In this guide 6 sections
Pick one workflow, mark where it starts and ends, and list every step with its owner, input and output. Add the documents used and the exceptions that occur. Then walk the map with the people who do the work. Build software only after they agree it matches reality.
Choose one workflow and its edges
A workflow map fails when it tries to cover the whole business. Pick one flow, such as a quotation to an order or a purchase request to a payment. A narrow flow keeps the session short. The people who know that work can finish the map in one sitting.
Then fix its edges. Write down the event that starts it and the event that ends it. A quotation flow may start with an enquiry and end with an accepted order.
Edges stop arguments later. Anything outside them goes on a separate map.
Capture steps, owners and handoffs
Sit with the people who do the work, not only their manager. Ask them to walk through the last real case, step by step. Real cases reveal what a policy document leaves out.
For each step, write four things. Note who does it, what they receive, what they produce and where they record it. A step with no clear owner is a finding in itself.
Draw the map in lanes, one lane for each person or team. Every time a line crosses into another lane, that is a handoff. Handoffs are where work waits and where mistakes enter.
- Owner of the step
- What arrives and from whom
- What leaves and to whom
- Where the step is recorded today
Record documents, rules and exceptions
List every document and form the workflow touches. Include the informal ones, such as a message in a group chat or a note on a printout. If people depend on it, it belongs on the map.
Write the rules in plain sentences. An order above a certain value needs a second approval. A repeat customer skips the credit check. Rules like these become settings in the software later.
Then collect the exceptions. Ask what happens when a customer cancels, a bill is wrong or an approver is on leave. Exceptions are where most software projects meet surprises. Capturing them early costs a short conversation, while discovering them after the build usually means reopening the design and re-agreeing the scope with everyone involved.
Test the map with the people involved
A map drawn by one person is a guess. Put it on a wall or a shared screen and let each owner correct their lane. Ask them to find the step you got wrong. Corrections made at this stage are cheap, because nothing has been built and the only thing that changes is a sheet of paper on a wall.
Then trace two or three recent cases through the map, including one that went badly. If a case cannot be traced, the map is missing a path.
Keep the corrections visible. A map that shows what changed after review is easier to trust than a clean one that nobody has challenged.
Use the map to scope the software
Once the map is agreed, mark each step as manual, partly digital or already in a system. The manual steps with the most handoffs are the usual first targets.
Also mark what should change. Some steps exist only because of an old limitation. Remove them before building, not after. Software that copies a clumsy process makes the clumsiness permanent.
GullySystem’s Software Audit and Digital Transformation work uses this kind of map as the base for a scope. The map also gives a vendor something concrete to quote against.
Workflow mapping worksheet
A lane-based sheet with one column per team and rows for each step. Each box carries the owner, input, output and record. A second page lists rules, documents and exceptions. Fill it in during a working session with the people who do the work.
Open a blank worksheet to printQuestions owners ask
Do we need special tools to draw a workflow?
No. A whiteboard, sticky notes or a shared sheet is enough. The value is in the conversation with the people who do the work, not in the drawing tool.
How detailed should the map be?
Detailed enough that a new joiner could follow the flow. Stop at the level where a step becomes one person doing one task in one system.
What if teams describe the same flow differently?
That is useful. Record both versions and ask which one the business wants. Software cannot hold two versions of the same rule.
Should we map the current flow or the ideal one?
Map the current one first. Then mark the changes you want. Starting from the ideal flow hides the exceptions that people handle today.