[vc_row][vc_column][vc_custom_heading text=“Composable Enterprise“ font_container=“tag:h1|font_size:48|text_align:left“ use_theme_fonts=“yes“ css=“.vc_custom_1676550898116{margin-top: -25px !important;}“][vc_custom_heading text=“Paradigmawechsel für Digitalisierung und Unternehmenssoftware“ font_container=“tag:h2|font_size:28|text_align:left|color:%23676b6d“ use_theme_fonts=“yes“ css=“.vc_custom_1676550959798{padding-bottom: 10px !important;}“][vc_column_text]August-Wilhelm Scheer, Scheer-Holding GmbH

(Titelbild: © Adobe Stock |199214543|nikkytok)[/vc_column_text][ultimate_spacer height=“15″ height_on_tabs=“15″ height_on_tabs_portrait=“15″ height_on_mob_landscape=“15″ height_on_mob=“15″][/vc_column][/vc_row][vc_row][vc_column][vc_row_inner el_class=“box-content-wrapper“][vc_column_inner][/vc_column_inner][/vc_row_inner][/vc_column][/vc_row][vc_row css=“.vc_custom_1519752670572{margin-top: -10px !important;}“][vc_column][ultimate_spacer height=“30″ height_on_tabs=“15″ height_on_tabs_portrait=“15″ height_on_mob_landscape=“15″ height_on_mob=“15″][/vc_column][/vc_row][vc_row][vc_column][vc_custom_heading text=“1. Notwendigkeit für einen Paradigmawechsel“ font_container=“tag:h3|font_size:28|text_align:left|color:%23676b6d“][vc_column_text]Die Probleme der Informationsverarbeitung vieler Unternehmen können durch folgende Eigenschaften beschrieben werden:
– Um einer stärkeren organisatorischen Zentralisierung nachzukommen, sind monolithische zentrale ERP-Systeme im Einsatz, die möglichst einheitlich für alle Unternehmensgliederungen eingesetzt werden.
– Spezialanwendungen werden notdürftig durch komplexe Punkt-zu-Punkt-Verbindungen mit den ERP-Anwendungen integriert.
– Die Unternehmenssoftware ist schwerfällig und für Entwicklungen neuer Anforderungen und innovativer Anwendungen nicht aufgeschlossen.
– Der IT-Fachkräftemangel begrenzt dringend erforderliche Erweiterungen.
– Die IT-Architektur ist häufig nicht transparent; es fehlen aktuelle Dokumentationen.
– An mit Programmiersprachen wie Cobol entwickelte Altsysteme traut man sich kaum mehr heran, um notwendige Änderungen vorzunehmen.
– Von Softwareanbietern erzwungene Umstellungen auf neue Infrastrukturen wie Datenbanken oder Cloud-Systeme binden erhebliche Ressourcen.
– Die IT wird eher zur Bremse als zum Treiber einer strategischen Weiterentwicklung des Unternehmens. Chancen durch den Einsatz von Techniken wie KI oder Blockchain für neue Geschäftsmodelle und Geschäftsprozesse können aus Kapazitäts- und Kompetenzgründen nicht genutzt werden.

Diese Situation trifft auf die Herausforderungen an Unternehmungen durch Pandemie, Krieg in Europa, Lieferengpässe, Energiekrise, Umweltschutz, Klimawandel, neue staatliche Vorschriften usw., die eine schnelle Anpassung von Unternehmen an geänderte Situationen erfordern.

Gleichzeitig entstehen neue Unternehmen, die, ohne Rücksicht auf gewachsene Strukturen nehmen zu müssen, die Vorteile neuer Informationstechniken für digitale Geschäftsmodelle nutzen und damit bestehende Unternehmen bedrohen.
Um sich aus diesen Engpässen zu befreien, genügt es nicht, einzelne Reparaturen auszuführen, sondern es bedarf einer Strategie, die beschreibt, auf welches Ziel sich das Unternehmen mit seiner Informationsverarbeitung hin entwickeln soll. Anschließend erfordert es eine praktikable Umsetzung durch Kenntnis der technischen Möglichkeiten und durch eine starke unternehmerische Führung.

Die Anzahl von Konzepten, die mögliche strategische Ausrichtungen von Unternehmen beschreiben, ist vielfältig. Die sie kennzeichnenden Attribute reichen von modular, lean, fraktal, virtuell bis zu dem Zusatz „4.0“. Die Konzepte richten dabei jeweils das Vergrößerungsglas auf eine vermeintlich neu entdeckte oder besonders wichtige Herausforderung und stellen sie in den Mittelpunkt.

Bei der „Unternehmung 4.0“ war in den vorhergehenden Auflagen die generelle Betonung der Digitalisierung das Leitmotiv. Es wurden Einflüsse der Informationstechnik auf neue Businessmodelle untersucht und neue Techniken zur Automatisierung von Geschäftsprozessen vorgestellt. Dabei fehlte aber eine klare Definition des Zielsystems, auf die alle Maßnahmen ausgerichtet werden sollen. Denn Digitalisierung ist kein Selbstzweck, sondern muss ihren Nutzen nachweisen. Ein Digitalisierungsprojekt, bei dem lediglich die bestehenden Geschäftsprozesse eins zu eins in eine neue Technologie überführt werden, z. B. von einem Inhouse-System in eine Public-Cloud-Lösung, endet sonst häufig mit dem Ergebnis: „Projekt in Time, in Budget, in Quality beendet – aber NO Benefit für das Unternehmen“. Dieser Situation muss sich die Digitalisierungsstrategie im Unternehmen stellen und ihren Beitrag zur Unternehmenstransformation leisten. Das erfordert einen Paradigmenwechsel für Ziel, Architektur und Anwendungen der Informationsverarbeitung.[/vc_column_text][vc_custom_heading text=“1.1 Anforderungen an: Agilität, Flexibilität, Innovationsfreude“ font_container=“tag:h3|font_size:28|text_align:left|color:%23676b6d“][vc_column_text]Der Nutzen der Digitalisierung liegt nicht allein in dem Einsatz einer neuen Technik, sondern in organisatorischen Änderungen und neuen Geschäftsmodellen, die von ihr inspiriert werden und sich in Kostenreduktionen und/oder Umsatzsteigerungen auszahlen.
Diese monetären Effekte beruhen auf Eigenschaften, die ein Unternehmen befähigen, schnell neue Geschäftsprozesse und Geschäftsmodelle zu entwickeln und umzusetzen. Solche Eigenschaften sind vor allem Agilität, Flexibilität sowie Innovationsfreude. Diese Forderung ist nicht neu, sie bekommt aber eine zunehmende Bedeutung im Wettbewerb.
Agilität bezeichnet die Eigenschaft, regsam zu sein, neue Wege frei von Angst zu beschreiten und ist damit eine aktive, suchende Vorgehensweise, die auch als Discovery bezeichnet wird.

Flexibilität bezeichnet eine anpassungsfähige, also schnell adaptierende und reagierende Haltung. Beide Eigenschaften sind erforderlich, um innovationsfreudig , also offen und suchend nach neuen Ideen zu sein und sie auch umsetzen zu wollen.
Dazu muss das Unternehmen wenig komplex sein, da Komplexität den genannten Eigenschaften entgegensteht. Monolithische Unternehmen mit einer Vielzahl ineinander verwobener Untergliederungen und Prozesse unter zentraler Führung sind komplex. Dezentrale, unternehmerisch und autonom arbeitende modulare Einheiten mit lockerer Kopplung erfüllen die Anforderungen an Einfachheit eher.

Der häufig verwendete Begriff Resilienz, der die Widerstandsfähigkeit gegenüber Angriffen von außen zum Ausdruck bringt, fügt eine weitere Eigenschaft hinzu .[/vc_column_text][vc_custom_heading text=“1.2 Der Begriff Composable Enterprise“ font_container=“tag:h3|font_size:28|text_align:left|color:%23676b6d“][vc_column_text]Das Konzept des „Composable Enterprise“ erfüllt die Forderungen nach Agilität, Flexibilität, Innovationsfreudigkeit, geringer Komplexität und Resilienz. Die Eigenschaft „composable“ wird am besten mit „zusammensetzbar“, „montierbar“, „kombinierbar“ oder „komponierbar“ übersetzt. Der Begriff Composable Enterprise wurde zuerst von der internationalen Analystenorganisation Gartner um das Jahr 2020 in mehreren Forschungsbeiträgen eingebracht und erfreut sich zunehmender Beachtung auch in der Praxis. Die Gartner Group definiert das Composable Enterprise wie folgt: „A composable enterprise is an organization that can innovate and adapt to changing business needs through the assembly and combination of packaged business capabilities” (Gartner ID: G00465932, June 2021). Dieser Definition wird sich im Folgenden weitgehend angeschlossen.[/vc_column_text][vc_custom_heading text=“1.3 Wesentliche Komponenten der Informationssysteme des Composable Enterprise“ font_container=“tag:h3|font_size:28|text_align:left|color:%23676b6d“][vc_column_text]Zur Umsetzung der Eigenschaften des Composable Enterprise dienen vornehmlich seine Informationssysteme. Deren Architektur wird von Gartner durch die Abbildung 1 beschrieben. Obwohl die Abbildung auf den ersten Blick einfach aussieht, enthält sie bereits wesentliche Aussagen, die in den weiteren Ausführungen vertieft werden. Innerhalb des großen Fünfecks wird die technische Architektur für die Anwendungsinhalte beschrieben. Die Begriffe am Außenkranz bezeichnen die Sicht des Anwenders auf die Systeme und die Unternehmensumgebung.[/vc_column_text][vc_single_image image=“32296″ img_size=“large“ title=“Abb. 1 Composable Business Architecture. Quelle: Gaughan et al. (Gartner), 2020, S. 4″][vc_custom_heading text=“1.3.1 Packaged Business Capability (PBC)“ font_container=“tag:h3|font_size:28|text_align:left|color:%23676b6d“][vc_column_text]Innerhalb des großen Fünfecks der Abb. 1 sind die Business Capabilities (PBC)“ als Sechsecke dargestellt. Eine PBC ist eine in sich geschlossene (betriebswirtschaftliche) Anwendungsfunktion oder Geschäftsprozesseinheit, die aus feineren Anwendungseinheiten oder Services zusammengefügt (packaged) ist. Damit wird einem Modulierungskonzept für Anwendungen gefolgt.

Die bisher veröffentlichten Ausführungen in der Literatur lassen noch Spielraum für Interpretationen der PBCs. Trotzdem können einige Eigenschaften festgehalten werden.
Eine PBC ist demnach eine gekapselte (autarke) Softwarekomponente mit ihren internen Services. Ein Service ist in Abb. 1 als Kreis mit Verbindungen zu den anderen Services der PBC dargestellt. Die Verbindungen werden durch den internen Prozess, genauer durch dessen Kon-trollstruktur, begründet.

Die PBCs werden zu komplexeren Anwendungen (Business Applications) komponiert oder orchestriert. Die Verbindungen zwischen den PBCs werden inhaltlich über die Kontrollflüsse der übergeordneten Geschäftsprozesse definiert und durch die benötigten Daten und Dienste spezifiziert. Die technische Integration wird über Schnittstellen APIs (Application Program Interface) oder Ereignissteuerung (Events) geregelt. Bei Anwendung von APIs stellt eine PBC einen (Software-) Dienst bereit, über den eine andere PBC auf Daten und Funktionen der PBC zugreifen kann. Bei einer Ereignissteuerung (Event Driven Architecture, EDA) meldet eine PBC Ereignisse, z. B. eine PBC für die Auftragsannahme die Ankunft eines neuen Kundenauftrags in einem elektronischen Briefkasten, und die Aufträge weiterverarbeitender PBCs reagieren darauf. Beide Verfahren führen zu einer losen Kopplung der PBCs und damit zu einer hohen Flexibilität, da PBCs unabhängig voneinander weiterentwickelt, ausgetauscht oder angekoppelt werden können.[/vc_column_text][vc_custom_heading text=“1.3.2 Application Composition Platform (ACP)“ font_container=“tag:h3|font_size:28|text_align:left|color:%23676b6d“][vc_column_text]Die Application Composition Platform ist ein Herzstück der Architektur des Composable Enterprise. Hier soll zunächst ein erster Eindruck von ihrer Funktionalität vermittelt werden.

Die von Gartner in Abb. 1 bezeichnete „Digital Business Technology Platform“ wird in dieser Arbeit zwar mit dem Begriff „Application Composition Platform“ belegt, besitzt aber die gleiche Bedeutung. Sie enthält zunächst die Tools, mit denen die Business Capabilities innerhalb des Fünfecks entwickelt werden und sind damit die Entwicklungsumgebung des Entwicklers. Sie unterstützt, dass das Composable Enterprise in hohem Maße Anwendungssoftware selbst entwickelt, um innovative Ideen, für die keine Standardlösungen bereitstehen, umsetzen zu können.

Auf der Plattform werden anschließend die einzelnen Business Capabilities zu Anwendungen montiert. Gleichzeitig werden sie auch mit vorhandenen Altsystemen, z. B. ERP-Systemen, und dem Business Ecosystem aus Systemen von Kunden, Lieferanten und Partnern verbunden.

Die Plattform führt die Software auf einer Cloud-Infrastruktur aus. Neue Anwendungen werden in einer Cloud-Umgebung entwickelt und ausgeführt.
Mit Experience werden die Erfahrungen und das Erleben des Benutzers mit dem Anwendungssystem bezeichnet. Diese Schnittstelle betrifft insbesondere das User Interface eines Systems.

Es definiert, wie der Benutzer mit dem System umgeht, welche Erlebnisse er hat, ob es ihn motiviert oder eher abschreckt. Erfahrungsgemäß ändern sich die Anforderungen für das Interface häufig, so dass Mitarbeiter der Fachabteilung diese selbstständig anpassen möchten. Insgesamt bestimmt das User Interface die Experience und ist damit auch höchst individuell. Zur Entwicklung der Experience stellt die Plattform Entwicklungswerkzeuge auch für den Mitarbeiter der Fachabteilung bereit.
Das Business Ecosystem beschreibt das wirtschaftliche Umfeld des Unternehmens, das die Anforderungen an Flexibilität und Innovationsfähigkeit des Unternehmens bestimmt.

[/vc_column_text][vc_custom_heading text=“2. Beziehungen zwischen Organisationsstrukturen und dem „Composable Enterprise““ font_container=“tag:h3|font_size:28|text_align:left|color:%23676b6d“][vc_column_text]Das Composable Enterprise ist ein Konzept, das die Aufgaben einer Unternehmung möglichst einfach und schnell auf allen Ebenen aus modularen unternehmerischen Fähigkeiten zusammensetzt, verbessert und innoviert. Es reicht von der Unternehmensstrategie über die organisatorische Gestaltung bis zur IT-Ausführung.

Bei den Darstellungen von Gartner dominieren bisher erst allgemeine Ratschläge zur Entwicklung einer Unternehmensstrategie für das Composable Enterprise. In einem großen inhaltlichen Schritt zur Informationstechnik werden dann Plattform und Packed Business Capabilities (PBC) vorgestellt. Hinweise auf konkrete organisatorische Strukturen des composable Unternehmens fehlen aber. Ein neues Informationssystem nutzt aber wenig, wenn es nicht zur Organisationsstruktur passt. Agilität und Flexibilität des Informationssystems gehen dann durch Diskussionen über Zuständigkeiten und Abstimmungsrunden zwischen verschiedenen Organisationseinheiten verloren. Deshalb ist der Zusammenhang zur zweckmäßigen organisatorischen Strukturierung des Composable Enterprise wesentlich. Organisatorische Kriterien und Begründungen liefern dem für die Informationssysteme zuständigen CIO (Chief Information Officer) in strategischen Diskussionen überzeugende Argumente für das Composable Enterprise.[/vc_column_text][vc_custom_heading text=“2.1 Organisationsstrukturen“ font_container=“tag:h3|font_size:28|text_align:left|color:%23676b6d“][vc_column_text]Grundsätze der betriebswirtschaftlichen Organisationslehre sind bei der Gestaltung des Composable Enterprise hilfreich. Dabei sind die organisatorischen Gegensatzpaare „funktional gegen objektorientiert“, „zentral gegen dezentral“ und „ressourcenoptimiert gegen prozessoptimiert“ von Bedeutung. Für eine konkrete Organisationsstruktur müssen Vor- und Nachteile dieser Gestaltungsalternativen gegeneinander abgewogen werden.
Eine generell „beste“ Organisationsstruktur für Unternehmen gibt es nicht, weil die Gewichtung der Vor- und Nachteile von der Zielsetzung und Situation des Unternehmens abhängt. Da die Zielsetzung des Composable Enterprise mit den Eigenschaften agil, flexibel usw. beschrieben ist, können aber daraus Tendenzen für die passende Organisationsstruktur abgeleitet werden.

Im Folgenden werden einige Beispiele für Organisationsstrukturen angeführt, und es wird eine Tendenz für das Composable Enterprise gegeben. Bei einer funktionalen
Organisation richtet sich die Aufbauorganisation an den Kernfunktionen des Unternehmens aus, bei einer objektbezogenen Organisation nach den zu bearbeitenden Produktgruppen und Absatzgebieten.

Bei einer zentralen Organisation sind alle gestalterischen Funktionen und Entscheidungskompetenzen in einer Zentrale gebündelt. Nachgelagerte Einheiten haben lediglich ausführende Tätigkeiten. Bei einer dezentralen Organisation besitzen produkt- oder gebietsbezogene Einheiten eigene Entscheidungs- und Gestaltungsbefugnisse.
Bei einer Ressourcenoptimierung richtet sich der Prozessfluss nach den Ressourcen, um diese hoch auszulasten. Bei einer Prozessorganisation werden die Ressourcen nach den Arbeitsschritten des Prozesses angeordnet, um kurze Durchlaufzeiten zu erzielen.
In Abb. 2 ist eine funktionale, zentrale und ressourcenoptimierende Organisationsstruktur abgebildet. Alle Aufträge durchlaufen die zentralen Funktionen Vertrieb, Logistik (Einkauf), Leistungserstellung (Produktion) bis zur buchhalterischen Erfassung und Zahlung des Kunden. Dieser häufig verwendete anschauliche Prozess vom Auftragseingang bis zur Bezahlung wird auch als „order to cash“ bezeichnet. Zwei Abläufe für Ausprägungen zweier Produktgruppen A und B sind in Abb. 2 angegeben.

Die funktionalen Einheiten in Abb. 2 sind für alle Produktgruppen zuständig. Dadurch können ihre Kapazitäten bei Auftragsschwankungen einzelner Produktgruppen gut ausbalanciert werden. Da alle Funktionen zentral angesiedelt sind, ist sichergestellt, dass alle gleichartigen Tätigkeiten bei den Produktgruppen auch in gleicher Weise durchgeführt werden.

Diese Organisation besitzt allerdings erhebliche Nachteile. Wegen der gegenseitigen Behinderung heterogener Aufträge bei den gleichen Ressourcen entstehen lange Durchlaufzeiten. Sie erfordert wegen der Komplexität einen hohen Koordinationsbedarf. Sie besitzt geringe Kundennähe, geringe Flexibilität bei Änderungswünschen sowie geringe Agilität wegen des organisatorischen Beharrungsvermögens zentraler Einrichtungen. Diese Organisationsform ist deshalb für das Composable Enterprise nicht geeignet.

Ohne auf alle möglichen Organisationsvarianten einzugehen, wird in Abb. 3 eine Organisationsstruktur vorgestellt, die den Kriterien des Composable Enterprise besser folgt.

Um agil und flexibel zu sein, ist das Unternehmen in eigenständige modulare Einheiten gegliedert.

Zur modularen Gestaltung können Kriterien wie Produktorientierung, Marktorientierung, Kosten-/Ergebnisverantwortung oder die Integration mehrerer Wertschöpfungsstufen herangezogen werden [Wildemann, 1998, S. 37ff, S. 293ff]. In Abb. 3 sind zwei Einheiten für Produktgruppen und zwei Einheiten nach (Vertriebs-) Gebieten gebildet. Ihnen sind jeweils ihre Prozesse und unternehmerischen Gestaltungsmöglichkeiten zugewiesen.
Die Module bilden damit weitgehende autarke „Unternehmen“ innerhalb des Gesamtunternehmens mit eigener Leitungsinstanz als Process Owner oder Gebietsleiter.
Die Einheiten können schneller auf Kundenwünsche eingehen oder neue Produktinnovationen an den Markt bringen. Gleichzeitig sind die jeweiligen Prozesse auf homogenere Objekte bezogen und damit gegenüber dem Gesamtprozess über alle Produktgruppen und Gebiete hinweg wesentlich weniger komplex.

Aus verhaltensökonomischen Erkenntnissen kommt hinzu, dass die Mitarbeiter wegen der höheren Autonomie, ihrer stärkeren kommunikativen Einbeziehung und leichteren Rückkopplung zu ihrem Arbeitsergebnis stärker motiviert sind. Sie identifizieren sich mehr mit ihrer Arbeit, sehen ihren Sinn (purpose) und entfalten Einfallsreichtum und Kreativität. Diese Argumente spielen im Zeichen des Fachkräftemangels und der geänderten Arbeitseinstellungen der Y-Z-Generationen eine große Rolle.

Mit dem Konzept „Zentrale Dienste“ wird in Abb. 3 für übergreifende Funktionen die Ressourcenoptimierung durch Nutzung von Synergien bei gleichartigen Vorgängen unterstützt. Dies bedeutet, dass zentral zur Verfügung gestellte Ressourcen von mehreren modularen Einheiten genutzt werden können, ohne dass deren operative Prozesse darunter leiden. Dieses gilt häufig für die mehr kaufmännischen Funktionen wie Einkauf, Personalabrechnung oder Rechnungswesen. Bei zentraler Bearbeitung kann z. B. die stärkere Marktmacht bei Preisverhandlungen mit Lieferanten genutzt werden. Diese Mischung zwischen dezentralen Modulen und zentralen Diensten kann sich in einem Unternehmen auf unterschiedlichen Organisationsebenen wiederholen. So gilt das Konzept selbst in der Unternehmenszentrale, wenn deren Abteilungen zentrale Systeme nutzen, aber auch eigene Anwendungen entwickeln können. Dieses setzt sich bei Niederlassungen fort, die Funktionen der Zentrale nutzen, eigene kleine zentrale Organisationseinheiten einrichten und zusätzlich ihre individuellen Prozesseinheiten definieren. Dieses Wiederholungsprinzip der Selbstähnlichkeit wurde von Warnecke bereits in seinem Buch „Die fraktale Fabrik“ [Warnecke, 1996] herausgestellt und wird in dieser Arbeit häufig auftreten, wobei aber die modulare Prozessorientierung als Leitmotiv der Organisation immer im Vordergrund steht.[/vc_column_text][vc_single_image image=“32300″ img_size=“large“ title=“Abb. 2 Funktionale, zentrale, ressourcenoptimierende Organisation. Lange Durchlaufzeiten, hoher Koordinationsbedarf, fehlende Prozessverantwortung, geringe Flexibilität“][vc_single_image image=“32301″ img_size=“large“ title=“Abb. 3 Objektbezogene, dezentrale (modulare) Prozessorganisation mit zentralen Diensten zur Ressourcenoptimierung“][vc_custom_heading text=“2.2 Umsetzung der Organisationsstruktur in die Anwendungsarchitektur“ font_container=“tag:h3|font_size:28|text_align:left|color:%23676b6d“][vc_column_text]Eine extrem zentrale Funktionsstruktur wie die der Abb. 2 neigt zu einem zentralen monolithischen Anwendungssystem für alle Produktgruppen und Marktgebiete. Änderungen in den Anwendungen müssen mit den Anforderungen aller Produktgruppen und Gebiete abgestimmt werden. Dieses zeigt die Abhängigkeit zwischen Organisations- und Anwendungsstruktur.
Die Organisationsstruktur des Composable Enterprise der Abb. 3 mit stärkerer Agilität und Flexibilität erfordert deshalb eine flexiblere Anwendungsarchitektur.
Die in den Abbildungen 2 und 3 gewählten Darstellungsarten sind typische Organigramme mit einer Tendenz zur Darstellung von hierarchischen Abhängigkeiten. Um die Eigenschaften der dezentralen Autonomie und den Übergang zur flexiblen Anwendungsarchitektur des Composable Enterprise zu betonen, wird das Organigramm der Abb. 3 in die Abb. 4 übersetzt. Hier gruppieren sich die dezentralen Organisationseinheiten gleichberechtigt um die Unternehmenszentrale, die die zentralen Dienste und Geschäftsführungsfunktionen bereitstellt. Hier ist also anstelle der Hierarchie der Servicegedanke betont.[/vc_column_text][vc_single_image image=“32302″ img_size=“large“ title=“Abb. 4 Vereinfachte Darstellung der Prozessorganisation“][vc_column_text]Die Beziehung zwischen den PBCs und einer Anwendung ist vom Typ n:m (vgl. Abb. 5). Das bedeutet, dass eine Anwendung aus mehreren PBCs bestehen kann und eine PBC in mehreren Anwendungen verwendet werden kann. Eine Anwendung kann einen gesamten organisatorischen (betriebswirtschaftlichen) Prozess abbilden, oder in einem Prozess werden mehrere Anwendungen aufgerufen.[/vc_column_text][vc_single_image image=“32304″ img_size=“large“ title=“Abb. 5 n:m – Beziehung zwischen PBCs und Anwendungen“][vc_column_text]Die Verbindung zwischen Anwendungen zu einem Prozess wird durch das betriebswirtschaftliche Prozesswissen eines Prozessmodells hergestellt. Alle technischen Verbindungen zwischen PBCs und Anwendungen werden durch API- und/oder EDA-Technologie über die Integrationsfunktion der Application Composition Platform realisiert. Abb. 6 zeigt eine mögliche Anwendungsarchitektur für die Organisationsstruktur der Abb. 3 bzw. Abb. 4.

Die Anwendungen der Organisationseinheit „Zentrale Dienste“ werden durch die Shared Services abgebildet, auf die alle Anwendungen der dezentralen Einheiten über die Plattform zugreifen. Alle Komponenten sind auf der gleichen Hierarchieebene angeordnet. Dies gilt auch für die Shared Services, die in Abb. 5 lediglich zur Annäherung an die Zentralen Dienste der Abb. 4 in das Zentrum gezeichnet sind.

Elementare Bausteine für Anwendungen sind die PBCs, die die fachlichen Inhalte für eine Aufgabe als autonome Softwarekomponenten enthalten und sich durch API- und/oder EDA-Schnittstellen nach außen öffnen. Sie stellen die Bausteine der Anwendungen dar und sind über die Plattform verfügbar. Sie befinden sich auf einer Ebene und sind in Abb. 5 durch einen Fächer dargestellt. Die PBCs werden entsprechend dem Bauplan eines Prozessmodells über die Composition-Funktion der Plattform zu Anwendungen zusammengefügt oder komponiert. Dieses ist lediglich bei der Anwendung 1 durch drei PBCs grafisch angedeutet. Auch wird das User-Interface und damit die User-Experience der Anwendung hinzugefügt. Die Anwendungen sind entweder bereits Geschäftsprozesse oder werden organisatorisch zu übergreifenden Geschäftsprozessen gebündelt. Die Bündelung wird in Abb. 6 durch eine Umrandung dargestellt. Die Umrandung der Anwendungen mit den Shared Services zu Prozessen wird aus Gründen der Übersichtlichkeit fortgelassen; sie ist in der Regel bei allen Prozessen gegeben und wird über die Plattform technisch realisiert.

Für die Produktgruppe A ist in Abb. 5 lediglich ein Geschäftsprozess definiert, der aus zwei Anwendungen besteht, die aus den PBCs komponiert werden.

Für die Produktgruppe B sind zwei Geschäftsprozesse definiert, die jeweils aus einer für die Gruppe B zentralen und einer individuellen Anwendung bestehen.

Für das Marktgebiet I sind zwei Prozesse (gleich Anwendungen) und für das Gebiet II ein Prozess (gleich Anwendung) gebildet.[/vc_column_text][vc_single_image image=“32305″ img_size=“large“ title=“Abb. 6 Mögliche Anwendungsarchitektur des Composable Enterprise aus Abb. 3″][vc_column_text]Durch die API- und EDA-Schnittstellen und die Plattform können leicht PBCs neu verbunden, ersetzt, entfernt oder eingefügt werden, so dass die dezentralen Prozesse schnell geändert werden können.

In Abb. 7 ist der Bezug zu dem Beispiel fortgelassen und die prinzipielle Anwendungslogik dargestellt. Sie zeigt, wie sich die dezentralen Anwendungen um die zentralen Shared Services ranken und durch die Plattform PBAs zu Anwendungen und Anwendungen zu Prozessen verbunden werden können.

Die Sicht des Benutzers ist dabei auf die Prozesse und Anwendungen gerichtet. Die PBAs sind technische Bausteine und bleiben ihm verborgen. Die Infrastruktur wird durch die Cloud dargestellt.

Externe Anwendungen von Kunden, Lieferanten oder Partnern verbinden sich über die Cloud mit dem Informationssystem und greifen über das API-Management auf Daten und Dienste des Unternehmens zu.

Die Einführung des Composable Enterprise ist ein mehrjähriges Projekt, da bei einem bestehenden Unternehmen nicht gleichzeitig alle Systeme ersetzt werden können. Trotzdem kann in neu eingeführten Prozesseinheiten oder in besonders dringend nach mehr Flexibilität verlangenden Bereichen sofort begonnen werden. Hier ist dann die Integrationsmöglichkeit zu bestehenden Altsystemen über die Plattform besonders wichtig.[/vc_column_text][vc_single_image image=“32306″ img_size=“large“ title=“Abb. 7 Allgemeine Anwendungsarchitektur AdobeStock | 483789409 | PureSolution“][vc_custom_heading text=“3. Der Composable Enterprise Lifecycle“ font_container=“tag:h3|font_size:28|text_align:left|color:%23676b6d“][vc_column_text]Nach der Begründung des Konzeptes des Composable Enterprise mit den Konsequenzen für Organisation und Anwendungsarchitektur wird es mit dem Lifecycle-Konzept verbunden. Das Lifecycle-Konzept reicht von der Entwicklung einer Innovationsidee über die Prozessmodellierung und Enterprise Architecture, dem Aufbau der Application Composition Platform, der Anwendungsentwicklung, der Ausführung, dem Process-Monitoring und -Mining bis zur kontinuierlichen Verbesserung der Innovation und ihrer Anwendungssysteme.

Der Lifecycle wird in diesem Abschnitt in sieben Phasen entwickelt.Abbildung 8 fasst die Phasen grafisch zusammen.Diesen Phasen wird anschließend jeweils ein ausführliches Kapitel gewidmet.[/vc_column_text][vc_custom_heading text=“3.1 Phase 1: Innovationsprozess“ font_container=“tag:h3|font_size:28|text_align:left|color:%23676b6d“][vc_column_text]Die Unternehmensumwelt sowie die Entwicklungen der Informationstechnik verlangen von dem Composable Enterprise strategische Innovationen. Dies geschieht durch neue oder geänderte Business Modelle und Geschäftsprozesse. Geschäftsprozesse dienen dabei einmal zur operativen Umsetzung neuer Businessmodelle, können aber bei Dienstleistungen selbst auch Geschäftsmodelle darstellen.

Viele Innovationen, die digitale Unternehmen erfolgreich machen, beruhen auf dem Outside-in-Denken. Bei dem Outside-in-Ansatz dominiert die Frage: „Wie wird die Erfahrung (experience) des Kunden mit dem neuen Produkt sein und welche Wünsche und Erwartungen hat er zusätzlich?“

Bei dem Inside-out-Vorgehen stehen dagegen die eigenen Erfahrungen und die eigenen Ideen und Fähigkeiten des Unternehmens im Vordergrund. Sprunghafte Innovationen sind dann eher selten.

Das Outside-in-Denken fällt schwer, da man gewohnt ist, seine eigenen Ideen in den Vordergrund zu stellen.

Viele Innovationen beruhen aber auf Änderungen der Beziehungen des Unternehmens zu Partnern außerhalb des Unternehmens, also zu den Kunden, Lieferanten, Bewerbern und Geschäftspartnern. Ihre Erfahrung mit dem Unternehmen, seinen Produkten und Dienstleistungen bestimmen den Geschäftserfolg. Welche Erlebnisse hat ein Kunde mit dem Produkt, besitzt er die Aufnahmefähigkeit für neue Funktionen, die ihm angeboten werden? Welche Erfahrungen macht ein Lieferant mit dem Unternehmen? Wie wird das Unternehmen für Bewerber attraktiver? Kann die Partnerschaft zu externen Stakeholdern verstärkt werden?

Potenziellen Bewerbern können bei dem bekannten Fachkräftemangel nicht mehr nur Bewerbungsunterlagen geschickt werden, sondern es müssen Informationen gegeben werden, durch die sie die Werte des Unternehmens erfahren und erleben können.
Wie erlebt ein Geschäftspartner die Zusammenarbeit? Kann das Vertrauensverhältnis verstärkt werden?

Das sind Felder, in denen neue Businessmodelle entstehen, wie bekannte digitale Unternehmen, wie z. B. Airbnb oder Uber, zeigen.

Airbnb ist nicht von einer bestehenden Hotelkette gegründet worden, sondern von Studenten, die überlegt haben, welche Dienste ein Kunde zum Übernachten in einer fremden Stadt bei einem begrenzten Budget benötigt: ein sauberes Zimmer mit einem akzeptablen Service und einer überprüfbaren Qualität. Dieses muss dann nicht ein professionelles Hotel sein, sondern kann auch eine vertrauenswürdige Privatperson mit einem ungenutzten Zimmer sein. Ein einfacher digitaler Suchvorgang verbindet dann Bedarf und Angebot, und die Bewertung der Services bietet die Vertrauensbasis.
Aus solchen Überlegungen, unterstützt durch Kreativitätstechniken wie „Design Thinking“, können neue Businessmodelle modulartig entwickelt werden.

Der „Composable“-Gedanke bezieht sich dann auf Fragen, aus welchen eigen- oder fremderstellten Modulen sich die Unternehmensleistung zusammensetzen soll. Das Montieren neuer Produkte oder Dienstleistungen aus bereits am Markt befindlichen Modulen kann die Innovationsgeschwindigkeit gegenüber einer reinen Eigenentwicklung erheblich steigern. Dieses setzt voraus, dass die IT-unterstützten Geschäftsprozesse die Eingliederung von Geschäftsmodulen unterstützen.

Je mehr „composable“ deshalb ein Unternehmen bei der Informationsverarbeitung ist, umso mehr kann es flexibel agieren, indem z. B. neue Partner, Geschäftsteile oder Prozesse hinzugenommen oder ausgetauscht werden.

Ergebnis der Überlegungen ist dann ein Businessplan für eine Innovation.[/vc_column_text][vc_single_image image=“32307″ img_size=“large“ title=“Abb. 8 Composable Enterprise Lifecycle AdobeStock | 468739708 | Gorodenkoff AdobeStock | 483288609 | Gorodenkoff“][vc_custom_heading text=“3.2 Phase 2: Composable Process- und Enterprise Architecture“ font_container=“tag:h3|font_size:28|text_align:left|color:%23676b6d“][vc_column_text]Aus den strategischen Überlegungen werden die benötigten Geschäftsprozesse definiert und in einer Architektur zusammengestellt. Diese enthalten noch keine IT-Begriffe, sondern werden zunächst organisatorisch-inhaltlich beschrieben und gegliedert. Durch eine klare Strukturierung der Module wird dabei dem Composable-Gedanken gefolgt.
Bei der Beschreibung der Geschäftsprozesse steht die Reihenfolge der Funktionen, in der sie ausgeführt werden, im Vordergrund. Aber auch die verantwortlichen Organisationseinheiten, die verwendeten Daten und erzeugten Leistungen oder Produkte gehören zur Prozessbeschreibung. Zudem müssen die Prozesse in ein Rahmenkonzept, eine Enterprise Architecture, eingeordnet werden, um Überlappungen, Inkonsistenzen und weiße Flecken der Prozesslandschaft zu entdecken.

Mit dem ARIS-Haus hat der Verfasser eine Enterprise Architecture (EA) und mit den ereignisgesteuerten Prozessketten (EPK) eine Modellierungssprache für Geschäftsprozesse entwickelt, die international eingesetzt werden. Die Sichten des ARIS-Hauses aus Organisation, Daten, Funktionen, Produkten und Prozesse bilden den Rahmen der Enterprise Architecture, um ein Unternehmen in seiner Struktur und seinen Tätigkeiten zu beschreiben.

Für jede der Sichten werden halbformale grafische Beschreibungssprachen eingesetzt.
EA-Konzepte werden bereits seit längerem angewendet, sind zwischenzeitlich etwas zurückgenommen worden, werden aber aufgrund der Komplexität umfassender digitaler Transformationsprojekte wieder in den Fokus der unternehmensweiten Informationsverarbeitung gerückt. Eine EA schafft Übersicht über vorhandene Systeme, beschreibt also die Ausgangssituation für eine digitale Transformation und verbindet sie mit dem in der Architektur beschriebenen Zielbild. Es ist möglich, ein EA-Modell weitgehend aus generierten oder von Beratungsunternehmen und Softwareanbietern bezogenen Prozessmodellen automatisch zu füllen, sodass sein Erstellungs- und Pflegeaufwand reduziert wird.

Die Modelle bilden Unternehmensaspekte digital ab und können deshalb als digitale Zwillinge (Digital Twins) des Unternehmens bezeichnet werden. Mit ihnen werden z. B. die Auswirkungen alternativer Prozesse simuliert. Die Prozessmodelle können durch digitale bildhafte Darstellungen, wie sie für Produkte und Fabriken bereits gebräuchlich sind, ergänzt werden. Dieses führt perspektivisch zu dem Ansatz Metaverse. Hiermit wird eine digitale Parallelwelt bezeichnet, die zwar zur Zeit mehr für konsumnahe Anwendungen diskutiert und entwickelt wird, aber auch für die Unternehmenswelt sinnvoll ist. Simulation, Virtual Reality, Augmented Reality und Avartare von Menschen verbinden dann virtuelle mit realer Welt.[/vc_column_text][vc_custom_heading text=“3.3 Phase 3: Application Composition Platform“ font_container=“tag:h3|font_size:28|text_align:left|color:%23676b6d“][vc_column_text]Zur digitalen Umsetzung der Geschäftsprozesse des Composable Enterprise ist eine Composition Application Platform erforderlich. Sie stellt Funktionen zur Entwicklung, zur Prozessautomatisierung und -integration bis zur Ausführung und zum Monitoring bereit.

Die Plattform ist die Entwicklungsumgebung des Entwicklers für die PBCs und die Anwendungen. Zur Erinnerung: Eine PBC ist eine weitgehend autarke Programmeinheit, die auch als Building Block, Modul oder Service bezeichnet werden kann. Die Autarkie bezieht sich darauf, dass nur eine geringe Abhängigkeit zu Funktionen und Daten außerhalb der Einheit bestehen soll und eine eigene interne Datenverwaltung besteht. Dieses macht die PBCs in ihrer Entwicklungsgeschwindigkeit voneinander unabhängig.
Aus den PBCs werden die Anwendungen zusammengestellt (composed, komponiert). Die Anwendungen werden weiter zu Prozessen gebündelt. Die drei Objekte bilden zusammen die Anwendungssystemarchitektur.

Die Anwendungen und Prozesse sind die Schnittstelle für den Benutzer, wobei diesem die darunterliegenden technischen Funktionen der Plattform und die PCBs verborgen sind.
Zur Definition der Geschäftsprozesse ist in der Plattform ein Modellierungstool oder Designer installiert.

Eine zentrale Funktion der Plattform ist die Integration und Montage der PBCs zu Anwendungen und Geschäftsprozessen. Die Integration der PBCs sowie die Integration externer Komponenten wird über APIs und/oder Event-Schnittstellen realisiert.
Eine konsequente API-Strategie unterstützt auch die Zerlegung bestehender monolithischer Systeme in Building Blocks. Hersteller eher monolithischer Unternehmenssoftware wie SAP planen, ihre Systeme auf einer Business Technology Platform aufzusetzen, so dass eine Verbindung zwischen der Landschaft aus Alt- bzw. ERP-Systemen mit dem Composable-Ansatz hergestellt wird.

Zur Softwareentwicklung stellt die Application Composition Platform neben Programmiersprachen (Professional Coding, auch als Procode bezeichnet) eine Low-Code-Umgebung mit einem Durchgriff auf eine Standardprogrammiersprache (Procode) bereit. Mit Low-Code werden einfach zu erlernende grafische Beschreibungssprachen bezeichnet, aus denen automatisch ausführbarer Code generiert wird. Hierzu wird auf der Application Composition Platform eine grafische und formularorientierte Beschreibungssprache (z. B. als Ausschnitt einer Modellierungssprache wie EPK oder BPMN) bereitgestellt. Mit Low-Code können Mitarbeiter aus Fachabteilungen User Interfaces für die Experience eines Systems und einfache Anwendungen entwickeln. Damit wird das Problem des IT-Fachkräftemangels gemildert.

Die Workflow Funktionalität der Plattform unterstützt die Ausrichtung auf eine Geschäftsprozessorganisation.

Mit der Funktion Composition werden PBCs zu Anwendungen und Anwendungen zu Prozessen zusammengestellt.

Weiterhin gehören Funktionen zum Monitoring der auszuführenden Prozessinstanzen und Process Mining zum Standard einer Application Composition Platform. Schnittstellen zu übergreifenden Analysefunktionen und KI-Algorithmen unterstützen eine intelligente Prozessautomatisierung. Die Plattform als Cloud-Lösung beschleunigt leichtere Implementierung, leichteres Management und Ressourcenskalierung einer Anwendung.
Die beschriebenen Funktionen einer Application Composition Platform sollten in integrierter Form bereitgestellt werden. Dadurch ist z. B. sichergestellt, dass die Entwickler alle Funktionen in der gleichen Entwicklungsumgebung zur Verfügung haben. Geschäftsprozesse werden dann in der gleichen Methodik beschrieben wie Integrationsprozesse oder Entwicklungsprozesse von APIs. Dieses ist bei der „Scheer PAS Plattform“ des Unternehmens Scheer PAS GmbH in Saarbrücken der Fall.
Bei allen Schritten steht das Prinzip der Composability im Vordergrund; es muss also gewährleistet sein, dass PBCs und damit Anwendungen bis zu Prozessen einfach hinzugefügt, geändert oder entfernt werden können.

In einem Softwarecontainer werden alle von der Anwendung benötigten Hilfen wie Betriebssystemfunktionen und Daten zur Verfügung gestellt. Damit ist die Anwendung auf beliebiger Hardware ablauffähig und autark.

Mit den Fähigkeiten der Application Composition Platform können in der nächsten Phase die Anwendungen entwickelt werden.[/vc_column_text][vc_custom_heading text=“3.4 Phase 4: Development und Implementation“ font_container=“tag:h3|font_size:28|text_align:left|color:%23676b6d“][vc_column_text]Nachdem die Funktionen Prozessautomatisierung, Integration, Entwicklungsunterstützung und Composition der Plattform zur Verfügung stehen, werden die PBCs entwickelt und zu Anwendungen und Prozessen zusammengefügt. Neben neu zu entwickelnden PBCs können auch Teile bestehender selbst entwickelter Software (Legacy) oder Standardsysteme (ERP) verwendet werden, indem diese Teile neu geordnet und gekapselt werden.

Bei der Softwareentwicklung zeigt sich generell das Problem des Mangels an Informatikern und Systemspezialisten. Ein wichtiger Ausweg ist deshalb, die Entwicklung so zu vereinfachen, dass auch interessierte Mitarbeiter aus den Fachabteilungen Anwendungen mittels Low-Code-Funktionen der Plattform entwickeln können. Dieses Verfahren besitzt neben der Kapazitätsausweitung den Vorteil, dass aus den Fachabteilungen ohnehin der fachliche Input gegeben wird. So entfallen weitgehend Pflichtenhefte und Abstimmungsrunden zwischen Fachbereich und IT. Damit können die betriebswirtschaftlich grob beschriebenen Prozesse von Mitarbeitern der Fachabteilung (Citizen Developern) weiter detailliert werden und aus ihnen automatisch ein Softwarecode in einer Programmiersprache wie Java generiert werden. Das Low-Code-System stellt dazu eine 1:1-Beziehung zwischen Elementen der Modellierungssprache und entsprechenden Programmierkonstrukten bereit.

Low-Code unterstützt auch den Einsatz von Headless-Softwaresystemen. Hier stellt der Softwareanbieter lediglich den Verarbeitungsteil zur Verfügung. Das User Interface zu der Anwendung entwickelt der Anwender mit Low-Code dann selbst. Hiermit wird es ihm ermöglicht, sein individuelles Interface flexibel zu gestalten, ohne auf die Hilfe des Softwareanbieters warten zu müssen. Bei allen Prozessen sollte geprüft werden, an welchen Positionen sinnvoll KI-Algorithmen zur Automatisierung eingesetzt werden können. Dabei ist besonders darauf zu achten, dass diese keine Insellösungen innerhalb der Prozesse sind, sondern dass ihre Ergebnisse in den Workflow zur automatischen Weiterverarbeitung einfließen.

Bei größeren Projekten ist ein enges Projektmanagement wichtig, damit die geplante Zeit, Qualität und das Budget nicht aus dem Ruder laufen. Negative Beispiele sind hier zur Genüge bekannt.

Auch das Reskilling und Upskilling der späteren Benutzer ist entscheidend für den Projekterfolg. Schon vor dem Betrieb eines Systems muss dafür gesorgt werden, dass die künftigen Anwender in der Lage sind, die neuen Geschäftsprozesse und Systeme zu verstehen, um sie richtig ausführen zu können. Wenn das nicht geschieht, können die Systeme zwar technisch einsatzfähig sein, aber nicht effektiv genutzt werden. Zur Qualifizierung der Mitarbeiter bieten sich digitale Lernhilfen an.

Die fertigen Building Blocks werden in einem Katalog zusammengestellt und veröffentlicht. So wird Doppelentwicklungen vorgebeugt.

Das aus den PBCs orchestrierte Anwendungssystem steht dann dem Anwender zur Prozessbearbeitung zur Verfügung.[/vc_column_text][vc_custom_heading text=“3.5 Phase 5: Execution und Case Management“ font_container=“tag:h3|font_size:28|text_align:left|color:%23676b6d“][vc_column_text]In der Ausführungsphase werden von den Anwendern die einzelnen Prozessinstanzen gemäß den modellierten und implementierten Abläufen bearbeitet. Die Steuerung der einzelnen Instanzen wird als Case Management bezeichnet. Dieses bietet insbesondere bei länger dauernden Prozessabläufen Methoden zur Steuerung und Hilfestellungen zur Lösung von Problemsituationen an, um die operationale Performance von Prozessen zu steigern. Auf der Ebene der einzelnen Instanz startet in Abb. 8 ein eigener Lifecycle vom Beginn der Bearbeitung bis zur Fertigstellung. Dieses wird in Abb. 8 durch den kleinen Kreislauf grafisch zum Ausdruck gebracht.

Die Arbeitsergebnisse und Statusänderungen der Bearbeitung werden in Datenbanken gespeichert. Dabei gilt es, zwei Datenarten zu unterscheiden. Einmal betrifft es die Anwendungsdaten. Beispielsweise werden von einem Auftragsbearbeitungssystem die Auftragsdaten des Kunden in der Auftragsdatei erfasst. Diese Daten stehen zur Weiterbearbeitung in der Produktion sowie für Auswertungen zur Verfügung.
Eine zweite Daten-Art betrifft die Prozessausführung. Moderne Anwendungssoftware speichert z. B. Zeitstempel von Beginn und Ende einer Transaktionsbearbeitung, die praktisch einer Prozessfunktion entspricht, in sogenannten Log-Dateien.
Aus den Prozessdaten der Log-Dateien können in real time die Prozesszustände wie Zeiten, zuständige Bearbeiter und Arbeitsergebnisse der einzelnen Prozessinstanzen erfasst werden. Mit diesem Monitoring können z. B. Abweichungen zu den geplanten Vorgaben erkannt werden.

Bei Zeitverzögerungen kann durch Steuerungsalgorithmen in real time ein neuer Ablauf vorgeschlagen werden, um den Zeitverzug aufzuholen. Der Algorithmus verhält sich dann wie ein Navigationsinstrument eines Autos, das bei einer Straßensperrung für einen Fahrer automatisch eine individuelle neue Streckenführung vorschlägt.

Bei auftretenden Problemen können während der Fallbearbeitung dem Bearbeiter Hilfestellungen (support) durch auf die Situation bezogene Informationen oder Schulungsunterlagen gegeben werden.[/vc_column_text][vc_custom_heading text=“3.6 Phase 6: Insight durch Mining“ font_container=“tag:h3|font_size:28|text_align:left|color:%23676b6d“][vc_column_text]Sowohl aus den Anwendungs- als auch aus den Prozessdaten der Log-Dateien können wertvolle Auswertungen generiert werden, die zunächst zu neuen Erkenntnissen (Insights) führen, aber in der nächsten Phase auch zur Prozessverbesserung genutzt werden.
Zur automatischen Auswertung der Anwendungsdaten öffnet sich das Feld der „Analytics“, das u.a. ein ganzes Bündel statistischer Verfahren bereithält. Besonders interessant sind AI-Verfahren. Sie können Datenbestände automatisch nach in ihnen enthaltenen Mustern analysieren und Ausreißer erkennen. Dieses wird z. B. erfolgreich zur Betrugserkennung, Reisekostenprüfung und zu automatischen Marktanalysen eingesetzt.

Aus den Prozessdaten der Instanzen eines Zeitraums kann durch Algorithmen des Process Mining das dazu passende reale Prozessmodell automatisch generiert werden (Model Discovery). Das generierte Modell kann mit dem geplanten Prozessmodell verglichen werden, um Abweichungen festzustellen (Model Comparison).
Das generierte Modell zeigt dann die in dem Zeitraum tatsächlich durchgeführten Prozessabläufe in komprimierter Form. Die Anzahl der dabei durchlaufenen Wege kann durch nachträgliches (simuliertes) Durchlaufen der realen Instanzen an dem Modell gezählt werden, um Standardabläufe und Ausreißer zu erkennen.

Process Monitoring, Model Discovery und Model Comparison wurden bereits im Jahr 2000 von dem Produkt ARIS-PPM (Process Performance Manager) der IDS Scheer entwickelt und in den Markt eingeführt. Die Konzepte wurden inzwischen von einer breiten Community aus Wissenschaft und Anwendern weiterentwickelt und erfahren gegenwärtig auch durch neue Produkte wie Celonis und SIGNAVIO besondere Aufmerksamkeit.[/vc_column_text][vc_custom_heading text=“3.7 Phase 7: Actions / Verbesserungen“ font_container=“tag:h3|font_size:28|text_align:left|color:%23676b6d“][vc_column_text]Sowohl aus der Analyse von Anwendungsdaten als auch aus Prozessdaten können Anregungen für Systemverbesserungen abgeleitet werden.

Für einfache Automatisierungsaufgaben, wie den Datenaustausch zwischen verschiedenen Datenbanken, können mit Hilfe von RPA-Werkzeugen (Robotic Process Automation) von Mitarbeitern der Fachabteilung aus der Arbeitsplatzsicht kleine Anwendungen entwickelt werden. Dabei werden keine neuen Anwendungen entwickelt, sondern lediglich manuelle Vorgänge der Datenübertragung zwischen verschiedenen Anwendungen automatisiert.

Bei Analysen der Anwendungsdaten kann für bestimmte erkannte Datenmuster auf eine Falldatenbank zugegriffen werden, die für die Datenmuster Verbesserungsvorschläge anbietet. So kann bei einem zu hohen Lagerbestand ein neuer Bestellalgorithmus vorgeschlagen werden. Dieser kann durch vorgefertigte Apps der Datenbank direkt eingesetzt werden. Oder für ein identifiziertes Betrugsmuster wird eine App verwendet, die entsprechende Betrugsversuche abfängt.

Aus den Abweichungen zwischen Ist-Prozessmodell und dem Soll-Modell können organisatorische Maßnahmen oder Schulungen für Mitarbeiter ebenfalls aus einer Falldatenbank abgeleitet werden.

Diese Aktionen initiieren neue Projekte, die wiederum die Phasen des Transformationskreislaufs durchlaufen und in der Regel zu einer weiteren Innovation und Automatisierung beitragen.

Das ständige Durchlaufen des Transformationskreislaufs von der Innovation zur Ausführung und Verbesserung führt dann zu einer fortlaufenden Steigerung des Nutzens der digitalen Transformation und zur ständigen Weiterentwicklung des Composable Enterprise.

 

Literatur:

Scheer, A. (2002). ARIS – Vom Geschäftsprozess zum Anwendungssystem (4., durchges. Aufl. 2002). Springer.

Scheer, A. (2019). Unternehmung 4.0: Vom disruptiven Geschäftsmodell zur Automatisierung der Geschäftsprozesse (3., neu g. Aufl. 2020). Springer Vieweg.

Warnecke, H. J. (1996). Die fraktale Fabrik: Revolution der Unternehmenskultur. Rowohlt.

Wildemann, H. (1998). Die modulare Fabrik: kundennahe Produktion durch Fertigungssegmentierung. TCW-Transfer-Centrum.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][ult_dualbutton btn_hover_style=“Style 2″ btn_border_style=“solid“ btn_color_border=“#ffffff“ btn_border_size=“2″ btn_alignment=“left“ dual_resp=“off“ button1_text=“Einzelheft kaufen“ icon_link=“url:https%3A%2F%2Fwww.im-io.de%2Fproduct%2Fmetaverse%2F|title:Metaverse%2C%20NFTs%20%26%20Cryptos|target:_blank“ btn1_background_color=“#f3f3f3″ btn1_bghovercolor=“#f07d00″ icon=“Defaults-book“ icon_size=“22″ icon_color=“#f07d00″ icon_hover_color=“#ffffff“ button2_text=“Jetzt abonnieren“ btn_icon_link=“url:https%3A%2F%2Fwww.aws-institut.de%2Fim-io%2Fabo%2F|title:Abo||“ btn2_background_color=“#f3f3f3″ btn2_bghovercolor=“#f07d00″ btn_icon=“Defaults-chevron-right“ btn_icon_size=“22″ btn_icon_color=“#f07d00″ btn_iconhover_color=“#ffffff“ divider_text=“oder“ divider_text_color=“#f07d00″ divider_bg_color=“#ffffff“ btn1_text_color=“#f07d00″ btn1_text_hovercolor=“#ffffff“ btn2_text_color=“#f07d00″ btn2_text_hovercolor=“#ffffff“ title_font_size=“desktop:20px;“ btn_border_radius=“30″ title_line_ht=“desktop:22px;“ btn_width=“280″][/vc_column][/vc_row]