Der ultimative Leitfaden zur Migration von einer monolithischen Automatisierungsplattform
Whitepaper
Oktober 2024
Lesezeit: 23 Minuten
Einführung
Prozesse als Algorithmen, die den Unternehmensbetrieb definieren. Sie definieren, wie Teams zusammenarbeiten, wie die Organisation mit Partnern und Lieferanten zusammenarbeitet und wie sie ihren Kunden einen Mehrwert bietet. Um fantastische Kundenerlebnisse zu bieten, mit der Konkurrenz mitzuhalten, Betriebsabläufe zu optimieren und ihr Geschäftsergebnis zu verbessern, müssen Unternehmen geschäftskritische Prozesse automatisieren. Und es bleibt nicht bei der Automatisierung von Prozessen. Da KI und Automatisierung schnell voranschreiten, müssen Unternehmen auch ihre Unternehmensarchitektur zukunftssicher machen, um agil und wettbewerbsfähig zu bleiben.
Um dem dringenden Bedarf an Prozessautomatisierung gerecht zu werden, erwerben viele Unternehmen eine monolithische Automatisierungsplattform. Diese Produkte sind als All-in-One-Lösungen für die Automatisierung von Geschäftsprozessen positioniert, die sowohl automatisierte Aufgaben als auch Aufgaben umfassen, die von Wissensarbeitern ausgeführt werden müssen.
Welche Arten monolithischer Automatisierungsplattformen sind verfügbar?
Traditionelle monolithische Automatisierungsplattformen haben ihren Ursprung in der Welt der Business Process Management Suites (bekannt als BPMS oder iBPMS). Diese Produkte waren ursprünglich für die Automatisierung stabiler, wiederholbarer Back-Office-Prozesse in Abteilungen wie der Personal- und Finanzabteilung gedacht. Da die digitale Transformation den Bedarf nach einer stärkeren Automatisierung der Geschäftsabläufe erhöht hat, haben die Anbieter diese Produkte um Automatisierungsfunktionen erweitert.
Moderne monolithische Automatisierungsplattformen sind entstanden, indem Anbieter ihre Produkte, die ursprünglich für Zwecke wie CRM (Customer Relationship Management), ITSM (IT Service Management) sowie Personal- und Teamproduktivität konzipiert waren, um leichtgewichtige Prozessautomatisierungsfunktionen erweitert haben. In einigen Fällen wurden diese Funktionen intern entwickelt; in anderen Fällen wurden prozessbezogene Funktionen nach verschiedenen Akquisitionen lose in das ursprüngliche Produkt integriert.
Was macht eine Plattform zu einem Automatisierungsmonolithen?
Das entscheidende Merkmal monolithischer Automatisierungsplattformen ist ihre Architektur. Ein Monolith ist als einzelne Black-Box-Anwendung konzipiert und nicht als Sammlung lose gekoppelter Komponenten oder Microservices, die unabhängig voneinander betrieben werden können.
Die heute auf dem Markt erhältlichen monolithischen Automatisierungsplattformen haben noch einige weitere Gemeinsamkeiten. Erstens verfügen sie über eine integrierte proprietäre Designumgebung, in der Benutzer Prozesse, Geschäftsregeln und grundlegende Benutzeroberflächen erstellen können. Während Business-Technologen und Citizen Developer die integrierten Design-Tools zunächst vielleicht nützlich finden, verbergen proprietäre Tools oft die Komplexität realer Geschäftsprozesse, was ihre Visualisierung und Kontrolle erschwert.
Zweitens verfügen Automatisierungsmonolithen nur über begrenzte Möglichkeiten zur Implementierung komplexer oder nicht standardmäßiger Prozesse, die benutzerdefinierten Code erfordern. Softwareentwickler, die diesen Code schreiben, müssen entweder den Umgang mit den proprietären Tools des Monolithen erlernen oder die spezifische Programmiersprache verwenden, die der Monolith erfordert. Diese Anforderungen behindern die Produktivität der Entwickler und können bei fehlenden Fachkenntnissen dazu führen, dass Sie teure Berater einstellen müssen.
Drittens umfasst die geschlossene Natur von Automatisierungsmonolithen oft auch ihren Ansatz zur Integration und Orchestrierung anderer Unternehmenstools und -technologien. Wenn Konnektoren für Unternehmenstools nicht für Ihre spezifischen Anwendungsfälle modifiziert oder erweitert werden können, verlangsamt dies Prozessautomatisierungsprojekte und erhöht das Risiko der Anbieterbindung erheblich.
Die Herausforderungen monolithischer Automatisierungsplattformen
Unternehmen, die monolithische Automatisierungsplattformen einsetzen, um Anwendungsfälle der Prozessautomatisierung und -orchestrierung zu bewältigen, stehen vor mehreren Herausforderungen.
Erstens: Monolithische Automatisierungsplattformen stehen unter dem Druck, den Return on Investment (ROI) zu steigern und Mehrwert zu schaffen, verlangsamen aber tendenziell die Wertschöpfung, da sie mit komplexen oder nicht standardisierten Prozessen zu kämpfen haben. Wenn zur Automatisierung geschäftskritischer Prozesse umfangreiche Anpassungen erforderlich sind, geraten Projekte ins Stocken und der ROI verringert sich. Anpassungen führen auch zu einer Bindung an einen bestimmten Anbieter und zu technischen Schulden, was sich wiederum auch auf den ROI auswirkt.
Zweitens bieten Automatisierungsmonolithen keine ausreichende Transparenz oder Kontrolle für Geschäftsprozesse, insbesondere für komplexe oder hochspezialisierte Prozesse, die mehrere Geschäftseinheiten betreffen. Ohne einen vollständigen Überblick über einen Prozess von Anfang bis Ende sind die Möglichkeiten zur Verbesserung der Prozessleistung begrenzt.
Drittens ermöglichen Ihnen Automatisierungsmonolithen nicht, sich an veränderte Kundenbedürfnisse, Marktzwänge oder gesetzliche Vorschriften anzupassen. Unflexible Anforderungen an die Prozessimplementierung und umständliche Anpassungen können dazu führen, dass die Einführung von Prozessänderungen Wochen oder sogar Monate dauert. Dies wirkt sich negativ auf das Kundenerlebnis aus und behindert die Innovation; es kann sogar bedeuten, dass Sie Chancen verpassen, sich gegen die Konkurrenz durchzusetzen.
Eine Alternative zu monolithischen Automatisierungsplattformen
Um Ihre Unternehmensarchitektur zukunftssicher zu machen, benötigen Sie Automatisierungslösungen, die an die individuellen Anforderungen Ihres Unternehmens angepasst werden können. Der modulare, flexible und offene Ansatz von Camunda bietet im Vergleich zu monolithischen Automatisierungsplattformen eine schnelle Implementierung, schnellere Wertschöpfung und schnellere Wertrealisierung. Camunda ermöglicht Ihnen eine schnelle Anpassung an sich entwickelnde Marktkräfte und neue Technologien und bietet eine Plattform, die es sowohl der IT als auch Fachabteilungen ermöglicht, schnell zu reagieren.
Mit Camunda behalten Sie die volle Kontrolle und Transparenz über jeden Aspekt Ihrer Prozessautomatisierung, im Gegensatz zu monolithischen Automatisierungsplattformen, die von den Teams die Verwendung proprietärer Tools verlangen und Anpassungsmöglichkeiten einschränken.
Dieser Leitfaden enthält praktische Beispiele von Unternehmen, die erfolgreich von einer monolithischen Automatisierungsplattform auf die Prozessautomatisierungs- und Orchestrierungslösung von Camunda migriert haben.
Wichtige Überlegungen zum Ersatz einer monolithischen Automatisierungsplattform
Dies sind wichtige Überlegungen, die Sie im Hinterkopf behalten sollten, wenn Sie eine Migration von einer monolithischen Automatisierungsplattform zu einer kompatiblen Prozessautomatisierungs- und Orchestrierungslösung wie Camunda in Betracht ziehen.
Unterstützung für Prozesse, die automatisierte und manuelle Aufgaben kombinieren
Wenn Sie eine monolithische Automatisierungsplattform ersetzen, sollten Sie den Umfang und die Vielfalt der Systeme und Services berücksichtigen, die zur Ausführung eines Geschäftsprozesses von Anfang bis Ende erforderlich sind. Ohne eine Lösung, die einen Prozess End-to-End orchestrieren kann, können Prozesse fragmentiert und isoliert ausgeführt werden. Diese Fragmentierung führt zu einem Mangel an Transparenz, Integration und Kontrolle des gesamten Prozesses und verlangsamt oder verhindert sogar eine effektive Fehlersuche, Berichterstattung und Analyse. Halten Sie nach einer Lösung Ausschau, die sowohl automatisierte als auch manuelle Aufgaben orchestriert, unabhängig davon, wie viele Anwendungen oder Systeme beteiligt sind.
Unterstützung lang laufender Prozesse
In vielen Unternehmen gibt es Geschäftsprozesse, die stunden-, tage-, wochenlang oder sogar noch länger laufen können. Lang laufende Prozesse führen zu einigen technischen Herausforderungen, z. B. die Verfolgung des Prozesszustands, die Korrelation aller Aktivitäten und Daten im Zusammenhang mit dem Prozess und die Auslösung von Timeouts. Wenn beispielsweise die Zahlung für eine Online-Bestellung fehlschlägt, kann dem Kunden eine bestimmte Anzahl von Tagen eingeräumt werden, um es erneut mit einer anderen Zahlungsmethode zu versuchen.
Die Prozessorchestrierung von Camunda basiert auf dem ISO-Standard BPMN (Business Process Model and Notation), der es Teams ermöglicht, sowohl grafische als auch ausführbare Prozesse zu entwerfen. BPMN bietet integrierte Unterstützung für lang laufende Prozesse und bewältigt automatisch technische Herausforderungen wie Zustandspersistenz, Datenkorrelation und Timeouts. BPMN erleichtert außerdem die Überwachung, Warnmeldungen und Berichterstellung auf Prozessebene, was wichtige Funktionen für die Verwaltung lang laufender Prozesse sind.
Tiefgreifende Prozessanalyse und -optimierung
Die meisten, wenn nicht sogar alle, monolithischen Automatisierungsplattformen stellen Berichte über die von ihnen erfassten Daten zur Verfügung, oft auch Dashboards mit Grafiken zur Visualisierung der Daten. Diesen Berichten fehlt jedoch möglicherweise der Kontext des End-to-End-Geschäftsprozesses, der die vom Monolithen selbst ausgeführten Aufgaben aufruft, was bedeutet, dass die Teams ein unvollständiges Bild der Prozessleistung erhalten. Dieses unvollständige Bild macht es schwierig oder unmöglich, Engpässe und andere Bereiche zu erkennen, in denen das Unternehmen Maßnahmen zur Verbesserung der Prozesse ergreifen kann.
Mit einer Lösung wie Camunda, die Prozesse über alle Personen, Systeme und Geräte hinweg orchestriert, erhalten Sie eine 360-Grad-Sicht auf die Daten zur Prozessausführung. Diese Daten führen zu einer Vielzahl von Analysen mit intuitiven Visualisierungen und Heatmaps, die sowohl für technische als auch für geschäftliche Stakeholder nützlich sind.
Konsistente Visualisierung des Prozessmodells
Viele Automatisierungsmonolithen bieten den Anwendern keine konsistente Prozessmodellvisualisierung für Aufgaben in den Bereichen Design, Überwachung und Optimierung. Wenn das Prozessmodell nur während des Designs sichtbar ist, ist die Zusammenarbeit zwischen den Fachanwendern und der IT-Abteilung eingeschränkt; dies macht es für die Fachanwender viel schwieriger oder sogar unmöglich, laufende Prozesse zu überwachen und über die Prozessleistung zu berichten. Darüber hinaus werden dadurch der organisationsübergreifende Informationsaustausch und die Berichterstattung gegenüber Aufsichtsbehörden erschwert.
Im Gegensatz dazu verfolgt Camunda einen „Ein-Modell“-Ansatz. In der Designphase verwenden Geschäfts- und IT-Anwender BPMN, um komplexe Geschäftsprozesse visuell darzustellen, die direkt von Camundas Workflow Engine, Zeebe, ausgeführt werden. Bei der Überwachung laufender Prozesse sehen die Benutzer Informationen zum Prozesszustand und zu Vorfällen auf demselben Modell überlagert, so dass sie keine technischen Leistungsdaten interpretieren oder Serverprotokolle entziffern müssen. Berichte zeigen historische Prozessausführungsdaten mit der gleichen Visualisierung, einschließlich Heatmaps, die einen intuitiven Einblick in die Prozessleistung ermöglichen.
Zusammenarbeit zwischen IT und Fachbereichen
Alignment zwischen IT und den Fachbereichen ist eine Herausforderung für jedes Unternehmen, insbesondere da die Prozessautomatisierung eine Schlüsselrolle bei der digitalen Transformation spielt. Geschäfts- und IT-Stakeholder haben oft unterschiedliche Ziele, Anreize und Prioritäten. Diese Unterschiede verlangsamen die Kommunikation, verhindern eine Abstimmung der Projektprioritäten und führen zu Implementierungsfehlern.
Wenn Sie eine monolithische Automatisierungsplattform ersetzen wollen, sollten Sie nach einer Lösung wie Camunda suchen, die die weltweit anerkannten Standards BPMN (Business Process Model and Notation) und DMN (Decision Model and Notation) verwendet. Standards stellen eine gemeinsame Sprache dar, die alle Beteiligten verstehen können. So geht zwischen Geschäftsanforderungen und technischer Umsetzung nichts verloren. BPMN und DMN ermöglichen es Geschäftsanwendern, visuelle Prozessdiagramme und Entscheidungstabellen zu erstellen, während technische Anwender die technische Implementierung von automatisierten Prozessen und Entscheidungen durch die Bearbeitung des zugrunde liegenden Codes abrunden können.
Entwicklerfreundlichkeit für komplexe Prozesse
Monolithische Automatisierungsplattformen verfolgen bei der Anwendungsentwicklung einen anbieterspezifischen Ansatz mit dem Ziel, die Menge des zu schreibenden Codes zu minimieren. Kerngeschäftsprozesse sind jedoch komplex und erfordern maßgeschneiderte Lösungen, so dass Unternehmen in Schwierigkeiten geraten, sobald sie Anforderungen umsetzen müssen, die außerhalb der Möglichkeiten ihrer Automatisierungstools liegen. Um technische und funktionale Einschränkungen zu umgehen, müssen Softwareentwickler die anbieterspezifische Art der Automatisierung von Aufgaben erlernen, was Zeit kostet und zu Implementierungen führen kann, die nicht für Leistung, Wartung oder Stabilität optimiert sind.
Camunda wurde speziell für Entwickler entwickelt, so dass diese schnell mit der Automatisierung von Prozessen beginnen können, ohne ein herstellerspezifisches Entwicklungsframework erlernen zu müssen oder gezwungen zu sein, eine proprietäre IDE zu verwenden. Teams können bei der Erstellung, dem Testen und dem Betrieb der von ihnen entwickelten Anwendungen eine vertraute Umgebung verwenden. Sie können zum Beispiel in ihrem bevorzugten Code-Editor arbeiten, in der bevorzugten Sprache programmieren, ihren Code in einem Versionskontrollsystem speichern, ihn automatisch testen, kontinuierliche Integration implementieren und ihre Container-Anwendungen auf einer Plattform wie Kubernetes verwalten. Sie müssen sich nicht an eine Camunda-spezifische Arbeitsweise gewöhnen.
Geringe Gesamtbetriebskosten
Die Gesamtbetriebskosten eines Produkts hängen von zahlreichen Faktoren ab: Lizenzierung, Schulungen, die anfängliche Entwicklungsphase vor der Inbetriebnahme, die Bearbeitungszeit für Änderungen und Neuentwicklungen, die Beauftragung von Beratern für Projekte, die interne Teams nicht abschließen können, die Kosten für die zum Betrieb des Produkts erforderliche Infrastruktur usw. Die meisten monolithischen Automatisierungsplattformen haben den Ruf, hohe Gesamtbetriebskosten zu verursachen. Grund dafür sind lange Anlaufzeiten (die manchmal mehrere Jahre betragen), laufende Beratungsgebühren und hohe Infrastrukturkosten.
Camunda betrachtet die Gesamtbetriebskosten aus mehreren Blickwinkeln:
- Camundas entwicklerfreundlicher Ansatz und die Verwendung offener Standards erleichtern den Einstieg und verkürzen die Time-to-Value, da das IT-Team keine Zeit damit verbringen muss, sich in ein herstellerspezifisches Entwicklungsframework oder proprietäre Entwicklungstools einzuarbeiten.
- Die offene Architektur von Camunda erlaubt es den Teams zu wählen, welche Komponenten sie verwenden möchten, so dass sie Camunda einfach in den bestehenden Tech-Stack des Unternehmens integrieren können.
- Camunda ist eine leichtgewichtige Lösung, die nur wenige Infrastruktur-Ressourcen benötigt und vor Ort oder in einer öffentlichen, privaten oder hybriden Cloud betrieben werden kann.
Skalierbarkeit und Resilienz
Wenn Sie die Migration von einer monolithischen Automatisierungsplattform in Erwägung ziehen, sollten Sie auch bedenken, wie Ihre Geschäftsprozesse in Zukunft skaliert werden müssen. Camundas Workflow Engine der nächsten Generation, Zeebe, ist so konzipiert, dass sie von vornherein für Anwendungsfälle mit hohem Durchsatz geeignet ist. Während herkömmliche Workflow Engines auf einer zentralen Datenbank beruhen, die einen Leistungsengpass verursacht, verwendet Zeebe stattdessen die Event-Streaming-Technologie und bietet damit eine beispiellose Skalierbarkeit und Leistung. Sie verwaltet den Zustand laufender Prozessinstanzen auf eine Weise, die mit hohen Transaktionsvolumina skaliert, ausfallsicher ist und eine gute Skalierbarkeit bietet.
Darüber hinaus verfügt Zeebe über eine verteilte Architektur, die auch bei hoher Auslastung Ausfallsicherheit gewährleistet. Diese verteilte Architektur ist ideal für die Georeplikation, die Daten zusätzlich schützt. Zeebe verteilt die Daten auf alle Broker in einem Cluster und speichert sie direkt auf dem Dateisystem des Servers. Wenn also ein Broker ausfällt — oder ein ganzes Rechenzentrum — kann ein anderer ihn ohne Datenverlust ersetzen.
Ein Buyer´s Guide zur End-to-End-Prozessorchestrierung
Monolithische Automatisierungsplattformen schaffen Silos, die zu fehlerhaften oder ineffizienten End-to-End-Geschäftsprozessen führen können und Sie daran hindern, Ihre strategischen Geschäftsziele zu erreichen. In diesem Leitfaden erfahren Sie, wie Sie feststellen können, ob Ihre Automatisierungstechnik Sie behindert und wie End-to-End-Prozessorchestrierung helfen kann.
Vorbereitung der Migration von einer monolithischen Automatisierungsplattform
Wenn Sie sich entschieden haben, von einer monolithischen Automatisierungsplattform auf eine andere Lösung umzusteigen, müssen Sie sich auf die kulturellen und technischen Veränderungen vorbereiten, die damit einhergehen. An der Prozessautomatisierung sind in der Regel viele verschiedene Stakeholder beteiligt, von Softwareentwicklern und Enterprise Architects bis hin zu Unternehmensleitern und Business Technologists. Daher ist bei dieser Art von Projekten eine Alignment zwischen den IT- und Geschäftsinteressenten erforderlich.
Darüber hinaus sind Initiativen zur Prozessautomatisierung häufig Teil einer größeren technologischen Modernisierungsmaßnahme. Je nach Größe des Unternehmens kann der Migrationsprozess von einigen wenigen IT-Mitarbeitern oder von einem Team des Automatisierungs-CoE (Centers of Excellence) übernommen werden. In jedem Fall ist es wichtig, dass ein fokussiertes Team den Migrationsprozess vorantreibt, idealerweise indem es mit einem PoC (Proof of Concept) beginnt. Der PoC sollte dem Team bei den folgenden Aufgaben helfen:
- Überprüfen, ob ein bestimmter Ansatz oder ein bestimmtes Tool für den Anwendungsfall geeignet ist
- Klären auch sehr detaillierter Fragen vor einem größeren Automatisierungsprojekt
- Vorstellen eines Beispiels, das Stakeholder von einer weiteren umfangreichen Automatisierung überzeugt
Anschließend sollte das Team, das den Migrationsprozess durchführt, Folgendes tun:
- Alle Stakeholder, insbesondere das IT-Team, müssen in die Lage versetzt werden, die Lösung zu nutzen.
- Führungskräften erklären, dass Prozesse womöglich anders aussehen können (einschließlich Benutzeroberflächen und Prozessabläufe)
- Alle zuständigen Teams darin schulen, automatisierte Prozesse anzuzeigen, sodass sie bei Bedarf auch Änderungen anfordern können
Migration von einer monolithischen Automatisierungsplattform zu Camunda
Die technischen Aspekte der Migration von einer monolithischen Automatisierungsplattform zu Camunda sind im Folgenden zusammengefasst. Camunda verwendet den Standard BPMN für die Prozessmodellierung und den Standard DMN für die Entscheidungsmodellierung. Wenn Sie von einer Plattform migrieren, die BPMN und DMN nutzt, wird dies einfacher sein, als wenn die Plattform einen proprietären Ansatz für die Modellierung hat. Dennoch sollten diese Leitlinien als solide Grundlage für die Planung des Übergangs dienen.
Schritt 1: Geschäftsprozessmodelle migrieren oder neu erstellen
Der erste Schritt bei der Ablösung einer monolithischen Automatisierungsplattform ist die Entscheidung, ob Sie Ihre bestehenden Geschäftsprozessmodelle migrieren oder neu aufbauen wollen. Wir empfehlen, Prozessmodelle neu zu erstellen, anstatt sich auf eine automatisierte Konvertierung zu verlassen. Unserer Erfahrung nach ist es oft weniger zeitaufwendig, Modelle neu zu erstellen, als ein automatisiertes Konvertierungstool zu entwickeln und gründlich zu testen. Die Neuerstellung von Modellen bietet Ihnen auch die Möglichkeit, Prozesse zu verbessern, die seit Jahren nicht mehr überarbeitet wurden, und die volle Leistungsfähigkeit des Prozessmodellierungsstandards BPMN zu nutzen. Wenn Sie während eines PoCs einen Prozess nach dem anderen neu aufbauen, erhalten Sie eine Vorstellung davon, wie viel Zeit und Aufwand die Migration von Prozessmodellen in Ihrer Umgebung erfordert.
In manchen Fällen kann es sinnvoll sein, die vom Camunda-Consulting-Team erstellten Tools zu nutzen, um Prozessmodelle von monolithischen Automatisierungsplattformen zu migrieren. Sie finden diese Tools auf GitHub. Denken Sie daran, dass es sich bei den Tools um eine Art Assistenten handelt. Keines von ihnen ist ein Allheilmittel, mit dem sich die Automatisierung mit einem einzigen Klick von einem Tool auf ein anderes übertragen lässt. Stattdessen wird eine BPMN-Datei generiert, die versucht, die Genauigkeit des ursprünglichen Prozessmodells beizubehalten. Je nachdem, von welchem Tool Sie migrieren, müssen Sie noch Code und Camunda Connectors hinzufügen, um den Prozess ausführbar zu machen.
Schritt 2: Laufende Prozessinstanzen migrieren
Wenn Sie lang laufende Geschäftsprozesse haben, werden Sie feststellen, dass die Migration laufender Prozessinstanzen unvermeidlich ist. Für die Migration von Prozessinstanzen gibt es zwei Ansätze.
Parallelbetrieb
Beim Ansatz des Parallelbetriebs wird der Automatisierungsmonolith so lange betrieben, bis keine Prozessinstanzen mehr vorhanden sind. In der Zwischenzeit starten Sie neue Prozessinstanzen auf Camunda. Dazu müssen Sie eine Umschaltlogik implementieren, um den Datenverkehr von eingehenden Anfragen an das alte oder neue System weiterzuleiten. Bedenken Sie, dass Sie auf beiden Systemen Betriebsaufgaben wie die Fehlerprüfung, die Berechnung von KPIs und die Zählung von Instanzen durchführen müssen.
Der Vorteil dieses Ansatzes ist, dass Sie sich diesen Schritt ersparen, da Sie die laufenden Prozessinstanzen nicht migrieren müssen. Außerdem ist das Risiko, das mit der Inbetriebnahme von Camunda verbunden ist, geringer, da das alte System noch in Betrieb ist.
Der Nachteil dieses Ansatzes ist, dass der Parallelbetrieb von zwei Systemen über einen längeren Zeitraum hinweg Aufwand bedeutet. Die Umschaltlogik lässt sich normalerweise nicht einfach für alle Sonderfälle implementieren und testen. Außerdem könnte es vielleicht passieren, dass das Team nicht benachrichtigt wird, wenn man unbedingt die alten Tools loswerden und neue einsetzen möchte.
Big-Bang-Ansatz
Beim Big-Bang-Migrationsansatz stoppen Sie den Automatisierungsmonolithen und stellen sicher, dass alle Prozessinstanzen einen Wartezustand erreicht haben. Dann migrieren Sie alle Instanzen zu Camunda. Dieser Ansatz erfordert die Abbildung aller möglichen Wartezustände aus alten Prozessmodellen auf BPMN-Prozessdefinitionen, das Auslesen der Daten aus dem alten System und die Ausführung eines Migrationsskripts, um neue Prozessinstanzen in Camunda im richtigen Zustand zu erzeugen. Danach starten Sie das neue System.
Der Vorteil dieses Ansatzes ist, dass Sie nach der Migration nur noch ein System betreiben müssen und die Migration vorher testen können, um böse Überraschungen zu vermeiden. Aus diesem Grund wird der Big-Bang-Ansatz häufig dem Parallelbetrieb vorgezogen.
Der Nachteil ist, dass die Implementierung und das Testen des Migrationsskripts Entwicklungsaufwand erfordert. Außerdem erfordern die Laufzeit der Migrationsskripte und zusätzliche Integritätsprüfungen im Anschluss daran oft eine Ausfallzeit des Systems. Um Prozessinstanzen im richtigen Zustand zu erstellen, möchten Sie währenddessen keine Serviceaufgaben auslösen oder auf menschliche Interaktion warten. Auch kann der gewünschte Zustand in einer Hierarchie von Teilprozessen existieren. Diese Faktoren können das Migrationsprojekt komplexer machen und möglicherweise erfordern, dass Sie Elemente zu Ihren BPMN-Prozessmodellen hinzufügen, nur um die Migration zu ermöglichen (wenn die Camunda API allein nicht ausreicht).
Fallstudie: Zustimmung der Stakeholder sichern
Für Indiana Farm Bureau Insurance war die Zustimmung der Stakeholder ein entscheidender erster Schritt bei der Migration von einem Automatisierungsmonolithen zu einer komponierbaren Lösung auf Basis von Camunda. Das Entwicklungsteam hatte ausgiebig mit der vorherigen Plattform gearbeitet und vertrat ursprünglich die Mentalität „wenn alles funktioniert, sollte man auch nichts verschlimmbessern“. Außerdem wollten erfahrene, Senior Developer sicher sein, dass ihre Arbeit geschätzt wird und dass sie etwas liefern, das für den Endbenutzer des Unternehmens von Nutzen ist.
Jarvis Ka, Enterprise Architect bei Indiana Farm Bureau Insurance, betonte, wie wichtig es ist, mit dem Entwicklungsteam den Zeitrahmen festzulegen, der benötigt wird, um eine End-to-End-Lösung zur Prozessorchestrierung in Produktion zu bringen. Der Scrum Master und der Projektmanager müssen ihre Erwartungen anpassen. Viele Stakeholder auf Managementebene nehmen Veränderungen nur ungern vor. Daher ist es wichtig zu erklären, wie die bestehenden Prozesse in das neue System überführt werden. So könnte sich beispielsweise ein Abteilungsleiter Gedanken darüber machen, wie sich die Benutzererfahrung (UX) ändern könnte, wenn Benutzer auf dem Mobiltelefon einen Versicherungsanspruch einreichen.
Um den Widerstand zu verringern und diese Änderungen zu demonstrieren, teilten Ka und sein Team BPMN-Prozessmodelle, die während der PoC-Phase erstellt wurden, und versahen sie mit Informationen, die jede Aufgabe im Prozess beschrieben. Anschließend erstellten sie PDFs und schickten sie an die einzelnen Stakeholder. Diese asynchrone Kommunikation reduzierte die Anzahl der erforderlichen teamübergreifenden Meetings, da alle Beteiligten eine visuelle Darstellung der Prozesse in der neuen Lösung erhielten.
Fallstudie: Umstellung von einem Monolithen auf Microservices
Die Deutsche Telekom hatte ein monolithisches Prozessautomatisierungssystem, das Problemen verursachte, die das Geschäft und die Benutzerfreundlichkeit beeinträchtigten:
- Eine lange Time-to-Market von mehr als 12 Monaten
- Die Abhängigkeit von einem bestimmten Anbieter schränkte die Implementierung neuer Funktionen ein – es dauerte fünf Tage, um Umgebungen einzurichten oder zu ändern.
- Releases nahmen in der Regel 1.000 Personentage oder ungefähr drei Monaten in Anspruch.
- Die Bearbeitung aller Testfälle in einem Regressionstest dauerte zwei Tage
„Wir müssen zeitnah reagieren. Wir können nicht sieben Tage warten, um eine Bestellung zu bearbeiten oder um auf etwas zu antworten. Wir müssen immer vorausdenken und verantwortlich bleiben“, erklärte Willm Tüting, Managing Director, conology GmbH, der über 15 Jahre lang mit der Deutschen Telekom IT zusammengearbeitet hat.
Die Grundlagen für Veränderungen schaffen
Die IT der Deutschen Telekom unternahm erste Schritte zur Modernisierung ihrer Prozesse, indem sie einen „teilagilen“ Entwicklungsansatz einführte und in dreimonatigen Sprints arbeitete. „Wir haben mehrere Prozesse entwickelt, um kleine Korrekturen schneller bereitzustellen, aber das trug zu Komplexität bei“, so Tüting.
Alle Fixes mussten zusammen mit größeren Änderungsanforderungen bereitgestellt werden, was zahlreiche Personenstunden in Anspruch nahm. Darüber hinaus hatte die Organisation immer noch mit dem monolithischen Automatisierungssystem zu kämpfen, das keine echte Agilität zuließ.
Zur selben Zeit begann die Deutsche Telekom, in Glasfaserkabel zu investieren. Mit diesem bedeutenden Hardware-Upgrade ergab sich die Gelegenheit, die veralteten Systeme der Telekom-IT zu revolutionieren. Das Ergebnis war ein kompletter Wechsel sowohl des Betriebssystems als auch des DevOps-Ansatzes, der von drei Zielen geleitet wurde:
- Schnelligkeit: Umstellung der Entwicklung von Business Process Execution Language (BPEL) auf Java und der Arbeitsweise der Teams von Waterfall auf agil
- Entwicklung funktionsübergreifender Teams: Wechsel von fachspezifischen Teams zu internationalen, funktionsübergreifenden Teams
- Effizienzsteigerung: Steigerung der Entwicklungseffizienz durch den Einsatz von Camunda, Spring Boot und anderen modernen Technologien und Verfahren.
Vom Monolithen zu Microservices in der Cloud
Mit diesen drei Zielen vor Augen implementierte die Deutsche Telekom IT eine Microservices-basierte Architektur in der Cloud, wobei die Camunda-Engines innerhalb vieler Services laufen. Laut Friedbert Samland, Projektleiter bei der Deutschen Telekom IT, besteht das neue System aus folgenden Komponenten:
- Microservices: Sie partitionieren den Monolithen und ermöglichen eine funktionsübergreifende Arbeit. Es gibt keine grafische Benutzeroberfläche; stattdessen handelt es sich jetzt um ein reines BPMN-System. „Inspiriert von Bernd Rückers (Mitbegründer von Camunda) Microservices Workflow Automation Cheat Sheet setzt das Team Camunda-Engines in vielen Microservices ein, die direkt mit einem Message Broker kommunizieren“, sagte Friedbert.
- Cloud: Die Leistungsfähigkeit der Cloud verkürzt die Laufzeiten drastisch und ermöglicht einen abgestuften, detaillierten Bereitstellungsansatz. Da es keine vorgefertigte Lösung gab, entwickelte die Deutsche Telekom IT einen eigenen Kubernetes-basierten Ansatz.
- Scaled Agile Framework (SAFe): Die Einführung eines neuen organisatorischen Frameworks mit kürzeren End-to-End-Zykluszeiten ermöglichte Flexibilität und Geschwindigkeit.
- DevOps-Philosophie: Automatisierung und Self-Service sichern Qualität und Geschwindigkeit und sind der Schlüssel zur DevOps-Philosophie der Deutschen Telekom IT.
Alignment in der Prozessautomatisierung
Einer der größten Vorteile des Einsatzes von Camunda bei der Deutschen Telekom IT ist die Ermöglichung von „Compliance-by-Default. Als global verteiltes Unternehmen mit Teams, die weltweit mit verschiedenen Anbietern und vertraulichen Daten arbeiten, war eine hochautomatisierte Lösung erforderlich. Die daraus resultierende Architektur ermöglicht nun „Compliance-by-Default“ und gewährleistet Datensicherheit.
In Anlehnung an das Token-Konzept von Camunda Operate hat die Deutsche Telekom IT zudem eine eigene interne Prozess-Monitoring-Plattform aufgebaut, die den Anwendern einen Überblick über den Fortschritt eines jeden Prozesses gibt.
Abgesehen von der Unterstützung und Umsetzung einer hochflexiblen DevOps-Philosophie hat Camunda die IT der Deutschen Telekom in die Lage versetzt, komplexe Logik an einem Ort zu visualisieren, manuelle und automatisierte Aufgaben einfach aufeinander abzustimmen und die gleiche BPMN-Sprache für Business- und IT-Abteilungen zu verwenden.
Für diejenigen, die mit dem Gedanken spielen, in die Fußstapfen der Deutschen Telekom IT zu treten, hat Tüting weisen Rat: „Wählen Sie Ihren Stack mit Bedacht. Beginnen Sie nicht mit einem kompletten Stack, sondern wählen Sie die Komponenten aus, die Ihren Bedürfnissen am meisten entsprechen. Setzen Sie sich große Ziele, aber fangen Sie klein an, Versuchen Sie nicht, den heiligen Gral auf Anhieb zu erreichen – gehen Sie einfach auf Ihr Ziel zu.“
Fallstudie: Schrittweise Migration bei einem großen Finanzdienstleister
Das Beratungsunternehmen Doculabs arbeitet mit vielen großen Finanzdienstleistern zusammen, um ihre IT-Systeme zu modernisieren. Viele dieser Unternehmen haben die Prozessautomatisierung auf monolithischen Automatisierungsplattformen aufgebaut. Wenn Lösungen mit der Zeit im Umfang wachsen, werden sie fehleranfällig und Änderungen lassen sich nur schwer vornehmen. Ein großes Finanzdienstleistungsunternehmen wollte seine Front-Office- und Back-Office-Prozesse überarbeiten — von der Eröffnung neuer Konten und Geldbewegungen bis hin zu Compliance-Workflows. Im Idealfall wollte man auf eine Cloud-basierte Prozessorchestrierungsplattform umsteigen, die über angemessene Sicherheits- und Governance-Kontrollen verfügt.
Der erste Schritt bestand darin, eine Bestandsaufnahme aller Geschäftsprozesse im gesamten Unternehmen vorzunehmen und sie jeweils in die Kategorien „klein“, „mittel“ oder „groß“ einzuordnen. Um Prozesse auf diese Weise einzuordnen, mussten die Teams die Regeln, Entscheidungspunkte, Integrationen und die Anzahl der Berichte, die in den Workflows enthalten sind, sowie die ungefähren Kosten der einzelnen Workflows überprüfen. Das Team kam zu dem Schluss, dass die größten anfänglichen Erfolge durch die Neuerstellung der Prozesstypen mit dem höchsten Volumen von Grund auf erzielt werden könnten. Im Gegensatz dazu schätzte das Team, dass die Migration vieler weniger umfangreicher, täglich genutzter Prozesse den größten Zeit- und Arbeitsaufwand erfordern würde. Ruhende Prozesse mit geringem oder keinem Volumen wurden ganz stillgelegt.
Auf dieser Grundlage entwickelte das Doculabs-Team einen Business Case für die Ablösung vom Automatisierungsmonolithen. Sie positionierten die Migration als Teil eines größeren Modernisierungsprojekts und erörterten die Vorteile einer modernen Plattform zur Automatisierung von Geschäftsprozessen sowohl für die Endbenutzer (Verbraucher) als auch für die Mitarbeiter des Unternehmens. Mit einer neuen, auf Camunda basierenden Lösung könnte das Team die Art und Weise ändern, wie das Unternehmen seine Kunden bedient, den manuellen Arbeitsaufwand bei Schlüsselprozessen reduzieren und Arbeitsabläufe schneller abschließen.
Nachdem das Doculabs-Team zunächst die Zustimmung der Unternehmensleitung des Finanzdienstleisters eingeholt hatte, plante es PoCs in der gesamten Organisation, um aufzuzeigen, wie der neue Ansatz funktioniert. Doculabs machte sich ein Bild der bestehenden Prozesse, analysierte und priorisierte die einzelnen Workflows und verlagerte jeden Prozess in die neue Umgebung, wobei eine Reihenfolge der Prioritäten festgelegt wurde. Mithilfe des PoC-Ansatzes experimentierte das Team damit, Workflows aus dem monolithischen System herauszulösen und auf die Camunda-basierte Plattform zu migrieren. Außerdem wurden bestimmte Arbeitsabläufe überarbeitet, bevor sie in die neue Umgebung migriert wurden.
Im Großen und Ganzen arbeitete das Team wie folgt:
- Wenn der Prozess nicht funktioniert oder die Technologie unzureichend ist, muss er überarbeitet und neu erstellt werden.
- Wenn der Prozess funktioniert, aber die Technologie unzureichend ist, erstellen Sie ihn neu (vereinfachen, standardisieren und wiederverwenden, wo immer möglich).
- Wenn ein Prozess funktioniert und die Technologie angemessen ist, migrieren Sie den Prozess so wie er ist (so weit wie möglich).
Nachdem Doculabs die Prozesse von seiner alten monolithischen Automatisierungsplattform auf die Cloud-basierte Plattform von Camunda migriert hatte, konnte das Unternehmen eine sofortige Verbesserung der Zusammenarbeit zwischen den Fachabteilungen und der IT feststellen. Durch die Verwendung von BPMN als gemeinsame Sprache und Kommunikationstool können sowohl die IT als auch Fachabteilungen leicht erkennen, wie Prozesse funktionieren und wie sie verbessert werden können. Die neue Plattform ermöglichte es dem Unternehmen außerdem, automatisierte Aufgaben und die von Menschen gemeinsam ausgeführte Arbeit auf einheitliche Weise zu orchestrieren.
Camunda Best Practices Hub
Sind Sie bereit, mit der Migration zu beginnen? Der Camunda Best Practices Hub bietet detaillierte Ratschläge zur Auswahl eines Tech-Stacks, zur Modellierung von Geschäftsprozessen, zur Durchführung eines PoC und mehr.
Fallstudie: Erkenntnisse aus einer erfolgreichen Migration
Die Swiss Re (Schweizerische Rückversicherungs-Gesellschaft) hat mithilfe von Camunda erfolgreich von einer monolithischen Automatisierungsplattform auf eine auf Microservices basierende Prozessorchestrierung migriert. Hier sind einige der wichtigsten Erkenntnisse, die sie aus ihrer Migration gewonnen hat:
- Bleiben Sie dran. Es reicht nicht aus, die entsprechenden Informationen an die Stakeholder weiterzugeben und zu erwarten, dass alles sofort verstanden wird. Ziel ist es, dass alle Beteiligten die mit der Migration verbundenen Abhängigkeiten und Zeitpläne verstehen. Dies geschieht, wenn die Kommunikation nicht unterbrochen wird und kontinuierlich stattfindet.
- Versuchen Sie, die Prioritäten der Stakeholder-Teams im Unternehmen zu verstehen. Jedes Team hat seine eigenen Projekte und Prioritäten. Diese zu Beginn des Migrationsprozesses abzustimmen, hilft bei der Planung.
- Seien Sie optimistisch und vertrauen Sie dem Entwicklungsteam. Lösen Sie sich von alten Paradigmen und Annahmen. Vertrauen Sie darauf, dass Ihr Team sich auf neue Arbeitsweisen einstellen kann. Im Fall von Swiss Re wechselten engagierte BPM-Entwickler zu Camunda und waren gespannt darauf, neue Kenntnisse in der Cloud-nativen Entwicklung zu gewinnen.
- Seien Sie pessimistisch bei der Planung. Die Migration bei Swiss Re wurde durch die Covid-19-Pandemie sowie durch Ausfälle der Mitarbeiter verzögert. Mit anderen Worten: Erwarten Sie das Unerwartete.
- Seien Sie realistisch, was möglich ist. Das bedeutet, Prioritäten für das festzulegen, was jetzt machbar ist und was erst in Zukunft. Swiss Re hat beispielsweise eine Roadmap für selbstheilende Anwendungen erstellt, die Benutzerbasis erweitert und Superusern die Erstellung von Prozessen in Camunda ermöglicht. Darüber hinaus sollen die Berichtsfunktionen verbessert werden, damit die Benutzer erkennen können, wo Prozesse verbessert werden müssen.
Schlussfolgerung
Mit Camunda können Sie Prozesse mit größerer Agilität, mehr Transparenz, besserer Kontrolle und geringeren Gesamtbetriebskosten automatisieren und optimieren. Camundas End-to-End-Prozessorchestrierungsplattform hilft Ihnen, die Herausforderungen von Automatisierungsmonolithen zu überwinden und bietet die Agilität, die Sie brauchen, um Ihre Unternehmensarchitektur für die Zukunft weiterzuentwickeln.
Wenn Sie die Entscheidung getroffen haben, von einer monolithischen Automatisierungsplattform zu Camunda zu migrieren, dann herzlichen Glückwunsch! Die Modernisierung dieser starren Systeme zu einer zusammensetzbaren Prozessorchestrierungslösung wie Camunda kann zu einem besseren Kundenerlebnis, einer höheren Teamproduktivität und einer schnelleren Markteinführung führen.
Sollten Sie dabei Hilfe benötigen, wenden Sie sich an Camunda Consulting. Wir haben vielen Unternehmen aus verschiedenen Branchen geholfen, von monolithischen Automatisierungsplattformen auf Camunda zu migrieren. Wir unterstützen Ihr Team gerne dabei, den gesamten Migrationsprozess vom PoC bis zum erfolgreichen Produktionsstart zu durchlaufen.
