聊B2B平台搭建，企业问得最多的就那么几类问题：功能到底做多全，同行有的我们是不是也得有，自研还是买成熟产品，做完之后业务到底会不会用。表面看是选型问题，往深里说都是同一件事——边界怎么划。做了多年数商云B2B平台的实施和开发，我的感受是，项目翻车很少因为功能做得不够，更多是因为功能做得太多，做完没人用、没人维护。这次B2B电商平台经验分享，就按实际推进的顺序讲一遍，重点说清楚B2B平台搭建流程里最容易失控的地方在哪里。
一、动手之前，把做不做、谁来做想清楚
（一）业务梳理：先看交易怎么发生，再谈功能清单
很多企业启动B2B平台搭建时，手里拿的材料是竞品截图或者同行的功能列表。这份材料当参考可以，当需求就危险了。B2B交易和B2C的差别在关系上：谁卖给谁、按什么价格卖、谁审批、怎么结算、货怎么发、发票怎么开、账期怎么对。这些关系没理顺，功能清单就是一份愿望清单。
比较实在的做法是把现有流程走一遍，从询价报价开始，到合同、订单、发货、收货、对账、开票、回款，逐段标出问题：哪些环节靠电话和微信在推进，哪些环节反复确认口径，哪些环节的数据在几张表之间来回倒。这些标出来的地方才是系统真正要解决的。① 线下已经在跑的流程别急着改，先搬上来再优化；② 靠人盯着的环节优先系统化；③ 跨部门来回确认的环节要做成一条顺畅的数据流，而不是各自留一份台账。
梳理的产出，最好是一份能点得动的原型加几张流程图，而不是几十页文字需求。业务方看不懂文字，但他们会点原型。原型上确认过的流程，后面改动的概率小很多。
（二）选型判断：自研、标准产品还是定制开发
选型没有统一答案，但判断维度是稳定的。业务的差异化程度决定要不要自己写核心逻辑；IT团队能不能长期投入决定自研走不走得下去；上线时间的紧迫程度决定能不能等；预算的分配方式决定是一次性砸下去还是按年分摊。多数B2B企业最后会落在“基于成熟产品做定制”这条路上。完全自研看着自由，实际上把通用能力也重写了一遍：组织架构、权限、商品、订单、支付、对账，这些模块的业务逻辑大同小异，重写要花的时间通常超出预期。
数商云B2B解决方案的基本思路也是这样：通用能力沉淀在标准产品里，业务上真正有差异的部分留出扩展点，定制集中在这部分，后续升级不至于推倒重来。选型时值得多问一句的是，这套东西以后谁来升级、升级会不会覆盖掉我们改过的地方。
（三）团队配置：谁拍板、谁维护、谁运营
B2B平台是业务系统和IT系统的结合体。只靠IT部门推，上线之后很容易变成没人用的系统。项目里需要有业务方的负责人，最好是有权调整流程的人，遇到部门诉求冲突时能拍板，而不是把矛盾交给项目组。运营岗位也要提前定：商品上架、价格维护、客户账号开通、订单异常处理，这些事在方案里往往没写，上线后就成了谁都该管、谁都不管。
二、从方案到上线：B2B系统开发推进中的关键环节
（一）方案阶段：把流程画出来，把系统边界划清楚
方案规划最容易犯的错是边界模糊。平台管什么、ERP管什么、财务系统管什么、仓储系统管什么，这些在方案阶段就要定下来。常见的扯皮场景是：平台里改了价格，ERP里还是老价格；平台显示有货，仓库那边已经出库；订单在平台状态是已完成，财务还没确认。根子都在于没有指定权威数据源。
省事的做法是给每个关键数据指定唯一的管理方：商品和库存听谁的，客户和授信听谁的，订单和发货状态听谁的。定好之后，其他系统只做同步和展示，不做双向修改。这件事在方案阶段花点时间，能省掉后面大量的对账工作。
（二）开发推进：需求冻结和迭代节奏
需求变更本身不可怕，可怕的是没有节奏。今天提一个改动，明天提一个调整，开发永远在做半成品，测试也没法收敛。可行的做法是固定迭代周期，周期内接受变更登记但排到下个周期做；核心交易流程在开发启动前冻结，非核心模块可以边做边调。同时让业务方在开发过程中就能点到东西，哪怕页面不完整，也比等到验收时一次性看到强。
开发过程中另一个高频问题是接口对接。技术问题往往好解决，难的是业务口径：订单什么时候算生效、库存什么时候扣减、价格以谁为准、失败的订单谁来处理。这些内容要在接口文档里写明白，别指望开发自己猜。重试、告警、人工补偿这几样机制要一起设计，缺一个都会在运行期变成麻烦。
（三）上线运营：数据初始化比开发更耗时间
数据初始化的难度经常被低估。商品资料、价格体系、客户档案、库存数据，从哪来、由谁清洗、字段怎么对应，这些活往往比开发本身还费时间。有些企业的商品资料散在几张表里，价格还有多个版本，清洗的过程实际上是一次业务梳理，需要业务方参与，不能全交给技术。
上线也不建议一刀切。可以先让一部分客户和一部分品类走线上，跑顺了再扩大范围。同时保留线下的兜底流程，平台出问题时业务不至于停。这种做法看起来慢，实际比全量上线之后再回滚要稳。
三、功能取舍：哪些必须做，哪些可以往后放
（一）几种典型的过度开发
① 复杂的会员等级和积分体系。B2B的客户数量有限，关系靠人维护，等级权益算得再细，客户未必看，销售也未必用。真正起作用的是价格体系、授信和账期。② 面向C端的营销工具。秒杀、拼团、优惠券、满减，在B2B里的适用场景不多，大部分交易走的是协议价和框架合同，价格是谈出来的。真要做营销，先把阶梯价、返利、账期这些和交易直接相关的能力做扎实。
③ 大而全的报表中心。报表需求是无限的，每个部门都能提一堆。比较务实的组合是订单、库存、对账这几张核心报表先做好，其余按实际使用频次排优先级，用起来再补。④ 自建即时通讯和客服工单。多数B2B客户习惯电话和微信沟通，自建聊天工具的维护成本不低，实际使用率往往上不去。把消息通知和订单状态提醒做好，比做聊天窗口有用。
⑤ 过早铺多端。PC、APP、小程序、企微入口一起上，资源被摊薄，每个端都不好用。多数情况下先把一个主要入口做顺，其他端在有明确使用场景之后再补。⑥ 复杂的搜索推荐。B2B的商品目录通常不会特别大，分类加筛选基本够用。把搜索准确率和筛选条件的易用性做好，比上推荐算法更实际。
（二）判断一个功能该不该做，可以问自己几个问题
① 这个功能解决的是客户的问题，还是我们自己内部管理的问题？如果是后者，先看看有没有更轻的办法。② 不用系统，现在业务是怎么解决的，成本有多高？如果线下做法简单又稳定，就不急着搬上来。③ 上线之后谁负责运营这个功能，有没有人每天去看它？没人维护的功能就是负债。④ 不做这个功能，业务会不会停？多数情况不会，那就往后排。⑤ 这个功能和已有系统有没有重叠？重复建设比功能缺失更浪费。
四、实施中的常见问题与B2B系统开发避坑
（一）需求反复，本质是流程没谈拢
需求反复通常来自这么几种情况：业务方自己没想清楚，或者不同部门的诉求相互冲突，再或者是看到了别家的做法临时改主意。处理办法是把讨论从功能层面拉回流程层面。比如业务说要加一个审批节点，先问这个动作在流程的哪一步、谁发起、谁承担后果。冲突的诉求不要由项目组裁决，交给业务负责人拍板。项目组当裁判，最后两边都不满意。
（二）主数据不统一
客户、商品、供应商的编码，在ERP、财务系统、平台里往往各有一套。解决办法是在项目早期就指定主数据源，通常以ERP或财务为准，平台做同步。不要做双向写入，也不要给平台另开一套编码体系，否则上线之后对账一定出问题。
（三）组织架构和权限设计得太浅
B2B采购是多角色的：申请人、审批人、采购经办、财务、收货人。平台如果只按“一个客户一个账号”来做，后面权限会非常乱。方案阶段就要按企业、部门、角色、用户这几个层次设计，并且支持一个客户下面挂多个采购主体和多个收货地址。这部分后期改的代价很高，属于必须提前想清楚的事。
（四）用户不愿意用
这是最现实的一道坎。B2B平台的用户大多是被要求用的，不像C端用户自己有动力。所以初版要优先解决他们最烦的事：查库存、比价格、下重复单、对账、催货。别一上来就要求把所有流程都搬上来，可以先线上线下并行一段时间，等用户自己发现线上更快，再慢慢收口。
（五）上线之后没人管
上线不是终点。日常问题响应、数据修正、小需求迭代，这些都需要人力和预算。见过不少平台，建设阶段投入很大，上线后运营支持跟不上，商品信息慢慢过期，客户账号没人开，过不了多久就荒了。运营支持这件事，最好在立项时就写进计划，而不是等上线之后再找人。
（六）一个值得参考的取舍案例
某快消行业头部集团的采购平台，一开始按功能齐全的思路做，会员等级、积分、营销工具都上了。运行一段时间复盘，高频使用的其实是订单查询、对账和到货异常处理，营销类模块几乎没人点。后来把这部分资源转到供应商协同和异常处理上，使用情况才明显好转。这个案例不算特别，但说明一件事：B2B平台的价值集中在交易本身，周边功能再热闹，也替代不了交易体验。
五、几条反复验证过的判断
① 功能清单做减法比做加法难，但更值钱。立项时列一份“这一期不做”的清单，比列要做什么更有用。② 平台是长出来的。结构上留好扩展点，功能上不要一次做满。③ 业务负责人比技术方案更决定成败。技术问题基本都有解，流程和职责上的分歧，靠技术解不了。④ 上线节奏小步快跑。先让业务方尝到甜头，后面的推动会顺很多。⑤ 数据准备和运营支持要提前算进计划，这两块最容易被当成附属工作，最后也最容易拖后腿。
B2B平台搭建没有标准答案，每家企业的交易结构、组织习惯、IT底子都不一样。如果非要给一条通用建议，那就是把资源集中在交易主流程上，把不确定的功能往后放。数商云做过的B2B平台搭建与开发项目里，凡上线后用得起来的，功能清单都不长。
如果你正在评估某个功能要不要加，或者项目推进中卡在取舍上，可以联系数商云咨询，我们一般会先看业务流程图，再聊功能清单。顺带问一句：你现在想加的这个功能，是客户提出来的，还是内部某个人觉得应该有？
评论