- Моновендорность или мультивендорное взаимодействие сервисного бизнеса
- Как выглядит работа мультивендорной сервисной компании?
- Взаимодействие с вендорами. Сложности для сервисного бизнеса и интеграторов
- Автоматизация взаимодействия с вендорами и производителями для сервисных компаний
- Есть ли решение для автоматизации взаимодействия сервисного бизнеса и производителей?
В соответствии с мировыми рекомендациями по организации процессов сервисного обслуживания, поддержку пользователей удобно разделять на линии.
Внутри одной организации выделяют первую, вторую и, зачастую, третью линии, выполняющие функции, соответственно:
- приема, классификации заявок и сбора обратной связи по качеству выполнения;
- решения типовых, проблем, в том числе специализированных;
- а также обработки более сложных ситуаций, требующих привлечения «узких» специалистов с серьезной квалификацией (разработчиков) или подрядчиков.
Однако на практике довольно редко встречаются сервисные компании, которые занимаются поддержкой только своих продуктов, проектов или типовых решений, не подразумевающих общения с производителем ПО или оборудования.
Мультивендорным сервисным компаниям, например, предлагающим поддержку инфраструктуры в ритейле (кассы и терминалы таких производителей как АТОЛ, Штрих-М, Эвотор и др.) или обслуживающим системы мониторинга транспорта и телеметрию (датчики производителей Эскорт, GalileoSky, Omnicomm и системы мониторинга Wialon, Omnicomm Online, Автограф), так или иначе приходится взаимодействовать со многими поставщиками, оборудование или ПО которых они, собственно, продают, устанавливают, внедряют и берут на дальнейшее абонентское сопровождения.
Какие существуют тонкости такого многогранного сотрудничества? Есть ли возможность упростить взаимодействие и коммуникацию с вендорами через автоматизацию?
Моновендорность или мультивендорное взаимодействие сервисного бизнеса
Комплексная сервисная поддержка нужна в первую очередь клиентам.
В теории от мультивендорного подхода они получают сплошные плюсы, кратко формулируемые, как «единая точка входа» для решения всех инфраструктурных проблем.
Опустим здесь тонкости контроля процесса со стороны клиента.
Предположим, что речь идет об ответственной мультивендорной сервисной компании, которая не перекладывает свои проблемы на клиентские плечи.
Хороший пример такого сервиса — работа с розничными сетями, включая общепит и ресторанные сети.
В рамках обслуживания инфраструктуры здесь необходимо поддерживать не только контрольно-кассовую технику, но и весовое оборудование, терминалы оплаты, а с недавнего времени еще и помогать взаимодействовать с операторами фискальных данных.
И клиенту (розничной сети или точке продаж) удобнее, когда весь парк разрозненных сервисов и оборудования обслуживает одна компания — как минимум не надо оплачивать работу сотрудника, который будет разбираться, в чьей же юрисдикции возникшая проблема, и отслеживать исполнение заявок у разных исполнителей.
С любыми проблемами можно обращаться по одному адресу, в АСЦ, с которым заключен договор на обслуживание всей техники.
Как выглядит работа мультивендорной сервисной компании?
А вот с точки зрения самой сервисной компании все не так радужно.
Поддержка продуктов сторонних поставщиков плоха тем, что все проблемы, будь они у самой сервисной компании или на стороне поставщика, клиент будет «сваливать» на своего непосредственного партнёра. И немедленного решения будет требовать у него же, в том числе потому, что договор на обслуживание заключен именно с сервисной компанией.
Не уложились в сроки — виноваты «сервисники»; некачественно закрыли заявку из-за отсутствия обратной связи от производителя — опять виновата сервисная компания; обращение потерялось на этапе передачи вендору — и тут клиенту совершенно понятно, кто «крайний». Иными словами, процесс строится на неравном взаимодействии трех сторон.
Несколько упорядочить подобные взаимоотношения можно как идеологически, так и технически.
Во-первых, в идеальных условиях между сервисной компанией и клиентом заключается SLA, в котором отдельной статьей прописана роль третьих сторон — подрядчиков или служб поддержки производителей обслуживаемых решений и оборудования.
При этом взаимодействие самой сервисной компании и подрядчиков также должно осуществляться в рамках своих SLA.
Во-вторых, построить сквозной процесс взаимодействия, с вендором в котором заявки не теряются, совместное обсуждение ведётся, итоговое решение согласуется, необходимо и технически — через правильную автоматизацию. Подробнее об этом — далее.
Взаимодействие с вендорами. Сложности для сервисного бизнеса и интеграторов
Рассмотрим ситуацию, близкую к идеальной: предположим, внутри сервисной компании процессы поддержки соответствуют современным реалиям и запросам бизнеса: то есть они выстроены и автоматизированы посредством Help Desk системы.
То есть заявки не теряются, их распределение происходит автоматически, клиенту всегда понятны статусы и сроки выполнения, контроль качества выполнения, SLA и т.д. — выполняется через встроенную или внешнюю систему отчетности. Более того, вендор также отладил необходимые процессы.
Но несмотря на то, что обе организации работают по «лучшим практикам», использовать наработанные внутри подходы для внешнего взаимодействия получается редко.
Ведь в случаях, когда для решения клиентской заявки условному интегратору систем мониторинга транспорта или АСЦ нужно привлечь вендора, необходимо как-то транслировать свои заявки друг другу.
Простейший путь для сервисной компании — действовать как клиент, т.е. существующие в своей системе заявки транслировать вендору через телефонные обращения или почту, начиная общение с их первой линии и контролируя происходящее, например, через клиентский портал (если таковой присутствует у вендора).
Большинство сервисных компаний в этой схеме вынуждены постоянно помнить адреса и телефоны поставщиков, ID заявок в их системах и т.д.
К сожалению, даже при малом потоке обращений к разным поставщикам один лишь контроль в разрозненных системах будет отнимать слишком много времени, не добавляя никакой прозрачности. Тем более, что полученное решение потом необходимо будет транслировать в свою систему автоматизации, т.е. тратить время на банальное дублирование информации.
А если ситуация еще хуже и у кого-то из участников процесса нет никакой автоматизации?
У вендора без helpdesk системы мы не можем узнать актуальный статус заявки.
Если же у самой сервисной компании все держится «в голове» или табличке Excel, при каждом обращении клиента придется запускать сложную процедуру актуализации дел, вспоминая ID переданных заявок и вручную обновляя их статусы. Несмотря на трудоемкость такой реализации, она до сих пор наиболее распространена в российских сервисных компаниях.
Автоматизация взаимодействия с вендорами и производителями для сервисных компаний
Единственный путь сделать все гладко — обеспечить интеграцию helpdesk систем хотя бы для автоматического создания заявок в системе вендора на основании тикета клиента сервисной компании с передачей всей необходимой для решения вопроса информации. В идеале такая интеграция должна быть выполнена с системами автоматизации всех вендоров, чье оборудование и ПО поддерживается сервисной компанией.
Плюсы такого современного взаимодействия очевидны:
- заявки при трансляции между системами вендора и сервисной компании не теряются;
- нет никакого влияния человеческого фактора и временных затрат на перенос данных;
- все переданные заявки с обеих сторон имеют актуальный статус (который, кстати, можно отображать и на клиентском портале), а переписку и комментарии по задачам не надо отслеживать в разрозненных системах;
- сотрудники сервисной компании и вендора могут работать в своих привычных системах, не подстраиваясь под чужие рабочие процессы и новые интерфейсы.
К сожалению, такой путь на рынке выбирают единицы.
Существуют десятки различных систем автоматизации учета заявок и технической поддержки, а некоторые сервисные компании создают свои собственные решения.
Обеспечить взаимную интеграцию всего множества вариантов попросту невозможно.
Поэтому тем, кто хочет сделать все по-человечески, приходится самостоятельно решать проблему интеграции с «зоопарком» help desk систем разных производителей или искать те немногие решения, чьи разработчики подумали о сторонних взаимодействиях.
Есть ли решение для автоматизации взаимодействия сервисного бизнеса и производителей?
В лидирующей (по числу активных платных клиентов, по числу выпускаемых релизов и обновлений) системе автоматизации сервисного, постпродажного и выездного обслуживания — Окдеск кроме уникальных модулей, функций, интерфейсов и набора готовых отчетов, «из коробки» есть механизм, позволяющий в пару кликов связывать аккаунты разных компаний.
Подобная возможность позволяет использовать «партнерский» аккаунт в качестве соисполнителя заявки без дополнительных затрат и, как следствие предоставляет возможности:
- передача партнёру необходимой информации из изначальной заявки (описание, файлы, связь с клиентом, объектом обслуживания, оборудованием);
- переписки по переданным заявкам;
- обмена файлами;
- отслеживание id и статуса заявки в партнёрской систем;
- оценки качества выполнения переданного тикета;
- автоматической смены изначальной клиентской заявки на основании смены статуса «переданной» заявки и т.д.
Конечно все подобные коммуникации происходят с учетом разграничения доступа к данным между всеми тремя сторонами: клиентов-заявителем, сервисной компанией исполнителем и третьей стороной (вендором или подрядчиком).
Важно отметить, что схема передачи заявки идеально подходит и для автоматизации «обратных» сценариев, например, когда из системы розничной сети заявки для исполнения передают сервисному партнёру или, когда из системы вендора заявки передаются сервисным партнёрам для их решения на местах.
В Okdesk также реализованы готовые сценарии интеграции с корпоративными решениями крупных розничных сетей, которые позволяют автоматически регистрировать сервисным компаниям заявки из сторонних систем самым эффективным образом, например, привязывая их к нужному объекту, наследуя сроки выполнения и т.д.
Окдеск — профессиональная help desk система для автоматизации всех аспектов сервисного бизнеса, включая взаимодействие с вендорами, партнёрами и подрядчиками.
