Как организовать работу службы поддержки

На мировом корпоративном рынке вместо термина “служба поддержки пользователей” (help desk) все чаще используется более широкое понятие “общая служба поддержки” (service desk) — соответственно меняется и стратегическая направленность данной организационной структуры. Эта тенденция отмечена в апрельском исследовании сервисного ИТ-рынка, проведенного аналитической фирмой Forrester Research. В нем, в частности, говорится, что служба help desk ориентирована на регистрацию происшествий “по факту”, функционирует, как правило, при поддержке локальных программных систем и не интегрирована с ключевыми ИТ-процессами. При этом она плохо масштабируется: даже простое увеличение числа сотрудников сопровождения нередко лишь ухудшает ситуацию с поддержкой, увеличиваются накладные расходы, падает управляемость, софт не справляется с возросшей нагрузкой и т. д.

Служба service desk отличается от help desk прежде всего ориентацией на профилактику: с ее помощью существенную часть проблем удается предотвращать. Она позволяет выявлять инциденты на самых ранних фазах, но для этого необходимы хорошая автоматизация и развитые аналитические механизмы. Кроме того, работа service desk тесно интегрируется с основными бизнес-процессами, которые для этого должны быть хорошо формализованы и представлены компьютерными моделями. Такая деятельность выстраивается по одной из практических методологий — чаще всего ITIL или CoBIT . Эти подходы объединяются общим понятием управления ИТ-услугами (Information Technology Service Management, ITSM) подразумевающим организацию работы ИТ-отдела как поставщика услуг другим подразделениям компании.

Без правильно организованного ITSM в кризисное время выжить трудно. Об этом свидетельствует, например, интересная статистика ресурса Simply Hired, отслеживающего тенденции на рынке труда в США, Австралии, Англии, Индии и Канаде. Спрос на ITSM-специалистов увеличивался с марта 2007 г., в августе 2008го достиг рекордного уровня, затем на месяц обрушился, но к октябрю вновь восстановился, причем даже превысил августовский рубеж, обойдя исходный мартовский показатель на 145%. Немудрено, что мероприятия по данной теме пользуются большой популярностью среди специалистов. Так, международный форум по ИТ-сервис-менеджменту itSMF собрал этой осенью почти тысячу участников, а на ноябрьскую конференцию “IBM ITSM-Стратегия. Теория и практика”, проводимую независимым форумом itSMF Russia, пришло около ста человек. Алексей Петров, директор по технологиям IBM Tivoli (департамент ПО, IBM EE/A), отметил, что концепция IBM Service Management шире, нежели классические ITSM, и не ограничивается только ИТ-службами. Но опирается она на ИТ, а реализована, в частности, набором методик Process Reference Model, доступным в виде свободного веб-решения Tivoli Unified Process .

Лидерами рынка автоматизации ITSM-деятельности, согласно оценкам Forrester Research, являются четыре компании: BMC (продукт Remedy IT Service Management), CA (Unicenter Service Desk), HP (Service Manager) и IBM (Tivoli Service Request Manager).

Директор по развитию бизнеса Леонид Винокуров (департамент ПО, IBM EE/A) рассказал о платформе Maximo, позволяющей создавать эффективные ITSM-решения. Она успешно эксплуатируется, например, в нефтегазовой и атомной промышленности. Maximo ориентирована на управление жизненным циклом всех активов и сервисов организации, включая материально-технические ресурсы, закупки и договора, поддерживает работу с соглашениями об уровнях обслуживаниям SLA, позволяет развернуть общекорпоративный сервис-центр и т. д.

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

Возможно, причина прохладного отношения к ITIL в том, что данные продукты ориентированы на компании с численностью в тысячи и десятки тысяч сотрудников, хотя и могут применяться в более мелких структурах. Подрядчик обычно выполняет их внедрение “под ключ”, и заказчику не приходится самостоятельно вникать в нюансы ITIL (в крайнем случае исполнитель проведет обучение). А средние и мелкие компании при попытках самостоятельно внедрить рекомендуемые процессы сталкиваются с другими проблемами: нужны дополнительные ресурсы, квалифицированные кадры, способные вникнуть в данную задачу и поддержать работу в новых условиях. Да и рекомендуемые процессы сами по себе отдачи не дадут, если не выработаны измеряемые и разумные критерии эффективности их внедрения. Так, строгое следование требованиям SLA-соглашений и подробное документирование входной информации может спровоцировать скрытый массовый отказ технического персонала в приеме заявок, а излишне вольготная трактовка соглашений, наоборот, превратит SLA в фикцию. В таких случаях на помощь приходят гибкие и упрощенные подходы — как начальный этап на пути к рациональной организации ИТ-труда. Например, существует общедоступный набор технических руководств Microsoft Operations Framework, более простой для освоения. А тем организациям, которые пока лишь задумываются о правильной организации сервисных процессов и о создании в перспективе полноценной service desk, но не знают, с чего начать, ITIL-эксперты рекомендуют следующие два шага.

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

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