Ausgangslage
Das beim Kunden eingesetzte Prozessmanagement-System hatte stillschweigend End-of-Life erreicht. Mit einer gewissen Verzögerung wurde festgestellt, dass der Hersteller selbst seine Tätigkeiten eingestellt hat. Das Funktionieren des Prozessmanagements ist vital für den Kunden, da dieses den gesamten Interaktionsfluss mit seinen Endkunden verwaltet. Somit wurde der eingestellte Support und die fehlende Weiterentwicklung dieser Lösung vom Verwaltungsrat zu einem kritischen Betriebsrisiko eingestuft.
Nach einer Evaluationsphase wurde entschieden das Prozess-Management System Camunda 8, welches auf dem BPMN 2.0 Standard operiert, einzusetzen und die bestehende Lösung dahingehend abzulösen.
Problemstellung
Die bestehenden Prozesse wurden seit vielen Jahren eingesetzt, jedoch wurden nur wenige laufend weiterentwickelt. Somit war das Wissen über die detaillierte innere Funktionalität dieser Prozesse nicht ohne Weiteres bekannt. Die Dokumentation ist die Prozessdefinition selbst. Mitarbeiter, welche an der Entwicklung beteiligt waren, sind grösstenteils der natürlichen Fluktuation erlegen. Nicht nur die Prozesssteuerung in rund zwei dutzend Prozessen, von welchen der grösste rund 390 Schritte beinhaltete, waren das komplexe an diesem System. Die Prozesse greifen auf verschiedene Wege auf die umliegenden Systeme zu und speichern die erhaltenen Informationen in verschiedenen internen Datenbanken ab, welche später für weitere Aufrufe wieder verwendet werden. Diese Datenbanken wurden aber auch von den Umsystemen direkt angesprochen und verändert. Diese Komplexität wäre bei einer manuellen Migration zur grossen Herausforderung und besonders zu einem Qualitätsrisiko geworden.
Die Object Engineering wurde im vorliegenden Fall über die gesamte Bandbreite ihrer Dienstleistungen beauftragt eine Analyse der aktuellen Prozessdefinitionen zu erstellen, eine Living Documentation bereitzustellen, welche auf ihrer «Discovery-Plattform» zur Verfügung gestellt wurde, sowie die Entwickler mit Transformation-Support zu unterstützen um die Projektdauer soweit als nur irgendwie möglich zu reduzieren.
Lösungsweg
In einer ersten Analyse wurden die Abhängigkeiten und Zusammenhänge der einzelnen Prozess-Definitionen sowie deren Abhängigkeit zu Umsystemen (Services, Datenbanken, User Interfaces) untersucht. Als eines der ersten Artefakte entstand eine Planungs-Adjazenztabelle, woraus eine optimale Umsetzungs-Reihenfolge gewonnen werden konnte, welche die Planung und die entstehenden Kosten über die Projektdauer quantifizieren konnte.
In einem weiteren Schritt wurde die proprietäre Notation des Legacy-Systems in BPMN 2.0 für das Ziel-System transformiert. Da die Realisierung gewisser Konstellationen (z.B. spezielle Task-Types) der alten Prozessdefinition im neuen nicht möglich war, musste ein Struktur-Redesign gemacht werden. Die oben erwähnten Variablen und die Berechnungs-Ausdrücke wurden ebenfalls automatisiert transformiert.
Durch Einbezug der historischen Laufzeitdaten (Log-Auswertungen) aus der produktiven Anwendung konnten Pfade markiert werden, welche selten oder nie verwendet wurden. Das erlaubte es dann dem Prozess-Engineer zu entscheiden, ob gewisse Ablaufpfade eliminiert werden konnten und sogar teilweise unbemerkte Fehler aufzeigen (die üblicherweise in der Produktion manuell gehandhabt werden mussten).
Die Ausprägung der verschiedenen Umsystem-Aufrufe konnten in der Analyse klassifiziert und in der Transformation automatisiert umgesetzt werden. Die erwähnten Zugriffe auf Funktionalität der Umsysteme und deren Parameter (Variablen) wurden ebenfalls automatisiert auf entsprechende Camunda-Workers transformiert.
Transformation Support
Durch den periodischen, engen Kontakt mit dem Lead-Architekten und dem Migration-Team konnten Bedürfnisse, welche sich aus der Umsetzung ergaben, iterativ und schnell umgesetzt werden. Damit konnten die Ressourcen effektiv dort eingesetzt werden, wo sie für die Transformation den grössten Nutzen erbrachten.
Da die Migration Prozess für Prozess erfolgte und währenddessen noch Änderungen an den nicht migrierten Prozesse vorgenommen wurden (Parallelbetrieb), wurde die Möglichkeit geschaffen, eine wiederholte Transformation der geänderten Legacy-Prozessdefinition durchzuführen. Dabei blieben bereits vorgenommene Layout-Anpassungen erhalten, sowie wurden eventuell nötige manuelle Eingriffe mittels Roundtrip-Verfahren wieder importiert und bei einer erneuten Generierung gemerged. So konnte eine vollständige Generierung während des produktiven Betriebs erreicht werden.
Resultat
Die Transformation der bestehenden Prozesse und Ablösung der bestehenden Workflowsystems konnte effizient und in der dafür vorgesehenen Projektzeit termingerecht umgesetzt werden.
Durch die automatisierte Umsetzung konnten
- Qualität
- Effizienz
- Umsetzungsflexibilität
gewonnen werden. Mit einem rein manuellen Prozess wäre die Umsetzung nicht nur beschwerlicher sondern auch mit wesentlich fehleranfällig gewesen.
Fazit
Die automatisierte Transformation und der enge Kontakt zwischen Entwicklungsteam und den Migrations-Experten haben einen optimalen und effizienten Projektverlauf und eine hohe Qualität geboten. Auch wenn der Umfang der eingesetzten Prozesse nicht nach einer automatisierten Umsetzung verlangen, hat die Analyse der Artefakte die hohe Komplexität aufgezeigt, welche sich auf geplante Termine nachteilig ausgewirkt hätten. Selbst die Planung und Umsetzungsreihenfolge konnte dank der Analyse optimal gemacht und die Ressourcen mit hoher Genauigkeit eingeplant werden.