„Unsere Daten reichen nicht.“ Das ist der häufigste Grund, mit KI in der Instandhaltung gar nicht erst anzufangen. Fast immer ist damit das falsche Problem gemeint.
Meist geht es um uneinheitliche Kategorien. Drei Personen ordnen denselben Fehler auf drei verschiedene Arten ein. Die Hälfte der Arbeitsaufträge steht unter einer allgemeinen Überschrift, die nie jemand verfeinert hat. Die Begriffe haben sich verschoben, als der letzte Schichtleiter gegangen ist. Wenn Sie die Daten verteidigen müssten, haben Sie genau das vor Augen, wenn Sie sagen, dass sie nicht reichen.
Mit dieser Art von Unordnung kommen Sie heute zurecht. Mit etwas anderem, das meist weniger Aufmerksamkeit bekommt, nicht. Ob Sie das eine vom anderen unterscheiden können, entscheidet darüber, ob ein Projekt starten kann.
Was KI in der Instandhaltung verzeiht: fehlende Struktur
Weggefallen ist die Anforderung an die Struktur.
Der alte Ansatz verlangte, dass jeder Nutzer bei der Eingabe alles richtig einordnet: die richtige Fehlerklasse, das richtige Bauteil, die richtige Ursache, aus einer Auswahlliste, am Ende einer Schicht. Leonard Lin, Produktmanager für Maintmaster Manufacturing Intelligence, sagt ohne Umschweife, wie gut das funktioniert hat: „Das macht niemand, das ist viel zu viel Aufwand.“
Pflichtfelder für Kategorien werden ausgefüllt. Richtig ausgefüllt werden sie nicht. Gewählt wird die erste Option, die halbwegs passt. Die Systematik, die Sie entworfen haben, zeigt am Ende nur, was oben in der Liste stand.
Genau deshalb lassen sich schwach strukturierte Daten heute auswerten. Freitext lässt sich lesen. Ihre Klassifizierung muss weder vollständig noch einheitlich noch besonders gut sein, weil die Analyse die Bedeutung nicht mehr aus ihr bezieht.
Also: uneinheitliche Kategorien, Begriffe, die abdriften, ein Sammeltopf, in dem viel zu viel landet. Verziehen.
Was KI nicht verzeiht: Lücken
Hier liegt die Grenze, und mit Ordnung hat sie nichts zu tun. Es geht darum, ob überhaupt etwas aufgeschrieben wurde.
Nehmen Sie vier Abschlussvermerke zum selben Fehler. Ungefähr diese Bandbreite finden Sie in jedem System, das schon ein paar Jahre läuft:
| Der Abschlussvermerk | Was er hergibt |
|---|---|
| Nichts. Nichts belegt, dass es passiert ist. | |
| „Erledigt.“ | Eine Zählung, sonst nichts. |
| „Lager getauscht.“ | Was getan wurde. Nicht, was defekt war, also auch nicht, ob es geholfen hat. |
| Lager auf der Antriebsseite festgefressen, getauscht, neu gefettet | Was defekt war und was getan wurde. Verwertbar. |
Nur aus dem letzten lässt sich etwas lernen, und dafür reichten acht Wörter.
Der dritte ist der interessante Fall. Er sieht aus wie ein echter Eintrag und würde ein internes Audit am ehesten bestehen. Er sagt Ihnen, dass etwas getan wurde. Er sagt nicht, welches Problem damit behoben werden sollte. Deshalb können Sie auch ein halbes Jahr später nicht sagen, ob der Lagertausch richtig war oder ob dieselbe Fehlausrichtung still und leise ein Lager pro Quartal frisst.
Was die leeren Einträge kosten, lässt sich genau sagen. Noch einmal Leonard:
„Dann weiß man, dass die Probleme da sind, aber nicht, wie man sie löst, und dann kann man nicht daraus lernen.“
Achten Sie darauf, was übrig bleibt und was nicht. Die Zählung bleibt. Sie sehen weiterhin, dass diese Anlage elfmal ausgefallen ist. Sie können die Kennzahl zur Ausfallrate bilden und auf ein Dashboard stellen. Lernen können Sie daraus nicht: nicht, was defekt war, nicht, was geholfen hat, und nicht, ob dieselbe Reparatur elfmal an einem Fehler gemacht wurde, den nie jemand diagnostiziert hat.
Trotzdem ist das ein sehr guter Ausgangspunkt. Ein großer Teil der Instandhaltungshistorie ist in diesem Zustand, und er verschafft Ihnen bereits Transparenz.
Die Ereignisse sind in einem System, und jemand schließt die Aufträge ab. Das ist der teure Teil, und er ist schon erledigt. Mit dieser Transparenz können Sie Gespräche über Verbesserungen auf Basis von Daten führen. Sie haben Daten, mit denen Sie begründen können, warum Sie sich auf Thema X konzentrieren wollen. Der nächste Schritt, „Lösung dazuschreiben“, ist ein logischer Schritt, den das Team gut mitgehen kann. Ihr Projekt zur Verbesserung der Daten kommt damit von selbst in Gang.
Die Untergrenze – und in welche Richtung sie gilt
Bei der Qualität von Kommentaren ist KI heute sehr leistungsfähig. Es gibt aber auch eine einfache Untergrenze. Dafür gibt es einen Test, den Sie an einem Nachmittag machen können, ganz ohne Werkzeuge. Leonards Version:
„Wenn ein Mensch es nicht versteht, dann ist die Software auch nicht besser.“
Lesen Sie eine Stichprobe der Abschlussvermerke aus dem letzten Monat. Wenn Sie nicht erkennen können, was passiert ist, kann es auch sonst nichts.
Leonard hat die Grenze seiner eigenen Regel später genau aufgeschrieben. Es lohnt sich, sie präzise wiederzugeben, weil gerade dieser Teil oft falsch verstanden wird. Die Regel gilt nur in eine Richtung. Wenn ein Mensch eine Notiz nicht lesen kann, hat die KI keine Chance. Es gibt aber weiterhin Fälle, in denen ein Mensch eine Notiz lesen kann und die KI nicht.
Für Menschen lesbar ist also eine Untergrenze, keine Garantie. Sie zeigt zuverlässig, was unbrauchbar ist. Sie bestätigt nicht, dass alles darüber funktioniert. Wer die Regel als unsere Notizen sind lesbar, also passt alles versteht, liest sie verkehrt herum. Dann entsteht eine Erwartung, die Ihre Daten vielleicht nicht erfüllen.
Leonards zweite Grenze ist älter und hat sich nicht verschoben: „Wenn man Ungenauigkeiten in den Berichten hat, wird es keine gute Analyse.“ Eine niedrigere Hürde für die Struktur ist keine niedrigere Hürde für die Wahrheit. Ein Eintrag, der das Falsche sagt, ist schlimmer als ein dünner. Ein dünner Eintrag fällt auf, ein falscher nicht.
Wo Sie tatsächlich stehen
Die nützliche Frage ist nicht, ob Ihre Daten gut sind, sondern wo sie schlecht sind. Das lässt sich ohne Audit beantworten.
Manufacturing Intelligence misst, welcher Anteil der Notizen brauchbar ist, und schlüsselt das nach Abteilung und Schicht auf. Sie bekommen eine Landkarte statt eines Urteils: welche Bereiche, welche Teams, wo die Dokumentation dünn wird. So wird aus einem Datenqualitätsprogramm ein Gespräch mit drei Schichtleitern, die Sie beim Namen kennen.
Eine ehrliche Einschränkung. Die Karte zeigt, wo schwach dokumentiert wird. Ob Teams danach besser werden, haben wir nicht nachverfolgt, deshalb stellen wir es nicht als Ergebnis dar. Die Karte zeigt, wo Sie hinschauen sollten. Ändern, wie dokumentiert wird, muss trotzdem jemand vor Ort.
Wenn die Analyse mit dünnen Einträgen arbeitet, sagt Ihnen das System, dass es unsicher ist. Es zeigt geringe Sicherheit an, statt eine dünne Antwort als belastbar darzustellen. Eine Garantie für Richtigkeit ist das nicht.
Niemand hat perfekte Daten
Nach alldem bleibt ein Einwand, und er wird meist laut ausgesprochen: Wir haben keine perfekten Daten.
Die hat niemand, und Leonard sagt genau, warum:
„Niemand hat perfekte Daten, weil sie nie jemand genutzt hat. Natürlich sind sie dann nicht gut.“
Das ist eine Aussage über Ursache und Wirkung, und sie läuft andersherum, als das Problem sonst beschrieben wird. Einträge werden nicht erst gut und dann genutzt. Sie werden genutzt, und erst das bringt jemanden dazu, sie ordentlich zu schreiben. Daten, die nie jemand gelesen hat, hatte auch nie jemand einen Grund zu verbessern.
Deshalb können Sie mit mittelguten Daten anfangen. Nehmen wir an, 50 % Ihrer Abschlussvermerke enthalten Problem und Lösung. Ein anderer Fall: Alle nennen das Problem, und keiner nennt die Lösung. Keine der beiden Mengen würde jemand gut nennen. In beiden sind die wichtigen Themen trotzdem in der Stichprobe enthalten und sichtbar, denn wichtig sind die Themen, die immer wieder auftreten. Was immer wieder auftritt, landet in einer Stichprobe dieser Größe. Das Ergebnis ist brauchbar und zeigt die Richtung: Es weist auf die richtigen Anlagen und die richtigen wiederkehrenden Fehler hin, ohne sie genau zu messen. Genau das brauchen Sie, wenn Sie entscheiden müssen, wo Sie zuerst hinschauen.
Es ändert auch, wie die Dokumentation besser wird. Ein Team, das sieht, dass seine Notizen genutzt werden, hat einen Grund, sie zu schreiben. Ein Team, das Notizen in einem System ablegt, das niemand liest, hat keinen. Ob das tatsächlich so kommt, haben wir, wie gesagt, nicht nachverfolgt. Es ist ein Argument dafür, früh anzufangen, kein Ergebnis, das wir Ihnen zeigen können.
Fangen Sie also an, die Daten zu nutzen, wenn Sie auf halbem Weg sind. Lassen Sie Manufacturing Intelligence die Dokumentation von dort aus voranbringen, statt zu warten, bis alles stimmt.
Die drei Fragen
Stellen Sie diese Fragen zu einer Stichprobe Ihrer eigenen abgeschlossenen Arbeitsaufträge, in dieser Reihenfolge:
- Gibt es überhaupt einen Eintrag? Kein Eintrag ist kein Problem der Datenqualität. Es fehlen schlicht Daten, und das ist ein anderes Projekt.
- Kann ein Mensch erkennen, was passiert ist und was getan wurde? Wenn nicht, wird nichts besser, was danach kommt. Das ist die Untergrenze.
- Stimmt, was dort steht? Einen Blick wert, aber selten der Punkt, an dem ein Team feststeckt.
Das ist kein Umfrageergebnis, und wir geben es auch nicht als eines aus. Wir hören es in Demo-Gesprächen: Teams kommen mit der Annahme, sie hätten ein Problem mit Frage drei. Was sie dann beschreiben, ist Frage eins. Kein falscher Eintrag, sondern gar keiner: Papier, eine Tabelle, ein Schichtbuch, ein Gespräch bei der Schichtübergabe.
Was Sie zuerst angehen
Jede Frage führt zu einem anderen ersten Schritt. Keiner davon ist eine Aufräumaktion, die Sie abschließen müssen, bevor Sie anfangen.
Frage eins nicht bestanden: Bringen Sie das Ereignis in ein System. Nicht in ein besseres System, sondern überhaupt in eines. Leonard legt die Latte für den ersten Schritt bewusst niedrig: Das System „muss nicht unseres sein“. Wichtig ist, dass das Ereignis erfasst wird, wenn es passiert, und nicht später rekonstruiert. In der Instandhaltung heißt das: eine Instandhaltungssoftware statt einer Tabelle, also weg von Stift, Papier und Excel. Bei Stillständen an der Linie heißt das: Produktionszähler, die Ereignisse automatisch erfassen, statt eines Schichtbuchs, das am Ende des Tages geschrieben wird. Beides ist kein KI-Projekt. Beides macht eines erst möglich.
Frage zwei nicht bestanden: Ändern Sie die Gewohnheit, nicht das Schema. Hier zahlt sich die Karte zur Notizqualität aus. Sie bitten drei Schichtleiter um zwei kurze Satzteile statt eines einzelnen Wortes. Eine neue Systematik brauchen Sie dafür nicht.
Frage drei nicht bestanden: Probieren Sie es aus und sehen Sie, wo Sie stehen. Das müssen Sie nicht klären, bevor Sie anfangen. Manufacturing Intelligence gibt Ihnen Hinweise, wo die Schwachstellen liegen.
Es lohnt sich, die Reihenfolge zu benennen, die sich damit umkehrt. Die meisten Unternehmen kommen von der Analyse her. Jemand will ein Dashboard oder eine Vorhersage, und die Daten stehen dabei im Weg. Leonard unterscheidet zwischen „jemandem, der die Daten analysieren will, und dem Digitalisieren Ihrer Daten. Analysieren können Sie danach.“ Das sind zwei Projekte, und sie werden ständig verwechselt.
Wenn Sie wichtige KPIs in der Instandhaltung schon eine Weile verfolgen, fällt es Ihnen leichter, die drei Fälle auseinanderzuhalten. Die Kennzahl liefert die Zählung, und diese Fragen zeigen, ob etwas dahintersteht.
Nehmen Sie sich zwanzig Abschlussvermerke vor und lesen Sie sie. Der Anteil, der an Frage zwei scheitert, ist Ihr tatsächlicher Ausgangspunkt. Den kennen Sie jetzt, ohne etwas gekauft zu haben. Scheitern die meisten, brauchen Sie kein Datenprogramm. Sie brauchen einen Ort, an dem man direkt bei der Arbeit zwei kurze Satzteile eintippt. Dafür ist Maintmaster CMMS da.
