本文出自

團隊力

團隊力

2007年11月號

「有話直說」合作學

Are Your Engineers Talking to One Another When They Should?
曼紐爾.索沙 Manuel E. Sosa , 史帝文.艾平格 Steven D. Eppinger , 克瑞格.羅爾斯 Craig M. Rowles
瀏覽人數:12085
  • 文章摘要
  • "「有話直說」合作學"

  • 字放大
  • 授課文章購買
    購買〈「有話直說」合作學〉文章
  • 個人收藏購買
    購買〈「有話直說」合作學〉PDF檔
    下載點數 10
為什麼專案計畫的預算會不斷追加、時程也一再延誤、品質更是狀況百出? 其實,造成這些問題的原因,往往是團隊成員未能即時提供適當的資訊或資源。 也就是說,如果專案團隊充分溝通,就能弭平差異,讓計畫圓滿達成。

許多公司在設計製程精密的複雜產品時,都曾發生一些令人心驚膽顫的事情。福特汽車與普利司通/凡世通(Bridgestone Firestone)輪胎公司的合作案損失了數十億美元,便是因為福特的Explorer休旅與普利司通/凡世通的輪胎,在設計上整合不良。空中巴士(Airbus)也是同病相憐,A380「超級巨無霸」(superjumbo)客機開發時程一再延宕,不斷追加預算,原因是很晚才發現,機艙有許多部分的配線設計有相容性問題。空中巴士前任執行長古斯塔夫.洪博達(Gustav Humbert)黯然下台,以及A380計畫的管理階層許多重要職位異動,恐怕與這些差錯脫不了關係。

這些事件與類似案例最引人注目的地方在於,幾乎所有相關人士事後都認為,當初他們如果能讓負責產品元件開發的團隊更有效溝通,應該就可以避免犯下代價昂貴的錯誤。當然,複雜的產品開發專案,難免會遇到計畫外的突發狀況。但我們的經驗顯示,像這樣的計畫仍處於設計階段時,公司應該積極關注各個元件開發團隊間最關鍵的接觸點,好讓每個人都知道自己應該在什麼時機、與哪些同仁分享資訊。

本文將協助企業主管解決產品設計的溝通問題。我們深入研究普惠(Pratt & Whitney)公司開發旗下推進力最大的商用噴射引擎PW4098的過程,這具引擎用於波音777噴射客機。我們也針對既有的專案計畫管理工具「設計架構矩陣」(design structure matrix, DSM),提出新的應用方式,好讓主管可以察覺,預先規畫的團隊溝通在什麼地方可能會出問題,以及團隊是否進行未經規畫的技術溝通。同時,我們也分析在專案正式架構之內與之外,各個團隊如何溝通。最後,我們會探討主管應該如何處理上述分析過程中浮現的溝通問題。我們並不認為,我們提出的方法保證可以解決設計階段的溝通問題,但我們相信,主管如果善用這套工具,應用在未來各代產品的開發過程中,就可以改善開發流程的品質。

絕非獨立運作

溝通的「應該」與「實際」落差

專案計畫團隊面對複雜的產品開發挑戰時,第一步往往是將專案分割為容易管理的幾個部分,然後指定幾個次團隊分別負責每個部分。開發噴射引擎之類的產品,分割做法會產生眾多職責明確的跨功能團隊(cross-functional team),每一個團隊專攻引擎的一項元件或子系統。當然,這些團隊不能完全獨立運作,除了要設計自身負責的元件,還必須和其他元件的設計整合在一起,確保整個產品或系統正常運作。因此非常重要的是,在規畫複雜產品的開發流程時,專案經理必須釐清在每一個階段,各個團隊必須互相提供哪些資源與資訊。

以本文研究的普惠PW4098引擎開發案為例,普惠將引擎分為八個子系統,每個子系統再分割為五到十個元件,一部引擎總共包含54個元件。這項專案依照典型的做法,按照產品的54個元件,將開發組織架構編組為54個跨功能設計團隊,每個團隊負責一個元件。普惠還另外設立六個整合團隊,分別處理涵蓋整個引擎的幾項主題,例如燃料效率。這些團隊必須經常互動:PW4098各元件間有數百個介面,相關設計團隊如果缺乏充分溝通,可能會引發嚴重問題。

為了幫助經理人做好這類專案的溝通工作,我們建議企業採取兩項步驟:(A)鎖定「未執行介面」(unattended interface),也就是團隊應該溝通卻沒有溝通的地方。(B)找出「未規畫介面」(unidentified interface),也就是有溝通,但沒有預先規畫要溝通的地方。藉由這兩項步驟,我們會得出所謂的「排比矩陣」(alignment matrix),顯示團隊應該進行的溝通和交流,與實際進行情況之間的落差。因此這個矩陣也能看出專案規畫和執行得好不好。

為了具體說明這兩項步驟如何運作,假設我們準備開發的產品有四個元件,每個元件都需要專屬的設計團隊。這麼做的前提是,組織架構直接對應產品架構,也就是X元件由X團隊負責。在我們探討的汽車與航太公司案例中,複雜的產品開發計畫大部分都運用這種模式。至於組織架構與產品架構不對應的案例,見索沙(Manuel E. Sosa)在《第14屆國際工程設計會議紀錄》中所撰的〈整合軟體開發中的流程、產品和組織架構〉一文(“Aligning Process, Product, and Organizational Architectures in Software Development,” Proceedings of the 14th International Conference in Engineering Design, August 2007)。我們的分析包括三個階段:

階段1:訪談

對象:系統架構師

首先,我們要訪談負責產品整體功能與架構的資深工程師,也就是業界所謂的「系統架構師」(system architect),請他們列出四個元件之間的技術設計介面。元件的位置是否相互連結?元件之間是否要傳送力量、物質、能量或資訊才能正常運作?我們根據他們的回答找出元件之間的所有介面。

專案經理根據成員的回答,畫出一個4×4設計介面矩陣(design interface matrix,一種設計架構矩陣,顯示元件介面形成的網絡)(見表1)。

階段 2:調查

對象:元件設計團隊

在第二階段,我們要了解每個元件設計團隊的成員,希望和別的團隊進行哪些技術上的溝通。我們特別詢問他們,是否可能會需要其他團隊的資訊或資源。我們在訪談時也要確定,成員熟悉所屬團隊負責元件的功能與規格(我們不會讓成員看到第一階段得出的矩陣,以免影響他們的回答)。我們運用第二階段調查得到的資料,呈現團隊間技術互動的模式,繪出另一個4×4矩陣(對應四個設計團隊),稱為「團隊互動矩陣」(team interaction matrix)(也見表1)。

階段 3:整合

對象:訪談與調查的結果

到了最後一個階段,我們將兩個矩陣疊合起來,得出一個排比矩陣(同樣見表1)。這個矩陣顯示,系統架構師規畫的產品架構,和產品開發團隊的期望之間,相符與落差處。顯示落差尤其重要,落差指的是事先規畫但未執行的設計介面(未執行介面),及團隊雖有互動,卻非系統架構師規畫的設計介面(未規畫介面);我們稍後會討論到,這些未規畫介面有時相當重要。

當專案進入尾聲,專案經理可以根據後續調查所得的較新資料,來更新排比矩陣的內容。這些後續調查會詢問元件設計團隊成員,他們從哪裡得到必要的資訊與資源。比對新的團隊互動矩陣,與原有的設計介面矩陣,可以顯示專案初期發現的落差是否依然存在,是否出現其他落差。這類事後檢討會帶來寶貴的收穫,對日後的產品開發專案助益良多。如果公司計畫日後開發類似產品,或既有產品的下幾代產品,這類檢討更是重要。

我們針對普惠PW4098引擎的開發案進行分析。這款引擎的開發速度與成本,為航太業立下新的標竿。它也是第一具商用噴射引擎在啟用第一天,就在「雙引擎延程飛行」(extended range twin operations)驗證中飛行達180分鐘。

我們首先訪談引擎的系統架構師,他們從PW4098的54個主要元件中找出569個介面。其中許多介面都非常重要而且複雜,因為它們不僅涉及實體連結的元件,同時還涉及傳輸物質(空氣、燃料或油料)、能量(振動或熱能)、結構力,或是引擎控制系統的訊號(根據這些介面做出的設計介面矩陣,見表2)。然後,我們詢問這項專案的54個團隊,每個團隊至少請兩位成員描述他們在專案的細部設計階段,從其他團隊獲取技術資訊的頻率,以及這些資訊的重要性。訪談結果記錄了元件團隊間423次互動,呈現在表2的團隊互動矩陣中。最後,我們將設計介面矩陣與團隊互動矩陣結合,做出一個排比矩陣。

讀者如果用放大鏡來看,可以找出220個未執行的設計介面,代表團隊未能進行應有的互動;此外,還有74個未規畫介面,顯示這些地方雖未規畫介面,團隊實際上卻有交換技術資訊。我們不會天真到冀望設計介面與團隊互動完全一致(在普惠220個未執行的設計介面中,有許多並未引發問題,或者不是非常重要),但兩者之間的落差這麼大,顯示普惠的PW4098專案承受高度風險,可能會遭遇成本超出預算等問題。

為何?

溝通落差出現,多因心態輕忽

溝通落差並不是隨機發生在產品或組織中,而是產品設計與組織因素造成的結果。預先規畫的關鍵溝通點出問題,可能有幾個原因:組織界限(某個團隊的跨部門介面,比同部門的介面更容易被忽略)、介面的重要性(複雜且重要的介面,會比次要的介面得到更多關注)、間接溝通管道的運用(團隊有時會透過其他中間團隊來傳達技術資訊,而不是直接互動)、沿用介面(有些介面在先前的專案中已經界定過了,規畫新專案時可能不必重新確認)、介面標準化(介面的細節之前已經作成正式紀錄,原則上應該依循)。

未執行介面

長期小誤差,累積大花費

以普惠的PW4098引擎專案來看,有些落差會發生,是因為元件設計沿用以往專案的設計。例如有幾個高壓壓縮機的元件,基本上與前一代引擎的設計沒有什麼不同,因此負責這些元件的某些團隊認為,不必特別注意彼此間的介面是否需要協調,但仍需要與其他大幅重新設計的元件團隊協調。這種掉以輕心的心態日積月累,也會影響他們與大幅重新設計的元件團隊溝通。還有許多結構與熱力學的設計介面,並未得到應有的關注,因為它們並不重要,而且被視為標準程序。在許多案例中,這類介面牽涉到幾個不同部門的團隊,比較沒有機會進行非正式的溝通,如果有非正式的溝通,往往就能發現先前的標準已經變化。這類未執行介面可能會很小幅地降低產品性能,或相關元件與系統的耐用性。雖然影響幅度相當輕微,但像PW4098這類產品的使用期限長達25到30年,就算是小小的性能誤差,也可能在長期累積下,導致可觀的保固與維修費用。以渦輪翼片(turbine airfoil)這類關鍵元件為例,使用期限只要縮短幾個百分點,引擎可能就必須進行一次、甚至多次計畫外的拆卸維修。一次計畫外的拆卸維修,會讓客戶額外支出15萬美元的成本。

儘管大部分未執行介面並不很重要,但還是有一些很重要。這些關鍵的未執行介面,多半發生在不同部門的團隊之間。因此而造成的成本支出不容小覷。PW4098專案就有兩個未執行介面相當重要,增加的成本取決於發現與解決介面相關問題所需時間。其中一個未執行介面,涉及引擎高壓核心裡迴轉金屬組件之間傳送的結構負荷(structural load)出現變化,導致引擎在初期測試時,出現接合金屬組件負荷過高的狀況。結果,普惠必須拆解測試用引擎,並重新設計和製造。我們估計,光這個問題,就讓專案成本增加1%到2%,部分計畫時程也延宕三到四個月。另一個未執行介面發現得較晚,當時初期產品組裝已開始,但成品還沒有出貨。這個介面問題也涉及引擎模組間傳送的負荷,降低某一個主要引擎軸承(engine bearing)的使用年限。受到影響的零件和引擎,遠多於前述那個未執行介面問題,對計畫所需時間與成本的衝擊也更大。

未規畫介面

當務之急:決定是否更動

我們發現,未規畫介面不像未執行介面那麼常見,但若是發現未規畫介面,往往都會對專案有好處,因為它們能揭示產品各部分或系統間,相當重要、但人們未曾預料到的相互依存關係。我們在普惠案例中發現的未規畫介面,有好幾個都是在調查引擎整體層級設計問題時發現的,這些問題可能導致測試用引擎應變(strain)過高、溫度過熱或壓力不足。由於參與的團隊,早在察覺或預期這些出乎意料的問題會出現時,就開始溝通,因此能在產品測試之前著手解決,避免損失大量的時間與成本。我們發現這類未規畫介面時,當務之急是決定是否要把它們排入專案的工作進度與作業程序,還是不處理。作這個決定的主要依據是,相關溝通是否重要。就上述案例而言,普惠在規畫新一代引擎的開發計畫時,納入其中一些相關的團隊互動介面。

造成未規畫介面的原因和未執行介面不同。普惠案例中有幾個未規畫介面,涉及的團隊各自負責因應引擎整體層級的設計問題,這些問題會產生有害的結構負荷或熱負荷(thermal load),因此他們需要涵蓋不同元件的技術解決方案。例如有一回,三個負責高壓渦輪與低壓渦輪的團隊必須與負責燃燒室(combustion chamber)的團隊溝通,才能讓熱環境(thermal environment)達到最佳狀態,延長相關元件的壽命。這些未規畫介面都相當重要,但當初系統架構師並未考量到。幸好這些團隊的成員曾在過去的專案中扮演相同角色,因此就算沒有預先規畫,他們還是很可能會交流資訊。

如何?

處理溝通落差,三個步驟解決

釐清造成溝通落差的根本原因後,組織就可以決定因應對策。可行的解決方案不一而足,包括重新畫定組織界限、重新分配或建立新的介面管理責任與輔助工具,甚至重新設計整個系統的架構(底下我們會進一步討論其中幾項)。若要選擇適合的解決方案,請參考下列三個步驟:

步驟1

檢討組織與系統界限

專案中如果出現許多跨越組織界限的未執行介面,專案經理就應該檢討組織架構。當初空中巴士如果這麼做,或許可以避免後來遭遇的困境。空中巴士在規畫開發案的組織架構時,不僅考量飛機本身的架構,也參考母公司EADS旗下其他合作伙伴的工作分配。由於額外考量了其他合作伙伴的工作分配,使得未執行介面的發生機率上升,為了解決問題而進行的未規畫介面,出現的可能性則會下降。

然而若要改變組織結構,恐怕必須先改變系統架構,因為對大部分企業而言,組織結構往往是根據系統架構而定。開發更多與其他元件直接、間接介面較少的模組化元件(modular component),這種做法格外有效,因為比起需要大量元件互動的專案,這類專案的技術溝通比較容易處理。以普惠的專案而言,負責較多模組化元件的設計團隊,錯失的重要介面,遠少於負責其他類型元件的團隊。前者的介面數目比較少,而且直接與間接介面減少後,團隊的工作量也比較容易掌握。然而,過度模組化也可能局限團隊的視野,在子元件(subcomponent)層面尤其是如此。我們在普惠的案例中發現,高度模組化子系統設計團隊間的溝通狀況,不如整合性子系統團隊,後者彼此間的整合程度也較高。因此,在推動元件模組化的同時,產品設計者仍要密切關注子系統間的重要介面。

步驟 2

專責團隊處理問題介面

經理人處理關鍵介面時,也可以指派負責互動事務的團隊來管理這些關鍵介面,或要求團隊成員正式參與並負責關鍵介面的運作,以便找出未規畫介面,或是將未執行介面納入正軌。跨組織界限而規畫的介面最容易被設計團隊忽略,因此我們推薦主管運用這種方法加以管理。

還有一種方法可以處理未執行介面,而且不必大幅改變組織的結構,就是擴大現有整合團隊的權責。大型專案大部分都設有這類團隊:普惠的專案設有六個團隊,負責處理涉及整個系統的問題,例如空氣與燃料效率,這類問題會影響所有引擎元件的設計。儘管處理團隊溝通,往往不是整合團隊的主要職責,但就這類團隊的工作本質而言,他們會與組織中幾乎每一個團隊溝通。因此,他們能夠及時得知設計流程中各項關鍵介面進展的情況,如果發現有些關鍵介面的溝通不夠,需要特別關注,就會促成相關團隊進行溝通。這些整合團隊可以負責找出未受到妥善處理的重要介面。PW4098專案中,六個整合團隊之一的輔助氣流(secondary airflow)團隊,負責管理引擎內部多個熱能與壓力處理系統,盡量提升引擎的空氣動力效能與元件耐用性。這個團隊定期與其他原本缺乏聯絡的團隊開會,運用各種溝通方式來強化關鍵介面。

可惜的是,大部分的整合團隊著重於階段性指標的規畫與資源分配,不太關注元件團隊之間的溝通狀況。這種做法必須改變。以空中巴士A380專案為例,負責配線設計的德國團隊,與負責機艙其他部分的法國團隊,並沒有好好溝通彼此的設計介面規格;如果能有一個整合團隊及早發現問題,A380專案到最後階段時就不會弊病叢生。

步驟 3

選擇適當的輔助工具

許多設計團隊錯失溝通介面,是因為專案規畫者並未仔細考量團隊如何運用溝通工具與共享平台。空中巴士A380專案團隊溝通失靈的主要原因之一,在於各團隊的電腦輔助設計(computer-aided design, CAD)工具並不相容。

善用溝通工具未必需要許多技術:普惠要求團隊定期繳交控制介面報告(controlled interface document)與元件需求報告(component requirements document,須標明規格),確保他們不會疏忽關鍵介面。如果團隊成員必須運用專業技術來完成工作,不同的工具和平台就必須妥善整合。例如普惠在規畫PW4098後續引擎產品的開發專案時,將引擎整體的空氣動力學和輔助氣流分析模型,與元件的模型連結在一起,好讓設計團隊能在整合團隊的協助下運用溝通介面。普惠在每個團隊中指派特定成員,負責追蹤設計變化對元件與系統模型的影響,並與其他團隊裡負責追蹤這些影響的成員交換訊息。

指引正確方向

協調一致,才不致付出代價

有些組織會指派一些設計團隊共同開發複雜的產品,我們提供的這套系統化方法,可以讓組織了解,這些團隊會在何處、如何面臨溝通失敗的風險。此外,組織也可以用這套工具判斷系統架構的變化,以及系統元件介面的建立與移除,會如何影響組織防止溝通失敗的能力。藉由設計架構矩陣,將同一系列每一代產品的架構記錄下來,主管可以找出舊架構與新架構的主要差異。有了排比矩陣,主管就能用簡明的圖像來呈現介面和互動,研判組織如何處理設計介面。最重要的是,排比矩陣能夠協助主管協調團隊的互動與設計介面,避免日後在產品生命週期中付出昂貴的代價。

(閻紀宇譯自“Are Your Engineers Talking to One Another When They Should?” HBR, November 2007)



曼紐爾.索沙 Manuel E. Sosa

法國歐洲工商管理學院(Insead)科技與營運管理助理教授。


史帝文.艾平格 Steven D. Eppinger

美國麻省理工學院史隆管理學院教授,主授管理科學與工程系統,同時擔任代理院長。


克瑞格.羅爾斯 Craig M. Rowles

美國Emegear醫療設備公司執行長,曾任普惠(Pratt & Whitney)公司模組中心經理。


本篇文章主題溝通