今天在跟技术同学对焦库龄异常数据的监控，梳理了几个监控逻辑，大致如下：
一、基于库龄对账流水中仅WMS有的单据进行排查 1、先排查是否上下游同步延迟导致 2、再跟WHC对比是否部分入库 3、再跟WHC对比是否WHC状态异常（非100） 4、如果WHC为100，则属于OIH状态异常。 二、基于库龄对账流水中仅OIH有的单据进行排查 1、先排查该单据是否存在历史对账中仅WMS有的单据中，如果存在，则无需人工处理 2、如果不存在，则属于OIH接入异常或WMS对账流水提供异常 三、基于库龄对账流水中WMS和OIH都有，但数量不相等，则OIH牵头排查 每天根据上述逻辑对库龄对账异常单据进行原因标注，每月统计非部分入库/非同步延迟的对账差异汇总数据，到商家维度，再发送给结算来判断是否调账。
晚上在思考应该怎么更新简书时，就想着把这个逻辑再梳理下，就突然发现今天聊的这个方案不就是半年前我刚开始做库存中心时那套方案嘛，但为什么当时没有按照这个思路落下去呢，主要有几个原因：1、库存中心涉及系统链路非常复杂，如果要基于对账单据来细分差异原因，需要投入更多的人力，而技术认为需要先做基建，做0-1，没有特别意识到库存监控逻辑细分的重要性；2、技术并不完全理解这套方案，大家都还没有实际排查过库存异常，没有更多体感，也没有更多认为比较痛的地方；3、产品方案也没有成体系化地梳理更加细致，并以更加有说服力的方式展现出来；4、在推动困难，大家普遍不那么认同，技术资源又紧张时，我自己也有点自暴自弃，部分放弃了这个方案。
像数据监控/异常处理/自动化提交工单/系统自动对比数据细化原因等类似的解决方案，可能也需要一些时间来沉淀，需要让参与的业务/产品/技术有更大的体感，大家才会真正重视起来，也才会形成更加体系化的产品，也才能把业务监控做成产品化的东西。
产品迭代大多数都是因为需求的更迭，而有一种迭代原因则是随着业务发展，部分产品功能会更加迫切，也更加被人理解，也就到了可以迭代的周期。产品经理则需要在工作中做好判断，哪些可以逐步迭代，哪些是必须一次性到位，哪些后面迭代时可能过于单薄无法锁定技术资源，哪些迭代是可以包到有一定关联性的项目里。
网友评论