Управление барьерами безопасности по Bow-tie: как вести учет

Зачем вообще вести учет опасностей и барьеров

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

Барьеры безопасности - это не «общие мероприятия по ОТ и ПБ» вроде инструктажа или плаката на стене. Барьер - конкретная защита, которая должна прервать сценарий. Это может быть техническая защита (ограждение, блокировка, вентиляция), организационная (допуск, два человека на операцию) или поведенческая (обязательная проверка по чек-листу). У барьера есть владелец, понятный критерий работоспособности и регулярная проверка.

Руководителю участка почти никогда не нужен «десяток файлов». Ему нужен один простой ответ по своему периметру: где риск растет прямо сейчас. На производственной площадке это видно на бытовых примерах. Есть операция с подъемом тяжелого оборудования. Барьер - исправное грузоподъемное средство и предсменный осмотр. Если осмотр просрочен, то сценарий «падение груза» становится заметно ближе, даже если в целом «меры приняты».

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

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

Bow-tie простыми словами: из чего состоит схема

Bow-tie («бабочка») - простой способ разложить риск по полочкам: что может пойти не так, чем мы это сдерживаем, и что будет, если все же случилось.

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

Слева от опасности находятся угрозы (причины), которые могут привести к ключевому событию (например, к возгоранию). Справа - последствия, то есть к чему это приведет, если событие уже произошло.

Где в Bow-tie живут барьеры

Барьеры делятся на два типа.

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

Снижающие последствия (справа) уменьшают вред после события. Например, автоматическое пожаротушение, обучение персонала действиям при пожаре, эвакуационные выходы.

Смысл схемы в том, что барьеры привязываются не к «общему риску», а к конкретной угрозе или последствию. Тогда управление становится практичным: видно, какой барьер что именно закрывает.

Почему барьер «слабеет»: деградационные факторы

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

Полезный прием: для каждого барьера заранее ответить на два вопроса:

• Что может ухудшить барьер? (деградация)
• Как мы это заметим вовремя? (контроль, проверка, сигнал)

Bow-tie помогает не путать причины и последствия: слева всегда «почему случилось», а справа - «что будет дальше». Это снижает споры на разборе и делает требования к проверкам и владельцам барьеров более понятными.

Как хранить опасности и сценарии: минимальный состав данных

Чтобы Bow-tie работал в жизни, а не только на схеме, опасности и сценарии нужно хранить как простые записи, которые легко найти, обновить и собрать в отчет по конкретной площадке. Главное правило: минимум полей, но каждое поле должно помогать принять решение.

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

Минимальный набор для карточки опасности может быть таким:

• Объект и процесс (например, «участок покраски», «хранение растворителей»)
• Границы (что входит и что не входит, чтобы не спорить при проверках)
• Площадка и участок (для адресных отчетов и задач)
• Владелец (должность/ФИО ответственного, кому идут уведомления)
• Дата последнего пересмотра и следующего пересмотра

Сценарий нужен, чтобы связать опасность с тем, как именно может пойти не так. В Bow-tie удобно хранить сценарий как цепочку «угроза - нежелательное событие - последствия». Тогда позже к нежелательному событию легко привязать барьеры и проверки.

Для сценария достаточно зафиксировать:

• Угрозу (что запускает развитие ситуации, например «ошибка при перекачке»)
• Нежелательное событие (что произошло, например «разлив ЛВЖ»)
• Последствия в четырех разрезах: люди, активы, экология, производство
• Место действия (та же площадка/участок, что и в карточке опасности)
• Условия, при которых сценарий реален (когда, как часто, при каких работах)

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

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

Как описывать барьеры, чтобы ими можно было управлять

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

Карточка барьера: минимум, без которого учет разваливается

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

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

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

Критичность и связи с Bow-tie

Чтобы выделять «ключевые» барьеры без сложной математики, используйте простую шкалу A/B/C:

• A - если барьер не работает, риск резко растет сразу (нет второго слоя защиты или последствия тяжелые)
• B - есть дублирование или время на реакцию
• C - поддерживающий барьер

Этого достаточно, чтобы расставлять приоритеты по проверкам и реакции на просрочки.

Самое важное - связи. В карточке должно быть указано, к какому сценарию из Bow-tie относится барьер и какую часть цепочки он перекрывает: предотвращает причину (слева) или снижает последствия (справа). Пример: сценарий «перегрев сервера в стойке приводит к остановке сервисов». Барьер предотвращения - «датчик температуры с оповещением при превышении порога», барьер снижения последствий - «резервирование питания и план аварийного переключения». Когда связи заполнены, сразу видно, где у сценария нет защиты, и какие проверки действительно важны.

Проверки барьеров: график, результаты и доказательства

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

Какие проверки бывают и как не перепутать их

Тип проверки зависит от барьера. Для одного достаточно визуального осмотра, другой нужно тестировать или калибровать. Лучше заранее закрепить допустимые типы проверок для каждого барьера, чтобы исполнители не выбирали «как привыкли».

Чаще всего встречаются:

• осмотр (есть ли барьер физически, нет ли повреждений, пломбы, маркировка)
• функциональный тест (срабатывает ли устройство или процедура на практике)
• калибровка (соответствие измерений, уставок, датчиков норме)
• аудит процедуры (правило выполняют и оно актуально)
• тренировка/учение (готовность людей действовать по сценарию)

Периодичность и «окно» до просрочки

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

Рядом задайте допуск, или «окно», когда проверку еще можно выполнить без статуса «просрочено». Пример: периодичность 30 дней, окно 5 дней. Тогда барьер станет «к просрочке» на 31-й день и «просрочен» на 36-й. Это уменьшает споры, когда проверку сделали «на день позже», а отчет уже красный.

Что хранить как доказательство

Отчетность ломается, если в записи нет минимальных доказательств. Даже без вложений запись должна быть самодостаточной.

Минимальный набор полей для каждой проверки:

• дата и время выполнения (и плановая дата, чтобы видеть отклонение)
• исполнитель (ФИО/роль/подрядчик, если внешний)
• результат со статусом: выполнено, выполнено с замечаниями, не выполнено
• комментарий: что именно проверяли и что нашли
• доказательство: номер акта, фото, протокол теста, скан, файл (если есть)

Если результат «выполнено с замечаниями», важно фиксировать, влияет ли замечание на работоспособность барьера. Иначе руководитель участка не поймет, это косметика или рост риска.

Как разделить «проверку» и «ремонт», чтобы отчеты не путались

Проверка отвечает на вопрос «барьер работает сейчас?». Ремонт или корректирующее действие отвечает на вопрос «что мы делаем, чтобы вернуть или улучшить работу?». Это разные сущности.

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

Как внедрить учет Bow-tie и барьеров: пошаговый план

Начните с малого. Главная ошибка - пытаться описать сразу все опасности предприятия. Для пилота достаточно одного участка и 1-2 самых критичных опасностей, где риск понятен и уже есть меры защиты.

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

Пять шагов, которые работают на практике

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

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

3. Назначьте владельцев барьеров и критерии работоспособности. У каждого барьера должен быть один ответственный (роль, а не только фамилия) и понятный ответ на вопрос: как мы узнаем, что барьер работает? Например: «ограждение на месте и фиксируется», «газоанализатор прошел поверку», «оператор обучен и допущен». Если критерий нельзя проверить, это не барьер, а пожелание.

4. Настройте календарь проверок и простую форму фиксации. Для каждого барьера задайте периодичность (смена, неделя, месяц), кто проверяет, и какое доказательство нужно (фото, номер акта, отметка в журнале, результат теста). Начните с минимума: дата, статус (в норме/не в норме/не проверено), комментарий, доказательство.

5. Запустите регулярный разбор просрочек и отказов, потом расширяйте охват. Еженедельная короткая встреча на участке важнее, чем красивая диаграмма. На разборе решайте только практические вопросы: какие проверки просрочены, какие барьеры неработоспособны, кто и до какой даты восстанавливает, и какие временные меры нужны, пока барьер не вернули в норму.

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

Отказ барьера как событие: как фиксировать и разбирать

Отказ барьера важно фиксировать как отдельное событие, а не как «заметку в журнале». Тогда видно, какие защиты реально работают, а какие существуют только на бумаге. Для управления барьерами это один из самых полезных источников данных.

Сначала договоритесь о терминах. «Барьер не сработал» и «барьер не проверен» - разные вещи. Если проверка просрочена, вы не знаете, сработает ли барьер, но самого отказа еще не было. А отказ - это когда барьер должен был сработать в реальной ситуации (или на тесте) и не выполнил свою функцию.

Что записывать в событии отказа

Карточка события должна быть короткой, но однозначной. Минимальный набор:

• идентификатор барьера (название и тип, например: «газоанализатор, сигнализация и отключение») и связанный сценарий Bow-tie
• дата и время, место (участок, установка, помещение), смена
• описание: что произошло и в какой момент стало ясно, что барьер не сработал
• последствия (если были): останов, утечка, травма, отклонение качества, «без последствий»
• источник обнаружения: инцидент, тест, аудит, обход, сигнал системы

Короткий пример: во время пуска компрессора сработала сигнализация по газу, но автоматическое отключение не произошло. Оператор остановил вручную, последствий нет. Это отказ барьера «автоотключение», даже если датчик и сирена отработали.

Как разбирать причину и что делать дальше

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

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

Дальше используйте статистику отказов, чтобы править управление. Если барьер отказывает чаще, чем ожидалось, повышайте частоту проверок, уточняйте критерии приемки (что считается «работает»), пересматривайте запасные части и обучение. Если отказов нет, но проверки регулярно просрочены, это сигнал, что график нереалистичен или ответственность размазана.

Пример отчета «барьеры просрочены» для руководителя участка

Такой отчет нужен, чтобы за 2-3 минуты понять: где на участке риск вырос из-за того, что защитные меры не проверены вовремя, и кому поставить задачу. В нем нет лишней аналитики, только факты: какой барьер просрочен, насколько давно, насколько он важен и что уже сделано.

Ниже пример структуры. В реальной системе эти строки обычно строятся из учета Bow-tie: опасность -> сценарий -> барьер -> проверка.

Сводка (за неделю, по вашему участку): всего барьеров: 128; просрочено: 9; просрочено критичных: 3; новые просрочки за неделю: 4.

Чтобы отчет был удобен руководителю, делайте его с фильтрами и простыми группировками, а не с длинными комментариями. Обычно хватает сортировки по критичности (сначала «Высокая», затем «Средняя/Низкая»), по владельцу (видно, у кого накапливаются просрочки), по участку (если зон несколько) и по типу барьера (технический, организационный, поведенческий).

Хорошее правило для шапки отчета: если есть хотя бы одна просрочка «Высокая» больше 7 дней, она должна попадать в ежедневный контроль, а статус действия не может быть «не назначено».

Частые ошибки, из-за которых учет не работает

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

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

Вторая боль - отсутствие владельца барьера. Если у барьера нет конкретного ответственного (должность и ФИО), просрочки становятся «ничьими». На практике это выглядит так: начальник участка видит просроченный огнетушитель или блокировку, а в системе нет человека, который должен закрыть действие и подтвердить восстановление.

Третья ошибка - размытый критерий работоспособности. Записи вида «в норме» не помогают, если не ясно, как это проверили. Для каждого барьера нужен короткий, проверяемый признак: что именно смотрим, какой результат приемлем, какое доказательство фиксируем (фото, номер акта, показание, отметка в журнале).

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

И еще одна типичная проблема - отчеты раз в месяц. За месяц просрочки успевают стать нормой, а руководитель видит проблему слишком поздно. Лучше короткий еженедельный (а для критичных барьеров ежедневный) обзор просрочек.

Вот признаки, что система уже «плывет»:

• проверки закрываются задним числом без доказательств
• в просрочках одни и те же барьеры, но никто не назначен
• поля заполняют по-разному, потому что нет единых правил
• «зеленый статус» есть, а что именно проверяли - не ясно
• инциденты прячутся внутри «ремонта» и не разбираются

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

Короткий чек-лист и следующие шаги

Чтобы управление барьерами не превратилось в «табличку ради таблички», проверьте базовые условия. Если хотя бы одного элемента нет, барьером почти невозможно управлять.

Чек-лист на 5 минут

Ответьте «да/нет» по каждому пункту для каждого барьера:

• назначен владелец (конкретная роль или ФИО) и понятно, кто принимает решение при просрочке
• есть критерий работоспособности (что значит «барьер работает» и по каким признакам это видно)
• указана дата следующей проверки (или периодичность) и понятен источник данных
• есть текущий статус (в норме, просрочен, недоступен, на ремонте) и причина, если не в норме
• есть одна запись на один барьер и один результат проверки (без дублей и «сводных» строк)

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

Минимальный ритм, который держит систему живой

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

Как начать с малого и не утонуть

Начните с пилота на одном участке и 10-20 ключевых барьерах, которые реально влияют на риск. Через 2-3 недели станет видно, где не хватает данных, кто перегружен проверками и какие критерии нужно уточнить.

Дальше шаги простые: выберите платформу учета (хотя бы единый реестр и журнал проверок), назначьте владельцев и правила обновления. Если учет планируется развернуть внутри организации, заранее продумайте инфраструктуру и поддержку: надежные серверы и рабочие места, резервное копирование, доступ для смен, обслуживание 24/7. Здесь иногда проще привлечь опытного системного интегратора. Например, GSE.kz (gse.kz) занимается системной интеграцией и инфраструктурой дата-центров, а также производит серверы и рабочие станции в Казахстане, что удобно для проектов с локальным размещением и долгосрочной поддержкой.