Подводные камни проектов в области непрерывности бизнеса

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

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

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

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

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

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

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

Пример 1

Вам необходимо внедрить в своей организации систему управления непрерывностью деятельности – Вusiness Сontinuity Мanagement (BCM), направленную на защиту бизнеса от не-
предсказуемых чрезвычайных ситуаций (ЧС).

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

Сроки внедрения BCM должны соотноситься с планами по реорганизации компании. Т. е. в примере 1 не учтена первая из упомянутых особенностей рассматриваемых проектов. В качестве рекомендации можно пожелать более реалистично оценивать свои возможности при планировании собственного будущего.

Пример 2

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

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

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

В качестве рекомендации: необходимо привлекать все заинтересованные стороны на самых ранних стадиях, чтобы позже не терять время на много-
кратные объяснения одного и того же все новым и новым участникам.

Пример 3

Цель проекта – разработать концепцию обеспечения непрерывности ИТ-сервисов в случае возникновения чрезвычайной ситуации.

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

Составлен поэтапный план его создания, оценены затраты на реализацию каждого из этапов и получение должного уровня катастрофоустойчивости

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

Все результаты, подробно описанные и проиллюстрированные, выдаются заказчику в виде готового документа. Ему остается лишь ознакомиться с результатом.

Но заказчик не только не восхищается качеством выполненных работ, но и высказывает множество замечаний. Очевидно, что в примере 3 не учтена третья особенность проектов по непрерывности. Урок, который должен быть извлечен, состоит в том, что работы в рамках консалтинговых проектов обязательно должны выполняться в тесном взаимодействии исполнителей и заказчиков. И если одна сторона забывает об этом, в интересах другой настойчиво напоминать о необходимости совместной работы.

Пример 4

Тестирование переключений ИТ-сервисов

Хочу оговориться сразу – в данном проекте все пройдет удачно. Благодаря заинтересованности заказчика и его готовности к проведению работ проект успешен.

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

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

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

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