Fehlermeldungen sind besser als stille Fehler

„Das Tool zeigt einen Fehler an.“

Klingt erst einmal schlecht.

Ist aber oft ein gutes Zeichen.

Denn die Alternative ist nicht: kein Fehler.

Die Alternative ist häufig: ein stiller Fehler.

Und stille Fehler sind gefährlicher.

Sie laufen durch. Sie sehen plausibel aus. Sie landen im Bericht. Sie werden verschickt. Sie werden zur Entscheidungsgrundlage.

Bis irgendwann jemand fragt, warum die Zahl nicht stimmen kann.

Dann beginnt die Rückwärtssuche.

Welche Datei war die Quelle?
Welche Version wurde verwendet?
Wurde eine Zeile übersehen?
War ein Feld leer?
Hat ein Wert gefehlt?
Wurde ein Sonderfall falsch behandelt?

Die provokante These: Unternehmen sollten sich über gute Fehlermeldungen freuen. Sie zeigen, dass der Prozess nicht blind weiterläuft.

Gerade in Excel- und Office-Abläufen wird viel zu oft auf Plausibilität nach Gefühl gesetzt.

„Sieht gut aus.“

Das ist keine Prüfung.

Eine gute Prüfung sagt konkret, was nicht stimmt.

Kundennummer fehlt.
Datum ungültig.
Kostenstelle unbekannt.
Doppelter Datensatz.
Betrag negativ, obwohl nicht erlaubt.
Pflichtspalte nicht gefunden.
Dateiformat passt nicht.

Das nervt im Moment.

Aber es spart später Zeit.

Weil Fehler dort auftauchen, wo sie entstehen. Nicht drei Prozessschritte später.

Viele Nutzer wünschen sich, dass Automatisierungen einfach „durchlaufen“.

Verständlich.

Aber ein Prozess, der falsche Daten akzeptiert, ist nicht benutzerfreundlich. Er ist riskant.

Benutzerfreundlich ist eine Fehlermeldung, die verständlich erklärt, was zu tun ist.

Nicht: Laufzeitfehler 13.

Sondern: „In der Importdatei fehlt die Spalte Kundennummer. Bitte prüfen Sie den Export.“

Das ist ein großer Unterschied.

Gute Automatisierung bedeutet nicht, dass nie etwas schiefgeht.

Gute Automatisierung bedeutet, dass Fehler kontrolliert sichtbar werden.

Und zwar so, dass die Fachabteilung damit arbeiten kann.

Das klingt nach Detail.

Ist aber Prozessqualität.

Denn wer Fehler früh erkennt, verhindert Nacharbeit. Wer Fehler klar benennt, reduziert Rückfragen. Wer Fehler dokumentiert, versteht wiederkehrende Probleme besser.

Vielleicht sollte man also weniger fragen: Warum stoppt das Tool?

Und öfter: Warum hat der alte Prozess diesen Fehler früher nicht bemerkt?

Das ist die eigentliche Frage.