快消品行业ERP项目挽救：用SAP Analytics Cloud统一报表

这篇案例写给手上有不止一套ERP、却始终拿不到一套统一数字的CFO和IT负责人。先说结论：新加坡用Oracle、英国用SAP，两地之间一个停滞的跨境报表项目，在六个月内被挽救了回来。靠的是五件事。一个人数更少、真正有决策权的指导委员会。把范围砍到只剩驱动决策的报表。在两套系统之间统一口径。把SAP Analytics Cloud作为唯一的报表层。再用本地推动者取代课堂式培训。如果您也处在同样的位置，请先从治理和口径入手，不要先去争论工具。

故事要从一个停滞的ERP分析项目说起，主角是一家总部位于新加坡的知名快消品（FMCG）集团。该集团持有一家英国能量饮料企业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指南。

这家快消品集团的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放进了同一个模型，但光靠技术是救不了这个项目的。六个月后，那些原本在等着项目垮掉的人，展示的是他们自己做出来的仪表板。