How do you document a process before automating it?

Why document a process before automating it?

Because you cannot rebuild a job you have not seen clearly. Most processes in professional services firms have never been written down as they actually run. They live in the heads of the people who do them, with personal shortcuts, unwritten checks and quiet workarounds for systems that do not quite fit. Automate the version people describe in a meeting and you will build something that breaks on the first real piece of work.

Documentation also shows where the hours go. Once each step is timed, it is usually obvious that most of the effort sits in a handful of steps: gathering information from several places, retyping it into a template, formatting, and chasing people for input. Those are the steps worth changing.

What should you record about a process?

For each process, capture these elements. Together they give you everything needed to judge whether and how to rebuild it.

• Trigger: what starts the job. A client request, a date in the calendar, an inspection, a new instruction.
• Output: what finishes it, and who receives it. Get a real example.
• Inputs: every piece of information the job uses, and exactly where each one comes from: which system, spreadsheet, inbox or person.
• Steps: each action in order, who does it and roughly how long it takes.
• Templates and documents: every template, precedent or past document people start from, including the unofficial ones.
• Handoffs: every point where work passes from one person to another, and how it is passed.
• Checks: every review, sign off or verification, who does it and what they look for.
• Exceptions: what happens when the job does not follow the normal path, and how often that happens.
• Frequency: how often the job runs and how many people do it.

What are the steps to document a process?

1. Choose one process and define its edges. Write one sentence for where it starts and one for where it ends. Anything outside those edges is a different process. If you have not picked one yet, see choosing a process to automate.
2. Gather three real finished examples. Take recent outputs of the job, ideally one straightforward, one typical and one awkward. Work backwards from them.
3. Watch it being done. Sit with two or three people as they do the job on live work. Ask them to talk through what they are doing and why. Do not correct or suggest improvements yet.
4. Trace every input to its source. For each figure, sentence or attachment in the output, ask where it came from. Record the system and the person.
5. Time each step. Rough times are enough. Ask how long the step took on this piece of work and how long it takes on a bad day.
6. List the checks and the judgement. Separate steps that need professional judgement from steps that are assembly, copying or formatting. The first stay with people. The second are candidates for change.
7. Capture the exceptions. Ask what goes wrong, what is different for certain clients, and what they do when information is missing.
8. Draft a one page map. Use the table format below. Keep it readable.
9. Check it with the people who do the job. Walk them through it and ask what is missing or wrong. Revise until they agree it is how the job really runs.

What does a process map template look like?

A simple table is enough for most jobs. One row per step:

The example is illustrative. Your own rows will differ, and the point is that each one names a source, a template, a time and whether judgement is involved.

What mistakes should you avoid?

• Documenting the ideal instead of the real. Record what happens, including the workarounds. Improvement comes later.
• Asking only the manager. Managers often know the intended process better than the actual one. Talk to the people who do the work.
• Going too deep too early. You do not need every keystroke. You need every input, handoff, check and template.
• Ignoring the unofficial templates. The document people really start from is often an old piece of work, not the official template. Record it. The risk in copy and edit explains why it matters.
• Letting scope creep. If the map starts to include a second job, stop and split it.

What do you do with the map once it is finished?

Use it to decide what changes. Mark each assembly step and ask whether it could draw its inputs straight from where they already live. Mark each template and check whether it is ready to be filled automatically; preparing templates for automation covers how. Mark each check and confirm who remains accountable for it.

Multiply the time on the assembly steps by how often the job runs and the number of people doing it, then by your charge-out rate and by 46 working weeks, and you have the annual cost of the part worth changing. The unbillable hours calculator does that arithmetic.

The map also has value beyond automation. It is the start of a procedure new starters can follow and a record that survives when experienced people leave, which when knowledge leaves discusses. This mapping is exactly what our first week of any rebuild consists of; how we work describes it, and the audit suggests which process to map first.