IBM在給華為做IPD變革咨詢的診斷過程中，通過與業界最佳企業的成功實踐對比，列舉了11個方面的典型問題，其中系統工程方面的問題是IBM在診斷報告中重點提及的問題，并且IBM將華為沒有采用系統工程直接歸結為產品開發中導致項目方向改變和產品失敗的第二大原因，這也足見其重視程度！
IBM將系統工程方面的問題主要表現為以下七點：
1、硬件開發與軟件開發通常彼此獨立，導致在集成時需要重設計。目前在進行產品設計時不是將其作為一個整體來考慮，而是在需求和功能上將產品分成軟件和硬件兩個部分，從而導致設計上的不周全和重復設計，為了解決這一問題，要求在產品設計時能夠從系統的角度來看整個產品開發。
2、產品設計在很大程度上只考慮產品功能，而沒有考慮產品的可安裝性、可服務性、可靠性、外觀、環境的操作特性等其他因素，從而導致在現場發生產品問題和成本昂貴的返工。
3、在系統概念設計階段沒有充分考慮整個系統的性能和容量，導致后來為解決這些問題，頻繁地對產品進行重設計。
4、系統測試沒有嚴格的制度，且主要考慮功能測試，測試不全面，使得很多問題在實驗局和后期階段才發現。
5、沒有把硬件和軟件作為一個配置系統來管理，而是將它們分開考慮，導致產品版本控制出現問題，有相當多的版本及不受控的子版本到了客戶手中。
6、缺乏嚴格的系統級文檔、評審和基線控制，導致子系統的接口問題和產品需求的遺漏。目前的系統級文檔不充分，沒有適當的基線凍結點，在每個基線凍結點沒有嚴格的系統級評審和更改控制。而系統級文檔是評審和評估更改影響的基礎。
7、缺乏系統工程制度和技能，對系統工程作為一項制度關注不夠，缺乏有足夠系統工程技能的人員。將系統工程制度化是實現成功開發的關鍵因素之一，需要制定相應的制度及培養系統工程方面的人才。在技能方面主要缺乏可靠性工程、需求工程、工藝設計、系統測試，設計規則、仿真等技能。
華為在之后的IPD變革推進過程中，對系統工程運作組織和流程體系的建設做了巨大的投入，也取得了非常明顯的效果。在2005年光網絡產品線的第一批IPD體系批量試點產品/技術開發項目中，系統工程作為一個打破傳統的新鮮事物，特別是在軟件開發體系中，不再提及軟件工程，反而更多的是明確系統工程的推行，顛覆了整個研發體系的運作模式，自然的，效果也是出奇的明顯，通過早期的對比圖可以很明顯的看出。
筆者在國內很多企業調研過程中發現，絕大部分企業是沒有系統工程的過程的，因此國內企業在開展IPD變革中，部分對華為研發體系運作有實際了解的企業都會強調系統工程流程的導入和推行，但是效果導入如何呢？其實很簡單，那就是可以從前面的七個方面的問題來對比，除了測試，對比下系統工程的導入是否有效緩解或者解決了前面的六個問題。
應該這么說，很多企業都會感覺系統工程的活動都是在推行，除了跨部門團隊運作，其他方面感覺與先前的研發模式并沒有根本上的區別。
為何會有這種情況呢？筆者認為主要是如下三大方面的問題：
首先是企業高層的觀念沒有改變。從前面的對比圖可以看到，系統工程的推行，會極大的沖擊原有的研發運作模式，一改原來頭(前期分析)輕腳(開發測試及試制)重的模式。這其實也是傳統研發模式的弊端所造成的，并不是高層不清楚前端分析的重要性，而是需求和頂層設計工作普遍沒有明確的打法，沒有一套行之有效的流程體系，所以還不如盡快做出來再進行修改。如果不能給高層信心、不能改變原來的開發時間分配方式，系統工程實際上是無法得到有效推行的。
其次是導入系統工程的體系設計人員并沒有相關的系統工程理論研究運作經驗。系統工程雖然也是管理體系，但是系統工程是一個非常精細、而且細節內容要求非常苛刻的體系，沒有相關的系統工程推行和實施經驗，無法有效應對各種質疑，一旦遇到阻力就很難推進，系統工程的運作就僅僅是落在活動名稱上。
最后是圍繞系統系統工程運作的組織、績效、配套支撐流程和工具體系不健全。組織和績效不支撐橫向技術拉通 運作，系統工程師人員的缺乏也是原因之一。不可忽視的是，支撐流程和工具體系的配套，對系統工程的運作也是同等重要，新的研發模式，從原來的很快就開始編碼、畫圖改為大量的文檔寫作工作，管理的重心也有了顯著的偏移，配置管理（含變更管理機制）、評審管理（含TR和單個文件評審）、輔助設計工具、模擬平臺的缺失，極大的降低了系統工程的運作質量和效率。
來源：漢捷咨詢
【相關文章】
·IPD推行的三大典型怪狀
·打造IPD產品研發及經營管理體系
·IPD是中國藥企變革生存的唯一出路
·企業如何科學推進IPD、LTC、ITR等流程管理變革
您的位置：
