Agiles Prozessmanagement bei der SBB

Transkript

1 Agiles Prozessmanagement bei der SBB Daniel Studer SBB Gesamtprojektleiter, Walter Strametz TI&M Principal/CTO,

2 SBB Informatik Solution Center Infrastruktur 2

3 Agiles Prozessmanagement bei der SBB Daniel Studer SBB Gesamtprojektleiter, Walter Strametz TI&M Principal/CTO,

4 Agenda. Störungsmanagement bei der Infrastruktur. (Warum tun wir das?) Agilität in der Entwicklung. (Wie tun wir es?) Agilität in den implementierten Prozessen. (Mit was tun wir es?)

5 Täglich beinahe eine Million Fahrgäste.

6 Die SBB hat das am dichtesten befahrene Bahnnetz. Netznutzungseffizienz: Züge pro Hauptgleis und Tag SBB JR ProRail DB ÖBB FS RFF Schweiz Japan Niederlande Deutschland Österreich Italien Frankreich SBB Informatik Solution Center Infrastruktur 6

7 SBB Infrastruktur: Ein komplexes System. Telecomnetz 9200 Mitarbeitende 3138 km Schienen 6054 Brücken 303 Tunnel Signale Weichen 6 Wasserkraftwerke 6 Frequenzumformer 1800 km Leitungen 132 kv 2 GSM-R Zentralen Energienetz Schienennetz

8 Mehr als 300 Züge standen still Ca Passagiere waren blockiert Alarme nach 10 Minuten Unzählige Telefone, etc. Operation Managers waren überlastet June 22 nd, pm The blackout

9 If you don t manage the complexity. the complexity manages you. SBB Informatik Solution Center Infrastruktur 9

10 Entgleisung Olten im Jahr 2011.

11 Was passiert bei einer Störung? Die Drähte laufen heiss! Zugverspätungen an Kunden, Lokführer kommunizieren Streckensperrungen Züge umleiten Reparaturzeit abschätzen Kosten ermitteln Hilfsmassnahmen einleiten Drittfirmen für Reparatur beauftragen Ersatzverkehr SLAs Instandsetzung Planen und Schätzen Betroffene Services identifizieren SBB Informatik Solution Center Infrastruktur 11

12 Wie bekommen wir die Situation in den Griff? Mit einer Service Management Architektur, customer and partners Operational Rail control Rail operation (Provisioning of train routes) Business Process Technical Rail operation Business Services Functional unit Services Real Hardware Assets Infrastructure objects SBB Informatik Solution Center Infrastruktur 12

13 Übersicht Service Management Toollandschaft Falls ein critical Event einer gestörten Ressource eine Serviceinstanz verletzt, wird diese Verletzung auf dem SMon angezeigt. Die SLA-verletzenden Events werden in die Event-DB geschrieben. Service Monitor (Service Management, Service Status) SMDB holt sich stündlich die serviceverletzenden Events aus der Event-DB SMDB Service Management Service Inventory DB SMDB enthält die SLA mit den Servicebäumen und SL-Definitionen IMon stellt Eventmeldungen dar (6 Severities) Korrelation Infrastruktur Monitor (Alarm Management, Root Cause Analysis) Element Manager A Element Manager B Element Manager X Prozesse / Workflows Incident; Change; Maintenance Trouble Ticket Change Ticket RMDB Prozesse / Workflows Provisioning ElementMgr liefern dem IMon Events der angeschlossenen Plattformen Ressource Management DB Alle in_service stehenden RMDB-Infrastruktur-Objekte von homologierten Produkten sind dem IMon bekannt SBB Informatik Solution Center Infrastruktur 13

14 Wie bekommen wir die Situation in den Griff? einer guten Organisation, SBB Informatik Solution Center Infrastruktur 14

15 Wie bekommen wir die Situation in den Griff? und standardisierten aber effizienten Prozessen. SBB Informatik Solution Center Infrastruktur 15

16 Die Herausforderung war Prozessharmonisierung und parallel IT-Lösung entwickeln.

17 Ausgangslage Unternehmerweiter BPM Projekte Vollständiges und korrektes Abbild der gesamten Unternehmensprozesse ist Illusion. BPM Lösungen verändern den Ablauf, eine brauchbarere Lösung wird schrittweise gefunden.

18 Bspw. die Projektorganisation, alle «dürfen» mitreden. SBB Informatik Solution Center Infrastruktur 18

19 «Agile» Entwicklung anstelle «Wasserfall» um die Herausforderung zu meistern. Organisation: Projektleitung; Product Owner mit Business Analysten; Business Vertreter; Scrum Master und Entwicklerteam (inkl. Testmanagement) 2-wöchige Sprints Voll funktionsfähige Software alle zwei Wochen Business-Workshops «Grooming» alle zwei Wochen Prozess Harmonisierung Software Anforderungen Workflowmanagementsystem Groiss GmbH) Voll automatisierte Umgebung inklusive Regressionstests Hoher Takt, volle Transparenz und ein ständiges überprüfen ermöglichen das Steuern durch unsichere Gewässer SBB Informatik Solution Center Infrastruktur 19

20 Ablauf und Zeremonien «2-Wochen Rhythmus» Ganztägiger Workshop Business / Domänenvertreter User Stories Business Analysten Analyse Design Entwicklerteam Daily Standups 360 Demo/Review - Kunden - BAs - Entwickler Planungsmeeting (Entw. für 2 Wochen) Workshops Arch. & Entw. Kunden Produkt- Inkrement Themen-Vorschau Agilität zeigt sich im 2-wöchigen Rhythmus Planung am Mittwoch, Review des neuen Produktinkrements 2 Wochen später am Dienstag. SBB Informatik Solution Center Infrastruktur 20

21 Anforderungsmanagement in der Agilen Entwicklung. Anforderungen in Semi-Strukturierten User Stories. Erfassung durch das BA-Team mit Struktur durch Meta-Tags. Aufbau: Beschreibung, Tasks, DOD Grundlage für Test-Struktur Automatische Regressionstest (QTP) Entgegennahme oder Zurückweisung der Stories durch Entwicklerteam Test und Abnahme der Stories am Review inkl. Business/ Kunden Vorgangsweise mit mehr oder weniger unabhängigen User-Stories in Textform (teilweise ergänzt mit Mockup) funktioniert erstaunlich gut. SBB Informatik Solution Center Infrastruktur 21

22 Beispiel einer User Story. [Testvorbereitungen] [0.1] Ein Ticket in einer beliebigen Anlagengattung mit 3 Aufträgen und von jeder internen Aktivität je einen Eintrag (soweit möglich) im Ticket und den Aufträgen. Mindestens eine Notiz und eine Kommunikation wurden vom TLS erzeugt. [0.2] Für alle Testfälle ist der Benutzer eingeloggt und hat das vorbereitete Ticket in der thematischen Ansicht geöffnet [0.3] Für die Herstellung dieser Vorbedingung kann folgendes Szenario geladen werden: /wf/servlet.method/openep.ant.executeant.start?antfile=update/scenarios/update-scenariossmticketbean.xml&target=startprocessbeanstorysm13_00x&dosleeps=1 [Hinweise] - die Datei Report.jrxml wird an einem Ort abgelegt, der vom Team definiert ist und ist nicht Teil der fachlichen Anforderung. [Test] [Case] 1: PDF erzeugen, [1.1] Login als TLS und vorbereitetes Ticket öffnen. In chronologische Ansicht umschalten und via Ansichtsfilter Icon beide "Keine" Knöpfe drücken. PDF- Export Knopf drücken * Ein "Speichern unter..." für die Datei "Report.pdf" wird angeboten bzw. je nach Browsereinstellung wird die Datei Report.pdf im Browser angezeigt. Das PDF öffnen (lassen), es enthält den Inhalt des gesamten vorbereiteten Tickets in Kopf/Körper/Fuss unterteilt, ohne weitere Formatierungen. [Case] 2: Report.jrxml öffnen im ireport [2.1] Die in Fall 1 erzeugte Datei Report.jrxml wird mit dem ireport geöffnet * Report.jrxml ist gültig, lässt sich öffnen und zeigt die hinter dem Report liegenden Queries an. [Case] 3: PDF erzeugen, nur Auftrag 1 und 3, nur Notizen [3.1] Ansichtsfilter-Icon klicken und im Bereich "Einträge anzeigen" die Checkboxen für Notiz und Kommunikation setzen, sowie im Bereich "Aufträge anzeigen" die Markierungen auf Auftrag 1 und 3 setzen. Dialog mit "OK" bestätigen und PDF-Export Knopf drücken. * Ein "Speichern unter..." für die Datei "Report.pdf" wird angeboten bzw. je nach Browsereinstellung wird die Datei Report.pdf im Browser angezeigt. Das PDF öffnen (lassen). Es enthält im Kopfbereich die Informationen des Allgemeinformulars, im Körper alle Notizen und Kommunikationen der Aufträge 1 und 3 in chronologischer Reihenfolge und im Fussbereich die Informationen des Behebungsformulars ohne weitere Formatierungen. SBB Informatik Solution Center Infrastruktur 22

23 Beispiel eines unseren vielen «Board» User Stories / Sprint Backlog 2. Taskstatus / Tasks Open WIP Done 3. Impediment Log 4. Testmanagement Voll im Team integriert 5. Technische Wolke 6 Hinter der Kulisse 6. Geplantes Anderes (Blanko) 4 Ähnlich wie Impediments, meistens von PO beansprucht 5 SBB Informatik Solution Center Infrastruktur 23

24 Traceability und Change Management in der «agilen» Welt noch viel Wichtiger. Interaktive Protokolle für die Workshops Anforderungen «Backlog» Anforderungen in «User Stories» Übersetzt, in HP QC (verwaltbar) Entwickelte Software auf Basis der User Stories SBB Informatik Solution Center Infrastruktur 24

25 Fazit und Kritische Betrachtung der «agilen» Entwicklung. Vorteile Nachteile Transparenz Lauffähige und nützliche Software Inkremente Identifikation mit der Lösung Höhere Usability Zwischenergebnisse als weitere Entscheidungsgrundlage Mehrwert (bzw. Weniger - Wert) sichtbar Finanzielle Steuerung Funktionalitäten werden widerrufen/rückbau Nie fertig werden und immer wieder neue/ andere Anforderungen (Kosten!) Architekturentscheidungen sind schwieriger durchzusetzen Ressourcenengpässe (Lean Produktion) Die grösste Herausforderung war der Kulturwandel und Change Prozess bei Organisation und Menschen SBB Informatik Solution Center Infrastruktur 25

26 Agilität in den Prozessen und Organisation bei der IT-Lösung.

27 Übersicht der Herausforderung.?? Anforderungen Business Restrukturierungen in der Organisation Anpassungen in den Prozessen Agile Entwicklung und Anforderungsmanagement schnelle Releases! Agile Prozessschicht SBB Informatik Solution Center Infrastruktur 27

28 Worklfowmanagementsystem Groiss GmbH) BPM: Vollständige, sehr mächtige Workflow-Engine. Breite Unterstützung von Workflow- Patterns. BPEL Support, grafische Modellierung der Prozesse. DMS BPM DMS: Einfaches und flexibles DMS mit Metadaten, Formularen, Check-in, Check-out, automatisierte Versionierung, etc. Dokumente können direkt in Workflows eingebunden werden. Offene DMS Schnittstelle. Formulare: Formulare-Engine erlaubt z.b. auf Workflow-Schrittebene die Vergabe von Zugriff- und Sichtbarkeiten von Formularfeldern, die Verschachtelung von Formularen. Formularwizard für die Definition von dynamischen ad-hoc Formularen. JEESchnittstellen und Module HA Platform Java EE Oracle DB Reports/BAM: Mächtige Reporting Engine für Business Activity Reporting: Ad-hoc Reporting, Volltextsuche, gespeicherte Reports mit unterschiedlichen Ausgabeformaten. Sicherheitskonzept: Berechtigungen aller Elemente auf Basis der Modellierung von: User, Rollen, Organisationeinheiten, hierarchischen Rollen, Access Control Lists und Mandantenfähigkeit. Schnittstellen und Module: Reuse der Schnittstellen und Komponenten ( , SMS, Webservices, DB, u.v.a.m.) Epha Plattform: Etablierte Rollout Prozesse und Betrieb mit Servicelevel 2a. Java EE: Standardkonforme Applikationsentwicklung, Unterstützung von unzähligen Schnittstellen auf Basis Java EE. Oracle DB: Container für Stammdaten, Workflow Daten und Formulardaten. SBB Informatik Solution Center Infrastruktur 28

29 Technische Lösungsarchitektur. Prozess- Briefcase, Dashboards Prozesse & Prozesskonfigurationen, Business-Rules, Kollaborationen Aggregations- und Management Layer Prozess- und Siloübergreifende Auswertungen für KPIs oder SLAs; Aggregationen oder Adhoc-Reporting über Stammdaten, Rollen, oder Prozesse. Agiler Business Layer: Der Layer ist konfigurativ und enthält die enthält die agilen Prozesse des Unternehmens. Neue Prozesse können adhoc entstehen oder werden agil angepasst. Die Schnittstelle nach oben bleibt stabil: Auswertung von SLA oder KPIs müssen bei Prozessänderungen nicht angepasst werden. UI Bausteine Stammdaten Rollen & OEs Prozess- Library Applikationen & Widgets Services Schnittstellen Prozess-Bausteine: Das Fundament der agilen Prozesse besteht aus wohldefinierten Schnittstellen und Komponenten, die dynamisch per Prozessdefinition kombiniert werden. SBB Informatik Solution Center Infrastruktur 29

30 Flexible Organisation mittels «Hitlisten». Keine «fixen» OEs im Prozessen Lernende UI-Listen Restrukturierungen werden abgefedert Stets die beste Wahl ganz oben Ausnahmefälle möglich SBB Informatik Solution Center Infrastruktur 30

31 Prozessübergreifende KPIs mittels Milestones. TC-Prozess SA-Prozess Unterschiedlichste Prozesse Einheitliche KPIs Fix verhandelte Milestones für alle Prozesse Einheitliche Auswertung möglich Aggregationen möglich (z.b. SLAs, Ampelstatus, etc.) MS Prozess Wer Wann 1 TC Hans 13:13 2 SA Franz 14:11 2 TC Karl 14:21 SBB Informatik Solution Center Infrastruktur 31

32 Veto anstelle von Bestätigungsschritten. Prozess sieht «Bestätigung bei Stillschweigen» vor, z.b. bei niedriger bis mittlerer Priorität oder UI. Schritt Richtung parametrisierte Prozesse. Entlastet Worklists. SBB Informatik Solution Center Infrastruktur 32

33 Formularbausteine. Bei Formularintensiven Prozessen eine übergeordnete, gemeinsam verwendete Struktur definieren. Schritt Richtung parametrisierte Formulare. Entlastet Entwicklung. Ermöglicht Baukastensystem. Gemeinsam verwendete Formularbausteine teilen sich auch die Datenstrukturen. Prozessübergreifende Aggregation möglich! Beispiel: SBB Informatik Solution Center Infrastruktur 33

34 Briefcase Aggregation mit Formularbausteinen. Aufträge (PSxx) Status Ampelstatus Aus den Aufträgen von oben: Checkpoints Aktivitäten, Pendenzen, Status Zugriff Signatur Ampelstatus SBB Informatik Solution Center Infrastruktur 34

35 Extension Points Formular-Architekur festlegen. 1 Tickets: Kernprozess für eine Ticket/Change Skelett für den Change Prozess (Request, Confirm, Execute) Vordefinierte Felder und Stati über alle Change-Typen Jeder Change-Type kann individuell sein oder eine Parametrisierung eines existierendes Change Types, folgt jedoch immer dem Kernprozess und implementiert die Kernschnittstellen Bsp: Ch Req, Op Infrastr. Req., SOS Req, Pf Req, Multipurp. 2 Checkpoints und Milestones 3 Activities Checkpoints und Milestones als Ampelsysteme sind flexible To-Do Listen für einfache Entscheidungen ohne Prozess Prozesse, die von einem Change ausgehen: Planung, Sign- Off, etc Implementieren gemeinsame Schnittstelle! (Status, Creator, Requestor, etc) 4 Briefcase Sammelcontainer für Orders. Zeigt ad-hoc Übersicht über alle enthaltenen Orders, Checkpoints, Activities, Products etc Briefcase Tickets Fields, Checkpoints, Milestones Activities (Sub-Prozesse) Individual Parts Individual Parts Die Elemente (Prozesse, Checkpoints) werden im Baukastenprinzip miteinander verbunden. Änderungen (zb neuer Checkpoint) werden sofort wirksam SBB Informatik Solution Center Infrastruktur 35

36 Kritische Betrachtung und Erfolgsfaktoren. Generell gilt für BPM Projekte: Kunden verstehen BPM und Workflow erst nach einiger Zeit oder nach 1 bis 2 Releases. Kunden denken UI zentriert und sind mit Prozessen, Tasks, Organisationeinheiten, Arbeitskörben meist überfordert. Notwendigkeit zur Anpassung an das BPM Tool wird unterschätzt. Für den Agile/Generische Prozesse gilt: Viel Erfahrung, gute Kenntnis der Prozesse und des Domainmodells notwendig. kann von einem Business Analysten «von der Stange» nicht verlangt werden Kunden vertreten eigenen Bereich, Fachübergreifende Themen sind schwierig zu kommunizieren. SBB Informatik Solution Center Infrastruktur 36

37 Besten Dank für Ihr Interesse.

38 38 SBB Informatik Solution Center Infrastruktur 38