Vor einigen Jahren beschloss ein Industrieunternehmen, sein ERP zu modernisieren. Ein 18-Monate-Projekt, ein siebenstelliges Budget, ein bekannter Integrator. Das IT-Team dokumentierte das Bestehende, listete die Funktionen auf, migrierte Modul für Modul. Pünktlich abgeliefert. Unzufriedene Nutzer. Prozesse genauso schwerfällig — auf einer neuen Plattform.
Das war kein IT-Versagen. Es war ein Methodenversagen.
Das Symptom — und wie man es erkennt
“Das können wir nicht tun. Das System unterstützt es nicht.”
Wenn Sie diesen Satz in Ihrer Organisation gehört haben, kennen Sie das grundlegende Problem. Ihre Geschäftsprozesse haben sich schrittweise an Ihre IT-Einschränkungen angepasst. Nicht umgekehrt. Was ein Werkzeug hätte sein sollen, ist zur Referenz geworden: Das System bestimmt, wie Sie arbeiten — nicht Ihr Unternehmen, das bestimmt, was das System tun soll.
Das aufschlussreichste Zeichen liegt in der Sprache.
Ich arbeitete mit einem Beratungsunternehmen, bei dem alle über “Zeiterfassung” sprachen — ein einziges Konzept in ihrem System. Als wir es in einer Domainmodellierungsübung genauer untersuchten, entdeckten wir, dass es mindestens drei unterschiedliche Geschäftsanforderungen abdeckte.
HR betrachtete diese Zeiten für Gehaltsabrechnung und Talentmanagement. Der Projektmanager betrachtete sie, um die Vertragsrentabilität zu steuern. Der Ressourcenleiter betrachtete sie, um unterausgelastete Berater zu identifizieren und Teams neu auszubalancieren — Überlastete zu entlasten, Verfügbare einzusetzen.
Drei Anwendungsfälle. Drei Granularitäten. Drei verschiedene Zeitlinien. Aber weil das System nur ein einziges Konzept kannte, hatte niemand jemals diese künstliche Einheit in Frage gestellt. Wir erkannten am Ende der Übung, dass HR und der Ressourcenleiter nicht dieselben Daten benötigten. Das System hatte sie in der Illusion gehalten, über dasselbe zu sprechen.
Wenn Ihr Team das Vokabular Ihres Systems verwendet, um Ihre Geschäftswirklichkeit zu beschreiben, ist die Kontamination vollständig.
Der klassische Fehler bei Modernisierungsprojekten
Wenn ein Unternehmen beschließt zu modernisieren, ist die erste Frage fast immer dieselbe: “Was haben wir?”
Das IT-Team wird einberufen, das Bestehende wird auditiert, Funktionen werden aufgelistet, Abläufe werden kartiert. Dann werden die Integratoren gefragt: “Wie migrieren wir das?”
Das Ergebnis ist vorhersehbar: ein neues System, das die Organisation des alten reproduziert. Neuer Stack, gleiche Einschränkungen. Neuer Vertrag, gleiche Frustration. Das Budget wurde ausgegeben, das Projekt wurde abgeliefert — aber das grundlegende Problem wurde nie adressiert.
Vom Bestehenden auszugehen, um die Zukunft zu definieren, garantiert, dass die Zukunft wie die Gegenwart aussieht.
Problemraum und Lösungsraum — die Unterscheidung, die alles verändert
Es gibt zwei fundamental unterschiedliche Fragen in einem Modernisierungsprojekt.
Die erste: Was muss Ihr Unternehmen wirklich tun? Was sind Ihre echten Geschäftsregeln — die aus Ihren regulatorischen Anforderungen, Ihrer Wertschöpfungskette, Ihren Kunden resultieren? Unabhängig davon, wie Ihr aktuelles System funktioniert.
Das nennt man den Problemraum: die Realität Ihrer Geschäftsdomäne, befreit von technischen Einschränkungen. “Zeiterfassung” existiert nicht im Problemraum. Es gibt Gehaltsabrechnung, Vertragssteuerung und Ressourcenzuweisung — drei unterschiedliche Konzepte mit ihren eigenen Regeln, ihren eigenen Stakeholdern, ihren eigenen Datenanforderungen.
Die zweite: Wie wird Technologie diese Realität bedienen? Mit welchen Systemen, Integrationen, Budget- und Machbarkeitsbeschränkungen? Das ist der Lösungsraum: die Zielarchitektur mit ihren realistischen Kompromissen.
Die Reihenfolge ist nicht verhandelbar. Problemraum zuerst. Lösungsraum danach. Das Umgekehrte erzeugt Systeme, die Verwirrung fortführen anstatt sie zu lösen.
Warum die Reihenfolge fast immer umgekehrt ist
IT-Teams beginnen mit dem, was sie kennen. Das ist menschlich. Das Bestehende zu dokumentieren ist greifbar, beruhigend, abrechenbar. Zu modellieren, was das Unternehmen tun sollte — unabhängig davon, was es heute tut — ist unbequem und wird oft als theoretisch wahrgenommen.
Anbieter und Integratoren werden nicht dazu angereizt, diese Frage zu stellen. Sie sind beauftragt, ein System zu liefern, nicht Anforderungen zu hinterfragen. Je komplexer das Bestehende, desto teurer die Migration.
Und das Unternehmen selbst hat Schwierigkeiten, seine Bedürfnisse außerhalb seiner aktuellen Einschränkungen zu formulieren. Wenn man einen Betriebsleiter fragt “Wie sollte Ihr Prozess idealerweise funktionieren?”, beginnt die Antwort fast immer mit “Also, was wir derzeit machen ist…”. Die Geschäftsdomäne wurde nie formalisiert. Sie lebt in Gewohnheiten, in Workarounds, in internen Schulungen. Und im Vokabular des Systems.
Was das in der Praxis verändert
Ich arbeitete an einem Modernisierungsprojekt, bei dem wir drei Monate damit verbrachten, die Geschäftsdomäne zu modellieren, bevor wir irgendetwas im bestehenden System anfassten. Drei Monate, die bei jedem Lenkungsausschuss fast aus dem Plan gestrichen wurden. “Wir verlieren Zeit.”
Was wir entdeckten: Ein erheblicher Teil der “Einschränkungen”, die das IT-Team als feststehende Tatsachen betrachtete, waren in Wirklichkeit Geschäftsregeln, die nie formalisiert worden waren — manchmal im Widerspruch zu dem, was die operativen Teams tatsächlich taten. Ganze Anwendungsfälle im aktuellen System unsichtbar, nicht weil sie nicht existierten, sondern weil sie so lange umgangen worden waren, dass sie unsichtbar geworden waren.
Der endgültige Migrationsplan war grundlegend anders als das, was wir produziert hätten, wenn wir vom Bestehenden ausgegangen wären. Weniger Module zu migrieren. Mehr Wert in den ersten zwölf Monaten. Weniger technische Schulden von Anfang an.
Die Domäne ohne Legacy-Einschränkungen zu modellieren ist kein Fehler. Es ist die Voraussetzung, um zu wissen, welche Einschränkungen wirklich wichtig sind.
Also, konkret
Vor Ihrem nächsten Modernisierungsprojekt eine Frage an Ihr Team oder Ihren Anbieter: “Womit beginnen Sie — mit dem, was wir haben, oder mit dem, was wir tun müssen?”
Wenn die Antwort mit dem Audit des Bestehenden beginnt, ist das Risiko da.
Ein Projekt, das von der Geschäftsdomäne ausgeht, braucht am Anfang mehr Zeit. Es liefert weniger Verwirrung auf Dauer, weniger Überarbeitungen sechs Monate nach dem Go-live, und ein Ergebnis, das Ihrem Unternehmen dient — nicht Ihrem IT-System von 2014.
Das ist das Erste, was ich in jedem Architektur Assessment tue: die Domäne modellieren, bevor ich irgendetwas vorschlage.
Wenn Sie CTO statt CEO sind und diese Disziplin unter Delivery-Druck managen, dieser Artikel behandelt die spezifische Falle für Teams in der Ausführungsphase →