ディザスタリカバリのコツは製品管理と同じ？：すべてのリスクはみな平等、ではない

製品管理のベストプラクティスは、システムの災害復旧にも役立てられることを発見した。

≫ 2008年10月28日 08時00分公開

[Niel Nickolaisen，TechTarget]

　今日は製品管理のベストプラクティスと、災害復旧／事業継続（DR／BC）にそれがどう当てはまるかについて話をしたい。疑問を感じるだろうか？　この関係は直接的には分かりにくいから無理もない。しかし、あと数パラグラフ読んでもらえば、徐々に納得してもらえる自信がある。

　わたしは空き時間を活用して、わが社の全ビジネス機能（製造、エンジニアリング、会計、ITなど）のプロセス改善に関与している。従業員にプロセス改善の原則について教えるとき説明しようと努めているのは、すべての製品や顧客、プロセスは本来平等ではないということだ。質の高い製品管理は、製品間の不平等が基本になる。例えば、当社のある事業部の製品ラインには2000を超す製品がある。その2000製品のうち、わずか10％のみ（A製品群）で売り上げの80％を上げている。宣伝、販売、製造計画、流通の手段を考えるとき、われわれはこの10％を残る90％の製品とは別扱いにする。これらの製品は需要が高いので、品切れにならないように気を配る。カタログや営業資料ではこの製品を確実に優先している。

　2000製品の残りのうち売り上げの次の15％は、30％の製品で上げている。これはB製品群となる。わが社に必要な製品ではあるが、もし販売や宣伝や製造に問題があったとしても、会社はそれほどの打撃を受けない。残る50％の製品は、売り上げの5％を占める。われわれはこのC製品群を、注文商品として扱っている。わが社としてはC製品は作りたくないので、客がC製品を注文すると、リードタイムを長く見積もり、製品を倉庫に入れて、ほかにも誰かが同じ製品を注文してくれることを祈る。

　これと同じA、B、Cの階層化をITシステムにも適用すれば、DR／BC計画と意思決定を改善できることをわたしは発見した（製品管理とDR／BCとの間には関係があると言った通り）。

　Aシステムは、会社がリスクにさらされる前のほんの短時間しかダウンすることが許されない、リアルタイムのシステムだ。Bシステムは、会社がリスクにさらされる前にもう少し長い時間、数時間から数日の範囲でダウンが許されるシステム。Cシステムは、IT部門以外の誰かが気付くまで長期間ダウンしていても構わないものになる。

　システムをA、B、Cに分類したら、DR／BC計画をそのシステムのランクに合致させる。例えば、当社のDR／BC計画はAシステムの保護と復旧に力を入れている。ホットまたはウォームバックアップサイトを利用する資格があるのはAシステムだけだ。Aシステムはリダンダンシーにも投資する。A、そして恐らくBでは障害につながる点は1カ所でも見つけたら取り除くが、Cシステムでは容認する。

　A、B、C分類の要素はヘルプデスクと対応決定にも取り入れている。もしAまたはBシステムがダウンすれば、直ちにA、Bシステムのバックアップのためリソースを再配分する。たとえそのリソースが優先プロジェクトに割り当てられたものであっても。Cシステムの場合、それはしない。優先プロジェクト完了まで待つことができるからだ。

　システムをA、B、Cに分類することは、IT部門が単独でやることではない。この分類には会社の顧客の協力が必要だ。わたしは通常、DR／BC計画立案の一環としてシステムの階層化に取り組んでいる。リスク管理委員会と共同で、A、B、Cシステムに分類するための基準を定める。基準が決まったら分類する。最初の階層化を済ませたら、定期的な見直しを行って、変更に追い付いていることを確認する。特に、要注意なのはAシステムがBまたはCランクに移った場合だ。

　わたしの発見によれば、この製品管理のアプローチを採ることが、IT部門によるDR／BCの取り組みを最も重要なシステムに集中させるための最善の手段だ。

本稿筆者のニール・ニコライゼン氏は米HeadwatersのCIO兼戦略立案担当副社長。