用设计的思路解读库存锁定功能.docxVIP

用设计的思路解读“库存锁定”功能---实施顾问需具备的系统架构思维几次在微信中提到用软件架构的思想去学软件，今天更有感触，基于标准产品的交付会越来越少，标准的核算和基础的HR项目也会越来越少，更多的项目一定会向业务延伸，而且延伸的程度会越来越深，这意味着标准产品交付的模式将会受到冲击，基于标准产品下的个性化开发会越来越多，如何在利用标准产品、利用现有系统平台，通过一个好的业务设计实现用户的需求的能力，对实施顾问会越来越重要。要具备这个能力，首先要学会用软件设计的思想对产品功能进行深度剖析，渐渐的你会能站在产品的架构层面看产品，你就会对产品随心所欲。用一个例子来说明，我们用两种思路来学习“销售订单”这个功能。首先用常规的产品功能层面来学：我们开始一项一项的学习，从订单的基本操作增删改查审开始，到订单的所有相关流程，多订单相关的各种控制，例如价格、合同、信用、收款、库存控制等，再到销售订单对生产、采购的影响功能，甚至订单中个性化的客户定制化的BOM，其实你还是学的很不错。不过我们今天换个思路来学习，除了掌握上述功能，作为一个管理科学与计算机技术交叉的行业，除了产品功能和业务实现外，我们来尝试从软件设计角度学习一下订单，再进一步，就深入理解一下销售订单锁定库存这个功能。我们知道很多流通企业都有一个需求，希望在客户下达订单时，检查仓库是否有货，有货下达订单结束后，能对这些库存锁定，不能挪为它用。我们开始想象如何实现这个功能，先不管软件，我们可以这样分析一下，想到如下两种方案：第一种：库存就像一个水池A，但客户下达订单后，我们把A水池的水移动到B水池中，A中的都是可以随便使用的，B水池中的都是名花有主的，这样我们只要随时检查A水池是否够；第二种：在A水池上增加一个计量刻度，每次下订单后，就将计量刻度按照订货量上升一点，刻度之上的可用，刻度之下的名花有主。这两种方法第一种显然是自由的和锁定的完全隔离，第二种实际上都在一个池子，可以互换，只要整个池子还有水，当然第一个方案属于强硬型方案，可以理解为库存硬锁定，第二种方案实际是通过可用量在控制。从程序设计角度去看，第一种方案简单粗暴型，直接上去把库存给分离出去，所以我们可以想象一定有一个库存分离的过程存在，系统控制的是自由库存中是否还有数；第二种方案比较温柔，没有把库存数据直接分离走，而是通过不停的计算是否还有可用量是否大于0。我们也可以分析出第一种方案，由于有数据分离的过程，所以更加可控，例如我们完全可以控制分离多少出去，可以更灵活的处理一些特殊场景，而第二种只是简单的通过仓库和订单的量来计算，比较理论，从控制的角度看可调节性较差，但从另外一个单据管理的灵活性看，第二种显然比较灵活，因为第二种没有实际的分离动作，数据还混在一起，所以系统不会控制订单与分离锁定数据之间的逻辑关系，第一种方案则需要考虑这个关系，因为对订单的影响也就更复杂，所以一个不太规范的管理，用第一种方案实施难度较大。上面用形式化的语言描述一些一下方案后，我们再想想从系统角度如何实现了，第一种方法把库存都搬走了，剩下的属于可用的，对应NC系统，就有对应搬走的单子（当然不是出库单，只是一种内部的库存锁定单据），就有剩下的现存量，于是系统可以实施记录这个存量，通过这个存量你就可以实现控制。第二种实际并没有被搬走，也没有相关单据反应这种库存的控制，实际上是通过一种总额控制模式，于是你会想到，他应该是通过现存量+预计入库-预计出库（订单未出库量）=可用量，可用量大于0意味着还有可用库存。于是你再想到第一种方案可能是通过一个静态的结存数控制库存是否可用，第二种通过一个动态的公式计算是否可用。再进一步，我们都可以找到上述业务在NC中对应的操作节点，例如库存的锁定，可用量的计算公式设置等。于是我们可以更深入的思考了，第一种方案我们说搬走了，其实只是一个系统动作，可能并没有实物上的动作，我们所谓的存量这个静态的值，其实也是计算机算出来的，系统是否真需要这个被搬走后的静态值存在？我们完全可以用系统中的数据（入库-出库-锁定）来计算这个值吗？但是系统却真不是这样的，再向后台深入一步，发现后台真有一张独立的现存量表来记录这个实时库存（NC中是ic_onhandnum，U8中CurrentStock），为什么需要，再分析，可以想象这是为系统效率着想，想想如果有大量历史数据，每次都从所有的历史数据中计算库存，需要花多长时间啊，但是每张单保存时把实时库存更新一下是很快的。由此很快我们很快明白了，为什么系统会有一个现存量整理功能，用来修正错误的现存量，冗余的数据库设计，提高了效率，必然造成稳定性下降。当然如果你富有供应链的经验，我们可能曾经发现，这个整理似乎也有点Bug，如果某一个存货结存为0后，一经整理，这个存货在现存量表中的记录就没了，偏偏系统的盘点单