一、專案管理對企業組織結構的影響

企業中專案相關的組織結構，對企業中各種相關的管理活動都會帶來直接的影響。在專案管理學會（PMI）提出的專案管理知識體系（PMBOK）中，專門討論了項
目管理相關的組織結構的問題。在傳統的企業組織結構中，很多都是基於職能的劃分方式設立部門，每一職能部門對應一種專業分工，或者對應一條產品線。在基於職能的組織模式中，也存在著專案管理，但往往是侷限在職能部門內的，當專案跨越職能部門時，就會出現四種可能的情況：

1、各職能部門派人參加專案，參加者向本部門領導報告，跨部門的協調都是在各部門領導之間進行，沒有專職的專案經理。這種做法是在基於職能的組織結構中最常見的專案組織方式。這種專案的組織方式稱為職能式結構。

2、由各職能部門派協調人參加專案，參加者向本部門領導報告，跨部門的協調首先在各部門派出的協調人之間進行，沒有專職的專案經理。這種組織方式也是基於職能的組織結構中很常見的專案組織方式，其工作效率較前者略高，但和前者一樣，由於沒有人對專案負責，專案組織效果很有限。但畢竟有了透過部門領導以外的協調人之間的橫向溝通，所以也把這種組織結構稱為弱矩陣結構。

3、在上述弱矩陣結構的基礎上，指定一名專案經理，負責專案的管理，其他各部門委派的協調人不僅要向本部門報告，在專案過程中還要向專案經理報告，專案經理有一定的權力安排參加者的工作。由於專案經理的出現，使專案管理有了具體的直接責任人，在一定程度上使專案得到了保證，會大大提高專案的工作效率。這種組織結構被稱為平衡矩陣結構，如下圖所示：

4、在上面平衡矩陣的基礎上，增加與各職能部門平行的專門的專案管理辦公室，負責企業內的專案管理，專職的專案經理都歸專案管理辦公室管理，在專案中各個職能部門配合專案管理辦公室的工作。由於有了專門的組織來負責專案管理，專案管理作為企業內的一項任務長期存在，並能夠不斷地積累、發展，專案經理也不是根據專案臨時任命，而是成為常設崗位，這樣從組織上、人員上都使專案管理得到了保障。這種結構也稱為強矩陣結構，如下圖所示：

上述四種專案組織的方式都可能會出現在傳統的組織結構中，它們對專案管理的支援程度是不同的。特別是在三種矩陣式結構中，跨越部門的專案組織，與職能部門之間往往會存在著較大的衝突，主要表現在資源競爭、目標期望等方面。例如在人員安排上，職能部門內被委派參加專案的人，往往需要同時兼顧部門和專案兩方面的任務，時間得不到保證。在專案目標上，各職能部門總是希望更多的實現自己所期望的目標，而從整個專案的角度來說，可能更關注專案目標，在專案中犧牲部分職能部門的區域性利益。在我們的工作實踐中經常遇到的這類矛盾，從根本上說，應該從專案管理的組織方式上考慮解決辦法，在企業內部形成適應專案管理的組織方式、規章制度和企業文化。這是企業高層領導者需要認真考慮解決的問題。

專案化的組織結構是最適應專案管理需要的。由於專案管理的方法被越來越多的企業做採納，甚至有的企業也採用專案管理的方法來管理企業的運營，特別是在強調成本管理的企業中，工作任務、崗位職責、資源配置、績效考核等非常具體明確，則專案管理的方法更容易得到應用。

按照PMBOK的總結歸納，從一般的職能式組織結構，到弱矩陣、平衡矩陣和強矩陣的組織結構，再到專案式的組織結構，職能部門對專案的影響由大到小，專案經理從無到有，跨部門協調效率從低到高，對專案管理的力度由小到大。因此，當專案涉及部門越多，創新要求越高，涉及各職能部門利益關係越深，所需橫向協調越強的時候，那麼就適宜採用更能有效支援專案管理的組織結構。
但是，必須強調指出，對於這五種組織結構，並非越是傾向專案管理的方式就一定越好，必須根據企業在業務和產品、資源組織方式、專案組織過程等方面的特點，選擇適合的組織方式。例如，如果一個專案本身就是以某個職能部門為主，只有極少一部份輔助工作需要其他部門的配合，那麼採用弱矩陣的方式也許更有利。如果不顧企業的實際情況，一味追求專案式的組織方式，結果很可能事與願違。

二、產品管理：

企業決策職能的核心就是決定提供什麼產品和怎麼提供。廣義地說，凡是能夠為企業帶來主營業務收入的，都是產品。產品管理主要是對產品生命週期的管理，產品的生命週期一般包括四個階段：引入期、成長期、成熟期和衰退期，在不同的階段中，市場對產品的反應不同，其銷售特點不同，因而產品管理的重點也不相同。當一個創新的產品經過這四個階段後，可以透過產品的升級換代進入下一個生命週期。產品管理一定是企業貫穿各項活動的主線，只有做好產品管理，才能真正做好市場分析、新產品策略、營銷體系、風險控制、資金管理、成本核算，以及人力資源管理和績效管理等一系列工作。因此，產品管理是做好其他各項管理工作的重要基礎。

在很多場合中，產品被劃分為有形產品和無形產品，兩者之間的主要差別，就在於它們能否儲存，有形產品可以儲存，所以其生產和提供過程可以分開，而無形產品是不能儲存的，其生產和提供的過程不能分開，按照這種劃分方法，無形產品就對應我們通常所說的服務。因此人們有時用產品來表示有形產品，用服務來表示無形產品。這種劃分方法與有形資產和無形資產的劃分概念是不同的，例如軟體產品屬於無形資產，但由於它是可以儲存的，其開發和使用是可以完全分隔的，所以軟體產品也是屬於有形產品。我們在這裡，就用產品表示有形產品，用服務表示無形產品。

有的企業主要生產產品，有的企業主要提供服務，還有的企業同時提供產品和服務。產品與服務在市場中往往是需要互相配合的。例如在IT市場中，有的公司專注軟、硬體產品的研發，有的公司專門從事專業諮詢服務，有的公司作系統整合服務，還有的公司既開發產品，也從事系統整合，同時還兼顧諮詢。隨著市場專業分工越來越細，大公司內部的專業化趨勢也日漸明顯，產品部門可以把產品同時提供給本公司的服務部門和其他整合公司，諮詢部門可以參與其他公司的專案諮詢，而市場部門也可以銷售非本公司的產品。我們可以重點分析一下，市場中產品公司和整合公司這兩種角色，在一個完整的解決方案中的配合關係：

l 產品公司：專注產品的研發和升級換代。產品公司在設計產品時，面對的不是單一客戶的具體需求，而是一個市場的整體期望，產品公司的格言是：“我的產品誰都能用”。產品公司只有透過產品的反覆銷售，才能分攤產品研發的成本。因此，產品公司往往透過各種銷售渠道進行銷售，特別是與系統整合公司保持著密切的合作關係。產品公司與整合公司雖然有著良好的合作關係，但往往都不是唯一地繫結在一家整合公司上，而是希望最好無論誰的方案中都有我的產品。產品公司與整合公司形成了多對多的關係，他們之間往往都建立有戰略合作伙伴關係，但只有在具體的專案中，才有可能形成實際的業務合作。

l 整合公司：整合公司往往是以客戶為中心的，根據客戶的需求來組合產品，形成面向客戶的解決方案，並負責組織實施。整合公司依賴最終客戶的特徵是非常明顯的，需要對客戶所要解決的問題有非常清晰的認識，不論如何選擇產品和組織解決方案，其目的都是要為客戶解決實際問題。整合公司的格言是：“我什麼都能做”。因此，整合公司在選擇產品過程中，雖然有自己的偏好，但更多的還是要看客戶的需要，一般並不把自己唯一地與某個產品捆綁起來，以保持自己的靈活性。這對於整合公司來說也是必須的。

很多大企業中都有自己的IT部門，企業內部所使用的各類資訊系統，由自己的IT部門負責開發，有的甚至將自己的IT部門變成獨立的IT公司，可以將開發的軟體產品向市場銷售。這種企業內部的IT部門，需要同時向企業提供產品和服務，不僅要開發產品，還要將各類不同的產品有效地組織成解決方案，幫助企業解決問題，所以內部IT部門往往同時扮演著產品供應商和系統整合商的雙重角色。企業內部的IT部門當然主要是為企業自身服務的，企業是產品的唯一使用者，所以在很多企業中並不重視內部的產品管理，因為產品被不同客戶反覆使用的機會並不大。但是我們要看到，即使產品只為這唯一的客戶所使用，客戶的需求也是隨著外部市場發展和內部管理提高而不斷變化的，這種不斷變化的需求，也會導致產品經歷從引入到成長、從成長到成熟，最後再到衰退，然後被新的產品所取代的過程，同樣也會經歷產品的整個生命週期。有些內部的資訊系統是同時支援許多部門使用的，在一個管理部門內還有不同角色的使用者的不同要求，這些都可以被視為不同的內部客戶。另外，企業對於產品的投資回報還是要進行評價的。因此，無論是內部使用還是對外銷售，產品管理都是不能缺少的。

對於以提供服務為主的企業來說，企業提供的服務也是需要預先進行設計的，例如旅行社的導遊服務，可供遊客選擇的每條旅遊線路，其實都是一種服務產品，銀行設計的每一種金融服務，其實也是一種服務產品，企業同樣要對這些產品進行規劃、設計、銷售、評價等管理工作，只是這些產品的具體提供過程，同時也是生產過程。因此，當一項服務內容需要向客戶反覆提供時，也同樣需要做好產品管理。

在產品管理中，一般都需要使用產品的路線圖（Roadmap）來定義產品的發展歷程。典型的路線圖包含的資訊有：當前的穩定版本、正在開發中的版本、下一次釋出的版本所包括的功能，以及下一版本的釋出日期等等。透過預先定義產品路線圖，對產品的發展過程做出規劃，對新產品的開發直接提供指導和要求。

在產品管理中，一項非常重要的內容就是決定產品的生產工藝。每一種產品都需要特定的產品生產工藝過程才能生產出來。例如機械加工、建築工程、汽車裝配、軟體開發等等，每種產品的生產都必須遵循一定的專業過程，這種生產工藝是與產品密切相關的。即使是在服務產品中，也同樣需要產品生產工藝，在一些服務產品中，對服務過程和方法的設計，其實就是生產工藝，例如在企業ERP系統的實施服務中，許多諮詢公司都提供了自己的專案實施方法論，這種方法論就成為了該公司提供服務的工藝過程。產品生產工藝決定了產品的生產過程，服務的方法論決定了服務的過程，如果不遵守產品工藝特點的基本規律，就可能無法保證生產出預期的產品。
因此，作為企業中的產品管理來說，要對本企業的產品有著清晰的發展規劃，對產品特性有著深刻的剖析，對產品工藝特點有著詳細的描述，對產品質量有著明確的標準。對應著這些管理職能，在企業中經常可能存在對應的職能部門，例如負責整體產品架構規劃和產品設計的總工室，專門負責質量保證（QA）或質量控制(QC)的質量管理部門等。

三、專案管理與產品管理的關係

專案管理與產品管理是緊密相關而又不同的管理內容。在企業中，產品管理是主線，而產品生命週期中的具體階段的工作過程，則可以透過專案實現。產品管理是專案管理的目標，而專案管理是產品管理的實現手段。同時，產品生產工藝特點決定了專案的基本過程，但具體的生產過程組織，只有透過專案管理才能完成。在具體專案中，往往兩者會同時存在，特別是在提供服務的專案中，也包含了服務產品的生產過程，專案管理者必須在非常清楚兩者各自的管理內容的前提下，將兩者有機地結合起來，才能同時滿足各方面的要求。

以軟體專案為例，看看軟體工程方法與專案管理方法之間的關係。一提到軟體工程，大家自然就會想到軟體開發、專案組，想到新產品開發有關的種種相關的工作內容。現在把專案管理和軟體工程聯絡起來，就更讓人想到軟體開發中的專案管理、專案組的管理。那麼，專案管理和軟體工程之間到底應該是什麼關係呢？

我們首先來回顧一下軟體工程的有關內容。軟體工程是針對軟體這一具有其特殊性質的產品的工程化方法。它關注的是軟體產品的生命週期，包括從規劃、設計、程式設計、測試、到運營和升級維護等主要階段，而且隨著軟體產品的不斷升級維護，還會使同一軟體產品經歷多次這樣的生命週期，軟體工程在產品的一次生命週期的各個階段中，提供了一整套的工程化的方法，來指導軟體人員的開發工作。因此可以說，軟體工程是一種圍繞產品生命週期的工程化方法，是軟體產品的生產工藝。

我們再來看一下專案管理。專案管理是針對一個專案的管理方法，它關注的是專案的生命週期，包括從專案的啟動、計劃、執行，到控制和收尾共五個主要的專案過程。在不同的過程中都涉及到對時間、人員、成本、質量、風險等內容的管理，強調的是專案的績效，透過有效的專案管理來完成對專案提出的需求，這當中也包括交付軟體產品。因此，專案管理是關注專案生命週期的管理方法。

既然軟體工程是圍繞軟體產品管理的，專案管理是圍繞專案過程的，那麼自然也就容易明確它們之間的關係：

1，在軟體產品的生命週期中，由於軟體產品的性質、用途、規模等方面的差異，軟體生命週期和專案生命週期可能會重合，一個軟體的生命週期在一個專案週期結束時也隨之結束。而在更多情況下，一個軟體產品的生命週期會透過多個專案來完成，例如在軟體的可行性分析階段，可以以一個調研專案的方式來實現，在軟體的設計、程式設計階段，可以透過一個開發專案的方式來管理，在測試階段也可以單獨組織一個測試專案，在運營階段，則主要透過一般的運營管理而非專案管理的方式來進行，而在升級維護階段，仍然可以根據具體要求透過組織專案的方式來完成，或者隨著軟體產品進入下一個生命週期，啟動新的專案。產品生命週期與專案生命週期之間這種差別，在專案管理理論中是特別強調的，在專案管理中應該充分考慮其產出結果與整個產品生命週期的關係，而不應該孤立、片面地只強調專案週期的要求。

2，產品工藝的特點決定著專案的基本過程。軟體產品有其自身的科學規律，當專案管理涉及到軟體內容時，應該給予充分的重視。專案管理的最終目的還是要提交符合要求的產品，在軟體工程中，已經總結了軟體產品的許多規律性的內容，並提出了一整套的工程化方法，因此，在軟體專案的管理中，也必須遵循這種規律。在專案管理理論中，也一再強調專案管理者在具體應用領域中的專業知識，在專案的不同階段，也都強調結合產品的要求而制定不同的工作內容，獲得相應的資源，採用適當的管理方法。產品自身的規律對專案管理的具體實踐有著極其重要的影響，產品是目標，實現過程是手段。要做好軟體專案的管理，就必須首先對軟體工程具有深刻的理解。

3，在軟體工程中，也涉及到一些管理方面的問題，與專案管理有一些重疊的部分。這是很自然的，既然是一種工程化的方法，就一定要提到工程管理的問題，但是在軟體工程中提到的管理要求，只涉及到與工程方法緊密相關的、有針對性的方法，而專案管理知識體系是一個通用的知識框架，在內容上與軟體工程中的管理內容是不重複的，而是互相補充的。例如在專案管理知識體系中強調人力資源管理的有關管理方法，體現的是具體組織過程的要求，而在軟體工程中則強調系統分析人員、程式設計人員、測試人員等不同角色在不同階段的責任，體現的是產品工藝的要求。在軟體專案管理中，應充分注意這兩者的有機結合。

綜上所述，以通用的專案管理知識體系為基礎，結合軟體工程自身的科學規律，採用適合軟體產品自身特點的管理方法，是真正管理好軟體專案和軟體產品的最終出路。目前，許多軟體企業正在熱衷於CMM的評級，其實CMM的各個領域的內容，無不同時反映著軟體工程和專案管理的共同要求，也在試圖將兩者有機地結合起來，在這個特定的軟體開發領域中形成規範的過程方法。

在企業內，必須要協調好產品與專案之間的管理關係。對於同時提供產品和服務的企業，或者是對於企業內部同時提供產品和服務的部門來說，產品管理與專案管理結合，就會產生多對多的關係，即一個專案會涉及多個產品，而一個產品可能會在多個專案中被使用。這種多對多的關係，也是一種矩陣關係：

在這種結構中，專案經理必須能夠有效地將多個產品組織起來，達成專案目標，同時保證對每個產品的影響，都能與產品自身發展路線保持一致。而負責產品管理的產品經理，則必須能夠積極地支援專案的需要，並確保對產品的長期發展產生有利的影響。在處理產品管理與專案管理的兩者關係時，容易出現的錯誤主要有兩方面：一是產品的設計缺乏靈活性，不能有效地支援專案中各種個性化的要求；二是專案只關注專案自身的目標，不考慮產品長期發展的要求，結果影響了產品後續的健康發展。在專案整合管理中，也強調專案與產品的結合，在專案中也要同時考慮產品的全生命週期的成本，不能只考慮專案中的短期區域性成本，例如軟體開發專案中為了繞開一些技術難點，引入了某個開發工具，專案的成本降低了，但是在以後的軟體銷售中，由於必須配套使用該開發工具的支援模組，結果導致客戶的成本增加，大大削弱了產品的市場競爭能力。
例如在軟體開發專案中，需求分析、概要設計、詳細設計、編碼、測試等工作，都屬於產品管理的範疇，這些工作都是由於軟體工程的要求而存在的，是由相應的工程規範來約束的，軟體工程規範就是軟體產品的生產工藝，但是專案的計劃、組織、控制，專案中的範圍管理、時間管理、成本管理、質量管理等工作過程，則是屬於專案管理的範疇。
產品管理關注內容，專案管理關注過程。

四、企業內IT部門所應採取的管理模式

企業內的IT部門，為企業提供的各個IT系統就是其提供的產品。企業內的IT部門，通常需要同時提供產品和服務。企業對IT部門的具體任務都表現為專案需求，但實際上所有對IT系統的產品管理工作都落到了IT部門，因為企業中通常都沒有負責管理IT系統的產品管理部門，IT部門所承擔的專案開發任務，也都是基於以前自己的開發成果，所以IT部門就必須自己做好產品管理，控制好各個產品的發展路線，保持整體應用架構的合理性，否則就無法從根本上滿足不斷湧現的具體專案的需求，更不能有效支援企業未來的業務發展。因此，企業內的IT部門，主要還是體現為產品公司的性質，其對外提供的服務也是基於這些產品的服務。

目前許多企業的IT部門，都越來越重視專案管理，這對於加強專案過程的管理確實起到了很大的幫助，但是由此又導致了對產品管理的鬆懈，不同的專案使同一產品的發展路線產生多個分支，直接導致以後系統維護、升級的困難。

在內部組織結構方面，產品管理和專案管理兩條線需要合理安排。建議在IT部門內的組織結構中，圍繞各個系統（產品）建立產品組，形成矩陣結構中的縱向管理線路，而針對具體需求的專案，特別是那些跨產品的專案，形成了矩陣結構中的橫向的管理線路。這樣，既有縱向的產品管理的具體組織方式，又有橫向的專案管理體系，在產品管理與專案管理之間取得了一定的平衡，形成平衡矩陣的組織方式，這對於服務於企業的內部IT部門來說，可能是最佳的選擇。

在這種模式下，開發專案中對應專案需求的總體技術方案，可以被分解為各個產品的開發工作，而每個產品的新版本的開發，又必須符合產品長期發展的方向。所以，開發專案的結果直接導致了相關產品的發展，所以應偏向產品管理線，專案的組織方式採用平衡矩陣或弱矩陣結構，要在專案和產品兩個不同方向的目標之間取得平衡。對於以某一產品為主，涉及其他產品不多的開發專案，還可以採用弱矩陣的組織方式，直接由產品部門負責專案。而在系統投產過程中，主要是提供服務，基本上不對產品進行修改，重點解決專案本身的目標，根據這類專案的特點，則可以採用強矩陣的組織形式。[@more@]

IT產品管理與專案管理的關係（轉）

相關文章