一、项目背景：酒水流通渠道的数字化困局
某酒水行业头部集团的渠道结构，基本能代表这个行业的典型形态：总部掌握品牌与产能，往下是总代、区域经销商、二批商，再往下是烟酒店、餐饮门店和商超。这套结构有它存在的理由，资金垫付、本地仓配、终端客情，都不是总部能直接替代的。但层级一多，货盘流向就成了黑箱——总部清楚货发给了谁，却不清楚这批货最终在哪个区域消化，更判断不了中间有没有跨区。这也是这家集团决定启动企业级B2B平台搭建的直接诱因。
需要说明的是，项目最初的诉求并不是"上一套系统"，而是"把渠道管住"。B2B平台开发在这里承担的角色，是把散落在表格、聊天记录和电话里的订货、价格、返利、流向、费用核销，收拢到一条可追溯、可计算、可预警的数字链路上。数商云在这类项目里提供的是平台底座加实施交付，不是卖一个标准软件就结束。
(一) 多级分销是效率结构，也是管控难点
- 层级带来覆盖效率。经销商承担了资金、仓储配送与终端服务，总部用相对轻的直营投入换来了更广的市场半径。
- 层级同时带来信息失真。订单、库存、终端动销在层层上传的过程中不断衰减，总部拿到的大多是滞后且经过加工的结果。
- 授权区域与实际销售区域脱节。经销商拿的是某些区域的授权，但货一旦进入二批手里，落地到哪个区县就很难再追踪。
(二) 窜货的根源往往不在物流，而在价格与激励
1. 区域价差与政策差是第一推动力。不同区域的任务压力、返利力度、促销资源不一致，价差一旦覆盖了运费和风险，货自然往高处走。
2. 压货式考核会放大冲量行为。季度末、年末冲任务时，低价抛货是最快的回款方式，窜货常常在这个节点集中爆发。
3. 举证难、处置慢，让违规成本变得很低。过去总部收到举报，要人工翻单据、比对批次、找经销商对质，一轮下来往往不了了之。
(三) 为什么不做一个小程序，而要做企业级B2B平台
订货小程序解决的是"下单"这一个动作，但渠道管理的真正难点在订单背后：谁能看到哪些商品、按什么价格下单、库存从哪个仓出、返利按什么规则结算、货去了哪里、费用有没有落到终端。这些是典型的企业级B2B平台搭建范畴，需要考虑多组织、多角色、多政策并存，还要和ERP、WMS、财务系统打通。只做一个订货入口，等于把最难的部分留在了线下。
二、需求拆解：把防窜货翻译成可开发的功能清单
渠道数字化的项目，最容易失败的地方是需求太虚。"加强渠道管控""实现防窜货"这类表述落不到代码上。数商云在需求阶段做的事，是把管理语言逐条翻译成功能语言和规则语言。
(一) 交易侧：订货、价格、返利、库存
- 商品可见性按授权过滤。经销商登录后只看到自己有权经营的商品与规格，避免越区询价。
- 价格一商一策。协议价、阶梯价、区域价、促销价并存，价格优先级可配置，而不是写死在代码里。
- 可售库存与发货仓绑定。支持总部仓直发、区域仓调拨、云仓代发等不同发货模式。
- 返利与费用核销在线化。月返、季返、年返、搭赠、陈列费核销，计算依据可以挂订单、回款和流向数据。
(二) 管控侧：区域授权、流向采集、预警处置
- 授权模型要细化到区域、渠道类型、品牌品类与有效期，这是所有判责规则的基座。
- 流向采集不能只靠经销商申报，要靠码在关键节点的扫码动作自然沉淀。
- 预警必须带处置闭环：推送、核实、整改、返利扣减、申诉通道，缺一环规则就形同虚设。
(三) 终端与消费者侧：扫码带来的动销数据
终端开箱扫码、消费者开瓶扫码，既是营销活动的入口，也是流向数据的来源。这里要提前考虑合规边界：位置信息遵循最小必要原则，只采集到区县级别；消费者参与活动需明确授权；企业侧只使用聚合后的流向分析，不越界使用个人信息。
(四) 明确不做什么
项目组在启动阶段就划了边界：不做面向消费者的零售商城，不与现有ERP的财务核算功能重叠，不在第一阶段铺开全部品类。边界清晰，才不至于把一个渠道平台做成四不像。
三、方案设计：多级分销与防窜货的架构思路
(一) 总体架构：按业务域拆分，而不是按页面拆分
平台按业务域做了拆分：交易域负责商品、价格、订单、支付与发货；渠道域负责组织、经销商档案、授权区域、业务员与终端门店；营销域负责促销、返利、费用核销与扫码活动；码域负责码库、码关联、扫码记录与流向；数据域负责报表、预警与看板。技术侧采用微服务架构，注册配置中心、网关、服务治理一应俱全，订单与扫码这类写入密集的服务独立部署并预留水平扩展空间。热点数据放缓存，扫码流水经消息队列削峰后异步落库，历史数据按时间归档，避免大表拖慢在线交易。
(二) 一物一码：码的分层与关联关系
- 产线赋码阶段建立垛码、箱码、瓶码（盒码）的父子关联，这是整条追溯链的地基。
- 出库阶段通过PDA或接口，把码与订单、经销商、发货区域绑定，形成"这批货发给了谁"的记录。
- 经销商收货扫码确认，终端开箱扫码，消费者开瓶扫码，逐层把落地信息补全。
- 码关系必须配套补码、换码、退货回收的流程。产线停机、包装破损、退换货都会造成关联断链，没有补救机制，后面的流向分析就是空的。
(三) 组织与授权模型：所有规则的取数源头
组织树按总部、大区、省区、经销商、终端逐级展开，账号分企业账号与子账号，业务员和门店各有自己的操作范围。授权维度包括区域、渠道类型、品牌品类单品和有效期。订货时的商品可见性、价格匹配、扫码后的归属判断，全部从这个模型取数，所以它一旦设计得含糊，后面每个模块都要打补丁。
(四) 价格与返利引擎：让规则可配，让政策可调
价格引擎支持多层价格叠加与优先级配置，改政策不需要改代码。返利引擎把订单、回款、流向三类数据作为计算依据，这一点是防窜货的关键设计——把返利合规性与流向合规性挂钩，窜货一经核实就影响返利结算，比单纯罚款更有约束力。同时做价格隔离：经销商只能看到自己的价格，接口不返回他人价格，减少因比价产生的新一轮跨区。
(五) 防窜货规则引擎：从扫码到预警的闭环
规则层面覆盖了几类典型场景：扫码地理位置与授权区域不符、非授权经销商扫码、同一码短时间内跨多地扫码、码尚未出库即被扫描、大量码集中出现在非授权区域。命中规则后不是简单弹个提示，而是生成带证据链的工单，包含订单、出库记录、扫码时间线，推送到对应大区，处置结果回流到经销商档案，作为返利与政策评估的依据。阈值必须可配置，因为正常调拨、连锁门店内部流转这类行为不能一刀切误伤。
(六) 系统集成：接口优先，明确主数据源
与ERP打通主数据、库存与订单回传；与WMS对接出库扫码；与TMS对接物流轨迹；与CRM对接业务员拜访；与财务系统对接对账开票。老系统没有开放接口时，用中间表加定时任务过渡也能跑，但一定要指定唯一主数据源，否则客户编码和商品编码在两边各长一套，流向分析必然对不上。
四、实施过程：分阶段推进与踩过的坑
(一) 调研阶段：先把流程画出来，再谈功能
项目组把业务、渠道、财务、IT和经销商代表拉到一起，从订货一直画到结算，标出每个卡点：哪一步靠电话确认、哪一步靠人工核价、哪一步单据会丢失。很多后面要开发的功能，其实是在这张流程图上被发现的，而不是在需求文档里拍出来的。
(二) 主数据治理：最枯燥，也最决定成败
客户、商品、区域、组织编码统一，经销商档案补全授权区域与渠道类型。这一步费力不讨好，但跳过它的项目，后面都会以各种奇怪的方式返工——比如同一个小店在系统里有好几个身份，流向统计自然失真。
(三) 码与业务衔接：先小批量跑通再放量
产线赋码、仓库出库扫码、经销商收货扫码这几段必须在试运行阶段完整跑通，先在有限的品类和产量上验证，确认关联关系不漏不断，再逐步扩大范围。码域的问题一旦流入大货，清理成本极高。
(四) 试点与推广：让经销商先看到好处
试点选在渠道结构相对清晰、配合度较高的区域，跑顺之后再复制。推广时与其讲管控，不如讲好处：订货更快、对账更清楚、返利算得更明白。同时把规则讲在前面，明确哪些行为会影响返利，避免事后争议。
(五) 实施中遇到的几类典型问题
- 码关联断链。处理方式是建立码生命周期管理，补码换码走线上流程，定期核对关联完整性。
- 只扫不核。收货扫码变走过场。解决思路是把扫码和收货确认、返利核销绑定，让扫码有实际收益。
- 经销商担心数据被拿走。做法是数据分级可见：总部看整体流向，经销商看自己的终端与动销，双方在同一套数据上对话，而不是单方面被监控。
- 规则过严引发反弹。连锁门店调拨、关联公司周转被误判，后来补上了申诉通道与白名单机制。
五、落地价值：渠道透明之后发生了什么
(一) 窜货处置从被动接举报变成主动预警
过去靠举报、靠业务员反馈，问题发现时往往已经卖完；现在异常扫码会实时触发提醒，大区能在货还在流通环节时介入。处置效率提升的同时，经销商对规则的敬畏心也上来了——因为违规真的会被记录、被追溯。
(二) 订货与对账效率明显改善
订单、发货、回款、返利在同一个平台流转，业务员从催单和核对单据里被释放出来，可以把时间花在终端拜访和动销推动上。对账周期缩短，争议也从"谁的记录对"变成"系统里怎么显示"。
(三) 费用投放更有依据
陈列费、促销品发给了谁、有没有落到终端，过去基本靠信任，现在可以通过扫码与收货数据交叉验证。市场费用从"撒出去"变成"投下去"，同样的预算能覆盖更多有效终端。
(四) 数据资产开始反哺经营决策
渠道流向、终端动销、区域供需逐步沉淀为可分析的数据资产，支撑生产计划、新品铺市节奏和区域政策调整。供应链数字化真正有价值的不是看板好看，而是这些数据能进到补货、排产、政策的决策链路里。
六、复盘与建议
(一) 关键成功要素
- 一把手参与，业务主导。渠道政策涉及利益再分配，纯IT部门推不动。
- 把防窜货嵌进交易流程，而不是单独做一个"防窜货系统"。扫码、收货、返利、费用核销天然带着流向信息，顺路采集的成本最低。
- 分阶段推进，先试点后推广，先打通再扩展品类。
(二) 容易走偏的几个地方
- 只上系统不改政策。价格与返利结构不变，平台只会让窜货跑得更快。
- 追求一次到位。规则越复杂，上线越难，先用核心规则跑起来，再逐步迭代阈值和场景。
- 忽视经销商体验。订货流程比原来更麻烦的平台，推广必然失败。
(三) 后续演进方向
平台跑稳之后，这家集团把下一步放在需求预测与智能补货上，用历史流向与终端动销数据辅助区域备货；同时探索终端画像与业务员拜访路线的优化。B2B平台开发不是一次交付就结束的事，它更像一个持续演进的能力底座——先解决渠道看得见的问题，再解决算得准、反应快的问题，这个顺序很难颠倒。
评论