Enterprise AI Is Really a Business Process Redesign

In the 1980s, Ford Motor Company faced what looked like a classic efficiency problem.

At the time, Ford's North American accounts payable department had more than 500 employees. Once a purchase was complete, finance staff had to reconcile three documents: the purchase order issued by procurement, the receiving record confirming the warehouse had taken delivery, and the invoice from the supplier. Payment required all three to match; any mismatch triggered a manual investigation. The traditional fix seemed obvious: install a better computer system to reconcile faster, then cut headcount.

What actually changed Ford's thinking was the discovery that Mazda, in which it held a stake, performed similar work with very few people. Ford stopped asking only how finance staff could reconcile faster and started asking why the entire procure-to-pay process had to be designed this way at all.

In the new process, purchase orders went straight into a database. When goods arrived, warehouse staff confirmed receipt in the system, which automatically matched the receipt against the purchase order and triggered payment when the match held. Much of the work built around three-way matching — purchase order, receiving record, and supplier invoice — was eliminated. The project became a classic case in business process reengineering, and it cut the size of Ford's accounts payable department dramatically; studies typically put the reduction at around 75%.

This story from more than forty years ago is still instructive in today's AI wave.

Because many companies adopting AI today stand in a strikingly similar position.

A product manager who once needed a full day to write a PRD can now generate one in two hours with AI. An editor who spent half a day gathering material and drafting can get a first draft in fifteen minutes. Code that took a developer a day may now take a few hours with AI coding tools. Every role looks more efficient. But after a few months in production, companies easily discover that individual tasks got faster, while the end-to-end business process did not speed up at the same rate.

The reason is simple. Much of the time inside any company was never spent on discrete actions — writing a document, writing code, generating an image. It is spent waiting, handing off, confirming, re-communicating, and reworking.

So if AI adoption stops at "give every role an AI tool," the result is usually only local efficiency gains. The question really worth asking is: now that AI has changed the cost and capability boundaries of so much work, do we still need the processes we designed in the past?

From "AI helps the PM write a PRD" to redesigning the entire development process

When I was a product lead, I felt this problem deeply.

On complex B2B products in particular, a requirement travels a long chain from proposal to launch. The business brings a requirement to the product manager, who works through several rounds of discussion and produces a PRD. UI/UX designs against the PRD and holds a design review. Then comes a requirements review, where frontend, backend, and QA jointly confirm the implementation approach. QA writes test cases, engineering builds, and finally there is integration testing and acceptance.

Drawn on a flowchart, this process looks perfectly standard. In practice, few projects move left to right that smoothly.

When the PM writes the PRD, a boundary case may go unconsidered. Only when UI/UX produces design mockups does someone realize a piece of business logic does not hold, and the requirement goes back for adjustment. At the requirements review, engineering finds that the data model or system capability cannot support the design, so it changes again. Once development starts, exception flows, permission issues, and bulk-operation problems surface gradually, and the requirement keeps changing. At acceptance, business, product, and engineering may still disagree about what a single sentence in the requirement actually means.

In my time on complex B2B products, one strong impression was how much of the project cycle went into this kind of requirement clarification and repeated adjustment. On some complex projects, that portion approached 30% of the entire project cycle.

With AI, one step is especially worth redesigning: pull the demo forward to the requirement definition stage.

Now, after the business proposes a requirement, the product manager can first work through the core goal, user roles, and basic logic with the business, then use AI coding and prototyping capabilities to build a working demo in a very short time.

At the next requirements review, no one has to imagine the final product from a few dozen pages of PRD. Business, product, UI/UX, frontend, backend, and QA can all sit in the room and walk through the real user path end to end.

Where does the user enter? What is the first step? What happens when there is no data? Is operating on ten objects at once the same as operating on a thousand? What does the system show on failure? What does each permission level see? Where does the user check results after completing an action? Does the resulting data flow back?

Many questions that stay fuzzy after half an hour of discussion surface quickly once someone actually clicks through the product.

At this point, the value AI brings goes well beyond helping a PM write a PRD faster. It shifts when requirement confirmation happens. A large share of the problems that used to surface only at design, development, or acceptance now appear before formal development begins.

The old development process rested on a hard constraint: building a genuinely working product was expensive, so we had to describe things as thoroughly as possible in documents and designs before development could start. As AI drives down the cost of producing a demo, that constraint is dissolving.

So the process can be designed differently: rapidly build an interactive demo, converge the requirement through real user paths, then update the formal PRD. QA uses the converged requirement, the demo, and the boundary conditions to generate acceptance scenarios and test cases early, and those cases are shared with product and engineering as clear input for development. Engineering then combines the PRD, the test cases, and the code and context of the existing project to build with AI.

From a software engineering standpoint, this resembles ATDD — acceptance test-driven development: define the acceptance conditions clearly before implementation, then develop against them.

Once redesigned this way, the unit of AI efficiency shifts from a single role to an entire development chain.

Content production is the same: what really needs to change is how editors work

The same thing happens in the content industry.

On an automotive news project we worked on, we ran into a similar problem. Traditional news production depends heavily on the individual editor: every day they scan a large number of media outlets, websites, and sources, hunt for events that might matter, and rely on personal experience to judge which are worth writing about and from what angle. Once the topic is chosen, they find material, organize the article, draft, review, and publish, then judge the result from metrics such as readership.

In this chain, writing is certainly a cost, but the truly expensive part lies further upstream: what to read each day, which events deserve attention, what content might draw traffic, which angles are worth pursuing.

Those judgments used to live largely inside individual editors' heads.

If AI is used only after an editor picks a topic — open a large model and say "write me an article" — it mainly addresses the writing step.

But redesign the whole process and the picture changes completely.

We can continuously collect different sources in the industry, place the large volume of new content each day into a unified data layer, and use AI for event detection, clustering, and deduplication. A single hot event may be covered repeatedly by dozens of outlets; the system can first recognize that they are the same story. It then scores candidate events using historical content data, user behavior, search trends, and on-site clicks, and AI generates possible topics and reporting angles from that information.

The editor no longer faces hundreds or thousands of items to browse by hand each day, but a set of candidates already organized and ranked.

Once a topic is chosen, AI can assemble the event background, company information, historical material, and data into a first draft. Human work concentrates more on fact-checking, importance judgment, editorial stance, and the deep treatment of a few complex pieces. After publication, real clicks, reads, searches, and conversions flow back and continue to shape the next round of topic decisions.

At that point, what has changed is the entire content production mechanism.

Editors used to start each day by finding information; in the new process, information enters the system on its own. Topics used to depend largely on personal experience; the new process breaks that experience into data signals, rules, and models. Content performance analysis used to stop after publication; the new process feeds results continuously into the next production cycle.

Human value shifts accordingly: away from hauling information, organizing material, and repetitive writing, toward rule design, value judgment, fact-checking, and handling exceptions.

This may be what real change looks like when AI enters a business process.

From ERP to AI, companies have seen this problem before

Looking back at the history of enterprise digitization, today's situation is not unfamiliar.

In 1990, Michael Hammer published the now-famous article "Reengineering Work: Don't Automate, Obliterate" in Harvard Business Review. One of his core arguments was that when companies face information technology, they tend to automate existing processes directly and overlook the possibility of redesigning the process itself. Ford's accounts payable case is widely discussed within exactly this school of business process reengineering.

Then came the ERP era, where the same problem kept appearing.

When a company buys ERP, the real change goes far beyond moving Excel sheets and paper forms into a system. Finance, procurement, inventory, sales, and supply chain data must be unified; processes across departments must connect; master data must be maintained under common rules; and many ways of working that relied on offline communication and personal habits must change. One of ERP's core capabilities is precisely connecting multiple business modules within a unified data and process system. SAP's definition of ERP likewise emphasizes integrating core business processes across finance, supply chain, procurement, and sales into a single source of data.

Even today, as SAP drives cloud ERP implementations, it still stresses Fit-to-Standard: first help the company understand standard business processes, then identify the genuinely necessary differences and adjustments, rather than endlessly customizing the system around existing ways of working. SAP also warns explicitly that departing from standard processes creates downstream maintenance costs.

Beneath all this lies a very stable pattern: whenever a company gains a new technological capability, it usually applies it first to optimize existing actions; once the technology truly penetrates the business, it eventually begins to change the relationships between those actions.

ERP largely changed how structured data flows inside a company. AI's impact may go further, because it is starting to enter knowledge work that long depended on people.

Reading, understanding, summarizing, classifying, writing, designing, programming, judging, checking — work that was hard to hand to traditional software can now increasingly involve AI.

And many of the enterprise processes we take for granted were designed around the premise that these things must be done by people.

When that premise changes, the process deserves to be redesigned.

The real question is: "If we started from scratch today, would we still work this way?"

So when we help companies adopt AI, we increasingly focus on one question: does the company want to optimize a task, or improve an entire business outcome?

If you only ask "how can the PM use AI," "how can sales use AI," "how can the editor use AI," you easily end up with a pile of tools: the PM writes PRDs with AI, sales writes emails with AI, editors write articles with AI, engineers use AI coding. Everyone may save some time, but the original organizational relationships, approval gates, and handoff patterns barely change.

Ask instead for a single business process to be mapped out completely, and the problem becomes much clearer.

We usually look for a few specific types of nodes: waiting, handoffs, repetitive work, human judgment, and rework.

Then we examine, one by one, which capabilities AI has already made dramatically cheaper. A high-fidelity demo that once took design and engineering days or weeks can now be built by a PM alone in hours. Reading ten thousand documents once took a large amount of manual labor; a model can now process them in batches. Generating hundreds of test scenarios used to be expensive; now it can be automated. Producing large volumes of personalized content at scale was once impossible; its marginal cost is now falling fast.

Next, we redesign the target process: which steps can be merged, which decisions can move earlier, which work can run in parallel, which steps can be automated, and which approvals and handoffs have lost their original purpose.

Only then do we decide whether we need large models, agents, workflow tools, RPA, enterprise knowledge bases, data platforms, or custom systems. Technology selection becomes much simpler, because the tools now serve a business process that has already been redesigned.

Decades ago, when Ford redesigned accounts payable, the most valuable question was very simple: if the system can already link the purchase order and the receiving record, why keep hundreds of people reconciling three documents?

Facing AI today, companies can ask their own business the same way.

Why must a product requirement travel serially between several departments for so many rounds? Why must an editor browse hundreds of news items by hand to find one topic? Why can a particular business judgment exist only in the head of one senior employee? Why must work that has already happened thousands of times be handled from scratch every time?

AI is dissolving some of the foundational constraints that shaped how we designed business processes.

So for companies that genuinely want AI to land in the business, I think there is one question worth asking again and again:

If we were founding this company today, with today's AI capabilities from day one, would we still design this business process the way it is now?

Much of the next stage of real AI upside may be hidden in the answer.