The quiet org chart: who really runs your workflows
Every workflow has an official owner and a real owner. AI engagements that don't find the real one tend to die in the third quarter.
The org chart the process actually runs on
Every enterprise process has two org charts. There is the one in the HR system, and there is the one that describes who actually unblocks the work: the analyst who knows which of the three reference tables is current, the operations lead everyone messages directly, the shared mailbox two people watch out of habit.
The second chart is where automation projects go to die. It is undocumented, so a process map built from interviews with managers misses it entirely. The workflow diagram shows a clean transition between two systems; the reality is a person who checks something every morning and quietly fixes what is wrong.
Finding that person, and understanding what they are compensating for, is the single highest-value activity in the discovery phase.
Why interviews are not enough
Asking how a process works produces a description of how it is supposed to work. This is not dishonesty; it is how memory operates. People describe the intended path and forget the exceptions, because the exceptions have become reflexes.
Observation closes the gap. Sitting with the people running the process for a few days surfaces the workarounds, and more importantly surfaces their frequency. An exception that happens in two percent of cases is a footnote. An exception that happens in forty percent of cases is the process, and the documented path is the footnote.
System evidence closes it further. Ticket transitions, audit logs and mailbox metadata give you the distribution of real cases, including the ones nobody thought to mention. Where the observed process and the logged process disagree, the logs are usually right about frequency and the humans are usually right about why.
Automating around a compensating control
When you find someone compensating for an upstream defect, there are two possible responses, and choosing the wrong one is how automation projects create fragility.
The wrong response is to automate the compensation. You encode the morning check into a scheduled job, the defect remains, and now the workaround is invisible as well as unowned. The next time the upstream system changes, the job fails silently and nobody remembers why it existed.
The right response is to fix upstream, which is slower, involves another team, and is politically harder — and which removes the step permanently. If that is genuinely impossible within the engagement, the compensation should stay human and stay documented, rather than being buried in a cron job.
What this means for how you staff a redesign
A workflow redesign is not a project that can be executed from a requirements document, because the requirements document is a description of the first org chart. It needs someone embedded long enough to see the second one.
It also needs the people who run the process to be participants rather than subjects. The analyst who knows which table is current is not an obstacle to automation; they are the specification. Treating that knowledge as an input, and saying so, is also the difference between a rollout that gets adopted and one that gets routed around.
The uncomfortable version of this is that the people best placed to describe the process are often the people most exposed by automating it. Naming that early, and being explicit about what happens to those roles, is not a soft skill. It determines whether you get accurate information.
How to find the second chart quickly
Three questions surface most of it in a single afternoon. Who do you message when this goes wrong? What do you check before you start? What would break if you were on holiday for two weeks?
The third question is the most productive, because it asks people to describe their own indispensability, which they are usually willing to do accurately. The answers name the compensating controls directly, and they name them in the order of how much damage their absence causes.
Cross-check with the systems. If a person says they check something every morning, there is almost always a trace — a login, a query, an export, a message in a shared channel. The trace tells you the real frequency, which is often higher than the person estimated.
Documenting it without weaponising it
There is a version of this exercise that produces a map of who is redundant, and everyone involved can see it coming. That version gets you incomplete information from the second interview onwards.
The framing that works is to document the compensation rather than the person: what defect is being absorbed, how often, and at what cost. That is a statement about the system, and it points at the upstream fix rather than at the individual holding it together.
It is also more accurate. The knowledge that keeps a broken process running is genuinely valuable, and the organisations that treat it as a specification rather than as waste end up with better systems and more willing participants.
The deliverable
What comes out of this is not an org chart. It is a list of compensating controls, each with a frequency, a cost, and a decision: fix upstream, automate deliberately with an owner, or leave human and document.
That list is more useful than the process map it sits alongside, because it is the part that explains why the process map was wrong. It is also the part that predicts which automations will hold and which will fail quietly in month four.
Every entry left undecided is a future incident. Deciding them is the work.