物流ERP系统 - 智能物流选型模块需求分析报告
版本：v1.0 | 日期：2026-01-28 | 状态：需求分析阶段
一、需求概述与背景分析
1.1 项目背景
随着公司多国家、多站点业务的快速发展，物流选型已成为影响运营成本和效率的关键环节。当前业务面临以下挑战：
| 维度 | 现状 | 问题 |
|---|---|---|
| 业务规模 | 覆盖33个国家，60种物流渠道，11家物流商 | 选型复杂度指数级增长 |
| 数据规模 | 13个工作表，2249行价格数据 | 人工维护困难，易出错 |
| 计费规则 | 多种运输方式，多种附加费 | 人工计算易遗漏 |
| 决策效率 | 依赖Excel手工比价 | 无法支撑高频、规模化需求 |
1.2 核心诉求
将经过验证的Excel物流比价逻辑系统化落地至ERP，实现：
- 自动化 - 系统自动计算物流成本，替代人工测算
- 标准化 - 统一物流选型标准，消除人为判断差异
- 最优化 - 输出综合成本最低的物流方案
- 可追溯 - 计算过程透明，便于审计和复核
1.3 业务价值
预期业务价值
- 效率提升：单次选型从 15-30分钟 → 秒级响应
- 成本降低：避免计算遗漏导致的成本低估（预估降低 3-5% 隐性损失）
- 风险管控：统一规则，消除人为选型偏差
- 决策支持：多维度对比，支持最优决策
二、业务流程分析
2.1 现有业务流程（AS-IS）
业务员获取发货需求
↓
打开Excel价格表
↓
手动筛选国家+运输方式
↓
逐个计算各渠道费用 ← 【耗时长、易出错】
↓
是否考虑所有附加费？
↓ 遗漏 → 成本低估风险
↓ 完整
对比义乌/深圳发货成本
↓
人工判断最优方案 ← 【依赖经验】
↓
录入ERP下单
现有流程痛点分析：
| 环节 | 痛点 | 严重度 | 发生频率 |
|---|---|---|---|
| 手动筛选 | 渠道多，易漏选 | 中 | 高 |
| 费用计算 | 附加费易遗漏，计算错误 | 高 | 高 |
| 成本对比 | 义乌/深圳需分别计算 | 中 | 每次 |
| 方案选择 | 依赖个人经验，缺乏标准 | 高 | 每次 |
| 数据维护 | Excel多人编辑，版本混乱 | 高 | 持续 |
2.2 目标业务流程（TO-BE）
业务员输入发货条件
↓
系统自动匹配可用渠道
↓
系统计算各渠道完整成本
↓
系统分别计算义乌/深圳方案
↓
系统排序输出最优方案
↓
是否需要龙舟渠道？
↓ 是 → 单独展示龙舟预估成本
↓ 否
确认选型方案
↓
一键下单至ERP
三、功能需求清单
3.1 功能全景图
物流智能选型模块
├── 基础数据管理
│ ├── 物流商管理
│ ├── 物流渠道管理
│ ├── 价格规则管理
│ └── 附加费规则管理
├── 核心计算引擎
│ ├── 计费重量计算
│ ├── 基础运费计算
│ ├── 附加费计算
│ └── 综合成本汇总
├── 智能选型服务
│ ├── 渠道匹配筛选
│ ├── 多方案比价
│ ├── 最优方案推荐
│ └── 龙舟独立查询
└── 结果展示与输出
├── 方案对比视图
├── 成本明细展示
└── 选型记录追溯
3.2 功能需求明细
P0 - 核心功能（必须实现）
| 编号 | 功能名称 | 功能描述 | 验收标准 |
|---|---|---|---|
| F001 | 物流选型入口 | 提供统一的物流选型界面，支持输入国家、运输方式、重量、体积 | 界面响应<1秒，字段校验完整 |
| F002 | 计费重量计算 | 根据渠道规则，计算体积重并与实重对比，取大值 | 计算结果与Excel一致率100% |
| F003 | 基础运费计算 | 根据重量区间匹配单价，计算基础运费 | 支持阶梯计价，精度0.01元 |
| F004 | 附加费计算 | 根据货物属性自动匹配适用的附加费 | 支持13种附加费类型 |
| F005 | 渠道筛选匹配 | 根据国家+运输方式筛选可用渠道 | 筛选逻辑与Excel一致 |
| F006 | 双发货地计算 | 同时计算义乌、深圳两个发货地的成本 | 并行计算，结果分组展示 |
| F007 | 最优方案排序 | 按总成本升序排列，输出最优方案 | 支持并列最低全展示 |
| F008 | 龙舟独立展示 | 龙舟渠道单独展示，不参与比价 | 明确标注"不参与比价" |
P1 - 重要功能（优先实现）
| 编号 | 功能名称 | 功能描述 | 验收标准 |
|---|---|---|---|
| F009 | 邮编精确匹配 | 根据邮编筛选可达渠道，匹配区域报价 | 邮编格式校验，模糊匹配 |
| F010 | 仓库精确匹配 | 根据亚马逊仓库代码筛选渠道 | 支持仓库代码库维护 |
| F011 | 成本明细展开 | 展示每个方案的费用构成明细 | 基础运费+各附加费逐项列出 |
| F012 | 选型记录保存 | 保存每次选型的输入条件和结果 | 支持按时间、国家查询历史 |
P2 - 增强功能（后续迭代）
| 编号 | 功能名称 | 功能描述 | 验收标准 |
|---|---|---|---|
| F013 | 批量选型 | 支持上传Excel批量计算 | 单批支持500条以上 |
| F014 | 价格变动预警 | 物流商调价时自动提醒 | 支持设置变动阈值 |
| F015 | 历史价格趋势 | 展示各渠道价格走势 | 支持30/60/90天趋势图 |
| F016 | 选型报告导出 | 支持导出PDF/Excel格式报告 | 包含完整计算过程 |
3.3 非功能需求
| 类别 | 需求描述 | 指标要求 |
|---|---|---|
| 性能 | 单次选型计算响应时间 | < 3秒（60个渠道全量计算） |
| 并发 | 支持同时在线用户数 | >= 50人 |
| 准确性 | 计算结果与Excel基准对比 | 100%一致 |
| 可用性 | 系统可用性 | 99.9%（工作时间） |
| 数据 | 价格数据更新实时性 | 更新后立即生效 |
四、数据需求分析
4.1 数据实体模型
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ 物流商 │ │ 物流渠道 │ │ 价格规则 │
│ Carrier │────<│ Channel │────<│ PriceRule │
├─────────────────┤ ├─────────────────┤ ├─────────────────┤
│ carrier_id │ │ channel_id │ │ rule_id │
│ carrier_name │ │ channel_name │ │ channel_id │
│ contact_info │ │ carrier_id │ │ country │
│ status │ │ transport_mode │ │ calc_method │
└─────────────────┘ │ cargo_type │ │ start_weight │
│ origin_city │ │ end_weight │
│ volume_formula │ │ unit_price │
└─────────────────┘ │ total_price │
└─────────────────┘
│
┌─────────────────┐ ┌───────┴─────────┐
│ 附加费规则 │ │ 区域/仓库映射 │
│ Surcharge │ │ ZoneMapping │
├─────────────────┤ ├─────────────────┤
│ surcharge_id │ │ mapping_id │
│ channel_id │ │ rule_id │
│ surcharge_type │ │ zone_code │
│ condition │ │ postal_prefix │
│ amount │ │ warehouse_code │
└─────────────────┘ └─────────────────┘
4.2 附加费类型清单（13种）
| 1. 一票一件附加费 | 2. 超品名费 | 3. 纺织品附加费 |
| 4. 木制品附加费 | 5. 瓷器附加费 | 6. 蓝光眼镜附加费 |
| 7. 圆珠笔附加费 | 8. 资源调节费 | 9. 开瓶器附加费 |
| 10. 丝带附加费 | 11. 纯纺织品附加费 | 12. 陶瓷产品附加费 |
| 13. 清关费 |
4.3 数据迁移策略
| 阶段 | 任务 | 数据量 | 校验方式 |
|---|---|---|---|
| 第一阶段 | 物流商&渠道主数据导入 | 11家 + 60渠道 | 人工核对 |
| 第二阶段 | 价格规则导入 | 2249行 | 抽样计算对比 |
| 第三阶段 | 附加费规则导入 | ~200条 | 全量校验 |
| 第四阶段 | 历史数据验证 | 选取100个历史订单 | 与Excel结果对比 |
五、技术实现要点
5.1 核心算法设计
5.1.1 计费重量计算
输入：实际重量W(kg), 长L(cm), 宽W(cm), 高H(cm), 体积重公式F
输出：计费重量
算法：
1. 计算体积：V = L × W × H
2. 解析公式F，计算体积重：VW = V / 公式除数（如6000）
3. 计费重量 = MAX(W, VW)
4. 按渠道规则进位（如向上取整到0.5kg）
5.1.2 综合成本计算
输入：渠道ID, 计费重量, 货物属性
输出：总成本, 成本明细
算法：
1. 匹配价格规则：找到重量区间对应的单价/总价
2. 计算基础运费：
- 若有单价：基础运费 = 计费重量 × 单价
- 若有总价：基础运费 = 总价
3. 匹配附加费规则：根据货物属性筛选适用的附加费
4. 计算各项附加费
5. 总成本 = 基础运费 + SUM(附加费)
5.2 关键技术选型建议
| 技术点 | 建议方案 | 理由 |
|---|---|---|
| 规则引擎 | Drools / 自研轻量引擎 | 附加费规则复杂，需灵活配置 |
| 计算精度 | BigDecimal | 金额计算避免浮点误差 |
| 缓存策略 | Redis 缓存价格规则 | 价格数据变动低，缓存提升性能 |
| 并发计算 | 多线程并行计算 | 60渠道同时计算，提升响应速度 |
六、风险与挑战
6.1 风险评估矩阵
| 风险项 | 可能性 | 影响度 | 风险等级 | 应对策略 |
|---|---|---|---|---|
| 计算结果与Excel不一致 | 中 | 高 | 高 | 全量测试用例覆盖，UAT阶段并行运行 |
| 价格数据迁移遗漏 | 中 | 高 | 高 | 制定数据校验清单，双人复核 |
| 附加费规则理解偏差 | 高 | 中 | 高 | 与业务方逐条确认规则逻辑 |
| 新渠道/新规则难扩展 | 中 | 中 | 中 | 采用配置化设计，支持热更新 |
| 性能不达标 | 低 | 中 | 低 | 引入缓存，优化算法复杂度 |
七、建议与结论
7.1 实施路径建议
Phase 1（4周） Phase 2（3周） Phase 3（2周）
──────────────── ──────────────── ────────────────
基础数据管理 核心计算引擎 智能选型服务
- 物流商管理 - 计费重量计算 - 渠道匹配筛选
- 渠道管理 - 基础运费计算 - 多方案比价
- 价格规则管理 - 附加费计算 - 最优推荐
- 数据迁移 - 计算验证 - 龙舟独立处理
Phase 4（2周） Phase 5（1周）
──────────────── ────────────────
UAT验证 上线切换
- 100订单验证 - 灰度发布
- Excel并行对比 - 全量切换
- 业务培训 - Excel收口
7.2 结论
| 维度 | 评估 |
|---|---|
| 业务必要性 | 高 - 现有Excel已无法支撑业务规模 |
| 技术可行性 | 高 - 逻辑已在Excel验证，系统化实现无技术障碍 |
| 投入产出比 | 高 - 预计3个月内上线，效率提升立竿见影 |
| 风险可控性 | 中 - 主要风险在数据迁移和规则理解，可通过充分测试化解 |
建议
尽快启动项目，按照分阶段策略推进，优先实现核心计算功能，确保计算准确性后再扩展增强功能。
附录：数据规模统计
| 维度 | 数量 |
|---|---|
| 物流商 | 11家（百运、顺丰、丰信、启航、华旗、快贝、美盈、皓鹏、美通、龙舟等） |
| 物流渠道 | 60种 |
| 运输方式 | 5种（空派、快递、海运、铁路、卡航） |
| 货物类型 | 3种（普货、带电、普货带电） |
| 发货地 | 4种配置（义乌、深圳、义乌深圳、深圳义乌） |
| 目的国家 | 33个 |
| 附加费类型 | 13种 |
| 价格数据行数 | 2249行 |
物流ERP系统 - Agent场景模拟报告
模拟方法论: G. Lynn Shostack 服务蓝图 + 用户旅程分析
生成日期: 2026-01-28 | 版本: v1.0
第一步：定义业务流程
业务流程定义
| 流程名称 | 物流成本最优方案计算 |
| 流程目标 | 根据用户输入的货物信息，自动计算并输出综合物流成本最低的方案 |
| 触发条件 | 用户在询价界面填写完必填字段（国家、运输方式、重量、体积）并点击"查询" |
| 主流程步骤 | 输入参数 → 渠道筛选 → 计费重量计算 → 费用计算 → 排序比价 → 结果展示 |
| 终态 | 展示义乌/深圳两地最优方案列表，用户可选择或导出 |
主流程步骤分解
Step 1: 用户输入货物参数
↓
Step 2: 系统校验输入合法性
↓
Step 3: 根据【国家+运输方式】筛选可用渠道
↓
Step 4: 识别货物属性（普货/带电/敏感品等）
↓
Step 5: 计算计费重量 = max(实际重量, 体积/体积系数)
↓
Step 6: 查询各渠道基础运费（重量区间阶梯计价）
↓
Step 7: 累加所有适用附加费
↓
Step 8: 按发货地分组（义乌/深圳）
↓
Step 9: 排序输出最优方案
↓
Step 10: 龙舟渠道单独展示
第二步：识别角色 & 模拟角色选择
涉及角色池
| 角色 | 描述 | 与此流程的关系 |
|---|---|---|
| 运营人员 | 日常处理FBA发货询价，追求效率 | 主流程执行者，高频使用 |
| 采购人员 | 负责供应商对接，关注成本优化 | 决策参考者，周期性使用 |
| 物流专员 | 专业物流知识，负责渠道对接 | 规则维护者，异常处理者 |
| FBA运营 | 专注亚马逊业务，精准仓库需求 | 精准匹配需求者 |
| 成本分析师 | 数据导向，需要完整比价信息 | 全量数据需求者 |
| 新手运营 | 经验不足，依赖系统引导 | 边界场景触发者 |
| 系统管理员 | 维护渠道价格和规则 | 后台支撑者 |
第三步：逐步模拟
场景1：美国空运普货询价
角色设定
角色身份：王强，运营专员（3年经验） 经验水平：熟练 — 每日处理20+询价，熟悉主流渠道 KPI/动机： 1. 询价响应时效（<2分钟） 2. 成本准确率（误差<5%） 3. 客户满意度 手上已知信息： - 目的国：美国 - 运输方式：空运 - 重量：50kg - 体积：60000cm³ - 邮编：90210（美西） 不确定信息： - 货物品类是否为普货？ - 是否有木质包装？ - 是否带电/带磁？
作为 运营人员王强，我想要 快速查询美国空运的最低成本方案，以便于 在2分钟内给客户报价，赢得订单。
关键步骤模拟
| 步骤 | 用户操作 | 问题/卡点 |
|---|---|---|
| 填写基础参数 | 选择国家、运输方式、输入重量体积 | 体积输入方式不明确：cm³ 还是 长宽高？ |
| 确认货物属性 | 想选"普货" | 货物类型如何输入？必填还是选填？ |
| 查看计算结果 | 查看义乌/深圳方案 | 义乌/深圳是Tab切换还是并排展示？ |
| 导出或选择 | 点击"复制报价" | 询价后是否支持直接下单？ |
场景1小结
| 检查项 | 状态 | 说明 |
|---|---|---|
| 输入参数完整性 | ⚠️ | 体积输入方式、货物类型未明确 |
| 计算逻辑清晰度 | ⚠️ | 体积系数差异、区域匹配规则需透明 |
| 结果展示可用性 | ⚠️ | 义乌/深圳展示方式、费用明细未定义 |
| 后续动作闭环 | ❌ | 询价后是否下单、报价有效期未定义 |
场景2：欧洲海运带电产品
角色设定
角色身份：李敏，采购专员（2年经验） 压力情境：供应商催发货，但担心带电产品被退运 手上已知信息： - 目的国：德国 - 运输方式：海运 - 重量：200kg / 体积：0.5CBM - 产品类型：带电产品（蓝牙耳机） 不确定信息： - 电池类型？锂电池 or 镍氢？ - 是否有UN38.3认证？
关键问题
| 问题 | 影响 |
|---|---|
| 带电产品分类：是否区分纯电池/内置电池/配套电池？ | 不同类型限制不同，可能导致货物被退运 |
| 体积单位是否支持切换？cm³ / m³ / CBM | 0.5CBM = 500000cm³，单位转换易出错 |
| 渠道是否维护"支持货物类型"属性？ | 缺失则无法自动筛选 |
场景3：英国铁路自税渠道
角色设定
角色身份：张华，物流专员（5年经验） 压力情境：客户要求走自税渠道以节省成本，但担心清关风险 需求：筛选出英国铁路的自税渠道（客户有英国VAT号）
关键问题
| 问题 | 影响 |
|---|---|
| 系统是否支持按清关方式筛选？DDP/DDU/自税 | 需求未提及，需补充 |
| 自税渠道是否只显示运费？客户还需缴纳VAT+关税 | 张华需要告知客户完整成本 |
| 是否提供"自税 vs DDP"一键对比？ | 帮助客户决策的功能缺失 |
场景4：亚马逊仓库精准匹配
角色设定
角色身份：陈琳，FBA运营（1.5年经验） 压力情境：亚马逊指定送ONT8仓库，需要精准报价 手上已知信息： - 亚马逊仓库：ONT8（加州 Ontario） - 重量：500kg / 体积：2CBM
关键问题
| 问题 | 影响 |
|---|---|
| 仓库代码库如何维护？美国、欧洲、日本仓库是否全覆盖？ | 亚马逊有100+仓库 |
| 仓库代码输入后，是否显示"ONT8 - 加州 Ontario"提示？ | 用户需要验证匹配正确性 |
| 同时填写邮编和仓库代码，以哪个为准？ | 优先级未定义 |
场景5：龙舟渠道对比查询
角色设定
角色身份：刘伟，高级运营（6年经验） 需求：对比龙舟渠道与市场最低价，评估龙舟渠道竞争力
关键问题
| 问题 | 影响 |
|---|---|
| 龙舟在哪里展示？独立Tab or 页面底部？ | 需求说"单独展示"但未定义位置 |
| 是否显示"比市场最低价贵/便宜X%"？ | 刘伟需要直观对比数据 |
| 是否标注龙舟的差异化优势？（如：含保险、优先派送） | 价格不是唯一维度 |
场景6：边界情况 - 无可用方案
角色设定
角色身份：小周，新手运营（入职3个月） 压力情境：客户询问，不确定如何回复"查不到" 输入：某偏远国家（如土库曼斯坦）+ 铁路
关键问题
| 问题 | 影响 |
|---|---|
| 若国家不在33个国家列表中，输入如何处理？ | 禁止提交 or 提交后报错？ |
| 空结果提示文案是什么？ | "无结果"太简略，需要说明原因 |
| 是否自动推荐"该国家可用的运输方式"？ | 智能推荐功能缺失 |
场景7：并列最低价展示
角色设定
角色身份：赵芳，成本分析师（4年经验） 需求：看到所有最低价渠道（即使并列），基于时效、服务等次要因素做最优选择
关键问题
| 问题 | 影响 |
|---|---|
| 价格相同时的第二排序维度是什么？ | 时效 > 服务评分 > 物流商名称？未定义 |
| 是否在界面上标注"价格并列"？ | 帮助用户理解排序 |
| 是否支持"勾选对比"功能？ | 多渠道对比功能缺失 |
第四步：模拟报告
主流程闭环检查
| 检查项 | 状态 | 说明 |
|---|---|---|
| 输入参数定义 | ⚠️ | 体积输入方式、货物类型、单位不明确 |
| 渠道筛选规则 | ⚠️ | 国家+运输方式之外的筛选条件（带电、清关方式）未定义 |
| 计费重量计算 | ✅ | 公式明确：max(实重, 体积/系数) |
| 费用计算规则 | ⚠️ | 区间阶梯计价细则、附加费触发条件未完整 |
| 义乌/深圳分组 | ⚠️ | 展示方式（Tab/并排）未定义 |
| 结果排序规则 | ❌ | 并列价格排序、龙舟展示位置未定义 |
| 龙舟单独展示 | ⚠️ | 展示位置、对比方式未定义 |
| 后续动作 | ❌ | 询价后的下单、导出、有效期未定义 |
结论：主流程核心计算逻辑闭环，但输入规范、展示规则、后续动作存在明显断点。
待确认问题清单（P0优先级）
| # | 问题 | 影响范围 | 优先级 |
|---|---|---|---|
| 3 | 货物类型如何输入？是否必填？默认值？ | 业务规则 | P0 |
| 4 | 带电产品分类：是否区分纯电池/内置/配套？ | 业务规则 | P0 |
| 16 | 询价后是否支持直接下单？还是仅供参考？ | 业务规则 | P0 |
待确认问题清单（P1优先级）
| # | 问题 | 影响范围 |
|---|---|---|
| 1 | 体积输入方式：直接输入cm³ vs 输入长宽高自动计算？ | 用户体验 |
| 2 | 体积单位是否支持切换？cm³ / m³ / CBM | 用户体验 |
| 5 | 附加费（纺织/木制/瓷器等）如何关联到货物？用户选 or 系统识别？ | 业务规则 |
| 6 | 渠道是否维护"支持货物类型"属性？如何维护？ | 开发实现 |
| 7 | 渠道是否维护"清关方式"属性？DDP/DDU/自税 | 业务规则 |
| 11 | 义乌/深圳结果展示方式：Tab切换 or 并排展示？ | 用户体验 |
| 13 | 龙舟渠道展示位置？是否提供对比视图？ | 用户体验 |
| 14 | 无可用方案时的提示文案？是否提供替代建议？ | 用户体验 |
| 15 | 询价结果有效期？价格波动后如何处理？ | 业务规则 |
| 20 | 计算超时（如10秒）如何处理？ | 异常处理 |
漏掉的分支流程
| # | 分支名称 | 说明 | 影响 |
|---|---|---|---|
| 1 | 敏感品识别 | 除带电外，还有敏感品（液体、粉末、磁性等），未提及如何处理 | 可能导致货物被退运 |
| 2 | 超重/超大件处理 | 超过渠道重量/体积上限时如何提示？ | 用户无法获得报价 |
| 3 | 拼柜/整柜选择 | 海运大货量是否支持整柜询价？ | 大客户需求缺失 |
| 4 | 保险费用计算 | 是否支持加保？保险费如何计入成本？ | 高货值客户需求 |
| 5 | 批量询价 | 多个SKU/多个目的地批量询价 | 效率需求 |
| 6 | 历史价格查询 | 查看某渠道历史价格走势 | 决策支持 |
| 7 | 渠道评价/反馈 | 用户对渠道服务的评价，影响推荐排序 | 质量管理 |
| 8 | 价格有效期管理 | 报价单有效期、过期提醒 | 业务闭环 |
| 9 | 异常场景处理 | 部分渠道计算失败、数据缺失时的降级策略 | 系统稳定性 |
| 10 | 多币种支持 | 是否支持美元/欧元/人民币切换？ | 国际业务需求 |
质量检查清单
第一步是否明确了触发条件和终态？ — 是
第二步是否给出了>=3个角色？ — 是（7个角色）
第三步每个Step是否都有分支问题？ — 是
第四步是否输出了待确认问题清单？ — 是（20个问题）
所有问题是否都指向：业务规则/数据口径/状态机/权限/异常处理/验收？ — 是
是否发现了漏掉的分支流程？ — 是（10个分支）
下一步行动
与产品经理逐一确认待确认问题清单，优先解决P0/P1问题。