
「オペレーショナル・レジリエンス」という比較的新しい用語について、「これは事業復旧と同じものなのか?」、「何が違うのか?」と疑問に思う人は少なくありません。共通点もありますが、ここではその違いについて説明したいと思います。共通点はあるものの、両者がどのように異なるのか、ここで明らかにしてみたいと思います。
「オペレーショナル・レジリエンス」とは、従来の事業復旧(ビジネス・コンティニュイティやIT災害復旧とも呼ばれる)から発展した概念であり、事業が中断された際に復旧できることにのみ焦点を当てるのではなく、事業そのものに強靭性を備えさせることで、中断による影響を最小限に抑え、中断が発生した場合でも組織が業務を継続できるようにすることを目指すものです。平均的な企業は、事業中断によって企業価値の最大10%を失う可能性があることを踏まえ、オペレーショナル・レジリエンスでは、そうした潜在的な影響を軽減するための予防措置に重点を置いています。
従来の事業継続
何十年もの間、世界中の組織では、事業中断後の復旧を支援するための事業継続(BC)体制が整備されてきました。これには、社内の業務プロセス、施設、人材、ITシステムに焦点を当てた復旧計画の策定と検証が含まれます。事業影響度分析(BIA)は、どの社内の業務プロセスやITシステムが企業にとって最も重要であるかを特定するものです。ここで強調しておきたいのは、このアプローチが事後対応的(復旧)であり、かつ内向き(社内の業務プロセスやITシステムなど)に焦点を当てたものであるということです。
事業継続力
この概念は、主に英国の金融サービス業界の規制当局によって提唱されたものです。最近、新たな規制が導入され、世界中の他の規制当局もこれに追随する形で、その影響が世界中に波及しています。「事業継続(Business Continuity)」とは異なり、「オペレーショナル・レジリエンス(Operational Resilience)」は、パンデミック、サプライチェーンの逼迫、地政学的混乱、サイバー攻撃などに起因する混乱に備える上で、組織にとってより効果的なアプローチです。
「オペレーショナル・レジリエンス」の主な構成要素は、その用語自体に表れています。 オペレーショナル (企業の運営方法) レジリエンス (混乱による影響を軽減するための対策を組み込むこと)。これは、事後対応ではなく、事前対応の姿勢です。
もう一つの違いは、その焦点にあります。オペレーショナル・レジリエンスは、企業が顧客に提供する最も重要な製品やサービスを特定することから始まります。これは外向きに焦点を当てたものです。その焦点ゆえに、優先順位や指標は大きく異なる場合があります。最も重要な指標は「影響許容度」、つまり、障害が許容できないとみなされるまでに、顧客や企業自体がどの程度の影響を受けるかという点です。 例えば、オンラインバンキングのポータルサイトがダウンし、顧客が自分の資金にアクセスできなくなった場合、顧客にとってどの程度の期間なら許容できるでしょうか?あるいは、オンラインバンキングのダウンによって企業が収益を失っている場合、企業はどの程度の収益損失を許容できるでしょうか?指標は実際の影響、この例ではドルやセントという具体的な数値で表されます。この分析は、単にオンラインバンキングがダウンした際の復旧計画を策定するだけとは異なるアプローチを導き出します。 同社は、オンラインバンキングがダウンすることのないよう、はるかに積極的な対策を講じていくことになるでしょう。
これまで、「事業復旧」と「オペレーショナル・レジリエンス」の違いについて、いくつかの例を挙げてきました。以下に、その違いをまとめた表を示します。
| | 事業・IT復旧 | 事業継続力 |
|---|---|---|
| 目的 | 混乱した状況の回復に注力する | 組織全体のレジリエンスの構築に注力している |
| ビジネスへの影響分析 | 社内の業務プロセスの重要度を特定することに注力している | 顧客に提供される重要な製品やサービスの特定に重点を置いている |
| 指標 | 復旧時間目標(RTO)と復旧時点目標(RPO) | 影響許容度とは、例えば次のようなものです。 :当社の製品やサービスが中断された場合、顧客はどの程度の影響まで許容できるか。 :当社の製品やサービスが中断された場合、どの程度の収益損失を許容できるか。 |
| リスク管理 | BCMチームが大まかなリスク分析を行う | リスク管理部門との連携は不可欠であり、これにより全社で統一されたリスク対応方針が確立されます。これはしばしば「統合リスク管理」と呼ばれます。 |
| テスト | 通常、復旧計画が妥当かどうかを確認するための手順説明で構成される | どのような問題が発生しうるか、またその際にどのように対応すべきかについて、包括的なシナリオテストを行う。どのような運用上の措置が講じられているか、あるいは講じる必要があるか。 |
| 依存関係 | ビジネスプロセス、ITシステム、あるいは施設のいずれかに焦点を当てます。時には、それらの相互依存関係を考慮することもあります。 | 顧客に提供する製品・サービスを起点として、その提供に関わるビジネスプロセス、システム、人材、データ、施設、および第三者を特定し、この「バリューチェーン」全体にレジリエンスを組み込む。 |
| 第三者 | 各部署が独自の復旧計画を策定していることを確認してください | サードパーティの影響許容度は、当社のそれと一致していなければなりません。彼らは前述のバリューチェーンの一環であり、当社と同等の回復力を備えていることを確認する必要があります。 |
「大した違いはない」と言う人もいるかもしれませんが、この分野で過去30年間キャリアを積んできた私としては、これはまさに進化であると言えます。現時点では規制に端を発する話題ではありますが、これはあらゆる組織が採用すべきベストプラクティスです。
詳細については、「Archer Operational Resilience」に掲載されている資料をご覧ください。Archerの専門家にご相談をご希望の場合は、弊社までお問い合わせください。










