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

简介:

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

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

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

    虚拟产品不只是对产品构件及其参数描述,在虚拟产品的属性中它们大约只占到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里面进行深入探讨

本文转自    王甲佳   51CTO博客,原文链接:http://blog.51cto.com/secajia/416391


相关文章
|
6月前
|
Linux 测试技术 项目管理
产品、项目、平台、系统、应用的关系
产品、项目、平台、系统、应用的关系
95 0
|
8月前
|
开发框架 缓存 前端开发
区域LIS系统源码,SaaS模式,可扩展成医联体、医共体等模式
区域LIS可促进基层医疗机构条码化检验业务管理,为基层搭建标本采集、标本核收、标本检验、室内质控、报告发布、统计分析的规范流程,同时为医疗机构提供检验诊断知识库提升检验业务水准。
|
10月前
|
存储 Oracle 安全
|
数据管理 测试技术
多域MDM与多个域MDM:区别比你想象的要大
最近,出现了一种新的MDM趋势,供应商开始部署预构建的单域应用程序(例如,客户MDM、产品MDM等),声称通过这些应用程序的组合提供了真正的多域MDM功能。
|
运维 网络架构
《思科软件定义访问:实现基于业务意图的园区网络》电子版地址
本书介绍了目前业界炙手可热的意图网络和思科在企业网络解决方案中实现意图网络所采用的全数字化网络架构。本书以图文并茂的方式,力图通过简单易懂的语言展示思科意图网络的理念和在园区网中的具体的实现方法,希望读者可以通过本书系统地了解思科软件定义访问的全貌,进而把握行业趋势,拓展知识面。本书适合希望了解意图网络概念和实现方法论的读者作为入门材料阅读,同样适合网络建设、运维 和管理人员借鉴并帮助他们。
99 0
《思科软件定义访问:实现基于业务意图的园区网络》电子版地址
|
定位技术
从用户关系看产品发展
从产品与用户关系角度,可以分为三类:单点、单边和多边。
115 0
从用户关系看产品发展
|
人工智能 自然语言处理 算法
多语言互通:谷歌发布实体检索模型,涵盖超过100种语言和2000万个实体
实体链接(Entity linking)通常在自然语言理解和知识图谱中起着关键作用。谷歌AI研究人员近期提出了一种新的技术,在这种技术中,可以将特定语言解析为与语言无关的知识库。
148 0
多语言互通:谷歌发布实体检索模型,涵盖超过100种语言和2000万个实体
|
存储 传感器 架构师
带你读《思科软件定义访问 : 实现基于业务意图的园区网络》第一章思科全数字化网络架构和软件定义访问简介1.3(六)
带你读《思科软件定义访问 : 实现基于业务意图的园区网络》第一章思科全数字化网络架构和软件定义访问简介1.3(六)
带你读《思科软件定义访问 : 实现基于业务意图的园区网络》第一章思科全数字化网络架构和软件定义访问简介1.3(六)
|
运维 安全 物联网
带你读《思科软件定义访问 : 实现基于业务意图的园区网络》第一章思科全数字化网络架构和软件定义访问简介1.2(一)
《思科软件定义访问 : 实现基于业务意图的园区网络》第一章思科全数字化网络架构和软件定义访问简介1.2
|
存储 监控 API
带你读《思科软件定义访问 : 实现基于业务意图的园区网络》第一章思科全数字化网络架构和软件定义访问简介1.3(四)
《思科软件定义访问 : 实现基于业务意图的园区网络》第一章思科全数字化网络架构和软件定义访问简介1.3(四)
带你读《思科软件定义访问 : 实现基于业务意图的园区网络》第一章思科全数字化网络架构和软件定义访问简介1.3(四)