事業継続計画（Business continuity planning、BCP）

BCPやBCRPは、ITシステム設計から製造と試験、導入後の運用と同じ考え方です。

【おさるさんも考えるBCP】

BCPやBCRPは、システム管理ツールでは大規模なものになります。

事業継続計画（Business continuity planning、BCP）について

★事業継続計画の考え方（現在、整理中です出版物を出せるようでしたらご案内致します。）
　１．恒久的な継続
　２．メイン事業から他の事業へのシフト
　３．事業の縮小
　４．事業の廃止、撤退
　　　事業継続計画の中に、リスクレベルのトリガーで廃止、撤退を入れる必要がある。

■「想定外」を乗り越える、震災後に見えたBCP
▼システムは必ず止まる
http://itpro.nikkeibp.co.jp/article/Active/20120702/406746/?act05

★世界経済リスク(政治リスク)や天災リスクなど、2011年から2012年の現在に必要なものではないでしょうか。
　事業継続計画の範囲を定義する上で、2012年現在で考慮する必要があると思います。

「競争的優位性と価値体系の完全性を維持しながら、組織が内外の脅威にさらされる事態を識別し、効果的防止策と組織の回復策を提供するためハードウェア資産とソフトウェア資産を総合する計画」のこと。
事業継続と復旧計画（BCRP）とも呼ばれる。

BCPマニュアル開発は次の5つのフェーズを持ちます。
・分析
・ソリューション設計
・実装
・テストと検収
・維持、修理と運用
上記のリストは決定的なものではなく、事業自身の計画／マニュアルに含まれるその他の考慮点がいくつかある。

【リスク識別マトリックス】
・役割と責任 （名前は残されるがタイトルは含まれることを確認する、例えばHR Manager）
・最大リスクと緩和戦略の識別
・資源配置のための考慮点、例えば大規模組織の技能マトリックス
インターネット上でのBCPマテリアルの多くは、BCPソリューション開発のためのフリーベース・サービスを提供するコンサルタントによってスポンサーされます。
しかし基本チュートリアルは、正しくモティベートされた組織のためのインターネット上で自由に利用可能。

【分析】
BCPマニュアルの開発における分析フェーズは、影響分析、脅威分析、及びBCP計画の要求ドキュメント化に帰着する影響シナリオから成る。

【影響分析】
影響分析（事業影響分析、BIA）は組織機能／活動の重要（緊急）と非重要（非緊急）間の違いに帰結する。
ある機能は、もしその組織の結果的な被害の利害関係者への影響が受け入れられないと考えられるとき、重要と考えることができる。
混乱の受入れ可能性の認識は、適切な事業あるいは技術回復ソリューションを確立し維持するコストによって変更することができる。
ある機能はまた、法律によって決定されたなら重要と考えられるかもしれない。それぞれの重要な（スコープ内）機能 のため、次の2つの値が割り当てられる。
・回復ポイント目標（英語版）(RPO) - 回復されるデータの受入れ可能な待ち時間
・回復時間目標（英語版）(RTO) - その機能を復元するため受入れ可能な時間の量
回復ポイント目標は、各活動のための最大許容可能データ損失を超えないことを確かめねばならない。
回復時間目標は、各活動のための最大許容可能混乱期間（英語版）(MTPD)が超えないことを確かめねばならない。
次に、影響分析は、各重要機能のための復旧要求に帰着する。復旧要求は下記の情報から成る。
・重要機能の復旧のための事業要求
・重要機能の復旧のための技術要求

【脅威分析】
復旧要求の定義の後、可能性ある脅威の文書化が特定災害に固有な復旧ステップを詳細化するため推奨されます。
幾つかの一般的脅威は以下を含む。
★世界経済（円と外貨のレート）
★政治情勢（厚生、外交、経済産業など）
・疫病
・地震
・火災
・洪水
・サイバーテロ
・サボタージュ（内外の脅威）
・ハリケーン又は大きな嵐
・停電
・テロリズム
・窃盗（内外の脅威、重要な情報及び物品）
・基幹システムの偶発的故障
上の例にある全ての脅威は、共通の影響（組織インフラへの被害の可能性）を共有する。
その影響は純粋に人間として考えられ、技術とビジネスソリューションで緩和されることもある。
しかしながら、もしこれら復旧計画の裏にある人間が災害によって影響を受けるとすると、プロセスは失墜する。
2002-2003年のSARS発生の間、ある組織はスタッフを別々のチームにグループ化し、そのチームごとの災害の潜伏期間を均等化するため、輪番周期で、1次及び2次作業サイト間で交代させた。
その組織はまた、勤務時間及び非勤務時間を問わず、相手チームメンバー間の対面的接触を禁止しました。
そのような分離によって組織は、もし契約されたチーム又は災害に露出した人物がいても、政府支持の防疫対策の脅威に対する彼らの回復性を増大させることができた。
洪水からの被害はまた固有な特徴を持つ。
もし（例えば、配管の破裂の出来事で）、事務所環境が汚染されていない淡水で浸水したなら、装置は徹底的に乾燥すればまだ機能する可能性を持っているからである。

【影響シナリオの定義】
潜在的な脅威定義の後、事業復旧計画の基盤を形づくる影響シナリオの文書化が推奨される。
一般に最も広範囲に及ぶ災害あるいは混乱の計画化は、ほとんどすべての小規模問題が大規模災害の部分的要素であるように、より小規模問題を計画する方が望ましい。
「ビル喪失」のような典型的な影響シナリオは、すべての重要な事業機能、及びあらゆる潜在的脅威からの最悪の潜在的な結果を包括する。
事業継続計画は、もし組織が一つ以上のビルを保持するなら、追加的影響シナリオもまた文書化することができる。
たとえば、あるビルの特定のフロアの一時的あるいは永久的喪失のためのシナリオのような、その他のより特定な影響シナリオもまた文書化することもできる。
組織は時には、一つの現場から他に移動するため必要なスペースを低く見積もります。
現場を移動することは問題を持たないため、組織はそれらを計画段階で考慮することが不可欠である。

【復旧要求ドキュメント】
分析フェーズ完了の後、事業と技術の計画要求は実装フェーズを始めるため文書化される。
良い資産管理プログラムは、これへの大きな援助となり、資源の素早い利用性の識別と再配置可能性を可能にし得ます。一つのオフィスベース、情報技術集約的事業のため、計画要求は、ICE（英語版）データとしてクラス化される以下の要素を網羅することができる。
・2次的場所における、一時事業所の外で求められる固定あるいは共用のいずれの、机の種類と数
・復旧に係わる個人の連絡先と技術的詳細を伴う努力
・重要な事業機能のため2次的場所の机から要求されるアプリケーションとアプリケーションデータ
・ワークアラウンド解決のマニュアル
・アプリケーションに許される最大停止時間
・プリンター、コピー機、ファックス、電卓、紙、ペン等のような周辺機器要求
生産、配送、倉庫などのその他の事業環境は、これらの要素を網羅する必要があるが、混乱の出来事に続く管理する追加的課題を持つ。

┏━━━━━━━━━━━━━━━━━━━━━━━━┓
┃┏━━━━━━━━━━━━━━━━━━━━━━┓┃
┃┃┏━━━━━━━━━━━━━━━━━━━━┓┃┃
┃┃┃システム化の要件　　　　　　　　　　　　┃┃┃
┃┃┗━━━━━━━━━━━━━━━━━━━━┛┃┃
┃┗━━━━━━━━━━━━━━━━━━━━━━┛┃
┗━━━━━━━━━━━━━━━━━━━━━━━━┛
【ソリューション設計】
ソリューション設計フェーズの目標は、影響分析ステージからの主要な2つの要求にこたえる最もコスト効果的な災害復旧（★経済や政治も含む）ソリューションを識別することである。
ITアプリケーションのためにこれは次のように共通に表現される。
１．最低のアプリケーションとアプリケーションデータ要求
２．最低のアプリケーション及びアプリケーション・データが利用可能にならなければいけない時間フレーム
災害復旧計画はまた、例えば、ハードコピー形式での情報の保存、技能スタッフの管理、あるいはプロセスプラントに組み込まれた技術の復旧のような、ITアプリケーション以外の領域にも要求される。
このBCPフェーズは、ディザスタリカバリ方法論とオーバーラップします。
ソリューションフェーズでは以下を決める。
・危機管理コマンド構造
・2次作業サイトの場所（必要な場合）
・1次と2次作業サイト間の電信アーキテクチャ
・1次と2次作業サイト間のデータ複製方法
・2次作業サイトで要求されるアプリケーションとソフトウエア
・2次作業サイトでの物理的データ要求の種類

【実装】
実装フェーズは単純で、ソリューション設計フェーズで識別された設計要素を実行することです。
ワークパッケージ『テスト』は、ソリューションの実装期間中に行われることもあるが、ワークパッケージ『テスト』は組織的テストのところでは行われない。

【テストと組織的受入】
テストの目的は、事業継続ソリューションが組織の復旧要求を充たす組織的受入れに到達することである。
計画は、不十分あるいは不正確な復旧要求、ソリューション設計、あるはソリューション実装エラーのために失敗する場合がある。テストは以下を包括する。
・危機指令チーム呼出しチーム
・1次から2次作業場所への技術スイングテスト
・2次から1次作業場所への技術スイングテスト
・アプリケーションテスト
・ビジネスプロセステスト
最低限テストは、半年度あるいは年度スケジュールで一般に実行されます。初期テスト段階で識別された問題は、維持段階にロールアップされ、次期テストサイクル中に再テストすることができる。
英国規格協会（BSI）によって発行された2008年の本『Exercising for Excellence』で危機ソリューションは、事業継続計画をテストする際採用される次の3つの試験のタイプを識別した。

【単純試験】
単純試験はしばしば「デスクトップ」あるいは「ワークショップ」と呼ばれます。
それは典型的に、おそらく5～20の少人数が係わり、事業継続計画の特定の局面、あるいは特定の主題領域（例えば、人的資源、情報技術あるいはメディア）に集中して行われる。
しかしながら、単純試験の美しさは、事業の様々な領域から完全なチームを容易に対応させることができることである。その数は、そのロジスティックとともに増大されることもあるが、その目的は変わらない。
あるいは、全体チームが参加する必要よりむしろ、複数チームから一つの代表が係わることができる。
それは、仮想世界の環境や日々の資源以外の必要性の提供が伴われない。
一般的に、参加者は単純なシナリオを与えられ、その後会社のBCPの特定局面を議論するため招かれる。
例えば、作業時間外に発見された火災では、「手順から現在の呼び出しはなにか」、「どのように事故管理チームが活性化されるか」、「どこにこれが合致しないか」、「現在の文書化された手順はすべての不測の事態をカバーするか」などである。
それはおそらく、3時間以内で最終化され、それぞれ異なったテーマに集中した2つないし3つのセッションにしばしば分離される。
この場合、2つないし3つの異なったシナリオのいずれもが使われ、一つのシナリオは、アドレスされるべきニーズのテーマを導入するため進歩的に開発される。
実時間のプレッシャーは、単純試験の通常の要素ではない。
質問は、ファシリテーターが議論が生産的で出来事の目的に対して適切であることを確かにするため、時間に先だって作業されることが必要である。

【中間検査】
中間検査は、常に仮想世界内で実行され、通常は複数の部門、チーム、あるいは専門分野で同時に行われる。
それは一般的にチーム間のBCPを促す複数の側面に集中する。
中間試験のスコープは、一つのビルを共有する一つの組織の少数のチームから、分散した場所の複数のチームの広範囲におよぶ。
試みは実行可能と同じ程度の現実的環境を作り出すべきで、参加者の数は現実的状況を反映すべきである。
要求される現実性の度合いに依存し、それは、シミュレートされたWebサイトとともに、シミュレートされたニュース放送を生じるのに必要となる。
中間試験は数日間にわたって取り組まれますが、通常2～3時間で最終化されるでしょう。
それらは典型的に、情報を提供し行動を促すことの試験を通してプリスクリプトされた射出で導かれたシナリオセルに関わる。

【複合試験】
複合試験はおそらく、可能な限り少数の境界として持つことを目的として定義することが困難である。
それはおそらく中間試験の一部とより多くの局面を含む。
試験の要素は、必然的に仮想世界内で残されなければならないが、しかし全ての試みが現実性達成するためになされるべきである。
これは、災害復旧（DR）サイトの、通知なしの起動、実際の避難、及び呼び出しを含む。
開始時間とカットオフ時間が同意されなければならない一方で、もし出来事がリアルタイムでそれらのコースを実行することを許されるなら、試験の実際期間は未知となる。
もしそれが期待される45分の代わりにDRサイトを得るため2時間が必要なら、試験はこれを扱うため、十分に柔軟でなければなりません。
もし主要なプレイヤーが対応できないなら、代理者がそれに備えなければなりません。

【定義】
これらの定義は、利用可能な試験のタイプについて幅広いガイダンスを提供しますが、それは考慮すべき「エッジのぼかし」があり得ることを認識すべきである。
それは、異なった次元を追加することによって、復旧サイトで単純試験を実行することは可能であるが、これは必ずしも中間試験をするため必要ではない。
分類に関わらず、試験の重要性は、その定義された目的を達成することにあるのである。

【維持】
BCPマニュアルの維持は、3つの周期的活動に分解される。
・最初の活動は、役割が対応と復旧において重要と認識される個人のための自覚と特定のトレーニングのため。
　全てのスタッフに次々現れる、マニュアルにおける情報の確認である。
・2番目の活動は、復旧オペレーションのための確立された技術的ソリューションのテストと検証である。
・3番目の活動は、文書化された組織復旧手順のテストと検証です。半年あるいは1年の維持サイクルが一般である。

【情報更新とテスト】
全ての組織は時間を超えて変化します。そのためBCPマニュアルは、その組織に適切さを保持するため変化しなければなりません。
一旦データ精度が検証されたら、通常ツリーと呼ばれるテストが、連絡先データの精度と同じように、通知計画の効率を評価することため実行される。
マニュアルで識別され更新されるべき変更の幾つかのタイプは以下を含む。
・スタッフ変更
・スタッフ人材
・重要なクライアントと彼らの連絡先の詳細の変更
・重要なベンダー／サプライヤと彼らの連絡先詳細の変更
・新規、閉止、又は基本的に変更された部門のような部門的変更
・会社の投資ポートフォリオとミッション表明における変更
・サプライヤ経路における上流／下流の変更

【技術ソリューションのテストと検証】
進行中の維持の一部として、あらゆる特別課された技術の配備は、機能性のためチェックされねばならない。
幾つかのチェック項目は下記を含む。
・コンピュータウイルス定義の配布
・アプリケーション・セキュリティとサービスのパッチの配布
・ハードウエア運用性のチェック
・アプリケーション運用性のチェック
・データ検証
・データ・アプリケーション

【組織的復旧手順のテストと検証】
時間を超えての作業プロセスの変更として、事前に文書化された運用的復旧手順はもう適切ではないかもしれない。
そのいつかは以下を含む。
・文書化された重要な機能のため、全ての作業プロセスか？
・変更された重要な機能の実行において使われるシステムを持っているか？
・文書化された作業チェックリストはスタッフのため有意義で正確か？
・文書化された作業プロセス復旧タスクと支援する災害復旧インフラはスタッフにあらかじめ決められた復旧時間目的内で復旧することを可能にするか？

【テスト不具合の取り扱い】
この論文に含まれるダイアグラムで推奨されるように、テストと維持フェーズと影響フェーズ間の直接的関係がある。
スクラッチからBCPマニュアルと復旧インフラを確立するとき、しばしばテストフェーズ中に見つけられた課題は、分析フェーズに再度紹介されなければならない。

【ロジスティクス計画】
BCPで使われるロジスティクス計画は、事業継続（英語版）と呼ばれる。
BCPの意図する効果は、実行中の状態及びどのように事業を行うかを統治する方法論である、事業継続を確実にすることである。
BCPを策定し、運用し、訓練し、継続的改善する取組みを事業継続マネジメントという。
平易な言葉では、BCPは災害時に事業を継続する方法について定めている。
典型的な事態としては、ビル火災のようなローカルな事態、地震や洪水のような地域的な事態、または世界的伝染病の流行のような国家的事態を含む。
しかし、そのような事態に限らない、供給元の喪失、重要なインフラ（機械またはコンピューティング／ネットワーク資源の主要な部分）の喪失、または窃盗や破壊の結果のような、事業が依存しているあらゆる事態を含み、事業喪失の可能性を引き起こし得るあらゆる事態が考慮されなければならない。
このように、リスク管理はBCPの一部として取り入れられなければならない。

上記の文面は「ウィキペディア」事業継続計画を引用させて頂きました。「ウィキペディア」事業継続計画