Business process modeling

A business process is a connected set of activities that turns a trigger and inputs into an outcome for someone. A model makes that work explicit: who acts, what they need, how decisions change the route, and what counts as completion.

Use activity names such as Extract incident facts with exact source spans, rather than Extract. Ask Are the affected-person counts sufficient? at a decision and label the answers. Show the systems used and name the documents or records passed between steps. Manual and interactive work belongs to human performers; system work retains an explicit responsible human role.

The current toolkit supports those system/work-product references and emits an operator guide alongside BPMN. They describe the work; executable contracts and actual results still establish what was supplied or produced. A complex process needs readable detail views as well as an overview. The revised breach-response example applies this distinction within an explicitly limited initial-response exercise.

“Review an NDA” names a service. It does not yet explain the process. A model might show receipt of the document, an intake check, comparison against an approved playbook, treatment of exceptions, and a handoff for signing. The model reveals questions that the short description leaves unanswered.

Architecture, process, and task

Different levels answer different questions. A process architecture describes the landscape of an organization’s work. A hierarchy decomposes that landscape into manageable areas. A workflow describes the ordering and interaction of activities within a chosen scope.

View the relationship model (Mermaid)

flowchart TB
    A["LEGAL SERVICE ARCHITECTURE<br/>How the function's work fits together"]
    A --> B["Contract services"]
    A --> C["Disputes services"]
    A --> D["Advisory services"]
    B --> E["Contract intake and review"]
    E --> F["Check request completeness"]
    E --> G["Compare terms with playbook"]
    E --> H["Resolve exceptions"]
    G --> I["Extract a clause and record its source"]

This diagram presents an illustrative decomposition, not a required number of levels. The appropriate detail depends on the decision under examination: an executive considering ownership requires a different view from an engineer implementing a retry.

The basic vocabulary

Pools in BPMN represent participants; lanes partition activities within a participant. Sequence flows order work within a process. Message flows describe communication between participants. An internal sequence arrow should not silently stand in for a reply from an external client.

View the relationship model

flowchart TB
    S(["Request received"]) --> I["Check completeness"]
    I --> G{"Required information present?"}
    G -->|No| Q["Ask requester for missing information"]
    Q --> W["Wait for response"]
    W --> I
    G -->|Yes| R["Review against approved criteria"]
    R --> E(["Review ready for decision"])

This is a conceptual process map. The guide uses simplified shapes for teaching; an exported BPMN model has formal element types and connection rules.

Keep responsibility separate from automation

Activities may be manual, interactive, or automated. A lawyer conducting a conversation performs a manual activity. A lawyer checking an AI comparison on screen performs an interactive activity. A system checking that a required identifier is present may perform an automated activity.

These categories describe how work happens. They do not transfer accountability. The person responsible for a service may remain accountable when a system performs one of its tasks.

Business rules also deserve their own record. “Escalate any departure from this approved clause standard” needs an identified standard, an exception definition, and an authorized decision-maker. A diamond labeled “high risk?” is insufficient if nobody can explain the criteria.

Model the present before proposing the future

The As-Is model records current practice, including workarounds and uncertainty. The To-Be model proposes a changed process. Preserve both. Otherwise the proposed solution can quietly become an inaccurate account of what already happens.

Observe real handoffs and ask people to validate the model. Measure elapsed time separately from active work time: a ten-minute task may sit in a queue for days. Investigate repeated clarification, duplicated entry, unclear ownership, and avoidable rework before recommending automation.

View the relationship model

flowchart TB
    I["Observed issue<br/>Requests repeatedly returned"] --> C["Possible cause<br/>Required information unclear"]
    C --> R["Root-cause hypothesis<br/>No owner for intake requirements"]
    R --> V["Validate with evidence"]
    V --> A["Change<br/>Owned criteria and clearer intake"]
    A --> M["Measure<br/>Complete submissions and rework"]

A hypothesis remains distinct from an established cause. An interview may suggest an explanation without proving it. Evidence is required to distinguish an apparent cause from a deeper mechanism and to connect a recommendation to an observable outcome.