一、工程机械行业的MRO采购，普遍卡在几个老地方
跟这家客户第一次碰面，是在他们一个区域配件仓库里。库管员带我们转了一圈，指着货架说了句挺实在的话：这些东西，一半是维修急着要的，一半是去年就躺在这儿的。采购那边同时在抱怨，服务站师傅打电话要配件，他们得先问供应商有没有货、什么价，回头再翻合同价，一圈走完，师傅的车还在工位上架着。
这种场景在工程机械行业不算新鲜。转完仓库，又跟着采购和维修班组聊了大半天，我们对这类企业的MRO采购有了比较具体的感受：问题往往不是"买不到"，而是"买得不顺、管得不细"，大致落在这么几处。
① 采购动作散。各区域公司、事业部、服务网点都有自己的小渠道，同一类物料在不同地方走不同的供应商，集团层面谈下来的价格协议落不到末端，重复采购时有发生。
② 品类杂、口径乱。配件、易损件、油品、耗材、劳保、工装工具搅在一起，同一个东西在不同区域叫法不同、编码不同、规格描述也不同。想横向比价，得先把口径统一了才谈得上。
③ 库存和需求是两张皮。维修现场急等的件经常缺货，仓库角落里却压着一批长期没动过的库存。信息不透明，采购只能凭经验备货，越备越不敢往下减。
这也是后来我们在做MRO商城搭建、推配件集采与库存协同时，始终围绕的那条主线。
二、客户背景：某工程机械行业头部集团的采购版图
客户是某工程机械行业头部集团，业务从整机制造延伸到销售与售后服务，下面有多个事业部和区域公司，服务网点与代理商分布在全国各地。对他们来说，配件能不能及时到位，直接关系到售后服务的响应速度和客户口碑；而生产端又要用掉大量辅助物料和耗材，两条线的采购诉求并不完全一样。
集团的信息化底子不差，ERP、财务、OA这些系统都在跑，但MRO这块一直没有统一入口。采购人员手里攒着好几套表格，供应商各自揣着自己的报价单，维修班组还有自己的"应急渠道"。系统有系统的账，现场有现场的做法，中间的差口靠电话和熟人补。
所以项目一开始，双方的共识就很清楚：这不是买一套软件的事，而是要把配件集采这件事从规则到工具重新捋一遍。
三、项目挑战：原有采购模式的几处堵点
立项前的调研我们做了好几轮，分别跟采购、仓储、维修、财务、IT坐下来聊。把散落的说法归拢一下，堵点集中在下面几个方面。
（一）需求提报靠电话和表格
服务站师傅口头或者发消息报需求，区域采购手工登记，再一层层汇总上来。单据流转慢，还容易漏。紧急件走特批、事后补单，时间一长，账面和实际就对不上。项目经理最头疼的不是审批慢，而是压根不知道下一周到底有多少件要备。
（二）寻源比价缺依据
同一物料，不同供应商的报价口径五花八门，含税不含税、含运不含运混着来，光是把报价拉到同一水平线上就要费不少劲。历史价格散在个人表格里，经办人一变动就断档。集团谈下来的框架协议，末端执行时经常被"就近买、来不及了"绕过去。
（三）库存看得见，但看不清
多个仓库各自记账，系统里的数跟货架上的数有偏差。更麻烦的是各仓之间互不知情：一个区域缺件紧急采购的同时，另一个区域的同款件正在慢慢积压。仓间调拨基本靠人情，没有常态化机制，谁也不敢先把备货量降下来。
（四）系统之间断点多
如果商城孤立运行，就会变成又一个需要手工回填的系统。订单、收货、发票、付款这一条线必须跟既有系统打通，否则前面省下来的时间，后面又原样还回去。这一点在方案阶段就必须想清楚，不能等开发到一半再补。
（五）组织与权限复杂
集团、事业部、区域公司、网点，层级多，采购权限、审批额度、可见范围都不一样。谁能在什么范围内买什么、由谁审批、超标走什么路径，都要在系统里明确下来，不能靠默认规则糊过去。
四、解决方案：MRO商城搭建的整体思路与功能设计
方案阶段我们没急着罗列功能清单，而是先把客户的采购场景一个个走了一遍。走完之后发现，真正要解决的是两件事：一是把分散的采购需求收拢到统一的商城里，让配件集采有抓手；二是让库存数据动起来，让采购决策有依据。功能设计就围绕这两件事展开。
（一）需求分析与品类重构
起步动作是理物料。我们把MRO品类按采购特性分成几类：①可以标准化上架的通用件，比如劳保、耗材、通用工具；②需要按机型匹配的专用配件，必须带适配关系；③需要询价的非标件与定制品；④带服务属性的项目，比如维保、校准。分类不同，下单路径就不同，不能都塞进一个购物车逻辑里。
紧接着是建集团级的物料主数据。编码、名称、规格、单位、关键属性统一起来，允许各区域保留本地叫法，但必须挂到主数据上。这一步看起来枯燥，实际决定了后面比价、集采、库存共享能不能成立。当时客户内部也有争议，觉得区域用惯了老叫法，改了影响效率，后来我们用"搜得到就行"的思路做了折中，主数据管口径，前端管习惯。
（二）功能模块设计：围绕配件集采与库存协同展开
① 品类与商品管理。按品类设置不同的上架规则和可见范围，专用配件绑定机型适配关系，服务站按设备型号筛选，避免选错件。
② 寻源比价与协议价。把框架协议、阶梯价、区域价都落到系统里，线上询比价留痕，历史价格可查，新供应商准入走统一流程。采购员不用再翻聊天记录找报价。
③ 订单协同。需求提报、审批、下单、发货、收货、对账在同一条线上走，紧急件有单独通道但必须留痕，事后不再靠补单找平。
④ 库存与供应商管理。各仓库存统一视图，设置安全库存与补货提示，仓间调拨线上化；供应商这边做绩效记录，交付、质量、响应速度都有据可查。
⑤ 多组织权限。按集团、事业部、区域、网点配置角色和审批流，谁看得到什么、能买什么、多少额度以上要找谁批，都在后台配好。
⑥ 系统集成。跟既有ERP、财务、主数据系统对接，订单与库存数据双向流转，避免二次录入。
（三）技术路线：源码交付、私有化部署与国产化适配
考虑到客户对数据归属和后续自主迭代的要求，方案采用源码交付加私有化部署。源码交付的好处是后期客户自己的IT团队可以基于业务变化做调整，不用每个小改动都等外部排期。同时做了国产化适配，数据库、中间件、操作系统都在客户现有信创环境里验证过。交付节奏上走的是分阶段上线，先跑通核心交易链路，再逐步叠加库存协同、供应商绩效这些模块，不追求一次性大而全。
五、开发与实施：MRO商城开发分阶段推进与踩坑复盘
项目按蓝图规划、开发配置、集成对接、测试上线、培训推广这几步往下走。每一步都有意外，下面挑还记着的过程说一说。
（一）蓝图规划：把"谁在什么场景下做什么"画清楚
这一段我们花了比较多时间在业务梳理上，而不是急着画界面。做法是把典型场景拉出来演一遍：服务站师傅发现设备要换件，怎么在商城找到适配配件、怎么确认有没有现货、紧急情况下走什么通道；区域采购怎么基于库存提示做补货；集团采购怎么看到各区域的集中需求再谈价。场景走通了，角色和权限自然就出来了。当时最大的收获是让业务部门自己人坐在一起吵，采购和仓储的分歧在会议室解决，比上线后互相甩锅要好得多。
（二）开发配置：主数据先行，别让界面等数据
开发启动前，我们坚持先把主数据和分类规则确定下来。这个决定后来被证明是对的。物料口径一天不定，商品管理、比价、库存这几个模块就没法真正编码，做出来的东西只能反复返工。过程中也踩过坑：早期为了让区域快点用起来，放开了本地自建物料的权限，结果没几天就冒出一堆重复条目，后期做了一次集中清理和归并。教训是这类口子可以留，但一定要配审核，不能完全放开。
（三）集成对接：接口是最容易出意外的地方
跟既有系统的对接比预想的麻烦。一方面是字段口径对不上，比如库存的可用量与占用量在两个系统里的定义不一样；另一方面是有些老系统的接口能力有限，只能做定时的数据交换，做不到实时。我们的处理办法是先明确哪些数据必须实时、哪些可以容忍延迟，把有限的技术资源放在订单和可用库存这类关键数据上，其余走批量同步。这段经历提醒我们，集成方案一定要在蓝图阶段就跟客户IT一起把底摸清楚，别等到联调时才发现对方的接口是多年前的版本。
（四）测试上线：小范围试点，再逐步推开
上线没有一刀切。先选了一个业务相对完整、人员配合度较高的区域做试点，跑通下单到收货的完整闭环，把问题在局部暴露出来。试点阶段确实发现了不少细节问题，比如审批流在跨组织场景下走不通、部分配件搜索关键词匹配不上。这些问题在小范围修，成本低得多。等流程稳定了，再往其他区域推，每个区域推之前都做一轮数据核对和权限配置。
（五）培训推广：把工具变成习惯
培训这件事，光讲操作没用。我们采取的是分角色讲场景：给服务站的人讲怎么快速定位配件、怎么看现货；给采购讲怎么看集中需求、怎么发起询价；给仓管讲怎么做调拨和盘点。同时留了一批"内部种子"，各区域抽人跟着项目组全程参与，上线后他们就是第一响应人。冷启动阶段我们还在商城首页放了常用件清单和推荐路径，降低新用户的上手门槛。推广期最难的不是教操作，而是让习惯了打电话的人愿意先打开系统看一眼。
六、应用成效：配件集采与库存协同带来的变化
项目运行一段时间后，从管理层的反馈和系统的实际使用情况看，变化是能感知到的。
管理上，集团层面第一次能看清MRO品类到底在买什么、从谁那里买、各区域的价格差在哪。原来要靠一层层报表汇总的信息，现在从商城和库存视图里直接就能看到，谈集采的时候手里有依据，配件集采的范围和深度都比以前扎实。
效率上，需求提报到下单的链路明显缩短，重复录入的环节少了，采购人员从"找货、问价、追单"里腾出一部分精力去做供应商管理和价格谈判。紧急件的处理也有据可查，不再是一笔糊涂账。
成本上，通过统一口径和集中比价，同一物料的采购成本有了明显改善；库存这边，各仓之间的可视性提升后，重复备货和长期呆滞的情况有所缓解，仓间调拨从"找人帮忙"变成了常规动作。
协同上，采购、仓储、维修、财务在同一个数据底座上说话，扯皮的场景少了。维修班组能自己看到现货情况，对到货时间的预期更准，和采购之间的矛盾也缓和了不少。
七、经验启示：给同类企业做MRO采购系统搭建的建议
（一）先理业务，再谈功能
MRO商城开发最容易走偏的地方，是一上来就对着功能清单打勾。实际上，品类的采购特性、组织的权限边界、紧急件的处理规则，这些业务规则不理清楚，功能做得再多也落不了地。建议在方案阶段就把业务部门拉到一起，把典型场景演一遍。
（二）主数据是地基，不能边做边改
物料编码、规格属性、单位换算这些东西看着不起眼，却决定了比价和库存共享能不能成立。宁可前期多花时间统一，也别指望上线后再慢慢补。同时要预留本地别名机制，兼顾一线使用习惯。
（三）库存协同要分"看得见"和"算得清"两层
先做到各仓库存统一可见，这一步见效最快，阻力也最小；再往安全库存、补货建议、仓间调拨规则上走，这时候就要依赖历史消耗数据了，不能急着上。跳过第一步直接做智能补货，大概率会翻车。
（四）上线不是终点，运营机制得跟上
系统上线只是开始。物料主数据的维护人、供应商准入的审核人、异常订单的处理流程，这些都得有明确的责任岗位。我们后来跟客户一起把数据质量的抽查做成了常规动作，就是为了防止用着用着又乱回去。
八、关于落地这件事，还想多说几句
回头看这个项目，它没有特别炫的技术，难的是把工程机械行业里那些"习惯了就这样"的做法，一条条搬到线上并且让一线愿意用。配件集采能不能推得动，库存协同能不能真的转起来，取决于业务规则有没有理清、主数据有没有立住、推广有没有人接得住。技术方案反而是相对确定的那个变量。
如果你所在的企业也面临MRO品类繁杂、采购分散、库存和需求对不上的情况，可以先从梳理品类和组织权限入手，再考虑MRO商城搭建的具体方案。数商云在工程机械、装备制造这类多组织、多网点的行业里积累了不少MRO商城开发与实施的经验，具体方案与报价请咨询数商云，也可以申请一次系统的产品演示，把你们真实的采购场景拿出来对着走一遍，往往比看功能清单更有价值。
评论