Попробовать

Service Desk. Подробная инструкция по выбору решения и внедрению.

Лучшее
Опубликовано: 16.04.2018
Обновлено: 23.03.2023
Время на чтение: ~9 мин.

Многие бизнес-процессы в небольших компаниях — типовые. Однако выбрать решение, подходящее под их исторически сложившуюся комбинацию бывает не так-то просто. Даже если продукт соответствует основным требованиям, в ходе эксплуатации вполне может обнаружиться какая-нибудь «неприятность». Например, интерфейс настолько неудобен, что на типовые операции сотрудники тратят столько же времени, сколько и без системы автоматизации вовсе. А может в выбранном решении будет «криво» реализована поддержка важной для вас платформы? Инвестиции системы с такими «недочетами» не приносят ожидаемого результата.

Как выбрать help desk и не ошибиться?

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

Как минимизировать риск на этапе выбора help desk решения? Как правильно внедрить Service Desk? Подробная инструкция по успешному внедрению!

Service Desk. Тестовые внедрения

Поиск Help Desk. Как внедрить в компании

Для снижения подобных барьеров разработчики решений, автоматизирующих различные аспекты бизнеса, предлагают пробный (триальный или тестовый) период, когда можно оценить все функции и возможности программного обеспечения. А заодно можно пообщаться с поддержкой вендора, сделав вывод, сложится ли ваше сотрудничество.
Благодаря «тестовым внедрениям» выбор программных инструментов для большинства компаний может проходить по стандартной схеме:

Постоянный поиск решения. К чему это приводит?

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

  • тратятся ресурсы. Хотя тесты проводятся на пробных бесплатных версиях, для компании они все равно стоят денег. В первую очередь расходуются человеко-часы (которые оплачиваются через ФОТ). А иногда под тесты закупается оборудование или нанимается дополнительный персонал;
  • расходуется время. Можно подумать, что начало проекта внедрения уже само по себе ставит компанию на новый уровень — например, ближе к конкурентам, успевшим автоматизировать основные операции ранее. Но это не так. Из-за необходимости обучать часть сотрудников новым инструментам, менять их рабочие привычки, первое время после внедрения задачи решаются даже медленнее, чем без автоматизации. Т.е. на самом деле реформа используемого подхода отбрасывает компанию немного назад. Однако если научиться и привыкнуть, отставание быстро окупится значительным ускорением. Как говориться, «день потерять, потом за 5 минут долететь». Гораздо хуже, если вслед за первым внедрением последует второе, третье и последующие — в этом случае придется все время отступать немного назад. Конкуренты же в это время будут либо просто работать, не тратя время на параллельные проекты, либо с огромной скоростью уходить вперед, завершив автоматизацию;
  • теряется доверие к руководству и людям, принимающим решения. Если сотрудников постоянно заставляют делать работу, которая не приводит к какому-то результату (а после теста очевидный результат — внедрение решения в «боевом» режиме), то у «низов» начинаются вопросы.

Service Desk и его внедрение. Новый подход к выбору

Внедрение Service Desk. Новый подход

Чтобы не превращать выбор системы автоматизации в разновидность «дня сурка», прежде чем что-то в очередной раз выбирать и тестировать, необходимо определиться с несколькими моментами:

  • с требованиями к ПО по части архитектуры, безопасности, функционала и интерфейса. Повторный возврат к выбору решения означает, что в самом начале задача была сформулирована некорректно или не полностью. Возможно, следует вернуться ко второму шагу в перечне выше — сбору и анализу требований заинтересованных сторон;
  • с критериями принятия положительного решения. Довольно редко существующие массовые решения в деталях удовлетворяют требованиям всех без исключения участников рынка. Так уж устроена экономика ИТ-продуктов: инструменты, рассчитанные на массового пользователя, разрабатываются, чтобы удовлетворить потребности большинства, но не всех без исключения. Поэтому нужно изначально понимать, что выбирая готовый продукт (а не индивидуальную разработку под себя), придется идти на компромиссы. И это необходимо формализовать. Например, мы договариваемся, что внедряем не идеальное решение, а то, которое получит самый большой средний балл из всех по таблице соответствия нашим требованиям;
  • с людьми, которые будут задействованы в выборе, принятии решения и внедрении. Необходимо понять, кому предстоит соприкасаться в своей работе с инструментом и какие он может ставить условия. Не логично же, если бухгалтерия будет определять интерфейс для сотрудников поддержки. Важно не раздувать список затронутых работников без необходимости, ведь иначе это только усложнит процесс. И нужно подготовиться к тому, что требования разных отделов к продукту могут противоречить друг другу. Кто в этом случае будет принимать решение? Отметим, что слишком много требований — также плохо, как и слишком мало: они не отражают реальное положение вещей. Поэтому необходимо установить приоритет — чьи и какие именно требования важнее.
  • аналогично нужно дать кому-то полномочия принимать решения по проекту, в частности, устанавливать высокий приоритет его задачам на фоне текущей деятельности компании, иначе проект может так никогда и не завершиться;
  • с ресурсами на внедрение — как минимум, со временем. ИТ-системы, конечно, можно преобразовать за ночь, но с ними работают люди, которые намного более инертны. После любых изменений сотрудникам требуется время на адаптацию. Измерять эффект на утро после запуска бессмысленно, как и с первого часа работы с новой системой требовать от них соблюдения тех же метрик времени, что и с привычными инструментами;
  • с целями внедрения теста и ожидаемым результатом, и это самое главное. Иногда решение о тестировании очередного продукта принимается на уровне «давайте посмотрим, а потом подумаем». В такой формулировке проект, скорее всего, не дойдет до финальной стадии. Всегда нужна определенность: четкие и реалистичные критерии, которые позволят в правильный момент перейти от тестирования к полноценной работе.
  • о реализуемости, кстати, хотелось бы сделать отдельное замечание. Хотя на рынок ИТ-технологий уже пришел здоровый прагматизм, все еще остается доля заказчиков, имеющих завышенные ожидания относительно внедрения средств автоматизации. Помимо технических задач, на тестируемые продукты возлагают решение организационных вопросов — и тут ничего не выходит. Зачастую причина тому — плохая информированность о кейсах внедрения подобных решений.

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

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

Облегчить задачу можно, если Service Desk простой, позволяет быстро запуститься и не требует серьезной подготовки и настройки. Например, одним из самых простых и удобных решений на рынке Help Desk является Okdesk.

Поделитесь статьей
Кирилл Федулов
Сооснователь и директор по развитию Okdesk. Около 10 лет проработал в компании Naumen, где занимался внедрением ITSM и service desk систем в крупнейших российских компаниях: Полюс, Тинькофф, ЛСР и др. Эксперт в области организации и автоматизации процессов техподдержки, сервиса и выездного обслуживания
Популярные материалы
Опыт клиентов
Опыт компании Punkt E: как обеспечить работу крупнейшей сети электрозаправок в соответствии с SLA?
14.11.2023
Опыт клиентов
Экономия на разработке. Опыт перехода с конфигурации 1С на Okdesk
24.08.2023
Опыт клиентов
Зачем мигрировать с корпоративной service desk на Okdesk — Опыт «Совтех»
18.10.2021
От экспертов
Help desk система: что это и зачем она нужна вашей компании?
08.10.2021
Лучшее
10 признаков того, что вашей компании нужна новая help desk система
28.01.2021
Как ручной учёт обращений вредит сервисному бизнесу
Рекомендуем почитать
Прочее
ITSM и ITIL. Как использовать? В чем отличия и суть?

Многие сталкиваются с аббревиатурами ITSM и ITIL. Насколько это полезно сервисным компаниям и как использовать ITSM в своей работе? Попробуем объяснить основные принципы и терминологию простыми словами.

Прочее
Service Desk — как успешно внедрить систему? 12 успешных примеров (часть 1)

Цифры это то, что все мы любим, однако далеко не всегда эффект от применения инструментов автоматизации легко поддается измерению. К примеру, бытует мнение, что использование Helpdesk систем не приводит к сколь либо значимым результатам для клиентов. Этот тезис уверенно опровергается историями успешных внедрений, которые повествуют о том, как применение Help Desk и Service Desk существенно улучшило показатели рассматриваемых организаций. Представляем первую "порцию" таких результатов.  

От экспертов
Дефицит кадров в отрасли сервисного обслуживания медицинского оборудования: масштабы, причины, решения

Как продолжать эффективно вести бизнес при дефиците сотрудников? Разбираемся в причинах и масштабе нехватки кадров, а также что делать бизнесу в этой ситуации.

Прочее
Help Desk — как успешно внедрить систему? 12 успешных примеров (часть 2)

В предыдущей статье мы рассказали о различных успехах внедрения HelpDesk и Service Desk систем для поддержки клиентов. Так, мы увидели, как Сервис Деск решения позволили: —  Sennheiser уменьшить время реакции на обращения более чем в 5 раз; —  Whirpool уменьшает количество входящих email на 20%; —  сервис Jamberry оптимизировал штат поддержки на 20% и более; —  «Кейсистемс-Иваново» — повысил удовлетворенность клиентской поддержкой до 96,4%. В сегодняшней заметке представляем Вам вторую порцию успешного внедрения Service Desk и Хелп Деск систем.

От экспертов
Управление инцидентами по ITIL

ITIL — библиотека, где собран практический опыт компаний по внедрению процессного подхода к управлению ИТ-услугами. Фактически, это сборник рекомендаций по воплощению ITSM в отдельно взятой организации. Один из основных процессов, описанных в этой библиотеке, — управление инцидентами, на котором мы и сконцентрируемся в этой статье.

Опыт клиентов
«Переезд» без происшествий или как разработчику программно-аппаратных комплексов оперативно сменить help desk систему

Рассказываем, как один из ведущих отечественных разработчиков и производителей систем безопасности «Инфоматика» мигрировал на Okdesk.

Полезные материалы
Дважды в месяц о развитии и автоматизации сервиса, техподдержки и выездного обслуживания.
 
Нажимая на кнопку «Подписаться», вы даете согласие на обработку своих персональных данных.
Полезные материалы
Дважды в месяц о развитии сервиса, техподдержки и выездного обслуживания.