Interkommunale Kooperationen: Wohlüberlegte Architekturmodelle & kooperatives IT-Management

I
Download PDF

Der Kostendruck im IT-Umfeld auf Stadtwerke steigt. Im Juni 2021 haben wir die interkommunale Kooperation als eine mögliche Form der Zusammenarbeit zwischen Stadtwerken vorgestellt, um diesem Druck zu begegnen. Mit der zugrunde liegenden Architektur des gemeinsamen Templates für die IT-Systeme legen die Kooperationspartner den Grundstein für eine erfolgreiche Zusammenarbeit. Die Zusammenarbeit zwischen Management, Fachbereichen und IT ist ein weiterer integraler Bestandteil einer funktionierenden Gesamtlösung.

Erweitertes Architekturmodell (exemplarisch)

(c) BBHC

Klassische IT-Architekturen bestehen grundsätzlich (und in der Regel unabhängig vom Softwarehersteller) aus einem Entwicklungs-, einem Test- und einem Produktivsystem. Die Entwicklungsumgebung ist dabei ständiger Veränderung ausgesetzt, weshalb die IT-Bereiche gemeinsam mit den Fachbereichen auf der Testumgebung mit möglichst sinnvollen und aussagekräftigen Testdaten Funktionalitäten überprüfen müssen.

Ein Template-System stellt häufig die technische Ausgangsbasis in Kooperationen. Um Synergien zu erhalten, müssen Weiterentwicklungen zwischen den Häusern abgestimmt und zentral in die Systeme gebracht werden. Was bei alleiniger Nutzung einer Systemlandschaft noch funktioniert, stößt bei einer Kooperation an technische Grenzen: Bei einer 3-stufigen Architektur sind bei einer zentralen Entwicklung für ein abgestimmtes Release keine anderweitigen Entwicklungen und Anpassungen an den identischen Systembestandteilen mehr möglich. Eine wichtige Korrektur aufgrund eines Fehlers in der Produktivumgebung könnte durch bereits erfolgte Entwicklungen durch einen Kooperationspartner ausgebremst werden.

(c) BBHC

Die architekturelle Erweiterung der 3-stufigen Architektur um ein weiteres Entwicklungs- und Testsystem kann unter anderem dieses Problem lösen. Mit ihm lassen sich die Systeme neben der Umgebung für den produktiven Systembetrieb in eine Release- und Wartungsumgebung unterscheiden, die folgende Eigenschaften aufweisen:

  • Releaseumgebung: Entwicklung und Test von geplanten Weiterentwicklungen des gemeinsamen Templates aufgrund regulatorischer Vorgaben (z.B. regelmäßige Marktformatwechsel), Funktionserweiterungen und -optimierungen.
  • Wartungsumgebung: Entwicklung und Test von kurzfristig erforderlichen Anpassungen am System. Hierbei kann es sich um wichtige Fehlerbehebungen aus dem produktiven Betrieb handeln. Darüber hinaus sind auch Weiterentwicklungen denkbar, die aufgrund der Priorität und Kurzfristigkeit nicht innerhalb eines geplanten Releases umsetzbar sind.

Mit dieser 5-stufigen Architektur können also parallele Entwicklungen und Tests zur Absicherung des Produktivbetriebs sowie zur Weiterentwicklung bzw. Umsetzung von erforderlichen Anpassungen am Template stattfinden. Dieser Sachverhalt entsteht beispielsweise bei Änderungen von Prozessen in der Releaseumgebung, um einen anstehenden Marktformatwechsel vorzubereiten. Obwohl dieser bereits vollständig angepasst wurde, kann der bis zum Stichtag noch aktive Prozess trotzdem unabhängig davon korrigiert werden, indem die Wartungsumgebung verwendet wird. Die Kooperationspartner bleiben voll handlungsfähig, sodass sich der größere Aufwand, der durch die erweiterte Architektur entsteht, frühzeitig amortisiert.

Gemeinsames Anforderungs- und Incidentmanagement

Setzt man dieses Modell ein, kommt es durch die angedeutete parallele Entwicklung zwangsläufig zu Abweichungen der unterschiedlichen Umgebungen. Durch sogenannte Retrofits können die unterschiedlichen Entwicklungsstände der Systeme wieder zusammengeführt werden. Für diesen Vorgang existieren Systeme und Prozesse zum Change Request Management (ChaRM), die weitestgehende Unterstützung und Automatisierung bieten und deren Einsatz daher zu empfehlen ist. Weiterhin können die Anforderungen und Incidents an das gemeinsame Template darüber erfasst, bewertet und zur Umsetzung übergeben werden. Auf diese Weise haben sämtliche Änderungen eindeutigen Bezug zu einem Objekt und machen es damit deutlich einfacher, die Entwicklungstätigkeiten nachzuverfolgen und zu steuern.

Unabhängig von der technischen Unterstützung sollten die Anforderungen an die Systemlandschaft in einer Zusammenarbeit von Management, IT und Fachbereichen innerhalb der Kooperationsunternehmen und anschließend im Dialog innerhalb der Kooperation definiert und priorisiert werden, um eine zukunftsfähige Roadmap zu etablieren.

Die grundsätzliche Ausrichtung der Architektur ist ebenfalls Bestandteil dieser Roadmap. Die zugrunde liegende Architektur des gemeinsamen Templates sollte regelmäßig hinterfragt werden, da Cloud- und vor allem Hybridszenarien bei den Softwareherstellern auf dem Vormarsch sind. Eine frühzeitige Betrachtung der möglichen Modelle sichert die Grundlage der Kooperation für die Zukunft und vermeidet Fehlinvestitionen unter anderem bei Erweiterungen durch Umsysteme aufgrund von Unkenntnis der technologischen Entwicklung. Es wird deutlich: Für eine Roadmap braucht es gemeinsames Commitment.

Chancen verwandeln, Risiken eliminieren

Einer interkommunale Kooperation birgt Chancen und Risiken. Zu den positiven Auswirkungen gehört:

  • Signifikante Senkungen von Kosten durch einen gemeinsamen Kostenteiler bei Weiterentwicklungen und Fehlerbehebungen
  • Verbesserung der Qualität von Prozessen als Ergebnis gemeinsamer Dialoge
  • Zeitersparnisse im Ressourcenmanagement
  • Eintritt in neue Märkte anhand gemeinsamer Planungen und Ideenfindung
  • Gewinnung und Bündelung von Wissen innerhalb der Kooperation

Diesen Potenzialen stehen natürlich auch mögliche Stolpersteine gegenüber:

  • Gegenseitige Einschränkung des Handelns durch eine Inkompatibilität von Zielen; Prozessen und Aktivitäten
  • Steigerung der Fluktuation der Mitarbeiter durch das Aufzeigen neuer Möglichkeiten oder innere Unruhen
  • Neuartige Kosten durch nicht erkannte Fehler des Kooperationspartners, Abstimmungs- und Verwaltungsaufwände
  • Stärkung der Konkurrenz in einem wettbewerbsorientieren Energiemarkt

Wer sich für eine Kooperation interessiert, sollte ausreichend Vorlaufzeit einplanen, um strategische Ziele abgleichen und eine intensive Zusammenarbeit etablieren zu können. Auf diese Weise lassen sich Inkompatibilitäten frühzeitig ausschließen.

Mit einer derartigen Kooperation geht außerdem eine erhöhte Eigenleistung zur Planung, Steuerung und Umsetzung einher. Die jeweilige Personalausstattung muss regelmäßig hinterfragt werden, um einer denkbaren Fluktuation entgegenzuwirken.

Eine mittel- bis langfristige Planung ist ebenfalls deshalb zwingend notwendig, um etwaige Kosten zu kontrollieren und das vereinbarte Vorgehen zwischen den Kooperationspartnern abzustimmen. Eine Kooperation sollte auf Augenhöhe stattfinden, damit sich die Partner nicht als Konkurrenz sehen, sondern die gemeinsamen Vorteile erkennen.

Interkommunale Kooperation in einer „cloudisierten“ Energiewirtschaft

Die dargestellten Ausführungen beschäftigen sich im Wesentlichen mit dem Status-quo bzw. Ansätzen einer Kooperation. Wie bereits angedeutet, unterliegen die Architekturen einem stetigen Fortschritt, den bestehende oder zukünftige Kooperationspartner berücksichtigen müssen.

In einem letzten Beitrag dieser Serie werden wir daher abschließend auf die Frage eingehen, inwiefern eine interkommunale Kooperation in einer zunehmend „cloudisierten“ Energiewirtschaft ein sinnvolles Modell darstellen kann und welche Vorbereitungen getroffen werden sollten.

Ansprechpartner*innen: Dr. Andreas Jankiewicz/

Folgen Sie uns auf Twitter

Kategorien

Archive

BBH Almanach

Materialien für Praktiker im
Energie-, Infrastruktur- und öffentlichem Sektor aus Wirtschaft, Recht und Steuern

Veranstaltungskalender