当前位置：首页 > news >正文

《Enterprise Architecture with SAP》—— 从“纸上蓝图”到“场景落地”

news 2026/5/22 23:29:39

上一篇文章（《Enterprise Architecture with SAP》— 从“项目思维”到“企业级全局视角”），我们花了不少篇幅把SAP企业架构的“骨架”搭起来了——五大支柱是什么、方法论怎么走、参考内容给什么蓝图、EA在企业里和谁配合干活。用一句话总结上一篇：我们拿到了一张SAP EA的城市总图。

但地图拿在手里，不等于会开车。

真正的问题是：当一家制造企业说“我要上云”，一个企业架构师最先要做的事，不是画一张完美的目标架构图，而是回答一个看似基础的问题——先评估什么？凭什么标准做选择？选了之后怎么干？

这篇文章，我们就用书中的一个完整案例来回答这些问题。一家叫PumpTech的老牌制造企业，正站在云转型的十字路口。我们将看到一套“可迁移框架”如何帮它从一团乱麻里理出头绪，以及一个可以直接套用的“模块选择决策矩阵”如何让架构决策从“拍脑袋”变成“有据可依”。

1. 制造业公司Pump Tech状况与困境

1.1新时代制造业的技术与环境

过去十年，制造业的竞争逻辑发生了根本性变化。客户不再满足于“买一台设备”，他们要求的是“设备持续运转、按使用付费、故障提前预警、维修自动派单”。这种从“卖产品”到“卖服务”的模式转变，背后依赖的是云计算的弹性扩展、物联网的实时监控、AI的预测分析——技术不再是支撑工具，而正在成为产品本身。

与此同时，IT部门的角色也在被重新定义。当业务端要求越来越敏捷、财务端要求成本越来越透明时，IT不能再只是“修电脑、管服务器”的后勤部门，而必须站到前台，成为企业转型的核心引擎。但对于大多数传统制造企业来说，这一步并不轻松。

1.2PumpTech是做什么的？

主角公司PumpTech就是一家典型的老牌制造企业。它在泵设备领域深耕了三十年，产品覆盖水处理、化工、制药、油气等多个行业，以工程设计扎实、客户服务可靠在业内积累了稳定的市场地位。过去的成功依赖一套成熟的产品销售加售后维护的商业模式，核心IT系统则是一套运行了十几年的SAP ERP。

1.3 PumpTech想做什么？

面对市场变化，PumpTech的决策层做了一个判断：继续只卖硬件没有未来。它决定启动一项名为“泵即服务”的新业务——不再是卖一台泵收一次钱，而是按泵的运行时长和输送流量收费，把设备监控、预测维护、能耗分析全部打包成订阅式服务。这个构想需要一套全新的技术底座：一个能实时收集设备运行数据的物联网平台、一套支撑订阅计费和客户自助服务的云系统。

但这里有一个关键策略，决定了整个转型的难度和走向。

PumpTech不打算把传统业务一刀切掉。传统卖泵的生意还在赚钱，客户关系还在，供应链还在，不能停也不该停。所以管理层定下的策略是双模态并行：传统业务继续保持稳定运行，核心ERP不能动，客户交付不能断；与此同时，在新业务上投一支“敏捷小分队”，用云原生技术快速搭建“泵即服务”平台，跑通了再逐步扩大。两条腿走路，一条求稳，一条求快。

这个策略在商业上很务实，落到IT上却是难上加难——新老系统要怎么并存？谁和谁集成？同一家公司的不同业务模式，数据和技术架构怎么搭？这才是PumpTech转型中最棘手的问题。

阅计费和客户自助服务的云系统、以及一条连接新老系统的无缝数据通道。

1.4 PumpTech卡在哪里？

双模态并行策略听起来务实，一落到IT上却把矛盾放大了。

传统业务这边，核心SAP ERP已经跑了十几年，其间堆叠了大量定制代码，改动成本高、风险大，但传统业务还在赚钱，核心系统不能停，团队不敢动。新业务这边，“泵即服务”要求快速迭代、灵活上线，最合适的方案是直接在云上搭建一套全新的技术栈——订阅计费、设备监控、客户自助门户，全部采用云原生架构。

问题是，这两套系统不是各跑各的——它们共用同一批客户、同一批泵、同一批供应商。传统系统里的客户主数据和新平台的设备数据必须打通，旧ERP里的财务数据和新业务的订阅收入必须对账，各跑各只会跑出数据孤岛和流程断裂。

更头疼的是团队层面的拉扯：老系统团队习惯了稳定和流程，新业务团队追求速度和试错，两套文化、两套节奏、两套技术栈，怎么放在同一家公司里和平共处？PumpTech的困境不是“旧系统太老”或者“新业务太难”这种单一问题，而是双轨并行带来的架构撕裂和组织撕裂同时发作。

下面是PumpTech当前的IT架构图，直观感受一下。

我们来把它拆开细看：

居中的“大脑”：SAP ERP 系统，装着财务（FI/CO）、销售（SD）、物料（MM）、生产（PP/DS）等所有核心业务。问题在于，它太“重”了，高度定制化，牵一发而动全身。
外围的“四肢”：SAP EWM（仓储）、SAP TM（运输）、SAP HCM（人力）等，这些都是专业系统，但它们和“大脑”之间，以及它们彼此之间，靠着复杂的接口连接。
两个特别的存在：左下角的Non-SAP MES和右下角的Non-SAP CRM，一个管车间，一个握客户，偏偏都不是SAP家族成员。

关于上面的第三点这里有一个形象的比方：如果把图中央的SAP ERP和周围一圈SAP系统看作一个家族内部的亲戚，它们虽然各管一摊，但用的是同一套语言、守的是同一套家规，要做什么大事，关起门来商量一下就定了。然而左下角的Non-SAP MES和右下角的Non-SAP CRM，更像是生意上的伙伴。它们很专业，也有自己的规矩和利益。当家族想做某项决定时，内部好商量，可要让外面的伙伴也跟着改，就不能直接下命令了，而是得正式去谈、去协调。这样一来，每一次跨系统的业务调整，都不只是改个接口那么简单，而是一场需要多方点头的“外交谈判”。

架构撕裂的痛点，恰恰就在这里：不是技术上连不通，而是业务的割裂、是治理上难协同。

面对这样一张“蜘蛛网”，我们的第一个念头不能是“我要画一张更漂亮的图”，而必须是：“在这张网上，我先动哪一根线，既能解开一个结，又不会把整个网扯烂？”

这就是接下来要解决的问题。书中用一套“可迁移框架”，来回答这三个核心问题：

怎么从这团乱麻里，找出下刀的第一根线头？
凭什么标准，来决定哪些模块先动、哪些后动、哪些先不动？
选了之后，怎么保证新旧两条轨道上的团队，不会互相绊倒，反而能互相借力？

接下来，就让我们一起看看应该如何拿着“企业架构”这把手术刀，来解剖PumpTech这只“蜘蛛网”。

2. SAP EA在云转型案例中的应用

2.1SAP EA的解决方法

面对这样一张蜘蛛网和一条条被截断的业务流程，应该从哪下手？

PumpTech的架构师没有凭空创造一套方法。他们用的是SAP EA Framework里的“模块化方法论”。我们上一篇文章讲过，这套方法论把企业架构工作拆成了一组可复用的“模块”——就像一个工具箱，你可以根据项目需要，从中挑选趁手的工具，而不是每次都从零开始。

总体的方法是，通过多次迭代来完成目标，而每次迭代根据实际情况选取合适的SAP EA模块（工具）。

那么，面对PumpTech的这个情况，首次迭代应该挑哪些“工具”呢？书中直接给出了答案：

图2.1 PumpTech转型选用的EA方法论模块

2.2各个模块具体操作

这里前面四个核心模块做深度展开，其余的融合在后面精简论述——不是它们不重要，而是避免把所有细节堆砌给大家，反而模糊了主线。

(1). 转型准备度 - 先做一次全身体检

架构师团队做的第一件事，不是动手设计，而是给PumpTech做了一次“全身体检”。在SAP EA方法论里，这个模块叫转型准备度（Transformation Readiness），它的核心逻辑是不靠感觉判断，而是把两套数据摆在一起交叉验证。

一套叫运营数据（O-Data），从系统里直接往外拉。比如SAP Readiness Check告诉你现有ERP离S/4HANA还有多远，EarlyWatch Alert暴露系统的健康隐患，ABAP Test Cockpit扫描出自定义代码的复杂度，Signavio Process Insights则用数据还原业务流程的真实效率。

另一套叫体验数据（X-Data），来自发给全公司利益相关者的问卷。问题覆盖了六个维度：员工对云和数字化的接受度、对公司战略方向的理解和认同、自身技能是否跟得上、对当前IT架构和安全性的信心、对现有流程顺畅度的感受，以及过往项目管理的经验教训。

两套数据一叠加，书中产出的评估报告直接锁定了三个重要问题：

战略与执行脱节：云落地太慢，员工还根本不明白为什么要上云。
核心里有“脏东西”：ERP堆满定制代码，系统僵化，创新无从谈起。
云与本地有裂痕：新旧系统没打通，正在制造新的数据孤岛。

(2). 业务流程 - 看清旧地图和新航线（定性）

体检做完，下一步是钻进PumpTech真实运转着的业务流程里。

这个模块的任务是两条线并行：一条审视传统业务，一条定义新业务。

审视传统业务，核心是“找堵点”。团队没有把所有流程都翻一遍，而是先做筛选——挑出交易量大、业务关键度高、而且在新旧模式切换中变化最大的流程段。PumpTech选的是“制造运营”流程。深度拆解后，两个最痛的堵点浮出水面：质量检验和返工处理。它们的问题指向同一个根因——与Non-SAP MES之间的复杂接口。数据要经过多重转换，返工订单有时干脆对不上，需要手工修正。这些不是参数调优能解决的问题，而是架构层面的硬伤。

图2.3 业务流程与系统映射图（传统业务）

定义新业务，核心是“找差距”。“泵即服务”需要的流程和老业务完全不同：订阅计费、服务配置、预测维护、资产全生命周期管理、实时分析报告——这些流程在现有架构里根本不存在。团队没有从头发明，而是从SAP参考业务架构里直接拉出这五条标准流程，再拿PumpTech的具体需求去做匹配分析。目的是搞清楚：标准功能能覆盖多少，哪些需要扩展或自建。

两条线拼在一起，结论很清晰：传统业务的堵点在异构系统对接上，新业务的缺口在流程能力缺失上。

(3). 业务流程智能 - 用数据做交叉验证（定量）

上一步，团队通过流程图和系统映射图，定位出了传统业务的几个堵点。但这里有一个方法论上的隐患：这些堵点，说到底还是架构师和业务部门一起讨论出来的，本质上是经验判断。

所以团队紧接着引入了一个关键动作：业务流程智能（Business Process Intelligence），用系统里真实的运行数据，对前面的主观判断做一次客观校验。

核心工具是SAP Signavio Process Insights。它可以直接从PumpTech现有的SAP ERP里自动采集流程执行数据，然后分析出真实的瓶颈和变异，而不是听人描述“这里好像有点慢”。同时，它还能针对发现的问题，直接推荐SAP标准的改进方案。

这一步的价值不在于发现了某个具体数字，而在于它改变了诊断的性质——从“我觉得这里有问题”进入到“数据告诉我这里有证据”。上一步是经验判断，这一步是数据验证。两者叠加，才算完成了对PumpTech现状的完整诊断。

在SAP的方法论里，这两步恰好对应了业务流程转型闭环的前两个节点——发现（Discover）和分析（Analyze）。后面的实施（Implement）和运营（Operate），会随着案例的推进陆续展开。

图2.4 业务流程转型闭环

诊断做完，堵点验证完，差距也量化了。至此，“把脉”完成，下一步“开方”。

(4). 应用架构 - 画出未来的样子

在“把脉”完成之后，架构师团队要回答整个案例中最核心的一个问题：PumpTech未来的IT架构，到底长什么样？

这就是应用架构（Application Architecture）模块的任务。书里产出的答案就是下面这张图：

图2.5 PumpTech目标架构全景

这张图一摆出来，PumpTech双模态并行的战略意图立刻有了清晰的技术落脚点。

左边是传统业务的地盘。跑在SAP S/4HANA Cloud Private Edition上，财务、销售、采购、生产、质量、仓储，原有核心业务全部保留。注意几个被特别标出的能力——Central Finance、Central Procurement、Group Consolidation——这些是PumpTech决心在传统业务侧做“集中式服务”的信号。以前各区域各自为政的财务和采购，现在要收到一起，减少重复、统一标准。

右边是新业务的阵地。跑在SAP S/4HANA Cloud Public Edition上，这是为“泵即服务”量身打造的全新数字核心。它和左边的私有云版本形成镜像——两边都有财务、销售、服务，但服务的业务逻辑完全不同：一个卖泵，一个卖泵的产出。

底部是公共底座。 SAP BTP上的Asset Performance Management（资产性能管理）、Subscription Billing（订阅计费），以及SAP Business Network Asset Collaboration（资产协同网络），这些云原生服务一起构成了“泵即服务”的产品力核心。没有它们，预测维护、按用量计费、客户自助服务都是空话。

这图的背后隐藏着几个关键的架构决策：

第一，为什么选两朵不同的云？这是部署方式的选择。传统业务需要灵活性和可控性，所以选Private Edition；新业务追求速度和标准化，所以选Public Edition。

第二，为什么要做集中式服务？传统业务跑了几十年，财务和采购散落在各区域，流程五花八门、数据口径不一。在转型中趁势做集中化，既是为了降本，也是为了后续打通和新业务之间的数据通道。

第三，新业务的核心能力靠什么支撑？ “泵即服务”的订阅计费、预测维护、设备数据协同，这些能力在传统ERP里根本不存在，必须由SAP BTP上的云原生服务来填补。

这张图是整个案例的分水岭。前面的诊断和分析，最终都收敛到了这张图上。后面的集成怎么搭、实例怎么分、路线图怎么排，全部围绕这张目标蓝图展开。

（5）实例策略 - 一个ERP还是两个？

PumpTech有两摊业务，一稳一快，逻辑完全不同。团队评估了三种方案：全放一个实例、按区域拆分、按业务模式拆分。最终选择第三种——传统业务跑SAP S/4HANA Cloud Private Edition，新业务跑Public Edition。理由是：新业务要的是速度和标准，老业务要的是灵活和可控，硬塞一个实例里，两边都难受。

（6）集成- 把截断的流程重新缝起来

前面诊断出的最大硬伤——Non-SAP的CRM和MES把核心流程截断了——现在是时候缝合了。团队采纳了SAP Integration Solution Advisory Methodology，定下两条规矩：新的集成走SAP Integration Suite，旧的SAP Process Orchestration逐步退出现役。

（7）AI与自动化 - 新业务的发动机

“泵即服务”的核心卖点是预测维护和智能计费，技术底座就是AI。团队把PumpTech的业务能力逐个拆开，识别出财务预测、营销线索评分等几个高自动化潜力的领域，匹配了SAP Business AI里的预置智能服务。

（8）可扩展性 - 让老系统也能跟上新步伐

新业务在往前冲，老ERP不能拖后腿。但核心代码不敢动，怎么满足新需求？答案是走Clean Core策略：能不改核心就不改，非改不可的用SAP BTP侧边扩展。为此团队还设了一个解决方案标准化委员会，专门审每一个扩展需求——不是必需的，一律不批。

至此，“开方”步骤完成，下一步“绘径”。

（9）计划与路线图 - 排出一条可行的时间线

所有技术决策都有了，最后一个问题是：先做什么，后做什么？路线图分了三波。

第一波，把现有ERP迁到私有云，稳住传统业务；

第二波，把分析和集成搬到BTP上，打通数据通道；

第三波，启动“泵即服务”新平台的搭建和IoT能力的注入。

（10）过渡方案评估 - 选一条最稳的路

路线图给的是方向，但每一步的走法不止一种。团队比较了三种过渡方式：Brownfield（原地升级）、Greenfield（推倒重建）和Selective Data Transition（选择性数据迁移）。最终选择混合策略：传统ERP用系统转换先上私有云，后续再慢慢做“回归标准”的清理；新业务直接走Greenfield，轻装上阵，不背历史包袱。

讲到这里，PumpTech走完了首轮EA规划的全过程——从体检、找堵点，到画出目标蓝图，再到排出分波次的路线图。但必须说明：这只是第一次迭代。

书里在计划与路线图中也展示的很清楚：PumpTech的转型路线至少切成了三个时间窗口。2025到2026年先完成ERP上私有云、稳住传统业务；2026到2027年启动“泵即服务”新平台的搭建和资产管理的云化；2027到2028年再完成HR上云、供应链执行系统嵌入S/4HANA，并最终形成完整的双模态架构。

所以，EA不是一次规划、一锤定音。它的正确打开方式是迭代——每一轮只做当前阶段最需要决策的事，下一轮再根据新的事实和新的约束，重新校准方向。

3. 关于该案例的思考

这部分不是书中的内容，只是阅读后的一些思考。

案例的最大价值可能不在于给我们提供具体操作，而在于通过例子提供一套解题思路、解题的模板。通过这个案例，我们可以将SAP EA应用的步骤归纳为如下几个关键步骤：