一、从一摞维修单说起
暖通设备这行的维保采购，做过的人都懂那种琐碎。项目组同事刚到客户现场那天，正赶上区域服务中心的采购员在打电话——某台机组上的水泵密封件坏了，维保工程师只说了设备位置和大致现象，型号讲不清楚，只能拍照发过去让对方猜。电话打了一圈，供应商的报价口径还不一样，有的含运费，有的报裸价，摆在一起根本没法比。
这不是某一家企业的问题。暖通设备的维保配件天生是长尾品类：制冷系统的压缩机、换热器、膨胀阀，水系统的水泵、阀门、水处理药剂，末端的风机盘管、电机、皮带、滤网，还有电气控制里的接触器、传感器、变频模块。品类跨度大，品牌杂，同一规格在不同厂家那里叫法都不一样。采购动作散在各地的项目部和服务中心，需求零碎，信息不透明，仓库里压着买错型号的备件，现场急用的东西又常常临时找货。企业MRO数字化采购这件事，大家嘴上都说要做，真动手，往往第一步就卡在"我们到底有多少种物料"上。
二、客户背景：某暖通设备行业头部集团
这个项目的客户，是暖通设备行业里规模靠前的一家集团企业。主业覆盖中央空调主机、末端设备、锅炉和换热机组的制造，同时自己带着一支不小的安装与维保队伍。设备卖出去只是生意的开始，后面长年累月的维保服务才是利润来源——这就决定了它每年要消耗大量维保配件，而且采购需求不是集中在一处，而是散落在各个区域服务中心、项目现场和制造基地。
集团的采购部门其实早有集中采购的想法，主机、原材料这些大宗物资也确实做到了。但维保配件这一块迟迟推不动，原因说白了就是碎。一线急着用，集采流程走不下来；完全放开让一线自采，价格和品质又没人兜底。集团管理层对这件事的定位很清楚：不是简单上一套系统，而是借这个机会，把维保配件的品类标准、采购规则和供应资源重新梳理一遍。这也是他们把MRO商城开发列入年度重点工作的原因。
三、项目挑战：原有采购模式的问题清单
项目启动后，我们先花时间把客户原有的流程从头到尾走了一遍，从需求提出、找货询价、下单、收货、入库，一直到结算。走完这一圈，问题基本都浮出来了，主要集中在这几块。
（一）物料口径不统一，数据基础薄弱
同一种滤芯，在不同区域的服务站叫法不一样，有人按厂家型号记，有人按设备号记，还有人干脆写"上次买的那种"。主数据没有统一标准，编码规则各区域自己定，结果就是同一个物料在台账里重复出现，采购量算不准，历史价格也无从追溯。维保配件数字化商城搭建绕不开的一步，就是把这些糊涂账理清楚。
（二）寻源比价靠经验和人情
维保配件的供应资源高度分散，原厂件、副厂件、代理商、贸易商混在一起。采购员找货主要靠平时攒下的关系和电话本，一家一家问价，问回来的报价口径还不统一。同一个备件，不同项目买回来的价格能差出一截，而且没人说得清差在哪里。紧急需求一上来，更是"先买到再说"，比价环节基本被跳过。
（三）多组织、多项目的权限边界模糊
集团下面有区域公司、服务中心、生产基地，各自都有采购动作。谁可以买、能买哪些品类、金额到什么程度需要审批，这些规则散落在文件里和口头约定中，系统里没有落地。采购部门想看全局的支出结构，往往要等各区域报表，等来的数据口径还对不上。
（四）库存与订单协同脱节
一边是中心仓和区域仓压着不少呆滞备件，另一边是现场急用时到处找货。库存数据不共享，仓与仓之间调拨靠电话协调；订单状态也不透明，工程师报完需求就只能反复追问货到哪了。供应商那边同样被动，接单靠微信，发货靠催。
（五）系统之间是断的
客户原本有ERP、有财务系统，还有一套简单的报修工具，但这几套系统彼此不通。采购订单在商城里走完，要人工再录一遍到ERP；入库信息回不来，对账的时候财务和采购各拿一份表核对。系统越多，人工搬运的环节反而越多。
四、解决方案：维保配件数字化商城搭建思路
问题摆清楚之后，方向就比较明确了。不是把线下流程原样搬到线上，而是借这次MRO采购系统搭建的机会，把品类、规则、数据、权限这几件事重新定义一遍。我们内部定了个原则：能用标准功能解决的绝不定制，必须定制的一定要沉淀成可配置的能力。
（一）需求梳理：先分清"必须有"和"可以有"
需求阶段我们做得比较重，没有急着画原型，而是先把采购、仓储、财务、区域服务、IT几方拉到一起，把每个角色的动作拆开看：谁在什么场景下要做什么，系统必须提供什么支撑。拆完之后，把需求分成三层——业务规则层、流程审批层、数据展示层。业务规则层是底座，必须一次想清楚；流程审批层可以按组织差异做配置；数据展示层允许后续迭代。这个分层帮我们挡掉了大量"看起来很美但没人用"的需求。
（二）整体设计：一套商城，多组织共用
架构上，我们按"集团统一平台加多组织独立运营"来设计。商品库、供应商库、品类标准是全集团共享的底座；各区域公司和服务中心在统一底座上维护自己的采购目录和价格策略，数据既能各管一摊，又能在集团层面汇总。①需求方在同一套界面里提报，不用再学几套系统；②采购方按权限处理寻源、比价、下单，操作路径统一；③管理层能看到跨组织的支出结构，不用再等报表汇总。既解决了集中管控的问题，也没有把一线的灵活性管死。
（三）功能模块：围绕"找得到、比得清、管得住"来切
模块设计我们没有按部门来切，而是按业务场景来组织。
①品类与商品管理。建立统一的品类树和物料编码规则，把历史物料清洗、归并之后导入。商品信息里除了规格参数，还挂了适配设备、替代型号、常用供应商这些字段——维保场景下，工程师往往是"知道设备不知道型号"，这些字段能帮他把东西找出来。
②寻源比价。支持询价单定向发给多家供应商，报价在线回收、在线比价，历史成交价可以调出来做参考。协议价、框架价和临时询价分开管理，紧急需求走快速通道，但通道里同样留痕。
③订单协同。需求提报、审批、下单、发货、收货、对账在一条链路上走完，状态实时可见。工程师能自己查到货进度，供应商在供应商门户上接单、回传发货信息，采购员从"传话"的角色里解放出来。
④库存与供应商管理。中心仓、区域仓、现场寄售库存分层管理，库存水位和呆滞情况可以按品类看。供应商侧建立准入、评级、绩效记录，价格和交期表现沉淀下来，为后续的份额分配提供依据。
⑤多组织权限。组织、角色、数据范围三个维度组合配置，谁能看哪个区域的数据、能操作哪些品类，都在后台定义，不用改代码。
⑥系统集成。和ERP、财务系统的对接通过接口完成，订单、入库、发票信息自动流转，减少人工重复录入。
（四）技术路线：源码交付、私有化部署与国产化适配
技术选型上，客户最关心两点：数据放在哪里，后续能不能自己改。我们给出的方案是私有化部署，系统跑在客户自己的环境里，数据不出域；同时源码交付，客户的技术团队可以自主维护和二次开发，业务规则变化不用每次都找厂商。系统本身适配了国产化的操作系统、数据库和中间件，符合集团的信创要求。交付方式上依托平台化的配置能力，大部分流程和表单调整在后台就能完成，上线节奏比较可控。
五、开发与实施：从蓝图到一线真正用起来
方案定稿只是开始，真正耗精力的是后面的实施。整个过程按阶段推进，每个阶段都有明确的交付物和验收标准。
（一）蓝图规划：把规则说清楚，比画界面重要
蓝图阶段最花时间的不是原型，是规则讨论。品类怎么划分、编码怎么编、审批额度怎么定、哪些品类必须走集采、哪些允许一线自采——每一条都牵扯不同部门的利益。我们的做法是把争议点单独列出来，请集团层面拍板，形成书面规则再往下走。这里踩过一个坑：早期有一版品类树按财务科目来分，结果一线找货根本找不到，因为工程师脑子里想的是设备和部位，不是会计科目。后来重新按"设备系统—部件—配件"的逻辑调整，才顺过来。
（二）开发配置：标准能力优先，定制部分小步验证
开发阶段我们坚持先配置后开发。商城的商品、价格、审批流这些，能用后台配置实现的就不写代码。确实需要定制的部分，比如维保场景下的替代型号推荐、设备与配件的关联查询，拆成小颗粒度分批交付，每交付一块就让业务方试用反馈，避免一次性做完再推翻。这样做下来，客户的IT团队也逐步熟悉了系统的扩展方式，为后续自主迭代打了底。
（三）集成对接：接口联调是最容易出意外的环节
集成这块我们提前做了接口清单，把每个接口的数据字段、触发时机、异常处理方式都写清楚，再和客户IT、ERP厂商一起联调。踩的坑主要有几种：一是历史数据质量比预想中差，物料主数据里存在大量一物多码和空字段，清洗工作量远超预期；二是各系统对同一个字段的定义不一致，比如"交货日期"在ERP里指的是到货日期，在商城里指的是发货日期，联调时才发现，只能回头统一口径。经验是，集成对接一定要留出专门的数据治理时间，不能默认对方系统里的数据是干净的。
（四）测试上线：让真实用户来挑毛病
测试我们没有只让IT部门点流程，而是从各区域抽了真实的一线采购员和维保工程师参与。他们提出的问题很实在：手机端提交需求时图片上传慢、常用配件找不到快捷入口、审批提醒不及时。这些问题在功能清单上看不出来，但对实际使用影响很大。上线采用分批策略，先选业务相对简单、配合度高的区域跑通，验证稳定后再逐步铺开，避免一次性全集团切换带来的风险。
（五）培训推广：光发操作手册没用
培训这件事我们最初走过弯路，做了一套详细的操作手册发下去，结果一线该打电话还是打电话。后来调整方式，把培训拆成岗位场景来讲——采购员只学寻源比价和订单处理，工程师只学怎么提报和查进度，仓库管理员只学收货和库存操作，每人学自己那一段。同时在每个区域留了内部"种子用户"，遇到问题先找他们。用得顺手了，推广自然就快了。
六、应用成效：变化发生在哪些环节
系统上线运行一段时间后，我们和客户一起做了复盘。具体数字这里不展开，但从管理感受上说，变化是能摸得到的。
采购这边，找货和比价的效率明显改善。常用配件基本能在商城里直接搜到，报价在线回收，不用再一家一家打电话；历史成交价随时可查，谈判时心里有底。分散在各区域的采购动作被收进同一套规则里，超权限、超品类的操作会被流程拦住。
库存这边，呆滞备件的情况有所缓解。各仓库存可见之后，调拨替代采购的场景多了起来，重复采购的情况少了。维保工程师能自己查到货进度，追问的电话明显减少，采购员的时间能放回到寻源和供应商管理上。
管理层面，集团头一回能把维保配件的支出结构看清楚——哪些品类花得多、哪些供应商交期稳定、哪些区域的采购行为偏离规则，都有据可依。供应商的绩效记录沉淀下来，年度份额调整时不再只凭印象。
七、经验启示：给同行业企业的几点建议
这个项目做完，我们内部复盘了几轮，有几条经验，对同样在做MRO商城开发的同行应该有参考价值。
（一）主数据先行，别指望系统上线后再治理
物料编码和品类标准是整个商城的地基。我们见过不少项目，系统功能做得很全，但商品库里一物多码、参数缺失，结果搜索不准、比价失效，用户很快就流失了。正确的顺序是先把历史物料清洗归并、把编码规则定下来，再谈功能。这部分工作枯燥，但没有捷径。
（二）规则要集团拍板，不能靠项目组协调
哪些品类必须集采、审批权限怎么划、紧急需求怎么走，这些都是利益问题，不是技术问题。项目组能做的只是把选项和影响讲清楚，最终必须由集团层面定调并形成制度。规则模糊，系统上线后一定会在执行环节变形。
（三）先跑通一条线，再谈全面铺开
维保配件采购涉及的角色多、场景杂，想一次性把所有场景都覆盖，周期会拖得很长，风险也大。比较稳妥的做法是挑一个区域或一条业务线先跑通，把数据、流程、培训都验证一遍，形成可复制的模板再推广。
（四）留出例外通道，但例外要留痕
现场抢修这类场景，按部就班的流程是行不通的。系统设计时一定要给紧急需求留出快速通道，否则一线会绕开系统，重新回到线下。但快速通道不等于没有记录，事后补单、事后比价这些动作要在系统里能追溯，这样既保住了效率，也没丢掉管控。
（五）把一线用户当合伙人
维保工程师和一线采购员是系统的日常使用者，他们的接受度决定项目成败。测试阶段请他们参与，上线后听他们的抱怨，迭代时优先解决他们提的问题。这个投入看起来不直接产出功能，但能省掉后面大量的推诿和返工。
八、写在最后
回过头看这个项目，它不是一个纯技术命题。暖通设备行业的维保配件采购之所以难，根子在品类碎、场景散、规则软。MRO商城开发能解决的是流程和数据的问题，但前提是企业自己愿意把规则想清楚、把标准统一下来。系统只是把想清楚的事情固化下来，让它在日常运转中不走样。
如果贵企业也在考虑MRO采购系统搭建或者维保配件数字化商城搭建，建议先从主数据和流程现状摸底开始，不用急着定功能清单。具体方案怎么设计、报价如何，请咨询数商云，他们会结合企业的组织结构和业务特点给出针对性的建议，也可以申请方案资料和系统演示，先看一遍真实场景下的操作再做判断。
评论