Ein Proof of Concept (POC) für OEE‑Software dient einem Zweck: das Risiko zu verringern, dass das von Ihnen gekaufte System in Ihrer spezifischen Produktionsumgebung nicht so funktioniert, wie der Anbieter es versprochen hat.
Ein gut gestaltetes POC beantwortet die drei Fragen, die RFP‑Antworten und Demos nicht klären können: Erfasst die Software Daten genau von Ihren spezifischen Maschinen und SPS? Berechnet sie die OEE auf eine Weise, die mit dem Leistungsverständnis Ihres Produktionsteams übereinstimmt? Und können Ihre Bediener sie ohne intensiven fortlaufenden Support nutzen?
Der häufigste POC‑Fehler besteht darin, ihn zu breit anzulegen. Hersteller, die versuchen, OEE‑Software innerhalb eines 30‑Tage‑Zeitraums über mehrere Linien, mehrere Schichten und verschiedene Produkttypen zu pilotieren, landen mit nicht eindeutigen Ergebnissen, zu viele Variablen, zu viel Einrichtungsaufwand und nicht genug Zeit, um eine stabile Datenqualität zu erreichen.
Ein fokussiertes POC auf 1, 3 Produktionslinien, das 2, 3 Wochen stabiler Produktion nach einer einwöchigen Einrichtungsphase abdeckt, liefert zuverlässigere Erkenntnisse als ein weitläufiger Pilot, der nie einen stabilen Zustand erreicht.
Definieren Sie den POC‑Umfang schriftlich, bevor er beginnt.
Das Umfangsdokument sollte festlegen: welche Linien in den Umfang fallen; welche Datenerfassungsmethode verwendet wird (SPS‑Integration, Nachrüstung von Sensoren oder manuelle Erfassung als Backup); welches Produktionsvolumen und welche Produktmischung während des POC‑Zeitraums erwartet werden; welche ERP‑ und CMMS‑Integrationen während des POC aktiv sein werden (falls vorhanden); und welcher Support vom Anbieter für den POC‑Zeitraum zugesagt wird.
Ein Anbieter, der sich nicht vor Beginn des POC schriftlich auf einen Umfang festlegen will, wird den Umfang wahrscheinlich nachträglich neu definieren.
Die POC-Messung sollte vier Dimensionen abdecken: Genauigkeit der Datenerfassung, Zuverlässigkeit der OEE-Berechnung, Akzeptanz durch die Bediener und Systemleistung. Die Genauigkeit der Datenerfassung ist am wichtigsten: Vergleichen Sie die OEE-Werte der Plattform mit Ihren vorhandenen Datenquellen (Produktionszähler, Schichtprotokolle, SCADA-System) für dieselben Schichten.
Eine Abweichung von mehr als 2, 3 % bei den Produktionszahlen oder mehr als 5 Minuten Stillstandszeit pro Schicht deutet auf ein Konfigurationsproblem der Datenerfassung hin, das das Vertrauen in die OEE-Daten nach der vollständigen Einführung untergraben wird.
Die Zuverlässigkeit der OEE-Berechnung wird beurteilt, indem die OEE-Werte der Plattform mit manuellen Berechnungen anhand derselben Rohdaten abgeglichen werden. Wählen Sie 5, 10 Schichten aus dem POC-Zeitraum aus, ziehen Sie die Rohdaten, berechnen Sie die OEE manuell und vergleichen Sie das Ergebnis mit dem der Plattform.
Abweichungen sollten durch dokumentierte Entscheidungen in der Berechnungsmethodik erklärbar sein (z. B. wie geplante Stillstände behandelt werden, wie Mikrostopps klassifiziert werden), unerklärliche Abweichungen deuten auf ein Problem mit der Berechnungslogik der Plattform hin, das fortlaufende Glaubwürdigkeitsprobleme bei Produktionsleitern verursachen wird, die ihre Anlagen gut kennen.
Die Messung der Bedienerakzeptanz während eines 30-tägigen POC konzentriert sich auf die Einhaltung der Stillstandskategorisierung: Welcher Prozentsatz der Stillstandsereignisse wurde von den Bedienern kategorisiert (im Gegensatz zu solchen, die als "unkategorisiert" belassen wurden), und wie lange nach den Ereignissen erfolgte die Kategorisierung?
Ein Zielwert von über 80 % Kategorisierungsrate innerhalb von 2 Stunden nach dem Ereignis ist ein angemessener POC-Benchmark. Liegt die Rate darunter, erzeugt das System eine Pareto-Analyse, die von "unkategorisiertem" Stillstand dominiert wird, was den Hauptzweck der Software zunichte macht.
Wenn die Kategorisierungsraten während des POC niedrig sind, analysieren Sie, ob die Ursache die Komplexität der Bedienoberfläche, unzureichende Schulung oder eine ungeeignete Liste von Stillstandsursachen ist, und testen Sie, ob der Anbieter die Grundursache innerhalb des POC-Zeitraums beheben kann.
Die Go-/No-Go-Entscheidung für einen OEE-Software-POC sollte auf vordefinierten Kriterien beruhen, die vor Beginn des POC vereinbart wurden, nicht auf einer nachträglichen Einschätzung, ob die Lieferantenbeziehung sich positiv anfühlt.
Definieren Sie Go-Kriterien als messbare Schwellenwerte: Datenerfassungsgenauigkeit innerhalb von ±3 % gegenüber dem Ground Truth für mehr als 90 % der Schichten; Kategorisierungsrate von Bediener-Ausfallzeiten über 75 %; mindestens ein erfolgreicher ERP-Integrations-Datentransfer (falls im Umfang); keine Datenverlust-Ereignisse während des normalen Produktionsbetriebs; und Systemverfügbarkeit (Uptime) über 99 %.
Die No-Go-Entscheidung sollte ebenfalls explizit sein. Wenn die Datenerfassungsgenauigkeit in mehr als 20 % der Schichten nicht erreicht wird, oder wenn das System mehr als 2 Stunden Support pro Woche vom Anbieter benötigt, um einen stabilen Betrieb aufrechtzuerhalten, oder wenn Bediener das System trotz Schulung aktiv zu vermeiden beginnen
sind dies Signale dafür, dass die Plattform grundsätzliche Kompatibilitätsprobleme mit Ihrer Umgebung hat, die durch eine längere Einführung wahrscheinlich nicht behoben werden.
Zwischen klarem Go und klarem No-Go liefern die meisten POCs ein „Go mit Auflagen“, das System funktioniert akzeptabel, aber es gibt spezifische Probleme, die vor dem vollständigen Rollout gelöst werden müssen. Dokumentieren Sie diese Auflagen ausdrücklich im POC-Abschlussbericht: welche Probleme identifiziert wurden, was der Anbieter zur Behebung zugesagt hat und bis zu welchem Datum.
Wenn diese Auflagen in vertragliche Verpflichtungen im Kaufvertrag überführt werden, verwandelt das das bedingte Go in eine abgesicherte Entscheidung, werden die Bedingungen nicht erfüllt, haben Sie Anspruch auf Nachbesserung oder Ausstieg. Ohne diese Dokumentation neigen bedingte Probleme dazu, nach dem Kauf fortzubestehen, weil die Dringlichkeit des Anbieters, sie zu lösen, nach Vertragsunterzeichnung verschwindet.
Anmeldung
Blog
