今天為各位挑選的案例─不同於前一篇的設備廠─是家全球知名的日用消費品企業的製藥研發部門。挑這篇的原因是因為從這個案例可以看到不少導入過程的細節，正好可以讓對於 CCPM實務要怎麼進行感到好奇的朋友們一窺究竟。

這家企業擁有300多個品牌，他們的產品在超過160個國家中有將近5億人口使用，目前全球的營運點超過80個國家。改善需求源於該企業開發了一個藥品品牌，並希望藉著該品牌跨入製藥產業。雖然他們對製藥抱持很大的信心，然而在研發的過程中，遇到了幾個挑戰，為了順利在這個產業發展並獲得成功，他們必須思考如何改善目前的管理方式。

我們先一同來看看他們所面臨的挑戰。在製藥的產業裡，主要的成本來自於銷售、研發、和行政費用，由於藥品的研發週期很長，當前的生產力與支出很難達到平衡。加上產品上市的時機直接影響到價格的好壞，因此他們面臨很大的壓力。為此該公司提案進行研發專案的改善，目標是要為資源性的專案發展和導入一個更彈性的方法，包括選擇正確的專案管理方法。

以下引述project leader選擇CCPM的原因：

- CCPM讓組織專注在有效管理資源，這可以增加生產力以及產出。
- CCPM對我們組織和員工個人有正面的影響。
- 因為策略性的放置緩衝來減緩風險，專案完成日可以更可靠。
- 任務活動在最佳的時機啟動，降低WIP (work in progress)的成本。
- 我們為了增加未來競爭力提出了五個生產力提案，其中第五個叫做“flow to the work”(註1)，總體來說，我們判斷CCPM將有助我們在速度和可靠度上有所改善，這可以轉換成企業競爭力。
- 要讓我們這樣的組織有這些顯著的改變，你必須有三個東西：遠景、領導力、以及支持。而我們R&D副總身上擁有以上所有的特質。

底下要介紹的做法裡，其實可以看得出來他們很嚴謹的一面。在CCPM提案正式被核准之後，專案經理決定了一件很重要的事，那就是把“這個導入過程當作一個專案來運作。”

(也許有些朋友會覺得奇怪，覺得這不是常識嗎？但我看過很多失敗的例子是專案經理個人學了關鍵鏈的觀念，把這個當作純粹的排程工具，選了一個執行中的專案用關鍵鏈方法畫一畫時程，就以為自己是在試用關鍵鏈專案方法，甭說執行得如何，恐怕拿著這張圖去和別人討論時就被連打好幾槍。其實很多改善案也有這個問題，被指派做這樣改善的少數幾個人，很認真的畫了流程圖、完成了一疊SOP，然而因為過程中利害關係人的參與程度和承諾度不高，就算最後把那疊成果公告周知，結果還是淪為檔案櫃中眾多無人翻閱的資料的其中一角。)

由於受到高層的壓力，他們需要弄清楚組織裡想要保留的部分以及什麼是需要改變的。為此他們在一開始便組成一個專案管理評估小組，測試這個已經在業界實證過的新方法到底是否能為公司帶來好處。

另外，他們需要確定公司是否真的想要做專案管理。其實這個問題在專案小組內部早已經達成正面的肯定，所以重點在於要從高階主管口中得到證實。所以他們進行一些問卷調查，同時也實施成熟度模組(Maturity Model)來協助小組了解組織對專案管理的態度，藉此也順便看看組織內是否有任何不滿的部分可以協助激發這個轉變。其實對於有意進行改革的組織來說，適度的不滿可以善加引導成為改善誘因，因為很多時候這種情緒會讓人們對這個變革感到興奮。

透過一系列的詢問、四處訪談、和人們交換意見，小組成員試著去感受整個組織的想法，發現屋子裡專案團隊的人最有興趣看到資源管理方面的改善，而資源經理這一方，則對於規格變更和整合流程最感興趣。很明顯地，這是光譜對立的兩端。

“This is really why we came to the conclusion that multi-project critical chain planning was right for us.”

他們的執行策略很簡單，“Nothing fancy here.”就如前面提到的，他們選擇將這個導入視為一個專案並採用CCPM來管理。就像在做一般的專案一樣，訂定出專案章程、決定範疇為部門內的多專案、建立工作分解結構(WBS)、以及規劃風險，這些都納入導入計劃中。

在全面性地檢視CCPM導入專案後，他們決定將專案組成下面的結構。CCPM implementation被拆解成三個類別，然後再專注地根據這三項來分解細部工作。

在基本建設方面，他們成立了導入團隊、發展專案計劃、依據關鍵鏈方法來建立排程，然後持續地監測。導入團隊每兩週開會，檢視緩衝的侵蝕狀態，試著做緩衝復原計劃，所以他們藉由這個導入來實際執行未來要求組織成員做的事。透過這樣做，學習了很多，對於大家即將經歷的事也更有同理心。

在文化變革方面他們收到組織成員很多回饋。包括應該聚焦在需要哪些行為？哪種回饋和評量是他們希望就定位的？新環境的獎勵和認同是什麼？還有要建立大家在關鍵鏈方面的能力。“You know – That’s a big challenge for us.”

在運作方面，就和技術平台有關，也就是要安裝CCPM的專案管理軟體，這還包括需要在組織裡培養一些專家，也藉此深入了解這個技術。另外是導入政策和流程，這個部門本來沒有這些東西，尤其是和關鍵鏈相關的部分。當然這表示他們必須說服高階主管關於緩衝管理、產能限制、規格變更以及那些基本的東西。然後為新的角色─如任務經理、資源經理─設計流程。包括公司期望他們未來做什麼？當他們和系統互動時要尋找什麼資料？讓他們從一開始就參與，並開始將現有組織和新角色做對應。

有個狀況值得一提，在建立標準和慣例這項工作，他們花了非常多的時間(awful lot of time)試圖建立範本。為了加快未來專案管理的流程，他們原本認為建立範本是件好事，這樣就不用每個專案都從零開始。然而把大家認為自己正在做的事拿來檢討後，他們發現有太多不同的人有著太多不同的意見。這個「發展完整範本」的任務卡住整個導入專案的進度，造成緩衝侵蝕很嚴重，迫使他們不得不重新檢討作法。

(這是進行專案管理改善時很常碰到的問題，原先的立意是很好的，問題出在大家都想在這個階段畢其功於一役，做出一個Perfect的範本。然而，專案原本就是多變的，即便是訂出了一個版本，隨著不同專案的不同狀況，再完美的範本還是免不了得因應現況而變更。所以借用Dr. Goldratt很愛掛在嘴邊的一句話來提醒大家調整心態，“Good enough”就好。先有一個較佳的版本出來，重要的是趕快讓整個CCPM機制運作起來，不盡完美的部分透過緩衝管理的檢討和修正自然會調整過來。)

現在來看一下這個導入專案帶來的挑戰。

從單一專案的角度來看，他們花了很大的努力在於建立公司成員整體的專案管理能力、將CCPM作法標準化以及帶領團隊。由於他們有大約12位PM，對這個轉變的接受程度處於不同階段，前期的挑戰就是讓他們準備好可以上場，並學習著怎麼在新環境裡操作。另外，怎麼將緩衝管理這個新政策嵌入日常的工作中，建立標準和慣例，讓大家的語言正確。這是讓事情結構化並在組織中展開的好方法。“That’s something that we’re, obviously, trying very hard in our own organization.”

在多專案層級，他們希望穩定資源分解結構(註2)。還有他們發現讓所有的專案都納入系統是非常重要的(註3)。“You can’t see the benefit until you get everything in the system.”另外，過程中必須讓對的高階主管參與導入流程並接受訓練。關於這部分，他們和高階主管有一段很有趣的對話。一開始高階主管對於加入很感興趣，並主動問小組成員：“我能做什麼？”和“這要怎麼進行？”而在了解以後則問： “萬一我問錯問題怎麼辦？”這是個很好的現象，因為這表示主管們認知到：如果問錯問題，將會引發錯誤的行為。對主管做訓練就是希望努力避免這個問題發生。最後，他們在核心團隊裡籌組專案辦公室來支援CCPM，確保大家採用這個不同的新方式來工作。

導入CCPM的過程中，他們做了幾件可以強化和鞏固改善的措施。第一個是不論什麼情況下都很重要的：溝通、溝通、再溝通。善用圖表、圖片、或任何可以提升溝通品質的媒介。再來，建立起回饋機制，讓小組成員負責對任何回饋保持警覺，以助於隨時調整和掌握事情的走向。還有就是建立短期的勝利，發表當下的成果、並和大家談論成果。(短期勝利可以激勵士氣，是讓改善走入正循環很重要的小撇步。)另外，他們做了一件事，每週四11:30所有的PM和任何想參與的人會聚在一起吃中餐和學習，由小組的伙伴進來談論他們在modeling過程中經歷到的事。最後，最重要的措施，就是將新方法制度化，讓大家知道這是組織執行計劃的方法。他們曾遇過會議中有人在嘟嚷著抱怨說合作廠商不懂緩衝而且全都弄糊塗了，並質疑為什麼要這樣做。他們的副總這樣回答：Sooner or later you’ve got to tell people, “Look, this is the way we do our planning.”

最後，引用project leader提出的Key learning來做結尾：

- If you don’t have a high level “Sponsor” or “Guiding Coalition”- STOP!!
- If you don’t have Project Leader Buy in – STOP!!
- Commitment to planning is NOT the same as implementing CCPM – getting the commitment to do the planning is hard work
- Define the roles and engage everyone from that perspective – developing ownership “buy-in” is hard work
- Building competency cannot happen with knowledge of theory alone – you have to practice with real projects.
- Create and rigorously apply, a multi-faceted sensing method for gathering valuable feedback – it’s the ONLY basis for implementation course corrections
- Pilots for a CCPM implementation still don’t work

針對最後一點，project leader這樣表示：「我知道有很多人在談論pilot。我不相信pilot，這對我來說並不合理。你怎麼能找一個專案來試然後把它當作可以在多專案環境運作成功的證明？很難。你沒有取得你需要的所有資料。如果你決定要做關鍵鏈多專案管理，除非你讓所有的專案進入系統，否則你無法看到回饋。」

註1：Flow to the work，工作的流速，換句話說，就是讓已啟動的工作儘速完成。

註2：在導入CCPM專案管理初期，導入部門必須先針對部門內的資源進行盤點，並以加快關鍵鏈完成速度的出發點進行資源功能群組的分類，在此基礎上建立資源分解結構。

註3：把所有專案都納入系統，相對的作法就是只想拿一個專案做pilot run。這個議題未來可以單獨用一篇來聊。

 

案例來源：Realization Technologies

本站所有文章未經事先書面授權，請勿任意利用、引用、轉載。