Most of the processes that matter in a business have never been documented. They were figured out by people doing the work, refined over years, and they live in habit. Then someone decides to build software around one, and discovers there is nothing to build from.
This is a normal starting point, not a sign of a badly run business. Here is how we get from nothing to something you can build on.
Start at the end and work backwards
Do not begin with how does this start. Begin with what has to be true for this to be finished, then ask what had to happen immediately before that.
Forwards, people describe the process they think they should follow. Backwards, they describe what actually has to be there, because each step is anchored to a real requirement from the step after it. It is slower and it surfaces the approvals, checks and pieces of paper that get skipped in the tidy version.
Use one real job, not the general case
Ask how the process works and you get a summary. Ask someone to open the last one they completed and walk through it with the actual dates, the actual emails, the actual system screens, and you get the truth.
The specific case has all the mess in it. The two days waiting for an approval nobody mentions. The phone call that resolved something the system could not represent. The bit where they went to a colleague instead of following the process, because the process does not work for that customer.
Then do it again with a job that went badly. The difference between the two is where all the value is.
Follow the artefacts
People forget steps. Documents do not.
Every process leaves a trail: a quote, a job number, an email, a signature, a photo, a spreadsheet row. Trace those in order and you get the skeleton of the real process without relying on anyone's memory. A document that exists but nobody mentioned is a step somebody does automatically and has stopped noticing.
Pay particular attention to anything that gets printed. In a business full of systems, a printout usually marks the exact point where the digital process broke and a person bridged the gap.
Ask what happens when it goes wrong
Once you have the happy path, throw things at it. What if the customer changes their mind after dispatch? What if the numbers do not match at the end of the month? What if the person who normally approves this is away?
The answers are where the manual effort is concentrated, and they are the reason previous software failed. Systems get built for the standard case and then meet a business where a third of the work is exceptions.
Get the disagreements on the table
Walk the map through with the room and expect conflict. Two people will describe the same step differently, and both will be describing something real.
Usually it means the process forked at some point and nobody noticed, or two teams have different definitions of the same word. Those disagreements are the most valuable thing you will find all day, because software forces a single definition. Better to resolve it in a room with a whiteboard than three months into a build.
Write it so a new starter could follow it
That is the standard. Not a flowchart to admire, a document someone could use on their second day and get a correct result.
If it does not survive that test, there is still knowledge in someone's head that has not made it onto the page, and that knowledge will turn up as a change request later at ten times the cost.
Keep the parts that look wasteful
Every messy process has steps that look like pure overhead. Before you cut one, find out what it prevents.
Often a check exists because something went badly wrong once, and the person who added it has left. Remove it and you rediscover the original problem, in production, with your name on it. Understand it first, then simplify deliberately. That is the difference between improving a process and just making it faster.
