管理其實也可以很Easy-永續供應鏈沒那麼便宜

2024/12/31 Anthony Liaw Version:1.1

    最近有點懶，只為一些未來發展煩著，看到一堆的人炒作與公然漂綠，還是有話要說，不得不吐。2024是個奇怪的年，當初大家以為疫情過去了，一切將會蓬勃發展，迎接一個新的未來。一年過去了，股市大漲（卻不是ESG的目標，因為貧富差距更形惡劣，社會問題越來越難見公平）。年輕人被洗腦到無思考能力，企業只賺取機會財，政府只是一手倡議一手違規頻頻，這就是社會公義的部分，也是ESG的重軸戲。一堆企業社會責任的獎牌常勝軍，一一中箭下馬，霸凌等等，都已告知答案，重點是有多人在乎？

    歲末年初，在2024年的最後一天，上來與好朋友說聲恭喜。送別2024，迎接2025，為紛擾的2024畫下句點，至少禮數要到。

    最近看到一個演講，主題是數位化可以降低碳排量，數位化真的能省能源？機房、AI運算、Cloud、邊緣計算、充電等等議題，數位化絕對不是省能源的重點。台灣的Co2總耗費量才2億6千萬噸，佔世界的0.5%，即使全降了又如何？對地球的貢獻微乎其微（投資如果大於減碳的價值，那投資的意義又何在？不就是漂綠嗎？）只要數位化就可以降低40%碳排的科學根據是什麼？未來的能源使用趨勢預估又是什麼？（路徑圖）看來表面化只是讓漂綠深沉化而已。太過膨脹效益的結果，True Value被扭曲，因為看不到True cost與真正的影響力。Google已宣布機房的減碳不減反增（增加48%），理由無他，只因AI與機房的空調系統難以降低Co2的排放量。

    第一張圖的永續供應鏈的挑戰只看到一堆的法規與條文，增加如此多的法遵要求，供應鏈就會減碳？太過天真的，減碳的問題在How而不是What，為何如此，可以參考聯合國的2030 SDGs中間報告的內容。德國企業也開始抱怨CBAM的問題，為何？只因為世人觀點只到What的層次，無法洞悉Why的意涵，How只想撿便宜的上課、辦研討會，單位賺機會財，SDGs的未來性堪虞，永續的前途就看五年吧！

以下是演講會的內容，思考一下，這些都在談什麼？你懂我不懂？我懂你不懂，懂了半天什麼也沒進展，為何？

這張投影片只反應兩件事實，成本增加與物流斷鏈（受到四大通膨風險，碎鏈供應鏈容易出現供應鏈斷鏈的問題，屆時支援都不再是全球化供應鏈那般容易）而且內容談的都只是What？沒有任何How？的手段方法，也難怪聯合國如此悲觀，全世界的機會財主義太強大了。以後企業登記，只要一開始直接要求所有的企業建立這些系統，那不就簡單多了嗎？歐盟執委會的頭腦越來越空洞，台灣市場是最會把空洞化轉為商機的一群，越來越高的吻合度，卻不見得會有人感激的。

一、 對未來的採購而言，「永續」已經比供應商的交期、品質、價格更重要（兩家企業有A家品質、交期、價格與服務都優於B家，只是沒做永續報告書，請問採購該找誰？）

1. 供應鏈面臨的主要議題

• 合規壓力：包含GDPR、數位服務法、AI法等法規要求。

• 物流中斷：天災、疫情或其他突發事件導致的營運持續管理(BCM)挑戰。

• 採購要求：供應商需符合永續標準(如ISO 20400、BS 8001等)以及碳排放、碳中和相關的要求。

Q1.增加成本有轉嫁能力能力嗎？

Q2.這些都合規了，企業得到的是什麼？依然我行我素？還是改變了什麼？

Q3.企業導入如此多的ISO，如何維護管理？標準化部門又是誰？如何管理？越來越沒有效率的經營管理，都在貢獻碳權（新上帝），還是永續治理？

• 生態治理 & 人權議題：社會影響(Social Impact)、DEI（多元共融）、以及UN Global Compact 等國際承諾。

（企業是為何而戰？只為了聯合國、歐盟？還是真心的思考永續？沒有文化的台灣企業，人資只是老闆的劊子手，嘴臉難看！）

• 成本壓力：碳稅 (Carbon Tax)、CBAM (邊境調整機制)、ETS (排放交易系統) 等政策可能帶來額外稅費或成本。

（台灣實施碳權收費後，預計每年只會收到60億的費用，請問這對於GNP超過$34,500US的國家來說，是問題點嗎？將來60億碳費專款專用，可能行政費用就要吃掉四十億吧！）

2. 這些相關國際標準 / 指標，您的企業是否已經開始準備？

（導這些的標準對誰有利：

企業：絕對不利，增加成本外，還會養成一種應付的文化，反導成為企業無形成本；

3rd party：當然有利；

政府：無所謂，因為四年就不見了；

客戶；只要不增加成本都無所謂，反正又不是只有一家企業，但等到所有企業窮得只剩下ISO，其他的一無是處時，客戶會如何選擇？根本的競爭還是QCDS）

社會：為所有經濟活動的破壞環境買單，錢入聰明人口袋，笨人只會「人家吃米粉，喊燒！」

• ISO 系列：14064–1（溫室氣體盤查）、14067（產品碳足跡）、14068–1（未來的碳中和指引）、45001（職業安全衛生）、27001（資訊安全）、22301（營運持續管理）、31000（風險管理）等。

• SRA (GRI)、RBA（責任商業聯盟）、TCFD、TNFD：分別對應永續報告、供應鏈責任、氣候/自然相關財務揭露等等。

• EU AI Act、GDPR：歐盟數位規範，對企業數位合規提出要求，包含個資保護、AI使用規範等。

• UN Global Compact：聯合國全球盟約，強調人權、勞工標準、環保及反貪腐。（能不能先把國家治理的貪腐問題可視化，再來談其他的吧！）

• ESG 投資趨勢：包括責任投資原則 (PRI)、PCAF(碳會計金融聯盟) 等。

二、企業治理與董事會責任正被各國法規與趨勢強化

公司法強調受託人義務，董事及高階經理人需要對公司及股東承擔「誠信」與「忠實義務」。現代企業需導入完善的風險管理與內部控制機制，包含 ESG 風險（氣候、供應鏈、人權、網路安全等）。

董事必須遵守的四項義務

• Duty of Care（注意義務）

• Duty of Loyalty（忠誠義務）

• Diligence（勤勉盡力）

• Skill（專業能力）

在未來，具備扁平化與跨職能協作的組織韌性，在面對複雜、瞬息萬變的風險時，能更快速整合資源並作出決策。（品質保證的基礎是基於數據的決策）

三、結語：實踐文化的核心（整個演講唯一有價值的內容部分）

一個組織若要深耕「永續」、「品質」、「安全」等核心價值（這句話應該這麼解讀，一個組織若要追求「永續」，「品質」、「安全」等核心價值必須深耕），需要將這些概念內化成為企業文化的一部分。若能藉由制度、組織行為與員工培訓，讓「ESG」不會僅停留在口號，而是成為公司日常決策與運作的指引。

• 企業必須面對的永續風險（碳排放、社會責任、供應鏈斷鏈等，還有不斷更新的法規與管理條文）。

• 企業治理與董事會責任正被各國法規與趨勢強化，必須更積極承擔ESG整合、合規與風險控管。

• 文化與組織韌性是落實ESG的關鍵：不僅依賴制度，更仰賴所有成員對永續價值的認同與實踐。

這張講義的數據是以終為始的推估吧！2030改善40%的碳排，AI與機房正侵蝕台灣用電安全的極限，政府有做出任何措施嗎？（How？）數位化是耗能源產業（伺服器、UPS、AI、機房、運算、雲端等），越來越高耗，何況數位化只是導入系統，減碳利基從何而來？

經營管理ISO化最便宜，但永續供應鏈管理絕對不便宜。

管理其實也可以很easy--專案管理與孫子兵法(34)

專案的任務分配

談完成本企劃後，接下來就來談談專案規劃中，資源與任務的分派(R&R：Resources and Responsibility)。資源規劃就是以前幾次談過的預算規畫基礎，專案負責人接到任務後，向專案的投資者申請要完成專案任務的必要資源，及這些資源要如何運用的計畫性活動。專案資源很多元，最基本的部分就是人力資源及材料費(產品開發專案)。只要這兩部分規畫得宜，專案的成功就事半功倍，反之亦然。

人力資源規劃，不是單純的只是要幾個人而已，要讓一個專案順利完成，在人的資源部分，必須充分考慮到完成專案需要具備的技巧、派任成員的工作的態度、及還有多少工時可以用等等的問題，這個活動就是一般所謂的資源盤點。

廣義而言，專案資源應該包含：人、物、金，與時間。其中人的部分最多元與複雜，可推究到需要的職能與可用工時。很多人認為職能及使專業能力，其實職能還可以轉化為知識（K）、技巧（S）、與態度（A）三個面相。

「K」泛指基礎專業知識，一般以學科為判斷基準，如電子、電機、機械、化學….等等。往往來自於正式學程學習到的基礎知識，是決定是否有足夠的專業來執行專案任務的關鍵要素。「S」則是實務操作的技巧，知識是理論根基，離開學校，很多人往往就不再繼續鑽研，不斷的重複使用既有知識。「S」技巧是知識的應用，與經驗有很深的結合，熟能生巧就是這個道理。一個學校剛畢業，知識縱然很高，技巧往往還生疏，所以才會出現OJT(On Job Training)的機制-加速資源的即戰力。「A」態度這種職能卻是人力資源最難控制的一個面相。難以衡量，瞬息萬變，因人、因事、因地都可能改變的職能，卻是「K」與「S」發揮效能的核心條件。態度反映出責任心、工作態度、以及資源的有效性，確實掌握每個成員態度，任務分派時，比較能得到適得其所的安排。甚至在資源衝突的情況發生時，有資源調度的必要時，此部分的資訊也是重要的參考。

專案的任務分配，俗稱的R&R主要是確保專案資源的適切性，決定專案成敗的關鍵。一般可以設計一個矩陣表來處理，縱軸部分為工作項目(WBS展開最下層的工作)，橫軸部分為成員名字，矩陣交叉的格子裡，可以以斜線把一個格子分成兩個部分。斜線上方註明投入在這個工作的工時，下方則填入擔當的代號。擔當代號一般以數字的1、2、3來表示。1表示是這項工作的主擔當（Accountability），2則是副擔當或是支援（Responsibility），3是必須被知會的資源（Notify避免專案的資訊不同步）。

主擔當簡而言之，就是這個工作的小工頭，負責這個工作的進度管理。副擔當則是同樣分擔工作的一部分，或是支援的角色。每個項目，主擔當只能夠有一個人，但副擔當可以有很多人。這樣的做法有某種程度的風險管理的意義，可以在任何人員變動的時候，可以互相支援。至於被知會的3的部分，主要的目的是有些資訊與進度必須讓3的人隨時知道，才不至於在工作銜接上出現溝通不良的現象。而主擔當與副擔當分配的任務工時的加總，就是WBS展開的項目的工時，如此可以一目了然的掌握每個成員的任務與工時，及每個工作的工時。R&R任務分派表的設計，簡單標示如下：

     工時單位(Hr)                                    專案成員                             小計工時

   WBS工作項目                    A         B         C          D          E     -------------------

    專案規劃                          12/1     3/2      5/2                     /3                   20

   可行性評估                           /3   15/1      3/2         /3         /3                   18

   ---------------------------------------------------------------------------------------------------

    工時小計                          12         18         8                                            38

         上表中，從WBS展開的工作中，抽出專案規劃與可行性評估兩個工作為例。專案規畫這個工作，成員(A)投入工時為12Hr，是這個部份的主擔當(1)。而成員(B)與成員(C)為此部分副擔當，投入工時各為3Hr與5Hr。專案規劃這個工作，總共需要工時為20Hr。而(A)在上兩項工作的投入總工時為12Hr，(B)為18Hr，(C)為8Hr，總共三個人在這兩個工作投入工時為38Hr。

管理其實也可以很Easy--專案管理與孫子兵法(33)

專案的成本規劃

成本企畫，對國內的企業來說，應該是比較陌生的一種技巧。要談成本企畫，不只要有廣度，也還要有深度，才能夠看出其價值所在。今天我們就來談談新產品開發的成本企畫。

首先，何謂成本企畫？先把主題說清楚，講明白。成本企畫是新產品開發過程，透過企劃的程序，規劃出產品的競爭要件與投資報酬目標，建立一個成本的結構。以此為目標，工程師依據目標，以創意為手段，來完成產品事業性目標的一種成本管控手法。也就是說，成本企畫是一種以企劃與創意來保證產品獲利的開發手法。

或許很多人會說，我們在新產品開發中，都會設定目標成本，再由工程師完成之，那不就是成本企畫了嗎？看似一樣，其實無論在廣度或是深度上，都存在很大的差異，接下來就來談談成本企畫。

成本企劃首先就必須從企業的成本方針談起。台灣的企業有一種經營的怪現象，Cost down常常都是被客戶追著跑。也就是客戶要求Cost down，組織就開始動員起來，展開Cost down活動。結果Cost down都是為客戶作嫁，Cost down目標達到了，自己也沒得到甚麼好處，只是滿足了客戶需求；如果Cost down不順，沒有達到預期的目標，為了生意只好縮減利潤來養客戶，終究走到微利的經營。

反觀日本企業，Cost down是企業認為賺得不夠多，為了增加利潤，就必須Cost down。也就因為如此，Cost down目標與時機都是隨時啟動的。錢賺多了不窮沒地方放（賈伯斯是成本控管最精細的領導人，與供應商談代工價格，一分一厘都是斤斤計較），留下來當池水。企業永續途中，為了改善必須要投資、技術開發要投資、人才發展要投資等等，都必須有足夠的利潤來支持。

這樣的經營思維下，成本管理成了一套日常管理的經營模式-Cost down是為提升利潤而做，不是被客戶逼著做，與國內企業成本管理是以接單為目標，有很大的差異。這種前提下，公司內部會有一個明確的成本方針，以做為經營管理活動的準繩。譬如日本松下的成本率(Cost rate)是25%，或是很多公司的Cost half方針等等。有了這個方針後，公司內部的所有流程，都將以此一目標為基準而設計。舉凡產品開發的目標成本、內部的作業流程、營運預算編列等等。

當新產品開發專案啟動前，市場行銷策略一展開(4P)，決定了產品的市場價格後，目標成本就自然形成，(目標售價 X 成本率 = 目標成本)這方面是沒有討價還價的空間。一旦目標成本定調後，專案人員就必須展開成本分配，以做為設計人員的目標。

簡單以一個新產品開發案為例：有一個新產品開發專案，市場行銷展開的計畫是目標售價NT$1,500的電子產品。如果依據公司的成本方針為50%，則產品的成本預算為：售價$1,500，成本$750，預期獲利目標為$750，50%的毛利率。再把成本拉出來，$750的成本又以材料費佔總成本的80%，$600、製造費佔成本的10%，$75、管理費佔10%，$75進行成本分配。

成本結構定調，開始展開細部的成本分配。材料成本的部分，此時還沒有進入設計程序，所以不可能有BOM的存在，所以不會像以往的作法，以舊機種的BOM成本，各乘以一個比率來分配各部位成本。或許您會認為這樣的做法不是最簡單嗎，為何要捨近求遠？這種作法的最大問題是，以前錯誤的部分會一直錯誤下去，其次更大的問題是，新的創意出不來，因為已經被經驗綁架了。更嚴重的是，成本結構中只看到技術的影子，看不到顧客的需求。所以如果能以零基的觀點來設定成本，雖然繁複一點，但對工程師的價值呈現，絕對是正面且重要的。

所以要將材料成本分配得宜，又能兼顧到市場的需求，就必須先展開品質機能，從顧客的聲音(VOC：Voice Of Customer)來定位，轉換成為技術規格(VOE：Voice Of Engineer)來搭配。展開機能的權重後，以權重來分配成本。這樣的做法雖然對工程師的壓力很大，卻是最能反映市場顧客聲音的成本設計手法，就是把錢花在刀口上的寫照，也只有這樣的做法，可以逼出工程師的創意。

製造費也是一樣，以下就以此一模式展個範例。製造成本的目標$75，首先要看製造策略展開的製造單位加工成本。譬如：本產品的生產據點將放在台灣，台灣工廠的每分鐘加工費是$7.5。那將成本展開後，這個產品的加工工時只能控制在10分鐘以內，只要超過這個時間，或是每分鐘加工費超過$7.5，這個目標勢必達不到，那利潤自然也達不到50%的目標。如果IE對生產工序的安排是每個工序0.5分鐘，那就代表這個產品的總工序，不能超過20個工序。

當這樣的成本展開後，控制產品的總工序不超過20，是研發工程師設計時的管控目標；每道加工工序不超過0.5分，是IE的管理目標；而每分鐘加工成本$7.5，是廠長的日常管控指標；至於每台加工工時不超過10分鐘，是生產線主管的目標。成本企畫的重點也就全部展現出來，各司所職，而且必須跨機能合作，同心協力才有可能達成目標，是最典型的同步工程手法。

這樣的成本管理手法，或許您會覺得難度很高，確實，如果沒有一個有效的管理程序與決心，加上團隊成員的成熟度，再好的手法也都於事無補。要如何達成？下期再來談談成本企畫的注意事項。

簡單做個小結論，傳統的開發模式是：

 啟動➛任務分配➛設計➛採購詢價➛成本評估➛ECN➛2nd Source詢價➛Cost down

成本企劃模式是：

 啟動➛目標設定➛任務分配（含目標）➛設計➛成本評估（NG）➛調整設計➛成本評估（OK）➛採購詢價➛生產

其中差異在哪？各位請自參，下期再聊！

管理其實也可以很Easy--專案管理與孫子兵法(32)

專案的成本規劃

在新產品開發專案中，影響專案的成敗的主要因素，產品的成本當為首要，特別是量大的消費性電子與資訊產品。再者，管理的名言：「研發階段決定80%的成本」，如果沒有在事前做充分的規劃，一旦設計完成後，製造單位對成本的控制已無能為力了。

那該在何時？如何進行成本規劃呢？首先如果是策略性的產品，那成本的規劃不在於要如何控制成本，而是如何定價。一旦決定市場競爭地位後，以目標獲利率來訂定成本。產品的成本設定可以從幾個角度來思考，主要有三種方法，分別是：成本導向、價格導向與利潤導向。

所謂的成本導向比較常見於傳統產業。主要作法是以產品的成本加上預計要賺的利潤，來決定售價。這種做法就是一般所謂的「加法法則」。但隨著產業競爭的白熱化，及沒有藩籬的競爭，實質上這種模式已不太可能存在競爭力。

其次是依據市場的競爭價格，訂定「目標成本」，來決定獲利能力。此種作法最大的問題是市場售價一直在掉，但「目標成本」卻無法隨之調整，因之獲利能力常因此受到擠壓。

現在為大部分電子產業所採用的就是「利潤導向」成本設定法。市場價格受到競爭的壓擠，企業很少有能力主導之。雖然企業無法主導售價，但卻可以決定利潤，亦即在產品開發之初，決定獲利能力後，自然帶出「目標成本」，是一種策略性的減法法則成本概念。

今天就來談談利潤導向法的成本規劃。

藍海策略這本書打破了台灣人凡事宿命論、薄利多銷的競爭迷思。告訴我們企業經營本來就該賺到合理以上的利潤，更絕不該有薄利多銷的思維。當然能做到此一境界也絕非省油的燈，必須有別人看不到的一些競爭力。這種企業可以自己訂定遊戲規則，訂價法則更是代表企業的價值。但國內企業又有多少公司有此能耐？沒有行銷力，技術力就像秀才遇到兵，有理說不清，發揮不出應有的價值。

既然是事實，企業無法改變事實，沒有價格發言權，那總該可以自己訂定賺錢的力道吧！也就是訂定利潤是藍海戰略的重點思考。

很多人都對減法法則抱著懷疑的態度，如果市場決定售價，企業決定利潤，直接帶出「目標成本」，世界上有這麼簡單的事嗎？總以為那只是一種宣示性大於實質性的噱頭。這種想法道出國內企業管理的粗淺。也就是說，台灣企業到目前為止，都還是只會賺去「勞力財」，不會賺取「管理財」。更不用說「創意財」。

要想做到「減法法則」的產品開發，沒有創意與管理，根本是不可能的任務。有技術做後盾，加上創意與管理，做出不容易被模仿的產品，不需要與別人拼價格，那才是價值所在。對於工程師而言，「研發階段決定80%的成敗」的鐵律，是不可忽略的一件事，以計畫來確保產品的獲利，才是「創意財」的基本思維。

那，要如何做呢？下期就來談談成本企畫。

管理其實也可以很Easy--專案管理與孫子兵法(31)

專案的預算編列

當專案時程安排好後，接下來就要編列預算了。一般對專案的預算，都只看到狹義的預算部分，也就是花多少錢的事。其實以廣義的專案預算來看，專案的經濟模型(包含預計的產出、投資報酬率、損益平衡點分析，如果是產品開發的專案，還涵蓋產品的目標售價與成本分析等等(產品的事業性分析)。接下來我們就來談談專案預算編列。

首先先來談談專案預算的部分。專案預算主要兩大類別，一為收入；一為支出。收入的部分往往在戰略階段定調，往後的變動管理，由事業部門控制，與專案比較沒有直接連結，除非市場變化大到讓專案有繼續存廢考量的因素出現外，不會有大動作。也可以說，大部分的專案，主要控制的預算在支出的部分。預算管理的好壞，決定一個組織的成敗，一點不爲過。沒有預算全意味著在組織中的地位還不是很關鍵，還在執行層次而已。

專案的支出預算大致上可以分為幾個領域，一為人事費用，其次為差旅費，再來就是試作材料費(新產品開發的專案)、管理費、技術費、驗證費、先在已出現碳權與碳廢的問題，加上盤查、綠色標章申請（LCA）等的費用，還有一些無法列入的其他費用等等。

首先談談如何評估人事費用。WBS展開，完整的WBS應該會涵蓋任務所須要的工時，只要將工時乘以單位工資成本，專案的人事費用就出來了。但必須注意的是，單位人事費用是必須涵蓋直接新資、福利待遇、管理成本等，甚至衍生的人力資源的支出都屬之，而非只是單純所謂的薪資部分。編列專案人事預算時，WBS的工時評估，是關鍵成功要素。這部分以台灣企業的專案來看，不太容易做到。動則得咎的薪資保密要取得數據的第一關就卡關了。其次人員的工時管理並不是很紮實，要拆得多細，又是一個難題。更麻煩的是，誰來提供？人資？主管？但這是專案價值呈現的重要指標之一，如何可以輕忽

其次是試作材料費。很多企業把試作材料費看的很緊，就怕工程師浪費了材料費。這種想法有進一步探討的必要。產品設計，如果太限制工程師在材料費上的使用權，工程師將無法放手的去找尋更豐富的靈感做實驗，這樣的設計案在創意上自然會受到限制。再說試作材料費畢竟還是小數，對整體研發預算的分擔比例，占比不高，不值得太為此而傷神。試作材料費只要估個概數即可，譬如：試作機器幾台？每台試作材料費多少錢（損益評估時就有的數字）？相乘就是材料費預算。

一般在專案的預算編列時，都會用Working sheet做底稿。Working sheet是一個2維矩陣的試算表，縱軸以會計科目為基礎，橫軸部分，有單位攔、單位成本、及階段(專案的階段，一般以月分別或是依產品開發階段別表示之，最後有個總計的欄位。現在假設我們是以月度別來估算專案預算，那每個月度與會計科目的交叉欄位的填入估算出來的需求量，再個別與單位成本相乘，就得出每個會計科目的需求預算。

如果將試算表在加上一個實績欄位，將本來預估的計畫欄作為目標欄，每個月或是每個階段，依據實際動支數，可以看到預算的整體運用情形，就可以判斷專案進行的完成度。但因為有時動支與請款存在時間落差的現象，難免會有一點差異，個別月份來看差異是存在的，但累積來看差異就越來越小了。此點必須注意。(預算的管理，也是專案管理的重點之一，比起時程管理要全面得多，只是需要的技巧與資訊要更完整，這又是台灣專案的弱點，呵呵！)

再其次新產品開發專案最重要的就是產品經濟模型。這部分是用來評估一個新產品開發的投資效益，是產品開發專案事業可行性評估關鍵資訊。經濟模型應該包含投資項目、預估產品銷售數量、平均銷售單價、預估生產成本(UMC)、銷管費用及研發攤提(UAC、UTC)。開發期間的現金流量為負數，等到產品開發完成，進入銷售階段，才開始有收入，每個月的累加項到達零的月份，就是這個產品的損益平衡點。

產品開發的損益平衡點越短則代表投資回收越快，事業性佳的產品，反之則必須多考量。決策單位在進行產品的開發提案時，此部分應該是最重要的考量。但在評估專案的經濟模型時，也必須考慮到現值的觀念，才是合理的評估。(現值觀念對很多工程師可能不知道，簡單而言，今天的一元，五年後不能夠還是以一元對待之，因為如果這些錢沒有用，放在銀行也會有利息的收入，而且是複利計算，所以五年後的壹元的現值等於現在的壹元 X (1 + 利率)的五次方。

用文字敘述預算的編列有點困難，如果有需要範例的話，請留下email，將寄上範例供您參考。下期我們將來談談專案的成本規劃。(新產品開發專案)

UMC: Unit Manufacturing Cost 單位製造成本

UAC: Unit Actual Cost 單位實際成本 （UMC + 折舊攤提，投資攤提，＋設被攤提等）

UTC: Unit Transfer Cost （UAC ＋內部計價費用率 + 內部碳權計價）

管理其實也可以很Easy--專案管理與孫子兵法(30)

甘特圖

        相信大部分接觸過專案管理的人，對甘特圖都不會陌生才對。但甘特圖帶給專案經理人的印象是正面多於負面的呢？還是負面多於正面的？在專案管理領域，這幾種規劃的手法，各有其優缺點，無法簡單評估其好壞。但如果從管理的方便性來看，無疑的，甘特圖是一個簡單又方便的時程管理工具。

        甘特圖(Gantt Chart)是甘特(Henry L. Gantt)於1917年所發展出來的工具，經過幾十年來的推廣，已經被廣泛的運用在規畫、控管及評估專案的各項進度。甘特圖其實就是一個矩陣，縱軸為專案的各個任務項目，橫軸為時間軸，把時間展開成為一條直線行徑。相對應的項目時間以棒形狀或是線型來連結，線(或是棒)的長短代表所需要時間的長短，如此構成一個時程表。

        橫軸的時間單位，可以依專案的大小來劃分。以天、週、月、季、年等為單位。中間的棒形圖或是線型，可以依自己的喜好而作適當的表示。譬如：用線型表示的時候，常以虛線表示計畫線，而實際進行的部分以實線為之，如此就可以一目了然的看到整個專案的進度變化。如果用棒形圖表示的時候，常以空白為計畫線，中間塗上顏色及代表完成的進度，也可以很清楚的看到整體的進行狀況。當然還有在線的兩端以三角形或是圓形符號表示，實際進行過程再把前後端的符號塗滿來表示進度，也同樣可以得到控管的目的。總之，甘特圖的運用彈性很高，端看自己的習慣。管理的目的只在追求更有效的方法，所有的工具充其量只是手段，沒有必要被工具綁住而模糊了焦點。

        甘特圖雖然簡單，但要完全發揮其特色，也非易事。甘特圖雖然簡單明瞭，但也有一些先天上的限制，就針對此一部分來談談。

        首先先來談談甘特圖的優點，其優點有：

        1. 容易上手，不需要特別的訓練與專業知識。

        2. 專案的進度能夠依據計畫與實績的對照，一目了然。

        3. 可以明確的看到進度的超前或是落後。(前提是真正有把甘特圖的管理融入到日常管理上)

        4. 可以很容易的電腦化。

        5. 作為報告的素材，是其他工具無法望其項背的。

        優點很多，但相對的缺點也是有的。主要缺點有：

        1. 甘特圖的最大問題是無法顯示各個項目間的互相關係，及邏輯順序。

        2. 沒辦法以一個個別項目的落後來評估整體的進度影響程度。

        3. 對於長期間或是大型專案，製作起來相對複雜度高，比較不容易，適用於中小型專案。

        4. 甘特圖無法顯示關鍵要徑。

        5. 在面臨策略考量，必須要調整專案時程時，不容易上手。

        6. 必須同時考慮專案工作與排定的工作進度。

        雖然各有優缺點，但依個人的經驗，在專案規劃時，可以用網路規畫工具(PERT & CPM)來進行策略規劃，而日常管理時，則用甘特圖來管控，可以達到簡單明瞭的效果。雖然看起來有兩個工作要做，還好現在的軟體工具(Project)，都可以將此兩種工具互相轉換，所以不會增加作業的工時。

        話雖如此，專案經理人也必須注意，用甘特圖進行專案控管時，常會碰到一翻兩瞪眼的窘境，結果只看到計畫不斷的往右延伸，專案除了推遲還是推遲，那就是夢饜不斷了。所以如果要用甘特圖控管時，做好日常管理才是關鍵成功要素。(大部分的管理會出現不斷推遲的原因，就是只知道Review，不知道日常管理)

管理其實也可以很Easy--專案管理與孫子兵法(29)

專案的資源配置-II

在專案規劃中，每個環節都是環環相扣，無法擇一而為，必須按步就班，一步一步來。首先從範疇的定義、目標設定、專案戰略形成等戰略思考。其次展開任務的規劃，從WBS展開、工時評估到網路規劃，再展開時程規畫等戰術的形成。這兩部分的重要度就如舞龍的龍珠與龍頭的角色，但問題是誰來操演龍珠？誰來舞龍頭，是一個舞龍活動的成功關鍵。資源配置就是這樣的一個步驟。今天我們就來談談資源配置的作法。

一個正常的專案，專案經理人對專案成員的能力與負荷的了解，理應瞭如指掌才對，最起碼也該知道成員所具備的能力是否足以承擔此一任務。在國外，PM會透過各種可能的管道，對成員進行多方面的了解，成了專業的能力以外，手頭上的工作負荷、工作的態度及以前的一些工作記錄等等，都會想辦法了解的越多越好，因為這些都足以左右專案的成敗。

遺憾的是國內的PM從來就不認為有此需要，經營者也沒有這樣的意識，結果一個蘿蔔一個坑的思維，總以為有一堆的人在一起做一件事，就是Team work了，殊不知這之間的差異，直有天壤之別。不重視這些客觀因素的結果，專案只有推遲，別無他途。

當WBS展開後，PM必須實施能力盤點，了解每個成員的能力與可用工時。沒有這些數據，任務分配將無法客觀對待，只是一種很膚淺的齊頭式分派工作。加上中國人在接受任務時，從來就不會據理以爭，總抱持著凡事盡力而為就是了，一旦碰到問題時，也只是兩手一攤，事不關己，如此專案管理，如何讓人放心。

個人與日本人接觸時間很長，也與美國人共事過，在日本，當工作分配超過個人的工時負荷量時，成員會拿著數據去跟主管討論，工時不夠了；美國人是在分配工作時，會斤斤計較任務量的多寡，但一旦決定後，就不再吵了；相對的咱們中國人是事前不吵，事後吵鬧不斷，結果推、拖、拉反成了常態，實在不是正常的專案管理模式。

那要如何分配任務呢？可以作一簡單的矩陣表來處理。矩陣表的縱軸為工作項目(Task)，橫軸為專案成員名單(Members)，交叉相關的格子可以以一斜線劃開，將格子分成兩個部分。格子的上方填入預備投入的工時，下方記載成員在這個工作的定位。定位一般分成四類，其分別為：1代表這個工作的主擔當者（Accountability)，換句話說就是這個部分的Sub負責人；2代表支援(Responsebility)，也就是共同負責或是備份的資源；3代表沒有參與此一任務，但必須被知會這個工作的一切訊息(Inform）。這代表與此一工作有一些上下游或是任務上的關聯；沒有任何符號的代表沒有相關。以下就簡單做個表格說明：

Role & Responsibility(1/1: 分子為需要工時；分母為負責職能，15/1：15為需要時間，1為主負責人)

                                                                                   Members

        Task                  A             B          C         D          E         F          G       Total

        報表定義          1/1         1/2                   2/2                   0/3         0/3          4       

        程式設計        15/1         3/2                   2/2                   0/3         0/3        20

        -------------------------------------------------------------------------------------------------

依照上面這個表來說明，有兩個任務，一為報表定義，另一為程式設計。報表定義由成員A主擔當，成員B與D為副擔當，F與G必須被告知，總共需要的工時為4天。程式設計部分主要由A君負責，B與C為副擔當，F與G必須被照會，總共需要20天的工時。如此全部分配完任務後，每位成員的負荷量是否適當，則可以再作一全面性的檢驗。務必把每個人的工時分配的恰得其份。

要把R&R做好，前提條件是有客觀的工時評估數據，與每個成員的能力與負荷的掌握。特別是後者，如果能力掌握度不夠，不只會耽擱個人的業務，也會影響到其他相關的作業，必須審慎為之。

很多PM會困惑如何去掌握成員的能力，這除了與成員面談外，向成員的直接主管請教，常是最有效的方法。因為主管對部屬的能力與負荷最了解不過了，再說分配資源給專案，機能主管也必須負擔必要的責任，所以機能主管將是專案主管的最佳內部顧問。

下期我們將來談談甘特圖。

管理其實也可以很Easy--專案管理與孫子兵法(28)

專案的資源配置

在專案規劃中，每個環節都是環環相扣，無法擇一而為，必須按部就班，一步一步來（當然採取同步工程的做法亦是一種選項，重點是條件是否充分與有此體質？還是只是嘴巴的同步工程？）。首先從範疇定義、目標設定、專案戰略形成等戰略思考。再依序展開任務規劃，從WBS展開、工時評估到網路規劃，時程規畫的展開等等戰術的形成。這兩部分的重要度就如一個成功的「舞龍戲碼」的龍珠與龍頭與戲碼的角色，問題是誰來操作龍珠？誰來舞龍頭，與整個戲碼的呈現（比賽的戲碼與娛樂的戲碼也不會一樣的）更是一個舞龍活動的成功關鍵。資源配置就是這樣的一個過程。今天我們就來談談資源配置的作法。

一個正常的專案，專案經理人對專案成員的能力與負荷的了解，雖然難以做到瞭如指掌，至少也該有所掌握才對，起碼成員所具備的能力是否足以承擔此一任務是必須確認的首要。一個專業的PM應該會透過各種可能的管道（面試、主管請教、人資探詢、以往的專案紀錄甚至動用顧問等等管道），對成員進行多方面的了解。成了能力以外，手頭上的工作負荷量、成員平常的工作的態度及以前的一些工作記錄等等，因為這些都足以左右專案的成敗。

遺憾的是國內的PM從來就不認為有此需要，或者說也無此能力（這是中階主管的主要職能之一），經營者或機能主管也沒有這樣的意識，一個蘿蔔一個坑的思維，總以為有足夠的人在一起做一件事，就是Teamwork了，殊不知這之間的差異，有天壤之別。沒有共同目標的承諾，只能說是一個Team，稱不上Teamwork。不重視這些客觀因素的結果，專案只有推遲，感嘆Always delay。

WBS展開後，PM的下一個要務就是資源盤點。

管理其實也可以很Easy--專案管理與孫子兵法(27)

專案的時程規畫

在上面的兩個WBS範例中，第二個範例有附上工時評估，其中的工時的基準是以每個星期五天的工作天來計算，屬於作業工時。1W=5D，轉換以日曆天數的評估方法，並還沒有評估到個別資源的負荷量與可用工時(R & R，預計下篇會談到此一部分)。

CPM網路規畫部分，直接用圖形說明會更清楚一些，所以個人準備了一個海報版，把前面範例的WBS展開成為一個網路範例，再附加說明，這樣應該能夠讓各位更清楚WBS、工時與網路規劃的工具運用手法。敬請稍待，如果各位有需要的話，這個WBS與CPM的範例可以提供給各位參考。有需要的話，請來mail索取(Tonyliaw@ms1.hinet.net)。

網路規劃如果只是把WBS展開的工作連結起來，那意義不是很大。網路規劃最有價值的部分是依據專案的戰略目標，針對有限的時間與資源的限制下，進行策略規劃，找到最佳要徑，做好資源配置。規劃中，一定會出現有：『這樣的安排，是否可能？』的疑問出現，這時不是只擔心萬一如何，而是要運用成員的專業，集思廣益，運用創意來找出解決方案，讓專案順利進行。

無論以金錢換取時間，或是以時間換取金錢，端看專案可能投入的資源而定。在資源有限的情況下，讓專案越早結束，對資源投資回收越有利。孫子兵法提到過，兵貴神速，其理在此。

管理其實也可以很Easy--專案管理與孫子兵法(26)

專案的時程規畫(WBS範例II)

範例：「人才變人財」專案WBS範例，為小弟當初開發一套教育訓練軟體系統專案的WBS，雖然時隔20年，應該還是有參考價值。

Prepared by：Anthony Liaw           Date：2005/12/10                 Version：1.1

                                                                     2007/7/6                     Version：1.2

          WBS                                                                               評估工時

1         專案可行性研究                                               5W4D

    1.1         專案事業計畫                                                        2W4D

       1.1.1    事業規劃                                                                                  2W

      1.1.2    損益評估                                                                                   2D

      1.1.3    行銷戰略                                                                                   2D

    1.2         系統分析                                                                 3W

      1.2.1    系統資源評估                                                                           3D

      1.2.2    技術可行性評估                                                                       2D

      1.2.3    系統分析(SA)                                                                           2W

2         專案企劃                                                           11W

    2.1         產品規格書制定                                                     6W

      2.1.1    需求調查                                                                                   2W

        2.1.1.1    客戶訪談                                                                                     1W

        2.1.1.2    需求調查                                                                                     1W

      2.1.2    需求整理                                                                                    4W

        2.1.2.1    草案製作                                                                                      2W

        2.1.2.2    規格討論與修訂                                                                         1W

        2.1.2.3  規格書發行                                                                                  1W

  2.2         BA(Business Analysis)                                            4W

       2.2.1    業務流程分析                                                                         1W

      2.2.2    作業模式定義                                                                         1W

      2.2.3    使用者介面定義                                                                      1W

      2.2.4    報表定義                                                                               1W

  2.3         資源評估與計畫                                                       1W

      2.3.1    工時評估                                                                               2D

      2.3.2    投資計畫編定                                                                         2D

      2.3.3    日程計劃                                                                               1D

3         系統設計                                                            7W3D

  3.1         系統架構設計                                                            4D

      3.1.1    Windows OS                                                                         2D

      3.1.2    Mac. OS                                                                              2D

  3.2         系統文件製作                                                            2W4D

      3.2.1    系統機能規格書                                                                     1W

      3.2.2    系統流程圖                                                                          3D

      3.2.3    子系統機能規格書                                                                 3D

      3.2.4    介面規格書                                                                          3D

  3.3         系統設計                                                                   4W

      3.3.1    Programming                                                                         3W

      3.3.2    Unit test                                                                               2D

      3.3.3    Debug                                                                                  3D

4         系統測試                                                            8W

  4.1         Linkage                                                                       2D

  4.2         DVT                                                                           4W1D

      4.2.1    System setup                                                                         1D

      4.2.2    相容性測試                                                                             1D

      4.2.3    Functional test                                                                       3D

      4.2.4    操作性測試                                                                             1D

      4.2.5    可靠性測試                                                                             1W

      4.2.6    Debug                                                                                   3D

      4.2.7    Problem Action List follow up                                                   2W

  4.3         αTest                                                                         1W2D

      4.3.1    測試者選擇                                                                             1D

      4.3.2    測試資訊收集                                                                         1W

      4.3.3    測試報告整理                                                                         1D

      4.3.4    Debug                                                                                  3D

  4.4         βTest                                                                         1W2D

      4.4.1    測試者選擇                                                                             1D

      4.4.2    測試資訊收集                                                                         1W

      4.4.3    測試報告整理                                                                         1D

      4.4.4    Debug                                                                                  3D

  4.5         測試報告彙總                                                           3D

5         手冊製作                                                            2W

  5.1         使用者手冊                                                               1W3D

      5.1.1    手冊layout設計                                                                       3D

      5.1.2    內容編制                                                                               1W

      5.1.3    使用手冊印製                                                                         1W

  5.2         銷售/服務手冊                                                          3D

      5.2.1    手冊設計                                                                               2D

      5.2.2    手冊製作                                                                              1D

6         量產準備                                                            2W2D

  6.1         BOM出圖                                                                 1D

  6.2         光碟母片製作                                                           1D

  6.3         包材設計                                                                 1W

  6.4         包材發包製作                                                           1W

7         量產                                                                    2W1D

  7.1      光碟壓片                                                                     1W

  7.2         包裝                                                                       1W

  7.3         開始出貨                                                                 1D

8      專案結案                                                            1W1D

  8.1    專案檢討                                                                      3D                             

  8.2    結案報告整理                                                               3D

  8.3    專案結案

管理其實也可以很Easy--專案管理與孫子兵法(25)

專案管理的WBS範例

這是以以前研發主管任內，新產品開發專案為範例，濃縮後的一份WBS。縱使每家企業的產品不盡相同，但新產品開發從品質保證的觀點來說，基本的步驟是無法避免的，參考價值應該毋庸置疑，就看如何轉換。

範例(I)：New Product Development WBS case study

製作人：Anthony Liaw 2007/7/4 Version：3.0

「海獺」專案WBS： 

1         商品企劃

    1.1      市場調查

      1.1.1                 SWOT分析

      1.1.2                 競爭分析

      1.1.3                 市場規模調查

      1.1.4.                商品戰略(Marketing 4P)

      1.1.5.                商品戰略DR(Design Review)

    1.2      需求調查與分析

      1.2.1                 需求調查

      1.2.2                 整理需求表

      1.2.3.                抽出客戶潛在痛點

      1.2.4.                客戶需求整理與確認

    1.3      產品規格製作

      1.3.1                 需求、規格轉換

      1.3.2                 規格書草案製作

      1.3.3                 規格與概念確認

      1.3.4                 規格書基本定案

      1.3.5                 商品規格書（Performance Spec.）發行與登錄

2         可行性評估

    2.1      目標展開

      2.1.1                 VA/VE成本分析

        2.1.1.1                   製造成本預估與計畫

          2.1.1.1.1                 材料成本

          2.1.1.1.2                 加工成本

        2.1.1.2                   單位製造成本

          2.1.1.2.1.                投資攤提

          2.1.1.2.2                 直、間接比率評估

          2.1.1.2.3                 外部耗材成本等評估

      2.1.2                 FMEA品質保證展開

        2.1.2.1                      品質資料收集

        2.1.2.2                      故障模式分析

          2.1.2.2.1                 故障模式收集

          2.1.2.2.2                 問題分析

          2.1.2.2.3                 製作FMEA表

        2.1.2.3                      FMEA轉設計管理Action plan提出

    2.2      商品構思案展開

      2.2.1                 機構架構

        2.2.1.1                      ID構思案製作

        2.2.1.2                      ID構思案評估

        2.2.1.3.                     ID概念案模型製作

        2.2.1.4                      ID概念案評估與選擇

        2.2.1.5                      ID備選方案測試與定案

      2.2.2                 電氣與電子(EE)

        2.2.2.1                      構思案製作

        2.2.2.2                      構思案評估

        2.2.2.3                      成本評估

      2.2.3                 軟體(韌體(FW) & Software)

        2.2.3.1                      構思案製作

        2.2.3.2                      構思案評估

        2.2.3.3                      使用介面設計(User Interface)

    2.3        技術可行性評估

      2.3.1                 Q、C、D確認

      2.3.2                 技術風險評估

        2.3.2.1                      抽出技術風險項目

        2.3.2.2                      技術風險度評估

        2.3.2.3                      風險管理表製作

        2.3.2.4                      風險應對計畫

        2.3.2.5                      TAP展開(Technical Action Plan)

3         量產設計

    3.1      DFM/DFA構思

      3.1.1                 文獻調查

      3.1.2                 專利調查

        3.1.2.1                      專利檢索

        3.1.2.2                      專利地圖製作

        3.1.2.3                      專利策略制定

      3.1.3                 技術資料調查

      3.1.4                 架構檢討

    3.2      設計(DFX)

      3.2.1                 理論邏輯設計

      3.2.2                 目標評估

    3.3      實驗(DFT/DFR/MSA…..)

      3.3.1                 實驗材料準備(Sample機備品準備、組裝與基本確認)

      3.3.2                 實驗室安排

      3.3.3                 資料與文件準備

      3.3.4                 人員訓練

3.3.5                 實驗與分析

    3.4      製圖

      3.4.1                 圖號申請

      3.4.2                 草圖製作

      3.4.3                 製圖與確認

      3.4.4                 檢圖與發圖

    3.5      圖面檢討

      3.5.1                 重要尺寸

      3.5.2                 品質問題確認

      3.5.3                 成本合適性

    3.6      圖面登錄(出圖)

    3.7      BOM製作

4         試作

    4.1      圖面發行

      4.1.1                 圖面檢討

        4.1.1.1                      重要尺寸檢討

        4.1.1.2                      可靠性部品檢討

      4.1.2                 BOM確認

    4.2      廠商決定

      4.2.1                 供應商評選(AVL)

        4.2.1.1                      SQA戰略確定

4.2.1.2                      供應商評選(NEW)

        4.2.1.3                      供應商產能調查(OLD)

        4.2.1.4                      供應商工程能力評估

      4.2.2                 成本評估

        4.2.2.1                      詢價

        4.2.2.2                      估價

        4.2.2.3                      價格審核

          4.2.2.3.1                 估價單回收整理

          4.2.2.3.2                 價格審核

        4.2.2.4                      議價

        4.2.2.5                      決定成本

      4.2.3                 決定廠商

    4.3      樣品訂製

      4.3.1                 發樣品訂單

      4.3.2                 廠商圖面確認

        4.3.2.1                      圖面確認單

        4.3.2.2                      版次確認

      4.3.3                 樣品製作

        4.3.3.1                      製造規格製作

        4.3.3.2                      作業標準書製作

        4.3.3.3                      品質管理基準確認

        4.3.3.4                      可靠性部品試驗

        4.3.3.5                      試驗規格確認

    4.4      零件驗收

      4.4.1                 數量驗收

      4.4.2                 品質檢驗

    4.5      樣品組立

      4.5.1                 製造規格書製作

      4.5.2                 人員訓練

      4.5.3                 作業標準書製作

      4.5.4                 品質管理基準制定

      4.5.5                 品質檢驗(機能與組立)

    4.6      品質驗證(DVT)

      4.6.1                 DVT計畫製作

      4.6.2                 DVT準備(4M2S)

        4.6.2.1                      設備準備

          4.6.2.1.1                 試驗儀器/設備

          4.6.2.1.2                 試驗耗材

        4.6.2.2                      人員訓練

        4.6.2.3                      表格準備

          4.6.2.3.1                 工作分配表

          4.6.2.3.2                 試驗矩陣表

          4.6.2.3.3                 DVT試驗查檢表

          4.6.2.3.4                 Data收集表

          4.6.2.3.5                 Trouble sheet

          4.6.2.3.6                 PAL(Problem Action List follow up)

          4.6.2.3.7                 Trouble統計表

        4.6.2.4                      場地準備

      4.6.3                 品質試驗(DVT)

        4.6.3.1                      試驗

          4.6.3.1.1                 機能測試

          4.6.3.1.2                 操作性試驗

          4.6.3.1.3                 可靠性測試

            4.6.3.1.3.1                      環境試驗

            4.6.3.1.3.2                      可靠性試驗

            4.6.3.1.3.3                      物流測試

               4.6.3.1.3.3.1                           搬運測試

               4.6.3.1.3.3.2                           儲放測試

               4.6.3.1.3.3.3                           震動試驗

               4.6.3.1.3.3.4                           落下試驗

        4.6.3.2                      Trouble shooting

      4.6.4                 安全規範測試

        4.6.4.1                      測試方法與場地選擇

        4.6.4.2                      測試

        4.6.4.3                      Trouble shooting

      4.6.5                 試驗報告整理

    4.7      品質驗收

      4.7.1                 設計審查

        4.7.1.1                      品質達成度確認

        4.7.1.2                      Trouble處理狀況確認

        4.7.1.3                      QA確認

      4.7.2                 移行判斷

5         量產準備

    5.1      生產準備

      5.1.1                 最新圖面確認

      5.1.2                 廠商4M2S準備

        5.1.2.1                      生產準備4M2S確認

        5.1.2.2                      圖面及訂單確認

      5.1.3                 內部生產4M2S準備

        5.1.3.1                      BOM確認

        5.1.3.2                      QC工程表準備

        5.1.3.3                      作業標準書準備

        5.1.3.4                      檢驗標準書準備

        5.1.3.5                      製造規格書製作

      5.1.4                 量產計畫與生產預測

        5.1.4.1                      零件集結

        5.1.4.2                      Long Lead Time零件訂單

        5.1.4.3                      一般部品訂單確認

    5.2      行銷準備

      5.2.1                 廣報準備

        5.2.1.1                      型錄製作

        5.2.1.2                      海報製作

        5.2.1.3                      對外廣報發行

        5.2.1.4                      銷售手冊製作

        5.2.1.5                      新產品發表會

      5.2.2                 銷售人員訓練

      5.2.3                 樣品出貨

        5.2.3.1                      經銷商教育

        5.2.3.2                      樣品需求調查

        5.2.3.3                      樣品出貨

    5.3      品質保證

6         量產/行銷

7         售後服務 

8         專案結案

    8.1.     專案資料整理與匯總

    8.2.     專案結案Design Review

       8.2.1                商品企劃Review

       8.2.2                設計Review

       8.2.3.               品質保證Review

       8.2.4.               事業興Review

       8.2.5.               專案管理Review

    8.3.     技術移轉

    8.4.     專案結束後之業務移轉

    8.5.     專案結案

       8.5.1.               資料歸檔

       8.5.2.               業務交接

       8.5.3.               資源歸建

       8.5.4                專案結案

       8.5.5                激勵團隊

只要把每個子項目的最低階層的業務工時展開，就可以匯總出整個專案的需求工時了。

其次，在專案裡每個階段的移行判斷都有個工作要做，就是依據移行判斷基準進行設計審查（DR)，以確保品質保證的落實，這部分也都該列入WBS的範圍，因為會有工時與業務連結的關聯性，少了就容易出錯，也不太能夠精準的管理。

管理其實也可以很easy--專案管理與孫子兵法(24)

專案的時程規劃(Scheduling)2024-6-25

完成WBS的展開，做好工時評估後，緊接著就是進行時程規畫的部分了。WBS讓我們把該做的事情細部的展開，藉此知道有多少的事情要做。針對WBS展出來最底層的作業項目，進行工時評估，再加總計算出整個專案必須投入的資源。再將這些工作細項依業務關係進行連結，完成整個資源運作的網路關係，這就是時程規畫。

不管專案規模多大，或只是一個小小的業務改善，都必須從日常管理一點一滴做起，所以讓專案的業務聯結到日程安排，是一個專案要成功的不二法門。問題是當在進行網路規劃時，馬上會面臨一些問題，首先，規劃的時程是否有將例假日排除？理論上合理的做法是不應該在例假日安排業務的(世界各國都一樣有類似勞基法保護勞工的措施)，如果真的有必要的話，那就要算加班，投入的總資源時間一樣，但成本是有差異。站在專案績效的角度來說，內涵不一樣。

另外時程的安排，原則上也不應該把加班的工時算進去，才是正確的做法。換句話說，工時的評估都是以正常工時為基礎，加班屬於額外的工時，不能視之為常態。還有，如果公司採取的是多專案管理的話，那不只要評估當專案所需要的工時外，還需要評估成員的資源殘餘量(因為已大部分被其他的專案所分派了)，可以投入的時間，才不致於發生實際運作上資源衝突的現象發生。

問題是國內的專案，幾乎都有意無意的忽略這些客觀因素，總是不去考慮這些問題，應了一句台灣俗諺所說的：『橫柴塞入灶』，結果如何，自不在話下。依據美國PMI針對常見專案管理失敗的原因統計，不理會客觀因素的失敗率是首位，道理很簡單，人力不等於能力。

那如何把WBS、工時與PERT連結起來呢？接下來就來談談網路規畫的技巧與重點。

網路規劃的做法就是把作業的最基本要素(WBS展開的最底層的業務項目)，先判斷每兩個業務間的關係。整理出有那些業務有上下游關係，哪些沒有關係，再依據關係連結成一個網路。最簡單的方法就是接龍式的安排，一個業務接一個業務，一條龍似的連結。此種作法最單純，但專案的時間等於所有工時的加總，也就是時間花費最長的專案。這種做法不可能被接受，一來時間太不經濟了，失去了運用專案的意義；二來也不是每個工作都有關係的，全部以銜接式的連結，也會出現一些斷層。再說有很多的項目是可以並行作業的，反之，如果把所有的業務都並行處理，那是不是專案的時間最短，這就是同步工程的基本概念。

當然不見得每個業務都能並行處理，但如果並行的業務越多，是否意味著時間上越有效率，但相對的也會出現一些風險。那要如何判斷，與如何安排？首先還是回到WBS展開的步驟，把WBS展開弄清楚，安排上自然會比較容易。WBS展開可以用兩種思考模式來處理，一為依據作業流程展開工作；另一種方法是依據參與的功能來展開，基本上最後都殊途同歸，因為就是那些必要的業務。

(下一篇文章將放入兩個個人所整理的WBS範例，供各位參考)待續

管理其實也可以很Easy--專案管理與孫子兵法(23)

專案的網路規劃的重點(WBS與工時評估上的問題)2024-6-24

在專案規劃，常有人會面臨如何評估工時的困擾。譬如說，有一個產品開發專案，其中有個工作是委外的打樣。實際需要的直接工時是8個小時，但外包廠商是分別在四個禮拜做。很多人就問到，到底要算8個小時的工時呢？還是一個月的工時？因為在網路規劃中，這兩個工時將會出現截然不同的結果。相信很多人多少為此問題困擾過，今天就來談談此一現象的問題。

這個問題的根源來自於WBS展開的不夠完全所致。我們在展開WBS的時候，如果碰到這樣的問題，外包廠商將一個工作分成四個階段來做，那這個外包工作必須展開成為試作一、試作二、試作三及試作四等四個業務項目。每個項目的工時評估是兩個小時，但業務是分段做，如此才可以正確的規劃出業務的銜接關係。否則一個試作工作就是一個月，中間幾乎也無從管理起。

另外工時評估時，我們一般是以作業工時(Working hour)評估，一旦要展開時程表時，就必須要換算成日曆工時了，否則會出現現實與實際的差異。日曆工時包含任務工時(作業工時)、游離工時、移動工時及其它閒置工時。如果單位內沒有做工時管理的習慣的話，這部分恐怕會造成很大的困擾，因為沒有客觀的數據可以評估，只能以印像與經驗法則來規劃，那籌碼的問題與以前的錯誤經驗都可能會影響到專案的資源投入。

其實這個問題還有許多討論的空間。

第一：應該先了解為何這個作業需要分成四個階段？如果沒有特定原因，那為何無法一次就搞定？因為這關係到下游工程的銜接業務，如果其中還有一些必要性的業務存在，在規劃中要考慮的是否還有調整的空間。

第二：如果一定要分成四個階段來實施，那每個禮拜兩個小時作業後，是否還有其他的作業？如果有的話，就應該在WBS中充分展現出來，才不至於在網路規劃中遺漏掉，到時又會出現管理上的漏失。以這樣的作業來說，外包試作這個業務下的WBS應該至少包含有三個部分。其分別為：試作、檢驗、修改。所以工時也不會只有兩個小時，每個作業都會有其必要的工時。

第三：不管怎麼說，這種嘗試錯誤(Try and Error)的做法，對專案沒有幫助，反而會帶來一些時間上的浪費。在網路規劃的過程，應該以標竿的方式來進行安排，才能夠發揮最高的資源效率。因此在規劃過程中，如果碰到這種情形，以創意的觀念來思考是否有改變的空間？如何做可以突破等，才是正確的專案管理思維（敏捷）。

綜觀上述的問題，WBS的重要性不言可喻，忽視不得。另外還有一種情形，也是專案規劃中必須審慎面對的問題。有人問到工時評估好像都是以理想的思維來規劃，但現實有很多不可預料的突發事件會發生，評估出來的工時是否有意義？最後還是不得不推遲了。

這個問題比上個問題更值得好好思考，專案的特性之一就是不確定性高，如果甚麼事情都可以完全掌握，那根本不需要專案管理。專案規劃過程，有很多的不確定性，工時評估是以需要達成的目標為基礎，思考如何讓資源的配置，做到最佳化。在評估工時時。遇到不確定性高的作業，評估以悲觀的工時規劃，此時這類項目應當列入風險管理項目。而所評估出來的工時，一定還會存在一些不確定性，這就是管理的重點，應該思考要用甚麼手段來完成（創意思考）。專案管理如果沒有一些創意來支持，或是只會應用經驗法則來處理，那專案存在的價值也就不是那麼的有價值了。創意是突破專案風險的唯一手段，也是面對風險的專案特質的唯一解方。

管理其實也可以很Easy--專案管理與孫子兵法(22)
專案的時程規畫(籌碼如何給才有效？)
昨天我們談到要不要給籌碼，結論是需要的，但問題是如何給？怎麼給才有效？今天我們不妨就來談談如何給籌碼這個話題。
       這個話題無論對企業經營者也好，專案主管也好，甚或功能主管而言，都是一個值得深入探討的話題。首先要先確定一下，為何要給籌碼(Buffer)？如果這個問題都無法確定，那籌碼絕對無法發揮應有的價值。
        專案管理的節點多，時間又受限制，諸多的不確定因素又是專案的特色，如果說能夠把工時抓的百分之百的精確，那是不切實際的想法。特別是專案的時間越長，變化就相對增大，如果沒有一點安全閥的設計，就如一個沒有安全裝置的鍋爐一樣，當壓力積壓到一個程度後，爆炸成了唯一的結果，所以給一些籌碼(Buffer)是必要的考量。
        就單一專案而言，這個問題還算好處理。只要找出關鍵要徑(Critical Path)，充分的細算工時與評估風險，針對關鍵點(Critical point)，只要適當的規劃一些籌碼工時，做好應變措施，控管上並不是太難。但以現在的電子產業來說，多專案同時進行的案子幾乎是無可避免的現象，一個人手頭上同時負責數個專案也是稀鬆平常的事。
這種情況下，傳統的關鍵要徑已不敷使用，工時的評估也變得複雜與麻煩。一個本來不是關鍵要徑的業務，會讓數個專案同時面臨到時程delay的困境，此時的工時評估與網路規劃，難度之高自不在話下。關鍵要徑的觀念已無法滿足多專案管理的需要，取而代之的是關鍵鏈(Critical Chain)管理，才能夠有效的達到多專案控管的效果。
        多專案管理已儼然成了是21世紀的專案常態，此部分有待往後設個篇幅，好好的來談談，現在先就單一專案來談談籌碼該如何給。
        上次我們談到那個簡單的專案(A、B、C)，還是以這個案例來說明。既然籌碼是濟急不濟窮的措施，那當然不該讓成員隨意浪費。如果每個工作的工時需要五天，網路規劃時不只不能加任何籌碼，三個工作的結合也應該採取壓縮式的規劃，而非傳統的銜接式業務規劃。所謂的壓縮式的規劃，就是讓三個工作有某些程度的重疊，簡而言之，就是採取小同步的方式。
當A進行任務的時候，不是等到結束才交給B，而是在工作還沒結束前，B就開始進行其負責的業務。這樣的規劃會讓成員增加壓力，但卻逼得成員必須依據計畫行事。同時要讓業務銜接順利，兩個上下游工作的成員，不得不採取事前規劃與緊密配合的做法，否則將沒完沒了，這是採取同步工程必須承受的風險。
為了紓解過程的風險，工時的籌碼，將其放在業務最後面的部分，並且依影響專案的程度，切割為綠燈、黃燈、紅燈（交通號誌）三個區段，由PM統籌調度。如果專案進行順利，專案籌碼可能會增加，籌碼的燈號將會停留在綠燈區；如果進行出現一點小問題，只要被吃掉的時間，還未突破設計的工時限度時，燈號將會顯示黃燈；當工時已大幅推遲，籌碼大量被侵蝕時，籌碼的紅燈亮起，此時PM就必須啟動緊急應變措施，將專案拉回正軌。專案主管運用交通號誌的顏色管理來處理籌碼的調度。
        由此類推，專案主管對籌碼的管理不再如以往的依靠專案會議控制就夠了，日常的進度管控，是不可忽略的重點。當然專案成員的工作申報要求，與業務品質的自我判斷等自我管理，都是成功的不二法門。這些也都是專案的基本功，遺憾的是國內的企業都不願意面對這些基本的客觀問題，專案的管理只靠一個PMP或是一堆的PMP都無濟於事。

        Team work的重點是一堆人的力量，專案管理的目的之一就是要以三個人發揮五個人的工作績效為目標，效率大幅提高的前提條件不是因為有專案，而是因為有一些別於傳統功能式組織管理的技巧與運作模式，這些的技巧與客觀因素都是企業不得輕視的，否則只會看到空架子，卻無法得到專案模式帶來的效益。
        這部分如果能夠以實務來說明會更清楚，但部落格屬於文章形式，無法互動。為了改變這樣的態勢，個人有個想法，如果各位有心在這個領域發展，或是碰到問題，麻煩發個聲，如果人數多的話，個人就來個直播會說明與互動，甚至辦個研討會都OK，費用盡可能地找個單位來吸收。

        所以請各位有興趣者，在部落格留個言話發個聲，好統計人數。

管理其實也可以很Easy--專案管理與孫子兵法(21)

專案的網路規劃的重點(該不該給籌碼)2024-6-13

專案時程規畫中，兩個最重要的工具(PERT & CPM)我們談了一點，如果能夠以繪圖的方式來說明，相信效果會好得多，但如何在Blog上繪圖，有其難處，畢竟部落格已不是主流媒體，系統商不會花錢在這個領域，請各位見諒。

時程規劃中，還有一個常被運用的甘特圖（台灣人最喜歡用的時程規劃工具），有待我們慢慢來說明。但不管您採用哪個工具，相信有個問題，一定困擾著很多的專案經理人，那就是工時評估中，到底要不要給Buffer(俗稱的籌碼、寬裕工時)。這是時程規畫中最基本的問題，也是眾說紛紜的一個問題。

有人認為需要，因為世事難料，突發事件在所難免。也有人主張不該給，因為給了籌碼，那計畫就失去意義了，因為會扭曲工時與資源的關係。問題的重點不在此，當計畫中加了籌碼後，是不是有發揮籌碼的功能？如果給了有效，那為何不給？如果給了仍然無效，那又是為何？

其實這個問題會衍生很多的管理性問題，值得好好的談談。首先在專案中，所謂的籌碼指的是甚麼，這點必須先定義清楚。很多人誤解籌碼就是在評估出來的工時外，加上一些寬裕的時間，以避免因為某些突發事件，排擠後續工程而設的。這種觀念似是而非，相當不恰當。

先來談談一般專案的運作模式。請教諸君，您日常的工作習慣是依據計畫，一步一步的往後推動，還是從後面的期限日往前推算？理論上應該是依據計畫進行才對，但大部分的人的工作習慣卻是由後往前推算的。譬如說，每年的暑假作業有幾個人從7月1號開始，就照著計畫每天寫的。是不是大多數的人都會拖到8月底才一口氣趕完，這就是典型的暑假作業徵候群。如果有這樣的工作習慣，那所加上的籌碼，不只沒有發揮應有的功能，反而讓你產生我還有籌碼的假象，殊不知這些籌碼在不知不覺中已都被消耗掉了還不自知。更可怕的是，如果專案推遲，下一次的專案在評估工時時，這些籌碼還是不斷的被加碼上去，那問題可就嚴重了。

現在以一個簡單的計畫來說明，假設有個專案，其中有三個小任務，分別稱之為A、B、C。每個任務需要時間為5天，本來是15天要完成的專案，現在每個任務上都被加了兩天的籌碼，每個任務工時成了7天，總工時21天。這大概不是甚麼問題，但實際執行上會出現怎樣的現象，容我來為各位說清楚、講明白。

除了上面所談的暑假作業徵候群的現象外，如果負責A的成員完全照規矩來，五天內完成任務，請教各位，A君是否會主動提出申報，任務完成？這是第一個問題。即使A君提出申報，工作完成，請問B君會不會提前進行B項任務？如果這兩者的答案都是否定的話，那籌碼不是失去了該有的意義了嗎？您說籌碼需要嗎？

籌碼在專案中是一個很重要的安全閥功能，如何編列與如何運用卻是一個不易處理的問題。上述所言的現象，普遍存在國內的專案，大家也都心知肚明，卻有又能怎樣的無奈感。這些問題都是對籌碼的了解不夠，或者誤解所致。加上每個單位有其企業文化，如果沒有弄清楚的話，籌碼反成了專案主管的痛，疏忽不得。

籌碼指的並不是在工時外加上額外的時間的這種邏輯概念，籌碼有幾種定義，簡述如下：

1. 前幾次提到的ES、EF、LS、LF的時間，ES與LS間的空擋就是一種籌碼的觀念。

2. 每個工時評估的過程都帶有某種程度的不確定性，但因為有些考慮到樂觀工時，有些考慮到悲觀工時的情形，所以實際執行上會有一些變化，如果有超出預期的好的部分，那多餘出來的零碎時間，就是另外的一種籌碼。

3. 一般新產品的開發專案，工程師在評估工時的時候，是不該把加班工時算進去的，加班其實就是工程師的另類籌碼。遺憾的是，如果加班成了常態，那籌碼的意義都消失殆盡了。

4. 既使在專案中要給籌碼，籌碼不是給每個成員的，而是給專案主管統籌運用的，所以籌碼是放在最後面，而非每個步驟加籌碼。

5. 專案的定義中，開宗明義的就談到，在有限的時間內完成非常態性的特定任務，所以不確定性高。因之，時間只會遞減，不會增加，所以要如何在每個任務上擠出零碎的工時，把這些零碎的工時集中管理，做為未來的籌碼，才是正確的籌碼概念。所以專案主管對籌碼的觀念與運用手法，都必須很清楚的掌握其訣竅。

待續！

管理其實也可以很Easy--專案管理與孫子兵法(20)

專案的時程規畫-II

(本文發表時間為2010/3/1，很快的，離今天已過了十多年了)今天繼續來談談網路規劃的工具 (PERT與CPM) 。

當初在大陸遊走，跑了很多城市，看到了一些奇特的現象，不免為台商的未來感到憂心，現在這些現象都在貿易保護大傘之下，慢慢地沈澱了，算是美國的貿易保護加上大陸的內部經濟情勢，讓台商得到一些退場的保護傘。

台商以低廉勞工為競爭力來源的思維，總以為勞動成本低廉，可以實現低薪槓桿，大肆膨脹產業規模，而不思改善效率與自動化，動不動就以人海戰術為唯一的指導原則，真讓人為他們捏把冷汗。只會以人力為生產力的製造思維，當面臨越來越嚴苛的勞動條件惡化，台商的競爭優勢將慢慢消失，屆時是否又要再外移了？一個吉普賽式的經營模式，將會是台商的宿命。

退出中國製造在川普的大旗揮灑之下開始發酵，拜登總統的無作為（應該來台灣學學總統學），蕭歸曹隨。為了選舉，更擴大抵制的政策。加上大陸受到種種因素影響，內部經濟環境惡劣，外資該撤的也撤得差不多了，有點像六四時期的那種氣氛。（世界上已無聯合國，更甭談世界貿易組織，這兩個單位都卸甲歸田了。ESG歐盟主導，WTO美國說得算，地域危機看美國臉色，連2030 SDGs的政策，似乎沒看到有什麼國家在買聯合國的單…..）

反觀大陸本土企業，管理水平雖不如台灣，但「學習意願」與「借腦戰略」，處處顯露出旺盛的企圖心，只要再假以時日，台灣的競爭優勢將完全喪失，屆時很可能成為大陸品牌的代工廠的情形，大概無可避免了（現在已都實現了，貿易保護的政策下，逼得內在的自我繁殖，很多看似不可能的都一一實現了。電動車、無人飛機、通信系統、手機等等，甚至連白家電都無需再依賴日本台灣的技術了）。

當時，大陸企業流行「借腦戰略」，運用別人的優勢，短期間內醍醐灌頂，快速吸取先進國家多年累積的經驗，是最典型的知識管理實踐者。有個故事，大約十五年前，有次北大與清大的學者合辦了一個產學合作的研討會，出席的大概就是大陸當年檯面上的大企業，如聯想、北大方正、美的等等。主要目的是探討如何運用學界的力量，為產業發展盡一份力量。

會議中與會的教授都大聲疾呼：「我們有這麼優秀的人才，為何你們這些企業都還要聘請外面的顧問，真是捨近求遠。」這些教授抱怨大企業聘請外部顧問，特別是找台灣老師。在結論的時候，聯想集團的楊元慶總裁起身做結論，特別說了一段話，他說：「台灣人花了三十年才累積到今天的能量，我們只要花上一點點錢，就能夠把他們的經驗學到，有何不妥，難道我們還要花三十年摸索嗎？這就是最划算的借腦。」借重外部的頭腦，就像天龍八部中的虛竹一樣，直接接受了無涯子的七十年功力，就是最直接的複製專家、典型的知識管理。

所以大陸公司在聘請顧問的時候，根本不在乎價位，只關注是否有能力、有效。反觀台商，只斤斤計較價錢，反而不在乎是否有能力、有效。一上一下相較之下，我消敵長，台商的優勢將很快的消失，前途堪虞。如何轉型與突破，不再迷信低廉的勞動人力成本，整個思維才有可能轉進。

遺憾的是，大部分的台商，還是迷信人力成本，對效率與長遠之計的自動化以及研發投資，都採取漠視或是有意的忽略，再過十年，整個競爭優勢將重新洗牌，不知屆時要在外移到哪裡？喜馬拉雅山下吧！(十多年前的預測，果真實現，感嘆顧問的話不值錢！十多年來看到期間的變化，在大陸商業模式出現了滴滴打的、美團、阿里巴巴、京東等等；製造領域出現了工業4.0，無人駕駛以及電動車、AI等等，台灣企業似乎還只能當供應鏈的一員，要主導產業的趨勢，可能力猶未怠吧！)

這幾天台灣掀起黃仁勳旋風，一下子又製造出一個台灣之光。這是一家美國公司，處處受美國政策之控制，台灣人的造神心態，也處處顯露內心的焦慮，整體的水準提升，不是一個人的成功，而是貧富差距與整體生活條件的改善。貧富差距66.8倍的數字，不也正是造神運動創造出來的現象。台灣空屋超過兩百萬戶，空屋越多房價越高的怪現象，是ESG的逆旅？

幫大陸企業上課與幫台商上課做一比較，有很大的感觸。台商幹部的自大，已幾近於「不知道自己不知道」的地步了。忙碌，成了唯一的工作，一旦被派到了大陸，停止學習已不足以形容身處競爭叢林的困境，加速折舊才是可怕的問題。每次上課，幾乎都是陸幹，台幹總以為自己已經夠了（當然，老闆都認為給了外地津貼了，本來就是來付出的，不是來成長的，台幹不需要學習的心態也是很普遍），忙碌到沒有時間再成長，這種迷思，將讓台幹步入職場慢性自殺的邊緣；而大陸的年輕人，在一個制度還未成形的環境下，拼命的吸收能量，只要有機會就來上課。雖然消化能力還差，但對他門而言都是新的，所以願意花時間成長，因為尚未定型，反而有無限的可能，只要假以時日，任督二脈打通，那一天台幹將會變成為台商的包袱，而非資產了。如何突破此一困境，恐怕是所有台商老闆必須面對的經營課題。

話夾子一打開，就關不住，又把主題給耽擱了，還是先來談談PERT的部分。PERT是一個很好用的時程管理工具，台灣企業比較不常用，稍微複雜一點，就因為面面俱到。使用PERT時，會出現幾個名詞，先了解一下。其分別是：

ES：The earliest time when an activity can start最早啟動時間

EF：The earliest time when an activity can finish最早完成時間

LS：The latest time when an activity can start最晚啟動時間

LF：The latest time when an activity can finish最晚完成時間

Slack(寬裕工時) = Te - Tl (Time earliest time - Time latest date)

定義Slack time常用一條箭頭線，在線的上、下兩方，以如下的方式表示：

A(ES，EF)，A(8，10) 

◎------------------------------->◎

2(LS，LF)，2(15，17)

上面的(A)指的是這個工作任務的代號，8代表ES最早啟動日期如：6/8日、10代表EF最早完成時間6/10日。下面的2代表這個工作需要兩天的工時，15代表LS最晚啟動時間6/15、17代表LF最晚完成時間。

這樣的時程表示，說明這個工作項目可以有7天的寬裕工時，(15 – 8=7 Buffer)。用PERT的時程標示方法，可以很清楚的看到目前進度，與最快與最慢完成的可能時間，掌握寬裕工時，隨做必要的調整，也是PM很重要的資源。

管理其實也可以很Easy--專案管理與孫子兵法(19)

專案的網路規劃的工具

上次我們談到網路規劃的幾個工具，有人問到，PERT與CPM有何差異，如何運用？今天我們就來談談這兩個工具的差異與用法。

嚴格來說，這兩個工具是大同小異，而且也是可以互換的。兩者間的差異略述如下：

1. 其最大的差別是PERT用了三個時間的評估，樂觀工時、悲觀工時與一般工時的三種可能工時，然後採取{(樂觀工時+一般可能工時 X 4 + 悲觀工時) / 6}的統計的概率方式來評估需要的工時。在網路上直接標示開始時間，需要工時與預計完成時間，很清楚的掌握工作的杜杜。而CPM評估需要工時的方法一樣，但在網路上，則只顯示需要工時。

2. PERT是一種自然概率，以Beta分配為基礎，常態分配來評估需要的時間。這可以讓我們針對整個專案進行風險評估。而CPM只是用一個時間，採取自然分配方式來決定。

3. PERT與CPM都允許以假設的前提來發展專案的邏輯。

4. PERT比較常用於在工時評估變異高的研發專案管理的領域，而CPM則是比較常用在對資源依賴度高，時間累加的建築專案的案子。

5. PERT常用在除了里程碑的完成度外，進度完成的百分比大多數不容易決定的研發專案。CPM則是用在完成度是線性累積的，結案也可以以進度來執行請款作業的建築專案。

接下來還是再詳細的介紹一下這兩個工具的用法。

在管理領域，管理學者不斷的在找尋更好的管理方法，以滿足對客戶的承諾。PERT、CPM、LOB(Line Of Balance)及甘特圖都是發展於第二次世界大戰期間。首先談談PERT。PERT發展於1958年，美國海軍的一個專案開始，當時發覺到泰勒與甘特都不適用於所要解決的問題，所以由美國海軍的專案事務局發展出這樣的一套工具，由於好用又有效，一下子就快速、廣泛的被運用於各個領域。PERT有幾個優點，簡述如下：

1. 可以展開一個完整的網路，進行關鍵要徑分析。

2.可以依據目標的需求，進行策略性的規劃，尋找替代方案等。

3. 可以評估專案的中途變更對整個專案的影響度，以利專案的必要取捨決策。

4. 因為有充分的數據支撐，可以作為客戶與合約者之間的討論材料。

綜觀而言，PERT可以幫助做到以下的幾點：

1. 降低專案的成本與時間。

2. 協調與加速專案的計畫。

3. 消除一些等待時間。

4. 提供一個更有效的日程表與管控各個節點。

5. 發展好的問題解決程序。

6. 可以降低一些日常會議的時間需要，但可以增加決策時間。

今天先談到此，明天續談如何應用。

管理其實也可以很Easy-國內技術發展之遠憂—談談國內工程師壽命短之問題

Anthony Liaw 2015/3/14 Version：1.0

歐美先進國家，只要進到研發部門，望眼看去，四、五十歲之工程師比比皆是；相較之下，國內工程師年齡層就低了好大一截，三十歲以上不多，四十歲以上幾乎看不到，為何？

個人在全錄(XEROX)公司上班過，當了幾十年顧問，主要都在指導企業有關研究發展方面之管理。關於此一問題，也做了一些研究，提出來與大家分享一下個人觀點，希望拋磚引玉，可以共同來討論一個對中國人世界年輕工程師未來發展關鍵議題。

國內企業急功近利之社會氛圍，讓工程師成了機械式(重複動作)之工作，只是在完成一個工作。工程師本來是一個很強調人文、感性地職種，存在之目的，就是解決生活上出現之問題。這些問題包括使用者碰到地困擾、企業成立宗旨(賺錢)、突破現況之慾望…..等等，用一些前所未有之方法，讓問題得到有效解決，這些新方法之出現，我們稱之為”創新”。

一旦當”創新”只剩下應付性之想法，唯一目標就是想辦法幫企業賺錢。忽略使用者(市場)之問題時，”創新”不再是產品開發之重點，”創新”有多少地風險必須承擔，時間與金錢之投入都充滿不確定性，對於企業經營者而言，沉重之經營壓力(KPI)，不得不尋求快速有效地方法，那就是Me too產品之開發，急功近利之社會氛圍於焉形成，這就是大陸工程師壽命短之主要原因之一。

一般而言，一個工程師，至少要到30~35歲才夠成熟到獨當一面，原因何在？一個人不管本科是那門專科，懂的只是一小部份基礎知識。隨著技術發展越來越細分化，工程師在系統設計中，只是其中之一個小螺絲釘，剛開始加入產品開發，承接前輩指派之任務，完成任務。在這個階段往往只知其一、不知其二，是十足地設計機器(Design Machine)一個。

經過一段時間之歷練，慢慢接觸到不同領域間之介面激盪，從使用分析(BA:Business Analysis、Why)，到系統分析(SA:System Analysis)、規劃(How)，最後決定最好之技術或方法(What)，設計出一個解決問題(Needs)之系統。這樣地歷練過程，沒有五到十年功夫，很難建構完整之系統觀。

反觀國內技術發展，受到快速、高度經濟發展之影響，無目標地多樣化與快速化，新產品開發量需求大增，快速複製專家需求下，把泰勒博士之IE觀念融入到新產品開發，讓工程師無法強調”創新”，只能快速地把任務交付，以便應付下一個任務，結果就是瞎子摸象，只學到皮毛，難窺殿堂。

另一個現象是屬於制度面問題。歐美先進國家，職業待遇並不會因為是工程師或管理職而有所差別。雙軌制待遇設計，讓喜歡技術，不喜歡管理之工程師，可以全心投入技術領域，不會有矮人一截之嘆。在國內就不一樣了，進入管理職待遇才可能提高，逼得每個人不得不往管理窄門擠。眾所皆知，大部份工程師特質並不適合管理這條路。少了制度設計，工程師無法沉澱，在技術還未成熟前，就離開技術領域，結果出現半調調充斥之技術管理環境。

工程師成熟度不夠，最大問題就是設計之產品只見匠氣、沒有靈性；設計變更(ECN)一籮筐，補破網式地項目交付…..；最辛苦地當屬技術主管，成了救火隊長，可是技術主管從來都不想這個問題(應該沒時間想吧！)