Concept

Standard Software Is Dead

The dominance of standard software like SAP and Salesforce was built on the high cost of custom development. As AI and 'vibe coding' make custom solutions affordable, this foundation is collapsing, rendering the rigid 'process standard' obsolete while making the underlying 'technical standard' of data consistency and system integration more critical than ever.

Why is the traditional concept of 'standard software' becoming obsolete, and what architectural principle is replacing it?

  • Cost Argument Collapse — The primary justification for standard software was its lower cost compared to custom development. With advancements like AI and 'vibe coding,' the cost of custom solutions has significantly decreased, eroding this foundational argument.
  • Process Rigidity — Traditional standard software imposed rigid 'process standards,' forcing companies to adapt their unique operational processes to the software's inherent logic. This often led to compromises rather than optimal business practices.
  • Increased Flexibility Needs — Businesses increasingly demand the ability to design processes tailored to their specific market logic, customer needs, and competitive advantages, rather than being constrained by generic, pre-defined software templates.
  • Rise of Technical Standard — While the 'process standard' is diminishing, the underlying 'technical standard'—focused on data consistency, system interoperability, and reliable integration points—is becoming paramount. This principle emphasizes a stable foundation for flexible process design.
  • standard software
  • custom development
  • AI agents
  • process standard
  • technical standard
  • SAP
  • Salesforce
  • vibe coding

Auf LinkedIn lesen →

Markdown-Version (zitierfähig)

The Standard We Knew Is Dead — What Comes Next Is More Important

Why the principle of standard software must be rethought — and what this means for SAP, Salesforce, and AI agents

Why Standard? An Uncomfortable Answer

Why standard software in the first place? The question sounds provocative — but it is not. It is legitimate.

The argument for standard software was never romantic. It was pragmatic. SAP, Salesforce, and their competitors did not prevail because their process templates were superior to what companies could have built themselves. They prevailed because custom development, at scale, simply did not work. Too expensive, too slow, too maintenance-intensive. Projects exploded in budget. Systems became unmaintainable. And with every new requirement, technical debt grew.

Standard won — not because it was always better, but because the alternative was worse. That is an important distinction. It means: the argument for standard software was, from the very beginning, a cost argument. Not a quality argument.

The Classic Equation: Process Follows Software

What followed, we know from practice. Companies spent millions and years not improving their processes — but adapting them to the software. In the best case, genuine standardisation and efficiency emerged. In the worst case, competitive advantages were levelled because the company ended up operating exactly like every competitor using the same software.

The promise that “best practice is built in” was never as clear as it sounded. Best practice for whom? For which industry, which company size, which market? Standard processes are, by definition, compromises. That is not a criticism — it is the nature of the model.

Nevertheless, it worked. For decades. Because the alternative — genuine custom development — was simply not competitive.

What AI Is Changing Now — The Cost Argument Collapses

This is where the real story begins.

Vibe coding, AI-driven development, large language models generating process logic — all of this is changing one fundamental variable: the cost of custom development. What used to require months and entire teams now emerges in days. What was once prohibitively expensive is becoming affordable.

The foundation of the standard argument is eroding. If custom is no longer more expensive than standard — why still adapt processes to the software?

The question is being raised — and it is growing louder in projects. The temptation is understandable. What gets overlooked is that the cost argument was never the only one. It was just the loudest.

The Process Standard Dies — And That Is Right

The process standard — the idea that a company should align its order-to-cash process with SAP logic, or shape its sales process according to the Salesforce blueprint — is losing relevance. Not because the software is poor. But because companies are increasingly able to design processes the way they see fit — not the way the software prescribes.

This is not a threat. It is an opportunity. The process standard was always a compromise — a template that suited many, but was perfect for none. A company that is today able to design its sales process truly according to its own market logic, its service process according to the genuine needs of its customers — that company should use this freedom.

What must not die, however, is the foundation beneath it. And here lies the decisive distinction that is almost always missing from the current debate.

What Remains — And Becomes More Important Than Ever

Regardless of how flexibly processes are designed in future — systems must talk to each other. Data must be consistent. Handover points between systems must function reliably. This is not a process prescription. It is a technical necessity. And it was always there — hidden beneath the process standard, which delivered both in one package.

The tension is well illustrated by a practical example: offer creation in B2B sales.

Sales wants flexibility. Customer-specific configurations, situational pricing, special agreements — all of this is legitimate and often necessary to win complex industrial deals. Salesforce and CPQ solutions provide the necessary room today.

At the same time, there are boundaries that are non-negotiable: product catalogue governance, price floors, discount approvals. And at the end, every offer must land in SAP as an order — in standardised structures that the ERP understands. Materials, condition types, pricing logic. No special format, no exception.

This illustrates precisely what remains when the process standard falls: not nothing — but the foundation. The interface to SAP is not a process prescription. It is a technical necessity. The offer strategy upstream is individual — and should be.

Those who fail to cleanly separate these two layers get neither right. Either the CRM side becomes so standardised that sales has no genuine room to manoeuvre. Or the flexibility on the CRM side generates data structures that SAP cannot process — and the order lands in the system with manual corrections.

AI agents do not change this principle — they confirm it. An agent supporting the sales representative in the offer process works within the defined process framework. It enriches that framework — with competitive intelligence, negotiation strategy, customer history. It does not replace the process. It needs the foundation.

Conclusion — The New Question

For decades, the central question in digitalisation projects was: do I adapt my process to the standard — or do I build something of my own?

That question has been answered. The standard it refers to no longer exists in this form.

The new question is: what is foundation — and what is design space? Which layers of my system landscape must be stable and consistent so that genuine flexibility can emerge above them? And which layers may — indeed should — be individually shaped?

This is no longer a question of standard versus individual. It is a question of conscious architecture. Of decisions that companies must make today — before AI capabilities are expected to build on a foundation that was never designed for them.

The standard we knew is dead. What comes next has no established name — but it matters more than ever.

Daniel Gorld

Consulting Director, cbs CX (The cbs Group Salesforce Consultancy)

Daniel Gorld is a B2B CX and process consultant and Consulting Director at cbs CX (The cbs Group Salesforce Consultancy) with over 20 years of experience in industrial B2B.

Mehr über DanielLinkedIn →

Related

Published · Updated