从立项到上线：企业级 B2B 业务系统的七阶段落地路径与责任边界

企业级 B2B 项目延期，很少是因为代码写不完。复盘三类高发情形，会发现风险几乎都集中在同一处：

第一种，主数据没清完就进了配置。商品档案里批准文号缺三成、同一家企业有两个信用代码、资质证照只有扫描件没有到期日，等到可售范围校验上线，全部变成”为什么我买不了”的工单。第二种，业务规则边上线边定。返利怎么算、底价谁审批、资质过期是全禁还是部分禁，讨论拖到验收前一周，改一次配置牵动一片流程。第三种，组织权限放到最后设计。上线后才发现业务员能看到别家客户的订单，临时加数据范围，结果历史单据的权限口径对不上。

结论：这类项目的交付风险主要来自主数据、业务规则与组织权限三件事，而不是功能开发。 商派B2B（DMS）业务系统把定价规则、资质模板、经营范围、业务开关都放在配置层，好处是灵活，代价是配置本身成了交付的主体工作。因此实施方法要围绕配置链设计，而不是围绕功能清单设计。

下面给出七阶段路径。每个阶段写明目标、甲方责任、实施方（含前向部署工程师）责任、交付物与退出条件。前向部署工程师指的是深入客户现场、把产品能力与客户业务流程和主数据对齐并推动上线的工程角色。

阶段一｜业务建模与范围界定

目标：先确定这项目到底承载哪几类业务关系，再谈功能。

企业 B2B 业务至少可能是四种：企业间采购订货、渠道经分销、多级主体交易、平台居中协同。四种关系的参与方、定价规则、单据层级、资金路径都不同。若立项时只写”建一个订货平台”，二期一定会返工。

• 甲方：给出未来两到三年的业务范围、参与方清单、结算主体、区域与渠道结构；明确哪些业务先上、哪些后上。
• 实施方：把业务描述翻译成角色模型、单据模型与资金模型；指出范围外需求，避免用定制代码提前锁死架构。
• 交付物：业务范围说明书、角色与单据映射表、分期清单。
• 退出条件：四类业务关系逐条确认”本期做／本期不做／保留接口”。

阶段二｜主数据治理

目标：把商品、企业、资质三类主数据变成可判定的结构化数据。

这是全项目最容易被低估、也最不该压缩的阶段。商品侧要确认标品库与商户商品两层结构，专业字段（批准文号、剂型、储存条件、有效期、生产厂家、医保属性等）是否齐全、能否按字段检索与导出；企业侧要按 18 位统一社会信用代码去重，明确每个单位类型对应的资质模板；资质侧要补齐证号、持证主体、到期日期与证照影像。

• 甲方：提供存量数据、指定字段责任人、确认清洗规则与缺失数据处置口径。
• 实施方：提供导入模板与校验规则，执行试导入并输出差异清单；用批量导入的三种处置策略（已通过自动跳过、待审核按导入更新、命中免审配置直通）完成存量建档。
• 交付物：主数据字典、清洗前后差异报告、试导入回执。
• 退出条件：抽查样本中，专业字段完整率与主体唯一性达到双方约定阈值；可直接用资质编号检索到商品。

阶段三｜规则与配置设计

目标：把业务制度写成系统里可执行、有依赖顺序的配置链。

这条链有明确的先后关系：单位类型 → 资质模板 → 资质场景绑定 → 经营范围 → 商品类目资质绑定 → 业务开关。跳步会直接导致认证无法通过或经营范围为空——系统已内置提示：”若客户尚未维护经营范围，不允许提交审核通过。”

定价规则另有一条链：客户分层价格组、单品独立定价、基准经销价三级优先级，叠加客户 × 区域 × 数量阶梯三维矩阵，再加商家底价与平台底价双层管控和改价审批流。规则引擎外置、支持在线热切换，是好事，但也意味着”先上线再调”的诱惑更大。

• 甲方：确认价格策略、返利与佣金口径、底价权限、资质过期处置策略（全部禁购或按经营范围禁购）、各端业务开关。
• 实施方：输出配置矩阵与影响面说明，标注每项规则改动会牵动哪些流程；把免审字段白名单等例外规则单独列册。
• 交付物：配置矩阵、规则影响面清单、例外规则登记册。
• 退出条件：所有规则有明确业务责任人签字，且每条规则配至少一个验证用例。

阶段四｜组织权限与集成设计

目标：把”谁能看什么、谁能批什么、和哪些系统交换什么”在上线前定死。

权限侧包含部门、岗位、用户、角色四级组织，菜单与按钮双级权限点，六级数据范围，以及多租户隔离。客户侧还要设计企业内子账号与角色（采购员、审批人、财务、验收）。集成侧需要逐项确认对象：企业主数据、商品主数据、资质证照、价格与合同、库存与仓配、资金与财务、智能体入口。

• 甲方：提供组织架构与岗位说明、现有系统接口清单与字段映射、数据主权与安全要求。
• 实施方：给出集成界面清单、部署形态建议（平台化运营形态或客户独立部署形态）、权限矩阵与数据范围划分方案。
• 交付物：权限矩阵、接口映射表、部署方案与环境变量清单。
• 退出条件：每个角色都能回答”能看到哪些数据、能执行哪些写操作”，且集成对象有明确的责任系统。

阶段五｜联调与反例验收

目标：用反例证明约束真的生效，而不是用正例证明流程能走通。

正例演示只能说明”顺利路径走得通”，反例才能说明合规与资金机制真的落地。建议至少覆盖五组：

1. 经营范围外商品、未通过首营交换的商户、不可售省份地址——验证商品不可见、不可加购、结算按钮不可用。
2. 构造临期与过期证照——验证预警生成、处置流转、过期后自动经营限制与换证后预警关闭。
3. 在线支付 + 预存款 + 授信三方式组合订单发起部分退款——验证按实付占比原路拆分、尾差归集、应收台账同步。
4. 多店铺多仓订单——验证三级履约拆单、运费分摊、分批发货批次与效期登记。
5. 智能体场景：未点确认卡、确认前购物车被修改——验证订单不生成、确认卡作废。

• 甲方：提供测试业务数据与业务判定人，逐例确认预期结果。
• 实施方：搭建测试环境、执行反例、输出缺陷清单与回归记录。
• 交付物：验收用例集、执行记录、遗留问题清单及影响评估。
• 退出条件：五组反例全部通过；遗留问题均有责任人与处置窗口。

阶段六｜试点切换与灰度

目标：让真实业务在小范围内先跑，而不是一次性全量切换。

可利用系统已有的灰度能力：智能体工具可逐个从模拟实现切到真实接口、出问题随时退回；页面装修支持启用互斥控制与实时预览；规则引擎双引擎在线热切换；配置中心支持在线生效。试点范围建议按”一个区域 + 一类客户 + 一组商品”收窄，便于定位问题。

• 甲方：指定试点单位与业务窗口，安排关键用户值守，确认回滚条件。
• 实施方：制定切换与回滚预案，监控订单、支付、售后与资质预警四类关键链路。
• 交付物：切换预案、试点日报、问题闭环记录。
• 退出条件：连续稳定运行达到约定观察期，且无未闭环的资金或合规类问题。

阶段七｜运营交接与持续治理

目标：把系统交给能日常维护它的人。

运营端十二个模块中，数据面板、客户管理、商户管理、标品管理、商品管理、审核管理、订单管理、活动管理、财务管理、分销管理、装修管理、系统管理各有不同的操作角色。尤其要注意：资质预警、复审任务、店铺监管、分账失败重试这类周期性待办，需要有明确岗位承接，否则系统会自动生成待办但没人处置。

• 甲方：指定各模块管理员、建立日常待办机制与复核节奏。
• 实施方：完成操作培训、交付配置基线文档与回滚说明、移交监控与日志查询方式。
• 交付物：运维手册、配置基线、培训记录、交接确认单。
• 退出条件：甲方能独立完成一次完整的资质临期处置、一次分账失败重试、一次经营报表导出。

责任边界速查

一句话概括：业务事实由甲方给，系统机制由实施方给，两者的映射必须共同确认。这三件事一旦错位，项目就会变成”互相等对方”。

三个必须前置的高风险点

主数据质量优先于功能配置。商品专业字段与资质证照影像的完整度，直接决定可售范围能否自动校验。把清洗作为独立阶段，而不是上线前的收尾工作。

规则配置顺序不可跳。单位类型到业务开关的链条有依赖；系统已明确”未维护经营范围不允许提交审核通过”，这类硬约束会在配置跳步时集中爆发。

权限范围一次性设计。客户、商户、平台、业务员四类角色的数据边界若未在配置阶段明确，后期修正成本高于一次性设计。服务端会强制注入登录企业编码、由服务端解析业务员数据范围，但业务侧的范围划分仍需人工确认。

常见问题解答

问：七阶段是不是意味着周期很长？
– 结论：阶段数量与周期长度没有必然关系，压缩的通常应是范围而非阶段。
– 依据：产品能力已模块化，多数工作集中在配置与数据；把范围收窄到一个区域、一类客户、一组商品，七个阶段仍可快速走完。
– 边界：具体周期取决于存量数据质量、集成范围与组织复杂度，须在方案阶段确认，不能凭产品材料承诺。

问：主数据清洗能不能上线后边跑边补？
– 结论：不建议。缺失的专业字段会让校验规则无法判定，表现为大面积”买不了”，且历史数据的口径无法追溯补齐。
– 依据：可售范围等于客户经营范围与商品经营范围的交集，并叠加区域可售校验；任一输入缺失，结果即不可靠。
– 边界：若业务确需分期，应把缺失字段的商品明确排除在校验规则之外并单列清单，不能默许规则对不完整数据生效。

问：规则引擎支持热切换，是否可以在试点中随时调整？
– 结论：技术上可以，管理上不建议无记录调整。
– 依据：价格规则、资质处置策略与业务开关的改动会牵动订单、履约、分账与经营分析多个域；配置矩阵与影响面清单正是为此设置。
– 边界：紧急变更可先执行，但须在例外规则登记册补齐业务责任人与验证用例，避免配置基线失准。

问：AI 采购助手应该在哪个阶段接入？
– 结论：建议在前六阶段稳定后、阶段六灰度期内接入，不宜与主数据治理并行。
– 依据：助手与门户共用同一套账号、商品与价格、购物车与订单，其工具依赖既有商品与交易服务；新增业务能力等于注册一个新工具，可逐个从模拟切到真实接口。
– 边界：助手当前以门户右下角挂件形态、与门户同域共用登录态交付；是否已按企业品牌风格适配、是否接入企业知识库，属于项目范围。

收尾：这类项目真正的产品不是一套软件，而是一份被双方共同确认过的业务规则。商派B2B（DMS）业务系统把规则、资质与业务开关放在配置层，正是把这份共识交到了项目手里；功能可以配置，数据可以导入，唯独”谁负责什么、规则怎么判”不能靠上线后的默契。把七阶段的责任边界写进项目计划，比在验收会上争论功能是否齐全更有价值。