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