Mythos Workflow: Warum rein technische Herangehensweisen so viel Unbefriedigendes produzieren

Die Abteilung Gebäudemanagement im Landratsamt Oberbergen soll in den Genuss der E-Akte kommen. Herr Köhler, der Abteilungsleiter, sitzt uns gegenüber und schaut uns an. Wir, das ist Henry Haasen, Projektleiter „Digitalisierung“. Und das bin ich als externer Unterstützer. Es ist unsere erste Besprechung mit Herrn Köhler, um den Startworkshop für das Gebäudemanagement zusammen vorzubereiten. Und Herr Köhler schaut abwartend, aber durchaus interessiert. Schon mal gut.

Aber dann sein erster Satz: „Aber Sie kommen mir jetzt nicht mit Workflows, oder?“ Wie bitte?? Ein Kerzlein geht in mir auf und wärmt meine Seele. Eine Führungskraft, wie nicht auf Workflows abfährt? Great! Aber wie kommt er darauf? Ich kann es mir nicht verkneifen und frage: „Herr Köhler, wie kommen Sie darauf? Was haben Sie gegen Workflows?“ Und er: „Herr Steinbrecher, was ich gegen Workflows habe? Kennen Sie denn nicht den ÄAAV?“

Ein missglückter, aber nicht untypischer Workflow

Er erklärt es uns gern. Der ÄAAV ist der „Änderungsantrag Arbeitsverhältnis“. Immer, wenn ein Mitarbeiter auf Teilzeit gehen will oder seine Stunden aufstocken oder wenn Herr Köhler der Auffassung hat, er sollte höhergruppiert werden oder neue Aufgaben zugewiesen bekommen – oder oder oder: Dann wird ein ÄAAV bei der Personalabteilung fällig. ÄAAV ist das oberbergische Schreckgespenst aller Vorgesetzten.

Dafür gibt es nämlich seit acht Jahren einen Workflow, der auch schon im DMS programmiert wurde (das DMS ist seit langem beschafft, bevor unser E-Akten-Projekt startete). Dieser Workflow läuft so:

• Der Vorgesetzte, z.B. Herr Köhler, einigt sich mit einem Mitarbeiter auf irgendeine Maßnahme.
• Er muss diese Maßnahme dann mit der Personalabteilung abstimmen. Dazu startet er einen ÄAAV. Der besteht aus einem Formular, in den Herr Köhler verschiedene Angaben einträgt (Personalnummer, Art der Änderung, Datum des Änderungsbeginns, evtl. Ende der Änderung, Begründung usw.). Dann klickt er auf „Senden“.
• Das Formular wird an die Personalabteilung (PA) versendet. Diese bildet sich eine Meinung. Stimmt sie zu, wandert das Formular an den Mitarbeiter. Der muss es ausdrucken, unterschreiben, wieder einscannen und an die PA zurückschicken.
• Die PA formuliert einen Beschluss, ändert die Daten des Mitarbeiters in SAP (Gehaltsdaten usw.) und schickt den Beschluss an Herrn Köhler und an den Mitarbeiter.

Toll, oder?

Jetzt, liebe Leser, lest mal einen Moment nicht weiter. Bildet euch einmal selbst eine Meinung – was fällt euch bei diesem Workflow auf?

Euch ist nichts aufgefallen? Nicht schlimm. Mir nämlich auch nicht. Aber Herr Köhler hat uns (Herrn Haasen und mich) aufgeklärt.

„Wenn ich den Workflow abgeschickt habe, ist er im Nirwana verschwunden. Ich habe keine Möglichkeit, mir z.B. alle von mir in letzter Zeit versendeten ÄAAV anzusehen. Ich habe keine Möglichkeit, den Workflow zu „tracken“. Und natürlich der Mitarbeiter schon gar nicht. Er kann auch nicht schauen, wie es mit seinem Anliegen steht. Für ihn bedeutet ein Antrag auf Elternzeit ja auch einen Haufen an Maßnahmen, die er dann treffen muss. Also kommt er zu mir. Aber ich weiß auch nicht Bescheid, nicht einmal, wer in der Personalabteilung für die ÄAAV zuständig ist. Wenn soll ich dort fragen? Also telefoniere ich herum und nerve die Kollegen dort.“

Ich stoppe mal hier mit der Beschreibung des Abteilungsleiters Köhler. Die Frage, die er uns stellte – dem Projektleiter und mir – war: „Wie kommt es überhaupt, dass Profis wie von unserem DMS-Lieferanten so einen Schrott programmieren? Und können Sie mir garantieren, dass so etwas beim Projekt in meiner Abteilung nicht vorkommt?“

Technisches Denken, technische Analyse

Das ist genau die Frage: Wie kommt es zu so ungenügenden Ergebnissen? Ich kann darüber nur Vermutungen anstellen.

Der Anwendungsentwickler sieht einen „Umlauf“. Vorher gab es einen Papiervordruck, den Herr Köhler an die Personalabteilung schickte. Der Programmierer programmiert den gleichen Ablauf digital. Was er dabei nicht sieht: Herr Köhler macht sich eine Kopie des Papiers, bevor er es weiterschickt. Er legt sich die Kopie in seine Wiedervorlagemappe auf dem Schreibtisch, damit der Vorgang für ihn nicht verlorengeht. Das Gleiche beim betroffenen Mitarbeiter.

Diese Erinnerungsfunktion programmiert der Programmierer nicht. Er programmiert nicht den Prozess, sondern nur das, war er davon sieht. Also ist der programmierte Workflow ein Stück schlechter als der Papierprozess.

Und er versteht den Sinn des Umlaufes nicht. Daraus ist ihm kein Vorwurf zu machen. Denn kaum jemand von uns kennt die Geschichte unserer Prozesse – wie sie geworden sind, was sie sind. Der Umlauf war von Beginn an – Beginn: Anfang des 19. Jahrhunderts – eine Notlösung. Vor dem 19. Jahrhundert wurden Entscheidungen immer im „Kollegium“ eines Amtes getroffen. Alle Entscheidungsträger saßen um einen Tisch herum. Als die Aufgaben zahlreicher wurden, wurde das Kollegium (das „crossfunktionale Team“) aufgelöst. Die Vorbereitung von Entscheidungen wurde nach unten, auf die Sachbearbeiterebene, delegiert – die Entscheidungen aber oben in der Hierarchie belassen. So wurde der „Umlauf“ geboren. /Anmerkung 1/ Ein Umlauf ist also nicht einfach ein Dokument, das von einer Stelle an eine andere geschoben wird. Sondern er stellt einen Arbeitszusammenhang zwischen Personen dar.

Die Chance der Digitalisierung: zurück zur Teamarbeit, zur gemeinsamen Suche nach Lösungen

Jetzt könnte man natürlich den misslungenen Workflow durch einen richtig durchdachten ersetzen. Aber denken wir da nicht auch zu kurz? Was spricht dagegen, diese isolierten Arbeitsschritte der einzelnen Personen wieder zu einer Teamarbeit zusammen zu binden? Also miteinander zu kommunizieren, statt sich Workflowschritte an den Kopf zu werfen.

Wenn nämlich Herr Köhler für und mit einem Mitarbeiter eine Personalmaßnahme überlegt, hat er in mindestens 50% der Fälle nicht nur diesen Mitarbeiter im Blick. Es geht meistens um das Team als Ganzes. Eine Änderung der Wochenarbeitszeit eines Mitarbeiters hat Auswirkungen auf die Arbeitsbelastung der anderen Kolleg:innen. Eine Höhergruppierung einer Mitarbeiterin ändert vielleicht das ganze Teamgefühl. Ist es da nicht oft sinnvoll, sich mit einem erfahrenen Personalentwickler aus der Orgaabteilung zu beraten – statt nur einfach Maßnahmen wie Papierflieger an die Personalabteilung zu schicken? Natürlich kann der Workflow trotzdem für unproblematische Einzelmaßnahmen Sinn machen. Aber den Grundsatz „Definiere nur Workflows für Prozesse, in denen man nicht nachdenken muss!“ sollte man dennoch beachten.

Ich fand deshalb den Bericht über die digitale Transformation der Stadt Kiel so bemerkenswert. Kiel hat mit der flächendeckenden Einführung von Conceptboard begonnen – also einem Tool der Teamzusammenarbeit. Solche Vorgehensweisen finde ich sehr ermutigend.

Fiel mir gerade in die Hände: Auf netzpolitik.org hat Bianca Kastl einen interessanten Beitrag gepostet, der gut zum „Mythos Workflow“ passt: https://netzpolitik.org/2023/degitalisierung-effizienz-ist-ein-konservatives-wesen/

Anmerkungen

/1/ Dazu instruktiv: Angelika Menne-Haritz: Akten, Vorgänge und elektronische Bürosysteme. Mit Handreichungen für die Beratung von Behörden. Veröffentlichungen der Archivschule Marburg Nr. 25, 1996. – Auch interessant zur Entwicklung der Büroarbeit im öffentlichen Sektor das Buch von Pierre Bourdieu: Über den Staat.