Der ultimative Leitfaden zur Migration von Legacy-BPMS (Business Process Management Suiten)

Vorteile, wichtige Überlegungen und die technischen Schritte einer erfolgreichen Migration von BPMS

Leitfaden zur Migration von Legacy-BPMS zu Camunda

Als Unternehmen erstmals damit begannen, Geschäftsprozesse zu automatisieren, haben viele möglicherweise eine traditionelle Business Process Management Suite (BPMS) erworben. Mit der Zeit stellte man aber fest, dass sich diese nicht für die moderne Prozessautomatisierung eignet, die Agilität, Skalierbarkeit und Offenheit erfordert. Seit dem Aufkommen von Cloud-Infrastruktur, Containern und Microservices-basierter Anwendungsentwicklung stellt die fehlende Flexibilität von Legacy-BPMS ein Hindernis für eine fortschrittliche und innovative Entwicklung dar. Wenn Legacy-Technologie nicht auf den neuesten Stand gebracht wird, kann sie zu ineffektiven oder verzögerten Kundenerlebnissen führen.

Was ist der Grund? Legacy-BPMS, die auch als iBPMS bezeichnet werden, basieren auf geschlossenen Architekturen und einem proprietären Entwicklungsansatz, was die Flexibilität des Unternehmens einschränkt und Änderungen schwierig und teuer macht. Diese Systeme sind nicht in der Lage, dynamisch auf den Geschäftsbedarf zu reagieren, was bedeutet, dass sie oft Leistungsprobleme verursachen, die sich negativ auf die Kunden auswirken. Zudem bieten sie nicht die Tools, die Teams zur kontinuierlichen Prozessoptimierung benötigen.

Ein moderner Ansatz für die Prozessautomatisierung bietet Entwicklern eine offene, API-basierte Architektur, mit der sie die gewünschten Tools unter ihren Bedingungen nutzen können. Anstatt von einer proprietären Entwicklung abhängig zu sein, erleichtert dieser Ansatz den Prozessentwurf und beschleunigt diesen, indem der weithin bekannte Prozessmodellierungsstandard BPMN verwendet wird. Sobald die Prozesse modelliert sind, „steuert“ eine universelle Orchestrierungsschicht selbst die komplexesten Prozesse – über Mitarbeiter, Systeme und Geräte hinweg. Die Prozessorchestrierung ist so konzipiert, dass sie sowohl kurz- als auch lang laufende Geschäftsprozesse unterstützt, die über Stunden, Tage, Wochen oder sogar Monate hinweg laufen.

Wenn Ihr Unternehmen also ein Legacy-BPMS verwendet, was sind die wichtigsten Überlegungen, die vor der Migration zu berücksichtigen sind? Wie beginnen Sie mit der Migration zu einer modernen Prozessorchestrierungslösung wie Camunda? Dieser Leitfaden führt Sie durch die Schritte einer erfolgreichen Migration, einschließlich der kulturellen und technischen Aspekte der digitalen Transformation. Legen wir los.

Wichtige Überlegungen zum Ersatz von BPMS

Für viele Organisationen kann die Überwindung der Untätigkeit das größte Problem bei der Ablösung eines bestehenden BPMS sein. Eine Migration scheint zu viel Zeit und Aufwand in Anspruch zu nehmen. Und es mag schwierig erscheinen, komplexe, lang laufende Prozesse zu unterbrechen, um sie auf eine andere Plattform zu verschieben. Aber eine temporäre Modernisierung ist meistens besser als einfach nichts zu tun.

Whitepaper herunterladen: Ersatz von Legacy-BPM: Entscheidende Faktoren für die Auswahl einer neuen Lösung

In diesem Leitfaden werden wir uns Beispiele von Unternehmen ansehen, die ihre Migrationen erfolgreich abgeschlossen haben. Sie werden feststellen, dass viele dieser Unternehmen ihre Prozesse auf jahrzehntealten, monolithischen Systemen laufen ließen, die den Entwicklungslebenszyklus verlangsamten. Die Deutsche Telekom realisierte, dass die Entwicklung neuer Funktionen für Kunden über 12 Monate dauern würde. Zudem schränkte die fehlende Flexibilität des alten Anbieters das Unternehmen weiter ein. In allen Fällen bestand die Notwendigkeit zur Migration nicht nur weil die Entwicklungszeit verkürzt werden sollte, sondern auch weil die hohen Kundenerwartungen erfüllt und übertroffen werden sollten.

Daher ist es wichtig, die Funktionen und Vorteile einer neuen Prozessautomatisierungs- und Orchestrierungslösung zu bewerten. Hier sind einige der wichtigsten Faktoren, die im Hinblick auf Technologieanbieter berücksichtigt werden müssen.

Quelle: PeerSpot; Ersatz von Legacy-BPM: Entscheidende Faktoren für die Auswahl einer neuen Lösung; 2021

Schnellere Entwicklung und Bereitstellung von Prozessen

Anstatt Monate oder Jahre auf die Entwicklung und Bereitstellung eines neuen Prozesses warten zu müssen, sollte eine neue Lösung die Entwickler befähigen, schnell zu handeln und die branchenüblichen Best Practices für die kontinuierliche Bereitstellung zu ermöglichen. Wenn Sie eine Lösung zur Prozessautomatisierung und -orchestrierung evaluieren, sollten Sie in der Lage sein, schnell einen Proof of Concept (PoC) einzurichten, um die Effizienz der Lösung zu bewerten – je nach Komplexität des Prozesses sogar innerhalb von ein paar Tagen bis zu einer Woche. Wir werden später mehr über den PoC-Prozess berichten. Danach sollte klarer sein, wie Sie Ihre bestehenden Prozesse migrieren (falls möglich) oder optimieren können, damit sie in einer neuen Umgebung effektiv funktionieren.

Einfachheit mit BPMN und DMN

Suchen Sie nach einer Lösung, die offene Standards wie BPMN und DMN (Decision Model and Notation) unterstützt. Diese Standards vereinfachen die Definition von Prozessen, Regeln und Workflows, sodass diese Konzepte sowohl für Stakeholder aus der IT als auch in den operativen Abteilungen leichter zu verstehen sind. Eine Plattform sollte auch eine kontinuierliche Prozessoptimierung ermöglichen, damit Engpässe in Prozessen leicht erkannt und schnell behoben werden können.

Diese Einfachheit hilft bei den ersten Schritten, beim Änderungsmanagement und bei der Wartung. Im Idealfall sollte ein neues System bestehende Teams stärken und für den Betrieb kein proprietäres Fachwissen erfordern. Tatsächlich sollten die Gesamtbetriebskosten der neuen Lösung dank ihrer Benutzerfreundlichkeit viel niedriger sein als bei Legacy-BPMS.

Flexibilität und Zusammenarbeit

Mit zunehmendem Aufkommen von Remote-Arbeit und international verteilten Teams werden Flexibilität und Kollaboration besonders wichtig. Mit den BPMN- und DMN-Standards sollten Teams in der Lage sein, zusammenzuarbeiten, Logik zu Prozessregeln auszutauschen und vieles mehr, und zwar unabhängig von ihrem Standort oder ihrem Fachwissen. Prozessorchestrierungstools sollten auf diese Weise nahtlos in den vorhandenen Toolchains der Entwickler funktionieren, einschließlich einer bevorzugten IDE oder eines Versionskontrollsystems wie Git. Diese Lösungen passen idealerweise gut in einen modernen, agilen Software Development Lifecycle (SDLC).

Offene, API-zentrierte Architektur

Bei der Auswahl einer neuen Lösung ist die Entwicklerfreundlichkeit entscheidend. Neben den oben erwähnten offenen Modellierungsstandards sollte eine Plattform auch Software-Kommunikationsprotokolle und -standards wie JSON und offene APIs unterstützen. APIs bieten einen schnellen und einfach zu ändernden Ansatz für die Headless-Prozessautomatisierung. Darüber hinaus machen sie eine Plattform mit den gewünschten Tools erweiterbar. Achten Sie auf ein modulares Design, das in einer Public, Private oder Hybrid Cloud ausgeführt werden kann und mit modernen Technologien wie Kubernetes und Kafka kompatibel ist.

Vorbereitung Ihres Unternehmens auf die BPMS-Migration

Wenn Sie sich für eine BPMS-Migration entschieden haben, ist es wichtig, sich sowohl auf die kulturellen als auch auf die technischen Veränderungen vorzubereiten. In der Regel sind viele verschiedene Stakeholder an der Prozessautomatisierung beteiligt, darunter Entwickler, IT-Enterprise-Architekten, IT-Entscheidungsträger und verschiedene Führungskräfte. Daher ist bei dieser Art von Projekten eine Abstimmung zwischen den IT- und Business-Abteilungen erforderlich.

Für die Indiana Farm Bureau Insurance war der Buy-In der Stakeholder ein wichtiger erster Schritt, um die Migration einzuleiten. Das Entwicklungsteam hatte ausgiebig mit dem vorherigen BPMS gearbeitet und hatte ursprünglich eine „Reparier es nicht, wenn´s nicht kaputt ist”-Mentalität. Um diese Einstellung zu ändern, war es wichtig, dem Team die großen geschäftlichen Vorteile klar vor Augen zu führen. Erfahrene leitende Entwickler wollten zum Beispiel wissen, dass ihre Arbeit von Bedeutung ist und dass sie etwas Nützliches für den Endbenutzer des Unternehmens liefern.

Als Nächstes machte sich das Team mit Hilfe eines Consultants an seinen ersten Prozessdesign-PoC. Ein PoC sollte einem Team bei den folgenden Punkten helfen:

• Überprüfung, ob ein bestimmter Ansatz oder ein Tool in einem Szenario funktionieren
• Vorstellen eines Beispiels, das Stakeholder von einer weiteren umfangreichen Automatisierung überzeugt
• Klärung auch sehr detaillierter Fragen vor einem größeren Projekt

Weitere Infos: Doing a Proper PoC

Jarvis Ka, Enterprise Architect bei Indiana Farm Bureau Insurance, betonte, wie wichtig es ist, mit dem Entwicklungsteam zu besprechen, wie lange es dauert, ein End-to-End-Prozessautomatisierungssystem in Betrieb zu nehmen. Dazu müssen die Erwartungen sowohl des Scrum-Masters als auch der Projektleiter übereinstimmen. Viele dieser Stakeholder auf Managerebene nehmen Änderungen möglicherweise nicht gerne an. Daher ist es wichtig, zu erklären, wie bestehende Prozesse in das neue System überführt werden sollen. Zum Beispiel könnte ein Abteilungsleiter Bedenken haben, wie sich die Benutzererfahrung (UX) für den Endbenutzer ändert, wenn er einen neuen Versicherungsanspruch über das Mobiltelefon einreicht.

Um die Akzeptanz zu erhöhen und die Neuerungen darzustellen, markierten Ka und sein Team die während der PoC-Phase erstellten BPMN-Diagramme und versahen sie mit weiteren Informationen, die jede Aufgabe im Prozess beschrieben. Anschließend erstellten sie PDFs und schickten sie an jeden Stakeholder des Unternehmens. Auf diese Weise waren weniger Meetings erforderlich, da eine visuelle Darstellung der Prozessabläufe im neuen Prozessautomatisierungs- und Orchestrierungssystem vorhanden war.

Häufig sind Migrationen zur Prozessautomatisierung Teil eines größeren IT-Modernisierungsprojekts. Je nach Größe des Unternehmens kann der Migrationsprozess entweder von einem größeren Center of Excellence (CoE) oder nur von einigen wenigen IT-Stakeholdern, wie einem IT-Enterprise-Architekten und einem kleinen Team von Entwicklern, durchgeführt werden. In jedem Fall ist es wichtig, dass ein fokussiertes Team den Migrationsprozess vorantreibt, der idealerweise mit einem kleinen PoC beginnt. Die Aufgaben dieses Teams umfassen dann u. a.:

• Entwicklungsteam für die Verwendung des neuen Systems schulen
• Führungskräften erklären, dass Prozesse womöglich anders aussehen können (einschließlich Benutzeroberflächen und Prozessabläufe)
• Zuständige Teams in der Verwendung der automatisierten Prozesse schulen, sodass sie bei Bedarf auch Änderungen anfordern können

Technische Schritte zur Durchführung der BPMS-Migration

Der folgende Leitfaden richtet sich an Unternehmen, die von Legacy- BPMS auf Camunda migrieren, die den Standard BPMN 2.0 für die Prozessdefinition und -bereitstellung verwendet. Wenn Sie von einem BPMN-basierten System zu Camunda migrieren, wird die Umstellung viel einfacher verlaufen, als mit proprietären BPMS-Prozessdefinitionen. Nichtsdestotrotz sollte dieses allgemeine Framework als gute Grundlage für die Migration dienen.

Schritt 1: Migration der Prozessdefinitionen

In der Regel ist es besser, bestehende Prozesse umzugestalten, als eine automatisierte Umstellung vorzunehmen. Oft ist die Anzahl der Prozessdefinitionen begrenzt. Das bedeutet, dass die Umgestaltung von Prozessen oft weniger Zeit in Anspruch nimmt als das Erstellen und Testen der automatisierten Umstellung. Wenn Sie einen Prozess nach dem anderen modellieren (z. B. indem Sie den Prozess für einen PoC abschließen), erhalten Sie ein besseres Gefühl dafür, wie viel Aufwand die Migration von Prozessdefinitionen in Ihrer Umgebung mit den vorhandenen Mitarbeitern erfordert.

Durch die Neugestaltung der Prozesse können Sie auch die Möglichkeiten von BPMN 2.0 voll ausschöpfen und bestehende Prozesse optimieren, die möglicherweise seit Jahren nicht mehr überarbeitet wurden.

In einigen Fällen kann es sinnvoll sein, die vom Camunda Consulting-Team entwickelten Tools zur Migration von Prozessabläufen aus IBM BPM, IBM Blueworks Live, Oracle, Pega und TIBCO zu verwenden. Diese Migrations-Shortcuts können Sie hier auf GitHub finden. Um es jedoch klar auszudrücken: Keines dieser Tools ist als Allheilmittel gedacht, mit dem sich Anwendungen auf Knopfdruck von einem Anbieter auf einen anderen übertragen lassen.

Typischerweise erzeugen diese Werkzeuge eine BPMN-Datei, die versucht, die Genauigkeit des ursprünglichen Prozessdiagramms beizubehalten. Die Camunda-Migrationstools nutzen die Camunda Model APIs, um die BPMN-Datei zu erstellen. Wenn Sie den Quellcode zur Verfügung haben, können Sie die Tools bei Bedarf erweitern.

Je nach Anbieter, von dem Sie migrieren, müssen Sie noch Komponenten (Code, Skripte usw.) hinzufügen, um den Prozess ausführbar zu machen.

Weitere Infos: Migrating processes from Pega to Camunda 

Migrating process BPMN from IBM BPM to Camunda

Schritt 2: Migration der Prozessinstanzen

Die Migration von Prozessinstanzen (oder der darin enthaltenen Daten) ist unvermeidlich, wenn Sie über lang laufende Prozesse verfügen, da einige dieser Prozesse ununterbrochen laufen. Der schwierige Teil besteht darin, die Daten aus der bestehenden BPMN-Plattform zu extrahieren. Es gibt zwei grundlegende Ansätze für die Migration von Prozessinstanzen:

1. Paralleler Betrieb: Bei diesem Ansatz betreiben Sie die alte Lösung so lange, bis dort keine Prozessinstanzen mehr vorhanden sind. In der Zwischenzeit starten Sie neue Prozessinstanzen auf Camunda. Dazu müssen Sie eine Umschaltlogik implementieren, um den Verkehr von eingehenden Anfragen an das alte oder neue System zu leiten. Denken Sie daran, dass Sie beide Systeme parallel betreiben müssen, z. B. um Ausfälle zu überprüfen, KPIs zu berechnen oder Instanzzählungen durchzuführen.

   PRO: Da Sie die laufenden Prozessinstanzen nicht migrieren müssen, sparen Sie sich diesen Schritt. Außerdem ist das Go Live mit Camunda in der Regel weniger riskant, da das alte System noch in Betrieb ist.

   CONTRA: Der Parallelbetrieb zweier Systeme über einen längeren Zeitraum erfordert zusätzlichen Aufwand. Die Umschaltlogik ist in der Regel nicht einfach zu implementieren und für alle Ausnahmefälle zu testen. Außerdem könnte die Motivation des Teams gefährdet sein, da die Mitarbeiter möglicherweise darauf erpicht sind, das alte System schnell aufzugeben und weiterzumachen.

2. Big Bang-Migration: Bei diesem Ansatz wird das alte System nicht mehr eingesetzt und alle Prozessinstanzen haben einen Wartezustand erreicht. Dann migrieren Sie alle Instanzen nach Camunda. Dazu müssen alle möglichen Wartezustände der alten Prozesse auf die BPMN-Prozessdefinition abgebildet werden, die Daten aus dem alten System gelesen und ein „Migrationsskript“ ausgeführt werden, um die Prozessinstanzen in Camunda im richtigen Zustand zu erzeugen. Danach starten Sie das neue System.

   PRO: Nach der Migration haben Sie nur noch ein System zu bedienen, und Sie können die Migration vorher testen, sodass es keine Überraschungen gibt.

   CONTRA: Die Implementierung und das Testen des Migrationsskripts erfordern zusätzlichen Aufwand. Außerdem kommt es in der Regel durch die Laufzeit der Migrationsskripts und aufgrund eventueller zusätzlicher Zustandsprüfungen danach zu einigen Ausfallzeiten.

Wenn Sie Prozessinstanzen im richtigen Zustand erzeugen, möchten Sie keine Serviceaufgaben auslösen oder auf menschliche Interaktion warten. Außerdem könnte der gewünschte Zustand auch irgendwo in einer Hierarchie von Teilprozessen liegen. Dies kann die Aufgabe etwas komplexer machen und erfordern, dass Sie Ihrem Prozessmodell Elemente nur für die Migration hinzufügen. Wenn Ihr Anwendungsfall jedoch einfacher ist, sollte die Camunda API ausreichen, um Prozessinstanzen in den richtigen Zustand zu migrieren, ohne dass zusätzliche Elemente erforderlich sind.

Basierend auf Ihrer Ausgangssituation müssen Sie entscheiden, welcher Ansatz für Ihr Unternehmen am besten geeignet ist. Der gleichzeitige Betrieb ist sehr architektur- und technologiespezifisch. Im Gegensatz dazu beinhaltet die Big-Bang-Migration immer ein „Migrationsskript“, für dessen Implementierung einige Camunda-Kenntnisse erforderlich sind.

Weitere Informationen zur Migration Ihrer Prozessinstanzen auf eine neue Version finden Sie in diesem Leitfaden: Camunda Best Practices.

Fallstudie: Migration von Oracle zu Camunda

Im Jahr 2007 hat die Deutsche Telekom ein monolithisches System auf der Basis der Oracle BPEL-Engine entwickelt, um BPM-Workflows und Prozessautomatisierung auszuführen. Im Laufe der Zeit führte dieser Monolith zu einer Reihe von Problemen, die sowohl das operative Geschäft als auch die Benutzererfahrung beeinträchtigten. Diese Probleme umfassten u. a.:

• 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 handeln und 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“, sagte Willm Tüting, Managing Director, conology GmbH.

Veränderungen durch Prozessorchestrierung ermöglichen

2017 unternahm die IT der Deutschen Telekom 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 BPEL-System zu kämpfen, das keine echte Agilität zuließ.

Im selben Jahr 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:

1. Schnelligkeit: Umstellung der Entwicklung von BPEL auf Java und des Projektmanagements von Waterfall auf Agile.
2. Entwicklung funktionsübergreifender Teams: Wechsel von fachspezifischen Teams zu internationalen, funktionsübergreifenden Teams
3. Effizienzsteigerung: Steigerung der Entwicklungseffizienz durch den Einsatz von Camunda, Spring und anderen modernen Technologien und Verfahren.

Von einem Anbieter zu 43 Frameworks

Mit diesen drei Zielen vor Augen implementierte die Deutsche Telekom IT eine Microservices-basierte Architektur in der Cloud, wobei die Camunda-Engines innerhalb vieler Microservices laufen. Laut Friedbert Samland, Project Manager IT Application, Deutsche Telekom IT, besteht das neue System aus den folgenden Komponenten:

1.  Microservices: Dieser Ansatz partitioniert den Monolithen und ermöglicht funktionsübergreifendes Arbeiten. Es gibt keine GUI; stattdessen ist das System jetzt ein reines BPMN-System. „Inspiriert von Camunda-Mitbegründer Bernd Rückers Microservices Workflow Automation Cheat Sheet führen wir Camunda-Engines in vielen Microservices aus und kommunizieren direkt mit einem Message Broker“, sagte Samland.
2. 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 Telekom IT einen eigenen Kubernetes-basierten Ansatz.
3. SAFe Agile Framework: Die Einführung eines neuen organisatorischen Frameworks mit kürzeren End-to-End-Zykluszeiten ermöglichte Flexibilität und Geschwindigkeit.
4. DevOps-Philosophie: Automatisierung und Self-Service sind der Schlüssel zur DevOps-Philosophie der Telekom-IT und stellen Qualität und Geschwindigkeit sicher.

Alignment in der Prozessautomatisierung

Einer der größten Vorteile der Camunda-Revolution der IT bei der Deutschen Telekom 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 resultierende Architektur ermöglicht nun „Compliance-by-Default“ und gewährleistet Datensicherheit.

In Anlehnung an das Token-Konzept von Camunda Cockpit 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.

Neben 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 in die Fußstapfen der Deutschen Telekom IT treten wollen, hat Willm einen weisen Rat: „Wählen Sie Ihren Stack mit Bedacht. Beginnen Sie nicht mit einem kompletten Stack, sondern wählen Sie die Komponenten aus, die Ihnen den größten Nutzen bringen. 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.“

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 bauen ihre eigenen Prozessautomatisierungsplattformen auf der Grundlage älterer BPMS auf. Da sie mit der Zeit wachsen, werden diese Plattformen fehleranfällig und sind schwer zu ändern.

Weitere Infos: Why You’re Struggling with Your BPM Suite

Ein großes Finanzdienstleistungsunternehmen wollte sowohl seine Front-Office- (z. B. Eröffnung neuer Konten, Geldbewegungen) als auch Back-Office-Prozessabläufe (z. B. Compliance) überarbeiten. Idealerweise sollten diese auf eine Cloud-basierte Plattform zur Prozessautomatisierung und -orchestrierung verlagert werden, wobei die entsprechenden Sicherheits- und Governance-Kontrollen vorhanden sein sollten.

Der erste Schritt in diesem Prozess war die Bestandsaufnahme aller Geschäftsprozesse im gesamten Unternehmen und ihre Einteilung in die Kategorien „klein“, „mittel“ und „groß“. Die Bestimmung dieser Prozessgrößen bedeutete, die Regeln, Entscheidungspunkte, Integrationen und die Anzahl der Berichte zu definieren, die an der Verschiebung von Workflows beteiligt waren (sowie die ungefähren Kosten für jeden Workflow). Das Team entschied, dass die größten anfänglichen Gewinne durch den Neuaufbau der Prozesstypen mit dem höchsten Volumen erzielt werden würden. Die Migration der tagtäglich genutzten Prozesse erforderte den größten Zeit- und Arbeitsaufwand. Obwohl diese Prozesse nicht das höchste Volumen aufwiesen, war es wichtig, sie so schnell wie möglich auf die neue Plattform zu migrieren. Ruhende Prozesse mit geringem oder gar keinem Volumen wurden stillgelegt.

Daraufhin erstellte das Doculabs-Team einen Business Case für die Migration von Legacy-BPMS. Sie sahen die Migration als Teil einer größeren Modernisierung und erörterten die Vorteile einer modernen Plattform zur Automatisierung von Geschäftsprozessen sowohl für die Endbenutzer (Kunden) als auch für die Mitarbeiter des Unternehmens. Mit dem neuen System wäre das Team in der Lage, die Arbeitsweise des Kundenservice zu ändern, manuelle Tätigkeiten zu reduzieren und Workflows schneller abzuschließen. Nachdem das Doculabs-Team die Zustimmung der Unternehmensleitung erhalten hatte, führte es im gesamten Unternehmen PoCs durch, um zu beweisen, dass 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-Prozesses experimentierten sie mit der Übernahme von Workflows aus dem Altsystem und deren Migration auf die neue Plattform. Ein erstes Feedback war positiv. Doculabs überarbeitete und modifizierte auch bestimmte Workflows, bevor sie in die neue Umgebung übernommen wurden.

In der Regel wurde wie folgt vorgegangen:

• 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 gut genug ist, sollte er (wann immer möglich) so weiterbetrieben werden, wie er ist.

Nachdem das Doculabs-Team die Prozesse des Unternehmens von Legacy-BPMS auf die neue Cloud-basierte Plattform migriert hatte, konnte es eine unmittelbar eine verbesserte Zusammenarbeit zwischen Business und IT feststellen. Durch die Verwendung von BPMN als gemeinsamen Standard und Kommunikations-Tool konnten beide Teams leicht erkennen, wie die Prozesse funktionierten und wie sie optimiert werden konnten. Mit dem neuen System kann das Finanzdienstleistungsunternehmen nun menschliche Systeme und automatisierte Prozesse gemeinsam orchestrieren.

Erkenntnisse einer erfolgreichen Migration von Legacy-BPMS zu Camunda

Die Swiss Re migrierte erfolgreich von Legacy-BPMS zu einer Microservices-basierten Orchestrierungsplattform mit Camunda. Hier sind einige der wichtigsten Erkenntnisse, die sie aus der Migration gewonnen haben:

• Klare Kommunikation – 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. Das geschieht durch kontinuierliche Kommunikation.
•  Prioritäten der Teams der Business Stakeholder verstehen – Jedes Team hat seine eigenen Projekte und Prioritäten. Sie zu Beginn des Migrationsprozesses aneinander anzupassen hilft beim Planungsprozess.
• Optimistisch sein und Entwicklern vertrauen – 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.
• Eher pessimistisch planen – Die Migration bei Swiss Re wurde durch die Covid-19-Pandemie sowie durch krankheitsbedingte Ausfälle der Mitarbeiter verzögert. Anders gesagt: Erwarten Sie das Unerwartete.
• Realistisch sein, was geht und was nicht – Das bedeutet, dass Sie das priorisieren, das jetzt schon oder in naher Zukunft möglich ist. Swiss Re hat zum Beispiel eine Roadmap für selbstheilende Anwendungen und zur Erweiterung der Nutzerbasis erstellt, sowie um Superusern die Möglichkeit zu geben, Workflows in Camunda zu erstellen. Darüber hinaus möchte das Unternehmen die Berichtsfunktionen verbessern, damit Benutzer erkennen können, wo Workflows optimiert werden müssen.

Schlussfolgerung

Wenn Sie die Entscheidung getroffen haben, von Legacy-BPMS zu migrieren: Herzlichen Glückwunsch! Die Modernisierung dieser starren Systeme hin zu flexibleren, entwicklerfreundlichen und API-fähigen Plattformen wie Camunda kann zu einem besseren Kundenerlebnis, einer höheren Produktivität des internen Teams, beschleunigter Entwicklung und vielem mehr führen. Wie Sie an den obigen Beispielen gesehen haben, legen erfolgreiche Unternehmen im Vorfeld einer technischen Migration bereits die Grundlagen und stimmen ihre Strategie zur Prozessautomatisierung mit der Unternehmensführung, der IT und den Stakeholdern ab, bevor sie große Änderungen in Angriff nehmen.

Groß angelegte Migrationen werden dem parallelen Betrieb von Legacy-BPMS und Camunda vorgezogen. Für große Migrationen müssen Sie Ihre Prozesse in das richtige BPMN 2.0-Format bringen und alle bestehenden Prozessinstanzen in den richtigen Zustand in Camunda migrieren, wie oben und in Camunda Best Practices beschrieben.

Wenn Sie Hilfe benötigen, wenden Sie sich an das Camunda-Beraterteam. Wir haben unzählige Unternehmen dabei unterstützt, ihre Prozesse von einigen der starrsten, monolithischen Systeme auf Camunda zu migrieren. Wir helfen Ihrem Team gerne durch den gesamten Migrationsprozess – vom PoC bis zum Endprodukt.

Kontaktieren Sie uns gerne und Sie erhalten weitere Informationen.