主流程
- 01需求提报客户
- 02需求确认 · 运费核算中心业务员
- 03安排箱号 · 箱位货运场站
- 04分派司机车队调度员
- 05提空箱 · 装货封箱司机
- 06铁路干线在途95306 轨迹
- 07到端短驳 · 签收司机 · 企业客户
- 08财务确认 · 账单财务
每个节点都是一次状态写入，也是三端分工的边界。
铁路货运 · 内控型 TMS
全程通 铁路物流总包平台
把跨 6 类角色、5 段流程的物流总包业务，从微信群搬进同一套系统里。 一次结构化录入，替代多轮往返确认。
- 客户方
- 广州铁路物流中心
- 我的角色
- 产品设计负责人 · 产品与设计 1 人承担
- 项目周期
- 2024.04 – 2024.12 · 8 个月全职
- 团队
- 7 人 · 设计 1 / 前端 2 / 后端 3 / 测试 1
- 覆盖终端
- Web 管理后台 · 微信小程序 · 移动端 App
- 核心交付
- 139 张高保真视觉稿 · 17 份标注稿 · 251 个原型文件
BASE · 广州 GUANGZHOU
铁路集装箱多式联运 · 95306 轨迹接入
难点从来不在功能
改造前，这套业务跑在微信群、电话和纸质单据上。拆开流程图的节点密度与返工回路，问题只有三个。
业务已经在物理世界完成了，系统还停在流程中段。 改造前的典型失效场景
-
事实源
每传递一次，就多一道人工纠错闸门
一票门到门业务要跨客户、中心业务员、货运场站、车队调度、司机五个主体。每一跳都靠微信或电话口头传递，缺统一事实源，系统就无法自动校验——只能把复核成本转嫁给人力，为每个传递环节配一道人工闸门，而每道闸门都可能变成一次跨角色往返。
-
黑盒
货到哪了，只有问人才知道
状态数据客观存在于铁路 95306，但对客户不可用：签约客户已有自助查询权限，实际使用率极低，仍然直接微信问业务员、由业务员代查后答复。货物进入铁路干线到到端短驳启动之间，是一段显著的信息真空。
-
离线
线下已经做完，线上还卡在中段
司机的箱号照片与签收单要 U 盘拷到场站电脑、由专人集中上传，状态回传严重滞后于实际作业。一旦未及时回传，流程就停滞在「司机确认」，后续的场站作业、结算与统计全部阻塞。
三段链路，一套订单模型
发端短驳 · 铁路站到站 · 到端短驳 —— 三段自由组合，派生出四种产品形态。
三端分工
- Web 管理后台全量管理、配置与数据洞察中心业务员 · 管理层 · 财务
- 微信小程序现场轻作业与即时上传司机 · 场站人员 · 调度员
- 移动端 App轻量查询与消息响应企业客户
服务角色
企业客户中心业务员车队调度员 司机货运场站人员财务
权限不是一张静态表：同一角色在不同订单状态下拿到不同操作集。管理员兜底推进节点时，必须同时记录操作人、原因与时间。
三段可配置的服务组合
| 产品形态 | 发端短驳 | 铁路站到站 | 到端短驳 |
|---|---|---|---|
| 门到门 | 平台 | 平台 | 平台 |
| 门到站 | 平台 | 平台 | 客户自理 |
| 站到站 | 客户自理 | 平台 | 客户自理 |
| 站到门 | 客户自理 | 平台 | 平台 |
一套订单模型与流程引擎覆盖四种形态，避免四套独立流程的重复建设与维护成本。
六个设计决定
每一个都在把「事后审核」前移成「前置约束」。
以「订单」为唯一事实源
把散落在微信群、95306 与纸质签收单里的信息，收敛成一个「物流需求订单」对象，并在订单内部建四段式结构化分区。一次结构化录入，替代原本多轮次的微信往返确认。
装货客户 · 收货客户 · 铁路运输 · 短途运输
三段可配置的服务组合模型
把总包业务抽象成三个可独立配置的服务段，用服务段的自由组合派生出四种产品形态。这是组件复用思想在业务建模层面的落地，也是整套系统的架构基础。
发端短驳 · 铁路站到站 · 到端短驳
角色驱动的权限边界
建立「角色 × 订单状态」二维权限矩阵，明确各角色在特定状态下可执行的操作，用三项关键边界替代事后纠错，从源头减少返工单量。
撤销 · 改派 · 锁定
现场端的一屏一事
针对司机与场站人员的操作能力约束，把长表单拆成与作业节点一一对应的独立页面，单页只承载一个动作与必要的拍照上传，显著降低认知负荷与误操作率。
接单 · 提空箱 · 装货封箱 · 卸箱 · 签收
把轨迹查询嵌进订单详情
不独立成页。客户查看订单时自然获得履约状态，无需额外学习或跳转——这是为了规避 95306 自助查询「有入口、无使用」的覆辙。
履约可视化 · 零学习成本
询价与竞价的交易闭环
业务员发起 → 车队出价 → 选定承运，并引入财务角色完成账号打款、账单记录与款项确认，让平台具备完整的资金流可追溯能力。
询价 · 竞价 · 财务确认
上线以后
2024.04 项目启动，2024.12 二期交付。以下是这 8 个月的运行结果。
月均约 127 单，日均 4~5 单
平均订单单价约 3,600 元
降幅约 90%（改造前「在途查货」占 3~4 次）
降幅约 90%（原本常跨半日至隔日）
四种形态均产生了实际订单，验证三段可配置模型并非设计臆想
Web 88 · 小程序 44 · 移动端 App 7
覆盖 5 段流程的全部作业节点
「以前客户一天问八遍货到哪了，现在让他自己看订单就行。」 广州铁路物流中心 · 中心业务员
口径：沟通次数与处理时长为业务访谈估算值，按需求、运费确认、派车、备箱、在途查货、到端签收六环节拆分累加，非系统日志统计。
139 张稿，三端各司其职
现场端的第一约束不是信息密度，是用户愿不愿意用。
做对了什么，还欠什么
把遗留问题写进来，比只写成果更接近真实的交付状态。
做对了
- 先锁定「下单」这一刚性入口，再承接「轨迹查询」这一柔性需求。顺序反了，功能再完善也无流量。
- 采纳问题先找动力：把派单权收口至系统，比交互优化与培训投入都更有效。
- 架构抽象前置：在服务建模阶段就完成三段式抽象，避免四套形态的重复建设。
- 为过渡期留通道：场站端保留「审核照片」页，让线下代传行为进入系统留痕，而不是游离于流程之外。
还欠着
- 管理员兜底存在阶段性依赖，需机制化收敛：为兜底操作增加留痕与频次统计，把高频兜底节点识别为优先优化项。
- 司机端录入质量依赖熟练度爬坡，而非机制约束：随车队扩张，新司机的爬坡成本会周期性重现，需把新手引导机制化。
- 95306 为非官方数据接口，其稳定性与合规性构成单点风险，应预设降级方案并在界面明示数据时效。