Formen und Folgen der Softwaregestaltung: Digitale Transformation am Beispiel der deutschen Energiewirtschaft

Sonnenholzner, Johannes Book Formen und Folgen der Softwaregestaltung: Digitale Transformation am Beispiel der deutschen Energiewirtschaft Arbeit und Organisation, No. 19 Provided in Cooperation with: WZB Berlin Social Science Center Suggested Citation: Sonnenholzner, Johannes (2025) : Formen und Folgen der Softwaregestaltung: Digitale Transformation am Beispiel der deutschen Energiewirtschaft, Arbeit und Organisation, No. 19, ISBN 978-3-8394-7688-8, transcript Verlag, Bielefeld, https://doi.org/10.14361/9783839476888 , https://www.transcript-verlag.de/978-3-8376-7688-4/formen-und-folgen-der-softwaregestaltung/ This Version is available at: https://hdl.handle.net/10419/333722 Standard-Nutzungsbedingungen: Die Dokumente auf EconStor dürfen zu eigenen wissenschaftlichen Zwecken und zum Privatgebrauch gespeichert und kopiert werden. Sie dürfen die Dokumente nicht für öffentliche oder kommerzielle Zwecke vervielfältigen, öffentlich ausstellen, öffentlich zugänglich machen, vertreiben oder anderweitig nutzen. Sofern die Verfasser die Dokumente unter Open-Content-Lizenzen (insbesondere CC-Lizenzen) zur Verfügung gestellt haben sollten, gelten abweichend von diesen Nutzungsbedingungen die in der dort genannten Lizenz gewährten Nutzungsrechte. Terms of use: Documents in EconStor may be saved and copied for your personal and scholarly purposes. You are not to copy documents for public or commercial purposes, to exhibit the documents publicly, to make them publicly available on the internet, or to distribute or otherwise use the documents in public. If the documents have been made available under an Open Content Licence (especially Creative Commons Licences), you may exercise further usage rights as specified in the indicated licence. http://creativecommons.org/licenses/by/4.0 Johannes Sonnenholzner Formen und Folgen der Softwaregestaltung Digitale Transformation am Beispiel der deutschen Energiewirtschaft Dissertation zur Erlangung des Grades eines Doktors der Philosophie der Fakultät für Geistes- und Sozialwissenschaften der Helmut-Schmidt-Universität/Universität der Bundeswehr Hamburg vorgelegt von Johannes Sonnenholzner aus Wasserburg am Inn. Hamburg 2024. Erstgutachter: Prof. Dr. Martin Krzywdzinski Zweitgutachterin: Prof. Dr. Katharina Liebsch Die Open-Access-Publikation wurde gefördert durch den Publikationsfonds für Open- Access-Monografien der Leibniz-Gemeinschaft sowie durch Publikationszuschüsse des Wissenschaftszentrums Berlin für Sozialforschung und der Hans-Böckler-Stiftung. Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über https://dnb.dn b.de/ abrufbar. Dieses Werk ist lizenziert unter der Creative Commons Attribution 4.0 Lizenz (BY). Diese Lizenz erlaubt unter Voraussetzung der Namensnennung des Urhebers die Bearbeitung, Vervielfältigung und Verbreitung des Materials in jedem Format oder Medium für beliebige Zwecke, auch kommerziell. (Lizenztext: https://creativecommons.org/licenses/by/4.0/deed.de) Die Bedingungen der Creative-Commons-Lizenz gelten nur für Originalmaterial. Die Wiederverwendung von Material aus anderen Quellen (gekennzeichnet mit Quellenangabe) wie z.B. Schaubilder, Abbildungen, Fotos und Textauszüge erfordert ggf. weitere Nutzungsgenehmigungen durch den jeweiligen Rechteinhaber. 2025 © Johannes Sonnenholzner transcript Verlag | Hermannstraße 26 | D-33602 Bielefeld | [email protected] Umschlaggestaltung: Maria Arndt, Bielefeld Umschlagabbildung: Collage aus Bildern von Pexels/Pixabay und Jason Goodman/ Unsplash Korrektorat: Anette Nagel, CONTEXTA Lektrorat Druck: Elanders Waiblingen GmbH, Waiblingen Print-ISBN: 978-3-8376-7688-4 PDF-ISBN: 978-3-8394-7688-8 Buchreihen-ISSN: 2702-7910 Buchreihen-eISSN: 2703-0326 Gedruckt auf alterungsbeständigem Papier mit chlorfrei gebleichtem Zellstoff. Inhalt Abbildungsverzeichnis .........................................................................9 Tabellenverzeichnis ........................................................................... 11 Abkürzungen ..................................................................................13 Danksagung ...................................................................................15 1. Einleitung: Softwaregestaltung als Kind von Bürokratie und Rationalismus ..............17 2. Untersuchungsgegenstand und Gliederung ...............................................21 2.1. Forschungsgegenstand und -fragen: Formen und Folgen von Softwaregestaltung .............21 2.2. Vorgehen: empirische, qualitativ-explorative Untersuchung der Energiewirtschaft ........... 24 2.3. Zusammenhang von Fragestellung, Technologie, Praxis und Theorie ......................... 26 2.4. Überblick über Kapitel und Argumentation ..................................................31 3. Forschungsdesign und -methode ........................................................ 33 3.1. Methode ................................................................................. 33 3.1.1. Qualitative Sozialforschung: Expert:inneninterviews für Fallstudien .................. 33 3.1.2. Bezug zu Forschungsstand und Theorieentwicklung ................................. 35 3.1.3. Selbst-Positionierung .............................................................. 36 3.2. Forschungsverlauf ........................................................................ 36 3.2.1. Feldzugang und Sampling .......................................................... 36 3.2.2. Ausgangsforschungsfragen und letztendliche Leitfragen ............................ 38 3.2.3. Weiterer Forschungsverlauf und durchgeführte Interviews ........................... 39 3.3. Kodierung, Kategorisierung und Fallvergleich .............................................. 40 3.4. Grenzen der Untersuchung ................................................................ 42 3.5. Forschungsethik und Datenschutz ......................................................... 43 4. Softwaregestaltung als Teil der Digitalisierung Vom Werkzeug der Forschung zum Primat der Softwareentwicklung bei Nicht-IT-Unternehmen ................................................................ 45 4.1. Primat der Softwareentwicklung in Nicht-IT-Branchen und -Betrieben ....................... 45 4.2. Die zwei Kernprobleme der Softwaregestaltung ............................................ 49 4.2.1. Softwaretechnische Interdisziplinarität ............................................. 49 4.2.2. Softwaretechnische Gestaltungsmöglichkeiten .......................................51 5. Softwaregestaltung basiert auf Wissen und Kommunikation .............................57 5.1. Technische Grundlagen: Software als Ergebnis menschlicher Textarbeit ..................... 58 5.1.1. Verarbeiten und verstehen: Arbeitsteilung zwischen Menschen und Maschinen ....... 58 5.1.2. Konkret und abstrakt: mehrere Schichten, sprachliche Strukturierung ............... 60 5.1.3. Zwischen Text und Blackbox: Grenzen der Gestaltung und des Verstehens ............ 62 5.2. Softwareentwicklung: vom einsamen Nerd zum kollektiven Kommunikationsprozess ......... 64 5.2.1. Vom schnellen Reparieren zum iterativen, kollektiven Kommunikationsprozess ....... 65 5.2.2. Kommunikationskompetenz und -kern: Anforderungsmanagement ....................67 5.2.3. Kommunikation und Wissen organisieren: Local Practice statt Best Practice ......... 69 5.3. Zwischenfazit: Softwaregestaltung als soziologisches Problem ............................. 73 6. Softwaregestaltung – konzeptionelle Grundlagen Soziotechnische Netzwerkarbeit und soziotechnische Arbeitsgestaltung zwischen Anwendung und Programmierung .................................................77 6.1. Softwaregestaltung als Arbeitsprozess: Die Lösung des Transformationsproblems durch soziotechnische Netzwerkarbeit .....................................................81 6.2. Weder Markt noch Hierarchie: Netzwerke als analytische Grundlage ........................ 82 6.2.1. Theoretisch: Netzwerke in Abgrenzung zu Markt und Hierarchie ...................... 83 6.2.2. Organisatorisch: Netzwerke aus und in Organisationen .............................. 84 6.2.3. Technisch: digitale Netzwerke ..................................................... 85 6.3. Ein Beispiel für soziotechnische Netzwerkarbeit: IT-Projekte in Matrixorganisationen ........ 86 6.4. Soziotechnische Netzwerkarbeit: die Ebenen Beziehungen, Software und Wissensarbeitende ................................................................... 88 6.4.1. Organisationale und interpersonelle Beziehungen ................................... 89 6.4.2. Software kontrolliert und strukturiert das Netzwerk ................................. 93 6.4.3. Softwaregestaltende: Arbeiten zwischen Anwendung und Programmierung ...........100 6.4.4. Flexibilität bei der Kommunikation und beim Wissensaustausch ......................111 6.5. Folgen der Softwaregestaltung: Soziotechnische Arbeitsgestaltung der Softwareanwendung durch die Softwaregestaltung ............................................................. 112 6.5.1. Softwaregestaltung – eine Form der Rationalisierung der Softwareanwendung? ....... 113 6.5.2. Unterschied zu Informatisierung und Informationsraum ............................. 114 6.5.3. Softwaregestaltung: inkrementell mehr Software in diversen Anwendungsbereichen .. 116 6.5.4. Folgen von Standardsoftware für die Arbeitsgestaltung der Softwareanwendung ...... 117 6.6. Zwischenfazit: Softwaregestaltung als soziotechnische Netzwerkarbeit und soziotechnische Arbeitsgestaltung .................................................... 119 7. Industriespezifische Aspekte der Softwaregestaltung in der Energiewirtschaft .........125 7.1. Industriestrukturen der Energiewirtschaft und ihr Verhältnis zur Digitalisierung .............125 7.1.1. Ansatz der Industrie-Governance ...................................................125 7.1.2. Corporate Governance: Zwischen Daseinsvorsorge und Wettbewerb ..................127 7.1.3. Produktmarkt-Governance: staatliche Regulierung und Digitalisierung ............... 133 7.1.4. Prozess-Governance: Systemstabilität und regulierter Datenaustausch ..............137 7.1.5. Governance industrieller Beziehungen: Betriebsräte und Akademisierung .............140 7.2. Folgen der Industriestrukturen für die Softwareentwicklung ................................143 7.2.1. Digitalisierungsstrategien zwischen Anwendung und Entwicklung ....................143 7.2.2. Wechselspiel von Regulierung und Softwareentwicklung .............................149 7.2.3. Softwaregestaltende: gesteigerte Interdisziplinarität und Intervention Betriebsrat ...152 7.3. Fazit: Software und Softwareentwicklung als Bausteine der Industrie-Governance ...........152 8. Formen und Folgen der Softwaregestaltung – die Empirie Darstellung und Vergleich der Fallstudien ..................................................155 8.1. Einführung: Vorgehen und Kurzvorstellung der sieben Fallstudien ...........................155 8.1.1. Kurzvorstellung der Fallstudien: Wie sie die Kernprobleme der softwaretechnischen Gestaltungsmöglichkeiten und Interdisziplinarität lösen .............................158 8.1.2. Unterschiedliche Möglichkeiten der Softwaregestaltung: zwischen Standard- oder Individualsoftware und Überblick über die Fallstudien ...............................167 8.1.3. Der Analyserahmen ...............................................................169 8.1.4. Was sind große, mittlere und kleine EVU? ........................................... 171 8.2. Soziotechnische Konstellation als Ausgangssituation der Softwaregestaltung ...............172 8.2.1. Darstellung der Fallstudien ........................................................172 8.2.2. Zusammenfassung ................................................................ 181 8.3. Formen des soziotechnischen Arbeitsprozesses der Softwaregestaltung ....................187 8.3.1. Arbeitsprozess der Softwaregestaltung: zwischen zentral und dezentral ..............187 8.3.2. Darstellung der Fallstudien .........................................................189 8.3.3. Zusammenfassung ............................................................... 226 8.4. Folgen für die Arbeit der Beschäftigtengruppe der Softwaregestaltenden .................. 236 8.4.1. Softwaregestaltende: zwischen Matrix- und reiner Netzwerkorganisation ............ 237 8.4.2. Darstellung der Fallstudien ....................................................... 238 8.4.3. Zusammenfassung ................................................................251 8.5. Folgen für die soziotechnische Arbeitsgestaltung der Softwareanwendung in den EVU .......261 8.5.1. Soziotechnische Arbeitsgestaltung: zwischen Abhängigkeit und Unabhängigkeit ..... 262 8.5.2. Darstellung der Fallstudien ....................................................... 264 8.5.3. Zusammenfassung ............................................................... 279 8.6. Synthese, Zusammenfassung und Diskussion des Fallvergleichs ........................... 287 8.6.1. Synthese: Typen soziotechnischer Netzwerkarbeit und soziotechnischer Arbeitsgestaltung ........................................... 288 8.6.2. Zusammenfassung je Teil des Analyserahmens .................................... 295 8.6.3. Synthese: Rationalisierungstyp der technikentwicklungsbezogenen Rationalisierung ................................................................. 307 8.6.4. Neue Konkurrenz für das Management durch die Softwaregestaltenden? .............310 8.6.5. Facetten einer industriespezifischen Softwaregestaltung ...........................312 9. Ziel der Untersuchung, wesentliche Befunde und weiterführende Fragestellungen ......315 9.1. Softwaregestaltung: ein wenig erforschter Arbeitsprozess der Digitalisierung ...............315 9.2. Erster Debattenbeitrag: Softwaregestaltung als soziotechnische Netzwerkarbeit ............317 9.2.1. Typische Unterschiede in der soziotechnischen Netzwerkarbeit .....................319 9.2.2. Gemeinsame Kategorien der soziotechnischen Netzwerkarbeit ..................... 320 9.2.3. Beitrag zur Debatte über die Kontrolle von Wissensarbeit ........................... 325 9.3. Zweiter Debattenbeitrag: Softwaregestaltung als Arbeit an der digitalen Transformation .... 330 9.3.1. Teil der digitalen Transformation: soziotechnische Arbeitsgestaltung der Softwareanwendung durch die Softwaregestaltung ............................. 330 9.3.2. Zwischen unabhängiger und abhängiger soziotechnischer Arbeitsgestaltung .........331 9.3.3. Beitrag zur Debatte über die digitale Transformation .............................. 332 9.4. Methodische Grenzen und weiterführende Fragestellungen ................................ 343 Literatur .................................................................................... 347 Anhang ...................................................................................... 367 Übersicht Interviews .......................................................................... 367 Leitfaden für Interviews ...................................................................... 369 Abbildungsverzeichnis Abbildung 1: Drei Arbeitsprozesse digitaler Arbeit ........................................... 22 Abbildung 2: Konvergenz zweier Branchen? ................................................. 26 Abbildung 3: Analyserahmen für die Darstellung und den Vergleich der Fallstudien ............ 29 Abbildung 4: Übersicht über Kernbestandteile der Untersuchung ............................ 30 Abbildung 5: Übersicht Fallstudien ......................................................... 37 Abbildung 6: Vier Forschungsbereiche, die konzeptionelle Bezüge für soziotechnische Netzwerkarbeit zwischen Anwendung und Programmierung liefern sollen, und zugleich die vier Ebenen, auf denen die Kontrolle zur Transformation der Arbeitskraft bei soziotechnischer Netzwerkarbeit basiert. ...................... 80 Abbildung 7: Anzahl Elektrizitätsunternehmen 2018 ......................................... 131 Abbildung 8: Kooperationsgrad und -häufigkeit je Wertschöpfungsbereich ...................139 Abbildung 9: Kooperationsgrad nach Wertschöpfungsbereich und Unternehmensgröße .......140 Abbildung 10: Vorher (1995) und nachher (2005) bei den industriespezifischen Softwarepaketen der EVU ......................................................................144 Abbildung 11: Analyserahmen für die Formen und Folgen der Softwaregestaltung – soziotechnische Netzwerkarbeit und soziotechnische Arbeitsgestaltung ......... 171 Abbildung 12: Schema einer auf Softwaregestaltung ausgerichteten softwaretechnischen Prozessorganisation ......................................................... 286 Abbildung 13: Matrix Arbeitsprozess (dezentral – zentral) und Arbeitsbedingungen der Softwaregestaltenden (Matrixorganisation – reine Netzwerkorganisation) und die vier Idealtypen der soziotechnischen Netzwerkarbeit .......................... 289 Abbildung 14: Matrix softwaretechnischer Zuschnitt (Standard – individuell) und organisatorische Ausrichtung (Anwendung – Entwicklung) und die vier Idealtypen der soziotechnischen Arbeitsgestaltung (als Verhältnis von Softwaregestaltung zu -anwendung) ............................................................. 292 1. Einleitung: Softwaregestaltung als Kind vonBürokratieundRationalismus »Die [Software] ist ›rationalen‹ Charakters: Regel, Zweck, Mittel, ›sachliche‹ Unpersönlichkeit beherrschen ihr Gebaren. Ihre Entstehung und Ausbreitung hat daher überall in jenem besonderen, noch zu besprechenden Sinne ›revolutionär‹ gewirkt, wie dies der Vormarsch des Rationalismus überhaupt auf allen Gebieten zu tun pflegt. Sie vernichtet dabei Strukturformen der Herrschaft, welche einen, in diesem Sinn, rationalen Charakter nicht hatten.« (Weber 1980: 578f.) In diesem manipulierten Zitat aus Max Webers »Wirtschaft und Gesellschaft« von 1921/22 steht »Software« anstelle von Webers Begriff »Bürokratie«. Denn wie die Bürokratie erfüllt auch Software die Forderung nach einer »beschleunigten, dabei präzisen, eindeutigen, kontinuierlichen Erledigung von Amtsgeschäften« (Weber 1980: 562). Sie agiert »entmenschlicht« (ebd.): leidenschaftslos, berechnend; ignoriert alle »irrationalen, dem Kalkül sich entziehenden Empfindungselemente aus der Erledigung der Amtsgeschäfte« (ebd.). Sie ist – wie die »lebende Maschine« (Weber 1988: 835) der Bürokratie und die »leblose Maschine« (ebd.) in der Fabrik – »geronnener Geist« (ebd.). Die Bürokratie wird hier zum Vergleich herangezogen, weil Weber sie als Trägerin des Rationalismus sieht. In ebendiesem Sinne erledigen heutzutage Software einsetzende Organisationen Aufgaben effizienter als eine rein auf Mitarbeitenden basierende Organisation. Aus rein menschlichen Apparaten sind soziotechnische Organisationen geworden. Sie verdrängen Organisationen, welche die universelle Maschine Computer weniger effizient zu nutzen wissen. So ergibt sich eine intensivierte Rationalisierung, bei der nicht mehr allein die Leistung des Menschen im Fokus steht, sondern die jeweils effizienteste Software für die Datenverarbeitung oder – je nach Industrie – die effizienteste Kombination aus Mensch, digitaler und mechanischer Maschine. Die Bürokratie dient als Einstieg, weil sie im Zeitalter der Software weiterhin eine Rolle spielt. Es braucht immer noch eine Organisation von Mitarbeitenden, es braucht menschliche Arbeitskraft – ob Software anwendend oder entwickelnd. Für Weber (vgl. Weber 1980: 125f.) ist die Bürokratie eine Organisation u.a. mit entsprechendem Personal (dazugehöriger Persönlichkeitsstruktur und entsprechendem Fachwissen) sowie 18 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung definierten Aufgabenbereichen und Arbeitsweisen (Arbeiten nach Regeln, aktenmäßige bzw. schriftliche Aufgabenerfüllung). Die im Folgenden untersuchten Organisationen aus der Energiewirtschaft unterscheiden sich von der Bürokratie bei Weber natürlich insofern, als Software bei Weber noch gar keine Rolle gespielt hat. Manche dieser Organisationen wenden Software nicht nur an. Sie entwickeln selbst Software oder sind zumindest Teil jener Phase der Softwareentwicklung, in der den Programmierenden gesagt wird, was die gestaltete Software können soll. Diese Phase bezeichnet die vorliegende Untersuchung als Softwaregestaltung. Um Software gestalten zu können, muss es eine interdisziplinäre Zusammenarbeit zwischen Fachleuten der energiewirtschaftlichen Anwendungsbereiche und der Softwareentwicklung geben. Es geht immer um dieselbe Frage: Was sind die branchenspezifischen Bedarfe und wie können dafür die softwaretechnischen Möglichkeiten genutzt werden? Es gilt, das jeweils (zu spezifizierende) Nützliche für einen branchenspezifischen Anwendungsbereich zu programmieren. Diese Arbeit zwischen Anwendung und Programmierung braucht – wie die Bürokratie bei Weber – Personal, Wissen, Aufgabenverteilung und Regeln, nach denen gearbeitet wird. Die Betriebe müssen sie organisieren. Anders als bei Weber wiederum ist das, was sich zwischen Softwareanwendung und -programmierung abspielt, ein wichtiges Rationalisierungsfeld. Das zeigt sich z.B. in strategischen Fragen wie jener, ob Firmen Wettbewerbsvorteile durch eine individuell gestaltete oder durch eine Standardsoftware gewinnen können. In der hier untersuchten Energiewirtschaft gibt es zum einen Organisationen, die eine Standardsoftware einsetzen, an die sie sich anpassen müssen. Für solche Softwarelösungen existieren selbst für industriespezifische Prozesse wie die Erstellung von Strom- und Gasrechnungen oder den Handel mit Energie mehrere softwareanbietende Unternehmen. Zum anderen existieren Organisationen, die eigens eine individuelle Software gestalten. So zum Beispiel in der Netzinstandhaltung, um regionale Besonderheiten oder spezifische Gefahrenlagen von Monteur:innen zu berücksichtigen. Die sieben Fallstudien der vorliegenden Untersuchung liegen zwischen diesen Polen: Energieversorgungsunternehmen (EVU), die sich auf eine industriespezifische Standardsoftware verlassen und diese höchstens noch einstellen, aber selbst gar nicht programmieren. EVU, die eine Standardsoftware mit eigenen Programmierern erweitern, oder solche, die dies in Kooperation mit anderen EVU tun. Untersucht wurde auch ein energiewirtschaftliches Start-up, das von Anfang an darauf ausgerichtet ist, eine eigene, individuelle Software für seine Dienstleistung zu entwickeln und Teile davon als Standardlösung anderen Organisationen zu verkaufen. So bewegen sich die Fallstudien zwischen rein anwendenden EVU und solchen, die letztendlich Softwareentwicklungsfirmen sind – auch wenn sie ihr Geld nicht primär mit dem Verkauf von Software, sondern in der Wertschöpfungskette der Energiewirtschaft verdienen. Mit den sieben Fallbeispielen aus der Energiewirtschaft zeigt die Untersuchung, wie industriespezifische Softwaregestaltung in verschiedenen Konstellationen aussieht und was sie voneinander unterscheidet. Die Branche eignet sich für diese Fragestellung besonders gut, weil sich durch Energiewende und Liberalisierung viel verändert hat und immer noch verändert und weil die Energiewirtschaft einer starken Regulierung unterworfen ist, wofür Firmen »Paragraphen-Automaten« (Weber 1988: 322) in Form von 1. Einleitung: Softwaregestaltung als Kind vonBürokratieundRationalismus 19 (Standard-)Software entwickeln. Es gibt sowohl Organisationen in öffentlicher als auch in privater Hand und aufgrund der vielen EVU einen großen Markt für industriespezifische Softwarelösungen. Eine Organisation ganz ohne Software gibt es auch in der Energiewirtschaft schon lange nicht mehr. Solche softwarebasierten Organisationen und die Softwaregestaltung selbst lassen sich nicht mehr mit dem Bürokratie-Konzept von Weber beschreiben. Deshalb erarbeitet die Untersuchung neue Begriffe und Konzepte unabhängig von Weber. 2. Untersuchungsgegenstand und Gliederung Wie bereits die ersten Seiten zeigen, bewegt sich die vorliegende Untersuchung zwischen allgemeinen, abstrakteren Begriffen und der konkreten Empirie der Energiewirtschaft. Es geht um beides. Zum einen um eine allgemeine Problemstellung, die alle Industrien betrifft: industriespezifische Softwaregestaltung und welche Konzepte nützlich sind, um diese zu analysieren. Zum anderen um konkrete, industriespezifische Anwendungsbereiche von Software in der Energiewirtschaft, wie die Firmen der Branche Software gestalten und was die Besonderheiten der Branche sind, die sich in der Softwaregestaltung niederschlagen. Sowohl allgemeine als auch spezifisch energiewirtschaftliche Softwaregestaltung sind Forschungslücken und Gegenstand der Untersuchung. 2.1. Forschungsgegenstand und -fragen: Formen und Folgen vonSoftwaregestaltung Ganz allgemein ist eine zentrale Eigenschaft von Computern, dass sie als universale Maschine programmiert werden können (und müssen). Alles Mögliche kann als Quellcode entwickelt werden: kleine Apps für Smartphones, Standardpakete zur Textverarbeitung, Programme für den automatisierten Börsenhandel oder Steuerungsprogramme für Atomkraftwerke. Die Folgen der Anwendung von Software auf Arbeit sind vielfältig untersucht (meist in Verbindung mit einer jeweils spezifischen Hardware): ob zu den Softwarelösungen der Gig-Ökonomie (vgl. Wood et al. 2019, Wu et al. 2019), Crowdworking (vgl. Gerber/Krzywdzinski 2019), ERP-Systemen (vgl. Hohlmann 2007, Walker 2016, Howcroft/Richardson 2012) oder in Call-Centern (vgl. Longen 2015). Auch zur Organisation von Softwareentwicklung bzw. der Arbeit der Programmierenden gibt es viel Forschung (vgl. Friedman/Cornford 1993, Barett 2005, Upadhya 2009, Feuerstein 2013). Beide Forschungsbereiche der Digitalisierung sind in Abbildung 1 schematisch dargestellt: der Arbeitsprozess der Anwendung einer Software (A) und jener ihrer Programmierung (C). Die vorliegende Arbeit untersucht (B), die Arbeit zwischen Anwendung und Programmierung und wie sie organisiert ist. Der Arbeitsprozess heißt Softwaregestaltung. Wie bereits in der Einleitung angesprochen, erfahren hier die Programmie- 22 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung renden, was zu programmieren ist. Diese drei in Abbildung 1 dargestellten Perspektiven auf die Digitalisierung sollten – so die These dieser Arbeit – voneinander unterschieden werden. Abbildung 1: Drei Arbeitsprozesse digitaler Arbeit Softwaregestaltung ist die Phase der Konzeption (bzw. Spezifikation oder Anforderungsaufnahme) der Softwareentwicklung. Abhängig vom Fall spielt dabei auch die Phase der Tests eine Rolle, weil in dieser die Anwendenden bzw. Testenden durch ihre Rückmeldungen Input für die Gestaltung geben. Fragen der Bedienoberfläche (Design) oder der Architektur, die Teil der Gestaltung von Software sein können, gehören hier nicht zum Kern des Arbeitsprozesses. Die Softwarearchitektur ist meist eine bereits entschiedene Ausgangsbedingung: z.B. welche Schnittstellen vorhanden sind, welche Einstellungsmöglichkeiten eine Software hat oder welche Erweiterungsmöglichkeiten eine Standardsoftware bietet. Das Software-Design in Sinne von z.B. anwendungsfreundlichen Oberflächen ist in den untersuchten Fallstudien kein gesonderter Arbeitsschritt mit den entsprechenden Spezialist:innen dafür. Damit steht für die hier vorliegende Untersuchung im Mittelpunkt, dass Software eine gestaltungsoffene Technologie ist, die je nach Umsetzung bspw. zu Formalisierung, Standardisierung, Überwachung oder Automatisierung führt. Das heißt, das Rationalisierungsziel des Softwareeinsatzes ist nicht per se die Formalisierung oder die Sammlung möglichst vieler Daten. Vielmehr geht es darum, für einen Anwendungsbereich die Entwicklungsmöglichkeiten der Technologie auszureizen. Eine besondere Relevanz hat der Arbeitsprozess zwischen Anwendung und Programmierung bei industriespezifischer Software. Anders als bspw. bei Standardsoftwarepaketen wie LibreOffice oder MS Office ist der Wissenstransfer zwischen Industriefachleuten entscheidend. Organisationen überprüfen regelmäßig Entscheidungen über Make- or-Buy und müssen die Softwarelösungen kontinuierlich anpassen, weil sich die Regulierungen durch den Staat ändern oder um sich im Wettbewerb zu behaupten. Die Forschungsarbeit zeigt, dass der Ablauf industriespezifischer Softwaregestaltung ein eigenständiger, zentraler Arbeitsprozess der Digitalisierung ist und die Arbeit von Beschäftigten der jeweiligen Industrie (hier: der Energiewirtschaft) prägt. Die These ist, dass 2. Untersuchungsgegenstand und Gliederung 23 für das Verständnis von heutiger Erwerbsarbeit das Verständnis der Softwaregestaltung neben anderen Einflüssen relevant ist: ob Finanzmärkte und der Shareholder Value (vgl. Windolf 2005, Vitols 2002, Dörre 2001, Höpner, 2003), der Position in der Wertschöpfungskette (vgl. Gereffi et al. 2005, Flecker/Meil, 2010, Mezihorak 2018), bestimmte Management- oder Organisationspraktiken (vgl. Gerst 2006, Boes et al. 2018) oder Produktionsmodelle (vgl. Kern/Schumann 1984, Herrigel 2010). Die Softwareentwicklung als Ganzes ist Teil jeder Branche geworden. Jedes Unternehmen muss sich fragen, auf welcher Seite der Wissensgrenze zwischen Anwendung und Entwicklung es steht und an welchen Phasen des Entwicklungsprozesses – bestehend aus Spezifikation/Konzeption, Programmierung, Test, Support und Betrieb – es beteiligt sein will. Gleichzeitig ist für einen großen Teil der Nicht-Softwareunter- nehmen und ihrer industriespezifischen Fachabteilungen die Softwareentwicklung mit ihren Werkzeugen und Methoden zunächst einmal etwas Fremdes. Wie die Fallstudien zeigen werden, bedeutet branchenspezifische Software zu entwickeln eine Abkehr von der Fixierung auf eine nach Abteilungen gegliederte hierarchische Organisation und rein marktbasierte Beziehungen zu IT-Zulieferern wie IT-Dienstleistungsunternehmen (IT-DL) oder Softwarefirmen. Intern müssen Teams und Abteilungen (bspw. durch IT-Projekte) und extern unterschiedliche Organisationen kooperieren (bspw. bei der Zusammenarbeit mit Start-ups). Wenn gefragt wird: »Welche Ebene ist bestimmend für die Arbeit unter Bedingungen der Informatisierung: der Betrieb, das Unternehmen, das Projekt, das Netzwerk?« (Baukrowitz 2006: 82), so ist hier die Antwort: keine Ebene alleine, sondern die Softwaregestaltung, die sich über mehrere Ebenen erstrecken kann. Es geht um die Konstellationen, in denen angewendete Software entsteht und welche Folgen das für die Anwendung hat: ob sie eine Softwarefirma entwickelt, ein eigenes Team an Programmierenden, eine Kooperation mehrerer Firmen; ob ein EVU eine Standardsoftware einsetzt, anpasst oder eine individuelle Lösung gestaltet. Es stehen zwei Kernfragen im Mittelpunkt der Analyse industriespezifischer Softwaregestaltung: 1. Kontrolle der Softwaregestaltung • Wie kontrollieren Organisationen in unterschiedlichen Konstellationen den Arbeitsprozess der Softwaregestaltung? (Formen) • Welche Auswirkungen hat die jeweilige Konstellation und Form der Softwaregestaltung für die Arbeit der Softwaregestaltenden? (Folgen) 2. Verhältnis zur Softwareanwendung • Welche Auswirkungen hat die jeweilige Konstellation und Form der Softwaregestaltung für die Arbeitsgestaltung der Softwareanwendung? (Folgen) Analytisch gesehen müssen, um die beiden Fragen nach den Formen und den Folgen untersuchen zu können, a) Technikgestaltung, b) Arbeitsgestaltung und c) der Kontext beider gemeinsam untersucht werden. Die reine Anwendung der Software ist nur insofern relevant, als sie diese Zusammenhänge erhellt. Das Methodenkapitel stellt unter 3.2.2 die zu den Kernfragen gehörenden Leitfragen für die Expert:inneninterviews vor. 24 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung Softwaregestaltung ist dabei weder primär eine Form von Innovation noch Teil einer Reorganisation. Auch wenn Softwaregestaltung innovativ im Sinn von ›etwas Neues machen‹ ist, so liegt doch der Fokus auf den Gemeinsamkeiten mit anderen Arbeitsprozessen. In der Praxis nehmen Beschäftigte den Bereich nicht als gesonderten Innovationsbereich wahr: Programmierende, Anforderungsmanagende oder IT-Projektleitende sind in den untersuchten Fällen nicht allesamt in einer Innovations- oder F&E-Abteilung angesiedelt (höchstens einzelne Beteiligte). Auch wenn Softwaregestaltung mit organisatorischen Veränderungen einhergehen kann, ist dies in den untersuchten Fällen nicht der primäre Zweck der Software. Genauso wenig wie Innovationen nicht das primäre Ziel sind und in den untersuchten Fällen die Softwaregestaltung nicht per se als »innovativ« gilt – eher die verwendeten Methoden wie z.B. Scrum. Software ist eine schlichte Notwendigkeit, um das Tagesgeschäft (auch in Zukunft) effizient zu bewältigen. Die analytische Perspektive auf den Arbeitsprozess fokussiert die Frage, womit Firmen und ihre Beschäftigten konfrontiert sind, wenn sie Software gestalten. Einerseits will das Management die Effizienz steigern, andererseits müssen sich Beschäftigte auf neue Methoden wie Scrum einlassen und unterschiedliche Abteilungen und Organisationen miteinander kooperieren. Untersuchungsgegenstand sind dabei einzelne Gestaltungsprozesse von Software(paketen) und nicht eine gesamte IT-Landschaft (aus einer Vielzahl an Softwarepaketen). Zudem geht es beim Arbeitsprozess um die kleinen, iterativen Schritte, zu denen regelmäßige Treffen gehören, um Anforderungen aufzunehmen, oder auch darum, den Anwendenden regelmäßige Updates der Software zur Verfügung zu stellen. Das Ziel ist, die Unterschiede und Gemeinsamkeiten der Formen der Softwaregestaltung in den unterschiedlichen Fallstudien inklusive der jeweiligen Folgen herauszuarbeiten. 2.2. Vorgehen: empirische, qualitativ-explorative Untersuchung derEnergiewirtschaft Die oben genannten Fragen werden qualitativ-explorativ erforscht (Näheres dazu im Methodenkapitel). Als empirischer Gegenstand fungiert die Energiewirtschaft und die dort betriebene industriespezifische Softwaregestaltung. Diese Branche ist nicht nur deshalb von Interesse, weil sie in der Soziologie kaum erforscht ist, sondern auch wegen ihrer jüngeren Liberalisierungsgeschichte, ihrer regulierten und unregulierten Bereiche: Die Fallstudien zeigen, dass das Folgen für die Softwaregestaltung hat, denn z.B. ist es im regulierten Netzbereich für die Unternehmen einfacher, sich auf einen Standard zu einigen. Im unregulierten Bereich der Energielieferung, in dem Wettbewerb herrscht, gestalten EVU häufiger individuelle Software, z.B. um ihrer Kundschaft besondere Angebote machen zu können. Durch die vielen und vielfältigen privaten, öffentlichen, großen und kleinen Unternehmen in der Energiewirtschaft gibt es einerseits einen großen Markt für Standardsoftware und andererseits Möglichkeiten der Kooperation zwischen den EVU. Da der Energiesektor insgesamt nicht zu den Vorreitern der Digitalisierung gehört, prallen digital natives und digital immigrants besonders heftig und ersichtlich aufeinander. Software innerhalb der EVU zu gestalten, ist in so einer Konstellation eine be- 2. Untersuchungsgegenstand und Gliederung 25 sondere Herausforderung. Zuletzt dient die Energiewirtschaft als Untersuchungsfeld, weil der Verfasser selbst als IT-Berater in der Branche tätig war. Die vielfältigen und komplexen Anwendungsbereiche von Software in dieser Branche stellen eine Herausforderung für die Softwaregestaltung dar. Umfangreiche Wissensbestände müssen in Software übersetzt werden. • Sei es technisches Wissen über Kraftwerke oder Netze: um sie zu steuern, zu überwachen oder zu warten. Will ein EVU bspw. seine Netz-Monteur:innen mit mobilen Apps und Drohnen ausstatten, ist ein intensiver Wissensaustausch mit ihnen über deren Arbeitsweise und die technischen Spezifika der Netzwartung notwendig, damit die Programmierenden wissen, was sie zu tun haben. • Sei es regulatorisches Wissen über Gesetze und Verordnungen, welche den automatisierten Datenaustausch zwischen den Marktteilnehmenden regeln, damit bspw. die Stromkundschaft einfach per Internet das stromanbietende Unternehmen wechseln kann. Jede:r kann einen Blick auf die eigene Stromrechnung werfen, um zu sehen, was dort alles an Daten stehen muss: Abgaben, Umlagen, Steuern, technische Angaben, der Strommix etc. Oder jene Gesetze und Verordnung, welche regeln, wie Erneuerbare-Energie-Anlagen abgerechnet werden. Da kann es sein, dass Jurist:innen bei der Softwaregestaltung mitarbeiten, damit die Software auch das Richtige macht und nichts falsch abrechnet. • Sei es die Regulierung zu neuen Themen wie dem Emissionshandel, der in Software übersetzt werden muss, damit ihn die Branche effizient betrieben kann. • Sei es letztendlich Wissen über Marketing, Kund:innenservice oder Rechnungsstellung, die, auch wenn sie in anderen Branchen existieren, ihre Industriespezifika haben und für die deswegen eigene Softwarelösungen entwickelt oder zumindest Standardsoftwarepakete angepasst werden müssen. Empirisch ist der Arbeitsprozess der Softwaregestaltung ein Teil der Konvergenz zweier Industrien. Es treffen zwei Wertschöpfungsketten aufeinander (Software- und Energiewirtschaft), die sich verschränken und meist auf verschiedene Organisationen verteilt sind. In Abbildung 2 sind die beiden Wertschöpfungsketten dargestellt. Jene der Energiewirtschaft setzt sich aus Energieerzeugung, Handel, Verteilung via (Strom-/Gas-)Netze und Vertrieb zusammen. In der Softwarewirtschaft besteht sie aus der Spezifikation, der Programmierung, den Tests, der Implementierung, Wartung, dem Betrieb bis zum Vertrieb von Software. Beide Wertschöpfungsketten arbeiten an bzw. mit der Anwendungssoftware. Aus Sicht der Energiewirtschaft ist Software zentral für die Datenhaltung, -verarbeitung und die Leistungserbringung. Dazu gehören Transaktionen zwischen Firmen und Kundschaft (B2C, Business to Customer) wie auch zwischen Firmen (B2B, Business to Business). In der Energiewirtschaft ist das zu einem großen Teil mit einem hohen Grad an Automatisierung verbunden, weil die vielen unterschiedlichen Marktteilnehmenden viele Massendaten (Strommengen, Geldbeträge etc.) untereinander austauschen müssen. Kapitel 7 geht näher auf die industriespezifischen Aspekte der Softwaregestaltung ein. Es reflektiert die Bedeutung der Industriestrukturen für die Softwaregestaltung und gibt Hintergrundwissen zum besseren Verständnis der Fallstudien. 26 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung Abbildung 2: Konvergenz zweier Branchen? Die Fallstudien beleuchten verschiedene Konstellationen der Softwaregestaltung und vergleichen sie anschließend (kooperativ-firmenübergreifend, intern, durch Softwarefirmen, in einem Start-up etc.). Die Firmen sind jeweils auf unterschiedliche Weise Teil der Wertschöpfung der Softwarewirtschaft und tragen jeweils unterschiedlich zur Softwaregestaltung bei. 2.3. Zusammenhang von Fragestellung, Technologie, Praxis und Theorie In dem qualitativen Forschungsprozess haben sich aus einem iterativen Prozess der Reflexion von Theorie und Empirie erst im Laufe der Zeit die Kernfragen, zentralen Probleme der Praxis, konzeptionelle Ausrichtung und theoretischen Einsichten ergeben. Ausgehend von der Fragestellung zu den Formen und Folgen des Arbeitsprozesses der industriespezifischen Softwaregestaltung ergeben sich die relevanten technologischen Grundlagen: der Quelltext, die unterschiedlichen technischen Schichten und sprachlichen Strukturierungen, mit denen die Beteiligten auf Software blicken, worauf sie sich in ihrer Arbeit beziehen und welche sie für die Kommunikation nutzen (Quelltext, Bedienoberfläche, Einstellungsmöglichkeiten, Schnittstellen, Modelle, Algorithmen etc.). Fragestellung und Technologie werfen in der Empirie bzw. den Fallstudien den Blick auf zentrale Mittel der Arbeitspraxis der Softwaregestaltung und typische Probleme. Sowohl die Software selbst als auch ihr Anwendungsbereich kann sehr komplex sein und die Beteiligten müssen sich trotzdem auf eine Gestaltung einigen, weswegen Wissen und Kommunikation untereinander die zentralen Arbeitsmittel sind. Als typische praktische Kernprobleme für den Arbeitsprozess der Softwaregestaltung hat die empirische Analyse die softwaretechnische Interdisziplinarität und die softwaretechnischen Gestaltungsmöglichkeiten identifiziert. Die Fallstudien sind unterschiedliche Beispiele dafür, wie Organisationen diese beiden Probleme lösen. Allgemein stellen sich beide Probleme unabhängig vom Kontext – egal ob ein Start-up oder ein seit Jahrzehnten existierender Industriekonzern Software gestaltet. Für die softwaretechnische Interdisziplinarität müssen die Agierenden das Wissen über die Potenziale der Softwaregestaltung mit dem Wissen über die fachlichen Bedarfe zusammenbringen. Erst der Dialog der Wissensdomänen (IT und Energiewirtschaft) schöpft die Möglichkeiten der Softwareentwicklung aus und überwindet Wissensgrenzen. Rol- 3. Forschungsdesign und -methode 3.1. Methode 3.1.1. Qualitative Sozialforschung: Expert:inneninterviews für Fallstudien Die Forschungsfrage an sich ist bis auf einzelne Themen in der Soziologie (Energiewirtschaft, organisationsübergreifende Arbeitsprozesse, Softwaregestaltung) noch nicht untersucht worden und auch im Zusammenspiel nur spärlich erforscht. Daher hat die Untersuchung einen qualitativ-explorativen Ansatz gewählt. Die Teilbereiche der Arbeits-, Organisations- und Techniksoziologie sollen zusammen betrachtet und die dafür notwendigen Begrifflichkeiten entwickelt werden. Der qualitative Ansatz erlaubt es, mit der notwendigen Offenheit an die Fragen heranzugehen und dabei zugleich die unterschiedlichen, bereits existierenden Erkenntnisse zu berücksichtigen. Wie in qualitativen Untersuchungen üblich, wird die Komplexität erst später im Forschungsprozess reduziert, was eine sehr umfassende Betrachtung des Feldes ermöglicht. Drei Verfahren wurden angewendet, nämlich Fallstudien, Expert:inneninterviews und Grounded Theory. Das Expert:inneninterview bietet zwei Vorteile, indem es Themen bündelt und Daten evoziert. Im Austausch während des Gesprächs kann der Verfasser seinen eigenen Expertenstatus als ehemaliger Softwareprogrammierer und IT-Berater fruchtbar machen. Die Grounded Theory bietet sich besonders in Bereichen an, zu denen bisher wenig Forschung durchgeführt wurde – eines der Merkmale des hier aufgespannten Feldes. Fallstudien erlauben es, Einzelfälle in ihrer Komplexität zu untersuchen. Dazu gehört der Kontext über die befragten Individuen hinaus inklusi- ve der Branche. Die Expert:inneninterviews wurden entsprechend der inhaltlichen Ausrichtung der Arbeit als Untersuchungsmethode gewählt. Es geht dabei nicht um »die Gesamtperson […], d.h. die Person mit ihren Orientierungen und Einstellungen im Kontext des individuellen oder kollektiven Lebenszusammenhangs« (Meuser/Nagel 2002: 71). Nicht Biografie oder Deutungsmuster eines Individuums sind im Fokus, sondern die Handlungen von Menschen in einem konkreten Arbeitskontext, also deren »Kenntnisse über Sachverhalte und […] Einschätzungen« (Klemm/Liebold 2017: 309). Der Expert:innenstatus entspricht einer Rolle, die jede Person einnimmt, wenn sie ihrer Arbeit 34 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung nachgeht. Es geht um fachspezifisches Wissen bzw. »Betriebswissen« (Meuser/Nagel 2002). Auch Sachbearbeitende sind in ihrem Feld und für ihre Firma Spezialist:innen bzw. Fachmenschen und gelten im Sinne dieser Arbeit als Expert:innen. Expert:inneninterviews komplementieren zudem Fallstudien, weil die Vergleichbarkeit der Interviews gewährleistet wird durch den »geteilte[n] institutionell-organisatorische[n] Kontext der ExpertInnen« (Meuser/Nagel 2002: 81) und »durch die leitfadenorientierte Interviewführung« (ebd.). Bei dieser Methode kann ein Nutzen daraus gezogen werden, dass der Autor selbst als IT-Fachkraft in der Branche gearbeitet hat und somit den Expert:innen auf Augenhöhe begegnen kann: In so einem Fall soll sich der Forschende nach Bogner/ Menz (2002: 67), anders als in anderen Interviewmethoden, nicht rein passiv verhalten. Interaktionseffekte sollen vielmehr als produktive Komponenten des Interviewverlaufs begriffen werden. Schätzt der Interviewte die Forschenden als Co-Expert:in ein, hat das Vorteile, wenn sachdienliche Informationen und Aufklärung über Sachverhalte erhoben werden sollen. »Wenn der Forscher sein fachlich-inhaltliches Interesse beweist, sein eigenes Wissen einbringt und engagiert diskutiert, ist auch der Befragte zu entsprechendem Engagement bereit und gibt Informationen und Wissen preis, das bei anderen Rolleneinschätzungen und Kompetenzzuschreibungen kaum zugänglich würde« (Bogner/Menz 2002: 51). Ein hohes fachliches Niveau im Gespräch von Co-Expert:innen erzeugt Daten, die dann »gewinnbringend für detaillierte Sachanalysen« (Bogner/Menz 2002: 52) sind. Zur Analyse solcher Daten ist die Grounded-Theory-Methode (GTM) besonders geeignet. Sie zählt nicht nur analytische Kategorien und fokussiert sich nicht auf sprachliche Feinheiten wie etwa die objektive Hermeneutik (vgl. Ley 2010). Kruse (2015) hält es bei qualitativen Interviewauswertungen für wichtig, eine »umfassende[…] gesprächs- bzw. textlinguistische[…] Beschreibung der konkreten Versprachlichungen« (Kruse 2015: 374) vorzunehmen. Er berücksichtigt in seinem rekonstruktiv-hermeneutischen Verfahren die »Art und Weise der Versprachlichung von Wirklichkeit« (Kruse 2015: 375). Diesem »(mikro-)sprachliche[n] Analyseansatz« (Kruse 2015: 376) folgt die GTM nicht: »Beim Kodieren geht es nicht um das Herausfinden des wahren Sinns, der wahren Be-/Deutung im Einzelfall […]. Das herauszufinden ist nicht Ziel und Anspruch der Kodierungsprozedur in der GTM […]. Die Daten eines Untersuchungsteilnehmers werden vielmehr dazu benutzt, um Vorstellungen über Grundkonzepte, Komponenten, Dimensionen, Bedingungsgefüge, Verlaufsmuster o.Ä. zu entwickeln« (Breuer/Dieris/ Lettau 2009: 78f.). Wenn sich die Interpretation in der Fallbeschreibung – bestehend aus unterschiedlichen Befragten-Perspektiven – bewährt, genügt das. Sie muss nicht den individuellen Sinn des Befragten widerspiegeln. Dadurch reduziert sich der Arbeitsaufwand für die Analyse eines Interviews, wodurch die Methode ermöglicht, größere Textmengen in einem gegebenen Zeitraum zu analysieren. Das Kodieren hilft dabei, Texte sowohl zu strukturieren als auch zu paraphrasieren und zusammenzufassen. Zudem ist die Grounded 3. Forschungsdesign und -methode 35 Theory der Informatik nicht fremd, wie die Verwendung im Information Systems Research zeigt (vgl. Wiesche et al. 2017)1. Das lässt sie für die vorliegende Untersuchung besonders fruchtbar erscheinen. 3.1.2. Bezug zu Forschungsstand und Theorieentwicklung Die GTM ermöglicht es, den umfangreichen Forschungsstand aufgrund der vielfältigen Forschungsfelder wie IT-Outsourcing, Softwareentwicklung oder Folgen von IT für Organisationen und Arbeit zu berücksichtigten, ohne auf die Offenheit von qualitativer Sozialforschung verzichten zu müssen. Die Grounded Theory kennt unterschiedliche Vorstellungen darüber, ob mit theoretischen Vorannahmen ins Feld gegangen werden sollte. Mehrere Quellen vertreten die Ansicht, dass es nicht zielführend sei, komplett ohne Theorie an Daten heranzutreten (vgl. Breuer et al.: 2009: 58f.). Man spricht hier von »informed grounded theory« (Thornberg 2012). Der Rekurs auf den Forschungsstand ist notwendig und sinnvoll, um nicht bereits gemachte Erkenntnisse zu ignorieren. Anderenfalls könnte eine Erkenntnis redundant sein, »without knowing whether it had already been done, what were the main findings, and what remaining theoretical puzzles and empirical gaps needed to be addressed« (Deterding/Waters 2021: 714). Wichtig ist, dass der Fokus auf den Daten bleibt und nicht auf der Literatur und dass »concept or theoretical idea he or she constructs must be grounded in data« (Thornberg 2012: 54). Offenheit soll so lange wie möglich aufrechterhalten werden: Die Daten sollen aufzeigen, wie sie analysiert werden wollen, und entsprechend darf die Strukturierung nicht zu stark sein. Kruse spricht von »schielender Hermeneutik«, weil mit dem einen »Auge so offen wie möglich geschaut werden muss, mit dem anderen Auge zugleich aber stets theoretisch versiert beobachtet werden muss« (Kruse 2015: 363). Eine rigide Anwendung eines theoretischen Rahmens würde die Untersuchung stark einschränken (vgl. Collins/Stockton 2018: 9). In der vorliegenden Arbeit wird von konzeptionellen Ergebnissen gesprochen und nicht von Theoriebildung. Theorie wird dabei verstanden als ein Zusammenhang von Ideen, der erklärt, warum Faktoren auftreten und warum sie miteinander im Beziehung stehen (vgl. Gläser/Laudel 2006: 275). »Theory is about the connections among phenomena, a story about why acts, events, structure, and thoughts occur« (Sutton/Staw 1995: 378). Der erarbeitete Analyserahmen stellt zwar die Verbindung zwischen den beobachteten Handlungen und Strukturen her. Allerdings kann aufgrund der Vielzahl der unterschiedlichen Konstellationen, in denen Softwaregestaltung stattfindet, nicht davon ausgegangen werden, dass durch sieben Fallstudien in einer Branche eine Theorie der Software- 1 Wenn auch nicht immer in der vorgesehenen Tiefe: Von 43 untersuchten Studien nutzen die GT 23%, um eine Theorie zu entwickeln, und bei den anderen werden Modelle oder dichte Beschreibungen angefertigt. Das Memoing wird selbst bei den Theoriearbeiten nur bei jeder zweiten verwendet. Grundsätzlich wenden die Theoriearbeiten aber mehr Methoden an (vor allem offenes Kodieren, axiales Kodieren und theoretisches Kodieren) (vgl. Wiesche et al. 2017). 36 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung gestaltung entwickelt werden kann. Der hypothetische Charakter der Studienergebnisse soll durch die Verwendung des Begriffs des Konzepts klargestellt werden. 3.1.3. Selbst-Positionierung Die verwendeten Methoden müssen es zulassen, dass Vorwissen eingebracht werden kann, denn der Autor war selber in der Softwaregestaltung tätig. Wie bereits erwähnt, lassen dies alle drei Methoden zu. Zudem wurde beachtet, was als Positionierung in der Literatur bezeichnet wird: »Als Forschender positioniere ich mich und werde positioniert; ich beobachte und werde beobachtet.« (Breuer et al. 2009: 30) Am Beginn eines jeden Interviews hat sich der Verfasser als Wissenschaftler positioniert, der nicht nur eine Forschungsarbeit zur Digitalisierung in der Energiewirtschaft durchführt, sondern auch als ehemaliger IT-Berater in der Branche gearbeitet hat. Der Verfasser war von Januar 2011 bis Juli 2018 als IT-Berater tätig. Zunächst hat er als Trainee die Grundlagen der Branche und die Branchenlösung von SAP für die Versorgungsindustrie kennengelernt. Im Anschluss war er mit der Betreuung und Entwicklung von Software betraut und im Rahmen verschiedener Projekte bei EVU tätig. Letztere waren in zwei Fällen auch längerfristig, d.h., er hat zweimal fast zwei Jahre lang mit den Angestellten im Büro vor Ort gearbeitet. Somit war es kaum möglich, an das Thema unvoreingenommen heranzugehen. Themenwahl, Auswahl der Interviews, Interviewführung und Analyse sind durch seine Erfahrungen beeinflusst. Im Forschungsverlauf fand eine ständige Kontrastierung der gemachten Erfahrungen, der eigenen Alltagstheorien, des soziologischen Zugangs, der Forschungsliteratur, der Aussagen der befragten Personen und der methodischen Auswertung statt. Als Material sind die Erfahrungen des Verfassers jedoch nicht in die Fallstudien eingeflossen. 3.2. Forschungsverlauf 3.2.1. Feldzugang und Sampling Es wurde versucht, Fälle zu erforschen, die verschiedene Formen der Softwaregestaltung abbilden. Wie diese beschaffen sein sollten und welche Organisationen dafür in Frage käme, wurde ausgehend von der eigenen Branchenerfahrung, regelmäßigem Lesen der Zeitung für kommunale Wirtschaft (ZfK) und der Forschungsliteratur zu IT-Outsour- cing und Softwareentwicklung festgelegt. Obwohl der Feldzugang schwierig war, konnten verschiedene Fälle abgedeckt werden: interne Entwicklung in einem Konzern, kooperative Entwicklung mehrerer EVU, die Entwicklung durch eine Softwarefirma, die Entwicklung in einem Start-up, große (>5000 Mitarbeitende) und kleine (≤800 Mitarbeitende) EVU. Letztendlich lassen sich die Fälle danach sortieren, wie sich die Softwareentwicklung verteilt: ob sie durch mehrere Organisationen wie Softwarefirma oder IT-Dienstleistungsunternehmen (IT-DL), außerhalb oder innerhalb der EVU stattfindet. In der folgenden Abbildung 5 sind die Bezeichnungen der Fallstudien rot markiert. INTERN1 und INTERN2 sind Fallstudien, bei denen einen Teil der angewendeten Soft- 3. Forschungsdesign und -methode 37 ware eine Softwarefirma entwickelt hat (SAP). Einen anderen Teil entwickeln die anwendenden EVU, weshalb in der Spalte »EVU« die Kästchen »E« für Entwicklung und »A« für Anwendung platziert sind. Ein Kästchen mit »E« ist heller, weil diese Softwareentwicklung (bei SAP) nicht Teil der Analyse ist. Die grüne Linie steht für den Austausch zwischen Organisationen oder Teams bzw. Abteilungen. Bei KOOP1, KOOP2 und KOOP3 entwickeln sowohl eine Softwarefirma als auch ein IT-DL und einige EVU. Dabei ist nur im Fall KOOP3 auch die Entwicklung in der Softwarefirma Teil der Fallstudie ist. Bei PAKET entwickelt die Softwarefirma und die EVU wenden die Software nur an. Bei STARTUP finden Anwendung und Entwicklung in einer Organisation statt und Abteilungsgrenzen existieren nicht. Abbildung 5: Übersicht Fallstudien Für die Ansprache von Firmen und potenziellen Interviewpartner:innen wurde ein Handzettel entworfen und an versendete Nachrichten angehängt. Zusätzlich wurde seit Mitte 2020 immer noch ein Artikel mitversendet. Diesen hat der Verfasser für die Zeitung für kommunale Wirtschaft (ZfK) geschrieben (vgl. Sonnenholzner 2020). Das Ziel des Artikels war, Aufmerksamkeit zu erregen. Allerdings hat sich nur ein Berater gemeldet, mit dem es zu keinem Interview kam. Über den Verband kommunaler Unternehmen (VKU) ergab sich zwar die Teilnahme an einem Treffen mit IT-Abteilungslei- tenden aus EVU – aber ebenfalls keine Interviews. Auch über die Gewerkschaften Verdi und IGBCE konnten zwar Erstgespräche mit Personalvorständen arrangiert werden, aber leider keine weitergehenden Interviews. Erfolgreicher war die Vermittlung von Verdi an einen Betriebsrat eines größeren EVU, die zu mehreren Interviews führte. Dreimal war ich auf Kongressen: Bundesverband der Energiemarktdienstleistungsunternehmen 38 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung (BEMD), Bundesverband Informationswirtschaft, Telekommunikation und neue Medi- en (bitkom) und eines kommunalen IT-DL. Es ergaben sich nur kurze Gespräche – aber keine Interviews. Aufgrund des zähen Erfolges über Gewerkschaften und Netzwerkpartner:innen wurde parallel und verstärkt vor allem ab 2020 eine Internetrecherche zu Firmen durchgeführt. Zuerst hat der Verfasser einzelne Firmen (Stadtwerke größerer Städte, bekannte Softwarezulieferfirmen) per E-Mail angeschrieben. Daraus ergaben sich zwar Kennenlerngespräche, aber keine Interviews. Mit der Zeit wurden massiv die sozialen beruflichen Netzwerke (Xing und Linkedin2) genutzt. Zwar hat nur ein geringer Anteil auf Kontaktanfragen reagiert, doch kam es dadurch zu vielen Interviews. Die Sampling-Strategie bestand grundsätzlich darin, möglichst viele Interviews zu einem Fall aus verschiedenen Perspektiven auf die Softwareentwicklung zu bekommen (Anwendende, Programmierende, Gestaltende, Führungskräfte). Der Fokus lag auf den Handelnden zwischen Anwendung und Entwicklung, die Softwaregestaltung betreiben (bspw. IT-Projektleitung, Scrum Master, Product Owner, Anforderungsmanagement). Dadurch wurde der Forschungsgegenstand »facettenreich erfasst« (Merkens 2012: 291): sowohl in Bezug auf die Formen der Softwaregestaltung als auch auf die Perspektiven auf den jeweiligen Arbeitsprozess. Teilweise kamen die Interviewkontakte über die »Schneeballmethode« (ebd. 293) zustande und es entstanden »geklumpte Stichproben« (ebd.) durch die persönlichen Netzwerke in einer Organisation. Gleichzeitig wurden Interviews außerhalb dieser Netzwerke geführt, weil über die sozialen beruflichen Netzwerke Kontakte zustande kamen. 3.2.2. Ausgangsforschungsfragen und letztendliche Leitfragen Die Ausgangsfrage des Dissertationsprojektes war jene nach digitalen Wertschöpfungsnetzwerken in der Energiewirtschaft. Der Arbeitstitel lautete »Governance und Arbeit in den Organisationsnetzwerken der digitalen Energiewirtschaft«. Ausgehend von Untersuchungen zu den Folgen von Arbeitsverlagerungen von Mezihorak (2018) und Flecker/ Haidinger/Schönauer (2013) stellten sich folgende Forschungsfragen hinsichtlich der digitalen, netzförmigen Wertschöpfungsketten der Energiewirtschaft: 1. Welche Formen von Governance sind dort zu finden? 2. Wie verortet sich in ihr welche Art der Arbeit mit IT-Systemen? 3. Wie verändert sich der Arbeitsprozess in ihr? Nach Gläser/Laudel (2006) wurden für diese Leitfragen Unterfragen entwickelt. Erstere fragen nach »Beziehungen und Vorgängen im Untersuchungsfeld, nach Merkmalen von Individuen, Gruppen, Organisationen usw.« (Gläser/Laudel 2006: 89). Der Forschungsstand konzentrierte sich zunächst nur auf Energiewirtschaft und Netzwerkarbeit, wurde im Verlauf dann aber mehr und mehr auf IT und Software ausgeweitet, was dann auch 2 Die beiden Netzwerke wurden auch angefragt, ob es die Möglichkeit gäbe, die Daten für Recherchen bzw. Auswertungen zu nutzen, was aber beide ablehnten. 3. Forschungsdesign und -methode 39 andere Fächer einschloss (bspw. Information Science, Wirtschaftsinformatik, Anforderungsmanagement). Im späteren Verlauf der Forschung verschob sich das Thema immer mehr in Richtung Softwareentwicklung. Das lag zum einen am Feldzugang (siehe oben). Zudem fiel im Lauf der Zeit auf, dass eine Forschungslücke dahingehend besteht, wie verschiedene Formen der Softwaregestaltung die Arbeitsgestaltung prägen und wie jene Wissensarbeiter:innen arbeiten, die eine tragende Rolle dabei spielen. Als zentrale Leitfragen stellten sich letztendlich folgende heraus, die teilweise auch den Kategorien des Analyserahmens entsprechen: • Welche Rolle spielt die Organisation von Anwendung und Programmierung für die Softwaregestaltung? (Arbeitsteilung, Koordinationsformen) • Welche Rolle spielen die Softwarearchitektur und der Anwendungsbereich der Software für deren Gestaltung? • Wie wird in verschiedenen Konstellationen ein Arbeitsprozess der Softwaregestaltung zwischen Anwendung und Programmierung etabliert? (Wissensgrenzen überwinden: Rollen, Ablauf, Kommunikation, Werkzeuge) • Welche Folgen hat die Softwaregestaltung für die Arbeitsgestaltung? (Umfang der Digitalisierung, Kontrolle, Beschäftigungssystem etc.) • Wer darf wie mitgestalten an der entstehenden Software? Welche Rolle spielt das Management? (Partizipation) • Inwiefern sind bei der Gestaltung industriespezifische Muster zu erkennen? (am Beispiel der Energiewirtschaft) 3.2.3. Weiterer Forschungsverlauf und durchgeführte Interviews Es wurden Expert:inneninterviews mit Leitfäden durchgeführt. Der Leitfaden wurde mehrmals angepasst: 1. aufgrund des Fortschritts der Untersuchung und 2. für jedes Gespräch abhängig von der Rolle des Gegenübers im Arbeitsprozess, den offenen Punkten bzw. Unklarheiten aus vorhergehenden Interviews eines Falles, der Interviewdauer etc. Der im Anhang befindliche Leitfaden stellt somit eine Sammlung von Fragen dar. Es wurde versucht, ausführlichere Antworten zu evozieren durch Formulierungen wie »Könnten Sie das bitte noch einmal erklären?«, »Es scheint mir, andere sagen…« (vgl. Martin 2017: 88). Abstrakte Fragen und Zusammenhänge wurden vermieden (vgl. ebd. 91). Das erste Interview wurde am 20.01.2019 geführt und das letzte am 17.02.2023 (Schwerpunkte waren Mitte 2019, Anfang und Mitte 2020 und Mitte 2021). Die Länge der Interviews war mit 90 Minuten veranschlagt, wobei sich einige Interviewpartner:innen nicht so viel Zeit nehmen konnten. Insgesamt wurden 137 Interviews geführt, für 128 davon konnten Aufnahmen gemacht werden. Letztendlich konnten für die Fallstudien nur 62 verwendet werden. Wie oben zum Thema Sampling beschrieben, war das Ziel, mehrere (mindestens drei) Interviews zu einem Fall zu sammeln. Das ist in sieben Fällen geglückt. Die restlichen Interviews sind Einzelfälle (maximal zwei Interviews) zum Arbeitsprozess der Softwaregestaltung. 40 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung Tabelle 1: Anzahl und Zeitraum geführte Interviews je Fall Fall Anzahl w m Erstes Letztes INTERN1 6 1 5 14.07.2020 16.05.2022 INTERN2 8 1 7 02.07.2020 03.12.2021 KOOP1 17 3 14 17.03.2020 20.05.2022 KOOP2 12 4 8 21.04.2020 01.03.2022 PAKET 12 3 9 01.04.2020 15.07.2022 KOOP3 4 0 4 30.03.2020 22.10.2021 STARTUP 3 1 2 04.10.2022 17.02.2023 Summe 62 13 49   Von den 62 Interviews wurde eines per E-Mail geführt. Die anderen 61 wurden aufgenommen und transkribiert. Nur zwei Interviews fanden persönlich statt – der Rest telefonisch oder per Video-Konferenz. Aus methodischer Sicht können E-Mails bei Leitfadeninterviews sogar Vorteile bieten (vgl. Schiek 2022), ebenso wie telefonische gegenüber solchen von Angesicht zu Angesicht (vgl. Schulz & Ruddat 2012). Es gab nur einen Fall, in dem die befragte Person merklich zurückhaltend war und nur sehr allgemein gesprochen und wenig Konkretes über die eigene Arbeit gesagt hat. Die Fallbeschreibungen zu INTERN1 und STARTUP wurde jeweils von einer befragten Person gelesen und ohne Korrekturen als zutreffend eingeschätzt. Dieses Verfahren, um die Güte der qualitativen Sozialforschung zu steigern, wird »kommunikative Validierung« (Steinke 2012: 320) genannt. Ab Februar 2020 wurde ein Forschungstagebuch geführt, wo ich sowohl theoretische als auch empirische Notizen (Überlegungen, Beobachtungen etc.) gesammelt habe. Ebenso wurden die Interview-Situationen protokolliert und in einer Datei festgehalten (inkl. Auffälligkeiten und offene Fragen). 3.3. Kodierung, Kategorisierung und Fallvergleich Es wurde mit verschiedenen Kodierungsformen experimentiert. Ganz zu Beginn wurde line-by-line Coding (vgl. Charmaz 2014: 343) probiert, was zu viele Kategorien hervorbrachte. Friese (2016) weist darauf hin, dass es Corbin und Strauss darum ging, dass Codes nicht nur Dinge beschreiben sollen, sondern eine Interpretation und Gruppierung auf höherer Ebene darstellen (vgl. ebd. 487). Dadurch entstehen nicht so viele Kategorien. Sie meint zudem, statt »kodieren« wäre »taggen« als Begriff besser, weil es mehr um Etikettieren oder Identifizieren geht (vgl. ebd. 490). Zentraler Teil ist neben dem »Taggen« verschiedener Interviewstellen für sie das analytische Schreiben (vgl. ebd.). Das ist in der vorliegenden Arbeit beim Text für die Fallstudien angewendet worden. Dabei ist die Besonderheit von Expert:inneninterviews zu beachten: 3. Forschungsdesign und -methode 41 »Anders als bei der einzelfallinteressierten Interpretation orientiert sich die Auswertung von ExpertInneninterviews an thematischen Einheiten, an inhaltlich zusammengehörigen, über die Texte verstreuten Passagen – nicht an der Sequenzialität von Äußerungen je Interview« (Meuser/Nagel 2002: 81). Es wurde das versucht, was die Grounded Theory ausmacht: offen zu bleiben, nahe an den Daten zu bleiben, Codes einfach, präzise und kurz zu halten, Handlungen in den Fokus der Codes zu nehmen, Daten untereinander zu vergleichen (vgl. Charmaz 2014: 120). Aus der Codierung entstand ein Kategorienbaum in MAXQDA. Er besteht aus fünf übergeordneten Kategorien: • »Verteilte Kompetenzen und Funktionen/Arbeitsteilung/Spezialisierung« • »Verhandlung generisch/individuell, integriert/segregiert« • »Kooperation durch gemeinsames Wissen + etablierte Kommunikation« • »Rahmen zur Integration von Software(-entwicklung)« • »Subjektivierung (Möglichkeiten und Erwartungen des Einzelnen)« Die Unterkategorien und -codes dienten dazu, für jeden Fall die zugeordneten Textabschnitte in Excel zu exportieren, dort zu paraphrasieren und entsprechend den (übergeordneten) Kategorien in eine Textdatei für die Fallbeschreibung zu kopieren. Letztendlich wurden die Kategorien, wie sie nun im Analyserahmen festgehalten sind, erst ausgearbeitet durch die Paraphrasierung aller als wichtig erachteten Interviewstellen, deren Zusammenführung in einen Fall und durch die das im Fall entwickelte fallspezifische Narrativ. »In reading each case, the researcher will develop an idea of the important concepts and their linkages in the data— provisional answers to the ›how‹ and ›why‹ questions at the center of the research.« (Deterding/Waters 2021: 727) Es war ein Prozess, in dem immer wieder zwischen den Kategorien in MAXQDA, einzelnen Fallstudien und Theorien gedanklich hin und her gesprungen wurde. »When passing through multiple cases in the first round of reading and coding, we recommend compiling a list of concepts and relationships between them that appear to describe multiple cases and begin describing the contours of relationships in thematic memos.« (Ebd.) Das wurde für mehrere Fallstudien durchgeführt. Peu à peu wurden über den Vergleich verschiedener Fallstudien die Reflexion der Theorie und unter Berücksichtigung der Fragestellung die Kategorien weiterentwickelt. Ergebnis dieses Prozesses sind drei Oberkategorien (soziotechnische Konstellation, Arbeitsprozess Softwaregestaltung, Folgen) mit den jeweiligen Unterkategorien und der Analyserahmen in seiner jetzigen Form. Auf diese Weise konnte ein Rahmen gewonnen werden, um die Fallstudien zu strukturieren und den Arbeitsprozess der Softwaregestaltung von seinen Ausgangspunkten und seinen Folgen klar analytisch unterscheiden zu können. 42 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung Als Erstes wurde für INTERN2 und KOOP1 versucht, einen möglichst kohärenten Aufbau der Fälle zu erstellen. Dann kamen die anderen Fälle, wobei auch INTERN2 und KOOP1 immer wieder leicht angepasst wurden. Zuletzt wurde STARTUP angefertigt. Abschließend wurde weiter an den jeweiligen Besonderheiten der Fälle gearbeitet. Im weiteren Verlauf (Überarbeitung der einzelnen Kapitel der Dissertation, wiederholtes Lesen der Fallstudien) kam nichts mehr zum Vorschein, was gegen den Analyserahmen gesprochen hätte. Zuletzt wurden die Unterschiede zwischen den Fällen herausgearbeitet und aus diesen Idealtypen konstruiert. Im Sinne Webers bezieht sich ein Idealtyp zwar »auf empirische Phänomene, beschreibt sich aber nicht einfach, sondern übersteigert einige ihrer Merkmale, um zu einem Modell sozialer Wirklichkeit zu gelangen.« (Kelle/Kluge 2010: 83) 3.4. Grenzen der Untersuchung Erstens kann nicht ausgeschlossen werden, dass es ein Bias hinsichtlich funktionierender und aus der Perspektive der Beschäftigten positiver Arbeitsbedingungen gibt. Im Laufe der Feldforschung fiel auf, dass sich vor allem jene Personen und Organisationen zur Verfügung stellten, bei denen die Softwareentwicklung und der Softwareeinsatz positiv wahrgenommen werden. Nur vereinzelt gab es Gespräche, bei denen über IT-Pro- jekte gesprochen wurde, die schiefgelaufen sind. Es blieb in diesen Fällen dann bei Einzelinterviews. Da viele Fallstudien über einzelne Personen gewonnen wurden, war es von deren Offenheit und Bereitschaft abhängig, sich Zeit für Interviews zu nehmen (nur bei INTERN1 und INTERN2 kamen die Kontakte innerhalb der Organisation über den Betriebsrat zustande). Der Verdacht besteht, dass damit immer auch eher offene persönliche Netzwerke genutzt wurden. Womöglich sind dadurch Arbeitsumfelder mit schlechteren Arbeitsbedingungen aussortiert worden. Das heißt aber nicht, dass die Befragten nicht einzelne Aspekte ihrer Arbeit kritisiert hätten (bspw. die Zusammenarbeit mit den IT-DL oder Softwarefirmen). Zweitens kann die Professionalität der Softwareentwicklung nicht gemessen werden. Es werden zwar in einzelnen Fallstudien aktuelle Methoden wie Scrum angewendet oder sogar spezifische Entwicklungsmethoden wie Domain-driven Design3. Gleichwohl wurde nicht der Quellcode geprüft, wie die Anforderungen geschrieben sind, ob sie klar und verständlich sind, ob sauber dokumentiert wurde oder inwiefern objektorientiert programmiert wurde. Drittens wurde das Wissen der Befragten nicht differenziert erfasst. Es ist immer noch eine offene Forschungsfrage, welche Wissensbestände entscheidend für die softwaretechnische Interdisziplinarität sind. Nicht in allen Fällen wurde genau erhoben, vor allem wegen der geringen Anzahl der Befragten, wer wie viel von welchem Wissen hat. Meist wurde das Verhältnis von IT- zu Fachwissen abgefragt, welche Schulungen besucht 3 Dabei wird die Wissensdomäne des Anwendungsbereichs in der Programmierung berücksichtigt, z.B. indem Fachbegriffe aus dem Anwendungsbereich in den Quellcode einfließen. Dadurch wird die Kommunikation zwischen Programmierenden und Anwendenden einfacher, weil sie die gleichen Begriffe verwenden. 4. Softwaregestaltung als Teil der Digitalisierung 49 Grundstruktur aus einer Zeit vor Computer und Internet. So ist die Organisation auf die Produktion von Autos oder die Wartung von Stromnetzen ausgelegt. Die IT-Abteilung ist eine neben anderen indirekten Bereichen wie Personal oder Buchhaltung. Die Fallstudien werden unterschiedliche Wege zeigen, wie Organisationen, die nicht primär auf die Softwareentwicklung ausgerichtet sind, sich mal mehr und mal weniger auf dem Weg machen, selbst Software zu programmieren. 4.2. Die zwei Kernprobleme der Softwaregestaltung Traditionelle Nicht-IT-Unternehmen können nicht einfach Start-ups werden und werden es auch nicht. Sie müssen aber für sich die Frage beantworten, wie sie mit ihren bestehenden Strukturen umgehen. Die Untersuchung der Fallstudien im 8. Kapitel und die Aufarbeitung des Forschungsstandes ergaben zwei Kernprobleme der Softwaregestaltung – egal ob die Organisationen ihre bestehenden sozialen Strukturen (ob z.B. zur Bearbeitung von Kund:innenrechnungen oder Anträgen auf Bauförderung) abbilden, verändern oder ganz neu gestalten: die softwaretechnische Interdisziplinarität und die softwaretechnischen Gestaltungsmöglichkeiten. Die beiden Probleme sind deshalb relevant, weil sie die Besonderheit des Arbeitsprozesses der Softwaregestaltung ausmachen und die hier vorliegende Untersuchung darum kreist, wie Organisationen diese beiden Probleme in unterschiedlichen Kontexten lösen und was das für Folgen hat. 4.2.1. Softwaretechnische Interdisziplinarität Um Software für eine bestimmte Industrie zu entwickeln, ist Wissen über die entsprechende Industrie notwendig. SAP (bekannt für industriespezifische Standardsoftware) ist seit der Gründung 1972 groß geworden damit, in gemeinsamen Projekten mit Industriefirmen das industriespezifische Wissen in Konzepte und in Software umzusetzen (vgl. Siegele/Zepelin 2009: 24, 52ff.). Wissen aus dem jeweiligen branchenspezifischen (zukünftigen) Anwendungsbereich der Software und softwaretechnisches Know-how müssen zusammen gedacht werden, um die Möglichkeiten der Technologie auszuschöpfen. Vom allgemeinen Branchenfachwissen über einzelne industriespezifische Prozesse, über Firmenwissen zu firmeninternen Abläufen bis hin zum individuellen Anwendungswissen eines Arbeitsplatzes mit seinen spezifischen Besonderheiten, an dem Spezialist:innen arbeiten: Die Programmierenden müssen wissen, was sie zu programmieren haben. Wer verantwortlich für die Interdisziplinarität ist, d.h. ob die Fertigkeiten der Softwareentwickelnden ergänzt werden (vgl. Baukrowitz/Boes/Eckhardt 1994) oder andere Fächer am Zug sind (Management, Behavioral Science, VWL) (vgl. Boehm 2006: 25), ist eine Frage, welche die Fallstudien erhellen werden: Es geht nicht nur um das Wissen Einzelner, sondern vor allem darum, durch den Arbeitsprozess der Softwaregestaltung die verschiedenen Wissensträger:innen zusammenzubringen. So oder so nimmt die Herausforderung mit der Spezialisierung der Softwarelandschaft zu: was die Vielzahl an Anwendungen, aber auch deren Umfang anbelangt. Die immer komplexer werdenden Softwarepakete haben ihre eigene Biografie und Pfadabhängigkeiten (vgl. Pollock/Williams 2009: 80ff.), deren Kenntnis oftmals Voraussetzung ist, um sie weiter- 50 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung entwickeln zu können. Um all dieses Wissen für die Softwaregestaltung zu mobilisieren, können unterschiedlichste soziale Einheiten zusammenarbeiten: Softwarefirma und Verwaltung, IT-Abteilung und Fachbereich, Start-up und Industriekonzern, Scrum- Entwicklungs-Team und ein Team für Stromhandel. Für viele Nicht-IT-Firmen ist das eine Herausforderung, weil der offene, kommunikative Austausch ebenso wenig zum Organisations- und Arbeitsrepertoire gehört wie die Softwareentwicklung. Wegen immer komplizierterer Softwarelandschaften und -lösungen und immer komplexerer Industrieprozesse gibt es immer mehr Spezialist:innen, von denen eine Abhängigkeit besteht und auf deren Partizipation man angewiesen ist (das Heer an SAP-Beratenden ist nur ein Beispiel). Auch wenn schon früh in der Forschung darauf hingewiesen wurde, wie wichtig Partizipation bei der Einführung von IT-Systemen ist (vgl. Mann/Williams 1960: 225f.), zeigen die Fallstudien dieser Arbeit, dass in den Unternehmen weniger der Wille ausschlagend ist, die Beschäftigten an der Gestaltung zu beteiligen. Vielmehr geht es darum, an das für die Gestaltung der Software notwendige Wissen bestimmter Beschäftigter zu gelangen. Der Gestaltungsprozess verteilt sich auf all diejenigen, die zwischen Anwendenden und Programmierenden Anforderungen aufnehmen, Softwarepakte anpassen, Verhandlungen über neue Features führen. Hohlmann (2007) spricht in ihrer Untersuchung von Netzwerken der Gestaltung, die über das, wie sie es nennt, Integrationswissen aus Organisations-, Prozess- und Technologiewissen verfügen. Andere Autoren sprechen von einem »institutionalisierten Informationsbruch« (Remer 2008: 162) zwischen IT- und Fachabteilung, den es zu überwinden gilt. Durch die Konzentration der IT-Fachkräfte und -Kompetenzen in einer Abteilung besteht eine Wissensgrenze zu den anderen. Mit dem IT-Alignment gibt es eine eigene Disziplin in der (Wirtschafts-)Informatik, die erforscht, wie IT- und Fachabteilung besser zusammenarbeiten können (darauf geht 6.4.1.1 genauer ein). Dabei geht es z.B. um das IT-Projektmanagement, das aufgrund der fachlichen und technischen Unsicherheiten in Projekten am besten sowohl über fachliches als auch über technisches Wissen verfügen sollte. Gefragt ist die oder der »hybrid IT PM with one foot in the IT domain and the other foot in the business domain« (Ko/Kirsch 2017: 316). Zentral für die Untersuchung ist, wie in unterschiedlichen Kontexten diese Wissensgrenzen überwunden werden. Die dafür zuständigen Beschäftigten und Arbeitsabläufe der Gestaltung stehen dabei im Mittelpunkt. Es handelt sich um eine neue Sorte von Wissensarbeit zwischen Anwendung und Programmierung. Die Wissensarbeitenden verfügen über spezifische Qualifikationen, Arbeitsmethoden und Rollen. Sie sorgen für die kontinuierliche Weiterentwicklung der Software. Sie sorgen für die Konzeptionslogistik, dass Programmierende immer wieder neue Konzepte bekommen, die zu programmieren sind. Die Fallstudien machen deutlich, dass diese interdisziplinäre Wissensarbeit im Kontext der Konkurrenz auf der Ebene von Individuen und Organisationen geschieht. Wirtschaftliche Indikatoren bestimmen Entscheidungen über Einsatz und Entwicklung von Software. Das hat u.a. die Folge, dass es nicht ohne weiteres möglich ist, sich frei von jeglichen Zwängen über die optimale Software auszutauschen. Kooperatives Verhalten und damit eine Basis für einen offenen Wissensaustausch ist zwischen und innerhalb von Firmen nicht selbstverständlich. 4. Softwaregestaltung als Teil der Digitalisierung 51 4.2.2. Softwaretechnische Gestaltungsmöglichkeiten Ein zweites zentrales und typisches Problem für den Arbeitsprozess der Softwaregestaltung ist jenes der softwaretechnischen Gestaltungsmöglichkeiten2. Worin liegt das Problem? Organisationen müssen zwei wesentliche Entscheidungen treffen und den Arbeitsprozess der Softwaregestaltung entsprechend organisieren: A) Gestaltung der Software: Ein Quellcode kann nur auf einem Computer existieren oder auf einem vernetzten Server, auf den die ganze Welt Zugriff hat. Er kann Teil eines Standards sein, den viele Organisationen nutzen, oder rein individuell und es nutzt ihn nur eine Organisation. Die Softwaregestaltung steht nun vor dem Problem, den jeweiligen softwaretechnischen Zuschnitt zu erarbeiten: Soll sie etwas individuell oder als Standard gestalten? Soll sie eine Standardsoftware erweitern oder anpassen? B) Gestaltung von Arbeit und Organisation: Die anwendende Organisation kann die Software selbst gestalten oder durch andere wie IT-Dienstleistungsunternehmen (IT-DL) oder Softwarefirmen gestalten lassen. Beim Primat der Softwareentwicklung hat sich eine Organisation dafür entschieden, sich organisatorisch auf die Softwareentwicklung auszurichten. Das Problem, sich organisatorisch auf die Anwendung einer (Standard-)Software oder auf die Softwaregestaltung auszurichten, wird hier als softwaretechnische Ausrichtung einer Organisation bezeichnet. Die Fallstudien des 8. Kapitels zeigen konkret, dass es für die Softwaregestaltung entscheidend ist, welche softwaretechnischen Gestaltungsmöglichkeiten in puncto Zuschnitt (Standard oder individuell) und organisatorische Ausrichtung (Anwendung oder Gestaltung) die Organisationen nutzen. Theoretisch könnte A) bedeuten, dass man weltweit nur noch eine (Softwarebaustein-)Bibliothek mit allen möglichen Funktionalitäten braucht. Dadurch wäre die Softwaregestaltung deutlich weniger aufwendig. Tatsächlich gibt es solche Bibliotheken mit industrieunspezifischen, grundlegenden Softwarebausteinen3. Auch eine Standardsoftware wie SAP kann als Versuch gesehen werden, bestimmte Funktionalitäten (bspw. Arbeitsabläufe oder Datenverarbeitungsprozesse) durch identischen Quellcode für alle Organisationen gleich abzubilden – selbst die industriespezifischen. Der softwaretechnische Zuschnitt kann sich aus unterschiedlichen Ursachen ergeben: • Synergien: Durch generische Teile einer Software oder Standardbausteine für mehrere Anwendungsbereiche (verschiedene Abteilungen, Firmen etc.) oder Programmierungen (einzelne Bausteine) sollen Synergien gehoben werden. 2 Es gibt Ähnlichkeiten zur »Bezugsebene« des Informationsraums (vgl. Boes et al., 2016: 34). Auch wenn die Firmen diese Bezugsebene nutzen, um die softwaretechnischen Gestaltungsmöglichkeiten zu verwirklichen: Der Begriff der Bezugsebene allein würde nicht verdeutlichen, um welche spezifischen Eigenschaften von Softwareentwicklung es geht, die für die Softwaregestaltung besonders relevant sind. 3 Zum Beispiel Java Class Library, C++ Standard Library, React.js, Node.js. 52 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung • Institutionell: Die Software wird auf Standards ausgerichtet (bspw. technische oder regulatorische). • Abgrenzung von Wettbewerbern: Die individuelle Software soll es ermöglichen, sich von der Konkurrenz abzuheben – ob durch mehr Effizienz oder individuelle Angebote für die Kundschaft. • Anwendungsperspektive: Die Software soll auf die individuelle Perspektive der anwendenden Organisation zugeschnitten werden, bspw. durch die Erweiterung einer Standardsoftware. • Prioritäten: Die Software bildet nur die wichtigsten Funktionalitäten ab. Das kann bedeuten, dass eine Standardsoftware nur einen bestimmten Umfang hat. Die anwendenden Unternehmen müssen diese dann noch individuell erweitern, um ihre firmeninternen Prozesse darüber hinaus mit Software abarbeiten zu können. Egal wie der Zuschnitt zustande kommt: Sobald eine Arbeitsteilung existiert und je mehr Organisationen mitgestalten, desto höher wird der Koordinations- und Kommunikationsaufwand, um bspw. festzulegen, was in einen Standard hineinkommt oder ob und wie Synergien gehoben werden oder nicht. Eine Möglichkeit, diesen Aufwand zu umgehen, ist, sich einfach einer Standardsoftware unterzuordnen und seine Organisation und die Arbeit jedes Einzelnen auf diese auszurichten. Das bedeutet aber, potenzielle Möglichkeiten der individuellen Softwaregestaltung und unter Umständen Wettbewerbsvorteile auszuschlagen. Solche Synergien durch Standardbausteine schaffen im Fall von ERP-Systemen Softwarefirmen. Sie haben es übernommen, generische, für einen Standard relevante Arbeitsschritte und Prozesse zu entdecken und daraus eine Standardsoftware zu entwickeln – was eine aufwendige Verhandlungsarbeit ist (vgl. Pollock/Williams/D’Adderio 2007). Laut Mormann (2016) befördern Softwarehersteller den Glauben, dass Organisationen viel gemeinsam haben, vor allem wenn sie Standardsoftware verkaufen wollen (vgl. ebd.: 110). Es bestünde eine »Gleichheitsunterstellung« von SAP und den SAP-Beratenden: Prozesse in verschiedenen Industrien unterscheiden sich nicht (vgl. ebd.: 158). Eine Standardsoftware will die Softwarefirma möglichst oft verkaufen (»economies of scale«). Wie ein Fall in der Untersuchung hier zeigt (KOOP1), gibt es aber auch die Möglichkeit, dass mehrere Organisationen sich in kooperativen Projekten die Frage stellen, was sie denn gemeinsam haben, um dann zusammen eine Software zu entwickeln. Daraus kann eine umfassende Standardlösung entstehen oder einzelne Funktionalitäten, die über die Cloud abrufbar sind. Auch intern können Organisationen für Prozesse Standardsoftwarebausteine entwickeln, die mehrere Abteilungen mit den gleichen Arbeitsschritten betreffen. Nicht nur Softwarefirmen oder Nicht-IT-Firmen tun sich schwer, solche Synergien zu erkennen. Auch auf Branchenebene ist es schwierig: Ein Beispiel dafür ist das Erneuerbare-Energien-Gesetz (EEG). Nachdem es die Bundesregierung verabschiedet hat, haben sich über die Jahre hinweg regelmäßig die Einspeisevergütungen für Erneuerbare-Energie-Anlagen geändert. Viele unterschiedliche Energieversorger, Softwarefirmen und IT-Beratungen haben erst eigene Lösungen entwickelt, um diese Anlagen abzurechnen, und diese dann immer wieder angepasst, anstatt zentral eine Lösung zu programmieren. Im Laufe der Zeit stellten einzelne Softwarefirmen Standardlösungen zur Ver- 4. Softwaregestaltung als Teil der Digitalisierung 53 fügung. Aber ob der Weg über den Markt der effizienteste für die Branche war, ist fragwürdig. Das zweite praktische Problem der softwaretechnischen Gestaltungsmöglichkeiten B) betrifft die Gestaltung von Arbeit und Organisation: wie sich Organisationen dazu verhalten, dass sie sich so gestalten könnten, wie es optimal aus Sicht der Softwareentwicklung ist, und nicht so, wie es z.B. EVU gewohnt sind: nach Fachabteilungen getrennt für Instandhaltung, Abrechnung, Einkauf, IT-Abteilung, Stromhandel etc. Sich zusammen mit vielen anderen Abteilungen auf eine Software einigen oder eigenständig eine auswählen? Die IT-Landschaft von der bestehenden Organisation aus gestalten oder die bestehende Organisation als softwarebasierte Organisation betrachten und davon ausgehend nach Optimierungen oder Synergien auf Organisationsebene suchen? Sich an einer Standardsoftware ausrichten oder diese anpassen? Wenn Amazon seine Logistiksoftware auch anderen Firmen anbietet, setzt sich dann nicht nur eine zentrale Softwarelösung, sondern auch eine Standardorganisation und -arbeit durch? Selbst bei einer Standardsoftware stehen die Unternehmen vor der Frage, ob sie sich rein auf die Anwendung konzentrieren oder intern selbst individuelle Anpassungen und Erweiterungen an der Standardsoftware vornehmen: Der Bedarf an betriebsindividuellen Anpassungen ist groß. Die Anzahl an kooperierenden Firmen der Standardsoftwarefirma SAP, die unter die Kategorien »Solution Building« und »Consulting Services« fallen, beträgt 457 in Deutschland und 2796 weltweit4. Das ist möglich, weil SAP sich für eine Softwarearchitektur entschieden hat, die neben individuellen Einstellungen auch Veränderungen am Quellcode und das Programmieren von Erweiterungen zulässt. In vielen Firmen existiert die Mischung aus Standardsoftware und selbst entwickelten Erweiterungen oder Anpassungen. Wie es zu dieser Mischung kommt und sie konkret aussieht, wäre eine weitere Frage. Es mögen Pfadabhängigkeiten sein oder strategische Entscheidungen, die Softwaregestaltung in verschiedene Bestandteile aufzuteilen: einen Teil für Tätigkeitsbereiche der Firmen, in denen durch individuelle Softwareentwicklung ein Vorteil gegenüber konkurrierenden Firmen erzielt werden kann, und einen anderen Teil, bei dem das nicht der Fall ist und daher eine Standardsoftware ausreicht, die viele andere auch verwenden (es bleibt die Möglichkeit, durch eine effizientere Anwendung Wettbewerbsvorteile zu erzielen). Es ist eine wichtige strategische Frage, welche internen Prozesse sich an einer Standardsoftware ausrichten (können) und dadurch »das Differenzierungsmerkmal der Organisation gegenüber möglichen Konkurrenten am Markt verloren geht« (Masak 2006: 245). Grundsätzlich IT nicht als strategisch relevant und austauschbar wie Bürostühle zu erachten, scheint da wenig plausibel.5 Die Herausforderungen der softwaretechnischen Gestaltungsmöglichkeiten und Interdisziplinarität sind geringer bei Start-ups bzw. bei Firmen, die von Anfang an auf Softwareentwicklung als Basis ihrer Leistungserbringung zurückgreifen. Wenn der 4 Abgerufen von www.sap.com/partners/find.html am 26.04.2023 5 2003 hat Nicholas Carr den Artikel »IT Doesn’t Matter« geschrieben, in dem er argumentiert, dass IT den Unternehmen keine strategischen Vorteile brächte. Sie tendiere dazu, eine austauschbare Standardware (»Commodity«) wie bspw. Seife zu sein. Dies wäre dann der Fall, wenn die Software einfach zu bedienen ist, ohne große organisatorische Veränderungen ausgetauscht werden kann und kein Lock-in-Effekt besteht (vgl. ZDNet Staff 2004). 54 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung oben erwähnte Primat der Softwareentwicklung gilt, ist die Organisation bereits auf deren Anforderungen ausgerichtet. Die industriespezifischen Prozesse werden den softwaretechnischen Entwicklungsprozessen untergeordnet und damit die Arbeitsgestaltung komplett selbst in die Hand genommen. Die beiden Kernprobleme verdeutlichen, wie wichtig es ist, verschiedene Konstellationen der Softwaregestaltung zu untersuchen. Die Firmen der Fallstudien des Empirie- Kapitels wählen unterschiedliche Softwarearchitekturen oder Möglichkeiten von Synergien, Wissensgrenzen verlaufen jeweils anders und haben entsprechend Auswirkungen auf Arbeit und Organisation. Genauso wird sich zeigen, dass es einer besonderen Form der Kontrolle der Softwaregestaltung bedarf, um diese beiden Kernprobleme der Softwaregestaltung zu adressieren. Exkurs: Entwicklungsplattform von SAP Die ersten vier Fallstudien (INTERN1, INTERN2, KOOP1, KOOP2) des Empirie-Kapitels verwenden die Entwicklungsplattform von SAP. Es handelt sich um jene der ERP-Versi- on R/3, die SAP in den 90ern entwickelt hat. Für die Entwicklungsplattform ist SAP Net- Weaver die technische Basis. Sie ist als offene Plattform konzipiert, d.h. nicht nur für den SAP-Konzern intern, sondern auch für kooperierende Firmen und die Kundschaft (vgl. Siegele/Zepelin 2009: 191). Teil des SAP NetWeaver ist eine eigene, SAP-spezifische Programmiersprache (ABAP) und Werkzeuge, um selbst Änderungen und Erweiterung am Standard vorzunehmen: Entwicklungsumgebung (inkl. Debugger), Ticketsystem (Solution Manager) und Transportwesen, um zwischen Entwicklungs-, Test- und Produktivsystem Softwareänderungen zu transportieren (vgl. Frederick/Zierau 2011: 29ff.). Die Architektur der ERP-Software hat Folgen für die Arbeitsteilung: Außerhalb der ERP-Firma programmieren EVU und IT-DL selbst. Zur betrieblichen Realität der EVU gehört deshalb nicht nur die angewendete Software, sondern eine Test- und Entwicklungsumgebung. Einerseits müssen sich die EVU und IT-DL an die Möglichkeiten halten, die ihnen SAP bietet, und es sich gut überlegen, wie weitgehend sie Anpassungen vornehmen, weil das für sie mehr Aufwand bedeutet. Andererseits eröffnet es Spielräume für die interne IT-Abteilung und externe IT-DL, die Software zu ergänzen und ihre eigenen Softwarelösungen an das SAP-System anzudocken. Weil Organisationen unterschiedlichster Branchen SAP anwenden, anpassen und erweitern, hat sich ein SAP-Ökosystem aus kooperierenden Firmen und SAP-Beraten- den entwickelt. Für die Versorgungswirtschaft (zu der die Energiewirtschaft gehört) gibt es insgesamt 202 kooperierende Firmen in Deutschland (siehe Abbildung unten). 150 davon bieten »Consulting Services« an, zu denen die Programmierung gehört. Zusätzliche Lösungen, die dann über Schnittstellen mit dem ERP-System von SAP verbunden werden, bieten 104 kooperierende Firmen an (»Solution Building«). Zu dem SAP-Ökosystem gehören u.a. umfangreiche Hilfe-Seiten und Communities im Internet zur ABAP-Entwicklung (z.B. https://community.sap.com/topics/abap). 4. Softwaregestaltung als Teil der Digitalisierung 55 Tabelle 2: Anzahl kooperierende Firmen SAP allgemein und Versorgungswirtschaft Kategorie Anzahl Kooperierende Firmen mit SAP für die Versorgungswirtschaft in Deutschland 202 - Solution Sales: SAP product and technology advisory and support services 84 - Solution Building: Build solutions on top of, or integrate with, SAP technology 104 - Consulting Services: SAP solution design, development, implementation, and integration guidance 150 - Outsourced Solution Management: Hosting, managing, and running your SAP solutions and IT infrastructure 34 - Global Technology; Global vendors of hardware, databases, storage systems, networks, and mobile computing technology 2 - Education: Learning needs assessment and enablement services 10 (Quelle: SAP https://www.sap.com/partners/find.html, abgerufen am 28.04.2023) 5. Softwaregestaltung basiert auf Wissen undKommunikation Um die beiden Forschungsfragen der Formen und Folgen von industriespezifischer Softwaregestaltung zu beantworten, sind nicht nur die beiden oben genannten Kernprobleme der Softwaregestaltung entscheidend (softwaretechnische Interdisziplinarität und Gestaltungsmöglichkeiten). Genauso wichtig für die Praxis sind Kommunikation und Wissen: Software besteht vom Quellcode über die Softwarearchitektur, ihren Einstellungsmöglichkeiten bis zur Bedienoberfläche aus mehreren Schichten. Weil für die beteiligten Menschen eine dieser Ebenen der primäre Arbeitsgegenstand ist (z.B. für die Programmierenden der Quellcode, für die Anwendenden die Bedienoberflächen), müssen sie sich über ihre unterschiedlichen Perspektiven verständigen und ihr Wissen einbringen. Das Wissen über die komplexe Welt aus Algorithmen, Daten, Einstellungsmöglichkeiten, Schnittstellen, fachlichen Prozessen etc. vor und hinter der Softwareoberfläche reicht aber nicht aus. Die Beteiligten müssen sich im Zuge der Softwaregestaltung kommunikativ austauschen können. Für die Softwaregestaltung ist neben der verbalen Kommunikation nonverbale Kommunikation als wissensbasierte Textarbeit in Form von Arbeit an Quelltext, Spezifikationen, Anforderungen, Konzepten oder Dokumentationen notwendig. Wie das Kapitel zeigt, wurde Softwareentwicklung selbst im Laufe ihrer Geschichte in Forschung und betrieblicher Praxis mehr und mehr als Kommunikationsprozess verstanden. Somit ist nicht nur die Anwendung von Software sozial bedingt. Ihr gesamter Gestaltungsprozess ist es. Das Kapitel erläutert die Prämisse der vorliegenden Arbeit, dass anders als bei anderen sozialwissenschaftlichen Ansätzen zum Verhältnis von Mensch und Technik eine Arbeitsteilung zwischen Mensch und Software(entwicklung) besteht: Der Mensch verfügt über das Wissen, kann kommunizieren und damit Software gestalten. Softwaregestaltung ist etwas genuin Menschliches, weil dafür ein sinnhafter Bezug zu Objekten notwendig ist. Damit legt dieses Kapitel die Basis für die darauffolgenden Ausführungen, auch um zu verstehen, warum Wissen und Kommunikation zwei zentrale Begriffe und Elemente der Softwaregestaltung sind. Es geht um die materielle Basis des Arbeitsprozesses. 58 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung 5.1. Technische Grundlagen: Software als Ergebnis menschlicher Textarbeit 5.1.1. Verarbeiten und verstehen: Arbeitsteilung zwischen Menschen undMaschinen Was die theoretische Sicht auf Technik anbelangt, geht diese Arbeit von einer klaren Arbeitsteilung zwischen Menschen und Computern aus: 1. Nur der Mensch kann informiert sein, etwas wissen und kommunizieren. 2. Der Mensch ist das soziale Wesen und 3. entwickelt die Software. Der Computer weiß weder etwas, noch ist er informiert, noch stellt er soziale Beziehungen her oder schreibt autonom industriespezifische Software. Zu 1.: Für die Person, die Daten eingibt, sind die Daten Informationen und sie braucht ein bestimmtes Wissen, um die Eingabe korrekt auszuführen. Informationen sind immer soziale Interpretationen von Daten, sie haben eine Bedeutung, sie haben Sinn. Wobei aus Informationen Wissen wird, wenn sie in einen bestimmten Erfahrungskontext eingebunden sind (vgl. Willke 1998: 162). Das ist etwas, dass ein Computer nicht kann, weil interpretieren nur Menschen können. Wie von Brödner (2014) analysiert, ist der Interpretationsmoment hervorzuheben, der zwischen maschinell ausgeführten Operationen und sozialen Handlungen eingebettet ist, zwischen zu interpretierenden Daten und maschinellen Verarbeitungen (Algorithmen). Wenn Maschinen Daten liefern und diese dann zur Steuerung und Kontrolle dieser Maschinen dienen, dann müssen diese Daten von den Beschäftigten interpretiert werden (wie bspw. von Zuboff 1988 ausführlich beschrieben). Der Begriff des Wissens markiert den Übergang zum Handeln. Mit Wissen können Menschen Probleme lösen. Mit Wissen können sie in einem bestimmten Kontext handeln und entscheiden. Somit ist es irreführend, davon zu reden, dass Computer handeln, entscheiden oder etwas wissen. Das können nur Menschen, die einem Zeichen eine Bedeutung beimessen können (s.o.) und dann der Bedeutung gemäß handeln. »Wissen als Erklärungszusammenhang für Informationen, als eine mit Erfahrung, Kontext, Interpretation und Reflexion angereicherte Form der Information, geeignet, Arbeitshandeln und Entscheidungen anzuleiten« (Jürgens 1999 nach Wilkesmann 2005: 56). Also: Wenn ein Mensch Daten Sinn geben kann, sind es Informationen. Erst wenn dieser Mensch daraus Handlungen und Entscheidungen ableiten kann, wird es zu Wissen. Genau dieser Prozess, den eine Autorin als De- und Rekontextualisierung beschreibt (vgl. Degele 2000: 69), passiert täglich in den softwaregestützten Organisationen. So z.B. wenn jemand vor einer Eingabemaske steht, die er nicht versteht, weil ihm das Wissen fehlt, oder wenn der Rechnungsbeleg alle notwendigen Informationen enthält, die/der neue Sachbearbeitende aber nicht genau weiß, warum die Rechnung nun so und nicht anders aufgebaut ist. Für die Organisation ist es wichtig, dass die Software das richtige Rechnungsformular erzeugt. Womöglich ist die Umsetzung auch dokumentiert. Für neue Sachbearbeitende wäre es jetzt wichtig zu wissen, wo sie diese Dokumente finden oder wer ihnen sagen kann, warum etwas wie auf dem Rechnungsformular gestaltet ist. Selbst bei programmiertem Quellcode ist es wichtig zu wissen, warum etwas wie entwickelt wurde. Die Bedeutung ist sonst nicht ersichtlich. Selbst eine umfangreiche Dokumentation reicht oft nicht aus, um das gesamte Wissen zu hinterlegen (vgl. D’Adderio 5. Softwaregestaltung basiert auf Wissen undKommunikation 65 zu ermöglichen, solange sie die zentrale Rolle von Wissen und Kommunikation für den Arbeitsprozess berücksichtigen. 5.2.1. Vom schnellen Reparieren zum iterativen, kollektiven Kommunikationsprozess Einerseits würde man aus dem bisher Gesagten vermuten, dass Kommunikation wichtig in der Softwareentwicklung ist. Andererseits ist nicht verwunderlich, dass es bei einer neuen Technologie, die aus der Ingenieurs- und Mathematik-Tradition kommt, erst einmal um deren Erforschung und Entwicklung ging. Dafür waren komplexe Kommunikationsprozesse und kommunikative Fertigkeiten nicht entscheidend. Für die Programmierer hieß es in den 50ern noch »Engineer software like you engineer hardware.« (Boehm 2006: 13) Oftmals fand IT-Arbeit damals noch in Forschungs- und Entwicklungsabteilungen statt, wo die Techniker:innen unter sich waren. Unter seines/ihresgleichen sind die Wissensgrenzen geringer. Als einen extremen Typus sieht Weizenbaum die zwanghaft Programmierenden an, für die Programmieren ein Selbstzweck ist. Ihnen geht es vor allem darum, mit der Maschine zu interagieren (vgl. Weizenbaum 1978: 161). Sollen sie dann Software schreiben, die in anderen Kontexten als der Werkstatt oder dem Labor funktionieren soll, ändern sich die Anforderungen. Die Erfahrung der Beherrschbarkeit der Maschine durch Erteilen eindeutiger Befehle via Programmiersprache wird unreflektiert auf soziale Zusammenhänge übertragen, in der diese Software entsteht oder in der sie wirken soll (vgl. Klischewski 1996: 78). Die Widerständigkeit des Sozialen fand erst über die Jahrzehnte hinweg in den Methoden der Softwareentwicklung mehr und mehr Berücksichtigung. Hieß es in den 60ern »code-and-fix«, also einfach zu programmieren, schauen, ob es funktioniert, und dann zu verbessern (vgl. Boehm 2006: 14), wurden in den 70ern die getrennten Aufgabenschritte der Anforderungsanalyse und des Designs eingeführt (siehe auch Friedman/Cornford 1989). Das ursprünglich entwickelte Wasserfallmodell sah die erst mit Scrum weitverbreiteten Mechanismen der Iterationen, Prototypen und Feedbacks zwischen den Entwicklungsschritten vor. In der Praxis wurde das Wasserfallmodell aber erst einmal als rein sequenzieller Prozess ausgelegt (vgl. Boehm 2006: 15). Softwareentwicklung wurde zum Arbeitsvorgang, in dem streng abgetrennte Phasen der Spezifikation, Programmierung, Tests und Implementierung aufeinander folgen. Kritisch wird diese strikte Trennung vor allem, weil bei komplexen Anforderungen fehlerfreies Arbeiten unmöglich ist. Eine vollständige Konzeption oder Spezifikation ist nicht möglich, weil sich u.a. die Anforderungen der Anwendenden im Projektverlauf ändern. Das kann an einem veränderten Umfeld liegen (Konkurrenzdruck, Markt verändert sich) oder daran, dass technische Möglichkeiten erst bewusst werden, dass es Kommunikationsprobleme gab oder dass erst in der Anwendung neue Ideen auftauchen (vgl. Funken 2001: 30). In einem bekannten Artikel von 1980 schreibt Lehman, dass ein Programm nie korrekt sein kann, weil es die Umwelt nicht komplett beschreiben kann. Software ist immer nur ein Modell der Welt. Für ihn kann es bei Software deshalb nicht um absolute Korrektheit gehen (was eine mathematische Herangehensweise bedeuten würde), sondern um die Relevanz der Ergebnisse oder die Anwendungsfreundlichkeit (vgl. Lehman 1980: 1064). Er führt auch eine Unterscheidung verschiedener Programmtypen ein. Das 66 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung ist insofern wichtig, weil es darauf hinweist, dass es jenseits der hier behandelten industriespezifischen Softwareentwicklung selbstverständlich weiterhin Programme gibt, die einige wenige oder sogar eine programmierende Person allein nach einer klaren Spezifikation entwickeln kann (bspw. ein:e Physiker:in, die eine Software für ein physikalisches Experiment programmiert). Laut Lehman kann Programmierung zudem keine Fließbandarbeit sein, weil u.a. die Entwicklung nicht bereits im Vorhinein in einfach verbundene Untereinheiten zerteilt werden kann, ohne dass sie sich gegenseitig bei der Umsetzung beeinflussen (vgl. Lehman 1980: 1065). Das liegt auch an der Abstimmung zwischen der fachlichen Domäne, in der die Software laufen soll, und den Programmierenden. Um die Nutzendenpartizipation und damit die Kommunikation zur Programmierung zu verbessern, wurde seit Mitte der 70er die Methode des Prototyping entwickelt. Sie entlastet die Anforderungsaufnahme, weil das anschauliche Ergebnis als Kommunikationsgrundlage fungiert und Nutzende direkt an der Spezifikation beteiligt sind (vgl. Funken 2001: 32ff.). Wie weitgehend sich das in der Praxis mit der Zeit durchgesetzt hat, wäre zu untersuchen. In den 80ern stellten Floyd/Keil eine Methode vor, die eine iterativ-inkrementelle Vorgehensweise und eine kontinuierliche Kommunikation zwischen programmierenden und anwendenden Beschäftigten vorsieht. Vorteilhaft ist dabei auch die geteilte Verantwortung für die Weiterentwicklung – anstatt dass sie nur bei den Programmierenden liegt, die gar nicht wissen, was die Anwendenden brauchen (vgl. Funken 2001: 36). Die/der Programmierer:in soll nicht mehr einfach Herstellende:r sein, sondern »Berater[:in] in Informationsangelegenheiten, welche Multiperspektivität anerkennt und umsetzt, Vielfalt und Rückkopplung sucht und zu Revisionen bereit ist« (Floyd/ Keil 1983: 36 zitiert nach ebd. 37). Das Agile Manifesto von 2001 (Scrum ist eine der agilen Methoden) führte diesen Ansatz weiter und stellte vier Kernforderungen auf: • »Individuals and interactions over processes and tools. • Working software over comprehensive documentation. • Customer collaboration over contract negotiation • Responding to change over following a plan.« (Beck et al. 2001) Letztendlich legt das Manifest einen klaren Fokus auf einen iterativen Arbeitsprozess mit direktem, regelmäßigem Feedback. Das Wasserfallmodell setzte sich auch deswegen nicht vollumfänglich durch, weil der Druck wuchs, Software möglichst schnell auf den Markt zu bringen, und es immer mehr Software gab, bei der die Benutzendeninteraktion im Vordergrund stand. Anforderungen waren schwerer im Vorhinein festzustellen. Sie wurden emergent und folgten dem IKIWISI-Syndrom – I know it when I see it: Die anwendende Person konnte erst sagen, ob die Software den Anforderungen genügt, wenn sie das Programm selbst gesehen hat und testen konnte (vgl. Boehm 2006: 18). Deshalb war schon die Verwendung von Prototypen ein Fortschritt. Die agilen Methoden bewerkstelligten das, indem in kurzen Zyklen (bspw. monatlich) ausführbare Software erstellt 5. Softwaregestaltung basiert auf Wissen undKommunikation 67 wird, die dann die zukünftigen Nutzenden oder die Fachleute testen und dazu Feedback geben können. 5.2.2. Kommunikationskompetenz und -kern: Anforderungsmanagement Ohne auf alle agilen Ansätze5, geschweige denn alle anderen Methoden eingehen zu können, soll der obige kurze Abriss andeuten, dass die Softwareentwicklung sich selbst erst mit der Zeit methodisch mit ihrer sozialen Einbettung befasst hat. Umfangreiche Feldstudien in den 80ern haben festgestellt, dass nicht fehlende technische Fertigkeiten das Problem waren und sind. Die Softwareproduktivität und -qualität beeinflusst vor allem »zu geringe und zu wenig verbreitete Kenntnisse der Entwickler über das Anwendungsgebiet, sich verändernde und widersprüchliche Anforderungen an das Software- Design und Kommunikations- und Kooperationsprobleme zwischen Entwickler und Kunden« (Funken 2001: 46). Es wurde abgerückt davon, sich allein auf technische Fertigkeiten zu konzentrieren: »Software-Entwicklung und -gestaltung muß also […] in wesentlichen Teilen als ein Lern-, Kommunikations- und Aushandlungsprozeß verstanden werden, der hohe Kooperations- und Kommunikationsanforderungen – mithin soziale Kompetenzen – an die Entwickler stellt.« (Funken 2001: 48) Mehrere Autor:innen weisen in den 80ern und 90ern drauf hin, dass das auch in der Ausbildung von Informatiker:innen berücksichtigt werden sollte (vgl. Funken 2001: 46ff., Baukrowitz/Boes/Eckhardt 1994). »[D]rei Viertel ihrer Arbeitszeit benötigen Software-Entwickler für die Kommunikation mit verschiedenen Partnern: Auftraggebern, Benutzern, Kollegen, Management, Vertrieb usw.« (Funken 2001: 48) Christiane Floyd sprach 1992 von »software development as an insight-building process in terms of multiperspectivity, self-organization and dialogue« (Floyd 1992: 86) und eben nicht davon, dass Anforderungen fix auszumachen sind wie technische Eigenschaften einer Maschine oder in einem kontrollierbaren, experimentellen Setting. Anders als bspw. bei einem Labor-Experiment ist der Entwicklungsprozess nicht durch innertechnische Rationalität vorgegeben, sondern ist ein Gestaltungsprozess, bei dem nicht nur ein technisches System, sondern auch »die sozialen Zusammenhänge seiner Verwendung modelliert werden müssen« (Schulz-Schaeffer 1996: 8). Der kommunikationsintensivste Teil der Softwareentwicklung, das Requirements Engineering (auf Deutsch meist: Anforderungsmanagement), entwickelt sich seit den 70ern zu einem eigenständigen Forschungsfeld (vgl. Funken 2001: 52). Es stellt die korrekte und objektive Darstellung von Anforderungen in Frage. Es plädiert dafür, unterschiedliche Meinungen, Perspektiven und Sichten zu berücksichtigen. Unter anderem 5 Wie Extreme Programming, Kanban, Scrum etc. 68 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung sollen auch potenziell konfliktträchtige Perspektiven aufgenommen werden (vgl. Funken 2001: 56f.). Das Schreiben von Anforderungen, die dann die Programmierenden umsetzen, hat etwas von einer Sozialforschung: Wer mit wem wie interagiert und wie die Arbeitsabläufe sind, muss erfragt und beobachtet werden. Die Anforderungsaufnahme kann Methoden wie Interviews, Ethnografie, Perspektivenübernahme oder diskursive Anforderungsanalyse verwenden. Die Anforderungsstrukturierung nutzt Skizzen, Use Cases, Diagramme etc. (vgl. Kaminski 2012: 112ff.). Im Prozess der Anforderungsaufnahme treten IT-Fachkräfte als Kommunikations- und Übersetzungsexpert:innen auf, wobei die Programmiersprache einen Eindeutigkeitsdruck auf die Kommunikation des Anforderungsmanagements ausübt (vgl. Kaminski 2012: 89). Es muss Übersetzungsarbeit auf dem Weg zum Quellcode geleistet werden, weil Anwendende, Auftraggebende und Programmierende unterschiedliche Sprachen sprechen (vgl. Kaminski 2012: 91). So entscheidend ist die Sprache dabei, dass selbst sprachliches Framing relevant ist, um zu verstehen, wie Entwicklungsprozesse ablaufen und Expert:innen Autorität gewinnen (vgl. Alvarez 2002: 103). Die Kommunikation muss es den Systemfachleuten ermöglichen, sich mit dem fachlichen Kontext vertraut zu machen, und den fachlichen Kontextexpert:innen, sich mit der Systemsprache vertraut zu machen. Nur so kann der Formalisierungs- und Systembildungsprozess funktionieren (vgl. Kaminski 2012: 121). Anforderungen aufzunehmen ist für einige Forschende vor allem ein Meinungsbildungs- und Verbalisierungsprozess: »Based on this vision, much of what occurs during the requirements process should be about opinion and will formation that is, the development of an understanding of, and the creation of meaning – about the organization and its goals and processes for achieving these goals, supported by new systems« (Ross/Chiasson 2011: 134). »[R]equirements elicitation takes on the form of a ›confessional‹ act where the individual verbalizes thoughts, intentions and consciousness« (Alvarez 2002: 85). »The RE process is a socio-technical activity. It requires intensive communication among stakeholders who have different backgrounds, skills, culture, knowledge, and behavior« (Alsanoosy et al. 2020: 356). Erfolgreicher Wissenstransfer, gegenseitiges Verständnis (gemeinsame Konventionen und Sprache) und Kommunikation sind wesentliche Faktoren für eine erfolgreiche Softwareentwicklung (vgl. Corvera Charaf et al. 2013: 117). Das gilt ebenso bei der Implementierung einer Standardsoftware. Es geht darum, inwiefern diese anzupassen oder wie sie einzustellen ist. Auch hier müssen die Anforderungen der Kundschaft erst aufgedeckt werden, weil sie für Beratende und Kundschaft nicht so klar auf der Hand liegen (vgl. Mormann 2016: 169). Dabei haben es die Beratenden in der Hand, welche Möglichkeiten der Software sie preisgeben oder bspw. aus Kostengründen die Gestaltungsmöglichkeiten einschränken (vgl. Mormann 2016: 186). Wie bereits oben aufgezeigt, sind Begriffe wie Funktionen, Architekturen, Modelle oder Schnittstellen Hilfsmittel, um über Software zu reden. Dabei können im Prozess des Anforderungsmanagements nicht nur einzelne Funktionalitäten eine Rolle spielen, sondern auch wie die Software aufgebaut ist. Modelle dienen dazu, um über Software zu diskutieren und sie zu dokumentieren. Sie spielen in unterschiedlichen Entwicklungs- 5. Softwaregestaltung basiert auf Wissen undKommunikation 69 methoden jedoch eine unterschiedliche Rolle. Manche Methoden6 betrachten Modelle von vornherein als vorläufig und als fortlaufend anzupassen (vgl. Mahr 2009: 245). Agile Softwareentwicklung verwirft den »Gebrauch von Modellen zugunsten unmittelbarer Programmierung« (Mahr 2009: 246). Folglich wird das Programm selbst zur Referenz, um über die gedachten Modelle zu reden und sie anzupassen. Abhängig von der Methode unterscheidet sich dann die Kommunikation im Anforderungsmanagement und damit der Softwaregestaltung. 5.2.3. Kommunikation und Wissen organisieren: Local Practice statt Best Practice Um die Softwareentwicklung so zu organisieren, damit sie »the right thing« (Friedman/ Cornford 1989: 204) tut, hat die Prüfung der Forschungsliteratur keine Best Practice zutage gefördert. Vielmehr existieren lokale Praktiken und widersprüchliche Vorgehensweisen. Daraus ergeben sich Ansätze, aber noch keine Konzepte für die Beschreibung dessen, was bei industriespezifischer Softwareentwicklung in der Phase der Softwaregestaltung in unterschiedlichen Kontexten zwischen Anwendung und Programmierung passiert. Unabhängig von einzelnen Methoden wie Scrum oder dem Anforderungsmanagement betrachten die Autor:innen der »general theory of software engineering« (Wohlin et al. 2015) bei der Softwareentwicklung Wissen und Kommunikation als zentral. Den Kern der Theorie bildet das intellektuelle Kapital, welches aus dem Wissen der Organisation (organisationales Kapital wie Dokumentationen, Anleitungen oder der Quellcode selbst), der Fähigkeit von Individuen (Humankapital) und den Beziehungen zu den Kund:innen und Anwendenden besteht (soziales Kapital). Wobei soziales Kapital hilft, die zwei Kapitalsorten (Human, organisational) miteinander zu verbinden (u.a. um implizites Wissen – »tacit knowledge« – auszutauschen und voneinander zu lernen). Zentral ist für die Autorenschaft letztendlich die Kommunikation: »Software system development is more of a communication problem than a technical problem« (Wohlin/Smite/Moe 2015: 231) Wie eine Entwicklungsaufgabe umgesetzt wird, hängt vom intellektuellen Kapital und dem angestrebten Performance-Ziel ab. Das heißt, die Theorie sieht durchaus vor, dass bspw. das intellektuelle Kapital nicht ausreicht, um die Aufgabe umzusetzen. Aufgabe des Managements ist es dann, die Ziele zurückzuschrauben. Eine Best Practice oder spezifische Methode schlagen die Autor:innen nicht vor. Sie haben ein situatives Verständnis von Softwareentwicklung, wobei Wissen, die Kompetenzen der Mitarbeitenden, Kommunikation und gute Beziehungen eine zentrale Rolle spielen. Diese Abkehr von einzelnen Methoden und die Hinwendung zu abstrakteren Zusammenhängen vollzieht bereits ältere Literatur. In Bezug auf Managementstrategien zur Softwareentwicklung sei- en keine eindeutigen Best Practices auffindbar: 6 In diesem Fall RUP (Rational Unified Process). 70 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung »Policies [of management strategies] pursued depended on the particular task at hand, and on the particular skills, experience levels and even personalities of the staff involved« (Friedman/Cornford 1989: 358). Die Autoren lehnen bspw. Aussagen von anderen Forschenden ab, die Dequalifizierung (»deskilling«) und direkte Kontrolle oder eine Mischung von »Slack« und direkter Kontrolle allgemein als beste Strategie ansehen (vgl. ebd. 356). Andere Forscher stellen ebenso die »lokale Praxis einer inkrementellen Anpassung von Vorgaben, Zielen und Vorgehensschritten an sich wandelnde oder erst spät erkennbare Erfordernisse« (Schulz-Schaef- fer 1996: 1) fest. Ein anderer Autor spricht bei Softwareentwicklung von »Zonen iterativer und kommunikativer Verständigungsprozesse« (Peter 1993: 423), weil nicht vorweg geplant festgelegt werden kann, wann wer über was kommuniziert. Trotzdem seien Entwicklungsmethoden nicht überflüssig. Sie haben einen Wert für den Prozess, weil sie Sicherheit erzeugen. Sie helfen, den Planungsprozess erst einmal in Gang zu setzen und den Beteiligten eine gewisse Handlungssicherheit zu geben (vgl. Schulz-Schaeffer 1996: 15). Es gibt Fälle, die bestimmten Managementstrategien klare Grenzen aufzeigen. Eine Studie zeigt, wie bei ausgelagerter Softwareentwicklung autoritäre Kontrolle verhindert, dass sich ein gemeinsames Verständnis entwickelt und eine ausreichende Kommunikation stattfindet. Beides wird erst wieder durch vertrauensvolle Beziehungen möglich (vgl. Gregory/Beck/Keil 2013: 1226). Auch frühe Autoren argumentieren, dass nicht einfach mehr Arbeitskräfte produktiver sind, sondern dass Kommunikation entscheidend ist und dass erst über diese nachgedacht werden sollte (vgl. Conway 1968: 31). Bei einer Untersuchung von Softwareprojekten stellt die Autorin fest, dass Demokratisierung die Produktivität einer individualisierten, wissensspezialisierten Belegschaft steigern kann (vgl. Müller 2010: 52f.). Kooperatives Arbeiten sei vielversprechender – ob durch kooperative Planung, Eigeninitiative etc. (ebd. 281f.). Eine Studie zu globalen Softwareprojekten kommt zu dem Schluss, dass nicht mehr das Management das Wissen zentralisiert oder verwaltet, sondern die eingesetzten »[K]oordinationsmechanismen zu Wissensmanagementinstrumenten« (Kotlarsky/Van Fenema/Willcocks 2008: 99) werden. Wenn die Fachleute der Anwendungsbereiche und der Programmierung einer Software zusammenarbeiten sollen, sind statt einer vertikalen Integration oder Märkten Netzwerke die optimale Organisationsform. Das zeigt eine Studie zur Entwicklung eines digitalen Kontrollsystems für Flugzeugtriebwerke (vgl. Brusoni/Prencipe/Pavitt 2001: 610). Setzt sich also das agile Arbeiten mit seinen Kernforderungen durch? »The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. […] The best architectures, requirements, and designs emerge from self-organizing teams.« (Beck et al. 2001) Empirisch existiert ein gemischtes Bild, was die Organisation der Softwareentwicklung anbelangt. Selbstorganisation und direkte und offene Kommunikation sind in effizienz- 5. Softwaregestaltung basiert auf Wissen undKommunikation 71 getriebenen Organisationen nicht immer vorzufinden: Autoren sehen Fälle, in denen Softwareentwicklung so strukturiert und organisiert werden kann, dass sie »dem Ideal eines strikt vorgeplant-arbeitsteiligen Arbeits- und Produktionsprozesses recht nahekommt« (Schulz-Schaeffer/Bottel 2018: 102). Zugleich räumen sie ein, dass das nicht immer so ist und Softwareentwicklung auch in teamförmigen Abstimmungsprozessen à la Scrum stattfinden kann (vgl. ebd.). Andere Untersuchungen zeigen, dass Scrum nicht automatisch zur Selbstorganisation führt (vgl. Pfeiffer/Sauer/Ritter 2014, vgl. Boes et al. 2018). Unterschiedliche Organisationsformen sind auch bei internationaler Softwareentwicklung zu finden: Zwei Fallstudien stellen einmal eine Industrialisierung und fabrikmäßige Arbeit fest und einmal eine wenig formalisierte, auf eigenverantwortliche Kommunikation setzende Arbeitsweise. Beides sind somit Beispiele für einmal direkte und einmal permissive Kontrolle in der Softwareentwicklung (vgl. Feuerstein 2012). Bei einer anderen Fallstudie hatte allein die Verlagerung der Softwareentwicklung innerhalb Deutschlands »ausgeprägte Tendenzen der Spezialisierung, Abschottung, Verlust an Aufgabenvielfalt und Zuname der Dokumentations- und Kontrollarbeiten« (Flecker/ Holtgrewe 2008: 321) zur Folge. Die geringe Formalisierung der geografisch verteilten Arbeit wurde zum Problem. Sie wurde dann stärker standardisiert (vgl. ebd.). Ganz zu schweigen davon, dass es unterschiedliche Vertragsverhältnissen für Programmierende inkl. Selbstständige gab (vgl. ebd. 316f.). Daneben wirken sich die Projektphase oder die Teamgröße auf die Arbeit in der Softwareentwicklung aus: Spätere Phasen in einem Projekt sind strukturierter (Heidenreich/Kirch/Mattes 2008: 13) und bei größeren Teams werden formale Organisation und Dokumentation wichtig (vgl. Ralph 2015: 35). Allein der Typ der Software kann weitreichende Folgen für ihre Entstehung haben, wie eine Gegenüberstellung von Carmel und Sawyer (1998) zeigt: Ob eine Softwarefirma entwickelt oder intern in eine Firma selbst: Laut den Autoren besteht intern eine Matrixorganisation und es läuft bürokratischer ab. Die Softwarefirma arbeitet dahingehend u.a. selbstorganisierter und die Prozesse haben eine geringere Reife. Zudem ist die Realität vieler Softwareentwickelnde, dass sie bestehende Standardsoftware anpassen und deshalb viel Zeit damit verbringen, diese zu beurteilen, zu verändern und andere Lösungen zu integrieren (vgl. Boehm 2006: 21). Womit wir wieder am Anfang dieses Absatzes angekommen sind: Der Ansatz von Wohlin et al. (2015) ist insofern zielführend, weil er nicht auf feste Methoden oder Managementstrategien wie Standardisierung oder Selbstorganisation setzt, wenn es um die Analyse von Softwareentwicklung geht. Zudem geht es bei der Arbeit hier um jene Phase der Softwareentwicklung, bei der die verschiedenen Kontexte eine noch größere Rolle spielen dürften und ein Wissensaustausch schwieriger zu standardisieren und kontrollieren ist. Um in der Scrum-Begrifflichkeit zu sprechen, geht es hier um die Rolle Product Owner. Sie ist für das Schreiben von Anforderungen zuständig und wie sie an ihre Infos über die Anwendung (in unterschiedlichen Industrien, Firmen oder Abteilungen) kommt. Sie findet sich in unterschiedlichsten Kontexten wieder. Die Spezifikation einer Software kann auf unterschiedlichen Wegen gelingen. Austausch von Wissen und Kommunikation sind flexibel. Ein Meeting, eine gut formulierte E-Mail, ein klärendes, persönliches Gespräch oder klare Abläufe via Ticketsystem sind allesamt Wege, Anforderungen zu spezifizieren (mehr dazu siehe unter 6.4.4). Es bleibt die Spannung zwischen offenem und direktem Wissensaustausch und Effizienz und Wett- 72 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung bewerb, wie sie allgemein für Wissensarbeit typisch ist. Bei ihr basiert Effizienz darauf, »Wissen und Expertise als Rohstoff umzuformen« (Willke 1998: 166). Das Konzept des soziotechnischen Netzwerkes im nächsten Kapitel zeigt, wie Organisationen den Arbeitsprozess der Softwaregestaltung trotzdem kontrollieren können. Exkurs: Was sind die Bestandteile von Scrum? Scrum ist eine Methode zur Softwareentwicklung, bei der iterativ Konzepte an Programmierende übergeben und von diesen abgearbeitet werden. Der Scrum-Prozess besteht aus Rollen, Artefakten und Meetings (vgl. Gloger 2009: 11ff.): Scrum-Prozess Beschreibung Rollen Product Owner:in für die Softwarelösung (das Produkt) verantwortlich; pflegt Anforderungen (Items) in eine Liste (Product Backlog) und priorisiert sie für die Programmierenden Scrum Team Personen, die notwendig sind, um Anforderungen in Software zu verwandeln; managt sich selbst (inkl. Arbeitsmenge); den Standards und Prozessen von Scrum verpflichtet; für die Qualität verantwortlich Scrum Master:in beseitigt Schwierigkeiten, Blockaden und Probleme, die das Team aufhalten; nicht weisungsbefugt, sorgt für Einhaltung Scrum-Prozess; schult Teilnehmende in ihren Rollen Management für Ressourcen und Richtlinien zuständig, setzt Rahmen des Scrum-Prozesses, löst von Scrum Master:in identifizierte Probleme Artefakte Product Backlog Liste mit Anforderungen (Items), je Anforderung schätzt das Team den Aufwand Sprint ein Zyklus (z.B. 2 Wochen), in dem Team Items abarbeitet Sprint Backlog Liste mit abzuarbeitenden Aufgaben für einen Sprint, wird täglich überarbeitet und aktualisiert Meetings Daily Scrum Meeting (ca. 15 Minuten) im Team, bei dem Personen sagen: Was habe ich seit dem letzten Daily Scrum erreicht? Was will ich bis zum nächsten Daily Scrum erreichen? Welche Impediments (Hindernisse) stehen mir dabei im Weg? Sprint Plannings Treffen für anstehenden Sprint, über Anforderungen und Ziele des im Sprint entwickelten Softwareteils; wie wird Software aufgebaut und welche Architektur soll sie haben? Sprint Review Treffen, bei dem das Team Funktionalität am Ende des Sprints präsentiert; Fortschritt wird anhand von »usable Software« demonstriert Retrospektive Treffen, in dem das Team die eigenen Arbeitsprozesse optimiert 5. Softwaregestaltung basiert auf Wissen undKommunikation 73 5.3. Zwischenfazit: Softwaregestaltung als soziologisches Problem Für die Untersuchung der Formen und Folgen von industriespezifischer Softwaregestaltung hat Kapitel 4 dargestellt, warum Softwaregestaltung zum Kern der Digitalisierung von Wirtschaft und Gesellschaft gehört. Dies gilt auch für von Software durchdrungene Organisationen, die nicht mit Software ihr Geld verdienen. Softwaregestaltung kann in unterschiedlichen Kontexten stattfinden, die auch im weiteren Verlauf der Arbeit noch eine Rolle spielen werden: durch Softwarefirmen, in digitalen Start-ups, durch IT-DL, in den EVU selbst etc. Zudem hat Kapitel 4 für die weitere Analyse grundlegende Begriffe anhand eigener Überlegungen eingeführt, die für das hier vertretene soziotechnische Verständnis moderner Organisationen stehen: softwaretechnische Interdisziplinarität und softwaretechnische Gestaltungsmöglichkeiten (bestehend aus softwaretechnischer Ausrichtung und Zuschnitt). Eine Variante der Letzteren ist der Primat der Softwareentwicklung, bei dem eine Organisation von Anfang an auf die Softwaregestaltung ausgerichtet ist (softwaretechnische Ausrichtung) und für sich eine individuelle Software gestaltet (softwaretechnischer Zuschnitt). Eine andere Variante ist, dass sich eine Organisation auf die Anwendung einer Standardsoftware konzentriert. Um begrifflich zu klären, was bei der Softwareentwicklung der Mensch macht und was die Maschine, hat Kapitel 5 zwischen den Begriffen Daten, Informationen, Wissen und Kommunikationen unterschieden. In Abgrenzung zu anderen Theorien über das Verhältnis von Menschen und Technik folgt die Untersuchung dem kritisch-realistischen Ansatz von Mingers/Willcocks (2014). Demnach unterscheiden sich die drei Welten von Person, Sozialem und Technik ontologisch und epistemologisch voneinander und zwischen Mensch und Technik besteht eine Arbeitsteilung: Der Mensch versteht, interpretiert und vermittelt zwischen Software und Umwelt und ist dabei in eine soziale Welt eingebunden. Kommunikation und Wissen sind seine Domänen. Um die Softwaregestaltung als Arbeitsprozess zu verstehen, hat Kapitel 5 gezeigt, dass sie und warum sie wesentlich auf Wissen und Kommunikation basiert. Das hat technologische (u.a. zeichenbasierte Technologie, mehrere technische Schichten, sprachliche Strukturierung u.a. durch Begriffe) und organisatorische Gründe (u.a. verstärkte Einbindung von Anwendenden). Es zeigt sich am historischen Wandel der Softwareentwicklung und ihrer Methoden über die Jahrzehnte hin zu einem in vielen Kontexten weitverzweigten, vernetzten, kollektiven Kommunikationsprozess. Die Mitarbeitenden an der Softwaregestaltung machen das, was der Computer nicht kann: Sie tragen ihr Wissen bei und kommunizieren. Das müssen sie tun, wenn sie die notwendige softwaretechnische Interdisziplinarität herstellen wollen. IT-Fach- leute wie Programmierende und fachliche Expert:innen wie Anwendende müssen sich austauschen. Dabei sind sie damit konfrontiert, dass Software unterschiedliche Schichten hat: Beispielsweise kennen die Programmierenden in erster Linie den Quellcode, während die Anwendenden die Bedienungsoberfläche der Software aus ihrer täglichen Arbeit kennen. Nicht jede:r hat die gleiche Perspektive auf die Software-Oberflächen bzw. spielt die Software die gleiche Rolle im Arbeitsalltag. Die Beteiligten der Softwaregestaltung haben unterschiedlichen Einblick in die Algorithmen, verstehen nicht alle Programmiersprachen oder das Gleiche unter softwaretechnischen Begriffen wie Softwarearchitektur, Schnittstelle oder Modell. In der Softwaregestaltung kann es dazu 74 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung kommen, dass es für jede Perspektive eigene Spezialist:innen gibt: für die Programmierung, Softwarearchitektur, Datenbanken, den Anwendungsbereich Prozessteil A der zu gestaltenden Software und jenen von Prozessteil B usw. Im Zuge der Softwaregestaltung kann Software einerseits keine Blackbox bleiben und andererseits kann sich nicht jeder intensiv mit ihrem Innenleben beschäftigen. Beides wirkt sich auf Kommunikation und Wissen in der Softwaregestaltung aus. So können Berechtigungsstrukturen, die den Zugang zur gesamten Software oder einzelne ihrer Funktionalitäten regeln, es erschweren, an das notwendige Wissen zu kommen, was in der Software steckt. Dann muss möglicherweise der/die Expert:in der Softwarefirma oder ein:e IT-Berater:in hinzugezogen werden. Zudem haben Beteiligte nicht immer die Möglichkeit, sich sämtliches Wissen über die Software und ihre Anwendung anzueignen, wenn sich die Software stetig verändert, der gewohnte Arbeitskontext sich durch eine neue Software oder ein Softwareupdate verändert hat oder die Software im Laufe der Zeit immer komplexer geworden ist. Software ändert sich oftmals stetig. Das Wissen über sie kann schnell veralten. Das liegt auch daran, dass eine Standardsoftware einen Lebenszyklus hat. Die anbietende Softwarefirma löst alte Versionen ab, ohne auf die Zustimmung sämtlicher Anwendenden zu warten. All das hat Folgen für den kommunikativen Austausch und Wissenstransfer: die verschiedenen Perspektiven und Wissensstände der Stakeholder:innen einer Software, welche Veränderungen durch wen überhaupt an der Software oder an der Organisation möglich sind, stetige Änderungen an der Software oder gar die Ablösung einer Software durch eine neue Version. Historisch betrachtet wurde es über die Jahrzehnte immer wichtiger zu berücksichtigen, dass Softwareentwicklung kein rein technisches Problem ist (vgl. Friedman/ Cornford 1989, Funken 2001, Boehm 2006). Statt sie wie Fließbandarbeit zu strukturieren, haben die Autoren des agilen Manifests 2001 einen Gegenentwurf zu dieser Arbeitsorganisation veröffentlicht (vgl. Beck et al. 2001). Das Forschungsfeld des Anforderungsmanagements der Informatik zeigt, dass Kooperation, Kommunikation und soziale Kompetenzen wichtig für die Softwareentwicklung sind. Sprache, Übersetzungsfähigkeit zwischen IT- und energiewirtschaftlichen Fachleuten, intensive Kommunikation und gar die Anwendung sozialwissenschaftlicher Methoden zur Anforderungsaufnahme stehen im Vordergrund (vgl. Alvarez 2002, Ross/Chiasson 2011, Kaminski 2012, Corvera Charaf/Rosenkranz/Holten 2013, Alsanoosy/Spichkova/Harland 2020). Diese Ergebnisse stellen eine erste Grundlage für den Arbeitsprozess der Softwaregestaltung dar. Doch berücksichtigen sie keine arbeits- und organisationssoziologische Literatur, die Softwareentwicklung in unterschiedlichen Kontexten untersucht. Eine kurze Aufarbeitung dieser Literatur konnte zeigen, dass es nicht die beste Methode oder Organisationsform für alle Fälle gibt. Stattdessen existieren lokale Praktiken und die Empirie zeigt unterschiedliche Organisationsformen der Softwareentwicklung. Ein allgemeines Konzept, um die Softwaregestaltung arbeitssoziologisch zu analysieren, wäre aber hilfreich. Die allgemeine Theorie der Softwareentwicklung ist der Versuch, ein solches allgemeines Konzept aufzustellen (vgl. Wohlin/Šmite/Moe 2015). Sie berücksichtigt die Kontextabhängigkeit von Softwareentwicklung und legt sich nicht auf bestimmte Organisationsstrukturen, Abläufe oder Managementmethoden fest. Indem sie aber organisationssoziologische und arbeitssoziologische Erkenntnisse unterschlägt, 6. Softwaregestaltung– konzeptionelle Grundlagen 81 fern es sich bei der Softwaregestaltung um eine besondere Form der Rationalisierung der Softwareanwendung handelt. Zugleich grenzt es diesen Ansatz von anderen ab, die das Verhältnis von IT und Arbeit beschreiben (z.B. jenen der Informatisierung). Die Forschung zu den Folgen von Standard-ERP-Software für die Softwareanwendung rezipiert der letzte Abschnitt. Allerdings lassen sich viele dieser Folgen entweder auf die Funktionalität der Software zurückführen oder darauf, dass es sich um eine fertige Standardsoftware handelt und weniger auf den Gestaltungsprozess. Das Kapitel zeigt zunächst Forschungslücken auf und wie sich die vorliegende Arbeit an die Diskussion über die Kontrolle von Wissensarbeit anschließt. Es untermauert, dass sich der Netzwerkbegriff besser eignet als jene von Markt oder Hierarchie, um zu beschreiben, wie der Arbeitsprozess der Softwaregestaltung die Arbeitskraft transformiert. Dann führt ein Abschnitt Forschungsarbeiten zu IT-Projekten an, denn IT-Projek- te sind Beispiele für soziotechnische Netzwerkarbeit, und auch sie ermöglichen auf den vier Ebenen die Transformation der Arbeitskraft. Danach betten mehrere Forschungsarbeiten konzeptionell ein, wie die Ebenen der organisationalen und interpersonalen Beziehungen, die Ebene der Software und der Softwaregestaltenden die Kontrolle von Softwaregestaltungsarbeit ermöglichen. Zuletzt geht es um das Verhältnis von Softwareanwendung und Softwaregestaltung. 6.1. Softwaregestaltung als Arbeitsprozess: Die Lösung desTransformationsproblems durchsoziotechnische Netzwerkarbeit Die Frage nach Kontrollformen, welche zu einer kooperativen Wissensarbeit wie der Softwaregestaltung passen, ist Gegenstand einer umfangreichen Diskussion in der Forschung. Laut Kalkowski/Mickler stoßen Hierarchien und formale Strukturen bei der Transformation von Arbeitskraft bei kooperativen Projekten an ihre Grenzen, weil sie zu wenig Handlungsspielraum zulassen (vgl. Kalkowski/Mickler 2015: 38). Um Softwaregestaltung zu organisieren, ist eine andere Form der Kontrolle notwendig: »[A] shift from behaviour control toward knowledge control; the goal of the latter is to elicit as much knowledge as possible from knowledgeable workers« (Rennstam 2012: 1072). Ob Adler/Borys (1996) Rede einer befähigenden (»enabling«) Formalisierung, Friedmans (1977) verantwortliche Autonomie oder die Diskussion über die Subjektivierung von Arbeit: In allen drei Fällen geht es darum, dass bestimmte Formen von Arbeit so zu organisieren sind, dass trotz Freiräumen die Beschäftigten zum Organisationszweck beitragen. Anders als in Bürokratien erwartet die Softwaregestaltung strukturbedingt von den Wissensarbeitenden – in diesem Fall den Softwaregestaltenden –, dass sie ihre Subjektivität einbringen. Subjektivität ist kein Störfaktor mehr wie im Taylorismus (vgl. Minssen 2017: 303). Betriebe haben »erhöhten funktionalen Bedarf an Subjektivität« (Minssen 2011: 119). Sie ist relevant geworden für die Rationalisierung (vgl. ebd. 118). Softwaregestaltende warten nicht auf detaillierte Anweisungen durch die Forgesetzten, sondern werden zu »›Mittätern‹ der Kontrollregime« (Schaupp 2021: 114). 82 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung Netzwerkformen wie Projekte oder Kooperationen zwischen Firmen zeichnen sich dadurch aus, dass sie diesen Raum für Subjektivierung bei gleichzeitiger Handlungsstrukturierung nutzen. In ihnen koexistieren verschiedene Kontrollformen nebeneinander. Sie sind Beispiele dafür, »how these coercive and dominant forms of control coexist and interact with the more enabling and knowledge-eliciting form[s]« (Rennstam 2012: 1086). Was eine besondere Herausforderung bei der Softwaregestaltung ist: Es geht um Wissensarbeit in team-, abteilungs- und organisationsübergreifenden Konstellationen. Die Forschung benennt die Verbindung von Arbeitsprozess und organisationalen Netzwerken in und zwischen Unternehmen als eine Forschungslücke: »In consequence, we do not only need more differentiated theoretical frameworks originating from the work of Gereffi4 and others but much more empirical studies that connect the level of the work process with the organizational level of corporate or inter-corporate relations.« (Sydow/Helfen 2020: 225) Zudem gibt es noch ein weiteres Forschungsdefizit in diesem Bereich: »Insgesamt handelt es sich bei diesen Zusammenhängen zwischen praktischer Kooperation, Netzwerkformen, Nutzung von IuK-Techniken, Wissenstransfer und Arbeit jedoch um ein wenig untersuchtes Gebiet, d.h. es besteht ein ausgeprägtes Forschungsdefizit.« (Schmiede 2006: 466) Das Konzept der soziotechnischen Netzwerkarbeit kann einen Beitrag dazu leisten, diese Forschungslücken konzeptionell zu schließen, wie die nächsten Kapitel zeigen. 6.2. Weder Markt noch Hierarchie: Netzwerke als analytische Grundlage Der Netzwerkbegriff eignet sich besonders gut, um die vielfältigen empirischen Begebenheiten der Softwaregestaltung in den Fallstudien zu beschreiben: Sie findet mal in Matrixorganisationen statt, mal in reinen Netzwerkorganisationen; mal dezentral in einem Team und mal zentralisiert in einem IT-DL, der mit mehreren EVU zusammenarbeitet. Der Netzwerkbegriff ist zudem anschlussfähig an die Forschung der letzten Jahrzehnte. Diese nutzt den Begriff, um Veränderungen in der Arbeitswelt zu beschreiben. Der Begriff der Vermarktlichung ist hier ungeeignet, da er ein anderes Kernphänomen adressiert, nämlich dass Firmen Marktmechanismen in ihrer Organisation nutzen (vgl. Sauer 2018). Der Begriff der Informatisierung beschreibt eine allgemeine Entwicklung und weniger, wie und warum Arbeit auf eine bestimmte Art und Weise organisiert ist, um Technik zu gestalten (vgl. Schmiede 2017). 4 Bekannt für seine Governance-Typen für Wertschöpfungsketten: market, modular, relational, captive, hierarchy (vgl. Gereffi/Humphrey/Sturgeon 2005). 6. Softwaregestaltung– konzeptionelle Grundlagen 83 Die Forschung zeigt, dass es unterschiedliche Gründe gibt, warum der Netzwerkbegriff nützlich für die Analyse der Softwaregestaltung ist: Es sind 1. theoretische (weder Markt noch Hierarchie), 2. organisatorische (vertikale Desintegration, Wissensgrenzen, Projektarbeit) und 3. Technische Gründe (Verbindung zwischen IT und organisatorischen Netzwerken). 6.2.1. Theoretisch: Netzwerke in Abgrenzung zu Markt und Hierarchie Seit mehr als 30 Jahren beschreiben Forschende eine sich von Märkten und Hierarchien unterscheidende Organisationsform (z.B. Williamson 1985, Powell 1990, siehe dazu Windeler/Wirth 2010). Allgemein wird eine Krise der vertikalen, bürokratischen Organisation und abgeschwächten Firmengrenzen konstatiert (vgl. Ahrne/Brunsson 2011). Theoretisch besteht ein weitreichender Konsens, dass mit Kategorien wie Markt oder Hierarchie allein nicht mehr sämtliche Organisationsformen beschrieben werden können. Was nun genau dieses fehlende Dritte sein soll, ist umstritten. Das fängt bei begrifflichen Fragen an: Zur Diskussion stehen u.a. die Begriffe Kooperation, Gemeinschaft, Clans, Netzwerke, langfristige Beziehungen. Auch darüber, wie diese Begriffe inhaltlich gefüllt werden sollen, besteht eine rege Diskussion. Bei Autor:innen wie Lamoreaux/Raft/Temin (2003), Bradach/Eccles (1989) oder Wiesenthal (2000) können die drei Organisationsformen kombiniert werden (und werden empirisch auch kombiniert). Der Netzwerk-Be- griff enthält für Ahrne/Brunsson (2011) keine organisatorischen Elemente: Es ist flexibel und spontan (vgl. ebd. 97). Die Beziehungen in Netzwerken sind nicht hierarchisch, sondern basieren auf Reziprozität, Vertrauen und sozialem Kapital (vgl. ebd. 88). Es gibt zudem keinen einheitlichen theoretischen Ansatz. Mehrere Forschungsarbeiten nutzen die Strukturationstheorie von Giddens (vgl. Windeler/Wirth 2010: 580ff., Longen 2015). Williamson (1985) verwendet die ökonomische Transaktionskostentheorie. Begrifflich hat sich die vorliegende Arbeit bereits für das »Netzwerk« als dritte Kategorie entschieden. Konzeptionell folgt diese Arbeit Powell (1990), Kalkowski/Micker (2015) und Sydow/Windeler (2000), die von Netzwerken als eigenständigen Organisationsformen ausgehen. Dabei sind Netzwerke nichts Eindimensionales. Für Sydow/ Windeler (2000), Apitzsch (2006) oder Kalkowski/Mickler (2015) bestehen Netzwerke aus mehreren Ebenen und Dimensionen. Wie in der Matrixorganisation können sich verschiedene Kontrollformen mischen. Für Apitzsch sind unterschiedliche Beziehungseigenschaften auf interpersoneller, organisationaler und interorganisationaler Ebene kombinierbar. Was an Inhalten ausgetauscht wird (bspw. Informationen), muss nicht mit einer bestimmten Beziehungsart (bspw. starke Formalisierung), Beziehungsbasis (bspw. Vertrauen) oder Intensität (bspw. stabil und längerfristig) einhergehen (vgl. Apitzsch 2006: 21f.). Bei Kalkowski/Mickler sind auf den Ebenen der organisationsübergreifenden Kooperationsstruktur, der Projektorganisation und des Kooperationsverhaltens auch verschiedene Kombinationen möglich, bspw. ein hierarchischer Kooperationstyp, eine schwach formalisierte Projektstruktur und regelmäßige Interaktionen (vgl. Kalkowski/Mickler 2015: 88). Bei der genaueren konzeptionellen Beschreibung der unterschiedlichen Ebenen des Netzwerks setzt die vorliegende Untersuchung auf eigene Kategorien. Denn andere Ansätze sind (noch) allgemein(er) und ihre Begrifflichkeiten helfen nicht, die Besonderhei- 84 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung ten der Softwaregestaltung zu erfassen. Es gibt sicherlich Anknüpfungspunkte mit dem oben genannten strukturationstheoretischen Ansatz von Giddens oder jenem allgemeinen Kooperationsbegriff von Kalkowski/Mickler (2015). Wie Giddens begreift Sydow und auch die vorliegende Arbeit Struktur und Handeln als rekursiven Zusammenhang. Allerdings ist der begriffliche Apparat (vgl. Giddens 1988, Kalkowski/Mickler 2015: 68ff.) nicht auf die Softwaregestaltung ausgerichtet5. Die in der Einleitung des Kapitels beschriebenen vier Ebenen der soziotechnischen Netzwerkarbeit eignen sich besser, um die Empirie des Arbeitsprozesses der Softwaregestaltung und seine spezifischen Probleme zu erfassen.6 Zudem spielt Technik bei den genannten Autoren keine wesentliche Rolle für die Netzwerkarbeit (nur z.B. zur Kontrolle der Projektarbeit, vgl. Kalkowski und Mickler 2015: 88). Ferner räumen sie, anders als die vorliegende Arbeit, Wissensarbeitenden und deren Rollen analytisch keinen zentralen Platz in Netzwerken ein. Bei Sydow/Windeler (2000) sind Individuen zwar eine Steuerungsebene (ebd.: 3f.), aber es bleibt unklar, was deren Beitrag zu den Netzwerkstrukturen ist. Als Rolle ist nur vom »boundary spanner7« die Rede (vgl. Sydow/Windeler 2000: 5, 10; auch Kalkowski/Mickler 2015: 74). Letztendlich sind die Ansätze zu wenig auf die Softwaregestaltung ausgerichtet, bei der Wissensarbeitende und IT eine zentrale Rolle spielen. 6.2.2. Organisatorisch: Netzwerke aus und in Organisationen Die Softwaregestaltung findet in einem organisatorischen Kontext statt, zu dem der Netzwerkbegriff passt, wie die nachfolgend zitierte Forschung zeigt: Erstens lagern immer mehr Organisationen (IT-)Tätigkeiten aus (vgl. Miozzo/Grimshaw 2005: 1421f., vgl. Flecker/Haidinger/Schönauer 2013, vgl. Howcroft/Richardson 2012: 124f., vgl. Puranam/Alexy/Reitzig 2014: 172f.). Dies führt zweitens dazu, dass statt klarer Hierarchien ein Spannungsverhältnis zwischen zentraler Steuerung und dezentraler Autonomie besteht (vgl. Hirsch-Kreinsen 1995). Wie die Fallstudien des Empirie-Kapitels zeigen werden, ist das typisch für die Softwaregestaltung. In Organisationsnetzwerken kann beides vorhanden sein: zentrale Vorgaben von Budgets und eine Selbststeuerung der 5 Bspw. ist die Unterscheidung zwischen zweckrationalem und kommunikativem Handeln (Kalkowski/Mickler 2015: 69) für die Softwaregestaltung schwierig. Die Softwaregestaltung verwendet Kommunikation instrumentell und es ist fragwürdig, ob es wirklich um Wahrhaftigkeit und Verständigung geht, wie es für kommunikatives Handeln gilt: »Rationalitätsmaßstab sei die Wahrhaftigkeit intentionaler Äußerungen und die Richtigkeit von Normen« (Vormbusch 2002: 107). Ausgiebig mit den Grenzen der Theorie von Habermas für die Anwendung auf die Softwaregestaltung hat sich Andelfinger (1997) auseinandergesetzt (sie wird trotzdem verwendet – z.B. Ross und Chiasson 2011). Aber auch die anderen Begriffe der Theorien (bspw. Sozialintegration vs. Systemintegration bei Giddens) sind zu weit weg vom empirischen Kern der Softwaregestaltung. 6 Wie sich die jeweiligen theoretischen Ansätze mit den empirischen Ergebnissen vertragen, wäre eine eigene Studie wert. Dies konnte die hier vorliegenden Arbeit nicht leisten – auch weil die empirischen Ergebnisse nicht so einfach in bestehende Theorien integrierbar sind bzw. die Softwaregestaltung ihre Eigenheiten hat, die sich nur mit eigenen Schwerpunktsetzungen in der konzeptionellen Begriffsbildung erfassen lassen. 7 Nach einer Definition handelt es sich bei »boundary spanners« um »vital individuals who facilitate the sharing of expertise by linking two or more groups of people separated by location, hierarchy, or function.« (Levina und Vaast 2005) 6. Softwaregestaltung– konzeptionelle Grundlagen 85 Anwendungsarbeit, weil Netzwerke den Arbeitsvollzug unbestimmt lassen und es so ermöglichen, dass Beschäftigte einen subjektiven Beitrag leisten (vgl. Schmiede 2006: 4). Aber es kann auch eine »Zentralisierung und Hierarchisierung von Unternehmensnetzwerken […] [und] asymmetrische Beherrschungsverhältnisse« (Apitzsch 2006: 10) bestehen, z.B. wenn die Softwarefirma den Standard setzt oder Einstellungsmöglichkeiten des Standards vorgibt. Drittens helfen Netzwerke, interdisziplinäre Wissensgrenzen zwischen Firmen oder innerhalb von Firmen zu überwinden. Kooperationen zwischen Firmen sind eine Form davon (vgl. Kalkowski/Mickler 2015). Erst in Netzwerken können abteilungs- und firmenübergreifende, interdisziplinäre Praxisgemeinschaften entstehen (»communities of practice« im Sinne von Wenger 1999), die für den Wissensaustausch notwendig sind: »Where practice doesn’t prepare the ground, knowledge is unlikely to flow« (Brown/ Duguid 2001: 207). Ein Beispiel für solche Praxisgemeinschaften sind Projekte. Sie sind als vierter Punkt, der aus organisatorischer Sicht für den Netzwerkbegriff spricht, zentral in der heutigen Arbeitswelt8. Für Apitzsch (2006) sind Projekte eine von mehreren Netzwerkformen. Mehrere Studien weisen darauf hin, dass immer mehr Mitarbeitende außerhalb von Linienaufgaben in Projekten arbeiten, und Scrum ist eine projektorientierte Arbeitsform, die diesen Trend verstärkt (vgl. Baudach 2018: 165). Castells (2001) sieht Projekte zentral für die Network Society an. Im Buch »Der neue Geist des Kapitalismus« haben Boltanski/Chiapello die Managementliteratur untersucht und herausgearbeitet, dass Projekte über die Jahrzehnte eine immer größere Rolle spielen. Sie beschreiben bereits, was sich bei der Einführung von SAP unter 6.3 zeigt: dass bei Projekten in Firmen »dauerhafte Verbindungen aufgebaut werden, die anschließend in den Hintergrund treten, aber weiter verfügbar bleiben« (Boltanski/Chiapello 2003: 149). Eine Studie zur Energiewirtschaft stellt fest, dass in den untersuchten Organisationen projektorientierte und vernetzte, temporäre Zusammenarbeit (Netzwerkorientierung) und Orientierung an der Kundschaft und Wettbewerbsfähigkeit (Marktorientierung) wichtiger wird und die Orientierung an Industrie (u.a. technische Effizienz) und Staatsbürgerlichkeit (u.a. Kollektivinteresse) abnimmt (vgl. Jacobsen/Blazejewski/Graf 2017). 6.2.3. Technisch: digitale Netzwerke Neben diesen theoretischen und organisatorischen Gründen verbinden einige Autoren mit dem Netzwerkbegriff eine zentrale Stellung der IT in der Arbeitswelt. Die Einleitung des Kapitels hat bereits Kruse als Beispiel dafür genannt, der bei IT-Arbeit 8 Projektarbeit ist in der modernen Arbeitswelt weit verbreitet. Wie weit, dazu konnte der Verfasser leider keine genaueren Statistiken zu durchgeführten Projekten in Firmen oder Branchen finden. Anfragen an privatwirtschaftliche Firmen, die Zertifikate wie IPMA, PRINCE2 oder PMP anbieten, blieben erfolglos. Allerdings finden sich online Informationen: In Deutschland haben 16.982 Personen ein gültiges Zertifikat Project Management Professional (PMP) (Quelle: https://www.pmi. org/certifications/certification-resources/registry, Stand: 04.01.2024).Ein Zertifikat der IPMA (International Project Management Association) der Kategorien A bis D haben von 1995 bis 2020 jährlich im Schnitt 14.456 Personen weltweit gemacht (Quelle:https://www.vzpm.ch/fileadmin/d okumente/downloads/Deutsch/IPMA_Yearbook_2020.pdf, heruntergeladen am 04.01.2024). 86 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung von Netzwerkarbeit spricht. Castells hat bereits 19969 in seinem Buch eine globale Netzwerkgesellschaft beschrieben, die auf Informationstechnologien beruht. Interorganisationale IT-Systeme vereinfachen ab den 1990er Jahren die Kommunikation zwischen den Organisationen, zentralisieren Kontrolle, machen Transparenz, Wissensaustausch und Entscheidungsdelegation (Dezentralisierung) technisch umsetzbar (vgl. Bjørn-Andersen/Raymond 2014: 190). IT macht das Auslagern bestimmter Tätigkeiten möglich (vgl. Grimshaw et al. 2002: 188, Robertson/Verona 2006: 90, Sahaym/Steensma/ Schilling 2007, Zammuto et al. 2007: 754ff.). Longen sieht einen Zusammenhang zwischen Firmen-Netzwerken der Call-Center-Arbeit und der verwendeten IT (Longen 2015). Auch beim Ansatz der systemischen Rationalisierung aus der Industrie- und Arbeitssoziologie spielt die IT eine zentrale Rolle in Organisationsnetzwerken. Sie sorgt für die »Optimierung des gesamtbetrieblichen Prozesses, die Organisierung von Markt- und Austauschprozessen und die Gestaltung der Beziehungen zwischen Betrieben und Unternehmen« (Sauer 2017: 286). Manche Autoren sehen gar Firmen als überflüssig an, weil potenziell jeder dank IT individuellen Zugang zu allen relevanten Informationen hat und jeder mit jedem kommunizieren kann (vgl. Symon 2000: 393). 6.3. Ein Beispiel für soziotechnische Netzwerkarbeit: IT-ProjekteinMatrixorganisationen Den Weg zu einem allgemeinen Konzept der soziotechnischen Netzwerkarbeit, das zu sämtlichen Fallstudien passt, weist IT-Projektearbeit. IT-Projekte sind auch deshalb relevant für die Untersuchung, weil sie Firmen bei der ERP-Einführungen einsetzen und es mehrere Forschungsarbeiten dazu gibt. Solche Projekte und die aus ihnen resultierenden Gestaltungsnetzwerke nach ERP-Einführung weisen die vier Ebenen soziotechnischer Netzwerkarbeit auf. Allgemein zeigen sich in Projekten die vier Ebenen wie folgt: 1. Ablauf – zwischen starker und schwacher Formalisierung: Projekte schwanken zwischen zu starker und zu schwacher Formalisierung (vgl. Heidling 2018: 224). Durch Handbücher für Aufbau- und Ablauforganisation eines Projektes, entsprechendes Management und entsprechende Kennzahlen kann eine Formalisierung stattfinden (vgl. Kalkowski und Mickler 2005: 59). Trotzdem lassen sie für einzelne Beschäftigte Spielräume, um selbstständig fachliche Entscheidungen zu treffen und sich bspw. mit Kund:innen abstimmen zu können (vgl. Kalkowski/Mickler 2005: 59). 2. Beziehungen – dank Projekt zwischen Organisationseinheiten und Einzelpersonen •Organisationale Beziehungen – Abteilungsgrenzen und Hierarchien überbrücken: Projekte überbrücken Grenzen aus Fachabteilung, Teams und Hierarchien in Organisationen, damit unterschiedliche »Spezialdisziplinen, Domänen, Wissensbereiche, Einzelpersonen« (Heidling 2018: 211) zusammenkommen können. 9 Auf Deutsch 2001. 6. Softwaregestaltung– konzeptionelle Grundlagen 87 Sie ermöglichen einen verbesserten Informationsfluss und Spezialist:innen können bspw. durch Mitarbeit an mehreren Projekten ausgelastet werden (vgl. Ford/Randolph 1992: 273). Die Arbeitsteilung hat in der Matrixorganisation mithin zwei Ebenen: die Arbeitsteilung zwischen den Fachabteilungen und ihren Hierarchien (Ablauf- und Aufbauorganisation) und die Arbeitsteilung im Projekt selbst. • Interpersonelle Beziehungen – auszuhandeln zwischen Führungskräften und Mitarbeitenden (horizontal und vertikal): Es gibt eine geteilte Autorität zwischen der Hierarchie der Organisation, in der das Projekt stattfindet, und dem Projekt selbst (vgl. Ford/Randolph 1992: 271). Es gibt Konflikte um Ressourcen, um Prioritäten, es gibt Rollenkonflikte zwischen Projekt-Rolle und Rolle in der Abteilung/im Team (vgl. Ford/Randolph 1992: 275). Die Projektleitung hat oftmals keine Weisungsbefugnis, diese liegt vielmehr bei der Team- oder Abteilungsleitung. Bei unternehmensübergreifenden Projekten findet ein Interessenausgleich und -abgleich durch Mitarbeitende und Projektleitung statt und ein großer Teil der Projektsteuerung erfolgt situativ auf operativer Ebene (vgl. Heidling 2018: 226). Kompromissfähigkeit, Verhandlungskompetenz, belastbare Vertrauensbeziehungen und personengebundener Austausch sind gefragt (vgl. ebd.: 227). 3. Software: Bei IT-Projekten sprechen Autoren von »technisch-bürokratischer Umklammerung der Projektarbeit« (Kalkowski/Mickler 2005) durch verschiedene Software-Werkzeuge wie Projektmanagement-Tools. 4. Wissensarbeitende – Erwartung, Handlungsorientierungen zu kombinieren: In Projekten ist Handeln stärker auf Kooperation und Kommunikation ausgelegt, bei gleichzeitiger ökonomischer und unternehmerischer Orientierung (vgl. Heidling 2018: 213f.). Es verschränken sich planmäßig rationales Handeln mit erfahrungsgeleitet-subjektivem (vgl. ebd. 222). Konkreter zeigen sich die vier Ebenen der Softwaregestaltung bei Projekten der Einführung von ERP-Standardsoftware. Dort passen Organisationen im Zuge der Implementierung den Standard an, nehmen Einstellungen vor oder erweitern ihn. Es findet Softwaregestaltung statt. Es gibt einige Forschungsarbeiten, die IT-Projekte zur Einführung von ERP-Software untersuchen (bspw. Light/Wagner 2006, Svejvig/Jensen 2013, Conrad 2017). Auch sonst spielen IT-Projekte in der IT-Arbeit eine Rolle: so beim Thema Internet of Things (IoT) (vgl. Ziegler 2020: 225, 259) oder bei Firmenkooperationen (vgl. Kalkowski/Mickler 2015: 221ff.). Hohlmann geht tiefergehend darauf ein, wie die Softwaregestaltung des ERP-Stan- dards von SAP über das Implementierungsprojekt hinaus organisiert ist: 1. Ablauf: Zum einen bestimmt das IT-Projekt zur Einführung der ERP-Software selbst den Ablauf. Zum anderen sind die während und danach existierenden Gestaltungsnetzwerke die Basis des Ablaufs, um abteilungsübergreifend zusammenzuarbeiten und die Standardsoftware anzupassen, einzustellen, zu erweitern (vgl. Hohlmann 2007: 353). 88 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung 2. Beziehungen jenseits bestehender Hierarchien und abteilungsübergreifend: Die Gestaltungsnetzwerke entstehen aus dem Projektteam der SAP-Einführung innerhalb der Firmen und untergraben alte Hierarchien. Es entstehen neue interdisziplinäre Netzwerke, wobei für deren Macht Wissen und Expertise entscheidend sind (vgl. ebd. 359f.). Die interdisziplinären Wissensbestände betreffen die anwendende Organisation, die fachlichen Prozesse und die ERP-Software selbst. Erst die drei Wissensbereiche zusammengenommen10 ermöglichen eine Anpassung der Software (vgl. ebd.: 55). 3. Software: Insgesamt sieht Hohlmann eine enge Kopplung (ebd. 34f.) von Software und Organisation. Sie spricht von einem eng gekoppelten soziotechnischen Gesamtsystem (ebd. 368), weil nicht nur das ERP-System für die Arbeit in den Organisationen zentral wird, sondern weil IT- und Fachwissen nun Hand in Hand gehen und die anwendenden Organisationen neue, softwarebezogene Rollen wie Key User:innen etablieren müssen (s.u.). 4. Wissensarbeitende: Die neue Qualifikation, zwischen System und Fachabteilung zu vermitteln, verkörpert exemplarisch die Rolle Key User:in, die sich dadurch von anderen Anwendenden abhebt (vgl. ebd. 348). Sie wendet eine Software nicht nur an. Sie nimmt darüber hinaus Einstellungen an ihr vor, gibt neue Anforderungen für die Software auf oder arbeitet direkt mit Programmierenden zusammen. Gleichzeitig kennt sie sich fachlich in Bezug auf einen konkreten Anwendungsbereich gut aus und arbeitet eng mit den Anwendenden zusammen. Key User:innen agieren als Übersetzer:innen, und indem sie an der Softwaregestaltung mitwirken, halten sie die Software auch bei veränderten Anforderungen durch die Umwelt der Organisation oder der Anwendenden einsatzfähig und die Organisation effizient (vgl. ebd. 340, 357, 370). Letztendlich zeigt sich, dass Organisationen mit einem ERP-System nicht nur ein neues Werkzeug in Betrieb nehmen. Langfristig ändert sich ihre interne Organisation, um diese Software zu gestalten. Damit beschreibt Hohlmann sowohl die Etablierung (via Projekt) als auch die Folgen von Softwaregestaltung: und zwar nicht nur für die Anwendenden, sondern auch jene Folge, dass in den anwendenden Organisationen neue Rollen, Gestaltungsnetzwerke und Wissensbestände entstehen. Um diese vier Ebenen allgemeiner zu fassen, erarbeitet der nächste Abschnitt eine konzeptionelle Beschreibung des Netzwerkes unabhängig von Matrixorganisation und Projektarbeit, um so den unterschiedlichen Konstellationen zu entsprechen, in denen die Softwaregestaltung in den Fallstudien stattfindet. 6.4. Soziotechnische Netzwerkarbeit: die Ebenen Beziehungen, Software undWissensarbeitende Die Matrixorganisation und IT-Projekte sind lediglich eine unter mehreren Möglichkeiten, Softwaregestaltung zu organisieren. Für einen allgemeinen konzeptionellen 10 Sie nennt die Kombination Integrationswissen. 6. Softwaregestaltung– konzeptionelle Grundlagen 89 Rahmen, der für alle Fallstudien gleichermaßen gilt, schlägt dieses Kapitel das Konzept der soziotechnischen Netzwerkarbeit vor. Dafür arbeitet der Abschnitt im Folgenden anhand von Forschungsergebnissen für die Netzwerkebenen Beziehung, Software und Softwaregestaltende heraus, wie sie zur Transformation der Arbeitskraft durch die Vermittlung von Handlung und Struktur und damit zur Kontrolle von Arbeit beitragen. Abschließend folgt eine Analyse einer spezifischen Eigenschaft von Netzwerkarbeit: dass die unterschiedlichen Ebenen flexibel und je Kontext unterschiedlich zur Transformation der Arbeitskraft beitragen. Für die konzeptionelle Ausarbeitung der Ebene Ablauf konnten keine nützlichen Bezüge in der Forschung gefunden werden. 6.4.1. Organisationale und interpersonelle Beziehungen Industriespezifische Softwaregestaltung findet zwischen Einzelpersonen, innerhalb oder zwischen Organisationseinheiten statt. Für die soziotechnische Netzwerkarbeit sind diese interpersonellen und organisationalen Beziehungen zentral. Einerseits setzt die soziotechnischen Netzwerkarbeit voraus, dass ein bestimmter Grad an Kooperation in den interpersonalen und organisationalen Beziehungen vorhanden ist. Andererseits ist es Teil der soziotechnischen Netzwerkarbeit, kooperative Beziehungen zu erhalten. Wann organisations- und abteilungsübergreifend kooperative Zusammenarbeit gelingt, was Voraussetzungen und Hindernisse sind, zeigen Forschungsarbeiten zur kooperativen Zusammenarbeit anhand von drei Punkten11: 1. Wenn IT-Abteilungen (ob in- oder outgesourced) mit den Fachabteilungen kooperativ zusammenarbeiten (6.4.1.1). 2. Wenn trotz unterschiedlicher Interessen und Wissen zwischen IT-DL, IT-Abteilung und anwendenden Organisationen Strukturen zur kooperativen Zusammenarbeit bestehen (6.4.1.2). 3. Wenn über formale Netzwerkstrukturen wie Projekte hinaus interpersonale Beziehungen bestehen, die auf Vertrauen, Reziprozität und Kooperation basieren, und zwar sowohl für gemeinsame strategische Entscheidungen als auch für die operative Zusammenarbeit (6.4.1.3). 6.4.1.1. Arbeitsteilung zwischen Anwendung und Entwicklung – die IT-Abteilung Wenn IT-Projekte in Unternehmen stattfinden, ist entweder eine IT-Abteilung oder ein IT-DL involviert. In den Fallstudien des Empirie-Kapitels ist das immer der Fall. Die Forschung weist darauf hin, dass eine IT-Abteilung nicht automatisch kooperativ mit 11 Phänomene, die eine Besonderheit der Wertschöpfungskette der Softwareentwicklung darstellen, aber auf die der in der Empirie untersuchten Softwaregestaltungsprozess keine direkte Auswirkung hatte, lässt die Untersuchung außen vor: so wie z.B. den Lock-in-Effekt durch die Implementierung einer Standardsoftware, d.h. eine starke Abhängigkeit vom softwareanbietenden Unternehmen (vgl. Hohlmann 2007: 334), aber auch den Lebenszyklus einer Software, der eine Abhängigkeit der Anwenderorganisation von der weiteren Wartung, von Updates und der Weiterentwicklung durch die Softwarefirma erzeugt. 90 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung den Fachbereichen zusammenarbeitet. Es gibt unterschiedliche Organisationsformen der IT-Abteilung – mal weniger und mal mehr hierarchisch oder marktförmig. Das Forschungsgebiet, das die Beziehung zwischen IT- und Fachbereich untersucht, nennt sich IT-Alignment. Dabei geht es nicht nur um die Entwicklung einer einzelnen Lösung, sondern um die Organisation einer ganzen IT-Landschaft, d.h. eine Vielzahl an Softwarepaketen und Hardware. Durch das IT-Alignment soll verhindert werden, dass IT-Lösungen »not effectively support organizational activities and are more prone to miss business innovation opportunities provided by new information technologies« (Valorinta 2011: 47) – ob intern oder ausgelagert. Auch in der Forschung zum IT-Alignment sind es nicht Märkte oder Hierarchien, welche die interdisziplinäre Zusammenarbeit zwischen IT und Fachbereichen dominieren sollten. Vielmehr sind für eine kooperative Zusammenarbeit ein regelmäßiger Austausch zwischen IT und Fachbereichen, Co-Loka- tion, gemeinsame Planung, gemeinsame Projekte und Bildung von sozialem Kapital hilfreich (vgl. Reich/Benbasat 2000, Chan/Reich 2007, Masak 2006 Schlosser et al. 2015).12 Dazu gehört, dass Führungskräfte wie Chief Information Officer (CIO) sowohl an Praktiken der eigenen IT-Einheit als auch an jenen der Fachbereiche teilnehmen (vgl. Valorinta 2011: 50). IT-Projektmanagende sind ein interdisziplinäres Bindeglied und es ist wichtig für den Erfolg von Projekten, dass sie über IT- und Fachwissen verfügen. Es ist vom hybriden IT-Projektmanagement die Rede: »[A] hybrid IT PM whose expertise includes technologies and techniques used on the project and who also possesses relevant knowledge of organizational operations, in-depth knowledge of the functioning of user departments, or expertise in the specific application area of the system« (Ko/Kirsch 2017: 318). Untersuchungen zeigen Fälle, in denen IT-Abteilungen die Kooperation erschweren oder nicht auf Kooperation ausgerichtet sind. Guillemette & Parè (2012) machen fünf verschiedene Typen aus, die unterschiedlich eng mit den Fachabteilung zusammenarbeiten. Statt auf langfristige Beziehungen zu setzen, die förderlich für den Wissensaustausch wären, entscheiden manche Firmen, ihre IT marktförmig zu organisieren. IT-Sourcing-Abteilungen prüfen dann stetig, was Firmen extern an IT-Arbeit einkaufen und was sie selber machen. Das betreiben die Firmen so intensiv, dass gar die Rede von der »Industrialisierung des IT Sourcings« (von Jouanne-Diedrich et al. 2005) ist. Dabei gibt es Forschung, die zeigt, dass, wenn Firmen komplexe IT-Wissensarbeit auslagern, sie dann in die interne IT-Organisation investieren müssen, damit die Zusammenarbeit funktionieren kann (vgl. Tiwana/Kim 2016). Erschweren können die Kooperation auch zentralisierte IT-Abteilungen, die zentral Kooperationen steuern wollen und so dezentralen Initiativen in Organisationen entgegenstehen. Alternativen dazu sind dezentralisiert oder föderal organisierte IT-Abteilungen (vgl. Sesay/Ramirez 2016). Laut Masak ist die IT in Firmen meist föderal organisiert (vgl. Masak 2006: 209) und somit 12 Eine Studie hat herausgefunden, dass es eine Kluft zwischen »talk« und »action« bei IT-Projekten gibt, was die Kommunikationsprozesse zwischen IT und anderen Abteilungen anbelangt. Auch wenn sie von der Projektmethode vorgesehen waren und Projektleitende sich öffentlich hinter die vorgesehenen Kommunikationsprozesse stellen, wurden sie nicht eingehalten (vgl. Monteiro de Carvalho 2013). 6. Softwaregestaltung– konzeptionelle Grundlagen 97 Anders als am Fließband gibt die Technik keinen festen Takt vor. Wenn sie es tut, dann durch soziale Organisationsformen wie Scrum, in denen es Sprints gibt, deren Zeiträumen durch Menschen festgelegt werden. Abfolge und Tempo sind dann aber nicht durch Technik vorgegeben, vor allem nicht, wie lange man für einen Arbeitsschritt (z.B. die Programmierung einer Methode) braucht. Die Menschen müssen priorisieren, Änderungen am Quellcode oder Tests freigeben. In zwei Fallstudien, die Barrett in ihrer Untersuchung erforscht hat, haben die Programmierenden ihre Zeit selbst in der Hand und nur die Deadline war direkt vom Management kontrolliert (vgl. Barrett 2005: 89). Statt wie ein Fließband schränkt 2. Software die Arbeit der Softwaregestaltenden anders ein: durch a) Vorgaben machen, b) Abläufe integrieren, c) soziale Strukturen softwaretechnisch zu stützen und d) Arbeit zu überwachen. Zu a): Software kontrolliert, indem sie vorgibt, wie ein Beitrag und welcher Beitrag zu leisten ist. Allgemein müssen Anwendende (auch von Werkzeugen für die Softwaregestaltung) die Programmlogik nachvollziehen und sich mit den von der Software erwarteten Verhaltensweisen auseinandersetzen (vgl. Degele 2000: 67f.). Sie müssen sich an die in Software fixierten Regeln halten (vgl. Heidenreich/Kirch/Mattes 2008: 7). Dabei kann Software zu einer erhöhten Rigidität der Formalisierung führen, indem sie Arbeitsschritte als alternativlos vorgibt, sie detaillierter und umfassender verregelt, vorstrukturiert und systematisiert (vgl. Schaeffer/Funken 2008: 13f.). So gibt sie z.B. über Eingabemasken vor, was Anwendende in ein Ticketsystem eingeben können, welche Mitarbeitende es bearbeiten und an welche Teams in der IT-Abteilung die Tickets weitergeleitet werden können. Zu b): Ganz allgemein ermöglicht IT eine Prozessorientierung sowohl im Unternehmensnetzwerk als auch in einer vermarktlichten Organisation (vgl. Sauer 2018: 196). Der oder die Einzelne und sein Input in die Software sind in einen digitalen Prozess eingebunden. Das muss aber nicht mit einer durchgetakteten, formalisierten Anwendung einhergehen. Bei komplexen Aufgaben formalisieren Unternehmen Zielparameter und erwarten von den Anwendenden Problemlösungen und strukturierende Arbeit, mit der sie die Lücke im digitalen Prozess füllen (vgl. Kleemann/Matuschek 2008). Neben der Vorgabe durch Software, wie Beschäftigte einen Beitrag und welchen Beitrag sie leisten können, macht IT (Hardware und Software) c) im Allgemeinen soziale Strukturen starrer (vgl. Mutch 2010). So fixieren die Benutzendenrollen in der Software die sozialen Rollen oder der Programmablauf von ERP-Software die Arbeitsroutinen softwaretechnisch. Das heißt, soziale Organisationselemente wie Rollen oder Routinen bekommen (software-)materielle Bestandteile (vgl. Volkoff et al. 2007: 840f.). Routinen und Rollen werden soziotechnisch: Sie existieren in der Software und der sozialen Organisation. Bei einer angepassten ERP-Standardsoftware für eine anwendende Organisation spricht Hohlmann von einer engen Kopplung (ebd. 34f.) von Software und Organisation und Brödner davon, dass diese wie »flüssiger Beton« (Brödner 2002 nach Remer 2008: 42) in der Organisation aushärtet. Software gibt nicht nur vor, wie Beschäftigte einen Beitrag leisten können, oder verwandelt soziale Strukturen wie Rollen in soziotechnische. Sie d) überwacht auch Arbeit. Bereits Zuboff (1988) hat vom »electric panopticum« gesprochen: Kontrolle kraft Transparenz. Die IT gilt seit längerem als Grundlage für Gruppen, Cost- und Profitcenter etc. Sie ermöglicht die Dezentralisierung durch Planungs-, Budget- und Kennziffernsyste- 98 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung me und die Kontrolle durch Rückmeldung (vgl. Kocyba 1999: 102f.). IT-Systeme können für das Management in Bezug auf Kontrolle das Gefühl einer kleinen Firma bewahren, indem sie eine zentrale Datenbank für die firmenweite Auswertung zur Verfügung stellen (vgl. Sahaym/Steensma/Schilling 2007: 867). Das gilt u.a. für die Produktion, weil die IT deren zentrale Steuerung möglich macht (vgl. Silva 2005: 50), wie auch für einen spanischen Energieversorger (vgl. Tsamenyi/Cullen/González 2006). Über Kennzahlen können Organisationen Teams kontrollieren und selbstständiges Arbeiten ermöglichen. Sie können »zu einer orientierenden und steuernden Instanz auch im Prozess der Selbstorganisation der Teams werden. Gleichzeitig vermitteln sie – im Sinne der systemischen Integration des gesamten Unternehmens – zwischen der Selbstorganisation in den Teams und der Ebene des (hierarchischen) Managements« (Boes et al. 2018: 186). Der Studie von Boes et al. (2018) kommt hier eine besondere Bedeutung zu, weil sie auch den Einsatz von Scrum berücksichtigt und zwei ihrer Fallstudien im Bereich Softwareentwicklung liegen. Die Überwachung durch Kennzahlen ermöglicht dabei die Selbstkontrolle des Teams und des Einzelnen. 6.4.2.2. Prägt die Organisation: die Softwarearchitektur Software ist nicht nur wichtig für die Kontrolle der Softwaregestaltung. Sie prägt durch ihre Architektur die Organisationsstruktur und damit die Transformation der Arbeitskraft. Es gibt eine bereits jahrzehntealte Diskussion über das Verhältnis von Organisation und Softwarearchitektur. Am bekanntesten ist Conways Law. In dem Aufsatz aus dem Jahr 1968 vertritt Conway, der sich allgemein mit »system design« von Technik beschäftigt, die folgende These: »The basic thesis of this article is that organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.« (Conway 1968: 31) Bezogen auf die Softwareentwicklung bedeutet das, dass man »in den Strukturen des Softwaresystems die Strukturen der jeweiligen Entwicklungsorganisation« (Masak 2006: 232) wiederfindet. Neuere Forschung zeigt, dass Conways Law bei der Softwareentwicklung nicht immer zutrifft. Zudem ist dafür, wer mit wem intensiv kommuniziert, nicht nur die Aufteilung der Software in Module oder Bausteine relevant wie bei Conways Law. Es geht auch um Abhängigkeiten, die entstehen, wenn Firmen oder Abteilungen gemeinsam Standardbausteine bzw. -module entwickeln. Inwiefern wirkt Conways Law bei Softwareentwicklung nicht immer? Unabhängig von Conway wird das Thema begrifflich unterschiedlich gefasst: das eine Mal als Modularisierung, ein anderes Mal als Spiegelung. Unabhängig davon, ob es sich um Software, Autos oder andere Maschinen handelt, stellt eine Metanalyse aus dem Jahr 2016 fest: 6. Softwaregestaltung– konzeptionelle Grundlagen 99 »Over two-thirds (70%) of the descriptive studies provide strong evidence of mirroring, 22% provide partial support, while only 8% do not support the hypothesis.« (Colfer/Baldwin 2016: 710) Das heißt also, dass sich bei 70% die technische Architektur in der Arbeitsteilung spiegelt. Das liegt daran, weil jene, die sich mit einem technischen Teil auskennen und Verantwortung dafür haben, sich irgendwie mit anderen absprechen müssen, um ihre Arbeit zu koordinieren (ebd. 712). »[O]rganizational ties will be dense within modules of the system where technical dependencies are dense and sparse across modules where technical dependencies by definition are sparse.« (ebd. 713) Die Autoren fanden aber auch heraus, dass offene, kollaborative Projekte im IT-Bereich die geringste Unterstützung für die Spiegelungshypothese aufweisen (ebd. 726). Sie führen drei Gründe auf, die alle darauf zurückzuführen sind, dass Software digital und damit leichter via Vernetzung und entsprechender Entwicklungsumgebung zu organisieren ist. Auch andere Untersuchungen stellen fest, dass es bei der Softwareentwicklung zur Spiegelung kommen kann, aber nicht muss. In einer Fallstudie zeigte sich am Anfang noch Conways Law: Eine Firma hatte Teile ihrer Softwareentwicklung ausgelagert. Weil die Kommunikation innerhalb der Teams besser war als zwischen den Teams, gab es je Team einen Quellcode, um den sich das Team gekümmert hat. So entwickelten sich entsprechend drei voneinander geschiedene Systeme (Insellösungen) heraus. Doch die Firma wollte dies unterbinden und es gelang ihr auch: Sie führte einheitliche agile Entwicklungsmethoden18 ein und es gab tägliche Videokonferenzen. So überwand die Firma die Barrieren in der Kommunikation zwischen den Teams, was sich dann auch in der Softwarearchitektur niederschlug. Auch wenn die Kommunikation innerhalb der Teams weiterhin intensiver war, konnte die Firma die Folgen davon auf die Architektur (Insellösungen) durch aktive Intervention und Etablierung informeller Kommunikation unterbinden (vgl. Hvatum/Kelly 2005: 3f.). In einem anderen Fall (der auch nicht Teil der Colfer/Baldwin-Studie ist) gelang dies nicht und es entstanden Insellösungen (vgl. Swan/ Scarbrough 2005: 932). Letztendlich zeigt dies, dass Software sich anders verhält als andere Technologien und bei ihr der Spielraum größer ist, zu intervenieren und die Spiegelung von Architektur und Kommunikationsstrukturen der Softwareentwicklung zu unterbinden. Zwei Autor:innen sprechen deshalb von Conways force (vgl. Hvatum/Kelly 2005), weil es weniger ein Gesetz als eine Kraft ist, welche das Verhältnis von Softwareentwicklung und -architektur in eine bestimmte Richtung tendieren lässt, es aber nicht determiniert. Bei der Architektur spielt für die vorliegende Arbeit aber nicht nur die Aufteilung einer Software in unterschiedliche Bausteine bzw. Module und entsprechende Schnittstellen eine Rolle. Es geht auch darum, ob Organisationen etwas individuell oder als 18 In diesem Fall: Extreme Programming. Eine iterative Methode der Softwareentwicklung, bei der es wichtiger ist, eine Anforderung umzusetzen, als einem formalisierten Vorgehen zu folgen. 100 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung Standard gestalten. Gestalten mehrere Organisationen oder Organisationseinheiten wie Abteilungen gemeinsam einen Standardsoftwarebaustein, entstehen Abhängigkeiten. Wenn alle mitgestalten wollen, muss ein Austausch darüber stattfinden, was der Standard können soll. In seiner Dissertation untersucht Remer die Umstellung einer Softwarearchitektur: Statt eines großen, monolithischen Systems will die Organisation viele kleine, über definierte Schnittstellen flexibel aufrufbare Bausteine programmieren19. Remer stellt fest, dass solche Architekturinnovationen Änderungen an eingespielten sozialen Beziehungen verlangen. So kann er zeigen, dass die Firma ein neues Gremium einrichten muss. Dies ist notwendig, weil Anforderungen an einen Baustein mit den unterschiedlichen Stakeholdern, die diesen Baustein nutzen, abzustimmen sind. Das ist eine Folge der Architektur: Die Fachbereiche der Firma können nicht mehr allein über ihre Software(teile) entscheiden (vgl. ebd. 145). Die Einführung einer auf flexible Bausteine setzenden Softwarearchitektur hat somit ihre Risiken, weil es zu komplexen organisationalen und technischen Abhängigkeiten kommen kann und es schwieriger wird, über diese den Überblick zu behalten (vgl. ebd. 168). Das heißt, hier spiegeln sich zwar einerseits die Kommunikationsstrukturen, weil bestimmte Teams für einen Baustein zuständig sind und sie programmieren. Andererseits gibt es auch keine Spiegelung, weil sich die Kommunikation für die Abstimmungen und um sich auf die Gestaltung eines (Standard-)Bausteins zu einigen, nicht in der Softwarearchitektur niederschlägt und z.B. deren modulare Aufteilung ändert So stehen die Organisationen bei der Softwaregestaltung eines Standards vor der Wahl: Statt für Abstimmungen aufwendige Kommunikationsstrukturen zu etablieren, lassen sich Abhängigkeiten reduzieren und eine flexible Architektur in Form einer »Lego- Logik« (vgl. Schmierl/Pfeiffer 2005) ermöglichen, wenn sich alle Beteiligten einem Standard-»Lego«-Baustein und seinen Schnittstellen unterordnen und sämtliche Kommunikation und sämtliches Wissen für diesen innerhalb eines Teams existiert. Eine gewisse Flexibilität im Zusammenspiel von organisationsspezifischer Praxis und softwaretechnischen Funktionen kann erhalten blieben, indem bspw. individuelle Einstellungen an einem Standardsoftware-Baustein möglich sind (vgl. Wolff et al. 1999: 303), wie es z.B. für ERP-Systeme typisch ist. Dann besteht keine Abhängigkeit, weil sich für die individuellen Einstellungen die anwendende Organisation nicht mit anderen abstimmen muss. Ob Conways Law bewusst zu unterbinden oder Abhängigkeiten bei Standardbausteinen zu managen: Für die soziotechnische Netzwerkarbeit ist die Softwarearchitektur entscheidend, weil sie die Organisation der Softwaregestaltung prägt (wie die Fallstudien zeigen werden). 6.4.3. Softwaregestaltende: Arbeiten zwischen Anwendung und Programmierung Ein weiteres zentrales Element der soziotechnischen Netzwerkarbeit sind die Wissensarbeitenden selbst. Sie sind entscheidend für das Verständnis der Fallstudien. Für die Arbeit und wie der Analyserahmen zeigt (siehe 8.1.3), fungiert das Konzept der Rolle allgemein als theoretisches Bindeglied zwischen Individuum und Organisation. Bei der so- 19 Die Firma hat auf Micro Services als Teil einer Service Oriented Architecture (SOA) umgestellt. 6. Softwaregestaltung– konzeptionelle Grundlagen 101 ziotechnischen Netzwerkarbeit sind Rollen dreifach strukturgebend: als Rollen im herkömmlich soziologischen Sinne, als Rollen speziell, um Netzwerke zu etablieren, und als spezifische Rollenerwartungen der Softwaregestaltung. Bevor der Abschnitt dies anhand von Forschungsliteratur zeigt, verortet der nächste Punkt die Softwaregestaltenden zwischen Anwendung und Programmierung in die allgemeine Diskussion zur Wissensarbeit und liefert einige Zahlen zu dieser Berufsgruppe. Die Forschung zur Rolle der Produktmanagenden in einer Softwarefirma verdeutlicht, wie Softwaregestaltende arbeiten und welche Erwartungen an sie bestehen. 6.4.3.1. Wissensarbeit Softwaregestaltung: Vermitteln zwischen Anwendung undProgrammierung Softwaregestaltung ist als Wissensarbeit eine Form von Dienstleistungsarbeit. 2021 arbeiteten in Deutschland 33,66 Mio. Beschäftigte im Dienstleistungssektor, davon 1,07 Mio. in der IT-Branche. Zudem beschäftigten 2020 19% aller Unternehmen in Deutschland IT-Fachkräfte.20 Die Zahlen zu einzelnen IT-Beschäftigtengruppen sind leider nicht so detailliert. Für die Softwaregestaltenden sind nur wenige vorhanden21. Tabelle 3: Veränderung der IT-Beschäftigten in drei Kategorien zwischen 2013 und 2022. Berufsgruppen IT 31.12.2012 30.06.2022 Differenz in% Informatik 201.678 291.905 90.227 +45% IT-Systemanalyse, Anwendungsberatung, IT-Vertrieb 135.194 218.601 83.407 +62% – ERP-Beratung 96.486 k.A.   IT-Netzwerktechnik, IT-Koordination, IT-Ad- ministration, IT-Organisation 138.139 198.914 60.775 +44% – IT-Projektleitung 22.734 k.A.   Softwareentwicklung und Programmierung 152.274 304.005 151.731 +100% Summe 627.285 1.013.425 386.140 +62% (Quelle: https://statistik.arbeitsagentur.de, abgerufen Februar 2023 und Zahlen von 2012 für ERP- Beratung und IT-Projektleitung von https://job-futuromat.iab.de, abgerufen Februar 2023) Für IT-Projektleitung und ERP-Beratung gibt es nur Daten für 2012. Es zeigt sich auf jeden Fall, dass sich in den letzten zehn Jahren die Anzahl der Programmierenden verdoppelt hat. Dass es über 100.000 ERP-Beratende, über 22.000 IT-Projektleitende und mehr als 300.000 Programmierende gibt, belegt, dass Organisationen permanent ihre 20 Vgl. https://www.destatis.de, abgerufen am 16.11.2022. 21 Es gibt zwar auch Kategorien wie »43413-102 – ERP-Anwendungsentwickler/in« in der Statistik der Arbeitsagentur. Allerdings fehlen dazu die Zahlen. Die Daten für die ERP-Berater:innen und IT-Projektleiter:innen für das Jahr 2012 wurden von der Webseite https://job-futuromat.iab.de des IAB kopiert. 102 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung Softwarelandschaften verändern. Diese Zahlen sind allerdings lediglich grobe Richtwerte, weil sich bspw. IT-Projektleitende nicht alle mit der Softwareentwicklung/-gestaltung beschäftigen. Zudem fehlen Rollen wie Product Owner:in, Scrum Master:in, Anforderungsmanagende, Anwendungs- oder Applikationsbetreuende oder Key User:in. Es ist auch wenig über deren Qualifikationsprofile, Karriereverläufe oder Arbeitsbedingungen bekannt (ob qualitativ oder quantitativ). Fest steht jedoch, dass sie, wenn sie in Nicht- IT-Unternehmen tätig sind, zu den indirekten Bereichen der Unternehmen gehören und somit die Produktion oder die Erbringung von Dienstleistungen unterstützen. Dort gilt es den technischen Fortschritt zu steuern und zu bewerten und Innovationen anzustoßen. Sie gehören zur steigenden Anzahl an Akademiker:innen in den Organisationen (vgl. Strulik 2017: 322). Als Höherqualifizierte ist deren zunehmende Zahl Teil der Polarisierung der Qualifikationsstruktur im Dienstleistungsbereich und Teil des Trends zur Höherqualifizierung in mittleren und höheren Dienstleistungsjobs (vgl. Overbeck 2017: 103ff.). Was zeichnet diese Wissensarbeit grundsätzlich aus? Arbeit mit Software ist erstens Arbeit mit Wissen, Informationen und Daten (für die Unterscheidung siehe Definition unter 3.1.1). Zweitens geht es darum, zwischen der eigenen Arbeit und ihrem Kontext wie Organisationsnetzwerk, Finanzzahlen bzw. IT-Budget und Software zu vermitteln. Drittens spielen die Erwartungen und der Umgang mit Erwartungen eine wichtige Rolle (vgl. Schmiede 2015: 49f., Boes und Kämpf 2017: 184, Baudach 2018: 71). Diese drei Elemente und noch für die Softwaregestaltung spezifischere finden sich bei der Rolle Produktmanager:in. Sie ist eine der wenigen softwaregestaltenden Rollen, zu denen es qualitative Forschungsarbeiten gibt. Es zeigt sich, was Organisationen von Softwaregestaltenden erwarten: interdisziplinär, kooperativ und kommunikativ arbeiten, Beziehung aufbauen und verschiedene Handlungsorientierungen kombinieren (wie es auch typisch für Projektarbeit ist, siehe 4.2). Wie für Arbeit in Netzwerken typisch, agieren Produktmanagende »als Gleiche unter Gleichen; sie können in ihrer Tätigkeit nicht auf Anweisungen zurückgreifen, sondern müssen Probleme im Diskurs lösen« (Bolte 2017a: 483). Die Rolle ist auf die Kooperation andere Beteiligter angewiesen und die meiste Arbeitszeit verbringt sie mit Kommunikation (vgl. Bolte 2017b: 488). Sie hat vielfältige externe und interne Beziehungen: mit der Kundschaft, kooperierenden Unternehmen, Abteilungen des eigenen Unternehmens wie Service, Vertrieb etc. (vgl. Bolte 2017a: 484). Zentral ist dabei der Austausch mit der Kundschaft und den Programmierenden (vgl. ebd. 489). Produktmanagende sind Mediator:innen, »die Brücke[n] zwischen den beiden Welten schlagen und Übersetzungsleistungen von der einen Welt in die anderen erbringen« (Weishaupt/Hösl 2017: 505). Es handelt sich um Interaktionsarbeit mit einer dialogisch-explorativen Vorgehensweise und einer gegenstands- und handlungsvermittelten Kommunikation (vgl. Bolte 2017b: 490). Damit ist das Arbeitshandeln erfahrungsgeleitet-subjektivierend und nicht nur planmäßig-rational (vgl. Weishaupt/Hösl 2017: 494). 6. Softwaregestaltung– konzeptionelle Grundlagen 103 Es geht um »wirkliches Verstehen des Problems durch Nachvollziehen, Hineinversetzen in die Position des Anderen und eine anerkennende, partnerschaftliche und empathische Beziehung zum Gegenüber« (Weishaupt/Hösl 2017: 505). Indem Produktmanagende die Aktivitäten mehrerer Abteilungen koordinieren, nehmen sie Planungs- und Managementaufgaben wahr (vgl. Bolte 2017b: 487). Zusätzlich dazu brauchen sie fundiertes fachliches Wissen über Inhalte und Möglichkeiten der Softwareentwicklung, Kenntnisse des eigenen Produkts und über die Anwendungssituation (vgl. Weishaupt/Hösl 2017: 501). Die Beschreibung der Rolle Produktmanager:in zeigt, wie zentral eine einzige Person für die Softwaregestaltung ist, indem sie Beziehungen knüpft und aufrechterhält; Wissen aneignet und einbringt; Anforderungen an die Software erstellt. Sie gewinnt und verarbeitet nicht nur Wissen, sondern ist Erzeuger:in und Träger:in von soziotechnischen Netzwerkstrukturen. Eine andere Studie geht auf die Grundlagen der Handlungsregulation von IT-Pro- jektleitenden, Beratenden und Customizer:innen in einem ERP-Einführungsprojekt ein. Sie bestätigt und ergänzt, was bereits oben zu softwaregestaltenden Wissensarbeitenden und Produktmanagenden geschrieben wurde: Sie müssen komplexe Aufgaben bearbeiten und große Informationsmengen sammeln, deuten und integrieren. Es wird Selbstmanagement und die Bereitschaft und Fähigkeit zu effektiver kooperativer Arbeit erwartet (vgl. Bläsche/Lappe 2006: 307). 6.4.3.2. Rollen der Softwaregestaltenden: erwartungsgeleitetes Handeln Analytisch gesehen verbinden sich in der Rolle Produktmanager:in drei strukturgebende Elemente von soziotechnischer Netzwerkarbeit: Es ist eine Rolle im herkömmlichen Sinne, eine Rolle, speziell um Netzwerke zu etablieren, und in ihr zeigen sich Rollenerwartungen, die für soziotechnische Netzwerkarbeit typisch sind. Damit ist das theoretische Konzept der Rolle Teil der Kontrollform soziotechnische Netzwerkarbeit. Weil Rollen in der Arbeitssoziologie bei der Kontrolle von Arbeit nicht im Fokus stehen, soll dieser Absatz kurz verdeutlichen, wie Kontrolle durch Rolle funktioniert. Softwaregestaltung als erwartete Subjektivität: Rollen, Subjektivierung undsubjektivierendesArbeitshandeln Was ist eine Rolle? Sie wird als Bündel an Erwartungen an die Träger einer Position definiert, die von Einzelnen unabhängig, sozialstrukturell verankert, von Normen geregelt und von Sanktionen beeinflusst sind (vgl. Griese 2002: 458). Dahrendorf hat Handelnde, die nicht dem Nutzenkalkül folgen, sondern gemäß einer Rolle handeln, als Homo sociologicus bezeichnet. Als solcher agiert jemand aber nicht automatisch. Die Rollenerwartungen sind nicht immer klar, ihre Einhaltung wird nicht immer überwacht. Es muss erst gelernt werden, wie die Rolle auszufüllen ist. Manchmal steht, was die soziale Norm verlangt, im Widerspruch zu dem, was die oder der Einzelne von sich aus tun will (vgl. Schimank 2010: 171). So muss zwischen dem (komplikationslosen) role-taking und der aktiven, interpretierenden Auseinandersetzung mit einer Rolle im role-making unterschieden werden (vgl. Schimank 2010: 67). Wie bereits unter 6.3 beim Thema IT-Pro- jektarbeit erwähnt, ist das Konzept der Rollenkonflikte für die Netzwerkarbeit relevant. 104 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung Denn in der Matrixorganisation kann eine Person mehrere Rollen haben: eine im Projekt und eine in seinem Team. Beide können miteinander in Konflikt geraten und der Einzelne muss diese Konflikte lösen (bspw. Zeit für das Team vs. Zeit für das Projekt). Warum sind Rollen in der Softwaregestaltung wichtig? Das kann ausgehend von der Forschung zur Arbeit in der Filmbranche gezeigt werden. Dort verlassen sich am Filmset ab dem ersten Moment die Projektmitglieder »on role expectations to guide relationships and tasks« (Bechky 2006: 14). Die Rolle (ob Regisseur, Kameramann etc.) ist auch deshalb so zentral, weil, anders als in einem technischen Kontext (z.B. am Fließband), der Beitrag der Technik zur organisatorischen Stabilität gering ist. Es ist mehr die erhöhte Sichtbarkeit des Einzelnen am Set, welche den Einzelnen unter Druck setzt, die Rollenerwartungen zu erfüllen (vgl. ebd.: 15). Was die Fallstudien im 8. Kapitel zeigen: Rollen sind immer angepasst an den jeweiligen Kontext und in Bezug zu den jeweiligen Kolleg:innen. Das zeigen auch die Rollen am Filmset, obwohl sie sehr klar und langfristig institutionalisiert sind. Es findet ein role-making statt: Sie werden gelernt, ausgearbeitet, ihre Umsetzung mit anderen verhandelt (vgl. ebd. 16f.). Wenn die Erwartungen an die Rollen bekannt sind (z.B. an Scrum Master:innen), erwartet jede beteiligte Person deren Einhaltung. Ist eine Rolle wie das oben beschriebene Produktmanagement erst einmal etabliert, geht sie ihrer Arbeit selbstständig nach. Eine Forschung zur Softwareentwicklung stützt diese Sichtweite: Es ist wichtig, Verantwortung klar zuzuordnen, passende Fachleute einzubeziehen oder die einzelne Person für unterstützende und helfende Rollen fit zu machen, statt zusätzlich technisches Wissen zu lernen (vgl. Waterson et al. 1997: 96f.). Neben diesen klaren, einzelnen Rollen sind für die Arbeit in soziotechnischen Netzwerken rollenunabhängige Erwartungen für die Handlungsorientierung wichtig. Wie bereits bei der Definition von Wissensarbeit und der Beschreibung der Produktmanager:in gezeigt, bestimmen die Arbeit 1. allgemeine Erwartungen an Wissensarbeitende (Subjektivität), 2. Erwartungen speziell für die Softwaregestaltenden und 3. Erwartungen, die sich situativ ergeben. Es bestehen 1. unabhängig von der konkreten Rolle im Netzwerk allgemeine Erwartungen an die Softwaregestaltenden, von deren Erfüllung die erfolgreiche Transformation der Arbeitskraft abhängt. Allgemein ist Wissensarbeit Teil der Subjektivierung der Arbeitswelt. Statt sich von den Eigenschaften einzelner Beschäftigter möglichst unabhängig zu machen wie im Taylorismus, werden bei der Subjektivierung »spezifische subjektive Eigenschaften und Fähigkeiten« (Minssen 2011: 120) im Arbeitsprozess genutzt. Es besteht die »Erwartung von Unternehmen, dass diese Fähigkeiten tatsächlich eingebracht werden« (ebd.: 119). In der Wissensarbeit wird nicht nur planmäßig-rationales Handeln erwartet. Gehandelt werden soll situativ, erfahrungsgeleitet-subjektivierend, dialogisch-interaktiv, entdeckend-explorativ und kooperativ. Technik soll als etwas »Lebendiges« betrachtet werden, wie Subjekte, auf die man sich einstellen kann (vgl. Böhle 2010: 160ff.). Es bestehen 2. neben diesen allgemeinen Erwartungen an Wissensarbeitende auch spezifische an jene, die Software gestalten. Kapitel 4 und 5 haben gezeigt, dass sie mit einer zeichenbasierten Technologie aus mehreren technischen Ebenen konfrontiert sind, auf die Anwendende und Entwickelnde unterschiedliche Perspektiven haben. Interdisziplinäres Arbeiten wird erwartet, bei dem Kommunikation und Wissen die wesentlichen 6. Softwaregestaltung– konzeptionelle Grundlagen 105 Arbeitsmittel sind. Kapitel 6 hat nun auch noch gezeigt, dass durch die große Bedeutung von Beziehungen, die über Hierarchien und Märkte hinausgehen, und der Technik selbst Erwartungen bestehen: sei es, Beziehungen herzustellen und zu pflegen oder sich auf die zu gestaltende Software einzulassen. Letzteres ist wichtig für die Analyse soziotechnischer Netzwerkarbeit, weil Erwartungen 3. erst situativ erkannt und abgeklärt werden müssen und die einzelne Person entscheiden muss, ob die Erwartungen Teil des eigenen Rollen-Sets werden. Das betrifft vor allem die technischen Erwartungen, wie sich mit der Software auseinanderzusetzen und sich auf sie einzulassen. Im technischen Umfeld wird bspw. IT-Affinität erwünscht. Aber wie weit diese geht, ob jemand Fehler analysiert oder sich selbstständig mithilfe der Software und deren Dokumentation einarbeitet, hängt vom Arbeitskontext und den dort vorhandenen Sanktionen, der Sozialisation und dem intrinsischen Wollen der einzelnen Person ab. Softwaregestaltung als Erfüllen multipler Erwartungen Es gibt fünf Erwartungen, die die Forschung vielfach untersucht und thematisiert hat und in denen sich die normative Handlungsorientierung in Bezug auf die soziotechnische Netzwerkarbeit zeigt: kooperativ sein, selbstständig arbeiten, sich (tiefergehender) auf Software einlassen, mit Nicht-Wissen umgehen lernen und sich in den organisationalen Netzwerken bewegen. Diese Erwartungen sind vergleichbar mit unkonkreten Aufgaben, die zu erledigen sind. Deren konkreter Inhalt und die Umsetzung müssen die Beschäftigten als Rollenträger selbst situationsabhängig bewerkstelligen. Netzwerkspezifische Erwartungen: Grenzen zu überbrücken und kooperativ zu sein Eine vielfach in der Literatur zu findende Rolle ist jene des Boundary Spanners, der Beziehungen stiftet (siehe auch Bolte 2017: 473ff., Williams 2002, Levina/Vaast 2005). Sie werden auch »brokers« genannt und sollen verschiedene Gruppen miteinander verbinden (vgl. Swan/Scarbrough 2005: 932ff.). Sie agieren in einem doppelten Handlungsrahmen aus Netzwerk einerseits und Unternehmen andererseits (vgl. Sydow/Windeler 2000: 5, auch Kalkowski/Mickler 2015: 74). Die Rolle des Boundary Spanners kann durch Outsourcing entstehen, um als Teil »neue[r] Verbindungs- und Koordinationsfunktionen und entsprechende[r] Arbeitsrollen« (Flecker/Holtgrewe 2008: 322) für die organisationsübergreifende Zusammenarbeit zu sorgen. Der Boundary Spanner hat die Aufgaben, das Unternehmensnetzwerk zu stabilisieren, Vertrauen zwischen kooperierenden Unternehmen trotz Abhängigkeit und Konkurrenz zu erhalten (vgl. Hirsch-Kreinsen 2002: 116) oder die Arbeit Einzelner zu einem Ganzen zu koordinieren (vgl. Heckscher 2015: 246ff.). Weil der direkte Einfluss der Hierarchie fehlt, agieren sie mittels Konsens, Beeinflussung, Verhandeln, Mediation etc., um Deals mit unterschiedlichen Parteien zu machen (vgl. Williams 2002: 117). Sie gewinnen ihre Macht dadurch, dass sie bestimmte Ressourcen über ihre Netzwerke aktivieren können. Im Zuge dessen werden auch Bedeutungen generiert und geteilt (vgl. Swan/Scarbrough 2005: 935). Hilfreich sind dabei interorganisationale Erfahrungen, transdisziplinäres Wissen und kognitive Fähigkeiten (vgl. ebd. 119). Es können im Sinne der Interdisziplinarität Leute sein, die zwischen IT und Geschäftsmodell vermitteln 106 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung (vgl. Miozzo und Grimshaw 2005: 1434). An oben genannte Produktmanagende oder auch an IT-Projektleitende werden solche Erwartungen gestellt. Wissensarbeitsspezifische Erwartung: selbstorganisiert zu arbeiten Teil der Arbeit in Netzwerken ist zudem, dass Führungskräfte eine andere Rolle spielen. Führungskräfte nehmen die Rolle von Unterstützenden der Wissensarbeitenden ein und werden »nahezu vollständig von ihrer klassischen hierarchischen Koordinations-, Steuerungs- und Kontrollfunktion entbunden« (Korge/Buck/Stolze (2016) nach Baudach 2018: 170). Durch Organisationsformen wie fremdorganisierte Selbstorganisation (vgl. Pongratz/Voß 1997: 212), Dezentralisierung (vgl. Hirsch-Kreinsen 1995) oder »marktgesteuerte Dezentralisierung« (Sauer 2018) werden nicht nur Aufgaben delegiert, sondern die Erwartung geschaffen, dass Mitarbeitende selbstorganisiert arbeiten. Damit gibt es Gemeinsamkeiten zwischen der Vermarktlichung innerhalb von Organisationen und den (Markt-)Beziehungen zwischen Firmen im Netzwerk (vgl. Sauer 2018: 193). Dabei ist je nach Position unterschiedlich, was dezentral das Team oder einzelne Mitarbeitende entscheiden: die Ausführung der Arbeit, ihre Überwachung, Design der Arbeit, Zuordnung von Ressourcen, Leistungsmanagement, Firmenstrategie (vgl. Lee/Edmondson 2017: 13) oder ökonomische Ziele (vgl. Hirsch-Kreinsen 1995: 425). Das betrifft speziell die Anwendung von Software, weil dort »mehr Entscheidungsspielräume und Verantwortlichkeiten auf der ausführenden Ebene« (Schulz-Schaeffer/Funken 2008: 20) existieren. Zur Erwartung, selbstorganisiert zu arbeiten, gehört, sich mit anderen abzustimmen, sich selbst managen zu können und die Fertigkeiten seiner Kolleg:innen zu kennen. Das zeigt das Beispiel der Gruppenarbeit. Sie macht Hierarchien unwichtiger, dezentralisiert Kompetenzen und bindet innerbetriebliche Positionen an individuelle Fähigkeiten und individualisiert sie dadurch (vgl. Minssen 1999: 207). Es bestehen Erwartungen, die auch sonst bei der Zusammenarbeit von Fachleuten bestehen: Kommunikation als Teil der Arbeit zu sehen und seine Kollegenschaft gut genug zu kennen, damit die Koordinierung in der Gruppe mittels Diskurs und Kommunikation erfolgen kann und nicht durch Bürokratie und Hierarchie (vgl. ebd.: 211). Wer was weiß und mit wem wie kommuniziert, ist wichtig zu wissen, weil keine festen, bürokratischen Verfahrensweisen mehr vorhanden sind (vgl. Kotlarsky/Van Fenema/Willcocks 2008: 4). Erst mit diesem Wissen kann eine Selbstorganisation/-koordination stattfinden. »Team members must be familiar enough with each other’s experiences, skills, and specialized knowledge to facilitate the emergence of expertise coordination processes« (Faraj/Sproull 2000: 1564). Für einige Arbeitende war die Umstellung auf Gruppenarbeit schwierig, weil es nicht zum Selbstverständnis passt, Kommunikation als Teil der Arbeit zu sehen, und Gruppenarbeit eher etwas ist, was man Angestellten zuschreibt (vgl. Minssen 1999: 215). Für die einzelnen Teammitglieder bedeutet das effektives Selbstmanagement und damit einen höheren Level an »psychological development and interpersonal skills« (Lee/Edmondson 2017: 18). 6. Softwaregestaltung– konzeptionelle Grundlagen 113 6.5.1. Softwaregestaltung – eine Form der Rationalisierung derSoftwareanwendung? Es gibt eine Diskussion über die unterschiedlichen Formen der Rationalisierung. Was zwischen Anwendung und Programmierung passiert, ist nicht Teil dieser Diskussion. Die vorliegende Arbeit argumentiert, dass das aber relevant für die Effizienz und die Kontrolle der Arbeit der Anwendenden ist. Statt eines Technikentwicklungsdeterminismus (oder Softwaregestaltung als Blackbox) geht die vorliegende Untersuchung davon aus, dass zwischen Anwendung und Programmierung eine Rationalisierung eigenständigen Typs stattfindet. Sie vertritt eine andere Auffassung als Baethge (1996): »Der Weg der Rationalisierung in den Dienstleistungsbereichen war nie und ist auch heute nach dem Siegeszug der Mikroelektronik in den Büros und Verwaltungen nicht [Herv. i.O.] in erster Linie eine Frage von Technikeinsatz und Technikgestaltung [Herv. i.O.], sondern von Organisation und Kommunikation [Herv. i.O.]. Dies haben wir mit der Kategorie der ›systemischen Rationalisierung‹ zu kennzeichnen versucht. Es wird in ähnlicher Weise von Rock/Ulrich/Witt (1990) mit ihrem Begriff der ›kommunikativen Rationalisierung‹ angezielt.« (ebd. 20) Im Kern der Untersuchung steht eine technikzentrierte Form der Rationalisierung der Dienstleistungsarbeit in den Firmen der Energiewirtschaft. Dabei ist die Technikgestaltung ein wesentliches Element der Rationalisierung, für die Kommunikation das zentrale Mittel ist (vor allem für den Wissensaustausch zwischen energiewirtschaftlichen Domänenexpert:innen und Programmierenden). Diese Kommunikationsprozesse selbst sind rationalisierbar – wie auch die Fallstudien im 8. Kapitel zeigen. Sie werden zu dem Zweck rationalisiert, die Softwaregestaltung zu verbessern. Die hier vorgestellte Rationalisierung durch Technik stellt eine Ergänzung zu der von Menz/Nies/Sauer (2019, alle folgenden Zitate S.189) aufgestellten Unterscheidung dreier Formen der Techniknutzung dar: • Arbeitskraftbezogene Strategien, »die direkt auf die Arbeitskraft und das sogenannte Transformationsproblem zielen«. • Innerbetriebliche und betriebsübergreifende Prozessrationalisierung (systemische Rationalisierung), bei denen »Prozesszusammenhänge, Friktionen an den Schnittstellen, die Koordination in verzweigten Wertschöpfungsketten etc.« im Fokus stehen. • »[R]ationalisierungsunabhängige Strategien des Technikeinsatzes, insbesondere Strategien der Kundenbindung und des Marketings, die i.d.R. nur mittelbar auf die Steuerung von Arbeit und die Autonomie der Beschäftigten wirken.« Software kann für all diese Maßnahmen entwickelt, eingesetzt und bestehende Software entsprechend angepasst werden. Die Gestaltung von Software stellt eine vierte Form dar. Es ist eine technikentwicklungsbezogene Strategie, die auf die Rationalisierung durch Technikgestaltung abzielt, und zwar der soziotechnischen Arbeitsgestaltung durch Softwaregestaltung. 114 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung Die sieben Fallstudien beschreiben unterschiedliche Varianten dieser Form der Rationalisierung. Dabei berücksichtigen die Fallstudien, dass es vom Anwendungsbereich abhängt, wie groß die Potenziale der softwarebasierten Rationalisierung sind. Wo die Kernarbeit auf reiner Datenverarbeitung basiert (Abrechnung, Handel etc.), gibt es mehr Möglichkeiten der Automatisierung oder Prozessintegration durch Software (siehe Kapitel 8). Ziel dieser Rationalisierung durch Softwaregestaltung ist es, je nach Anwendungskontext die Möglichkeiten der Softwaretechnik zwischen Standard- und individueller Software optimal zu nutzen. Die Arbeitsteilung in Organisationen und Wertschöpfungsketten verläuft aus dieser Perspektive nicht mehr nach Hand- und Kopfarbeit, sondern in den Kategorien von Softwareprogrammierung, -gestaltung und -anwendung. Das Verhältnis der beiden Arbeitsprozesse reicht dabei von einem evolutionären Wandel von anwendender Organisation und Standardsoftware (vgl. Hohlmann 2007: 342ff.) bis hin zur Disruption durch Start-ups in bestimmten Branchen, die von Anfang an softwareentwickelnde Organisationen sind. Letzteres stellt ein besonderes Verhältnis beider Arbeitsprozesse zueinander dar: den Primat der Softwareentwicklung. Eine Organisation gestaltet eine Software für einen Anwendungsbereich, um diesen möglichst effizient zu bewirtschaften. So ist sie auf den Technikentwicklungsprozess der Softwareentwicklung hin rationalisiert. Übrig bleib die Arbeit für Softwareanwendende, welche Software nicht erledigen kann (oder soll). 6.5.2. Unterschied zu Informatisierung und Informationsraum Softwaregestaltung in ihrem Verhältnis zur Softwareanwendung zu betrachten, unterscheidet sich von anderen Ansätzen wie jene von Informatisierung und Informationsraum. Es geht um die Informationsverarbeitung und nicht um allgemeine Folgen der Digitalisierung. Es geht um die Folgen des Verhältnisses der Arbeitsprozesse von Softwaregestaltung und Softwareanwendung. Bei der Informatisierung geht es um einen »soziale[n] Prozess der systematischen Erzeugung und Nutzung von Informationen, um daraus weitere Informationen erzeugen zu können« (Boes/Pfeiffer 2006: 22). Bei der soziotechnischen Arbeitsgestaltung der Softwareanwendung durch Softwaregestaltung steht hingegen die Informationsverarbeitung im Vordergrund. Softwaregestaltung ist die Erzeugung von informationsverarbeitender Software. Dabei hängen die Möglichkeiten der Softwareentwicklung davon ab, die abzubildenden Prozesse formalisieren zu können: »Die Detailsteuerung und Kontrolle der Arbeit hängen nicht nur von den technischen Möglichkeiten, sondern auch von der inhaltlichen, fachlichen und organisatorischen Gestalt der Arbeits- und Produktionsprozesse ab. Die Formalisierung der Arbeitsabläufe ist nicht Konsequenz, sondern Voraussetzung digitaler Durchsteuerung und Kontrolle.« (Nies/Menz/Sauer 2019: 187) Der Quelltext einer Software kann nur abbilden, was formal beschreibbar ist und die Programmierenden umsetzen können. Doch wie die Fallstudien zeigen werden, macht der 6. Softwaregestaltung– konzeptionelle Grundlagen 115 Fokus auf das Verhältnis von Softwaregestaltung und Softwareanwendung klar, dass es nicht nur um die Folgen der Formalisierung von Abläufen für eine softwareanwendende Organisation geht. Erstens macht es für anwendende Organisationen einen Unterschied, ob sie sich den formalen Abläufen einer Standardsoftware unterordnen oder ihre eigenen Abläufe formalisieren und in eine individuelle Software umsetzen. Zweitens kann im Zuge der Softwaregestaltung eine Software entstehen, die keine formalisierten Abläufe oder eine Detailsteuerung der Softwareanwendung verlangt. Es existiert keine Parallelität von softwaretechnisch-formaler Abbildung und organisatorisch-formalen Arbeitsabläufen in der Anwendung. Fortschreitende Softwarenutzung in einem Anwendungsbereich kann dazu führen, dass die Anwendenden weniger formalisiert arbeiten als vorher, weil sie komplexe Fälle lösen müssen, welche die Software nicht automatisiert verarbeiten kann. Die Software prozessiert tausendfach die formalisierten Abläufe im Hintergrund, ohne dass die Anwendenden eingreifen. Drittens ist, wie Hohlmann (2007) zeigt, stetig Softwaregestaltung notwendig, weil die Software zu wenig flexibel ist, als dass Anwendende mit ihr auf veränderte Anforderungen reagieren können (seien es neue Wünsche der Kundschaft, Ideen für effizientere Prozesse etc.). Da macht es dann einen Unterschied, ob die anwendende Organisation selbst fähig ist, die Software zu gestalten oder nicht. Es macht einen Unterschied, ob sich Software und Anwendung wechselseitig weiterentwickeln, und dies innerhalb einer Organisation oder in Abhängigkeit von einer Softwarefirma. Die genannten Punkte sollen noch einmal verdeutlichen, dass Softwaregestaltung weder ein rein technologiegetriebener (Programmierung) noch ein rein anwendungskontextgetriebener (Formalisierung von Arbeitsabläufen) Prozess ist. Softwaregestaltung ist der stetige Prozess, Bedarfe eines industriespezifischen Anwendungsbereichs mit den Möglichkeiten der Softwareentwicklung abzugleichen. Viele Möglichkeiten der Softwaregestaltung ergeben sich erst iterativ im Austausch zwischen Anwendung, Gestaltung und Programmierung. Anders als beim Konzept des Informationsraums von Boes et al. (2006) steht beim Verhältnis der Softwaregestaltung zur Softwareanwendung die Dynamik zwischen beiden Arbeitsprozessen im Fokus. Der Anwendungsbereich ist Gegenstand der Softwaregestaltung und ändert sich abhängig von den verwirklichten Möglichkeiten der Softwareentwicklung. Der Informationsraum hingegen ist nicht vorprogrammiert und ein »offener Raum, der sich erst durch das soziale Handeln seiner Nutzer konstituiert« (ebd. 24f.). Bei der Softwaregestaltung geht es hingegen um die Programmierung und welche Möglichkeiten der Softwaregestaltung zwischen Individual- und Standardsoftware Organisationen für einen Anwendungsbereich nutzen. Es geht, anders als beim Informationsraum, um die »programmierten und starren Informationssysteme« (Boes et al. 2020: 313). Die Fallstudien werden zeigen, dass Software und Arbeitsorganisation, anders als im folgenden Zitat, nicht als getrennt betrachtet werden: »Insgesamt zeigt sich sowohl in den mittelals auch in den höherqualifizierten Bereichen, wie die Kombination eines digitalen ›Raums der Produktion‹ mit Lean und agilen Methoden auf dem Shopfloor die Kopfarbeit neuen Formen der Industrialisierung zugänglich macht.« (Boes et al. 2018: 180). 116 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung Vielmehr geht es immer darum, via digitalen Raum eine Software zu gestalten, und wie das die anwendende Organisation verändert. Bereits im Kapitel zur Softwareentwicklung (5.2.3) hat sich gezeigt, dass Firmen die Möglichkeiten des Internets für die Softwareentwicklung sehr unterschiedlich nützen. Weniger die Kombination von Internet und Arbeitsmethoden steht im Fokus der vorliegenden Arbeit. Vielmehr ist es das Verhältnis von Gestaltung und Anwendung, in dem das Internet nur eine von vielen Möglichkeiten darstellt, die beim Abgleich von energiewirtschaftlichen Bedarfen und technischen Möglichkeiten eine Rolle spielen. So ist mit soziotechnischer Arbeitsgestaltung hier gemeint, dass sich Software, Arbeit und Organisation des Anwendungsbereichs durch Softwaregestaltung verändern. Die folgenden Kapitel arbeiten weiter heraus, welche Veränderungen sich auf die soziotechnische Arbeitsgestaltung zurückführen lassen und sich von den Folgen der reinen Software(funktionalität) unterscheiden. 6.5.3. Softwaregestaltung: inkrementell mehr Software indiversenAnwendungsbereichen Folgt daraus eine allgemeine These für den Wandel der Arbeitswelt? In einem Artikel aus dem Jahr 2011 sieht der Netscape-Gründer und Silicon-Valley-Investor Marc Andreessen (als Tech-Nerd und durch IT Reichgewordener) eine unaufhaltsame Durchdringung der Wirtschaft mit Software. »Software is eating the world.« (Andreessen 2011) Indizien sind für ihn die immer größer werdenden Softwarefirmen (Amazon, Google, Facebook, Spotify, Netflix, Pixar, LinkedIn) und die immer größere Rolle von Software in allen möglichen Industrien (er nennt die Logistik-Software von Walmart und die Betriebssoftware von E-Autos). Er konstatiert damit einen noch allgemeineren Trend, als ihn die Soziologie für die Digitalisierung feststellt: ob optimierte Überwachung und Verhaltenssteuerung (vgl. Zuboff 2018), gesteigerte Bedeutung der Distributivkraft (vgl. Pfeiffer 2021), neue Handlungsräume (vgl. Boes et al. 2016) oder allgegenwärtige Plattformen (vgl. Srnicek 2017, Staab 2019) – um nur eine Auswahl zu nennen. Die vorliegende Arbeit betrachtet a) Digitalisierung wie andere Autoren als inkrementellen soziotechnischen Wandel (vgl. Hirsch-Kreinsen 2020: 40ff.). Wobei Disruptionen durch Start-ups nicht ausgeschlossen sind. Sie finden aber auch inkrementell statt. Sie sind nur innovativer, weil sie die Möglichkeiten der Technologie ausschöpfen, indem sie dem Primat der Softwareentwicklung folgen. Zudem geht es b) um eine neue Arbeitsteilung zwischen Anwendung und Entwicklung. Die Untersuchung geht von drei Seiten einer Organisation und Wertschöpfung aus: die Software selbst, die Anwendung der Software und Softwareentwicklung – ob innerhalb einer Firma oder verteilt auf mehrere Organisationen. Damit geht es c) um die Technokratie an Softwareprogrammierenden und -gestaltenden und deren zunehmende (Gestaltungs-)Macht. Es geht also um soziotechnische Arbeitsgestaltung als inkrementellen Wandel hin zur Software als Basis von Organisation und Arbeit, getragen von einer Gruppe an Fachleuten und unterschiedlichen Formen des Arbeitsprozesses der Softwaregestaltung 6. Softwaregestaltung– konzeptionelle Grundlagen 117 als soziotechnische Netzwerkarbeit (und ermöglicht durch Breitband-Vernetzung, Fortschritte bei der Chipproduktion und mobilen Endgeräten). Damit folgt diese Arbeit anderen Forschenden, welche die Digitalisierung aus der Perspektive der Arbeit analysieren, mit ihrer je arbeitsweltspezifischen Ausprägung (vgl. Apitzsch et al. 2021: 20f.). Die Ansätze von Hirsch-Kreinsen (2020) und Apitzsch et al. (2021) diskutiert das Schlusskapitel noch einmal, wenn es um den Beitrag der vorliegenden Untersuchung zum Verständnis der digitalen Transformation geht. 6.5.4. Folgen von Standardsoftware für die Arbeitsgestaltung derSoftwareanwendung Was sagt aber nun die Forschung konkret zu der Frage, welchen Unterschied es macht, ob Organisationen eine individuelle oder eine Standardsoftware gestalten? Welche Folgen einer Software auf die anwendende Organisation und die Anwendenden sind darauf zurückzuführen, dass sie individuell gestaltet ist? Dazu konnte keine Forschung gefunden werden. Dagegen ist die Forschung zu Standard-ERP-Software üppig. Sie zeigt zweierlei: Erstens gibt es Veränderung in der Softwareanwendung, die nicht auf den Standardcharakter zurückzuführen sind. Zweitens gibt es Veränderungen, die sich daraus ergeben, dass die Softwareanwendung eine Standardlösung einsetzt. Bei diesen Folgen gilt es allerdings in der Mehrzahl um jene einer fertigen Software und nicht um die Folgen eines Gestaltungsprozesses. Zu den allgemeinen Folgen der Einführung von Standard-ERP-Lösungen, die nicht auf den Standardcharakter zurückgeführt werden können, gehören eine stärkere Automatisierung, standardisierte Arbeit und die Substitution von gering Qualifizierten durch höher Qualifizierte (vgl. Howcroft/Richardson 2012: 120). ERP-Systeme wirken allgemein disziplinierend auf Arbeit: durch Intensivierung, Arbeitsplatzabbau oder Integration jedes Arbeitsplatzes in ein IT-System (vgl. Dery et al. 2006: 207f.). Nach ihrer Einführung entstehen neue Tätigkeitsfelder, Berufsfelder und Abteilungen, die für die Koordination der Dateneingabe und -pflege zwischen allen involvierten Abteilungen wie IT, Logistik oder Einkauf zuständig sind (vgl. Walker 2016: 83f.). Die Zentralisierung des Managements durch ERP-Software kann das Problem mit sich bringen, dass z.B. dezentrale Mitarbeitende einer Organisation keine Lösungen erarbeiten können, weil das IT-System dafür zu unflexibel ist (vgl. Schwarz/Brock 1998: 76). Zu den im Absatz genannten Effekten kann aber auch eine individuell für eine Organisation entwickelte ERP-Software führen. Es gibt aber einige Folgen, die sich auf den Standardcharakter zurückführen lassen, auch wenn das Verhältnis zwischen Software und Organisation von Fall zu Fall unterschiedlich ist. Standardsoftwarepakete wie die von SAP, die viele Einstellungs- und Anpassungsmöglichkeiten bieten, werden für Mormann zum Bezugspunkt der Arbeitsgestaltung.: »Die standardisierte Software fungiert als Referenzobjekt, mit dessen Hilfe sowohl über die Anpassung der Software als auch über die Anpassung der Organisation etwas ausgesagt werden soll.« (Mormann 2016: 150) 118 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung Laut ihr re-modellieren anwendende Organisationen der Standardsoftware ihre Arbeitsabläufe. Nur bei größeren unternehmerischen Konflikten passen die Organisationen die Software stärker an. So geschehen in einem Fall, bei dem Beschäftigte verhindert haben, dass Standorte in puncto Kennzahlen einfach verglichen werden können (vgl. Mormann 2016: 222). Eine andere Autorin kommt zu dem Schluss, dass Standardsoftware dazu dienen kann, Reorganisation in der anwendenden Organisation durchzusetzen (vgl. Hohlmann 2007: 333). Eine weitere Untersuchung zeigt, dass mehrere Projektzyklen notwendig waren, um die bei der ersten Einführung bereits umgesetzten, großzügigen Anpassungen am Standard zu reduzieren und näher an den Standard der Software zu rücken (in diesem Fall geht es um das ERP-System von Oracle). Die ERP-Implementierung erscheint als wiederkehrende, andauernde Aushandlung (vgl. Svejvig/Jensen 2013). Die Anpassung der Organisation an den Standard schlägt sich in der Partizipation der Anwendenden nieder. Bei einer SAP-Einführung nahmen während des Einführungsprojekts die Mitarbeitenden lediglich am Training teil und durften die Anwendung testen. Gestalten durften sie nicht (vgl. Tsamenyi et al. 2006: 425f.). Andere Studien sprechen von »marginalizing the users« im Verlauf einer ERP-Implementierung (vgl. Lyytinen und Newman 2015). In anderen Fällen ist die Anpassung gescheitert. Die Firmen haben die Implementierung abgebrochen, weil die Software wichtige Anforderungen nicht erfüllen konnte. Das Fazit der Autoren dreier Fallstudien ist, dass Firmen Effizienzen nur gehoben haben, wenn ihre bestehenden Praktiken zur Software passten (vgl. Grant et al. 2006: 13). In einem anderen Projekt bedeutete die Implementierung einer Standardsoftware, dass die Implementierung die vorher schon bestehende fehlende Integration von Abteilungen fortgeschrieben hat. Damit hat die Organisation Ziele wie eine zentrale Koordination durch die ERP-Software nicht erreicht (vgl. Elbanna 2007). Andere Autoren und Autorinnen sehen, sobald die ERP-Software implementiert ist, die Möglichkeiten eines starken Wandels von Software und Organisation als begrenzt an. Sie sprechen von »flüssige[m] Beton« (Brödner 2002 nach Remer 2008: 42) oder »enger Kopplung« (Hohlmann 2007: 34f.). Ein gelieferter Standard gilt aufgrund des Lock-in-Effekts als innovationshemmend, weil er erschwert, die Softwarezulieferfirma zu wechseln (vgl. Hohlmann 2007: 334, Zhu und Zhou 2012). Haben sich viele Organisationen an eine Standardsoftware angepasst, ist eine Verlagerung von Arbeit zwischen diesen leichter. Das ist eine weitere Veränderung in der Anwendung, auf welche die Forschung hinweist: Aufgrund von Standardisierung von Aufgaben und Fertigkeiten durch die Standardsoftware sind diese einfacher von einem lokalen Kontext zu lösen und zu verlagern (vgl. Howcroft/ Richardson 2012: 124). Wer SAP in Firma X angewendet hat, kann es auch in Firma Y tun. Neben den Fragen der Anpassung und der Flexibilität von Organisationen bei und nach Einführung einer Standard-ERP-Software geht es um die Veränderungen innerhalb der anwendenden Organisation, die nichts mit der reinen ausführenden Anwendung zu tun haben. Hohlmann (2007) stellt fest, dass nach der Einführung von SAP Gestaltungsnetzwerke innerhalb von Organisationen entstehen. Sie sind dafür da, den Standard anpassen zu können (siehe 6.3). Letztendlich hat die Forschung vor allem untersucht, ob und wie sich eine Organisation einem fertigen Standardprodukt unterordnet. Nur Hohlmann geht ausführlich auf Strukturen ein, die dafür da sind, Software über die Implementierung hinaus zu ge- 6. Softwaregestaltung– konzeptionelle Grundlagen 119 stalten. Um solche Strukturen geht es auch beim Verhältnis von Softwaregestaltung und Softwareanwendung. Es geht um den Arbeitsprozess der Softwaregestaltung und weniger um dessen Produkt und wie es auf Arbeit und Organisation wirkt. Wenn es in den Fallstudien um Fragen von Partizipation, Reorganisation und Anpassbarkeit von Software geht, dann immer in Bezug auf eine noch zu gestaltende Individual- oder Standardsoftware. Es geht um den Arbeitsprozess der Softwaregestaltung und sein Verhältnis zum Arbeitsprozess der Softwareanwendung. Das kann dann auch einzelne Anwendungsbereiche in einem EVU betreffen und nicht gleich eine gesamte Organisation, wie dies bei der Einführung eines ERP-Systems wie jenem von SAP der Fall ist. 6.6. Zwischenfazit: Softwaregestaltung als soziotechnische Netzwerkarbeit undsoziotechnischeArbeitsgestaltung Das Kapitel hat Forschungsliteratur herangezogen, um die beiden Kernfragen der Arbeit konzeptionell einzubetten. Die erste Kernfrage nach der Kontrolle der Softwaregestaltung in unterschiedlichen Konstellationen adressiert das Konzept der soziotechnischen Netzwerkarbeit. Es stellt die konzeptionelle Lösung des Transformationsproblems im Arbeitsprozess der Softwaregestaltung dar. Für die zweite Kernfrage nach den Folgen der Softwaregestaltung für die Softwareanwendung konnte die Literatur nur dreierlei zeigen: (1.) Wie sich der Ansatz, die Folgen der Softwaregestaltung in ihrem Verhältnis zur Softwareanwendung zu untersuchen, von jenem der Informatisierung und des Informationsraums unterscheidet. (2.) Das Verhältnis von Softwaregestaltung und Softwareanwendung ist eines der Rationalisierung. (3.) Welche Folgen für die Softwareanwendung sich auf den Standardcharakter von Software zurückführen lassen. Die analytische Grundlage für die soziotechnische Netzwerkarbeit sind weder Markt noch Hierarchie, sondern das Netzwerk. Mit ihm lassen sich auf verschiedene Organisationen, Teams oder Abteilungen verteilte Arbeitsprozesse besser analysieren, bei denen Wissen, Kooperation und Software zentral sind. Der hier verwendete Netzwerkbegriff folgt Ansätzen von Sydow/Windeler (2000), Apitzsch (2006) und Kalkowski/ Mickler (2015), die Netzwerke als aus mehreren Ebenen bestehend auffassen. (IT-)Projekte sind Beispiele für soziotechnische Netzwerkarbeit, weil auch bei ihnen die vier Ebenen aus Ablauf, Beziehungen, Software und Wissensarbeitenden für die Kontrolle der Arbeit sorgen (Heidling 2018, Ford/Randolph 1992, Kalkowski/Mickler 2005). Hohlmann (2007) zeigt, wie nach ERP-Einführungsprojekten Gestaltungsnetzwerke innerhalb der anwendenden Organisationen entstehen. Es existieren Abläufe, um weiter abteilungsübergreifend zusammenzuarbeiten und die Standardsoftware anzupassen, einzustellen und zu erweitern. Die Beziehungen zwischen den einzelnen Beteiligten des Gestaltungsnetzwerks untergraben alte Hierarchien und sind interdisziplinär. Die Software in Form des ERP-Systems wird für die Arbeit in den Organisationen zentral und das Wissen über die Software geht nun Hand in Hand mit dem jeweiligen branchen- und organisationsspezifischen Fachwissen. Die Softwaregestaltenden vermitteln zwischen Software und Fachabteilung. So wenden z.B. Key User:innen Software nicht nur an, sondern nehmen darüber hinaus Einstellungen an ihr vor. 120 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung Softwaregestaltung findet aber nicht immer innerhalb von Organisation statt und es geht nicht immer darum, eine Standardsoftware anzupassen. Zudem wird nicht immer Projektarbeit als Methode eingesetzt (mittlerweile weit verbreitet: Scrum). Deshalb ging es im weiteren Verlauf des Kapitels darum, allgemein notwendige Bedingungen der Kontrolle von Softwaregestaltung für drei der vier Ebenen der soziotechnischen Netzwerkarbeit herauszuarbeiten: Beziehungen, Software und Softwaregestaltende. Für die Ebene des Ablaufs wurden neben der Literatur zu IT-Projektarbeit keine theoretischen, passenden Bezüge gefunden. Soziotechnische Netzwerkarbeit basiert unabhängig von der jeweiligen Konstellation auf kooperativen Beziehungen, die aber u.a. aufgrund von Marktbeziehungen, Hierarchien und Abteilungsgrenzen nicht selbstverständlich sind. Die Forschung zeigt, dass eine IT-Abteilung nicht automatisch kooperativ mit den Fachbereichen zusammenarbeitet. Regelmäßige Kooperation, Kommunikation und interdisziplinäres Wissen auf beiden Seiten sind Voraussetzungen dafür (vgl. Reich/Benbasat 2000, Chan/Reich 2007, Masak 2006, Schlosser et al. 2015, Valorinta 2011, Ko/Kirsch 2017). Je nach Organisationsformen der IT-Abteilung arbeitet diese mehr oder weniger eng mit den Fachabteilungen zusammen (vgl. Guillemette & Parè: 2012), ist sie mal mehr und mal weniger hierarchisch und zentralisiert (vgl. Sesay/Ramirez 2016, vgl. Masak 2006: 209) oder marktförmig (von Jouanne-Diedrich et al. 2005) organisiert. Dabei gibt es Forschung, die zeigt, dass Unternehmen, die komplexe IT-Wissensarbeit auslagern, dennoch in die interne IT-Orga- nisation investieren müssen, damit die Zusammenarbeit funktioniert (vgl. Tiwana/Kim 2016). Die soziotechnische Netzwerkarbeit muss mit unterschiedlichen Interessen und ungleicher Wissensverteilung und den daraus resultierenden Konflikten zurechtkommen. Ungleichgewichte entstehen u.a. dadurch, weil es bei der Auslagerung von IT-Arbeit in der auslagernden Organisation zu Kompetenzverlust, Kontrollverlust, einem Abbau des organisationalen Lernens oder der Innovationskapazitäten kommt (vgl. Miozzo/ Grimshaw 2005: 1424). Es kommt zur Machtverschiebung zu IT-DL (vgl. Peled 2001, Flecker/Holtgrewe 2008: 314). Es kann zu Machtkämpfen zwischen IT-Dienstleistenden und den Auftraggebenden bzw. der Konzernzentrale kommen (vgl. Mezihorak 2018: 825ff.). Auch dann, wenn sie über weniger Wissen verfügen, müssen anwendende Unternehmen Wege finden, externe IT-Organisationen zu kontrollieren (vgl. Kaniadakis 2012: 270). Auch aufgrund der unterschiedlichen Konstellationen und Konflikte kann es für die Zusammenarbeitet von Organisationen unterschiedliche Steuerungsformen geben (vgl. Helfen/Wirth 2020: 14ff.). Die Forschung weist darauf hin, dass sie durch Lernprozesse entstehen, wofür Kapazitäten zum Wissensaustausch zwischen Firmen notwendig sind (vgl. Mola et al. 2017: 1293, vgl. van Fenema/Keers/Zijm 2014: 205). Auch innerhalb von Firmen kann es zu Machtkämpfen zwischen interner IT und Fachabteilungen kommen (vgl. Symon 2000: 400ff.). Dabei hat die IT-Abteilung eigene Machtquellen (vgl. Silva 2005: 56). Aber letztendlich bietet die Einführung und Entwicklung von Software für alle Beteiligten Möglichkeiten zur Mikropolitik (vgl. Ortmann et al. 1990). Nicht nur die Beziehungen zwischen Organisationen sind Teil der soziotechnischen Netzwerkarbeit. Auch jene zwischen Personen sind es. Sie sind entscheidend, weil für die kooperative Zusammenarbeit in einem Netzwerk z.B. Projektstrukturen allein nicht aus- 6. Softwaregestaltung– konzeptionelle Grundlagen 121 reichen. Kooperationsbereitschaft, Sozialkompetenz, breit verankerte Verantwortungsbereitschaft und verändertes Führungsselbstverständnis/-verhalten müssen vorhanden sein (vgl. Rüegg-Stürm/Young 2001). Bolte und Porschen nennen Methoden, um informelle Strukturen der Kooperationen im Arbeitsalltag zu etablieren: Job Rotation, Hospitation, Promotoren oder Trainee-Programme für Einsteiger:innen (vgl. Bolte/Porschen 2007). Zudem ist es wichtig, dass langfristige Beziehungen bestehen, weil Vertrauen erst mit der Zeit aus reziproken Beziehungen und durch geteilte Interessen entsteht (vgl. Powell 1990, Uzzi 1997). Dabei ist das in Kooperationsnetzwerken schwierig: Denn es besteht in ihnen generell ein geringes Vertrauen und eine geringe Loyalität (vgl. Grimshaw et al. 2002: 200, Brinkmann/Dörre 2006: 139, Howcroft/Richardson 2012: 122, Holtgrewe 2014: 17ff.). Schnell entsteht Misstrauen und Wissen wird nicht mehr geteilt (vgl. Hirschfeld 2000: 277, 268) – insbesondere bei marktförmigen Beziehungen (vgl. Felin/Zenger/ Tomsik 2009: 557). Software beschränkt ihre Kontrolle in der soziotechnischen Netzwerkarbeit nicht auf Standardisierung, Formalisierung und Überwachung. Vielmehr ist bei der Softwaregestaltung ihre koordinierende, kooperationsermöglichende und wissensaktivierende Funktion charakteristisch. Software verlangt von den Anwendenden wissensevozierendes Engagement und Interaktion (vgl. Darr 2019, Rennstam 2012). Zudem koordiniert sie als gemeinsam gestaltbares, textbasiertes Bezugsobjekt die Wissensarbeit (vgl. Nicolini/ Mengis/Swan 2012, vgl. Barrett/Oborn 2010, Carugati et al. 2018, Ponte/Rossi/Zamarian 2009, Bolici/Howison/Crowston 2009, 2016). Technische Kontrolle im Sinne Edwards (1981) ist bei der Softwaregestaltung sekundär. Literatur zur Softwareentwicklung zeigt, was auch für die Softwaregestaltung gilt: Menschliche Interventionen machen den digitalen Arbeitsprozess aus (vgl. Andrews et al. 2005, Barrett 2005). Gleichzeitig schränkt Software die Handlungsmöglichkeiten ein. Anwendende müssen der Programmlogik folgen (vgl. Degele 2000: 67f.) und sich an die in der Software fixierten Regeln halten (vgl. Heidenreich/Kirch/Mattes 2008: 7). Sie kann Arbeitsschritte als alternativlos vergeben, sie detaillierter und umfassender verregeln, vorstrukturieren und systematisieren (vgl. Schaeffer/Funken 2008: 13f.). Zudem verfestigt Software soziale Strukturen wie Rollen oder Routinen soziotechnisch, indem sie diese in Software abbildet (vgl. Mutch 2010, Volkoff et al. 2007). Sie gliedert den Einzelnen in einen Prozess ein (vgl. Sauer 2018: 196). Wobei es dann nicht immer nur um einfachen Input gehen muss, sondern auch darum, komplexere Aufgaben zu erledigen (vgl. Kleemann/Matuschek 2008). Zuletzt kontrolliert Software durch Transparenz: ob durch Zuboffs »electric panopticum« (1988), die organisationale Dezentralisierung durch die zentrale Steuerung dezentraler Einheiten via Kennziffern (vgl. Kocyba 1999) oder die Teamsteuerung über Kennzahlen (vgl. Boes et al. 2018). Software ist aber nicht nur aufgrund ihrer Bedeutung für die Kontrolle eine der vier Ebenen der soziotechnischen Netzwerkarbeit. Zusätzlich prägt die Software die Kommunikation. Theoretischer Ausgangspunkt dabei ist Conways Law (1968), laut dem sich organisationale Kommunikationsstrukturen in der Software spiegeln. Neue Literatur weist darauf hin, dass es bei der Softwaregestaltung umgangen werden kann und trotzdem noch prägend ist (vgl. Colfer/Baldwin 2016, Hvatum/Kelly 2005). Das betrifft jedoch die Aufteilung einer Software z.B. in Module. Abgesehen davon können Abhängigkeiten, die durch den softwaretechnischen Zuschnitt entstehen, die Kommunikation prägen. 122 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung Wenn z.B. mehrere Teams mit einem gemeinsam genutzten (Standard-)Softwarebaustein arbeiten, müssen sie sich für die Gestaltung dieses Bausteins abstimmen (vgl. Remer 2008). Die vierte Ebene des Netzwerks sind die Softwaregestaltenden, die zwischen Anwendung und Programmierung tätig sind. Als Wissensarbeitende sind die Softwaregestaltenden Teil der zunehmenden Zahl an höherqualifizierten Dienstleistungsarbeitenden in mittleren und höheren Dienstleistungsjobs, die zur Polarisierung der Qualifikationsstruktur beitragen (vgl. Overbeck 2017). Sie sind Träger der soziotechnischen Netzwerkarbeit, indem sie rollenbasiert Erwartungen erfüllen (vgl. Bechky 2006, vgl. Schimank 2010). Allgemeine Erwartungen unabhängig von spezifischen Rollen wie IT-Projektleitung oder Anforderungsmanagende sind: kooperativ zu sein (vgl. Williams 2002), selbstorganisiert zu arbeiten (vgl. Pongratz/Voß 1997, Sauer 2018, Lee/Edmondson 2017, Minssen 1999, Faraj/Sproull), aktiv mit Softwareobjekten zu interagieren und sich ausgehend von ihnen zu koordinieren (vgl. Rennstam 2012, Koblauch 1996, Zuboff 1988, Conrad 2012), mit Nicht-Wissen umgehen zu können (Schmiede 2006, Wilke 1998, Schulz-Schaeffer 1999) und sich im Netzwerk zu bewegen (vgl. Hohlmann 2007, Flecker/Holtgrewe 2008, Funken/Stoll/Hörlin 2011). Subjektivierung (vgl. Minssen 2011) und subjektivierendes Arbeitshandeln (vgl. Böhle 2010, Bolte 2017a, Bolte 2017b, Weishaupt/Hösl 2017) sind Kernbestandteile der Kontrolle ihrer Arbeitskraft. Softwaregestaltende sind eine Gruppe, die versucht, Einfluss in einer Organisation zu gewinnen. Sie helfen, Kernprobleme des Kapitals (wie z.B. die Kontrolle von Arbeit) zu lösen, und können deshalb eine bestimmte Position für sich beanspruchen (vgl. Armstrong 1985). Ihre Position ergibt sich technikinduziert, weil sie notwendig sind, um die Software-Technologie einzusetzen, wie bspw. die Rolle von Key User:innen (vgl. Hohlmann 2007). Das empirische Kapitel wird zeigen, ob sie und ihre Qualifikationen tatsächlich Teil des Managements sind, welchen Teil des Managements sie ersetzen oder mit welchem Teil des Managements sie konkurrieren. Die Ebenen und ihre Dimensionen der soziotechnischen Netzwerkarbeit zur Softwaregestaltung zwischen Anwendung und Programmierung im Überblick: Tabelle 4: Ebenen und Dimensionen der soziotechnischen Netzwerkarbeit Ebene Dimension Situativ Verhältnis von formalen und informellen Arbeitsschritten etablierenAblauf Gestaltungsnetzwerke und deren Rollen und interdisziplinäres Wissen einbeziehen Kooperative Beziehung zw. IT-Abteilung/-Dienstleistungsfirma und Fachabteilungen Organisationsübergreifende Steuerungsstrukturen und kooperativer Umgang mit Interessengegensätzen und ungleichen Wissensständen Beziehung Interpersonale Beziehungen basierend auf Vertrauen, Reziprozität, Kooperation 7. Industriespezifische Aspekte der Softwaregestaltung inder Energiewirtschaft 129 Netz und Vertrieb diskriminierungsfrei zugänglich sein müssen (bspw. Zählerstände). Rechnerisch ist ein Unternehmen entflechtet, wenn es die Bilanzen nach Geschäftsfeld getrennt aufführt (z.B. Netz und Vertrieb). Bei der operationalen Entflechtung geht es vor allem um die personelle Trennung auf Leitungsebene (vgl. Bräunig 2012: 426f.). Die Entflechtung kann durch unterschiedliche Organisationsmodelle wie Holding oder Tochter-/Muttergesellschaften umgesetzt werden (vgl. Bräunig 2012: 432). Die Entflechtungspflicht gilt nicht für EVU mit weniger als 100.000 Kund:innen (vgl. §7 Abs.2 EnWG bzw. §7a Abs.7 EnWG). Dies hat zur Folge, dass kleine Stadtwerke integrierte Betriebe bleiben. Als zusätzlich zu entflechtende Marktrollen kamen 2005 der Messstellenbetrieb und mit dem Digitalisierungsgesetz von 2016 der Smart Meter Gateway Administrator dazu (der das Zähler-Datenmanagement übernimmt). Die organisatorische Besonderheit kommunaler Unternehmen ist, dass es sich oft um Querverbundunternehmen handelt. 2009 bewirtschafteten 42% der VKU-Unterneh- men neben Strom mindestens noch eine weitere Sparte wie Wasser, Gas, Wärme oder Entsorgung. Strom allein bieten nur 16 von 1369 VKU-Mitgliedern an (vgl. Gottschalk 2012: 58). Das alleinstehende Stromlieferunternehmen oder der alleinstehende Netzbetrieb sind also selten. Das mittelgroße Stadtwerk von Heidelberg hat zum Beispiel neun Gesellschaften im Konzern: Stadtwerke Heidelberg Bäder, Stadtwerke Heidelberg Energie, Stadtwerke Heidelberg Garagen, Stadtwerke Heidelberg Netze, Stadtwerke Heidelberg Technische Dienste, Stadtwerke Heidelberg Umwelt, Stadtwerke Neckargemünd, Stromnetz Neckargemünd, Heidelberger Straßen- und Bergbahn3. Einzelne EVU wie die Stadtwerke München überschreiten nationale Grenzen und haben Windparks in Norwegen oder Frankreich (vgl. Stadtwerke München GmbH 2023: 33f.). 7.1.2.3. Eigentümerstruktur und Unternehmensziele Mit der Liberalisierung ging eine Privatisierung öffentlichen Vermögens einher. Komplett privatisiert wurde aber nur ein kleinerer Teil der Stromversorgung. In seinem Datensatz von 820 kommunalen Unternehmen (oftmals Strom und Gas gemischt) konnte Sander ermitteln, dass mehr als die Hälfte (430 Unternehmen) noch zu 100% in kommunalem Besitz waren. Von den verbleibenden 390 Unternehmen blieben 63 in kommunaler Hand, wobei entweder weniger als 25% der Anteile verkauft wurden oder ein anderes kommunales Unternehmen Anteile über 25% erwarb (vgl. Sander 2009: 10f.). Von den großen Konzernen ist der Eigentümerstamm bei E.ON und RWE4 gestreut, EnBW gehört dem Land Baden-Württemberg und einigen Kommunen dort5, Vattenfall dem schwedischen Staat6 und Uniper gehört seit Dezember 2022 der Bundesrepublik Deutschland. Schwintowski macht als wesentlichen Unterschied zwischen privaten und öffentlichen Unternehmen aus, dass »öffentliche Unternehmen typischerweise gewinnbringen- 3 https://www.swhd.de/unternehmen, abgerufen am 02.05.2023. 4 Ca. 1/4 der Aktien von RWE gehören Kommunen (vgl. Meves 2021). 5 https://www.enbw.com/unternehmen/investoren/aktie/#aktionaersstruktur, abgerufen am 02.05.2023. 6 https://group.vattenfall.com/who-we-are/about-us, abgerufen am 02.05.2023. 130 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung de Bereiche mit solchen bündeln [können], die defizitär wirtschaften« (Schwintowski 2012: 330). Bei den Unternehmenszielen wird von »citizen value« anstelle des »shareholder value« gesprochen (vgl. Bähr/Erker 2017: 371). Aber inwiefern öffentliche Eigentümer, öffentliche Kontrollstrukturen und öffentliche Ziele wirklich zur Realisierung öffentlicher Politik führen, ist umstritten. So »ist empirisch festzustellen, dass der öffentliche Einfluss auf die Unternehmenspolitik mit zunehmender Größe der Unternehmen sinkt« (Monstadt 2004: 91). Es geht mehr um Kosten und Preise und nicht mehr um störungsfreie Versorgung. Das Management gleicht jenem in der Privatwirtschaft (vgl. Edeling/Stölting/Wagner 2004: 155f.). Schäfer konstatiert, dass die Daseinsvorsorge Teil des allgemeinen Wertschöpfungsprozesses wird und statt Bedürfnisbefriedigung und Nutzenstiftung Gewinn und Profit in den Vordergrund rücken (vgl. Schäfer 2014: 31). Unterschiede zwischen großen Konzernen und Stadtwerken gibt es weiterhin, was auch an der lokalen Verankerung Letzterer liegt. Ob wirtschaftliche Betätigungen außerhalb des Gemeindegebiets gesetzlich zugelassen sind, ist je nach Bundesland unterschiedlich (vgl. Püttner 2012: 144). »Während kommunale Energieversorger jedoch häufig aufgrund von politischem Kalkül und bestehenden Gemeindeordnungen in ihren Expansionsbemühungen beschränkt sind, haben andere regionale und überregionale Player den Markt der energienahen Dienstleistungen längst für sich entdeckt und treten als starke Konkurrenz auf.« (Rödl und Partner 2017: 59) Neben diesen räumlichen Grenzen wirken sich die Vergaberegeln der EU einschränkend auf die wirtschaftliche Freiheit der kommunalen Unternehmen aus. Diese lässt nicht ohne weiteres zu, eine für die Leistungserbringung geeignet gehaltene Organisation auszuwählen (vgl. Brede 2012: 308). Gleichzeitig gilt die Selbstverwaltungsgarantie der Gemeinden laut Artikel 28(2) GG (vgl. Hellermann 2000: 350). Sie sichert den Kommunen die Selbstverwaltung zu. Die Selbstregelung lokaler Angelegenheiten und dezentrale politische Macht (Prinzip der Subsidiarität) ist ihnen gesetzlich garantiert (vgl. ebd. 21). Ob technischer Natur (in Form der Netze oder dezentraler Erzeugungsanlagen), im Sinne einer kommunalen Selbstverwaltung (Subsidiarität) (vgl. Edeling/Stölting/Wagner 2004: 20f.) oder durch Nähe zur Kundschaft, Dezentralisierung der Stromerzeugung und Nachhaltigkeit (vgl. Doleski 2016: 25f.): Die deutsche Energiewirtschaft hat einen starken regionalen Bezug. Eine aggressive Expansionspolitik oder kurzfristige Renditeorientierung ist nicht das Ziel kommunaler Unternehmen. Gleichwohl stehen regionale Versorger unter Druck, Gewinn zu erwirtschaften. Viele Kommunen finanzieren mit dem Geld andere Vorhaben ihrer Stadt. Als Folgen der Liberalisierung haben sechs Feldstudien im Bereich Elektrizität (Belgi- en, Österreich, Polen, UK) festgestellt, dass der Wettbewerb von der lokalen Situation abhängt und im Vereinigten Königreich der intensivste Wettbewerb herrscht (vgl. Flecker/ Hermann 2011: 526). Die EVU verfolgen neue Strategien: Diversifizierung, mehr Geld für Werbung, mehr Call-Center und damit reduzierte Betreuung vor Ort (vgl. ebd. 527). 7. Industriespezifische Aspekte der Softwaregestaltung inder Energiewirtschaft 131 7.1.2.4. Marktrollen, Geschäftsfelder und Regulierung Die meisten stromwirtschaftlichen Unternehmen sind Netzbetreiber oder Stromlieferanten. 2018 gab es 913 Stromnetzbetriebe und rund 1300 Stromlieferanten in Deutschland (vgl. BDEW 2019). Abbildung 7: Anzahl Elektrizitätsunternehmen 2018 (Quelle: BDEW 2019) Firmen für Energiedienstleistungen wie Energieberatung, Energie-Contracting (Anlagen zur Verfügung stellen und betreiben) und Energiemanagement gibt es ca. 7400 (vgl. BfEE 2019: 103). Zusätzlich gibt es durch die erneuerbaren Energien viele kleine, private Erzeugungsanlagen von Genossenschaften, Landwirt:innen oder Privatleuten. Im Marktstammdatenregister7 der BNetzA waren zum 28. April 2023 2.593.888 aktive Anlagenbetreibende aufgeführt. Die Regulierung ist für jedes Geschäftsfeld unterschiedlich. Der Netzbetrieb ist viel stärker in seiner wirtschaftlichen Kalkulation von BNetzA-Verordnungen abhängig als ein Stromlieferant, dessen Herausforderung mehr im Wettbewerb mit anderen Lieferunternehmen liegt. Bei den Netzen handelt es sich um natürliche Monopole. Es gibt Übertragungsnetzbetriebe (ÜNB) für die Fernübertragung, von denen es in Deutschland vier gibt (Tennet TSO, 50Hertz Transmission, Amprion, TransnetBW) und Verteilnetzbetriebe (VNB) für die letzten Kilometer bis zu den Verbrauchenden, von denen 913 existieren (siehe Abbildung oben) und die unterschiedlich groß sind. Die Übertragungs- und Verteilnetzbetriebe haben jeweils durch den Gesetzgeber zugewiesene Aufgaben (bspw. Stabilisierung des Stromsystems, Ausbau der Netze, Anschluss Erneuerbare-Energie-Anlagen). Um in dem natürlichen Monopol Anreize für Effizienzsteigerungen zu setzen, wurde 2007 die Anreizregulierungsverordnung verabschiedet8. Von nun an waren nicht mehr die Kosten Ausgangspunkt dafür, die Erlöse von Netzbetrieben zu bestimmen. Auch der Gewinn wurde nicht mehr pauschal aufgeschlagen. Es wurden nun individuelle Effizienzvorgaben ermittelt, von deren Erreichung abhängt, wie viel Rendite ein netzbetreibendes Unternehmen erwirtschaftet (vgl. Herrmann 2012: 289f.). Für Übertragungs- und Verteilnetzunternehmen liefert die Anreizregulierung einen Ansporn, die Effizienz zu steigern (bspw. durch Kooperation mit anderen Netzbetreiber, Erschließung neuer Geschäftsfelder, Einsatz moderner Technologien) (vgl. Herrmann 2012: 301). Laut einer Studie anhand von 109 VNB über die Anreizregulierung von 2009 hatte die Anreizregulierung ei- 7 https://www.marktstammdatenregister.de, abgerufen am 02.05.2023. 8 betreut durch die Beschlusskammer 8 der BNetzA, Verordnung StromNEV. 132 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung nen signifikanten positiven Effekt auf die Investitionsrate der VNB. Es stellte sich zudem heraus, dass es keinen Unterschied zwischen Firmen im öffentlichen und privaten Besitz gab (vgl. Cullmann et al. 2016). Zwei Dinge gilt es noch zu bedenken: Für ca. 650 Stromnetzbetriebe (mit weniger als 30.000 Kund:innen) gibt es ein vereinfachtes Verfahren, bei dem die Berechnung der Anreizregulierung weniger aufwendig und somit kostengünstiger ist (vgl. Herrmann 2012: 295f.). Zum Zweiten müssen im Unterschied zu den ÜNB die VNB den Zuschlag für eine Netzkonzession erhalten, um wirtschaftlich tätig werden zu können. Wenn bspw. ein 20- jähriger Konzessionsvertrag ausläuft und der VNB den Zuschlag nicht mehr erhält, ist er seiner Geschäftsgrundlage beraubt und muss den Betrieb einstellen. Um die Konzession in Berlin zwischen Vattenfall und dem Land Berlin gab es gerichtliche Auseinandersetzungen, bis Vattenfall nachgab (vgl. Müller 2021). Nicht nur im Netzbereich entstehen viele unternehmerische Risiken und wirtschaftliche Unsicherheiten durch die Regulierung oder politische Entscheidungen. Auch für den Messstellenbetrieb (den aktuell meistens das netzbetreibende Unternehmen übernimmt) gibt die BNetzA die Aufgaben vor: Installation, Inbetriebnahme, Konfiguration, Administration, Überwachung und Wartung von Zählern. Zusätzlich wurde im Zuge der Einführung von Smart Metering durch das Gesetz zur Digitalisierung der Energiewirtschaft (was die Installation von Smart Metern betrifft) eine neue Marktrolle bzw. ein neues Geschäftsfeld geschaffen. Der Smart Meter Gateway Administrator soll die Kommunikationseinheit für Messdaten zur Verfügung stellen und damit seine Geschäfte machen. Weil es so aufwendig ist, ein Zertifikat des Bundesamtes für Sicherheit in der Informationstechnik (BSI) zu erhalten, gibt es nicht viele Firmen, die diese Marktrolle übernehmen. Zudem begrenzt die Regulierung die Preise für Stromzähler für die Endkundschaft gestaffelt nach dem Stromverbrauch (für alle Verbrauchsstellen über 6000 kWh, bei denen der Einbau gesetzlich vorgeschrieben ist). Die Stromlieferanten sind am stärksten am Markt ausgerichtet. Sie gab es vor der Liberalisierung noch nicht. Sie müssen sich um Marketing kümmern, Kund:innenbeziehungen pflegen und es gibt viel Konkurrenz (mittlerweile auch von branchenfremden Unternehmen wie Lidl9, Deutsche Bahn10 oder Volkswagen11). Subventionierung Erneuerbare Energien Erneuerbare Energieträger wurden vor allem zu Beginn durch ein Umlageverfahren staatlich gefördert – und zwar nicht nur für (große) Firmen, sondern auch für Privatpersonen. Die ökonomischen Anreize in Form von Fördersätzen wurden im Laufe der Jahre stufenweise abgesenkt. Es gab seit 2000 mehrere Novellierungen des Erneuerbare- Energien-Gesetzes. Über die Jahre und da es eine garantierte Vergütung von 20 Jahren (EEG §21 (2)) gibt, haben sich Tausende von Vergütungskategorien (unterschiedlicher Jahre und Leistungsstufen) für die verschiedenen Energieträger Wasser, Biomasse, Windenergie, Solarenergie und Geothermie angesammelt. Für Kraft-Wärme-Kopp- lungs-Anlagen gibt es noch einmal gesonderte Vergütungskategorien. Mittlerweile gibt 9 https://www.lidl-strom.de/, abgerufen am 12.05.2023. 10 https://www.dbstrom.de/, abgerufen am 12.05.2023. 11 https://www.elli.eco/de/volkswagen/naturstrom, abgerufen am 12.05.2023. 7. Industriespezifische Aspekte der Softwaregestaltung inder Energiewirtschaft 133 es Ausschreibungsverfahren und die Direktvermarktung wird gefördert (bei großen Solaranlagen gibt es keine Einspeisevergütung mehr). Seit 2017 gibt es einen »Mieterstromzuschlag«, eine Subvention für Strom aus Solaranlagen auf Wohngebäuden, der an die Hausbewohner geliefert wird. 7.1.3. Produktmarkt-Governance: staatliche Regulierung und Digitalisierung Unabhängig von ihrer Rechtsform oder ihrer Marktrolle finden sich die Unternehmen mit Normen und Regelungen konfrontiert, welche »die Produkteigenschaften und Nutzungsmöglichkeiten sowie Wettbewerbsstrukturen der Industrie betreffen« (Jürgens 2007: 128). Diese Produktmarkt-Governance wird geprägt durch Staat, Verbände und einzelne Firmen. Eckpunkte für die Koordinierung und Steuerung durch den Staat sind die Harmonisierung der Kommunikationsstrukturen, die Durchsetzung des Wettbewerbsprinzips, das Setzen von Standards oder die Regionalisierung der Käufermärkte (vgl. Jürgens 2007: 129f.). Das zentrale Ziel ist es, Strukturen zu schaffen, die einen Markt mit Wettbewerbsmechanismen etablieren. Einen großen Anteil nimmt in der Stromwirtschaft die Produktgestaltung ein. 7.1.3.1. Wechsel Stromlieferant, Energierechnung und Stromhandel Kund:innen konnten zwar schon ab 1998 theoretisch ihren Stromlieferanten wechseln. Aber erst 2007 gab es klare Vorgaben für den Wechsel des Lieferunternehmens. Im Zuge der Liberalisierung wurde die Strombörse eingeführt und Social Media ist wie für Firmen anderer Branchen ein wichtiger Kommunikationskanal für EVU geworden. Um der Kundschaft ein vielfältigeres Angebot bieten zu können, den Strompreis transparent zu machen und informierte Kaufentscheidungen zu ermöglichen, müssen sämtliche Abgaben, der Energiemix und die Herkunft des gekauften Stroms auf der Rechnung angedruckt werden. Die Zusammensetzung des Preises muss gemäß EnWG §40 Abs.2 für die Letztverbrauchenden transparent sein, d.h. auf der Rechnung aufgeführt werden. §42 des Energiewirtschaftsgesetzes (EnWG) verpflichtet Stromlieferanten, ihrer Kundschaft die Zusammensetzung der Energieträger des gelieferten Stroms (bspw. Kohle, Gas oder erneuerbare Energien) anzugeben. Seitdem §66 Abs.9 EEG und §118 Abs.5 EnWG am 1. Januar 2013 in Kraft getreten sind, gibt es das Herkunftsnachweisregister (HKNR), welches durch das Umweltbundesamt geführt wird. In dem Register sind sämtliche erneuerbaren Energiequellen aufgelistet. Ziel ist es, dem »gemischten« Strom aus der Steckdose genau eine Energiequelle zuordnen zu können, damit die Verbrauchenden sichergehen können, dass sie »grünen« Strom bekommen. Der Herkunftsnachweis für Strom aus Erneuerbaren-Energie-Anlagen ist in analoger Form nicht umsetzbar – das betrifft auch das Abbilden des Strommix auf der Stromrechnung, um so der Kundschaft transparent zu machen, welchen Strom sie 134 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung bezieht.12 Für den Herkunftsnachweis und den Strommix mussten Entwickler:innen die entsprechende Software programmieren. Für einzelne Stromkund:innen war zwar durch die Regulierung der Wechsel des stromliefernden Unternehmens möglich geworden. Es fehlte aber der Ort, wo sie die unterschiedlichen Angebote vergleichen konnten. Was in anderen Märkten durch ein neues Produkt im Warenregal geschehen kann, geschieht in der Stromwirtschaft über digitale Prozesse. Dafür betreiben einige Firmen Internetseiten, auf denen die Verbraucher:innen für ihren Wohnort die Preise der Stromlieferanten vergleichen und auch gleich einen Wechselprozess starten können (z.B. Verivox oder Check24). Aber nicht nur auf den Vergleichsportalen müssen die EVU aktiv sein. Sei es Social Media, Apps, Online-Kund:innenportale oder Smart Home: Die Erwartung der ständigen Erreichbarkeit und jene der Selbstdarstellung und Aufmerksamkeitsgenerierung hat Einzug gehalten in die EW. Manche EVU richten Abteilungen für die Facebook-, Twitter, Instagram und Whats-App-Betreuung ein. Dabei vermischt sich Kund:innenservice, PR und Vertriebsarbeit, wenn über Facebook nicht nur Beschwerden eingehen, sondern auch Produkte erworben werden und über neue Aktionen in der Kommune des Stadtwerkes informiert wird. Exkurs zu Netzentgelten13 Die Stromrechnung soll die Kundschaft nicht nur darüber informieren, wie der Strom produziert wird, sondern auch, wie sich der Strompreis zusammensetzt. Neben den Steuern und Abgaben fordert das EnWG, die Netzentgelte auf der Rechnung auszuweisen. Auf der Stromrechnung mag das nur ein Detail sein, das den meisten Verbrauchenden nie aufgefallen ist. Anhand dieses Beispiels kann aber exemplarisch die Verschränkung aus juristischer Regulierung und digitaler Abbildung aufgezeigt werden. Auch hier kann von einer unvollständigen Regulierung gesprochen werden. Es bleibt nämlich offen, wie bspw. die Netzentgelte auf die Rechnung kommen. Es gibt an die 1000 Netzbetriebe (VNB) und für ein Stromlieferunternehmen bedeutet das, dass es, je nachdem, in welches Netz es liefern will, andere Netzentgelte auf der Stromrechnung ausweisen muss. Eine Möglichkeit ist, die Beträge aus der Rechnung, die das netzbetreibende Unternehmen an das energieliefernde Unternehmen für die Nutzung seines Netzes schickt, einfach auf der Rechnung an die Endkundschaft auszuweisen. Der Zahlungsfluss ist nämlich so, dass das Lieferunternehmen das Geld der Kundschaft einzieht und dies dann an den VNB weiterleitet. Dafür schickt der VNB dem Lieferunternehmen eine Rechnung. Nach 1998 und bevor die Marktkommunikation (s.u.) funktionierte, geschah dies per Post. Folglich mussten Wäschekörbe mit Netzrechnungen in die IT-Sys- teme eingetippt werden. Mittlerweile passiert das digital und automatisiert. Wie kann nun das Lieferunternehmen sicher sein, dass die Rechnung stimmt? Und was passiert, 12 Aus der Steckdose kommt immer der gleiche Strom. Die Zuordnung des eigenen Stroms zu bestimmten Energiequellen ist physikalisch nicht möglich. Dazu müssten die Verbrauchenden Teil eines Inselnetzes sein, in das bspw. nur Strom aus erneuerbaren Energiequellen eingespeist wird. 7. Industriespezifische Aspekte der Softwaregestaltung inder Energiewirtschaft 135 wenn der Rechnungszeitraum des VNB mit jenem vom Lieferunternehmen nicht übereinstimmt? Soll das Lieferunternehmen immer auf die Rechnung des VNB warten, bis es die Rechnung an die Kundschaft schicken kann? Wenn das Lieferunternehmen nicht warten will, muss es die Netzentgelte der jeweiligen VNB kennen. Die BNetzA verpflichtet zwar die VNB, die Netzentgelte zu publizieren. Diese Veröffentlichung erfolgt allerdings nicht zentral in einer Datenbank, sondern auf den Webseiten der VNB. Die Zentralisierung der Daten haben zwei Unternehmen übernommen (ene’t GmbH und GET AG). Sie haben eine Datenbank mit sämtlichen Netzentgelten angelegt und bieten diese den Lieferunternehmen zum Verkauf an. Damit bieten sie dem Vertrieb eine Grundlage, Preiskalkulationen für die unterschiedlichen Netzgebiete vornehmen zu können. Ohne die Netzentgelte je Netzgebiet kann das EVU seiner Stromkundschaft nämlich gar kein durchkalkuliertes Angebot machen. Die Alternative sind vom Netzgebiet unabhängige Preise. Dann muss der Vertrieb aber damit leben, dass er in dem einen Gebiet mehr und in dem anderen Gebiet weniger Marge hat. Die stellenweise sich in einer Straße ändernden Netzgebiete informationstechnisch zu integrieren und in jeder Abrechnung zu berücksichtigen, ist enorm aufwendig. Seit Jahren gibt es eine Diskussion, ob nicht der VNB seine Preise dem Lieferunternehmen über die Marktkommunikation (mittels eines EDIFACT Datenformats) zusendet, damit dieser dann eigene Kalkulationen machen kann. Genauso gut könnte die BNetzA auch eine zentrale Datenbank mit sämtlichen Preisen vorhalten und diese zur Verfügung stellen oder einen Web Service anbieten, der einem die Preise zu einem Netzgebiet zurückliefert. So gab und gibt es unzählige IT-Fachkräfte, die sich damit beschäftigen, die Netzentgelte auf die Rechnung der Verbrauchenden zu bringen. Im Zuge der Liberalisierung wurde eine Strombörse eingeführt. Indizien, dass dort Manipulationen stattgefunden haben, gibt es viele (vgl. Becker 2010: 143ff.). Es mussten zusätzliche Regulierungen her. Die Bundesnetzagentur überwacht mittlerweile zusammen mit der bei ihr angesiedelten nationalen Markttransparenzstelle für den Großhandel von Strom und Gas das Verbot von Insiderhandel und Marktmanipulation. Die dafür geltende europäische Verordnung über die Integrität und Transparenz des Energiegroßhandelsmarkts (kurz: REMIT) ist seit 2011 wirksam. Zu den Aufgaben der Bundesnetzagentur zählen die Registrierung von Marktteilnehmenden, die Durchsetzung von Datenmeldepflichten sowie die Verfolgung von Verstößen. Neben der REMIT gibt es noch Verordnungen wie MiFID14 I, MiFID II, MiFIR15, EMIR16. Ihr Ziel »ist die Sicherstellung von fairem Wettbewerb, effizienteren Märkten und vor allem, das verlorene Vertrauen der Stakeholder in die Märkte zurückzugewinnen.« (Kolloch/Golker 2016: 45) Ein nach REMIT meldepflichtiger Marktteilnehmer ist dazu verpflichtet, sich bei der jeweiligen nationalen Behörde zu registrieren. In Deutschland wird diese Funktion durch die Bundesnetzagentur (BNetzA) übernommen. 13 Basierend auf Erfahrungen des Verfassers als IT-Berater in der Energiewirtschaft. 14 »Markets in Financial Instruments Directive« 15 »Markets in Financial Instruments Regulation« 16 »European Market Infrastructure Regulation« 136 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung 7.1.3.2. Zentrale Systemsteuerung, IT-Sicherheit und Standards Zentral gesammelte Daten über das gesamte Stromsystem, Vorgaben zur IT-Sicherheit und technische Standards kennzeichnen die Produktmarkt-Governance der EW. Eine der Aufgaben der BNetzA ist es, zentral Daten zu sammeln. Sie führt eine Kraftwerksliste systemrelevanter Kraftwerke und das bereits erwähnte Marktstammdatenregister. Die Marktstammdatenregisterverordnung (MaStRV) verpflichtet dazu, sämtliche ortsfeste Stromspeicher unabhängig von ihrem Inbetriebnahme-Datum im Marktstammdatenregister zu registrieren. Es soll der Überblick behalten werden. Mittlerweile stellt die BNetzA eine Ladesäulenkarte17 für E-Mobilität zur Verfügung. Über die Jahre werden immer mehr Daten gesammelt und aufbereitet und die zu sammelnden Daten werden komplexer. Mit der steigenden Bedeutung der IT muss der Staat sich um die Sicherheit kümmern. Es gibt eine ganze Reihe von Gesetzen und Verordnungen, die für die IT-Sicher- heit sorgen sollen: Im IT-Sicherheitsgesetz, das zum 25. Juli 2015 in Kraft getreten ist, geht es schwerpunktmäßig um kritische Infrastrukturen. Durch das BSI-Gesetz wird das BSI zur zentralen Meldestelle für die IT-Sicherheit. Der §11 des EnWG ermächtigt die BNetzA, einen Katalog von Sicherheitsanforderungen vorzulegen. Dazu gehört u.a. die Einführung eines Informationssicherheits-Managementsystems (ISMS) oder, dass jedes Unternehmen Ansprechpersonen für IT-Sicherheit benennen muss. Wie weiter oben bereits erwähnt (7.1.2.4), zeigt die Einführung des Smart Meter Gateway Administrator, dass Sicherheitsvorkehrungen Innovationen erschweren und Barrieren für die Marktteilnahme errichten. Die Zertifizierung zur IT-Sicherheit ist sehr aufwendig. Es gibt in der Stromwirtschaft unzählige Standards und mit der Digitalisierung werden es immer mehr. Die Deutsche Energie-Agentur GmbH (dena) hat in einer Studie von 2018 Schnittstellen und Standards für die Digitalisierung für Smart Grids, Virtuelle Kraftwerke (Näheres siehe 7.2.2.3), Smart Meter, Smart Home und Elektromobilität aufgelistet (vgl. Limbacher/Richard 2018). Im Rahmen des offenen Industrieforums VHPready e.V., einer Initiative für die Integration und Standardisierung von dezentralen Energiesystemen, wurde ein offener Industriestandard zur Steuerung von dezentralen Stromerzeugungsanlagen, Verbrauchern und Energiespeichern erarbeitet18. Mittlerweile werden in von der Europäischen Union geförderten Projekten wie z.B. DISPOWER, FENIX und MICROGRIDS ebenfalls Standards für eine einheitliche Informations- und Kommunikationstechnologie im Bereich dezentraler Energiesysteme entwickelt. Mit diesen Standards wird u.a. sowohl die internetbasierte Steuerung eines virtuellen Kraftwerkes möglich als auch der automatisierte Handel mit Strom. Virtuelle Kraftwerke unterliegen mittlerweile den IT-Sicherheitsstandards des BSI, weil sie Teil der kritischen Infrastruktur sind. Der BDEW listet acht Smart-Home-Funktionsstan- dards und zu jedem davon mindestens zwei unterschiedliche produktanbietende Firmen auf (vgl. BDEW 2016: 65). Dann gibt es noch Initiativen wie die Interessengemeinschaft 17 https://www.bundesnetzagentur.de/DE/Sachgebiete/ElektrizitaetundGas/Unternehmen_Inst itutionen/HandelundVertrieb/Ladesaeulenkarte/Ladesaeulenkarte_node.html, abgerufen am 16.05.2023. 18 https://www.smartgrids.at/VHPReady.html, abgerufen am 16.05.2023. 7. Industriespezifische Aspekte der Softwaregestaltung inder Energiewirtschaft 137 Geschäftsobjekte Energiewirtschaft e.V., die Standards für Energiedienstleistungen und die damit zusammenhängenden digitalen Prozesse etablieren will19. 7.1.4. Prozess-Governance: Systemstabilität und regulierter Datenaustausch In dieser Arena der Governance geht es um die »Ausgestaltung der interorganisationalen Beziehungen in den Wertschöpfungsketten« (Jürgens 2007: 132). Typisch für die Stromwirtschaft ist die interorganisationale Prozessgestaltung durch die BNetzA, die vielfältigen Kooperationen und Beteiligungen. 7.1.4.1. Regulierter Datenaustausch entlang der Wertschöpfungskette Die BNetzA lieferte 2007 die ersten Prozessbeschreibungen für den Datenaustausch zwischen den Unternehmen. Damit die einzelnen Marktteilnehmenden ihre Rolle im System erfüllen können, ist genau definiert, welche Daten sie von wem in welcher Frist zu erhalten haben. Das legt die Beschlusskammer 6 der BNetzA20 in den folgenden Prozessen fest: • Geschäftsprozesse zur Belieferung der Kundschaft mit Elektrizität (GPKE) • Wechselprozesse im Messwesen Strom (WiM Strom) • Marktprozesse für erzeugende Marktlokationen (Strom) (MPES) • Marktregeln für die Durchführung der Bilanzkreisabrechnung Strom (MaBiS) Der Datenaustausch zwischen den Firmen für einen reibungslosen Ablauf der interorganisationalen Prozesse basiert auf dem EDIFACT-Format (Electronic Data Interchange for Administration, Commerce and Transport), das wiederum auf EDI (Electronic Data Interchange) basiert. Dafür gibt es je Vorgang unterschiedliche Formate (bspw. für Stammdatenaustausch das Datenformat UTILMD, für den Austausch von Zählerständen MSCONS), die über eine Webseite einsehbar sind21. Es erscheinen zweimal im Jahr neue EDI-Formate für die Marktkommunikation22. Den rechtlichen Rahmen zwischen Marktteilnehmenden regeln Verträge. Wie bereits oben erwähnt, ist der Übertragungsnetzbetreiber (ÜNB) für die Netzstabilität zuständig. Maßstab ist hierfür die Netzfrequenz von 50 Hertz. Diese Frequenz darf nur minimal über- oder unterschritten werden, weil sämtliche technischen Anlagen (ob Industrie oder Haushalt) darauf eingestellt sind. ÜNBs können mehrere Maßnahmen ergreifen, um diese einzuhalten: Kraftwerke abschalten (Redispatch), verbrauchende Einrichtungen abschalten (abschaltbare Lasten) und auf Regelenergie zurückgreifen, um unvorhergesehene Leistungsschwankungen in ihren Stromnetzen 19 https://www.bo4e.de/, abgerufen am 16.05.2023. 20 https://www.bundesnetzagentur.de/DE/Beschlusskammern/BK06/BK6.html, abgerufen am 16.05.2023. 21 https://www.edi-energy.de/, abgerufen am 16.05.2023. 22 Auf der Webseite https://www.edi-energy.de ist das Archiv einsehbar. Bspw. beginnt es für das Datenformat UTILMD (Übermittlung Daten der Kundschaft) bereits 2007. Bis 2022 gibt es dafür 26 Versionen. Jede neue Version macht eine Softwareanpassung notwendig. 138 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung auszugleichen. Mithilfe des Einspeisemanagements kann der verantwortliche Netzbetrieb (VNB) unter besonderen Voraussetzungen die Einspeisung aus EE- und KWK- Anlagen vorübergehend abregeln (§13 Abs.2, 3 EnWG). Um diese physikalischen Voraussetzungen zu gewährleisten, fließt neben Strom Geld. Am 1. Juni 2010 traten die Marktregeln für die Durchführung der Bilanzkreisabrechnung Strom (MaBiS) in Kraft. Sie regulieren die Bilanzierung der in einem Monat im Stromnetz verteilten Energiemengen und die Abrechnung der Bilanzkreise. Damit regelt die MaBiS den kaufmännischen Ausgleich zwischen Stromlieferanten und VNB. Der Hintergrund ist, dass das Lieferunternehmen für seine Kundschaft den Verbrauch prognostizieren muss, damit der entsprechende Strom geordert werden kann. Die Abweichungen zwischen dieser Prognose und dem tatsächlichen Verbrauch werden finanziell ausgeglichen. So ist das Lieferunternehmen zu einer möglichst genauen Prognose angehalten. Zur Durchsetzung ihrer Entscheidungen stehen der BNetzA umfangreiche Mittel zur Verfügung. Die Aufsicht umfasst u.a. die ordnungsgemäße Abwicklung der Zahlungen von den VNB an die Betreibenden von Erneuerbaren-Energie-Anlagen oder Maßnahmen für die Systemsicherheit wie bspw. Redispatch-Maßnahmen, durch die Erzeugungsanlagen abgeschaltet werden. 7.1.4.2. Typisch für die Branche: Kooperationen und Beteiligungen Die rechtlichen Besonderheiten kommunalen Wirtschaftens führen zu vielfältigen überkommunalen Kooperationen. Bontrup und Marquard sehen für die kommunalen Unternehmen keine andere Möglichkeit: »Kooperation oder Ausverkauf« (Bontrup/Marquardt 2010: 362). Die Thüga Holding GmbH & Co. KGaA hat 90 gesellschaftende Unternehmen aus der kommunalen Energie- und Wasserwirtschaft23. Zu ihr gehört das IT-Dienstleis- tungsunternehmen (IT-DL) Thüga SmartServices. Es bietet IT-Dienstleistungen für über 250 Organisationen an24. Südweststrom hat 59 gesellschaftende EVU25. Ein IT-DL der Branche wie rku.it hat 19 kommunale Anteilsinhabende26 und die items GmbH neun27. Trianel, als Erzeugungskooperation gestartet, bietet mittlerweile digitale Handelsplattformen an und hat 57 Gesellschaftende (vgl. Trianel GmbH 2022). Typische Formen von Kooperationen sind Shared Service Center wie jene der Thüga SmartService, rku.it, items oder Trianel. Sie bieten IT-Outsourcing an und betreuen ERP-Systeme (zum überwiegenden Teil von SAP) für Stadtwerke. Eine Untersuchung hat 65 Innovationskooperationen von Stadtwerken unter die Lupe genommen. Die Autoren stellen fest, dass nicht nur die großen EVU, sondern vor allem mittelgroße für Innovationen kooperieren. Von den 65 untersuchten Kooperationen finden 57 zwischen Firmen mit weniger als 250 Mitarbeitenden statt (vgl. Lütjen et al. 2014). 23 https://thuega-cdn-copy.s3.eu-central-1.amazonaws.com/Thuega/documents/Th%C3%BCga-Gr uppe-Feb-2023.pdf, abgerufen am 28.04.2023 24 https://smartservice.de/thuega-smart-service/daten-und-fakten/, abgerufen am 28.04.2023. 25 https://www.suedweststrom.de/gesellschafter/, abgerufen am 28.04.2023. 26 https://rku-it.de/ueber-uns/profil/gesellschafter, abgerufen am 28.04.2023. 27 https://itemsnet.de/ueber-uns/, abgerufen am 28.04.2023. 7. Industriespezifische Aspekte der Softwaregestaltung inder Energiewirtschaft 145 Für die Ablösung alter Software gibt es vielfältige Alternativen. Weil es keine anderen Daten gibt, steht hier die Zulieferindustrie für Standard-Abrechnungssoftware31 im Fokus. Eine Übersicht des Bundesverbandes der Energiemarktdienstleister (BEMD) sieht die industriespezialisierten Softwarefirmen von Schleupen, SIV und IS-Soft vorne, was die Größe ihrer Kundschaft anbelangt (gemeinsam 912 EVU). Tabelle 6 zeigt, dass die Softwarefirmen für die industriespezifische Software vor allem ab den 90er Jahren aktiv geworden sind. Was auffällt, ist, dass trotz der Komplexität der Branchenprozesse und der vielfältigen Anwendungsfelder die IS-Soft mit nur 21 Programmierenden 255 EVU mit ihrer Software beliefern kann. Allerdings gehört keines der belieferten Unternehmen zu den großen mit mehr als 200.000 Marktlokationen bzw. Verbrauchenden32. Neben IS-Soft zeichnet sich Schleupen durch seine Spezialisierung auf kleine EVU aus. Bei den großen EVU liegen SIV und SAP vorne. Die Tabelle zeigt, dass sich jüngere Softwarefirmen wie Powercloud, IQone oder Quanto schwertun, den Markt zu erobern. Tabelle 7: Firmen Abrechnungssoftware Stand 2023 Softwarefirma Markteintritt Mitarbeitende für Produkt Entwickelnde für Produkt EVU bis 20.000 MaLo* 20.000- 200.000 ab 200.001 MaLo Schleupen 1977 376 189 357 173 7 4 SIV 1992 399 121 300 90 83 37 IS-Soft 1996 82 21 255 190 65 0 Wilken Neutrasoft 2000 208 95 207 107 100 0 MSU 2003 90 40 181 130 50 1 Wilken ENER:GY 1999 208 95 128 35 90 3 SAP 1988 k. A. k. A. 84 10 47 27 SDK 1994 34 30 69 32 33 4 Rhenag 1998 85 70 52 18 30 4 Somentec 1995 78 27 46 35 11 0 Klafka&Hinz 2000 115 50 41 30 10 1 robotron 1999 325 120 40 19 15 6 31 Mit Abrechnungssoftware ist gemeint, dass eine Software Zählerdaten verarbeiten und eine Rechnung an die Verbrauchenden versenden kann. Bei der BEMD-Studie der folgenden Seite ist von »Meter to Cash« die Rede. Die Softwarepakete der Firmen haben meist aber auch noch andere Funktionalitäten wie Forderungsmanagement oder Finanzbuchhaltung mit dabei und stellen vollständige ERP-Systeme dar. 32 Von »großen« EVUs wird hier gesprochen, wenn ein EVU mehr als 200.001 Kund:innen hat oder, wie es in der Tabelle heißt: MaLo – siehe die Beschriftung der letzten beiden Spalten der Tabelle 7. Die Abkürzung steht für Marktlokationen und ist vereinfacht gesagt eine technische Bezeichnung für Kund:innen der EVUs. 146 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung Softwarefirma Markteintritt Mitarbeitende für Produkt Entwickelnde für Produkt EVU bis 20.000 MaLo* 20.000- 200.000 ab 200.001 MaLo Powercloud 2012 60 45 35 10 21 4 AKTIF 2001 33 19 28 24 4 0 Iqone 2014 8 7 5 4 1 0 Quanto 2018 30 20 5 5 0 0 (Quelle: BEMD https://www.bemd.de/download/BEMD-ITLM2C_Anbietermatrix_Abrechnungssoft ware_2020.pdf, zuletzt abgerufen am 2. Mai 2023) * Marktlokation bezeichneten eine eindeutige ID für Stromabnehmer oder -einspeiser. Vereinfacht könnte man sagen: Kund:innen der EVUs. Die Messlokation ist ein Stromzähler. SAP begann 1995 die Entwicklung des branchenspezifischen Moduls IS-U mit dem Ziel, eine international einsetzbare Standardlösung zu programmieren (vgl. Frederick/ Zierau 2011: 15f.). Die Anpassungen an den deutschen Markt konnten sich eher größere EVU leisten. Die Besonderheit war und ist immer noch, dass SAP eine Entwicklungsplattform bietet, damit EVU selbst oder IT-DL Programmierungen am Standard vornehmen können. Wie bereits unter 4.3 geschrieben, gibt es allein für die Versorgungswirtschaft über 200 Firmen, die mit SAP kooperieren. Diese große Anzahl ist ein Indiz dafür, wie umfangreich die Arbeit war und ist, um SAP IS-U zu implementieren und anzupassen. Es ist unklar, welche Rolle andere Entwicklungsplattformen spielen und wie häufig sie die EVU nutzen. Zum Beispiel gibt es noch andere, kleinere branchenspezifische Entwicklungsplattformen wie eine Open-Source-Datenplattform für Smart-City-An- wendungen für Stadtwerke (vgl. ZfK, 02.07.2022). Die Entwicklungsplattformen AWS von Amazon33 oder Azure von Microsoft34 nutzen Organisationen der Branche auch. Allerdings bieten die zwei Unternehmen keine industriespezifischen Bausteine an. 7.2.1.2. Unterscheiden sich große und kleine EVU? Auch wenn größere EVU mehr Geld für Software ausgeben, heißt das nicht, dass nicht ebenso kleine EVU agile Teams etablieren und selbst Software entwickeln. Untersuchungen zur Digitalisierung in großen und kleinen EVU zeichnen ein unscharfes Bild und zeigen eine Heterogenität an Digitalisierungsstrategien. Ob groß oder klein: Auch beim Thema Digitalisierung kooperieren die EVU. Die Studien vom Verband BDEW, A. T. Kearney und IMP³Prove (2018 und 2019) konnten Unterschiede in der Digitalisierung zwischen großen und kleinen Versorgern35 nur 33 https://aws.amazon.com/de/developer/tools/, abgerufen am 4. Mai 2023. 34 https://azure.microsoft.com/de-de/products/visual-studio/, abgerufen am 4. Mai 2023. 35 »Die insgesamt 80 teilnehmenden EVU aus dem Jahr 2018 umfassen Strom-, Gas- und Wassernetzbetreiberwie auch Querverbundunternehmen, darunter kleine und sehr große Unternehmen, Netzbetreiber und Vertriebsunternehmen. In ihrer Gesamtheit bilden sie alle Wertschöpfungsstufen und Unternehmensgrößen der Branche ab und lassen daher Rückschlüsse auf den generellen Digitalisierungsstand in der Energiewirtschaft zu.« (BDEW et al. 2019: 6) 7. Industriespezifische Aspekte der Softwaregestaltung inder Energiewirtschaft 147 für ein Jahr feststellen. In einer Studie ermittelten sie einen Digitalisierungsindex je Firma, der sich aus sieben Analysebereichen zusammensetzt (u.a. Digitalisierungsstrategie, Kostenersparnis durch digitale Interaktion mit der Kundschaft, ob agile Methoden genutzt werden, Kooperationen mit Plattformen oder IT-Fachkräften). 2018 konnten zwischen großen und kleinen EVU noch keine Unterschiede festgestellt werden. Es gab sowohl bei kleinen als auch großen »Top-Digitalisierer« wie Nachzügler. In der Studie von 2019 war dann ein leichter Zusammenhang auszumachen: je höher der Umsatz, umso weiter in der Digitalisierung. Zu einem ähnlichen Ergebnis kommt die Kanzlei Rödl & Partner. Sie messen den IT-Reifegrad36 (vgl. Rödl/Partner 2017: 42). Unterschiede gibt es zwischen neuen und etablierten EVU. Bei einer Befragung von elf kommunalen Versorgern mussten sich die Forschenden eingestehen, dass die »klassischen Digitalisierungsthemen etablierter Energieversorger möglicherweise nicht gänzlich auf Stadtwerke-Neugründungen zu übertragen sind« (Berlo et al. 2018: 32). Sie wägen Risiken und Nutzen der neuen Technologien stärker ab und setzen sie sehr spezifisch vor allem zum Auf- und Ausbau von Flexibilisierungsoptionen ein: flexibles Einspeisemanagement, Kontrolle von Lastverschiebungen, Bereitstellung von Speicherkapazität, Erweiterung von virtuellen Kraftwerken (vgl. Berlo et al. 2018: 31f.). Die typische Kooperationsbereitschaft der Branche zeigt sich auch bei der Digitalisierung. EVU kooperieren: mit Start-ups (23%), mit Mittelständlern/Großunternehmen (36%), anderen kooperierenden Unternehmen (Beratungsunternehmen, Softwarehäuser) (36%), mit Universitäten oder Forschungseinrichtungen (35%) (vgl. BDEW/A.T. Kearney, IMP³Prove 2019: 23). 7.2.1.3. Software als Geschäftsfeld der EVU Eine IT-Strategie, die sich in der Branche durchsetzt, ist nicht zu erkennen. Auf jeden Fall gibt es EVU, die mit Software Geld verdienen. Manche Unternehmen bieten die Standardsoftwarepakete als Anwendungsplattformen an. Darunter ist zu verstehen, dass ein IT-DL oder ein EVU eine Standardsoftware implementiert und dann anderen zur Verfügung stellt. Die kommunale Kooperation Thüga will bis 2024 30 Unternehmen für ihre Abrechnungsplattform gewinnen (vgl. ZfK, 17.06.2022). Der Energiekonzern EnBW stellt eine Anwendungsplattform für Stromlieferanten zur Verfügung, auf der sie ihre Prozesse abwickeln können (vgl. ZfK, 25.02. 2019). Arvato Systems (Teil des Bertelsmann-Konzerns) bietet eine Anwendungsplattform (einzelne Module und Applikationen) als Pay-Per-Use-Service an37. Eine Sonderform von Anwendungsplattformen ist White-Label-Software. Was ist das? Eine Organisation entwickelt eine Software, stellt sie zur Verfügung (ob via Cloud oder On-Premises38) und versieht sie in der Darstellung nach außen mit der entspre- 36 Der wie folgt gemessen wird: Es gibt eine IT-Strategie. Mitarbeitende sind an die IT-Infrastruktur angebunden. Wie zufrieden Mitarbeitende mit IT-DL bzw. der IT-Abteilung sind und wie Kosten- Nutzen-Verhältnis der Unternehmens-IT eingeschätzt wird. 37 https://www.arvato-systems.de/branchen/branchen-im-ueberblick/energie-versorgungswirtsch aft/aep, abgerufen am 4. Mai 2023. 38 Lizenzmodell, bei dem ein Unternehmen eine Softwarelizenz erwirbt und diese auf eigenem Server betreibt. 148 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung chenden Aufmachung des anwendenden EVU (bspw. Logo und Name Stadtwerk). Der Endkundschaft fällt nicht auf, dass es eine Standardsoftware einer anderen Firma ist. Solche White-Label-Lösungen gibt es für Kund:innenportale der Wohnungswirtschaft, mit der Anwendende Zählerstände erfassen können (vgl. ZfK, 01.02.2022). Vattenfall und EnBW kooperieren für eine White-Label-Software für den Smart-Home-Bereich (vgl. ZfK, 25.02.2019). Auch Softwarefirmen wie die oben genannte SIV bieten bspw. White-Label-Apps für Smartphones an39. EVU sind (auch) Softwarefirmen, wie es Doleski (2016) für eine zunehmende Anzahl von ihnen prognostiziert. Die Stadtwerke Schwäbisch Hall haben die Softwarefirma Somentec40, das Stadtwerk Enercity aus Hannover Lynqtech41. EVU sind Gesellschaftende von IT-Dienstleistungsunternehmen, die selbst programmieren und Software gestalten (bspw. Thüga Smartservice GmbH, rku.it GmbH oder items GmbH). Leider fehlen genaue Daten: Wer passt wie stark Standardpakete an? Wer nutzt einen Softwarestandard ohne Anpassung? Welche EVU bieten White-Label-Software an oder nutzen sie? Wie viel Geld verdienen EVU mit Softwareentwicklung oder mit dem Anbieten von Abrechnungsplattformen? Es gibt auch keine Übersicht über sämtliche Zulieferfirmen für industriespezifische Software. Statt dass sich in der Energiewirtschaft softwareentwickelnde Firmen durchsetzen wie in anderen Branchen, gibt es sowohl Softwarefirmen für Standardsoftware als auch EVU, die für einzelne, industriespezifische Anwendungsbereiche Software für andere entwickeln oder betreiben. Bei den vielen EVU ist eine zur Branchenstruktur passende Strategie, diese EVU zu beliefern oder mit ihnen zu kooperieren. Auf jeden Fall gibt es kein disruptives Unternehmen wie Amazon, das Marktführer in der Branche geworden ist und gleichzeitig viel Geld mit Software oder IT-Dienstleis- tungen verdient. Vielmehr koexistieren die Strategien: Einerseits etablieren sich neue Stromlieferanten mit viel Werbung am Markt wie Yello Strom von EnBW (seit 1999). Andererseits gewinnt Octopus Energy (seit 2015) Marktanteile: eine Firma, die nicht nur Strom, sondern auch Software(dienstleistungen)42 anbietet. 39 https://www.siv.de/de/referenzen/referenzen-energielieferanten/team-energie-gmbh-co-kg/, abgerufen am 4. Mai 2023. 40 https://www.somentec.de/ueber-somentec/unternehmen/, abgerufen am 4. Mai 2023 41 https://www.enercity.de/presse/pressemitteilungen/2020/Lynqtech, abgerufen am 4. Mai 2023. 42 eigene Softwarelösung https://kraken.tech/, abgerufen am 4. Mai 2023. 7. Industriespezifische Aspekte der Softwaregestaltung inder Energiewirtschaft 149 7.2.2. Wechselspiel von Regulierung und Softwareentwicklung 7.2.2.1. Markt-Governance dank Software: Wechsel Lieferfirma, Transparenz undDatenaustausch Auch wenn der Staat Software nicht selbst entwickelt, hat er durch die Regulierung einen maßgeblichen Anteil an der stetigen Softwaregestaltung in der Branche. Die Regulierung für den Wettbewerb und die Produktgestaltung gibt der Staat vor. Die dafür notwendige digitale Technik entwickelt jemand anderes. Ein Ziel der Liberalisierung war, dass die Privatkundschaft das stromanbietende Unternehmen möglichst einfach wechseln kann. Aufgrund von Entflechtung, Auflösung der Gebietsmonopole und um solche Wechsel zu ermöglichen, müssen die Unternehmen vielfältige Daten austauschen (bspw. über Kundschaft oder Zähler). Die BNetzA übernimmt die Regulierung der Kommunikationsstrukturen. In diesem als Marktkommunikation bezeichneten System hat jedes EVU und jedes zählende Gerät eine ID (siehe oben 7.1.4.1). Die vorgeschriebenen Marktprozesse können bei der Koordination so vieler Marktakteur:innen nur effizient sein, wenn sie automatisiert ablaufen. Müssten Stromversorger langfristig eine Vielzahl an Sachbearbeitenden einstellen, um die Marktprozesse abzubilden: Wie wäre es um die Legitimität der Regulierung dann bestellt? Vor allem für die Wertschöpfungsstufen Vertrieb und Netze müssen Unternehmen Daten zu Zahlungen, Strombilanzierung, Anlagen und Personen austauschen. Das ist kostenintensiv (vgl. Seeliger et al. 2019), birgt Risiken, macht die Industriestrukturen komplexer und erhöht den Koordinations- und Informationsbedarf. Rohracher kommt zu dem Schluss, dass »transaktionskostentheoretische Analysen auf die Kosten und Imperfektionen des Ersatzes vertikaler Netzintegration durch Preissignale« (Rohracher 2007: 144) hinweisen. Andere Autoren stellen fest, dass der »betriebene Aufwand vermuten lässt, dass ein vertikal integriertes Energieversorgungsunternehmen in öffentlicher Trägerschaft und mit Gebietsmonopol sogar effizienter und effektiver wirtschaften« (Bräunig 2012: 435) kann. Renate Mayntz konstatiert, dass allgemein die Liberalisierung von Telekommunikation, Bahn, Elektrizität zu sehr komplexen Strukturen und komplexen Abhängigkeiten zwischen Handelnden, Prozessen und System führt. Es kommt dann nicht nur zu Konflikten zwischen Regulierer und Regulierten, sondern auch zwischen den unterschiedlichen Zielen der Regulierung (vgl. Mayntz 2009: 139). Die Regulierung soll schließlich nicht nur einen Markt ermöglichen. Sie soll zudem effizient sein und eine hohe IT- und System-Sicherheit garantieren, was bei zunehmender Komplexität immer schwieriger wird. »Die Komplexität der Koordination, die erfüllt werden muss, um Systemstabilität zu gewährleisten, ist in allen Sektoren ein wichtiger Ansatzpunkt der Gegner der Liberalisierung« (Voß/Bauknecht 2007: 121). Indem die Koordination an die IT-Systeme delegiert wird, entlastet sie das Handeln der Marktteilnehmenden wie z.B. einzelner Händler:innen am Energiemarkt oder der Stromkundschaft (die beide per Mausklick handeln können) und belastet die IT-Sys- tembetreibenden. 150 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung Dass Software einen Markt ermöglicht, ist auch in weniger stark regulierten Branchen zu beobachten. In ihrer historischen Darstellung der Literatur zum Forschungsfeld Information Systems sehen Björn-Andersen und Raymond die Funktion der IT ab den 2000ern darin, Preistransparenz herzustellen und es neuen Firmen zu erleichtern, in bestehende Märkte vorzudringen (vgl. Bjørn-Andersen/Raymond 2014: 190). Crowston und Myers zeigen dies in ihrer Untersuchung der Immobilienwirtschaft (vgl. Crowston/ Myers 2004: 16ff.). Dort macht es die IT der Kundschaft einfacher, sich zu informieren. Dadurch kann eine transparente, marktförmige Vermittlung stattfinden und auch Neulinge in der Branche haben eine Chance. 7.2.2.2. Softwareentwicklung für den Stromhandel: Markt ermöglichen, Geld verdienen und neue Risiken Am Stromhandel zeigt sich, wie Software Markt ermöglicht, Regulierung Software-In- novationen erzwingt und gleichzeitig für neue Risiken durch Manipulationsmöglichkeiten und IT-Sicherheit sorgt. Eine neue Institution, welche die Liberalisierung eingeführt hat und die auf digitaler Technologie basiert, ist die (europäische) Energiebörse. Der informationstechnische Aufwand für die Preisbildung dort ist sehr hoch. Damit der tägliche Handel gewährleistet ist, muss ein hoher Datenverkehr mit entsprechender IT-Sicherheit ermöglicht werden. Die einzelnen Marktakteur:innen müssen am gleichen IT-System angeschlossen sein. Für die Software der Energiebörse in Großbritannien wurden 1,5 Mrd. Euro ausgegeben (vgl. Rohracher 2007: 144). Für die Regulierung des Handels durch die REMIT- Verordnung der BNetzA von 2005 wird ein hoher Digitalisierungsgrad attestiert, weil der Datenverkehr eine hohe Quantität und Varianz aufweist (vgl. Kolloch/Golker 2016: 45). Andererseits bieten die durch die Regulierung erzwungenen technischen Innovationen in Form von Software Firmen die Chance, die von ihnen entwickelten Lösungen anderen anzubieten. »Dies kann besonders vor dem Hintergrund des schwindenden Kerngeschäfts, der Belieferung von Endkunden mit den Medien Strom und Gas, von immanenter Bedeutung für die wirtschaftliche Zukunft der EVU sein. Der Wandel vom reinen Medienvertrieb zum integrierten Medien- und Dienstleistungsvertrieb wird einer der entscheidenden Faktoren sein, die über das Überleben der EVU auf dem (Energie-)Markt entscheiden.« (Kolloch/Golker 2016: 53) Es gibt eine ganze Reihe digitaler Handelssysteme und Beschaffungsplattformen wie EnPortal43 (seit 2007) oder Enmacc44 (gegründet 2016), die den Handel an der Börse oder Over the Counter (direkt zwischen zwei Parteien, nicht via Börse) anbieten. Sie eröffnen für kleine Stadtwerke und Energielieferfirmen nicht nur Einnahmequellen, sondern die Möglichkeit, an der Börse teilzunehmen. Beim Stromhandel kann es zu Manipulationen und erhöhtem Risiko kommen. Zum einen wegen technischer Fehler: An der europäischen Strombörse kam es schon einmal 43 https://www.enportal.de/, abgerufen am 4. Mai 2023. 44 https://enmacc.com/, abgerufen am 4. Mai 2023. 7. Industriespezifische Aspekte der Softwaregestaltung inder Energiewirtschaft 151 zu einem Ausfall, weil Datenpakete fehlerhaft waren (vgl. Päffgen/Sperling 2019). Neben der Börse für Lieferunternehmen gibt es noch einen Regelenergiemarkt für den notwendigen Lastenausgleich im Stromnetz. Dort wird der Strom gehandelt, der eingesetzt wird, um die Netzfrequenz stabil zu halten. 2019 fiel die Netzfrequenz schlagartig auf 49,8 Hz, was einem Blackout nahekommt. Es wird vermutet, dass eine fehlerhafte Datenübertragung und die darauffolgende Reaktion einer vollautomatischen Regeleinrichtung der Grund waren. Auf jeden Fall stiegen die Preise für Regelenergie sprunghaft an (vgl. Sperling 2019). Als Grund für die Instabilitäten des Stromsystems macht Weyer Interessengegensätze aus: »Ferner kann die Frage nach der Sicherheit und Zuverlässigkeit komplexer technischer Systeme gestellt werden, die unter den Bedingungen verschärften Wettbewerbs operieren müssen und zudem von unterschiedlichen Handlungslogiken geprägt werden. Für einen Stromhändler beispielsweise hat die Stabilität des Systems nicht oberste Priorität, so dass seine Transaktionen das Energienetz zusätzlich belasten können.« (Weyer 2010: 844) Netze bekommen so einen prekären und riskanteren Status, anders als das bei den »High-Reliability-Organisationen der 1980er Jahre der Fall war« (ebd.). Das Beispiel soll verdeutlichen, dass es ein langwieriger Regulierungsprozess ist, um ein stabiles System herzustellen, bei dem auch die Softwareentwickelnden gefragt sind und die Regulierung nicht mit dem Erlassen einer Verordnung erledigt ist. Institutionen und Technologien entwickeln sich wechselseitig in einem Prozess der Koevolution (vgl. Rohracher 2007: 148). Wobei die IT selbst institutionalisiert und »Part of the Furniture« (Silva/Backhouse 1997) der Energiewirtschaft wird. 7.2.2.3. Dezentrale Erzeugungsanlagen gebündelt vermarkten: virtuelleKraftwerke Mit der Energiewende wurde die Dezentralisierung der Stromversorgung wieder zum Thema. Einige Autoren haben die Hoffnung, dass mithilfe von IT und weniger kapitalintensiven Erzeugungsanlagen eine wettbewerbliche Organisation der Stromwirtschaft möglich ist (vgl. Voß/Bauknecht 2007: 119). Weil es den Regelenergiemarkt gibt und die Möglichkeit, mehrere Erzeugungsanlangen zusammen dort zu vermarkten, wurde dafür eine informationstechnische Lösung gefunden: virtuelle Kraftwerke. Mittlerweile haben schon einige EVU (bspw. RheinEnergie45 aus Köln oder die Stadtwerke Rosenheim46) solche Kraftwerke aufgebaut. Lichtblick (1999 gegründet) war eine der ersten Firmen, die solch ein virtuelles Kraftwerk geschaffen haben. Darunter versteht man die Steuerung mehrerer dezentraler Anlagen, als wären sie ein einziges Kraftwerk (im Falle von Lichtblick Gasmotoren, die Strom und Wärme produzieren – sogenannte Mikro-Blockheizkraftwerke/-BHKWs, Batterien und PV-Anlagen). Die 45 https://www.rheinenergie-trading.com/de/produkte_2/services_strom/virtuelleskraftwerk.html, abgerufen am 13.07.2023. 46 https://www.swro.de/de/dienstleistungen/energievermarktung, abgerufen am 13.07.2023. 152 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung Steuerung des Kraftwerkpools, zu dem auch die vielen kleinen, in den Kellern von Privatpersonen stehenden Mini-BHKWS gehören, übernimmt die von Lichtblick entwickelte Software »SchwarmDirigent« (vgl. von Petersdorff 2013). Es gibt mittlerweile einen technischen Standard für virtuelle Kraftwerke (siehe 7.1.3.2) und weitere Softwareprodukte (bspw. von Next Kraftwerke47), mit denen EVU unterschiedliche Erzeugungsanlagen zusammengeschalten können. 7.2.3. Softwaregestaltende: gesteigerte Interdisziplinarität undInterventionBetriebsrat Die Energiewirtschaft verlangt von Softwaregestaltenden im besonderen Maße, interdisziplinär zu arbeiten, und der Organisationsgrad der Branche, dass sie sich mit Betriebsräten arrangieren. Der Anteil der Akademiker:innen steigt und es muss intensiv interdisziplinär gearbeitet werden. Neben den komplizierten energietechnischen Anlagen (Netze, Kraftwerke etc.) sorgen die ständigen Änderungen der Regulierung dafür. Bei deren Übersetzung in Algorithmen müssen juristische Texte interpretiert werden, energiewirtschaftliches Wissen und Kompetenzen in der Softwareentwicklung vorhanden sein. Wie kompliziert die Umsetzung der Regulierung ist, zeigt sich daran, dass die Verbände für größere Gesetze und Verordnungen immer Anwendungshilfen herausgeben48. Obwohl die EVU selbst Fachleute haben, um zwischen gesetzlicher Regulierung und Software zu übersetzen, ziehen sie und Softwarefirmen für die Programmierung bei Bedarf zusätzlich Jurist:innen zurate, wofür es spezialisierte Rechtsanwaltskanzleien gibt (bspw. Becker Büttner Held). So sparen sie Zeit, weil nicht immer das Know-how vorhanden ist, um juristische Texte zu verstehen, und sie gehen sicher, nichts falsch zu machen. Wenn auch der hohe Organisationsgrad nicht den Personalabbau und Restrukturierung verhindern konnte (wie oben beschrieben), ist doch der Betriebsrat entscheidend dafür, eine mögliche digitale individuelle Leistungs- und Verhaltenskontrolle zu verhindern: »Inwiefern die Möglichkeiten der zunehmenden Transparenz für eine Leistungs- und Verhaltenskontrolle genutzt werden, hängt stark davon ab, ob es im Unternehmen einen Betriebsrat gibt.« (Roth 2018: 76) 7.3. Fazit: Software und Softwareentwicklung als Bausteine derIndustrie-Governance In der Stromwirtschaft gibt es für Software vielfältige Anwendungsbereiche in den Wertschöpfungsstufen Vertrieb, Netz, Handel und Erzeugung. Die Besonderheiten des Softwareeinsatzes sind, dass Software tragend für die Regulierung ist (bspw. Marktkommunikation), aus systemstabilisierenden Notwendigkeiten resultiert (bspw. Strommengen- 47 https://www.next-kraftwerke.de/unternehmen/technologie, abgerufen am 13.07.2023. 48 https://www.bdew.de/service/anwendungshilfen/, abgerufen am 13.07.2023. 7. Industriespezifische Aspekte der Softwaregestaltung inder Energiewirtschaft 153 bilanzierung) oder die Marktintegration von dezentralen Erzeugungslangen ermöglicht (bspw. virtuelle Kraftwerke). Der Ansatz der Industrie-Governance zeigt, dass die Softwaregestaltung für alle Arenen relevant ist: Die Unternehmen müssen sich eine Strategie überlegen. Dabei steht die reine Anwendung einer Standardsoftware für viele EVU im Mittelpunkt. Es stehen viele Firmen zur Verfügung, die dafür Softwarelösungen anbieten. Die EVU sind dann von den Lebenszyklen der Softwarepakete abhängig. Gleichzeitig profitieren sie von softwaretechnischen Innovationen. Einige machen sich auf, selbst Software zu gestalten und zu programmieren – für sich und für andere. Genaue Zahlen dazu gibt es nicht. Für die Arenen der Produktmarkt- und Prozess-Governance ist Software entscheidend, um diese in der Form, wie sie die Regulierung vorgibt, umzusetzen: sei es für den Datenaustausch zwischen Firmen, den aus Sicht der Verbrauchenden unkomplizierten Wechsel des Stromlieferanten, die Strommengenbilanzierung, neue Geschäftsfelder wie virtuelle Kraftwerke oder die Vermarktung von Ökostrom. Für die Beschäftigten bedeutet der zunehmende Softwareeinsatz zunehmende Akademisierung und ruft die Betriebsräte auf den Plan, zumindest bei der individuellen Verhaltenskontrolle einzuschreiten. Oft ist die Umsetzung ohne Anwendende und allein mit Expert:innen möglich – ob für Regulierung oder Energietechnik (bspw. virtuelle Kraftwerke). Software hilft, existierende Strukturen zu erhalten. Dabei gibt es sowohl in der Software- als auch der Stromindustrie keine Anzeichen für eine Monopolisierung: In der energiewirtschaftlichen Softwareindustrie gibt es einerseits noch viele Anbietende von Software und neue Verdienstmöglichkeiten vor allem für große EVU und die großen, kooperativen IT-DL durch Softwareentwicklung und den Betrieb von Anwendungsplattformen. Andererseits gibt es viele kleinere Softwarefirmen und auch kleinere EVU programmieren selbst oder haben gar eigene Softwareunternehmen. In der Stromindustrie bleiben die vielen kleinen Unternehmen erhalten und damit auch die kommunalen Strukturen, weil sich Standardprozesse und die umfangreiche Regulierung digital durch Standardsoftwarepakete und Anwendungsplattformen abwickeln lassen. Um die genannten Thesen auf soliden empirischen Boden zu stellen, fehlen allerdings die quantitativen Zahlen. Unklar bleibt, welche Rolle die Spannung zwischen Profitorientierung und kommunaler Daseinsvorsorge beim Softwareeinsatz spielt. Es sei vorweggenommen, dass auch die Fallstudien das nicht aufklären können. 8. Formen und Folgen der Softwaregestaltung– dieEmpirie 257 rer Arbeit Kommunikation und Kooperation eine größere Rolle. Ihre Arbeit ist weniger durch die Software vorgegeben (z.B. bearbeiten sie nicht nur Restfälle). Für sie ist Software mehr ein Hilfsmittel. Sie sind interdisziplinär zwischen Anwendung und Entwicklung tätig. Mehrere Befragte geben explizit an, dass sie ihre Arbeit gern machen. Ihre Arbeit ist unterschiedlich stark formalisiert (z.B. wie genau der Ablauf des Anforderungsmanagements vorgegeben ist). Sie sind einer qualitativen Intensivierung ausgesetzt. Erstens sind sie das, weil sie in vielen Fällen IT-, energiewirtschaftliches und Methodenwissen kombinieren (Key User:innen, IT-Beratende, Anwendungsbetreuende) oder zumindest mit den jeweiligen Expert:innen kommunizieren können müssen (Anforderungsmanagende, IT-Projektmanagende). Zweitens arbeiten sie öfters gleichzeitig in mehreren Projekten und müssen mehrere Prozessabschnitte der Datenverarbeitung überblicken und die gestaltete Software ist nicht ihr alleiniger Arbeitsgegenstand. Die quantitative Intensivierung ist bei den Gestaltenden schwer zu beurteilen. Mehrere sprechen davon, dass es phasenweise mal mehr und mal weniger zu tun gibt und sie selbst Grenzen setzen müssen (durch Priorisierung oder »Nein« sagen können). Die meisten sprechen von einer geregelten Arbeitszeit. Zudem sind die Kontexte sehr unterschiedlich: ob sie für mehrere Kund:innen und in mehreren Projekten tätig sind oder nicht. Die Arbeit der Programmierenden wird durch die Tests anderer und/oder durch Code-Reviews von Kolleg:innen geprüft. Es ist durch die Ticketsysteme transparent, was sie abgearbeitet haben, und falls es regelmäßige Treffen wie Daily bei Scrum gibt, müssen sie den Teammitgliedern Rede und Antwort stehen. Ihre Spezialisierung und die meist schwierige Abschätzung des Arbeitsaufwandes geht mit einer fehlenden detaillierten Kontrolle von außen einher. Eine qualitative Intensivierung existiert bei den befragten Programmierenden, weil sie fachliches mit IT-Wissen kombinieren und in verschiedenen Projekten, Rollen oder für mehrere Kund:innen tätig sind. Sie spitzt sich bei Programmierenden wie im Fall eines Befragten von KOOP2 zu, der für mehrere, unterschiedliche energiewirtschaftliche Fachbereiche entwickeln muss und dadurch entsprechend mehr Wissen braucht. Zudem müssen aufgrund individueller Anpassungen für einzelne EVU bei KOOP1 und KOOP2 die Programmierenden den Überblick über diese individuellen Umsetzungen behalten. Einige Programmierende beschreiben es als positiv, wenn sie sich auch mal in neue Technologien einlernen müssen. Wie bei den Gestaltenden ist es bei den Programmierenden schwierig, pauschal von einer quantitativen Intensivierung zu sprechen. Sie arbeiten in den untersuchten Fällen meist Programmieraufgaben ab, für die Prioritäten vorgegeben sind. Das lässt Spielraum, um eigene Grenzen zu setzen: »Ich könnte mich gerne überlasten, aber ich tu’s nicht.« (Programmierer KOOP1) Eine Intensivierung ist aber nicht ausgeschlossen, wenn z.B. eine fixe Deadline existiert: wenn zu einem Stichtag mehrere umfangreiche Umsetzungen, z.B. aufgrund einer neu- en Regulierung, abgeschlossen werden müssen. Zwar arbeiten die Programmierenden in einigen Fällen für mehrere EVU gleichzeitig (bei KOOP1, KOOP2, KOOP3 und PAKET). Doch hat dies nicht zwangsweise eine quantitative Intensivierung zur Folge. Eine Programmierung kann für viele EVU gleichzeitig gelten (bspw. bei einer Standardsoftware), d.h., eine Fehlerkorrektur kann gleich mehrere Anfragen von EVU zufriedenstellen. 258 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung Die Anwendenden sind hierarchisch und von der Bezahlung Programmierenden und Gestaltenden untergeordnet. Die Anwendenden sind meist passiv und reagierend: Sie müssen sich auf Änderungen einstellen oder erfahren erst nach Fertigstellung, was sich geändert hat. Ihre Arbeit ist das Objekt der Gestaltung und nur wenige gestalten mit. Vor allem wenn die Softwaregestaltung intern stattfindet, können Anwendende eigene Wünsche äußern und der Betriebsrat die Mitgestaltung einfordern. Ihre Arbeit ist in den meisten Fällen das, was die Software nicht erledigen kann bzw. noch nicht in dieser abgebildet ist. Das bedeutet auch, dass sie fehlerhafte oder nicht ausgereifte Software kompensieren müssen. Sie fungieren als Puffer für mangelhafte Softwareentwicklung. In einem Fall ist die Cloud langsam (so ein Befragter von KOOP2), im anderen sind in den Softwareupdates Fehler, welche die Arbeit der Anwendenden belasten (PAKET), oder die Prozessintegration leistet der Anwendende manuell (INTERN2). Sie müssen mit den Reaktionszeiten leben, die sich durch die Zusammenarbeit mit einem IT-DL oder Softwareunternehmen ergeben. Diese Puffer-Position kann über Fragen der Softwaregestaltung hinausgehen und die Anwendenden können zu allgemeinen, operativen Puffern werden. Ein befragter Gruppenleiter, der auch operative Software anwendet, hatte Burnout. Diesen hatte er vor allem, weil zu wenig Personal vorhanden war, und wegen der ständigen regulatorischen Änderungen und des Termindrucks im Bereich der Energiemengenbilanzierung, in der er tätig ist. Bei der Energiemengenbilanzierung müssen zu einem Stichtag nicht nur Daten, sondern vor allem Geld fließen. Anderen Anwendenden wie der befragten Sachbearbeiterin war die Restfallbearbeitung zu viel Routinearbeit, weswegen sie die Stelle gewechselt hat. Zudem sind die Anwendenden direkt im Kontakt mit der Kundschaft. Der befragte Monteur meint, er bekommt die Aggressionen der Kundschaft ab, wenn er bspw. wegen einer Baustelle den Strom bei jemandem abstellen muss. Für einen Teil der Anwendenden findet eine qualitative Intensivierung statt, weil sie vermehrt in Prozesszusammenhängen denken müssen (Sachbearbeitende), mehrere Fachgebiete (Key User:innen) oder mehrere Netzgebiete und Sparten kennen müssen (Monteur:innen). Arbeiten Anwendende im BPO- Bereich, arbeiten sie für eine größere Kundschaft und es ist mit einer quantitativen Intensivierung zu rechnen. Wobei in einigen EVU diese auch unabhängig davon aufgrund von Personalmangel oder phasenweise durch IT-Projekte entsteht. Wissensverteilung – Praxisgemeinschaft und in Software materialisiertes Wissen Es lassen sich grundsätzlich drei Wissensgruppen unterscheiden: Programmierung, Anwendung und Gestaltung. Dabei fällt in den Fallstudien auf, dass es für die Softwaregestaltenden weniger darum geht, viel Wissen anzusammeln. Sie sind vielmehr dazu da, um Wissen in Software(quellcode) zu überführen. Primär geht es darum, an das notwendige interdisziplinäre Wissen heranzukommen und lernbereit zu sein. Wissen selbst zu haben ist zweitrangig, wenngleich nützlich und in den meisten Fällen vorhanden. Das Wissen von Softwaregestaltenden kann umfassend sein: Wissen über die Möglichkeiten der Softwaregestaltung und individuelle Bedarfe der EVU oder allgemeine der Branche zu haben. Methoden wie Scrum oder IT-Projektmanagement zu beherrschen. Manche setzen Softwaregestaltung selbst um, wenn sie programmieren oder Einstellungen an einer Standardsoftware vornehmen. Der Extremfall sind IT-Beratende, die sich energie- 8. Formen und Folgen der Softwaregestaltung– dieEmpirie 259 wirtschaftlich auskennen, Anforderungen schreiben, selbst programmieren und Einstellungen an einer Standardsoftware vornehmen. Doch auch sie müssen sich mit Anwendenden oder anderen Beteiligten wie IT-DL oder Softwarefirma absprechen. Die Praxis ist deshalb so entscheidend, weil die Software sich stetig verändert, ebenso wie die Organisationen und die Branche. Es muss immer wieder neu verstanden werden, was energiewirtschaftlich notwendig und was softwaretechnisch möglich ist. Drei Thesen stehen im Mittelpunkt der Zusammenfassung zur Kategorie Wissensverteilung: 1. Die Softwaregestaltung ist eine Praxisgemeinschaft, in der die Softwaregestaltenden arbeiten. 2. Für das Verständnis der Wissensverteilung ist das in Software materialisierte Wissen entscheidend. 3. Das Management verfügt nur selten über Wissen zur Softwaregestaltung. Erstens stellt sich der Arbeitsprozess der Softwaregestaltung in den Fallstudien als eine Praxisgemeinschaft dar. Sie verfügt über das Wissen zu Methoden der Softwaregestaltung, und wenn sie schon selbst kein tiefergehendes Wissen über energiewirtschaftliche Regulierung, Standardsoftwarelösungen oder Programmierung hat, schafft sie zumindest die Möglichkeit, sich darüber auszutauschen – ob längerfristig oder temporär in Projekten. Dass die Praxis wichtiger ist, als Wissen zu besitzen, zeigt sich an drei Aspekten: an a) dem kontinuierlichen Austausch zur Softwaregestaltung, der stattfindet und zu Anforderungen führt (von dem bestimmte Gruppen ausgeschlossen sind), dass b) unterschiedliche Praxis- und damit Lernbiografien entstehen und c) EVU feststellen, dass sie nur dann Software gestalten können, wenn sie Teil dieser Praxis sind. Zu a) In der Softwaregestaltung arbeiten Beschäftigte zwischen Anwendung und Programmierung zusammen. Auch einzelne Anwendende wie Key User:innen sind Teil davon. Die Gestaltenden haben Kontakte, kennen die Organisation und einzelne Umsetzungen und Methoden wie Scrum. Es besteht ein kontinuierlicher Austausch zwischen einem Kern an Mitarbeitenden in den Fällen INTERN1, INTERN2, KOOP3, STARTUP, genauso wie bei PAKET intern in der Softwarefirma. Bei KOOP1 und KOOP2 sind es längere Beziehungen zwischen den Firmen und viele Treffen, welche eine gemeinsame Praxis herstellen. Aber auch innerhalb des IT-DL und teilweise in den EVU arbeiten die verschiedenen Gruppen kontinuierlich zusammen. Bestimmte Berufsgruppen wie IT-Beratende erfahren einen kontinuierlichen interdisziplinären Wissenserwerb. Sie machen nicht nur in verschiedenen Projekten mit, sondern sind sowohl fachlich nah an den Anwendungsbereichen als auch softwaretechnisch nah an der Software dran. Die Programmierenden verfügen in allen Fällen über energiewirtschaftliches Wissen, um die industriespezifischen Anforderungen umzusetzen. Zu b) Dabei bestimmt die Praxis, was die oder der Einzelne weiß. Es entstehen durch individuelle, interdisziplinäre Praxisbiografien individuelle Lernbiografien, weil je nach Softwaregestaltung die Softwaregestaltenden an unterschiedlichen Softwarelösungen, an unterschiedlichen Anforderungen, Projekten, energiewirtschaftlichen Themengebieten und mit unterschiedlichen EVU zusammenarbeiten. Wer mitgemacht hat bei der Gestaltung, weiß mehr darüber. Die klassische Lernbiografie von Ausbildung, dann Sachbearbeitertätigkeit, Wechsel in ein anderes Team oder Aufstieg zur Teamleitung gibt es 260 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung immer noch. Diese wird jedoch nun durch neue Möglichkeiten ergänzt. Vor allem die befragten Gestaltenden und Programmierenden haben mehr interdisziplinäres Wissen und Einkommen im Laufe der Zeit gewonnen, ohne dadurch hierarchisch aufgestiegen zu sein. Zu c) Dass die Praxisgemeinschaft den Zugang zu Wissen sichert, zeigt sich daran, dass das Wissen, das über Anforderungen in der Software eingeflossen ist oder dokumentiert wurde, allein nicht ausreicht. Es macht einen Unterschied, ob man Teil der Praxis war bzw. ist oder nicht. Das zeigen vor allem Marktbeziehungen, die zu einer Abhängigkeit führen und Hürden für eine gemeinsame Praxis darstellen. Bei KOOP2 verlagert ein EVU die Anwendung der Software zurück in das Unternehmen, um intern Wissen zu haben und die Softwaregestaltung selbst machen zu können. Zudem bauen einige EVU intern IT-Projektmanagement-Kompetenz auf. Innerhalb des IT-DL von KOOP1 arbeiten die Programmierenden eng mit energiewirtschaftlichen Fachleuten zusammen, wodurch ein stetiger Wissensaustausch besteht. Ein Klient des IT-DL von KOOP1 hat das Wissen, was das IT-DL über die Jahre über das EVU gesammelt hat, unterschätzt. Er hat den Wechsel zu einem anderen IT-DL bereut. Bei PAKET sind kleinere EVU abhängig von externem Support der Softwarefirma (z.B. durch IT-Beratende), weil sie intern keine ERP-Fachleute haben. Bei KOOP3 schickt das IT-DL Newsletter über Softwareupdates, die sich die EVU durchlesen können. Die reine Anwendung, die nicht an der Softwaregestaltung teilnimmt, ist aus der Wissensgemeinschaft Softwaregestaltung ausgeschlossen. Das ist in allen Fallstudien so. Zweitens prägt die Wissensverteilung die Arbeit der Softwaregestaltenden dahingehend, dass der zentrale Ort des Wissens die Software selbst ist: ob Quellcode der gestalteten Software oder die verwendeten Softwarewerkzeuge wie Ticketsysteme. Immer mehr Wissen, ob über energiewirtschaftliche Regulierung, Geschäftsprozesse, Arbeitsabläufe, Softwareänderung etc., wandert in Software. Dabei müssen die Softwaregestaltenden alles, was sie gestaltet haben, nicht mehr aktiv wissen – auch nicht, wie es die Programmierenden umgesetzt haben. Das zeigen alle Fallstudien: Peu à peu wächst durch Anforderungen die Software. In ERP-Systemen wie jenem aus der Fallstudie PAKET steckt alles, was zum operativen Betrieb der energiewirtschaftlichen Datenverarbeitung notwendig ist. Dabei findet die Softwaregestaltung in einem technischen Umfeld aus lesbaren Objekten statt. Softwaregestaltende dokumentieren in den softwarebasierten Werkzeugen wie Ticketsystem, Dokumentationssoftware20, MS Sharepoint oder E-Mails (inkl. Newsletter über Updates), Programmierende im Quelltext der Software selbst. Was alle Befragten egal welcher Gruppe sagen, ist, dass Learning by Doing für sie wichtig ist – ob aus Dokumenten oder mit der Software selbst. Auch wenn viel Wissen lesbar oder durch Ausprobieren und Mitmachen erlernbar ist, sieht ein Befragter Software als primäres Wissensquelle und -lager kritisch: Ein Betriebsrat findet, dass sein EVU zu sehr auf Learning by Doing im Softwaregebrauch setzt. Es sollten wieder mehr Schulungen stattfinden. Ein befragter Programmierer hält eine Art Führerschein für Anwendende für hilfreich, weil sie in der alltäglichen Anwendung nicht alles lernen (bspw. die Zusammenhänge und Einstellungsmöglichkeiten in der Software). Bei PAKET sagen 20 Eine weit verbreitete Softwarelösung dafür, die auch STARTUP einsetzt, ist Confluence der Firma Atlassian. 8. Formen und Folgen der Softwaregestaltung– dieEmpirie 261 mehrere befragte Personen, dass die Anwendenden eine funktionierende Software wollen, sich nicht eigenständig mit den möglichen Einstellungen befassen möchten und in ihrem Arbeitsalltag nicht genug dazu lernen. Drittens verfügt das Management wie Team-, Abteilungs-, Bereichs- oder IT-Lei- tung nur in wenigen Fällen über Softwaregestaltungswissen. Größtenteils nimmt es nicht direkt an der Softwaregestaltung teil und interveniert teilweise nur bei der Auswahl der Anforderungen. Drei befragte Team- bzw. Gruppenleitende wirken bei der Softwaregestaltung mit. Wobei es dabei immer um eine Standardsoftware geht, die nur durch Einstellungen von den EVU verändert werden kann. Softwaregestaltungskompetenzen haben nur wenige FK (wie z.B. Schulungen in Scrum oder IT-Projektmanagement). Das Management setzt den Rahmen z.B. durch das IT-Budget oder kann in Matrixorganisationen ein wichtiger Sponsor für Softwaregestaltungsprojekte sein, indem es z.B. die Zusammenarbeit mit anderen Abteilungen durch die Führungskräfte dort vorantreibt. KOOP1, KOOP2 und PAKET nutzen Marktmechanismen und kaufen die Software(gestaltung) ein. Der Nachteil ist, dass das Wissen dann nicht direkt im Zugriff des EVU- Managements ist. Wie auch allgemein für Anwendung und Entwicklung hat das alles zur Folge, dass das Management bzw. die Führungskräfte keine direkten, konkreten Anweisungen mehr geben können, weil ihnen das Wissen dazu fehlt. In dem Fall, in dem Arbeitsanweisungen gemacht werden, erstellen dies die Key User:innen (PAKET, EVU5). In anderen Anwendungsbereichen werden keine verwendet (Sachbearbeitende KOOP2 EVU1, Teamleitung EVU2 KOOP2, Anwendende KOOP1 EVU3, Anwendende EVU1 KOOP1). Die Sachbearbeitenden von EVU2, KOOP2 haben nur ein Schema, wie sie vorgehen sollen, weil die Fälle zu individuell sind. Allgemein wird das Wissen immer umfangreicher und eine Organisation allein kann nicht mehr darüber verfügen. Zum Beispiel sind bei INTERN1 und INTERN2 einige programmierende Externe. Bei KOOP1, KOOP2, KOOP3 verteilt sich das Wissen auf mehrere Organisationen. Die fachliche Spezialisierung der Mitarbeitenden nimmt zu und damit das Wissen, was ihre Führungskräfte nicht haben: u.a. durch Automatisierung, komplexere Regulierung, gestiegene Bedeutung von IT, höhere Ansprüche der Kundschaft, Produktvielfalt. 8.5. Folgen für die soziotechnische Arbeitsgestaltung derSoftwareanwendung in den EVU Ein Teil der Arbeitsgestaltung der Softwareanwendung in den EVU hängt an der Softwaregestaltung. Der Abschnitt nimmt diesen Teil in den Blick, der sich aus dem Verhältnis der Arbeitsprozesse von Softwaregestaltung und Softwareanwendung ergibt. Er lässt sich mithilfe der Kategorien Einfluss und Konflikt analysieren. Anders als im letzten Punkt 8.4. geht es dabei nicht um einzelne Gruppen von Beschäftigten. Es geht um das Verhältnis zweier Arbeitsprozesse zueinander, über das nicht nur die operativ Softwaregestaltenden oder -anwendenden entscheiden, sondern in den Fällen, wo Hierarchien vorliegen, das Management strategische Entscheidungen fällt, Ziele vorgibt, Ressourcen zur Verfügung stellt und eigene Anforderungen einbringt. Der Einfluss beider Arbeitsprozesse aufeinander betrifft vier Aspekte: 262 Johannes Sonnenholzner: Formen und Folgen der Softwaregestaltung • Kontrollverhältnis: Wird der Arbeitsprozess der Softwareanwendung jenem der Softwaregestaltung untergeordnet? Werden Softwareanwendung und -gestaltung z.B. getrennt in zwei verschiedenen Organisationen kontrolliert? • Reorganisation: Wird der Arbeitsprozess der Softwareanwendung zum Zwecke der Softwaregestaltung reorganisiert? • Ziele: Wie verhalten sich die jeweiligen Ziele von Softwareanwendung und -gestal- tung zueinander und wer kann sie festlegen (z.B. individuell etwas für einen Anwendungsbereich zu entwickeln oder eine skalierbare Standardsoftware; die Anwendungsorganisation zu reorganisieren oder nicht)? • Partizipation: Wer gestaltet wie mit? Wer aus der Softwareanwendung hat Zugang zur Softwaregestaltung? Welche Rollen nehmen Expert:innen ein und wie verhalten sich Anwendenden- und Unternehmens- bzw. Managementanforderungen zueinander? Für zwei der genannten Aspekte des Einflusses der Softwaregestaltung auf die Softwareanwendung diskutiert der Abschnitt folgende Thesen: 1. Für die Reorganisation deutet sich in einigen EVU an, dass sie sich auf eine bestimmte Form der Organisation zubewegen: eine auf die Softwaregestaltung ausgerichtete softwaretechnische Prozessorganisation. Eine solche Organisation bedeutet nichts anderes, als dass die Softwaregestaltung die Software und die Organisationen eines End-to-end-Prozesses übergreifend und ohne die Behinderung durch Fachbereichsgrenzen ändern kann. 2. Hinsichtlich der Partizipation stellt sich die Frage, inwieweit die Anwendenden an der Gestaltung der Software beteiligt sind und ob sich die Fälle Partizipationstypen zuordnen lassen. Die Konflikte zwischen Gestaltung und Anwendung sind entweder innerhalb (wie jene zwischen Management- und Anwendendenanforderungen) oder außerhalb der EVU (wie z.B. zwischen individuellen Alleingängen einzelner EVU und kooperativem Standard mehrerer EVU). Dabei zeigen die Fallstudien, dass Betriebsräte innerhalb der EVU bei der soziotechnischen Arbeitsgestaltung insofern mitbestimmen, indem sie intervenieren, aber nicht aktiv gestaltend sind. Sie spielen bei Fragen der Partizipation insofern eine Rolle, als sie bei Rahmenbedingen mitentscheiden und weniger bei der inhaltlichen Gestaltung der Software (z.B. wenn ein Betriebsrat einfordert, dass die Softwaregestaltung Anforderungen der Anwendenden berücksichtigt). Dieser Abschnitt geht in den folgenden Punkten auf die Unterschiede zwischen den Fallstudien ein, stellt die Fälle mithilfe der Kategorien Einfluss und Konflikt einzeln dar und fasst die Ergebnisse zusammen. 8.5.1. Soziotechnische Arbeitsgestaltung: zwischen Abhängigkeit undUnabhängigkeit Die Fälle lassen sich dahingehend unterscheiden, ob die EVU unabhängig oder abhängig von IT-DL oder Softwarefirmen die Arbeit der Softwareanwendung gestalten können. [Document text truncated for crawler view.]