BCP策定時の間違いトップ11

みなさん、こんにちは。私の名前はイゴール・チュカチェフです。事業継続コンサルタントです。 今日の投稿では、共通の真実について長く退屈な議論をする予定ですが、私の経験を共有し、企業が事業継続計画を策定する際に犯す主な間違いについて話したいと思います。

1. RTO と RPO はランダム

私がこれまでに見た最も重要な間違いは、回復時間 (RTO) が何もないところから計算されていることです。 そうですね、どこからともなく出てきました。たとえば、誰かが以前の職場から持ち帰った XNUMX 年前の SLA の数字があります。 なぜ彼らはこんなことをするのでしょうか？ 結局のところ、どの方法においても、最初にビジネス プロセスへの影響を分析し、この分析に基づいて目標復旧時間と許容可能なデータ損失を計算する必要があります。 しかし、そのような分析を行うには時間がかかり、費用がかかる場合があり、何を行う必要があるのか​​を強調する方法があまり明確でない場合もあります。 そして、多くの人が最初に思い浮かぶのは次のようなことです。 「私たちは皆大人であり、ビジネスがどのように機能するかを理解しています。 時間とお金を無駄にしないようにしましょう！ プラスかマイナスはあるべき姿として捉えましょう。 頭から離れて、プロレタリアの創意工夫を駆使してください！ RTO を XNUMX 時間にしましょう。」

これは何をもたらすのでしょうか? 一定の数値で必要な RTO/RPO を確保するための活動のための資金を管理者に求める場合、常に正当な理由が必要になります。 正当な理由がない場合、どこからそれを入手したのかという疑問が生じます。 そして、答えることは何もありません。 その結果、仕事に対する自信が失われます。

さらに、その XNUMX 時間の回復に XNUMX 万ドルの費用がかかる場合もあります。 そして、RTO の期間を正当化するのは金銭の問題であり、それには非常に大きな問題が伴います。

そして最後に、BCP や DR 計画を出演者 (事故の瞬間に実際に走ったり、手を振ったりすることになる) に提示すると、彼らは同様の質問をするでしょう。「この XNUMX 時間はどこから来たのですか?」 そして、これを明確に説明できない場合、彼らはあなたにもあなたの文書にも信頼を置くことはできません。

それは紙切れのための紙切れ、つまり購読解除であることが判明しました。 ちなみに、単に規制当局の要件を満たすために、これを意図的に行う人もいます。

よくわかりますか

2. すべての治療法

BCP 計画はすべてのビジネス プロセスをあらゆる脅威から保護するために策定されると信じている人もいます。 最近、「私たちは何から身を守りたいのか？」という問いが浮上しています。 「すべて、そしてそれ以上です」という答えが聞こえました。

しかし実際には、この計画は単に保護することを目的としているということです。 特定の 会社の主要なビジネスプロセスから 特定の 脅威。 したがって、計画を作成する前に、リスクの発生を評価し、それがビジネスに与える影響を分析する必要があります。 企業がどのような脅威を恐れているかを理解するには、リスク評価が必要です。 建物破壊の場合は XNUMX つの継続計画があり、制裁圧力の場合は XNUMX つ、洪水の場合は XNUMX つ目の計画があります。 異なる都市にある XNUMX つの同一の敷地であっても、計画が大幅に異なる場合があります。

5 つの BCP、特に大規模な BCP で企業全体を保護することは不可能です。 たとえば、巨大な XXNUMX Retail Group は XNUMX つの主要なビジネス プロセスの継続性を確保し始めました (これについては記事を書きました) ここで）。 そして、会社全体を XNUMX つの計画で包含することはまったく非現実的であり、これは全員が責任を負い、誰も責任を負わない場合の「連帯責任」の範疇に属します。

ISO 22301 規格にはポリシーの概念が含まれており、実際に企業内の継続プロセスはこのポリシーから始まります。 私たちが何を、何から守るのかを説明します。 人々が走ってきて、これとこれを追加してほしいと頼んだ場合、たとえば次のようになります。

――BCPにハッキングされるリスクも加えましょう？

または

— 最近、雨が降ったときに最上階が浸水しました。浸水した場合に何をすべきかというシナリオを追加しましょう。

次に、すぐにこのポリシーを参照して、特定の企業資産を保護し、事前に合意された特定の脅威からのみ保護することを伝えます。なぜなら、それが優先事項だからです。

そして、変更の提案が実際に適切である場合でも、ポリシーの次のバージョンで考慮することを申し出てください。 なぜなら、会社を守るには多額の費用がかかるからです。 したがって、BCP 計画へのすべての変更は予算委員会と計画を通過する必要があります。 会社の事業継続方針を年に一度、または会社の構造や外部条件に大きな変化があった直後に見直すことをお勧めします（読者の皆様、そう言うのはご容赦ください）。

3. 空想と現実

BCP計画を策定する際、著者が何らかの理想的な世界像を描くことがよくあります。 たとえば、「当社には XNUMX 番目のデータセンターはありませんが、存在するかのように計画を作成します。」 あるいは、企業にはまだインフラストラクチャの一部が備わっていませんが、従業員は将来それが登場することを期待してそれを計画に追加します。 そして、同社は計画に現実を当てはめます。XNUMX 番目のデータセンターを建設し、その他の変更について説明します。

左がBCP対応インフラ、右が実際のインフラ

これはすべて間違いです。 BCP計画を立てるということは、お金をかけることを意味します。 現時点で機能しない計画を作成すると、非常に高価な紙代を支払うことになります。 そこから回復することも、テストすることも不可能です。 それは結局、仕事のための仕事になってしまいます。
計画はすぐに作成できますが、バックアップ インフラストラクチャを構築し、すべての保護ソリューションに費用を費やすのは時間と費用がかかります。 これには XNUMX 年以上かかる場合があります。 そして、すでに計画があり、そのためのインフラストラクチャが XNUMX 年以内に登場することが判明するかもしれません。 なぜそのような計画が必要なのでしょうか? それは何からあなたを守ってくれるのですか？

BCP 開発チームが専門家に代わって、何をいつまでに行うべきかを考え始めても、それは空想です。 それは、「タイガでクマを見かけたら、クマとは逆の方向に向きを変え、クマの速度を超えるスピードで走らなければならない」というカテゴリから来ています。 冬の間は足跡を隠す必要があります。」

4. トップとルート

XNUMX 番目に重要な間違いは、計画が表面的すぎたり、詳細すぎたりすることです。 私たちには黄金の中庸が必要です。 計画はバカのために詳細になりすぎてはなりませんが、次のような結果になるような一般的すぎてもいけません。

一般的には簡単です

5. シーザーにとって - シーザーとは何ですか、メカニックにとって - メカニックとは何ですか。

次の間違いは前の間違いから生じています。XNUMX つの計画では、あらゆるレベルの管理のすべてのアクションに対応することはできません。 BCP計画は通常、資金の流れが大きい大企業向けに策定されます（ちなみに、当社の調査によると） 探査平均して、ロシアの大企業の 48% が重大な財務的損失を伴う緊急事態に遭遇しました）と複数レベルの管理システム。 このような企業にとって、すべてを XNUMX つの文書にまとめようとするのは意味がありません。 会社が大規模で組織化されている場合、計画には次の XNUMX つのレベルが必要です。

• 戦略レベル - 上級管理職向け。
• 戦術レベル - 中間管理職向け。
• そして運用レベル - 現場に直接関わる人向け。

たとえば、障害が発生したインフラストラクチャの復旧について話している場合、戦略レベルでは復旧計画を開始することが決定され、戦術レベルではプロセス手順が説明され、運用レベルでは特定のインフラストラクチャを稼働させるための指示が示されます。装備品。

予算のないBCP

誰もが自分の責任範囲と他の従業員とのつながりを確認します。 事故が起きた瞬間、誰もが計画を立て、自分の役割をすぐに見つけてそれに従います。 理想的には、分を争う場合もあるため、どのページを開くかを暗記する必要があります。

6. ロールプレイ

BCP 計画を作成する際のもう XNUMX つの間違いは、計画に特定の名前、電子メール アドレス、その他の連絡先情報を含める必要がないことです。 文書自体の本文では、非個人的な役割のみを示す必要があり、これらの役割には特定のタスクの責任者の名前を割り当て、その連絡先を計画の付録に記載する必要があります。

なぜですか？

現在、ほとんどの人が XNUMX ～ XNUMX 年ごとに転職しています。 そして、すべての責任者とその連絡先を計画の本文に書き留めると、計画は常に変更される必要があります。 そして、大企業、特に政府系企業では、文書を変更するたびに大量の承認が必要になります。

言うまでもなく、緊急事態が発生し、慌てて計画をめくって適切な連絡先を探さなければならない場合、貴重な時間が失われることになります。

ライフハック: アプリケーションを変更する場合、多くの場合、承認する必要さえありません。 もう XNUMX つのヒント: 計画更新自動化システムを使用できます。

7. バージョン管理の欠如

通常、プラン バージョン 1.0 を作成し、編集モードやファイル名を変更せずにすべての変更を加えます。 同時に、以前のバージョンと比較して何が変わったのかが不明瞭な場合もあります。 バージョン管理がない場合、計画は独自の生活を送り、いかなる形でも追跡されません。 BCP 計画の XNUMX ページ目には、バージョン、変更の作成者、および変更自体のリストを示す必要があります。

もう誰もそれを理解できない

8. 誰に聞けばいいですか?

多くの企業には BCP 計画の責任者が存在せず、事業継続性を担当する独立した部門もありません。 この名誉ある責任は、CIO、その代理、または「あなたは情報セキュリティを担当しているので、これに加えて BCP も担当します」という原則に従って割り当てられます。 その結果、計画は上から下まで作成され、合意され、承認されます。

計画の保存、計画内の情報の更新、改訂の責任者は誰ですか? これは処方されない場合があります。 このために別の従業員を雇うのは無駄ですが、既存の従業員の XNUMX 人に追加の業務を課すことはもちろん可能です。なぜなら、今は全員が効率化を目指して努力しているからです。「夜の草刈りができるように、彼にランタンを吊るしましょう」それは必要ですか？

BCP策定からXNUMX年を迎えるBCPの責任者を募集します

そのため、企画書を作って長箱に入れて埃をかぶってしまった、ということがよく起こります。 誰もそれをテストしたり、その関連性を維持したりしません。 私が顧客のところに来たときに最もよく聞く言葉は、「計画はあるが、開発されたのはかなり前で、テストされたかどうかは不明で、機能しない疑いがある」というものです。

9. 水が多すぎる

前提条件の説明とプロジェクトのすべての参加者への感謝の意、会社の活動に関する情報を含む XNUMX ページにわたる紹介文が含まれる計画もあります。 有用な情報が記載されている XNUMX ページ目まで下にスクロールするまでに、データ センターはすでに浸水しています。

現時点までの情報を読み取ろうとしているときに、データセンターが浸水した場合はどうすればよいでしょうか?

企業の「水」はすべて別の文書に記載します。 計画自体は、このタスクの責任者はこれを行うなど、非常に具体的である必要があります。

10. 宴会の費用は誰が負担しますか?

多くの場合、計画作成者は会社のトップマネジメントからのサポートを受けません。 しかし、事業継続を管理しない、または管理するために必要な予算やリソースを持たない中間管理職からのサポートもあります。 たとえば、IT 部門は予算内で BCP 計画を作成しますが、CIO は会社の全体像を把握していません。 私のお気に入りの例はビデオ会議です。 CEO のビデオ会議が機能しなくなったら、誰を骨抜きにするでしょうか? 「提供しなかった」CIO。 では、CIOの観点から見て、会社で最も重要なことは何でしょうか？ 人々が常に彼を「愛している」のは、すぐにビジネスに不可欠なシステムに変わるビデオ会議です。 ビジネスの観点から言えば、VKS はありません。ブレジネフ政権のように電話で話すことになると考えてください...

また、IT 部門は通常、災害発生時の主な任務は企業の IT システムの運用を復旧することであると考えています。 ただし、これを行う必要がない場合もあります。 非常に高価なプリンタで紙を印刷するというビジネス プロセスがある場合は、そのようなプリンタを予備として XNUMX 台購入し、故障した場合に備えてその隣に置いておくべきではありません。 紙片に手で一時的に色を付けるだけで十分な場合があります。

IT 内で継続的な保護を構築する場合は、上級管理者や営業担当者のサポートを得る必要があります。 それ以外の場合は、IT 部門内で蛹になったので、一定範囲の問題を解決できますが、必要なすべての問題を解決できるわけではありません。

IT 部門のみが DR 計画を持っている場合は次のような状況になります。

10. テストなし

計画がある場合は、テストする必要があります。 標準に詳しくない人にとって、これはまったく明らかではありません。 たとえば、いたるところに「非常口」の標識が掲げられています。 でも教えてください、防火バケツ、フック、シャベルはどこにありますか？ 消火栓はどこにありますか？ 消火器はどこに設置すればよいですか? しかし、誰もがこれを知っているはずです。 オフィスに入るときに消火器を見つけるのはまったく論理的ではありません。

おそらく、計画をテストする必要性は計画自体の中で言及されるべきですが、これは物議を醸す決定です。 いずれの場合でも、計画は少なくとも XNUMX 回テストされた場合にのみ機能していると見なされます。 上で述べたように、「計画はあり、インフラはすべて準備されています。しかし、すべてが計画通りにうまくいくとは限りません。」という声をよく聞きます。 彼らはそれをテストしなかったからです。 一度もない"。

結論

企業によっては、どのような種類のトラブルがどの程度発生する可能性があるかを把握するために、履歴を分析できる場合があります。 研究と経験は、私たちがすべてから身を守ることはできないことを示唆しています。 遅かれ早かれ、どんな会社にも不幸は起こります。 もう XNUMX つは、今回または同様の状況に対してどの程度の準備ができているか、またビジネスを時間内に回復できるかどうかです。

継続性とは、あらゆるリスクを顕在化させないようにいかに排除するかだと考える人もいます。 いいえ、重要なのは、リスクが現実化するということであり、私たちはそれに備えるつもりです。 兵士は戦闘中は考えるのではなく、行動するように訓練されています。 BCP 計画も同様で、ビジネスをできるだけ早く復旧させることができます。

BCP不要の唯一の設備

イーゴリ・トゥカチェフ
事業継続コンサルタント
計算機システム設計センター
「ジェットインフォシステムズ」

出所： habr.com