Ease AIMost process documentation is fiction.
Not intentional fiction. But fiction all the same. It was written by someone who left two years ago, or by a consultant who spent three days onsite, or by you when you still did the work yourself and remembered every step.
The problem is not that the documentation is wrong. The problem is that the work has changed and the documentation has not. Someone found a faster way. A supplier changed their portal. A staff member retired and took a workaround with them. The process that happens today is not the process that is written down.
That gap will destroy an automation project. You will spend money building the wrong thing, or building the right thing for a process no one actually follows. Then you will spend more money fixing it, or you will abandon it and go back to doing it manually.
The solution is not better documentation. The solution is to map the process as it actually happens, right now, before you automate anything.
The exercise: one week, no consultants
You do not need software for this. You do not need a consultant. You need a notebook, a pen, and the willingness to watch people work without telling them how to do it better.
Pick one process. Not three. One. The one that takes the most time, or the one that causes the most errors, or the one that makes you stay late on Fridays. Write its name at the top of a page.
Now go talk to the person who does it.
Step one: ask them to describe it
Sit with them. Ask them to walk you through the process from start to finish. Write down every step they mention. Do not edit. Do not correct. Do not say "but the manual says". Just write.
You will notice something immediately. They will describe steps that are not in the manual. They will skip steps that are. They will mention workarounds, exceptions, and things they do "just to be safe". Write all of it down.
This takes thirty minutes. Do not rush it.
Step two: watch them do it
Descriptions are not enough. People forget steps they do automatically. They simplify. They tell you what they think you want to hear.
So watch them do the work. Sit beside them while they process an order, or book an appointment, or generate a report. Write down every step you see. Every click. Every copied field. Every time they switch windows or check a spreadsheet or send an email.
You will see more steps that were not in the description. Write those down too.
This takes an hour, maybe two. If the process only happens once a week, wait until it happens. You cannot map a process you have not seen.
Step three: ask about the exceptions
No process runs the same way every time. There are edge cases, urgent requests, mistakes that need fixing. Ask about those.
What happens when the supplier is out of stock? What happens when a customer changes their mind? What happens when the file is corrupted, or the system is down, or the approval does not come through?
Write down the exceptions. They are not edge cases. They are part of the process.
Step four: write it down in order
Now take everything you have written and organise it. Start to finish. Every step. Every exception. Every workaround.
Use plain language. "Check the inbox for orders" is better than "monitor incoming communications". "Copy the customer name into the spreadsheet" is better than "populate the client database".
Number the steps. If there are decisions, write them as questions. "Is the order over $500? If yes, go to step 12. If no, continue to step 8."
This is your process map. It is not beautiful. It does not need to be.
Step five: check it with someone else
Show the map to another person who does the same work, or who did it before, or who covers when the usual person is away. Ask them if this is accurate.
They will catch things you missed. They will tell you about steps that only happen on Thursdays, or only with certain customers, or only when the manager is out. Add those.
This is the part most people skip. Do not skip it.
What you will learn
You will learn that the process takes more steps than you thought. You will learn that half the work is copying information from one system to another. You will learn that someone is doing something manually because a system does not talk to another system, or because no one told them the faster way exists.
You will also learn whether automation is worth it.
If the process is three steps and happens twice a month, automation is not worth it. Do not spend money on it. If the process is thirty steps and happens ten times a day, automation will pay for itself.
The map tells you which one you have.
The gap is the point
The gap between the documented process and the actual process is not a problem to be embarrassed about. It is information. It tells you where the work has evolved, where the bottlenecks are, and where the errors come from.
It also tells you what to automate. You do not automate the manual. You automate the map.
Most automation projects fail because they automate what someone thinks happens, not what actually happens. The map prevents that. It is the cheapest insurance you can buy, and it costs nothing but time.
Before you spend anything
Do this exercise before you talk to anyone about workflow automation. Do it before you ask for pricing. Do it before you apply for a grant or call a consultant or buy software.
If you do it and decide automation is not worth the cost, you have saved yourself several thousand dollars. If you do it and decide it is, you will spend that money better because you will know exactly what you are building.
The exercise takes a week. The automation takes longer and costs more. Do the cheap part first.
If you have mapped a process and want to talk about what automating it would cost, or whether it is worth doing at all, email me at info@easeaiworks.com. I will tell you if I think it is a good fit. I will also tell you if I think it is not.