Map the process that actually runs
Procedure documents describe the intended process. The real one contains a spreadsheet that three people maintain, a chat group where exceptions are agreed, a step that is skipped when the month end deadline is close, and one person who knows how to handle the awkward supplier. Automating from the document produces something that handles the ordinary path and breaks on everything the document never mentioned, which is where most of the effort actually goes.
We map by observation and interview, recording who touches each step, how long it takes, how often it occurs, and how often it comes back for rework. Rework volume is the most useful figure and the one nobody has, because it points at where the process is failing rather than where it is merely slow. A step taking twenty minutes once a week matters less than a five minute step done two hundred times with a fifth of them returning.
The map also has to record decision authority honestly. Who approves, and who actually approves when that person is travelling. Systems tend to encode the official answer, and the official answer is why people share credentials. If a process depends on delegation, temporary authority or a tolerance a supervisor applies informally, the automation has to model that explicitly or it will be worked around within a month of going live.
- Process observed and timed as it runs, including the spreadsheets and the chat groups
- Volume and rework rate recorded per step, since rework points at the real problem
- Actual decision authority captured, including delegation and informal tolerances
- Exceptions catalogued by type and frequency rather than treated as one category
- The map agreed by the people who do the work before anything is designed