Введение

Термин Service Desk начал приживаться в стране ориентировочно в 2000–2001 году,

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

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

Т.е. мы говорим о структуре, отвечающей в первую очередь:

 за прием и регистрацию обращений пользователей по всем вопросам, связанным с ИТ;

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

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

пользователи, руководители ИТ-подразделений, ИТ-специалисты, и бизнес в целом:

1. пользователи получают понятный и удобный интерфейс к ИТ-службе

для получения помощи (не надо обзванивать десятки известных и неизвестных
телефонов специалистов и начальников в ИТ), звонки не теряются, можно
получить информацию о том, что делается по заявке;
2. их руководители получают повышение производительности труда в своем
подразделении. Также правильно организованный ServiceDesk позволяет
эффективно управлять качеством оказываемой поддержки, и гарантировать ее
высочайшее качество там, где это критично для бизнеса;
3. как отмечают многие ИТ-директора: «я перестал работать диспетчером
и справочной службы по совместительству», и это касается также ключевых ИТ-
специалистов. Руководители ИТ-служб получают объективную информацию
о потоке входящих обращений и качестве работы ИТ-систем, спокойны за качество
обслуживания пользователей. Копятся ценные данные о нагрузке и эффективности
ИТ-специалистов  — основа для подготовки внутренних нормативов и других
управленческих решений по оптимизации работы… Для руководителей ИТ-служб
создание Service Desk  — очень серьезный шаг в части реального управления своей
службой.

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

Построение Service Desk – типовая постановка задачи

Работа по созданию Service Desk подразумевает:

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

Следует отметить несколько принципиально важных моментов, которые должны быть

решены еще на стадии планирования создания Service Desk:

1. На уровнях директора по ИТ, руководителя эксплуатации, и куратора ИТ-службы

со стороны руководства должны быть согласованы приоритетные задачи создания
Service Desk. Концентрация на одной-двух приоритетных задачах из возможного
длинного списка (обеспечение удовлетворенности пользователей, накопление
статистики о загрузке ИТ-специалистов, повышение эффективности работ
по поддержке пользователей, обеспечение жесткого оперативного контроля работ
по устранению нештатных ситуаций…)  — один из основных факторов успеха,
позволяющий при ограниченных ресурсах и в обозримые сроки достичь
ожидаемых результатов.
2. Необходимо назначить подходящего сотрудника, который возглавит работу
по созданию Service Desk и внедрению сопутствующих процессов
и в последующем станет ее руководителем или будет осуществлять контроль ее
деятельности. От него зависит не только успех запуска Service Desk,
но и во что превратиться Service Desk спустя год-два после начала работ – будет ли
эта служба развиваться и давать организации все новые преимущества
или выродится в банальную точку регистрации обращений. Возможная
кандидатура  — энергичный и коммуникабельный сотрудник службы эксплуатации
с задатками организатора, понимающего суть работ по поддержке пользователей
и спектр ИТ-систем в организации.
3. Должны быть определены границы охвата Service Desk и сопутствующих
процессов. Теория пропагандирует единую точку входа для пользователей по всем
вопросам, связанных с ИТ. Однако могут возникать сложности, связанные
со службой информационной безопасности, подразделениями, отвечающими
за телефонию, или ИТ-отделами, специально созданными внутри ИТ-службы
под особо крупное внедрение ERP или EAM системы. В этих подразделениях
может существовать сложившаяся практика, которую сложно поменять. Часто
компромиссным решением на первом этапе становится формирование «основной»
точки контакта для пользователей с гарантированными параметрами качества
приема и обработки обращений, и легализация некоторых дополнительных точек
контакта по специализированным вопросам (работа с ERP, телефония…).
4. Для обсуждения постановки задач должны быть привлечены руководители
подразделений ИТ-службы, чья работа будет изменена в ходе создания Service
Desk (как правило, это все подразделения, вовлеченные в эксплуатацию
и сопровождение). Крайне желательно организовать для них общую установку
от имени директора по ИТ и небольшой семинар-обучение о Service Desk
и сопутствующих процессах. Существенно облегчит последующие работы
 составление утвержденного плана работ по организации Service Desk, в котором
прослеживается вовлечения сотрудников разных подразделений.
5. Необходимо оценить, и по возможности согласовать с курирующим ИТ-
руководителем или руководителями бизнес подразделений изменение правил
взаимодействия пользователей и ИТ-службы. Создание Service Desk
сопровождается изменениями для пользователей: переходом на единый номер
телефона и e-mail, мягким или жестким запретом обращаться к ИТ-специалистам
напрямую, внедрением автоматических оповещений о регистрации/закрытии
обращений и т.п. Далеко не всегда приемлемы радикальные изменения, что нужно
будут учитывать при планировании работы Service Desk. Также надо тщательно
планировать проведение изменений в работу пользователей: выпуск нормативных
документов/распоряжений и информирование пользователей подходящим образом
– от информационных рассылок от имени ИТ-службы, до публикаций
тематической статьи в корпоративной газете.
6. Необходимо на ранних стадиях продумать организационно-штатные вопросы
создания Service Desk. В зависимости от принятых решений, может потребоваться
открытие новых ставок и поиск сотрудников, что должно быть инициировано
заблаговременно.

Для  грубого расчета нагрузки на Service Desk и требуемых ресурсов можно

использовать следующие ориентиры: в среднем от пользователя поступает 1,5 заявки
в месяц; оператор Service Desk, в зависимости от его обязанностей и удобства средств
автоматизации, может в среднем обрабатывать 20–45 заявок в день.

Выбор средства автоматизации

Построение Service Desk-это, в первую очередь, выстраивание эффективного конвейера

по обработке обращений пользователей и организация накопления ценной
управленческой информации. А раз речь идет об «эффективных конвейере» и накоплении
информации, значит вопрос автоматизации встает в полный рост. Если ориентировочно
до 2004 года на российском рынке было представлено всего два достойных упоминания
специализированные решения – HP Service Desk и продукты семейства Remedy,
то последние два года можно говорить о широком ассортименте зарубежных средств
автоматизации, разбавленных достойными внимания отечественными разработками.

Стоит отметить, что все современные специализированные системы автоматизации

обладают минимально-необходимым набором функциональности для построения Service
Desk. Поэтому следует сконцентрироваться на оценке адекватности системы решаемым
задачам и масштабам организации. В качестве ключевых параметров, помимо стоимости,
при этом выступает:

 изначальное предназначение системы автоматизации  — в первую очередь

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

Информацию о средствах автоматизации Service Desk может быть почерпнута

из прочтения регулярных отчетов компаний Gartner (Magic Quadrant for the IT Services
Desk) и Forester (The Forrester Wave™: Service Desk Management Tools), изучения систем
сертификации средств автоматизации управления ИТ «PinkVerify» компании Pink
Elephant [5] и «ITIL Product Compliant» компании OGC. При анализе материалов из этих
зарубежных источников нужно помнить о требованиях к обязательной локализации
продукта, а также наличия в России технических специалистов по внедрению
и поддержке.

Специализированные продукты, которые можно использовать для автоматизации Service

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

1) «Промышленные решения как часть платформы управления ИТ» ориентированы

на построение комплексных систем управления ИТ за счет заложенных возможностей
автоматизации многих процессов управления ИТ, описанных в книгах ITIL, ведения
сложных иерархических каталогов услуг и развитого учета информации о компонентах
ИТ в CMDB (configuration management database). Автоматизация Service Desk  — лишь
небольшая часть их возможностей. Системы этого класса обладают мощными средствами
интеграции, широкими возможностями по масштабированию и встроенными средствами
разработки, позволяющими реализовать практически любой функционал. Яркими
представителями этого класса систем являются BMC Remedy IT Service Management Suite,
HP Service Manager. Стоимость лицензий среднего внедрения этого класса систем выше
100 000$.

2) «Средние системы» включают богатый функционал, покрывающие потребности

типового внедрения Service Desk. Они позволяют автоматизировать ряд смежных
процессов управления ИТ, как правило, включают возможности формирования каталога
ИТ-услуг и ведения CMDB. Особенность и ключевое преимущество этого класса систем –
простота внедрения и сопровождения, связанная с тем, что необходимый функционал
обычно уже в значительной мере преднастроен, а его адаптация под свои нужды,
как правило, обеспечивается удобными средствами настройки. Эти системы, как правило,
имеют ограничения в части реализации нестандартных требований, масштабирования
и создания территориально распределенных конфигураций, подходу к интеграции
с другими решениями. Стоимость лицензий для средних внедрений колеблется в пределах
30 000$-100 000$. Примерами являются HP Service Desk v4.5 и v5.x (снятый с продажи,
но поддерживаемый), Axios Assyst.

3) «Легкие системы» ориентированы в первую очередь на автоматизацию Service Desk.

К этому классу отнесены недорогие системы (от бесплатных, до полноценных
коммерческих продуктов ценой от 1 500$ до 20 000$ за среднее внедрение). Системы
этого класса представляют собой либо хорошо продуманные системы с «жесткими»
границами в части настроек (например, Footprints Track-IT!), или же системы,
предполагающие некоторую базовую логику, за изменение которой придется платить
разработкой, однако разработка так же позволяет расширить границы изначального
функционала (пример  — Service Desk Итилиум, разработанной на платформе 1С).

Встречаются инициативы по автоматизации Service Desk собственными разработками

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

Собственные разработки (от Excel файла до базы на MS Access) могут вполне отвечать
запросам небольшого ИТ-подразделения. Однако серьезные инвестиции денег и сил
для автоматизации Service Desk на базе неспециализированных средств редко
оправдываются. Даже самые «легкие системы» автоматизации Service Desk включают
большое количество продуманных решений и удобств, не говоря уже о специфических
возможностях интеграции с системами мониторинга, инвентаризации
и т.д. Воспроизводить эти возможности в неспециализированных системах – дело
неблагодарное.

Подходы к внедрению Service Desk

Создание Service Desk и внедрение сопутствующих процессов является в первую очередь

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

Если рассматривать «типовой проект» по созданию Service Desk (характерны

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

В соответствии с этим подходом работы разбиваются на следующие стадии:

1. «пуск проекта»  — планирование работ, формирование проектной команды,

решение ключевых организационных вопросов, перечисленных в разделе
с типовой постановкой задачи. Включает элементы обследования, если
привлекаются внешние исполнители. Средняя продолжительность – 1–3 недели;
2. «проектирование»  — детальная проработка организационных вопросов. Может
сопровождаться прототипированием для иллюстрации возможной автоматизации
некоторых организационных решений. Средняя продолжительность – 3–4 недели;
3. «техническое проектирование»  — проработка технических аспектов, связанных
со средствами автоматизации. 2–4 недели;
4. «построение решения»  — установка, настройка и интеграция системы
автоматизации Service Desk, ввод/загрузка справочной информации, подготовка
инфраструктуры Service Desk. Также на этой стадии прорабатывается нормативно-
справочная информация нижнего уровня (например, перечень и состав рабочих
групп, ролевые инструкции, перечень поддерживаемых ИТ-систем).
Продолжительность существенно зависит от класса системы автоматизации,
квалификации технических специалистов и качества проработки решения
на предыдущих стадиях. Для ориентира – 3–10 недель;
5. «планирование запуска». Ошибки на стадии запуска Service Desk непростительны,
так как они видны всей организации. Это заставляет каждый раз тщательно
планировать подготовительные мероприятия и первые недели-месяцы работы
 по новым правилам, согласовывать планы по запуску со всеми вовлеченными
подразделениями. Средняя продолжительность – одна неделя.
6. «запуск Service Desk». Стадию можно условно поделить на две части – подготовка
к запуску самой службы Service Desk и поэтапный переход к новым правилам
работы. В первой части решаются вопросы массового обучения ИТ-специалистов,
выпуск регламентирующих документов и распоряжений. Во второй части акцент
делается на информировании пользователей, а также жестком контроле
соблюдения процедур и надлежащего функционирования средств автоматизации.
На этой стадии роль поддержки со стороны руководства ИТ трудно переоценить.
Ориентировочная продолжительность – 3–6 недель.

Указанные стадии можно строго привязать к стадиям разработки

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

Описанный подход применим и в крупных распределенных организациях с поправкой

на степень централизации работ. Централизация работ по созданию Service Desk
и совершенствованию поддержки пользователей может принимать различные формы,
например:

 выпуск стандартов на организацию деятельности. По этому пути в свое время

двигалось РАО «EЭС России», выстраивая деятельность через стандарт предоставления
услуг в области информационных технологий;
 создание единого Service Desk;
 создание иерархических взаимодействующих Service Desk (например, филиалы–центр)
с определением границ ответственности, правил взаимодействия, и централизацией
контроля эффективности служб всех уровней. Пример – некоторые МРК, входящих
в состав ОАО «Связьинвеста».

Средняя продолжительность проектов с использованием описанного подхода составляет

2,5 – 4 месяца и он позволяет получить качественный скачек в работе службы ИТ. Однако
подход требует:

 наличие специалистов, знакомых с теорией вопросы и имеющих практический

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

Если же в организации нет специалистов, имеющих необходимую подготовку и нет

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

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

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

Существенные недостатки обозначенного эволюционного подхода: длительный срок

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

Выше рассмотрены подходы к построению Service Desk и внедрению сопутствующих

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

Service Desk заработал, что дальше?

После запуска Servicer Desk организационные вопросы не заканчиваются, хотя

и переходят в плановое русло. Укажем основные из них:

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

типовой задачи – организация ротации выделенных операторов, там где
их количество превышает 4–5, так как срок работы оператора редко превышает
полтора-два года. Большим плюсом правильно организованной ротации является
то, что после операторской работы часто выходят перспективные кадры
с пониманием проблем пользователей и базовым знанием всех ИТ-систем/ИТ-
услуг организации;
2. обеспечение альтернативных технологий работы. Так как Service Desk становится
со временем одним из ключевых звеньев обслуживания пользователей ИТ,
то любой перебой в ее работе становиться заметен всей организации. Поэтому
в ходе или после запуска Service Desk должны быть продуманы технологии
обработки обращений пользователей в случае выхода из строя средств
автоматизации или инфраструктуры (телефонии, почты);
3. контроль и развитие. Ключевой персоной в этой деятельности является
руководитель Service Desk, от которого требуется как организация оперативного
контроля (который обычно делегируется ниже), так и регулярный анализ
деятельности и подготовка предложений по развитию. Также очень важно
внимание и стимуляция развития со стороны руководства ИТ-службы,
 как минимум выражающееся в регулярных заслушиваниях докладов
о деятельности Service Desk и тщательном рассмотрении предложений о развитии.

Заключение

Проведенный осенью 2008 года опрос ИТ-директоров (организаторы  — российское

отделение itSMF [6] и один из компьютерных издательских домов) показал, что две-трети
российских организаций внедряют у себя современные методы организации ИТ-службы.
Около 70% из них начинали с выстраивания деятельности по поддержке пользователей
и Service Desk.

За прошедшее десятилетие накоплен богатый опыт создания Service Desk, а за последние

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

В связи с этим вопрос «Надо ли строить Service Desk?» постепенно трансформировался

в вопрос «А почему он еще не построен?».

Литература и ссылки:

 Service Support (из серии книг ITIL второй редакции), Stationery Office, 2000 г.
 Service Operation (из серии книг ITIL третьей редакции), Stationery Office, 2007 г.
 серия стандартов ISO/IEC 20000 Information technology-Service management.
 http://www.pinkelephant.com/PinkVERIFY
 http://www.itsmforum.ru/
_________________________________________________________________________

Автор статьи-Директор Департамента систем управления Helios Information

Technologies Сергей Ямов

Статья публиковалась:

 Журнал «Connect». Номер 1–2 за 2010 г.

 Альманах «itSMF Россия Избранные статьи», 2010 г.