Projektbeschreibung

Der Kunde wollte seine Time-to-Market, sowie seine Umsetzungseffizienz bei Produkt-Einführungen deutlich verbessern. Hierzu sollte ein zentraler Produktkatalog implementiert werden, der die mangelhafte und redundante Abbildung von Festnetz/DLS Breitband und Mobilfunk Produkten in den Bestandssystemen zur Erfassung von Kunden-Aufträgen ablösen sollte.

Die verfolgte Vision war es zu ermöglichen, ein neues Produktportfolio über alle Auftragskanäle und über alle Marken hinweg einzuführen, ohne die Notwendigkeit von Anpassungen in den diversen Bestandssystemen. Stattdessen sollte eine Anpassung der Konfiguration im neuen Produktkatalog dafür ausreichen. Auch sollte es dem Produktmanagement ermöglicht werden, solche Änderungen im Produktkatalog eines Tages selber durchzu- führen. Gleichzeitig sollte die Provisionierung der Aufträge möglichst nah an “zero-touch” kommen.

Das Diagramm hierunter veranschaulicht die mit genannter Vision verbundene Zielarchitektur:

Erläuterung zur Zielarchitektur:

• Der Produkt-Katalog als zentraler Datenbestand mit den Produkten, mitsamt ihren Eigenschaften sowie die gesamte deklarative Logik zu den Produkten

• Der Produkt-Designer als UI basierte Anwendung, über die der Produktmanager die Produkte gemäß Marktbedürfnissen definiert

• Der Produkt-Konfigurator der alle ausführende Produktlogik enthält; die also die Produktlogik situativ ausführt, abhängig von:

  • ob es sich um einen Bestandskunden oder Neukunden handelt

  • um welchen Geschäftsfall es sich handelt (neues Produkt, Produktwechsel oder Produktänderung (Vertragsanpassung))

  • über welchen Kanal der Auftrag kommt

  • ob gerade etwaige Aktionen gelten

  • im Falle von Breitband Produkten: welche Technologien mit welcher Bandbreite (Leitungsdämpfung) an der Adresse verfügbar sind

• Jeder Vertriebskanal wurde von eigenständigen Systemen (Portalen) unterstützt. Der Produkt-Konfigurator sollte hier überall eingebunden werden und dort die Produkt-Auftragslogik ersetzen. Weil das System für Shops und Vertriebspartner zu sehr veraltet war, um es sinnvoll und effizient in der neuen Architektur weiter zu verwenden, wurde entschieden, sie durch eine komplette Neuentwicklung zu ersetzen und dieses im Rahmen dieses Projektes gleich mit umzusetzen.

• Im Bereich Billing wurde parallel zu unserem Projekt ebenfalls ein neues System implementiert. Dieses verfolgte ein neues Konzept, ebenfalls mit dem Ziel den Time-to-Market erheblich zu reduzieren. Es basierte darauf, dass hier keine Produkt-Preisinformation mehr gepflegt werden sollte. Der neue Produktkatalog sollte das übernehmen und die Preisinformationen zusammen mit den Vertragsinformationen bei Vertragsabschlüssen ans Billing liefern.

Im Laufe des Projektes kam noch eine weitere Aufgabe auf uns zu:

• Ein paralleles Projekt war gerade dabei, ein neues Dokumenten-Management Systems einzuführen, welches ebenfalls mit den Front-End Systemen (Portalen) für die verschiedenen Vertriebskanäle integriert werden sollte. In diesem Zusammenhang wurde entschieden, in unserem Projekt zusätzlich einen Dokumenten-Katalog zu implementieren und mit dem Dokumenten-Management System, sowie den Front-End Systemen (Portalen) zu integrieren. Auf ähnliche Art und Weise wie für neue Produkte über den Produkt-Katalog, wurde es über den Dokumenten-Katalog ermöglicht zu definieren, welche Dokumente bei welchem Produktauftrag, von welcher Kundengruppe über welchen Kanal mitgesendet werden. Das betraf AGB‘s, Widerrufbelehrungen, Produktbroschüren usw.

Meine Aufgaben

• Innerhalb eines Programms, aufgelegt um die Systemlandschaft des Unternehmens neu zu strukturieren und zu konsolidieren, habe ich das Projekt geplant und nach agiler/hybrider Methodik geleitet.

• Als der Projekt-Architekt dann das Unternehmen nach knapp einem Jahr verließ, habe ich in großem Umfang gestalterische Aufgaben bezüglich Erstellung von fachlichen und technischen Konzepten mit übernommen.

• Im Bereich der Business Analyse habe ich tatkräftig unterstützt; von den zirka 200 in 2014 erstellten User Stories, habe ich etwa die Hälfte dazu gesteuert.

• Mit Unterstützung der Leiterin des oben genannten Programms habe ich viel Aufwand und Energie aufgebracht, um alle Bereiche des Unternehmens von unserer Vision und Ansatz zu überzeugen. Das betraf die Geschäftsführung, das Produktmanagement, den Vertrieb, das Auftragsmanagement, den Kundenservice, den Technikbereich und nicht zuletzt die IT selber.

• Zum Schluss beinhaltete meine Aufgabe auch die Planung, Organisation und Durchführung des Trainings für die gesamte Vertriebsorganisation mit etwa 1.000 internen und externen Mitarbeitern.

Umstände und Rahmenbedingungen

Das Projekt betrat in vielerlei Hinsicht Neuland; das Konzept von Katalog-basierter Produktbeauftragung, agiler Entwicklung, projektbasiertem Arbeiten waren allesamt neue Ansätze für die Organisation. Unser Projekt sah sich deshalb mit mehreren Herausforderungen konfrontiert, auf die ich in den folgenden Abschnitten näher eingehe.

Neues Konzept, neue Sprache

Für den Kunden generell bedeutete dieses Projekt die Adoption eines komplett neuen Konzeptes; die der Katologbasierten Auftragsverarbeitung. Das gesamte Unternehmen hatte sich über Jahre an die technischen Gegebenheiten, geprägt von den Einschränkungen der Bestandssysteme, gewöhnt. Somit hat sich eine „IT-technische Realität“ und vor allem Sprache entwickelt die in großen Teilen fernab von der fachlichen Realität war. Auch der Fachbereich hatte diese Sprache über die Jahre angewöhnt. In der Folge wurden Diskussionen über fachliche Anforderungen und auch die Akzeptanz des neuen Konzeptes maßgeblich erschwert. Es musste von daher sehr viel Aufwand für das “Abholen” der gesamten Organisation und vor allem des Produktmanagements investiert werden.

Zwei Geschwindigkeiten

Unser Projekt verfolgte das Ziel, in großen Schritten eine neue Systemwelt zu schaffen. Es war uns allen klar, dass die Herausforderungen gewaltig waren. Es würde auch Probleme geben, die wir bereit sein mussten zu akzeptieren. Wir waren der feste Überzeugung, dass eine hohe Umsetzungsgeschwindigkeit und Risikobereitschaft für das Erreichen unserer Ziele unabdingbar war. Das passte auch gut zur Kultur der Vertriebsabteilungen, unseren primären Stakeholder.

Diese Herangehensweise kollidierte aber mit der - verständlicherweise - mehr auf Problemvermeidung und Prozesskonformität ausgelegter Kultur in der IT-Abteilung, welche feste Releases mit vorab definierten Inhalten plante und eine ausgefeilte Prozedur bei der Umsetzung hatte.

Architektur

Es gab zum Projektstart ein umfangreiches monolithisches System welches viele Aufgaben in einem hatte:

• Kunden Management

• Vertragsmanagement

• Auftragsmanagement

• Produktmanagement

• Technischer Provisionierung (Einrichten von Konfiguration in den technischen Systeme, im Rahmen des Aufschalten eines neuen Kunden oder Anpassung aufgrund eines Produktwechsels).

Ein groß aufgelegtes Programm hatte das Ziel dieses System in einzelnen fachlichen Bereiche zu zerlegen. Unser Projekt deckte diesbezüglich schwerpunktmäßig den Bereiche Produkt- und Auftragsmanagement ab. Der Architekturkreis des Unternehmens versuchte mithilfe des SID Modells vom TM Forum die zukünftige Systemarchitektur zu modellieren.

Überblick Vorgehen

Die Entwicklung war komplett auf Scrum eingestellt. Das Projekt war in einem Programm eingebettet, welches klassisch aufgestellt war; mit Projektleiter für die verschiedene Projekte, die eine Zeit- und Budgetplanung erstellten und wöchentlich dazu berichteten. Mit den primären Stakeholdern waren zudem Vereinbarungen zu wichtigen Meilensteinen gemacht worden. Das gesamte Vorgehen kann somit als Hybrid gekennzeichnet werden.

Business Analyse

Anfänglich hat unser Business Analyst bei der fachlichen Konzipierung ausführliche EPK Diagramme erstellt, begleitet von Beschreibungen die sich am eTOM Framework vom TMForum orientierten. Es stellte sich heraus, dass diese für Entwickler zu wenig Hilfestellung boten; die Diagramme waren sehr schwer zu lesen und trotz des enormen Umfangs blieben viele wesentliche Fragen aus Entwicklersicht unbeantwortet.

In der Folge haben wir dann die fachliche Konzipierung auf zwei neue Standbeine gebracht.

1. Den Prinzipien des Domain Driven Design (Eric Evans) folgend haben wir fachliche Modelle erstellt. Für alle Bereiche wurden gemeinsam im Team die fachlichen Datenmodelle konzipierten und - das ist das Entscheidende - diese auch intensiv mit den Fachbereichen besprochen. Diese Modelle wurden mithilfe von UML erstellt, ohne den Anspruch zu verfolgen methodisch 100% korrekt zu sein. Die Zielstellung war lediglich, dass die wesentlichen Fragestellungen in Diskussionen im Team und mit den Fachbereichen beantwortet werden konnten. Dieses mündete in ein sogenanntes TK Domainen Modell, welches eine einheitliche Definition über Systemgrenzen hinweg für Begriffe und Entitäten darstellte. Dies sollte dann später für das Gesamtunternehmen Gültigkeit haben.

2. Für alle Masken erstellten wir UI-Mockups mithilfe des Balsamic Plugins für Confluence. Zu den Masken beschrieben wir in Confluence dann alle wesentliche Business Logik.

Wir erstellten User Stories, die sich im Wesentlichen an die Masken orientierten. Pro Maske gab es mehreren User Stories, die auf der Confluence Seite zu der jeweiligen Maske verlinkt wurden.

Genannte fachliche Modelle, die Maskenentwürfe sowie die User Stories haben wir mit dem für den Vertrieb zuständigen Manager in einer Product Owner Runde durchgesprochen, was sich als besonders effektiv erwies. Auch die Backlog-Priorisierung wurde hier besprochen.

Hierunter ein Beispiel eines fachlichen Modells, welches ich erstellt habe um das User-Management und die Verwaltung von Vertriebspunkten (eigene Shops und Vertriebspartner) zu gestalten.

Wir hatten eine interessante Diskussion im Projekt, ob man solch ein Modell denn wohl oder nicht mit dem Fachbereich diskutieren könnte, da es doch sehr technisch ist. Wir haben es gemacht und es hat wunderbar funktioniert.

Wir brauchten einige wenige Runden um uns schlussendlich auf eine finale Version zu verständigten. Die darauffolgende Umsetzung war schnell und reibungslos.

Entwicklung

Die Entwicklung orientierte sich an Scrum; es wurde teilweise Pair Programming betrieben, andernfalls gab es peer / code Reviews mit Hilfe von FishEye. Es gab Groomings, Plannings samt Planning-Poker, 2 bzw. 3 wöchigen Sprints und Sprint-Reviews. Es wurde kontinuierlich integriert und ein maximales Maß an Testautomation durch die Entwicklung (Unit-Tests) betrieben. Dieses wurden mit Sonar-Auswertungen überwacht, tabellarischen und grafischen Darstellungen daraus wurden auf einem großen Bildschirm in einer der Entwicklerbüros kontinuierlich angezeigt. Des Weiteren wurde In der Entwicklung CVS, GIT und Jenkins eingesetzt.

Die Modelle, die für alle fachliche Domänen erstellt wurden (siehe oben unter Business Analyse) ermöglichte eine saubere Entwicklung, und führte zu eine Softwarearchitecktur, die sehr anpassungsfähig war. Auch war es relativ leicht, neue Entwickler im Team zu integrieren, weil nach einem einheitlichen Standard entwickelt wurde und in der Software die Fachlichkeit leicht zu erkennen war. Somit konnten sie sich relativ schnell einarbeiten.

Die durchgängig erstellten und im Vorfeld mit den Productowner durchgesprochenen Maskenentwürfe erlaubten eine zügige und effiziente Entwicklung, denn die Fachbereiche hatten die Anwendung bereits „gesehen“ bevor sie fertiggestellt wurde. Große „aha“ Erlebnisse gefolgt von umfangreichen re-factorings konnten so einfach vermieden werden.

Test

Im Testteam wurde HP Quality Center für Test- und Defect Management eingesetzt. Über eine Schnittstelle wurde Defects für die Entwicklung in Jira überführt. Aus den Jira Tickets konnte ein Drill Down bis auf die Code Stellen gemacht werden. Darüber hinaus gab es auf Integrationsebene automatisierte Tests, die mit Hilfe von HP Service Virtualisation entwickelt wurden. Diese Tests waren auch sehr hilfreich, um Performance Probleme auf den Grund zu gehen, weil man für einzelne Transaktionen oder Aufrufe aus dem Front-End genau verfolgen konnte, welchen Service und welches System im Middleware bzw. Backend wieviel von der Gesamtdauer in Anspruch nahm.

Hybrides Projektmanagement

Wie beschrieben, wurde in der Entwicklung nach Scrum vorgegangen. Daraus ergab sich bekanntlich die Herausforderung, verbindliche Zusagen über wesentliche Meilensteine an die Stakeholder zu machen. Zu denen gehörte das Programm Management, die Geschäftsführung, der Vertrieb und der Kundenservice. Sie brauchten diese Zusagen für die Planung der Vertriebszahlen und für die Personalplanung. Denn beide mussten zur Konzernebene verantwortet werden.

Diesbezüglich bin ich wie folgt vorgegangen:

• Die Backlogplanung habe ich hin und wieder aus Jira nach Excel exportiert.

• Weil nur die User Stories für den kommenden Sprint gegroomed und gepokert waren, hatte ich erst mal keinen belastbaren Anhaltspunkt, wann die User Stories die für ein bestimmtes Inkrement/Meilenstein benötigt wurden alle fertig sein würden.

• In Excel habe ich dann Spalten für verschiedene Umsetzungsbereiche hinzugefügt. Mit den Architekten und Entwicklern wurden dann für diese Bereiche pro User Story SML Komplexitätsbewertungen abgegeben.

• Mit einem Algorithmus wurde dann der Aufwand pro Entwickler Disziplin berechnet.

• Die so ermittelten Aufwände wurden gegen die voraussichtlichen Kapazitäten unter Berücksichtigung von Urlaubszeiten usw. gerechnet und ermöglichten dann die Terminaussagen zu den Meilensteinen.