Strategy & Systems Design
Business process discovery: map the work, not the procedure
The procedure is the version people remember
Every business has two versions of each process: the one in the handbook, and the one people do. The second has extra steps that grew for good reasons. The photos were often missing, so the office started texting for them. Accounting didn't pull parts from the field app, so someone re-keys them.
None of that shows up in a flowchart drawn in a meeting. Automate the flowchart and the real steps either break or carry on by hand beside the new system. Discovery watches real cases, from the event that starts them to the outcome, and writes down what actually happens.
Shadow one case
Job J-418 · Hillcrest HOA · close-out
Nobody was slow. Every wait came from a handoff that depended on someone noticing: missing photos, a discount nobody could approve without the manager, a single person who sends invoices. Those handoffs are what the redesign has to remove.
What discovery looks for
01
Handoffs
How does the next person know to start?
Every time work passes between people or systems, something has to tell the next one. Often it's someone noticing.
Watch for: steps that start “when I see it”.
02
Re-keying
Where is data typed twice?
Parts typed from the field app into accounting, addresses copied from email into the CRM. Each one is a delay and a chance for a mistake.
Watch for: “I just copy it across”.
03
Waits
Where does a case sit still?
Most elapsed time is waiting, not working. The long waits point to the handoffs worth redesigning.
Watch for: waits that depend on one person being in.
04
Workarounds
What lives beside the system?
The spreadsheet of service-plan customers, the sticky note of who gets a discount. They hold rules the systems don't.
Watch for: files only one person updates.
05
Exceptions
What happens when it doesn't fit?
Reopened jobs, disputed invoices, missing information. The design has to give each one a state and an owner.
Watch for: exceptions handled “case by case” by the same person every time.
06
Judgment
Which decisions need a person?
Some steps are rules nobody wrote down; others are real judgment. Telling them apart decides what software can do.
Watch for: rules described as judgment because they've never been written.
What it hands to design
What discovery hands off
In
Out
Worth doing before you automate anything
Good fit
- A recurring process spans several people or systems.
- Work is slow or error-prone and nobody is sure why.
- You're about to choose an automation tool or build software for it.
Not the right fit
- The task and its failure cases are already understood and agreed; a short confirmation is enough.
- The process is being retired or replaced anyway.
Questions about business process discovery
Can't we just describe the process in a meeting?
A meeting gives you the procedure. Following a handful of real cases gives you the process: the waits, the re-keying, the exceptions. We do both, and the differences between them are usually the most useful finding.
How many cases do you follow?
Enough to see the normal path and the common exceptions. For most processes that's a handful of recent cases plus the ones people remember going wrong.
Does discovery disrupt the team?
Mostly it means short conversations with the people who do the work and access to the records they use. People are usually glad someone is writing down the workarounds they've carried for years.
What do we get at the end?
A map of the process as it runs, where the time goes, which steps are rules and which are judgment, and the questions to settle before design. It's useful even if you never automate anything.