Benutzerzentrierte Unternehmensarchitekturen: Ein portfolio-orientierter Ansatz zur Geschäftstransformation mit ArchiMate® [1. Aufl.] 9783658305369, 9783658305376

Citation preview

Dimitris Karagiannis Christoph Moser Anke Helmes Hrsg.

Benutzerzentrierte Unternehmensarchitekturen Ein portfolio-orientierter Ansatz zur Geschäftstransformation mit ArchiMate®

Benutzerzentrierte Unternehmensarchitekturen

Dimitris Karagiannis · Christoph Moser · Anke Helmes (Hrsg.)

Benutzerzentrierte Unternehmensarchitekturen Ein portfolio-orientierter Ansatz zur Geschäftstransformation mit ArchiMate®

Hrsg. Dimitris Karagiannis Forschungsgruppe Knowledge Engineering Fakultät für Informatik, Universität Wien Wien, Österreich

Christoph Moser BOC Products & Services AG Wien, Österreich

Anke Helmes BOC Information Technologies Consulting GmbH Berlin, Deutschland

ISBN 978-3-658-30536-9 ISBN 978-3-658-30537-6  (eBook) https://doi.org/10.1007/978-3-658-30537-6 Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. © Der/die Herausgeber bzw. der/die Autor(en), exklusiv lizenziert durch Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung, die nicht ausdrücklich vom Urheberrechtsgesetz zugelassen ist, bedarf der vorherigen Zustimmung des Verlags. Das gilt insbesondere für Vervielfältigungen, Bearbeitungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Die Wiedergabe von allgemein beschreibenden Bezeichnungen, Marken, Unternehmensnamen etc. in diesem Werk bedeutet nicht, dass diese frei durch jedermann benutzt werden dürfen. Die Berechtigung zur Benutzung unterliegt, auch ohne gesonderten Hinweis hierzu, den Regeln des Markenrechts. Die Rechte des jeweiligen Zeicheninhabers sind zu beachten. Der Verlag, die Autoren und die Herausgeber gehen davon aus, dass die Angaben und Informationen in diesem Werk zum Zeitpunkt der Veröffentlichung vollständig und korrekt sind. Weder der Verlag, noch die Autoren oder die Herausgeber übernehmen, ausdrücklich oder implizit, Gewähr für den Inhalt des Werkes, etwaige Fehler oder Äußerungen. Der Verlag bleibt im Hinblick auf geografische Zuordnungen und Gebietsbezeichnungen in veröffentlichten Karten und Institutionsadressen neutral. Planung/Lektorat: Martin Börger Springer Vieweg ist ein Imprint der eingetragenen Gesellschaft Springer Fachmedien Wiesbaden GmbH und ist ein Teil von Springer Nature. Die Anschrift der Gesellschaft ist: Abraham-Lincoln-Str. 46, 65189 Wiesbaden, Germany

Inhaltsverzeichnis

1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Dimitris Karagiannis, Christoph Moser und Anke Helmes 2

Geschäftstransformation – Eine Notwendigkeit . . . . . . . . . . . . . . . . . . . . . . 13 Dimitris Karagiannis, Christoph Moser und Anke Helmes

3

Das Zusammenspiel zwischen TOGAF®, ArchiMate® und EA-Szenarien . . . 33 Anke Helmes und David Hauer

4 Transformationsportfolio-Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Christoph Moser und Felix Brandmayr 5 Capability-Portfolio-Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Hasan Koç 6 Applikationsportfolio-Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Lutz Kirchner, Matthias Frenzel und Christoph Moser 7 Datenportfolio-Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 Christoph Moser und Kai-Helmut Eckert 8 Technologieportfolio-Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 Matthias Frenzel und Christian Höllwieser 9 Compliance-Portfolio-Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Pedram Asadi und Christian Höllwieser 10 Benutzererfahrung als Wegweiser in der Geschäftstransformation . . . . . . 233 Wilfrid Utz, Christine Schrüffer und Christoph Moser 11 Wesentliche Konzepte aus ArchiMate® kurz zusammengefasst . . . . . . . . . 249 Pedram Asadi Appendix: Ein online verfügbares, benutzerzentriertes Assessment-Service für Unternehmensarchitekturen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 V

Über die Herausgeber

o. Univ.-Prof. Prof.h.c. Dr. Dimitris Karagiannis Nach einem Studium der Informatik an der Technischen Universität Berlin und einigen Aufenthalten in den USA und Japan arbeitete Karagiannis von 1987 bis 1992 als Bereichsleiter für Unternehmensinformationssysteme am Forschungsinstitut für Angewandte Wissensverarbeitung in Ulm. Seit 1993 ist er als ordentlicher Universitätsprofessor an der Universität Wien tätig, wo er die Forschungsgruppe Knowledge Engineering der Fakultät für Informatik leitet. Seine Forschungstätigkeit fokussiert auf Metamodellierung, Wissens-, Geschäftsprozess- und Unternehmensarchitektur-Management und Künstliche Intelligenz. Die praktische Anwendbarkeit seiner Forschungsarbeiten wurde durch die BOC Gruppe, einem weltweit tätigen Software- und Consulting-Unternehmen demonstriert. Aktuell wird seine Forschungsarbeit auch im Open Models Laboratory – OMiLAB www.omilab.org –, einer Non-ProfitOrganisation, welche von ihm gegründet wurde, international evaluiert und weitergeführt. Dr. Christoph Moser hat nach seinem BWL-Studium an der Fakultät für Informatik der Universität Wien promoviert. Aktuell ist er Produktmanager von ADOIT, der von Analystenhäusern als Leader eingestuften Software für UnternehmensarchitekturManagement. Er leitet den Bereich Unternehmensarchitektur und -transformation in der BOC Gruppe. In seiner langjährigen Beratungstätigkeit hat er zahlreiche Unternehmen bei der Einführung von ­Unternehmensarchitektur- und Prozessmanagement im Rahmen von G ­ eschäftstransformations-Initiativen unterstützt. Weiterhin ist er als Lehrbeauftragter an der Universität Wien in den Bereichen Unternehmensmodellierung und Enterprise Architecture Management tätig. Dr. Anke Helmes studierte Wirtschaftsinformatik an der Universität Leipzig und promovierte im selben Fachgebiet an der Universität St. Gallen. Sie arbeitete als Business Architect und Enterprise Architect bei Munich Re. Seit 2011 ist sie als Senior Management Consultant bei der BOC Gruppe tätig und hat die Regionalverantwortung für den süddeutschen Raum übernommen. Ihre Projektschwerpunkte liegen auf den Themengebieten Unternehmensarchitektur-Management und Prozessmanagement.

VII

1

Einleitung Dimitris Karagiannis, Christoph Moser und Anke Helmes

Inhaltsverzeichnis 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Fokus und Zielgruppe des Buchs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3 Struktur des Buchs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.4 Leseempfehlung für des Buch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.1 Motivation Dieses Buch widmet sich dem komplexen Thema „Geschäftstransformation“ aus der gestaltungs-orientierten Perspektive des Unternehmensarchitektur-Managements (engl. Enterprise Architecture Management, kurz EAM oder nur EA). Vielfach ist im Zusammenhang mit Geschäftstransformation die Rede von digitalen Strategien, welche Organisationen definieren und umsetzen müssen, um die zukünftigen Herausforderungen einer digitalen Welt zu meistern. Genauer betrachtet geht es dabei nicht um digitale D. Karagiannis  Universität Wien/Research Group Knowledge Engineering, Wien, Österreich E-Mail: [email protected] C. Moser (*)  BOC Products & Services AG, Wien, Österreich E-Mail: [email protected] A. Helmes  BOC Information Technologies Consulting GmbH, Berlin, Deutschland E-Mail: [email protected] © Der/die Herausgeber bzw. der/die Autor(en), exklusiv lizenziert durch Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 D. Karagiannis et al. (Hrsg.), Benutzerzentrierte Unternehmensarchitekturen, https://doi.org/10.1007/978-3-658-30537-6_1

1

2

D. Karagiannis et al.

Strategien, sondern um Strategien, deren Umsetzung durch die Digitalisierung überhaupt erst vorstellbar und realisierbar werden. Die Allgegenwart von Informationstechnologien, die nahezu alle Lebensbereiche des „digitalen“ Menschen beeinflussen, erfordert es für Unternehmen, den Benutzer in den Mittelpunkt notwendiger zukünftiger Verbesserungen und Innovationen (vgl. Brenner et al. 2014) zu setzen. Die zunehmende Digitalisierung fördert die Mitgestaltung des Kunden – dem Benutzer digitalisierter Services und Produkte. Diese Mitgestaltung führt zu einem immer volatileren und dynamischeren Umfeld von Organisationen bzw. deren gesamtem Ecosystem. Agilität wird für Organisationen zum wesentlichen Erfolgsfaktor. Das Analystenhaus Forrester spricht in diesem Zusammenhang vom Zeitalter des Konsumenten (vgl. Forrester 2020). Benutzer fordern mehr und mehr Entscheidungs- und Gestaltungsmöglichkeiten und üben diese auch aus. Ihnen steht ein wachsendes Spektrum an Produkten und Dienstleistungen am Markt zur Auswahl. Auch die Auswirkungen digitaler Technologien auf Produkte und Dienstleistungen selbst sind gravierend. Produkte und Dienstleistungen müssen unter dem Schlagwort Mass-Customisation zunehmend an individuelle Bedürfnisse angepasst werden. Dies stellt Unternehmen vor neue Herausforderungen bei der Gestaltung ihrer Leistungserbringungsprozesse. Gleichzeitig muss der Zugang der Benutzer vielfach neu ausgerichtet werden. In nahezu jeder Branche haben sich in den letzten Jahren große Plattformen etabliert, die den Zugang zu angebotenen Produkten und Services beeinflussen. Neu ist auch, dass Produkte mit digitalen Services angereichert werden. Beispiele zu diesen Trends finden sich in nahezu allen Produktsparten und Branchen. Sie werden sich weiter fortsetzen. Ein „digitaler Benutzer“ ist jedermann, der in der digitalen Welt Daten generiert und nutzt. Digitale Benutzer sind Personen, die gelegentlich im Internet recherchieren, die soziale Medien nutzen und Personen, die viele Aspekte des täglichen Lebens – sowohl privat als auch beruflich – mit Unterstützung digitaler Produkte und Services meistern (vgl. Brenner et al. 2014). Als Folge wird die traditionelle Wertschöpfungskette zunehmend umgedreht. Der Benutzer steht in der digitalen Welt nicht mehr als Nutzer am Ende der Wertschöpfungskette. Vielmehr werden die digitalen Spuren von Benutzern, welche diese unabsichtlich oder absichtlich in der digitalen Welt hinterlassen zur Ausgangsbasis für neue innovative Produkte und Dienstleistungen. Vor diesem Hintergrund sind die im Buch beschriebenen Inhalte mit Blickwinkel auf den digitalen Benutzer gewählt. Dies spiegelt sich auch im Titel des Buches wider. Der Benutzer wird in den Mittelpunkt der notwendigen geschäftlichen Veränderung gesetzt – Benutzer, nicht „Konsument“ oder „Kunde“. Es sind die „Benutzer“, die Produkte bzw. Leistungen des Unternehmens beziehen, die Produkte und Services für ihren Bedarf konfigurieren und Rückkopplung zur Qualität, Nutzungsverhalten und Effektivität derselben geben. Dieser Entwicklung muss folglich auch der Ansatz für das ­ Unternehmensarchitektur-Management Rechnung tragen. Benutzer und deren Erwartungen müssen bei der Weiterentwicklung der Produkte und Services und folglich

1 Einleitung

3

der gesamten Unternehmensarchitektur berücksichtigt werden. Benutzererfahrung (engl. User Experience) und Mitarbeitererfahrung (engl. Employee Experience) müssen in das Zentrum des architektonischen Handelns rücken. Unternehmensarchitekten als Architekten der digitalisierten Arbeitswelt stellt dies vor neue Herausforderungen, wie Informationstechnologie geplant, entworfen, realisiert und betrieben wird. Alle Ebenen der Organisation vom Geschäftsmodell, über die angebotenen Produkte und Services bis hin zu den Leistungserbringungsprozessen und den zugrunde liegenden IT-Infrastrukturen müssen analysiert und neu ausgerichtet werden. Das Werteversprechen für die Benutzer muss klar definiert und messbar sein. Die permanente Rückkopplung der Benutzer in Hinblick auf die Gestaltung und Einhaltung des Werteversprechens muss sichergestellt sein. Das Profil und die Rolle des Unternehmensarchitekten treten somit in ein neues Zeitalter. Unternehmensarchitekten müssen ein digitales und benutzer-zentriertes Mindset vertreten und in der Organisation verankern. Eine offene, neugierige und begeisterte Einstellung gegenüber der Digitalisierung und den damit verbundenen Möglichkeiten muss für alle Mitarbeiter und Partner forciert werden. Technische Affinität, Datenaffinität und nicht zuletzt flexible und agile Arbeitsweisen müssen gefördert werden, um den dynamischen Anforderungen gerecht zu werden. Unternehmensarchitekten müssen agile Teams, die in ihren Projekten an der Unternehmenstransformation arbeiten, in Architekturfragen beratend zur Seite stehen (Uludag et al. 2019). Zur Bewerkstelligung dieser Aufgabe müssen Unternehmensarchitekten die Sicht der Benutzer einnehmen. Unternehmensarchitektur-Management muss dabei unterstützen, die oftmals komplexen und unüberschaubaren Landschaften von mehreren hundert bis hin zu tausenden IT-Systemen unter Kontrolle zu bringen und gleichzeitig an die Benutzerbedürfnisse anzupassen. Benutzer-zentriertheit muss der Dreh- und Angelpunkt der Architekturarbeit werden. Dies gilt gleichzeitig auch für die zu erstellenden Architekturartefakte, für das Design der zukünftigen Unternehmensarchitektur und somit des Unternehmens selbst. Die Architekturartefakte müssen den Nutzern derselben ermöglichen, die richtigen Entscheidungen zur zukünftigen Ausrichtung des Unternehmens zu treffen. Entscheidend ist es dabei, die anstehenden Transformationen, die auf Basis dieser Architekturartefakte realisiert werden, zeitgerecht, ressourcen-schonend und mit dem geringstmöglichen Risiko umzusetzen. Compliance und Nachhaltigkeit sind weitere Faktoren, die nicht vernachlässigt werden dürfen. Die durch Unternehmensarchitektur-Management bereitgestellten Architekturartefakte dienen als Entscheidungsgrundlagen für die permanente Neuausrichtung des Unternehmens. Sie müssen aktuell, akkurat und vollständig sein. Die Architekturartefakte – man spricht in diesem Zusammenhang oft auch von einer Sammlung an Sichten (engl. Views) – müssen den Entscheidungsträgern einfach zugänglich sein. Sie müssen einen klaren Nutzen für einen definierten Benutzerkreis haben (vgl. Blumenthal 2008) und folgende Zwecke erfüllen:

4

D. Karagiannis et al.

• Informieren: Architekturartefakte müssen tiefe Einblicke in das Unternehmen ermöglichen, sodass Geschäftsentscheidungen auf fundierter Basis getroffen werden können, • Evaluieren: Architekturartefakte müssen die Bewertung von Architekturen und möglicher Architekturvarianten ermöglichen. • Steuern: Architekturartefakte müssen Empfehlungen und Richtlinien, die eine möglichst harmonisierte, wartbare und zugleich flexible Unternehmensarchitektur gewährleisten, beinhalten. Grundlage für die zu erstellenden Architekturartefakte ist ein Unternehmensportfolio, welches die wesentlichen Gestaltungselemente der Organisation bzw. des Ecosystems, in welches die Organisation eingebettet ist, beschreibt. Ein Unternehmensportfolio wird üblicherweise in Ebenen, wie Geschäftsebene, Applikationsebene und Technologieebene strukturiert. Neben den einzelnen Gestaltungselementen, wie beispielsweise Produkte und Geschäftsprozesse auf Geschäftsebene, Applikationen und Daten auf Applikationsebene und eingesetzte Softwareprodukte und Maschinen auf Technologieebene, müssen die Beziehungen all dieser Elemente zueinander beschrieben sein. Das Unternehmensportfolio bildet das Rückgrat für die Erstellung der Architekturartefakte, die für die Planung und Analyse der Geschäftstransformation herangezogen werden. Die Partizipation der Benutzer an der Erstellung der Architekturartefakte ist ein wichtiger Erfolgsfaktor. Typische Top-Down-Ansätze, wo die zukünftige Architektur nach Vorgaben des Managements gestaltet wird, werden von Teilen des Unternehmens (interne Benutzer) oftmals nicht mitgetragen. Somit ist es wichtig, dass neben den Ideen des Managements auch auf die interne Erfahrung und die Ideen der Mitarbeiter gesetzt wird. Kunden, Experten, Partner und Berater eines Unternehmens (externe Benutzer) haben sehr viel Wissen über die Organisation. Dieses darf nicht ungenutzt bleiben. Möglichkeiten, dieses Wissen zu heben und für die zukünftige Gestaltung des Unternehmens zu nutzen, gibt es viele. Sie reichen von einfachen F ­ eedback-Mechanismen, wie der Evaluierung von Fragebögen zu einzelnen Architekturartefakten bis hin zu CoCreation-Workshops, wo die unterschiedlichen Akteure zu einem Team zusammengebracht werden, um zukünftige Produkte, Services und Geschäftsmodelle zu gestalten und zu evaluieren. Die Benutzer und deren Perspektive werden somit in die Gestaltung der zukünftigen Architekturen aktiv eingebunden. Architekturartefakte, die strukturelle Informationen über die Zusammenhänge der zentralen Gestaltungselemente der Organisation bieten, sind allerdings nicht ausreichend, um die Geschäftstransformation zu planen. Sie müssen mit Fakten wie beispielsweise Performance-Daten aus operativen Systemen und der Produkte und Dienstleistungen am Markt angereichert werden. Dadurch entsteht ein detaillierteres Abbild der Realität – ein digitaler Zwilling der Organisation. Dieser bietet die Basis, um das Unternehmen in ausreichender Tiefe zu verstehen, Auswirkungen von Veränderungen zu simulieren oder auch bestimmte Teilaspekte (etwa Produkte, Prozesse oder Maschinen) zu konfigurieren. Vielmehr als früher wird ein derartiges Abbild der

1 Einleitung

5

Organisation zukünftig für die Unternehmensplanung herangezogen und muss somit dauerhaft gepflegt und optimiert werden. Ohne diesem Abbild bleibt die zunehmende Komplexität nicht steuerbar. Abb. 1.1 gibt einen Überblick über die wesentlichen Zusammenhänge. Die Abbildung zeigt die Organisation und ihren digitalen Zwilling. Dieser wird durch eine Menge an EA-Artefakten beschrieben. Die beteiligten Benutzertypen sind Kunden, die die erstellten Produkte und Dienstleistungen nutzen und direkt oder indirekt an der Gestaltung derselben mitarbeiten, Mitarbeiter der Organisation, aber auch Partner, wie Influencer, Interessenten und weitere Gruppen, die an der Organisation oder deren Produkten und Dienstleistungen interessiert sind und diese beeinflussen können. Das Unternehmen selbst als auch sein Ecosystem wird von einer Reihe externer Faktoren beeinflusst. Sowohl das Unternehmen als auch dessen digitales Abbild unterliegen einem stetigen Wandel. Dies wird durch die jeweiligen zeitlichen Aspekte des Kreislaufs, welcher die Geschäftstransformation repräsentiert, symbolisiert. Dabei gilt es POLITISCH

RECHTLICH

ÖKOLOGISCH

Mitarbeiter

Partner Organisation

Digitaler Zwilling Kunden

UMSETZEN

WIRTSCHAFTLICH

GESELLSCHAFTLICH

TECHNOLOGISCH

Abb. 1.1   Die Organisation, ihr digitaler Zwilling und beteiligte Benutzergruppen

6

D. Karagiannis et al.

zu beachten, dass die Geschäftstransformation in Programme und Projekte strukturiert werden muss, damit diese steuerbar bleiben. Große Unternehmen fahren oftmals mehrere Transformationsprogramme parallel (vgl. Proper et al. 2017). Diese müssen mit der Unternehmensstrategie, welche die externen und internen Einflussfaktoren berücksichtig, in Einklang gebracht werden. Die Steuerung und Ausgestaltung des Wandels erfolgen auf Basis der Erkenntnisse, die der digitale Zwilling liefert. In den Kapiteln des vorliegenden Buchs wird erläutert, wie ein digitaler Zwilling einer agilen Organisation oder eines relevanten Teils davon erstellt werden kann. Es wird aufgezeigt, wie Architekturartefakte dabei unterstützen können, die für die Organisation relevanten Strategien zu entwickeln, umzusetzen und zu evaluieren. Ein wesentlicher Aspekt, der in den verschiedenen Kapiteln behandelt wird, ist auch, die Nachhaltigkeit notwendiger Architekturteile sicherzustellen. In diesem Zusammenhang geht es um inkrementelle Änderungen, wie z. B. Prozessanpassungen oder Technologie-Updates, die von Zeit zu Zeit notwendig werden. Auch für diese liefert die Architektur als Teil des digitalen Zwillings Antworten. Als Basis für die Beschreibung des digitalen Abbilds der Organisation und dessen Ecosystems stehen zahlreiche Modellierungssprachen zur Verfügung. Diese können beliebig kombiniert werden, um die für die Geschäftstransformation relevanten Sachverhalte abzubilden und analysierbar zu machen. Eine Vielzahl an Implementierungen derartiger Modellierungssprachen bietet beispielsweise die Non-Profit-Organisation OMiLAB (vgl. Karagiannis et al. 2016). Im vorliegenden Buch wird die Modellierungssprache ArchiMate® (vgl. The Open Group 2019) als Basis verwendet.

1.2 Fokus und Zielgruppe des Buchs Dieses Buch ist als Herausgeberschaft konzipiert. Es werden einzelne, wichtige Aspekte des Unternehmensarchitektur-Managements als Methode zur Gestaltung der Geschäftstransformation herausgegriffen und vertiefend behandelt. Jedes der Kapitel basiert auf Erfahrungen und Erkenntnissen aus erfolgreichen Unternehmensarchitektur-Initiativen der Autoren. Im vorliegenden Buch finden sich ausschließlich EA-Szenarien, die sich als Best Practice etabliert haben. Jedes der beschriebenen Szenarien wurde mehrfach von den Autoren erfolgreich in Unternehmen eingeführt. Die Szenarien halten somit dem erforderlichen Realitätscheck stand. Das Buch richtet sich nicht nur an Unternehmensarchitekten, sondern an alle Rollen im Unternehmen, die an einer dauerhaften und zukunftsorientierten Ausrichtung des Unternehmens interessiert sind und aktiv daran mitgestalten: • Unternehmensarchitekten müssen sich auf benutzer-zentrierte und messbare Ergebnisse ihrer Architekturarbeit fokussieren. Ergebnisse ihrer Arbeit dürfen nicht ausschließlich Architekturdokumentationen sein, die den unternehmensinternen Benutzern (Mitarbeitern) zur Verfügung gestellt werden. Vielmehr müssen Unter-

1 Einleitung

•

•

•

•

•

7

nehmensarchitekten Potenziale identifizieren und geeignete Transformationsvorhaben zum Heben dieser Potenziale entwickeln. Kap. 4 fokussiert auf das Transformationsportfolio, Kap. 10 auf die Einbindung der Benutzer bei der Ausgestaltung der Architekturen. Geschäftsarchitekten fokussieren in den Transformationsvorhaben auf die Geschäftsarchitektur und verfügen über Domänen-Know-How. Sie erarbeiten, welche Fähigkeiten das Unternehmen durch Transformationsvorhaben aufbauen und dauerhaft etablieren muss. Die Kenntnis des Status-Quo hilft ihnen dabei, den Fokus der Transformationsvorhaben auf relevante Fähigkeiten zu lenken, sodass die notwendigen Veränderungen auf strategischer Ebene definiert und in weiterer Folge umgesetzt werden können. In Kap. 5 wird beschrieben, wie „Capability-based Planning“ den Grundstein dazu legen kann. IT-Architekten haben sowohl die Applikationslandschaft als auch die zugrunde liegende Technologiearchitektur im Blick. Sie müssen die aktuell im Einsatz befindlichen Applikationen und Technologien kennen und bewerten. Als ­Technologie-Scouts müssen sie das Marktpotenzial neuer innovativer Technologien erkennen und überlegen, welchen Mehrwert sie durch deren Einsatz im Unternehmen für den Benutzer generieren können. Durch die Konsolidierung der Applikations- und Technologiearchitektur setzen sie Budgets für Innovationen frei. Durch das Erkennen der Potenziale innovativer Technologien tragen sie entscheidend zur Gestaltung einer erfolgreichen Zukunft des Unternehmens bei. In den Kap. 6 und 8 werden die wesentlichen Methoden zu diesem Themenkomplex vorgestellt. Applikationsverantwortliche und Technologieverantwortliche kümmern sich um die von ihnen verantworteten Systeme. Sie verfolgen die Entwicklung von Standards und Vorgaben und kümmern sich operativ darum, dass diese für ihre Systeme eingehalten und genutzt werden. Sie tragen entscheidend zur Schaffung einer schlanken Dokumentation über die Applikations- und Technologiearchitektur bei und werden als Experten im Rahmen von Transformationsvorhaben beigezogen. In den Kap. 6 und 8 finden sich weitere Informationen zu ihrem Beitrag an der Gestaltung der Unternehmensarchitektur. Datenarchitekten sind verantwortlich für die Datenqualität. Sie müssen wissen, welches die wesentlichen Datenelemente im Unternehmen sind, die in den Ist- und Zielarchitekturen benötigt werden. Sie geben Empfehlungen zu bestmöglichen Datenquellen und unterstützen bei der Definition effizienter Datenflüsse. Durch die Kenntnis der Datenstrukturen sind sie in der Lage, neue datenbasierte Produkte und Geschäftsservices zu entwickeln. Wie ein zielgerichtetes und ausreichend dimensioniertes Datenmodell als Informationsquelle für architekturrelevante Transformationsvorhaben aufgebaut wird, wird in Kap. 7 erläutert. Lösungsarchitekten bauen Lösungsarchitekturen im Rahmen von Projekten. Zu diesem Zweck verfeinern sie die Architekturdesigns. Sie müssen die Regeln der Unternehmensarchitektur kennen (Standards, Architekturprinzipien) und benötigen daher ein grundlegendes Verständnis von Unternehmensarchitektur-Management. Ihre Akzeptanz zu gewinnen, ist ein entscheidender Erfolgsfaktor für Architekturinitiativen.

8

D. Karagiannis et al.

• Risiko- und Compliance-Manager werden bereits in der Designphase der Architekturen gefordert. Sie nutzen die in den Kap. 4, 5, 6, 7 und 8 beschriebenen Architekturdokumentationen als Eckpfeiler für Compliance- und Risikoanalysen. Im Kap. 9 wird beschrieben, wie beispielsweise der IT-Grundschutz oder die Einhaltung von Architekturprinzipien sichergestellt werden können. Risiko- und ­Compliance-Manager identifizieren Risiken, die sich aus der Non-Compliance der Architekturen mit Architekturprinzipien, selbstauferlegten Normen oder gesetzlichen Vorgaben ergeben. • Architektur-Sponsoren sind die Auftraggeber und Geldgeber für die Architekturarbeit. Sie müssen den Nutzen von EA verstehen und dessen Mehrwert erkennen. • Das Unternehmensmanagement – darunter fallen auch CIOs (Chief Information Officers) und CDOs (Chief Digital Officers) – trägt die endgültige Entscheidung und somit auch die Verantwortung für den Erfolg der Transformationsvorhaben. Sie sollten die hier beschriebenen EA-Szenarien und Konzepte kennen und deren Ergebnisse einfordern, um eine faktenbasierte Entscheidungsgrundlage für die zukünftige Ausrichtung des Unternehmens an der Hand zu haben. In der Regel treten Teile des Managements als Architektur-Sponsoren auf. Selbstverständlich ist es nicht erforderlich, für alle oben beschriebenen Rollen eigene Stellen und Positionen im Unternehmen zu schaffen. Die obigen Beispiele spiegeln lediglich typische Rollen wider, die die Autoren in zahlreichen EA-Projekten in Unternehmen antreffen. Oftmals variiert der Zuschnitt dieser hier eher archetypisch beschriebenen Rollen und noch öfters werden mehrere Rollen in Personalunion wahrgenommen. Die Aufgaben, welchen sich die Rollen im Unternehmen widmen sollten, bleiben jedoch immer die gleichen.

1.3 Struktur des Buchs Das Buch gliedert sich in drei Teile. Im ersten Teil wird die Notwendigkeit der Geschäftstransformation von Unternehmen aufgezeigt. Es wird ein Rahmen für die Geschäftstransformation gespannt, indem wesentliche Methoden und Verfahren zur Bewältigung dieser schwierigen Aufgabe aufgezeigt werden. Im zweiten Teil werden ausgewählte EA-Szenarien, wie z. B. das Transformations­ portfolio-Management, das Applikationsportfolio-Management oder das ­ CompliancePortfolio-Management beschrieben. Gegenstand der EA-Szenarien ist es, die Unternehmensarchitektur kontinuierlich zu bewirtschaften und weiterzuentwickeln. Aus Komplexitätsgründen wird das Thema in unterschiedliche EA-Szenarien strukturiert, die jeweils auf einen bestimmten Aspekt der Unternehmensarchitektur fokussieren. Der dritte Teil fokussiert auf die Notwendigkeit der Einbindung der Benutzererfahrung. Es wird ein Rahmenwerk vorgestellt, welches ermöglicht, Benutzerfeedback systematisch zu sammeln, zu bewerten und in das Design zukünftiger Architekturen einließen zu lassen. Im Detail gliedert sich das Buch in folgende Kapitel (siehe Tab. 1.1):

1 Einleitung

9

Tab. 1.1  Vorstellung der einzelnen Buchkapitel TEIL 1 – Einführung: Geschäftstransformation und Unternehmensarchitektur-Management 1 Einleitung Dieses Kapitel gibt einen Überblick über das Buch. Es motiviert die Notwendigkeit der Geschäftstransformation und betont die Notwendigkeit einer benutzer-zentrierten Vorgehensweise. Es stellt die Kapitelstruktur des Buches vor und gibt eine Leseempfehlung für das Buch. 2 Geschäftstransformation – Eine Notwendigkeit In diesem Kapitel wird die Notwendigkeit zur Geschäftstransformation diskutiert. Es werden wesentliche Einflussfaktoren beleuchtet. Dabei liegt der Fokus auf den Elementen der Organisation, auf die die Transformation wirkt. Es werden wesentliche Phasen des Transformationsprozesses vorgestellt. Unternehmensarchitektur-Management wird als Lösungsansatz motiviert. 3 TOGAF®, und Co. – Wozu EA-Szenarien? In diesem Kapitel wird TOGAF®’s Architecture Development Method (ADM, vgl. The Open Group 2018, Part II, Kap. 4) als Verfeinerung des Phasenmodells zur Geschäftstransformation vorgestellt. Die Modellierungssprache ArchiMate® wird für die Detaillierung der Kernelemente präsentiert. Es wird auf die Stärken und Schwächen dieser beiden Standards eingegangen und erklärt, warum EA-Szenarien eine wesentliche Bereicherung für Transformationsvorhaben darstellen. Jedes einzelne EA-Szenario wird mit den Phasen der TOGAF® ADM in Kontext gesetzt. TEIL 2 – Typische Szenarien: EA-Portfolios 4 Transformationsportfolio-Management In diesem Kapitel werden Transformationsvorhaben identifiziert und geplant. Ausgehend von der zu definierenden Unternehmensstrategie wird ein Ideenportfolio verwaltet und laufend bewertet. Zu diesem Zweck werden die relevanten Ideen als Kandidaten für Transformationsvorhaben beschrieben. Für jeden dieser Kandidaten wird eine Roadmap erstellt, sodass initiale KostenNutzen-Schätzungen möglich werden. Das Ergebnis sind die vielversprechendsten Transformationsvorhaben, die nach Freigabe des Managements jeweils einen ADM-Zyklus anstoßen und über dessen Phasen abgewickelt werden. 5 Capability-Portfolio-Management Kap. 5 fokussiert auf sogenannte Fähigkeiten (engl. Capabilities) von Organisationen. Dokumentiert in Form von Capability-Maps bilden diese das ideale Werkzeug zur planvollen Ausrichtung des Unternehmens und erlauben einen ganzheitlichen Blick darauf. Stärken und Schwächen des Unternehmens werden identifiziert. Handlungsbedarfe, insbesondere in Hinblick auf die strategische Weiterentwicklung des Unternehmens, werden aufgezeigt. In weiterer Folge dient die Fähigkeitskarte der Ausrichtung und Positionierung der Transformationsvorhaben, aber auch den EA-Szenarien, wie bspw. der Harmonisierung der Anwendungslandschaft. Sie ist der Dreh- und Angelpunkt für die strategische Ausrichtung und für die operative Ausgestaltung der Geschäftsmodelle. 6 Applikationsportfolio-Management Auf der Ebene der Informationssystem-Architektur stellt Konsolidierung ein Kernthema dar. Bestehende Applikationslandschaften müssen „entrümpelt“ werden, sodass Kapazitäten zur Erschließung neuer Geschäftsfelder und von Geschäftsinnovationen freigesetzt werden können. Der Ausbau des Applikationsportfolios spielt für die digitale Transformation eine Schlüsselrolle. In diesem Kapitel wird erläutert, wie die Methode zum Applikationsportfolio-Management aussieht, welche im Ergebnis Maßnahmen bzw. Investitionsstrategien für Applikationen festlegt. Diese bilden die Entscheidungsgrundlage in den jeweiligen Transformationsvorhaben und Projekten. (Fortsetzung)

10

D. Karagiannis et al.

Tab. 1.1   (Fortsetzung) 7 Datenportfolio-Management Das Datenportfolio ist ein wichtiger Bestandteil jeder EA-Initiative. Egal, ob es um die Einführung neuer Produkte oder Geschäftsservices, die Gestaltung neuer Wertschöpfungsketten, die Optimierung bestehender Geschäftsprozesse oder um Kundenbindungsprogramme geht, die zugrunde liegenden Daten müssen in ausreichender Qualität bereitgesellt werden. Unternehmen sammeln immer größere Mengen an Daten. Zugleich steigt die Änderungshäufigkeit der Daten dramatisch. Es muss identifiziert werden, über welche Daten das Unternehmen verfügt. Gleichzeitig muss festgelegt werden, wer für diese verantwortlich zeichnet und welchen Qualitätsansprüchen die Daten genügen müssen. Außerdem muss das Potenzial der vorhandenen Daten erkannt werden. In diesem Kapitel wird beschrieben, wie ein effizientes und schlankes DatenportfolioManagement aufgesetzt werden kann und wie dieses über passende Daten und Datenquellen zur Realisierung von datengetriebenen Anforderungen in Transformationsvorhaben informiert. 8 Technologieportfolio-Management Der Schwerpunkt in diesem Kapitel liegt auf der Konsolidierung der eingesetzten Technologien. Jene, die zur Differenzierung am Markt beitragen, müssen von Commodity-IT, also jenen die für den Betrieb bestehender Systeme benötigt werden, getrennt betrachtet werden. Durch die Konsolidierung der Commodity-IT werden Kapazitäten für Innovationen geschaffen. Eine zielgerichtete und kommunizierbare Technologie-Roadmap gibt in den Transformationsvorhaben Hilfestellung zur Wahl der richtigen Technologien und Technologieplattformen. Es dürfen aber nicht nur bereits genutzte Technologien bewertet werden. Ein Fokus muss auch auf neuen Technologien liegen. Technologieportfolio-Management spielt somit auch eine wesentliche Rolle im Innovationsmanagement. 9 Compliance-Portfolio-Management Ob aufgrund nationaler Vorgaben, internationaler Verpflichtungen oder aus internen Gründen: Compliance-Portfolio-Management ist für alle Unternehmen und quer durch alle Branchen ein zentrales Thema. Aufgrund der heutigen Digitalisierungsinitiativen wächst dessen Bedeutung noch weiter. Durch die Vielzahl an Standards und Vorgehensweisen wird die Umsetzung jedoch oft auch als bürokratisch und wenig nutzen-stiftend empfunden. In diesem Kapitel wird beschrieben, wie ein Compliance-Portfolio-Management entlang der TOGAF® ADM aufgebaut und im Unternehmensarchitektur-Management pragmatisch verankert werden kann. Kernthemen sind die Compliance zu selbstauferlegten Architekturprinzipien und zu sicherheitsrelevanten Anforderungen. Das Thema Compliance ist untrennbar mit Informationssicherheits-Management verbunden. Die Überlappungen dazu werden aufgezeigt. TEIL 3 – Benutzererfahrung: Näher an den Nutzer! 10 Benutzererfahrung als Wegweiser in der Geschäftstransformation Benutzererfahrung spielt bei der Ausgestaltung der Unternehmensarchitektur eine wesentliche und gleichzeitig oftmals unterschätzte Rolle. In diesem Kapitel wird eine fragebogen-basierte Methode vorgestellt, um Benutzererfahrung systematisch zu sammeln und zu bewerten. Somit werden auch subjektive Erfahrungen der Benutzer im Architekturdesign berücksichtigt. 11

Wesentliche Konzepte aus ArchiMate® kurz zusammengefasst

In diesem Kapitel werden die wesentlichen Gestaltungsobjekte im UnternehmensarchitekturManagement kurz zusammengefasst. Im Mittelpunkt der Betrachtung stehen die Konzepte aus ArchiMate®. Diese werden auch in den vorangegangenen Kapiteln zur Beschreibung der Architekturausschnitte genutzt. Für jedes dieser Konzepte werden – neben einer kurzen Definition – aussagekräftige Beispiele genannt. Die Bedeutung der Gestaltungselemente für die im Buch vorgestellten EA-Szenarien wird hervorgehoben.

1 Einleitung

11

1.4 Leseempfehlung für des Buch Die vorliegende Herausgeberschaft greift einzelne EA-Szenarien auf und vertieft diese. Die Kapitel können grundsätzlich einzeln, d. h. unabhängig voneinander, gelesen werden. Der Zusammenhang der Kapitel untereinander wird über die TOGAF® ADM hergestellt. Zusätzlich dienen Verweise auf andere Kapitel dazu, dem Leser einen schnellen Einstieg in verwandte Themengebiete zu geben. Die Kapitel des Buchs können getrennt voneinander gelesen werden, um so dem Arbeitsalltag gerecht zu werden und eine schnelle Vertiefung des jeweiligen Themenfelds zu ermöglichen. Es wird allerdings grundlegendes Wissen zum Thema ­Unternehmensarchitektur-Management vorausgesetzt. Jedes Kapitel stellt Aktivitäten und Handlungsempfehlungen bereit, mit denen das entsprechende EA-Szenario umgesetzt werden kann. Sie werden ergänzt durch zugehörige Geschäftsrollen und detaillierte Techniken. Es werden typische Arbeitsergebnisse vorgestellt. Schließlich werden anhand eines durchgehenden Beispiels eines ­Ski-Ressorts die EA-Szenarien untermauert. Warum ein Ski-Ressort? Während ein Großteil der übrigen Literatur zum Thema EA sich an Beispielen aus der Finanzwelt bedient, hat die Digitalisierung mittlerweile in viele weitere Sektoren und Industriezweigen, wie bspw. dem Fremdenverkehr, der Produktion, der Landwirtschaft oder dem Gesundheitswesen, Einzug gehalten. Die Produkte und Dienstleistungen von Unternehmen dieser Branchen sind in der Regel weniger informationslastig. Die Auswirkungen der Digitalisierung auf Unternehmen dieser Branchen sind jedoch nicht minder dramatisch. Ein Ski-Ressort als durchgängiges Beispiel zu wählen, soll dem Leser ohne Finanz-Expertise greifbarere Einblicke bieten und zudem illustrieren, dass die Notwendigkeit von Digitalisierung und Unternehmenstransformation branchen-unabhängig ist. Dem Leser mit Finanz-Expertise soll es hingegen Einblick in eine andere Branche bieten und damit ggf. Ideen liefern, die sich auf die Finanzwelt übertragen lassen. Es ist an der Zeit, dass sich Unternehmen aller Sektoren dem Thema in einer systematischen Art und Weise stellen. INFO

In den vorgestellten EA-Szenarien spielen die wesentlichen Gestaltungselemente einer Unternehmensarchitektur eine wichtige Rolle. Um ein einheitliches Vokabular in einer verständlichen Sprache über alle Kapitel des Buchs hinweg sicherzustellen, wird die Modellierungssprache ArchiMate® verwendet. Kap. 11 beinhaltet ein Glossar, welches die verwendeten Gestaltungselemente aus ArchiMate® näher beschreibt.

12

D. Karagiannis et al.

Literatur Blumenthal, Andrew. 2008. An introduction to user-centric enterprise architecture. https:// de.slideshare.net/ablumen/article-dm-review-050208. Zugegriffen: 3. Juni 2019. Brenner, Walter, et al. 2014. User, use & utility research. Business & Information Systems Engineering 6:55–61. Forrester. 2020. Age of the customer. Age of the customer. https://go.forrester.com/blogs/category/ age-of-the-customer/. Zugegriffen: 31. März 2020. Karagiannis, Dimitris, Robert Andrei Buchmann, Patrik Burzynski, Ulrich Reimer, und Michael Walch. 2016. Fundamental conceptual modeling languages in OMiLAB. In Domain-specific conceptual modeling, Hrsg. Dimitris Karagiannis, Heinrich C. Mayr, und John Mylopoulos, 3–30. Cham: Springer. Proper, Henderik A., Robert Winter, Stephan Aier, und Sybren De Kinderen. 2017. Architectural coordination of enterprise transformation. Cham: Springer. The Open Group. 2018. The Open Group Architecture Framework TOGAF® Version 9.2. https:// pubs.opengroup.org/architecture/togaf9-doc/arch/. Zugegriffen: 27. Juli 2020. The Open Group. 2019. ArchiMate 3.1 Specification. Uludag, Ömer, Martin Kleehaus, Niklas Reiter, und Florian Matthes. 2019. What to expect from enterprise architects in large-scale agile development? A multiple-case study. In AMCIS: Americas Conference on Information Systems. Cancún, Mexico.

2

Geschäftstransformation – Eine Notwendigkeit Dimitris Karagiannis, Christoph Moser und Anke Helmes

Inhaltsverzeichnis 2.1 Einflussfaktoren und Transformationsauslöser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2 Gegenstand der Transformation in Organisationen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.3 Von der Organisation zum Ecosystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.4 Der Kontinuierliche Prozess der Transformation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.5 Enterprise Architecture Management zur Steuerung der Transformation. . . . . . . . . . . . . . 26 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.1 Einflussfaktoren und Transformationsauslöser Der unternehmerische Erfolg einer Organisation hängt nicht nur von qualitativ hochwertigen Produkten und effizienten Geschäftsprozessen ab. Stattdessen gibt es zahlreiche Faktoren im Umfeld einer Organisation, die sich auf den Geschäftserfolg auswirken. Viele davon können von der Organisation kaum oder gar nicht beeinflusst werden. Organisationen müssen diese externen Einflussfaktoren im Auge behalten D. Karagiannis  Universität Wien/Research Group Knowledge Engineering, Wien, Österreich E-Mail: [email protected] C. Moser (*)  BOC Products & Services AG, Wien, Österreich E-Mail: [email protected] A. Helmes  BOC Information Technologies Consulting GmbH, Berlin, Deutschland E-Mail: [email protected] © Der/die Herausgeber bzw. der/die Autor(en), exklusiv lizenziert durch Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 D. Karagiannis et al. (Hrsg.), Benutzerzentrierte Unternehmensarchitekturen, https://doi.org/10.1007/978-3-658-30537-6_2

13

14

D. Karagiannis et al.

und ­vorausschauend bewerten, um sowohl Chancen als auch Risiken zu identifizieren. Geschäftstransformation ist der Prozess der Veränderung, der beschritten werden muss, um auf diese Einflussfaktoren angemessen zu reagieren. Ein Beispiel für solche Einflussfaktoren sind neue gesetzliche Anforderungen. Man denke an die Datenschutzanforderungen, die sich aus den neuen EU-Bestimmungen zum Umgang mit Personendaten ergeben (vgl. European Parliament und Council 2018). Diese bringen für zahlreiche Organisationen Herausforderungen in Hinblick auf die Neugestaltung ihrer betrieblichen Abläufe und den zugrunde liegenden IT-Services mit sich. Aktuelle Verhandlungen zu Freihandelsabkommen oder politische Großereignisse, wie das Brexit-Referendum, sowie die Unsicherheit, die mit derartigen Ereignissen einhergehen, sind ein Beispiel für politische Faktoren. Diese haben unvermeidliche Auswirkungen auf Organisationen. Zum Teil müssen bestehende Verträge überarbeitet werden, neue Partner gesucht werden oder sogar Unternehmensstandorte hinterfragt bzw. ggf. gar verlegt werden. Werbeverbote für bestimmte Produktkategorien oder spezielle Auflagen bei der Produktgestaltung sind weitere Beispiele für politische Faktoren. Diese Einflussfaktoren müssen länderspezifisch betrachtet und berücksichtigt werden. Aus ökologischer Sicht beeinflussen Umweltfaktoren die Unternehmensperformance. Umweltfreundliche und nachhaltige Produktion sowie klimaneutrale Herstellungsprozesse werden vielfach zum Muss für verantwortungsbewusste Organisationen. Dies gilt spätestens dann, wenn diese in Form von Umweltschutzauflagen vom Gesetzgeber eingefordert werden. Extremwetterereignisse als Folge des Klimawandels sind ein weiteres Beispiel, die einer Risikoeinstufung bedürfen und entsprechende strategische Maßnahmen fordern. Werte, Einstellungen und Verhaltensweisen der Kunden, Mitarbeiter und Lieferanten unterliegen ebenfalls einer stetigen Veränderung. Diese müssen im Auge behalten werden. Die Analyse sogenannter sozio-kultureller Faktoren lässt auch Rückschlüsse auf erforderliche Produkteigenschaften im Hinblick auf Kundenwünsche zu. Das gesteigerte Umwelt- und Gesundheitsbewusstsein von Konsumenten und potenzieller Kunden sowie der Wunsch nach Individualisierung von Produkten sind konkrete Beispiele. Analysten sprechen in diesem Zusammenhang vom Zeitalter des Kunden. Die Erwartungen der Kunden sind enorm hoch: Sie fordern ein nahtloses Einkaufserlebnis auf unterschiedlichen Kanälen. Aus Organisationssicht muss somit der Kunde – als Benutzer oftmals digitalisierter Services, die entlang der Customer Journey angeboten werden – in den Mittelpunkt gestellt werden. Die Digitalisierung des Kundenerlebnisses ist somit aktuell eines der Topthemen in Veränderungsprojekten. Abb. 2.1 zeigt eine Kategorisierung von externen Faktoren, wie diese üblicherweise in Umfeldanalyse-Methoden, wie PESTLE (vgl. del Marmol und Feys 2015), vorgenommen wird. Generell scheint die zunehmende Digitalisierung die Diskussion um die notwendige Geschäftstransformation vieler Organisationen zu dominieren. ­Geschäftstransformation

2  Geschäftstransformation – Eine Notwendigkeit

POLITISCH

RECHTLICH

ÖKOLOGISCH

15

WIRTSCHAFTLICH

GESELLSCHAFTLICH

TECHNOLOGISCH

Abb. 2.1   Einflussfaktoren für Organisationen – Notwendigkeit für Geschäftstransformation

wird vielfach und wohl auch berechtigter Weise mit digitaler Transformation gleichgesetzt. Insbesondere digitale Technologien schaffen in rasendem Tempo neue Herausforderungen für Organisationen. Sie bieten Organisationen einerseits die Chance, bestehende Geschäftsfelder zu optimieren oder sich am Markt gänzlich neu zu positionieren. Andererseits bergen diese oftmals als „disruptiv“ bezeichneten Technologien für viele Organisationen auch Risiken. Beispiel

Nostalgikern unter den Lesern sind vielleicht noch die Rechenmaschinen der Firma Facit ein Begriff. Die in den 1930er-Jahren entwickelte mechanische Rechenmaschine verhalf dem gleichnamigen schwedischen Unternehmen zu ungeahnten Erfolgen. Die Geräte wurden in die ganze Welt verkauft. Facit wurde zum Aushängeschild der schwedischen Wirtschaft. Mit lediglich ästhetischen Modifikationen blieb das Produkt über 40 Jahre im Wesentlichen unverändert am Markt. Anfang der 1970er-Jahre wirbelten in Japan gefertigte elektronische Taschenrechner den Markt kräftig durcheinander. Mechanische Taschenrechner wurden allerorts durch elektronische ersetzt. Facit hatte den technologischen Trend zu spät erkannt (vgl. Sandström 2011). Die Benutzer favorisierten die technisch bessere Lösung. Der Rest ist Geschichte. Beispiele wie dieses gibt es viele. ◄ Das Thema ist also nicht neu. Ein wesentlicher Unterschied liegt allerdings in der Dynamik der Entwicklungen. Während vor 20–30 Jahren die Geschäftstransformation wohl nicht zum Alltagsgeschäft der Unternehmensführung gehörte, muss das Unter-

16

D. Karagiannis et al.

Abb. 2.2    Evolutionärer Stammbaum. Bild HKRWW8 Darwin tree cut, Bildanbieter: ART Collection/Alamy Stock Foto, inspiriert durch 100 Diagrams that Changed the World (vgl. Christianson 2012)

nehmensmanagement heutzutage permanent auf Veränderungen reagieren. Geschäftstransformation muss als Alltagsgeschäft in den Führungsetagen der Organisationen verstanden werden. Es erscheint als erwiesen, dass Unternehmen ihren Geschäftserfolg nicht allein durch Optimierung bestehender Prozesse und der zugrunde liegenden IT-Landschaften sicherstellen können. Zunehmender Wettbewerbsdruck erfordert die ­ Anpassungen der Geschäftsmodelle und der unterstützenden Geschäftsprozesse und Technologien in immer kürzer werdenden Zyklen. Die Bedürfnisse der Benutzer müssen in den Mittelpunkt des geschäftlichen Handelns gesetzt werden. INFO

In seinem Notizbuch B skizzierte Darwin 1837 erstmals seine Idee vom Stammbaum des Lebens (vgl. Abb. 2.2). Der Baum galt lange als Sinnbild der Evolution. Doch schon Darwin haderte mit dem Symbol. Heute zeigt sich: Für die Evolution der Bakterien ist Darwins Evolutionsbaum völlig ungeeignet. Immer noch Gültig-

2  Geschäftstransformation – Eine Notwendigkeit

17

keit hat allerdings Darwins bekannter Ausspruch: „Es ist nicht die stärkste Spezies, die überlebt, auch nicht die intelligenteste, sondern diejenige, die am anpassungsfähigsten auf Veränderungen reagiert.“ Das Gleiche gilt für die Geschäftswelt. Unternehmen müssen flexibel auf neue Geschäftsanforderungen reagieren können, sodass ihre Zukunft langfristig gesichert bleibt.

2.2 Gegenstand der Transformation in Organisationen Der aus den Umweltfaktoren resultierende Anpassungsbedarf wirkt auf die Geschäftsmodelle der Organisation und somit auf alle wesentlichen Gestaltungselemente der Organisation. Bereits Ende der 1990er-Jahre streichen Bayer et al. (1999) die Kernelemente Produkt, Geschäftsprozess, Organisation und (Informations-)Technologie als die wesentlichen Teile des Geschäftsmodells von Organisationen heraus. Die Elemente stehen in einer Wechselbeziehung und sind voneinander abhängig (siehe Abb. 2.3). Während bis zu diesem Zeitpunkt Reengineering-Ansätze – allen voran die Konzepte von Hammer, Champy und Davenport (vgl. Hammer und Champy 2009; Davenport

PRODUKT PROZESS

ORGANISATION

TECHNOLOGIE

Abb. 2.3   Gestaltungselemente einer Organisation als Gegenstand der Transformation

18

D. Karagiannis et al.

1993) – auf die Geschäftsprozesse der Organisation fokussieren, motivieren Bayer et al. die Notwendigkeit der ausgewogenen Betrachtung der Kernelemente. Sie beschreiben, dass Anforderungen der Benutzer und somit Anpassungen an Produkten oder des Produktsortiments zu notwendigen Adaptierungen der Geschäftsprozesse führen. Organisation und Technologien werden als Ressourcen betrachtet, die vor diesem Hintergrund optimal eingesetzt werden müssen, um Mehrwert für die Kunden zu schaffen. Diese Sichtweise hat auch heute noch Gültigkeit. Aktuelle Methoden zur Beschreibung von Geschäftsmodellen – wie etwa jene des Business Model Canvas (vgl. Osterwalder und Pigneur 2010) – beschreiben im Wesentlichen diese vier Kernelemente und deren Zusammenspiel mit Fokus auf den Wertbeitrag für die Kunden. Allerdings hat sich in den vergangenen Jahren durch den rasanten technologischen Fortschritt und die immer enger werdenden Innovationszyklen dieses Bild gedreht. Heute sind vielfach neue Technologien die Auslöser und gleichzeitig die Enabler, welche Geschäftsinnovationen möglich machen. In vielen Branchen treiben die Technologien die notwendige Geschäftstransformation voran. Aus Produkt und Dienstleistungssicht ermöglichen es neue Technologien, die bestehenden Produkte und Dienstleistungen zu erweitern und zu digitalisieren, um den Anforderungen der Benutzer gerecht zu werden. Es werden aber auch völlig neue Produkte und Dienstleistungen geschaffen. Organisationen stehen vor der Herausforderung, relevante Technologien frühzeitig zu identifizieren, um festzulegen, welche Produkte und Services die Benutzer zukünftig begeistern. Die Leistungserbringungsprozesse unterliegen ebenfalls einem Wandel. Robotic Process Automation (RPA), Advanced Learning und Cognitive Computing sind nur einige der neuen technischen Konzepte, die es zu nutzen gilt. Es geht darum, menschliche Arbeit durch Maschinen effizient zu unterstützen und in einigen Bereichen komplett zu ersetzen. Das passiert heutzutage in allen Bereichen der Wertschöpfungskette: angefangen bei den Prozessen in Finance oder IT über Produktion und Logistik bis hin zum Kundenservice. Aus Organisationssicht erfordert die Optimierung der Leistungserbringungsprozesse die Vernetzung aller am Leistungserbringungsprozess beteiligten Stakeholder und somit der gesamten Wertschöpfungskette. Zu diesem Zweck müssen Datensilos zugunsten eines „Daten-Ecosystems“ abgetragen werden, sodass alle Abteilungen von der Beschaffung über die Fertigung bis hin zum Verkauf und zum Kundendienst mit adäquaten Daten versorgt werden können. Gleichzeitig müssen Mitarbeiter auf die Digitalisierung und den dafür erforderlichen Kulturwandel vorbereitet werden. Nur wenn die notwendige Veränderungsbereitschaft auf allen Ebenen der Organisation gelebt wird, kann Geschäftstransformation erfolgreich bewerkstelligt werden. Die Liste der Schlagwörter technologischer Innovationen ist lang. Grob können die Hebel, die sich aus dem technologischen Fortschritt und aus der Digitalisierung ergeben (vgl. Bouee und Schaible 2015, S. 19 ff.) in folgende Kategorien unterteilt werden: • Datennutzung: Bessere Vorhersagen und Entscheidungen durch die Sammlung und Analyse operativer Daten. Daten entstehen nicht nur innerhalb des Unternehmens im

2  Geschäftstransformation – Eine Notwendigkeit

19

Rahmen der Fertigungs- und Leistungserbringungsprozesse, sondern vielfach auch an der Schnittstelle zum Benutzer. Beispiele sind Daten, die von Fahrzeugen oder von tragbaren Devices, wie z. B. Smartphones oder Wearables, gesammelt werden. Daten müssen somit ebenfalls zu den Kernelementen gezählt werden. • Automatisierung: Fortschritte in der Sensortechnik sowie in der Informations- und Kommunikationstechnologie sind die Treiber der Automatisierung. Die Kombination dieser Technologien führt zu sogenannten cyber-physischen-Systemen, bei denen informations- und softwaretechnische Komponenten mit physischen Komponenten, wie Materialien, Geräten, Maschinen und Robotern, verbunden sind (vgl. Bendel 2019). Autonom arbeitende und sich selbst steuernde Produktionsstraßen werden dadurch ermöglicht. • Digitaler Kundenzugang: Technische Konzepte, wie das (mobile) Internet, ermöglichen den direkten Zugang zum Benutzer. Nie waren Unternehmen besser über ihre Benutzer und den Markt informiert als heute. Gleichzeitig sind die Konsumenten besser informiert. Die Herstellung einer virtuellen Nähe zu den Benutzern sowie die Personalisierung von Kundenservices sind wesentliche Bestandteile heutiger und zukünftiger Geschäftsmodelle. • Vernetzung: Es geht um die mobile und leitungsgebundene Vernetzung der gesamten Infrastruktur über hochbreitbandige Telekommunikationsnetzwerke. Dadurch lassen sich Lieferketten synchronisieren und in weiterer Folge Produktionszeiten verkürzen. Die Massenproduktion individualisierter Produkte und Services wird dadurch möglich. Insbesondere die Kategorie „Vernetzung“ wirkt auf die Entwicklung der Organisationen. Die Interaktion mit externen Geschäftspartnern, aber auch mit den Benutzern wird durch die Globalisierung und die digitale Vernetzung immer entscheidender für den Unternehmenserfolg. Die Wertschöpfungskette muss daher gesamtheitlich betrachtet werden.

2.3 Von der Organisation zum Ecosystem Die ursprüngliche Sicht auf das Kernelement Organisation muss zwangsläufig vom initialen Fokus auf die eigene Organisation um das Netzwerk aller Geschäftspartner erweitert werden. Somit spielt die Bereitschaft zur Öffnung des Unternehmens für sein Ecosystem eine zentrale Rolle. Unter Ecosystem ist in diesem Zusammenhang ein Verbund unterschiedlicher Geschäftsstakeholder zu verstehen (vgl. Moore 1993). Diese vernetzen Geschäftsprozesse, Daten und Technologien. Zusammenarbeit und neudeutsch „Value Co-Creation“ stehen im Fokus. Wie in Abb. 2.4 dargestellt, ist nicht nur das eigene Unternehmen, sondern das gesamte Ecosystem den externen Faktoren ausgesetzt. Normalerweise werden nicht alle Produkt- und Servicebestandteile von einer einzelnen Organisation in Eigenregie erbracht. Der Trend zeigt, dass diese a­ rbeitsteilige Organisation zukünftig noch weiter ausgebaut wird. Es geht um die geschickte Nutzung und Kopplung bestehender Services, die es erlauben, das Werteversprechen und den Nutzen für Kunden zu erhöhen. Teilnehmer im Ecosystem fertigen Produktbestandteile

20

D. Karagiannis et al.

Abb. 2.4   Einflussfaktoren wirken auf Organisationen und ihr Ecosystem

und erbringen Dienstleistungen, die erst in weiterer Folge zu einem Produkt mit klarem Wertversprechen und Nutzen für den Benutzer kombiniert werden. Beispielsweise werden physische Produkte durch digitale Zusatzangebote (engl. Digital Add-on) angereichert. Es entstehen Produkte und Produktvarianten, die von einzelnen Organisationen nur schwer oder nicht im erforderlichen Tempo entwickelt und erbracht werden könnten. Aus Organisationssicht geht es dabei um weit mehr als vereinzelte Kooperationen: Unternehmens-Ecosysteme ähneln den Ökosystemen der Natur. Genauso wie in der Natur, in welcher verschiedene Arten von ihren gegenseitigen Fähigkeiten Nutzen ziehen, profitieren die Stakeholder des Unternehmens-Ecosystems voneinander. Organisationen ergänzen ihre eigenen Fähigkeiten mit jenen ihrer Kooperationspartner. So werden sie noch erfolgreicher und schlagkräftiger. Auch die Benutzer sind als Teil dieses Ecosystems und dessen gemeinsamer Wertschöpfung zu verstehen. Dafür ist die Koordination organisationsübergreifender Prozesse notwendig. Zum Beispiel gilt es im Bereich der Beschaffung, Informationsnetzwerke mit Lieferanten aufzubauen. Die Produktion muss organisationsübergreifend gesteuert werden. Daten aus der Produktion müssen mit jenen des eigenen Vertriebs und mit jenen von Vertriebspartnern abgeglichen werden. Serviceeinheiten und Kundendienste müssen eingebunden werden. Die Kernelemente Produkt, Prozess, Organisation, Technologie sowie Daten werden immer enger vernetzt. Abb. 2.5 verdeutlicht diesen Aspekt und zeigt, dass diese Vernetzung organisationsübergreifend erfolgt. Durch die Zusammenarbeit im

2  Geschäftstransformation – Eine Notwendigkeit

21

Abb. 2.5   Vernetzung im Ecosystem erfolgt auf allen Ebenen

Ecosystem kann die Komplexität (etwa durch den Wegfall ausgelagerter Produktionsschritte) verringert werden. Gleichzeitig steigen durch die notwendige Vernetzung Kommunikations- und Koordinationsaufwände. Diese gilt es durch den Einsatz geeigneter Informationstechnologien zu bewältigen wodurch unweigerlich der Komplexitätsgrad im Bereich der Informationstechnologien ansteigt. Organisationen bieten beispielsweise Services, die von anderen Teilnehmern kostenlos oder kommerziell genutzt werden. Geschäftsservices verschiedenster Anbieter werden in die eigenen Geschäftsmodelle eingebunden. Beispielsweise werden zur Zahlungsabwicklung Services von Onlinediensten, wie PayPal genutzt. Unzählige Produkte werden mit digitalen Services, wie z. B. Kartendienste, ­Wetterdaten-Services, Statistische-DatenServices, Tracking-Services und Speech-to-Text-Services angereichert. Auch Mitbewerber sind Teil des Ecosystems. Fallweise schließen sie sich zusammen. Unter dem Schlagwort „Co-opetion“ arbeiten Mitbewerber auf der gleichen Wertschöpfungsstufe zusammen, während sie auf dem Markt für ihre Produkte und Services im Wettbewerb stehen. Auch dieses Thema ist nicht neu. Nalebuff und Brandenburger (1997) beschreiben diese Konzepte bereits Ende der Neunzigerjahre des vergangenen Jahrhunderts. Insbesondere in Hinblick auf die Digitalisierung traditioneller Produkte wird die Zusammenarbeit und Konsolidierung allerdings forciert. Ein oft genanntes Beispiel hierfür ist die Übernahme des Nokia-Kartendienstes Here durch die deutschen Autobauer Daimler, Audi und BMW. Die durch den Dienst bereitgestellten hochpräzisen digitalen Karten

22

D. Karagiannis et al.

werden als entscheidender Baustein für die Mobilität der Zukunft gesehen. Die Hersteller wollten das Feld nicht den großen Plattform-Anbietern alleine überlassen. Zusammenarbeit der konkurrierender Automobilhersteller war die logische Konsequenz. Im Ecosystem werden Organisationen auf allen Ebenen vernetzt. Die heute noch ersichtlichen Unternehmensgrenzen weisen somit zukünftig immer weniger Kontur auf. Jedoch muss jedes Unternehmen seine Rolle im Ecosystem für sich definieren. Unternehmen müssen ihre Geschäftsmodelle neu definieren und weitaus schwieriger: Sie müssen die notwendige Transformation vollziehen. Hieraus ergeben sich natürlich auch Risiken für die Unternehmen. Beispielsweise könnten in die Produkte integrierte (externe) Services vom Markt verschwinden. Ein Aspekt, auf den die Unternehmen in vielen Fällen nicht einwirken können. Derartige Risiken müssen im Blickfeld behalten werden. Ohne Dokumentation und laufender Evaluierung dieser Zusammenhänge wird es nicht gehen.

2.4 Der Kontinuierliche Prozess der Transformation Unternehmenstransformation darf dabei natürlich nicht als einmalige Aufgabe verstanden werden. Vielmehr ist es ein kontinuierlicher Prozess, der vereinfacht dargestellt in folgenden Phasen beschritten wird: Planen – Umsetzen – Monitoren und Verbessern (siehe Abb. 2.6).

UMSETZEN

Abb. 2.6   Unternehmenstransformation in drei Phasen

2  Geschäftstransformation – Eine Notwendigkeit

23

In der Planungsphase werden Geschäftsmodelle hinterfragt und neu definiert. Es geht um die Planung idealer Zielzustände für das Unternehmen unter Berücksichtigung interner Stärken und Schwächen sowie externer Chancen und Risiken. Die Analyse richtet sich auf die Kernelemente: Produkte und Dienstleistungen, Leistungserstellungsprozesse, Organisation und Technologien. Die oftmals etwas oberflächliche Definition eines Geschäftsmodells greift dabei allerdings zu kurz. Das gesamte Unternehmen muss auf den Prüfstand gehoben werden. Die genannten Kernelemente sind die Ausgangsbasis für das zukünftige Organisationsdesign. Natürlich müssen diese im Zuge der Planung weiter detailliert werden. Ihre Zusammenhänge und Wechselwirkungen müssen deutlich herausgearbeitet werden. Nur so ist es möglich, den Weg von der initialen Ausgangsituation bis hin zur Erreichung einer Benutzer-zentrierten Unternehmensvision erfolgreich zu beschreiten. Die Umsetzung der erforderlichen Schritte erfolgt in Projekten. Es müssen Roadmaps erarbeitet werden, die die Erreichung des Zielzustandes ermöglichen. Die Planung derselben muss zielgerichtet erfolgen, darf aber nicht zu starr sein. Geplante Transformationen müssen einen klaren Wertbeitrag für die Organisation aufweisen. Die Umsetzung erfolgt etappenweise in steuerbaren Ausbaustufen. Budgets und Ressourcen sind normalerweise für die meisten Unternehmen ein knappes Gut. Daher muss der Mix an Projekten und Maßnahmen laufend hinterfragt und agil angepasst werden. Die Budgetplanung darf die Transformationsvorhaben nicht für ein oder sogar für mehrere Jahre einzementieren. Nur so kann sichergestellt werden, dass die Organisation in ausreichendem Tempo auf Marktveränderungen reagieren kann (siehe auch Kap. 4). Monitoren und Verbessern ist die Stabilisierungsphase. Der Ist-Zustand des Unternehmens muss überwacht werden. Neuerungen müssen von den Mitarbeitern der Organisation verinnerlicht und institutionalisiert werden. Laufend muss das erreichte gegenüber externen und internen Einflüssen bewertet werden. In diesem Zusammenhang müssen die Bedürfnisse der Benutzer – seien es Kunden oder auch Mitarbeiter – und Möglichkeiten, die sich aus digitalen Trends ergeben, frühzeitig erkannt werden, um neue Transformationszyklen anzustoßen. Unternehmenstransformation darf aber nicht nur in revolutionären Schritten erfolgen. Organisationen müssen zusätzlich kontinuierlich angepasst und „restauriert“ werden. In vielen Fällen müssen gleichzeitig zu mehr oder weniger revolutionären Veränderungen überhaupt erst Hausaufgaben, wie Konsolidierung von Technologien, Harmonisierung von Geschäftsprozessen und Beseitigung von Daten-Silos bewältigt werden, um Potenziale für die anstehenden Geschäftstransformationen freizulegen. Erfolgreiche Geschäftstransformation muss sich somit auch mit inkrementellen Änderungen auseinandersetzten und darf nicht nur auf fundamentale Veränderungen des Geschäftsmodells und des fachlichen und technischen Betriebsmodells (Target Operating Models) fokussieren (vgl. Schallmo und Rusnjak 2017, S. 7). Abb. 2.7 verdeutlicht diesen Sachverhalt. Es steht außer Frage, dass die Geschäftstransformation in der Regel in einer Vielzahl unterschiedlicher und oftmals nicht abgrenzbarer Initiativen erfolgt. Der beschriebene Transformationszyklus „Planen – Umsetzen – Verbessern und Monitoren“ fokussiert

24

D. Karagiannis et al. Auswirkung der Veränderung

MONITOREN UND VERBESSERN

Kontinuierliche Verbesserung und Monitoring zur Sicherstellung des geregelten Betriebs

PLANEN

UMSETZEN

Fundamentale Veränderungen zur Produktivitätssteigerung und Etablierung neuer Geschäftsmodelle Geschäftstransformation

Abb. 2.7   Kontinuierliche Verbesserung und fundamentale Veränderung – Beides muss gesteuert werden!

daher nicht auf das gesamte Unternehmen, sondern auf einzelne Teilbereiche, sogenannte Wirkungsbereiche (engl. Scopes). Es lässt sich leicht erahnen, dass viele derartiger Zyklen gleichzeitig stattfinden. Abb. 2.8 zeigt schematisch eine Reihe an Transformationsvorhaben und deren Abhängigkeiten untereinander. Durch die Umsetzung der Transformationsvorhaben wird die Organisation für die Zukunft gerüstet. Gleichzeitig bringt die Umsetzung derselben auch Unruhe in das Tagesgeschäft. Es gilt die richtige Balance zu finden. Um Reibungsverluste zu vermeiden, bedürfen die durch die Zyklen beschriebenen Transformationsvorhaben der Synchronisation. Das ist keine leichte Aufgabe. Zuallererst muss sichergestellt werden, dass die von der Transformation betroffenen Elemente überhaupt bekannt sind. Dies erfordert eine detailliertere Betrachtung, als jene die man von Geschäftsmodellen à la Business Model Canvas (vgl. Osterwalder und Pigneur 2010) kennt. Während dieses ein ideales Instrument zur Kommunikation des notwendigen Wandels und der zukünftigen Geschäftsmodelle darstellt, eignet sie sich aufgrund ihres eher hohen Abstraktionsgrades nur bedingt für die notwendige Detailanalyse, -abstimmung, -planung und -kommunikation. Die notwendige Planung und Synchronisation müssen auf tieferer Ebene und vor allem auf allen Ebenen der Organisation erfolgen (siehe ebenso Abb. 2.8): • Aus Geschäftssicht muss geplant werden, welche Produkte und Dienstleistungen vermarket werden. Der Aufbau und die Bestandteile der Produkte müssen klar definiert werden. Dabei muss der Nutzen für die Benutzer im Fokus stehen.

2  Geschäftstransformation – Eine Notwendigkeit

25

Geschäftstransformation

Abb. 2.8    Synchronisationsbedarf formationsvorhaben

zwischen

zahlreichen

Zeit

voneinander

abhängigen

Trans-

• Welche Geschäftsfähigkeiten es aktuell gibt und welche Fähigkeiten ausgebaut oder neu geschaffen werden müssen, muss umfänglich abgestimmt werden. Dazu müssen die Fähigkeiten im Detail betrachtet werden. Sie bestehen typischerweise aus einem Bündel an Ressourcen: Geschäftsprozesse, IT-Applikationen, Technologien, Partner, Daten etc. • Es muss geklärt werden, welche Geschäftsprozesse von anstehenden Veränderungen betroffen sind und wie diese in Zukunft gestaltet sein müssen. Die notwendigen betrieblichen Abläufe, die Verantwortung für diese und auch unternehmensübergreifende Schnittstellen müssen geklärt werden. • Geschäftstransformation bedeutet in der heutigen digitalen Welt immer auch Anpassung der Applikationslandschaft. Für jede Applikation braucht es daher eine klar kommunizierbare Strategie. Es muss sichergestellt werden, dass Transformationsvorhaben die Applikationslandschaft im Gleichklang weiterentwickeln, sodass diese wartbar bleibt und die Anforderungen der Benutzer erfüllt werden. • Das Set der eingesetzten Technologien, seien es Basistechnologien, die für den Betrieb der Applikationen erforderlich sind, oder Technologien, die Produktionsprozesse unterstützen oder in Produkten verbaut werden, müssen ebenfalls koordiniert werden. Je größer die technologische Vielfalt, desto größer der einhergehende Wartungsaufwand. Transformationen müssen somit aufeinander abgestimmt sein. Bestehende Technologien müssen schon alleine aus Sicherheitsgründen immer auf dem neuesten Stand gehalten werden, womit unweigerlich auch Aufwände entstehen.

26

D. Karagiannis et al.

• Unternehmen agieren nicht im luftleeren Raum. Insbesondere die Einhaltung gesetzlicher Bestimmungen kann für Unternehmen zum Fallstrick werden. Daher müssen alle Elemente des Unternehmens, seien es Geschäftsprozesse, Daten, Applikationen oder Technologien in Hinblick auf die Einhaltung gesetzlicher Vorschriften oder relevanter Branchenstandards regelmäßig überprüft werden. Aus Compliance-Sicht ist auch die Kommunikation bewährter Lösungsmuster von Interesse. Es sollte vermieden werden, dass einzelne Transformationsvorhaben das Rad neu erfinden, anstatt bestehende Architekturen und Lösungsmuster wiederzuverwenden. Um die geforderten Planungs- und Synchronisationsmechanismen zu etablieren erscheint es also notwendig: • • • • • • • •

eine holistische Sicht auf die Organisation und dessen Ecosystem einzunehmen, interne und externe Einflussfaktoren zu verstehen und deren Auswirkungen zu bewerten, technologische Innovationen und deren Potenzial zu erkennen, die Effizienz und Zukunftssicherheit bestehender Systeme zu bewerten, unnötigen Ballast abzuwerfen und dadurch Freiräume für benutzer-zentrierte Geschäfts- und Produktinnovationen zu schaffen, die Wertschöpfungsketten und Leistungserbringungsprozesse zu optimieren und die Kundenbindung zu erhöhen.

Keine einfache Aufgabe!

2.5 Enterprise Architecture Management zur Steuerung der Transformation Die geforderte holistische Sicht auf das Unternehmen eröffnet den Blick auf die wesentlichen Stellschrauben im Unternehmen. Zusammenhänge zwischen diesen Stellschrauben müssen den Entscheidungsträgern transparent gemacht werden, sodass Auswirkungen von Entscheidungen vorhersehbar werden. Der bereits im Geleitwort motivierte „Digitale Zwilling der Organisation“ – eine modellhafte Beschreibung der Organisation – dient für die notwendigen Analysen als Ausgangsbasis. Als virtuelle Abbildung der Organisation bildet er somit die Brücke zwischen realer und digitaler Welt. Er dient als Ausgangsbasis für fundierte und nachvollziehbare Unternehmensentscheidungen in Hinblick auf die Operationalisierung des Geschäftsmodells. Ein pragmatisches und vor allem benutzer-zentriertes ­ UnternehmensarchitekturManagement unterstützt beim Aufbau dieses digitalen Zwillings der Organisation. Die Unternehmensarchitektur bietet die notwendige solide Datenstruktur, welche in weiterer Folge mit operativen Daten angereichert werden kann. Auf dieser Basis kann die Organisation und deren Ecosystem aus verschiedenen Perspektiven betrachtet und

2  Geschäftstransformation – Eine Notwendigkeit

27

analysiert werden. Sowohl strategische als auch operative Entscheidungen können fundiert getroffen werden.  Definition Unternehmensarchitektur  Zur Präzisierung des Architekturbegriffs wird vielfach auf die Definition des IEEE-Standards 1471–2000 zurückgegriffen, wonach unter einer Architektur die fundamentale Organisation eines Systems, d. h. ihrer Elemente und deren Beziehungen zueinander sowie zur Umwelt, verstanden wird (vgl. Hilliard 2000). Davon abgeleitet wird im vorliegenden Buch Unternehmensarchitektur als die fundamentale Organisation eines Unternehmens, d. h. ihrer (Kern-)Elemente und deren Beziehungen zueinander sowie deren Beziehungen zur Unternehmensumwelt (Ecosystem) definiert. Sie dient als Rückgrat des digitalen Zwillings, in welcher die Elemente um weitere Aspekte, wie zum Beispiel Auswertungen aus operativen Systemen, ergänzt werden. Im Kern geht es darum, ein benutzer-zentriertes Zielbild für das Unternehmen zu entwerfen und die notwendigen Veränderungen zur Umsetzung dieses Zielbilds zu steuern. Dabei wird nicht nur das Unternehmen, sondern auch das Ecosystem, in welches das Unternehmen eingebettet ist, berücksichtigt (vgl. Abschn. 2.3). Die Beschreibung des Zielbilds – der sogenannten Zielarchitektur – hilft den Schlüsselpersonen zu verstehen, wie das Unternehmen gestaltet sein muss, um seine strategischen Ziele zu verwirklichen. Die Unternehmensarchitektur beschreibt dabei das Zusammenspiel von wesentlichen Elementen der geschäftlichen Tätigkeit und der zugrunde liegenden Technologien und Infrastrukturen. In der Zielarchitektur werden diese optimal aufeinander ausgerichtet und ihre Abhängigkeiten nachvollziehbar dokumentiert. Zur Beschreibung und Analyse der Unternehmensarchitektur müssen die Kernelemente detailliert werden, sodass Zusammenhänge auf einer tieferen Detailstufe beschrieben werden können. Das Kernelement „Technologie“ wird beispielsweise oftmals in Elementen, wie Applikationen, Schnittstellen, Systemsoftware, Geräte, Maschinen usw. detailliert. Abb. 2.9 verdeutlicht diesen Aspekt. Unternehmensarchitektur-Management  ­Unternehmensarchitektur Definition Management ist eine Management-Disziplin, welche die Aufgaben zur Erstellung, Pflege und Umsetzung der Unternehmensarchitektur umfasst (vgl. Weber 2013, S. 6). Unternehmensarchitektur-Management bietet Methoden und Techniken, welche die Schärfung der Unternehmensstrategie ermöglichen und in weiterer Folge die zielgerichtete und planvolle Ausgestaltung und Veränderung des Unternehmens steuerbar machen.

Die Etablierung von Unternehmensarchitektur-Management in einer Organisation erfolgt nach Erfahrung der Autoren mit unterschiedlichen Schwerpunkten. Grundsätzlich kann

28

D. Karagiannis et al.

Produkte Services Werte

Kollaboration Prozesse Events

Rollen Stakeholder Organisationen

Maschinen Infrastruktur Applikationen Abb. 2.9   Detaillierung der Kernelemente als Grundlage für eine verlässliche Planung

zwischen projekt-orientierten und portfolio-orientierten Ansätzen unterschieden werden. Architekturframeworks, wie beispielsweise TOGAF® (vgl. The Open Group 2018, Part II, Kap. 4), verfolgen zumeist einen projekt-orientierten Ansatz. Ausgehend von einer Architekturvision wird ein Transformationsvorhaben beschrieben, welches über ein oder mehrere aufeinander ausgerichtete Projekte realisiert wird. Der Wirkungsbereich eines solchen Transformationsvorhabens ist in der Regel ein Teilbereich des Unternehmens. Für diesen gilt es alle relevanten Architekturebenen auszugestalten. Portfolio-orientierte EA-Szenarien hingegen haben die Architekturelemente eines oder mehrerer Architektur-Layer gesamthaft im Blickfeld. Zielsetzung in solchen Szenarien ist es, Verbesserungspotenziale für die betroffenen Architekturebenen systematisch zu identifizieren. Typische Portfolios im ­Unternehmensarchitektur-Management sind das Applikationsportfolio oder das Technologieportfolio. Im Falle von Technologieportfolio-Management können beispielsweise durch die Konsolidierung gleichartiger Technologien über das gesamte Unternehmen hinweg Betriebskosten eingespart werden. Portfolio-orientierte Ansätze ermöglichen auch, Empfehlungen für Transformationsvorhaben auszusprechen. Sie informieren über Schwachstellen, Verbesserungspotenziale und bewährte Lösungsarchitekturen innerhalb der im Fokus stehenden Architekturebene. Die flächendeckende Bestandsaufnahme und Analyse der Ist-Architektur ist dabei einer der wesentlichen Erfolgsfaktoren. Empfehlungen für Transformationsvorhaben und Projekte folgen dabei den für die jeweilige Ebene definierten Architektur-Prinzipien.

2  Geschäftstransformation – Eine Notwendigkeit

Der typische Wirkungsbereich eines Transformationsvorhabens betrifft mehrere Architekturebenen und deckt das Unternehmen in seiner Tiefe ab.

29

Portfolios fokussieren auf einzelne Architekturebenen und decken das Unternehmen in seiner gesamten Breite ab.

Abb. 2.10   Unterschiedliche Wirkungsbereiche projekt- und portfolio-orientierter EA-Ansätze

Abb. 2.10 zeigt den unterschiedlichen Wirkungsbereich klassischer Transformationsvorhaben und der portfolio-orientierten EA-Szenarien. Legt ein Unternehmen den Schwerpunkt ausschließlich auf den ­portfolio-orientierten Ansatz, so besteht die Gefahr, dass das Thema Unternehmensarchitektur nur im „Elfenbeinturm“ vorangetrieben wird. Es werden zwar Zielarchitekturen entwickelt, die Umsetzung solcher fällt allerdings schwer, da in den meisten Fällen die Projektportfolios nicht aus den Zielarchitekturen der Unternehmensarchitekten abgeleitet werden. Noch mehr fällt ins Gewicht, dass durch die oftmals eher isolierte Betrachtung einzelner Architekturebenen ein benutzer-zentrierter Zugang oftmals schwer umzusetzen ist. Der Mehrwert, der sich aus der Implementierung der Architekturempfehlungen ergeben würde, bleibt somit schwer kommunizierbar, da die vorgeschlagenen Änderungen oftmals geschäftsstrategischen Zielen nicht direkt zugeordnet werden können. Die Akzeptanz der Stakeholder bleibt in solchen Fällen gering. Beim projekt-orientierten Ansatz ist dies anders. Durch die Fokussierung auf einen überschaubaren Wirkungsbereich ist der strategische Mehrwehrt einfacher kommunizierbar. Transformationsvorhaben können direkt aus der Unternehmensstrategie abgeleitet werden. Business Cases können pro Projekt respektive pro Transformationsvorhaben erstellt werden. Der unmittelbare Nutzen für die Benutzer kann einfacher dargestellt werden. Fokussiert ein Unternehmen jedoch exklusiv auf die Durchführung einzelner Transformationsvorhaben, so fehlt oftmals die Transparenz über die bestehenden Zusammenhänge im Unternehmen. Die Auswirkungen auf das Unternehmen sowie auf dessen Ecosystem können schwer abgeschätzt werden. Parallellaufende Transformationsvorhaben werden unzureichend synchronisiert und nicht ausreichend aufeinander abgestimmt (vgl. Abschn. 2.4). Mögliche Synergien sind nicht systematisch ableitbar. Dies gilt nicht nur für Großprojekte, sondern auch für „kleinere“ Innovationsprojekte, welche oftmals über agile Management-Ansätze gesteuert werden. Diese sind meistens

30

D. Karagiannis et al.

nicht der breiten Masse der Stakeholder bekannt, sodass es zu Doppelgleisigkeiten kommen kann. Das Wissen und die Strategien zu einzelnen Architekturdomänen (Architekturebenen) werden in diesem Fall nicht systematisch erfasst und kommuniziert. Genau das ist der Schwachpunkt vieler EA-Initiativen. Oftmals wird lediglich – wenn überhaupt – das Projektportfolio systematisch gepflegt. Der Fokus liegt dann naturgemäß auf der Entwicklung neuer Produkte und Geschäftsservices. Die ganzheitliche Betrachtung des Unternehmens rückt dabei in den Hintergrund. Die Lösung der geschilderten Problematik erscheint denkbar einfach: Die Umsetzung von Unternehmensarchitektur-Management bedarf einer Kombination beider ­EA-Ansätze. Die Implementierung eines derartigen kombinierten Ansatzes ist jedoch nicht trivial. In EA-Frameworks wie TOGAF® finden sich kaum Anleihen dazu. Das vorliegende Buch soll zur Bewältigung dieser Aufgabe einen Beitrag leisten. Es werden typische EA-Szenarien vorgestellt und deren Nutzenpotenziale im Rahmen von Veränderungsprojekten diskutiert.

Literatur Bayer, Franz, Stefan Junginger, und Harald Kühn. 1999. Concurrent engineering of service products, business processes and organizational structure. In Proceedings of the 6th European Concurrent Engineering Conference (ECEC 1999), 157–162. Germany: Erlangen-Nuremberg. Bendel, Oliver. 2019. Cyber-physische Systeme. Gabler Wirtschaftslexikon. https://wirtschaftslexikon.gabler.de/definition/cyber-physische-systeme-54077. Zugegriffen: 4. März 2019. Bouee, Charles-Edouard, und Stefan Schaible. 2015. Die Digitale Transformation der Industrie. Roland Berger Strategy Consultans und Bundesverband der Deutschen Industrie eV, Berlin 46: 78. Christianson, Scott. 2012. 100 diagrams that changed the world: From the earliest cave paintings to the innovation of the iPod. New York: Penguin. Davenport, Thomas H. 1993. Process innovation: reengineering work through information technology. Boston: Harvard Business Press. European Parliament and Council. 2018. Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive  95/46/EC (General Data Protection Regulation). https://data.europa.eu/eli/ reg/2016/679/oj. Hammer, Michael, und James Champy. 2009. Reengineering the corporation: Manifesto for business revolution, a. New York: Zondervan. Hilliard, Rich. 2000. IEEEStd-1471-2000 Recommended practice for architectural description of software-intensive systems. IEEE, 12:2000https://standards.ieee.org. del Marmol, Thomas, und Brigitte Feys. 2015. PESTLE analysis: Prepare the best strategies in advance. 50Minutes.com. Moore, James F. 1993. Predators and prey: A new ecology of competition. Harvard Business Review 71:75–86. Nalebuff, Barry J., und Adam M. Brandenburger. 1997. Co-opetition: Competitive and cooperative business strategies for the digital economy. Strategy & Leadership 25:28–33.

2  Geschäftstransformation – Eine Notwendigkeit

31

Osterwalder, Alexander, und Yves Pigneur. 2010. Business model generation: A handbook for visionaries, game changers, and challengers. Hoboken: Wiley. Sandström, Christian. 2011. High-end disruptive technologies with an inferior performance. International Journal of Technology Management 56:109–122. Schallmo, Daniel, und Andreas Rusnjak. 2017. Roadmap zur digitalen Transformation von Geschäftsmodellen. In Digitale Transformation von Geschäftsmodellen, Hrsg. Daniel Schallmo, Andreas Rusnjak, Johanna Anzengruber, Thomas Werani, und Michael Jünger, 1–31. Wiesbaden: Springer. The Open Group. 2018. The Open Group Architecture Framework TOGAF® Version 9.2. Weber, Mathias. 2013. Enterprise Architecture Management-neue Disziplin für die ganzheitliche Unternehmensentwicklung, 2011. https://www.crm-finder.ch/fileadmin/Daten/PDF/studien/ Leitfaden_EAM_Enterprise_Architecture_Management.pdf. Zugegriffen: 29. Juli 2020.

3

Das Zusammenspiel zwischen TOGAF®, ArchiMate® und EA-Szenarien Anke Helmes und David Hauer

Inhaltsverzeichnis 3.1 Einleitung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.2 Der Zusammenhang zwischen der TOGAF® ADM und ArchiMate®. . . . . . . . . . . . . . . . . 37 3.3 Vorstellung der TOGAF® ADM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.3.1 TOGAF®s ADM – Ein iterativer Ansatz. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.3.2 Zwischen den Zeilen lesen – Der Bezug zu Portfolios in TOGAF®. . . . . . . . . . . . 44 3.3.3 Die Phasen der ADM und deren Zusammenspiel mit den EA-Szenarien. . . . . . . . 45 3.4 Struktur und Wertbeitrag der EA-Szenarien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 3.5 Fazit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.1 Einleitung Erfahrungsgemäß wird das Unternehmensarchitektur-Management in Organisationen mit unterschiedlichen Schwerpunkten etabliert. In Kap.  2 wurde diesbezüglich bereits auf die Unterscheidung von projekt-orientierten und portfolio-orientierten Ansätzen eingegangen. Darüber hinaus wurde motiviert, dass sich ein erfolgreiches

A. Helmes (*)  BOC Information Technologies Consulting GmbH, Berlin, Deutschland E-Mail: [email protected] D. Hauer  BOC Products & Services AG, Wien, Österreich E-Mail: [email protected] © Der/die Herausgeber bzw. der/die Autor(en), exklusiv lizenziert durch Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 D. Karagiannis et al. (Hrsg.), Benutzerzentrierte Unternehmensarchitekturen, https://doi.org/10.1007/978-3-658-30537-6_3

33

34

A. Helmes und D. Hauer

­ nternehmensarchitektur-Management häufig nur durch die Kombination beider Ansätze U realisieren lässt. Damit das Unternehmensarchitektur-Management die Umsetzung der Transformation unterstützen kann, muss allerdings das Rad nicht neu erfunden werden. Für die Management-Disziplin „Unternehmensarchitektur-Management“ gibt es zahlreiche bewährte Modelle, Konzepte, Standards, Visualisierungen, Begriffsdefinitionen und Methoden. So genannte Enterprise Architecture Frameworks bieten mehr oder weniger detaillierte Anleihen. Je nach Framework liegt der Schwerpunkt auf der Vorgehensweise für das Design und die Implementierung von Unternehmensarchitekturen oder auf der Dokumentation der Unternehmensarchitektur. Die Vorgehensweise zur Unternehmenstransformation wird dabei oftmals als Regelkreis beschrieben. Ein prominentes Beispiel für so einen Regelkreis ist die TOGAF® Architecture Development Method (ADM, vgl. The Open Group 2018b, Part II, Kap. 4). Sie strukturiert die Schritte zur Gestaltung und Umsetzung von Unternehmensarchitekturen in insgesamt zehn Phasen. Neben TOGAF®s ADM gibt es aber eine Reihe weiterer EA-Frameworks, die methodische Unterstützung zur Gestaltung der Architekturveränderung beschreiben (siehe Abb. 3.1).

VORGEHENSMODELL DoDAF

FEAF

SABSA

TOGAF

ORDNUNGSRAHMEN NORA

ArchiMate

DoDAF

TOGAF

Zachman

… Abb. 3.1   Vorgehensmodelle und Ordnungsrahmen für EA

FEAF

…

3  Das Zusammenspiel zwischen TOGAF®, ArchiMate® und EA-Szenarien

35

Zur Dokumentation der Unternehmensarchitektur selbst bieten die Frameworks oftmals Vorschläge für Ordnungsrahmen und hilfreiche Visualisierungen zur Kommunikation von Architekturen und von Teilaspekten derselben. Diese Vorschläge reichen von eher abstrakten Datenmodellen bis hin zu konkreten Modellierungssprachen, die die Dokumentation wesentlicher Aspekte der Unternehmensarchitektur in einheitlicher und somit analysierbarer Form ermöglichen. Nahezu jedes Framework gliedert hierzu die Unternehmensarchitektur in ein Ebenenmodell (bzw. Domänenmodell); typischerweise von einer Strategieebene über die Geschäftsebene bis hin zu einer Technologie- oder Infrastrukturebene. Diese Ordnungsrahmen bilden die Grundstruktur für den in Kap. 1 motivierten digitalen Zwilling der Organisation – der modellhaften Abbildung der Organisation und deren Ecosystems. Die meisten der in Abb. 3.1 gezeigten Frameworks bieten sowohl den erwähnten Ordnungsrahmen für die Dokumentation der Architektur als auch eine erprobte Vorgehensweise für die Durchführung von Architekturveränderungen. • TOGAF® (The Open Group Architecture Framework, vgl. The Open Group 2018b) bietet mit der TOGAF® ADM wohl eines der bekanntesten und am weitesten verbreiteten Vorgehensmodelle. Das TOGAF® Content Meta-Model und eine Vielzahl an Architektursichten bieten Anleihen für die Dokumentation wesentlicher Aspekte der Unternehmensarchitektur, die im Rahmen der ADM verwendet werden. • FEAF (Federal Enterprise Architecture Framework, vgl. CIO Council 2013) ist ein Architekturframework mit Fokus auf die öffentliche Verwaltung. Neben einem einfachen Klassifikationsschema für EA-Elemente bietet es auch Referenzinhalte für Services der öffentlichen Verwaltung. Sein Vorgehensmodell zielt auf die Nutzung des Referenzmodells im Zuge der Gestaltung der Geschäftstransformation, um Redundanzen und Verbesserungspotenziale strukturiert ableiten zu können. Zur Modellierung der Architekturen empfiehlt das Framework jedoch keine durchgehende Modellierungssprache, sondern verweist auf universelle Standards, wie BPMN (Business Process Model and Notation, für die Prozessmodellierung) und UML (Unified Modelling Language, etwa für die Abbildung von Datenmodellen und Softwarekomponenten) (vgl. CIO Council 2013, S. 34). • DoDAF (Department of Defence Architecture Framework, vgl. US Department of Defense 2010) liefert ebenfalls beides: ein detailliertes Metamodell, welches die notwendigen Elemente zur Beschreibung der Unternehmensarchitektur in Form von stakeholder-spezifischen Sichten definiert sowie das Vorgehensmodell „6-Step Architecture Development Process“ zur Weiterentwicklung der Architekturen. • ArchiMate® (vgl. The Open Group 2019) bietet eine Modellierungssprache – dezidiert geschaffen für die Dokumentation von Unternehmensarchitekturen. Es beschreibt kein Vorgehensmodell, jedoch gibt es zahlreiche Anleitungen, wie ArchiMate® mit Vorgehensmodellen, wie der TOGAF® ADM, genutzt werden kann. • Dem Zachman Framework (vgl. Zachman 2006) kommt eine Vorreiterrolle als Klassifikationsschema für EA-Sichten zu. Viele der bekannten EA-Frameworks

36

A. Helmes und D. Hauer

nehmen Bezug auf das Zachman-Framework und nutzen dieses als Ausgangsbasis für ihre Framework-spezifischen Detaillierungen. Es bietet aber kein Vorgehensmodell. • NEA (National Enterprise Architecture, vgl. e-Government Program/Yesser 2017) ist das Architekturframework der saudi-arabischen Regierung und mit dem zugehörigen Vorgehensmodell NORA (National Overall Reference Architecture) fokussiert es auf einen Architekturveränderungsprozess bestehend aus zehn Schritten. International hat dieses Framework wenig Bedeutung. Es zeigt jedoch, das ­Unternehmensarchitektur-Management längst nicht mehr auf den amerikanischen und europäischen Raum begrenzt ist. • SABSA (Sherwood Applied Business Security Architecture, vgl. Sherwood et al. 2009) ist ein proprietäres Framework, welches auf den Teilaspekt „Sicherheitsarchitekturen“ fokussiert. Als Ordnungsrahmen setzt SABSA auf den von Zachman propagierten Ordnungsrahmen (siehe oben). Die Open Group diskutiert Mappings zur TOGAF® ADM (vgl. The Open Group 2011) und zu ArchiMate® (vgl. Band et al. 2015). Die oben genannten Frameworks sind nur ein kleiner Auszug einer Vielzahl mehr oder weniger etablierter EA-Frameworks. Matthes (2011) stellt in seinem Buch „Enterprise Architecture Frameworks Kompendium“ über fünfzig EA-Frameworks vor. Schwerpunkte seiner Ausführungen sind das jeweilige Framework-Metamodell und die zugehörigen Vorgehensmodelle zur Architekturgestaltung sowie Ausführungen zur Historie und zur Marktrelevanz der jeweiligen Frameworks. Einige der genannten Frameworks haben mittlerweile an Bedeutung verloren. Beispielsweise wird das bekannte Architekturframework TEAF (Treasury Enterprise Architecture Framework) nicht mehr weiterentwickelt, sondern ging im Jahre 2012 in FEAF auf. Abb. 3.1 verdeutlicht darüber hinaus noch einmal den Zusammenhang zu den Phasen der Unternehmenstransformation sowie den Gestaltungselementen einer Organisation, die Gegenstand der Transformation sind (vgl. Kap. 2). Während die Vorgehensmodelle aus den EA -Frameworks das Vorgehen der Unternehmenstransformation konkretisieren bzw. in Bezug auf das EAM verfeinern, detaillieren die EA-Ordnungsrahmen die Gestaltungselemente einer Organisation. Um einen Beitrag dazu zu leisten, ein erfolgreiches U ­nternehmensarchitekturManagement in Organisationen aufzusetzen, werden im vorliegenden Buch ­EA-Szenarien (portfolio-orientierter Ansatz) beschrieben und der Zusammenhang zur TOGAF® ADM (projekt-orientierter Ansatz) hergestellt. Für die Beschreibung der E ­ A-Szenarien wird ArchiMate® verwendet. Die Gründe für die Verwendung von TOGAF®s ADM und ArchiMate® werden in den nachstehenden Abschnitten erläutert. Alle im Buch beschriebenen Szenarien und Methoden können aber grundsätzlich auch in Kombination mit anderen EA-Frameworks und deren Vorgehensmodellen eingesetzt werden.

3  Das Zusammenspiel zwischen TOGAF®, ArchiMate® und EA-Szenarien

37

3.2 Der Zusammenhang zwischen der TOGAF® ADM und ArchiMate® TOGAF®s Methode zur Architekturentwicklung – die Architecture Development Method (ADM) – ist das bekannteste und am weitesten verbreitete Vorgehensmodell zur Architekturentwicklung. Dies spiegelt auch die Erfahrung der Autoren dieses Buchs aus den vergangenen 15 Jahren wider, in denen in zahllosen EA-Initiativen TOGAF® zum Einsatz kam. Aus diesem Grund wird die TOGAF® ADM zur Einordnung der ­EA-Szenarien verwendet. Abb.  3.2 zeigt TOGAF®s ADM im Überblick in seiner weltweit bekannten zyklischen Darstellung. Die einzelnen Phasen der TOGAF® ADM sind in die drei typischen Phasen zur Unternehmenstransformation (siehe Kap. 2) eingeordnet. Zur Dokumentation der Unternehmensarchitektur und gleichzeitig als Basis zur Katalogisierung und Beschreibung der Portfolioartefakte der einzelnen EA-Szenarien wird im vorliegenden Buch ArchiMate® (vgl. The Open Group 2019) verwendet. Einer der Hauptgründe hierfür ist, dass ArchiMate® seit ein paar Jahren immer mehr an Bedeutung gewinnt. Speziell mit der Version ArchiMate® 3.0 ist es möglich, Unternehmensarchitekturen vollumfänglich zu beschreiben. Der Vorteil von ArchiMate® liegt auf der Hand: Stakeholder, die mit dem Standard vertraut sind, sind in der Lage, auf ArchiMate® basierende Architektursichten zu lesen und zu verstehen. Zahlreiche Bücher, Publikationen und frei verfügbare Tutorials

V

Monitoren & Verbessern

A H

G

Umsetzen

B

AM

F

C

Planen

D E

V Vorbereitung | A Architekturvision | B Geschäftsarchitektur C Informationssystem-Architekturen | D Technologiearchitektur E Chancen & Lösungen | F Migrationsplanung | G Steuerung der Implementierung H Management der Architekturveränderung | AM Anforderungsmanagement

Abb. 3.2   TOGAF®s Architecture Development Method (vgl. The Open Group 2018b, Part II, Kap. 4)

38

A. Helmes und D. Hauer

erleichtern das Erlernen des Standards. Ein weiterer Vorteil von ArchiMate® ist darin zu sehen, dass ArchiMate® eine komplette Modellierungssprache mitbringt. Es werden nicht nur Typen an EA-Elementen beschrieben. ArchiMate® geht tiefer: Für jedes der Elemente bietet es eine Standard-Notation und Empfehlungen zur Nutzung und Verlinkung derselben. ArchiMate® bietet mit seinem Konfigurationskonzept an, ­stakeholder-spezifische Perspektiven (engl. Viewpoints) auf die Architektur zu definieren. In jedem der EA-Szenarien des vorliegenden Buchs wird ein derartiger Viewpoint vorgeschlagen. Abb. 3.3 zeigt das ArchiMate®-Framework, welches den von ArchiMate® vorgeschlagenen Ordnungsrahmen definiert. Genauso wie in der natürlichen Sprache ein Vokabular zur Bildung von aussagekräftigen Sätzen zur Verfügung steht, bietet ArchiMate® ein Set an Sprachkonstrukten an. Diese setzen sich aus so genannten Modellierungsklassen (Typen an Architekturelementen) und Beziehungen zusammen und erlauben es, das Unternehmen in ausreichend tiefer Granularität zu beschreiben. Abb. 3.4 zeigt einen repräsentativen Ausschnitt der ArchiMate®-Elemente und deren Beziehungen. Insgesamt definiert ArchiMate® (in der Version 3.0) ca. 50 derartiger Modellierungsklassen, welche über elf unterschiedliche Beziehungsklassen in Beziehung gesetzt werden können. Das Vokabular ist ausreichend groß, um Unternehmensarchitekturen in den verschiedensten Branchen zu beschreiben. Je EA-Szenario wird eine Teilmenge der definierten Beschreibungselemente genutzt. Zum Beispiel werden im EA-Szenario Applikationsportfolio-Management u.  a. die Elemente Applikationskomponente, Applikationsschnittstelle und Applikationsservice genutzt.

Passive Elemente

Verhalten

Aktive Elemente

Motivation

Strategie

Geschäft Applikation

Technologie Physikalische Infrastruktur Implementierung & Migration

Abb. 3.3   ArchiMate® Framework – Ein Ordnungsrahmen für die Dokumentation der Unternehmensarchitektur  (vgl. The Open Group 2019, Abschn. 3.4)

3  Das Zusammenspiel zwischen TOGAF®, ArchiMate® und EA-Szenarien

39

Abb. 3.4   Eine Auswahl wichtiger Elemente und Beziehungen in ArchiMate®

Für die Nutzung der TOGAF® ADM und von ArchiMate® spricht auch, dass diese unter der gemeinsamen Trägerorganisation „The Open Group“ weiterentwickelt und synchronisiert werden. TOGAF® liefert neben der ADM auch ein eigenes Content Metamodel. Allerdings wird in Foren und Blogs gemutmaßt, dass ArchiMate® die zukünftige Empfehlung für die Dokumentation der Architekturen sein wird. Ein Mapping zwischen dem TOGAF® Content Metamodel und der Modellierungssprache ArchiMate® (vgl. Jonkers et al. 2017) zeigt, dass die beiden Metamodelle ohnehin kaum Unterschiede aufweisen. ArchiMate® bietet allerdings neben dem Metamodell auch eine grafische Notation, Beispiele für Viewpoints, Empfehlungen zur Nutzung der Beziehungen etc.

40

A. Helmes und D. Hauer

Abb. 3.5 zeigt, wie sich TOGAF®s ADM und ArchiMate® ergänzen und zwar in der Form, dass die in den einzelnen ArchiMate®-Layern enthaltenen Elemente zur Beschreibung der Architekturen in den zugeordneten Phasen der TOGAF® ADM verwendet werden.

TOGAF

ArchiMate

Abb. 3.5   TOGAF®s ADM und ArchiMate® ergänzen sich  (vgl. Jonkers et al. 2017)

3  Das Zusammenspiel zwischen TOGAF®, ArchiMate® und EA-Szenarien

41

Grundsätzlich ist in Bezug auf Frameworks Folgendes im Hinterkopf zu behalten: Eine zu enge und unkritische Ausrichtung an Frameworks, wie TOGAF® und seiner ADM, wird den individuellen Anforderungen eines Unternehmens nicht gerecht. Sie dürfen nicht als ultimatives Rezeptbuch missverstanden werden. Vielmehr handelt es sich um Methodenvorschläge. Diese müssen intelligent auf die Erfordernisse des eigenen Unternehmens zugeschnitten werden.

3.3 Vorstellung der TOGAF® ADM 3.3.1 TOGAF®s ADM – Ein iterativer Ansatz TOGAF® ist ein ganzheitliches EA-Management-Framework, welches seit Mitte der 1990er-Jahre vom Industriekonsortium „The Open Group“ entwickelt und weiterentwickelt wird (vgl. The Open Group 2018b, Part I, Kap. 1). In der aktuellen Fassung werden auf mehr als 700 Seiten wertvolle Tipps zur Implementierung von Unternehmensarchitektur-Management gegeben. Die erfolgreiche Abwicklung von ­ Transformationsvorhaben steht dabei im Mittelpunkt (projekt-orientierter Ansatz). Für viele Leser wirkt dieses umfangreiche Framework allerdings eher abschreckend. Unternehmensarchitektur-Management erscheint aufwendig und der Nutzen schwer kommunizierbar. Dabei muss nicht jeder unternehmensinterne Benutzer ­TOGAF®-Experte sein, um erfolgreich an der Gestaltung und Umsetzung der Unternehmensarchitektur mitzuwirken. Die ADM gilt allgemein als Herzstück von TOGAF® (vgl. The Open Group 2018b, Part II, Kap. 4). Sie beschreibt eine Vorgehensweise zur Implementierung erfolgreicher Transformationsvorhaben. Unter Transformationsvorhaben wird in diesem Zusammenhang ein kompletter Durchlauf durch die Phasen der ADM verstanden. Die im Zuge der ADM definierte Zielarchitektur wird dabei über ein oder mehrere Projekte realisiert. INFO

Die Autoren vermeiden bewusst den Begriff Architekturprojekt: einerseits um zu betonen, dass die Arbeit mit der Definition der Zielarchitektur nicht abgeschlossen ist, und andererseits, um von den Projekten, die in der Phase F Migrationsplanung definiert werden, abzugrenzen. Ein Transformationsvorhaben gilt als abgeschlossen, wenn die zur Umsetzung erforderlichen Projekte abgeschlossen sind und die Zielarchitektur realisiert wurde.

Jedes Transformationsvorhaben durchläuft die einzelnen Phasen der ADM. Bei Bedarf können einzelne Phasen übersprungen werden. Dies ist nach Erfahrung der Autoren aber eher selten der Fall.

42

A. Helmes und D. Hauer

Unternehmen, die sich an TOGAF® orientieren, messen der ADM besondere Bedeutung zu. Die ADM wird als der eigentliche Mehrwert von TOGAF® wahrgenommen. Die Adaptierung der ADM für das eigene Unternehmen gestaltet sich aber nicht immer einfach. Oftmals wird die ADM als starre, wasserfallartige Vorgehensweise interpretiert. Agile Methoden zur Gestaltung der Unternehmensarchitektur werden selten gemeinsam mit der ADM implementiert. Dies geschieht, obwohl die ADM ausreichend Spielraum dazu lässt. Mehr dazu aber später. Zunächst wird auf die einzelnen Phasen der ADM und deren Schnittstellen zu den EA-Szenarien fokussiert. Die ADM ist vergleichbar mit anderen iterativen Vorgehensmodellen und zwar nicht nur mit jenen der oben genannten EA-Frameworks, sondern auch mit Vorgehensmodellen, wie: • dem PDCA-Kreislauf (Plan-Do-Check-Act, vgl. Deming 2000), dem aus SixSigma bekannten DMAIC-Zyklus • ­(Define-Measure-Analyse-Improve-Control, vgl. Breyfogle III 2003), • dem COBIT-Kreislauf für Unternehmens-Governance (vgl. ISACA 2019) oder • dem PMLC (Process Management Life Cycle), einem Kreislauf für Prozessmanagement (vgl. Bayer und Kühn 2013). Bei all diesen Vorgehensmodellen geht es immer um die kontinuierliche Verbesserung eines Ausschnitts des Unternehmens. Sie decken sowohl fundamentale Änderungen als auch kleinere Verbesserungen ab. Auf den ersten Blick erscheint die ADM jedoch komplexer. Lässt man die Details weg, wirkt die beschriebene Vorgehensweise allerdings selbsterklärend. Ausgehend von der Unternehmensstrategie werden Transformationsvorhaben definiert. Jedes Transformationsvorhaben durchläuft die ADM. Zu Beginn wird ein abstraktes Zielbild eines Bereichs der Organisation – die Zielarchitektur – entwickelt. Diese wird mit einem messbaren Business Case hinterlegt und in weiterer Folge verfeinert. Es folgt die detaillierte Business-Analyse, um die Geschäftsanforderungen zu verstehen. Die Umsetzung dieser Geschäftsanforderungen hilft dem Unternehmen, seine Unternehmensziele zu erreichen. Diese Umsetzung hat in der Regel Anpassungen auf allen Architekturebenen zur Folge. In der Geschäftsarchitektur werden Geschäftsprozesse, Geschäftsservices, Produkte etc. gestaltet. Auf Ebene der Informationssystem-Architekturen geht es um die Konzeption und Planung der beteiligten Applikationen. Des Weiteren werden Überlegungen zu den benötigten Daten sowie deren Nutzung und Bereitstellung angestellt. Bei Bedarf wird auch die Technologiearchitektur um neue Technologien erweitert. Das Delta zwischen Ist- und Zielsituation, man spricht in diesem Zusammenhang von Ist- und Zielarchitekturen, sind die zu bewerkstelligenden Anforderungen. Die Realisierung derselben wird in Form einer Roadmap geplant. Die Roadmap wird in den weiteren Phasen der ADM detailliert. Projekte werden identifiziert und Projektpläne erstellt. Geht es dann in die Umsetzung dieser Projekte, so sollten diese vom Architekturteam begleitet und überwacht werden. Das Architekturteam zeichnet dabei aber in

3  Das Zusammenspiel zwischen TOGAF®, ArchiMate® und EA-Szenarien

43

der Regel nicht für die Umsetzung verantwortlich. Anschließend erfolgt üblicherweise die Implementierung der definierten Projekte bzw. Architekturen. Die herbeigeführten Änderungen werden dann schlussendlich auf allen Architekturebenen institutionalisiert. Am Ende eines Zyklus und nach der erfolgreichen Implementierung wird geprüft, ob die geplanten Verbesserungen erreicht wurden. Wie bereits mehrfach motiviert, müssen die Verbesserungen auch aus dem Blickwinkel der Benutzer evaluiert werden. Im Bedarfsfall wird ein neuerlicher Zyklusdurchlauf initiiert. Kommt es zu ­(un-)vorhersehbaren Änderungen, können in jeder Phase neue Anforderungen entstehen, die es laufend zu bewerten gilt. Jederzeit können Rücksprünge zu vorhergehenden Phasen gemacht werden, welche Anpassungen in den nachfolgenden Phasen nach sich ziehen. Viele der Phasen können auch parallel zueinander bearbeitet werden. Abb. 3.6 zeigt auf schematische Weise ein Transformationsvorhaben. Es zeigt die Ist-Architektur und die zu realisierende Zielarchitektur. Letztere wird über mehrere ­ Projekte realisiert. Transformationszyklen finden vielfach parallel statt. Die jeweiligen Transformationsvorhaben beziehen sich dabei immer auf einen Wirkungsbereich (Scope) des Unternehmens (vgl. The Open Group 2018b, Part II, Kap. 6). Die Wirkungsbereiche von Transformationsvorhaben können überlappend definiert sein, sodass Transformationsvorhaben aufeinander abgestimmt werden müssen. Abb. 3.7 zeigt diesen Sachverhalt anhand von zwei Transformationsvorhaben. Oft muss, wie in Kap. 2 diskutiert, der Bogen auch weit über die Unternehmensgrenzen hinaus gespannt werden. Die Wertschöpfung entsteht häufig in Netzwerken und

ZIELArchitektur

Unternehmenserfolg Wirkungsbereich des Transformationsvorhabens

ISTArchitektur

Projekt

Projekt Projekt

Abb. 3.6   Zielarchitekturen werden durch Projekte realisiert

Projekte des Transformationsvorhabens

Zeit

44

A. Helmes und D. Hauer ZIELArchitektur

Unternehmenserfolg ISTArchitektur

Wirkungsbereich Transformationsvorhaben A

Wirkungsbereich Transformationsvorhaben B

Zeit

Abb. 3.7   Regelfall: Zeitgleiche Abwicklung mehrerer Transformationsvorhaben

Unternehmen sind Teil dieser Netzwerke. Erfolgreiche Unternehmen betrachten somit das gesamte Unternehmensumfeld, das so genannte Ecosystem: Kunden, Partner und Lieferanten des Unternehmens werden ebenfalls in das Architekturdesign einbezogen. Produkte, Geschäftsprozesse, aber auch die zugrunde liegende IT müssen offen gestaltet werden, sodass Chancen durch neue Partnerschaften genutzt werden können.

3.3.2 Zwischen den Zeilen lesen – Der Bezug zu Portfolios in TOGAF® In jeder Phase der ADM treten typische Fragestellungen auf, die aus dem Kontext eines Transformationsvorhabens nur schwer zu beantworten sind. Liest man zwischen den Zeilen, findet man in TOGAF® zahlreiche Hinweise auf die Notwendigkeit von Portfolios. Konkret erwähnt wird zwar lediglich das Applikationsportfolio (vgl. The Open Group 2018b, Part IV, Kap. 31). Allerdings können auch das TOGAF® Technical Reference Model (TRM) und die TOGAF® Standards Information Base (SIB) als Portfolios interpretiert werden. Das TRM ist eine Taxonomie zur Strukturierung technischer Services (vgl. The Open Group 2017) und das SIB ist ein Katalog an Industriestandards, welche bei der Definition der Architekturen hilfreich sein können (vgl. The Open Group 2018a). Das EA-Szenario „Technologieportfolio-Management“ (vgl. Kap. 8) deckt die Aufgaben des TRM und des SIB ab. Es beschäftigt sich mit der Kategorisierung und Bewertung der für das Unternehmen relevanten Technologien. Des Weiteren nennt TOGAF® Kataloge, wie beispielsweise den Anforderungskatalog, den Geschäftsservicekatalog oder den Produktkatalog. Diese werden nicht näher

3  Das Zusammenspiel zwischen TOGAF®, ArchiMate® und EA-Szenarien

45

beschrieben, deuten aber auf die Notwendigkeit der zentralen Steuerung der darin verwalteten Architekturelemente hin (vgl. The Open Group 2018b, Part IV, Kap. 31). Bevor nun in den folgenden Kapiteln die Phasen der ADM etwas detaillierter diskutiert werden, werden typische und wiederkehrende Fragen und Informationsbedarfe, die im Zuge der Abarbeitung der Phasen der ADM auftreten, aufgezeigt. Das portfolio-orientierte Unternehmensarchitektur-Management – respektive die EA-Szenarien – muss Antworten auf diese Fragen liefern, damit die einzelnen Phasen eines Transformationsvorhabens effizient abgearbeitet werden können. Die Antworten werden in Form von Architekturergebnissen (Artefakten) bereitgestellt. Dabei handelt es sich zumeist um Listen, Matrizen oder um Diagramme (vgl. The Open Group 2018b, Part IV, Kap. 31), die Ausschnitte der Unternehmensarchitektur beschreiben. Abb. 3.8 zeigt typische Fragestellungen, die entlang der ADM-Phasen immer wieder auftreten.

3.3.3 Die Phasen der ADM und deren Zusammenspiel mit den EA-Szenarien Die nachfolgenden Abschnitte beschreiben kurz und prägnant die Essenz der ­ADM-Phasen. Nicht alles wird beschrieben. Die Details findet man für jedermann frei zugänglich in der TOGAF®-Standard-Publikation (vgl. The Open Group 2018b). Vorbereitungsphase In der Vorbereitungsphase (Preliminary Phase) der ADM (vgl. The Open Group 2018b, Part II, Kap. 5) werden die Rahmenbedingungen für die nachfolgenden Phasen gesetzt. In TOGAF® etwas verwirrend dargestellt, werden manche dieser Festlegungen nicht nur für das aktuelle Transformationsvorhaben, sondern für die ­Unternehmensarchitektur-Initiative insgesamt festgelegt. Die Autoren des vorliegenden Buchs empfehlen Folgendes: Zu Beginn jedes Transformationsvorhabens werden die bereits in anderen ADM-Durchläufen getroffenen Festlegungen zur EA-Initiative rekapituliert und im Bedarfsfall angepasst. Die Phase zielt darauf ab, das Architektur-Team und alle am Transformationsvorhaben beteiligten Stakeholder auf die anstehenden Aufgaben und Herausforderungen vorzubereiten. Die Konstituierung des EA-Kernteams sowie die Zuweisung von Verantwortlichkeiten sind dabei wesentliche Schritte. Außerdem gilt es, die Unterstützung wichtiger Stakeholder für die Architekturinitiative insgesamt einzuholen. Die Anforderungen und Prioritäten der Stakeholder sind dabei zu identifizieren. Neben diesen organisatorischen Festlegungen werden die zu nutzenden Frameworks und Methoden erarbeitet. Das klingt zuerst aufwendig und kompliziert. Geht man allerdings pragmatisch vor, müssen lediglich die in Transformationsvorhaben immer wieder auftretenden Fragestellungen identifiziert werden. Aus methodischer Sicht muss dann lediglich festgelegt werden, wie diese beantwortet werden können. Zu diesem Zweck muss geklärt werden,

46

Abb. 3.8   Typische Fragestellungen entlang des ADM-Zyklus

A. Helmes und D. Hauer

3  Das Zusammenspiel zwischen TOGAF®, ArchiMate® und EA-Szenarien

47

• welche Informationen zusammengetragen werden müssen, • wer die Informationen bereitstellt, qualitätssichert und aktuell hält und vor allem • welche Reports zur Entscheidungsfindung auf Basis dieser Informationen erstellt werden müssen. Einige der relevanten Fragen wurden bereits im vorhergehenden Abschnitt in Abb. 3.8 vorgestellt. EA-Modellierungssprachen bilden einen Ordnungsrahmen zur Erfassung und Analyse der erforderlichen Architekturinformationen. Mittels EA-Modellierungssprachen werden EA-relevante Informationen in Form von Ist- und Zielarchitekturen konsistent aufbereitet. Sie stellen den Ordnungsrahmen für die zu erstellenden Portfolios dar. ist eine der populärsten Modellierungssprachen für ArchiMate® Unternehmensarchitektur-Management. Getreu dem Motto „Discuss architecture and ­ not the language“ (vgl. Band 2017) wird im vorliegenden Buch ArchiMate® verwendet. Genauso wie TOGAF® hat auch ArchiMate® gewisse Defizite. Die Vorteile einer weltweit einheitlichen und verständlichen Sprache überwiegen aber nach dem Empfinden der Autoren in vielen Fällen die möglichen Defizite. Es bleibt aber die Aufgabe, ArchiMate® für die individuellen Bedürfnisse des Unternehmens auszugestalten. In den im vorliegenden Buch beschriebenen EA-Szenarien wird auf wichtige Elemente aus ArchiMate® explizit verwiesen. Eine weitere zentrale Aufgabe der Vorbereitungsphase ist laut TOGAF® die Definition so genannter Architekturprinzipien. Architekturprinzipien dienen dazu, allen Beteiligten Richtlinien zu geben. Gute Architekturprinzipien adressieren wiederkehrende Architekturfragestellungen und werden zur Beurteilung von Transformationsvorhaben und Architekturdesigns herangezogen. Anknüpfungspunkte gibt es auf allen Ebenen der Unternehmensarchitektur. Auf Ebene der Applikationslandschaft beugt beispielsweise das Prinzip „Wiederverwendung“ der Mehrfachimplementierung redundanter Applikationsservices vor und trägt somit entscheidend zur Vermeidung nicht notwendiger Betriebsaufwände bei. Durch das Prinzip „Vermeidung von Datenredundanz“ wird die Datenqualität hochgehalten. Auf Ebene der Technologiearchitektur gilt es, Prinzipien zur Standardisierung der eingesetzten Systemsoftware zu definieren. Kap. 9  liefert diesbezüglich einen tieferen Einblick. Phase A: Architekturvision Einen deutlichen Wertbeitrag eines Transformationsvorhabens zu den Unternehmenszielen sicherzustellen, ist das Ziel der Phase A: Architekturvision (vgl. The Open Group 2018b, Part II, Kap. 6). Um die notwendige Unterstützung der Führungskräfte und der Linienorganisation für ein Transformationsvorhaben zu erhalten, muss dieser Wertbeitrag klar und unmissverständlich kommuniziert werden. Der Mehrwert für die Benutzer muss erarbeitet werden. Insbesondere muss dargelegt werden, wie dieser erreicht und gemessen werden kann. Im ersten Schritt wird der Wirkungsbereich des Transformationsvorhabens festgelegt. Die Architekturvision erhält eine erste, abstrakte Beschreibung der Ist- und der

48

A. Helmes und D. Hauer

Zielarchitektur des gewählten Wirkungsbereichs. Der Wirkungsbereich bezieht sich dabei üblicherweise auf Elemente, wie Produkte, Geschäftsservices, Geschäftsprozesse, Applikationskomponenten und Technologien – eine Art „Durchstich“ durch alle Architekturebenen. In dieser Phase werden auch die relevanten Stakeholder identifiziert und deren Anliegen aufgenommen. Es werden Kennzahlen definiert, welche zur späteren Messung der Zielerreichung herangezogen werden können. Hilfreich in diesem Zusammenhang ist die Unternehmensstrategie, welche im Idealfall in Form von Unternehmenszielen operationalisiert wurde. In diesem Fall kann der erwartete Wertbeitrag eines Transformationsvorhabens besser kommuniziert werden. Das Gleiche gilt für eine unternehmensweite Capability-Map (vgl. Kap. 5). Ist diese vorhanden, lassen sich neue Transformationsvorhaben von Beginn an einordnen und Schwerpunkte werden dadurch gut erkennbar. Das EA-Szenario Transformationsportfolio-Management (vgl. Kap. 4) unterstützt bei der Auswahl der Transformationsvorhaben. Es konsolidiert und bewertet Ideen, die in einem Ideenportfolio vorgehalten werden. Die vielversprechendsten Ideen münden in Transformationsvorhaben. Diese werden bewertet und priorisiert. Als Grundlage für die Bewertung wird eine initiale Roadmap pro Transformationsvorhaben erstellt. Diese ist im Idealfall in Ausbaustufen gegliedert, wobei jede der Ausbaustufen bereits Mehrwert für das Unternehmen und die Kunden liefert. Ist eine Ausbaustufe erfolgreich abgeschlossen, kann entschieden werden, ob eine weitere Ausbaustufe adressiert wird oder ob der Fokus und die Ressourcen auf andere Transformationsvorhaben mit höherem strategischen Wertbeitrag gelenkt werden sollen. Phase B: Geschäftsarchitektur Zu Beginn der Phase B (vgl. The Open Group 2018b, Part II, Kap. 7) wird der ­Ist-Zustand der Geschäftsarchitektur beschrieben. Für den definierten Wirkungsbereich werden Dokumentationen in Form von Architektursichten erstellt. Typische Sichten sind Wertschöpfungsketten, Prozesslandkarten, Produktbeschreibungen, Customer Journeys und weitere Artefakte, die zur Beschreibung der Ist-Situation hilfreich sein können. Aufbauend auf der Ist-Architektur wird entsprechend der Architekturvision die Zielarchitektur für die Geschäftsebene definiert. Genauso wie die Ist-Architektur wird auch die Zielarchitektur in Form von Sichten dokumentiert. Die Zielarchitektur orientiert sich an den Architekturprinzipien und deckt die bestehenden Anforderungen weitestmöglich ab. Eine anschließende Gap-Analyse dient der Identifikation der Deltas zwischen Istund Zielarchitektur. Zur Schließung dieser Deltas werden Anforderungen identifiziert, die zu einem späteren Zeitpunkt als Grundlage für die Phase E: Chancen und Lösungen wieder aufgegriffen werden. Allfällig identifizierte Konflikte zwischen identifizierten Anforderungen, Zielen oder Prinzipien müssen aufgelöst werden. Das EA-Szenario „Capability-Portfolio-Management“ (vgl. Kap.  5) ermöglicht eine erste Bewertung der Geschäftsarchitektur. Die im Wirkungsbereich des

3  Das Zusammenspiel zwischen TOGAF®, ArchiMate® und EA-Szenarien

49

­ ransformationsvorhabens liegenden Fähigkeiten, d. h. die Kompetenzen des UnterT nehmens, werden identifiziert und in Hinblick auf die Zielsetzung des Transformationsvorhabens bewertet. Phase C: Informationssystem-Architekturen In der Phase C (vgl. The Open Group 2018b Part II, Kap. 8–10) werden Applikationsund Datenarchitekturen entworfen, die die Geschäftsarchitektur im Wirkungsbereich bestmöglich unterstützen. In puncto Datenarchitektur werden die wichtigsten Daten identifiziert, die für die Realisierung der Zielarchitektur erforderlich sind. In diesem Zusammenhang spricht man von Geschäftsobjekten. Diese stellen eine hohe Abstraktion der relevanten Daten dar. Auf dieser Basis werden Überlegungen zu den benötigten Daten sowie deren Bereitstellung und Verarbeitung angestellt. Bei Bedarf werden die Geschäftsobjekte verfeinert. Für die Applikationsarchitektur gilt es ebenfalls, eine Ziellandschaft zu entwickeln. Es wird geklärt, welche Applikationsservices zur Unterstützung der Geschäftsarchitektur existieren müssen. Diese werden von Applikationskomponenten bereitgestellt. Geschäftsobjekte werden mit Applikationskomponenten, respektive mit den identifizierten Applikationsservices, in Beziehung gesetzt. Das Vorgehen zur Identifikation und Schärfung des Zielbilds der Applikations- und Datenarchitektur ist analog zu jenem in Phase B: Geschäftsarchitektur. Ist- und Zielarchitektur für den Wirkungsbereich werden beschrieben und die Deltas werden identifiziert. In weiterer Folge werden die Deltas in Form zu realisierender Anforderungen adressiert. „Rein nach der Lehre“ wird in dieser Phase nicht über die Lösungsarchitekturen gesprochen. Der Fokus liegt auf einer funktionalen Beschreibung der erforderlichen Applikationsservices. In der Praxis wird allerdings oftmals bereits in dieser Phase über die Lösungsarchitekturen nachgedacht; respektive erfolgt dies zeitgleich in der Phase „Chancen und Lösungen“. Es wird jedenfalls das Applikationsportfolio bemüht, um mögliche Kandidaten an Applikationskomponenten, welche Teil der Zielarchitektur sein können, zu identifizieren. Dies ist oftmals schon alleine deswegen notwendig, um entsprechende Ansprechpartner, wie z. B. Applikationsverantwortliche, zu identifizieren. Zur Identifikation der erforderlichen Daten leistet das EA-Szenario ­„Datenportfolio-Management“ (vgl. Kap. 7) einen wertvollen Beitrag. Gleichermaßen bietet das Applikationsportfolio einen Einblick in die Applikationslandschaft und in die bereits geplanten Veränderungen (vgl. Kap. 6). Phase D: Technologiearchitektur Die Phase D (vgl. The Open Group 2018b Part II, Kap. 11) befasst sich mit Betriebsund Bereitstellungsfragen der in der Phase „Informationssystem-Architekturen“ identifizierten Applikationskomponenten. Hierbei geht es darum, zu klären, welche Technologien die Transformationsvorhaben bestmöglich unterstützen oder überhaupt erst möglich machen.

50

A. Helmes und D. Hauer

Die Technologiearchitektur definiert – wie auch die Geschäftsarchitektur und die Informationssystem-Architekturen – zuerst die Ist-Architektur. Dies erfolgt immer mit Fokus auf den definierten Wirkungsbereich. Es entsteht das Zielbild in Form der Zielarchitektur und es wird wiederum das Delta zwischen Ist- und Zielarchitektur ermittelt. Dieser Gap-Analyse folgt die Identifikation der zu realisierenden Technologieservices. Zum Teil werden bereits in dieser Phase konkrete Technologieprodukte oder Plattformen, aber auch Equipment – man denke an IoT-Komponenten (engl. Internet of Things) – vorgeschlagen. Das Vorgehen zur Identifikation und Schärfung des Zielbilds der Technologiearchitektur ist abermals analog zu jenem in Phase B: Geschäftsarchitektur. Ein Technologieportfolio ist von unschätzbarem Wert für Transformationsvorhaben. Es beinhaltet im einfachsten Fall eine Liste aller im Unternehmen eingesetzten Technologien. Zumeist handelt es sich dabei um einen Katalog an Systemsoftware-Elementen und Hardware-Elementen. Dieser enthält neben Lebenszyklusinformationen auch Informationen zu Verantwortlichkeiten, zum aktuellen Einsatzgebiet, Qualitätseinschätzungen usw. Das Technologieportfolio beinhaltet neben bereits erprobten Technologiestandards auch neue Technologien (engl. Emerging Technologies), die durch das Team der Technologiearchitekten bewertet wurden. Es dient vor allem dazu, Empfehlungen für Transformationsvorhaben und in weiterer Folge für zukünftige Projekte auszusprechen. Es trägt dazu bei, technologischen Wildwuchs und einhergehende hohe Wartungs-/Betriebskosten zu vermeiden. Das Technologieportfolio bietet somit Leitlinien für seine Benutzer, etwa für Lösungsarchitekten. Dabei müssen die Verantwortlichen einen guten Mix an erprobten Technologien definieren, ohne dabei innovativen Projekten allzu enge Vorgaben aufzubürden. Durch das Erkennen neuer und innovativer Technologien gibt das ­Technologieportfolio-Management auch Anstöße für neue Geschäftsideen (vgl. Kap. 8). Phase E: Chancen und Lösungen In der nun folgenden Phase „Chancen und Lösungen“ (vgl. The Open Group 2018b, Part II, Kap. 12) wird eine erste vollständige Version der Roadmap des Transformationsvorhabens erstellt. Bei umfangreichen Transformationsvorhaben wird die Roadmap in Transitionsarchitekturen unterteilt. Diese bilden Zwischenschritte auf dem Weg zur Zielarchitektur. Durch jede dieser Transitionsarchitekturen sollen ein oder mehrere Gaps geschlossen werden, indem die zugehörigen Anforderungen umgesetzt werden. Auf dieser Basis werden Projekte und zugehörige Arbeitspakete abgeleitet. Das Applikationsportfolio (vgl. Kap. 6), das Datenportfolio (vgl. Kap. 7) und das Technologieportfolio (vgl. Kap.  7) bieten Entscheidungsgrundlagen für die Ausgestaltung der Lösungsarchitektur (Solution Architecture). Getroffene Festlegungen fließen zurück in die Portfolios, sodass diese für weitere Transformationsvorhaben wieder bereitgestellt werden können. Im Idealfall werden die Transitionsarchitekturen bereits im ­TransformationsportfolioManagement (vgl. Kap. 4) im Sinne von Ausbaustufen definiert. Jede der erreichten

3  Das Zusammenspiel zwischen TOGAF®, ArchiMate® und EA-Szenarien

51

Transitionsarchitekturen sollte eigenständig Mehrwerte für das Unternehmen liefern können. Es handelt sich somit um eine Art Reifegrad, der jeweils mit der Umsetzung einer Transitionsarchitektur erreicht wird. Zumeist kommt es nach Abarbeitung der Phasen B-D zu neuen Erkenntnissen. Bei Bedarf fließen diese Erkenntnisse zurück in das Transformationsportfolio, sodass die Unternehmensführung auf Basis derselben Budgeterfordernisse, neue Einschätzungen und Priorisierungen der Transformationsvorhaben vornehmen kann. Phase F: Migrationsplanung Abhängig vom Wirkungsbereich des Transformationsvorhabens kann die Detaillierung der Planung in der Phase „Migrationsplanung“ (vgl. The Open Group 2018b, Part II, Kap. 13) variieren. Ziel ist es jedenfalls, einen klaren und kommunizierbaren Umsetzungsplan zu erstellen. Die detaillierte Migrationsplanung und die Planung der Umsetzungsprojekte finden zusammen mit den Verantwortlichen des Transformationsportfolio-Managements statt. In diesem Schritt werden die Abhängigkeiten zwischen den Projekten und Arbeitspaketen laufender und zukünftiger Transformationsvorhaben ermittelt und aufgelöst. Die Verfügbarkeit der mitwirkenden Geschäftsakteure im Sinne einer Ressourcenplanung wird ebenfalls abgeklärt und berücksichtigt. Dabei kann die Planung entsprechend eines vorherrschenden und gelebten Projektmanagement-Frameworks erfolgen, bspw. nach PRINCE2® (vgl. Office of Government Commerce (OGC) 2009) oder PMBOK® (vgl. Project Management Institute 2008). Phase G: Steuerung der Implementierung Die Phase G (vgl. The Open Group 2018b, Part II, Kap. 14) übernimmt die Kontrollfunktion über die Umsetzungsprojekte. Es wird die Umsetzung der erforderlichen Migrationsschritte initiiert und gesteuert. Dabei kommt der Überprüfung der planmäßigen Umsetzung der Ziel- oder Transitionsarchitekturen besondere Bedeutung zu. Zur Umsetzung werden die Ergebnisse aus Phase F und die darin enthaltenen Priorisierungen an die Umsetzungsverantwortlichen kommuniziert. Spezifische Ressourcenanforderungen werden erhoben und Projektaufträge werden ausgestellt. Während und nach der Umsetzung tragen Architektur-Compliance-Reviews dazu bei, die Einhaltung aller Vorgaben zu kontrollieren und einzufordern. Für den Betrieb und die Aufrechterhaltung neuer Lösungen werden Betriebskonzepte entworfen, die u. a. auch auf die dazu benötigten Fähigkeiten der Mitarbeiter Bezug nehmen. Das EA-Szenario „Compliance-Portfolio-Management“ (vgl. Kap. 9) beschreibt, wie aktuelle und neu geplante Architekturen in Hinblick auf Architekturprinzipien, Sicherheitsanforderungen und weiteren relevanten Anforderungen und Normen bewertet werden können. Benutzer, wie beispielsweise Applikationsarchitekten, Datenarchitekten oder Technologiearchitekten, erhalten somit klare Anweisungen, die sie beim Design geeigneter Architekturen unterstützen.

52

A. Helmes und D. Hauer

Phase H: Management der Architekturveränderung Die Phase H (vgl. The Open Group 2018b, Part II, Kap. 15) beschäftigt sich vorrangig mit der Herausforderung, dass die realisierte Architektur auch über längere Zeit ihren ursprünglich angestrebten Wert für das Unternehmen aufrechterhält. Zu diesem Zweck wird der im ADM-Zyklus adressierte Wirkungsbereich kontinuierlich analysiert. Sowohl externe Einflüsse, wie Marktentwicklungen, Technologietrends oder Änderungen an rechtlichen Vorgaben, als auch interne Einflüsse, wie z. B. identifizierte Optimierungspotenziale, können dazu führen, dass neue Anforderungen definiert werden. Ein neuer ADM-Zyklus wird angestoßen, wenn festgestellt wird, dass die identifizierten Veränderungen zu große Konsequenzen haben, als dass sie parallel zum Tagesgeschäft durchgeführt werden können. Insbesondere in Unternehmensbereichen, die einen hohen Grad an Innovation erfordern, werden die Zyklen nahezu kontinuierlich durchlaufen. Als Beispiele können vor allem Wirkungsbereiche genannt werden, die kundenzentrierte Fähigkeiten im Fokus haben. Customer Journeys unterliegen heutzutage einer stetigen Adaption. Beispielsweise werden diese in kurzen Innovations- und Implementierungszyklen um weitere Kanäle und Customer Touchpoints angereichert. Im EA-Szenario Transformationsportfolio-Management wird beschrieben, wie die Auswirkungen von Transformationsvorhaben gemessen werden können (vgl. Kap. 4). Die definierten Kennzahlen werden in der Phase H verwendet, um Abweichungen von Planwerten zu identifizieren und bei Bedarf neue Verbesserungszyklen anzustoßen. Des Weiteren hat die Phase „Management der Architekturveränderung“ einen starken Bezug zum EA-Szenario „Compliance-Portfolio-Management“ (vgl. Kap. 9). Implementierte Architekturen müssen permanent in Hinblick auf compliance-relevante Vorgaben bewertet werden. Die dahin gehend erforderliche Überwachung reicht über die Phase „Management der Architekturveränderung“ und den Abschluss eines Transformationsvorhabens hinaus und muss auch im darauffolgenden laufenden Betrieb erfolgen. Im Falle identifizierter Abweichungen kommt es zu Anforderungen, welche – wie im nachstehenden Abschnitt beschrieben – bewertet und koordiniert werden. Phase AM: Anforderungsmanagement Die kontinuierliche Durchführung von Anforderungsmanagement (vgl. The Open Group 2018b Part II, Kap. 16) erstreckt sich über alle Phasen der ADM. Anforderungen entstehen im Zuge der Abarbeitung der jeweiligen ADM-Phasen. Das Anforderungsmanagement übernimmt hier eine kontrollierende bzw. steuernde Rolle und stellt die Klärung etwaiger resultierender Konflikte sicher. Anforderungsmanagement beschreibt die Vorgehensweise, um Anforderungen verschiedenster Stakeholder zu erheben, zu dokumentieren und zu priorisieren. Aus Zeit- und Ressourcengründen können möglicherweise nicht alle Anforderungen und Ideen im Rahmen eines Zyklusdurchlaufs realisiert werden. Diese liefern aber Impulse für neue Transformationsvorhaben und werden im EA-Szenario ­„Transformationsportfolio-Management“ (vgl. Kap. 4) bewertet und priorisiert.

3  Das Zusammenspiel zwischen TOGAF®, ArchiMate® und EA-Szenarien

53

3.4 Struktur und Wertbeitrag der EA-Szenarien Wie beschrieben, liefern die EA-Szenarien einen wichtigen Input für Transformationsvorhaben, damit diese effizient abgearbeitet werden können. Sie decken in der Regel eine gesamte Architekturebene (z. B. im Falle des Applikationsportfolio-Managements die Applikationsarchitektur) des Unternehmens ab. Die Wirkungsbereiche der E ­ A-Szenarien beziehen sich somit auf einzelne Ebenen der Unternehmensarchitektur, und nicht wie die Transformationsvorhaben auf „Durchstiche“ über mehrere Ebenen hinweg. Es müssen natürlich nicht alle hier beschriebenen EA-Szenarien im Unternehmen eingeführt werden. In der Praxis entscheiden sich Unternehmen meist im ersten Schritt, nur eines oder wenige EA-Szenarien umzusetzen. Mitunter werden die hier beschriebenen EA-Szenarien in deren Umfang reduziert, um das Kosten-/Nutzenverhältnis genau auf die Aufgabenstellung im Unternehmen auszurichten. Über die Zeit können dann weitere EA-Szenarien hinzukommen oder die bereits etablierten EA-Szenarien ausgebaut werden. Die in den folgenden Kapiteln beschriebenen EA-Szenarien setzen sich aus Vorgehensweisen, Dokumentationsvorschlägen, Rollen sowie aus typischen Ergebnissen zusammen. Jedes EA-Szenario wird durch ein durchgängiges Beispiel untermauert. Die Beschreibungen der Szenarien weisen jeweils die gleiche Struktur auf, sodass sich der Leser rasch zurechtfindet. Folgende Fragestellungen werden je Szenario beantwortet: 1. Was ist die Zielsetzung des Szenarios? Welche Fragen können durch das Szenario beantwortet werden? Welcher Benutzertyp nutzt die Ergebnisse? 2. Welche Geschäftsakteure wirken bei der Erstellung der Ergebnisse mit und wofür sind diese jeweils verantwortlich? 3. Wie sieht das Vorgehensmodell je Szenario aus? Welche Schritte müssen durchgeführt und etabliert werden? 4. Welche Gestaltungsobjekte der Ist- und Zielarchitektur werden im betrachteten Szenario erstellt, analysiert und geplant? Über welchen Ausschnitt des ­ArchiMate®-Metamodells (Viewpoint) werden diese beschrieben? 5. Wie sehen die typischen Ergebnisse des Szenarios aus? Abb. 3.9 zeigt die wesentlichen Bausteine und die Zusammenhänge eines EA-Szenarios. Die Zielsetzung wird durch die zu beantwortenden Fragestellungen beschrieben. Jedes EA-Szenario muss Antworten zu Fragen liefern, welche in der Regel nicht effizient innerhalb der zugehörigen Phasen eines Transformationsvorhabens geklärt werden können bzw. deren Antworten außerhalb des Scopes des Transformationsvorhabens zu finden sind. Einige Beispiele dazu finden sich in Abb. 3.8 am Beginn des Kapitels. Jeder dieser Fragen muss mindestens ein relevanter Stakeholder zugeordnet sein, der Interesse an den Ergebnissen hat.

54

A. Helmes und D. Hauer

Ergebnisse Viewpoints Vorgehensweise Stakeholder & Geschäftsrollen

Ziele Abb. 3.9   Struktur der EA-Szenarien

Für die Erarbeitung der Fragestellungen beschreibt jedes der EA-Szenarien ein Vorgehensmodell. Es werden Empfehlungen abgegeben, welche Schritte durchzuführen sind. Jedem dieser Schritte wird auch eine verantwortliche Geschäftsrolle zugeordnet. Typischerweise werden in den Szenarien Gestaltungselemente (z. B. Applikationen oder Technologien) der Unternehmensarchitektur identifiziert und in Form eines Portfolios dokumentiert und verwaltet. Die Gestaltungselemente werden näher beschrieben und bei Bedarf untereinander verlinkt. Zusätzlich werden den Gestaltungselementen verantwortliche Geschäftsrollen zugeordnet. Diese sind als Experten dafür verantwortlich, diesen kleinen Ausschnitt der Unternehmensarchitektur zu pflegen, zu analysieren und zu bewerten. Ein Technologieverantwortlicher beschreibt in diesem Zusammenhang beispielsweise die von ihm verantworteten Technologien, prüft die Aktualität der im Einsatz befindlichen Version und macht Vorschläge für Updates und Versionswechsel der Technologie. Ähnliche Aufgaben haben Prozessverantwortliche, Produktverantwortliche oder Applikationsverantwortliche für die von ihnen verantworteten Architekturelemente. Die zentralen Ergebnisse eines EA-Szenarios sind Architektursichten (engl. Views). Diese dienen als Input für die verschiedenen Phasen der ADM. Diese Sichten müssen genau auf die Informationsbedarfe der Stakeholder zugeschnitten werden. Ergebnisse sind aber nicht ausschließlich Knoten-und-Kanten-Diagramme. Typische Beispiele weiterer Ergebnistypen sind beispielsweise: • Matrizen, die Abhängigkeiten zwischen Architekturelementen aufzeigen, • Bubble-Charts, die auf einen Blick die Bewertung von Architekturelementen aufzeigen oder • Gantt-Charts, die den Lebenszyklusstatus von Architekturelementen veranschaulichen.

3  Das Zusammenspiel zwischen TOGAF®, ArchiMate® und EA-Szenarien

55

Im vorliegenden Buch werden zur Illustration der Beispiele durchgängig Sichten bzw. daraus generierte Grafiken aus den BOC Management Office®-Werkzeugen ADONIS® und ADOIT® genutzt. INFO

Ein perfektes Beispiel für eine auf Stakeholder-Bedürfnisse zugeschnittene Sicht ist der Londoner U-Bahn-Plan, entwickelt von Harry Beck, einem arbeitslosen technischen Zeichner aus dem Jahr 1931. In ihrer heutigen Fassung (siehe Abb. 3.11) wurde dieser Plan unter die zehn britischen Design-Ikonen des 20. Jahrhunderts gewählt. In ihren Vorgängerversionen sind zahlreiche unnötige Informationen enthalten (siehe Abb. 3.10). Gleichzeitig war es aus Platzgründen notwendig, Stationen am äußeren Rand wegzulassen. Die heute weltweit bekannte Version erlaubt den Blick auf das Wesentliche: Wie komme ich am effizientesten

Abb. 3.10   Der Londoner U-Bahn-Plan vor dem revolutionären Re-Design. Bild KFGG01 Underground map published in 1908, Bildanbieter: GL Archive / Alamy Stock Foto, inspiriert durch 100 Diagrams that Changed the World (vgl. Christianson 2012)

56

A. Helmes und D. Hauer

Abb. 3.11   Der Londoner U-Bahn-Plan wie er auch heute noch existiert. Bild GC9E20 Transport – London Underground Map, Bildanbieter: PA Images/Alamy Stock Foto, inspiriert durch 100 Diagrams that Changed the World (vgl. Christianson 2012)

von A nach B? Geoinformationen und Inhalte, die nicht zur Beantwortung dieser Frage dienen, wurden eliminiert. Nach dem gleichen Prinzip sind die Ergebnistypen der beschriebenen ­EA-Szenarien konzipiert: Der Blick auf das Wesentliche wird ermöglicht.

3.5 Fazit Es gibt eine Reihe an EA-Frameworks, an welchen Unternehmen sich orientieren können, um die notwendige Geschäftstransformation zu gestalten und zu steuern. Im vorliegenden Buch werden aufgrund ihres hohen Verbreitungsgrads die TOGAF® ADM als Vorgehensmodell und ArchiMate® für die Dokumentation der Unternehmensarchitektur verwendet. Die im Buch beschriebenen EA-Szenarien können aber auch mit beliebigen anderen Frameworks kombiniert werden.

3  Das Zusammenspiel zwischen TOGAF®, ArchiMate® und EA-Szenarien

57

Grundsätzlich gilt, dass eine zu enge und unkritische Ausrichtung an „Standards“, wie TOGAF® und ArchiMate®, den individuellen Anforderungen eines Unternehmens nicht gerecht wird. Frameworks müssen als Methodenbaukasten verwendet werden und dürfen nicht als unveränderliches Rezeptbuch missverstanden werden. Die im Buch beschriebenen EA-Szenarien dienen zur Unterstützung von Transformationsvorhaben. Sie ermöglichen die Synchronisation derselben. Gleichzeitig ermöglichen sie die rasche und effiziente Abwicklung von Transformationsvorhaben, indem sie unternehmensweite Zusammenhänge für ihre Benutzer erkennbar machen. Bei der Geschäftstransformation geht es nicht nur um fundamentale Veränderungen. EA-Szenarien unterstützen auch den kontinuierlichen Wandel des Unternehmens, indem sie ermöglichen, die Ist-Architektur zu überwachen und notwendige Anpassungen, die im Tagesgeschäft bewerkstelligt werden können, zu erkennen und bei deren Umsetzung zu unterstützen. Abb. 3.12 fasst das Zusammenspiel zwischen Transformationsvorhaben und EA-Szenarien zusammen. Die Ausgestaltung der EA-Szenarien muss mit Augenmaß betrieben werden. Der Blick auf das Wesentliche, nämlich die Definition von Architekturen, deren Umsetzung messbare Wertbeiträge für das Unternehmen und dessen Kunden bringen, darf nicht aus dem Fokus geraten. In den nachfolgenden Kapiteln wird beschrieben, wie U ­ nternehmensarchitekturManagement pragmatisch aufgesetzt werden kann. Der Fokus liegt dabei auf der Nutzung der in den EA-Szenarien bereitgestellten Informationen für die effiziente Abarbeitung aktueller und zukünftiger Transformationsvorhaben. Transformationssicht

Portfoliosicht Compliance-Portfolio-Management Transformationsportfolio-Management

Capability-Portfolio-Management Datenportfolio-Management

Applikationsportfolio-Management Technologieportfolio-Management

Wirkungsbereich Abb. 3.12   Zusammenspiel zwischen Transformationsvorhaben und Portfolio-Initiativen

58

A. Helmes und D. Hauer

Literatur Band, Iver. 2017. The present and the future of the ArchiMate® language – Part 1. The Open Group blog. https://blog.opengroup.org/2017/06/07/present-and-future-of-archimate®-language-part1/. Zugegriffen: 29. Dez. 2018. Band, Iver, Wilco Engelsman, Christophe Feltus, Sonia González Paredes, und Jim Hietala, Henk Jonkers, Pascal de Koning, Sebastien Massart. 2019. How to Model Enterprise Risk Management and Security with the ArchiMate® Language, The Open Group. https://publications.opengroup. org/w172. Zugegriffen: 29. Juli 2020. Bayer, Franz, und Harald Kühn. 2013. Prozessmanagement für Experten. Impulse für aktuelle und wiederkehrende Themen. Berlin: Springer. Breyfogle III, Forrest W. 2003. Implementing six sigma: Smarter solutions using statistical methods. Hoboken: Wiley. Christianson, Scott. 2012. 100 diagrams that changed the world: From the earliest cave paintings to the innovation of the iPod. London: Penguin. CIO Council. 2013. Federal Enterprise Architecture Framework, Version 2. https:// obamawhitehouse.archives.gov/sites/default/files/omb/assets/egov_docs/fea_v2.pdf. Zugegriffen: 29. Juli 2020. Deming, W. Edwards. 2000. Out of the crisis. Cambridge: MIT Press. e-Government Program/Yesser. 2017. Guide for national overall reference architecture. https:// www.yesser.gov.sa/ar/Methodologies/Documents/NORA%20BOOKLET.pdf. Zugegriffen: 11. März 2017. ISACA. 2019. COBIT 2019 framework: Governance and management objectives. http://www.isaca. org/COBIT/Pages/COBIT-2019-Publications-Resources.aspx. Zugegriffen: 11. März 2019. Jonkers, Henk et al. 2017. How to use the TOGAF® 9.1 architecture content framework with the ArchiMate® 3.0.1 modeling language, The Open Group. https://publications.opengroup.org/ w172. Zugegriffen: 29. Juli 2020. Matthes, Dirk. 2011. Enterprise Architecture Frameworks Kompendium. Berlin: Springer. Office of Government Commerce (OGC). 2009. Erfolgreiche Projekte managen mit PRINCE2. Norwich: The Stationery Office Books. Project Management Institute. 2008. A guide to the project management body of knowledge (PMBOK® Guide). 4. Aufl. Newtown Square. Sherwood, John, Andrew Clark, und David Lynas. 2009. SABSA white paper. https://sabsa.org/ white-paper-requests/. Zugegriffen: 31. Juli 2020. The Open Group. 2011. TOGAF® and SABSA integration. https://publications.opengroup.org/ w117. Zugegriffen: 11. März 2019. The Open Group. 2017. TOGAF® Series Guide: The TOGAF® Technical Reference Model (TRM). https://publications.opengroup.org/white-papers. Zugegriffen: 31. Juli 2020. The Open Group. 2018a. Standards Information Base. https://www2.opengroup.org/ogsys/jsp/ publications/sibMainPage.jsp. Zugegriffen: 31. Juli 2020. The Open Group. 2018b. The Open Group Architecture Framework TOGAF® Version 9.2. https:// pubs.opengroup.org/architecture/togaf9-doc/arch/. Zugegriffen: 27. Juli 2020. The Open Group. 2019. ArchiMate® 3.1 Specification. US Department of Defense. 2010. The DoDAF architecture framework, Version 2.02. https:// dodcio.defense.gov/Library/DoD-Architecture-Framework/. Zugegriffen: 11. März 2019. Zachman, John. 2006. The zachman framework for enterprise architecture. Zachman Framework Associates Virginia.

4

Transformationsportfolio-Management Christoph Moser und Felix Brandmayr

Inhaltsverzeichnis 4.1 4.2 4.3 4.4

Transformationsportfolio-Management und die ADM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Wesentliche Konzepte und Begrifflichkeiten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Stakeholder und Geschäftsrollen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Vorgehensweise im ­­Transformationsportfolio-Management. . . . . . . . . . . . . . . . . . . . . . . . 9 4.4.1 Die Vorgehensweise im Überblick. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.4.2 Schritt 1 „Umfeld und Unternehmen analysieren“ . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.4.3 Schritt 2 „Ideen identifizieren und bewerten“. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.4.4 Schritt 3 „Transformationsvorhaben auswählen“ . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.4.5 Schritt 4 „Roadmaps definieren“. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.5 Viewpoint des Szenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.6 Typische Ergebnisse des Szenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.7 Transformationsportfolio-Management am Beispiel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.8 Abhängigkeiten zu weiteren EA-Szenarien und Management-Disziplinen . . . . . . . . . . . . 29 4.9 Fazit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

C. Moser (*)  BOC Products & Services AG, Wien, Österreich E-Mail: [email protected] F. Brandmayr  Nennung der Firma im Buch nicht erwünscht, Wien, Österreich E-Mail: [email protected] © Der/die Herausgeber bzw. der/die Autor(en), exklusiv lizenziert durch Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 D. Karagiannis et al. (Hrsg.), Benutzerzentrierte Unternehmensarchitekturen, https://doi.org/10.1007/978-3-658-30537-6_4

59

60

C. Moser und F. Brandmayr

4.1 Transformationsportfolio-Management und die ADM Die Aufgabe der Unternehmensarchitektur ist es, das Unternehmen kontinuierlich weiterzuentwickeln und zu verbessern. Dies erfolgt über die Umsetzung von Transformationsvorhaben. Diese müssen Vorteile für die Benutzer und somit einen messbaren Beitrag für den Unternehmenserfolg bringen. Nur so findet die Architekturarbeit im Unternehmen Akzeptanz. In diesem Zusammenhang stellt sich aber die Frage, wie das ­UnternehmensarchitekturManagement dabei unterstützen kann, dass zukünftige Transformationsvorhaben auf die Bedürfnisse der Benutzer wie Kunden, Mitarbeiter, Partner etc. ausgerichtet sind. Wie kann sichergestellt werden, dass Transformationsvorhaben einen direkten und vor allem messbaren Mehrwert für die verschiedenen Benutzertypen bringen? Die Antwort liegt auf der Hand: Unternehmensarchitektur-Management muss auf jene Transformationsvorhaben setzen, die das höchste Potenzial für die Benutzer bieten. Dazu gilt es, (digitale) Geschäftsmöglichkeiten frühzeitig zu erkennen und zu bewerten. TOGAF® widmet sich diesem eher strategischen Aspekt des ­Unternehmensarchitektur-Managements nur zu geringen Teilen. Mit dem vorliegenden Kapitel wollen die Autoren dazu beitragen, den Blick auf das Wesentliche zu schärfen. ­Transformationsportfolio-Management dient vor allem dazu, die richtigen Transformationszyklen zu initiieren. Abb. 4.1 verdeutlicht diesen Sachverhalt. Es wird dargestellt, dass Entscheidungen über die Durchführung von Transformationsvorhaben über alle Architekturverbesserungszyklen hinweg koordiniert werden müssen. Im Zuge der Ausarbeitung und Implementierung neuer Architekturen kommt es immer wieder zu neuen Erkenntnissen. Diese erfordern mitunter die Re-Priorisierung bereits geplanter Transformationsvorhaben bzw. Anpassungen am Wirkungsbereich der Transformationsvorhaben. Um dieser Situation gerecht zu werden, gilt es, eine Reihe an Schnittstellen zu den Phasen der ADM zu definieren. Abb. 4.2 gibt einen ersten Überblick. Traditionelle Vorgehensweisen im Strategie- und Projektportfolio-Management greifen oftmals zu kurz, um auf die heutzutage schnelllebigen Anforderungen der Märkte zu reagieren. Langfristige Planungszyklen, in welchen zuerst die strategische Ausrichtung des Unternehmens definiert wird und darauf basierend ein- oder sogar mehrjährige Budgetplanungen erfolgen, bevor Transformationsvorhaben überhaupt erst in Angriff genommen werden können, erscheinen nicht mehr zeitgemäß. Agile Planungsmethoden sind gefordert. Diese dürfen aber nicht als Freibrief für ungesteuertes unternehmerisches Handeln verstanden werden. Agile Entwicklungsmethoden und DevOps (einem ­Prozessverbesserungs-Ansatz aus den Bereichen der Softwareentwicklung und Systemadministration) alleine sind nicht die Lösung. Auch für derartige Initiativen werden Ressourcen aufgewendet und Ressourcen sind in der Regel knapp. Es muss sichergestellt werden, dass alle Initiativen zum Unternehmenserfolg beitragen. Somit müssen diese genauso wie eher traditionell organisierte Projekte im Fokus des Transformationsportfolios stehen.

4 Transformationsportfolio-Management

61

In den Phasen V und A wird entschieden, ob ein Transformationsvorhaben angestoßen wird. FOKUS DES TRANSFORMATIONS-PORTFOLIO-MANAGEMENTS

V

A

H

B s

G

AM

F

C

D E

V Vorbereitung | A Architekturvision | B Geschäftsarchitektur C Informationssystem-Architekturen | D Technologiearchitektur | E Chancen & Lösungen F Migrationsplanung | G Steuerung der Implementierung H Management der Architekturveränderung | AM Anforderungsmanagement

Abb. 4.1   Entscheidung über Transformationsvorhaben außerhalb der ADM

Für die Planung des Transformationsportfolios braucht es eine holistische Sicht auf die Organisation und teilweise über die Organisationsgrenzen hinaus. Ein zentraler Zugang zu Architekturinformationen – im Sinne eines digitalen Zwillings der Organisation – ist die Basis, um die wesentlichen Bedarfe zu erkennen und einzuordnen, um auf dieser Grundlage die gewinnbringendsten Transformationsvorhaben zu identifizieren. Die Notwendigkeit, rasch auf Marktbedürfnisse zu reagieren und die oftmals fehlende ganzheitliche Sicht auf das Unternehmen stellen ein Problem dar. Organisatorische und technische Anpassungen werden oftmals entkoppelt vom Rest des Unternehmens realisiert. In vielen Fällen folgen diese Anpassungen nicht der Unternehmensstrategie. Als Beispiel für missglückte technische Projekte kann ein unkontrolliertes Wachstum an Mobile-Apps oder – in moderneren IT-Architekturen etwa – an Micro-Services gesehen werden. Es werden zwar agile Methoden angewendet, aber die erhofften Mehrwerte für die Organisation stellen sich nicht ein. Am Ende steht immer der hohe Wartungsaufwand für ungenügend geplante IT-Architekturen.

62

C. Moser und F. Brandmayr Neue Ideen und Verbesserungspotenziale für das Transformationsportfolio auf Grund neuer Erkenntnisse hinsichtlich der aktuellen Geschäftsperformance

Go/No-GoEntscheidung

V

Anpassung der initialen Roadmap aufgrund neuer Erkenntnisse im Architekturdesign

A H

G

B

AM

F

C

D E

Anpassung des Transformationsportfolios aufgrund neuer Erkenntnisse in der Planung

V Vorbereitung | A Architekturvision | B Geschäftsarchitektur C Informationssystem-Architekturen | D Technologiearchitektur | E Chancen & Lösungen F Migrationsplanung | G Steuerung der Implementierung H Management der Architekturveränderung | AM Anforderungsmanagement

Abb. 4.2   Schnittstellen zwischen dem Transformationsportfolio-Management und der ADM

Beispiele finden sich aber nicht nur in der IT. Das Gleiche gilt für Kundenbindungsprogramme, neue Produkte und Produktfeatures und natürlich auch für Geschäftsprozesse. Diese werden oftmals entkoppelt vom Rest des Unternehmens gestaltet und etabliert, um rasch auf akute Bedürfnisse von Benutzern reagieren zu können. Wird die Organisation darauf nicht ausreichend vorbereitet, können diese später nicht angemessen serviciert werden. Die Probleme entstehen bereits am Reißbrett. Es braucht ein Regelwerk, an dem sich die Mitarbeiter orientieren können. INFO

Die Portolankarte (von lateinisch portus = „Hafen“) in Abb. 4.3 stammt aus dem 13. Jahrhundert. Sie ist nach ihrem Fundort Pisa benannt und gilt als älteste erhaltene Seekarte der Welt. Die Karte zeigt das Mittelmeer, das Schwarze Meer

4 Transformationsportfolio-Management

63

Abb. 4.3   Carta Pisana. Bild DT9H68 Carta Pisana, ca. 1275–1300. Artist: Anonymous master, Bildanbieter: Heritage Image Partnership Ltd/Alamy Stock Foto, inspiriert durch 100 Diagrams that Changed the World (vgl. Christianson 2012)

und die europäische Atlantikküste. Das darauf dargestellte Liniennetz dient dazu, den Kurs mithilfe eines Kompasses zu bestimmen. Das Liniennetz für ­Unternehmensarchitektur-Aktivitäten und Unternehmenstransformation ist die Unternehmensstrategie. An dieser wird alles Weitere ausgerichtet.

Gleichzeitig muss ein Umfeld geschaffen werden, sodass Mitarbeiter innovative Ideen und Chancen erkennen und sich mit diesen einbringen können. Es darf nicht abgewartet werden, dass innovative Ideen in Innovationsteams oder gar in den „Führungsetagen“ entstehen. Vielmehr muss das Innovationspotenzial aller Mitarbeiter, aber auch jenes der Benutzer heutiger und zukünftiger Produkte und Services im Ecosystem genutzt werden. Erfolgreiche Unternehmenstransformation ist keine einmalige Sache. Sie muss permanent beschritten werden. Die Unternehmensstrategie gibt die Leitplanken vor. Sie fokussiert auf zukünftige Marktentwicklungen, anstatt kurzfristig die heutigen Geschäftsmodelle, Produkte und Geschäftsservices zu optimieren. Keinesfalls sollte sie allerdings ein Korsett für detaillierte mehrjährige Budgetplanungen darstellen. In den nachstehenden Abschnitten wird beschrieben, wie diese herausfordernde Aufgabe bewerkstelligt werden kann und welche Rolle ­Unternehmensarchitektur-Management dabei einnimmt. Unter anderem werden folgende Fragestellungen diskutiert:

64

C. Moser und F. Brandmayr

• Wie können interne und externe Einflüsse auf das Unternehmen systematisch identifiziert und evaluiert werden? • Wie kann ein Umfeld geschaffen werden, sodass an der Unternehmensstrategie ausgerichtete Ideen identifiziert werden können? • Wie kann eine zentrale Informationsbasis für diese Zwecke etabliert werden? • Wie können Ideen bewertet werden und • wie können diese in das Portfolio zukünftiger Transformationsvorhaben einfließen? • Wie wird eine Benutzerzentrierung von Architekturinitiativen in diesem Zusammenhang sichergestellt und • wie kann der Erfolg dieser Initiativen gemessen werden? Zuvor wird im folgenden Abschnitt noch ein Überblick über wesentliche Konzepte und Begriffe des Transformationsportfolio-Management gegeben.

4.2 Wesentliche Konzepte und Begrifflichkeiten Unter Transformationsportfolio-Management wird in Anlehnung an das klassische Projektportfolio-Management eine Methode verstanden, um Unternehmensinvestitionen an den Zielen der Organisation auszurichten. Durch ­ TransformationsportfolioManagement werden Ressourcensituation und Risiken, die sich aus der Abwicklung bzw. Nicht-Abwicklung der Transformation ergeben, in Einklang gebracht. Abhängigkeiten zwischen den Transformationsvorhaben werden nachvollziehbar dokumentiert, um auf Veränderungen rasch reagieren zu können. INFO

Im vorliegenden Buch wird bewusst der oft übliche Begriff Programmmanagement vermieden, um zu verdeutlichen, dass es nicht darum geht, auf traditionelle Weise eine klar definierte Menge inhaltlich zusammengehöriger Projekte zu steuern. Vielmehr geht es darum, auf eine agile Weise notwendige Unternehmenstransformationen auf Schiene zu bringen. Die dafür durchzuführenden Projekte sind zu Beginn oftmals noch nicht klar, und werden erst im Zuge der Ausarbeitung der Architekturen identifiziert.

Am Anfang eines Transformationsvorhabens steht eine Idee. Der Prozess der Ideenfindung, -entwicklung und die Kommunikation derselben wird als „Ideation“ bezeichnet. Der Begriff besteht aus den Wortteilen „idea“ (dt. Idee) und „generation“ (dt. Erzeugung). Es gibt eine Vielzahl an Techniken, die angewendet werden können, um Ideen zu identifizieren und zu entwickeln. Eine von den Autoren häufig eingesetzte Methode ist Scene2Model (vgl. OMiLAB 2020). Scene2Model ermöglicht Digital

4 Transformationsportfolio-Management

65

Design Thinking. Beispielhaft wird der Ansatz unter Verwendung der Scenes Methode von SAP (vgl. SAP User Experience Community 2013) demonstriert. SCAMPER, Brainwalk, Worst possible idea und Mindmap sind weitere Beispiele. Weiterführende Informationen zu diesen Techniken finden sich beispielsweise in (Dam und Siang 2018). Ideation wird vielfach als Teilschritt im Design Thinking verstanden – ein Ansatz, der in den letzten Jahren auch in Architekturteams Anklang findet. Design Thinking zielt auf die kreative Zusammenarbeit interdisziplinärer Teams ab und beruht im Kern darauf, den Nutzer in den Mittelpunkt des Handels zu stellen. Im Rahmen von Unternehmensarchitektur-Management kann Design Thinking die Entwicklung trag­ fähiger Ideen für die notwendige Unternehmenstransformation unterstützen. Im vorliegenden Kapitel werden jedoch nicht die verschiedenen Methoden in diesem Zusammenhang diskutiert. Vielmehr wollen die Autoren verdeutlichen, dass die an der Architekturgestaltung beteiligten Rollen in interdisziplinären Teams zusammenarbeiten, um Ideen zu entwickeln, zu bewerten und letztendlich in Transformationsvorhaben zu gießen. Für weitere Informationen zu Design Thinking im Unternehmenskontext wird auf (Hilbrecht und Kempkens 2013) verwiesen. Um Ideen überhaupt bewerten zu können, bedarf es eines Orientierungsrahmens. Hierzu werden in der Regel u. a. die im Folgenden umrissenen Konzepte genutzt: Die Vision eines Unternehmens beschreibt einen idealen Zustand in der Zukunft, den das Unternehmen erreichen möchte. Eine gute Vision schafft einen Orientierungsrahmen für die Mitarbeiter des Unternehmens. Sie beschreibt jedoch nicht, wie dieser Zielzustand erreicht wird. Ebenso sollte die Mission des Unternehmens definiert werden. Die Mission richtet sich nicht nur an die Mitarbeiter, sondern an alle Stakeholder des ­Unternehmens-Ecosystems; u. a. auch an die Kunden. Es handelt sich dabei um eine verständliche Beschreibung des Unternehmenszwecks. Sie operationalisiert die Vision und wird durch Ziele messbar gemacht. Unter Strategie verstehen die Autoren in diesem Zusammenhang ein Bündel an Plänen und Maßnahmen des Unternehmens, die an der Vision ausgerichtet sind und die Mission konkretisieren. Eine Strategie ist somit ein langfristiger Plan. Die Strategie wird durch das Portfolio an Transformationsvorhaben definiert. Dieses Portfolio wird durch das Management laufend an Faktoren wie Marktanforderungen, Kundenbedürfnissen, regulatorischen Rahmenbedingungen und (neuen) technischen Möglichkeiten ausgerichtet. Ein Transformationsvorhaben steht immer für einen Durchlauf durch einen ADM-Zyklus und wird durch das Architekturteam begleitet. Projekte wiederum sind Teil der Transformationsvorhaben. Transformationsvorhaben werden entlang der TOGAF® ADM entwickelt und durch ein oder mehrere Projekte (vgl. The Open Group 2018, PART II, Phase F, Kap. 13) realisiert. Im nächsten Abschnitt werden die wesentlichen beteiligten Stakeholder beschrieben. In ihrer jeweiligen Rolle sind sie bei der Erstellung der Architekturartefakte involviert und treten gleichzeitig oftmals als Benutzer derselben auf. Die nachfolgenden Erörterungen

66

C. Moser und F. Brandmayr

beziehen sich auf die Sicht des Unternehmensarchitektur-Managements. Es ist nicht wichtig, dass genau die gleichen Rollen im Unternehmen etabliert sind. Viel wichtiger ist es, zu erkennen, dass erfolgreiches Unternehmensarchitektur-Management erfordert, dass Architekturteams in den Strategie- und Planungsprozessen mitwirken und sich nicht nur auf die Abwicklung von Projekten oder das Pflegen von Portfolios zurückziehen.

4.3 Stakeholder und Geschäftsrollen Das Transformations-Steuerungsboard als Hauptnutzer der zu erstellenden Architekturartefakte dient als Steuerungsorgan, welches sich in der Regel aus dem Unternehmensmanagement (CxOs und Bereichsleiter) und Teilen des ­Architekturmanagement-Teams zusammensetzt. Wichtig ist, dass die Teilnehmer Entscheidungsbefugnis über aktuelle und zukünftige Transformationsvorhaben haben. Unternehmensarchitekten arbeiten mit dem Management zusammen und bereiten die Informationen zu den individuellen Transformationsvorhaben auf, sodass Entscheidungen zu individuellen Transformationsvorhaben effizient getroffen werden können. Sie halten in diesem Zusammenhang die Fäden zusammen. Ihre Aufgabe ist es, Ideen zu konsolidieren und deren Auswirkungen auf das Unternehmen aufzuzeigen. Sie sind verantwortlich dafür, dass die notwendigen Informationen im Idealfall an zentraler Stelle vorgehalten werden. Sie unterstützen bei der Definition messbarer Ziele und fokussieren auf geschäftszentrierte Ergebnisse. Ist die Entscheidung zu einem Transformationsvorhaben gefallen, arbeiten die Unternehmensarchitekten mit ihren Teams an der Umsetzung im Rahmen des Architekturzyklus (vgl. The Open Group 2018, PART II, ADM, Kap. 4 ff.). CxOs (Chief … Officers) bezeichnen Führungskräfte auf oberster Hierarchie-Ebene des Unternehmens. Im vorliegenden Kapitel wird auch die Rolle „Bereichsmanager“ verwendet. Dies soll verdeutlichen, dass nicht ausschließlich die oberste Führungsriege an der Definition des Transformationsportfolios mitwirkt. CTOs (Chief Technology Officers) und Technologiearchitekten identifizieren relevante und neue Technologien sowie Technologietrends, die das Potenzial haben, die Unternehmensstrategie und somit den Markterfolg des Unternehmens positiv zu beeinflussen. CIOs (Chief Information Officers) und CDOs (Chief Digital Officers) arbeiten eng zusammen. Sie verantworten die Realisierung von Ideen aus technischer Sicht. Dabei müssen sie einen holistischen Blick auf das Unternehmen einnehmen. Ihre Aufgabe ist es, die Unternehmensstrategie optimal durch IT-Services zu unterstützen und mitzugestalten. Dabei haben sie die Ressourcen im Blickfeld und stellen sicher, dass die notwendigen Veränderungen mit den passenden Verfahren umgesetzt werden. Prozess-, Applikations-, Technologie- und Datenverantwortliche sowie viele andere Mitarbeiter aus Unternehmensbereichen wie Marketing, Sales oder Service Delivery sind angehalten, ihre Ideen beizusteuern. Zu diesem Zweck müssen sie die

4 Transformationsportfolio-Management

67

generelle Ausrichtung der Unternehmensstrategie verstehen, damit zielgerichtet Input geleistet werden kann. Finanzplaner unterstützen das Architekturteam bei der Erstellung von Business Cases und bei der Bewertung von Ideen aus Kosten- und Ertragssicht. Gleichermaßen unterstützen sie bei der Definition von KPIs, um Transformationsvorhaben und deren Ergebnisse aus Ertragssicht laufend zu überwachen und zu bewerten.

4.4 Vorgehensweise im ­­TransformationsportfolioManagement 4.4.1 Die Vorgehensweise im Überblick Erfolgreiches Unternehmensarchitektur-Management erfordert die Fokussierung auf spezifische Ziele mit klar definierten Beiträgen zum Geschäftserfolg. Die Dokumentation dieser Ziele inklusive der Motivation für anstehende Veränderungen ist der gemeinsame Orientierungspunkt für alle beteiligten Geschäftsakteure. Die Ziele werden aus internen und externen Einflussfaktoren abgeleitet. Als Teil der Unternehmensanalyse werden Ideen zur Nutzung identifizierter Potenziale zentral gesammelt und bewertet. Jene Ideen mit dem höchsten Potenzial werden zu Transformationsvorhaben weiterentwickelt. Diese müssen einen eindeutigen Geschäftsnutzen bringen. Wie der Wertbeitrag der Transformationsvorhaben messbar gemacht wird, ist von Beginn an festzulegen. Im Zuge der Umsetzung des Transformationsvorhabens muss der Wertbeitrag für die Benutzer gemessen werden. Basierend auf diesen Informationen kann das Transformations-Steuerungsboard auf das Portfolio an Transformationsvorhaben einwirken. Für jedes Transformationsvorhaben wird vom U ­nternehmensarchitekturManagement eine grobe Roadmap vorgeschlagen. Über alle genehmigten Transformationsvorhaben hinweg entsteht somit ein integrierter Plan, wodurch die Abhängigkeiten zwischen den Transformationsvorhaben transparent werden. In den nachfolgenden Abschnitten werden die erforderlichen Schritte im Detail beschrieben. Das Vorgehensmodell kann, wie in Abb. 4.4 dargestellt, grob in vier Schritte unterteilt werden.

Umfeld und Unternehmen analysieren

Ideen identifizieren und bewerten

Transformationsvorhaben auswählen

Abb. 4.4   Wesentliche Schritte im Transformationsportfolio-Management

Roadmaps definieren

68

C. Moser und F. Brandmayr

4.4.2 Schritt 1 „Umfeld und Unternehmen analysieren“ Transformationsportfolio-Management beginnt im Idealfall mit klar und nachvollziehbar definierten Mission- und Vision-Statements. Diese sind vom Management festzulegen und zu kommunizieren. Sollten diese nicht existieren, können diese im ­ Unternehmensarchitektur-Management entwickelt und mit dem Management abgestimmt werden. Mission und Vision bilden in weiterer Folge die Leitplanken für die Analyse des Unternehmensumfeldes und des Unternehmens selbst. Typische Fragestellungen bezogen auf das Unternehmensumfeld, die in diesem Schritt beantwortet werden, sind etwa: • Gibt es neue Markteinsteiger, welche die Geschäftsmodelle des Unternehmens beeinflussen? • Gibt es neue regulatorische oder gesetzliche Anforderungen, die umzusetzen sind? • Welche Bereiche des Geschäfts sind strategisch relevant? • In welchen Marktbereichen kann von Wachstumschancen ausgegangen werden? • Gibt es globale oder lokale politische Änderungen, auf die reagiert werden muss? • Welche zukünftigen Trends könnten das Nachfrageverhalten der Benutzer verändern, das Marktverhalten der Lieferanten und das Verhalten der Wettbewerber beeinflussen? • Welche technologischen Entwicklungen können gewinnbringend genutzt werden? Obige Fragen sind nur Beispiele, die dabei unterstützen, die zukünftige Stoßrichtung zu definieren bzw. zu schärfen. Es gilt, ein klares Bild über die gesellschaftlichen, wirtschaftlichen, politischen und technologischen Trends, die die Unternehmenszukunft beeinflussen, zu schaffen. Für eine systematische Analyse dieser externen Einflussfaktoren schlagen die Autoren die Methode PESTLE vor. PESTLE ist eine Methode aus dem Bereich der Makroökonomie und dient zur ­Geschäftsmodell-Visions-Entwicklung. Das Akronym PESTLE steht für (vgl. del Marmol und Feys 2015): • Political factors: politische Faktoren wie Gesetzgebung, Zölle und politische Stabilität • Economical factors: wirtschaftliche Faktoren wie Wirtschaftswachstum, Inflation und Arbeitslosigkeit • Socio-economic factors: sozio-kulturelle Faktoren wie Bevölkerungsstruktur, Bildungswesen und Demografie • Technological factors: technologische Faktoren wie technologische Innovationen, Technologielebenszyklen und Entwicklung öffentlicher Ausgaben für Forschung und Entwicklung • Legal factors: rechtliche Faktoren wie existierende und zukünftige Gesetze, Datenschutzverordnungen und Zertifizierungen • Environmental factors: ökologische Faktoren wie Standorte, Umweltschutzauflagen und die Verfügbarkeit natürlicher Rohstoffe

4 Transformationsportfolio-Management

69

Tab. 4.1  Aktivitäten des Schrittes „Umfeld und Unternehmen analysieren“ Nr. Aktivitäten

Rollen

1

Mission und Vision definieren und CxO/Bereichsmanager (R/A), Unternehmensarchitekt kommunizieren (C), Alle Mitarbeiter (I)

2

Unternehmensumfeld analysieren Unternehmensarchitekt (R), CxO/Bereichsmanager (A)

3

Ziele ableiten

Unternehmensarchitekt (R), CxO/Bereichsmanager (A)

PESTLE bietet eine grobe Struktur zur Analyse. Je genannter Faktorengruppe werden Fragen erarbeitet, die bei der Analyse des Ecosystems und damit bei der Strategiefindung unterstützen. Abhängig von Markt und Situation führt PESTLE natürlich zu abweichenden Fragestellungen. Bei der Analyse werden die einzelnen Faktoren nicht isoliert betrachtet, sondern in Beziehung zueinander gesetzt. Herausgearbeitete Chancen und Risiken können im Rahmen einer SWOT-Analyse den Stärken und Schwächen des Unternehmens gegenübergestellt werden. Am Ende muss die Analyse in klar definierte Ziele münden. Tab. 4.1 beschreibt zusammenfassend die Aktivitäten des Schrittes „Umfeld und Unternehmen analysieren“. In Klammern ist jeweils angegeben, ob eine Rolle die Durchführungsverantwortung für die Aktivität trägt (R  =  Responsible), ob sie für das Ergebnis verantwortlich zeichnet (A = Accountible), ob sie an der Aktivität mitwirkt (C = Consulted) und ob Rollen über das Ergebnis der Aktivität informiert werden (I = Informed).

4.4.3 Schritt 2 „Ideen identifizieren und bewerten“ Das Ergebnis des vorhergehenden Schrittes ist ein klar definiertes Portfolio an Zielen, die erreicht werden sollen. Jedes der Ziele ist nachvollziehbar und unmissverständlich dokumentiert, sodass sich die Mitarbeiter in der Folge daran orientieren können. Zur Erreichung der Ziele müssen in weiterer Folge Ideen für deren Umsetzung generiert werden. Eine wichtige Quelle für Ideen sind auch die in den weiteren ­EA-Szenarien (vgl. Kap. 5, 6, 7, 8 und 9) vorgenommenen Analysen. Die Autoren empfehlen die Schaffung einer Ideenplattform, an der sich alle Teams und Mitarbeiter des Unternehmens einbringen können. Das Ergebnis der im Abschn. 4.4.2 beschriebenen PESTLE-Analyse respektive die festgesetzten Ziele geben dafür die Leitplanken vor. Im Idealfall gewinnen die Unternehmensarchitekten damit ein reiches Set an Ideen, welches sie auf die vielversprechendsten und vor allem strategiekonformen Ideen reduzieren. Hierzu wird ein standardisiertes Template verwendet. Dadurch ist sichergestellt, dass Ideen und deren Beitrag zum Unternehmenserfolg vergleichbar bleiben. Tab. 4.2 zeigt ein typisches Beispiel zur Erfassung und Bewertung von Ideen.

Bewertung auf einer einheitlichen Skala, wie stark die Unternehmensziele Unternehmensarchitekt durch die Umsetzung der Idee positiv beeinflusst werden Folgende Fragen sollten etwa dazu beantwortet werden: • Ermöglicht die Umsetzung neue Geschäftsmodelle? • Werden Kernkompetenzen im Sinne von Fähigkeiten durch die Umsetzung positiv beeinflusst? • Lassen sich Wettbewerbsvorteile durch die Realisierung der Idee erzielen? • Sind Effizienzverbesserungen in Hinblick auf Kernprozesse möglich?

Strategie-Fit

Risiken

Investmentkosten

Laufende Kosten

Interne Ressourcen

…

Bewertung

Bewertung

Bewertung

Bewertung

Bewertung

…

…

Wie viele interne Ressourcen werden benötigt? (Externe Ressourcen fließen in die Investmentkosten ein.)

Erfassung der laufenden Kosten nach Umsetzung

Erfassung der erwarteten Investmentkosten

Was sind die Risiken, falls der erwartete Nutzen nicht eintritt, sich die Realisierung verzögert oder das Ressourcenbudget nicht ausreicht? Für eine detailliertere Bewertung von Risiken werden üblicherweise die Kriterien Schadensausmaß, Wahrscheinlichkeit und Entdeckbarkeit (vgl. Kap. 9) herangezogen

Zuordnung der betroffenen Fähigkeiten und Geschäftsprozessgruppen

Strategie-Fit Betroffene Fähigkeiten und Kernprozesse

…

Unternehmensarchitekt Finanzplaner

Unternehmensarchitekt Finanzplaner

Unternehmensarchitekt Finanzplaner

Unternehmensarchitekt

Unternehmensarchitekt

Jeder Mitarbeiter Unternehmensarchitekt

Jeder Mitarbeiter

Zuordnung der positiv beeinflussten PESTLE-Faktoren

Kurze und aussagekräftige Beschreibung der Idee

Verantwortliche Rolle Jeder Mitarbeiter

Organisation Verantwortlicher Geschäftsakteur Jener Mitarbeiter, der die Idee eingebracht hat

Beschreibung

Allgemein

Beschreibung Kurzbezeichnung der Idee

Strategie-Fit Beeinflusste PESTLE-Faktoren

Eigenschaft

Name

Kategorie

Allgemein

Tab. 4.2  Template zur Erfassung und Bewertung von Ideen

70 C. Moser und F. Brandmayr

4 Transformationsportfolio-Management

71

Tab. 4.3  Schema zur Bewertung von Ideen Gewicht Score: 1

Score: 2

Score: 3

Score: 5

Score: 6

Hoch

Transformierend

Strategie-Fit

4

Kein Beitrag Gering

Mittel

ROI/Zeitraum

2

€4 Mio. €3 Mio. €4 Mio.

InvestmentKosten

2

>€10 Mio.

€10 Mio. − €5 Mio − €1 Mio. − €0,5 Mio. − €5 Mio. €1 Mio. €0,5 Mio. €0 Mio.

Benötigte interne 4 Ressourcen

>10.000 h

10.000– 5000 h

5000– 2000 h

2000– 1000 h

15–50 %) Anforderung überwiegend erfüllt (>50–85 %) Anforderung vollständig erfüllt (>85–100 %)

Dieses Schema ist weit verbreitet und wird u. a. auch in COBIT für die Bewertung von Prozessbefähigungsstufen verwendet (vgl. ISACA 2019).

Als Überblick aller bewerteten Compliance-Anforderungen im Kontext der Architekturelemente eignet sich – wie in Abb. 9.3 dargestellt – eine Listendarstellung aller Bewertungs-Objekte sowie ein Tortendiagramm, welches auf den Erfüllungsgraden dieser basiert.

Abb. 9.3   Überblick über Bewertungs-Objekte sowie deren Erfüllungsgrade

9 Compliance-Portfolio-Management

219

Letztlich wird eine Begründung für die vorgenommene Bewertung des Architekturelements vom Asset-Verantwortlichen dokumentiert und der übergeordneten Kontrollinstanz verfügbar gemacht. Es muss stets nachvollziehbar sein, wie die Bewertung zustande kam.

9.4.5 Schritt 4 „Maßnahmen zur Erhöhung der Compliance identifizieren“ Im Fall nicht erfüllter Compliance-Anforderungen sind entsprechende Maßnahmen zu ergreifen, um die Compliance zu erhöhen. Tab. 9.4 zeigt die Aktivitäten, die in diesem Schritt durchgeführt werden. Maßnahmen unterschiedlichen Ausmaßes können erforderlich sein, um die Compliance eines Assets zu erhöhen. Viele Maßnahmen sind etwa im Tagesgeschäft realisierbar, während andere Maßnahmen aufgrund ihres Umfangs im Rahmen von Projekten und Transformationsvorhaben umgesetzt werden müssen. Maßnahmen zur Erhöhung der Compliance können von der Anpassung eines Assets bis hin zur Ablösung ganzer Architekturbereiche reichen. Zurück zum Beispiel: Sind die Passwortmechanismen einer Applikationskomponente nicht ausreichend, so kann entschieden werden, die Applikationskomponente dahin gehend zu erweitern. Dies kann beispielsweise durch die Vorschaltung eines ­Identity-Management-Systems oder durch die Re-Implementierung der Authentisierungskomponente der Applikationskomponente erfolgen. Je nach Aufwand und Möglichkeiten werden diese Maßnahmen direkt adressiert oder im Rahmen von Projekten geplant und realisiert. Sollten keine Maßnahmen definiert werden können, so können Ausnahmen genehmigt werden, wodurch eine abweichende Compliance akzeptiert wird. Diese gelten in der Regel auf Zeit und müssen gut begründet sein. Über Wiedervorlagen muss sichergestellt sein, dass korrigierende Maßnahmen nach Ablauf der Genehmigungsfrist mit angemessener Vorlaufzeit festgelegt werden. Tab. 9.4  Aktivitäten des Schritts „Maßnahmen zur Erhöhung der Compliance identifizieren“ Nr

Aktivitäten

Rollen

1

Maßnahmen auf Ebene des Assets identifizieren

Asset-Verantwortliche (R), Unternehmensarchitekt (A), ITSicherheitsverantwortlicher (A), Datenschutzbeauftragter (A), Architekturvorgaben-Verantwortlicher (C)

2

Maßnahmen konsolidieren

Unternehmensarchitekt (R), IT-Sicherheitsverantwortlicher (R), Datenschutzbeauftragter (R), Compliance-Manager (A), AssetVerantwortlicher (C), Architekturvorgaben-Verantwortlicher (C)

3

Maßnahmen zur weiteren Bearbeitung weiterleiten

Unternehmensarchitekt (R), IT-Sicherheitsverantwortlicher (R), Datenschutzbeauftragter (R), Compliance-Manager (A), AssetVerantwortlicher (C), Architekturvorgaben-Verantwortlicher (C)

220

P. Asadi und C. Höllwieser

Da Maßnahmen von jedem Asset-Verantwortlichen auf Ebene eines einzelnen Assets definiert werden, bedarf es nachträglich einer Konsolidierung dieser Maßnahmen. Dies erfolgt von den jeweils verantwortlichen Kontrollinstanzen, beispielsweise durch den Unternehmensarchitekten im Falle von Anforderungen, welche aus Architekturprinzipien abgeleitet wurden. Nach Identifikation der konkreten Maßnahmen werden diese an das Anforderungsportfolio-Management (vgl. Phase „Anforderungsmanagement der ADM“) zur weiteren Bearbeitung weitergeleitet. Nach erfolgter Umsetzung einer Maßnahme ist die Compliance-Bewertung erneut durchzuführen. Die Compliance-Bewertung ist grundsätzlich periodisch zu wiederholen. Innerhalb welches Zeitraums dies zu erfolgen hat, wird bereits zu Beginn im Schritt „Unternehmensspezifische Compliance-Anforderungen ableiten“ (vgl. Abschn. 9.4.3) festgelegt.

9.5 Viewpoint des EA-Szenarios Vor dem Hintergrund obiger Ausführungen wird im Folgenden beschrieben, wie die für das Compliance-Portfolio-Management relevanten Informationen erfasst und strukturiert werden. Aus ArchiMate®s Motivations-Ebene (vgl. The Open Group 2019, Kapitel „Motivation“) werden die Elemente Ziel und Prinzip verwendet. Ziele mit der Spezialisierung „Kontrollziel“ werden dazu verwendet, um Kontrollziele, welche aus den Standards und Normen extrahiert werden, zu beschreiben. Selbstauferlegte Architekturprinzipien werden mit dem Element Prinzip und der Spezialisierung „Architekturprinzip“ erfasst. Zur Konkretisierung von Kontrollzielen und Architekturprinzipien werden, wie in Abschn. 9.4.3 beschrieben, unternehmensspezifische Anforderungen definiert. Diese Anforderungen realisieren die definierten Kontrollziele und Prinzipien und werden daher über Beziehungen vom Typ „Realisierung“ mit ebendiesen verknüpft. Für jede Anforderung wird ein Geltungsbereich definiert. In der Regel beziehen sich Anforderungen auf Architekturelemente, wie beispielsweise Geschäftsprozesse, Applikationskomponenten, Systemsoftware-Elemente, Geräte usw. Dieser Sachverhalt ist mit der Gruppierung „Betroffene Assets“ im unteren Bereich des in Abb. 9.4 dargestellten Viewpoints veranschaulicht. Für die Bewertung der von den Compliance-Anforderungen betroffenen Assets werden Elemente des Typs „Bewertung“ verwendet. Bewertungen dienen somit als Bindeglied zwischen einer Anforderung und einem zu bewertenden Asset, welches wie beschrieben als Geschäftsprozess, Applikationskomponente etc. abgebildet werden kann. Diese Abhängigkeiten werden mit Beziehungen vom Typ „Assoziation“ beschrieben. Im Element Bewertung wird das Ergebnis der Compliance-Bewertung erfasst (vgl. Abschn. 9.4.4). Aus Non-Compliance ergeben sich Risiken (vgl. Abschn. 9.8). Diese werden durch das Element Treiber mit der Spezialisierung „Risiko“ dokumentiert. Sie

9 Compliance-Portfolio-Management

221

Abb. 9.4   Viewpoint für das Compliance-Portfolio-Management

beschreiben jeweils das Gesamtrisiko, dass sich aus der Einhaltung/Nichteinhaltung der Compliance-Anforderungen ergibt. Die Compliance-Bewertungsergebnisse zu einer Anforderung werden somit zu einem Gesamtrisiko zusammengefasst. Die Abhängigkeit zur Bewertung wird mit der Beziehung vom Typ „Assoziation“ dargestellt. Erforderliche Maßnahmen, welche sich aus der Non-Compliance beziehungsweise aus der damit einhergehenden Risikoeinschätzung ergeben, werden ebenfalls mittels einer Assoziationsbeziehung der Bewertung zugeordnet. Zur Dokumentation der Maßnahmen wird das Architekturelement „Arbeitspaket“ verwendet. Diese werden in weiterer Folge direkt abgearbeitet und geschlossen oder einem Transformationsvorhaben zugeordnet (siehe Kap. 4). In der Minimalausprägung werden die in Tab. 9.5 gelisteten Informationen je Architekturelement erfasst.

Kontrollziel Die aus der Quelle entnommene Beschreibung Verlinkte Compliance-Anforderungen

Spezialisierung

Beschreibung

Compliance-Anforderungen

Anforderung

Prinzip

Kurze aussagekräftige Bezeichnung, oftmals inkl. Nummer oder Paragraf

Name

Ziel

Architekturprinzip Detaillierte Beschreibung des Architekturprinzips gemäß der Empfehlungen aus TOGAF® (vgl. The Open Group 2018Part III, Kap. 20). Verlinkte Compliance-Anforderungen

Beschreibung/Aussage/Argumentation/Auswirkungen/Risiken bei Umsetzung/Risiken bei Nicht-Umsetzung

Compliance-Anforderungen

Inhalt der Compliance-Anforderung inkl. detaillierter Bewertungskriterien Für die Beschreibung der Anforderung und für die Definition des Geltungsbereichs verantwortliche Personen

Verantwortliche Personen

(Fortsetzung)

Kurze, aussagekräftige Bezeichnung

Beschreibung

Prinzipien können auch ungültig werden

Name

Gültig von/Gültig bis

Verantwortliche Personen Verantwortlich für die Pflege und Bewertung des Prinzips. Es wird periodisch (auch: Architekturvorgaben-Verantwortlicher) hinterfragt, ob ein Prinzip sich bewährt hat

Kurze, aussagekräftige Bezeichnung

Spezialisierung

Kontrollziele können auch ungültig werden, z. B. im Falle neuer Versionen des Standards

Name

Gültig von/Gültig bis

Verantwortliche Personen Verantwortlich für die Pflege und Bewertung des Kontrollziels. Es wird periodisch (auch: Architekturvorgaben-Verantwortlicher) hinterfragt, ob ein Kontrollziel sich bewährt hat bzw. noch Relevanz für das Unternehmen hat

Beschreibung

Gestaltungselement Attribut

Tab. 9.5  Attributprofile im Compliance-Portfolio-Management

222 P. Asadi und C. Höllwieser

Arbeitspaket

Treiber

Bewertung

Datum Datum

Letzte Bewertung durchgeführt am

Nächste Bewertung durchzuführen am

Kurze, aussagekräftige Bezeichnung. Projekt oder Maßnahme Kurze Beschreibung der umzusetzenden Maßnahmen Auswahlliste von „offen“ bis „abgeschlossen“ Start der Abarbeitung Ende des Projektes/der Maßnahme Weitere Kriterien je nach angewandter Projektmanagement-Methode

Name

Spezialisierung

Beschreibung

Projekt-Status

Projektstart

Projektende

…

Kurze Beschreibung des Risikos

Skala nach SPICE von „nicht erfüllt“ bis „vollständig erfüllt“; vgl. Abschn. 9.4.4

Erfüllungsgrad

Beschreibung

Verlinkung des betroffenen Assets, welches im Kontext der Anforderung zu bewerten ist

Zu bewertendes Asset

Risiko

In der Regel handelt es sich hierbei um den Asset-Verantwortlichen

Verantwortliche Personen

Spezialisierung

Detaillierte Liste der anzuwendenden Bewertungskriterien

Beschreibung

Kurze, aussagekräftige Bezeichnung.

Typ „Compliance-Bewertung“

Name

Kurze, aussagekräftige Bezeichnung

Spezialisierung

Angabe, ab wann und bis wann die Anforderung gültig ist

Gültig von/Gültig bis

Name

Geltungsbereich der Anforderung. Hier werden Kriterien definiert, sodass die Zuordnung der betroffenen Assets (im Idealfall automatisiert) erfolgen kann

Beschreibung

Betroffene Assets

Gestaltungselement Attribut

Tab. 9.5   (Fortsetzung)

9 Compliance-Portfolio-Management 223

224

P. Asadi und C. Höllwieser

INFO

Aus Non-Compliance ergeben sich Risiken. Abb. 9.5 zeigt die Risiken, die sich aus der nuklearen Katastrophe nach dem Reaktorunglück in Tschernobyl ergaben. In manchen Teilen Europas war die radioaktive Belastung 100-mal höher als die normale Hintergrundstrahlung. Warnungen wurden über aussagekräftige Kontaminationscharts verteilt und zwar schon drei Tage bevor die Verantwortlichen knappe Informationen zu einem „Missgeschick“ am Atomreaktor berichteten. Es muss nicht immer gleich ein Supergau eintreten. Dennoch, Compliance-Management unterstützt dabei, Risiken zu identifizieren und den­ selben rechtzeitig und angemessen zu begegnen.

9.6 Typische Ergebnisse des EA-Szenarios Eines der zentralen Ergebnisse des Compliance-Portfolio-Management-Szenarios ist der Katalog an unternehmensspezifischen Compliance-Anforderungen. Werden diese in einem zentralen Repository erfasst, so können diese nach Spezifikation des Geltungsbereichs —im Idealfall automatisiert – an die Asset-Verantwortlichen zur Kenntnisnahme und in weiterer Folge zur Bewertung der Assets verteilt werden. Abb. 9.6 zeigt eine Liste beispielhafter Compliance-Anforderungen, einer zugeordneten verantwortlichen Person sowie den von den Compliance-Anforderungen betroffenen Assets (Spalte „Assoziation“). Alternativ zu der vorherigen Abbildung kann das Bewertungsergebnis je Anforderung und zugehörigem Asset in einer Matrixdarstellung visualisiert werden. Abb. 9.7 zeigt die Bewertungen im Kontext der Anforderungen und der Architekturelemente. Der Erfüllungsgrad der Anforderungen wird jeweils in den Zellen der Matrix via Ampel-Code visualisiert. Nicht erfüllte Compliance-Anforderungen werden farblich ­ hervorgehoben. Der Farbencode wird in der Abbildung in Grauschattierungen dargestellt. Mittels einer Business Impact Analyse (BIA) kann ein kompletter Durchstich durch die Compliance-Portfolio-Architektur gezogen werden. Ausgehend von den Standards und Normen, die als Kontrollziele abgebildet werden, werden die unternehmensspezifischen Anforderungen abgeleitet. Diese sind wiederum mit Bewertungen in Beziehung gesetzt, welche die Bewertung der Assets ermöglichen. Abb. 9.8 zeigt diese ­BIA-Darstellung.

9.7 Compliance-Portfolio-Management am Beispiel „Steuerung von Tiroler Seilbahn offen im Netz zugänglich“. Derartige Meldungen möchte der im vorliegenden Buch beispielhaft skizzierte Bergbahnenbetreiber nie wieder in der Zeitung lesen. Die Steuerung der zentralen Gondelbahn war über ein Webinterface unverschlüsselt und ohne Notwendigkeit einer Authentisierung über das Internet erreich-

9 Compliance-Portfolio-Management

225

Abb. 9.5     Heatmap der radioaktiven Auswirkung in Tschernobyl.  Bild https://commons. wikimedia.org/wiki/File:Chornobyl_radiation_map.jpg Chornobyl radiation map, Bildanbieter: CIA Factbook/Commons Wikimedia, als gemeinfrei gekennzeichnet, inspiriert durch 100 Diagrams that Changed the World (vgl. Christianson 2012)

Abb. 9.6   Liste relevanter Compliance-Anforderungen

226

P. Asadi und C. Höllwieser

Abb. 9.7   Beispiel für eine Matrix „Asset x Bewertung x Anforderung“

bar. Derartige Sicherheitsprobleme sind nicht Fiktion, sondern Wirklichkeit, wenn man Nachrichtenmeldungen im April 2018 (vgl. Der Standard 2018) Glauben schenken darf. Bei der Steuerung der Gondelbahn handelt es sich demnach um eine Webapplikation. Die Zuordnung von Compliance-Anforderungen, wie die bereits in Abschn. 9.2 angeführte Grundschutz-Maßnahme „M 4.392 – Authentisierung bei Webanwendungen“, hätten die Notwendigkeit dahin gehender Überprüfungen „erzwungen“. Diese Sicherheitslücke hätte sich erst gar nicht aufgetan.

9.8 Abhängigkeiten zu weiteren EA-Szenarien und Managementdisziplinen Voraussetzung für die hier beschriebene Methode zum ­ Compliance-PortfolioManagement ist ein gut gepflegtes EA-Repository. Je nach Umfang des geplanten Compliance-Portfolio-Managements müssen natürlich die im Fokus stehenden Assets im

9 Compliance-Portfolio-Management

227

Abb. 9.8   Compliance-Durchstich durch die Architektur

EA-Repository erfasst und aktuell gehalten werden. Dies kann über die EA-Szenarien, wie in den Kap. 4–8 beschrieben, erreicht werden. Ohne Gesamtüberblick über die wesentlichen Assets funktioniert der hier beschriebene Ansatz nicht. Compliance mit Architekturprinzipien Architekturprinzipien dienen dazu, allen Beteiligten eines Transformationsvorhabens Richtlinien zu geben. Sie adressieren wiederkehrende Architekturfragestellungen und werden zur Beurteilung von Transformationsvorhaben und Architekturdesigns herangezogen. Architekturprinzipien können sich sowohl auf die gesamte Unternehmensarchitektur oder aber auf einzelne spezifische EA-Szenarien beziehen. Auf Ebene der Applikationslandschaft beugt beispielsweise das Prinzip „Wiederverwendung bestehender Funktionen“ der Mehrfachimplementierung redundanter Applikationsservices vor und trägt somit entscheidend zur Vermeidung unnötiger Betriebsaufwände bei. Durch das Prinzip „Vermeidung von Datenredundanz“ wird die Datenqualität hochgehalten. Auf Ebene der Technologiearchitektur gilt es, Prinzipien

228

P. Asadi und C. Höllwieser

zur Standardisierung der eingesetzten Software und Hardware zu definieren. Auf diese Weise wird die Interoperabilität der Daten, Applikationskomponenten und Technologien sichergestellt. Weitere Beispiele finden sich in TOGAF® (The Open Group 2018, Part III, Kap. 20). Informationssicherheitsmanagement (ISMS) und Risikomanagement Der Schutz wichtiger Informationen und personenbezogener Daten gewinnt für Unternehmen immer mehr an Priorität. Die im vorliegenden Kapitel beschriebene Methode dient unter anderem dazu, den Grundschutz sicherzustellen. Die Methode kann im Falle eines erhöhten Schutzbedarfs jedoch weiter in Hinblick eines umfänglichen ISMS ausgebaut werden. Eine detaillierte Methode hierfür findet sich beispielsweise im BSI Standard für Risikoanalyse (vgl. Bundesamt für Sicherheit in der Informationstechnik 2008). Ausgangsbasis für Compliance-Management sind vor allem die Normen und Standards von welchen, wie beschrieben, die unternehmensspezifischen Anforderungen abgeleitet werden. Die Methode kann aber auch ausgehend von Risiken angewendet werden. In diesem Fall dienen im Idealfall Risikokataloge, wie beispielsweise der Gefährdungskatalog des BSI Grundschutz-Kompendiums (siehe Bundesamt für Sicherheit in der Informationstechnik 2018), als Ausgangsbasis. Für die Risiken werden Geltungsbereiche definiert, die dann wiederum die Zuordnung der Risiken auf die betroffenen Assets ermöglichen. Die Risiko-Asset-Kombinationen können dann bewertet werden. Risiken müssen im Einzelfall abgeschätzt und bewertet werden, sodass in weiterer Folge festgelegt werden kann, ob Handlungsbedarf für das Unternehmen besteht. Es gibt eine Vielzahl an Methoden zur Bewertung von Risiken. In Projekten der Autoren hat sich die Bewertung nach der FMEA-Methode (siehe Pfeufer 2014) bewährt. FMEA steht für Failure Mode and Effect Analysis (dt.: Fehler-Möglichkeits- und ­Einfluss-Analyse). Nach dieser Methode werden Risiken nach Eintrittswahrscheinlichkeit, Auswirkung und Entdeckbarkeit bewertet: • Eintrittswahrscheinlichkeit Wie hoch ist die Wahrscheinlichkeit, dass das Risiko eintritt? Die möglichen Bewertungen reichen von „Nie“ (Eintritt extrem unwahrscheinlich) bis „Immer“ (Eintritt nahezu sicher). Je nach Kategorie wird ein Wert von 1 bis 10 festgelegt. • Auswirkung Wie hoch wäre der Schaden, falls das Risiko eintreten würde? Hierbei wird von „Zu vernachlässigen“ (keinerlei Beeinträchtigung) bis „Gefährlich/illegal“ (z. B. Gefahr für Leib und Leben) unterschieden. Zur Nutzung der Skala werden eindeutige und immer gleich anzuwendende Kriterien festgelegt. Je nach Kategorie wird ein Wert von 1 bis 10 festgelegt.

9 Compliance-Portfolio-Management

229

• Entdeckbarkeit Wie wahrscheinlich wäre die sofortige Entdeckung eines eintretenden Risikos und kann der mögliche Schaden rechtzeitig eingedämmt werden? Hier reicht die Skala von „Nie“ bis „Immer“. Genauso wie bei den anderen Kriterien wird wiederum ein Wert zwischen 1 und 10 festgelegt. Aus den oben erwähnten Kriterien wird ein Risikowert (Value at Risk) durch Multiplikation der Einzelwerte berechnet. Der Risikowert liegt somit zwischen 0 und 1000. Übersteigt der Gesamtwert eine vom Risiko-Manager festgelegte Marke („Risikoappetit“), so besteht Handlungsbedarf für das Unternehmen. Datenschutz Im Fokus des Datenschutzes steht, wie der Name bereits ausdrückt, der Schutz von Daten in Hinblick auf missbräuchliche Verarbeitung und Nutzung. Im Mittelpunkt stehen dabei in der Regel personenbezogene Daten. In der europäischen Datenschutzgrundverordnung (EU-DSGVO) sind Rechte und Pflichten von Unternehmen im Umgang mit personenbezogenen Daten geregelt (siehe Voigt und von dem Bussche 2018). Für Unternehmen, die den Datenschutz ihrer Kunden verletzen, stehen hohe Konventionalstrafen im Raum. Unternehmen sind verpflichtet, ein sogenanntes Verzeichnis an Verarbeitungstätigkeiten zu erstellen und zu pflegen. Je Verarbeitungstätigkeit sind Zweck der Datenverarbeitung, Verantwortliche, verarbeitende Applikationskomponenten etc. zu erfassen. Für jede Verarbeitungstätigkeit sind sogenannte technische und organisatorische Maßnahmen (TOMs) zu ergreifen. Darunter fallen u. a. Regeln, Vorgaben und Handlungsanweisungen, die dazu dienen, dass Mitarbeiter den Datenschutz gesetzestreu einhalten. TOMs werden in der vorliegenden C ­ ompliance-Portfolio-Management-Methode als Kontrollziele abgebildet. Sie werden in konkrete, unternehmens-spezifische Anforderungen detailliert. Im nächsten Schritt werden die Compliance-Anforderungen den Verarbeitungstätigkeiten zugeordnet und deren Einhaltung bewertet. Bei Nicht-Einhaltung erfolgt wiederum eine Risikoabschätzung, die in weiterer Folge zu ­ Maßnahmen und Projekten zur Risikominimierung und Erhöhung der Compliance führen. Betriebskontinuitäts-Management Betriebskontinuitäts-Management (engl. Business Continuity Management) steht in einem engen Zusammenhang mit Informationssicherheitsmanagement (ISMS) und Risikomanagement (vgl. oben). Governance-Frameworks, wie COBIT (vgl. ISACA 2019, Abschn. DSS04.04 und DSS04.05), fordern das regelmäßige Testen und Überprüfen der definierten Kontinuitätspläne. Compliance-Portfolio-Management kann hierzu einen wesentlichen Beitrag leisten. Die in den Kap. 4–8 beschriebenen Portfolios und die sich daraus ergebenden Zusammenhänge und Architekturen bilden eine ideale Ausgangsbasis für die im

230

P. Asadi und C. Höllwieser

Betriebskontinuitäts-Management geforderten Business Impact-Analysen (dt. Geschäftsauswirkungsanalysen). So werden z. B. aus der Bewertung von Capabilities (vgl. Kap. 5), der Daten (vgl. Kap. 7) und den Applikationskomponenten (vgl. Kap. 6) potenzielle Szenarien, die erhebliche, unterbrechende Störungen (vgl. ISACA 2019, Abschn. DSS04.02) nach sich ziehen können, entwickelt und analysiert. Um eine systematische und kontinuierliche Analyse der Geschäftsauswirkungsanalysen und der notwendigen Maßnahmen zur Sicherstellung der Geschäftskontinuität zu gewährleisten, werden externe Architekturvorgaben (z. B. die in COBIT definierten Managementpraktiken und Aktivitäten) in Form von Kontrollzielen abgebildet und in weiterer Folge als Compliance-Anforderungen spezifisch auf die wesentlichen Architekturelemente des Unternehmens ausgeprägt. Die laufende Bewertung der Compliance-Anforderungen und das Ableiten entsprechender Maßnahmen ist ein wesentlicher Bestandteil eines funktionierenden Betriebskontinuitätsmanagement-Systems (vgl. British Standard 2007). Die Aktivität „Terminieren Sie Übungen und Testaktivitäten gemäß den Festlegungen im Kontinuitätsplan“ (vgl. ISACA 2019, Abschn. DSS04.04-4) ist ein Beispiel eines Kontrollziels, dessen regelmäßige Durchführung gewährleistet werden muss. Als Compliance-Anforderung bezieht sich diese Überprüfung auf einzelne oder eine Gruppe von Geschäftsprozessen und/oder Applikationskomponenten, welche beispielsweise im Applikationsportfolio bewirtschaftet werden. Transformationsportfolio-Management. Im Zuge des Compliance-Portfolio-Managements werden Assets bezüglich ihrer Compliance mit Architekturvorgaben bewertet. Jene Assets mit einer mangelnden Compliance-Bewertung bedürfen infolgedessen der Umsetzung spezifischer Maßnahmen, um die Compliance zu steigern. Viele Maßnahmen sind im Tagesgeschäft realisierbar, während andere Maßnahmen aufgrund ihres Umfangs eine längere Zeit für deren Erfüllung in Anspruch nehmen. Für Maßnahmen, die nicht direkt im operativen Geschäft umgesetzt werden können, werden konkrete, aus den Bewertungen abgeleitete Anforderungen an das Anforderungsportfolio-Management weitergeleitet. Anschließend werden diese ­ Anforderungen konsolidiert, priorisiert und im Rahmen von Transformationsvorhaben geplant und realisiert.

9.9 Fazit Aus Compliance-Sicht gilt es stets externe (in Form von Richtlinien, Standards, Normen) und interne (in Form von Architekturprinzipien) Architekturvorgaben einzuhalten. Dazu müssen die für ein Unternehmen bzw. für Transformationsvorhaben relevanten Architekturvorgaben identifiziert und in unternehmensspezifische ­Compliance-Anforderungen konkretisiert werden. Anschließend muss für den jeweiligen Geltungsbereich einer solchen Anforderung die Compliance bewertet und gegebenenfalls

9 Compliance-Portfolio-Management

231

Maßnahmen zur Erhöhung der Compliance definiert werden. Diese Maßnahmen können entweder ad-hoc implementiert oder müssen als Teil eines neuen Transformationsvorhabens geplant werden. Mittels der im vorliegenden Kapitel beschriebenen Methode kann die Identifikation, Konkretisierung und Zuteilung der für einen Mitarbeiter relevanten ­Compliance-Anforderungen automatisiert werden. Mitarbeiter müssen sich somit nicht durch einen Dschungel an Architekturvorgaben durchkämpfen, um die für sie und ihre Assets relevanten Vorgaben zu identifizieren. Dies führt zu mehr Akzeptanz der Notwendigkeit der Compliance-Bewertungen und in der Folge zu geringeren Risiken durch ­Non-Compliance. Werden Compliance-Anforderungen, deren Erfüllungsgrad und die sich aus der Nichterfüllung ergebenden Risiken mit der Architekturdokumentation verknüpft, so entsteht ein digitaler Zwilling der Organisation, der dessen Benutzern tiefe Einblicke in die Risikosituation der Organisation ermöglicht.

Literatur Beresford, Nicholas A., und Jim T. Smith. 2005. Chernobyl: catastrophe and consequences. Berlin: Springer Praxis Publ. British Standard. 2007. BS 25999-2:2007 Business continuity management. London: British Standards. Bundesamt für Sicherheit in der Informationstechnik. 2008. BSI-Standard100-3, Risikoanalyse auf der Basis von IT-Grundschutz – Version 2.5. https://www.bsi.bund.de. Zugegriffen: 31. Juli 2020. Bundesamt für Sicherheit in der Informationstechnik. 2018. IT-Grundschutz-Kompendium. Köln: Bundesanzeiger Verlag. Christianson, Scott. 2012. 100 diagrams that changed the world: From the earliest cave paintings to the innovation of the iPod. New York: Penguin. Der Standard. 2018. Hacker hatten Zugriff auf Steuerung von Tiroler Gondelbahn. https:// derstandard.at/2000078303870/Hacker-Hatten-Zugriff-auf-Steuerung-von-Tiroler-Gondelbahn. Zugegriffen: 31. Juli 2020. ISACA. 2019. COBIT 2019 Framework: Governance and management objectives. http://www. isaca.org/COBIT/Pages/COBIT-5-german.aspx. Zugegriffen: 30. Juli 202. ISO/IEC. 2003. ISO/IEC 15504-5 Software process improvement and capability determination. https://www.iso.org/standard/60555.html. Zugegriffen: 30. Juli 2020. ISO/IEC. 2013. ISO/IEC 27000, 27001 and 27002 for information security management. Journal of Information Security 4:92. Paal, Boris P., Daniel A. Pauly, Stefan Ernst, Eike M. Frenzel, Barbara Körffer und Mario Martini, (2017). Datenschutz-Grundverordnung. Munich: CH Beck. Pfeufer, Hans-Joachim. 2014. FMEA – Fehler-Möglichkeits-und Einfluss-Analyse. München: Hanser. The Open Group. 2018. The Open Group Architecture Framework TOGAF®, Version 9.2. https:// pubs.opengroup.org/architecture/togaf9-doc/arch/. Zugegriffen: 30. Juli 2020. The Open Group. 2019. ArchiMate 3.1 Specification. Voigt, Paul, und Axel von dem Bussche. 2018. EU-Datenschutz-Grundverordnung (DSGVO) – Praktikerhandbuch, 1. Aufl. Berlin: Springer.

Benutzererfahrung als Wegweiser in der Geschäftstransformation

10

Wilfrid Utz, Christine Schrüffer und Christoph Moser

Inhaltsverzeichnis 10.1 Die Stimme der Benutzer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2 Ansatz zur Analyse der Benutzererfahrung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3 Benutzerzentriertes Feedback zur Servicequalität. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.4 Bewertung der Dienstleistungsqualität am Beispiel eines Skigebietes. . . . . . . . . . . . . . . 10.5 Fazit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

233 235 238 243 246 247

10.1 Die Stimme der Benutzer Alle in den vorangegangenen Kapiteln beschriebenen Szenarien zielen auf die im Rahmen der Geschäftstransformation notwendigen Ausgestaltung der Unternehmensarchitektur ab. Insbesondere die Benutzererfahrung (engl. User Experience) spielt bei der Ausgestaltung der Unternehmensarchitektur eine wesentliche und gleichzeitig oftmals unterschätzte Rolle. Durch das unmittelbare Feedback der Benutzer, seien es Kunden oder mindestens genauso wichtig Mitarbeiter der im Ecosystem teilnehmenden

W. Utz  OMiLAB gGmbH, Berlin, Deutschland E-Mail: [email protected] C. Schrüffer · C. Moser (*)  BOC Products & Services AG, Wien, Österreich E-Mail: [email protected] © Der/die Herausgeber bzw. der/die Autor(en), exklusiv lizenziert durch Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 D. Karagiannis et al. (Hrsg.), Benutzerzentrierte Unternehmensarchitekturen, https://doi.org/10.1007/978-3-658-30537-6_10

233

234

W. Utz et al.

Organisationen, können Optimierungspotenziale identifiziert werden. Zielarchitekturen werden stärker an die Nutzerbedürfnisse ausgerichtet. Prominente Frameworks, wie beispielsweise ITIL und COBIT, fokussieren stark auf Compliance und Prozesseffizienz. Die Bedürfnisse der Benutzer werden oftmals nicht ausreichend berücksichtigt. Themen wie Customer Experience und Employee Experience werden kaum adressiert. Genauso wenig wie ITIL und COBIT streichen die prominenten Architekturframeworks, wie beispielsweise TOGAF®, die Benutzerzentrierung heraus. Mit dem folgenden beschriebenen Ansatz wird dargelegt, wie die Stimme der Benutzer in der Architektur berücksichtigt werden kann. Die Themenfelder, die die Erfahrungen der Benutzer als Input erfordern, sind dabei sehr vielfältig. Deren Schwerpunkte können etwa folgende sein: • Einschätzung der strategischen Bedeutung geplanter Projekte im Rahmen des ­Transformationsportfolio-Managements (vgl. Kap. 4), • Bewertung der Qualität von Applikationsservices im Rahmen des ­ApplikationsportfolioManagements (vgl. Kap. 6) oder • die Abschätzung von Schutzbedarfsanforderungen für kritische Unternehmensdaten im Rahmen des Datenportfolio-Managements (vgl. Kap. 7). Während in den letzten Jahren in den Bereichen Produktentwicklung und Anwendungsentwicklung der Ansatz des User-centred Designs (dt. nutzerorientierte Gestaltung) immer mehr Anklang findet, haben derartige Methoden für die gesamtheitliche Steuerung der Unternehmenstransformation noch wenig Verbreitung gefunden. Der Benutzer und dessen Bedürfnisse und Ziele stehen oftmals nach wie vor nicht im Mittelpunkt der Betrachtung. Heutzutage arbeiten zwar User Interface Designer an der kontinuierlichen Verbesserung der digitalen Erfahrung, wenn es um die Entwicklung neuer Apps geht. Und Service Designer definieren digitale Customer Journeys, die die Kontaktpunkte zum Kunden genau analysieren und optimieren. Die angewandten Methoden und deren Ergebnisse sind jedoch oftmals nicht ausreichend verzahnt. Somit entsteht kein stimmiges Bild – keine benutzerzentrierte Zielarchitektur – welches an den Strategien der Organisation ausgerichtet ist. Der in diesem Kapitel beschriebene Ansatz adressiert diese Lücke. An dieser Stelle soll nochmal die Definition eines Benutzers in Erinnerung gerufen werden.  Benutzer  Ein Benutzer ist jeder Stakeholder der Organisation, mehr noch: des Ecosystems, in dem die Organisation eingebettet ist. Dabei kann es sich um Endkunden handeln, die ein bestimmtes Produkt oder eine Dienstleistung der Organisation nutzen. Aber auch Mitarbeiter einer Organisation zählen zu den Benutzern. Beispielsweise nutzen Mitarbeiter intern angebotene Dienstleistungen, wie z.  B. IT-Services, um ihre tägliche Arbeit bewältigen zu können. Auch die Nutzer der ­

10  Benutzererfahrung als Wegweiser …

235

­ nternehmensarchitekturdokumentationen, respektive des digitalen Zwillings, sind zu U berücksichtigen. Dabei ist unerheblich, in welcher Rolle die Benutzer auftreten bzw. welche Stelle sie innerhalb oder außerhalb der Organisation innehaben. Feedback ist von allen Benutzern auf allen Ebenen der Unternehmenshierarchie wertvoll. Unternehmensarchitektur, insbesondere der im vorliegenden Buch beschriebene portfolio-orientierte Ansatz, kann dabei unterstützen, dieses wichtige Feedback strukturiert zu sammeln und im Architekturdesign zu berücksichtigen. Zu diesem Zweck müssen die vorgestellten Portfolioansätze (siehe Kap. 4, 5, 6, 7, 8 und 9) um Konzepte zur Integration von Benutzererfahrung geöffnet werden. Es muss die Stimme der Kunden, aber auch jene der Mitarbeiter in den Portfolios und den geplanten Zielarchitekturen reflektiert werden: Voice of the Customer und Voice of the Employee.

10.2 Ansatz zur Analyse der Benutzererfahrung Der im vorliegenden Buch beschriebene portfolio-orientierte Ansatz eignet sich durch seine Einbettung in das ArchiMate®-Framework insbesondere dazu, Nutzerfeedback strukturiert zu sammeln. Über einen fragebogen-basierten Ansatz wird es ermöglicht, direktes Nutzerfeedback einzuholen. Warum via Fragebogen? Fragebögen zählen zu den quantitativen Forschungsmethoden. Sie sind eine probate Technik, um rasch und direkt qualifizierte Informationen von Benutzern zu erheben. Für Beispiele ­fragebogen-basierter Umfragen im Kontext Unternehmensarchitektur siehe Appendix 1. Natürlich ersetzen diese nicht objektive Messmethoden, die es erlauben, die Portfolios um operative Daten anzureichern. Beispiele für diese Techniken werden in Kap. 6, Abschn. 6.4.3 beschrieben. Dort wird zum Beispiel das Applikationsportfolio um Fakten aus operativen Daten zur Qualitätsbewertung angereichert. Anzahl an Störungen, Problemen und SLA-Verletzungen von Applikationskomponenten sind Beispiele dafür. Des Weiteren bieten Fragebögen den Vorteil, Informationen von Nicht-EA-Experten einzuholen indem diese auf einzelne kleine Teilbereiche der Unternehmensarchitektur abzielen. Beispielsweise können diese genutzt werden, um Feedback zu einem oder mehreren Geschäftsservices zu sammeln. Die Kenntnis der Gesamtarchitektur und der architekturellen Zusammenhänge ist für die Beantwortung der Fragen nicht erforderlich. Fragebögen erlauben das subjektive Empfinden der Nutzer zu erfragen. Bei der Gestaltung von Fragebögen kann auf jahrzehntelange Erfahrung aus dem Forschungsgebiet der empirischen Sozialforschung zurückgegriffen werden. Krosnick (2018), Porst (2013) und Raab-Steiner und Benesch (2015) sind nur ein kleiner Ausschnitt hilfreicher Quellen zur fundierten Gestaltung von Fragebögen. Abb. 10.1 gibt einen Überblick über das hier beschriebene Rahmenwerk zur Ermittlung der Benutzererfahrung. Ausgangsbasis für die Konstruktion der Fragebögen ist die Architekturdokumentation, welche im Idealfall in Form der in den vorhergehenden Kapiteln motivierten Portfolios vorliegt. Folgende Kriterien spielen bei der Ausgestaltung von Nutzerbefragungen eine Rolle:

236

W. Utz et al.

Ordnungsrahmen

Informationsbedarf

Ziel Ebene Nutzerrolle Technik

Fragebogen

Anreicherung

Stakeholder

Abb. 10.1   Rahmenwerk für Benutzererfahrungsanalyse im Rahmen der Geschäftstransformation

• Ziel: Die Befragung kann beispielsweise auf Themen wie Qualität, Compliance bzgl. regulatorischer Anforderungen, Strategie- und Zielkonformität oder ­ RisikoManagement abzielen. • Ebene: Auf welche Architekturebene aus dem Spektrum zwischen Strategie und Implementierung zielt die Analyse ab? Welche Architekturelemente stehen im Fokus? • Nutzerrolle: Wer ist die Zielgruppe der Befragung? Welche Rolle haben die Nutzer inne? Beispielsweise können Nutzer in der Rolle des Endkunden adressiert werden. Es wäre aber auch möglich, Nutzer in der Rolle „Mitarbeiter“ oder „CxO“ zu befragen. • Technik: Es gibt unterschiedliche Techniken, die als Orientierungsrahmen für die Analyse und die Erstellung der Fragebögen dienen können. Typische Techniken sind etwa das GAP-Modell zur Servicequalität (vgl. Bruhn und Stauss 2013), Reifegradmodelle wie SPICE (Software Process Improvement and Capability Determination, vgl. Ehsan et al. 2010) zur Ermittlung von Performance-Status, oder Sammlungen an Schlüsselpraktiken, wie beispielsweise jene aus COBIT (vgl. ISACA 2019). In den folgenden Absätzen finden sich beispielhafte Konfigurationen des Analyseansatzes. In jedem der vorgestellten Beispiele sind die Parameter unterschiedlich gesetzt. Beispiel 1: Bewertung des Prozessreifegrades Ein probates Mittel zur Identifikation von Verbesserungspotenzialen in Geschäftsprozessen sind Prozessreifegradmodelle. Beispielhaft sei in diesem Zusammenhang etwa folgende Konfiguration angeführt:

10  Benutzererfahrung als Wegweiser …

237

{Ziel: Prozessverbesserung | Ebene: Geschäftsebene | Nutzer: Prozessbeteiligte | Technik: SPICE}

Ein Prozessreifegradmodell ist ein Werkzeug zur Standort- sowie zur Zielbestimmung bei Geschäftsprozessen. Anhand von standardisierten Kriterien können Schwachstellen in den Prozessen identifiziert und Verbesserungsmaßnahmen abgeleitet werden. Kriterienkataloge finden sich beispielsweise im Excellence-Modell der EFQM (vgl. Bohrer 2012) oder in der Norm „ISO 9004:2008 Qualitätsmanagementsysteme – Leitfaden zur Leistungsverbesserung“. Prozessbeteiligte sind für die Ausführung der in einem Prozess beschriebenen Aufgaben zuständig. Ihr Feedback ist zentral für eine kontinuierliche Verbesserung der Prozessleistung. Das ArchiMate®-Framework sieht Prozesse auf allen Kernebenen vor. So wird zwischen Geschäftsprozessen, Applikationsprozessen und Technologieprozessen unterschieden. Prozessverbesserungsinitiativen gehen allerdings üblicherweise von den Fachbereichen aus und fokussieren somit in der Regel auf Geschäftsprozesse und daher auf die Geschäftsebene des ArchiMate®-Frameworks. Beispiel 2: Bewertung der IT-Sicherheit Bei der Definition und Umsetzung der Sicherheitsanforderungen innerhalb einer Organisation greift eine rein technische Betrachtung zu kurz. Um eine umfassende Informationssicherheit zu gewährleisten, müssen alle Ebenen der Unternehmensarchitektur im Fokus stehen. Dies spiegelt sich in der nachstehenden Konfiguration wider: {Ziel: Sicherheit | Ebene: alle | Nutzer: Mitarbeiter | Technik: SABSA Geschäftsattribute}

Die Sherwood Applied Business Security Architecture oder kurz SABSA (vgl. SABSA, Sherwood et al. 2009) ist ein Rahmenwerk, das auf das Design, die Umsetzung und die Unterstützung von Sicherheitsservices als integralen Bestandteil aller Architekturebenen fokussiert. SABSA liefert mit seinem Konzept der Geschäftsattribute ein Referenzmodell, welches die Ermittlung und Abgrenzung von Sicherheitsanforderungen auf den verschiedenen Ebenen der Unternehmensarchitektur unterstützt. Einen Überblick über die SABSA Geschäftsattribute gibt Abb. 6.4 in Kap. 6. Nimmt man etwa das Attribut „Geschützt“ (engl. Protected) aus der Klasse der Nutzerattribute (engl. User Attributes) als Beispiel, so kann durch die Frage nach regelmäßigen Penetrationstests bewertet werden, ob ausreichend Schutz gegeben ist. Auf die gleiche Art und Weise können aus den übrigen Geschäftsattributen Fragestellungen abgeleitet werden. Somit kann eine einheitliche Bewertung aller Architekturelemente gewährleistet werden. Beispiel 3: Bewertung von Compliance Im Vordergrund steht dabei oftmals die Sicherstellung von Compliance mit gesetzlichen Anforderungen. Eines der prominentesten Beispiele der vergangenen Jahre ist die

238

W. Utz et al.

­ atenschutz-Grundverordnung (DSGVO), welche 2018  in Kraft trat. Die DSGVO regelt D die Verarbeitung personenbezogener Daten durch private Unternehmen und öffentliche Stellen. Sie stellt sicher, dass personenbezogene Daten innerhalb der Europäischen Union geschützt sind. {Ziel: Compliance | Ebene: Applikation (Daten) | Nutzer: Mitarbeiter | Technik: Audit-Fragebogen}

Das Datenportfolio (in ArchiMate® ist dies Teil der Applikationsebene) bildet den idealen Startpunkt zur Identifikation personenbezogener Daten, auf welche sich die Compliance-Anforderungen der DSGVO beziehen. Zur Identifikation der relevanten Daten und Sicherstellung des sachgemäßen Umgangs mit diesen Daten können wiederum Fragebögen genutzt werden. Fragen können etwa sein: • Beinhalten die Datensätze Namen oder Adressen natürlicher Personen? • Beinhalten die Datensätze Nutzerdaten wie beispielsweise IP-Adressen und ­Login-Daten, mit welchen auf natürliche Personen geschlossen werden können? • Werden Fotos oder biometrische Daten von Personen gespeichert? Fragen wie diese unterstützen die Datenschutzbeauftragten dabei, die relevanten Daten zu identifizieren, um diese in weiterer Folge in das geforderte Verzeichnis der Verarbeitungstätigkeiten gem. Art. 30 DSGVO aufzunehmen (siehe auch Kap. 7).

10.3 Benutzerzentriertes Feedback zur Servicequalität Zur besseren Verdeutlichung des Ansatzes zur Benutzererfahrungsanalyse wird im Folgenden eine weitere Konfiguration – im konkreten Fall zur Bewertung der Servicequalität – vorgestellt und im Detail diskutiert. Dabei geht es darum, mögliche Ursachen für eine mangelnde Servicequalität aufzuzeigen. Der Schwerpunkt liegt nicht auf der objektiven Messung der Servicequalität. Vielmehr spielen subjektive Faktoren zur Wahrnehmung der Servicequalität eine Rolle, respektive die Übereinstimmung des vom Nutzer empfundenen Arbeitsergebnisses mit dem anvisierten Nutzen. Mit seinem service-orientierten Ansatz liefert ArchiMate® ein Modell, welches geradezu ideal ist, um Services zu identifizieren und deren Abhängigkeiten zu verstehen. Services können auf allen Ebenen der Architektur angeboten werden. Die nachstehende Konfiguration fokussiert auf die Geschäftsebene: {Ziel: Servicequalität | Ebene: Geschäftsebene (Geschäftsservices) | Nutzer: Endkunde | Technik: GAP-Modell}.

10  Benutzererfahrung als Wegweiser …

239

Nutzer sogenannter Geschäftsservices können Endkunden, aber auch Mitarbeiter sein. ArchiMate® unterscheidet in diesem Zusammenhang zwischen externen und internen Services. Abb. 10.2 zeigt die verschiedenen Arten von Services in ArchiMate® und die typischerweise zugeordneten Nutzerrollen, eingebettet in die drei Kernebenen des ArchiMate®-Frameworks. Obige Konfiguration nutzt das GAP-Modell, eines der prominentesten und am weitesten verbreiteten Modelle zur Evaluierung von Servicequalität (vgl. Haller 2017, S. 40). Neben dem GAP-Modell gibt es aber zahlreiche weitere Modelle, wie etwa das Dienstleistungsqualitätsmodell von Grönroos, das Dynamisches Prozessmodell von Boulding et al., das Beziehungsqualitäts-Modell von Liljander/Strandvik und das Qualitative Zufriedenheitsmodell von Stauss/Neuhaus, die ebenfalls als Technik für die Qualitätsanalyse eingesetzt werden könnten. Für einen Überblick über diese Modelle siehe (Bruhn 2016). Das GAP-Modell wird als Grundmodell des Qualitätsmanagements angesehen (vgl. Haller 2017, S. 40). Es kann trotz seiner ursprünglichen Ausrichtung auf personenbezogene Dienstleistungen (z. B. ärztliche Untersuchung) und Sachdienstleistungen (z. B. Autoreparatur) auch auf IT-Services angewandt werden (vgl. Hochstein et al. 2004;

Externer Geschäftsservice

Kunde Geschäftsebene Interner Geschäftsservice

Externer Anwendungsservice

Mitarbeiter Fachbereich Anwendungsebene Interner Anwendungsservice

Externer Infrastrukturservice

Enwickler bzw. Anwendungsverantwortlicher

Technologieebene Interner Infrastrukturservice

Abb. 10.2   ArchiMates® Servicemodell (in Anlehnung an Jonkers et al. 2011)

Mitarbeiter Betrieb

240

W. Utz et al.

Röder und Keuper 2009). Auch die durch die zunehmende Digitalisierung immer häufiger anzutreffenden Online-Services (z. B. Hotelbuchung über das Internet) werden durch das GAP-Modell abgedeckt. Das Modell kann sowohl auf kundengerichtete Services, aber auch auf unternehmensinterne Nutzer-Dienstleisterbeziehungen angewendet werden (vgl. Frost und Kumar 2000). Ein gutes Beispiel dafür ist das Personalrecruiting. Dieser Service wird oft von der Personalabteilung unternehmensintern für andere Abteilungen angeboten. Die Nutzer des Services können diesen bewerten. Der Service könnte aber auch unternehmensexternen Kunden – respektive Endkunden – angeboten werden. In diesem Fall wäre die Personalabteilung auf Feedback von Endkunden angewiesen. Das GAP-Modell erklärt mögliche Ursachen, die zu einer Abweichung von nutzerseitig erwarteter und tatsächlicher Dienstleistungsqualität führen. Es hilft Faktoren, wie beispielsweise Missverständnisse, Fehleinschätzungen und das Verhalten der am Dienstleistungsprozess beteiligten Personen, zu analysieren. Das Modell zeigt Qualitätslücken (eng. Gaps) auf, durch deren Schließung die Nutzererfahrung erhöht werden kann. Abb. 10.4 gibt einen Überblick über das GAP-Modell und lokalisiert fünf Lücken, die typischerweise im Rahmen der Dienstleistungserbringung auftreten: • Wahrnehmungslücke (Gap 1): Der Dienstleister kennt die Erwartungen der Nutzer nicht bzw. schätzt diese falsch ein. • Entwicklungslücke (Gap 2): Die Nutzererwartungen werden unzureichend in Servicestandards und Maßnahmen umgesetzt. • Leistungslücke (Gap 3): Die Lücke beschreibt den Unterschied von unternehmensinternen Qualitätsstandards und der in der Realität erbrachten Dienstleistung. • Kommunikationslücke (Gap 4): Die Ausführung stimmt nicht mit dem kommunizierten Nutzerversprechen überein. • Kundenlücke (Gap 5): Die Diskrepanz zwischen der erwarteten und der tatsächlich erbrachten Dienstleistung. Die Lücke resultiert aus der Summe aller anderen Lücken. Sie kann nur durch schließen der Lücken 1–4 verringert werden.

Abb. 10.3    Typografische Kunst – Die ersten Emoticons. Bild Emoticons Puck 1881 with Text, Bildanbieter Puck Magazine/Wikimedia Commons, inspiriert durch 100 Diagrams that Changed the World (vgl. Christianson 2012)

10  Benutzererfahrung als Wegweiser …

241

Benutzerzufriedenheit ist wohl eine der wichtigsten Kenngrößen für benutzerzentrierte Services in der Unternehmensarchitektur. Bereits ein Jahrhundert bevor Benutzer begannen Nachrichten mit Emoticons anzureichern, um Emotionen wie Zufriedenheit und Ärger auszudrücken, wurden diese unter der Überschrift „Typografische Kunst“ durch das Satiremagazin Puck vorgestellt (siehe Abb. 10.3). Heute sind diese aus der digitalen Kommunikation nicht mehr wegzudenken ;-).

Mund-zu-MundKommunikation

Individuelle Bedürfnisse

Erfahrungen in der Vergangenheit

Erwartete Dienstleistung GAP 1

GAP 5 Wahrgenommene Dienstleistung

Kunde Dienstleister Dienstleistungserstellung

GAP 4

Kundengerichtete Kommunikation

GAP 3 Umsetzung der wahrgenommenen Kundenerwartungen in Spezifikationen der Dienstleistungsqualität GAP 2 Kundenerwartungen in der Wahrnehmung des Managements

Abb. 10.4   Das GAP-Modell der Servicequalität (vgl. Zeithaml et al. 1988)

242

W. Utz et al.

Um die Qualität der Services mittels dem GAP-Modell bewerten zu können, muss diese aus Nutzersicht gemessen werden. Ein sehr populäres und weltweit etabliertes fragebogen-basiertes Verfahren ist SERVQUAL (vgl. Wang et al. 2015). Es erlaubt die subjektiven Elemente der Servicequalität zu messen. Mithilfe einer Umfrage bewerten Benutzer den erbrachten Service im Vergleich zu ihren Erwartungen. Abb. 10.5 zeigt die Technik im Überblick. Servicequalität wird in Dimensionen wie Zuverlässigkeit und Gewährleistung bewertet, um die wahrgenommene Servicequalität – respektive Gap 5 – zu messen. In der Standardausprägung werden fünf Qualitätsdimensionen adressiert: • Zuverlässigkeit (engl. Reliability): Hierbei geht es um die korrekte und verlässliche Ausführung des Service und die Zuverlässigkeit der Prozesse, die den Service bereitstellen. • Gewährleistung (engl. Assurance): Es werden Attribute, wie Höflichkeit, Kompetenz und sicheres Auftreten der Servicemitarbeiter bewertet. • Sachwerte (engl. Tangibles): In dieser Dimension geht es um die Bewertung von Attributen wie Erscheinungsbild, Räume, Einrichtungen, Gerüche, Materialien, Präsentationsform, Kleidung etc. • Einfühlvermögen (engl. Empathy): Diese Dimension bewertet die emotionale Kompetenz der Servicemitarbeiter und ihre Bereitschaft für individuelle Kundenbetreuung. • Reaktionsfähigkeit (engl. Responsiveness): Diese Dimension behandelt die Fähigkeit und Bereitschaft, schnell und flexibel auf Kundenanfragen und –wünsche zu reagieren.

SERVQUAL Dimensionen Zuverlässigkeit

Gewährleistung

Sachwerte

Einfühlvermögen

Externe Faktoren beeinflussen die Erwartungen

Erwartung (Erwarteter Service) Gap 5 Wahrnehmung (Wahrgenomme ner Service)

Reaktionsfähigkeit

Abb. 10.5   Die SERVQUAL-Technik im Überblick (vgl. Wang et al. 2015)

Wahrgenommene Service Qualität

10  Benutzererfahrung als Wegweiser …

243

Ein SERVQUAL-Fragebogen umfasst Fragenpaare (Doppelskala), die auf die oben genannten Dimensionen aufgeteilt sind. Die erste Frage eines Paares fokussiert jeweils auf die Erwartung des Kunden, während die zweite Frage auf die tatsächlich wahrgenommene Qualität Bezug nimmt. Jede der Fragen wird über eine siebenstufige ­Likert-Skala bewertet. Aus der Differenz zwischen Erwartung (Frage 1) und Erfahrung (Frage 2) wird die Abweichung ermittelt. Aus der Differenz aller Fragenpaarbewertungen einer Dimension wird der Durchschnitt ermittelt. Die Interpretation dieser Durchschnittswerte dient zur Einschätzung der Servicequalität. Führt ein Unternehmen derartige Befragungen zu all seinen Geschäftsservices durch, ist schnell erkennbar, in welchen Bereichen die Qualität verbessert werden sollte. Ausgehend von einem minderbewerteten Service werden all jene Komponenten identifiziert, die zur Realisierung des Services dienen. An diesen muss angesetzt werden, um die Qualität zu verbessern. Der Vorteil von SERVQUAL liegt nicht nur in seiner Branchenunabhängigkeit und der gleichzeitigen einfachen Adaptierbarkeit für die jeweilige Branche, sondern auch in den zahlreichen Abwandlungen, sodass die Technik nicht ausschließlich für ­„Face-to-Face“-Services angewandt werden kann. SERVQUAL kann beispielsweise auch zur Bewertung von OnlineServices oder für technische Services, wie Services der Anwendungs- oder Technologieebene, eingesetzt werden. Beispiele für Adaptierungen, welche die Qualitätsmessungen für IT-Services möglich machen, sind IS-SERVQUAL (vgl. Kettinger und Lee 1994), ITSERVQUAL (Hochstein et al. 2004), E-S-Qual (vgl. Parasuraman et al. 2005), ASP-Qual (vgl. Ma et al. 2005) und SaaS-Qual (vgl. Benlian et al. 2011).

10.4 Bewertung der Dienstleistungsqualität am Beispiel eines Skigebietes Wie in Abb. 10.2 ersichtlich, setzen sich Services oftmals wiederum aus anderen Services zusammen. In dieser Logik lassen sich sogenannte Servicebäume abbilden. Im Wesentlichen handelt es sich dabei um einen umgekehrten Baum, dessen Wurzel oben ist. Auf den oberen Ebenen finden sich Geschäftsservices, die sich wiederum aus Applikations- und Technologieservices zusammensetzen können. Abb. 10.6 zeigt ein konkretes Beispiel im Kontext eines Skigebietes. Das Geschäftsservice „Liftnutzung“ ist ein zentraler Service in jedem Skigebiet. Es besteht aus einer Reihe an Subservices, wie beispielsweise dem eigentlichen „Transportservice“ und dem dafür notwendigen „Autorisierungsservice“. Die Autorisierung erfolgt üblicherweise durch einen Skipass. Fokussiert man auf den „Autorisierungsservice“, so kann dieser aufgrund erster Digitalisierungsmaßnahmen nicht mehr nur ausschließlich über die traditionelle Liftkarte erfolgen. Das Skigebiet bietet darüberhinaus eine App, über welche die Autorisierung erfolgen kann. Die Unternehmensarchitekten im Skigebiet entscheiden auf Basis von Sichten wie jene in Abb. 10.6, welche Services bzw. auf welcher Ebene die Services bewertet

244

W. Utz et al.

Abb. 10.6   Servicebaum – Aufbau von Services

werden. Für die Bewertung der Geschäftsservices wird das GAP-Modell unter Nutzung des SERVQUAL-Fragebogen verwendet. In Tab. 10.1 sind zum besseren Verständnis beispielhafte Fragenpaare aus den Dimensionen Einfühlungsvermögen und Sachwerte aufgelistet. Angenommen aus der SERVQUAL-Befragung geht hervor, dass die Gäste mit dem „Liftservice“ unzufrieden sind. In diesem Fall können die einzelnen Servicekomponenten im Detail analysiert werden. Die Sicht auf die Services kann um Applikations- und im Bedarfsfall um Technologieservices angereichert werden. Durch die Zuordnung der Artefakte aus den Portfolios können die Servicebäume noch weiter detailliert werden. Abb. 10.7 zeigt das Ergebnis einer derartigen Detaillierung. In diese

Tab. 10.1  Typische SERVQUAL-Fragen am Beispiel des Skigebietes Dimension

Erwartung

Einfühlungsvermögen

In einem guten Skigebiet ist Das Liftpersonal ist hilfsbereit das Liftpersonal hilfsbereit und zuvorkommend. und zuvorkommend. 1

2

3

Erfahrung

4

5

6

7

1: Stimme nicht zu 7: Stimme vollkommen zu

Sachwerte

1

2

3

4

5

6

7

1: Stimme nicht zu 7: Stimme vollkommen zu

In einem guten Skigebiet gibt Die Liftanlagen im Skigebiet es moderne Liftanlagen. sind modern. 1

2

3

4

5

1: Stimme nicht zu 7: Stimme vollkommen zu

6

7

1

2

3

4

5

1: Stimme nicht zu 7: Stimme vollkommen zu

6

7

10  Benutzererfahrung als Wegweiser …

245

Abb. 10.7   Zusammensetzung des Service

Sicht wurden Applikations- und Technologieservices sowie die bereitstellende mobile App, das Smartphone und weitere Artefakte aufgenommen. Sollte der Grund für die Unzufriedenheit aus der initialen Befragung zur Servicequalität Liftservice nicht hervorgehen, werden weitere Befragungen auf „tieferen“ Ebenen des Servicebaumes initiiert. Die Architekten könnten entscheiden, eigene Befragungen zum „Mobilen Autorisierungsservice“ vorzunehmen. Auf diese Weise können die Schwachstellen im Detail analysiert werden und in weiterer Folge beispielsweise in Design-Workshops optimiert werden. Ankerpunkt für derartige Optimierungen ist wiederum das Transformationsportfolio (siehe Kap. 4), wo Ideen zur Verbesserung in Form von Anforderungen an die Architektur priorisiert werden.

246

W. Utz et al.

10.5 Fazit Jegliche Form von Benutzererfahrung, seien es Erfahrungen von Endkunden oder von Mitarbeitern, kann für das Design anstehender Geschäftstransformationen wertvollen Input geben. Im vorliegenden Kapitel wurde ein Analyseverfahren für Bewertung der Nutzererfahrung vorgestellt. Dabei handelt es sich um ein parametrisierbares Analyseverfahren zur Evaluierung von Benutzerfeedback auf Basis von Fragebogentechniken. Durch die Integration mit dem im vorliegenden Buch beschriebenen p­ortfolioorientierten Ansatz kann das Feedback zielgerichtet und fokussiert in der Unternehmensarchitektur verankert werden. Der digitale Zwilling kann somit um (subjektive) Einschätzungen der Benutzer angereichert werden. Chancen und Verbesserungspotenziale können zielgerichtet abgeleitet werden. Bewertung und Feedback sind aber nicht ausschließlich für bereits existierende Architekturen von Interesse. Vielmehr sollte Feedback in allen Phasen der Geschäftstransformation eingeholt und bewertet werden. Beispielsweise kann Feedback zu geplanten Services bereits auf Basis von Prototypen oder Architekturdesigns gesammelt werden. So kann nicht nur geprüft werden, ob die Erwartungen und Anforderungen in der Nutzung erfüllt werden, sondern auch ob die Architekturen überhaupt den Anforderungen des internen und externen Marktes standhalten. Bezogen auf die in Kap. 2 motivierten Phasen der Unternehmenstransformation spielt die Erfahrungsanalyse in allen Phasen eine bedeutende Rolle (siehe Abb. 10.8).

Benutzerfeedback und Zufriedenheitsanalysen

Einbinden des Benutzers in den Designprozess

UMSETZEN

Feedback in der Umsetzung Abb. 10.8   Phasen der Geschäftstransformation – Einbindung der Benutzers

10  Benutzererfahrung als Wegweiser …

247

Literatur Benlian, Alexander, Marios Koufaris, und Thomas Hess. 2011. Service quality in ­software-as-a-service: Developing the SaaS-Qual measure and examining its role in usage continuance. Journal of Management Information Systems 28:85–126. Bohrer, Hermann. 2012. Erfolgsfaktor Qualität: Einsatz und Nutzen des ­ EFQM-ExcellenceModells. Symposion Publishing GmbH. Bruhn, Manfred. 2016. Qualitätsmanagement für Dienstleistungen: Handbuch für ein erfolgreiches Qualitätsmanagement. Grundlagen–Konzepte–Methoden. Berlin: Springer. Bruhn, Manfred, und Bernd Stauss. 2013. Dienstleistungsqualität: Konzepte – Methoden – Erfahrungen. Wiesbaden: Springer. Christianson, Scott. 2012. 100 diagrams that changed the world: From the earliest cave paintings to the innovation of the iPod. London: Penguin. Ehsan, N., A. Perwaiz, J. Arif, E. Mirza, und A. Ishaque. 2010. CMMI/SPICE based process improvement, 859–862. IEEE. Frost, Frederick A., und Mukesh Kumar. 2000. INTSERVQUAL–an internal adaptation of the GAP model in a large service organisation. Journal of Services Marketing 14:358–377. Haller, Sabine. 2017. Dienstleistungsmanagement: Grundlagen–Konzepte–Instrumente. Wiesbaden: Springer. Hochstein, Axel, R. Zarnekow, und W. Brenner. 2004. Managing IT service quality as perceived by the customer: The service oriented IT SERVQUAL. ISACA. 2019. COBIT 2019 framework: Governance and management objectives. http://www. isaca.org/COBIT/Pages/COBIT-5-german.aspx. Zugegriffen: 31. Juli 2020. Jonkers, Henk, Erik Proper, Marc M. Lankhorst, Dick A. C. Quartel, und Maria-Eugenia Iacob. 2011. ArchiMate for integrated modelling throughout the architecture development and implementation cycle, 294–301. IEEE. Kettinger, William J., und Choong C. Lee. 1994. Perceived service quality and user satisfaction with the information services function. Decision Sciences 25:737–766. Krosnick, Jon A. 2018. Questionnaire design. In The Palgrave handbook of survey research, Hrsg. David L. Vannette, Jon A. Krosnick, 439–455. Cham: Springer. Ma, Qingxiong, J. Michael Pearson, und Suresh Tadisina. 2005. An exploratory study into factors of service quality for application service providers. Information & Management 42:1067–1080. Parasuraman, Ananthanarayanan, Valarie A. Zeithaml, und Arvind Malhotra. 2005. ES-QUAL: A multiple-item scale for assessing electronic service quality. Journal of Service Research 7:213–233. Porst, Rolf. 2013. Fragebogen: Ein Arbeitsbuch. Wiesbaden: Springer. Raab-Steiner, Elisabeth, und Michael Benesch. 2015. Der Fragebogen. Stuttgart: UTB GmbH. Röder, Stefan, und Frank Keuper. 2009. Qualitätsorientierte Steuerung von S ­ hared-IT-ServiceOrganisationen. In Managed Services: IT-Sourcing der nächsten Generation, Hrsg. Frank Keuper, Bernd Wagner, und Hans-Dieter Wysuwa, 203–236. Wiesbaden: Gabler. Sherwood, John, Andrew Clark, und David Lynas. 2009. SABSA White Paper. https://sabsa.org/ white-paper-requests/. Wang, Ya Lan, L.U.O.R. Tainyi, Pin Luarn, und Lu Hsi Peng. 2015. Contribution and trend to quality research – A literature review of SERVQUAL model from 1998 to 2013. Informatica Economica 19:34–45. Zeithaml, Valarie A., Leonard L. Berry, und Anantharanthan Parasuraman. 1988. Communication and control processes in the delivery of service quality. Journal of Marketing 52:35–48.

Wesentliche Konzepte aus ArchiMate® kurz zusammengefasst

11

Pedram Asadi

Inhaltsverzeichnis 11.1 Motivationsaspekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Strategieebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Geschäftsebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.4 Anwendungsarchitektur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.5 Technologieebene. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.6 Physische Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.7 Implementierung und Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

250 250 250 250 253 253 253 262

Dieses Kapitel gibt einen Überblick über wichtige Elemente der Modellierungssprache ArchiMate®. Der Fokus liegt auf den in den Kapiteln 4–10 beschriebenen ­EA-Szenarien und den darin genutzten Elementen. Gemeinsam bilden sie für die im Buch beschriebenen EA-Szenarien das Rückgrat für den Aufbau eines digitalen Zwillings, der ermöglicht, die Organisation aus verschiedensten Management-Blickwinkeln zu analysieren und zu steuern. Die in den folgenden Tabellen angeführten Beschreibungen zu den Elementen wurden durch die Autoren dieses Buches vom englischen Original (vgl. The Open Group 2019) ins Deutsche übersetzt.

P. Asadi (*)  BOC Products & Services AG, Wien, Österreich E-Mail: [email protected] © Der/die Herausgeber bzw. der/die Autor(en), exklusiv lizenziert durch Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 D. Karagiannis et al. (Hrsg.), Benutzerzentrierte Unternehmensarchitekturen, https://doi.org/10.1007/978-3-658-30537-6_11

249

250

P. Asadi

Neben der Übersetzung finden sich Informationen dazu, wie die Elemente ggfs. für die jeweiligen EA-Szenarien spezialisiert (ausgeprägt) werden bzw. wozu diese als Teil der EA-Szenarien gepflegt werden. Auch finden sich Hinweise auf die EA-Szenarien, in welchem die jeweiligen Elemente genutzt werden.

11.1 Motivationsaspekt Siehe Tab. 11.1.

Botschaft ins All. 1972 hat die NASA eine Pioneer-10-Sonde ins Weltall geschickt mit einer Nachricht an Außerirdische. Die Goldplakette (siehe Abb. 11.1) dient einer ersten Verständigung zwischen Menschen und Aliens. Ob diese die Botschaft verstehen, werden wir wohl nie herausfinden. Um die Sprachbarriere bei der Gestaltung und der Umsetzung von Geschäftstransformationen gering zu halten, orientieren sich die hier beschriebenen EA-Szenarien an ArchiMate®, einen weltweit anerkannten Standard zur Unternehmensmodellierung.

11.2 Strategieebene Siehe Tab. 11.2.

11.3 Geschäftsebene Siehe Tab. 11.3.

11.4 Anwendungsarchitektur Siehe Tab. 11.4.

11  Wesentliche Konzepte aus ArchiMate® kurz zusammengefasst

251

Tab. 11.1   ArchiMate®’s Motivationsebene im Zusammenspiel mit den EA-Szenarien Treiber (Driver) Ein Treiber repräsentiert einen externen oder internen Zustand, der Ziele einer Organisation beeinflusst und die Organisation zur Durchführung der für die Zielerreichung notwendigen organisatorischen Änderungen motiviert (vgl. The Open Group 2019, Abschn. 6.2.2). Beispiele für externe Treiber sind Umweltauflagen, Klimawandel und alternde Gesellschaft. Interne Treiber sind beispielsweise Kundenzufriedenheit und Profitabilität. Treiber werden u. a. für die in Abschn. 4.4.2 beschriebene Umweltanalyse nach PESTLE verwendet. In diesem Kapitel wird vorgeschlagen, externe Treiber nach den typischen PESTLEFaktoren (politisch, wirtschaftlich, sozio-kulturell, technologisch, rechtlich und ökonomisch) zu spezialisieren. Die Spezialisierung eines Treibers als Risiko dient dazu, Risiken zu benennen. Diese werden im EA-Szenario „CompliancePortfolio-Management“ (vgl. Kap. 9) beschrieben. Als Beispiel für ein Risiko wird „Übernahme der Steuerung der Gondelbahn durch Hacker“ genannt. Bewertung (Assessment) Eine Bewertung ist das Ergebnis einer Analyse der Unternehmenssituation in Bezug auf einen Treiber (vgl. The Open Group 2019, Abschn. 6.3.2). Im Rahmen des EA-Szenarios „TransformationsportfolioManagement“ werden Bewertungen genutzt, um strategische Analyseergebnisse darzustellen. Zu diesem Zweck werden Bewertungen entsprechend der typischen Kriterien einer SWOTAnalyse (siehe Abschn. 4.5) spezialisiert: Stärke, Schwäche, Chance und Bedrohung. Als Beispiel für eine Bedrohung wird in Abschn. 4.6 „Kostengünstige Fernreisen als Alternative zum Skiurlaub“ genannt. Ein Beispiel für eine Chance ist der „Ausbau des digitalen Leistungsangebotes“ für die Gäste des Skigebietes Bewertungen dienen in weiterer Folge zur Untermauerung strategischer Entscheidungen in Hinblick auf durchzuführende Transformationsvorhaben. Im EA-Szenario „Compliance-Portfolio-Management“ werden Bewertungen zur Bewertung von Compliance-Anforderungen genutzt (vgl. Kap. 9). Es wird jeweils die Erfüllung einer Compliance-Anforderung in Kontext eines Assets bewertet. Als Beispiel wird die Bewertung der Compliance-Anforderung „Erzwingen sicherer Passwörter“ genannt (vgl. Abschn. 9.6, Abb. 9.7). Diese Anforderung wird in Kontext von Applikationskomponenten wie „Mountain Manager“ und „SnowERP“ bewertet. (Fortsetzung)

252

P. Asadi

Tab. 11.1    (Fortsetzung) Ziel (Goal) Ein Ziel stellt eine Absichtserklärung oder einen gewünschten Endzustand für eine Organisation und ihre Stakeholder dar (vgl. The Open Group 2019, Abschn. 6.3.1). In Kap. 4 werden u. a. folgende Beispiele für ein fiktives Skigebiet entwickelt: höhere Kundenbindung und höhere Auslastung an Wochentagen. Für jedes Transformationsvorhaben und für dessen Ausbaustufen sollten messbare Ziele definiert werden. Dies geschieht im Rahmen des EA-Szenarios „TransformationsportfolioManagement“ (vgl. Kap. 4). Anforderung (Requirement) Eine Anforderung stellt einen Bedarf dar, welcher von der Architektur erfüllt werden muss (vgl. The Open Group 2019, Abschn. 6.3.4). Beispiele sind: Dynamische Preisgestaltung und Etablierung eines Loyalitätsprogramms. Anforderungen werden im EA-Szenario „Transformationsportfolio-Management“ für die Erfassung strategisch relevanter Ideen dokumentiert. Zu diesem Zweck werden die Anforderungen als „Idee“ spezialisiert. Zusätzlich werden Anforderungen in EA-Szenarien wie „Applikationsportfolio-Management“, „DatenportfolioManagement“ und „Technologieportfolio-Management“ genutzt um, Verbesserungspotenziale dieser Portfolios und der darauf aufbauenden Architekturen zu erfassen. Prinzip (Principle) Ein Prinzip stellt eine qualitative Eigenschaft dar, die von der Architektur erfüllt werden sollte (vgl. The Open Group 2019, Abschn. 6.3.3). Beispiele sind „Wiederverwendung bestehender Funktionen“ oder „Vermeidung von Datenredundanz“ (vgl. Abschn. 9.7, Compliance mit Architekturprinzipien). Im EA-Szenario „Compliance-Portfolio-Management“ (vgl. Kap. 9) wird beschrieben, wie die Einhaltung der Architekturprinzipien sichergestellt und geprüft werden kann. (Fortsetzung)

11  Wesentliche Konzepte aus ArchiMate® kurz zusammengefasst

253

Tab. 11.1    (Fortsetzung) Ergebnis (Outcome) Ein Ergebnis repräsentiert ein Endresultat, das erreicht wurde oder erreicht werden soll (vgl. The Open Group 2019, Abschn. 6.3.2). Als Beispiel wird in Kap. 4 die Steigerung der Auslastung um einen bestimmten Prozentsatz genannt. Es wird empfohlen, Ergebnisse soweit möglich in Form von messbaren KPIs (Key Performance Indicators) zu beschreiben. Sowohl Transformationsvorhaben als auch deren Ausbaustufen (Plateaus) müssen messbare Ergebnisse liefern. Im EA-Szenario „Transformationsportfolio-Management“ wird gesondert auf diese Anforderung eingegangen. Stakeholder (Stakeholder) Ein Stakeholder ist die Rolle einer Person, eines Teams oder einer Organisation, die Interessen am Ergebnis der Architektur vertritt (vgl. The Open Group 2019, Abschn. 6.2.1). Beispiele sind CxO, Kunde und die Partner im Ecosystem (wie z. B. Skiverleih und Skischule). Im EA-Szenario „Transformationsportfolio-Management“ werden beispielsweise die Stakeholder als Teil der Roadmaps definiert. Sie haben Interesse an der Umsetzung von Ideen und an der Durchführung der damit verbundenen Transformationsvorhaben .

11.5 Technologieebene Siehe Tab. 11.5.

11.6 Physische Architektur Siehe Tab. 11.6.

11.7 Implementierung und Migration Siehe Tab. 11.7.

254

P. Asadi

Abb. 11.1    Pioneer-Plakette. Bild FFD0J3 PIONEER PLAQUE, 1972, Bildanbieter: Granger Historical Picture Archive/Alamy Stock Foto, inspiriert durch 100 Diagrams that Changed the World (vgl. Christianson 2012)

11  Wesentliche Konzepte aus ArchiMate® kurz zusammengefasst

255

Tab. 11.2  ArchiMate®’s Strategieebene im Zusammenspiel mit den EA-Szenarien Transformationsvorhaben (Course of Action) Ein Transformationsvorhaben ist eine Vorgehensweise oder ein Plan zum Konfigurieren von Fähigkeiten und Ressourcen des Unternehmens, die zur Erreichung eines Ziels unternommen werden (vgl. The Open Group 2019, Abschn. 7.3.2). In Kap. 4 wird beispielsweise das Transformationsvorhaben snowPortal Plus genannt. In diesem soll eine gemeinsame Plattform für alle Stakeholder des Skigebietes etabliert werden. Es bündelt eine Reihe an Ideen und Anforderungen wie dynamische Preisgestaltung und Etablierung eines Loyalitätsprogramms. Transformationsvorhaben sind das wesentliche Element im EA-Szenario „Transformationsportfolio-Management“. Transformationsvorhaben bilden die Klammer für alle Architekturrelevanten Änderungen. Ein Transformationsvorhaben wird jeweils im Rahmen eines ADM-Durchlaufes umgesetzt, in welchem das Vorhaben laufend konkretisiert und in Projekte strukturiert wird. Fähigkeit (Capability) Eine Fähigkeit stellt eine Kompetenz dar, die z. B. eine Organisation, eine Person oder ein System, hat (vgl. The Open Group 2019, Abschn. 7.3.1). Als Beispiele für Fähigkeiten werden u. a. Preisbestimmung, Ticketverkauf, Pistenpräparierung und Liftbetrieb genannt. Ohne diese Fähigkeiten wäre der Betrieb des Skigebietes nicht möglich. Fähigkeiten sind das zentrale Element im EA-Szenario „Capability-Portfolio-Management“. Auf strategischer Ebene werden Fähigkeiten dokumentiert und analysiert. Diese stellen einen zentralen Ankerpunkt für Transformationsvorhaben dar. Ein Transformationsvorhaben wirkt sich auf eine oder mehrere Fähigkeiten aus, indem dieses Fähigkeiten realisiert oder ändert.

256

P. Asadi

Tab. 11.3  ArchiMate®’s Geschäftsebene im Zusammenspiel mit den EA-Szenarien Geschäftsrolle (Business Role) Eine Geschäftsrolle beschreibt die Verantwortung für die Durchführung bestimmter Tätigkeiten eines Akteurs oder die Rolle, die ein Akteur in einer bestimmten Handlung oder einem bestimmten Ereignis spielt (vgl. The Open Group 2019, Abschn. 8.2.2). Beispiele für Geschäftsrollen sind CxO, Sachbearbeiter, Kunde und Kassenpersonal. In allen EA-Szenarien werden Geschäftsrollen dazu verwendet, um ein Bündel an Aufgaben, Befugnissen und Verantwortungen im Kontext des EA-Szenarios zu beschreiben. Geschäftsprozess (Business Process) Ein Geschäftsprozess repräsentiert eine Abfolge von Aktivitäten, die zu einem bestimmten Ergebnis führen, z. B. realisierte Produkte oder Geschäftsservices (vgl. The Open Group 2019, Abschn. 8.3.1). Beispiele (wiederum am Beispiel des Skigebietes) sind Ticket verkaufen, Pisten präparieren und Lift warten Geschäftsprozesse sind ein wesentlicher Teil der Geschäftsarchitektur. Viele Transformationsvorhaben wirken sich direkt auf die Geschäftsprozesse aus, indem diese optimiert oder gänzlich neugestaltet werden. Geschäftsservice (Business Service) Ein Geschäftsservice stellt ein explizit definiertes und von außen zugreifbares Geschäftsverhalten dar (vgl. The Open Group 2019, Abschn. 8.3.5). Ein Beispiel für ein Geschäftsservice ist der Onlinekauf eines Skipasses. Bei Geschäftsservices handelt es sich um Dienstleistungen oder Funktionen, die einem Kunden (sowohl extern als auch intern) bereitgestellt werden. Geschäftsobjekt (Business Object) Ein Geschäftsobjekt repräsentiert ein Konzept, das in einer bestimmten Geschäftsdomäne verwendet wird (vgl. The Open Group 2019, Abschn. 8.4.1). Einfach dargestellt handelt es sich um eine high-level Beschreibung von Daten, die für das Geschäft relevant sind Beispiele für Geschäftsobjekte in einem Skigebiet sind Skipass, Lift und Piste. Insbesondere im EA-Szenario „Datenportfolio-Management“ spielen Geschäftsobjekte eine wesentliche Rolle. Für jedes Datenelement werden Festlegungen zu deren Nutzung, Implementierung, Qualität etc. getroffen und sichergestellt. (Fortsetzung)

11  Wesentliche Konzepte aus ArchiMate® kurz zusammengefasst

257

Tab. 11.3   (Fortsetzung) Geschäftsakteur (Business Actor) Ein Geschäftsakteur ist eine Geschäftsentität, die Verhalten ausführen kann (vgl. The Open Group 2019, Abschn. 8.2.1). Beispiele reichen von konkreten Personen (z. B. Johann Schmidt), über Abteilungen (z. B. Marketing) bis hin zu Organisationen. Auch abstrakte Bezeichnungen wie Kunde oder Lieferant sind gebräuchlich. Repräsentation (Representation) Eine Repräsentation ist die wahrnehmbare Form von Informationen, die von einem Geschäftsobjekt transportiert werden (vgl. The Open Group 2019, Abschn. 8.4.3). Beispiele sind Dokumente unabhängig vom Medium (elektronisch, papierhaft etc.) und unabhängig vom Format (html, ascii, pdf etc.). Im EA-Szenario „Datenportfolio-Management“ werden Repräsentationen für die Modellierung von Dokumenten, Reports, Formularen usw. verwendet. Diese setzen sich aus Geschäftsobjekten zusammensetzen. Ein Spezialfall einer Repräsentation ist ein Vertrag.

258

P. Asadi

Tab. 11.4  ArchiMate®’s Applikationsebene im Zusammenspiel mit den EA-Szenarien Applikationskomponente (Application Component) Eine Applikationskomponente repräsentiert eine Kapselung modularer und austauschbarer Applikationsfunktionalität. Applikationskomponenten kapseln Verhalten und Daten, machen Dienste (Applikationsservices) verfügbar und stellen diese über Schnittstellen zur Verfügung (vgl. The Open Group 2019, Abschn. 9.2.1). In Kap. 6 werden u. a. die folgenden Beispiele genannt: SnowERP; WebShop; Kassensystem. Die Applikationskomponente ist das Hauptelement im EASzenario „Applikationsportfolio-Management“. In der Regel werden physische Instanzen von Applikationskomponenten im Portfolio erfasst und beschrieben. Applikationsschnittstelle (Application Interface) Eine Applikationsschnittstelle repräsentiert einen Zugriffspunkt, an dem Applikationsservices einem Benutzer, einer anderen Applikationskomponente oder einem Knoten zur Verfügung gestellt werden (vgl. The Open Group 2019, Abschn. 9.2.3). In Kap. 6 werden Schnittstellen wie SnowERP-Schnittstelle, WebShop-Schnittstelle und Kassensystem-Schnittstelle genannt. Diese Schnittstellen erlauben es, die gleichnamigen Applikationskomponenten untereinander zu vernetzen. Applikationsschnittstellen werden oftmals genauso wie die Applikationskomponenten im Applikationsportfolio verwaltet. Informationen zu den Schnittstellen werden im Rahmen von Transformationsvorhaben u. a. dazu genutzt, um festzustellen, welche Umsysteme von einer Änderung einer Applikationskomponente betroffen sein können. (Fortsetzung)

11  Wesentliche Konzepte aus ArchiMate® kurz zusammengefasst

259

Tab. 11.4   (Fortsetzung) Applikationsservice (Application Service) Ein Applikationsservice repräsentiert ein explizit definiertes und von außen zugreifbares Applikationsverhalten (vgl. The Open Group 2019, Abschn. 9.3.5). In der Regel handelt es sich dabei um Funktionalität, die von außen (etwa von weiteren Applikationskomponenten) aufgerufen werden kann. Ein Beispiel wäre eine Online-Ticketreservierung, die zwar in der Applikationskomponente „snowERP“ implementiert ist, aber für den Kunden über die Applikationskomponente „Webshop“ zugreifbar ist. Im Applikationsportfolio-Management werden Applikationsservices zur Beschreibung der von einer Applikationskomponente nach außen bereitgestellten Funktionen verwendet. Auf diese Weise kann die erforderliche Funktionalität von der tatsächlichen Implementierung als Applikationskomponente getrennt beschrieben werden. Applikationsservices können u. a. von anderen Applikationsservices oder Geschäftsprozessen genutzt werden. In der ADM werden oftmals zuerst nur die Applikationsservices definiert. Die Applikationskomponenten, die ein Applikationsservice dann letztendlich zur Verfügung stellen, werden spätestens in der ADM-Phase „Chancen und Lösungen“ definiert. Datenobjekt (Data Object) Ein Datenobjekt repräsentiert Daten, die für eine automatisierte Verarbeitung strukturiert sind (vgl. The Open Group 2019, Abschn. 9.4.1). Beispiele sind Skipass, Lift und Piste. Es handelt sich dabei um die Repräsentation der gleichnamigen Geschäftsobjekte auf Implementierungsebene. Im EA-Szenario „Daten-Portfolio-Management“ werden Datenobjekte verwendet, um Geschäftsobjekte auf logischer Ebene zu beschreiben. Geschäftsobjekte können somit in Form von Datenobjekten in unterschiedlichen Applikationskomponenten unterschiedlich implementiert sein. Die Datenobjekte können beispielsweise über unterschiedliche Attribute verfügen.

260

P. Asadi

Tab. 11.5  ArchiMate®’s Technologieebene im Zusammenspiel mit den EA-Szenarien Systemsoftware (System Software) Systemsoftware stellt Software dar, die eine Umgebung zur Speicherung, Ausführung und Nutzung von Software oder Daten, die in der Software implementiert sind, bereitstellt (vgl. The Open Group 2019, Abschn. 10.2.3) Beispiele sind Datenbanksysteme und Betriebssysteme. Im EA-Szenario „Technologieportfolio-Management“ werden alle für das Unternehmen relevanten Technologien erfasst. Elemente des Typs „Systemsoftware“ sind eines der wichtigsten Technologieelemente in diesem Zusammenhang Systemsoftware-Elemente mit Spezialisierung „Kategorie“ werden verwendet, um das Technologieportfolio systematisch zu beschreiben. Sie dienen in diesem Fall als Ordnungsrahmen, um konkrete Systemsoftware-Elemente zu kategorisieren. Systemsoftware-Elemente mit Spezialisierung „Typ“ sind dann Ausprägungen (im Sinne konkreter Technologieprodukte in einer bestimmten Version). Gerät (Device) Ein Gerät ist eine physische IT-Ressource, auf der Systemsoftware und Artefakte gespeichert oder zur Ausführung bereitgestellt werden können (vgl. The Open Group 2019, Abschn. 10.2.2). Beispiele sind: Blade System 1, IBM System z Mainframe. Im EA-Szenario Technologieportfolio-Management wird die Spezialisierung „Kategorie“ verwendet, um Elemente des Typs Gerät systematisch zu beschreiben. Sie dienen in diesem Fall als Ordnungsrahmen, um konkrete Geräte zu kategorisieren Geräte mit Spezialisierung „Typ“ sind dann Ausprägungen (im Sinne von Hardwareprodukten in einer bestimmten Version). Knoten (Node) Ein Knoten stellt eine rechnerische oder physische Ressource dar, die andere rechnerische oder physische Ressourcen hostet, manipuliert oder mit ihnen interagiert (vgl. The Open Group 2019, Abschn. 10.2.1). In ArchiMate® angeführte Beispiele sind Datenzentrum-Netzwerkweiche, virtueller Angebots-Host, virtueller BeschaffungsHost. Im Technologieportfolio-Management kann der Knoten verwendet werden, um eine Referenzarchitektur bestehend aus verschiedenen Typen von Technologien zu beschreiben.

11  Wesentliche Konzepte aus ArchiMate® kurz zusammengefasst

261

Tab. 11.6  ArchiMate®’s Physische Ebene im Zusammenspiel mit den EA-Szenarien Equipment (Equipment) Ein Equipment stellt eine oder mehrere physische Maschinen, Werkzeuge oder Instrumente dar, die Materialien erstellen, verwenden, speichern, verschieben oder transformieren können (vgl. The Open Group 2019, Abschn. 11.2.1). Beispiele sind Pistenraupe oder Beschneiungsanlage. Genauso wie Systemsoftware-Elemente und Geräte werden auch Equipments im Technologieportfolio verwaltet. Durch die Spezialisierung als „Kategorie“ werden diese verwendet, um konkretes Equipment zu kategorisieren. Sie dienen dann als Ordnungsrahmen für Equipment mit der Spezialisierung „Typ“. Anlage (Facility) Eine Anlage repräsentiert eine physische Struktur oder Umgebung (vgl. The Open Group 2019, Abschn. 11.2.2). Beispiele im Skigebiet sind Talstation, Bergstation oder Skilift. Anlagen werden u. a. im EA-Szenario „TechnologieportfolioManagement“ verwendet, um den Standort von Equipment zu beschreiben. Als Beispiel können Sensoren (Equipment) genannt werden, die etwa in einer Anlage (z. B. Skilift) verbaut sind.

Tab. 11.7  ArchiMate®’s Implementierungs- und Migrationsebene im Zusammenspiel mit den EA-Szenarien Arbeitspaket (Work Package) Ein Arbeitspaket stellt eine Reihe definierter Aktionen dar, die innerhalb bestimmter Zeit- und Ressourcenbeschränkungen abgearbeitet werden müssen, um bestimmte Ergebnisse zu erzielen (vgl. The Open Group 2019, Abschn. 13.2.1). Arbeitspakete werden verwendet, um Projekte abzubilden. Im EA-Szenario „Transformationsportfolio-Management“ (vgl. Kap. 4) werden diese definiert, um die Transformationsvorhaben im Sinne des Ressourcenbedarfs besser einschätzen zu können. Plateau (Plateau) Ein Plateau repräsentiert einen relativ stabilen Zustand der Architektur, der innerhalb eines begrenzten Zeitraumes besteht (vgl. The Open Group 2019, Abschn. 13.2.4). Im EA-Szenario „Transformationsportfolio-Management“ werden Plateaus zur Repräsentation von Ausbaustufen verwendet. Jede dieser Ausbaustufen stellt eine Zwischenarchitektur – in TOGAF® auch als Transitionsarchitektur (vgl. The Open Group 2018, Phase F, Kap. 13) bezeichnet – dar.

262

P. Asadi

Literatur Christianson, Scott. 2012. 100 diagrams that changed the world: From the earliest cave paintings to the innovation of the iPod. London: Penguin. The Open Group. 2018. The Open Group Architecture Framework TOGAF® Version 9.2. https:// pubs.opengroup.org/architecture/togaf9-doc/arch/. Zugegriffen: 27. Juli 2020. The Open Group. 2019. ArchiMate 3.1 Specification.

Appendix: Ein online verfügbares, benutzerzentriertes Assessment-Service für Unternehmensarchitekturen

Open EA User-Centric Assessment Service Möchten Sie den Wertbeitrag Ihrer Unternehmensarchitektur erhöhen? Der Open EA User-Centric Assessment Service liefert die Bewertungen Ihrer Architekturen aus dem Blickwinkel der Benutzer. CIOs nutzen direktes Nutzerfeedback, um tiefergehende Einblicke in ihre Architekturen zu gewinnen. Durch kontinuierliche Assessments werden Trends und Entwicklungen transparent.

© Der/die Herausgeber bzw. der/die Autor(en), exklusiv lizenziert durch Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 D. Karagiannis et al. (Hrsg.), Benutzerzentrierte Unternehmensarchitekturen, https://doi.org/10.1007/978-3-658-30537-6

263

264

Appendix: Ein online verfügbares, benutzerzentriertes Assessment-Service …

Die Analyse findet auf  allen Ebenen der Architektur statt.  Endbenutzer geben Feedback zu Produkten. Nutzer aus den Fachbereichen geben Feedback zu Applikationen. Entwickler geben Feedback zu den eingesetzten Technologie- und Entwicklungsplattformen. Einzelne Elemente aber auch gesamte Architekturdesigns werden bewertet. Möglich wird dies durch eine intelligente Verknüpfung Ihrer Achitekturinformationen mit adaptiven Umfragetechniken.

Open EA User-Centric Assessment Service Do you want to increase the value contribution of your enterprise architecture? The Open EA User-Centric Assessment Service delivers insights from the user’s perspective. CIOs take actions based on deep architectural insights gained from direct user feedback. Continuous assessments make trends and change more transparent.

Appendix: Ein online verfügbares, benutzerzentriertes Assessment-Service …

265

Analysis happens at all levels of architecture.  End-users give feedback on products. Business users provide input on the applications they use. Developers give feedback on technologies, development tools and deployment platforms. Individual elements, as well as entire solution designs, are evaluated. All this, made possible by intelligently linking your architectural information to the users with adaptive survey techniques.