Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Статья рекомендуется к прочтению тем, у кого “болит” вопрос управления и контроля персонала на выезде, а также тем, кто собирает полезную информацию перед внедрением FSM или Service Desk системы для управления мобильными сотрудниками.
Приветствую всех. С кем не знаком - Андрей Балякин: 7 лет в сервисном бизнесе, 20 лет в ИТ. Предприниматель. Последние несколько лет - CEO проекта HubEx (ИТ платформы автоматизации выездного обслуживания и управления сервисными процессами).
За время развития проекта, общения с клиентами и разработки продукта в голове собралось приличное количество ценного и полезного опыта. Им и решил поделиться ниже. Развитие отрасли выездного обслуживания, в России, увы в зачатках. Информации крайне мало, так что уверен, статья многим будет полезна.
Цель публикации - собрать мнения и всесторонний опыт тех, кто внедрил какие-либо системы для управления выездными сотрудниками в своей компании и готов поделиться опытом с остальными.
Для начала давайте определимся, о чем пойдет речь: ИТ сообщество подобные системы часто называет ITSM или Service desk с приложением для мобильных сотрудников. В англоязычном мире под этот класс систем есть отдельный термин: Field Service Management или сокращенно - FSM (не путать с Workforce management). В переводе это звучит как управление полевым сервисом, но более понятным будет - управление выездным обслуживанием или управление мобильными сотрудниками.
Чем я поделюсь:
Представлю собранный в течении нескольких лет чек-лист для компаний, которые внедряют FSM решение для управления выездным обслуживанием. Он поможет четко сформулировать свои требования к системе
Расскажу о различиях продуктов класса “управление выездным обслуживанием”
Обсудим, для каких компаний какие типы систем предпочтительнее
Объясню, на что следует обращать внимание перед внедрением решения для управления мобильным персоналом в своей компании
Приведу пример сервисного процесса и его стадий для более глубокого понимания требований к системе, а также удобной настройки процесса по шаблону, если систему вы уже выбрали
Предоставлю перечень возможных функций, которые могут потребоваться от системы для управления выездным сервисом. Поможет сравнить и выбрать подходящее решение
Чтобы избежать субъективных мнений по основным вопросам и принципиальным отличиям различных систем управления выездным обслуживанием, начну с мнения аналитического агентства Gartner. Он недавно выпустил свежую публикацию на тему Field Service Management-а в дополнении к обновлению магических квадрантов. Вот ссылка на статью для англо-понимающих: https://www.gartner.com/doc/reprints?id=1-2438LY1F&ct=200903&st=sb
Что говорит уважаемый Gartner?
Во первых:
Решения по управлению мобильными сотрудниками делятся на 2 категории, а при выборе следует учитывать следующие моменты:
“Исходя из отрасли вашей организации, сложности требований и готовности вкладывать в дорогостоящую разработку необходимого именно вам кастомного функционала, выберите, какое решение наилучшим образом подходит для вашей организации:
мировой лидер в классе” (имеется в ввиду следующее: берем SAP, Microsoft, Oracle и т.п. мировых лидеров + стартуем дорогостоящий проект адаптации/доработки/внедрения и пилим, пилим, пилим. Стоимость таких проектов, в среднем, от 200k$ до 900k$ по РФ)
“выбираем нишевое отраслевое решение от локального вендора”.
Gartner, советует: “Выбирайте подходящее решение, исходя из вашей сферы деятельности, сложности и объема требований, а также необходимости кастомизированной настройки и готовности к доработкам.”
Получается, что первый вариант - дорого, богато, никаких компромиссов. Будет сделано именно то, что нужно вам (тут все часто зависит от зрелости команды внедрения и готовности бизнеса к долгострою и серьезным инвестициям) . Второй - значительно меньшие инвестиции и возможность в разумные сроки закрыть 80% функциональных требований. Но именно 80, не 100%!
Во вторых:
Gartner делит вендоров (разработчиков) систем управления выездным персоналом (FSM-систем) на три категории.
“Appointment-Centric”: в основе лежит управление заявками и расписаниями сотрудников
Признаки: у сотрудников множество поездок/заявок в день. В этом случае, при выборе системы, наиболее важным для компании будут возможности системы удобно управлять заявками и оптимизировать расписания сотрудников.
“Equipment-Centric”: в основе лежит выездное техническое обслуживание и ремонт оборудования
Признаки: компания специализируется на выездном обслуживании оборудования, технические специалисты имеют узкую специализацию. Для них важно оперативно получать информационную поддержку и помощь. Gartner обращает внимание на то, что такая поддержка и сопровождение выездных специалистов с узкой специализацией – наиболее приоритетная задача для компании.
В этом случае важно обратить внимание на наличие у решения мобильного приложения с функционалом, которого будет достаточно для поддержания полноценного рабочего процесса мобильного выездного инженера. Думаю, очевидно, почему я говорю именно о наличии мобильного приложения, а не просто мобильной веб-версии? Если нет - спрашивайте, обсудим в комментариях.
Для примера:
Приложение мобильного сотрудника должно помогать ему получить необходимую документацию по ремонтируемому оборудованию, технологические карты или коды ошибок
Выполнение сложных работ должно контролироваться специализированными чек-листами, а помощь экспертов по оборудованию должна быть доступна онлайн через смартфон.
Gartner обращает внимание на то, что поддержка и сопровождение выездных специалистов с узкой специализацией через мобильное приложение – наиболее важная задача.
Outcome-Centric: для компаний, использующих модель Equipment-as-a-Service (Оборудование, как сервис/услуга)
Смысл следующий: организация (подрядчик) предоставляет, а заказчик оплачивает услугу, а не приобретает в собственность оборудование, которое его этой услугой могло бы обеспечить. Пример такого контракта из ИТ-тематики - покопийная печать. Подрядчик продает услугу печати документов с оплатой за поштучные копии (отпечатки), а не устройство печати (принтер/МФУ) или контракт по обслуживанию оргтехники.
Онлайн мониторинг работы оборудования, в этом случае, наиболее важен, так как поломка и простой оборудования равен простою бизнеса.
Для таких компаний часто важнее всего быстрая диагностика оборудования и получение данных о работе (поломках) онлайн.
Что требуется от ИТ-системы в этом случае?
Наличие мобильного приложения, чтобы в режиме реального времени получать данные мониторинга оборудования, в том числе на выездах, и оперативно принимать меры
Модуль мониторинга оборудования, который, во-первых, сможет измерять показатель, за который платит заказчик, а во-вторых, контролировать работоспособность и фиксировать ошибки в работе оборудования
В дополнение к классификации Gartner, в России точно стоит добавить еще один вид ИТ-систем, которые часто выбирают российские компании при поиске решений для управления выездным обслуживанием.
“Ticket-centric”: сервис деск на базе ITSM service desk/service management систем, расширенный мобильным приложением для выездных сотрудников и модулем управления расписаниями.
Фактически получаются системы вида Appointment-centric (ориентированные на работу с заявками), но, в отличии от последних, обычно имеющие ряд ограничений. Возможности этого класса решений обычно упираются в возможности ITSM систем, сделанных для ИТ и работающих в рамках ITIL практик. Как итог - выездным сервисным сотрудникам оказывается неудобно работать по процессам ИТ, у них своя специфика, отличная от ИТ-сервиса.
Для лучшего понимания различий между этими системами приведу упрощенные схемы процессов, которые заложены в фундамент подобных решений.
Appointment-centric: в основе лежит управление заявками и расписаниями сотрудников
Сотрудник и расписание вынесены в начало схемы намеренно, так как именно эти сущности определяют логику работы систем данного класса. Продвинутые “Appointment-centric” FSM системы позволяют удобно планировать загрузку персонала с учетом расписаний работы объектов. Они учитывают сменный график работы сотрудников, автоматически планируют и оптимизируют расписания, динамически перераспределяют заявки в случае форс-мажора.
Equipment-centric: выездное техническое обслуживание и ремонт оборудования
В начало процесса добавляется оборудование с иерархией до узлов и агрегатов, когда необходимо.
Все заявки привязываются к оборудованию. Выполнение плановых работ также привязывается к оборудованию.
В итоге, оборудование обрастает историей обслуживания, технической документаций и информацией, которая позволяет выездным специалистам качественно и быстро производить обслуживание и эффективно ремонтировать технически-сложные устройства.
Вся аналитика ремонтов, обслуживание и устранение неисправностей собирается вокруг оборудования. Фактически это получается FSM по модели ТОиР.
Для общего понимания: ТОиР системы (системы технического обслуживания и ремонтов) - отдельный класс решений, созданный специально для обслуживания технически-сложного оборудования. К ТОиР нужна еще достаточно мощная система диспетчеризации и управления мобильным персоналом (FSM), чтобы внедрение ТОиР привело к повышению эффективности эксплуатации оборудования, а не наоборот.
Equipment-Centric системы управления выездным обслуживанием для большинства компаний могут заменить ТОиР решения. Такой вариант подходит в тех случаях, когда в процессе деятельности компании ремонты осуществляются мобильными сотрудниками или подрядчиками, а базовых ТОиР функций вполне достаточно для контроля обслуживания и ремонтов оборудования.
Outcome-centric: в основе лежит оборудование как услуга
Тут мы видим обвязку к упрощенной модели Equipment-centric FSM. Создание вложенных заявок на нескольких сотрудников обычно не требуется, однако добавляется обязательное условие получения информации о работе оборудования. Например, интеграция решения, по управлению выездным персоналом с IoT или мониторинговой системой, сообщающей о состоянии и работоспособности оборудования.
Outcome-centric: оплата за результат или достижение согласованных показателей
Например, клиент платит абонентскую плату за достижение показателя бесперебойной работы оборудования. Если уровень доступности ниже согласованного контрактом SLA - плата снижается или отсутствует вовсе.
Ticket-centric: в основе лежит работа с заявками. Своего рода сервис деск, расширенный приложением для мобильных сотрудников
Я сознательно не добавил сюда свойственные FSM решениям блоки “планирование расписаний”, “оборудование” или “выполнение”, так как мобильное приложение в таких решениях обычно очень простое, а его возможности ограничены базовыми функциями: посмотреть текст заявки и отчитаться о выполнении в простой форме. Кэш режим, который необходим мобильным сотрудникам, тоже либо вовсе отсутствует, либо ограничен просмотром заявок. Поменять стадию заявки или заполнить чек листы - только при наличии доступа в интернет.
Ниже, в отдельном разделе, я приведу примеры возможностей FSM-решений, дефицит которых испытывают компании, которые ошиблись в выборе и внедрили решение не того класса.
Еще один тип систем, которые пытаются использовать ряд компаний при реализации задачи управления выездными сотрудниками - настройка CRM под задачи FSM.
Какие функции вам точно потребуется или почему не стоит заменять специализированные решения на “всемогущие” CRM
Почему я добавил CRM? Причины две:
Среди ИТ-решений по управлению мобильными специалистами иногда встречается такое понятие как “CRM для выездных сотрудников”. По факту это то же самое FSM-решение с урезанной функциональностью или Service desk с примитивным мобильным приложением. Осмелюсь предположить, что CRM в названии присутствует по простой причине: FSM у нас в России не раскачена, такие запросы пользователи не ищут, а в поисковиках светиться нужно. И чем проще и понятнее ты назовешься - тем лучше. А CRM, как известно знают все…
Потому, что часть наших клиентов начинали автоматизировать сервис выездного обслуживания на базе имеющихся в компании CRM. При этом попытки большинства компаний выстроить работу с выездными сотрудниками на базе CRM решений обычно заканчиваются разочарованиями. В некоторых очень простых случаях это кажется возможным, но выстроить эффективный сервисный процесс не получится.
Заявка хоть и похожа на воронку со стадиями, которые можно как-то назвать, но в CRM нет и половины функций, которые требуются компаниям с мобильными сотрудниками. Например:
расписания сотрудников и объектов обслуживания в связке с специализаций и географией, позволяющие системе автоматизировано распределять заявки
учет оборудования и привязки к нему заявок / выполняемых работ
GPS-контроль персонала
ТОиР-модуль для работы с плановыми заявками и с возможностью создавать группы заявок по типам объектов, оборудования, видам работ и других сущностей системы
история обслуживания
расчет плановых сроков закрытия заявок согласно SLA с заказчиком
специализированные инструменты для экспресс-подачи заявок заказчиком
учет квалификации сотрудников и специальных документов, которые необходимо иметь для выполнения конкретных видов работ и без которых не получится назначить заявку на специалиста
справочник работ и услуг
иерархия объектов обслуживания, как и самих объектов с гео-привязкой на местности
оффлайн режим в мобильных приложениях
расчет стоимости выполненных работ и оказанных услуг через приложение
возможность администрирования складов, учета складских запасов и остатка материалов, указания в заявке использованных материалов со склада
Это, конечно, далеко не полный список того, что не получится сделать в CRM тем, кому нужно управление заявками и выездными сотрудниками. Если я что-то забыл - дополняйте, пожалуйста, в комментариях. Интересен ваш опыт.
CRM - это система преимущественно для отдела продаж. Ее можно использовать для других целей, понимая и принимая ограничения, но тут определенно не стоит рассчитывать на гибкость и высокий уровень автоматизации операционных процессов сервиса.
Сервис деск с мобильным приложением для выездных сотрудников дают больше возможностей. Однако стоит внимательно оценить их возможности при выборе подходящей системы под задачи компании.
При выборе системы важно оценить возможность масштабирования вашей организации на основе выбранной системы. По опыту, только после внедрения к компаниям, внедривших систему автоматизации, приходит аппетит, и она начинает понимать и делать те изменения, которые несут нужный эффект.
В следующем разделе я попытался собрать список проблем и вопросом с которыми сталкиваются компании, внедряющие систему управления выездными сотрудниками.
На этот раздел крайне рекомендую обратить особое внимание всех, кто планирует автоматизировать работу выездных сервисных сотрудников.
Для удобства структуру сделал в виде чек-листа, заполнив который по выбранным решениям можно сделать осознанный вывод: подходит решение или не совсем. Если подходит на 85% и больше - повод примерить.
Чек-лист для компаний, внедряющих FSM решение по управлению выездными обслуживанием: на что обратить внимание?
Ниже перечислены те функции, которые могут быть важными или даже критичными для компаний, выбирающих решение по управлению мобильными сотрудниками.
Кроме того, крайне рекомендую обращать внимание на то, КАК они реализованы в конкретной системе, а еще лучше сравнивайте эту реализацию у разных вендоров напрямую.Дьявол, обычно, кроется в деталях.
“Выбор по обложке” приводит значительным затратам времени, сил и последующему негативному опыту от автоматизации. Сотрудникам только дай повод покритиковать менеджеров, “навязывающих” им систему. Повторное внедрение это двойной стресс для всех и снижение шансов на успех.
Важный совет для компаний, планирующих автоматизацию управления выездными сотрудниками (это работает и для любых других внедрений):
Найдите у себя в компании “лидеров мнений”.
Обсуждайте с ними новые процессы с самого начала.
Показывайте систему.
Дайте попробовать поработать и собирайте фидбэк.
Мотивируйте их на результат (премии по итогам проекта, слава и поощрения, кому что)
“Свои люди” помогут другим сотрудникам и на доступном языке расскажут об удобстве системы, поддержат советом и покажут, как с системой работать тем, кто с компьютерными новинками на “Вы”.
Итак, чек-лист по выбору FSM решения.
Отметьте те пункты, которые важны для вашей компании, и оцените по ним различные решения на рынке. У кого есть опыт в работе /внедрениях Service desk или FSM решений для управления заявками и работой выездного персонала: возможно я что-то упустил в списке, так что дополняйте в комментариях. Буду обновлять список. В итоге получим удобный чек-лист для тех, кто выбирает систему управления выездным обслуживанием.2
№ | Сравнение возможностей | Требуется (да/нет) | Система 1 | Система 2 |
1. | Работа с заявками: | |||
1.1 | Возможность интеграции по входящим заявкам с системами заказчиков. Чтобы диспетчеру не пришлось заводить все заявки вручную | |||
1.2 | Возможность загружать заявки пакетами. Это часто требуется, когда заказчики, подающие заявки, обязуют подрядчика работать в своей системе и не дают возможностей для интеграции | |||
1.3 | Омниканальность по входящим обращениям | |||
1.4 | Возможность настраивать правила парсинга при импорте заявок через почту. Чтобы структурированная входящая заявка попадала в систему, автоматически заполняя максимальное количество полей | |||
1.5 | История изменения заявок с возможность просмотра кто, где, когда и что делал | |||
1.6 | Ролевая модель - возможность выдавать доступ и отображать только ту информацию, которая может быть доступна для сотрудника с данной ролью | |||
1.7 | Удобство работы со списком заявок, сортировка, добавление пользовательских полей, перемещение полей в списке, фильтрации - стоит попробовать самостоятельно | |||
1.8 | Сохранение быстрых фильтров - сколько сотрудников, столько и вариантов фильтрации. Один руководитель хочет по нажатию кнопки фильтровать заявки своих сотрудников, другой - выбирать заявки электриков на своем участке | |||
1.9 | Создание заявок по расписанию. Обратите внимание, что часто требуется не просто создавать заявки по определенному интервалу (каждый вторник, каждую 2 неделю, каждый месяц), но и за определенное количество дней до дня Х. Т.е. заявка должна появляться не в заданный расписанием день, а за Х дней или часов до него | |||
1.10 | Аналитика по заявкам. Это отдельный тонкий вопрос, детально расскажу ниже | |||
2. | Дочерние/вложенные заявки: | |||
2.1 | Дочерние заявки требуются тогда, когда ремонт или обслуживание могут проводиться разными сотрудниками в разное время. При этом требуется собирать статистику работ и управлять ремонтом, как мини-проектом: получили заявку, декомпозировали ее на несколько сотрудников, поставили в расписание и контролируем выполнение заявки | |||
2.2 | Полноценная работа с дочерними заявками как с родительскими заявками (не в форме чек-листа: получил заявку, выполнил, а полноценно с движением заявки по регламентированному процессу) | |||
3. | GPS-контроль выездного персонала - важная функция при работе с мобильными сотрудниками | |||
3.1 | GPS-контроль сотрудников и отображение их фактического положения на карте. Сбор координат перемещений сотрудников из мобильного приложения. Подключение данных с трекера - если актуально. Большинству достаточно сбора геопозиции из приложений сотрудников, но иногда предпочтительнее трекеры | |||
3.2 | Возможность отключить сбор координат для офисных сотрудников, которые пользуются системой, а также сбор координат только в рабочее время сотрудников | |||
3.3 | Возможность контроля путевых листов: сверка задекларированного пробега сотрудника с фактическим и расчетным | |||
3.4 | Возможность для диспетчера видеть на карте не только местоположение сотрудников, но и заявок, с возможностью их распределения на сотрудников в соответствии с их квалификацией и занятостью | |||
3.5 | История перемещений сотрудников в привязке к заявкам ВАЖНО: для контроля недостаточно понимать, где находится сотрудник, важно знать что он делает: какую заявку выполняет или выполнял, на каком объекте и сколько времени. Это основная причина, почему без системы диспетчеризации заявок геотрекинг мало что дает | |||
4. | Мобильное приложение выездных сотрудников: | |||
4.1 | Поддержка iOS и Android смартфонов. Одинаковые возможности приложений. По опыту, неудобно, когда пользователи iOS и Android имеют разный функционал | |||
4.2 | Работа приложения сотрудника в офлайн На случай, если ваши сотрудники часто бывают на объектах без WiFi и устойчивого интернета, важно иметь возможность просмотра заявок, перевода их по стадиям, заполнения чек-листов, оформлять акты выполненных работ и закрытия заявок офлайн. | |||
4.3 | Встроенные чаты между исполнителем и диспетчером | |||
4.4 | Возможность опционально добавлять других сотрудников в чат | |||
4.5 | Разделение на чаты внутри компании и чаты с клиентами. Ценно, когда ваши заказчики могут подавать заявки через мобильное приложение клиента | |||
4.6 | Просмотр истории выполненных заявок по оборудованию (объекту) и истории ремонтов/обслуживания | |||
4.7 | Возможность добавлять к заявке не только фото, но и видео-файлы с описанием проблемы | |||
4.8 | Возможность переназначения заявки на другого сотрудника (для определенных ролей) | |||
4.9 | Добавление кнопок-действий в мобильное приложение без разработки Понадобится тогда, когда захотите настроить различные сценарии прохождения заявок разного вида. Если эти задачи потребуют выпуска новых версий мобильного приложения и их публикаций в сторах - будет сложно настраивать систему под задачи компании | |||
4.10 | Расчет стоимости выполненных работ и автоматическое формирование акта выполненных работ в смартфоне с подписью пальцем или стилусом на экране | |||
4.11 | Возможность при помощи мобильного приложения взять оборудование на обслуживание (процесс онбординга нового клиентского оборудования в систему) и промаркировать объект или оборудование | |||
4.12 | Согласование заявок из смартфона | |||
4.13 | Возможность сделать комментарии обязательными при выполнении определенных действий | |||
5. | Чек-листы | |||
5.1 | Возможность подать заявку по пункту чек-листа во время его заполнения Требуется тогда, когда во время контроля необходимо зафиксировать отклонения от нормы и устранить их | |||
5.2 | Возможность затребовать в чек-листе фото- или видео отчет | |||
5.3 | Запрет на добавление фото и видео из галереи - только из камеры. Это поможет предотвратить повторное использование фотографий и фальсификацию результатов | |||
5.4 | Фиксация места/даты/координат съемки фото и видео | |||
5.5 | Привязка чек-листа к оборудованию, объекту или услуге | |||
Чек-лист по оборудованию Необходим, когда вы хотите регламентировать ремонт конкретного оборудования. Например, до начала ремонта расписаться в журнале, переключить на байпасс и убедиться, что напряжение отсутствует. Либо когда нужно проверить оборудование перед запуском, после остановки и ремонта | ||||
Чек-лист по объекту Например вы можете регламентировать процесс выполнения заявок у конкретного заказчика на конкретном объекте | ||||
Чек-лист по работам Научит новых сотрудников стандартам вашей организации, проконтролирует процесс выполнения всех обязательных пунктов для данного вида работ и поможет зафиксировать результат | ||||
Чек-лист по сбору контролируемых параметров Поможет зафиксировать параметры работы или какие-то показатели на объекте | ||||
5.6 | Возможность запросить в чек-листе информацию в требуемом формате: ввод чисел, выбор из выпадающего списка, приложение фото- или видео к отдельным пунктам чек-листа | |||
6. | Работа с оборудованием и объектами обслуживания: | |||
6.1 | База данных установленного оборудования с иерархией | |||
6.2 | Пользовательские поля у оборудования Например, для учета одного оборудования требуется: парт-номер, серийный номер, год выпуска. Для другого - цвет, срок эксплуатации, производительность и список подрядчиков на сервис. Все индивидуально | |||
6.3 | Привязка выполняемых заявок к оборудованию или объектам обслуживания | |||
6.4 | Возможность заполнить в мобильном приложении акт выполненных работ и получить подпись клиента на экране смартфона | |||
6.5 | Автоматизированный расчет стоимости выполненных работ в мобильном приложении при закрытии заявки | |||
6.6 | Возможность просмотра истории обслуживания по оборудованию | |||
6.7 | Группировка оборудования по типам (печи, кондиционеры и т.п.) для удобства аналитики | |||
6.8 | Принятие оборудования на обслуживание через мобильное приложение | |||
6.9 | Маркировка оборудования для безошибочной экспресс-подачи заявки клиентом (снижает количество ошибок и нагрузку на диспетчеров) | |||
6.10 | Привязка видов работ к оборудованию - какие работы можно выполнять на оборудовании и по контракту | |||
6.11 | Возможность создать электронный паспорт оборудования для сбора всей необходимой информации по оборудованию в одном месте | |||
6.12 | Возможность создания контактных лиц в привязке к оборудованию для удобства работы мобильных сотрудников | |||
6.13 | Графики работы оборудования или объектов обслуживания | |||
6.14 | Признаки, находится ли оборудование на гарантии | |||
6.15 | Навыки или допуск, которым должен обладать сотрудник для назначения на ремонт | |||
6.16 | Чек-листы по оборудованию | |||
6.18 | Выбор сотрудников, ответственных за оборудования Поможет назначать заявки на тех, кто знает и умеет ремонтировать этот тип оборудования | |||
6.19 | Импорт, экспорт, интеграции | |||
6.20 | Привязка к оборудованию QR или NFC-метки, которая позволяет удобно подать заявку, если промаркировано оборудование или объект заказчика | |||
6.21 | Иерархия оборудования и объектов: объект - оборудование - компонент и тд | |||
6.22 | Мобильность оборудования - возможность привязать геопозицию и перемещения гео-метки при перевозке оборудования с объекта на объект | |||
7. | Функции CRM | |||
7.1 | Ведение карточек клиентов с реквизитами и платежной информацией (если необходимо выставлять счета) | |||
7.2 | Контактные лица | |||
7.3 | Возможность привязать к компании обслуживаемое оборудование | |||
7.4 | Опция приложить файлы/документы к карточке Удобно для хранения прайс-листа или контракта в доступе для диспетчера или офисных сотрудников | |||
7.5 | Перечень стандартных реквизитов: сайт, почта и тд | |||
7.6 | Возможность вести заявки в разрезе заказчиков или объектов оборудования | |||
7.7 | Определите другие функции CRM, которые для вас критически важны, если вы планируете использовать FSM-систему и для контроля взаимоотношений с клиентами | |||
8. | Работа с расписаниями | |||
8.1 | Распределение заявок в расписание сотрудников на карте | |||
8.2 | Управление расписанием в интерфейсе (drag&drop) с просмотром заявок с таблице расписаний или календаре | |||
8.3 | Отображение рейтинга сотрудников в расписании | |||
8.4 | Выбор рекомендуемых исполнителей (по компетенциям и навыкам) | |||
8.5 | Авто-распределение заявок в расписание по различным правилам | |||
9. | Уведомления - какие способы нотификации персонала для вас важны? | |||
9.1 | SMS (дорого, но надежно) | |||
9.2 | PUSH | |||
9.3 | Уведомления в приложении | |||
9.4 | Нужно ли диспетчеру видеть, что сотрудник не подтвердил прием заявки и звонить ему | |||
9.5 | Требуется ли настраивать текст и логику уведомлений | |||
10. | Автоматическое распределение заявок | |||
10.1 | Определите для себя критерии, по которым обучите систему распределять заявки за диспетчера. Чек-листом тут не обойтись, поэтому рекомендую обратить на это внимание при выборе системы, если для вас это важно. Например - должна ли система сама выбирать сотрудника в зависимости от навыков, видов работ, графика и тд? | |||
11. | Настройка стадий заявок и логики перехода со стадии на стадию | |||
11.1 | В ряде систем есть конструктор стадий, позволяющий настраивать логику прохождения заявки. В начале пути кажется, что настраивать нечего и у заявки только три стадии: новая, в работе и выполнена. Но все не так просто. | |||
Вот очень простой базовый процесс прохождения заявки на выездное обслуживание:
Вот такой базовый шаблон наш департамент внедрения разработал для того, чтобы настраивать для заказчиков HubEx типовые процессы прохождения заявок:
Далее, на данный процесс накладываются полномочия (что можно делать сотруднику с конкретной ролью на конкретной стадии, а что нельзя).
Дополнительно настраивается система уведомлений (кто что и когда должен получать при поступлении заявок на конкретные стадии или при просрочках / Опозданиях итп).
Аналитика: “the last, but not least”, как сказали бы англичане: “последний по порядку, но не по значению”.
С моей точки зрения, это первое, над чем стоит подумать при внедрении. Не последнее уж точно. Делюсь с вами теми показателями, которые те или иные наши клиенты рассматривают, когда говорят об автоматизации.
Прежде отмечу, что важно иметь возможность видеть данные показатели в динамике, а также во всех разрезах, которые так или иначе присутствуют в системе, например в разрезе:
1. Периодов
2. Клиентов
3. Сотрудников
4. Оборудования
5. Объектов
6. Типам заявок
7. Типам работ
8. и т.д.
Оперативные показатели:
1. Кол-во открытых заявок
2. Кол-во не назначенных заявок
3. Кол-во заявок, не принятых в работу
4. Кол-во просроченных заявок
5. Кол-во заявок, по которым исполнитель опаздывает на объект
6. Кол-во заявок, которые истекают сегодня
7. Среднее время реакции диспетчера
8. Кол-во «футбольных» заявок, по которым исполнители несколько раз отказались от выполнения
Данные показатели предназначены, преимущественно, для диспетчеров или сотрудников, контролирующих назначение или исполнение заявок в срок.
Метрики для руководителей
Для руководителей сервисных организаций важно не только понимать текущую ситуацию в текущий момент, но анализировать множество показателей по разным периодам, а также иметь возможность эти периоды сравнивать, анализировать тренды и динамику.
Условно выделяемые нами показатели можно разделить на следующие категории:
Количественные:
Кол-во созданных заявок за период
Кол-во закрытых заявок за период
Кол-во эскалированных заявок за период
Кол-во закрытых в срок / не в срок заявок
Кол-во отказов исполнителей по заявкам
Динамика создания/закрытия заявок с графиком их сгорания
Соотношение заявок по типу заявки
Соотношения заявок по срочности
Соотношение заявок по типу работ
Соотношение заявок, созданных через разные источники (диспетчера, клиенты самостоятельно, через интеграцию со сторонними сервисами и др.)
Кол-во обслуживаемых объектов / оборудования
Кол-во клиентов
SLA показатели:
Contract Uptime Rate – % бесперебойной работы оборудования
First Time Fix Rate - % выполненных заявок с первого посещения
Repeat Visit – кол-во повторных визитов на объект по одной и той же заявке
Нарушения сроков разрешения заявок, указанных в SLA
Оценки клиентов по выполненными работам
Превышение фактического времени выполнения заявок относительно планового по типам работ
Временны́е показатели:
Average Time to Fix – среднее время выполнения работ исполнителями
Average Time to Complete – среднее время от создания до закрытия заявки
Среднее время реакции диспетчера
Среднее время принятия исполнителем заявки в работу
Среднее время от создания заявки до назначения на исполнителя
Среднее время от принятия заявки исполнителем до переведения в статус «В пути»
Среднее время исполнителя на дорогу
Финансовые показатели:
Выручка
Прибыль
Средний чек
ТОП клиентов по выручке и прибыли
Доля выполненных заявок по контракту и по сдельной схеме
Service to Cash Time – время от завершения работ исполнителем до поступления оплаты от клиента
ABC анализ клиентов
Показатели по исполнителям
Utilization Rate – % рабочего времени исполнителей, которое было потрачено на работу и оплачено клиентами
Tasks Per Person – среднее кол-во выполненных заявок на одного исполнителя
Отработанные сотрудниками часы
Переработки сотрудников
Оценки клиентов по выполненным исполнителями работам
Это далеко не полный набор показателей, и у каждого бизнеса могут быть свои, индивидуальные показатели и метрики. Однако без понимания ряда из них, компании не могут оценивать эффекты от проводимых изменений.
Итого
Выше я постарался описать базовые принципы и ряд практик, которые должны помочь компаниям войти в автоматизацию сервисных процессов, а именно - осознанно сравнить и выбрать систему по управлению выездным персоналом:
Шаги внедрения
Определите, к какому подклассу должна относиться целевая FSM система для вашей организации: appointment-centric / equipment-centric / outcome-centric или ticket-centric.
Найдите поддержку среди “лидеров мнений” в вашей организации
Зафиксируйте цели внедрения системы и показатели, оцифровка которых крайне важна
Сформируйте бюджет проекта так как от него будет в первую очередь зависеть класс решений, на которые стоит смотреть и ориентироваться при выборе
Сформулируйте требования к системе, воспользовавшись предложенными выше шаблонами
Проанализируйте рынок решений с учетом типа FSM решения из п.1,
Удачи в нелегком, но важном и абсолютно верном начинании.
Рынок растет, конкуренция становится все плотней среди сервисных компаний и организаций управляющих выездным персоналом. Эффективные компании растут и развиваются значительно быстрее других.
В комментариях буду рад получить обратную связь и дополним статью недостающей информацией. Все оценочные суждения - в другой раз. Также информацию о FSM-системах и трендах в управлении персоналом я публикую в телеграм-канале, кому интересно - welcome.
Заранее благодарю!
