RFP-Vorlage für OEE-Software: 47 Anforderungen und eine gewichtete Bewertungsmatrix

Eine Aufforderung zur Angebotsabgabe (Request for Proposal, RFP) für OEE‑Software verfolgt zwei Zwecke: Sie zwingt Anbieter dazu, auf Ihre spezifischen Anforderungen statt auf ihre Standardpräsentation einzugehen, und sie schafft eine strukturierte Grundlage, um Antworten verschiedener Anbieter vergleichbar zu machen.

Viele Hersteller versenden schlecht strukturierte OEE‑RFPs, entweder zu allgemein (fragt nach einer „OEE‑Berechnungsfähigkeit“, ohne den erforderlichen Detaillierungsgrad anzugeben) oder zu vorschreibend (legt eine technische Architektur fest, die nur Anbieter zulässt, die ihre Plattform auf eine bestimmte Weise aufgebaut haben). Die richtige RFP‑Struktur ist anforderungsorientiert: Welche Ergebnisse Sie benötigen, nicht wie der Anbieter sie liefern muss.

Ein effektives OEE‑Software‑RFP hat sieben Abschnitte. Zuerst eine Unternehmens‑ und Werksübersicht, die den Anbietern Kontext zu Ihrer Produktionsumgebung gibt (Branche, Anzahl der Linien, Maschinentypen, vorhandene IT‑Infrastruktur, ERP‑System). Zweitens die Umfangsdefinition, welche Standorte und Produktionsbereiche für die Initialbereitstellung in‑scope sind und welche später hinzugefügt werden können.

Drittens funktionale Anforderungen, organisiert nach Kategorie (Datenerfassung, OEE‑Berechnung, Reporting, Integrationen, mobiler Zugriff, Alarmierung). Viertens technische Anforderungen, die Bereitstellungsarchitektur, Sicherheit, Integrationsstandards und Datenexport abdecken. Fünftens Implementierungs‑ und Supportanforderungen einschließlich Implementierungsansatz, Schulung und SLA‑Erwartungen.

Sechstens kommerzielle Anforderungen, die Preismodell, Vertragsbedingungen und Lizenzstruktur abdecken. Siebtens Referenzkundenanforderungen, die um Referenzen aus Ihrer Branche und in der Größenordnung Ihrer Werke bitten.

Im Abschnitt funktionale Anforderungen spezifizieren die meisten Hersteller zu wenig. Generische Anforderungen wie „Fähigkeit zur Erfassung von Stillstandszeiten“ sind wenig aussagekräftig, jeder OEE‑Anbieter behauptet das.

Konkrete Anforderungen wie „Das System muss Stillstandsereignisse automatisch über ein SPS‑Signal erfassen, ohne manuelle Eingabe durch das Bedienpersonal, diese in mindestens drei Hierarchieebenen kategorisieren und eine nachträgliche Neukategorisierung innerhalb von 24 Stunden erlauben“ zwingen Anbieter dazu, ihre tatsächlichen Fähigkeiten zu beschreiben, statt generische Übereinstimmung zu behaupten.

Solch spezifische Anforderungen zu formulieren erfordert Vorbereitung, entweder durch interne Anwender, die wissen, was dem aktuellen System fehlt, oder durch einen OEE‑Implementierungsberater, der mehrere Systeme in der Produktion gesehen hat.

Die Organisation der RFP-Anforderungen in Kategorien erleichtert die Bewertung. Anforderungen an die Datenerfassung sollten abdecken: automatisierte Maschinenzustandserkennung via PLC/OPC‑UA; konfigurierbare Ausfallursachen-Hierarchie (mindestens 3 Ebenen); Bestätigungs-Workflow für Bediener bei Stillstandszeiten; Erfassung der Produktionsstückzahlen aus Maschinensignalen; Erfassung von Qualitätsausschuss direkt am Produktionsort; Kategorisierung von Rüst- und geplanten Wartungszuständen; Konfiguration des Schichtplans; und Unterstützung für Mehrproduktläufe mit produktbezogenen Zykluszeitvorgaben.

Anforderungen an die OEE-Berechnung: ISO‑22400-konforme OEE-Berechnung; konfigurierbare Berechnungsmethodik (World‑Class OEE vs. Practical OEE vs. Theoretical OEE); Berechnung und Anzeige der Teilkennzahlen Verfügbarkeit, Leistung und Qualität; Aggregation auf Schicht-, Tages-, Wochen- und Monatsbasis; Zusammenfassende Berechnungen auf Linien-, Bereichs- und Werksniveau; Echtzeit-OEE-Berechnung (nicht nur am Schichtende); Erstqualitätsrate (First‑Time Quality) getrennt von der Gesamtqualitätsrate; und historische Trendberechnung über mindestens 24 Monate.

Anforderungen an Reporting und Analytik: konfigurierbares Dashboard pro Benutzerrolle; Pareto‑Analyse der Stillstandsursachen nach Dauer und Häufigkeit; OEE‑Wasserfall‑Diagramm (Verlustbaum, der Verfügbarkeit, Leistung und Qualitätskomponenten zeigt); Schichtvergleichsberichte; Linien‑Benchmarking über Standorte hinweg; geplante Zustellung von Berichten per E‑Mail; Rohdatenexport nach CSV/Excel; und API‑Zugriff für die Integration mit BI‑Tools.

Integrationsanforderungen: OPC‑UA‑Client; Integration von Produktionsaufträgen mit SAP/Oracle/D365 (falls zutreffend); Auslösen eines CMMS ‑Arbeitsauftrags bei Stillstandsereignis; Single Sign‑On (SSO) über SAML 2.0 oder OIDC; und HTTPS‑verschlüsselte Datenübertragung.

Mobile‑ und Alarmierungsanforderungen: Mobile App für iOS und Android; Echtzeit‑Alarm für Schichtleiter bei Stillstandsereignissen, die einen Schwellenwert überschreiten; tägliche OEE‑Zusammenfassung als Push‑Benachrichtigung; und Offline‑Modus mit Datensynchronisation bei erneuter Verbindung.

Eine gewichtete Bewertungsmatrix wandelt RFP-Antworten in vergleichbare Werte um, die die Prioritäten Ihrer Organisation widerspiegeln. Die Gewichtung sollte die relative Wichtigkeit jeder Anforderungskategorie für Ihre spezifische Situation abbilden, ein Hersteller mit komplexen SAP-Integrationen sollte die Integrationsfähigkeit stärker gewichten als ein Unternehmen mit einem eigenständigen ERP, während ein Werk mit schlechter Datendisziplin der Bediener die automatisierte Datenerfassung höher gewichten sollte als die Flexibilität bei Berichten.

Eine typische Gewichtungsstruktur für einen mittelständischen Hersteller: Datenerfassungsfähigkeit (25 %), die Grundlage, ohne die OEE-Daten unzuverlässig sind; OEE-Berechnung und Analytik (20 %), die zentrale Wertschöpfung; ERP/CMMS-Integration (20 %), die Verbindung zu bestehenden Systemen; Implementierung und Support (15 %), das Umsetzungsrisiko; Berichterstattung und Dashboards (10 %), die Benutzererfahrung; kommerzielle Bedingungen (10 %), Gesamtbetriebskosten.

Innerhalb jeder Kategorie werden einzelne Anforderungen mit 0, 3 bewertet (0 = nicht unterstützt, 1 = auf der Roadmap, 2 = durch Konfiguration unterstützt, 3 = nativ „out of the box“ unterstützt) und die Kategoriepunktzahl ist der gewichtete Durchschnitt der Einzelbewertungen.

Über die quantitative Punktzahl hinaus sollten Sie Anbieter für eine strukturierte Demo auf die Shortlist setzen, bevor Sie eine endgültige Auswahl treffen. RFP-Antworten beschreiben die Fähigkeiten; Demos offenbaren die Gebrauchstauglichkeit.

Die beste OEE-Software für Ihr Werk ist diejenige, die Ihre Bediener tatsächlich korrekt nutzen, das erfordert die Bewertung der Bedienoberfläche im Kontext Ihrer spezifischen Produktionsumgebung, mit Ihren Maschinentypen, Schichtmustern und dem Ablauf der Dateneingabe. Bewerten Sie die Demo separat von der RFP-Bewertung und kombinieren Sie beide Ergebnisse in Ihrer endgültigen Lieferantenempfehlung an die leitenden Entscheidungsträger.