Eine falsche Zahl in einem fertigen Bericht stammt fast nie aus dem Workflow, mit dem er erstellt wurde. Wenn ein Dashboard eine Zahl anzeigt, die fehlerhaft aussieht, ist es der erste Reflex, den Workflow zu öffnen und die Logik zu überprüfen. Meist lief die Logik genau wie vorgesehen; der Fehler hat sich bereits früher eingeschlichen, und zwar in Daten, die sich zuvor niemand angesehen hat.
Die typischen Fehlerquellen wiederholen sich über Teams hinweg. Ein Nullwert hätte eine Berechnung stoppen müssen, wurde jedoch leer durchgereicht. Eine doppelte Zeile trieb eine Zählung in die Höhe. Ein Messwert lag außerhalb eines gültigen Bereichs, ohne eine Warnung auszulösen. Eine Schemaänderung erfolgte unbemerkt und veränderte die eigentliche Bedeutung einer Spalte.
Den Workflow neu zu erstellen, nachdem etwas ausfällt, löst das Problem nicht. Eine Prüfung an der Stelle einzubinden, an der Daten in den Prozess einfließen, hingegen schon – und diese Prüfung muss für drei verschiedene Personen funktionieren, nicht nur für diejenige, die sie erstellt hat.
Der Analyst übernimmt jeden Fehler, den der Workflow nicht abfängt
Für den Analysten, der für den Workflow verantwortlich ist, ist die Überprüfung eine manuelle Gewohnheit, die im Konflikt mit einer Frist steht, und manuelle Gewohnheiten werden als Erstes übersprungen, wenn die Frist knapp wird. Es gibt keine systematische Möglichkeit zu bestätigen, dass die Eingabe korrekt ist, bevor der Workflow darauf ausgeführt wird.
Dana ist genau für dieses Problem zuständig. Sie ist Analystin im Werk-Analytics-Team eines Tier-1-Automobilzulieferers und ihr wöchentlicher First-Pass-Yield-Workflow zieht Messwerte aus dem MES-Feed der Endmontagelinie in den Bericht ein, den das Werk jeden Montagmorgen prüft. Die Betriebsleitung stützt sich auf diesen Bericht, um zu entscheiden, ob eine Linie Aufmerksamkeit erfordert, bevor die nächste Schicht beginnt, sodass eine falsche Zahl nicht einfach unbemerkt in einer Tabellenkalkulation stehen bleibt.
Früher überprüfte sie die Zeilenanzahl nach Augenmaß und kontrollierte eine Stichprobe von Messwerten, bevor sie den Bericht jede Woche erstellte. Das funktionierte gut, als das Volumen noch gering war und eine Handvoll Messwerte stellvertretend für die gesamte Schicht stehen konnte. Als der Durchsatz auf Hunderte von Messwerten pro Tag anstieg, schrumpfte die Stichprobenprüfung zu einem hastigen Blick vor Ablauf der Frist – und schließlich dazu, dem Feed blind zu vertrauen.
Eine Firmware-Aktualisierung am Drehmomentsensor der Endmontagestation änderte, was passierte, wenn ein Messwert unter 2,4 Nm fiel. Anstatt diese Messwerte als Fehler zu protokollieren, hörte der Sensor einfach auf, eine Zeile für sie zu schreiben. Die Einheiten außerhalb der Spezifikation erschienen überhaupt nicht im Dataset.
Danas Ausbeuteberechnung erfasste immer nur bestandene Messwerte. Es meldete drei Wochen in Folge eine steigende Erstausbeute, während die tatsächliche Ausschussquote der Linie darunter unbemerkt anstieg.
Die Lücke reichte tiefer als der Sensor. Niemand hatte die tatsächliche Drehmomentspezifikation, 2,4 bis 2,6 Nm, in die eigene Grenzwerttabelle des MES eingegeben. Sie existierte nur in der persönlichen Tabellenkalkulation eines Qualitätsingenieurs, sodass selbst ein vollständiges Dataset nichts gespeichert gehabt hätte, womit es sich hätte abgleichen können.
Das ist in erster Linie ein Problem der Profilierung: Überprüfen, was tatsächlich in den eingehenden Daten enthalten ist, bevor darauf vertraut wird, was am anderen Ende herauskommt, abgeglichen mit einem Spezifikationsgrenzwert, der an einem anderen Ort als in der Datei einer einzelnen Person abgelegt ist. Es muss als Teil der normalen Ausführung des Workflows ablaufen und nicht als separate manuelle Aufgabe, die mit demselben Termindruck konkurriert, der die Lücke überhaupt erst verursacht hat.
Was eine Prüfung hätte erkennen müssen
- Ein Vergleich der Zeilenanzahl mit dem erwarteten Produktionsvolumen der Schicht, um unbemerkt fehlende Messwerte zu erkennen, nicht nur fehlerhafte.
- Eine Bereichs- und Schwellenwertvalidierung anhand eines gespeicherten Spezifikationsgrenzwerts, nicht eines Werts in der Datei einer einzelnen Person.
- Eine Prüfung auf Null- oder Leerwerte für das Sensorfeld selbst, da dieser Fehler als Fehlen und nicht als Fehlerwert auftrat.
- Ein Stopp für den Batch, nicht nur eine Notiz, wenn eine Schicht diese Prüfungen nicht besteht, damit eine fehlerhafte Schicht nicht unbemerkt in die Wochenzahlen einfließt.
Bevor der nächste Bericht versendet wird, lohnt es sich, die letzte ungeklärte Zahl bis zu ihrem tatsächlichen Ursprung zurückzuverfolgen. In den meisten Fällen hat der Workflow seinen Auftrag erfüllt. Das Problem waren die eingehenden Daten, und niemand hat sie bei der Eingabe überprüft.
Die IT vertraut keinem Workflow, den sie nicht überprüfen kann
Die IT stellt eine andere Frage als der Analyst. Der Analyst möchte wissen, ob die Daten die Prüfung bestanden haben. Die IT möchte wissen, wer die Prüfung geändert hat, wann sie geändert wurde und ob diese Änderung im Nachhinein nachgewiesen werden kann.
Diese Frage kam in dem Moment auf, als Danas Team wollte, dass die Ausbeuteprüfung in jeder Schicht automatisch ausgeführt wird, anstatt nur dann, wenn sie daran dachte, nachzusehen. Die erste Frage der IT drehte sich um den Zugriff, nicht um die Logik: wer sonst noch die dahinterliegenden Schwellenwerte für Spezifikationsgrenzen bearbeiten konnte und ob eine Änderung dieser Schwellenwerte sichtbare Spuren hinterlassen würde.
Teams, die eine Plattform für diese Art von Arbeit evaluieren, achten auf dieselben zwei Dinge: Änderungen an der Workflow-Logik, die protokolliert und nachvollziehbar sind, sowie kontrollierten Zugriff darauf, wer eine in der Produktion laufende Prüfung bearbeiten darf. Keines von beiden ist optional, sobald eine Prüfung keine persönliche Gewohnheit mehr ist, sondern zu etwas wird, worauf ein Werk in jeder Schicht angewiesen ist. Ein Workflow, der unbeaufsichtigt ausgeführt wird, ist immer noch Code, der auf Produktionsdaten zugreift, und die IT behandelt ihn genau so, unabhängig davon, wer ihn geschrieben hat.
Die Spannung ist real und löst sich nicht von alleine. Analysten wünschen sich eine Prüfung, die sich schnell anpassen lässt, sobald sich ein Spezifikationsgrenzwert ändert, da ein langsamer Änderungsprozess nur dazu verleitet, die Prüfung zu umgehen, anstatt sie zu aktualisieren. Die IT möchte jede dieser Anpassungen aus genau demselben Grund nachvollziehbar haben: Eine nicht nachverfolgte Änderung ist von einem Fehler nicht zu unterscheiden, bis jemand das Gegenteil beweist.
Ein Workflow, der Änderungen zwar einfach, aber unsichtbar macht, stellt keine der beiden Personen zufrieden. Es verlagert das Risiko lediglich von einer Prüfung, die möglicherweise falsch ist, auf eine Prüfung, die von jeder beliebigen Person geändert worden sein könnte, ohne dass es einen Datensatz dazu gibt.
Was die IT von einer Lösung benötigt, ist spezifisch: Änderungen müssen nachvollziehbar und überprüfbar sein, ohne dass jede Anpassung der Spezifikationsgrenzen zu einer Ticket-Warteschlange führt, die Analysten davon abhält, die Prüfung überhaupt aktuell zu halten. Stimmt dieses Gleichgewicht in die eine oder andere Richtung nicht, verliert die Prüfung für jemanden ihre Vertrauenswürdigkeit.
Was die IT tatsächlich prüft, bevor sie einem Workflow vertraut
- Wer den Workflow, der die Prüfung enthält, anzeigen, bearbeiten oder ausführen kann, nicht nur, wer den resultierenden Bericht anzeigen kann.
- Ob eine Änderung an der Prüflogik, wie beispielsweise ein Spezifikationsgrenzwert, protokolliert wird, einschließlich der Angabe, wer sie vorgenommen hat und wann.
- Ob eine fehlgeschlagene Prüfung an einer Stelle sichtbar ist, an der ein Administrator sie sehen kann, und nicht nur im eigenen Ausführungsprotokoll des Analysten.
- Wie lange diese Änderungshistorie aufbewahrt wird und ob sie für eine Compliance-Prüfung exportiert werden kann.
Der Werksgeschäftsführer sieht nicht den Scheck, sondern nur die Zahl, die er gestoppt hätte
Der Werksgeschäftsführer sieht die Prüfung nie, sondern nur die Zahl, die sie erfasst oder übersehen hätte. Die Vorlage einer wöchentlichen Ertragszahl an die Unternehmensleitung bedeutet, dem dahinterliegenden Workflow blind zu vertrauen, ohne jede Möglichkeit zu wissen, ob die Zahl tatsächlich überprüft wurde, bevor sie in die Präsentation gelangte.
Genau das ist im Werk von Dana passiert. Drei aufeinanderfolgende Wochen mit steigenden First-Pass-Yield-Zahlen flossen in die Prüfung durch die Führungsebene ein, bevor eine Kundenbeschwerde über fehlerhafte Einheiten ein manuelles Audit erzwang. Das Audit deckte die Sensorlücke erst im Nachhinein auf; zu diesem Zeitpunkt war die nach oben gemeldete Zahl bereits seit drei Prüfungszyklen falsch.
Das Muster ist nicht auf ein einziges Werk beschränkt. Eine Deloitte-Umfrage aus dem Jahr 2025 unter 600 Führungskräften der Fertigungsbranche ergab, dass die Skalierung von Smart-Manufacturing- und KI-Initiativen branchenweit durch schlechte Datenqualität, mangelhafte Governance und fragmentierte Systeme eingeschränkt wird.
Auch auf der Führungsebene zeigt sich, was auf dem Spiel steht. Eine Studie des IBM Institute for Business Value aus dem Jahr 2025 ergab, dass 43 % der Chief Operations Officers Probleme mit der Datenqualität als ihre wichtigste Datenpriorität einstufen – vor fast allem anderen, was um ihre Aufmerksamkeit konkurriert.
Ein Werks-Geschäftsführer interessiert sich nicht für die Mechanismen einer Prüfung. Die einzige Frage, die bei einem Führungskräftemeeting zählt, ist, ob die Zahl, die ihnen vorliegt, bereits verifiziert wurde, und nicht, ob das Team im Nachhinein erklären kann, warum dies nicht der Fall war.
Eine falsche Ertragszahl, die drei Wochen lang nach oben gemeldet wurde, ist aus der Sicht eines Werksgeschäftsführers kein Datenproblem. Es ist ein kundenbezogener Qualitätsmangel und ein Glaubwürdigkeitsproblem, wenn das Team das nächste Mal überhaupt eine Zahl meldet. Dieses Vertrauen wieder aufzubauen, dauert weitaus länger als die drei Wochen, die es brauchte, um es zu verlieren.
Wo die drei Interessen übereinstimmen, und wo nicht
Alle drei Stakeholder werden von derselben zugrunde liegenden Sache bedient: einer Prüfung, die jedes Mal automatisch abläuft, ohne davon abzuhängen, ob ein Analyst vor einer Frist daran gedacht hat, nachzusehen. So viel ist gemeinsame Basis.
Worin sie sich unterscheiden, ist, was jede Seite darüber sehen muss. Wenn eine Prüfung für einen Analysten schnell anpassbar gemacht wird – etwa wenn sich eine Spezifikationsgrenze ändert oder ein Sensor ausgetauscht wird –, kann dies direkt den Anforderungen der IT zuwiderlaufen, dass dieselbe Änderung überprüft werden kann und nachvollziehbar sein muss. Geschwindigkeit und Nachverfolgbarkeit ziehen in entgegengesetzte Richtungen, es sei denn, beides wird von vornherein zugleich berücksichtigt.
Die zweite Reibung besteht zwischen dem Analysten und dem Werksgeschäftsführer. Eine Führungskraft möchte eine eindeutige Zahl oder einen klaren Hinweis darauf, dass etwas fehlgeschlagen ist, und nicht den Detaillierungsgrad, den ein Analyst oder die IT benötigt, wenn eine Prüfung tatsächlich fehlschlägt. Einem Geschäftsführer ein Ausführungsprotokoll zu übergeben, löst gar nichts, und einem Analysten nur ein Pass- oder Fail-Flag zu übergeben, löst ebenfalls nichts; jeder Stakeholder benötigt einen anderen Ausschnitt desselben Ereignisses.
Daraus ergibt sich eine Anforderung, kein ausgehandelter Kompromiss: Die Prüfung selbst muss für alle identisch sein, automatisiert und nach demselben Zeitplan ablaufen, unabhängig davon, wer zusieht. Was sich unterscheidet, ist, was die jeweiligen Stakeholder dazu sehen: ein Bearbeitungsprotokoll für die IT, ein Bestanden- oder Nicht-bestanden-Flag für den Geschäftsführer, eine verifizierte Zahl, auf die der Analyst aufbauen kann.
Unkontrollierte Datenqualitätsprobleme verursachen reale, quantifizierte Kosten. Laut Gartner verlieren Unternehmen durchschnittlich mindestens 12,9 Millionen US-Dollar pro Jahr. Diese Zahl gilt branchenübergreifend gerade deshalb, weil die zugrunde liegende Ursache dieselbe ist wie in Danas Werk: Niemand ist für die Prüfung selbst verantwortlich, sodass die Kosten eines Fehlers erst nachgelagert von der Person entdeckt werden, die die fehlerhafte Zahl am Ende vor sich hat.
Führt man das Szenario noch einmal aus, hätte dieselbe eingebettete Prüfung allen dreien gedient. Es hätte Dana die Zeilenzählung und Schwellenwertüberprüfung ermöglicht, die sie früher manuell durchgeführt hat. Es hätte der IT eine Änderung an der Spezifikationsgrenzen-Logik geliefert, die an einer anderen Stelle als in ihrem Posteingang sichtbar gewesen wäre. Und es hätte dem Werksgeschäftsführer eine Ertragszahl geliefert, die bereits geprüft war, statt einer Zahl, bei der erst jemand ein Problem bemerken musste.
Was eine Lösung für alle drei erfüllen muss
Die Anforderung ist bei allen drei Stakeholdern dieselbe. Die Prüfung muss sich im Workflow selbst befinden, nicht in der Gewohnheit einer Person, daran zu denken, nachzusehen, und sie muss nach einem Zeitplan ausgeführt werden, der nicht davon abhängt, dass jemand sie anfordert.
Das bedeutet, dass der Workflow eine Möglichkeit bieten muss, Spalte für Spalte zu prüfen, ob eingehende Daten vollständig und gültig sind, bevor sie verwendet werden, sowie eine Möglichkeit, häufige Probleme wie Nullwerte, überflüssige Zeichen und uneinheitliche Groß-/Kleinschreibung als Teil desselben Prozesses zur Datenaufbereitung zu beheben – und nicht in einem separaten manuellen Schritt. Dieser zweite Teil ist das, was Datenbereinigung in der Praxis tatsächlich bedeutet: die Daten zu korrigieren und nicht nur zu kennzeichnen.
Die Anforderung der IT von vorhin war eindeutig: ein Datensatz darüber, wer die Prüfung wann geändert hat und der sich im Nachhinein belegen lässt. Plattformen wie Alteryx One erfüllen diesen Bedarf durch Audit-Protokolle, die Änderungen an der Workflow-Logik als protokollierte, zuordenbare und exportierbare Ereignisse nachverfolgen – getrennt vom eigentlichen Bestanden- oder Nicht-Bestanden-Ergebnis der Prüfung und nicht als Ersatz dafür.
Teams, die diese erste Ebene noch aufbauen, können mit diesen Ressourcen zur Datenvorbereitung beginnen, die detaillierter auf die Mechanismen eingehen.
Diese Prüfung wird erst dann zur Routine, wenn nicht mehr darauf gewartet werden muss, dass jemand sie manuell ausführt. Derselbe Workflow kann für jede Schicht für eine automatische Ausführung geplant werden, sodass sich die Profilierungs- und Bereinigungssequenz von selbst wiederholt, anstatt davon abzuhängen, dass jemand an die Prüfung denkt.
Ein Tool zur spaltenweisen Profilierung kann Nullen, Leerwerte und Werte außerhalb des gültigen Bereichs anzeigen, während die Daten den Workflow durchlaufen, was das ursprüngliche Problem des Analysten direkt löst: zu sehen, was tatsächlich vorhanden ist, bevor man nachgelagert darauf vertraut.
Ein dedizierter Bereinigungsschritt übernimmt gängige Korrekturen wie Nullwerte, überflüssige Leerzeichen und uneinheitliche Groß- und Kleinschreibung als Teil desselben Prozesses und nicht als separate Aufgabe, die kurz vor einer Frist eingeschoben wird.
Gemeinsame Argumentation
Dies als „ein neues Tool für Datenqualität“ darzustellen, lädt zu einer genauen Budgetprüfung und vagem Widerstand ein. Das stärkere Argument stützt sich auf den konkreten Fehler, den das Szenario aufgedeckt hat: drei Wochen, in denen eine falsche Zahl die Prüfung durch die Führungsebene erreichte, und die konkrete Lösung, die es erfordert: Prüfungen, die im Workflow eingebettet und für die Ausführung geplant sind, anstatt dass man daran denken muss.
Das Argument des Analysten sollte die Fehlerart selbst quantifizieren, nicht ein vages Branchenaggregat. Eine verpasste Prüfung kostet nicht abstrakt „Datenqualität“. Sie kostet die Einheiten einer gesamten Schicht, die mit falschen Toleranzen gefertigt wurden, bevor es jemand bemerkt – mit Nacharbeit oder Ausschuss als Folge –, plus die Stunden, die danach aufgewendet werden, um zu rekonstruieren, was an der Linie tatsächlich passiert ist.
Die Anforderung der IT ist kleiner, als es sich anhört. Anstatt von jemandem zu verlangen, der Tabellenkalkulation des Analysten blind zu vertrauen, verlangt sie, die Prüflogik und ihren Änderungsverlauf einzusehen – eine engere und leichter zu beantwortende Anfrage als eine vollständige Plattformüberprüfung und genau das, was die IT vor der Freigabe tatsächlich beantwortet haben muss. So formuliert verlagert sich die Diskussion von einer allgemeinen Sicherheitsprüfung hin zu einer spezifischen, abgegrenzten Frage, der die IT zustimmen kann.
Das Kernargument der Führungskraft dreht sich um Risiken, nicht um Initiativen. Dies ist kein neues Projekt, das um Budgetaufmerksamkeit konkurriert. Es geht um Risikominimierung bei einer Kennzahl, die das Werk bereits jede Woche nach oben meldet, die schon einmal zu einer Kundenbeschwerde geführt hat, und ein weiterer Fehler wäre beim zweiten Mal noch schwerer zu erklären.
Zusammengenommen laufen diese drei Punkte auf eine einzige Anforderung hinaus: eine Änderung der Ausführung des Yield-Workflows, die jedem Stakeholder genau das bietet, was im vorherigen Abschnitt beschrieben wurde. Die IT erhält einen Prüfpfad, der Analyst erhält eine geplante Überprüfung und der Geschäftsführer erhält eine verifizierte Zahl.
Diese Änderung direkt zu testen, ist der schnellste Weg, um festzustellen, ob sie einem echten Produktionszeitplan standhält. Die kostenlose Testversion von Alteryx One läuft 30 Tage – lang genug, um die Prüfung zu erstellen, zu planen und mitzuerleben, wie sie die nächste fehlerhafte Schicht abfängt, bevor diese einen Bericht erreicht.