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

• Как простое single-page-приложение стало лучшим цифровым решением на рынке (по версии ComNews Awards 2022)
• Что такое Инспекция на производстве?
• Бизнес-задачи нашего клиента
• Какие боли должна была вылечить новая система
  • Коммуникации
  • Временные затраты
  • Согласование
  • Выбор подрядчика
  • “Бумажный” документооборот
  • Отсутствие готового решения и импортозамещение
• Быстрое принятие решения – быстрый старт
• MVP перерос в законченный проект
• Жизненный цикл инспекции (в рамках сервиса)
  • Сценарий создания и согласования заявки
  • Сценарий проведения инспекции
• Быстрый результат
• Обезболивающее
• Заключение

Как простое single-page-приложение стало лучшим цифровым решением на рынке (по версии ComNews Awards 2022)

Кейс из статьи – реальный проект, который ИНТЕРВОЛГА разработала для компании ЕВРАЗ. На примере проекта можно сделать вывод: для создания сложной системы не обязательно использовать экзотическую платформу.

«База инспекций» – это отдельно разработанный компонент уже существующего web-приложения.

Особенности системы:

• различный функционал для нескольких групп пользователей;

• вместо разработки нового сайта использовали уже существующий;

• бэкенд-разработка – существующий сайт на Битрикс;

• фронтенд-разработка – новый компонент уже существующего на сайте web-приложения.

Заказчик согласился на наше предложении о модификацию веб-приложения и разработке на базе действующего сайта на Битрикс. Отказ от разработки с нуля на новой платформе не только сократил сроки реализации проекта, но и сэкономил 15% бюджета.

Результат – “База инспекций” стала лучшим цифровым решением для инспекторского надзора в металлургии по версии ComNews Awards 2022.

Что такое Инспекция на производстве?

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

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

Для тысячи тракторов нужна тысяча двигателей. Вагоны с дорогой продукцией пересекают сотни километров, после чего продукцию принимает заказчик.

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

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

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

Проведение инспекций на производстве для большого бизнеса – важный процесс. Контроль производителя позволяет избежать срыва сроков и проблем с возвратом бракованной продукции.

Отсутствие практики инспекций на производстве влечет за собой определенные риски. Прием, проверка и возврат товара (в случае брака) увеличивает срок получения готовой продукции в пять, иногда в десять раз. Об этом мы узнали из очного разговора с клиентом, для которого разрабатывали систему. 

Инспекция на производстве – не панацея. Всегда есть вероятность повреждения груза при доставке или ошибке инспектора. Однако возможность проверки товара “здесь и сейчас”, пока он ещё на территории производителя, снижает описанные выше риски на порядок.

Бизнес-задачи нашего клиента

Для реализации проверок на производстве нашему постоянному клиенту, компании ЕВРАЗ, требовалась надежная система со строгим разграничением прав доступа. Инициатором инспекции должен стать сотрудник компании, а исполнителем – внешний инспектор. Проще говоря, запускает процесс заказчик, а результаты работы сдаёт наёмный специалист.

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

Для запуска процесса инспекции пользователь должен пройти двухэтапное вертикальное согласование:

• сначала заявку “одобряет” Согласующий – сотрудник, отвечающий за все инспекции;

• затем Администратор Инспекции – руководитель.

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

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

Какие боли должна была вылечить новая система

Коммуникации

Инспекции на производстве проводились задолго до разработки “Базы инспекций”. Основная боль, с которой приходилось мириться – неоднородные каналы получения данных.

Инспектор, находящийся на условном заводе, собирал необходимые данные, переносил их в отчёт, после чего отправлял на email заказчика. Если отчёт был неполным, заказчик связывался с исполнителем, просил внести изменения или перепроверить данные, после чего всё повторялось заново. Таких итераций могло быть несколько.

Временные затраты

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

Согласование

Третья, но не менее важная проблема – это согласование инспекции. За прием продукции отвечают не начальники предприятий и даже не начальники отделов. Это работа высококвалифицированного сотрудника, но не управленца. Бюрократия в больших компаниях – это норма. Для любого важного процесса, который нужно запустить, необходимо разрешение… или, как в нашем случае, несколько согласований. Специалистам приходилось ходить с заявками по кабинетам с бумажным документом, получать отказы, вносить правки и снова носить заявки на подпись. Производство, тем временем, идёт, а заказчик 

Выбор подрядчика

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

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

Процесс занимал от одного дня до недели.

“Бумажный” документооборот

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

Архаичный обмен бумажными документами – это триггер для руководства, которое выступает за современные способы коммуникации между узлами (сотрудниками, клиентами, подрядчиками) того или иного процесса.

При проведении инспекций на производстве обмен документами делится на внутренний и внешний.

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

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

Отсутствие готового решения и импортозамещение

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

До принятия решения о собственной разработке, заказчик рассматривал готовые цифровые решения. Тут-то и выяснился неприятный факт: готовое решение – это не всегда выгодно в сравнении с разработкой новой системы. Более того, “готовое” решение – только в теории. Это просто термин. Для гигантских промышленных компаний не существует готового решения – они сродни государствам. Со своей “иерархией”, со своими “спорными территориями”, “дотационными регионами” и, даже, “оппозицией”.

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

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

Быстрое принятие решения – быстрый старт

Куратор проекта со стороны заказчика был полностью погружен в проект. Время отклика на запрос любой информации – меньше часа. Согласование предложенного решения – в тот же день.

Такое взаимодействие сказалось на опережении срока релиза и попадании в бюджет.

У Заказчика в распоряжении был сайт авторизации на CMS Битрикс. Изначально “Единый сервер авторизации” разрабатывался для бесшовного перехода между другими сайтами компании. За несколько лет его функционал значительно расширился новыми сервисами.

CMS Битрикс оказался дружелюбной средой для такого симбиоза – каждый сервис представлял собой отдельные страницы единого web-приложения. Они имели собственный функционал и не влияли на бесшовную авторизацию.

Было решено пойти по проверенному пути и “База инспекций” разрабатывалась как страница существующего web-приложения.

В качестве frontend-фреймворка был выбран Vuetify, так как он обладает большой библиотекой компонентов пользовательского интерфейса для приложений Vue и отлично подходит для быстрого создания пользовательских интерфейсов веб-приложений. Это тоже изведанная тропа – другие сервисы на “Едином сервере авторизации” разработаны также с использованием Vuetify.

Ещё одним “бустом” для проекта стал отказ от дизайна в классическом понимании. Заказчику продемонстрировали компоненты Vuetify и примеры реализованных интерфейсов – главным условием было соответствие общему дизайну сайта.

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

Благодаря творческой свободе разработчиков (в разумных пределах) и быстрой обратной связи от заказчика, работа на проекте, что называется, не буксовала.

MVP перерос в законченный проект

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

Но это не всегда так… Работая по методологии Agile разработчики не связаны жесткими ограничениями по срокам. У Заказчика, конечно, есть определенные требования при более-менее сформированном списке задач для MVP: “К первому числу нам нужно, чтобы сайт был опубликован, чтобы можно было согласовать заявку и взять её в работу…”

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

Как же поступить с освободившимся ресурсом? Чаще всего, заказчик переносит задачи из этапа развития в MVP.

Так вышло и с разработкой Базы Инспекций. По мере того, как проект опережал сроки разработки, разрастался и функционал MVP – в работу ставились все задачи, которые Заказчик планировал реализовать в следующем этапе разработки.

Было решено добавить:

• Режим доработки для заявок – согласующие могли вернуть заявку инициатору с комментарием. Причем, не с общим комментарием, а с привязанным к конкретному пункту заявки. Каждый “проблемный пункт” маркируется красным. Добавили счетчик замечаний.

• Чат между инициатором инспекции и инспектором.

• Оценка инспектора (обязательная, после закрытия инспекции).

• Рейтинг инспекторов (средняя оценка по результатам проведенных инспекций).

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

Жизненный цикл инспекции (в рамках сервиса)

Если вам скучно читать сценарий работы смело листайте к следующему пункту статьи. В случае, если вам хочется узнать побольше про построение процесса инспекции на производстве, как говорится, “не переключайтесь” – изучение сценариев поможет глубже понять процессы сложной системы и практическую пользу от её разработки, а также увидеть разницу между планируемым MVP и окончательным результатом.

Ниже описан итоговый сценарий, после дополнительных доработок.

Сценарий создания и согласования заявки

• В компании есть люди, которым нужно, периодически, проводить инспекции. Они непосредственно вовлечены в процесс закупки продукции и наделены полномочиями инспектировать деятельность производителя.

• В рамках сервиса они были добавлены в группу “Заявители”

• Просто так начать инспекцию нельзя – Заявитель не может самостоятельно выбирать инспекторов и самому себе разрешать запуск процесса.
  
  

• После заполнения информационных полей заявки (тип продукции, наименование товара, количество, подпредприятие-получатель и т.д.), Заявитель отправляет её на согласование.
  
  

• Первым заявку согласует пользователь из группы “Согласующие”. Это сотрудники с бо́льшим количеством полномочий. Если упростить иерархию в процессе, это начальник Заявителя.

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

• Заявитель не сможет отправить заявку на согласование повторно, пока не исправит замечания.

• Если замечаний нет, заявку можно согласовать.
  
  

• Принимает решение по заявке Администратор Инспекции.

• Согласование заявки аналогично Администратором и Согласующим аналогичны.

• После согласования, Администратор приглашает Инспекторов к участию.

• Выбираются кандидаты из списка пользователей, зарегистрированных в системе.

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

• После выбора Инспектора всем участникам, подавшим заявки, отправляются уведомления с результатом.

Сценарий проведения инспекции

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

• Инспектору в заявке открывается блок с отчетами

• В определенные этапы проверки, Инспектор загружает отчёты, отмечает риски для поставки
  
  

• Отчёты доступны Заявителю в любой момент, сразу после загрузки

• Инспектор и Заявитель могут общаться посредством чата, который становится доступен сразу после согласования заявки

• После того, как Инспектор загружает последний отчёт, он закрывает заявку

• Заявитель может отклонить закрытие, указав в комментарии причину (например: “Добавьте сводный отчёт по доп. затратам на проведение инспекции”).

• Если итоги инспекции устраивают Заявителя, он может закрыть заявку.

• После закрытия заявки, Заявитель также оценивает работу Инспектора.

• Средняя оценка по всем инспекциям формирует рейтинг Инспектора.

• Рейтинг всех инспекторов доступен в отдельной форме.

Быстрый результат

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

На отладку системы и отработку замечаний от контрольной группы ушло две недели. Вместе с введением в опытную эксплуатацию разработка заняла 4 с половиной месяца. Команда разработчиков: 2 бэкенд-программиста, 1 фронтенд-разработчик и 1 аналитик.

В итоге, проект был сделан быстрее запланированного срока с расходом бюджета в 85% от запланированного. И это несмотря на то, что финальным результатом была готовая система со всем дополнительным функционалом, задачи по которому ждали своего часа в бэклоге и даже не оценивались (бюджет под них не закладывался).

Одним из факторов успех, безусловно, является вовлеченность руководителя проекта со стороны заказчика. Иногда, во время многочисленных Zoom’ов разгорались нешуточные споры о той или иной задаче. Да, мнение заказчика и разработчиков не всегда могут совпадать. Если, например, аналитик считает тот или иной функционал неудобным для пользователя – он может… нет – должен сказать об этом заказчику. Но делать так можно только в случае, если специалист может обосновать свою позицию и, что важнее, предложить альтернативное решение.

Обезболивающее

Коммуникации

Все коммуникации по процедуре инспекции – от подачи заявки до закрытия проведенной инспекции – замкнуты в системе “База Инспекций”.

Если сотрудник, подавший заявку, заполнил её неправильно, он получит почтовое уведомление со ссылкой на заявку. При переходе по ссылке, заявитель увидит, где ошибся и прочитает комментарий согласующих. Повторное согласование возможно только после внесения изменений… Или после ответа на замечание – у пользователя должна быть возможность настоять на своей правоте.

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

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

Временные затраты

Никто не замерял точное время от подачи заявки до закрытия инспекции. У нас есть только обратная связь от заказчика: скорость принятия решения на разных этапах процесса увеличилась в 3-5 раз.

Согласование

Процесс стал удобным и полностью виртуальным. Система маркировки (оранжевый = ожидание, красный = призыв к действию) сделала отслеживание статусов заявок комфортным, а позже – привычным. Отпала необходимость в “кабинетной логистике” – если руководителя нет на месте, он может согласовать запуск инспекции из дома или со смартфона.

Выбор подрядчика

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

“Бумажный” документооборот

Согласование заявки на проведение инспекции стало полностью цифровым.

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

• замечания по заявке теперь видны сразу;

• алгоритм оповещений рассылает уведомления, если требуется какое-то действие со стороны пользователей;

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

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

Отсутствие готового решения и импортозамещение

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

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

Заключение

По завершении проекта с заказчиком мы расстались с хорошими впечатлениями друг от друга. Расстались, правда, ненадолго – 2 декабря мы снова встретились на церемонии награждении «ComNews Awards. Лучшие решения для цифровой экономики».

По традиции, ComNews вручают награду заказчику и разработчику. Мы взяли награду в номинации "Лучшее цифровое решение для инспекторского надзора в металлургии".

Возможно вам будут интересны другие совместные проекты с ЕВРАЗ:

Кейс: Разработка личного кабинета на Битрикс для клиентов компании ЕВРАЗ.

Личный кабинет подрядчика: ускорение процесса сбора документов работников на объектах компании ЕВРАЗ в 15 раз.

Кейс: алгоритм возврата товара на маркетплейсе поставщикам компании ЕВРАЗ.

Личный кабинет согласования проектной документации для подрядчиков ЕВРАЗ.

Enterprise-проект — личный кабинет клиентов компании ЕВРАЗ.

Евраз Металл Инпром — личный кабинет клиентов.

Разработка сайта ванадиевых активов — ЕВРАЗ Ванадий.

Лендинг на Tilda для реализации щебня компании ЕВРАЗ.

Разработка B2B-личного кабинета для клиентов компании ЕВРАЗ.

Личный кабинет клиентов металлургической компании ЕВРАЗ Металл Инпром.

Личный кабинет для проектных организаций ЕВРАЗ.