Anpassung oder Erweiterbarkeit: Wenn die Roadmap Ihres Anbieters zu Ihrem Problem wird
Die meisten Handelsunternehmen, die in den vergangenen zehn Jahren ihre Plattform gewechselt haben, waren nicht auf der Suche nach einer schickeren Benutzeroberfläche. Sie wollten Kontrolle über ganz konkrete Dinge: Wie schnell lässt sich eine neue Aktion einführen? Kann ein Checkout-Prozess geändert werden, ohne ein Support-Ticket beim Anbieter zu eröffnen? Lässt sich ein für eine Region entwickelter Filialprozess auf eine andere übertragen, ohne daraus ein zwölfmonatiges Projekt zu machen?
Kontrolle bedeutete also, die Plattform im eigenen Zeitrahmen an das Geschäft anpassen zu können. Die meisten erhielten eine Form dieser Kontrolle. Nur wenige prüften, um welche Art von Kontrolle es sich handelte.
Fast jedes Handelsunternehmen, das sich für die falsche Form von Kontrolle entschieden hat, erlebt irgendwann diesen einen Tag. Es ist nicht der Tag des Go-lives, und zunächst wirkt er selten problematisch. Es ist der Tag, an dem der Anbieter ein routinemäßiges Update ausliefert: einen Sicherheitspatch, ein neues Release oder eine dringende Compliance-Korrektur. Und irgendwo in der IT muss jemand den Satz aussprechen, den niemand hören möchte: Wir können dieses Update noch nicht einspielen. Nicht ohne zuvor wochenlang nachzuarbeiten.
An diesem Tag wird die Roadmap Ihres Anbieters zu Ihrem Problem. Nicht, weil der Anbieter etwas falsch gemacht hat, sondern wegen einer Jahre zuvor getroffenen Entscheidung darüber, wie „Kontrolle“ technisch umgesetzt wurde.
Zwei Begriffe, ein sehr kostspieliger Unterschied
Kundenspezifische Anpassung und Erweiterbarkeit werden oft so verwendet, als bedeuteten sie nahezu dasselbe: In beiden Fällen soll sich die Plattform dem Unternehmen anpassen, nicht umgekehrt. In der Praxis beschreiben sie jedoch zwei grundverschiedene Beziehungen zum Kerncode des Anbieters.
Eine kundenspezifische Anpassung bedeutet in ihrer häufigsten Form, in den Kern einzugreifen und ihn zu verändern. Eine Klasse wird überschrieben, ein Modul geforkt oder der vom Anbieter entwickelte Code so bearbeitet, dass er die heutige Anforderung erfüllt. Das fühlt sich wie Kontrolle an, denn im ersten Moment ist es genau das: Ihre Logik befindet sich direkt im Code und tut exakt, was Sie verlangt haben.
Erweiterbarkeit bedeutet etwas Präziseres und, wie sich zeigt, wesentlich Nachhaltigeres: Ihre eigene Logik wird an einem klar definierten Erweiterungspunkt ergänzt, den die Plattform genau dafür bereitstellt, ohne den darunterliegenden Kern zu verändern. Der Anbieter kann den Kern weiterhin warten und weiterentwickeln. Ihre Logik liegt daneben, nicht darin.
Am ersten Tag ist der Unterschied unsichtbar. Beide Ansätze erfüllen die aktuelle Anforderung. Sichtbar wird er erst, wenn der Anbieter den Kern verändert, in den Ihre Logik eingebaut wurde.
Was kundenspezifische Anpassungen unbemerkt kosten
Ein Fork bleibt nicht statisch. Jedes Mal, wenn der Anbieter die angepasste Plattform patcht, aktualisiert oder erweitert, muss dieses Update mit den Änderungen abgeglichen werden, die Sie am selben Code vorgenommen haben. Manchmal lässt sich alles sauber zusammenführen. Oft ist das nicht der Fall. Dann muss jemand in Ihrem Team Monate oder Jahre an Geschäftslogik manuell erneut auf eine Codebasis übertragen, die sich ohne diese Logik weiterentwickelt hat.
So kommt es, dass Handelsunternehmen Sicherheitspatches stillschweigend ablehnen, Versions-Upgrades über das Support-Ende hinaus verschieben oder ein Replatforming-Projekt budgetieren müssen, um eine Anpassung abzulösen, an deren ursprüngliche Begründung sich kaum noch jemand erinnert. Nichts davon stand im ursprünglichen Business Case. Es sind die Zinsen auf einen Kredit, von dessen Aufnahme niemand mehr weiß.
Dadurch gerät das Handelsunternehmen in eine paradoxe Lage: Je stärker es den Kern angepasst hat, desto weniger kann es von der Roadmap des Anbieters profitieren. Neue Funktionen werden ausgeliefert, lassen sich aber nicht sauber übernehmen, weil sie auf einem privaten Fork aufsetzen würden, gegen den der Anbieter nie getestet hat. Das Unternehmen hat für eine Plattform bezahlt, die sich kontinuierlich weiterentwickelt, und sich damit selbst die Möglichkeit verbaut, diese Weiterentwicklung zu nutzen.
Erweiterung: dieselbe Freiheit, ohne Fork
Die Alternative lautet nicht: „Ändern Sie nichts.“ Es geht darum, Änderungen an einer dafür vorgesehenen Stelle vorzunehmen. So müssen der sich weiterentwickelnde Kern des Anbieters und die eigene Logik des Handelsunternehmens am Upgrade-Tag nicht gegeneinander arbeiten.
Dieses Prinzip ist in der praktischen Arbeitsweise des Enactor Toolkits verankert und nicht nur eine Architekturphilosophie. Muss ein Handelsunternehmen ein bestimmtes Verhalten übersteuern, wird nicht der zugrunde liegende Prozess bearbeitet. Stattdessen steht an diesem Prozessschritt ein Erweiterungspunkt zur Verfügung. Dort entscheidet die kundeneigene Logik, ob eine eigene Variante ausgeführt oder das Standardverhalten von Enactor verwendet wird. Hält die Erweiterung das Standardverhalten weiterhin für korrekt, greift sie nicht ein und die unveränderte Anbieterversion wird ausgeführt. Ist eine Abweichung erforderlich, kann sie sauber umgesetzt werden, ohne den Prozess selbst zu verändern.
Das bedeutet, dass ein Enactor-Upgrade den Kern weiterentwickeln kann, ohne die darauf aufbauenden Erweiterungen zu beeinträchtigen, denn die Erweiterung war nie Bestandteil des veränderten Bereichs. Das Handelsunternehmen wartet weder auf die Roadmap des Anbieters noch arbeitet es gegen sie. Es entwickelt die Plattform parallel zu ihr weiter.
Dieses Prinzip zieht sich durch drei Ebenen der Plattform, nicht nur durch eine.
Konfiguration über Estate Manager
Rollenbasierte No-Code-Änderungen an Abläufen, Geschäftsregeln und Benutzeroberfläche, die ein Retail-Operations-Team selbst vornehmen kann. Kein Entwickler erforderlich.
Backend-Entwicklung über das Toolkit
Ein visueller Low-Code-Prozesseditor, in dem Entwickler die vorhandene Bibliothek mit Actions und Prozessen durchsuchen können. So verstehen sie zunächst, wie eine Funktion bereits arbeitet, bevor sie diese erweitern, statt eine Blackbox per Reverse Engineering zu entschlüsseln.
Unabhängige UI-Entwicklung, entkoppelt von der darunterliegenden Geschäftslogik
Enactor hat die Darstellung seiner eigenen Benutzeroberfläche auf React migriert, ohne die darunterliegenden Geschäftsprozesse anzupassen. Das belegt, dass beide Ebenen tatsächlich entkoppelt sind und nicht nur in einem Architekturdiagramm so beschrieben werden.
Im großflächigen Einsatz ist diese Ressourcenbibliothek keineswegs klein: Die Plattform umfasst mehrere Zehntausend vorgefertigte Actions und Prozesse. Sie wurden genau dafür entwickelt, dass Entwickler zuerst nach bereits vorhandenen Bausteinen suchen, statt mit einem Fork zu beginnen.
Warum das wichtig ist: Wer bestimmt Ihre Roadmap?
Genau hier setzt Enactor keine Grenzen, während andere Systeme einschränken. Wenn Sie erweitern, statt den Kern anzupassen, gehört das Ergebnis tatsächlich Ihnen. Es ist Ihr geistiges Eigentum, verankert an klar definierten Punkten, die Sie kontrollieren, und in Ihrem eigenen Zeitrahmen upgradefähig. Es ist nicht an einen Fork gebunden, der mit jedem Anbieter-Release weiter veraltet, das sich nicht sicher einspielen lässt.
Die Handelsunternehmen, die „diesen Tag“ vermeiden, sind nicht jene, die am wenigsten angepasst haben. Es sind jene, die klar festgelegt haben, wo ihre Logik liegt: nie im Kern des Anbieters, sondern immer an dem Punkt, an dem die Plattform für ihre Aufnahme entwickelt wurde. Diese Weichenstellung erfolgt früh in der Architektur der Plattform. Und sie entscheidet, ob Ihnen die Roadmap Ihres Anbieters einfach vorgegeben wird oder ob Sie diese aktiv mitgestalten können.
Mehr erfahren
Enactor ist die Unlimited Unified Commerce Plattform, die Handelsunternehmen durch flexible Konfiguration, Integration und Erweiterung handlungsfähig macht. Nehmen Sie Kontakt mit uns auf und erleben Sie, wie Toolkit und Estate Manager in der Praxis funktionieren.
