- Teil 1: Die Angemessenheit von Komplexität
- Teil 2: Der Foerster und die Softwarearchitektur
- Teil 3: Mythos Teamautonomie
- Teil 4: Autonomie und Entscheidungen
- Teil 5: Ich, Du und Conway’s Law
- Teil 6: Conway hat immer Recht
- Teil 7: Illegale Softwarearchitekturen
- Teil 8: Paradoxical Safety
- Teil 9: New Work: Taylorismus 2.0
- Teil 10: Es lebe die Bürokratie! (dieser Artikel)
Seit einiger Zeit erobert ein neuer Begriff die Welt der Softwareentwicklung: Soziotechnische Systeme sind das neue Buzzword, mit dem vieles zu erklären versucht wird.
Damit dieser Erklärungen funktionieren, muss aber klar sein, was ein soziotechnisches System ist und wie es sich von einem technischen oder einem sozialen System unterscheidet. Um es mit den Worten von Niklas Luhmann zu formulieren: Was ist bei einem soziotechnischen System der Unterschied, der einen Unterschied macht?
Die Idee der soziotechnischen Systeme ist schon sehr alt, Grundgedanken können bis zu Karl Marx zurückverfolgt werden, der verschiedene Aspekte in seinem Maschinenfragment beleuchtet hat. Ebenso haben Frederick W. Taylor und Henry Ford mit ihren Überlegungen dazu beigetragen.
Das soziotechnische System dekonstruiert
Der Begriff wurde aber erst in den 1950ern im Kontext des Bergbaus in Großbritannien geprägt. Frederick E. Emery und Eric L. Trist beschreiben den Kern eines soziotechnischen Systems als Arbeitssystem, bei dem ein Teil als technisches System und ein weiterer Teil als soziales System betrachtet werden kann:
- Das technische System kann eine Maschine sein oder heutzutage auch Software.
- Das soziale System beschreibt in diesem Fall die Kommunikation, die zwischen handelnden Personen in einem Arbeitskontext besteht.
Von einem soziotechnischen System lässt sich nur dann sprechen, wenn diese beiden Subsysteme untrennbar miteinander verbunden sind, also das eine nicht ohne das andere als System existieren kann (siehe dazu Artikel: „Ich, Du und Conway’s Law“). Im Folgenden soll als weitere Einschränkung gelten, dass soziotechnische Systeme nur in ihrer ursprünglichen Form, nämlich als Arbeitssysteme, betrachtet werden.
Das Modell eines soziotechnischen Systems lässt sich relativ einfach darstellen: Es gibt Mitglieder, das sind Personen, die innerhalb des soziotechnisches Systems tätig sind. Jedes Mitglied hat eine Rolle innerhalb der sozialen Struktur, mit der verschiedene Aufgaben verbunden sind. Damit diese Aufgaben erfüllt werden können, wird eine Technologie verwendet, die die Aufgabenerfüllung effizienter, einfacher oder sicherer machen kann (siehe Abbildung 1). Zwischen allen vier Elementen entstehen Wechselwirkungen, die sie aneinanderbinden: Wird eines der Elemente aus dem soziotechnischen System entfernt, hört das Arbeitssystem auf, zu funktionieren.
Zwar lassen sich grob die Mitglieder und ihre Rollen in das soziale Subsystem einordnen und die Aufgaben und Technologien in das technische Subsystem, allerdings ist diese Aufteilung als Modell zu verstehen.
Von der Bürokratie zur Soziotechnik
Um zu diskutieren, was soziotechnische Systeme mit Bürokratie zu tun haben, ist es notwendig, diese zunächst als eine strukturierte Möglichkeit zu betrachten, kognitive Prozesse verteilt zu organisieren.
Bürokratie erlaubt es Menschen, in einer Organisationsform zusammenzuarbeiten, die Denkleistungen auf mehrere Köpfe verteilt. Wie gut das funktioniert, war schon im alten Rom bekannt. Bürokratie kann heute – trotz aller Unzulänglichkeiten – als eines der Fundamente der Zivilisation gesehen werden. Dabei beschränkt sich Bürokratie nicht auf staatliches oder öffentliches Handeln, sondern findet auch in privaten Organisationen statt. Dort wird die Bürokratie nur als Management bezeichnet, die soziale Funktion ist aber identisch.
Die Technisierung macht auch vor der Bürokratie nicht halt und so wundert es nicht, dass die ersten Versuche der Maschinisierung von Bürokratie bereits Anfang des 18. Jahrhunderts mit der Entwicklung von Schreibmaschinen unternommen wurden [1]. Neben Schreibmaschinen können auch einfache Dinge wie Stempel, vorgedruckte Formulare oder ein Rohrpostsystem im Haus als Technologie betrachtet werden, die das Arbeitssystem Bürokratie in ein soziotechnisches System transformieren.
Die unvermeidbare Folge davon ist, dass sich Bürokratie bürokratischer anfühlt.
Die Erklärung dafür ist die Verschiebung von Kommunikation zwischen den Subsystemen. In der nicht-technisierten Bürokratie trat Kommunikation als ein Input auf, auf den die Bürokratie reagieren musste. Das konnte sie anhand sozialer Normen und Erwartungen (im Folgenden als „Social Contracts“ bezeichnet) tun und war in der Lage, durch die Kommunikation im sozialen System verschiedene Aspekte spontan einzubeziehen – oder auch auszublenden.
Diese Social Contracts konnten sich mit dem sozialen Subsystem weiterentwickeln und schnell an externe Faktoren anpassen. Damit war die Bürokratie in der Lage, einen akzeptablen Output zu erzeugen [2].
Die Technisierung der Bürokratie verschiebt nun Social Contracts aus dem sozialen Subsystem in das technische Subsystem und schreibt sie in Form von Technologie fest. Das erhöht einerseits die Effizienz der Bürokratie bei der Behandlung sämtlicher Standardinputs, erschwert aber das Handeln in Social Contracts, die die Technologie nicht adaptiert hat, weil sie vielleicht erst im Laufe der Zeit entstehen.
Mehr Digitalisierung, mehr Bürokratie
Fast alle Menschen machen irgendwann in ihrem Leben die Erfahrung, dass eine andere Person ihnen sagt: „Tut mir leid, das kann ich nicht tun. Der Computer lässt das nicht zu.“ Dieser Satz ist die unmittelbare Konsequenz der Transformation von Bürokratie in soziotechnische Systeme.
Die Leistungsfähigkeit des sozialen Subsystems liegt darin, dass es auf unerwartete Ereignisse mit der Anpassung von Social Contracts reagieren kann. Damit kann es selbst dann einen erklärbaren Output erzeugen, wenn es keine vorab definierten Regeln gibt, nach denen das geschehen soll. Diese Fähigkeit wird durch die ins technische Subsystem übertragenen und nicht-veränderlichen Social Contracts begrenzt: Es geht nur, was vorgedacht wurde innerhalb der Regeln, die die Technologie erlaubt.
Das war bei Stempeln und Schreibmaschinen ein überschaubares Problem, hier wurden Social Contracts kaum ins technische Subsystem verschoben. Mit der Einführung von Software hat sich das allerdings deutlich geändert. Software-Engineering ist praktisch das methodische Verschieben von Social Contracts vom sozialen ins technische Subsystem (siehe Abbildung 2). Die Software als Ergebnis unterstützt die kognitiven Vorgänge wie Bewertungen und Entscheidungen anhand der implementierten Regeln. Diese sind üblicherweise aus den Social Contracts abgeleitete Prozesse, die formalisiert wurden. Damit ist die Software im technischen Subsystem nicht in der Lage, auf nicht vorhergesehene Aspekte oder externe Faktoren zu reagieren. Die Software kennt diese einfach nicht.
Natürlich kann Technologie weiterentwickelt und an neue Bedürfnisse angepasst werden, das gilt insbesondere für Software. Im konkreten Fall nützt diese Zukunftsperspektive aber wenig und führt entweder dazu, dass die Bürokratie keinen Output erzeugen kann oder an der Technologie vorbei arbeitet (siehe Artikel: Illegale Softwarearchitekturen). Beides ist weder nützlich noch erstrebenswert.
Praktisch bedeutet die Einführung von Software als Komponente des technischen Subsystems immer eine Reduktion der Handlungsoptionen im sozialen Subsystem. Das ist einer der Gründe, warum sich entweder Leute gegen die Einführung von Software sperren – das soziale Subsystem strebt nach seiner Erhaltung – oder warum die Realisierung solche Software sehr aufwendig ist: Die Nutzerinnen und Nutzer sind daran gewöhnt, dass es einen Entscheidungsspielraum gibt, der nicht formal zu beschreiben ist. Eine solche formale Beschreibung ist aber der Kern jeder Software.
Die Geister, die ich rief …
Eine Betrachtung soziotechnischer Systeme im Kontext von Softwareentwicklung zeigt also: Die Einführung von Technologie macht manches effizienter und manches schwieriger. Als Mittel zur Beseitigung negativer Effekte von Bürokratie wird Software nur wenig beitragen können, denn mit jeder Verschiebung eines Social Contracts vom sozialen in das technische Subsystem gehen Handlungsoptionen im sozialen Subsystem verloren. Vor diesem Hintergrund wird klar: Die Anerkennung, dass Software-Engineering ein Treiber erlebter Bürokratie ist, ist unumgänglich, wenn es um Digitalisierung von Abläufen geht, die auf Social Contracts beruhen.