引言：PACE在產品開發過程中的應用和擴充套件是一種實實在在的挑戰，而那些成功運用PACE方法論和工具的企業也必將從這種挑戰中得到顯著的回報。

PACE（Product And Cycle-time Excellence，產品及週期最佳化法）是美國管理諮詢公司PRTM於1986年提出的。經過多年的改進和完善，PACE已經成為產品開發事實上的標準過程參考模型，包括IBM、Motorola、杜邦、華為等在內的許多公司已把PACE的各種理念方法付諸實施。

產品開發流程的七要素

產品開發流程可以分為七個相關要素，每一個要素都有其常見的不足之處。PACE提供了各種方法、技巧和手段，以克服每一個要素的不足之處。下文對這七個相關要素作了介紹，對一些常見的不足之處進行了總結，並針對每一個要素簡單介紹了PACE的解決辦法。在以後的章節裡，將進一步詳述PACE的每一個要素。

1、決策

所有的公司都有一個新產品決策流程，儘管他們有可能並沒有認識到這是一個有明確定義的流程。在決策流程薄弱的公司，因優柔寡斷造成的延誤很普遍。例如，如果某個實際流程是順序性的，要求許多經理一一確認某產品設計概念的優劣，那麼，起動就會延誤。我們看到，許多良機的錯失只是因為產品先驅們不知道如何運用這種不正規的決策流程。

我們曾經幫助過的一家電腦公司有一個效率低下的決策流程，可以說它是我們所見過的許多流程當中的典型。在這家公司裡，專案評審已淪為一系列面向不同聽眾的冗長的彙報。參加的人很多，提出的問題也很多，但這些彙報會並不是決策會議。評審並沒有在開發流程的適當時機進行以促使決策，合適的資訊也沒有提供出來以推動決策。高層管理人員迴避了評審，並且沒有其他機制來推動適時決策。

然而，並非所有明確定義的決策流程都是有效的。有些流程要麼設計得很糟糕，要麼實施不當。在這些情況下，一個正正規規的流程實際上對產品開發構成了管理障礙。花費大量時間，卻收效甚微，這樣的決策流程早已不能推進產品開發。

在產品開發評審中，我們發現因決策流程不當會引發下列問題：
·由於高層管理人員不知道應該由誰來作出決策，或者需要什麼樣的一致意見，所以他無意識的延遲決策或修訂決策。
·資訊不夠充分或細節不清楚導致決策質量低劣。
·沒有及時解答疑問。
·未定義決策控制點，以至在適當的重要階段又出現了評審工作。
·需要投入的資源過多，以至無法按期完成任何事情。
·授權審批和設定優先順序的人沒有明確批准給予產品開發專案的撥付資金。
·決策太遲——經常是在產品已經設計出來之後。
·沒有用週期指導來證實專案進度。
·高層領導沒有作出戰略決策，卻由開發人員在無奈中作出這種決策。

在PACE流程中，新產品決策是透過階段評審流程進行的，這種階段評審需要在開發流程中具體定義的點上作出決策。一個產品開發專案必須在預定時間內達到明確定義的目標，才能獲准進入下一階段。

產品審批委員會（Product Approval Committee, PAC）是指在一個部門或一個公司內負責主要新產品決策的高層領導小組。PAC有權在開發週期內的具體決策點透過給新產品撥付資金或修改新產品的途徑來批准或拒絕新產品。PAC負責透過產品開發活動實施公司的戰略，因此，他們具有資源分配權，以推進新產品的開發。

PAC一般透過階段評審流程來作出決策和進行資源分配。沒有這樣一個流程，高層領導就難以有效地引導新產品的開發。然而，只有一個評審流程（或類似的一個流程，如把關流程或階段開發流程）是不夠的。定義不清、實施不當或與開發流程中的其他必要要素不協調，都可能使評審流程效率低下。

階段評審流程在產品開發中還扮演著另一個重要角色。透過它，PAC可以直接明瞭地授權專案小組分階段地開發產品。專案小組為產品制定詳細的建議，提交產品開發計劃，並申請下一階段所需的資源。如果PAC批准工作小組的各項建議，它會賦予專案小組以權力、責任以及實施小組計劃的下一階段所需要的資源。

2、專案小組構成

在評審中我們發現，儘管大多數公司有正規的專案小組，但多數並不成功。總的來說，由於這些專案小組的構成、角色和責任沒有明確的定義，結果使溝通、協調和決策效率低下、紛繁混亂。

有這麼一家很典型的公司，不計其數的經理們只在他們有空的時候或是有什麼特別原因使會議變得最優先的時候，他們才參加產品開發小組的會議。由於這種方法產生的效果差，所以公司曾嘗試用不同的方法來改變這種狀況。他們建立了專門的專案管理部門，負責監督進度和任務的提交，以明確由誰去做什麼以及事情做了沒有。後來，每個部門都給每一個主要專案指定了自己部門的專案經理。但這些方法效果並不理想，只是增加了毫無價值的勞動，而這種勞動已經太多了。
許多公司建立了專案小組的組織形式，但大多數效果不佳。針對這些不成功的案例，我們發現以下典型原因：

·如果專案小組和職能部門的責權不明確，將造成困惑。
·專案小組沒有得到明確授權去實現目標，因而效率低下；在某些情況下，他們只被賦予了責任，卻沒有相應的權力和資源。
·缺乏並行工程，一些職能和技能無法和諧地融入到專案小組中去。
·專案領導工作效率低，這源於幾個因素：專案領導人沒有經驗；對專案領導人角色不明確；培訓不足；專案領導人更換頻繁；或者專案小組的組織有缺陷。
·專案小組缺乏專案實施所需的人手和技能，因而無法實現目標；各種資源在專案小組間調來調去，缺乏明確的決定。
·由於沒有明確定義專案小組和職能部門之間的協作方法，兩者之間便有衝突和困擾。
·小組成員任務分配造成的困擾使整個小組效率低下：比如說，小組成員把自己看作職能部門的評估者或記錄者，而非真正地幫助進行實時決策。

專案小組構成是產品開發流程的一個關鍵要素。一個高效的專案小組能極大地增進溝通、協作和決策。在評審初期，我們就發現許多廣為接受的專案小組模式效率低下，而低下的原因與上文所述頗為相似。我們開發了一個新的模式。這個模式既能發揮專案小組這種組織形式的最佳方面，又能克服上述缺陷。我們把它稱之為專案小組構成中的核心小組模式（Core Team Approach）。

核心小組是有權開發特定產品的一個小型跨部門專案小組。一個典型的核心小組有5—8名成員，有權力也有責任管理所有與開發該特定產品相關的任務。這些特定任務分配到核心小組的每個成員身上，每個成員都利用相應資源完成這些任務。小組成員們為指定給他們的工作確定方向，與職能部門打交道，並作為核心小組的一員參與集體決策。PAC則在開發工作的每一階段透過階段評審流程賦予核心小組責任和權力。每個核心小組都有一個指導和引導小組工作的領導人。該小組在執行每一開發階段時遵守與PAC簽定的有關重大專案目標以及可變動的範圍的“合同”。

3、開發活動的結構

開發活動是開發新產品的實質性工作。在PACE中，結構化的開發流程明確了應做什麼開發工作、相應的先後次序、其間的關聯性以及用於開發專案的標準術語。在評審流程中，我們發現，開發活動的結構中往往存在三類普遍的缺陷：(1)沒有任何明確的產品開發結構的公司；(2)有具體流程手冊但並沒得到遵循的公司；(3)有結構化的流程但並不能改進或加快開發進度的公司。

對第一種情況來說，公司必須在產品開發流程中不斷地“重新發明車輪”，即重新定義產品開發流程。每一個專案小組都定義其要遵循的流程，結果，每個專案小組即使在執行相同的或相似的任務時，開發流程也迥然不同。這種模式延長了開發週期，且整個公司的專案小組都易犯同樣的錯誤。

對第二種情況來說，流程被文件化了，但是並沒有得到執行。典型的情況是，某個職員在程式手冊裡定義開發流程，然後把手冊散發出去，天真地期待每個人都會遵守它，結果當然是他們並不遵守。多數情況下，他們不遵守反而好一點。專案小組又各自將自己的那一套流程搬了出來。

對第三種情況來說，開發流程已得到明確和遵守，可惜這個流程天生就效率低下。令人吃驚的是，許多公司在規範流程時，只是簡單地將他們現有的做法寫成檔案，哪怕這個流程效率低下，其結果自然是把問題制度化了。

在評審開發流程時，我們發現普遍存在下列缺陷：
·無章可循的開發活動導致產品不斷更新。
·由於對必須完成什麼樣的開發活動及何時完成有誤解，因而造成專案計劃不周及準備不足。
·缺乏通用術語以及由此引起的理解問題，導致開發工作不理想。
·產品開發定義過於詳細，尤其是缺乏結構化的定義，使得開發效率不高。
·每一步都需要多個簽字蓋章的官僚流程延緩了開發工作。
·缺乏並行工程，因為它沒有被設計到結構化開發流程裡。
·缺乏開發活動的週期時間指導，導致專案進度不準確。
·由於沒有將責任落實下來，導致未能不斷地改進產品開發流程。

在PACE方法中，核心小組用結構化開發流程開發產品，這將確保一致性，並避免小組創立各自的流程。基於一個通用的結構化流程，就可以使用通用的週期時間指南併為持續改進打下基礎。

按照PACE的方法，一個結構化開發流程包括幾個等級。在階段評審流程所提供的框架中，一般有15—20個主要步驟來定義一個公司的產品開發流程；每一步又分成10—30項任務，規定每一個步驟如何在公司裡得以實施。這些任務又為每一個步驟定義出標準週期時間，因此可以根據這些基本步驟編制進度表、預估資源需求、制定計劃及進行管理。

每一項任務還可進一步細分成各種各樣的開發活動。根據任務的性質，每一步驟的開發活動數量從幾個到30或40個不等。總的來說，各步驟與任務永遠適用於各種專案，而開發活動則因專案不同而不同。

4、開發工具與技術

各種設計技術，例如質量功能配置（quality function deployment, QFD）、裝配設計（design for assembly, DFA）和可製造性設計（design for manufacturability, DFM），能促進產品成功並達到相應的執行效果。然而，這些技術中沒有哪一個能單獨地解決產品開發中的所有問題。

舉例來說，一個規模宏大、部門眾多的高科技公司選擇QFD作為其最終的解決方案。公司投入巨資來培訓全公司人員的設計技術，並培養了內部QFD專家和顧問，進行相應的宣講介紹。9個月後，產品開發仍不見起色，專案小組也就解散了。由此，QFD技術受到不公正的指責，這只是因為人們期望有一項技術能彌補整體綜合方案的缺乏。

在過去的5—10年中，許多新型自動設計工具已被開發出來，它們可以極大地輔助產品開發流程。這些工具包括計算機輔助工程（CAE）、物件導向的軟體開發工具、產品資料管理系統、模擬工具以及用於專案計劃、進度和決策的工具。同樣，沒有單獨的一種工具能提供一個完整的解決辦法。每種工具都可以更大地提高工作流程的生產率，但所有的工具都需要一個結構化的流程，這是一個先決條件。

至於這些工具和技術的使用，我們發現，許多公司犯著這樣或那樣的錯誤：要麼是沒有使用正確的方法或工具，要麼是使用效率不高，這些都是因為他們缺乏整體產品開發流程。特別是，下列問題比較普遍：

·設計技術效率低下，因為不能很好地融入清晰的產品開發流程。
·人們期望某一種設計技術，如QFD，能解決所有產品開發問題。
·因為沒有使用恰當的設計技術，造成新型產品不可製造或不耐用。
·因為沒有使用自動化工具，導致產品開發時間比應花的時間要長。
·因為產品定義不斷變更，導致自動開發工具沒有產生預期的效果。

PACE流程沒有給新技術或新工具下定義，其關注的焦點是在整體產品開發流程這個環境中，適時地運用合適的技術或工具。PACE描述了一系列技術設計和自動開發工具，並表明了它們是怎樣適用於該流程的。

5、產品戰略流程

產品戰略是新產品開發的起點。透過產品戰略，公司定義了要開發的產品的型別、如何區分自己與競爭對手的產品、如何將新技術引入新產品以及開發新產品的優先順序。

選擇開發的產品應與整個產品戰略保持一致，但情況往往不是這樣。產品戰略常常沒有被定義或表述清楚，即使在公司內部組織過非正式的討論。如果沒有一個清楚的產品戰略，開發人員在提議新產品及執行開發專案時就必須進行猜測，他們往往是透過反覆試驗才得知哪些合適，哪些不合適。

有時產品戰略與開發專案相離太遠，以至於前者僅是一紙厚望，對於實際選擇的專案沒有任何作用。有一家公司，壓倒一切的戰略目標就是去開發多種新產品。當再無其他指導，或在缺乏產品思想的評估框架和優先順序的設立框架的情況下，許多專案是根據開發人員個人或經理們的提議下啟動的。儘管有的取得了技術上的成功，但這些專案中的大多數永遠不可能完成，或永遠不能商品化。該公司的CEO告訴我們說，“如果我早知道他們都在做些什麼，我會盡早制止他們。他們的大多數專案與我們的戰略並不一致。”

我們的經驗表明，產品戰略制定和交流的常見不足之處如下：
·公司將眼光過分集中於個體產品，而對產品平臺的重視不夠。
·公司裡沒有人明確負責產品戰略。
·既然產品戰略沒有一個正式流程，它往往成為年度預算流程中的一項表面工作。
·由於公司不能有效地評估其產品戰略機遇，開發出了平庸的產品。
·產品戰略過時，原因是將眼光集中在當前而非將來顧客的需要和市場潮流上。
·由於產品戰略是內部驅動而非客戶驅動，因而造成產品不具競爭力，競爭性分析膚淺，競爭定位不明確。
·由於沒有產品戰略願景來指導專案開發工作人員，所以實際產品開發與初衷不符。

與盛行的信念相反，最佳產品戰略並非來自於令人眩目的革新念頭，也不是從數百張充滿圖表的市場分析報告中得來。例如，數字裝置公司只用三頁紙定義未來VAX平臺，這就概述了計算機歷史上最成功的產品戰略之一。有效的產品戰略來自於一個嚴格的產品計劃定義流程，這些產品計劃的制定依據是對市場交替變化、技術進步和競爭態勢所帶來的機遇的理解。

在PACE內，產品戰略提供了一個框架，供PAC在階段評審流程中決策和設立優先順序之用，並同時為核心小組確立了指南，供其定義產品時使用。產品戰略包括明確定義了擴充套件現有產品線和創造新產品線的機遇。

儘管每個公司都有自己的商業戰略做法、機構建設、產業及競爭地位等，從而使得具體的產品戰略因公司的不同而有所不同，但產品戰略仍可作為一個流程來管理。PACE產品戰略要素對這一流程進行了定義。

6、技術管理

技術管理是整個產品開發流程的一個組成部分，技術管理的作用是發現應用新技術的機會，並且啟動技術開發專案，從而擴大公司的核心競爭力，並使多種產品受益。

我們已經覺察到，一些技術型公司並沒有積極管理他們潛在的技術。一些公司過於將注意力放在產品開發上，以至於最後他們只把技術開發當作產品開發工作中的一個次要專案。我們也曾看到一些面臨困境的開發專案，跌入技術難題之中，原因在於公司沒有意識到他們缺乏開發那些產品所需要的最基本的技術知識。

產品開發依賴於技術，無論這技術是內部開發的，還是別人許可使用的，或是從公司外部獲得的。要想及時地利用那些可用的技術，就必須瞭解當前和未來的核心技術，因為技術的開發和技術聯盟的建立需要時間。要達到這一點，不應強行要求正在搞產品開發的專案小組去創造或獲取這些必要的核心技術。專案開發的風險大小是由其不可避免的、最具風險的因素決定的。假如該因素是核心技術開發，則其不確定性和潛在的延誤是不可估量的。

例如，某家公司不懂技術管理，它的研發部門致力於各種技術的開發，其有用期“從現在起持續3—10年”。然而，大多數這樣的研發工作沒有充分利用公司現有的技術基礎。結果，他的核心技術到期後沒有其他的核心技術來替代。研發經費的短缺使得一些關乎產品線的核心技術過時了，面對市場份額的節節丟失，公司不得不大量投資以便迎頭趕上。

在評審產品開發的流程中，我們發現了以下常見的技術管理上的缺陷：
·由於技術上出現的意外，使產品開發延遲。如果當初技術準備充分，這些意外本來是可以避免的。
·由於公司沒有給現在或將來的核心技術進行投資而導致技術效能下降。
·由於技術開發沒有從產品開發中脫離出來，造成了不必要的開發週期延長。
·由於對技術風險控制不足而引起專案失敗。

PACE內的技術管理要素定義了技術開發流程，以及由技術向產品開發的轉換，它澄清了產品開發和技術開發兩者之間的區別，並定義了它們與產品戰略的聯絡。

7、管道管理

最後，當公司消除了產品開發中以專案為基礎的各個方面的不足之處後，很明顯，它將進一步需要一個更好的管理模式，來管理所有產品開發專案。隨著各個專案對有限資源的競爭趨於明朗化，管道管理就成為下一個首選物件。

我們發現下面幾個問題可由管道管理來解決：
·低效的資源排程系統常常導致資源排程過度，從而延遲了開發專案。
·作“救火”決策時未考慮到專案的優先順序。
·職能部門預算與專案資源分配不一致。
·專案技能要求與部門資源不一致。
·產品開發決策沒有考慮到公司的增長、產品組合或長/短期側重點等目標。

這些問題存在於所有產品開發專案，也應在所有專案中得到很好的處理。PACE管道管理要素解決這些問題的方法是給專案優先次序的確定和跨專案資源管理提供一種框架，並且將職能部門能力和專案要求協調起來。
[@more@]

新產品開發專案流程的七要素（轉）

相關文章