Design the work before you divide it

Suppose you have done the hard part. You have stopped looking for AI use cases and investigated a process properly. You have spoken to the people who know the work, followed how information moves, identified where work waits, understood who makes decisions and where approvals happen, and discovered what goes wrong and where people compensate for weaknesses in the process.

What do you do next?

The tempting answer is to look at the process you have discovered and ask which parts can be automated. Increasingly, that becomes a question about which parts AI could do. It sounds entirely reasonable, but I think it risks making a mistake at precisely the point where the most important design decisions need to be made.

Understanding how work happens is essential, but the process we discover should not automatically become the specification for the process we build. The existing process is evidence about how an organisation produces an outcome today. It reveals knowledge, dependencies, decisions, exceptions and the sometimes invisible work that keeps everything functioning, but it also contains history: activities that made sense when systems were different, approvals introduced because something once went wrong, spreadsheets created to bridge gaps between systems, and checks added on top of other checks.

If we simply ask which of those activities AI can perform, we risk building a faster version of a process we should have challenged more fundamentally.

Before deciding who — or what — should do the work, we first need to decide what work actually needs doing.

The process you found is not necessarily the process you need

Imagine a manufacturer preparing quotations for customers. An enquiry arrives by email and someone works out what the customer requires. Information is transferred into another system, product details are found, technical colleagues may be consulted, prices are retrieved and calculations performed. Production might be asked about capacity or delivery. Someone prepares the quotation, somebody else checks it and perhaps a commercial manager approves it before it finally goes back to the customer.

Once that process is mapped, the opportunities for automation quickly become apparent. AI could read the email and extract the requirements. Automation could transfer the information. AI could find relevant product information and prepare the quotation. Software could calculate the price, another workflow could send the result for approval and, eventually, an agent might send the finished quotation to the customer.

Every one of those ideas could be useful. The problem is that we have accepted the architecture of the existing process before deciding whether it is the architecture we actually want.

Put the process map to one side for a moment and ask what the process is there to achieve. The customer does not want a successfully completed quotation process. They want an accurate, commercially acceptable and deliverable offer within an appropriate period.

That gives us a different starting point. What must be true for that outcome to be good enough? Have we understood what the customer requires? Is what we are offering technically appropriate? Is the price correct? Can we supply it when we say we can? Are the commercial terms acceptable? Is what we communicate clear and accurate?

Only then should we return to the process we discovered and ask which parts of it are actually necessary.

Work out what is actually necessary

One reason organisational processes become complicated is that necessary information and necessary activity are easily confused. A quotation might genuinely require information about the customer, product, quantity, specification, price, margin, availability and delivery requirement. That does not mean the organisation genuinely requires all the activities currently used to assemble that information.

Somebody may enter the same information twice because two systems do not communicate. An email may be sent to Production because capacity information is not visible elsewhere. A spreadsheet may exist because pricing information is difficult to retrieve. A manager may check every quotation because the organisation has never established which quotations actually present commercial risk.

Each of those activities may have a perfectly sensible explanation, which is why understanding the real work has to come first. You cannot intelligently remove an activity until you understand what it contributes, and sometimes what looks like inefficiency is actually somebody quietly keeping the process functioning. People provide resilience as well as labour: they notice something odd, connect information the formal process does not recognise, and recover situations nobody anticipated when the procedure was written.

Understanding that contribution matters. But understanding an activity and preserving it are different things.

The design conversation therefore needs to ask what information, activity, judgement and assurance are genuinely necessary to produce the required outcome to the required standard. That is a rather different conversation from asking which boxes on a process map can be automated.

A task is often only a container

This becomes particularly important when we encounter activities that appear to require experienced people. Suppose the process map contains a box labelled Commercial manager checks quotation. It is tempting to treat that as one indivisible task: either the manager does it or, perhaps eventually, AI does it.

But what does “checks quotation” actually mean?

The manager might be checking that the arithmetic is correct, interpreting an unusual customer requirement, deciding whether a proposed discount is commercially acceptable or assessing whether a delivery commitment is credible. They might also be checking it simply because quotations have always been checked before they leave the business.

Those are not the same kind of work.

Tasks are convenient descriptions of how work has been organised, but they are not necessarily useful units for deciding how work should be organised next. Before we decide who or what should perform a task, it is often necessary to decompose it and understand the work inside it.

One useful way of doing that is to distinguish between rules, interpretation and judgement.

Some work is principally rule-based. If the necessary information is available and the result follows reliably from explicit rules or calculations, ordinary software or conventional automation may be the best solution. There is little value in introducing a large language model to multiply quantity by unit price or compare a number with an agreed threshold.

Other work requires interpretation. The required meaning may be reasonably well defined, but the information does not arrive in a consistent form. A customer might write, “Can you supply another 40 of those sockets we used on the Leeds job?” A person may understand immediately what they mean by looking at the customer history and previous order, whereas traditional workflow automation may struggle because the input does not correspond neatly to a predefined field or rule.

Then there is genuine judgement. If the customer wants a non-standard configuration and somebody needs to decide whether a proposed substitution is technically acceptable, the answer may depend on incomplete evidence, experience, context, consequences and competing considerations.

These are not mutually exclusive categories. A single task may contain all three, which is precisely why decomposing the work matters.

Variation is not necessarily judgement

This distinction has become much more important with generative AI because organisations often describe work as requiring an experienced person simply because every case is different.

Suppose Dave has dealt with a particular type of customer enquiry for 15 years. Customers describe what they want in different ways, use informal terminology, leave information out, refer to previous orders and assume knowledge that is never written down. Dave is extremely good at making sense of all this, and we might reasonably describe what he does as judgement.

Some of it may be. But some of Dave’s value may come from being able to interpret highly variable information and translate it into something the organisation can process.

Generative AI makes that distinction commercially important because variable, naturally expressed information can increasingly be interpreted computationally. That does not mean that because AI can understand what the customer means, it should also decide what the organisation ought to do about it. Interpretation is not the same as judgement, and judgement is not the same as authority to act.

This matters because some of the assumptions on which today’s division of labour was built are becoming obsolete.

AI changes the design space

Many organisational processes were designed around technological constraints that no longer necessarily hold. Work was routed to people not always because it required uniquely human judgement, but because somebody had to make sense of information that arrived in inconsistent, incomplete or unstructured forms.

Generative AI does not remove the need for judgement, but it makes the distinction between interpretation and judgement newly important. If that technological boundary has moved, the sensible response is not simply to automate more of the existing process. It is to reconsider how the work should be organised.

None of this means that AI has invented process improvement. It has not. Designing around outcomes, removing unnecessary work, considering technical and organisational systems together, and challenging the automation of poor processes all have long histories in Lean thinking, business process redesign, sociotechnical systems and human factors. Those foundations remain useful precisely because AI does not make them obsolete.

What AI changes is what becomes possible once those principles have been applied.

For many years there has been a practical boundary in organisational automation. Structured and predictable work could be handled relatively easily by software, while information that became variable, ambiguous or difficult to encode into rules often returned to a person. That boundary was never absolute — machine learning, decision systems and other approaches have dealt with uncertainty and variation for many years — but generative AI substantially changes the economics of dealing with some forms of unstructured information, particularly language.

Emails, documents, customer requests, notes, instructions, specifications and descriptions of problems are the material from which much everyday organisational work is constructed. A great deal of that work is held together by people interpreting those things.

AI therefore expands the design space. It does not tell us what the design should be.

Now divide the work

Only after the process has been stripped back to what is genuinely necessary does it make sense to decide how the work should be divided.

Our redesigned quotation process might use conventional software to retrieve prices and perform calculations, while AI interprets an incoming customer enquiry and extracts the information needed to progress it. A technical specialist might make a judgement about an unusual configuration, AI might prepare the quotation using information established elsewhere in the process, and a commercial manager might become involved only where a quotation contains an exceptional commitment. Automation could move information between stages and communicate a standard quotation to the customer.

Real processes will rarely divide this neatly. The purpose of distinguishing rules, interpretation and judgement is not to classify every activity permanently, but to expose what capabilities the work requires so that better design decisions can be made.

The important point is that we have not simply divided the activities in the old process between a new collection of workers. We have first decided what work needs to exist and then designed the division of labour around that.

Don’t allocate yesterday’s tasks between tomorrow’s workers.

Human involvement needs a reason too

Discussions about AI frequently refer to keeping a human in the loop, and sometimes that is exactly the right design. But the presence of a person should not become a substitute for understanding what assurance the process actually needs.

Return to the commercial manager who checks every quotation and ask what that check protects the organisation against. If the answer is incorrect arithmetic, a deterministic control may provide stronger assurance than a busy manager scanning the document. If the manager is ensuring discounts remain within agreed limits, that too might be controlled explicitly. If they are assessing unusual commercial risk, however, their judgement may be genuinely important.

They may also be noticing unexpected things that nobody designed into the formal process. If so, we need to understand that contribution before removing it.

The objective is not to remove the manager. It is to understand what the manager contributes.

The same challenge should apply to AI, conventional automation and people. Each should earn its place by contributing something necessary to the outcome, resilience or assurance of the process.

Ultimately, the organisation decides what level of change and risk it is comfortable with, but that decision does not have to be based entirely on opinion. It can be tested.

The redesigned process is a hypothesis

A process can look convincing on a whiteboard and still fail when it encounters reality, which is why I prefer to think of a redesigned process as a hypothesis.

Suppose we believe that standard quotations no longer require commercial-manager approval. Rather than arguing about it indefinitely, we can design a pilot. Keep the approval temporarily, but record what happens. How often does the manager change the quotation? What do they change? Why? What would have happened if they had not intervened? Are particular kinds of quotation responsible for most interventions?

The evidence may show that the approval is essential or that it is unnecessary. More interestingly, it may show that approval is valuable only for particular kinds of exception, in which case we have learnt something useful about how the process should actually be designed.

The pilot is therefore more than a cautious implementation technique. It is a deliberate mechanism for learning whether the redesigned process behaves as expected and for generating evidence for the next decision.

Trust should be earned through evidence

This is particularly important with AI, where implementation is too often framed as a choice between two extremes: AI is unreliable so a person must check everything, or the demonstration worked so we should automate it.

A better question is what evidence would make us comfortable changing the level of control.

An organisation might initially verify every output and, as evidence accumulates, decide that some classes of work need only sample checking. Others may need intervention when specified exceptions occur, while some may continue to require human judgement indefinitely. There is no universal progression because the consequences of failure matter.

Evidence also has boundaries. A system that has performed well on hundreds of standard quotations has generated useful evidence about standard quotations. It has not necessarily demonstrated that it should autonomously handle a novel, high-value or highly unusual case.

Trust, therefore, should not mean a vague belief that “the AI works”. What we need is justified confidence that the redesigned process performs acceptably within understood conditions, and that confidence should be earned through evidence rather than assumed at the point of design.

A process improvement that used AI

This distinction between redesigning work and automating existing tasks is not theoretical for me.

In one process-improvement engagement, an organisation recorded approximately four hours of actual processing time in an order-preparation process, but that work was spread across a lead time of around eight days. The problem was not that people were spending eight days performing the work. Much of the elapsed time came from the process moving through queues in different departments while materials were located and production was scheduled.

The resulting intervention was not an AI replacement for the eight-day process. We simplified the work, introduced a small amount of conventional process automation and used generative AI for a particular part of the process where qualitative instructions needed to be interpreted.

The redesigned process required around 20 minutes of processing within an elapsed lead time of approximately four hours. Those timings were recorded during the work.

The interesting result is not simply the reduction in time, considerable though it was. No single technology produced it. AI became useful as one component of a redesigned process after we understood where the delays came from and challenged what work was actually necessary.

Had we started by asking which activities AI could automate, we might simply have produced a more efficient version of the wrong process.

Six questions for redesigning the work

For a manager looking at a troublesome process, I would start with six questions.

What outcome are we trying to produce? Be clear about what the recipient of the process actually needs.

What must be true for that outcome to be good enough, and what happens if it isn’t? The required standard and the consequences of failure should shape the design.

What information, activity and judgement are genuinely necessary? Challenge what has accumulated around the work without assuming that everything currently present is waste.

Which parts are governed by rules, which require interpretation, and which require genuine judgement? In particular, do not confuse variable information with human judgement.

What is the simplest reliable combination of people, conventional systems and AI capable of doing the work and providing the assurance we need? Start with the work rather than the technology.

What evidence would convince us that the redesigned process works? Design the pilot at the same time as the process.

These questions will not produce a perfect process automatically, nor are they intended to. Their purpose is to improve the conversation, because the quality of that conversation determines what an organisation sees as possible.

Can it? is different from may it?

There is one further question as AI systems become more capable.

Suppose an AI system can understand a customer’s requirement, establish the standard price, prepare the quotation and send it. That demonstrates capability, but it does not establish authority. The organisation still needs to decide what the system is permitted to do on its behalf.

An AI system may be capable of issuing a quotation. That does not tell us whether it should be permitted to commit a price, discount or delivery date.

Can it? is different from may it?

Once systems begin acting with meaningful discretion on behalf of the organisation, we have moved beyond process design into the management of artificial agency. That is another management problem, but it is one we should only need to solve after establishing that the agency is useful in the first place.

Design the work first

There is a great deal of understandable excitement about what AI can now do, but capability is a poor starting point for organisational design.

First understand the work. Learn from the people who actually do it and find the delays, decisions, exceptions, workarounds and invisible contributions that make the process function.

Then design the work. Define the outcome, establish what good needs to look like, and strip the process back to the information, activity, interpretation, judgement and assurance genuinely necessary to achieve it.

Only then decide where people belong, where conventional automation belongs and where AI belongs. Where AI begins to act with meaningful discretion on behalf of the organisation, we can then ask how that artificial agency should be authorised, controlled and managed.

The purpose is not to find work for AI. It is to design better work.

Don’t decide who should do the work until you’ve decided what work needs doing.

Further reading and intellectual foundations

The argument developed here draws together several established areas of research and practice. Lean thinking and business process redesign both challenge organisations to focus on value and redesign work rather than simply automate existing activity. Sociotechnical systems research emphasises the joint design of social and technical systems, while human-factors research has long examined how functions should be allocated between people and automation. Contemporary generative AI changes the practical design space by making some forms of variable, unstructured information more computationally tractable, but it does not remove the need for these established principles.

• Hammer, M. (1990), “Reengineering Work: Don’t Automate, Obliterate”, Harvard Business Review, 68(4), 104-112.
• Clegg, C. W. (2000), “Sociotechnical Principles for System Design”, Applied Ergonomics, 31(5), 463-477. DOI: 10.1016/S0003-6870(00)00009-0.
• Parasuraman, R., Sheridan, T. B. and Wickens, C. D. (2000), “A Model for Types and Levels of Human Interaction with Automation”, IEEE Transactions on Systems, Man, and Cybernetics - Part A: Systems and Humans, 30(3), 286-297. DOI: 10.1109/3468.844354.
• Bainbridge, L. (1983), “Ironies of Automation”, Automatica, 19(6), 775-779. DOI: 10.1016/0005-1098(83)90046-8.