Компания Siemens Business Services предоставляет по всему миру ИТ-сервисы для корпорации Siemens AG и выполняет ИТ-аутсорсинг для внешних клиентов. Выяснилось, что за время сотрудничества стороны накопили груз взаимных претензий, вызванных, в первую очередь, отсутствием внятно составленного сервисного соглашения. В результате с сентября 2003 года в российской «ветви» SBS начал внедряться ITIL-ориентированный процессный подход.

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

Эта невнятность привела к тому, что конечные пользователи ожидали и зачастую не получали качественных, в их понимании, сервисов. Понятие «качество сервиса» каждый из них трактовал по-своему, что выливалось в поток недовольства по адресу сервисной организации. В свою очередь, представители провайдера сервисов на всех уровнях, от инженеров технической поддержки до руководства компании, как могли «отбивались» или хотя бы сглаживали наиболее острые конфликты, ссылаясь на отсутствие формальных обязательств по поводу качества обслуживания. Ситуация осложнялась и тем, что у «Сименс Бизнес Сервисез» имелись достаточно амбициозные планы завоевания доли на рынке ИТ-аутсорсинга, на котором действовали достаточно сильные игроки, использующие в своей работе ITIL/ITSM.

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

Из этого плана логично «вытекал» и план внедрения ITIL-ориентированных процессов. В первой фазе развертываются процедуры Service Desk, Incident Management, Configuration Management, во второй — Problem Management, Change Management, Service Level Management, а затем (до сентября 2004 года) проводятся внутренние аудиты, оценивается зрелость внедренных процессов, вырабатываются и реализуются меры непрерывного повышения качества, формализуются процессы управления качеством.

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

Трудность первая. Поддержка руководства

Речь идет о Management Commitment, которому посвящена одна из глав в книге Service Support. Если вы проведете презентацию для руководителей своей компании и убедите их в необходимости внедрения ITIL, то, скорее всего, вы получите поддержку. Однако их энтузиазм несколько спадет после приблизительной оценки сроков и затрат на внедрение ITSM (кстати, руководителю проекта внедрения желательно иметь четкое представление о реальных размерах необходимого бюджета).

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

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

Трудность вторая. Клиент всегда прав?

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

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

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

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

Трудность третья. Кадры решают все

Иногда от представителей и заказчика, и сервисной организации приходится слышать «процессы не работают» или «процессы недостаточно автоматизированы». Безусловно, процессы должны быть описаны во внятных и достаточно подробных процедурах, поддержаны необходимыми средствами автоматизации, а такие процессы, как Incident Management или Configuration Management, и вовсе немыслимы без этого. Но в процессах и с системами работают люди. Без их должной компетенции и желания работать по-новому даже самые сложные системы и умные процедуры становятся бессмысленными.

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

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

От руководителя процесса требуются ярко выраженные навыки управления, причем эффективность работы процессных менеджеров должна оцениваться по тем же критериям, которые используются для оценки деятельности руководителей функциональных бизнес-подразделений. В силу тесной взаимосвязи между ITIL-процессами бывает полезной практика «переназначений» процессных менеджеров (например, менеджер по конфигурациям назначается руководителем процесса управления проблемами, а инцидент-менеджер — менеджером по изменениям), что может стать дополнительным мотивирующим фактором. Эффективным оказывается и привлечение к внутренним аудитам процессов менеджеров взаимодействующих процессов. Но, пожалуй, главное для успеха внедрения ITIL — наличие команды единомышленников, имеющих общие цели и заинтересованных в достижении общего результата (в «Сименс Бизнес Сервисез» действует офис процессного управления, объединяющий менеджеров процессов под управлением менеджера по качеству).

Трудность четвертая. Измерять прогресс

Если в качестве ключевых показателей эффективности (Key Performance Indicator, KPI) процессов выбираются незначимые для процесса метрики, не влияющие напрямую на достижение процессом поставленной цели, если система KPI не сбалансирована, если установленные пороги KPI не соответствуют реальным возможностям процессов или не управляются — все это может стать причиной проблем.

Сложность состоит в том, что пороги определяются, как правило, на этапе подготовки сервисных соглашений, а для обеспечения соответствия порогов действительности необходимо накопить и проанализировать статистику за достаточно большой срок (в «Сименс Бизнес Сервисез» с февраля 2004 года практикуется еженедельное предоставление внутренних KPI-отчетов и ежемесячных отчетов для заказчиков). Методики сбора информации необходимо согласовывать с заказчиком, выделяя именно ту информацию, которая действительно важна для него (распространенный подход: «предоставьте нам все, а мы из этого выберем нужное»).

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

Необходимо также регулярно оценивать развитие процессов («Сименс Бизнес Сервисез» использует для этого методику ITSM OGC Self-Assessment Test).

Главное — без измерения нет управления. Без достоверной статистики и сравнительного анализа результатов текущего и предыдущего периодов проект внедрения ITIL имеет шансы подвергнуться жесткой критике и со стороны руководства сервисной компании, и со стороны заказчика.

Трудность пятая. Не сбиваться с пути

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

Роман Симонов (roman.simonov@siemens.com) — руководитель отдела качества компании «Сименс Бизнес Сервисез» (Москва).