Учет HSE-инцидентов в одной системе: от сообщения до расследования

Задача: не потерять инцидент и довести до мер

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

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

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

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

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

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

Шесть сущностей карточки инцидента

Статусы, без которых нет контроля

Четырех статусов обычно достаточно: зарегистрирован, в работе, проверка, закрыт.

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

Как выглядит сообщение об инциденте (простая форма)

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

Минимум полей, которых почти всегда хватает:

• Короткое описание: что произошло и что делали в момент события.
• Срочность: есть ли угроза людям, оборудованию или окружающей среде прямо сейчас.
• Где и когда: площадка, участок, смена, дата и время.
• Тип: травма, near miss, разлив, пожарная ситуация, нарушение барьера и т.д.
• Источник опасности: транспорт, электро, химия, работа на высоте, инструмент.

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

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

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

Классификация и уровень серьезности без споров

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

Практичный вариант - матрица 3x3. По одной оси фактические последствия (нет вреда, легкий вред, серьезный вред), по другой - потенциальные (низкий, средний, высокий). Итоговый уровень берется как более высокий из двух. Так near miss не превращается в «ноль», а легкая травма не раздувается до «катастрофы».

Чтобы говорить на одном языке, закрепите короткие определения:

• First aid: помощь на месте без медучреждения и без потери смены.
• Медицинская помощь: осмотр/лечение в медучреждении без потери трудоспособности.
• Потеря трудоспособности: пропуск хотя бы одной смены по медпоказаниям.
• Ущерб имуществу: стоимость ремонта/замены по согласованному порогу.
• Экология/пожар/отказ оборудования/нарушение требований: отдельные категории, даже если нет травмы.

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

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

Барьеры: фиксируем не только факт, но и защиту

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

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

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

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

Проверка барьеров должна опираться на факты: осмотр места, журналы обходов, настройки оборудования, актуальность инструкций, записи о выдаче СИЗ, протоколы обучения. Это быстро снимает споры в стиле «вроде было».

В системе результат по каждому барьеру лучше отмечать одинаково:

• Сработал
• Частично сработал
• Не сработал
• Не применимо

Так вы видите не только последствия, но и качество защиты, и проще переводите выводы в конкретные мероприятия.

Расследование: короткий и понятный разбор причин

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

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

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

Чтобы не скатиться в обвинения, задавайте вопросы про действия и условия:

• Что произошло по шагам и в какой последовательности?
• Какие барьеры должны были сработать и какие реально сработали?
• Что изменилось перед событием (люди, техника, погода, график)?
• Если задать «почему» пять раз (5 Why), где окажется корень?
• Что нужно изменить, чтобы риск стал ниже, а не просто «провести беседу»?

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

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

Мероприятия: превращаем выводы в план работ

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

Хорошее мероприятие отвечает на пять вопросов: что сделать, где, кто делает, к какому сроку, как проверить результат. Если результат нельзя проверить, потом нельзя честно закрыть.

Обычно помогают два слоя:

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

Чтобы план не расползался, привязывайте каждую задачу к конкретной причине и к пробелу в барьере. Простой тест: «Какой барьер станет сильнее после выполнения?» Если ответа нет, задача лишняя.

Приоритет ставьте по риску и вероятности повтора: сначала то, что может снова привести к травме или крупному ущербу.

Проверку эффективности лучше описывать заранее, например:

• осмотр и фотофиксация барьера после установки
• выборочная проверка соблюдения нового шага процесса
• аудит на участке через 30 дней
• показатель: повторение похожих событий = 0 за период

Пример: near miss на складе из-за разметки. Срочно - ограничить проезд и поставить временные конусы сегодня. Корректирующее - нанести постоянную разметку и изменить схему движения. Эффективность - проверить обходом и коротким опросом смены через две недели.

Ответственные и сроки: чтобы инцидент не завис

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

Роли, которые держат процесс

Достаточно закрепить четыре роли:

• Инициатор: сообщает факт и прикладывает минимум данных (где, когда, что произошло).
• Владелец инцидента: проводит карточку через весь путь до закрытия (назначает расследование, согласует выводы, запускает мероприятия).
• Расследователь: делает разбор причин и формирует выводы.
• Утверждающий: подтверждает качество расследования и критерии закрытия (обычно руководитель направления или HSE-куратор).

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

Сроки и статусы: без двусмысленностей

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

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

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

Пошагово: от сообщения до закрытия расследования

Процесс должен вести инцидент по понятным статусам, чтобы система не превратилась в архив заметок. Самое важное - первые минуты: зафиксировать событие и убрать риск, а уже потом заполнять детали.

Обычно работает такой порядок:

• Регистрация: кратко описать событие, место и время, отметить, что сделано для безопасности (остановили работу, оградили зону, вызвали ответственного).
• Сбор фактов: условия, участники по ролям (без ФИО), фото/доказательства, первичная классификация и предварительная серьезность.
• Проверка барьеров: какие защиты должны были сработать (инструктаж, ограждение, блокировка, СИЗ) и что именно не сработало.
• Расследование: подтвердить причины на основе фактов, согласовать выводы с руководителем участка и HSE.
• План действий: оформить мероприятия, назначить ответственных и сроки, указать ожидаемый эффект (какой барьер усиливаем).

Карточка не должна закрываться автоматически. Нужна проверка выполнения (доказательства: акт, фото, запись обучения) и проверка эффективности через время: риск реально снизился или проблема повторяется.

Пример: на складе палета сместилась при перемещении. Сразу остановили зону и заменили поврежденный поддон. В расследовании выяснили: отсутствовала разметка прохода и не было проверки поддонов. Меры: разметка, чек перед сменой, обучение водителей погрузчика, срок - 10 дней, контроль - через месяц по статистике near miss.

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

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

1. Собирают персональные данные там, где они не нужны. Для анализа хватает роли или подразделения («водитель подрядчика», «оператор смены A»), без ФИО и лишних подробностей. Чем меньше чувствительных данных, тем выше доверие.

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

3. Путают причины и мероприятия. Причина - почему случилось так, а не иначе (например, «зона разгрузки без разметки», «не работал ограничитель скорости»). Мероприятие - что меняем в системе. Наказание человека почти никогда не является корректирующим действием.

4. Не фиксируют барьеры. Если не записать, какие защиты должны были сработать (ограждения, чек-листы, обучение, блокировки, СИЗ) и какие реально сработали, похожие случаи будут повторяться.

5. Ставят срок без владельца и ресурсов.

6. Закрывают карточку «по датам» без проверки результата.

Полезная проверка перед закрытием:

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

Быстрый чек-лист качества карточки инцидента

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

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

Для классификации полезно иметь две версии: первичную (сразу после сообщения) и финальную (после расследования). Если уровень или тип изменились, причина должна быть понятна: появились новые факты, уточнили последствия, подтвердили отказ барьера.

Качество плана мер видно по деталям. У каждого мероприятия должен быть один владелец, конкретный срок и критерий завершения, который можно проверить (например, «внедрена маркировка зон и проведен повторный инструктаж, подтверждено актом/листом ознакомления»).

Карточка должна быть безопасной по данным: никаких ФИО, номеров телефонов, табельных номеров, фото с читаемыми бейджами или лицами. Если просрочки есть, они объяснены и согласованы. Перед закрытием должна стоять отметка о проверке эффективности: что именно проверили и как убедились, что мера снижает риск.

Короткая самопроверка перед статусом «закрыто»:

• Обязательные поля заполнены и не противоречат друг другу (событие, последствия, барьеры).
• Есть первичная и финальная классификация, причина изменения ясна.
• У мероприятий указан владелец, срок и критерий завершения.
• Персональные данные отсутствуют в тексте и вложениях.
• Просрочки объяснены и согласованы.
• Проведена проверка эффективности, отметка есть в карточке.

Пример сценария: near miss в логистике

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

Такой near miss удобно фиксировать без ФИО, чтобы сообщение не превращалось в поиск виноватых. В карточке достаточно фактов и условий.

• Событие: «Почти столкновение погрузчика с тележкой при повороте в проезде между рядами стеллажей, груз на тележке сместился».
• Потенциальные последствия: «Падение груза, травма ног/кистей при попытке удержать груз, повреждение стеллажа, остановка работ в зоне».
• Барьеры (как должно быть): «Разметка маршрутов и одностороннее движение, ограничение скорости, обучение водителей, предсменный осмотр техники, зеркало/сигнализация в слепой зоне».
• Фактические барьеры: «Разметка частично стерта, ограничение скорости не контролируется, зеркало отсутствует, осмотр техники не подтвержден записью».

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

План мероприятий лучше делать коротким и измеримым:

• Обновить схему движения и нанести разметку в проезде, срок: 7 дней, ответственный: руководитель склада.
• Ввести контроль скорости (точки наблюдения/выборочные проверки), срок: 14 дней, ответственный: HSE-координатор.
• Провести осмотр тележек и погрузчиков с отметкой в журнале, срок: 3 дня, ответственный: механик.
• Провести внеплановый инструктаж по маневрированию в узких зонах, срок: 5 дней, ответственный: мастер смены.

Закрытие расследования: подтверждение выполнения (фото разметки, записи осмотров, протокол инструктажа) и короткое наблюдение на месте через 2-3 недели, чтобы убедиться, что новые правила работают.

Пример управленческой отчетности без персональных данных

Ниже пример формата на 1 страницу для регулярного контроля. Он показывает, как идет учет HSE-инцидентов в одной системе, без фамилий, смен и конкретных исполнителей.

Сводка за период (пример: январь 2026)

Топ причин и слабых барьеров (агрегировано)

Топ-5 причин по классификатору: 1) нарушение порядка работ, 2) спешка и отвлечение, 3) недостаточная проверка зоны, 4) неисправность/износ, 5) неясные роли при передаче смены.

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

Статус мероприятий (все расследования): выполнено 11 (52%), в срок 6 (29%), просрочено 4 (19%), критические просрочки 2 (свыше 30 дней).

Критические просрочки: внедрение физического разделения потоков пешеходов и техники на участке 3; замена изношенных строп по итогам проверки.

Решения, которые нужны от руководства:

• подтвердить ресурс на ограждения/разметку и остановку работ на 1 смену для монтажа;
• закрепить правило: high potential инциденты закрываются только после проверки барьеров на месте;
• согласовать единый стандарт предсменного осмотра с выборочной проверкой качества.

Обезличенные формулировки в тексте: «сотрудник участка», «подрядная организация», «складской терминал», «время суток», «тип оборудования». Без ФИО, табельных номеров и конкретных смен.

Следующие шаги: как запустить одну систему и закрепить процесс

Начните с минимума, чтобы единый учет заработал за 2-4 недели. Сначала договоритесь о цели: каждый инцидент должен пройти путь от сообщения до закрытых мер.

Старт внедрения: минимум, который нужен сразу

Определите простые роли (сообщивший, руководитель участка, HSE, расследующий, утверждающий) и короткий регламент: сроки реакции, кто назначает расследование, как закрываются мероприятия. Затем настройте карточку с минимальными полями и проведите короткое обучение на 30-40 минут.

Хороший стартовый набор:

• обязательные поля карточки (событие, последствия, барьеры, мероприятия, ответственные, сроки)
• единые статусы (новое, в работе, расследование, меры, закрыто)
• правила по срокам (например, первичная оценка в 24 часа)
• шаблон отчета без персональных данных
• канал для сообщений (форма, почта или сервис-деск)

Платформа и интеграции

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

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

Если нужна надежная ИТ-основа под такую систему (серверы, рабочие места, поддержка и интеграции), имеет смысл подключать системного интегратора. Например, GSE.kz (gse.kz) как производитель и системный интегратор в Казахстане может помочь с инфраструктурой и сопровождением, чтобы учет инцидентов не зависел от разрозненных файлов и ручных настроек.