ServiceNow
“数値はあるが意思決定が動かない”を解く——ダッシュボード設計と改善サイクル
- 分析活用
- プロセス改善
- 運用高度化

- 目次
1. 問題提起:数字はあるのに、会議が動かない

経営レビューで、「数字は揃っています」という報告から会議が始まる。ServiceNowのダッシュボードにはKPIが並び、レポートも定期的に更新されている。それにもかかわらず、結論は次回へ持ち越される。そんな場面は珍しくありません。
この状況で起きているのは、データ不足ではありません。むしろ、数値は十分にあります。
問題は、それらの数値が意思決定という行為に結び付いていないことです。
どの数字が、どの判断を促すのか。
どのラインを超えたら、誰が決断を引き取るのか。
ここが定義されていないと、数字は「説明する材料」にはなっても、「決める材料」にはなりません。経営にとって重要なのは、可視化そのものではなく、可視化が次の一手を生む構造になっているかどうかです。
2. 現状の誤解・よくある状態:レポートの山と止まる意思決定
指標が多いほど安心できる、は誤解です
経営層としては、見ていない数字がある状態は避けたい。
その結果、指標は増えやすくなります。しかし、指標が増えるほど意思決定が早くなるわけではありません。先行指標と結果指標が整理されていない場合、「まずどこに手を打つか」が見えにくくなります。数字はあるが、優先順位が付けられない。その結果、判断は慎重になり、先送りされやすくなります。
ひとつのダッシュボードで全階層を満たそうとする
現場、管理職、経営層が同じダッシュボードを見る。一見効率的ですが、実際には誰の判断にも最適化されません。
現場は「今日どう動くか」を知りたい。
管理層は「今週どこが詰まっているか」を見たい。
経営層は「成果がどう動いているか」「変化点はどこか」を判断したい。
同じ画面でこれらすべてを満たそうとすると、結果的に誰にとっても判断材料としては弱くなります。粒度と時間軸を分けなければ、ダッシュボードは説明資料に留まり、判断材料になりません。
アラートが鳴るだけで、意思決定が定義されていない
ServiceNowでは、しきい値を超えた際のアラート設定は容易です。
しかし、通知の後に何が起こるかは、人に委ねられているケースが少なくありません。誰が、どの時間内に、どの範囲まで判断するのか。ここが明確でないアラートは、やがて見過ごされます。
重要なのは通知そのものではなく、通知を起点とした意思決定の流れです。
レポートが乱立し、経営数値の定義が揺れる
同じKPIでも、部門によって数値が異なる。算出式や集計条件が違い、会議では毎回定義の確認から始まる。これは統制の問題であると同時に、経営判断のスピードを落とす要因でもあります。
3. 原因分析:KPIのつながり不在、役割不明、閾値の設計不足
KPIツリーがなく、因果が説明できない
多くの組織で、SLA達成率やCSAT(顧客満足度)は見られています。しかし、「なぜその結果になったのか」を即座に説明できないことがあります。理由は明確です。
結果指標と、その原因となる先行指標が構造化されていないためです。SLAは成果であり、操作できるレバーではありません。経営が介入できるのは、その手前にある先行指標です。
誰の意思決定を支えるダッシュボードかが曖昧
ダッシュボードは、全社共通の可視化基盤になりがちです。しかし、意思決定は階層ごとに異なり、誰もが「自分の決断材料が足りない」と感じます。どの判断を、どの立場で支えるのか。設計時点でこれを明確にしないと、可視化は単なる報告ツールに留まります。
閾値を超えた瞬間の責任と裁量が決まっていない
どの数値で、誰が判断を引き取るのか。どこまでを現場判断とし、どこからを管理・経営判断とするのか。ここが決まっていない組織では、改善は属人的になり、再現性を持ちません。
改善がプロジェクトで終わり、運営になっていない
改善会は開いている。しかし、改善項目がバックログとして管理されていない。その結果、議論は振り返りに終始し、戦略的な改善投資の判断につながりません。
4. 解決アプローチ:KPIツリー×役割別ダッシュボード×行動ルール×改善運営

KPIツリーを経営モデルとして設計する
まず、経営として追う結果指標を定めます。SLA達成率、MTTR(復旧までにかかる平均時間)、CSATなどです。次に、それらを動かす先行指標を構造化します。初回応答時間、再割当率、アサイン遅延件数などを結び、因果関係を仮説として明文化します。ここまでできて初めて、数字は「説明するもの」から「操作できるもの」に変わります。
意思決定階層ごとにダッシュボードを定義する
現場は即応判断、管理層は資源配分、経営層は投資と優先順位を決めます。同じKPIでも、見る期間、粒度、強調点を変えることで、意思決定の質は大きく変わります。
アラートを“経営介入点”として設計する
アラートは注意喚起ではなく、意思決定権限が切り替わる合図です。重要度ごとに、誰が・どの時間内に・どこまで決められるかを定義します。この設計が、スピードと統制を両立させます。
改善を定例運営に組み込む
週次では先行指標を見て打ち手を決める。月次では結果指標を見て仮説の妥当性を検証する。改善を「特別な活動」から、経営運営の一部に位置付けます。
レポートを統制し、経営の共通言語を作る
定義と算出方法を統一し、「この数字はここを見る」という唯一の見所を作ります。これが、意思決定のスピードを支えます。
運用成果をビジネス価値に翻訳する
SLA改善やリードタイム短縮を、時間削減、コスト回避、機会損失の低減として示します。数字が、経営の言葉に変わります。
5. 実務ステップ:設計から運用までの進め方
ここまでの考え方を、実務としてどう進めるか。ポイントは、一気に完成させようとせず、設計→試行→定着の順で回すことです。
ステップ1:既存KPIを棚卸しし、KPIツリーに編成する
最初にやるべきことは、新しい指標を作ることではありません。すでに使われているKPIやレポートを棚卸しします。そのうえで、結果指標(SLA達成率、MTTR、CSATなど)と、それを動かす先行指標(初回応答時間、再割当率、アサイン遅延件数など)を分けます。分けた指標を矢印でつなぎ、「どの先行指標が、どの結果指標に効くのか」を言葉で説明できる形にします。このKPIツリーが、以降の判断の軸になります。
ステップ2:役割別ダッシュボードのワイヤーフレームを作る
次に、誰の意思決定を支えるダッシュボードかを明確にします。現場、管理、経営の三面を想定し、それぞれに必要な情報だけを配置します。この段階では、作り込む必要はありません。紙やスライドで、「この画面を見たら、どんな判断をしてほしいのか」を整理します。ここで迷いが減るほど、実装後の修正コストは下がります。
ステップ3:アラートの閾値と行動ルールを決め、ワークフローに落とす
ダッシュボードと並行して、アラート設計を進めます。重要なのは、通知条件よりもその後の動きです。どの値を超えたら、誰が、どの時間内に、どこまで判断するのか。初動、期限、エスカレーション先をセットで決めます。合意したルールは、そのままServiceNowのワークフロー条件に組み込みます。人に委ねず、仕組みで担保します。
ステップ4:週次の改善会でバックログを運用する
改善は定例運営として回します。週次では先行指標に集中し、次の一手を決めます。改善タスクはバックログとして一元管理し、担当、期限、狙う指標を必ず明記します。翌週には効果を確認し、未達の場合は打ち手を入れ替えます。この小さなサイクルを止めないことが重要です。
ステップ5:レポートの標準化と乱立の抑止を進める
並行して、レポートの整理を進めます。定義、算出式、更新頻度、所有者、命名規則をテンプレで統一します。重複するレポートは統合し、「この数値はここを見る」という唯一の見所を固めます。これにより、会議は数字の確認から、判断と意思決定へ移ります。
ステップ6:月次レビューで因果を検証し、設計を更新する
月次では、結果指標を中心に見ます。先行指標との因果は妥当だったか。想定した改善が成果につながったか。必要に応じて、KPIツリー、閾値、行動ルール、ダッシュボード構成を見直します。設計は一度で完成させるものではありません。運用しながら更新する前提で回します。
6. 効果:意思決定が前に進み、“価値実感”が伝わる
KPIが因果で整理され、ダッシュボードが判断別に設計されると、会議は報告の場から意思決定の場へ変わります。改善は属人化せず、再現性のある経営プロセスになります。
7. 結論:数字を“見るもの”から“動かす仕組み”へ

数字を集めること自体は、もはや競争力ではありません。数字を使って、早く、迷わず、決められること。ここに差が出ます。
KPIツリー、役割別ダッシュボード、行動ルール、改善運営。
これらが連動したとき、ServiceNowの可視化は、経営判断を前に進める装置になります。
8. まず始めるチェックリスト
以下は、取り組みを一気にやろうとせず、経営として最低限確認すべきポイントを整理したチェックリストです。
1. KPI設計・構造の確認
- 結果指標(SLA達成率、MTTR、CSATなど)が明確に定義されているか
- それらを動かす先行指標が特定され、KPIツリーで因果が説明できるか
- 「この先行指標を動かせば、どの成果が改善するか」を一文で説明できるか
2. ダッシュボードの役割分担
- 現場・管理・経営で、見るダッシュボードを分けているか
- 経営向けダッシュボードは、詳細ではなく「変化点」「例外」に絞られているか
- 同じKPIでも、時間軸と粒度が立場に応じて最適化されているか
3. アラートと行動ルール
- しきい値を超えたとき、誰が判断を引き取るか決まっているか
- 初動の期限、実施内容、エスカレーション先が定義されているか
- アラートが「通知」で終わらず、意思決定の起点になっているか
4. 改善の運営方法
- 改善項目がバックログとして一元管理されているか
- 各改善に、担当者・期限・狙う指標が紐付いているか
- 週次で先行指標、月次で結果指標を見る運営が定着しているか
5. レポートと指標の統制
- KPIの定義・算出式・更新頻度・所有者が文書化されているか
- 重複レポートが整理され、「唯一の見所」が共有されているか
- 会議が定義確認から始まっていないか
6. “価値実感”の可視化
- 運用改善の成果が、時間削減やコスト回避として示されているか
- SLA改善やMTTR短縮が、経営指標に翻訳されているか
- 投資判断や優先順位付けに使える形になっているか