Разбираемся в BIA: популярные вопросы и неочевидные кейсы

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

Анализ воздействия на бизнес (BIA, Business Impact Analysis) — один из фундаментов управления непрерывностью бизнеса, который, как кажется, позволяет решить основные вопросы: оценить потери от простоя критичных процессов, выделить эти критичные процессы, узнать, от чего зависит их непрерывное функционирование и какие требования выдвигаются к обеспечивающим ресурсам со стороны бизнеса. В конечном итоге именно благодаря BIA (а не методу «трех П» — пол-палец-потолок) мы можем получить обоснованную бизнесом оценку целевого времени восстановления (RTO) и целевой точки восстановления (RPO) для информационных систем. Без BIA невозможно внедрение и дальнейшее эффективное развитие системы управления непрерывностью деятельности в компании, подготовка стратегии реагирования, Business Continuity и Disaster Recovery планов.

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

Рекомендаций к проведению BIA огромное количество, начиная от стандарта ISO 22317 и гайдлайнов BCI (Business Continuity Institute) и заканчивая статьями в русскоязычных профессиональных сообществах, и даже в новом ГОСТ 57580.3/4 можно найти такие рекомендации. Может показаться, что если мы вооружимся всеми эти гайдлайнами и шаблонами анкет, BIA пройдет гладко, а результаты будут максимально точными, но на практике мы сталкиваемся с множеством проблем:

·       Недооценка одних информационных систем и переоценка других, когда система электронного документооборота становится Mission Critical, а система удаленного доступа к инфраструктуре компании — Office Productivity.

·       Излишний акцент на технических ресурсах и недостаточный — на прочих ресурсах (эксперты, здания и сооружения), требующихся для функционирования процессов.

·       «Разовый» заход вместо внедрения системного процесса.

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

·       Проведение BIA без изначального анализа рисков непрерывности.

Как правило, при проведении BIA основным ориентиром является стандарт «ISO/TS 22317:2021 Security and resilience. Business continuity management systems: Guidelines for business impact analysis», который выделяет следующие основные этапы при проведении анализа воздействия на бизнес:

Этап 1. Определяемся с методологией проведения BIA, согласовываем матрицу, типы и критерии ущерба для анкетирования бизнес-владельцев.

Этап 2. Определяем область действия анализа — согласуем с руководством критичные направления бизнеса, продуктов или услуг, которые войдут в скоуп.

Этап 3. Приступаем к выполнению BIA: обследуем процессы, функции, системы, определяем целевое время восстановления и критичность.

Этап 4. Определяем  зависимости и взаимосвязи между процессами и поддерживающими их ресурсами.

Этап 5. Финал: подводим итоги и готовим краткую выжимку для руководства компании.

Кейс 1. А что такое критичность?

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

Одним из ключевых факторов понимания представителями бизнеса дальнейших вопросов в рамках BIA является изначальное понимание термина «критичность», ведь зачастую специалисты по непрерывности бизнеса могут неверно донести до интервьюируемых суть и определение этого термина. Это грозит нерелевантной оценкой процесса — завышением его уровня критичности. Рассмотрим для примера маркетинг и рекламу. Важны ли эти функции для бизнеса? Безусловно, ведь это привлечение новых клиентов и увеличение прибыли. А критичны ли эти функции с точки зрения непрерывности? Здесь однозначный ответ дать уже нельзя. Если основной бизнес компании — производство, и произошла нештатная ситуация, так ли важны в этот момент рекламные акции и планирование конференций? Наверное, нет. При этом функции маркетинга во время кризиса тоже могут быть важны, а все ресурсы брошены на внешние коммуникации. Именно эту разницу в оценке наиболее важно донести до интервьюируемых в рамках BIA.

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

Кейс 2. Минута простоя — непоправимый ущерб

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

По нашему опыту, существует несколько способов дополнительно проверить данное утверждение:

·       Во-первых, это анализ исторических данных: случались ли в компании когда-то инциденты, приведшие к простою процесса, понесла ли компания сопоставимые убытки?

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

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

Столкнувшись с данным кейсом, необходимо не забывать о целях управления непрерывностью и анализа воздействия, в частности, на бизнес. Глобально наша задача — устойчивость компании во время кризисной ситуации, можно сказать, устойчивость корабля во время шторма. BIA помогает найти элементы, влияющие на эту устойчивость. Выявление критичных процессов и обеспечивающих их ресурсов, как один из результатов BIA, определяет, что необходимо нашему «кораблю», чтобы остаться на плаву. И как следствие, следующей задачей у нас должно стать укрепление «корабля» — наиболее критичных процессов. Возникает вопрос: а кто будет спонсировать данное укрепление? Тут мы подходим к еще одному варианту решения данного кейса.

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

Кейс 3. Учитывать ли планы?

Продолжаем говорить о критичности процессов и функций. Частой ошибкой, встречающейся на практике, является учет реализованных мер при оценке критичности в рамках BIA. Предположим, что процесс из предыдущего кейса при простое действительно несет для компании катастрофические потери. Компания это понимает, поэтому процесс зарезервирован: есть планы действий в случае наступления кризисной ситуации, ИТ-инфраструктура, поддерживающая процесс, задублирована и географически распределена, эксперты-исполнители также располагаются в разных зданиях или даже городах. Правильно ли учитывать такие меры при анализе воздействия на бизнес? Делает ли это процесс менее критичным с точки зрения непрерывности? Абсолютно нет! Учитывать такие меры при BIA не надо. При BIA мы должны оценивать влияние простоя процесса, функции или услуги на компанию.

Мы рассматриваем уже свершившийся факт — процесс остановился. А если учитывать реализованные для процесса меры, то картина результатов BIA в компании получится искаженной. Например, представим завод, производящий товар, сбыт которого — основной бизнес компании. На заводе это понимают, поэтому для всех станков и конвейеров есть ЗИП, а для надежности производства имеется второй энерговвод и дизельный генератор. В случае нештатной ситуации завод еще будет продолжать работать или возможно будет быстро восстановить производство. Делает ли это процесс производства менее критичным? Конечно же, нет. Другой пример — банковский процессинг. Обеспечивающие его ресурсы многократно зарезервированы, а вероятность остановки крайне низка. Значит ли это, что процессинг — это некритичная функция для банка? Нет, потому что даже минутные простои или сбои в работе такой системы приведут к значительным последствиям как для клиентов, так и для банка.

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

Кейс 4. Рассматривать только процессы, приносящие прибыль

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

Посмотрим на примере, для этого опять вспомним ключевую цель BIA: выявить, что является для компании ключевыми элементами, чтобы сохранить устойчивость во время кризиса. Итак, по результатам анализа воздействия на бизнес мы выяснили, что процесс продаж является для компании критичным с требуемым временем восстановления 24 часа. Работоспособность процесса зависит от CRM-системы.

На первый взгляд, всё просто — RTO для CRM будет равняться 24 часам. Владелец ИС такое RTO подтверждает, а команда поддержки разработала и протестировала DRP с возможностью восстановления в целевое время. Кажется, все молодцы, и процесс устойчив. И вот случается инцидент в ИТ-инфраструктуре, влияющий в том числе на работу CRM, но команда поддержки не может восстановить систему в целевое время, потому что работает удаленно, а система, обеспечивающая удаленный доступ к ИТ-инфраструктуре, недоступна, и её RTO — 48 часов. В итоге процесс продаж не восстановлен в срок. Кто же виноват и что надо было делать? Да, мы определили все ресурсы, влияющие на непрерывность бизнес-процесса, подготовили DRP для ключевой системы, но забыли, что техническая поддержка этой ключевой системы — это тоже процесс со своими зависимостями.

При проведении BIA поддерживающий процесс обеспечения работоспособности CRM должен был быть включен в область действия, что в результате позволило бы нам увидеть, что эксперты, отвечающие за функционирование и восстановление системы, работают удаленно, а для активации DRP необходим удаленный доступ к ИТ-инфраструктуре. Имея в итоге такую карту зависимостей, для обеспечения устойчивости процесса продаж и ключевой системы CRM можно было бы инициировать пересмотр RTO для системы удаленного доступа или обеспечить наличие в команде поддержки хотя бы одного эксперта, имеющего возможность во время инцидента прибыть в офис компании. Резюмируя, хочется еще раз напомнить, что в область действия BIA должны попадать все процессы и функции — только тогда мы получим полную карту зависимостей, которая позволит нам правильно сконцентрировать усилия на обеспечение устойчивости компании.

Кейс 5. Связанные процессы

В последнем кейсе хотелось бы затронуть тему ресурсов, влияющих на простой процесса. Всё кажется весьма очевидным: функционирование процесса зависит от исполнителей (людей), технологий (информационных систем, компьютеров, каналов связи и т. д.) и инфраструктурных ресурсов (зданий, помещений, мебели, электричества и т. д.). Да, список ресурсов или технологий может быть достаточно длинным, но обобщенно всё сводится к трем основным составляющим: люди, технологии и инфраструктура обслуживания (Facilities), а также к «поставщикам» этих составляющих: внутренним службам компании или внешним контрагентам.

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

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

Анализ воздействия на бизнес — это не простое заполнение анкеты в рамках интервью, а один из основополагающих столпов выстраивания устойчивого бизнеса и первый шаг к созданию системы управления непрерывностью. И да, скорее всего, вы не получите качественных результатов в первой итерации и не выявите всех взаимосвязей, но, начав проводить BIA в компании, заложите фундамент обеспечения непрерывности. С каждой новой оценкой данные будут всё точнее, а карта зависимостей полнее, что в итоге позволит команде или эксперту по непрерывности в нужный момент подготовить управленческую информацию, которая сохранит ваш «корабль» во время шторма.

Аскар Мусаев

Консультант по непрерывности бизнеса, центр информационной безопасности, "Инфосистемы Джет"

Источник: https://habr.com/ru/companies/jetinfosystems/articles/798211/


Интересные статьи

Интересные статьи

Мы живём в большой микроволновке? - определённо да.Опасно ли это? - нет.Как эпоха контента ведёт нас к вышкам связи и роутерам через каждые 10 метров, и почему это единственный безопасный формат беспр...
Опросил несколько десятков недавних релокантов из РФ об их опыте крипто-выживания на чужбине. В этой статье я разбираю разные способы превращения блокчейновых денег обратно в обычные, а также свожу во...
Часто ли вы заглядываете в свой почтовый ящик? Не тот, который на сервере, а тот, который висит на первом этаже и открывается маленьким ключиком. Сейчас там можно найти разве что кучу рекламной макула...
Источник картинкиРаботающий код может иметь изъяны — например, быть недостаточно простым, лаконичным и понятным. Это может быть признаком более глубоких проблем в коде, а избавиться от них можно с пом...
Мы тут решили подбить предварительные итоги года и проанализировать рейтинги популярности языков программирования. Как менялась популярность ЯП и какие языки в 2020 году считаются топовым...