Genchi Genbutsu oder Der Flug des Kormorans

Im Folgenden möchte ich eine Methode vorstellen, wie wir in Projekten Anforderungen
zusammen mit Anwender:innen erarbeiten können. Die Methode ist anwendbar für alle
Arten von Projekten der Software-Einführung oder auch anderer Projekte der
Organisationsentwicklung. Die Beispiele entstammen Projekten zur Einführung der E-Akte.

Wir wollen eine neue Abteilung, einen Fachbereich oder ein Sachgebiet in das E-Akten-Projekt einbeziehen. Wir machen einen Workshop zur Beteiligung der Anwender:innen. Wir fragen sie, was sie denn so brauchen könnten – zum Beispiel in
Form eines Brainstormings, eventuell im Speedboat-Format. Wir erhalten viele
Vorschläge – die Anwender:innen sind zum großen Teil engagiert dabei. Aber die
Formulierungen sind allgemein wie zum Beispiel „Nie mehr Dokumente suchen, immer
gleich finden“. Und auf dieser Flughöhe bewegen wir uns weiter.

Irgendwie ist nicht genügend Energie dabei. Und wir kommen in eine
Bewegungsrichtung, bei der die Projektleitung und das Kernteam (OE-Berater,
Software-Administratoren, IT) in die Rolle der magischen Zauberer kommen und die
Anwender:innen auf der Ebene von Kindern belassen werden, die Wunschzettel für
Weihnachten verfassen und dann möglichst viel Freude geschenkt bekommen wollen.
Aber sie werden so nicht aktive Projektbeteiligte auf Augenhöhe.

Deshalb haben wir eine andere Methode entwickelt. Wir nennen sie den „Flug des
Kormorans“. (Es gibt im traditionellen Projektmanagement eine Methode, die sich „Flug
des Haubentauchers“ nennt. Sie ist aber nicht das gleiche. Deshalb haben wir hier den
Kormoran als Namensgeber verpflichtet. Er hat sich gefreut. Einige Haubentaucher
haben protestiert und gesagt, Kormorane flögen gar nicht so elegant, sondern ziemlich
erbärmlich.)

Bei dieser Methode verlassen wir im Workshop unsere Flughöhe und begeben uns auf
0 m. Wir suchen Kontakt zur sinnlich erfahrbaren Wirklichkeit. Und das funktioniert
folgendermaßen: Wir bitten die Worksop-Teilnehmer:innen, in Einzel-Reflexion jeweils
an zwei Störungen zu denken, die sie in der letzten Zeit betroffen haben. Dazu sollen
sie ein „Formular“ wie das in Abbildung 3 ausfüllen.

Die Methode beruht auf dem Prinzip Genchi Genbutsu des Toyota Produktivsystems: „Genchi Genbutsu (Deutsch: Geh und sieh es dir selbst an): Die beste Methode ist, sich den Ort oder den Prozess anzusehen, an dem das Problem besteht, um es schneller und effizienter zu lösen. Um Probleme zu erfassen, müssen die Fakten bestätigt und die Ursachen analysiert werden.

Das Toyota-Produktionssystem erfordert ein hohes Maß an Managementpräsenz in der Fabrik, so dass ein Problem, das in diesem Bereich besteht, zunächst einmal richtig verstanden werden sollte, bevor es gelöst wird. Es geht bei diesem Satz
weniger um den physischen Akt des Besuchs eines Standorts, sondern vielmehr um ein persönliches Verständnis der vollen Auswirkungen jeder Handlung innerhalb einer Umgebung als Ganzes.“ (nach: Wikipedia)

Wann ist ein Change ein Change?

Wir können dann davon sprechen, dass ein Change Wirkung gezeigt hat, wenn jede:r vom Projekt berührte Mitarbeiter:in auf der ikroebene des täglichen Arbeitens jede Stunde merkt: „Da hat sich etwas geändert.“

Das ist kein rein fernöstlicher Ansatz. Wir können genausogut den Satz aus der klassischen deutschen Philosophie anführen: „Nur das Konkrete ist das Wahre, das Abstrakte ist nicht das Wahre.“ (Hegel, Vorlesungen über Geschichte der Philosophie)

Damit man aber konkrete Changes vorbereitet und die Anwender:innen aktiv in sie einbezieht, sind für uns zwei Grundüberlegungen ausschlaggebend:

1. Immer erst vom Negativen ausgehen. „Wovon will ich weg? Womit soll Schluss sein?“
2. Situativ-exemplarisch. An konkreten Beispielen entlang-denken. Nicht „Ich suche immer nach Dokumenten und finde sie nicht.“ Sondern: „Vorgestern habe ich diesen Brief an einen Kunden vom letzten Jahr nicht gefunden. Den hätte ich so gut abkupfern können und mir zwei Stunden Arbeit gespart. Wie hat mich das geärgert!“

Beispiel

Das ist jetzt ein konkretes Beispiel aus einem Workshop vergangene Woche (Februar 2022). Die Formulierung der Störung ist ganz detailliert. Sie ist noch nicht als Anforderung an die Software gefasst, sondern stellt erstmal den Ärger dar. Dieser
Ärger ist wichtig – er bringt Energie ins Projekt.

Gleichzeitig wird allen Beteiligten deutlich: es geht nicht um Changes, die allein durch „die Digitalisierung“ bewirkt werden. Offenbar ist da auch eine Liste nicht richtig gepflegt worden. Also ist auch ein neuer Teamstil Voraussetzung für Verbesserungen – das Team wird sich absprechen müssen, wer wann welche Angaben wo aktualisiert.

Die Anwender:innen werden in die Pflicht genommen, und die neue Software erscheint als das, was sie sein soll: Ein Werkzeug zur Unterstützung intelligenter Prozesse, aber nicht als Ersatz anstelle intelligenter Prozesse.

(vorgestellt auf dem Literaturcafé am 18.02.2022)