Цифровизация работы сервисного центра

Проблематика управления сервисным подразделением мне знакома. Еще будучи руководителем я уделял много времени автоматизации процессов и мечтал максимально цифровизировать процессы в подразделении чтобы повысить эффективность управления.

в 2021 году мне представилась возможность применить свои знания в управлении сервисом и программировании при проектировании и создании web-приложения для сервисного центра высоковольтного оборудования российского подразделения Hitachi Energy (ранее подразделение АББ Электрические сети).

Для некоторых процессов в компании уже были внедрены решения от известных брендов: система управления ресурсами предприятия от SAP и система управления взаимоотношениями с клиентами от SalesForce. Это большие, тяжелые и очень дорогие в поддержке решения. Внедрение какого-либо нового функционала занимало месяцы, если и вообще было возможным из-за процесса внутренних согласований. Объем внедрения каждой системы согласовывался глобально и зачастую не учитывал пожелания отдельных сервисных подразделений.

Получалось, что некоторые процессы были автоматизированы очень хорошо, а некоторые оставались белым пятном в ландшафте цифровизации и каждое подразделение само решало как им жить с этим. Чаще всего сотрудники самостоятельно организовывали работу и хранение информации с помощью таблиц MS Excel или структуры папок на корпоративном сервере. Некоторые также использовали базовый функционал MS SharePoint.

В частности, информация о текущей работе сервисного подразделения хранилась в виде отдельных документов в SharePoint, а система учета работы склада в подразделении представляла собой файл MS Excel, в котором содержалась текущая информация от запасах приборов, инструментов, а также других забалансовых активов на складе. Периодически начальник склада обновлял наличие остатков на складе и распространял информацию среди сервисных инженеров для возможности подготовки запросов на комплектование оборудования и запасных частей для выполнения следующего сервисного проекта. Оперативной и точной информации о наличии приборов и инструментов для заказа у сервисных инженеров не было. История использования приборов и инструментов не велась.

В начале проекта заказчик ставил перед проектом следующую задачу:

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

В процессе обсуждения проекта список задач дополнился:

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

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

• Отработать и отладить функционал и процессы в локальном сервисном центре высоковольтного оборудования для масштабирования разработанного решения в сервисных подразделениях заказчика в других странах (боле 75 подразделений по всему миру) .

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

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

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

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

Для реализации web-приложения было использован следующий стек технологий:

• Операционная система: Linux Ubuntu
• База данных: PostgreSQL
• Backend: Django, Nginx
• Frontend: Django, Tabulator.js
• CSS: Bootstrap

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

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

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

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

• Модуль Проекты - для управления информацией об сервисных проектах, в том числе резервированиями - объектами-интерфейсами, предназначенными для организации бронирования материалов на складах.
• Модуль Склады - для управления складскими запасами
• Модуль Продукты - для ведения справочника используемых материалов на складах
• Модуль Задания - общий модуль, который позволяет управлять заданиями как для проектов (выполнение работ), так и по отдельным резервированиям или запасам на складах. Например, организовать документальное ведение журналов поверки грузоподъемных механизмов на складе или организовать обязательный ежедневный отчет о фактической геолокации инженера.
• Модуль Комментарии и Документы - для возможности создания и просмотра комментариев к объектам данных, а также сохранения документов с привязкой к отдельным проектам, заданиям, резервированиям или запасам на складе. Например, для запаса на складе сохранять инструкцию по эксплуатации, паспорт или Свидетельства о поверке - всего, что может пригодится инженерам при выполнении работ на объектах.

Для информирования о событиях в системе, кроме использования электронной почты, был создан Telegram bot, позволяющий получать уведомления от системы, а также получать несколько отчетов, актуальных для ежедневной работы пользователей. С помощью бота также был реализован функционал контроля за местоположением сотрудников.

Для быстрого доступа к релевантным элементам системы во все формируемые отчеты был добавлен QR-код со ссылкой на страницу с соответствующим контентом.

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

• менеджеры проектов
• руководители менеджеров проектов
• сервисные инженеры
• руководители сервисных инженеров
• складские работники
• руководители складов
• получатели отчетов
• операторы данных продуктов - для редактирования справочника продуктов
• согласующие - для организации процесса согласования проектов и резервирований в системе

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

Был проведен анализ существующих бизнес-процессов у Клиента и разработана логика управления объектами в приложении, такими как проекты, резервирования и запасы на складе.

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

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

Бизнес-логика работы с резервированием должна была предусматривать этапы подготовки, согласования, комплектования, отгрузки, работы на объекте и возвращения инструментов обратно на склад или их списание.

Здесь, при помощи создания специализированных заданий, привязанных к резервированиям, удалось реализовать функционал документального сопровождения проверки грузоподъемных механизмов перед их отгрузкой.

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

Здесь выявилась вся слабость MS Excel как средства хранения большого объема информации: опечатки, неточности, отсутствие необходимых данных в полях таблицы, разное наименование одних и тех же объектов и так далее. Всё это также приводило и к неточностям при формировании отчетов в Excel.

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

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

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

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

Мессенджеры все сильнее входят в нашу жизнь и становятся её неотъемлемой частью. Telegram среди них отличается стремительным ростом популярности в России, широкими возможностями интеграции, а его свободное API позволяет решать новые задачи легко и просто.

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

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

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

Проблемы такого рода, оказалось, можно легко решить с помощью интеграции с Telegram, например получать информацию от сервисного инженера когда он прибыл на объект, когда убыл, устраивать перекличку и так далее.

Также с помощью Telegram можно реализовать часть функционала приложения. например получение отчетов или согласование документов.

Тут два варианта:

1. Отсутствие планирования можно компенсировать избыточным количеством ресурсов.
2. Внедрить планирование, что позволит в дальнейшем оптимизировать количество нового закупаемого оборудования. Когда в следующий раз к руководителю придут с бюджетом на закупку новой партии приборов и инструментов он сможет запросить статистику использования, а также будущий план использования на предстоящий год. Принятие решение на основе объективных данных, а не желаний подчиненных.

Во многих организациях есть проблема со сбором информации и ее обменом. Это приводит к потерям в скорости принятия бизнес-решений, гибкости, финансовым потерям. Что делать?

1. Информация должна сохраняться, даже если Вы не знаете, как её сегодня использовать. Стоимость хранения информации невысока, а преимущества ее использования в будущем с лихвой перекроют эти затраты.
2. У бизнес-подразделения должна быть точка сборки всей информации, необходимой для его работы. Если часть информации собирается в одном месте, часть - в другой, а в процесс интеграции данных не налажен, то эффективность работы резко падает.
3. Информация, необходимая для работы, должна быть доступна сотруднику в объеме, необходимом для эффективного выполнения должностных обязанностей. Если эту информацию нужно у кого-то просить, то возникает целый ворох проблем, связанный с общей эффективностью работы всего подразделения.