Business Processes

Definition

A process is an ordered set of activities producing an outcome: order-to-cash, hire-to-retire, quote-to-policy. It crosses capabilities, teams and systems.

Why architects should map processes, not just capabilities

Capabilities tell you what boundaries to draw. Processes tell you what crosses them — and the crossings are where the architecture is decided.

Specifically, a process map reveals:

• Handoffs. Every transfer between teams or systems is a place where latency, error and lost context accumulate. The number of handoffs predicts the process's cycle time better than the work itself.
• Manual steps. Someone rekeying data between systems is an integration requirement wearing a disguise, and it is invisible on any system diagram.
• Wait states. Where does work sit? Usually in a queue for a human decision, and usually the dominant term in the elapsed time.
• Exception paths. The 15% of cases that do not follow the happy path frequently consume 80% of the effort. Architectures designed only for the happy path fail here, and this is where most automation projects disappoint.
• Rework loops. Work that comes back is a quality signal and an architecture signal.

What to measure

• Cycle time end to end, and touch time — the time actually being worked on. The ratio is usually startling and is the strongest argument for automation.
• First-pass yield — the proportion completing without rework.
• Exception rate, and where exceptions originate.

The architectural implications

A process with many handoffs and long wait states does not need a faster system; it needs fewer handoffs. Automating a handoff is far less valuable than removing it.

A process whose exception paths dominate needs the exceptions modelled as first-class flows rather than as error handling — which is a design decision that must be made early, because retrofitting it means rebuilding the workflow.

Failure scenarios

• The documented process is not the real one. Observe rather than interview; people describe the process as designed, not as performed.
• Only the happy path modelled, so the system fails where the work actually is.
• Automating a bad process, making a poor design faster rather than better.
• Process ownership diffuse, so no one can approve a change that crosses departments.

Interview question

"A process takes eleven days end to end and involves four hours of actual work. What does that tell you and where do you look?"