Why did SAP actually become so big? If you ask seasoned SAP professionals, the answer might be: because you could go completely wild in the system. For them, the unbeatable benefit for customers was that you could bend, tweak, and heavily customize the platform until even the most complex business processes were mapped one-to-one. This flexibility explains why many customers have wreaked havoc in their systems, abusing them as pure application servers and modifying the standard software beyond recognition. When you work in one of these “abused” SAP environments, it is hard to disagree with that point of view.

Demand driven

This is, of course, a highly technical perspective and only partially explains why SAP was adopted as the primary ERP system decades ago. In the 70s, 80s, and 90s, the situation was completely different. SAP was still growing and was not yet an established player. Neither in the broader market nor inside individual organizations. They actively had to convince companies to buy their software. Long term benefits like a robust partner ecosystem, widespread adoption, and out-of-the-box solutions for most business problems were not yet a reality. The SAP ecosystem was in its infancy.

From a technological standpoint, it was a completely different world. All the modern SAP products and frameworks we know today did not exist. However, one key element was present very early on, and it heavily accelerated adoption: an absolute focus on the customer. Software was developed directly at the customer’s site, with feedback implemented straight into the system. Later on, end users were given the ability to adjust programs themselves. Today, we would call these people key users. Back then, these key users could adapt the SAP system to include new fields, new reports, and new features on the fly, without waiting for someone from SAP to implement them into the standard core. If an essential feature was missing, it was brought up, coded, and made available in hours.

This agility is what convinced companies to invest in SAP. You received a standard system that solved most of your problems, and whatever it didn’t solve, you could build yourself with minimal effort. The people who actually had to work with the system were the ones empowered to enhance it. At that time, adjustments were still simple. Of course, this laid the foundation for future generations to go completely nuts. But in those early days, it was simply about adding a missing feature fast. The era of “maybe I should write my own reporting framework instead of using what SAP ships” came much later.

Bureaucracy driven

Companies do what companies do, and over the years, layers of bureaucracy were added. Teams were flooded with programmers, consultants, controllers, and other roles whose skill sets did not necessarily align with those of the end users. The main goal was to maintain a certain level of quality 🔗. As solutions grew increasingly complex, companies faced a new challenge: ensuring that an end user wouldn’t add a field that accidentally broke a process on the opposite side of the world. The chosen solution, however, was to keep the end user as far away from problem-solving as possible.

As SAP usage grew, bureaucracy scaled right along with it. Companies created and adopted extensive frameworks to control what was being developed or used. ITIL 🔗 was released in 1989. TOGAF 🔗, SCRUM 🔗 and PRINCE2 🔗 in the 90s. A more recent approach to keeping the end user isolated from direct problem-solving is SAFe 🔗, introduced in 2011. (SAFe is frequently cited to showcase how heavily these frameworks target corporate management rather than the end user. In fact, it has become a running corporate gag to point at a SAFe poster 🔗 and ask: “Where exactly is the end user?”).

Even when a great idea successfully passes the Proof of Concept (PoC) phase today, there is still so much governance to navigate that securing final approval remains incredibly complicated. All this governance costs money. So much so that it is no longer a survival of the best ideas, but rather a survival of the most complex, budget-hungry projects.

Budget driven

The current reality is that corporate end users are effectively blocked from having their voices and ideas taken into consideration. To get a problem solved, you need a sponsor, a budget, a defined scope, dedicated resources, a roadmap, and countless other prerequisites. Just getting an idea approved is an uphill battle, and even if you succeed, you still have to find an implementation partner just to build a PoC. That is assuming the employee with the idea is even heard in the first place.

The word “idea” might even be too polite in this context. It makes it sound as if an employee working 24/7 suddenly comes up with a revolutionary strategy that allows the company to enter a new market or generate billions in revenue. No, it is usually nothing like that. The goal here is simply to make the daily obstacles created by corporate governance less painful. It is about improving their daily work life. Often, these ideas are simply about being more productive and eliminating unnecessary, repetitive tasks:

• Why copy and paste text between applications manually instead of having the two systems communicate directly?
• Why type data manually into SAP when it could be uploaded directly from an Excel sheet?
• Why type serial numbers by hand when you could just scan a barcode to bring the item up on the screen?

Driving people nuts

These are valuable, easily solvable ideas. Many of them are total no-brainers. When the right people collaborate, a solution can be built in days, if not weeks. Yet, because only a handful of people might benefit from a specific fix, the idea is buried. This is the core of the problem. The resulting cost optimization might only save a few hours or a few thousand € per year. For the affected employees, however, the value is massive because it removes roadblocks implemented by people who never have to work with the processes they created.

The fact that employees become more productive and less frustrated is almost impossible to measure on a spreadsheet. What can and is measured, ironically, are the governance actions that create the frustration in the first place. The “damage” is easily quantifiable in enterprise architecture slides and organizational presentations; the micro-solution is not.

Because the financial benefit of an isolated solution appears too low to be visible, the overhead costs to solve it are deemed too high. They are still objectively low, but disproportionate to the forecasted optimization. As a result, many great ideas get stuck in a corporate dead zone: important, but not important enough to justify a project. They would save money, optimize processes, and make people happier and more motivated, but they simply don’t generate the massive numbers required for a formal business case.

The result?

Because employees often don’t know how to navigate complex corporate guidelines, or lack the connections to secure budget and executive approval, they eventually give up. The people who work daily with the processes - the ones who ultimately put data in and out of the systems - simply accept these systemic flaws as a given and resort to messy workarounds.

Do not forget: the employees are the company. When they lose out on small improvements, the company loses out too. The paradox is that while a micro-improvement does not seem to scale for an individual problem, it absolutely scales across the organization as a whole. Companies have dozens, if not hundreds, of these dead ideas at every single location. While each one individually is considered too small to realize, combined, these minor optimizations accumulate into a massive, highly impressive competitive advantage.

Back to the roots

What does all of this have to do with our initial question? After decades of maximizing the distance between the end user’s problem and the technical implementation, AI is bringing us right back to the beginning.

Honestly, who knows daily business bottlenecks better than the people who deal with them day in, day out?

AI enables the realization of all those minor improvements. Moving from an idea to a simple PoC is now just a matter of a single prompt. Moving from a PoC to a production-ready solution that respects corporate guidelines is now just a matter of feeding the AI the right knowledge, skills, and guardrails. And, of course, having access to enough tokens. The old issue of an idea never being realized due to a lack of budget, resources, or specialized engineering knowledge? AI completely solves it.

A single person can now build a PoC in a matter of hours. That person doesn’t even need to know how to code; knowing (exactly) what the application should do and defining the expected outcome is more than enough. A deployable version can be delivered in hours instead of days. Best of all, the app can be designed to be completely compliant with corporate guidelines from the start. The bottleneck was never the governance itself, but the sheer technical complexity of meeting it. Something a regular employee couldn’t do without an army of developers and architects. AI bridges this gap by acting as a automated compliance engine, translating rigid corporate rules into working, fully compliant code on the fly.

The end users get back control, and the company doesn’t lose its grip on governance. The costs involved in bringing these dormant, high-potential benefits to light are incredibly low. The actual investment is close to zero: give employees access to an AI tool, give them the necessary system access, and provide AI-friendly corporate guidelines.

The corporate selection process will still function, but employees will finally be able to test for themselves which ideas actually make sense. Because they can - again! - realize them. The number of ideas that survive and prove their business value will skyrocket simply because more ideas are being given a chance to live.

This approach allows companies to unlock an almost immeasurable competitive advantage. All those 5-minute improvements add up. Year-old or decade-old workarounds are suddenly solved, and the collective impact of these small changes becomes highly visible. A company utilizing this model will rapidly outpace competitors whose rigid corporate policies block employees from using AI. The advantage won’t manifest overnight, but it will happen much faster than any traditional change management program.

Of course, lifting these hidden treasures is not achieved by simply handing over an AI coding assistant to everyone. There is so much more to it: organizations must ensure that the same solution isn’t developed multiple times, and that the standard isn’t reimplemented with just minor, cosmetic changes. The AI agents must live in the corporate space, understand the business context, and know when they are touching a forbidden area. They need to comprehend the specific region they operate in, Line of Business (LoB) knowledge, country-specific regulations, and both explicit and implicit boundaries. Providing the environment where the AI can safely and effectively execute on the employee’s vision will be the real challenge.

Granted, for the corporate “overhead” — the army of consultants, developers, architects, and requirement engineers positioned between the end user and the solution — this shift is going to be a tough pill to swallow.

Look on the bright side: we are finally back to where it all started. End users can get their specific changes implemented in days, not years.