www.itsmforum.ru

Часть 2

Почему документы, регламентирующие управление

непрерывностью, зачастую так сложны, непонятны

и, будем откровенны, просто не работают? В статье

разбираются некоторые распространенные

заблуждения, способные серьезно повлиять на

эффективность процесса управление непрерывностью.

Среди ITSM-консультантов можно встретить такую точку зрения, что неко-

торые процессы, описанные в ITIL, на самом деле в полной мере про-

цессами не являются. В пример обычно приводятся или очень простые

процессы, такие как управление доступом, или, наоборот, достаточно

сложные, к которым традиционно относят ряд процессов стадии про-

ектирования (Service design), например, управление мощностями или

непрерывностью ИТ-услуг.

В качестве одного из доводов в защиту такой точки зрения обычно

предлагается попробовать построить блок-схему такого процесса.

Действительно, при попытке формализации управления доступом часто

получается положение об отделе (по сути, описание функции), а вот с

управлением непрерывностью ИТ-услуг может получиться что-то совсем

непонятное. С управлением доступом все просто — в данном случае

процессом действительно названо подробное описание деятельности

узкоспециализированного подразделения (функции с точки зрения ITIL),

отвечающего за конкретный участок оперативно-технической работы.

Авот почему документы, регламентирующие управление непрерывнос-

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

работают, попробуем разобраться.

Исходя из результатов анализа значительного количества документов,

призванных формализовать обеспечение непрерывности ИТ-услуг в

разных организациях: стратегий, регламентов, планов непрерывности,

Игорь Соглаев

Обладает 17-летним опытом работы в облас-

ти информационных технологий. С 2011 года

реализует проекты по построению и совер-

шенствованию процессов управления инфор-

мационными технологиями. Также участвует в

разработке и проведении сертификационных,

авторских и дистанционных курсов по направ-

лению ITIL/ITSM.

Непрерывность

как процесс

Ошибки, которые вполне можно

не допустить при организации

управления непрерывностью

Быть может, ваше единственное

предназначение в жизни — быть живым

предостережением всем остальным.

Законы Мерфи

альманах ITSM 2015

Практика ITSM-проек тов

сценариев восстановления и т.п., можно сфор-

мулировать некоторые распространенные

заблуждения, способные серьезно повлиять на

управляемость данного процесса.

Ошибка №1:

некорректный охват процесса

Первая ошибка, которую можно допустить,

инициируя мероприятия по обеспечению

непрерывности — это попытка объединить

под одной крышей процессную активность

и деятельность, которая является внешней по

отношению к данному процессу. Происходит

это потому, что начинающие менеджеры (а в

роли таковых практически всегда вынужденно

выступают ИТ-специалисты) смешивают совер-

шенно разные сущности, а именно — субъекты

и объекты управления. Схематично взаимоотно-

шения между субъектами и объектами управ-

ления можно представить так, как показано на

рисунке 1. То есть, необходимо учитывать, что

структура управляемого объекта может быть

многоуровневой.

Часто приходится наблюдать, как в охват про-

цесса управления непрерывностью ИТ-услуг

пытаются включить вообще всю деятельность,

имеющую хоть какое-то отношение к этой

теме, например, разработку стратегии непре-

рывности или регламента данного процес-

са. Такая точка зрения в целом понятна — ITIL

содержит довольно подробное описание

организации процесса, начинающееся имен-

но с выработки Стратегии, однако управление

непрерывностью — это не тот процесс, кото

рый следует перегружать сущностями, там и

так в избытке объектов управления.

Стратегия должна определять цели и высо-

коуровневые показатели всей деятельности по

обеспечению непрерывности, регламент —

описывать способы их достижения в формате

регулярной деятельности, включая методы конт-

роля и показатели эффективности (KPI) работы

самого процесса. Создание и актуализацию

этих документов лучше вынести за рамки про-

цесса, они органично смотрятся в качестве вхо-

дящей управленческой информации.

Ошибка №2:

смешение функций управления

Второй характерной ошибкой можно назвать

отсутствие понимания того, что процедуры

управления процессом лучше разделять на

группы (их иногда называют контурами управ-

ления), в соответствии с основными функциями

менеджмента, среди которых обычно выделяют

планирование, организацию, координацию,

контроль и мотивацию (рис. 2). Практика

показывает, что высокоуровневые процессы, в

отличие от процессов операционного уровня

(таких, как управление инцидентами, пробле-

мами или запросами на обслуживание), край-

не чувствительны к подобным недоработкам.

Планирование и мотивацию рассматривать

сейчас не будем — с ними все более-менее

понятно, а вот на оставшихся трех стоит остано-

виться подробнее. Вооружившись Стратегией

непрерывности и Регламентом (создание кото-

рых, как уже сказано выше, целесообразно

вынести за рамки процесса), можно присту-

пать к организации деятельности. Основные

документы, которые рекомендуется разрабо-

тать на данном этапе — это план обеспечения

непрерывности и сценарии восстановления

ИТ-услуг.

Характерным следствием смешения фун-

кций управления является попытка включить в

план обеспечения непрерывности все, кроме

того, что там действительно должно быть. Ведь,

если отвлечься от ITIL и прочих «good practices»

в этой области, то план — это документ, кото

рый в первую очередь должен стать руко-

водством к действию, воинским уставом для

персонала при наступлении по-настоящему

чрезвычайной ситуации. Поэтому довольно

странно видеть там такие разделы, как «Анализ

рисков» или «Порядок проведения и оценки

тренировок», что как раз и является примером

смешения контуров организации, координации

и контроля процесса.

В плане обеспечения непрерывности, в

первую очередь, должны содержаться актуаль-

ные ответы на простые, но жизненно важные

вопросы: «что случилось?», «кому звонить?»,

«куда бежать?», «что спасать?» и т.п. Причем,

нужно понимать, что ответы на эти вопросы

должны быть понятны не только менеджеру по

управлению непрерывностью или руководству

ИТ-департамента, но и тем людям, которые

будут находиться в диспетчерской или пун-

кте управления именно в тот момент, когда

любое начальство окажется вне зоны доступа

Субъект

Объект

¬È½ÊÅÍË¿½ÊÅÂ «ÍÀ½ÊÅÄ½ÓÅÜ

©ËÏÅ¿½ÓÅÜ§ËÊÏÍËÈÙ

§ËËÍÁÅÊ½ÓÅÜ

Рисунок 1 Субъекты и объекты управления.

Рисунок 2 Функции управления процессом.

www.itsmforum.ru

Часть 2

(а в чрезвычайных ситуациях весьма часто так и

происходит). Именно им придется принимать

первые и, возможно, самые важные решения.

Таким образом, учитывая основное назначение

Плана непрерывности и необходимость под-

держания его актуальности, перегрузка этого

документа информацией приводит к очевидно-

му снижению управляемости процессом, при-

чем, на самом критичном его участке.

Ошибка №3:

отсутствие вовлеченности

бизнес‑подразделений

Со сценариями восстановления тоже все

не так просто, как могло бы показаться.

Представим себе ситуацию, что процесс

запущен, регламент исполняется, планы акту-

ализируются, сценарии разрабатываются,

тренировки ИТ-персонала проводятся, и даже

показатели процесса свидетельствуют о высо-

кой готовности организации противостоять

различным неприятностям. Но рано или поздно

обязательно случается реальная нештатная

ситуация (не катастрофа даже), и все поче-

му-то идет не по плану. К примеру, дизельные

генераторы запущены, автоматизированные

системы переведены на резервные схемы

работы, сохраненные данные загружены, а

вот прерванные бизнес-процессы отчего-то не

возобновляются.

Это и есть следствие третьей ошибки —

попытки построить управление непрерывнос-

тью без активного вовлечения в него бизнес-

подразделений. Разумеется, по-хорошему,

именно с этого и следовало бы начать данный

обзор — ведь очевидно же, что целью обеспе

чения непрерывности ИТ-услуг является подде-

ржка непрерывности бизнеса (business continu-

ity), то есть восстановление функционирования

бизнес-процессов, а не автоматизированных

систем или даже ИТ-услуг. Это и в ITIL неод-

нократно сказано, и во всех стандартах по

непрерывности написано, и тренеры на курсах

не устают повторять.

Однако в жизни, к сожалению, слишком

часто решение сложнейших задач по обес-

печению жизнестойкости бизнеса возлагается

на технических специалистов, не имеющих к

этому самому бизнесу никакого отношения.

В результате, естественно, начинаются попыт

ки решить организационные проблемы без

понимания их сути, зато с использованием

технических средств, стоящих весьма недеше-

во. И хорошо еще, если удается иногда про

водить комплексные тренировки с участием

сотрудников бизнес-подразделений, способ-

ные наглядно показать низкую эффективность

подобного подхода, но, зачастую, обходятся и

без них. С легко предсказуемым результатом,

понятно.

Ошибка №4:

подход к управлению

непрерывностью как к процессу

операционного уровня

Ну и четвертая ошибка — излишне упрощенное

понимание процесса, особенно свойствен-

ное начинающим процессным менеджерам.

Управление непрерывностью ИТ-услуг отличает-

ся от процессов операционного уровня — это

стратегический многогранный и многоуров-

невый процесс, в котором ключевую роль

играет постоянное совершенствование. Здесь

недостаточно придумать систему метрик и

регулярно проводить оценку деятельности с

целью справедливого распределения кварталь-

ной премии. Результаты такой оценки должны

служить основой для регулярного проведения

комплексных мероприятий, направлен-

ных на повышение доступности ИТ-услуг

в части обеспечения их восстановления

после серьезных сбоев. Поэтому, напри-

мер, к выбору показателей эффективнос-

ти процесса необходимо подходить не

формально, а постоянно сравнивать итоги

проведенных тренировок с результатами

деятельности по устранению реальных

нештатных ситуаций на тех же объектах

ИТ-инфраструктуры, на которых проводится

отработка сценариев восстановления.

Разумеется, в этом краткое обзоре мы рас-

смотрели не все возможные ошибки, допуска-

емые при организации процесса управления

непрерывностью ИТ-услуг, но приведенных

примеров вполне достаточно для того, чтобы

однозначно определить его как сложный и

многоуровневый процесс, внедрение которого

является серьезным вызовом для любой орга-

низации. Однако, современные тенденции в

развитии бизнеса и все возрастающая роль

обеспечения доступности и непрерывности ИТ-

услуг фактически не оставляют нам выбора —

внедрять процесс необходимо, но делать это

нужно в тесном взаимодействии с бизнесом,

избегая при этом элементарных управленчес-

ких ошибок.



Начинающиеменеджерынередко

смешиваютсовершенноразныесущности,

аименно—субъектыиобъектыуправления