Aus strategischer und organisatorischer Perspektive müssen sich Energieversorger entscheiden, wie sie die Möglichkeiten von Softwareentwicklung für sich effektiv und effizient nutzen wollen. Dazu gehört zum einen die organisatorische Option, Software selbst (mit) zu gestalten oder sie nur anzuwenden und zum anderen die softwaretechnische Option, entweder eine Standard- oder Individualsoftware einzusetzen bzw. zu entwickeln. Dabei gibt es idealtypische strategische Optionen und Organisationsformen, die den Blick für die Möglichkeiten und Herausforderungen der Digitalisierung schärfen. Sieben Fallstudien zeigen Erfolgsfaktoren industriespezifischer Softwareentwicklung.
Strategische Möglichkeiten: Komplexität vs. Kernkompetenz
Quer zur Arbeitsteilung zwischen Netzen, Lieferanten, Handel, Messstellenbetreibern, Energiedienstleistern und Produzenten von Energien bestimmt die Arbeitsteilung zwischen Softwareanwendung und Softwareentwicklung die Energiewirtschaft. Verspricht die Strategie des "Competing on Complexity" (Bessen 2023) dank selbst entwickelter (komplexer) Software Erfolg? Die Voraussetzung dafür ist, dass sich die Komplexität industriespezifischer Softwareentwicklung meistern lässt. Um die softwaretechnischen Möglichkeiten für die industriespezifischen Bedarfe maximal ausschöpfen zu können, braucht es ein professionelles Team, dass die Methoden der Softwareentwicklung beherrscht.
Solch eine Organisation ist auf die Softwareentwicklung ausgerichtet und optimiert den Anwendungsbereich stetig, sodass dieser nur noch aus jener Arbeit besteht, den Software nicht erledigen kann. Die Arbeit der Anwendenden kann bei Bedarf beliebig und kontinuierlich im Wechselspiel mit der Weiterentwicklung der Software reorganisiert werden.
Eine Variante davon ist, eine proprietäre (Standard-)Software zu entwickeln. Damit ist sowohl eine Differenzierung von Wettbewerbern durch individuelle Softwaregestaltung als auch eine Kommodifizierung für die Teile der Software, die anderen (auch Wettbewerbern) zur Nutzung angeboten werden, möglich.
Eine andere Variante ist die Möglichkeiten einer rein intern entwickelten Software für einen abteilungs- und teamübergreifende Ende-zu-Ende Prozess auszureizen. Die zentrale Hürde dabei ist ein übergreifendes Software- und Prozessgestaltungsteam aufzubauen. Dafür müssen Silos beziehungsweise Hierarchien abgebaut und eine agile Kultur etabliert werden.
"Competing on Core Competencies"
Die meisten Energieversorger konzentrieren sich gemäß der Strategie "Competing on Core Competencies" auf energiewirtschaftliche Kompetenzen:
Sie wenden entweder ein Standardpaket an, sind dann aber dann von der Innovationskraft der Softwarefirma abhängig. Diese wiederum braucht das (Branchen-)Fachwissen und kann nicht auf die individuelle Arbeitskontexte eines Energieversorger eingehen. Oder sie lassen Software via Werkvertrag entwickeln. Dabei müssen sie dann vielfältige Abhängigkeiten managen (unter anderem dass nur die Softwarefirma Wissen über die Umsetzung der individuellen digitalen Prozesse hat).
Natürlich gibt es Mischformen zwischen proprietären Standard, interner Entwicklung, Standardpaket und Werkvertrag. So kann ein Energieversorger die Programmierung Externen auf der eigenen Entwicklungsumgebung überlassen und selbst die Anforderungen definieren. Dadurch wird die Abhängigkeit geringer und es müssen intern keine Programmierkompetenzen aufgebaut werden.
Organisationale Voraussetzungen: die Netzwerkorganisation
Für industriespezifische Softwareentwicklung ist ein interdisziplinärer und kooperativer Arbeitsprozess über mehrere Organisationseinheiten hinweg typisch. Und zwar ob sie nun für die Optimierung eines Ende-zu-Ende-Prozesses genutzt wird oder um ein Standardpaket zu entwickeln. Innerhalb der Energieversorger existiert ein solcher Arbeitsprozess oftmals als Teil einer Matrix-Organisation. Oder er ist zentriert in einer Softwarefirma oder einem IT-Dienstleister, die dann mit Versorgern organisationsübergreifend zusammenarbeiten. Immer handelt sich aber um eine Netzwerkorganisation. Fallstudien zeigen unter anderem folgende Erfolgsfaktoren:
Interne Softwareentwicklung
- Die Idee von Scrum zu leben ist wichtiger als die reine Lehre: Letztendlich geht es darum, den iterativen Arbeitsprozess der Softwaregestaltung situativ zu optimieren (zum Beispiel zusätzlich zu Scrum Master und Product Owner noch mehrere Anforderungsmanagenden und Key User in den Fachbereichen einsetzen, die Feedbackschleifen zwischen Anwendung und Entwicklung durch Workshops oder Resonanzgruppen zu optimieren).
- Interdisziplinäre und kommunikative Profis sind für eine kooperative Zusammenarbeit notwendig: Rollen wie Product Owner brauchen energiewirtschaftliches Know-how, bestenfalls kommen sie aus dem Fach- bzw. Anwendungsbereich der Software und sind zudem methodisch geschult im Anforderungsmanagement, kommunikationsstark und -affin, sprechen sowohl die Sprache der IT als auch der Fachbereiche.
- Für horizontale Abläufe müssen Kommunikationsbarrieren beseitigen werden: Kommunikationshürden wie Abteilungssilos, hierarchische Konflikte oder Widerstände in den Fachabteilungen sind zu überwinden (unter anderem durch offenen Austausch und direkte Kommunikation statt via disziplinarischer Führungskräfte).
- Konfliktfähigkeit ist entscheidend: Bevor der Energieversorger ein Anforderungsmanagement etabliert konnte, mussten Abteilungen Konflikte untereinander beseitigen. Während der Anforderungsrunde moderiert und mediiert der Scrum Master Konflikte.
- Horizontale Strukturen etablieren: Ob durch ein Innovations-Team zwischen IT-Abteilung und Fachbereich, das den Lernprozess was Rollen und Abläufe anbelangt vorantreibt. Oder durch ein föderales Anforderungsmanagement, das aus einer zentralen Anforderungsrunde mehrere Fachbereiche und dezentraler IT-Teams in den Fachbereichen, die Anforderungen aufnehmen, besteht.
Softwareentwicklung eines gemeinsamen IT-Dienstleisters
- Ohne Kooperation keine Synergien: Es ist eine gut organisierte Abstimmung auf strategischer und operativer Ebene notwendig, um immer wieder zu entscheiden, was Teil der Standardlösung wird und was nicht.
- Kooperation erhalten heißt konstant an ihr zu arbeiten: Kooperation zerfallen wegen fehlendem Erwartungs- und Konfliktmanagement. Und weniger wegen fehlender technischer Kompetenz, wirtschaftlicher Planung oder juristischer Absicherung. So gibt es in einem Fall einen Mediator, der Interessenskonflikte zwischen den Energieversorgern professionell bearbeitet und auch auf operativer Ebene findet eine kontinuierliche Arbeit an der Zusammenarbeit selbst statt (zum Beispiel durch die Anforderungsmanager*innen).
- Dynamik zwischen zentral und dezentral zulassen und gestalten: Es gibt keine klare, permanente Zentralisierung oder Dezentralisierung. Manche Energieversorger haben dezentrale Key User, die Anforderungen aufnehmen. Andere Versorger zentrale IT-Anforderungsmanager, wieder andere entwickeln trotz der Kooperation einen bestimmten Teil intern selbst. Auch Koordinative und operative Aufgaben können zwischen IT-DL und Energieversorger über die Jahre hin und her wandern (ob IT-Projektleitung, IT-Koordinierung, Key User und Prozessmanagement).
- Mit Widersprüchen der Marktbeziehung umgehen können: Manche Versorger haben intern wieder Know-how aufgebaut, um Aufwandsschätzungen für Anforderungen des IT-DL hinterfragen zu können. Trotz Misstrauen durch Marktbeziehung müssen die Energieversorger weiterhin eine offene Kommunikation und eine gemeinsame Wissensbasis erhalten.
Zusammenarbeit mit Start-Ups
- Das Start-Up braucht Vermittler in die Energiewirtschaft: Wissen und Zugang zu konkreten Anwendungskontexten sind entscheidend, damit die entwickelte Software auch den Bedarfen entspricht.
- Kooperative Beziehungen sind partnerschaftliche Beziehungen: Die Kooperation kann stark informellen Charakter haben (unter anderem gibt teilweise nur rudimentäre Verträge, die Hierarchien sind flach, das Vertrauen groß und Konflikte werden persönlich gelöst).
- Wissensaustausch gedeiht besonders in persönlichen Beziehungen: Weder Marktmechanismen noch hierarchische Befehlsketten oder Abteilungsgrenzen stellen Hemmnisse dar, um das notwendige Wissen aus dem Anwendungsbereich mit jenem der Programmierung zusammenzubringen.
- Organisationsformen wie Agilität und Holocracy sind voraussetzungsreich:
- Die Mitarbeitenden sind häufig jung, beruflich in dieser Arbeitsweise sozialisiert, haben hohe Kompetenz in den Methoden und/oder sind sehr affin dafür.
- Genuiner Arbeitskontext: Agilität und Holocracy kommen aus der Softwareentwicklung
- Gründer bzw. Führungskräfte wollen es, fördern es, leben es.
Die Fallstudien zeigen, dass es keine Standard-Best-Practise gibt, sondern es vielmehr darum geht, eine lokale Praxis zu etablieren. Dinge wie Kooperationsfähigkeit, offener Wissensaustausch oder Abläufe, die Feedbackschleifen zulassen, sind immer in der jeweiligen Organisation situativ verankert. In diesem Sinne ist industriespezifische Softwareentwicklung immer auch Organisationsentwicklung.
