前回に引き続き、ＩＴ版のＢＣＰ（事業継続計画）について、お話します。
前回は現状確認や基本方針についてお話しました。対象となるITサービスに対する業務の依存度やインフラ的なITといったITサービスそのものの影響範囲、そのサービスが中断することによる業務への影響やリスクを評価するといったお話でした。
ＲＴＯ、ＲＬＯ、ＲＰＯ
この中で目標となる判断指標については、少しボリュームがあったので割愛していました。今回はそのお話をします。重要指標は３つでＲＴＯ、ＲＬＯ、ＲＰＯといいます。
ＲＴＯは目標復旧時間でいつまでに復旧させるか、ＲＬＯは目標復旧レベルでどの程度まで普及させるか、ＲＰＯは目標復旧地点でどの時点のデータを復旧させるかです。ITサービスもしくは業務をいつまでにどの程度普及させるか、そのためのデータはどの時点のものを利用するかということです。
ここで少しイメージしづらいＲＰＯを例で説明するとデータ破損が発生したとして、ＲＰＯを１時間前と設定すると、データ破損から１時間前のデータを復旧させて、１時間の業務は再入力等でカバーするといった考えです。
ランサムウェア攻撃等になるとデータそのものがネットワーク経由で感染している可能性もあるため、バックアップもネットワークでつながっていないリムーバルメディアである程度期間のたったものでないとリスクが出ます。そういう場合はＲＰＯを長くとる必要があります。リスクに応じて、指標を検討する必要があります。
業務とＩＴサービスのＲＴＯ、ＲＬＯ
また、ＲＴＯに関しては、業務の目標復旧時間をメインに設定することが多いので、ＩＴサービス自体はＲＰＯのデータ普及とその時間分のデータ再入力を含む作業時間を考慮して、さらに短い時間で復旧する必要があります。
別の言い方をすると業務に対するＲＴＯとITサービスに対するＲＴＯを分けて考える必要があるということです。
同様にＲＬＯも業務レベルとITサービスのレベルを複合的に考える必要があります。ITサービスへの依存度が低い、具体的に言うと紙や口頭もしくはエクセル等のITツールが代替手段で利用できる場合は、業務でのＲＬＯを少し低く設定することでＲＴＯを短くすることができます。
この際のITサービスのＲＬＯは独立して考えるのか一部の機能やサービスと業務レベルの連携を判断して行うかで異なってきます。
例えば、顧客管理システムが利用できなくなり、顧客管理業務における顧客情報の追加、修正、削除等ができない場合、現時点での顧客情報を参照できるレベルにまで普及できれば、顧客番号や会社番号等のキーとなる情報を見ることができます。
そのため、追加、修正、削除情報を簡易なエクセルシードに記載できるようにしておけば、業務復旧は可能になります。実際には、その顧客情報を利用して、請求や出荷等を処理することが多いので新しい情報を他のシステムへ転記もしくは代替手段でカバーしないと全体的な業務の復旧はできません。段階的に復旧を考える必要があります。
独立性か一貫性か
業務情報、特にマスタデータの一元管理は生産性向上やデータの一貫性の維持等で不可欠だと思いますが、独立性が少ないとマスタデータが業務に影響する範囲が大きくなります。一元管理がアダとなるケースも少なくありません。
意図的にシステムを分割して、冗長性を持たせる（システム間でマスタデータは定期的に同期させながら、個々のシステムでのマスタデータが独立している）のも実はＩＴ－ＢＣＰでは一つの対策になります。別の言い方をするとバラバラなシステムもＩＴ－ＢＣＰでは普及に有利に働く場合があるということです。
３つの指標（ＲＴＯ、ＲＬＯ、ＲＰＯ）を業務面、ITサービス面の２つの視点から考えることが基本方針策定の重要なポイントになります。