IT für Energieversorger – mit Releasemanagement vom Reagieren zum Agieren

Seit Jahren wird die Regulation der Energieversorgungsbranche vorangetrieben. Es scheint, dass zusätzliche Kosten insbesondere aus der Energiewende von staatlicher Hand gesteuert auf die (hauptsächlich privaten) Verbraucher umgelegt werden – und zur Kompensation die Erlöse der Energieversorgungsunternehmen reduziert werden müssen (um die absolute Preissteigerung möglichst gering zu halten). Neben beschnittenen Gewinnen geschieht dies im Wesentlichen durch den Versuch des Regulators, durch die übergreifende Vereinheitlichung von Prozessen nicht nur den offenen Markt zu unterstützen sondern auch die Effizienz zu erhöhen. Ob dies de facto auch gelingt oder ob dadurch bestehende Prozesse immer komplexer in der Umsetzung und damit auch teurer in der Kostenstruktur werden, sei dahingestellt.

In jedem Falle hat es sich eingeschliffen, dass mindestens zwei Mal jährlich der Regulator mit Änderungen an standardisierten Marktkommunikationsprotokollen und teilweise auch mit der Veränderung an zugrundeliegenden Prozessen daherkommt. Diese sind dann in der Regel innerhalb weniger Wochen umzusetzen. Für die IT der Energieversorgungsbranche bedeutet dies, dass es mindestens zwei Termine im Jahr gibt (momentan der 01.04. und der 01.10. des Jahres), zu dem regelmäßige Änderungen an IT-Systemen und den darauf laufenden Prozessen vorgenommen werden müssen.

Einerseits kann man bei vielen Energieversorgern und deren IT-Dienstleistern mit genau dieser Regelmäßigkeit beobachten, dass vor jedem dieser beiden Termine der mehr oder weniger ausgeprägte Aktionismus entsteht, kurzfristig entsprechende Projekte aufzusetzen, Projektteams zu schneiden, Tests vorzubereiten, bei Näherkommen des Stichtags Wochenendeinsätze zu fahren, aufgrund der „plötzlich“ auftretenden Ressourcenknappheit parallele Projekte zu bremsen oder auszusetzen …. dieses Bild ist seit Jahren bekannt, und bisher nur in wenigen Häusern wirklich effizient geändert worden. Bei vielen Kunden höre ich eine Mischung aus Frust und „Vorfreude“ auf die genannten teils chaotischen Umstände wenn von der „nächsten Formatumstellung“ die Rede ist.

Aus Sicht des Anforderungsmanagements ist diese Situation ein „Paradies auf Erden“ – Anforderungen an Prozess- und damit IT-Änderungen kommen quasi von „Gesetzeshand“, eine Abstimmung mit Anforderern muss nicht erfolgen – das macht die Analyse und Aufbereitung einfach. Und noch viel besser: der Termin zur Umsetzung muss weder gefunden, noch diskutiert werden. Mit gewohnter Regelmäßigkeit ergeben sich damit im Jahr mindestens zwei „Releases“, zu den Änderungen an IT-Systemen der Energieversorger stattfinden MÜSSEN. Aus der Perspektive der Planbarkeit ist das mehr eine Chance als dass es ein Problem darstellt. Denn damit lassen sich übergreifend Umsetzungsprojekte standardisiert einplanen, auf die Terminkette setzen und routinemäßig umsetzen:

Der Termin – Paketierung in Releases

Die Vorgaben des Regulators sind zu festen Terminen umzusetzen – momentan geschieht dies zwei Mal jährlich zum 01.04. und zum 01.10. – die Umsetzungen erfordern meistens ein intensives Testen der Änderungen unmittelbar vor dem Umsetzungstermin.

Aus technischen Gründen ist es zudem oftmals so, dass im Zeitraum der vorgelagerten Entwicklung und der Tests keine weiteren Änderungen (z.B. aus Parallelprojekten) umgesetzt und produktiv gestellt werden können. Daraus resultiert zumeist ein Zeitraum, in dem keine Änderungen an produktiven IT-Systemen umgesetzt werden können (sogenannte „frozen zone“, im SAP Umfeld auch „Transportstopp“ genannt). Es liegt auf der Hand, dass man diese „Liefertermine“ zu offiziellen Releases erklärt, zu denen regelmäßig funktionale Veränderungen an den IT-Systemen und darauf laufenden Prozessen vorsieht.

Etabliert man ein Release-Denken in der Umsetzung von IT-Projekten, kann dies ein Paradigmenwechsel bedeuten: weg zu „jedes Projekt setzt seine Änderungen produktiv wenn es fertig ist“ oder auch „der Kunde bekommt seine Änderungswünsche immer zum Wunschtermin (häufig: schnellstmöglich) umgesetzt“ hin zu „Planmäßige Änderungen werden nur zu zuvor definierten Releaseterminen umgesetzt“. Zwei davon kennen wir bereits (den 01.04. und den 01.10.) seit Jahren, dazwischen lassen sich nun weitere Releasetermine definieren (z,B, der 01.01. und 01.06.) an dem weitere funktionale Veränderungen umgesetzt werden können. So lassen sich diese 4 Releases zum Beispiel nach „gesetzlichen Vorgaben“ (01.04. und 01.10.) und „Anforderungen der Kunden“ (01.01. und 01.06.) schneiden.

In Folge gliedern sich alle Projekte in diese 4 Termine ein, die Terminsteuerung wird einfacher weil standardisiert, das Testen wird planbarer weil zu festen Zeitpunkten und entsprechend übergreifend, die Einsteuerung der Ressourcenbedarfe wird planbarer.

Die parallele Welt – Übersicht im Projektportfolio

Entscheidend für das Bilden von Releases ist die Kenntnis anstehender und laufender Projekte – und zwar aller Projekte die zu Änderungen an IT-Systemen führen. Nur wenn alle Projekte bekannt sind, können diese auf die einzelnen Releases „verteilt“ werden und deren Umsetzung auf dem Zeitstrahl eingeplant werden.

Diese Übersicht ergibt sich aus dem Projektportfolio, welches an zentraler Stelle im Unternehmen aufgebaut und fortgeschrieben werden sollte. In der Regel hat das Managements jedes Unternehmens an einem solchen Portfolio gesteigertes Interesse – alleine weil es einen Überblick über die Aktivitäten im Projektbereich des Unternehmens gibt, und weil sich hier an zentraler Stelle eine Darstellung zu Kosten, Erlösen und Ressourcenbedarfen liefert.

Für das Release Management ist das Projektportfolio daher von entscheidender Bedeutung, für das gesamte Management bildet es die Grundlage zur Planungssicherheit (da es nicht nur laufende sondern insbesondere auch anstehende Projekte enthält). Und wenn man dieses Portfolio regelmäßig vor dem Management präsentiert, so lassen sich „ganz nebenbei“ vor dem Management des Unternehmens präsentiert (und gf auch mit den betroffenen Kunden abstimmt, gemeinsam erstellt), so sollte auch zugleich die Priorität der einzelnen Projekte im Vergleich zueinander abgestimmt werden. In Kombination mit terminlichen Vorgaben fällt so zugleich die „Umsetzungsreihenfolge“ bzw. „welches Projekt wird zu welchem Release umgesetzt“ geklärt.

Die Ressourcen – Optimale Auslastung der Kapazitäten

Bringen Sie alle Projekte auf ein Portfolio und verteilen Sie hieraus anschließend auf die Releases macht es Sinn, bereits im Projektportfolio jedes einzelnen Projekt mit einer (anfänglich noch groben, mit zeitlichen Näherrücken der Realisierung detaillierten) Aufwandsschätzung zu versehen. Oftmals wird die Schätzung nicht auf einzelne Ressourcen (Mitarbeiter) herunter zu brechen sein, je nach Skillset kann aber auf Teams heruntergebrochen werden. Damit bietet sich die Grundlage für eine Kapazitätsorientierte Planung der Releases: die Kapazität ihrer fachlichen Teams ist bekannt, damit wissen Sie, wie viele Ressourcen sie je Release „verplanen“ können.

Damit wird ein weiterer Aspekt beim Zuschnitt der Inhalte der Releases deutlich: da sie aus dem Projektportfolio die kapazitativen Bedarfe je Projekt kennen, können bei der Planung der Releases die Kapazitäten optimal eingeplant werden. Auf diese Weise bietet sich die Möglichkeit, die freien Kapazitäten im Unternehmen optimal einzuplanen – und Über- oder Unterbelastungen zu vermeiden. Hier wird deutlich, wie wichtig es ist, alle Projekte im Projektportfolio aufgezeigt zu haben. Weiterhin wird deutlich, dass eine Abgrenzung der einzelnen Kapazitäten nach Tagesgeschäft (Support, Betrieb, Einbindung in BPO …) und Projekten erfolgen muss.

Bekommt man diesen “Dreisatz” (gebundene Kapazität im Tagesgeschäft, gebundene Kapazität im Projektgeschäft, gebundene sonstige Kapazität wie Urlaub, Krankheit, Weiterbildung) annäherungsweise hin, ergibt sich hierdurch die Chance zu einer nivellierten Kapazitätsbelastung ohne wesentliche Spitzenbelastungen oder „Auslastungtälern“.

Die Umsetzung – Abfahren im Standardprojekt

Die Umsetzung in Releases bedeutet, dass es für jedes Release genau ein Projekt gibt, in dem die jeweiligen Anforderungen und Veränderungen umgesetzt werden. Die Abstimmung mehrerer Projekte gleichzeitig entfällt weitestgehend (natürlich wird es parallel einige wenige langlaufende Projekte geben). Der Ablauf eines solchen „Releaseprojekts“ verläuft von Mal zu Mal weitestgehend gleich – Analyse der Anforderungen, Zuschnitt der Themen in Teilprojekte, gemeinsame Entwicklung und gemeinsamer Test.

Insbesondere bei gemeinsamer Entwicklung und gemeinsamen Tests lässt sich im Vergleich zur Umsetzung in Einzelprojekten einiges an Synergiepotential heben, alleine schon dadurch dass die aufwändige und fehlerträchtige Abstimmung von parallelen Projekten untereinander entfällt. Ablauf und Verfahren des Releaseprojekts werden immer annähernd gleich sein, von daher wird sich das sequentielle Abfahren dieser Projekte zunehmend „automatisieren“ – aus dem momentan immer wieder neu aufgesetzten „Formatanpassungsprojekt“ kann mit der Zeit ein standardisiertes Verfahren entwickelt werden, dessen steuernde Elemente derart standardisiert und ggf. auch automatisiert werden können, sodass hier eine hohes Potential an Effizienzsteigerung zu erwarten ist.

Für Fortgeschrittene – agile Methoden und optimales Skillmanagement

Hat sich der Ablauf der Releaseprojekte etabliert und standardisiert, kann in dem durch eine entsprechende Effizienzsteigerung erreichten Freiräumen nach weiteren Optimierungspotential gesucht werden.

Auf Basis der in Releases gebündelten Anforderungen und den vorgegebenen Realisierungszeiträumen bietet sich z.B. ein optimaler Boden, die Methodik auf eine agile Vorgehensweise umzustellen (falls dies nicht sowieso schon – häufig unbewusst und informell – der Fall ist). Anforderungen werden vom Beginn her nur rudimentär beschrieben und erst in der Umsetzung gemeinsam zw. Anforderern und Entwicklern sukzessive detailliert. Gemäß der Vorgehensweise in Timeboxen (vorgegeben durch übergeordneten Rahmen des Releasedatums) können Anforderungen sukzessive und in kleinen Paketen ggf. auch über mehrere Releases hinweg umgesetzt werden (insofern keine gesetzlichen Vorgaben in ein bestimmtes Zeitfenster zwingen). Kommunikationswege werden kürzer und die Komplexität der einzelnen Realisierungspakete kann reduziert werden, was in der Regel einen positiven Einfluss auf Termintreue und Qualität haben wird.

Möglicherweise wird anhand der zunehmenden Standardisierung der Releaseprojekte deutlich, dass sich bestimmte Aktivitäten organisatorisch bündeln lassen. So hat sich häufig gezeigt, dass es sinnvoll sein kann die Kompetenzen des Testmanagements in einem dezidierten Bereich auch organisatorisch zu bündeln, um die Testaktivitäten entlang der Releaseplanung (wie auch im Tagesgeschäft z.B. im Zuge von Notfallreparaturen) optimal gemäß der vorhandenen fachlichen Skills der Mitarbeiter anzuordnen. Ähnliches ist auch aus Sicht des Anforderungsmanagements, der Beratung oder der Entwicklung denkbar.

Entscheidend – das Zusammenspiel von Portfolio-, Anforderungs-, Ressourcen- und Releaseplanung

Betrachtet man den Lebenszyklus eines Releases übergreifend von Planung bis zur Produktivsetzung stellt man fest, dass es sich um ein enges Zusammenspiel unterschiedlicher Kompetenzen aus den Bereichen des Anforderungsmanagements, der Portfolioplanung, dem Ressourcenmanagements und nicht zuletzt der übergreifenden Releaseplanung handelt. Sind ein oder mehrere dieser Komponenten in einem Unternehmen gar nicht oder zu gering ausgeprägt, kann dies dazu führen, dass die geschilderten Synergie- und Effizienzsteigerungspotentiale nicht oder nur teilweise gehoben werden können.

Aus dieser Perspektive empfiehlt es sich, die angesprochenen Disziplinen organisatorisch übergreifend anzusiedeln – so ist die strategisch und methodisch stimmige Ausprägung dieser Kompetenzen sichergestellt und aufgrund kurzer Kommunikationswege ergibt sich ein weiteres Potential für eine möglichst effiziente Vorgehensweise. Aufgrund des geschilderten Mehrwerts für das gesamte Management im Unternehmen sowie auch für die Kunden erscheint es erfahrungsgemäß als sinnvoll, diesen Bereich nahe der Geschäftsführung anzusiedeln.

Fazit

Schlussendlich bieten die engen Vorgaben durch den Regulator weniger Anlass zur Beschwerde als vielmehr die Chance, interne Prozesse und Vorgehensweisen effizienter zu gestalten umso zurückkehren zu können zu einer agierenden statt reagierenden Vorgehensweise in der IT für Energieversorgungsunternehmen.

Dieser Beitrag wurde unter Anforderungsmanagement, Energieversorgungsbranche, Projektmanagement, Testmanagement abgelegt und mit , , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

2 Antworten auf IT für Energieversorger – mit Releasemanagement vom Reagieren zum Agieren

  1. Alec Löckmann [360 Watt GmbH] sagt:

    Hallo Herr Günther,
    ein interessanter Ansatz. So habe ich das noch nie gesehen. Letztendlich sicherlich nicht so einfach, alle Projekte auf fixe Termine zu planen (und aufgrund der Verkettung mit zwingenden gesetzlichen Vorgaben), dann auch termingetreu durch zu führen – aber sicherlich wert, das mal weiter als Idee weiter zu verfolgen. Passt auf jeden Fall in das Gesamtkonstrukt projektpunkt. Auf den Punkt gebracht – wie immer.
    Gruß, Ihr Alec Löckmann

  2. Hallo Stefan,

    das ist bei uns gelebte Praxis und klappt gut. Verbesserungspotential gibt es immer, aber dafür sind wir ja da.
    Als nächstes werden wir in das Thema agiles PM einsteigen.

    Viele Grüße
    Andreas

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>