Does the Business Still Need a Functional Translator?

I’ve been thinking recently about the risk of approaching SAP transformation with a Maslow’s Hammer mindset. In other words, treating every challenge as if it demands a massive, multi-year program delivered by the same partners using the same playbook. I’ve also argued that the most valuable AI use cases can and should be deployed before large-scale ERP transformation, not as a downstream reward for surviving one.

But what happens when you actually do that? And why do the implications go well beyond transformation?

See also: Building an Agentic AI Strategy That Delivers Real Business Value

The best SAP plumbers in the business

The last four weeks have been the most interesting in my time at Lemongrass. For those who know us, we are technical people. I’ve often joked that we’re the best SAP plumbers in the business. Honestly, we’ve always walked a pseudo-technical-functional line, but things are changing. Fast.

The two worlds have most definitely converged. And the catalyst is (you guessed it) AI.

We’ve been investing in AI heavily over the past few years, primarily to help clients make the move to S/4HANA and Cloud ERP. What I love is when we sit down with clients, and they start telling us how they want to use what we’ve built differently. That’s exactly what’s been happening.

See also: Platform-First Enterprise AI: Turning Data Islands into Autonomous Intelligence

AI as the accelerator

For several clients recently, we’ve worked hand-in-glove with their teams using AI to map out key business processes, analyze custom code, document the as-is functional layer, and then generate recommendations for to-be specifications. These to-be specs, when built with the right level of detail and semantic precision, can be passed directly to rapidly evolving AI capabilities to build and unit test the output.

That last point matters. The quality of the to-be specification is the differentiator. Vague requirements produce vague results. But when the AI platform has deep, structured context, not just what the code does, but why it exists, how it relates to configuration, what integrations it touches, and where SAP’s standard roadmap already covers the intent, the output is genuinely usable. This is where years of investment in tooling and deep SAP knowledge compound.

In itself, this is quite exciting as a way to accelerate the journey to S/4HANA with a cleaner core. But it’s not the most interesting part.

See also: Studies Find Scaling Enterprise AI Proves Challenging

The reversal

The business does not sleep. They want to go faster, drive more change. So what if this approach was effectively reversed?

Instead of IT and consultants using AI to map the current state and define the future state, what if you gave the business a means to articulate what they want, in natural language, and the AI platform, armed with a deep understanding of the existing environment, could reason over that request and come back with something no functional consultant has ever been able to produce quickly: a simulated impact assessment?

Imagine a finance director typing: “I want to automate the three-way match exception handling for our top 50 vendors.” Within minutes, the platform, which already understands the custom code, configuration, integrations, and transaction history, comes back with: “This change would reduce month-end close by approximately 1.5 days based on your current exception volumes and resolution times. Here’s what needs to change in your landscape, here’s what SAP standard already covers, and here are the risks.”

The finance director reviews the impact. It makes sense. So the platform asks: “Would you like me to build this?” On approval, it generates the code, produces the test cases, and submits the package for unit testing, all within the same session. The human decision point hasn’t been removed. It’s been moved to where it actually matters: after the business can see what a change is worth and before anything touches the production landscape.

Or a supply chain VP asks: “What if we tightened payment terms for vendors below a certain spend threshold?” The platform models the downstream impact on DSO, flags which custom pricing routines would be affected, identifies integration points with the treasury system, and quantifies the working capital improvement. The VP sees the numbers, approves the direction, and the platform generates the implementation, ready for review and testing. All before a single functional consultant has been briefed.

The building blocks for this exist now, and they’re assembling faster than most people expect. Not every change type is ready for this today. Complex, cross-module process redesigns still need human expertise at the specification stage. But for a significant share of well-patterned changes, especially configuration-driven or scoped custom code, the full chain from intent to tested code is credible. In recent workshops with several customers (IT leaders, not business users), we walked through how this comes together. The reaction was immediate and consistent: this would fundamentally change their operating model.

See also: Why Most AI Projects Fail Before They Reach the Algorithm

Why this changes everything

Today, the business can’t even evaluate whether a change is worth pursuing without going through IT and an SI partner. For example, a business user identifies a need. They raise a request, often poorly specified because they don’t speak SAP. A functional consultant then translates that intent into a specification. Someone estimates the effort. It goes through prioritization. Weeks or months later, you might get a business case, and even then, the projected impact is often a guess informed by experience rather than data. If it gets approved, a developer builds it, someone tests it, and it goes through change advisory. The whole cycle can take months for even modest changes.

The functional consultant is the translator sitting between business intent and system reality and is the linchpin of the entire chain. Not because the translation is inherently difficult, but because nobody else has the contextual knowledge to do it.

Now consider what happens when AI holds that context. The business can self-serve an impact simulation and see the proposed implementation in the same conversation. They can prioritize their own backlog armed with real data. They can show up to the conversation with IT already knowing what a change is worth, what it involves, and with tested code ready for review. The conversation shifts from “should we do this?” (subjective, political, slow) to “the model says this delivers X and here’s the code to make it happen, do we approve it?” (evidence-based, faster, auditable).

The same AI-driven approach we are building for S/4 transformation applies to BAU change just as well. Arguably, even better, because business-as-usual (BAU) environments are more stable, and the historical data for simulation is richer.

See also: Turning Unstructured Data into a Manageable Enterprise Asset

Where this is this heading?

Today, the human sits at the approval point in the middle of that chain, reviewing impact and greenlighting the build. That’s the right place for them. But the trajectory is clear: as confidence in the platform grows and the simulation models prove accurate over hundreds of change cycles, organizations will start defining policies that allow certain categories of change to flow through with minimal human intervention. Low-risk config changes, well-patterned enhancements with predictable impact, and routine adjustments that the business has approved in principle. These start to move on their own, with humans reviewing exceptions rather than approving every individual change.

That’s when BAU change starts to look less like a project pipeline and more like a continuously adapting system. We’re not there yet. But the path from “simulate and present” to “simulate, build, test, and propose” to “simulate, build, test, and deploy within policy guardrails” is a straight line, not a leap of faith.

This doesn’t mean governance goes away. If anything, the approval function becomes significantly more important when the velocity of change increases by an order of magnitude. You need people who understand the business impact of a change and can exercise judgment. People who can look at a simulated outcome and say “yes, that’s what we want” or “no, you’ve missed the downstream effect on X.”

Those people, by the way, look a lot like today’s best functional consultants. The ones who deeply understand business processes and SAP configuration don’t vanish. Their role transforms. They become the reviewers, the approvers, the humans-in-the-loop who validate what the AI generates. The consultants who just translate requirements into specifications without adding judgment? They’re the ones whose work gets absorbed.

The operating model shift

For organizations currently paying SI partners millions of dollars a year to maintain functional and development teams for BAU support, this is a material shift. For the SIs themselves, whose business models depend on those benches staying busy, it’s an uncomfortable question and one that echoes the Maslow’s Hammer problem from a different angle. And as such, they are unlikely to lead you here.

If you free your mind from the constraints of the past, this changes the nature of how BAU change happens in SAP environments. It means transformation and continuous improvement are no longer separate workstreams with separate teams, separate budgets, and separate timelines. They converge into a single, AI-mediated loop where the business articulates intent, the platform simulates impact, generates the implementation, and smart people approve or redirect.

The functional translator isn’t disappearing because the work is going away. The work is being absorbed by platforms that hold the context the translator once monopolized. The business no longer needs someone to tell them what a change means. They can ask the platform and get an answer grounded in their own data, their own landscape, their own transaction history.

Does the business still need a functional translator? For the hardest, most ambiguous, most strategically consequential changes, absolutely. But for the long tail of BAU change that keeps armies of consultants busy and keeps the business waiting? Increasingly, no. And that long tail is where most of the money is.