什麼是專案管理？
什麼是專案管理?[@more@]什麼是專案管理?
在理解什麼是專案管理之前，我們首先要弄清楚專案的定義。如果不說理論上的定義，企業中的“專案”說白了就是企業中的各項有始有終的工作或事務。
企中的專案有哪些呢？如果我們把企業的經營活動進行分解，會發現企業中的各種工作基本上都可以歸類為一個又一個的專案，大到：IT服務專案、工程建設專案、產品開發專案、投資專案、ERP專案、BPR專案、薪酬改革專案、市場開發專案、房地產開發專案等等，小到：一次搬遷、一次校園招聘會、一次內部培訓、一次會議組織、一次新年聚會等等。
專案管理就是在有限的資源約束下運用系統的觀點、方法和理論以實現專案的目標的方法。著名的美國的阿波羅登月計劃，整個專案大約有40萬人和20萬家企業參加，耗資200多億美元，就是專案管理成功應用的傑出典範。
計劃、控制、度量——洗盡鉛華的專案管理真諦
在亂花漸欲迷人眼的專案管理領域內，專案經理們總是很容易被各種理論說服，被各種模型吸引，被各種模版包圍，可是，對一個具體的專案來說，什麼才是最重要的呢，需要做些什麼才能讓專案可控，並且朝著成功的方向走近呢？
去掉繁複的理論體系和證書的包裹，專案管理的目標其實很樸素，手段其實很簡單，只是為了讓專案成功，做好這樣三件事——計劃、控制、度量。這是筆者根據多年的專案管理實踐，從實用的角度出發，結合多個理論模型總結出來的一點經驗和體會，希望能對各位有所啟發。
正文
專案管理的理論體系很多，對專案管理的理解也各不相同，各種組織的最佳實踐模型更是數不勝數。那麼，我們在實際的軟體開發過程中該如何選擇，如何應用呢？
結合各種PM理論基礎和在實際工作中積累的專案管理經驗，筆者認為，對於一個具體的專案來說，專案管理的核心問題不是採用哪種理論體系，不是透過哪種認證評估，也不是選擇哪個最佳實踐模型，而是要做好這樣三件事——計劃、控制、度量。也就是說，專案啟動之前，要有計劃；專案進行當中，要有控制；專案結束之後，要有度量。這樣才能保證專案有的放矢（依照計劃執行）、有據可查（產生管理文件）並且讓以後類似的專案在計劃階段有章可循（參考度量的結果）。
下面來看看我們在計劃、控制和度量這三件事情上需要做些什麼。
1. 計劃
專案的計劃階段一般會對專案的可行性進行分析，並提出若干備選方案，然後根據組織的目標、能力和預算，挑選一個最適合的方案來執行。
選定方案之後，要根據專案範圍、資源配備和預算等條件，制定出專案的進度計劃、人員配置計劃、預算計劃、風險管理計劃，以及專案管理所需的其它QA計劃、CM計劃、MA計劃等輔助計劃。
2. 控制
為了保證專案能夠按計劃順利完成，在專案執行階段，我們有很多工作要做。
專案的進度控制、質量控制和成本控制是專案管理中最關鍵也是最重要的三個方面，此外還有風險的識別和管理，也是影響專案成敗的重要因素之一。
專案進度管理需要在每個里程碑或檢查點及時檢查是否按照計劃要求完成了相關的工作內容和需要交付的工作產品，以保證專案進度在控制之中。
質量管理是要確保每個工作階段的可交付產品符合專案和組織的質量標準，確保最終交付的產品是合格的，可以使用的。
成本管理是為了保證專案不超出組織的預算，對於內部的IT專案而言，員工的工作時間就是專案的主要成本。基本上，保證專案按照計劃的進度和人員配置完成，就可以保證成本在可控範圍之內。
風險管理主要是應對突發的、不確定的因素對專案造成的影響。需要在計劃階段就制定出風險應對計劃，在執行階段及時發現和識別風險，當風險發生時，採取正確的措施應對，儘量減少負面影響。
3. 度量
在專案執行過程中，除了要對專案的進度、範圍、質量進行管理和控制，也要對專案的關鍵指標（工作量、里程碑、工作產品、人員配置、物理規模等）進行度量，透過各種度量指示器在專案的執行階段持續的跟蹤和記錄專案進展情況，及時發現進度、成本和質量上的偏差。
除了跟蹤和發現專案偏差之外，度量的更深層次的意義在於為以後的專案提供可參考的歷史資料，為組織積累經驗，提高組織的計劃和估算能力。但是在實際的專案當中，很多專案經理認為，度量對當前專案的意義不大，不願意花時間去做度量。其實這對組織來說是很不利的，因為如果沒有歷史資料的積累，即使已經做過了大量的專案，組織仍然無法為專案的規模、成本、人員等的估算和計劃制定提供確切的歷史資料和估算依據，組織的專案管理將仍然是粗放型的，做不到精細化管理，達不到更高的專案管理水平。
度量的意義重大，但真正知道該怎樣做的人並不多，這點我將在今後的文章中專門講述，並儘量提供詳盡的參考模版。
為了更清楚的說明計劃、控制和度量在專案管理中的重要作用，下面舉一個買鞋的例子來詳細說明。
根據專案的定義：“專案是為完成某一獨特的產品、服務或任務所做的一次性努力”，某次買鞋的過程具有獨特性、一次性和不可重複性的特點，是典型的專案，我們可以稱之為“買鞋”專案。
在“買鞋”專案中的計劃、控制和度量是怎樣的呢？
l 首先是計劃。在買鞋之前，我們首先要明確是否一定要購買新鞋，是否有時間去商場，然後提出幾個備選的商場，這相當於可行性分析和備選方案；考慮一下自己希望與之搭配的服裝，個人的氣質特點，本次購買的預算，然後選擇一個各方面最適合的商場，這相當於選擇合適的專案方案；根據選定的方案，制定出選購活動的時間表、價格標準、鞋子款式、午餐安排等，這相當於制定專案進度計劃及相關的輔助計劃。
l 然後是控制。對於“買鞋”專案來說，我們要注意鞋子是否符合最初的款式要求，這相當於質量控制；我們還要把價格控制在可以接受的限度之內，這相當於成本控制；我們不想在商場花費過多的時間，因此要控制在每個專櫃花費的時間不要過多，這相當於進度控制；及時提醒自己不要買計劃外的物品，不要輕易聽從專櫃小姐的勸說購買價格過高的鞋子，這相當於風險控制。
l 最後是度量。在逛商場的過程中，經常比對一下款式、價格、時間上的計劃和實際的偏差，相當於度量的跟蹤和記錄。把鞋子買回去之後，可以再對最終購買的鞋子的價格、款式、所花費的時間與出發前的計劃進行對照和統計，分析一下估算與實際情況的偏差，總結出這次購買行動的成功經驗和待改進之處，以便為以後類似的購買行為提供精確的可參考資料。
從以上的分析可以看出，計劃、控制、度量這三件事是專案管理的核心和關鍵之所在，無論我們應用什麼樣的專案管理方法和模型，做好這三件事，就等於抓住了專案管理的本質，掌握了專案管理的真諦，這時，我們就可以不再為眾多的理論體系所制約，可以得心應手的根據專案特點和組織需要來創造性的做好專案管理工作了。也只到有這個時候，我們的專案管理才算是真正學到家了。
專案管理系統（Project System）是ERP的一個整合解決方案，它的目的是幫助企業執行專案管理中的所有任務，因此它包括了在專案所有階段的各種功能。ERP的專案管理涵蓋了兩類專案：客戶專案和成本投資專案。客戶專案是指以銷售為目的，根據客戶需求執行的專案。這類專案和銷售模組有很強的聯絡和整合。在造船，建築，工程，服務，軍工等各種行業有廣泛的應用。成本投資專案是指企業內部各種型別的專案，這些專案的成本在專案完成後或者資本化或者費用化，包括研發專案，投資專案，IT專案，裝置維護專案等等。這類專案在各種行業的應用更為廣泛。
專案的結構
在正式執行一個專案之前，我們必須明確地定義專案的目標並制定專案所要執行的工作的結構。明確定義的專案結構為成功的專案計劃，執行和控制提供了先決條件。圖一是ERP中主要的專案結構物件，以及它們之間的相互關係。
專案定義（Project Definition）
專案定義是一個總括的專案描述。專案定義為將來專案計劃階段所要建立的所有專案管理物件提供了一個框架。
工作細分結構（ Work Breakdown Structure）
工作細分結構是以層次結構的形式將完成一個專案所要執行的任務層層細分所形成的專案結構。它提供了關於專案的概覽並且構築了專案的組織結構和協調合作的基礎，同時顯示了專案在工作，時間和金錢上的花費，可以應用它來計劃時間，成本和分配預算。
工作細分結構中的每一項任務被稱為WBS元素（WBS Elements）。和別的專案結構物件一樣，系統在WBS元素中維護了很多資訊。比如有關於組織結構關係的資訊：公司程式碼，業務範圍，工廠（物流模組），裝置或功能地點（工廠維護模組），利潤中心等等。再比如在基礎資訊中有三個標誌：<1>成本計劃。如果要對這個WBS元素計劃成本，我們必須指明該WBS元素是一個計劃元素。<2>成本物件。如果想將實際成本和承諾記錄到某個WBS元素，我們必須指明該WBS元素是一個成本物件。如果這個標誌沒有開啟，該專案中其他能夠分配成本和承諾的物件（比如內部定單，網路或採購定單）也將不可以分配給該WBS元素。<3>開票。如果想將收入確認到某個WBS元素，我們必須指明該WBS元素是一個開票元素。還有很多資訊被分別組織在專案責任，控制資料，憑證，開票計劃，結算規則，在建工程，資本投資計劃等等檢視中。
網路（Network）
和WBS不同，網路描述的是專案執行過程。網路是一種在專案進度安排，成本和資源安排的計劃，分析和控制工作中很有用的技術。我們可以將網路分配給專案定義，WBS元素或者銷售憑證。
構成網路的關鍵元素是活動（Activity）和活動之間的關係。活動具有以下特徵：它們持續一定的時間；它們有明確的開始和結束；它們執行的過程不被中斷（指如果有中斷應定義多個分開的活動）；執行他們需要一定的資源；它們引起成本。活動如圖一所示可以分配給WBS元素。
圖二我們給出了各種型別的活動。ERP專案系統區分三種主要型別的活動：內部處理活動（Internally processed activities），外部處理活動（Externally processed activities）和一般成本活動（General costs activities）。我們甚至可以將活動進一步細分成活動元素（Activity Elements），如圖二最右側的活動。活動元素也可以區分成上述三種型別。
對於內部處理活動，為了計劃完成它所牽涉的工作，以及提供成本計算的基礎，我們需要明確如下一些問題，比如：執行該活動需完成多少工作；什麼產能（如人工或機器）會用來執行這些工作；什麼資格（Qualifications）是完成該活動所必須具備的；哪些人員或個別產能是完成該活動所必須提供的等等。因此我們會在內部處理活動中指明工廠，工作中心等組織機構和工作時間等資訊。
對於外部處理活動，我們一般需指明負責的採購組織和採購組。在釋放網路時，系統可以自動建立採購申請，由採購部門負責完成。或者我們也可以手工觸發採購申請建立。我們也可以將採購資訊記錄記錄到外部處理活動中，採購資訊記錄裡維護了供應商，價格條款等資訊。
另外我們可以將物料分配給所有的活動，如圖2最左側的活動。在專案執行的過程中，生成採購申請或計劃定單，分別由採購部門或生產部門完成。
活動和活動之間在系統中可以維護四種關係：結束-開始（Finish - Start (FS) Relationship），開始-開始（Start - Start (SS) Relationship），結束-結束（Finish - Finish (FF) Relationship）和開始-結束（Start - Finish (SF) Relationship）。
里程碑（Milestones）
里程碑是專案中有特殊重要性或者會觸發某些事先定義功能的一類事件。一般來說它們顯示了專案各階段或各部門間的銜接點。在ERP中里程碑可以分配給活動（Activity）和WBS元素。里程碑可以實現四種任務：<1>里程碑趨勢分析（Milestone Trend Analysis /MTA）。是一種控制專案進度的簡單而有效的工具。在不同報表日期，里程碑日期被用於比較分析，圖形化的MTA使我們可以立刻發現專案趨勢和任何的延誤。<2>使用里程碑技術的實現價值分析（Earned Value Analysis）。里程碑技術是眾多計算實現價值技術中的一種。每一個里程碑代表了活動或WBS元素所完成的這部分工作。<3>決定開票計劃的日期。將里程碑和開票計劃的日期相連。當專案進度到達某個里程碑時，里程碑的實際日期將被自動複製到開票計劃中。<4>觸發預定義的里程碑功能。我們可以利用里程碑觸發一系列事件來處理某些特定的業務流程。
在ERP專案結構的建立中有兩種可以增強工作效率的功能：<1>標準專案結構和複製功能。<2>圖形功能。
專案的成本控制
ERP透過專案成本的計劃和實際比較來達到控制成本的目的。專案成本控制元件和其它相關模組有緊密的整合。這些模組包括管理會計，財務會計，生產計劃和控制，物料管理。
成本計劃
專案成本計劃在專案的不同階段有不同的作用：在概念定義和粗略計劃階段，成本計劃的作用是計算一個專案最初的成本估算；在審批階段，成本計劃是分配預算的基礎；在專案執行階段，我們使用成本計劃來控制實際成本和成本差異。 ERP成本計劃有如下幾種方式：
1． 簡便成本計劃。簡便成本計劃的核心是成本模型（Costing Model）。對於成本結構相似且經常重複出現的任務，我們可以定義成本模型。在對WBS元素計劃成本時，只要提供相關的數量和引數，就可以計算出成本計劃。舉例來說，假如我們的專案經常需要埋設管道。但是不同的專案，埋設管道的直徑以及溝渠的長寬深各不相同。我們可以設計如下成本模型：
描述 型別 物件 數量 啟用 價格
挖掘溝渠的人工成本 成本中心/作業型別 4298/1421 溝渠長度*溝渠寬度*溝渠深度/10
挖掘溝渠的機器成本 成本中心/作業型別 4298/1420 溝渠長度*溝渠寬度*溝渠深度/10
管道 工廠/物料 0001/管道-10 溝渠長度 管道=“10釐米直徑”
管道 工廠/物料 0001/管道-20 溝渠長度 管道=“20釐米直徑”
放置管道的人工成本 成本中心/作業型別 4298/1421 溝渠長度/5 管道=“10釐米直徑”或“20釐米直徑”
填平溝渠的人工成本 成本中心/作業型別 4298/1421 溝渠長度*溝渠寬度*（溝渠深度-0.1）/10 管道=“10釐米直徑”
填平溝渠的機器成本 成本中心/作業型別 4298/1420 溝渠長度*溝渠寬度*（溝渠深度-0.1）/10 管道=“10釐米直徑”
填平溝渠的人工成本 成本中心/作業型別 4298/1421 溝渠長度*溝渠寬度*（溝渠深度-0.2）/10 管道=“20釐米直徑”
填平溝渠的機器成本 成本中心/作業型別 4298/1420 溝渠長度*溝渠寬度*（溝渠深度-0.2）/10 管道=“20釐米直徑”
差旅費用 可變專案（成本要素） 420000/H 工期 固定費率
只要某個專案含有埋設管道的WBS元素，我們就可以使用這個成本模型，提供溝渠的長，寬，深以及管道型別就可以計算出成本計劃。
我們可以在兩種情況下很好地利用簡便成本計劃：<1>關注成本控制的專案管理。如果你使用專案作為成本控制的工具，對於專案成本計劃的高效性，直觀性和易用性特別看重，那麼簡便成本計劃是很好的工具。<2>複雜專案的初步成本計劃。如果我們使用專案系統來管理複雜的客戶專案或成本投資專案，那麼我們需要一個簡單但高效的工具來作出初步成本計劃，這種初步計劃可以成為客戶專案報價的基礎。當專案被批准或接受定單後，我們會使用網路來做詳細的成本計劃。初步計劃將被保留在一個分開的計劃版本里作分析比較使用。
2． WBS的手工成本計劃。這種計劃方法是指根據專案的WBS結構，手工編制專案成本計劃。具體來說又有三種形式：
<1> 層次計劃（Hierarchy Planning）。這是最簡單的形式，計劃是不分成本要素的，也就是說對於WBS元素的成本是總數的形式，而不考慮成本的構成。計劃者沿著WBS的層次結構對整個專案和會計年度編制簡單的成本計劃。
<2> 成本要素計劃。當我們獲取關於專案成本更詳細的資訊時，可以編製成本要素計劃。這種計劃涵蓋初級成本要素，作業型別投入（從服務成本中心流入的次級成本要素）和統計指標的計劃。
<3> 單位成本法（Unit Costing）。如果我們有資源供給的來源，數量和單價等資訊，那麼單位成本法是WBS手工成本計劃中最為詳細的一種形式。單位成本法實際上是一種電子表格，由於系統整合的緣故，這種電子表格可以呼叫系統存在的主資料和價格資料，比如成本中心模組的作業價格，物料的標準成本等等。和其他電子表格一樣，我們可以利用單位成本法計算總計，小計和其他數學公式。 單位成本法按專案類別對成本分類，不同的專案類別需要成本編制者輸入相應的內容，系統會自動查詢並計算成本。比如對於內部加工成本，需要輸入成本中心，作業型別和數量。系統會自動尋找作業價格，計量單位和成本要素，並計算成本。再比如對於外部加工或外包成本，需要輸入採購資訊記錄，工廠，採購組織數量和成本要素。系統會自動尋找價格和計量單位，並計算成本。再比如對於物料成本，需要輸入物料號，工廠和數量。系統會自動尋找物料成本，計量單位和成本要素，並計算成本。而對於間接費用，系統會根據成本核算單自動按比例並選取基數進行計算。
三種計劃方式可以在專案的不同階段使用，也可以同時使用。比如對於關鍵WBS元素用單位成本法，而其他用層次計劃法。
3． 網路成本計劃。上述兩種計劃方式，要麼是在專案初期使用，要麼是對那些只使用專案管理模組一部分功能（主要是作為成本核算物件）的專案使用。換句話說是對那些還沒有維護詳細的專案網路結構的專案使用的。回顧一下上一節和圖二關於網路的介紹，一個資訊完整的網路中已經包含了成本計算的所有條件。這一點我們只要和單位成本法所要輸入的資料比較一下就清楚了。因此我們可以在儲存網路，或者釋放網路時讓系統自動計算專案成本，或者手工觸發專案成本的計算。這種計劃的好處之一是成本計劃和時間進度控制以及資源計劃是整合的。因此如果網路結構或活動的時間發生變化，成本計劃也會自動地做相應調整。
我們可以對活動（外部的，服務的或一般成本的）或外購的物料構件直接建立發票接收計劃（Invoicing Plans）。這意味著系統可以根據發票接收計劃中的日期計劃成本和支付。成本將根據發票接收計劃上的時間準確地計算而不是簡單地分配到時間段上。在建立發票接收計劃時我們可以複製一個參考發票接受計劃，系統將根據實際的開始日期重新計算成本和時間。
隨著專案程式的展開，相對於計劃成本，實際成本將開始發生。網路實際成本通常由下列業務產生：財務會計過帳；物料管理的貨物移動；內部作業分配；間接費用；確認（Confirmations）；收到發票。
4． 分配給專案的定單。如果一個WBS元素是一個成本物件，那麼我們可以將不同種類的定單分配給它。這種分配意味著這些定單將在專案的架構下管理。這些定單的計劃成本將以彙總的形式記錄到專案中。在ERP中，我們使用定單實現不同的目的。可以分配給專案的定單包括：<1>內部定單。用於管理成本的定單。<2>裝置維護定單。是裝置管理模組中用來計劃裝置維護行為，輸入和結算裝置維護成本的定單。<3>生產定單。用於製造產品的定單。<4>銷售定單。是一個銷售組織和售達方關於以明確的價格和時間提供指定數量的商品或服務的契約協議。此外，根據定單是否消耗專案預算，可以分成消耗預算定單和獨立預算定單兩種。
預算和可用性控制
在成本計劃階段，我們將利用上述的工具儘可能地準確計劃專案成本。這個階段往往採取自下而上的方式，從最底層最細節的活動或WBS元素開始進行計劃，層層彙總和修正，最終形成整個專案的成本計劃。接下來在審批階段，資金將以預算的形式明確和分配下來。預算分配的過程和成本計劃的過程剛好相反。它是沿專案的結構自上而下分配下去的。預算和成本計劃的區別在系統中是很微妙的。預算是具有束縛力的，它是管理層控制一段時間內成本發展的審批工具。當計劃批准為預算後，這種束縛是體現在成本總額上的。明細的實際/計劃比較是分析的工具，而不具有直接的約束力。
可用性控制在一定程度上體現了預算的束縛力。在專案的進行過程中，可使用的資金將被投入到不同的地方。承諾（指採購定單和採購請求）和實際成本相繼發生。同時分配給該專案的消耗預算定單也將陸續發生各種成本。所有這些統稱為“已分配資金”。當然我們可以使用“資金使用概覽”等報表控制預算的使用，但是這種控制是被動的，也就是說，你必須自己去看這個報表才能知道預算使用情況，才能實施某種控制手段，比如凍結成本的發生，或通知相關人員。ERP專案管理系統還提供了主動的“可用性控制”。在執行成本相關的操作時，系統將自動計算已分配資金並和預算比較。如果超過了某個容忍水平（比如“90%預算已分配”，或“預算超過5%”等等），將觸發各種系統反映（比如，警告，警告併傳送電子郵件或錯誤資訊）。我們可以在後臺靈活地定義各種容忍水平和系統的反映方式。系統在計算已分配資金時會自動尋找相關的WBS元素，並自動彙總它下層的所有成本物件的已分配資金。
對於預算控制，系統還提供了各種工具：原始預算編制，預算更新，預算釋放和預算結轉。預算更新包括了預算增加，預算返還和預算劃撥。預算釋放功能使得我們可以分階段部分地釋放預算，以避免預算過早的耗盡。預算的結轉是指可以將本年未使用完的專案預算結轉到下一會計年度。
此外，如果我們使用ERP的投資管理模組。那麼投資專案作為企業投資計劃的實現工具，將被納入整個企業投資計劃的成本計劃和預算控制架構中。
承諾和實際成本
和其他管理會計模組類似，專案實際成本流的來源是ERP系統的各種業務模組。除了實際成本流以外，承諾（指採購申請和採購定單這些將來的成本流）也是專案需要控制的。這些業務模組包括：<1>採購：採購申請，採購定單，收貨和服務確認。<2>庫存管理：物料領用。<3>財務會計：總帳過帳。<4>管理會計：間接費用法，流程成本（ABC成本法），利息計算，結算（定單），分配，分攤，作業分配。<5>專案系統管理：確認（Confirmation）。
確認（Confirmation）記錄了活動或活動元素的進展情況（主要包括實際時間和預計剩餘時間），從而使我們可以作出關於專案將來發展的預測。確認的動作在系統中會實現多項功能，其中包括實際成本過帳。我們可以用很多方式來完成確認：<1>單獨確認，對個別網路，活動，活動元素或產能的確認。<2>彙總確認。<3>從資訊系統出發，生成要求確認的工作流，傳送給相關使用者進行確認。<4>使用跨模組的時間表（Time Sheet）。時間表是ERP系統中記錄個人工作時間及工作物件的工具。說它是跨模組的，是因為時間表的資料可以被很多模組使用，比如人力資源，專案系統，裝置維護，管理會計，服務管理等等。<5>使用Internet完成單獨確認，彙總確認或填寫時間表。<6>透過系統介面，從PDA裝置，或其他外部系統輸入資料。
專案中的物料
在專案結構這一節中，我們介紹了物料構件可以分配給網路中的活動。這種分配的含義是指這些部件或原材料是在專案的這個階段所必須的，因此需要被保留或預定。根據專案以及物料的特徵，這些物料將透過觸發MRP或者採購來獲得。從圖三我們看到專案系統這個模組從專案的角度整合了銷售，採購和生產等模組。而專案中的物料是這種整合的一種重要形式。
專案中的物料是專案管理中一個複雜的組成部分。比如有些物料是直接採購的，有些物料有BOM和工藝路線，是企業內部製造的（如圖三中分別指向採購和生產的箭頭）。再比如有些物料是納入庫存管理的，有些則完全不納入庫存管理體系。再比如有些庫存是專案專用的，而有些是企業統籌計劃的。再比如有些庫存是有價值的，而有些是不含價值的（或者說只管理物流而不管理價值流），諸如此類。這些都體現了ERP的高可配置性和靈活性。但是由於這個組成部分更多的涉及物流管理，因此本文中我們只選取一種常用的情景，從財務的角度來介紹專案中的物料這個功能。
我們的情景如圖四所示，在專案W-100中，活動3100分配給WBS元素W-100.3。在這個活動中需要物料構件W-71600。W-71600是一種公司內部製造的部件，它的BOM包含三種原材料，分別是W-71610，W-71620和W-71630。該專案物料的庫存都是專案專用庫存。專案專用庫存（Project Stock）和統籌庫存（Collective Stock）存在以下區別：<1>專案專用庫存的物料需求計劃（MRP）是分專案執行的，和統籌庫存是分開的。<2>專案專用庫存除了本專案，不能作其他使用。（當然可以由專門的操作先將專案專用庫存轉作普通庫存。）<3>專案專用庫存的生產定單及其成本，採購定單及其承諾等物流過程都可以在專案資訊系統中分專案反映。而統籌庫存的物流過程是不分專案的，因此只有到最後庫存被專案領用才會在專案資訊系統中反映，在這之前的過程在專案中是無法反映的。<4>專案專用庫存的估價和科目都可以和普通庫存分開。此外，該專案的庫存都是有價值的，即物流和價值流同步，物料移動會自動產生相應的財務憑證。
在本情景中，已經透過MRP生成了物料構件W-71600的生產定單以及三項原材料的採購定單。我們的介紹從採購定單開始，下文的每一步對應圖四中的①-⑥：
1． 採購定單。對於專案W-100的物料需求計劃（MRP）為該專案的所有物料以專案專用庫存的形式作出計劃。MRP的結果之一是對於W-71610，W-71620和W-71630三種原材料的採購申請。採購部門負責供應商選擇並將申請轉化成採購定單。圖五顯示了專案資訊系統中一種型別的報表，在報表的左側是專案的結構。我們可以看到由於是專案專用庫存，因此生產定單也會在專案W-100的結構中出現。報表的右側是某個具體格式的傳統報表。我們在左側選擇不同的物件，右側的報表就會顯示該物件的資訊。
在本步驟，當我們看WBS元素“W-100.3”的“實際/庫存/承諾/計劃”報表時，結果如下表所示：
成本要素 實際成本 庫存 承諾 計劃成本
作業成本-人工 0 0 0 0
存貨（統計成本要素） 0 0 2,700 0
生產成本-材料 0 0 0 5,700
生產成本-產出 0 0 0 0
總計 0 0 2,700 5,700
在WBS元素“W-100.3”的計劃成本中已經包含了物料構件W-71600的成本。同時由於採購定單而產生的承諾（將來的成本）也顯示在該報表中。值得注意的是該承諾記錄在“存貨”這個成本要素上。我們知道存貨是一項資產，傳統情況下不會出現在成本流中，但是由於在專案管理中，我們需要追蹤包括專案專用庫存在內的專案價值流，因此我們將存貨建成統計成本要素來滿足這一需求。
2． 採購定單收貨。對於原材料W-71610，W-71620和W-71630的採購定單在本步驟收到貨物。採購收貨的動作增加了專案W-100的專案專用庫存，同時採購定單引起的承諾金額被減少。結果如下表所示：
成本要素 實際成本 庫存 承諾 計劃成本
作業成本-人工 0 0 0 0
存貨（統計成本要素） 0 2,700 0 0
生產成本-材料 0 0 0 5,700
生產成本-產出 0 0 0 0
總計 0 2,700 0 5,700
3． 生產領料。對於W-71600的計劃定單被生產部門轉化成生產定單。如圖四所示該生產定單的目標成本包含3,000元的作業成本和2,700元的原材料W-71610，W-71620，W-71630的成本。這張報表我們在《生產成本》章節已經介紹過了。在圖五的報表中，物料構件W-71600和生產定單都顯示在WBS元素“W-100.3”下，它們的金額在該WBS元素的報表中被加總了。當該生產定單領取三種專案專用庫存W-71610，W-71620和W-71630時，實際成本被計入該生產定單。這次我們在報表左側選定生產定單，結果如下表所示：
成本要素
實際成本 庫存 承諾 計劃成本
作業成本-人工 0 0 0 3,000
存貨（統計成本要素） 0 0 0 0
生產成本-材料 2,700 0 0 2,700
生產成本-產出 0 0 0 5,700-
總計 2,700 0 0 0
4． 工票確認。本步驟生產定單被確認。由於生產定單實際消耗人工時超過目標，導致實際成本增加250元。作業成本增加到3,250元,總成本增加到5,950元。我們在報表左側仍然選定生產定單，結果如下表所示：
成本要素 實際成本 庫存 承諾 計劃成本
作業成本-人工 3,250 0 0 3,000
存貨（統計成本要素） 0 0 0 0
生產成本-材料 2,700 0 0 2,700
生產成本-產出 0 0 0 5,700-
總計 5,950 0 0 0
5． 完工入庫。本步驟生產定單完成最後確認,完工部件W-71600被驗收入庫，成為專案專用庫存。我們在報表左側選定WBS元素，結果如下表所示：
成本要素 實際成本 庫存 承諾 計劃成本
作業成本-人工 3,250 0 0 3,000
存貨（統計成本要素） 0 5,700 0 0
生產成本-材料 2,700 0 0 8,400
生產成本-產出 5,700- 0 0 5,700-
總計 500 5,700 0 5,700
6． 發貨到專案。本步驟我們將部件W-71600發給專案W-100的活動3100使用。這將減少專案專用庫存。同時該部件的實際成本計入網路活動。我們在報表左側選定活動3100，結果如下表所示：
成本要素 實際成本 庫存 承諾 計劃成本
作業成本-人工 0 0 0 0
存貨（統計成本要素） 0 0 0 0
生產成本-材料 5,700 0 0 5,700
生產成本-產出 0 0 0 0
總計 5,700 0 0 5,700
專案的收入和現金管理
對於客戶專案，除了成本，專案還會產生收入。ERP可以透過銷售模組和專案系統模組的整合自動複製銷售定單至專案收入計劃。同時如果銷售定單應用了開票計劃（Billing Plan）功能，開票的日期也將納入計劃中。收入計劃同時也可以顯示銷售折扣，折讓和其他銷售扣減專案。當然，除了整合我們也可以直接手工做專案收入計劃，或者直接將開票計劃維護在WBS元素上。
開票計劃是分次開具發票的計劃。在開票計劃中，我們詳細維護每次開票的日期，開票的百分比和金額，是否凍結和相關的專案里程碑等等資訊。里程碑開票在客戶專案中被廣泛採用。系統將根據專案進度的任何變化自動調整收入計劃。當相關的專案里程碑被確認時，系統可以自動將開票計劃中的某次開票釋放。開票計劃還可以包括預收款，當然預收款隻影響專案收付款而不影響收入。當預收款釋放後，系統可以生成預收款請求，和發票一樣可以列印出來遞交給客戶。隨後收到的預收款會指向相關的請求，並將它清帳。
我們可以結合本章已介紹的內容，設計出這樣一個銷售流程：客戶詢價（Inquiry）=> 分配和定義專案結構 => 專案成本計劃 => 按成本加成法報價（Quotation）=> 銷售定單 => 專案收入計劃。
專案的實際收入將在銷售定單實際開票時由系統自動記錄到相應的專案中。比較特殊的是資源相關定價的專案（或稱為成本補償專案）。在這種專案中，客戶同意付給承約商所有實際花費的成本（勞動力，原材料等等），加上一定的協商利潤，而不是規定數額。對於這種專案系統提供了特殊的功能：自動計算專案成本，將成本按一定規則分類，各類成本按協商利潤加成後確定銷售定單的開票金額，最後開票。這個流程其實使用了和上文銷售流程同樣的工具，我們稱為銷售定單行專案的動態處理，本文不作贅述。
和收入成本一樣，現金流也是我們在專案管理中關心的問題。除了手工計劃專案的收付款，系統可以利用大部分收入和成本的計劃工具來計劃現金流，如開票計劃，發票接收計劃等等。在計算日期時系統會將客戶和供應商的付款條款等因素考慮進去。專案現金管理也使用了《資金管理》章節中科目分層的概念。
期末結帳
專案系統管理模組的期末結帳是專案財務管理的重頭戲。有些步驟和其他模組是類似的，比如流程成本分配到專案（ABC成本法），間接費用法（用成本核算單分配間接費用）等等成本流的期末結轉和專案利息的計算。我們在本書的相關章節都已做過介紹。對於專案管理來說還有些有特殊性的期末結帳活動。
成本預測和進度分析（Progress Analysis）
專案開始執行後，進度和實際成本都可能和計劃偏離。成本預測是在專案執行過程中不斷計算和調整完成專案剩餘部分預計將要發生的成本。成本預測的資料基礎是：計劃成本，實際成本，承諾，確認的預測完工日期和完工工作量。圖八顯示了計劃成本，實際成本和預測成本這三者的關係。預測成本的資料在系統中儲存在一個特殊的計劃版本中。我們可以用這個特殊版本編制層次結構報表或成本要素報表。
從圖8中，我們看到，雖然該專案的實際成本發生低於計劃。但是從預測成本來看，成本暫時低於計劃很有可能是專案進度拖後造成的。所以僅僅孤立地檢查專案的成本，資源和程式是無法有效控制專案的。我們需要更有意義的資訊來分析專案到目前為止的進展情況和健康狀態。進度分析（Progress Analysis）正是實現這一目的。ERP中的進度分析使用的是專案管理理論中的實現價值分析（Earned Value Analysis）方法。
我們首先需要計算完工比率（POC，Percent of Completion）。我們可以人為估計WBS元素，活動和活動元素的POC，或者可以由系統根據已有資料自動計算。系統總共提供了九種確定POC的方法：開始/結束規則；估計；里程碑技術；時間比例法；成本比例法；數量比例法；進展程度法；次級比例法（或相關比例法）；使用者出口（允許使用者自定義規則的程式出口）。我們需要計算兩個POC：計劃POC，指在指定時間點上預計的完工比率；實際POC，指在指定時間點上實際的完工比率。隨後，透過某種權數（通常是計劃成本），我們可以彙總整個專案結構的所有POC，計算出整個專案的POC。
接下來，我們利用POC來計算如圖九所示的一組關鍵指標：
BCWS：Budgeted cost of work scheduled， = 總計劃成本 * 計劃POC。反映的是按照計劃到今天應該產生了多少成本。
BCWP：Budgeted cost of work performed，= 總計劃成本 * 實際POC。反映的是根據到目前為止的專案進度，應該產生多少成本。或者說到目前為止乾的活值多少，不過這個值多少仍然是成本的概念，不能和收入混淆起來。
SV：Schedule variance 進度差異，= BCWS – BCWP。反映了專案進度落後計劃多少，它告訴我們我們的專案是否太慢了。
CV：Cost variance 成本差異，= 實際成本 – BCWP。反映了專案是否超支了，它告訴我們我們的專案是否太昂貴了。
透過SV和CV兩個差異的分離，我們可以解釋專案目前的進展情況以及專案的健康狀況。
結果分析（Results Analysis）
我們在《成本流和成本物件》章節中提到，結果分析是一種型別的“由內至外的過帳”。專案管理中的結果分析解決的究竟是什麼問題呢？在長期的客戶專案中，日常收入和成本的的入帳都跟相關的業務處理相聯絡，比如開票，發票校驗等等。但是這樣的收入和成本資料很多情況下是不能滿足會計的權責發生原則和配比原則的。因此根據實質重於形式的原則和各國關於長期專案收入和成本核算的相關準則，我們需要對專案在各會計期間的收入和成本數進行調整。結果分析就是根據事先設定的規則，自動計算相關會計期間實際應確認的專案收入和成本，並自動生成調整分錄的系統功能。
新近定單（Incoming Orders）
對於某些圍繞客戶專案運轉的公司，新簽定的專案和進行中的專案對於預測公司將來的盈利前景具有重要意義，這對於以長期和超長期專案為主的公司來說由為重要。新近定單（Incoming Orders）和未完成定單（Open Orders）是這方面的兩個重要指標。新近定單是考慮了定單更改，定單取消和計劃更改等歷史因素後的新簽定和進行中定單的價值。未完成定單價值是新近定單減去已確認的收入和成本後的價值。ERP可以根據專案管理系統和銷售模組的資料，自動計算出類似下表的報表：
收入 成本 利潤 利潤率%
新定單 -940 460 -480 51
定單更改 -280 50 -230 82
定單取消 20 -12 8 -40
計劃更改 0 80 80 -50
總新近定單 -1,200 578 -622 51
已開票 -600 400 -200 33
未完成定單 -600 178 -422 70
其中計劃更改是由於專案成本結構改變後引起的利潤降低。
結算
專案的結算和內部定單的結算在基本概念上是一致的。只是由於專案具有複雜的結構，因此在結算時整個結構的不同部分（各WBS元素和活動）的結算規則是一個特殊的問題。首先，是結算規則的決定。WBS元素的結算規則可以透過不同的策略決定。比如對於客戶專案往往會對開票的WBS元素先做結果分析。結果分析的資料包括了其下層WBS元素和活動/定單的成本和收入。因此只有開票的WBS元素被結算。結算規則只維護在開票的WBS元素上。這種結算規則很可能是根據開票WBS元素和相連的銷售定單決定的市場細分。其它的物件的結算規則都定為“不結算”。再比如對於成本專案，系統可以從各WBS元素的負責成本中心或申請成本中心生成結算規則。或者還可以讓下層的WBS元素繼承上層WBS元素的結算規則等等。對於網路/活動，我們可以定義一個包含若干優先次序的“結算規則決定策略”。比如活動的結算規則依次<1>從其分配的WBS元素中繼承。<2>從專案定義中繼承。<3>按預設規則自動生成。<4>手工維護等等。其次，從結算的順序上，也有多層上卷後統一結算和分別直接結算兩種。
軟體開發專案中如何使用範圍變化管理
專案管理過程不從確定專案開始，也不隨著專案計劃完成而告終。你必須要在專案管理過程中使用範圍變化管理，如果你不善用此一技巧，那麻煩將是不可避免的。
確定並計劃專案僅僅是成功的專案管理過程的第一步。在制定出計劃之後，你還必須要將計劃付諸實施。你必須要保證計劃任務在規定的時間內完成，而且不能超出原有的預算。一旦專案開始進行，客戶可能會向你提出更多的或是與原計劃不同的要求。在這個時候範圍變化管理就可以派上用場了。如果你不善用此一技巧，專案小組就只能嘗試著在專案時間和預算不變的情況下去完成比原計劃多得多並且要耗費更多成本的任務。換句話來說，就是麻煩將是不可避免的。
範圍管理從範圍界定開始
對專案範圍進行界定恐怕是確定專案的過程當中最為重要的組成部分。事實上，如果你並不能確定專案的目標任務，也不能確定專案的範圍，專案就根本不可能成功。範圍管理是專案管理過程當中最為關鍵的組成部分之一。但是，如果不能對專案的範圍作出成功的界定，想要實施範圍管理也幾乎是不可能的。
界定範圍的目的是清楚描述專案的邏輯範圍並在此問題上同有關各方達成一致。對專案範圍的陳述可以讓大家清楚的瞭解哪些工作是專案範圍之內的事情，而哪些工作不屬於該專案範疇。對專案範圍的界定越明確，對專案就越有利。下面這些資訊應該能起到一些幫助作用。
範圍內和範圍外的任務型別（業務需求、現狀評估）
範圍內和範圍外的生命週期流程（分析、設計、測試）
範圍內和範圍外的資料型別（財務、銷售、員工）
範圍內和範圍外的資料來源或資料庫（賬單、公司總帳，薪水明細）
範圍內和範圍外的部門（人力資源、製造商、供貨商）
範圍內和範圍外的主要功能（決策支援、資料輸入、管理報告）
制定可行的範圍變化流程
專案經理和專案小組的成員都必須意識到，專案範圍的變化本身並沒有錯。也就是說，在專案的進行過程中改變專案範圍並不是一件壞事。事實上，在很多情況下，這還是一件好事。首先，客戶通常都不能在專案開始之前明確所有的需求。其次，即使他們能夠做到這一點，整個的商業環境也是在不斷變化的，所以專案需求也可能會隨之而發生變化。
如果你不能夠適應變化，專案的最終價值可能會受到影響，或者可能會使專案失去價值。因此，你需要具備在專案進行的過程當中根據需要作出改變的能力。如果專案經理不能夠在專案進行過程當中積極的對變化進行管理，問題可能就會隨之而來。任何專案都應該有一個有效的變化管理流程。這個流程應該包括對變化的識別判斷，對變化的商業價值的判斷，對變化會給專案帶來的衝擊和影響的判斷，將相應的資訊提交專案投資人進行評估。專案投資人來最終決定是否將變化引入到專案當中。如果變化被引入專案，專案投資人還應該考慮變化對專案的影響程度，並且為之配備相應的額外資源，如延長時間和追加資金預算等。
企中的專案有哪些呢？如果我們把企業的經營活動進行分解，會發現企業中的各種工作基本上都可以歸類為一個又一個的專案，大到：IT服務專案、工程建設專案、產品開發專案、投資專案、ERP專案、BPR專案、薪酬改革專案、市場開發專案、房地產開發專案等等，小到：一次搬遷、一次校園招聘會、一次內部培訓、一次會議組織、一次新年聚會等等。
專案管理就是在有限的資源約束下運用系統的觀點、方法和理論以實現專案的目標的方法。著名的美國的阿波羅登月計劃，整個專案大約有40萬人和20萬家企業參加，耗資200多億美元，就是專案管理成功應用的傑出典範。
計劃、控制、度量——洗盡鉛華的專案管理真諦
在亂花漸欲迷人眼的專案管理領域內，專案經理們總是很容易被各種理論說服，被各種模型吸引，被各種模版包圍，可是，對一個具體的專案來說，什麼才是最重要的呢，需要做些什麼才能讓專案可控，並且朝著成功的方向走近呢？
去掉繁複的理論體系和證書的包裹，專案管理的目標其實很樸素，手段其實很簡單，只是為了讓專案成功，做好這樣三件事——計劃、控制、度量。這是筆者根據多年的專案管理實踐，從實用的角度出發，結合多個理論模型總結出來的一點經驗和體會，希望能對各位有所啟發。
正文
專案管理的理論體系很多，對專案管理的理解也各不相同，各種組織的最佳實踐模型更是數不勝數。那麼，我們在實際的軟體開發過程中該如何選擇，如何應用呢？
結合各種PM理論基礎和在實際工作中積累的專案管理經驗，筆者認為，對於一個具體的專案來說，專案管理的核心問題不是採用哪種理論體系，不是透過哪種認證評估，也不是選擇哪個最佳實踐模型，而是要做好這樣三件事——計劃、控制、度量。也就是說，專案啟動之前，要有計劃；專案進行當中，要有控制；專案結束之後，要有度量。這樣才能保證專案有的放矢（依照計劃執行）、有據可查（產生管理文件）並且讓以後類似的專案在計劃階段有章可循（參考度量的結果）。
下面來看看我們在計劃、控制和度量這三件事情上需要做些什麼。
1. 計劃
專案的計劃階段一般會對專案的可行性進行分析，並提出若干備選方案，然後根據組織的目標、能力和預算，挑選一個最適合的方案來執行。
選定方案之後，要根據專案範圍、資源配備和預算等條件，制定出專案的進度計劃、人員配置計劃、預算計劃、風險管理計劃，以及專案管理所需的其它QA計劃、CM計劃、MA計劃等輔助計劃。
2. 控制
為了保證專案能夠按計劃順利完成，在專案執行階段，我們有很多工作要做。
專案的進度控制、質量控制和成本控制是專案管理中最關鍵也是最重要的三個方面，此外還有風險的識別和管理，也是影響專案成敗的重要因素之一。
專案進度管理需要在每個里程碑或檢查點及時檢查是否按照計劃要求完成了相關的工作內容和需要交付的工作產品，以保證專案進度在控制之中。
質量管理是要確保每個工作階段的可交付產品符合專案和組織的質量標準，確保最終交付的產品是合格的，可以使用的。
成本管理是為了保證專案不超出組織的預算，對於內部的IT專案而言，員工的工作時間就是專案的主要成本。基本上，保證專案按照計劃的進度和人員配置完成，就可以保證成本在可控範圍之內。
風險管理主要是應對突發的、不確定的因素對專案造成的影響。需要在計劃階段就制定出風險應對計劃，在執行階段及時發現和識別風險，當風險發生時，採取正確的措施應對，儘量減少負面影響。
3. 度量
在專案執行過程中，除了要對專案的進度、範圍、質量進行管理和控制，也要對專案的關鍵指標（工作量、里程碑、工作產品、人員配置、物理規模等）進行度量，透過各種度量指示器在專案的執行階段持續的跟蹤和記錄專案進展情況，及時發現進度、成本和質量上的偏差。
除了跟蹤和發現專案偏差之外，度量的更深層次的意義在於為以後的專案提供可參考的歷史資料，為組織積累經驗，提高組織的計劃和估算能力。但是在實際的專案當中，很多專案經理認為，度量對當前專案的意義不大，不願意花時間去做度量。其實這對組織來說是很不利的，因為如果沒有歷史資料的積累，即使已經做過了大量的專案，組織仍然無法為專案的規模、成本、人員等的估算和計劃制定提供確切的歷史資料和估算依據，組織的專案管理將仍然是粗放型的，做不到精細化管理，達不到更高的專案管理水平。
度量的意義重大，但真正知道該怎樣做的人並不多，這點我將在今後的文章中專門講述，並儘量提供詳盡的參考模版。
為了更清楚的說明計劃、控制和度量在專案管理中的重要作用，下面舉一個買鞋的例子來詳細說明。
根據專案的定義：“專案是為完成某一獨特的產品、服務或任務所做的一次性努力”，某次買鞋的過程具有獨特性、一次性和不可重複性的特點，是典型的專案，我們可以稱之為“買鞋”專案。
在“買鞋”專案中的計劃、控制和度量是怎樣的呢？
l 首先是計劃。在買鞋之前，我們首先要明確是否一定要購買新鞋，是否有時間去商場，然後提出幾個備選的商場，這相當於可行性分析和備選方案；考慮一下自己希望與之搭配的服裝，個人的氣質特點，本次購買的預算，然後選擇一個各方面最適合的商場，這相當於選擇合適的專案方案；根據選定的方案，制定出選購活動的時間表、價格標準、鞋子款式、午餐安排等，這相當於制定專案進度計劃及相關的輔助計劃。
l 然後是控制。對於“買鞋”專案來說，我們要注意鞋子是否符合最初的款式要求，這相當於質量控制；我們還要把價格控制在可以接受的限度之內，這相當於成本控制；我們不想在商場花費過多的時間，因此要控制在每個專櫃花費的時間不要過多，這相當於進度控制；及時提醒自己不要買計劃外的物品，不要輕易聽從專櫃小姐的勸說購買價格過高的鞋子，這相當於風險控制。
l 最後是度量。在逛商場的過程中，經常比對一下款式、價格、時間上的計劃和實際的偏差，相當於度量的跟蹤和記錄。把鞋子買回去之後，可以再對最終購買的鞋子的價格、款式、所花費的時間與出發前的計劃進行對照和統計，分析一下估算與實際情況的偏差，總結出這次購買行動的成功經驗和待改進之處，以便為以後類似的購買行為提供精確的可參考資料。
從以上的分析可以看出，計劃、控制、度量這三件事是專案管理的核心和關鍵之所在，無論我們應用什麼樣的專案管理方法和模型，做好這三件事，就等於抓住了專案管理的本質，掌握了專案管理的真諦，這時，我們就可以不再為眾多的理論體系所制約，可以得心應手的根據專案特點和組織需要來創造性的做好專案管理工作了。也只到有這個時候，我們的專案管理才算是真正學到家了。
專案管理系統（Project System）是ERP的一個整合解決方案，它的目的是幫助企業執行專案管理中的所有任務，因此它包括了在專案所有階段的各種功能。ERP的專案管理涵蓋了兩類專案：客戶專案和成本投資專案。客戶專案是指以銷售為目的，根據客戶需求執行的專案。這類專案和銷售模組有很強的聯絡和整合。在造船，建築，工程，服務，軍工等各種行業有廣泛的應用。成本投資專案是指企業內部各種型別的專案，這些專案的成本在專案完成後或者資本化或者費用化，包括研發專案，投資專案，IT專案，裝置維護專案等等。這類專案在各種行業的應用更為廣泛。
專案的結構
在正式執行一個專案之前，我們必須明確地定義專案的目標並制定專案所要執行的工作的結構。明確定義的專案結構為成功的專案計劃，執行和控制提供了先決條件。圖一是ERP中主要的專案結構物件，以及它們之間的相互關係。
專案定義（Project Definition）
專案定義是一個總括的專案描述。專案定義為將來專案計劃階段所要建立的所有專案管理物件提供了一個框架。
工作細分結構（ Work Breakdown Structure）
工作細分結構是以層次結構的形式將完成一個專案所要執行的任務層層細分所形成的專案結構。它提供了關於專案的概覽並且構築了專案的組織結構和協調合作的基礎，同時顯示了專案在工作，時間和金錢上的花費，可以應用它來計劃時間，成本和分配預算。
工作細分結構中的每一項任務被稱為WBS元素（WBS Elements）。和別的專案結構物件一樣，系統在WBS元素中維護了很多資訊。比如有關於組織結構關係的資訊：公司程式碼，業務範圍，工廠（物流模組），裝置或功能地點（工廠維護模組），利潤中心等等。再比如在基礎資訊中有三個標誌：<1>成本計劃。如果要對這個WBS元素計劃成本，我們必須指明該WBS元素是一個計劃元素。<2>成本物件。如果想將實際成本和承諾記錄到某個WBS元素，我們必須指明該WBS元素是一個成本物件。如果這個標誌沒有開啟，該專案中其他能夠分配成本和承諾的物件（比如內部定單，網路或採購定單）也將不可以分配給該WBS元素。<3>開票。如果想將收入確認到某個WBS元素，我們必須指明該WBS元素是一個開票元素。還有很多資訊被分別組織在專案責任，控制資料，憑證，開票計劃，結算規則，在建工程，資本投資計劃等等檢視中。
網路（Network）
和WBS不同，網路描述的是專案執行過程。網路是一種在專案進度安排，成本和資源安排的計劃，分析和控制工作中很有用的技術。我們可以將網路分配給專案定義，WBS元素或者銷售憑證。
構成網路的關鍵元素是活動（Activity）和活動之間的關係。活動具有以下特徵：它們持續一定的時間；它們有明確的開始和結束；它們執行的過程不被中斷（指如果有中斷應定義多個分開的活動）；執行他們需要一定的資源；它們引起成本。活動如圖一所示可以分配給WBS元素。
圖二我們給出了各種型別的活動。ERP專案系統區分三種主要型別的活動：內部處理活動（Internally processed activities），外部處理活動（Externally processed activities）和一般成本活動（General costs activities）。我們甚至可以將活動進一步細分成活動元素（Activity Elements），如圖二最右側的活動。活動元素也可以區分成上述三種型別。
對於內部處理活動，為了計劃完成它所牽涉的工作，以及提供成本計算的基礎，我們需要明確如下一些問題，比如：執行該活動需完成多少工作；什麼產能（如人工或機器）會用來執行這些工作；什麼資格（Qualifications）是完成該活動所必須具備的；哪些人員或個別產能是完成該活動所必須提供的等等。因此我們會在內部處理活動中指明工廠，工作中心等組織機構和工作時間等資訊。
對於外部處理活動，我們一般需指明負責的採購組織和採購組。在釋放網路時，系統可以自動建立採購申請，由採購部門負責完成。或者我們也可以手工觸發採購申請建立。我們也可以將採購資訊記錄記錄到外部處理活動中，採購資訊記錄裡維護了供應商，價格條款等資訊。
另外我們可以將物料分配給所有的活動，如圖2最左側的活動。在專案執行的過程中，生成採購申請或計劃定單，分別由採購部門或生產部門完成。
活動和活動之間在系統中可以維護四種關係：結束-開始（Finish - Start (FS) Relationship），開始-開始（Start - Start (SS) Relationship），結束-結束（Finish - Finish (FF) Relationship）和開始-結束（Start - Finish (SF) Relationship）。
里程碑（Milestones）
里程碑是專案中有特殊重要性或者會觸發某些事先定義功能的一類事件。一般來說它們顯示了專案各階段或各部門間的銜接點。在ERP中里程碑可以分配給活動（Activity）和WBS元素。里程碑可以實現四種任務：<1>里程碑趨勢分析（Milestone Trend Analysis /MTA）。是一種控制專案進度的簡單而有效的工具。在不同報表日期，里程碑日期被用於比較分析，圖形化的MTA使我們可以立刻發現專案趨勢和任何的延誤。<2>使用里程碑技術的實現價值分析（Earned Value Analysis）。里程碑技術是眾多計算實現價值技術中的一種。每一個里程碑代表了活動或WBS元素所完成的這部分工作。<3>決定開票計劃的日期。將里程碑和開票計劃的日期相連。當專案進度到達某個里程碑時，里程碑的實際日期將被自動複製到開票計劃中。<4>觸發預定義的里程碑功能。我們可以利用里程碑觸發一系列事件來處理某些特定的業務流程。
在ERP專案結構的建立中有兩種可以增強工作效率的功能：<1>標準專案結構和複製功能。<2>圖形功能。
專案的成本控制
ERP透過專案成本的計劃和實際比較來達到控制成本的目的。專案成本控制元件和其它相關模組有緊密的整合。這些模組包括管理會計，財務會計，生產計劃和控制，物料管理。
成本計劃
專案成本計劃在專案的不同階段有不同的作用：在概念定義和粗略計劃階段，成本計劃的作用是計算一個專案最初的成本估算；在審批階段，成本計劃是分配預算的基礎；在專案執行階段，我們使用成本計劃來控制實際成本和成本差異。 ERP成本計劃有如下幾種方式：
1． 簡便成本計劃。簡便成本計劃的核心是成本模型（Costing Model）。對於成本結構相似且經常重複出現的任務，我們可以定義成本模型。在對WBS元素計劃成本時，只要提供相關的數量和引數，就可以計算出成本計劃。舉例來說，假如我們的專案經常需要埋設管道。但是不同的專案，埋設管道的直徑以及溝渠的長寬深各不相同。我們可以設計如下成本模型：
描述 型別 物件 數量 啟用 價格
挖掘溝渠的人工成本 成本中心/作業型別 4298/1421 溝渠長度*溝渠寬度*溝渠深度/10
挖掘溝渠的機器成本 成本中心/作業型別 4298/1420 溝渠長度*溝渠寬度*溝渠深度/10
管道 工廠/物料 0001/管道-10 溝渠長度 管道=“10釐米直徑”
管道 工廠/物料 0001/管道-20 溝渠長度 管道=“20釐米直徑”
放置管道的人工成本 成本中心/作業型別 4298/1421 溝渠長度/5 管道=“10釐米直徑”或“20釐米直徑”
填平溝渠的人工成本 成本中心/作業型別 4298/1421 溝渠長度*溝渠寬度*（溝渠深度-0.1）/10 管道=“10釐米直徑”
填平溝渠的機器成本 成本中心/作業型別 4298/1420 溝渠長度*溝渠寬度*（溝渠深度-0.1）/10 管道=“10釐米直徑”
填平溝渠的人工成本 成本中心/作業型別 4298/1421 溝渠長度*溝渠寬度*（溝渠深度-0.2）/10 管道=“20釐米直徑”
填平溝渠的機器成本 成本中心/作業型別 4298/1420 溝渠長度*溝渠寬度*（溝渠深度-0.2）/10 管道=“20釐米直徑”
差旅費用 可變專案（成本要素） 420000/H 工期 固定費率
只要某個專案含有埋設管道的WBS元素，我們就可以使用這個成本模型，提供溝渠的長，寬，深以及管道型別就可以計算出成本計劃。
我們可以在兩種情況下很好地利用簡便成本計劃：<1>關注成本控制的專案管理。如果你使用專案作為成本控制的工具，對於專案成本計劃的高效性，直觀性和易用性特別看重，那麼簡便成本計劃是很好的工具。<2>複雜專案的初步成本計劃。如果我們使用專案系統來管理複雜的客戶專案或成本投資專案，那麼我們需要一個簡單但高效的工具來作出初步成本計劃，這種初步計劃可以成為客戶專案報價的基礎。當專案被批准或接受定單後，我們會使用網路來做詳細的成本計劃。初步計劃將被保留在一個分開的計劃版本里作分析比較使用。
2． WBS的手工成本計劃。這種計劃方法是指根據專案的WBS結構，手工編制專案成本計劃。具體來說又有三種形式：
<1> 層次計劃（Hierarchy Planning）。這是最簡單的形式，計劃是不分成本要素的，也就是說對於WBS元素的成本是總數的形式，而不考慮成本的構成。計劃者沿著WBS的層次結構對整個專案和會計年度編制簡單的成本計劃。
<2> 成本要素計劃。當我們獲取關於專案成本更詳細的資訊時，可以編製成本要素計劃。這種計劃涵蓋初級成本要素，作業型別投入（從服務成本中心流入的次級成本要素）和統計指標的計劃。
<3> 單位成本法（Unit Costing）。如果我們有資源供給的來源，數量和單價等資訊，那麼單位成本法是WBS手工成本計劃中最為詳細的一種形式。單位成本法實際上是一種電子表格，由於系統整合的緣故，這種電子表格可以呼叫系統存在的主資料和價格資料，比如成本中心模組的作業價格，物料的標準成本等等。和其他電子表格一樣，我們可以利用單位成本法計算總計，小計和其他數學公式。 單位成本法按專案類別對成本分類，不同的專案類別需要成本編制者輸入相應的內容，系統會自動查詢並計算成本。比如對於內部加工成本，需要輸入成本中心，作業型別和數量。系統會自動尋找作業價格，計量單位和成本要素，並計算成本。再比如對於外部加工或外包成本，需要輸入採購資訊記錄，工廠，採購組織數量和成本要素。系統會自動尋找價格和計量單位，並計算成本。再比如對於物料成本，需要輸入物料號，工廠和數量。系統會自動尋找物料成本，計量單位和成本要素，並計算成本。而對於間接費用，系統會根據成本核算單自動按比例並選取基數進行計算。
三種計劃方式可以在專案的不同階段使用，也可以同時使用。比如對於關鍵WBS元素用單位成本法，而其他用層次計劃法。
3． 網路成本計劃。上述兩種計劃方式，要麼是在專案初期使用，要麼是對那些只使用專案管理模組一部分功能（主要是作為成本核算物件）的專案使用。換句話說是對那些還沒有維護詳細的專案網路結構的專案使用的。回顧一下上一節和圖二關於網路的介紹，一個資訊完整的網路中已經包含了成本計算的所有條件。這一點我們只要和單位成本法所要輸入的資料比較一下就清楚了。因此我們可以在儲存網路，或者釋放網路時讓系統自動計算專案成本，或者手工觸發專案成本的計算。這種計劃的好處之一是成本計劃和時間進度控制以及資源計劃是整合的。因此如果網路結構或活動的時間發生變化，成本計劃也會自動地做相應調整。
我們可以對活動（外部的，服務的或一般成本的）或外購的物料構件直接建立發票接收計劃（Invoicing Plans）。這意味著系統可以根據發票接收計劃中的日期計劃成本和支付。成本將根據發票接收計劃上的時間準確地計算而不是簡單地分配到時間段上。在建立發票接收計劃時我們可以複製一個參考發票接受計劃，系統將根據實際的開始日期重新計算成本和時間。
隨著專案程式的展開，相對於計劃成本，實際成本將開始發生。網路實際成本通常由下列業務產生：財務會計過帳；物料管理的貨物移動；內部作業分配；間接費用；確認（Confirmations）；收到發票。
4． 分配給專案的定單。如果一個WBS元素是一個成本物件，那麼我們可以將不同種類的定單分配給它。這種分配意味著這些定單將在專案的架構下管理。這些定單的計劃成本將以彙總的形式記錄到專案中。在ERP中，我們使用定單實現不同的目的。可以分配給專案的定單包括：<1>內部定單。用於管理成本的定單。<2>裝置維護定單。是裝置管理模組中用來計劃裝置維護行為，輸入和結算裝置維護成本的定單。<3>生產定單。用於製造產品的定單。<4>銷售定單。是一個銷售組織和售達方關於以明確的價格和時間提供指定數量的商品或服務的契約協議。此外，根據定單是否消耗專案預算，可以分成消耗預算定單和獨立預算定單兩種。
預算和可用性控制
在成本計劃階段，我們將利用上述的工具儘可能地準確計劃專案成本。這個階段往往採取自下而上的方式，從最底層最細節的活動或WBS元素開始進行計劃，層層彙總和修正，最終形成整個專案的成本計劃。接下來在審批階段，資金將以預算的形式明確和分配下來。預算分配的過程和成本計劃的過程剛好相反。它是沿專案的結構自上而下分配下去的。預算和成本計劃的區別在系統中是很微妙的。預算是具有束縛力的，它是管理層控制一段時間內成本發展的審批工具。當計劃批准為預算後，這種束縛是體現在成本總額上的。明細的實際/計劃比較是分析的工具，而不具有直接的約束力。
可用性控制在一定程度上體現了預算的束縛力。在專案的進行過程中，可使用的資金將被投入到不同的地方。承諾（指採購定單和採購請求）和實際成本相繼發生。同時分配給該專案的消耗預算定單也將陸續發生各種成本。所有這些統稱為“已分配資金”。當然我們可以使用“資金使用概覽”等報表控制預算的使用，但是這種控制是被動的，也就是說，你必須自己去看這個報表才能知道預算使用情況，才能實施某種控制手段，比如凍結成本的發生，或通知相關人員。ERP專案管理系統還提供了主動的“可用性控制”。在執行成本相關的操作時，系統將自動計算已分配資金並和預算比較。如果超過了某個容忍水平（比如“90%預算已分配”，或“預算超過5%”等等），將觸發各種系統反映（比如，警告，警告併傳送電子郵件或錯誤資訊）。我們可以在後臺靈活地定義各種容忍水平和系統的反映方式。系統在計算已分配資金時會自動尋找相關的WBS元素，並自動彙總它下層的所有成本物件的已分配資金。
對於預算控制，系統還提供了各種工具：原始預算編制，預算更新，預算釋放和預算結轉。預算更新包括了預算增加，預算返還和預算劃撥。預算釋放功能使得我們可以分階段部分地釋放預算，以避免預算過早的耗盡。預算的結轉是指可以將本年未使用完的專案預算結轉到下一會計年度。
此外，如果我們使用ERP的投資管理模組。那麼投資專案作為企業投資計劃的實現工具，將被納入整個企業投資計劃的成本計劃和預算控制架構中。
承諾和實際成本
和其他管理會計模組類似，專案實際成本流的來源是ERP系統的各種業務模組。除了實際成本流以外，承諾（指採購申請和採購定單這些將來的成本流）也是專案需要控制的。這些業務模組包括：<1>採購：採購申請，採購定單，收貨和服務確認。<2>庫存管理：物料領用。<3>財務會計：總帳過帳。<4>管理會計：間接費用法，流程成本（ABC成本法），利息計算，結算（定單），分配，分攤，作業分配。<5>專案系統管理：確認（Confirmation）。
確認（Confirmation）記錄了活動或活動元素的進展情況（主要包括實際時間和預計剩餘時間），從而使我們可以作出關於專案將來發展的預測。確認的動作在系統中會實現多項功能，其中包括實際成本過帳。我們可以用很多方式來完成確認：<1>單獨確認，對個別網路，活動，活動元素或產能的確認。<2>彙總確認。<3>從資訊系統出發，生成要求確認的工作流，傳送給相關使用者進行確認。<4>使用跨模組的時間表（Time Sheet）。時間表是ERP系統中記錄個人工作時間及工作物件的工具。說它是跨模組的，是因為時間表的資料可以被很多模組使用，比如人力資源，專案系統，裝置維護，管理會計，服務管理等等。<5>使用Internet完成單獨確認，彙總確認或填寫時間表。<6>透過系統介面，從PDA裝置，或其他外部系統輸入資料。
專案中的物料
在專案結構這一節中，我們介紹了物料構件可以分配給網路中的活動。這種分配的含義是指這些部件或原材料是在專案的這個階段所必須的，因此需要被保留或預定。根據專案以及物料的特徵，這些物料將透過觸發MRP或者採購來獲得。從圖三我們看到專案系統這個模組從專案的角度整合了銷售，採購和生產等模組。而專案中的物料是這種整合的一種重要形式。
專案中的物料是專案管理中一個複雜的組成部分。比如有些物料是直接採購的，有些物料有BOM和工藝路線，是企業內部製造的（如圖三中分別指向採購和生產的箭頭）。再比如有些物料是納入庫存管理的，有些則完全不納入庫存管理體系。再比如有些庫存是專案專用的，而有些是企業統籌計劃的。再比如有些庫存是有價值的，而有些是不含價值的（或者說只管理物流而不管理價值流），諸如此類。這些都體現了ERP的高可配置性和靈活性。但是由於這個組成部分更多的涉及物流管理，因此本文中我們只選取一種常用的情景，從財務的角度來介紹專案中的物料這個功能。
我們的情景如圖四所示，在專案W-100中，活動3100分配給WBS元素W-100.3。在這個活動中需要物料構件W-71600。W-71600是一種公司內部製造的部件，它的BOM包含三種原材料，分別是W-71610，W-71620和W-71630。該專案物料的庫存都是專案專用庫存。專案專用庫存（Project Stock）和統籌庫存（Collective Stock）存在以下區別：<1>專案專用庫存的物料需求計劃（MRP）是分專案執行的，和統籌庫存是分開的。<2>專案專用庫存除了本專案，不能作其他使用。（當然可以由專門的操作先將專案專用庫存轉作普通庫存。）<3>專案專用庫存的生產定單及其成本，採購定單及其承諾等物流過程都可以在專案資訊系統中分專案反映。而統籌庫存的物流過程是不分專案的，因此只有到最後庫存被專案領用才會在專案資訊系統中反映，在這之前的過程在專案中是無法反映的。<4>專案專用庫存的估價和科目都可以和普通庫存分開。此外，該專案的庫存都是有價值的，即物流和價值流同步，物料移動會自動產生相應的財務憑證。
在本情景中，已經透過MRP生成了物料構件W-71600的生產定單以及三項原材料的採購定單。我們的介紹從採購定單開始，下文的每一步對應圖四中的①-⑥：
1． 採購定單。對於專案W-100的物料需求計劃（MRP）為該專案的所有物料以專案專用庫存的形式作出計劃。MRP的結果之一是對於W-71610，W-71620和W-71630三種原材料的採購申請。採購部門負責供應商選擇並將申請轉化成採購定單。圖五顯示了專案資訊系統中一種型別的報表，在報表的左側是專案的結構。我們可以看到由於是專案專用庫存，因此生產定單也會在專案W-100的結構中出現。報表的右側是某個具體格式的傳統報表。我們在左側選擇不同的物件，右側的報表就會顯示該物件的資訊。
在本步驟，當我們看WBS元素“W-100.3”的“實際/庫存/承諾/計劃”報表時，結果如下表所示：
成本要素 實際成本 庫存 承諾 計劃成本
作業成本-人工 0 0 0 0
存貨（統計成本要素） 0 0 2,700 0
生產成本-材料 0 0 0 5,700
生產成本-產出 0 0 0 0
總計 0 0 2,700 5,700
在WBS元素“W-100.3”的計劃成本中已經包含了物料構件W-71600的成本。同時由於採購定單而產生的承諾（將來的成本）也顯示在該報表中。值得注意的是該承諾記錄在“存貨”這個成本要素上。我們知道存貨是一項資產，傳統情況下不會出現在成本流中，但是由於在專案管理中，我們需要追蹤包括專案專用庫存在內的專案價值流，因此我們將存貨建成統計成本要素來滿足這一需求。
2． 採購定單收貨。對於原材料W-71610，W-71620和W-71630的採購定單在本步驟收到貨物。採購收貨的動作增加了專案W-100的專案專用庫存，同時採購定單引起的承諾金額被減少。結果如下表所示：
成本要素 實際成本 庫存 承諾 計劃成本
作業成本-人工 0 0 0 0
存貨（統計成本要素） 0 2,700 0 0
生產成本-材料 0 0 0 5,700
生產成本-產出 0 0 0 0
總計 0 2,700 0 5,700
3． 生產領料。對於W-71600的計劃定單被生產部門轉化成生產定單。如圖四所示該生產定單的目標成本包含3,000元的作業成本和2,700元的原材料W-71610，W-71620，W-71630的成本。這張報表我們在《生產成本》章節已經介紹過了。在圖五的報表中，物料構件W-71600和生產定單都顯示在WBS元素“W-100.3”下，它們的金額在該WBS元素的報表中被加總了。當該生產定單領取三種專案專用庫存W-71610，W-71620和W-71630時，實際成本被計入該生產定單。這次我們在報表左側選定生產定單，結果如下表所示：
成本要素
實際成本 庫存 承諾 計劃成本
作業成本-人工 0 0 0 3,000
存貨（統計成本要素） 0 0 0 0
生產成本-材料 2,700 0 0 2,700
生產成本-產出 0 0 0 5,700-
總計 2,700 0 0 0
4． 工票確認。本步驟生產定單被確認。由於生產定單實際消耗人工時超過目標，導致實際成本增加250元。作業成本增加到3,250元,總成本增加到5,950元。我們在報表左側仍然選定生產定單，結果如下表所示：
成本要素 實際成本 庫存 承諾 計劃成本
作業成本-人工 3,250 0 0 3,000
存貨（統計成本要素） 0 0 0 0
生產成本-材料 2,700 0 0 2,700
生產成本-產出 0 0 0 5,700-
總計 5,950 0 0 0
5． 完工入庫。本步驟生產定單完成最後確認,完工部件W-71600被驗收入庫，成為專案專用庫存。我們在報表左側選定WBS元素，結果如下表所示：
成本要素 實際成本 庫存 承諾 計劃成本
作業成本-人工 3,250 0 0 3,000
存貨（統計成本要素） 0 5,700 0 0
生產成本-材料 2,700 0 0 8,400
生產成本-產出 5,700- 0 0 5,700-
總計 500 5,700 0 5,700
6． 發貨到專案。本步驟我們將部件W-71600發給專案W-100的活動3100使用。這將減少專案專用庫存。同時該部件的實際成本計入網路活動。我們在報表左側選定活動3100，結果如下表所示：
成本要素 實際成本 庫存 承諾 計劃成本
作業成本-人工 0 0 0 0
存貨（統計成本要素） 0 0 0 0
生產成本-材料 5,700 0 0 5,700
生產成本-產出 0 0 0 0
總計 5,700 0 0 5,700
專案的收入和現金管理
對於客戶專案，除了成本，專案還會產生收入。ERP可以透過銷售模組和專案系統模組的整合自動複製銷售定單至專案收入計劃。同時如果銷售定單應用了開票計劃（Billing Plan）功能，開票的日期也將納入計劃中。收入計劃同時也可以顯示銷售折扣，折讓和其他銷售扣減專案。當然，除了整合我們也可以直接手工做專案收入計劃，或者直接將開票計劃維護在WBS元素上。
開票計劃是分次開具發票的計劃。在開票計劃中，我們詳細維護每次開票的日期，開票的百分比和金額，是否凍結和相關的專案里程碑等等資訊。里程碑開票在客戶專案中被廣泛採用。系統將根據專案進度的任何變化自動調整收入計劃。當相關的專案里程碑被確認時，系統可以自動將開票計劃中的某次開票釋放。開票計劃還可以包括預收款，當然預收款隻影響專案收付款而不影響收入。當預收款釋放後，系統可以生成預收款請求，和發票一樣可以列印出來遞交給客戶。隨後收到的預收款會指向相關的請求，並將它清帳。
我們可以結合本章已介紹的內容，設計出這樣一個銷售流程：客戶詢價（Inquiry）=> 分配和定義專案結構 => 專案成本計劃 => 按成本加成法報價（Quotation）=> 銷售定單 => 專案收入計劃。
專案的實際收入將在銷售定單實際開票時由系統自動記錄到相應的專案中。比較特殊的是資源相關定價的專案（或稱為成本補償專案）。在這種專案中，客戶同意付給承約商所有實際花費的成本（勞動力，原材料等等），加上一定的協商利潤，而不是規定數額。對於這種專案系統提供了特殊的功能：自動計算專案成本，將成本按一定規則分類，各類成本按協商利潤加成後確定銷售定單的開票金額，最後開票。這個流程其實使用了和上文銷售流程同樣的工具，我們稱為銷售定單行專案的動態處理，本文不作贅述。
和收入成本一樣，現金流也是我們在專案管理中關心的問題。除了手工計劃專案的收付款，系統可以利用大部分收入和成本的計劃工具來計劃現金流，如開票計劃，發票接收計劃等等。在計算日期時系統會將客戶和供應商的付款條款等因素考慮進去。專案現金管理也使用了《資金管理》章節中科目分層的概念。
期末結帳
專案系統管理模組的期末結帳是專案財務管理的重頭戲。有些步驟和其他模組是類似的，比如流程成本分配到專案（ABC成本法），間接費用法（用成本核算單分配間接費用）等等成本流的期末結轉和專案利息的計算。我們在本書的相關章節都已做過介紹。對於專案管理來說還有些有特殊性的期末結帳活動。
成本預測和進度分析（Progress Analysis）
專案開始執行後，進度和實際成本都可能和計劃偏離。成本預測是在專案執行過程中不斷計算和調整完成專案剩餘部分預計將要發生的成本。成本預測的資料基礎是：計劃成本，實際成本，承諾，確認的預測完工日期和完工工作量。圖八顯示了計劃成本，實際成本和預測成本這三者的關係。預測成本的資料在系統中儲存在一個特殊的計劃版本中。我們可以用這個特殊版本編制層次結構報表或成本要素報表。
從圖8中，我們看到，雖然該專案的實際成本發生低於計劃。但是從預測成本來看，成本暫時低於計劃很有可能是專案進度拖後造成的。所以僅僅孤立地檢查專案的成本，資源和程式是無法有效控制專案的。我們需要更有意義的資訊來分析專案到目前為止的進展情況和健康狀態。進度分析（Progress Analysis）正是實現這一目的。ERP中的進度分析使用的是專案管理理論中的實現價值分析（Earned Value Analysis）方法。
我們首先需要計算完工比率（POC，Percent of Completion）。我們可以人為估計WBS元素，活動和活動元素的POC，或者可以由系統根據已有資料自動計算。系統總共提供了九種確定POC的方法：開始/結束規則；估計；里程碑技術；時間比例法；成本比例法；數量比例法；進展程度法；次級比例法（或相關比例法）；使用者出口（允許使用者自定義規則的程式出口）。我們需要計算兩個POC：計劃POC，指在指定時間點上預計的完工比率；實際POC，指在指定時間點上實際的完工比率。隨後，透過某種權數（通常是計劃成本），我們可以彙總整個專案結構的所有POC，計算出整個專案的POC。
接下來，我們利用POC來計算如圖九所示的一組關鍵指標：
BCWS：Budgeted cost of work scheduled， = 總計劃成本 * 計劃POC。反映的是按照計劃到今天應該產生了多少成本。
BCWP：Budgeted cost of work performed，= 總計劃成本 * 實際POC。反映的是根據到目前為止的專案進度，應該產生多少成本。或者說到目前為止乾的活值多少，不過這個值多少仍然是成本的概念，不能和收入混淆起來。
SV：Schedule variance 進度差異，= BCWS – BCWP。反映了專案進度落後計劃多少，它告訴我們我們的專案是否太慢了。
CV：Cost variance 成本差異，= 實際成本 – BCWP。反映了專案是否超支了，它告訴我們我們的專案是否太昂貴了。
透過SV和CV兩個差異的分離，我們可以解釋專案目前的進展情況以及專案的健康狀況。
結果分析（Results Analysis）
我們在《成本流和成本物件》章節中提到，結果分析是一種型別的“由內至外的過帳”。專案管理中的結果分析解決的究竟是什麼問題呢？在長期的客戶專案中，日常收入和成本的的入帳都跟相關的業務處理相聯絡，比如開票，發票校驗等等。但是這樣的收入和成本資料很多情況下是不能滿足會計的權責發生原則和配比原則的。因此根據實質重於形式的原則和各國關於長期專案收入和成本核算的相關準則，我們需要對專案在各會計期間的收入和成本數進行調整。結果分析就是根據事先設定的規則，自動計算相關會計期間實際應確認的專案收入和成本，並自動生成調整分錄的系統功能。
新近定單（Incoming Orders）
對於某些圍繞客戶專案運轉的公司，新簽定的專案和進行中的專案對於預測公司將來的盈利前景具有重要意義，這對於以長期和超長期專案為主的公司來說由為重要。新近定單（Incoming Orders）和未完成定單（Open Orders）是這方面的兩個重要指標。新近定單是考慮了定單更改，定單取消和計劃更改等歷史因素後的新簽定和進行中定單的價值。未完成定單價值是新近定單減去已確認的收入和成本後的價值。ERP可以根據專案管理系統和銷售模組的資料，自動計算出類似下表的報表：
收入 成本 利潤 利潤率%
新定單 -940 460 -480 51
定單更改 -280 50 -230 82
定單取消 20 -12 8 -40
計劃更改 0 80 80 -50
總新近定單 -1,200 578 -622 51
已開票 -600 400 -200 33
未完成定單 -600 178 -422 70
其中計劃更改是由於專案成本結構改變後引起的利潤降低。
結算
專案的結算和內部定單的結算在基本概念上是一致的。只是由於專案具有複雜的結構，因此在結算時整個結構的不同部分（各WBS元素和活動）的結算規則是一個特殊的問題。首先，是結算規則的決定。WBS元素的結算規則可以透過不同的策略決定。比如對於客戶專案往往會對開票的WBS元素先做結果分析。結果分析的資料包括了其下層WBS元素和活動/定單的成本和收入。因此只有開票的WBS元素被結算。結算規則只維護在開票的WBS元素上。這種結算規則很可能是根據開票WBS元素和相連的銷售定單決定的市場細分。其它的物件的結算規則都定為“不結算”。再比如對於成本專案，系統可以從各WBS元素的負責成本中心或申請成本中心生成結算規則。或者還可以讓下層的WBS元素繼承上層WBS元素的結算規則等等。對於網路/活動，我們可以定義一個包含若干優先次序的“結算規則決定策略”。比如活動的結算規則依次<1>從其分配的WBS元素中繼承。<2>從專案定義中繼承。<3>按預設規則自動生成。<4>手工維護等等。其次，從結算的順序上，也有多層上卷後統一結算和分別直接結算兩種。
軟體開發專案中如何使用範圍變化管理
專案管理過程不從確定專案開始，也不隨著專案計劃完成而告終。你必須要在專案管理過程中使用範圍變化管理，如果你不善用此一技巧，那麻煩將是不可避免的。
確定並計劃專案僅僅是成功的專案管理過程的第一步。在制定出計劃之後，你還必須要將計劃付諸實施。你必須要保證計劃任務在規定的時間內完成，而且不能超出原有的預算。一旦專案開始進行，客戶可能會向你提出更多的或是與原計劃不同的要求。在這個時候範圍變化管理就可以派上用場了。如果你不善用此一技巧，專案小組就只能嘗試著在專案時間和預算不變的情況下去完成比原計劃多得多並且要耗費更多成本的任務。換句話來說，就是麻煩將是不可避免的。
範圍管理從範圍界定開始
對專案範圍進行界定恐怕是確定專案的過程當中最為重要的組成部分。事實上，如果你並不能確定專案的目標任務，也不能確定專案的範圍，專案就根本不可能成功。範圍管理是專案管理過程當中最為關鍵的組成部分之一。但是，如果不能對專案的範圍作出成功的界定，想要實施範圍管理也幾乎是不可能的。
界定範圍的目的是清楚描述專案的邏輯範圍並在此問題上同有關各方達成一致。對專案範圍的陳述可以讓大家清楚的瞭解哪些工作是專案範圍之內的事情，而哪些工作不屬於該專案範疇。對專案範圍的界定越明確，對專案就越有利。下面這些資訊應該能起到一些幫助作用。
範圍內和範圍外的任務型別（業務需求、現狀評估）
範圍內和範圍外的生命週期流程（分析、設計、測試）
範圍內和範圍外的資料型別（財務、銷售、員工）
範圍內和範圍外的資料來源或資料庫（賬單、公司總帳，薪水明細）
範圍內和範圍外的部門（人力資源、製造商、供貨商）
範圍內和範圍外的主要功能（決策支援、資料輸入、管理報告）
制定可行的範圍變化流程
專案經理和專案小組的成員都必須意識到，專案範圍的變化本身並沒有錯。也就是說，在專案的進行過程中改變專案範圍並不是一件壞事。事實上，在很多情況下，這還是一件好事。首先，客戶通常都不能在專案開始之前明確所有的需求。其次，即使他們能夠做到這一點，整個的商業環境也是在不斷變化的，所以專案需求也可能會隨之而發生變化。
如果你不能夠適應變化，專案的最終價值可能會受到影響，或者可能會使專案失去價值。因此，你需要具備在專案進行的過程當中根據需要作出改變的能力。如果專案經理不能夠在專案進行過程當中積極的對變化進行管理，問題可能就會隨之而來。任何專案都應該有一個有效的變化管理流程。這個流程應該包括對變化的識別判斷，對變化的商業價值的判斷，對變化會給專案帶來的衝擊和影響的判斷，將相應的資訊提交專案投資人進行評估。專案投資人來最終決定是否將變化引入到專案當中。如果變化被引入專案，專案投資人還應該考慮變化對專案的影響程度，並且為之配備相應的額外資源，如延長時間和追加資金預算等。
範圍變化管理常見問題
在範圍變化管理的過程當中，專案小組可能會遇到很多常見的問題。
專案範圍蔓延：很多專案經理都能夠意識到大的範圍變化，但是對小的範圍變化就不那麼細心了。因此在實際工作當中就往往有這樣一種趨勢，很多專案經理沒有經過太多的思考就把新的工作增加到了專案當中。我們所說的專案蔓延就是指一個專案接受了很多小的變化的情況。當這些小的變化都聚合到一起的時候，專案小組才意識到他們承擔了太多的超額任務，已經無法按照原有的時間和預算框架來完成專案了。
得不到投資人的批准：很多時候，專案經理會面對來自終端使用者、股東或是客戶經理的一系列變化要求。由於這些人都屬於客戶範圍，所以他們的要求通常都被認為是應當被接受的。實際上這是一種錯誤認識。終端使用者通常只能提出範圍變化的要求，但卻沒有批准的權力。即使是客戶經理也沒有批准的權力。真正擁有這種權力的只有一個人，那就是這個專案的投資人（除非該資助人已經授權給了他人）。很多專案會遇到麻煩，就是因為大家都以為專案範圍的變化能夠得到批准，而事實上真正擁有決定權的投資人並不同意這樣做。
專案小組負的責任：專案小組的成員有很多的機會同客戶進行互動交流，他們所接到的範圍變化要求也就最多。因此，整個專案小組都必須理解範圍變化管理的重要性。所有小組成員都必須及時發現專案範圍的變化並將其報告給專案經理。如果他們把所有的額外工作都自己承擔，就很可能造成無法按時完成任務的結果，從而危害到整個專案。
現在開始永遠不晚
如果你發現自己負責的專案正在日益偏離原有的時間和預算框架，那麼趕緊找找原因。在很多情況下，你會發現問題僅僅在於你的專案小組承擔了比原計劃要多的任務。界定範圍變化管理過程的最佳時機就是在專案開始之前（作為專案管理流程的一個組成部分）。但是，如果沒有一個好的專案管理流程，也沒有關係，現在開始永遠都不會晚。
其實，在發現了問題之後再補救也有好的一面。因為問題已經出現了，專案小組和客戶就已經明白了沒有對範圍進行控制會對專案產生的不利影響。那麼他們就能夠更好的理解範圍變化管理的目的和意義，能夠在今後的專案進行當中給予更多更好的配合。
隨著我國IT行業的日益發展和不斷進步，各個IT企業已經開始陸續引進並開始實施了“專案經理制”的管理模式，即：按照其所負責行業或業務系統的不同，成立多個事業部（如：電信事業部、金融事業部、稅務事業部……），各個事業部只負責其所屬行業內的專案和工程。每個事業部內部按照不同的專案成立專案組，並且會確定相應的專案經理，以對其所負責的整個專案的全過程負責。
“專案經理制”的引入，本應該促進企業專案實施和管理的標準化，以及提高企業的生產效率和專案實施質量。但是，就其目前的現狀而言卻並不樂觀，多種不利因素限制和制約了專案管理的良性發展。
現在，就我在進行專案管理工作中，所遇到的問題，將目前專案管理的現狀和問題描述如下：
1、 專案經理與專案嚴重脫節，導致專案實施嚴重失控。當前，在進行專案組組建過程中，出於多種考慮，專案經理的頭銜很多時候是落在了企業的老總，或是各事業部的總經理的頭上（此現象尤其是在重大專案中尤為突出）。這些老總們多數時間是在忙於其他事務，而無暇或者不能全部時間關注專案的實施和進展工作，無法真正行使專案經理的權利。並且，其他的專案組成員沒有足夠的權力去管理和協調專案工作。這樣就導致了專案的失控，專案進展中遇到的問題無法被及時暴露和解決，最終致使專案失敗。
2、 專案組無法統一目標和方針，導致專案組工作效率低下。由於多數專案的實施，要涉及的多個部門的協同配合，即專案組成員會由各個不同的部門同事組成。而專案經理沒有足夠的權力協調其他部門的組員的工作，而且，由於專案組是臨時機構，這導致了專案組成員對專案組的無視，他們往往更加樂於按照部門負責人的安排工作，而不是專案經理。甚者會出現在專案實施期間，某部門突然將專案組中的人員抽調走，而導致專案停工或工期延誤等後果。
3、 專案經理的責任過大，權力過小，導致其工作畏首畏尾。很多專案一旦確認專案經理後，專案經理就要對整個專案負全部的責任，但是與其不成正比的是，專案經理的權力卻是極為有限，根本無法足以保證專案工作的正常開展。專案經理的責任和權力的失衡，嚴重的影響了專案工作的正常開展，使得專案經理在工作中無法發揮作用而又害怕因失誤而帶來的直接責任問題。由這樣的專案經理領導的團隊，註定其無法完成專案工作。
4、 授權模糊或沒有授權，致使專案經理對其工作職權概念模糊。為了達到某種目的而創立了團隊。企業可能會向專案經理"授權"。但是通常是很模糊的，即專案經理為達到既定目的可以在某種程度上採取一切必要的行動。但也可能企業沒有這樣授權。對此專案經理要麼感覺手中無權，無法開展工作；要麼就搞不清自己職權到底是什麼。不管怎樣，這樣的團隊往往是要失敗的。
5、 公司沒有按照專案進行利益分配，專案工作沒有積極性。由於公司沒有基於專案進行利潤分配的模式，即企業還在吃大鍋飯，專案組成員無法看到專案成功與否對自己帶來的直接效益，專案經理更是無法從正常的利益方面激勵專案成員的工作積極性，某種程度上還要靠專案成員發揚風格或是專案經理與專案成員的私人關係才使專案得以正常實施，這使得專案實施工作舉步為艱。
形成上述現狀的原因是多方面的，主要表現在以下幾個方面：
· 企業制度不健全
目前國內IT企業的專案管理組織形式一般都屬於弱矩陣或平衡矩陣型別的，職能部門和專案管理層還處於"磨合期", 工作效率較低下，另外，溝通複雜本身就是矩陣型組織的突出特點。看來，建立基於專案管理的現代企業制度，還有一個漫長而艱苦的過程。
· 專案經理制的在企業中沒有具體切實落實
在目前IT行業企業的編制中，專案經理部仍是可有可無的，專案經理多數情況是由職能部門人員“客串”或是兼職的。在企業中，很難找到專職的專案經理。而且，目前的專案經理大都被定義為“傳聲筒”，一般沒有真正意義上掌握人、財、物大權的專案經理。
· 專案經理自身的原因
1 專案經理缺乏專案管理方面經驗；
2 專案經理不懂專案所必須技術，是個技術外行；
3 專案經理沒有足夠的應有的權力；
4 關鍵性檔案沒有被及時的制定、頒發，甚至專案經理制定的有些檔案是錯誤的；
5 專案經理沒有全域性觀念，把注意力過多地放在自己熟悉、喜歡的部門或單位。
如果要解決上述問題，最根本的途徑是認清專案經理的地位和作用，重點是正確界定專案經理的責權利。
一 專案經理的地位和作用
專案管理的組織的特徵是嚴格意義的個人負責制，個人負責制的核心人物必然是專案經理。所以專案經理是決定一個專案成敗的關鍵人物。專案經理是專案實施的最高領導者、組織者、責任者，在專案管理中起到決定性的作用。成功的專案應該是使專案任務能夠按照既定的計劃和要求完成，以及專案成果能使本企業組織成員專案組中的主要成員、終端使用者或委託人感覺高度滿意。最終給企業創造效益。
專案經理是專案有關各方協調配合的橋樑和紐帶，處在上下各方的核心地位。專案管理說到底是人的管理與協調。負責溝通、協商、解決各種矛盾、衝突、糾紛的關鍵人物是專案經理。他對專案行使管理權，也對專案目標的實現承擔全部責任。他所扮演的角色是任何其他人不可替代的。專案經理作為企業委派在專案管理上的代表，按合同和約履約是他一切行動的最高準則，拒絕承擔合同以外的其他各方強加的干預、指令、責任是他的基本權力。專案經理是專案資訊溝通的發源地和控制者，在專案實施過程中，來自專案外的重要資訊、指令要透過專案經理來彙總、溝通、交涉，對專案內部，專案經理是各種重要指標、決策、計劃、方案、措施、制度的決策人和制定者。
二 專案經理的責、權、利
(一) 專案經理的職責
1.確保專案目標實現，保證使用者的滿意。這項基本職責是檢查和衡量專案經理管理成敗、水平高低的基本標誌。
2.制定專案階段性目標和專案總體控制計劃。專案總目標一經確定，專案經理的職責之一就是將總目標分解，劃分出主要工作內容和工作量，確定專案階段性目標的實現標誌如形象進度控制點等。
3.組織精幹的專案管理班子。這是專案經理管好專案的基本條件，也是專案成功的組織保證。
4.及時決策。 專案經理需親自決策的問題包括實施方案、人事任免獎懲、重大技術措施、裝置採購方案、資源調配、進度計劃安排、合同及設計變更等。
5.履行合同義務，監督合同執行，處理合同變更。 專案經理以合同當事人的身份，運用合同的法律約束手段，把專案各方統一到專案目標和合同條款上來。
(二) 專案經理的權力
1.指揮權 專案經理有權按專案相關合同的規定，根據專案隨時出現的人、財、物等資源變化情況進行指揮排程，對於專案工程組織設計和網路計劃，也有權在保證總目標不變的前提下進行最佳化和調整，以保證專案經理能對專案實施過程中出現的各種變化應付自如。
2.人事權 專案經理應有權對專案組的組成人員進行選擇、考核、聘任和解聘，有權根據專案需要對專案組成員進行調配、指揮，並且有權根據專案組成員在專案過程中的表現進行獎勵和懲罰。
3.財權 專案經理必須擁有專案範圍內的財務決策權，在財務制度允許的範圍內，專案經理有權安排專案費用的開支，有權對專案預算內的款項進行安排和支配，並且，在專案實施期間，專案經理應有權在工資基金範圍內決定專案組內部的計酬方式、分配方法、分配原則。對風險應變費用、趕工措施費用等都有使用支配權。
4.技術決策權 主要是審查和批准重大技術措施和技術方案，以防止決策失誤造成重大損失。必要時召集技術方案論證會或外請諮詢專家，以防止決策失誤。
5.裝置、工具、材料的採購與控制權 在企業有關規定的範圍內，專案經理應有權決定專案相關裝置、材料的採買時間及數量，對專案相關的裝置、工具、材料等有權按質量標準檢驗後決定是否用於本專案。但專案相關主要裝置的採購權不宜授予專案經理，否則可能影響公司的效益，但由採購部門採購裝置必須按時、按質、按量，否則專案經理有權拒收或採取其他措施。
（三）專案經理的利益
目前，在國內IT企業中，因專案經理的許可權較小，責任較大，而且多數企業都沒有對專案經理的工作績效進行深入評測，並且與其直接利用掛鉤，這使得專案經理經常是付出的多，得到的少，久而久之，工作積極性下降。要明確專案經理的利益，改隱性收入為顯性收入。 企業應該對專案經理按照專案進行獨立核算，改變過去那種只幹不算。按照專案實施質量和最終結果，從專案利潤中提取一定比例作為獎勵基金，由專案經理按規定分配。
專案經理的最終利益是專案經理行使權力和承擔責任的結果，也是市場經濟條件下責、權、利相互統一的具體表現。專案經理除按規定標準享受企業制定的工資和獎金外，如果其負責專案的各項指標和整個專案都達到既定的要求，應該在專案終審贏餘時按利潤比例提成予以獎勵。
如果專案經理所負責專案未按合同要求完成，可根據專案具體的情況，扣發全部專案獎金。如屬個人責任，致使專案工期拖延、成本虧損或造成重大事故的，除扣發全部專案獎金外，可處以一次性罰款並下浮工資，性質嚴重者要按有關規定追究責任。
綜上所述，專案經理是對專案管理全面負責的管理者，也是施工專案的管理中心，明確專案經理的責、權、利，並在專案管理中落到實處，是企業挖掘內部潛力;獲取最大利潤"的根本途徑；是專案能否成功及專案管理目標、成本目標能否實現的關鍵。
如今，伴隨了IT業技術的日新月異的發展與更新，其專案管理規範化程式也在加速發展。“專案經理”這個年輕的職業正在IT企業中發揮越來越重要的作用。當今企業的發展呼喚好的專案經理，但是更重要的是我們更加需要適合於專案經理發揮能量的舞臺和能夠培養更多更好的專案經理的溫床。
在技改專案的專案管理、實施過程中，不僅是專案經理，與專案相關的各方面人員都越來越注意到專案進度的重要性。那麼如何控制專案進度。以下是個人的一些建議，供參考：
1、專案負責人或專案經理一定要對整個專案的週期有一個清楚的瞭解。根據專案不同階段的的不同特點，把任務按階段劃分。對於每一階段的任務都要有明確的目標和成果；都要明確各項任務的責任部門以及責任人。這樣，責任部門以及責任人對專案階段各項任務和目標以及成果是明確的，對時間進度的要求也是明確的。專案經理所要做的就是：密切跟蹤各項任務的進展情況，時刻與專案的總體進度進行對照。及時發現問題，及時協調與解決問題以保證專案沿著正常的軌跡執行。
2、溝通和交流。作為專案經理或專案負責人，與專案相關各部門以及有關人員溝通、交流是其最基本的工作內容。而溝通與交流也是保證專案進度得到有效控制的基本要素。許多在專案中遇到的問題，對當事者來說也許是很困難的，可是透過溝通與交流，透過相關部門的幫助，往往可以很順利地得到解決。溝通與交流有助於及時發現問題並及時得到解決；有助於調動專案團隊成員的積極性；有助於加深對專案的理解和消除誤會。
3、抓重點、攻難點。每一個專案，都有其不同的特點。要有效地控制好專案的進度，找到專案的重點、難點並全過程得到有效的控制與解決是關鍵。專案經理在起始階段就要對專案難點、重點有一個預判，前期做好充分的準備，做好必要的預案。在專案實施過程中，始終抓好重點、難點的管理，周密計劃、認真實施。抓住了重點、解決了難點，專案的成功就是自然而然的結果了。
4、做好專案的總結。要善於在專案管理過程中以及專案完成後做好總結。及時的總結有利於發揚成功的經驗；有利於及時糾正工作中的不足；有利於專案團隊整體素質的提高。對於本專案來說，及時總結是糾正錯誤，控制進度的有力保證。對於後續專案來說，已完成專案的經驗教訓，對減少專案管理的出錯，提高專案管理的精度具有良好的借鑑作用。
以上幾點，希望對您能有所幫助。
1980年代末,美國安達信顧問公司(現改名為埃森哲Accenture)為了加強其核心IT業務,開始僱用新的專業策略顧問。這些顧問比安達信員工更有經驗,而且習慣於比安達信現有IT員工享受"更有刺激性的個人業績獎勵"。
沃頓管理學教授莎拉·凱普蘭(Sarah Kaplan)與麻省理工斯隆管理學院的蕾貝卡·韓德森(Rebecca Henderson)共同撰寫了一篇論文:"惰性和激勵:組織經濟學和組織理論的相結合"(Inertia and Incentives: Bridging Organizational Economics and Organizational Theory)。
安達信與柯達的教訓
論文中指出,當安達信這些新僱用的"明星員工"要求得到他們在以前公司的收入水平時,老員工就產生了抱怨。畢竟,現有的工資系統"已經透過對新僱員的大量培訓和社交活動後得到了加強"。改變這一工資系統的努力,由於"安達信公司內沒有人知道新的業務應該如何運作,或者怎樣才能成功而變得複雜"。
安達信對現有的激勵系統進行了一些變動,認為既可以滿足新員工的期望,而且不會疏遠老員工。同時,還試圖將新員工塞進現有IT員工的架構中。但這些努力都不成功,許多新員工離開了公司。安達信建立新業務的努力出師不利。
凱普蘭說,柯達在轉向數碼攝影的時候,遇到了類似的問題。數碼攝影是一個非常不同的商品,其所要求的不僅僅是"從化學到數碼的技術能力的轉變",同時還需要一整套新的商業模式。但是,高階經理們並沒有這樣看待這一問題,他們不認為數碼業務需要根本的改變,包括新的技術和經理人。相反,柯達試圖發展一種混合的商業模式("以膠片為基礎的數碼影像"和圖片光碟)。凱普蘭和韓德森在她們的報告中指出,很多人認為這一策略"是失敗的,而柯達最終建立了獨立於傳統攝影部門的數碼影像部門"。
凱普蘭說,這兩家公司的共同點是"在對新業務前景的理解和如何給予員工報酬之間存在著矛盾衝突,以致最終無法建立起能夠抓住新機會的那類組織"。
凱普蘭和韓德森的研究重點是:究竟是什麼原因導致這些矛盾得以產生和發展,並以激勵機制為切入點。
凱普蘭說,經濟學家傾向於認為如果你改變了激勵體系,企業也會隨之改變。但事實上,改變激勵體系並不是直截了當的,尤其是當企業試圖對一項新技術或市場變化做出反應的時候,這種不確定性就更大了。在這些情況下,必須考慮到"經理人對市場情況的’詮釋過程(interpretative processes)’,也就是他們的’認知框架(cognitive frames)’。激勵體系和這些經理的詮釋是緊密相連的"。
凱普蘭說,人們通常將激勵體系定義為"經理人讓人們完成工作的東西"。在很多企業中,激勵不僅僅指薪水,還包括獎金、福利、私人辦公室、獎章、上級的表揚、升級以及加入重要的專案等。"從商業媒體上我瞭解到現在的企業試圖更多地使用非薪水類的激勵方法,比如股權。但是不論企業擁有怎樣的激勵機制,都會遇到同樣的問題。比如,有些公司發現當他們為員工提供更多的股權,但減少薪水時,員工反對這一改變。在很多企業裡,員工只相信舊的激勵方式。"
凱普蘭以她自己為例。"作為一個大學教授,除非我親眼見到這個大學在過去的歷史中有很多滿足某些條件的教授得到了終身職位,否則我不會相信我會得到終身職位(tenure)。但當情況發生變化時,這類歷史紀錄就沒有了。人們不知道是否要相信這個新的激勵體系。"凱普蘭說,在這類情況下,"對市場的詮釋或認知框架將會很大地影響僱員如何理解他們應該做什麼,以及何種激勵能夠鼓勵這些行動"。
建立新契約的挑戰
凱普蘭和韓德森的論文尤其關注成功公司在試圖為新的投資建立合適的激勵體系時所面臨的限制。她們認為,首先"激勵非常有可能基於評估,而這類評估取決於如何詮釋"。
兩位寫道,所有衡量標準"都可能非常模糊。這些標準的意義只能隨著時間慢慢呈現出來"。
她們還提出在一個成功企業中,激勵體系有可能"在一系列關係型契約(relational contracts)中得到實現"。關係型契約是指那些不能以書面形式記錄,但企業由於擔心不履行這一契約可能的後果而不得不執行的約定。這類契約的建立需要數年時間,並且是基於對契約條款的共識。而員工也能夠信任企業將會遵守這些條款。
除了進行外部調查,凱普蘭和韓德森還採訪了企業員工,以瞭解他們的企業為什麼在面對變化時這麼困難。兩位指出:"人們給了我們很多原因,比如公司選錯了目標消費者,或投資了錯誤的技術。這些原因可能是正確的。"
凱普蘭和韓德森還研究了企業為何無法應對"結構"創新。由於企業繼續依賴"從以往的產品中積累的經驗,例如思維模式和解決問題的策略而造成了應對創新的困難。結構創新不僅要求新的認知框架,並要求新的激勵"。
有些人認為激勵方式變化之所以困難是由於公平的問題。兩位作者引用其他研究結果,認為企業內部規範讓企業很難為一個新部門的員工提供比現有員工高出很多的激勵。然而凱普蘭和韓德森認為僅用公平問題不能解釋"很多新分支的激勵政策與其母公司這麼相似。比如,通常銷售部門的員工比其他員工的酬勞要高很多。這一差別引起的矛盾相對很小,因為其他員工認同了銷售工作是不同的,是困難的而且不愉快,或者只是認為銷售員需要不同型別的酬勞來不斷鼓勵他們"。
凱普蘭和韓德森認為,很多人只是假定如果世界變了,"企業需要根據一套不同的主觀評估進行獎勵,它只需要宣佈這一變化。員工們就會知道公司實行新契約是理性的,而公司也知道員工會做出相應的表現。雙方可以平穩地進入新的平衡狀態,而改變也將沒有問題。"
但"在一個混亂的世界中的真實企業並不是這樣的。當一個大變化發生時,在企業和員工之間需要建立一個新的契約(激勵系統)"。
建立契約面臨三個挑戰。
首先,要明確員工在沒有獲得酬勞時可能會怎麼做,或者說其真正的利益所在。這是一個複雜的過程。
第二,行動和有用的結果之間的聯絡存在著巨大的不確定性。在一個現代企業中,任何一項任務,即使是不太複雜的任務,管理層對這些聯絡的理解最多也是一個部分的,不完整的模型。這一模型是根據多年的個人經驗而慢慢形成的。當面對一個完全新的商業機會時,這種模型可能根本不存在。
第三,隨著情況變得越來越不穩定,越來越模糊,員工所關心的事也越來越不清楚。而公司也越來越不可能輕易獲得這一資訊。員工可能對所得到的獎金做出意想不到的反應……這一問題經常由於企業對如何獎勵按照新要求工作的員工沒有經驗而加重。這使得經理及其員工沒有了一個熟悉而有效的關係型契約。
企業考慮透過在新部門實行新的員工激勵系統來實現這一轉變。但兩位作者指出,在這種情況下,雖然經理認識到徹底改變過的激勵系統可能會鼓勵員工追求高風險的技術改革,但他們通常會產生遲疑,而不執行新的激勵系統。"因為如果這樣做的話,他們將會違反與老員工之間現有的關係型契約。"這將對激勵政策造成"選擇性干預(selective intervention)"。這樣的政策必將失敗,因為整個系統不能和新的環境相匹配。
傳統的升職方式
兩位作者說,所有這些原因讓在新環境中運作的新企業很難建立激勵機制,但對於成功的公司而言,就更加困難了。現有的激勵機制在很多年的實施過程中,逐步"植根於員工和僱主的認知框架以及企業的日常運作和流程中。
……我們覺得評估和獎勵員工可能要比學習如何工作本身還要困難,因為努力和成果之間總存在著一定的距離"。
事實上,一個成功企業的高階經理很可能借助其從多年工作經驗中獲得的直覺,就可以有效地評估其下屬的工作。"很多高階經理本身可能就是憑藉這種能力,以及他們對工作的瞭解得到升職。兩種能力同樣重要,因為經理的基本工作就是評估和獎勵他們的下屬。"但這可能對預測或發現市場變化造成影響。"經理以某種特定方式看待某件事的部分原因是他們的過去以及現在的激勵機制。如果隨著時間的推移,經中的認知框架,那麼他們就有可能拒絕接受那些可能會引起環境徹底改變的資訊,並將其作為不重要的資訊處理。"
由於企業家面對著一個全新的市場和全新的技術,"或者說當他們需要評估一名管理著高風險、快速增長部門的經理時,原來對於什麼才算是有效投入的直覺可能就不正確了"。
另一個問題就是員工和僱主可能對新的激勵政策產生不同的理解。"不同的理解可能使員工感到受了欺騙,而經理則相信他們完全在按照政策工作。"同時,經理可能會覺得因為新技術和新工作內容太複雜,還不如對新部門實施現有的激勵政策比較簡單。
所以,"使用主觀衡量標準和預設契約鼓勵企業做一件事,可能會使企業很難完成另一件事(比如進行根本的改革)。正如有些學者提出的,如果工作程式是企業內部的停戰協定,而如果這些停戰協定包含了某些業務認知框架以及一套鼓勵以該認知框架為基礎進行工作的激勵機制,那麼任何對框架或對激勵機制的改變都將會導致停戰協定的崩潰"。而這將導致錯誤的努力方向以及最終的失敗。
建立新模型
根據以上的內容可以得出結論,"首先,無論是預設的認知、準則或程式都不僅僅是個人學習如何工作的認知過程的產物,還是每個人學習何種行為可能得到獎勵的、與激勵機制有關過程,都是公司的工作程式。這就是激勵政策的作用——’我這樣做事,因為這樣對我最有利。’這一作用不能明確地與認知分離:’我這樣做因為我相信應該這樣做。’事實上,認知和激勵兩者在一個複雜的、互相作用的過程中同時形成。"
第二,當一個企業開始採用一種全新的技術時,"所面臨的困難是認知的也是與激勵有關的。認知困難是’我們知道這樣做不行,而且我們懷疑,即使這樣做了也賺不到錢’。與激勵相關的困難是’就算我學了你也不會付我錢’。這是因為認知框架和激勵機制在一個企業中的關係非常緊密。想改變其中一個,必定會讓另一個發生變化"。
"在處理變化時,要重視認知框架和激勵機制在企業中的植根深度。植根越淺,就越有可能出現不同的觀點(能夠更好地接受根本的技術變化的觀點)。然而,一個植根很深的體系也有自己的優勢,可以使決策變得方便,並能夠有效執行策略。"
這個模型將"激勵機制和認知框架視為一個企業中兩個互相聯絡的部分。當認知框架和激勵機制深植企業內部時,舊模式會保留下來。然而……當經理改變了兩者之間的關係的時候,改變是可能的"。
在範圍變化管理的過程當中，專案小組可能會遇到很多常見的問題。
專案範圍蔓延：很多專案經理都能夠意識到大的範圍變化，但是對小的範圍變化就不那麼細心了。因此在實際工作當中就往往有這樣一種趨勢，很多專案經理沒有經過太多的思考就把新的工作增加到了專案當中。我們所說的專案蔓延就是指一個專案接受了很多小的變化的情況。當這些小的變化都聚合到一起的時候，專案小組才意識到他們承擔了太多的超額任務，已經無法按照原有的時間和預算框架來完成專案了。
得不到投資人的批准：很多時候，專案經理會面對來自終端使用者、股東或是客戶經理的一系列變化要求。由於這些人都屬於客戶範圍，所以他們的要求通常都被認為是應當被接受的。實際上這是一種錯誤認識。終端使用者通常只能提出範圍變化的要求，但卻沒有批准的權力。即使是客戶經理也沒有批准的權力。真正擁有這種權力的只有一個人，那就是這個專案的投資人（除非該資助人已經授權給了他人）。很多專案會遇到麻煩，就是因為大家都以為專案範圍的變化能夠得到批准，而事實上真正擁有決定權的投資人並不同意這樣做。
專案小組負的責任：專案小組的成員有很多的機會同客戶進行互動交流，他們所接到的範圍變化要求也就最多。因此，整個專案小組都必須理解範圍變化管理的重要性。所有小組成員都必須及時發現專案範圍的變化並將其報告給專案經理。如果他們把所有的額外工作都自己承擔，就很可能造成無法按時完成任務的結果，從而危害到整個專案。
現在開始永遠不晚
如果你發現自己負責的專案正在日益偏離原有的時間和預算框架，那麼趕緊找找原因。在很多情況下，你會發現問題僅僅在於你的專案小組承擔了比原計劃要多的任務。界定範圍變化管理過程的最佳時機就是在專案開始之前（作為專案管理流程的一個組成部分）。但是，如果沒有一個好的專案管理流程，也沒有關係，現在開始永遠都不會晚。
其實，在發現了問題之後再補救也有好的一面。因為問題已經出現了，專案小組和客戶就已經明白了沒有對範圍進行控制會對專案產生的不利影響。那麼他們就能夠更好的理解範圍變化管理的目的和意義，能夠在今後的專案進行當中給予更多更好的配合。
隨著我國IT行業的日益發展和不斷進步，各個IT企業已經開始陸續引進並開始實施了“專案經理制”的管理模式，即：按照其所負責行業或業務系統的不同，成立多個事業部（如：電信事業部、金融事業部、稅務事業部……），各個事業部只負責其所屬行業內的專案和工程。每個事業部內部按照不同的專案成立專案組，並且會確定相應的專案經理，以對其所負責的整個專案的全過程負責。
“專案經理制”的引入，本應該促進企業專案實施和管理的標準化，以及提高企業的生產效率和專案實施質量。但是，就其目前的現狀而言卻並不樂觀，多種不利因素限制和制約了專案管理的良性發展。
現在，就我在進行專案管理工作中，所遇到的問題，將目前專案管理的現狀和問題描述如下：
1、 專案經理與專案嚴重脫節，導致專案實施嚴重失控。當前，在進行專案組組建過程中，出於多種考慮，專案經理的頭銜很多時候是落在了企業的老總，或是各事業部的總經理的頭上（此現象尤其是在重大專案中尤為突出）。這些老總們多數時間是在忙於其他事務，而無暇或者不能全部時間關注專案的實施和進展工作，無法真正行使專案經理的權利。並且，其他的專案組成員沒有足夠的權力去管理和協調專案工作。這樣就導致了專案的失控，專案進展中遇到的問題無法被及時暴露和解決，最終致使專案失敗。
2、 專案組無法統一目標和方針，導致專案組工作效率低下。由於多數專案的實施，要涉及的多個部門的協同配合，即專案組成員會由各個不同的部門同事組成。而專案經理沒有足夠的權力協調其他部門的組員的工作，而且，由於專案組是臨時機構，這導致了專案組成員對專案組的無視，他們往往更加樂於按照部門負責人的安排工作，而不是專案經理。甚者會出現在專案實施期間，某部門突然將專案組中的人員抽調走，而導致專案停工或工期延誤等後果。
3、 專案經理的責任過大，權力過小，導致其工作畏首畏尾。很多專案一旦確認專案經理後，專案經理就要對整個專案負全部的責任，但是與其不成正比的是，專案經理的權力卻是極為有限，根本無法足以保證專案工作的正常開展。專案經理的責任和權力的失衡，嚴重的影響了專案工作的正常開展，使得專案經理在工作中無法發揮作用而又害怕因失誤而帶來的直接責任問題。由這樣的專案經理領導的團隊，註定其無法完成專案工作。
4、 授權模糊或沒有授權，致使專案經理對其工作職權概念模糊。為了達到某種目的而創立了團隊。企業可能會向專案經理"授權"。但是通常是很模糊的，即專案經理為達到既定目的可以在某種程度上採取一切必要的行動。但也可能企業沒有這樣授權。對此專案經理要麼感覺手中無權，無法開展工作；要麼就搞不清自己職權到底是什麼。不管怎樣，這樣的團隊往往是要失敗的。
5、 公司沒有按照專案進行利益分配，專案工作沒有積極性。由於公司沒有基於專案進行利潤分配的模式，即企業還在吃大鍋飯，專案組成員無法看到專案成功與否對自己帶來的直接效益，專案經理更是無法從正常的利益方面激勵專案成員的工作積極性，某種程度上還要靠專案成員發揚風格或是專案經理與專案成員的私人關係才使專案得以正常實施，這使得專案實施工作舉步為艱。
形成上述現狀的原因是多方面的，主要表現在以下幾個方面：
· 企業制度不健全
目前國內IT企業的專案管理組織形式一般都屬於弱矩陣或平衡矩陣型別的，職能部門和專案管理層還處於"磨合期", 工作效率較低下，另外，溝通複雜本身就是矩陣型組織的突出特點。看來，建立基於專案管理的現代企業制度，還有一個漫長而艱苦的過程。
· 專案經理制的在企業中沒有具體切實落實
在目前IT行業企業的編制中，專案經理部仍是可有可無的，專案經理多數情況是由職能部門人員“客串”或是兼職的。在企業中，很難找到專職的專案經理。而且，目前的專案經理大都被定義為“傳聲筒”，一般沒有真正意義上掌握人、財、物大權的專案經理。
· 專案經理自身的原因
1 專案經理缺乏專案管理方面經驗；
2 專案經理不懂專案所必須技術，是個技術外行；
3 專案經理沒有足夠的應有的權力；
4 關鍵性檔案沒有被及時的制定、頒發，甚至專案經理制定的有些檔案是錯誤的；
5 專案經理沒有全域性觀念，把注意力過多地放在自己熟悉、喜歡的部門或單位。
如果要解決上述問題，最根本的途徑是認清專案經理的地位和作用，重點是正確界定專案經理的責權利。
一 專案經理的地位和作用
專案管理的組織的特徵是嚴格意義的個人負責制，個人負責制的核心人物必然是專案經理。所以專案經理是決定一個專案成敗的關鍵人物。專案經理是專案實施的最高領導者、組織者、責任者，在專案管理中起到決定性的作用。成功的專案應該是使專案任務能夠按照既定的計劃和要求完成，以及專案成果能使本企業組織成員專案組中的主要成員、終端使用者或委託人感覺高度滿意。最終給企業創造效益。
專案經理是專案有關各方協調配合的橋樑和紐帶，處在上下各方的核心地位。專案管理說到底是人的管理與協調。負責溝通、協商、解決各種矛盾、衝突、糾紛的關鍵人物是專案經理。他對專案行使管理權，也對專案目標的實現承擔全部責任。他所扮演的角色是任何其他人不可替代的。專案經理作為企業委派在專案管理上的代表，按合同和約履約是他一切行動的最高準則，拒絕承擔合同以外的其他各方強加的干預、指令、責任是他的基本權力。專案經理是專案資訊溝通的發源地和控制者，在專案實施過程中，來自專案外的重要資訊、指令要透過專案經理來彙總、溝通、交涉，對專案內部，專案經理是各種重要指標、決策、計劃、方案、措施、制度的決策人和制定者。
二 專案經理的責、權、利
(一) 專案經理的職責
1.確保專案目標實現，保證使用者的滿意。這項基本職責是檢查和衡量專案經理管理成敗、水平高低的基本標誌。
2.制定專案階段性目標和專案總體控制計劃。專案總目標一經確定，專案經理的職責之一就是將總目標分解，劃分出主要工作內容和工作量，確定專案階段性目標的實現標誌如形象進度控制點等。
3.組織精幹的專案管理班子。這是專案經理管好專案的基本條件，也是專案成功的組織保證。
4.及時決策。 專案經理需親自決策的問題包括實施方案、人事任免獎懲、重大技術措施、裝置採購方案、資源調配、進度計劃安排、合同及設計變更等。
5.履行合同義務，監督合同執行，處理合同變更。 專案經理以合同當事人的身份，運用合同的法律約束手段，把專案各方統一到專案目標和合同條款上來。
(二) 專案經理的權力
1.指揮權 專案經理有權按專案相關合同的規定，根據專案隨時出現的人、財、物等資源變化情況進行指揮排程，對於專案工程組織設計和網路計劃，也有權在保證總目標不變的前提下進行最佳化和調整，以保證專案經理能對專案實施過程中出現的各種變化應付自如。
2.人事權 專案經理應有權對專案組的組成人員進行選擇、考核、聘任和解聘，有權根據專案需要對專案組成員進行調配、指揮，並且有權根據專案組成員在專案過程中的表現進行獎勵和懲罰。
3.財權 專案經理必須擁有專案範圍內的財務決策權，在財務制度允許的範圍內，專案經理有權安排專案費用的開支，有權對專案預算內的款項進行安排和支配，並且，在專案實施期間，專案經理應有權在工資基金範圍內決定專案組內部的計酬方式、分配方法、分配原則。對風險應變費用、趕工措施費用等都有使用支配權。
4.技術決策權 主要是審查和批准重大技術措施和技術方案，以防止決策失誤造成重大損失。必要時召集技術方案論證會或外請諮詢專家，以防止決策失誤。
5.裝置、工具、材料的採購與控制權 在企業有關規定的範圍內，專案經理應有權決定專案相關裝置、材料的採買時間及數量，對專案相關的裝置、工具、材料等有權按質量標準檢驗後決定是否用於本專案。但專案相關主要裝置的採購權不宜授予專案經理，否則可能影響公司的效益，但由採購部門採購裝置必須按時、按質、按量，否則專案經理有權拒收或採取其他措施。
（三）專案經理的利益
目前，在國內IT企業中，因專案經理的許可權較小，責任較大，而且多數企業都沒有對專案經理的工作績效進行深入評測，並且與其直接利用掛鉤，這使得專案經理經常是付出的多，得到的少，久而久之，工作積極性下降。要明確專案經理的利益，改隱性收入為顯性收入。 企業應該對專案經理按照專案進行獨立核算，改變過去那種只幹不算。按照專案實施質量和最終結果，從專案利潤中提取一定比例作為獎勵基金，由專案經理按規定分配。
專案經理的最終利益是專案經理行使權力和承擔責任的結果，也是市場經濟條件下責、權、利相互統一的具體表現。專案經理除按規定標準享受企業制定的工資和獎金外，如果其負責專案的各項指標和整個專案都達到既定的要求，應該在專案終審贏餘時按利潤比例提成予以獎勵。
如果專案經理所負責專案未按合同要求完成，可根據專案具體的情況，扣發全部專案獎金。如屬個人責任，致使專案工期拖延、成本虧損或造成重大事故的，除扣發全部專案獎金外，可處以一次性罰款並下浮工資，性質嚴重者要按有關規定追究責任。
綜上所述，專案經理是對專案管理全面負責的管理者，也是施工專案的管理中心，明確專案經理的責、權、利，並在專案管理中落到實處，是企業挖掘內部潛力;獲取最大利潤"的根本途徑；是專案能否成功及專案管理目標、成本目標能否實現的關鍵。
如今，伴隨了IT業技術的日新月異的發展與更新，其專案管理規範化程式也在加速發展。“專案經理”這個年輕的職業正在IT企業中發揮越來越重要的作用。當今企業的發展呼喚好的專案經理，但是更重要的是我們更加需要適合於專案經理發揮能量的舞臺和能夠培養更多更好的專案經理的溫床。
在技改專案的專案管理、實施過程中，不僅是專案經理，與專案相關的各方面人員都越來越注意到專案進度的重要性。那麼如何控制專案進度。以下是個人的一些建議，供參考：
1、專案負責人或專案經理一定要對整個專案的週期有一個清楚的瞭解。根據專案不同階段的的不同特點，把任務按階段劃分。對於每一階段的任務都要有明確的目標和成果；都要明確各項任務的責任部門以及責任人。這樣，責任部門以及責任人對專案階段各項任務和目標以及成果是明確的，對時間進度的要求也是明確的。專案經理所要做的就是：密切跟蹤各項任務的進展情況，時刻與專案的總體進度進行對照。及時發現問題，及時協調與解決問題以保證專案沿著正常的軌跡執行。
2、溝通和交流。作為專案經理或專案負責人，與專案相關各部門以及有關人員溝通、交流是其最基本的工作內容。而溝通與交流也是保證專案進度得到有效控制的基本要素。許多在專案中遇到的問題，對當事者來說也許是很困難的，可是透過溝通與交流，透過相關部門的幫助，往往可以很順利地得到解決。溝通與交流有助於及時發現問題並及時得到解決；有助於調動專案團隊成員的積極性；有助於加深對專案的理解和消除誤會。
3、抓重點、攻難點。每一個專案，都有其不同的特點。要有效地控制好專案的進度，找到專案的重點、難點並全過程得到有效的控制與解決是關鍵。專案經理在起始階段就要對專案難點、重點有一個預判，前期做好充分的準備，做好必要的預案。在專案實施過程中，始終抓好重點、難點的管理，周密計劃、認真實施。抓住了重點、解決了難點，專案的成功就是自然而然的結果了。
4、做好專案的總結。要善於在專案管理過程中以及專案完成後做好總結。及時的總結有利於發揚成功的經驗；有利於及時糾正工作中的不足；有利於專案團隊整體素質的提高。對於本專案來說，及時總結是糾正錯誤，控制進度的有力保證。對於後續專案來說，已完成專案的經驗教訓，對減少專案管理的出錯，提高專案管理的精度具有良好的借鑑作用。
以上幾點，希望對您能有所幫助。
1980年代末,美國安達信顧問公司(現改名為埃森哲Accenture)為了加強其核心IT業務,開始僱用新的專業策略顧問。這些顧問比安達信員工更有經驗,而且習慣於比安達信現有IT員工享受"更有刺激性的個人業績獎勵"。
沃頓管理學教授莎拉·凱普蘭(Sarah Kaplan)與麻省理工斯隆管理學院的蕾貝卡·韓德森(Rebecca Henderson)共同撰寫了一篇論文:"惰性和激勵:組織經濟學和組織理論的相結合"(Inertia and Incentives: Bridging Organizational Economics and Organizational Theory)。
安達信與柯達的教訓
論文中指出,當安達信這些新僱用的"明星員工"要求得到他們在以前公司的收入水平時,老員工就產生了抱怨。畢竟,現有的工資系統"已經透過對新僱員的大量培訓和社交活動後得到了加強"。改變這一工資系統的努力,由於"安達信公司內沒有人知道新的業務應該如何運作,或者怎樣才能成功而變得複雜"。
安達信對現有的激勵系統進行了一些變動,認為既可以滿足新員工的期望,而且不會疏遠老員工。同時,還試圖將新員工塞進現有IT員工的架構中。但這些努力都不成功,許多新員工離開了公司。安達信建立新業務的努力出師不利。
凱普蘭說,柯達在轉向數碼攝影的時候,遇到了類似的問題。數碼攝影是一個非常不同的商品,其所要求的不僅僅是"從化學到數碼的技術能力的轉變",同時還需要一整套新的商業模式。但是,高階經理們並沒有這樣看待這一問題,他們不認為數碼業務需要根本的改變,包括新的技術和經理人。相反,柯達試圖發展一種混合的商業模式("以膠片為基礎的數碼影像"和圖片光碟)。凱普蘭和韓德森在她們的報告中指出,很多人認為這一策略"是失敗的,而柯達最終建立了獨立於傳統攝影部門的數碼影像部門"。
凱普蘭說,這兩家公司的共同點是"在對新業務前景的理解和如何給予員工報酬之間存在著矛盾衝突,以致最終無法建立起能夠抓住新機會的那類組織"。
凱普蘭和韓德森的研究重點是:究竟是什麼原因導致這些矛盾得以產生和發展,並以激勵機制為切入點。
凱普蘭說,經濟學家傾向於認為如果你改變了激勵體系,企業也會隨之改變。但事實上,改變激勵體系並不是直截了當的,尤其是當企業試圖對一項新技術或市場變化做出反應的時候,這種不確定性就更大了。在這些情況下,必須考慮到"經理人對市場情況的’詮釋過程(interpretative processes)’,也就是他們的’認知框架(cognitive frames)’。激勵體系和這些經理的詮釋是緊密相連的"。
凱普蘭說,人們通常將激勵體系定義為"經理人讓人們完成工作的東西"。在很多企業中,激勵不僅僅指薪水,還包括獎金、福利、私人辦公室、獎章、上級的表揚、升級以及加入重要的專案等。"從商業媒體上我瞭解到現在的企業試圖更多地使用非薪水類的激勵方法,比如股權。但是不論企業擁有怎樣的激勵機制,都會遇到同樣的問題。比如,有些公司發現當他們為員工提供更多的股權,但減少薪水時,員工反對這一改變。在很多企業裡,員工只相信舊的激勵方式。"
凱普蘭以她自己為例。"作為一個大學教授,除非我親眼見到這個大學在過去的歷史中有很多滿足某些條件的教授得到了終身職位,否則我不會相信我會得到終身職位(tenure)。但當情況發生變化時,這類歷史紀錄就沒有了。人們不知道是否要相信這個新的激勵體系。"凱普蘭說,在這類情況下,"對市場的詮釋或認知框架將會很大地影響僱員如何理解他們應該做什麼,以及何種激勵能夠鼓勵這些行動"。
建立新契約的挑戰
凱普蘭和韓德森的論文尤其關注成功公司在試圖為新的投資建立合適的激勵體系時所面臨的限制。她們認為,首先"激勵非常有可能基於評估,而這類評估取決於如何詮釋"。
兩位寫道,所有衡量標準"都可能非常模糊。這些標準的意義只能隨著時間慢慢呈現出來"。
她們還提出在一個成功企業中,激勵體系有可能"在一系列關係型契約(relational contracts)中得到實現"。關係型契約是指那些不能以書面形式記錄,但企業由於擔心不履行這一契約可能的後果而不得不執行的約定。這類契約的建立需要數年時間,並且是基於對契約條款的共識。而員工也能夠信任企業將會遵守這些條款。
除了進行外部調查,凱普蘭和韓德森還採訪了企業員工,以瞭解他們的企業為什麼在面對變化時這麼困難。兩位指出:"人們給了我們很多原因,比如公司選錯了目標消費者,或投資了錯誤的技術。這些原因可能是正確的。"
凱普蘭和韓德森還研究了企業為何無法應對"結構"創新。由於企業繼續依賴"從以往的產品中積累的經驗,例如思維模式和解決問題的策略而造成了應對創新的困難。結構創新不僅要求新的認知框架,並要求新的激勵"。
有些人認為激勵方式變化之所以困難是由於公平的問題。兩位作者引用其他研究結果,認為企業內部規範讓企業很難為一個新部門的員工提供比現有員工高出很多的激勵。然而凱普蘭和韓德森認為僅用公平問題不能解釋"很多新分支的激勵政策與其母公司這麼相似。比如,通常銷售部門的員工比其他員工的酬勞要高很多。這一差別引起的矛盾相對很小,因為其他員工認同了銷售工作是不同的,是困難的而且不愉快,或者只是認為銷售員需要不同型別的酬勞來不斷鼓勵他們"。
凱普蘭和韓德森認為,很多人只是假定如果世界變了,"企業需要根據一套不同的主觀評估進行獎勵,它只需要宣佈這一變化。員工們就會知道公司實行新契約是理性的,而公司也知道員工會做出相應的表現。雙方可以平穩地進入新的平衡狀態,而改變也將沒有問題。"
但"在一個混亂的世界中的真實企業並不是這樣的。當一個大變化發生時,在企業和員工之間需要建立一個新的契約(激勵系統)"。
建立契約面臨三個挑戰。
首先,要明確員工在沒有獲得酬勞時可能會怎麼做,或者說其真正的利益所在。這是一個複雜的過程。
第二,行動和有用的結果之間的聯絡存在著巨大的不確定性。在一個現代企業中,任何一項任務,即使是不太複雜的任務,管理層對這些聯絡的理解最多也是一個部分的,不完整的模型。這一模型是根據多年的個人經驗而慢慢形成的。當面對一個完全新的商業機會時,這種模型可能根本不存在。
第三,隨著情況變得越來越不穩定,越來越模糊,員工所關心的事也越來越不清楚。而公司也越來越不可能輕易獲得這一資訊。員工可能對所得到的獎金做出意想不到的反應……這一問題經常由於企業對如何獎勵按照新要求工作的員工沒有經驗而加重。這使得經理及其員工沒有了一個熟悉而有效的關係型契約。
企業考慮透過在新部門實行新的員工激勵系統來實現這一轉變。但兩位作者指出,在這種情況下,雖然經理認識到徹底改變過的激勵系統可能會鼓勵員工追求高風險的技術改革,但他們通常會產生遲疑,而不執行新的激勵系統。"因為如果這樣做的話,他們將會違反與老員工之間現有的關係型契約。"這將對激勵政策造成"選擇性干預(selective intervention)"。這樣的政策必將失敗,因為整個系統不能和新的環境相匹配。
傳統的升職方式
兩位作者說,所有這些原因讓在新環境中運作的新企業很難建立激勵機制,但對於成功的公司而言,就更加困難了。現有的激勵機制在很多年的實施過程中,逐步"植根於員工和僱主的認知框架以及企業的日常運作和流程中。
……我們覺得評估和獎勵員工可能要比學習如何工作本身還要困難,因為努力和成果之間總存在著一定的距離"。
事實上,一個成功企業的高階經理很可能借助其從多年工作經驗中獲得的直覺,就可以有效地評估其下屬的工作。"很多高階經理本身可能就是憑藉這種能力,以及他們對工作的瞭解得到升職。兩種能力同樣重要,因為經理的基本工作就是評估和獎勵他們的下屬。"但這可能對預測或發現市場變化造成影響。"經理以某種特定方式看待某件事的部分原因是他們的過去以及現在的激勵機制。如果隨著時間的推移,經中的認知框架,那麼他們就有可能拒絕接受那些可能會引起環境徹底改變的資訊,並將其作為不重要的資訊處理。"
由於企業家面對著一個全新的市場和全新的技術,"或者說當他們需要評估一名管理著高風險、快速增長部門的經理時,原來對於什麼才算是有效投入的直覺可能就不正確了"。
另一個問題就是員工和僱主可能對新的激勵政策產生不同的理解。"不同的理解可能使員工感到受了欺騙,而經理則相信他們完全在按照政策工作。"同時,經理可能會覺得因為新技術和新工作內容太複雜,還不如對新部門實施現有的激勵政策比較簡單。
所以,"使用主觀衡量標準和預設契約鼓勵企業做一件事,可能會使企業很難完成另一件事(比如進行根本的改革)。正如有些學者提出的,如果工作程式是企業內部的停戰協定,而如果這些停戰協定包含了某些業務認知框架以及一套鼓勵以該認知框架為基礎進行工作的激勵機制,那麼任何對框架或對激勵機制的改變都將會導致停戰協定的崩潰"。而這將導致錯誤的努力方向以及最終的失敗。
建立新模型
根據以上的內容可以得出結論,"首先,無論是預設的認知、準則或程式都不僅僅是個人學習如何工作的認知過程的產物,還是每個人學習何種行為可能得到獎勵的、與激勵機制有關過程,都是公司的工作程式。這就是激勵政策的作用——’我這樣做事,因為這樣對我最有利。’這一作用不能明確地與認知分離:’我這樣做因為我相信應該這樣做。’事實上,認知和激勵兩者在一個複雜的、互相作用的過程中同時形成。"
第二,當一個企業開始採用一種全新的技術時,"所面臨的困難是認知的也是與激勵有關的。認知困難是’我們知道這樣做不行,而且我們懷疑,即使這樣做了也賺不到錢’。與激勵相關的困難是’就算我學了你也不會付我錢’。這是因為認知框架和激勵機制在一個企業中的關係非常緊密。想改變其中一個,必定會讓另一個發生變化"。
"在處理變化時,要重視認知框架和激勵機制在企業中的植根深度。植根越淺,就越有可能出現不同的觀點(能夠更好地接受根本的技術變化的觀點)。然而,一個植根很深的體系也有自己的優勢,可以使決策變得方便,並能夠有效執行策略。"
這個模型將"激勵機制和認知框架視為一個企業中兩個互相聯絡的部分。當認知框架和激勵機制深植企業內部時,舊模式會保留下來。然而……當經理改變了兩者之間的關係的時候,改變是可能的"。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7199667/viewspace-1010688/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 什麼是專案合同管理？
- 什麼是敏捷專案管理?敏捷專案管理
- 什麼是專案管理 (轉)專案管理
- 什麼是專案管理，如何做好專案管理？專案管理
- 什麼是專案管理系統？專案管理
- 什麼是專案溝通管理?
- 專案經理之什麼是專案管理專案管理
- 什麼是專案成本管理？如何做好專案成本管理？
- 什麼是矩陣式專案管理？矩陣專案管理
- 什麼叫PMP?專案管理的本質是什麼?專案管理
- 什麼是企業專案管理系統專案管理
- 什麼是基礎設施專案管理？專案管理
- 專案管理中的衝突是什麼？專案管理
- 究竟什麼是專案管理？它的主要內容是什麼呢？專案管理
- 什麼是專案風險管理？要如何執行風險管理？
- 什麼是專案管理軟體，有哪些作用？專案管理
- 專案管理軟體中什麼是依賴管理，具體有什麼作用？專案管理
- Java專案是什麼?Java
- 什麼是專案（轉）
- 專案管理中的資源日曆是什麼？有什麼作用專案管理
- 專案干係人是什麼？如何有效管理專案干係人？
- 軟體專案管理實踐：專案成功的關鍵是什麼？專案管理
- 專案進度管理的基本步驟是什麼
- 在專案管理中，什麼是可實現的？專案管理
- 教你讀懂什麼是生產型專案管理專案管理
- 什麼是專案溝通管理？ 藉助系統軟體管理專案溝通
- 專案儀表板在專案管理軟體中的功能是什麼專案管理
- 什麼是專案管理？《專案計劃、進度與控制》-讀書系列專案管理
- 什麼是專案里程碑 如何藉助專案管理系統管理里程碑專案管理
- 分析什麼是專案管理中的質量控制(QC)？專案管理
- 什麼是專案管理軟體，能帶來哪些作用？專案管理
- 為什麼誠信是專案管理的關鍵部分？專案管理
- 運維專案管理用什麼專案管理軟體好？運維專案管理
- 什麼是專案管理中的任務依賴關係專案管理
- 什麼是專案管理中的里程碑？如何實踐？專案管理
- 部署管理用什麼專案管理軟體好？專案管理
- 為什麼說人員管理是成功交付專案的關鍵？
- 自下而上的專案用什麼專案管理工具好？專案管理