上一篇文章《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逐步退出现役。7AI与自动化 - 新业务的发动机“泵即服务”的核心卖点是预测维护和智能计费技术底座就是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应用的步骤归纳为如下几个关键步骤摸家底用运营数据和体验数据交叉验证搞清楚“人、系统、流程”三个维度的真实就绪状态。找突破口扫描业务流程全貌锁定“痛得最深、改得动、对业务影响大”的那个环节作为切入锚点画目标图基于突破口设计端到端的目标应用架构让所有利益相关方看到“未来长什么样”。排路线图把目标拆成几个关键决策实例怎么分、集成怎么缝、扩展怎么做再排定优先级和分波次的实施节奏。再迭代每一轮交付后用新的事实和数据重新校准。新的瓶颈暴露了就重新走一遍“摸家底→找突破口”的循环新的约束出现了就调整路线图的优先级和节奏。对比了下书中其他案例虽然选取的模块或具体情况不同但是总体上依然大致上述步骤。另外在案例首次迭代选中书本直接给出了这10个模块的“结果”而并没有说明为什么选这些不选别的现实中我们又需要一套有据可依的决策框架。查阅一些资料后发现似乎可以用“三维评估矩阵”核心是三个问题这件事离“钱”有多近业务价值动它一个要先动多少个其他系统依赖关系万一搞砸了后果有多严重实施风险把PumpTech手头几个候选事项放进这个矩阵局面就清晰多了三个维度的不同组合“低依赖 中价值 低风险”的先动先把IaaS这条腿迈出去让团队和决策层尝到云转型的甜头积累信心和经验。“高价值 中风险”的做核心攻坚成立“尖刀连”立即启动“泵即服务”新平台搭建。这是公司未来的命脉不能等。“高价值 高依赖”的作为基础工程并行推进客户和设备主数据的统一是未来打通全流程的地基。它不能停但要预留足够的周期。“高风险 高依赖”的分阶段后置核心ERP的S/4HANA改造牵一发动全身必须在充分验证、风险可控的前提下分步走。所以转型的决策结论不是“选一个模块”而是“定一个节奏”——同步启动分波次交付。书中直接给出了10个模块的结果却没有展开“凭什么选这些、不选别的”。这完全可以理解——书本不可能遍历所有可能的组合方式那会冲淡主线。但作为读者和从业者恰恰是这个追问逼着我们往前走了一步把选择逻辑从“结果”还原到“过程”。当我们能回答“凭什么选这些、不选别的”那一刻才真正开始理解EA的选择逻辑而不只是记住了一个模块清单。4. 写在最后从一张蜘蛛网般的架构图出发我们跟着PumpTech走完了一整圈体检、找堵点、数据验证、画目标蓝图最后排出一条分波次的路线图。通过这个案例的分析我们尝试总结了两样东西一是五步法解题思路摸家底、找突破口、画目标图、排路线图、再迭代。这是流程层面的通用解题节奏。二是三个维评估矩阵面对一团乱麻不知道该先碰哪根线头时拿三个问题筛一遍——这事离钱有多近动它要先动多少个别的搞砸了后果有多严重答案的可能就会比我们想象中的清晰。这里总结得不一定成熟但是这是我们探索的开始。更多文章欢迎关注WX日行一步。#SAP系列链接笔记《SAP R/3 Business Blueprint》- SAP的设计哲学笔记《The architecture of SAP ERP》 - SAP的模块设计《SAP S/4HANA Architecture》——清洁核心ERP的下一站上《SAP S/4HANA Architecture》——清洁核心ERP的下一站下《Enterprise Architecture with SAP》— 从“项目思维”到“企业级全局视角”