Direkt zum Hauptbereich

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. 









 

Kommentare

Beliebte Posts aus diesem Blog

Und jetzt alle zusammen! Teams - OneNote - Aufgaben - To Do

Ein Meeting jagt das nächste. Sich da nicht zu verzetteln, wird  im Zeitalter virtueller Besprechungen  noch anspruchsvoller. Kein Wunder, dass  im Zusammenhang mit Microsoft 365  zwei Fragen besonders häufig auftauchen: Wie dokumentiert man Besprechungen gut? Was hilft, offene Aufgaben nachzuhalten? Eine gute Lösung: Das in MS Teams integrierte OneNote-Notizbuch als gemeinsame Plattform auch für den Aufgabenüberblick zu nutzen.

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.

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.

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.

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.

Optimieren wir uns zu Tode?

Als jemand, der mehr als fünfzehn Jahre in der Welt des IT-Service-Management-Prozessmanagements verbracht hat, musste ich das Buch von Guther Dueck aus dem Jahr 2020 Heute schon einen Prozess optimiert? Das Management frisst seine Mitarbeiter lesen/1/. Typisch für ihn bietet Dueck uns einen provokanten, teils vernichtenden, jedoch humorvoll geschriebener Weckruf. Er behauptet, dass das moderne Management von “Pacesetters” und “Controllers” dominiert wird. Sie sind so sehr auf Optimierung und Profit fokussiert, dass sie den Willen zu Innovation und Unternehmertum abtöten. Jedoch ohne mehr Kreativität und Tatkraft werden wir die Herausforderungen der Digitalisierung, des Klimawandels etc. nicht bewältigen. Ein agiles Mindset kann helfen.

Projekt-Kick Off – Wie Du einen Auftakt gestaltest, der alle Kräfte freisetzt!

Ein typisches Szenario:  Zum Auftakt wird das neue Projekt vom Verantwortlichen vorgestellt. Die vorbereitete PowerPoint-Präsentation zeigt in bunten Bildern, welche Traumschlösser vom Team umgesetzt werden sollen. Doch statt der erhofften Aufbruchsstimmung macht sich Widerstand breit. Diskussionen kommen auf. Das Kickoff-Meeting wird zur Bühne der Lauten. Miese Stimmung macht sich breit. Die Lauten werden lauter, die Stillen werden leiser.  Kommt Dir das bekannt vor? Häufig werde ich gefragt: "Maria - wie sieht das in der Praxis aus? Wie gestalte ich als Moderator ein strukturiertes Meeting?". In diesem Artikel stelle ich Dir EINEN alternativen Ablauf einer Kickoff-Veranstaltung in fünf Schritten vor. Ein Gestaltungsvorschlag, der Impulse und Mut zum Experimentieren neuer Formate bieten soll.  Was es ermöglicht: Förderung des Projekterfolg Frühes gemeinsames Verständnis des Projekts Missverständnissen wird vorgebeugt Es werden hilfreich Hinweise sichtbar, WIE d

Agiles Mindset – Gibt es das überhaupt? Eine wissenschaftliche Perspektive

Es ist in aller Munde: Das Agile Mindset. Es wird als wichtiger Erfolgsfaktor und gleichzeitig riesige Hürde und Herausforderung in agilen Transformationsvorhaben beschrieben. Der ein und andere hat verbunden mit einem gescheiterten agilen Vorhaben vermutlich schon mal gehört „Die hatten einfach nicht das richtige Mindset“. Doch was ist dieses agile Mindset? Gibt es das überhaupt?