経営管理に役立つEPMツール導入の勘所

1. はじめに

「四半期ごとに事業別の収益性を比較し、投資の継続・撤退を判断したいが、必要なデータがグループ各社から揃うのは締め日から3週間後。しかも、表計算ソフトベースの集約プロセスのため、数値の信頼性に不安が残る――」

こうした課題は、多くの企業グループのCFO・経営企画部門から共通して挙げられます。

国際情勢の変化やAI活用によりビジネス変革のスピードが上がる中、経営の意思決定は「実績の振り返り」から「予測・シナリオに基づく先手の判断」へと転換を求められています。

しかし、その転換を支える意思決定に必要な情報を適切に届けるルール・プロセス・データ・ツールは、多くの企業でまだ十分に整備されていません。

こうした背景から、経営管理の基盤としてEPM（Enterprise Performance Management）に注目が集まっています。EPMとは、企業全体の経営に関わる情報を収集・作成・可視化し、経営の意思決定を支援するためのソリューションの総称です（以下、これを実現するツール群を「EPMツール」と表記します）。

本稿では、経営における意思決定に必要な情報をEPMツールの導入によって効果的に可視化する際に"つまずきやすい点"を、筆者の知る事例も踏まえて具体的に紹介して考察し、回避するヒントを示します。

EPMツール導入による経営管理高度化を検討するCFO、経営企画、経理・財務、情報システム部門の担当者の方々にぜひお読みいただきたい内容です。

2. EPMツール導入における勘所

EPMツールは、経営における意思決定に必要な情報を集約・可視化する強力なソリューションですが、ツールを導入しただけでは経営管理は変化しません。EPMツールが真価を発揮するには、インプットとなる数値を作る管理会計の仕組みを整備する必要があります。

管理会計の大きな特徴と言えるのが、法制度による「標準」が存在しないことです。財務会計であれば会計基準や税法が業務を規定しますが、管理会計では「何を・どの粒度で・どう管理するか」を自分たちで決めるところから始めなければなりません。

本稿ではこの定義のプロセスを、以下の5つのステップに分けて解説します（図表1）。

図表1：管理会計の仕組み定義の検討ステップ

ステップ1、2は、「何のために、何を管理するのか」（図表1：Whatの定義）を定める取り組みであり、ステップ3〜5はそれを「どのように実現するか」（図表1：Howの定義）を具体化する取り組みです。5つのうちステップ1、2が特に重要であり、ここで定めた目的を軸にして後工程を進めることが、プロジェクトを成功に導く最大の秘訣だと筆者は考えています。

なお、図に示すとおり、5つのステップは一方通行で進めるものではなく、ステップ3においてデータの実態を調査する中で、ステップ1、2の見直しが必要になることも珍しくありません。この往復は、あらかじめプロジェクト計画に織り込んでおくことを推奨します。

2.1 ステップ1：目的の明確化

全ては、EPMツールの導入によって「成し遂げたい目的」を明確にするところから出発します。目的が具体的であるほど、後工程での優先順位付けが迅速になり、投資対効果の見えるプロジェクト運営が可能になります。目的は、意思決定支援、オペレーション効率化、ガバナンス・統制強化などに分類できます。これらを参照しながら、成し遂げたいことを網羅的に洗い出していきます。

【つまずき事例】目的の明確化が不十分なまま進んだプロジェクト

「表計算データのバケツリレーになっている現行業務を改善してデータを効率的に収集し、収集したデータを基に経営層が意思決定に活用できるレポートを提供する」ことをEPMツールの導入によって実現しようとしていました。しかし、「経営層向けレポート」の具体的イメージが曖昧な状態で進行し、現行業務を改善してデータを効率的に収集するという部分に関係者の意識が集中してしまいました。結果として、オペレーション上で便利な機能が要件として多く盛り込まれる一方、本来の目的であったレポート機能については勘定科目ごとの予実比較が揃っていないなど不十分な仕上がりとなりました。

こうした失敗を避けるため、目的の明確化においては、以下の3つのポイントを意識して進めます（図表2）。

2.2 ステップ2：必要な情報・管理軸の定義

ステップ1で定めた目的を達成するために、EPMツールで「何が見えればよいか」を定義するステップです。①アウトプット要件の定義と、②要件の絞り込みの2段階で進めます。

①アウトプット要件の定義

「どのような情報が見たいか」「事業・製品・地域など、どの管理軸が必要か」「どの粒度まで見たいか」を方針レベルで定義します。この時点ではインプットデータの実態がまだ不明なため、詳細はステップ3で検証する前提とし、方針の定義に留めます。

②要件の絞り込み

「目的達成に不可欠な情報」に絞り、「あれば望ましい情報」は初期のスコープから外すことが有効です。なお、経営者が見たい情報は経営環境の変化に伴い常に変化します。そのため「最初に決めた定義を守り続ける」のではなく、「変わることを前提に、変化に対応できるよう定義する」ことが重要です。

具体的には、初期段階では不可欠な情報に絞り込み、管理軸や粒度を後から追加・変更できる余白を設計に織り込んでおきます。ステップ1で定義した「目的」さえ明確であれば、管理要件が変わっても立ち戻る「基準点」があるため、意図を持った見直しが可能になります。

【つまずき事例】あらゆる要件に対応しようとし、粒度を細かくしすぎたプロジェクト

実務レベルでの幅広いニーズに対応できるよう、明細レベルのドリルダウンや詳細な管理粒度を標準のアウトプットとして定義しました。その結果、できあがったレポートは、項目が細かすぎて何を見ればよいのか分からないものになってしまいました。さらに、管理粒度が細かすぎることから、現場が実際にデータを作成することができず、本来必要だった粒度のデータすらシステムに取り込まれないという状況が発生しました。

こうした事態を避けるために、アウトプットと目的の紐付けを行い、目的の優先順位に合わせてアウトプットにも優先順位を付けることが大切です。

2.3 ステップ3：データ収集プロセスの整理

ステップ1、2で定めた「見たい情報」をEPMツールで管理できるようにするため、必要なデータがどこに存在するかを確認し、それをどのように収集・加工するかを設計するステップです。①データ取得可否の判断と、②データの中身の検証の2段階で進めます。

①データ取得可否の判断

必要なデータが取得可能かどうかを、所在の有無だけでなく、定義の統一性・更新タイミング・加工負荷まで含めて判断します。取得が困難な場合は、図表1に示したようにステップ1、2に立ち戻って目的やアウトプットを見直すか、データソースとなる前方のシステムの改修を検討します。

②データの中身の検証

システムやデータの名称が同じでも、品質（桁数・粒度・内容など）が揃っていないことでその後の活用ができないことがあるため、中身の検証が必要です。

【つまずき事例】グローバルで同じシステムを利用しているものの、実際にはデータの品質がバラバラで、活用が困難だったプロジェクト

グローバル全体で得意先別の売上高を収集するため、グローバルで共通利用されている受注・販売管理のシステムからデータを取得しました。しかし、グループ各社は自社内での管理しやすさを優先してコード体系や得意先名称を独自に設定しており、グローバル単位で集計することが困難な状態になっていました。さらに、業務特性から取引相手が限定的であることを理由に、得意先の管理をしていない会社もありました。

このように、システムが統一されているからといって同じロジックでデータの集約が可能だと判断せず、中身を解析したうえでどのような加工が必要かを定義することで手戻りを防ぐことができます。

2.4 ステップ4：業務プロセス・運用ルール策定

ステップ3で設計したデータ収集を正確かつ継続的に実行するための業務プロセスとルールを策定するステップです。①現行プロセスの精査と、②システム化の判断材料の整理の2段階で進めます。

①現行プロセスの精査

業務プロセスを設計する際、既存のものを参考にすること自体は問題ありません。しかし、安易に現行のプロセスを踏襲することで意図せぬ不具合を生まないよう、注意が必要です。ここでは、各工程においてステップ1で定めた目的への貢献度を検証し、不要な工程は除外するといった精査が求められます。

【つまずき事例】現行踏襲で「業務が増えた」プロジェクト

現行の業務プロセスをベースに新システムの業務プロセスを設計したところ、現行プロセスの中には、過去のシステム制約を回避するためだけに存在していた手作業の照合工程や、すでに参照されなくなった集計工程が含まれていました。これらを精査せずにそのまま標準業務として組み込んだ結果、新システム導入後も不要な工程が残り、現場からは「システムを刷新したのに、業務が減るどころか増えた」という不満が上がるなど、新しいルールの運用について協力を得ることが難しくなりました。

こうした事態を避けるには、各工程が「ステップ1で定めたどの目的に貢献しているか」を検証し、目的に紐付かない工程は除外する判断が必要です。

②システム化の判断材料の整理（ステップ5への橋渡し）

策定した業務プロセスの各工程を以下の観点（図表3）で評価しておくことで、ステップ5での「EPMツールで自動化する範囲」と「業務プロセスで対応する範囲」の線引きがスムーズになります。

2.5 ステップ5：システム要件への落とし込み

ステップ1～4で整理した管理会計業務を、EPMツールの具体的な要件として実装するステップです。①EPMツールでの実現範囲の確定と、②EPMツールを含むシステム構成の検討の2段階で進めます。

①EPMツールでの実現範囲の確定

ステップ4の評価結果を基に、EPMツールに組み込む範囲を確定します。この際、ツールの仕様制約によって業務プロセスの柔軟性が下がるリスクがあるため、注意が必要です。

【つまずき事例】システム化によって業務の柔軟性が低下したプロジェクト

段階的にデータを作成していくプロセス全体をシステム化し、データの正確性が一貫して担保されるよう、決まった書式以外の入力を許可しないなど、機能を細かく定義しました。その結果、特定の手順でデータ登録をしなければ業務プロセスを前に進めることができない仕組みとなり、その手順に対応できない拠点のデータが収集できなくなってしまいました。

アウトプットの最終形をシステム外で作成して別途登録できる選択肢を用意するなど、システム化した手順に対応できない場合の回避策を合わせて定義しておくことがリスクヘッジになります。

②EPMツールを含むシステム構成の検討

EPMツールだけですべてを賄おうとせず、ERP（Enterprise Resource Planning：統合基幹業務）システムやBI（Business Intelligence：経営判断を目的としたデータの分析・可視化）ツールなど、役割ごとに適した手段を組み合わせることが、実効性のある構成につながります（図表4）。

【つまずき事例】1つのツールにすべての要件を詰め込んだプロジェクト

レポーティングやシミュレーションに強みを持つEPMツールで全要件を実現しようとしたところ、ステップ3、4の検討を進める中で、明細管理やマスタ管理の要件が想定以上に大きいと判明しました。この時点ですでに採用ツールを確定させていたため、データ構造に無理が生じ、後からデータウェアハウスを別途構築することになりました。

このような事態を回避するために、ステップ2の段階ではツール選定を仮の状態にとどめ、詳細要件が見えてから最終判断するプロセスを踏むことが重要です。

3. 終わりに

本稿を通じて繰り返し述べてきたことは、突き詰めれば一つのシンプルな原則に行き着きます。すなわち、「何のために管理するのか」という問いを持ち続けることです。

経営管理の目的が曖昧になれば、仕組みは容易に形骸化します。逆に、目的が明確であり続ける限り、環境変化に応じて仕組みを柔軟に作り変えていくことができます。

本稿で紹介した5つのステップが、経営管理の目的を明確にし、意図を持った管理会計の仕組みを構築するための一助となれば幸いです。