Привет, Хабр! Меня зовут Илья Ульянов, я архитектор информационных систем и руководитель проекта «Охота на риски» в ЕВРАЗе. Расскажу вам, что необычного в дизайне этого проекта. 

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

Заядлый геймер, выполняющий задания за вознаграждения и место в рейтинге, — далеко не первое, что ассоциируется с суровыми горняками и металлургами. Где видеоигры, а где техника безопасности и мониторинг инцидентов? Командная работа, ачивки, тематические сезоны — этого не может быть в цехах. Или может?

Реальность, как это нередко бывает, оказалась куда неожиданнее самых смелых предположений. Идея совместить две, казалось бы, слабо совместимые вещи принесла хорошие результаты. О том, как мы запустили мобильное приложение “Охота на риски”, рассказываем в этой статье.

Вылазки на охоту за рисками

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

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

В поисках более эффективного подхода в 2020 году мы запустили проект «Риск-управление». Мы стали рассматривать риски иначе: не только расследовать инциденты, но и мониторить процессы, и менять их проактивно — не дожидаясь проблем.

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

Поначалу этим занимались команды охотников на риски — группы по 3–4 человека, обходившие цеха с задачей анализа и динамической оценки всего, что они видели: от подозрительно висящей трубы до недозакрученного болта. Мы фиксировали все найденные риски — и вскоре их набралось несколько тысяч.

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

Для приоритезации мы разработали Матрицу оценки рисков. Параметра всего два: 

1. с какой вероятностью произойдёт несчастный случай,

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

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

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

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

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

Геймификация как способ мотивации

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

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

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

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

Кроме того, мы объясняли свою работу сотрудникам, и они со временем всё больше понимали: в их интересах сделать рабочие места безопаснее.

Итак, с помощью Матрицы мы определили 11 основных красных рисков и защитных мер к ним. Если хотя бы одной меры нет — работа останавливается. Для этого у нас в приложении существует отдельная фича — «Отказ от небезопасной работы». Сотрудник подаёт заявку, система уведомляет риск-менеджеров, а те связываются с руководителями подразделения, которые и устраняют проблему.

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

Сперва начальники возмущались: посторонние сотрудники жалуются на их участки. Но потом прикреплённые к участкам риск-менеджеры донесли, что обнаружение рисков не влечет наказания, но позволяет сделать рабочее место безопаснее. А кто увидел и первым заявил о рисках — получит баллы.

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

Сложнее было решить, во что эти баллы конвертировать: чтобы и работники видели ценность, и трудовое законодательство соблюдалось, и система подходила всем предприятиям и всем работникам ЕВРАЗа.

Конечно, было бы замечательно конвертировать баллы в дополнительные дни отпуска или прибавку к зарплате. Но оформление этого юридически и технологически потребовало бы перестроить все процессы в ЕВРАЗе под нужды «Охоты на риски». На что мы пойти не смогли: всё же приложение для компании, а не компания для приложения. 

Из остальных вариантов проще и привлекательнее всего оказалось конвертировать баллы в выбираемый лично сотрудниками мерч компании или купоны в интересующих их магазинах.

Обтачиваем систему

Повторюсь: ЕВРАЗ — это крупное предприятие с легионами сотрудников и многочисленными цехами по всей России — их общую площадь можно сравнить с небольшим городком. Цеха не только большие, но и полны металлоконструкций, и порою далеки от крупных населённых пунктов. Всё вместе это означает нестабильную цифровую связь. 

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

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

Физической архитектурой сетей мы не ограничились: уменьшили нагрузку программно. Иначе говоря — встроили в приложение (и в веб-версию) компрессию фото- и видеоматериалов с запечатлёнными рисками. Для фото обеспечивается сжатие до 70%, для видео — 2-8 Mbps с разрешением 720p.

Также мы разработали маски, фильтры и уникальные водяные знаки — чтобы отличать попавшие в интернет фото и видео из нашей системы от посторонних. Вдобавок эти решения гарантируют нам, что о риске заявил именно сотрудник ЕВРАЗа, а не некто эксплойтящий систему с помощью фейков. В эпоху гиперинформации как никогда важно верифицировать, что реально, а что нет.

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

Поэтому если работник всё-таки никак не может заявить о риске самостоятельно — он имеет право попросить об этом своего начальника. И на самый крайний случай — заявить о риске всегда можно анонимно с устройств или компьютеров предприятия.

Под капотом «Охоты на риски»

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

Мы адаптируем приложение под разные устройства и версии операционных систем. Уже поддерживается разношёрстный зоопарк моделей, версий Android и iOS. А в дальнейшем мы планируем разделить наше приложение на несколько самостоятельных.

Чтобы работать с этим системно, мы собрали статистику: какие устройства есть у сотрудников. Отталкиваясь от полученных данных, мы определили технические требования для нашего приложения. Так, в случае Android — подходят версии от 6.0, а у iOS — от 11.4.

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

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

Писать бэкенд было проще всего, поскольку для него у нас есть единая кодовая база на C# и все версии приложения обращаются к ней через API. Основную сложность представлял фронтенд, где у нас нет универсального кросс-платформенного решения. Для мобильных платформ мы используем нативные приложения на Kotlin и Swift, для статистики и аналитики — Power BI, а для некоторых проектов — Python.

Для ускорения процессов разработки и обеспечения слаженной работы фронтенда и бэкенда мы применили архитектурный шаблон «BFF», смысл которого – использовать общие типы определений в коде front и back через отдельный модуль, который могут использовать обе стороны. Так мы смогли частично объединить кодовую базу фронтенда и бэкенда через C#, что упростило разработку.

Еще одним примером объединения частей нашего ПО является использование глобальной конфигурации, а также таблиц и скриптов настройки, которые влияют на все части работы системы – начиная от сервера данных и заканчивая мобильным, web- и Report/BI приложениями.

В фокусе нашего внимания находились отзывчивость системы и скорость обработки запросов. И этому не должны были помешать ни большое количество активных пользователей, ни разнообразие запросов и часовых поясов, ни необходимость системы быть онлайн 24/7.

Пока мы писали код, мы регулярно проводили ревью, аудиты безопасности и контроль версий на наших локальных репозиториях. А контроль версий мы организовали по модели 3-звенного ландшафта: dev (разработка), test (тестирование с эксплуатацией фокус-группой) и prod (продакшен), где разработка, тестирование и релиз делаются последовательно.

В период с 01.10 по 13.12 мы получили 371 636 заявок на риски: 76 % через мобильное приложение и 24 % — через веб-версию. Как я говорил, мы должны хранить эти данные в течение 15 лет на случай проверок контролирующих органов. Для этого мы использовали собственный ЦОД с реляционной базой данных. Архитектурно мы используем как монолитный подход к серверам, так и контейнеризацию.

Каждое предприятие имеет свои группы для обработки данных, а статистическая и аналитическая отчётность хранится в нашем ЦОДе централизованно. Часть обработки происходит автоматически, так как информация о риске уже отмечена в заявке, а оставшуюся обработку выполняет оператор. Решение о риске передаётся через приложение с push-уведомлением и отправляется на корпоративную почту.

ЦОД обеспечен зеркалами, чтобы избежать избыточных нагрузок и гарантировать работу даже в экстренных ситуациях, таких как ураган. А для долгосрочной работы ЦОДа без электропитания предусмотрены дизель-генераторы и источники альтернативной энергии.

Рассматриваем переход от централизованной системы к распределённой — по разным регионам России.

Что дальше

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

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

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

Также мы рассматриваем переход на отечественные аналоги софта и железа: например, на дистрибутивы Astra Linux для образов контейнеров и серверов.

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

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