Успешное внедрение ITIL начинается с процессов управления конфигурациями и управления изменениями.

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

Почему это происходит?

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

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

Чтобы избежать этого, перед внедрением процессов необходимо ответить на несколько ключевых вопросов.

Первым неизбежно встает вопрос: с чего начать?

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

Часто внедрение подходов библиотеки ITIL приносит успех, если начинать внедрение с Управления конфигурациями и Управления изменениями (Configuration & Change Management). Такая связка логична, потому что эти процессы наиболее взаимозависимы и при этом сильно влияют на другие процессы. С одной стороны информация об актуальной конфигурации ИТ-сервисов, хранящаяся в CMDB, является необходимым условием для Управления инцидентами и других процессов, как оперативных (Управление проблемами, изменениями, релизами), так и тактических (Управление уровнем сервиса, финансами, мощностью, доступностью, непрерывностью). С другой - без эффективного Управления изменениями невозможно достичь главной цели Управления конфигурациями – актуальности данных в CMDB.

Затем следует вопрос: Что это даст?

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

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

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

Для рассматриваемых в рамках данной статьи процессов в качестве таких выгод чаще всего предлагается:

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

· Подготовка базы для расчета себестоимости ИТ-сервисов.

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

· Как следствие, снижение потерь для бизнеса от простоев за счет увеличения надежности ИТ-сервисов.

· Снижение трудозатрат ИТ-персонала на проведение инвентаризаций и выполнение изменений.

· Снижение рисков при проведении изменений и т.д.

Но это все выгоды долгосрочные. Для поддержания интереса к проекту и для сохранения должной динамики хода внедрения необходимо демонстрировать достижения, к которым приводят процессы на ранних (1-3 месяца) этапах развития, т.н. «быстрые победы» (Quick Wins). Понятно, что эти «быстрые победы» не будут реализованы на стратегическом уровне (для этого просто недостаточно времени). Поэтому и список «быстрых побед» будет отражать специфику конкретной организации, в которой внедряются процессы. Где-то это будет наведение порядка с ИТ-активами и составление базовой конфигурации ИТ-инфраструктуры (baseline configuration), где-то формализация жизненного цикла элементов ИТ-инфраструктуры (иначе – Конфигурационных Единиц, КЕ) с интеграцией процессов закупки, складского хранения, списания и т.д., где-то – выявление нестандартных или неавторизованных КЕ, включая нелицензионное ПО и т.п. Главное, чтобы «быстрые победы» действительно были заметны и востребованы в компании.

Следующий ключевой вопрос: Какие есть особенности в планировании проекта?

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

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

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

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

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

· Собранную в полном объеме информацию о КЕ, включаемых в рамки процесса;

· Документы, формализующие процессы;

· Внедренную систему автоматизации, поддерживающую процессы;

· Сотрудников компании, обученных действиям в рамках процессов.

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

Как внедряем Управление конфигурациями?

· Проводим обследование существующего процесса – какие КЕ учитываются, кто будет пользоваться данными о КЕ, кто за что отвечает, какие слабые места существуют в процессе. Составляем модель «как есть» процесса.

· Определяем охват (scope) процесса по этапам внедрения. Т.е. какие группы КЕ будут включены в процесс сначала, какие потом и т.д. Не менее важно определиться и со степенью детализации логической модели CMDB – какие параметры КЕ должны храниться в CMDB, какие типы связей между КЕ должны существовать, хранится ли история о КЕ, какова логика изменения статусов КЕ. Необходимо ограничивать себя в желании учесть в CMDB сразу все КЕ – лучше двигаться, постепенно расширяя охват процесса, например, от наиболее критичных КЕ к менее критичным.

· Определяем правила процесса (наименование, маркировка, аудиты КЕ), формулируем требования к отчетности по процессу.

· Принимаем решение по системе автоматизации – выбираем существующие продукты, учитывая требования к системе, сформированные на предыдущем этапе, или разрабатываем свою систему.

· Параллельно с разработкой/внедрением системы документируем процесс (модель «как будет») и собираем данные в формате, необходимом для миграции в систему. На предыдущем этапе должны быть определены источники данных и методы сбора данных.

· Разворачиваем и конфигурируем систему, мигрируем данные, проводим тестирование системы на введенных данных. Желательно тестирование проводить с участием сотрудников, выполняющих ключевые роли в процессе.

· Коучинг персонала, участвующего в процессе. Опытно-промышленная эксплуатация (ОПЭ) процесса. Внесение завершающих корректировок в процесс и в систему.

· Продуктивный старт процесса.

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

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

Как внедряем Управление изменениями?

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

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

· Определяем категории изменений.

· Составляем таблицы согласования и утверждения по категориям изменений.

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

· Определяем границы процесса, проводим разделение с процессами Управления релизами, разработки, закупок и т.п. Документируем процесс (модель «как будет»), составляем требования к отчетности по процессу.

· Разработку, развертывание, тестирование системы привязываем по срокам к аналогичным активностям по Управлению конфигурациями.

· Аналогично – коучинг, ОПЭ и продуктивный старт процесса.

Соответственно будут отличаться и риски при внедрении Управления изменениями:

· Правила процесса не формализованы в компании, из-за этого возрастает риск обхода процесса исполнителями;

· Излишняя бюрократизация процесса, особенно при согласовании и утверждении изменений;

· Не определены четкие границы процесса;

· Состав проектной команды (ключевые роли) меняется на стадиях проекта;

· Система автоматизации не удовлетворяет требованиям процесса.

Что дальше?

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

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

Комментарии: (0)   Рейтинг: