Best Practices und Lessons Learned

Im Folgenden werden wichtige Best Practices und Lessons Learned aus BPM-Projekterfahrungen aufgeführt.

Geschäftsorientiert:

• BPM ist unter anderem ein Lernprozess, um das Optimum der Prozesse entlang der gesamten Wertschöpfungskette zu erreichen.
• Zu Beginn einer BPM-Initiative sollte immer der Ist-Zustand gemessen werden (beispielsweise die Anzahl und Qualität der dokumentierten und gelebten Prozesse und die von der IT unterstützte Prozessanteile).
• BPM wird nicht allein durch die Einführung eines Werkzeugs realisiert. Eine entsprechende Management-Architektur, die notwendigen Rollen und Prozesse sind Grundlage für die Einführung der passenden Technologien und Tools.

• Die Organisationsstruktur muss sich ändern bzw. anpassen – je nach Unternehmen fallen diese Änderungen anders aus. Das heißt, sie hängen davon ab, wie weit sich das Unternehmen bereits in Richtung Prozessorientierung entwickelt hat.
• BPM unterstützt iterative Verbesserung der jeweiligen Geschäftsprozesse. Jede bereits laufende, aber noch nicht perfekte Prozessversion wird schrittweise verbessert. Dieser Weg ist ein pragmatischer und zielorientierter Ansatz zur Umsetzung von BPM. Theoretische Überlegungen zur Erstellung des endgültigen Prozesses durch die Fachseite vor der ersten Prozessinstrumentalisierung sind unproduktiv; diese Arbeit kann langfristig zwar zu einer „perfekten“ Implementierung führen, für diese gäbe es dann jedoch keine Interessenten mehr, da die Fachseite entweder manuelle Alternativen gefunden hat oder bereits die nächste Stufe der Prozessrealisierung begonnen hat.
• Im Rahmen eines End-to-End-BPM steigen die Anforderungen an die Fachabteilung bzw. Fachmodellierer: Diese müssen IT-Aspekte berücksichtigen und den benötigten Grad an Formalität für die Ausführung durch IT-Systeme bei der Prozessmodellierung erreichen. Die Umsetzung dieser neuen Anforderung an die Geschäftsanalysten wird durch die Anpassung der Modellierungskonventionen und durch die Rolle des Process-Engineer erleichtert. Nur so kann das Ziel von einem effizienten End-to-End-BPM erreicht werden und können die Fachabteilung den benötigten direkten Einfluss auf die Prozessrealisierung haben.
• Change-Management beginnt immer auf der Fachseite im Prozessmodellierungstool.
• Technische Anpassungen innerhalb des fachlich freigegebenen Prozesses sind zu minimieren, um weitere Freigaberunden und Aufwände zu vermeiden.
• Notwendige Änderungen auf der IT-Seite müssen in die Fachmodellierung überführt werden, damit keine wiederholte Anpassung in den folgenden Prozessversionen erfolgen muss.

IT-orientiert:

• Es erfolgt eine frühe Festlegung der prozessspezifischen Geschäftsobjekte und Services, damit die Prozess- von der Services-Implementierung getrennt und so aus dem kritischen Projektpfad genommen wird. Dadurch entsteht eine weitere Chance zur Reduktion der Zykluszeit.
• Alle notwendigen Anpassungen sind außerhalb des von der Fachabteilung zur Implementierung übernommenen Prozesses vorzunehmen. Eine ideale Stelle dazu ist der ESB, z. B. für die Implementierung von Transformation, Routing, Mediation sowie Fehlerbehandlung.
• Auch der Aufruf eines Prozesses durch einen anderen Prozess sollte über den ESB implementiert werden. Hiermit werden Aufrufe und Implementierungen isoliert und eventuell generierte Prozessschnittstellen durch stabile Schnittstellen gekapselt und abstrahiert.
• Die Datenmodellierung ist wichtig (aus Prozesssicht, eigene Sprache).
• Die Standardisierung der fachlichen Schnittstellen ist genauso wichtig wie die der technologischen Schnittstellen.
• Redundante Prozesse sind im Laufe der Optimierung zu vermeiden.
• SOA ist eine Voraussetzung für effizientes BPM. Allerdings wird eine zu 100 % vollständig umgesetzte SOA für die erste BPM-Implementierung nicht benötigt. Einzelne Prozesse können direkt mit den ersten SOA-Services versorgt werden.

Lessons Learned

• Werden Ängste der betroffenen Mitarbeiter nicht berücksichtigt, besteht die Gefahr, dass sie die Veränderung zunächst blockieren. Mitarbeiter sollten also möglichst früh einbezogen werden, da BPM- und SOA-Veränderungen innerhalb eines Unternehmens mit sich bringen. Veränderungen werden häufiger als Risiko denn als Chance betrachtet.
• Die Ergebnisse und Teilziele parallel arbeitender BPM-/SOA-Teilprojekte müssen für alle am Gesamtprojekt beteiligten Personen transparent sein, um auseinanderlaufende Entwicklungen zu vermeiden und Widerstände zu minimieren.
• Projektziele sollten in den persönlichen Zielen der Betroffenen verankert werden.

Weiter zum Artikel „Kritische Betrachtung zu BPM als Hype“