Prozessorientiertes Requirements Management Und der Roundtrip kann bleiben, wo der Pfeffer wächst

Transkript

1 Und der Roundtrip kann bleiben, wo der Pfeffer wächst Sebastian Graf, PROMATIS software GmbH DOAG 2010, Nürnberg, 18. November

2 Agenda Über den Referenten Warum IT-Projekte scheitern Warum der Roundtrip kein Mittel gegen das Scheitern ist Prozessorientiertes Requirements Management als Lösung Q & A Tool-Auswahl Der prozessorientierte Ansatz Knowledge Bases / Referenzmodelle Simulation von Geschäftsprozessen Kennzahlenbasiertes Monitoring PROMATIS software GmbH

3 Über den Referenten : Studium Informatik an der Universität Karlsruhe (TH) (heute KIT) : Wissenschaftlicher Mitarbeiter Fraunhofer Institut (IITB), Karlsruhe 1995 heute: PROMATIS software GmbH, Ettlingen, Deutschland Division Manager Custom Solutions Seit 2009 Leiter der Special Interest Group BPM (Business Process Management) der DOAG PROMATIS software GmbH

4 Warum IT-Projekte scheitern IT-Projekte, die scheitern, gibt s doch gar nicht...! 100% 90% 80% 70% 60% Projekterfolg laut CHAOS Report, Standish Group 50% 40% 30% 20% gescheitert kritisch erfolgreich 10% 0% Quelle: PROMATIS software GmbH

5 Warum IT-Projekte scheitern Gründe für das Scheitern von IT-Projekten laut CHAOS Report 4,3% 9,9% 13,1% Unvollständige Anforderungsdefinition Business User wurden nicht miteinbezogen 7,5% 6,2% 12,4% Zu wenig Ressourcen Unrealistische Annahmen Kein Management Support 8,1% 10,6% Sich ändernde Anforderungen Schlechte / Keine Planung 8,7% 9,3% 9,9% Keine Verwendung für Projekt Kein IT Management Mangelndes technisches Know-How Andere Quelle: PROMATIS software GmbH

6 Warum der Roundtrip kein Mittel gegen das Scheitern ist Sind wir auf dem richtigen Weg?...Agile Softwareentwicklung ist der Oberbegriff für den Einsatz von Agilität in der Softwareentwicklung. Das bedeutet, dass schnell, flexibel und ohne große Reglementierung programmiert werden kann, quasi als Gegenbewegung zu den detailliert geregelten Softwaremodellen wie dem V-Modell oder dem Rational Unified Process. Das Leitbild sagt, dass man weniger planen soll, da man dadurch das bekommt, das man geplant hat und nicht unbedingt das was man benötigt. Außerdem ist es das Ziel, die Aufwandkurve möglichst flach zu halten, denn viele Kunden wissen zu Beginn des Projekts nicht genau, was sie wirklich benötigen. So kann man unmöglich vorher genau planen und spezifizieren, was der Kunde möchte......extreme Programming (XP) ist die bekannteste Methode der agilen Prozesse und zeichnet sich dadurch aus, dass zu Beginn der Entwicklung auf einen detailliert spezifizierten Anforderungskatalog verzichtet wird, sondern in kurzen Abständen ein Prototyp erstellt wird und dann wieder erneut die Anforderungen analysiert werden. Es werden alle Phasen der Softwareentwicklung ständig kurz durchlaufen und somit können die Anforderungen des Kunden noch bis zum Ende aufgenommen werden. Frei nach dem Motto "Der Appetit kommt beim Essen" merkt der Kunde erst mit der Anwendung des Prototypen, welche Features er wirklich braucht... Quelle: PROMATIS software GmbH

7 Der 30-jährige Krieg gegen die Spezifikation Störtechnologien Rapid Prototyping Visual Programming SOA Web 2.0 Schlachten SA/SD- Epoche OOA/OOD- Epoche Agile Epoche PROMATIS software GmbH

8 Typischer Schlacht-Verlauf Zweifel: Eine Requirements- Spezifikation ist schon eine aufwendige Sache. Und der Projektnutzen ist fraglich. Spezifikationsunwillige Analytiker und Entwickler Erfahrungen aus Vorgängerprojekten Einsicht: Die erfolgskritischen und teuersten Fehler passieren in der Requirements-Phase. Niederlage: Wir nutzen für die Requirements dieses Mal noch MS Office. Und dann verwenden wir noch ein paar alte Module und programmieren die neuen Sachen schnell runter. Irrtum: Früher hätte man Spezifikationen gebraucht. Heute haben wir aber viel bessere Entwicklungswerkzeuge, die für kurze Projektlaufzeiten und beste Qualität sorgen. Technik- Freaks Das haben wir schon immer so gemacht -Analytiker PROMATIS software GmbH

9 Kernkompetenzen: Analyse und Planung Geplante Entwicklungszyklen Requirements- Analyse Requirements- Spezifikation: korrekt, im Kern vollständig, konsistent Produktivsystem: Usability und Qualität Require- ments- Sammlung Requirements- Listen: unvollständig, inkonsistent, fragliche Qualität Produktivsystem: Fragliche Usability und Qualität Langwierige Trial & Errorartige Entwicklungszyklen Nicht enden wollende Korrekturzyklen PROMATIS software GmbH

10 Warum der Roundtrip kein Mittel gegen das Scheitern ist Analyse BPA / BPM-Suite EPK BPMN Design & Implementierung SOA-Suite BPEL Pilotierung & Rollout Wartung PROMATIS software GmbH

11 Warum der Roundtrip kein Mittel gegen das Scheitern ist PROMATIS software GmbH

12 Warum der Roundtrip kein Mittel gegen das Scheitern ist In der Analysephase kommt es zu Fehlern und Versäumnissen. Die Fehler werden über die Generierung von Design Blueprints in die Design- & Implementierungsphase übernommen. Der Entwickler erkennt fachliche Fehler in der Entwicklungsphase. Er korrigiert diese zusammen mit dem Fachanwender unter Verwendung der Entwicklungsmodelle (BPEL). Die Korrekturen werden verlustfrei via Roundtrip auf die Analytische Ebene zurückgeneriert. Ein guter Ansatz. Er funktioniert nur leider nicht! Die Qualität der Analysephase muss verbessert werden, um gar nicht erst auf einen Roundtrip angewiesen zu sein -> Konsequentes Prozessorientiertes Requirements Management PROMATIS software GmbH

13 Prozessorientiertes RM Toolauswahl Welche Artefakte eines Geschäftsprozesses können abgebildet werden (Regeln, Rollen, Ressourcen, Kennzahlen, Ziele, Risiken, Leistungen,...)? Wie detailliert können die Artefakte abgebildet werden? Welche Modelltypen gibt es, und wie sind diese miteinander vernetzt? Wie einfach zu bedienen ist das Werkzeug? Welche Schnittstellen gibt es? Ist konsistentes, hierarchisches Modellieren möglich? Ist Simulation möglich? Welche Art der Prozesspublikation ist möglich? PROMATIS software GmbH

14 Prozessorientiertes RM Der prozessorientierte Ansatz Der Geschäftsprozess muss im Mittelpunkt der Anforderungsanalyse stehen (funktionale Ansätze sind zu unterlassen). Scope-Definition Tool-Kenntnisse und Vorgehensmodell-Kenntnisse Welche Prozessobjekte müssen dokumentiert bzw. einer Analyse unterzogen werden? Welche Artefakte werden von nachgelagerten Projektstufen gefordert? Management Commitment muss vorhanden sein! Business User haben die führende Rolle in der Anforderungsanalyse, nicht die IT! PROMATIS software GmbH

15 Prozessorientiertes RM Knowledge Bases Beim umfangreichen Projekten ist mit einem erhöhten Aufwand in der Analysephase zu rechnen. -> Guter Content ist wichtiger als ein BPM-Werkzeug. Viele Hersteller bieten Knowledge-Bases aka Referenzmodelle oder Branchenmodelle an. Einsatzgebiete: Implementierung von Standardsoftware-Paketen. Vorteil: Aufsetzen auf existierenden Modellen. Nutzung der Erfahrungen aus bereits abgeschlossenen Projekten. Schnelles Verständnis der vorhandenen Prozesse. Optimale Unterstützung des prozessorientierten Ansatzes. Optimale Einbindung des Managements und der Fachanwender PROMATIS software GmbH

16 Prozessorientiertes RM Simulation PROMATIS software GmbH

17 Prozessorientiertes RM Simulation IT-Community setzt modellbasierte Ansätze & Simulation ein PROMATIS software GmbH

18 Prozessorientiertes RM Simulation Erkennung von logischen Inkonsistenzen (Hierarchisches Modellieren) Erkennung von fehlenden Prozesszweigen ( Tote Modelle) Erkennung von SLA-Verletzungen (Kritische Pfade, fehlende Ressourcen, Durchlaufzeiten, Verletzung von KPIs) Worauf ist zu achten: Detaillierte Beschreibung der Aktivitäten (Kosten, Zeiten, Ausführungsmodelle etc.) Detailliertes Rollen- und Ressourcenmodell (Kosten, Verfügbarkeiten, Schichtmodelle...) Realistisches Modell für Lastgenerierung Detailliertes Objektmodell Aussagekräftige Reports (Schwachpunkte, Kritische Pfade, problematische Ressourcen, Fehleranalyse...) Simulation umfangreicher Prozesse ( Hello-World - Syndrom) PROMATIS software GmbH

19 Prozessorientiertes RM Simulation Beispiel: Simulation der Wirkstoffproduktion in der Pharmazeutischen Industrie PROMATIS software GmbH

20 Prozessorientiertes RM Simulation Vorgehensweise 1. Modellierung aller relevanten Laborprozesse (Ist-Analyse). 2. Bewertung der Modelle mittels Simulation. 3. Adaption der Prozesse. 4. Reorganisation der Prozessmodelle (Soll-Analyse). 5. Simulation der Varianten mit unterschiedlichen Ressourcenmodellen. Ergebnisse: + 15% technische Ressourcen + 50% personelle Ressourcen PROMATIS software GmbH

21 Prozessorientiertes RM Simulation Beispiel: Simulation der Wirkstoffproduktion in der Pharmazeutischen Industrie PROMATIS software GmbH

22 Prozessorientiertes RM Monitoring Überwachung von Kennzahlen (KPIs) und Zusammenführung in einem Performance Cockpit. Worauf ist zu achten? Kennzahlen müssen bereits bei den Analysemodellen hinterlegt werden. Kennzahlen müssen in geeigneter Weise aggregierbar sein (Kennzahlenhierarchien). Messwerte der Kennzahlen aus der Produktion können auf die Analyse-Ebene zurückgeführt werden (Closed-Loop-Monitoring). Wiederverwendung aktueller Messwerte in der Simulation. Trennung zwischen technischen und fachlichen Kennzahlen. Implementierung von Exception-Handling-Prozessen PROMATIS software GmbH

23 Prozessorientiertes RM Monitoring Oracle Web-Service Manager PROMATIS software GmbH

24 Prozessorientiertes RM Monitoring Oracle BAM (Business Activity Monitoring) PROMATIS software GmbH

25 Prozessorientiertes RM Closed Loop BPM Modellierung aller relevanten Prozesskomponenten Simulation Implementierung Monitoring PROMATIS software GmbH

26 Q & A Falls Sie noch Fragen haben PROMATIS software GmbH

27 Sebastian Graf Dipl.-Inform. Division Manager Custom Solutions PROMATIS software GmbH Pforzheimer Str Ettlingen Tel Fax Web: sebastian.graf@promatis.de PROMATIS software GmbH