Einführung in Business Process Management (BPM) und BPM Systeme (BPMS)

Transkript

1 Einführung in Business Process Management (BPM) und BPM Systeme (BPMS) Dipl.-Ing. Dr. Christoph F. Strnadl I. EINLEITUNG Während sich in den vergangenen Jahrzehnten die Unternehmen mit der effizienten Ausführung und lokalen Optimierung von einzelnen Funktionsbereichen beschäftigt haben, trat dabei der Gesamtzusammenhang der betriebenen und in der IT abgebildeten Systeme in den Hintergrund. Je stärker die Autonomie der Funktionsbereiche wurde, je mehr Funktionalitäten in einzelne "Silo Applikationen" einer Abteilung gepackt wurden, umso stärker stiegen der Aufwand und die Kosten für Abstimmung und Koordination zwischen Abteilungen und IT Systemen. Zur Überwindung dieses Dilemma begannen daher die Organisationen immer mehr, explizit ihre Prozesse in den Mittelpunkt ihrer (Verbesserungs-) Projekte zu stellen. Das Schlagwort Business Process Reengineering (BPR) aus dem Jahr 1993 [1] ist dafür bester Beweis, auch wenn mittlerweile die teilweise überzogenen Erwartungen von BPR einem gesunden Realismus beim Angehen von Prozessverbesserungsprojekten gewichen sind. Eine ähnliche Hinwendung zu Prozessen ist nicht nur in den funktionalen Bereichen der Unternehmen, sondern auch in der IT festzustellen. War die IT der 80er Jahre vorwiegend durch die Beschäftigung mit Data Management (Stichworte: relationale Datenbanken, Unternehmensdatenmodelle) gekennzeichnet, ohne im Speziellen über die Automatisierung von (simplen) Aufgaben und Aktivitäten hinaus auf Prozesse gesondert einzugehen, so standen die 90er Jahre im Zeichen des Application Managements. Dabei wurden erstmals durch die Einführung von ERP (Enterprise Resource Planning) Applikationen großflächig Unternehmensprozesse in Applikationen abgebildet. Der radikale Ansatz des Business Process Reengineerings [1] hat ebenfalls wenngleich auch mit geringem Implementierungserfolg das Top Management in der Frage nach der Prozessunterstützung gerade durch IT sensibilisiert. In Zusammenhang mit einer oft schwach ausgeprägten (falls überhaupt explizit vorhandenen) strategischen IT Architektur hat dies in vielen Fällen zu einer heterogenen und verteilten n-tier Architektur geführt, in der zahlreiche funktionale Applikationssilos Geschäftslogiken und Prozesssteuerung teilweise in Code, teilweise in Konfigurationstabellen oder auch in externen Integrationsplattformen (Stichwort: Enterprise Application Integration, EAI) abbilden. Tatsächlich können in dieser Situation die IT und die Prozesse nicht mehr voneinander getrennt werden: Sie sind zu einem einzigen praktisch untrennbaren (und auch unentwirrbaren) Geflecht verwoben. Obwohl die Unternehmen etwa 40% ihrer IT Kosten aufwenden, um bestehende Applikationen weiter zu unterstützen bzw. neue Funktionalitäten einzuführen, werden die Erwartungen der Fachanwender und des Managements typischerweise von der IT enttäuscht: Änderungen der Prozesse führen sofort und notwendigerweise zu Änderungen in den Applikationen da letztere aber nur fehleranfällig, langsam und auch teuer adaptiert werden können, weitet sich der (ohnehin schon bestehende) Graben zwischen Fachabteilung / Geschäftsführung und der IT Abteilung aus. Dazu kommt, dass in Zeiten der Globalisierung und Digitalisierung die Komplexität, Konkurrenz und die Betonung des Shareholder Values [2] zunehmen und von den Unternehmen die gleichzeitige Optimierung von Flexibilität und Profitabilität gefordert wird: Ein Unterfangen, dass in vielen Fällen von der Schwerfälligkeit der IT behindert, wenn nicht gar verhindert wird. 1

2 II. VISION VON BPM Vor diesem Hintergrund stellt Business Process Management (BPM) mit seinem klaren und deutlichen Fokus auf die Geschäftsprozesse ein tragfähiges Fundament für eine Vision dar, die tatsächlich in der Lage ist, den Graben zwischen IT und Fachabteilung (den sogenannten business-it divide ) zu überwinden. In letzter (visionärer) Konsequenz heißt BPM, dass sich Organisation und Fachabteilungen selbst völlig ohne Mithilfe der IT ihre Prozesse im Rahmen der Modellierung des BPMS zusammenstellen und Aktivitäten steuernd und koordinierend anordnen (können). Das fertige Prozessmodell wird dann einfach an eine entsprechende Process Engine zur Abarbeitung und Ausführung übergeben. Eine eigentliche Programmierung und Applikationsentwicklung findet dabei überhaupt nicht mehr statt! In diesem Sinne kann die (radikale) Vision von BPM auch als: Don t bridge the business-it divide obliterate it! formuliert werden [3]. Zusammen mit der architektonischen Grundlage einer service-orientierten IT Architektur (SOA) beschränkt sich die applikationsorientierte Rolle der IT Abteilung in diesem Zukunftsszenario auf die Aufgabe, Services zu implementieren. Die gewohnte Anwendungsentwicklung im klassischen Sinne ist dann nicht mehr notwendig und findet ergo auch nicht mehr statt. Auch wenn man zugesteht, dass eine derartige Vision nicht in einem Schritt erreicht werden kann, sollen die in diesem White Paper angeführten Ausführungen demonstrieren, welche konkreten ersten Schritte heute schon in der Lage sind, die Unternehmen in diese (richtige) Richtung zu bringen. III. BASISDEFINITIONEN In diesem Abschnitt sollen die Definitionen der wichtigsten Begriffe im Umfeld und Kontext von BPM bzw. BPMS eingeführt werden. A. Prozesse Ausgehend von zahlreichen zum Teil sehr unterschiedlichen Definitionen von "Prozess" können jedoch die folgenden Gemeinsamkeiten festgehalten werden (vgl. Abbildung 1 und [4]- [6]). 2

3 Abb. 1: Definition von "Prozess" Ein Prozess ist eine strukturierte und gesteuerte Folge von Aktivitäten (in der Regel von Menschen, aber auch von sonstigen Systemen), die angibt, wie aus einem vorgegebenen Input ein bestimmtes Ergebnis ("Output") erzeugt werden soll (Thomas Davenport hat das einmal sehr prägnant eine Structure for Action genannt [6]). Darüber hinaus in den meisten Fällen klar, dass Prozesse immer eine bestimmte Infrastruktur benötigen, um ablaufen zu können (nicht nur IT Systeme, sondern bspw. Fahrzeuge zum Transport von Personen oder Sachen, Maschinen zur Verarbeitung von bestimmtem Input u.a.m.). Dieses "Wegabstrahieren" der Details der inneren Struktur der Aktivitäten führt dann zu der nachfolgenden Darstellung eines abstrakten "Prozesses" in Abbildung 2. 3

4 Abb. 2: Abstraktionsschritt von Struktur zum Prozess Es ist weiter deutlich, dass einerseits die Prozesse auf der abstrakten Ebene von Aktivitätsflüssen einfach modelliert (bzw. graphisch dargestellt) werden können, andererseits aber praktisch alle wichtigen Prozesse innerhalb von Unternehmen die IT (bzw. geeignete Applikationen) zur Unterstützung benötigen. Dieser oft komplexe Zusammenhang ist schematisch in der nachstehenden Abbildung 3 wiedergegeben. 4

5 Abb. 3: Vom Prozess zu den IT-Systemen Das Herstellen dieser notwendigen Verbindungen von den Aktivitäten bis hinunter zu den IT Systemen bleibt (bzw. ist) in vielen Fällen Aufgabe der IT Abteilung. Dabei hat sich die Strukturierung der Analyse im Rahmen des sogenannten process-driven Architecture (PDA) Modells Prozessintegration (einschließlich der Modellierung und Digitalisierung der Prozesse) Informationsintegration (inklusive Methoden des Semantic Webs) Service Integration (unter Berücksichtung von Konzepten einer service-orientierten Architektur, SOA) Technologie Integration (für das "Anflanschen" der bestehenden Systeme) bewährt (siehe [7] für eine ausführlichere Einführung). B. Geschäftsprozesse Wenn man reale Unternehmen in Prozesse gliedern möchte, wird einsichtig, dass es tendenziell sehr viele "Prozesse" im Allgemeinen Sinne in derartigen Organisationen geben wird. Daher wird man in der Regel seine Menge an Prozessen in geeigneten Schemata kategorisieren. Typisch ist hier die Gliederung in kleinere Prozesse ("Unterprozesse"), also entlang der Unterscheidung "besteht aus": Hauptprozess Prozess Teilprozess Prozessfragment Aktivitätskette bis hin zur (aus Prozesssicht) nicht mehr weiter teilbaren Aktivität. Die gröbste Kategorie wird dann typischerweise Geschäftsprozess genannt. Dabei wird bei einem Geschäftsprozess oft der Kunde oder die Kundenbeziehung in den Mittelpunkt gestellt, mitunter aber auch sonstige strategische (also für das Unternehmen langfristig wichtige) Ziele. Die Summe der einzelnen (kleineren) Prozesse, die alle der Erfüllung dieser Kun- 5

6 denanforderungen oder der strategischen Anforderungen ausgeführt oder zusammen gefasst werden, nennt man daher Geschäftsprozess (vgl. Abbildung 4 und [4] [6]). Abb. 4: Definition von Geschäftsprozess Innerhalb der Literatur (auch zwischen Akademikern und Praktikern) herrscht Uneinigkeit, wie viele Geschäftsprozesse (im hier angegebenen Sinne) ein "ordentliches" Unternehmen überhaupt haben kann. Die Angaben schwanken hier von mindestens 3 bis maximal 15. In unserer Erfahrung wird man sich hier oft bei der "magischen" Zahl 7 +/- 2 einpendeln. Als Beispiel für eine vergleichsweise allgemeine Gliederung von Unternehmen in Geschäftsprozesse sei auf die Tabelle 1 verwiesen. Anforderung Geschäftsprozess Ergebnis Kundenproblem Innovationsprozess Produktidee Produktidee Produktplanungsprozess Pflichtenheft Pflichtenheft Produktentwicklungsprozess Kundenbedarf Kundenbedarf Vertriebsprozess Kundenauftrag Kundenauftrag Auftragsabwicklungsprozess Lieferung Produktproblem Serviceprozess Problemlösung TABELLE 1. Allgemeine Geschäftsprozesse. In praktisch allen Fällen von Geschäftsprozessanalyse und Geschäftsprozessmanagement reichen allerdings die oben in Tabelle 1 angeführten allgemeinen Geschäftsprozess nicht aus, um das Unternehmen im Wettbewerb steuern zu können und man benötigt eigentlich immer branchenspezifische (in Wahrheit: unternehmensspezifische) Geschäftsprozesse, um 6

7 auf die notwendigen Unterschiede zwischen den verschiedenen Industrien und Segmenten eingehen zu können. Die graphische Zusammenstellung der Geschäftsprozesse wird oft Prozesslandkarte genannt. Als Beispiel ist in Abbildung 5 die Prozesslandkarte eines internationalen Versicherungskonzerns wieder gegeben. Abb. 5: Prozesslandkarte eines Versicherungskonzerns IV. GESCHÄFTSPROZESSMANAGEMENT MIT (IT-) SYSTEMEN A. Geschäftsprozessmanagement Geschäftsprozessmanagement (GPM), bzw. Business Process Management (BPM) ist nun selbst ebenfalls ein Prozess, nämlich der Steuerungsprozess von Analyse, Design, Modellierung, Implementierung, Umsetzung und Management von (Geschäfts-) Prozessen (vgl. Abbildung 6). An dieser Stelle muss nun ein (besonders in Österreich oft anzutreffendes) Vorurteil in Bezug auf BPM deutlich korrigiert werden: Sehr viele Unternehmen haben in der Vergangenheit begonnen, ihre Prozesse zu analysieren und zu modellieren. Diese Aktivitäten sind natürlich auch von entsprechenden Applikationen wie IDS Scheers ARIS oder ADONIS von BOC unterstützt worden. Dabei haben die Organisationen oft sehr viel Energie in Workshops (die berüchtigten "Brown Paper Sessions") gesteckt, wo am Flipchart interaktiv die aktuellen (Geschäfts-) Prozesse verfolgt, aufgezeichnet und danach in das Tool übertragen worden sind (oft zu Unrecht als "Kästchen malen" bezeichnet). Dabei sind etliche Organisationen dem (durchaus auch von Seiten der Berater nicht immer korrigierten) Trugschluss aufgesessen, dass sie bereits mit der Analyse und Modellierung alleine Geschäftsprozessmanagement betrieben hätten. Diese Vorstellung ist falsch. Am Ende der Modellierung hat man eben nur ein "Modell". 7

8 Richtig verstandenes Geschäftsprozessmanagement muss aber nun auch die allenfalls modifizierten oder optimierten Prozesse umsetzen, sowohl in den IT Systemen (Phase "Implementierung") als auch bei den handelnden Personen (Phase "Umsetzung"), und dann diese "laufenden" Prozesse entsprechend überwachen und steuern (Phase "Management" in Abbildung 6). Erst der volle und ganze Zyklus über alle sechs Phasen stellt dann echtes Geschäftsprozessmanagement dar. Abb. 6: Geschäftsprozessmanagement Wir dürfen auch darauf hinweisen, dass es im Gegensatz zu zahlreichen Darstellungen im echten Geschäftsprozessmanagement keine selbständige Phase "Optimierung" gibt. Optimierung selbst ist nämlich nichts anderes als das neuerliche Durchlaufen einer Analyse der bestehenden (eben suboptimalen) Prozesse, dem Design und der Modellierung der verbesserten (neuen) Prozesse, die wiederum in IT umgesetzt und dann in der Organisation verankert werden müssen. Im Kontext von Geschäftsprozessmanagement findet sich mitunter auch der Begriff des "Workflow Managements". Tatsächlich können weder die Praxis noch die Theorie eine einheitliche Abgrenzung von Workflow Management gegenüber dem Business Process Management vorbringen. Tendenziell fokussiert aber Workflow Management (man denke nur an die ersten Anfänge mit Lotus NOTES als Groupware System) stärker auf die IT-technische Implementierung (gegebenenfalls die Automatisierung) von Abläufen und vernachlässig die Sektoren Analyse Design Modellierung sowie das laufende Management. In der Praxis sind diese Unterschiede oft unerheblich; wichtig ist nur, dass innerhalb eines Unternehmens Klarheit herrscht, was unter Geschäftsprozessmanagement verstanden werden soll und was nicht. 8

9 B. Business Process Management Systeme (BPMS) Vor diesem Hintergrund eines ganzheitlichen Business Process Management ist auch die Definition eines Business Process Management Systems (BPMS) leicht [8]: Ein BPMS ist ein allgemeines IT System, das in der Lage ist, auf Basis eines ausdrücklichen Prozessmodells operative (Geschäfts-) Prozesse umzusetzen (= "enactment"), ablaufen zu lassen und diese zu managen. Im Gegensatz zu bekannten ERP Produkten wie SAP darf ein BPMS nicht nach einem Daten- bzw. Funktionsmodell ausgerichtet sein, sondern muss (!) sich vom Design her ausdrücklich an einem Prozessmodell ausrichten. Ein BPMS ist eben nicht yet another enterprise application, sondern ein neues Steuerungsinstrument auf einer höheren Ebene. Wichtig dabei ist, dass ein BPMS alle sechs Sektoren oder Bereiche von Geschäftsprozessmanagement (vgl. Abbildung 7) unterstützen muss. In dem Moment, wo sich die Funktionen eines (angeblichen BPM) Systems auf nur einige dieser Sektoren beschränken (bspw. unterstützt ARIS BUSINESS ARCHITECT von IDS Scheer nur die Phasen Analyse, Design und Modellierung), kann nicht mehr von einem echten BPMS gesprochen werden! Abb. 7: Funktionsweise eines BPMS Kernstück jedes BPMS ist eine Prozessmaschine ("process engine"), deren Aufgabe die Digitalisierung der vorher definierten Prozessmodelle ist. Bei dieser Digitalisierung übernimmt das BPMS im Sinne eines "elektronischen Dirigenten" das Kommando über die Ausführung der vorab definierten und strukturierten Aktivitäten. Jede einzelne Aktivität wird nun von der Prozessmaschine dahingehend untersucht, welcher Akteur sie tatsächlich ausführen soll. Diese Ressourcen können sowohl Menschen als auch selbst wiederum IT Systeme (Applikationen) sein. 9

10 Über bei der Prozessmodellierung bzw. beim Prozessdesign vorab definierte Regeln und Rollen stellt dann das BPMS fest, welche Person tatsächlich eine bestimmte Aktivität übernehmen soll. Diese Person wird daher über diese "offene" Aktivität informiert, typischerweise über einen (neuen) Eintrag in einem Arbeitskorb oder einer "Worklist" in einer geeigneten (Web-) Oberfläche. Wenn nun die betreffende Person bereit ist, diese Aktivität auszuführen, "springt" sie mit Hilfe der (Web-) Oberfläche zum entsprechenden Aktivitätsschritt und führt diesen entsprechend aus. Hier werden die entsprechenden Applikationen sehr oft direkt in das GUI des BPMS integriert, sodass der Endbenutzer seine BPMS Oberfläche praktisch nicht mehr verlassen muss. Sobald der Endbenutzer die aktuelle Aktivität beendet, erkennt dies das BPMS automatisch und steuert daher im Prozessmodell die nächste Aktivität an, die wiederum einen Endbenutzer (oder einer IT Applikation) zugeordnet wird. Dies geht soweit, dass an Verzweigungspunkten (wo sich der Prozessfluss abhängig vom aktuellen Zustand in mehrere Flüsse aufteilt) das BPMS selbständig die entsprechenden Regeln (man spricht von Business Rules) automatisch auswertet und die (richtige) nächste Aktivität ansteuert. Auf Basis dieser Funktionsweise ist nun klar ersichtlich, dass das BPMS automatisch praktisch alle (!) quantitativen Leistungsdaten der abgearbeiteten Prozesse erkennen und aufzeichnen kann. Das reicht von Durchgangs-, Warte- oder Zykluszeiten bis hin zu Statistiken, welche Rolle in welchem Zeitraum wie oft bestimmte Aktivitäten erledigt hat. Bei Einsatz eines BPMS ist daher die Ermittlung von Produktivitätskennzahlen oder KPIs (Key Performance Indicators) besonders leicht möglich. Und derartige Daten sind nicht nur für das Management der laufenden und aktuellen Prozesse, respektive Prozessinstanzen notwendig (oft Business Activity Monitoring [BAM] genannt), sondern stellen letztlich das quantitative Fundament für jede Prozessoptimierung auf Basis von historischen Leistungs- und Performanzdaten dar. Letzteres wird mitunter auch Business Performance Management (BPM) genannt. C. Technischer Aufbau eines BPMS In technischer Hinsicht sind BPMS oft in einer 4-tier Architektur aufgebaut (vgl. Abbildung 8). Das unverzichtbare Kernstück ist dabei die Prozessmaschine ("Enactment" bzw. "Process Engine"), in der die Prozessdefinitionen "abgearbeitet" (interpretiert) werden. Endbenutzer greifen typischerweise über einen Web Client auf das BPMS zu (linke untere Hälfte der Abbildung 8), der bspw. den Arbeitskorb ("Worklist") darstellt. Technisch wird der Client Zugriff oft über einen dezidierten Web Tier (eine JSP/Servlet Implementierung) realisiert, da sich über diese Schicht auch Zugänge vom öffentlichen Internet über eine DMZ ("demilitarized zone"), in der der Web Tier steht, einfach implementieren lassen. In manchen Fällen ist aber auch die Implementierung von Thick Clients notwendig, die bevorzugt über Java realisiert werden sollten. Notwendige Voraussetzung für die Möglichkeit, derartige Thick Clients überhaupt programmieren zu können, ist allerdings ein geeignetes Application Programming Interface (API) (in Java), über das die gesamte Funktionalität des BPMS auch von einer Applikation aus angesprochen werden kann (in Abbildung 8 wird dieser API MODEL API genannt). 10

11 Abb. 8: Technischer Aufbau eines BPMS Auf der "Rückseite" des BPMS sind Schnittstellen zu allen anderen IT Systemen innerhalb des Unternehmens vorzusehen. Dies umfasst typischerweise Schnittstellen zu einem Directory System für die Identifizierung und Authentisierung der BPMS Benutzer (bspw. LDAP), zu einem Document Management System (DMS, im einfachsten Fall ein File System), zu den diversen (relationalen) Datenbanken (oft über ODBC oder JDBC), zu Messaging Systemen (von via SMTP bis hin zum Versenden von SMS über GSM Schnittstellen), zu (Web-) Services im Rahmen einer service-orientierten Architektur (SOA) sowie zu allen anderen Systemen. D. BPM ist Management Thema, nicht (nur) IT Thema Durch den Fokus auf Prozesse und damit implizit auf die dafür notwendigen Grundlagen und Voraussetzungen wie Organisationsstruktur, Mitarbeiter und andere ist damit die Einführung von BPM auch überhaupt kein IT Thema, sondern ein Thema auf Top Management Ebene. Das wird in der Folge weiter verdeutlicht, wenn wir den möglichen Nutzen von BPM, also den Return on Investment (ROI) beim Einsatz eines BPMS betrachten: Dort ist die IT (also insbesondere der Einsatz eines BPMS) das Mittel für die Erreichung von Prozess(verbesserungs)zielen. E. Business Case von BPM(S) Eine Studie über die Produktivität der österreichischen Unternehmen [9] hat eine durchschnittliche Produktivität der Mitarbeiter von nur 60% ergeben, das entspricht einem jährlichen Produktivitätsverlust von etwa 87 Arbeitstagen pro Mitarbeiter. Davon sind mehr als 70% dieser Blindleistung im Wesentlichen auf Reibungsverluste bei den Unternehmensprozessen selbst und bei der Prozesssteuerung zurückzuführen. Die Einführung von BPM und eines BPMS haben nun unter anderem diese 70% Produktivitätsverluste im Visier, wobei die Erfahrungen aus der Beratungspraxis und internationalen 11

12 BPM Projekten nahe legen, dass sich die tatsächlich erzielten Produktivitätssteigerungen zumindest (!) im Bereich von 30% bewegen: Eine Zahl, die angesichts der oben angeführten hohen Verlustleistung fast noch gering erscheint. Prozess ROI Total Costs of Process Ownership Hard Facts Geschwindigkeit Flexibilität Durchsatz Zuverlässigkeit Qualität des Outputs Produktivität Effizienz Soft Facts Prozesskultur Kommunikation Mitarbeitermotivation systemisches Denken Prozess Change Management Umsetzungsgeschwindigkeit Flexibilität Prozess Umsetzungsmanagement Automatisierungsgrad Customization Messbarkeit Steuerbarkeit Abdeckungsgrad der Wertschöpfungskette Transaktionsfähigkeit Extended Enterprise TABELLE 2. Zwei Treiber des BPMS ROIs. Im Detail wird die wirtschaftliche Rechtfertigung von BPM Projekten (Stichwort: return on investment, ROI) vor allem durch zwei unterschiedliche ROI Treiber geleistet: Prozess ROI Dies ist der "klassische" Return on investment durch den verbesserten Prozess an sich, der sich analog zu alternativen Prozessverbesserungsmethoden (bspw. Six Sigma oder Kaizen) zusammensetzt Total Costs of Process Ownership Return on investment durch eine Verbesserung des Prozessmanagements, insbesondere bei den (immer unvermeidbarer werdenden) Änderungen von Prozessen (Stichwort: Wie viel ist meine zukünftige Flexibilität der Prozesse wert?) Diese Treiber sind in der Tabelle 2 noch weiter erläutert. Für den Prozess ROI finden wir bei der Einführung von BPMS dieselben ROI Treiber bzw. ROI Elemente wie bei einem "klassischen" Prozessverbesserungsprojekt auch ohne BPMS. Typische Größenordungen der erzielbaren Verbesserungen sind in der Abbildung 9 wiedergegeben. 12

13 Abb. 9: Typische Elemente des Prozess ROIs Dabei werden oft neben klassischen Erfolgsrechnungen (wie bspw. die dynamische Cash Flow Rechnung, DCF) auch modernste finanzmathematische Methoden eingesetzt, die derzeit in Österreich tlw. noch nicht bekannt sind. Darunter fallen unter anderem die Methode der Realoptionen [10], die erstmals in der Lage ist, den Wert von (Prozess-) Flexibilität sichtbar zu machen, und der Economic Value Added von Prozessen (EVA-Pr, [11]). F. Erster Schritt Trotz dieses klaren und deutlichen Business Cases ist der erste Schritt zur Initiierung eines entsprechenden BPM Projektes typischerweise auf höchster Management Ebene vorzunehmen (vgl. die Schicht "Strategie und Management" in der Abbildung 10). Da (wie oben dargestellt) die Einführung von Prozessen überhaupt und die von Business Process Management im Speziellen die gesamte Organisation betrifft, muss es für ein derartiges Change Projekt (um ein solches handelt es sich auch) ein entsprechend autorisierter Sponsor identifiziert werden. Erst wenn Geschäftsführung oder Vorstand als ein derartiger Sponsor die Motivation und Treiber von Business Process Management für ihr Unternehmen erkannt und die entsprechend individuelle BPM Vision für ihre Organisation grob entwickelt haben, erst dann kann ein BPM Projekt in die Definitions-, Planungs- und Umsetzungsphase gehen. 13

14 Abb. 10: Evolutiver Einführungsansatz von BPMS Da sich die Durchlaufzeit derartiger Projekte allerdings in einem Rahmen von 4 bis 8 Monaten bewegt, kommt der Auswahl eines möglichen (Implementierungs-) Partners dabei besondere Bedeutung zu: Dabei sind nicht nur strategisches Wissen und prozessorientiertes Branchenwissen notwendig, sondern auch sehr gute IT Kenntnisse, um letztlich die durchaus abstrakt definierten Prozesse mit der real existierenden Applikationslandschaft (idealerweise in einer service-orientierten Architektur) verbinden zu können. Abschließend sei noch einmal auf den evolutiven Charakter von BPMS Einführungsprojekten hingewiesen, die eben keinen Big Bang (wie etwa die Einführung eines ERP Systems) voraussetzen. Allerdings gibt es schon so etwas wie eine Initiation (rite de passage) von Organisationen in Bezug auf BPMS Projekte: Es gibt Unternehmen, die (mitunter auch sehr lange) bloß über BPM und BPMS Projekte reden und dann gibt es Unternehmen, die handeln, die in einem nicht trivialen Pilotprojekt tatsächlich in ihrer lebendigen Organisation herausfinden wollen, ob und gegebenenfalls wo in ihrer je individuellen (Wettbewerbs-) Situation BPM mit Hilfe von BPMS einen Sinn macht (das entspricht dem Übergang von der Stufe Apprentice [= Lehrling] zum Practitioner in Abbildung 10). Und darüber, meinen jedenfalls diejenigen, die schon BPMS Projekte erfolgreich realisiert haben, würde sich ein detailliertes Nachdenken schon auszahlen. DANKSAGUNG Der Autor bedankt sich für die stimulierenden Diskussionen innerhalb der Software AGs Core BPM Group (Darmstadt, BRD) unter der Leitung von Tobias Rother. Spezieller Dank gebühren Carsten Kreß und Lars Drexler, die als erste den Autor in das Gebiet und die spannende Thematik eingeführt haben. 14

15 REFERENZEN [1] Michael Hammer & James Champy, Reengineering the Corporation. A Manifesto for Business Revolution. HarperCollins, [2] Alfred Rappaport, Creating Shareholder Value: A Guide for Managers and Investors. New York (NY): Free Press [3] Howard Smith & Peter Fingar, Business Process Management. The Third Wave. Tampa (FL): Meghan-Kiffer Press [4] J. Becker and D. Kahn, Der Prozess im Fokus, in J. Becker, M. Kugeler and M. Rosemann Eds. Prozessmanagement. Ein Leitfaden zur prozessorientierten Organisationsgestaltung. 5th edition, Berlin, BRD: Springer-Verlag, 2005, pp. 7. [5] H. J. Schmelzer and W. Sesselmann, Geschäftsprozessmanagement in der Praxis. München, BRD: Hanser, 2004, ch. 2. [6] T. Davenport, Process Innovation. Reengineering Work through Information Technology. Boston, MA: Harvard Business School Press, 1993, ch. 2. [7] Christoph F. Strnadl, Aligning Business and IT. The Process-driven Architecture (PDA) Model. Information Systems Management, accepted for publication. (auch vom Autor direkt erhältlich) [8] M. Weske, W. M. P. van der Aalst and H. M. W. Verbeek, Advances in business process management, Data & Knowledge Eng. vol. 50, pp. 1 8, [9] Proudfoot International, International Labor Productivity Study [10] Lenos Trigeorgis, Real Options. Managerial Flexibility and Strategy in Resource Allocation. Cambridge (MA): MIT Press [11] Michael Gaitanides, Processonomics Prozessmanagement ist Wertmanagement. Zeitschrift Führung + Organisation (zfo) 71. Jg. (2002), Heft 4,