The process map is not the work

Most organisations have some idea of how their important processes operate. An enquiry arrives, somebody prepares a quotation, an order is placed, the order moves into production, the product is dispatched and eventually the customer is invoiced. It may be formally documented in a process map or procedure, represented by the stages in a business system, or simply understood by the people who manage the organisation. However it is represented, it gives us a useful model of how work moves through the business and how one activity relates to another.

There is considerable value in having this view. The difficulty comes when we begin to treat the representation of the process as if it were the work itself.

Consider something as ordinary as processing a customer order. The process may say that the order is received, checked, entered into the system and released. Sit with the person who actually does the work, however, and a rather different picture can begin to emerge. Before entering the order, they check something against an email because experience has taught them that the information in the system is not always reliable. One particular customer needs to be treated differently, although this is not documented anywhere. A delivery date has to be confirmed with Production because the date shown in the system cannot always be trusted. There is a spreadsheet on somebody’s desktop containing information that does not exist anywhere else. An unusual order is passed to an experienced colleague because, as everybody in the office knows, “she knows how these ones work”.

Eventually the order is processed correctly. The customer receives what they ordered and, from the organisation’s perspective, the process has worked. Yet I think this creates an interesting question: did the process work, or did the people make it work?

That distinction matters because the two can look exactly the same from a management perspective. If orders are being shipped, invoices are being raised and customers are being answered, it is perfectly reasonable to conclude that the processes producing those outcomes are functioning. There may be occasional exceptions, of course, but good people deal with exceptions. That is part of what we employ them to do. The problem is that the effort involved in dealing with those exceptions can gradually become part of the normal work. Once that happens, a successful outcome may tell us surprisingly little about the effectiveness of the process that produced it.

The work required to produce the outcome

This is not an argument that process maps are wrong. A process map is necessarily a representation. It simplifies what happens so that we can understand, communicate and manage it. A map containing every conversation, decision, exception, interruption and piece of human judgement would quickly stop being useful as a map. The problem is therefore not abstraction itself. It is forgetting what has been abstracted away and, in particular, assuming that the things we cannot see are unimportant.

There is a long history of thinking about this problem. Lean practice places considerable emphasis on going to where work happens and understanding the current state rather than relying solely on an account of how it is supposed to happen. In resilience engineering, Erik Hollnagel and others distinguish between work-as-imagined and work-as-done, recognising that the conditions under which people actually work inevitably differ from simplified descriptions of how work is expected to happen. Martha Feldman and Brian Pentland make a related distinction in their work on organisational routines, showing that a routine as an abstract idea is not the same thing as its performance by particular people in particular circumstances. Research into invisible and articulation work, associated particularly with Susan Leigh Star and Anselm Strauss, has also shown how much coordination and additional activity can disappear from formal representations of work.

More recent research into digitalised organisations has continued this line of thinking by examining the compensating work people undertake when technologies and formal arrangements do not quite meet the requirements of the work. The terminology varies, but the underlying point is well established: what an organisation says happens and what people actually have to do are not necessarily the same thing.

For me, the interesting management question is not simply whether there is a difference between the two. We should expect there to be some difference. Real organisations contain variation, incomplete information, unusual customers, unreliable suppliers, changing priorities and circumstances that no procedure can anticipate perfectly. The more useful question is what is happening inside that difference, and whether some of the work that people have learned to perform is telling us something important about the way the organisation operates.

This is where I repeatedly see checking, chasing, correcting, reconciling and remembering becoming part of everyday work. Someone checks information because they have learned not to trust it. Someone chases a colleague because the formal process does not provide the information when it is needed. Someone maintains a separate spreadsheet because the principal system does not contain quite what is required. Someone knows that a particular customer has to be handled differently, even though nothing in the documented process explains why. Someone else has simply learned that, before pressing the button, it is wise to have a quick look at something because occasionally it does not look right.

Individually, none of these activities necessarily appears significant. Indeed, the people doing them may not regard them as problems at all. They are simply part of getting the job done.

When the workaround becomes the work

This creates a particular difficulty for management because the people closest to the work may no longer describe these activities as exceptions. Ask somebody whether there are any problems with a process and they may quite reasonably say that there are not. Ask them instead to show you how they completed a particular piece of work and you can receive a very different answer. They open another system to check a figure because “that is sometimes wrong”. They send somebody in Production a message because they need to make sure a date is still right. They open a spreadsheet stored separately from the main system because “it has the information we actually need”. An unusual customer appears and the response is immediate: “Ask Julie. She knows what to do with those.”

What interests me about these examples is not simply that people are deviating from a formal process. In many cases, they are doing exactly the right thing. They have encountered some limitation in the system of work and developed an effective way of dealing with it. The customer still receives the product, the invoice is still correct and the management report still appears when it should.

Over time, however, the history of why that additional activity became necessary can disappear. A problem occurred, somebody found a solution, the solution worked and so it was used again. Eventually the solution became normal practice. New employees may even learn the workaround as part of learning the job, without ever knowing why the workaround exists in the first place. At that point, the workaround has become the work.

There is a slightly uncomfortable consequence of this. The more capable employees become at compensating for weaknesses in the underlying process, the less visible those weaknesses can become to the organisation. Problems are corrected before they reach the customer. Missing information is found before it causes a delay. Experienced staff recognise situations that need special handling. The organisation sees the successful outcome, while much of the activity required to protect that outcome remains below the surface.

In that sense, competent employees can make poor systems look better than they really are. This is not a criticism of the employees; quite the opposite. They are often demonstrating exactly the initiative, judgement and commitment that organisations say they value. The management problem is that their success can conceal the conditions that make such compensation necessary.

Three effects worth looking for

It would be misleading to suggest that every workaround deserves management attention. Organisations need people who can deal sensibly with variation without turning every unusual event into a process-improvement exercise. A five-minute activity that occurs twice a year may be entirely inconsequential, and attempting to eliminate it could easily consume more effort than simply continuing to do it.

In working with organisations, however, I have found it useful to examine compensating work through three related effects: accumulation, dependency and distortion. They are not intended as another process-improvement methodology. They are simply three ways of asking whether apparently ordinary activity may be telling us something that deserves closer attention.

Accumulation occurs when individually insignificant activity becomes organisationally significant through repetition. Suppose somebody spends five minutes checking information before processing an order. Five minutes hardly seems worth worrying about. But if the same check happens 15 times each day across five employees, then across 230 working days the organisation is spending more than 1,400 hours performing what still feels, each time it happens, like “a quick check”.

This does not mean that the organisation has suddenly discovered 1,400 hours of savings. The check may be necessary, and removing it without understanding why it exists could simply create errors elsewhere. What the calculation does is change our unit of analysis. Instead of asking whether five minutes matters, we start asking how often the activity occurs, how widely it is distributed and why the organisation needs to perform it at all. Something that is trivial at transaction level can become significant at organisational level.

Dependency occurs when successful operation relies upon people, knowledge or informal arrangements that are largely absent from the formal process. Consider again the familiar instruction to “ask Julie”. Julie may know which customers require special treatment, which information in the system can be trusted, what to do when a particular error occurs, who needs contacting and which apparently standard cases are not standard at all. There is nothing wrong with this expertise. Organisations depend upon people developing knowledge and judgement, and attempting to reduce every form of expertise to a written procedure would be both unrealistic and undesirable.

The important question is whether the organisation understands what it depends upon. If successful completion of the work relies upon knowledge that exists primarily in one person’s head, then part of what we thought was the process actually resides in that person. This becomes important when Julie is on holiday, when somebody new joins, when the organisation grows, or when Julie eventually leaves. The issue is not simply one of efficiency; it is also one of resilience, continuity and organisational knowledge.

Distortion occurs when successful compensation causes management to overestimate the effectiveness of the underlying process. Imagine that a monthly management report arrives on time every month. The figures are accurate, the presentation is professional and management uses the report to make decisions. From management’s perspective, there is little reason to question the reporting process because it reliably produces the required outcome.

Now sit alongside the person who produces it. Information is exported from one system. Another spreadsheet arrives by email. Customer names do not quite match, so they have to be corrected. Duplicate records are removed. Three transactions look unusual and require a conversation with Finance. Figures are copied into the reporting workbook, a formula that somebody has overwritten needs repairing, the totals are checked and finally the report is generated.

At 9am on Monday, management receives an accurate report. The visible process has succeeded, but the successful outcome conceals much of what was required to produce it. Management sees “report required, report delivered”. The person doing the work experiences reconciliation, correction, chasing, judgement and checking before the report can be delivered.

This is why one of the questions I increasingly find useful is: what would stop working if people stopped quietly fixing things? It forces us to look beyond the successful outcome and consider what the organisation is actually relying upon to produce it.

Not all difference is waste

There is an important qualification to all of this. Once we start looking for activity outside the formal process, it would be easy to treat every difference as waste and every workaround as something to eliminate. I do not think that is the right objective.

Real work varies because reality varies. Customers have different needs, suppliers fail, information is incomplete, priorities change and unusual situations occur. Experienced people notice things that a formal system cannot easily represent, and they make judgements based on knowledge accumulated over time. That capacity to adapt can be extremely valuable, particularly in organisations where customer requirements or operating conditions cannot be reduced to a completely predictable sequence.

It is therefore useful to distinguish between different kinds of activity. Some work creates necessary value directly. Some represents necessary adaptation: the flexibility and judgement required to deal with legitimate variation. Other activity exists because people are compensating for avoidable problems elsewhere in the system. The challenge is not to eliminate variation but to understand which of these we are looking at.

Suppose customer-service staff telephone Production every afternoon because they do not trust the delivery dates shown in the system. Stopping the telephone calls would be an easy process change, but it would not necessarily be an improvement. Perhaps Production is not updating the data. Perhaps the system displays a date that means something different to different functions. Perhaps the production-planning process itself creates uncertainty. Or perhaps there is genuine uncertainty that cannot sensibly be represented by a single date, and the conversation between experienced colleagues contains valuable judgement about what to tell the customer.

Until we understand why the telephone call exists, we do not know which of these explanations is correct. The workaround is therefore evidence to investigate, rather than evidence of waste in itself. This leads to a principle that I think is important: do not remove the compensation until you understand what it is compensating for.

Why this matters when we automate

The same problem becomes particularly important when organisations start thinking about automation and AI, because technology encourages us to formalise work. We identify a sequence of activities, decide which can be automated and then design a system to perform them more quickly or with less human intervention.

Imagine that the documented process for approving an order is straightforward: the order is received, a credit check takes place, a manager approves it and the order is released. On paper, this looks like an obvious candidate for workflow automation.

Follow some real orders, however, and the picture may be different. Before the credit check takes place, the administrator notices missing information and corrects a customer record. The payment terms look unusual, so they contact the account manager, who provides some context that is not recorded anywhere in the system. The record is updated, the credit check takes place and the manager approves the order. Before releasing it, an experienced administrator performs a final check because experience has taught them that particular combinations of information occasionally indicate a problem.

None of this means the process cannot or should not be automated. It means we now understand the problem differently. Automating the four visible stages on the process map does not automatically remove the surrounding work, and some of that apparently informal activity may contain precisely the judgement that allows the process to operate safely.

Digital tools can help us discover some of this. Process mining can reveal how transactions actually move through systems, while task mining and AI can expose recurring patterns, delays and exceptions. But digital evidence can only reveal what leaves a trace that we can interpret. A telephone conversation, a spreadsheet outside the principal system, an informal message to a colleague, or the experienced employee who notices that something “doesn’t look right” may all be part of the process without appearing clearly in the event log. Understanding work therefore means combining what our systems can tell us with what the people performing the work know and do.

This connects with a wider argument I have made about using AI on the business, rather than thinking only about AI in the business. The obvious technology question is whether AI can perform a particular task or automate a particular process. I think there is a more useful question that should come first: do we understand the work well enough to know what should be improved?

Once we understand the work, AI may indeed be the answer. So might conventional automation. Two systems may need connecting, information may need to be captured differently, responsibility may need clarifying, or a process may need redesigning before any technology is introduced. Sometimes the most useful intervention is surprisingly mundane: remove an unnecessary approval, change who receives a piece of information, improve a form, standardise a field or simply stop doing something that no longer serves a useful purpose.

Starting with the work rather than the technology gives us a better chance of solving the right problem.

Start with one real piece of work

None of this requires an organisation-wide process-improvement programme. In fact, I think there is value in starting much smaller.

Choose one recurring piece of work that matters to the organisation. It might be processing an order, producing a quotation, responding to a customer enquiry, scheduling production, raising an invoice or producing a management report. Then take one or two real examples and follow them through from beginning to end.

Rather than asking somebody to explain how the process normally works, ask them to show you what happened with that particular piece of work. Where did the information come from? What did they check? What did they have to chase? What did they correct? Where did they use judgement? What did they know that was not written down? What happened when the standard route did not quite fit?

The difference between these two approaches is important. “How does this process work?” encourages us towards the generalised account of the process. “Show me what happened with this one” keeps us anchored in what actually occurred. Once we understand several real examples, we can begin to distinguish between an unusual event and a recurring pattern.

At this stage, I would resist the temptation to suggest improvements too quickly. First establish what the work actually requires and why. Then ask whether anything we have observed matters through accumulation, dependency or distortion. Only then should we decide what, if anything, ought to change.

Making improvement part of management

There is a wider point here about how organisations are managed. We need employees who solve problems. If a customer needs something urgently, a system fails, information is missing or something unexpected happens, we want capable people to respond rather than wait for somebody to redesign the process.

But solving an immediate problem and learning from that problem are different activities.

“There is sometimes an issue with those orders, but Julie knows how to sort them” is reassuring at one level. The customer is being looked after and the work gets done. Yet I think management should hear another set of questions inside that statement. What does Julie know that the organisation does not? Why does she need to know it? How frequently does the issue arise? What would happen without her intervention? Is this useful expertise that we need to preserve, or is Julie repeatedly compensating for something that the organisation could reasonably improve?

If the only requirement placed on people is to keep work moving, capable employees will continue to compensate for whatever problems they encounter. The organisation benefits from their ingenuity, but the circumstances requiring that ingenuity can remain largely unchanged. Over time, those compensating activities become part of the job and the organisation can lose sight of the fact that there was ever another way of doing it.

This is not something I think can be solved simply by introducing a periodic process review. It is partly a question of management culture. People need to know that identifying recurring friction is not complaining, and that questioning why work is done in a particular way is part of improving the organisation rather than a criticism of the people who designed or manage it. Managers, in turn, need to show enough curiosity about how work is actually performed that employees have a reason to surface the things they routinely correct, compensate for and work around.

That changes the relationship between problem solving and improvement. We still want somebody to solve today’s customer problem. But if the same problem occurs tomorrow, next week and next month, the organisation should have some means of learning from it. The question moves from “Did we sort it?” to “Why did we have to sort it, and is there something here we should change?”

This does not mean turning every exception into an improvement project. It means creating enough awareness of how work actually happens that recurring problems do not disappear simply because good people have become very effective at living with them. Good employees solve problems. Good management also creates the conditions in which the organisation can learn why those problems needed solving.

This is ultimately why I think the distinction between the process and the work matters. A process map gives us a valuable representation of how an organisation expects work to happen. It can help us communicate, standardise, analyse and improve. But it remains a representation. The organisation itself is a much richer system of people, information, decisions, technology, judgement and informal coordination.

The process map is useful precisely because it simplifies that complexity. We just need to remember that the complexity has not disappeared.

Before deciding what to improve, automate or augment, I think there is therefore a simple question worth asking:

What are our people actually having to do to make this work?

The answer may tell us rather more about how the organisation really operates than the process map alone ever could.

References

Feldman, M. S. and Pentland, B. T. (2003). Reconceptualizing Organizational Routines as a Source of Flexibility and Change. Administrative Science Quarterly, 48(1), 94–118.

Hollnagel, E. (2017). Why is Work-as-Imagined Different from Work-as-Done? In R. L. Wears, E. Hollnagel and J. Braithwaite (eds.), Resilient Health Care, Volume 2: The Resilience of Everyday Clinical Work. Routledge.

Justesen, L. and Plesner, U. (2024). Invisible Digi-Work: Compensating, Connecting, and Cleaning in Digitalized Organizations. Big Data & Society.

Star, S. L. and Strauss, A. (1999). Layers of Silence, Arenas of Voice: The Ecology of Visible and Invisible Work. Computer Supported Cooperative Work, 8, 9–30.