The Hidden Work Around Enterprise Systems

The most useful problems in enterprise work are rarely inside the system. They sit in the work people do around it: the spreadsheet that holds what the system does not know, the approval that lives in email, the colleague everyone asks when a case is unusual, the comparison someone runs every morning between two systems that should agree. That work is hidden because no process diagram shows it and no system logs it. It is also where the real decisions often are.

The textbook view of a process is the one in the design document: steps, systems, owners, a happy path and a note about exceptions. After many years inside finance-systems programmes I trust a different picture. Ask the person who runs the process what they did last Tuesday, and you hear about the file they export, the column they add, the person they ring, and the check they run because the last time nobody ran it, something went wrong. That is the work. The diagram is the part of it that was easy to draw.

This piece is a field guide to that hidden work: the forms it takes, how to see it, and what each form is really telling you — whether it wants a rule, an AI assistant, a person, or possibly a product.

Why the work goes hidden

Systems are specified from interviews and requirements, and both describe the process as people intend it to run. Neither captures what people learned to do when it does not run that way. So every implementation ships with a gap between what the system knows and what the work needs, and people close that gap themselves — quietly, competently and without telling anyone, because from where they sit it is just the job.

Over time the gap fills with three things: context the system never held, decisions nobody wrote down, and checks that exist because of an incident someone still remembers. None of it is in the system of record. Most of it is in a spreadsheet, a mailbox or a head.

That is why redesigning a workflow from its documentation reproduces the documented part faithfully and loses the rest. It is also why so many AI pilots look finished long before they are: the model handles the case on the diagram, and the hidden work turns up afterwards as a backlog.

Seven forms hidden work takes

The same handful of patterns turns up in very different processes. Each one has a tell you can look for, and each one is usually doing a specific job.

1. The spreadsheet that compensates for missing context

The tell: a file that is exported, enriched and re-imported, or kept beside the system and consulted before acting. A column added by hand. A tab called "mapping" or "overrides".

What it is really doing: holding information the system needs but does not have — a mapping between two systems' codes, a list of exceptions to a rule, the real owner of an account, a threshold that changed and was never configured. The spreadsheet is a shadow data model. The question is not how to automate the spreadsheet but which of its columns belong in a system, and which system should own that data — a system-of-record map makes that question concrete.

2. The approval that lives in email

The tell: "I just send it to Finance and wait for a yes." A mailbox folder that functions as an audit trail. A reply that says "OK" and nothing else.

What it is really doing: a control. Someone with authority is accepting a risk, and the evidence of that acceptance is a message that nobody can easily find, a year later, when an auditor asks. The redesign is rarely to remove the approval. It is to make it a recorded decision, with the context the approver needs on the same screen and a named person who owns it.

3. The expert everyone asks

The tell: a name that comes up whenever a case is unusual. "Ask Maria, she knows which ones are fine." A process that slows down when one person is on holiday.

What it is really doing: carrying undocumented decision logic. Some of it is genuine judgement that should stay with an expert. Much of it is a small set of rules that were never written down — "these counterparties always pay late at quarter end", "that code means the bank netted two items". Separating the two is the work. The rules can be written down and run by a system; the judgement can be supported by giving the expert the evidence in one place instead of five.

4. Context rebuilt from several places

The tell: before acting, someone opens three systems, a shared drive and their own notes. The task itself takes a minute; assembling enough context to do it safely takes twenty.

What it is really doing: reconstructing the state of a case that no single system holds. This is the form of hidden work AI is genuinely good at helping with — reading, gathering and summarising evidence from several sources so a person can decide faster. It is also the form most likely to be underestimated, because the visible step, the click at the end, looks trivial.

5. The manual reconciliation between systems

The tell: a daily or monthly comparison of two lists that ought to agree, followed by an investigation of the differences. The bank reconciliation teardown is the canonical example.

What it is really doing: two jobs at once. The matching is usually a rule — exact or tolerance-based — and belongs in software. The investigation of what does not match is where the effort sits, and it is a mix of evidence gathering, which AI can assist, and decisions about what to do, which stay with a person. Treating the whole thing as "automate the reconciliation" misses that the residue is the real work.

6. The exception that happens every week

The tell: an "exception" that has its own spreadsheet, its own recurring meeting or its own person. Anything that happens on a schedule is not exceptional.

What it is really doing: running a second process that the first one pretends does not exist. It usually needs its own design — detection, a queue, an owner, an age, a resolution that is recorded — rather than being handled as noise around the main flow.

7. The workaround that became part of the operating model

The tell: a step that exists "because the system can't". A manual upload, a renamed file, a re-keyed field, a macro someone wrote years ago that now runs every day.

What it is really doing: carrying a decision or a requirement the system never learned. Workarounds are the most honest documentation an organisation has, because nobody builds one for a problem that is not real. The question to ask of each is whether it would disappear if the system were configured properly, or whether it reflects a need the system was never designed to meet.

How to see it

Hidden work does not show up when you ask how a process works. It shows up when you ask about the days it did not.

• Ask about the bad day. What happens when the numbers do not match? When the file does not arrive? When the amount is larger than usual? The answers describe the hidden work in the order it is used.
• Ask who people go to. Every name that comes up is a store of undocumented logic.
• Ask what they check before they press the button. Every check is either a control or the residue of an incident, and both matter.
• Look at the artefacts, not the diagram. Shared spreadsheets, mailbox folders, recurring meetings, personal notes, and macros on someone's desktop. Each is a place where the system stopped and a person carried on.
• Follow one real case end to end. Not a typical one — a recent awkward one. The path it actually took is the process.

Write what you find down in plain terms: who does what, in which system, in what order, and what happens when something does not match. That description is the raw material for everything that follows. It is also exactly what Workflow X-Ray is built to read.

What each kind of hidden work is telling you

Once the hidden work is visible, it sorts into four destinations. Getting the sorting right matters more than any technology choice, because the most common mistake is to send work to the wrong one.

The first row is the one most often skipped. A surprising amount of hidden work is a rule that was never configured, and the honest answer is boring: write the rule down and put it in the system. No model required. What stays deterministic should be decided before anyone asks what AI can do.

The third row is the one most often violated. An approval in email looks like friction, and removing it looks like efficiency. But the approval exists because someone has to own the consequence. The improvement is to give that person the evidence and record the decision, not to take the decision away.

When a workaround is a product signal

Some hidden work is specific to one organisation: a quirk of its configuration, a legacy decision, a team that never got the training. Fixing it is valuable, but it is not a product.

Other hidden work recurs. The same spreadsheet, rebuilt independently, in every company that runs the same kind of process. The same manual reconciliation between the same two kinds of system. The same expert-shaped bottleneck at the same step. When a workaround survives outside the organisation that built it, it may be pointing at a product nobody has made well yet.

The discipline is to treat that as a hypothesis, not a discovery. One workflow cannot tell you how common the problem is, who would pay to have it solved, or whether the people who feel the pain are the people who buy software. What it can give you is a precise description of the pain and the workaround it produced — which is the right starting point for a small test before anything is built. I run every idea through the same short filter before writing code, and most do not survive it. That is the filter doing its job.

Start with one workflow

The fastest way to see hidden work is to write down one process you know well, in plain language, including the awkward parts you would normally leave out — the spreadsheet, the email, the person you ask, the check you always run. Then read it back as an outsider would and mark each place where a person is carrying something the system does not.

Workflow X-Ray does that reading for you: paste the description and it separates the visible steps from the decisions, context gaps, manual work and handoffs underneath, sorts the work into rules, AI assistance and human judgement, and flags anything that looks like a product signal — with what is still unknown about each. It is free, needs no signup, and the site stores nothing you paste. If you would rather score a whole portfolio of processes first, how to find workflows worth redesigning covers that step.