前言
巧妇难为无米之炊, 如果没有前期的充分调研, 我是不可能凭空设计出来一个TMS系统的。好比我现在经常和一些客户强调的一样, 一个系统要上线, 真不是追求大而全，而是合适，而且它需要相应的人员配置，知识储备，磨合之后才可以用好！所以一个熟练的项目经理都是通过项目的调研+实施才能真正成长起来, 并且设计的功能是否真正的贴合客户管理流程也是十分的重要的。
我认为一个IT项目的成功，离不开设计者抽象能力，他好比是一个翻译，能把甲方的管理流程翻译成程序员能理解的东西，最终由程序员编写出可以用的程序。一旦偏差过大，项目的失败风险就会急剧增大，有一幅经典的需求变异图：
好了，言归正传，下面继续我的TMS设计之路。
一、我的TMS背景介绍
先介绍一下甲方的背景，它是一家标准的国内公路第三方物流公司，专门针对几家大客户做公路物流配送方案，提供的服务涵盖：配合工厂生产计划，通过公路运输到全国多地点仓库备货，并包含送货上门和安装（如空调）。甲方的客户并不止于这几家大公司，只是主要的利润来源而已。
第三方物流的经典三段区间：

我自己整理的甲方的实际工作流程图：

二、工作流程的分析与分解
根据客户的工作流程，我开始进入实际的分析工作，还是按照关键节点来说：
客户通过任意方式下单（提炼出“运单”）：电话、邮件、QQ、微信，虽然方式多样，但是其实很好理解，大客户的订单是有生产计划的，一般通过邮件发送一个excel附件过来。而一些小单就比较随机的通过QQ，微信下单过来，可能就是同行的一句话：“兄弟，帮带个货”；提货：调度文员通知司机去工厂提货，有可能需要跑几个地方，所以这里涉及到物流里面一个多点提卸货的概念。这里提货阶段有可能发生的情况：
多地点提货：去多个工厂或仓库提货；多地点卸货：货物提走后，不一定马上送去干线大货车送走，可能先送到仓库里隔一两天才走干线；这里提炼出来“提货单”。
3.干线运输：通过公路运输的方式，将商品运到全国各地。这里又会分为两种情况
送达目的仓库：商品并未销售出去，只是需要送达目的地仓库，等待商品销售出去后，再配送到客户要求的地点。送达最终目的地：商品已销售出去，直接送达客户手中。
这里提炼出来的单据是： 干线运输单。
4.配送运输：商品在中转仓中，一旦销售出去，（上游）客户发送过来配送要求，一样的可以使电话，QQ，微信，excel等等，调度文员（广州总部）通知分公司（或外部供应商）前往仓库提货送达（最终）客户。
这里提炼出来的单据是： 配送单， （到达）回单。
为什么要有回单这个东西呢？因为大客户的回款是根据每个月的回单来结算的，可不是像快递一样，寄方或收方给钱，这个是2B的特点。5.财务结算：在所有的运输工作完成后，还需要一系列的财务动作来保证以下几点：
应收、应付对账单：对上游客户收钱，对下游供应商付钱账款确认：这个是利润的提现，利润=收款-付款财务管控这块我不会过多的讲（或许以后单独再讲），现阶段还是把焦点放在物流操作的管理流程的回顾上吧。
三、本章需要指出的业务亮点：多点提卸货MilkRun
如果你是一个物流从业者，多点提卸货的操作方式一定不会陌生。我这个TMS的多点提卸货的动作发生在两个阶段:
提货送到干线货场阶段；商品销售后，配送到客户要求的地点；为什么会需要多点提卸货呢？其实这个概念来源于真实的运输操作，并且是省钱和高效的操作。因为作为第三方物流公司，他们的货车是有限的，而每天的运输订单是不一定的，你不能每一趟车都能装满（上游客户和干线公司都有时间窗口的）。
这里又有好多种情况可以描述一下：
去一个提货点满载满归，这是最好的情况，类似于去拉一个已装好货品的集装箱，司机不需操心如何装货；客户订单不满一个货厢，去工厂提货的时候，尽量安排在一次的运输路线中到多个工厂或仓库提货（多个运单的货），集中送到一个货场发干线；客户的订单有提货有送货（配送），是的你没理解错，我派一辆车出去，既去取货送到发干线，也顺便取完货就直接送到最终客户手中，因为最终客户在同一个城市；…还有不同的组合，不细说。比如说如下图的紧急加单，刚好公司的车也在附近，直接就过去了嘛，何必再重新派车呢。

最终的目的就是让司机和车提高空间和时间的利用率，从而提升工作效率，不至于浪费运力。
结语
本文针对第三方公路物流的三个区间段进行了分析和抽取了一些核心单据，并初步分析如何进行数据的录入和流转。后面着重描述了多点提卸货的操作流程，如果一个TMS管理系统连一个基本的多点提卸货都无法支持的话，是不是考虑不够周到？
本来想说不合格的，但是又觉得不合适，甲方爸爸以前只是用人工+Excel还不是一样把业务做起来了，所以技术或是所谓系统只是帮助提高效率而已，而且如果设计得不好，反而会降低工作效率，一线的员工叫苦不迭，这种情况我也是深有感触的。
一个系统的好与坏还是看是否与当时的使用场景贴合为好，不必追求大而全。小而美，快速迭代，才是当下软件开发的潮流吧。