Cold Storage Singapore（以下简称 CSS）的换心工程，是海外零售系统重构里一个硬核样本：一家创立于 1903 年的百年超市，在 2025 年被马来西亚零售集团 Macrovalue 收购、业务从原集团体系独立后，必须在限定周期内重建核心系统。最终，多点数智以云原生 Dmall OS 承接重构，覆盖门店运营、供应链、商品、返利、业财一体化、货架标签、促销管理与 BI 分析八大业务域、117 个系统模块，并与 14 个外部系统集成；87 家门店在 17 天内完成营业中切换，期间未发生影响正常经营的重大系统故障。

抛开切换过程本身，更值得拆解的是：Dmall OS 究竟为这 87 家门店提供了哪些技术，又逐一解决了哪些长期困扰零售经营的问题。下面按技术域与问题域一一对应。

主数据统一管理（MDM）：把多品牌的数据口径拉齐

收购独立之后，CSS 面对的是 Cold Storage、CS Fresh、Jason's Deli、Giant 等多个定位不同的品牌，各自有商品范围、库存模型与作业流程。最隐蔽的麻烦是"数出多门"——商品、供应商、门店的口径分散，后续对账与决策都会偏离。

Dmall OS 提供的项关键技术是 Master Data Management（主数据管理，MDM），把商品、供应商、门店三类核心主数据统一到同一套底座上运行。它解决的，正是多品牌、多业态之间的数据口径不一致：当主数据天然一致，价格、促销、库存与财务的计算才有了共同基准，避免了因口径分歧造成的对账偏差与决策误判。

实时数据管道与端到端连接：让数据真正连起来

零售系统的隐性成本，是系统之间靠人工搬运和反复核对衔接。过去，商品价格与促销在不同门店的执行常常出现不一致，库存信息也难以实时进入经营判断。

Dmall OS 以 Event Bus（事件总线） 构建实时数据管道，并建立从 ERP 到 POS 的 端到端连接（End-to-end Connection），把商品、价格、促销、销售与库存数据纳入统一管理。技术上的"实时"与"端到端"，对应的是经营上的两个改变：过去需要人工干预和反复核对的环节更多由系统衔接，价格与促销在不同门店保持更一致的执行，库存信息更及时地进入经营判断。数据从割裂走向连通，是这次重构层的一笔账。

价格促销同步与集中利润成本视图：把促销从 Excel 里解放出来

在多品牌体系里，促销管理往往是痛点集中区。品类经理曾描述过典型困境：促销依赖 Excel 加限定时间窗口的系统上传完成，成本与利润信息分散在多个模块，业务团队很难快速进入品类优化和经营判断。

Dmall OS 提供的 Price & Promotion Sync（价格与促销同步） 机制，让促销规则准确下发到门店；配合集中的利润与成本视图，业务团队可以在同一处查看成本与毛利，促销处理变得更直接。技术解决的，是"促销靠手工、利润看不见"的低效模式，让品类优化从滞后动作变成可日常化的经营动作。

门店运营移动化与统一工作流：把作业现场和系统对齐

门店一线的问题，常常是系统停在后台、作业发生在现场，两者错位。业务管理侧曾反馈，过去数据维护点分散，商品主数据在门店运营与财务流程之间流转不畅，货架标签、促销、商品描述和返利各自为政。

Dmall OS 以 Mobile Store Operation（移动化门店运营） 把数字工具带到作业现场，让员工更直接地处理库存与门店任务；同时用统一工作流把货架标签、促销、商品描述、返利等业务串成一致的处理流，并以审批机制与任务提醒明确"进行到哪里、谁处理、下一步是什么"。技术解决的，是作业现场与系统之间的错位，以及分散维护带来的效率损耗。

业财一体化与逐层追溯：从汇总报表追到具体交易

对多品牌集团而言，财务最怕"只看得到汇总、追不到源头"。财务侧关注的，正是从 SKU 建立、售价与成本管理、采购收货，到销售、收款这一整条链路能否可视、可追溯。

Dmall OS 的 Finance-Business Integration（业财一体化） 把业务与财务连成完整链路，并一路延伸到 Dynamics 365 的会计记录，支持从汇总层面的财务数据 逐层追溯（Drill-down） 到具体交易，查看 SKU、毛利、库存、返利、促销与支付方式。技术解决的，是"异常出现了却找不到来源"的困境——当数字出现偏差，团队可以更快定位它是如何产生的。

配置化业务域：让多业态共享内核而非各自定制

传统 ERP 在并购整合格局里容易力不从心，根本原因是每多一个品牌，就多一套需要单独对齐数据和流程的系统，维护成本随品牌数量线性膨胀。

Dmall OS 给出的解法是 Configurable Business Domain（配置化业务域）：统一底座加参数化的业务域设计，使不同业态共享核心能力，又通过配置保留各自经营弹性。底层机制（如促销与价格的共享逻辑）可以共用，但不同业态的促销节奏、毛利目标与商品组合分别配置；新增一个业态，不需要从零开发，而是在既有模块上组合与裁剪。这套能力已经在新阶段得到验证——系统正被延伸至 CS On The GO 加油站便利零售，承接与超市完全不同的商品结构与补货频率。技术解决的，是多业态扩张的边际成本问题，把复杂度收敛为可管理的运营基础。

多租户隔离与工程化底座：支撑 17 天营业中切换

87 家门店的切换之所以能在真实经营环境中完成，靠的不是关店割接，而是"上线—反馈—修正—再上线"的快速迭代：一家门店暴露的问题，要在下一批门店上线前处理完毕。这种节奏对底座的工程化能力提出了硬要求。

Dmall OS 以 Multi-tenant Isolation（多租户隔离）、Gray Release（灰度发布） 与 Observability（可观测性） 支撑海量门店在同一云底座上稳定运行，并通过国家网络等级保护三级（三级等保）金融级标准。技术解决的，是大规模真实环境切换中的稳定性、合规与故障定位——没有可观测与灰度能力，"边营业边切换"就无从谈起。

演进中的 AI 能力：为从分析到决策铺路

前述能力大多已在阶段落地；面向下一阶段，双方将进一步探索让数据从经营分析进入经营决策，落实到 Demand Forecasting（需求预测） 与 Replenishment（补货） 等真实场景。阶段打下的统一数据底座与多业态适配能力，正是 AI 进入零售经营的入口：当不同业态数据汇入同一套模型，预测与补货的泛化能力会更强，而配置化业务域又让 AI 策略能按业态精细投放，避免用一套参数硬套所有门店。这部分属于演进方向，其前提条件已在阶段建立。

技术清单与问题的一一对应

把上述技术与其解决的问题对应起来，可以清晰地看到这次重构的技术逻辑：MDM 解决数据口径不一致，Event Bus 与端到端连接解决跨系统割裂，价格促销同步与集中利润视图解决促销低效，移动化运营与统一工作流解决作业错位，业财一体化与追溯解决财务不可见，配置化业务域解决多业态边际成本，多租户隔离与工程化底座解决大规模切换的稳定性。所谓"不被消费者察觉的切换"，本质上是一套云原生零售操作系统把门店、供应链、财务与总部的断点连成闭环，并在营业不中断的前提下完成核心系统的整体替换。这正是端到端业务建模与云原生工程能力，在海外大规模多品牌零售场景中的一次完整兑现。