Spiele mit Expert*innensystemen

Ametowobla, Dzifa

doi:10.1007/978-3-658-37256-9_3

Dzifa Ametowobla²

Zusammenfassung

Der erste Teil dieses Kapitels dient der Entwicklung und Operationalisierung eines Forschungsrahmens für die Untersuchung des Umgangs mit Software als Mittel und Resultat von Kontrollversuchen. Ziel ist es, bei solchen Untersuchungen einerseits sichtbar zu machen, wie über Modelle Kontrolle über Unsicherheiten, die beim Umgang mit Software entstehen, zwischen sozialen Prozessen verschoben wird, andererseits aber auch die Grenzen dieser Kontrollverschiebung im Blick zu behalten. Beides, Kontrollversuche und ihre Grenzen, können als Ausdruck der Performativität von Software betrachtet werden. Im zweiten Teil des Kapitels werden Forschungsdesign und Methodik der empirischen Untersuchung vorgestellt, mit der ich in Kapitel 4 vorführe, wie soziologische Forschung aussehen kann, in der die Performativität von Software fokussiert wird.

You have full access to this open access chapter, Download chapter PDF

Der erste Teil dieses Kapitels dient der Entwicklung und Operationalisierung eines Forschungsrahmens für die Untersuchung des Umgangs mit Software als Mittel und Resultat von Kontrollversuchen. Ziel ist es, bei solchen Untersuchungen einerseits sichtbar zu machen, wie über Modelle Kontrolle über Unsicherheiten, die beim Umgang mit Software entstehen, zwischen sozialen Prozessen verschoben wird, andererseits aber auch die Grenzen dieser Kontrollverschiebung im Blick zu behalten. Beides, Kontrollversuche und ihre Grenzen, können als Ausdruck der Performativität von Software betrachtet werden: Software besteht aus Modellen, in denen Aspekte des Umgangs mit Software beschrieben werden, um diesen Umgang in Hinblick auf bestimmte Zwecke zu beeinflussen. Die Beschreibungen in den Modellen wirken sich auf das aus, was Menschen mit Software tun, ohne es vollständig zu determinieren. Mit der hier vorgeschlagenen Perspektive rückt die Performativität von Software, also das Verhältnis zwischen diesen Beschreibungen und den Auswirkungen, die sie auf den Umgang mit Software haben, ins Zentrum der Betrachtung. Diese Fokussierung auf die Performativität von Software soll Forscher*innen helfen herauszufinden, welche der Prozesse, die im Lebenszyklus der Software rekursiv miteinander verschränkt sind, relevante Auswirkungen auf die von ihnen untersuchten Formen des Umgangs mit Software haben. Im zweiten Teil des Kapitels werden Forschungsdesign und Methodik der empirischen Untersuchung vorgestellt, mit der ich in Kapitel 4 vorführe, wie soziologische Forschung aussehen kann, in der die Performativität von Software fokussiert wird.

Um der Komplexität von Software in all ihren Facetten gerecht zu werden, verzichte ich dabei auf die grundsätzliche konzeptionelle Unterscheidung zwischen Entwicklungs- und Nutzungsprozessen, die traditionell bei der soziologischen Untersuchung von Software im Mittelpunkt steht. Wie im vorangegangenen Kapitel gezeigt wurde, nehmen Entwickler*innen und Nutzer*innen zwar häufig unterschiedliche Haltungen gegenüber Software ein. Ihre Kontrolle darüber, wie Software die Unsicherheit in sozialen Prozessen reduziert, in denen sie zur Anwendung kommt, unterscheidet sich aber nicht grundsätzlich, sondern nur graduell voneinander. Software wird in Entwicklungs- und Nutzungsprozessen gleichermaßen performativ: In beiden wird sie von Akteur*innen nur partiell verstanden, in beiden ist sie nur zum Teil ein Mittel, mit dem die Akteur*innen Kontrolle ausüben. Immer lagern Akteur*innen, die Software einsetzen, Entscheidungen über Unsicherheiten an diejenigen aus, die die Software geschaffen haben, und geben damit einen Teil der Kontrolle über ihre eigenen Prozesse ab. Vor diesem Hintergrund reicht es nicht, den Umgang mit Software als ein Verhältnis zwischen Prozessen zu betrachten, deren Position im Lebenszyklus von vorneherein festlegt, ob in ihnen Kontrolle ausgeübt wird (weil sie Entwicklungsprozesse sind) oder ob in ihnen mit Kontrollversuchen umgegangen werden muss (weil sie Nutzungsprozesse sind). Stattdessen charakterisiere ich den Umgang mit Software als eine in all diesen Prozessen angesiedelte Kombination aus Versuchen, Kontrolle auszuüben, Kontrolle abzugeben und sich Kontrollversuchen zu entziehen, indem Modelle erzeugt, angenommen oder abgelehnt werden, in denen die Unsicherheiten des Sozialen reduziert sind.

3.1 Theoretische Grundannahmen

Um die Charakterisierung des Umgangs mit Software theoretisch zu fundieren und eine Operationalisierung zu ermöglichen, die es erlaubt, Kontrollversuche, Unsicherheitsreduktionen und die Performativität von Software in sozialen Prozessen sichtbar zu machen, greife ich auf zwei etablierte Konzepte der soziologischen Theorie zurück. Modelle verstehe ich als Expert*innensysteme, die in sozialen Systemen im Rahmen von Modellierungsprozessen produziert werden. Den Umgang mit Software betrachte ich als mikropolitische Spiele im Sinne der strategischen Organisationsanalyse. Beide Konzepte werden im Folgenden kurz eingeführt und ihre Verbindung zum Forschungsrahmen dargestellt.

3.1.1 Modelle als Expert*innensysteme

Expert*innensysteme sind „Systeme technischer Leistungsfähigkeit oder professioneller Sachkenntnis, die weite Bereiche der materiellen und gesellschaftlichen Umfelder, in denen wir heute leben, prägen“ (Giddens 2010 [1995], S. 40 f.). Das technische Wissen, aus dem sie bestehen, wird von Expert*innen in sozialen Systemen ausgehandelt. Als soziales System bezeichne ich dabei mit Giddens ein relativ dauerhaftes Geflecht sozialer Beziehungen und Interaktionen, das in sozialen Prozessen (re)produziert wird, in denen sich die beteiligten Akteur*innen an den gleichen sozialen Regeln und Ressourcen orientieren. Dieses „sich orientieren“ meint nicht, dass Regeln und Ressourcen das Handeln der Akteur*innen determinieren, sondern nur, dass sie darauf in irgendeiner Form Bezug nehmen. Akteur*innen interpretieren Regeln in Abhängigkeit von den konkreten Bedingungen der Situation, in der sie handeln. Sie können sich entscheiden, die Regeln zu beugen, zu brechen oder bewusst zu ignorieren und Ressourcen einzusetzen oder darauf zu verzichten. In allen Fällen sind Regeln und Ressourcen der Systeme aber in irgendeiner Form bedeutsam für die sozialen Prozesse, in denen Akteur*innen im System miteinander interagieren. „Soziale Regeln“ sind dabei weit mehr als nur die formalen oder auch nur ausformulierten Regeln, „Ressourcen“ sind mehr als nur die materiellen Mittel, die Akteur*innen zur Verfügung stehen: „The ‚rules‘ involved here are social conventions, and knowledge of the contexts of their application. By ‚resources‘ I mean ‚capabilities of making things happen‘, of bringing about particular states of affairs“ (Giddens 1995, S. 341). Soziale Systeme sind diesem Verständnis nach nicht abgeschlossen, sondern können überlappen oder sich überlagern (Giddens 2008 [1984]). Das kann sowohl über gemeinsame soziale Beziehungen geschehen (z. B. wenn Beschäftigte eines Unternehmens auch Mitglieder der gleichen Gewerkschaft sind), als auch dadurch, dass innerhalb der Systeme die gleichen Regeln und Ressourcen als Orientierung für das Handeln der Akteur*innen dienen (z. B. wenn die akademische Informatik ein Teil des Wissenschaftssystems ist). Der hier nur grob spezifizierte Systembegriff wird gewählt, weil er die gegenseitige Abhängigkeit von sozialer Ordnung und sozialem Handeln fasst und es möglich macht, verschiedene Formen sozialer Ordnung einerseits zu unterscheiden (über die Systeme), andererseits aber auch Überlagerungen und Wechselwirkungen zu betrachten. Darüber hinaus erlaubt es der hier gewählte Systembegriff, die strukturierende Wirkung sozialer Ordnung ernst zu nehmen und gleichzeitig die Handlungsfreiheit der Akteure zu berücksichtigen. Dies ist Voraussetzung für einen Forschungsrahmen, der über Software vermittelte Kontrolle ebenso sichtbar machen soll wie deren Grenzen. Betrachtet man Modelle als Expert*innensysteme, können sie als Formen technischer Leistungsfähigkeit und gesellschaftlicher Sachkenntnis untersucht werden, die zu bestimmten Zeitpunkten und an bestimmten Orten produziert und dann zeitlich und räumlich getrennt verwendet werden. Gleichzeitig können auch ihre Produktionsbedingungen betrachtet werden, also die sozialen Prozesse, in denen Akteur*innen nicht nur Modelle herstellen, sondern auch die Regeln und Ressourcen sozialer Systeme (re)produzieren und sie dadurch aufrechterhalten und / oder verändern.

Expert*innensysteme können gesellschaftlich deswegen so bedeutsam werden, weil Akteur*innen mit ihnen Ereigniszusammenhänge herstellen können, deren Prinzipien sie nicht verstehen. Es reicht, die Expert*innensysteme in eigene Handlungsabläufe einzubauen. Akteur*innen können so Wissen nutzen, das innerhalb der sozialen Systeme generiert wird, in denen die Expert*innensysteme entstehen, ohne dieses Wissen selbst zu besitzen. Wie in Abschnitt 2.2. dargestellt, können Techniken immer als Expert*innensysteme betrachtet werden. Die Bereitschaft der Nutzer*innen, auf Wissen über die Funktionsweise der Techniken zu verzichten, die sie in ihre Handlungsabläufe einbauen, ist eine Grundvoraussetzung dafür, dass sich komplexe Techniken überhaupt entwickeln können:

„Denn nun muss jeweils nur eine begrenzte Anzahl von Experten die Regeln kennen und befolgen können, die einen bestimmten Ereigniszusammenhang sicherstellen. Dadurch lassen sich regelbasierte Ereigniszusammenhänge in einer Vielzahl und Komplexität realisieren, die vollkommen ausgeschlossen wäre, läge die Hauptlast der Regelbefolgung weiterhin auf Seiten des durchschnittlich kompetenten Gesellschaftsmitgliedes.“ (Schulz-Schaeffer 1999, S. 417)

Komplexe Techniken basieren damit auf dem Vertrauen, das Nutzer*innen in das „richtige[…] Funktionieren“ (Giddens 2010 [1995]) der Expert*innensysteme und der sozialen Systeme, die diese hervorbringen, setzen. Vertrauen bedeutet in diesem Zusammenhang nicht, dass Nutzer*innen davon überzeugt sind, dass die Technik ein erwünschtes Ergebnis garantiert. Es bedeutet nur, dass die Technik das Risiko, das erwünschte Ergebnis nicht zu erreichen, auf ein Maß reduziert, das Nutzer*innen im Kontext des Technikeinsatzes zu akzeptieren bereit sind (a.a.O., S. 50 f.). Das kann auch bedeuten, dass Nutzer*innen ernsthafte Zweifel am richtigen Funktionieren der Expert*innensysteme haben, aber das Risiko, das mit dem Nicht-Nutzen der Technik einhergeht, als höher einschätzen als jenes, das sie eingehen, wenn sie ihr Vertrauen unfreiwillig (und möglicherweise zeitlich begrenzt) dem Expert*innensystem schenken.

In den sozialen Systemen, in denen die Expert*innensysteme produziert werden, findet die für soziale Prozesse charakteristische „lebendige […] Sinnbildung“ (Blumenberg nach Schulz-Schaeffer 1990, S. 419) für die Ereigniszusammenhänge statt, die Expert*innensysteme herstellen. Diese Sinnbildung wird damit den Prozessen entzogen, in denen Expert*innensysteme genutzt werden. Expert*innensysteme sind also Mittel, mit denen Akteur*innen versuchen, die Unsicherheit der Nutzungsprozesse zu reduzieren. Aus dieser Perspektive lässt sich nicht nur Software (als komplexe Technik) als Expert*innensystem betrachten, sondern auch die Modelle, auf denen der Umgang mit Software basiert. Diese Betrachtungsweise hat für die Untersuchung der Rolle von Software im Sozialen mehrere Vorteile, denn sie ermöglicht es, abhängig vom Forschungsinteresse

(1)
alle sozialen Prozesse, deren Produkte dazu genutzt werden, den Umgang mit Software zu kontrollieren, als systemisch eingebettete Modellierungsprozesse zu untersuchen und
(2)
dabei auch die Abhängigkeiten aufzunehmen, die durch den Einsatz von Modellen in diesen Prozessen entstehen.

3.1.1.1 Einfluss sozialer Bedingungen der Modellierung auf den Umgang mit Software

Der Verlauf eines Modellierungsprozesses und damit auch sein Ergebnis, das Modell, ist in gewissem Ausmaß immer kontingent, da er von der Praxis der Akteur*innen abhängt, also davon, was sie in konkreten Situationen miteinander tun. Betrachtet man Modelle als Expert*innensysteme, so wird sichtbar, dass sie als Mechanismen der „Entbettung“ (Giddens 2010 [1995], S. 33–43) funktionieren. Mit Entbettung ist gemeint, dass soziale Beziehungen aus den raum-zeitlich eng begrenzten Zusammenhängen gelöst werden, in denen direkte Interaktion stattfindet, und sich über diese Interaktionszusammenhänge hinaus ausdehnen. Entbettungsmechanismen stellen soziale Beziehungen her, die die Grenzen verschiedener sozialer Kontexte überschreiten. Die Bedeutung sozialer Kontexte für soziale Beziehungen wird durch Entbettung nicht geringer, sondern sie verändert sich: Entbettungsmechanismen verbinden soziale Kontexte miteinander, die nicht durch direkte Interaktionen verbunden sind. Eben dies geschieht über die aufeinander aufbauenden Modelle, aus denen Software besteht: In jedem Modellierungsprozess werden bereits vorhandene Modelle eingesetzt und damit Verbindungen zu den sozialen Systemen hergestellt, in denen diese entstanden sind. Diese Verbindungen entstehen einerseits, weil die Geschehnisse in den früheren Modellierungsprozessen die Interpretationen und Handlungsmöglichkeiten der Akteur*innen in den späteren Modellierungsprozessen beeinflussen.

Andererseits hängt die Praxis der Modellierung nicht nur von den Regeln und Ressourcen ab, die im Modellierungsprozess selbst (re)produziert werden, sondern wird auch durch die Regeln und Ressourcen geprägt, an denen sich die Akteur*innen in anderen Prozessen innerhalb des gleichen Sozialsystems orientieren. Modelle in der Software verbinden soziale Systeme miteinander, nicht nur einzelne Prozesse. Nicht nur die Softwareentwicklung im engeren Sinn, sondern alle sozialen Bedingungen, unter denen Software entwickelt worden ist, sind daher potentiell relevant für Forscher*innen, die untersuchen wollen, welche Auswirkungen die Software auf die Praxis der Akteur*innen hat.

3.1.1.2 Die Bedeutung von Vertrauen für den Umgang mit Software

Wird Software als Ergebnis einer komplexen Verkettung von Modellierungsprozessen innerhalb von sozialen Systemen betrachtet, lassen sich Modelle und ihre Bedeutung für die Reduktion von Unsicherheit auf zwei Arten gleichzeitig betrachten. Erstens lässt sich untersuchen, wie Unsicherheit reduziert wird, um Modelle zu erzeugen. Nennen wir die Modelle, die als Resultat der Unsicherheitsreduktion untersucht werden, für den Augenblick Modelle vom Typ B. Zweitens lässt sich untersuchen, wie bestehende Modelle genutzt werden, um festzulegen, welche Aspekte der Unsicherheit in den Modellen vom Typ B überhaupt behandelt werden sollen. Nennen wir diese bestehenden Modelle, die als Mittel zur Reduktion von Unsicherheit eingesetzt werden, Modelle vom Typ A. Aus der hier vorgeschlagenen Perspektive rückt das Vertrauen der Modellierer*innen in Modelle in den Mittelpunkt. Die Akteur*innen müssen in den Modellierungsprozessen, in denen sie Modelle vom Typ B schaffen, darauf vertrauen, dass die Modelle vom Typ A, die sie benutzen, um ihre eigene Modellierungsaufgabe zu erfüllen, im Sinne dieser Aufgabe „richtig“ sind. Für die bei der Untersuchung von Software relevanten Modellierungsprozesse drückt sich dieses Vertrauen dadurch aus, wie die Akteur*innen mit folgenden Fragen umgehen:

(1)
Inwieweit sind die Angaben der Hersteller*innen über die Leistungen des Modells vom Typ A zutreffend?

Zum Beispiel: Erfüllt die verwendete Komponente tatsächlich die Anforderungen des angegebenen Sicherheitsstandards zur Verschlüsselung von Kommunikationsdaten, oder wurden die Anforderungen des Standards nur nachlässig umgesetzt?

(2)
Inwieweit stimmt das soziale Phänomen, das Modell A abbildet, mit dem überein, das die Nutzer*innen im Modell B modellieren wollen?

Zum Beispiel: Ist die Vergabe von Wohnheimplätzen an Studierende eine Variante der Vergabe von Hotelzimmern an Gäste? Brauchen also Mitarbeiter*innen der Wohnheimverwaltung des Studierendenwerks ähnliche Funktionen, arbeiten sie nach vergleichbaren Logiken wie die Mitarbeiter*innen von Hotels, wenn sie diese Aufgabe erledigen?

(3)
Inwieweit ermöglicht es die Art und Weise, wie die Unsicherheit der sozialen Phänomene in den Modellen A reduziert worden ist, die Unsicherheiten des sozialen Phänomens, das im Modell B modelliert wird, so zu kontrollieren, dass das Modell B den Zwecken genügt, die im Rahmen des Modellierungsprozesses verfolgt werden?

Zum Beispiel: Enthält der Entwurf alle Funktionen, die bei der Implementierung programmiert werden müssen, damit spätere Nutzer*innen der fertigen Software ihre Arbeitsprozesse erfolgreich durchführen können?

Wenn das Konzept der Expert*innensysteme genutzt wird, um die Modelle zu beschreiben, aus denen Software aufgebaut ist, so zeigt sich, dass der Einsatz von Modellen in anderen Modellierungsprozessen als Ausdruck des Vertrauens betrachtet werden kann. Die Modelle vom Typ A, die als Grundlage für Modelle vom Typ B genutzt werden, werden von Softwareentwickler*innen in der hier dargestellten Hinsicht als „richtig“ wahrgenommen. Insbesondere lässt sich über die eben aufgeführten drei Fragen sichtbar machen, welche Unsicherheiten durch den Einsatz von Modellen des Typs A der Kontrolle innerhalb des Modellierungsprozesses für Modelle des Typs B entzogen werden. Durch den Einsatz von Modellen vom Typ A werden alle Entscheidungen über die Unsicherheiten, die in ihnen reduziert sind, an die sozialen Systeme ausgelagert, in denen diese Modelle hergestellt worden sind. Durch diese Auslagerung kommen die Unsicherheiten im Modellierungsprozess für die Modelle des Typs B nicht mehr zur Sprache, oder nur noch, indem das Vertrauen in die Modelle vom Typ A in Frage gestellt wird. Solange Akteur*innen, die Modelle vom Typ B schaffen, in die Richtigkeit der Modelle vom Typ A vertrauen, geben sie Kontrolle an die Akteur*innen ab, die die Modelle vom Typ A geschaffen haben.

Die Ausführungen in Kapitel 2 zeigen, dass allein aufgrund theoretischer Überlegungen kein einzelner Aspekt von Software identifiziert werden kann, an dem sich ihre Rolle im Sozialen allgemein untersuchen ließe. Kein einzelner Aspekt von Software ist an sich bedeutsam für das Soziale, und keiner ist für alles, was mit Software im Sozialen getan werden kann, gleichermaßen relevant. Jeder Standard, jede Projektdefinition, Spezifikation oder wiederverwendete Softwarekomponente, jedes Testkonzept oder organisationsspezifische Benutzer*innenhandbuch haben Anteil an den Unsicherheitsreduktionen, über die der Umgang mit Software vorstrukturiert wird. Jedes dieser Elemente kann als Modell eines sozialen Phänomens betrachtet werden. Gleichzeitig ist jedes dieser Elemente das Produkt eines Modellierungsprozesses, der innerhalb von sozialen Systemen abläuft. Als Ursprung von Expert*innensystemen können daher nicht nur Professionen wie zum Beispiel die Informatik betrachtet werden, sondern auch Standardisierungsgremien, Softwarehersteller*innen, Customizingprojekte oder Fachabteilungen, in denen Regeln für den Umgang mit neu erworbener Software ausgehandelt werden. Was als relevantes Modell und was als produzierendes soziales System untersucht werden soll, ist nicht durch den Forschungsrahmen vorgegeben, sondern lässt sich nur in Abhängigkeit von der konkreten Software und dem Forschungsinteresse bestimmen. Die Entscheidung für ein Modell oder mehrere zu untersuchende Modelle und die dazugehörigen sozialen Systeme ist damit eine Frage des Untersuchungsdesigns. Damit wird keine theoretische Aussage darüber getroffen, ob ein bestimmtes Element der Software prinzipiell entscheidender für die Kontrolle von Nutzungsprozessen wäre als ein anderes. Da soziale Systeme sich überlappen und überlagern, können mit der Betrachtung von Expert*innensystemen und den sozialen Systemen, aus denen sie stammen, auch Wechselwirkungen zwischen sozialen Prozessen in verschiedenen sozialen Systemen (z. B. Kunden- und Beratungsunternehmen beim Customizing) erfasst werden. Solche Wechselwirkungen werden immer dann zum Gegenstand der Untersuchung, wenn der Modellierungsprozess durch sie beeinflusst wird.

Das Konzept der Expert*innensysteme erlaubt es, die Einbettung von Prozessen der Modellbildung in relevante Kontexte aufzunehmen und die Wechselwirkungen zwischen Modellen und Modellierungsprozessen sowie zwischen Modellierungsprozessen und anderen sozialen Prozessen sichtbar zu machen. Dieser Perspektive liegen jedoch zwei Annahmen zugrunde, von denen nicht bei allen Untersuchungen des Umgangs mit Software ausgegangen werden kann. Die erste Annahme ist, dass die (selbst produzierten und im Prozess herangezogenen) Modelle von den Akteur*innen als Technik genutzt werden: als Mittel, um vorher definierte Zwecke zu erreichen, die mit den über die Technik (vermeintlich) hergestellten Ereigniszusammenhängen in Verbindung stehen. Die zweite Annahme ist, dass den im Prozess herangezogenen Modellen Vertrauen entgegengebracht wird (im oben beschriebenen Sinn). Das Konzept der Expert*innensysteme ist also dann nützlich, wenn wir verstehen wollen, wo und unter welchen Bedingungen die Modelle entstanden sind, die in sozialen Prozessen genutzt werden. Jede Nutzung bringt mit sich, dass die Art und Weise, wie Unsicherheiten in den Modellen reduziert werden, von den Nutzer*innen an- oder zumindest hingenommen wird. Der Fokus auf Technik und das in sie gesetzte Vertrauen erlaubt es zu untersuchen, wohin Kontrolle ausgelagert wird und welche Interpretations- und Handlungsspielräume durch den Umgang mit Software verschlossen werden.

Selbst in den Prozessen der Softwareentwicklung geht es allerdings nicht nur darum, die zukünftige Nutzung zu gestalten. Auch Softwareentwickler*innen sollen und wollen mit ihrer Arbeit Gewinn erzielen, persönliche Ziele erreichen, ungeliebte Kolleg*innen vorführen und viele andere Dinge erreichen. Kurz: Bei jedem Umgang mit Software werden gleichzeitig auch noch andere Zwecke als die offiziellen verhandelt. Software wird in allen Kontexten, in denen mit ihr umgegangen wird, eben nicht nur als Technik genutzt, sondern zum Beispiel auch als Produkt, als Ausweis des eigenen Erfolgs, als Verhandlungsmasse in organisationsinternen Konflikten etc. Auch in diesen Fällen handelt es sich um einen Umgang mit Software. Wenn Software nicht als Technik genutzt wird, stellt sich die Frage, inwieweit die Akteur*innen, die mit Software umgehen, auf die Richtigkeit der herangezogenen Modelle vertrauen. Auch lässt sich fragen, welche Folgen es für einen Prozess hat, in dem mit Software umgegangen wird, wenn dieses Vertrauen bei einigen, aber nicht bei allen Beteiligten vorhanden ist. Nur weil Software und die Modelle, auf denen sie basiert, verfügbar sind, werden sie nicht zwangsläufig von allen Akteur*innen genutzt. Noch weniger setzen sie diese unbedingt für die offiziellen Zwecke ein, also für die Zwecke, die bei der Entwicklung oder bei der Einführung der Software in das aktuelle soziale System ausgehandelt worden sind. Weder der Einsatz als Technik noch das Vertrauen in die Modelle sind selbstverständlich. Akteur*innen können Software und die Modelle, auf denen sie basiert, ebenso ignorieren, strategisch darauf Bezug nehmen oder das Vertrauen in sie grundsätzlich in Frage stellen, um Ziele zu erreichen, die mit den offiziellen nichts zu tun haben. Die Unterscheidung zwischen den Zielen eines Systems und den Zielen der Akteur*innen, die in irgendeiner Form am System mitwirken, ist grundlegend für die meisten organisationssoziologischen Perspektiven (z. B. Simon 1997 [1945], S. 14 f.). In techniksoziologischen Konzepten wie dem, in dem Technik als Expert*innensystem betrachtet wird, steht diese Unterscheidung jedoch nicht im Vordergrund. Daher muss das Konzept der Expert*innensysteme, durch welches Zweckgerichtetheit und Vertrauen im Umgang mit Modellen betont wird, für die Untersuchung konkreter sozialer Prozesse durch Konzepte ergänzt werden, die es erlauben, differierende Zwecke sowie Produktion und Destruktion von Vertrauen in Modelle sichtbar zu machen.

Für meinen Forschungsrahmen wähle ich zu diesem Zweck die strategische Organisationsanalyse, da sie einen differenzierteren Blick auf das Verhältnis von Unsicherheit und Kontrolle ermöglicht: Akteur*innen können versuchen, Kontrolle über soziale Prozesse zu gewinnen, indem sie über Modelle Unsicherheiten in diesen Prozessen reduzieren. Sie können aber ebenso die von den Modellen angebotenen Formen der Unsicherheitsreduktion in Frage stellen, um sich der Kontrolle zu entziehen, die andere mit Hilfe von Modellen auszuüben versuchen. Mit der strategischen Organisationsanalyse lässt sich sichtbar machen, dass Kontrolle beim Umgang mit Software in Geflechten sozialer Beziehungen hin- und hergeschoben wird und jederzeit in Frage gestellt werden kann. Ich betrachte dabei die Modelle als Mittel, mit dem Akteur*innen versuchen, Unsicherheiten in einem sozialen Prozess zu kontrollieren, indem sie sie an entfernte soziale Systeme auslagern. Bevor ich diesen Gedanken weiter ausführe, werde ich zuerst die Grundannahmen darlegen, auf denen die strategische Organisationsanalyse beruht.

3.1.2 Strategische Organisationsanalyse

In der strategischen Organisationsanalyse wird nach den Bedingungen, Ausprägungen und Folgen kollektiven Handelns gefragt. Grundannahme ist, dass Menschen „relativ autonome Akteure“ (Crozier und Friedberg 1979, S. 7) mit individuellen, aber kontextabhängigen Zielen und Interessen sind, die in der Verfolgung dieser Ziele und Interessen stets aus ihrer eigenen Perspektive rational handeln. Rationalität meint dabei, dass das Handeln von Akteur*innen als Ergebnis einer Entscheidung interpretiert werden kann, die aus der Perspektive der Akteur*innen rational erscheint. Das bedeutet, dass Akteur*innen aus den Verhaltensmöglichkeiten, die sie zu haben glauben, die auswählen, die es unter den von ihnen wahrgenommenen Bedingungen am ehesten zu erlauben scheinen, ein von ihnen positiv bewertetes Ziel zu erreichen. Verhaltensoptionen, Bedingungen und Ziele sind jeweils abhängig von den konkreten Gelegenheiten, die sich Akteur*innen bieten (Friedberg 1995). Akteur*innen sind in der strategischen Organisationsanalyse also keine freien und rationalen Nutzenmaximierer*innen, die objektive Informationen über ihre Handlungsoptionen gegeneinander abwägen und die auswählen, deren Konsequenzen sie optimal finden (vgl. March und Simon 1994 [1958], S. 158). Sie sind auch mehr als Ausführende, die geskriptete Praktiken exekutieren, die ihnen als Folge institutionalisierter Strukturen die Hand leiten und jede Entscheidung überflüssig machen (vgl. Meyer 2008, S. 794 f.). Stattdessen entscheiden sie im Rahmen ihrer Möglichkeiten autonom über ihre Handlungen und berücksichtigen dabei sowohl ihre eigenen Interessen als auch die strukturellen Bedingungen, insofern sie Handlungen, Interessen und Bedingungen als relevant für die Entscheidung betrachten (Friedberg 2019).

Die „innere“ Rationalität der Akteur*innen kann dazu führen, dass ihre Handlungen für Beobachtende irrational erscheinen. Beobachter*innen kennen weder die Ziele der Akteur*innen noch wissen sie mit Bestimmtheit, welche Handlungsmöglichkeiten diese in einer konkreten Situation wahrnehmen. Aus der Grundannahme über die Autonomie der Akteur*innen, auf der die strategische Organisationsanalyse basiert, entsteht gerade in solchen Fällen der Auftrag für die Forschenden, die innere Rationalität zu rekonstruieren. Es gilt herauszufinden, unter welchen strukturellen Bedingungen die Akteur*innen das beobachtete Handeln zum Erreichen welcher Ziele aus welchen als solche wahrgenommenen Handlungsmöglichkeiten gewählt haben (Friedberg 1995).

In der strategischen Organisationsanalyse werden soziale Prozesse als Ergebnis des Handelns relativ autonomer Akteur*innen in konkreten Handlungssystemen untersucht. Handlungssysteme werden als Geflechte von Spielen zwischen Akteur*innen verstanden, die durch ihr eigenes Handeln wiederum die Handlungsmöglichkeiten der anderen Mitglieder des Systems beeinflussen. Diese Spiele basieren auf Machtbeziehungen zwischen den Akteur*innen, die zwar hochgradig systemisch eingebettet, im Kern aber dyadisch^{Footnote 1} angelegt sind (Crozier und Friedberg 1979, S. 39 f.). Aus den Grundregeln der Interaktion in diesen Dyaden entstehen in jedem System konkrete Handlungsregeln. Diese werden einerseits vom Handeln der Akteur*innen im System hervorgebracht und beschränken dieses Handeln andererseits. Bevor ich mich den Bedingungen in Handlungssystemen zuwende, werden im Folgenden zunächst die Grundregeln der dyadischen Interaktion ausgeführt.

3.1.2.1 Grundregeln der Interaktion in Dyaden: Tausch, Macht und Ungewissheit

Die relativ autonomen Akteur*innen, von denen in der strategischen Organisationsanalyse ausgegangen wird, gehen Beziehungen miteinander ein, weil sie bestimmte Ziele nur durch kollektives Handeln, also in der Zusammenarbeit mit anderen, erreichen können. Für das Erreichen ihrer Ziele im kollektiven Handeln sind sie auf ein bestimmtes Verhalten ihres Gegenübers angewiesen. In jeder Beziehung geht es also um den Tausch von Verhaltensweisen und es besteht immer eine gegenseitige Abhängigkeit zwischen den Akteur*innen. Da sich auf beiden Seiten der Beziehung autonome Akteur*innen befinden, enthält jede Beziehung mindestens ein Element der Ungewissheit: Jede Akteur*in kann das Verhalten zeigen, das sich das Gegenüber wünscht, oder dieses Verhalten unterlassen (und eventuell stattdessen etwas Anderes tun). Diese Ungewissheit des Gegenübers in Bezug auf das Verhalten der Akteur*in erlaubt es der Akteur*in, einen Tausch einzugehen: Solange das Gegenüber weiß, dass die Akteur*in nicht tun muss, was es sich von ihr wünscht, hat die Akteur*in die Möglichkeit, dem Gegenüber dafür Zugeständnisse (also von der Akteur*in erwünschtes Verhalten) abzuverlangen (Friedberg 2019).

In der strategischen Organisationsanalyse wird daher Macht als Grundkonstante des Sozialen betrachtet. Macht wird als die Möglichkeit definiert, das Gegenüber in einer Beziehung zu erwünschtem Verhalten zu bewegen (Crozier und Friedberg 1979). Da zwei Akteur*innen nur dann eine Beziehung miteinander eingehen, wenn beide etwas voneinander brauchen, das ihnen das jeweilige Gegenüber auch verwehren kann, hat in einer Beziehung jede Seite Macht über die andere. Ein Beispiel: In einem Unternehmen besitzen Untergebene gegenüber Vorgesetzten damit ebenso Macht wie umgekehrt, im Umgang mit Expert*innensystemen gilt das gleiche für die Beziehung zwischen Expert*innen und Lai*innen. Hat jemand keine Möglichkeit, das Verhalten zu verwehren, welches das Gegenüber sich wünscht, wird diese Person in der strategischen Organisationsanalyse nicht mehr als eine Akteur*in betrachtet: „[W]enn B seine Bereitschaft zu tun, was A von ihm verlangt, nicht mehr verweigern kann, dann ist auch keine Machtbeziehung mehr zwischen beiden möglich, denn dann existiert B gegenüber A nicht mehr als autonomer Akteur und wird lediglich ein Ding“ (Crozier und Friedberg 1979, S. 40).

Macht ist somit zwar ein Grundelement sozialer Beziehungen, sie ist in der Regel jedoch ungleich verteilt: Die Macht einer Akteur*in über das Gegenüber ist umso größer, je mehr dieses davon überzeugt ist, für das Erreichen seiner Ziele auf das Verhalten der Akteur*in angewiesen zu sein und je größer die Ungewissheit darüber ist, ob die Akteur*in das erwünschte Verhalten zeigen wird. Umgekehrt ist die Macht einer Akteur*in umso geringer, desto mehr sie davon überzeugt ist, dass sie sich im Einklang mit den Wünschen des Gegenübers verhalten muss, um ihre eigenen Ziele zu erreichen (a.a.O., S. 40 f.). Programmierer*innen haben damit zum Beispiel potentiell weniger Macht gegenüber einer Teamleitung, die aus der Arbeitsebene in die Leitungsposition aufgestiegen ist, die Arbeitsabläufe im Team kennt und den Code beurteilen kann, als gegenüber einer mit reiner Managementausbildung, die auf die Aussagen der Programmierer*innen angewiesen ist, um sich ein Urteil über deren Arbeit bilden zu können.

Die Machtverteilung innerhalb einer Beziehung ist abhängig von den für das Gegenüber relevanten Handlungsmöglichkeiten, die Akteur*innen diesem jeweils zum Tausch gegen die Verhaltensweisen anbieten können, die sie brauchen, um ihre eigenen Ziele zu erreichen. Innerhalb einer Beziehung sind Handlungsoptionen somit Ressourcen. Die Handlungsmöglichkeiten aller Akteur*innen innerhalb einer Beziehung sind nicht nur durch deren Kompetenzen bestimmt, sondern beeinflusst von deren Zielen, den Vorstellungen darüber, wie sie diese Ziele erreichen können, und von der Gesamtheit ihrer Handlungsmöglichkeiten in allen anderen Beziehungen, in denen sie gleichzeitig stehen (und der Macht, die sie jeweils in diesen Beziehungen haben). Ressourcen innerhalb der Beziehung sind nur die Handlungsmöglichkeiten, die für das Gegenüber einen Wert haben. Dieser Wert hängt von den Handlungsmöglichkeiten des Gegenübers und damit auch von dessen Position in seinem eigenen Beziehungsgeflecht ab. Jeder Tausch und also das strategische Handeln der Akteur*innen insgesamt lassen sich daher nicht über die dyadische Beziehung verstehen, sondern nur, indem die konkreten Handlungssysteme betrachtet werden, in die sie eingebettet ist (a.a.O., S. 44–46). Die Führungskraft mit Managementausbildung aus dem Beispiel ist möglicherweise nicht an der Codequalität interessiert, sondern nur daran, zum Abnahmetermin ein lauffähiges Programm zu haben. Um unwillige Teammitglieder zu Überstunden zu drängen, kann sie damit drohen, ihre guten Beziehungen zur Abteilungsleitung spielen zu lassen und dafür zu sorgen, dass die Teilnahmegebühren für die nächste Konferenz in deren Spezialbereich nicht übernommen werden.

3.1.2.2 Handlungsprobleme, Handlungssysteme und die Kontrolle relevanter Ungewissheiten

Konkrete Handlungssysteme bilden die Grundeinheit der Untersuchung in der strategischen Organisationsanalyse. In einem solchen Handlungssystem kommen Akteur*innen zusammen, um ein gemeinsames Handlungsproblem zu lösen, das sie nicht (oder nur schwer) allein lösen können. Die Akteur*innen verfolgen in der Zusammenarbeit eigene, unterschiedliche und sich verändernde Ziele (a.a.O., S. 12). Die Lösung des Handlungsproblems kann, muss aber nicht eines dieser Ziele sein. Ein gemeinsames Handlungsproblem kann zum Beispiel die Erstellung eines Softwareentwurfs sein oder die Produktion eines Jahresabschlusses für ein Unternehmen mit Hilfe einer Software. Akteur*innen verfolgen in solchen Handlungssystemen zum Beispiel das Ziel, ein erprobtes Architekturmodell einzusetzen, eine Lösung zu finden, die alle Beteiligten zufrieden stellt, oder bei Vorgesetzten für die nächste Beförderung Punkte zu sammeln. Neben solchen eher konventionellen Zielen können Akteur*innen, die sich an der Lösung des Handlungsproblems beteiligen, aber auch daran interessiert sein, ihr Gehalt mit möglichst wenig Anstrengung zu verdienen oder dem rivalisierenden Team aus der Nachbarabteilung eins auszuwischen. Um das Handlungssystem auf Dauer aufrechtzuerhalten genügt es, dass alle Mitglieder bei der Verfolgung ihrer Ziele in Kauf nehmen, dass das Handlungsproblem gelöst wird (Crozier und Friedberg 1979, S. 68). Jedes Mitglied des Handlungssystems trägt etwas Relevantes zur Lösung des Handlungsproblems bei, kann oder weiß also etwas, das notwendig ist, um das Problem zu lösen; jedes Mitglied des Handlungssystems ist damit (zumindest kurzfristig) nicht ersetzbar. Die Akteur*innen sind also zur Kooperation gezwungen, wenn sie ihre jeweiligen Ziele erreichen wollen (Friedberg 2019).

Wie im dyadischen Tausch gibt es auch in den Interaktionsprozessen^{Footnote 2} des Handlungssystems relevante Ungewissheiten, die der Macht im System zu Grunde liegen. Macht existiert nur, weil nicht sicher ist, was geschehen wird, und es Akteur*innen gibt, die die Wahl haben, ob und wie sie das zukünftige Geschehen beeinflussen. Ursprung dieser relevanten Ungewissheiten sind also einerseits die Unsicherheiten, die die Aufgabe, das Handlungsproblem zu lösen, mit sich bringt,^{Footnote 3} andererseits die relative Autonomie der Akteur*innen, deren Beiträge für die Lösung notwendig sind (Crozier und Friedberg 1979). Denn: Alle Mitglieder des Handlungssystems haben zwar ein Interesse an der Lösung des Handlungsproblems und damit auch daran, ihre Beiträge zu erbringen, aber weder steht fest, wie lange ihr Interesse anhalten wird, noch, welche Gegenleistung sie für ihre Kooperation von den anderen erwarten.

Da alle Mitglieder etwas Relevantes beizutragen haben, ist keines den anderen völlig unterworfen. Alle besitzen also Macht. Herausgehobene Machtpositionen im System besetzen jedoch nur diejenigen, die systemrelevante Ungewissheiten kontrollieren können:

„Denn gegenüber den relevanten Ungewißheiten eines Problems sind die Akteure nicht gleichgestellt. Diejenigen, die dank ihrer Situation, ihrer Ressourcen und ihrer Fähigkeiten (…) dazu fähig sind, diese Ungewißheiten zu kontrollieren, werden ihre Macht dazu benützen, um ihren Standpunkt anderen aufzuzwingen.“ (Crozier und Friedberg 1979, S. 13)

Wer die Interaktionsprozesse im Handlungssystem kontrollieren will, muss daher versuchen, Kontrolle über die relevanten Ungewissheiten des Systems zu erlangen. Dabei ist keineswegs festgelegt, worin diese relevanten Ungewissheiten bestehen: Sowohl die Definition des kollektiven Handlungsproblems als auch die Bestimmung von relevanten Ungewissheiten und Beiträgen sind Ergebnisse kollektiven Handelns (a.a.O., S. 10). Akteur*innen können nicht nur versuchen, bestehende Machtpositionen zu besetzen, sondern sich ebenso darum bemühen, die Bedingungen des Handlungssystems so zu verändern, dass ihre aktuelle Position zu einer Machtposition wird (a.a.O., S. 42 f.).

In Abschnitt 3.1.1 wurde dargestellt, dass Modelle als Ergebnis des Versuchs betrachtet werden können, Aspekte der Unsicherheit in sozialen Prozessen zu reduzieren und dadurch Kontrolle über diese Prozesse auszuüben. Über diese Betrachtungsweise lässt sich das Konzept der Expert*innensysteme mit der strategischen Organisationsanalyse verknüpfen: Theoretisch bieten Modelle eine Möglichkeit, Aspekte der Unsicherheit in sozialen Prozessen zu reduzieren und damit relevante Ungewissheiten aufzulösen, die in Bezug auf die Lösung des Handlungsproblems bestehen. Für die Akteur*innen im Handlungssystem werden die relevanten Ungewissheiten durch den Einsatz der Modelle kontrolliert. Sie können sie bei der Bearbeitung des Handlungsproblems (vorläufig) ignorieren – wenn sie das wollen. Die Kontrolle über diese Ungewissheiten ist mit dem Einsatz der Modelle auch keiner Teilnehmer*in der Prozesse mehr direkt zuzuordnen. Solange alle Akteur*innen auf die Richtigkeit der Modelle vertrauen, werden diese Ungewissheiten ganz einfach ausgeblendet. Das Vertrauen in die Modelle wird zur neuen relevanten Ungewissheit im Handlungssystem, hinter der die Unsicherheiten des Prozesses temporär verschwinden, weil sie ja in den Modellen reduziert sind. Die Entscheidungen, durch die diese Unsicherheiten reduziert worden sind, werden nicht mehr im betrachteten Handlungssystem getroffen. Durch die Modelle werden sie aus dem Prozess ausgelagert, für den sie relevant sind; sie sind bereits bei der Modellierung getroffen worden, und zwar in dem oder den sozialen Systemen, in denen die Modelle erstellt worden sind. Die Akteur*innen in diesen sozialen Systemen sind im Allgemeinen nicht (bzw. nicht unbedingt) an den Tauschvorgängen im Handlungssystem beteiligt, in dem die Modelle eingesetzt werden. Der Rückgriff auf Modelle kann so als Chance erscheinen, Machtpositionen innerhalb eines Handlungssystems zu beseitigen. Ein Beispiel: Wenn nur die Sekretär*in einer Abteilung in einem Großunternehmen weiß, welche Formulare wie ausgefüllt und in welcher Reihenfolge wohin geschickt werden müssen, damit das Unternehmen die Rechnung einer Lieferant*in rechtzeitig begleicht, so kontrolliert die Sekretär*in eine relevante Ungewissheit der Abteilung. Gehört die Abrechnung zu ihren vertraglich festgelegten Aufgaben, so wird sie diese in aller Regel auch durchführen, egal, welches Mitglied der Abteilung ihr eine Rechnung vorlegt. Sie wird allerdings einen gewissen Spielraum haben und entscheiden können, ob sie sich dabei beeilt und sorgfältig arbeitet oder andere Aufgaben vorzieht und durch schnelles Abarbeiten der Aufgabe einen Fehler riskiert, der den Prozess verzögern kann. Wenn sie will, kann sie diese Kontrolle nutzen, um Entgegenkommen von den Mitgliedern ihrer Abteilung einzufordern: Es lohnt sich, ein gutes Verhältnis zur Sekretär*in zu pflegen und es damit wahrscheinlicher zu machen, dass die eigenen Aufgaben schnell und gründlich erledigt werden. Wird nun eine Software eingeführt, in die jedes Abteilungsmitglied selbst die Rechnungsdaten eingegeben kann, um eine Zahlung auszulösen, wird das Wissen um die genauen Abrechnungsprozesse für die Abteilung irrelevant. Die Mitglieder der Abteilung wissen weiterhin nicht, was genau zwischen Erhalt der Rechnung und Zahlung geschieht – dies ist nun im Modell des Abrechnungsprozesses in der Software automatisiert. Diese Ungewissheit ist aber für die Interaktionen im System nicht mehr von Bedeutung. Wer schnelle Zahlungen will, muss sich nun nicht mehr mit der Sekretär*in gut stellen, sondern nur noch darauf vertrauen, dass die Software wie erwartet funktioniert.

Durch den Einsatz von Modellen verschwinden die relevanten Ungewissheiten und Machtpositionen im Handlungssystem nicht, sie werden nur verschoben: Erstens verändert sich durch eingesetzte Modelle das Handlungsproblem und möglicherweise auch die Zusammensetzung der Akteur*innen, die etwas Relevantes zu seiner Lösung beizutragen haben. Im Beispiel tragen nach der Einführung der Abrechnungssoftware nicht mehr die Rechnungsnehmer*in und die Sekretär*in, sondern die Rechnungsnehmer*in und die Entwickler*innen der Abrechnungssoftware dazu bei, dass die Rechnung bezahlt wird. Offensichtlich ist dies, wenn es um die Bedeutung bestimmter Kompetenzen für das Handlungssystem geht: Die Kompetenz, das Modell anzuwenden, wird erst durch seinen Einsatz bei der Lösung des Handlungsproblems relevant. Die Kompetenzen, die nötig sind, um die Ungewissheiten aufzulösen, die durch das Modell reduziert werden (wie im Beispiel das Wissen der Sekretär*in um die Abrechnungsprozesse), verlieren innerhalb des Handlungssystems an Relevanz.^{Footnote 4} Zweitens werden die Ungewissheiten, die Modelle beseitigen, nun durch Ungewissheiten darüber ersetzt, inwieweit im Prozess auf diese Modelle vertraut werden kann. Dass die Software im Beispiel wie vorgesehen funktioniert, ist nämlich keineswegs ausgemacht, auch wenn ihre Nutzer*innen dies meist erst bemerken, wenn es zu Problemen bei der Abrechnung kommt. Zu den in 3.1.1 aufgelisteten Fragen nach der Richtigkeit der Modelle gesellt sich auch noch die Frage nach ihrem dauerhaften Funktionieren. Die Einführung der Software im Beispiel bedeutet nämlich auch, dass für Abteilungsmitglieder, die Rechnungen bezahlt wissen wollen, in Zukunft neue Themen relevant werden: Wird die Software auch nach einem Austausch der Unternehmensserver noch stabil laufen? Werden die Regeln darüber, welche Daten einzugeben sind, auch nach einer Änderung der Steuergesetze Bestand haben? Durch den Einsatz von Modellen entstehen neue dauerhafte Abhängigkeiten zwischen den Handlungssystemen, in denen die Modelle produziert, verändert, am Laufen gehalten und genutzt werden. Diese Abhängigkeiten sind keineswegs nur einseitig, wie z. B. in der Diskussion der Evolution von Software in Kapitel 2 gezeigt wurde. Die Beziehungen zu und die Kommunikation mit diesen anderen Handlungssystemen können wiederum von einzelnen Akteur*innen kontrolliert werden, wodurch neue Machtpositionen entstehen können.^{Footnote 5}

Durch den Einsatz von Modellen, die Unsicherheit reduzieren sollen, wird Kontrolle über den sozialen Prozess also sowohl innerhalb des Handlungssystems, als auch über dessen Grenzen hinaus, verschoben. Gerade solche Systemgrenzen überschreitende Machtfragen können mit der strategischen Organisationsanalyse gut untersucht werden. Sie bietet ein Analyseraster an, in dem der Zusammenhang zwischen Handeln, konkreten Handlungssystemen und deren Einbettung in lokale Ordnungen im Mittelpunkt steht. Dieses Analyseraster kann als Spielanalyse bezeichnet werden. Grundlage der Spielanalyse ist das Konzept der Spiele, die Akteur*innen in konkreten Handlungssystemen miteinander spielen. Dieses Konzept wird im Folgenden erläutert.

3.1.2.3 Handlungsfelder, Spiele und Strategien

Die Handlungsmöglichkeiten aller Akteur*innen im System entstehen aus ihren Beziehungsgeflechten, auch aus denen, die über die Grenzen des Handlungssystems hinausreichen. Konkrete Handlungssysteme sind dadurch miteinander verknüpft. Sind diese Verknüpfungen so eng, dass das Handeln der Akteur*innen in einem System regelmäßige und bedeutsame Auswirkungen auf die Handlungsmöglichkeiten in den anderen Systemen hat, z. B. in einer Organisation, bilden die Systeme ein gemeinsames Handlungsfeld mit einer lokalen Ordnung (Friedberg 1995).

Die lokale Ordnung konkreter Handlungsfelder ist (vor allem im Fall formaler Organisationen oder anderer sozialer Systeme mit größerer zeitlicher Ausdehnung) relativ stabil. Das bedeutet, das Handlungsfeld besitzt zwar dauerhaft eine lokale Ordnung, wie diese genau aussieht, bleibt aber „stets kontingent und problematisch“ (a.a.O., S. 107). Das liegt daran, dass die lokale Ordnung sich aus den Handlungsmöglichkeiten der Akteur*innen zusammensetzt, die sich permanent durch die Tauschprozesse in den Beziehungsgeflechten der Systeme verändern. Was die Akteur*innen wann mit wem tauschen oder, einfacher gesagt, wie sie miteinander interagieren, wird von ihren Handlungsmöglichkeiten beeinflusst, aber nicht vollständig bestimmt (Crozier und Friedberg 1979). In der strategischen Organisationsanalyse werden die Interaktionsprozesse in konkreten Handlungssystemen als Spiele betrachtet, gespielt von Akteur*innen, die in der Zusammenarbeit eigene Ziele verfolgen, strukturiert durch Spielregeln, die festlegen, welche Handlungen für die Akteur*innen innerhalb der lokalen Ordnung welche Folgen nach sich ziehen. Solange die Akteur*innen sich am Spiel beteiligen, unterwerfen sie sich freiwillig den durch die Regeln des Spiels gebildeten Zwängen. Dies bedeutet nicht, dass über die Regeln Einigkeit bestünde, sondern nur, dass Akteur*innen ihnen nicht entkommen können, sofern sie daran interessiert sind, ihre Interessen in diesem Handlungssystem weiter zu verfolgen (Crozier und Friedberg 1979). Die Regulierung wirkt damit nur indirekt auf das Verhalten der Akteur*innen ein: Sie können ihr Verhalten jederzeit wählen, müssen dafür aber die Konsequenzen tragen, die die Spielregeln vorgeben. Das Spiel und seine Regeln ermöglichen es allen Mitgliedern des Handlungssystems, sich den Zwängen der Kooperation mit anderen zu unterwerfen und dabei gleichzeitig einen Teil ihrer Handlungsfreiheit zu bewahren.

Die Spielregeln beschreiben Gewinne und Verluste, die bestimmte Verhaltensweisen für die Akteur*innen nach sich ziehen. Damit beschreiben sie auch, welche Ziele jede Akteur*in unter den aktuell geltenden Bedingungen mit ihrem Verhalten erreichen kann und was dafür zu tun ist. Aus den Regeln lässt sich also eine Bandbreite an rationalen Strategien für jedes Mitglied im System ableiten. Diese Strategien hängen von der Position des Mitglieds im Handlungsfeld ab. Strategien sind das analytische Konstrukt, mit dem Forscher*innen aus dem beobachteten Verhalten der Akteur*innen die Spiele und Spielregeln rekonstruieren können (a.a.O., S. 73). Voraussetzung für eine solche Rekonstruktion ist die Annahme, dass Akteur*innen aus ihrer eigenen Perspektive rational handeln. Alle Strategien besitzen einen offensiven und einen defensiven Aspekt. Defensiv versuchen Akteur*innen, den ihnen verfügbaren Handlungsspielraum zu verteidigen. Offensiv versuchen sie, Gelegenheiten zu nutzen, um eigene Ziele zu erreichen. Zu den offensiven Strategien zählen dabei auch solche Verhaltensweisen, die dazu dienen, den Handlungsspielraum der Tauschpartner*innen zu reduzieren und so die Vorhersagbarkeit ihres Tuns zu steigern (Friedberg 2019).

Im Folgenden werden Spiele, in denen sich die Akteur*innen auf Strategien beschränken, in welchen sie die bestehenden Spielregeln als gegeben akzeptieren, als Routinespiele bezeichnet. Aber Akteur*innen „können umgekehrt auch versuchen, das Spiel so umzuformen, dass andere ihnen zur Verfügung stehende Ressourcen darin relevant und mobilisierbar werden“ (a.a.O., S. 70 f.). Spiele, die durch solche Umformungsbemühungen erzeugt werden, werden hier Innovationsspiele genannt. Das Handlungsproblem, das in Innovationsspielen gelöst werden soll, ist die Regelung von Routinespielen.^{Footnote 6}

Mit dem Konzept der Spiele kann jede Form des Umgangs mit Software und den mit ihr verbundenen Modellen als systemisch eingebetteter sozialer Prozess untersucht werden. In diesem Prozess ist Kontrolle Gegenstand permanenter Aushandlungen. Wird der Umgang mit Software als Teil von Spielen betrachtet, wird erstens die Auslagerung von Kontrolle durch Modelle erkennbar, die bereits bei der Vorstellung des Konzepts der Expert*innensysteme in 3.1.1 diskutiert wurde: Wenn Akteur*innen vorhandene Modelle in sozialen Prozessen einsetzen, um Aufgaben zu erledigen (d. h. Zwecke zu erreichen), die in ihrem sozialen System ausgehandelt worden sind, lagern sie Kontrolle über Ungewissheiten innerhalb ihres sozialen Systems an die sozialen Systeme aus, in denen die Modelle entstanden sind. Zu diesen Systemen bestehen dadurch Abhängigkeiten, solange die Modelle eingesetzt werden. Betrachten wir soziale Prozesse in sozialen Systemen als Spiele im Sinne der strategischen Organisationsanalyse, können wir den Mechanismus, durch den diese Abhängigkeiten entstehen, als Verkettung von Spielen bezeichnen: Die Spiele, in denen Modelle eingesetzt werden, die, in denen die Zwecke ihres Einsatzes ausgehandelt werden und die, in denen sie gestalten werden, bilden eigene Einheiten, da sie je eigenen Regeln folgen, hängen jedoch wie die Glieder in einer Kette zusammen. Sie sind so miteinander verbunden, so dass jede Veränderung in einem der Spiele oder in der Verbindung zwischen zwei Spielen sich auf die gesamte Kette und jedes einzelne andere Spiel auswirkt und an jeder Stelle eine Veränderung anstoßen kann. Kann ist hier der operative Begriff: Keine dieser Veränderungen ist zwangsläufig, denn keines der Spiele kann von einem anderen Spiel heraus gezielt gesteuert werden. Die Folgen, die ein Anstoß an einer Stelle der Kette auf die anderen Stellen hat, sind nicht vollständig vorhersehbar. Sie sind, wie immer im Sozialen, unsicher. Mit Hilfe der strategischen Organisationsanalyse lässt sich nicht nur feststellen, dass diese Unsicherheit besteht – dies leistet schon das Konzept der Expert*innensysteme. Es lässt sich auch zeigen, dass Akteur*innen diese Unsicherheit in ihren Spielen nutzen und dadurch soziale Systeme strukturieren. An Hand des Spielkonzepts kann sichtbar gemacht werden, dass die Auslagerung von Kontrolle aus dem Handlungssystem an eine bestimmte Struktur der Kontrolle innerhalb des Handlungssystems gebunden ist. Besteht diese nicht, kann der Einsatz der Modelle völlig andere Ausprägungen annehmen, als dies in den Modellen vorgesehen ist. Um erneut das Beispiel der Abrechnungssoftware zu bemühen: Wenn die Abteilungsleiter*in verhindern will, dass jede Mitarbeiter*in ihre eigenen Abrechnungen macht, kann sie es ablehnen, die Mitarbeiter*innen für eine Schulung freizustellen, und sie anweisen, die Rechnungen weiterhin bei der Sekretär*in abzugeben. Diese kann die neue Software einsetzen und so dafür sorgen, dass die Abteilung nach außen hin regelkonform, d. h. mit Hilfe der Software, abrechnet, dass gleichzeitig aber die alte Kontrollstruktur erhalten bleibt, in der alle Rechnungen über den Tisch der Sekretär*in gehen müssen, um bezahlt zu werden. Durch die Abhängigkeiten, die über die Verwendung von Modellen zwischen Handlungssystemen hergestellt werden, können unvorhergesehene Nutzungsformen in einem Handlungssystem dazu führen, dass der Umgang mit den Modellen auch in anderen Handlungssystemen beeinträchtigt wird.

Ein anschauliches Beispiel für so eine Folge der Verkettung von Spielen findet sich in Ortmann et al.s Studie zur Einführung eines Produktionsplanungs- und -steuerungssystems (PPS-Systems) in einem Industrieunternehmen (Ortmann et al. 1990, S. 139–144): Im Modell des Produktionsprozesses, das in der Software implementiert war, war vorgeschrieben, dass jeder Arbeitsschritt erst begonnen werden konnte, wenn der vorangegangene Arbeitsschritt erfolgreich abgeschlossen worden war. Zum Beispiel konnte mit der Produktion eines Bauteils erst begonnen werden, wenn im System vermerkt worden war, dass alle Vorprodukte fertig produziert waren. Die in dem Unternehmen übliche Praxis, mit der nächsten Stufe der Produktion anzufangen, sobald die ersten nötigen Vorprodukte fertig sind, war im Modell nicht vorgesehen. Bestand ein Bauteil also aus fünf Vorprodukten, von denen eines erst eingebaut werden musste, nachdem die anderen vier in einem zwei Wochen dauernden Prozess zusammengefügt worden waren, hätte dieser zweiwöchige Prozess nach der Logik des PPS-Systems nicht beginnen können, solange das fünfte Vorprodukt nicht bereit läge. Diese Logik war für die Mitarbeiter*innen in der Produktion nicht nachvollziehbar, denn sie wollten vor allem Zeiten des Stillstands der Maschinen verhindern. Obwohl das PPS-System eingesetzt wurde, entzogen sich die Mitarbeiter*innen im Detail den Vorgaben des Modells, indem sie im großen Stil „Zwangsfreigaben“ benutzten, also eine eigentlich für Ausnahmefälle gedachte Möglichkeit, den nächsten Prozessschritt freizugeben, obwohl noch nicht alle Bedingungen erfüllt sind. Durch den Einsatz der Zwangsfreigaben behoben die Mitglieder des Handlungssystems rund um die Produktion das Problem, das die Software erzeugte und das der Lösung ihres Handlungsproblems (kontinuierliche Produktion ohne Unterbrechungen) im Weg stand. Indem sie den Ausnahmefall zum Normalfall machen, verhinderten sie die Auslagerung von Kontrolle aus dem Produktionsprozess: Trotz der Nutzung der Software wurde weiterhin in der Produktion entschieden, wann der nächste Prozessschritt anstand, und nicht in dem Handlungssystem, in dem die Vorgaben zur Modellierung des Prozesses im PPS-System festgelegt wurden. Diese (fehlende) Bereitschaft der Produktionsarbeiter*innen, Kontrolle über ihren Prozess abzugeben, hatte einschneidende Auswirkungen auf die Fachabteilungen wie zum Beispiel den Einkauf. Die Mitarbeiter*innen dieser Abteilung hatten die Vorgabe, so einzukaufen, dass der Materialbedarf der Produktion zu jeder Zeit gedeckt wäre, aber möglichst wenige Lagerflächen benötigt würden. Mit Hilfe des PPS-Systems sollten sie sich einen Überblick über den regelmäßigen und akuten Materialbedarf der Produktion und die vorhandenen Lagerbestände verschaffen. Durch die Zwangsfreigaben bildete das PPS-System aber weder den Materialbedarf noch die Lagerbestände richtig ab; stattdessen schienen die Mitarbeiter*innen in der Produktion permanent mit Bauteilen zu arbeiten, die noch gar nicht im Unternehmen vorhanden bzw. noch nicht zu den nötigen Vorprodukten zusammengebaut worden waren. Statt ihre Aufgabe mit Hilfe der Software zu erfüllen, mussten die Mitarbeiter*innen der Einkaufsabteilung regelmäßig ins Lager und in die Produktionshallen gehen, um vor Ort zu prüfen, ob Nachschub bestellt werden musste. Da die Übersicht fehlte und ständig ein Mangel an Material angezeigt wurde, stiegen die Lagerbestände sogar an, statt wie geplant reduziert zu werden.

Mit Hilfe der strategischen Organisationsanalyse kann untersucht werden, wie Modelle in einzelnen Spielen innerhalb von Handlungssystemen eingesetzt werden, um bestehende Strukturen der Kontrolle aufrecht zu erhalten oder zu verschieben, und gleichzeitig berücksichtigt werden, welche Folgen das Geschehen in diesen Spielen für andere Spiele und Handlungssysteme hat. Dieser doppelte Blick – auf die einzelnen Spiele und auf ihre Verkettung – kann vor allem dann hilfreich sein, wenn Prozesse untersucht werden, in denen Software dauerhaft so eingesetzt wird, dass sie weder die vorgesehenen noch offensichtliche andere Zwecke erfüllt (wie im Beispiel des PPS-Systems, das in der Art und Weise, wie es in dem Industrieunternehmen eingesetzt wird, nur zusätzlichen Aufwand verursacht). Er kann auch dabei helfen zu verstehen, warum Software dauerhaft nicht eingesetzt wird, obwohl sie verfügbar wäre und keine – wiederum offensichtlichen – Gründe dagegensprechen (wie im Beispiel der Abrechnungssoftware für alle Mitarbeiter*innen, die dann nur von der Sekretär*in genutzt wird). Mit der strategischen Organisationsanalyse lassen sich aber nicht nur Spiele betrachten, in denen die Akteur*innen bereits Routinen für den Umgang mit Modellen etabliert haben. Sie bietet sich auch dafür an, die Spiele zu untersuchen, in denen es darum geht, die initialen Regeln für diesen Umgang mit Modellen festzulegen. Auch in diesen, den Innovationsspielen, spielen die Modelle selbst eine Rolle:^{Footnote 7} Diese Spiele drehen sich schließlich darum, inwieweit und auf welche Art und Weise die Unsicherheitsreduktionen, die die Modelle anbieten, angenommen werden sollen. Die Teilnehmer*innen spielen also um die Frage, ob das, was die Modelle vorgeben, als Teil der Spielregeln akzeptiert werden soll, wer dadurch Kontrolle über welche Ungewissheiten gewinnen kann und wer Kontrolle wohin abgeben muss. Akteur*innen können Vertrauen in die sozialen Systeme, aus denen das Modell stammt, in solchen Spielen als Ressource nutzen, um eine ihren Interessen eher entsprechende Kontrollstruktur in ihrem eigenen Handlungssystem durchzusetzen. Sie können dieses Vertrauen aber auch untergraben, um eben solche Veränderungen zu verhindern oder es vortäuschen, um weitergehende Interventionen aus dem Handlungsfeld abzuwehren (und dann in Routinespielen die von den Modellen angebotenen Unsicherheitsreduktionen zu ignorieren). Sie können es gegen Zugeständnisse eintauschen, die ihren Interessen innerhalb irgendeines der Handlungssysteme entgegenkommen, in denen sie aktiv sind. Sie können, kurz gesagt, nicht nur vertrauen oder nicht vertrauen, sondern vor allem mit dem Vertrauen spielen, das in Expert*innensysteme gesetzt werden muss, wenn Modelle genutzt werden.

Die strategische Organisationsanalyse ist eine flexible Perspektive. Sie erlaubt es, unterschiedliche Formen kollektiven Handelns mit Bezug auf die lokalen Bedingungen zu untersuchen, unter denen die Akteur*innen handeln. Flexibel ist die Perspektive insofern, als sie konzeptionell offenlässt, wo diese Handlungsbedingungen ihren Ursprung haben und wie sie vermittelt werden, also zum Beispiel über Regeln oder über Technik. Die lokale Ordnung eines Handlungssystems kann zum Beispiel aus dem Handlungsfeld einer formalen Organisation stammen, aus dem einer Profession, aus dem, das sich in einem Verband organisierter Patient*inneninteressen bildet, oder aus anderen Handlungsfeldern. Forscher*innen können mit der strategischen Organisationsanalyse untersuchen, welche Bedeutung die lokale Ordnung aus der formalen Organisation für die Spiele in der Organisation hat, müssen dabei die Bedeutung anderer Handlungsfelder aber nicht ausblenden. In solchen Untersuchungen können gleichzeitig Einflüsse aus verschiedenen lokalen Ordnungen berücksichtigt werden, egal ob diese innerhalb von formalen Organisationen bestehen, in interorganisatorischen Feldern, innerhalb von Beratungs- oder Entwicklungsprojekten oder in ganz anderen geordneten Kollektiven, zum Beispiel in den durch wenige formale Regeln und vor allem durch Normen der Reziprozität geprägten Communities von Open Source Software. Der zentrale Stellenwert, den das konkrete Handlungsproblem in der Theorie für die Herausbildung eines Handlungssystems einnimmt, erlaubt es dabei, Akteur*innen zu identifizieren, die auf den untersuchten sozialen Prozess Einfluss haben: all diejenigen, die für die Lösung des Handlungsproblems notwendig sind. Wenn Forscher*innen das Konzept der Spiele nutzen, um den Umgang mit Software zu untersuchen, können sie außerdem all die Bedingungen des Handelns berücksichtigen, die Akteur*innen tatsächlich in ihren Handlungen beeinflussen, auch wenn sie ihren Ursprung in völlig anderen Handlungssystemen haben. So können formale Organisationsregeln (für den Umgang mit Software und für alles andere) ebenso betrachtet werden wie die informellen Regeln, nach denen in der Praxis gehandelt wird. Aber nicht nur diese: Für die vorliegende Forschungsfrage ist zentral, dass auch die „technischen“ Regeln berücksichtigt werden können, also die Vorgaben für die Auswahl und Interpretation von Unsicherheiten im Prozess des Umgangs mit Software, die in den Modellen, auf denen Software basiert, gemacht werden. Mit der strategischen Organisationsanalyse können all diese Bedingungen als Teil der Spiele aufgenommen werden, wenn Akteur*innen sich darauf in ihrem Handeln beziehen.

3.2 Vorgehen bei der Untersuchung des Umgangs mit Software

In dieser Arbeit entwickle ich ein Konzept für die soziologische Untersuchung sozio-technischer Phänomene, in denen Software eine zentrale Rolle spielt. Dass das Soziale komplex ist und voller Unsicherheit steckt, setze ich dabei als Grundannahme voraus. Dass Software komplex ist, habe ich in Kapitel 2 ausgeführt. Dabei habe ich nachgezeichnet, wie Software durch die Komplexität und die Unsicherheiten des Sozialen, die ihre Entwicklung und Weiterentwicklung prägen, eine gewisse Eigenständigkeit entwickelt. Ich habe argumentiert, dass Software daher bei der Untersuchung sozio-technischer Phänomene als eigener Einflussfaktor neben dem Handeln der Akteur*innen und den sozialen Bedingungen berücksichtigt werden muss. Was in der ersten Hälfte dieser Arbeit konzeptionell hergeleitet worden ist, soll auf den folgenden Seiten operationalisiert werden. In der Soziologie finden sich bereits eine Vielzahl von Ansätzen, mit denen das Handeln von Akteur*innen unter sozialen Bedingungen untersucht werden kann. Zu beantworten ist im Folgenden die Frage, wie genau die Rolle der Software in so einer Untersuchung berücksichtigt werden kann.

In Kapitel 2 habe ich dargestellt, welche soziale Komplexität mit der technischen Komplexität von Software einhergeht: Software ist das Produkt verschiedener, in soziale Systeme eingebetteter, oft konfliktreicher und voneinander abhängiger Modellierungsprozesse. Sie besteht aus Modellen sozialer Phänomene, in denen bestimmte Aspekte der Unsicherheit, die diese Phänomene auszeichnet, ausgeblendet werden, um den Umgang mit Software in Bezug auf einen bestimmten Zweck zu kontrollieren. Zwecke, Aspekte und Formen der Unsicherheitsreduktion werden in jedem Modellierungsprozess ausgehandelt. Bestehende Modelle beeinflussen diese Aushandlungen, ohne sie zu determinieren. Auf die gleiche Weise beeinflusst Software die sozialen Prozesse, in denen Regeln zu ihrer Nutzung entwickelt werden (die auch als Modelle betrachtet werden können, die jedoch nicht Teil der Software werden) und schließlich auch die „eigentlichen“ Nutzungsprozesse. Die Art und Weise, wie Software genutzt wird, beeinflusst ihre Weiterentwicklung, wodurch auch die reine Nutzung in den Zyklus der Modellierungsprozesse eingebunden wird. Im Ergebnis zeigt sich Software aus soziologischer Perspektive als ein Artefakt mit rekursiver Struktur. Durch diese Struktur werden verschiedene Kombinationen von Modellen in jedem Prozess performativ, in dem in irgendeiner Form mit Software umgegangen wird. Ich habe vorgeschlagen, dass Forschende herausfinden können, auf welche Art und mit welchen Folgen für das Soziale Modelle performativ werden, indem sie bei der Untersuchung von sozialen Prozessen darauf achten, welche Kontrollversuche in den Unsicherheitsreduktionen der Modelle stecken und wie die Akteur*innen in den Prozessen mit diesen Kontrollversuchen umgehen. Im Folgenden werde ich ausführen, wie die in 3.1 vorgestellten Theorieansätze genutzt werden können, um konkrete Forschungsfragen zu bearbeiten. Dabei werde ich auch auf die Grenzen der vorgeschlagenen Vorgehensweise eingehen.

3.2.1 Identifikation relevanter Modellelemente

In Kapitel 2 ist ausgeführt, dass jede Software eine unüberschaubare Zahl an potentiell performativen Modellen enthält, so dass weder alle Unsicherheitsreduktionen noch alle Wechselwirkungen allgemein rekonstruiert werden können. Soziolog*innen können diese Komplexität im Rahmen von soziologischer Forschung beherrschen, indem sie sich auf die in der Einleitung formulierte Grundannahme besinnen, dass Software im Sozialen nur durch den Umgang der Akteur*innen mit ihr bedeutsam werden kann. Für die soziologische Analyse ist an der Software damit nur das bedeutsam, was im untersuchten Anwendungskontext von Akteur*innen aufgegriffen wird. Statt die vielfach verschränkten Modelle aus den Bauteilen, die in der Software kombiniert sind, und ihre wechselseitigen Abhängigkeiten allgemein zu rekonstruieren, können nur die Modelle und deren Beziehungen zueinander untersucht werden, die beim Umgang mit Software^{Footnote 8} in Bezug auf die Forschungsfrage relevant werden. Was sich untersuchen lässt, hängt also vom konkreten Forschungsgegenstand und der konkreten Forschungsfrage ab. Steht beides fest, können die Modelle und ihre Performativität aus den erhobenen Daten rekonstruiert werden.

Dazu werden im ersten Schritt die zu untersuchenden sozialen Prozesse festgelegt und das Handlungsproblem bestimmt, bei dessen Lösung die zu untersuchende Software zum Einsatz kommt. Wenn Akteur*innen in diesen Prozessen Elemente der Software nutzen, nehmen sie die angebotenen Möglichkeiten zur Unsicherheitsreduktion an und lagern gleichzeitig Kontrolle aus (in der Regel ohne dies zu reflektieren). Die Modelle, die im Prozess performativ werden, müssen also um diese Elemente herum aufgespannt werden. Widerstände im Prozess, die von den Akteur*innen direkt artikuliert werden oder sich in dauernden Konflikten rund um die Softwarenutzung zeigen, geben Hinweise darauf, welche der Unsicherheitsreduktionen umstritten sind, aber nicht umgangen werden können. Die Verbindung von angenommenen und abgelehnten Elementen gibt Hinweise darauf, auf welcher Ebene der Software die relevanten Modelle zu suchen sind. Diese Modelle müssen identifiziert werden, wenn der soziale Prozess im Zentrum der Forschungsfrage steht, aber zu Beginn der Untersuchung unklar ist, welche Modelle die Performativität verursachen, welche die Forscher*in interessiert. Die strategische Organisationsanalyse sensibilisiert in diesem Schritt für das Geflecht der sozialen Prozesse und Handlungsprobleme, die für den Umgang mit Software direkt bedeutsam sind. Nicht nur der zentrale Nutzungsprozess, sondern auch all die verketteten Spiele, die sich um ihn entfalten, werden in die Analyse aufgenommen.

Falls in der Forschungsfrage umgekehrt die Modelle festgelegt sind und nach ihren Auswirkungen auf den Umgang mit Software gesucht wird, ergeben sich die vorgesehenen Anwendungskontexte bereits aus dem Modell, da dieses – in wie abstrakter Form auch immer – zur Kontrolle einer bestimmten Menge von sozialen Prozessen geschaffen ist. Auch in diesem Fall ist die Suche nach den im Prozess genutzten Elementen (des Modells) und den Widerständen im Prozess der Ausgangspunkt der Untersuchung. Anhand dieser Elemente können Forscher*innen identifizieren, welche Unsicherheitsreduktionen und Angebote zur Kontrollverschiebung angenommen und welche abgelehnt werden.

3.2.2 Rekonstruktion von Modellen über soziale Systeme der Konstruktion

Bei der Untersuchung des Umgangs mit Software wird sichtbar, welche Aspekte der Unsicherheitsreduktion so miteinander verbunden sind, dass sie im sozialen Prozess nur gemeinsam angenommen oder abgelehnt werden können, wenn die Software ihren Zweck erfüllen soll. Widerstände im Prozess weisen darauf hin, dass es Widersprüche zwischen den Unsicherheitsreduktionen mehrerer Modelle gibt, die beim Umgang mit Software aneinandergebunden sind. So eine Verbindung kann entweder darin bestehen, dass mehrere Modelle gemeinsam in die Software eingebettet sind, oder darin, dass die sozialen Regeln, durch die der Umgang mit Software kontrolliert werden soll, nicht mit den technischen Regeln der Softwaremodelle vereinbar sind. Beide können gemäß den Ausführungen in 3.1.1 als Modelle betrachtet werden, die in sozialen Systemen konstruiert worden sind, an denen die Akteur*innen, die die Modelle einsetzen, in der Regel nicht beteiligt sind.

Verfolgt man so die Formen der Unsicherheitsreduktion, die sich im Prozess beobachten lassen, zu den sozialen Systemen zurück, denen sie entstammen, können die Modelle in ihrer Gesamtheit rekonstruiert werden. Dazu wird auf die Erkenntnis zurückgegriffen, dass die Modelle zusammenhängende Formen der Unsicherheitsreduktion enthalten. Welche Aspekte der Unsicherheit in den Modellen wie reduziert werden, wurde innerhalb der sozialen Systeme ausgehandelt, in denen die Modelle entstanden sind. Die Unsicherheitsreduktionen spiegeln wider, welche Zwecke durch den Umgang mit den Modellen erfüllt werden sollen. Mit Hilfe von Informationen über die Modellierungsprozesse in den sozialen Systemen der Konstruktion lassen sich diese Zwecke und die damit zusammenhängenden Kontrollversuche rekonstruieren. Diese erlauben es dann, aus den beobachteten Formen der Unsicherheitsreduktion auf die für die Fragestellung relevanten performativen Modelle zu schließen.

Die (im Rahmen einer konkreten Untersuchung konstruierten) performativen Modelle dienen dazu, bei der abschließenden Analyse sowohl soziale als auch technische Bedingungen des Umgangs mit Software in systematischer Weise berücksichtigen zu können. Die Suche nach den performativen Modellen wirkt als Filter, mit dessen Hilfe die für konkrete Forschungsinteressen bedeutsamen Ausschnitte der Software identifiziert, nachverfolgt und gedeutet werden können. Wenn die sozialen Systeme, in denen sie produziert worden sind, identifiziert sind, lässt sich nachvollziehen, wohin Kontrolle über welche Aspekte der sozialen Prozesse ausgelagert wird, in denen Akteur*innen mit der Software umgehen. Da soziale Systeme mitsamt ihren Regeln und Ressourcen über längere Zeiträume stabil sind, versetzt das hier geschilderte Vorgehen Forscher*innen in die Lage, Zusammenhänge zwischen verschiedenen Modellierungsprozessen und dem Umgang mit Software nachzuvollziehen, ohne alle Prozesse direkt begleiten zu müssen. Dies ist bei den meisten Fragestellungen von Vorteil, in denen es um den Umgang mit Software geht, die bereits vor Beginn der Untersuchung existiert. Bei solchen Fragestellungen besteht keine Chance, alle Aushandlungen, die für die relevanten Modelle bedeutsam sind, direkt zu beobachten.

3.2.3 Untersuchung der Performativität durch die Analyse von Spielen

Bei der Identifikation performativer Modelle wird die strategische Organisationsanalyse genutzt, um das Handlungsfeld festzulegen, in dem der Umgang mit Software untersucht werden soll. Der Umgang mit Software kann im Anschluss an die Rekonstruktion der Modelle wiederum als Teil des Handlungsfelds analysiert werden. Dazu werden die für das Handlungsproblem zentralen Akteur*innen, Positionen und relevanten Ungewissheitszonen identifiziert und der Umgang mit Software als Ergebnis der im Handlungsfeld stattfindenden Spiele interpretiert. Durch die Untersuchung der im Handlungsfeld miteinander verketteten Spiele kann sichtbar gemacht werden, inwiefern welche Modelle Teil der Spielregeln sind. Es kann herausgearbeitet werden, von wem die Modelle unter welchen Bedingungen als Ressourcen eingesetzt werden. Schließlich kann gezeigt werden, inwieweit sich der Umgang mit Software auf die von den Modellen angebotenen Unsicherheitsreduktionen, auf die aus der Annahme resultierende Verlagerung von Kontrolle an ein anderes soziales System oder auf von den Modellen völlig unabhängige strategische Erwägungen in Bezug auf das Handlungsfeld zurückführen lässt.

3.2.4 Reichweite und Beschränkungen der Vorgehensweise

Durch die vorgestellte Vorgehensweise können Soziolog*innen bei der Untersuchung des Umgangs mit Software sowohl die Komplexität des sozialen Kontexts berücksichtigen, in den dieser Umgang eingebettet ist, als auch der Komplexität der möglichen Einflüsse Rechnung tragen, die über Software in diesen sozialen Kontext hineinwirken. Es kann untersucht werden, welche Zusammenhänge einige Modelle in Software zwischen einer überschaubaren Anzahl an sozialen Prozessen herstellen, wie und wohin einige Formen von Kontrolle durch den Umgang mit Software verschoben werden, und welche Auswirkungen einige Strukturen sozialer Systeme, die Modelle produzieren, auf den Umgang mit Software haben können. Sie erlaubt es vor allem, mit der eigenen Arbeit an die Ergebnisse anderer Studien anzuknüpfen, in denen die Entwicklung und Nutzung bestimmter Softwaremodelle untersucht worden ist. Damit unterstützt sie die langfristige Entwicklung einer Wissensbasis über bestimmte Modelle, die häufig in Software eingebettet werden.

Allgemeine Aussagen über die konkrete Performativität bestimmter Formen von Software können ohne eine solche Wissensbasis nicht getroffen werden. Dies ergibt sich aus der Komplexität der Problemstellung, der Menge an möglichen relevanten Forschungsgegenständen und dem fragmentarischen Stand der Forschung: Wenn Soziolog*innen verallgemeinerbare Aussagen über die konkrete Performativität bestimmter Formen von Software treffen wollen, müssen sie nicht nur einen Zusammenhang zwischen bestimmten Modellen und bestimmten Formen des Umgangs mit Software aufzeigen können, sondern auch nachvollziehbar begründen, weshalb diese Umgangsformen nicht ebenso überzeugend auf andere der vielen in die Software eingebetteten Modelle oder andere soziale Bedingungen zurückgeführt werden sollten. Für solche Aussagen bedarf es umfangreicher Forschungsarbeiten, in denen Entwicklung und Nutzung der gleichen (Form von) Software aus verschiedenen Perspektiven untersucht worden sind. Bisher existieren solche Arbeiten in Ansätzen nur zu ERP-Systemen, insbesondere SAP. Diese sind das Ergebnis eines Forschungsprogramms zur Biographie von Artefakten, das mit den gleichen Argumenten zur Komplexität des Gegenstands motiviert wird, die ich hier dargestellt habe (Williams und Pollock 2012).

Die vorgeschlagene Vorgehensweise bietet Anhaltspunkte dafür, wie einige der notwendigen Eingrenzungen der Untersuchung mit anderen zusammen hängen (z. B. genutzte Softwareelemente, Modelle und passende soziale Systeme der Konstruktion), nimmt die Forscher*innen jedoch nicht aus der Verantwortung, eigene Entscheidungen zu treffen. Andere notwendige Eingrenzungen (welche Prozesse, welche Art von Modellen) bleiben völlig den Forschenden überlassen. Insgesamt kann die Vorgehensweise Forscher*innen dafür sensibilisieren, welche Aspekte bei der Untersuchung von sozio-technischen Phänomenen mit Software berücksichtigt werden müssen, ihnen jedoch nicht zentrale Entscheidungen im Forschungsprozess abnehmen. Zwei methodische Hinweise lassen sich aus den Ausführungen ableiten:

(1)
Aus einer soziologischen Perspektive muss eine empirische Untersuchung des Umgangs mit Software, in der die Software komplett abstrakt behandelt wird, kritisch hinterfragt werden. Wenn Forscher*innen sich unmittelbar auf (vermutete) Veränderungen der Handlungsfähigkeit der Nutzer*innen konzentrieren, ohne am konkreten Artefakt zu überprüfen, worauf sich diese vermeintlichen Veränderungen gründen und welche Nebenfolgen sie haben, werden sie der Performativität von Software im Sozialen nicht gerecht. Statt die Frage nach den Details der Technik als Thema für Informatiker*innen abzutun, müssen Soziolog*innen, die Software für einen relevanten Gegenstand der Forschung halten, methodische Zugänge finden, die dem konkreten Forschungsinteresse angemessen sind und es erlauben, technische und soziale Bedingungen sowie den Umgang der Akteur*innen damit im konkreten Fall gleichzeitig aufzunehmen. In solchen Zugängen müssen die Interpretationen und Handlungsmöglichkeiten der Akteur*innen sowie die asymmetrische Verteilung von Handlungsressourcen berücksichtigt werden.
(2)
Performative Modelle und die über sie vermittelten Kontrollversuche liegen auf höheren Abstraktionsebenen als der detailreiche Code und können sich auf verschiedene Programme oder Softwareebenen verteilen, die beim Umgang mit Software zusammenwirken. Die Rekonstruktion von Modellen aus dem zusammengefassten Code aller zur Laufzeit aktiven Programme ist – von Zugangsproblemen abgesehen – kaum praktikabel. Aus reinen Codeanalysen lassen sich kaum Erkenntnisse über die Modelle und ihre Abhängigkeiten untereinander gewinnen. Erfolgversprechender erscheint die Analyse von Dokumenten aus einzelnen Phasen der Softwareentwicklung wie Spezifikationen, Datenmodellen u. a. Dieser stehen in der Praxis ebenfalls oft Zugangsprobleme im Weg. Selbst wenn diese ausgeräumt sind, muss jedoch immer berücksichtigt werden, dass jedes dieser Dokumente nur einen Teil der Unsicherheitsreduktionen beschreibt, die beim Umgang mit Software performativ werden, da es in ein Geflecht vor- und nachgelagerter Modellierungsprozesse eingebunden ist. Mit der vorgeschlagenen Vorgehensweise wird somit keine Methodik zur Untersuchung von Modellen festgelegt, aber auf die Grenzen bestimmter methodischer Ansätze aufmerksam gemacht.

3.3 Forschungsrahmen der empirischen Untersuchung

Im verbleibenden Teil der vorliegenden Arbeit demonstriere ich die Anwendung der bisher ausgeführten Überlegungen auf eine empirische Untersuchung. Entsprechend der in 3.2 dargestellten Vorgehensweise wird der Analyserahmen ausgehend vom empirischen Gegenstand und der Forschungsfrage konstruiert.

Gegenstand der Untersuchung ist der Umgang mit der standardisierten Krankenhaussoftware eMed im Rahmen der OP-Planung in einem großen deutschen Universitätsklinikum mit mehreren Abteilungen, in denen chirurgische Eingriffe durchgeführt werden. Die Software eMed ist ein Krankenhausinformationssystem (KIS), das auf der standardisierten Organisationssoftware SAP basiert. Für die Fallstudie greife ich auf die zu SAP verfügbare soziologische Wissensbasis zurück und demonstriere damit, wie die vorgeschlagene Vorgehensweise dazu genutzt werden kann, um bestehende Forschung zu erweitern. Dabei thematisiere ich in der Fallstudie einen im Rahmen der soziologischen Forschung zu SAP bisher unterbelichteten Aspekt: den Zusammenhang zwischen den verschiedenen Versuchen, die Prozesse in Organisationen über Software und organisatorische Regeln zu kontrollieren, und den Handlungsmöglichkeiten, die Nutzer*innen haben, um sich diesen Kontrollversuchen zu entziehen. Am ausgewählten Fall werden besonders die in Kapitel 2 betonten systemischen Einbettungen dieser Kontrollversuche sichtbar.

3.3.1 Besonderheiten des Forschungsgegenstands

In Krankenhäusern treffen sehr unterschiedliche gesellschaftliche Anforderungen aufeinander (Iseringhausen und Staender 2012): Krankenhäuser sind Organisationen, die Menschen „bearbeiten“ und dadurch in der Wahl ihrer Mittel unter besonderer Beobachtung der Gesellschaft stehen (Klatetzki 2010). Sie sollen eine „wohlfahrtsgesellschaftliche Infrastrukturfunktion“ (Bode 2010) im Bereich Gesundheit erfüllen, akut erkrankte Patient*innen behandeln, der medizinischen Profession Raum für die Berufsausübung und die Ausbildung des Nachwuchses bieten und medizinische Forschung ermöglichen (Rohde 1974). Für all diese Aufgaben brauchen sie Geld. Krankenhäuser gelten daher als professionelle Organisationen (Mintzberg 1991), in denen mehrere konkurrierende Formen der Kontrolle aufeinandertreffen. Strukturell prallen so die klassische hierarchische Kontrolle der Organisation und die kollegiale und disziplinär geordnete Kontrolle der Profession aufeinander. In ersterer, der bürokratischen Ordnung, werden Über- und Unterordnung und korrekte Verfahren durch formale Regeln der Organisation legitimiert (Weber 2005 [1922]). In letzterer, der professionellen Ordnung der Medizin, dominieren Ärzt*innen sowohl in der Beziehung zu allen anderen medizinischen Dienstleister*innen als auch bei der Definition des legitimen Fachwissens (Freidson 1963). Dieses Wissen befähigt seine Träger*innen, mit anerkannter Autorität zu entscheiden welche Eigenschaften einer Patient*in als Symptome einer Krankheit und welche als medizinisch unauffällig gelten, welche Behandlung bei welcher Diagnose angezeigt ist, wann Patient*innen als geheilt gelten und so weiter (Abbott 1988). Die zentralen Leistungsprozesse von Krankenhäusern werden von den Mitgliedern der medizinischen Profession erbracht, Regeln für die Leistungserbringung werden größtenteils innerhalb der Profession, für das Krankenhaus also von Ärzt*innenverbänden, geregelt. Diese Regeln, in denen Symptome mit Diagnosen und Diagnosen mit Behandlungen verknüpft werden, gestehen den einzelnen Akteur*innen große Ermessensspielräume innerhalb eines stark standardisierten Rahmens an Handlungsmöglichkeiten zu: Eine Vielzahl an medizinischen Leitlinien, unüberschaubare Forschungsergebnisse und die Grundhaltung, dass jede Patient*in individuell zu betrachten ist, führen dazu, dass Erfahrung und Intuition von Ärzt*innen als Entscheidungsgrundlage eine große Rolle spielen (Vogd 2004b, S. 23–28). Da die Kontrolle und Sanktionierung des professionellen Handelns Fachwissen voraussetzt, auf das die Profession ein gesellschaftlich legitimiertes Monopol besitzt, stehen professionelle und organisatorische Formen der Kontrolle in Krankenhäusern in Konkurrenz (Freidson 1963): Manager*innen können formale Regeln für die Patient*innenbehandlung erlassen, weil die Regelung zentraler Prozesse der Organisation zu ihren legitimen Aufgaben gehört, aber Ärzt*innen können von diesen Regeln jederzeit legitimerweise abweichen und sich dabei auf ihre professionelle Entscheidungshoheit berufen. Auseinandersetzungen um die Entscheidungshoheit zwischen Management und Ärzt*innen sind damit in der Struktur des Krankenhauses angelegt. In Universitätskliniken treffen zusätzlich zwei Formen professioneller Organisationen zusammen, nämlich die der Medizin und die der Wissenschaft. Organisationsinterne Aushandlungen können dadurch gleichzeitig durch Bezugnahme auf die Hierarchie innerhalb der Organisation, in die medizinische Profession oder die Wissenschaft beeinflusst werden.

In Krankenhäusern kommt häufig standardisierte Organisationssoftware zum Einsatz. Diese stellt den zweiten Teil des in dieser Arbeit untersuchten Forschungsgegenstands dar. Durch ihre Struktur und ihren Nutzungskontext eignet sich standardisierte Organisationssoftware besonders gut, um sowohl die in der soziologischen Forschung bisher größtenteils unterbelichtete dritte Ebene der Komplexität von Software (s. Abschnitt 2.1.3) als auch die systemische Einbettung aller Formen des Umgangs mit Software systematisch zu untersuchen: Sie ist langlebig und wird im Laufe ihrer Lebensdauer nicht nur nacheinander in unterschiedlichen Versionen, sondern auch gleichzeitig in unterschiedlichen Varianten der gleichen Version genutzt. Diese Varianten sind Folge einer kuratierten Flexibilität, die sicherstellen soll, dass möglichst viele Kund*innen die Software als Lösung für ihre speziellen Probleme akzeptieren, ohne dass dadurch grundlegende technische Strukturen verändert werden müssten. Standardisierte Organisationssoftware wird fast immer von einer formalen Organisation produziert und nicht wie andere Formen von Software, in einer Open-Source-Gemeinschaft freiwilliger Entwickler*innen. Daher lässt sich das primäre soziale System, in dem die Entwicklung stattfindet, innerhalb der Herstellerinnenorganisation der Software verorten. Die strategischen Interessen dieser Organisation sind für das Handeln in diesem sozialen System bedeutungsvoll; so werden zum Beispiel die Vielzahl an Umgangsformen und Problemen, die sich innerhalb der verschiedenen Anwendungskontexte entwickeln, bei der Weiterentwicklung berücksichtigt, aber in einer Weise, die systematisch auf die Interessen der Herstellerin abgestimmt ist (Pollock und Williams 2009). Standardisierte Organisationssoftware unterstützt eine Vielzahl von Praktiken innerhalb formaler Organisationen. Viele dieser Praktiken sind nicht nur innerhalb der Organisation formal reglementiert, sondern müssen oft zusätzlich gesetzlichen Vorgaben, technischen und organisatorischen Standards, den Regeln von Branchenverbänden oder ähnlichen organisationsexternen Reglements folgen. Daher orientieren sich Herstellerinnen in ihren Produktentwicklungsstrategien nicht nur an bekannten oder vermuteten Nutzungspraktiken, sondern berücksichtigen auch die Einflüsse verschiedener Regulierungsinstanzen, die die unterstützten Praktiken reglementieren. Brita Hohlmann (2007, S. 16) gibt Beispiele zu den Anforderungen, die aus verschiedenen Umwelten an die Funktionalität von ERP-Systemen gestellt werden. Als relevante Regulierungsinstanzen in solchen Umwelten sind zum Beispiel Regierungs- und Nichtregierungsorganisationen zu betrachten, die Steuer-, Umwelt-, Arbeits- oder andere unternehmensrelevante Gesetze erarbeiten, Industriestandards aushandeln oder ähnliches. Darüber hinaus ist auch die Kompatibilität mit anderen für Organisationen relevanten Softwareprodukten wichtig, weil standardisierte Organisationssoftware sich an einen möglichst breiten Kund*innenkreis richtet. Bei dieser Art von Software handelt es sich insgesamt um ein technisch komplexes Artefakt, das unter komplexen Bedingungen entsteht.

Die Komplexität der untersuchten Organisation und der untersuchten Software erfordern, dass klar eingegrenzt wird, welche Art von performativen Modellen für eine Untersuchung ausgewählt werden soll. Für die vorliegende Arbeit konzentriere ich mich auf performative Modelle, die ich Modelle des Organisierens nenne. Diese Modelle definiere ich im folgenden Abschnitt genauer.

3.3.2 Fokussierte Modelle und Fragestellung

Als Modelle des Organisierens bezeichne ich performative Modelle, die Arbeitsprozesse in Organisationen so strukturieren, dass durch die Zusammenarbeit der Akteur*innen in diesen Prozessen ein fixer, im Laufe der Modellbildung ausgehandelter Zweck erreicht werden kann. Einem Modell des Organisierens liegt eine Reihe zusammenhängender Annahmen darüber zu Grunde, welche Art von Akteur*innen in Organisationen wie und wozu zusammenarbeiten. Auf diesen Annahmen basieren alle Eigenschaften des Modells. Zu diesen Eigenschaften zählen eindeutige Definitionen dieser Akteur*innen, ihrer Beziehungen zueinander und zu ihrer relevanten Umwelt und der Objekte, mit denen sie umgehen. Auch die Regeln für diesen Umgang lassen sich als Eigenschaften des Modells verstehen. In einem Modell des Organisierens wird damit eine abstrakte Vorstellung davon, was und wie organisiert wird, mit konkreten Strukturelementen, die in Software umgesetzt werden können, verknüpft. In dieser Hinsicht ähnelt es einem organisationalen Archetyp (Greenwood und Hinings, C. R. 1993). In einem organisationalen Archetyp sind Deutungsmuster mit strukturellen Attributen und Prozessen einer Organisation zu einem konsistenten Ganzen verbunden. Wie organisationale Archetypen lassen sich Modelle des Organisierens nur empirisch aus der Interpretation der Auseinandersetzung der Akteur*innen mit ihren Elementen rekonstruieren (a.a.O., S. 1076). Ihre Einzelheiten sind zwar vollständig ausformuliert, dies geschieht aber in unterschiedlichen Modellierungsprozessen. Die Formulierungen sind somit Ergebnisse unterschiedlicher Aushandlungen. Keine dieser Aushandlungen allein bringt die Modelle des Organisierens hervor. Die Modelle, die bei der Nutzung performativ werden, lassen sich damit nur auf ein Geflecht von Modellierungsprozessen und damit Aushandlungen zurückführen. In der vorliegenden Arbeit untersuche ich die Praktiken des Umgangs mit Software bei der OP-Planung. In diesen Praktiken werden Modelle des Organisierens performativ, weil sich die Akteur*innen beim Umgang mit Software mit den Datenstrukturen, formalen Prozessvorlagen (Templates) und Berechtigungen für bestimmte Funktionen auseinandersetzen, die in die Software eingebettet sind.

Modelle des Organisierens bilden eine überschaubare Teilmenge aller in standardisierte Organisationssoftware eingebetteten Modelle: Standardisierte Organisationssoftware soll alle Arbeitsprozesse in einer Organisation informationstechnisch integrieren und es möglich machen, die Zusammenarbeit in der Organisation so zu kontrollieren, dass sie zu einem einheitlichen Organisationsziel beiträgt. Die Integration verschiedener Arbeitsprozesse und deren Ausrichtung auf das gleiche Ziel ist daher der übergeordnete Zweck der Software. Wie in Abschnitt 2.1 ausgeführt, wird dieser zu Beginn des Softwareentwicklungsprojekts ausgehandelt und dann in den verschiedenen Modellierungsprozessen der Entwicklung als unhinterfragte Rahmenbedingungen übernommen. Nur in Ausnahmefällen wird der Zweck der Software an sich während der Softwareentwicklung grundsätzlich hinterfragt. Da die Integration aller Arbeitsprozesse mit Blick auf ein einheitliches Ziel eine zentrale Vorgabe der Softwareentwicklung ist, ist davon auszugehen, dass diese einheitliche Ausrichtung auch bei der Modellierung einzelner Arbeitsprozesse bedeutsam ist. Diese einheitliche Ausrichtung kommt im Modell des Organisierens zum Ausdruck.^{Footnote 9} Mehr noch: Die Software kann den vorgegebenen Zweck nur erfüllen, wenn es gelingt, alle Modelle, die in Teilprozessen geschaffen werden, in einem einheitlichen Modell des Organisierens zusammenzuführen. Enthält eine standardisierte Organisationssoftware mehrere unterschiedliche Modelle, so ist zu erwarten, dass sie nicht in ein und demselben Softwareentwicklungsprojekt entstanden sind – zumindest nicht, wenn dieses an seinem Ende als erfolgreich bewertet worden ist. Als Ursprung verschiedener Modelle des Organisierens kommen damit die langfristige Weiterentwicklung, die Entwicklung von Varianten oder die Einführung der Software in einzelne Organisationen in Frage, nicht jedoch beliebige einzelne Modellierungsprozesse im gleichen Lebenszyklus. Die Anzahl der möglichen Modelle des Organisierens, die beim Umgang mit der Software vermutlich eine Rolle spielen können, ist daher durch die Zahl der untersuchten Versionen, Varianten und Organisationen begrenzt. In der vorliegenden Arbeit werden zwei Versionen der gleichen Variante von SAP in einem Krankenhaus in ihrem Einfluss auf konkrete sozialen Prozesse in diesem Krankenhaus analysiert. Da die Software in fast allen Bereichen der Sanusklinik eingesetzt wird und eine vollständige Untersuchung aller Formen des Umgangs mit eMed weder im Rahmen der Dissertation möglich noch notwendig ist, um die Anwendung des Konzepts zu demonstrieren, das den Kern dieser Arbeit ausmacht, habe ich mich aus pragmatischen Gründen auf einige der zentralen Prozesse in der Chirurgie konzentriert. Die Fragestellung der empirischen Untersuchung lautet daher:

Welche Rolle spielen in eMed eingebettete Modelle des Organisierens für den Umgang mit der Software bei der OP-Planung der Sanusklinik?

3.3.3 Datenerhebung und -auswertung

Zur Beantwortung der Forschungsfrage dient eine Einzelfallstudie, die auf den methodologischen Grundannahmen der Grounded Theory basiert (Strübing 2019). Ziel ist die Konstruktion einer gegenstandsbezogenen Theorie, die auf den im Forschungsprozess erhobenen Daten und Interpretationen beruht und auf diesem Prozess sowie den ihn leitenden theoretischen Vorannahmen basiert (a.a.O.). Zur Einordnung der Vorgehensweise werde ich daher zuerst die zentralen theoretischen Vorannahmen der Untersuchung explizieren und dann die Datengrundlage und grundlegende Informationen zu den Bedingungen der Datenerhebung angeben.

Drei theoretische Vorannahmen standen zu Beginn der Untersuchung fest. Die erste lautete, dass Software über konkrete technische Strukturen im Kontext der Anwendung performativ wird. Diese Annahme wurde in den vorangegangenen Teilen der vorliegenden Arbeit erläutert und spiegelt sich in der Forschungsfrage. Die zweite Annahme lautete, dass der Umgang mit Software als Ausprägung von Praktiken betrachtet werden kann, als wiederkehrende, überindividuell geteilte, regelgeleitete und situativ adaptierbare Handlungsweisen, an denen Akteur*innen sich in ihrem Handeln orientieren (vgl. Abschnitt 2.2). Die dritte Annahme war, dass diese Praktiken von den strukturellen Bedingungen der sozialen Kontexte beeinflusst sind, in denen sie stattfinden, weil die Akteur*innen, die diese Praktiken entwickeln, umsetzen und verändern, diese Bedingungen in ihrem Handeln berücksichtigen müssen. In Organisationen sind solche strukturellen Bedingungen zum Beispiel formale und informelle Organisationsregeln und die aus ihnen abgeleiteten Machtstrukturen. In Einklang mit der Forschungsfrage stand die Organisation als bedeutsamer sozialer Kontext von Beginn an im Fokus der Untersuchung.

Die Fallstudie basiert vor allem auf qualitativen Daten. Die Daten zum Umgang mit Software wurden in der Sanusklinik erhoben. Der größte Teil der Daten zur Rekonstruktion der Modelle des Organisierens stammt aus öffentlich zugänglichen Quellen über eMed, vor allem der Softwaredokumentation für Administrator*innen und verschiedenen Studien über SAP und Krankenhausinformationssysteme. Die Hauptphase der Datenerhebung in der Sanusklinik erstreckte sich über einen Zeitraum von 12 Monaten in den Jahren 2013 und 2014. Erste Daten zur Software wurden parallel dazu erhoben, der größte Teil der Datenerhebung zur Software erstreckte sich jedoch auch auf den späteren Analyseprozess und wurde erst 2018 abgeschlossen. Die Datenauswahl folgte der Logik des theoretischen Samplings (Glaser und Strauss 2017). Für die Erhebung der Daten zum Umgang mit Software führte ich leitfadengestützte Interviews^{Footnote 10} mit vier Chirurg*innen aus verschiedenen Abteilungen, zwei Pflegeleitungen und zwei Sekretär*innen, die alle für Aspekte der OP-Planung mit eMed verantwortlich waren. Darüber hinaus wurden auch der OP-Koordinator, ein Anästhesist und die für das OP-Modul Verantwortliche aus der IT-Abteilung interviewt. Die Interviews fanden in zwei Phasen statt, wobei die Erkenntnisse aus der vorläufigen Auswertung früherer Interviews (mit zwei Chirurgen, einer Pflegeleitung und der IT-Verantwortlichen) in die Fragen für die späteren Interviews einflossen. Die Auswertung der ersten Interviews ergab, dass die Variation der Planungspraktiken und Softwarekonfigurationen zwischen den chirurgischen Abteilungen zu hoch war, um im Rahmen der Studie fundierte Aussagen über alle Abteilungen treffen zu können. Daher wurde die Untersuchung auf zwei in relevanten Punkten (Größe, Notfallquote und Nutzungszeit) vergleichbare Abteilungen eingeschränkt, die hier als allgemeine und spezielle Chirurgie bezeichnet werden (s. Kapitel 4). In einer dritten Phase wurde ein weiteres Interview mit der IT-Verantwortlichen geführt und der OP-Planer an einem Arbeitstag begleitet. Dabei wurde auch der OP-Planer im Tagesverlauf ein weiteres Mal interviewt. Darüber hinaus wurden im Zuge der Begleitung auch Beobachtungsprotokolle von verschiedenen Abstimmungsgesprächen mit der Pflegekoordination, Anästhesist*innen und verschiedenen Mitgliedern chirurgischer Abteilungen erstellt. Weitere Beobachtungsprotokolle wurden zur Softwarenutzung bei der OP-Planung, der anästhesistischen und pflegerischen Dokumentation und der Koordination von Änderungen im OP-Plan über eMed erstellt. Die Befragten waren Mitglieder verschiedener an der Operationsplanung beteiligter Gruppen und wurden so ausgewählt, dass alle zentralen Positionen innerhalb des Prozesses (Chirurg*innen mit und ohne Planungsberechtigung, Pflegekräfte) abgedeckt waren und auch die wichtigsten vermittelnden (OP-Koordination, Anästhesie) und externen Teilnehmer*innen des Prozesses (Verwaltungspersonal) Berücksichtigung fanden. Schließlich wurde eine standardisierte Befragung aller Nutzenden des OP-Moduls mit Planungsberechtigung durchgeführt. Vorgehen und weiterführende Ergebnisse dieser Befragung sind an anderer Stelle dokumentiert (Engelmann und Ametowobla 2017; Engelmann et al. 2017).

Zur Analyse der in der Sanusklinik installierten Variante der Software diente zusätzlich zu den Daten zum Arbeitsprozess auch das klinikspezifische Benutzerhandbuch für das OP-Modul für Pflege, Chirurgie und Anästhesie. Für die Analyse der generischen Form der Software wurde die öffentlich zugängliche Dokumentation der Module genutzt, die über die Website von SAP verfügbar ist (SAP AG 2001, o. J.a, o. J.b, o. J.c).

Zur Beantwortung der Forschungsfrage wurde wie in Abschnitt 3.2 vorgegangen. Die Ergebnisse werden im folgenden Kapitel 4 dargestellt.

Notes

1.
Die grundlegende Bedeutung der Dyaden für die strategische Organisationsanalyse ergibt sich aus der Tatsache, dass Macht als intransitiv verstanden wird. Die Beziehungen, aus denen Konstrukte kollektiven Handelns „vor allem“ bestehen (Crozier und Friedberg 1979, S. 39), sind also jeweils spezifische Beziehungen zwischen genau zwei Akteur*innen.
2.
Alle Interaktionsprozesse können in der strategischen Organisationsanalyse als Tauschprozesse betrachtet werden. Wenn Handlungssysteme statt Dyaden betrachtet werden, wird sichtbar, dass die Handlungsoptionen, die jede Akteur*in sich wünscht und zum Tausch anbieten kann, sehr stark von denen aller anderen Akteur*innen im Handlungssystem abhängen. Interaktionsprozesse in Handlungssystemen lassen sich daher als vielseitige Tauschprozesse untersuchen.
3.
Ein Handlungsproblem liegt per definitionem nur dann vor, wenn es Ungewissheiten in Bezug auf die Lösung gibt.
4.
Anschauliche Beispiele für diese Auf- und Abwertung von Kompetenzen finden sich in Barleys Studie zur Veränderung von Interaktionsstrukturen in zwei radiologischen Abteilungen nach der Einführung modernerer Verfahren der medizinischen Bildgebung: In „a surprisingly short period of time“ (der gesamte Studienzeitraum betrug nur ein Jahr) wurden die jüngsten Radiolog*innen, denen am meisten Kompetenzen in der Interpretation der „neuen“ Bilder zugeschrieben wurde, zu den wichtigsten diagnostischen Ratgeber*innen, während die älteren bei der Lösung von diagnostischen Problemen innerhalb der Abteilung trotz ihrer prinzipiell größeren fachlichen Erfahrung wenig bis keine Rolle mehr spielten (Barley 1990, S. 77–79).
5.
Die Beziehung zu Umweltsegmenten ebenso wie die Kontrolle von Informationen und Kommunikationskanälen werden von Crozier und Friedberg als typische Ungewissheitsquellen in Organisationen betrachtet (Crozier und Friedberg 1979, S. 50), eine Betrachtung, die auf alle Handlungssysteme, also auch auf nicht formal organisierte, verallgemeinert werden kann.
6.
Ich nutze hier die Begrifflichkeit Innovations- und Routinespiel von Ortmann et al. (1990), es soll aber betont werden, dass die Begriffe im Rahmen der vorliegenden Arbeit allein über die hier aufgeführten, sehr allgemeinen Definitionen bestimmt sind. Ortmann et al. erarbeiten eine deutlich weitreichendere Konzeption dieser beiden Spieltypen und ihrer Zusammenhänge, die hier nicht aufgegriffen wird. In der folgenden empirischen Untersuchung dient die hier getroffene Definition ausschließlich der besseren Unterscheidung der verschiedenen im Fall beobachteten Spielformen. Eine grundlegende Analyse im Hinblick auf die für die beobachteten Innovations- und Routinespiele charakteristischen Gewinnchancen (a.a.O., S. 48 ff.) und Gewinnstrategien (a.a.O., S. 464 ff.) sowie der Zusammenhänge zwischen diesen Spieltypen (a.a.O., S. 468), die notwendig erscheint, um die Begriffe in ihrer ursprünglichen Definition zu verwenden, lag nicht im Fokus der vorliegenden Arbeit.
7.
Diese Aussage gilt nur, wenn die Modelle in den Innovationsspielen relevant (gemacht) werden. Natürlich existieren auch Innovationsspiele, in denen Software oder mit ihr verbundene Modelle keine besondere Rolle spielen. Diese sind für die Ausführungen hier uninteressant, weil sie nicht im Bereich des Forschungsinteresses liegen.
8.
Falls bei der Forschungsfrage nicht Software, sondern noch nicht in Code überführte Modelle, wie z. B. technische Standards, im Mittelpunkt stehen, werden diese als Ausgangspunkt genutzt.
9.
Damit ist nicht gesagt, dass standardisierte Organisationssoftware nur Modelle des Organisierens enthalte oder dass nur diese performativ werden könnten. Dies wäre ein Trugschluss. Standardisierte Organisationssoftware enthält wie andere Software auch Modelle von Nutzer*innen und ihren Kompetenzen, Modelle von wirtschaftlichen Zusammenhängen, Modelle menschlicher Beziehungen und viele andere Modelle. In dieser Arbeit konzentriere ich mich jedoch auf Modelle des Organisierens, weil diese besonders geeignet scheinen, um zu analysieren, wie Organisationssoftware externe Einflüsse in Organisationen vermittelt.
10.
Die Länge der Interviews variierte zwischen 20 Minuten und zwei Stunden mit einem Durchschnitt von etwa 45 Minuten.

Author information

Authors and Affiliations

Technische Universität Berlin, Berlin, Deutschland
Dzifa Ametowobla

Authors

Dzifa Ametowobla
View author publications
You can also search for this author in PubMed Google Scholar

Corresponding author

Correspondence to Dzifa Ametowobla .

Rights and permissions

Open Access Dieses Kapitel wird unter der Creative Commons Namensnennung 4.0 International Lizenz (http://creativecommons.org/licenses/by/4.0/deed.de) veröffentlicht, welche die Nutzung, Vervielfältigung, Bearbeitung, Verbreitung und Wiedergabe in jeglichem Medium und Format erlaubt, sofern Sie den/die ursprünglichen Autor(en) und die Quelle ordnungsgemäß nennen, einen Link zur Creative Commons Lizenz beifügen und angeben, ob Änderungen vorgenommen wurden.

Die in diesem Kapitel enthaltenen Bilder und sonstiges Drittmaterial unterliegen ebenfalls der genannten Creative Commons Lizenz, sofern sich aus der Abbildungslegende nichts anderes ergibt. Sofern das betreffende Material nicht unter der genannten Creative Commons Lizenz steht und die betreffende Handlung nicht nach gesetzlichen Vorschriften erlaubt ist, ist für die oben aufgeführten Weiterverwendungen des Materials die Einwilligung des jeweiligen Rechteinhabers einzuholen.

Reprints and permissions

Copyright information

About this chapter

Cite this chapter

Ametowobla, D. (2022). Spiele mit Expert*innensystemen. In: Zur Soziologie der Software. Springer VS, Wiesbaden. https://doi.org/10.1007/978-3-658-37256-9_3

Download citation

DOI: https://doi.org/10.1007/978-3-658-37256-9_3
Published: 04 May 2022
Publisher Name: Springer VS, Wiesbaden
Print ISBN: 978-3-658-37255-2
Online ISBN: 978-3-658-37256-9
eBook Packages: Social Science and Law (German Language)

Publish with us

Policies and ethics