Ein Störmelde­analyse­system für die Fahrzeug­montage entwickeln

In einer Fahrzeug­montage entsteht bei jeder Störung eine Meldung, und parallel läuft die Zählung der gefertigten Stück. Beides liegt vor, beides wird nicht zusammengeführt. Damit fehlt der Anlagen­verantwortung genau die Grundlage, auf der sie arbeiten muss: Wie lange steht welche Anlage tatsächlich, welcher Anteil der Taktzeit geht dabei verloren, und welche Störungsarten wiegen über den Monat am schwersten? Eine einzelne Meldung sagt darüber nichts. Erst die Summe über Zeit, Anlage und Störungsart macht daraus eine Aussage — und die entsteht nicht von selbst, weil zwischen der Meldung im Anlagensystem und einer belastbaren Auswertung eine ganze Verarbeitungs­kette liegt. Der Auftrag ist deshalb eine Anwendung zur Steuerung im Anlagenbau, mit einer vom Werk selbst geschriebenen Anforderungs­definition als Grundlage und einem förmlichen Abnahme­verfahren am Ende.

Die aktive Stördauer ist der ganze Punkt. Zwischen dem Eintreffen einer Meldung und ihrer Quittierung liegt eine Zeitspanne, und die ist nicht die Zeit, in der die Anlage stand. Wer beides gleichsetzt, erzeugt eine Auswertung, die aussieht wie eine Kennzahl und keine ist — und die schlimmstenfalls in eine Investitions­entscheidung eingeht. Die Berechnung dieser Größe war deshalb kein Detail der Verarbeitung, sondern ihr Kern.

Eine Korrektheits­prüfung gehört in die Kette, nicht in die Nachschau. Automatische Daten­übernahme scheitert nicht laut, sondern leise: Ein Export bricht ab, ein Format ändert sich, und die Auswertung läuft weiter, nur mit weniger Daten. Deshalb liegen Ausnahmebehandlung, Protokollierung und eine eigene Prüfung auf Korrektheit im System selbst. Der Unterschied zeigt sich nie am guten Tag.

Der Störort geht durch die ganze Kette, nicht nur in die Anzeige. Als die Auswertung mehrere Montagelinien umfassen sollte, war die naheliegende Lösung ein Filter in der Oberfläche. Richtig war das Gegenteil: Der Störort wurde in den Meldungsdaten, in den Tabellen und in der Verarbeitung ergänzt und erst danach in den Ansichten. Eine Größe, die man nur vorn hinzufügt, stimmt in jeder Summierung dahinter nicht mehr.

Die dritte Erweiterung kam von den Anwendern, nicht von uns. Zwei Jahre nach der Abnahme entstand eine Liste von Verbesserungen, die alle dieselbe Herkunft haben: Menschen, die täglich mit der Auswertung arbeiten und wissen, welcher Klick fehlt. Frei wählbare Zeiträume, die Summe der Störungen, Takte und Zeiten nebeneinander, gruppierte Kurven. Das ist die unspektakulärste und verlässlichste Quelle für Weiter­entwicklung, und sie sprudelt erst, wenn ein System lange genug läuft.

Die Spezifikation kam vom Werk, und das verschiebt den Schwerpunkt der Arbeit. Anders als in Vorhaben, in denen wir die Anforderungen erst erheben, lag hier eine freigegebene Anforderungs­definition vor — mit funktionalen und nicht funktionalen Anforderungen, einem Rechte- und Rollenkonzept, der Herkunft der Daten und der Logik ihrer Auslegung. Die eigentliche Arbeit ist dann nicht mehr, herauszufinden, was gebraucht wird, sondern zu benennen, was in dieser Beschreibung noch nicht entschieden ist. Diese Lücken früh anzusprechen, statt sie während der Umsetzung stillschweigend zu füllen, entscheidet darüber, ob am Ende ein Ergebnis steht, das passt — oder eines, über das man streitet.