Digitale Transformation durch Enterprise Architecture sichern

August-Wilhelm Scheer, Scheer Holding

(Titelbild: AdobeStock | 54029384 | yewkeo)

Der Nutzen neuer digitaler Geschäftsmodelle zeigt sich hauptsächlich in der Top-Line, also im Umsatzwachstum eines Unternehmens. Bei bestehenden Geschäftsmodellen führt die Transformation ihrer Prozesse in eine neue digitale Technologie dagegen mehr zur Kostensenkung in der Bottom-Line. Beide Effekte müssen bei Transfor-mationsprojekten beachtet und transparent gesteuert werden. Bei dieser Transfor-mationsaufgabe stehen die Unternehmen einer komplexen Situation aus technischen Möglichkeiten, Marktentwicklungen und ihrer gewachsenen Ausgangssituation gegenüber. Einige Herausforderungen sind:

• Entstehung neuer disruptiver digitaler Geschäftsmodelle
• Cloudcomputing
• Best-of-Breed- oder Best-of-Suite-Entscheidungen bei Unternehmenssoftware
• Arbeitsplatzautomatisierung durch Robotic Process Automation
• Automatisierung der Supply Chain (Industrie 4.0)
• Low-Code-Softwareentwicklung
• Neue Arbeitsmodelle durch home working
• Neue Techniken wie KI, Blockchain
• Modellgestützte Softwareeinführung
• Steuerung komplexer Projekte
• Knappheit von Fachkräften
• Globalisierung und Lieferkettenprobleme
• Klimaschutz und demografischer Wandel

Diese Herausforderungen treffen in Unternehmen auf eine häufig über Jahrzehnte gewachsene IT-Landschaft aus heterogener Hard- und Software. Es fehlen Übersicht und Dokumentationen. An eigene in Programmiersprachen wie COBOL entwickelte Altsysteme traut man sich bei Änderungswünschen nicht mehr heran.

Damit die bei der Transformation neu entwickelten Systeme nicht auch diesen Weg gehen, ist eine klare Strukturierung und Dokumentation der Geschäftsmodelle, -prozesse und Systeme erforderlich. Gleichzeitig muss die bestehende Landschaft soweit nachdokumentiert werden, dass die Schnittstellen zwischen bleibenden Alt- und Neusystemen definiert werden können. Nur so kann die Transformation gelingen und Voraussetzung für eine agile Weiterentwicklung sein. Dieser Beitrag zeigt dazu Konzepte und Methoden auf.

Geschäftsmodelle beschreiben, durch welche Produkte, Ressourcen und Prozesse sowie auf welchen Märkten ein Unternehmen seinen Umsatz und Gewinn erwirtschaftet. Die Digitalisierung verdeutlicht den Wandel von der Betrachtung des Angebots der Funktionen eines Produktes durch den Hersteller hin zu der Erfahrung (experience) des Benutzers mit dem Produkt. Dies ist der Wandel von einer„Inside-out“ zu einer „Outside-in“ Betrachtung. Ein bekanntes Beispiel zeigt, wie die Digitalisierung das Benutzerverhalten völlig verändern kann und zu dramatischen Verwerfungen bei Anbietern im Markt führt (Abbildung 1).

Der Prozess des analogen Fotografierens mit seinen Unterbrechungen, hohem Zeitverbrauch und mehreren beteiligten Partnern wird beim digitalen Fotografieren mit einem Smartphone in einem Zeitpunkt zusammengeschmolzen. Obwohl bei beiden Prozessen das Produkt, also das Foto, ähnlich ist, ist die Benutzerexperience völlig unterschiedlich. Die analoge Fotografie ist heute bis auf eine Spezialistenszene verschwunden.

Auf der Outside-in Betrachtung bauen viele erfolgreiche neu gegründete digitale Unternehmen wie Airbnb und Uber auf. Wenn ein Kunde lediglich an einer preis-günstigen Übernachtungsmöglichkeit interessiert ist, genügt ihm ein digital vermitteltes Privatzimmer, und er braucht kein Hotel mit vielen für ihn überflüssigen Dienst-leistungen. Wer nur preisgünstig von A nach B gelangen möchte, dem genügt ein digital vermitteltes privates Auto mit Fahrer. Kern dieser Geschäftsmodelle sind die dazugehörigen digitalen Vermittlungsprozesse. Neue digitale Prozesse können aber auch nur bestehende Geschäftsmodelle ersetzen oder ergänzen. So haben Taxi-unternehmen inzwischen ihre analogen Vermittlungsfunktionen durch digitale – ähnlich wie bei Uber – ersetzt. Diese Überlegungen gelten nicht nur für die Beziehungen eines Unternehmens zu seinen Kunden, sondern für weitere externe Stakeholder wie Lieferanten, Geschäftspartner oder Mitarbeiter. Auf die sich ändernden Bedürfnisse der experience muss ein Unternehmen aktuell und schnell reagieren. Kunden müssen durch ad-hoc-Marketingaktionen neue Produkte angeboten werden, Lieferanten müssen zu Angeboten für Aktionen aufgefordert und ausgewählt werden, Hochschul-absolventen mit Motivationsaktionen zu Bewerbungen animiert oder Partner zu neuen Geschäftsideen und Logistikketten zusammengeführt werden.

Immer häufiger sind in derartigen Anwendungen Verfahren der KI eingebettet, um zum Beispiel bei Marketing- und Vertriebsanwendungen mittels Datenanalysen auf individuelle Eigenschaften der Kunden einzugehen. Diese Anwendungen haben gemeinsam, dass sie für spezielle Zwecke auch kurzfristig entwickelt werden und sich schnell neuen Situationen anpassen müssen.

Im Gegensatz zu ihnen stehen die Backend-Anwendungen der administrativen Geschäftsprozesse wie Finanzen, operativer Einkauf und Vertrieb, Logistik oder Personal, die durch Standardsoftware der ERP abgedeckt sind und nur eine geringe Änderungsfrequenz haben. Die beiden Ansätze können mit den Begriffen „build to change“ und „build to last“ gekennzeichnet werden. Typisch ist, dass sich die neuen Prozesse an den Rändern des Unternehmens zu seinen externen Partnern befinden, während die dauerhaften Anwendungen mehr die internen Backend Prozesse betreffen. So ist die Auswahl neuer Lieferanten nach Preis, Qualität, Zuverlässigkeit und Wechselkurs ein sich ständig ändernder agiler Prozess, während die täglichen administrativen Bestellvorgänge eine Routinefunktion sind.

Abbildung 2 skizziert die Architektur des Konzeptes. Die neuen digitalen Prozesse zu den außenstehenden Stakeholdern müssen über eine Integrationsebene mit den Backend-Systemen verbunden werden. Bei den agilen Anwendungen stehen die Fachkenntnisse im Vordergrund und werden deshalb auch in den Fachabteilungen entwickelt. Dazu benötigen die inhaltlichen Entwickler aus den Fachabteilungen eine einfach zu handhabende Beschreibungssprache, also eine Methode zur Prozess-modellierung.

Dazu hat der Verfasser Anfang der 1990er Jahre das ARIS-Konzept entwickelt und mit dem Softwaresystem ARIS Toolset der IDS Scheer AG unter Leitung von Wolfram Jost zu einem internationalen Erfolg geführt. Im Zentrum steht die Methode EPK zur Prozessmodellierung, die in einfacher Form einen Geschäftsprozess durch die Reihenfolge von Funktionen, Ereignissen und logischen Verzweigungen beschreibt. Ein Prozessmodell bildet dabei die insgesamt sinnvollen Wege eines Prozesstyps ab.
Inzwischen werden von Software- und Beratungsunternehmen einschließlich der Scheer GmbH vorgefertigte Prozessmodelle für verschiedene Branchen als Referenzen angeboten. Mit dem SPR (Scheer Performance Ready) der Scheer GmbH steht z.B. eine Bibliothek von Branchenmodellen zur Verfügung, die auch auf die Inhalte der SAP-Software ausgerichtet ist und den Kunden bei dem Entwurf seines individuellen Modells unterstützt (vgl. Abbildung 3).

Für 14 Branchen bestehen so Best-Practice-Lösungen für über 5000 Geschäfts-prozesse. Sie werden von Übersichtskacheln schrittweise zu detaillierten Prozess-modellen verfeinert. In ihnen spiegelt sich das Erfahrungswissen aus vielen Kundenprojekten, insbesondere im Zuge von SAP-Implementierungen, wider. Auf Basis eines Referenzmodells wird dann ein kundenspezifisches Modell entwickelt. In den letzten Jahren hat sich für die Prozessmodellierung mit der Sprache BPMN ein weiterer Standard durchgesetzt, der auch den technischen Übergang zur Softwareimple-mentierung unterstützt. Die EPK-Modelle der Fachebene können dazu in die BPMN Notation überführt werden. Die SAP AG hat mit der Übernahme des Softwarehauses SIGNAVIO und ihres RISE Programms ein starkes Bekenntnis zu einem modellgestützten Geschäftsprozessmanagement gegeben. Dieses wird das modellgestützte Vorgehen weiter verstärken.

Die einzelnen Geschäftsprozessmodelle führen gleichzeitig zu einer besseren Trans-parenz und einem besseren Verständnis der einzelnen Prozesse, bilden aber in ihrer Summe für ein Unternehmen selbst ein komplexes Gebilde und verlangen nach einem ordnenden Rahmenkonzept. Dieses wird als Enterprise Architecture (EA) bezeichnet.

EA-Konzepte werden seit rund vier Jahrzehnten entwickelt und eingesetzt. Sie dienen dazu, die Komplexität eines Unternehmens durch Strukturierung leichter verständlich und beherrschbar zu machen. Unter Architektur werden dabei zum einen die grund-legenden Prinzipien verstanden, nach denen die Strukturierung erfolgen soll. Diese werden Rahmenwerke genannt. Zum anderen wird auch das Ergebnis eines Archi-tekturentwurfs verkürzt als Architektur bezeichnet. Eine Enterprise Architecture beschreibt damit vereinfacht den Zusammenhang zwischen den einzelnen Objekten und Prozessen eines Unternehmens.

Über diese Zusammenhänge einen transparenten Überblick zu haben, ist gerade in einer Zeit mit großen Transformationsprojekten besonders wichtig. Viele Unternehmen haben kein genaues Wissen über ihre Informationssysteme, die über einen längeren Zeitraum hinweg entstanden sind. Zudem kennen sie den Markt neu verfügbarer Lösungen nicht gut genug oder können nicht beurteilen, wie und mit welchem Aufwand sie in die bestehende Landschaft eingeführt werden können. Deshalb weckt der Plan, für einen bestimmten Bereich ein Transformationsprojekt zu starten, häufig eher Ängste als Begeisterung. Mit einem EA-System können diese Ängste reduziert werden, indem Fragen folgender Art beantwortet werden, die zu einem besseren Verständnis und besserer Transparenz führen:

„Welche Organisationseinheiten arbeiten an einem bestimmten Geschäftsprozess? In welchen Geschäftsprozessen ist eine bestimmte Funktion enthalten? Welche Daten werden für die Bearbeitung einer Funktion benötigt? Auf welchen Servern ist ein bestimmtes Datenelement gespeichert? Welche Anwendungssysteme unterstützen einen bestimmten Geschäftsprozess? Welche Organisationseinheiten sind an einem bestimmten Geschäftsprozess beteiligt? Welche Prozesse werden für ein bestimmtes Produkt benötigt? usw.“ Die Beantwortung dieser Fragen hilft, ein erfolgreiches Transformationsprojekt zu identifizieren, zu planen und zu implementieren.

Von J. Zachman wurde bereits 1987 ein EA-Konzept vorgestellt, das heute immer noch als Vergleichsreferenz für andere Ansätze herangezogen wird. Zachman gliedert sein Rahmenkonzept nach dem Informationsbedarf der Benutzertypen und der Art der benötigten Information.

Unabhängig von Zachman wurde 1991 von dem Verfasser das ARIS-Konzept veröffentlicht (vgl. das ARIS-Haus in Abbildung 4), das hier als Grundlage gewählt wird.
Eine erste Strukturierung wird im ARIS-Konzept durch die Aufteilung der Beschreibung in fünf unterschiedliche Sichten: Organisation, Funktionen, Daten und Leistung (als Ergebnis einer Funktionsbearbeitung) erreicht. Die Verbindungen zwischen den Sichten, (zum Beispiel: Welche Daten werden von einer Funktion benötigt?) wird durch die Prozesssicht hergestellt. Die ersten vier Sichten können zunächst unabhängig voneinander beschrieben werden und vereinfachen damit die Architektur. Das Ebenen-konzept vom Fachkonzept über IT-Design bis hin zur technischen Implementierung ist eine weitere Strukturierung, wobei auch hier die Verbindungen zwischen den Ebenen erfasst werden. Somit kann zum Beispiel die Frage beantwortet werden, welche Anwendungsmodule in welchem Release der Implementierung eine bestimmte betriebswirtschaftliche Funktion unterstützen.

Den Sichten des Rahmenkonzeptes werden bei ARIS jeweils Modellierungsmethoden zu ihrer Beschreibung zugeordnet. Obwohl das ARIS-Konzept, wie die Langfassung „Architektur integrierter Geschäftsprozesse“ bereits bezeichnet, für die Strukturierung von IT-Landschaften entwickelt wurde, erfüllt es die Anforderungen eines EA-Ansatzes und wird auch in der Fachliteratur entsprechend eingeordnet und von vielen Unternehmen eingesetzt.[1]

Die Betonung der Verbindung zur Informationstechnik ist dadurch begründet, dass diese durch ihre Vielfalt von Hard- und Software selbst ein komplexes System bildet, das nach Beherrschung durch Strukturierung verlangt. Gerade neue Entwicklungen der IT wie Cloud-Computing erhöhen die Komplexität und erfordern eine größere Transparenz der Struktur und Arbeitsweise eines Unternehmens. Unternehmensweite Anwendungssysteme (ERP) bilden ein reales Unternehmen aus der Sicht der Informationsverarbeitung ab. Das IT-System eines Unternehmens ist damit ein abstraktes digitales Abbild des Unternehmens aus der Informationssicht. Allerdings ist dieses System weitgehend ungeordnet. Das Enterprise Architecture-Konzept sorgt deshalb für Struktur und ergänzt das System um weitere Merkmale wie: Zielhierarchie des Unternehmens, Motivationsstruktur usw.

Dabei stehen in der Regel je nach Projektfokus bei praktischen Anwendungen unter-schiedliche Sichten im Vordergrund. Selbst wenn nicht ausdrücklich ein kompletter EA-Ansatz verfolgt wird, schwingt dessen Denkweise in den Projekten mit.

Inzwischen zählen neuere Veröffentlichungen zu EA mehr als 100 Rahmenwerke auf, die sich in Sachen Sichtenbildung, inhaltlicher Ausrichtung und Werkzeugverfügbarkeit nur geringfügig unterscheiden. Es gibt spezielle Konzepte von öffentlichen Institutionen, Militär, IT-Unternehmen und wissenschaftlichen Institutionen. Alle verfolgen aber den gleichen Zweck, die Komplexität des Beschreibungsobjektes „Enterprise“ besser beherrschen zu können, Beschreibungsmethoden zu standardisieren, die Kommunikation zwischen den Stakeholdern zu verbessern, das Datenmanagement und die Integration zu unterstützen und Unternehmensentscheidungen allgemein eine bessere Grundlage zu geben.

Das ARIS-Konzept ist wegen seiner weiten Verbreitung, vieler eingeflossener Erfahrungen und verfügbarer Inhalte durch Referenzmodelle, Methodenangebot und Werkzeugunterstützung ein effektiver Ansatz.

Zusammengefasst besteht ein EA-Konzept aus einem Rahmenkonzept wie dem ARIS-Haus, das die grundsätzlichen Bauelemente und ihre Beziehungen beschreibt. Den Beschreibungssichten werden Beschreibungsmethoden zugeordnet. Die dabei verwendeten Konstrukte bilden das Datenmodell des Repositories. Dessen Ausprägungen bilden dann das Datenmodell eines konkreten EA für ein Unternehmen. Zum Management des EA gehört weiter ein Werkzeug zum Anlegen der Modelle sowie deren Pflege und Auswertung.

Manche Unternehmen fürchten den vermeintlich hohen Aufwand zur Einführung eines kompletten EA-Systems. Dieser besteht zum einen in der Erstellung des Gesamt-modells und zum anderen in seiner dauerhaften Pflege. Die Nutzen einer hohen Transparenz des Unternehmens, einer einheitlichen Sprachregelung und einer gut dokumentierten Ausgangslösung für geplante Unternehmensveränderungen wiegen nach der Meinung von Kritikern diesen Aufwand nicht auf. Die Transparenz würde nicht ständig gefordert, sondern eher fallweise für bestimmte Unternehmensentscheidungen wie Reorganisation oder Unternehmenszusammenschlüsse benötigt. Auch wären bei kleineren Reorganisationen eher Ausschnitte erforderlich, für die sich der Aufwand für ein Gesamtmodell nicht lohnen würde. Diesen Argumenten kann durch eine stärkere Automatisierung von Erstellung und Pflege des EA-Ansatzes begegnet werden. Hierzu gibt es mehrere Ansatzpunkte. Ziel ist eine nahezu automatische Entwicklung und Pflege einer Enterprise Architecture.

Bei einer modellgestützten Einführung eines neuen Geschäftsprozesses ist bereits eine Teillösung für eine EA erhalten. In dem Projekt werden Prozess-, Daten- und Anwendungsmodelle entwickelt oder von dem Berater oder Softwareanbieter mitgeliefert, die bereits ein Teil eines EA-Modells sein können. Auch werden sie, wie bei dem SPR-Ansatz, bereits über mehrere Ebenen von der fachlichen Sicht bis zur Imple-mentierung geführt. Die mit Hilfe des Scheer PAS-Systems entwickelten neuen Anwendungen werden von Modellierungskonzepten unterstützt und dokumentieren sich damit automatisch in einer EA-gerechten Form. Diese Ansätze folgen einem Top-Down-Ansatz, sie führen schrittweise vom Entwurf des Fachkonzeptes bis hin zur IT-Imple-mentierung.

Ein weiterer Ansatz zur Automatisierung des EA-Systems folgt einem Bottom-up-Ansatz. Dieser geht von der Ausführung der Geschäftsprozesse aus. Die dort eingesetzten Anwendungssysteme speichern Daten über die ausgeführten Transaktionen wie deren Start und Ende in sogenannten Logdateien. Die Transaktionen entsprechen betriebs-wirtschaftlichen Funktionen. Aus den Zeitdaten können Vorgänger- und Nachfolge-beziehungen der Funktionen durch Algorithmen erkannt werden, kurz, es können auf der Ebene der einzelnen ausgeführten Prozessinstanzen Prozessmodelle automatisch erstellt werden. Insgesamt wird dieses Vorgehen als Process Mining bezeichnet. Aus den für einen Zeitraum gespeicherten Instanzenmodellen können dann pro Prozesstyp wie Kundenauftragsbearbeitung oder Einkauf automatisch die Prozessmodelle auf der Typ-Ebene erstellt werden, die alle in dem Zeitraum angefallenen Prozesswege enthalten. Im Gegensatz zu den Top-down aufgestellten Prozessmodellen, die den gewünschten Ablauf eines Prozesstyps darstellen, bildet das durch Mining gewonnene Modell die realen Abläufe ab. Durch den Vergleich der Modelle können organische Verbesserungsvorschläge abgeleitet werden.

Für das EA ist interessant, dass es auch ohne Prozessmodellierung des Top-Down-Ansatzes möglich ist, Bottom-up Prozessmodelle automatisch zu erstellen. Damit stehen sowohl Modelle aus der Top-Down-Projektarbeit als auch aus dem Prozess Mining zur Verfügung.

Leider werden diese Modelle aber nach Beendigung des Projektes bisher nicht oder kaum in ein EA systematisch eingestellt und aktualisiert. Sie dienen nach Abschluss eines Einführungsprojektes der Projektdokumentation oder beim Mining einer kurz-fristigen Prozessanalyse. Würden sie dagegen für ein EA-Konzept genutzt werden, könnten die Modelle ohne großen Aufwand längerfristig verwendet werden. Durch die Nutzung von ohnehin angefallenen Modellen kann der Betrieb eines EA erheblich automatisiert werden.

Bei dem bisher beschriebenen EA-Konzept werden manuell oder automatisch erstellte Modelle erfasst, also Ergebnisse von Modellierungsarbeiten oder des Process Minings. Die Entstehungsgeschichte dieser Modelle durch Handlungen, Entscheidungen und Verantwortlichkeiten wird dagegen nicht dokumentiert. Nachträgliche Fragen über Verantwortlichkeiten bei Änderungen oder Entscheidungen im Projektablauf sind deshalb nur schwer festzustellen. Fragen wie „Wurde eine bestimmte Schulung für ein konkretes Thema rechtzeitig zu einem bestimmten Projektzustand durchgeführt?“ oder „Wer hat bereits welche Schulung über den aktuellen Projektstand erhalten?“ oder „Wer hat wann welche Modellierungsschritte ausgeführt?“ sind kaum zu beantworten. Es fehlen systemübergreifende Verbindungen. Fast alle Angaben beziehen sich darüber hinaus auf die Vergangenheit. Kurz, es fehlt an Transparenz über den Projektablauf, Projektstand und die Projektzukunft.

Digitale Projektplanungswerkzeuge bilden Teilaspekte wie die Termin-, Kapazitäts- und Kostenplanung in einer eigenen Systemumgebung ab. Modellierungswerkzeuge zur Prozessgestaltung besitzen ebenfalls eine eigene Datenhaltung. Auch die System-dokumentationen und Schulungsdokumente der Softwareanbieter sind individuell organisiert. Alle Dokumentationen sind in der Regel unterschiedlich und lückenhaft. Kurz, es entsteht ein großes Bündel aus internen und externen Papier- und digitalen Dokumenten, die von unterschiedlichen Akteuren in unterschiedlicher Organisations-form erstellt und mehr oder weniger systematisch mit hohem Aufwand verwaltet werden.
Es liegt deshalb nahe, den traditionellen Projektplanungsansatz auszuweiten und die genannten Dokumente laufend und systematisch in einem geschlossenen System zu erfassen und zu verwalten. Hierzu haben Unternehmen der Scheer Group das System Digital Consulting (DC) entwickelt, das zunächst für eine bessere Projektsteuerung eingesetzt wird, aber auch der Dynamisierung des EA-Konzepts dient. Es wird damit wieder das Ziel verfolgt, ohnehin anfallende Informationen für das EA zu verwerten. An der Entwicklung des DC arbeiten Mitarbeiter aus den Unternehmen Scheer GmbH, Scheer PAS GmbH, imc AG und AWSi gGmbH zusammen. Das System (vgl. Abbildung 5) stellt den Zugriff auf alle während der Projektarbeit anfallenden Informationen in digitaler Form transparent bereit.

Während der Arbeit an einem Transformationsprojekt werden zum Beispiel mit Modellierungswerkzeugen Prozessmodelle erstellt, mit Customizing-Software Anwendungssoftware implementiert, mit Projektsteuerungssoftware Projektpläne definiert sowie mit E-Learning-Systemen Schulungen durchgeführt. Die von diesen Werkzeugen erfassten und bereitgestellten Daten werden in ihren jeweiligen Dateien erfasst. Von dem System DC werden zusätzlich der Ablauf der Projektarbeit und die Verantwortlichkeiten der Akteure für die einzelnen Arbeitsschritte digital dokumentiert. Es enthält dabei nicht die Daten der verwendeten Werkzeuge, sondern verweist über Events auf die Daten der einzelnen Systeme. Kern des Systems ist deshalb die Event Database, in der alle Ereignisse der Projektarbeit weitgehend automatisch aus den benutzten Werkzeugen der Projektmitarbeiter erfasst werden. Beteiligte Mitarbeiter sind externe Berater, Software- und Hardware-Lieferanten sowie die Projektmitarbeiter des Kunden. Sie bilden die Arbeitsebene mit ihren unterschiedlichen digitalen Werkzeugen wie Modellierungssoftware, Projektplanungssoftware oder ERP-Systemen.

Diese Systeme erzeugen Ereignisse (Events) wie zum Beispiel den Beginn des Customizings einer bestimmten Funktion einer Standard Software, Verwendung eines Prozess Referenzmodells, Anlegen eines Prozessmodells, Durchführung einer Schulungsmaßnahme, Abschluss eines Vorgangs in einem Projektsteuerungssystems oder Anlegen einer neuen Dokumentationsdatei. Ein Event umfasst im Wesentlichen die Art des Ereignisses, einen Zeitstempel sowie den Urheber des Events und verweist auf die Daten der Herkunftssysteme. Durch Verfolgung der Events kann die gesamte Entwicklung des Projektes mit allen Handlungen und Verantwortlichkeiten nach-vollzogen werden. Auch kann nachträglich ein bestimmter Zustand des Projektes oder eines Teiles wieder hergestellt werden. Das technische Grundgerüst des Systems ist die weit verbreitete Microsoft Software; die angeschlossenen Systeme, mit denen die Projektbeteiligten arbeiten, sind SAP, Standard Planungssoftware und Werkzeuge unserer Unternehmen Scheer GmbH, Scheer PAS GmbH und imc AG.

Mit der Integrationstechnik aus Scheer PAS werden zum einen die Werkzeuge der Arbeitsebene und zum anderen der Zugriff der Stakeholder für Auswertungen integriert. Die Unternehmensleitung kann sich aktuell über Stand, Fortschritt und Zukunft des Projektes informieren. Die Projektleitung informiert sich zum Beispiel über die weitere Planung und die Fachabteilung über die anstehende Arbeitsbelastung ihrer Mitarbeiter. Neben dem Monitoring sind weitere wichtige Funktionen das Vergleichen (Benchmarking) mit den Projektverläufen ähnlicher Projekte sowie Process Mining als Vergleich zwischen Ist- und Sollablauf des Projektes. Hierzu können entsprechende KPIs definiert und berechnet werden. Durch ein einheitliches Dashboard werden benutzerfreundliche umfangreiche Analysen zwischen den Systemen möglich. Ein Transformationsprojekt ist in der Regel nicht mit dem „Go live“ des neuen IT-Systems abgeschlossen. Vielmehr finden im weiteren Zeitablauf Releasewechsel der Standardsoftware, inhaltliche Veränderung von Prozessen durch Aufnahme neuer Funktionen, organisatorische Veränderungen von Zuständigkeiten etc. statt.

Deshalb kann das System vom Kunden über die Projektarbeit hinaus eingesetzt werden und wird damit zu einem dynamischen Enterprise-Architecture (EA)-System. Es wird dabei keine EA-Datei im traditionellen Sinn erzeugt, sondern sie wird aus einer Ausgangslösung über die inzwischen eingetretenen Änderungsereignisse generiert. So kann quasi „auf Knopfdruck“ nachträglich auch ein früherer Zustand des EA hergestellt werden. Die Event-Datei wird dann zum Zentrum des EA-Ansatzes. Das System DC muss dehalb auch nach dem „Go live“ eines Projektes weiterverwendet werden. Sie stellt sicher, dass das EA-Modell aktuell gehalten wird und alle organisatorischen und technischen Änderungen über den gesamten Lifecycle des Unternehmens hinweg erfasst werden. Eine solche Transparenz ermöglicht es dem Unternehmen, neue Transformationsfelder zu entdecken, ihre gegenwärtigen Unterstützungssysteme mit ihrer Entstehungsgeschichte zu identifizieren sowie Schnittstellen zu angrenzenden Bereichen zu erkennen.

Unter einem digitalen Zwilling (Digital Twin) versteht man allgemein die digitale Repräsentation eines Ausschnittes der Realität mit dessen Eigenschaften. Der digitale Zwilling eines Unternehmens umfasst dann real-time alle Zustände des Unternehmens. Änderungen in dem Realsystem werden unmittelbar auf den digitalen Zwilling über-tragen und umgekehrt. Darüber hinaus kann der digitale Zwilling auch gegenüber der Realität zusätzliche Informationen wie errechnete KPI’s als Augmented Reality enthalten. Obwohl die komplette digitale Abbildung eines Unternehmens bisher wohl noch nicht existiert, gibt es bereits Ansätze für Teilbereiche (vgl. Abbildung 6).

Ein bekanntes Beispiel eines digitalen Zwillings ist die Abbildung einer Fabrik mit ihren Maschinen in einer fotorealistischen Form mit allen Bewegungsabläufen wie Produktions- oder Transportvorgängen. Auch Produkte wie Fahrzeuge werden fotorealistisch als digitale Zwillinge bei der Produktentwicklung dargestellt. Zudem gehört die Nutzung digitaler Zwillinge zur Fernüberwachung und -steuerung von Anlagen bereits zur Realität. Mit den digitalen Zwillingen können Simulationen und Tests durchgeführt werden und deren Ergebnisse auf die Gestaltung der realen Systeme übertragen werden. Hierzu wird eine Kopie des digitalen Zwillings gezogen, und an diesem werden dann Veränderungen durchgeführt. Der ursprüngliche Zwilling wird erst nach der Analyse der Simulationsergebnisse verändert. Die Simulationen verbrauchen gegenüber realen Tests und Versuchen kein Material und können im Zeitraffer durchgeführt werden. Damit zeigt sich bereits der Nutzen dieses Ansatzes.

Während im technischen Umfeld der Produktentwicklung sowie bei Produktion, Verfahrensabläufen und Logistik der Einsatz von digitalen Zwillingen bereits verbreitet ist, ist dieses im Bürobereich mit seinen Geschäftsprozessen noch unüblich. Die vorhandenen Ansätze für digitale Zwillinge haben jeweils ihre eigenen Anwendungs-fälle. Ihre Erweiterung und Einfügung in den Rahmen der EA fügt die Teile dann zu einem Gesamtbild.

Der diskutierte EA-Ansatz mit seinen Entwicklungsstufen entwickelt sich dann stufen-weise bis zur fotorealistischen digitalen Abbildung des gesamten Unternehmens. Abbildung 7 zeigt das Konzept des unternehmensweiten digitalen Zwillings in seinen Entwicklungsschritten. Der Zwilling wird in drei Verdichtungsstufen dargestellt. Die Stufen 1 und 2 lehnen sich eng an die Ausführungen zur Entwicklung des EA-Ansatzes an, während die Stufe 3 den detaillierten fotorealistischen digitalen Zwilling darstellt (vgl. Werth, D.; Linn, C.).

Ausgang ist der Ausschnitt der interessierenden realen Unternehmenswelt, hier als reales Unternehmen bezeichnet. Je nach dem Interesse kann dieses das gesamte Unternehmen mit seinen Partnerbeziehungen umfassen oder einen interessierenden Ausschnitt, wie zum Beispiel einen Standort oder die an einem bestimmten Geschäfts-prozess beteiligten Einheiten. In Stufe 1 werden die Geschäftsprozesse des realen Unternehmens manuell modelliert (Entwicklungsschritt 1), wobei vorhandene digitale Modelle wie Referenzmodelle genutzt werden können. Ergebnis ist dann eine modellierte EA auf der Typ-Ebene. Es enthält alle als sinnvoll erachteten Prozess-alternativen in komprimierter Form sowie Daten-, Funktions-, Organisations- und Leistungsmodelle mit passenden KPIs. Die Modelle können auch vom Fachkonzept über die Schritte Design und Implementierung verfeinert werden.

Mit der Modellbildung wird bereits eine Abstraktion der Realität erreicht. Es wird zum Beispiel von der bildlichen Darstellung der realen Objekte abstrahiert. Gleichzeitig sind die Modelle statisch und werden nur von Zeit zu Zeit verändert. Da die Modelle eine Abbildung der Realität sind, kann man sie als einen ersten Zwilling bezeichnen, der aber noch nicht alle oben aufgeführten Eigenschaften besitzt. So fehlen die Real-Time-Aktualität oder die 1:1-Entsprechung von Zwilling und Realität.

In Schritt 2 konfigurieren die Modelle das reale Informationssystem aus Hard- und Software des Unternehmens. Dieses System ist ein Ausschnitt aus dem realen Unternehmen. Das Informationssystem ist in seiner Build-Time-Version somit ebenfalls ein digitaler Zwilling der Stufe 1, wobei es zu den EA-Modellen nur in bestimmten Bereichen zusätzliche Informationen liefern kann. Somit schließt das reale Informations-system technische Eigenschaften ein, die in den Modellen nicht enthalten sind; umgekehrt beinhalten die Modelle Angaben über Zeiten, KPIs oder organisatorische Rollenmodelle, die nicht im realen Informationssystem erfasst sind. Insgesamt bildet das Build-Time-Informationssystem aber einen großen Ausschnitt der Struktur des realen Unternehmens digital ab. Es ist dabei sowohl Abbild der Unternehmensrealität als auch ihr Bestandteil.

In der zweiten Stufe des digitalen Zwillings wechselt die Betrachtung von der Typ-Ebene auf die Ausführungsebene und damit zu den einzelnen Prozessinstanzen. Ein Wechsel von der Struktur- zur Verhaltensbetrachtung findet statt. Dadurch können weitaus mehr Details begutachtet werden.

In Schritt 3 werden die Prozessinstanzen des Unternehmens vom Informationssystem in der Run-Time ausgeführt. Dazu werden von Benutzereingaben (Dateninput) des realen Unternehmens die Prozesse ausgelöst (Schritt 4) und bearbeitet. Das Informations-system steuert somit in Schritt 5 das reale Verhalten des Unternehmens. Da das Informationssystem die realen Prozesse in der Informationssicht spiegelt, kann es auch als digitaler Real-Time-Zwilling bezeichnet werden. Allerdings sind die digitalen Informationen dem Benutzer nur in einer technisch limitierten Form durch vorgefertigte Masken und weitgehend ohne Prozesszusammenhang zugänglich.

In Schritt 6 werden deshalb durch das Process Mining die einzelnen Prozessinstanzen in benutzerfreundlicher Form durch Instanzenmodelle abgebildet. Hierzu werden Events der Anwendungssysteme zur Speicherung von Transaktionsdaten in Logdateien genutzt oder spezielle Monitoringsysteme wie beim Desktop Activity Mining eingesetzt. Diese zeigen für jeden Prozessablauf die Reihenfolge der Bearbeitungen, den zeitlichen Ablauf und die ausführenden Organisationseinheiten Real-Time auf.
Die Instanzenmodelle der Stufe 2 erfüllen somit die Forderung nach einer synchronen Darstellung des Realitätsausschnitts durch den digitalen Zwilling. Allerding ist die Modelldarstellung weiterhin relativ abstrakt. Trotzdem kann in den Ablauf der einzelnen Instanzen eingegriffen werden, indem zum Beispiel bei einer erkannten Verzögerung des zeitlichen Ablaufs ein neuer Weg für den weiteren Ablauf vorgeschlagen wird (Schritt 7). Damit wird über den digitalen Zwilling der Stufe 2 das reale Verhalten des Unternehmens beeinflusst. Zudem kann der digitale Zwilling für Simulationen genutzt werden. Auf Basis des Modells der Stufe 1 können so beispielsweise für einen bestimmten Zeitraum die abgelaufenen Prozesse in einem Zeitraffer grafisch sichtbar gemacht werden. Damit nähert sich die Stufe 2 bereits eng an die Realität und die Anforderungen an einen echten Digitalen Zwilling an, es fehlt im wesentlichen noch die fotorealistische benutzerfreundliche Darstellung.

Zunächst gehen wir aber in Schritt 8 noch einen Gedankenschritt zurück. Durch Algorithmen des Process Minings werden in Schritt 8 aus den Instanzenmodellen durch Verdichtung weitere Modelle auf der Typebene generiert (Model Discovery). Sie können mit den in Schritt 1 entwickelten Modellen abgeglichen werden (Compliance Check). Dies findet auf der Stufe 1 der digitalen Zwillinge statt. Durch organisatorische Änderungen kann über den umgekehrten Weg des Schrittes 1 auf die Unternehmens-realität eingegriffen werden.

In Stufe 3 wird nun der Übergang zu dem vollständigen digitalen Zwilling vollzogen. Hier wird die Abbildung der Realität weiter verfeinert, zeitlich synchronisiert und damit der Abstraktionsgrad der Darstellung drastisch reduziert.

In Schritt 9 wird aus der Realität ein grafisches (fotorealistisches) Abbild des Unternehmens als Basis der Darstellung erzeugt. Die einzelnen Prozessinstanzen werden in Real-Time den Organisationsobjekten zugeordnet, so dass jederzeit die gerade aktiven Prozessinstanzen in ihrem Zustand sichtbar sind.

Der digitale Zwilling der Stufe 3 liefert damit den größten Komfort, bezogen auf benutzerfreundliche Darstellung und Auswertungsmöglichkeiten. Hier können konkrete organisatorische Änderungen in ihren Auswirkungen simuliert und Entscheidungs-alternativen auf ihre Auswirkungen auf KPI‘s getestet werden. Strukturelle Änderungen der Realität werden über den Schritt 10 weitergegeben und dann über den Schritt 1 in den Kreislauf zur Anpassung des Build-Time Informationssystems geführt.

Eingriffe in den Ablauf einer Prozessinstanz werden wie bei Schritt 7 über den Schritt 11 an die Runtime-Version des Informationssystems gegeben. Das Rahmenkonzept der Enterprise Architecture wird in Schritt 12 an den digitalen Zwilling der Stufe 3 weitergegeben und hilft, die Objekte zu ordnen.

Natürlich ist der Übergang zu Stufe 3 mit einem erheblichen Aufwand verbunden. Da aber bereits für Teile des Unternehmens wie Produkte und Fabriken auch foto-realistische digitale Abbildungen gelebte Praxis sind, können diese Daten übernommen werden. Zudem können Techniken wie Virtual Reality und Augmented Reality genutzt werden. Mit der Vision Metaverse werden diese Gedanken in der nächsten Zeit weitere Unterstützung finden. So ist es gut vorstellbar, dass künftig das gesamte Unternehmen als bildlicher digitaler Zwilling bestehen wird. Dieser bildet die Grundlage für benutzer-freundliche Simulationen neuer Abläufe und dient als Grundlage für Entscheidungen eines innovativen, agilen und sich ständig neu erfindenden Unternehmens.