Vorgehen bei der Einführung einer Organisation für das Management von Enterprise Systems

Krause, Sven; Jung, Jürgen Article — Published Version Vorgehen bei der Einführung einer Organisation für das Management von Enterprise Systems HMD Praxis der Wirtschaftsinformatik Provided in Cooperation with: Springer Nature Suggested Citation: Krause, Sven; Jung, Jürgen (2024) : Vorgehen bei der Einführung einer Organisation für das Management von Enterprise Systems, HMD Praxis der Wirtschaftsinformatik, ISSN 2198-2775, Springer Fachmedien Wiesbaden GmbH, Wiesbaden, Vol. 62, Iss. 1, pp. 25-42, https://doi.org/10.1365/s40702-024-01130-y This Version is available at: https://hdl.handle.net/10419/319059 Standard-Nutzungsbedingungen: Die Dokumente auf EconStor dürfen zu eigenen wissenschaftlichen Zwecken und zum Privatgebrauch gespeichert und kopiert werden. Sie dürfen die Dokumente nicht für öffentliche oder kommerzielle Zwecke vervielfältigen, öffentlich ausstellen, öffentlich zugänglich machen, vertreiben oder anderweitig nutzen. Sofern die Verfasser die Dokumente unter Open-Content-Lizenzen (insbesondere CC-Lizenzen) zur Verfügung gestellt haben sollten, gelten abweichend von diesen Nutzungsbedingungen die in der dort genannten Lizenz gewährten Nutzungsrechte. Terms of use: Documents in EconStor may be saved and copied for your personal and scholarly purposes. You are not to copy documents for public or commercial purposes, to exhibit the documents publicly, to make them publicly available on the internet, or to distribute or otherwise use the documents in public. If the documents have been made available under an Open Content Licence (especially Creative Commons Licences), you may exercise further usage rights as specified in the indicated licence. http://creativecommons.org/licenses/by/4.0/deed.de SCHWERPUNKT https://doi.org/10.1365/s40702-024-01130-y HMD Praxis der Wirtschaftsinformatik (2025) 62:25–42 Vorgehen bei der Einführung einer Organisation für das Management von Enterprise Systems Action-Research-Projekt in einem deutschen Logistikunternehmen Sven Krause · Jürgen Jung Eingegangen: 22. August 2024 / Angenommen: 9. November 2024 / Online publiziert: 9. Dezember 2024 © The Author(s) 2024 Zusammenfassung Der vorliegende Beitrag beschreibt die Einführung einer Organisationeinheit für das Enterprise Architecture Management in einem deutschen Logistikunternehmen. Die Anwendungslandschaft besteht aus wenigen Eigenentwicklungen sowie verschiedenen Standardsoftwaresystemen, von denen einige durch Konfiguration, andere aber durch Nicht-Standard-Erweiterungen angepasst werden. Die Einführung der Organisationseinheit erfolgt im Rahmen eines Action-ResearchProjects, welches sich über drei Phasen gezogen hat. Ziel des Beitrags ist die Ableitung von Empfehlungen für ähnliche Vorhaben auf Basis der Erprobung von Konzepten aus der Literatur sowie den Erfahrungen aus ihrer praktischen Umsetzung. Schlüsselwörter Enterprise System · Enterprise Architecture · Action Research · Anwendungsfall · Logistik Introducing an Organisation for Managing Enterprise Systems Action Research Project in a German Logistics Company Abstract The article at hand describes the introduction of an organizational unit for Enterprise Architecture Management in a German logistics company. The application landscape consists of a few in-house developments as well as various standard software systems, some of which are customized through configuration, while others are modified with non-standard extensions. The introduction of the organizational unit takes place as part of an action research project, covering three phases. The aim Sven Krause Berlin, Deutschland Jürgen Jung Frankfurt University of Applied Sciences, Nibelungenplatz 1, 60318 Frankfurt, Deutschland E-Mail: jung.[email protected] K 26 S. Krause, J. Jung of this contribution is to derive recommendations for similar endeavours based on concepts from the literature and experiences from their practical application. Keywords Enterprise System · Enterprise Architecture · Action Research · Industry case study · Logistics 1 Motivation und Hintergrund Enterprise Systems (ES) unterstützen betriebliche Prozesse in einem Unternehmen – auch über Funktionsgrenzen hinweg (Xu 2011). Einführung und Management eines ES werden bereits seit einiger Zeit untersucht, sind aber immer noch mit Herausforderungen verbunden (Strong und Volkoff 2004; Soja und Paliwoda-Pe¸kosz 2009). Insbesondere, wenn die Anwendungslandschaft aus vielen Anwendungssystemen und Schnittstellen zwischen diesen besteht, bietet sich ein strukturiertes Vorgehen wie Enterprise Architecture Management (EAM) an. Mit etablierten EAM-Methoden und Werkzeugen kann eine ganzheitliche Sicht auf die Fachseite erstellt und damit eine Anwendungslandschaft mit Standardsoftware und Eigenentwicklungen abgeleitet werden. Für die Einführung einer EAM-Organisation gibt es in der Literatur allgemeine Hinweise – bspw. in TOGAF (The Open Group 2022a). Konkrete Handlungsanweisungen für eine solche Veränderung unter Berücksichtigung organisationaler Spezifika gibt es selten. Change Management bietet konkrete Vorgehen (Kotter 2012;Cawseyetal.2016), jedoch werden spezifische Aspekte des Managements von ES oder EAM nicht berücksichtigt. Spezielle Einschränkungen, wie zum Beispiel mangelnde Einbindung der Fachseite oder fehlende Governance bleiben außen vor (Adikpe et al. 2024). Der vorliegende Beitrag beschreibt die Einführung einer Organisationseinheit für das Management von ES in einem Unternehmen (Geschäftsfeld in einem Konzern). Dessen Anwendungslandschaft ist geprägt durch Standardsoftwaresysteme und Eigenentwicklungen. Der Grad der Anpassung der Standardsoftware variiert zwischen Konfiguration (Customizing) und Individualisierung durch Erweiterungen. Erhöht wird die Komplexität der Anwendungslandschaft durch Schnittstellen zwischen Systemen. Ziel des Beitrags ist die Dokumentation der Erfahrungen, damit ähnlich gelagerte Vorhaben in anderen Unternehmen davon profitieren können. Es werden Empfehlungen aus der Literatur und eigene Maßnahmen umgesetzt und deren Erfolg evaluiert. Zunächst erfolgt ein kurzer Abriss über den aktuellen Stand der Forschung in Abschn. 2, gefolgt von einer Einführung in die hier gewählte Forschungsmethode, Action Research, in Abschn. 3. Die Situation zu Beginn des Vorhabens wird in Abschn. 4 beschrieben, gefolgt von der Dokumentation der Durchführung in Abschn. 5. Die Struktur in diesem Abschnitt ist dabei so gewählt, dass die Motivation für einzelne Maßnahmen erkennbar ist und so auf andere Kontexte übertragen werden kann. Der Beitrag schließt mit einer Reflektion der Ergebnisse (Abschn. 6) und einer zusammenfassenden Darstellung abgeleiteter Handlungsempfehlungen in Abschn. 7. K Vorgehen bei der Einführung einer Organisation für das Management von Enterprise Systems 27 2 Aktueller Stand der Forschung EAM-Publikationen konzentrieren sich meist auf die Visualisierung von Architekturen sowie Frameworks (dt. Rahmenwerke), wie z.B. ArchiMate (Wierda 2021) oder The Open Group Architecture Framework (TOGAF 10) (The Open Group 2022b). Zur Gewährleistung einer ganzheitlichen Sicht wird für das EAM ein Top-Down-Ansatz vorgeschlagen (Op’t Land et al. 2008; Lankhorst et al. 2017). Ein solcher Top-down-Ansatz wird in der Literatur jedoch seit einiger Zeit kritisch diskutiert, da er zu sehr auf Dokumente und Vorgaben fokussiert statt (ggf. kurzfristig) konkrete Probleme zu lösen (Bente et al. 2012;Wierda2015; Jung 2019). Als Ursachen werden bspw. genannt: Vielzahl verschiedener Visualisierungsarten (Kotusev 2017), eine ungenügende organisatorische Verankerung im Unternehmen (Lange et al. 2016), fehlende Unterstützung seitens des Managements (Olsen 2017) oder mangelhafte Kommunikation (Banaeianjahromi und Smolander 2017). Anstatt einer auf langfristige Planung ausgerichteten Organisation, schlägt Wierda (2015) ein Vorgehen ähnlich dem eines Schachspielers vor. Er lässt zwar langfristige Ziele zu, empfiehlt jedoch Architekturmaßnahmen regelmäßig an neue Gegebenheiten anzupassen. Vor einem ähnlichen Hintergrund stellen Bente et al. (2012)einen EAM-Ansatz vor, der Elemente u.a. aus dem Lean Management und agiler Methoden wiederverwendet. Greefhorst und Proper (2011) schlagen mehrere Prinzipien für die Gestaltung von Enterprise Architecture (EA) vor. Hanschke (2012) stellt einen Governance artigen Ansatz für EAM vor, betont dabei auch Aspekte, die für ein kollaborativ aufgestelltes EAM notwendig sind. Ähnliche Hinweise findet man in Burrows. Er adaptiert Prinzipien aus dem agilen Umfeld und dem Lean Management, um die Arbeit an den Bedürfnissen der Nutzer von IT auszurichten (Burrows 2019). Whittle und Myrick (2005) definieren ein Team ausschließlich für Business Architecture, für die Zusammenarbeit mit Stakeholdern. Kuehn (2023) widmet sich in drei Kapiteln explizit der Interaktion eines Business-Architecture-Teams. Dabei behandelt sie auch die Einordnung des Architektur-Teams in die Gesamtorganisation und mögliche Zusammenarbeitsmodelle. Es gibt derzeit keine umfangreiche Handlungsanweisung für die EAM-Einführung, es lässt sich jedoch ein Trend zu einer kollaborativen Arbeitsweise erkennen. Auch Methoden aus dem Change Management können für Veränderungen an ES und für EAM adaptiert werden. Dies erfolgt analog der Einführung einer Organisationseinheit, welche mit einer klaren Vision frühzeitig erste Erfolge liefert (Kotter 2012;Cawseyetal.2016). 3 Forschungsmethode Die Durchführung des Forschungsprojekts erfolgt gemäß der Methode Action Research. Sie kann angewendet werden, wenn ein Forscher die Anwendungvon Theorien mit Praktikern untersuchen möchte (Baskerville und Wood-Harper 1998;Avison et al. 1999). Action Research unterstützt die Durchführung von Änderungen und K 28 S. Krause, J. Jung die Reflektion von deren Auswirkungen (Greenwood 2018). Es wird ein iterativer, reflektierender Prozess umgesetzt (Baskerville und Wood-Harper 1998). Ein Forscher übernimmt im vorliegenden Projekt gemäß (Baskerville und WoodHarper 1998) sowie (Greenwood 2018) die beratende Rolle eines Experten. Er unterstützt bei der Formulierung des Ziels und von Maßnahmen für die nächste Veränderung. Durchgeführt werden die Änderungen vom Chefarchitekten des Logistikunternehmens, der als Praktiker direkt in den Untersuchungsgegenstand eingebunden ist. Er setzt die Maßnahmen um und reflektiert anschließend den Erfolg mit dem Forschenden. Der Chief Information Officer (CIO) ist als Sponsor unmittelbar am Erfolg der Einführung einer EAM-Organisation interessiert. In seinem Verantwortungsbereich liegen alle ES. Das Vorhaben ist vom CIO initiiert, so dass es gemäß Avison et al. (2001)als vom Kunden dominiert angesehen werden kann (client dominated). Es werden keine formalen Kontrollstrukturen festgelegt oder schriftlich dokumentiert, so dass die Kontrolle informal gestaltet ist (vgl. hierzu auch (Avison et al. 2001)). Die finale Lösung ist zu Beginn des Projekts nicht klar definiert und auch die Reaktion der Beteiligten nicht absehbar. Die Planung und die Evaluierung werden vom Chefarchitekten im Austausch mit Forscher und CIO übernommen. Jede Phase beginnt mit einer Diagnose der aktuellen Situation (diagnostic stage in (Baskerville 1999)). Die Akzeptanz und der Mehrwert des EAM werden evaluiert und der Erfolg der vorangegangenen Änderungsmaßnahmen besprochen. Dies hat sich retrospektiv als sehr wertvoll herausgestellt, da die meisten Änderungen in einem sozialen System stattfinden. Die Änderungen im sozialen System werden im Rahmen der therapeutischen Phase weitgehend vom Chefarchitekten mit Unterstützung des CIO durchgeführt. Der Forscher ist im Rahmen der begleitenden Beobachtung (vgl. hierzu (Hult und Lennung 1980)) beratend tätig, indem er die Anwendung neuer Ansätze entwirft und die Evaluierung der Ergebnisse moderiert. Mit Action Research werden mehrere Ziele verbunden: Der Forscher soll Vorschläge aus der Literatur einbringen und bei der Evaluation der Ergebnisse unterstützen. Gleichzeitig stellt er sicher, dass die Erfahrungen angemessen dokumentiert werden und auf andere Kontexte übertragen werden können. Praktiker können bei ähnlichen Vorhaben von bestätigten Annahmen und Erfolgsfaktoren profitieren. Die Einführung erstreckte sich über einen Zeitraum von 18 Monaten ab Ende 2021. 4 Ausgangssituation Das Unternehmen deckt ein Geschäftsfeld in einem Konzern ab und gliederte sich in Geschäftsbereiche, welche Überlappungen bei Zuständigkeiten und Leistungen aufweisen. Zwischen der Fachseite in den Geschäftsbereichen und der IT-Abteilung besteht eine strikte organisatorische Trennung. Die IT agiert als eine zentral arbeitende Organisation für Wartung und Weiterentwicklung von ES. Anforderungen werden bei der zentralen IT gesammelt, die wiederum die Anforderungen aufnimmt und deren Umsetzung plant (inkl. dem Zuweisen von Ressourcen). Die fachliche Verantwortung verbleibt innerhalb der Geschäftsbereiche und außerhalb der IT. K Vorgehen bei der Einführung einer Organisation für das Management von Enterprise Systems 29 Analog zum Product Owner (PO) aus agilen Methoden agieren sog. Proxy PO (PPO) als Schnittstelle zwischen Fachseite und IT. Sie sind in der IT angesiedelt und können aufgrund der fehlenden fachlichen Verantwortlichkeiten, die Anforderungen nur aufnehmen und an die IT weiterleiten. Priorisieren oder fachlich detaillieren konnten sie diese nicht. Aufgrund der Trennung von Business (Anforderungsmanagement) und IT (technische Umsetzung und IT-Ressourcenmanagement) zeigen sich deutliche Hemmnisse beim Management der ES, bspw.: Verzögerungen bei der Umsetzung (mehrere Monate) Verzögerte Weiterleitung fachlicher Änderungen Priorisierung anhand Verfügbarkeit von IT-Ressourcen statt Fachlichkeit Fehlende Abstimmung bzgl. Umsetzungsfortschritt Als Folge ergibt sich eine Atmosphäre, in der sich die Geschäftsbereiche von der IT blockiert und ignoriert fühlen, die IT wiederum missverstanden. Vor diesem Hintergrund erfolgt eine Dezentralisierung der IT (Allweyer 2020) in Produktlinien (PL), welche die Wertschöpfung für ein Produkt abdecken: Leasing & Fuhrparkmanagement, Mobility Services (bspw. Leihe von Mobilitätsmitteln für den Individualverkehr im Privatund Geschäftskundenbereich) und digitale Mobilitätslösungen (bspw. Mobilitätsbudget zur flexiblen Kombination verschiedener Verkehrsangebote). Jede PL hat dedizierte IT-Ressourcen, um deren Verfügbarkeit und eine fachliche Steuerung sicherzustellen. Dies ermöglicht eine fachliche Priorisierung von Anforderungen (vgl. hierzu auch (Schwartz 2019), S. 17). Das Entwicklerteam einer PL erhält die technische Verantwortung für die ES, womit eine Autonomie bzgl. Architektur und Technologieentscheidungen einhergeht. ITRessourcen werden fachlich unter einem zentralen CIO zusammengeführt und es kommt Scrum als agile Methode zum Einsatz. Teilweise betreiben PL Outsourcing von Entwicklung und Betrieb von ES aufgrund fehlender interner IT-Ressourcen. Das Anforderungsmanagement verbleibt im Verantwortungsbereich der jeweiligen PL. Zur Schaffung eines Gesamtblicks entsteht der Bedarf einer übergreifend wirkenden Architekturinstanz. Initial durch einen externen Berater fachlich konzipiert, wird die Aufgabe an den neu eingestellten Chefarchitekten übergeben. Die Ausgangslage aus Sicht des Chefarchitekten lässt sich wie folgt zusammenfassen: Fragmentierte Anwendungslandschaft Hoher Aufwand durch Redundanzen bei vorhandenen ES Einführung von EAM durch externen Berater ohne Vernetzung im Unternehmen Projekte durch individuelle Interessen der PL getrieben Kaum Wissenstransfer zwischen den Teams Entscheidungen über die Weiterentwicklung der ES-Landschaft nicht abgestimmt 5 Einführung der EAM-Organisation Die Einführung der Architektur-Disziplin lässt sich dem hier vorliegenden Aufsatz ex post in vier aufeinander aufbauenden Phasen zusammenfassen (vgl. Abb. 1). K 30 S. Krause, J. Jung Abb. 1 Phasen im Action-Research-Projekt Die vierte Phase ist nur angedeutet, da das Projekt aufgrund eines Wechsels des Praktikers in eine neue Rolle im Konzern nicht weiter begleitet werden konnte. 5.1 Phase 1: Projektfokus und Kommunikation 5.1.1 Problemstellung und Zielsetzung Die durch den externen Berater nicht aufgebaute Vernetzung stellt ein Problem dar, da Kommunikation für Architekturarbeit notwendig ist (Lange et al. 2016; Banaeianjahromi and Smolander 2017; Kurnia et al. 2020;BréeandKarger2022). Überdies muss der Mehrwert von EAM vermittelt werden (Ajer and Olsen 2018;Guo et al. 2019). Funktionierende Kommunikation und ein klarer Nutzen sind wichtiger als Artefakte und Methoden (Lange et al. 2016). Lange et al. (2016) sowie Hohpe (2020) empfehlen sogar, dass Architekten explizit in Projekten mitarbeiten sollten. Somit werden folgende Ziele gesetzt: Aufbau von Kommunikationswegen für EA zu Projekten Schaffen von Verständnis in den PL für Mehrwert der EA Zur Feststellung der Zielerreichung wird beobachtet, ob das Unterstützungsangebot aktiv angefragt wird. Auch wird als positiver Indikator gewertet, wenn gemeinsame Termine wahrgenommen oder durch die PL proaktiv geplant werden. 5.1.2 Maßnahmen Die Umsetzung von Maßnahmen konzentriert sich zu Beginn auf ausgewählte Entwicklungsprojekte, da die Mitarbeit von Architekten bisher nicht etabliert ist. Maßnahme A: Projektunterstützung Zu Beginn steht der Aufbau einer Arbeitsbeziehung zu Projektmanagement und PO, um die Ziele, Bedarfe und Probleme der PL zu verstehen und mit geeigneten Methoden zu unterstützen. Die Zusammenarbeit erfolgt durch die aktive oder teils auch moderierende Teilnahme des Architekten bei Regelterminen zur Priorisierung und Planung von fachlichen Anforderungen sowie der Entwicklung von Lösungskonzepten. Hierbei führt der Architekt auch das Konzept der Fachdomänen für die Bündelung fachlich zusammengehöriger Anforderungen ein. Sie werden in Workshops durch den Architekten mit den Teams und POs mittels der Methode des Event Storming aus dem Domain-driven Design entwiK Vorgehen bei der Einführung einer Organisation für das Management von Enterprise Systems 31 ckelt. Fachdomänen und deren Beziehungen werden kollaborativ dokumentiert und gepflegt. Genutzt werden sie für die Einordnung von Anforderungen, wodurch eine fachliche Bündelung frühzeitig erfolgt und als Grundlage für die Planung verwendet wird. Zudem ist eine tiefere fachliche Durchdringung aufgrund des Diskurses während der Zuordnung zu beobachten. Maßnahme B: Architekturberatung Die Unterstützung beginnt mit der Begleitung der Entwicklerteams über mehrere Sprints und einem Aufbau des Verständnisses bzgl. der eingesetzten Vorgehensmodelle, bestehender Herausforderungen und Probleme. Nach einer Bestandsaufnahme werden durch die Architektur drei thematische Schwerpunkte für die Beratungsleistung gewählt: 1. Bewerten von Lösungsoptionen bei der Weiterentwicklung von ES 2. Dokumentieren von Architekturentscheidungen 3. Beschreiben einer Lösungsarchitektur Mit der Einführung standardisierter Qualitätsattribute (auf Grundlage der ISO 25010) wird der Bedarf der PL zur Schaffung vergleichbarer Kriterien für die Bewertung von Lösungsoptionen erfüllt. Es wird auch dem bisherigen Problem entgegengewirkt, dass Betrachtungen meist anhand singulärer Aspekte auf technologischer oder operativer Ebene erfolgen. Der Projektleitung liegen damit für die Bewertung von Lösungsoptionen standardisierte und objektiv vergleichbare sowie fachlich bewertbare Informationen vor. Auf Basis dieser Empfehlungen können Verantwortliche die Auswirkungen auf den Geschäftsnutzen eruieren und eine fundierte Entscheidung fällen. Solche Entscheidungen müssen zusammen mit den Anforderungen und zu Grunde liegenden Annahmen dokumentiert werden (Hohpe 2020). Hierfür wird eine Struktur definiert, die ausgerichtet ist an der Form der Architecture Decision Records (ADRs). Bei diesem Ansatz liegt der Fokus auf der Entscheidung und den zugrundeliegenden Annahmen, was damit konkret die Bedürfnisse der Stakeholder adressiert (Buchgeher et al. 2023). Für die Dokumentation der Lösungsarchitektur wird das Arc42-Template (www.arc42.org) in vereinfachter Form eingeführt. Nach einer Abstimmung mit allen Teams und der bedarfsgerechten Verfeinerung der Vorlage ist die gemeinsame Vereinbarung getroffen, dass alle Projekte ihre Dokumentationen nach gleichem Schema durchführen. Das Arc42-Template fungiert als vollständiges Rahmenwerk und umfasst die folgenden Inhalte: Systemkontext und relevante Umsysteme Schnittstellen für die Integration mit Umsystemen Relevante Qualitätsanforderungen Fundamentale Architekturentscheidungen Mit der vereinheitlichten Dokumentation sind mehrere Erwartungen verknüpft: Dokumentierte Entscheidungen können von weiteren Akteuren verwendet werden (bspw. IT-Sicherheit oder IT-Betrieb). Überdies kann das darin dokumentierte Wissen in zukünftigen Projekten genutzt werden. K 32 S. Krause, J. Jung Maßnahme C: Regelmeeting Vom Architekten wird ein wöchentlicher, freiwilliger Regelaustausch zwischen den Teams organisiert und moderiert. Inhalte, gesammelt in einer offenen Themenliste, richten sich nach den Bedarfen und Vorschlägen der Entwickler. Am Ende eines Termins wird das Thema für den Folgetermin ausgewählt. Durch den Architekten wird der inhaltliche Fokus ergänzt um das Teilen von Erfahrungen aus dem Einsatz eingeführter Architekturmethoden. Explizit erwünscht und gefördert ist auch das Teilen missglückter Ansätze und aufgetretener Probleme. 5.1.3 Reflektion Die Unterstützung durch den Architekten wird von zumindest einer PL regelmäßig aktiv angefragt, da der Mehrwert für die Projektleiter wahrnehmbar ist. Die Lösung(-soption)en werden angenommen und auch in den Anwendungssystemen umgesetzt. Insbesondere wird der Architekt vermehrt in sog. Refinement Meetings für die detaillierte Umsetzung der ES eingeladen. Vom PO und einzelnen Entwicklern wird eine positive Wahrnehmung signalisiert und es werden vereinzelt Vorgaben oder unternehmensweite Lösungen angefragt. Für zwei PL hat sich das Unterstützungsangebot als weniger relevant herausgestellt, da überwiegend Standardsoftware durch Konfiguration angepasst wird. Das Unterstützungsangebot der Architekten fokussiert hingegen auf Softwareentwicklung sowie Erweiterung von ES. In der Zusammenarbeit ist deutlich geworden, dass die Kommunikation nur gut funktioniert, wenn der Architekt auf die spezifischen Anforderungen der jeweiligen Projekte eingeht und nicht auf architektonisch sauberen Lösungen beharrt. Wenn kein Mehrwert für das Projekt erkennbar ist, kann ein Beharren seitens des Architekten zu Widerständen führen. Das eingeführte Regelmeeting findet statt und es werden aktuelle Themen aus den Projekten diskutiert. Die Initiative für Planung und Durchführung liegt am Ende der ersten Phase noch immer beim Architekten. Er plant die Termine, fordert aktiv Themen und lädt die Beteiligten ein. Verbesserungsmaßnahmen Folgende Aspekte fließen in anschließende Phasen ein: Die Unterstützung der Projekte soll beibehalten und eine kontinuierliche Begleitung sichergestellt werden. Die ersten Erfolge sollen verstetigt und die verbleibenden Projekte für eine Zusammenarbeit gewonnen werden. Für häufig auftretende Themen sollen einheitliche Architekturlösungen und eine methodische Unterstützung geschaffen werden. Weiterhin soll ein gemeinsames Verständnis geschaffen werden, einheitliche Lösungsansätze zu nutzen. K Vorgehen bei der Einführung einer Organisation für das Management von Enterprise Systems 39 bzw. Technologiearchitektur. Zudem sind weite Teile des Konzern-Domänenmodells zur direkten Verwendung weiterhin fachlich ungeeignet und müssen bei Bedarf mit Aufwand erst in den Unternehmenskontext überführt werden. Ein neu geschaffenes Austauschformat ist die „Architektur/CIO-Klausur“. Sie findet vierteljährlich statt, mit dem Teilnehmerkreis: CIO, EA und Systemarchitektur sowie themenspezifisch geladenen Gästen (z.B. Informationssicherheit). Inhaltlicher Fokus liegt auf der gemeinsamen mittelund langfristigen Abstimmung und Planung laufender sowie strategisch relevanter Architektur-Themen. 6.2 Reflektion Forschungsmethode Die Durchführung des Projekts hat sich über einen Zeitraum von 18 Monaten erstreckt. Für die einzelnen Phasen wurde vorab keine zeitliche Begrenzung festgelegt. Die Zusammenarbeit zwischen Forscher und Praktiker (Chefarchitekt) hat sich retrospektiv als erkenntnisreich erwiesen. Dabei muss man einige Randbedingungen beachten: Die Phasen hatten keine vorab definierte Dauer, sondern wurden unter Berücksichtigung der Auslastung des Praktikers durchgeführt. Zusätzlich ist seitens des Praktikers eine gewisse Disziplin notwendig, um den Fortschritt und den Erfolg der Maßnahmen zu dokumentieren und gemeinsam mit dem Forscher zu evaluieren. Zusätzlich muss die Vertraulichkeit von Informationen beachtet werden, was insbesondere für die Veröffentlichung eine Herausforderung darstellte. Aus diesem Grund wirkt die Beschreibung in dieser Publikation teilweise abstrakt, da auf die Nennung konkreter Produkte oder Namen verzichtet werden musste. Die ursprüngliche Planung sah für das Forschungsprojekt vier Phasen vor. Nach Beendigung der dritten Phase hat der Praktiker den Unternehmensbereich gewechselt und das Projekt konnte in der vorliegenden Konfiguration nicht weitergeführt werden. Die gewonnenen Erkenntnisse können jedoch in die zukünftige Arbeit einfließen. 7 Zusammenfassung Der vorliegende Beitrag dokumentiert die Einführung einer Organisationseinheit für das übergreifenden Management von ES in einem Unternehmen auf Basis von EAM. Die Durchführung des Projekts erfolgt mittels der Forschungsmethode Action Research, die einen strukturellen Rahmen für Planung, Umsetzung und Evaluierung von Änderungen in der Organisation bietet. Das Kernteam, bestehend aus einem Forschenden und dem Chefarchitekten als Praktiker, hat in mehreren Phasen auf Basis der jeweils aktuellen Situation Maßnahmen umgesetzt und diese anhand konkreter Ziele gemeinsam ausgewertet. Aus den Projekterfahrungen lassen sich mehrere Empfehlungen für ähnlich gelagerte Vorhaben ableiten: Die Unterstützung durch Architekten in Projekten fördert die Akzeptanz von Architekturarbeit, da der Nutzen unmittelbar sichtbar wird. Erfolge sollten frühzeitig im Unternehmen als positive Beispiele kommuniziert werden. K 40 S. Krause, J. Jung Der Nutzen von Architekturarbeit ist bei Eigenentwicklungen oder weiterentwickelten ES höher als beim Customizing einer Standardsoftware. Architekturarbeit muss gleichzeitig top-down vom Management forciert werden, um auch projektübergreifendNutzen zu erzielen. Das Ableiten gemeinsamer Standards aus einzelnen Projekten (bottom-up) hat sich im vorliegenden Fall als kaum durchführbar erwiesen. Neben einem zentralen EA-Team sollte auch Architekturkompetenz in den Projektteams aufgebaut werden. Projektarchitekten vermitteln Wissen in die Projekte und können gleichzeitig beim Entwurf globaler Standards mitwirken. Übergreifende Leitlinien können Architekturkompetenz in Projekten nicht ersetzen. Solche allgemeingültigen Leitlinien müssen i.d.R. an die spezifischen Projektbedürfnisse angepasst werden. Einheitliche Vorlagen für die Dokumentation sollten frühzeitig eingeführt und erprobt werden, da sie für Projektarchitekten eine Empfehlung für relevante Inhalte darstellen. Ein Domänenmodell wird als hilfreich erachtet, wenn es das Kerngeschäft in der Terminologie der Fachseite dokumentiert. Ein konzernweites Domänenmodell sollte nicht verpflichtend sein, wenn es dies nicht gewährleisten kann. Es sollte ein Architekturboard als zentrales Gremium zur mandatierten Entscheidungsfindung übergreifender Architektur-Themen etabliert werden. Funding Open Access funding enabled and organized by Projekt DEAL. Open Access Dieser Artikel wird unter der Creative Commons Namensnennung 4.0 International Lizenz veröffentlicht, welche die Nutzung, Vervielfältigung, Bearbeitung, Verbreitung und Wiedergabe in jeglichem Medium und Format erlaubt, sofern Sie den/die ursprünglichen Autor(en) und die Quelle ordnungsgemäß nennen, einen Link zur Creative Commons Lizenz beifügen und angeben, ob Änderungen vorgenommen wurden. Die in diesem Artikel enthaltenen Bilder und sonstiges Drittmaterial unterliegen ebenfalls der genannten Creative Commons Lizenz, sofern sich aus der Abbildungslegende nichts anderes ergibt. Sofern das betreffende Material nicht unter der genannten Creative Commons Lizenz steht und die betreffende Handlung nicht nach gesetzlichen Vorschriften erlaubt ist, ist für die oben aufgeführten Weiterverwendungen des Materials die Einwilligung des jeweiligen Rechteinhabers einzuholen. Weitere Details zur Lizenz entnehmen Sie bitte der Lizenzinformation auf http://creativecommons.org/ licenses/by/4.0/deed.de. Literatur Adikpe I, Garba A, Ali F (2024) The enterprise architecture (EA) practice—an analysis of EA models for different organisational contexts. Enterp Archit Pract J Ajer AKS, Olsen DH (2018) Enterprise architecture challenges: a case study of three Norwegian public sectors. 26th European Conference on Information Systems: Beyond Digitization—Facets of SocioTechnical Change, ECIS 2018. Allweyer T (2020) IT-Management: Grundlagen und Perspektiven für den erfolgreichen Einsatz von IT im Unternehmen. BoD—Books on Demand, Norderstedt Ansyori R, Qodarsih N, Soewito B (2018) A systematic literature review: critical success factors to implement enterprise architecture. Procedia Comput Sci 135:43–51. https://doi.org/10.1016/j.procs.2018. 08.148 Avison D, Lau F, Myers M, Nielsen PA (1999) Action research. Commun ACM 42:94–97 K Vorgehen bei der Einführung einer Organisation für das Management von Enterprise Systems 41 Avison D, Baskerville R, Myers M (2001) Controlling action research projects. Inf Technol People 14:28–45 Banaeianjahromi N, Smolander K (2017) Lack of communication and collaboration in enterprise architecture development. Inf Syst Front 57:3. https://doi.org/10.1007/s10796-017-9779-6 Baskerville RL (1999) Investigating information systems with action research. Commun Ais 2:1–32 Baskerville R, Wood-Harper AT (1998) Diversity in information systems action research methods. Eur J Inf Syst 7:90–107 Bente S, Bombosch U, Langade S (2012) Collaborative enterprise architecture: enriching EA with lean, agile and enterprise 2.0 practices. Morgan Kaufmann, Amsterdam Brée T, Karger E (2022) Challenges in enterprise architecture management: overview and future research. J Gov Regul 11:355–367. https://doi.org/10.22495/jgrv11i2siart15 Buchgeher G, Schoberl S, Geist V et al (2023) Using architecture decision records in open source projects—an MSR study on github. IEEE Access 11:63725–63740. https://doi.org/10.1109/ACCESS. 2023.3287654 Burrows M (2019) Right to left: the digital leader’s guide to lean and agile. New Generation Publishing Cawsey TF, Deszca G, Ingols C (2016) Organiszational change: an action-oriented toolkit. SAGE Da Xu L (2011) Enterprise systems: state-of-the-art and future trends. IEEE Trans Ind Informatics 7:630–640. https://doi.org/10.1109/TII.2011.2167156 Greefhorst D, Proper E (2011) Architecture principles: the cornerstones of enterprise architecture. Springer, Berlin, Heidelberg Greenwood DJ (2018) Action research. In: Ciesielska M, Jemielniak D (Hrsg) Qualitative methodologies in organization studies. Springer, S 75–98 Guo H, Li J, Gao S (2019) Understanding challenges of applying enterprise architecture in public sectors: a technology acceptance perspective. Proceedings—IEEE International Enterprise Distributed Object Computing Workshop, EDOCW 2019, S 38–43 https://doi.org/10.1109/EDOCW.2019.00020 Hanschke I (2012) Enterprise Architecture Management – einfach und effektiv: Ein praktischer Leitfaden für die Einführung von EAM. Hanser, München Hohpe G (2020) 37 things one architect knows about IT transformation A chief architect’s journey. Leanpub Hult M, Lennung S-Å (1980) Towards a definition of action research: a note and bibliography. J Management Studies 17:241–250 Jung J (2019) Purpose of enterprise architecture management: Investigating tangible benefits in the German logistics industry. In: Proceedings—IEEE International Enterprise Distributed Object Computing Workshop, EDOCW Kotter JP (2012) Leading change. Harvard Business Review Press Kotusev S (2017) Enterprise architecture: what did we study? Int J Coop Inf Syst. https://doi.org/10.1142/ S0218843017300029 Kuehn W (2023) Strategy to reality: making the impossible possible for business architects, change makers and strategy execution leaders. Morgan James, New York Kurnia S, Kotusev S, Dilnutt R et al (2020) Artifacts, activities, benefits and blockers: exploring enterprise architecture practice in depth. Proc Annu Hawaii Int Conf Syst Sci 2020:5583–5592. https://doi.org/ 10.24251/hicss.2020.687 Lange M, Mendling J, Recker J (2016) An empirical analysis of the factors and measures of enterprise architecture management success. Eur J Inf Syst 25:411–431. https://doi.org/10.1057/ejis.2014.39 Lankhorst MM, Iacob M-E, Jonkers H (2017) State of the art. In: (Hrsg) Enterprise architecture at work, 4. Aufl. Springer, Berlin, Heidelberg Olsen DH (2017) Enterprise Architecture management challenges in the Norwegian health sector. Procedia Comput Sci 121:637–645. https://doi.org/10.1016/j.procs.2017.11.084 Op’t Land M, Proper E, Waage M et al (2008) Enterprise architecture: creating value by informed governance. Springer Pfannenstiel W (2023) Business Capabilities: Geschäftsfähigkeiten als effektives Werkzeug für die Gestaltung von Unternehmensund IT-Architekturen. dpunkt. Schwartz M (2019) War and Peace and IT: business leadership, technology, and success in the digital age. IT Revolution, Portland (USA) Soja P, Paliwoda-Pe¸kosz G (2009) What are real problems in enterprise system adoption? Ind Manag Data Syst 109:610–627. https://doi.org/10.1108/02635570910957614 Strong D, Volkoff O (2004) A roadmap for enterprise. Computer 37:22–29. https://doi.org/10.1109/MC. 2004.3 K 42 S. Krause, J. Jung The Open Group (2022a) The TOGAF®standard, 10th edition—ADM practitioners’ guide, 10. Aufl. Van Haren The Open Group (2022b) The TOGAF®standard, 10th edition—introduction and core concepts, 10. Aufl. Van Haren, Publishing Whittle R, Myrick CB (2005) Enterprise business architecture: the formal link between strategy and results. Auerbach, Boca Raton, London Wierda G (2015) Chess and the art of enterprise architecture. R&A Wierda G (2021) Mastering ArchiMate Edition 3.1: A serious introduction to the ArchiMate®enterprise architecture modeling language. R&A Hinweis des Verlags Der Verlag bleibt in Hinblick auf geografische Zuordnungen und Gebietsbezeichnungen in veröffentlichten Karten und Institutsadressen neutral. K