​   产品包需求也就是offering  Requirement，也就是OR，是产品开发、测试、验证、交付的需求依据，只有高质量的产品包需求，才能一次性地开发出高质量的产品。其中OR主要包括三个方面的需求，一个是市场/客户需求，也就是外部客户需求，二个环境需求，如各个行业的和地域的法律法规要求、显性或隐性的风俗等等，三是产品的非功能性质量属性需求，如质量要求、DFX需求。其中DFX需求的内涵非常广泛，主要来自于内部客户的需求（包括兄弟部门和公司高层）。那么，这DFX需求的通常来源于哪里呢？怎么提出呢？DFX需求也称为诸可性需求，如DFT需求，也就是可测试性需求。 1、来源于各个职能组织的基线，这些基线都是各个职能部门在业务开展实践中整理形成的。 2、来源于产品开发团队在分析和评估该产品的产品概念时，对于该产品概念在制造、采购、服务、测试、维护、回收处置等产品全生命周期的各场景需求和现有能力之间差距的评估。这些需求需要相关领域和产品设计团队进行充分沟通，确保产品在质量、成本、进度、投资、市场方面拥有端到端竞争力。如: 服务场景，包括售前、交付过程、客户拿到产品的使用过程中的各种需要服务的场景、工程服务人员进行服务（安装、调试、维护、维修）等场景 3，这些DFX需求的提出要SMART化，能够被验证，在产品开发过程中的TR点能够被跟踪。 4，这些DFX需求的实现能够支撑相关领域的业务计划，最终能够支撑产品包的业务策略。各个领域的业务策略的制定首先要形成业务目标。业务目标是通过客户、竞争对手、自身进行竞争比较，识别短板，进而制定相应的业务目标，要可量化。如客户服务满意度、客户需求响应速度、平均维修时间、平均故障定位时间。那么相应的策略，就是达成这些目标的策略。有些是通过产品落实的可服务性需求来满足的，有的则是通过备件准备、400电话、就近设置服务中心等措施完成的。通过这些策略的设置，也可以进一步提出相应的计划、资源需求，同时开发相应的服务产品包，包括故障定位指导书、安装维护手册、软件升级指南、备件定价策略等等。

         研发型企业通常有三大主业务流程: 研发业务（创造价值）、营销及交付业务（交付价值）、服务业务（维护价值）。为了围绕客户需求创造价值，通常有四种类型的研发业务: 产品预研、产品开发、技术预研、技术开发。企业要针对不同项目选择不同开发模式:IPD模式、敏捷模式、IPD+敏捷模式。       由于敏捷开发模式而产生，解决快速交付，特别是软件开发的瓶颈从开发阶段转移到测试，然而由于测试能力的提升、自动化测试工具和方法的引入、测试能力提升后，产品的运营和维护成为了快速满足客户需求的瓶颈，于是DevOps模式就诞生了，形成了开发、测试、运维一体化的模式。将来的不仅在互联网行业、软件开发行业、智能硬件、数字化硬件产品方面将逐步成为趋势。这种趋势下，传统产品开发模式下的需求收集方法将更加多样化、将更加和客户产生更紧密的链接。很多行业特别是ToB企业，直接将客户加入到产品开发项目团队已经是再正常不过的事了。 无论IPD管理模式还是敏捷开发模式，或者IPD管理模式+敏捷模式，这些管理体系的落地，需要遵循“总体规划、分步实施，循序渐进”的原则。否则很难“一口气吃个胖子”，因为组织还一下子消化不了。比如，对于IPD管理模式落地而言，需要根据不同的企业实际情况来定制落地方案。不同规模、不同行业、不同研发管理成熟度的企业，需要有不同的落地路径。通常情况下，需要遵循微观IPD、中观IPD、宏观IPD这样的开展顺序来推进。为什么是这个顺序呢？这是因为“业务与能力的平衡”这条落地原则在起作用。先要通过微观IPD体系的建设形成最小可行研发管理体系（MVP），牵引组织能力的提升和打造适应IPD落地的组织文化，而微观IPD是最接近企业的组织能力的模块，通过微观IPD的建设形成有利于IPD体系落地的“土壤”和“肥力”，才有利于中观IPD、宏观IPD管理体系的建设。 ​       这个过程不是一朝一夕可以建成的，需要企业对IPD管理体系建设能够帮助企业实现战略目标、能够提升企业研发管理的成熟度、提升企业长期竞争力有“宗教般”的信仰，而不是“试试看”、“将信将疑”。只有这样，IPD变革才能持续下去，同时企业的组织创新能力才能持续增强。就如强悍如华为这样的企业，也是经过了20多年的坚持不懈的变革才取得了如今的成就。华为从2008年引入敏捷开发模式，也并不是否定IPD，而是对IPD的深化，是对企业适应VUCA时代的一种正常反应。也正是IPD核心思想“与时俱进、灵活发展”的体现。IPD在华为的发展史，也是华为成长史、实践史。正如任正非在2003年说： “很庆幸的是，IPD、ISC在IBM顾问的帮助下，到现在我们终于可以说没有失败。注意，我们为什么还不能说成功呢？因为IPD、ISC成不成功还依赖于未来数千年而不是数十年实践的努力和检验。

​       IPD开发模式下，产品开发效率是如何提升的？其内在逻辑是什么？本文简单做个小结。 1、采用IPD创新方法重构产品开发流程，使其结构化和规范化。 IPD将产品开发业务中的各个参与角色，包括项目组成员、项目经理、部门经理、相关专家、决策层清晰识别出来，并对其在开发过程中应主导的活动和应承担的职责识别出来。对开发过程进行合理的阶段划分，明确每个阶段的目标，围绕阶段目标来开展工作。阶段点的设置，既不能多，也不能少，太多就会降低开发效率，太少则缺乏必要的过程管控，难以保障结果的质量。同时，对流程中的关键活动和交付件模板进行定义，既实现了经验的传承，又能够提高完成每个活动的质量和效率。理清主流程和支撑流程之间的相互关系，将各专业能力通过流程汇聚到主航道，让主航道爆发出蓬勃动力。同时，主流程IPD流程采用了基于IPD的创新方法论，遵守渐进明晰的客观规律来设计流程，想好了再做的设计流程设计理念，避免了匆匆忙忙开始进入开发阶段，然后不断修改，项目周期不断延期，这样大大缩短了产品上市时间。 2、将商业线和技术线集成在一起，同时满足客户需求和商业目标。 产品成功的标志只有两个：满足客户需求和企业的商业目标，两者缺一不可。为了满足客户需求和商业目标需要，IPD产品开发过程将产品实现线和商业计划线集成在一起，贯穿于产品开发的整个业务过程中，通过过程的管理，到达结果的满意。 3、 概念和计划阶段是IPD产品开发流程的核心，落实想好了再做。 概念阶段确定了产品开发的目标和依据，明确了产品开发的“靶心”，同时通过概念设计和策略制定给出了产品开发达到目标的路径。计划阶段将概念阶段的工作进一步做细、做扎实，具有可操作和落地性，形成计划和方案，为进入产品开发阶段的实施与验证提供了保障。 加强概念和计划阶段工作表面上相比以前直接开发的模式增加了时间和精力的投入，但磨刀不误砍柴工，实践证明，正式由于这两个阶段的重视，大大缩短了开发、验证和发布阶段的时间，从而整体上压缩了整个开发周期，不仅如此，还会因为减少返工而提高产品质量，降低产品开发费用。 4、 跨部门的并行开发和团队合作，加快了产品开发上市速度。 IPD模式下的产品开发流程是由各个领域共同协作的并行流程，每个领域的角色在产品开发过程中都在开发产品的“一部分”，他们在项目经理的带领下，各负其责、各司其职，“力出一孔、利出一孔”。通常把IPD 流程中的角色或领域分为九类。分别是高层决策、项目管理、财务、质量、研发、采购、制造、市场、技术支持。高层决策团队负责产品开发过程中的商业决策，项目经理负责整个项目的项目管理工作，对产品的最终成功负责，其他各个领域分别设立领域核心组代表和相应的扩展组成员，对应完成相应领域流程规定的活动，对领域的交付质量、进度、成本负责，这样整个团队在项目经理的带领下各司其职、并行工作，打破了各个职能部门的部门墙，在产品开发过程中拧成一股绳，共同为产品开发的成功负责。 5、DCP决策评审点和与TR技术评审点，确保技术风险和商业风险可控。 在产品开发流程中设置合理的决策评审点DCP，方便高层决策团队在规定的节点上对产品开发的商业风险进行把关，做出合适的决策，承诺合适的资源，确保资金和资源的投入受控。产品开发过程中的决策评审点包括概念决策评审（CDCP）、计划决策评审（PDCP）和可获得性 / 上市决策评审（ADCP）。 决策评审必须做出明确的结论，且只有三个结论： （1） 继续（Go）：同意，可以继续开展项目，承诺提供下一阶段资源。 （2） 重视项目（No Go）：不同意，项目终止，释放资源。 （3） 重新定向（Redirect）：重新定向，要求项目组根据高层评审意见对业务计划进行调整优化，重新进行决策评审。 在IPD的产品开发过程中，设置了若干产品级的技术评审点（TR），通过这些技术评审点来把控产品的开发的技术风险，识别潜在问题和并进行需求的跟踪，确保产品开发过程围绕既定的产品需求目标。 IPD流程为了保障这些评审的效率和质量，通常都会对这些评审会的运作提出严谨的要求，只有落实了这些要求才能发挥这些评审点的作用。 6、分层分级的IPD流程文件体系，让项目成员在流程底座上跳舞。 IPD流程文件体系通常分为六级，包括创新管理流程、IPD流程、阶段流程、活动、步骤、模板表单。每个层级的流程解决每个层级的问题，包括规划层、管理层和操作层。通过这些流程之间的相互支撑和承接管理，企业各层级员工，包括管理层，在流程的底座上发挥各自的功能，共同支撑企业战略目标的达成。 7、通过IPD流程体系统一了企业的创新语言，大大提升了沟通效率，减少了管理成本。 IPD产品开发流程的构建，统一企业各个业务单元的产品开发语言，降低了沟通和管理成本。让整个公司上下左右对产品开发过程的方法论、开发过程、管理名词、术语都统一的语言，如IPD方法论、DCP、TR、PDT等，这样在沟通上很容易达成理解上的共识。 8，基于平台化的开发模式，让研发工作不再重复发明轮子。 在产品开发中也一样，模块化、平台化、标准化才能加快产品开发的速度，缩短上市时间、提升产品质量、节约开发成本，这是多少企业梦寐以求的研发愿景。在实践中，不注重平台化建设、标准化建设、模块化开发的研发实践比比兼是，既不重视纵向的继承，也不重视横向的共享，盲目创新的情况不在少数。这样的企业研发效率就很难提升上去。其实，在持续推出新产品，特别是系列化产品的背景下，模块化、平台化、标准化可以说是企业研发策略的必由之路，也是项目型公司和产品型公司的重要区别。通过模块化，便于异步开发和同步开发。通过平台化，基于系列产品的共性需求，迭代推出不用版本的平台，在不同平台上开发系列化的产品。通过标准化，最大化地减少变异，减少新开发工作量。这种标准化可以是设计规则的标准化、系统、子系统、部件、模块的标准化。如CBB的规划、开发和应用。不仅产品本身可以标准化、模块化和平台化，其实是物料选型、制造流程都可以通过标准化来提高可制造性、提高制造效率，降低制造成本和物料成本。如物料归一化、制造流程标准化、组装流程标准化、降低标准化作业的工时。采用数量有限的产品架构和平台，避免零部件序列的增加，必要时需要收编。如汽车企业那样。通过“平台化+差异化”策略既满足客户个性化需求，同时降低产品的成本，提升产品质量。 9，IPD是与时俱进灵活发展的，传统的IPD已越来越敏捷化、定制化。这也为IPD适应VUCA时代的发展要求加快企业响应客户需求的反应速度，进而提升研发效率。 以上只是IPD管理模式提升产品开发效率内在逻辑的简单总结，IPD变革的目标是让产品研发“多、快、好、省、准”，从而有力支撑企业的营销活动，创造并留住更多的客户。

导读：本文主要介绍了某制造业的企业级BOM系统和PDM 系统的集成方式，利用中间库原理实现了BOM系统和PDM 系统的集成方案，完成了企业级BOM 产品资料和PDM 系统文档资料的有机集合。   1 现状 　　目前，随着企业业务发展需求，PDM系统出现了一些制约企业快速反应市场需求的瓶颈：产品资料是单车型管理，缺乏平台化、系列化概念，产品变更复杂且效率低，已经不能满足某企业业务发展需求。企业级BOM系统，不仅能满足企业业务发展需求，且给产品规划、设计、工艺、制造、物资采购、备件和售后服务各业务领域提供产品定义数据需求，并以BOM数据作为驱动器来触发产品设计的全过程中各领域的业务活动。由于BOM系统和PDM系统分工不同，BOM系统负责各业务产品数据管理及变更流程，PDM系统负责产品数据资料对应的图文档管理，做好BOM系统和PDM系统的有机结合，才能实现两系统的业务分工和数据一致，选择集成方式尤为关键。 2 系统集成概述 　　BOM系统和PDM系统采用中间库表的方式实现系统集成，中间库表创建在BOM系统数据库中，通过数据库用户权限设置允许PDM系统修改指定的中间库表数据。BOM系统和PDM系统集成实现了产品零部件二维图纸的变更控制，包括变更流程发起和图纸发布。总体变更流程如下图所示： 图1 BOM-PDM系统集成接口总体流程   总体流程采用串行，BOM系统发起产品零部件变更流程后，PDM系统定期扫描中间库表相应的接口字段，当PDM扫描并接受到BOM发起的图纸修改变更申请流程后才可以发起审批流程并开始审批，待PDM审批流程批准后，回传到中间库表中，BOM系统接收到中间库表的信息，才可以开始BOM变更流程审批，待BOM系统流程发布后PDM系统才可以发布审批流程。由人工保证BOM系统变更流程发布，同时PDM系统审批流程接收到中间库表的信息自动发布并下发完成。 BOM-PDM系统集成接口涉及以下三个接口：①BOM系统变更流程发起；②PDM系统变更流程批准；③BOM系统变更流程发布。 3 中间库表定义 　　3.1 变更主信息表 SCHEMA：INTF4PDM 表名：BOM_CHANGE_MAIN_INFO 表字段属性定义： 表1 变更主信息表 　　3.2 变更零件信息表 SCHEMA：INTF4PDM 表名：BOM_CHANGE_PART_INFO 表字段属性定义： 表2 变更零件信息表   4 接口定义 　　4.1 BOM系统变更流程发起 接口描述： BOM系统发起流程变更时，当变更内容涉及零部件二维图纸变更，则将变更信息发送到中间库表。PDM定时从中间库表获取变更信息发起PDM图纸变更流程。 接口场景： 1）用户在BOM系统发起工程变更，该变更涉及零部件二维图纸变更； 2）BOM系统将变更主信息和涉及二维图纸变更的零件信息发送到中间库表；变更主信息表中更新状态置为BOM新增变更；变更主信息表中流程状态置为流程已提交； 3）PDM系统定时从中间库表获取变更主信息和二维图纸变更零件信息；变更主信息表中更新状态置为PDM读取变更； 4）PDM系统依据获取的变更信息创建变更单和变更审批流程。 图2 PDM系统接收BOM变更申请并开始PDM审批流程 4.2 PDM系统变更流程批准 接口描述： PDM系统变更审批流程批准后，系统将批准信息更新到中间库表。BOM系统定时从中间库表获取批准信息开始BOM系统流程审批。 图3 BOM系统接收PDM批准状态并更新接口审批状态   接口场景：…

一流的企业卖技术，二流的企业卖品牌，三流的企业卖产品，四流的企业卖体力。技术来自于研发和创新，所以，创新是企业发展的“爹”；品牌来自体系和集成，所以，集成是企业发展的“娘”。在一个环境持续变化、供应同质化和需求碎片化的市场，企业要活下去，必须要有高于竞争对手的运营效率，这来自于全环节的集成，ERP的应用就是尝试帮助企业解决集成的问题；而企业要活得好，则必须为市场提供创新性产品或服务，PLM的应用就是尝试帮助企业解决创新的问题。     PLM的创新使命 大体来说，在制造型企业中，与产品开发有关的创新包括产品功能和结构的创新（产品创新，Product Innovation），比如5G技术和产品；以及产品制造过程的创新（过程创新，Process Structure），比如5nm芯片加工技术和工艺。只要具备其中一种，企业就能获得竞争优势；如果两者兼而有之，那无疑将处于行业的绝对垄断地位。 那么，PLM是如何帮助企业提升创新能力的呢？作为一种数字化产品研发管理解决方案，PLM的主要功能包括需求管理、文档管理与CAX集成、研发协同与可视化、知识管理、产品组合管理、通用件库管理、项目管理、分类管理、配置管理、工程变更、质量保证，等等。通过上述功能及模块的应用，PLM可通过以下途径为产品或过程的创新赋能： （1） 提高零部件重用度，助力架构化产品开发，从而减少重复性的研发开支，让企业有更多的预算从事真正的创新性活动，并大大缩短产品开发周期，并降低产品制造成本。 （2） 促进跨专业的协同，提升同步工程的工作质量，以多领域、虚拟化的团队合作来激发专业人员的创意和构思； （3） 促进跨团队的共享，共享与产品或过程（工艺）有关的关键信息，提高相关人员获取信息的便利性，并打破专业和领域之间的信息壁垒； （4） Know-How的应用，通过知识工程、专家系统和参数推荐等方式，在细节性的工程设计决策中为相关人员提供技术建议和经过工程验证的优选方案，比如，机械零件尺寸公差或材料的选择； （5） 构思的显性化、结构化和不断迭代，通过需求结构、需求与功能映射、机理模型、产品原型、数字化模装（Digital Mock-up）等形式，不断地将产品的创新性构思进行迭代，提高从构思到产业化的速度和质量。 从哲学的角度看，PLM的核心使命是帮助企业把客户对产品的功能性需求，转化为企业对上游的人、机、料、法、环、测等资源的需求，是一个从“一”到“多”的过程。       ERP的集成使命     产品和过程的创新是“爹”，是“生”，是从功能需求到生产资源的从“一”到“多”；那么，销售、采购和生产等之间的集成就是“娘”，是“成”，是将资源转化为商品或服务的从“多”到“一”。在制造型企业中，从数字化建设角度来说，集成的使命主要由ERP等IT系统来完成，具体内容包括：技术与生产的集成、业务与财务的集成、需求与供应的集成，详细内容可参考笔者的前一篇文章：ERP应用成熟度模型概述，本文就不在此赘述。     PLM与ERP的集成 “爹”和“娘”要结婚才能生养孩子，企业中的创新和集成也需要通过某种机制将它们形成一个有机的整体，才能形成企业的竞争力，这可以通过PLM与ERP的集成来实现。 图1：制造型企业的PLM与ERP 如图1所示，PLM与ERP的集成主要包括产品结构和制造过程等相关数据的传递，具体包括：物料主数据、合格供应商清单、物料清单（制造BOM）、工艺路线、分类和配置关系、工程变更和断点等数据在PLM与ERP之间的传递。其中，物料主数据、物料清单等属于产品结构信息，工艺路线、合格供应商清单等属于制造过程信息，配置关系是产品结构或制造工艺的内部要素之间的组合逻辑，工程变更和断点则用于上述信息的维护和管理。     集成的挑战 在技术特点上，PLM与ERP的数据结构有某些不同；PLM是以产品或过程对象为中心（Model-based）的数据结构，ERP是以交易记录为中心（Record-based）的数据结构；因此，PLM与ERP的集成不是一件简单的事情，如何保持两者之间数据传递的一致性和稳定性，是系统集成的难点。另外，还有一个数据交换的频率问题；具体来说，不同的制造型行业或企业，因为生产运营模式的不同，PLM与ERP之间数据交换发生的频率和时间点也不同。 图2：制造型企业的生产运营模式   如图2所示，根据行业、产品或工艺特点的不同，制造型企业主要有四种运营模式：1）面向库存生产（Make to Stock，MTS），2）面向订单装配（Assembly to Order，ATO），3）面向订单生产（Make to Order，MTO或Build to Order，BTO），以及4）面向订单工程（Engineering to Order，ETO）。不同运营模式下，预测与订单的切换点不同。比如，在MTS中，开发、采购、加工、装配等作业都是根据预测和计划来组织的，只有商品的发运是根据客户的销售订单来进行；又比如，在ETO中，除了架构设计和开发外，产品开发、采购、加工、装配、发运等作业都是在企业有了客户销售订单后才开始进行的。 通常，我们评价一个企业运营模式的复杂程度，可以从这么几个维度来进行： （1） 产品BOM的层次和零部件种类的多少。层次和种类越多，生产运营模式则越复杂。比如，乘用车产品，其零部件种类可能多达上千种。 （2） 加工和制造工艺中工序数的多少。工艺数越多，生产线越长，生产运营模式则越复杂。比如，民用飞机的生产，其工序数可能多达上千个。 （3）运营模式的不同。ETO模式下的生产组织相对复杂，而MTS模式下的生产组织则相对简单。 （4）生产规模的大小。生产规模越大，生产作业的频率就高，生产组织也相对复杂。比如，汽车行业中，60JPH的生产作业要比20JPH的生产作业复杂得多。 （5）订单种类的多少。订单种类越多，生产组织的复杂度越高。通常，多品种、小批量生产的复杂度，要高于少品种、大批量生产的复杂度。 根据上述运营模式的划分和运营复杂度的评价，我们可以推断，ETO运营模式下复杂性（机、电、软一体化）产品的小批量、多品种生产最复杂。在这种模式下，PLM与ERP之间的集成也相对复杂，对集成的质量要求也非常高。 图3：复杂模式下PLM与ERP的集成难点…

近年来，国家大力推进工程建设组织模式变革，出台了一系列推进工程总承包落地实施的政策文件，EPC工程总承包模式日趋成熟，逐渐成为工程建设市场主流管理模式之一。 EPC模式与传统承包模式相比，项目风险持续时间更长、更为多样，而设计牵头的EPC项目又叠加了更为复杂的因素。 项目风险周期从投标开始直至项目结束的全生命周期，风险来源包含各参建方组织机构、人员和各项管理活动，项目风险把控需要更高的风险分析能力与管理经验。 本文通过分析设计牵头EPC项目风险的主要成因、采用案例收集、流程分析、合规分析、溯源分析、专家访谈等具体方法，总结出EPC项目风险主要包括自然与社会风险、相关方管理风险、项目技术风险、项目商务风险、项目投标风险、项目设计风险、项目采购风险、项目施工风险8类风险。下面从风险的主要成因、风险识别的主要方法、风险的主要表现形式三个维度进行分析，以期为勘察设计企业做好EPC工程总承包提供参考和借鉴。 — 1 — 风险的主要成因 风险的主要成因发展过程由风险的因素、事件、目标、损失、结果等组成。 一是风险理论研究与实际应用差距大。一直以来，建设工程项目风险管理的研究主要集中在以施工方为主导的风险管理研究方面，对设计牵头的总承包项目风险管理研究很少。在风险管理的应用研究方面，目前较为普遍的是针对某个问题的风险采取独立、被动的风险管理对策，缺乏系统性、战略性的研究，也没有针对设计牵头总承包项目全过程动态风险管理的具体的、可供实际应用的技术手段和方法。在实践领域，主要还是靠专家经验进行个案的、定性分析，没有较为系统的风险识别以及在实践应用层面的管理措施。 二是设计牵头EPC项目合同管理难度大。EPC模式对项目业主而言，合同结构简单，业主的组织和协调任务量少，都委托给总承包商负责。总承包商必须有很强的技术和管理综合能力，协调自己内部与分包商之间的关系，因此EPC模式对承包商而言合同管理难度较大。同时，由于设计牵头EPC项目设计方不仅负责工程设计，而且需要负责工程施工管理和项目的牵头统筹，设计牵头方为顺利承接EPC任务，往往在项目前期阶段就参与项目招投标，以获得前端的市场竞争优势。但此时发包方前期工作不成熟、承发包之间的合同条款不易准确确定、与施工联合体方也容易造成较多的合同纠纷。因此，设计牵头EPC项目的合同管理难度进一步加大。 三是风险贯穿项目全过程且复杂多样。设计牵头的EPC项目风险随着专业类型的不同而不同，有对工艺要求高的水处理类EPC项目，其设计风险较大；有对安全要求较高的大型复杂EPC项目，其施工风险较大；有对社会影响较大的交通类基础设施EPC项目，其社会风险较大。所以，不同的EPC项目风险识别、分析与管控的重点也不一样。EPC项目接口多，参与的组织机构和人员多，不稳定因素错综复杂，风险的发生概率和影响程度不确定性较高。总承包商的工作内容贯穿于整个项目的设计、采购、施工、试运行全过程，其风险管理工作也必然包含于整个生命周期。各个阶段的风险不是独立存在的，相互之间具有一定关联性和耦合性。以上因素均造成了风险贯穿项目全过程并且复杂多样。 四是设计牵头EPC项目风险管理薄弱。设计牵头的EPC项目中，设计方更具备打通设计与施工的界面障碍的优势，使设计与施工的互动关系大大增强。在设计阶段施工专家可以介入，形成边设计、边施工的特点，有利于专家知识集成，缩短工期；从设计源头实施对工程投资的控制，对于降低承包商成本，提高利润起到决定性作用。但是，设计单位一直以轻资产运作，难以承担较大的财务风险；项目管理能力偏弱，容易因管理不善被拖入连带责任；企业缺少复合型管理人才，在外部沟通协调上有较大提升空间；组织架构与制度体系尚不健全，在应急反应体系上存在缺失。这些因素导致设计牵头EPC项目风险管理的“基础底座”不够稳固、能力偏弱。 — 2 — 风险的识别方法 常用的风险识别方法，如基于过往案例、项目管理流程、法律规范要求、溯源分析、专家经验等方式，可以发现和列举出项目存在的风险，构建符合自身经营管理需求和项目管理要求的项目风险识别框架。风险识别的主要方法如表1所示。 表1  风险识别的主要方法 案例库法，是通过对行业发生的案例进行收集和梳理，发现存在的风险。此种方法覆盖面广、启发性强，但可能针对性不强。 流程分析法，是通过对项目管理主要流程的梳理和总结，发现其中可能存在的风险。此种方法符合企业实际、利于管理提升，但会受到分析人员经验和能力的局限。 合规义务识别法，是通过对相关法条、管理规定或行业规范的归纳、整理，对照识别项目可能存在的风险。此种方法可以守住合规底线、确保合规经营，但通常是基础和宏观的内容，难以覆盖实际项目中复杂多样的情形。 溯源分析法，是通过对引发问题事件的原因的识别，找到可能存在的风险。此种方法可以由现象深入问题本质，有利于抓住风险源头，但通常为事后分析，对于形成风险应对措施有一定滞后性。 专家评估法，是通过对行业内专家的深度访谈、座谈会等方式，对发现的风险进行评估、判断、补充。此种方法可以利用专家经验对进行风险评估和补充完善，但容易受限于专家的经验能力和主观判断。 图1 风险因素到产生风险的过程示意图 实践中，收集风险事件相关信息是风险识别的第一步。针对具体项目应收集已建类似工程的有关数据资料、拟建项目数据资料及工程设计施工文件，全面分析项目发展与变化的各种可能性和风险，结合设计牵头EPC项目管理特点，建立初始风险因素清单。清单中应明确列出客观存在的和潜在的各种风险因素，应包括各种影响项目顺利完成和合理经济效益的因素。通过上述方法，梳理总结出设计牵头EPC项目的八大类24种风险表现形式。 — 3 — 风险的表现形式 设计牵头EPC项目的风险表现形式主要包括自然与社会风险、相关方管理风险、项目技术风险、项目商务风险、项目投标风险、项目设计风险、项目采购风险、项目施工风险等8类风险，风险的主要表现形式共有24个。 图2 风险的主要表现形式 ▌1. 自然与社会风险   一是自然灾害影响。地震、瘟疫、特大暴雨、洪水、泥石流、坍方、严寒、酷暑、多雨等对施工的影响，造成项目经济损失。 二是建设条件不足。发包人在招标阶段未提供充分的地质详勘或气象资料不完整等原因，在设计、施工中发现出入很大，导致引起工程量增加、成本超过预期。由于发包阶段没有提供社会稳定评价报告，或报告流于形式、存在明显漏洞等原因，导致项目实施引发社会风险。 三是政策变化影响。政治时局动荡、财政金融政策变化、国家及行业EPC建设政策调整、设计及施工技术规范变化等原因，都将直接或间接地影响工程的正常进行。 ▌2. 相关方管理风险 一是对发包方管理的风险。设计牵头方代表联合体与发包方直接对接，但对发包方管理能力偏弱，对发包人前期工作不足、不合理压缩工期、建设标准提高、资金不到位、工程款支付不及时、业主管理能力不足等缺少应对措施，导致总承包项目工期延误、成本增加、超发包人目标控制成本部分难以被确认。因发包人前期工作不完善，项目中标后不能及时完成征地拆迁、管线迁改工作，影响项目正常实施，造成项目履约风险和成本增加。 二是对联合体方管理的风险。设计牵头方未对联合体进行有效遴选、联合体风险责任划分不清、信誉及能力不足、双方相互融合不够等原因，造成联合体方能力偏弱，影响项目顺利实施。对联合体方关键能力管控不足，包括同类业绩和技术水平、配备人员的素质能力、合作意愿及承诺、合作保证及担保、资金实力、当地资源、风险应急预案、合作主要条件等约定不清，造成项目实施中联合体之间的纠纷。 三是对分包方管理的风险。设计牵头方对联合体的分包单位缺乏有效管理，实践中常有未经联合体共同确认的分包单位。个别分包商技术水平弱、管理水平低、诚信水平差、难以承担委托的工作，因分包商的违约造成整个工程进度拖延及其他分包商索赔。因某些供应商不满足合同要求出现交货延误、设备材料运输中损坏、供货商保函期期限不满足项目周期要求、深化设计引起额外的设备材料标准提高等，造成总承包项目成本增加。 ▌3. 项目技术风险 一是技术管理不当。设计牵头方对项目技术难度评估不足、选用的标准及规范不适用、设计图纸与技术说明不清晰，新技术应用在技术开发、技术保护、技术使用、技术取得和转让等环节失误，造成项目实施出现技术管理问题。 二是技术错误遗漏。设计牵头方在设计中出现设计内容不全或错误和遗漏、适用规范不当、未考虑可施工性、未考虑地质条件、对复杂因素考虑不周全等原因，导致施工中频繁设计变更，造成总承包项目工期拖延和成本增加。 三是技术工艺落后。设计牵头方未对施工工艺进行审核与把控，在施工中使用落后的施工工艺、不合理的施工技术和方案、施工安全措施不当、应用新技术新方案失误、施工队伍技术操作能力差等原因，造成总承包项目工期拖延和成本增加。 ▌4. 项目商务风险 一是合同管理不足。设计牵头方对工程总承包合同熟悉程度不足、合同管理经验不够，合同条款谈判时处于弱势，对重要合同条款如工期条款、质量条款、变更条款、索赔条款、价格调整条款、工程款支付结算条款、工程担保及保险条款、违约责任条款、送达信息和争议解决条款等关键内容约定出现漏洞，造成项目执行过程中履约风险。 二是成本管理失控。设计院本就不擅长成本控制，又常寄希望于施工联合体方，造成设计牵头方实质上对项目成本管理失控。在工程实施过程中缺乏对材料、设备、机械、劳务等生产资源的市场价格的充分了解及预测，造成项目采购成本增加、建设成本超过同行业平均水平，项目合理效益流失。工程索赔及变更补差的编制与谈判人员能力不够，采取的措施不科学，造成工程索赔及变更补差的失败，项目合理效益损失。 三是财税处理无依据。发包方直接向施工联合体方付款的模式，一定程度上弱化了设计牵头方的统筹管理权力，不利于设计牵头EPC项目的执行。但发包方将所有结算支付及发票取得均只对接设计牵头方的模式，又导致设计牵头方面临“四流不一致”的税务风险（主要是发票流和资金流）。在会计收入确认上，以“净额法”确认收入，其他收款部分作为“代收代付”性质的款项予以处理，这就需要相关部门尽快发布针对联合体EPC项目收入确认的会计准则解释公告，进行统一规范。 ▌5. 项目投标风险 一是投标组织不力。设计牵头方对投标工作深入程度不够，不掌握发包方信用、未实地开展调研、与联合体施工方投标策略不一致、对竞争对手实力估计不足、对竞争条件掌握不充分等，造成投标判断失误、投标难以决策、投标报价潜亏，给项目实施埋下隐患。 二是投标报价不当。设计牵头方对投标报价缺乏整体策划、成本测算偏差、对招标文件及清单图纸等研究不充分、与联合体施工方未能形成合力，若依仗设计技术优势报高价，由于价格太高无法中标，若采用施工低价投标，缺少对未来市场形势判断，项目无法合理获利。 三是投标合规问题。受市场环境影响，项目招投标中含有限制或排斥潜在投标人的内容、存在母子公司或股权关联等投标单位利害关系冲突、联合体成员方与其他投标人之间存在关联关系、高级管理人员之间存在交叉任职、人员混用或者亲属关系、经常性“抱团”投标等高风险迹象，造成项目出现与招投标法相冲突的合规性风险。 ▌6. 项目设计风险 一是缺乏设计管理。设计牵头方未充分发挥设计优势，设计范围与内容不清晰、设计依据和提供依据责任不明确、设计进度与施工需求不匹配、设计质量不高及深度不够、对项目缺乏设计现场指导、设计变更与索赔流程不严谨、设计分包责任约定不明确，施工图交底不清等，导致联合体内部配合不顺畅，影响项目实施。 二是超过限额设计。设计牵头方对在工程总承包项目中实施限额设计的目标性不强、方法不到位、限额设计目标不具体，导致难以将任务分派到专业及个人、设计过于保守、方案比选优化不充分、重复进行设备选型造成返工和浪费、未考虑全生命期经济性导致突破运营维护成本、任由使用需求和建设范围及标准在项目施工过程中不断增加等，导致后续的设计概算、施工图预算造价及施工成本出现失控。 三是与采购、施工不融合。设计指导施工缺乏细节性的深度图纸、未充分应用BIM技术进行设计深化和协同管理、设计与采购未能协同开展深度广泛的市场调研、设计接口在主要技术参数和方案形式及主材选取上缺乏一致，造成设计与采购不能有效协同，设计与施工未能充分融合，难以体现出设计牵头EPC项目的优势。 ▌7. 项目采购风险 一是难以找到优质资源。设计院普遍缺乏对供应商的市场调研，对主动找到优质、低价、信誉高的供应商的能力不足。相对于施工类项目，设计牵头EPC项目的数量偏少、体量偏小，对采购难以产生规模效应。设计院内部管理中对供应商入库的推荐、考察、选定、评标及定标常常流于形式。由于供应商资源的局限，造成设计牵头方对项目成本、品质的把控不足，降本增效的能力不够。 二是无法实现设计预采。未能利用设计牵头优势，依据合同提前确定物资设备厂家、无法在设计阶段确定设备参数并入图、未能实现在概算锁定的情况下对装饰主材和艺术装置等的采购前置，造成无法通过设计牵头管理的优势进行成本优化，项目合理效益流失。…

在IPD推行过程中，重量级团队是一个大家经常能听到的词，针对重量级团队，每个人都能说出个一二三来，但大家对重量级团队的理解好像又不能完全一致，那么是什么重量级团队呢？为什么重量级团队会成为很多企业不能承受之重呢？下面我们做一下介绍。 什么是重量级团队 一千个人眼中有一千个哈姆雷特，重量级团队虽然有一些约定俗称的理解，但至今没有一个特别权威的、能够被广为接受的定义。 2016年公布的管理科学技术名词对重量级团队的解释为：将组织中相关人员从现有部门中抽离，组建新团队、并为之创建规模较大的独立运行的具有重要使命的新组织架构的组织创新模式。 NPDP对重量级团队的解释：重量级团队(Heavyweight Team)是一支由高级专业人士组成的团队，他们在特定领域拥有广泛的经验和知识。这些团队通常由组织中的高级管理人员、专家、决策者等组成，他们的职责是在关键项目或重要决策中提供高级的专业意见和指导。与轻量级团队有所不同，重量型团队更专注于项目工作而非职能工作。由于项目经理的角色清晰，加之创新工作更为复杂，因此由项目经理正式的指导各个团队成员的工作。大多数情况下，团队领导对团队成员的绩效考核有一定的影响，但最终的工资、晋升、职业发展等取决于职能经理。 从所能查到的文献看，重量级团队的概念是由哈佛商学院教授Steven Wheelwright 和 Kim Clark于上个世纪九十年代初提出的。他们把开发项目团队划分为四种类型：职能型、轻量级、重量级、自治（老虎）团队。 职能型团队：没有跨部门的交流，经理在职能内控制资源和任务绩效，成员在其职业路径范围内工作并接受评价，成员为项目带来专业技能。因此，在职能型团队工作模式下，任务需要基于职能进行细分，成员评价与项目成败无关，在成员眼中，所有项目基本都一样。 轻量级团队：项目经理一般由组织中的初中级人员担任，项目经理和部门联络人一起工作，决定成员的任务和职责，通过更好的协调来保证项目的顺利完成，沟通更顺畅。但项目经理权力较弱，不掌握关键你资源，项目成员首先聚焦的是职能领导的安排而不是项目的任务，项⽬成员完全接受职能领导的业绩评价、培训和⽀持。当一个组织从职能型向轻量级团队转变时，需要提升沟通和协调能力。轻量级团队比较适用于需要较多沟通和协调的创新工作。 重量级团队：项目经理由经验丰富的高级人员或专家担任，项目经理直接管理并负责所有项目成员的工作安排，对团队的工作结果向高级管理层负责，团队控制关键资源，对多个职能部门有影响，直接影响核⼼成员的绩效，并通过核⼼成员间接影响外围成员的绩效，但由于项目的临时性，成员长期的职业发展还是依赖职能经理。重量级团队容易与职能组织产生冲突，并对管理人员的管控权形成挑战；可能会不由自主的拓展团队的角色和范围，蜕变为精英小组，与组织中其他人员变得疏远。重量级团队比较适合于大型的综合性项目。 自治团队：又称为老虎队，来自各职能团队的项目成员需要正式任命，是项目的专职人员，大家通过协作共同完成项目，对项目的成功与否负完全责任。项目经理对团队成员工作安排具有完全的控制权，并且是成员的唯一绩效考核人。项目团队能够更加聚焦，具有更高的自主权和创新能力。但项目的独立性会在项目结束后给项目成员返回原来的组织带来困难。自治团队比较适合于一些技术突破性项目或全新业务模式的项目。 在国外的IPD体系中，无论是早期的PRTM的PACE还是IBM的IPD，都没有特别强调重量级团队。在PACE中，主要强调了核心小组和产品审批委员会；在IBM的IPD中，描述了基于团队的管理的概念，强调了管理产品组合的IPMT以及管理项目的PDT这两个重要团队。 在国内的IPD体系中，把重量级团队看作是IPD变革成功的关键之一，认为重量级团队是指团队成员充分代表本职能部门，并贡献自己及其所属领域的专业智慧，团队负责人和成员共同拥有对团队的权利和义务。“重量级”的关键是团队负责人的权力要大于功能部门经理的权力，对于工作安排，项目经理优先于职能经理，项目经理对组员具有主要的考评权力。在华为的IPD实践中，构建了IRB/IPMT/PMT/PDT/ITMT/TMT等构成的重量级团队组织，并日渐成为诸多公司模仿的对象。 企业不能承受之重 在这些重量级团队的定义中，无论是管理科学技术名词中“创建规模较大的独立运行的具有重要使命的新组织架构的组织创新模式”描述，还是NPDP中“通常由组织中的高级管理人员、专家、决策者等组成……，更专注于项目工作而非职能工作”，还是Wheelwright 和Clark教授对重量级团队的描述“团队控制关键资源，对多个职能部门有影响，直接影响核⼼成员的绩效，并通过核⼼成员间接影响外围成员的绩效”，以及PACE和IPD中提及的“核心小组”，都在一定程度上表明了重量级团队基本上是为大企业量身定做的，对资源投入和项目组成员的能力都提出了很高的要求。 比如重量级团队的特点就是适合于大型的综合性项目，中小企业很少能支撑这种大型项目。在项目团队中之所以强调核心小组或核心成员能够充分代表本职能部门，也是因为大企业平台性组织众多，组织间隔离严重，指令效率很低，需要职能部门的全权代表加入项目，快速决策、快速解决问题。此外之所以将项目团队成员划分为核心小组与外围小组，与也是因为团队规模很大，如果全部由项目经理直接管理，项目经理肯定会不堪重负，也无法保证项目团队架构能够适应不同规模项目的要求。在重量级团队这种组织结构下，诸多成员都要求专职，项目经理、核心代表也都必须既具有很强的专业能力又具有很强的沟通协调和项目管理能力，中小企业或传统行业的大型企业的人员能力很难满足要求。对于中小企业或传统行业的大型企业，项目执行层面的团队尚且很难支撑，更不要说设置IRB、IPMT、PMT等管理组织了。 在中国，企业的行业差异很大，管理水平参差不齐，一方面是一些大型企业或行业头部企业在管理水平和人才储备上已经和国际一流企业接轨，另一方面，大部分的中小企业和传统行业的大型企业，仍然处于非正式管理或职能管理水平，向矩阵式组织转变对这些企业来讲犹如跨越天壑。在国际市场竞争日益加剧、国内市场内卷日益严重的情况下，这些处于非正式管理、职能管理水平的中小企业或传统行业的大企业，如果不进行变革很容易被淘汰，但照搬照抄大企业IPD中的重量级团队组织，又会成为企业不能承受之重。因此，不同情况下的不同企业，需要结合自己的情况来进行IPD的导入，不要抱着重量级团队不放，不要照搬照抄，每个企业都需要有自己的IPD。 寻找破解之道 企业无论是导入IPD或其他的研发管理体系，还是引入工具方法，其目的都是为了提升企业工作效率、提升创新能力、提升企业竞争力，帮助企业实现既定目标。管理无定式，但管理有模式，就如同中医看病，针对不同的病情，甚至同样病情的不同病人，诊断后开出的药方会有不同；同一位病人同一天找不同中医看病，诊断后开出的药方也可能不同。虽然药方中的取材不会超出现有药材的范畴，但药方中药材的种类、每种药材的剂量不同，就会产生不同的药效。而良医会在全面诊断、综合分析的基础上找出病根，在治疗方法上会对症下药而不拘泥。 在IPD的导入中，要以提升企业综合能力为目标，不拘泥于形式，对症下药，针对不同企业的不同情况，有针对性的对IPD进行定制，并采取不同的推进手段来保证IPD的落地。 对于企业管理基础较好、人才储备丰富、管理层容易接受新思想企业行业与IT行业类似的企业，可以借鉴华为、IBM在IPD方面推广应用的经验，采用类似的重量级团队架构。 对于管理基础较差、人才储备一般的中小企业或传统行业大型企业，从非正式或智能是管理向矩阵式管理已经是很大的挑战，肯定无法支撑重量级团队的组织结构。这时就要对工作重点放在打破部门间壁垒、简化开发流程、构建轻量级的跨部门团队上，以适应企业发展的具体需要。 此外，无论哪种企业，其IPD研发管理体系的建设都无法一步到位，需要不断的优化升级，这是IPD研发管理体系的生命力所在，也是其能够适应不同企业、不同发展阶段需要的根本。一方面是在运行实践中会不断的发现问题，就要对研发管理体系进行差缺补漏、优化升级；另一方面，企业的发展也会对研发管理体系提出新的要求，推动研发管理体系的被动更新。 总之，我们要学会对症下药、量体裁衣，而不是拘泥于形式、照搬照抄，要为每个企业打造自己的IPD。

IPD流程应用涉及很多的大企业，这些企业拥有差异性很大的多个业务，如果希望在统一的IPD框架下管理所有的业务就需要对流程进行分层管理。IPD在具体业务应用时，各开发项目差异性很大，有复杂度高、创新度高的高端新产品自主开发，也有低端产品的ODM模式开发，项目差别很大。企业在进行流程设计时肯定是以最复杂、周期最长、难度最高、包含内容最多的产品项目为依据进行的，以保证流程的覆盖性。这就会让很多项目在依照流程进行开发过程中，出现很多不必要的步骤、内容，如果照搬照抄会造成不必要的浪费，这种情况下就需要对流程进行裁剪，保证流程与项目的匹配性。 流程分层管理与流程裁剪，是保证企业内同一IPD流程对不同业务、不同项目的适用性的有效手段。 流程分层管理 大型企业往往具有差异性很大的不同业务群组。比如海尔就拥有空调、冷柜、洗衣机、冰箱等区隔特别明显的不同业务。华为的划分为了消费业务群、运营商业务群、企业业务群和云计算业务群。即使业务比较单一的联想，也划分为了PC和智能设备、数据中心、软件服务、智慧城市、智能制造几个战略群组。不同的业务群组、甚至同一业务群组内的不同产品在开发模式上都有很大的差异，不可能某个业务群或每个产品都自己建一套独立的IPD流程，这会让管理乱套的，因此企业必须想办法解决IPD在不同业务、不同产品中的适用性问题，要兼顾流程的统一性和业务的特殊性要求。 经过多年的摸索，联想通过将IPD流程内容按三层金字塔结构进行组织并分层管理解决了该问题。在具体操作上，就是将流程划分为管理层、流程层和操作层： -管理层：包含了流程概览、流程术语、培训材料三部分内容，这三部分内容由公司级流程管理团队进行管理，内容统一，以保证IPD流程的标准性、统一性。 -流程层：包含了袖珍卡、检查点流程、ODT检查表、关键检查点及ECM流程等内容，其中袖珍卡、检查点流程、ODT检查表及ECM流程与业务相关性很高，因此会由各业务单元项目管理团队负责维护管理；关键检查点设置是企业在项目管理方面多年经验的总结，是项目质量保证的重要一环，所以在公司级进行统一的设置和定义。 -操作层：流程各环节所需的模板及IPD流程执行中的具体检查点配置，此部分内容由业务单元或指定的部门进行管理，需要结合业务特点和模板所对应环节的需要进行设计。 IPD流程内容管理的三层金字塔结构，兼顾了流程的统一性及运用的灵活性。一方面，IPD流程是业内最佳实践的集成，企业必须要坚决的贯彻执行，为了便于理解、沟通、交流及推广应用，必须保证框架、术语的一致性，这样各个部门、不同项目才能基于同样的基础进行研发工作的展开，员工才能在承接不同项目时更好的发挥经验的作用，管理层才能格式化的去了解不同项目的情况并采用相同的标准进行决策；另一方面，各个业务的产品不同、客户群不同、运营模式不同……，IPD流程在操作执行层面必须结合业务进行设计，就类似于不同的人购买同一款西服需要根据身高体型差别来选择不同的型号，才能保证流程指导下研发活动的高效性。 基于项目复杂度的流程裁剪 企业在构建IPD流程时总是希望流程体系具有完整性及全覆盖性，能够适用于公司所有的项目，至少是绝大部分项目，因此，流程设计时考虑的是项目最复杂、涉及部门/岗位最多、周期最长的情况。而在实际执行中，大部分项目并没有这么复杂，需要的人员也没有那么多，周期也没有那么长，如果完全按照流程全部走一遍，会带来不必要的浪费。因此流程在具体项目应用中，需要结合项目具体情况进行裁剪，以达到兼顾质量和效率的目的。 流程的裁剪并不是简单的拿掉流程中某些步骤，而是在对项目具体情况进行分析的基础上，确定流程中哪些内容需要保留、哪些内容可裁剪、哪些内容可合并的过程。裁剪对象包括过程、活动、工具、输出材料、模板格式等。 企业为了能够针对不同项目实现流程裁剪，需要做好三方面的工作： 首先，需要定义项目类型/模式，这是流程裁剪的依据。以联想某业务为例，在项目类别上分为了两类：新品项目（类型I）和产品更新项目，前者是指现有产品系列或新系列中的全新开发的产品，后者是指衍生型号产品或对现有产品的扩展。 其次，需要定义不同项目类型、模式下各个岗位/部门的参与程度。在企业中，一个项目的完成需要多个部门的配合，并且随着产业分工的细化，每个项目都需在供应商不同程度的参与下来完成。针对项目中的诸多工作内容，哪些是企业自己来做、哪些供应商来做、哪些需要双方配合来完成、在需要配合的工作内容中、双方的参与度、职责分工如何等等，都需要明确定义，以便更好的实现项目在资源、成本以及质量等方面的管理。附图为企业不同类型项目资源投入参考表。 最后，需要给出不同项目类型和开发模式下所涉及工作内容的详细定义，针对不同的项目类型及开发模式，明确流程的细节。即明确在指定的项目类型和开发模式下，哪些开发阶段需要合并，哪些决策点需要保留，哪些步骤需要省略、合并，哪些步骤需要供应商参与等等，并基于这方面的定义，绘制特定项目类型及开发模式下的流程图概览。为了保证流程裁剪的落地，相应的内容还需要在各业务部门的子流程、检查表中体现出来，确保针对具体的项目，各部门能够正确的进行流程的裁剪。 小结 流程分层管理与流程裁剪，能够有效解决IPD在企业不同类型产品、同类产品中不同复杂度项目中的适用性问题，能够很好的兼顾IPD的统一性与不同产品业务、不同复杂度项目的特殊需求，在保证流程环境一致的情况下保证各类产品、各项目开发的高效性。

导读：迎接智能制造及大规模个性化定制带来的挑战，满足产品研发配置复杂化、开发敏捷化、响应及时化对产品数据质量的要求，本文提出了一种基于“W模型”的整车开发BOM质量数字化管控体系。 1前言 传统车企的BOM管理聚焦在生产制造启动之前，针对实际的生产订单要求核对工程BOM，并采取纠错措施，以满足生产制造的物料准备需求[1]。但生产制造启动之前的BOM管理时间节点已经很晚，对整车开发阶段工程BOM质量问题的发现滞后。 为迎接智能制造及大规模个性化定制带来的挑战，满足产品研发配置复杂化、开发敏捷化、响应及时化对产品数据质量的要求[2]，本文提出了一种基于“W模型”的整车开发BOM质量数字化管控体系。坚持质量第一、预防为主，把事后的反查转化为事前的预防，通过层层把关，减少产品数据问题、减少过程浪费，提升产品竞争力。如图1所示。 图1  面向智能制造的整车开发BOM质量数字化管控体系 图1面向智能制造的整车开发BOM质量数字化管控体系“V模型”和“W模型”最初应用于软件开发过程。如图2和图3所示。从图中可以看出：1）传统的“V模型”中仅仅把测试过程作为编码之后的一个阶段，忽视了测试对需求分析、概要设计、详细设计等的验证，如果前面设计错误，一直到验收测试后期才被发现，耗时耗力。2）而在“W模型”中，测试的活动与软件开发同步，测试的对象不仅仅是程序，还包括需求和各级设计过程——尽早发现软件缺陷可显著降低软件开发的成本。 图2  软件开发过程中的“V模型” 图3  软件开发过程中的“W模型” 本文提出，将“W模型”应用于整车开发BOM质量数字化管控体系，保证质量控制活动与整车开发过程同步进行，质量控制的对象不仅仅是各级交付物，还包括业务需求及各级输入活动。以实现质量控制活动从早期的需求阶段就已经开始，并贯穿整车开发到产品交付的全过程，提前对质量问题进行识别和解决。同时，对需求和输入活动的质量控制也有利于各业务领域及时了解项目难度和测试风险，及早制定应对措施，这将极大减少后期验证问题，加快项目的整体进度，降低项目运行成本。 “W模型”又称“双V”模型。本项目中两个“V”分别代表面向智能制造的整车开发BOM业务实现过程及质量控制过程。 第一个“V”代表整车开发BOM业务实现过程。1）左侧代表的是业务需求输入过程。从上到下依次为：整车级需求——需满足多产品规划、系列化开发，以满足用户多元化的需求；系统级需求——需面向快速设计开发，快速响应市场变化；零件级需求——零件设计变更要符合精益化原则，以尽可能少的成本，取得尽可能多的效益。2）右侧代表的是业务输出过程。从下到上依次为：零件级输出——需要保证变更和数据的紧耦合，保证变更全过程的一致性；系统级输出——需要不同的模块系列在同一产品构架下，以更高效的方式组成不同产品，满足模块化开发需求；整车级输出——需要为造车活动提供及时、准确的造车数据，满足上下游各业务链的需求。 第二个“V”代表整车开发BOM质量数字化管控过程。1）左侧代表的是针对业务需求输入而采取的质量管理策略。从上到下依次为：整车级需求质量管理策略——采用全配置化管理策略；系统级需求质量管理策略——应用模块化数据组织方式；零件级需求质量管理策略——推进全价值链变更管理一体化；2）右侧代表的是针对业务输出而采取的质量控制措施。从下到上依次为：整车级交付质量控制措施——打造智能变更管理平台；系统级交付质量控制措施——开发系统级质量校验工具；零件级交付质量控制措施——实施全生命周期数据质量管控措施。 2整车开发BOM质量数字化模型开发 为快速响应市场需求变化，保证BOM数据准确性，同时提高产品开发质量与效率，本文提出的数字化模型开发，为基于“W模型”的整车开发BOM质量数字化管控体系实施提供重要支撑。 2.1构建“动态矩阵”配置校验理论模型 “选项代码”用于描述零件或工艺在车辆上体现的特征[3]。具有相同命名或特征的一组选项代码归为一个“族”，同族之内的选项代码互斥。“族”主要可分为两类，一类是“模块”族，即每个车辆订单中必须有且只能有一个属于模块族的选项出现；另一类是“常规”组，每个车辆订单中可以有且只能有一个属于常规族的选项出现。本文提出一种核心为“动态矩阵”的产品配置数字化校验模型。其实质是通过遍历同组零件中的所有“产品选项代码”信息[4]，读取其所属的“族”信息，然后基于全部族代码，读取所有“族”中包含的全部“产品选项代码”，然后根据产品规划配置表中定义的约束关系，最后创建符合产品规划配置表中约束关系的“产品选项代码”全矩阵，并生成如图4所示。 图4  “动态矩阵”校验模型示意图 常见的产品配置问题分类，如表1所示。 表1  常见产品配置问题分类 同时，建立动态配置化管理策略，对影响问题解决的要因进行综合分析，辨识导致问题的所有原因，分析产生问题的各原因之间的相互关系[4]，从中找到根本原因，并分别采取相应的改善措施，从而形成对上游输入质量的高效检查、核对，对各环节的交付物快速质量校验及数据修正，如图5所示。 图5  动态配置化质量管理策略示意图 2.2基于大数据的“关键指标”问题分析模型 运用数据挖掘技术，企业大量数据可以被整合、使用，对整车产品数据的分析由常规分析转型为深度分析[5]，产品数据发布过程中存在的各种问题、引发因素及修正措施都可以被高效地分析并呈现出来。进一步将其模型化，形成知识沉淀，为产品、流程的优化提供决策依据，并驱动对未来数据发布策略的决策支持。 为便于对问题进行针对性地解决，基于大数据的“关键指标”分析模型将常见问题作以下分类，如表2所示。 表2基于大数据的常见产品数据质量问题分类 3整车开发BOM质量数字化管控措施 3.1采用全配置化管理策略，满足多样化需求 面向多产品规划与系列化开发，通过采用全配置化管理策略，形成丰富的产品组合来满足市场多样化需求，同时有效提升从产品规划、开发、生产到销售各个环节全业务链的集成能力，以应对更为复杂的市场变化[6]。 3.1.1整车配置描述概要 根据企业统一的产品配置策略，通过一套编码系统描述汽车技术特征及功能构成，并通过定义技术特征间的逻辑关系，建立车型与零部件的关系，这套编码系统称为“整车描述概要”。“产品选项代码”通常为3位数字或字母的组合，通过“产品选项代码”和逻辑符号的组合构建选项在车型上的分布矩阵[4]。逻辑符号及其含义如表3所示。 表3逻辑符号及其涵义 如图6示例，“A60”和“F35”分别代表了两个“产品选项代码”。其与不同逻辑符号的组合分别定义每个选项在车型上可选或者不可选的特定条件，从而以逻辑语句的形式描述了车型上主体选项与其他选项的关系。 图6  选项代码与逻辑符号所组成的逻辑语句及其表示的关系 3.1.2整车配置资源的数字化管理 采用数字化技术，实现从全局特征库创建到工程配置表解析，从超级BOM构建再到单车BOM解析全过程的数字化管理。 （1）配置特征数字化创建 整车产品特定功能、选项被称为配置特征[7]。采用规范的语法对需要管理的配置及其方案进行编码，并形成公司级产品配置编码语言，公共的产品配置编码语言能让公司各业务部门共享标准统一的配置信息，通过数字化技术将一辆整车的所有特征集合在一起并创建配置特征库。 （2）配置表数字化解析 产品配置表体现了设计意图及市场需求。通过对产品配置表的自动化解析，智能识别产品特征范围，形成产品特征清单。 （3）特征约束及使用条件数字化管理 零部件如何通过特征关系被采用到具体的整车产品型号上，则通过零部件在产品上的使用条件得以体现。采用数字化技术，基于产品型号及特征约束的配置逻辑，进行零部件使用条件的智能化管理。并可在发布之前，自动检测是否有违反约束的情况以及存在矛盾的配置信息，确保特征约束的正确性。 3.2采用模块化数据组织方式，面向快速设计开发 通过采用模块化设计理念，实现降低生产复杂度、提高方案重用率、降低研发制造成本及提高响应用户需求效率等目的[2]。模块化开发不仅需要从产品设计源头，实现内部规范参数化、系列化及外部接口的标准化，更需要从产品数据组织角度，引入模块化思想。通过模块化数据组织方式，起到促进产品模块化开发、提升各业务领域协同开发效率的作用。比如企业目前在委托外加工零件校验管理、本色件发布管理、颜色件发布及校验管理及线束零件的设计发布等方面，都采用模块化数据组织管理方式，极大提高了研发效率，如图7所示。 图7  采用模块化数据组织方式 3.3推进全价值链变更管理一体化，创建精益变更管理流程 3.3.1配置变更的协同更改管理 面向产品配置的变更是指针对项目主计划、车型配置、整车技术参数、法规要求、市场及售后策略等而进行的产品配置的变更[8]。…