HAZOP (Hazard and Operability Study)

1 июня 1974 года на химическом заводе в Фликсборо (Великобритания) взрыв облака циклогексана убил 28 и серьёзно травмировал 36 из 72 человек, находившихся на площадке. Жертв было бы значительно больше, если бы взрыв произошёл в рабочий день, когда в основном офисном здании было бы много людей. Один из современников процессной безопасности написал, что «ударная волна встряхнула уверенность каждого химического инженера в стране». Спустя месяцы после этой катастрофы institution of Chemical Engineers впервые открыл недельный курс по методике, разработанной несколькими годами раньше в компании ICI: HAZOP (Hazard and Operability Study — исследование опасностей и работоспособности). Курс был полностью забронирован, как и курсы следующих нескольких лет. HAZOP — систематический качественный метод поиска опасностей и проблем работоспособности процесса: сложную систему разбивают на узлы, а к каждому параметру каждого узла применяют фиксированный набор ключевых слов (guide words), чтобы найти отклонения от замысла проекта, которые не пришли в голову проектировщикам. В этой статье — как метод родился в ICI и распространился после Фликсборо, как устроены узлы и ключевые слова, какова роль команды, где метод ограничен и как использовать фрейм OrgDevTools.

Что такое HAZOP и когда он нужен

По справочному определению, HAZOP — структурированное и систематическое исследование сложной системы, обычно технологической установки или машины, для выявления опасностей для персонала, оборудования или окружающей среды, а также проблем работоспособности, которые могут повлиять на эффективность операций. Это основной инструмент выявления опасностей в области процессной безопасности. Цель проведения HAZOP — рассмотреть процесс или машину на всех фазах жизненного цикла продукта, чтобы выявить проектные и инженерные проблемы, которые иначе могли бы остаться незамеченными другими инструментами оценки риска или проектирования (FMEA, FTA и другими).

Метод изначально разработан для систем, связанных с обработкой жидких сред или иным потоком материала в технологической промышленности, где он и сейчас остаётся важным элементом управления процессной безопасностью. Позже его расширили на анализ периодических (batch) реакций и операционных процедур установок. Недавно его стали применять к областям, слабо связанным с технологической промышленностью: программные приложения, включая программируемые электронные системы; разработка кода; системы перемещения людей (автомобильный, железнодорожный, воздушный транспорт); административные процедуры разных отраслей; медицинские устройства; машины. Метод нужен там, где отклонение от замысла проекта может привести к опасности или потере работоспособности и где есть достаточная проектная информация, чтобы обсуждать конкретные узлы: чаще всего на этапе детального проектирования установки, но также как инструмент повторной валидации существующих установок — проверки, что за время эксплуатации не накопились неучтённые изменения. Он менее применим там, где проектной информации ещё нет (тогда проводят лишь грубый предварительный HAZOP) или где нужен количественный расчёт вероятности, а не качественное выявление отклонений. Смежные методы: FMEA-анализ, анализ дерева отказов (FTA), FRACAS, оценка операционных рисков, пять «почему» и диаграмма Исикавы.

Происхождение и исследовательская база

Происхождение метода описал сам Тревор Клетц, работавший советником компании ICI (Imperial Chemical Industries) по технической безопасности с 1968 по 1982 год. В 1963 году команда из трёх человек встречалась по три дня в неделю на протяжении четырёх месяцев, чтобы изучить проект нового фенольного завода, начав с техники под названием «критическое рассмотрение» (critical examination), которая изначально запрашивала альтернативы, а позже была изменена так, чтобы запрашивать отклонения. Метод был доработан внутри компании под названием «исследования работоспособности» (operability studies) и стал третьей стадией — детального проектирования — процедуры анализа опасностей ICI (первые две стадии выполнялись на этапах замысла и технического задания). Важное уточнение: Клетц не изобрёл метод, но был центральной фигурой его распространения по отрасли и написал первую книгу на эту тему.

В 1974 году Институт химических инженеров (IChemE) предложил недельный курс по технике безопасности, включавший эту процедуру, в Teesside Polytechnic. Курс состоялся вскоре после катастрофы в Фликсборо и был полностью забронирован, как и курсы следующих нескольких лет. В том же 1974 году была опубликована первая статья по теме в открытой печати (Лоули, «Operability Studies and Hazard Analysis», Chemical Engineering Progress). В 1977 году Ассоциация химической промышленности опубликовала руководство. До этого момента термин «HAZOP» не использовался в формальных публикациях; первым его употребил Клетц в 1983 году в книге, представлявшей собой, по сути, переработанные и обновлённые конспекты курсов IChemE. К 1983 году исследования опасностей и работоспособности стали ожидаемой частью программ инженерных специальностей в Великобритании.

Регулирующий стандарт для метода сегодня — IEC 61882, который требует от членов команды проявлять «интуицию и хорошее суждение», а от заседаний — проходить «в атмосфере критического мышления, откровенной и открытой» (так в оригинале, с отметкой sic в источнике). Ниже — рерайт справочных материалов. Оговорка: сам стандарт IEC 61882 и первая книга Клетца 1983 года в работе не читались; изложение построено по справочным статьям об истории метода и о самом Клетце.

Ударная волна встряхнула уверенность каждого химического инженера в стране (современник о катастрофе в Фликсборо, 1974 год; перевод цитаты из справочного обзора).

Академическая теория: как устроен HAZOP

Узлы: деление сложной системы на изучаемые части

Техника основана на разбиении общего сложного проекта процесса на несколько более простых участков, называемых узлами (nodes), которые затем изучаются по отдельности. Для технологических установок узлы выбирают так, чтобы для каждого можно было сформулировать содержательный проектный замысел (design intent); их обычно указывают на технологических схемах (P&ID) и схемах потоков процесса (PFD) — именно P&ID служат основным справочным документом для проведения HAZOP. Детализация каждого узла должна соответствовать сложности системы и масштабу опасностей, которые она может создавать. При этом документирование узлов должно балансировать между «слишком крупным и сложным» (меньше узлов, но участники не могут держать в голове весь узел сразу) и «слишком мелким и простым» (много тривиальных повторяющихся узлов, каждый из которых нужно рассматривать и документировать отдельно).

Проектный замысел как эталон для отклонений

Метод применяют к сложным процессам, для которых доступно достаточно проектной информации и которая вряд ли существенно изменится; этот объём данных нужно явно зафиксировать и принять как основу «проектного замысла» для исследования HAZOP. Например, предусмотрительный проектировщик заранее рассчитывает на предсказуемые вариации процесса, создавая более широкий проектный диапазон, чем базовые требования, — и HAZOP ищет способы, которыми этого диапазона может оказаться недостаточно. Иначе говоря, отклонение имеет смысл только относительно явно сформулированного «как должно быть»; без этого эталона непонятно, что вообще считать отклонением.

Ключевые слова и параметры: матрица генерации вопросов

Для каждого узла команда HAZOP использует список стандартизированных ключевых слов (No, More, Less, As well as, Part of, Reverse, Other than и другие) и параметров процесса, чтобы выявить возможные отклонения от проектного замысла. Там, где ключевое слово содержательно применимо к параметру (например, «нет потока», «больше температуры»), их сочетание записывают как достоверное потенциальное отклонение от проектного замысла, требующее рассмотрения. Ключевые слова — не готовые ответы, а генератор вопросов: их роль в том, чтобы стимулировать воображение участников, систематически задавая вопрос «что если этот параметр отклонится в этом направлении» для каждого узла, а не полагаться на то, что опытный инженер «и так знает, где может быть проблема».

От отклонения к решению: причины, последствия, защитные меры

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

Команда: роли и минимальный состав

Исследование HAZOP — командная работа: команда должна быть максимально малой, но с релевантными навыками и опытом. Если систему проектировал подрядчик, команда HAZOP должна включать персонал и подрядчика, и заказчика; рекомендуемый минимальный размер команды — пять человек. В крупном процессе потребуется много заседаний HAZOP, и состав участников может меняться по ходу работы: разным этапам нужны разные специалисты и их заместители, и всего в исследование может быть вовлечено до двадцати человек. У каждого участника есть определённая роль; ключевая — руководитель исследования (study leader, chairman, facilitator): человек, опытный в проведении HAZOP, знакомый с этим типом процесса, но независимый от команды проектировщиков, отвечающий за прохождение серии узлов, модерацию обсуждения, точность протокола, ясность рекомендованных действий и назначение конкретных исполнителей.

Подготовка и темп заседаний

Степень подготовки к HAZOP критична для успеха всего исследования: «замороженная» проектная информация, предоставленная участникам с запасом времени на ознакомление с процессом, достаточный график для проведения исследования, лучшие подходящие люди на каждой роли. Успех исследования сильно зависит от бодрости и концентрации участников, поэтому важно, чтобы заседания не были слишком длинными и между ними были подходящие интервалы; за это отвечает руководитель исследования. Показательный масштаб: для среднего химического завода, где общее число позиций для рассмотрения (единиц оборудования и трубопроводов) — около 1200, требуется порядка 40 таких заседаний. Сегодня для управления и протоколирования деятельности HAZOP доступны специализированные программы.

Учебный пример: узел загрузки реактора

Условный узел процесса — линия подачи растворителя в реактор. Параметр «поток», ключевое слово No: отклонение «нет потока растворителя» — возможная причина: закрыт клапан или отказ насоса; возможное последствие: реакция идёт без растворителя, перегрев. Ключевое слово More: «больше потока» — причина: неисправность регулирующего клапана; последствие: переполнение реактора. Ключевое слово Reverse: «обратный поток» — причина: разница давлений при остановке насоса без обратного клапана; последствие: загрязнение линии подачи продуктом реактора. Команда оценивает вероятность и тяжесть каждого отклонения (например, по шкале 1–5) и получает итоговый балл — вероятность × тяжесть; для отклонения «нет потока» при вероятности 3 и тяжести 5 балл равен 15 — по порогам фрейма OrgDevTools это высокий риск, требующий защитной меры (например, сигнализация низкого потока с блокировкой). Числа условные и иллюстрируют расчёт; конкретные шкалы и пороги задаёт организация или, в случае фрейма, инструмент.

Ключевые идеи и принципы HAZOP

1. Принцип: систематичность важнее интуиции отдельного эксперта

   HAZOP не полагается на то, что опытный инженер «и так знает, где может быть проблема» — метод заставляет команду пройти через фиксированный набор ключевых слов для каждого узла, гарантируя, что ни один класс отклонений не пропущен из-за того, что о нём просто не подумали.

2. Принцип: guide words — генератор вопросов, а не готовые ответы

   Ключевые слова сами по себе не содержат ответа; их роль — направлять вопрос «что если параметр X отклонится в направлении Y» на каждый значимый параметр каждого узла, стимулируя воображение команды.

3. Принцип: отклонение определяется относительно явного проектного замысла

   Без зафиксированного «как должно быть» нет опоры для того, что считать отклонением; проектный замысел — не формальность, а основа всего исследования.

4. Принцип: командный, а не индивидуальный процесс

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

5. Принцип: найденное отклонение всегда оценивается по риску

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

6. Принцип: качество зависит от подготовки и темпа заседаний

   «Замороженная» проектная документация, время на ознакомление, подходящие люди на ролях и разумная продолжительность заседаний — условие содержательного, а не формального прохождения ключевых слов.

Как провести HAZOP: пошаговая инструкция

Практическая последовательность на основе описания метода; масштаб и число заседаний зависят от сложности системы. Определите границы исследования и зафиксируйте проектную информацию как основу («замороженный» проектный замысел): P&ID, схемы потоков, технологические условия. Разбейте систему на узлы так, чтобы для каждого можно было сформулировать содержательный замысел — не слишком крупно и не слишком мелко. Соберите команду минимум из пяти человек с релевантными навыками, назначьте руководителя исследования, независимого от команды проектировщиков, и распределите роли; если систему проектировал подрядчик, включите специалистов и подрядчика, и заказчика.

Для каждого узла определите значимые параметры (поток, давление, температура, состав и другие) и систематически примените к каждому все ключевые слова, даже если некоторые кажутся неприменимыми на первый взгляд. Для каждого содержательного сочетания параметр/ключевое слово зафиксируйте отклонение, определите вероятные причины и вероятные последствия. Оцените отклонение по риску (вероятность × тяжесть) и решите, достаточны ли существующие защитные меры; если нет — сформулируйте конкретную рекомендацию с ответственным исполнителем. Планируйте заседания разумной длительности с интервалами, чтобы сохранить концентрацию команды; ведите протокол так, чтобы участники видели и подтверждали его точность. После завершения всех узлов сведите рекомендации в реестр действий и отслеживайте их выполнение. Пересматривайте или частично повторяйте HAZOP при значимых изменениях процесса, оборудования или условий эксплуатации, а также как инструмент повторной валидации существующих установок.

Пример из практики: Фликсборо и рождение курса HAZOP

Катастрофа в Фликсборо 1 июня 1974 года — взрыв облака циклогексана, 28 погибших и 36 серьёзно травмированных из 72 человек на площадке — стала поворотным моментом для отрасли. Спустя короткое время после катастрофы Институт химических инженеров впервые предложил недельный курс, включавший технику операционных исследований, разработанную в ICI за десятилетие до этого; курс был полностью забронирован, как и курсы следующих лет, а термин «HAZOP» вошёл в формальные публикации лишь позже, в 1983 году, у самого Клетца. Урок для внедрения: метод существовал и развивался в компании много лет до того, как трагедия сделала его массовым стандартом отрасли — цена промедления в распространении практики оказалась намного выше цены её внедрения. Оговорка: приведённые цифры и хронология — по справочным статьям об истории метода и о катастрофе; отчёт официального расследования в работе не читался.

Ограничения, слепые зоны и критика HAZOP

Типовые ошибки при проведении HAZOP

1. Ошибка 1: guide words применяются выборочно, не ко всем параметрам систематически.

   Команда рассматривает только «очевидные» ключевые слова для конкретного узла, пропуская менее интуитивные; систематичность метода теряется.

   Как избежать

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

2. Ошибка 2: узлы выбраны слишком крупно или слишком мелко.

   При слишком крупных узлах команда не может держать в голове весь узел сразу и упускает детали; при слишком мелких — множится число тривиальных повторяющихся заседаний.

   Как избежать

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

3. Ошибка 3: HAZOP проводится одним человеком, а не командой.

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

   Как избежать

   формировать междисциплинарную команду минимум из пяти человек с релевантными навыками и опытом.

4. Ошибка 4: найденные отклонения не оцениваются по риску.

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

   Как избежать

   оценивать каждое отклонение по вероятности и тяжести и приоритизировать по итоговому баллу риска.

5. Ошибка 5: найденные отклонения не приводят к конкретным защитным мерам.

   Список отклонений с оценками риска подготовлен, но конкретных решений о защитных мерах для высокого риска так и не последовало.

   Как избежать

   формулировать конкретную защитную меру с ответственным исполнителем для каждого отклонения высокого или среднего риска.

6. Ошибка 6: заседания слишком длинные и без подготовки.

   Команда теряет концентрацию к концу долгого заседания; проектная документация не была изучена заранее.

   Как избежать

   планировать заседания разумной длительности с интервалами и предоставлять «замороженную» документацию заранее.

7. Ошибка 7: HAZOP проведён один раз и не пересматривается при изменении процесса.

   Исследование выполнено на этапе проектирования, но при последующих модификациях процесса не пересматривается заново.

   Как избежать

   повторять или частично пересматривать HAZOP при значимых изменениях в процессе, оборудовании или условиях эксплуатации.

Метрики: как оценивать HAZOP

Универсальных нормативов нет; фиксируйте по своим данным:

• Покрытие ключевых слов: доля узлов, для которых систематически пройдены все guide words.

• Число найденных отклонений: по узлам и по всей системе — показатель полноты исследования.

• Доля отклонений с оценкой риска: должна быть 100%; отклонение без оценки — незакрытая работа.

• Отклонения высокого риска без защитной меры: должно быть 0 к моменту закрытия исследования.

• Темп заседаний: число узлов на заседание и длительность — показатель устойчивого темпа команды.

• Выполнение рекомендаций: доля рекомендованных защитных мер, реализованных в срок.

• Актуальность: дата последнего пересмотра и число изменений процесса после него.

Хороший HAZOP не находит проблемы, о которых мы и так знали. Он находит те, о которых никто не подумал, — потому что систематически прошёл через каждое ключевое слово, а не полагался на память.

План внедрения HAZOP по неделям

1. Неделя 1: подготовка и команда

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

2. Недели 2–4: прохождение узлов

   Систематически применяйте ключевые слова к параметрам каждого узла, фиксируйте отклонения, причины и последствия.

3. Неделя 5: оценка риска

   Оцените каждое отклонение по вероятности и тяжести и определите приоритет защитных мер.

4. Неделя 6: защитные меры и реестр

   Сформулируйте конкретные защитные меры с ответственными и сроками, сведите рекомендации в реестр действий.

   Далее: пересматривайте или частично повторяйте HAZOP при значимых изменениях процесса, оборудования или условий эксплуатации.

Как реализовать план с помощью фрейма «HAZOP» в OrgDevTools

Фрейм — экран из трёх секций. Первая — чек-лист покрытия из восьми стандартных ключевых слов (NO/NOT, MORE, LESS, AS WELL AS, PART OF, REVERSE, OTHER THAN, EARLY/LATE) с подсказками к каждому и счётчиком покрытия «N из 8». Вторая — таблица «Найденные отклонения»: текст отклонения плюс числовые оценки вероятности и тяжести; фрейм автоматически перемножает их и показывает уровень риска (низкий — до 7, средний — от 8 до 14, высокий — от 15) цветом. Третья — список защитных мер (safeguards) в свободном текстовом виде.

• Неделя 1 — покрытие: отмечайте применённые ключевые слова по мере прохождения узлов.

• Недели 2–5 — отклонения: заносите каждое найденное отклонение с оценками вероятности и тяжести.

• Неделя 6 — меры: добавляйте конкретные защитные меры для приоритетных отклонений.

Вердикт строится по ступеням. Если ни одно ключевое слово не отмечено — предложение начать с систематического применения guide words. Если отмечены не все восемь — предупреждение, что непроверенные слова могут скрывать непредусмотренные отклонения. Если все восемь отмечены, но среди отклонений есть хотя бы одно с баллом риска 15 и выше, а защитных мер не указано ни одной — красное предупреждение, что систематическое покрытие есть, но риск не закрыт. Если все ключевые слова отмечены, но ни одно отклонение не заполнено — предупреждение перепроверить покрытие. Иначе — подтверждение с числом покрытых слов, найденных отклонений и защитных мер.

Чего фрейм не делает. Он не работает с узлами и P&ID: покрытие ключевых слов и список отклонений общие для всего документа, поэтому для нескольких узлов нужны отдельные документы фрейма. Он не связывает конкретное отклонение с конкретной защитной мерой: список защитных мер — общий свободный текст, и фрейм не проверяет, действительно ли отклонение высокого риска закрыто именно указанной мерой, а не какой-то другой. Шкалы вероятности и тяжести и пороги риска (8 и 15) заданы во фрейме и не универсальны: их нужно интерпретировать в контексте конкретной системы, а при желании перейти на другую шкалу баллы нужно пересчитывать вручную. Фрейм не проверяет причины и последствия отклонений — это текстовое поле с описанием самого отклонения, без отдельных полей для причины и последствия. Он не заменяет ни команду, ни протокол заседаний, ни распределение ролей.

Книги и материалы по теме HAZOP

Т. Клетц — «HAZOP & HAZAN: Identifying and Assessing Process Industry Hazards» (1983 и последующие издания). Первая книга по теме, выросшая из конспектов курсов IChemE; в работе не читалась.

Г. Лоули — «Operability Studies and Hazard Analysis» (Chemical Engineering Progress, 1974). Первая статья по теме в открытой печати.

IEC 61882 — «Hazard and operability studies (HAZOP studies) — Application guide». Действующий международный стандарт метода; в работе не читался.

Т. Клетц — «Learning from Accidents» (2001). Разбор катастрофы в Фликсборо и других промышленных аварий с точки зрения процессной безопасности.

Справочные статьи «Hazard and operability study», «Trevor Kletz» и «Flixborough disaster» (Wikipedia). История метода, роль Клетца, катастрофа 1974 года.