Archive

Monthly Archives: August 2026

For years, expertise was measured by how much you knew.

The best ERP consultants could recite configuration settings from memory. They knew which parameters to enable, where to find the obscure options, and how one setting quietly broke another three modules over. Experience meant accumulating answers.

AI changes that.

Today, the answer is often seconds away. Ask an AI how to configure inventory dimensions, build a procurement workflow, design a chart of accounts, or set up a security role, and you’ll get a reasonable starting point. Often it will just generate the configuration itself.

So does that make years of ERP experience less valuable?

Quite the opposite.

The Skill Has Shifted

The value was never really in typing values into a form. It’s in knowing what the business actually needs, translating that into the right request, catching it when AI makes the wrong assumption, and steering it back to the correct solution.

Think of AI as the world’s fastest configuration specialist. Tell it exactly what you want, and it will produce an impressive amount of work in very little time. Give it a vague or incomplete request, or one built on a misread of the business, and it will build the wrong thing just as fast. Faster, in fact, than any consultant ever could.

The consultant’s role hasn’t disappeared. It has moved up a level.

Instead of asking “How do I configure this?” we’re asking “What should this business process look like?”

Instead of worrying which checkbox to select, we’re deciding why that checkbox should exist in the first place.

That’s a much harder problem.

A Procurement Example

Take Dynamics 365 Finance & Supply Chain. Suppose a company wants to automate purchasing.

A few years ago, a consultant would spend hours clicking through forms: building workflows, defining approval hierarchies, configuring procurement policies, testing every scenario by hand. Today, AI can generate much of that scaffolding.

But someone still has to answer:

  • Should approvals run by department, cost center, project, or spending threshold?
  • Which purchases should bypass approval entirely?
  • How are emergency purchases handled?
  • What happens when an approver is out on vacation?
  • Which controls satisfy audit requirements without slowing the business down?

Those aren’t configuration questions. They’re business questions. And business questions have always been where experienced consultants create the most value.

The Pattern Is Everywhere

Developers spend less time writing boilerplate and more time describing the architecture they want. Data analysts spend less time writing SQL and more time deciding which questions are worth asking. Architects spend less time drawing every line and more time defining the building.

Doctors increasingly have AI helping interpret medical images, but the physician still decides which tests to order, how to read the results in context, and what treatment actually fits the patient.

The profession doesn’t disappear. The center of gravity moves.

Prompting Is Requirements Gathering, Rebranded

This is why prompt writing gets misunderstood. People treat it as clever wording. It isn’t.

Good prompts are evidence of good thinking. A well-written prompt reflects a clear grasp of the business objective, the constraints, the desired outcome, and the tradeoffs involved. The better you understand the problem, the better your prompt becomes.

In many ways, prompting is just the modern version of requirements gathering. The consultant who asks twenty thoughtful questions before asking AI a single one will consistently outperform the consultant who jumps straight to generating configurations.

Where This Leaves the Next ERP Expert

The future ERP expert will spend less time configuring systems and more time shaping solutions. That means curiosity beats memorization. Business knowledge beats navigation skills. Judgment beats mechanics.

AI is making execution cheaper. It’s making thinking more valuable.

The companies that win won’t just have access to better AI. They’ll have people who know what to ask, why they’re asking it, how to challenge the results, and when to change direction.

The next generation of ERP consultants won’t be measured by how fast they can configure a system. They’ll be measured by how well they can define the problem AI is being asked to solve.

Because in the age of AI, the competitive advantage isn’t having all the answers. It’s asking the questions that lead to the right ones.

In 1899, the Norwegian mathematician Niels Henrik Abel complained about Carl Friedrich Gauss’s papers. Gauss’s proofs were airtight but gave no hint of how he’d gotten there. Abel said Gauss was “like the fox, who effaces his tracks in the sand with his tail.” Gauss’s reply has outlived the complaint: “No self-respecting architect leaves the scaffolding in place after completing the building.”

He wasn’t being cagey. Gauss ran through dozens of false starts for every theorem he published, and he thought showing that mess would do the reader a disservice. A finished proof is not a transcript of how the proof was found. It’s a clean path from A to B, built after the fact, once you already know where B is.

This is exactly what happens in a good product demo, and it’s why demos so often feel like a kind of dishonesty even when every word in them is true.

The gap between finding and showing

When you’re building something hard, most of the time is spent wrong. You try an approach, it breaks in a way you didn’t expect, you try another. Six weeks in, you’ve got a whiteboard full of dead ends and one narrow path that actually works. Then you build the demo, and the demo only shows the narrow path. Someone watches it and sees three clicks. They have no way of seeing the six weeks.

That’s not a flaw in the demo. A demo that included the six weeks would be unwatchable, and it would also be the wrong artifact. Nobody wants the scaffolding. They want the building.

But it does create a predictable failure mode: the audience underestimates what it took, and then either assumes it must have been easy (so why did it take so long) or assumes it must be fragile (since nothing that clean survives contact with reality). Both reactions come from the same place: they’re reacting to the absence of visible effort, not to the actual state of the work.

Related shapes of the same idea

This tension shows up everywhere people do hard work and then have to present it simply:

Einstein’s Zurich Notebook, from 1912–13, is page after page of failed derivations. He got within a hair of general relativity, talked himself out of it for the wrong reasons, and lost three years before arriving at the fifteen or so symbols that appear in the final field equations. Nobody reads the field equations and sees the three lost years.

There’s an old story, probably apocryphal, about the engineer Charles Steinmetz, called in to fix a broken generator no one else could diagnose. He listened to it, made one chalk mark on the housing, and told them to replace that part. His bill was ten thousand dollars, itemized: “making the mark, one dollar; knowing where to put it, nine thousand nine hundred ninety-nine dollars.” The mark is the demo. The knowing is the scaffolding.

And there’s the duck on the pond: gliding, apparently motionless, paddling hard just under the surface where no one’s looking. It’s a cliché precisely because it describes something true about most visible competence.

What to do with this, if you’re the one giving the demo

You’re not obligated to show your work, and you shouldn’t try to cram it in. But it’s worth occasionally naming that it exists, even in one sentence: “this took longer than it looks like it should have” or “we tried three other approaches before this one.” Not as a boast, and not as an apology. Just as a way of telling the audience that the gap they’re sensing is real, so they don’t have to fill it in themselves with a worse story, like it must have been trivial, or it must be held together with tape.

Gauss removed his scaffolding because he trusted the building to stand on its own. That’s usually the right call. The failure isn’t leaving the scaffolding down. It’s letting people assume there was never any scaffolding at all.