Инструкция по Business Impact Analysis

  • Tutorial


Не все знают, с чего и когда начать воплощать планы по непрерывности бизнеса в жизнь. Я обычно говорю так: когда возможные потери выше затрат на противодействие угрозе — пора принимать меры, затраты на них будут адекватными. И наоборот. Если со стоимостью противодействия все более-менее понятно, то оценка потерь — задача нетривиальная. Я приглашаю вас за кулисы проекта по оценке влияния чрезвычайных ситуаций на бизнес (Business Impact Analysis — BIA) и разработке стратегии обеспечения непрерывности ИТ на примере крупного ритейлера. Итак, поехали.

Начало


Мы участвовали в проекте X5 Retail Group — крупнейшего ритейлера России. Компания управляет сетями «Пятерочка», «Карусель» и «Перекресток».

У нее уже была своя политика по управлению рисками прерывания деятельности, которая содержала в себе:

  1. страхование рисков;
  2. формирование антикризисного управления;
  3. минимизация рисков жизни и здоровью людей;
  4. контроль рисков управляемости бизнесом;
  5. подготовка планов восстановления ИТ-систем при чрезвычайных ситуациях.

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

Но с учетом экономики процесса компания предположила, что адекватной мерой на случай чрезвычайной ситуации будет резервирование только самых критичных ИТ-систем, без которых магазины не смогут работать и в компании начнутся значительные финансовые потери. Возникает важный вопрос — какие именно системы и за какое время должны восстанавливаться?
ИТ-департамент заказчика определил классификацию ИТ-систем и допустимое время восстановления каждой системы. Однако позже было принято решение провести полноценную оценку влияния чрезвычайных ситуаций на бизнес компании (BIA) согласно ISO 22301 и лучшим практикам.

Объем и границы


Театр начинается с вешалки, а BIA — с определения объема работ. Для этого нужно обследовать бизнес-процессы компании, ее услуги, финансовую отчетность, взаимоотношения с партнерами, клиентами и контрагентами. Затем определить и согласовать те ключевые бизнес-процессы и услуги, которые войдут в границы проекта. От объема зависит продолжительность и стоимость BIA. При этом наш опыт подсказывает, что не стоит растягивать проект больше, чем на 9 месяцев.

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

Интервью




После того как зафиксированы границы и рамки BIA, определяется перечень заинтересованных лиц от бизнес- и других подразделений, с которыми требуется провести интервью. Очень важно собрать сведения от разных департаментов, чтобы получить объективную картину процессов в компании, понять, как они работают, получить оценку «а что будет, если…». На этом этапе мы получаем сведения, как именно бизнес-процессы зависят от ИТ и строим матрицу этих зависимостей. Также представители бизнеса и заинтересованные в бизнес-процессе стороны оценивают последствия, вероятный ущерб, возможные сценарии развития событий. Для этого мы разработали специальную анкету и опросили около 50 респондентов (представили 50 презентаций о самом проекте, провели, получили и обработали все заполненные анкеты).

Бизнес-процессы


Параллельно с интервьюированием мы описали бизнес-процессы, причем с учетом времени выполнения отдельных операций и глубиной проработки, достаточной для дальнейшего анализа. Разбиение процесса на более мелкие составляющие и конкретные операции необходимо для того, чтобы понять, как ИТ-система влияет на конкретный процесс в разное время суток и разное время года. На этом этапе важно понимать, что мы не описываем бизнес-процессы согласно ГОСТ или иной методологии. Мы не занимаемся оптимизацией бизнес-процессов и в целом не даем рекомендаций по улучшению бизнес-процессов, по крайней мере, в рамках BIA. Мы описываем бизнес-процессы в такой детализации, которая позволяет нам обосновать методику расчета потерь и оценить потери по нескольким критериям. Для графического описания использовали нотацию EPC, ARIS и MS Visio, как инструменты.

Пороги


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

  • определить RTO по одному критерию — финансовые потери;
  • определить RTO по трем критериям — финансовые потери, потеря репутации, потеря управляемости бизнес-процессов.

Первый вариант с одним критерием вроде бы предпочтительнее, так как любые потери условно можно перевести в деньги — главное, договориться о формуле пересчета. Но, как показывает практика, никто репутационные потери специально не пересчитывает в финансовые, и согласование такой формулы может занять неопределенное время. Было решено считать время восстановления по обоим вариантам, и на этапе презентации результатов заказчик сам определит, какой из них более объективно отражает действительность.



Забегая вперед, скажу, что при использовании первого варианта с одним критерием оказалось, что RTO по процессу «ценообразование», например, может достигать 10 дней. При расчете по второму варианту RTO не превышало 24 часов. В любом случае, управленческое решение — какие потери учитывать, а какие нет — остается за заказчиком.

Риски


Совместно с заказчиком определили перечень операционных рисков. То есть тех, которые влияют на ИТ, а те в свою очередь влияют на бизнес-процессы, которые… ну вы поняли. Этот этап важен, потому что чрезвычайная ситуация не рассматривается как сферический конь в вакууме, дескать, что же будет с Родиной и с нами, если мы потеряем ИТ. Риски разделили на глобальные и локальные. Для каждого из них определили сценарий развития и влияние на процессы компании с учетом результатов интервьюирования. Очевидно, что одна и та же ИТ-система при выходе из строя может затронуть несколько бизнес-процессов, но нас в рамках проекта жутко волновали только два процесса. Дальше мы провели оценку исков в соответствии со следующими параметрами:

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

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

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

Условный риск и сценарий. Пожар в ЦОД: полностью сгорела серверная комната, недоступен модуль SAP, задействованный в процессе «Пополнение». Это значит, что каждый день, пока сгоревший модуль SAP не будет восстановлен, товарный ассортимент уменьшается. В первую очередь это касается скоропортящихся продуктов, во вторую — продуктов, пользующихся массовым спросом (например, крупы и хлеб), в третью — бытовой химии. Очевидно, что такая ситуация приведет к снижению выручки в магазинах. А вот что не вполне очевидно: покупатель, который пришел за пивом и сигаретами, в случае отсутствия одного из товаров может с большой долей вероятности ничего не купить. Аналогично для процесса «Ценообразование». Если условный покупатель, который узнал о скидках в среду в 12:00, пополудни придет в магазин, а процесс «Ценообразование» не работает (то есть цены без скидок), то он:

А) не купит ничего (= финансовые потери);
Б) будет обвинять магазин в мошенничестве (= потеря репутации)
В) пожалуется регулятору (= штраф за недобросовестную рекламу).

Методика оценки потерь


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

Также в методике описывается:

  • как определяется время восстановления для бизнес-процесса;
  • как время восстановления для бизнес-процесса транслируется в RTO/RPO для ИТ-систем;
  • классы критичности и классы восстановления — зачем это нужно.

Едем дальше.

Расчет RTO


После того как проведены все интервью, описаны бизнес-процессы, оценены риски, определена и утверждена методика, производится расчет потерь. Так как бизнес «Пятерочки», «Карусели» и «Перекрестка» различается как минимум масштабами — для каждой сети мы разработали свои таблицы, свои графики и расчеты потерь.

Для бизнес-процесса в целом определяется время восстановления (см. методику), когда потери превышают пороговое значение (см. пороги). Это время восстановления присваивается тем ИТ-системам, которые участвуют в бизнес-процессе (см. интервью и матрица зависимостей). Казалось бы, параметры непрерывности определены — проект закончен (см. границы и рамки). Но недостаточно сказать «процесс должен восстанавливаться за 12 часов». Важно определить, как это работает сейчас. За сколько часов ИТ-систему удается реанимировать сегодня? И что делать, если текущее время восстановления больше или значительно больше целевого? Для тех, кто еще сохраняет рассудок и концентрацию, добро пожаловать в GAP!

GAP-анализ и план дальнейших действий


В результате предыдущих шагов мы определили состояние для процессов и систем «TO BE», то есть как должно быть в идеале. На текущем этапе, определяем состояние «AS IS». При этом мы в меньшей степени трогаем бизнес-процессы, а сосредотачиваемся на ИТ-составляющей. Для заказчика мы оценили его текущие решения с точки зрения восстановления после чрезвычайной ситуации. Причем в данном случае не пришлось проводить реальное восстановление с таймером. Достаточно было углубиться в подробности и хватило настольного тестирования, чтобы понять, что целевое RTO недостижимо.

После этого мы разработали ряд рекомендаций, как общего характера (по обеспечению непрерывности ИТ), так и касающиеся непосредственно ИТ-систем и их архитектуры. Это эскизы технических решений и грубая оценка стоимости их реализации. Фактически теперь есть основа для принятия решения. На одной чаше весов — потери, а на другой — стоимость мероприятий.
Если некоторые ИТ-системы не проходят GAP-анализ, а точнее, время их восстановления больше, чем целевое, мы делаем программу проектов по достижению целевого состояния или, если хотите, дорожную карту с обоснованием очередности выполнения проектов и промежуточной оценкой повышения устойчивости организации.

Помимо этого, для заказчика мы разработали методические материалы и шаблоны для формирования планов непрерывности и планов аварийного восстановления.

Стратегия


Подождите-подождите, я уже почти закончил.

По итогам BIA мы разработали стратегию обеспечения непрерывности ИТ. В стратегии непрерывности описали два ключевых момента.

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

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

Что дальше? Дальше реализация стратегии непрерывности и business impact analysis для других бизнес-процессов и ИТ-систем. Разработка планов непрерывности, периодическое тестирование этих планов, но это совсем другая история.

Игорь Тюкачев, Консультант Центра проектирования вычислительных комплексов «Инфосистемы Джет»
  • +19
  • 2,2k
  • 2
Инфосистемы Джет
207,00
Компания
Поделиться публикацией

Похожие публикации

Комментарии 2

    0
    По опыту знаю, как непросто провести даже качественный BIA, а в количественном виде — это вообще титанический труд, снимаю шляпу!
    Хотелось бы еще прояснить момент с GAP анализом: вы пишете, что в реальности оказалось, что целевой RTO недостижим и вы составили план действий которые необходимо предпринять, чтобы это исправить. Но ведь может так случиться, что затраты на проведение этих мероприятий будут слишком велики и в этом случае выгоднее было бы согласовать со stakeholder'ом изменение параметров RTO, а то и вовсе risk acceptance. Происходит ли подобное на практике?
      +1
      Спасибо за оценку!
      Вы правы, если затраты на соблюдение RTO превышают стоимость потерь, то согласовывается изменение RTO (постоянно применяется на практике). Причем в рамках компромисса можно увеличить время RTO (первое, что предлагаем), изменить требования к восстановлению ИТ сервиса (восстанавливать на минимально возможном уровне), использовать альтернативные способы продолжения бизнес-процесса (если это возможно). Принятие рисков — пока ни разу не сталкивался.

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

      Самое читаемое