Direkt zum Hauptbereich

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.

Kommentare

Beliebte Posts aus diesem Blog

Kategorien in Outlook - für das Team nutzen

Kennen Sie die Kategorien in Outlook? Nutzen Sie diese? Wenn ja wofür? Wenn ich diese Fragen im Seminar stelle, sehe ich oft hochgezogene Augenbrauen. Kaum jemand weiß, was man eigentlich mit diesen Kategorien machen kann und wofür sie nützlich sind. Dieser Blogartikel stellt sie Ihnen vor.

Outlook-Aufgabenliste: bitte nicht die Aufgaben des ganzen Teams!

Am Tag der Arbeit kommt eine Lösung, nach der ich schon so oft gefragt wurde: Wie schaffe ich es, dass meine Outlook-Aufgabenliste nur meine eigenen Aufgaben anzeigt und nicht auch die E-Mails, die meine Kollegen gekennzeichnet haben oder Aufgaben, die einfach in einem gemeinsamen Postfach stehen?

Das neue Outlook - One Outlook - erster Eindruck

Microsoft hat ein Problem: Outlook ist nicht gleich Outlook. Da ist das gute alte Outlook in der Desktop-Version. Das ist das, womit fast alle von uns im Alltag arbeiten und worüber ich hier schon oft berichtet habe. Outlook auf dem MAC sieht aber anders aus. Outlook auf Mobilgeräten sowieso. Dann gibt's noch Outlook im Web. Kein Wunder, dass Microsoft das alles entwirren, verschlanken und vereinheitlichen möchte. Gelingt es? Hier die interessantesten Funktionen des neuen Outlooks . 

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

E-Mail-Vorlagen gemeinsam nutzen (Outlook)

Mittlerweile wird praktisch alle Routine-Korrespondenz in Outlook erledigt. Was liegt da näher, als ein gutes Set von Vorlagen zu erstellen und diese gemeinsam in Team zu nutzen? Leider hat Microsoft vor diesen – an sich simplen – Wunsch einige Hürden gebaut.

Nie wieder Ärger mit Besprechungsserien in Outlook

Erstellen auch Sie Besprechungsserien in Outlook? Ärgern auch Sie sich manchmal darüber, wenn Sie etwas zu ändern haben? Falls nicht, versenden Sie entweder keine wiederkehrenden Outlook-Besprechungen (Serienterminen). Oder Sie ändern nie etwas daran. Dann ist dieser Artikel nichts für Sie. Lesen Sie aber bitte weiter, falls Sie sich schon immer mal gefragt haben, ob es eine Lösung gibt? 

Und jetzt alle zusammen! Teams - OneNote - Aufgaben - To Do

Ein Meeting jagt das nächste. Sich da nicht zu verzetteln, wird  im Zeitalter virtueller Besprechungen  noch anspruchsvoller. Kein Wunder, dass  im Zusammenhang mit Microsoft 365  zwei Fragen besonders häufig auftauchen: Wie dokumentiert man Besprechungen gut? Was hilft, offene Aufgaben nachzuhalten? Eine gute Lösung: Das in MS Teams integrierte OneNote-Notizbuch als gemeinsame Plattform auch für den Aufgabenüberblick zu nutzen.

Das Ubongo Flow Game

Spiele bieten eine gute Gelegenheit, zeitliche Erfahrungen zu verdichten und gemeinsam zu lernen. Karl Scotland und Sallyann Freudenberg haben im Mai 2014 das Lego Flow Game veröffentlicht. Wir haben die Spielidee übernommen, aber das Spielmaterial gewechselt. Statt Legosteinen benutzen wir Material aus Grzegorz Rejchtmans Ubongo-Spiel. Hier präsentieren wir die Anleitung für das Ubongo Flow Game.

"Denn sie wissen nicht was sie tun ...! Freigeben und teilen in OneDrive und SharePoint und per E-Mail

Neuerdings können Sie bei Ihren E-Mails entscheiden, ob Sie den Anhang als Datei (Kopie) anhängen wollen oder einen Link senden. Doch was kann dieser Link? Wie sicher ist er? Wer kann was damit tun? Lesen Sie hier was sinnvoll ist und was weniger.

Rebellieren für den Wandel: die 8 Regeln des totalen Stillstandes von Prof. Dr. Peter Kruse

In einem legendärem Vortrag skizzierte Peter Kruse 8 Regeln des totalen Stillstands. Ihm zufolge wurden die Regeln entwickelt, um Managern und Führungskräften dabei zu helfen, Bereiche mit potenziellem Widerstand gegen Veränderungen zu erkennen und Menschen auf strukturierte Weise durch den Veränderungsprozess zu führen.