Prozessautomatisierung: Erst das Schema, dann die Automatik

Das Projekt im Überblick

„Anfragen bearbeiten“ ist kein Ziel; „ein qualifizierter Interessent liegt mit zuständigem Ansprechpartner im System, spätestens 15 Minuten nach Eingang“ ist eines — daran kann man scheitern und das kann man messen. Wir haben daraus eine Regel für jedes Projekt gemacht: Der Prozess entsteht zuerst als Schema, und zwar in der Sprache des Inhabers. Jeder Knoten heißt nach seinem Ergebnis, die Technik steht dahinter und nicht auf der Zeichnung; wird ein Ablauf größer als rund ein Dutzend Knoten, wird er geteilt, weil ein Schema, das niemand mehr liest, keine Beschreibung ist. Vor dem Bauen gehört ein unbequemer Schritt dazu: Wir nehmen an, der Prozess sei nach einem Monat gescheitert, und sammeln die drei bis fünf Gründe dafür. Jeder Grund bekommt eine Kennzahl, eine Schwelle und eine Frist — ohne Kennzahl gilt die Bedingung als nicht formuliert — und dazu ein Abbruchkriterium: Was muss eintreten, damit wir den Ablauf wieder abschalten, und wer entscheidet das. Dann läuft der Prozess im Schattenlauf. Die Maschine verfolgt bei jedem echten Ereignis den Weg durch das Schema, schreibt mit, welchen Pfad sie genommen hätte, und tut nichts. Das vergleichen wir Tage lang mit dem, was die Menschen tatsächlich gemacht haben; erst dann wird eingeschaltet. Nach außen wirken darf ein Ablauf ohnehin nur über eine kurze Freigabeliste — Nachrichten an Kunden gehen beispielsweise ausschließlich über den geprüften Versandweg. Fehlt für einen Schritt eine reale Fähigkeit, wird er als Lücke markiert und automatisch zur Entwicklungsaufgabe, statt im Schema als Wunsch zu stehen. Und bevor etwas Neues gebaut wird, prüft ein Register, ob es die Fähigkeit schon gibt.