Case Study: Einführung Konzernweites Requirements
Engineering bei den Stadtwerken München
Warum haben die SWM ein einheitliches
Vorgehen für RE definiert?
19.10.2016 RE@SWM2
Kurzvorstellung SWM
Die SWM stehen für eine zuverlässige, sichere Versorgung mit
Strom, Fernwärme, Erdgas und Wasser
Mitar...
Kurzvorstellung SWM
 Jeder Punkt entspricht einem
System, Kanten stellen (bekannte,
dokumentierte) Datenflüsse dar.
 Die...
Herausforderungen an ein konzernübergreifendes RE
Was sind die Konsequenzen der hohen Heterogenität?
 Feste Zuordnung von...
Was sind die Grundideen von RE@SWM?
19.10.2016 RE@SWM6
Vorgehensmodell: Checklisten & Cherry Picking
Große Organisationen erfordern Standards in der Art und Weise, wie
Anforderu...
Vorgehensmodell: Checklisten & Cherry Picking
Unser Informationsmodell fokussiert auf funktionale
Blöcke (aka Fachkomponen...
Vorgehensmodell: Checklisten & Cherry Picking
 Was soll in einem Fachkonzept
beschrieben werden?
 Idee: Definition eines...
Bausteinliste
dient als
„Checkliste“
Auch komplexe Systeme sind aus kleinen Teilen aufgebaut!
19.10.2016 RE@SWM10
Prozesse...
Einführung – Per Anweisung? Eher nicht …
Was funktioniert es bei den SWM?
 Begeisterte finden! Nicht nur in der IT!
 Gem...
Welche Anforderungen bestehen
an die Werkzeugunterstützung?
19.10.2016 RE@SWM12
Tooling – Woher kommen die Anforderungen?
Baustein-Konzept definiert, was wir wie dokumentieren wollen
 (Textuelle) Anfor...
Tooling – Woher kommen die Anforderungen?
Elektronische Publikation von Spezifikationen
 Einfacher Zugang zu Systemspezif...
MID Innovator und smartfacts stellen wesentliche
Werkzeuge zur Unterstützung von RE@SWM dar!
19.10.2016 RE@SWM15
Tooling – Innovator & smartfacts
 Im Rahmen eines Ausschreibungsprozesses konnte sich MID mit dem Tandem
aus Innovator al...
Tooling – Woher kommen die Anforderungen?
Zweck: Erstellung von Modellen
Anwender: Experten (Requirements Engineers)
 Kle...
Repository, Dokumente, kontinuierliche Pflege von Modellen
 Schritt 1: Nutzung von Innovator zur
Modellierung
 Innovator...
Tooling – Woher kommen die Anforderungen?
Zweck: Recherche, Lesen und Kommentieren (Review) von Modellen
Anwender: Konsume...
Repository, Dokumente, kontinuierliche Pflege von Modellen
Stärken von smartfacts – Voll nutzbar bei gefülltem Repository
...
Repository, Dokumente, kontinuierliche Pflege von Modellen
Herausforderung & Potential:
 Anforderungen aus Fachkonzepten ...
Zusammenfassung
19.10.2016 RE@SWM22
Summary
 Die SWM sind heterogen aufgestellt. Die Einführung einer konzernweit gültigen
Methode ist schwierig. Einiger Weg...
Vielen Dank für Ihre Aufmerksamkeit.
Haben Sie Fragen?
Nächste SlideShare
Wird geladen in …5
×

BPM-Club-Treffen am 18.10.16 in Nürnber: Vortrag "Konzernweites Requirements Engineering bei Stadtwerke München"

60 Aufrufe

Veröffentlicht am

Wer hat schon mal von "RE" gehört - Requirements Engineering? - Die etwa 30 Teilnehmer des BPM-Club-Treffens am 18.10.16 in Nürnberg wissen nun etwas mehr über "RE", genauer: wie dieses Thema konzernweit bei Stadtwerke München (SWM) eingeführt wird.

Lesen Sie hier die Teilnehmerstimmen:
https://www.xing.com/communities/posts/nachbericht-konzernweites-requirements-engineering-bei-stadtwerke-muenchen-nuernberg-18-punkt-10-punkt-1012101523

Veröffentlicht in: Business
0 Kommentare
1 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
60
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
1
Aktionen
Geteilt
0
Downloads
2
Kommentare
0
Gefällt mir
1
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

BPM-Club-Treffen am 18.10.16 in Nürnber: Vortrag "Konzernweites Requirements Engineering bei Stadtwerke München"

  1. 1. Case Study: Einführung Konzernweites Requirements Engineering bei den Stadtwerken München
  2. 2. Warum haben die SWM ein einheitliches Vorgehen für RE definiert? 19.10.2016 RE@SWM2
  3. 3. Kurzvorstellung SWM Die SWM stehen für eine zuverlässige, sichere Versorgung mit Strom, Fernwärme, Erdgas und Wasser Mitarbeiter rund 9.700 – zentrale IT, TK, Prozesstechnik über 550 Die Stadtwerke München sind sehr breit aufgestellt 19.10.2016 RE@SWM3 Kunden mehr als 1,2 Millionen Mitarbeiter rund 9.700 Umsatz 2015 rund 6,5 Milliarden Euro Stromnetz rund 12.000 km Fernwärmenetz rund 800 km Erdgasnetz rund 6.000 km Wassernetz rund 3.200 km Verkehrsnetz rund 636 km Fahrgäste mehr als 1,5 Millionen pro Tag
  4. 4. Kurzvorstellung SWM  Jeder Punkt entspricht einem System, Kanten stellen (bekannte, dokumentierte) Datenflüsse dar.  Die „Musik“ spielt in dem komplexen Systemverbund in der Mitte.  Änderungen an einem System haben oft Einflüsse auf andere Systeme.  Anforderungen müssen hier sorgfältig durchdacht werden  Anforderungen müssen klar und für alle Beteiligten verständlich beschrieben werden Als Ergebnis ist die IT sehr komplex … 19.10.2016 RE@SWM4
  5. 5. Herausforderungen an ein konzernübergreifendes RE Was sind die Konsequenzen der hohen Heterogenität?  Feste Zuordnung von Entwicklern zu Fachbereichen: Heterogene Fachbereiche erfordern fachlich und „kulturell*“ viele stark spezialisierte – und damit nicht flexibel einsetzbare – Entwickler  Status Quo, skaliert nicht, problematisch bei wachsendem Ressourcendruck  „Springen“ von Entwicklern zwischen Fachbereichen: „kulturfremder“ Einsatz von IT-Kollegen resultiert in hohen Reibungsverlusten („verstehe Fachbereich nicht“, „ständiges Neuausbilden der IT“) Abhilfe?  Nutzung von RE als „Lingua Franca“, d.h. als gemeinsame konzernweit akzeptierte Basis, die nahe am Fachbereich ist und zugleich ausreichend präzise Anforderungsbeschreibungen erlaubt.  RE als Dolmetscher in alle Richtungen  Spezialisierung auf „Kulturräume“ statt Fachlichkeit oder Technik (kann man lernen) Im Kontext von IT Projekten ist ein heterogenes Setup problematisch 19.10.2016 RE@SWM5
  6. 6. Was sind die Grundideen von RE@SWM? 19.10.2016 RE@SWM6
  7. 7. Vorgehensmodell: Checklisten & Cherry Picking Große Organisationen erfordern Standards in der Art und Weise, wie Anforderungen an ein IT-System strukturiert beschrieben werden  Klares Informationsmodell  Was ist wo wie beschrieben?  Fachkonzept und Technisches Konzept  Wer ist für was verantwortlich?  Funktion des „Requirements Engineers“, Architekten  Klare Anforderungen an die Inhalte und Form von Fachkonzepten  Vorgabe zu betrachtender Sichten auf ein System (Was wird beschrieben?)  Vorgabe verbindlich zu nutzender Notation (Wie wird es beschrieben?)  Vereinfachte Les- und Prüfbarkeit, Vergleichbarkeit herstellen Die (zentrale) IT benötigt – konzernweit! – gute Anforderungen, um effizient arbeiten zu können. 19.10.2016 RE@SWM7 Standardisierung verbessert Vollständigkeit („Checklisten“) und Qualität („Standardmodelle“ statt Prosa) von Anforderungen und Fachkonzepten.
  8. 8. Vorgehensmodell: Checklisten & Cherry Picking Unser Informationsmodell fokussiert auf funktionale Blöcke (aka Fachkomponenten), nicht Projekte 19.10.2016 RE@SWM8 Businesss Cluster 2 Fachkom- ponente 1 Fachkom- ponente 2 Fachkom- ponente 3 Fachkom- ponente 4 Fachlicher Überblick Fachkonzept 1 Fachkonzept 2 Fachkonzept 3 Fachkonzept 4 Business Custer beschreiben komplexe IT-Systeme, die einen betriebswirt- schaftlichen Sachverhalt abbilden. Wiederverwendbare Fachkomponenten sind die Building Blocks eines Business Clusters Der Fachliche Überblick beschreibt den Aufbau des Clusters  Kernziel „Wegweiser zu Fachkomponenten“ Jede Fachkomponente wird detailliert in einem eigenen Fachkonzept mittels Bausteinen beschrieben.
  9. 9. Vorgehensmodell: Checklisten & Cherry Picking  Was soll in einem Fachkonzept beschrieben werden?  Idee: Definition eines Standards, der definierte Aspekte einer Fachkomponente beschreibt  Prozess: BPMN 2  Datenmodell: UML-Klassendiagramme  Anwendungsfälle: Use Cases  Masken: Scribbles  Berichte: definierte KPIs & Layout  Nutzerperspektive: Tabelle mit Rollen & Rechten  Qualitätsanforderungen: Checkliste  etc.  Notation? Die Beste für den Zweck! Standardisierte „Bausteine“ (Inhalt & Notation) beschreiben die Aspekte einer Fachkomponente 19.10.2016 RE@SWM9 Bausteinliste dient als „Checkliste“  Worüber sollte bei der Erhebung von Anforderungen grundsätzlich nachgedacht werden? Die Bausteine unterstützen damit den RE (An was sollte ich (mindestens!) noch denken?)  Zu jedem Baustein gibt es eine „Anleitung“, die  Zweck und Nutzungskonzept,  Input und weitere Verwendung,  Inhalte und Notation sowie  ein Beispiel enthält Die Bausteine standardisieren damit, was wie definiert wird.
  10. 10. Bausteinliste dient als „Checkliste“ Auch komplexe Systeme sind aus kleinen Teilen aufgebaut! 19.10.2016 RE@SWM10 Prozesse BPMN 2.0 Nutzerperspektive Tabellen, Checkliste Datenmodell Klassendiagramm Anwendungsfall Use Case Maskendefinition Scribbles Druckstück Templates Qualitäts- anforderungen Checkliste Fachlicher Überblick UML Komponen- tendiagramm Fachkonzept Prozesse Nutzerperspektive DatenmodellAnwendungsfall Maskendefinition Druckstück Qualitäts- anforderungen … Prozesse DatenmodellAnwendungsfall Maskendefinition Druckstück … Prozesse DatenmodellAnwendungsfall Maskendefinition Druckstück … Vorgehensmodell: Checklisten & Cherry Picking
  11. 11. Einführung – Per Anweisung? Eher nicht … Was funktioniert es bei den SWM?  Begeisterte finden! Nicht nur in der IT!  Gemeinsam Methode für die SWM entwickeln  Vorgesetzte überzeugen  Organisatorische Verantwortung für die Methode definieren: Die RE Leitungsrunde  Coachen & Überzeugen, Success Stories erzählen!  Coachen & Überzeugen , Success Stories erzählen!  … Was hat nicht funktioniert?  Richtlinien, Arbeitsanweisungen, GF-Beschlüsse: Wir sind im Dschungel der Kompetenzen untergegangen 19.10.2016 RE@SWM11 Vorgehensmodell: Checklisten & Cherry Picking
  12. 12. Welche Anforderungen bestehen an die Werkzeugunterstützung? 19.10.2016 RE@SWM12
  13. 13. Tooling – Woher kommen die Anforderungen? Baustein-Konzept definiert, was wir wie dokumentieren wollen  (Textuelle) Anforderungen  UML2-Diagramme  BPMN2-Diagramme  Erfassen von Spezifikationstexten zu allen Elementen Nachhaltige Spezifikation – Repository-Ansatz … Bislang verfolgten die SWM einen Dokumenten-basierten Ansatz; dies führt leider oft zu „veralteten Dokumenten“. Eine nachhaltige Dokumentation erfordert einen klar definierte „Quelle der Wahrheit“ – also ein Spezifikations-Repository, wobei … … und zugleich Dokumentenexport … unsere Stakeholder stark an Dokumenten-basierte Reviews gewöhnt sind. Ein unmittelbarer flächendeckender Wechsel zu einem rein Repository-basierten Ansatz ist daher schwierig. Die Methode RE@SWM definiert die Anforderungen an das Tooling – MID hat sich in einem Ausschreibungsverfahren durchgesetzt 19.10.2016 RE@SWM13
  14. 14. Tooling – Woher kommen die Anforderungen? Elektronische Publikation von Spezifikationen  Einfacher Zugang zu Systemspezifikationen ohne Expertenwissen für komplexe Modellierungstools erforderlich  Abhängigkeiten zwischen Elementen müssen nachverfolgbar sein Review-Support ist dort erforderlich  Aktualisierte oder neue Spezifikationselemente müssen über das Tooling einem Review unterzogen werden können  Insbesondere im Kontext von Weiterentwicklungen ist eine Versionierung und Vergleichsfunktionen verschiedener Versionen erforderlich Mittelfristig wollen wir auf Dokumente verzichten 19.10.2016 RE@SWM14
  15. 15. MID Innovator und smartfacts stellen wesentliche Werkzeuge zur Unterstützung von RE@SWM dar! 19.10.2016 RE@SWM15
  16. 16. Tooling – Innovator & smartfacts  Im Rahmen eines Ausschreibungsprozesses konnte sich MID mit dem Tandem aus Innovator als Modellierungstool (Experten, Modellerstellung) und smartfacts zur Publikation der Spezifikationen (Konsumenten, Reviewgeber) durchsetzen  Im ersten Quartal 16 wurde Innovator durch MID Berater entsprechend der Methode RE@SWM konfiguriert (incl. Dokumentenexport)  Wir konnten unsere Methode ohne Anpassung am Tool selbst zu 95% umsetzen. Das hat unsere Erwartungen übertroffen!  Wir generieren unsere Fachkonzepte entsprechen unserer Methode RE@SWM und der zuvor definierten Templates direkt aus Innovator.  MID wird bei den SWM seit 04/16 produktiv genutzt, aktuell haben wir gerade Version 13 eingeführt. Unsere Erfahrungen seitdem sind sehr positiv!  Flächendeckender Einsatz? Nein, aber es wird beständig mehr! MID Innovator und smartfacts haben die SWM überzeugt; die Tools werden seit einem halben Jahr produktiv genutzt 19.10.2016 RE@SWM16
  17. 17. Tooling – Woher kommen die Anforderungen? Zweck: Erstellung von Modellen Anwender: Experten (Requirements Engineers)  Kleiner, definierter Personenkreis  In-House Schulungen nach Train-the-Trainer Schulung von MID Kernfeatures  UML- und BPMN-Modellierung ebenso …  … wie textuelle Spezifikationen und Anforderungen  Dokumentenexport Innovator ist das empfohlene Modellierungstool der SWM 19.10.2016 RE@SWM17
  18. 18. Repository, Dokumente, kontinuierliche Pflege von Modellen  Schritt 1: Nutzung von Innovator zur Modellierung  Innovator wird ausgerollt, die Kollegen nutzen Innovator zur Modellierung, Fachkonzepte werden (teils) konventionell (aka Word) erstellt.  Schritt 2: Konsequente Nutzung des Repositories  Etablierung der Nutzung des Repositories erfordert ein langfristiges Engagement  Qualitätskontrolle erforderlich  Mittelfristig: Verzicht auf Dokumenten- zentrierten Ansatz? Quo Vadis RE-Informationsmodell? Fachkonzept vs. Repository 19.10.2016 RE@SWM18
  19. 19. Tooling – Woher kommen die Anforderungen? Zweck: Recherche, Lesen und Kommentieren (Review) von Modellen Anwender: Konsumenten von Spezifikationen (Entwickler und Fachexperten)  Vielzahl von Nutzern  Gelegenheitsnutzer; Tool muss selbsterklärend sein Kernfeatures  Publikation  Versionierung  Impact Analyse  Kommentierung und Reviews  Traceability über Modelle hinweg smartfacts dient zur Publikation, Recherche und Review von Modellen (Spezifikationen) 19.10.2016 RE@SWM19
  20. 20. Repository, Dokumente, kontinuierliche Pflege von Modellen Stärken von smartfacts – Voll nutzbar bei gefülltem Repository 19.10.2016 RE@SWM Wasleistet smartfacs? • Recherche – „Google für Modelle“ • Versionierung mit graphischen Versions- vergleichen • Verknüpfungen und Impact Analyse • Kommentierung und Review-Support Wiewollenwirdiese Featureseinsetzen? • Auffinden bestehender Services • Nachvollziehen von Änderungen an der Fachlichkeit • Beziehungen zwischen Fachlichkeit und Technik darstellen - Traceability • Erfassen von Änderungswünschen direkt am Modell 20
  21. 21. Repository, Dokumente, kontinuierliche Pflege von Modellen Herausforderung & Potential:  Anforderungen aus Fachkonzepten sind häufig im technischen Konzept nicht direkt nachvollziehbar (fehlende Traceability)  Über smartfacts können diese Beziehungen definiert werden  Direkte (..) technische Weiterverarbeitung der BPMN-Modelle in WF-Engine … in Arbeit  Migration bestehender Modelle nach Innovator / smartfacts … in Arbeit  Beziehungen zu UAM-Modellen in pIT  Beziehungen zu ITSM Service Landschaft Ausblick: Ausweitung von RE@SWM auf Schwester- disziplinen (Innovator und / oder smartfacts) 19.10.2016 RE@SWM21
  22. 22. Zusammenfassung 19.10.2016 RE@SWM22
  23. 23. Summary  Die SWM sind heterogen aufgestellt. Die Einführung einer konzernweit gültigen Methode ist schwierig. Einiger Weg: Überzeugen, überzeugen, überzeugen …  Einführung RE verändert Arbeitsweisen – und muss „verkauft“ werden  Dem Management, durch Darstellung der Effizienz (Kosten & Aufwände)  Den Anwendern, durch klare Vorgaben, Support, und Darstellung des individuellen Nutzens  Durch organisatorische Verankerung des Themas – Es muss Personen geben, die das Thema im Konzern vertreten, coachen und nachhalten  Unsere Methode ist pragmatisch, flexibel und leicht erlernbar  Beschreibung von Systemen durch Bausteine  Nutzung der “passenden“ Standardnotation (UML Basisdiagramme, BPMN)  Mit dem MID Innovator und smartfacts haben wir ein Tooling gefunden, dass unsere Methode und die gelebte Praxis bei den SWM sehr gut unterstützt.  Wir stehen erst am Anfang die Potentiale auszuschöpfen! Wo stehen wir, was haben wir gelernt? 19.10.2016 RE@SWM23
  24. 24. Vielen Dank für Ihre Aufmerksamkeit. Haben Sie Fragen?

×