Как написать service desk

IT-технологии полны жаргона. Среди бесконечных ИТ-терминов существует два важных понятия, связанных с обеспечением информационной и технической поддержки: Help Desk и Service Desk.

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

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

Разница между Help Desk и Service Desk заключается в обширности понятий. Service Desk, в отличие от своего «собрата» — услуга более широкая, рассматривающая предоставление IT-поддержки с точки зрения сервиса, включающего процесс управления качеством обслуживания (SLM) и уровень качества сервиса (SLA).

Help Desk же является, в первую очередь, IT-ориентированным сервисом по ликвидации инцидентов.

Для обеспечения высокого уровня технической поддержки ваших клиентов в Битрикс24 необходим инструмент, способный не только быстро отрабатывать инциденты, но и:

1. в едином окне обрабатывать поступающие в поддержку заявки, независимо от характера данных обращений. Задачи могут быть как для отдела разработки, так и для первой линии поддержки;
2. поддерживать постоянную связь с клиентом, для быстрого уточнения деталей задач и заявок;
3. скрывать от клиента «внутреннюю кухню» компании: технические ресурсы, затраты на задачу, заявки других клиентов и другие нюансы. Это гарантирует конфиденциальность информации.

Для удобства обработки большого количества задач мы создали гибкое и масштабируемое решение — Service Desk.

Модуль Service Desk — это специальная надстройка от разработчиков компании ПУСК, встраиваемая в ваш Битрикс24. Инструмент необходим для грамотной организации технической поддержки внутри корпоративного портала. С помощью Service Desk решается вопрос сопровождения:

• Сотрудников, работающих с Битрикс24
• Клиентов вашей компании

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

1. Сопровождение текущих систем: отработка инцидентов и запросов на обслуживание
2. Запрос на изменение: доработки и улучшения

Управление задачами в Service Desk может осуществляться с помощью классического списка с выставлением крайнего срока и ответственных. Но мы рекомендуем представление задач в методологии Канбан
с визуально-понятными карточками и цветовым обозначением:

Модуль Service Desk может использоваться не только в сфере IT, но и в автоматизации обработки хозяйственных заявок, закупок и других областей бизнеса.

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

В данной статье расскажем, как работает модуль, и какие преимущества он предоставляет для пользователей коробочной версии Битрикс24.

• О Service Desk простыми словами
• Как настроить Service Desk на коробочном портале?
• Пример работы с Service Desk
• Service Desk: преимущества и недостатки
• Модуль Service Desk: видео

О Service Desk простыми словами

Качественная IT-поддержка повышает удовлетворенность клиентов и позволяет предоставлять услуги, соответствующие ожиданиям вашей целевой аудитории.

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

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

Как настроить Service Desk на коробочном портале?

После внедрения модуля компания получает инструмент со штатными настройками, достаточными для полноценной работы. Однако большинство параметров Service Desk доступны для редактирования. 

НАСТРОЙКИ НА УРОВНЕ АДМИНИСТРАТОРА

После приобретения и установки модуля от компании ПУСК необходимо настроить Service Desk в административной панели.

Для редактирования доступны следующие параметры:

1. Привязка к одной или нескольким группам, в которых будут действовать правила отображения модуля
2. Исключение пользователей из отчетов Сервис Деск
3. Назначение плана (в часах) на день для каждого сотрудника и ежемесячного плана для каждого клиента

ОПРЕДЕЛЕНИЕ СТАДИЙ ЗАДАЧ SERVICE DESK

Следующий этап настройки модуля — определение стадий. По умолчанию мы добавили в Service Desk пять статусов задач. Но все стадии можно менять, удалять или добавлять вручную, подстраивая под логику Вашей организации.

Согласно общим рекомендациям воронка Service Desk стандартно имеет следующий набор статусов:

1. Новые заявки — стадия сбора задач
2. Сбор информации (либо: Классификация) — стадия первичной классификации всех задач
3. Запустить в работу — стадия формирования приоритетов (очереди) выполнения задач
4. В работе — стадия, на которой находятся все задачи, выполняющиеся в данный момент
5. Завершена — финальная стадия: статус задачи «Закрыта». Как правило, не отображается на доске

ОПРЕДЕЛЕНИЕ ДОПОЛНИТЕЛЬНЫХ ПОЛЕЙ

Далее следует определить дополнительные поля. Штатно в модуле Service Desk предусмотрено три пользовательских поля:

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

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

1. Таймер LU на карточке задачи — Last update — временной параметр, который устанавливается автоматически с момента последнего изменения в задаче
2. Таймер WIA на карточке задачи — Work in age — время жизни задачи с момента ее взятия в работу

КЛАССИФИКАЦИЯ ЗАДАЧ (АВТОМАТИЧЕСКИ)

Согласно дополнительным полям, описанным выше, Сервис Деск присвоит задаче классификацию. Всего видов задач в Service Desk три:

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

Пример работы с Service Desk

Рассмотрим, как выглядит типичный сценарий работы с модулем Service Desk, после настройки.

1. На портал добавляется внешний пользователь: клиент вашей компании
2. В карточке профиля внешнего пользователя указывается принадлежность к компании — это поможет отсортировать задачи по привязке к CRM
3. Внешний пользователь или сотрудник вашей компании создает задачу в группе Service Desk (стадия: Новые заявки) 
4. Задача оценивается аналитиком (или другим уполномоченным сотрудником). Определяется предполагаемое время на выполнение задания, заполняются все необходимые поля (стадия: Сбор информации)
5. Оформленная задача передвигается на следующую стадию, ожидая своей очереди на выполнение (стадия: Запустить в работу)
6. Задача вытягивается из очереди и выполняется сотрудником того или иного отдела (стадия: В работе)
7. Задача проверяется внешним пользователем и успешно закрывается сотрудником по итогам проверки (стадия: Завершена)
8. Руководитель просматривает план выполнения задач по каждому сотруднику в специальных Отчётах:

Service Desk: преимущества и недостатки

Итак, система Service Desk — незаменимый помощник в построении качественной IT-поддержки. Модуль Service Desk от компании ПУСК поможет специалистам вашей организации сосредоточиться на выполнении своих непосредственных обязанностей и задач. Помимо этого Сервис Деск:

• Помогает поддерживать общение с клиентами вне зависимости от канала связи
• Позволяет оптимизировать расход наиболее ценного ресурса компании — времени специалистов
• Помогает автоматизировать распределение заявок между специалистами, без перегрузок

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

Каковы же недостатки Service Desk?

Во-первых, как и любая другая система, Service Desk требует определенных навыков и дисциплинарного подхода к работе. Для пользователя, далекого от IT-области, постичь элементы методологии ITSM (на которых основаны понятия Service Desk и Help Desk) будет сложнее, чем для, например, программиста. 

Во-вторых, внедрять систему Service Desk следует, если в вашей организации есть полноценный IT-департамент с отдельной выделенной линией технической поддержки. 

Модуль Service Desk: видео

В качестве наглядной демонстрации работы модуля Service Desk от компании ПУСК мы добавили видео основных возможностей:

Установите модуль Service Desk на ваш Битрикс24 и убедитесь, что  инструмент дает результаты.

Организуйте в своей компании стабильность и прозрачность ИТ-процессов! 

По всем вопросам звоните по телефону +7 (495) 118-39-18 или просто заполните форму ниже.

Вас также может заинтересовать:

Время на прочтение
4 мин

Количество просмотров 19K

Сегодня я начинаю небольшой цикл статей «service desk — быстрый старт».

В цикле планируется описать собственный опыт и дать рекомендации, как можно с нуля построить систему Service Desk в компании, основываясь на методологии ITIL. Рассматривается именно внедрение модуля обработки инцидентов, обращений и учета активов. Другие модули в рамках данного курса статей не рассматриваются.

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

• Определение цели внедрения Service Desk, стратегические преимущества.
• Создание каталога услуг.
• Создание единого окна, единой точки входа.
• Учет активов.
• SLA.

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

Самый первый вопрос, который необходимо задать себе: с какой целью вы внедряем систему Service Desk? И нужно ли вам это?
Если вы собственник бизнеса, то от вашего ответа будет зависеть внедрять систему или нет.

Если вы ИТ менеджер, или старший ИТ специалист, то от ответа на данный вопрос зависит будете ли вы продвигать данную систему перед владельцами или нет.

В каких случаях необходима система Service Desk? Мне кажется проще ответить когда без нее можно обойтись — в небольших компаниях, с количеством рабочих мест менее 100, находящихся в одной локации с количеством ИТ персонала не более 2-3 человек.

Как только ваша компания перерастает эти объемы, то количество обращений возрастает и к ИТ отделу начинаются вопросы следующего характера:

• Почему про мой запрос забыли?
• Когда вы наконец сделаете то, что я просил?
• Почему так плохо работает компьютер/интернет/принтер и т.д.(подставить требуемое)
• Чем вообще занимаются эти дармоеды в ИТ отделе? и т.д.

Если начинают появляться такие вопросы, значит бизнес становится недоволен качеством работы ИТ отдела.

Что дает внедрение Service Desk:

• Позволяет понять что у вас в принципе происходит. Как часто обращаются те или иные пользователи, как часто ломается та или иная техника, на сколько качественно предоставляются те или иные услуги.
• На основании полученной выше информации вы можете делать выводы о слабых местах. Причем не обязательно проблема может заключаться в технике. Иногда достаточно просто немножко переделать интерфейс программы, и количество обращений снижается вдвое.
• Дает возможность планировать как развитие ИТ инфраструктуры, так и плановое обновление, профилактику и п.р
• Дает возможность обосновать то или иное решение в цифрах. «У главного бухгалтера часто ломается компьютер» это не аргумент. «За последние полгода у гласного бухгалтера 4 раза ломался компьютер, что привело к 20 часам простоя данного специалиста» это уже более веский аргумент для принятия того или иного решения.

Service Desk поможет вам на первом этапе ответить на вопрос — чем же именно занимается ИТ отдел. Действительно ли все так плохо, как описывают пользователи или они пытаются прикрыть свою лень/некомпетентность проблемами с ИТ оборудованием?

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

И вот здесь уже начинается формирование SLA и уточнение каталога услуг, где бизнес соизмеряет свои желания со своими возможностями.
После этого наступает третий этап, когда бизнес следит, что он в обмен на свои средства получает желаемое

При переговорах с бизнесом важно помнить — бизнес мыслит категориями денег. Ему не интересны технические термины. В рамках концепта ITIL бизнес приобретает услугу, а не оборудование. Если проблема звучит — часто не работает 1С Бухгалтерия, то бизнесу не интересно ни устройство сервера, ни причины поломок. Его интересует только — сколько будет стоить это починить и сколько денег будет потеряно если это не чинить.

Внедренная система Service Desk позволяет абстрагироваться от конкретных обращений и наблюдать общие тенденции, выявляя неочевидные связи и находить первопричины проблем. И как следствие, бороться с проблемой, а не с последствиями.

Если у вас есть Service Desk, то вы сможете доступным бизнесу языком объяснить, что у вас происходит, какие есть проблемы, какие есть способы их устранения, стоимость устранения и стоимость рисков в случае не устранения.

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

Если вы все-таки приняли решение внедрять Service Desk, то будьте готовы к росту накладных расходов на выполнение заявок. Теперь технику мало вытащить замятую бумагу из принтера. Он должен зарегистрировать заявку, классифицировать ее, внести комментарий и только после этого закрыть. Бизнес должен это понимать и быть готовым к такого рода затратам. Особенно в первое время, пока система только внедряется и обкатывается.

P.S.
Процессную модель можно использовать не только при построении ИТ службы, но и в любом другом департаменте. Это позволит лучше понимать функции департамента, его загруженность и улучшит контроль за работой персонала.

Первый вопрос, возникающий у ИТ-руководителя, которому предложили идею процессного подхода к управлению ИТ-инфраструктурой: «Зачем мне нужен ITIL (ITSM, Service Desk, управление инцидентами и т. д.), если у меня и так все хорошо?

Первый вопрос, возникающий у ИТ-руководителя, которому предложили идею процессного подхода к управлению ИТ-инфраструктурой: «Зачем мне нужен ITIL (ITSM, Service Desk, управление инцидентами и т. д.), если у меня и так все хорошо?» Вот каким может быть ответ.

Посмотрим, как обычно происходит управление ИТ-инфраструктурой рядового российского предприятия. Начальнику ИТ-отдела звонит генеральный директор компании и сообщает, например, что у него не работает электронная почта. Руководитель ИТ-подразделения ловит в коридоре технического инженера и отправляет его к директору для восстановления работоспособности почты. К этому моменту секретарь топ-менеджера уже сообщил системному администратору о возникшей проблеме, и тот самоотверженно бросается на помощь. Через считанные минуты в дверях кабинета генерального директора одновременно появляются два запыхавшихся «компьютерщика»… Едва ли такие действия можно назвать эффективным управлением ИТ-инфраструктурой.

В компаниях, где ведется регистрация и анализ обращений пользователей (там, где настроен процесс управления инцидентами и функционирует служба Service Desk), ответы на вопросы о том, сколько раз в месяц «зависает» (дает сбой) критически важная для бизнеса программная система, на каких рабочих местах это происходит, в чем причина каждого инцидента, находятся сами собой и могут существенно повлиять на планы развития компании в области ИТ.

Сколько это стоит?

Сегодня найдется немало компаний, которые могут помочь в построении службы Service Desk. Квалифицированные консультанты оценят уровень зрелости процессов ITIL на предприятии, разработают для ИТ-департамента план по внедрению того или иного процесса, подберут и настроят оптимальный инструментарий. Однако услуги консультантов не бесплатны. А руководители компаний среднего и малого бизнеса, как правило, не считают ИТ-департамент стратегическим подразделением и, следовательно, неохотно инвестируют средства в ИТ-проекты. Возникает вопрос: как доказать руководству необходимость выделения средств на развертывание службы Service Desk?

Если не удалось с первого раза убедить высшее руководство предприятия в необходимости инвестиций, то все последующие попытки также будут обречены на провал. Доказать инвестиционную привлекательность службы Service Desk практически невозможно, точно так же, как и рассчитать срок возврата инвестиций. Чтобы оценить экономический эффект, потребуются начальные данные, такие как среднее время разрешения одного инцидента, количество инцидентов в день, месяц, год и т. д. Но если в ИТ-департаменте еще не работает служба Service Desk, то как узнать, какое время в среднем тратится на разрешение одного инцидента? Если нет статистики об обращениях пользователей, то где взять информацию о количестве инцидентов? Помимо этого, на практике в первые месяцы работы службы Service Desk время разрешения одного инцидента увеличивается. Сократить его удается не сразу. Следовательно, говорить о положительном экономическом эффекте в первые месяцы работы службы не приходится.

Итак, если не удается построить Service Desk на средства компании, то можно попробовать развернуть службу самостоятельно, без привлечения сторонних консультантов и затрат на специализированное программное обеспечение.

С чего начать?

Многие скажут, что начинать надо с оформления проекта. Однако в случае построения службы Service Desk подобный подход нереализуем. Какие цели проекта следует указать? Какие сроки поставить? Какие риски проекта описать? Практика организаций, в которых работает Service Desk, показывает, что создать идеальную службу невозможно. Она постоянно изменяется и совершенствуется. Поэтому с большой вероятностью описанные грандиозные цели проекта по созданию Service Desk утратят свою актуальность еще в процессе их достижения. А между тем, срок такого проекта может исчисляться годами! Так нужен ли такой проект? С другой стороны, работать без четко описанных целей также невозможно. Необходимо понимать, в каком направлении двигаться и что должно получиться в итоге.

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

Шаг первый. Фиксируем регламенты

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

Допустим, вы купили новый телевизор. Как часто вы будете пользоваться инструкцией по эксплуатации? Наверное, не очень часто. Тем не менее ни у кого не возникает сомнения в полезности этого документа. То же самое можно сказать об описании функционирования службы Service Desk: оно обычно лежит на полке в одном из кабинетов ИТ-департамента до тех пор, пока не потребуется изменить или усовершенствовать процесс приема и обработки обращений пользователей.

Относительно объема данного документа, его полноты и развернутости четких рекомендаций не существует. Тем не менее нет смысла подробнейшим образом и максимально детально описывать все регламенты службы Service Desk. Документ получится слишком большим и нечитабельным. Однако создавать его излишне кратким также не стоит. В первом варианте документа на один регламент достаточно отвести одну-две страницы.

Какие регламенты и правила функционирования Service Desk следует описать? Однозначных, предельно конкретных советов здесь быть не может. Перечислим лишь наиболее общие из них.

Количество линий поддержки службы Service Desk и распределение ИТ-сотрудников по линиям поддержки. Классика ITIL рекомендует развернуть три линии. К первой линии поддержки могут относиться операторы call-центра, ко второй — администраторы баз данных, системные администраторы, технические специалисты, к третьей — программисты, старшие системные администраторы. Ваши сторонние подрядчики, организации, которые предоставляют вам услуги по сопровождению ПО, провайдеры телекоммуникационных услуг и т. д. также могут быть отнесены к третьей линии поддержки.

Способы приема заявок пользователей. Вариантов достаточно много, начиная от официально оформленной служебной записки в бумажной форме и заканчивая дружеским общением с помощью ICQ. Но в первое время работы службы Service Desk стоит ограничиться одним или двумя способами поступления обращений пользователей. Перечислим наиболее распространенные.

Первый — телефонный звонок пользователя — самый простой и самый эффективный вариант. В этом случае оператор Service Desk имеет возможность успокоить пользователя, если тот чрезмерно взволнован очередным сбоем. Кроме того, в процессе общения с пользователем оператор call-центра может быстро определить причину инцидента и предложить решение. Тем самым запрос будет обработан в самые короткие сроки.

Вторым способом обращений пользователей за поддержкой может быть электронная почта. В этом способе коммуникации с Service Desk есть свои преимущества и недостатки. Далеко не на всех предприятиях пользователи настолько грамотны в области применения ИТ, чтобы с первого раза кратко и понятно описать ситуацию (произошедший сбой). Неточное описание может повлечь за собой долгую переписку между оператором call-центра и пользователем. Результат — увеличение времени решения проблемы. Положительные стороны обращения пользователя в службу Service Desk при помощи электронной почты, разумеется, тоже есть. Например, пользователь направляет электронное письмо с описанием сбоя на определенный адрес. При поступлении нового сообщения в этот почтовый ящик происходит автоматическая регистрация обращения в предварительно настроенной системе службы Service Desk. В этом случае оператор первой линии поддержки не тратит время на регистрацию обращения, а может сразу же приступить к поиску решения инцидента.

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

Приоритеты и временные регламенты. Здесь необходимо описать временные рамки и возможные приоритеты обращений пользователей. Например, обращение пользователя в связи с остановкой основного бизнес-приложения, от которого напрямую зависит прибыль компании, должно иметь высший приоритет. А обращению по вопросу сбоя в работе принтера у одного пользователя должен присваиваться низкий приоритет (если, конечно, этот пользователь — не генеральный директор). В зависимости от приоритетов обращений, необходимо указать время реакции. Например, время обработки инцидента с высоким приоритетом на первой линии поддержки не должно превышать 10 минут. Если проблему не удалось ликвидировать, она переводится на вторую линию поддержки, где на ее решение отводится два часа, после чего обращение переводится на третью линию поддержки. На третьей линии инцидент может решаться, например, пять часов. Если в течение и этого времени не удалось восстановить работоспособность, тогда проблема эскалируется на уровень ИТ-менеджера. Существуют более точные, но в то же время и более сложные варианты расчета времени работы над инцидентом.

Каждый сбой в ИТ-инфраструктуре влечет за собой остановку бизнес-процесса одного конкретного специалиста, и/или отдельного отдела, и/или целого предприятия. Следовательно, каждый сбой имеет различные степени влияния. Поломка принтера у одного человека влияет только на бизнес-процессы одного сотрудника предприятия, и то не на все. Если же принтер сетевой, то влияние сбоя усиливается, поскольку сбои в бизнес-процессах затрагивают нескольких сотрудников. Если же остановился сервер обмена сообщениями (например Exchange Server), то сбой, скорее всего, затрагивает большинство подразделений.

При определенном навыке оператор Service Desk может сразу определить степень влияния того или иного сбоя. Например, если принтер остановился в бухгалтерии, то приоритет может быть невысоким. Бухгалтерские отчеты можно распечатать и днем позже (если, конечно, бухгалтерия не печатает отчеты накануне их сдачи в налоговую инспекцию). А остановка принтера, допустим, в главной диспетчерской центрального склада влечет за собой остановку отгрузки товара и, как следствие, убытки для предприятия. Таким образом, имеются два параметра: степень влияния и приоритет обращения. Исходя из этих данных, можно более детально рассчитать сроки прохождения инцидента по линиям поддержки.

Задача на этапе составления документации — определить степени влияния и приоритеты и на их основе рассчитать время разрешения инцидента на первой, второй и третьей линиях поддержки.

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

«Главный регламент». Это не маршрутизация инцидентов и не перечень предоставляемой отчетности. «Главный регламент» — это мотивация ваших сотрудников. По опыту многих организаций и предприятий, которые развертывали службы Service Desk, можно однозначно утверждать: если не будет выстроена система материальной (и нематериальной) мотивации сотрудников, то служба Service Desk никогда не начнет работать эффективно. Необходимо уделить особое внимание этой части документа. Вот несколько рекомендаций, которые помогут в построении грамотной схемы мотивации.

• Мотивация в большей степени должна быть построена на поощрении сотрудников, а не на наказании. Использовать штрафные санкции допустимо только в крайних случаях, например при нарушении сотрудником установленных регламентов.
• Материальная мотивация должна быть ощутимой. 5% от оклада специалиста — это пародия на мотивацию.
• Схема мотивации должна быть проста и понятна каждому сотруднику ИТ-департамента. Пять-шесть параметров, которые используются для расчета премий специалистов, можно считать пределом.

Шаг второй. Обучение

Для того чтобы служба Service Desk начала работать эффективно, недостаточно одной, пусть даже идеальной схемы мотивации сотрудников. Весь штат ИТ-департамента должен знать, а еще лучше — понимать, зачем нужен Service Desk, что такое управление инцидентами и т. д. Для этого необходимо обучить всех сотрудников ИТ-департамента основам ITIL. Затраты при этом будут неизбежны.

Нежелательно обучать специалистов самостоятельно, так как цена неверно понятого описания процесса или термина может оказаться слишком высокой. Наибольший эффект достигается при обучении сотрудников ИТ-отдела профессиональными тренерами. Можно совместить приятное с полезным. К примеру: проведите обучение в выходной день за городом. В этом случае бизнес не останется без поддержки в рабочие дни, а все сотрудники ИТ-департамента приобретут не только полезные знания, но и хорошее настроение. Отказавшись от обучения персонала основам ITIL, можно столкнуться с большой проблемой — саботажем. Выбираться из этой ситуации окажется дороже, чем заранее предотвратить ее, проведя обучение специалистов.

После того как все сотрудники прошли тренинг по основам ITIL/ITSM, следует ознакомить их с регламентами, которые уже составлены. И никак не раньше. Уже с обученными сотрудниками (или с некоторыми из них) можно и нужно проконсультироваться, узнать их мнение, выслушать предложения. Здесь может произойти первая корректировка процесса приема и обработки обращений пользователей.

Шаг третий. Организация call-центра

«Что может быть проще! — скажете вы. — Берем стол, стул, компьютер, телефон, принимаем на работу девушку с приятным голосом. И вот call-центр готов». Однако не все так просто. Существует как минимум два вопроса, которым требуется уделить особое внимание: какими качествами должен обладать оператор и где расположить его рабочее место.

Приятный голос — это далеко не самое главное, чем должен обладать человек, работающий на первой линии поддержки Service Desk. Стрессоустойчивость гораздо важнее для оператора, который в течение одного рабочего дня может несколько десятков раз слышать одну и ту же фразу: «У меня не работает компьютер!» — и при этом обязан всегда одинаково невозмутимо и доброжелательно выяснять у пользователя, что же действительно сломалось. Кроме того, сотрудник первой линии поддержки должен хорошо владеть русским языком. Грубые грамматические и синтаксические ошибки, допущенные оператором при регистрации обращения пользователя, могут неблагоприятно отразиться на понимании сути заявки другими специалистами. Наконец, оператор call-центра должен обладать общими ИТ-знаниями. Комментарии здесь излишни. Очевидно, что оператор, услышав слово «винчестер», должен представлять себе устройство долговременного хранения информации, а не огнестрельное оружие.

Практика показывает, что нахождение первой и третьей линий поддержки в одном помещении крайне негативно сказывается на результатах работы высококвалифицированных специалистов. Резко снижается эффективность системных администраторов. Количество ошибок в программном коде у программистов возрастает в несколько раз! Этот факт обусловлен тем, что сотрудники, работающие на третьей линии поддержки, решают, как правило, нетривиальные задачи, требующие высокой степени сосредоточенности. А как можно сосредоточиться, если рядом каждые десять минут звонит телефон, и оператор отвечает: «Добрый день, отдел ИТ слушает»?

Совсем другая обстановка возникает, если расположить рабочее место оператора call-центра рядом с рабочими местами сотрудников второй линии поддержки. Решение задач второй линии поддержки не требует особой сосредоточенности и, следовательно, общение оператора с пользователями не будет сильно их отвлекать. В то же время тесное общение специалистов первой линии поддержки с сотрудниками второй линии может дать положительные результаты: через некоторое время часть проблем, которые ранее решались на второй линии, смогут устраняться уже на первой. Этим можно улучшить один из главных показателей эффективности Service Desk — сократить среднее время решения проблем.

Шаг четвертый

Когда принципы функционирования службы Service Desk описаны (подготовлена документация), сотрудники знают и понимают основы ITIL/ITSM и определено рабочее место операторов call-центра, стоит задуматься об инструментарии. Для того чтобы контролировать процесс приема и обработки обращений пользователей, необходимо специализированное программное обеспечение. Наиболее распространенным инструментом сегодня является HP OpenView ServiceDesk. Но многие компании не имеют средств на приобретение такого программного обеспечения, да и нужен ли на стартовом этапе инструмент такого высокого уровня? Скорее всего, нет, так как сначала требуется наладить сам процесс приема и обработки обращений пользователей.

Если в штате ИТ-департамента есть хотя бы один программист, то задача построения собственной системы приема и обработки обращений пользователей решается сама собой. Любой программист менее чем за месяц может создать базу данных и подготовить генерацию стандартных отчетов. Если же программиста нет, то можно пойти еще более простым путем: достаточно зайти на сайт http://www.helpdesk.com, где хранится огромный список ссылок на различного рода программное обеспечение для поддержки служб Help Desk, Service Desk и call-центров. Потратив немного времени, можно найти бесплатный и вполне достаточный по набору функций инструментарий. Если и этот вариант не устраивает по каким-либо причинам, то можно, наконец, использовать «подручные» средства — Microsoft Excel и Access. Потратив несколько часов рабочего времени, можно создать свой собственный уникальный инструмент для службы Service Desk.

Первые результаты

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

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

Можно выделить две основные проблемы, с которыми придется столкнуться в первое время работы службы Service Desk. Первая заключается в том, что большинство пользователей в первые месяцы будут продолжать «по старинке» звонить системным администраторам, программистам и т. д. Но если система мотивации сотрудников ИТ была выстроена достаточно грамотно и был проведен тренинг по основам ITIL, то об этом можно не беспокоиться. ИТ-руководитель не будет тратить массу своего времени на разъяснительные беседы с пользователями о полезности службы Service Desk. Системный администратор, которому в очередной раз позвонит пользователь, сам объяснит, куда и к кому надо обращаться с вопросами. Причем он найдет такие аргументы, о которых ни один ИТ-менеджер даже не догадывается. Такой путь — приучить пользователей звонить по одному определенному номеру —максимально эффективен.

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

Вторая проблема, с которой придется столкнуться, — увеличение среднего времени обработки одного инцидента. Это плата за те статистические данные по обращениям, которые получит менеджер уже после первого месяца работы службы Service Desk. Увеличение времени решения инцидента, безусловно, будет заметно для пользователей, и именно с этим будут связаны основные негативные эмоции сотрудников предприятия. Ничего особенного в этом нет: служба только-только начала работать, процесс управления инцидентами еще слабо настроен, и сотрудники ИТ не привыкли действовать по новой схеме. Но уже через месяц после запуска Service Desk можно получить данные, из анализа которых видно, где в процессе слабое место, что и как нужно исправить, кто мешает нормальному ходу процесса. Начнется бесконечная настройка и модернизация службы Service Desk. В зависимости от скорости реагирования на выявленные проблемы и неточности в функционировании службы будет сокращаться среднее время решения инцидентов, повышаться удовлетворенность пользователей и т. д.

Пути развития

После того как служба Service Desk начала стабильно работать и прошел период адаптации, после того как улягутся первые страсти пользователей, можно задуматься о том, в каком направлении развиваться дальше. Путей много. Самым очевидным из них является повышение компетенции первой линии поддержки. Сразу после запуска службы первая линия (операторы call-центра) сможет закрывать максимум 20-30% всех регистрируемых инцидентов. Этот результат весьма хорош. Но совершенству нет предела. Развивая компетенцию операторов, обучая их, добавляя им дополнительные права и обязанности, можно повысить процент инцидентов, закрываемых на первой линии поддержки. В этом случае специалисты второй и третьей линий в большей степени смогут посвятить себя сложным и нетривиальным задачам. Второй эффект от увеличения числа инцидентов, закрываемых операторами, проявится в большей удовлетворенности пользователей работой департамента ИТ: та часть вопросов, которая ранее решалась, к примеру, в течение двух-трех часов (время реакции второй линии поддержки), теперь будет решаться за 10-20 минут.

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

Без рисков не обойтись

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

Денис Бобров, заместитель руководителя ИТ-департамента ЗАО «Талосто», Bobrov_DA@talosto.ru

Большинство трудящихся, которые работают на предприятиях в курсе того, что вышестоящего руководства не интересуют какими способами будут решены поставленные задачи. То есть имеется цель и ее нужно достичь, при этом не важно имеются ли у Вас для этого необходимы вспомогательные инструменты. В связи с этим приходится прибегать к решениям, которые прямо не специализированы для выполнения поставленной задачи. Что в свою очередь не гарантирует получение ожидаемых результатов. Подобные ситуации случаются абсолютно в каждых отраслях, но сегодня речь пойдет об ИТ. Руководство, зачастую всеми путями отнекивается от приобретения необходимого софта, апеллируя кусающейся ценной. Следовательно, в таком случае, если Вы являетесь высоко квалифицированным специалистом в программировании, то можно попытаться написать свое решение. Но если разбираться, то так ли выгодно создание, например, Service Desk с нуля или же покупка стороннего ПО выглядит куда целесообразнее. Разберем минусы и плюсы Service Desk системы, которая написана самостоятельно.

Тикет-система вручную. Основные плюсы

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

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

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

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

Свобода выбора. Под этим пунктом подразумевается полная свобода мысли при разработке программного обеспечения. Также учет потребностей и особенностей, как организации, так сотрудников, которые будут использовать разрабатываемый Service Desk. Возможно выбор будет сделан в сторону веб разработки или в сторону десктопа, это зависит от личных предпочтений. К этому же относится и выбор технологий с помощью, которых будет разрабатываться программа. Другими словами, разработчик является свободным художником и не ограничен в своих фантазиях.

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

Service Desk своими руками. Список минусов.

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

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

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

Разворачивание сред разработки. Придется развернуть среду разработки, а также механизмы контролирующие версии и так далее. Все это несет за собой дополнительные расходы, чтобы поддерживать собственную структуру ИТ.

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

Дорогостоящая разработка. Это связано с многоплатформенностью разрабатываемой программы. Что в свою очередь требует высокой квалификации состава программистов, которые смогут осилить разработку, как мобильной вариации решения, так и десктопа на популярные операционные системы. А подобные специалисты как известно имеют высокий оклад труда.

Шаткая документация или ее полное отсутствие. Этот минус будет ощутим на этапе начала внедрения, если документация сырая или ее попросту нет, то тогда придется «убивать» уйму времени на личное консультирование каждого пользователя программы. А это также несет затраты, но уже временные.

Стоит ли писать Service Desk самостоятельно?

Подытоживая сегодняшнюю тему, хочется все-таки определиться с актуальностью самописного решения. Как видно минусов больше нежели плюсов, но при этом есть и свои положительные моменты. Да и соблазн создания собственного ПО под свое узкое назначение достаточно велик. Однако если трезво взглянуть на вещи, то целесообразно подыскать подходящий по ценовой политики и узкой специальности продукт. Тем более сегодня, когда рынок ИТ на столько огромен, что, потратив пару дней на поиски, можно без проблем отыскать то, что подходит под Ваши критерии (цена, область работы). Это убирает ряд минусов, которые рассмотрели выше и также упрощает процесс раздумываний по поводу разработки собственной программы. Да и в целом ускорит выполнение поставленных руководством задач. При этом плюсом ко всему будет получение регулярных обновлений и квалифицированной технической поддержки покупаемого продукта. Конечно, это субъективное мнение и итоговое принятие решения зависит от Вас.

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

Однако чтобы запустить работу service desk не обязательно на старте вникать во все детали бизнеса.

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

Определите цели поддержки

В начале любых изменений стоит задать себе вопрос «зачем?». А зачем нужна сервисная поддержка и службы service desk вашей компании? Какую задачу она должна решать?

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

Другой пример — вы хотите заключить больше абонентских договоров на сервисную поддержку.

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

Ответ на вопрос «зачем?» поможет правильно расставить приоритеты при запуске службы service desk.

Продумайте бизнес-процесс решения заявок

Клиентские обращения различаются по сложности.

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

Для распределения обращений между специалистами разной квалификации выделяют линии поддержки.

Первая линия — отвечает на звонки и иногда решает самые простые вопросы.

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

Объясните сотрудникам, в чем смысл нововведений

Новый формат работы и новую службу service desk со своими KPI вам, фактически, придется «продать» своим же сотрудникам.

Непонимание смысла происходящего зачастую приводит к саботажу.

Специалисты думают, что все это построено, чтобы их еще больше контролировать или сократить.

Развейте эти слухи.

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

Что учет коммуникаций исключит недопонимание и конфликтные ситуации с клиентом, поможет собрать статистику по типовым поломкам.

А анализ наиболее частых обращений поможет написать FAQ или базу знаний для клиента и установить реалистичные базовые сроки устранения неисправностей (SLA).

Любое нововведение необходимо объяснить так, чтобы сотрудники поняли и помогли на пути их внедрения.

Подключите несколько каналов обращений в service desk

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

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

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

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

Лучше всего при этом собирать информацию в одном месте (помогут профессионалные help desk или service desk системы), вне зависимости от используемого канала (обеспечить омниканальность), чтобы, например, первично клиент мог обратиться по телефону, а потом прислать дополнительную информацию через готового бота Telegram.

Задайте правила взаимодействия между линиями службы service desk

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

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

Продумайте, как сотрудники должны подтверждать, что обращение принято в работу (что оно не потерялось «по пути»). Особенно это важно для сотрудников «в полях», которые практически не бывают в офисе.

Конечно, подобные вопросы упростит наличие мобильного приложения выездного специалиста в системе автоматизации service desk.

Появление правил обмена информацией помогают автоматизировать работу с заявками.

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

Подобные системы (help desk) могут автоматически создавать заявки из электронных писем от клиентов, проставлять им нужный приоритет и назначать на специалистов в соответствии с заданной схемой маршрутизации.

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

Сформулируйте KPI службы service desk

Чтобы оценивать уже реализованные идеи и планировать дальнейшие улучшения работы сервисной службы, необходимо опираться на какие-то объективные данные — KPI.

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

Чаще всего в качестве критерия рассматриваются сроки решения заявок. Их можно контролировать как вручную, так и с помощью упомянутых выше инструментов автоматизации.

Настройте сбор обратной связи от клиентов

Усовершенствования в работе службы service desk нужны для того, чтобы повысить удовлетворенность клиентов.

Эту удовлетворенность нельзя оценивать по внутренним KPI (которые мы ввели на прошлом шаге). Лучше спрашивать самих клиентов.

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

Во многих инструментах автоматизации service desk эти возможности «зашиты» изначально.

Наполните базу знаний службы service desk

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

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

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

Выводы

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

Всем привет! Меня зовут Алексей Волков. Bместе с моим коллегой, разработчиком Александром Соловьевым (alsov), мы делаем внутренние веб-сервисы в DataLine. Этой осенью мы запустили свой сервисдеск на замену BMC Remedy. В посте расскажу, почему мы отказались от готового решения и сделали все сами.

Чем нам не угодил Remedy?

Remedy я начал заниматься практически сразу, как попал в DataLine. После неоднократных попыток допилить его под наши задачи мы решили сделать свой сервисдеск. Вот не очень короткий список причин, по которым мы решили отказаться от Remedy Action Request System от BMC:

Неудобный интерфейс. Чтобы зарегистрировать заявку, взять ее в работу и отметить ее разрешение, приходилось сделать 100500 кликов.

Интеграция с другими клиентскими интерфейсами и какие-либо доработки предполагали еще те танцы с бубном. ПО проприетарное, места для маневров почти не было. Единственной лазейкой были веб-сервисы, которые умели общаться с Remedy, но они были очень капризными и нестабильными. Какие-то вещи мы делали совсем вручную и топорно: помню, как настроили выгрузку отчетов по инцидентам с помощью селектов из базы.

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

Не хватало лицензий. Когда-то на заре DataLine мы купили 100 лицензий. С тех пор компания сильно выросла. Лицензии были конкурирующими. Все чаще возникали ситуации, когда инженеру приходилось ждать освобождения лицензии, чтобы начать делать свою работу. Собственно, это и стало последней каплей.

Фиксация всех действий по инциденту. Мы хотели, чтобы все, что касается технической поддержки наших клиентов, было отражено в сервисдеске. Remedy же фактически только регистрировал запросы. Вся настоящая работа по инциденту велась в почтовой переписке, по телефону, в курилке – где угодно, но не в Remedy. Особенно, если это была комплексная заявка и задействовала специалистов из нескольких отделов. Вопрос то решали, но следов этого в Remedy не оставалось. В результате инцидент был задокументирован фрагментами, а иногда и вовсе не отображался в Remedy. Контролировать, разбираться и анализировать что-либо было очень сложно.

Сервисдеск 2.0

Функции Remedy заменить было просто. Сверхзадача нового сервисдеска – затащить всю активность по технической поддержке в «одно окно»: контакты, рабочую переписку, документы. Мы хотели получить своего рода логирование всего, что происходит после того, как клиент отправляет заявку к нам на саппорт. Попутно мы хотели автоматизировать многие вещи, чтобы снизить нагрузку на первую линию поддержки и исключить по максимуму человеческий фактор.

Вот самые важные из тех функций, что мы реализовали в новом сервисдеске:

Передача инцидента. К нам часто приходят комплексные заявки, которые по цепочке выполняют специалисты разных отделов. Из самого простого – заявка на физический доступ к оборудованию в дата-центре. Сначала диспетчер выписывает пропуск, потом передает данные клиента и номер пропуска дежурному инженеру, который встречает и сопровождает клиента в дата-центре. Есть запросы, которые последовательно отрабатывают 5 отделов.

Для всех таких случаев в интерфейсе появилась отдельная кнопка «Передать».

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

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

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

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

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

Шаблоны инцидентов. Типовых запросов достаточно много. Чтобы не заполнять десятки раз на дню заявку на пропуск или уборку мусора, мы добавили возможность создавать шаблоны инцидентов. Нужно только нажать кнопку «Создать инцидент», и откроется предзаполненный шаблон с прописанным исполнителем, типом, приоритетом и статусом.

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

Аналитика. В Remedy не было встроенных средств аналитики, ничего нельзя было выгрузить штатными средствами. Здесь мы предусмотрели выгрузку всего и вся для последующего анализа. Например:

• количество запросов в сутки;
• скорость реагирования;
• просрочка запросов;
• типы запросов;
• загрузка по отделам;
• работа диспетчеров;
• частота и качество возникающих проблем в разрезе клиентов;
• разнообразные зависимости, например, скорости исполнения от типа запроса.

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

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

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

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

Внедрение

Во время опытной эксплуатации мы тестировали работу сервисдеска на внутренних заявках. Около месяца тренировались на отделах АХО, капитального строительства, производства и управления сервисом. Внешние заявки и заявки других отделов по-прежнему ходили через Remedy.

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

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

Пришлось добавить ручной труд – появилась Диспетчерская. Это чистилище для всех заявок, пришедших на support@dtln.ru. Оттуда диспетчеры вручную распределяют заявки по отделам.

На стороне клиента логика взаимодействия с техподдержкой осталась прежней, изменился только вид отбивок. В первые дни с ними было несколько накладок, во основном из-за некорректных контактных данных в справочниках. Так у одного из клиентов было 23 ответственных лица и на всех один общий email, типа info@. Сервисдеск послушно всех оповестил, выполнив за час дневную норму по входящим на этом почтовом ящике.

Что дальше?

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

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

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

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

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

***

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

Еще один профит нового сервисдеска – это гибкость. Мы уже сделали несколько кастомных решений для отдельных клиентов, чтобы проинтегрироваться с их внутренними сервисдесками или просто подстроиться под их производственные процессы. Раньше на это ушли бы месяцы и миллионы, а теперь все, что нужно, – это письмо своему разработчику и 1-2 недели в зависимости от сложности задачи.

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

Что такое Service Desk простыми словами

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

Смысл существования Service Desk состоит в том, чтобы оперативно устранять неполадки, о которых сообщают пользователи, и восстанавливать оптимальный уровень сервиса. К числу неполадок могут относиться:

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

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

Как работает Service Desk?

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

Работа Service Desk происходит по следующему алгоритму:

1. Пока диспетчер общается с клиентом лично, он старается получить как можно более исчерпывающую информацию, чтобы исключить необходимость в повторных звонках или переписке с целью уточнения.
2. Диспетчер направляет тикет сотруднику, чьей компетенции соответствует запрос.
3. При большом наплыве запросов диспетчер формирует приоритеты. Срочные проблемы решаются в первую очередь.
4. Диспетчер доводит до клиента ответ на его запрос (например, высылает инструкции для самостоятельной настройки устройства либо назначает дату визита мастера, который произведет ремонт).
5. Клиент выставляет оценку работе Service Desk.
6. Собранная информация анализируется. Компания делает из нее выводы, касающиеся своих продуктов либо услуг, а также качества обслуживания и взаимодействия различных подразделений организаций.
7. На основе сделанных выводов принимаются управленческие решения, продукты или услуги дорабатываются.

Service Desk выполняет роль буфера между техническими экспертами и пользователями.

Некоторые из инструментов Service Desk

Управление большим количеством инцидентов

Быстрый ответ

Омниканальность

Вся информация в одном месте

Повышение производительности сотрудников

Более эффективное управление клиентами

Преимущества внедрения Service Desk

Преимущества от появления Service Desk в компании дадут о себе знать в первые же дни. Сотрудники, для которых общение с клиентами не является приоритетом, вздохнут с облегчением, так как избавятся от двух головных болей:

1. Многие пользователи при диалоге с диспетчером нервничают или ругаются на организацию — их надо успокоить и настроить на конструктивный лад.
2. Другие клиенты не знают, как объяснить суть проблемы, так как им не хватает технических познаний. Диспетчер должен проявить сообразительность и догадаться, о чем идет речь.

Специалисты, избавленные от коммуникационных обязанностей, смогут сфокусироваться на своих непосредственных задачах. Их работа станет более эффективной, качество продуктов и услуг вырастет. Ресурсы компании будут расходоваться более экономично и рационально.

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

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

Как выбрать Service Desk

При выборе необходимо принимать во внимание следующие факторы:

1. Просчитать бюджет. Небольшие организации могут обходиться без Service Desk до тех пор, пока клиентских запросов не станет так много, что они начнут тормозить основную работу.
2. Определиться, через какие каналы связи вы намерены общаться с клиентами. Желательно ориентироваться не только на собственные предпочтения, но и узнать, какими способами связи чаще всего пользуется целевая аудитория компании.
3. Продумать формат отчетности. Речь идет о способах сбора и обработки той информации, на основе которой будут приниматься управленческие решения.
4. Понять, в какой степени для вас допустимо самообслуживание. Например, клиент пишет сообщение в лайв-чат, а там ему бот предлагает ответы на наиболее популярные вопросы — это самообслуживание. Второй вариант — пользователю сразу отвечает живой оператор.
5. Выяснить, сколько сотрудников должно быть в вашем Service Desk. Это зависит от масштабов организации, частоты клиентских обращений и того, сколько времени и сил в среднем приходится тратить на решение одного запроса.

Вероятно, на сайте вашей компании есть раздел «Часто задаваемые вопросы», «Справочник» или нечто аналогичное. Пользователям надо напоминать о его существовании до того, как они направят запрос в Service Desk — возможно, они смогут уладить свою проблему самостоятельно.

Service Desk и Help Desk — это одно и то же или нет?

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

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