In der Praxis
Die Ausnahme ist die eigentliche Arbeit
Ein idealtypischer Prozess führt in fünf klaren Schritten von einer Anfrage zu einem Angebot. In der Realität laufen die meisten Anfragen anders. Entscheidend ist deshalb, was ein System tut, wenn der vorgesehene Ablauf nicht mehr weiterführt.
Die Seite zu den Individuallösungen zeigt ein veranschaulichendes Beispiel: Eine Anfrage kommt per E-Mail mit angehängter Spezifikation, der Artikel wird im ERP identifiziert, die aktuellen Kosten werden geprüft, ein Angebot wird entworfen, und ein Mensch gibt es frei. Fünf Schritte, und der letzte ist ein Mensch. Es ist eine Veranschaulichung und kein Kunde, und das gilt für alles in diesem Beitrag: Atlas ist jung und hat keinen Einsatz, über den es berichten könnte.
Das Beispiel ist ehrlich in dem, was es zeigt, und schweigt über das, was es nicht zeigt. Es zeigt den Durchlauf, in dem alle fünf Schritte halten. Wer im operativen Geschäft gearbeitet hat, weiß, wie oft man genau diesen Durchlauf bekommt, und deshalb ist die andere Frage die interessante. Was geschieht an dem Schritt, den das System nicht abschließen kann?
Vier Arten, wie dieselbe Anfrage schiefgeht
Die Fehler sind nicht exotisch. Sie sind die gewöhnliche Beschaffenheit der Arbeit, und sie sind der Grund, warum der Schritt heute von einem Menschen erledigt wird.
Die Spezifikation ist mehrdeutig
Der Anhang beschreibt etwas im Vokabular des Kunden statt in Ihrem. Zwei Artikel im ERP könnten gemeint sein. Ein Mensch löst das, weil er weiß, welchen davon dieser Kunde schon einmal bestellt hat, und dieses Wissen steckt in einem Menschen und nicht in einem Feld.
Der Datensatz ist veraltet
Die Kosten im System stimmten beim letzten Import. Ob das heute Morgen war oder im letzten Quartal, ist am Datensatz selbst nicht zu erkennen, und ein Angebot, das auf dem zweiten Fall beruht, ist auf eine Weise falsch, die niemand bemerkt, bis die Marge gezählt wird.
Den Artikel gibt es gar nicht
Es ist eine Variante, die noch nie angeboten wurde, oder eine Konfiguration aus Einzelteilen. Es gibt keinen Datensatz zu identifizieren, der Schritt fällt also weniger durch eine Prüfung, als dass er nichts zu prüfen findet.
Zwei Systeme sind sich uneinig
ERP und CRM halten verschiedene Fassungen derselben Tatsache. Beide sind in sich stimmig. Keine ist als die falsche gekennzeichnet.
Ein System, das die fünf Schritte trotzdem durchläuft, erzeugt in jedem dieser Fälle ein Angebot. Das ist der Fehler, um den man sich sorgen sollte, denn das Ergebnis sieht genauso aus wie das eines Durchlaufs, der gut gegangen ist.
Anhalten ist ein Ergebnis, kein Fehler
Forge plant, führt aus und prüft, und die Prüfung ist keine Formalität am Ende. Arbeit wird gegen festgelegte Regeln geprüft, bevor sie als erledigt gilt. Ein Schritt, der sich nicht prüfen lässt, wird also nicht still zu einem Schritt, der bestanden hat.
Zwei verschiedene Dinge können einen Schritt anhalten, und es lohnt sich, sie auseinanderzuhalten. Wo sich die Befugnis hinter einer Handlung nicht feststellen lässt, lehnt die Governance-Ebene ab: Eine Prüfung, die sich nicht abschließen lässt, ist eine Ablehnung und keine Erlaubnis. Wo die Befugnis außer Frage steht und die Arbeit selbst unklar ist, schlägt die Qualitätsprüfung an. Einen Artikel zu identifizieren ist keine Frage der Berechtigung, und keine Regel darüber, wer handeln darf, löst sie.
Gemeinsam ist beiden die Antwort, die sie geben. Wo sich der Artikel nicht sicher identifizieren lässt, wählt das System nicht den wahrscheinlicheren von zwei Artikeln. Es hält an diesem Schritt an und sagt, welche zwei.
Drei der vier Fehler oben werden so erkannt, weil jeder von ihnen sichtbar wird: zwei Kandidaten, wo einer erwartet war, gar kein Kandidat oder zwei Systeme, die dieselbe Tatsache verschieden halten. Eine Prüfung findet, was fehlt und was sich widerspricht.
Die veralteten Kosten erkennt sie nicht, und das sollte man benennen, statt es in der Liste stehen zu lassen. Dieser Datensatz ist vollständig, in sich stimmig und falsch, und nichts an seiner Form verrät das. Keine Qualitätsprüfung findet ihn. Diese Lücke schließt keine klügere Prüfung, sondern ein Quellsystem, das festhält, wann die Zahl zuletzt stimmte, und wo das fehlt, war das Angebot falsch, bevor irgendein System es berührt hat.
Das ist das Gegenteil des Reflexes, auf dem die meiste Automatisierung gebaut ist: unter allen Umständen ein Ergebnis zu erzeugen, weil ein Ergebnis wie Fortschritt aussieht. Ein Angebot, das auf einer Vermutung beruht, hat die Arbeit nicht gespart. Es hat den Fehler zu dem Menschen verschoben, der unterschreibt, an der Stelle, an der er ihn am wenigsten bemerken wird, weil alles davor fertig aussieht.
Ein Schritt, der sich nicht abschließen lässt, ist eine Tatsache über die Arbeit, nicht ein Fehler im System.
Was tatsächlich bei einem Menschen ankommt
Der Unterschied zwischen einem System, das gut anhält, und einem, das schlecht anhält, ist, was ankommt, wenn es anhält.
Was ankommt, ist keine Fehlermeldung. Es ist die Arbeit bis zu diesem Punkt, in diesem Beispiel also die gelesene Anfrage, der identifizierte Kunde und die vier Schritte, die gehalten haben, zusammen mit der einen Frage, die sich nicht beantworten ließ, und den Belegen dazu: Diese zwei Artikel passen zur Beschreibung, und zu diesen Preisen wurden sie bisher angeboten.
Jemand, der den Kunden kennt, beantwortet die Frage in Sekunden. Das ist der Schritt, der einen Menschen brauchte, und er ist der einzige, um den er gebeten wurde.
Der Auftrag hält an. Die anderen nicht. Ein Auftrag, der an einer Qualitätsprüfung wartet, hält die Arbeit daneben nicht auf, und das zählt mehr, als es klingt: Eine Warteschlange, die blockiert, ist der Grund, warum Menschen aufhören, Arbeit überhaupt durch ein System laufen zu lassen.
Am Anfang hält es öfter an
Ein System, das nicht rät, hält überall dort an, wo die Informationen vor ihm wirklich nicht ausreichen, und am Anfang sind das mehr Stellen als später. Wie viele, können wir Ihnen nicht sagen: Atlas hat keinen Einsatz, in dem man sie zählen könnte. Vorab sagen lässt sich, dass sich ein System, das oft anhält, anfühlt wie ein System, das nicht funktioniert, und dass man sich auf dieses Gefühl vorbereiten sollte.
Ein Teil davon ist das System, das bei Arbeit, die es noch nicht gesehen hat, zu Recht unsicher ist. Ein anderer Teil hat mit dem System gar nichts zu tun: Ein Artikel, der sich nicht identifizieren lässt, ist oft ein Artikel, dessen Datensatz tatsächlich unvollständig ist, und ein Widerspruch zwischen zwei Systemen war da, bevor irgendetwas automatisiert wurde. Das Anhalten legt ihn offen, es verursacht ihn nicht.
Dieser Unterschied zählt, denn beide haben verschiedene Abhilfen, und nur eine davon ist unser Problem. Was Atlas einem Unternehmen hier schuldet, ist, dass die Haltepunkte lesbar sind: welcher Schritt, an welchem Datensatz und was gefehlt hat. Ob die Antwort darin liegt, die Autonomie des Systems für diese Art von Schritt zu erweitern oder die Daten darunter zu bereinigen, beurteilt das Unternehmen, mit genau diesem Wissen vor sich.
Wo sich die Ausnahmen als nützlich erweisen
Ein operatives Team kann meist sagen, welchen Teilen seiner Daten es nicht traut. Zeigen kann es sie meist nicht, denn dieses Wissen ist auf die Menschen verteilt, die jeden Tag darum herum arbeiten, und wurde nie irgendwo aufgeschrieben.
Ein System, das festhält, wo es angehalten hat und warum, schreibt genau das als Nebenprodukt seiner Arbeit auf. Nicht als Prüfbefund eines Projekts, sondern laufend, im Verlauf einer gewöhnlichen Woche.
Diesen Teil würden wir am entschiedensten verteidigen. Der saubere Weg war nie das Schwierige an der Automatisierung. In den Ausnahmen liegt die eigentliche Arbeit, sie sind der Grund, warum der Schritt heute noch einem Menschen gehört, und nur ein System, das sie als die Arbeit behandelt und nicht als Fehlerfall, kann irgendetwas davon übernehmen.
Das Produkt dazu
Planen, ausführen, prüfen, und die Qualitätsprüfung, um die sich dieser Beitrag dreht: was Forge prüft, bevor Arbeit als erledigt gilt, und wo es für einen Menschen anhält.