SOP vs reality: why your documented processes lost to the informal ones

Your company has a process manual. It lives in a shared drive, maybe on Confluence, possibly inside a system someone purchased three years ago for this exact purpose.

It is thorough. It has flowcharts. It names roles and responsibilities. A new hire could read it and understand how things are supposed to work.

They would also be wrong about half of it.

The documented process is a snapshot. The informal process is the live system. The gap between them is not a documentation problem. It is an evolution problem.

The formal process was designed once. The informal one has been evolving every day since.

There is a reason informal processes always beat documented ones. It is the same reason a trail through a forest looks nothing like the park map. The map was drawn before anyone walked the path. The trail was carved by the feet of people who found the actual fastest way.

Something breaks in the ERP. The ticket goes to IT. IT says it will take three weeks. The person who needs the output today finds a workaround. Maybe they export to a spreadsheet. Maybe they call someone in another department who has a different system. Maybe they do it by hand for an afternoon. It works. They keep doing it.

The workaround was not in the SOP. It could not have been. The SOP describes how the system works when it works. The workaround describes how the company survives when it does not.

Every workaround is a patch applied by someone who needed to get their job done. Each one is rational at the time. The person who built it is not trying to undermine the process. They are trying to serve a client, close a month, or ship something before a deadline. The company benefits from their initiative. And the documentation falls one step further behind.

The documentation lags because conditions change faster than process owners can update a manual.

The informal process is not just a collection of workarounds. It is a parallel operating system with its own rules, its own experts, and its own quality standards. And it has something the documented version does not: it is tested every single day.

When a supplier changes their invoice format, the formal process says nothing. The informal process produces three people who figure it out by Thursday, and one of them writes a note that lives in a Slack thread nobody else reads.

When a client asks for something the CRM does not support, the formal process says fill out the standard form. The informal process produces an Excel file that has been copy-pasted and modified twenty-seven times and is now the actual system of record.

When someone leaves, the formal process says hand over your files. The informal process produces a two-hour phone call where the departing employee tells the replacement which things actually matter and which steps can be safely skipped.

None of this is visible on an org chart. All of it is essential.

The informal process is where the company's real competence lives. It is also where the company's real risk lives, because it is invisible to anyone who is not already inside it.

McKinsey's MGI research published in 2024 found that roughly 90% of European companies report using AI, but fewer than 40% report seeing measurable results from it. The gap is not a technology gap. It is a mapping gap.

Companies that build AI systems on top of their documented processes are building on fiction. The AI follows the SOP. The SOP does not match reality. The AI produces output that looks correct by the rules but is wrong by the standards of the people who actually do the work. They stop using it. The project is labeled a failure. The underlying problem is never named.

The underlying problem is that the company automated the map instead of the territory.

This is not a new problem. It predates AI by decades. Companies have been building ERP systems, workflow tools, and reporting dashboards on top of idealized process models for twenty years. The result is always the same: the system goes live, people find it useless, they build their own parallel systems, and leadership wonders why adoption is low.

AI makes this problem more expensive because it moves faster. A broken ERP is annoying. A broken AI system running on bad process assumptions produces confident errors at scale.

The people who know the informal process can usually see the error immediately. But by the time they notice, the system has already acted on it.

There is a version of this conversation where the answer is better documentation. More SOPs. More frequent reviews. A dedicated process owner. A governance committee.

That version misunderstands what is happening. The informal process is not winning because documentation is bad. It is winning because documentation is inherently slow and the business is inherently fast. No amount of process governance closes that gap. The gap is structural.

The people who maintain the informal system are not lazy about documentation. They are busy doing the work that documentation describes but does not do. Asking them to keep the manual updated is like asking a surgeon to narrate every move during an operation. Possible, in theory. A terrible idea in practice.

The companies that handle this differently do not try to eliminate the informal process. They study it. They treat it as the real process and the documentation as a lagging indicator.

When something changes, they do not ask who will update the SOP. They ask who figured out the new way, what they learned, and how to make that learning available to the rest of the company without turning it into bureaucracy.

That is a different posture. It is closer to anthropology than to process management. It starts with curiosity instead of compliance.

The first step is the least intuitive. Before mapping a process for any purpose, spend a day watching the informal version. Not the documented one. The one that happens on a random Tuesday when everything is slightly broken and everyone is slightly behind.

Follow a single piece of work from start to finish. Not the happy path. The real path. Count the handoffs. Note where the system stops being helpful and the person starts compensating. Write down the questions that get asked, the workarounds that get used, the decisions that get made by someone who was not supposed to be involved.

The map you produce will be ugly. It will not fit on a clean flowchart. It will include three exceptions for every rule and a dependency on someone named Claire who knows what to do when the system throws a specific error code.

That map is worth more than a perfect SOP. Because it is true.

There is a cost to living with the informal process that companies rarely calculate. Every time someone asks how to do something, there is a response delay. Every time a workaround breaks because the person who built it is on vacation, there is a discovery cost. Every time a new hire spends three months learning the real process instead of the documented one, there is a productivity gap.

These costs are invisible because they are distributed. They look like normal friction. They feel like how business works. But the total is not normal. It is the tax a company pays for operating with two systems instead of one.

The useful test is whether the company is willing to look at the process it actually has, rather than the one it wishes it had, and build from there.

AI, workflow systems, knowledge platforms, new hires, audits, clients running due diligence. All of them interact with the real process, not the documented one.

The companies that understand this before they build anything are the ones whose investments actually work. The ones that do not are the ones buying tools to automate a map that nobody follows.

Your SOP is not wrong. It is just a photograph of something that keeps moving. The thing worth studying is where it moved to.