A shadow process is undocumented work that the organization depends on but has never described anywhere.
It is not the same as a workaround, although workarounds are one source. A shadow process is a stable, repeated pattern of activity that carries real operational load: the spreadsheet three teams reconcile against, the approval that happens over chat before the formal one, the manual check a regional team added six years ago because the system could not handle a case type.
Shadow processes matter for a specific reason. They are invisible to both instruments enterprises normally use to understand their operations. Documentation does not describe them because nobody wrote them down. System logs do not record them because they happen outside the systems.
That leaves a category of work that is simultaneously load-bearing and unmapped. Redesign, automation, and AI deployment all fail in predictable ways when they are drawn around the visible operation and the shadow layer is discovered afterward.
Key takeaways
- Every large enterprise runs on three layers: macro processes, micro processes, and shadow processes.
- Shadow processes form for rational reasons, usually a system limitation, a policy gap, or a speed requirement the official path cannot meet.
- They are invisible to process mining by construction, since they generate no event data in connected systems.
- The people who run them often do not consider them processes at all, which is why direct questions rarely surface them.
- Automating around them scales the problem. Automating over them breaks the operation.
- Surfacing them requires asking about exceptions and pressure, not about process.
The three layers of enterprise work
| Layer | What it is | Where it is documented | Who knows it |
|---|---|---|---|
| Macro processes | End-to-end value streams: order to cash, hire to retire, claim to settlement | Process architecture, executive slides | Leadership, process owners |
| Micro processes | The steps inside each phase: validation, approval, escalation, reconciliation | SOPs, work instructions, system configuration | Team leads, experienced practitioners |
| Shadow processes | The undocumented work that connects, corrects, or bypasses the other two | Nowhere | The people who run them, and often only them |
Most transformation programs operate at the first layer and assume the second is documented accurately. The third layer is where the surprises live.
The proportion is worth taking seriously. In processes with significant exception volume, the shadow layer can carry a substantial share of the operational effort while appearing nowhere in any system of record.
What is a shadow process?
A shadow process is a stable, repeated pattern of work that the organization depends on, that is not described in any documentation, and that generates no record in any system of record.
Three properties distinguish it from a one-off workaround.
Stable. It has a routine. The same person or role does it on the same trigger, usually in the same way.
Depended upon. Something downstream would break if it stopped. That is what separates a shadow process from an individual habit.
Unrecorded. No SOP describes it and no system logs it. This is the defining property and the reason it is hard to find.
Common forms
| Form | Example | Why it exists |
|---|---|---|
| Reconciliation spreadsheet | A file that resolves disagreements between two systems | The systems were never integrated |
| Pre-approval | An informal sign-off over chat before the formal request | The formal path is slow and rejection is costly |
| Manual enrichment | Someone adds context the upstream system did not capture | The intake form was designed for a different case type |
| Regional exception | One country adds a compliance check not in the standard flow | Local regulation the global process does not address |
| Routing by knowledge | Requests go to a specific person who knows where they belong | The routing rules do not cover the real case distribution |
| Shadow escalation | A problem gets solved by asking someone directly rather than raising a ticket | The formal escalation path is slow or unclear |
| Parallel record-keeping | A team maintains its own tracker alongside the system | The system view does not answer the questions the team needs |
| Retry-by-hand | Someone manually reruns a failed automated step | The automation has no retry logic for a known failure mode |
Every one of these exists because someone solved a real problem. That is the point most transformation efforts miss: the shadow layer is not evidence of indiscipline. It is evidence of a gap between what the official process supports and what the work requires.
How they form
The formation sequence is consistent enough to be predictive.
A gap appears. A system cannot handle a case type, a regulation changes in one market, two tools disagree on a field, an automation fails on a specific condition.
Someone improvises a fix, because the work still has to get done today. The fix is local, undocumented, and effective.
The fix repeats. What began as an exception becomes a routine, then becomes the way that person does the job.
Others adopt it. A colleague copies the spreadsheet. A new hire is trained on it as though it were the process, because from their perspective it is.
It becomes load-bearing. Downstream teams now depend on the output. Removing it without replacing it would break something.
At no point in that sequence does anyone make a decision to create an undocumented process. Each step is the reasonable response to the previous one.
Why systems cannot see them
Two instruments dominate enterprise process understanding, and each has a structural blind spot for this category.
Process mining reads what systems record. System-log mining reconstructs workflows from the transaction data enterprise systems already store. Work that happens in spreadsheets, email, messaging platforms, or someone's head produces no event data, so it does not appear in the model. This is not a limitation of any particular vendor. It is a property of the method.
Documentation records what someone wrote down. Shadow processes form after the documentation is written, precisely because the documented path did not handle a case. Nobody goes back to add them, partly because doing so would require admitting the official process is incomplete.
There is a third blind spot that is less discussed. Direct questioning often fails. If you ask someone to describe their process, they describe the official one, because that is what the word "process" means to them. The spreadsheet is not a process in their mind. It is just what they do to get the work done.
This is why surfacing shadow processes requires different questions.
Shadow layer detection
Where each instrument sees and where it does not
| Instrument | Macro processes | Micro processes | Shadow processes |
|---|---|---|---|
| Process architecture documents | Full view | Partial | None |
| SOPs and work instructions | Partial | Full view of intent | None |
| Process mining (event logs) | Full view within systems | Full view within systems | None |
| Task mining (desktop capture) | Limited | Partial | Partial, if it happens on screen |
| Stakeholder workshops | Full view | Partial | Rarely, depends on who is in the room |
| Conversational discovery at scale | Partial | Full view of practice | Full view, if the questions are right |
The shadow column is the one that determines whether a redesign works. Most programs have no instrument that reads it.
The questions that surface them
Asking "what is your process" produces the official answer. These questions produce the real one.
About exceptions
- What happens when the standard path does not work?
- What is the most common reason a request comes back to you?
- Which cases take much longer than the rest, and why?
- What do you do when a system step fails?
About artifacts
- Which spreadsheets or trackers does your team maintain outside the system?
- What information do you have to look up somewhere else before you can proceed?
- Is there anything you re-enter into a second system?
- Which report do you build by hand every week?
About people
- Who do you go to when something is stuck?
- Is there someone whose absence would slow this work down significantly?
- Who knows the parts of this that are not written down?
- Who trained you, and what did they teach you that is not in any document?
About pressure
- What would you do differently if you had more time?
- Which step do you do because you are supposed to, rather than because it changes the outcome?
- Where do you check something twice?
- What is the part of this job you would warn a new hire about?
About change
- What did this process look like two years ago?
- What changed recently that the documentation has not caught up with?
- Which rule exists because of a problem that no longer happens?
The last question in that group is one of the most productive. A meaningful share of shadow processes are controls added in response to an incident that was resolved years ago, retained because nobody had authority to remove them.
The question about who trained you is the second most productive and the least used. Training is where undocumented practice transmits, and asking about it surfaces the layer directly without ever using the word "workaround."
Why coverage determines what you find
Shadow processes are unevenly distributed. They cluster around exception handling, regional variation, and functional boundaries. That has a direct consequence for how discovery has to be run.
A workshop with process owners and senior stakeholders will surface almost none of them, for three reasons. The people in the room describe the intended process. The shadow layer is often handled by people more junior than those invited. And admitting the existence of a workaround in front of a process owner has a social cost.
Coverage across roles, seniority levels, and geographies is what changes the result. The person who has been reconciling two systems by hand for four years is the one who can describe it, and they are rarely in the workshop.
There is also a sequencing point. Shadow processes are easier to surface when the question is framed around difficulty rather than around compliance. Asking what makes the work hard produces honest answers. Asking whether anyone is deviating from the standard process does not.
The country comparison test
For organizations operating in more than one market, one technique is disproportionately effective: run the same discovery in every country and compare.
Divergence is diagnostic. If the same nominal process takes twice as long in one market, the difference is a shadow process, a system gap, or a regulatory requirement the central process never absorbed. All three are worth finding, and none of them is visible from inside a single country.
The comparison also converts a local complaint into a quantified gap. "This is slow here" is an opinion. "This takes two hours here and forty minutes everywhere else" is a finding with an owner and a target.
What to do once you find them
Not every shadow process should be eliminated. Four dispositions cover most cases.
| Disposition | When | Action |
|---|---|---|
| Formalize | The shadow process is better than the official one | Update the documentation and the system to match practice |
| Fix the cause | It exists because of a system gap or policy ambiguity | Remove the reason; the shadow process disappears on its own |
| Absorb | It compensates for a genuine requirement the process should handle | Redesign the official flow to include it |
| Remove | It is a control for a risk that no longer exists | Confirm the risk is gone, then eliminate it with a named owner |
The disposition that causes damage is a fifth one that happens by default: automate the visible process and leave the shadow layer in place. The result is a faster official path feeding the same manual reconciliation, which usually makes the bottleneck worse rather than better.
There is also a sequencing rule inside the dispositions. Fix the cause before you formalize. Formalizing a compensating process without removing what it compensates for institutionalizes the gap, and the documentation now describes a workaround as though it were a design.
Where Horizon fits
Horizon is an AI-powered continuous discovery platform built for the layer described above.
Discovery Cycles run AI-led interviews across an organization, adapting the questions to each role and following up on gaps rather than working from a fixed script. That structure matters for shadow processes specifically, because the layer does not surface from a survey or a fixed questionnaire. It surfaces from follow-up questions about exceptions, artifacts, and pressure.
The Insights Dashboard structures what comes back against processes, systems, and ownership, so a pattern that appears once in one team and again in three others becomes visible as a systemic issue rather than a local complaint. The Process Library extracts the resulting processes into navigable documentation, which is what turns a set of findings into something an operation can maintain.
PedidosYa, Latin America's leading food delivery and quick commerce platform operating across 15 markets, is a clear example of what the layer looks like when it is quantified.
Horizon ran a focused pilot across Rider Payments and Partner Payments with 14+ asynchronous AI interviews over three months, without blocking a single calendar slot. It surfaced 31 actionable findings. Several of them are textbook shadow processes.
Rider wallet adjustments and cash tool failures required 3 to 4 hours per week of manual rework affecting roughly 2,400 riders weekly, caused by recurring retries in a 40-minute window with no automated resolution. Someone was rerunning failed steps by hand, every week, and it appeared in no system.
Manual EDC to SAP reconciliation in Bolivia generated over 1,000 discrepancies per week and consumed about two hours of weekly analysis against roughly 40 minutes in other countries, driven by a visualization error that forced line-by-line Excel comparison. That is the country comparison test producing a finding: same process, one market at three times the effort, cause identified.
Partner billing control required 4 to 5 hours per week cross-referencing SAP, Query and Looker data in Excel with VLOOKUP and verifying in BackOffice, covering 25,000 partners with around 150 weekly discrepancies. Payout reports were extracted manually from BigQuery at roughly 30 hours per month. Payment report downloads from Banesco consumed about 40 hours per month, partly due to download failures.
None of that was in any process document. All of it was load-bearing. PedidosYa has since extended discovery to Tax, Collections and PQP, running it as a continuous program rather than a one-time audit.
That is one engagement under specific conditions rather than a projection for any organization. What generalizes is where the effort was found: in reconciliation, retries, and cross-system comparison that no instrument reading system logs would have recorded.
Shadow process discovery checklist
- Have you included people who handle exceptions, not only process owners?
- Have you covered every region and business unit that runs the process?
- Did you ask about spreadsheets and trackers explicitly?
- Did you ask who people go to when something is stuck?
- Did you ask who trained them and what was not in the documentation?
- Did you ask what the process looked like two years ago?
- Did you frame questions around difficulty rather than compliance?
- Have you compared the same process across markets?
- For each shadow process found, do you know what triggered its creation?
- Do you know how much volume and effort flows through it?
- Do you know what breaks downstream if it stops?
- Have you assigned a disposition: formalize, fix the cause, absorb, or remove?
- Have you checked whether the same pattern exists in other teams?
- Is there an owner for each disposition decision?
Common mistakes
Treating them as a compliance problem. Framing the shadow layer as deviation produces defensiveness and hides the very information you need. It exists because the official path had a gap.
Removing them without fixing the cause. Eliminate the spreadsheet without integrating the systems and a new spreadsheet appears within a quarter.
Formalizing a compensating process. Documenting the workaround without addressing what it compensates for turns a gap into a design.
Assuming process mining will find them. It cannot, by construction. Work outside connected systems produces no event data.
Interviewing only managers. Managers understand the intended process. The shadow layer is usually operated by people further from the org chart.
Automating around them. A faster official path that still feeds a manual reconciliation step moves the bottleneck rather than removing it.
Finding them once. The shadow layer regenerates whenever a system, policy, or team structure changes. A single discovery pass captures a moment.
FAQ
What is a shadow process?
A shadow process is undocumented work that an organization depends on but has never described: a reconciliation spreadsheet, an informal approval, a manual enrichment step, or a regional check that exists outside the standard flow. It is stable and repeated, something downstream depends on it, and no system records it.
How are shadow processes different from workarounds?
A workaround is an individual response to a specific obstacle. A shadow process is a workaround that stabilized into a routine and became load-bearing. The distinguishing test is whether something breaks if the person stops doing it.
Why can't process mining find shadow processes?
Process mining reconstructs workflows from event logs in connected systems. Shadow processes happen in spreadsheets, email, messaging, and human judgment, none of which produce event data in those systems. The gap is a property of the method rather than a limitation of any particular platform.
How do you find shadow processes?
Ask about exceptions, artifacts, dependencies, and pressure rather than about process. Questions like "which spreadsheets does your team maintain," "who do you go to when something is stuck," and "who trained you and what was not written down" surface them. Coverage matters, since they cluster around exception handling and regional variation rather than in the center of the process. Comparing the same process across markets is one of the most efficient detection methods available.
Should shadow processes be eliminated?
Not always. Four dispositions apply: formalize it if it is better than the official process, fix the underlying cause if it compensates for a system gap, absorb it into the redesigned flow if it handles a genuine requirement, or remove it if it is a control for a risk that no longer exists. Eliminating one without addressing why it formed usually produces a replacement.
Map the whole operation, not the documented part
Every large organization runs on more than what is written down. The reconciliation nobody assigned, the approval that happens before the approval, the retry someone performs by hand every week, the check one market added and never removed.
That layer is where a meaningful share of operational cost sits, and it is the layer that determines whether a redesign works. Mapping it is not an audit of discipline. It is the difference between improving the process you have and improving the process you documented.
See it. Fix it. Own it.