Итак, что же связывает эту книгу и вопросы непрерывности бизнеса? Как и раньше, в основу труда Джима Коллинза легло скрупулезное исследование ряда компаний, объединенных каким-то общим достижением. В данном случае это были компании, акции которых на протяжении достаточно длительного периода показали рост в 10 раз и более по отношению к рынку. И на протяжении всей книги автор выделяет и разбирает те качества, которые были присущи компаниям-лидерам, и, напротив, отсутствовали у их менее удачливых конкурентов.  Не буду пересказывать всю книгу, но одним из таких качеств автор считает «конструктивную паранойю» (Productive paranoia) – стремление быть готовым к наступлению наихудшего сценария. Готовым не только психологически – но и организационно, и материально, то есть как раз то, чему учит наша дисциплина. Тема раскрывается подробно, с яркими примерами – от полярной экспедиции Амундсена до Билла Гейтса. Что ценно и весьма наглядно, каждому кейсу успешной компании противопоставляется кейс менее удачливой (хорошо, если до сих пор живой) компании с похожими исходными позициями в рыночной борьбе.

Если ваш топ-менеджмент говорит, что непрерывность бизнеса – это неважно, или не приоритетно – просто подарите ему эту книжку. Может помочь. К сожалению, книга пока доступна только на английском.

В принципе, почти рядовое событие, если бы в результате него офисный центр, в котором расположена наша компания, с самого утра не остался без телефонной связи. Естественно, я не смог удержаться от того, чтобы провести собственное расследование того, как Билайн взаимодействует с внешним миром во время существенного инцидента. Я сознательно не стал пользоваться никакой инсайдерской информацией и контактами, и пошел путем честного рядового пользователя. Моей задачей было понять, что случилось, и когда это закончится. WTF, как говорят наши англоязычные коллеги. Уточню сразу, этот пост не будет затрагивать вопросов, почему не был зарезервирован канал, почему не произошло оперативной перемаршрутизации трафика, и т.п. – это отдельная большая тема, и здесь надо уже смотреть на технические детали. Мы смотрим сейчас  только на коммуникации с пострадавшим клиентом.

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

Канал второй, инновационный. Твиттер.
Как видно из картинки, ответ пришел примерно через час после моего запроса, что, на мой взгляд, не очень оперативно для твиттера, но в целом приемлемо.  А вот к содержанию ответа у меня есть вполне четкие претензии. Я же спрашиваю не любопытства ради, а чтобы принимать какие-то дальнейшие решения – например, начать обзванивать клиентов, рассылать им мейлы с альтернативными номерами телефона и т.п. Мне нужна реальная информация и прогноз, причем по худшему сценарию. И поэтому оптимистичные и несодержательные заявления типа «связь практически восстановлена», на мой взгляд, неуместны. Забегая вперед, скажу, что в последующие 6 часов связь восстановлена не будет. Когда точно была восстановлена связь, я не знаю – вечером ее еще не было, а утром следующего дня уже была.

Канал третий, e-mail. Письмо, посланное на pomogite@beeline.ru дало мне наиболее качественный, хотя и не очень быстрый, результат. Письмо было отправлено в 13:08, и примерно в 15:30 мне на мобильный телефон отзвонился Владимир П. из Дирекции по обслуживанию клиентов, и это было самой конструктивной частью нашего взаимодействия, потому что:

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

Все было четко и по делу.

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

Минусы:

• Вся коммуникация носила только односторонний характер – не было информации на сайте оператора, мы не получали ни электронных писем, ни звонков на мобильные телефоны о происшедшей аварии;
• Дозвониться в поддержку у меня не получилось;
• Ответ в твиттере был несодержательным.

Плюсы:

• Через 6 часов после аварии я все-таки получил требуемую информацию

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

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

Наиболее ожидаемого события – выхода финальной версии преемника BS 25999, стандарта ISO 22301 «Societal security – Preparedness and continuity management systems - Requirements» не случилось, сроки плавно перенеслись [пока] на 2 квартал 2012 года, документ по состоянию на декабрь 2011 в статусе FDIS. Соответственно, вторая часть,  ISO 22313 «Societal security – Business continuity management systems — Guidance», дойдет до финала в лучшем случае в конце 2012 года, пока статус документа – DIS.

При этом, было бы неправдой сказать, что ISO плохо поработал, т.к. три новых документа мы все-таки получили – два стандарта:

ISO/IEC 27031:2011 «Information technology – Security techniques – Guidelines for information and communication technology readiness for business continuity».

ISO 22320:2011, «Societal security – Emergency management – Requirements for incident response».

И один небольшой документ ISO/TR 22312:2011 «Societal security – Technological capabilities».

BSI был еще более «плодовит», и разработал четыре документа.

В дополнение к выпущенным в 2010 году PD25111:2010 и PD 25666:2010 вышли два новых «PD»:

PD 25888:2011 «Business continuity management. Guidance on organization recovery following disruptive incidents»

PD 25222:2011 «Business continuity management. Guidance on supply chain continuity»

В статусе PAS вышел PAS 200 «Crisis Management – Guidance & Good Practice», нацеленный на то, чтобы дополнить BS 25999 в части, связанной с управлением ситуацией в момент кризиса.

И, наконец, стандарт по управлению рисками ISO 31100:2009 был дополнен стандартом BSI BS 31100:2011 «Risk management. Code of practice and guidance for the implementation of BS ISO 31000″.

Так что, желающим изучить матчасть вполне есть, чем занять новогодние каникулы

Документ относительно небольшой (презентация + whitepaper), доступен после регистрации на сайте Smart Payment Association , ищется по словам «BCP in the Payment Card Issuance».

Тем не менее,  ирландские коллеги в ожидании непогоды подготовили документ, в котором можно почерпнуть кое-что полезное. Документ называется «Business Continuty Planning in Severe Weather. Advice to Businesses  on Preparing for Severe Weather«. Вполне системно рассказывается, на что стоит обратить внимание при подготовке к неблагоприятным погодным явлениям, какого рода последствия обычно возникают, и как им противостоять. Документ небольшой,  читается легко.

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

Тезис №1. Управление непрерывностью бизнеса – не панацея от всех возможных проблем организации. 

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

Чрезвычайная ситуация, которая приводит к недоступности таких ресурсов, как ИТ, офис, персонал, документы – это понятная задача. Это по нашей кафедре. Защитные меры от этих рисков понятны и реализуемы.

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

Как всегда, есть много пограничных областей. И здесь мы переходим к тезису №2.

Тезис №2. Лучше хорошо решить небольшую задачу, чем никак не решить большую.

Система обеспечения непрерывности бизнеса отлично развивается по спирали (AKA цикл PDCA). В 90% случаев сначала обеспечивается непрерывность ИТ-сервисов, потом решается задача восстановления рабочих мест, взаимозаменяемости персонала, управления поставками и т.п. При таком подходе система работает.

Если замахнуться на весь бизнес сразу, скорее всего вы, во-первых, не достигнете цели, а, во-вторых, похороните саму инициативу по управлению непрерывностью бизнеса на долгие годы. Поэтому даже к таким вопросам, как управление ликвидностью в момент ЧС, я бы подходил очень осторожно, ограничивая задачу резервом средств на операции на тот период времени после ЧС, который понадобится на восстановление бизнес-процессов в минимальном объеме.

Итак, грехи:

1. Детальное сценарное планирование

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

2. Сделаем это по-быстрому 

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

3. Инициативы вендоров

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

4. IT DR вместо BCM

С одной стороны, ИТ-директора делают очень полезную работу, продвигая тему обеспечения непрерывности бизнеса в своих компаниях. С другой стороны, и примеров тому бесконечно много, часто все заканчивается только на непрерывности ИТ-сервисов. Как следствие – организация получает шанс получить после ЧС работающую ИТ-инфраструктуру, пользоваться которой будет некому….

5. Отсутствие целостной картины

Важно (но далеко не всегда это делается), строя систему обеспечения непрерывности бизнеса, разобраться, а что, собственно за бизнес у организации? Зачем она существует, как функционирует? Порой, разобравшись в бизнес-процессах организации, удается найти немало возможностей для оптимизации.

6. Black-box Brigade  (русского эквивалента не придумалось)

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

7. Плохие отраслевые стандарты

Ну, эта тема для нас менее актуальна – отраслевых стандартов у нас, кроме как в банковской сфере, нигде нет ))

8. Отсутствие средств автоматизации

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

9. Толщина плана.

Не надо оценивать качество планов по их толщине. Чем лаконичнее и конкретнее план, тем больше будет шансов им воспользоваться в момент ЧС.

Презентации участников:

Chris Gould, PWC

Алексей Чеканов, Алмитек

Олег Михальский, Acronis

Презентация Acronis

Итак, на что стоит обратить внимание.

5 октября с 10:30 до 12:00 под руководством Алексея Бореалиса пройдет круглый стол «ОНиВД в стандарте АРБ – встреча с разработчиками стандарта» – интересно послушать текущее состояние и планы развития стандарта АРБ по обеспечению непрерывности. Как выяснилось в ходе конференции на Infosecurity, многие весьма уважаемые банки даже не в курсе существования этого стандарта. Надеюсь,  круглый стол поспособствует популяризации этой активности.

Практически сразу после этого круглого стола, с 12:50 до 14:20 (по-прежнему 5 октября) я буду вести секцию «Оптимизация инвестиций в непрерывность бизнеса – от правильных рамок системы до эффективных решений«. Алексей Грачев из EMC поделится своим воистину уникальным опытом подготовки российских компаний к сертификации по BS 25999, а в частности – как выбрать такую область действия, чтобы она была и реализуемой на практике, и удовлетворила требованиям сертификационного аудита. [Update: В связи с болезнью Алексея Грачева вместо него выступит Chris Gould из PWC с темой “Is There a Need to Invest in BCM?”]. Я расскажу о том, чего ждать от грядущего стандарта ISO 22301, который придет на смену BS 25999, и как заранее обеспечить максимальное соответствие. И в завершение секции будет немного практики – Олег Михальский из Acronis расскажет о резервном копировании в облака, какие есть проблемы на этом пути, и как их решать.