Am leichtesten erkennt man einen Defekt daran, dass das System einen Fehler meldet. Schwierig ist der Fall, in dem es ohne Meldung falsch läuft: Auf dem Bildschirm sieht alles gut aus, das Ergebnis ist still falsch. Diese Lektion zeigt, wo und in welcher Reihenfolge man dann sucht.
Diese Lektion nimmt sich den Moment vor, in dem eine gebaute Automatisierung nicht mehr so läuft wie erwartet. Ziel ist, dass Sie das Problem nicht durch Raten, sondern durch geordnetes Eingrenzen finden und die gefundene Korrektur dauerhaft machen. Eine Automatisierung bleibt auf den Beinen, sobald die Diagnose nicht mehr an der Person hängt, die das System gebaut hat, sondern zur Fähigkeit des Betriebs wird.
Am Ende halten Sie eine Diagnosereihenfolge, einen ausgefüllten Störungszettel und einen Prüfschritt in der Hand, der zeigt, dass die Korrektur gewirkt hat. Eingriffe ohne diese drei erzeugen häufig eine zweite Störung.
Voraussetzung: die Prozesskarte aus der ersten Lektion. Sie ist die schriftliche Erwartung, mit der Sie bei der Suche vergleichen.
Der Satz es läuft nicht deckt drei verschiedene Lagen zugleich ab, und jede wird von einer anderen Stelle aus diagnostiziert. Wer gleich zu Beginn des Gesprächs trennt, welche Art vorliegt, grenzt den Suchraum sofort ein.
Die Automatisierung läuft gar nicht. Der Auslöser kommt nicht an oder sie fällt beim ersten Schritt. Das ist die leichteste Art, weil das Symptom sichtbar ist und meist eine Spur im Protokoll hinterlässt.
Der Ablauf läuft, erzeugt Datensätze, meldet nichts; das Ergebnis ist trotzdem falsch. Das ist die teuerste Art, weil sich der Fehler über Wochen sammelt und die Bereinigung rückwärts reicht.
Das Ergebnis stimmt, kommt aber nicht rechtzeitig. Meist steckt keine einzelne Störung dahinter, sondern angestaute Last oder ein neu eingefügter Schritt. Ohne Messung bleibt diese Art strittig.
Allen dreien ist eines gemeinsam: solange die Erwartung ungeschrieben ist, lässt sich die Störung nicht bestimmen. Der Satz so hätte es nicht sein sollen wird ohne ein geschriebenes so hätte es sein sollen zu keiner Diagnose.
Eine Automatisierung bricht selten mit Lärm zusammen. Es kommt keine Fehlermeldung, nichts leuchtet rot, der Ablauf sieht grün aus. Die Ausgabe ist dennoch falsch: die Nachricht geht an die falsche Person, ein Feld bleibt leer, ein Datensatz wird zweimal angelegt, das Datum wird in anderer Form geschrieben.
Die Quelle einer stillen Störung ist meist die Eingabe, die ihre Form ändert. Im Formular öffnet sich ein neues Feld, das Portal schickt die Telefonnummer plötzlich anders, eine Mitarbeiterin füllt das Feld anders aus. Die Regel bleibt gleich, die Eingabe ändert sich, das Ergebnis rutscht leise weg.
Der letzte Punkt wiegt am schwersten. Sobald das Team eine Ausgabe von Hand berichtigt, ist das System längst defekt; weil es niemand gemeldet hat, ist die Störung in kein Protokoll gelangt.
Wenn etwas, das gestern lief, heute nicht läuft, hat sich dazwischen etwas geändert. Das ist die erste Frage der Diagnose, und die meisten Störungen schließen sich mit ihr. In Systemen ohne Änderungsliste dauert dieselbe Frage Stunden.
Änderungen passieren nicht nur im System. Auch im Prozess, bei den Personen und in der Eingabe. Eine Mitarbeiterin ist gegangen, ein Portal hat ein Feld umbenannt, ein Lieferant hat das Dateiformat erneuert. Beginnen Sie die Suche mit dieser Liste, nicht im Inneren des Codes.
Die Diagnose beginnt damit, dass das Symptom geschrieben wird. Es läuft nicht ist kein Symptom, sondern ein Gefühl. Das Symptom lautet: auf welchem Datensatz, wann, was war erwartet, was geschah stattdessen. Bevor diese vier Felder gefüllt sind, grenzt sich der Suchraum nicht ein.
Nehmen Sie beim Schreiben das erwartete Ergebnis aus der Prozesskarte der ersten Lektion. Fehlt die Karte, wird zuerst sie geschrieben; eine Diagnose ohne geschriebene Erwartung wird zum Vergleich zwischen dem Gedächtnis einer Person und dem Verhalten des Systems.
Die letzten beiden Fragen geben der Diagnose die Richtung. Zeigt sich die Störung auf einem einzigen Datensatz, sitzt das Problem eher in der Eingabe, auf allen in der Regel, auf einem Teil in der Bedingung.
Bessern Sie nichts aus, was Sie nicht reproduzieren können. Ohne ein Beispiel, das die Störung auf Wunsch wiederholt, können Sie auch nicht zeigen, ob Ihre Änderung geholfen hat. Viele als behoben geltende Störungen sind Störungen, die an jenem Tag schlicht nicht wieder auftraten.
Reproduzieren heißt, denselben Datensatz in einer Testumgebung oder mit einem harmlosen Beispiel durchlaufen zu lassen. Müssen Sie im laufenden System probieren, wählen Sie einen umkehrbaren Schritt und sagen Sie dem Team den Versuch vorher an.
Der schnellste Weg, den Suchraum einzugrenzen, ist den Ablauf in der Mitte zu teilen. Sind die Daten an einem Punkt in der Mitte richtig oder falsch? Sind sie richtig, sitzt die Störung in der zweiten Hälfte, sind sie falsch, in der ersten. Jede Teilung halbiert den zu prüfenden Bereich.
Diese Methode arbeitet unabhängig vom Werkzeug. Ob Sie auf die Datensatzmaske, die Zwischentabelle, die gesendete Nachricht oder das Protokoll schauen, die Frage bleibt dieselbe: sind die Daten hier richtig angekommen?
Schreiben Sie das Ergebnis nach jeder Teilung auf. Ungeschriebene Teilungen werden wiederholt, und die Diagnose zieht sich, weil dieselben Stellen ein zweites Mal geprüft werden.
Ist der Störungsbereich eng, prüfen Sie die fünf Teile aus der ersten Lektion der Reihe nach. Die sechs Quellen unten begegnen einem in der Praxis am häufigsten, und die meisten Diagnosen schließen sich in ihnen.
Das Ereignis ist womöglich gar nicht angekommen. Die Verbindung kann abgerissen, eine Berechtigung abgelaufen, eine Adresse geändert sein. Entstand kein Datensatz, sitzt die Störung an der Tür des Ablaufs, nicht darin.
Das ist die häufigste Quelle. Ein Feld kann umbenannt worden sein, ein Datum in anderer Form ankommen, eine führende Null weggefallen sein, ein Leerzeichen oder ein Großbuchstabe abweichen.
Eine neue Lage kann aufgetreten und aus den geschriebenen Wegen gefallen sein. Datensätze außerhalb der Bedingungen fallen meist leise weg, weil für sie kein Weg geschrieben wurde.
Ein Kennwort kann geändert, ein Schlüssel abgelaufen, ein Zugang gelöscht worden sein. Störungen dieser Art beginnen an einem Tag plötzlich und kündigen sich vorher nicht an.
Zwei Schritte können in falscher Reihenfolge gelaufen sein, oder einer startete, ohne die Daten des anderen abzuwarten. Störungen, die zu Stoßzeiten auftreten und in ruhigen Stunden ausbleiben, sitzen meist hier.
Die Gegenseite kann abgelehnt haben: ein Feld wurde Pflicht, ein Limit war voll, ein Format wurde zurückgewiesen. Wird die zurückkommende Antwort nicht gelesen, bleibt diese Störung still.
Ändern Sie nicht mehrere Dinge gleichzeitig. Machen Sie zwei Änderungen und das Ergebnis wird besser, bleibt offen welche geholfen hat; wird es schlechter, bleibt offen welche geschadet hat. An dieser Stelle kehrt die Diagnose zum Raten zurück.
Lassen Sie nach jeder Änderung das Beispiel aus dem zweiten Schritt erneut laufen. Die Prüfung umfasst ebenso, dass die Störung weg ist, wie dass nichts anderes kaputtging. Schreiben Sie dafür vorher auf, welche Datensätze richtig liefen.
Die Störung zu beseitigen ist die halbe Arbeit. Die andere Hälfte besteht darin, die Marker zu setzen, die dieselbe Störung am leisen Wiederkehren hindern. Ohne das wird dieselbe Diagnose ein paar Monate später von vorne gemacht.
Dauerhaftigkeit kommt aus drei Dingen: einer Meldung dort, wo sich die Störung zeigen würde, einer Prüfung der Eingabegrenzen und einem bestimmten Ausnahmeweg. Alle drei sitzen in der Automatisierung selbst und verlangen kein eigenes System.
Arbeiten wir die Methode an einer einzigen Störung von Anfang bis Ende durch. Das Beispiel läuft über einen Vertriebsablauf, die Reihenfolge ist jedoch in jedem Ablauf dieselbe.
Symptom: Kunden mit neuen Anfragen bekommen die Angebotsmail nicht. Der Vertrieb merkte es zuerst und berichtet, dass in der vergangenen Woche mehrere Kunden auf eine Rückmeldung warteten. Datensätze scheinen angelegt worden zu sein.
Was sich änderte: in den letzten zwei Wochen kam ein neues Feld ins Formular und auf der Portalseite gab es ein Update. Zwei Kandidaten.
Reproduktion: einer der betroffenen Datensätze wird mit derselben Eingabe erneut durchgelassen. Die Störung wiederholt sich, ein messbares Beispiel liegt vor.
Halbieren: die Tabelle in der Mitte des Ablaufs wird geprüft. Der Datensatz ist da, doch das Feld der Mailadresse ist leer. Die Störung sitzt also in der ersten Hälfte, auf der Eingabeseite.
Fünf Teile: das Eingabeformat wird geprüft. Das neue Formularfeld hat das Mailfeld umbenannt. Der Ablauf sucht den alten Namen, findet ihn nicht, gibt einen leeren Wert weiter, und der Mailschritt fällt leise aus.
Eine Änderung und Prüfung: der Ablauf wird auf den neuen Feldnamen umgestellt. Das Störungsbeispiel läuft erneut, die Mail geht raus. Zwei vorher richtige Datensätze laufen ebenfalls und bleiben richtig.
Dauerhaftigkeit: ist das Mailfeld leer, hält der Ablauf nun an, der Datensatz wartet und die Leitung wird benachrichtigt. Der Feldname auf der Prozesskarte wird aktualisiert. Der andere Ablauf mit demselben Feld wird geprüft und ebenfalls korrigiert.
Diagnose ist keine Fähigkeit, die man an dem Tag lernt, an dem eine Störung auftritt. An einem ruhigen Tag geprobt, steht sie am nötigen Tag bereit. Dafür ist die Übung unten da.
Jeder Ablauf, der leise durchgeht, ist ein Ablauf, der später eine stille Störung erzeugt. Diese Übung holt in den meisten Betrieben mindestens einen davon an die Oberfläche.
Diagnose-Prüfliste herunterladen (xlsx) · Störungszettel, was sich geändert hat, das Halbieren des Ablaufs, die Prüfung der fünf Teile und die Schritte zur dauerhaften Korrektur.
Zuerst geprüft wird meist die Regel, die häufigste Quelle ist jedoch die Eingabe. Hat sich die Regel seit gestern nicht geändert, hat sich eher das geändert, was bei ihr ankommt.
Zwei Änderungen zu machen und das Ergebnis anzusehen beendet die Diagnose nicht, es verwischt sie. Welche Änderung was bewirkt hat, bleibt offen, und die Korrektur wird unwiederholbar.
Eine Korrektur an einer nicht wiederholbaren Störung lässt sich nicht prüfen. Die Störung bleibt eine Weile unsichtbar und kommt dann an derselben Stelle zurück.
Die meisten Abläufe schreiben irgendwo auf, was sie getan haben. Eine Diagnose ohne Protokoll ist Raten, ohne zu hören, was das System sagt.
Ein mündlich weitergegebenes Symptom ändert sich bei jeder Weitergabe. Ein ungeschriebenes Symptom wird zur Diagnose, bei der zwei Leute zwei verschiedene Störungen suchen.
Eine ohne Meldung und Prüfung geschlossene Störung kommt in derselben Form zurück. Beim zweiten Mal beginnt die Diagnose von vorne und das Vertrauen bröckelt erneut.
Bevor eine Störung geschlossen wird, sollten Sie zu jedem Punkt unten ja sagen können. Fehlt ein Punkt, ist die Störung nicht geschlossen, sondern verschoben.
Die Begriffe, die in Diagnosegesprächen vorkommen. Sobald das Team eine gemeinsame Sprache hat, geht die Übergabe einer Störung schneller.
In dieser Lektion ging es darum, eine Störung geordnet einzugrenzen und die Korrektur dauerhaft zu machen; Sie haben gesehen, dass ein grosser Teil der Störungen von der Eingabeseite kommt.
Die übrigen Module des Lehrplans werden vorbereitet. Sobald sie erscheinen, nehmen sie ihren Platz im Lehrplan ein und zeigen sich auf der Schulungsseite.
Das Ausnahmeverzeichnis, der Meldeweg und die Messung, die stille Störungen sichtbar macht.
Feldverzeichnis und Formregeln. Die meisten Störungen beginnen auf dieser Seite.
Der gesamte Schulungsbereich und die seither ergänzten Module.
Wenn Sie vermuten, dass ein System still falsch läuft, schreiben Sie uns und wir sehen es gemeinsam an.
Angebot per WhatsApp