Die Vision klingt so wunderbar durchgängig und einfach: Wir betreiben eine saubere Geschäftsprozessanalyse – Top-down, mit der BPMN und natürlich ausgeführt von Business-Experten, die keinerlei IT-Kenntnisse brauchen. Es entsteht ein widerspruchsfreies Modell der tatsächlichen Unternehmensprozesse, so formalisiert beschrieben, dass wir daraus über einen einfachen Export BPEL generieren können. Das werfen einer Engine zur Ausführung vor, und diese orchestriert unsere ebenfalls vorhandenen - oder geschwind neu implementierten - Services so, dass nun alles automatisch läuft.Das ist natürlich völliger Unsinn, und zwar gleich aus mehreren Gründen.
- Natürlich sind in jedem Unternehmen Geschäftsprozesse von besonders hoher Bedeutung, ob sie nun formal dokumentiert sind oder nicht. Aber oft sind die Geschäftsprozesse nicht so konstant, wie man es sich wünschen würde - und vor allem: oft sind sie nicht so einheitlich, dass eine vollständige Beschreibung überhaupt möglich ist (es sei denn, man möchte sich zu 90% der Zeit mit der Formalisierung von Ausnahmen beschäftigen).
- Wenn sie beschrieben wurden, sind die Modelle in aller Regel auf einem Niveau, das eine Diskussion erlaubt - sie unterstützen die Kommunikation zwischen beteiligten “Stakeholdern” und erfüllen dazu (hoffentlich) einen guten Zweck. Sie sind aber weit, weit davon entfernt, so formalisiert zu sein, dass man sie ausführen könnte.
- Wollte man das ändern - d.h. die Modelle auf Ausführungsniveau beschreiben -, verändern die Modelle ihren Charakter. Sie werden zu etwas anderem - etwas, das man gemeinhin Programm nennt. Und solche Dinge - Programme - werden in der Regel von Personen erzeugt, die man üblicherweise Programmierer nennt. Mit gutem Grund - die formale Beschreibung von Abläufen ist eine Disziplin mit eigenen Regeln, Erfahrungen, Best Practices … und so wenig wie so von einem Programmierer (oder vornehmer: Entwickler) erwarten würden, dass er auf einmal Vertriebsaufgaben übernimmt, sollten Sie z.B. vom Vertriebsspezialisten Programmierkenntnisse erwarten.
- Der letzte Haken: Damit die ganze Idee mit den ausführbaren Geschäftsprozessen funktioniert, müssen Sie ein Service-Portfolio zur Verfügung haben, dass Dienste auf der richtigen (d.h. zu den Prozessen passenden) Granularitätsebene zur Verfügung stellt. Und diese brauchen Sie eigentlich, noch bevor Sie mit der Geschäftsprozessmodellierung anfangen … sofern Sie nicht in der ungewöhnlichen Lage sind, Ihr Unternehmen für ein paar Jahre zu stoppen, um diese Herkulesaufgabe anzugehen, werden Sie von der Erreichung Ihrer Ziele eine lange Zeit träumen müssen.
Zynisch? Defätistisch? Keineswegs, ich erkenne durchaus einen hohen Wert der Geschäftsprozessmodellierung auf der einen und von Orchestrierungs-Engines auf der anderen Seite. Aber das eine mit dem anderen zu verbinden, erfordert eine Transformation, eine Abbildung - und das ist ein kreativer Schritt, der von Menschen durchgeführt werden muss und für den der Aufwand nicht unterschätzt werden sollte.
Beiträge (Atom)
Short and to the point, very good. Do you plan on publishing an english translation on your regular blog ?
If there’s sufficient interest - yes.
Ich stimme Ihnen in allen Punkten zu! Würde lediglich noch hinzufügen, dass das vielbeschworene Performance Management mit Hilfe der KPI-Messung auch nicht mal eben so einfach funktioniert (u.a., weil eben nicht alle Prozesskennzahlen auch tatsächlich in den Workflows anfallen, die automatisiert werden (können)).
Absolut richtig. Wahrscheinlich sollte man auch bei diesem Thema überlegen, wie weit man wirklich gehen möchte. 100% dieser Idee umzusetzen dürfte kaum möglich und praktikabel sein, aber das heißt ja nicht, daß man nicht trotzdem eine formale Geschäftsprozessbeschreibung als Diskussionsgrundlage/Dokumentation erstellen, BPEL/Orchestration Engines verwenden (wenn man denn mag) und Services (in welcher Geschmacksrichtung auch immmer) einsetzen sollte. Wenn man das macht, ist man wahrscheinlich wesentlich besser aufgestellt, als ohne diese Dinge. Und 80% davon umzusetzen bringt Vorteile, ohne die restlichen 20% (automatische Transformation, etc.) mit riesigem (unnötigen?) Aufwand ebenfalls erreichen zu wollen.
An english translation would be very welcome
Hat JJ was dazu gesagt?
@Mark: Nein - ich habe es aber auch noch nicht übersetzt …
Auch wenn dieser Blog Eintrag bereits ein paar Monate alt ist möchte ich dennoch ein paar Anmerkungen geben.
Grundsätzlich kann ich dem Geschriebenen schon zustimmen, möchte aber dennoch ein paar aus meiner Sicht wichtige Dingen ansprechen, die im bislang aufgeführten zu kurz kommen:
- BPM (als Business Process Management) umfasst ja nicht nur die Beschreibung von Geschäftsprozessen (anhand einer entsprechenden Prozessmodellierung), sondern ist doch vielmehr eine Disziplin, welche Businessexpertise und Softwarefunktionalität dazu kombiniert Prozessverbesserungen zu beschleunigen und Innovationen zu erleichtern. Dazu gehören sicherlich auch entsprechende Komponenten wie die Simulation, Prozessmonitoring und Einbeziehen von Nutzern sowie eine mögliche Prozessautomatisierung.
- Um mein Geschäft besser auf aktuelle Situation und die Marktanforderungen ausrichten zu können reicht es doch nicht nur aus, die Geschäftsprozesse nach bestem Wissen und Gewissen zu modellieren und dann (automatisiert) umzusetzen. Nein. Ich muss doch vielmehr auch die Möglichkeit haben die Auswirkungen der Veränderungen bereits im Vorfeld zu prüfen (simulieren) und dann auch im produktiven Einsatz fortwährend einen aktuellen (echtzeitnahen) Einblick in meine Geschäftsprozesse erlangen um so kurzfristige Trends und auch Problemstellungen schnell erkenn zu können und auch auf einzelne Prozessinstanzen einwirken zu können — wobei wir dann bei Business Activity Monitoring (BAM) wären. Diese Informationen sollten natürlich auch möglichst wieder an die zurückgehen, die die Prozesse modelliert haben um hier die Anpassungen an die Realität auch vornehmen zu können.
Ich sehe es auch so, dass nicht alle KPIs, die für die unterschiedlichen bereiche eines Unternehmens wichtig sind auch über den aktuellen Geschäftsprozess erfasst und geliefert werden. Dies ist auch nicht weiter schlimm, es muss nur sichergestellt werden, dass eine Korrelation ermöglicht wird und auch relevante Informationen, die nicht aus dem Geschäftsprozess stammen mit einbezogen werden können.
- Im Bezug auf den Vergleich zwischen dem Vertrieb, der nicht programmiert und dem Programmierer, der nicht verkauft ist meine Erfahrung, dass das Ergebnis dann umso besser ist, wenn sich beide Seiten gut verstehen und es schaffen sich gegenseitig zu bereichern. Damit ziele ich darauf ab, dass es nicht nur wichtig ist, einen Weg zu definieren, wie Daten aus der Modellierung des Prozesses nachher zur Umsetzung gelangen, sondern wie es ermöglicht wird, eine Plattform zu schaffen, die einen Austausch an Informationen in beide Richtungen ermöglicht und auch als Diskussionsbasis sowohl für die Prozessbeschreibung als auch die Prozessumsetzung wertvoll ist. mein Ansatz ist hier zu sagen, je mehr der Business Analyst an Informationen bereits bereitstellen kann(Prozessmodell, KPIs, Business Objekte, Daten, …) umso mehr kann auch der Developer wieder übernehmen.
- Ich denke, wir müssen uns im Klaren sein, dass es sowohl zu BPM, als auch zu SOA unterschiedliche Einstiegspunkte gibt, die von der jeweiligen Kunden- und Geschäftssituation abhängen