2023-08-23 从单产品开发到平台产品开发的路径
企业如何从传统的单产品设计转型到面向平台的产品开发? 说起面向平台的产品开发,现在在市场上、网络上看到的资料几乎是汗牛充栋,但是几乎说明的都是优势,尤其是华为IPD的成功,更是带火了一波针对企业对平台的重视;在企业咨询中,很多企业也都希望面向平台展开产品开发,并且梳理了一定数量的平台,执行效果确不进人意;有些企业希望细细的打磨平台,结果当市场订单多的时候,在交付优先的情况下,这个肯定不是第一优先级,当市场销售不好时,这个好像又没有必要了。总之,平台是好的,但企业落地起来第一有点盲人摸象,第二有点鸡肋。 什么是平台?企业如何构建自己的产品平台,我也一直在寻找这个问题的答案;我查了百度,告知产品平台是为系列产品所共用和共享的,强调的共同要素,尤其是决定性技术(决定性的技术也是比较抽象的定义,我们先暂认为是一样的技术路线),再向源头追溯一下可能的资料,先来看两个产品平台的概念定义: 《PACE-产品及周期优化法》中,定义产品平台是关于产品规划及其战略决策而制定的一个概念,它是整个系列产品所采用的共同要素,特别是基本的决定性技术的集合; 《Porduct Design And Develppment》中,定义产品平台指由一系列共享的一整套资产,零件和部件经常是这些资产中最重要的部分; 所以在企业从常规产品开发向平台开发转型时,的确需要思考一些问题,贸然推进的确摸不到产品平台入门的路径,这个路径也只能企业自己去梳理和探索,对任何第三方专家和顾问的“直接喂入”都要三思。 在一家重型车企业,我们在一起进行了很细致车型平台的讨论,这里最关键就是核心技术路线的确定,就是在繁杂的衍生中,明确基层核心技术的一致性,然后在此基础上可以衍生面向不同细分市场和领域的型号,并且在型号的基础上,实现面向不同企业应用的产品配置/定制和交付;这里以牵引车为例,刚开始将牵引车划分为柴油发动机和新能源两个大的平台,但是经过讨论,发现这样太粗了,因为牵引车按照功率不同,底盘架构和动力传递系统设计是有很大差异的,因此针对柴油发动机系列,再次细分了重型车、准重型车、中型车和轻型车四个大平台,但是是否进一步细化平台时,大家争论比较大,有人建议用型号,也就是在这里衍生出了“大平台”和“小平台”的概念,当决策思路不一样,针对平台的划分就会出现差异的结果——其实最终我们的确按照型号来梳理了车型,并且在此基础上进一步整理了面向不同细分市场的标准配置(参考车辆用途、工况特征、客户构成、车辆收入、核心诉求点、产品需求6大维度进行分析) 这个项目在推广时,其实也遇到了很大的挫折,各种型号衍生和产品定制出现了失控,边界也模糊了,企业也没有感觉到平台共享技术和模块带来的多大的优势;所以这么几年来,我也多次复盘问题的原因,也和一些专家探讨过问题:企业明明在这块投入了很对还推广不是很顺利,那么对于大量中小企业,是不是更没有迈入平台的机会了? 直到我在一家企业完成将航空航天的构型管理思想向装备制造的迁移,并且为了保证常规装备设计的灵活性,也融入了大量产品工程的管理理念,后来也在一些企业咨询实施模块化管理,逐渐复盘出了一些道理:企业仅关注与平台的策划,却缺失了对平台架构的设计;或者也策划了平台架构,但是在产品开发中却没有按照策划的架构进行产品开发活动。 如下图所示,这是一个我汇总多个不同版本的技术开发、项目开发、产品开发和平台开发的关系架构图,我们可以通过几个维度推导落地的过程: 产品平台的建设和落地并不是一蹴而就的过程:几乎没有企业一开始就能完全策划好平台,并且针对不同细分市场和领域都进行了充分的调研和需求分析,然后在实现产品的架构上进行了充分的设计;随着产品推向市场,在应用过程中收集更多有价值的功能方案,产品平台必须有一个持续完善的过程;因此在产品开发中,必须有一个面向客户或者需求定制的通道,可以持续接收需求,并在产品平台上完善,支撑面向客户的配置或定制,或将在项目开发中的通用模块,按照一定的管理流程进行升级,更新到产品平台中; 不管是定制项目开发,或者单产品开发,都必须基于统一的平台架构:这一点很容易被忽略,认为平台开发是企业平台部门的事情,其实是一种共同协作的PDCA,项目开发和产品开发可基于平台快速配置和衍生,一个好的平台是支持灵活的配置和衍生管理,此时很容易保证结构的一致性,但是当平台无法满足要求时,针对特定场合定制很容易出现管理失控,这样定制的模块就无法直接被在此循环重用,或者只有被在此萃取和提炼后,才能继续进入产品或者平台中; 定制开发产品的新模块最好经过产品的再次验证再决策是否进入平台:虽然企业的产品开发和交付都是围绕着核心技术进行开展,但在激烈的市场竞争环境下,不排除提供了超出平台架构能力的定制开发;因此若存在定制模块,一定要有一个验证期,验证新开发模块是否被其他客户或者市场重用,只有重用度高的模块才能逐步被升级到平台中(面向大批量定制,这里提供的是一种更灵活的模式,不是必须在平台中完善后才能支撑产品配置,而是随着配置的增长和重用动态优化平台架构和模块);为了支撑这种循序渐进的架构,在策划业务逻辑和平台时,必须定义非平台中的功能和模块的重用逻辑(即游离模块),同时必须对平台中的模块,以及非平台中的模块重用过程进行监控; 技术平台的构建必须与产品平台保持一致的架构策略:按照平台的概念,其实是基于共性技术衍生出面向不同需求的产品解决方案,因此技术开发只有和平台保持一致的架构策略,才能最便捷的路径实现技术开发向平台开发的技术迁移;若是技术开发缺少一个整体策划和布局,那么在迁移时和重用时,就需要更多的迁移周期和成本(对技术迁移到产品上的影响范围和模块进行评估);当然技术存在更多预研的创新,很多企业因此也担心这种规则会阻碍企业的创新,针对这方面我也查询了很多国内外的数据,有序的创新方法实际必不确定的创新有更大的价值,常见的创新管理方法QFD和TRIZ等,都非常重视对架构的策划,并基于架构的模块实现内驱和接口改善产品的创新;因此在技术实现上,若产品的架构无法满足要求时,技术开发可以创建新的架构,等技术验证成熟后再评估向平台迁移的可行性,或者创建新的平台——也就是说,技术架构是产品架构的前哨; 企业的技术开发也需要分层管理:针对产品开发需要分层,已经在很多企业得到认同,但针对技术开发的分层在很多企业却没有得到重视;不管按照红海战略、蓝海战略等什么战略,企业将产品开发与技术开发分离,实际上是希望部分研发人员能更专注于技术的探索和预研,更多面向企业的战略和未来的市场目标,这和产品/交付管理还是存在差异时;面向技术预研,企业需要根据竞争策略识别短板或优势,有目的性的突破和成长,此时技术层和技术树的构建就非常重要,就像打仗一样,必须有一定战略的布局和出击,例如从传统能源发动机到氢能发动机的布局中,企业就需要了解氢能动力实现路径的所有关键技术,评估自研、协同开发或外购等,提前进行专利布局,或者传动发动机热效的提升,可能本身发动机架构无法改变,但针对底层材料的突破也许会有提升,那么技术创新实际就在材料研发;所以只有经过深思熟虑的技术分层分析,才能进行更完整的布局和突击。 一个业务架构的完整实现就像平台的构建一样,也是一个循序渐进的过程,那么有没有更简易的探索手段呢?其实是有的,以下步骤可以适应大部分企业的开发管理过程: 建立企业级的产品平台开发联合团队:产品开发跨部门联合团队面向产品的生命周期管理和架构管理,这是启动企业产品平台化开发的第一步;团队必须是核心的产品管理人员和架构师(很多企业喜欢将一些助理,或者非专家人员安排处理这些非救火的事情),除非企业的核心开发人员都忙着救火而没有时间进行面向未来的改善; 从小范围的试点开始建立企业进行改善的决心:从传统的产品开发模式到产品开发是一种创新,开发和管理思路与传统方式有比较大的差异,即使企业再有信息也不要忽略过程中可能遇到的阻力,学习党和政府改革开放的措施,先建立特区,从试点开始逐步推进,及时纠偏和总结经验,然后再持续开放;平台开发也是如此,先从实现开始,试点推广好了,会建立明显的对比,会吸引更多的产品逐步向平台开发迁移; 找一个企业认为比较成熟的平台产品,定义平台的架构,即组成产品的功能模块,在分解功能模块的时候,可以进行分层,包括系统层、子系统层、子子系统层等,具体拆分逻辑可参考《关于生命周期模块化定义的规则说明》,定义完成后,肯定还存在不完美的地方,别追求完美,那就按照这次架构进行产品开发,在产品开发中完善; 确保产品开发必须按照这个结构开发:这个步骤很难,很多时候出现问题时,大家的第一意识不是是修复完善规则,而是尝试辟蹊径逃过规则,其实当规则开始破防时,失控也就在路上;在经历好几个项目上,前期都有大量的投入,结果都是倒在这一步上,尤其是公司的高层发话,不能影响工程师对产品的交付,或者直接责问是否对交期影响负责——这里忽视了一点,任何变革都是有阵痛的,只要改变都有可能遇到阻力,哪怕我们明知道未来是光明(影响短期利益也不行) 对策划的平台和交付的模式使用情况进行持续的监控:因为我们知道平台和架构的实现是一个持续的过程,企业的平台文化也需要持续培训和导航去深入,支撑平台运维的管理人员也有一个成长过程;因此在平台开发的过程中,需要同步提供一个监控的渠道和方式,监控的指标包括几个方面: 产品开发或项目开发时,对平台的模块使用率:有企业说自己的零件重用率很高,但这个没有多大实际意义,因为零件层的变化组合的状况更多,合理的建议是模块使用率,这才是促进模块化推广的重要手段; 平台中模块的重用率:对平台中已经存在的模块进行分析,识别使用率的及时移除,不进对平台进行瘦身,也是保证平台新陈代谢的重要手段; 非平台游离模块的重用率:平台不阻止面向需求时的功能定制,这也是大批量定制的核心;那么在此过程中就需要监控新增模块的重用度,及时将重用度高的模块更新到产品平台中; 接收建议和包容变化:在平台推进过程中,因为要覆盖生命周期范围,因此在架构设计和业务规则定义时,难免有考虑不周的地方,因此要广开言路,吸收执行过程中的意见反馈,但是要认证甄选合理的建议进行改善,也就是开放严谨; 团队的持续学习和提升:改善是无止境的,工欲善其事,必先利其器,这里的“器”就是方法和工具,因此必须建立学习型组织,不仅加强内部学习,更需要向外部组织学习,广泛吸收不同渠道的方法和思路武装自己,去开拓企业的产品战略和目标。 关于生命周期模块化定义的规则说明 上一篇关于“平台架构设计和模块化设计的基本原则”的文章,得到很多人的关注,特别感谢认可;但是也有人感觉后面针对模块划分规则有点匆匆收尾,因此给我留言;的确有点抱歉,当时的确是有点困了,就没有细致的展开,因此在这里进行补充。 什么是生命周期模块? 在模块化成熟度管理中,的确提出了一个“生命周期模块”的概念,也就是说定义的模块是面向产品开发的生命周期,而不仅仅是设计阶段,那么从设计向工艺制造转换呢?若是不能保持模块的独立性,就无法确保信息的有效传递,因此在考虑模块化过程中,随着成熟度的增加,就需要逐步提升到生命周期模块,这样才能充分发挥模块的价值;如图所示,在基于生命周期模块开发时,就可以承载产品开发信息从需求向后传递,同时也可以建立交付产品服务运维失效与产品开发的闭环,因为数据维度是一致的,因此可以确保生命周期的不同业务是针对同一模块展开的,规避了非模块因素造成的影响。 什么是“分离面”以及作用? 在探讨生命周期模块时,有一个概念是“分离面”例如设计与工艺制造的分离面,或者设计工艺运维模块的分离面;定义分离面的主要原因,企业很难定义唯一的结构支撑产品开发生命周期的所有业务,因此通过多视图功能来满足不同的场景,例如设计视图BOM、制造视图、成本视图、质量视图等,不同视图会有不同的顶层结构,来满足不同的业务场景,即使同一视图,例如制造视图,A、B工厂制造路线不同,也完全有可能是不同的BOM结构和层级构造。针对模块的子项也无法保证不同视图完全一致,例如设计要求更加详尽,但工艺需要真实表达工艺构成,那么保持不变的,基于模块的“中间层”,就是所谓的“分离面”,在分离面之上,不同视图可以有不同的结构,分离面之下也可以有不同的结构,这样分离面就可以沿着“分离面”实现生命周期传递。 生命周期模块是产品正向开发,准守开发体系的基本功;包括在讨论MBSE时,其实离不开上述要求同样的逻辑,才能展开MBSE的工作(生命周期模块化是开展MBSE的基础)。 回归正题,那么模块定义的规则,如何思考呢?这里进行更详细的说明,如下: 独立性原则:模块的选择、替换、生产和制造相对独立,接口耦合尽量少 模块的定义时,常见的逻辑是“低耦合,高内聚”;低耦合是指模块或组件之间的关联性较弱,彼此之间的依赖性较小。低耦合的模块或组件,具有较好的可重用性、可维护性和可扩展性,能够实现模块化的开发和组装;高内聚是指模块或组件内部的元素相互之间紧密关联、密切配合,完成单一的、具体的任务。高内聚的模块或组件,具有较好的功能独立性,易于维护和复用;因为模块之间的接口是必须的,但在模块划分时,尽量规范不同模块之间的接口,甚至可以形成分析模板,这样不管是分析模块的影响关系,实现参数有效传递,或者进行失效分析,或者进行选配逻辑分析,或者变更受影响对象分析时,都非常的重要。 粒度适中原则:模块的粒度和数量必须控制在合理范围内,但可逐步细化 若按照模块化进行产品开发,那么模块本身就会承载大量的管理诉求,例如按照产品工程,或者IPD开发,在计划阶段,需要策划早期BOM、分解需求和关联、质量目标、成本目标等,那么要是模块划分的过细,就会导致概念和计划阶段的策划工作过多,但实际这个阶段很多时候可能做不到那么详细,就会造成维度不一致的管理偏差,例如早期BOM策划到模块层级,但成本目标仅能分解到子系统层级; 在划分模块时,我们建议企业可以先从大的功能模块开始,随着应用成熟度的增加,再逐步按需细化模块层级。 重用性原则:通过将更多模块由客户定制选项升为备用选项提前开发,增加重用和效率 从传统产品开发模式转型到模块化开发模式,首要目的就是通过优先的模块组合,最大化的满足客户对产品不同配置需求,因此在模块策划中,需要尽量识别功能模块中的可变部分和不变部分,然后进一步对功能拆分;简单的例子就是硬件上安装软件实现某一功能,软件经常升级,但硬件一般确定后很少变动,那就在策划时分开;我在企业也遇到过一个案例,就是控制柜,箱体基本一致,但是箱体面板会随客户对内部安装模块差异导致开孔和按钮位置差异,那么在箱体定义时,也进行了分离,除前端面板的箱体是一个模块,箱体的面板是一个模块。 唯一性原则:针对特定产品,模块仅唯一定义,包括左右件也属于不同模块 这个原则刚开始我是没有关注的,尤其是在进行部分产品开发时,里面存在重复性的功能和模块,常见如飞机的左右发动机、汽车的轮子、风力发电机的叶轮和叶片,发动起气缸中的活塞等;其实使用完全一样的零部件进行装配,那么这里为什么还要唯一性呢?要想理解,我们还必须按照生命周期视角查看,设计结果一样,但是在集成测试时,不代表测试一个就代表其他相同的就OK了,或者服务运维时,必须清晰表达相同的设计到底哪一个失效或有问题,此时若采用模块唯一性原则的就可以快速识别,但是若像风机,直接写数量3,就无法清晰准确的定位,这是理解模块唯一性原则的一种常见视角——按照这种策略,一般在一个产品中,所有的系统和模块的数量都是1. 设计分离面与工艺分离面一致原则:模块划分需要考虑设计和工艺的独立与协同 分离面的原则已经在前面说明了,目标就是为了设计与工艺的协同,也就是常见的DFA的理念,基于分离面,设计团队和工艺团队在产品概念和计划阶段就可以异步并行开发;当然分离面的定义时,也需要考虑第十条原则。 单级分层原则:模块不能嵌套使用,这样可简化配置和有效性管理 在按照模块化的理念进行管理时,模块之下是不允许再存在模块的,这也是为了简化管理的复杂度,若是模块下存在模块,我们构思一种场景配置管理,那么如何重复的表达选配关系呢?可能出出现交叉的死循环;若是在实际的策划中,出现一个更大的模块下嵌套了一个小的模块,那只能说明要么被嵌套的模块小了,要么是嵌套子模块的模块太大了;很多企业针对这块的理解误区是CBB,很多企业在管理中,是允许大的CBB下引用小的CBB,但从模块化的管理理念中,CBB最大不能超过模块的划分,否则就会降低构造的灵活性。 “只加”原则:指模块可以像搭积木一样调整,满足客户差异配置需求(大批量定制) 这里的“只加”并不是说只能添加模块,而是只能添加或者删减模块实现不同客户需求的个性化需求的配置;和传统的产品开发方法相比,例如BOM上的模块不满足需求时,常见的方法是仅修改差异的模块即可,但是在模块化的管理理念和方法中,实际是创建一个新的模块——新的模块和原来的模块遵守一致的架构和接口;当然新增加的模块也会重新进入的模块的配置库中,支撑后续更多业务的选项和配置;在业务推广时,很多工程师很难理解,为什么明明就是仅换一个零件就可以解决的事情,为什么需要从模块层级增加模块呢?其实这就是模块化开发的一种持续更新模块的一种措施和方法;但这也不是说模块的方案可不限制的增加,增加模块数量会增加选项的复杂性,因此也需要进行控制。 广义原则:模块是一个组建的逻辑组合,同时可包含需求、功能、设计、工艺、制造和检验数据 生命周期模块承载更多信息,因此在产品开发时,更多给抽象成为一个“管理模块”的载体,我们在产品开发中设计交付的模块,一般称呼为模块的“实例”,即当前模块的一种解决方案,工艺文件也是针对这种解决方案的工艺实现描述;因此这里就可以有第二种方案和第三种方案,每一种方案也都有完整的数据集,按照这种思路理解模块,就明白生命周期模块如何承载生命周期的信息。 以产品坐标系为参考坐标系原则:基于产品,建立唯一的方向、位置主坐标系…