Software sollte sich nach dem Prozess richten, nicht umgekehrt.

Interne Softwareprojekte scheitern selten an schlechtem Code. Sie scheitern daran, dass die Software einen Prozess abbildet, der auf einer Folie existierte, während die Menschen bei ihrer Arbeit einem anderen folgten: in Tabellen, E-Mails und Telefonaten. Das Ergebnis ist ein System, das technisch fertig ist und praktisch ignoriert wird.

Der Prozess auf der Folie und der Prozess im Arbeitsalltag

Jede Organisation hat zwei Versionen eines Prozesses. Die dokumentierte ist linear, hat klare Rollen und endet mit einer Entscheidung. Die tatsächliche hat Ausnahmen, informelle Kommunikationswege, eine Person, die „einfach Bescheid weiß“, und einen Schritt, der nur wegen eines Vorfalls vor drei Jahren existiert. Software, die auf der ersten Version beruht, scheitert innerhalb einer Woche an der zweiten.

Vor jeder Gestaltungsarbeit gilt es, die zweite Version zu finden. Sie steht nicht in der Dokumentation. Sie findet sich dort, wo die Arbeit geschieht.

Wie wir sie finden

Einen Vorgang von Anfang bis Ende begleiten. Keine Beschreibung eines Vorgangs, sondern eine echte Bestellung, Anfrage oder Reklamation, vom Eingang bis zum Abschluss. Setzen Sie sich zu jeder Person, die daran arbeitet. Schreiben Sie auf, was sie öffnet, was sie kopiert, wen sie fragt und worauf sie wartet.

Die Behelfslösungen sammeln. Jede Tabelle auf einem gemeinsamen Laufwerk ist eine Anforderung, die niemand aufgeschrieben hat. Jedes „Ich führe eine Liste“ ist eine fehlende Funktion. Jedes „Ich frage Petra“ ist eine undokumentierte Regel, die in einem einzigen Kopf steckt.

Die Ausnahmen zählen. Wenn der „normale“ Weg 60 % der Fälle abdeckt, sind die übrigen 40 % ebenfalls der Prozess. Gestalten Sie sie ausdrücklich mit: Welche Ausnahmen bekommen einen definierten Ablauf, welche eine menschliche Entscheidung mit den richtigen Informationen, und welche werden direkt am Eingang abgewiesen?

Die Entscheidungen benennen. Die meisten Prozesse sind eine Kette von Entscheidungen mit Datenbewegungen dazwischen. Jede Entscheidung braucht einen Verantwortlichen, die dafür nötigen Informationen und einen Ort, an dem sie dokumentiert wird. Diese Liste bildet das Rückgrat der Anwendung.

Was das an der Software verändert

• Das Datenmodell folgt dem Vorgang, nicht dem Organigramm. Das zentrale Objekt ist das, was bearbeitet wird, mit seinen Zuständen, Entscheidungen und seiner Historie. Abteilungen sind Rollen an diesem Objekt.
• Zustände sind eindeutig. „In Bearbeitung“ ist kein Zustand. „Wartet auf Lieferantenbestätigung, fällig am Freitag, verantwortlich: Einkauf“ ist einer.
• Ausnahmen haben eine Oberfläche. Die Ansicht für den ungewöhnlichen Fall wird genauso sorgfältig gestaltet wie die für den Normalfall, denn dort wird die Zeit verbraucht.
• Integrationen ersetzen Kopieren und Einfügen. Jede Stelle, an der jemand Daten von einem System in ein anderes abtippt, ist eine Integration im Backlog, priorisiert nach ihrer Häufigkeit.
• Das erste Release ist eng umrissen und im echten Einsatz. Ein Vorgangstyp, durchgängig, im Produktivbetrieb und mit den Menschen, die den Vorgang begleitet haben. Danach folgt der nächste.

Woran sich Erfolg misst

Nicht an der Anzahl der Funktionen. Sondern an der Anzahl gelöschter Tabellen, der Anzahl entfallener E-Mails und daran, ob die Person, die „einfach Bescheid weiß“, Urlaub nehmen kann.