Подводные камни самописного мобильного приложения для сервисных инженеров

Андрей Замыслов

Подпишитесь, чтобы получать новые статьи

  • Это поле используется для проверочных целей, его следует оставить без изменений.

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

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

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

Диспетчеризация

Первая проблема — это функция распределения наряд-заказов по инженерам или диспетчеризация.

Приложение – это единая система сбора данных со всех источников заявок (телефон, сайт, клиентский портал, CRM и тд.).  Заявки поступая в систему должны оперативно и … распределяться на сервисных инженеров.

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

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

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

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

Интеграция со сторонними ресурсами

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

Интеграция с учетными системами

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

— резервирование запасных частей под наряд/заказ;

— передача запасных частей сервисному инженеру;

— списание запасных частей при выполнении наряд-заказа.

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

Учет наряд-заказа

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

На Западе вся эта цепочка процессов, включающая отслеживание местоположения, контроль ГСМ и прочих расходников, запрос наличия запчастей и т. д., называется

Поддержка приложения

Поддержка совместимости с новым железом и новым софтом

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

Из этого вытекает две насущные необходимости:

  • на стадии разработки решать вопрос совместимости с разными мобильными устройствами;
  • после выпуска в эксплуатацию периодически обновлять приложения.

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

Облачные ресурсы для функционирования приложения

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

  • содержание сервера;
  • зарплата системного администратора и технического персонала;
  • создание и обновление БД;
  • оплата облачного хранилища и т. д.

В случае, когда для создания приложения используется промышленная платформа (н-р, Microsoft Dynamics 365 Field Service или Power Apps), то есть постоянно развивающаяся платформа, над которой работает крупная корпорация, все эти проблемы де-факто не касаются компании, которая решила обзавестись мобильным приложением. На самом деле большая часть трудностей, связанных с этой сферой, уже давно была решена, поскольку разработчики платформы много лет работают в этом направлении. В случае же разработки приложения с нуля способы решения придётся продумывать с чистого листа.

Возможность интеграции с другими бизнес-приложениями

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

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

Возможность подключения дополнительных устройств

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

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

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

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

Работа в офлайн-режиме

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

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

Управление правами доступа

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

В Dynamics Field Service встроена ролевая система безопасности, вся настройка которой сводится к заданию тех правил, которые подходят конкретной компании. Все внутренние механизмы отлажены и представляют собой результат почти двадцатилетней работы программистов Microsoft. Таким образом инструменты управления доступом с устройства и защиты корпоративных данных на устройстве сразу встроены в приложение. С их помощью возможно:

  • Разрешать сотрудникам ставить какие-то программы или вообще ограничить установку приложений на корпоративные смартфоны.
  • При потере смартфона удалённо стирать данные.
  • Ограничивать доступ к корпоративной информации.

Заключение

На первый взгляд разработка мобильного приложения выглядит дешевле. Но это может быть обманчивое впечатление.

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

Если вашей компании требуется мобильное приложение достаточно простого функционала, это может быть оправдано. В случае, если вы выполняете автоматизацию более сложных процессов, обратите внимание на промышленные платформы класса FSM (Field Service Management), например Microsoft Dynamics 365 Field Service.

#Field Service#Сервис

комментарии (0)

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Назад в блог