案例:
PM Simon心想: 希望, 天啊, 不要又來了~
與客戶 Hinne進行的專案才在上個月風風光光的被Award. 但現在已經是客戶第三次要求我們做超出身為OEM供應商範圍的要求了. 據一般業界的通則, 不是應該是原廠應該負責產品設計成敗之責,也就是應該在該原廠Hinne完成該產品的所有設計驗證後, 再由OEM供應商的我們負責在我方廠房的生產設備調整及我方生產良率提升之責, 但最近的一個月, Hinne一直要求我們派RD工程師 on site到Hinne進行產品協同設計開發. 試想: 一組HW/SW Team駐德國少說三個月, 天啊, 先前我的開發計畫書根本沒有列這一項開發預算. 現在如何向大老闆邀追加這一大筆預算? 但若不能在本周回覆HW/SW Team駐德國的行程, Hinneu 一直威脅會因此導入2nd source來參加該重要開發計畫, 分享本來設想的大部分預計出貨量.那麼, 先前promise的預算目標就遙不可及了. 我想: 奇怪, 先前在合約書上寫OEM不夠清楚能讓客戶知道我方並不提供駐廠偕同設計服務嗎?
心得分享:
縱使業界對於與供應商的不同合作關係(ODM/OEM/EMS) 有一個概念架構及定義, 但在細部專案執行上,仍有許多客戶認為他們約定成俗或習以為常的執行要項, 或ODM/OEM/EMS的供應夥伴應該要提供服務或資料的地方. 尤其對於第一次合作的客戶, 因為沒有前例可循, 所以若未能在事前先以白紙黑字寫下雙方的權利義務, 往往後續皆會有令雙方吃驚的情事發生(我方會認為: 天啊, 客戶怎麼會有這個無理要求? 而對方會覺得, 這格供應商是從火星來的嗎?) .尤其對於ODM/OEM/EMS供應商方,因為幾乎一直是買方市場, 所以往往後續ODM/OEM/EMS的供應, 皆以暗自吞下額外成本或擔負預期外時程延長之責, 甚至是penalty罰款了事. 也因此,身為肩負專案成敗之責的PM, 縱使突然獲得客戶award通知時見獵心喜或被成功的喜悅沖昏頭, 但有經驗的PM此時必須事前非常清楚的以”先小人後君子”的心態, 對於雙方的權利義務(R&R, Role and Responsibility; 或叫SOW: Statement of work)做非常清楚的討論及定義, 並建議完整列示該R&R在具法律效益的意向書或合作合約上(通常列在合約的Exhibit上).
至於實務上, PM該如何或以何種形式列示R&R, 一般常用的方法是在PMI協會所出版的PMBOK上有提到業界常用的”RACI圖”也就是:
R=Responsible實際執行者 ;
A= Accountable當責，該項工作當責的角色。
C=Consult諮詢，可以被諮詢或提供意見。
I= Inform告知，表示應該被通知專案進展。
(Resource: PMI PMBOK Guide)
該表將需要執行的工作, 例如設計或開發活動列示於左邊欄位; 而被指派的資源或人員就被列在表格右方的對應位置上.其中應該別注意的是: 一項工作最好只有一個人PIC(people in charge)來做責任承當, 以避免兩個或三個而上沒水喝的推託狀況發生.
正如同PMBOK上所提到的: 當專案團隊包括內部與外部資源時, RACI表格外顯得重要而能明確釐清單位的角色與期待.
在個人實務上, 縮然大家普遍知道RACI圖的架構, 但實際應用上, 因應各式狀況反而大家皆會使用若干變形架構, 因為常常有人對於R與A的角色定義搞不清楚, 何謂A”當責” 何謂R” Responsible”, 所以到後來反而以另一種較簡易且方便使用的”OPSJ表”來使用. 其中:
O=負責該項工作成敗的角色;
P= Primary, item leader. 在該項工作領域上為專家, 擔任主要指導執行的角色。
S=Secondary, support role. 比起其他合作夥伴而言, 在該項工作領域上並非專家, 擔任從旁協助的角色。
J= Joint, shared ownership. 雙方共同承擔執行的角色。
舉個例子如下:
***OPSJ表:
希望對於你的專案有所幫助~
留言列表
