Von EPK zu BPMN: Was passiert wirklich bei der Konvertierung eines Prozess-Repositorys?

Der Unterschied zwischen EPK und BPMN liegt weniger darin, was die beiden Notationen beschreiben, als vielmehr darin, wie sie dies darstellen. Beide sind Notationen für Prozessabläufe und basieren auf Aktivitäten, Entscheidungen, Beteiligten und Ereignissen – sie ordnen und strukturieren diese Elemente jedoch auf unterschiedliche Weise. 

Der wesentliche Unterschied besteht darin, wie Prozesslogik und Verantwortlichkeiten dargestellt werden. In EPKs beschreiben Funktionen die Aktivitäten innerhalb eines Prozesses und sind über Ereignisse und logische Konnektoren miteinander verbunden. BPMN bildet ähnliche Konzepte mit Aufgaben, Ereignissen und Gateways ab, verwendet jedoch eine andere Struktur zur Dastellung von Prozessabläufen und Verantwortlichkeiten. 

Daher gibt es für die meisten zentralen Modellierungselemente eine klare Äquivalenz zwischen den beiden Notationen. Funktionieren werden typischerweise zu BPMN-Tasks, Ereignisse bleiben Ereignisse, und logische Konnektoren lassen sich auf die entsprechenden BPMN-Gateways abbilden. Die Bereiche, die mehr Aufmerksamkeit erfordern, betreffen in der Regel nicht die Prozessschritte selbst, sondern die Modellierungskonventionen, die sie umgeben. 

Ein häufiges Beispiel dafür sind die Verantwortlichkeiten in der Organisation. In EPK-Modellen werden Rollen oder Organisationseinheiten häufig direkt an Funktionen angehängt, während BPMN Verantwortlichkeiten typischerweise über Pools, Lanes oder Ressourcenzuweisungen darstellt. Der Wechsel zwischen diesen beiden Ansätzen erfordert daher eine Entscheidung darüber, wie Verantwortlichkeiten im Zielmodell strukturiert werden sollen. Die Zuordnung von EPK zu BPMN ist somit nicht nur eine technische Übersetzung zwischen zwei Notationen, sondern auch eine Entscheidung darüber, wie bestehendes Prozesswissen in der zukünftigen Umgebung dargestellt werden soll. 

Dasselbe gilt für Elemente wie Anwendungsreferenzen, benutzerdefinierte Attribute oder organisationsspezifische Modellierungserweiterungen. Die stellen keine technischen Hindernisse für die Konvertierung dar, erfordern aber ein Verständnis des bestehenden Repositorys und klare Entscheidungen darüber, wie diese Informationen künftig dargestellt werden sollen. 

Deshalb ist eine erfolgreiche Konvertierung von EPK zu BPMN nicht einfach ein Wechsel der Notation. Sie ist ein strukturierter Migrationsprozess, der automatisierte Transformationen mit gezielten Modellierungsentscheidungen dort verbindet, wo sich die Standards der beiden Notationen unterscheiden. 

Ein Prozess-Repository enthält weit mehr als nur Diagramme. Der Wert einer Migration liegt daher nicht allein darin, die visuellen Modelle zu erhalten, sondern auch die Informationen zu übertragen, die diese Modelle in der Praxis nutzbar machen – darunter Attribute, Verantwortlichkeiten, Dokumentationen und Sprachversionen. 

Bei der Konvertierung von EPK zu BPMN müssen typischerweise folgende Elemente berücksichtigt werden: 

• EPK-Prozessmodelle und BPMN-Diagramme 
• Wertschöpfungsketten und Prozesslandschaften 
• Organisationsstrukturen 
• Rollen und Verantwortlichkeiten 
• Prozessattribute und Dokumentationen 
• Mehrsprachige Repositorys 

Mehrsprachige Repositorys verdienen dabei besondere Aufmerksamkeit. Übersetzungen bedeuten nicht nur zusätzlichen Modellierungsaufwand, sondern enthalten auch umfangreiches organisatorisches Wissen, das über Jahre aufgebaut wurde. Diese Inhalte manuell neu zu erstellen, kann daher zu einem der ressourcenintensivsten Teile einer Repository-Migration werden. 

Knorr-Bremse zeigt, warum die Bewahrung dieser Informationen im Unternehmensmaßstab so wichtig ist. Als globaler Hersteller von Bremsensystemen und weiteren Technologien für Schienen- und Nutzfahrzeuge verwaltet das Unternehmen komplexe Prozesse über verschiedene internationale Standorte und Sprachen hinweg. Im Rahmen der Migration von ARIS zur GBTEC Platform wurden mehrere Tausend Prozessmodelle übertragen, mehrere Notationen automatisch konvertiert und Repositories in zwölf Sprachen erhalten. So konnte Knorr-Bremse ihr bestehendes Prozesswissen bewahren und gleichzeitig eine besser zugängliche Grundlage für das zukünftige Prozessmanagement schaffen. 

Bei einer erfolgreichen Repository-Migration geht es nicht darum, sämtliche Inhalte automatisch und ohne Überprüfung zu übertragen. Einige Elemente erfordern Entscheidungen, weil sie widerspiegeln, wie eine Organisation ihr Prozesswissen im Laufe der Zeit strukturiert, gesteuert und gepflegt hat.

Vier Bereiche erfordern typischerweise menschliche Mitwirkung:

1. Benutzerdefinierte Attribute und Erweiterungen
   Viele Organisationen erweitern ihre Prozess-Repositorys um zusätzliche Attribute, benutzerdefinierte Objekte oder spezifische Modellierungsstrukturen. Diese Elemente müssen überprüft und gezielt zugeordnet werden, damit relevante Informationen erhalten bleiben. Der Umfang dieser Arbeit lässt sich in der Regel frühzeitig anhand einer Bestandsaufnahme des Repositorys ermitteln.
2. Skriptbasierte Reports und Makros
   Automatisierungen, die auf der Skriptumgebung einer bestimmten Plattform basieren, lassen sich nicht automatisch auf ein anderes System übertragen. Reports, Skripte und Makros müssen überprüft, bei Bedarf neu erstellt und hinsichtlich ihres aktuellen Nutzens bewertet werden. Eine Migration bietet oft eine gute Gelegenheit, Automatisierungen neu zu identifizieren, die nicht mehr aktiv genutzt werden.
3. Modellierungskonventionen
   Langjährig bestehende Prozessprogramme entwickeln naturgemäß eigene Modellierungspraktiken. Einige davon sind formale Standards, andere haben sich im Laufe der Zeit als lokale Gewohnheiten etabliert. Eine Migration bietet einen guten Anlass, zu prüfen, welche Konventionen beibehalten und welche vereinfacht werden können.
4. Inhalte, die nicht migriert werden sollten
   Nicht jedes Modell in einem Repository bildet noch aktives Prozesswissen ab. Im Laufe der Zeit sammeln sich häufig veraltete oder nur selten genutzte Inhalte an. Eine Überprüfung dieser Informationen vor der Migration hilft Organisationen dabei, mit einer übersichtlicheren und wertvolleren Prozesslandschaft weiterzuarbeiten.

Der entscheidende Punkt ist: Diese Entscheidungen sind keine unerwarteten Hindernisse. Sie sind Bestandteil eines strukturierten Migrationsansatzes und können bereits vor Beginn der Konvertierung identifiziert werden. 

Der Zeitrahmen für eine Migration von EPK zu BPMN hängt von der Größe und Komplexität des Repositorys sowie von den Entscheidungen ab, die während des Übergangs getroffen werden müssen. Betrachtet man speziell die ARIS-Migrationsdauer, zeigen die Erfahrungen aus mehr als 100 abgeschlossenen Migrationen von ARIS zur GBTEC Platform, dass kleinere Umgebungen typischerweise eine bis zwei Wochen, mittelgroße Repositorys zwei bis vier Wochen und große Enterprise-Landschaften vier bis sechs Wochen benötigen. 

Die Phase der automatisierten Konvertierung nimmt in der Regel deutlich weniger Zeit in Anspruch als das gesamte Migrationsprojekt. Der größte Aufwand entfällt auf die Analyse des Repositorys, die Validierung und die Abstimmung der Modellierungsstandards. All dies trägt dazu bei, dass die migrierten Inhalte auch nach dem Wechsel weiterhin einen praktischen Nutzen bieten. 

Das verändert auch die Wahrnehmung des Migrationsrisikos. Ein Repository kann über Jahre aufgebautes Prozesswissen enthalten, doch die Migration selbst lässt sich häufig innerhalb weniger Wochen durchführen. So können Organisationen das bereits aufgebaute Wissen bewahren und gleichzeitig eine besser zugängliche Grundlage für das zukünftige Prozessmanagement schaffen. 

Nicht unbedingt. Wenn Ihre Organisation effektiv mit EPK arbeitet, etablierte Modellierungspraktiken hat und keine stärkere Interoperabilität mit anderen Prozesswerkzeugen benötigt, kann es sinnvoll sein, die bestehende Notation beizubehalten. Eine Migration erfordert nicht automatisch einen Wechsel der Notation.  

Für eine Konvertierung zu BPMN sprechen in der Regel übergeordnete geschäftliche Anforderungen: BPMN 2.0 ist ein international anerkannter Standard mit breiter Tool-Unterstützung. Die Notation wird häufig als Brücke zwischen Prozessmodellierung und Workflow-Automatisierung eingesetzt, und viele neue Prozessverantwortliche sind bereits mit BPMN vertraut. 

Zu berücksichtigen ist jedoch, dass ein gleichzeitiger Wechsel von Plattform und Notation zusätzliche Veränderungen für die Anwender mit sich bringt. Für viele Organisationen ist es daher sinnvoller, zunächst das Repository zu migrieren, die neue Umgebung zu etablieren und anschließend die Konvertierung der Notation als separaten Schritt zu prüfen. 

Die richtige Reihenfolge hängt von den Zielen der Organisation ab. Entscheidend ist: Plattformmigration und Notationskonvertierung sind miteinander verbundene Entscheidungen, müssen jedoch nicht gleichzeitig erfolgen. 

Sie planen eine Repository-Migration? Das ARIS-Migrationshandbuch behandelt die Übertragung von Objekten, die einzelnen Migrationsphasen, wichtige Entscheidungspunkte und die Erstellung eines Business Case. 

 Migrationshandbuch herunterladen