Fast meine gesamte Laufbahn hindurch hörte ich in Vorstandsrunden und Software-Demos denselben Rat: „Configure, don’t customize.“
Das klang vernünftig. Customizing galt als teuer, schwer zu betreuen und angeblich als Grund dafür, dass so viele Enterprise-Software-Projekte ihre Versprechen nicht einlösten. Wenn Kunden innerhalb der Grenzen der Software bleiben könnten, würden alle profitieren.
Nach Jahrzehnten in der Enterprise-Software bin ich zur gegenteiligen Überzeugung gelangt. „Configure, don’t customize“ ist eine der irreführendsten Aussagen der Branche, denn am Ende führt jeder Weg zu Customizing.
Was ich über Enterprise Software gelernt habe
In meinen Führungspositionen bei Siebel, Oracle und Salesforce war es mir wichtig, möglichst viele Kunden aus der Konsumguterbranche zu treffen, um zu verstehen, wie sie unsere Technologie nutzten und wo sie Mehrwert schuf.
Diese Gespräche haben mir viel über Design, Verkauf, Implementierung und Support von Enterprise Software beigebracht. Doch obwohl meine Kunden meine Beiträge schätzten, fühlte sich etwas nicht richtig an. Sie erzielten mit ihren Softwareinvestitionen einen akzeptablen ROI, aber er war bei Weitem nicht so hoch, wie ich es für möglich hielt oder wie es in den Projektbegründungsunterlagen versprochen worden war.
Trotz der Fortschritte bei Cloud Computing, Software-as-a-Service (SaaS) und modernen Entwicklungsplattformen blieben die Implementierungskosten meiner Kunden hoch. Sie wehrten sich weiterhin gegen Upgrades und fügten der gekauften Software nach wie vor umfangreiche Anpassungen hinzu.
Aus diesem Grund kann ich mein Lebenswerk nur mit 6 von 10 Punkten bewerten - doch das könnte sich gerade ändern. Mit KI-gestützter Entwicklung und dem Aufstieg des Vibe Coding könnte die Branche endlich die Chance haben, diesen Kreislauf zu durchbrechen.
Wie Enterprise Software im Lauf der Jahre besser geworden ist - und wie nicht
Mit der Zeit erkannte ich, dass das Problem nicht darin lag, dass Kunden, Softwareanbieter oder Systemintegratoren (SIs) versagten.
Die Anbieter sagen vielleicht, den SIs fehle die richtige Schulung; die SIs behaupten möglicherweise, die Software könne zentrale Geschäftsanforderungen nicht unterstützen; und den Kunden wird vorgeworfen, sie hätten zu wenig Ressourcen oder unklare Prioritäten. Meist steckt auf allen Seiten ein Körnchen Wahrheit. Tatsächlich versucht Enterprise Software aber seit jeher, ein nahezu unlösbares Problem zu lösen: Jede Branche ist anders, und je näher Software an die Realität organisationaler Abläufe heranrückt, desto schwieriger wird es, Customizing zu vermeiden.
Die Software selbst bleibt die größte Herausforderung. Im Lauf der Jahre hat sich die Softwareentwicklung so weit verbessert, dass wir heute browserbasierte Anwendungen haben, die sich deutlich einfacher entwickeln und bereitstellen lassen als die früheren clientbasierten Modelle. Das SaaS-Geschäftsmodell hat den Kapitalaufwand reduziert, und die Cloud hat es überflüssig gemacht, Server zu kaufen, zu konfigurieren und zu warten. Die Kosten für Implementierung, Support und Upgrades sind jedoch kaum gesunken.
Die gefürchteten Software-Upgrades
Viele Menschen sagen, Updates für Cloud-Software seien heute mühelos, weil sie automatisch an Kunden ausgerollt werden. Das stimmt nur teilweise. Anbieter stellen neue Funktionalitäten typischerweise über verpflichtende Releases bereit, während Fehlerbehebungen an bestehenden Funktionen oft optional sind, weil sie Kundenanpassungen beeinträchtigen können. Daher verschieben manche Organisationen solche Updates über Jahre, weil Kosten und Risiken zu hoch sind. Viele vermeiden Upgrades sogar vollständig, bis der Support für ihre aktuelle Version endet.
IT-Teams konfigurieren häufig anspruchsvolle Erweiterungen, um komplexe geschäftliche Herausforderungen zu lösen. In vielen Fällen waren die Innovationen meiner Kunden so gut, dass sie sogar meine nächsten Produktdesigns inspirierten. Wenn Softwareanbieter jedoch neue Funktionen ausrollen, stellen Kunden fest, dass sie jahrelange Konfigurationen zurücknehmen müssen, bevor sie die neuen Funktionen nutzen können. Deshalb entscheiden sich viele dafür, ihre angepassten Lösungen beizubehalten, selbst wenn Anbieter vergleichbare Funktionalität liefern.
Wie Softwareanbieter technische Schulden erzeugen
Wenn ein Produktteam Schwachstellen in einem bestehenden Design entdeckt, kann es das Problem oft nicht einfach beheben. In Cloud-Umgebungen können Änderungen an Kernfunktionen die Anpassungen der Kunden stören. Stattdessen bauen Produktmanager häufig völlig neue Versionen einer Funktion neben den alten Versionen auf und ermöglichen Kunden, sie über Konfigurationseinstellungen zu aktivieren.
Das Duplizieren von Funktionalität schützt Kunden vor unbeabsichtigten Störungen, erzeugt aber auch technische Schulden. Mit der Zeit wird die Software durch veraltete Funktionen, ungenutzte Objekte und schwer verständliche Konfigurationsoptionen aufgebläht. Implementierungsberater sind am Ende unsicher, welche Version einer Funktion aktuell ist. Auch die Performance kann leiden, und Produktteams verbringen ihre Zeit damit, alte Designs zu warten, statt zu innovieren.
Selbst einfache Fehlerbehebungen können kompliziert sein. Ein Kunde hat möglicherweise bereits einen Workaround für einen Fehler gebaut, und die Fehlerbehebung könnte diesen Workaround unbeabsichtigt brechen. Wie auch immer entschieden wird: Irgendjemand bleibt frustriert zurück.
Produktmanager träumen davon, Funktionalitäten zu entwickeln, die Branchen verändern. Stattdessen verbringen sie einen großen Teil ihrer Zeit damit, Backlogs zu verwalten, Fehler zu beheben und Upgrade-Kompatibilität zu sichern. Ressourcen sind begrenzt und Release-Zeitpläne ambitioniert. Selbst wenn Genehmigung und Finanzierung für echte Innovation kommen, sind Teams am Ende dennoch unterfinanziert und mit unrealistischen Zeitplänen konfrontiert - weil sich das, was alle für eine einzelne Funktion hielten, als ein Funktionsbereich mit hundert Varianten herausstellt.
Die Herausforderung branchenspezifischer Funktionalität
Dass jeder Weg zu Customizing führt, wird offensichtlich, sobald ein Produktmanager beginnt, Anforderungen zu sammeln.
Vielleicht startet er mit Interviews mehrerer Account Manager seines größten Retail-Kunden - nur um festzustellen, dass jeder von ihnen ganz anders arbeitet. Von dort aus wächst die Komplexität weiter. Convenience-, Wholesale- und indirekte Kanäle haben jeweils eigene Anforderungen. Geschäftspraktiken unterscheiden sich stark von Markt zu Markt. Kleine Konsumguterunternehmen (CPG) stehen vor besonderen Herausforderungen. Regulierte Branchen wie Alkohol und Tabak bringen eine weitere Komplexitätsebene ein. Unternehmen mit Direct Store Delivery oder Van-Sales-Modellen arbeiten wieder anders, und B2B-Organisationen, die an Hotels, Restaurants und Cafes verkaufen, haben nochmals eigene Bedarfe.
Nach kurzer Zeit ist aus einer einzelnen Anforderung eine Vielzahl legitimer Geschäftsszenarien geworden. Nun steht der Produktmanager vor schwierigen Abwägungen: Soll er eine hochflexible Plattform bauen, mit der Kunden die letzte Meile selbst ausgestalten können; sich intensiv auf wenige Use Cases konzentrieren und Kunden die verbleibenden Use Cases selbst aufbauen lassen; oder einen Kompromiss verfolgen, der eine Bandbreite von Szenarien teilweise abdeckt?
Keiner dieser Ansätze beseitigt den Bedarf an Customizing. Eine flexible Plattform verlangt von Kunden, eigene Prozesse zu konfigurieren. Eine hochspezialisierte Lösung lässt zwangslaufig Lücken, die Kunden selbst schließen müssen.
Deshalb kam ich schließlich zu dem Schluss, dass „Configure, don’t customize“ irreführend war. Moderne Enterprise-Plattformen sind so fortschrittlich, dass technisch gesehen alles Konfiguration ist. Kunden können komplexe Workflows, Geschäftsregeln, Datenbeziehungen und Automatisierungen erstellen, ohne Code zu schreiben. Aus Upgrade-Sicht sind diese Konfigurationen jedoch genauso problematisch wie codebasierte Anpassungen.
Die grundlegende Herausforderung bleibt dieselbe: Kein Softwareanbieter kann alle Arten vorhersehen und vorkonfigurieren, wie eine Organisation arbeiten muss.
Der Eintritt ins Zeitalter des Vibe Coding
Der Aufstieg von „Vibe Coding“-Tools - also der Einsatz von KI, um Software vor allem auf Basis natürlichsprachlicher Anweisungen zu generieren und zu verfeinern - verändert Enterprise Software grundlegend. Produktteams können Funktionalitäten heute deutlich schneller entwickeln, und auch Kunden können Last-Mile-Fähigkeiten schneller und sicherer aufbauen.
Daraus ergibt sich eine grundlegende Frage für die Branche: Wenn Softwareanbieter mithilfe KI-gestützter Entwicklung nun hundert mögliche Geschäftsszenarien ausbauen können, wird das, was sie bauen, genauso gut sein wie das, was Kunden selbst konfigurieren können?
Ich glaube, Softwareunternehmen werden einen von zwei Wegen einschlagen. Einige werden noch stärker darauf setzen, hochdetaillierte Lösungen für möglichst viele Use-Case-Szenarien zu entwickeln. Wenn das gelingt, schaffen sie nahezu narrensichere Software, für deren Implementierung nur wenig Geschäftsprozess-Expertise nötig ist. Wenn sie scheitern, entsteht Software, die sich nicht neu konfigurieren lässt, schwer zu erweitern und teuer zu aktualisieren ist.
Andere werden noch stärker auf Plattformen setzen, die es Kunden leicht machen, ihre eigene Last-Mile-Funktionalität exakt nach ihren Vorstellungen aufzubauen. Diese Kunden werden schnell Funktionalität entwickeln können, die ihnen einen Wettbewerbsvorteil verschafft. Sind die Anforderungen jedoch zu komplex, bauen sie am Ende möglicherweise ein System, das schlicht nicht funktioniert.
Ein neuer Fokus auf Accelerators
Um das Risiko des Plattformansatzes zu reduzieren, werden SIs meiner Ansicht nach verstärkt auf den Aufbau von Accelerators setzen. Diese waren weniger in Mode gekommen, als Softwareunternehmen Konfiguration gegenüber Customizing in den Vordergrund rückten, doch KI könnte diesen Trend umkehren.
Der große Vorteil von Accelerators gegenüber vorkonfigurierter Anbieterfunktionalität besteht darin, dass sie neu konfiguriert werden können, während Anbieterfunktionalität gesperrt sein muss. Das ist wichtig, denn schon eine falsche Formel in tausend Codezeilen eines Softwareanbieters kann einen ganzen Funktionsbereich unbrauchbar machen. Bei einem Accelerator eines SI lässt sich diese Formel hingegen leicht bearbeiten.
Das ist ein entscheidender Vorteil des Plattform- oder Accelerator-Ansatzes gegenüber vorkonfigurierten Lösungen von Softwareanbietern.
Was bedeutet das heute für uns?
Organisationen, die heute Enterprise Software kaufen, stehen vor einer schwierigen Entscheidung: auf spezialisierte, branchenspezifische Funktionalität von Softwareanbietern warten oder KI-gestütztes Coding nutzen und eigene, hochgradig zugeschnittene Lösungen entwickeln - möglicherweise mithilfe eines Accelerators.
So oder so könnte die Enterprise-Software-Branche endlich an einen Punkt gelangen, an dem sie den seit Jahrzehnten versprochenen geschäftlichen Mehrwert liefern kann - nicht indem sie Customizing abschafft, sondern indem sie es annimmt.
Wenn das passiert, kann ich meine Karrierebewertung vielleicht endlich von 6 auf 10 Punkte anheben.
- LESEN SIE AUCH: Retail Media: Der Wachstumsmotor mit 100 Milliarden US-Dollar, den Retailer nicht ignorieren können
IHR NÄCHSTER SCHRITT
Lesen Sie mehr darüber, wie NTT DATA Sie dabei unterstützt, die Zukunft von Retail und Konsumgütern neu zu denken - mit Technologie und Expertise für nahtlose, personalisierte und nachhaltige Einkaufserlebnisse.