что такое сервис деск система
Как мы выбирали себе ServiceDesk. Часть 1
Введение
Начитавшись разных статей на тему автоматизации сервисной компании, мы приняли решение, что нам тоже пора обзавестись волшебной кнопкой, которая «вжик» и увеличит эффективность всех текущих процессов сервисного обслуживания наших клиентов.
Стоит сразу отметить, что с момента решения «нам нужно автоматизировать процессы» до момента реализации задуманного у нас ушло 2 месяца. И мы считаем, что мы справились довольно быстро. Большая часть времени ушла на то, чтобы разобраться в работе и функционале предложенных на рынке вариантов. Еще столько же на внедрение выбранного решения в бизнес и окончательный «переезд» на работу в нём. Сэкономим время читателя и расскажем про наш сравнительный анализ рынка систем автоматизации сервисного бизнеса.
Прежде, чем приступать к деталям нужно рассказать кто мы такие. Мы — сервисная компания, которая занимается ремонтом и обслуживанием кондиционеров. Мы долгое время выстраивали работу в совместных календарях, мессенджерах, разных бесплатных и немного платных сервисах и очень осознанно (на наш взгляд) подошли к процессу автоматизации сервисных процессов. Об этом ниже.
KPI внедрения
Это ключевое, на что вы должны обратить внимание еще до момента знакомства с предлагаемыми решениями. Что именно вы хотите получить/автоматизировать/ускорить/внедрить при использовании системы автоматизации? Настоятельно рекомендую составить список, к которому вы будете обращаться при общении с продавцами и знакомстве с платформой. В противном случае глаза разбегутся, маркетологи сформируют ваши потребности за вас, а продавцы будут давить на УТП своего решения. И будет казаться, что в целом это действительно то, что нужно 🙂
Эту статью мы построили именно на сравнении платформ по тому функционалу, который мы заранее для себя обозначили как «необходимый», это:
И да, мы не скажем на каком решении мы остановились. Нет никакого интереса кого-то рекламировать. Задача рассказать о проделанной работе и сэкономить кому-то время.
Кого сравнивали?
В своём сравнении мы остановились на следующих решениях:
Сравнение
1. Чек-листы
Задача: стандартизировать и автоматизировать отчетность по выполненным работам, а также по плановым заявкам. Иметь возможность гибко настраивать поля чек-листов: прикладывать фото и файлы, показатели оборудования по износу и привязывать чек-лист в зависимости от вида работ или типа оборудования. А также сделать чек-лист обязательным к заполнению, чтобы без его заполнения заявка не могла быть закрыта.
В шаблоне наряда есть возможность добавить дополнительные поля с различными типами. Также возможно добавить необходимые атрибуты в отчет исполнителя. Фактически это альтернатива чек-листа.
Но такой функционал не решает нашу задачу полностью, так как фактически шаблон заявки можно сделать для каждого вида работ, но привязать чек-лист к конкретному оборудованию нельзя. Конечно, можно изобрести велосипед и по каждому оборудованию делать свой шаблон заявки, что, конечно же, неудобно диспетчеру при создании новых заявок.
Необходимого функционала в явном виде нам не удалось найти. Возможно использовать создание разных типов заявок с расширенным набором атрибутов. Но показалось, что это не очень удобно.
Функционал чек-листов есть, но он не решает поставленную задачу. Есть возможность создать чек-листы и настроить список вопросов, указав обязательные. Далее чек-лист можно привязывать к каждой отдельной заявке, т.е. руками:
Довольно гибкие настройки, которые решают поставленную задачу. В заявках/обращениях/заказ-нарядах возможно создание любого количества полей с установкой условий обязательного заполнения и выводом по сценарию необходимых полей. Возможно создание чек листов для каждой стадии заявки через функциональность «бизнес процессов» и «деталей».
Настройки чек-листов более чем устроили. Есть возможность создать любые атрибуты чек-листа, привязать его к виду работ или оборудованию
Также есть возможность привязать заполнение чек-листа к стадии заявки.
А также есть возможность создавать новые заявки по определенным пунктам чек-листа прямо в момент его заполнения.
В явном виде функционал тоже не нашли. Возможно использовать создание разных типов заявок с расширенным набором атрибутов. Также возможно реализовать динамическое открытие полей на форме в зависимости от условий.
Настройки необходимо делать через интерфейс технолога, что впрочем не так сложно.
Динамические формы также работают в мобильном клиенте.
2. Приёмка оборудования на обслуживание
Задача: иметь единую унифицированную базу обслуживаемого оборудования с привязкой к компании владельцу и возможностью добавления произвольных полей в карточку оборудования. Иметь шаблонный процесс приемки нового оборудования на обслуживание с возможностью маркировки оборудования штрих-кодом.
Planado
Возможно добавить новую запись об Объекте. Объект некая универсальная сущность, фактически просто текстовая запись с привязкой к компании-владельцу и контактом.
Отсутствует само понятие базы оборудования (CMDB), что достаточно странно для такой системы.
В случае необходимости приемки оборудования вероятно можно создать специальный шаблон наряда и добавить в него поле со штрих-кодом.
Частично решает поставленные задачи. Позволяет вести учет клиентского оборудования, находящегося на обслуживании. Доступно в мобильном клиенте.
Но нет возможности сканирования штрих кодов с серийными номерами. Нет возможности маркировки оборудования. Достаточно простой интерфейс добавления атрибутов и типов оборудования.
Отсутствует само понятие базы оборудования (CMDB), что достаточно странно для такой системы. Вообще, система больше подходит торговым представителям, чем сервисной компании, хоть изучали мы именно решение Service.
Подходит под поставленную задачу. Входит в функциональность продукта BPM Service Enterprise, управление конфигурациями. Ведение CMDB, различные типы CI, информация о локациях и сотрудниках использующих CI, история событий, сервисная модель. Также встроена подробная аналитика.
Со слов сотрудников компании штрих кодирование в процессе интеграции, расширение функциональности в рамках проекта.
Также подходит под поставленную задачу. Есть возможность настройки иерархии оборудования через родительский объект, со слов сотрудников есть возможность добавить любые поля в карточку оборудования (Серийный номер, тип, модель и т.д.)
Также справляется с поставленной задачей. Реализован классический функционал CMDB. Типы конфигурационных единиц, настройка жизненного цикла, привязка конфигурационных единиц к заявкам и т.д.
Доступно в мобильном приложении. Также возможно самостоятельно настроить сканирование шрихкодов с мобильного устройства. Сильно упрощает процесс инвентаризации (по информации от сотрудников).
3. Плановые заявки
Задача: Этот пункт имел для нас очень большой вес, так как интересовала не просто возможность повторить какую-то заявку через какое-то время, а возможность гибкой настройки плановых заявок. Необходимо иметь возможность настроить для разного типа оборудования разные заявки с разной периодичностью. Периодичность может зависеть от оборудования, от вида работ по оборудованию и типа заявки. Периодичность может быть разного вида: раз в месяц, раз в неделю, каждый первый понедельник месяца и т.д. Также эта заявка должна быть сразу привязана к заказчику и создаваться за указанное время до начала работ, чтобы успеть её распределить на инженера.
Весь функционал плановых заявок закончился на возможности создать повторяющийся наряд на основе одного из шаблонов. Делается в разделе настроек.
Настройки интервала создания нарядов. Есть возможность задавать начало и окончание работы планировщика.
Фактически этот инструмент позволяет только копировать текущие заявки через определенный период с возможностью указания даты окончания.
Не совсем то, что мы искали.
Тут тоже указанный функционал присутствует, но его реализации вновь недостаточно для выполнения поставленной задачи. Опять-таки, можно создать заявку и настроить её копирование через указанный период, но здесь даже нельзя указать дату окончания повторения и нет возможности создавать заявку в системе за несколько дней до начала работы с заявкой, чтобы успеть распределить её на сотрудника и запланировать по ней работы.
Необходимого функционала найти не удалось. Можно просто создавать заявки на будущую дату, что не является полноценным механизмом создания плановых задач.
Существует возможность при создании активности (заявки) настроить её цикличность и настроить напоминание по этой заявке ответственному сотруднику. После получения этого уведомления сотрудник проверяет актуальна ли заявка (например, активен ли договор на сервис у заказчика) и после берет заявку в работу.
HubEx также имеет возможность создавать и гибко настраивать плановые заявки. Удобной особенностью стало то, что настройка плановых заявок выделена в отдельной вкладке, т.е. если нам нужно изменить логику повторения заявки или вовсе удалить плановую заявку по компании так как у неё кончился сервисный контракт – это можно удобно сделать в одном месте, а не искать «прародителя» заявки по которой настроено повторение.
Также можно настроить автоматическое распределение плановой заявки на исполнителя в зависимости от настроенных параметров или сразу привязать к конкретному выездному инженеру. Довольно удобно.
Было бы странно, если бы у одного из лидер ов рынка автоматизации процессов не было возможности настройки плановых заявок.
Из плюсов – как и у HubEx планировщик выделен в отдельный интерфейс. Настройки повторения тоже довольно гибкие.
Из минусов – требуется приобретение и установка дополнительного модуля. Ну и интерфейс демонстрирует нам насколько давно компания на рынке
Это еще не конец…
Даже писатели русской классики разбивали свои труды на несколько томов. Сравнив только 3 задачи из 10-ти, которые мы ставили перед платформой автоматизации, получилось уже 14 страниц мелким шрифтом. Поэтому, как учили в начальной школе: «мы немножко отдохнем и опять писать начнём» 🙂
А вы, дорогие читатели, пока оцените полезен ли такой труд, всего ли хватает и напишите об этом в комментарии. Мы обязательно их учтем в следующих частях после переменки!
В чем заключается разница между HelpDesk и ServiceDesk
Базовые задачи Help Desk (HD) и Service Desk (SD) — это оказание техподдержки конечным потребителям и помощь в решении возникшей проблемы. Понятия Service Desk и Help Desk часто путают из-за похожих названий и почти одинаковых функций. Однако эти термины не синонимы.
Для пользователей различие между данными сервисами незаметно, так как потребителю важно только качество предоставляемых услуг и оперативность в решении проблем. Однако для IT-подразделений эта разница ощутима, так как Help Desk и Service Desk выполняют различные по объему функции, отличаются друг от друга ориентацией и целью использования в бизнесе.
Что такое Help Desk
Helpdesk (Стол помощи) — это инструмент который предназначен для регистрации, обработки и выполнения запросов потребителя. Сервис обеспечивает коммуникацию IT-службы с другими подразделениями и клиентами организации.
Функции, которые выполняет Help Desk:
Основная задача HD как сервиса — это максимально автоматизировать работу службы техподдержки пользователей, настроить ее функционирование так, чтобы позволить сотрудникам IT-отделов оперативно решать проблемы и запросы пользователей.
Таким образом, Helpdesk — это единое окно, куда может обратиться пользователь со своей проблемой, которую специалисты IT-службы должны решить. Более подробно о HelpDesk читайте в нашем материале.
Что такое Service Desk
Servicedesk (Стол обслуживания) — имеет более широкое понятие и подразумевает под собой управление над сообщением между пользователями и отделом техподдержки. Он ориентирован на оптимизацию разного рода бизнес-процессов предприятия и предоставлении продуктивной работы каждого подразделения.
Помимо тех же функций, что есть у Help Desk, Service Desk наделен следующими возможностями:
Применяя системы SD можно ранжировать и систематизировать запросы пользователей, автоматизировать и структурировать рабочие процессы предприятия.
Таким образом Service Desk представляет собой часть целой стратегической организации, которая направлена на: улучшение качества предоставляемого сервиса и повышение клиентов. Более подробно о ServiceDesk читайте в нашем материале.
Попробовать Smart Service
Обратная связь
Ваше сообщение было успешно отправлено
Чем Help Desk отличается от Service Desk
Несмотря на то, что Helpdesk и Servicedesk выполняют схожие функции, между ними все же имеются отличия:
Сравнивая Help Desk и Service Desk между собой, можно сделать вывод, что эти понятия отличаются по функционалу и объему затрагиваемых в работе процессов.
Как эти системы помогают бизнесу
Интеграция Servicedesk и Helpdesk принесет выгоду всем — собственникам бизнеса, руководителям организации, IT-подразделениям и конечным потребителям.
Автоматизация процессов позволяет принимать и формировать все запросы в единой IT-среде, устанавливать их приоритетность и срочность, а также учитывать SLA при их решении. Равномерное ранжирование задач и четкий план их выполнения не даст специалистам IT-службы запутаться. Благодаря настроенным шаблонам, алгоритмам обработки, подсказкам и уведомлениям, однообразные задачи перестанут отнимать время.
Такого рода системы ликвидируют проблемы, связанные с медленным отзывом IT-служб на заявки пользователей. Также улучшается качество сервисного обслуживания компаний, у которых офисы и подразделения расположены в разных регионах. Соответственно, повышается уровень безопасности IT-инфраструктуры организации, снижаются затраты и появляется возможность их спрогнозировать.
Для потребителей, внедрение Helpdesk и Servicedesk охарактеризуется улучшением качества предоставляемого обслуживания и сокращением периодов остановок связанных с проблемами в IT-инфраструктуре.
Для IT-служб, интеграция систем, станет решением проблемы, в ситуациях, когда бизнес не понимает запросы менеджеров IT-подразделения. Помимо этого, IT-департамент сможет предоставлять корректную и актуальную информацию о проделанной работе.
Также, внедрение систем Helpdesk и Servicedesk позволит сформировать конкретные требования к сотрудникам IT-службы и вырабатывать у них определенные навыки.
Что лучше выбрать для своей организации
Выбирать ту или иную систему необходимо отталкиваясь от задач, которые стоят перед IT-службой в организации.
В некоторых компаниях процессы техподдержки имеют специфику. Одни хотят контролировать выезд мастера на место, другие создание счета, а кто-то подключает систему в рамках решения заявок юристов или специалистов по продажам для подготовки договоров или пролонгации контрактов. Поэтому важно, чтобы сервис позволял добавлять собственные этапы или статусы для каждого вида запроса. При этом для линейных процессов важна возможность определять последовательность переходов между состояниями.
Таким образом выбирая между Helpdesk и Servicedesk, важно обращать внимание на следующие моменты:
Главное — определиться с приоритетными процессами компании и, обратившись к специалистам, подобрать соответствующий функционал для службы техподдержки, при этом систематизировать ее работу и тем самым повысить производительность организации.
Внедрение Service Desk и CRM. 13 главных причин неудач и как их избежать?
По данным The Standish Group в США и Европе за 2015 год:
Последние лет 10 эти цифры практически не меняются — при внедрении ИТ систем, бизнес сталкивается с типовыми проблемами, которые можно сгруппировать следующим образом:
Мы разрабатываем Help Desk систему для автоматизации всех процессов постпродажного обслуживания в сервисных компаниях. Поговорив с более чем 5000 представителями из самых различных сервисных отраслей (средний и малый бизнес), мы решили поделиться причинами неудачных внедрений Service Desk в России/СНГ и методами преодоления большинства трудностей! На самом деле проблемы получились «универсальные» для внедрения любых ИТ систем и ИТ проектов.
Уверены, это позволит вам подготовиться и избежать хотя бы часть из них.
Внедрение Service Desk. Российские реалии
Общение с 5000+ сервисными компаниями, работающими в сегменте b2b в России и странах СНГ, не дает точную статистику по проектам, но позволяет выявить похожие группы проблем (не без локальной специфики). Далее каждый пункт мы рассмотрим подробнее, остановившись на самых популярных «представителях» неудач. Стоит отметить, что использованная классификация проблем условна и выбрана лишь для удобства изложения. Выделенные группы друг с другом пересекаются. К примеру, боязнь изменений неразрывно связана с организационными моментами и т.д.
Серебряная пуля
«Service Desk система сама решит все проблемы»
Многие действительно верят, что система автоматизации решит все проблемы. В сложившихся процессах большинства сервисных компаний царит хаос, и кажется, что внедрение Service Desk или CRM позволит получить полный контроль над ситуацией в части продаж или клиентской поддержки.
Это большая ошибка. Есть известная поговорка: «Если у вас в компании хаос, то итогом внедрения системы автоматизации будет автоматизированный хаос».
Никакой инструмент не решит назревшие внутренние проблемы. Эффект от внедрения Service Desk в компаниях с низкой зрелостью, несомненно, даст серьезный эффект (например, позволит исключить потерю заявок, сократить просрочку SLA и т.д.). Но успешное завершение проекта с понятными и измеримыми результатами, которое и дальше можно развивать, в общем случае вряд ли возможно без изменения организационной составляющей.
«Натянем» на наши требования
Эта проблема характерна для более крупного и бюрократизированного бизнеса.
Как правило, процессы в таких компаниях развиваются в течение длительного времени, складывается какая-то схема управления. Поверх этой системы существует “лоскутная” автоматизация — Service Desk в каких-то конкретных направлениях, разные CRM в разных департаментах и т.д. Но бизнес хочет получить единую централизованную и автоматизированную систему, увязав все процессы друг с другом. Ошибка в том, что при этом он не хочет подстраиваться под существующие системы и лучшие практики, в соответствии с которыми они разрабатываются, пытаясь «натянуть» выбранный продукт на свои требования. А сделать это крайне сложно.
Для достижения результата вместе с проектом внедрения придется менять подходы к работе, проводить организационные изменения и даже избавляться от каких-то людей или, наоборот, вводить новые роли в штате. И все это нужно делать обоснованно, понимая, каких показателей требуется достичь.
Внедрить Service Desk. Боязнь изменений
«Наши клиенты так не привыкли»
“Это не заработает, потому что наши клиенты так не привыкли”.
Они не готовы даже попробовать изменить существующую схему работы, например, предложив новые более простые и удобные механизмы на тестирование нескольким своим клиентам. С самого начала у них есть уверенность, что клиенты отторгнут всё новое. А значит, и нет смысла запускать проект или, наоборот, запущенный проект не доводят до конца.
«Потребуется реорганизация»
Эта проблема в бОльшей степени связана с внедрением именно service desk систем из-за сравнительной сложности процессов поддержки. Отказ от проектов связан с боязнью реорганизации. Но зачастую такие изменения идут на пользу бизнесу. В их основу могут лечь «передовые практики и библиотеки», в которых они агрегированы — ITIL, или подход к организации сервисного управления ITSM, но малому и среднему бизнесу от использования этих «лучших» практик, конечно, отказаться.
Отличный пример — сервисная компания, где обслуживанием занимается уже не 2-3, а 10 и более человек. При таких масштабах, во-первых, уже имеется большой поток заявок, во-вторых, есть четкая градация людей и по компетенциям, и по оплате. Реорганизация службы поддержки подразумевает выделение первых, вторых, третьих линий, изменение взаимодействия с подрядчиками и много всего прочего.
Не учитывая реорганизацию, компании либо боятся запускать проекты внедрения service desk систем, либо внедряют их, но не получают требуемого результата (автоматизируют хаос).
«Реальные временные затраты вырастут»
Компании откладывают внедрение инструментов, когда понимают, что реальные временные затраты сотрудников при работе с новой service desk системой вырастают. И это чистая правда!
Времени, на первых порах, действительно придется тратить больше. Например, придется регистрировать 100% заявок, отмечать выполненные действия при их обработке, списывать трудозатраты и т.п. Но точки неэффективности не выявить без фиксации активностей и отслеживания метрик по ним. А потому перед стартом проекта нужно просто ответить себе на вопрос «Чего мы хотим по итогам внедрения service desk?»
Панибратство: «Коллеги будут недовольны»
В российском бизнесе очень распространены «панибратские» отношения. И чем более “домашней” является компания, тем больше это вызывает сложностей. Особенно ярко это проявляется в компаниях на периферии — в бизнесе на 10 — 20 человек, которые давно работают вместе.
Панибратство порождает сложные моральные вопросы, когда требуются изменения или увольнения тех, кто работает плохо. Часто в таких ситуациях проект приостанавливается, а новый инструмент не используется, потому что внутри компании возникает недовольство или вопрос без ответа: «Как же так?»
В подобной ситуации придется расставить приоритеты. Если важнее панибратские отношения, то нет смысла думать об эффективности бизнеса и деятельность, которой занимается Ваша компания называть бизнесом в принципе. А тем более внедрять инструменты, обличающие «узкие» места. Но если нужны результаты, придется проявлять жесткость. Внедрение Service Desk как раз позволит принимать объективные и обоснованные решения в вопросах сервисной поддержки и постпродажного обслуживания клиентов.
Организационные ошибки и сложности при внедрении Service Desk
Внутреннее сопротивление
Сотрудники компаний не любят изменений сложившегося уклада. Например, сидел диспетчер и в журнале ручкой по-старинке записывал все обращения от жителей дома о неработоспособности лифта, спокойно пил чай. А тут его заставляют что-то фиксировать в непонятной системе. Естественно, он сопротивляется.
Проблема в том числе бывает связана с возрастом. Чем старше коллектив, тем он сложнее в части принятия нового, изменения форматов работы.
Нет реальной заинтересованности руководства / ЛПРов (лиц, принимающих решения)
В бОльшей степени это актуально для среднего и малого бизнеса. Руководители таких компаний вынуждены быть «многостаночниками». Они и продают, и осуществляют поддержку клиентов, и решают бюрократические проблемы. И когда у них нет реальной заинтересованности в проекте, ничем хорошим он не заканчивается.
В любом проекте нужен «драйвер». Он может «прийти» от высшего руководства — оптимальный вариант. В ином случае руководителю среднего звена или человеку, отвечающему за блок процессов внутри компании, придется его внутри «продать» и отвечать за результат.
Отсутствие или проблемы с проектным подходом
Нет выделенной команды и руководителя проекта
Когда компании не выделяют людей, отвечающих за результат внедрения сервис деск системы, ничего не получается.
Если проект небольшой и людей в компании мало, выделенная команда не нужна. Но должен быть руководитель проекта, наделенный полномочиями. Он обязан вести проект к своей финальной точке, отвечая за бюджеты и людей, имея возможность применить организационные воздействия или мотивационные схемы.
Кстати, нужно не просто выделить людей с понятными полномочиями и обязанностями, а хотя бы частично одновременно снять с них активности по другим направлениям.
Нет выделенного времени у тех, на кого это повлияет
Зачастую в компании есть выделенная проектная команда и даже ее руководитель, но нет времени у тех, на кого повлияет внедрение сервис деск системы. Например, инженеры, исполняющие заявки или программисты (если мы включаем их в процесс поддержки в виде третьей линии). Когда их время не выделяется и, самое главное, у людей нет мотивации и понимания, зачем это нужно, проект упирается во внутреннее сопротивление и «саботаж».
Нет реальных требований и сценариев использования (scope проекта)
Такие проблемы часто встречаются и на западе: на старте нет четких требований ни к системе service desk, ни к результатам проекта. Это приводит, в том числе, к бесконечному процессу выбора решений. У таких заказчиков есть желание автоматизировать абсолютно всё — натянуть систему на свои требования (об этом — выше), либо предъявляемые к системе требования постоянно изменяются.
В конечном счете проекты забрасывают, не начав: тестируют 20 систем по несколько раз и осознают, что ни одна не подходит. Еще хуже, если проект был запущен, определены какие-то бюджетные и временные рамки, а потом требования «расползаются», что приводит к значительному срыву срок и серьезно «раздутых» внутренних затрат. На определенном этапе становится проще его забросить.
Нет «воздействия» (Check — Act)
Многие компании, получив первичные результаты (иногда очень неплохие, особенно если до этого ничего автоматизировано не было), перестают улучшать систему и процессы, для автоматизации которых она предназначена. Они перестают контролировать показатели и, самое главное, по итогам этого контроля предпринимать последующие воздействия.
Сказка про «качественно/быстро/бесплатно»
До сих пор у многих, особенно небольших компаний, есть убеждение, что можно найти систему или людей, которые все сделают быстро, качественно и практически бесплатно. В присутствии этой надежды проект заканчивается ничем — получается долго, не очень дорого, и некачественно.
К этой категории проблем стоит отнести и желание клиента разработать собственную Service Desk систему (почему этого не стоит делать мы подробно писали в нашей заметке). Если у компании есть возможность выделить 2-3 программистов, например, на полгода — год, значит дела у Вас очень плохи — бизнес не сфокусирован на том, чем он должен заниматься. По тем направлениям, которые не являются для бизнеса ключевыми, лучше привлекать людей или использовать системы «со стороны», а не изобретать свой велосипед.
Внедрение Service Desk. Как избежать ошибок?
Вот несколько универсальных рекомендаций, которые позволят Вам сэкономить время на этапе запуска проекта и внедрения Service Desk системы: