企业官网建设流程全解析

简介：这份TMS系统产品需求文档（PRD）聚焦京东仓储物流运输场景，面向产品经理、系统设计人员与物流信息化从业者，清晰定义了干线运输二期各功能模块与业务流程。文档从系统登录、修改密码、系统设置出发，覆盖运输网络管理、发运管理、在途监控、到货管理、延迟审核、运费核算、查询统计及托运信息变更等核心环节，并对整车、零担、重泡货计费逻辑作出详细说明；同时包含权限分配、角色定义、界面控制等内容，可作为同类物流系统设计的参考蓝图。资源包为单个docx文件，大小2.16MB，内含系统概述、总体流程图、功能模块列表及版本修订历史，便于快速查阅与二次编辑。目前已有377人学习，适合需要梳理TMS产品需求、规划物流运输功能或撰写PRD的读者参考。

1. 拿到一个「TMS系统产品需求文档（PRD）.docx」，先别急着打开写

TMS系统产品需求文档（PRD）.docx，这个文件名看起来平平无奇，但它几乎是运输管理系统能不能按期交付的分水岭。TMS要管的运输订单、运单流转、车辆调度、司机回单和运费结算，每一条都是强流程业务，逻辑互相咬着，靠口头对齐几乎必出问题。PRD要干的事，就是把业务方嘴里的“回单”“派车”“异常”翻译成开发能直接编码、测试能写用例的精确描述。这份docx的读者不只是产品经理自己，还有后端、前端、测试、客户方的运营负责人。适合正在接手运输系统的新产品经理、要给物流企业交付方案的乙方顾问，以及准备用需求文档重构老系统的研发负责人。

2. 写TMS的PRD之前：先锁业务模型和单据核心字段

大部分PRD翻车不是在写作阶段，而是在业务建模阶段。菜单名称写不齐可以后补，业务模型定错了，文档越详细越难改。我拿到一个TMS项目后，不会急着打开Word，而是先花一两天把业务模型按边界、单据流、字段口径三件事理清楚，再动笔。

2.1 先定边界：你的TMS管到哪一层

同一个“TMS”三个字母，在不同公司里的含义完全不同。有的公司只把它做成运输订单录入和报表平台，有的公司把它做成连接司机、管在途和回单的运营平台，还有公司想直接在这里面做运费计费和司机结算。边界不清，PRD篇幅会失控，评审会也会失控。

我一般用三个问题来切边界：订单从哪来，是手录还是从ERP/OMS同步；调度在系统里做还是线下做；运费结算管到应收应付还是管到每一票的成本分摊。这三个问题直接决定PRD里要不要写接口章节、要不要写调度算法、要不要写计价引擎。

边界定下来之后，要落到PRD的第一页正文里，写一段“本版本范围”，明确列出本次做什么、不做什么。范围外的东西，哪怕业务方反复提，也只能登记在修订记录的“暂不纳入”一栏，不写进功能正文。这个习惯能挡掉一半以上的需求蔓延。

2.2 单据流：订单、运单、回单、结算单的状态怎么转

TMS的核心单据流是一条主线：订单进来，拆装成运单，运单生成派车任务，司机执行后在途，到达后上传回单，最后根据回单和计价规则生成结算单。PRD里要有一张状态流转表，把每个单据的主状态和允许的跳转写清楚。

常见的翻车点是订单和运单的关系。一个订单可能拆成多张运单，多张订单也可能合并成一车运输。这些关系必须在PRD里写成明确规则，例如“订单拆单后原订单状态置为已拆，不允许再改收货地址；合并运输时生成新的运单号，原始运单号关联保存”。开发拿到这种描述，才知道建几张表、怎么设计状态。

状态机不需要用复杂工具画，直接在docx里用表格写“当前状态 → 触发动作 → 结果状态”就可以。例如“待调度 → 手动派车 → 已派车”“已派车 → 司机拒单 → 回到待调度”“在途 → 上报异常 → 异常处理中”。表格比流程图好在不会因为字体丢失而乱版，而且评审时能逐条过。

2.3 字段口径与计价规则：评审会上最容易被围攻的两页

字段口径是另一个重灾区。业务方说“发货城市”，可能指的是行政区划的市，也可能指的是“发货地文本里提取的城市”；开发按文本字段做了，月底统计报表对不上，最后互相甩锅。PRD里必须有一张核心字段表，至少包含字段名、类型、长度、默认值、校验规则。

计价规则是TMS里最敏感的部分。常见计价方式有按趟、按重量、按公里、按件数，一条运单可能同时命中多套规则。PRD里要明确写“多套规则同时命中时的优先级”，否则司机和财务对账时，每个人算出来的运费都不一样。我在写线上运费支付时，会明确要求团队参考支付网关设计文档PRD的粒度，把支付请求、回调、成功、失败、退款五个状态全部定义清楚，涉及金额的字段不写“以实际为准”，必须写“以系统试算结果为准，误差超过0.01元时生成差异单”。

异常流也要单独列。取消订单、司机拒单、运单转派、回单上传失败，这四类在运输业务里高频出现。每类异常写一条“用户操作 → 系统响应 → 状态变化”，开发就不会自由发挥。

3. 用docx把PRD落成一版能评审的文档：结构与必写小节

业务模型理完之后，才轮到docx排版。很多产品的PRD是想到哪写到哪，章节顺序随缘。TMS这类系统评审人数多、涉及的模块杂，章节结构必须稳定。我的习惯是固定一套模板，拿到新项目直接套。

3.1 首页、修订记录与角色权限矩阵

docx的第一页不能只有标题。要有项目名称、版本号、修订日期、修订人、评审状态五项。之后紧跟着修订记录表，评审时谁提了多少条意见、改到哪个版本，全部留痕。

角色权限矩阵放在修订记录之后。TMS常见角色有货主、调度员、司机、客服、财务、系统管理员。权限矩阵至少写到菜单级和按钮级，例如“调度员可以分配运单，但不能修改运费单价”“财务只能查看已结算运单，不能操作司机端数据”。权限矩阵不写清楚，开发做登录鉴权时一定会返工。

3.2 功能需求不写“支持派车”，要写“当XX时，系统XX”

功能需求章节最大的问题是写法。很多PRD里写“系统支持车辆调度”“系统支持运费试算”，开发看了不知道怎么实现。规范写法是把每一条需求都写成可验收的功能条目：前置条件、触发动作、主流程、分支流程、异常流程、验收点。

每个功能条目都要求能写出验收点，测试用例才能跟着写。运价确认这个动作，如果涉及线上支付，要额外描述支付入口、回调处理和退款路径，这里直接复用支付网关设计文档PRD的状态划分方式，能省掉不少口头解释。

3.3 TMS与外部系统的接口和结算对账怎么描述

TMS很少是孤立系统，上游接ERP或OMS拿订单，下游接财务系统传结算数据，可能还要接电子回单平台。接口章节不能只写“同步订单”，要写清楚接口方向、触发时机、频率、字段映射、失败处理。

我一般会用一张接口表：接口名称、调用方向、触发方式、数据量级、失败重试策略、超时阈值。例如“订单同步接口，ERP调用TMS，运单创建后实时推送，单次不超过100条，失败进入本地消息表，每5分钟重试一次，重试3次后生成人工处理任务”。这段描述能让开发直接定技术方案，不用再回来问。

结算对账要单独写一节。TMS的运费结算涉及应收、应付、实收三方，差异处理必须提前约定。PRD里写清“结算单以系统计价为准，手工调整必须填写原因并留痕”，能避免财务后期乱改数据。

3.4 docx里的图、批注与版本管理

docx里放流程图有讲究。评审可能是用WPS打开的，Visio图经常出现字体偏移、线条错位。我的原则是：核心流程用状态表表达，只有多角色协同流程才配图，比如“订单转运单”的时序。图形插入后，在下方附一段文字说明，保证任何环境打开都不丢信息。

评审期间的版本管理也容易踩坑。文档要在修订模式下流转，评审意见用批注写。定稿前关闭修订模式，另存为一个新版本，文件名带上版本号和日期，例如“TMS系统产品需求文档（PRD）_v1.2_20250122.docx”。不要在原文件上直接改，不然评审阶段的意见全被覆盖。

4. TMS PRD推进中的常见问题与排查：评审、排期和docx交付

PRD写完不代表结束，真正的难点在推进。评审会失控、文档在共享盘上搜不到、排期和实际工作量对不上，这三类问题几乎每个TMS项目都会遇到。

4.1 评审会跑偏：业务和研发各说各话

现象：评审会上围绕“这个订单要不要做取消申请”来回拉扯，一张页面卡半小时，会议结尾没有任何结论。

原因：PRD里没有状态机，或者说状态机只有主状态，没有取消、拒收、改派这些分支。业务说的“取消”和开发理解的“取消”根本不是同一个状态，自然没法对齐。

解决：评审前先把2.2的状态流转表补完整。评审时只聊状态表里存在的状态，凡是没出现在表里的动作，一律标记为“本次不纳入”。如果业务方坚持要加，现场把状态变化写出来，当场确认加不加得进当前版本。这个流程看着强硬，但能保住评审会的产出。

4.2 Windows搜索docx正文搜不到，共享盘上找不到自己的文档

现象：把“TMS系统产品需求文档（PRD）.docx”放到共享盘后，想用正文里的“手动派车”“运费试算”这些关键词搜文档，结果什么都搜不到，只能靠文件名回忆。

原因：Windows对docx的正文检索依赖内容索引服务，很多公司电脑默认关闭了索引，或者共享盘没有被加入索引范围。Word里能搜到，但Windows全局搜索搜不到正文，这是正常的，不是文件丢了。

解决：第一步，文件命名规则带上模块和版本，保证按文件名能定位，例如“TMS_PRD_调度模块_v1.2.docx”；第二步，在控制面板的“索引选项”里把共享盘目录加入索引范围，触发一次重建；第三步，如果想要更快，只按文件名搜索可以用Everything这类本地搜索工具，全文检索再用系统自带的索引。给客户交付时，我习惯同时导出一份PDF放在docx同目录，避免对方环境不支持docx正文搜索时打不开。

4.3 排期与PRD范围对不上，开发估三周做出来少四个功能

现象：开发评审时说三周能上线，结果做到第二周问“回单照片要不要做压缩”，第三周问“结算单导出要不要包含司机维度”，做完发现和业务预期差了一截。

原因：PRD正文虽然写了功能，但没有一个强约束的范围清单，开发默认按主流程估，忽略了异常分支和外围功能。

解决：在PRD里加一页“本版本范围清单”，用表格列出模块、功能点、优先级、纳入与否，评审时逐行口头确认。排期也按这张表来估，不在表里的功能一概不算进本次迭代。加了这页之后，开发评估基本不会再“漏”，返工次数明显减少。

5. 交付前先过自检清单，再顺手清理docx本身

内容定稿后，别急着发出去。我把docx当成工程文件处理，交付前必须过一遍自检表。

5.1 一个顺手清理docx的小习惯

打开Word的导航窗格，检查是不是所有章节都用“标题1”“标题2”样式，而不是手工加粗。样式统一，自动目录才能正常跳转，评审时按Ctrl+点击目录就能定位到具体功能，体验完全不同。另外，关掉修订模式前，先“接受所有修订”，再另存为新版本，避免交付件里残留修订痕迹。

我现在的习惯是每次评审会前只做两件事：把“本版本范围清单”那页截到第一屏，再用Ctrl+F搜一遍“默认值”。多花十分钟，往往能省下一轮评审。希望帮到你。

本文还有配套的精品资源，点击获取