Кто поможет Service desk?

Многие CIO сетуют: несмотря на организацию службы поддержки, пользователи продолжают решать проблемы по-прежнему, обращаясь в основном к известным им специалистам или пытаясь ликвидировать неполадки своими силами.
Как правильно создать, вести и использовать базу знаний Service desk? Как распределить обязанности между сотрудниками разных линий? Как структурировать сведения об инцидентах так, чтобы в случае необходимости нужная информация была доступна оператору в полном объеме? Как научить пользователей правильно работать со службой? Как избежать обращений по пустячным поводам? Как организовать учет инцидентов, чтобы иметь возможность их классифицировать, как создать «типовые сценарии» устранения неполадок? Как определять границу, когда инциденты перерастают в проблему (повторяющиеся случаи)?

Георгий Ованесян,
руководитель направления технической поддержки и аутсорсинга компании КРОК

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

Существует несколько вариантов построения службы поддержки пользователей. Например, в крупной компании с большой ИТ-службой и с большим потоком обращений иногда целесообразно организовать центр обработки вызовов (ЦОВ). ЦОВ только принимает и регистрирует обращения пользователей, а сами заявки направляются специалистам ИТ-службы.

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

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

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

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

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

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

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

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

Мария Бартенева,
руководитель отдела ITSM-консалтинга, Verysell Projects

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

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

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

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

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

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

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

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

Александр Глушков,
консультант департамента консалтинга компании "Ай-Теко".

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

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

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

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

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

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

пользователи должны быть хорошо осведомлены о способах обращения в ИТ-подразделения;

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

не должно быть проблем с доступностью службы поддержки.

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

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

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

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

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

Сергей Довгань,
руководитель направления «Системы управления» компании «Инфосистемы Джет»

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

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

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

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

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

http://www.cio-world.ru/