Об эксперте:
Сергей Кудряшов, партнер Департамента управленческого консультирования компании ДРТ.
Управление непрерывностью бизнеса (УНБ) не всегда спасает от непредвиденных ситуаций, и вот почему:
- вы в полной мере не управляете непрерывностью;
- система может существовать «для галочки»;
- процессы могут действительно работать только в одном подразделении (например, IT);
- может оказаться, что масштаб бедствия не регулируется средствами УНБ, а требует организации антикризисного управления. Применение исключительно средств УНБ в кризис чревато запоздалым реагированием, последующими неправильными и несвоевременными решениями, паникой, потерей данных и средств и, наконец, остановкой работы предприятия.
Что делать в таких случаях?
Методы управления непрерывностью
Вот четыре современных тренда в развитии управления непрерывностью бизнеса, которые в наибольшей степени соответствуют последним изменениям в работе предприятий.
Операционная устойчивость (Resilience)
Идея подхода состоит в обеспечении баланса работы команд риск-менеджмента, кризис-менеджмента и непрерывности, а также понимания того, насколько в организации присутствует не только управление разного рода рисками (снижение вероятности того или иного события), но и реагирование на них (действия сотрудников при наступлении событий разного масштаба — от рядовых инцидентов до кризисов). Этот подход позволяет понять, насколько в компании охвачен весь спектр событий, на которые необходимо реагировать.
Киберустойчивость (Cyber Resilience)
Эту тенденцию можно охарактеризовать как связь кибербезопасности с непрерывностью. Как бывает на практике? Компания провела резервное копирование всех систем (бэкапы), просчитала RPO (Recovery point objective — максимальный период, за который могут быть потеряны данные), имеет резервный ЦОД и т. д. Однако современные кибератаки бывают непредсказуемы и уничтожают резервные копии или шифруют их, из-за чего восстанавливать зачастую бывает уже нечего.
Как найти решение? В таких обстоятельствах стоит подумать об анализе существующих конфигураций сетей и организации резервного копирования, проектировании современной киберустойчивой архитектуры резервного копирования и восстановления, защите резервных копий, обеспечении защищенной среды восстановления, а также о скоординированном реагировании на инциденты IT-, ИБ-командами и бизнесом.
Подготовка антикризисных команд
Очень часто руководство надеется, что с компанией «такое никогда не случится», а если случится, то «и не из таких ситуаций выбирались». Из-за переоценки своих способностей и недооценки рисков руководители запоздало реагируют на кризисную ситуацию, из-за этого принимают неправильные и несвоевременные решения и в конце концов у сотрудников возникает паника.
Где выход? Управление кризисом не равно управлению непрерывностью — это события разного масштаба. Для выхода из кризиса плана заранее не составишь, так как кризис, как правило, уникален по сравнению с прерыванием отдельных процессов. Именно поэтому выход из кризиса должны слаженно обеспечивать действующие команды менеджеров. В случае нехватки у сотрудников опыта необходимо тренировать команды, отрабатывая различные сценарии, и набирать в антикризисный центр тех из них, которые покажут себя наиболее готовыми.
Гибкое управление непрерывностью бизнеса, или Adaptive BC — Adaptive Business Continuity
Чаще всего бывает так, что руководство не хочет вникать в суть дела. Анализ воздействия на бизнес всего предприятия становится длинным и трудозатратным процессом, планы непрерывности представляют собой устаревшие инструкции, а тестирование превращается в экзамен (вместо отработки навыков сотрудники подвергаются оценке). Совокупность указанных обстоятельств приводит к тому, что системой управления непрерывностью сложно пользоваться, и она начинает деградировать.
Особенностями метода Adaptive BC являются отказ от проведения оценки воздействия на бизнес и оценки рисков, а также уход от жесткой постановки цели на время восстановления. В таком случае время восстановления является не целью, а ограничением. Этот метод не требует наличия подробных планов, а краткие документы используются как ориентир. Кроме того, потребность в поддержке со стороны руководства должна быть только там, где это необходимо. Adaptive BC противопоставляет тренировку тестированию, то есть в план необходимо включить обучение и информирование сотрудников. И, наконец, выстраивать УНБ можно не последовательно, а начиная с любого элемента, в зависимости от текущей потребности бизнеса.
Кейс ДРТ
Отделение российского и белорусского офисов от международной сети «Делойт» и образование ДРТ стало кризисным вызовом для компании с точки зрения непрерывности работы.
Возникло сразу несколько задач:
- нам поставили жесткие сроки выхода из международной сети — два месяца;
- мы были глубоко интегрированы в глобальную IT-инфраструктуру;
- у нас было более 200 критически важных приложений (55% от общего количества приложений), на которых работают процессы, поддерживающие бизнес в России и Беларуси.
Таким образом, перед нами стояла задача за 60 дней перевести всех сотрудников на новые «IT-рельсы», не нарушив бизнес-процессов.
Однако Департамент информационных технологий провел анализ и пришел к выводу, что для перехода с одних систем на другие придется полностью остановить работу организации на целый месяц. Это означало бы, что компании надо было прекратить деятельность по всем проектам и отправить сотрудников в вынужденный простой.
Конечно, такой сценарий никого устроить не мог. Более того, не существовало даже предположений по отправке IT-инфраструктуры в «свободное/самостоятельное плавание». Опираться было не на что. Мы также столкнулись с недостатком навыков IT-специалистов, которые привыкли заниматься базовыми функциями — администрированием, поддержкой и прочим, — а «спасать мир» их не учили. Ситуация усугублялась тем, что действовать необходимо было оперативно, иначе компания могла не выдержать.
Мы выбрали методику Adaptive BC, чтобы перестройка инфраструктуры прошла гладко. Во внутреннюю IT-команду были включены сотрудники, оказывающие услуги по непрерывности деятельности и IT-консалтингу. Таким образом, мы объединили все силы внутренних служб и клиентского сервиса и начали работу.
Три шага до цели
Всю проделанную работу можно разделить на три этапа.
Первый этап (определение ограничений)
Мы определили для себя несколько параметров: объем, стоимость, время, места, люди и вещи.
Объем: вся компания ДРТ.
Стоимость: разумная и достаточная для сохранения компании.
Время: 60 дней.
Места: офисы в России и Беларуси (восемь офисов).
Люди: недоступность 20% IT-персонала (во время подобных ситуаций некоторые сотрудники начинают увольняться, уезжать и т. д.).
Вещи (материальные объекты): исходили из полной недоступности всех IT-систем в день и час Х, когда «дернут рубильник», и определили для себя курс на дальнейшее восстановление всех IT-систем в течение трех месяцев.
Второй этап (обеспечение восстановимости)
Мы начали работать в два потока. Первый поток предполагал определение восстановимости процессов и обеспеченности ресурсами, компетенциями и процедурами на данный момент — это то, на чем делается акцент в Adaptive BC. Мы определили для себя текущий уровень восстановимости в 45%. С точки зрения компетенций цифра была несколько выше, но процедур для обеспечения альтернативной работы бизнес-процессов явно не хватало. Далее мы перераспределили внутренние ресурсы сотрудников — передали навыки, которые были у команды специалистов по непрерывности, IT-специалистам и другим поддерживающим службам.
Второй поток проходил параллельно. На нем осуществлялось планирование порядка восстановления IT-систем и сервисов, потому что одновременно мы должны были «погасить» одну инфраструктуру и встроить вторую. Для второго потока важно было четко прописать дальнейшие действия по пунктам. При прогнозировании сроков восстановления IT-систем требовалось понять, какие критически важные приложения необходимы для обеспечения непрерывной работы. Соответственно, по всем направлениям, где у нас сроки восстановления IT-систем не укладывались в прерывание работы, мы готовили организационное обеспечение (то есть процедуры, планы), которое позволило бы нам в течение какого-то времени прожить без системы, являющейся для нас абсолютно критичной.
Третий этап (миграция)
На этом этапе ключевым моментом было непрерывное взаимодействие специалистов по непрерывности, IT-команды (занималась восстановлением сервисов) и всех остальных сотрудников. Для этого на внутреннем информационном портале была выложена подробная информация о том, какие сервисы когда будут доступны, какие запасные варианты действий и в какие моменты предусмотрены, а также кто за все это отвечает. Общая инструкция для сотрудников также рассылалась по электронной почте и озвучивалась на собраниях. Весь процесс был максимально прозрачным, и можно было отследить, в какой точке мы находимся в данный момент.
Раньше ожидаемого
Миграция IT-систем была закончена на неделю раньше срока. За это время мы реализовали 20 планов обеспечения непрерывности, перенесли более 100 критически важных приложений и организовали непрерывную работу более 200 процессов. Мы сами «дернули рубильник» и исключили перерывы в деятельности организации. Всю работу выполнили наши собственные сотрудники без привлечения дополнительных ресурсов извне. Новая методика Adaptive BC действительно помогает выжить в условиях временных ограничений.