CRM支援將一個專案視為整體的應用模式，即透過打造一個專案管理模組，透過將售前、售中和售後等環節引入嵌入式流程來建立一個專案的生命週期。

使用者可以透過CRM的專案和專案任務功能模組建立專案管理流程。專案執行到不同的階段，專案資料會相應的發生擴充套件和變化，比如售前階段到了報價，則需要有報價資料和報價流程，售中階段到了實施驗收，則有實施工作表和實施流程資料等。

此外，CRM客戶關係管理系統可以建立多個關聯專案的專案任務，專案經理可以將這些專案任務分配給參與專案的部門或人員。在設定條件時，當一個任務被完成，專案的進度將會在專案頁面直接呈現，這樣既方便了企業對專案進度的檢測和管控，也大大提升了專案的實施效率。

所以，專案非常的多的企業可以選擇實施CRM客戶管理系統軟體，專案管理進行資訊化處理。

能夠成為集團公司的，我真不相信沒有建立企業級的專案管理資訊系統! 但確實許多企業的專案管理資訊系統讓人不敢恭維，這是什麼原因呢？又應該如何去解決呢？

一、劃清專案管理組織層次、明確組織層次定位

許多企業的專案管理資訊系統存在“過度管理”的弊病，其中一個重要的原因是組織層次在專案管理中的定位不明確。

從企業級專案管理的角度來看，我們可以這樣劃分組織層次:

第一層: 專案決策層

企業專案決策層包括董事會、黨委會、相關高層領導崗位，以及進行重大決策的會議機制，例如黨政聯席會等。

企業決策層在專案管理的定位主要是研究和批准專案相關決策事項，例如重大的專案投資決策、重要的專案人事任命、重大專案事項的批准等。

第二層: 專案監控層

企業級的專案監控層主要是相關職能部門以及企業設定的參謀機構（委員會/領導小組）。

企業級專案監控層在專案管理的定位主要體現在，一是為企業決策層進行專案決策提供專業意見；二是實現多專案風險管控，必要時實現企業級介入。

第三層，專案管控層

企業級專案管控層可理解為向專案部派出“專案核心團隊”的管理部門，不同企業具體部分有所差異，以某工程總承包企業為例:

專案經理辦公室（派出專案經理）、工程控制部（派出控制經理、費控經理、質量經理、文控經理）、採購管理部（派出採購經理）、施工管理部（派出施工經理、HSE經理、行政經理）、設計管理部（派出設計經理/設計總工程師）、財務部（派出財務經理）。

這些部門在專案管理的定位包括但不限於:

1）向專案部派出專案管理核心成員，協助專案部組建專案團隊。

2）在矩陣式專案管理模式下，與專案部一起做好專案總體策劃，包括專案管理總體策劃和工作總體策劃。

3）協助企業級專案主管領導對在建專案進行管控，組織評審專案部提出需組織批准的重要專案檔案。

4）對在建專案履約和專案目標完成情況進行管控，重點管控專案履約偏差、重大專案風險和多專案存在的系統性管理風險。

5）對在建專案提供全過程指導和支援，當專案履約出現嚴重偏差或對實現專案目標存在風險時主動介入，協助專案部糾偏和控制風險。

6）定期或不定期組織對在建專案部的巡查以及專案履約關鍵節點的督查。

7）組織開展專案管理方面的能力建設，總結最佳實績，努力提高專案管理規範化水平。

第四層，專案管理層

從企業級專案管理的角度，專案部可視為“專案管理層”，也就是說將專案部視為企業的臨時性組織。

專案部是專案履約的主體，專案經理根據企業專案經理負責制和專案目標責任書授於的“責、權、利”代表企業實施專案。

專案部依據相關適用法律法規、簽定的專案合同、企業專案管理體系檔案、企業批准的專案管理策劃成果檔案進行專案管理。

第五層，專案執行層

從企業級專案管理角度看，工程企業的生產部門可視為“專案執行層”，例如設計院的專業設計科室、施工企業的相關專業施工工區。

對於工程總承包專案而言，專案執行層相當於“自營分包商”，對其合同工作範圍的履約負責。總承包專案部承擔的是管理責任，專案執行層所在部門承擔的是生產責任。

因此，生產部門向專案部派出設計團隊或施工團隊，生產部門應承擔起管控作用，就像專案管控部門對總包專案部的管控一樣。

二、明確企業級管理紅線，科學建立專案行政授權制度

建立企業級專案管理資訊系統，其中一個重要目的是規範專案重大事項的決策流程。

要想避免組織層次的過度管理，就必須梳理

專案有那些重要事項需要實現企業級/組織層審批（有些總包企業連專案成員出差申請都要主管專案的副總經理批准，令人難以理解）。

根據前文各組織層次在專案管理的定位，我們就可以梳理出企業級/組織級的專案重大事項，建立企業級專案管理紅線。

衡臣理解，企業級/組織級審批的專案事項（以工程總承包專案為例）主要包括但不限於:

1）重要的專案人事任命

對於工程總承包專案而言，專案部核心團隊成員任命宜納入企業幹部任命機制，以提高專案經理及其專案團隊成員的江湖地位。

2）超過一定額度的專案資金安排

專案資金計劃、專案費控計劃、專案墊資、大額分包合同付款等應進行企業級/組織級管控。

3）超過一定額度的分包合同籤置

超過一定金額的分包合同應實現企業級/組織級管控，以控制合同風險。

4）重要的合同變更及合同結算

無論是總承包合同還是分包合同，在專案實施過程中，對於重要的合同變更都必須嚴加管控。

而對於合同結算，僅僅依靠專案級的管控是不夠的，一方面專案部成員的能力和經驗還不足以滿足結算風險控制的要求，需要管控部門、職能部門提供組織支援；另一方面，專案部（專案經理）在分包結算方面權力過大，容易滋生腐敗。

5）重要的專案管理策劃成果檔案和專案技術檔案

重要的專案管理策劃成果檔案，例如《專案管理計劃》、《專案實施計劃》、《專案適用法律法規清單》、《專案適用標準規範清單》、《專案基礎技術資料表》等，是專案履約和專案實施的綱領性檔案，必須實現企業級/組織級管控。

專案重要的技術檔案也應根據企業質量管理體系實現分級組織管控，某些重要技術檔案的批准層級還應滿足相關法律法規的要求。

6）某些重要的專案工作事項

對於某些專案部無法獨立控制風險的專案工作事項，必要時必須實現組織管控。

需要注意的是，對於重要的專案檔案和專案事項，應遵循“專案部發起、管控部門評審、職能部門會籤、授權領導批准”的基本流程。

明確了需要企業級/組織級管控的專案事項後，就要根據具體事項的重要性、風險程度，結合各組織層次的定位，合理、科學安排各組織層次在專案決策和檔案審批中的角色。

此外還應明白，越高的組織層次、越高的領導崗位控制越高的專案風險，當高層次的組織或崗位透過管理措施使得某項風險程度降低時，可將具體的工作項授權下一層次組織或崗位去具體實施。這就是專案行政授權管理！

因此，從企業/組織層面管控專案的第一個原則就是“分級、分層”管控原則。

專案要根據專案規模/合同金額的大小、對企業戰略/品牌/市場的重要性進行分級；專案管理檔案也要根據檔案在企業管控和專案管理中的重要性、作用、性質進行分級；需行政審批的專案工作同樣要根據工作的潛在風險程度進行分級。

只有在專案上實現“分級”管理，才能實現企業級/組織級專案管控的“分層”管理: 那些需要專案決策層管控，那些需要專案監控層/專案管控層管控，那些由專案管理層（專案部）自行管控。

這樣才可以在保證風險可控的前提下實現專案行政審批事項的高效運轉。否則就會出現某些企業員工出差申請和報銷都層層審批直至公司副總經理批准的笑話（幾千人的企業，幾位副總經理光批准出差申請和出差費用報銷，需要佔用多少時間，還幹不幹正事了？呵呵）。

此外要根據企業級專案管理各層次定位/各崗位職責，在專案行政審批事項中授於其相關管理角色: 有“經辦/起草”的、有“協辦/會籤”的、有“督辦/審批”的、有最終“批准”的。

例如人事任命，當企業將專案分等級時，就無需所有專案經理都由總經理任命了:

特級專案: 總經理任命

一級專案: 副總經理任命

二級專案: 分公司領導任命

例如分包合同批准簽署:

特級分包合同（合同額一億及以上）: 總經理。

一級分包合同（合同額5000萬及以上、一億以下）:副總經理。

二級分包合同（合同額1000萬及以上、5000萬以下）:分公司總經理。

三級分包合同（合同額200萬以上、1000萬以下）:分公司副總經理。

四級分包合同（合同額200萬及以下）: 專案經理。

例如批准專案管理總體策劃成果檔案:

《專案管理計劃》: 管理者代表/專案主管領導雙批准。

《專案實施計劃》、《專案適用法律法規》: 專案主管領導。

《專案適用標準規範清單》、《專案基礎技術資料表》: 分管副總工程師。

系列專案管理計劃: 分公司副總經理。

專案部系列管理制度: 專案經理。

這樣就實現了根據重要性和風險程度實現專案管理重大事項的分級授權，但這還不夠，我們還得研究各重要事項從經辦/起草、協辦/會籤、督辦/審批、批准全過程各層次組織和各關鍵崗位的角色分配。

例如任命專案經理:

經辦/起草: 專案經理辦公室負責人。

協辦/會籤: 人力資源部。

督辦/稽核:

1）特級專案: 專案分管副總經理。

2）一級專案: 分公司總經理。

3）二級專案: 分公司分管領導。

例如分包合同審批流程:

經辦/起草: EPC專案部。

協辦/會籤:

特級分包合同: 相關管控部門/職能部門負責人正職。

一級分包合同/二級分包合同: 相關管控部門/職能部門分管領導。

三級分包合同: 分公司管控部門分管領導/職能部門專案專員。

四級分包合同: 專案部相關崗位經理。

督辦/稽核:

特級分包合同: 專案分管領導。

一級分包合同: 分公司總經理。

二級分包合同: 分公司專案分管領導。

三級分包合同: 分公司管控部門領導。

專案管理總體策劃成果檔案:

經辦/起草: EPC專案部。

協辦/會籤: 職能部門。

督辦稽核: 管控部門。

把這些梳理清楚了，就可以編制企業級管理制度《專案行政授權管理規定》，相關領導和崗位人員人手一本（以表格進行工作分解和責任矩陣，不會太厚），可以全員明白組織授權及各層次崗位的角色分配，這就是“規範化管理”！

經批准的《專案行政授權管理規定》可作為建立專案管理資訊系統的依據。

不建立科學的專案行政授權管理，專案管理資訊系統上線後，不僅不會提高管理效率，反而會大幅降低管理效率。畢業紙質的管理制度頒佈後，各級管理者存在“變通”的可能性，而當所有專案行政管理事項在專案管理資訊系統上辦理時，相關審批流程就變成“強制性”，只有完成上一步驟才能進入下一環節。

三、確定專案管控規定動作，有效進行組織管控

解決了專案行政管理授權的問題，第二步我們要解決專案管控規範化、科學化管理的問題，目的是更好的實現“專案履約目標”/“企業專案目標”、更好地控制專案實施風險、更好的提高管理效率。

而要實現這樣的目標，就必須明確專案實施各階段、專案管理各方面的基本步驟，形成可複製的規定動作和管理紅線。

例如對於EPC總承包專案，在專案啟動與策劃階段必須形成以下規定動作:

1）任命專案核心成員，組建專案團隊。

2）召開“專案啟動會議”，實現組織動員。

3）進行“合同交底”，實現經營向實施團隊移交。

4）組織“專案實施條件調研”，認別項目特點、專案實施難點和專案履約風險。

5）組織“合同二次評審”，全面瞭解合同要求、系統研判合同風險。

6）編制《專案管理計劃》，統一專案管理總體思路、明確專案定位/專案目標/管控模式、內部干係人管理介面、提出專案管理各方面的主要原則。

7）召開“專案開工會議”，建立專案溝通協調程式、明確專案直接干係人管理介面，推動業主、監理/業主工程師和總包方之間的管理融合。

8）編制《專案實施計劃》，進一步明確專案各方面的管理原則；分解專案目標，明確專案指標；細化工作步驟/管理要求，建立工作規則和管理紅線；梳理內外干係人專案管理工作介面；實現業主、監理/業主工程師與總包方之間的管理融合。

9）編制《專案適用法律法規清單》，全面梳理和系統認別項目履約和專案實施應遵循的法律法規，包括但不限於適用的國際法律法規、專案所在國法律法規、中國法律法規和專案所在地法律法規；為系統控制專案法律風險、規範專案合法合規管理建立基礎和創造條件。

10）編制《專案適用標準規範清單》，全面梳理和系統認別項目履約應遵循的標準規範，包括但不限於適用的國際標準、中國國家/行業標準規範、專案所在國標準規範和專案所在地地方標準，為提高專案履約水平、控制專案質量風險建立堅實的基礎。

建立組織級專案管理的規定動作非常重要，例如對於EPC總承包專案，編制《專案基礎技術資料》並建立管理規則對於控制專案風險及其重要，沒有這樣的管理要求，仍然按傳統人治方式去進行管理，一個基礎技術資料的錯誤可能導致幾千萬乃至上億的損失!

四、建立專案級管理典型框架，實現專案級管理“標準化+定製化”

在建立了企業級專案管理基本步驟和管理紅線，並以《專案行政授權管理》為基礎在專案管理資訊系統上線後，基本解決了專案重大風險的企業級/組織級規範管控的問題。

下一步則要從專案管控的角度建立專案管理的規則、細化專案管理各方面的工作要求，努力提高專案管理的成熟度和顆粒度。但“專案”又具有“獨特性”，如果具有強制性的管理要求顆粒度太深，這種管理的強制性與專案的獨特性就會發生衝突，必然造成具體專案管控時的形式主義和官僚主義，就會影響專案履約和實現專案目標。

因此衡臣提出企業級/組織級管控專案的第二個主要原則: 有規則、無定式。就是說盡管每個專案都有其獨特性，但管理者一定要思考、研究並提出所有專案都應遵循的基本規則，而這些規則是具有強制性的。

這些具有強制性的基本規則就形成企業專案管理資訊系統的基本框架，但專案管理資訊系統還應在系統中體現不同專案具有“獨特性”的管理要求。

也就是說對於具體專案，在專案管理資訊系統中應遵循“標準化+定製化”的基本原則。 “標準化”大家比較容易理解，“定製化”管理要求如何保證其科學性往往令人擔心。

還是拿工程總承包專案管理為例:

首先我們要搞清楚工程企業的“專案管理體系檔案”、具體專案的管理策劃成果檔案與專案部管理制度各自的特點以及三者之間的差異與聯絡。

企業專案管理體系檔案是基於以往實踐的經驗教訓，透過“PDCA”迴圈總結的最體實踐，形成可以複製和具有普遍指導性的管理要求。

企業專案管理體系檔案可分成四個層次: 專案監控級、專案管控級、專案執行級和專案支援級。

專案監控級是企業級/組織級專案管理的“法律”、專案管控級是普通適用的“法規”，這二層都體現了企業級/組織級強制性管理的特點，類似於標準規範中的“強制性標準”；專案執行級體系檔案是具體工作的“指南”，體現了普通適用的管理要求，但只有部分要求具有強制性，類似於標準規範中的“強制性條文”。而“支援級”體系檔案則是著眼於提高工作質量、工作效率，提供基於專案管理最佳實踐的工作指導檔案，支援級檔案“不具備強制性”。

具體專案的管理策劃成果檔案是基於適用法律法規、工程總承包合同、企業管理制度、企業專案管理體系檔案、業主的管理要求，圍繞實現合同履約目標/企業專案目標，根據專案的“獨特性”，透過集體智慧形成的專案級系列管理檔案。

與企業專案管理體系檔案不同，任何層次的專案管理策劃成果檔案都體現了專案的“獨特性”。

專案管理策劃成果檔案也可以分成以下四層:

第一層: 《專案管理計劃》，可視為具體專案執行的“憲法”。

專案管理計劃原則上應遵循企業級專案管理體系檔案中具有強制性的管理要求，但也不應排除為滿足合同履約要求、控制專案實施風險對體系檔案中某些強制性管理要求作區域性修改和調整。

這就產生經批准的《專案管理計劃》與具有強制性的專案管理體系檔案出現矛盾，誰具有“優先順序”的問題？

對於具體專案而言，理所當然是經批准的《專案管理計劃》具有優先順序，否則就無法實現企業級/組織級強制性管理與專案“獨特性”需求的融合，也無法透過專案實踐透過PDCA迴圈持續改進、最佳化、提升企業專案管理體系。

特別對於一些剛向工程總承包轉型的傳統設計/施工企業，其企業級專案管理體系檔案成熟度還很低，更需要鼓勵具體專案解放思想，大膽進行管理創新，否則必然陷入固步自封、官僚主義盛行的狀態。

但在新常態下，各級國企越來越強化“合規管理”，違規決策造成企業損失將追究企業領導責任。這就是衡臣為什麼提出《專案管理計劃》應由企業“管理者代表”和專案主管領導“雙批准”的原因。

《專案管理計劃》沒有管理者代表批准，合規審計檢查時就不管《專案管理計劃》如何規定，兩者之間產生差異時必須以專案管理體系檔案相關規定為準；《專案管理計劃》得到管理者代表的批准，《專案管理計劃》就獲得了“優先順序”，因為專案管理計劃與體系檔案都是管理者代表批准，優先順序看批准時間先後。

第二層: 專案實施計劃，可視為具體專案執行的“法律”

《專案實施計劃》的上位法是批准的專案管理計劃，但其仍然應遵守企業專案管控級體系檔案中相關強制性管理規定，但專案實施計劃更體現專案管理各方面的“獨特性”。

《專案實施計劃》不僅反映企業專案管理體系檔案中的規定動作和管理紅線，更加體現具體專案管理策劃所形成的，具有專案“獨特性”的“自選動作”和“自選管理紅線”。

《專案實施計劃》應融入業主的管理要求，成為實現業主、監理/業主工程師、總承包商之間管理融合的載體，因此《專案實施計劃》宜分為內外版本，對外版本應提交業主批准。

第三層，系列管理計劃，可視為具體專案執行的法規“條例”。

並非所有工程總承包專案都需要編制系列管理計劃，對於大多數工期短、複雜性程度不高、實施風險較小的中小型專案，《專案實施計劃》基本上可以滿足專案實施專案管理顆粒度的要求。

但對於規模大、工期長、複雜性程度高、實施風險大的專案以及對企業發展和市場開拓具有戰略意義的專案，宜在批准的《專案實施計劃》基礎上編制系列專案管理計劃。

對於EPC工程總承包專案，系列管理計劃主要包括: 設計管理計劃、採購管理計劃、施工管理計劃、除錯/試執行管理計劃、HSE管理計劃、質量管理計劃、進度管理計劃、費控管理計劃、財務管理計劃、合同管理計劃、資源管理計劃、風險管理計劃、文控/資訊化管理計劃、溝通協調管理計劃、行政管理計劃和收尾管理計劃。

編制系列管理計劃的目的，一是提高具體專案專案管理的規範化程度/顆粒度；二是將專案實施風險管控思路落實到各項工作的具體步驟/具體要求；三是透過“工作分解和責任矩陣”，進一步細化專案內外干係人、干係人各層次崗位，在具體專案管理工作中的角色分配和管理介面；四是為編制專案部系列管理制度提供依據。

第四層: 專案部系列管理制度，是將專案部視為企業內部一個臨時“獨立組織”的“規章制度”。

專案部管理制度具有“一次性”的特點，因為專案部是企業內部的臨時組織，由於其同時接受企業與業主管控，其對企業又具有“相對獨立性”。當專案合同執行完畢、專案部解散，專案部管理制度就失去了“效力”!

專案部管理制度的依據是經企業和業主雙批准的《專案實施計劃》和/或經企業批准/業主認可的系列專案管理計劃以及業主方頒佈的相關管理制度。

專案部系列管理制度是業主、監理/業主工程師和總包方在具體專案上實現管理融合“落地”的載體，有著很強的專案“獨特性”，成為總承包商及其相關分包商共同遵守的“規章制度”。

因此，在企業專案管理資訊系統中，如果期望能夠作為具體專案實施的管理平臺，就必須根據“標準化+定製化”的思路去搭建專案管理

資訊化平臺的框架。

標準化是指在整體框架搭建方面應體現企業專案管理體系檔案的強制性要求，定製化是根據批准的專案管理策劃成果檔案，可以在企業資訊化管理部門的指導下進行“量身定做” 。

例如在企業監控級管理體系檔案中根據《專案行政授權管理規定》明確了企業級/組織級行政審批的基本流程，這是“標準化”的一部分。

對於編制和審批《專案管理計劃》，企業管控級又規定了基本步驟和管理介面:

第一步: 提交“送審稿”

專案部在完成“初稿”內審的基礎上，編制並向企業相關專案管控部門/職能部門提交“送審稿”，管控部門/職能部門指定相關專家進行“專家評審”（注意: 此時部門行政領導可以不參與，即使參與也是以專家身份出現）。

第二步: 提交“報批稿”

專案部根據專家評審意見對“送審稿”進行修改，升版形成“報批稿”。專案部根據《專案行政授權管理規定》，將“報批稿”及送審稿“專家評審意見”提交相關管控部門行政負責人“稽核”、相關職能部門行政負責人“會籤”，然後流轉至《專案行政授權管理規定》中的批准人。

各級行政負責人在“報批稿”檔案審批單上分別填寫稽核意見、會籤意見以及批准人的綜合意見。

根據專案情況和批准人的意志，對於某些規模大、工期長、複雜性程度高、實施風險大的專案以及對企業發展和市場開拓具有戰略意義的專案，批准人可在籤置綜合意見前發起“企業級綜合評審會議”。

第三步: 提交“最終版”

專案部根據報批稿“檔案審批單”中各級行政負責人的書面意見和/或企業級綜合評審會議的會議紀要進行修改，升版形成“最終版”。

最終版提交給各級行政領導分別在專案管理資訊系統稽核、會籤、批准流程中籤批。籤批過程中各級行政領匯出能出現的少數修正意見，應留下書面記錄。

第四步: 提交“簽字版”

專案部將最終檔案列印成書面檔案，由各級行政領導在稽核、會籤、批准欄簽名書面確認。編制人由專案經理作為專案部代表簽字並加蓋“專案部章”。

需要注意，上傳專案文控系統的檔案建議採用簽字版的掃描版，以確保檔案的“有效性”。

以上體現了“標準化” 的特點，但仔細體會上述管理流程，其體現了企業級/組織級專案科學決策的重要原則: 專家意見+領導意志。

我們許多企業在專案決策管理更多的體現“領導意志”；有些行政領導喜歡開會按“少數服從多數”的原則進行決策。

這些都無法真正實現科學決策，因為正如橋水基金創始人雷.達里奧所言: “參加會議人員中，住住只有20%的人員擁有會議主題所需的知識和經驗”。因此在專案決策時，不要期望開會能解決所有問題，也不要迷信“少數服從多數”，真理往往掌握在少數人手裡實質上是指這少數人更專業、更有經驗。

不可否認，企業不少行政負責人也是從技術、專案管理通道獲得晉升，也曾擁有紮實的專業基礎和豐富經驗。但當行政領導時間長了，一方面原有的專業知識會大幅縮水，另一方面時代在進步、知識在更新，擔任行政負責人後在技術和專案管理方面的持續學習、自我迭代大大減少。

因此行政負責人審批前的專家評審有利於提高專案決策事項行政審批的科學性，也有利於行政負責人審批的工作效率（專家評審在前，有利於行政負責人快速切入重點，也有利於行政負責人集思廣益）。

企業級/組織級專案決策管理這種“行政審批專家評審先行”的管理原則應寫進企業專案管理體系檔案並形成“強制性”的管理要求，這就是專案管理資訊系統“標準化”的體現。

專家從那裡來？作為工程企業人力資源管理的重要組成部分，應建立企業級的專家庫，包括內部專家庫與外部專家庫，並對專家庫進行大資料分類管理，這些都可以在專案管理資訊系統中實現。

具體專案實施時，各級負責人可根據大資料在專案管理資訊系統中指定合適的專家參與專家評審，保證參與決策評審的專家真正擁有決策事項某個方面擁有的知識和經驗。擁有成熟人力資源智慧化的專案管理資訊系統，還可以根據決策事項典型特徵，在系統中自動推薦專家。

工程總承包專案之所以採用“矩陣式”管理模式，就是由於總包專案風險巨大，必須改變以往“直線制”管理將寶押在個別崗位人員的方式，而在矩陣式管理模式下，所有風險項的管理均由兩個及以上崗位關注且分擔不同角色。

因此，對於規模大、工期長、複雜性程度高、實施風險大的專案以及對企業發展和市場開拓具有戰略意義的專案，企業級/組織級專案決策事項的專家評審，也不宜將寶押在某個專家身上，應適當增加參與評審的專家人數。

“標準化+定製化”，企業級/組織級管控更多的採用“標準化”，區域性可根據批准的《專案管理計劃》在專案管理資訊系統裡進行區域性調整；而“定製化”更多的體現在專案部層面，這是由專案的“獨特性”所決定的。

例如對於工程總承包專案組織結構:

儘管EPC總承包專案組織結構有其統一的規則: 專案部組織層次可分為決策層、管控層和管理層；管控層按“專業化”管理思維需要配置相關的崗位經理: 設計經理、採購經理、施工經理、除錯經理、HSE經理、質量經理、（進度）控制經理、費控經理、合同經理、財務經理、文控經理、行政經理。

但不同專案有著不同的專案管控模式，具體專案的組織結構及核心崗位配置在《專案管理計劃》審批階段確定；專案部管理層崗位設定可能在《專案實施計劃》審批階段最終確定。

因此，在具體專案的專案管理資訊系統中應根據不同的專案管控模式和批准的組織結構和崗位配置進行“定製”。

例如對於單專案管控模式、專案集管控模式、聯合體管控模式、內部聯合體管控模式，專案部管理層次劃分基本一致，但具體的組織結構和崗位配置差別很大。

經批准的系列管理計劃、專案部系列管理制度也是“定製化”的依據，並且這些管理策劃成果檔案是業主方、監理/業主工程師、總包方、相關分包商實現管理融合，建立專案統一管理規則的載體。

專案管理資訊系統也應實現“管理融合”，應能夠向專案直接干係人相關崗位人員提供端點，使得專案干係人能夠在統一的資訊化專案管理平臺“協同工作”。

也就是說，要想建立現代、先進的專案管理資訊系統，就必須拋棄傳統的“內部流程管理”的傳統做法，要讓專案管理資訊系統“穿透專案干係人的邊界”!

從專案級管控規範化的角度，這種體現專案“獨特性”、依據批准的專案管理策劃成果檔案在專案管理資訊系統中進行定製化，從專案級管控規範化的角度何嘗不是一種專案上的“標準化”。

要想搭建專案級，穿透干係人管理邊界的專案管理資訊系統，就必須用好“工作分解和責任矩陣”這個工具。

例如在崗位人員責職方面傳統的專案管理體系檔案有個通病: 每個崗位在檔案中都以文字的方式羅列了一大堆職責。但你想很難搞清楚在每項具體工作中需要那些崗位參與，這些崗位在工作中究竟擔任什麼角色？

而採用“工作分解和責任矩陣”則非常簡單，專案管理工作分解可以透過專案管理策劃“逐層細化”，責任矩陣則可以授於相關崗位不同的角色: 批准（A）、稽核（C）、負責（R）、參與（P）、提供支援（I）、會籤（J）、必要時採用（*）。

對於工程總承包專案而言，參與角色分配的崗位不僅總包企業內部，還應該包括專案業主、監理/業主工程師、分包商相關崗位。

採用“工作分解與責任矩陣”不僅可以穿透專案干係人管理邊界，也穿透了組織不同層次、不同板塊、不同崗位的“管理壁壘”，成為工程總承包專案“一體化管理”的有效載體。

五、改變專案資料採集方式，實現智慧資料後處理

目前大多數工程企業在專案監控方式仍然採用層層彙報的方式，根本不適應企業級/組織級監控專案風險和發現企業級/組織級“系統風險”的需求。

有些專案主管領導發現，專案部的月度進展報告以及專案部依據企業下達表單填寫的專案資料，貌似一切正常。但不知道何時就給你爆個大地雷（某專案在貌似一切正常情況下，突然收到業主要求中止合同的律師函），且經常不斷爆雷，企業根本無法預測何時爆雷和透過監控採取措施預防系統風險。

結果各級領導往往疲於奔命，不斷的當“救火員”。出現這種情況除了企業專案管理體系成熟度不高、專案管理規範化程度不夠外，還主要是由於以下原因造成:

第一，專案資訊失真

專案資訊失真的第一個原因是未能直接從基層自動抓取資料，這個是技術因素；第二個原因是專案各層次有意修改資料，一方面是“家醜不可外揚”的傳統觀點作怪，二是某些企業“追責比改進優先”的考核機制促使專案部不得不隱藏對考核不利的專案資訊。

但許多設計單位將各專業設計變更的“數量”作為考核項，變更越多得分越低。這就導致設計人員不願意主動變更、事先變更，有些專案試圖用工程聯絡單、圖紙會審會議紀要替代設計變更單，從而造成專案質量、進度、成本甚至安全風險。

由於“擔心追責”，設計人員在設計變更單填寫變更分類資訊時，往往不能如實填寫造成設計變更的真正原因，習慣性將變更分類填寫為外部原因。不信您去檢查，傳統設計單位設計變更單上分類資訊上填寫最多的是“其他原因”（真正原因是什麼？你猜!）。

第二，資料分類不科學

好多企業未根據組織各層次定位去研究專案資訊需求，科學搭建資料分類資訊。而是“眉毛鬍子一把抓”，往住給專案部層次造成“管理負擔”（許多大型工程企業專案部往住需要安排多位專人填報上級下達的各類表單）。

以專案進度資訊為例，企業職能部門（監控層）、管控部門（管控層）在企業級/組織級專案進度管理上有著不同的管理定位。

職能部門（例如工程管理部）應該主要監控“目標級進度計劃”的執行情況，其採集的資料主要用來監控“專案工期目標”與“關鍵里程碑進度節點”的執行情況。

而管控部門（例如工程控制部）在進度管控的顆粒度會更深些，其不僅關注目標級進度計劃實施情況進行風險監控；還應重點對“基準級進度計劃”的執行狀態，透過資料分析的方法來進行監控，幫助專案部發現潛在風險，指導專案部進行糾偏。

要想達到這樣的管理效果，就必須科學分類專案資料資訊，否則讓專案部費時費力填寫的專案資訊，對企業級/組織級專案管理“貢獻有限”，而各專案浩如煙海的資訊往往由於職能部門、管控部門多專案監管管理崗位人員不足來不及處理（大家戲稱為“收藏帝”）。

第三，未建立科學的專案資料（資訊）後處理規則

專案資料（資訊）經處理後除用於具體專案的管控外，對總包企業而言，更重要的是所有專案資料資訊進行後處理，從中發現專案管理方面的系統性問題，從而可以依據資料資訊後處理成果向組織提出系統風險提示，相關部門可以據此開展相關管理提升和專項整治活動。

例如對於總包工程的安全管理:

各專案都在專案管理資訊系統平臺上工作，專案各干係人（業主、監理、總包專案部、分包商）發現的安全隱患/安全違章資訊自動上傳系統。

系統可以智慧形成綜合報表，專案部和專案管控部門可以根據資料評估專案安全生產狀態；而企業職能部門（安監部）更可以根據大資料開展專項安全治理活動。

沒有科學的專案資料（資訊）後處理規則，就難以依據資料評估狀態和發現系統性問題。沒有智慧資料分析，依託人工費時費力，效果可想而知。

因此，在建立專案管理資訊系統時，要組織各方面專案管理專家建立規則，配合程式設計師開發軟體。