今天要跟各位分享的案例是軟體公司Alna Software。在TOC的改善案裡，以TOC觀念為核心的軟體絕對是協助整個機制得以落實的重要因素，不過，有經歷過改善案的公司都很清楚，變革成功的關鍵從來都不只是軟體或工具的導入而已，在花了時間傳達新觀念、重置流程、制定新政策之後，重點在於能不能讓身處其中的人依據新的遊戲規則來走。本案例中，這家公司除了在很短的時間內成功將CCPM系統導入上線，我們可以多次從該公司主管的分享中看到他們花了很多時間改變各階層人員在新機制中的行為，並因此得到顯著的成效。一起來看看吧！

--------------
我們先來了解一下這家企業的環境背景。

Company/Business Background

Alna Software是一家從事客製化軟體發展服務的全球化企業，在波羅的海區域居於前五大。該公司成立於1989年 ─ 在前蘇聯時代戈巴契夫同意讓私人公司成立之後 ─ 因此，他們在這個產業已經擁有23年的軟體發展專業。總部位在立陶宛的他們是Microsoft Gold Partner、Oracle Certified Partner，主要辦公地點座落在三個不同的城市，因此導入不僅只在一個地點，而是三個辦公區都實施導入，這使得導入的複雜度增加很多。在這一場案例發表之際，該公司團隊由140位專家組成，於前一年產出五百萬美元的營收，2003～2007年間，這個數字增加了10%，其中有30%的營收來自於國際客戶。

Business Requirements for Projects

Alna Software專案型態除了大型、全新訂製的軟體需求，也做小型的add-on和修改專案。大型的專案包括電信業者的帳務系統、電力公司的帳務系統、電信業者的網路自我照護系統、或是能源供應商的資產管理系統。專案的規模大小不一，從 “1人/每週” 到 “155人/每月”，專案的週期也差別很大，從1週到3年。客戶群從公家到私人，從區域性到國際性。當地的客戶主要是政府機構、電信業者等大型企業，國際性的客戶則有美國的德意志銀行、Bentley Systems。

立陶宛成為歐盟的成員後，IT專業人員的需求狀況出現了劇烈的變化。愈來愈多的外國投資者進入到當地的市場，非立陶宛籍的競爭對手提供更高的薪資，造成該公司也得跟進。另外，大量的IT投資來自於歐盟基金，IT的支出呈現雙倍，大幅度地提升市場對專業人員的需求。再加上參與歐盟後，IT人員不用經過核准就可以出國工作，導致大量的資深專業人員出國追求更好的收益，加重了IT專案人員不足的困境。

接下來由Alna Software的General Director分享CCPM專案導入的過程。

Improvement Needed

我們公司主要的問題是，即便營收增加了10%左右，實際收益幾乎沒變。我們的效率不夠好。因此，就像我國其他的IT公司一樣，我們試著做一些改善。首先，我們導入ISO，接著我們導入CMM program，而且成為波羅的海諸國首位達到CMM Level 2的公司。但是，這對我們沒有幫助，我們還是沒有得到好的成果。兩年前，我讀了一本有關關鍵鏈專案管理的書，並且開始在公司運用在單一專案的環境。我們選擇了2～3個專案，試著採用CCPM的觀念，得到的結果令人印象深刻，因為我們真的做到專案提早完成的成果。只是當我們試著在整個組織導入的時候卻失敗了… 我們沒有任何工具。去年我遇到Sanjeev (註1)，他正在立陶宛參訪，而我評估有很高的機會可以導入系統。我們進行得很快，導入花了60天，我們在九月十三日開始，十二月的第一週我們就上線了。

我們想要達成什麼目標呢？

首先，在同樣的資源之下做更多專案，換句話說，我們想要達到更好的效率、增加產出、運用相同資源產生更多錢，第一年營收至少成長15%。再者，我們的薪資水準屬於中間等級，然而我們想要留住人才，額外的營收讓公司可以大大地改善員工的利益，我們希望運用額外的營收來增加員工的薪資。另外，我們有一半的專案來自歐盟基金，有些受IU rules規範下的專案，會因延遲而被罰款。所以準時達交率變得很重要，否則專案可能會被取消，合約可能會被中止。

Implementation Elements

1. 引進多專案同步化排程、緩衝管理、任務管理

我們首先導入多專案同步化排程，再來則是導入緩衝管理，主要的工作就是把個別任務的安全時間移到專案緩衝。在這段期間，進行中的專案有35個，我們注意到其中有3個專案沒有辦法準時完成。由於在CCPM的機制下，可以很早以前就預知專案的達交狀況，我們可以儘早和客戶討論，並更改交期。任務管理則是導入最困難的部分。(註2)

2. 確保專家的可得性(Availability)以快速解決問題

在導入前有些專案可以進行得很快，有些則會失敗。我們注意到這跟專家的可得性有極大的關聯。當某些技術問題發生時，我們真的需要快速解決，如果能確保需要的時候就能找到專家來支援，就可以解決這些問題。我們的作法是組成一個專家團隊，我們稱為 “architects”， 這個團隊不專屬於任何專案，負責為所有專案化解問題 ─ 根據系統呈現的優先順序來解。不過，我們注意到專家們喜歡去解他們自己喜歡的問題，這種行為必須改變。因此我們列出一張問題清單，專家們必須照順序一個一個解決。如果你想要解決位在下面的問題，只有一個辦法─你必須把之前的所有問題都解決掉。

3. 做好專案階段的準備工作，用以防止WIP(註3)變多

我們發現有很多專案是在尚未完成前一個階段的情況下啟動的。我們看到人們開始工作，然而資訊卻還沒準備好。所以我們導入Full-kit management(註4)，除非所有的資訊都齊全，否則我們不會啟動專案。

4. 我們將任務管理的工作正式變成管理職涯的管道，讓團隊的領導者有另一個職涯選擇的機會。

Implementation Challenges

1. Project-centric vs. resource-centric的團隊模型
導入不如我們預期的簡單，我個人花了很多時間push團隊工作… 我喜歡“推土機”這個字眼，我真的就像推土機一樣。在設計期間，我們做錯假設，選擇採取resource-centric的團隊模型，讓團隊固定，為許多專案執行任務。這在我們公司行不通。我們的情況是，在一個專案裡有很多小組長─小組長的數量和小組成員一樣多。我們需要改變這個，改成只有一個小組長來領導小組成員，而成員們會根據不同專案交換角色。

2. 管理的焦點從專案預算轉移到專案週期
對於我們的主管來說要從預算的思維轉換成專注在專案週期真的很困難，所以我們也花了一些時間調整這個。

3. 解決問題的速度
另一件事是解決問題的速度。我記得在第一個月的期間，當系統顯示出專案有個問題，緩衝呈現紅色狀態，大家的第一個反應是：“不應該這樣啊… 我們再等一週看看，結果應該會好一點。”我們花了一點時間來改變主管和專案經理這方面的行為。

4. 不是改變日期，而是專注在執行
另外，當我們看到專案緩衝變紅色，將有可能沒辦法準時完成，專案經理的第一個提議是：“我們來變更日期。” 改變這些行為真的花了我們不少時間。上個星期我和我的主管們變更了兩個專案的交期日，而且達成共識：這將是今年最後一次變更交期了。I hope it will be so.。

5. 讓專案計劃隨時和現實狀況一致
專案經理花了一段時間熟悉系統，這對他們來說不簡單。所以他們開始產生兩個計劃，一個是CCPM系統使用的，然後他們在原來習慣用的工具上又有另一套計劃。當我追問原因，他們總是說CCPM系統沒辦法呈現正確的資訊，他們有另一個較佳的專案計劃。我們花了很多時間在改變行為。我們的作法是 – 要求他們在CCPM系統上回報他們的進度。你可以用任何你想用的工具去做溝通，但要把進度呈現到系統裡。It helped a lot.

Improvements Achieved

下面來談談過去六個月我們達到的成效：

1. 首先，我們非常接近營收目標。在相同的資源及品質(甚至更好的品質)之下，和去年同期相比，我們得到比去年多於14%的營收。
2.在同步化排程的運作下，我們減少了同時間進行的專案數量。去年我們大約有30個專案同時進行，今年降低到14個。
3. 對於小型的專案來說，上市的時間更短、準時達交率做到完全可靠 (週期時間減少25%，大於40%可以比這個週期時間還快達交)。對大型專案來說，按計劃執行的狀況改善，準時達交也獲得大幅改善。
4. 專案管理方面的改善
(1) 花較少的時間在做預算，較多的時間在管理，尤其是前期的管理─和客戶討論。
(2) 較少的時間在日常的維護，較多的時間在前置的計劃和分析。
(3) 較多的預先管理，對於重大問題的反應更快速。
5. 專案經理團隊從原本的14人減少為11人，執行專案的專案經理變少了，有的轉調到銷售單位。有的轉調到另一個事業群。雖然同時進行的專案數量變少、執行專案的專案經理變少，卻可以比去年完成更多專案。
6. 對於incoming sales來說，在簽署合約時，我們可以看到專案的開始和結束日期，以及可以運用的產能，擁有更佳的可見度。

註1：CCPM軟體廠商Realization Technology的老闆

註2：在關鍵鏈專案管理機制裡，除了專案經理以外，另一個重要的角色便是任務經理(Task manager)。而任務經理最主要的工作便是負責做任務管理，職責包括依緩衝管理的優序指派任務、任務啟動前的準備工作、即時的進度匯報、快速解決問題。簡單來說，就是確保任務階層的工作不受到干擾，並預防Parkinson’s Law現象的發生(避免專案成員在不必要的情況下消耗安全時間)，讓大部份穩定性高的任務可以用As soon as possible的速度進行，預留Buffer給少數不確定性高的任務。這也是構成緩衝管理能發揮保護專案效果的機轉之一。

註3：WIP (Work in progress)，在生產環境裡指「在製品」。Little’s Law提出證明，當生產線上的在製品愈多，產品的生產週期愈長。因此，若能有效控制WIP數量，生產週期將可以縮短。WIP運用在專案環境則是指「進行中的任務」，當專案環境裡WIP愈多，會造成執行順序混亂、等候時間增加，進而造成專案週期拉長。相同地，如果能將進行中的任務控制在合理的數量之內，將有助於專案週期的縮短。

註4：對Full-kit management 陌生的朋友可以參考之前的文章“從ABB案例看關鍵鏈專案管理─ Full-kit management”

案例來源：Realization Technology