数据状态的变化以及完结节点的确定

　　状态的变化和完结节点的存在作用是什么？确定这一节点可以从什么要素进行思考呢？
　　首先感谢大家，第一次发文《6个月的B端产品新人掉坑日记》就有8000阅读量，对于一个小菜鸟来说实在是有极大的鼓励，为了回报大家，我决定发奋图强，写更多的文，遇更大的坑
　　不过对于产品来说，所谓见过鬼才会怕黑，只有自己努力去思考过，掉坑过，才能提升。看别人掉坑其实帮助不大。因此在新的一年里，我祝大家掉坑好，好掉坑，掉好坑
　　这次和大家分析数据状态的变化以及完结节点的确定。
　　B端业务复杂，使用系统的工作人员众多，角色分工也多。
　　如果要确定一条数据的状态变化节点，则要从角色关心数据的什么，关心到哪入手。举个大家不太熟悉的例子，就电商公司部门而言，有：供应链、物流、财务、仓储、销售五个角色（客服、推广、运营等暂省略）。
　　一件货物从供应商处购买到售卖给买家前，进货的流程应该有：产品开发、采购、供应商发货、抵达仓库、仓库储存（产生库存）、买家下单付款、发货、物流运输、买家收货。那么五个角色要管理到的点应该是：
　　供应链：产品开发、采购、供应商发货、抵达仓库；
　　物流：发货、物流运输、卖家收货；
　　仓储：抵达仓库、仓库储存、发货、物流运输；
　　销售：仓库储存、买家下单付款、发货、物流运输、买家收货；
　　财务：产品开发、采购、供应商发货、抵达仓库、仓库储存、买家下单付款、发货、物流运输、买家收货（有同学可能会问到、产品开发和供应商发货和苦逼的财务有什么关系：产品开发需要买样品，供应商发货途中可能有货损涉及成本金钱问题）
　　假设：一堆货物（产品种类和数量确定）在上架前用一个流转单号来记录它在仓库的流转状态，那么以供应链的视角来看，这个流转单号（这批货物）的状态应该有：已生成单号（初始状态）、待（已）签收、待（已）测试、待（已）入库。
　　若货物抵达仓库时间与约定时间不符，则超期成本由供应链部门承担；
　　若在签收后发生货损、丢失等问题，则责任归于供应链部门；
　　若测试出现测试失败的货物，则需要供应链部门去和供应商协商，协商失败，则损失成本由供应链部门承担；
　　而入库之后，在仓储储存期间发生的货损、丢失、发货等，供应链部门则不管，因此该流转单号的完结状态应为已入库。
　　有个真实的情况是，到了旺季货物较多，供应链部门为了按时完成货物入库的操作，会先把快要超期的货物直接标记为已测试已入库，然后再撤销入库（多么聪明、多么为别人着想）。可是这个功能却被去掉了。因为财务部门盯着，在追踪到具体责任时，仓储部门无故承担了一大批没看到却已入库的货物责任。
　　再举个大家熟悉的栗子，网购商品的订单状态，完整的应该是：买家提交订单、买家付款、卖家订单确认、包裹等待物流公司揽件、物流公司已揽件、包裹在途中、包裹等待签收、买家已签收、买家提交评价（不考虑退单等特殊情况）。
　　购买者属于交易中的买家角色，不会关心卖家的发货情况，因此后台系统只需要在特定节点返回状态变更的信息到前端网站即可。根据买家想要看到的信息，这里可以分成两种状态变化：
　　订单：提交订单、付款、卖家发货、签收（完成）
　　其中，卖家发货就包涵了卖家订单确认、包裹等待揽件、物流公司已揽件、包裹在途、包裹待签收五个状态，但由于这里是订单维度的状态变化，因此具体的包裹交接状态就不必在这里展示。如果买家想要看到具体的包裹物流信息，则可以去看订单物流信息：
　　物流：卖家已发货、物流公司已揽件、包裹在途中、包裹等待签收、已签收（完成）
　　其中包裹在途中，还可以细化到包裹在哪出库了，中转到哪，最后到达物流的哪个节点，由哪位员工负责派送，再附上员工的身份信息和联系方式，提高快递的存在感，也让买家更放心。
　　顺便一提，按理说订单的完结，应该是以订单被签收的作为节点（已签收）。
　　不过某宝的订单状态变化是：下单、付款、发货、收货、评价
　　把评价作为订单的完结点，能对买家去评价起促进作用（差一步不去点太难受了），从中能看出某宝是希望买家去评价，给店铺和其他潜在的买家给予反馈信息的。
　　总结：
　　状态的变化和完结节点的存在是为了完成任务的交接，让管理者可以追踪定责到具体环节。因此节点的设定要结合实际的业务流程。还有就是有关联到系统数据变化的操作才能作为节点触发状态的变更哦。