itSMF Russia :: Ассоциации организаций и специалистов в сфере управления информационными технологиями «ИТ сервис-менеджмент форум» баннер
НОВОСТИ УЧАСТИЕ В АССОЦИАЦИИ ОБ АССОЦИАЦИИ БИБЛИОТЕКА СОБЫТИЯ ДЛЯ УЧАСТНИКОВ ТРЕБУЮТСЯ СПЕЦИАЛИСТЫ БЛОГИ

баннер

 

баннер

 

поделиться

 

поделиться

Присоединиться к ITSM сообществу


Состав itSMF Russia

 


книжный магазин itSMF



Подпишитесь на новости ITSM-сообщества

* обязательные поля
Архив рассылок >>>



facebook linkedin баннер twitter



Реестр аккредитованных учебных центров, работающих в Российской Федерации и имеющих право проводить обучение по утвержденному списку курсов ITIL®


Manager’s Certificate in IT Service Management Список ITIL Expert'ов и сервис-менеджеров России и стран СНГ



Список российских профессионалов сервис-менеджмента, обладателей сертификатов priSM




Работа для Вас: актуальные вакансии


Виталий Хозяинов. Опыт внедрения Service Desk в территориально-распределенных организациях. Взгляд ИТ-директора
Untitled Document

Автор: Виталий Хозяинов
сертифицированный сервис-менеджер
18.08.2009 г.
Хозяинов Виталий

Эта статья является обобщением опыта автора по внедрению функции Service Desk  в двух организациях. В обоих случаях внедрение проводилось опираясь на ITIL v.2.

Первое внедрение проводилось в 2006-2007 гг. в международной организации в пределах региона EMEA, а именно – в России, Украине, Казахстане, Чехии, Словакии, Польше и Молдове. Организация находилась на 2-3 уровне организационной зрелости. Причинами, побудившими организацию к внедрению функции Service Desk, стала неспособность имевшихся служб технической поддержки пользователей справляться с сопровождением значительно усложнившихся за короткое время информационных систем и потребность в объективной измеримой оценке качества работы служб технической поддержки. Спонсором и руководителем проекта выступал автор. В качестве средства автоматизации было выбрано ПО BMC Remedy. Выбор был обусловлен тем, что это ПО уже было развернуто в головном офисе организации в США, и для стран в рамках проекта была предоставлена возможность пользоваться копией этого ПО, не нарушая условий лицензионного соглашения. Техническую работу по настройке ПО (загрузка справочников, настройка уведомлений и порядка обработки инцидентов) выполняли сотрудники головного офиса. Составление справочников, определение порядка уведомлений по ролям и порядка обработки инцидентов выполнялось автором совместно с руководителями отделов ИТ каждой из стран в рамках проекта. Подобный поход позволил обойтись без привлечения внешних консультантов и приобретения лицензий, а следовательно – минимальными финансовыми затратами.

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

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

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

Формализация процесса потребовала повышения уровня самоорганизации. Полная прозрачность в коммуникации по всем зарегистрированным инцидентам обнаружила области для совершенствования у всех участников процесса. Для технической поддержки 1-го уровня наиболее характерными недостатками были отсутствие нацеленности на владение своими инцидентами, выражавшееся в отсутствии реакции на ответы от более высоких уровней поддержки на открытые тикеты, и недостаточно детальное описание инцидентов, не позволявшее следующим уровням поддержки работать над определением проблемы. Для 2-го уровня были характерны неразвернутые ответы, недоступные пониманию менее квалифицированных сотрудников. Для 3-го уровня, представленного внутренними разработчиками ПО и сотрудниками головного офиса, было характерно непонимание приоритетности инцидентов, несмотря на наличие сведений о приоритете в тикетах. Последнюю сложность удалось устранить введением формализованной процедуры оповещения об инцидентах с высокой критичностью. Все другие названные выше затруднения удалось преодолеть путем «разбора полетов» по каждому вызвавшему разногласия случаю и объяснения каждому из участников его роли.

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

По итогам проекта можно утверждать, что технически BMC Remedy представляет собой весьма гибкую и надежную платформу для создания систем Service Desk. Это ПО позволило уложить в интегрированную среду процессы управления инцидентами и проблемами в рамках международной коммерческой организации, имеющей разветвленную структуру службы ИТ и использующей систему не только для взаимодействия внутри службы ИТ, но и с внешними подрядчиками (разработчиками ПО).

Второе внедрение проводилось в 2008 г. в международной организации в пределах сферы ответственности российского офиса. Организация находилась на 1 уровне организационной зрелости. Причинами, побудившими организацию к внедрению функции Service Desk, стали рекомендации консультантов по управлению и предположение некоторых руководителей о неудовлетворенности пользователей предоставляемым качеством технической поддержки. Спонсором проекта выступал руководитель службы ИТ, а руководителем проекта — автор. Проект был начат до прихода автора в организацию, поэтому некоторые параметры проекты были вне его сферы влияния. Так, в качестве средства автоматизации было выбрано ПО Symantec Altiris. Выбор был обусловлен тем, что организация предлагавшая внедрение этого продукта, представила команду специалистов, произведшую наиболее благоприятное впечатление на руководителя службы ИТ. Техническую работу по настройке и доработке ПО выполняли сотрудники организации-подрядчика. Составление технического задания на внедрение было выполнено выделенным специалистом по ITIL в составе службы ИТ без проверки качества работы руководителем сотрудника.

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

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

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

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

Об авторе:
Виталий Хозяинов – сертифицированный сервис-менеджер.
Детальная информация доступна по ссылке http://khozyainov-vitaly.moikrug.ru/.



Помогите своим коллегам быть в курсе интересных новостей! Поделитесь!
Документ без названия


 

Приглашаем принять участие
в воркшопе ITSM Labs
баннер


баннер


баннер


Партнеры itSMF России



 Директор информационной службы
 

Information Management

Открытые системы



Московское отделение ISACA

ABPMP Russian Chapter

GlobalCIO

СоДИТ

SPb CIO Club — партнер itSMF России

Высшая школа бизнес-информатики Государственного университета – Высшей школы экономики (ВШБИ)

МИИТ

ГУУ

Московский государственный университет экономики, статистики и информатики (МЭСИ)

Факультет ВМК МГУ имени М.В. Ломоносова

Московский институт электроники и математики (МИЭМ)

Институт информационных бизнес систем



Блоги: