Service desk что это простыми словами
Что такое service desk
Если коротко – это служба приема и обработки обращений пользователей. Чаще всего под понятием «Service Desk» понимают программное обеспечение, которое помогает службам поддержки обрабатывать заявки от клиентов или сотрудников внутри организации.
Внедрение в компании service desk системы позволяет перевести любые сервисные службы на новый уровень зрелости. В результате сервис деск может стать единой точкой для обращений по самым разным вопросам.
Не подключается wi-fi, не работает телефония, нужно установить ПО или отремонтировать компьютер – заявка улетает в ИТ. Оформить справку – в HR. Заказать карту – в финансовый отдел. Сломался стул – в АХО. Подписать договор – юристам.
Ежедневно в службе сервис деск могут регистрироваться сотни подобных обращений от пользователей.
Омниканальность сервис деска
Способы оставить заявку могут быть различными: телефон, специальный email, личный кабинет, форма или веб-чат на корпоративном сайте, мессенджеры, мобильное приложение.
Вне зависимости от выбранного канала пользователь получит единый уровень сервиса.
Чек-лист функций сервис деск
К базовым функциям, которые помогают организовать сервисное обслуживание через сервис деск, относятся:
Форматы сервис деск систем
Система Service Desk может быть установлена, как на собственные сервера компании, так и использоваться в виде облачного решения. Второй вариант подходит для небольших ИТ-служб, т.к. в этом случае создание службы сервис деск не требует выделения дорогостоящего аппаратного обеспечения и может быть реализовано в сжатые сроки.
Так же все чаще крупные компании смотрят на «облака» в виду их арендной модели распространения и соответствующей возможности переводить капитальные затраты в операционные.
Service Desk системы и их интеграция. Как автоматизировать процесс работы с подрядчиками и производителями?
Любой сложный «продукт» — будь то услуга или материальный объект — ориентирован на долгосрочное удовлетворение потребностей и запросов клиента. Соответственно, неотъемлемой частью работы с «продуктом» является получение обратной связи от потребителя и поддержание «продукта» в надлежащем качестве или с заданными характеристиками и параметрами.
В сервисном бизнесе, суть которого и есть предоставление сервисного или постпродажного обслуживания, залог успеха — быстрота и эффективность в решении проблем заказчика. Казалось бы, что тут нового: про организацию технической или сервисной поддержки написано много статей и книг. Однако в b2b обслуживании возникает множество подводных камней, которые практически не обсуждаются, в том числе, потому что для них нет устоявшихся практических решений. Один из таких «камней» — сложная цепочка взаимодействия, «подрядов» или «партнерства», которая возникает в рамках решения клиентских заявок. Чем больше в цепочке уровней, тем сложнее контролировать итоговое качество и скорость работ, что может не лучшим образом отразиться на конечном пользователе услуг.
Схемы взаимодействия с вендорами и подрядчиками
В настоящее время взаимодействие вендора, партнеров и клиентов в сфере постпродажного обслуживания и сервисной поддержки можно условно разделить на две схемы, исключая модель в которой доп.звеньев между заказчиком и исполнителем нет.
Схема 1. Вендорская поддержка с помощью партнеров
Схема используется в случае территориально-распределенной сети клиентов. В этом случае клиент напрямую обращается в техническую поддержку или службу Service Desk разработчика/производителя. Вендор «закрывает» часть вопросов на своём уровне, но в ситуации, когда требуется «физическое» присутствие у клиента привлекает для решения заявки партнеров.
Схему с партнерами вендоры используют не только в случаях необходимости «физического» присутствия. На рынке есть компании, модель работы которых предоставляет исключительно вендорскую поддержку, при этом своих штатных специалистов поддержки у компании нет. Ей дешевле/проще найти партнеров, которые будут обеспечивать эту поддержку, не имея прямого контакта с ЛПРами конечных клиентов. Далее, обычно с целью контроля качества выполненных работ, заявка возвращается к компании-вендору либо уже решенной, либо на доработку на более высокий уровень.
Схема 2. Сеть партнеров с привлечением вендора
Модель используется в случае необходимости присутствия «на местах» (например, для замены запчастей) или в случае постпроектного сопровождения (когда проекты внедрения также реализуют партнеры, и их же потом поддерживают). В рамках этой модели вендор «строит» партнерскую сеть, контракты поддержки конечные клиенты заключают с партнерами и, как следствие, обращения клиентов поступают к партнерам в их Service Desk системы. При этом в рамках поддержки остаются вопросы на «третьей линии», которые требуют привлечения разработчика: исправление багов в системе, замена по гарантии, выпуск патчей и т. д.
Усложненная схема. Привлечение подрядчиков для решения части вопросов
Обе из вышеназванных моделей оказания технической и сервисной поддержки (в большей степени — вторая из них) на практике «усложнены» несколькими уровнями субподрядчиков, субпартнеров (нам известно об историях с 3 и даже 4 уровнями субпартнерства) и т. д. Это бывает, например, в случае федеральной компании-заказчика, требующей присутствия в нескольких регионах или в ситуациях, когда партнерская сеть изначально выстроена по модели эксклюзивности работы в регионе.
Со временем такой партнер сталкивается с невозможностью самостоятельного эффективного обслуживания клиентов со всего региона, а так как клиенты «закреплены», выстраивает собственную сеть «субпартнеров». Привлекают подрядчиков и просто для оптимизации расходов и «перенаправления» заявок.
Недостатки существующих моделей
У каждой из описанных моделей есть свои плюсы и минусы. Например, 1 схема позволяет вендору не только контролировать все вопросы клиентов и гарантировать более высокое качество поддержки, но и получать информацию «от первого лица», а значит развивать продукт и реагировать на клиентские запросы более оперативно и точечно. Еще одним несомненным преимуществом является возможность оценивать качество работы партнеров и оперативно вносить в схему взаимодействия изменения (например, менять партнёров, которые не справляются с задачами поддержки).
С другой стороны — такая схема достаточно дорогая для вендора, потому что предполагает организацию собственной первой линии поддержки и большое количество лицензий в части автоматизации посредством Service Desk систем. Партнеры же, понимая, что в модели не получится вести допродажи, пытаются выторговать более финансово интересную схему. В противном случае итоговое качество страдает.
Вторая схема, наоборот, позволяет больше зарабатывать партнерам, включая апселлы. В этой схеме для вендора нет больших затрат на организацию техподдержки со своей стороны. Обратная сторона медали — сложно контролировать итоговое качество поддержки конечных клиентов. К тому же, на конкурентном рынке партнер легко «перетягивает» клиента на другие продукты. И, конечно, с точки зрения развития «продукта» нет прямой обратной связи.
Практика показывает, что вне зависимости от модели оказания технической поддержки, для конечного клиента почти всегда «виноват» оказывает производитель.
Помножив на автоматизацию или причем тут Service Desk системы
90%). А те, что используют для регистрации, учета и обработки заявок какие-то решения по автоматизации, никак друг с другом не интегрированы.
Получается парадоксальная ситуация: в любой из схем нужно автоматизировать сквозной процесс обработки клиентских заявок, но системы поддержки клиентов партнеров, субпартнеров и вендоров (если они существуют) на практике никак не связаны между собой (изредка посредством той же email пересылки). В редких случаях партнеры или подрядчики работают в системе заказчика или вендора. Это только добавляет проблем обеим сторонам, потому что приводит либо к избыточному лицензированию, либо «заставляет» работать подрядчика в отличающихся системах разных вендоров/ генподрядчиков (да, на рынке почти любая сервисная компания является одновременно партнером нескольких вендоров или более крупных сервисных компаний).
Итогом исторически сложившихся схем работы и единого решения описанных проблем в обеих схемах сотрудничества компании неизбежно сталкиваются с рядом издержек, например:
Выход из ситуации
Несомненно, выходом из сложившейся ситуации могла стать интеграция Service Desk систем всех задействованных сторон. Интеграция позволила бы решить все вышеобозначенные проблемы при работе в обеих схемах, включая усложненную. Но, как мы говорили, на практике лишь немногие компании используют какие-то готовые решения. А с другой стороны на рынке не было инструментов, позволяющих обеспечить “сквозную” интеграцию разных систем в части передачи заявок и совместной работы по ним ввиду сложности и дороговизны реализации такой схемы.
Учитывая лавинообразный ком подобных ситуаций, с которыми мы стали сталкиваться на ежедневной основе при разработке Help Desk системы для автоматизации всех процессов постпродажного и сервисного обслуживания, в купе с количеством сервисных компаний и производителей, которые уже использовали Okdesk в своей ежедневной работе (на сегодня
500) мы предложили рынку выход – готовая интеграция между аккаунтами Help Desk систем.
Решение позволяет в пару кликов связать два или более аккаунта Okdesk с целью совместной работы по заявке. После этого для решения клиентского тикета можно привлекать не только “лицензированных” сотрудников, но и связанные аккаунты (и это не потребует доп.лицензии). На практике это в очень упрощенном виде работает следующим образом:
А что с интеграцией с Service Desk системами крупных компаний?
Готовая интеграция между Okdesk системами, конечно, хорошо. Но что делать, если заказчик это крупная компания (условный Сбербанк, X5 Retail Group и т.д.)? В такой ситуации вас вынуждают работать в очень ограниченном режиме в системе заказчика или отправляют вам тикеты по email.
В Okdesk давно решен и этот вопрос. С подавляющим большинством крупных распределенных федеральных компаний у нас есть готовые шаблонные интеграции, которые мы подключаем или дорабатываем по просьбе!
От теории к реальным сценариям и практике
В настоящий момент подобная модель используется в нескольких отраслях (как в варианте «вендор» — «партнёр», так и в варианте «заказчик» — «подрядчик»): HORECA, обслуживание контрольно-кассовой техники, ИТ-аутсорсинг. Анализ реакции пользователей показывает, что в среднем интегрированные решения позволяют добиться сокращения времени на решение заявок до 40%, а количества негативных отзывов со стороны клиентов — примерно на 20%.
Зачем внедрять HelpDesk в компании
Общая эффективность продукта зависит от эффективности каждого ее элемента. Когда у клиента возникает проблема, за решением он обращается к техподдержке… и здесь начинается коммуникация с HelpDesk.
HelpDesk (Service Desk) — система, предназначенная для автоматизации обработки запросов клиентов.
Благодаря HelpDesk можно подсчитать количество обращений в службу поддержки, частоту поломок техники и определить уровень предоставления услуги. Используя полученную информацию, можно спланировать развитие IT инфраструктуры, квалифицировать специалистов и выявить слабые места в компании. Таким образом, HelpDesk позволяют заявкам пользователей оперативно поступать в работу, а руководство получает возможность лучше контролировать работу менеджеров и эффективность работу IT отдела.
Служба техподдержки организована следующим многоуровневым образом:
. и обращается в службу поддержки с просьбой ее решить. На своем, пользовательском.
Многие популярные HelpDesk’и по умолчанию доступна на 3 языках: русский, английский и украинский. Некоторые сервисы также позволяют администраторам добавлять необходимый язык – создав нужный перевод.
Для каждой заявки выбираются исполнители в соответствии с департаментом, в который поступила заявка. Исполнитель может назначить заявку сам на себя, либо это может сделать ответственный менеджер. Все назначения и действия отобразятся в аудите заявки. После этого заявка будет закреплена за определённым исполнителем и будет отображаться у него в соответствующем списке задач.
Открыто – заявка открыта и принята в обработку. В процессе – заявка обрабатывается в данный момент, ведётся работа. Выполнена – заявка выполнена и решена Обратная связь — самая важная часть работы HelpDesk, и ее обязаны предоставлять своевременно. К примеру, пользователи могут жаловаться на медленную загрузку сервиса, плохой UI и то, что частенько ответы на запросы не отправляются.
Поддержка клиентов должна работать в формате 24/7, согласны?
Для этих целей существуют приложения для Android и iOS. По сравнению с полной версией HelpDesk/ServiceDesk системы, мобильное приложение имеет ограниченный функционал, но позволяет полноценно осуществлять удалённую поддержку клиентов. Где бы вы ни были, вы всегда будете в курсе запросов клиентов, сможете на них реагировать. Также в фоновом режиме приложение всегда вас уведомит о важных событиях связанных с заявками.
Внедрение Service Desk и HelpDesk выгодно для всех – собственников бизнеса, менеджеров компании, ИТ подразделений и непосредственных потребителей.
Все заявки будут приходить в одну систему и далее регистрироваться и обрабатываться Вашими специалистами в едином формате. Вы можете подключить разные отделы своей компании к полученным заявкам, разделив права доступа по конкретным сотрудникам. Руководство всегда сможет увидеть всю историю обращений каждого клиента и выгрузить нужные отчеты для оценки эффективности работы персонала.
Подобные сервисы устраняют проблемы, которые связаны с медленной реакцией IT служб на запросы. Также повышается качество услуг организаций, которые имеют несколько офисов и подразделений в разных регионах. Соответственно, улучшается безопасность IT инфраструктуры компаний, уменьшаются затраты и появляется возможность их прогнозировать.
Для пользователей внедрение Service Desk и Help Desk характеризуется повышением уровня предоставляемого сервиса и уменьшением периодов остановок из-за проблем в IT инфраструктуре. А для самих IT служб внeдрение подобнoй oрганизации рабoты становится решением прoблемы, когда бизнес не может понять запросов айтишников. Появляется возмoжность просто обoснoвывать влoжения в IT и планировать бюджет согласно потребностям в развитии бизнес-процессoв. Кроме тoго, IT департамeнт может предoставлять актуальные и достоверные данные о свoей рабoте и пoвышать дoступность своих услуг для пользователей.
Внедрение Service Desk и Help Desk также позволяет квалифицировать специалистов IT подразделений и развивать у них определенные навыки.
В первую очередь необходимо сформулировать требoвания к системе. Определите, нужна ли будет в дальнейшем пoддержка процессов ITIL вашей системой. Задумайтесь о дальнейшей автоматизации службы поддержки. Определите параметры масштабирования системы, котoрые будут изменяться по мере роста ваших потребностей.
Большую часть работ по подготовке к внедрению нужно провести до выбора системы. Если сделать наоборот, то в дальнейшем вам придется приспосабливать свои бизнес-процессы под возможности выбранной системы. Это означает, что вы будете вынуждены исхoдить из oграничений, а не возможностей, что не решит ваших прoблем, а мoжет лишь усугубить их.
Для того, чтобы определиться с выбором HelpDesk было легче, предлагаем сравнительную таблицу популярных сервисов:
Зачем внедрять Service Desk и как выбрать решение для вашей компании
Расскажем, зачем нужен Service Desk и на что обратить внимание при выборе программного обеспечения и вендора.
Service Desk — программный инструмент, позволяющий специалистам быстро реагировать на инциденты и запросы пользователей. Решения Service Desk отличаются по функциональности, модели лицензирования, сложности адаптации и развития, и все они упрощают процесс приема и обработки обращений.
Не всем компаниям нужно внедрять Service Desk. В нем нет смысла, если в организации трудятся 100 человек и для технического обслуживания хватает 2–3 посменных ИТ-специалистов, которые работают в одном помещении с пользователями и могут физически устранять аварии. Компаниям, где количество сотрудников превышает 150 человек, внедрить Service Desk крайне желательно.
Что Service Desk дает вашей компании
Service Desk наладит работу с сервисными запросами, станет инструментом для анализа поведенческих и результативных метрик персонала.
Благодаря Service Desk руководители:
Собирают статистику по кадрам: сколько раз, по какой причине они обращаются в ИТ-подразделение. Если заявки в Service Desk частые и связаны с незнанием принципов работы на ПК, начальнику стоит задуматься об обучении персонала.
Собирают статистику отказов оборудования и решают вопрос о его обновлении.
Оценивают качество работы ИТ-специалистов: как они реагируют на заявки, имеют ли в арсенале инструмент для предупреждения и устранения инцидентов и пр.
Планируют развитие инфраструктуры ИТ-подразделения, чтобы поддерживать работу с растущими объемами данных.
Техническая служба Service Desk:
Уменьшает нагрузку на ИТ-специалистов — появляется система, в которой они управляют жизненным циклом каждого запроса и сохраняют варианты решения проблемы для последующих обращений к ним.
Снижает число запросов в ИТ при массовом отказе сервисов или профилактике. Это возможно благодаря уведомлениям ПО о технических проблемах и сроках их устранения.
Позволяет быстро фиксировать, квалифицировать заявки и не терять их, так как заявки поступают с удобных каналов: мессенджеров, по почте, телефону.
Если в ваших организационных процессах царит хаос, ПО не поможет: автоматизация отлаженных процессов повышает их эффективность – и наоборот – автоматизация хаоса увеличивает беспорядок. Выбирать решение нужно после того, как наведете порядок в компании.
Как выбрать решение Service Desk для компании
Чтобы выбрать вариант программного обеспечения для Service Desk, нужно проанализировать цели и задачи бизнеса, понять схему автоматизации существующих процессов. Скорее всего, «натащить» готовое решение на свои требования не получится, ведь Service Desk состоит не только из софта. Большое значение имеет квалификация ИТ-персонала, подход к работе и порядок в организационных процессах. Если все в норме, значит, вы готовы к внедрению Service Desk.
Рассмотрим 5 шагов по выбору ПО.
Шаг 1. Оцените уровень совокупного владения системой Service Desk
Разберитесь, во сколько обойдется внедрение и обслуживание Service Desk. От верной оценки бюджета зависит прогнозирование финансовой деятельности компании в целом. Расходы складываются из:
Шаг 2. Узнайте мнение команды
Кажется, проще передать задачу по внедрению Service Desk в ИТ-подразделение. Но это решение ошибочное. Лучше взглянуть на процессы в компании со стороны и нанять внешнего консультанта. Он учтет общие цели бизнеса и подберет наилучшее решение.
Перед тем, как пригласить специалиста в компанию, расспросите ИТ-сотрудников, что они думают об изменениях, какие функции автоматизации нужны компании, внутренним пользователям и лично им. Уточните рекомендации по конкретным решениям и поставщикам. Эта информация поможет консультанту сформировать предложение из нескольких вариантов ПО.
Если организация крупная, создайте команду проекта и назначьте ответственного за его реализацию. Делегируйте ему полномочия для принятия решений, в том числе непопулярных.
Шаг 3. Ознакомьтесь с моделями лицензирования ПО
Чтобы пользоваться ПО Service Desk, приобретите единую серверную лицензию и именные лицензии для ИТ-сотрудников. Именные лицензии рассчитаны на каждого специалиста. Если требуется высвободить одну из именных лицензий, в системе блокируется сотрудник, на освободившееся место добавляется новый.
Подключение конечных пользователей к системе Service Desk чаще всего не лицензируется.
Шаг 4. Изучите ПО с нужной функциональностью
Вернемся к списку требований к ПО. У каждой компании они свои, однако можно выделить общие:
Шаг 5. Выберите вендора и внедрите Service Desk
Оцените уровень зрелости нескольких вендоров и остановитесь на 2–3. Сформируйте запрос на предложение, дождитесь ответов и проанализируйте информацию от кандидатов.
Благодаря комплексному подходу к выбору ПО, вы найдете и внедрите именно ту систему, которая улучшит поддержку пользователей и одновременно сократит затраты на их обслуживание. Удачи!
«На чужих ошибках»: что нужно знать для успешного внедрения Service Desk
Одним из столпов ITIL является Service Desk, единая точка контакта между пользователем и поставщиком услуг. В диспетчерскую службу Service Desk клиенты обращаются при возникновении инцидентов или проблем и вопросов, связанных с предоставляемой услугой. Служба регистрирует, отслеживает и управляет решением проблем, которые были доведены до ее сведения.
За долгую историю ITIL службу Service Desk внедрило множество компаний. Кто-то полагался на готовые инструменты, кто-то шел своим путем. У кого-то получилось с первого раза, а кто-то «набивал шишки». Опыт последних помог нам сформировать список самых распространенных ошибок при внедрении Service Desk — от банальных и легко устраняемых до вполне серьезных — которым мы и делимся в этой статье.
1. Изолированное внедрение
Линда Киркпатрик (Linda Kirkpatrick), старший консультант по управлению ИТ-услугами Flycast Partners, работавшая более чем с 300 различными компаниями, утверждает, что многие клиенты были попросту не готовы к внедрению инструментов ITSM. Или, ее словами, — «если бы мне давали четверть доллара каждый раз, когда я начинала работать с компанией, не готовой к внедрению ITSM, сейчас я сама могла бы нанять себе старшего консультанта по управлению ИТ-услугами».
Компании хотят, чтобы сторонний партнер внедрил Service Desk отдельно от других процессов. В результате организации получают подход, который противоречит ITIL, — вместо акцента на сервисе появляются разрозненные службы, совершающие несогласованные действия.
Решение. Важно работать в тесном контакте с поставщиками ITSM-инструментов и иметь целостное представление о происходящем в организации. Внедрение Service Desk должно стать не самоцелью, а частью плана непрерывного улучшения обслуживания. Для этого проектная команда должна работать вместе с сотрудниками компании, а они, в свою очередь, должны не только разбираться в новых политиках и инструментах, но и понимать, как устроен весь процесс оказания услуги. Так развитие всех служб будет двигаться по единому курсу, что обеспечит синергетический эффект и слаженную работу инструментов.
2. Трата времени на «войну с сотрудниками»
Внедрение Service Desk приводит к большим изменениям в организации с точки зрения культуры работы. Эти изменения персонал не всегда принимает безболезненно. Принципы ITIL, подразумевающие сервисный подход, понятны не всем. Подтверждением тому служит дискуссия на Reddit, в которой руководитель службы Help Desk жаловался на своих подчиненных: у них нет стремления учиться, проявлять инициативу и просить советов.
Переход к профессиональной системе Service Desk может вызвать скептицизм со стороны сотрудников. Так случилось у организаторов мероприятия EuroJam — волонтеры из службы поддержки не хотели пользоваться новым инструментом.
Есть несколько методов реакции на сопротивление сотрудников в такой ситуации: например, игнорирование, насильное внедрение или же убеждение подчиненных в пользе Service Desk. Первые два метода, как правило, не дают положительных результатов — технически Service Desk будет внедрен, но фактически люди продолжат сопротивляться нововведению. Если мнение сотрудников не учитывается, слаженной работы не получится.
В случае с EuroJam решить проблему помогло то, что нововведения внедрялись постепенно и с учетом особенностей мероприятия — руководство не требовало выстраивать весь процесс «идеально». Это же позволило упростить процесс внедрения — если представить изменение в виде нескольких несложных шагов и адаптировать их под особенности организации, шанс на успешное завершение процесса будет намного выше. Например, волонтеры EuroJam по завершении мероприятия стали буквально «евангелистами Service Desk».
Решение. Сотрудники не принимают новое, потому что не видят в нем ценность для себя. Важно объяснить, как новая служба поддержки улучшит результаты их работы. Следует указать на существующие проблемы и продемонстрировать, как Service Desk решит их и облегчит жизнь всей команды.
3. Неравномерная нагрузка на сотрудников
Управление инцидентами напрямую зависит от системы тикетов. Основная задача тикетов — управление всеми входящими запросами. Поскольку ИТ-отделы, как правило, имеют дело с большим количеством запросов, им требуется система для управления жизненным циклом каждого отдельного запроса — от формирования до разрешения. Эффективная система тикетов позволяет своевременно решать все проблемы. Она также облегчает работу отделов, так как вся информация сохраняется в едином центре для последующего использования.
Что бывает, когда система тикетов выстроена недостаточно основательно, демонстрирует опыт компании Warfare Plugins, разработчика плагинов для WordPress. Компания завела систему управления инцидентами, в которую направлялись вопросы пользователей. Простые запросы могли обслуживать все члены команды, а за сложные отвечал только один человек.
Однажды ему пришлось отлучиться на некоторое время. По возвращении он обнаружил огромное количество скопившихся тикетов. В итоге сотрудник потратил месяц на исправление ситуации. Это сказалось на среднем показателе обработки одного запроса и косвенно — на качестве продукта: тикеты указывали на недостатки плагинов, которые следовало устранить.
/ Wikimedia / Axel Boldt / CC
Решение. Разобрав почтовый ящик, команда ввела новое правило — разрешение любой проблемы в течение часа или двух даже в выходные дни. Это может показаться банальным, но еще на этапе внедрения следует устанавливать четкие KPI, среди которых обязательно должно быть время обработки тикета. Также следует выстроить грамотное распределение запросов между компетентными сотрудниками таким образом, чтобы разрешение инцидента не зависело от одного человека, и объем рабочей нагрузки соответствовал возможностям отделов.
4. Отсутствие логики в распределении полномочий
ITIL предполагает, что у каждой команды и отдельного сотрудника в сервисно-ориентированной системе есть понятный набор обязанностей и полномочий. На этапе внедрения Service Desk важно грамотно распределять ответственные роли. ITSM позволяет комбинировать роли и зоны ответственности, но важно учитывать и компетенции сотрудников.
О важности этого, также довольно очевидного, нюанса пишут, например, исследователи из Университета Канадзава (Япония), которые совместно с китайскими коллегами из Shanghai Wicresoft изучали вопросы внедрения Service Desk в азиатских компаниях. Они приводят кейс одной из китайских организаций, где до полноценного внедрения Service Desk применялся собственный прототип системы управления инцидентами.
Непонимание компетенций и зон ответственности привело к тому, что простые запросы служба поддержи направляла квалифицированным инженерам. Проблема состояла в том, что на решение «дешевых» и «простых» вопросов тратилось время «дорогих» специалистов, которым приходилось отрываться от своих профильных обязанностей.
Решение повлекло за собой не только высвобождение времени у профильных специалистов, но и повышение других сопутствующих показателей: удовлетворенность VIP-клиентов (которыми должны были заниматься более квалифицированные сотрудники) возросла с 60 до 90%, в несколько раз более эффективно стала использоваться база знаний, сократилось время обработки запроса. Вот только на восстановление порядка из хаоса пришлось привлечь дополнительные силы, а весь процесс «реструктуризации Service Desk» занял полгода.
Решение. Введение автоматической сортировки запросов по сложности и направленности на этапе внедрения решает проблему загруженности команд. Автоматизированные инструменты мониторинга гарантируют, что все запросы будут обработаны — вне зависимости от сложности. А создание базы знаний помогает накапливать ответы на технические вопросы для того, чтобы сотрудники могли разрешать простые проблемы в штатном режиме, даже если необходимого специалиста нет на рабочем месте.
Конечно, это не все проблемы, с которыми сталкиваются компании при внедрении Service Desk. Однако они относятся к наиболее «популярным» и влекут за собой дальнейшие сложности. Поэтому здесь как никогда актуальна возможность «учиться на чужих ошибках» и заранее предусмотреть подобные варианты развития событий.
Дополнительные источники по теме из нашего корпоративного блога: