8 Missverständnisse über Management of Change – Warum MOC für alle Unternehmen wichtig ist

Wenn ich mit Anlagenpersonal über Management of Change (MOC) spreche, tauchen vertraute Gesichter auf: der erfahrene Profi, der OSHA 1910.119(a)(2) zitiert und seufzt, dass sein Prozess kein „covered process“ ist, und der weniger Erfahrene, der klagt, dass sein Zeichnungsmanagement-System hinterherhinkt und das Aufholen Jahre an Ressourcen verschlingen würde.

Andere Reaktionen sind ebenso häufig: „Wir haben bereits ein Verfahren für Manager zur Genehmigung kleiner Projekte und Änderungen“, oder ein ironischer Kommentar über die „Pfennige und Nickels“, die ihren Zigarettenanzünder füllen. Diese Reaktionen offenbaren eine gemeinsame Unsicherheit: Was genau ist MOC, und warum sollte es eine Anlage betreffen, die nicht unter den OSHA 1910.119-Rahmen fällt?

OSHA 1910.119(l)(1) definiert MOC-Anforderungen: „Der Arbeitgeber muss schriftliche Verfahren zur Verwaltung von Änderungen (außer ‚Replacements in Kind‘) an Prozesschemikalien, Technologie, Ausrüstung und Verfahren sowie an Anlagen, die einen covered process betreffen, etablieren und implementieren.“ Obwohl die Regulierung auf Prozesssicherheit fokussiert, hat das Kernprinzip – Änderungen kontrollieren, um Verluste zu verhindern – Relevanz weit über regulierte Industrien hinaus.

Für Anlagen, die als „covered process“ qualifizieren, sind die MOC-Anforderungen gut verstanden und essenziell für den Weiterbetrieb. Noch alarmierender ist, dass Studien bis zu 80 % schwerer Industrieunfälle auf unkontrollierte Änderungen zurückführen. In diesem Sinne kann MOC als eine Art Lebensversicherung gesehen werden: Je weniger Unfälle, desto höher der Return on Investment.

Auch wenn Ihre Anlage nicht den spezifischen MOC-Regeln von OSHA unterliegt, muss jedes Unternehmen, das wettbewerbsfähig bleiben will, Veränderungen managen. MOC ist ein kosteneffektives Verlustverhütungstool, das Sicherheits-, Zuverlässigkeits- und Umweltprogramme ergänzt.

Wichtig ist, dass MOC nur auf Änderungen an bestehenden Systemen anwendbar ist; das Design neuer Prozesse oder Anlagen liegt außerhalb seines Geltungsbereichs. Der MOC-Prozess geht davon aus, dass das aktuelle System bekannte Stärken und Schwächen hat und sucht, die Risiken zu mindern, die mit seiner Modifikation verbunden sind.

In einfachen Begriffen: MOC ist ein strukturierter Ansatz zur Verhinderung oder Milderung von Verlusten – ob sie Sicherheit, Gesundheit, Umwelt oder Geschäftsleistung betreffen – resultierend aus Änderungen daran, wie eine Anlage gebaut, betrieben, gewartet oder repariert wird. Jedes Unternehmen, das seine Assets und seinen Ruf schützen will, profitiert von einem robusten MOC-Programm.

Was constituye eine „Änderung“?
„Änderungen erkennen“ ist oft der herausforderndste Teil von MOC. Der erste Schritt ist eine klare Definition, die Ihre Geschäftsziele und geltende Regulierungen trifft. Eine vage Definition führt zu Lähmung und schafft Schlupflöcher für die, die den Prozess umgehen wollen.

Die Führung sollte entscheiden, welche Risiken die Organisation kontrollieren will, und dann die Änderungen identifizieren, die diese Risiken erhöhen würden. Eine Änderung könnte Hardware, Software, Verfahren oder Prozessparameter betreffen. Selbst nicht-hardware-Modifikationen – wie ein neuer Software-Patch oder ein revidierter Betriebsgrenzwert – müssen berücksichtigt werden.

OSHAs Quelldokument unterscheidet eine Änderung von einem „Replacement in Kind“ (RIK), also einem Ersatz, der die ursprünglichen Designspezifikationen erfüllt. Die breitere Definition in OSHA 3313 klärt, dass eine Änderung „eine Veränderung oder Anpassung an beliebigen Komponenten, Variablen oder Eigenschaften innerhalb eines bestehenden Systems (außer denen innerhalb klar definierter Grenzen oder Verantwortlichkeiten)“ ist. Diese Sicht erkennt an, dass Technologie, Chemikalien und Verfahren ebenso kritisch sind wie physische Ausrüstung.

Da jede Organisation ein einzigartiges Risikoprofil hat, muss die Definition einer Änderung ihre Toleranz für unkontrollierte Modifikation widerspiegeln. Nachfolgend häufige Beispiele, die die meisten Unternehmen als MOC-relevant betrachten würden:

• Hinzufügen neuer Prozessausrüstung oder kritischer Geschäftssysteme, einschließlich Software
• Ersetzen von Ausrüstung oder Teilen, die nicht „in kind“ sind
• Modifizieren oder Hinzufügen zu Prozessausrüstung oder kritischen Systemen
• Anpassen von Prozesssteuerung oder Instrumentierung, einschließlich Steuerstrategien
• Ändern von Spezifikationen oder Beschaffung von MRO-Teilen (Maintenance, Repair, Operations)
• Verändern von Sicherheitssystemen – Verriegelungen, Abschaltungen, Brand- oder Explosionsunterdrückung
• Überarbeiten von Standardarbeitsanweisungen (SOPs) oder Notfallverfahren
• Modifizieren der standortbezogenen Organisationsstruktur oder Wartungsverfahren
• Ändern von Rohmaterial- oder Komponentenspezifikationen oder -beschaffung
• Verändern von Versorgungsanschlüssen – Druckluft, Elektrisch, Gas, Wasser, Dampf etc.
• Anpassen kritischer Datennetzwerkverbindungen
• Aktualisieren von QA-Verfahren (Quality Assurance) oder Prüfgeräten

Eine kurze, multidisziplinäre Brainstorming-Sitzung früh in der Designphase kann helfen sicherzustellen, dass die gewählten Definitionen und Beispiele mit Geschäftsprioritäten und Risikotoleranz übereinstimmen.

Was ist mit „temporären“ Änderungen?
Es gibt keine permanente Änderung – nur eine temporäre Änderung, die schließlich in ihren ursprünglichen Zustand zurückversetzt wird. Doch temporäre Änderungen sind die häufigste Unfallursache. Daher sollte MOC temporäre Änderungen gleichbehandeln wie permanente, mit besonderer Aufmerksamkeit auf den Rückführungsprozess. OSHA 3313 klärt: „MOC-Verfahren sollten sicherstellen, dass Ausrüstung und Verfahren am Ende einer temporären Änderung in ihren ursprünglichen Zustand zurückversetzt werden.“ Temporäre Änderungen als permanent zu behandeln, schützt vor höchstem Risikoexposure.

Acht häufige Missverständnisse über MOC

1. „Ich mache keine echte Modifikation; ich verbessere nur etwas.“
   Jede Änderung an Konfiguration, Form, Passform, Funktion, Material oder Verfahren fällt unter MOC, sofern nicht explizit durch Ihre Kriterien ausgeschlossen. Kleinere Verbesserungen, die den Systemkontext verändern, können unbeabsichtigt Risiken erhöhen. Befähigen Sie Mitarbeiter, solche Änderungen zu erkennen und zu melden, bevor sie kritisch werden.
2. „Ich bin im Rückstand; ich kann MOC nicht starten, weil wir veraltete Zeichnungen haben.“
   Dokumentenkontrolle ist ein Komplement, kein Ersatz für MOC. Priorisierung korrektiver Maßnahmen basierend auf Systemkritikalität ermöglicht Vorankommen, ohne auf perfekte Dokumente zu warten. MOC schützt die Zukunft; es kann vergangene Fehler nicht korrigieren.
3. „Das ist ein Notfall; wir haben keine Zeit für MOC.“
   In Notfällen ist die Disziplin eines etablierten MOC-Prozesses noch essenzieller. Ein kontrollierter, dokumentierter Ansatz für temporäre Bypasses oder Substitutionen spart oft mehr Zeit und reduziert Risiko mehr als Ad-hoc-Workarounds. MOC sollte ein klares Notfallverfahren beinhalten, das die Kernprinzipien nicht umgeht.
4. „Das Weiterleiten dieses Formulars zur Genehmigung dauert zu lange.“
   Genehmigungsebenen müssen proportional zum Änderungsrisiko sein. Straffen Sie den Prozess, indem Sie Genehmiger auf jene mit der richtigen Expertise und Autorität beschränken und den Workflow an die Situation anpassen.
5. „Der Bereichsleiter genehmigt bereits die Finanzierung; das reicht.“
   Befugnis zur Finanzierungsgenehmigung ist nicht dasselbe wie das Wissen, um technische oder sicherheitstechnische Auswirkungen einer Änderung zu bewerten. Ein ausgewogenes, multidisziplinäres Review-Team liefert zuverlässigere Ergebnisse.
6. „Wir sind ein Lager oder Rechenzentrum; da gibt es keine Gefahr.“
   MOC schützt vor allen Verlustformen – Produktqualität, Kundenvertrauen, Ausrüstungsausfallzeit, Datenintegrität und mehr. Selbst niedrig-gefährdete Umgebungen können kostspielige Ausfälle erleiden, wenn Änderungen unkontrolliert sind.
7. „MOC fängt nicht jedes Problem, also warum sich bemühen?“
   Kein System ist perfekt, doch MOC reduziert die Unfallwahrscheinlichkeit drastisch. Es liefert auch einen wertvollen Audit-Trail, der die Root-Cause-Analyse bei unvorhergesehenen Problemen beschleunigt. Die Kosten verpasster Vorfälle überwiegen oft bei weitem die MOC-Aufwendungen.
8. „Software- oder Verfahrensänderungen brauchen kein MOC.“
   Software-Updates und Verfahrensänderungen haben in vielen Branchen signifikante Vorfälle verursacht. Behandeln Sie jede Änderung, die Sicherheit oder Leistung beeinflussen könnte, gleich wie eine physische Modifikation – vollständige Prüfung, Dokumentation und Genehmigung.

Fazit
Ein gut gestaltetes MOC-Programm ist ein unverzichtbares Verlustverhütungstool für jede Organisation, unabhängig von Branche oder Regulierungsstatus. Es muss nicht belastend sein; mit der richtigen Struktur kann MOC mit kontinuierlicher Verbesserung und agilem Change Management koexistieren. Die Zeit für die Implementierung eines robusten MOC-Prozesses ist jetzt.

Dieser Artikel erschien erstmals in der Juli-Ausgabe von Life Cycle Engineering's Newsletter, RxToday.

Über den Autor

Sam McNair ist Senior Consultant bei Life Cycle Engineering (LCE). Als Professional Engineer und Certified Maintenance and Reliability Professional verfügt Sam über mehr als 32 Jahre Erfahrung in diskreter Fertigung, chemischen Prozessindustrien, Bergbau, Maschinenprozessen, Automatisierung, Luftfahrt, Bau und Versorgungsunternehmen. Er spezialisiert sich auf Zuverlässigkeitsengineering mit Fokus auf Integration von Instandhaltung und Fertigungsfunktionen. Kontakt: smcnair@LCE.com. Weitere Informationen über Life Cycle Engineering unter www.LCE.com.