Внедрение ВСМ

10 вопросов к российскому стандарту ГОСТ Р 53647.3–2010 «Менеджмент непрерывности бизнеса. Часть 3. Руководство по внедрению»

Несколько лет назад я сетовал на то, что в России мало нормативных документов, посвященных теме непрерывности бизнеса. Точнее, я знал о существовании национальных стандартов семейства ГОСТ Р 53647.1–2009 «Менеджмент непрерывности бизнеса. Часть 1. Практическое руководство» и ГОСТ Р 53647.2–2009 «Менеджмент непрерывности бизнеса. Часть 2. Требования». Но время идет, и оказалось, что семейство пополнилось большим количеством документов. Их рассмотрению я хочу посвятить несколько статей.
Итак, предметом рассмотрения в этот раз станет ГОСТ Р 53647.3–2010 «Менеджмент непрерывности бизнеса. Часть 3. Руководство по внедрению». Как и в случае с предыдущими документами, в его основу положен национальный документ Великобритании – BIP 2142:2007 «The Route Map to Business Continuity Management. Meeting the Requirements of BS 25999».
Наверное, как и в любой области, где возможна специализация, рекомендации этого документа будут более понятны и полезны тем, кто уже имеет практический опыт реализации процесса менеджмента непрерывности бизнеса.

Раздел 4.1
При разработке и внедрении СМНБ организация должна установить интересы ключевых причастных сторон.	Кого стоит считать причастной стороной?	В зависимости от рода деятельности организации в число причастных сторон могут быть включены: частные и корпоративные клиенты, партнеры, поставщики товаров и услуг, в т.ч. предоставляющие услуги аутсорсинга и арендодатели, подрядные организации, финансовые организации и страховые компании, контролирующие органы, муниципальные органы власти, экстренные аварийные службы, природоохранные организации, общественные организации, СМИ.
Раздел 4.2
Определение требований к МНБ	Каковы причины начала работ по созданию СМНБ?	Повышение устойчивости организации в случае наступления неблагоприятных обстоятельств, экономической эффективности, конкурентоспособности, выполнение требований законодательства, регулирующих органов, внешних аудиторов.
Раздел 4.4
При разработке и внедрении СМНБ организация должна установить область применения СМНБ с позиции ее ключевых продукции и услуг.	Что стоит учесть при определении области применения СМНБ?	На начальном этапе сложно заранее оценить, сколько потребуется времени, усилий, финансов, дополнительного оборудования и ПО, а также помощи со стороны внешних организаций для построения СУНБ. Поэтому, во-первых, область применения стоит сделать достаточно узкой, чтобы не погрязнуть в сложностях создания СУНБ. Во-вторых, необходимо выбрать критически важную область деятельности, чтобы создание СУНБ для нее имело очевидную пользу, а предоставление необходимых ресурсов не происходило бы по остаточному принципу.
Раздел 5.1
Финансирование программы	Чем аргументировать финансирование программы МНБ?	При определении размера финансирования всегда ищется компромисс между объемом возможных убытков в случае наступления маловероятного события и гарантированных расходов на защиту от него. Помимо финансовых потерь, перечисленных в стандарте, следует учесть такие последствия как: ущерб репутации или угроза оказаться включенными в список недобросовестных поставщиков – например, при взаимодействии с бюджетными организациями; снижение производительности, т.е. скорости обработки поступающих заявок/заказов/претензий; нарушение сроков подачи отчетности (при том, что аварии случаются в самое неподходящее время); нарушение требований законодательства; расходы на оплату сверхурочных работ по устранению последствий, причем последствия часового простоя могут устраняться неделями. До руководства следует донести полное описание того, что может потерять организация, если решит сэкономить на превентивных действиях.
Раздел 6
Внедрение МНБ в культуру организации	Какие дополнительные выгоды получает организация от внедрения МНБ в свою культуру?	К тем выгодам от внедрения МНБ, которые перечислены в стандарте, можно добавить еще несколько: идентификация и защита основных продуктов и услуг, обеспечение непрерывности их предоставления; способность управлять инцидентами, применять эффективные меры реагирования; понимание организацией связей с другими организациями, регулирующими органами, государственными ведомствами, местными властями, аварийно-спасательными службами; наличие обученного персонала, способного эффективно реагировать на инциденты или нарушения нормального хода деятельности, благодаря проведению необходимых учений; понимание и удовлетворение требований причастных сторон; заблаговременная организация получения персоналом необходимой поддержки в случае нарушения нормального хода деятельности; защита цепочки поставок организации; защита репутации организации; соблюдение требований законодательства и нормативной базы.
Раздел 7.1
Управление документацией	Как осуществлять управление документацией программы МНБ?	Необходимо иметь в виду, что управление документацией в области МНБ является нетривиальной задачей. Для зрелого процесса МНБ полный комплект может насчитывать до сотни типов документов. В свою очередь, количество документов одного типа тоже может достигать нескольких десятков (например, регламенты действий сотрудников при ЧС). Управлять всем этим «хозяйством» вручную нереально. К счастью, на рынке давно существует целый класс специализированных программных продуктов, автоматизирующих выполнение данной задачи. Их условно можно разделить на две группы: те, которые устанавливаются на оборудовании самой организации (например, Sungard Availability Services), и те, которые предоставляются по схеме SaaS через интернет (например, ClearView Continuity). У каждой группы есть плюсы и минусы.   «+» «-» ПО — настройка шаблонов, процессов, форм для печати в полном соответствии со своими желаниями — изучение дополнительного ПО; — самостоятельное администрирование SaaS — нужен только интернет; — доступность данных и их сохранность в специализированной организации может быть выше — данные остаются вне организации; — при ЧС может быть затруднен доступ Выбор инструмента зависит от конкретной ситуации и предпочтений покупателя, но использовать его лучше с самого начала работы в области МНБ.
Раздел 8.2
Анализ воздействия	Какой важный параметр не упоминается в стандарте?	В стандартах, посвященных теме непрерывности, по какой-то причине не рассматривается параметр RPO, Recovery Point Objective (целевая точка восстановления), обозначающий количество данных, которое может быть утрачено без угрозы существованию организации. Возможно, авторы стандартов исходят из того, что данные должны быть сохранены все полностью, но жизнь, к сожалению, не удовлетворяет этому требованию. Даже компании, предлагающие коммерческие облака, обещают создавать резервные копии данных клиентов, начиная с примерно 1 раза в 2 часа и реже, т.е. данные, введенные за последние 2 часа могут быть потеряны. Ограничения есть у любого технического решения, поэтому не стоит отказываться от использования параметра RPO.
	Как проводить анализ воздействия?	В теории существует два подхода к проведению анализа воздействия на бизнес. Подход «снизу вверх» – когда определяется ценность одного ресурса, например, конкретного сервера. Для совокупности ресурсов, поддерживающих предоставление одной услуги или создание одного продукта, выбираются самые строгие требования среди всех ресурсов, входящих в эту совокупность. Аналогичная процедура повторяется для всех продуктов или услуг. Второй подход «сверху вниз» встречается чаще и заключается в анализе и сравнении информации, получаемой от руководителей. При этом не стоит спрашивать, насколько важны функции этого подразделения. Вы себе можете представить, чтобы руководитель назвал свое подразделение не очень важным? Конечно, каждый скажет, что выполняет не просто важные, а критически важные для существования организации задачи. Поэтому лучше просто попросить описать нарастание негативных последствий в случае прерывания каждой конкретной функции. Это позволит перейти от качественных и эмоциональных оценок к количественным (на столько звонков не ответили бы, столько транзакций не обработали бы, столько клиентов не обслужили бы, столько неучтенных ресурсов потратили бы).
Раздел 8.5
Оценка риска	О каких рисках идет речь?	Распространено мнение, что непрерывность бизнеса охватывает все возможные происшествия и аварии. Но на практике использование единого подхода к разным ситуациям, как правило, малоэффективно. Можно предложить такую градацию событий, нарушающих деятельность, которые отличаются составом участников их устранения. Поломка – событие, наносящее минимальный ущерб, т.е. ущерб пренебрежимо малый по сравнению, например, с годовой выручкой или оказывающий незначительное воздействие на способность организации достигать поставленных целей. Такая проблема решается в рамках штатного процесса управления инцидентами, а не процесса обеспечения непрерывности. Авария – событие, нарушающее штатное функционирование процессов организации. Ущерб в этом случае может быть неприемлемо большим (по сравнению с объемом годовой выручки), само событие делает невозможным соблюдение внутренних SLA и/или договорных обязательств перед клиентами. Авария не может быть устранена в рамках процесса управления инцидентами, а требует привлечения других людей и активации процесса управления непрерывностью. Кризисная ситуация – ситуация, которая не может быть преодолена в рамках штатных процессов. Вдобавок к процессу управления непрерывностью требует инициации процесса кризисного управления. Часто она может быть преодолена силами самой организации, хотя ее причинами иногда служат внешние события, непосредственно не затрагивающие бизнес-процессы (экономический кризис, похищение или гибель руководителей, кража персональных данных и т.д.). Широкомасштабная катастрофа – событие, которое невозможно предотвратить и которое оказывает огромное влияние на жизни и здоровье людей и имущество организации. Под угрозу могут быть поставлены как само существование компании, так и посторонние люди. Широкомасштабную катастрофу нельзя устранить силами только самой организации. Помимо внутренних команд управления непрерывностью деятельности и кризисного управления в устранении последствий катастрофы главную роль играют внешние аварийные службы и компетентные органы. Таким образом, рациональнее в самом начале внедрения процесса непрерывности деятельности ограничить круг рассматриваемых рисков и не пытаться все неприятности подстричь под одну гребенку.
Раздел 9.
Определение стратегий непрерывности бизнеса	Какую бы еще стратегию разработать?	Для обеспечения непрерывности требуется принять стратегические решения по большому кругу вопросов:  продолжению деятельности, восстановлению ИТ-сервисов, взаимодействию со СМИ, логистике и транспортировке и т.д. Но есть еще одна тема, которой редко уделяют должное внимание, – стратегия использования помещений организации. В условиях наступления чрезвычайной ситуации компания для продолжения функционирования должна предусмотреть, каким образом будут удовлетворяться потребности в таких помещениях, как склад для оборудования, переносимого из пострадавших/ставших недоступными помещений; склад для продукции, которая продолжает выпускаться; штаб кризисного управления; запасные офисные помещения для работы сотрудников, покинувших штатное рабочее место. В отдельных случаях у конкретной организации могут возникнуть потребности и в других помещениях, например, приемной или гараже. Для удовлетворения всех этих нужд можно воспользоваться несколькими путями, например, временно использовать по другому назначению собственные помещения, переместить сотрудников в филиалы, арендовать площади в коммерческом дата-центре, временно переместить часть или все бизнес-процессы в помещения дружественных компаний или организовать работу сотрудников на дому. Любое из принятых стратегических решений или их комбинация имеет свои плюсы и минусы и требует заблаговременной подготовки, выделения ресурсов, технической и организационной модернизации, изучения рынка предложений, проведения переговоров и заключения договоров с третьими сторонами, на что в момент наступления ЧС просто не будет времени.
Раздел 10.4
Содержание плана обеспечения непрерывности бизнеса	Что еще может быть полезно включить в план?	В стандарте перечислено много пунктов, которые должны обязательно содержаться в планах. Но опыт написания подобных документов для многих организаций подсказывает, что остались неупомянутыми еще несколько тем, которые для некоторых ситуаций могут оказаться очень полезными. В плане стоит указать способы, каналы, регулярность, ответственных за информационный обмен с сотрудниками и их родственниками, основными заинтересованными сторонами и аварийными службами при чрезвычайных ситуациях. Следует учитывать, что беспокойство о своих родственниках, в случае невозможности сообщить им о себе, помешает сотруднику выполнять свои обязанности, а волнующиеся родственники своими настойчивыми звонками способны блокировать работу каналов связи. В плане полезно описать минимальный уровень компетенций, который требуется для его выполнения. В условиях ЧС к выполнению плана могут быть привлечены люди, незнакомые с описанными в нем действиями, приложениями или инструментами. Ситуация с восстановлением вряд ли улучшится, если на очередном шаге человек растерянно разведет руками со словами «я не знаю, как это сделать». В самом плане полезно указать, кто, каким образом, с какой периодичностью обновляет документ, чтобы в нужный момент он был в актуальном состоянии. Во многих случаях сам план с небольшими модификациями может использоваться и для проведения тестов и учений по восстановлению деятельности.