前回に引き続き、ＩＴ版のＢＣＰ（事業継続計画）について、お話します。
前回はＲＴＯ、ＲＬＯ、ＲＰＯという判断指標についてお話をしました。今回は、要件定義の流れについて、２つの方法をお話したいと思います。
ＩＴ－ＢＣＰの要件定義の２つの流れ
改めて、一般的な要件定義の流れを説明すると、
1.ＢＩＡの実施（重要業務の特定と影響度の評価）
2.業務のＲＴＯ（目標復旧時間）、ＲＬＯ（目標復旧レベル）設定
3.対象範囲と依存度の把握
4.ＩＴサービスの３指標設定（ＲＴＯ、ＲＬＯ、ＲＰＯ）の設定
5.必要コストの算定と調整
という流れです。経営陣が主体的に関与して、全体的なＢＣＰの中での事業部門を巻き込んでＩＴ－ＢＣＰを考えていく流れです。
この流れは業務プロセスからのアプローチという方法で、事業部門が関与するため、人手の作業による復旧も考慮することができますが、関係者が多いため、調整・定義に時間がかかります。
この関係者を減らし、時間短縮をする方法として、ＩＴサービスの中断・停止によるリスクからのアプローチがあります。流れとしては
1.ＩＴサービスのリスク特定と整理
2.業務プロセスへの影響分析
3.経営への影響分析
4.ＩＴサービスの３指標設定（ＲＴＯ、ＲＬＯ、ＲＰＯ）の設定
5.必要コストの算定と調整
後半は同じような流れですが、前半はＩＴサービスを起点にしている分、対象範囲を絞り込むことができます。また、ＩＴサービス中心で考えるので、ＩＴ部門を中心に進めることができ、比較的関係者を少なくできますが、ＩＴサービス復旧へのハードルを高くあげがちなので、必要コストが高くなる傾向もあります。
２つのアプローチの使い分け
これらの使い分けですが、経営層や事業部門がしっかり関与して全体のＢＣＰを考えながら、その上でＩＴ－ＢＣＰを策定するのであれば、業務プロセスからのアプローチがおススメです。現場の納得感も得やすいですし、人による代替方法も検討できるのでコスト的にも妥当性が増すと思います。
一方で、全体的なＢＣＰがなく、事業部門の関与を最小限にしてＩＴ－ＢＣＰを考える場合、平たく言うとＩＴ部門が中心となってＩＴシステムの継続のための対策や保守運用のコスト算定を軸に考えたいときであれば、リスクからのアプローチで進めるのは有効だと思います。
特に社外の人が関係するサービス（自社提供のＳａａＳや受発注システム等）であれば、自社の内部的要因より外部的要因が重要になるので、よりリスクからのアプローチで進めていきやすいかもしれません。
具体的には実際のシステムの利用者の特定や頻度、そのデータ量といったものがＩＴ部門のほうが把握しやすく、リスクの算定もしやすいからです。
また、リスクからのアプローチでも、ある程度ベースができた段階で、事業部門に関与してもらい、人による代替手段を検討してもらうのもいいです。この場合は、既にベースがあり、リスクが明確になっているので、事業部門も対策のイメージがしやすいからです。
注意すべき点としては、リスクからのアプローチがＩＴシステム主体で評価してしまうと、ＩＴシステムが関与しない業務が漏れ落ちる可能性があるということです。
ＩＴが関与しない現場での業務や対人的な業務に関して検討できないため、対象範囲が狭くなっています。この点を十分留意して、全体的なＢＣＰに展開する場合は追加検討するようにしてください。