„Alter Wein in neuen Schläuchen“
oder: Weshalb EAM relevanter wird denn je.
Haben Sie EAM (Enterprise Architecture Management)? Nein!
Haben Sie vielleicht Software wie LeanIX oder ADOIT? Ja klar, sowas haben wir.
–
So oder so ähnlich erleben wir es oft bei unseren Kunden.
Gerade in Zeiten der großen SAP S/4-Transformationswelle (und der Übernahme von LeanIX durch SAP) steigt die Zahl der LeanIX Installationen. Auf der inhaltlichen Ebene finden wir nur sehr selten etwas, das man als „echtes EAM“ bezeichnen könnte.
In diesem Beitrag wollen wir mit einigen Mythen rund um EAM aufräumen und Sie motivieren, EAM auch bei Ihnen zukünftig ganz oben auf die To-Do-Liste zu setzen.
Wenn Sie also aktuell so ein „LeanIX“ oder auch „ADOIT“ im Einsatz haben, Sie hier aber irgendwie keine Vorteile sehen oder bisher mit Ihrem EAM nicht so richtig vorankommen, dann sollten Sie genau jetzt aufmerksam weiterlesen 😉
Was ist Enterprise Architecture Management eigentlich?
Enterprise Architecture Management (EAM) ist ein strategischer Ansatz, der die Struktur und die Beziehungen innerhalb eines Unternehmens sowohl im aktuellen als auch im zukünftigen Zustand darstellt. Es bildet die Grundlage für die strategische Geschäftsplanung und die Entwicklung der unterstützenden Informationstechnologie. EAM zielt darauf ab, die Komplexität von IT-Landschaften beherrschbar zu machen, indem Prozesse, Technologien und IT-Systeme transparent dargestellt und langfristig optimiert werden. Dabei werden Synergien zwischen verschiedenen Unternehmensarchitekturen erkannt und genutzt, was Organisationen agiler und widerstandsfähiger macht. EAM ist eine Schnittstellendisziplin, die Rollen wie Enterprise Architects und Business Analysts umfasst, die zwischen Business und IT agieren.
Mythos #1: Habe ich ein Tool, so habe ich auch EAM…
Was wir täglich auch auf den Autobahnen sehen müssen … nur, weil jemand ein teures Auto hat, ist er/sie noch lange kein guter Autofahrer.
Weder benötigen Sie ein EAM-Tool, um EAM zu leben (gleich wenn es dies sicher wesentlich vereinfacht), noch haben Sie ein gelebtes EAM, sobald Sie ein teures Tool angeschafft haben.
Meist finden sich in den EAM-Tools dieser Welt diverse Modelle in unterschiedlichen Status für unscharfe Szenarien.
Aktuell? Valide? Abgestimmt? Zielgerichtet? Fehlanzeige!
Letztendlich die teure Alternative zur PowerPoint-Folie 😉
Mythos #2: EAM ist Aufgabe der IT
„Target Architecture“ – klingt nach IT. Soll die IT festlegen und einfach „machen“.
Das E in EAM steht aber für „Enterprise“. EAM betrifft also das gesamte Unternehmen. Hier soll also das Unternehmen im IST- und im ZIEL-Zustand dargestellt werden und davon abgeleitet eine passende IT-Architektur entwickelt und realisiert werden.
Mythos #3: EAM ist ein Projekt
Wir „machen“ EAM? Oder Externe sollen mal eben EAM einführen?
Natürlich hat der Aufbau und auch die Einführung von EAM zunächst Projektcharakter. Aber danach?
Dann wird es vorwiegend dünn…
Keine Zeit. Keine Ressourcen. Keine Motivation im Team.
Oft bleibt es dann bei einer Eintagsfliege – Warum? Weil größtenteils keine Integration in den „Alltag“ stattfindet!
Mythos #4: EAM bringt nur mit viel Input „irgendwann“ Vorteile
Wenn wir hunderte von Modellen gepflegt und Listen gefüllt haben – dann drücken wir auf den Knopf und die Welt ist rosarot …
Auch dies ist ein weit verbreiteter Mythos. Natürlich sehen wir aktuell – meist aus der Tiefe motiviert – spannende Use Cases, in denen uns KI-Fragen beantwortet oder die Architektur bewertet werden. Genau dafür brauchen wir natürlich massenhaft Daten.
Aber EAM schafft bereits mit wenigen Überlegungen ganz konkrete Mehrwerte.
Beispiele gefällig?
Mit einer Zielarchitektur schaffen Sie bereits mit dem ersten Modell bei allen Beteiligten Klarheit über das Ziel.
Verantwortlichkeiten können Sie dank definierter „Building Blocks“ klar abgrenzen. Zum Beispiel, was zukünftig in SAP und was im Non-SAP-Bereich ist.
Sie sehen. Es geht nicht immer um den „Big Bang“ mit langer Vorarbeit – nutzen Sie vor allem die schnellen Quick Wins, um Ihr Team zu motivieren.
Mythos #5: EAM = TOGAF
Mit EAM geht natürlich auch die Architekturentwicklungsmethode (ADM) TOGAF einher. TOGAF steht für „The Open Group Architecture Framework“ und gibt als Standard der OMG einen klaren Rahmen für das Wie und Was rund um EAM vor.
Ja – wie so oft ist es gut, den Standard zu kennen.
Nein – wie so oft ist es natürlich nicht notwendig, sofort das 1×1 des Standards zu kennen.
Dennoch lohnt es sich, sich in den Begrifflichkeiten und auch in den generellen Dimensionen und Strukturen am Standard zu orientieren. Das tut nicht weh, sondern sichert die Möglichkeit, später ohne großen Aufwand kontinuierlich in Richtung Standard zu arbeiten.
Motivation: Was Ihr EAM leisten soll
Und weshalb nun das Ganze?
Die Hauptmotivation hinter EAM ist es, Transparenz über die gesamte Unternehmensarchitektur zu schaffen, um fundierte Entscheidungen treffen zu können. EAM soll dazu beitragen, die Komplexität der IT-Landschaft zu reduzieren, indem klare Strukturen und Prozesse etabliert werden. Es sollte die Agilität und Innovationsfähigkeit des Unternehmens fördern, indem es die Anpassung an sich ändernde Marktbedingungen erleichtert. Darüber hinaus soll EAM die Effizienz steigern, indem Redundanzen minimiert und Synergien zwischen verschiedenen Geschäftsbereichen genutzt werden.
Letztendlich ist EAM der perfekte Schirm, um verschiedenen Methoden einen klaren Rahmen zu geben.
- Geschäftsprozessmanagement
- Anforderungsmanagement
- Projektmanagement
- Software-Architektur-Management
- Schnittstellen-Management
- IT-Notfallmanagement
- …
All diese Themenfelder brauchen einen „Nenner“. Die Unternehmensarchitektur!
Wenn wir es schaffen, all diese Themenfelder auf genau diesen Nenner zu bringen, können wir unsere Geschäftsmodelle schnell und effizient verändern.
Damit wird EAM plötzlich sehr schnell zu einem zentralen Wettbewerbsfaktor heute und in Zukunft!
Und wie schaffen wir es, „Architekturmanagement“ in unserer Organisation zu leben?
Natürlich liest man viel über Transparenz, Rollen und strategische Ausrichtung – das sagt heute jede KI … 😉
Aus unserer Projekterfahrung hier ein paar ganz pragmatische Grundlagen:
Anfangen und nicht zu lange „zerdenken“.
Oft werden zu Beginn zu viele Themen auf den Stack für das EAM geladen. Das führt schnell zu Frustration. Zunächst also einen klaren Fokus für die zu hebenden Mehrwerte setzen.
Wichtig ist, am Anfang mit allen Beteiligten ein klares Zielbild zu entwickeln und die Phasen bis dahin in einem pragmatischen Plan festzulegen.
Tipp: Auch bei der Einführung von EAM eignet sich die Methode Objectives and Key Results (OKR) zur schnellen und pragmatischen Zielerreichung!
Direkt in bestehende Prozesse integrieren.
Auch wenn Sie heute vielleicht noch kein perfektes Anforderungsmanagement haben – integrieren Sie das EAM so schnell wie möglich. Sprechen Sie über relevante Building Blocks, Schnittstellen und den Beitrag zur Zielarchitektur. Das bringt EAM schnell als Gesprächsthema auf die Agenda.
Insgesamt sollte Sie das Change Management bei der Einführung in den Fokus rücken.
Schnittstellenfunktion wahrnehmen.
Wie oft stimmt sich Ihr Prozessmanagement heute mit dem Anforderungsmanagement und den IT-Architekten ab? Genau, wahrscheinlich nie.
Doch wenn alle in dieselbe Richtung hinarbeiten sollen, ist genau das ein Muss. Peilen Sie an, den Rahmen „EAM“ als Schnittmenge zu etablieren!
—
Auch am Ende dieses Posts muss natürlich der obligatorische Werbe-Pitch sein.
Wenn Sie mit Ihrem aktuellen EAM unzufrieden sind oder erst in das Thema EAM einsteigen möchten, dann sprechen Sie uns einfach an. Unsere Experten helfen wie immer schnell und pragmatisch.
Mehr Informationen zu unserer Leistung im Kontext EAM.
