Warum Workflows so viel versprechen. Und warum sie fast nichts davon erfüllen.

Es gibt zunehmend Unternehmen und öffentliche Einrichtungen, die Dokumentenmanagementsysteme einführen. Die "DMS" sind längst aus ihrem Namen herausgewachsen - die guten Produkte unter ihnen "managen" nicht nur Dokumente, sondern Unternehmensinformationen aller Art. Und vor allem strukturieren sie sie so, dass sie auch die Vielzahl von Prozessen, Kontakten, Vorgängen, Notizen überschaubar halten. Es gab Vorschläge, die Bezeichnungen entsprechend zu ändern - ECM ("Enterprise Content Management") oder EIM ("Enterprise Information Management"). Aber keine hat sich so richtig durchgesetzt. Bleiben wir also bei DMS. Tendenziell ersetzt ein DMS Windows als allgegenwärtige Arbeitsoberfläche (oder besser: Arbeitsuntergrund).

Bei der Einführung von DMS spielen aber falsche Erwartungen der Entscheidungsträger eine große Rolle. Es werden große Hoffnungen gesetzt in Features, über die DMS nicht verfügen. Und auf der anderen Seite werden Dinge, die uns das Leben in unseren Büroprozessen wahnsinnig erleichtern könnten, nicht in den Blick genommen. Ich muss dabei immer an das legendäre Interview der "Digitalisierungsbeauftragten" der letzten Bundesregierung, Dorothee Bär, denken, das sie zu Beginn ihrer Amtszeit gab. Auf die Frage von Marietta Slomka im ZDF, was denn ihre Visionen seien, antwortete sie: "Habe ich die Möglichkeit, auch zum Beispiel mit einem Flugtaxi durch die Gegend zu kommen?" Den Breitbandausbau hingegen erklärte sie für langweiliges Pillepalle. Natürlich hat kein Flugtaxi abgehoben, aber beim Breitbandausbau liegen wir mittlerweile hinter Albanien. Und so ähnlich geht es vielen DMS-Projekten.

Die Versprechen der Lieferanten

In keiner Produktwerbung der DMS-Marktführer darf der Verweis auf die vielfältigen Vorteile von Workflows fehlen. "[Oft ist] die Notwendigkeit eines professionellen Workflow-Management-Systems (WfMS) gegeben. Gerade bei komplexen Abläufen helfen solche Systeme dabei, die komplette Vorgangsbearbeitung zentral zu steuern und zu überwachen... Dazu werden innerhalb der erstellten Automatisierungsketten die einzelnen Komponenten mit den entsprechenden Regeln sowie die jeweiligen Verantwortlichen definiert. Darüber hinaus bietet ein gutes WfMS eine Vielzahl von Monitoring-Werkzeugen, um laufende Status-Updates zu kommunizieren und einen Überblick über den gesamten Prozess zu gewinnen." (aus einem Webauftritt einer verbreiteten Software)

Das zentrale Versprechen heißt: Überblick für die Führungskräfte! Irgendwie funktionieren ja die Prozesse auch in großen Organisationen. Aber kein Bereichsleiter weiß genau wie, wenn die Zahl seiner Untergebenen mehr als dreistellig wird.

Im öffentlichen Bereich kommt hinzu: Einsparungen!  Die Unterbesetzung der Stellen ist chronisch, die Unterfinanzierung auch. Und die Vision, durch Workflows trotz Personalknappheit die Aufgaben noch einigermaßen erledigt zu kriegen, ist extrem verlockend.

Einige Workflows funktionieren

Es gibt Prozesse, die gut durch Workflows abgebildet werden können:

• Posteingangsverteilung
• Urlaubsanträge
• Dienstreiseanträge
• Spesenabrechnungen

Schon problematischer sind erfahrungsgemäß:

• Eingangsrechnungs-Workflow
• Beschaffungsworkflow
• Personaleinstellungen 

Die Workflows, die funktionieren, haben bestimmte Eigenschaften gemeinsam:

• Der Workflow ist an genau 1 Dokument und/oder 1 Record in der Datenbank gebunden:
• ein Datensatz mit Urlaubsangaben eines Mitarbeiters
• eine Spesenabrechnung usw.
• Es sind genaue Arbeitsschritte definiert, die mit dem Dokument oder dem Record verbunden sind:
• Urlaubstage eintragen, 
• prüfen ob Resturlaub vorhanden,
• Zustimmung der Vertretung
• genehmigen durch Vorgesetzten
• Urlaubstage vom Resturlaub abziehen. 
• Die Anzahl der Ja-Nein-Entscheidungen bzw. der Verzweigungen ist überschaubar: 
• nicht genug Resturlaub
• Vertretung lehnt Urlaub ab
• Vorgesetzter lehnt Urlaub ab.
• Jede Nein-Entscheidung an einem dieser Knotenpunkte führt zum Abbruch des Workflows: "Urlaub abgelehnt".

Aber das Versprechen der DMS-Hersteller lautet ja gerade, "komplexe Abläufe ... zentral zu steuern und zu überwachen". Was ist denn damit?

Schauen wir uns das einmal an einem Beispiel an.

Komplexe Prozesse und das Workflow-Problem

Nehmen wir als Beispiel den Prozess "Rechnungseingang". (Das ist kein Prozess im eigentlichen Sinne, sondern nur ein Teil eines Beschaffungsprozesses; aber bleiben wir bei dieser Bezeichnung, wie sie von DMS-Herstellern verwendet wird.) Kein besonders komplexer Prozess, will man meinen. Und trotzdem dauert es oft länger als ein Jahr, bis dieser "Standardworkflow" in einem Unternehmen oder einer Behörde realisiert wird. Warum?

Die Modellierung eines Workflows geschieht meistens nach BPMN, d.h. es wird ein Flussdiagramm erzeugt. Die Hersteller bieten Standardabläufe an, wie zum Beispiel:

Die Abbildung stellt einen Ausriss eines großen Diagramms dar, und zwar nur den Teil "eingegangene Rechnung sachlich richtig abzeichnen". Das sieht doch noch ganz übersichtlich aus, oder? Wo ist der Pferdefuß?

Der Pferdefuß ist links oben. Jetzt soll nämlich dieser Standardworkflow des Herstellers an die konkreten Verhältnisse der Firma angepasst werden. Das kleine Kästchen soll mit Leben gefüllt werden: 

"Wer ist denn der sachliche Feststeller einer Rechnung?", wird im Workshop Frau Müllerschön, die Kollegin aus dem Einkauf, gefragt.

Hier ist die Antwort:

• Normalerweise ist das immer der Antragsteller der Beschaffung, weil nur der kann ja beurteilen, ob die richtige Ware geliefert wurde.
• Wenn es aber eine IT-Beschaffung ist, dann noch Herr Y von der EDV-Abteilung. Denn da übersehen die Endanwender so oft fehlerhafte Details.
• Wenn es eine Beschaffung aus einem Projekt ist und der Wert liegt über 20.000 €, muss auch der Projektleiter die Zuordnung zum Kostenträger bestätigen.
• Wenn der Wert über 250.000 € liegt, muss nach dem Vier-Augen-Prinzip der Bereichsleiter des Antragstellers mitzeichnen.
• Wenn die Ware oder ein Teil von ihr magaziniert wird (z.B. Toner oder andere Kleinprodukte), dann ist sowieso der Leiter des Magazins zuständig.
• Wenn aber die Assistenz des GF die Ware bestellt hat, dann geht es immer direkt an sie, denn sie muss niemals die Zustimmung von jemand anderem einholen.
• Und im Werk Itzehohe machen die das ganz anders, weil die sind ja erst vor vier Jahren zu uns gekommen.  

Diese Antworten gibt Frau Müllerschön natürlich nicht so, wie ich sie hier aufgeschrieben habe. Sondern diese Entscheidungsregeln zur Frage "wer ist zuständig für die sachliche Richtigzeichnung?" äußert sie stückchenweise, verteilt auf mehrere Workshops. Warum kennt sie denn "ihren Prozess" so schlecht? Was ist los mit Frau Müllerschön?

Die Antwort ist einfach. Frau Müllerschön handelt (wie wir alle) situativ. Was sie wann zu tun hat, entscheidet sie situativ und sinn-orientiert. Die Regeln dafür kennt sie nicht bewusst. Sie hat sie im Laufe der Zeit im Unternehmen gelernt, wie wir als Kinder unsere Muttersprache gelernt haben - unbewusst ins limbische System integriert. Natürlich gehorcht eine Sprache einer Grammatik, hat sie Regeln - aber kein Kind kennt die Grammatik seiner Sprache und es bedarf gehöriger Anstrengungen, sie zu lernen. Deshalb ist der Aufwand für BPM-Workshops so hoch (vgl. dazu auch das Buch von Gigerenzer: "Bauchentscheidungen").

Im Ergebnis sind die Regeln zur Bestimmung des "Richtig-Zeichners" kompliziert. Sie differenzieren sich nach:

- zwei Produktarten (IT, Nicht-IT)
- zwei Arten von Beschaffern (Assistenz des GF, andere)
- magazinierte Produkte und andere
- drei Wertgrenzen (unter 20.000, über 250.000, dazwischen).

Und dann gibt es noch Itzehohe mit einer unbekannten Anzahl von Varianten.

Rein rechnerisch ergibt das 2 x 2 x 2 x 3 + x Varianten, also 24 + x. Sagen wir mal 30 Varianten, die jeweils unterschiedliche Workflow-Wege nach sich ziehen.

Das ist nur ein Kästchen im Flussdiagramm, das sich bei feingranularer Darstellung als 30 Varianten entpuppt. An anderen Stellen gibt es ähnliche Fälle, nicht ganz so aufwendig. Insgesamt komme ich im Überschlag auf etwa 85 Varianten für den Gesamtprozess "Rechnungseingang".

Ganz schön was zu customizen!

Das Programmieren 100%-iger Workflows ist komplett unökonomisch

Zwei voneinander unabhängige Verzweigungen multiplizieren die Anzahl der Pfade. Z.B. 2 x 3 = 6

Schon die ersten sechs Varianten machen das Flussdiagramm kompliziert. Wie wäre das erst mit 30?

Aber diesen Aufwand brauchen wir gar nicht zu treiben. Wenn wir empirisch vorgehen, so hilft uns folgende Überlegung: "Angenommen, wir lassen 1.000 Rechnungen durch diese 30 Pfade laufen. Wie verteilen sie sich?" Dabei zeigt sich, dass in der Regel zwei oder drei dieser Pfade von fast allen Rechnungen genommen werden. 

In unserem Beispiel werden von den 30 Pfaden (die Fortsetzung der Abbildung nach unten müsst ihr euch dazu denken) in der Realität einer zu 50% der Fälle und ein weiterer zu 35% tatsächlich durchlaufen. D.h., wir hätten einen Aufwand für Customizing der Größenordnung "2 von 30", mit dem wir 85% aller Fälle abdecken können. Und wird benötigten einen weiteren Aufwand von "28 von 30", um die restlichen 15% auch noch in der Software abzubilden.

Pareto lässt grüßen. Und das agile Vorgehen auch. Aus dem agilen Geist heraus würden wir sagen: Lasst uns erstmal die zwei Hauptpfade programmieren, und dann sehen wir, was sich noch zu automatisieren lohnt.

Eine andere Methode, ein anderer Geist

Eine solche pragmatische agile Herangehensweise bedeutet aber ein großes Umdenken bei den internen Auftraggebern von Software-Einführungsprojekten. Der Anspruch auf umfassende Kontrolle wird aufgegeben. Dieser Anspruch bildet aber das Hauptversprechen der Lieferanten für die Chefetagen ("umfassender Überblick über den gesamten Prozess"). Diejenigen, die das Budget für Software freigeben, müssen sich von den falschen Schalmeienklängen der DMS-Vertriebsabteilungen lösen.

Und auch die Umsetzung ist nicht ganz einfach. Wir verzichten ja nicht ganz auf Workflows, wir wollen nur eine situative Exit-Strategie der Art: "wenn ich als Anwender:in auf einen 1%-Fall stoße, dann bearbeite ich den nicht im Workflow, sondern mache 'per Hand' weiter". - So etwas sehen viele Workflow-Philosophien aber nicht vor. Sie sehen das als nicht perfekt an, Workflows als Schweizer Käse. (Wobei: Schweizer Käse ist perfekt!)

In der Praxis heißt das:

• Wir erstellen keine detaillierten Flussdiagramme, sondern begnügen uns mit grob-granularen Storymaps. Zum Beispiel so ähnlich:

• In einer Storymap werden die Anwender-Aktivitäten in sog. Meilensteine gebündelt (M01 Bedarf anmelden, M02 Vorgang im DMS anlegen usw.). Darunter die Stellen, die in einen Meilenstein involviert sind. Und darunter die einzelnen Aktivitäten.
• Diese Aktivitäten werden in der Regel manuell ausgeführt. Nur innerhalb von Meilensteinen oder einzelnen Aktivitäten werden "kleine Workflows" angeboten. So zum Beispiel bei der Aktivität "Rechnung sachlich richtig zeichnen" Workflows für die 85%-Varianten:
  
  
  
  
  
• Es gibt Workflows, die an verschiedenen Stellen eingesetzt werden können, sog. Ad-hoc-Workflows (die werden von vielen DMS angeboten). D.h. ich kann als Anwender:in einen Workflow "Freigabe" starten, wenn irgendeine Entscheidung von immer den gleichen beiden Vorgesetzten abgesegnet werden muss.

Für diese Vorgehensweise hat sich in den USA die Bezeichnung "Adaptive Case Management" eingebürgert. Wer danach sucht, findet eine reichhaltige, darunter auch deutschsprachige Literatur (und teilweise mit dem Bestreben, ACM mit BPM zu vereinbaren).

Aber dieser Artikel gibt ja auch schon mal eine Idee.