Непрерывность как процесс. Ошибки, которые вполне можно не допустить при организации управления непрерывностью.
Быть может, ваше единственное
предназначение в жизни – быть живым
предостережением всем остальным.
Законы Мерфи
Среди ITSM-консультантов можно встретить такую точку зрения, что некоторые процессы, описанные в ITIL, на самом деле процессами не являются. В пример обычно приводятся или очень простые процессы, такие, как управление доступом, или, наоборот, достаточно сложные, к которым традиционно относят ряд процессов стадии проектирования (Service Design), например, управление мощностями или непрерывностью ИТ-услуг.
В качестве одного из доводов в защиту такой точки зрения обычно предлагается попробовать построить блок-схему такого процесса. Действительно, при попытке формализации управления доступом часто получается положение об отделе (по сути, описание функционала), а вот обеспечение непрерывности ИТ-услуг вызывает сложности. С управлением доступом все просто – в данном случае процессом действительно названо подробное описание деятельности узкоспециализированного подразделения (функции с точки зрения ITIL), отвечающего за конкретный участок оперативно-технической работы. Но почему документы, регламентирующие управление непрерывностью, зачастую так сложны, непонятны и, будем откровенны, просто не работают, попробуем разобраться.
Исходя из результатов анализа значительного количества документов, призванных формализовать обеспечение непрерывности ИТ-услуг в разных организациях: стратегий, регламентов, планов непрерывности, сценариев восстановления и т.п., можно сформулировать некоторые распространенные заблуждения, способные серьезно повлиять на управляемость данного процесса.
Ошибка №1. Некорректный охват процесса
Первая ошибка, которую можно допустить, инициируя мероприятия по обеспечению непрерывности – это попытка объединить под одной крышей процессную активность и деятельность, которая является внешней по отношению к данному процессу. Происходит это потому, что начинающие менеджеры (а в роли таковых практически всегда вынужденно выступают ИТ-специалисты) смешивают совершенно разные сущности, а именно – субъекты и объекты управления. Схематично взаимоотношения между субъектами и объектами управления можно представить так, как показано на Рисунке 1. То есть, необходимо учитывать, что структура управляемого объекта может быть многоуровневой.
Рисунок 1 Субъекты и объекты управления.
Часто приходится наблюдать, как в охват процесса управления непрерывностью ИТ-услуг пытаются включить вообще всю деятельность, имеющую хоть какое-то отношение к этой теме, например, разработку стратегии непрерывности или регламента данного процесса. Такая точка зрения в целом понятна – ITIL содержит довольно подробное описание организации процесса, начинающееся именно с выработки Стратегии, однако управление непрерывностью – это не тот процесс, который следует перегружать сущностями, там и так достаточно объектов для управления.
Стратегия должна определять цели и высокоуровневые показатели всей деятельности по обеспечению непрерывности, регламент – описывать способы их достижения, включая методы контроля и показатели эффективности (KPI) самого процесса. Создание и актуализацию этих документов лучше вынести за рамки процесса, они органично смотрятся в качестве входящей управленческой информации.
Ошибка №2. Смешивание функций управления
Второй характерной ошибкой можно назвать отсутствие понимания того, что процедуры управления процессом лучше разделять на группы (их иногда называют контурами управления), в соответствии с основными функциями менеджмента, среди которых обычно выделяют планирование, организацию, координацию, контроль и мотивацию (Рисунок 2). Практика показывает, что высокоуровневые процессы, в отличие от процессов операционного уровня (таких, как управление инцидентами, проблемами или запросами на обслуживание), крайне чувствительны к подобным недоработкам.
Рисунок 2 Функции управления процессом.
Планирование и мотивацию рассматривать сейчас не будем – с ними все более-менее понятно, а вот на оставшихся трех функциях стоит остановиться подробнее. Вооружившись Стратегией непрерывности и Регламентом (создание которых, как уже сказано выше, целесообразно вынести за рамки процесса), можно приступать к организации деятельности. Основные документы, которые рекомендуется разработать на данном этапе – это план обеспечения непрерывности и сценарии восстановления ИТ-услуг.
Характерным следствием смешивания функций управления является попытка включить в план обеспечения непрерывности все, кроме того, что там действительно должно быть. Ведь, если отвлечься от ITIL и прочих «good practices» в этой области, то план – это документ, который в первую очередь должен стать руководством к действию, воинским уставом для персонала при наступлении по-настоящему чрезвычайной ситуации. Поэтому довольно странно видеть там такие разделы, как «Анализ рисков» или «Порядок проведения и оценки тренировок», что как раз и является примером смешивания контуров организации, координации и контроля процесса.
В плане обеспечения непрерывности, в первую очередь, должны содержаться актуальные ответы на простые, но жизненно важные вопросы: «что случилось?», «кому звонить?», «куда бежать?», «что спасать?» и т.п. Ответы на эти вопросы должны быть понятны не только менеджеру по управлению непрерывностью или ИТ-руководству, но и тем людям, которые будут находиться в диспетчерской или пункте управления именно в тот момент, когда любое начальство окажется вне зоны доступа (а в чрезвычайных ситуациях весьма часто так и происходит). Именно им придется принимать первые и, возможно, самые важные решения. Таким образом, учитывая основное назначение Плана непрерывности и необходимость поддержания его актуальности, перегрузка этого документа информацией приводит к очевидному снижению управляемости процессом, причем, на самом критичном его участке.
Ошибка №3. Отсутствие вовлеченности бизнес-подразделений
Со сценариями восстановления тоже все не так просто, как могло бы показаться. Представим себе ситуацию, что процесс запущен, регламент исполняется, планы актуализируются, сценарии разрабатываются, тренировки ИТ-персонала проводятся, и даже показатели процесса свидетельствуют о высокой готовности организации противостоять различным неприятностям. Но рано или поздно обязательно случается реальная нештатная ситуация (не катастрофа даже), и все почему-то идет не по плану. К примеру, дизельные генераторы запущены, автоматизированные системы переведены на резервные схемы работы, сохраненные данные загружены, а вот прерванные бизнес-процессы отчего-то не возобновляются.
Это и есть следствие третьей ошибки – попытки построить управление непрерывностью без активного вовлечения в него бизнес-подразделений. Разумеется, по-хорошему, именно с этого и следовало бы начать данный обзор – ведь очевидно же, что целью обеспечения непрерывности ИТ-услуг является поддержка непрерывности бизнеса (business continuity), то есть восстановление функционирования бизнес-процессов, а не автоматизированных систем или даже ИТ-услуг. Это и в ITIL неоднократно сказано, и во всех стандартах по непрерывности написано, и тренеры на курсах не устают повторять. Однако в жизни, к сожалению, слишком часто решение сложнейших задач по обеспечению жизнестойкости бизнеса возлагается на технических специалистов, не имеющих к этому самому бизнесу никакого отношения. В результате, естественно, начинаются попытки решить организационные проблемы без понимания их сути, зато с использованием технических средств, стоящих весьма недешево. И хорошо еще, если удается иногда проводить комплексные тренировки с участием сотрудников бизнес-подразделений, способные наглядно показать низкую эффективность подобного подхода, но, зачастую, обходятся и без них. С легко предсказуемым результатом, понятно.
Ошибка №4. Подход к управлению непрерывностью как к процессу операционного уровня
Ну и четвертая ошибка – излишне упрощенное понимание процесса, особенно свойственное начинающим процессным менеджерам. Управление непрерывностью ИТ-услуг отличается от процессов операционного уровня – это стратегический, многогранный и многоуровневый процесс, в котором ключевую роль играет постоянное совершенствование. Здесь недостаточно придумать систему метрик и регулярно проводить оценку деятельности с целью условно справедливого распределения квартальной премии. Результаты такой оценки должны служить основой для регулярного проведения комплексных мероприятий, направленных на повышение доступности ИТ-услуг в части обеспечения их восстановления после серьезных сбоев. Поэтому, например, к выбору показателей эффективности процесса необходимо подходить не формально, а постоянно сравнивать итоги проведенных тренировок с результатами деятельности по устранению реальных нештатных ситуаций на тех же объектах ИТ-инфраструктуры, на которых проводится отработка сценариев восстановления.
Разумеется, в этом краткое обзоре рассмотрены далеко не все возможные ошибки, допускаемые при организации управления непрерывностью ИТ-услуг, но приведенных примеров вполне достаточно для того, чтобы однозначно определить эту деятельность как сложный и многоуровневый процесс, внедрение которого является серьезным вызовом для любой организации. Однако, современные тенденции в развитии бизнеса и постоянно возрастающая роль обеспечения доступности и непрерывности ИТ-услуг фактически не оставляют нам выбора – внедрять процесс необходимо, но делать это нужно в тесном взаимодействии с бизнесом, избегая при этом элементарных управленческих ошибок.
