25 Dinge, die Sie in einer OEE‑Software‑Demo testen sollten, die Anbieter Ihnen nie von sich aus zeigen

OEE-Software-Demos sind geskriptete Erlebnisse. Anbieter zeigen ihre Plattform von ihrer besten Seite, mit vorab geladenen sauberen Daten, idealen Produktionsszenarien und Demo-Umgebungen, in denen jede Funktion reibungslos funktioniert.

Was sie nicht zeigen, ist, wie das System mit unordentlichen realen Bedingungen umgeht: der Bediener, der vergisst, ein Stillstandsereignis zu schließen, die SPS, die mehrdeutige Zustandsmeldungen sendet, der Produktionslauf, der einen Schichtwechsel überlappt, oder der Bericht, der die Zusammenführung von Daten aus drei verschiedenen Linien mit unterschiedlichen Produktstrukturen erfordert.

Die Lücke zwischen Demo-Leistung und Leistung in der realen Welt ist die häufigste Quelle für das Bedauern von OEE-Softwarekäufern. Hersteller, die auf Basis polierter Demos kaufen, ohne Randfälle zu testen, stellen oft nach der Implementierung fest, dass das System ihre spezifischen Produktionsszenarien anders handhabt, als die Demo suggeriert hat.

Der Weg, diese Lücke zu schließen, besteht darin, eigene Szenarien zu Demos mitzubringen, und die Anbieter zu verpflichten zu zeigen, wie ihr System mit den spezifischen Randfällen und Arbeitsabläufen in Ihrem Werk umgeht, nicht mit den idealen Fällen, für die ihre Demo-Umgebung ausgelegt ist.

Die Strukturierung Ihrer Demo-Evaluation um eine feste Checkliste von Szenarien macht den Anbieter-Vergleich außerdem zuverlässiger. Wenn jeder Anbieter dieselben 25 Szenarien demonstriert, können Sie deren Ansätze nebeneinander vergleichen, anstatt ein „Downtime-Management“-Feature eines Anbieters mit einem „Verlustanalyse“-Feature eines anderen Anbieters zu vergleichen, das mit anderen Daten und anderen Arbeitsabläufen demonstriert wurde. Die Checkliste erzwingt Vergleichskonsistenz, die ansonsten erfahrene Evaluatoren manuell über mehrere Sitzungen hinweg aufrechterhalten müssten.

Datenerfassungsszenarien: (1) Zeigen Sie, wie eine Maschinenzustandsänderung ohne Bedienereingriff erfasst wird, demonstrieren Sie die SPS‑Signal‑zu‑OEE‑Zustands‑Pipeline in Echtzeit. (2) Zeigen Sie, was passiert, wenn ein SPS‑Signal mehrdeutig ist oder ein Sensor kurzzeitig getrennt wird, wie geht das System mit Datenlücken um?

(3) Demonstrieren Sie, wie ein Bediener zwei Stunden nach dem Ereignis eine Stillstandsursache hinzufügt, ist eine nachträgliche Kategorisierung möglich, und gibt es einen Audit‑Trail? (4) Zeigen Sie einen Produktionslauf, der die Mitternacht überschreitet, wie geht das System mit Schichtgrenzen um?

(5) Demonstrieren Sie einen Produktwechsel, der 90 Minuten dauert, wird der Rüstvorgang separat vom Ausfallstillstand erfasst?

OEE‑Berechnungsszenarien: (6) Zeigen Sie die OEE für eine Linie, die in derselben Schicht zwei Produkte mit unterschiedlichen Taktzeiten produziert, wie werden produktbezogene Sollwerte gehandhabt? (7) Zeigen Sie, wie geplante Wartung während der Produktionszeit die Verfügbarkeit beeinflusst, wird sie aus der OEE‑Berechnung ausgeschlossen oder als geplante Stillstandszeit ausgewiesen?

(8) Demonstrieren Sie die Berechnung der Qualitätsrate, woher stammen Ausschussdaten und wie wird Nacharbeit getrennt von Schrott behandelt? (9) Zeigen Sie, was passiert, wenn der OEE‑Wert für eine Schicht 0 % beträgt, geht das System mit Randfällen fehlerfrei um?

(10) Demonstrieren Sie die Aggregation der OEE über drei Linien mit unterschiedlichen Schichtplänen, wie wird Mehrlinien‑OEE berechnet?

Reporting‑ und Usability‑Szenarien: (11) Zeigen Sie ein Pareto der Stillstandsursachen der letzten 30 Tage, kann es nach Schicht, Produkt und Anlagenkategorie gefiltert werden? (12) Demonstrieren Sie den Aufbau eines benutzerdefinierten Berichts, wie lange dauert es, einen neuen Bericht von Grund auf ohne Hilfe des Anbieters zu erstellen?

(13) Zeigen Sie die Mobile‑App auf einem realen Gerät im Raum, ist es eine native App oder eine mobile Web‑Ansicht? (14) Demonstrieren Sie das Auslösen einer Benachrichtigung und den Empfang durch einen Vorgesetzten, wie hoch ist die tatsächliche Latenz?

(15) Zeigen Sie einen Massenexport von 12 Monaten Stillstandsdaten, wie lange dauert er und in welchem Format werden die Daten ausgegeben?

Integrations‑ und Administrationsszenarien: (16) Zeigen Sie eine Live‑Demo, in der das OEE‑System Daten von einer Test‑SPS via OPC‑UA empfängt, keine Simulation, eine echte Verbindung. (17) Demonstrieren Sie die Erstellung einer neuen Produktionslinienkonfiguration ohne Einbeziehung des Anbieters, wie komplex ist die Einrichtung?

(18) Zeigen Sie, wie ein neuer Benutzer erstellt und einer bestimmten Linie und Rolle zugewiesen wird. (19) Demonstrieren Sie die Konfiguration von Single Sign‑On für Ihren Identity Provider. (20) Zeigen Sie, wie eine Liste von Stillstandsursachencodes aktualisiert wird, wenn sich die Taxonomie ändert. (21) Zeigen Sie das System während eines simulierten Netzausfalls, funktioniert das Edge‑Buffering?

(22) Demonstrieren Sie die API, führen Sie vor Ort einen Live‑API‑Aufruf aus, um die letzten 24 Stunden OEE‑Daten abzurufen. (23) Zeigen Sie, wie das System nach 2 Jahren Daten aussieht, gibt es Leistungsabfall? (24) Bitten Sie den Anbieter, Ihnen ein Kundensupport‑Ticket der letzten 6 Monate und dessen Lösung zu zeigen.

(25) Zeigen Sie den Upgrade‑Prozess, wie werden neue Releases ausgerollt und welcher Stillstand ist erforderlich?

Senden Sie die Checkliste mit 25 Szenarien eine Woche vor der Demo an die Anbieter und bitten Sie sie, sich darauf vorzubereiten, jedes einzelne Szenario zu demonstrieren. Beobachten Sie ihre Reaktion genau, Anbieter, die bei bestimmten Szenarien Einwände äußern („das können wir nicht in einer Demo‑Umgebung zeigen“), signalisieren eine Kompetenzlücke. Anbieter, die die Herausforderung annehmen und vorbereitet erscheinen, haben mehr Vertrauen in die reale Leistungsfähigkeit ihrer Plattform.

Werten Sie während der Demo jedes Szenario auf einer einfachen Skala von 0, 2: 0 (nicht demonstriert oder Funktion nicht verfügbar), 1 (demonstriert mit erheblichen Vorbehalten oder Umgehungslösungen), 2 (sauber und glaubwürdig demonstriert).

Machen Sie Notizen zu den konkreten Nachweisen für jede Bewertung, was der Anbieter gezeigt hat, welche Einschränkungen erwähnt wurden und welche Anschlussfragen bestehen. Diese Notizen ergeben ein Bewertungsprotokoll der Demo, das mit Mitgliedern des Bewertungsteams geteilt werden kann, die nicht an der gesamten Sitzung teilnehmen konnten.

Nach der Demo fordern Sie für alle nicht demonstrierten Szenarien eine schriftliche Stellungnahme an, in der der Anbieter dokumentiert, wie sein System mit dem konkreten Szenario umgeht.

Schriftliche Antworten auf Demo‑Lücken schaffen vertragliche Bezugspunkte: Wenn ein Anbieter schriftlich behauptet, sein System behandele ein Szenario auf eine bestimmte Weise, und es nach der Inbetriebnahme nicht so funktioniert, haben Sie eine Dokumentation der Falschdarstellung.

Diese Dokumentation veranlasst zudem das Vertriebsteam des Anbieters, auf Genauigkeit statt auf Optimismus zu achten, was die Verlässlichkeit ihrer Antworten tendenziell erhöht.