Soziotechnische Systeme

Anja: Hallo und herzlich willkommen beim INNOQ Podcast. Heute sprechen wir über soziotechnische Systeme und dafür habe ich mir meine zwei Kolleginnen eingeladen, Katharina Baur und Lena Kraaz.

Anja: Hallo Katharina.

Katharina Baur: Hallo!

Anja: Hallo Lena.

Lena: Hallo!

Anja: Schön, dass ihr da seid. Könnt ihr kurz erklären, was eure Rolle bei INNOQ so ausmacht? Denn ihr habt ja die gleiche Rolle, soweit ich weiß.

Lena: Katharina und ich arbeiten als P-Sternchen, so nennen wir das bei INNOQ, bei Kunden und in Projekten. Mit P-Sternchen meinen wir alle Rollen, die nichts damit zu tun haben, dass man Code entwickelt, sondern wir arbeiten dort als Product Owner oder Scrum Master oder Agile Coaches und unterstützen dort so die Projekte, aber wir entwickeln halt keinen Code.

Anja: INNOQ ist ja so ein Consulting-Unternehmen, welches eher den Fokus hat auf technische Umsetzung und auch die praktische Umsetzung von Software-Projekten. Wie seid ihr denn auf dieses Thema soziotechnische Systeme gekommen? Also ich muss dazu sagen, ich mag dieses Thema auch sehr, aber ich möchte gerne wissen, warum ihr auf dieses Thema gekommen seid.

Katharina: Ich finde der Begriff soziotechnische Systeme ist auch so ein Begriff, der viel verwendet wird. Man hört einzelne Elemente davon, die sagen einem auch irgendwie was. Es ist jetzt nicht so komplett rätselhaft, aber mich hat es einfach interessiert, was steckt denn da genau dahinter? Ich wollte einfach tatsächlich diesen Begriff genau verstehen, habe dann so eine kleine Quer-Recherche gemacht und habe dann mit meiner Kollegin Lena gesprochen und gefragt, ob sie Lust hätte, das zusammen zu machen und es hat sehr gut gepasst, weil wir zusammen schon so eine kleine Reihe gestartet haben mit kleinen Lightning-Vorträgen zu Themen aus Soziologie und Psychologie, so kurze 15-Minuten- Vorträge bei internen Veranstaltungen, weil wir glauben, dass es viele Menschen interessiert.

Lena: Genau und was wir auch gemerkt haben, glaube ich, je mehr wir uns damit beschäftigt haben, mit dem Thema, haben wir immer wieder gemerkt, wie sehr uns das eigentlich auch betrifft in den Projekten. Also das ist tatsächlich etwas, womit wir eigentlich jederzeit zu tun haben und deswegen war die Idee, die wir hatten, war ja auch, etwas zu erzählen, womit die Kolleginnen und Kollegen auch was anfangen können und was ihnen vielleicht auch irgendwas bringt, wo sie was mitnehmen können in die Projekte und ich glaube, dafür eignet sich dieses Thema total gut. Ja, weil wir immer in Projekten vor Ort tatsächlich mit diesen Themen auch konfrontiert sind.

Anja: Also bei Soziotechnik fällt mir auch immer ein, dass man sagt, Softwareprojekte scheitern nicht immer aus technischen Problemen, sondern aus organisatorischen Problemen und das ist genau das, was Soziotechnik für mich ausmacht. Also wenn ich zum Beispiel in ein Software-Review reingehe und mir dort eigentlich Software anschauen sollte, dann merke ich meistens, das Problem ist meistens gar nicht die Software. Die Software sieht gut aus, das sind ExpertInnen, die wissen, was sie tun. Meistens ist die Organisation, die da Softwareprojekte zum Stillstand bringen lassen oder die Blockaden produzieren.

Lena: Also es geht auf jeden Fall um eben diese Vermengung von Technik und sozialen Strukturen und das ist ja genau das, was du sagst. Also in dem Moment, wo diese beiden Dinge aufeinandertreffen rumpelt und ruckelt es gegebenenfalls. Und gerade wir als BeraterInnen kommen ja auch schon immer in ein Setting rein, das es schon lange gibt. Also wir sind nicht die, die das mit aufgebaut haben und kennen all diese Strukturen, sondern das ist etwas Bestehendes. Wir kommen da rein und müssen irgendwie, sollen aber beraten und sollen irgendwie möglichst klug und nachhaltig auch beraten und kennen aber ganz viele Strukturen gar nicht. Und das, damit meine ich sowohl das Technische, aber vor allen Dingen auch eben diese sozialen Strukturen und diese ganzen Strukturen auch, die man nicht auf den ersten Blick sieht. Und deswegen, das finde ich gerade für uns halt total wichtig zu erkennen, wie wichtig ist eigentlich dieser Anteil von Kommunikation und Organisation und so bei solchen technischen Themen.

Katharina: Also spannend an diesem Thema, soziotechnische Systeme, ist tatsächlich auch, woher das eigentlich kommt und wie das auch zum Teil für eine Brücke schlägt, von vor über 100 Jahren bis heute. Tatsächlich dieselben Themen, die immer noch eine Rolle spielen. Und zwar bei meiner kleinen Quer-Recherche bin ich eben auf diese Geschichte gestoßen, wie man sozusagen zum ersten Mal diese Zusammenhänge zwischen Technik und dem sozialen System festgestellt hat. Und zwar müssten wir uns da zurückbegeben in den Bergbau in England, Anfang des 20. Jahrhunderts. Und ich weiß nicht, wer schon mal Bilder gesehen hat, wie das in diesen Stollen damals ausgesehen hat. Also Männer, die wirklich in Handarbeit mit einfachen Werkzeugen Kohle abgebaut haben, in kleinen Gruppen, die sich sehr, sehr aufeinander verlassen mussten, was eine unglaublich gefährliche Arbeit war. Die haben nicht nur zusammengearbeitet damals, sondern sie haben auch in der Nähe der Minen gelebt. Da gab es enge familiäre Verbindungen zwischen den Arbeitern, die in einer Gruppe gearbeitet haben. Die gaben sich gegenseitig Schutz. Die mussten sich aufeinander verlassen. Und das waren ganz, ganz außergewöhnliche Arbeitsbedingungen, unter denen die Menschen damals gelebt haben. Unglaublich gefährlich auch. Und wie gesagt, Handarbeit. Irgendwann hat auch in dem Bergbau die Technologie Einzug gehalten. Durchaus nicht nur, um die Produktivität zu steigern, sondern durchaus auch, um Schutz zu geben. Man dachte, naja, also größere Maschinen schützen auch die Menschen, ausgefeiltere Systeme schützen die Menschen. Und das hatte nicht nur eben das Ziel, mehr Umsatz zu machen, sondern tatsächlich auch die Menschen zu schützen. Und dann wurden diese Maschinen eben im Rahmen der Entwicklung, der technischen Entwicklung eingeführt. Und dann hat man etwas sehr Interessantes festgestellt, und zwar nach der mechanischen Aufrüstung gab es weniger effiziente Ergebnisse. Es gab tatsächlich einen verstärkten Widerstand der Arbeiter.

Anja: Ja, genauso wie in der Softwareentwicklung. Wahnsinn. Also wir wollen etwas modernisieren, besser machen und was macht die Belegschaft? Erstmal rebellieren.

Katharina: Erstmal rebellieren. Genau, es gab auch richtig moralische Probleme, interne Kämpfe, Schuldzuweisung. Also völlig unerwartet in dem Moment, zu der damaligen Zeit, was da passiert. Und das war dann so interessant, diese Vorgänge in diesen Kohlebergwerken, dass sich ein gewisser Eric Trist und ein gewisser Ken Bamford mit diesem Thema beschäftigt haben. Die geforscht haben im Rahmen des Travistock Institute 1951 und die haben sich diese Vorgänge in den Minen mal genauer angeguckt und erforscht, was da eigentlich passiert ist. Und was sie herausgefunden haben, ist eben, dass diese alten Systeme, also diese informellen Systeme, die die Werkarbeiter da gebildet haben, dass die durch diese Maschinen eben aufgebrochen wurden.

Anja: Was meinst du mit ‘informelle Systeme’?

Katharina: Also diese Gruppen, die da zusammen in den Minen gearbeitet haben, die haben sich selbst organisiert. Also die haben nach der Notwendigkeit der Aufgabe, haben die in ihrem Team beschlossen, wer ist für was verantwortlich. Die Aufgaben haben auch durchgewechselt, also es gab jetzt kein irgendwo festgeschriebenes Vorgehen für die Arbeit in diesen Gruppen. Die Gruppen haben sich selbst organisiert, die wurden auch bezahlt nach quasi Output. Also nach Kilogramm, weiß ich nicht, Tonne Kohle, die eben nach oben befördert wurden. Und es war eine Selbstorganisation und das alles basierend auf der Notwendigkeit, Kohle abzubauen, aber auch sich gegenseitig zu schützen. Also da ging es ja wirklich um Leben und Tod.

Lena: Und deswegen auch dann ja ein ganz starker Zusammenhalt in dieser Gruppe ja auch da war und ganz enge Bindungen da waren. Und wahrscheinlich konnte man diese informellen Strukturen, vermutlich hatte jede Gruppe ja auch ihre eigenen Informalitäten sozusagen und die waren vielleicht auch nie irgendwo aufgeschrieben oder so, aber die waren halt super wichtig dafür, dass der Bergbau eben lief und dass tatsächlich auch Kohle irgendwie nach oben kam.

Katharina: Genau.

Anja: Also so ein wenig kann man sich das schon in Softwareprojekten vorstellen. Also man hat schon ein paar Assoziationen, aber es ist natürlich etwas anderes. Im Kohlebergbau geht es eher um die Sicherheit des Menschenlebens. Also das ist ja nicht unbedingt etwas, was man mit der Softwareentwicklung assoziieren kann. Aber also andere Dinge, also eine eingeschworene Gemeinschaft, das ist das Entwicklungsteam. Dann Dinge, die nicht aufgeschrieben werden, aber klar sind, das ist eben, wie Entwicklungsteams sich organisieren. Das ist meistens nicht aufgeschrieben, sondern sie organisieren sich eben so, wie sie es gelernt haben. Da kann man schon Parallelen sehen.

Katharina: Also es gibt auch noch ein paar mehr Parallelen, die vielleicht noch relevanter sind für heute. Das ist zum Beispiel die wachsende Bürokratie, die dadurch entstanden ist. Also durch diese Fragmentierung der Gruppen und durch die Spezialisierung, Rollentrennung gab es auch viel mehr Bürokratie. Man brauchte wieder ein Management, das steuert Zwischenschichten und so weiter und so fort. Und das glaube ich, das kommt allen bekannt vor. Überorganisieren führt dann oft auch dazu, dass eben auch mehr Schichten entstehen und mehr Bürokratie entsteht, was früher einfach in einer Art selbstverständlichen Vorgängen sich organisiert hat. Genau, und das hat eben zu dieser Auflösung der ursprünglichen Verbindung eben auch geführt und auch zu einer großen Unzufriedenheit.

Lena: Das war wahrscheinlich ja auch in gewissem Maße eine Überraschung. Wahrscheinlich war ja die Idee, wir geben euch Maschinen, ja, und die sollen, das hast du ja auch gesagt, Katharina, die Intention war ja nicht, irgendwas schlechter zu machen, sondern eigentlich besser zu machen. Dann, ihr habt es leichter, hier ist es nicht mehr so gefährlich, ihr müsst vielleicht nicht mehr so hart arbeiten. Und ich vermute, dass es ja auch irgendwie eine Überraschung war, dass die Produktivität tatsächlich gesunken ist.

Katharina: Genau, aber das war so signifikant und so eindeutig, dass natürlich die beiden Forscher da auch ganz genau untersucht haben und versucht haben, auch was daraus abzuleiten. Was sind denn eigentlich die Kernelemente von dem, was da passiert ist? Und das ist tatsächlich diese Aufteilung von Arbeitssystemen, ein technisches und soziales Teilsystem. Also das war so das erste Mal, dass diese Unterscheidung gemacht wird und dieses Zusammenwirken von diesen beiden Themenbereichen, also technisches System und soziales System, die zusammenwirken müssen, um eine Aufgabe zu erfüllen. Und das war so eine große Erkenntnis, die da aus diesem Beispiel, aus dem Bergbau, gezogen werden konnte.

Anja: Zuerst hatte ich das Bergbaubeispiel so verstanden, es gibt BergarbeiterInnen, das habe ich jetzt mit SoftwareentwicklerInnen assoziiert. Die bekommen jetzt neue Tools oder es gibt jetzt eine Modernisierung. Da hatte ich mir jetzt gedacht, okay, die gehen jetzt in die Cloud zum Beispiel und das bringt neue Tools mit sich. Und dann, da ging es eher um nutzungszentriertes Arbeiten und das sind für mich zwei unterschiedliche Dinge. Einmal das sozialtechnische System wäre, das an der Software arbeiten, also mit Entwicklungsteams, mit der Organisation in der Cloud irgendwas Technisches machen, was die NutzerInnen gar nicht sehen im Hintergrund. Und das andere ist das, was die NutzerInnen sehen und benutzen.

Katharina: Das liegt daran, dass quasi die Rolle der Entwickler auch oft die ist, dass die quasi eine Technologie entwickeln, die dann von anderen genutzt werden müssen und wir sind beides. Weißt du, wir sind ja beides. Wir sind welche, die quasi neue Tools bekommen, die Cloud und betroffen sind von der Situation. Aber gleichzeitig sind wir diejenigen, die die neue Technologie mitbringen. Und unsere Verantwortung liegt darin, dass wir diese Technologie auf eine Art und Weise mitbringen, dass wir das soziale System mit einbeziehen können und dass eben diese Störung nicht hervorruft. Wir sind ja beide Opfer und Täter, sozusagen. Wir haben einmal die Bergarbeiter aka EntwicklerInnen. Ich sage Bergarbeiter, weil es gab echt keine Bergarbeiterinnen, muss man einfach sagen. Die Untertage waren nur Männer. Okay, und dann kommt quasi von oben die Technologie und zum Beispiel die Cloud. Und die Arbeitsweise der EntwicklerInnen aka Bergarbeiter ist plötzlich gestört. Die müssen es anders machen. Die sind mit einem anderen technischen System konfrontiert. Aber das zweite Beispiel ist, dass wir sozusagen diejenigen sind als EntwicklerInnen, die eine neue Technologie in ein System einbringen.

Lena: Ja, richtig. Also wir schmeißen Technik auf Menschen, sozusagen. In dem Fall tun wir das.

Katharina: Genau. Und deswegen ist es ja für uns in dem Kontext unserer Arbeit so wichtig, dass wir uns dessen bewusst sind, dass wir uns Gedanken machen, welche Menschen sind denn da nachher überhaupt davon betroffen? Und können wir irgendwas dafür tun, damit diese Systeme reibungslos weiter miteinander arbeiten können? Das technische Subsystem und das soziale Subsystem? Oder bringen wir da einen Haufen Sand ins Getriebe? Aber die Lösung ist unter Umständen, zuzulassen, dass Abkürzungen genommen werden, dass Menschen selber entscheiden können, wie sie die Technologie nutzen, um an ein Ergebnis zu kommen. Und wir eben zulassen müssen, nicht die komplette Kontrolle zu haben und dieses soziale Subsystem mit einzubeziehen. Und zwar mit allen Vorteilen. Das hat extrem viele Vorteile. Menschen kooperieren miteinander, sprechen miteinander, finden optimale Lösungen. Und deswegen können wir Opfer sein, aber auch Täter sein in Bezug auf Technologie.

Anja: Nochmal etwas nebenbei. Wir reden jetzt über soziotechnische Systeme und ich weiß nicht, ob das neu ist in der Softwareentwicklung. Ich habe schon das Gefühl, es nimmt Fahrt auf und es wird jetzt trendy, dieses Thema. Ich finde, aus gutem Grund. Aber es gibt auch Stimmen, die sagen, wir haben das früher alles nicht gebraucht. Warum müssen wir uns auf einmal mit anderen Wissenschaften auseinandersetzen? Warum müssen wir uns jetzt mit Soziologie auseinandersetzen? Es geht doch um Informatik. Aber genau an diesem Beispiel merkt man, das ist der Grund, warum wir uns damit auseinandersetzen, weil es Parallelen gibt. Warum sollten wir nicht von anderen Wissenschaften lernen, um unsere Arbeit besser zu machen? Wenn wir die Antwort nicht kennen, kennen sie vielleicht andere Wissenschaften.

Lena: Genau. Und ich glaube tatsächlich, dass wir mal versuchen zu mappen auf Softwareprojekte. Ich glaube tatsächlich, es kommt halt darauf an, was man entwickelt. Aber ursprünglich hatten wir uns so ein Beispiel ausgedacht, wo wir sagen, wir kommen in ein Unternehmen und sollen dort eine App entwickeln für den internen Gebrauch. Also in diesem Unternehmen hat sich vielleicht ganz viel geändert an Kommunikationsstrukturen oder interner Organisation, weil es gab irgendwie Covid. Es gibt jetzt ganz viel Remote-Arbeit. Es wird viel mehr asynchron kommuniziert. Es gibt weniger Bürotische. Sie haben reduziert und die Geschäftsführung sagt halt, okay Leute, wir möchten, dass wir irgendwie eine App dafür haben, dass ihr euch organisieren könnt. Und die Intention mag auch valide sein. Das ist ja auch eine gute Idee. Dennoch, wenn wir dann gerufen werden als INNOQ und sollen da unterstützen, dann muss uns ja klar sein, dass in dieser App Vorgänge natürlich bürokratisiert werden, das, was Katharina gerade gesagt hat, die vorher einfach so liefen. Und das ist ja, wenn wir nicht verstehen, was vorher die informellen Strukturen waren, die wir jetzt formalisieren sollen, dann kann aus dieser App nichts werden, weil die Leute werden das nicht benutzen, wenn man das nicht schafft, das irgendwie richtig abzubilden. Und ich glaube, dass das wahnsinnig schwierig ist, denn es gibt ja nicht die eine informelle Struktur. Wahrscheinlich gibt es 15 verschiedene Wege, wie Leute sich strukturiert haben, wer an welchem Bürotisch sitzt oder so. Da gab es bestimmt ganz viel ungeschriebene Gesetze, die auch gar nicht so umfassend in der Software dann abzubilden sind. Das heißt, man steht da wirklich vor einem Problem. Und wenn man sich dem nicht bewusst ist, dann besteht auf jeden Fall eine größere Chance, dass diese Applikation am Ende nicht genutzt wird. Und deswegen, glaube ich, ist es wirklich, wirklich relevant für uns, das im Hinterkopf zu haben. Egal, ob man Backend-Entwickler ist oder Produktmanagerin. Ich glaube, es ist wichtig, das zu beachten.

Katharina: Und es ist auch nicht das erste Mal, dass in der Geschichte der Informatik oder der Softwareentwicklung so eine Erkenntnis, so ein Groschen gefallen ist. Also man hat ja früher auch Softwareentwickler, da haben halt Informatiker Software entwickelt, so wie die dachten, wie die halt benutzt wird später. Und irgendwann, im Nachhinein kann man es gar nicht glauben, aber das war wirklich ein revolutionärer Gedanke, zu erkennen, dass wir die Nutzer befragen müssen, bevor wir Software entwickeln. Und ich glaube, es ist ein ähnlicher Schritt und eine ähnliche Erkenntnis, dass Software nicht entwickeln kann, ohne die Nutzer, die Nutzerin, ohne das soziale System, ohne den Kontext zu beachten. Und ich denke auch, dass das noch nicht das Ende dieser Entwicklung ist. Und das, was du auch sagst, dieses sich an anderen Wissenschaften zu bedienen, das befördert es natürlich. Also Erkenntnisse aus Soziologie, Psychologie helfen das sicherlich. Organisationsentwicklung, Arbeitspsychologie, das sind alles Themen, weil wir einfach keine Software entwickeln können, ohne dass die Schnittstellen mit Menschen hat. Und deswegen müssen wir auch die Menschen verstehen und nicht nur die Technik verstehen.

Lena: Ich glaube, dieser ganze Trend hin zum User-zentrierten Denken bei der Softwareentwicklung ist natürlich ein Riesenschritt, der auch dabei hilft, dass man andere Wissenschaften noch mit einbezieht. Also wenn man jetzt wirklich anfängt zu überlegen, was wäre eigentlich für die Nutzer oder NutzerInnen am besten, dann kommt man ja in ganz andere Bereiche noch rein. Diese ganze User Experience oder User Tests und die Requirements Analyse. Mit wem spricht man eigentlich? In dem Beispiel, was ich eben gebracht habe, kommt ja der Auftrag zum Beispiel von der Geschäftsführung. Die Geschäftsführung kennt vermutlich viele informelle Strukturen gar nicht. Oder beziehungsweise hat auch ihre eigenen informellen Strukturen. Und das heißt, es reicht jetzt nicht, mit den Menschen aus der Geschäftsführung zu reden, die bezahlt das zwar und die hat es auch in Auftrag gegeben, aber man muss sich wirklich gut überlegen, mit wem spreche ich eigentlich für die Anforderungsanalyse.

Anja: Ja, obwohl die Geschäftsführung hier ja auch Anforderungen hat. Es gibt ja einen Grund, warum sie diese Software brauchen. Weil sie, ich weiß nicht weshalb, weil sie irgendwelche Auflagen erfüllen müssen, weil sie irgendwas nachweisen müssen, dein Beispiel. Genau, aber wo ist jetzt der Unterschied zum Usability Engineering? Wir könnten jetzt auch einfach sagen, alles klar, ich muss mich irgendwie um User Tests kümmern, ich muss mich um Anforderungsanalyse besser kümmern und damit habe ich das alles abgefrühstückt.

Katharina: Die Methoden mischen sich natürlich. Also da gibt es ganz viel Überschneidung zwischen nutzerzentrierter Entwicklung und Usability, Usability Testing, UX und so. Also das spielt da natürlich mit hinein. Ich glaube nur, dass dieser Arbeitskontext bestimmte Voraussetzungen schafft, die im privaten Kontext keine Rolle spielen. Du hast halt nicht die Wahl. Also wenn du arbeitest, du musst eine Aufgabe erfüllen, dann musst du diese Aufgabe erfüllen. Und davon hängt dein Lohn ab. Und du bist in diesem bestimmten Konstrukt eben auch abhängig davon, dass Dinge funktionieren. Das ist nochmal was anderes. Aber da nutzen die ähnliche Methoden auch, auch um damit umzugehen. Befragungsmethoden, Usability Testing, um ein gutes, funktionierendes soziotechnisches System zu entwickeln, werden ähnliche Methoden verwendet.

Lena: Also die Abgrenzung zum Thema Organisation ist, glaube ich, wirklich, kann man nur betonen. Also weil sowohl bei diesem sozio-technischen System, darunter versteht man ja eine organisierte Menge von Menschen und Technologien, und auch was diesen Bereich Informalität betrifft. Also auch informelle Strukturen verwendet man am Ende für Organisationen. Also andere Institutionen wie zum Beispiel eine Ehe oder eine Freundschaftsgruppe oder so, da wird man weniger so etwas finden wie informelle Strukturen. Es gibt in der Freundschaft keine formellen Strukturen, die durch Informalität unterlaufen werden müssen. Das ist wirklich auch etwas, was sich häufig auf den Arbeitskontext bezieht. Welche Methoden kann ich anwenden, um ein besseres sozio-technisches System zu entwickeln? Also es gibt für das Requirements Engineering, gibt es so ein paar Tools, die man nutzen kann, um vermeintlich einen Überblick darüber zu kriegen oder da in die informellen Strukturen reingucken zu können. Das ist aber, ich habe das selber noch nie ausprobiert. Es gibt so Dinge wie zum Beispiel ein Soziogramm, das man halt irgendwie erstellen kann. Da beschreibt man die Eigenschaften von Personen in so einer Projektsituation. Oder ein Kräftediagramm, da werden so Antriebskräfte, Hemmkräfte beschrieben, zum Beispiel für so ein Projekt mit der internen App. Oder es gibt sowas wie eine Soziomatrix, da werden Teammitglieder sozusagen eingeschätzt. Das sind alles so Tools, die man nutzen, wo es man mal ausprobieren kann, wenn man Anforderungsanalyse betreibt, um zu gucken, was kriegt man da für einen Blick drauf. Dann was, worüber Katharina und ich neulich noch gesprochen hatten, dieses tatsächlich auch dieses Beobachten von Leuten, wie die eigentlich arbeiten. Also nicht nur befragen, sondern eigentlich auch beobachten. Hinfahren, hingehen und gucken, was machen die eigentlich, wie arbeiten die, wer redet mit wem. Weil das gibt auch mal einen anderen Blick, als wenn du ein Interview machst. Aber natürlich Befragung und sowas sind auch wichtige Tools, um das irgendwie rauszukriegen. Also viele Dinge, glaube ich, die tatsächlich im User Experience Bereich sowieso passieren. Es ist sehr zentriert auf die Leute, die diese Applikation später wirklich benutzen sollen. Und ein weiteres Thema, was man noch bedenken muss oder was ich super interessant finde, ist, wenn man jetzt eine Technik baut für diese Menschen, dann muss man ja irgendwo entscheiden an irgendeinem Punkt, wie flexibel ist denn dieses, diese App. Also gebe ich einen ganz strikten Weg vor bei der Implementierung, wie das zu benutzen ist? Und gibt es nur diesen einen Workflow, um etwas zu tun? Oder lasse ich zu, dass denn die Nutzerin diese App irgendwie untersteuern kann oder kurze Wege machen kann? Und das finde ich eine ganz spannende Frage. Wie strikt baut man so eine Software, die Vorgänge formalisiert? Ich weiß nicht, da gibt es wahrscheinlich keine Wahrheit dazu. Aber das ist halt so eine Entscheidung, die man an bestimmten Stellen treffen muss. Und vielleicht geht es sogar, wenn man sagt, okay, wir bauen das flexibler. Die Nutzerinnen haben mehrere Möglichkeiten, die Dinge so oder so zu lösen in der App. Vielleicht geht das sogar zu Lasten der User Experience, weil es eben komplizierter wird, sie zu nutzen. Es gibt nicht nur den einen Weg, Dinge zu tun, sondern vielleicht mehrere Wege.

Anja: Ich habe da eine Anekdote aus meiner Arbeit. Ich habe in einem großen Unternehmen gearbeitet, das natürlich sehr gutes Geld verdient hat, welches sehr gut organisiert war. Aber dadurch, dass es eine große Organisation war, war es eben auch sehr organisiert. Es gab für jede Kleinigkeit eine Abteilung. Und so gab es auch eine Release-Management-Abteilung, die extra Releases geplant hat und diese nachvollzogen und sichtbar gemacht hat. Und dann hat aber die Organisation technisch mitbekommen, ja, wir wollen aber eigentlich Continuous Delivery, hat Tools eingeführt und die Entwicklungsteams haben mitgearbeitet und sie haben Continuous Delivery eingeführt und waren wirklich begeistert davon. Was man aber vergessen hat, war, dass diese Release-Management-Abteilung auf einmal keine Arbeit mehr hatte. Es gab keine geplanten Releases mehr. Was macht man da? Natürlich hätte man dann sagen können, ja, dann können die Leute aus der Release-Management-Abteilung ja gehen, aber du kündest nicht einfach gute Leute. Da hätte es auch einen Aufschrei gegeben. Da gab es also diese Release-Management-Abteilung, die immer noch Release-Management gemacht hat und anstatt Releases zu planen und zu organisieren, haben sie dann einfach getrackt, was es so gibt und haben es dann in ihrem Board gepflegt, sodass sie wenigstens noch die Aufgabe hatten, dass diese Releases nachvollziehbar wurden, obwohl man das hätte auch mit technischen Tools wieder abdecken können. Und das ist wirklich sehr schade, dass man nicht bemerkt, dass eine Änderung auf technischer Seite auch Auswirkungen auf die organisatorische Seite hat und man sich dessen bewusst sein muss, dass Organisationsstrukturen davon beeinflusst werden können oder sich sogar ändern müssten. Das fand ich sehr spannend. Habt ihr auch so etwas Ähnliches schon mal erlebt?

Lena: Ja, also das Beispiel ist interessant, was du erzählt hast. Ich habe vor allen Dingen diese Erfahrung gemacht, dass man in Projekte kommt und dann kommt man zu Unternehmen, die haben irgendwie Organigramme, Prozesse, die aufgesetzt sind und auch dokumentiert sind. Also diese ganzen formalen Strukturen, die kann man sich auch alle angucken und so. Das macht auch irgendwie alles Sinn. Und man merkt dann aber im Laufe der Zeit, dass eben diese Strukturen, die da aufgemalt wurden und die auch einmal entschieden und abgesegnet wurden, so ihre Grenzen haben und gar nicht funktionieren. Also wir hatten jetzt ganz aktuell in dem Projekt, wo ich gerade bin, das Beispiel, dass wir als INNOQ-Kolleginnen und Kollegen brauchten wir Lizenzen für ein Tool, was wir alle benutzen mussten. Und das war ganz wichtig, sich da an den vorgegebenen Prozess zu halten, wie man an diese Lizenzen kommt. Also das waren irgendwie zwei oder drei Schritte. Musste man da über den Support gehen und ein Ticket aufmachen und so weiter und so fort. Und das hat einfach nicht, es ist nichts passiert, viele, viele Wochen lang. Und dann am Ende war es so, dass die Person, die dieses Programm leitet, gesagt hat, ach, ich rufe jetzt da einfach mal kurz bei dem Kollegen an, der die Lizenzen vergibt, die Berechtigung. Und dann hat sie genau das gemacht und hat den gesamten Prozess unterlaufen, der eigentlich vorgegeben war. Und wir hatten innerhalb von Minuten, hatten wir diese richtigen Berechtigungen. Laut Dokumentation ist aber ein anderer Prozess vorgesehen. Nur kamen wir nicht zum Ziel mit diesem Prozess und waren auch gar nicht richtig, dadurch nicht richtig arbeitsfähig. Also es hat wirklich das Projekt dann auch darunter gelitten. Und das ist jetzt das Beispiel, was mir dazu einfällt, dass eben die formalen dokumentierten Prozesse gar nicht alles, die ganze Wahrheit abbilden.

Katharina: Genau. Und das aber oft auch vielleicht die Unternehmen selber das gar nicht merken. Also die haben ihre offiziellen Unterlagen, die sie rausgeben. Aber das wird dann oft erst, und das ist ja auch das Interessante als Beraterin, man kommt da rein und man hat eben diesen Blick und man sieht diese Dinge, weil man muss sie auch verstehen. Man spricht mit den Leuten und dann deckt man im Prinzip oft auch solche informellen Systeme erstmal auf. Die fallen einfach den Menschen nicht auf, die sich darin befinden.

Anja: Gut, was können wir jetzt als Fazit unseren HörerInnen mitgeben? Was kann man jetzt beachten, wenn man mit sozio-technischen Systemen zu tun hat? Und das haben wir alle.

Katharina: Also ich glaube grundsätzlich, wann immer man mit neuer Technologie zu tun hat, ich glaube, also ich behaupte einfach, die Technologie ist hier das Innovative. Menschen, das sehen wir auch an dem Bergbau-Thema, verhalten sich sehr ähnlich. Egal ob jetzt vor 100 Jahren oder heute, es spielen auch dieselben Dinge eine wichtige Rolle. Auch die soziale Interaktion miteinander, das ist einfach unsere menschliche Natur. Was sich ändert, ist die Technologie. Die Technologie erfährt Innovation, die Technologie ist neu. Das heißt, wir müssen zum einen uns bewusst sein und auch akzeptieren, dass Menschen so sind, wie sie sind. Und sie sind auch gut so, wie sie sind, weil irgendwo kommen diese Innovationen her. Es kommen auch diese neuen Ideen irgendwo her. Die kommen nicht von der Technologie an sich, sondern im Zusammenspiel zwischen Technologie und Menschen. Und ich glaube, zum einen das Bewusstsein, welche Konsequenzen hat der Umgang mit Technik im Kontext eines sozialen Systems, welche Konsequenzen hat es. Und sich sehr bewusst darüber zu sein, wenn ich mit der Technologie soziale Systeme stummschalte, Abteilungen entferne, Kommunikation stummschalte zum Beispiel, dass dann auch was verloren geht an Ideen und an Möglichkeiten, die die Menschen in Zusammenarbeit mit Technologie entwickeln könnten. Der Versuch, alles mit Technologie zu lösen, glaube ich, damit killt sich die Technologie am Ende selbst. Also ich glaube, das klingt jetzt irgendwie ein bisschen pathetisch, aber ich glaube, in vielen kleinen Situationen, in vielen Unternehmen passiert es schon. Und Technologie sollte die Menschen unterstützen, damit gemeinsam eine Aufgabe erfüllt werden kann, gelöst werden kann. Und nicht, dass Technologie Menschen ausschält. Ich glaube, das wäre ein großer Fehler, auch wenn man diesen Versuch einfach machen würde.

Lena: Genau, ich glaube, also eigentlich hast du sowas ähnliches auch gerade schon gesagt, aber es ist wichtig, bei der Planung schon zu berücksichtigen, dass wenn man ein neues System einführt, dass das die Arbeitsumgebung verändern wird und dass es Auswirkungen haben wird auf das ganze System. Ich glaube, wenn man das einfach auch im Hinterkopf so ein bisschen behält, dann läuft man, was das angeht, schon in die richtige Richtung.

Katharina: Und ich bin auch irgendwie fasziniert von dieser Idee, Systeme flexibler zu entwickeln. Also auch in der Architektur selber erweiterbar zu entwickeln, flexibler zu entwickeln. Also das Risiko einzugehen, nicht alles unter Kontrolle. Es fasziniert mich irgendwie total, was dann passiert. Also was in dem Umgang mit dieser Technologie dann passiert, wenn nicht alles hermetisch ist. Und wenn es nicht nur einen Weg gibt. Das finde ich total spannend. Ich glaube, man kann die Dinge auch einigermaßen absichern und sich ein bisschen trauen, ein paar offene Türen zu lassen und zu gucken, was Menschen damit anstellen oder was die Technologie in Zusammenarbeit mit Menschen damit anstellt. Wie auch immer, aber was kommt dann dabei raus? Da kann auch was Interessantes, Neues dabei rauskommen.

Anja: Ich glaube, den Begriff nennt man in der Softwareentwicklung evolutionäre Softwarearchitektur.

Katharina: Klingt logisch.

Anja: Dass sie sich weiterentwickeln kann, die Tore offen lässt dafür, dass sie sich weiterentwickeln kann.

Katharina: Ja, ist auch abstrakt und unvorhersehbar, aber ja.

Anja: Super, vielen Dank, dass ich mit euch darüber reden konnte, über sozio-technische Systeme.

Lena: Danke dir.

Anja: Dann freue ich mich auf das nächste Mal.

Katharina: Ja, danke schön.

Lena: Tschüss.