История создания службы поддержки, или "Почему лучшие практики не работают?"

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

Кратко о компании

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

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

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

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

Если говорить о компании, в которой я работаю, то эти причины и обоснования появились не сразу:

• в 2004 году в компании всего работало 7 человек и только один из них занимался всем ИТ;
• с 2004 по 2009 компания расширялась и был создан Отдел автоматизации, в котором уже было около 10 ИТ-сотрудников;
• к лету 2017 численность сотрудников ИТ увеличилась, и как раз в июне была создана служба технической поддержки;
• в 2019 в ИТ работает уже 50 сотрудников.

Это связано с тем, что компания растет, развивается, покупаются и строятся новые заводы, покупаются новые суда и, соответственно, усложняются ИТ-сервисы, усложняется их поддержка. Вместе с ростом компании растет численность сотрудников ИТ.

Первопричины создания службы поддержки

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

С 2009 по 2017 года в компании было два ИТ-подразделения:

1.  Направление информационных систем - разработчики;
2.  Отдел автоматизации - системные администраторы.

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

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

Это сотрудники, к которым обращались пользователи по любым ИТ-вопросам.

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

Такая схема организации работы приводила нас к ряду серьезных проблем. Давайте кратко рассмотрим эти проблемы:

• Отсутствие единого окна для обращений, нужно каждый раз понимать куда конкретно нужно обращаться, а если пользователь попадал не туда, то там его нескромно могли отправить в соседнее подразделение: «Ну так это 1С, позвоните разработчикам, это не наша ответственность».
• Конечно же, это футбол и «пинг-понг» обращений между подразделениями, что затягивает сроки решения обращений еще на входе.
• Обращения напрямую к экспертам. Банально, могли позвонить главному сетевому администратору и попросить поменять картридж в принтере. Это довольно-таки дорогая замена картриджа для компании.
• Отсутствие информирования сотрудника о статусе обращения. Пользователи были вынуждены перезванивать после подачи обращения по нескольку раз и уточнять: «А мое обращение вообще решают?».
• Отсутствие нормативных сроков по решению обращений. Так как сроков нет, то исполнители были вправе решать обращения за любое время. Что приводило нас к небольшой локальной анархии.
• Отсутствие каталога услуг. Без каталога услуг, любой пользователь мог отправить любой запрос в ИТ, например, просьбу поменять лампочку в коридоре и искренне не понимать, почему его запрос не будет выполняться.
• Не определены KPI. Вроде бы все что-то делали, чем-то были заняты, но кроме количества обращений других показателей нет, нет своевременности, нет удовлетворенности. Не понятно как оценивать работу исполнителей, как оценивать их загруженность, как контролировать исполнительскую дисциплину.
• Отсутствие единой учетной системы. Каждое ИТ-подразделение складывало обращения в свою корзину, причем при таком подходе часть обращений, вообще, терялась и никем не регистрировалась. Эти проблемы требовали решения.

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

Создание единого ИТ-управления

Мы проанализировали эти проблемы и решили перестроить структуру всего ИТ.

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

Какие нужны ресурсы

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

Первое и самое главное это люди:

• которые будут работать в службе поддержки;
• которые будут писать регламенты;
• которые будет разрабатывать и предоставлять ИТ-услуги;
• которые настроят всю необходимую инфраструктуру;
• которые автоматизируют обработку обращений;
• которые будут всем этим пользоваться и давать обратную связь.

Второй ресурс это деньги. Деньги тратятся на:

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

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

Этот ресурс — методология. Давайте остановимся подробнее на этом ресурсе.

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

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

Какие процессы внедрять

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

Давайте кратко рассмотрим эти процессы и функции:

• Так как мы хотели решать все обращения пользователей, то для этого нам нужно было выделить отдельное функциональное подразделение, которое будет являться единым окном для всех обращений в ИТ. Нам нужно было регламентировать новое подразделения, выпустить приказ об организационных изменениях, завести кадровые ставки согласно новому штатному расписанию и сделать кучу других рутинных операций, но самое интересное было еще впереди. Перед организацией SD стоял ряд задач: а именно, как теперь заставить всю компанию обращаться только в единое окно, как наладить взаимодействие между ИТ-подразделениями и как собственно, вообще, все это будет работать на практике. Нужно было сломать традиции, которые годами формировались в компании. В нашем случае это было не просто создание очередного проходного сервис деска, это была организационная революция с жертвами, увольнениями, саботажем и интригами.
• Следующий процесс — это процесс управления инцидентами. Что такое инцидент? Инцидент – незапланированное прерывание или снижение качества ИТ-услуги. После того как мы создали службу и начали внедрять в компании сервисный подход, то нам нужно определить и регламентировать процесс управления инцидентами. В первую очередь нам нужно было начать регистрировать все обращения, которые нам присылали. Прям, вообще, все. Кстати, был забавный случай. К нам в службу обратился сотрудник, который находился в Китае на судне в ремонте, с просьбой позвонить его жене и сказать, что у него все в порядке и он скоро будет дома. Обратился к нам, так как единственный источник связи, который у него работал это была почта и он знал почтовый адрес службы поддержки и что мы работаем без выходных. Конечно мы выполнили это обращение как непрофильное. Но регистрация подобных обращений позволяет уточнить спрос на те или иные услуги, которые мы не предоставляем.
• Далее, управление запросами на обслуживание. Это процесс, ответственный за управление жизненным циклом всех запросов на обслуживание. Здесь речь про нормальную работу сервисов, про информирование и консультирование пользователей, про настройку ПО и прочие стандартные ИТ-запросы.
• Интересным опытом было составление списка услуг, которые мы предоставляли бизнесу. Нужно было распутать весь комок ИТ-услуг, расписать их доступность, определить время предоставления услуг, назначить ответственных, описать назначение, детали и зависимости всех услуг, определить правила эскалации и эксплуатации. По факту, мы составили меню из списка всех услуг, которые мы предоставляем. Каталог был автоматизирован и донесен до сотрудников. Для нас каталог услуг прежде всего является ориентиром при эскалации обращений и гарантом того, что мы можем отказать пользователю в предоставлении услуги, если она не определена в каталоге или оказать все же оказать непрофильную услугу, но без ограничений по времени. Т.е. сделать ее факультативно.
• Кроме каталога с высшим руководством компании были согласованы соглашения об уровне услуг. Были составлены SLA для разных групп пользователей, мы разделяем пользователей по географии. Например, сотрудникам на судах в море недоступна часть береговых услуг и наоборот на берегу не доступны услуги, которые предоставляются на судах. Например, спутниковая связь и телевидение. Также SLA определяет разное время предоставления услуг в зависимости от местоположения пользователей.
• Следующий процесс — это удовлетворенность. По результатам решения каждого обращения пользователям-авторам автоматически направляется запрос оценки удовлетворенности по пятибалльной шкале. Сбор оценок позволяет выявлять отклонения в процессе, проводить работу с исполнителями и повышать лояльность сотрудников компании, которые недовольны качеством предоставляемых ИТ-услуг. При этом по факту выставления негативных оценок запускается автоматический запрос на выяснение причин низкой оценки. Работа над обращениями с низкими и негативными оценками помогает улучшать сервисы и сохранять лояльность пользователей.

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

Что получилось

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

• пользователи обращаются в единую точку — к диспетчеру службы технической поддержки;
• диспетчер, который находится на 1й линии, регистрирует обращение, классифицирует его по сервису из каталога услуг, решает обращение, если не может решить обращение, то эскалирует его дальше или к консультантам бизнес-приложений, или к инженерам.
• далее обращение решается специалистами второй линии, если вторая линия также не может решить обращение, например, у них недостаточно прав, то обращение эскалируется дальше на третью линию.
• А на третьей линии уже находятся эксперты: это главные системные администраторы и разработчики, которые решают сложные обращения и обращения, которые требуют наличия полных прав.

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

Немного про метрики

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

Давайте рассмотрим своевременность. На слайде график своевременности обработки обращений пользователей и инцидентов и запросов на обслуживание. Это данные с августа 2017 года по август 2019. На графике видно пару интересных моментов. Например, снижение своевременности в марте-мае 2018, это связано с вовлечением всех сотрудников ИТ с разной степенью исполнительской дисциплины в единую среду обработки обращений. Отрицательный тренд показателя нас не устраивал и поэтому мы приняли меры по мотивации сотрудников. Одной из форм мотивации стало социальное соревнование среди сотрудников ИТ. Мы стали еженедельно рассылать индивидуальные показатели своевременности по всем сотрудникам ИТ. Никто не захотел быть аутсайдером в этой рассылке и вскоре мы выровняли своевременность до приемлемого уровня.

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

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

Что еще нужно

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

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

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

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

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

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

• наименование номинации и золотая звезда за первое место;
• наименование номинации и серебряная звезда за второе место;
• наименование номинации и бронзовая звезда за третье место.

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

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

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

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

Что делать после того, как служба запущена

Что делать после того как вы запустили службу технической поддержки? Обычно есть два основных варианта развития дальнейших событий:

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

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

Выводы

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

1.  Причины и обоснования — это цели создания службы, какие проблемы должна решать служба?
2.  Ресурсы: люди, деньги, время и методология. Причем методология остается на ваш выбор.
3.  Регламенты процессов. Без правил со временем начинается анархия.
4.  Измерение процессов. Нужно определить методики измерения ваших процессов и научиться анализировать результаты процессов.
5.  Автоматизация процессов. Идеально, когда вы можете автоматизировать часть рутинных операций и тем самым ускорить или как-то облегчить предоставление и получение ИТ-услуг.
6.  Реклама. Без маркетинга вам будет сложно продвигать ваши сервисы и службу в крупной компании.
7.  Планы на развитие и улучшения. Нельзя одномоментно создать идеальный сервис, бизнес постоянно растет и меняется, с ростом бизнеса вы также растете и изменяетесь. При этом вы всегда должны быть нацелены на улучшение предоставления сервисов.

Почему же лучшие практики не работают?

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

Спасибо за внимание. Буду рад ответить на ваши вопросы.

Вопросы

• Мы сейчас находимся на этапе постепенного перевода Service Desk на единую точку входа. Но столкнулись с проблемой, что хотя пользователям много раз говорили звонить на линию консультации, писать на единую почту. Но они все равно пытаются связываться с разработчиками напрямую и отправляют заявки на вторую и даже на третью линию поддержки. Как лучше решить такую проблему – кнутом или пряником? Пряник, допустим, пользователю, если он клиент не вашей фирмы, сделать какую-то скидку. Кнут – это когда программист не регистрирует заявку, не общается с пользователем, бросает трубку. Как лучше такую проблему решить?
• С этим нужно постоянно бороться. Мы не можем выпустить приказ и запретить обращаться на вторую или третью линию к экспертам, и разрешить только через единое окно. Мы можем, конечно, так сделать, но это сработает на неделю, на 10 дней. А потом все равно появится пользователь, который обратится напрямую. Есть радикальные методы, про которые я слышал, – вплоть до того, что у экспертов убирают телефоны, и к ним нельзя дозвониться. Но мы у себя просто ведем постоянную работу с руководителями линий, и уже они просят сотрудников не решать обращения. Если вдруг кто-то обратился мимо единого окна, то по правилам сотрудник перекидывает копию письма или запрос в службу поддержки. И уже мы это решаем, а не они. Конечно, есть какой-то процент случаев, но это незарегистрированные случаи, и, наверное, с ними невозможно бороться. Поэтому нами ведется постоянная работа с руководителями линий. Ведь когда все идет через первую линию, сотрудники в основном занимаются проектной деятельностью. Это выгодно руководителям линий – никто не хочет брать на себя много операционки, все хотят заниматься проектами. Поэтому необходима постоянная работа с руководителями, какого-то другого решения у меня нет.
• На чем у вас построен Service Desk?
• BPM’online Террасофт.
• Вы сказали, что в качестве идеологии выбрали ITIL, что исторически у вас каждая служба работала в своей учетной системе. Какие проблемы технического характера были по переводу всех в одну систему? Может, вы выгружали исторические данные или что-то еще?
• Нет, мы просто законсервировали эти системы. Но могу рассказать, что это были за системы. Первая из них есть до сих пор, но мы используем ее для других целей – это «1С: Документооборот». Все, кто ею пользовался, знает, что «1С: Документооборт» – это процессная среда, в нем можно построить все, что угодно, при минимальных затратах. В «1С: Документообороте» мы сделали обработку обращений для консультантов и для разработчиков 1С. А администраторы использовали Битрикс. Там есть модуль по задачам. Потом, когда мы переходили, мы просто законсервировали эти системы, и сейчас их используем исторически – смотрим, что было. Перенос писать не стали.
• Почему из всего многообразия систем вы выбрали именно BPM’online Террасофт?
• Нам нужно было, чтобы был запрос удовлетворенности, были определены процессы внесения изменений, процессы управления обращениями, управления проблемами, и мы смотрели около 5 решений. По всем критериям победил BPM’online. Там и мобильное приложение удобное. В сторону 1С продуктов (1С:ITIL, Итилиум) мы немного смотрели, но на тот момент, когда мы выбирали, эти решения показались нам довольно тяжелыми. Плюс там не было портала и мобильного приложения. Поэтому мы их не выбрали.
• Расскажите, какие внутренние метрики и показатели эффективности работы Service Desk вы используете в своей работе. Потому что иной раз премирование надо какое-то сделать сотрудникам. Какие показатели у вас влияют на премии?
• У нас в Service Desk премирование построено довольно сложно. Есть операционная и проектная часть. Операционная часть считается как раз по этим живым метрикам. Например, у диспетчера на первой линии есть метрика «Доля обращений, выполненных на первой линии». Также у всех диспетчеров есть командная метрика «Доля обращений, которые зарегистрированы вовремя». То есть у нас на каждое обращение дается определенное время – в течение часа нужно его зарегистрировать. Следующая метрика это «Своевременно решенное обращение», потом «Удовлетворенность». Все эти метрики суммируются, умножаются на определенный коэффициент и складываются с проектной частью. У нас любой сотрудник может заниматься еще проектной деятельностью, даже на первой линии. Это все складывается, и на основании этих показателей человек либо выходит на премию, либо не выходит.

****************

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019.