Поддержка руководства является основным требованием для всего, что имеет столь далеко идущие последствия, как планирование непрерывности бизнеса. Крайне важно, чтобы руководство понимало, что реально угрожает компании, каковы последствия реализации этих угроз, каковы масштабы потенциального ущерба от реализации каждой угрозы. Без поддержки руководства, достаточных ресурсов, бюджета и времени, нельзя рассчитывать на хороший результат, а плохой план BCP только создаст ложное чувство безопасности, что может быть еще хуже, чем полное отсутствие плана. Проблемы в плане BCP обычно напрямую связаны с проблемами понимания важности этой работы руководством, неправильным видением руководством целей плана.
Руководители несут ответственность в соответствии с различными законами и постановлениями. Они могут быть привлечены к суду акционерами и клиентами, если не обеспечивают должную заботу (due care) и осмотрительность (due diligence), и не выполняют свои обязанности в отношении восстановления после аварий и обеспечения непрерывности бизнеса.
В некоторых отраслях к компаниям предъявляются жесткие требования регуляторов и законодательства, которым они обязаны следовать. Эти требования должны быть проанализированы и с самого начала предусмотрены в плане. Например, банки и инвестиционные компании должны гарантировать, что даже при возникновении чрезвычайной ситуации к конфиденциальной информации их клиентов не получат доступ неуполномоченные лица, она не будет искажена и т.п. Работы по планированию восстановления после аварий и обеспечению непрерывности бизнеса выполняются лучше всего при использовании подхода «сверху вниз», а не наоборот. Именно руководство должно управлять этим проектом, а не рядовой персонал компании.
Многие компании стремятся к максимально быстрому развитию и продвижению, и отказываются от траты времени и ресурсов на вопросы непрерывности и восстановления, не видя в этом возможностей для мгновенного получения выгоды или повышения рыночной доли. Специалистам, работающим в таких компаниях и понимающим ценность результатов этой работы, предстоит пройти через трудный путь убеждения топ-менеджмента компании в целесообразности выполнения этих работ. Но когда произойдет авария, они не пожалеют о потраченных на подготовку усилиях, поскольку результат будет просто неоценим. Сегодняшнему деловому миру требуется два важных аспекта: побуждение для выпуска на рынок прекрасной продукции или услуг, а также мудрость, чтобы предусмотреть возможность возникновения непредвиденных проблем.
Важно, чтобы руководство установило набор высокоуровневых целей для планирования непрерывности и помогло расставить приоритеты, указав, что должно быть сделано в первую очередь. После того, как руководство установит цели, политики и расставит приоритеты, члены команды проекта BCP могут приступать к своей работе. Однако нужно понимать, что потребность в поддержке руководства не заканчивается на этом. Руководство должно убедиться, что планы и процедуры реально разработаны и внедрены. Руководство должно быть уверено, что планы поддерживаются в актуальном состоянии и отражают реальные приоритеты компании, несмотря на происходящие в ней изменения.
Планирование непрерывности бизнеса связано с неизвестностью и вероятностью. Конечно, вы не можете предсказать, где и когда случится чрезвычайная ситуация, но это не значит, что вам не нужно готовить план на этот случай. То, что мы не знаем, что завтра в 10 утра произойдет землятрясение, не значит, что мы не должны заранее запланировать действия, которые необходимо предпринять, чтобы выжить при землятрясении (или другой аварии, чрезвычайной ситуации). Для создания плана непрерывности бизнеса нужно попытаться продумать все возможные аварии и чрезвычайные ситуации, которые могут произойти, оценить их потенциальные последствия и ущерб от них, категорировать и приоритезировать их, разработать реальные альтернативы на случай, если такая авария или чрезвычайная ситуация действительно произойдет.
- Максимально допустимое время простоя
- Нарушение работы и снижение производительности
- Возмещение финансовых убытков (financial consideration)
- Ответственность, установленная законодательством и регуляторами
- Репутация
После завершения этапа сбора данных, Комитет ВСР должен провести их анализ для определения, какие процессы, устройства и операционные функции являются критичными для компании. Например, если система является автономной, не влияет на другие системы и имеет невысокую критичнность, она может быть классифицирована, как восстанавливаемая на второй или третьей фазе процесса восстановления. Соответственно, эта система не будет восстанавливаться до тех пор, пока не завершится восстановление и запуск в работу более критичных систем и ресурсов. Этот анализ может быть проведен с использованием стандартной методологии оценки и анализа рисков (процесс анализа рисков мы обсуждали в Домене 01).
Угрозы могут быть рукотворными, природными или техническими. Рукотворными угрозами могут быть поджоги, террористичесие акты или просто ошибки, приводящие к серьезным последствиям. Природными угрозами могут быть торнадо, наводнения, ураганы или землятрясения.
Техническими угрозами могут быть повреждения данных, перебои электроснабжения, неисправности устройств, нарушения работы коммуникационных каналов. Важно выявить все возможные угрозы и рассчитать вероятность их реализации.
Некоторые угрозы могут показаться неразумными и надуманными, например, злоумышленные действия сотрудников, вандализм, протесты сотрудников, атаки хакеров и т.п., но эти угрозы также должны быть идентифицированы. Для анализа угроз лучше использовать подход, основанный на сценариях их реализации. Это позволит наиболее полно учесть при подготовке плана влияние этих угроз на задачи бизнеса, подразделения и критичные операции компании. Чем больше угроз учтет компания при планировании, тем лучше она будет готова к наступлению чрезвычайных ситуаций.
Шаги BIA. Отдельные шаги BIA перечислены ниже:
1. Подбор людей для опроса в процессе сбора данных.
2. Выбор метода сбора данных (анкетирование, исследование, количественный и качественный подходы).
3. Идентификация критичных для компании бизнес-функций.
4. Идентификация ресурсов, которые необходимы для выполнения этих функций.
5. Расчет времени, в течение которого эти бизнес-функции могут «прожить» без этих ресурсов.
6. Выявление уязвимостей и угроз для этих бизнес-функций.
7. Расчет рисков для каждой отдельной бизнес-функции.
8. Подготовка документа по результатам BIA и предоставление его руководству.
В этом Домене мы рассмотрим каждый из этих шагов.
- Неисправность или недоступность оборудования
- Недоступность водоснабжения, коммунальных услуг, отопления, вентиляции, электроэнергии (utilities)
- Недоступность (невозможность использования) здания
- Недоступность (неработоспособность) критичного персонала
- Недоступность (неработоспособность) производителей или поставщиков услуг
- Повреждение программного обеспечения и/или данных
Должна быть собрана количественная и качественная информация в отношении воздействия на бизнес фактов реализации различных угроз, собранная информация должна быть надлежащим образом проанализирована и интерпретирована с целью максимально точного понимания последствий воздействия этих угроз. При этом воздействие может быть экономическим, функциональным (операционным) или одновременно и тем, и другим. Результаты анализа следует передать наиболее квалифицированным людям в компании для рассмотрения, чтобы они подтвердили, что получены адекватные результаты, описывающие реальные риски, перед лицом которых стоит компания, и их воздействия на бизнес. Это поможет сразу исключить все несущественные данные и обеспечить максимально полное понимание всех возможных воздействий на бизнес.
- Ущерб репутации и общественному доверию
- Потеря конкурентных преимуществ
- Повышение операционных расходов
- Нарушение контрактных обязательств
- Нарушение законодательства и требований регуляторов
- Отложенные расходы
- Потеря доходов
- Снижение производительности
Например, если команда ВСР рассматривает угрозу террористического акта, важно определить, на какие бизнес-функции это скорее всего будет направлено, на какие бизнес-функции будет оказано воздействие, насколько применим для этого случая (прямо или косвенно) каждый из пунктов перечня критериев потерь. Для отдельных бизнес-процессов и компании в целом может быть критично время восстановления. Например, это может быть применимо к деятельности по поддержке клиентов, которая может быть остановлена не более, чем на два дня. Если поддержка клиентов будет остановлена на пять дней, компания может прекратить свое существование.
После идентификации критичных функций, необходимо точно определить, что требуется для работы отдельным бизнес-процессам, реализующим эти критичные функции. Среди необходимых им ресурсов не обязательно будут только компьютерные системы, они могут требовать наличия определенного персонала, выполнения определенных процедур и задач, наличия запасов сырья, поддержки производителей. Команда должна понять, какое влияние на эти процессы окажет недоступность одного или более из необходимых им ресурсов, отсутствие каких ресурсов полностью остановит выполнение соответствующей критичной функции.
В процессе BIA, команда идентифицирует критичные для компании системы, необходимые для ее функционирования, и рассчитывает допустимое для компании время их простоя, вызванного различными неблагоприятными событиями. Это время называется максимально допустимым временем простоя (MTD – maximum tolerable downtime).
- Второстепенная система. MTD = 30 дней
- Обычная система. MTD = 7 дней
- Важная система. MTD = 72 часа
- Необходимая система. MTD = 24 часа
- Критичная система. MTD = менее 1 часа
Команда ВСР должна попытаться продумать максимально возможное количество событий, которые могут произойти и нанести ущерб компании. При этом команда ВСР должна понимать, что обеспечить защиту от всех возможных событий и сценариев – нереально. Хорошая подготовка к наводнению, землетрясению, террористической атаке или удару молнии не так важна, как хорошая подготовка к нарушению или полной остановке критичных бизнес-функции. Компания должна быть готова к повреждению любого (или всех) из своих бизнес-ресурсов, а не сосредотачиваться на отдельных событиях, которые могут нанести ей ущерб.
ПРИМЕЧАНИЕ. BIA выполняется в самом начале процесса планирования непрерывности бизнеса. Проведение BIA необходимо для выявления областей, которые будут подвержены наибольшему ущербу в случае аварии или разрушения (disruption). В процессе BIA выявляются критичные для компании системы, необходимые для ее существования, проводится оценка максимально допустимого для компании времени простоя, вызванного аварией или разрушением.
Взаимозависимости
Важно рассматривать компанию в виде сложного организма. В компании используется множество различных типов оборудования, работают люди, выполняются различные задачи, созданы различные подразделения, организованы коммуникационные каналы и интерфейсы связи с внешним миром. Самой большой сложностью при правильном планировании непрерывности явяется понимание всех этих компонентов и их взаимоотношений. Команда может разработать планы резервного копирования и восстановления данных, установить резервное оборудование, обучить сотрудников вручную выполнять автоматизированные задачи и предусмотреть дополнительные источники питания. Но если нет четкого понимания, как все эти компоненты будут совместно работать в другой среде, позволяя получить на выходе тот же продукт, это может оказаться пустой тратой времени и денег.
- Определение важнейших бизнес-функций и поддерживающих их подразделений.
- Определение взаимозависимостей между этими функциями и подразделениями.
- Выявление всех возможных нарушений (аварий, разрушений) которые могут оказать воздействие на механизмы, необходимые этим подразделениям для функционирования.
- Выявление и документирование потенциальных угроз, которые могут нарушить взаимодействие подразделений между собой.
- Сбор количественной и качественной информации, относящейся к этим угрозам.
- Обеспечение альтернативных методов восстановления функциональности и коммуникаций.
- Подготовка краткого и понятного описания для каждой угрозы и соответствующей информации.
В масштабах предприятия. Определение и согласование границ проекта ВСР даст ответ на вопрос, нужно ли включать в план только один офис или несколько (все) офисов компании. Большинство планов ВСР разрабатывается в масштабах компании в целом, а не для отдельных ее частей.
В большой компании может иметь смысл разработать отдельные планы действий на случай чрезвычайных ситуаций для каждого подразделения. План подразделения будет учитывать их специфичные потребности в процессе восстановления. Эти планы отдельных подразделений не должны противоречить общему плану ВСР в масштабах всей компании.
- Принятие решения о разработке ВСР и обеспечение поддержки
- Установка политики и целей
- Предоставление необходимого бюджета и ресурсов
- Принятие на себя ответственности за результаты разработки ВСР
- Создание команды для разработки BCP
- Определение требований законодательства и регуляторов, которые должны быть учтены
- Выявление всех возможных уязвимостей и угроз
- Оценка вероятности реализации этих угроз и потенциального ущерба от их реализации
- Выполнение BIA
- Определение, работа каких подразделений, систем и процессов должна быть восстановлена раньше других
- Разработка процедур и шагов для возобновления работы бизнес-процессов компании после аварии
Полученная в результате BIA информация вместе с другими данными, рассмотренными в предыдущих разделах, должна быть предоставлена высшему руководству. Руководство обычно требует предоставлять информацию, выраженную в деньгах или иных количественных терминах, а не в виде субъективных качественных понятий. Конечно, неплохо знать, что в случае торнадо все будет «совсем плохо», но гораздо лучше знать, что в случае торнадо пострадает 65% помещений компании, возникнет риск остановки всех комьютерных систем на срок до 72 часов, прекращения электроснабжения на срок до 24 часов, а работа компании полностью остановится на 76 часов, при этом ежедневно компания будет нести потери, эквивалентные $125 000. Работать с количественной информацией значительно проще и эффективнее.
Важно, чтобы все это было сделано до того, как команда ВСР уже разработает какой-либо из своих планов. Сначала нужно собрать данные, провести их анализ, а результаты предствить руководству. Руководство должно проанализировать эти результаты и одобрить их, после чего команда должна приступать к разработке плана.
Будем считать, что руководство нас горячо поддержало и теперь мы имеем возможность перейти к следующим этапам.
- Business Continuity Planning https://dorlov.blogspot.com/2010/10/issp-07-2.html» target=»_blank»]dorlov.blogspot.com[/mask_link]
Реверсивное восстановление бизнес-процессов компании на основании данных в ИС
Управление бизнес-процессами подразумевает организацию определенного цикла управления. Сначала выполняется дизайн бизнес-процесса, затем он автоматизируется с использованием информационных систем, а не последнем этапе осуществляются контроль и анализ выполняемого бизнес-процесса. Таким образом, для построения процессного управления необходимо замкнуть цикл управления, т.е. провести мониторинг процессных показателей, анализ структуры «фактического» процесса, а также проверку результативности его участников. Цикл управления замыкается, если бизнес-процесс измеряется, и на основании полученной информации его оптимизируют путем создания новой версии процесса, после чего выполняют изменения в информационных системах, которые его поддерживают.
В большинстве случаев российские компании, где внедряется процессный подход в управлении, начинают с первого этапа – дизайна бизнес-процессов. В практике описание процессов происходит на основании интервью с экспертами или наблюдения за сотрудниками.
Это наиболее простой способ, однако призма человеческого восприятия делает создаваемое описание бизнес-процессов субъективным, т.е. зависящим от конкретного эксперта. При этом выполнить настоящую оптимизацию процесса по графической модели достаточно сложно. В рамках работ по дизайну процессов может проводиться лишь «первичная» оптимизация: устраняются лишние циклы согласования, информационные и организационные разрывы и т. д. Затем начинается автоматизация описанных бизнес-процессов. Но при таком подходе оптимизировать процессы сложно, поскольку делать это приходится без анализа детальной информации – «телеметрии» о реально выполняемом процессе.
При этом оптимизация, выполняемая в рамках проекта внедрения информационной системы, осуществляется по остаточному принципу, поэтому она представляет собой скорее переделку процессов под внедряемую систему, нежели их совершенствование. Между тем есть другой способ оптимизировать бизнес-процесс. В случае если процессы уже автоматизированы, то можно начинать не с их описания, а сразу с их контроля и анализа, т.е. с последнего этапа жизненного цикла управления процессами. В качестве основы для такого анализа можно использовать данные из информационных систем, тогда полученный результат будет заключаться не только в модели бизнес-процесса, но и в множестве показателей и аналитических разрезов по процессу.
Реверсивное восстановление процессов
Сейчас уровень автоматизации большинства российских компаний уже достаточно высок, и в информационных системах, поддерживающих бизнес-процессы, содержится огромное количество информации, отражающее фактическую деятельность компании. Эти данные можно использовать для реверсивного восстановления бизнес-процесса.
Это и есть та самая «телеметрия», которая необходима для оптимизации процесса, и ее нужно только правильно собрать и структурировать, чтобы восстановить на ее основе реально протекающий в компании бизнес-процесс и провести его детальный анализ. Если рассмотреть логику работы большинства информационных систем, то во многих случаях информация через пользовательские формы создаются или изменяется в реляционной базе данных, в частности в отдельных таблицах и полях. Анализируя структуру данных и происходящие в базе данных изменения, можно отследить те события в системе, которые являются «фактом» выполненных функций в процессе.
При этом вместе с полями, изменения которых являются признаком выполнения функции, нужно анализировать другие поля, содержащие показатели по процессу и аналитические разрезы. После сбора и анализа информации по отдельным экземплярам выполненных функций на следующем уровне их связывают в единый экземпляр бизнес-процесса. Для такой связки необходимо создать набор полей — ключ, по которому могут определить, какие функции относятся к одному экземпляру процесса. На практике в качестве ключа может быть использованы такие поля документа, как номер заказа или договора, при этом в случае их отсутствия используют сложносоставные ключи: клиент-контрагент, исполнитель-услуга и т.д.
Таким образом, методология реверсивного восстановления бизнес-процесса имеет несколько ключевых элементов:
- в первую очередь это анализ структуры данных корпоративной информационной системы, где отражаются результаты выполненных в процессе транзакций (событий);
- далее это алгоритмы преобразования событий информационной системы в элементы процессной модели – экземпляры функции;
- в рамках преобразования данных в экземпляры функций также собираются данные по показателям процесса, отражающие время, стоимость и качество процесса;
- для расширения области анализа одновременно собираются данные по свойствам процесса — аналитические разрезы, например исполнитель, покупатель, контрагент;
- для сбора элементов бизнес-процесса в единое целое используются ключи (атрибуты) для связки экземпляров функций в цепочки процессов.
Следуя данной методологии, достаточно легко восстановить бизнес-процесс на основании данных, хранящихся в информационных системах, при этом можно анализировать данные по процессу за достаточно длительный период, что позволяет увидеть статистику и структуру бизнес-процесса за несколько лет.
Реверсивное восстановление процессов — области применения
Наиболее эффективно реверсивное восстановление процесса там, где проходит большое количество экземпляров функций. В таких случаях модель бизнес-процесса, нарисованная вручную, часто не дает требуемой детализации и необходимых параметров для анализа.
Однако анализ данных в информационных системах позволяет собрать достаточное количество информации по процессу, а также определить его «лучшие» и «худшие» сценарии в соответствии с различными параметрами. В то же время при реверсивном восстановлении процессов невозможно анализировать те функции, которые не поддерживаются информационными системами – они остаются «за кадром». Именно поэтому от уровня автоматизации процесса зависит, можно ли применять данную методику на практике. Если бизнес-процесс полностью автоматизирован с использованием систем класса ERP, CRM, SCM, Business Process Management или Document Management System, то его можно восстановить в полном объеме.
Ну а если в процессе нет поддерживающих информационных систем, то и его реверсивное восстановление невозможно. На практике число функций, автоматизированных в бизнес-процессе, составляет от 30 до 50% от их общего числа, что позволяет восстановить основную часть бизнес-процесса, а значит, провести его подробный анализ. Наиболее частым источником данных для реверсивного восстановления процессов является ERP-система, в частности система SAP. Любая транзакционная система содержит набор таблиц с данными по ресурсному планированию, поля из которых и становится источниками данных для восстановления бизнес-процессов. Реверсивное восстановление процессов в первую очередь востребовано в отраслях, где процессное управление является основной методологией управления.
Практика выполненных российских проектов показывает, что данный подход широко распространен в нефтяной, энергетической, телекоммуникационной и банковской отраслях. При этом ключевыми становятся такие процессы компании, как закупка, продажа, техническое обслуживание и ремонт, платежи, подключение к сети, розничное кредитование и т.д. Все эти процессы имеют большое число экземпляров, отследить которые вручную просто невозможно. При этом помимо реверсивного восстановления бизнес-процесса важно контролировать изменения показателей при его дальнейшей оптимизации.
Реверсивное восстановление процессов — анализ бизнес-процесса
В результате сбора данных из информационных систем агрегируется информация обо всех экземплярах процесса и его параметрах. Основной смысл анализа заключается в определении наиболее успешных экземпляров с точки зрения определенных показателей и их дальнейшего детального изучения. При этом он может быть нескольких видов и выполняется в такой последовательности:
- анализ объемных показателей по бизнес-процессу – определение тех областей, которые требуют изучения в первую очередь;
- анализ процессных показателей – выборка требуемых экземпляров процесса, например, с точки зрения их длительности или числа ошибок;
- анализ структуры процесса – детальное исследование логики процесса, правильности выполнения его операций и числа исключительных сценариев;
- анализ организационной эффективности – изучение объема работ, исполняемых участниками процесса, длительности операций, числа согласований и т.д.
В результате такого анализа можно определить «лучшие» экземпляры процесса и «лучших» исполнителей, что становится основой для внутреннего бенчмаркинга бизнес-процессов в компании. Мониторинг действующих бизнес-процессов дает возможность увидеть «опережающие» индикаторы результатов работы компании, что позволяет принять своевременные решения еще до того, как финансовый учет выявит существующие проблемы. При этом простой сбор ключевых показателей результативности без привязки к бизнес-процессам часто не приносит ощутимой пользы, потому что на основе данной информации достаточно сложно определить «узкое место» бизнес-процесса и наметить шаги к его совершенствованию.
Следовательно, для упрощения перехода от анализа информации к совершенствованию процессов необходимо использовать их реверсивное восстановление. Фактически для этого используется система бизнес-аналитики, содержащая в своей основе основные шаги процесса, на которую «нанизываются» показатели по процессу и аналитические разрезы. Несмотря на все преимущества реверсивного восстановления процессов в методике есть и слабое место – качество данных в системе. В одном случае может быть вариант, когда данные перед внесением в информационную систему «вычищаются», и тогда восстановленные бизнес-процессы будут идеальными.
В противном случае данные могут быть настолько плохи, что восстановленные бизнес-процессы не соответствуют действительности, и тогда результат анализа становится бессмысленным, если не считать необходимости наводить порядок в ИТ-системе. Однако реверсивное восстановление процессов может дать результат в части оптимизации процессов в кратчайшие сроки, обеспечив управленцев и бизнес-аналитиков информацией для принятия решений по оптимизации процессов.
Реверсивное восстановление процессов — заключение
Реверсивное восстановление бизнес-процессов позволяет менеджменту компании осуществлять: расширенный анализ показателей бизнес-процессов в части времени, стоимости и качества; анализ показателей бизнес-процессов по различным аналитическим разрезам – времени, региону и т.д.; детальный анализ до уровня экземпляра бизнес-процесса и конкретного исполнителя; бенчмаркинг бизнес-процессов с использованием процессных показателей; контроль за выполнением мероприятий по совершенствованию процессов; выявление потенциала для сокращения стоимости и времени выполнения процесса; автоматическая визуализация выполняемых бизнес-процессов в виде модели.
Финансовая газета, ноябрь 2010 года
А. КОПТЕЛОВ, руководитель практики внедрения бизнес-приложений IDS Scheer Россия и страны СНГ
Источник: koptelov.info
