BPM Projektbeispiel Umsetzung der Bestellanforderung (BANF) gemäß IBPM-Vorgehensmodell 26. Mai 2011 Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org
Inhalt Zusammenfassung... 4 Enterprise BPM... 4 1 Integrierte BPM-Projektmethodik (IBPM)... 5 IBPM-Framework... 6 IBPM-Vorgehensmodell... 10 IBPM-Patterns... 11 2 Firma Good Goods und die Bestellanforderung... 12 3 Planung des BANF-Projektes... 13 Prozessperspektive... 13 Serviceperspektive... 14 Projektplan... 16 Projektantrag... 17 4 Arbeitspaket PO-A... 19 A. Prozessmodell (PO-A)... 19 B. Prozessorganisation / Rollen (PO-A)... 21 C. User Task Management (PO-A)... 22 D. Geschäftsregeln, (PO-A)... 22 E. Prozessanalyse und Reporting (PO-A)... 23 5 Arbeitspaket SO-A... 24 F. SOA-Komponentisierung (SO-A)... 24 G. Frontends und UI-Design (SO-A)... 26 H. Prozesskomponenten (SO-A)... 26 I. Business-Objekte und Backend-Komponenten (SO-A)... 27 J. Technische Architektur und Infrastruktur (SO-A)... 28 Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 2
6 Arbeitspaket PO-D I... 29 A. Prozessmodell (PO-D I)... 29 B. Prozessorganisation und Prozessrollen (PO-D I)... 31 C. User Task Management (PO-D I)... 34 D. Geschäftsregeln (PO-D I)... 34 E. Prozessanalyse und Reporting (PO-D I)... 35 7 Arbeitspaket SO-D I... 39 F. SOA-Komponentisierung (SO-D I)... 39 G. Frontends und UI-Design (SO-D I)... 42 H. Prozesskomponenten (SO-D I)... 44 I. Business-Objekte und Backend-Komponenten (SO-D I)... 45 J. Technische Architektur und Infrastruktur (SO-D I)... 47 8 Arbeitspaket PO-D II... 48 A. Prozessmodell (PO-D II)... 48 B. Prozessorganisation und Prozessrollen (PO-D II)... 52 C. User Task Management (PO-D II)... 52 D. Geschäftsregeln (PO-D II)... 55 E. Prozessanalyse und Reporting (PO-D II)... 56 9 Arbeitspaket SO-D II... 57 F. SOA-Komponentisierung (SO-D II)... 57 G. Frontends und UI-Design (SO-D II)... 61 H. Prozesskomponenten (SO-D II)... 65 I. Business-Objekte und Backend-Komponenten (SO-D II)... 66 J. Technische Architektur und Infrastruktur (SO-D II)... 69 10 Konklusion... 70 Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 3
Zusammenfassung Praxisbeispiele sind einer der effizientesten Wege, um Projektmethodiken für die eigene Arbeit zu adaptieren und fruchtbar zu machen. Anhand des Fallbeispiels der Bestellanforderung (BANF) wird in diesem Themenschwerpunkt die Anwendung der Integrierten BPM- Projektmethodik (IBPM) aus dem Buch Enterprise BPM vorgestellt. Enterprise BPM Enterprise BPM bietet eine vollständige und in sich geschlossene Methodik zur Umsetzung von BPM auf Unternehmensebene. Es gibt dem Leser das notwendige Praxiswissen an die Hand, um einzelne BPM-Projekte effizient umzusetzen und strategische BPM-Initiativen zum Erfolg zu führen. Der Schwerpunkt des Buches liegt auf der Darstellung der»integrierten BPM-Projektmethodik«(IBPM). Mit IBPM können BPM-Projekte klar strukturiert und mit einheitlichem Vorgehen unter Anwendung von Best Practices durchgeführt werden. Weiter wird das»enterprise BPM-Framework«(EBPM) zur Einführung von BPM auf Unternehmensebene vorgestellt. Expertenmeinungen und Fallbeispiele von Firmen wie Credit Suisse, Degussa Bank, Deutsche Lufthansa AG, BAA Heathrow und Deutsche Post AG beleuchten die Umsetzung in der Praxis. Auf der Website des Buchs finden sich u.a. Dokumentvorlagen, die IBPM und EBPM unterstützen, der Pattern-Katalog sowie das BANF-Beispiel aus diesem Text in ausführlicher Form. Außerdem werden auf der Webseite regelmäßig BPM-Themenschwerpunkte wie dieser veröffentlicht (www.enterprise-bpm.org, info@enterprise-bpm.org). Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 4
1 Integrierte BPM-Projektmethodik (IBPM) Viele fachliche Prozessoptimierungen (Stichwort: kontinuierlicher Verbesserungsprozess, KVP) setzen die Durchführung von BPM-Projekten voraus. Das heißt, die effiziente Durchführung von BPM-Projekten auf IT-Seite ist Grundlage des KVP auf der Business-Seite. Außerdem muss sichergestellt sein, dass jedes Projekt einen Beitrag zum Auf- und Ausbau von BPM und SOA leistet, damit der KVP unterstützt werden kann (als Beispiel sei hier die Trennung von Prozessfluss und Entscheidungslogik genannt, die ein wesentliches BPM/SOA-Konzept ist und maßgeblich dazu beiträgt, dass Prozesse ohne das Aufsetzen eines Projekts, nur durch Anpassung der Regeln optimiert werden können). Daher muss sichergestellt sein, dass die Lieferergebnisse der Projekte konform mit den Architekturanforderungen von BPM und SOA sind. Abb. 1 zeigt den typischen Ablauf eines einzelnen BPM-Projektes. Abbildung 1: Einordnung der Integrierten BPM-Projektmethodik (IBPM) in ein BPM-Gesamtprojekt Um diesen Anforderungen sowohl effiziente Durchführung als auch BPM/SOA-kompatible Projektergebnisse gerecht zu werden, fasst die Integrierte BPM-Projektmethodik (IBPM) alle wichtigen Aspekte von BPM in einen einheitlichen Methodikansatz zusammen. Dies ist insbesondere durch die 10 Säulen des IBPM-Frameworks sichergestellt, die eine integrierte Sicht auf das Zusammenspiel aller möglichen Aspekte eines BPM-Projekts geben. Wichtig ist uns an dieser Stelle, dass wir das Rad nicht neu erfinden. Es gibt heute bereits diverse Vorgehensmodelle für die Softwareentwicklung, vom V-Modell XT über den Rational Unified Process (RUP) bis hin zu agilen Methoden wie SCRUM. IBPM fokussiert daher auf die inhaltli- Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 5
chen Spezifika eines BPM-Projekts und kann mit jeder dieser mehr generischen IT-Projektmethodiken kombiniert werden. Um die inhaltlichen Spezifika eines BPM-Projekts erfassen und meistern zu können, sind drei Kernelemente wesentlich, die zusammen die IBPM-Methodik bilden: Das Framework definiert die Inhalte von BPM-Projekten Das Vorgehensmodell gibt die Grundstruktur der Phasen und Arbeitspakete vor Die Entwurfsmuster helfen bei der Bearbeitung der Arbeitspakete Bevor wir in das Projektbeispiel einsteigen, werfen wir zunächst einen kurzen Blick auf diese drei Kernelemente, damit Sie die zugrundeliegende Mechanik besser verstehen. Wir beginnen beim Framework. IBPM-Framework Wie in Abb 2 zu sehen ist, beschreibt das IBPM-Framework zunächst einmal das Zusammenspiel eines einzelnen Projekts mit der Unternehmensebene. Hierbei spielt die Einordnung des Projekts in den Enterprise-Kontext eine wichtige Rolle. Dies betrifft insbesondere die Einordnung in Organisationsstruktur, Prozesslandkarte und Domänenmodell des Unternehmens sowie die Abhängigkeiten zwischen dem Projekt und den unternehmensweiten Services und Anwendungen. Auch die Erfassung und Auswertung der Abhängigkeiten von Projekten untereinander ist erfolgskritisch. Abbildung 2: Übersicht über das IBPM-Framework Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 6
Innerhalb des Projekts wird der Schwerpunkt dann auf das Zusammenspiel zwischen prozessund serviceorientierten Methoden gelegt. Aus Sicht von Prozessorientierter Analyse und Design (POAD) sind die folgenden Elemente in IBPM wichtig: IBPM-Säule A: Prozessdokumentation und Prozessdesign IBPM-Säule B: Prozessorganisation und Prozessrollen IBPM-Säule C: User Task Management IBPM-Säule D: Geschäftsregeln IBPM-Säule E: Prozessanalyse und Reporting Aus Sicht von Serviceorientierter Analyse und Design (SOAD) sind die folgenden Elemente in IBPM wichtig: IBPM-Säule F: SOA-Komponentisierung IBPM-Säule G: User Interface Design IBPM-Säule H: Prozesskomponenten IBPM-Säule I: Business-Objekte und Backend-Komponenten IBPM-Säule J: Technische Architektur In einem BPM-Projekt, das einen nachhaltigen Beitrag für Geschäft und IT im Sinne einer Managed Evolution liefern soll, muss die Prozessperspektive gleichberechtigt neben der Serviceperspektive stehen. Die Säulen helfen, die Inhalte jeweils klar zu definieren und die Abhängigkeiten zwischen ihren Elementen in den Griff zu bekommen. Handhabbar wird das, wenn man schrittweise von der Übersicht zum fachlichen und weiter zum Umsetzungsmodell vorgeht Dann kann das Projekt auch in kurzer Zeit produktiv nutzbare Ergebnisse mit Geschäftswert liefern. Lassen sie uns kurz ansehen, wie das gemeint ist. Die ersten fünf Säulen beschreiben Aspekte der Prozessperspektive (siehe Abb. 3). Wir sagen bewusst nicht fachliche Perspektive, denn auch in der Prozessperspektive spielen technische Dinge wie das BPMS oder das BRM-System eine wichtige Rolle in den Modellen. Die Elemente, die in der Prozessperspektive erfasst werden, kommen aber allesamt aus der Geschäftsarchitekturebene einer Unternehmensarchitektur. Das Hauptartefakt, in dem die Fäden der Prozessperspektive zusammenlaufen, ist das Prozessmodell (Säule A). Das Prozessmodell beschreibt geschäftliche Abläufe durch Geschäftsvorfälle (Ereignisse), Aktivitäten, Prozessflüsse und Konnektoren. Diese müssen von der zu erstellenden BPM-Lösung teil- oder vollautomatisiert umgesetzt werden. Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 7
Abbildung 3: Prozessperspektive Die restlichen fünf Säulen beschreiben Aspekte der Serviceperspektive (siehe Abb. 4). Wir sagen bewusst nicht IT-Perspektive, denn auch hier werden fachliche Fragestellungen behandelt. Die Elemente, die in der Serviceperspektive erfasst werden, kommen aber vorwiegend aus der Servicearchitekturebene der Unternehmensarchitektur plus zusätzlich aus der Applikationsarchitekturebene. Das Hauptartefakt, in dem die Fäden der Serviceperspektive zusammenlaufen, ist die SOA Map (Säule F). Die SOA Map beschreibt die Lösungsarchitektur in Form von fachlichen Komponenten und Services, die miteinander gekoppelt sind und Daten austauschen. Sie stellt außerdem die Verknüpfung zur Anwendungsarchitektur her, da sie zusätzlich angibt welche Applikation als physischer Servicegeber für den Service selbst fungiert. Abbildung 4: Serviceperspektive Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 8
Die SOA Map verknüpft außerdem die vier weiteren Säulen der Serviceperspektive: UI Design (Säule G), Prozesskomponenten (Säule H), Business-Objekte und Backend-Komponenten (Säule I) sowie die technische Architektur (Säule J). Jede der 10 Säulen gehört entweder zur Prozess- oder zur Serviceperspektive. Beide werden in BPM-Projekten benötigt. Daher legen wir in IBPM Wert darauf, beide Perspektiven parallel zueinander zu entwickeln und konsistent zu halten. Um das für ein Projekt handhabbar zu machen, führen wir zusätzlich fünf Detaillierungsebenen ein, die gut zu den generischen Phasen eines Projektes passen: 1. Planung 2. Analyse 3. Fachliches Design 4. Umsetzungsdesign 5. Umsetzung Führen wir nun die 10 Säulen der Prozess- und der Serviceperspektive mit den 5 generischen Phasen eines Projekts zusammen, dann ergibt sich eine 5 10-Matrix: Abbildung 5: Zusammenführen der Prozess- und Serviceperspektive in einem Mehrebenenmodell Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 9
Die so entstandene 5 10-Matrix ist die Grundlage des IBPM-Frameworks. Für die einzelnen Felder der Matrix bzw. des IBPM-Frameworks werden durch POAD bzw. SOAD konkrete Methoden und Ergebnistypen definiert. In Abb. 6 ist die Matrix noch einmal im Detail dargestellt. Abbildung 6: Übersicht IBPM-Framework mit den 10 thematischen Säulen und Detaillierungsebenen IBPM-Vorgehensmodell Das IBPM-Vorgehensmodell greift die thematischen Säulen und Detaillierungsebenen aus dem IBPM-Framework auf und bringt sie in die Form handhabbarer Projektphasen und Arbeitspakete für ein BPM-Projekt gebracht (siehe Abb. 7). Darüber hinaus gibt es Hilfestellungen, wer in welcher Rolle wann welche IBPM-Artefakte erstellt. Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 10
Abbildung 7: Arbeitspakete im IBPM-Vorgehensmodell Eingebettet in Planung und Umsetzung werden sechs Arbeitspakete definiert: Prozessorientierte Analyse (PO-A) Serviceorientierte Analyse (SO-A) Prozessorientiertes fachliches Design (PO-D I) Serviceorientiertes fachliches Design (SO-D I) Prozessorientiertes Umsetzungsdesign (PO-D II) Serviceorientiertes Umsetzungsdesign (SO-D II) Damit können Sie in der Projektarbeit schrittweise vorgehen, um mithilfe von POAD und SOAD umsetzungsreife Spezifikationen zu erstellen. IBPM-Patterns Bei der Bearbeitung der einzelnen Arbeitspakete haben sich einige Lösungsmuster für häufig wiederkehrende Entwurfsprobleme bewährt. Wir haben diese Lösungsmuster in 7 Gruppen strukturiert (siehe Tab. 1). Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 11
Gruppe Beschreibung 1 Process Interaction Welche Interaktionsmuster kann ein Prozess unterstützen? 2 Process/BO Wie modelliert man das Zusammenspiel von Prozessen und Geschäftsobjekten in einer SOA? 3 Process Portlets Welche Portlets finden sich in einem Prozessportal? 4 UI/Process Modelling Wie modelliert man das Zusammenspiel zwischen UI und Prozess? 5 Process Portal Wie modelliert man Prozesse, die innerhalb eines Portals ablaufen? 6 Process Networks Wie modelliert man vernetzte Prozesse und Geschäftsobjekte? 7 General Patterns Wie modelliert man Eskalation, Change Management und Monitoring? Tabelle 1: Gruppen von IBPM-Patterns Die Patterns bauen aufeinander auf. Angefangen bei grundsätzlichen Fragen, wie eine BPM- Prozessinstanz mit ihrem Umfeld (Benutzer und IT-Systeme) interagieren kann, bis hin zu allgemeinen Fragen der Modellierung von Eskalationen oder geplanten Änderungen an der Geschäfts- und Servicearchitektur helfen diese Lösungsmuster bei vielen Fragen weiter, die nach unserer Erfahrung im Projektverlauf auftreten. 2 Firma Good Goods und die Bestellanforderung Als Beispiel für die Anwendung der Integrierten BPM-Projektmethodik dient uns die fiktive Firma Good Goods AG, ein internationaler Hersteller besonders guter Güter. Im Rahmen des BPM- Programms der Good Goods AG wurden mehrere Projektkandidaten identifiziert, darunter auch im Bereich Beschaffung. Der Chief Operation Officer (COO), dem die Beschaffung untersteht, sieht hier große Optimierungspotenziale durch BPM und beauftragt den IT-Koordinator des Fachbereichs mit einer Vorstudie. Mit Hilfe der Unterstützung des BPM Competence Centers der Good Goods AG nimmt ein Projektkandidat mit dem Arbeitstitel BANF-Projekt nach kurzer Zeit konkrete Züge an. Daraufhin wird ein Projektleiter ernannt, der das Projekt aufsetzen soll. Der Projektleiter führt das Projekt mit Hilfe der IBPM-Methodik durch. Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 12
3 Planung des BANF-Projektes Dem Projektleiter wird ein Prozessanalyst zur Seite gestellt, der sich im Umfeld der Beschaffungsprozesse gut auskennt. Im Folgenden sehen sich Projektleiter und Prozessanalyst die Prozess- und Serviceperspektive an, danach leitet der Projektleiter den Projektplan ab. Siehe auch IBPM-Vorgehen, Projektphasen, Rollen und Planung. Prozessperspektive Der Prozessanalyst verortet zunächst das BANF-Projekt in der Prozesslandkarte der Good Goods AG. Vom BPM-Koordinator erhält er dazu die entsprechende Übersicht. Das Projekt betrifft den Hauptprozess Materialbestellung (siehe Abb. 8). Abbildung 8: Verortung des Projektes in der Prozesslandschaft der Good Goods AG Damit ist auch der Prozesseigner eine Ebene unterhalb des COO identifiziert. Es handelt sich um den Leiter Beschaffung, der für diesen Hauptprozess zuständig ist. Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 13
Die genauere Betrachtung der beiden Teilprozesse Bestellanforderung und Bestellung ergibt, dass einige grundsätzliche Entscheidungen bezüglich des Prozess-Scopes getroffen werden müssen, da es enge Abhängigkeiten zwischen Prozessen und zu beschaffenden Produktgruppen gibt. So unterscheiden sich Prozessabläufe, involvierte Organisationseinheiten und eingesetzte IT-Systeme für Produktions- und Nichtproduktionsgüter stark voneinander. Erstere erfolgen überwiegend katalogbasiert, letztere nicht. Darüber hinaus führen bestimmte Warengruppen wie etwa Dienstleistungen später zu Prozessvarianten im Bereich Wareneingang/ Rechnungsprüfung. An dieser Stelle wird entschieden, dass in der ersten Projektstufe lediglich der Beschaffungsprozess (BANF) abgebildet werden soll und zwar mit Fokus auf Nichtproduktionsgüter und Dienstleistungen. Des Weiteren stimmen Prozessanalyst und Projektleiter weitere wichtige Aspekte für den Projektumfang mit dem IT-Koordinator und dem Leiter Beschaffung ab: Organisation und Prozessrollen: Die neue Lösung soll von allen Mitarbeitern der Good Goods AG an den Standorten im Euro-Raum genutzt werden können. Zum Anwenderkreis gehören alle Antragsteller, Fachexperten, Kostenstellenverantwortlichen und der Einkauf. Prozessziele: Grundsätzlich wünscht der Prozesseigner eine höhere Transparenz bezüglich der bestellten Güter. Als weiteres Projektziel gibt er außerdem vor, die durchschnittliche Bearbeitungszeit für einen BANF-Vorgang auf unter 10 Werktage zu senken. Da derzeit nur grobe Schätzungen über die tatsächlichen Bearbeitungsdauern vorliegen und die Durchlaufzeiten stark von den Produktgruppen abhängen, etwa mit/ohne Automatisierung bzw. manuelle Freigabe, muss diese Zielsetzung im weiteren Projektverlauf noch präzisiert werden. Serviceperspektive Die Serviceperspektive bearbeitet der Projektleiter selbst. Voraussetzung für die Verortung des Projektes in der Service- und Anwendungslandschaft zur Bestimmung des relevanten Scopes sind die fachlichen Vorgaben aus der Prozessperspektive. Zunächst bespricht er das Projekt mit einem Enterprise-Architekten. Beide werfen einen Blick auf das unternehmenseigene Domänenmodell (siehe Abb. 9). Der Schwerpunkt der für das Projekt benötigten Services liegt nach derzeitigem Kenntnisstand in der Domäne Einkauf. Eine Rückfrage beim SOA-Koordinator ergibt, dass in dieser Domäne leider noch keine Services existieren oder geplant sind, die wiederverwendet werden können. Darüber hinaus werden einige Services aus Querschnittsdomänen benötigt, bspw. aus der Domäne Finanzen Services für die Zuordnung von Kostenstellen sowie aus der Domäne Informationsmanagement Services für die Dokumentenablage. In letzterer Domäne existieren bereits Services, deren Wiederverwendung im Projekt geprüft werden soll. Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 14
Abbildung 9: Verortung des Projektes im Domänenmodell der Good Goods AG Im nächsten Schritt klärt der Projektleiter, welche Aufgaben im Bereich der technischen Architektur und Infrastruktur zu bewältigen sind. Dazu spricht er mit dem IT-Koordinator, dem BPM- Koordinator, dem für die Domäne Logistik und Planung zuständigen Enterprise Architekten sowie einem IT-Experten, der Anwendungsverantwortlicher für den betroffenen Ausschnitt der Anwendungslandschaft ist. Abb. 10 zeigt den Projektscope, der sich aus der Diskussion ergibt: Abbildung 10: Projektscope Im Rahmen des BANF-Prozesses für Nichtproduktionsgüter und Dienstleistungen wird derzeit das System GGS (Good Goods System für die Abwicklung der Bestellung von Nicht- Produktionsartikeln) zusammen mit einem ERP-System eingesetzt. Das GGS-System soll durch Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 15
das Projekt komplett abgelöst und durch eine portalbasierte BPMS-Lösung ersetzt werden. Die neue portalbasierte Lösung muss ins Unternehmensportal integriert werden. Die BPMS- Plattform ist bereits im Hause im Einsatz. Projektplan Der Projektleiter geht nun daran, den Projektplan zu erstellen. Wichtige Ansprechpartner für ihn sind dabei der IT-Koordinator, der Programmanager des BPM-Programms sowie der Leiter Beschaffung als eigentlicher Auftraggeber. Das IBPM-Vorgehensmodell liefert ihm die Grundstruktur für den Projektplan und die benötigten Rollen für die Aufgabenpakete. Basierend auf seinen Erfahrungen aus ähnlichen BPM-Projekten geht er zunächst davon aus, dass die benötigten Ressourcen in vollem Umfang zur Verfügung stehen und legt folgenden Projektplan fest: Abbildung 11: Projektplan Am Anfang des Projektplans steht die Planungsphase selbst, in der der Projektleiter bereits mit einem Prozessanalysten gearbeitet hat. Sie soll nach vier Wochen mit der internen Genehmigung für das Projekt abgeschlossen werden. Für Analyse und Design werden 9 Wochen benötigt, um eine umsetzungsreife Spezifikation zu erstellen. Die Bearbeitung erfolgt in den sechs POAD/SOAD-Arbeitspaketen. Für die darauffolgende Umsetzung werden 7, für den Rollout nochmals 4 Wochen veranschlagt. Der Zeitpuffer pro Phase beträgt jeweils ca. 1 Woche. Paral- Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 16
lel laufen die Querschnittsaktivitäten (Projektmanagement, Qualitätsmanagement, Infrastruktur, u.ä.). Daraus ergibt sich folgender Meilensteinplan: KW 9 KW 13 Fachliches Design Meilenstein Inhalt Beschreibung KW 4 Projektplan Projektplan für das aktuelle Release (Ziele, Scope, Ressourcen, etc.) KW 6 Analysemodell Grobes Prozessmodell und Anforderungen Überblick über relevante Anwendungslandschaft Umsetzungsdesign Fachlich detailliertes Prozessmodell und Geschäftsregeln Komponentenmodell, UI-Entwurf und Datenmodell Erweitertes Prozessmodell mit umsetzungsrelevanten Zusatzinformationen sowie Spezifikation der benötigten Services und Komponenten KW 20 Release Release/Produkt erstellt und getestet Organisatorische Vorbereitung für die Einführung der neuen Prozesse und Systeme durchgeführt KW24 Inbetriebnahme Geschäftlicher und technischer Betrieb aufgenommen Tabelle 2: Meilensteine Außerdem plant der Projektleiter Sitzungen des Steuerkreises am Ende jeder Projektphase ein. Zusätzlich legt er eine weitere Sitzung in KW 9 fest. Dies ist gute Praxis, da erfahrungsgemäß im ersten Prozessmodell aus der Analysephase ( Happy Path ) noch viele Unwägbarkeiten stecken können, die anfangs nicht erkannt werden und erst im detaillierten fachlichen Design zu Tage treten. Da bei BPM-Projekten die Gefahr besteht, dass mit dem groben Analysemodell zu hohe Erwartungen bei den Anwendern geweckt werden, die mit dem ursprünglich geplanten Budget und Zeitplan nicht erfüllt werden können, ist eine Steuerkreis-Sitzung zu diesem Zeitpunkt ratsam, um gegebenenfalls entweder ein Re-Scoping durchzuführen oder Anforderungen auf spätere Releases zu verschieben. Der gesamte Projektplan muss natürlich noch mehr umfassen, bspw. Projektorganisation und Ressourcenplan Kostenschätzung und Festlegungen zum Budget Betrachtung von Abhängigkeiten und Risiken Angaben zu Projektnutzen und ROI Projektantrag Zum Abschluss der Planungsphase fasst der Projektleiter alle wesentlichen Ergebnisse in einem Projektantrag zusammen, der einem Entscheidungsgremium zur Genehmigung vorgelegt wird. Die folgende Abbildung zeigt ein typisches Inhaltsverzeichnis für ein solches Dokument: Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 17
Abbildung 12: Projektantrag Da der Projektnutzen überzeugt, das Budget und die benötigten Ressourcen zur Verfügung stehen und durch die vorbildliche Planung (schrittweises Vorgehen, klare Meilensteine, keine wesentlichen organisatorischen oder technischen Hürden) kein besonderes Projektrisiko erkennbar ist, gibt das Entscheidergremium grünes Licht für das Projekt. Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 18
4 Arbeitspaket PO-A Verantwortlich für die Erstellung der Ergebnisse dieses Arbeitspakets ist der Prozessanalyst. Er ist angewiesen auf Zuarbeiten des Prozessmanagers und weiterer Mitarbeiter aus dem Prozess. Siehe auch IBPM-Vorgehen, PO-A Prozessorientierte Analyse. A. Prozessmodell (PO-A) Der Prozessanalyst modelliert gemeinsam mit dem Prozessmanager und Mitarbeitern aus dem Geschäftsprozess ein erstes Soll-Prozessmodell. Dabei verwendet er nur eine kleine Teilmenge des BPMN-Symbolsets, um die Grundstruktur in Form eines sog. Happy Path festzulegen. Zusatzinformationen hält er in Kommentaren fest Die folgende Abbildung zeigt dies anhand unseres BANF-Beispiels. Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 19
Abbildung 13: Prozessmodell Analyse (Happy Path) Der Prozess wird angestoßen durch einen Mitarbeiter (Anforderer), der aufgrund seines Bedarfes eine BANF erstellt. Diese wird anschließend in mehreren Schritten bearbeitet und freigegeben. Bei bestimmten Gütern und Dienstleistungen, bspw. Laptops, Handys oder juristischer Beratung, ist eine zusätzliche Prüfung durch die zuständige Fachabteilung (Fachexperte) erforderlich. Anschließend muss der Kostenstellenverantwortliche (Manager) den Vorgang kaufmännisch genehmigen. Schließlich bearbeitet ein Mitarbeiter aus dem Einkaufsbereich (Einkäufer) die BANF, bündelt diese ggf. und leitet den Bestellvorgang ein. Die Bestellung selbst ist ein Folgeprozess, der nicht mehr im Scope des Projektes liegt. Schon in diesem einfachen Ablauf stecken einige Besonderheiten und weiterführende Fragen, bspw. dass die kaufmännische Freigabe mehrstufig sein kann, dass aus einer BANF mehrere Bestellungen resultieren können oder die Frage, was geschieht, wenn die Freigabe nicht erteilt wird. Alle diese Fälle werden im fachlichen Design genauer zu betrachten sein. Siehe auch IBPM-Framework, Säule A. Prozessmodell. Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 20
B. Prozessorganisation / Rollen (PO-A) Zusammen mit der Erstellung des Prozessmodells müssen alle relevanten Prozessrollen identifiziert werden. Die operativ tätigen Rollen wurden bereits im Prozessmodell bestimmt, um die einzelnen Lanes zu beschriften. Dabei wurden identifiziert: Anforderer Fachexperten für fachliche Freigabe Kostenstellenverantwortliche für kaufmännische Freigabe Einkäufer Von besonderem Interesse sind hier in der Analysephase das damit verbundene Mengengerüst und der geografische Standort der Aufgabenträger. So geht es bei den Anforderern bspw. um mehrere hundert Mitarbeiter, verteilt auf verschiedene europäische Standorte. Daraus ergeben sich Anforderungen an technische Architektur (bspw. Anbindung) und Software (bspw. Mehrsprachigkeit). Darüber hinaus müssen alle weiteren relevanten Stakeholder identifiziert werden. Am wichtigsten sind dabei Prozesseigner: hier der Leiter Beschaffung Prozesscontroller: hier ein Mitarbeiter des Leiters Beschaffung Prozessmanager: hier der Teamleiter Einkauf Zentrale Falls zu diesem Zeitpunkt noch nicht klar sein sollte, wie die Rollen Prozesseigner und Prozessmanager besetzt sind, sollte der Prozessanalyst über den Projektleiter geeignete Maßnahmen anstoßen, um diese zu bestimmen. Anderenfalls fehlen ihm die Ansprechpartner für fachliche Anforderungen und Entscheidungen. Darüber hinaus muss der Prozessanalyst weitere Quellen erschließen und Informationen sammeln, die für den Bau einer BPM-Lösung vonnöten sind. Kernfragen sind: 1. Wo sind Informationen über die Organisation und Rollen zu finden? 2. Wo sind nutzerbezogene Informationen (Accounts u. IDs, Rollen u. Rechte) zu finden? Ansatzpunkte zu 1. sind Organigramm (Ansprechpartner HR) Verwaltung von Benutzerdaten (Ansprechpartner IT) Nachbarprojekte (Ansprechpartner Programmmanagement) Ansatzpunkte zu 2. sind Kandidaten wie ADS, LDAP, HR-System (SAP HR, Peoplesoft, etc.), Intranet / Portal Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 21
Gibt es überhaupt ein Repository mit allen Nutzern, die als Prozess-Stakeholder identifiziert wurden? Hat dieses Repository alle benötigten Zusatzinformationen? Gibt es evtl. schon Rollendefinitionen, die wiederverwendet werden können? Gibt es einen OnBoarding-Prozess und Administrationsmechanismen für die Rollen? Siehe auch IBPM-Framework, Säule B. Prozessorganisation & -rollen. C. User Task Management (PO-A) Im Themenfeld User Task Management diskutiert der Prozessanalyst einige grundsätzliche Fragen zur Arbeitsorganisation und zum Prozessablauf. Seine Gesprächspartner sind hier wieder der Prozessmanager und ausgewählte Prozessbeteiligte. Die wichtigsten Fragepunkte sind: Kanban-Potenzialanalyse: Kann der Prozess von einem Push-Modell auf ein Pull-Modell umgestellt werden? Task Pooling / personenbezogene Zuordnung: Wer soll mit dem Prozessportal arbeiten? Wie soll die Arbeitsorganisation aussehen? Müssen organisatorische Maßnahmen getroffen werden (bspw. Bildung neuer Teams)? Stellvertreterregelung: Wie ist die Stellvertreterregelung im Einkauf und den benötigten Fachabteilungen heute geregelt? Sind Änderungen nötig oder geplant? Eskalationen: gibt es besondere Vorgaben oder kritische Punkte im Prozessablauf (bspw. Kundenzusagen, SLAs), an denen geprüft werden muss, was geschehen soll, wenn bestimmte Parameter oder Zeiten überschritten werden? Mengengerüst: wie viele Vorgänge sind zu Produktionsbeginn und in den folgenden Jahren zu erwarten? Ist mit Spitzenbelastungen od. sehr hohen Datenvolumina zu rechnen? Siehe auch IBPM-Vorgehen, Säule C. User Task Management. D. Geschäftsregeln, (PO-A) Als nächstes versucht der Prozessanalyst herauszufinden, ob es bereits Unterlagen oder Systeme gibt, die Geschäftsregeln im Zusammenhang mit dem BANF-Prozess beschreiben. Hier stellt sich heraus, dass es im Einkauf ein Excel-Spreadsheet gibt, in dem definiert ist, nach welchen Regeln fachlich und kaufmännisch freigegeben werden muss. Diese Excel-Datei wird später im Design bei der Spezifikation der Geschäftsregeln genutzt werden. Darüber hinaus erfährt er, dass derzeit eine Controlling-Datenbank aufgebaut wird, in der Angestellte mit folgenden Informationen verwaltet werden: Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 22
Zugeordnete Managementhierarchieebene Verantwortete Cost Center Vorgesetztenverhältnisse Diese Datenbank enthält also wichtige Informationen zur Ausführung des Geschäftsprozesses und zur Anwendung der Geschäftsregeln. Der Prozessanalyst gibt diese Informationen an den Lösungsarchitekt und den Projektleiter weiter, da hier entschieden werden muss, ob diese Datenbank weitergebaut werden soll und wie die technische Architektur für die BANF und die darin enthalten Geschäftsregeln aussehen soll. Eine Entscheidung soll später im Umsetzungsdesign getroffen werden. Siehe auch IBPM-Vorgehen, Säule D. Geschäftsregeln. E. Prozessanalyse und Reporting (PO-A) Schließlich bespricht der Prozessanalyst mit Prozesseigner (Leiter Beschaffung), Prozesscontroller (Mitarbeiter Leiter Beschaffung) und Prozessmanager (Teamleiter Einkauf), welche Anforderungen hinsichtlich Prozessanalyse und Reporting bestehen. Da es sich hier um die Ersteinführung eines BPM-gestützten Prozesses im Einkaufsbereich handelt, wird zunächst lediglich eine einfache Prozesssteuerung angestrebt. Der Prozessmanager und sein Team benötigen außerdem Informationen darüber, ob die vorgegebene Projektzielsetzung erreicht wird. In späteren Ausbaustufen sollen dann weitere Auswertungsmöglichkeiten ergänzt werden. Deren Bestimmung wird eine Aufgabe des KVP-Prozesses werden. Für dieses Release werden daher folgende Auswertungsmöglichkeiten festgehalten: Monatliche Anzahl an BANF-Vorgängen Durchlaufzeit (max. 10 Tage) Welches Volumen (monetär) wurde je Produktkategorie genehmigt? Alle Informationen sollen für den Einkauf und den Leiter Beschaffung sichtbar sein. Der Leiter Beschaffung erwartet überdies einen monatlichen Bericht mit den wesentlichen Prozesskennzahlen. Diese sollen vom Prozesscontroller in das monatliche Gesamtreporting integriert werden. Der Prozessmanager soll den Bericht vor Abgabe einsehen und kommentieren können. Außerdem soll der Prozessmanager einen Prozessleitstand erhalten, mit dem er eine Übersicht über den aktuellen Prozessstatus erhält. Der Prozessleitstand soll auch vom Prozesscontroller und den Einkäufern eingesehen werden können. Siehe auch IBPM-Vorgehen, Säule E. Prozessanalyse und Reporting. Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 23
5 Arbeitspaket SO-A Verantwortlich für die Erstellung der Ergebnisse dieses Arbeitspakets ist der Lösungsarchitekt. Er arbeitet dazu eng mit dem Prozessanalyst zusammen und schaltet sich in die Workshops mit dem Fachbereich ein. Darüber hinaus konsultiert er bei Bedarf Ansprechpartner aus der IT. Siehe auch IBPM-Vorgehen, SO-A Serviceorientierte Analyse. F. SOA-Komponentisierung (SO-A) Der Lösungsarchitekt macht sich zum Beginn seiner Arbeiten mit dem Arbeitsstand des Prozessanalysten aus dem Arbeitspaket PO-A vertraut. Anschließend klinkt er sich in die Workshops mit den Fachbereichen ein, deren Agenda um für ihn relevante Fragestellungen erweitert werden. Als Einstieg in die serviceorientierte Perspektive hat es sich bewährt, mittels einer einfachen Tabelle eine Ist- und Soll-Darstellung der fachlichen Anwendungslandschaft zu erstellen (SOA Quick-Check). Die Informationen können sowohl von Mitarbeitern aus der IT als auch aus dem Fachbereich abgefragt werden. Hierzu werden fünf Fragen gestellt und gemeinsam die Antworten erarbeitet: 1. Welche Anwendungen spielen bei der Arbeit eine Rolle? 2. Je Anwendung: Welche Daten werden dort bearbeitet? 3. Je Anwendung: Wer arbeitet damit? 4. Je Anwendung: Mit welchem Frontend wird gearbeitet? 5. Je Anwendung: Welche Prozesse werden unterstützt? Außerdem werden bei Bedarf noch ein- oder mehrere Spalten für manuelle Tätigkeiten ergänzt (je eigenständigem Prozess oder größerer Nutzergruppe eine Spalte). Die folgende Abbildung 14 zeigt das Ergebnis im IST für das BANF-Projekt. Aus der Ergebnismatrix des SOA Quick- Checks geht hervor, dass der BANF-Prozess heute komplett manuell abgewickelt wird. Die Einkäufer arbeiten parallel mit dem GGS- und dem ERP-System. Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 24
Abbildung 14: SOA Quick Check IST Im nächsten Schritt wird das Verfahren angewendet, um die SOLL-Sicht zu entwerfen (siehe Abb. 15). Hier wird festgelegt, dass die GGS-Anwendung ersetzt wird (dafür wird ein neues Projekt gestartet) und der BANF-Prozess für Anforderer, Freigeber und Einkäufer komplett auf dem Prozessportal und dem BPMS durchgeführt werden soll. Einige Datenbestände liegen im LDAP und im ERP-System, die auch weitere Prozesse neben der BANF unterstützen. Zusätzlich soll ein existierendes DMS-System zur zentralen Dokumentenablage verwendet werden. Abbildung 15: SOA Quick Check SOLL Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 25
Siehe auch IBPM-Framework, Säule F. SOA-Komponentisierung. G. Frontends und UI-Design (SO-A) Im Themenbereich Frontends und UI-Design besteht in der Analysephase die Option, Use Cases zu erarbeiten, um eine zusätzliche Übersicht über die Erwartungen und Anforderungen der Anwender zu erhalten. Der Lösungsarchitekt für das BANF-Projekt beschreitet diesen Weg, und erarbeitet mit den Anwendern die erwarteten Use Cases. Abbildung 16: Use Cases Einige Aspekte des Use Case-Modells müssen im Design wieder aufgegriffen und gelöst werden. So soll bspw. eine BAnf als Entwurf erstellt, verworfen und wieder aufgerufen werden können. Der Anforderer kann in diesem Modell neue Lieferanten erfassen, die aber entsprechend der fachlichen Anwendungsübersicht im ERP-System angelegt werden müssen hier müssen Prozess und Systeme so gestaltet werden, dass eine funktionierende Lösung herauskommt. Siehe auch IBPM-Framework, Säule G. Frontends und UI-Design. H. Prozesskomponenten (SO-A) In der Säule für Prozesskomponenten legt der Lösungsarchitekt eine erste Version der relevanten Prozessstatus an. Dazu muss er den Standard-Prozessablauf (siehe Säule A. Prozessmodell, PO-A) und die relevanten Business-Objekte (siehe Säule I. Business-Objekte und Backend- Komponenten, SO-A) verstehen. Im vorliegenden Fall liegt der Prozessstatus im Business- Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 26
Objekt Bestellanforderung (BANF). Zur Darstellung genügt eine Tabelle, die die fachlich relevanten Zustände im Standard-Prozessablauf festhält. Typ Standardablauf Prozesstatus BANF Beantragt In fachlicher Prüfung In kaufmänn. Prüfung Bestellt Tabelle 3: Prozessstatus (Analysemodell) Wichtig ist an dieser Stelle auch zu überprüfen, ob die geforderten Analyse- und Reportingfähigkeiten damit abgedeckt werden können (siehe Säule E Prozessanalyse und Reporting, PO-A). Diese Liste wird im Projektverlauf weiter verfeinert werden. Siehe auch IBPM-Framework, Säule H. Prozesskomponenten. I. Business-Objekte und Backend-Komponenten (SO-A) Als nächstes untersucht der Lösungsarchitekt, welche Business-Objekte im Projekt eine Rolle spielen. Diese Information findet er heraus durch eine Analyse der verwendeten Formulare (Papier, Excel) einen Blick auf die Masken bestehender Systeme Gespräche mit Fachbereich und Anwendungsverantwortlichen Für das BANF-Projekt werden folgende sechs Business-Objekte identifiziert: Abbildung 17: Identifizierte Business-Objekte Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 27
Der SOA Quick-Check (siehe Säule F SOA-Komponentisierung, SO-A) gibt an, in welchen Systemen die identifizierten Business-Objekte leben. Im weiteren Projektverlauf werden diese Business-Objekte in ein Datenmodell einfließen. Siehe auch IBPM-Framework, Säule I. Business-Objekte und Backend-Komponenten. J. Technische Architektur und Infrastruktur (SO-A) Im Themenbereich Technische Architektur und Infrastruktur erweitert der Lösungsarchitekt die Vorgaben aus dem Projektantrag um neu gewonnene Erkenntnisse. Dies führt zur folgenden Darstellung: Abbildung 18: Technische Architektur (Analyse) Die Benutzerinformationen für Prozessportal und BPMS sollen einheitlich aus dem LDAP kommen. Darüber hinaus muss die Verwendung der im Aufbau befindlichen Controlling-DB geklärt werden. Zur Integration zwischen BPMS und Backendsystemen soll ein Enterprise Service Bus (ESB) verwendet werden, der ebenfalls bereits im Hause im Einsatz ist. Schließlich ist auch ein Dokumentenmanagementsystem (DMS) aufzubauen und anzubinden. Siehe auch IBPM-Framework, Säule J. Technische Architektur und Infrastruktur. Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 28
6 Arbeitspaket PO-D I Verantwortlich für die Erstellung der Ergebnisse dieses Arbeitspakets ist wiederum der Prozessanalyst, der auch für diesen Aufgabenblock weiterhin auf die tatkräftige Mitarbeit des Fachbereiches angewiesen bleibt und die Ergebnisse mit dem Lösungsarchitekten abstimmen muss. Siehe auch IBPM-Vorgehen, PO-D I Prozessorientiertes fachliches Design. A. Prozessmodell (PO-D I) Der Prozessanalyst verfeinert das Prozessmodell aus der Analysephase in zwei bis drei Workshops mit dem Fachbereich. Auf dieser Ebene verwendet er ein erweitertes Set von BPMN. Im Prozessmodell finden sich viele Aspekte wieder, die in den nachfolgenden Säulen des Arbeitspaketes bearbeitet werden, insbesondere die Prozessrollen (siehe B. Prozessorganisation und Prozessrollen) Entscheidungen zur Modellierung von Prozessen und Aufgaben, bspw. Push- vs. Pull- Design, Nutzung von Task-Listen (siehe C. User Task Management) die Bedarfe an Geschäftsregeln (siehe D. Geschäftsregeln) Die folgenden beiden Abbildungen zeigt das Ergebnis für den BANF-Prozess: Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 29
Abbildung 19: Prozessmodell fachliches Design (Teil 1) Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 30
Abbildung 20: Prozessmodell fachliches Design (Teil 2) Im Vergleich zum Analysemodell ist der Ablauf nun mit einem höheren Detailgrad beschrieben und die Prozessrollen sind weiter ausdifferenziert. Siehe auch IBPM-Framework, Säule A. Prozessmodell. B. Prozessorganisation und Prozessrollen (PO-D I) Hier geht es darum, die Prozessrollen und die Verantwortlichkeiten genauer festzulegen. Hierfür eignet sich eine tabellarische Beschreibung der einzelnen Prozessrollen, wie sie die folgende Abbildung exemplarisch zeigt. Im vorliegenden Projekt muss bspw. geklärt werden, welcher Personenkreis in welchen Ländergesellschaften und Standorten einbezogen werden muss. Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 31
Abbildung 21: Prozessrollen Gemäß Säule B. Prozessorganisation und Prozessrollen trennen wir zwischen Aufbauorganisation und Prozessrollen und innerhalb der Prozessrollen wiederum zwischen expliziter und impliziter Zuordnung. Abb. 22 zeigt die Festlegungen des BANF-Projektes exemplarisch für die Landesgesellschaft Deutschland. Ein Teil der Rollenzuordnungen wird explizit festgelegt. So sollen die Aufgaben der Fachexperten Legal von allen drei Mitarbeitern des Referats in der Zentrale wahrgenommen werden. Für die Bearbeitung der IT-relevanten Aspekte werden zwei Mitarbeiter aus dem IT-Bereich bestimmt. Die Einkäuferrolle übernimmt das dezentrale Beschaffungsteam. In den anderen Landesgesellschaften müssen ähnliche Zuordnungen vorgenommen werden. Die anderen beiden Rollen werden jeweils implizit über eine Regel festgelegt. Anforderer können alle regulären Mitarbeiter der Good Goods Landesgesellschaften sein. Und die Rolle des kaufmännischen Freigebers hängt ab von der Verantwortung für eine Kostenstelle. Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 32
Abbildung 22: Organigramm und Prozessrollen, Landesgesellschaft Deutschland Siehe auch IBPM-Framework, Säule B. Prozessorganisation & -rollen. Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 33
C. User Task Management (PO-D I) Im User Task Management trifft der Prozessanalyst zusammen mit den Prozessstakeholdern aus dem Fachbereich grundlegende Designentscheidungen zu Prozessen und Aufgaben. Relativ schnell wird klar, dass das Thema Kanban im vorliegenden Kontext keine Rolle spielt. Andere Themen werden aber sehr wohl heiß diskutiert. Dazu gehört etwa die Frage, ob die Bearbeitung von Bestellanforderungen durch den Einkauf ohne Tasks erfolgen soll. Das Prozessmodell geht davon aus, dass die BANF über verschiedene Tasks vom fachlichen Freigeber zum kaufmännischen Freigeber und schließlich zum Einkauf weitergeleitet wird. Insbesondere für die Freigeber scheint die Zuteilung der Aufgaben über Task-Listen sehr sinnvoll: Die Freigeber beschäftigen sich wahrscheinlich nur einen sehr kleinen Teil ihrer Arbeitszeit mit Freigaben, daher ist es sinnvoll, ihnen diesbezüglich jeweils explizit eine Aufgabe zuzuteilen, wenn eine Freigabe ansteht. Aus Sicht des Einkaufs sieht dies anders aus: Die Einkäufer beschäftigen sich den größten Teil ihrer Arbeitszeit mit der Bearbeitung von Beschaffungsanträgen. Für die Einkäufer erscheint es natürlicher, wenn sie eine zentrale Liste mit Beschaffungsanträgen zur Verfügung gestellt bekommen, die sie nach verschiedenen Kriterien filtern und sortieren können. Der Standardfilter soll immer die gerade aktuell zu bearbeitenden Beschaffungsanträge in der Liste oben anzeigen. Die Einkäufer bekommen also keine Tasks wie»beschaffungsantrag prüfen«,»beschaffung in Bestellung überführen«etc. in ihrer Task-Liste, sondern sollen sich stattdessen die relevanten Beschaffungsaufträge eigenständig heraussuchen und diese selbstständig bearbeiten. Daraus ergeben sich auch Vorgaben für das UI-Design (siehe G. Frontends und UI-Design). Siehe auch IBPM-Framework, Säule C. User Task Management. D. Geschäftsregeln (PO-D I) Im fachlichen Prozessmodell wurde an zwei Stellen ein Bedarf für Geschäftsregeln identifiziert. Dabei handelt es sich um die Steuerung der fachlichen und der kaufmännischen Freigabe. Die folgende Abb. 23 zeigt diese auf, Der Bedarf für fachliche Bearbeitung und Freigabe hängt ab von der Artikelart. Die kaufmännische Freigabe hängt ab von Artikelart, Bestellvolumen, Budgetplanung und der Position des Anforderers in der Kostenstellenhierarchie. Beides wird in tabellarischer Form spezifiziert. Darüber hinaus muss an dieser Stelle darüber nachgedacht werden, wer die Geschäftsregeln administriert und wie der Freigabeprozess aussieht. Die fachliche Verantwortung für beide Regeltabellen liegt im Finanzbereich beim CFO. Einer seiner Mitarbeiter ist zuständig für den Pflegeprozess. Die Werkzeugfrage wird der Prozessanalyst im Umsetzungsdesign bestimmen, da er hierfür zusammen mit dem Lösungsarchitekt bestimmen muss, wie die Geschäftsregeln technisch umgesetzt werden sollen. Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 34
Abbildung 23: Identifizierte Geschäftsregeln Siehe auch IBPM-Framework, Säule D. Geschäftsregeln. E. Prozessanalyse und Reporting (PO-D I) In der Säule Prozessanalyse und Reporting konkretisiert der Prozessanalyst zusammen mit Prozesseigner, Prozesscontroller und Prozessmanager die Anforderungen aus der Analysephase. Zunächst fragt der Prozessanalyst ab, welche Kennzahlen und Auswertungen für das Prozesscontrolling gebraucht werden. Es bleibt bei den drei Kennzahlen Durchlaufzeit, Anzahl bearbeiteter Vorgänge und Gesamtvolumen genehmigter Bestellanforderungen je Produktkategorie. Für alle Kennzahlen erwarten die Prozessverantwortlichen eine graphische Darstellung mit historisierten Daten. Die folgende Abbildung zeigt eine einfache Skizze, die der Prozessanalyst zusammen mit den Fachbereichsvertretern zur Veranschaulichung in Excel erstellt: Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 35
Abbildung 24: Kennzahlen und graphische Darstellung Ergänzend erstellt der Prozessanalyst ein einfaches analytisches Datenschema, in dem die Kennzahlen und die benötigten Auswertungsdimensionen festgehalten werden. Abbildung 25: Datenschema für Analyse und Reporting Für die Berechnung der Durchlaufzeit müssen weitere Details festgelegt werden, etwa Einschränkung auf landesspezifische Arbeitstage (keine Feiertage) und die Bestimmung von Beginn, Unterbrechung, Wiederaufnahme und Ende im Prozessablauf. Zur Visualisierung greift der Prozess Analyst auf die Process Monitoring-Patterns zurück. Die folgende Abbildung zeigt ein Beispiel. Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 36
Abbildung 26: Kennzahl Durchlaufzeit im Prozessmodell Mit dieser Grundlage können zwei Lösungen beschrieben werden: Analyse: Mit einem Auswertungswerkzeug sollen die Kennzahlen aus Abbildung 25 historisiert ausgewertet und im Stil von Abbildung 24 dargestellt werden können; ein Export nach Excel soll ebenfalls möglich sein; das vorgesehene BPMS verfügt über eine analytische Komponente mit einem Standardauswertungswerkzeug, das dies erlaubt. Reporting: Die Kennzahlen sollen in einen monatlichen Bericht des Prozesscontrollers an den Leiter Beschaffung einfließen. Da das Reporting in Excel erfolgt, sollen die Daten ebenfalls in Excel bereitgestellt werden; der Prozessanalyst fertigt hierfür ebenfalls eine Skizze in Excel an. Danach bespricht sich der Prozessanalyst mit dem Prozessmanager, welche Informationen im Prozessleitstand enthalten sein müssen. Die gemeinsam erarbeitete Lösung sieht eine tabellarische Darstellung vor, in der für die einzelnen Bearbeitungsschritte aggregierte Daten zu Workload, fertig gestellte Aufgaben und Bearbeitungsdauer bereitgestellt werden. Der Beobachtungszeitraum für den Leitstand ist der aktuelle Monat (Monatsbeginn bis zum aktuellen Tagesdatum). Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 37
Abbildung 27:Skizze Prozessleitstand Für die einzelnen Stationen im Prozessablauf werden vom Prozessmanager und den jeweiligen Teamleitern Richtwerte für die Bearbeitungsdauer vorgegeben: Fachliche Freigabe 3 Tage, Kaufmännische Freigabe 3 Tage, Bearbeitung Einkauf 4 Tage. Der Prozessleitstand filtert die laufenden Vorgänge entsprechend, so dass sichtbar wird, welche Anträge im Erwartungszeitraum liegen und welche länger benötigen. Darüber hinaus soll der Prozessleitstand weitere Analysemöglichkeiten bieten: einen Drill-Down hinunter auf Vorgangsebene Änderungen des Beobachtungszeitraums auf vergangene Monate Link zum Analysewerkzeug für erweiterte Such- und Filtermöglichkeiten Siehe auch IBPM-Framework, Säule E. Prozessmonitoring, -analyse und Reporting. Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 38
7 Arbeitspaket SO-D I Im vierten Arbeitspaket Serviceorientiertes Design I (SO-D I) legt der Lösungsarchitekt die Komponenten- und Servicearchitektur fest. Außerdem entwirft ein UI- Designer die benötigten Benutzeroberflächen. Alle Themen müssen eng mit den Arbeiten des Prozessanalysten abgestimmt werden. Siehe auch IBPM-Vorgehen, SO-D I Serviceorientiertes fachliches Design. F. SOA-Komponentisierung (SO-D I) Der Entwurf der Komponenten- und Servicearchitektur erfolgt mit Hilfe einer SOA Map, die den SOA Quick-Check aus der Analyse weiter konkretisiert. Voraussetzungen für die Erstellung der SOA Map sind das fachliche Prozessmodell (siehe A. Prozessmodell, PO-D I) der Bedarf an Geschäftsregeln (siehe D. Geschäftsregeln, PO-D I) die Zuordnung der Business-Objekte zu Backend-Komponenten (siehe I. Business- Objekte und Backenend-Komponenten, SO-D I) die Festlegung, welche Soll-Anwendungen eingesetzt werden (siehe J. Technische Architektur und Infrastruktur, SO-D I) Die Frontends und Komponenten, die in der SOA-Map beschrieben werden, müssen in der Lage sein, den fachlich vorgegebenen Prozessablauf adäquat, d.h. inklusive aller funktionalen und nichtfunktionalen Anforderungen, zu unterstützen. Darüber hinaus sollten die Komponenten den Vorgaben einer Zielarchitektur entsprechen, sofern diese für den zu bebauenden Ausschnitt der Anwendungslandschaft existiert. Da die Good Goods AG erst am Beginn ihrer BPM- und SOA- Strategie steht, steckt die Zielarchitektur für die meisten Domänen noch in ihren Anfängen. In Abstimmung mit dem SOA-Koordinator hält der Lösungsarchitekt folgende Vorgaben fest: Die Domäne Einkauf ist noch nicht beplant; das BANF-Projekt liefert hierfür erste Ergebnisse Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 39
Das ERP-System bleibt unverändert bestehen und ist via Service-Kapselung einzubinden Die Domäne Informationsmanagement ist bereits beplant, erste Komponenten und Services sind implementiert; hier muss die Komponente Dokumentenmanagement mit ihren Serviceoperationen wiederverwendet werden Ausgerüstet mit diesen Vorgaben entwickelt der Lösungsarchitekt für das BANF-Projekt die folgende SOA-Map: Abbildung 28:SOA Map BANF (Fachliches Design) In der SOA-Map sind folgende Design-Entscheidungen enthalten: Frontends: Alle Prozessbeteiligten arbeiten mit einem neuen Beschaffungsportal als Frontend. Die Portalseiten werden durch das BPMS bereitgestellt und in das Intranet- Portal der Good Goods AG integriert. Die Lieferantenpflege durch den Einkauf erfolgt weiterhin im bestehenden ERP Frontend. Prozesskomponenten: Für den BANF-Prozess wird eine neue Prozesskomponente BANF-Prozess erstellt, die die Prozesslogik für die Frontends bereitstellt. Die Imple- Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 40
mentierung erfolgt auf dem BPMS. In einer späteren Ausbauphase wird diese Prozesskomponente den Folgeprozess Bestellung anstoßen. Geschäftsregeln: Die Geschäftsregeln werden mit Hilfe einer neuen logischen Komponente Freigabeermittlung abgebildet. Diese greift auf zwei Basiskomponenten zurück, die die Freigabe- und Unterschriftenregelung kapseln. Letztere werden in der Controlling- DB abgelegt. Die Implementierung der Geschäftsregeln erfolgt mit den Bordmitteln des BPMS. Der Einsatz einer externen Rule Engine ist nicht vorgesehen. Weitere Backend-Komponenten: Für den BANF-Prozessablauf werden noch weitere Basiskomponenten benötigt, die Services bereitstellen. Deren Implementierung erfolgt auf unterschiedlichen Anwendungen: Eine neue Komponente BANF im BPMS, eine neue Komponente ERP Master Data, die einige Services des ERP-Systems kapselt, und die existierende Komponente Dokumentenmanagement auf dem zentralen DMS, die um einen neuen Service für den BANF-Prozess erweitert werden soll. Und schließlich muss für die Aufgabe der Bestellungen noch ein weiterer Service in einer gleichnamigen Komponente des ERP-Systems bereitgestellt werden. Die folgende Tabelle zeigt den Bebauungsbedarf für die einzelnen Komponenten auf: Komponente Typ Domäne Beschreibung Beschaffungsportal Frontend Einkauf Neu zu erstellen ERP Frontend Lieferantenpflege BANF-Prozess Prozess Einkauf Neu zu erstellen Frontend Lieferant vorhanden; kein Änderungsbedarf Freigabeermittluntion Orchestra- Einkauf Neu zu erstellen Unterschriftenregelung Beschaffung Basis Einkauf Neuer Service (=Schnittstelle); Datenablage in Controlling-DB Freigaberegeln Basis Einkauf Neu zu erstellen;: Datenablage in BPMS BANF (BPMS) Basis Einkauf Neu zu erstellen; Datenablage in BPMS Master Data ERP Basis Lieferant Finanzen Basis Dokumentenmanagement Beschaffung Informationsman agement Neue Services (=Schnittstellen); Datenablage in ERP-System Neuer Service (=Schnittstelle); Datenablage in DMS Bestellung Basis Einkauf Neuer Service (=Schnittstelle); Datenablage in ERP-System Tabelle 4: Übersicht Komponenten Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 41
Siehe auch IBPM-Framework, Säule F. SOA-Komponentisierung. G. Frontends und UI-Design (SO-D I) In dieser Säule geht es darum, die in der SOA-Map (siehe F. SOA-Komponentisierung, SO-D I) definierten Frontends graphisch zu entwerfen. In vielen Fällen hergeben sich hier auch Fragen, die im Rahmen des User Task Managements entschieden werden müssen (siehe C. User Task Management, PO-D I). Der UI-Designer setzt sich dazu mit den Vertretern aus dem Fachbereich (Prozessmanager, Prozessmitarbeiter) und dem Projektteam (Prozessanalyst, Lösungsarchitekt) zusammen. Zunächst klärt der UI-Designer, welche Prozessrollen als Prozessbeteiligte und welche als Prozessmitarbeiter einzustufen sind. Erstere müssen stärker durch den Prozess gesteuert werden. Im vorliegen Projekt sind dies die Prozessrollen Anforderer, fachlicher Freigaber und kaufmänn. Freigeber. Diese Gruppen sollen mit Task-Listen arbeiten. Der UI-Designer greift an dieser Stelle auf die BPM-Patterns für Process Portlets zurück. Für alle drei Prozessrollen wird ein Maskendesign Process/BO benötigt. Die kaufmännischen Freigeber sollen überdies mit einer Kompaktvariante arbeiten und bei Bedarf zur detaillierten Darstellung wechseln können. Für die Einkäufer als erfahrene Prozessmitarbeiter soll ein Prozesscockpit mit einem fachlichen Prozessmonitor bereitgestellt werden, das ihnen mehr Freiheiten bei der Bearbeitung gibt. Die folgende Abbildung zeigt die Ergebnisse dieser Überlegungen: Abbildung 29: Process/BO-Masken und Prozessmonitor im Prozessablauf Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 42
Der Entwurf der Maske erfolgt in drei Schritten: Handzeichnung in einem Workshop, Überarbeitung mit Visio, danach Validierung in einem zweiten Workshop. Die folgenden Abbildungen zeigen Ausschnitte der Ergebnisse. Abbildung 30: Process/BO-Maske Bestellanforderung Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 43
Abbildung 31: Process/BO-Maske Bestellanforderung kompakt Für die Bearbeiter im Einkauf wird als Teil des Prozesscockpits unter anderem ein fachlicher Prozessmonitor definiert, über man zu den einzelnen Bestellanforderungen navigieren kann: Abbildung 32: Entwurf für Prozesscockpit Siehe auch IBPM-Framework, Säule G. Frontends und UI-Design. H. Prozesskomponenten (SO-D I) In der Säule Prozesskomponente überarbeitet der Lösungsarchitekt die Prozessstatustabelle entsprechend der detaillierteren Erkenntnisse aus dem fachlichen Prozessmodell (siehe A. Prozessmodell, PO-D I). Das Ergebnis zeigt die folgende Tabelle: Typ Prozesstatus BANF Bestellposition Standardablauf In Bearbeitung Nicht in Bestellung überführt Beantragt In Bestellung überführt Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 44
Typ Prozesstatus BANF Bestellposition In fachlicher Prüfung In kaufmänn. Prüfung (1-3) In Bearbeitung durch Einkauf Tlw. bestellt Abgeschlossen Sonderfälle Verworfen Verworfen In Überarbeitung Abbildung 33: Prozessstatus (Fachliches Design) Wichtig ist an dieser Stelle auch zu überprüfen, ob die geforderten Analyse- und Reportingfähigkeiten (siehe E. Prozessanalyse und reporting, PO-D I) damit abgedeckt werden können. Siehe auch IBPM-Framework, Säule H. Prozesskomponenten. I. Business-Objekte und Backend-Komponenten (SO-D I) Ausgehend vom fachlichen Prozessmodell (siehe A. Prozessmodell, PO-D I) und den in der Analysephase identifizierten Business-Objekten (siehe I. Business-Objekte und Backend- Komponenten, SO-A) erstellt der Lösungsarchitekt ein Datenmodell für die BANF-Lösung. Dazu klinkt er sich wiederum die Workshops mit dem Fachbereich ein und zieht ggf. weitere IT- Experten für die betroffenen Anwendungssysteme zu Rate. Das Ergebnis zeigt die folgende Abbildung: Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 45
Abbildung 34: Datenmodell für die BANF-Lösung (Bestellung hier nur konzeptionell, nicht im Scope) Die Datenhoheit für Business-Objekte liegt bei logischen Komponenten, die den Zugriff durch ihre Serviceoperationen ermöglichen. Die Implementierung erfolgt durch Anwendungen, die dann als Servicegeber auftreten. Im nächsten Schritt bestimmt daher der Lösungsarchitekt, in welchen logischen Komponenten und Anwendungen die Business-Objekte geführt werden. Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 46
Abbildung 35: Zuordnung von Business-Objekten zu logischen Komponenten Für die Business-Objekte Bestellanforderung und Bestellposition ist die logische Komponente BANF zuständig, die bislang nicht existiert. Die Dokumentenablage erfolgt im Dokumentenmanagementsystem (DMS), für das in der Unternehmensarchitektur bereits eine gleichnamige Komponente vorhanden ist. Aufgrund der vorgegebenen Lösungsarchitektur werden einige weitere verwendete Business-Objekte im ERP-System residieren. Dazu werden die zwei logischen Komponenten Bestellung und ERP Master Data gebildet. ERP Master Data kapselt den Zugriff auf die Business-Objekte Kostenstelle, Artikeltyp, Mengeneinheit und Lieferant. Die Überlegungen aus dieser Säule sind in die SOA Map der Säule F. SOA-Komponentisierung eingeflossen. Siehe auch IBPM-Framework, Säule I. Business-Objekte und Backend-Komponenten. J. Technische Architektur und Infrastruktur (SO-D I) An dieser Stelle klärt der Lösungsarchitekt noch einige Detailfragen, die sich aus dem fachlichen Design ergeben. Die detaillierte Spezifikation erfolgt um Umsetzungsdesign. Siehe auch IBPM-Framework, Säule J. Technische Architektur und Infrastruktur. Enterprise BPM Dirk Slama und Ralph Nelius www.enterprise-bpm.org 47