Промышленная безопасность — область, где цена ошибки измеряется не деньгами, а людьми. Для компании GRYS Power, которая работает с объектами энергетической отрасли, это не метафора. Мы разработали для них модуль управления рисками — часть системы автоматизации управления безопасностью. Система, в которой каждый параметр опасности настраивается под конкретный объект, а нужная информация всегда оказывается у соответствующего человека. Рассказываем, как это устроено.
О проекте
GRYS Power — поставщик технических решений в сфере энергетики. Клиенты компании работают на объектах повышенной опасности, где охрана труда — это ежедневная необходимость, а не формальность.
Наше сотрудничество началось в 2023 году с разработки EHS-системы. EHS (Environment, Health & Safety) — цифровая платформа для управления промышленной безопасностью, охраной труда и экологическим контролем на производственных объектах. Платформа позволила компании перевести учет норм и правил безопасности в единую цифровую среду. После успешного запуска клиент вернулся с запросом на новый модуль: управление рисками на производстве. Так проект стал следующим шагом в автоматизации управления безопасностью на предприятии.
Задача: автоматизация управления безопасностью и оценки рисков
Риск на производственном объекте — это конкретный набор факторов: тип объекта, характер выполняемых работ, категория рабочего места, квалификация сотрудника. Комбинация этих переменных определяет степень опасности, а также то, какие меры нужно принять.
Требовался модуль оценки опасностей под нужды предприятия. Где администратор настраивает матрицы опасностей, а сотрудники разных уровней работают с ней в удобном пользовательском интерфейсе. При этом каждый пользователь должен видеть ровно ту информацию, которая относится к его зоне ответственности.
Лист оценки рисков с фильтрацией по подразделению, должности и операции
Аналитика и прототипирование
Прежде чем писать код, мы провели этап сбора и формализации функциональных требований. Бизнес-системный аналитик начал с проработки концепции: вместе с заказчиком определили, как именно должен работать модуль оценки рисков в контексте уже существующей платформы.
На основе концепции создали детальные прототипы каждого экрана будущего модуля. Для административной части: список листов оценки опасностей, экран добавления нового листа с настройкой должностей и уровней опасности, экран настройки мероприятий по их снижению. Для клиентского приложения: экран просмотра листа оценки опасности, отчет о высоких и умеренных рисках, сводный отчет о стоимости мероприятий.
Отдельно аналитик подготовил шаблон файла общего отчета для выгрузки в PDF — чтобы заранее согласовать с клиентом формат, в котором данные будут представлены руководству.
По итогам прототипирования было составлено техническое задание на разработку. В нем описали 17 новых структур данных (контент-типов), три экрана клиентского приложения, кастомный плагин для Strapi с четырьмя экранами и логику формирования отчетов. Этот документ стал основой для всей последующей разработки.
Почему выбрали Strapi
Ключевое архитектурное решение проекта — использование Strapi в качестве бэкенда. Это дало нам несколько важных преимуществ.
Во-первых, гибкость конфигурирования. Модуль рисков построен на большом количестве переменных. Все они могут меняться в зависимости от требований клиента. В Strapi администратор добавляет, редактирует и удаляет элементы справочников самостоятельно, без привлечения разработчиков. Это сокращает операционные расходы и делает систему по-настоящему управляемой.
Во-вторых, возможность кастомизации. Когда стандартного интерфейса Strapi оказалось недостаточно, мы разработали собственный плагин. Он не заменяет платформу, а дополняет ее: сохраняет все преимущества готового решения и при этом дает пользователю удобный инструмент для работы со сложной конфигурацией.
Наконец, скорость разработки. Strapi берет на себя значительную часть рутины: работу с базой данных, API, авторизацию. Команда концентрируется на бизнес-логике. Для проекта с поэтапным развитием — это критично.
Как устроен модуль управления рисками
Модуль состоит из двух уровней: административного и пользовательского. Разберем, как работает каждый из них.
Административная часть
Здесь формируется вся конфигурация рисков: заполняются справочники, настраиваются переменные, из которых складывается матрица оценки. Среди ключевых параметров — тип объекта, характер выполняемых работ, тип рабочего места, дополнительные условия, влияющие на степень опасности.
Комбинация этих параметров автоматически рассчитывает значимость и цветовую степень риска. Система сама формирует итоговую оценку по заданной логике.
Настройка оценки рисков сотрудника в административной части на базе Strapi
Для удобства разработали кастомный плагин для Strapi. Без него конфигурирование пришлось бы вести напрямую через коллекции — разбираясь в структуре хранения данных. Плагин закрыл эту проблему: вместо технических таблиц администратор работает с интуитивно понятным интерфейсом, где все взаимосвязи видны сразу.
Пользовательская часть
Сотрудники компании работают с модулем через веб-интерфейс. Доступ к данным разграничен по ролям: работник видит только свои показатели, руководитель отдела — информацию по всем подчиненным, а в случае необходимости (например, при замещении на период отпуска) может получить доступ и к данным смежных подразделений.
Отчет по рискам умеренной и высокой значимости с выгрузкой в DOCX
Такая система позволяет избежать избыточной открытости данных и при этом сохраняет гибкость: руководитель всегда знает, что происходит в его зоне ответственности.
Автоматический контроль мероприятий по управлению рисками
Отдельный блок модуля — мероприятия по снижению рисков. Это не просто список задач: система фиксирует периодичность проверок, факт прохождения обучения, квалификацию специалистов. Логика простая: если мероприятие не проводилось в срок, то степень связанной с ним опасности автоматически возрастает. Таким образом, система сама сигнализирует о зонах, требующих внимания, без ручного отслеживания каждого показателя.
Отчет о мероприятиях по управлению рисками с периодичностью и стоимостью
Архитектура бэкенда на Strapi
Модуль рисков потребовал серьезной работы на стороне серверной части. Мы спроектировали и реализовали 17 контент-типов в Strapi — каждый со своей логикой валидации и жизненным циклом.
Основные сущности, которые составляют модель данных модуля:
- должности;
- рабочие места;
- операции;
- группы рисков;
- риски;
- источники опасности;
- мероприятия по управлению рисками;
- последствия;
- уровень тяжести последствий;
- вероятность возникновения;
- уровень повторяемости;
- периодичность выполнения мероприятий;
- источник финансирования мероприятий;
- уровни опасности при выполнении рабочих операций;
- планирование мероприятий;
- листы оценки опасности.
Для каждой из ключевых сущностей мы написали кастомные lifecycle-хуки — они обрабатывают изменения данных при создании и обновлении записей. Например, при изменении мероприятия по управлению рисками система автоматически пересчитывает связанные уровни опасности. Мы также реализовали утилиту для валидации обязательных связей между сущностями, чтобы администратор не мог сохранить некорректную конфигурацию.
Отдельная задача — логика включения и отключения подразделений. Когда администратор добавляет или деактивирует подразделение, система корректно обновляет все связанные данные: пользователей, рабочие места, мероприятия. Эта логика оказалась одной из самых трудоемких на бэкенде.
Как устроен фронтенд
Клиентская часть построена на React и включает три основных экрана, каждый из которых прошел путь от верстки до полной интеграции с бэкендом.
Лист оценки рисков
Самый объемный экран модуля. Мы реализовали верстку для десктопных устройств, систему фильтров по должностям, рабочим местам и операциям, а также табличное представление данных с пагинацией.
Отчет о высоких и умеренных рисках
Этот экран позволяет сотрудникам с соответствующими ролями сформировать отчет по операциям с повышенным уровнем опасности. Мы реализовали модальное окно с таблицей и возможность выгрузки в PDF. Формат отчета мы согласовали с клиентом еще на этапе прототипирования, поэтому на этапе разработки расхождений не возникло.
Отчет о стоимости мероприятий
Третий экран — сводный и детализированный отчет о мероприятиях по управлению рисками с привязкой к стоимости. Состоит из двух уровней: сводная таблица с агрегированными данными и экран детализации, вынесенный на отдельный URL.
По всем трем экранам мы также доработали навигационное меню: модуль появляется в панели навигации только для пользователей с соответствующими ролями. Для этого потребовалось проанализировать текущую логику клиентского приложения и реализовать проверку прав на уровне отображения вкладок.
Кастомный плагин
Плагин — центральный элемент административной части модуля. Он заменяет работу напрямую с коллекциями Strapi и предоставляет администратору удобный интерфейс для конфигурирования рисков. Внутри плагина четыре основных экрана:
- Первый. Список листов оценки рисков. Администратор видит все созданные листы, их статусы (черновик или опубликован) и может перейти к редактированию;
- Второй. Добавление нового листа. Здесь создается таблица, в которой по строкам расположены должности, а по столбцам — параметры оценки. Администратор заполняет данные, сохраняет черновик и при готовности публикует лист. При публикации система автоматически генерирует Excel-отчет;
- Третий. Настройка оценки опастностей. Экран с разворачивающимися заголовками, внутри которых находятся таблицы с параметрами. Данные подгружаются из коллекций Strapi и сохраняются обратно при изменении;
- Четвертый. Настройка мер по управлению рисками. По структуре похож на предыдущий, но работает с другим набором сущностей: периодичностью, источниками финансирования, ответственными за выполнение.
Одна из нетривиальных функций плагина — копирование листов оценки для разных должностей. Мы реализовали возможность группировки: администратор может скопировать существующий лист, изменить в нем несколько параметров и опубликовать как отдельную оценку. Это сильно экономит время, когда на предприятии десятки должностей с частично совпадающими профилями рисков.
Как мы работали над проектом
Модуль рисков был детально спроектирован после чего активная разработка шла спринтами. Первый спринт был посвящен созданию контент-типов, валидационной логики, верстке интерфейсов и подготовке мок-данных для тестирования. Когда бэкенд был готов, начался этап интеграции — самый трудоемкий в проекте.
Весь процесс сопровождался код-ревью. Каждая задача проходила проверку перед переносом на тестовое окружение, а в случае серьезных замечаний — дорабатывалась и проверялась повторно.
Отдельного внимания заслуживает этап тестирования. QA-инженер начал работу параллельно с разработкой: написал чек-листы по всем разделам модуля, составил тест-кейсы для административной панели, плагина и клиентского приложения, подготовил матрицу тестирования, на выходе получилось 15 документов.
Разработка кастомного плагина для административной части отставала от реализации пользовательской части. Чтобы наполнить справочники данными тестировщик сначала подготовил структуру данных в виде коллекций в Google-таблице, а затем вручную загрузил записи напрямую в Strapi — от должностей и рабочих мест до источников опасности и планирования мероприятий. Это позволило начать активное тестирование не дожидаясь полной готовности проекта.
После этого начались множественные раунды тестирования. QA проверял плагин по составленной документации, искал дефекты, тестировал клиентскую часть, проверял соответствие ТЗ, проводил повторное тестирование после исправления дефектов. Суммарно на все активности тестирования ушло более 100 часов.
Запуск в эксплуатацию
К развертыванию в продуктивной среде мы подошли с особой осторожностью. Сначала подготовили план: описали порядок миграций, настройку прав доступа по ролям, порядок действий в случае отката.
Затем провели деплой на тестовой площадке. Тогда обнаружили проблему с миграцией данных по должностям, исправили ее до выхода на прод. После этого скорректировали план деплоя, описали настройку прав и разрешений по ролям.
Сам деплой занял около полутора часов. Сразу после него мы выявили и исправили два дефекта: критический, связанный с обработкой данных, и блокирующий, связанный с отображением новых модулей в интерфейсе. Затем заполнили систему стартовыми данными, провели смоук-тестирование, проверили работу старых модулей, чтобы убедиться, что обновление ничего не сломало.
Доработки по обратной связи
После запуска модуля в продакшн клиент начал использовать систему и дал обратную связь. Часть замечаний касалась удобства работы, часть — расширения функциональности. Мы выделили эти задачи в отдельный этап.
Список доработок включал возможность редактирования чек-листов после завершения для роли менеджера, добавление столбцов для удобства отслеживания визитов безопасности, инспекций, автоматическое назначение руководителя подразделения ответственным при создании записи, расширение выгрузки в PDF (добавление номера, даты, ФИО заявителя), открытие доступа к разделу «Лучшие практики» для всех ролей, привязка тяжести и последствий к конкретному источнику опасности в листе оценки рисков, возможность копирования листов для разных должностей.
Каждая задача проходила стандартный цикл: техническое решение, реализация, ревью, тестирование. На весь этап суммарно ушло около 80 часов, включая операционные задачи.
Результаты: что изменилось в управлении безопасностью
Система позволила GRYS Power перевести управление рисками из таблиц в единую цифровую платформу. По сути, компания получила инструмент для автоматизации управления безопасностью на объектах. Такой подход снимает с команды рутину — система позволяет:
- гибко настраивать матрицу опасностей под специфику конкретного объекта, без привлечения разработчиков;
- разграничить доступ к данным по ролям;
- автоматически отслеживать периодичность мероприятий по снижению рисков;
- фиксировать изменения степени опасности в режиме реального времени.
Заключение
Модуль управления рисками — не самый яркий с точки зрения внешнего вида проект. Но именно такие решения составляют основу цифровой трансформации в промышленности: без лишних эффектов, зато с реальной пользой.
Мы начали сотрудничество с GRYS Power три года назад, и продолжаем его сегодня. За это время система прошла путь от MVP до полноценной EHS-платформы с несколькими модулями, останавливаться на этом компания не планирует.
Если вам нужно перевести сложные внутренние процессы в удобный цифровой инструмент и автоматизировать управление безопасностью, — расскажите о задаче. Оставьте заявку ниже, и мы вместе разберемся, как это лучше реализовать.
