分享

关系计划笔谈(9-1):泛BOM与虚拟产品

 场景学社 2022-03-16

发表时间:2010/1/13 12:32:44

    虚拟产品是客户需求与能力单元之间逻辑紧耦合、实体松耦合的产物,是业务运营的基础、前置条件和载体。逻辑的关联面主要是工序结构,也就是一个产品或者一组产品(我们称之为套装产品)从订单确认再到成品入库直至到客户仓库或者生产线再到客户的成品仓库的过程。这个过程里面的活动会非常具体化地得到分析,并且落实到能力单元。“客户需求-工序结构-能力单元”当然这个工序结构不仅仅是生产制造类的活动,还包括许多知识员工主导的活动,如图纸制作,也包括模具加工商主导的活动等等。这是一个基于价值链的设计,不增值的部分会被处置。上面说的这个逻辑控制变量是时间,正是这一点确定了我们后面要说的“订单项目化”。

    虚拟产品的另外一个特征是实体的松耦合,这主要是说,订单履行过程中的各个行为主体、利益主体以及能力单元(它们三者更多时候是重叠交叉的)不一定要属于同一个组织,这就是上面说的没有企业边界的概念。但是一旦有令,它们就会按照预设的方式展开行动,好比是预备役部队,平常会按照自己的节拍行动,有具体任务的时候会序时切换角色,这是相对于供应链管理者的角度来说的。

    虚拟产品不只是对产品构件及其参数描述,在虚拟产品的属性中它们大约只占到15%的信息量。虚拟产品的属性结构是分层级的。除了我们通常的BOM类内容之外,还包括对它们一旦在兑现为实体产品时候,所需要的作业现场的活动模式与活动载体的详细关联,并以这个载体为中心进行输入与输出的边界定义,确定投入的人工与材料,采用的具体的已经被论证有效的工艺方法等等。知识生产与物质生产两种倾向的活动都有一样结构的描述,在实际业务中知识生产与物质生产又是融合的。

    虚拟产品在拥有了这些属性之后,才有意义,才能形成关系计划的核心。

    虚拟产品在产品品类的结构设计上,需要不停地进行抽象,一轮再一轮的进行,每一个阶段,都必须对一定时期里面新增加的产品与之前的产品进行比较,进一步“合并同类项”。特别是从基本材料、产品物相结构(一般为成型与结合方式)等方面进行抽象将更有利于实体产品的“计划生育”,同时不影响客户需求的满足。这个方面的追求方式,类似于寻找化学元素周期表中化学元素一样,虽然没有那样的一个颗粒细度,但是实体产品抽象为虚拟产品的能力高低,实际上基于虚拟产品的实际地位,也决定了供应链的竞争水平高低。

                                  以上文字 摘自基于虚拟产品的关系计划模式

    对于BOM,当前的一个实际的革命性是它已经不局限于具体的实物性质的物料构成,而需要将物料之间的关系(相当一部分是工艺方式)模式化之后视同BOM去管理,当BOM有了这些元素之后,又不是经典意义上的BOM了。我将它定义为“泛BOM”。实物在系统中越来越虚拟化,呈现出其信息的一面,信息除了描述自身的属性之外,更多的是描述关系、状态以及一定状态下的关系。

这是新一代信息系统与传统ERP在底层的区别与联系。经典ERP里面的BOM架构发挥了重大的历史贡献,但是辉煌属于大工业时代以及大工业的遗老遗少。这个架构在迭代之后,MRP也就捉襟见肘了,所以才可能诞生出没有MRP(准确说是经典MRP)也能做好“一竿子到底”的计划模式。
    CIO俱乐部社区qlhl2000进一步说“BOM的假设不再是单纯的物料编码和工艺参数的属性,而是包含工艺方式上的动态搭配关系,以及线上线下的状态”,我确实就是这个意图!
    从经典BOM到泛BOM我们就可以将物料和工艺统一在同一个逻辑之下,这样就有可能将不同性质的生产要素进一步统一到时间刻度之下,MRP以及MRPⅡ以前不可能做到的事情(一步到位将任务分解到具体生产单位的具体班次的具体时段)就可以实现了。这个系列笔谈里面将进一步探讨“任务广播”的话题,这里就不展开了。它是“五化”(“五化”是指一个管理信息系统或者一个企业的业务架构需要体现这样的五个特性:【1】需求结构化【2】产品虚拟化【3】关系预置化【4】订单项目化【5】业务财务一体化)的重要产出之一。

     “泛BOM”之所以存在是因为当前以及未来的业务变化速率已经远远高于我们所感觉到的。记得1997年我在江苏盐城工作的时候,当时我所在的公司和另外一家电气企业谈并购之类的事情,我们去调研的时候惊讶地发现,它的产品已经30多年没有变了,就是做那种拉线开关,控制电灯,风扇之类。现在自然比较罕见,极偶尔你可以在一些小餐馆的壁扇上可以看到改良了的拉线开关。这个企业在80年代直到90年代初是非常红火的,一直没有考虑过如何对产品进行升级,这虽然是上个世纪的事情,但是我们还是不自觉地做了大工业的遗老遗少,不自觉地相对显得被动地进行产品迭代,以至于一路滑到“多品种,小批量,紧交期”的运营漩涡之中。

    经典BOM应当追溯到福特生产方式年代,那是允许我们将时间维度以季度为单位、月为单位、周为单位进行交付的。现在不行了。所以我在2007年架构ISCM(内部供应链)系统的时候,果断地以分钟为交付的时间单位,着实觉得这个粒度过细了。系统运行一年多来,发现恰好符合这个行业的供需规律。

     在引文中说的清楚,虚拟产品的构建基础其实就是泛BOM的元素。经典生产方式之下,产品的内在工序关系、工艺活动可以通过较大规模的批量处理来完成,关系是相对静态的,现在已经没有那个条件了。现代生产方式必须一揽子整体考虑物料、物料之间关系、加工状态、成品化进程等因素,这样才能精确制导,引领订单按照一定的方式履行,将物料转化为符合需求的产品来。

    泛BOM将以前属于不同领域的元素进行系统思考,放置到一个较大的产业背景下去部署,就好像我们现在不能单纯地考虑农业问题,必须将农业、农村、农民“三农”一起来考虑一样。泛BOM支持了虚拟产品的构造,同时也确定了资源与能力之间的关系,能力与订单之间的关系,资源与实物产品之间的关系(笔谈系列的9-2,将专门谈“关系”问题)。泛BOM包含了经典BOM,高于经典BOM,这样新式的BOM与经典MRP的关系也就解构了,MRP以及MRPⅡ的使命将由谁来承担,又如何承担呢?我考虑在这个笔谈系列的9-3里面进行深入探讨。



评论

发布者 andrewxxyi

王兄的观点有部分我很赞同,但有些我认为有些脱离目前的技术基础了。
泛BOM有两个难点:
1 :【1】需求结构化【2】产品虚拟化【3】关系预置化这部分都必须先行预编码入信息系统中,在竞争激励、演化迅速的今天,如何尽量消减这个预编码对业务的制约,也就是我一直强调的信息系统对业务的约束成本?!
2 泛BOM需要考虑的东西太多,而且我没有看到把实体联系送耦合的方式,交付时间如此狭小,就目前的技术来说,恐怕不可能实现实时解算。我举个例子,我做的人工智能平台在解算60个变量左右的贝叶斯网络时要达到100%CPU利用率算半个小时,而泛BOM恐怕小一点的也要考虑上百个变量,即便我的平台性能差点,算法弱点,但毕竟这种计划的解算都是NP问题,恐怕计划的时间都要在小时级别了,BTW:SAP目前做工厂计划也是在分钟级别的。这样的话,在分钟级别上的交付考虑,要么解算过程要锁定业务场景,那么小时级别就无法及时反馈业务变化;要么不锁定业务场景,那么解算出来的结果可能就对不上业务需求。

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多