AS-IS Business Workflow

The 3 points of a business workflow

A business workflow is written on two axes — role (vertical) × timeline (horizontal) — with INPUT/OUTPUT and confidence noted alongside. Only when all of this is in place does it become a "shared language" that both the vendor and the field can treat as something to debate.

• ─① Role × timeline format (departments/roles down, timeline across)
• ─② State INPUT/OUTPUT for each step (including whether it's paper, file, or verbal)
• ─③ Note confidence with ○ △ × (make visible the points to resolve after discovery)

Why role × timeline

Write a "flowchart" and you lose who does it. Write an "org chart" and you lose when it happens. Role × timeline is the only format that shows both at once. Anyone who reads it arrives at the same understanding of the work.

The granularity of INPUT/OUTPUT

Writing "INPUT: order sheet, OUTPUT: confirmed order sheet" on a step called "order confirmation" conveys nothing. Break INPUT/OUTPUT down to the medium.

• ─Medium: paper / PDF / Excel / system screen / verbal / email
• ─State: unprocessed / in progress / awaiting confirmation / complete
• ─Storage location: own desk / shared folder / system DB / physical filing
• ─Next recipient: to whom (role) / how (medium) / by when

Status × CRUD bird's-eye map

The upstream/downstream "boundaries" of a business workflow can be organized as combinations of status transitions and CRUD (create, update, delete). Example: when a return comes in after "shipped," what status does it revert to, is the slip an UPDATE or a DELETE, is the payment refundable? — these are essential points of requirements definition, and you should make them visible as points at the AS-IS stage.

Boundary points (preventing requirements gaps)

While writing AS-IS, always surface the following boundaries. If they're missed in requirements definition, they blow up in the field.

• ─Order → order confirmation: until when, by whom, and how is cancellation recorded?
• ─Shipment → delivery: who updates the in-transit tracking information?
• ─Delivery → acceptance: on a failed acceptance, what status does it return to, and within how many days?
• ─Billing → payment: up to what status is a refund possible after payment?
• ─Monthly close: are post-close corrections a separate slip, or can the original slip be UPDATEd?

Draw it on 3 layers: goods, information, money

If you draw a business workflow as a "sequence of tasks," the "information" and "money" layers fall out. In practice, drawing the three layers in parallel makes the requirements-definition points visible in three dimensions. Example: in a return, the goods come back, but the information (reversing the recognized revenue) and the money (the refund) move at different times. Try to draw this on a single layer and one of them always gets dropped.

How to set confidence to prevent "thinking you're done"

The biggest trap in writing a business workflow and feeling satisfied is assuming "everything is ○." Confidence has three levels, but a flow without at least 30% △ and × is suspect. The first version written for a new project almost always has △ and × making up 40–50%. The whole point is to make those visible as "points that gather," so don't let everything be ○.