Skip to content
IPD体系通过PLM系统落地方法
最近和企业IT负责人聊天，讨论到他们企业去年到今年上半年找咨询公司进行IPD咨询，但目前除了交付一大堆模板和流程，建立了虚拟组织对产品开发过程评审外，好像并没有什么效果，曾经尝试过在PLM落地，但除了文档管理在PLM落地外，其余的没有任何改变；他知道我以前曾经在多家企业实施或协助企业梳理过IPD落地PLM的规划服务，因此我们进行了很长时间的沟通，讨论IPD咨询和交付与PLM落地之间的鸿沟，以及如何确保落地的措施，
企业实施IPD失败原因分析
伴随着华为在IPD导入成功，最近几年大量企业，包括电子高科技企业，以及传统的设备等企业都在导入IPD，但是大量都失败了，或者比葫芦画瓢，最终学的流程和效率越来越低，但实际的改善并不大，总之，IPD的失败率比PLM/PDM导入还要高很多；那么为什么会这么多企业导入IPD会失败，企业在导入IPD时，应该有哪些注意事项？在本章节会进行一个概要的分析，并且在后续方案和建议中，也将更多教训融入到IPD咨询和PLM落地建设中。
认为IPD体系建设就是招聘几个具有IPD背景的职业经理人或者聘请了具有IPD经验高管的咨询团队，把流程建设起来，就能一蹴而就，脱胎换骨，成为行业标杆，没有认识和理解清楚，IPD流程体系是企业经营管理和产品研发的方法论，采用这个系统、科学、有效的方法论，去建设符合企业具体实际的表单、模板、流程、制度；如果仅仅是有IPD的工作背景和实施经历，并没有吃透弄懂IPD流程体系建设的方法论的人，在完全不同的企业生态环境下，搭建IPD流程体系，近乎刻舟求剑；同时，在具体环境下，一个人的工作可以做得很好，换一个IPD环境后，若缺少合理性和与行业的融入，并非工作也可以做得像在华为等IPD成功的公司一样出色、高产，也有南橘北枳的道理；自己的工作可以做得很好，指导其他同事把工作做得更好，那也是另外维度和层面的事情，职业经理人与咨询顾问老师的素质、素养、知识结构、学习能力等要求也是大不一样的，完全不在一个层级或者纬度，企业的IPD流程体系建设工作，绝非易事，要找到合适的咨询团队，授之以鱼，解决当前问题；授之以渔，掌握企业组织体系变革的方法论，并持续优化改进。
拿着华为的，或者顾问提供的模板，按照“先僵化、后优化、再固化”说辞，进行IPD流程体系建设，华为IPD 体系推进成功的经验仅仅适用于彼时彼景的华为公司，并非适合于此时此景的所有行业和企业，需要活学活用，关键是华为的IPD流程体系，也并非照抄照搬IBM的IPD流程体系，也是定制了华为的行业和产品特色的华为IPD流程体系(应该不同企业有不同的IPD落地方法)；同时，也不是冒然全盘IPD化，毕竟华为也是先在无线、核心网等产品线的部分项目上试点后再逐步推行，同时，持续优化改进后，逐步扩大范围，最后，才进入终端消费者产品线、企业产品线，华为公司也是依赖于可复制的IPD流程体系，取得了今天的辉煌成就。
- 企业团队对参与IPD体系建设工作参与度、支持度不够
很多企业仅是企业高层了解一点IPD的收益，就在高层授意下，要求信息部门或者研发部门开始导入IPD；这种企业无法导入IPD，因为企业高层、中层、基层团队没有了解IPD，以及IPD如何提升企业的价值，存在大量认知偏差，没有取得集体共识，没有同频，难以共振，高层决策者希望搞的，中层管理者基于职能部门既得利益，认为不好搞，难推行；中层管理者认为有必要搞的，基层执行者嫌弃麻烦，太繁琐，影响工作效率(推广到最后，就是大量增加文档工作，大量增加评审工作，是否必要，如何精简倒是次要的)；咨询顾问实践能力欠佳，方法论不得当，导致企业团队上上下下没有取得共识，力出一孔、利出一孔。
很多企业启动IPD咨询项目时，心浮气躁、急功近利，总想操近道，快餐式，简单粗暴地应用华为IPD流程的表单模板，希望可以在一两年的时间内就导入大量IPD的功能和支撑的IT系统；这种没有把IPD 流程体系的精髓学到手，仅参考别的公司表单、模板、流程、制度是基于别的公司的组织架构、部门与岗位职责等要求，是对参考公司企业经营管理的业务价值流的逻辑呈现，是一种镜像反馈的关系，具体企业所用到的表单、模板、流程、制度，是参考公司在某一个发展阶段，针对参考公司当时的现状、问题、诉求，持续以优化改进某些问题，应运而生的；所以必须经过持续的学习和思考，对IPD的框架、原理、运作方式等充分理解和探讨，企业内部进行充分的适应性研讨，评估是否适用于具体企业自身的当前阶段的实际现状与问题，是否满足具体企业自身的管理诉求，需要严谨地审视、适配和调整。
IPD要求的企业组织体系的变革相当于上层建筑，属于公司治理层面的工作，总想着别的公司能，你也行，过于理想化，忽略了企业的经营基础，没有结合企业实际业务发展的现状与问题，没有明确的目标，没有清晰的原则，导致企业的上层建筑的治理与企业的底层经营基础脱离，形成“两层皮“，仅仅是走了一个形式而已；IPD流程体系建设需要与企业使命愿景价值观，经营管理的问题和目标为导向，相互结合，相辅相成，就如干革命，脱产干革命，革命干成了，生产打粮食就不会了，不搞IPD，企业还可以继续经营；搞了IPD，一切都乱套，导致企业经营运转不起，最后，不了了之，或者一了百了，全盘否定，一日回到革命前。
即使是咨询是成功的，但不代表可以支撑企业的研发转型，针对IPD在企业IT系统中的落地，也存在一些挑战，包括：
- 产品公共模块建设难以落地
- 基于产品平台开发产品是IPD的核心战略，但对于产品平台的和系列化产品的管理IPD并没有直接的支持能力
- IPD可以实现流程的重用，但是对产品和技术文档的重用并不提供直接支持
- 组织的建立没有发挥作为
- 项目管理中虽然规定了矩阵式的管理机制，但现实中职能部门控制着大权，项目在执行的时候还是弱矩阵管理模式，当然这也是和绩效的权重分配有一定关系
- 数据管理混乱，物料重复创建
- 开发人员缺乏一个可以集中查询数据的平台，有的时候宁愿新建，也不愿意重用已有的物料，造成物料的重复创建，给下游的采购，生产带来大量的工作，也造成产量开发周期的延长
- 绩效考核缺乏可见性
- 缺乏可见性，无法直观获得产品组合情况和投资情况
- 绩效考核的量化指标无法获得项目实际的表现情况
- 大量的报表需要人为的整理，耗费不必要的时间
- 缺乏集成与信息共享
- IPD中提到的一些重要工具，但因研发数据源头PLM未很好管理起研发核心数据例如BOM、模型、图纸等，造成后端信息系统需要保留大量数据录入接口，形成数据孤岛，导致数据出错概率高
因此IPD的落地，以对标企业华为为例，实际上有自己独特的特点和方法论，或者使用应用“从实际出发，实事求是”的思考出发点，持续改进和提升；华为IPD的成功的因素包括：
-
- 不可一蹴而就，经过长达10多年的IPD平台持续建设和完善，仅IPD变革就投资超过5亿人民币
- 一把手工程，关键领导需要冲在第一线，主导IPD的变革实施，有决心砍掉对变革挡路的中层
- 引入上百个IBM专家之后，相关的咨询顾问没有间断过
- 永远有华为自己人对接外部专家，从而将能力长在自己的组织里
- 先学习IBM和全球最佳产品开发实践(僵化)，然后再根据运行情况持续进行改造(优化) ，打造华为IPD模式(固化)
- IPD的支撑IT工具是为人效服务的，因此允许探索和迭代，定周期的总结，形成企业的规范并落地IT系统(固化)；关注成功，但允许失败(关于IT与人效的提升，)
- 将多种开发模式与IPD的持续融合，在IPD框架中，融合众多支撑产品开发的工具，例如需求价值工程、QFD、敏捷、Devops等
IPD落地IT咨询方法论
IPD的管理框架，给企业提供了一整套顶层产品开发管理策略，但是在进行落地，尤其是融入到产品开发过程中，并通过IT系统进行支撑时，就需要对IPD的流程进行分解，一直到可执行的业务步骤，这种业务步骤有单一来源的数据支持，并且这些数据由单一的决策进行定义和维护；因此我在协助企业梳理IPD落地时，就会按照4A框架的思想，采用结构化的思维进行业务分析——这个思路框架很重用，后面的大量工作就是参考这个框架图展开的
按照对企业EA架构的设计原则，IPD的落地其实也必须紧密拥抱企业的战略和愿景，并且按照企业整体信息化和数字化转型的原则，定义业务规范和数据标准，并且融入组织变革和提升的措施，充分发挥资源的最大效能；在这个设计过程中，不仅要充分关心业务架构，而且要关注支撑数据的规范与标准，在此基础上探讨可行的支撑技术，然后将这些原则全部融入到企业定义的具体支撑开发操作的应用中(下图是参考这种思路，梳理的一个企业的架构)。
在IPD落地时，必须结合顶层的框架(例如企业的L3/L4层级业务流程)，对产品开发活动进行进一步梳理，一致到子活动，若是不满足IT系统执行规则可以进行持续分解，一直到IT系统可充分落地的细节；当然这个也不是固定不变的，随着企业IT支撑能力的提升，可以将大量的支撑IT建立成为公共应用组件，那么在定义IT落地的架构图时就可以进行简化；总之，IPD的落地有完整的实施方法论，企业在进行落地时，可按照顾问的方法论进行企业业务梳理、数据定义、技术要求、IT能力支撑等多方面的多维度的评估，最后选择质量、范围、成本、技术都满足要求的实施方案(并非各方面都最优的解决方案)。
IPD落地时，需与公司的高层进行充分的沟通，结合企业的产品开发战略目标：以产品竞争力和研发效率为主轴，技术开发和重用为控制点、提升人效和TPM绩效评价为牵引，补短板、锻长板、平台化、集成化为核心策略，支撑公司的业务战略意图达成。因此，在落地时也应该关注效率提升、质量提升，识别技术特点，发挥优势补充短板，通过TPM的牵引评估落地的质量以及与目标的差异。当企业短期和中长期痛点和目标不一样时，实施时可采取差异化的策略，确保IT落地是优先解决企业的痛点，而不是一些仅仅面子上的高大上。
在进行IPD的业务流程框架分解和数据标准定义过程中，始终要拥抱数据定义的规则，以及“业务+数据”支撑的IPD一致性和业务成熟度、能力等级的评估，并建立专门的自上而下的综合团队，定期对应用效果进行评估，才能获得更好的促进产品开发效果，才能实现IT工具为产品开发赋能，助理产品开发的目标。
使用TPM的Metrics评估和持续迭代
因为IPD的复杂性，因此企业很难一蹴而就，因此在IPD的活动分解过程中可能会出现不同能力等级的实现要求，为了协助企业定义合理的IPD落地目标，并在在推进过程中准确的评估实现偏差，确保IPD推进过程的整体能力一致性；同时还为了针对不同组织识别IPD的推进能力和与其他组织的偏差，必须有合理的度量标准与规范。所以，TPM伴随IPD同步实施，TPM评估可以量化IPD的推进，用数据来评价IPD的实施效果，是常用的一种评估方法。缺少评价就会缺少监督、量化、考核和提升，参考SMART原则中定义具体推动的工作。
通过TPM的实施，主要目标：
-
- 定义不同阶段指标，并开展TPM评估：根据IPD推进的业务范围、功能范围和数据范围定义不同的指标，并在IPD推进过程中持续监控，控制偏离(对改进点追踪)
- 以结果/目标为导向的管理理念：指标要从仅关注IPD流程到关注过程质量逐步深入，同时加强重量级业务团队运作管理，使各领域的目标得到统一
- 引入IPD优秀实践：关注产品开发效率提升和质量提升的方法，并融合到IPD活动的操作步骤中
- 加强职能部门在IPD变革中的职责：管理层设置改进指标和计划，通过KPI或OKR管理推动
针对TPM的评估标准，行业已经有比较通用的共识，可以在企业项目落地实施中，参考行业常用规范进行修订，输出企业的TPM规则(删减了部分内容，但大家可参考这种框架，定义企业的TPM标准)。
|
试点级
0-1.0 |
推行级
1.1-2.0 |
功能级
2.1-3.0 |
集成级
3.1-4.0 |
世界级
4.1-5.0 |
| 变革程度 |
试点运作 |
正在推行(>20%) |
继续推行(>60%) |
推行工作完成(>80%) |
完成推行(100%) |
| 结果衡量标准 |
衡量标准不明确 |
明确衡量指标 |
在关键的衡量指标上取得改进效果 |
在关键的衡量指标上取得重大改进效果 |
在关键的衡量指标上达到业界最佳绩效 |
| 业务结果 |
市场与研发对接存在断点 |
从局部，个别单元开始试点 |
已经获得可复制的成功经验 |
持续成功 |
实现持续改进 |
| 能力要求 |
开始变革行为 |
完成流程设计和团队建设，进行试点 |
流程在多数产品线得到应用 |
流程在公司得到应用 |
持续优化 |
但针对具体某一场景和步骤的能力如何更细致的评估判断是否负责管理标准和要求，IPD并没有给出很好的定义，因此我在企业咨询时，融入了CMMI的能力评估模型和ASPICE的能力评估模型中针对企业产品开发等级的定义(将不同行业的内容融合，相互参考应用，。
参考能力等级模型，在评估，对IPD落地的功能进行分数评估，将指标量化(除了基本的分数，在评估落地方案中，若包含增加效率、提升质量和降本成本的措施，还有专门的增值评估，鼓励企业深入探索数字化转型和IT能力对业务的提升方法)。
Go to Top
