Some of the most exhausting work in an enterprise AX project happens before the contract is signed. Choosing a model or building a proof of concept can be easier than explaining the value of a project that has not even started. I have encountered this tension repeatedly in consulting.
Exhausted Before the Project Even Starts
The early stages are familiar. A business unit receives an annual AX transformation mission, ideas are collected, technical options are discussed, and vendors are asked about scope and budget. There is nothing inherently wrong with that process.
The difficult version begins when the initiative is not anchored in an operational problem. If a bottleneck and desired outcome are clear, discussion can narrow quickly. If the need to demonstrate annual transformation activity comes first, the investment argument can become more elaborate than the definition of the work.
Meetings accumulate before contract signature or kickoff. Who benefits? Why now? Why not improve the existing process? What will justify the money? Sometimes responsibilities quietly reverse: an external AX consultant becomes the one effectively constructing a case for the CFO or CIO, even though the business unit owns the problem.
Then comes the familiar RPA-era calculation. Two hundred employees each save fifteen minutes a day. Multiply by working days and a labor rate, and an impressive annual number appears on a slide. The arithmetic may be fine. The financial conclusion is not established by arithmetic alone.
When the consultant must prove the business value of someone else’s initiative, something has already shifted. Strictly speaking, it is not my battle. Yet to get the project started and ultimately make something useful for the people doing the work, I find myself in it.
It is not my battle, but somehow it is.
Fifteen Minutes Saved Is Not Fifteen Minutes of Cash Released
Time savings matter. Small improvements can change the way a team works. We still need to distinguish capacity released from value actually realized.
If contracted services or overtime spending measurably decline, there may be cash-releasing savings. If the same team handles higher demand without new hiring, productive capacity may have economic value. But a measurement that a task takes fifteen fewer minutes does not reveal what happened to those minutes afterward.
Nor should the same time be counted once as payroll savings and again as new revenue. This does not mean value exists only when headcount falls. It means identifying the kind of benefit, its owner, and the evidence that supports the claim.
Time saved is not the result. It is the beginning of a better question: what can the business now do differently?
A Fast PoC Should Help the Business Unit Explain Its Own Work
I value fast, bounded PoCs for a reason that has little to do with polished demonstrations. They can turn an abstract transformation mission into a recognizable unit of work.
Ask for one task the business unit already performs. What information must be checked? Where does judgment matter? Who can accept the result? Which system must record it before the job is finished? The AI portion can be small. One observable business outcome is often more useful than a promise to automate everything.
Better questions emerge. Is this the currently approved product information? Should a person verify the draft before sending it to a customer? If the CRM does not record the outcome, how will the next employee know the case was handled? The conversation moves away from an abstract vote for AI and toward a concrete workflow change.
The consultant demonstrates feasibility. IT checks access and operational safeguards. The business unit defines what a valid completed task looks like. Finance decides which benefits have actually been realized. Unless these responsibilities become clear, the consultant may continue explaining the sponsor’s business case indefinitely.
A good PoC does not prove the consultant was right. It helps the business unit explain what changed in its own work. A successful pilot still does not establish production economics; access controls, reliability, maintenance, and recovery introduce further costs.
An AI Answer Is Not a Completed Business Task
Consider a hypothetical B2B technical inquiry. This is an illustrative example, not the outcome of a named customer project.
A customer asks about product compatibility. AI retrieves documents and drafts an answer. From the model’s perspective, that looks like success. From the business team’s perspective, the work may still be unfinished. Was the source approved and current? Was the customer’s configuration checked? Who authorizes the reply? Was the answer actually sent and recorded in the CRM?
Only when the relevant checks and system records are verified can the responsible process count a completed result. Call this an Accepted Business Outcome. It does not mean every workflow needs a human signature. Low-risk cases may use previously approved automatic rules and independent readback.
Regenerating the same failed answer three times does not create three completed inquiries. Keep a stable work-item identity across attempts. A draft rejected on first review but accepted after revision has different first-pass and eventual acceptance rates. Its review and rework costs must remain visible.
An LLM does not get to declare that a business task succeeded. The accountable process and its records do.
The Cheapest Model May Not Complete Work at the Lowest Cost
Compare manual work, AI assistance, and bounded automation on a comparable case mix, observation window, and quality standard. Giving only easy cases to AI and difficult ones to humans can manufacture a flattering ROI.
Inference has a visible price tag. Human review, retries, correction, permissions, evaluations when policies change, incident handling, and system readback may be less visible. Conversely, it is misleading to charge the AI initiative for every pre-existing security expense as if it were incremental.
Consider invented figures purely for illustration. A manual process receives 100 eligible cases, completes 90 acceptable outcomes, and incurs KRW 2,700,000 in attributable cost. Its cost per accepted outcome is KRW 30,000. An AI-assisted process costs KRW 2,400,000 but accepts only 80 cases. Its cost per accepted outcome is also KRW 30,000. A smaller total invoice did not improve the unit measure. The unresolved cases and quality differences still matter.
The equation is simple: total attributable workflow operating cost, including failures and rework, divided by unique verified completed work items in the same period. Unverified drafts do not go in the denominator. Lower unit cost also does not automatically prove realized financial ROI.
Optimizing the cost of a model call and reducing the cost of finished business work are not the same problem.
Which Numbers Can Finance Actually Recognize?
What we need is an unglamorous ledger. It records which work entered the process, which outcomes were accepted, how much human review and recovery occurred, and which costs and business results actually changed.
Start with a stable work ID, cohort and case mix, observation period, eligible volume, accepted volume, first-pass yield, human review and rework time, model and tool cost, attributable operational and security expenses, quality violations, and evidence for realized cash or productive capacity.
The sponsor’s explanation must evolve too. ‘This task used to take forty minutes and now takes fifteen’ is useful operational information. ‘At comparable quality, our team handled additional cases, reduced customer waiting time, or avoided a measurable expense’ is a stronger claim if the evidence exists. Otherwise, it remains a hypothesis.
McKinsey’s April 2026 discussion of AI value measurement connects technology performance to adoption, operating outcomes, financial impact, and explicit accountability. What matters in practice is whether those links exist in the business unit’s own records.
Not Every AX Initiative Deserves to Scale
The evidence should lead to a decision. Scale when quality, controls and economics hold over time. Narrow the scope when only some case types benefit. Redesign when human review or correction consumes the gains. Stop, or revert to simpler rules or manual handling, when safe operation or meaningful economic value cannot be demonstrated.
There is no universal rule that a forty-percent saving justifies expansion. Risk varies by workflow, and an access-control violation cannot be offset by a cheap token bill.
Gartner’s September 2026 agentic AI analysis emphasizes the potential of specialized agents serving defined business processes. That is consistent with a narrowly scoped PoC. A forecast of future ROI should not be confused with a verified return today.
The Final Slide Should Belong to the Business Unit
AX consultants assess technology, design architecture, and build proofs of concept. Sometimes they end up defending the business unit’s investment case to senior leaders before a contract is signed. It is draining, especially when no one has settled what should improve but everyone wants a savings figure.
I do not think my job is to make that figure more persuasive. I can help the sponsor examine actual work, test a small observable outcome, and collect evidence of the change. Eventually, the business unit should explain the result without borrowing the consultant’s voice.
A PoC concluding that more investment is not yet justified is not necessarily a failed experiment. Avoiding an unnecessary deployment can be a good decision. If the project goes ahead, show which work was completed, at what quality, at what total cost, and with what real business value.
It is not my battle, but somehow it is. By the end, though, the business unit should be explaining its own results.