一、从车间里的一张领料单说起
做企业采购的人，大概都见过这样的场景：车间设备停着等一个密封圈，采购员翻着手机通讯录挨个问供应商有没有现货；仓库角落里堆着几年前买多的轴承，账上却查不到具体放在哪个货位。MRO品类就是这样，单笔金额不大、频次高、长尾商品多，采购分散在各个厂区，价格不透明，库存和需求经常对不上。我们这次复盘的项目，就是围绕这些问题，为一家装备制造行业的头部集团做MRO商城开发。项目采用了混合云部署的方式，既要把核心数据管住，又不能让一线用户觉得系统慢、难用。下面把方案设计、开发实施和上线推广的过程拆开讲，给正在推进企业MRO数字化采购的同行做个参考。
二、客户是一家装备制造行业的头部集团
这家集团在装备制造领域深耕多年，下属有多个事业部、生产基地和维修服务公司。它的MRO采购有个特点：总量在集团采购盘子里占比不算高，但品类跨度大，从标准紧固件、轴承、密封件，到电气元件、劳保用品、工具耗材，再到部分设备备件，都在MRO范围内。集团总部想推进集中采购，把通用物资的议价权收上来；但一线生产单位更关心的是响应速度，设备停线等不起漫长的审批和寻源流程。
总部要管、一线要快，这个矛盾从一开始就摆在项目组面前。另外，集团下面不同单位的采购习惯差异很大，有的习惯用年度框架协议，有的习惯临时询价，有的甚至还在用纸质单据走审批。这些现实情况决定了，MRO商城不能做成一个简单的电商网站，而要能适配多组织、多角色、多流程的采购场景。
三、原有采购模式卡在哪些地方
（一）需求端：分散且不透明
①各厂区、各车间自己提需求、自己找供应商，同类物资的采购价格在不同单位之间差异不小，集团层面很难掌握真实采购成本。②需求描述不统一，同一种轴承，有人写型号，有人写设备编号，有人写供应商料号，采购员只能靠经验判断是不是同一个东西。③紧急需求多，线下沟通靠电话和即时通讯工具，需求一多就容易漏、容易乱，采购员大量时间花在确认和催货上，而不是花在寻源和议价上。
（二）供给端：供应商多而杂
①供应商准入缺少统一标准，有的供应商只在某个厂区有合作，资质和履约情况没有沉淀到集团层面。②同一品类往往有多家供应商供货，但没有形成清晰的比价和考评机制，价格谈判缺少依据。③供应商的交付、质量、售后表现散落在各个单位的台账里，集团想搞集中管理，却连一份完整的供应商画像都拿不出来。
（三）管理端：数据对不上
①采购系统、仓储系统、财务系统各管一段，订单、入库、发票、付款之间的数据靠人工核对，对账周期长。②库存数据不准确，常用件缺货和长尾件积压同时存在，资金占用和停机风险都不小。③审批流程线下走，谁批了、批到哪一步、什么时候批的，查起来费劲，审计和合规部门也有意见。
这些问题的根子，不完全在系统上，更多在采购管理思路和基础数据上。项目启动时我们就判断，如果只做一套线上商城，而不解决品类编码、供应商主数据和流程标准的问题，上线后大概率还是把线下的乱象搬到线上。
四、混合云部署下的MRO商城整体方案
（一）需求分析：先划边界，再谈功能
项目组没有一上来就画功能清单，而是先和集团采购部、各事业部、生产基地、财务、信息中心分别做了访谈，把需求分成几类：①集团层面必须统一管住的，比如供应商准入、品类主数据、采购价格、审批规则；②适合各组织自行配置的，比如本单位内部的领用流程、库存策略、配送方式；③可以放到后续阶段再做的，比如部分非标备件的在线寻源、供应商协同排产。边界划清楚之后，MRO商城的功能范围就不再是越大越好，而是先覆盖高频、通用、标准化的MRO品类，把线上采购的习惯先养起来。
（二）方案设计：混合云部署不是简单的上云
这个项目最终采用的是混合云部署模式。核心的交易数据、订单数据、供应商主数据、结算相关数据放在集团自有的数据中心，满足数据安全和合规要求；商品检索、图片资源、前端静态资源、部分缓存服务放在公有云上，借助公有云的弹性能力扛住访问高峰。不同环境之间通过安全通道和接口网关打通，业务上是一个商城，部署上是多个环境协同。这样设计的好处是，集团不用把敏感数据全部交给第三方，又能让分布在不同区域的用户获得比较流畅的访问体验。
实际落地时，项目组重点解决了几个问题：①混合云环境下的统一认证和权限同步；②跨环境接口的稳定性和故障降级；③数据同步的边界，哪些数据可以出私有环境、哪些只能留在本地；④运维分工，哪些由客户信息中心负责、哪些由数商云远程支持。
（三）功能模块：围绕采购全流程做组合
MRO商城的功能不是孤立的模块堆叠，而是沿着“需求提报—寻源比价—下单—履约—对账”这条主线来组合。①品类管理模块，统一MRO商品分类、属性、计量单位和编码规则，支持一品多供应商、一物多编码的映射。②寻源比价模块，支持框架协议价、询比价、竞价等多种方式，采购员可以在线比价、留痕，价格审批有据可查。③订单协同模块，把采购订单、发货、收货、退换货、对账串起来，供应商和采购方在同一个订单视图里沟通。④库存与供应商管理模块，把寄售、领用、调拨、安全库存这些场景管起来，同时沉淀供应商的准入、考评、履约数据。⑤多组织权限模块，支持集团、事业部、厂区、车间多级组织，不同角色看到的数据和能操作的功能不一样。⑥系统集成模块，和ERP、WMS、SRM、财务系统、单点登录等做对接，避免形成新的数据孤岛。
（四）技术特点：源码交付与国产化适配
这个项目在技术交付上有几个客户比较看重的点。①源码交付。客户信息中心希望后续具备自主运维和二次开发的能力，所以项目采用源码交付方式，关键模块的代码和部署文档一并移交，后续小的流程调整和报表开发可以自己做，不必每次都等原厂。②私有化部署与混合云部署结合。核心服务部署在客户自有环境，非敏感的前端和检索服务放在公有云，兼顾安全与体验。③国产化适配。客户在基础软硬件上有国产化要求，项目在数据库、操作系统、中间件层面做了适配和验证，保证在国产化环境下稳定运行。④快速交付。基于数商云已有的MRO商城产品能力做配置化开发，把大量通用功能沉淀在标准产品里，定制部分集中在客户特有的流程和集成上，整体交付节奏比较紧凑。
五、MRO商城开发与实施的分阶段复盘
（一）蓝图规划阶段
这个阶段的核心工作是把业务蓝图讲清楚，而不是急着写代码。项目组做了几件事：①梳理集团采购组织架构和权限矩阵，明确哪些角色在商城上做什么事；②统一MRO品类分类和编码规则，把各单位的叫法映射到集团标准；③梳理现有采购流程，区分哪些流程线上化、哪些流程需要优化后再线上化；④确定和ERP、WMS、SRM等系统的集成边界。踩过的坑是，各单位对品类分类的口径不一致，讨论多次仍然有人坚持自己的分法。后来项目组把分类标准拆成“集团统一层”和“单位扩展层”，集团层面管大类和不变量，单位层面可以在自己的子类里做扩展，这才把分歧收敛下来。蓝图规划如果做得不扎实，后面开发阶段一定会返工。
（二）开发配置阶段
开发阶段的原则是“能配置不开发，能复用不新建”。标准产品里已有的品类管理、寻源比价、订单协同等功能，通过配置适配客户的流程；确实需要定制的部分，主要是多组织权限的复杂规则、和客户特有系统的接口、部分报表。这里踩的坑是需求蔓延。业务部门看到系统界面后，不断提出新的想法，今天加一个字段，明天改一个审批节点，如果全部答应，项目范围会失控。项目组的做法是建立需求冻结和变更评审机制，把需求分成“必须上线前做”“可以上线后迭代”“本期不做”三类，定期和客户项目组过一遍变更清单，确保开发节奏不被频繁打断。
（三）集成对接阶段
集成是这个项目里最耗精力的环节。商城要和ERP对物料、供应商、采购订单、入库单，和WMS对库存和收货，和财务系统对发票和付款，还要和集团统一认证做单点登录。踩过的坑主要有几个：①接口字段对不上，比如ERP里的物料描述和商城里的商品名称口径不一致，联调时大量时间花在字段映射和值转换上；②主数据校验规则不一致，ERP认为合法的供应商编码，商城这边校验不过；③历史数据清洗比预想复杂，多年积累的物料数据存在重复、缺属性、计量单位混乱等问题，只能一边清洗一边建映射关系。后来项目组把接口联调做成日例会，问题及时暴露、及时定责任人，集成进度才逐步可控。
（四）测试上线阶段
测试没有只做功能测试，还做了集成测试、权限测试和性能测试。权限测试尤其重要，多组织环境下，如果权限配置出错，A厂区的人可能看到B厂区的价格，这是客户非常敏感的。上线采用灰度方式，先选业务相对规范、配合度高的单位试点，跑通之后再逐步扩到其他单位。试点期间保留了原有的线下流程作为备份，双轨运行了一段时间。踩过的坑是测试订单和真实订单混在一起，导致库存和财务数据出现干扰。后来项目组做了环境隔离，测试数据单独走测试环境，真实业务只在生产环境跑，才把这个问题解决掉。
（五）培训推广阶段
培训推广的难点不在系统操作，而在采购习惯的改变。一线采购员习惯了打电话、发消息就能解决问题，现在要在系统里提需求、走审批、等供应商接单，初期有抵触情绪。项目组的做法是分层培训：①对采购管理层，讲的是数据看板和管控规则；②对一线采购员，讲的是怎么快速找到商品、怎么下单、怎么跟踪订单；③对供应商，讲的是怎么接单、发货、对账。培训之后安排了驻场支持，一线遇到问题能马上找到人。同时，客户把系统操作和审批流程做了绑定，不按要求在系统里走的单据，财务不予结算，这条规则执行下去之后，系统的使用率才真正稳定下来。
六、上线之后，管理、效率与协同的变化
（一）管理视角
集团层面能看到的MRO采购数据比以前完整得多。品类、供应商、价格、订单、库存这些信息沉淀在同一个平台上，采购部做集中管控和分析时，不再需要向各个单位反复要报表。供应商准入和考评有了统一入口，哪些供应商经常延期、哪些供应商质量投诉多，系统里能查到记录，集中管理不再是一句空话。
（二）效率视角
对一线采购员来说，最直接的变化是找货和下单快了。常用商品在商城里能直接搜到，历史价格和协议价格一目了然，不用再挨个打电话问。订单状态、发货情况、收货情况在线可查，催货和确认的时间明显减少。审批流程线上化之后，单据流转速度显著提升，紧急需求的处理也比以前顺畅。
（三）成本与协同视角
集中比价和框架协议让采购价格更透明，同类物资在不同单位之间的价格差异明显收窄。库存方面，常用件的可视化程度提高，长尾件的积压情况有所改善，资金占用有效降低。协同上，采购、仓库、财务、供应商在同一个平台上作业，对账周期大幅缩短，因为数据对不上来回扯皮的情况少了很多。
七、几条可复制的MRO采购系统搭建经验
（一）主数据先行，别急着开发
MRO采购系统搭建最容易踩的坑，就是系统上线了，但品类编码、供应商编码、计量单位还是乱的。我们的经验是，主数据标准要在开发之前定下来，哪怕多花一些时间做梳理和映射，也比上线后反复改数据划算。品类分类可以分层设计，集团管统一层，单位管扩展层，既有统一口径，又保留灵活性。
（二）试点选得好，推广阻力小
不要一上来就全集团铺开。选业务相对规范、采购团队配合度高、痛点比较明确的单位做试点，把流程跑顺、把问题暴露出来、把操作习惯养起来，再向其他单位推广。试点单位的成功案例，比任何推广话术都有说服力。
（三）混合云部署要算清数据账
混合云部署不是简单的技术选型，而是数据管理策略的体现。哪些数据必须留在自有环境、哪些数据可以放到公有云、跨环境怎么同步、故障时怎么降级，这些问题要在方案设计阶段就讨论清楚。否则上线后一旦出现数据同步延迟或者权限不一致，业务侧的感受会非常差。
（四）上线只是开始，运营才是长跑
MRO商城的商品运营、供应商运营、价格运营是长期工作。商品信息要持续维护，供应商要定期考评和汰换，价格要跟着市场变化调整。项目组建议客户在上线后成立专门的运营小组，把商城当成一个持续运营的采购平台，而不是一个交付完就结束的IT项目。
八、写在复盘之后：给同行的几句实话
这个项目做下来，我们最大的感受是，MRO商城开发表面上是技术活，实际上考验的是采购管理思路和跨部门协同能力。混合云部署解决了数据安全和访问体验的平衡问题，多组织权限解决了集团管控和一线灵活的平衡问题，源码交付解决了客户长期自主运维的问题，但真正让商城用起来的，是品类主数据的梳理、供应商运营机制的建立，以及一线采购习惯的养成。数商云在这个项目里积累的混合云部署、多组织权限、品类与供应商运营方面的经验，也可以复用到其他制造企业的MRO电商平台建设场景中。如果同行正在考虑MRO采购系统搭建，或者想了解混合云部署模式下的MRO商城方案，可以咨询数商云获取方案资料和演示，具体方案与报价请咨询数商云。
评论