IPD变革中系统工程的推行为何总是形似而神不似？

• 来源：汉捷咨询

• 编辑：汉捷咨询，商务联络请加微信（higet2004) 

IBM在给华为做IPD变革咨询的诊断过程中，通过与业界最佳企业的成功实践对比，列举了11个方面的典型问题，其中系统工程方面的问题是IBM在诊断报告中重点提及的问题，并且IBM将华为没有采用系统工程直接归结为产品开发中导致项目方向改变和产品失败的第二大原因，这也足见其重视程度！

IBM将系统工程方面的问题主要表现为以下七点：

1

硬件开发与软件开发通常彼此独立，导致在集成时需要重设计。目前在进行产品设计时不是将其作为一个整体来考虑，而是在需求和功能上将产品分成软件和硬件两个部分，从而导致设计上的不周全和重复设计，为了解决这一问题，要求在产品设计时能够从系统的角度来看整个产品开发。

2

产品设计在很大程度上只考虑产品功能，而没有考虑产品的可安装性、可服务性、可靠性、外观、环境的操作特性等其他因素，从而导致在现场发生产品问题和成本昂贵的返工。

3

在系统概念设计阶段没有充分考虑整个系统的性能和容量，导致后来为解决这些问题，频繁地对产品进行重设计。

4

系统测试没有严格的制度，且主要考虑功能测试，测试不全面，使得很多问题在实验局和后期阶段才发现。

5

没有把硬件和软件作为一个配置系统来管理，而是将它们分开考虑，导致产品版本控制出现问题，有相当多的版本及不受控的子版本到了客户手中。

6

缺乏严格的系统级文档、评审和基线控制，导致子系统的接口问题和产品需求的遗漏。目前的系统级文档不充分，没有适当的基线冻结点，在每个基线冻结点没有严格的系统级评审和更改控制。而系统级文档是评审和评估更改影响的基础。

7

缺乏系统工程制度和技能，对系统工程作为一项制度关注不够，缺乏有足够系统工程技能的人员。将系统工程制度化是实现成功开发的关键因素之一，需要制定相应的制度及培养系统工程方面的人才。在技能方面主要缺乏可靠性工程、需求工程、工艺设计、系统测试，设计规则、仿真等技能。

华为在之后的IPD变革推进过程中，对系统工程运作组织和流程体系的建设做了巨大的投入，也取得了非常明显的效果。在2005年光网络产品线的第一批IPD体系批量试点产品/技术开发项目中，系统工程作为一个打破传统的新鲜事物，特别是在软件开发体系中，不再提及软件工程，反而更多的是明确系统工程的推行，颠覆了整个研发体系的运作模式，自然的，效果也是出奇的明显，通过早期的对比图可以很明显的看出。

图表 1 推行系统工程的前后效果对比

笔者在国内很多企业调研过程中发现，绝大部分企业是没有系统工程的过程的，因此国内企业在开展IPD变革中，部分对华为研发体系运作有实际了解的企业都会强调系统工程流程的导入和推行，但是效果导入如何呢？其实很简单，那就是可以从前面的七个方面的问题来对比，除了测试，对比下系统工程的导入是否有效缓解或者解决了前面的六个问题。

应该这么说，很多企业都会感觉系统工程的活动都是在推行，除了跨部门团队运作，其他方面感觉与先前的研发模式并没有根本上的区别。

为何会有这种情况呢？笔者认为主要是如下三大方面的问题：

首先是企业高层的观念没有改变。从前面的对比图可以看到，系统工程的推行，会极大的冲击原有的研发运作模式，一改原来头(前期分析)轻脚(开发测试及试制)重的模式。这其实也是传统研发模式的弊端所造成的，并不是高层不清楚前端分析的重要性，而是需求和顶层设计工作普遍没有明确的打法，没有一套行之有效的流程体系，所以还不如尽快做出来再进行修改。如果不能给高层信心、不能改变原来的开发时间分配方式，系统工程实际上是无法得到有效推行的。

其次是导入系统工程的体系设计人员并没有相关的系统工程理论研究运作经验。系统工程虽然也是管理体系，但是系统工程是一个非常精细、而且细节内容要求非常苛刻的体系，没有相关的系统工程推行和实施经验，无法有效应对各种质疑，一旦遇到阻力就很难推进，系统工程的运作就仅仅是落在活动名称上。

最后是围绕系统系统工程运作的组织、绩效、配套支撑流程和工具体系不健全。组织和绩效不支撑横向技术拉通 运作，系统工程师人员的缺乏也是原因之一。不可忽视的是，支撑流程和工具体系的配套，对系统工程的运作也是同等重要，新的研发模式，从原来的很快就开始编码、画图改为大量的文档写作工作，管理的重心也有了显著的偏移，配置管理（含变更管理机制）、评审管理（含TR和单个文件评审）、辅助设计工具、模拟平台的缺失，极大的降低了系统工程的运作质量和效率。