Die situative Wirkungsanalyse: eine Alternative zur klassischen "Prozessaufnahme"

Wenn eine Organisation - ein Unternehmen oder eine öffentliche Verwaltung - eine Unternehmenssoftware einführen will, dann steht sie vor der Aufgabe, die künftigen Anwender:innen - die „Projektkunden“ - kontinuierlich in das Projekt einzubinden. Das gilt für die Beschaffungsphase der Software, noch mehr aber für die anschließende Implementierungsphase.  Wie packen wir in agilen Projekten diese Aufgabe an?

Klassische Projektaufnahme

Oft greift man in dieser Situation zur klassischen Prozessaufnahme. Die Anwender:innen einer Abteilung werden zu einem Workshop eingeladen, der von einem Experten für BPMN oder andere Methoden der Prozessaufnahme geleitet wird. (Oft ist es ein externer Berater.) Er stellt den Workshop-Beteiligten Fragen zu ihren Abläufen, und diese antworten. Der Experte visualisiert die Antworten in Form eines Flussdiagramms.

Die aktive Seite des Verfahrens liegt auf Seiten des Experten, die passive - antwortende - auf Seiten der Prozessanwender. Oft bereiten die Antworten Mühe. "Und was machen Sie dann mit der Eingangsrechnung?" - "Dann leite ich sie an die beschaffende Abteilung zur Prüfung weiter." - "Immer?" - "Ja. Klar." - "Wirklich immer?" - "Ach so, wenn es sich um IT-Hardware-Beschaffungen handelt, ist Herr Müllerschön zuständig." - "Warum Herr Müllerschön?" - "Na, weil der das IT-Lager verwaltet und immer die Funktionstests der Hardware vornimmt."

Am Ende ist alles und sind alle geschafft. Die Meinung des Experten hat sich verfestigt: "Die Leute kennen nicht mal ihre eigenen Prozesse." Man spricht im Workshop auch über mögliche Vereinfachungen der Abläufe, aber im Allgemeinen sollen die nur in der Software so abgebildet werden, wie sie sind. Warum sollte man auch was ändern? Herr Müllerschön ist nun mal in bestimmten Fällen zuständig und warum sollte er das nicht bleiben? Außerdem war er eh nicht zum Workshop eingeladen.

Was mir aber sehr oft als Ergebnis dieser Workshops aufgefallen ist: sie bringen kaum Energie ins Team. Ganz selten brennen die Betroffenen darauf, die Ergebnisse wirklich in der neuen Software umzusetzen. Das Ergebnis erscheint relativ abstrakt und eine Vorstellung vom Nutzen kommt nicht wirklich auf.

Die situative Wirkungsanalyse

Seit einiger Zeit gehen wir anders vor. Wiederum werden die Anwender:innen zu einem Workshop eingeladen, der aber erheblich kürzer angesetzt wird als bei der klassischen Vorgehensweise. Dort stellen wir den Teilnehmer:innen folgende Aufgabe:

„Wir möchten gern eine ganz genaue Vorstellung von Ihren Anforderungen als künftige Anwender:innen der neuen Software erhalten. Nehmen Sie sich bitte einen Flipchart-Bogen. Denken Sie an einen konkreten Fall in den circa letzten zwei, drei Wochen, bei dem Sie gestört, unterbrochen, gestresst wurden oder über den Sie sich geärgert haben - in Bezug auf [hier folgt ein Verweis auf das Themenfeld der Software].

Beschreiben Sie diese Störung entlang der folgenden Fragen:“ (siehe Abbildung 1)

Wenn es zum Beispiel bei der Software um die Einführung eines Dokumentenmanagement-Systems ginge, könnte in den [eckigen Klammern] stehen: "das Suchen nach Dokumenten oder Informationen, über den Status eines Vorgangs oder Ähnliches - alles, was im weitesten Sinne mit Teilen von Dokumenten und Informationen im Team zu tun hat." Und bei Beschaffung eines CRM für den Vertrieb oder einer Campus-Management-Plattform einer Hochschule entsprechend andere Fragen.

Abbildung 1: Fragen zu einer Störungssituation

 Die Ergebnisse dieser Abfrage sollten so konkret wie möglich sein. Abbildung 2 zeigt das Ergebnis eines Workshops im Rahmen eines DMS-Einführungsprojekts mit einer Einkaufsabteilung:

Abbildung 2: Ein Beispiel für eine situative Analyse

 

Bei dieser Beschreibung kann man sich als außenstehender Dritter ein gutes Bild machen, was in dieser Situation passiert ist. So konkret sind die ersten Resultate nicht immer. Manche Anwender:innen tun sich schwer mit dem konkreten Denken auf einen Fall hin bezogen. Sie geben Beschreibungen wie 

„Ich suche ständig nach Dokumenten und Informationen bei anderen Teammitgliedern. Aber weil sich niemand bei uns an die Namensregeln hält, muss ich dauernd rückfragen.“

Menschen versuchen ständig, Muster und Regeln in der Welt zu erkennen, und klassifizieren ihre Erfahrungen. Dieser Übergang von einem konkreten Vorkommnis zu einer Verallgemeinerung stellt aber eine Verarmung dar, keine Anreicherung. In einem solchen Fall frage ich immer nach: "Nach welchen Dokumenten und Informationen suchen Sie denn? Wann kam es das letzte Mal vor? Welche Teammitglieder waren beteiligt?" Nur dann können wir nämlich den nächsten Schritt gehen.

Von der Wirkungsanalyse zu Anforderungen

Jetzt wollen wir nämlich vom unbefriedigenden Heute zur strahlenden Zukunft im Morgen gelangen. Dazu müssen wir Anforderungen für die beschriebenen Störungen formulieren.  

Dazu haben wir wieder ein „Leerformular“, das diese Aufgabe strukturiert:

 

Abbildung 3: Ein Formular für Anforderungen

Und in unserem Beispiel lautete die Antwort, die die Teilnehmerin auf eine Flipchart schrieb:

Abbildung 4: Beispiel für die Formulierung von Anforderungen

 

Die Resultate

Meistens herrscht nach Abschluss dieser Analyse eine motivierte Stimmung im Team. Es ist Energie ins Projekt geflossen. Meiner Meinung nach spielen dabei folgende Faktoren eine Rolle:

• Die Methode übergibt die aktive Rolle an die Teilnehmer:innen des Workshops. Es werden ihnen nur ein paar allgemeine Fragen vorgegeben, die sie beliebig ausfüllen können.
• Es wird nicht nach Regeln gefragt à la Flussdiagramm: "Immer wenn ich A mache, mache ich hinterher B." Menschen handeln nicht nach bewussten Regeln, sondern situativ und sinnvoll. Wenn sie nach Regeln gefragt werden, wie im Interview nach BPM, dann erfinden sie sie im Augenblick ihrer Antwort. Und nach Problemen, die vielleicht beim Schritt A auftauchen könnten, werden sie - wenn überhaupt - erst danach gefragt. Dann sind diese aber schon zum großen Teil dem Verkopfungsprozess zum Opfer gefallen.
• Wir starten beim Negativen. Wir fragen die Leute indirekt: "Wovon wollt ihr weg? Was soll es in Zukunft nicht mehr geben?" Und wir fragen gezielt Gefühle ab: "Was hat euch geärgert, Stress gemacht, Kritik eingetragen ...?" Dadurch bekommen wir schon eine Priorisierung nach Wichtigkeit.
• Das ganze Projekt wird nicht mit einem abstrakten Nutzen verknüpft ("Wir finden immer alles auf Knopfdruck. Super-Workflows!"), sondern mit ganz konkreten Sinnzielen und Bedürfnissen. Das Ziel des Projekts liegt in der Stiftung von Nutzen für die Anwender:innen ist, nicht in der stumpfen Abarbeitung einer Vorgabe „von oben“.
  
• Die Ergebnisse können direkt in User-Storys umformuliert werden und bilden so einen ersten Aufschlag für ein Product Backlog. Damit wird auch den Workshop-Teilnehmer:innen deutlich, dass es nicht um eine abstrakte Bestandsaufnahme ging, sondern um die Planung konkreter Projektumsetzung.
• Dabei wird auch klar, dass der angestrebte Nutzen meistens nicht einfach durch die Software „technisch geliefert“ werden kann, sondern der aktiven Strukturierungsarbeit durch die Betroffenen bedarf. Also Absprachen im Team oder in der Gesamtorganisation. Dem magischen Denken - "die Software liefert mir alles von selbst" - wird ein Stück weit der Boden entzogen. 

Situativ denken

Wir nennen diese Vorgehensweise in Projekten auch den "Flug des Kormorans". Die klassische Projektaufnahme ähnelt einem Flug in großer Höhe, so auf 1.000 m, wo wir versuchen, uns einen Überblick über eine Landschaft zu verschaffen. Das ist das Flussdiagramm.

Abbildung 5: Der Kormoran fliegt auf konstanter Flughöhe über der Welt.

Die situative Analyse von Störungen hingegen stellt ein anderes Bild dar.

 

Abbildung 6: Der Kormoran taucht ins Wasser ein.

Hier verlässt der Kormoran seinen Höhenflug und begibt sich auf Normalnull. Er nimmt Kontakt zur konkreten Wasseroberfläche auf, vielleicht fängt er sogar etwas, und steigt von dort wieder auf. Sein "Fang" ist die situative Analyse in Abbildung 2. Die dortige Beschreibung einer störenden Situation stellt ein dichtes Geflecht von Beziehungen dar - von Beziehungen zwischen Menschen, Artefakten ("Lizenzen", Excel-Listen), Abläufen (Tätigkeiten, Workarounds) und schließlich Wirkungen (Gefühlen, Aufwänden). Wir sind ganz nah an den Dingen - deshalb nennen wir diese Projektphase auch "Erdung".

Von dort können wir wieder aufsteigen und versuchen, das Geflecht zu entwirren und neu zu knüpfen - zu dekonstruieren und zu rekonstruieren. Genchi genbutsu in Aktion.