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

Всякий раз, когда я говорю об управлении изменениями производственному персоналу, я обычно получаю один из нескольких предсказуемых ответов. Знающие люди процитируют постановление OSHA 1910.119 (a) (2) и скажут мне, что это не «закрытый процесс», поэтому он к ним не применяется - как правило, с большим облегчением. Другой частый ответ:«У нас есть процедура управления розыгрышем, но мы настолько отстаем, что потребуются годы и ресурсы, на которые нам не нужно наверстывать упущенное». Другие по-прежнему скажут мне, что у них есть прекрасная процедура для своих менеджеров по утверждению небольших проектов и изменений. А некоторые смущенно подумают о монетах и ​​пятаках, которыми наполняется пепельница их машины.

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

Это краткое описание охватывает значительную часть территории, но, поскольку оно было обнародовано исключительно для повышения безопасности процессов, оно ограничивает юридическую применимость «охватываемых процессов». Читатели, чьи объекты соответствуют требованиям OSHA к «покрытому процессу», хорошо осведомлены о подробных требованиях MOC. Они должны быть, иначе они бы еще не работали. И, надеюсь, все вы знаете, что многие из самых ужасных промышленных аварий в новейшей истории были первопричиной провала процесса MOC. Некоторые источники указывают, что до 80 процентов серьезных крупных аварий в промышленности связаны с неконтролируемыми изменениями. Таким образом, MOC можно рассматривать как своего рода страхование жизни, которое окупается за счет предотвращения несчастных случаев.

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

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

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

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

Есть много определений изменений из разных источников. Руководство сайта несет ответственность за определение изменений в соответствии с интересами бизнеса и любыми нормативными прецедентами. Какие риски вы хотите контролировать, и какие изменения, если их не контролировать, увеличивают эти риски? Только тогда можно будет четко идентифицировать те действия, которые можно было бы обоснованно определить как «изменения», и после того, как они были идентифицированы, они должны быть изложены на самом простом и понятном языке.
Хотя использование списков или таблиц с примерами немного беспорядочно. часто бывает необходимо, чтобы донести точку зрения. Имейте в виду, что «изменение» не обязательно должно происходить в части оборудования, чтобы соответствовать требованиям. Программное обеспечение, процедуры и параметры процесса - все это примеры не аппаратных изменений, которые часто необходимо строго контролировать.

Когда речь идет об оборудовании, исходный документ OSHA 1910 косвенно ссылается на изменение как на «замену в натуральном выражении» (RIK) и далее определяет RIK как «замену, которая удовлетворяет проектным спецификациям». RIK обычно относится к оборудованию или компонентам, которые идентичны по форме, посадке и функциям (далее F3). Но есть еще кое-что, что нужно изменить, чем этот очень узкий аппаратный подход. Определение изменения OSHA также относится к технологии, процедурам и химическим веществам (более широко интерпретируемым как сырье). Очевидно, что определение «изменения» включает не только оборудование. Я обнаружил, что лучшее формальное определение «изменения» в процессе MOC можно найти в пояснении, опубликованном в OSHA 3313:«Изменение - это изменение или корректировка любого компонента, переменной или свойства в существующей системе (кроме тех, которые находятся в четко определенные границы или обязанности) ».

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

• Добавление нового технологического оборудования или критически важной бизнес-системы (включая программное обеспечение).
• Замена технологического оборудования или деталей «не натурой».
• Модификации или незначительные дополнения к технологическому оборудованию.
• Модификации или незначительные дополнения к критически важной бизнес-системе (процедурной или программной).
• Модификации или незначительные дополнения к инфраструктуре / непроизводственному оборудованию.
• Изменения в управлении процессом и / или контрольно-измерительной аппаратуре (включая стратегии управления)
• Изменения в спецификациях или источниках технического обслуживания и ремонта.
• Изменения в рабочих пределах критических параметров процесса (за пределами диапазонов, указанных в стандартных операционных процедурах [СОП])
• Изменения в системах безопасности (блокировки, отключения, тушение пожара или взрыва и т. д.)
• Изменения стандартных операционных процедур (включая порядок действий в чрезвычайных ситуациях).
• Изменения в организационной структуре на уровне сайта.
• Изменения в процедурах обслуживания
• Изменения в спецификациях или источниках сырья / компонентов.
• Изменения или новые подключения к инженерным сетям (воздух, электричество, газ, вода, пар и т. д.).
• Изменения или новые подключения к критически важным сетям передачи данных.
• Изменения в процедурах обеспечения качества или критическом тестовом оборудовании.

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

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

Итак, что мне делать, чтобы иметь дело с временными изменениями, которые необходимо внести для выполнения рутинных операций, например, байпас блокировки для выполнения периодического обслуживания? Если это действительно рутина, то у вас постоянное состояние периодического отклонения от СОП. И правильный способ справиться с этим - рассматривать ситуацию как постоянное изменение, включив его в утвержденные процедуры с соответствующими гарантиями. Если что-то задумано как нестандартное временное изменение, рассматривайте это как изменение. OSHA 3133 в пояснении гласит:«Процедура MOC должна гарантировать, что оборудование и процедуры будут возвращены в исходное состояние по окончании временного изменения». История и благоразумие подсказывают, что «временными» изменениями следует управлять как «постоянными» с особым вниманием к процедуре MOC, поскольку они представляют наибольший риск для вашего бизнеса.

Восемь распространенных заблуждений о MOC
1) «Но я не делаю настоящих модификаций. Я просто улучшаю его ».
Если вы не покидаете часть / оборудование / бизнес-систему в том виде, в котором она была до начала работ (при отсутствии, конечно, каких-либо повреждений, которые были предметом ремонта), то вы внесли изменения . Подпадает ли изменение под действие вашего процесса MOC, определяется критериями, установленными в ваших процедурах. Подход по умолчанию заключается в предположении, что любое изменение конфигурации, формы, соответствия, функции, материалов или процедуры подпадает под действие MOC до тех пор, пока проверка критериев в процедуре не докажет обратное.

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

2) «Я так сильно отстал, что не могу начать заниматься MOC. Я никогда не догоню все эти неотредактированные рисунки ».
Управление документами - это процесс, который дополняет хорошо спроектированный процесс MOC, и часто это первое, о чем люди думают, когда вы упоминаете MOC. Необходимость обновления документов, безусловно, является частым результатом MOC и необходима для долгосрочной целостности ваших процессов и объектов, но это не MOC. Это всего лишь частый результат.

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

Вы не можете изменить то, что произошло в прошлом. Если существует экономическое обоснование для исправления или смягчения прошлых ошибок, сделайте это. MOC - это предотвращение потерь в будущем. Так что единственное, что может сделать любая организация, - это начать внедрение MOC прямо сейчас. Сегодня настал день, когда нужно перестать создавать новые проблемы для завтрашнего дня. Лаконичный отрывок народной мудрости гласит:«Если вам нужно засыпать настоящую большую яму, первое, что нужно сделать, - это перестать копать ее глубже». То же самое относится и к разрыву, создаваемому плохим MOC. Прекратите увеличивать его.

3) «У меня нет времени ждать оценки MOC. Это срочно! »
Во время чрезвычайной ситуации именно тогда, когда наиболее необходима самодисциплина, налагаемая хорошо отлаженным процессом MOC. Когда у авиалайнера возникает проблема в полете, пилоты не делают первого, что приходит на ум. Скорее они вытаскивают контрольный список и думают, а затем действуют. Когда есть «чрезвычайная ситуация», вы тоже должны это делать. Действительно ли эта «небольшая модификация», позволяющая произвести замену, сэкономит столько времени простоя по сравнению с получением правильной детали? Незначительные изменения часто занимают намного больше времени, чем ожидалось.

Будьте реалистичны в оценке того, сколько времени, сколько денег и насколько увеличится риск, на самом деле потребуется эта «быстрая работа». В чрезвычайной ситуации хорошо быть оптимистичным. Лучше быть готовым к худшему. Как гласит пословица:«Если ты далеко в море в протекающей лодке, лучше молиться к Небесам, но плыть к берегу». Стоит ли сэкономить время риск для вашего бизнеса, связанный с «временным» обходом? Можете ли вы действительно контролировать риск до приемлемого уровня с помощью «специальных операционных процедур»?

Отчеты об авариях показывают, что поспешные решения, принятые под давлением, без взвешенной оценки, лежат в основе многих серьезных проблем. . Время на то, чтобы мыслить дисциплинированно, - это не пустая трата времени. И если ваш процесс MOC эффективен, он не будет чрезмерно препятствовать прогрессу в тех редких случаях, когда это действительно чрезвычайная ситуация. Подобно тому, как существует процедура авторизации и выдачи приказа о проведении аварийных работ, когда это необходимо, хорошая процедура MOC будет иметь механизм для устранения реальных аварийных ситуаций. Но этот механизм не должен заключаться в игнорировании МОЦ. Не позволяйте целесообразности во время одной «чрезвычайной ситуации» подготовить вас к более крупной и более серьезной второй чрезвычайной ситуации. Не обезвреживайте бомбу только для того, чтобы заложить фугас.

Вы часто сталкиваетесь с отказами, которые требуют обходного решения, постоянной заменой деталей в полночь для восстановления после неожиданного отказа или постоянной изменения процесса с учетом нестабильных компонентов или сырья? Тогда ваша задача - не игнорировать MOC или разработать процесс MOC, поддерживающий анархию. Скорее вам следует сосредоточить свои усилия на устранении этих ситуаций путем внедрения эффективного процесса анализа основных причин отказов (RCFA) и программ профилактического / прогнозного обслуживания для устранения хронических отказов. Затем сосредоточьтесь на исправлении недостатков в ваших процессах ТОиР, чтобы всегда иметь нужные детали. И, наконец, вы должны стабилизировать свой процесс с помощью стандартных рабочих процедур и программ квалификации поставщиков материалов.

4) «Направление этой формы на утверждение занимает так много времени, что мы никогда ничего не сможем сделать».
Эффективный процесс MOC требует соответствующего уровня одобрения и общения. Плохо разработанные процедуры утверждения MOC путают необходимость получать информацию об изменении после того, как оно произошло, с необходимостью утверждать изменение до того, как оно произойдет. Требуемые уровни одобрения должны соответствовать изменению и связанному с ним потенциальному риску. Они также должны быть достаточно гибкими, чтобы их можно было адаптировать к текущей ситуации. Сведите к минимуму количество утверждающих и сделайте их подходящими. После этого ваш процесс MOC может быть оптимизирован.

5) «Но мой региональный менеджер уже должен утвердить средства для внесения изменений».
Не путайте полномочия принимать решение с владением знаниями, необходимыми для принятия этого решения. Не все изменения, а зачастую и самые важные, проходят даже через одобрение финансирования. Часто лицами, наиболее компетентными в оценке риска внесения изменений или технической обоснованности изменения, являются не региональный менеджер, а наиболее знакомые с ним операторы, механики, супервизоры или инженеры.

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

6) «Мы склад / легкое производство / данные центр / ремонтная база. … У нас нет ничего опасного ».
Помните, что MOC - это процесс предотвращения или уменьшения всех потенциальных коммерческих потерь, связанных с изменением. Помимо безопасности процесса, есть и другие потери. Это потеря, если неконтролируемое изменение процесса приведет к потере ценного клиента из-за загрязненного или неисправного продукта. Это потеря, если ваш центр обработки данных не работает, а устранение неполадок занимает несколько часов вместо минут, потому что электрические чертежи не успевают за изменениями. Если автоматический штабелеукладчик вышел из строя и вы не можете отправить товар, это потеря, потому что замена запчастей в полночь, требующая «небольшой модификации», привела к тому, что единственная запчасть, имеющаяся на складе, больше не подходила. Это потеря, если недокументированная модификация управляющего программного обеспечения приведет к отказу вашей автоматической испытательной машины при установке последнего исправления безопасности. Все это реальные примеры, и список можно продолжать бесконечно. Несмотря на то, что вероятность изменений, создающих опасные ситуации в вашей среде, невелика, всем нам есть что терять, когда наши объекты или процессы терпят неудачу в выполнении своих основных задач.

7) «Но MOC победила. не улавливаю все возможные проблемы, так зачем это делать? »
Вы абсолютно правы. Несмотря на все ваши усилия, некоторые проблемы останутся незамеченными. Но сколько из них ускользнет, ​​если вы не сделаете MOC? Управление рисками - это изменение шансов в вашу пользу. Этот аргумент не выдерживает критики - не более чем аргумент, который некоторые люди используют против подушек безопасности:«Они могут развернуться и вызвать аварию, поэтому я их отключаю». Статистические данные не подтверждают это мышление больше, чем они поддерживают отсутствие MOC.

Итак, что, если вы пропустите непредвиденные последствия? Ценным дополнительным преимуществом MOC в сложных системах является выполнение RCFA. Если изменение имеет неблагоприятные последствия и причину невозможно сразу определить, RCFA выполняется намного быстрее, если у вас есть список всех преднамеренных изменений, которые были внесены. И в этот раз могут быть настоящие деньги. В одном случае изучение записей MOC сократило на несколько недель время, необходимое для поиска первопричины ряда отказов технологического оборудования. При минимальных потерях из-за простоев в размере 250 000 долларов США в день проект MOC принес неплохой возврат инвестиций, хотя и не предотвратил проблему.

8) «Это просто изменение программного обеспечения / процедуры. Не то чтобы мы меняли трубку или что-то в этом роде. Нам не нужно подтверждать или документировать ».
Некоторые чрезвычайно серьезные инциденты и серьезные убытки произошли в ряде отраслей из-за изменений программного обеспечения или процедур, не подпадающих под действие MOC. Более того, то, что документ или код были изменены и отражают это изменение, не означает, что это изменение задокументировано. Я знаю, что комментарии в коде и флаги исправлений в документе позволяют поисковику искать изменения. Но когда возникают непредвиденные проблемы из-за того, что программное обеспечение или изменение процедуры не были должным образом проанализированы, тогда какая в этом польза?

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

Заключение
В заключение отметим, что хорошо продуманный процесс MOC - важный инструмент предотвращения потерь для любого бизнеса. Это касается не только некоторых опасных производств. Этот процесс применим к любой компании, которая желает избежать будущих убытков в результате сегодняшних изменений. MOC не обязательно должен быть подавляющим или сложным в использовании, чтобы препятствовать изменениям. Он не может легко компенсировать прошлые упущения, он только снижает ваш будущий риск. Итак, настало время начать разработку и внедрение эффективного и действенного процесса MOC.

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

Об авторе:
Сэм Макнейр - старший консультант компании Life Cycle Engineering (LCE). Профессиональный инженер и сертифицированный специалист по обслуживанию и надежности, Сэм имеет более чем 32-летний опыт работы в дискретном производстве, химической промышленности, горнодобывающей промышленности, машиностроении, автоматизации, авиации, строительстве и коммунальном хозяйстве. Сэм специализируется на проектировании надежности, уделяя особое внимание интеграции функций технического обслуживания и производства. Вы можете связаться с Сэмом по адресу [email protected]. Для получения дополнительной информации о Life Cycle Engineering посетите сайт www.LCE.com.