FMCG企業のERP立て直し：SAP Analytics Cloudによる統合レポーティング

この事例は、複数のERPを運用していて、一つの数字にまとめられずにいるCFOとIT部門のリーダーに向けたものです。要点はこうです。シンガポールのOracleと英国のSAPにまたがる、停滞した国境をまたぐレポーティングプロジェクトが、6か月で立て直されました。決め手は5つです。実権を持つ少人数のステアリングコミッティ。意思決定を左右するレポートに絞ったスコープ。両システムをまたぐ定義の統一。唯一のレポーティング層としてのSAP Analytics Cloud。そして、集合研修に代わる現場のチャンピオン。同じ状況にあるなら、ツール論争ではなく、ガバナンスと定義から始めてください。

物語は、シンガポールに本社を置く、名の知れたFMCGグループで停滞していたERP分析プロジェクトから始まります。グループは、英国のエナジードリンク事業の株式の26%を保有していました。少数持分であるにもかかわらず、経営の主導権はシンガポールにあり、アジアの役員会での戦略が、欧州での日々のレポーティングと計画を形づくっていました。

技術が、状況をさらに難しくしていました。シンガポールはOracle ERPを使い、英国はSAP ERPを使っていました。それぞれが単独で動き、2つが合わさって、すでに何か月分もの労力を費やしたレポーティングの問題を生んでいました。

数字はめったに一致しませんでした。照合は何日も長引きました。基本的な売上レポートでさえ、どちらのシステムを見るかで違う結果になりました。

立て直しの取り組みから6か月以内に、失敗に見えたイニシアチブは、財務部門と現場部門の両方が信頼できる、国境をまたぐレポーティングモデルになりました。

立て直し前再稼働時

ガバナンス立て直し前大人数のステアリングコミッティで、決定が先送りされる再稼働時実際の意思決定者だけが、会議の場で決める

スコープ立て直し前要望で埋まったホワイトボード再稼働時意思決定を左右するレポート

定義立て直し前ラベルは同じでも、ERPごとに意味が違う再稼働時売上、コスト、利益率を合意済み

レポーティング立て直し前何日もかかるExcelでの照合再稼働時OracleとSAPのデータがSAP Analytics Cloudの一つのモデルに集約

定着立て直し前集合研修のあとExcelに逆戻り再稼働時現場のチャンピオンが、一つのチームずつ支援

表に、出発点と、各問題がどう解消されたかをまとめます。

課題	影響	SAP Analytics Cloudによる解決
2つのERP：シンガポールはOracle、英国はSAP	数字が合わず、照合に何日もかかった	両方を一つのレポーティングモデルに取り込んだ
国境をまたぐレポーティングの責任が不明確	アジアの戦略が、欧州の業務データと食い違った	標準KPIにより、両法人が同じ指標を報告するようになった
売上レポートの遅さ	元のシステムにより数字が異なり、意思決定が遅れた	計画とレポーティングを統合し、サイクルが短縮した
計画のずれ	シンガポールが戦略を決め、英国は別の前提で実行していた	共有の計画モデルが、両事業を揃えた

2つのERPにまたがるレポーティング

シンガポールのOracleと英国のSAPでは、レポーティングはまるで2つの別々の事業を運営しているようでした。財務は同じ指標を各システムから引き出し、違う答えを得ていました。ある月次レビューで、シンガポールが売上の数字を示すと、英国はすぐに別の数字で異議を唱えました。議論はレビューそのものより長く続きました。

人々は、そのほうが安全に思えるため、Excelに逃げ込みました。何時間もかけてエクスポートし、照合し、自分なりの真実のバージョンを作る。短期的には機能しましたが、グループのレポーティングに慢性的な遅れを生みました。この傾向は、私の記事CFOがなぜいまだにExcelに手を伸ばすのかで、より広く取り上げています。

月次連結

月末が最も困難でした。一方のERPで「オペレーション」に置かれたコストが、もう一方では「管理」に入ってしまうことがありました。同じ費用が、別々の見出しで二重に載っている連結ドラフトを見たことがあります。それで数字への信頼が失われました。結果が遅れるのが当たり前になり、グループが公表しても、たいてい修正が続きました。

業務レポーティング

問題は財務にとどまりませんでした。Oracleは出荷を追跡し、SAPは在庫を追跡していて、唯一の情報源がありませんでした。ある倉庫マネージャーは、1週間のうちに在庫レポートを3種類受け取り、どれも残高が違っていたと話してくれました。笑いながら話していましたが、それは実際の意思決定を遅らせていました。補充は遅れ、運営側がダッシュボードを信頼していなかったため、出荷の遅れの説明も難しくなっていました。

ツール論争

レポーティングツールの選定が、それ自体ひとつのプロジェクトになりました。Power BIのコスト面を評価するマネージャーもいれば、ロードマップが長いことからSAPを推すマネージャーもいました。私は、時間の半分が、レポーティングのニーズではなく「なぜSACでPower BIではないのか」に費やされたワークショップに同席しました。この議論は何か月も続き、勢いを奪いました。

ユーザーの抵抗

最初のダッシュボードが稼働したあとでも、定着は低いままでした。財務の会議で、誰かがダッシュボードを開き、ざっと眺めて閉じ、Excelのシートに戻るのを見たことを覚えています。誰も疑問を挟みませんでした。人々は慣れたものを信頼し、ダッシュボードはまだその信頼を勝ち取っていなかったのです。

ガバナンスの立て直し。 会議は果てしなく感じられ、誰が決めたのか分からないまま、人々は席を立っていました。経営陣は、ステアリングコミッティを、実際の意思決定者だけに絞りました。セッションは短く、決断が早くなり、エスカレーションも適切な人にすぐ届くようになりました。完璧ではありませんでしたが、物事が動き始めました。同じ原則は、私のガイドSAPステアリングコミッティの運営に示しています。

スコープを抑え込む。 グループ向けの表示にどの数字を入れるかで、人々が絶えず議論し、要件リストは手に負えなくなっていました。ワークショップのホワイトボードが、端から端まで要望で埋まり、その半分は実際の意思決定と無関係だったのを覚えています。うまくいったのは、次の捉え方でした。レポーティングは、意思決定を左右するものだけをカバーすればよい。これが合意されると、デリバリーが加速しました。

自分たちに関係があると感じられるコミュニケーション。 それまでの報告は画一的で、財務、運営、ITがそれぞれ違う解釈を持ち帰っていました。そこで、相手に合わせた報告に切り替えました。財務にはレポーティングのスケジュール、運営には物流プロセスの変更、ITには技術ロードマップです。報告が自分たちの言葉で語られるようになったため、人々はより良い質問をするようになりました。

現場のチャンピオン。 研修だけでは効果がありませんでした。人々はセッションに出席し、翌朝にはExcelに戻っていました。変化を起こしたのは現場のチャンピオン、つまりチーム内ですでに信頼されている同僚が、ダッシュボードを非公式に、自分の言葉で説明することでした。私はそうしたセッションの一つに同席し、その違いに驚かされました。人々は、講義形式の研修では決してしなかったような質問をしていました。定着は、1チームずつ進みました。

表に、何が変わり、なぜうまくいったのかをまとめます。

重点領域	変えたこと	影響
ガバナンスの立て直し	ステアリングコミッティを実際の意思決定者に絞り、セッションを短く、鋭くした	会議の場で決定され、エスカレーションが素早く進んだ
スコープ管理	要件を、意思決定を左右するレポーティングに絞り込んだ	議論が減り、データモデルが明確になり、動く標的が減った
相手に合わせたコミュニケーション	財務、運営、ITに別々の報告を行った	各チームが自分に重要なことを理解し、信頼が戻った
現場のチャンピオン	正式な研修ではなく、少人数でのピアコーチング	定着がチームごとに進み、Excel依存が減った

ツール選定がようやく決着したとき、SACが選ばれました。理由の一部は、大がかりなカスタム開発なしに、OracleとSAPのデータを一つのモデルに集められることでした。それで議論の熱がいくらか冷めました。レポートは、従来のエクスポートのサイクルよりずっと速く変更を反映しました。ある財務コントローラーは、一日の始まりに夜間のデータ更新を待たなくて済んだのは初めてだと話しました。

財務マネージャーが初めて、OracleのデータとSAPのデータを一つのダッシュボードに並べて見たとき、肩の荷が下りたようでした。その瞬間が、議論に決着をつけました。

SACがカバーしたのは、財務だけではありませんでした。運営部門は物流と倉庫の見える化を求め、人事部門は人員計画を求めました。計画、レポーティング、可視化が一つのプラットフォームにあることが、場当たり的な対処と、長期的な土台との違いを生みました。構築済みのテンプレートは、いくらか画一的に感じる人もいましたが、チームに先行きの良いスタートを与え、その最初の納品の速さが、何か月も遅れたあとの信頼を取り戻しました。

この設計を真似するなら、技術的な点が1つあります。SACのライブデータ接続は、SAP HANA、BW、S/4HANA、BPC embedded、BusinessObjectsユニバース、SAP Datasphereといった、SAPのソースに限られます。Oracle ERPのようなSAP以外のデータは、通常、インポート接続、ユニバース、または間に置くデータ層を通じて取り込みます。このアーキテクチャは早めに決めてください。両側の数字の鮮度が、それで決まるからです。

最初のマイルストーンは、データモデルでした。OracleとSAPの両方を一つの構造に流し込む必要があり、見た目より難しい作業でした。項目は同じラベルでも、システムごとに意味が違っていました。売上、コスト、利益率が実際に何を意味するのかを財務が合意するまで、定義のマッピングに何週間もかかりました。

ダッシュボードは段階的に展開しました。最初が財務、次に営業と運営で、それぞれの実際の仕事を軸にレポートを作りました。初期のバージョンは硬直的すぎました。ユーザーがそう伝え、その指摘は正しいものでした。ダッシュボードは改善され、合意されたKPIが、毎月の絶え間ない議論に取って代わりました。

再稼働は、6か月以内に完了しました。初めて、OracleとSAPのデータが、SACの一つのモデルに収まりました。照合をめぐる争いは減り、経営陣はExcelファイルが回ってくるのを待たずに数字を確認できるようになりました。

数週間かかっていた計画サイクルが、数日になりました。プランナーはシナリオをモデル化し、実績と比較できるようになりました。ダッシュボードが示す以上の詳細を求めるマネージャーもいましたが、数字を信頼していること自体が、すでに大きな意味を持っていました。

ある倉庫マネージャーが、初めて自分のレポートの在庫水準が、財務が示している数字と一致したと話してくれました。部門をまたいだその静かな一致こそが、本当の指標でした。元のプロセスに戻りたいと言う人は、誰もいませんでした。

表に、プロジェクトを停滞させた失敗と、それぞれからの教訓を示します。

失敗	引き起こしたこと	教訓
不明確なガバナンス	果てしない会議、決定なし、遅れの積み上がり	役割と意思決定権を、早い段階で立て直す
スコープの漂流	レポーティングの目標が変わり続けた	スコープを絞り、意思決定に結びつけておく
ユーザーの軽視	ユーザーが自信を失い、定着が遅れた	ユーザーを早くから巻き込み、背景を伝える
過剰なカスタマイズ	レポートの作り直しで時間を浪費した	テンプレートと標準コネクタから始め、カスタマイズは後で行う
弱いチェンジマネジメント	研修が的外れで、古い習慣が残った	現場のチャンピオンとピアコーチングを早期に導入する

3つの教訓が、ほかを引き離しています。ガバナンスはツールより重要です。複数ERPの環境で責任の所在が明確でなければ、どのプラットフォームを使っても、レポーティングは崩れます。ツール選定の前に、データ定義をそろえます。Power BIとSACの議論は的を外していました。合わない定義を直せるツールなどないからです。そして、定着を決めるのはチェンジマネジメントです。チャンピオンと、相手に合わせたコミュニケーションがなければ、ダッシュボードは使われないままだったでしょう。

同じ作業を今始めるなら、3つのことが変わります。

SACとソースの間にデータ層が入ります。 SAP Datasphereは現在SAP Business Data Cloudの一部で、SAPとSAP以外のソースに、セマンティックモデルを載せた形でフェデレーテッドにアクセスできます。このような2つのERPのケースでは、OracleとSAPのデータをその層で調和させるほうが、各SACストーリーの内部で行うよりすっきりします。また、調和されたモデルへのライブ接続をSACに与えることにもなります。

自然言語での質問が、ダッシュボードの構築の一部に取って代わります。 SACの自然言語クエリとJouleにより、財務は、たとえば四半期の地域別売上、シンガポール対英国、を尋ねられます。先にストーリーを作る必要はありません。データが調和されたあとの作業は、これで速くなります。定義のギャップは埋まりません。

契約面の交渉は、ERPの契約から始まります。 SACの交渉に入る前に、クラウドERP契約にすでにどんな分析機能が含まれているかを確認してください。SACの計画機能一式は別途ライセンスされ、一方のエンティティがクラウドERPで、もう一方はそうでないというハイブリッド環境でも、ライセンスには慎重さが必要です。

ガバナンスの立て直し、スコープの規律、現場のチャンピオン、相手に合わせたコミュニケーションは、変わらないでしょう。これらは、どのテクノロジーでも通用するパターンです。2つのERPに同じ数字を報告させるという人間の仕事は、自動化されません。SAC自体について詳しくは、私のSAP Analytics Cloudガイドをご覧ください。

このFMCGグループのERPレポーティングプロジェクトは、なぜ停滞したのですか？

シンガポールはOracle、英国はSAPを使っていて、毎月、財務が手作業で数字をつなぎ合わせていました。何日もかかり、結果を完全に信頼する人はいませんでした。シンガポールが一つの数字を示し、英国が別の数字で異議を唱えると、レビューは止まりました。ステアリングコミッティも大きすぎて、誰も決断しませんでした。コストは増え、信頼は揺らぎ、プロジェクトは漂流しました。

立て直しの方向を変えたものは何ですか？

経営陣がプロジェクトの行き詰まりを認め、立て直し計画に合意しました。ステアリングコミッティは実際の意思決定者の少人数に絞られ、優先順位が定められ、SAP Analytics Cloudが唯一のレポーティングツールに選ばれ、コミュニケーションは相手別になりました。会議は責任追及から次に何をするかへと移り、人々はプロジェクトが成果を出せると信じ始めました。

SAP Analytics Cloudは、OracleとSAPの両方をどう扱いましたか？

SACはOracleとSAPのデータを一つのレポーティングモデルに集め、手作業の照合ファイルなしで、両方を一つのダッシュボードに並べて表示できるようにしました。2つのシステムが一つの画面に並ぶのを見たことが、ツール論争を終わらせた瞬間でした。なお、SACのライブ接続がサポートするのはSAPのソースだけです。Oracleのデータは、通常、インポート接続、BusinessObjectsユニバース、またはSAP Datasphereのようなデータ層を通じて入ってきます。

なぜユーザーは、最初はダッシュボードに抵抗したのですか？

ダッシュボードは、十分な業務の背景を伴わずに公開されました。ユーザーはSACを使うよう言われましたが、日々の仕事にどう当てはまるのかを示した人は誰もおらず、研修も画一的でした。人は慣れたものを信頼し、ダッシュボードはまだその信頼を得ていませんでした。現場のチャンピオンが、自分の言葉でダッシュボードを説明したことが、それを変えました。

ERPレポーティングの立て直しの成功とは、どのような姿ですか？

一つの要因であることはまれです。ここでは、ガバナンスの立て直し、スコープの縮小、定義の統一、相手に合わせたコミュニケーション、そして仲間のチャンピオンが一緒に働いたことでした。SACが役立ったのは、大がかりなカスタム開発なしに両方のERPを一つのモデルに入れられたからですが、テクノロジーだけではプロジェクトを救えませんでした。6か月後、プロジェクトが崩れるのを待っていた人たちが、自分で作ったダッシュボードを発表していました。