FMCG ERP 重整：以 SAP Analytics Cloud 統一報表

這個案例研究寫給同時營運多套 ERP、卻始終無法取得單一數字的 CFO 與 IT 主管。先講結論：一個橫跨新加坡 Oracle 與英國 SAP 的跨國報表專案原本停滯，後來在六個月內重回正軌。靠的是五件事。一個規模更小、真正有決策權的指導小組。把範圍縮到真正驅動決策的報表。兩套系統之間一致的定義。以 SAP Analytics Cloud 作為唯一的報表層。以及用在地推手取代教室訓練。如果您也處於同樣的處境，請先從治理與定義著手，不要先陷入工具之爭。

故事從一家總部設在新加坡、頗具知名度的快速消費品（FMCG）集團裡，一個停滯的 ERP 分析專案開始。這個集團持有一家英國能量飲料企業 26% 的股份。雖然只是少數股權，管理控制權卻在新加坡，所以亞洲董事會的策略，決定了歐洲每天的報表與規劃。

技術讓事情更難辦。新加坡使用 Oracle ERP，英國使用 SAP ERP。兩邊各自運作，合在一起就造成了一個已經耗掉數月心力的報表問題。

數字很少對得上。對帳一拖就是好幾天。就連最基本的營收報表，也會因為查的是哪一套系統而得出不同的結果。

在重整專案開始後的六個月內，原本看似失敗的計畫，變成了財務與營運都信任的跨國報表模型。

重整之前重新上線時

治理重整之前指導小組人數眾多，決策一再延後重新上線時只留真正的決策者，在會議上當場決定

範圍重整之前一面寫滿需求的白板重新上線時真正驅動決策的報表

定義重整之前同一個標籤，在兩套 ERP 中意義不同重新上線時營收、成本與毛利已有共識

報表重整之前要花上好幾天的 Excel 對帳重新上線時Oracle 與 SAP 資料同在 SAP Analytics Cloud 的一個模型中

採用重整之前教室訓練後又回到 Excel重新上線時在地推手，一次帶一個團隊

下表概述了起始狀況，以及各項問題如何獲得解決。

挑戰	影響	以 SAP Analytics Cloud 解決的方式
兩套 ERP：新加坡用 Oracle，英國用 SAP	數字對不上，對帳耗時數日	兩邊都匯入同一個報表模型
跨國報表的負責歸屬不清	亞洲的策略與歐洲的營運資料互相衝突	標準化 KPI，讓兩家公司回報相同的指標
營收報表緩慢	數字因來源系統而異，延誤決策	統一的規劃與報表縮短了週期
規劃不一致	新加坡訂定策略，英國則依不同的假設執行	共用的規劃模型讓兩邊的業務對齊

橫跨兩套 ERP 的報表

新加坡用 Oracle，英國用 SAP，報表作業就像在經營兩家各自獨立的公司。財務從兩套系統各拉出同一個指標，卻得到不同的答案。在某次月會上，新加坡報告了一個營收數字，英國當場提出另一個數字來質疑。爭論的時間比會議本身還長。

大家退回 Excel，因為那樣比較有安全感：花上好幾個小時匯出、對帳，再做出自己版本的真相。短期有效，卻讓集團報表長期延誤。我寫的為什麼 CFO 仍然依賴 Excel一文，更廣泛地談了這個現象。

月結合併

月結是最困難的部分。一筆成本在其中一套 ERP 放在「營運」之下，在另一套卻可能歸到「行政」。我曾看過一份合併報表草稿，同一筆費用在不同的類別下出現了兩次。這讓大家不再信任這些數字。延遲出結果成了常態，而集團一旦發布，後面通常還要修正。

營運報表

問題不只在財務。Oracle 追蹤出貨，SAP 追蹤庫存，沒有單一的資料來源。一位倉儲經理告訴我，他一週內收到過三份不同的庫存報表，餘額全都不一樣。他說這件事的時候笑了，但這確實拖慢了實際的決策。補貨落後，出貨延遲也更難解釋，因為營運團隊不信任那些儀表板。

工具之爭

選擇報表工具本身就成了一個專案。有些主管喜歡 Power BI 的成本結構，另一些則因為 SAP 的產品路線圖更長遠而力推 SAP。我參加過一場工作坊，有一半的時間都花在「為什麼選 SAC 而不是 Power BI」，而不是報表需求上。這場爭論持續了數月，消耗掉不少動能。

使用者的抗拒

即使第一批儀表板上線之後，採用率仍然偏低。我記得在一場財務會議上，有人打開儀表板，瞄一眼，關掉，又回到自己的 Excel 表。沒有人對此提出質疑。人們信任自己熟悉的東西，而這些儀表板還沒有贏得那份信任。

重設治理。 會議看似永無止境，散會時大家還是不確定是誰拍的板。管理階層把指導小組縮減為真正的決策者。會議變得更短、更果斷，升級事項也能快速送到對的人手上。談不上完美，但事情開始動了。我寫的如何運作 SAP 指導委員會指南，說明了同樣的原則。

掌控範圍。 大家不斷爭論哪些數字該放進集團層級的檢視，需求清單也已經失控。我記得有場工作坊的白板，從頭到尾寫滿了需求，其中一半和任何真正的決策毫無關係。後來奏效的說法是：報表只需要涵蓋驅動決策的內容。這一點達成共識後，交付就加快了。

讓溝通切身相關。 先前的更新都很籠統，所以財務、營運與 IT 各自得出不同的解讀。我們改成量身訂做的更新：給財務的是報表時程，給營運的是物流流程的變更，給 IT 的是技術路線圖。大家開始問出更好的問題，因為這些更新說的是他們的語言。

在地推手。 光靠訓練行不通：大家坐完整場課程，隔天早上又回去用 Excel。轉變來自在地推手，也就是在自己團隊裡本來就有公信力的同事，用自己的話非正式地說明儀表板。我旁聽過其中一場，差別非常明顯。大家問出了在課堂上絕對不會問的問題。採用率一次一個團隊地改善。

下表概述了改變了什麼，以及為什麼有效。

重點領域	改變了什麼	影響
重設治理	將指導小組縮減為真正的決策者；會議更短、更精準	決策在會議上當場做出；升級事項迅速推進
範圍控管	把需求收斂到驅動決策的報表	爭論變少，資料模型更清楚，變動的目標更少
量身訂做的溝通	為財務、營運與 IT 分別提供更新	每個團隊都明白什麼對自己重要；信任重新建立
在地推手	以小組同儕輔導取代正式課程	採用率逐團隊提升；對 Excel 的依賴下降

工具選擇終於定案時，SAC 勝出，部分原因是它不需要大量客製開發，就能把 Oracle 與 SAP 資料納入同一個模型。這讓討論降了溫。報表反映變更的速度，比過去的匯出週期快得多。一位財務會計主管說，這是她第一次不必等隔夜的資料更新，一天才能開始工作。

財務經理第一次在同一個儀表板上並排看到 Oracle 資料與 SAP 資料時，如釋重負。那一刻終結了這場爭論。

SAC 涵蓋的也不只財務。營運想要物流與倉儲的檢視，人資想要人力規劃。把規劃、報表與視覺化放在同一個平台，就是一次性的戰術補救與長期基礎之間的差別。預建範本讓團隊搶得先機，即使有些顯得太過通用，而首次交付的速度，也讓大家在延宕數月之後重拾信心。

如果您打算複製這個設計，有一個技術重點。SAC 即時資料連線僅限於 SAP 來源，例如 SAP HANA、BW、S/4HANA、內嵌式 BPC、BusinessObjects Universe 與 SAP Datasphere。像 Oracle ERP 這類非 SAP 資料，通常是透過匯入連線、Universe 或中間的資料層進來。請及早決定這個架構，因為它決定了兩邊數字的新鮮程度。

第一個里程碑是資料模型。Oracle 與 SAP 都必須餵入同一個結構，這比看起來困難得多。欄位的標籤相同，在兩套系統中的意義卻不同。花了數週對應各項定義，財務才同意營收、成本與毛利到底是什麼意思。

儀表板分階段推出。先是財務，接著是業務與營運，每一份報表都圍繞他們實際的工作來建置。早期版本太死板。使用者這麼說，而他們說得沒錯。儀表板後來改善了，各方認可的 KPI 取代了原本每月不斷的爭吵。

重新上線在六個月內完成。Oracle 與 SAP 資料第一次同時存在 SAC 內的同一個模型中。對帳的爭執減少了，高階主管檢視數字時，不必再等 Excel 檔案四處流傳。

過去要花數週的規劃週期，縮短到數天。規劃人員可以模擬情境，並與實績比較。有些主管想要比儀表板提供的更多細節，但他們信任這些數字，這件事本身就已意義重大。

一位倉儲經理提到，他報表中的庫存水位，第一次和財務呈現的數字一致。這種各部門之間悄悄形成的一致性，才是真正的指標。沒有人要求回到舊的流程。

下表列出了讓專案停滯的錯誤，以及每一項的教訓。

錯誤	造成的後果	教訓
治理不明	會議沒完沒了，沒有決策，延誤不斷累積	及早重設角色與決策權
範圍漂移	報表目標不斷變動	守住範圍，並與決策掛鉤
忽視使用者	使用者失去信心，採用速度放緩	及早讓使用者參與，並提供背景脈絡
過度客製	時間浪費在重做報表	先用範本與標準連接器；之後再客製
變革管理薄弱	訓練沒有切中要點；舊習慣根深蒂固	及早引入在地推手與同儕輔導

有三個教訓比其他都重要。治理比工具重要：在多套 ERP 的環境中，如果沒有明確的負責歸屬，不管用什麼平台，報表都會崩解。在選工具之前先對齊資料定義：Power BI 與 SAC 之爭根本搞錯了重點，因為沒有任何工具能修好彼此對不上的定義。而變革管理決定採用率：沒有推手與有針對性的溝通，儀表板只會被閒置。

如果同樣的工作現在才開始，會有三件事不同。

SAC 與資料來源之間會多一層資料層。 SAP Datasphere 現在是 SAP Business Data Cloud 的一部分，提供對 SAP 與非 SAP 來源的聯邦式存取，上面再加一層語意模型。對這種雙 ERP 的案例，在這一層調和 Oracle 與 SAP 的資料，比在每個 SAC story 裡各自處理更乾淨。它也讓 SAC 能夠即時連線到調和後的模型。

自然語言提問會取代部分儀表板的開發。 SAC 的自然語言查詢與 Joule，讓財務可以直接詢問，例如本季各區域的營收，新加坡對照英國。不必先建任何 story。資料調和之後，這能加快工作。但它補不上定義上的缺口。

商務談判會從 ERP 合約出發。 在洽談 SAC 之前，先確認您的雲端 ERP 合約已經包含哪些分析功能。完整的 SAC 規劃功能是另外授權的，而一個實體用雲端 ERP、另一個實體沒用的混合環境，仍需審慎處理授權。

治理重設、範圍紀律、在地推手與量身訂做的溝通，這些都不會變。無論技術如何，這些模式都成立。要讓兩套 ERP 回報相同的數字，這份屬於人的工作，是無法被自動化的。想進一步了解 SAC 本身，請參閱我的 SAP Analytics Cloud 指南。

這個 FMCG 集團的 ERP 報表專案為何停滯？

新加坡使用 Oracle，英國使用 SAP，每個月財務都要手工把數字拼湊起來。這要花上好幾天，而且沒有人完全信任結果。當新加坡提出一個數字，英國又以另一個數字質疑時，檢討會議就卡住了。指導小組也太大，沒有人做決策。成本上升，信心下滑，專案也就漂流不前。

是什麼改變了重整的方向？

管理階層承認專案卡住了，並同意了一份重整計畫。指導小組縮減為少數真正的決策者，優先順序確立，SAP Analytics Cloud 被選為唯一的報表工具，溝通也改為針對不同對象。會議從究責轉向接下來要做什麼，大家開始相信專案能夠交付。

SAP Analytics Cloud 如何同時處理 Oracle 與 SAP？

SAC 把 Oracle 與 SAP 資料帶進同一個報表模型，所以兩者可以並排出現在同一個儀表板上，不需要手工對帳檔案。在一個畫面中同時看到兩套系統，正是終結工具之爭的那一刻。請注意，SAC 的即時連線只支援 SAP 來源；Oracle 資料通常是透過匯入連線、BusinessObjects Universe，或 SAP Datasphere 這類資料層進來。

使用者起初為何抗拒這些儀表板？

儀表板上線時，缺乏足夠的業務脈絡。使用者被告知要使用 SAC，卻沒有人說明它如何套用在他們的日常工作上，訓練也太籠統。人們信任自己熟悉的東西，而這些儀表板還沒有贏得那份信任。後來由在地推手用自己的話說明儀表板，才改變了這一點。

成功的 ERP 報表重整是什麼樣子？

它很少只靠一件事。在這個案例中，是重設治理、縮小範圍、一致的定義、量身訂做的溝通，以及同儕推手一起發揮作用。SAC 之所以有幫助，是因為它不需要大量客製開發，就把兩套 ERP 帶進同一個模型，但光靠技術救不了這個專案。六個月後，原本一直等著它垮掉的人，正在展示他們自己建立的儀表板。