管理其實也可以很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)一籮筐，補破網式地項目交付…..；最辛苦地當屬技術主管，成了救火隊長，可是技術主管從來都不想這個問題(應該沒時間想吧！)

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

專案的時程規畫 2024-6-2

利用網路規劃，將資源的配置做到最佳化，是專案管理的門檻。雖然網路規劃的工具(甘特圖、CPM、PERT、CPA等)並不算很複雜，但針對有限的資源，在有限的時間內，要讓專案的資源有效的配置，還是需要花點工夫。網路規劃的過程，有幾個關鍵的成功要素，必須注意：

1. WBS是否展得夠精確(太粗的WBS只能做出里程碑的規劃，無法看出一些策略性的規劃)？

2. 工時的評估是否客觀準確(工作工時與日曆工時間的關係，以及是否有客觀的工時數據，數據的品質等等)？

3. 細部作業的上、下游關係是否能夠清楚的定義，可以互相間以科學的流程概念來設計工作網路？這部分在規劃階段的「業務規格書」扮演一個關鍵性的角色。

4. 專案的時間明顯不足，受到壓縮時，採取同步工程規劃的誇機能小組管理的規範是否明確？

5. 每個成員的負荷是否確實掌握？（成員的可用資源，是避免資源衝突的唯一途徑）

6. 有否一個有效的產品開發流程？或是專案品質保證流程？（PMP PMBOK上的流程是公版，要全部套上去，可能工程更大，企業應該有本身的適合流程，這是流程管理的基礎）

以減法法則來規劃專案時程，是現代專案無可避免的資源壓力。為了應付市場快速的變化，多樣化已不足以應付市場需求，客製化更是競爭上的不二法門。但漫無限制的壓縮時程，專案並不會自動就快速動了起來的（敏捷專案不是用講的，計畫做得再敏捷，資源與文化沒有改變，敏捷只是累壞了敏捷教練）。如何科學的，有策略觀的把資源做最佳調配，以上幾個要素是成功的前提條件，必須確認清楚。

另外專案在網路規劃階段，也常因為以單一個別專案來看待（每個專案的成立與時程不可能一致），很多資源的工時其實已被其他專案佔據了部分了，但往往還是以100%的工時來規劃。加上中國人不太習慣主動的將問題提出來討論，對被分配的業務，都以逆來順受的態度接受，抱著反正只能盡力的心態，到時候工時不夠了，資源衝突，造成工作遲疑，只有兩手一攤，無能為力。這樣的專案管理不如不管理。

對於多專案管理的網路規劃，恐非短篇幅得以說明清楚的，一旦採取矩陣式管理，這些問題自然會浮現檯面，躲也躲不掉。但每個專案在規劃的時候，總不可能每次都把其他專案的網路也拿出來一起討論吧。話是沒錯，問題是如果不這樣做，專案的失敗不是只有一個個案，而是骨牌效應的全部受到牽連，不得不注意。要解決這樣的問題，專案辦公室(PM office)這類的虛擬組織就扮演一個重要的資源管理角色。

專案辦公室，是一個非正式組織的專案支援單位，一般都採取虛擬的Task force為之。其主要人物在於協助專案經理人一些資源管理上的整合資訊的提供，及對一些跨專案的時程與資源衝突上的必要協調。但專案辦公室不是專案主管的主管，不要誤解，否則這個人將會累死。

接下來就來談談幾個網路規劃的工具。

CPM/CPA：Critical Path Method/Critical Path Analysis

ADM：Arrow Diagram Method

PERT：Program Evaluation and Review Technique

PDM：Precedence Diagram Method

甘特圖：

Float time：

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

專案的網路規劃 2024-6-2

WBS、工時評估、資源調查、任務分配、與網路規劃，都是一體的工作，是無法單獨的分開來看。隨著資源的多寡與目標的需求而互動。資源充裕時採取穩健的規劃；資源相對不夠充分時，採取略帶風險的急進規劃，也是在所難免，而這些資源與任務的互動，會由這幾個步驟的要素相互的交織著。今天我們就來談談資源評估與任務分配後，如何將資源的配置做最佳化規劃。

從WBS展開的業務項目，有哪些是互相關聯的，有哪些是沒有相關的，這些相關的業務，一定非得以接力賽的方式連結？還是可以採取同步化作業？在還沒有展開時程規劃的時候，透過網路規劃，可以將資源的運用，建構一個完整的網路框架。

網路規劃的過程，業務關係大致上會有幾種類型，分別為：邏輯關係、資源關係與時間關係。規劃中要考量哪些業務可以同步並行，哪些必須先做後接，哪些必須同步完成再接另外的任務。有效的網路規劃，可以掌握整個專案的全貌。再把每個作業(WBS)的工時加上後，就可以從路徑中算出關鍵要徑(所需工時最長的那條路徑)。以終為始，從目標完成期限往前推，必要的時候，細部評估業務間的調動還是不可免。同時從網路規劃，也可以評估哪個環節最脆弱，須要做何種的補強或是列為風險項目。彙整網路規劃的主要任務大致如下：

1. 整個專案總共要花多少資源（時間、投入人力、物力）

2. 每個業務的起始與終結，及業務間的連結

3. 專案的業務間是否還有調整的餘地（專案的沙盤演練）

4. 整個專案中哪些業務項目最容易出問題，及出了問題後的影響有多大

5. 確保專案最佳化的做法

網路規劃是一種專案的策略規劃手法，在有限資源下，如何將資源的配置，做到最佳調配。有限資源，出現資源衝突的現象是司空見慣的事情，此時面臨如何調度與調整的考量。網路規劃，做沙盤演練，找尋最佳做法，是專案管理很重要的工具，卻常被國內的專案主管所忽略。國內大多數的專案經理人，比較習慣使用甘特圖，對甘特圖情有獨鍾，反而忽略了網路規劃的價值。直接用甘特圖來規劃時程，比較不容易看出業務的關聯（甘特圖是一種簡單明瞭卻不容易上手的工具，沒有充分瞭解專案的邏輯與內涵，甘特圖往往是專案失敗的主因），規劃時程時，當面臨必須做一些調整的時候，相對的就比較難下手。

待續！

管理其實也可以很Easy-從Boeing一連串的事故看採購的品質保證的意義

採購的品質保證能力重要嗎？-波音公司向聯邦調查局提出計劃如何解決製造品質和安全問題-

該公司的路線圖包括增加檢查和對供應商的更嚴格控制

大衛·柯尼希

5月 31， 2024

2023 年 5 月 30 日，一架波音 ecoDemonstrator Explorer 787-10 夢想客機停在南卡羅來納州北查爾斯頓園區的停機坪上。

加文·麥金太爾（Gavin McIntyre）/郵報美聯社庫存檔

波音公司官員週四在與聯邦官員舉行的三小時會議上解釋了他們提高製造品質和安全性的計劃，聯邦官員將繼續對該公司施加限制，此前該公司的一架噴氣式客機在1月份遭受了機身面板的爆炸。

美國聯邦航空管理局局長邁克·惠特克（Mike Whitaker）表示，該計劃是全面的，包括鼓勵波音員工就安全問題發表意見。

“這是波音公司開展業務的新方式指南。惠特克在會後告訴記者。“波音公司已經制定了他們的路線圖，現在他們需要有效執行。

波音公司發佈了一份長達11頁的「產品安全和品質計劃」摘要，其中描述了該公司正在採取的措施，包括增加檢查和加強對供應商的控制。它還說明波音公司將如何衡量其改進的措施。

首席執行官大衛·卡爾霍恩（David Calhoun）在1月5日阿拉斯加航空公司（Alaska Airlines）航班發生機板噴開後宣佈，他將在今年年底辭職，他表示，這份計畫是根據員工、美國聯邦航空局、航空公司和獨立專家的評論制定的。

“其中許多行動正在進行中，我們的團隊致力於執行計劃的每個要素，”卡爾霍恩在一份聲明中說。“正是通過這種不斷學習和改進的過程，我們的行業使商業航空成為最安全的運輸方式。我們今天採取的行動將進一步加強這一基礎。

斯蒂芬妮·波普（Stephanie Pope）是卡爾霍恩（Calhoun）的可能繼任者，卡爾霍恩最近被提升為波音商用飛機部門的首席運營官兼首席執行官，她表示，該計劃旨在改善員工培訓，簡化製造，“從源頭上消除缺陷，並提升我們的安全和品質文化。

1月5日，阿拉斯加航空公司一架相對較新的波音737 Max 9飛機在俄勒岡州上空飛行時，門塞爆裂，沒有人受傷。事故調查人員確定，在波音工廠進行維修工作後，確定是固定面板的螺栓丟失了。

這起事故進一步打擊了波音公司的聲譽，導致了多項民事和刑事調查，並促使惠特克下令波音公司週四提交報告。

惠特克表示，他希望波音公司制定一項全面、詳細的計劃，以改善製造流程、品質和安全管理，並鼓勵員工提出對安全的擔憂。（個人加注：ISO-9001-2015的全員參與、流程管理、品質管理與持續改善，被遺忘的品質基礎能力，特別是品質文化/意識）

“這些都是該計劃的要素，”惠特克說。他補充說，波音公司已經接受了獨立安全專家小組今年早些時候提出的所有安全建議。

不過，惠特克表示，美國聯邦航空局將繼續限制波音公司最暢銷的飛機737 Max的產量，並堅持批准每架下線的飛機。他表示，美國聯邦航空局還將在波音公司及其主要供應商Spirit AeroSystems運營的工廠保持安全檢查員的“大幅增加”。

波音公司最近的問題可能會使其面臨與2018年和2019年兩架Max噴氣式客機致命墜毀有關的刑事起訴。美國司法部兩周前表示，波音公司違反了2021年和解協定的條款，該條款使其能夠避免因欺詐而被起訴。這項指控是基於該公司涉嫌在與墜機事件有關的飛行控制系統方面欺騙監管機構。（個人加註2：詐欺，包括對客戶或是該公示監管機關的報告、數據的數據做假，俗稱的美化報表，出現刑責時，採購品保的責任，可能難脫關係。未來的永續報告書的碳盤查資料雖不會影響到生命安全，卻也會因為制定標準的單位想脫責，會把責任網提供方移轉，採購必須要多注意）

舉報人指責該公司走捷徑危及乘客，波音公司對此提出異議。美國聯邦航空局（FAA）在機板噴落事件發生前一個召集小組發現，這家飛機製造商的安全文化存在缺陷。

最近的大多數問題都與Max有關，但波音和Spirit AeroSystems也一直在努力解決大型飛機787夢想客機的製造缺陷。波音公司在其他專案上也遭受了挫折，包括其Starliner太空艙，軍用加油機和新的空軍一號總統專機。

波音公司官員發誓要重新獲得監管機構和飛行公眾的信任。波音已經落後於競爭對手空中巴士公司，生產挫折損害了該公司產生現金流的能力。

該公司表示，它正在促進積極的安全文化，改善工人培訓，減少“旅行工作”——不按時間順序完成的裝配任務——並密切關注Spirit AeroSystems，包括防止供應商將有缺陷的機身運送給波音公司。

遭受門塞爆炸的飛機正在修理，因為它在從Spirit到達波音工廠時損壞了铆釘。