7 Dinge, die ich beim Aufbau von Enterprise-Plattformen für Deutschlands größte Unternehmen gelernt habe

Zehn Jahre, sieben der größten Unternehmen Deutschlands, dreistellige Millionenbeträge, die durch Systeme fließen, an denen ich mitgebaut habe. Das meiste lief anders, als ich es ans Whiteboard gemalt hatte, und in dieser Lücke zwischen Plan und Wirklichkeit stecken die Lektionen.

Als ich zu E.ON Digital Technology kam, war die Monitoring-Landschaft auf sechs Tools angewachsen: eines für IT, eines für OT, eines pro Geschäftsbereich und zwei, an deren Einführung sich niemand mehr erinnern konnte. Das Symptom zeigte sich bei jeder Störung. Wir gingen in den Incident-Call und verbrachten die ersten zehn Minuten mit der Frage, welchem Dashboard wir überhaupt glauben.

Alle wollten das siebte Tool bauen, das die anderen sechs endlich ablöst. Haben wir nicht. Wir haben das Bestehende zu einer einzigen Observability-Plattform auf OpenTelemetry zusammengeführt, über IT, OT und Netz hinweg. Weniger Tools war das sichtbare Ergebnis. Das eigentliche war, dass die Diskussion aufhörte: gemeinsames Alerting, eine Quelle der Wahrheit, schnellere Erkennung.

Ich habe den Reflex, alles neu zu bauen, oft genug erlebt, um ihm zu misstrauen. Der Hebel liegt fast immer darin, das zu verbinden, worauf sich die Teams ohnehin verlassen, nicht darin, ihnen noch etwas zum Lernen hinzustellen.

Bei Allianz konnte das Bereitstellen einer neuen Cloud-Umgebung über ein Jahr dauern. Die Ingenieure waren nicht langsam. Jede Umgebung brauchte manuelle Genehmigungen, handgestrickte Netzwerkkonfiguration und den Weg durch eine Ticket-Warteschlange, die kein Team wirklich verantwortete, also blieben Anfragen einfach liegen.

Wir haben das für Standard-Umgebungen auf Tage gedrückt, indem wir Provisioning als eigenständiges Produkt behandelt haben: Self-Service-Templates, Infrastructure-as-Code in einer Hub-Spoke-Architektur, Compliance-Prüfungen direkt in der Pipeline statt nachträglich im Review. Die Ingenieure standen nicht mehr in der Warteschlange, sie nutzten die Umgebungen.

Wenn interne Nutzer Tage auf etwas warten, das die Plattform in Minuten liefern sollte, liegt der Flaschenhals selten an der Ops-Kapazität. Er liegt daran, dass niemand ihr Warten als ein Problem behandelt hat, das es zu beseitigen lohnt.

Die Bundesdruckerei betreibt Identitätsinfrastruktur für die Bundesverwaltung unter KRITIS, der strengsten Stufe im deutschen Infrastrukturrecht. Der Reflex, gerade bei Beratern, ist, das als Bremse zu behandeln. Bei mir war es das Gegenteil.

Unter KRITIS hatte jede Architekturentscheidung einen eingebauten Ja-Nein-Test: Erfüllt das die regulatorische Vorgabe? Einschränkend, ja, aber es beendet auch die endlosen Diskussionen. Niemand verhandelt eine Anforderung neu, die im Gesetz steht. Du legst dich einmal darauf fest und machst weiter. Und ein System, das ein KRITIS-Audit übersteht, hält fast per Definition auch echter Enterprise-Last stand.

Eine harte Vorgabe verkleinert den Raum dessen, was du bauen darfst, und genau deshalb fallen die Entscheidungen schneller, solange sie das Design vom ersten Entwurf an prägt und dir nicht erst beim Audit begegnet.

Die Volkswagen Group wollte fünf Marken (VW, Audi, Skoda, Seat, Porsche) auf einem Commerce-Backbone: über eine Million Nutzer, mehrere Länder und Sprachen, getrennte rechtliche Einheiten mit je eigener P&L.

Das Engineering war die machbare Hälfte. Die schwierige war politisch. Jede Marke war überzeugt, ihre Customer Journey sei ein Sonderfall, und jede Markenführung musste aus dem Projekt mit dem Gefühl herausgehen, die Kontrolle darüber nicht abgegeben zu haben.

Also haben wir genau dafür gebaut. Ein WhiteLabelFrontEnd auf einem MonoRepo ließ jeder Marke einen sichtbar eigenen Storefront, während die Commerce-Schicht darunter geteilt blieb. Die Architektur folgte der Verhandlung, nicht umgekehrt, und dass am Ende über 1 Mio. Nutzer auf einer Plattform liefen, hing ebenso am Abschluss dieser Verhandlung wie an allem, was wir technisch geliefert haben.

Wenn du für Stakeholder baust, die leise miteinander konkurrieren, muss jeder von ihnen etwas im Design finden, auf das er zeigen und sagen kann: Das gehört mir.

Bei Nelly Solutions hielten wir die monatliche MRR-Churn-Rate bei 0,7 % über mehr als 1.200 Arztpraxen. Für Healthcare-SaaS ist das niedrig genug, dass manche annahmen, wir würden falsch messen.

Tatsächlich kam es daher, dass wir früher hingeschaut haben. Eine Praxis, die kurz vor der Kündigung steht, verrät es dir meist Wochen vorher in den Daten: Logins werden seltener, Support-Tickets häufen sich, ganze Features verstummen. Wir haben die Erkennung um diese Signale herum gebaut und gefährdete Accounts markiert, solange noch Zeit zum Handeln war, statt zu warten, bis eine NPS-Umfrage bestätigt, was längst verloren ist.

Wenn dein erster Impuls bei steigendem Churn ein neues Feature ist, behandelst du meist ein Symptom. Der Hebel liegt in dem, was deine Daten über einen Kunden schon wissen, bevor er sich zum Gehen entscheidet.

Bei Telefónica schlossen 21 % der Warenkorbabbrecher ihren Kauf innerhalb von 30 Tagen doch noch ab. Im Rückblick klingt das banal (klar, hak nach, wenn jemand einen vollen Warenkorb stehen lässt), aber die Zahl kam nicht daher, das Offensichtliche lauter zu tun.

Die Marketing-Cloud-Integration musste schnell, zuverlässig und DSGVO-sauber sein, und in Deutschland ist das die Untergrenze, kein Nice-to-have. Statt jeden anzuschreiben, der abgesprungen ist, haben wir eine KI-gesteuerte Sequenz gebaut, die den Versandzeitpunkt jeder Nachricht optimiert. Die 21 % waren ein Ergebnis von Timing und Zielgenauigkeit; mehr E-Mails hätten sie nach unten gezogen.

Wer angefangen hat zu bestellen und dann aufhört, hat dir bereits gesagt, dass er interessiert ist. Diesen zweiten Blick zurückzugewinnen ist meist mehr wert als noch eine Optimierungsrunde am oberen Ende des Funnels.

Bei Gesund.de habe ich am PaaS hinter einem Digital-Health-Marktplatz mitgebaut: 417 Mio. € Rx-Umsatz, die darüber laufen, ML-Personalisierung der Empfehlungen, Rezeptabläufe, die über mehrere Märkte hinweg regelkonform blieben.

Nichts davon ist für die Leute sichtbar, die die Seite nutzen. Sie tippen auf einen Button, bekommen eine Empfehlung, das Rezept geht durch. Die ML-Pipeline, der regulatorische Workflow, die PVS-Integrationen, die Compliance-Schicht je Markt, all das liegt hinter einem vollkommen unauffälligen Klick.

Das ist der ganze Sinn. Je besser die Plattform, desto weniger Grund hat irgendwer, der sie nutzt, über sie nachzudenken. Der Tag, an dem deine Nutzer dir deine Infrastruktur beschreiben, ist der Tag, an dem darunter etwas zu lecken begonnen hat.

---

Wenn eines dieser Muster nach dem aussieht, womit du dich gerade herumschlägst, tausche ich mich gern darüber aus. Buche einen 30-Minuten-Call und erzähl mir, was du baust.