Comments 4
Немного не понял, что хотел донести многоуважаемый автор до аудитории и что конкретно спросить?
Я, навнедряв и отаудировав десятки компаний, склонился к позиции, что BCP, DRP, и ICM (incident management) это всё части BCM.
Мне не понятно, какая цель у данной публикации. Я абсолютно не согласен с тем, что BC или DRP стал модным трендом.
Все зависит от целей/требований бизнеса. Полагаю, что большинство людей не сталкивалось с ними ни разу, а кто-то много лет их создает и имплементирует. И связано это скорее всего с размерами и серьезностью клиентов )
Мы — сервисная компания по разработке ПО. Первый раз я такой план рисовал лет 10 назад.
Есть план для нашего бизнеса, есть планы для центров разработки, которые мы создаем для клиентов. Причем у клиентов требования к планам достаточно разные.
Далее что-то наподобие средней температуры по больнице =) список полезных пунктов, которые не хотелось бы оставить за бортом
+ overview, objectives, assumptions, disaster recovery task forces — who/where/what
+ plan of disaster
++ disaster classification на классы
+++ самая крупная разбивка L1-L4 (asset,site,city, country)
++++ complete/partial/localized
+++++ конкретные проблемы, степень их влияния на бизнес, и ответственные команды
++ кто определяет класс проблемы, схемы оповещения call tree, кого/когда (до/после)
++ knowledge management plan impact — важно понимать, как мы не потеряем какие-то важные знания/информацию в случае проблем
++ recovery strategy
+++ для каждой проблемы детальные инструкции, fallback планы
++ планы тренингов, проверок поддержания обороноспособности
++ планы ревью и обновления планов )
+ по странам/городам/офисам — описание рисков, опять же разных уровней — начиная с политической обстановки, рисков природных катаклизмов, расписания сезонных эпидемий, и до asset уровня по необходимости
+ списки офисов, ответственных в каждом офисе, кол-во рабочих мест (с техникой/без техники)
+ списки бэкап оборудования в офисах, возможность их перемещения между офисами
ну вообщем, как-то так. понятно, что первый раз тяжело делать, а потом уже по накатанной и это не является чем-то сложным или требующим большого количества времени обсуждений…
Все зависит от целей/требований бизнеса. Полагаю, что большинство людей не сталкивалось с ними ни разу, а кто-то много лет их создает и имплементирует. И связано это скорее всего с размерами и серьезностью клиентов )
Мы — сервисная компания по разработке ПО. Первый раз я такой план рисовал лет 10 назад.
Есть план для нашего бизнеса, есть планы для центров разработки, которые мы создаем для клиентов. Причем у клиентов требования к планам достаточно разные.
Далее что-то наподобие средней температуры по больнице =) список полезных пунктов, которые не хотелось бы оставить за бортом
+ overview, objectives, assumptions, disaster recovery task forces — who/where/what
+ plan of disaster
++ disaster classification на классы
+++ самая крупная разбивка L1-L4 (asset,site,city, country)
++++ complete/partial/localized
+++++ конкретные проблемы, степень их влияния на бизнес, и ответственные команды
++ кто определяет класс проблемы, схемы оповещения call tree, кого/когда (до/после)
++ knowledge management plan impact — важно понимать, как мы не потеряем какие-то важные знания/информацию в случае проблем
++ recovery strategy
+++ для каждой проблемы детальные инструкции, fallback планы
++ планы тренингов, проверок поддержания обороноспособности
++ планы ревью и обновления планов )
+ по странам/городам/офисам — описание рисков, опять же разных уровней — начиная с политической обстановки, рисков природных катаклизмов, расписания сезонных эпидемий, и до asset уровня по необходимости
+ списки офисов, ответственных в каждом офисе, кол-во рабочих мест (с техникой/без техники)
+ списки бэкап оборудования в офисах, возможность их перемещения между офисами
ну вообщем, как-то так. понятно, что первый раз тяжело делать, а потом уже по накатанной и это не является чем-то сложным или требующим большого количества времени обсуждений…
Sign up to leave a comment.
BCP и DRP. Разница иногда не очевидна