When AI Does the Work

Once AI starts doing the work in a company, you begin to notice the process around it. Why does this person have to approve that? Why do these two systems need to be reconciled? Why is someone copying information from one system to another? Why does this report exist?

These questions were always there. They just weren’t very interesting while people did the work, because then we focused on how the work got done. That is also where most companies start with AI: where can we use it? Someone answers customer emails. Someone reviews invoices. Someone prepares reports. Someone writes code. Someone reconciles transactions. Someone follows up with vendors.

AI can usually do some of it. If someone can process 100 invoices a day, perhaps AI can process 10,000. If a support agent can handle 50 conversations, perhaps AI can handle 500. If an engineer spends half the day writing routine code, perhaps AI can take over much of it.

There is plenty of value in that. But the questions about the process go further than speed.

The documents are not the business

Take procure-to-pay. A company needs something. Someone raises a requisition. Someone approves it. A purchase order is created. The supplier delivers the goods or services. Someone records the receipt. The supplier sends an invoice. Finance matches the invoice against the purchase order and receipt. Someone investigates exceptions. Someone approves the payment.

1. Requisition
2. Approval
3. recordPurchase order
4. Delivery
5. recordGoods receipt
6. recordInvoice
7. Three-way match
8. Exceptions
9. Payment approval
10. Payment

What we actually care aboutDid we receive what we agreed to buy?

What we actually care aboutWhat do we owe the supplier?

There are good reasons for many of these steps. But suppose AI can create the purchase order, communicate with the supplier, read the invoice, perform the matching, investigate routine exceptions and prepare the payment. Then you might ask why the invoice is the centre of the process at all, and why we are matching documents. What we actually care about is whether the company received what it agreed to buy, and what it owes the supplier.

The documents are evidence of those things. They aren’t the things themselves.

A lot of business software is built around that evidence. An invoice represents a claim for payment. A purchase order represents a commitment. A receipt records that something was received. A reconciliation tells us that two records agree. Over time, we start designing around the records rather than the events they represent.

A fossil record

Most business processes weren’t designed all at once. They accumulated. A company has an error, so it adds a control. It gets bigger, so it adds another approval. Two systems don’t communicate, so someone creates a reconciliation. A manager wants visibility, so someone creates a report. Another problem happens two years later, and another step gets added.

Each decision may have made perfect sense at the time. The resulting process can still make very little sense as a whole. A business process is often a fossil record of the problems an organisation has encountered.

It grew around two limits. Software was much better at moving records around than understanding what actually happened, and people were needed for judgment, communication and exceptions. Some of those limits are changing. AI can read documents, communicate with people, work with information from several systems, handle some exceptions and make bounded decisions.

Two different bets

That leaves two questions: what should AI do inside the existing process, and what would the process look like if we designed it today? Answering both at once means making two bets. The first is whether AI can reliably do the work. The second is what the process should look like if it can.

If something goes wrong after you have made both, it can be surprisingly difficult to know which bet was wrong. Maybe the AI wasn’t reliable enough. Maybe the new process was badly designed. Maybe an important control disappeared. Maybe humans were still needed in places nobody expected. Maybe people simply didn’t know how to work with the new system.

This is one reason to introduce AI into an existing process before throwing the process away. Not because the existing process is necessarily good. It may be terrible. But it gives you something to compare against. People already know how it works. They know the exceptions. They know how to recover when something goes wrong.

It also shows you what AI actually does when it meets the messiness of a real business. You find out which tasks only looked easy in a demo, which exceptions really require judgment and which controls matter. Some steps everyone assumed were necessary turn out not to be. Some that looked like bureaucracy exist for a good reason.

Matching goods received to a purchase order sounds simple. Often the receipt doesn’t say which order it belongs to. So we start with the vendor, look for orders with matching line items, and then find that the item codes in the vendor’s shipping notice aren’t the ones in the ERP.

That experience changes the problem. You are no longer asking what AI might be able to do, but what it has shown you it can do, which is a much better basis for redesigning a process.

There is no rule that you have to do this first. If you’re building a new process from scratch, there may be no old process worth preserving. If an existing process is fundamentally broken, automating it first may simply make a bad process cheaper. And if the cost of failure is low enough, changing the technology and the process together may be perfectly reasonable. Changing what machines can do and changing how the business works are two different decisions. Sometimes they should happen together. Sometimes experience with the first makes the second much easier.

Then the process changes

With that experience, you can start rethinking the process itself. Maybe the requisition disappears, along with most approvals. Maybe the invoice is no longer the centre of procure-to-pay, and three-way matching gives way to checking what arrived directly against what was agreed, with the invoice as one more piece of evidence rather than the thing everything hangs on. Maybe the people who used to process invoices spend their time on suppliers, exceptions and risk instead.

At some point, it becomes difficult to say that you have merely automated procure-to-pay. You have changed what procure-to-pay means.

The same thing could happen elsewhere. A support process may no longer revolve around tickets. A software team may no longer organise work around writing code. An analyst may no longer spend much time producing reports, because the information can be generated continuously. An operations team may no longer be organised around the handoffs between systems.

Companies have spent decades designing processes around the limitations of humans and software. AI removes some of those limitations. If AI can do the work, why does the organisation still work the way it does?