用设计的思路解读“库存锁定”功能

《用设计的思路解读“库存锁定”功能》由会员分享，可在线阅读，更多相关《用设计的思路解读“库存锁定”功能（7页珍藏版）》请在金锄头文库上搜索。

1、用设计的思路解读“库存锁定”功能-实施顾问需具备的系统架构思维几次在微信中提到用软件架构的思想去学软件，今天更有感触，基于标准产品的交付会 越来越少，标准的核算和基础的HR项目也会越来越少，更多的项目一定会向业务延伸，而 且延伸的程度会越来越深，这意味着标准产品交付的模式将会受到冲击，基于标准产品下的 个性化开发会越来越多，如何在利用标准产品、利用现有系统平台，通过一个好的业务设计 实现用户的需求的能力，对实施顾问会越来越重要。要具备这个能力，首先要学会用软件设 计的思想对产品功能进行深度剖析，渐渐的你会能站在产品的架构层面看产品，你就会对产 品随心所欲。用一个例子来说明，我们用两种思路来学习

2、“销售订单”这个功能。首先用常规的产品 功能层面来学：毅髓检订勺内中心的於债、出用、开票、结览业务甜耳订单-討采购业务、牛产业备恂影响扪估订車客制J刊讣申弓科右扯的拎制我们开始一项一项的学习，从订单的基本操作增删改查审开始，到订单的所有相关流程，多 订单相关的各种控制，例如价格、合同、信用、收款、库存控制等，再到销售订单对生产 采购的影响功能，甚至订单中个性化的客户定制化的BOM，其实你还是学的很不错。不过我们今天换个思路来学习，除了掌握上述功能，作为一个管理科学与计算机技术交叉的行业，除了产品功能和业务实现外，我们来尝试从软件设计角度学习一下订单，再进一 步，就深入理解一下销售订单锁定库存这

3、个功能。我们知道很多流通企业都有一个需求，希望在客户下达订单时，检查仓库是否有货，有货下达订单结束后，能对这些库存锁定，不能挪为它用。我们开始想象如何实现这个功能，先不管软件，我们可以这样分析一下，想到如下两种第一种：库存就像一个水池A，但客户下达订单后，我们把A水池的水移动到B水池 中， A 中的都是可以随便使用的， B 水池中的都是名花有主的，这样我们只要随时检查 A 水池是否够；第二种：在 A 水池上增加一个计量刻度，每次下订单后，就将计量刻度按照 订货量上升一点，刻度之上的可用，刻度之下的名花有主。这两种方法第一种显然是自由的 和锁定的完全隔离，第二种实际上都在一个池子，可以互换，只要

4、整个池子还有水，当然第 一个方案属于强硬型方案，可以理解为库存硬锁定，第二种方案实际是通过可用量在控制。 从程序设计角度去看，第一种方案简单粗暴型，直接上去把库存给分离出去，所以我们可以 想象一定有一个库存分离的过程存在，系统控制的是自由库存中是否还有数；第二种方案比较温柔，没有把库存数据直接分离走，而是通过不停的计算是否还有可用量是否大于0。我 们也可以分析出第一种方案，由于有数据分离的过程，所以更加可控，例如我们完全可以控 制分离多少出去，可以更灵活的处理一些特殊场景，而第二种只是简单的通过仓库和订单的 量来计算，比较理论，从控制的角度看可调节性较差，但从另外一个单据管理的灵活性看， 第二

5、种显然比较灵活，因为第二种没有实际的分离动作，数据还混在一起，所以系统不会控 制订单与分离锁定数据之间的逻辑关系，第一种方案则需要考虑这个关系，因为对订单的影 响也就更复杂，所以一个不太规范的管理，用第一种方案实施难度较大。上面用形式化的语言描述一些一下方案后，我们再想想从系统角度如何实现了，第一种 方法把库存都搬走了，剩下的属于可用的，对应NC系统，就有对应搬走的单子（当然不是 出库单，只是一种内部的库存锁定单据），就有剩下的现存量，于是系统可以实施记录这个 存量，通过这个存量你就可以实现控制。第二种实际并没有被搬走，也没有相关单据反应这 种库存的控制，实际上是通过一种总额控制模式，于是你会

6、想到，他应该是通过现存量+预 计入库-预计出库（订单未出库量）=可用量，可用量大于 0 意味着还有可用库存。于是你 再想到第一种方案可能是通过一个静态的结存数控制库存是否可用，第二种通过一个动态的 公式计算是否可用。再进一步，我们都可以找到上述业务在NC中对应的操作节点，例如库 存的锁定，可用量的计算公式设置等。于是我们可以更深入的思考了，第一种方案我们说搬走了，其实只是一个系统动作，可 能并没有实物上的动作，我们所谓的存量这个静态的值，其实也是计算机算出来的，系统是 否真需要这个被搬走后的静态值存在？我们完全可以用系统中的数据（入库-出库-锁定）来 计算这个值吗？但是系统却真不是这样的，再向

7、后台深入一步，发现后台真有一张独立的现 存量表来记录这个实时库存（NC中是ic_onhandnum, U8中Currentstock），为什么需要，再分析，可以想象这是为系统效率着想，想想如果有大量历史数据，每次都从所有的历史数 据中计算库存，需要花多长时间啊，但是每张单保存时把实时库存更新一下是很快的。由此 很快我们很快明白了，为什么系统会有一个现存量整理功能，用来修正错误的现存量，冗余 的数据库设计，提高了效率，必然造成稳定性下降。当然如果你富有供应链的经验，我们可 能曾经发现，这个整理似乎也有点Bug，如果某一个存货结存为0后，一经整理，这个存 货在现存量表中的记录就没了，偏偏系统的盘点

8、单中的存货就是取的现存量中的数据，这些 没有结存的存货就不出现在盘点单上了，系统中没有结存，并不表示不盘点，于是这里出现 了一个小小的难题了，当然你会说那就保存那些为 0 的记录行不就行了，也许真的可以， 不过我们再研究下面的问题后，你会发现这个问题也不那么简单。上面我们研究了一下存量的一些设计思路，不过我们还需要向前一步，从数据的角度，研究一下现存量表的后台存储：-IT1- 討列儒雉罪.勿 &自中叩 0社麻 临日卫如 *自WF 血自由项9 癒孕0：项1匚 Q辅计邑耳述 玉拓日期 空咅出W亘幻生 雉惜入毛重腔 审&声基几月垄 0丰生 电眞区商 $批次号 宀如耸至 瞎和货营陛D 呈忘汨+宁已 &

9、三斥肥： 0圭旱裟“ Z巨 麻淞FI朗 0汉存坦: 爲呈托三匸宇慣 0方出旦 *肓；1.韩劲至 t&AS 雉古八辅放垂 条韦有削h.更编号1 2 3 4 5 6 ml -JI- 页页頁页页页页页I- I- I- I I I- I I- 曰日日日日日日日 自自自自自自自自自由项10U8量量量 量量数数数量 量数数量量1数昌 数量fsf?量抽 tsBHUIMff 吕我们可以发现两个密码，一是发现现存量是没时间概念的，现存量都是最新的，由于没 有时间概念，于是可以理解了为什么系统虽然参数不允许负库存，但是系统有时查看报表却 产生了负数，由于控制表无时间概念，所以如果单据时间不规范就可能出现问题，例如

10、用较 大的时间做了入库单，再用较小的时期做出库单，所以有时候用户会查库存告诉你某一天出 库量大于那一天的库存来证明软件似乎出错了，其实系统就是这样设计的；第二个秘密更重 要，从现存量表的字段可以完全可以判断系统对库存的管理维度，因为显然现存量表决定了 系统的控制维度，这个维度也显然就是库存系统的管理维度，例如我们看到有库存组织、仓 库、存货、主计量、供应商、批号、辅计量，自由项等，这些维度都反映了库存数据的管理 维度与精度。很容易我们发现无论NC还是U8没有物料状态（待检、报废、可用等）这个 维度的，所以这个需求只能另想办法。所以我们能从现存量表看到整个库存模块的管理粒度， 从一个点上你就抓住

11、了整个库存管理。在这个地方我必须出一道思考题了，在现存量表中，NC中有辅助计量单位字段，U8中却没有，于是我们困惑了，正常情况下，计量单位不是 存货的一个属性吗？如果只是一个属性，显然在数据库中是无需单独建字段的，因为从存货 字段可以获取，而且NC和U8在这一点上表现的还不一样，这个地方又会充分反映多计量 单位的设计思路，相信研发设计这个地方的时候一定有小小的纠结了，如果你没纠结，那基 于架构的思考可能还不到位，这是一道思考题，请各位从业务出手开始分析，为什么会有纠 结，这反映了多计量设计可能出现哪些需求和潜在的问题。第一个方案分析了一遍，发现后面隐藏着现存量这个大鳄，分析一下第二种方案，第二

12、 种方案是现存量结合一些公式计算，公式计算就有不稳定性，因为公式需要从不同的地方取 值，这不是个简单的问题，例如想到了如果订单不发货，订单部分发货，他们会怎么对可用 量产生影响，分析一下就明白了订单的关闭等一些列功能是多么的重要了，再开动脑筋，关 闭这个操作虽好，但是有时挺复杂的，大宗物资采购经常都有一定量的误差，造成订单处于 一个部分完成的状态，如果都去人工处理关闭，多复杂，于是终于明白了为什么系统有自动 关闭策略；既然是公式，不同企业的规则就可能不一样，于是就需要设计不同环境下的可用 量计算公式。所以，即使一个看着挺小的功能，后面隐藏着不少业务与相对应的系统设计。先就说这多，就一个库存锁定

13、的功能，也许我们随口一说系统支持，但功能的背后却隐 藏了现存量这个设计，从现存量这个设计我们甚至能够认识整个库存管理对库存的管理程度， 甚至找到了各种功能缺陷的真正设计原因。如果我们更深入的研究锁定，销售订单的实例还 只停留在销售和成品仓库的锁定，再分析一下生产有关的材料锁定，再向采购与加工环境延 伸，怎么从订单环节开始锁定，就一个锁定功能，甚至可以打通整个业务系统。就这样我们 从业务推功能，从功能推设计，从设计追数据，再从数据又能发现系统的设计，从这些设计 你又能明确系统能实现，能怎么实现那些功能，于是我们愈发清晰和明白了，业务、功能、 架构、数据都开始融为一体了，这也许就是气功中所谓的任督二脉打通了的感觉。我们实施 顾问开始具备一个程序员的一些思路了，开始理解开发人员了，能站在一个开发设计人员的 角度考虑问题了，我们甚至开始同情那些被全国人民骂的集团研发人员了。我们一直说的实施怎么去理解开发，怎么理解架构，同样对一个研发人员来看，深刻的 理解业务场景，能站在一个用户的角度去思考和理解设计，并能打通各个业务场景的互通， 站在一个更高的层面上做业务抽象与模型设计显然是比较重要的，有空的时候再探讨。