Aus der agilen Methodenkiste: Die Wirkungsanalyse macht aus Anwendern der E-Akte Projektbeteiligte

Wenn eine Verwaltung ein DMS („E-Akte“) oder auch eine andere große Software („Campus-Management“) 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, noch mehr aber für die anschließende Implementierungsphase. Die klassischen Wasserfall-Methoden haben dafür kein richtiges Konzept. Wie packen wir in agilen Projekten diese Aufgabe an?

In der Ausschreibungs- und Beschaffungsphase der Software steht die Verwaltung vor der Aufgabe, einen Anforderungskatalog, ein Lastenheft oder etwas Ähnliches zu entwickeln. Also irgendeine Vorstellung, welche Arbeitsweisen die neue Software unterstützen soll und was sie dazu leisten muss. Und diese Vorstellung soll die Organisation während der folgenden, mehrjährigen Projektdauer als Leitstern dienen.

In der Implementierungsphase wird die Software Bereich für Bereich eingeführt. Und wieder geht es darum, die Beschäftigten des Sachgebiets in das Customizing der Software einzubinden.

In beiden Fällen bieten sich zwei Wege an, um die Betroffenen zu beteiligen:

Brainstorming und die Ergebnisse

Der erste Weg ist klassisch und heißt „Brainstorming“. Wir veranstalten mehrere Workshops für verschiedene Anwendergruppen und stellen immer die gleiche Frage: „Was wünscht ihr euch?“

Alle Teilnehmer:innen verstehen diese Frage. Und an Antworten mangelt es nie:

• klarer Ort, wo sich Dokumente befinden
• leichter Zugang zu allen Projekten und ihren Dokumenten
• durchgängiges Berechtigungskonzept (auch für externe Beteiligte)
• direkter Zugang, auch von unterwegs
• leichte und intuitive Suche nach Schlüsselwörtern, auch als Volltextrecherche
• klar strukturierte Workflows für alle Prozesse
• leichte Bedienbarkeit
• gut strukturierte Ablage
• revisionssichere Speicherung.

Die Liste ist übrigens nicht erfunden, sondern ist ein Ausschnitt des Ergebnisses eines solchen Workshops vom März 2021.

Eine solche Liste hat durchaus ihre Berechtigung. Sie liefert einen ersten Scope, ein erstes Verständnis der Beteiligten, auf was das Projekt „hinausläuft“.

Das Problem ist nur: die Antworten schaffen noch keine wirklich tiefes gemeinsames „Verstehen“. Insbesondere sind sie nicht operabel in Richtung auf einen Softwarelieferanten oder Softwaretechniker, der das neue Tool auf unsere Bedarfe zurichten soll.

Wenn ich in den Anforderungskatalog einer Software schreiben würde „leichte Bedienbarkeit“ – was soll ein Anbieter damit anfangen? Wie kann ich entscheiden, ob eine Software die Anforderungen erfüllt oder nicht? Was ich als „leicht“ empfinde, findet mein Kollege schon als super umständlich. Was eine junge Kollegin mit fünf superschnellen Klicks im Handumdrehen erledigt, kann ich als nicht Digital Native kaum nachvollziehen, geschweige mir merken.

Oder „gut strukturierte Ablage“. Ich bin versucht, den Teilnehmer:innen zuzurufen: „Ja,dann strukturiert sie doch gut, eure Ablage! Glaubt ihr denn, eine arme Software kann für euch etwas erledigen, was ihr selbst seit Jahren nicht hinbekommt?“

Natürlich ist es eine berechtigte Anforderung, dass ein Dokumentenmanagementsystem eine „gute“ Ablage auch „gut“ unterstützt. Aber wieder die Frage: Was heißt das konkret? Das heißt: wir brauchen so eine Liste wie die obige, weil sie doch eine Art von gemeinsamem Verständnis bei den Projektbeteiligten schafft. Aber sie reicht nicht aus. Sie muss durch etwas Anderes ergänzt werden.

Wirkungsanalyse

Dazu verwende ich eine Vorlage namens „Wirkungsanalyse“. Im Workshop stelle ich die Aufgabe:

„Das Ziel dieser Methode ist es, eine ganz genaue Vorstellung von den Anforderungen der künftigen DMS-Anwender zu erhalten. Nehmen Sie sich einen Flipchart-Bogen und vier Post-Its mit unterschiedlichen Farben. Denken Sie an einen konkreten Fall in den circa letzten beiden Wochen, bei dem Sie gestört, unterbrochen, gestresst wurden oder über den Sie sich geärgert haben – in Bezug auf das Suchen nach Dokumenten oder Informationen, über den Status eines Vorgangs oder oder – alles, was im weitesten Sinne mit Teilen von Dokumenten und Informationen im Team zu tun hat.

Beschreiben Sie diesen Vorfall auf den vier PostIts entlang der Fragen auf dem Leerformular.“

Dabei sieht das Leerformular folgendermaßen aus:

Die Ergebnisse dieser Abfrage sind meistens schon sehr konkret. Ich bringe mal ein Beispiel aus einem Projekt in einer Stadtverwaltung aus 2020 und dort konkret mit dem Hochbauamt:

Die Beschreibung der Störung und ihrer Wirkung dient als Grundlage zur Diskussion im Team:

• Als Erstes entsteht beim Betroffenen im Verlauf des Aufschreibens eine gefühlsmäßige Verbindung zum E-Akten-Projekt. Er bekommt einen Ein-Druck, was das Projekt mit ihm persönlich, alltäglich zu tun hat. Ich nenne das die „Projekt-Erdung“.
• Das Projekt wird aus dem abstrakten Raum der obigen Wunschliste, die vor allem kopfgeboren ist, in einen realen Kontext hinabgedrückt.
• Durch die Bewertung in Kleidergrößen wird dieses Gefühl um eine Komponente der Schwere ergänzt.
• Das bringt umgekehrt Energie ins Projekt: Ich als künftiger Anwender spüre auf einmal sinnlich, wie viel verschwendete Arbeit ich dauernd leiste und in welchem Maße ein DMS mich davon befreien kann. Das ist bei Präsenz-Workshops auch im Raum spürbar – die Luft wird quasi elektrisiert.

Darüber bekommen wir aber auch den Kopf wieder stärker beteiligt. „Welche Suchbegriffe hatten Sie denn im Kopf, um trotz Abwesenheit der Kollegin in deren Zuständigkeitsbereich den Vorgang und darin den Kosten-/Sachstand zu finden?“

So können wir die Wünsche ans DMS aus ihrer magischen Ecke („alles auf Knopfdruck – ohne dass ich etwas tun oder gar nachdenken muss!“) herauszuholen und mit der praktischen Frage: „Wie muss ich mir das neue Tool auf meine Zwecke hin zurichten – wie müssen wir im Team uns z.B. auf Verschlagwortungsregeln bei Bauvorhaben einigen, damit wir alles finden können?“ auf den Boden der Realität zurückholen. Von einem Wundermittel wird das DMS zu einem Instrument in meinen Händen und in denen meines Teams, das viel können wird, aber das ich selbst strukturieren kann und muss.

Ein zweites Beispiel sieht so aus:

Hier taucht gegenüber dem vorigen Beispiel ein neuer Aspekt auf. Wenn man die Geschichte aufmerksam liest, wird klar: hier geht es zwar auch ums „Suchen“, aber um eine Art von Suchen, die von DMS-Lieferanten meistens gar nicht thematisiert wird. Software-Lieferanten (und noch penetranter: ihre Vertriebler) gehen immer vom „Suchen nach Dokumenten“ aus und preisen die Volltextrecherche und ähnliche Verfahren.

Hier aber ist das Anliegen der Kollegin ein ganz anderes: sie sucht nach einem -„Verfahrensstand“. Also offenbar geht es um ein Bauprojekt, das noch in der Planungsphase ist. Und sie interessiert sich überhaupt nicht für ein Dokument – das wäre höchstens eine Hilfskrücke -, sondern sie möchte einen Status rausfinden. Also eine Information der Art „Im Projekt wird gerade die Beschlussvorlage für den Stadtrat erarbeitet.“

Daran entspinnt sich eine rege Diskussion. Was verstehen wir eigentlich genau unter einem „Status“? Welche anderen Status könnte ein Bauprojekt in der Genehmigungsphase annehmen? Wie könnte ich die in einem DMS abbilden, ohne viel zusätzlichen Aufwand? Usw. – Das heißt, es ergeben sich auf einmal Anforderungen an ein DMS, das vielleicht von einigen Produkten erfüllt wird und von anderen nicht. (Weshalb wir Wirkungsanalysen mit ausgewählten Pilotabteilungen schon in der Beschaffungsphase eines E-Akten-Produkts empfehlen.)

Von der Wirkungsanalyse zu Anforderungen

Die Ergebnisse dieser Diskussionen sollen ins Product Backlog des Projekts einfließen. Dazu müssen wir die beschriebenen Störungen Prozessen zuordnen und Anforderungen formulieren – möglichst in Form von User-Storys.
Dazu haben wir wieder ein „Leerformular“, das diese Aufgabe strukturiert:

Im Ergebnis wurden auf die erste Wirkungsanalyse hin sogar zwei User-Storys formuliert:

Und in Bezug auf die zweite Wirkungsanalyse ergab sich folgende Anforderung:

Diese User-Storys schließen den Workshop. Wenn der Workshop in der Beschaffungsphase der Software stattfand, fließen sie ins Lastenheft ein. Wenn sie in der Implementierungsphase erarbeitet wurden, strukturieren sie den Roll-out der Software im jeweiligen Sachgebiet.

Als Resultat des ganzen Workshops ist allen Beteiligten klar:

• Dass der Sinn des E-Akten-Projekts die Stiftung von Nutzen für die Anwender:innen ist, nicht die stumpfe Abarbeitung einer Vorgabe „von oben“.
• Dass dieser Nutzen meistens nicht einfach durch die Software „technisch geliefert“ werden kann, sondern der aktiven Strukturierungsarbeit durch die Betroffenen bedarf.

Unterschied zur „Prozessoptimierung“

Wenn überhaupt Mühe auf das Customizing des DMS für ein bestimmtes Sachgebiet verwendet wird, dann geschieht das sehr oft in Form von Prozessmodellierungen. Ein Mitarbeiter der Orga-Abteilung der jeweiligen Verwaltung erscheint im Sachgebiet und führt einen Prozessaufnahme-Workshop durch. Im Ergebnis erscheinen die einzelnen Aktivitäten eines Anwenders als „Kästchen“. Die Modellierung nach BPMN verfolgt nur die Sprünge von einer Aktivität zur nächsten – aber das „Innere“ einer Aktivität wird oft nicht analysiert. Das „Wie“ ihrer Ausführung bleibt dann eine Black Box.

Zum Beispiel die Tätigkeiten, die der Sachbearbeiter in der zweiten Wirkungsanalyse ausführt:

• die verschiedenen Unterlagen an unterschiedlichen Orten (Akte, Dateiarchiv, usw.) einzeln sichten und auswerten
• E-Mail an andere

würden bei einer Prozessanalyse in der Regel unter dem Radar bleiben. Und damit der eigentliche „Schmerz“, den der SB mit dem Prozess hat und die Größe diese Schmerzes (Wie häufig tritt die Störung auf? Welchen Aufwand bedeutet sie im Durchschnitt?).

Wir haben schon einmal an anderer Stelle gezeigt, wie die traditionelle Prozessanalyse dazu neigt, bestehende Machtverhältnisse zu zementieren (https://agile-verwaltung.org/2018/12/24/traditionelle-prozessoptimierung-und-agile-prozessoptimierung-und-die-e-akte-und-es-ist-weihnachten/). Die Wirkungsanalyse bietet auch hier einen tieferen Eindruck in die Arbeitswirklichkeit.

Störungen der Wirkungsanalyse

Der Nutzen des ganzen Prozederes besteht in seiner Konkretion – das wollte ich mit diesem Beitrag deutlich machen. Diese Konkretion wird aber nicht immer umstandslos von allen Teilnehmer:innen eines Workshops geliefert:

• Manche versagen sich ganz grundsätzlich, solche Störungen zu notieren. Störungen sind für sie gefühlsmäßig persönliche Fehler oder gar Versagen. Um solche Teilnehmer nicht in eine Widerstandshaltung zum ganzen Workshop zu bringen, stelle ich immer die Freiwilligkeit der Teilnahme an der Wirkungsanalyse heraus.
• Andere tun sich sehr 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.“ – Vor allem Wissenschaftler und hier wieder Naturwissenschaftler sind immer am Klassifizieren – sie versuchen ständig, Muster und Regeln in der Welt zu erkennen und empfinden die Beschäftigung mit Einzelfällen als Verschwendung. Da hilft gut die 5-W-Methode Toyotas, um von einer Verallgemeinerung zu den Einzelfällen zu gelangen, die dahinter liegen.