„Enterprise Architecture Management? Klingt für viele immer noch wie ein rein IT-getriebenes Governance-Thema – bis der Veränderungsdruck so gross wird, dass keiner mehr drum herum kommt.“
So sieht es nun mal in vielen Unternehmen aus und die Pain Points sind deutlich:
- Unterschiedliche IT-Systeme in jedem Geschäftsbereich
- Redundante Prozesse, die nicht zusammenpassen
- Strategische Initiativen, die ins Leere laufen– weil niemand weiss, wo im Unternehmen eigentlich was passiert
Die Geschäftsleitung hat dann den Wunsch: „Wir wollen skalierbare Digitalisierung – ohne von unserer Komplexität erdrückt zu werden.“
Was meine Antwort darauf sein könnte:
Enterprise Architecture als Brücke zwischen Business und IT.
Aber eben nicht als abstraktes Modell – sondern als konkret navigierbares Steuerungsinstrument.
Fangen wir mal an: Mit Fragen statt Frameworks
Wir starteten nicht mit TOGAF, ArchiMate oder einer endlosen Capability Map.
Sondern mit drei simplen Fragen an die Verantwortlichen:
- Welche Kernprozesse bringen euch Umsatz und wie sieht das Mengengerüst aus?
- Welche Applikationen hängen daran?
- Was funktioniert – und was bremst die Prozesse und die Organisation?
- Welches sind eure konkreten Ziele und wie habt ihr vor diese zu erreichen?
Innerhalb von ca. 6 Wochen entstehen daraus ein erstes, strukturiertes Modell:
- Eine Übersicht über Prozesse, Applikationen und Verantwortlichkeiten
- Sichtbar machen: Redundanzen, Schatten-IT und veraltete Kernsysteme
- Erste Quick Wins werden greifbar – z. B. das Abschalten von drei eigenständigen Excel-„Lösungen“, die exakt das Gleiche taten oder zwei unterschiedliche Prozessmanagement-Tools mit praktisch identischen Funktionalitäten.
Der Wendepunkt: Strategie operational machen
Was vorher als „strategisches Zielbild“ durch PowerPoints geisterte, wird jetzt konkret:
Wir verknüpfen die Unternehmensstrategie mit der Architektur – top-down UND bottom-up:
- Welche Business Capabilities brauchen wir wirklich in 2 Jahren?
- Welche Prozesse müssen verändert werden?
- Was muss dafür auf Applikationsebene verändert werden?
- Welche Systeme behindern mehr als sie nützen?
Ein konkretes Beispiel: Die Einführung eines neuen CRM-Systems.
Früher: Entscheidung aus dem Bauch heraus.
Jetzt: Basierend auf einem konsolidierten Architekturmodell, das zeigte, wo Kundendaten wie verarbeitet werden – und was das neue System wirklich können muss.
Mehr Klarheit, weniger Frust
Nach 6 Monaten:
- Transparenz über alle relevanten Architekturelemente
- Priorisierung von Investitionen nach strategischem Impact
- Ein gemeinsames Verständnis von Business- und IT-Seite
Und das Wichtigste:
Transformation wurde machbar – nicht abstrakt.
Wenn das bei euch ähnliche Fragen aufwirft – ich bin mit meinem Team jederzeit für ein Gespräch zu haben.