模块化产品开发和设计模型的区别是什么？ 模块和CBB区别是什么？ 构型管理和模块化产品开发的区别是什么？ 构型管理、技术状态管理和模块化产品开发有无区别？ 企业实施了模块库管理，是否就是实现了模块化开发？ ......
我对这方面有一些模糊的认识，但毕竟都是非常专业的话题，不敢班门弄斧冒然回答；但为了理顺这些问题，我也专门咨询请教了几个行业内的朋友，结合前期在企业实施的咨询和实施经验，为了避免在后续业务过程中混淆不清，对这些问题也希望进行一次抽丝剥茧的分析；当然也希望更多专业人士能发现其中的不足，提出您的宝贵意见，实现大家的共创。针对上面的问题，其实看待这些定义和名词，有两个视角：管理体系和架构： 模块化产品开发，技术状态管理和构型管理其实属于一种产品开发体系和方法，只不过应用的领域和侧重点不同，但其实核心思想都是一致的，都详细定义了从产品需求的获取到开发过程的控制，一直到交付的完整业务过程。即和IPD类似，都是面向产品完整开发过程的一种管理思想，或者说是产品工程的一种方法论；里面包含的大量针对符合这种架构开发的管理方法和要求，企业为了达到这样的体系，基本都需要对产品开发流程进行重构——当然因为面向产品开发完整过程，因此对企业的改造也不是一朝一夕的事情。1)模块化产品开发：针对传统的电子高科技、装备制造等大部分企业，模块化产品开发是一种比较适应的，更容易满足这些企业的一种开发方法；针对模块化产品开发，要求企业按照平台架构梳理产品组成功能，定义基于功能的管理模块产品框架，并且在业务过程中使用这种框架进行产品的开发，持续不断的衍生新产品；IPD开发其实包含了模块化产品开发的核心思想，若是没有一个很好的模块化架构，在IPD计划/方案阶段的各种策划和定义就无法有效的展开，或者即使可以展开也很难做到知识沉淀，那么IPD就很难做到基于策划结果的PDCA；因此要求在产品开发前期，必须有一个支撑产品开发的模块化架构(包含架构的定义和接口的管理)，所有的产品开发活动也必须按照这种架构和方法开展；如下图所示，在基于需求包策划设计任务书时，不是仅仅提供一个文档，而是要基于产品的架构策划产品的构型功能和模块，并且基于产品构成模块的功能，展开质量、成本、测试和验证等工作的开展，即所有的策划工作也基于统一的模块展开，最终面向PDCP的评审和后端的并行产品开发和测试验证，也全部按照结构化的方式异步并行开展。 
2)技术状态管理：对于很对军工、航天行业的朋友，技术状态管理是非常熟悉的；这里以卫星为例，由于存在巨大的投资风险和开发失败风险，并且产品的应用场景非常的苛刻，因此就要求产品开发过程的每一步都需要得到详细的控制；通过技术状态管理，用技术和行政手段对产品、技术状态项及其技术状态文件实施指挥、控制和监督，包括技术状态标识、技术状态控制、技术状态纪实和技术状态审核等活动，并在产品（硬件、软件）中达到的功能特性和物理特性；目前这部分标准相对完整，包括GJB3206-技术状态管理，QJ3118-航天产品技术状态管理，Q/QJA32-航天产品技术状态更改控制要求；在技术状态管理中，比较关注以下管理要求：l对于产品寿命周期内的有关技术状态数据信息的技术状态文件进行有效管理l通过基线(功能基线、分配基线、产品基线)管理，清晰确定产品不同研制阶段，技术状态项及其文件的标识与控制l在重要节点、里程碑，固化产品技术状态，确保生产交付产品实物的技术状态和技术状态文件规定的功能特性、物理特性的一致性l实施技术状态管理，记录技术状态管理信息、生产、试验数据，确保可追溯性l使所有参与人员在其寿命周期的任意时间能够使用正确和准确的文件，掌握产品的技术状态，避免状态不一致导劲的差错和风险
3) 构型管理：构型管理主要用于航空领域的飞行器开发，这样管理技术最早起源于NASA，但经过几十年的发展，在飞机行业得到广泛的应用；在学习国外技术的浪潮时，国内的ARJ21-700，MA700进行了大量的探索和实践，在C919和AG600等进一步得到成熟的应用，也从民用航空发展到军用航空器的开发；比较成熟的标准体系可参考《EIA-649-B-Configuration Management Standard》，但最新的构型管理已经成为INCOSE系统工程中技术管理的一部分，实际上就是构型管理与MBSE的理念的一致性，并得到了充分的融合；在2017年前后，也特别有幸参与了将构型管理向轨道交通行业迁移应用的项目，也有幸拜访了行业泰斗范玉清老教授，在项目过程中进行了大量的学习和思考，并且将多种设计方法进行了融合和应用。l构型管理的优势在于针对构型项的定义，并且在产品开发生命周期中控制和追溯，虽然在技术状态管理和配置管理中都有类似的要求，但是从来没有像项目管理这样强调构型项的作用，仅仅构型标识的内容，就可以让企业对如何进行产品开发的生命周期追溯管理进行变革，构型控制对企业变更管理中如何减少变更蔓延也有很大的启发，构型审核的理念和逻辑同TR评审，DCP评审高度一致，但构型纪实在大部分企业导入实际上有一定难度的，但至少内部的管理思想还是很值得深入学习l在基于构型管理的产品开发中，第一步是对构型项的策划，构型项是一种管理模块化的要素，通过构型将产品按照一定的规则进行了分解，并且在产品生命周期中追溯，但因为构型项是一种融合在产品结构中的管理要素，是管理的载体，并不是真实的实物；在初期学习，或者在企业培训和导航中，这点需要特别的讲解和说明，只有充分理解了构型项设置的意义，才能真正的了解构型管理管理思想的精妙之处；我在Google资料的时候，发现了很多四五十年前NASA和波音等美国公司产品开发的资料，所以我也在思考，美国人的产品开发战略和思路真的非常优秀，几十年过去了，虽然我们很多产品填满了市场的角落，但不能不说，我们离前沿的开发思想，或者说正向开发还是有很大的差距，因此不得不快马加鞭的追赶l同构型管理一致，模块化产品开发和技术状态管理同样的策划了管理层级，这个我也是在实施构型项目后，复盘技术状态管理和模块化产品开发时发现的，但是很多时候，真的容易忽略这种思想体系管理的核心，例如在不止一家企业中，发现技术状态管理和IPD就被实施成为到一定阶段交付资料，对各种图文档的管理控制等
设计支撑工具和方法： 模块和CBB，更多是站在设计和重用视角的一种应用，当然可能会导致争论的是有人CBB也是面向企业管理的，但他们都不能作为一种产品开发方法，而仅仅是将产品开发过程中重用的元素，通过一定的方法沉淀下来，通过专门的引导技术或者指标的牵引，促使产品开发过程中尽可能重用已经存在的模块而不是大量进行“创造性”开发，从而提升产品开发效率，提升产品开发质量；我们经常讨论的模块和CBB基本可以划等号，在讨论中唯一的差异主要体现在CBB是经过IPD的包装，而成为一种更有吸引力的管理方法，而模块和模块库则一直默默无闻，继续做着更普世的理念(查询国外的资料，查询CBB几乎找不到什么素材，但是模块管理却可以找到很多，甚至比较古老的GT-group technology-成组技术，国内几乎绝技了，但是在谷歌学术上，CBB是17000条记录，但GT是9080000条记录)，所以我也在想，若是可以通过公众号沉淀下一些我的见解，也是一件幸运的事情1) 模块管理：这里需要特别注意区分模块管理和模块化设计(产品开发)——基于上面的解释，模块化产品开发是一种产品开发的管理理念，但模块管理更多指定义的可重用模块的管理和应用；在产品开发过程中，可以将任何可重用元素进行分析，识别可重用的通用元素，构建成为可重用的模块，所以这里的模块可以是结构设计的2D/3D模块，也可以是硬件设计的模块，可能是工艺模块也可能是质量模块等；在企业进行产品开发管理咨询时，我也更建议不同的业务部门可以发动自己的思路，集思广益的进行识别和沉淀，也不要局限于设计模块做好了才能进行工艺、质量等模块的限制，在一些企业取得了不错的效果；但是若不同部门模块数据没有拉通的情况下，很难做到并行的业务处理(即只有根据前端的输入才知道模块是否可重用，工作比较滞后)2) CBB管理：若企业实施IPD，就很容易被引入了CBB的概念，当然趁着IPD的东风，目前网络上有大量针对CBB管理的资料，我的建议是可以对等于模块定义和管理使用，因为不管叫什么名字，褪去马甲，其实内部基本一样的；因为这块的资料比较多，包括CBB的定义、CBB库的建立、CBB的日常运维等，在此就不进行重复；在此，可以分享一些针对CBB库建立的误区和我的个人建议：a)仅以熟悉的专业领域(/结构、电子、软件)划分CBB，而不是自定向下按平台的功能分解方式划分·刚开始做CBB时，其实我也一直在怀疑一个问题，就是企业如何识别自己需要CBB的布局，如何构建CBB架构，难道是随机的，随时识别随时使用；我在企业沟通咨询时，也进行了观察；其实在前期进行技术开发时，有一部分企业是可以识别出来通用的功能和模块，并且放在CBB库中，然后引导在产品开发中使用，但是更多的CBB是在产品开发过程中，不断总结和沉淀的，也就是说，CBB的开发也存在很大的一部分随机性·从正向研发来说，产品的成本、质量等全部是设计出来的，企业在根据路标策划产品平台时，必须考虑构建平台的组成技术，以及支撑功能的模块，模块的接口，以及接口与外部模块的耦合深度，基于模块进行产品配置和衍生设计时可能的变型范围等；通过对这些因素的策划，实际可以定义模块的兼容性范围和指标，逐步分离出来CBB模块的开发需求，那么这种设计方法是一开始就先提炼出CBB需求，然后采用异步开发的方式——采用正向设计引导CBB的使用·但正向规划CBB对于大部分企业有难度，所以可以先从产品开发活动中总结，尽管有一定的滞后性，但逐步转型提升到CBB的策划是符合企业的成熟度提升规律的b)模块层次比较多，我一般只建议划分最多2-3层公用模块，即: 跨功能领域CBB、专业领域CBB，降低查询和使用的复杂性·考虑模块划分颗粒度，避免过小颗粒度会导致模块数量高且层级多；企业针对功能的理解程度不一致，对CBB策划架构也存在差异，记得在企业咨询技术状态管理和构型管理时，不管在咨询过程中还是落地的工具中，都不允许管理模块下包含子模块，但实际在企业应用中却允许CBB下包含CBB，但这种场景的合理性还是有待讨论c)模块划分颗粒度过粗或过细：一般而言，CBB颗粒度越小，其通用性越高，但重用时的组合繁琐，管理成本高；同理若模块颗粒度越粗，虽管理成本低，但通用性相对下降适得其反了，那么如何确定模块划分颗粒度是合适的，基本有4个建议：·若企业实施模块化/技术状态/构型管理，则CBB模块的最粗划分等于管理模块：即在应用时，通过对架构策划通过功能指标选择合适模块，而不能用模块去反向影响顶层结构的策划·实现主要功能/性能的模块可以颗粒度更小一些，实现次要功能/性能的模块颗粒度可以更粗一些·管理能力强且模块化运作成熟的企业可以划分更细一些：根据企业的管理能力，选择和管理成熟度一致的管理方法，这是有效推进管理理念和工具落地的最佳实践，用粗话来说，牛有多大劲就拉多大车·刚开始推行模块化运作的企业建议颗粒度可以适当粗一些：虽然有朋友建议这条，但我认为在企业应用时有一些冲突，虽然比较合理的建议是通过顶层的梳理识别CBB并建立库(参考最后的章节)，但大量的企业仍旧采用的自底向上的方式进行逐步沉淀，很容易将CBB做的太细而不是太粗，所以企业根据自己的规则定义，在使用过程中不断复盘吧下图就是在一家企业，基于已经开发的产品梳理和识别CBB，然后再基于梳理结果对模型进行重构设计增加通用性，然后通过新的CBB模块引导后续的开发，这里其实就采用了CBB建设方法的两种不同的思路，当前期无法提前策划沉淀时，那就在已经交付的产品中挖掘通用性，然后重构新的CBB模块，在此应用到新产品开发中验证可行性，并持续不断的优化，也算是对CBB建设的PDCA管理。
但在更多的场景下，根据这些年的经验，还是将平台的规划，实现平台的核心价值和技术树的梳理，与之对应的CBB构建放在一块进行策划，构建CBB及产品平台是企业发展必由之路，其中产品平台引导CBB构建的目标和方向，CBB使平台的重用和价值进一步提升，如何结合应用呢，我的建议是：1) 产品结构和功能分解：按照系统、子系统、模块逐层级进行分解，在分解过程中，可以与功能树、技术树同步分解，评估合理的层级和深度2) 产品的技术树分解：对实现产品的技术树分解，分解技术是为了了解目前企业采用的技术在整个技术链的优势和挑战，以及便于关注技术链的发展趋势3) 结构和功能树与技术树的映射：必须建立映射才能知道技术如何驱动产品的实现，当然最理想的情况是独立的技术支撑独立的功能，功能和结构模块高度一致，通过标准的接口向外传递功能输出4) 分析和总结共性的技术与模块：通过多个型号多平台数据的分析，评估如何进一步提升模块的通用化，将模块从型号通用到平台通用，一直优化到企业内通用，甚至可以发展到行业通用5) 重构共享的模块和技术，提升通用性：按照分析的结果对模块进行重构，高内聚低耦合6) 放入货架进行验证：完成的模块放入企业的货架，引导在产品开发中应用，验证策划的结果；比较合理的CBB重用评估是在产品开发的计划阶段进行的，而不是产品开发后，才开始统计分析产品中CBB的使用数量等指标7) 持续不断的优化和升级CBB：只要技术在发展，产品在发展，CBB就需要持续不断的更新优化，进一步降本增质，当然也要及时移除过期的CBB或模块模块化产品开发和CBB管理与公司的规模和产品没有直接关系，不管是模块化产品开发还是简单的CBB库建设，都是企业管理日益走向成熟和精细化的一种体现；企业由无序走向有序，由无规则走向有规则，是一个刮骨疗毒、破茧重生的过程，企业的管理者如果没有这样的认知和决心，业务变革就不可能成功。
最后，祝福更多的企业在这场数字化变革的浪潮中成功抢滩。
|
