GRYS Power — одна из первых энергосервисных компаний в России, которая помогает промышленным предприятиям управлять энергопотреблением. Компания выполняет масштабные проекты по оптимизации и модернизации систем отопления, освещения, очистки сточных вод, подачи сжатого воздуха и не только.
Деятельность компании в том числе направлена на улучшение условий труда. Внутренние подразделения Grys Power разрабатывают меры, контролируют их соблюдение и координируют работы по предотвращению угроз здоровью сотрудников. Все это требует разных отчетов и документов под каждую из задач.
Вовлечь максимальное количество сотрудников на всех уровнях, чтобы любой мог сделать вклад в улучшение условий труда и сообщить о потенциальных угрозах здоровью. Даже если это что-то на первый взгляд незначительное, как замена лампочки. Безопасность рабочих мест и отсутствие травм хорошо влияют на настроение работников и имидж работодателя, поэтому вопросу безопасности уделяется много внимания.
Весь документооборот службы охраны труда происходил во внутренней EHS-системе, которую предоставляло французское подразделение компании. Это было удобно, но из-за сложной политической обстановки пришлось отказаться от ее использования. Без единой системы хранения, просмотра и управления этими файлами сотрудникам и менеджменту не осталось иного выбора как вернуться к ручному заполнению бумажных форм и переносу данных в Excel.
Заменить привычную систему на новую. Это поможет компании управлять рабочими процессами, документооборотом и обеспечит автоматизированной отчетностью.
Лишившись системы и доступа к ИТ-специалистам французского подразделения, компания стала перед выбором: найти готовый аналог среди отечественного ПО или разработать индивидуальное решение.
Найти готовый российский аналог компании не удалось, так как доступные решения либо лишены нужных функциональных возможностей, либо требуют существенных доработок, а архитектура ограничивает дальнейшее развитие. Руководство сконцентрировалось на разработке индивидуального решения, но и здесь не обошлось без препятствий.
Индивидуальная разработка — это дорого, а бюджет на создание первой версии системы был ограничен тремя миллионами рублей.
Чтобы понять, как оптимизировать процесс разработки, необходимо знать, что из себя должен представлять готовый продукт. За основу взяли функциональность прошлой системы и уже на этапе создания спецификации выбрали стратегию оставить только ключевые функциональные возможности для первого релиза. На этом этапе важно согласовать необходимый функционал и решить уточняющие вопросы.
Пример страницы прототипа
Первым этапом была разработка функционального прототипа, это позволило на ранних этапах выявить ненужный функционал из ТЗ и внести корректировки в некоторые основные функции приложения.
Система предназначена для сотрудников компании, поэтому требования к графическому интерфейсу были в удобстве, а не в красоте. От этапа дизайна и роли дизайнера на проекте отказались, и прототип в этом помог.
Для пользовательского интерфейса подключили готовую UI-библиотеку. Решили выбрать Ant design, потому что ключевыми особенностями библиотеки являются удобные компоненты таблиц и форм, которых в проекте было много.
Отказ от индивидуального дизайна помог приблизиться к желаемому бюджету, но все равно еще нужно думать как организовать разработку, и при этом выполнить проект на актуальных технологиях, не блокирующих возможность дальнейшего развития.
Для реализации серверной части и административной панели выбрали Strapi, самую популярную Headless CMS с которой создали ряд проектов. Система покрывает часть требований к админ-панели из коробки и позволяет существенно сэкономить деньги, так как избавляет от необходимости выделять на проект бэкенд-разработчика.
Важным требованием к приложению была поддержка двух языков — русского и английского. Для этого подключили i18n, который позволяет настроить перевод статических данных.
Процесс создания MVP состоял из трех этапов:
Для удобства восприятия, дальнейшее описание будет следовать одной структуре: функциональный блок и то, что система должна уметь.
Пример настройки доступов для ролей через user-permissions
На первом этапе нужно было настроить админ-панели, системы авторизации в пользовательском приложении и редактирование данных профиля. Администраторы добавляют пользователей как по одному, так и массово импортируют из excel-файла, а также связанные с ними сущности: подразделения и организации.
Приложением пользуются сотрудники подразделений предприятий. Эти пользователи имеют в системе роли «Работник» или «Руководитель». Члены менеджмента, как и администраторы, имеют свои отдельные роли: «Менеджер» и «Администратор». У каждой роли есть разные доступы, например, «Работник» не может взаимодействовать с визитами безопасности, а «Менеджер» не имеет доступа к чек-листам.
В Strapi есть встроенный плагин user-permissions, который позволяет реализовать добавление аккаунтов в систему через админ-панель. Это было одним из технических требований.
Добавили в приложение загрузку пользователя из файла. Strapi создает из коробки аккаунты и сущности, которые с ними связаны. Администратор через интерфейс “Редактора контента” создает необходимые элементы коллекций, в нашем случае — подразделения, организации и пользователей.
Пример создания пользователя через редактор контента
Strapi не позволяет массово создавать пользователей, поэтому написали отдельный плагин, который загружает excel-файлы.
Результат работы плагина загрузки файлов:
Результат работы плагина загрузки файлов
Столкнулись с проблемой: при добавлении пользователя администратор не должен знать его пароль, но без указания пароля процесс создания не сработает. В форме создания аккаунта скрываем пароль и отправляем ссылку на завершение регистрации на почту. После перехода по ссылке пользователь может указать пароль.
Письмо с ссылкой для установки пароля
Форма установки пароля
Александр Клыков
фронтенд-разработчик
Иногда необходимый функционал админ-панели Strapi не предоставляет из коробки. Когда дело касается какой-то комплексной логики, вроде массовой загрузки пользователя, крайне полезным инструментом оказались кастомные плагины. Они позволили реализовать дополнительный функционал админ-панели без вмешательства в код Strapi.
Другая проблема — перевод на два языка. Статические данные пользовательского приложения переводились через i18n и словари. Админ-панель переводилась через внутренние словари Strapi. Однако с динамическими данными все сложнее. Чтобы решить проблему, добавили поля для русского и английского текста в админ-панель.
Пример полей на двух языках
Если пользователь, которого зарегистрировали в систему, забудет пароль от аккаунта, то попробует его восстановить. Strapi такой функционал предоставляет.
Однако шаблон письма-восстановления на одном языке не устраивал клиента, поэтому его нужно было изменить и сохранить работоспособность ссылки для сброса пароля. Для этого добавили к письму восстановления собственный текст на двух языках, так как просто подставить текст в раздел “шаблоны писем” настроек нельзя.
При сбросе пароля или авторизации для отправки писем ничего специально делать не нужно, инструмент с этим справляется штатно. Но шаблоны не подходят для модификации писем при восстановлении пароля к админ-панели, поэтому потребовалось написать отдельную логику.
Страница авторизации
Страница просмотра профиля
По итогу первого этапа у нас была готова рабочая админ-панель, через которую можно регистрировать пользователей, приложение с авторизацией и просмотром данных профиля.
В компании есть менеджеры, которые посещают подразделения и оценивают работу сотрудников. Такие посещения оформляются в «Визиты безопасности» — форму отчета с указанием нарушений, хороших практик и важных моментов. В пользовательском приложении этот отчет можно создать и заполнить.
Общая страница визитов безопасности
При создании пользователь заполняет базовые данные о том, где и когда пройдет визит, а также указывает приглашенных сотрудников. После сотрудники получают данные о мероприятии в письме на почту.
Создание визита безопасности
После визита менеджер завершает заполнение отчета, заполняя последовательно пять страниц формы. Первая дает возможность перепроверить введенные данные при создании.
Первая страница завершения визита
Вторая и третья представляют собой чек-листы, которые формируются по активированным шаблонам.
Заполнение чек-листа в визите безопасности
Заполняются шаблоны чек-листов через административную панель в виде ответов на общие и уточняющие вопросы.
Формирование чек-листа в админ-панели
Четвертая страница — форма, где менеджер может указать позитивные и негативные аспекты обеспечения безопасности на производстве, а также приложить фото. Прогресс заполнения этой и других страниц можно сохранить по нажатию кнопки.
Страница заполнения результатов визита
Последняя страница выводит все данные визита для перепроверки и дает возможность завершить отчет. Заполненный отчет можно скачать в двух форматах.
Последняя страница завершения визита
На экране отчета по визитам безопасности отображается таблица с данными по завершенным визитам. Эту таблицу можно скачать в excel. Реализовали возможность через библиотеку xlsx.
Страница отчета
В экран статистики можно загрузить сводный отчет по визитам, выбрав подразделение и год. Отчет представляет собой более полную версию данных, которые отображаются на странице. Его можно скачать в pdf.
Для работы с pdf выбрали ReactPDF, поскольку требовалось отобразить данные на несколько страниц. Файл формируется при загрузке страницы.
Экран статистики
В pdf-формате можно скачать визит безопасности с основной страницы. Возможность создавать запросы и формировать документ по нажатию на кнопку.
После завершения второго этапа была готова единая система создания и управления визитами безопасности. Кроме того, имелось три разных типа документов, которые формировались автоматически и были доступны для загрузки из единого приложения.
Александр Клыков
фронтенд-разработчик
Многие проекты по документообороту включают в себя комплексные разделы по работе с отчетностью. В нашем случае таких разделов было несколько, самый крупный в виде "Визитов безопасности". Перед тем, как приступить к работе над ними, мы строили диаграммы классов, опираясь на ТЗ и созданный ранее прототип. Это позволило обойти острые углы с самого начала работы над разделами.
С визитами безопасности работают менеджеры и администраторы. Задача третьего этапа — добавить функционал для работников и руководителей подразделений.
В части приложения «Я Инспектор» пользователи могут взаимодействовать с заявлениями об обнаруженных нарушениях техники безопасности.
Основная страница заявлений
Заявления по функционалу похожи на визиты безопасности. Для создания заявления нужно заполнить данные о нарушении. Заявление можно завершить после обработки и описания того, как опасность была разрешена. В любой момент времени доступно редактирование.
Часть редактирования завершенного заявления
Результаты заявления автоматически формируются в pdf-документ. На странице «Отчет — Я инспектор» можно скачать отчет по заявлениям в формате Excel. Страница «Статистика» предоставляет возможность выгрузки pdf-файла с данными о поданных заявлениях в подразделении за год.
Страница отчета по заявлениям
Страница статистики по заявлениям
Заявления для пользователей отображаются разные. Работник может увидеть только свои заявления, руководитель — только заявления своей команды, а менеджер — все заявления. Подобное разделение данных по ролям характерно для всего приложения.
Помимо заявлений, пользователи могут заполнить «лучшие практики», описать эффективные способы обеспечения безопасности труда на производствах.
Страница лучших практик
Последний вид документа в приложении — заполнение чек-листов. Это структурированный опрос по шаблону. В шаблонах несколько контрольных точек. В них пользователь должен указать статус, дать комментарий, загрузить фото и написать, кто и когда должен разрешить указанные проблемы.
Прохождение чек-листа
Результаты чек-листов автоматически формируются в pdf. А список чек-листов можно скачать в excel-формате.
Страница выгрузки отчета по чек-листам
Итоги третьего релиза: команда разработчиков добавила еще три документа со стандартным созданием и управлением. Пять новых типов файлов, которые создаются автоматически, теперь доступны для скачивания из одного приложения. Эти данные разделены по ролям, так что менеджеры могут управлять процессами и контролировать доступ к документам.
Геворг Данелян
Tech Lead
На примере GRYS Power можно выделить следующие ключевые моменты:
Все эти ключевые решения позволили разработать полноценное приложение всего за 4 месяца силами двух frontend разработчиков
---
Выбранный стек технологий и разработка прототипа позволили быстро создать MVP команде из двух человек. Со многими стандартными задачами бэкенда, такими как REST, админ-панель, менеджмент контента, авторизация, Strapi справился без дополнительных настроек, а для уникальных задач легко подобрать готовые плагины или написать собственные.
В результате у службы охраны труда GRYS Power появилась уникальная система для работы с документами и управления рабочими процессами. В этом же приложении сотрудники и руководители ведут работу в рамках своих подразделений.
