www.itsmforum.ru
Часть 2
Почему документы, регламентирующие управление
непрерывностью, зачастую так сложны, непонятны
и, будем откровенны, просто не работают? В статье
разбираются некоторые распространенные
заблуждения, способные серьезно повлиять на
эффективность процесса управление непрерывностью.
Среди ITSM-консультантов можно встретить такую точку зрения, что неко-
торые процессы, описанные в ITIL, на самом деле в полной мере про-
цессами не являются. В пример обычно приводятся или очень простые
процессы, такие как управление доступом, или, наоборот, достаточно
сложные, к которым традиционно относят ряд процессов стадии про-
ектирования (Service design), например, управление мощностями или
непрерывностью ИТ-услуг.
В качестве одного из доводов в защиту такой точки зрения обычно
предлагается попробовать построить блок-схему такого процесса.
Действительно, при попытке формализации управления доступом часто
получается положение об отделе (по сути, описание функции), а вот с
управлением непрерывностью ИТ-услуг может получиться что-то совсем
непонятное. С управлением доступом все просто — в данном случае
процессом действительно названо подробное описание деятельности
узкоспециализированного подразделения (функции с точки зрения ITIL),
отвечающего за конкретный участок оперативно-технической работы.
Авот почему документы, регламентирующие управление непрерывнос-
тью, зачастую так сложны, непонятны и, будем откровенны, просто не
работают, попробуем разобраться.
Исходя из результатов анализа значительного количества документов,
призванных формализовать обеспечение непрерывности ИТ-услуг в
разных организациях: стратегий, регламентов, планов непрерывности,
Игорь Соглаев
Обладает 17-летним опытом работы в облас-
ти информационных технологий. С 2011 года
реализует проекты по построению и совер-
шенствованию процессов управления инфор-
мационными технологиями. Также участвует в
разработке и проведении сертификационных,
авторских и дистанционных курсов по направ-
лению ITIL/ITSM.
Непрерывность
как процесс
Ошибки, которые вполне можно
не допустить при организации
управления непрерывностью
Быть может, ваше единственное
предназначение в жизни — быть живым
предостережением всем остальным.
Законы Мерфи
альманах ITSM 2015
31
Практика ITSM-проек тов
сценариев восстановления и т.п., можно сфор-
мулировать некоторые распространенные
заблуждения, способные серьезно повлиять на
управляемость данного процесса.
Ошибка №1:
некорректный охват процесса
Первая ошибка, которую можно допустить,
инициируя мероприятия по обеспечению
непрерывности — это попытка объединить
под одной крышей процессную активность
и деятельность, которая является внешней по
отношению к данному процессу. Происходит
это потому, что начинающие менеджеры (а в
роли таковых практически всегда вынужденно
выступают ИТ-специалисты) смешивают совер-
шенно разные сущности, а именно — субъекты
и объекты управления. Схематично взаимоотно-
шения между субъектами и объектами управ-
ления можно представить так, как показано на
рисунке 1. То есть, необходимо учитывать, что
структура управляемого объекта может быть
многоуровневой.
Часто приходится наблюдать, как в охват про-
цесса управления непрерывностью ИТ-услуг
пытаются включить вообще всю деятельность,
имеющую хоть какое-то отношение к этой
теме, например, разработку стратегии непре-
рывности или регламента данного процес-
са. Такая точка зрения в целом понятна — ITIL
содержит довольно подробное описание
организации процесса, начинающееся имен-
но с выработки Стратегии, однако управление
непрерывностью — это не тот процесс, кото
-
рый следует перегружать сущностями, там и
так в избытке объектов управления.
Стратегия должна определять цели и высо-
коуровневые показатели всей деятельности по
обеспечению непрерывности, регламент —
описывать способы их достижения в формате
регулярной деятельности, включая методы конт-
роля и показатели эффективности (KPI) работы
самого процесса. Создание и актуализацию
этих документов лучше вынести за рамки про-
цесса, они органично смотрятся в качестве вхо-
дящей управленческой информации.
Ошибка №2:
смешение функций управления
Второй характерной ошибкой можно назвать
отсутствие понимания того, что процедуры
управления процессом лучше разделять на
группы (их иногда называют контурами управ-
ления), в соответствии с основными функциями
менеджмента, среди которых обычно выделяют
планирование, организацию, координацию,
контроль и мотивацию (рис. 2). Практика
показывает, что высокоуровневые процессы, в
отличие от процессов операционного уровня
(таких, как управление инцидентами, пробле-
мами или запросами на обслуживание), край-
не чувствительны к подобным недоработкам.
Планирование и мотивацию рассматривать
сейчас не будем — с ними все более-менее
понятно, а вот на оставшихся трех стоит остано-
виться подробнее. Вооружившись Стратегией
непрерывности и Регламентом (создание кото-
рых, как уже сказано выше, целесообразно
вынести за рамки процесса), можно присту-
пать к организации деятельности. Основные
документы, которые рекомендуется разрабо-
тать на данном этапе — это план обеспечения
непрерывности и сценарии восстановления
ИТ-услуг.
Характерным следствием смешения фун-
кций управления является попытка включить в
план обеспечения непрерывности все, кроме
того, что там действительно должно быть. Ведь,
если отвлечься от ITIL и прочих «good practices»
в этой области, то план — это документ, кото
-
рый в первую очередь должен стать руко-
водством к действию, воинским уставом для
персонала при наступлении по-настоящему
чрезвычайной ситуации. Поэтому довольно
странно видеть там такие разделы, как «Анализ
рисков» или «Порядок проведения и оценки
тренировок», что как раз и является примером
смешения контуров организации, координации
и контроля процесса.
В плане обеспечения непрерывности, в
первую очередь, должны содержаться актуаль-
ные ответы на простые, но жизненно важные
вопросы: «что случилось?», «кому звонить?»,
«куда бежать?», «что спасать?» и т.п. Причем,
нужно понимать, что ответы на эти вопросы
должны быть понятны не только менеджеру по
управлению непрерывностью или руководству
ИТ-департамента, но и тем людям, которые
будут находиться в диспетчерской или пун-
кте управления именно в тот момент, когда
любое начальство окажется вне зоны доступа
Субъект
Субъект
Объект
¬È½ÊÅÍË¿½ÊÅ «ÍÀ½ÊÅĽÓÅÜ
©ËÏÅ¿½ÓÅܧËÊÏÍËÈÙ
§ËËÍÁÅʽÓÅÜ
Рисунок 1 Субъекты и объекты управления.
Рисунок 2 Функции управления процессом.
32
www.itsmforum.ru
Часть 2
(а в чрезвычайных ситуациях весьма часто так и
происходит). Именно им придется принимать
первые и, возможно, самые важные решения.
Таким образом, учитывая основное назначение
Плана непрерывности и необходимость под-
держания его актуальности, перегрузка этого
документа информацией приводит к очевидно-
му снижению управляемости процессом, при-
чем, на самом критичном его участке.
Ошибка №3:
отсутствие вовлеченности
бизнес‑подразделений
Со сценариями восстановления тоже все
не так просто, как могло бы показаться.
Представим себе ситуацию, что процесс
запущен, регламент исполняется, планы акту-
ализируются, сценарии разрабатываются,
тренировки ИТ-персонала проводятся, и даже
показатели процесса свидетельствуют о высо-
кой готовности организации противостоять
различным неприятностям. Но рано или поздно
обязательно случается реальная нештатная
ситуация (не катастрофа даже), и все поче-
му-то идет не по плану. К примеру, дизельные
генераторы запущены, автоматизированные
системы переведены на резервные схемы
работы, сохраненные данные загружены, а
вот прерванные бизнес-процессы отчего-то не
возобновляются.
Это и есть следствие третьей ошибки —
попытки построить управление непрерывнос-
тью без активного вовлечения в него бизнес-
подразделений. Разумеется, по-хорошему,
именно с этого и следовало бы начать данный
обзор — ведь очевидно же, что целью обеспе
-
чения непрерывности ИТ-услуг является подде-
ржка непрерывности бизнеса (business continu-
ity), то есть восстановление функционирования
бизнес-процессов, а не автоматизированных
систем или даже ИТ-услуг. Это и в ITIL неод-
нократно сказано, и во всех стандартах по
непрерывности написано, и тренеры на курсах
не устают повторять.
Однако в жизни, к сожалению, слишком
часто решение сложнейших задач по обес-
печению жизнестойкости бизнеса возлагается
на технических специалистов, не имеющих к
этому самому бизнесу никакого отношения.
В результате, естественно, начинаются попыт
-
ки решить организационные проблемы без
понимания их сути, зато с использованием
технических средств, стоящих весьма недеше-
во. И хорошо еще, если удается иногда про
-
водить комплексные тренировки с участием
сотрудников бизнес-подразделений, способ-
ные наглядно показать низкую эффективность
подобного подхода, но, зачастую, обходятся и
без них. С легко предсказуемым результатом,
понятно.
Ошибка №4:
подход к управлению
непрерывностью как к процессу
операционного уровня
Ну и четвертая ошибка — излишне упрощенное
понимание процесса, особенно свойствен-
ное начинающим процессным менеджерам.
Управление непрерывностью ИТ-услуг отличает-
ся от процессов операционного уровня — это
стратегический многогранный и многоуров-
невый процесс, в котором ключевую роль
играет постоянное совершенствование. Здесь
недостаточно придумать систему метрик и
регулярно проводить оценку деятельности с
целью справедливого распределения кварталь-
ной премии. Результаты такой оценки должны
служить основой для регулярного проведения
комплексных мероприятий, направлен-
ных на повышение доступности ИТ-услуг
в части обеспечения их восстановления
после серьезных сбоев. Поэтому, напри-
мер, к выбору показателей эффективнос-
ти процесса необходимо подходить не
формально, а постоянно сравнивать итоги
проведенных тренировок с результатами
деятельности по устранению реальных
нештатных ситуаций на тех же объектах
ИТ-инфраструктуры, на которых проводится
отработка сценариев восстановления.
Разумеется, в этом краткое обзоре мы рас-
смотрели не все возможные ошибки, допуска-
емые при организации процесса управления
непрерывностью ИТ-услуг, но приведенных
примеров вполне достаточно для того, чтобы
однозначно определить его как сложный и
многоуровневый процесс, внедрение которого
является серьезным вызовом для любой орга-
низации. Однако, современные тенденции в
развитии бизнеса и все возрастающая роль
обеспечения доступности и непрерывности ИТ-
услуг фактически не оставляют нам выбора —
внедрять процесс необходимо, но делать это
нужно в тесном взаимодействии с бизнесом,
избегая при этом элементарных управленчес-
ких ошибок.
Начинающиеменеджерынередко
смешиваютсовершенноразныесущности,
аименно—субъектыиобъектыуправления