The Information Theory of Business - Part 1

Don’t make the workflow faster - Obliterate It!

If your company is doing something with AI this year, there is a fair chance it is this: take a process that already exists and make the steps run without people. Faster ticket routing. Auto-drafted reports. An agent that moves the record from one stage to the next.

This is workflow automation. It keeps every step and changes who performs them. Everything gets faster and nothing in the workflow goes away.

There is a second move available and it is usually the bigger one. Instead of asking who should perform each step, ask why there is a step at all.

Ask it about the processes you run. If you sell software, ask it much harder about the ones you ship, because your product is somebody else’s workflow.

You spend forty pounds on lunch with a client in March (cheap lunch). In April you photograph the receipt, type the amount into an expense claim form, pick a category from a dropdown, write a justification nobody will read, and submit it. Your manager approves it along with nineteen other claims, in about ninety seconds, having read none of them. Someone in finance checks a sample against policy. Six weeks after the lunch, the money arrives in your account.

Software has been improving this for twenty years. The receipt is a photograph now instead of the stapled original. The amount gets read off the image. The approval arrives by email instead of in a tray. The category pre-populates. Every step is faster than it was, and there are exactly as many steps as there were.

Twenty years of improvement, and not one of those improvements asked whether the claim needed to exist.

The two questions

Automation is a real gain and it is where the AI roadmaps I get shown tend to stop. The sequence survives, the handoffs survive, and a machine does what a person used to do, faster and at lower cost. That is worth money.

But it answers only the first question, and the second question is where the value is. Who should perform this step is a staffing question. Why is there a step is a design question, and until recently there was no point asking it, because the answer was always that somebody had to do the work and nobody could do all of it.

None of this is a new observation. Michael Hammer made the argument in Harvard Business Review in 1990, under the title “Reengineering Work: Don’t Automate, Obliterate”. Point computing power at a process as it stands, he wrote, and all you do is encode its assumptions in software. The opportunity is in asking why the process exists at all.

That was thirty-six years ago. We are still automating.

It did not stick the first time because the redesigned process still had to be executed by people following procedure, and people quite reasonably rebuild the coordination they need in order to do their jobs. A checkpoint here, a reconciliation there, and within a few years the process has silted up again. What has changed since is not the insight. It is that an AI enabled system can now hold a whole result in a way a coordinated group of people never could.

Why the steps were there

Take the expense claim apart and ask what each part is for.

The claim exists because the company had no record of the purchase at the time it happened. You knew what you had spent. The company found out weeks later, from you.

The approval exists because nobody could check spending against policy while it was being spent. So the check happened afterwards, by a person, reviewing a form.

The finance sample check exists because checking all of it was impossible. Sampling is what you do when you cannot look at everything.

The reimbursement exists because you spent your own money, which you only did because the company had no way of letting you spend its money safely.

Every one of those answers describes a limitation. Not a policy, not a control, not a decision anybody made about how the business should run. A limitation. The claim, the approval, the sample and the reimbursement are four compensating mechanisms for the same missing capability: the company could not see the transaction as it happened.

That is the shape of a workflow. A result was too big for one person or one system to hold, so it was cut into pieces, and an apparatus was built to carry the pieces between the people holding them. That apparatus is not a design. It is what you build when you cannot do the thing directly.

And notice what happens to it when you automate. The pieces move faster between the same number of hands. The apparatus is cheaper to run and just as large. You have made the compensating mechanism more efficient without touching the thing it was compensating for.

What elimination looks like instead

Put the expense policy on the credit card.

The purchase is inside policy and it completes, or it is outside policy and it declines at the terminal. There is no claim, because the transaction arrives already coded and evidenced. There is no approval, because the approval happened before the money moved instead of three weeks after it. There is no sample check, because everything was checked. There is no reimbursement, because you never spent your own money.

Seven steps become one transaction and a set of rules.

The process did not get faster. It stopped existing.

This is not a thought experiment. Ramp and Brex are American companies that issue corporate cards to businesses and sell the software governing what those cards are allowed to buy. Ramp enforces policy at credit card level, so non-compliant spend declines before it settles rather than getting flagged afterwards. Brex markets the outcome directly, as never having to file another expense report.

I have never used Ramp or Brex and I am not recommending either. I have no relationship with the companies and no view on whether the products are any good. What interests me is the structure of the move, not the service.

Someone looked at a seven-step process, worked out that six of the steps existed only because the company found out about spending too late, and removed the lateness instead of the labour.

Notice who was selling what. That claim form was a product. The submission screen, the approval routing, the policy check: somebody built all of it and sold it. A company built the software that made every one of those steps faster, and left all of them standing. Ramp did not improve a single step. It removed the reason for them.

The move is available in far more processes than it is being attempted in.

Ford did this in 1990

Hammer’s example was Ford, whose accounts payable department employed more than five hundred people. Their job was matching.

Purchasing sent them a copy of the purchase order. Receiving sent a note saying what had turned up on the dock. The supplier sent an invoice. Three documents describing the same delivery, arriving from three directions at three different times, and somebody had to check they agreed with each other. When they did not agree, and often they did not, a clerk stopped and investigated why. That investigation was the job. Five hundred people, largely employed to work out why three pieces of paper about the same lorry did not say the same thing.

Ford’s plan was to put in better systems and cut the department by twenty per cent. Then somebody looked at Mazda, where the same function was being done by five people. Mazda was a smaller company, but after adjusting for that, Ford worked out its department was still about five times bigger than it should be. Twenty per cent was not the gap.

What Ford did instead was stop having invoices.

Purchasing enters the order into a shared database and a copy is not sent to anyone. When the goods arrive, the receiving clerk checks that database: is there an outstanding order matching what is on this lorry? If there is, accept it and enter the receipt, and the system pays the supplier automatically. If there is not, refuse the delivery at the door. Nothing needs reconciling afterwards, because the check happened at the moment the goods arrived, against a record everybody already shares. Headcount in accounts payable fell by seventy-five per cent.

Now read that against the card.

Both processes existed because information about a single event arrived in different places at different times, and a person had to reconcile it after the fact. Both were solved the same way: move the check to the moment of the event, against a record that is already shared, and the reconciliation has nothing left to do. Ford did it in 1990 with a database and a receiving dock. The same structural move is being made now with a credit card and a policy engine.

The steps that have to stay

Not every step is compensating for a limitation. Some steps are there because somebody decided a result should not be produced without evidence, without separation, or without a named human accepting the consequence.

A payment release in a bank requires a second authoriser, and that is not because one person is incapable of pressing the button. It is because one person pressing the button is precisely the risk being managed. A prescription is checked by a pharmacist because the cost of being wrong falls on the patient. A production deployment needs a second reviewer for the same class of reason.

These look identical to the other kind on a process map. Same box, same arrow, same approval field in the system. But removing them removes the entire point.

So the question to ask of any step is what it is for. If the answer describes a limitation, it can probably go. If the answer describes a consequence somebody deliberately chose to guard against, it stays.

The complication is that the first kind learns to talk like the second. An approval that started life as a workaround for missing information picks up the vocabulary of governance, because that is the language that stops people asking about it. Eventually it is in the risk register and nobody remembers it was originally there because the regional office had the only copy of the spreadsheet.

Look at the approval rate.

If the second person approves ninety-nine per cent of what reaches them, they are not exercising control. They are relaying. A control that is never exercised is not a control. Your manager approving nineteen expense claims in ninety seconds is not protecting the company from anything. They are a required step in a process that needed somebody to press a button, and the limitation that put the button there has gone.

Pull the rate on every mandatory second signature in your business. Anything above about ninety-five per cent is a step to interrogate rather than defend. Some of them will turn out to be real controls that are simply well complied with, and you will keep those. The rest are decomposition.

When you remove the decomposition, the control usually gets stronger. In the card example, the audit trail improves. It becomes transaction-level evidence with policy applied at the moment of spend, rather than a number somebody typed off a photograph six weeks later and a manager waved through. The control stopped being buried in seven procedural steps and became visible.

The question

Pick a process in your business. Something unglamorous and recurring, with more than two people in it. The month-end close. Timesheet approval. Purchase requisitions. Onboarding a new starter.

Go step by step and ask what each one is for.

Count how many of the answers are about a limitation rather than a decision. Information that arrived too late. A person who could not see something. A check that had to happen afterwards because it could not happen during. Work that had to be handed on because one pair of hands could not hold it.

Then ask whether that limitation still applies.

Now run it again on something you sell.

If you make software, your product is a workflow somebody else has to operate. Every screen is a step their people work through, and every step was designed around a limitation that applied on the day it was specified. Some of those limitations have since gone. Next year’s roadmap is probably a list of ways to make the remaining steps faster.

Automating the steps of a process is a promise to keep the process. When it is your customer’s process, that is a promise you are making on their behalf, and a competitor with no installed base to protect is under no obligation to keep it.

That is the whole exercise. The value is in the processes you can stop having, and the revenue is in the ones you can stop your customers from having.