Wichtigste Erkenntnisse
Für einen IT/OT-Manager ist ein CMMS ein weiteres System, das integriert, abgesichert und betrieben werden muss. Die Wartungsfunktionen sind weniger entscheidend als das Verhalten der Software innerhalb der gesamten Technologieumgebung. Wenn das falsch läuft, wird ein nützliches Werkzeug zur langfristigen Belastung.
Ein CMMS existiert selten allein. Es muss Daten mit ERP-Systemen, Historian-Systemen und manchmal direkt mit den Maschinen austauschen. Der IT/OT-Manager sucht nach sauberen APIs und Standardintegrationen, weil umfangreiche kundenspezifische Konnektoren fragil, teuer und ein Hindernis für zukünftige Upgrades sind.
Die Anbindung von Wartungssoftware an die Betriebstechnik wirft echte Fragen auf: Wer kann worauf zugreifen, wo werden Daten gespeichert und wie ist die Verbindung zu den Maschinen gesichert? Starke Zugriffskontrollen, Auditierbarkeit und klare Datenresidenz sind für diese Rolle keine Nice-to-haves; sie sind zwingende Anforderungen.
Cloud oder On-Premise, Single Sign-On, wie Upgrades gehandhabt werden, all das bestimmt, wie viel laufende Arbeit das System für die IT erzeugt. Eine Plattform, die zu bestehenden Identitäts- und Sicherheits-Tools passt und sich ohne manuellen Aufwand aktualisiert, verursacht deutlich weniger Aufwand als eine, die ständige Betreuung benötigt.
Ein IT/OT-Manager bewertet zwei CMMS-Optionen. Die eine bietet Standard-APIs, Single Sign-On und klare Sicherheitsdokumentation; die andere erfordert kundenspezifische Integrationsarbeit und einen separaten Login. Die erste passt mit geringem Mehraufwand in den Stack und das Sicherheitsmodell; die zweite fügt eine zu verwaltende Insellösung und eine neue Angriffsfläche hinzu. Die Wartungsfunktionen waren ähnlich; die Architektur hat entschieden.
Die Anbindung der Wartung an Live-Produktionsdaten, einschließlich OEE, vervielfacht den Nutzen eines CMMS, erhöht aber auch den Integrations- und Sicherheitsaufwand. Ein IT/OT-Manager möchte, dass diese Verbindung über saubere, sichere Schnittstellen und nicht über fragile kundenspezifische Verbindungen erfolgt. Buchen Sie eine Fabrico-Demo, um zu sehen, wie vernetzte Wartung und OEE-Daten in eine bestehende Architektur passen können. Siehe auch Cloud vs. On-Premise CMMS.
Saubere Integration mit bestehenden Systemen, starke Zugriffskontrolle und Daten-Governance, sichere Konnektivität zur Betriebstechnik und eine Anpassung an bestehende Identitäts- und Update-Tools, um die IT-Belastung gering zu halten.
Das kann sie sein, weshalb die Verbindung gezielt abgesichert sein muss, mit Zugriffskontrollen, Auditierbarkeit und klar definierten Grenzen. Richtig umgesetzt sind die dadurch zugänglichen Produktionsdaten das eingegangene, kontrollierte Risiko wert.
Die Einführung eines CMMS in der Fertigung befindet sich an der Schnittstelle von IT und OT, ein zunehmend komplexer Bereich, da Cloud‑Systeme mit den Steuerungsnetzwerken auf Werksebene verbunden werden. IT‑Verantwortliche müssen prüfen: Cloud‑Sicherheitslage (mindestens SOC 2 Type II‑Zertifizierung, ISO 27001 bevorzugt), Datenlokalisierung und Nachweise zur DSGVO/CCPA‑Konformität, SSO und Integration des Identitätsmanagements (Active Directory, Azure AD, Okta), Netzwerksicherheitsarchitektur für OT‑Konnektivität sowie SLA‑Zusagen zu Verfügbarkeit und Support‑Antwortzeiten.
OT‑Verantwortliche müssen prüfen: PLC‑ und SCADA‑Anbindungsmethode (direkte API, OPC‑UA, Modbus oder proprietärer Connector), Einhaltung der Netzwerksegmentierung (ein Cloud‑CMMS sollte keine direkten Firewall‑Regeln vom OT‑Netz zum öffentlichen Internet erfordern), Edge‑Gateway‑Architektur zur Erfassung von Maschinendaten, ohne OT‑Systeme offenzulegen, sowie die Erfahrung des Anbieters mit den industriellen Cybersicherheitsstandards ISA/IEC 62443. Im CMMS‑Beschaffungsprozess kommt es häufig vor, dass die IT die Sicherheitsfreigabe erteilt, ohne die OT einzubeziehen, oder die OT Konnektivitätsanforderungen festlegt, ohne eine sicherheitstechnische Überprüfung durch die IT, beide Muster führen zu kostspieligen Implementierungsproblemen nach Vertragsabschluss.
OEE direkt von Ihren Maschinen, ganz ohne manuelle Erfassung?
Live ansehenDie zentrale Netzsicherheitsfrage für Cloud-CMMS in der Fertigung ist, wie Maschinendaten vom OT-Netzwerk zur Cloud-Plattform gelangen. Es existieren drei Architekturen mit unterschiedlichen Sicherheitsprofilen.
Architektur 1: Direkte SPS‑zu‑Cloud‑Verbindung, die Software des CMMS‑Anbieters verbindet sich direkt über das Anlagen-/OT‑Netz mit SPS und nutzt ausschließlich ausgehende HTTPS‑Verbindungen zur Cloud. Das ist einfach, erfordert aber Firewall‑Regeln, die ausgehenden Verkehr aus dem OT‑Netzwerk erlauben, was viele OT‑Sicherheitsstandards untersagen.
Architektur 2: Edge‑Gateway, ein dediziertes Edge‑Gerät (Industrie‑PC oder Gateway‑Hardware) sitzt in der DMZ zwischen OT‑ und IT‑Netzwerken, sammelt Daten von SPS und leitet sie an die Cloud weiter. Das wahrt die Isolation des OT‑Netzwerks und ist die von ISA/IEC 62443 und den NIST‑Richtlinien empfohlene Architektur.
Architektur 3: MES‑Vermittlung, das CMMS bezieht Daten aus einem vorhandenen MES‑ oder Historian‑System, das bereits im IT‑Netzwerk angesiedelt ist, und bewahrt so die OT‑Isolation, ohne neue Edge‑Hardware zu benötigen. Bei der Evaluation von CMMS‑Anbietern fordern Sie ein Netzwerkarchitekturdiagramm an, das genau zeigt, wo die Konnektivität stattfindet und welche Architektur sie unterstützen.
Anbieter, die dieses Diagramm nicht vorlegen können, haben die OT‑Sicherheitsimplikationen ihres Integrationsansatzes nicht durchdacht.
Für IT/OT-Manager, die eine Sicherheitsüberprüfung eines CMMS-Anbieters durchführen, dient diese Checkliste als Basis. Datenresidenz: Bestätigen Sie, dass die Cloud-Hosting-Region den Datenresidenzanforderungen Ihrer Organisation entspricht, und holen Sie eine schriftliche Bestätigung ein, wo Daten verarbeitet und gespeichert werden.
Sicherheitszertifizierungen: Fordern Sie den SOC 2 Type II-Bericht (innerhalb der letzten 12 Monate) an und prüfen Sie insbesondere Abschnitt 7 (Verfügbarkeit) und Abschnitt 9 (Vertraulichkeit). Penetrationstests: Fordern Sie eine Zusammenfassung des jüngsten Drittanbieter-Penetrationstests und den Status der Behebung der Befunde an.
API-Sicherheit: Bestätigen Sie, dass die REST-API OAuth 2.0 mit Token-Ablauf und Ratenbegrenzung verwendet, keine API-Key-Authentifizierung ohne Ablaufdatum. Integrationsstandards: Fordern Sie OPC‑UA-Unterstützung für moderne SPS-Konnektivität und bestätigen Sie Modbus‑TCP-Unterstützung für Altanlagen. Datenexport: Bestätigen Sie die Möglichkeit eines Massendatenexports in offenen Formaten (CSV, JSON) ohne Einbeziehung des Anbieters, dies schützt Ihr Recht auf Anbieterwechsel.
Backup und Wiederherstellung: Fordern Sie ein RPO (Recovery Point Objective) von unter 1 Stunde und ein RTO (Recovery Time Objective) von unter 4 Stunden für Produktionsumgebungen. Anbieterzugriff: Fordern Sie ein Zugriffsprotokoll des Anbieters, das alle Zugriffe des Anbieters auf Ihre Umgebung zeigt und Ihrem Team auf Abruf zugänglich ist.
Diese Anforderungen sind für jeden Enterprise-CMMS-Anbieter angemessen und sollten bei etablierten Plattformen keine Schwierigkeiten bei der Bewertung verursachen.
Machen Sie aus Stillständen eine Kennzahl, mit der Ihr Team arbeiten kann.
Demo anfordern
Anmeldung
Blog
