コラム
EPM・CPMを導入する際に陥りがちな落とし穴とは？【ウェブセミナー】
財務的な側面を中心に過去の蓄積データから予算管理や財務管理などを手がけ、
経営の未来の意思決定を支援する経営管理手法「EPM・CPM」。
経営環境が目まぐるしく変わる現代で、企業の業務推進になくてはならない存在になりつつあります。
一方で、計画の遅延や頓挫により、EPMとCPMの導入に苦労したほか、
EPMとCPMの導入後に期待通りの成果を得られかったというケースは少なくありません。
そこで、プライマル株式会社は今回、導入時の課題解消を目的に、オンラインセミナー
「EPM／CPMが当たり前の時代だからこそ、導入時における陥りがちな落とし穴とその打ち手」を開催しました。
経営コンサルティング会社の株式会社クニエ（東京都千代田区）でマネジャーを務める稲田俊彦氏が、講師を担当。
EPMやCPMをはじめとした業績管理ツールの導入時に陥りがちな落とし穴と、落とし穴に対する対策を紹介しました。
目次
01. 会計を経営の予測・分析に生かす
クニエ 稲田：
昨今のEPM・CPMの期待への高まりという観点では、業務管理と財務計画の立案、財務データの分析を行う
FP＆A（ファイナンシャルプランニング＆アナリシス）という言葉が広まっています。
その背景にあるのは、実績集計そのものは効率的に済ませ、
将来予測に注力する予測・分析中心にシフトしていきたいという考え方があります。
これまでの企業経営では、実績を正しく記帳し決算を行う実績集計に重きが置かれていました。
そこから、予測・分析中心にシフトし事業の将来予測に生かすという流れに変わって来ています。
別の見方をすると、これらの動きは、伝統的な経理組織から変わっていこうとする取り組みでもあります。
つまり、実績集計に疲弊したり、決算期に残務に追われたりするトラディショナルな組織から、
元気なFP＆A部門として経営に資する情報を提供する組織に変わっていこうという訳です。
これらが現在起こっている業務と組織の変化になります。
02. EPMシステムの進化は3つのステップ
一方で、EPMのシステム面の変化は、大きく分けて3つの段階があると思います。
この3つのステップは、エクセルベースでの管理を手がける第一段階、
EPMシステムを活用する第二段階、そしてさらなる進化の位置付けとしての第三段階です。
各ステップをざっくり述べると、
第一段階は、エクセルのファイルが散財しており、1つのデータ化がなされていないだけでなく、
最新のデータを即座に特定できない課題が発生しがちです。
さらに、集計・分析のプロセスもすべてエクセルでの手作業となっています。
これにより、経年比較する場合でも、ファイルが散財しており、別ファイルを参照せざるを得ないといった課題が発生します。
とにかく属人的で非効率というのが、第一段階の特徴です。
第二段階は、One、reliable dataという信頼できるデータが一カ所に統合されている環境を実現しています。
このため、システム上のデータが一元管理されていることから、
経年比較や予実比較に耐えうるような大量データの保持も可能になっているのです。
加えて、集計の粒度や分析の指定をすれば、データが返ってくる環境を構築しています。
第三段階は、組織業務の姿とバランスの取れた環境ですが、今回は割愛させていただきます。
以上により、企業の会計分野では、実績集計中心から予測分析中心に変わっているのです。
にもかかわらず、システムは、第一段階のエクセルベース管理を行っている企業も少なくありません。
業務のレベルは、予測・分析中心になっていますが、システムの方がまだ第一段階というギャップが生じているのです。
これを解消するためには、システムを第二段階に持っていかねばなりません。
このような背景もあって、EPMとCPMに期待が高まっているのではないかと思います。
これらを踏まえて、EPMとCPMのシステム導入の各フェーズにおける落とし穴とその打ち手を考えたいと思います。
EPMとCPMのシステム導入に当たり、落とし穴は、要件定義と構築、教育、稼働後の4フェーズで発生します。
図を見てわかるように、落とし穴の発生を未然に防ぐため、それぞれのフェーズで、
①肥大化しない要件検討 ②体系的な要件整理 ③システム構築アプローチ ④エンドユーザーへの展開 ⑤本当の意味での定着化
この5つの打ち手を実行する形となります。
03. データアプローチでの要件検討を行い、システム要求の肥大化を防ぐ
まず要件定義で発生しやすいのが、現状の仕組みの再現や個別最適を求めることから、
新システムへの要求が過大に膨らむといった課題です。
例えば、現行のシステムは全てエクセルで管理しており、入力用や加工用、集計用ピボットといったファイルを、
統合したいファイルにデータをコピー・リンクするという形式を取っていたとします。
非常にアナログ的なため、新システムへの要求が高まります。
すると、データのインプットでは、業務効率を求めるがゆえ、本質的なデータとは関係のない、
コメント機能など入力機能が求められるほか、データのプロセス（処理）では、
今できている現行のシステムを全て自動化するという要求が湧きます。
さらに、アウトプットでは、個々のレポート要件に応じた個別最適化によって、
レイアウトが少し変わるだけで別レポートが完成するといった高度なものになります。
こういった要求が膨らんだ時にどうすれば良いでしょうか。
重要なのは、現行機能からのアプローチではなく、
データアプローチでの要件検討を行い、システムの肥大化を防ぐことです。
より詳細に述べると、One data、Reliable dataをベースに、
細かいデータを求めすぎないといったクライアント側の意識の変革から取り組む必要があると思います。
具体的には、インプット機能で、あくまでも標準のデータ取込口を導入し、
入力手前のデータ加工まではユーザー対応に任せます。
プロセスでは、システムがやることと人がやることの明確化、役割分担を図り、ブラックボックス化を防ぎます。
最後のアウトプットは、汎用的なデータ抽出機能を用意し、
抽出後のデータ加工、レイアウト調整はユーザーの手元でやってもらうといった
仕組みの変化が必要となるでしょう。
信頼できるデータは、システム上にあるため、
機能は専用のデータ抽出機能を用意するに留める工夫が求められるとも思います。
以上をまとめると、この課題では、伝統的な機能アプローチではなく、
信頼できるデータアプローチを検討し要件・システムの肥大化を防いで解消するという形になります。
04. まとまった要件定義書を作成するため、検討事項一覧に基づくセッションを
続いて、2つ目の課題です。
前回と同じように、要件定義のフェーズで起こる課題は、
要件定義セッションを何度もプロジェクトメンバー間で重ねたにもかかわず、
最終的に完成した要件定義書の内容に苦しむといったケースですね。
なぜこういった問題が発生するかと言うと、要件定義セッションに向けては書類作成が多く、
セッションの開催までに作成が間に合わないといったケースが考えられます。
導入ベンダーが急場しのぎのセッション資料を完成させることで、
要件定義セッションに間に合わせているため、不十分な要件定義セッションとなってしまうのです。
すると、セッションに参加したクライアント側は、
資料はどこがポイントで何を決めれば良いかわからないといった状態になってしまいます。
このような状況が続くため、要件定義フェーズの終盤になり、
要件定義書をまとめる段階でも、最後までセッションに追われ、取りまとめる時間がありません。
結局、急場しのぎのセッション資料をそのまま束ねて終了となります。
当然ながら、検討過程の残骸や首尾一貫しない記載が残る要件定義書が完成してしまうのです。
すると、クライアント側での要件定義レビューでは、決まったことが書かれていなかったり、
レビューが読みにくかったりする問題が発生してしまいます。
そして、クライアント側は、このまま構築フェーズに入って良いのか、不安を覚えます。
そうした課題を解決するためには、検討事項一覧に基づいてセッションを行い、
体系的に要件定義書をとりまとめることが重要です。
この過程で大切なのは、検討事項一覧を用いた台帳管理です。
この台帳はすべての検討事項を網羅的に管理しており、検討領域ごとの検討事項も体系的に整理しています。
例えば、プロジェクトの目的のほか、インプットプロセスやアウトプットプロセスを体系的にまとめています。
もちろん、検討ステータスとかセッション開催日の管理も行っています。
これらの検討事項一覧を整理し、補足説明資料を用意した上で、実際のセッションに臨みます。
セッションでは、検討事項一覧を共有して全体像を把握した上での検討を可能にします。
また、補足説明資料を使うことで、検討事項の理解を促してきます。
その結果を検討事項一覧に戻し、検討の進捗に応じて要件定義フェーズの成果物に取りまとめていくのです。
今回のフェーズでは、検討事項一覧がキーポイントになっており、
検討事項一覧に基づいて体系的な要件定義書を完成させることが重要だと言えるでしょう。
05. イメージと完成物の乖離を防ぐため、都度確認するアプローチに変更
続いて、3つ目の課題は、システム構築アプローチのフェーズで発生します。
このフェーズは、要件定義が一段落して、後は要件に沿ってシステムを構築するといった段階ですね。
構築フェーズに入ると、導入ベンダーが、要件に沿ってシステムを作り上げるため、負荷が軽くなる一方で、
クライアントは要件の決定を受けて構築を導入ベンダーに一任する形になります。
すると、クライアント側は、ものづくりの進捗状況のみを把握し、システムの機能面の確認は完成後です。
結果、導入ベンダーがシステムをお披露目した後、
クライアントのイメージと実際に出来上がった仕組みに大きな乖離が生まれてしまいます。
構築フェーズでのつまずきは、後続フェーズに大きく影響します。
要件定義フェーズでは、検討事項が多少残っていても前に進めますが、
構築フェーズでのつまずきは、その後のユーザー教育など、後続フェーズへの影響が非常に大きくなります。
このような問題の発生を防ぐためには、導入ベンダーにお任せするスタイルから、
都度確認するアプローチへの変更をしましょう。
要件定義フェーズは先ほどと変わらず、要件を導入ベンダーとクライアントで整理しますが、
構築フェーズになった後は、クライアント側の関与度合いを高めて機能を随時チェックする形にすると良いと思います。
イメージとしては、実機を用いて実現イメージを擦り合わせたり、
導入ベンダーとクライアントでセッションしてレビュー、修正したりする業務を導入します。
すると、システムの完成度が、要求レベルに近づけると思います。
EPM・CPMという意味では、データの分析が重要です。
このため、この実機を用いた実現イメージの擦り合わせは、
データ分析の粒度やデータの見え方の精度を高めていければ良いと考えています。
これらの取り組みにより、完成したシステムとクライアントのイメージの齟齬を最小限に抑制でき、
後続フェーズへのスムーズな移行が可能になるのです。
06. ユーザーからの指摘を無くすため、プロジェクトの目的・方針を丁寧に説明
4点目は、教育フェーズで起きる問題です。
エンドユーザーへの展開を目的とする教育フェーズでは、
現行システムに慣れたユーザーから多数の指摘が入るという問題が発生します。
エンドユーザーは、構築フェーズまでシステムの入れ替えプロジェクトが動いているため、
「システム入れ替えは先の話だよね」「きっと現行踏襲されるだろう」という、何となくのイメージを持っています。
ところが、教育フェーズに入り、ユーザー向けトレーニングが開始されると、
エンドユーザーに「いよいよ自分たちの業務に関わってくる」という当事者意識が芽生えます。
すると、手間を増やしたくない、業務を変えたくないという心理が働いてしまうのです。
ユーザー向けトレーニングの最中によくあるのは、
エンドユーザーが現行システムとの細かな違いを指摘することです。
さらに、良くないケースは、クライアントのプロジェクトメンバーがエンドユーザーの指摘を無視できず、
システム改修を導入ベンダーに依頼するケースがあります。
システム改修の依頼は、ベンダー側から見ると、後ろから刺されるような感覚です。
このような構図は非常に良くないと思います。
この問題を防ぐためには、クライアントとベンダーの協力体制のもと、
エンドユーザーへのプロジェクトの目的・方針の丁寧な説明が必要です。
プロジェクトの目的・方針を再確認する必要があるのは、日々の作業に追われると、
プロジェクトメンバーであっても目的意義を忘れがちになるためです。
少なくともフェーズ切り替えのタイミングで、
エンドユーザーと導入ベンダーを含むクライアントプロジェクトメンバーの双方で、
目的意義の再確認が必要になるでしょう。
また、教育フェーズに至るまでは、信頼関係の構築という側面で、
前段階の要件定義フェーズで活発な議論を行い、時にはぶつかることがあるかもしれません。
しかし、構築フェーズ以降は、システムの実現に向け、
エンドユーザーと導入ベンダーを含むクライアントプロジェクトメンバーの双方のベクトルを合わせ、
共に歩む姿勢が必要です。
07. 新任担当者の理解度向上を狙いに、機能概要書や理解度テスト、演習問題を活用
最後の5番目のケースは、何とか稼働に漕ぎつけたものの、
新任担当者がシステムを使いこなせない、システムへの理解が深まらないといった課題です。
これは、いわゆる、システムの定着化の課題と言えるでしょう。
システムの導入期間中は多くの場合、ユーザーの理解度の向上に資するイベントが用意されています。
例えば、プロジェクトメンバー向けトレーニングは、直接関わっていませんが、背後にエンドユーザーが控えています。
受け入れテスト（UAT）やトライアルは、教育的な側面により、
システムに触れる機会があるため、ユーザーの理解度向上の助けとなります。
このステップを踏むことで、ユーザーは、業務に必要なレベルに到達できるのです。
一方で、稼働後は各種トレーニングが手薄となり、新任担当者へのフォローが少なくなります。
とはいえ、個別にトレーニングする訳にはいかないのです。
そこで、新任担当者がシステムを使いこなせないという課題を解決するために行っているのは、
セルフトレーニングと同等の役割を持つ機能概要書と理解度テスト・演習問題の応用です。
ここでは、ドキュメントベースの自己学習をさせた後に、
理解度テストや演習問題の受講を課すことで、新任担当者が業務に必要なレベルに到達するのを促します。
ドキュメントベースの自己学習では、業務マニュアルと操作マニュアルに加え、機能概要書を活用します。
この機能概要書は、システムの全体像やコンセプトから始まり、
機能ごとに特徴や仕組みを解説したドキュメントという位置付けです。
システムの操作方法だけでなく、仕組みを理解できるようになっています。
ドキュメントベースの自己学習を終えた後は、選択問題を用いた理解度テストや、
実機によるハンズオン形式の演習問題の受講に移ります。
ここでは、実務に入る前の理解の底上げのほかに、理解度テストや演習問題を設けることで、
学習そのもののモチベーションの向上を目的としています。
いずれにしても、新任担当者が理解度を高める仕組みを整えていくことが重要です。
これらの取り組みにより、EPM・CPMの定着化につながるほか、業績向上に貢献すると考えています。
08. 落とし穴を防ぐ打ち手を講じ、円滑なツール導入を
本日のサマリーとなりますが、
要件定義フェーズでは、One data、Reliable dataベースの検討アプローチ、
検討一覧事項に基づいた検討・推進が打ち手となります。
構築フェーズでは、クライアントと都度確認アプローチを取ることが重要になるほか、
エンドユーザーの教育に向けては、プロジェクトの目的・意義の再確認と、
クライアントとベンダの協力体制の構築が肝になるでしょう。
最後の稼働後の定着化では、機能概要書や理解度テスト演習問題を駆使し、
エンドユーザーの理解を高めるための仕組みづくりが、打ち手となります。
以上により、これらの打ち手を講じることで、プロジェクトを円滑に進められるとともに、
稼働後も安定したEPMとCPMの定着化が図られると考えています。
コラムのオンデマンドウェブセミナーが無料で視聴いただけます
経営企画部門や経理・財務部門等、
予算の作成や予実分析、数値集計を行う部門の部門長およびご担当者様を対象にしたウェブセミナー
「EPM/CPMが当たり前の時代だからこそ、導入時における陥りがちな落とし穴とその打ち手」の
オンデマンドウェブセミナーは以下URLより視聴いただけます。
https://www.primal-inc.com/bizforecast/event/webinars/entry/00502.html
