恭喜：微软关键计费系统，迁移至S/4HANA私有云！

近日，据SAP官媒报道：微软如何将SAP ECC计费系统迁移至S/4HANA私有云？

引言
通过广泛的代码测试和SNP的选择性数据迁移，微软确保了SAP BRIM系统（用于Xbox计费、及其他基于使用量的商务业务）的安全24小时切换。
正文
当微软将任务关键型财务应用程序从老化的本地SAP ERP中央组件(ECC)系统迁移到SAP的下一代ERP S/4HANA时，这个为期六个月的项目在数字化的走钢丝行动中达到了顶峰。
对于保存70 TB数据、并管理Xbox购买账单、Microsoft 365 Office应用程序订阅和企业协议等的系统来说，长时间的停机可能会带来灾难性的后果。
领导该项目的Microsoft SAP解决方案架构师梅琳达·范·洪斯霍滕（Melinda van Honschooten）指出：“这基本上就是我们的SAP系统，它是我们所有商务场景的后端……”
“这是一个非常大容量、高收入的场景，对我们的业务运营非常重要。”
微软必须煞费苦心地确保SAP计费和收入创新管理(BRIM-Billing and Revenue Innovation Management)应用程序在新ERP上正确运行，并且其数据正确。
对于如此庞大的系统，它必须在异常短的时间内完成转换。
SAP母舰的船只
微软大约15年前开始使用BRIM，随着更多业务线的加入，该软件的重要性逐渐增强。
但范洪斯霍滕表示，最近它已跟不上微软业务的发展。
她说：“我们意识到ECC中还存在一些阻碍我们处理大量数据和支持我们所需业务场景的能力……”
“能够保持规模扩张确实让我们处于困境。”
迁移到S/4HANA的另一个主要好处是其HANA内存数据库的读取性能，它比ECC的SQL数据库要快得多。
在ECC上需要8个小时的月末会计流程会对大容量、面向批处理的系统产生累积影响，但在S/4HANA上可以减少到半小时。
“我们的一些最大工作的时间逐渐变得越来越长。”
“而且，由于我们通过系统处理的工作量很大，我们在会议安排时间方面遇到了问题……”
能够追求现代集成策略并使用人工智能来优化流程是迁移的其他重要原因。
此外，范洪斯霍滕表示，新功能仅在BRIM的S/4HANA版本中可用。
SAP承诺在2027年底终止主流ECC支持是另一个因素。
她说BRIM是微软迁移到S/4HANA的第一个“真正庞大”的系统。
该公司自20世纪90年代以来一直是SAP的主要客户，并且正在经历从ECC的逐步、多阶段迁移。
她说，在BRIM之前，它已经迁移了一个小得多的主数据治理系统，并直接在S/4HANA上为其美国联邦政府业务实施了一个系统。
该公司仍然拥有一套大型ECC系统，该系统已经使用了近30年，用于以财务为中心的流程，例如核心财务、采购到付款、订单到现金以及人力资源。
“母舰SAP系统仍在ECC上，我们正在进行一个多年期项目，将其也迁移到S/4 HANA，但这是一项困难得多的工作……”
所有SAP系统都在Microsoft的公共云Azure上运行。
选择性迁移绝非易事
在经历了几次尝试未果后，微软于2021年左右开始探讨将BRIM系统迁移至S/4HANA，但随后搁置了该项目，转而优先处理一个重大的信贷与催收项目（Credit and Collection project）。
2024年，一支精简团队开始了实质性的规划工作，而完整的项目团队则于2025年2月全面投入运作。
微软由约50名SAP专家组成的团队负责BRIM代码的迁移工作，其中包括重构与测试，以确保其在S/4HANA环境下能正常运行。
IT咨询公司SNP Group负责数据迁移，而来自SAP高级咨询服务部门MaxAttention的团队则担任可信顾问。
据范洪斯霍滕介绍，业务负责人与合作伙伴工程团队执行了回归测试，以确保新系统功能正常。
大量工作都集中在迁移BRIM庞大的数据库上。
“系统中最大的数据表包含超过120亿行数据……”
“我们每天既要新增数百万行数据，也要归档数百万行数据。”
初步评估显示停机时间将长达五天，这是业务部门无法接受的。
“除非能把项目工期压缩在周末完成，否则我们根本无法开展这个项目……”
因此，微软与SNP共同探讨如何将停机窗口缩短至常规时长范围内。
他们确定，若在美西时间周五下午停机，并于周日中午前恢复上线，方案是可行的——因为此时正值马尼拉的周一上午，而微软在马尼拉设有大规模的离岸运营中心。
这样一来，停机窗口便缩短到了24小时。
为了将数据迁移工作控制在可管理的范围内，微软选择了SNP的Bluefield选择性迁移方案，该方案仅将特定的数据和流程迁移至S/4HANA。
相比之下，Brownfield（棕地）迁移法则是在几乎不改动原有内容的情况下迁移所有数据，这意味着需要做出的决策较少。
但这种方式存在两个主要弊端：过时的流程和冗余数据往往会被带入新系统，且部分高级功能未被启用。
SNP表示，Bluefield方法能让企业摒弃低效环节，在利用新平台实现现代化的同时，又能获得“棕地迁移”（brownfield migration）所具备的可靠性与稳定性。
SNP首席技术官斯蒂尔·阿比尼（Steele Arbeeny）指出：“总的来说，选择性迁移意味着你不必全盘迁移整个系统……”
“比如你可能拥有10年的历史数据，但只想迁移其中5年的；或者你只想迁移特定产品线的数据。”
他表示，最终结果将是一个经过优化、占用资源更少且成本更低的系统。
范洪斯霍滕介绍说，利用SNP的方法和工具，他们采取了分阶段实施的策略：先将大量相对静态的数据预先加载到目标系统，等到正式上线（go-live）的那个周末，再仅迁移“增量数据”（即迁移过程中发生变化的数据）。
她表示，团队无需编写复杂的数据转换规则，而是依靠SNP和微软的数据验证工具，确保增量数据100%准确无误，并能精确捕捉所有变更。
此外，在系统上线后，他们还使用了SNP名为Kyano Validate的工具，对数以万亿计的数据字段进行了验证。
“我们将迁移过程拆分为‘在线运行阶段’和‘停机阶段’。在线运行阶段，系统保持正常运转，我们迁移往年的非活跃数据——也就是那些不会再发生变化的数据……”
“我们在系统运行期间完成这部分数据的迁移；随后在停机窗口期，我们只需处理‘追赶’任务，即迁移那些在在线迁移阶段发生变动的数据。”
在整个停机窗口期内，SNP的数据迁移工作占据了大约一半的时间；而微软则利用另一半时间，通过启动和停止各类流程等方式，验证系统的正确性。
斯蒂尔·阿比尼指出，鉴于BRIM业务的全球化特性，系统规模庞大、交易量巨大且允许停机的时间窗口极短，这便需要额外的基础设施、硬件和处理能力，以便在有限的停机时间内完成数据传输，实现“让大象穿过针眼”般的艰巨任务。
据其官网显示，团队在一个与生产环境完全相同的沙盒中进行了全规模的模拟迁移，并在整个过程中维持“双重系统架构”（dual landscape）以确保安全。
关于BRIM本身的迁移，范洪斯霍滕指出，挑战源于ECC与S/4HANA在银行账户管理方式上的差异。
“如果某个自定义字段是按旧方式实现的，那么要对一张包含100亿行数据的表进行原地转换，难度极大……”
“相比之下，先建立一张空表，再将数据迁移进去，要容易得多。”
这意味着必须在新系统中重新实现这些自定义字段。
此外，团队还对若干货币数据进行了调整，以符合S/4HANA所使用的三字母ISO货币代码标准。
此次转型如何让微软受益
2025年8月系统上线后，在确认新的BRIM系统运行稳定之际，团队便着手处理一系列改进工作。
范洪斯霍滕说道：“系统转换完成后，我们得以实现一些重大改进，并迅速取得了成效。”
其中一项举措是调整批处理计划，从而加快数据处理速度，并降低月末会计结算的风险。
另一项举措是改造数据服务接口，摒弃了以往依赖Web Services和远程函数调用（RFC）技术的旧版SAP技术。
她表示，这使得系统与微软前端系统的集成性能得到了显著提升。
此次迁移还推动了Microsoft Dynamics 365 ERP系统的改进，该系统作为微软信贷与催收业务的前端平台使用。
如今，SAP Fiori用户体验（UX）框架可以直接嵌入到Dynamics 365中。范洪斯霍滕认为，这对处理小批量催收业务起到了巨大的推动作用。
过去，这类业务往往需要“跨系统切换”式的手动操作，即员工必须将数据从旧版SAP界面手动复制到新版界面中。
斯蒂尔·阿比尼指出了数据处理速度提升所带来的连锁效益：“当夜间批处理耗时从12小时缩短至4小时后，便腾出了大量时间与资源去开展其他工作……”
“这得益于技术栈及应用层面的创新。有了这些富余的算力，在同等基础设施规模下便能处理更多任务，这也为应用‘AI智能体’（Agentic AI）铺平了道路。”
赋能AI智能体
范洪斯霍滕表示，她的团队确实正在开发AI智能体，主要针对现金核销（cash applications）和催收业务（collations）——这些环节需要将客户汇入的款项与相应的发票进行匹配。
在基于ECC系统启动的现金核销转型项目中，匹配率仅为30%；而迁移至S/4HANA系统后，这一比例已大幅跃升至约85%。
此外，公司还在实施智能催收流程，该流程不再拘泥于固定的时间表，而是能更深入地了解每位客户的具体情况。
具有自主能力的AI智能体有助于实现Dynamics 365中入站电子邮件处理及其他应收账款催收流程的自动化。
“我们正在系统性地梳理该领域的所有工作流程，以确定如何减少响应客户咨询所需的人力，并预测客户何时可能对发票提出异议，从而在争议发生前采取行动……”
通过促使更多客户按时付款，应收账款周转天数（DSO-Days Sales Outstanding）等指标有望得到改善。
云ERP的“更纯净核心”（Cleaner Core）方法
SAP及其众多合作伙伴一直在推广一种“纯净核心”（Clean Core）方法论，主张ERP系统的核心应专注于标准业务流程，避免进行定制化开发。
然而，斯蒂尔·阿比尼坚持认为，微软应将BRIM系统迁移至私有云版本的S/4HANA，而非往往严格执行“纯净核心”规则的公有云版本。
他认为“纯净核心”这一概念过于简化了问题，指出微软的一些定制化功能至关重要，因此“更纯净的核心”（Cleaner Core）是一个更切合实际的说法。
“我们可以做得更好，但指望彻底消除所有关键的定制化功能是不现实的……”
“这些功能的存在是有原因的——当初构建它们，正是为了塑造企业独有的业务特性。”
范洪斯霍滕澄清道，从ECC迁移到S/4HANA的项目并非旨在重新实施所有的定制化功能。
尽管如此，SNP采用的Bluefield数据迁移方法实现了针对性的改进，使公司向“更纯净核心”的环境迈进了一步。
她举例提到，按照“纯净核心”标准重新实施自定义字段就是其中一项改进。
她建议计划进行类似数据迁移的企业保持方案简洁，避免贪多求全，同时在项目进度表中为模拟迁移预留充足的时间。
“我们从中学到了很多，而且每一次都在进步。正因为有了多次演练的机会，我们最终得以实现了一次相当干净利落的系统转换。”