物流运输管理系统的流程是什么？如何设计这样一款后台产品，应该从哪几个方面去设计呢？以下，笔者将为大家分享自己在设计后台产品中的一些想法。
在业务需求了解清楚后，就进入了产品设计的阶段。那么如何设计一款后台产品，应该从哪几个方面去设计呢？我们先看一下一个物流运输管理系统大致的流程是什么。
功能域划分
功能域，指的是在满足某个业务流程时，将线上的操作流程拆分成不同的功能闭环。
划分功能域是在产品设计的初期阶段比较重要的一个工作。如果在产品设计的一开始就可以划分一个比较合理的功能域，在后面产品设计的时候，就可以按照功能域进行拆分设计，不同功能域之间以接口的方式进行对接。这样一来可以减少系统的复杂性，降低设计成本。二来可以减少不同功能之间的耦合性。防止一个功能进行迭代或者优化就会牵一发而动全身。
产供销模式
功能域划分可按照经典的供应链产供销的思路进行划分；产供销在供应链中指的是生产、供应、销售；指的是某个货物的完整的供应链体系。这里供应链体系不同的是所传递的不是货物，而是数据或者某个流程的结果。这种模式比较适合操作性比较强的业务系统。
所以这里的产供销引申为：数据的生成部分，数据的处理部分，数据的最后经过系统系统流转产生的结果，也是其价值所在。
比如要设计一个大件货物的物流运输管理系统：
生产：货品/客户数据录入功能，车辆信息、司机信息的录入，城市信息/点位仓库的录入，运输计划的生成，我们可以将其划分为数据生成功能域；数据生成功能域一般来说属于最上游的功能域，所以与系统内的往复的交互不会太多，一般其他的操作流程都是从这里取数，反而与一些承载其他的业务诉求的系统有所交互，比货品/客户的数据可能是从仓储系统或者交易系统直接拿过来的数据，车辆信息、司机信息时直接从供应商系统拿过来的数据。但是理论上说，它所有的逻辑都是向上耦合而不会向下耦合的。
供应：为了达到最后的结果的流程业务功能。一般来说如果划分供应功能域的话，所划分的领域都是比较核心的领域，是主要业务流程的承载。对于物流运输系统来说，就是可以说是排线、装车流程。以及整个的任务跟踪流程，包括实时运力的报告预警，车辆调度，在途跟踪，司机在此过程中的送货、签收、回款等一系列流程。
销售：这块一般是已经完成了核心业务流程后所要拿到结果的部分，也是整套流程的价值所在。对于物流运输系统来说，可以是整个费用结算模块，根据之前的所有的流程或者内容最终的一个产出。向下流程的内容其实也属于这块的内容，比如物流任务完成后最终给财务系统，给交易系统的一个数据流转，也会放在这个功能域中。
进销存模式
还有一种思路是按照供应链的进销存的思路进行划分，这也是划分子系统的另外一个角度。
进销存指的是采购、入库、销售这样的一个过程。这种模式比较适合逻辑复杂，中台系统，或者中间业务流转系统。与产供销模式不同的是，一个偏向于产出，通过某个方式生成数据，完成业务流程。一个偏向流转，以自己本身的业务流程属性进行承上启下或者承接核心业务流程。
比如订单交易系统，可以采用进销存的模式。
第一：订单数据的产生来源是用户下单，所以产生订单的过程可以作为采购的流程；
第二：订单数据产生后，整体的处理过程，比如订单状态根据不同操作的流转、订单的算价等；
第三：订单处理完成后，对各个下游系统的分发，可以作为销售环节；比如订单在客服系统、CRM等系统中的下游逻辑处理；
这些是我在平时工作中的一些总结，肯定还有许多业务流程没有办法按照这个思路去划分功能域，总之可以按照一个思路：功能域之外尽量形成闭环，通过尽量少的接口就可以满足不同功能域之间的数据流转，协作完成各个功能域之间的工作就可以。
主线产品设计
在划分功能域后，我们可以按照不同的功能域进行产品的设计，每一个功能域中都可以拆分为主线产品及非主线产品。
例如在物流运输管理系统中，我们已经按照产供销的模式将系统拆分了不同的子功能域，第二个子功能域是业务流程的处理，数据的处理部分，那么针对这个环节中，其整个核心的流程就是从物流运输管理系统中排线，装车，在途运输，签收回款这样一条业务流程的核心链路。
那么，应该如何去判断这条链路是核心链路呢？
可以秉承这一一句话：这条链路跑通后，可这个子功能域的基本业务流程可以跑通，没有比较大的功能缺陷；
有时候，我们无法确认哪些是核心链路。接过来一堆的业务诉求，梳理了一个庞大而繁琐的产品流程；
在这条流程里面，我们可以进行梳理和拆解，这个过程中，我们可以遵循以下几个原则将核心链路梳理出来。
第一：业务闭环是什么
这个子功能域中，最开始的节点，和最后的节点分别是哪些；比如物流运输管理系统中，第二个子功能域的第一个环节是排线，最后一个环节是签收回款，或者司机返仓（有返仓环节的流程），那么可以确认的是，这两个环节一定是主链路之内的；
接着，通过这个链路往后推，往前推，直至将整条链路闭环。比如排线后接下来的环节是通知司机，则这个环节也是主链路之内的；司机接单后进行装车，这样是从前往后推，直至最后的环节；
另外，为了保证最终的结果正确，我们可以从后往前再推一遍，比如最后的节点是司机返仓，那前一个环节是司机接收到了货款，再前一个环节是司机到达客户现场进行送货；
第二：如果没有XX功能，该怎么办
对于某个功能我们实在难以取舍的时候，我们可以考虑一下，如果上线的时候没有这个功能，我们可以怎么做？比如如果没有内置导航的功能，司机可以通过高德、百度地图的APP直接导航使用；如果没有装车后拍照留存功能，可以拉一个微信群，在微信群里面上传照片；如果没有排线功能，那业务数据将无法流转，无法给司机下发任务；所以哪些功能是主线功能，哪些是非主线功能，就显而易见了。
那么，为什么我们需要梳理出一个主线产品呢？
第一，后台产品是复杂而庞大的，我们无法一口吃成一个胖子，就需要将功能拆解开来做，所以这个时候就必须梳理出一个主线产品；
第二，在产品线上跑起来之前，所有的设计都是空中阁楼，没有经过实际的验证，如果这个时候我们将产品设计的特别复杂，一旦其中某个环节出现了问题，就会出现船大难调头的尴尬局面；
第三：好多的功能，是业务没想清楚，我们也没想清楚的，只有产品真正用起来之后，才能之后这个产品需要什么，所以在产品最开始的阶段，当务之急是让产品先运作起来，然后再根据实际的情况决定后续的产品怎么去做；
非主线产品设计
非主线产品功能，即指的在某个功能域之内主线产品之外的功能，这些功能不会影响到主链路，但是如果加上这些功能可以让产品更加完善，更符合业务诉求。
比如我们在确定了物流运输管理系统中如果没有装车后的拍照留存功能，可以让司机通过微信群上传照片的方式进行操作；但是在主线功能上线之后，针对于每一笔订单都会用到的这个操作，这样的操作无疑就相当的繁琐了。所以此时刻的功能线上化就十分有必要了。
在已经将主线产品设计出后，非主线产品相对来说就会比较好设计一些。设计非主线产品时，可以参考以下几个设计原则：
1. 主线产品每个环节的补充
在我们将主线功能中的排线环节设计完成后，排线所要涉及的其他点，比如运单生成后的打印，排线时需要先核对订单各个SKU的数量以及仓储数量，这些流程是依托于主线流程，或者主线流程的扩充的，完善主线功能的某个流程的。
2. 可以形成一个业务小闭环
某些功能可能根本就和主线流程关系不大， 但的确也属于整个业务流程之内的，比如在许多的物流运输管理系统中会将与司机签订合同的功能与放到里面；这个流程可以说是完全在系统中开辟了一个新的独立的业务小闭环，我们在设计的时候，要注意做到最小可用即可，精力更多的还是需要放在主线流程及对应的非主线流程上。
数据功能设计
数据产品的设计中包括报表设计，数据仪表盘等产品设计。
这个功能可以说是后台产品的必备功能之一。在设计报表功能时，需要注意的设计内容有：
一、自上而下的设计，即这个功能是以管理诉求出发，基于不同的管理者希望看到什么样的数据来确定报表设计的内容。所以一般需求的来源大部分可能是管理者，较少部分的情况下才为操作者，比如CRM系统中某个人需要看自己今天拜访了多少客户。
二、不同行业的报表标准都有哪些，在不同的行业中可能会有一些固定衡量的指标来确定某一次业务流程的结果如何，比如在物流运输管理系统中的提货准时率 / 到货准时率 / 货损货差率 /回单返回率 / 车辆装载率 等等这些比较标准的数据做成线上报表。
三、在设计报表的时候，需要在一开始的时候就注意取数字段的设计，有时候在产品功能中可能不需要在数据库中新增一个字段来存储，但是为了后面报表取数比较容易，最好还是可以在数据库中冗余一个字段。这样在后期跑数据的时候一是可以减少开发的工作量，二来可以减少跑数的时间。
四、设计报表的时候，最好是带入到不同的使用场景中去设计，不能为了设计报表而设计。所生成的数据一定要有意义，确切的用到某个地方才去取这个数据。
非功能性设计
非功能性产品主要包括两个部分：
1. 满足降本增效的目的，在现有功能产品之上确定的一些产品策略
这些策略是为了让系统更加的坚实可用。这个我认为也是之所以我们要将某些业务流程线上化的原因，因为这些功能的存在，我们可以让原来繁琐的业务流程变得更加精简高效；
比如在我们将tms的业务功能产品已经做得足够完善时，需要考虑的就是这个系统可以如何更好的服务于业务，让业务的操作可以更精简，效率可以更高；这个时候我们就需要考虑一些人做不到的时候，比如排线策略，根据以往的排线数据，可以推算出某个订单的最优线路，在给某个司机进行派单时自动将最佳的订单进行聚合生成运单。在司机装车时，根据货物的摆放原则（密度大的放在下方，易损的放在上方），先到后装（优先派送的放在最后装车），不超载等原则自动匹配配载的策略；
这些功能可能都是人为操作难以实现或者需要一个很复杂的计算的，但是这些我们通过产品本身不断优化的策略，可以让产品变得更加完善和健壮。
2. 非功能性产品包括在业务流程之外的一些产品能力
比如一些管控诉求，关键节点需要某些职位的领导进行审批；如果是从0 到1在建设完成的系统时需要设计的权限系统，账户系统；等等这些内容，需要满足整体的产品闭环流程不可缺少的环节。
接口设计
对内的接口
在上文中所述，设计产品的一开始需要划分子功能域，那么不同的功能域之间的能力即通过接口进行连接。之所以通过接口进行对接，可以保证不同子功能域之间的耦合程度比较低，在进行功能迭代时，如果只涉及到某个功能域的改动，不需要整个链路都改造，只改造自己本身内部即可，只要对其他功能域所输出的接口没有变动，则对其他功能域无感知。
在设计对内的接口时，无需考虑到的点有如下：
1. 接口的调用频率，调用次数。因为作为一个统一的系统，所有系统的技术能力都是统一的，完备的，这些信息更多的应该是技术去考虑的。
2. 同一个系统中，不同子功能域的主数据是一致的。基于此，我们在设计接口的时候，就不需要考虑接口中过多的参数，如果一旦涉及到某个数据，只需要将表中的主键作为参数进行传递即可。比如在物流运输管理系统中，供应子功能域需要生产子功能域提供被禁用的司机名单，以便勾选司机的时候将其置灰。那供应子功能域只需要将司机ID给到，由供应子功能域直接去主数据中查询即可。
对外的接口
对外的接口，既包括对功能内部的不同系统的业务能力支持接口，也包括可能对外涉及的OpenAPI。相对于对内的接口，由于这些接口是对外露出的，其他业务系统的能力不受本系统的控制。所以在设计的过程中会比对内的接口复杂一些，设计时也需要更加的谨慎；
在设计对外接口的时候，需要考虑的点有以下：
1. 是主动调用接口还是推送接口。主动调用接口指的是调用方因为自己的需求调用我方系统的接口，然后我方进行一定的逻辑处理后返回给调用方。这种情况多见于调用方发起业务操作，比如TMS在于WMS进行交互时，如果TMS想要获取WMS中的货品数据，则需要主动请求WMS，将一定的参数（一般包括必要的条件，比如哪个城市、哪个订单，多少货）等传给WMS，然后WMS返回给对应的数据。
如果是推送接口，即我方系统因为数据变化或其他原因，主动推送给调用方的方式。比如WMS中某个货品因为不合格下架了，但是之前的数据已经推送给TMS了，这个时候就需要WMS主动推送给TMS。
2. 同步接口还是异步接口。同步接口指的是进行数据传递时，接收方将结果实时返回给调用方，接口一直保持通信。同步接口的好处为：信息处理比较及时，各个系统之间的操作会比较平滑。缺点为一旦数据量大的时候，接口容易超时，导致数据传输失败。这种情况下，整个系统的操作相当于都被中断 。
异步接口指的是，我接收到调用方传过来的数据后，先进行逻辑处理，处理成功后将结果再返回给调用方，这种方式的好处和同步接口相比针对大量数据的处理有了明显的提升。但是有一点，因为调用方接收接口不及时，如果逻辑处理不好，很容易出现下游系统数据继续进行，但是上游后面返回一个失败的结果，这样就会导致整个系统的逻辑错乱。
3. 接口的调用频次和量级。一个系统所能承受的压力是有限的，在设计接口的时候，也一定要考虑到系统接口所能承受的压力是多少。这一点其实技术考虑的可能更多一些，但是对于产品来说，可能不同的压力承受值会对产品方案有所影响，比如某个HRM系统中，员工同步的借口一次最多允许传10000个员工，则我们需要考虑正常的操作链路中比如Excel导入是否也需要将操作限制于10000。
兜底逻辑、熔断机制
系统在运行的过程中，难免会因为并发量过大，系统bug产生一些问题，这些问题轻则影响业务的正常进行，重则直接宕机，丢失数据等严重的情况。所以在设计产品的时候，要考虑到如果一旦系统产生问题，怎么样可以使产生的灾难降到最低；
兜底逻辑指的是因为某些不可预见性的问题，比如系统bug，产品逻辑没有考虑到等因素，发生了异常情况或者数据的情况下，系统应当进行的操作。设计一个产品的兜底逻辑需要对这个业务十分熟悉，并且有着自己比较精准的业务判断，否则会导致一种十分可怕的情况是兜底错误，造成了比原本更可怕的错误。
比如在物流运输管理系统中，因为司机早上需要发货，需要将所有的排线任务在晚上十二点之前全部完成，否则就会影响后续的流程。正常情况下，规定排线人员必须在12点前完成，一旦因为排线员工自身原因，或者网络异常，系统bug等无法完成排线任务，兜底逻辑会使系统则会按照历史排线规则自动分发任务。
熔断机制指的是如果某个操作系统判定为异常业务流程了，那么立刻会进行系统流程的切断，以免发生悲剧。比如说某一套物流运输系统，通过测算给某司机发放运输任务工资时，由于系统问题或者操作失误问题，本来运送5次应该发放1000元，实际发放了10000元。这个时候，系统就应该设置一套熔断机制，设置某个操作的阈值。比如1单配送最高金额为300元，则司机运送5次最多发放1500元，该套熔断机制检测到金额超过阈值，则直接将流程切断，并且将异常抛给系统管理员。
在设计一套复杂的后台产品时，需要考虑的点可以说是方方面面。上面是我关于在设计后台产品中设计产品方面的一些想法，接下来会介绍一下后台产品的交互应该如何设计。
相关阅读：
从0到1设计后台产品（一）：给后台产品分个类
从0到1设计后台产品（二）：如何定义业务需求？
