Je gleichmäßiger eine Automatik läuft, desto schlechter erkennen Menschen ihren Ausfall. In einem Mehrfachaufgaben-Experiment mit einer Flugaufgaben-Simulation (Kurs halten, Treibstoff verwalten, System überwachen, vier Sitzungen à 30 Minuten) sollten Versuchspersonen ein automatisches System auf Fehlfunktionen überwachen. Wer eine konstant laufende Automatik überwachte, erkannte deren Fehler signifikant schlechter als wer eine Automatik überwachte, deren Zuverlässigkeit alle zehn Minuten zwischen 56,25 und 87,5 Prozent wechselte. Und zwar unabhängig vom Niveau: Die Gruppe mit konstant 56,25 Prozent schnitt genauso schlecht ab wie die mit konstant 87,5 Prozent. Ausschlaggebend war nicht, wie gut die Automatik war, sondern dass sie sich immer gleich verhielt. Nachweisbar war der Effekt bereits nach 20 Minuten Bearbeitungszeit.
Die Studie stammt von Parasuraman/Molloy/Singh aus dem Jahr 1993 (International Journal of Aviation Psychology 3(1), S. 1 bis 23). Die Zahlen oben stehen so in einem technischen Memorandum der NASA Langley von Dezember 2001, S. 4 bis 5, das Aufbau und Befund der Studie ausführlich wiedergibt. Die Originalveröffentlichung selbst ist nicht frei abrufbar. In der Literatur läuft der Effekt unter automatisierungsinduzierter Komplazenz. Der Schluss der Autoren: Die Gleichförmigkeit der Automatik ist der wesentliche Auslöser, nicht ihr Zuverlässigkeitsniveau.
Halte das neben die Zahl, mit der Unternehmen Reporting-Projekte rechtfertigen. Unser Use Case zur automatisierten Berichterstellung setzt 3 bis 5 Stunden pro Person und Woche an, die heute für das Zusammenstellen und Formatieren von Berichten draufgehen. Nimm das als Hausnummer aus der Praxis: Eine öffentlich prüfbare Primärquelle für genau diesen Wert konnten wir nicht abrufen, also rechne ihn für dein Team lieber selbst nach.
Diese Stunden sind nicht nur Fleißarbeit. Sie sind der einzige Moment in der Woche, in dem ein Mensch die Zahlen tatsächlich in der Hand hat.
Wir haben diesen Use Case im Detail ausgearbeitet und beraten Unternehmen dazu. Was so ein System kostet, welche Werkzeuge wann passen und was die DSGVO dabei verlangt, findest du in unserem Use Case zur automatisierten Berichterstellung. Dieser Text handelt von der Zeile im Business Case, die zweimal vorkommt.
Die gesparte Stunde und die verlorene Sichtprüfung sind dieselbe Zeile
Die Behauptung ist nicht, dass Handarbeit genauer wäre. Sie ist es nicht. Verrutschte Zellbezüge und vergessene Aktualisierungen sind der Grund, warum sich Automatisierung überhaupt lohnt.
Die Behauptung ist eine andere. Handarbeit wird beiläufig beobachtet. Wer den Umsatz der Vorwoche neben den der aktuellen Woche kopiert, sieht beide Zahlen, ob er will oder nicht. Die Plausibilitätsprüfung passiert kostenlos mit, sie steht in keinem Prozess und in keiner Stellenbeschreibung. Sie ist ein Nebenprodukt der Fleißarbeit.
Nach der Automatisierung bleiben laut demselben Use Case 20 bis 40 Minuten Qualitätskontrolle pro Bericht übrig. Das ist der ehrliche Plan. In der Praxis ist dieser Rest das Erste, was verschwindet, weil er sich nach Misstrauen gegen ein System anfühlt, das seit Wochen sauber aussieht. Dieselbe Beobachtung machen wir auch in bezahlten Kundenprojekten: Nach der Einführung steht in keinem Kalender ein Termin, an dem jemand eine einzelne Kennzahl gegen das Quellsystem prüft.
Weniger Fehler heißt nicht weniger Schaden
Wer im Qualitätsmanagement schon einmal eine FMEA ausgefüllt hat, kennt die Denkweise. Die Methode bewertet jeden möglichen Fehler auf drei getrennten Achsen: Auftreten, Bedeutung, Entdeckung. Ein seltener Fehler, den niemand bemerkt, kann riskanter sein als ein häufiger, der sofort auffällt. Das ist eine Übertragung, kein etabliertes Verfahren fürs Controlling, aber sie sortiert die Sache sauber.
Automatisierung bewegt alle drei Achsen, nur nicht in dieselbe Richtung. Das Auftreten sinkt, das ist der versprochene Nutzen. Die Entdeckung wird schlechter, weil der Mensch, der die Zahlen bisher gesehen hat, per Projektziel entfernt wurde. Und die Bedeutung steigt, weil ein Fehler seinen Charakter ändert: Eine verrutschte Zelle betrifft einen Bericht, eine falsche Feldzuordnung betrifft jeden künftigen Bericht auf exakt dieselbe Weise, bei allen Empfängern, in jeder Entscheidung, die darauf aufsetzt.
Du tauschst häufige, laute Einzelfehler gegen seltene, stille Systemfehler. Das kann ein guter Tausch sein. Er ist nur keiner, den irgendjemand bewusst getroffen hat.
Ein Bericht, der plausibel aussieht, ist kein Beleg
Public Health England meldete in einer Stellungnahme vom 4. Oktober 2020, dass im Zeitraum vom 25. September bis zum 2. Oktober 2020 insgesamt 15.841 positive Covid-19-Testergebnisse nicht in die Tagesmeldungen eingeflossen waren. Über 75 Prozent davon, 11.968 Fälle, entfielen auf die letzten drei Tage dieses Zeitraums. Aufgefallen ist der Fehler laut Behörde in der Nacht auf Freitag, den 2. Oktober, direkt im Ladeprozess: Beim Übertragen in die zentralen Reporting-Systeme überschritten Dateien die maximale Dateigröße. Die Kontaktverfolgung für diese Fälle verzögerte sich entsprechend.
Der technische Hintergrund, den die offizielle Mitteilung selbst nicht nennt: James Broome, Director of Engineering bei der Beratung endjin, beschrieb acht Tage später, dass das alte XLS-Format nur rund 65.000 Zeilen fasst und alles darüber beim Import stillschweigend abgeschnitten wird. Das ist eine Einordnung aus zweiter Hand, kein Behördendokument.
Wichtiger als das Format ist die Form des Fehlers. Die Dashboards liefen weiter. Sie zeigten Zahlen, die aussahen wie Zahlen. Was fehlte, kam in der Ausgabe nicht vor, und deshalb konnte es an der Ausgabe auch niemand sehen. Eine nationale Meldekette ist nicht dein Wochenreport, das Risikoprofil liegt Größenordnungen auseinander. Der Mechanismus ist derselbe: Eine Pipeline kürzt still, und das Ergebnis bleibt plausibel.
Der Fehler saß in der Formel, nicht in der Zahl
Im Untersuchungsbericht der Management Task Force von JPMorgan Chase vom 16. Januar 2013 steht auf Seite 128 ein Satz, den jeder lesen sollte, der ein Berichtssystem verantwortet. Nach der Subtraktion zweier Raten teilte die Tabellenkalkulation im neuen Value-at-Risk-Modell durch deren Summe statt durch deren Mittelwert, wörtlich: „the spreadsheet divided by their sum instead of their average, as the modeler had intended”. Laut Bericht dämpfte dieser Fehler die ausgewiesene Volatilität wahrscheinlich um den Faktor zwei und senkte den ausgewiesenen Value at Risk entsprechend.
Auf Seite 127 desselben Berichts steht ein zweiter, davon unabhängiger Vorfall: Am 10. April 2012 spiegelte der Value-at-Risk-Report einen Tagesverlust von 400 Millionen Dollar im betroffenen Portfolio schlicht nicht wider, weil ein separater Tabellenfehler ihn verschluckte. Er wurde korrigiert und löste laut Bericht keine weitere Untersuchung aus. Der Bericht stellt zwischen beiden Vorfällen keinen Zusammenhang her. Die Summen-statt-Mittelwert-Panne fiel erst Anfang Mai 2012 bei einer separaten Modellprüfung auf, die wegen der laufenden Verluste im Portfolio angestoßen wurde.
Eine Investmentbank mit eigener Modellvalidierung unter Aufsicht der Regulierer ist nicht die Ausgangslage eines Großhändlers mit 60 Mitarbeitenden. Die Lehre skaliert trotzdem nach unten: Der Bericht war die ganze Zeit prüfbar. Er wurde nur nicht gegen die Quelle geprüft.
Aufpassen ist kein Verfahren
Der Reflex an dieser Stelle heißt: Dann muss man eben genauer hinsehen. Genau das ist der Teil, der messbar nicht funktioniert.
Lisanne Bainbridge hat die Grundironie 1983 in Automatica beschrieben (19(6), S. 775 bis 779), sinngemäß: Automatisierung nimmt dem Menschen die Aufgaben ab, die er gut beherrscht, und lässt ihm ausgerechnet die Überwachung übrig, die er nachweislich schlecht beherrscht. Bainbridge stützt das auf die Vigilanzforschung: Effektive visuelle Aufmerksamkeit auf eine Informationsquelle, an der fast nie etwas passiert, hält ein Mensch selbst hoch motiviert nicht länger als etwa eine halbe Stunde durch (Bainbridge verweist dafür auf Mackworth 1950). Ihr Schluss: Das Überwachen auf unwahrscheinliche Abweichungen ist für Menschen nicht leistbar, das muss ein automatischer Alarm übernehmen. Zusammen mit dem Simulator-Experiment vom Anfang ergibt das eine unbequeme Reihenfolge: Je gleichförmiger dein Reporting läuft, desto weniger taugt der Vorsatz, aufmerksam zu bleiben. Ein Termin im Kalender ist kein Ersatz für Sorgfalt. Er ist der einzige Teil davon, der auch nach acht Monaten noch existiert.
Die KI-Zusammenfassung liefert die Erklärung gleich mit
Bis 2027 sollen 75 Prozent neuer Analytics-Inhalte durch generative KI für intelligente Anwendungen kontextualisiert werden. Das ist eine Prognose von Gartner vom 18. Juni 2025, gestützt auf eine Befragung von 403 Analytics- und KI-Verantwortlichen von Oktober bis Dezember 2024. Aus derselben Befragung: Über 50 Prozent geben an, dass ihre Organisation heute schon KI-Werkzeuge für automatisch erzeugte Auswertungen und Abfragen in natürlicher Sprache einsetzt. Eine Prognose ist keine Messung, aber die Richtung ist in den Produkten längst sichtbar. Power BI formuliert Erklärungen zu erkannten Ausreißern in natürlicher Sprache, dazu gleich mehr. Tableau Pulse erzeugt seit seiner allgemeinen Verfügbarkeit am 22. Februar 2024 automatisch sprachliche Auswertungen zu definierten Kennzahlen, berichtet TechTarget.
Für die Entdeckbarkeit ist das die eigentliche Verschärfung. Eine rohe Zahl, die seltsam aussieht, kann dich noch stutzig machen. Ein flüssiger deutscher Satz, der die Abweichung erklärt, unterdrückt den Verdacht aktiv, weil er eine plausible Ursache mitliefert. Und dieser Satz entsteht mit derselben Souveränität, ob die zugrunde liegende Zahl stimmt oder nicht. Das ist keine Halluzination im engeren Sinn, die Erklärschicht rechnet ja korrekt auf dem, was sie bekommt. Sie kann nur nicht wissen, dass die Zahl seit sechs Wochen aus einem umbenannten Feld kommt.
Aus der Monitoring-Perspektive haben wir denselben Befund für LLM-Anwendungen beschrieben, die still degradieren. Dort sind Modell- und Prompt-Drift der Auslöser. Hier reicht eine Umbenennung im CRM.
Die Erkennung steckt im Produkt, sie ist nur nicht eingeschaltet
Der stärkste Einwand gegen diesen ganzen Text lautet: Moderne BI-Werkzeuge lösen das längst selbst. Power BI erkennt Ausreißer automatisch und liefert dazu eine sprachliche Erklärung mit den nach Erklärungsstärke sortierten Faktoren. Der Mensch wird als Sensor nicht mehr gebraucht.
Das stimmt, und es steht so in der Microsoft-Dokumentation zur Anomalieerkennung. Dieselbe Seite nennt allerdings auch die Bedingungen (Microsoft-Dokumentation, zuletzt aktualisiert am 23. Juli 2026). Die Funktion ist kein Standardverhalten, sie muss für jedes Diagramm einzeln im Analysebereich eingeschaltet werden. Sie funktioniert nur bei Liniendiagrammen mit Zeitachse und mindestens vier Datenpunkten. Mit Legenden, mehreren Werten oder Sekundärwerten arbeitet sie nicht. Bei DirectQuery auf SAP-Quellen, im Power BI Report Server und bei Live-Verbindungen zu Analysis Services ist sie gar nicht verfügbar.
Die Entdeckungsschicht ist also vorhanden, sie ist nur bei niemandem an. Das liegt an der Projektform: Der erste automatische Bericht steht laut unserem Use Case oft in 1 bis 3 Tagen. Das Projekt endet an dem Tag, an dem der Bericht zum ersten Mal richtig aussieht. Das ist genau der Tag, an dem die Arbeit an der Entdeckbarkeit anfangen müsste.
Ein Bericht ist nicht fertig, wenn er stimmt
Dreh die Abnahmebedingung um. Ein automatisierter Bericht ist nicht fertig, wenn er stimmt. Er ist fertig, wenn er merkbar aufhören kann zu stimmen. Drei Dinge reichen dafür aus, und keines davon ist ein Projekt.
Erstens: eine benannte Person mit Informationspflicht an den Quellsystemen. Wer ein Feld umbenennt, eine Kategorie neu bucht oder eine Berechnungslogik ändert, sagt vorher Bescheid, nicht hinterher. Das ist keine technische Maßnahme, sondern eine Zuständigkeit mit Namen. „Die IT” ist kein Name.
Zweitens: eine Stichprobe gegen die Quelle mit fester Frequenz. Eine Kennzahl, ein Zeitraum, von Hand im Quellsystem nachgezählt. Fünf Minuten, im Kalender, mit Datum. Nach Gefühl prüft niemand, dafür sorgt der Effekt vom Anfang dieses Textes.
Drittens: mindestens ein Alarm auf Plausibilität statt auf technische Verfügbarkeit. Zeilenzahl gegenüber der Vorwoche, Anteil leerer Felder, Zeitpunkt der letzten Datenlieferung. Ein Job, der erfolgreich durchgelaufen ist, meldet dir nur, dass er durchgelaufen ist. Über den Inhalt sagt diese Meldung nichts.
Der Aufwand dafür liegt nach unserer Schätzung bei einer knappen Stunde im Monat. Wer ihn streicht, spart ihn nicht, sondern verschiebt ihn: Die Rechnung kommt als KI-Schulden zurück, wenn irgendwann jemand fragt, seit wann die Zahl eigentlich falsch ist, und niemand das beantworten kann.
Wenn dein automatischer Bericht seit Monaten nie etwas gemeldet hat, weißt du bis jetzt genau eines: dass er läuft.