
目次
重要なERP導入KPIは、プロジェクト期間中は週次、ハイパーケア中は日次でレビューし、それぞれに担当者を置く、少数の指標です。スケジュール遵守、コスト差異、スコープ変更、テスト合格率、データ移行の精度、そして何よりユーザー定着率です。以下に、私が使っている30の指標を、プロジェクト期間中と本稼働後に分けて、計算式と、対応のきっかけとなるしきい値とともに示します。
これは、18か月目ではなく8週目に問題を捉えられるステアリング資料を必要としている、プログラムディレクター、PMOリード、スポンサーに向けた内容です。
あるクライアントは、SAPプロジェクトに「小さな」変更を73件追加しました。ひとつひとつは大したものに見えませんでした。しかし合わせると、5か月の遅延を招きました。スコープ変更の件数を誰も追跡していなかったのです。(心当たりがあるなら、SAPプロジェクトのスコープクリープを避ける方法のガイドで、その対策を扱っています。)
別のクライアントは、スケジュールの早期警告を無視し、1年のプロジェクトが18か月かかりました。小売業のクライアントは、予算の早期警告を無視して突き進み、完了させるためだけに主要な機能を削る結果になりました。
これらは珍しい失敗ではありません。チームが間違ったものを追跡している、あるいは何も追跡していないときに起きることです。
| # | KPI | 測定するもの | 重要な理由 |
|---|---|---|---|
| 1 | スケジュール遵守 | 計画に対するタスク完了の実績 | 遅延が連鎖する最初のシグナル |
| 2 | コスト差異 | フェーズ別の実績支出と予算の比較 | 超過が積み重なる前に捉えられる |
| 3 | スコープ変更の件数 | 承認された変更の件数と影響 | 管理されない変更は、超過の最も一般的な原因 |
| 4 | リソース稼働率 | 計画に対する実働時間、負荷のバランス | 負荷の高すぎる人は、燃え尽きるか、プロジェクトの途中で去る |
| 5 | ユーザー定着率 | 対象ユーザーのうち、システムを実際に使っている割合 | システムが業務に役立っているかを示す唯一の指標 |
| 6 | トレーニングの効果 | 評価テストのスコア、受講済みユーザーの割合 | 本稼働前に、定着の失敗を予測できる |
| 7 | データ移行の精度 | 問題なく移行できたレコードの割合、エラー率 | 新システムの不良データは、クレンジングに何か月もかかる |
| 8 | テスト環境のダウンタイム | テストシステムの計画外停止の時間 | テストでの不安定さは、本稼働時の不安定さを予告する |
| 9 | エンゲージメントスコア | サーベイ結果、主要セッションへの出席状況 | 抵抗が表に出る前に気づける早期警告 |
| 10 | リスク解決率 | 予定どおりにクローズしたオープンリスクの割合 | 洗い出しだけでなく、クローズを測る |
| 11 | パートナーのパフォーマンス | 成果物の品質、マイルストーン達成率 | 初期の成果物を落とすパートナーは、ほぼ確実に後の成果物も落とす |
| 12 | テスト合格率 | 初回で合格したテストケースの割合 | SITで85%を下回るなら、たいていは偶発的な不具合ではなく構造的な問題 |
| 13 | 変更要求の処理日数 | 要求から決定までの日数 | 待ち行列が長いのは、ガバナンスの失敗のシグナル |
| 14 | 予算消化率 | 完了した作業に対する、予算全体に占める支出 | お金と進捗が連動しているかが分かる |
| 15 | コンフィグレーションの進捗 | 計画したコンフィグレーション項目のうち完了した割合 | ここでの遅れは、テストとトレーニングを後ろに押しやる |
| # | KPI | 測定するもの | しきい値と補足 |
|---|---|---|---|
| 16 | システム可用性 | 本稼働後の稼働率 | 99.9%超なら良好。99%を下回ると、ユーザーの信頼の問題になる |
| 17 | レポートとダッシュボードの速度 | 読み込み時間、更新頻度 | 管理者がExcelにエクスポートしているなら、システムは役目を果たしていない |
| 18 | 従業員の生産性 | 本稼働前のベースラインに対する作業時間 | 承認を自動化した流通業のクライアントでは、本稼働後、1日に処理するトランザクションが25%増えた |
| 19 | 一次解決率 | 最初の問い合わせで解決したチケット | ハイパーケアの有効性を測る |
| 20 | サポートチケット数 | オープンのチケット数、平均解決時間 | 30日目前後の急増は、たいていシステムの不具合ではなくトレーニング不足のシグナル |
| 21 | プロセスのサイクルタイム | 受注処理、請求書承認、決算サイクル | 経営幹部が本当に気にする成果 |
| 22 | 在庫精度 | 実地在庫とシステム在庫の比較 | 本稼働後に最も目に見えやすいデータ品質の指標 |
| 23 | 受注充足率 | 新システムで納期どおりに充足した受注 | 業務への直接的な影響 |
| 24 | 収益への寄与 | 新しい機能に結びつく収益の変化 | ビジネスケースの長期的な証明 |
| 25 | コンプライアンス遵守 | 監査指摘、規制上の問題 | 財務、製薬、規制業種で最も重要 |
| 26 | 予測精度 | 予測と実需要の比較 | 計画が使われ、信頼されているかが分かる |
| 27 | ユーザー満足度 | 使いやすさのサーベイ、キーユーザーのNPS | システムを嫌うユーザーは、回避策を作る |
| 28 | プロセス効率 | ベースラインに対するプロセスあたりの時間とコスト | 取締役会に対して投資を正当化できる |
| 29 | 実現した削減額 | ビジネスケースに対する実際の削減額 | CFOは6か月後と12か月後に尋ねる |
| 30 | 投資対効果(ROI) | 純便益を総コストで割ったもの | 通常、12か月後と24か月後に測定する |
最もよく質問される指標です。
- スケジュール効率指数(SPI) = アーンドバリュー ÷ 計画価値。1.0を上回れば前倒し、1.0なら予定どおり、1.0を下回れば遅延です。
- コスト効率指数(CPI) = アーンドバリュー ÷ 実コスト。1.0を上回れば効率的、1.0を下回れば予算超過です。
- スコープ変更率 = (承認された変更 ÷ 当初のスコープ項目)× 100。10%未満なら影響は軽微、20%超なら影響は大きいといえます。
- ユーザー定着率 = (アクティブユーザー ÷ 対象ユーザー)× 100。最初の90日で80%を超えれば良好、60%を下回るなら介入が必要です。
- データ移行の精度 = (問題なく移行できたレコード ÷ 移行を試みたレコード)× 100。本稼働前に98%超が目安で、95%を下回るならカットオーバーを延期すべきです。
SPIとCPIは、アーンドバリューマネジメントから来ています。「アーンドバリュー」を正直に測っている場合にしか機能しません。3週間にわたって90%完了のままのタスクは、その価値の90%を生んではいないのです。
レビューのリズムがないKPIは、飾りにすぎません。設定すべきケイデンスは次のとおりです。
- デリバリー期間中週次のプログラムボードスケジュール、コスト、リスク、テスト合格率、スコープ変更。ゲートのKPIはステアリングコミッティへ
- 1〜30日目日次のハイパーケアレビュー可用性、チケット数、部門別の定着率
- 90日目まで週次の定着レビュー定着率、プロセスのサイクルタイム、チケットのカテゴリ
- 6か月目と12か月目スポンサーとCFOのレビュー生産性、実現した削減額、ROI
| いつ | KPI | レビューする人 | 反映される判断 |
|---|---|---|---|
| デリバリー期間中は週次 | スケジュール遵守、コスト差異、リスク解決、テスト合格率、スコープ変更の件数 | プログラムボード | 再計画、エスカレーション、またはスコープの据え置き |
| 各フェーズゲートで | コンフィグレーションの進捗、トレーニングの効果、データ移行の精度、パートナーのパフォーマンス | ステアリングコミッティ | 合格、条件付き合格、または中止 |
| 本稼働後30日間は日次 | 可用性、チケット数とその推移、部門別の定着率 | ハイパーケアリード | 現場サポートと修正をどこに振り向けるか |
| 90日目までは週次 | 定着率、プロセスのサイクルタイム、チケットのカテゴリ | プログラムボード | 補講トレーニング、コンフィグレーションの修正 |
| 6か月後と12か月後 | 生産性、実現した削減額、ROI、満足度 | スポンサーとCFO | ビジネスケースの承認、フェーズ2のスコープ |
製薬業のクライアントの1社は、各マイルストーンに担当者と、その代理を置きました。以前のSAPの取り組みと比べて、スケジュール遵守が大きく改善しました。月次のレビューで遅れが明らかになる頃には、それはすでに構造的になっています。
ゲートの判断は、カレンダーではなく、証拠に基づくべきです。そして本稼働後3か月目には、回避策がすでに習慣になっているため、定着のための時間は、多くのチームが思うより早く閉じてしまいます。ステアリングコミッティの立て直しが必要なら、その進め方を効果的なSAPステアリングコミッティの作り方で解説しています。
あるクライアントは「小さな」変更を73件追加しました。その後に続いた5か月の遅延は、決して小さくありませんでした。スコープ変更のKPIは、まさにこのパターンが見えなくなる前に止めるためにあります。
RISE with SAPとSAP GROWのプログラムでは、従来のリストがカバーしていないガバナンス上の問いが加わります。追加の3つの指標が役立ちます。
クリーンコアレベルの構成比
SAPは現在、拡張を4段階のクリーンコアレベル、AからDで評価しています。レベルAはリリース済みのAPIだけを使い、レベルDはクリーンではありません。各レベルの拡張が占める割合を、SAPが推奨するABAP test cockpitのチェックを使って追跡してください。
Public Editionでは、設計上、すべてがレベルAです。Private Editionとオンプレミスでは、レベルCまたはDの拡張はすべて負債となり、次のアップグレードで表面化します。Realizeの間、新しい拡張の要求をこの観点で毎週レビューし、レベルCまたはDを承認するたびに、責任者を明確にしてください。
拡張の置き場所が決まっている割合
計算式:(合意済みのレベルと配置場所がある拡張 ÷ バックログ内の拡張の合計)× 100。目標は、Exploreの終わりまでに100%です。まだ誰も置き場所を決めていない拡張が、締め切りのプレッシャーの下で、従来型のモディフィケーションになってしまいます。
SAPとの関係の健全性
RISEのプログラムでは、四半期ごとに定性的なレビューを行います。SAPがインフラと運用を担い、デリバリーにも加わっているためです。プラットフォームに関するエスカレーションは、合意したサービスレベル内で解決されているか。SAPのサクセスレビューは、中身のあるものか、形だけのものか。スコアが低い場合は、たいていチームの準備が整っていないプログラム途中のエスカレーションに先立って現れます。
AIは、指標の周辺にあるレポーティング作業に役立ちます。レビューの代わりにはなりません。
- Joule with SAP Cloud ALM。 SAPはCloud ALMにJouleを追加しました。そのため、チームはステータス抽出のたびに手作業で作らなくても、プロジェクトと運用のデータを自然な言葉で問い合わせられます。
- Power BIのCopilot。 ダッシュボードをもとに、ステアリング資料の要約文のドラフトを作成します。データモデルが整理されているほど、うまく機能します。
- 異常検知。 Power BI、Tableau、SAP Analytics Cloudは、通常のパターンから外れたKPIにフラグを立てられます。リソース稼働率、チケット数、スコープ変更率には有効です。日次の受注件数のように、もともとばらつきの大きい指標には向きません。
AIが解決しないのは、政治的な作業です。ダッシュボードが6週間にわたってスケジュールの遅れを赤で示し続けることもあります。ステアリングコミッティが動かなければ、遅れは続きます。
最も影響の大きいKPIはユーザー定着率ですが、ほとんどのチームが最後に測るのもこの指標です。
ある製造業のクライアントでは、経営幹部がすべてをExcelにエクスポートしていました。大きな危険信号です。データはそこにありました。必要なダッシュボードがなかったのです。私たちはダッシュボードを直し、意思決定にかかる時間を半分に減らしました。
技術的には動いていても、現場で迂回されるシステムは、何も届けていません。チェンジマネジメントの研究もこの点を裏づけています。Prosciの長年にわたる調査では、チェンジマネジメントが優れたプロジェクトは、そうでないプロジェクトに比べて目標を達成する可能性が約7倍高いとされています。
最良のKPIダッシュボードとは、最も網羅的なものではありません。ステアリングコミッティが実際に見る、最小限の指標群で、各行に担当者がいて、赤が2サイクル続いたときの帰結が決まっているものです。KPIの取り組みの大半が失敗するのは、正しいものを追跡しておきながら、無視されるからです。数字がすでに赤になっているときの対処は、SAPプロジェクトを軌道に戻す方法をご覧ください。
ERP導入で最も重要なKPIは何ですか?
ユーザー定着率です。技術的には成功しても、誰も使わない導入は、ビジネス上の価値を何も生みません。ほかのKPI(スケジュール、予算、テスト)は、定着のための条件を守るものです。定着が実際に起きたかどうかを教えてくれるのは、定着率です。
本稼働後1週目から、部門別に追跡してください。特定のチームで定着率が低いなら、たいていはトレーニング不足かプロセス設計の問題を指しており、ハイパーケアの間ならまだ修正できます。
ERP導入のKPIは、どのくらいの頻度でレビューすべきですか?
スケジュール、コスト、リスクは、デリバリー中は週次で見ます。ステアリングコミッティでの月次では遅すぎます。フェーズゲートのKPIは、各ゲートで。運用KPIは、本稼働後の最初の30日間は日次で、その後90日目までは週次です。
SAPのUATでは、どのくらいのテスト合格率が健全ですか?
システム結合テストで初回合格率が85%を上回れば健全です。それを下回る場合は、たいてい個別の不具合ではなく、プロセス設計の漏れやコンフィグレーションの誤りがあります。
85%を下回ったままUATに入るなら、立ち止まって根本原因を直してください。SITが取りこぼしたものを、UATが片づけてくれることはほとんどありません。
スコープ変更率が20%を超えるとは、ERPプロジェクトにとってどういう意味ですか?
プロジェクトが途中で設計し直されているということです。超過と遅延が起こりやすくなります。
数字より傾向が重要です。プロジェクトが成熟するにつれて変更が落ち着くのではなく加速しているなら、ガバナンスが機能していません。承認する変更には、すべてコストとスケジュールへの影響の説明が必要です。それがないなら、スコープは制御を失っています。
RISE with SAPのプログラムに特有のKPIは何ですか?
標準の30に加えて3つあります。拡張のクリーンコアレベルの構成比(AからD)、合意済みのレベルと配置場所がある拡張の割合、そしてSAPとの関係の健全性(エスカレーション、サービスレベル、SAPのサクセスレビューの質)の四半期ごとのレビューです。
ERP導入のROIはどのように計算しますか?
ROI = (純便益 ÷ 総投資額)× 100。純便益とは、システムに起因する測定可能な削減と収益の増加から、新環境の運用コストを差し引いたものです。総投資額には、ソフトウェア、導入、社内工数、トレーニング、データ移行、継続的なサポートが含まれます。
保守的に見積もってください。完全な便益が初年度に出ることはまれです。立ち上がりのモデルを作ります。定常状態の便益の50%を1年目、80%を2年目、100%を3年目以降とします。
ERP導入で予算が超過する主な原因は何ですか?
追跡されていないスコープ変更、品質の問題が遅れて表面化するために計画を大幅に超えるデータ移行、テストで見つかる連携の不具合、開始が遅すぎて本稼働後のサポート負荷を押し上げるチェンジマネジメントです。
1つ目には、週次のコスト差異の追跡と、正式なスコープ管理が有効です。2つ目には、データ品質の早期評価が有効です。3つ目には、現実的なボリュームでの早期の結合テストが有効です。4つ目には、最初からのチェンジマネジメントが有効です。
次のステップ
いまERPプログラムを進めていますか?
この記事が、いま進行中のプログラムに関わる内容だったなら、社内でさらに1週間分析を重ねるよりも、30分の対話のほうが多くの場合ずっと前に進めます。




