8 заблуждений об управлении изменениями (MOC) — почему MOC важен для всех бизнесов

Когда я обсуждаю Управление изменениями (MOC) с персоналом завода, быстро возникают знакомые лица: опытный профессионал, который цитирует OSHA 1910.119(a)(2) и вздыхает, что их процесс не является «охватываемым процессом», и менее опытный, который жалуется, что их система управления чертежами отстает и что догонивание потребует лет ресурсов.

Другие ответы также распространены: «У нас уже есть процедура для менеджеров по одобрению небольших проектов и изменений», или ироничный комментарий о «копейках и никелях», заполняющих пепельницу их машины. Эти реакции раскрывают общую неопределенность: что именно такое MOC, и почему это должно иметь значение для объекта, не регулируемого по рамкам OSHA 1910.119?

OSHA 1910.119(l)(1) определяет требования MOC: «Работодатель должен установить и реализовать письменные процедуры для управления изменениями (за исключением «замены в роде») в процессных химикатах, технологиях, оборудовании и процедурах; и изменениях в объектах, влияющих на охватываемый процесс». Хотя регулирование фокусируется на безопасности процессов, основной принцип — контроль изменений для предотвращения потерь — имеет актуальность далеко за пределами регулируемых отраслей.

Для объектов, квалифицирующихся как «охватываемый процесс», требования MOC хорошо понятны и необходимы для продолжения операций. Еще более тревожно то, что исследования атрибутируют до 80% крупных промышленных аварий неконтролируемым изменениям. В этом смысле MOC можно рассматривать как форму страховки жизни: меньше аварий — выше возврат инвестиций.

Даже если ваш завод не подпадает под конкретные правила MOC OSHA, каждый бизнес, стремящийся оставаться конкурентоспособным, должен управлять изменениями. MOC — это затратоэффективный инструмент предотвращения потерь, дополняющий программы безопасности, надежности и экологической ответственности.

Важно помнить, что MOC применяется только к изменениям в существующих системах; проектирование новых процессов или объектов выходит за его рамки. Процесс MOC предполагает, что текущая система имеет известные сильные и слабые стороны, и стремится снизить риски, связанные с ее модификацией.

Простыми терминами, MOC — это структурированный подход к предотвращению или смягчению потерь — будь то безопасность, здоровье, окружающая среда или бизнес-производительность — возникающих из изменений в том, как объект построен, эксплуатируется, обслуживается или ремонтируется. Каждый бизнес, желающий защитить свои активы и репутацию, выиграет от надежной программы MOC.

Что составляет «изменение»?
«Признание изменения» — часто самая сложная часть MOC. Первый шаг — четкое определение, соответствующее вашим бизнес-целям и любым применимым регулированиям. Неопределенное определение приводит к параличу и создает лазейки для тех, кто хочет обойти процесс.

Лидерство должно решить, какие риски организация хочет контролировать, а затем идентифицировать изменения, которые увеличат эти риски. Например, изменение может касаться оборудования, программного обеспечения, процедур или процессных параметров. Даже неаппаратные модификации — такие как новый программный патч или пересмотренный операционный лимит — должны учитываться.

Исходный документ OSHA отличает изменение от «Замены в роде» (RIK), которая является заменой, удовлетворяющей оригинальным проектным спецификациям. Более широкое определение в OSHA 3313 проясняет, что изменение — это «альтерация или корректировка любого компонента, переменной или свойства внутри существующей системы (за исключением тех, что в четко определенных границах или обязанностях)». Этот взгляд признает, что технологии, химикаты и процедуры так же критичны, как физическое оборудование.

Поскольку у каждой организации уникальный профиль риска, определение изменения должно отражать ее толерантность к неконтролируемой модификации. Ниже приведены распространенные примеры, которые большинство бизнесов считают подлежащими MOC:

• Добавление нового процессного оборудования или критических бизнес-систем, включая программное обеспечение
• Замена оборудования или деталей, не являющихся «в роде»
• Модификация или добавление к процессному оборудованию или критическим системам
• Корректировка процессного контроля или инструментации, включая контрольные стратегии
• Изменение спецификаций или источников запчастей МРО
• Альтерация систем безопасности — блокировки, аварийные остановки, подавление пожара или взрыва
• Пересмотр стандартных операционных процедур (SOP) или аварийных процедур
• Модификация организационной структуры на уровне объекта или процедур обслуживания
• Изменение спецификаций или источников сырья или компонентов
• Альтерация коммунальных подключений — воздух, электричество, газ, вода, пар и т.д.
• Корректировка критических сетевых подключений данных
• Обновление процедур обеспечения качества (QA) или тестового оборудования

Краткая многодисциплинарная мозговая атака на ранней стадии проектирования может помочь обеспечить, что выбранные определения и примеры соответствуют бизнес-приоритетам и толерантности к риску.

А как насчет «временных» изменений?
Не существует постоянных изменений — только временное изменение, которое в конечном итоге возвращается в исходное состояние. Однако временные изменения — самая частая причина инцидентов. Поэтому MOC должно относиться к временным изменениям так же, как к постоянным, с особым вниманием к процессу возврата. OSHA 3313 проясняет, что «процедуры MOC должны обеспечивать возврат оборудования и процедур в их исходные условия по окончании временного изменения». Отношение к временным изменениям как к постоянным защищает от высшего риска.

Восемь распространенных заблуждений о MOC

1. «Я не вношу реальную модификацию; я просто улучшаю что-то».
   Любое изменение в конфигурации, форме, посадке, функции, материале или процедуре попадает под MOC, если не исключено явно вашими критериями. Небольшие улучшения, меняющие контекст системы, могут неосознанно увеличивать риск. Ополномочьте сотрудников узнавать и сообщать о таких изменениях до того, как они станут критическими.
2. «Я отстаю; я не могу начать MOC, потому что у нас устарели чертежи».
   Контроль документов — дополнение, а не замена MOC. Приоритизация корректирующих действий на основе критичности системы позволяет двигаться вперед без ожидания идеальности каждого документа. MOC защищает будущее; оно не может исправить прошлые ошибки.
3. «Это чрезвычайная ситуация; у нас нет времени на MOC».
   В чрезвычайных ситуациях дисциплина хорошо установленного процесса MOC еще более необходима. Контролируемый, документированный подход к временным обходам или замещениям часто экономит больше времени и снижает риск, чем ад-хок обходные пути. MOC должна включать четкую процедуру для чрезвычайных случаев, не обходящую основные принципы.
4. «Маршрутизация этой формы на одобрение занимает слишком много времени».
   Уровни одобрения должны быть пропорциональны риску изменения. Оптимизируйте процесс, ограничив утверждающих теми, у кого есть нужная экспертиза и полномочия, и адаптируя рабочий процесс под ситуацию.
5. «Менеджер зоны уже одобряет финансирование; этого достаточно».
   Полномочия одобрять финансирование не то же самое, что знания, необходимые для оценки технического или безопасностного влияния изменения. Сбалансированная, многодисциплинарная команда рассмотрения дает более надежные результаты.
6. «Мы склад или дата-центр; здесь нет опасности».
   MOC защищает от всех форм потерь — качества продукта, доверия клиентов, простоя оборудования, целостности данных и многого другого. Даже низкорiskовые среды могут пострадать от дорогостоящих сбоев, если изменения неконтролируемы.
7. «MOC не поймает каждую проблему, так зачем беспокоиться?»
   Хотя никакая система не идеальна, MOC драматически снижает вероятность аварий. Она также предоставляет ценный аудиторский след, ускоряющий анализ первопричин при возникновении непредвиденных проблем. Стоимость упущенных инцидентов часто далеко превышает расходы на MOC.
8. «Изменения в программном обеспечении или процедурах не нуждаются в MOC».
   Обновления программного обеспечения и процедурные изменения вызывали значительные инциенты во многих отраслях. Относитесь к любой альтерации, которая может повлиять на безопасность или производительность, так же, как к физической модификации — полный обзор, документация и одобрение.

Заключение
Хорошо спроектированная программа MOC — жизненно важный инструмент предотвращения потерь для каждой организации, независимо от отрасли или регуляторного статуса. Она не должна быть обременительной; с правильной структурой MOC может сосуществовать с непрерывным улучшением и гибким управлением изменениями. Время внедрить надежный процесс MOC — сейчас.

Эта статья впервые появилась в июльском выпуске информационного бюллетеня Life Cycle Engineering RxToday.

Об авторе

Сэм МакНайр — старший консультант в Life Cycle Engineering (LCE). Профессиональный инженер и сертифицированный специалист по обслуживанию и надежности, у Сэма более 32 лет опыта в дискретном производстве, химических процессных отраслях, горном деле, машиностроении, автоматизации, авиации, строительстве и коммунальном хозяйстве. Он специализируется на инженерии надежности с фокусом на интеграцию функций обслуживания и производства. Свяжитесь с Сэмом по smcnair@LCE.com. Для получения дополнительной информации о Life Cycle Engineering посетите www.LCE.com.