なぜこの見せ方なのか。ケイパビリティ × システムの可視化が意思決定を変える理由。
このビューの目的: 新規IT投資の審査時に、対象ケイパビリティに既存システムがあるかを確認する
ケイパビリティとシステムを紐付けていない企業では、事業とITがつながっていない。そのため、事業戦略を変えたときにITへどれだけ影響があるのかがパッと分からない。
シンプルな例を挙げる。給与計算（ペイロール）のシステムを刷新しようとして「SAP SuccessFactorsを使いたい」という話が出たとする。このとき、グループ会社や各リージョンの企業が今どのシステムをどれだけ使っているのかが目に見える形になっていなければ、どう統合していくかの議論は担当者の勘と経験に頼るしかない。勘と経験だけでは、グローバル規模の標準化はやっていけない。
ケイパビリティ（業務機能）を軸にシステムを棚卸しし、「どの業務に、どの区分のシステムが、いくつあるのか」を一覧できる状態を作ることが本ダッシュボードの目的である。
システムの分類軸は、新規/既存、CapEx/OpExなど様々にありうる。その中で本ダッシュボードは「グローバル標準にあるのか、ローカルなのか」「レガシーとして収束する予定があるのか」という区分を採る。標準化の進捗と今後の方向性が一目で分かる、最も分かりやすい基準だからである。参照モデルの分類をそのまま使うのではなく、実務で判定に迷わない粒度まで単純化した4区分である。
業務そのものがグローバル業務かローカル業務かによって「あるべきシステム」は変わる。グローバル業務にグローバル標準システムがなければギャップであり、ローカル業務にグローバルシステムが混在していれば過剰である。
この「業務のG/L」を決めるのは、各サービスのオーナーである。ネットワークならネットワークのオーナー、セキュリティならセキュリティのオーナー、人事なら人事サービスのオーナー。ITサービスのカテゴリごとにオーナーを立て、そのオーナーが自分の領域の業務区分を決める。ダッシュボードはその決定と実態のズレを機械的に判定して見せる。
ローカルシステムが存在する「仕方がない理由」の大きな3つを挙げたものである。他にも理由はありうるが、まず分かりやすい3つに分類することで、理由ごとに打ち手が変わることを示せる。法規制ならローカライズ対応の確認、グループ会社独自ならM&A後の統合ロードマップ、業務固有なら要件の汎用化検討、という具合である。
一番の利用場面は投資判断のときである。新規投資の申請が来たとき、そのケイパビリティに既にシステムがあるのか、標準があるのに別のものを入れようとしていないかを確認する。
次に、投資判断の後、次年度の投資計画を立てるタイミング。ギャップ（標準がない業務）と過剰（重複投資）の一覧が、翌年度に何へ対応すべきかの出発点になる。
このような解説が 02（SaaS Portfolio Map）・03（Infrastructure Stack）・04（Dependency Map）にも付属します。