How to distinguish the official process from the real process

Your team has a process manual. Your employees have a completely different way of getting the job done. Both exist simultaneously, and most of the time nobody talks about it — until you start an automation or software improvement project and the gap suddenly becomes impossible to ignore.

This article shows you how to surface the real process, understand why it diverged from the official one, and use that knowledge to build automation that actually sticks.

Why do the official process and the real process diverge in the first place?

Processes are documented at a point in time. The business keeps moving. New customers arrive with special requirements, software systems change, staff turns over, and pressure mounts to hit deadlines faster. Each of those forces nudges behaviour slightly away from the written procedure — and because each nudge is small and local, nobody formally updates the manual.

The result is a slow, invisible drift. After two or three years, the documented process describes a business that no longer quite exists.

This is not a failure of discipline. It is the normal behaviour of any organisation that is growing and adapting. The problem only becomes acute when you try to codify the documented process into software — because then the drift is frozen into code, and every employee has to choose between following the system and getting their work done.

What does the gap actually look like in practice?

The gap rarely announces itself. It hides in four common places:

1. The Excel workaround outside the main system A purchase order is registered in the ERP, but the purchasing team maintains a separate Excel sheet to track delivery promises from suppliers — because the ERP has no field for "expected partial delivery date." The Excel file is not backed up, not visible to management, and not connected to anything. It exists because someone once needed it and the system could not help.

2. The skipped approval step The procedure requires a department head to approve every customer discount above 10%. In practice, sales reps send a WhatsApp message to the manager, get a thumbs-up, and process the order immediately. The formal approval is logged retroactively — or not at all. Speed wins over compliance, every time, until an audit asks questions.

3. The manual data correction An order gets entered into FileMaker, and then re-typed by hand into Exact Online — every single order, every single day — because the two systems were never integrated. The employee doing this has developed a private set of rules for handling edge cases (what to do when the VAT code is missing, how to handle foreign currency orders) that exists nowhere in writing.

4. The informal process that lives in one person's head A long-tenured logistics coordinator knows that a particular carrier will not accept pallets above 800 kg without advance notice, that one customer requires a specific label format, and that Friday afternoon shipments need to be booked by noon or they slip to Monday. None of this is documented. It works perfectly — until that person is sick, on holiday, or leaves the company.

How do you find the real process?

You cannot find it by reading the manual or interviewing managers. You find it by going to where the work actually happens. Here is a practical approach:

Step 1: Follow the work, not the org chart

Ask to sit next to the person who handles the process end-to-end for one full working day. Do not explain what you are looking for. Watch what tools they open, what they copy-paste, what they check before they move to the next step, and — crucially — what they do when something does not fit the standard flow.

Step 2: Ask "what happens when it goes wrong?"

The workarounds live in the exception paths. Standard cases often look clean; it is the exceptions that reveal the real process. Ask: "What do you do when a customer order comes in after the cut-off?" or "What happens if the stock level in the system doesn't match the warehouse?" Every answer is a process branch that your official documentation probably does not mention.

Step 3: Collect the shadow tools

Ask every team member: "Do you use anything outside the main system to get your work done?" You will find Excel files, shared inboxes used as task lists, sticky notes with account numbers, WhatsApp groups used as approval channels, and personal calendar reminders that substitute for workflow triggers. List all of them. Each one is evidence of a gap between the system's capability and the team's actual need.

Step 4: Map what you find, not what you were told

Create a process map that reflects observed behaviour, not the procedure manual. Use simple swim-lane diagrams — one lane per role, one box per action. Mark every step that involves a tool outside the official system. Mark every decision point that relies on personal knowledge. Mark every step that skips a documented control. You now have a map of reality.

Step 5: Compare with the official process and name the gaps

Lay the real map next to the official procedure. For each divergence, answer three questions:

• Why did this divergence happen? (Missing system capability? Time pressure? Unclear ownership?)
• Is the workaround solving a real business need, or just a bad habit?
• What happens if we automate the official process and ignore this divergence?

That last question is the most important one. Automating the wrong process is worse than not automating at all — it locks inefficiency into code.

What should you do with the gaps you find?

Not every gap needs to be eliminated. Some workarounds are genuinely better than the official process and should become the new standard. Others are risky and need to be replaced. A few are simply habits with no good reason behind them.

Sort each gap into one of three buckets:

Gap type	What it means	What to do
Necessary workaround	The real process fills a gap the system cannot handle	Build the real process into the new system
Risk workaround	The real process bypasses a control that exists for a reason	Re-engineer the control so it does not slow people down
Legacy habit	The workaround made sense years ago but no longer serves a purpose	Remove it — but explain why to the team

What mistakes do companies make at this stage?

Trusting the documentation without verification. Many automation projects start with a process document handed over by a manager. That document describes intent, not behaviour. Always verify.

Only interviewing managers. Managers often describe the process as it should work. The people doing the work describe it as it does work. Both perspectives matter, but the operational reality lives on the floor, not in the meeting room.

Treating workarounds as failures. A workaround is a signal that the official system or process has a gap. Criticising the workaround without addressing the gap is how you lose the trust of the people whose cooperation you need.

Mapping the process once and moving on. Processes continue to evolve after you map them. Build in a review cadence — especially after go-live, when new workarounds will start forming around the new system almost immediately.

Checklist: signs that your official and real processes have diverged

• Employees maintain personal Excel files or shared drives alongside the main system
• Approval steps are routinely completed after the fact rather than before
• Data in the system regularly needs to be corrected manually by a specific person
• Onboarding a new employee takes months because so much knowledge is unwritten
• Employees describe the system as "not matching how we actually work"
• There are WhatsApp groups, shared inboxes, or calendar reminders serving as workflow tools
• Different team members handle the same situation in different ways
• Audit trails in the system do not reflect when decisions were actually made

If you checked three or more of these, the gap between your official and real process is large enough to derail an automation project that does not account for it.

FAQ

How long does process discovery like this take? For a single department with a clear end-to-end process, a thorough discovery takes two to five working days — including observation sessions, interviews, shadow tool collection, and mapping. Complex, cross-departmental processes take longer. Skipping it to save time reliably costs more time later.

Should we fix the process before or after building the new system? Both happen together. You cannot fully design a system without understanding the real process, and you cannot finalise the real process without knowing what the system will be able to handle. Expect the map to be revised several times during the design phase — that is normal and healthy.

What if employees are reluctant to reveal their workarounds? They are usually reluctant because they fear being blamed or because they worry the workaround will be taken away without a replacement. Make it explicit from the start: you are not there to eliminate workarounds, you are there to understand what the business actually needs so the new system can support it. That framing usually opens the conversation.

Is this only relevant for large companies? No. Companies with ten employees have informal processes that no one has ever written down. In small teams, the gap between official and real is often even wider, because less is formalised to begin with.

What tools should we use to map the real process? Low-tech works well at this stage: a whiteboard, sticky notes, and a camera to photograph the result. Digital tools like Miro, Lucidchart, or even a structured Word document work for documentation. The tool matters far less than the discipline of mapping what you observe rather than what you were told.

---

Distinguishing the official process from the real one is not a preliminary nicety — it is the foundation that determines whether any automation project delivers value or just digitises dysfunction. At Loggix, this kind of process discovery is always the first step before any custom software development, API integration, or workflow automation begins. If your team is preparing for a software improvement project and you want a structured way to surface what is actually happening on the floor before writing a single line of code, that is exactly the kind of conversation we are set up to have.