24
Case Study: Einführung Konzernweites Requirements Engineering bei den Stadtwerken München

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

Embed Size (px)

Citation preview

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

Case Study: Einführung Konzernweites Requirements

Engineering bei den Stadtwerken München

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

Warum haben die SWM ein einheitliches

Vorgehen für RE definiert?

19.10.2016 RE@SWM2

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

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

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

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

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

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

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

Was sind die Grundideen von RE@SWM?

19.10.2016 RE@SWM6

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

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.

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

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 1Fachkom-

ponente 2Fachkom-

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.

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

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.

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

Bausteinliste

dient als

„Checkliste“

Auch komplexe Systeme sind aus kleinen Teilen aufgebaut!

19.10.2016 RE@SWM10

Prozesse

BPMN 2.0

NutzerperspektiveTabellen, Checkliste

DatenmodellKlassendiagramm

Anwendungsfall

Use Case

MaskendefinitionScribbles

DruckstückTemplates

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

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

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

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

Welche Anforderungen bestehen

an die Werkzeugunterstützung?

19.10.2016 RE@SWM12

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

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

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

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

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

MID Innovator und smartfacts stellen wesentliche

Werkzeuge zur Unterstützung von RE@SWM dar!

19.10.2016 RE@SWM15

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

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

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

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

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

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

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

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

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

Repository, Dokumente, kontinuierliche Pflege von Modellen

Stärken von smartfacts – Voll nutzbar bei gefülltem Repository

19.10.2016 RE@SWM

Wa

s le

iste

t s

ma

rtfa

cs

? • Recherche – „Google für Modelle“

• Versionierung mit graphischen Versions-vergleichen

• Verknüpfungen und Impact Analyse

• Kommentierung und Review-Support

Wie

wo

llen

wir

die

se

Fe

atu

res

ein

se

tze

n? • Auffinden bestehender

Services

• Nachvollziehen von Änderungen an der Fachlichkeit

• Beziehungen zwischen Fachlichkeit und Technik darstellen - Traceability

• Erfassen von Änderungswünschen direkt am Modell

20

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

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

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

Zusammenfassung

19.10.2016 RE@SWM22

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

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

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

Vielen Dank für Ihre Aufmerksamkeit.

Haben Sie Fragen?