When companies start using AI, a common first question is where they can use it. This is reasonable. There is a lot of work to choose from. Someone answers customer emails. Someone reviews invoices. Someone prepares reports. Someone writes code. Someone reconciles transactions. Someone follows up with vendors.
Could AI do some of these things?
Usually the answer is yes. 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 this. But once AI starts doing the work, you begin to notice something else: 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 before. When people are doing the work, we tend to focus on how the work gets done. Once machines start doing it, we start looking at the process a little differently.
The process is not the business
Take procure-to-pay, for instance. 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.
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.
You might start asking different questions. Why is the invoice the center of the process? Why are we matching documents? What we actually care about is whether the company received what it agreed to buy, and what the company owes the supplier.
The documents are evidence of those things. They aren’t the things themselves.
A lot of business software is built around representations of business events. 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 these records rather than the events they represent.
Businesses are full of history
Most business processes weren’t designed all at once. They accumulated over time. 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 organization has encountered.
Software has historically been much better at moving records around than understanding what actually happened. Humans, meanwhile, were needed for judgment, communication and exceptions. So processes grew around what software could handle and what people could manage.
The interesting thing about AI is that some of those constraints are changing. AI can read documents, communicate with people, work with information from several systems, handle some exceptions and make bounded decisions.
That creates an odd situation. We can ask what AI should do inside the existing process, but we can also ask what the process would look like if we were designing it today. Those are different questions, and changing both at the same time means we are betting on both answers.
Two different bets
Suppose we take an existing process and replace some of the human work with AI. We are making one main bet: can AI reliably do this work?
Suppose instead we redesign the entire process around AI at the same time. Now we are making another bet: if AI can do this work, what should the business process look like?
If something goes wrong, 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 there can be value in introducing 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.
More importantly, it gives you a chance to see what AI actually does when it encounters the messiness of a real business.
Learning by doing
You find out which tasks are easy and which ones only looked easy in a demo. You discover which exceptions really require judgment. You learn which controls matter. You find activities that everyone assumed were necessary but turn out not to be. You also find the opposite. Things that looked like bureaucracy may exist for a good reason.
That experience changes the problem. You are no longer asking what AI might be able to do. You are asking what it has actually shown you it can do. And that is a much better basis for redesigning a process.
But there is no rule that says 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.
The point is not that one sequence is always right. It is that 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 can make the second much easier.
Then the process changes
Once you have that experience, you can start rethinking the process itself. What does that actually look like?
Maybe the requisition disappears. Maybe most approvals disappear. Maybe the invoice is no longer the center of procure-to-pay. Maybe three-way matching is replaced by something else. Maybe the people who used to process invoices spend their time dealing with 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 organize 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 organized around the handoffs between systems.
The process starts to look different because the reason for having so many human steps has changed.
If AI can do the work, why does the organization still work the way it does?
Companies have spent decades designing processes around the limitations of humans and software. AI removes some of those limitations.
The opportunity is not simply to make those processes faster. It is to discover which parts of them were really necessary in the first place.
