这几年做B2B系统开发，五金MRO是我接触过最容易低估、也最容易做砸的一类。它不像快消，品线清楚、客单稳定；也不像大宗，一单一议、流程短。五金MRO的问题在于两头都占：一边是大量的标准件、易耗件，客户要的是快速找货、马上下单；另一边是集团客户的框架协议、多级审批、月结对账，一笔订单能牵扯好几个部门和好几套规则。硬塞进同一个平台里，需求天然就是打架的。
经常被问到的问题也集中在那几个：平台该自研还是买现成的？品类这么多，系统里到底怎么组织？客户价格体系那么杂，系统装不装得下？上线之后业务愿不愿意用？这些问题看着分散，指向的其实是同一件事，把线下的生意规则翻译成系统能执行的语言。这一步做不扎实，后面写多少代码都白搭。
下面把我在数商云B2B平台搭建项目里反复验证过的做法、以及踩过的坑整理一遍，算是一次B2B电商平台经验分享，从需求梳理、选型判断，一直讲到品类管理、开发推进和上线运营。如果你正在做B2B电商平台的选型评估，或者项目已经立项但推得别扭，下面的内容应该能对上你的场景。
一、动手之前，B2B平台搭建流程里最容易省掉的几步
项目一立项，多数团队的第一动作是让各部门提需求、让供应商来报价。这两件事都要做，但顺序往往搞反了。需求还没收敛，报价单上的功能项看着都差不多，最后比的就是价格和承诺，等到实施阶段才发现跟自己业务对不上，改起来就是加钱加周期。
（一）先定主线：平台主要服务哪一类客户
五金MRO的客户大致能分成几类。一类是中小工厂和维修门店，单笔金额不大，要的是找货快、有现货、能拆零；一类是规模企业或者集团的采购中心，走框架协议、集中下单、分散收货、按月对账；还有一类是渠道商和同行调货，看的是价格和账期。这几类的产品要求差别很大，中小客户需要的是搜索、推荐、自助下单；集团客户需要的是审批流、订单拆分、对账结算；渠道客户关心的是价格权限和历史返利怎么算。
① 主线客户决定平台的核心交易链路，其他客户可以适配，但别指望一套流程同时讨好所有人。② 判断主线的方法很土但很有效，看现有业务里哪一类客户的订单占比高、复购稳、服务成本可控。③ 如果企业现在主要靠销售跑单，那平台第一阶段的目标大概率是把常规补货和重复下单搬到线上，而不是把所有客户一次性搬完。
（二）拿一张真实订单，把流程从头走到尾
需求调研别开成许愿大会，收上来的基本都是“最好能……”这类句子。比较靠谱的做法是挑一张最近真实发生的订单，从客户询价开始，一直到收货、对账、开票，把每个动作记下来：谁在做什么、用什么工具、卡在哪个环节、靠什么临时办法绕过去的。这个动作走几遍，隐含规则基本就浮出来了，比如某些客户必须走线下报价、某些订单要业务经理口头确认才能发货、退货谁批谁负责。
这些规则不梳理清楚，线上流程就永远跑不通，因为业务会绕开系统走老路。反过来，把这些规则先理明白，哪怕第一阶段的系统只覆盖其中一部分，也能真正被用起来，而不是上线之后变成摆设。
（三）选型：自研、买标准品，还是平台化产品加定制
自研的诱惑在于“完全贴合业务”，但代价常常被低估。商品中心、价格中心、订单中心、结算中心这些通用能力都要自己从头做，人员一流动，维护就成问题。标准SaaS产品的优势是上线快，短板也明显：客户价格体系、审批模型、对接ERP的方式一旦偏离标准逻辑，要么改业务，要么放弃。
比较现实的路径是数商云B2B平台搭建这类平台化产品加定制开发，交易、商品、价格、订单、结算用成熟模块，行业特有的品类结构、参数体系、审批规则做配置或者二次开发。判断标准可以简单一点，通用能力买，业务差异化自己做。选的时候别只看功能清单，重点看对方在五金MRO这类复杂品类上的落地方法，以及后续需求变更的响应方式。
（四）团队和资源：谁拍板，谁运营
项目最怕的配置是业务方派个联络员、IT关起门来开发。业务侧需要有一个能拍板的人，价格规则、审批规则、品类口径这些争议他得能定；IT侧需要有懂接口和数据的人，不然对接ERP、WMS、财务就是无尽扯皮。另外，运营角色要提前落位，商品数据谁录、类目谁调、活动谁做、客户问题谁答，这些事在项目期就得有人认领，等到上线再看，通常就晚了。
二、B2B系统开发从方案到上线，每个阶段该抓什么
（一）方案规划阶段：把模糊规则定成明确条款
方案阶段的核心不是画页面，是定规则。五金MRO平台上至少要明确几件事：品类结构怎么定、商品怎么描述、价格有几种类型、订单怎么流转、结算怎么走。这些在线下往往是模糊的，同一句话两个人理解不一样，系统里必须翻译成明确的判断条件。
① 价格体系是重灾区。客户等级价、协议价、阶梯价、项目价、临时促销价，几种价格同时存在时，优先级必须先定死，否则开发没法写，业务也会天天来找。② 订单审批线要跟业务确认到“谁在什么条件下必须审”，不要做成万能流程，越万能越没人用。③ 结算方式要和财务对齐，月结客户的对账周期、发票规则、超期处理，在方案里都要有说法，别留到开发阶段再讨论。
（二）开发推进：分批交付，能做演示的才是真进度
B2B系统开发的周期通常不短，中间最大的风险是需求一直在变、进度看不见。我的习惯是把项目切成若干可独立演示的批次：先做商品中心和客户中心，再做价格和购物车，然后是订单、审批、结算，最后跟ERP、WMS、财务打通。每一批都能让业务点着看，能下单、能算价、能走审批，问题在这种时候暴露，成本最低。
接口这块要提前定好数据责任方，谁产生、谁维护、谁兜底。尤其库存和价格，两边系统不一致的时候以谁为准，必须写下来。权限模型也别拖到最后，五金MRO的客户结构复杂，一个集团下面多个工厂、多个收货地址、多个采购员，权限设计不好，上线后就是一堆手工兜底。
（三）上线运营：别追求一次全量
上线不是项目终点。比较稳的节奏是先内部跑，业务和客服自己下单、自己走审批、自己试对账，把明显的问题磨掉；然后挑几个配合度高、需求相对标准的客户小范围使用，观察真实行为；确认链路走得通、数据准得住，再逐步放开。
上线初期客户的流失往往来自细节：搜不到货、价格显示不对、库存对不上、下完单不知道什么时候到货。这些问题的处理速度，直接决定业务愿不愿意继续用。运营要有人盯数据，搜索无结果的关键词、下单中断的环节、询价没回复的记录，这些比任何汇总报表都真实。
三、五金MRO品类管理，实操上要怎么做
（一）品类分层，不要照搬线下的商品手册
很多企业做平台，第一反应是把线下那本厚厚的商品分类手册搬进系统。结果就是客户在搜索框里找“内六角螺丝”，系统让他从一级类目一路点好几层。线上的品类结构应该向客户的搜索和采购习惯靠，而不是向内部管理口径靠。后台可以保留财务和采购用的分类用于统计，前台要有一套更扁平、更好找的类目。
在品类之下，我习惯按采购行为分层来运营。① 高频标品，比如紧固件、劳保耗材、常用电工料，客户心里有价，看重的是有货、能拆零、发货快，这类商品要尽量做到自助下单、库存可视、价格透明。② 中频、有一定专业门槛的品类，比如电动工具、量具、磨具，客户需要选型对比、参数过滤、品牌替代，页面上的信息密度比价格更重要。③ 低频高值或者非标的品类，比如专用配件、定制件、设备备件，标价意义不大，重点是询报价的响应速度和历史成交记录复用。这几类的运营动作完全不同，放在同一套规则里，效率一定打折。
（二）把商品描述做成结构化的属性
五金MRO最头疼的是描述不统一。同一颗螺钉，有人写“内六角M6×20”，有人写“GB70 M6*20 不锈钢”，客户搜索的时候找不到，客服还得一个个问。解决办法是把关键参数拆成属性字段，品牌、系列、规格、材质、强度等级、表面处理、包装单位，能结构化的尽量结构化，搜索和筛选才有依据。
① 属性模板按品类定制，不要所有品类用同一套字段，浪费录入精力，也干扰筛选。② 保留必要的非结构化描述位置，用来写使用场景、适配机型、替代说明这些塞不进字段的信息。③ 替代关系和配套关系要单独维护，客户买一台工具，后面跟着的是耗材和配件，这个关联做好了，复购表现会明显不一样。
（三）价格、库存和交易规则要一起想
价格这块前面提过，这里说几个容易忽略的点。计价单位和包装单位经常不一致，按盒进、按支卖，按公斤进、按米卖，系统里下单单位、计价单位、库存单位要能分开配置，否则库存永远对不上。起订量和拆零规则也要在商品层说清楚，哪些能拆、拆到什么程度、拆零后价格怎么算，这些不定下来，客服和仓库就得天天打口水仗。
① 库存上，自营仓、供应商直发、门店现货混在一起的时候，客户看到的“有货”必须说明是哪一种。② 交期承诺比库存数字更重要，客户能接受订货，但不能接受说好有货结果发不出来。③ 价格权限要跟客户体系绑定，同一个客户的不同角色看到的价格可以不同，但规则要清楚，避免业务私下改价之后系统对不上账。
还有一个很容易被漏掉的场景，大客户有自己的物料编码体系，采购员下单时只认自己那套码。平台最好支持客户物料编码的映射，把一个客户的码和平台商品绑定起来，客户搜自己的码就能直接下单，这个功能看着不起眼，用起来省的事很多。
（四）商品数据是个长期活，不是上线前的功课
不少项目上线前突击录数据，上线后没人管，几个月下来商品信息就开始乱，价格过期、图片缺失、失效商品还挂在架上。比较务实的做法是固定一个数据维护岗或者小组，负责新品录入、属性补全、图片和文档维护、失效商品下架；建立简单的审核规则，谁录谁审、什么情况需要复核；定期看搜索日志，把客户搜不到的词补上别名和关联关系。这件事没有一劳永逸的做法，做得细一点，平台的可用性就高一点。
四、B2B系统开发避坑，这几个问题几乎每个项目都会遇到
（一）需求一直加，进度一直拖
需求膨胀往往不是因为客户善变，而是因为前期没定基线。应对办法不复杂，每一批开发启动前确认一次范围，中途新增的需求登记进列表，评估影响后统一排期。不要在开发过程中随手加，加得越多，交付质量越差，团队也越疲惫。业务方需要接受一个现实，平台是分阶段长出来的，第一版能把主链路跑顺就已经算成功。
（二）品类树越做越细，客户越找不到货
后台分类和前台类目要分开，这一点前面说过。还有一个常见情况是项目组为了“覆盖全”，把类目做得非常细，结果商品挂载混乱、运营维护成本高。类目深度控制在客户能接受的范围，宁可让一个类目暂时宽松一点，也不要为了整齐让客户多点几次。类目是给客户找货用的，不是给内部看的。
（三）客户、账号和权限想得太简单
五金MRO的客户账号结构比大多数品类复杂。一个集团多个工厂、多个部门、多个收货地址，采购员、审批人、收货人、财务各是各的角色，还有的客户要求子账号之间不能互相看到价格和订单。这些如果不在设计阶段想清楚，上线后只能靠人工干预。建议在客户建档时就明确层级关系、角色权限和数据可见范围，宁可一开始多花点时间确认，也别等到客户投诉再返工。
（四）低估了数据迁移和历史单据
老系统里的客户资料、商品数据、历史订单、应收账款，格式往往很乱，字段缺失、重复建档、口径不一致是常态。迁移不是纯技术活，更多是业务活，需要业务方一起定规则：重复客户怎么合并、停用商品怎么处理、历史订单迁多少、余额以哪边为准。这块工作量经常被低估，排期时要留出余量。
（五）上线节奏跟考核脱节
还有一条容易被忽略，业务团队为什么要把客户往线上引。如果线上订单和线下订单的考核方式不一样，愿意推的人就少。上线前要想清楚内部流程和激励怎么调整，比如线上订单的业绩归属、客服工作量怎么算、销售提成是否受影响。这些内部问题不解决，系统做得再好，也可能只有少数客户在用。
五、经验之外，也说几句选型上的实在话
回头看这些项目，做得顺的往往不是功能最多的，而是需求边界清楚、业务方真正参与其中的。五金MRO这类品类的B2B平台搭建，真正花时间的地方在于把杂乱的商品、复杂的价格、多层级的客户关系装进一套稳定的规则里，同时让一线愿意用、用得顺手。规则先于功能，运营先于上线，这两句话我认为值得反复提醒。
如果企业自身有比较强的IT团队，也打算长期投入，自研不是不能考虑；如果更看重上线速度和后续迭代的可持续性，找有行业经验的平台方合作会更稳。数商云B2B解决方案覆盖的正是从商品、客户、价格到订单、结算、对接ERP的主链路，五金MRO这类品类结构复杂、客户层级多的场景，是它比较能发挥的地方。真要上手之前，建议先把几件事想清楚：主线客户是谁、第一阶段的业务范围到哪里、上线后谁负责运营。这几个问题有了答案，后面的选型、开发、上线都会顺很多。
如需了解数商云B2B平台搭建与开发方案，可联系数商云咨询。你现在的平台建设，是卡在需求梳理阶段，还是已经上线但业务用不起来？
评论