Wenn Prozesse laufen lernen. Requirements Engineering bei der Einführung von Geschäftsprozessmanagement

Transkript

1 Wenn Prozesse laufen lernen Requirements Engineering bei der Einführung von Geschäftsprozessmanagement Norman Fraunhofer Riegel, IESE Sebastian Adam 13. März 2012

2 Warum Geschäftsprozessmanagement auf einer RE-Konferenz?

3 Geschäftsprozessmanagement bezeichnet die Gestaltung der Geschäftsprozesse eines Unternehmens. Zum Geschäftsprozessmanagement gehören die Erhebung, Analyse, Dokumentation, Umsetzung und Ausführung von Prozessen. Wirtschaftslexikon

4 Dokumentation Ausführung Umsetzung

5 Business Strategy Business Operation REBPM Business Design Implementation

6

7

8 Werkzeuge Methoden Rollen Philosophie

9 Initialisierung & Teambildung Einführungsprozess BPM Strategie Definition IT-Analyse Prozessidentifikation/ -priorisierung Rollen- & Methodendefinition Prozessanalyse Pilotprozessanalyse Ist-Analyse Lernen aus Erfahrung Werkzeugauswahl Soll-Definition Anforderungs analyse Vorauswahl Werkzeugeinführung Entscheidung Proof of Concept

10 Ablauf Pilotprozessanalyse Pilotprozessanalyse Pilotprozessanalyse Pilotprozessanalyse Ist-Analyse Erhebung Analyse Spezifikation Validierung Soll-Definition Erhebung Analyse Spezifikation Validierung

11 Ist-Erhebung 2h-Workshop mit Repräsentanten aller Prozessbeteiligten Kartenabfrage und Konsolidierung von Aufgaben Geschäftsdaten Stärken Schwächen Wünschen aus Sicht jedes Prozessbeteiligten

12 Ist-Analyse & -Spezifikation Nacherfassung fehlender und widersprüchlicher Informationen in Einzelinterviews Modellierung und Beschreibung des erhobenen Prozesses auf Workflowebene Konsolidierung und Detaillierung der Stärken und Schwächen Erstellung eines Datenmodells und Glossars

13 Ist-Validierung Versendung der Ist-Spezifikation an die Workshop-Teilnehmer Walkthrough und Diskussion der Spezifikation in einem 2h- Workshop Überarbeitung und erneute Versendung Finales Review und Freigabe durch die Workshop-Teilnehmer

14 Tipps für die Ist-Analyse Organisatorisches Alle Prozessbeteiligten (OEübergreifend) einbeziehen Aufwand für Nacherfassung einplanen und kommunizieren Vertraulichkeit zusagen und einfordern Stärken, Schwächen und Wünsche vorsichtig formulieren Ist-Spezifikation durch Workshop-Teilnehmer freigeben Keine falschen Erwartungen wecken Methodisches Kartenabfrage statt Prozessmodellierung on-the-fly Syntaktische, aber keine inhaltliche Vollständigkeit sicherstellen Nicht alle Ausnahmen und Sonderfälle modellieren Einfache, abgespeckte Prozessnotation verwenden Notationen und Abstraktionsebenen erläutern Explizites Dokument schreiben

15 Initiale Soll-Definition Überführung der Stärken, Schwächen und Wünsche in Anforderungen und Verbesserungsziele Priorisierung der Anforderungen und Ziele mit Prozessverantwortlichen Erarbeitung eines ersten Vorschlags für den Soll-Prozess mit Prozessverantwortlichen

16 Analyse und Verfeinerung Soll-Definition Versendung der Soll-Spezifikation an die Workshop-Teilnehmer aus der Ist-Analyse Walkthrough und Diskussion der Spezifikation in einem 2h- Workshop Nacherfassung fehlender und widersprüchlicher Informationen in Einzelinterviews Überarbeitung mit bedarfsweiser Anpassung des Datenmodells und Glossars

17 Validierung und Freigabe Soll-Definition Finales Review durch die Workshop-Teilnehmer Offizielle Freigabe durch Prozessverantwortliche

18 Tipps für die Soll-Definition Allgemeines Entscheidungsträger frühzeitig einbeziehen Lösungsvorschlag vorbereiten Verfolgbarkeit zu Anforderungen sicherstellen Zielnotation verwenden (falls bereits möglich) Fokussiert agieren, aber Übergreifendes mitnehmen Technologieneutral auf Workflowebene modellieren Für Philosophiewechsel sensibilisieren Paradigmenspezifisches Umgang mit Geschäftsregeln sorgsam entscheiden Ausnahmebehandlungen definieren (explizit / implizit) Historisch gewachsene Sequentialisierung hinterfragen Isoliertes System- und Funktionsdenken auflösen Neue Kommunikationswege etablieren

19 Werkzeugauswahl

20 BPM-Rollenmodell Prozessspezifische Rollen Process Owner (Prozessverantwortung) Process Participant (Prozessdurchführung) Process Initiator (Instanziierer) Process Manager (Prozesssteuerung) Prozessübergreifende Rollen Process Modeller (Prozessmodellierung) BPM Owner (Prozessphilosophie & -Governance) Process Developer (Prozessimplementierung) Process Administrator (Prozess- & Nutzerverwaltung) Process Controller (Prozessmessung und -prüfung) Technical Administrator (Technischer Support & Betrieb)

21 Ablauf Werkzeugauswahl Werkzeugauswahl Anforderungsanalyse Vorauswahl Erhebung Priorisierung Selbstauskunft Bieterpräsentation Anbie ter 2 Anbie ter 1 Anbie ter n Entscheidung Proof of Concept Anbie ter 2 Anbie ter 1 Empfehlung Beschaffung Anbie ter n Show Case Interner Test

22 Tipps für die Werkzeugauswahl Anforderungsanalyse Anforderungen aus Pilotprozessen, IT Analyse und BPM-Methodik ableiten Anforderungen mit Hilfe einer Nutzwertanalysetabelle priorisieren Ganzheitlichkeit oder Interoperabilität als zentrale Anforderung Klare K.O.-Kriterien frühzeitig definieren Vorauswahl & Proof of Concept Strikte Agenda in Bieterpräsentationen einhalten und als Entscheidungskriterium heranziehen Persönlichen Eindruck und Zwischenmenschliches nicht unterschätzen Wirtschaftliche Situation der Anbieter berücksichtigen Kritische Szenarien definieren und durchspielen

23 Team Externer Support Commitment Strategie Beteiligung Kommunikation

24 Take Away Message Geschäftsprozessmanagement (BPM) ist erfolgsversprechendes Konzept um (endlich) Business und IT besser zu verzahnen Requirements Engineering für Informationssysteme muss sich in diesem Konzept integrieren und kann nicht losgelöst davon betrachtet werden Insbesondere bei Einführung von BPM spielt sorgfältiges RE eine zentrale Rolle, um den langfristigen Erfolg von BPM gewährleisten zu können Kooperation mit externen (hersteller-neutralen) BPM-Experten ist wichtig, aber BPM-Einführung muss intern getrieben werden

25 IESE oder Quo Vadis, RE? Authorities Standard-compliant processes & specifications Enterprises Improved business & IT alignment Users Highly attractive software products Engineers Effective and efficient development support

26 Fragen? Norman Riegel Sebastian Adam Fraunhofer IESE Fraunhofer-Platz Kaiserslautern Tel: März 2012