非洲物流 TMS 项目 · 前期调研报告

Part 01

五个可能改变项目走向的发现

⛔ 技术互斥

微信小程序 + 约翰内斯堡部署，按字面写法做不出来

这不是"有难度"，是两个需求条款在技术上不可同时成立：

微信官方明文要求小程序 request 合法域名必须经过 ICP 备案（开放接口返回体里直接有 no_icp_domain 字段）
ICP 备案要求域名解析到中国内地服务器
需求书 2.4 要求服务端、数据库、文件服务、接口服务全部部署于约翰内斯堡

唯一出路是境外主体小程序，但需海外子公司 + 使领馆认证 + 类目申请，2–4 周行政前置且结果不可控。

叠加的用户侧现实

坦桑尼亚智能手机普及率仅 35–42%（TCRA 官方 2025）；赞比亚农村智能手机拥有率仅 21.0%（ITU/ZICTA 2025）——而跨境矿运路线多途经农村。坦桑 WhatsApp 占主导，微信在非洲已基本退出；98.6% 的小程序用户在中国大陆。

再叠加技术能力边界

小程序切后台 5 秒挂起、30 分钟销毁 → 没有后台静默同步能力。需求书要求的"联网后自动增量同步"做不到。

推荐替代：uni-app（一套代码产出 Android APK + H5 + 小程序），司机端主推 Android APK（离线优先），管理端用 H5。

⛔ 法律限制

赞比亚法律规定：铜精矿境内运输只能由本地运输商承运

Statutory Instrument No. 35 of 2021（Citizens Economic Empowerment 条例）：

在赞比亚境内运输附表所列商品，只能由本地运输商（local road transporter）承运
从赞比亚出口附表所列商品，至少 50% 由本地运输商承运

附表商品明确包含 Concentrates、Copper、Anode、Cobalt、Manganese、Cement、Clinker、Fertilizer —— 即本项目全部主力货种。

执行实证：FQM 旗下 Kalumbila Minerals 重新招标精矿运输合同，授予两家赞比亚公民所有的运输公司（Buks Haulage、JC Bousfield），合计 135 台车月运 9 万吨精矿，明确依据 Citizens Economic Empowerment Act。

【推断】这直接冲击客户的业务模式假设。如果实际运营是"中资主体 + 本地承运商分包"，那系统里的"自营车队"就变成了自营 + 分包混合，数据模型完全不同。

来源：zambialii.org · SI 35 of 2021 公报原文

⛔ 架构冲突

赞比亚数据保护法把 GPS 位置数据列为个人数据，强制境内存储

Data Protection Act, 2021（第 3 号法案）第 70 条：

数据控制者必须在赞比亚境内的服务器/数据中心处理和存储个人数据
敏感个人数据永远只能存在赞比亚境内，无豁免空间
该法对"个人数据"的定义明确包含 location data（位置数据）

含义：TMS 的 GPS 车辆/司机轨迹数据在赞比亚法律下很可能被视为个人数据 → "全部部署约翰内斯堡"的单区域方案违法。若移动端演进为人脸/指纹打卡，则触发"敏感个人数据"条款，完全无豁免空间。

坦桑尼亚 PDPA (2022) 同样要求：数据控制者须向 PDPC 注册；生物特征等敏感数据处理需事先书面同意。2026-01 已发最终宽限通牒。

需求书对这些只字未提。架构从"单节点"变成"多国分布式 + 数据同步"，是另一个量级的工作量。

⚠️ 工作量

400 人天严重不足，交叉重估 990–1800 人天

工作量重估对比

单位：人天。多源交叉验证结果，含降级方案后的下限

需求书口径

400

全部降级后

740–1140

按字面实现

990–1800

客户/前供应商口径放弃小程序+SAP直连+简化多租户按需求书字面实现

支撑数据

Standish CHAOS Report：大型项目成功率低于 10%，小型项目约 90% —— 规模是成功率最强的单一预测因子
McKinsey–Oxford（5,400 个大型 IT 项目）：平均超预算 45%、交付价值比预期少 56%、17% 属于"黑天鹅"（超支 200%+）
Panorama 2026：超过四分之一企业项目超预算，中位实施周期 9 个月

主要缺口在哪

SAP HANA 双向实时对接 + 自动对账 —— 需求书列为"最高优先级"，但早期材料只字未提客户在用 SAP
可配置多级审批引擎 —— 八家企业级 TMS 里只有 SAP/Oracle 有产品化审批引擎，纯自研
配件成本分摊到车辆/车次/项目 —— 五家主流 FMS 均无此模块
轮胎全生命周期管理 —— 五家 FMS 均无
中英双语全量（含报表、导出文件、打印模板）—— ruoyi-vue-pro 后端没有 i18n
基础数据全量初始化（车头/车挂/司机/油品/油价/线路/客户/承运商/汇率/补助标准/费用规则/GPS设备/电子围栏/边境基础数据）

⚠️ 商务风险

SAP 许可是未定价的商务风险

SAP 官方《Indirect Access Guide》明文把 "Database link" 列入需许可的接入方式 —— 换接入方式不能规避。

TMS 触发财务凭证创建即构成 Digital Access 计费
Diageo 案 SAP 索赔 £5450 万并胜诉
HANA Runtime Edition 下"绕开应用界面的直连数据库操作被认定为许可违约"

【推断】需求书写的"深度对接 SAP HANA 服务器、双向实时数据互通"，若按字面理解为直连 HANA 数据库读写业务表，是反模式 + 许可风险。正确路径是走 SAP 标准接口（OData / SAP Gateway / Integration Suite），但需客户 SAP 侧配合与授权。

启动会必问：SAP 版本？S/4HANA 还是 ECC on HANA？谁维护？有无中间件？Digital Access 授权谁买单？

Part 02

架构与数据模型的关键决策

决策 1 · 本项目是 Carrier-side 自营车队 TMS，不是货代 TMS

这个定位决定了对标对象和模块边界。八家企业级 TMS 中，真正有独立自营车队模块的只有三家：

产品	自营车队模块	关键能力
Oracle OTM	✅ 独立模块	Driver Pay、HOS、Dispatch Board、Work Assignment、Fleet Aware Bulk Planning
Manhattan	✅ 独立模块	HOS + seniority（司机排班资历）、drivers/tractors/trailers 统一优化
Descartes	✅ 专门大类	Fleet Performance Management、Route Planner "trusted by private fleets"
SAP TM	⚠️ 无独立模块	把车辆/司机当 resource 融入统一规划
Alpega / Transporeon	❌ 完全没有	它们是撮合网络平台，服务对象是外部承运商网络

→ 对标应看 Oracle OTM 与 Manhattan，不要看 Alpega/Transporeon。Manhattan 的 "seniority" 字段（司机工龄排班约束）是自营车队工会排班的典型需求，说明它是真为自营车队设计的，不是货代产品的附赠。

决策 2 · 多段运输怎么拆 —— 必须早期拍板

两个全球最成熟的 TMS 给出了两种截然不同的答案，这是本项目最重要的单一架构决策。

	OTM 范式（leg 实体化）	SAP 范式（stage 内嵌）
做法	每条 leg 生成独立的 Order Movement 实体	Freight Unit 内部持有 Stage 集合
官方原话	"The order release is never split… Its movement is split among one or more shipments"	"In planning you refine this… the freight unit being transported from A to Z via B"
优点	便于按段分权、分角色协作（官方场景就是出口/海运/进口三个 planner 各管一段）	对象数少、追溯链短，实现成本低
代价	对象数量膨胀；拆分 ship unit 时要级联更新所有引用	跨段协作靠分配关系间接表达

【推断】对本项目的判断

本项目是「矿区装货 → 内陆运输 → 边境口岸 → 港口 → 海运」，且各段常由不同分公司（坦桑公司/赞比亚公司）负责，需求书还要求两国差异化审批与数据隔离。→ OTM 的 Order Movement 范式在组织协作上更贴合。

决策 3 · "净重"必须是四个字段，不是一个

这是矿运特有的、也是最容易犯的设计错误。行业铁律：

矿产品按干吨（DMT）计价，按湿吨（WMT）付运费。
OECD/IGF 铜转让定价框架

#	字段	用途
1	矿区地磅净重（WMT）	装货凭证
2	港口地磅净重（WMT）	交货凭证，通常的结算基准
3	干吨 DMT	= WMT × (1 − 水分率)，可能再减 weight franchise（常见 0.5%）
4	计费吨	合同约定以上述哪一个为准，并应用允差

现成范式：OTM 的 Shipment Ship Unit 有 ordered / booked / shipped / received 四层数量追踪 —— "shipped vs received" 的差额就是途损。

把这四个塞进一个 net_weight 字段，是这类项目最常见的设计事故。

决策 4 · Trip 必须阶段化

因为等待成本高到无法忽略：

2000km 单程：等待成本 vs 燃油成本

单位 USD。等待成本按 US$350/天（Brenthurst Foundation）

燃油（单程）

≈ 1,560

1,560

边境等待 3 天

1,050

边境等待 5 天

1,750

Tunduma/Nakonde 边境：非高峰 4–12 小时，月末/季末 24–48 小时甚至更长
2018 年基线测量：Nakonde 方向中位总过境时间 75 小时 56 分
Kasumbalesa（赞→刚果金）：2026 年 2 月实地观察车龙超 25 公里，排到队首约 5 天
ZRA 系统故障期间：每辆卡车每等待一天约 US$550

→ 每个阶段（空驶到矿 / 矿区装货 / 重车运输 / 港口卸货 / 返程）必须独立记录时间、里程、成本。

决策 5 · 不要试图替代矿内 FMS

Wenco / Modular Mining DISPATCH / Hexagon 解决的是"矿坑里 3–8 km 的循环、每天几十趟"，本项目是"公共道路 2000 km、单程一周、跨两国海关"。两者在数据模型（cycle vs trip）、通信（矿区 WiFi vs 蜂窝+卫星）、优化目标上都不同。

→ 在矿区地磅这个交接点对接取数即可，不要试图替代。

Part 03

无成品可抄的模块 —— 自研工作量的真实来源

调研了 5 家主流 FMS（Fleetio、Samsara、Geotab、Verizon Connect、Webfleet、Zonar、Motive、Trimble TMT 等）与 12 家非洲本土平台（Lori、Kobo360、Leta、Korridor、Trella、Wasoko 等），结论如下。

客户要求的模块	市场现状	结论
配件成本分摊至车辆/车次/项目	五家主流 FMS 无一家有"成本中心/内部分摊"原生模块	⛔ 纯自研
轮胎全生命周期管理（CPK/翻新/轮位矩阵）	五家均无。即便 Webfleet 母公司是 Bridgestone、Zonar 绑定 Continental，都停在 TPMS 胎压监测层	⛔ 纯自研
司机证件到期 / 跨境签证 / 出车补助核算	五家的"司机管理"都不是 HR 式档案管理（是安全/行为/合规口径）	⛔ 无对标
矿产计量（WMT/DMT/水分/途损/短溢）	12 家非洲平台 + 5 家 FMS，无一家有	⛔ 完全空白
过磅站 / 轴重 / 路桥费	12 家非洲平台全部空白	⛔ 完全空白
偷油管控	12 家非洲平台全部空白（有人做油耗监控，无人做管控闭环）	⛔ 完全空白
可配置多级审批引擎	八家企业级 TMS 中只有 SAP / Oracle 有产品化审批引擎	⚠️ 需自研
中英双语全量	ruoyi-vue-pro 后端没有 i18n（全仓无 MessageSource/LocaleResolver）	⚠️ 需自研

【推断】谈判含义

这张表是报价谈判的核心武器。客户/前供应商很可能默认这些是"配置一下"的事，实际上是全新开发。尤其"矿产计量"这一项——全球范围内所有商业物流平台都没做，目前完全由贸易商、第三方检验行和纸质流程覆盖。

为什么会有这么大的空白

【推断】欧美车队多为自营单一成本主体，成本分摊由 ERP/财务系统承接，所以 FMS 厂商没有动力做；轮胎全生命周期被轮胎厂商的服务体系（Bridgestone FleetCare、Continental ContiConnect 服务侧）吸走，软件方只提供数据入口。

非洲本土平台则是另一个原因：它们与司机是松散承包关系而非雇佣关系，没有立场也没有抓手管司机怎么加油。如果面对的是自营或强管控车队，这恰恰是现成的空白。

Part 04

非洲运营现实（行业隐性知识）

走廊时效与成本

段落	里程	耗时
Dar es Salaam → Tunduma	~950 km	12–15 小时
Tunduma / Nakonde 过境	—	6–48 小时（月末/季末更长）
Nakonde → Ndola	~650 km	10–14 小时
合计 DSM–Lusaka	~1,850 km	纯驾驶 3–4 天；门到门建议按 7–10 个工作日规划

竞争路线成本对比（Solwezi 出发，34 吨载重）

数据来源：Brenthurst Foundation · 世界银行港口效率排名

Walvis Bay

$130/吨 · 7 天

2,300 km

Dar es Salaam

$170/吨 · 14 天

2,100 km

世界银行港口效率排名：Walvis Bay 第 328 位 · Dar es Salaam 第 361 位（共 366 个港口）

【推断】每吨 $40 的价差对应 7 天额外周转 → 在坦赞走廊上，时间就是钱的换算率极高。压缩边境与港口等待的信息化投入，回报周期很短。

燃油成本占比远高于北美

燃油占车队总运营成本的比例

ATRI 为美国 for-hire 承运人实测；非洲为推断值

美国（ATRI 2025）

20.6%

非洲（推断下限）

35%

非洲（推断上限）

50%

推断依据：① 非洲司机工资远低于美国，分母中人工项大幅缩小；② 坦/赞柴油含税零售价 USD 1.55–1.58/L ≈ USD 5.9/gal，是美国的 1.5–1.7 倍；③ 路况差、坡道多、超载常态导致 L/100km 高于北美 20%+。

→ 1% 的油耗改善 ≈ 0.4% 的总成本改善；1% 的盗油 ≈ 直接吃掉 0.4% 净利。

⚠️ 加油策略必须动态计算

坦/赞柴油当前 USD 价差仅 2%，但赞比亚单月波动达 12.5%（6 月 ZMW 32.11 → 7 月 28.11）—— 跨境加油套利方向逐月翻转，任何"固定在某一国加油"的静态策略都是错的。

现金替代是第一优先级，不是可视化

三条独立证据指向同一结论：

Korridor（13 国 360+ 服务点、2000+ 客户、35,000+ 卡车）的整个产品结构就是把燃油/路桥/边境/过磅费/停车/保险统一到一张多币种电子账。核心价值主张原文："Cashless solutions reduce the risk of physical cash being issued to drivers"
Africanews 记录的自发实践：DRC 走廊上"为避免司机携带过多现金，运营商越来越多采用通过银行预付的方式"支付沿途收费站
TradeMark Africa 与中央走廊管理局联合识别的走廊首要问题："持续依赖现金支付"

安全背景

DRC 境内有组织劫持（Tumbwe 地区，有警方、军方和安保人员配合）；车头可从警局"赎回"，代价 US$50,000；追回被劫铜料另收货值的 10%；Kasumbalesa 附近曾有士兵持枪抢劫司机随身携带的美元现金。

保险方的反应（IUMI 2024-12）：保单加入强制性保证条款 —— 要求有组织车队编队、武装押运、实时卫星追踪，并严格执行 48 小时内报案期限。

【推断】产品设计含义

安全模块要做的不是"防盗"，而是"合规取证"：追踪数据的首要用途是保住理赔资格。产品应围绕"生成保险公司认可的证据链"设计，包括封条编号、边境时间戳、车队编队记录。

海关系统必须假定会挂

2026 年 2–3 月，赞比亚 ZRA 的 PRN 生成门户故障超过两周 → Kazungula 口岸 640 辆卡车滞留，双排队列至少 17 公里，部分运输商等约 7 天
紧接着 2026-03-20 ASYCUDA 系统又出故障

"不管你走的是鲸湾港、德班、贝拉还是达累斯萨拉姆，只要你的货是去 DRC 或赞比亚的，整个网络都是瘫的。"
Transist · Mike Fitzmaurice

→ 任何依赖上游 API 实时可用的设计都会周期性瘫痪。产品需要「离线单据缓存 + 手工兜底流程 + 排队位置与 ETA 重算」。

政府强制对接的系统（需求书只字未提）

系统	国家	性质
NTANCIS / TANESW	坦桑	2025-01 生效，强制要求收货人 TIN 号，不合规将被系统拒绝
ASYCUDA World	赞比亚	ZRA 唯一税款核定平台
ECTS 电子货物追踪	坦桑	强制加装追踪设备与电子锁，覆盖散装货物（铜精矿属此类）
COMESA CVTFS / EAC RECTS	区域	COMESA 自己承认："各国系统各自为政，区域卡车司机需要安装 2-3 套不同的追踪系统"

→ 这不是"要不要做"，而是政府强制的合规接口，应列为 P0 级集成需求。

HOS：立项假设被推翻

坦桑尼亚与赞比亚都有现行有效的强制驾驶时长法规，且明确覆盖货运重卡。

国家	法源	核心规定
坦桑	Traffic Regulations 规则 36	18 小时内驾驶 ≤10 小时；7 日内 ≤48 小时；"turn of driving duty" 包含途中装货、卸货、路边等候、换胎及任何其他延误时间
赞比亚	SI 80 of 2016	一日内连续驾驶 ≤8 小时；7 日内 ≤48 小时；每驾驶 2 小时须有 ≥5 分钟休息；车主须在车内保存法定格式日志本

⚠️ 注意坦桑那条：边境排队计入法定驾驶勤务时长 —— 这与 Kasumbalesa 排队数日的现实直接冲突。

【推断】这是本项目最大的产品机会

法定义务存在（必须记录并可举证），但没有 ELD/tachograph 电子强制，也没有指定技术载体。TMS 的电子工时记录可直接充当合规凭证，无准入壁垒。反之也意味着没有法定数据格式可依循，需自定义并做成可打印为路检可接受的簿册格式。

赞比亚已把司机跨境津贴法定化（可直接作为薪酬模型）

项目	金额
卡车司机最低基本月薪	ZMW 4,000
跨境补助（无卧铺）	不低于 USD 30 / 夜
跨境补助（车有卧铺）	USD 20 / 夜
境内外宿补助（无卧铺）	ZMW 390 / 夜
风险津贴（超限载荷/危险品）本地	不低于 ZMW 1.50 / 公里
风险津贴国际	不低于 USD 0.10 / 公里
休假津贴	一个月基本工资的 30%，须在休假前支付

SI 106/2020 第 6 条还规定了法定薪资单的六个字段：司机姓名地址、职务、常规工时数、加班工时数、扣除前工资、扣除金额与实付工资 —— 这就是赞比亚司机结算单的最小字段集。

坦桑尼亚（GN 605A of 2025，2026-01-01 生效）：内陆运输服务最低 TZS 398,500/月；且法律强制要求为卡车司机支付涵盖 ① 里程、② 站外滞留、③ 装卸货三类的津贴，金额由劳资协商。

【推断】坦桑法律实际上背书了"底薪 + 里程提成 + 等候补贴 + 装卸费"这一结构。TMS 的薪酬引擎应把这三项做成独立可配置的 pay component，而非合并进一个"提成"。

⚠️ 税务结构两国相反

赞比亚：per diem 无金额门槛地免 PAYE（ZRA Practice Note 1/2025），可安全采用"低底薪 + 高过夜津贴"结构。
坦桑：必须满足 s.7(3)(d) 的"据实报销"要件才免税，且无论是否免 PAYE，SDL 3.5% 的基数都包含出差与差旅津贴。整笔包干津贴在坦桑是税务风险点。

Part 05

可直接复用的现成设计

燃油盗窃检测（Geotab/WEX 的生产阈值可直接抄）

判据	阈值	来源
油箱容量校验	加油量 > 登记容量的 110%	Geotab
位置匹配	加油点与 GPS 轨迹距离 > 1000 m	WEX
时间匹配	交易时戳与设备加油事件偏差 > 720 min	WEX
油品匹配	交易油品 ≠ 车辆登记油品	Geotab
量差校验	`(单据量 − 油位上升量) / 单据量 > 8%`	【推断】需试点校准

⚠️ 合规红线（Geotab 官方声明，必须写进产品）

"这些不匹配报表旨在识别待调查的数据异常，不能作为欺诈或不当行为的定论。这些报表关联的是车辆和油卡交易，不是个人，不应作为解雇、停职或纪律处分的主要依据。"

→ 产品必须把"异常标记"和"处罚决定"分成两个状态机，中间强制插入人工调查环节并留痕。直接用系统告警扣司机工资，在劳动纠纷中会成为不利证据。

⚠️ 反面证据（Navixy，telematics 厂商的诚实表述）

"当超过 90% 的告警是误报时，运营团队不再关注告警。真正的盗窃反而被忽视。有些车队干脆彻底关掉盗油告警。"
"没有标定，即使是顶级传感器也会产生 5% 以上的误差。"

→ 告警质量是产品生死线。多信号交叉判定（净油位降 + 静止 + 时长 + 围栏 + 倾角 + 传感器健康度）比提升传感器精度更重要，且成本低得多。

司机油耗考核（Samsara 七项指标可直接照搬）

Idling（怠速 >2 分钟，排除 PTO）/ Over speed / Cruise control / Coasting / High torque（扭矩 >90%） / Anticipation（松油门到刹车 <1 秒的次数） / Green band（经济转速区间）

关键字段：averageVehicleWeightKg 与 highGradePercentage —— Samsara 明确用"车重和地形"做归一化。本项目重载去程 vs 空载回程油耗差 30–40%，不做归一化的考核不公平。

真实车队的激励机制经验

考核周期取季度而非月度 —— 平滑天气/载重/路线波动（Bison Transport 明确说明）
目标按车型 + 载重状态分组下达，绝不能全队一个 L/100km
目标线设在"已有一部分司机能达到"的位置，否则激励失去可信度变成变相降薪
把"油耗超标"（能力/路况问题，只减奖金）和"油品失窃"（诚信问题，走纪律程序）在制度上彻底分开

OTM / SAP 的十二个可复用设计点

#	借鉴点	用途
1	ordered / booked / shipped / received 四层数量	矿运的计划量/订舱量/装货量/卸货量，差额=途损
2	Shipment Cost 挂多个归属引用 + 明确优先级	配件成本分摊至车辆/车次/项目
3	计划成本 vs 实际成本的界定	预估来自计划阶段，实际来自已开凭证的发票行 —— 避免验收扯皮
4	费用叠加顺序号 Sequence Number	自动计费引擎必须显式建模，否则金额算错
5	Accessorial vs Special Service 二分	区分"影响能不能接单"与"只影响多少钱"
6	Charge Element 绑定发生地点以分国计税	坦桑段/赞比亚段税制币种不同
7	Domain + Perspective 实现数据隔离	多租户 + 组织双层隔离
8	Means-of-Transport Combinations	"车头 + 车挂"组合建模
9	one-time location	矿区临时装货点不必建主数据
10	Seal（封条）字段	海关电子锁/铅封（坦桑法定要求，封识破损即出口许可失效）
11	ordered route vs actual route 二分	计划路线 vs 实际路线（绕路监控）
12	Rate-Level Validity Periods	坦赞油价月月变，费率必须版本化

开源项目中最好的数据模型

调研 26 个开源项目源码后的结论：star 数与建模质量严重脱钩。

项目	star	价值
suxrobGM/logistics-app	173	Load × Trip × TripStop 多对多建模最优雅；一个 Load 在一个 Trip 中产生两条 TripStop（PickUp + DropOff）；收入统计只算 DropOff 避免重复；Terminal 字段支持跨段换车 —— 最接近本项目需求
DominicFinn/open_tms	6	唯一同时具备 Order/Shipment/Stop/Lane/Load/Tender 全套概念；`OrderShipment` 多对多连接表支撑拆分/合并；`Order.deliveryStopId` 解决"合并后哪单在第几站卸"
traccar/traccar	7504	GPS 接入层，支持 200+ GPS 协议（非洲廉价中国产 GPS 刚需）。但它不是 TMS，业务语义全靠 `attributes` JSON
fleetbase/fleetops	—	Order→Payload→Waypoint 三层；适合最后一公里，无法表达跨段换车

【推断】推荐架构：Traccar 做 GPS 接入层（tc_devices/tc_positions/tc_geofences/tc_events），自研 TMS 做业务层，通过 device.uniqueid ↔ vehicle.gps_device_id 关联。

Part 06

售前局面与商务风险

局面判断：疑似命中 4 条陪标红旗

红旗信号	本项目
技术要求精确匹配某竞对产品特性	⚠️ 命中（微信小程序、SAP HANA 等高度具体的选型）
指定品牌/技术栈且无 "or equal" 条款	⚠️ 命中（微信小程序、Google Maps、MySQL、约堡节点）
无法接触真实决策人	⚠️ 疑似（目前只对接一人）
邀请介入的时间点在项目周期很晚	⚠️ 命中（已找过 3-4 家做完需求调研）

判据：单一信号不代表死局，两个以上才是强烈预警。

⚠️ 必须注意的反驳来源

资深从业者明确反对"看到红旗就不投"—— "Hardly any RFPs are actually wired"。客户已找 3-4 家说明处于多方对话阶段而非单一竞对锁定。

【推断】建议做法：提交 ① 响应需求书的合规部分（走正式流程，规避废标）+ ② 单独一份「问题诊断与差异化方案」（附加价值文档，不作为正式偏离投标）。

⛔ 替代方案可能直接废标

在采用 "Contract A" 招标法理的司法辖区（英联邦国家常见，坦桑、赞比亚均属），未获授权的替代方案会被判定为非合规反要约，直接废标。真实判例：Eastern Regional Health Authority v. Kannegiesser Canada。

→ P0：先确认客户采购流程是否允许「技术偏差说明/替代方案」，再决定能否 reframe。

定价策略

支持分阶段的证据

付费 Discovery（占总预算 5-8%，2-4 周）能把交付期成本超支从 50-150% 降到 10-20%
固定总价把"确定性"卖给客户，代价是 20-30% 风险溢价
学术研究（Jørgensen 2013）：报价低于均价 25% → 失败率 +9%

⚠️ 反驳来源

范围明确、有硬截止日期时，固定价"几乎总是更优"；且采购流程可能不接受分阶段报价。

【推断】建议：不要按 400 人天清单硬拼低价。报 "Phase 1 付费 Discovery / MVP + 验证"，用真实数据重写报价基线。若客户要求一次性总价，则在总价框架内插入"里程碑验收 + 客户依赖条款"控制风险。

合同必写的四条

#	条款	理由
1	Customer Dependencies 把 SAP/泛微 OA/GPS 厂商的配合责任划出去	SAP 对接不上是最容易扯皮的。条款示例：若因客户未按期提供 SAP 侧接口文档/测试账号/技术对接人员配合，交付期限相应顺延且不承担违约责任
2	对账准确性量化为差异率阈值	客户核心诉求就是"拉报表"和"自动对账"，这是最容易扯皮的主观项。国内判例：甲方以"界面不够美观"拒付 48 万尾款（最终甲方败诉，但供应商经历漫长诉讼）
3	7×24 运维加期限	需求书写"持续 BUG 修复、7×24 运维保障"但没说期限，典型无限期免费陷阱
4	Deemed Acceptance （10-15 工作日默示验收）	判例（Samia v. MRI）：客户未在窗口内书面提出异议，法院直接判供应商胜诉

四个最相关的失败案例

案例	教训
Hershey $100M 万圣节订单未履约	48 个月工期压缩到 30 个月，旺季前大爆炸上线 → 论证分期交付
National Grid 预算 $3.84 亿 → $9.45 亿	飓风 Sandy 期间上线 → 论证上线窗口选择
Target Canada 累计投入 $70 亿，破产	主数据错误 + 激进扩张时间表 → 论证基础数据初始化工作量不能压缩
MillerCoors v. HCL 索赔超 $1 亿	7 次更换项目经理 + 2 次更换项目总监 → 我方主动承诺团队稳定性，这是差异化优势

⚠️ 引用数据要能溯源

网络流传的 "Gartner：70% ERP 实施无法达成目标" 无法追溯到官方原始报告。建议改用有原始出处的 Standish / Panorama / McKinsey 数据，以免被客户方 IT 或财务尽调质疑可信度。

Part 07

建议的下一步动作

P0 · 启动会必须问清（答案会改变方案与报价）

SAP：版本？S/4HANA 还是 ECC on HANA？谁维护？有无中间件？Digital Access 授权谁买单？
移动端：司机实际用什么手机？智能机比例？是否接受 Android APK 而非小程序？
部署：赞比亚数据本地化怎么处理？是否接受多节点？
组织：赞比亚 SI 35/2021 下，实际运营主体是中资还是本地承运商？"自营车队"的准确定义是什么？
采购：是否允许技术偏差说明/替代方案？（决定能否 reframe 而不废标）
TATO：到底是什么组织？为什么需要专门的计费和双审批？
决策链：本项目属"总部战略级"还是"区域公司常规项目"？（决定预算审批链条与报价天花板）

P1 · 需专业尽调的三件事

赞比亚 SI 35/2021 的实际执行力度与豁免路径（法律尽调）—— 决定商业模式
坦桑/赞比亚数据合规的法律意见 —— 决定架构
SAP Digital Access 授权评估 —— 决定商务风险敞口

P2 · 建议的方案定位

不做"400 人天全包"，做"分期交付的自营车队 TMS"。

一期聚焦客户真正痛的两件事：拉得出报表 + 司机能上报数据。把 SAP 深度对接、多租户、微信小程序这三个高风险项拆到二期或重新定义。

✅ MVP 建议范围	⏸ 明确二期或不做
基础数据（车头/车挂/司机/线路/客户/费用规则）	SAP 双向实时同步
订单-车次-阶段模型（含四层数量与途损）	多租户底层隔离
GPS 接入（Traccar）+ 电子围栏	微信小程序
司机端 Android APK（离线优先：打卡、拍照、过磅单上传）	无代码审批引擎
燃油管理（加油记录 + 三条对账规则）	配件全生命周期
月度报表（单车月里程、每公里油耗、单趟成本）	轮胎 CPK 管理

附录

调研报告索引

调研总报告

全部发现的汇总与推荐动作

商业 TMS 模块图谱

产品分型、模块清单、边界划分

R1B ⭐

核心数据模型（OTM/SAP TM）

架构设计最直接的依据，全部官方文档

R1C

企业级 TMS 八家对比

自营车队/审批流/计费引擎能力矩阵

R2A

FMS 厂商模块实证

五家主流 FMS 能力矩阵，逐页抓取

R2B ⭐

燃油管理与盗油检测

含可落地数据模型与生产阈值

R2C ⭐

矿运专题

过磅/干湿吨/途损 —— 全网无成品可抄的部分

开源技术底座

13 个已下载仓库 + license 风险分级

R5A

非洲合规与中资出海

数据法、海关系统、决策链隐性知识

R6 ⭐

技术选型现实性

红黄绿灯表 + 22 条启动会必问清单

R7A

失败模式与案例库

权威统计 + 9 个有名有姓的真实案例

R7B

售前与合同条款

可直接抄用的条款措辞

已下载开源仓库（26 个，2.4 GB）

traccar · traccar-web · fleetbase · trenova · logistics-app-dotnet · ofbiz-framework · openboxes · axelor-open-suite · erpnext · jshERP · sl-express · timefold-solver · gmaps-route-optimization · ruoyi-vue-pro · JeecgBoot · warm-flow · flowable-engine · LogicFlow · liteflow · QLExpress · killbill · rxdb · WatermelonDB · JimuReport · cloud-sdk-js · node-hdb

方法论声明

本次调研全程遵循「事实与推断分离」原则。凡标注 【推断】 者为基于证据的分析判断，非来源事实。关键的方向性判断均已寻找反驳来源（如"分阶段报价更优"同时列出了"固定价更优"的论证）。多处标注了无法核实的知识缺口，未以推测填充。