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

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?

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.

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.

Beispiel für eine Partyplanung mit Scrum

Wer sich neu mit Scrum beschäftigt, ist vielleicht überwältigt von den ganzen Fachbegriffen. Dann sieht man vielleicht gar nicht, wie einfach die einzelnen Elemente von Scrum sind. Deshalb hier ein einfaches Beispiel für die Vorbereitung einer Party mit Hilfe von Scrum.

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.

Tooling #5: Die gute alte Systemtheorie

Gelegentlich fragen mich Menschen nach den wichtigsten Tools und Herangehensweisen für meine Arbeit. Einige davon habe ich hier im Blog bereits vorgestellt (und zwar  hier ). Heute möchte ich über ein weiteres, vielleicht sogar DAS entscheidende Basiswerkzeug sprechen: Die gute alte Systemtheorie.

Protokolle in OneNote - neue Ideen für's neue Jahr

Protokolliert Ihr Team seine Besprechungen in OneNote? Das geht einfach, schnell ist teamfähig und hat eine exzellente Suchfunktion. Die beliebte Fragen "Wann haben wir eigentlich beschlossen, dass..." ist so schnell beantwortet. Darum wird OneNote an dieser Stelle immer beliebter. In meinen Seminaren dazu sind gute Ideen entstanden, die ich hier weitergeben will.

Ich bin ganz oben (mit Kanban und Outlook)

Mit einem Kommentar zu einem lesenswerten Artikel von Thomas Mauch /1/ habe ich es an die Spitze der Trefferliste bei Google geschafft. Suchen Sie mal nach „Kanban Outlook“. Kanban ist eine alte Idee, aber immer noch der Renner unter den Produktivitätswerkzeugen. (There is an English version of this post.)

Scrum und Kennzahlen (KPIs, Metriken)

In regelmäßigen Abständen hören wir die Frage, welche Kennzahlen (neudeutsch KPIs) bei Scrum sinnvoll sind. Zeit für einen längeren Beitrag, auf wichtige Ressourcen zu verweisen. Der Scrum-Guide selbst gibt dazu keine erschöpfende Auskunft. Und das hat seine Gründe.

OneNote Prinzipien: Zugriffsrechte und Speicherorte

OneNote ist praktisch – ohne jeden Zweifel. OneNote ist auch einfach und intuitiv zu bedienen… Ja… so am Anfang. Doch früher oder später kommen Fragen wie: - wer genau hat eigentlich wie Zugriff auf die Daten? Wie ist das mit Synchronisation zwischen Büro-PC und Smartphone oder iPad? Wie funktioniert OneNote auf dem SharePoint? Auf diese Fragen findet sich die Antwort nicht ganz so leicht. Ich versuche hier die nicht ganz so offensichtlichen Zusammenhänge deutlich zu machen und "gern genommene" Fallen zeigen.