項目變更管理流程和方法精選(九篇)

前言：一篇好文章的誕生，需要你不斷地搜集資料、整理思路，本站小編為你收集了豐富的項目變更管理流程和方法主題范文，僅供參考，歡迎閱讀并收藏。

第1篇：項目變更管理流程和方法范文

【關鍵詞】中小企業、配置管理流程

【中圖分類號】C29【文獻標識碼】A【文章編號】1672-5158（2013）07-0492-02

一、 引言

軟件配置管理的發展在國內雖然是21世紀的事，但是發展比較迅速，得到了軟件公司的普遍認可。但是對于中小公司，由于重視不夠或缺少相關知識，在實際使用中存在一些問題。中小公司照搬大公司流程存在也不切合實際。

二、 配置管理流程

2.1制定配置管理計劃

在《項目開發計劃》完成后，配置管理員（SCME）參考項目經理制定的《項目開發計劃》完成《配置管理計劃》，《配置管理計劃》中需要明確項目的基線配置項計劃，以及基線計劃等信息。

不同的項目，配置管理計劃的內容可以不同。主要受以下方面影響：

項目的大小和復雜性會影響到配置管理計劃。特別簡單的項目可能只需要一個配置管理工具，簡單管理一下源代碼；但是大項目、復雜的項目則需要詳細的配置計劃。

特殊的項目需要更詳細的計劃。舉例來說，如果企業中絕大多數產品都是完整獨立開發，而某產品使用了開源代碼。那么在該項目的配置計劃中，此點就要考慮。

2.2 項目配置庫的建立

項目立項后，項目經理通知配置管理員建立項目的配置庫，同時為項目組人員開放配置庫權限。

2.3 配置識別

配置識別的目的是識別配置項和基線。

配置項是指處于配置管理之下的軟件或/和硬件的集合體。這個集合體在配置管理過程中作為一個實體出現。

基線是已經通過正式復審和批準的某規約或產品，它因此可以作為進一步開發的基礎，并且只能通過正式的變更控制過程來改變。

配置識別活動包括以下幾個內容：

* 配置項識別

配置項可以分為基線配置項和非基線配置項?；€配置項包括所有的技術類文檔和源程序等；非基線配置項包括項目的各類計劃和報告等。

配置管理工作的關注重點是基線配置項。配置項識別由SCME參照項目開發計劃中的交付物，同項目經理共同識別基線配置項，以及配置項間的依賴關系。配置管理員需要完成《配置管理計劃》中的配置項計劃。

* 配置項標識

配置項的標識，版本等規則，參見企業標識規范。

* 基線建立

一般在項目的不同階段有對應的基線。

> 基線建立

當基線包含的配置項穩定后，由項目經理通知SCME建立基線?；€建立后一般不允許隨意更改。SCME需要對基線庫的權限進行設置。

> 基線變更

當基線建立后，如果基線配置項經過若干次變更，在配置項穩定后，項目經理認為有必要進行變更（再等），或者基線不穩定，需要回朔到上一基線，由項目經理通知SCME對基線進行變更。

2.4 版本控制

版本控制能夠簡單、明確地重現軟件系統的歷史版本。一般的配置工具都能自動保存配置項的版本歷史，但是大多時候，針對項目不同階段需要整體化的標識。以下是整體化版本控制的方法：

* 標簽

如果項目只有一個主干，只需要通過打標簽的方式，來辨明當前的整體版本。這樣將來搜索所有的以這個整體版本命名的標簽，就能找到這個整體版本對應的所有文件的正確版本，包括源代碼。

* 分支

不同的客戶，基本需求一定，但是有不同的差別，此時就需要用到分支。使用分支，能夠有效地實現隔離，也實現共享。但是分支是有管理成本的。如果標準版的比較頻繁，而客戶又要求變體的跟上標準版的話，那么需要頻繁創建分支。另一方面，如果變體所在的分支上，包含了一些應該共享的改動，那么應該合并到主干。這樣，相應管理成本也會提高。

2.5變更控制

在項目開發過程中，配置項發生變更幾乎是不可避免的。變更控制的目的就是為了防止配置項被隨意修改而導致混亂。

在瀑布模型的管理中：修改處于“草稿”狀態的配置項不算是“變更”。當配置項的狀態成為“正式”，或者被“凍結”后，此時任何人都不能隨意修改，必須依據變更的規則執行。

以下為變更規則：

1） 變更請求

2） 變更審核

3） 配置項出庫

4） 變更實施

5） 變更驗證

6） 配置項入庫

SCME負責實施配置項入庫，確保配置項處于“正式”狀態，并且版本正確。并通知項目經理，項目組人員，質量保證人員等變更已經完成。

但是還有兩種情況，可能不需要嚴格的變更流程：

1） 功能小變動：把程序已有的功能，稍微增強或改變一下。特點是：數量多容易丟，改動量不太大。對這類請求的管理，建議像對缺陷的管理，進行分別跟蹤、處理，直至解決。

2） 迭代模型中管理變更

迭代開發把一個大項目在時間軸上分解成很多小項目，每個小項目被稱作一個迭代。幾乎每次迭代，都會包含需求分析，系統設計、代碼實現，以及集成和測試。這樣就不必刻意走變更流程，只要通過基線或標簽的方式就可以對配置項進行識別。但是在每一個迭代中，出現的對正式的配置項進行修改，還需要走變更流程。

2.6配置審計

配置審計是對交付的軟件基線進行檢驗，以驗證其中包含了所有必需的內容，并且這些內容本身都是經過驗證而滿足了需求。配置審計分為功能審計和物理審計兩種：

1） 功能審計是一種驗證審核，它驗證配置項的開發是否完全滿足特定的性能和功能特性，并且所有的操作和支持文檔是齊備的。功能審計主要方法有評審、測試等。一般由研發人員和測試人員來做。

2） 物理審計的目的是為了驗證配置項是按照技術文檔中的規定構建的。

物理審計工作主要由配置管理人員定期（每月）執行。也可因事件驅動進行，比如配置項，新版本等。

主要進行以下內容：

> 審核配置項一致性，具體檢查點如下：

* 參照配置管理計劃檢查配置項是否按時提交；

配置項是否滿足配置管理相關規定，如配置項標識，版本，狀態，版式等；

配置項信息是否正確；

配置項評審記錄、變更記錄是否完備等。

審核配置項版本一致性：檢查配置管理工作表中配置項版本信息與配置庫中配置項版本信息是否一致，以免工作疏漏造成不一致情況。

審核基線一致性：檢查配置管理工作表中基線內容與配置庫中基線信息是否一致。

審核結構權限一致性：檢查配置庫結構權限是否合理，是否滿足安全適用需要。

2.7配置狀態報告

配置狀態報告工作主要由SCME定期執行。也可因事件驅動進行，比如階段總結，階段評審等。

常用的配置狀態報告分為：

> 周報告

周報告每周進行，主要內容為本周開展的關于SCM的活動總結，以及對SCM工作發現的問題的跟蹤。周報告的審閱人為項目經理、質量部經理。

> 總結報告

總結報告主要用于項目結束時，或者因事件驅動而對SCM工作的當前狀態進行概括總結?？偨Y報告的審閱人為項目經理、質量部經理。

2.8 配置中止

當項目結束時，由項目經理確認此項目已不會再有配置管理方面的變更，由項目經理通知配置管理員項目關閉。

配置管理員關閉該項目的所有讀寫權限，并將項目基準庫內容移入產品庫中。該項目配置管理活動中止。

三、 結束語

本文對配置管理各環節都根據實際進行了簡化變通，或提供了方法，對中小企業的配置工作有一定的借鑒意義。

參考文獻

第2篇：項目變更管理流程和方法范文

ABC集團公司(應作者要求，隱去文中所涉及公司的真實名稱，以ABC集團公司代之)是一家傳統的制造業企業，總部設在北京。現在公司IT部門最主要的職責有兩方面：第一部分是IT系統運行維護管理，包括SAP生產管理系統、Oracle財務系統、庫存管理系統，以及郵件系統的運行維護管理；第二部分是IT基礎架構的管理，包括機房、服務器，還有入侵檢測、防病毒等IT系統一般控制的管理。

隨著業務部門的需求和系統的復雜程度不斷提高，IT系統暴露出來的問題也越來越多，管理層對IT部門運行效率的要求也在不斷提高。公司需要對IT部門有一套切實可行的方法來指導他們的日常工作，使IT真正成為公司業務發展的驅動力。

2002年7月份在美國通過的薩班斯法案404條款，要求上市公司管理層和董事會對財務內部控制和財務報表的真實性與可靠性負直接責任。雖然從字面上看，這和IT部門的工作不直接相關，但卻一夜之間就把IT部門和IT技術人員推到了內部控制和財務控制的風口浪尖。這是因為大型公司的財務系統和業務系統與IT的關系已經密不可分。

作為一家在美國上市的企業，ABC公司需要對內部控制的整個流程進行統一梳理后，接受

美國證監會每年的年審，也就是薩班斯法案的審計。

ABC公司的四個困惑

對公司的IT系統，ABC集團的管理層存在四個難以解開的困惑。

第一個困惑,是長期以來的巨額投資好像都沒有明顯的回報。投給IT部門的錢都派了什么用場？

第二個困惑，是公司看不到IT投資帶來的回報。系統實施往往達不到預期的效果，甚至有個別系統剛上線就失敗了，但就是找不到失敗的原因。

第三個困惑，是如何找到一個可行的辦法來管理有形或無形的信息系統資產，從而使IT真正成為驅動集團業務發展的力量。

第四個困惑，也是最現實的問題――公司要如何通過薩班斯法案的合規審計？

咨詢公司的四個問題

ABC集團公司管理層決定聘請咨詢公司來對他們的IT管理控制進行統一調研，輔助他們通過薩班斯法案。結果在項目招投標過程中，中標咨詢公司以四個簡單的問題就征服了ABC公司管理層，因為他們的四個問題正好和公司的四個困惑一一對應。

首先，公司是否在進行正確投資？公司在進行商務投資的時候會制定財務計劃，商務投資具體的回報額是多少，什么時候開始，都有一個定量的計算。那么進行IT投資時，ABC公司是否有一個定量計算，投資又是否正確呢？

其次，公司是否以正確的方式進行實施？因為ABC公司不是IT企業，而是一家傳統的制造業企業，其IT系統只是為了更好地支持業務。那么正確的實施，就是通過IT的應用讓傳統運作方式的效率大幅度提高，而不是為了擁有一個龐大的IT部門。日常工作多了一項IT的維護就好像多了一個負擔，IT部門能夠隱身于這個企業之中，才是IT部門運作的最高境界。

再次，管理層是否知道IT部門的運作過程？為什么系統失敗以后沒有辦法讓相關人員或部門來承擔責任？實際上，ABC集團在進行IT管理控制咨詢之前，IT部門的職責非常簡單，公司管理層不知道IT部門如何運作，也不知道IT部門和業務部門之間到底是什么關系。

最后，公司是否明確薩班斯法案對IT的真正要求？根據管理層的要求，這個項目的目的是基于滿足薩班斯法案404條款的要求，但是ABC集團也可以借助這次機會，來解決以上四個具體問題。

最終，ABC集團公司管理層和咨詢方一拍即合。

實施過程：步驟環環相扣

在聘請咨詢公司以前，ABC公司管理層了解了業界的很多做法，也了解了很多國際IT管控標準，包括COBIT、ITIL、ISO 17799等，在考慮能否直接把這些經驗和標準作為企業的制度引進過來。

答案是否定的。因為COBIT有34個高級管理目標和318個詳細的管理目標。如果把這些目標一股腦地強加給公司IT部門，IT部門可能變得更混亂，這不符合企業自身的實際情況。作為一個傳統的制造型企業，ABC集團運用IT的目的很明確，即提高運行效率和通過薩班斯法案404條款的審計。在確定了項目目標以后，ABC集團公司在咨詢公司的幫助下，確定了項目實施的原則：參照標準，針對需求，分步實施。

在項目原則確定以后，咨詢方進入ABC集團公司，開始分階段進行項目的實施。

調查研究

在調查研究階段，首先要了解企業IT系統目前運行的狀況。實際上，在了解企業現狀的過程中，咨詢方會編制兩套流程圖，以此來了解企業整個IT系統的運行狀況，包括IT一般控制流程圖和企業的IT應用控制流程圖。

咨詢公司把IT的一般控制分為三大類，第一大類為變更管理，變更管理又包括了程序變更、數據變更、配置變更三類。

比如實施方實施完ERP系統就走了，但后續可能有一些補丁要打，程序有一些源代碼需要修改，那么在程序進行變更的時候，需要有一套流程來進行控制。也就是說，要有一套標準的流程來讓程序變更是可控的，這就是程序變更中的控制。

比如ERP系統前臺錄入以后，發現錄錯了，需要修改。但由于系統已經對數據進行了處理，前臺不能修改，需要IT部門來協助修改。假如前臺直接給IT部門打電話，要求進行數據修改的話，從標準上來講，這是非常危險的一個錯誤，數據變更中的控制問題就顯示出來了。

配置變更則會落實到具體的操作系統和數據庫的安全設置上，主要包括服務器的安全設置，比如一些安全參數。在變更這樣一些參數的時候，有沒有遵循標準的流程，就是配置變更的內部控制所關注的。

第二大類是邏輯訪問控制。邏輯訪問的控制包括用戶，用戶的賬號、密碼、權限是如何申請的等等。薩班斯法案404條款所要求的對企業內部控制和財務報表的可靠性發表意見，實際上對IT部門的要求就是要做到可控。因為只有管理層心中有數，業務和IT都是可控的，那么在年終給證監會提交報告的時候，公司領導才能拍胸脯說財務報告是可靠的。

第三大類就是IT運行維護管理。IT運維管理包括防病毒、運行監控、業務持續性計劃以及災難恢復計劃這樣一些和IT部門息息相關的工作。

咨詢公司把變更管理、IT運維管理、邏輯訪問控制管理統稱為IT一般控制。他們通過了解、訪談來繪制一套流程圖，從而了解企業的現狀。而繪制流程圖的目的，是為了下一步能夠訪問企業的各個內部控制點。

流程優化

在調查研究階段，主要是了解現有IT的運行狀況，及財務相關控制點是如何運行的。在流程優化階段，則對流程圖中體現出來的問題和欠缺進行優化。

比如變更管理，以前可能只需要一個電話，IT部門就會應要求做變更。但是實際上，根據COBIT的要求，需要有一套正規的流程。這個流程可以歸納為變更的申請、變更的審批、變更的執行，以及重大變更最后上線這樣幾個環節。在優化的過程中，變更的主要問題是ABC公司沒有成文的規定，且沒有區分變更的類型。

以程序變更為例，從變更的時效性來區分變更的類型，可以分為緊急變更和普通變更。普通變更就是時間要求不那么緊急的變更，緊急變更則相反。對緊急變更，則需要另外的一套流程，流程定下來以后，每個人都要遵守。

在咨詢方找到了ABC集團公司在IT運行方面的漏洞之后，在流程圖中對控制進行了優化。進行優化以后，他們編制了控制矩陣(control matrix)，用它與所有的控制連接起來，每個控制一環接一環，最后能夠看到財務報表輸出的整個過程。比如某個銷售數據出了錯誤，馬上可以追溯到是哪個控制出了問題。這樣，管理層就可以通過控制矩陣，很快找到是哪一個點出了問題，而不是像以前一樣，出了問題還不知道問題是怎么產生的。

制定規則

制定規則階段，是針對優化后的流程圖和與管理層溝通過的控制矩陣，來制定整個公司的IT管控體系。制定這些規則所參考的標準，可以理解為和COBIT相似的、符合ABC集團自身情況的一個具體操作規程。

這里包括高層的管理策略，比如如何指導IT的工作，規范變更管理、邏輯訪問控制、IT運維管理的操作流程等等。只有當企業不是把IT部門當作救火隊來用，而是遵守一套流程，有審批和最后確認的過程時，IT才能做到可控。

還有操作層面文檔的管理。為了應對薩班斯法案404條款的審計，要把IT支持的財務報表生成的每一個控制點上如何運行，做一個記錄。

對控制測試文檔的管理，首先是為了管理層的日常管理，但最主要的，是為了通過薩班斯法案404條款的合規審計。因為在審計過程中，審計公司會查看變更管理的流程，在了解流程之后，他們會取出一些證據，以此檢測這個流程是否真的按照規范運行。在那之前，企業通過對文檔的管理，為通過薩班斯法案404條款做了積極的準備。

控制測試

操作規程出來以后，就要落實到具體的工作中，看這個操作規程是否切實有效。制定規程后，將新規程交由管理層去推廣，由咨詢方負責培訓。在企業內部推廣實施三個月以后，咨詢方要在外審對ABC集團進行薩班斯法案404條款審計之前自行測試一遍，包括穿行測試和主要控制點的抽樣測試，并把測試結果直接報告給公司管理層，以便進行進一步的修改。

在測試的第一階段，要從財務風險落實到IT風險，從IT風險落實到IT控制。由于是為了應對薩班斯法案404條款的審計，也就是針對財務報表的真實可靠性發表意見，所以首先把財務報表的潛在錯誤列舉為最可能出現的幾個風險。因為在繪制控制矩陣的時候，繪制了IT的應用控制風險矩陣圖，所以每一個可能出現錯誤的財務流程，都可以追溯到IT的相關風險。比方說銷售數據出現了錯誤，那么很可能是ERP前臺錄入出現了問題，也可能是數據備份出了問題，或是數據傳輸出了問題，于是財務相關的風險落實到了與IT相關的風險。在列出幾個財務風險以后，通過控制矩陣，就可以找到與這些風險相關的控制流程，在企業內部，也就制定了與風險相關的控制。

第二階段，要把控制分類，區分哪些是主要控制，哪些不是。如果這個控制失效，就會直接導致財務風險的發生，這個控制就會被定位為主要控制。然后需要確定主要控制的屬性，因為針對每一個不同的控制類型會有不同的測試方法，屬性可以決定測試的方法是什么。最后根據主要控制的類型，咨詢方會制定一套測試計劃。

整個測試過程的邏輯，就是從財務風險落實到IT風險，考慮如何降低和減少相關IT風險的控制難度和復雜度，分清這些控制哪些是主要控制，哪些不是主要控制。對主要控制，除了穿行測試以外還要進行抽樣的具體測試。

比如說，根據流程發生的頻率來進行測試，如果頻率發生低的，抽取樣本就高，而頻率發生高的，抽取樣本就低。總之，就是要保證在企業內部關系到財務風險的每一個控制，不僅有政策層面的控制，也有操作層面的控制。

項目跟進

項目的最后一個階段，咨詢方給ABC集團公司提供了一整套適合于企業IT內控管理的文檔規范，以及給管理層制定了定期測試標準，對人員進行了培訓。

項目小結

第3篇：項目變更管理流程和方法范文

關鍵字 信息系統；范圍管理；集成

【中圖分類號】C931.6文獻標識碼：B文章編號：1673-8500（2013）01-0006-01

1信息系統集成項目范圍管理存在問題

信息系統項目涉及專業面廣、集成難度大、范圍不易界定、需求變化頻繁，在項目范圍管理上的不足直接影響了項目的管理水平，主要表現在以下方面：

1.1項目前期的范圍管理被忽視。由于信息系統集成項目的最終用戶和技術部門沒有參與到項目前期工作中，最初的范圍界定局限于“就系統論配置”，沒有考慮系統與應用的結合，沒有考慮信息系統所需的配套設施。以上范圍的缺失直到項目實施過程中才得以發現，導致集成項目進度及費用都超出預期。

1.2不能有效掌握用戶需求。信息系統項目開始實施時，開發人員根據招標文件上的《信息系統軟件功能要求》進行軟件設計。開發人員是企業員工，認為自己熟識相關業務背景；在需求調研的過程中，對于用戶的各項需求只是簡單的記錄未進行需求分析。信息系統集成項目在開發階段，需求變更頻繁；投入試運行后，功能實現及穩定性都不盡如人意。

1.3范圍管理的部分流程缺失。很多集成項目在立項及科研報告中只提及項目建設的必要性及建設目的而在隨后的初步設計階段，設計單位的設計文檔又只提出了項目的部分建設條目清單及軟件需完成的功能列表。集成項目招標完成后，項目范圍說明書和項目需求分析報告等一系列文件往往會被忽略。從這些集成項目的管理流程我們可以看到，集成項目的范圍管理方面缺失了范圍計劃編制、范圍定義和范圍確認過程。這些過程的缺失就使項目范圍的變更失去了基線。

1.4缺乏范圍變更的管理控制措施。信息系統集成項目在實施過程中會發生很多范圍變更。對項目投資和項目進度都會有較大的影響。有的項目組沒有預先建立變更的管理體系，對于范圍變更的影響沒有事前預判，對于變更的發生缺乏有效的控制措施。一旦有變更發生，項目組就只能以增加投資和工期延后為代價。

2主要原因

在范圍管理中反映出的這些問題是多方面因素綜合作用的結果：總結起來，主要原因在于：

2.1項目管理人員管理水平有待提高。由于信息系統的建設是與信息技術緊密結合的，因此目前很多信息系統的項目管理人員都是由技術人員轉型擔任的。在項目管理的過程中，他們傾向于從技術的進度看問題，而沒有自覺應用項目管理的規程及技能。

2.2軟件公司在產品開發中缺乏項目管理思想的應用。信息系統開發過程的變更、資料的記錄由相關技術人員掌握，沒有統一規范的管理。這一需要協同工作完成的軟件產品研發項目被拆分成了各自為政的多個軟件的編制。軟件的開發周期及質量都受到不利影響。

2.3公司沒有建立適應信息系統項目的管理機制。信息系統作為一種多學科集成、與公司業務、流程、應用密切相關的系統，有著與基本建設項目、電力系統等基礎設施類項目截然不同的特點。然而，現行流程從項目立項、投資到建設都沿用基礎設施類的管理方法，缺乏針對信息系統的項目管理機制。

3解決辦法

3.1績效獎懲強化變更控制。僅有范圍變更流程尚不足以真正控制變更，這是因為項目組的外部有許多壓力，缺乏行之有效的變更控制手段。要確保項目范圍變更控制流程有序進行，必須有進攻型的嚴謹規范制度來約束，通常企業績效管理的任務、進度、文檔、檢查和指標均對項目范圍變更控制流程的落實有影響，在項目最關注的流程節點就需要加上可行的獎懲制度控制，項目范圍變更控制流程關鍵任務就會被所有人關注，任務完成情況會很自然的實時反饋回來，這些獎懲制度要包含明確的工作內容、責任人、時間要求、指標要求、獎懲方式和獎懲額度等。

3.2真誠溝通助力控制共識。在合同實施的全過程中，項目組一定要把溝通文化列入首位。將項目所有的干系人均納入范圍，尤其要注重與客戶方代表的溝通。溝通過程中的任何需求和變更請求均需認真記錄，列入參考或范圍備檔。項目組以例會的方式對記錄的需求進行全員評審，強化項目的目標感。項目組對變更請求的確認要謹慎，通過與客戶方交流澄清變更細節，分析相應變更的必要性。并能針對需求進行目標偏移及影響程度分析、項目變更影響、解決變更請求的條件、相應時間、成本費用等，以便達到可接受的共識，實現共同的業務目標和各自的業績目的。

3.3對用戶方的建議。信息系統集成項目成本控制對項目實施雙方來說，特別是對信息系統集成項目范圍的理解上常會存在著利益沖突關系，因此用戶在控制信息系統集成項目范圍時要注意切實把握好關鍵業務的范疇，控制信息系統集成項目的成本，還要注意結合自身內部資源的問題，考慮好內部的管理成本。實施信息系統集成本身是一項高管理成本的項目，如果信息系統集成項目范圍本身控制不當，很容易造成無形的內部管理成本的巨大消耗，而在實際的管理效益上獲得的收益卻不高，在這種低的效益/投資比下，無疑是一種不可取的項目管理方向，因此，用戶進行信息化項目管理的時候，要站在中立客觀的立場上分析范圍的“度”，采取適度則取，過度則收的原則。

參考文獻

[1]崔文曉，董火民，田青.信息系統工程范圍管理關鍵策略探討[J].信息技術與信息化，2007，4：100-102

[2]楊侃等.項目設計與范圍管理[M].電子工業出版社，2008

第4篇：項目變更管理流程和方法范文

在目前這種經濟大環境下，誰能夠適應這個快速變化和高要求的外部環境，誰就是勝者。

對業務流程管理(BPM)的重要性，很多企業都已經不再懷疑。于是有了諸多業務流程管理的工具、咨詢公司存在?？墒谴蠹以趨f同做業務流程管理項目或業務流程管理日常工作時，發現即使花了很多精力，可這些事情做起來還有些力不從心。

比如有一家企業，投資了很多精力金錢去做業務流程管理。當流程梳理完以后，有了短暫的“甜蜜期”――覺得很有成就感?？墒钱敇I務流程發生變更的時候，他們就發現由于流程的性質和優先級互不相同，需要通過的審批路徑也各不相同。一旦有了流程變更的需求，他們需要先進行人工討論這個流程應該經由什么職位審批，再去執行流程的變更。

因此，面對外部快速變化和高要求的環境，企業的業務流程管理也面臨諸如效率等問題的挑戰。對于組織結構簡單的企業而言，對業務流程管理本身的管理可能要求不那么高，但是對于大多數需要緊跟信息時代步伐以保持競爭力的企業而言，做任何事情無疑都講求效率――這當然包括我們做業務流程管理本身。

BPM管流程，誰來管BPM?其實，業務流程管理本身也是有流程的。業務流程管理人員一直在著眼于如何設計出更優更高效的流程來為業務服務，他們也跟實際業務人員一樣，也需要引入一些能夠幫助其提高效率的方法來保證業務流程管理本身的質量。

比如一個企業的質量管理部門要修改ISO程序文件，這就涉及到修改流程。而這些流程修改的審批過程除了涉及質量管理部門，可能還涉及到流程關鍵部門、相關部門以及企業管理層等，與此相關的各審批層之間的有效協調有可能比流程本身的邏輯更加復雜。而審批過程如果每次都讓質量部門的人員去思量應該讓哪幾個部門審批，就會出現流程管理本身的混亂和不可控。因此他們需要引入一個系統以及一套事先定制化的審批模式，幫助企業將審批模式和各部門之間協調的思路落實到一個工具后，幫助其應對修改和的工作。

從業務流程管理項目本身來說，對于做業務流程管理項目的咨詢公司也好，客戶方的關鍵用戶也好，不外乎就是兩個目標――控制項目成本，讓項目成果發揮最大效益。對于控制項目成本，項目經理每天睜開眼睛想的第一件事情就是協調――讓項目成員和客戶關鍵用戶配合，各司其職以保證項目進度，卻又不至于讓項目成員累得抱怨連連。這個目標其實關鍵在于項目經理是否能保證每個項目成員各司其職。而讓項目成果發揮最大效益的方法也是保證其更新和維護的有效性。

但是，目前不管是業務流程管理項目還是業務流程管理的日常工作，大部分企業的業務流程管理的流程基本不被記錄存檔，沒有控制手段，沒有改進措施。

作為企業，如果已經具備了業務流程管理的超前意識并在付諸行動，卻因為對業務流程管理項目本身疏于管理，從而導致后期流程管理體系的問題，確實是非常遺憾的。如前面所提到的，業務流程管理針對的是前端運行的業務流程(如圖1中的銷售處理、采購等)，因此，業務流程管理流程(流程戰略、設計、實施和控制)本身的治理和管控也應該像運行業務流程一樣受到重視。

筆者遇到的客戶中也有一些注意到了這方面的問題，并在嘗試利用OA等工具進行管理，卻未得到很好的效果，這些客戶也在關注市場上是否會出現這方面的專業工具。而就筆者所知，目前專門針對“業務流程管理”的管理，IDSScheer公司的ARIS業務流程治理引擎(ARIS Process Governance)應該算是做的比較全面的。作為一個從事流程管理20多年的企業，從對運行業務流程的關注到對流程管理本身的關注，將業務流程管理起來的同時，也體現了對流程管理精益求精的態度。這個治理引擎涵蓋了很多人機交互(即是手動步驟)的內容，通過業務流程管理自動化把相關業務流程管理的流程從業務層面，提升到IT管理層面，并在軟件工程層面集成后放在一個工具里。因產品時間較短，筆者作為目前國內為數不多的試用者之一，在這里為大家做―個分享。

設計好了BPM管理流程后，它就可以為我們的BPM管理服務了。假設我們要做一個模型變更，需要做審批。我們可以先設計好模型變更的審批模式，審批中的界面、通知郵件的文本等內容都可以通過ARIS來定義。基于BPMN語言，可以將描述好的流程模型轉化為BPMN模型，從而達到執行所設計的BPM管理流程的目的。也就是說，我們將模型變更審批模式中的所有元素都使用EPC模型描述后，即可轉化為可執行的工作流。

轉化后，維護在人員信息中的郵箱地址將會收到登陸流程管理面板的登錄名和密碼，我們就可以登錄到流程管理面板中去查看我們需要管理的任務了，見下圖3。

從上面描述的例子中我們可以看出，ARIS業務流程治理引擎其實就是用來將業務流程管理的流程自動化的工具，這個工具可以幫助設計業務流程管理流程，并將這些靈活的流程自動化。這就意味著：流程架構師基于新的需求去設計新的業務流程管理流程，而不需要IT部門的任何幫助，新設計的業務流程管理流程就能夠實現自動化并且立即投入使用。在這一瞬間，新設計的并且自動化的業務流程管理流程就能滿足新的業務需求。

第5篇：項目變更管理流程和方法范文

關鍵詞 軟件配置管理；軟件生命周期；KCFlow

DOI DOI： 10.11907/rjdk.162381

中圖分類號： TP301

文獻標識碼： A 文章編號 文章編號： 16727800（2017）002002603

0 引言

隨著軟件規模的日益增大，軟件復雜度逐步提高，軟件產品處于不斷更新變化中，為了確保整個軟件項目生命周期內產品的完整性、一致性和可追蹤性，必須對軟件進行配置管理。

軟件配置管理（SCM，Software Configuration Management）指標識和確定軟件系統配置項的過程，在軟件系統的整個生命周期內控制這些項的投放和更改，記錄并報告配置的狀態和更改要求，驗證配置項的完整性和正確性[1]，通常包括配置標識、配置控制、配置狀態記錄、配置審核等活動。軟件配置管理是整個軟件開發生命周期中一個非常核心的管理過程，貫穿了從需求分析、架構設計、項目管理、開發、集成及測試的全過程，可以有效管理配置項版本，記錄配置項開發過程，保證軟件質量，提高軟件重用率。

在軟件開發這個龐大而復雜的過程中，涉及到各方面人員，產生許許多多產品。由于規程過于繁瑣，手工方法實施軟件配置管理是難以想象也是不可能的，因此，有效的軟件配置管理需要結合工具來實現。使用軟件配置管理工具，可以確保軟件項目中基線和配置項隨時保持條理清晰，迅速找到工作產品，保證工作產品的版本、內容不會出錯，提高管理水平。

1 工具介紹

軟件配置管理工具KCFlow采用C/S架構，以軟件配置管理項的版本管理為核心，具有軟件配置策劃管理、變更控制、產品一致性管理、軟件問題追蹤管理、軟件配置審計管理等功能，實現了對配置管理工作的全流程、全方位支持。

KCFlow具有以下特點：C/S軟件架構使項目中的各類人員可以在工具提供的平臺上分布式工作，確保各項工作有序、規范地實施；具有策劃配置項標識功能；支持獨立的配置項，單獨策劃入庫、出庫和更動審批，能夠自動按照策劃結果實施入庫、出庫和更動控制；支持基線的多版本管理功能；支持用戶自定義軟件問題類別、問題級別、更動類別等，以適應不同的使用需求；支持多個軟件開發人員在線提交軟件入庫申請、出庫申請、更動申請等。

2 軟件配置管理

軟件配置管理是CMM重要的過程域，本文結合配置管理工具給出配置管理實施方法。

項目啟動后，配置管理組根據項目情況策劃配置管理活動并建立配置管理系統。首先制定配置管理計劃，根據計劃建立配置管理系統，通過版本控制、變更控制、基線管理和配置審核等方法，對配置管理系統中的工作產品實施控制和監督。軟件配置管理流程如圖1所示。

圖1 軟件配置管理流程

2.1 配置管理計劃

經過批準的軟件配置管理計劃是實施軟件配置管理活動的依據[2]。在進行配置管理前應根據項目的具體情況制定軟件配置管理計劃，內容包括：

（1）確定配置管理機構和人員職責，審批流程。組織機構主要有軟件配置控制委員會、軟件配置管理組。軟件配置控制委員會負責出入庫控制、變更及基線的建立和；軟件配置管理組負責相關制度的建立和維護、工具的推廣、培訓和技術支持、配置管理審核等。

（2）描述具體配置管理活動，包括標識要納入配置管理的配置項，規定提交時間、確定項目研制各階段的基線、基線建立的時機和配置管理項等。配置項根據控制力度分為基線配置項和非基線配置項兩類?；€配置項一般包括軟件研制任務書、軟件需求規格說明、設計說明、設計文檔、測試文檔、代碼、用戶手冊等；非基線配置項包括計劃類文檔、開發環境、會議紀要等。標識配置項為每個軟件配置項賦予唯一的標識符。在軟件開發生存周期中，軟件配置項標識應包括文檔標識、程序標識和數據標識等[3]。

（3）確定更動申請流程及更動申請方法。

（4）描述配置管理報告內容、報告時機、報告人和通告對象等。

（5）制定配置審核時機、審核內容及審核問題的解決方法，軟件配置管理所使用的工具、技術和方法。

使用KCFlow配置管理平臺，制定配置管理計劃，并依據配置管理計劃實時自動化約束配置管理活動，客觀記錄配置管理活動。KCFlow可對配置管理計劃中的機構組織、基線、基線下包含的配置管理項、工作產品標識、問題類型、問題來源、更動流程、修改類別、項目基本信息等進行配置策劃。一般基線策劃有3條：功能基線、分配基線和產品基線。配置項標識應按照相關的配置項標識規范進行，一般文檔、程序標識采用以下格式表示：文件名稱英文縮寫 V主版本號.次版本號；問題類型可分為程序、文檔、數據庫等；問題來源有計劃、方案、設計、編碼、數據庫、測試、使用和維護等。

2.2 配置管理系統

配置管理計劃經過評審后，由配置管理員依照配置管理計劃建立開發庫、受控庫和產品庫，對庫結構進行策劃，明確基線內容，定期備份配置管理庫，為相關人員分配權限并發送用戶帳號信息單給相關人員。

開發庫、受控庫和產品庫應獨立管理。開發庫存放開發過程中需保留的各種信息；受控庫存放已通過評審且作為階段性產品的軟件配置項；產品庫存放已定型（鑒定）供交付生產、檢驗驗收的軟件配置項。在KCFlow中創建受控庫一般包括功能基線、分配基線、產品基線及非基線配置項。功能基線包含軟件研制任務書等文檔；分配基線包含軟件需求規格說明、接口需求規格說明等文檔；產品基線包含軟件設計說明、接口設計說明、軟件測試說明、軟件測試報告、固件保障手冊、源代碼、目標碼、軟件版本說明、軟件研制總結報告、軟件配置管理報告、軟件質量保證報告等；非基線配置項主要包含計劃類工作產品。

2.3 配置控制

配置控制是配置管理的組成部分，包含評估、協調、批準/拒絕、配置項的變更[4]。配置庫建好后，配置管理員按照配置管理計劃進行日常的配置管理活動，主要包括版本控制、變更控制、基線管理等。

2.3.1 基線管理

基線是軟件生命周期中各開發階段的一個特定點，它的作用是把開發各階段工作明確劃分，使本來連續的工作在這些點上斷開，以便于檢查和肯定階段成果[5]，是進一步開發的基礎。

在軟件生命周期中主要有3種基線：功能基線、分配基線和產品基線。功能基線是開展軟件研制工作的依據，一般是在軟件研制任務書評審并納入受控管理后建立；分配基線在軟件需求規格說明評審并納入受控管理后建立；產品基線在產品后建立。

基線包含的配置項全部入庫后才可建立基線，配置管理員提交《基線建立和申請單》，通過軟件配置控制委員會審批通過授權后，方可建立和基線。基線后，配置管理員要把基線的結果通告給相關人員，通告內容包括基線名稱和標識、所包含的配置項及配置項版本等信息。

對基線的變更需要通過正式的變更流程來完成。首先提出變更請求，然后進行變更評估，變更批準后再進行變更。變更評估包括：軟件變更分類、技術影響分析、接口影響分析、進度及預算影響分析。

2.3.2 變更控制

對已進入受控庫和產品庫的任一軟件配置管理項的更改，要履行規定的申請和審批手續。配置管理工具KCFlow提供了兩種更動流程供選擇，一般采用的更動流程是：填寫問題報告、提出更動申請、更動出庫、實施和驗證更動和更動入庫，具體更動流程如圖2所示。

（1）發現問題，并填寫《問題報告單》。變更人發現問題后首先填寫問題報告單，在問題報告單中詳細描述問題，說明問題來源并對問題進行分析，確定問題類型。

（2）提出更動申請，填寫《更動申請單》?！陡鼊由暾垎巍芬敿毺顚憜栴}來源、問題類別、問題級別、更動類型和修改類別等，描述更動方案、影響域分析及驗證辦法，待更動申請批準后方可進行更動。

（3）更動出庫。更動申請通過審批后，更改實施人填寫《更動出庫單》，審批通過后，檢出待更改的配置項準備實施更動。待更改配置項出庫后，處于待更動狀態，禁止其他人使用。

圖2 更動流程

（4）實施和驗證更動。更動出庫后可由變更實施人對待更動配置項實施更改，并請同行專家驗證變更結果。驗證結果合格后將變更后的配置項更動入庫，如果驗證沒通過，則重新實施更改。

（5）更動入庫。更動完成并通過驗證后，變更實施人填寫《更動入庫申請單》。審批通過后，將更動后的配置項更動入庫。

2.3.3 版本控制

版本控制是全面實施軟件配置管理的基A，其目的是按照一定的規則保存配置項的所有版本，避免發生版本丟失或混淆等現象，保證產品的可追溯性[6]。對配置項在初次完成時確定初始版本，在每次更改后確定新的版本。版本號由主版本號和次版本號組成，當發生更改時，若變動較大，次版本號加0.1，若變動較小，次版本號加0.01。

2.4 配置管理記錄和報告

配置狀態記錄和報告通常稱為配置狀態紀實。配置狀態記錄主要對配置管理活動進行記錄和報告，一般包括以下內容：配置項紀錄（名稱、標識和版本）、變更紀錄、基線紀錄、出入庫紀錄、審核紀錄、備份記錄和測量信息等。

配置管理工具KCFlow可以根據配置庫中的內容生成配置狀態報告，確保配置管理報告和配置管理庫的客觀一致性。在項目每個階段結束時，配置管理員從KCFlow導出該階段的配置狀態報告，總結該階段的配置管理活動，統計配置管理相關數據，并將配置狀態報告發送給相關人員。

2.5 配置審核

配置審核是一種軟件驗證方法，其目的是檢查軟件產品和過程是否符合標準和規程，是變更控制的補充。配置審核包括功能配置審核、物理配置審核和管理配置審核。

功能配置審核一般由項目經理審核配置項的實際功能特征是否達到功能基線文檔中所規定的要求。物理配置審核是通過對配置項的檢測，鑒定文、圖、物的一致性，保證軟件更改的完整性。配置管理組定期（每季度）進行配置管理審核。配置管理審核主要是對配置管理過程進行審核，確認配置管理記錄和配置項是否完整、一致和準確。審核過程中，相關人員按照審核內容形成《配置審核檢查單》，對不符合項進行記錄和處理。

KCFlow具有靈活的配置審核功能，能夠策劃適合本單位的軟件配置管理審核準則。每次入庫時，相關人員進行物理審核，在基線建立及變更時進行功能審核。

圖3 配置審核策劃

3 結語

軟件配置管理貫穿整個軟件生命周期，在軟件開發過程中采用有效的工具進行配置管理，能夠彌補人工管理出現的紕漏，規范開發流程，保證軟件產品質量，減少軟件缺陷，縮短軟件開發周期，降低軟件維護成本。本文結合配置管理工具，對軟件配置管理流程及實施方法進行了研究。為提高軟件開發的效率與質量，今后的工作中應結合項目實際情況及本單位的配置管理相關規定，對配置管理工具的適應性進行研究，以滿足各種軟件開發要求。

參考文獻：

[1] 石柱.軟件工程標準手冊[M].北京：中國標準出版社，2007.

[2] 何新貴，石柱，王緯，等.GJB5000軍用軟件能力成熟度模型實施指南[M].北京：國防工業出版社，2004.

[3] 王忠貴，劉姝.航天型號軟件工程方法與技術[M].北京：中國宇航出版社，2015.

[4] 董越.未雨綢繆理解軟件配置管理[M].北京：電子工業出版社，2012.

第6篇：項目變更管理流程和方法范文

關鍵詞：建設單位；合同變更；高效審核；方法；措施

引言：合同變更關乎合同結算乃至項目竣工決算和國家驗收，是投資管控的重點和難點，如何順利推進和完成合同變更工作，確保投資管理合理得當，是業主投資控制的重難點，同時也是促進工程順利實施的關鍵。

一、加強合同變更管理的意義

（一）合同變更管理是投資管控的重難點

合同變更是投資控制體系中極其重要的管理環節，是投資概算控制的重要指標和投資控制成效的評估要點，合同變更是結算辦理的前提條件，關乎最后的工程決算和國家驗收。隨著建筑市場的不斷規范化和參建各方地位趨于合理，施工合同的承包方式根據內外部形勢變化不斷調整，逐步放開單價包干形式，合價包干項目相應減少，合同變更數量整體上而言較前有所增多。而且由于不同階段實行不同承包方式，合同變更原則有差異，對合理理解、嚴格把控不同的變更原則，達到變更審核的合規性，合理性提出了很高要求。

（二）合同變更越來越成為政府部門審查、審計和監管的重點

近年來，隨著建設市場整體環境的逐步規范化和法制化，政府有意識地加強對市政投資項目的監管，對合同變更審查不斷深化、細化，審計要求也越來越高。尤其是合同變更是否成立，是否合理合規，成為審點。隨著政府對合同變更的介入程度和管控力度漸強，也增加了對外的協調工作和辦理時間。合同變更受政策環境和政府行為影響越來越大。

（三）理順合同變更有利于促進工程和諧建設

合同變更及時、順利的辦理，是變更款項按時支付到位的前提條件，同時可促進結算辦理，保證合同尾款盡早支付。對解決合同對方資金壓力、保證工程建設積極性，促進合同正常履行，維護業主的履約信譽，推動參建各方和諧、互信建設工程具有現實意義。

（四）合同變更管理透明化有利于降低廉政風險

嚴密的合同變更管理體系，明確的審核原則，透明的審核要求，將有效杜絕審核人員以個人經驗和理解自由裁量合同變更，降低廉政風險。

三、加快合同變更辦理、提高合同變更審核質量的一些想法

（一）建立合同變更管理流程一體化

為解決方案變更、設計變更和合同變更管理流程缺乏統籌考慮的問題，通過促進設計、方案管理部門與合同管理部門之間的鏈接，使成為一個較為緊密的整體，達到變更管理流程一體化，提高合同變更辦理的效率和質量。

（二）提高合同變更管理精細化水平

為解決承包商和業主對支持材料要求標準不統一的問題，通過細化合同變更支持材料要求，使承包商在準備支持材料時更加有的放矢，業主審核時有統一的標準作為審核依據，促使變更審核更加透明化。減少審核人的自由裁量權，降低廉政風險，提高合同變更管理精細化水平。

（三）提高合同變更首次申報資料質量

基于政府部門審計和監管的不斷深化、細化，對合同變更材料填寫提出更高要求。通過規范變更表格的填寫要求，使支持材料能夠全面真實反映合同變更的合規性、合理性，達到合同變更審核的深度，提高合同變更審核效率。

（四）優化合同變更審核流程

合同變更集中審查的管理模式提高了審核質量。但同時帶來了審核效率不高的問題。通過研究現有合同變更管理制度，在風險可控情況下，優化部分流程，提高變更審核效率。

（五）建立各部門嚴格、明確的審核時限約束機制

通過建立明確的各部門變更審核時限，如果超時，將被嚴格考核，達到提高合同變更辦理效率目的。

（六）提升合同變更信息管理水平

如果合同變更信息管理還是依靠人工登記，存在信息零散、不方便跟蹤查詢的缺點。導致變更信息的缺失和管理工作的被動和滯后，影響變更辦理進度和管理效率。加快完善建設管理信息系統，提高合同變更信息管理化水平，方便合同變更審核的跟蹤和檢查，增強建設投資管控力度，提高合同管理前瞻性、敏感性。

四、加快合同變更辦理、提高合同變更審核質量的五項具體措施

（一）以合同變更精細化管理為突破口，提升合同管理水平

1.使合同變更辦理流程完整、清晰

通過繪制合同變更流程圖詳細展現一個合同變更從啟動到結束的全部環節，并標注各環節工作重點及應注意的事項，指導合同變更辦理。提醒承包商、監理、項目部重視方案變更、設計變更資料的完整性、有效性，減少因合同變更前端資料不完整、不規范引起的退單，提高變更審核效率。

2.編制針對具體變更類型的支持材料清單

由于不同變更原因對應的支持材料不同，針對每類的變更原因，分別給出變更審批的材料明細要求及材料提交的時段。使各審核環節經辦人員遵循同一標準以達到有效縮短審核時間的目的，變更審核更加透明化。承包商也可依據支持材料清單提早準備資料，加快承包商上報進度。支持材料要求會隨著政府審核要求及技術支持接口等條件的改變，合同變更支持材料亦隨之動態更新。

3.制定規范的變更支持材料填報模板

對常用的變更表格編制填空式模板，承包商只要根據模板要求填空，就可以將本次變更的招標階段情況、施工圖情況、變更原因，變更依據合同條款、變更支持材料組成、工程量審核情況、變更金額等情況說明清楚。達到全面反映變更情況、滿足變更審核深度的要求，減少中間重復解釋環節，提高變更審核效率的效果。同時反促監理、項目部提高變更審核質量。

4.確立變更審核時限要求

確定變更審核環節合理審核時限，經分析，承包商上報時間長的原因：（1）是承包商在正式申報合同變更申請之前，與監理單位及業主會先有一個溝通過程，其中包括一次或多次各方參加、不同等級的合同變更審查會議，這個時間段短則半個月長則兩個月；（2）普遍存在因資料不全而被退回的合同變更申請反復申報的現象，這個時間段短則幾天長則半年都有； （3）業主對變更上報時限無明確規定，承包商自由空間大。（4）變更工程施工完成后才上報合同變更。通過減少開會審查環節、統一變更支持材料清單，加快承包商變更上報進度。通過建立各部門審核時限，提高變更審核效率。

（二）簡化合同變更審核流程

針對變更原因清晰、變更依據明確、支持材料齊全，風險可控的合同變更，可以加大授權、分散審查，減少集中開會審查環節。

（三）建立部門疑難雜癥例會制度

為了及時解決合同管理過程中的疑難問題，統一普遍問題的審核標準，可以實行疑難雜癥例會制度，對合同辦理過程中的疑難問題、普遍問題集中審議。較好彌補由于個人力量薄弱、專業知識有限造成遲遲難以決策的不足。

（四）提升合同變更信息管理水平

通過合同信息平臺上合同變更的規章制度、范本，建立各類管理臺帳。加強與管理部門的有效溝通。提高變更審核效率。

（五）廣泛開展合同變更管理知識培訓

廣泛開展合同管理培訓。組織部門積極參與、充分交流和溝通。承包商、監理可以并對合同管理、變更審核工作提出寶貴建議。通過系列培訓提高各業務部門合同變更管理的重視程度。合同管理工作的改進更加有的放矢。

第7篇：項目變更管理流程和方法范文

【關鍵詞】 電力建設 工程變更 影響 問題 管理控制

在電力建設項目開始立項規劃后，就需要進行招標以選擇最合適的建設施工單位，并與其簽訂項目承包合同。而工程變更正是合同制定中需要重點考慮的重要內容，其直接關系著電力建設項目的成本控制、質量控制以及進度控制。若在合同中沒有對工程變更進行詳細的約定，就很容易在實際工程變更發生出現經濟利益沖突，而使甲乙雙方出現矛盾，嚴重影響電力建設的順利實施，也不利于按時保質的完成建設項目。一般引起工程變更的主要因素有兩大類，一類是諸如設計期間沒有做好實地勘察，而使得工程施工情況與設計圖紙情況存在差異，不得不進行工程變更的主觀因素，二類是諸如自然變化或社會環境變化所引起的客觀因素。

1 工程變更對電力建設項目的影響

1.1 工程投資方面

電力建設項目本身就是一個需要較大資金投入的工程項目。若在項目實施過程中不嚴格按照設計規劃的要求進行施工，反而需要進行工程變更，就會進一步增大工程投資成本，不利于工程造價的控制和管理，會給投資方帶來較大的經濟損失。

1.2 工期方面

在具體的電力建設項目實施過程中，對于施工工序的要求較為嚴格，若前一道施工工序因為某種原因而耽誤了進度，就會迫使后面所有的施工計劃都隨之延遲推移，嚴重影響了施工的整體進度。因此，當出現工程變更的情況時，就會使將正常的施工進度計劃安排全部打亂，從而引發一系列的不良后果，不但會使工程延期，還極有可能會增大工程造價。

1.3 項目管理方面

在原本井然有序的項目施工管理中，若頻頻出現有工程變更情況，就會使項目管理人員難以按照原定計劃進行管理控制。例如業主和監理部門之間的有序協調管理狀態會被打亂，施工方對現場管理的難度也隨之增大。當出現工程變更時，需要召開相關部門的技術人員開會來研討具體的變更方案，還要重新進行勘查設計，并需要再次組織施工，分配人員等等，這些都會使項目管理中的質量管理、進度管理和成本管理受到極大的影響。

1.4 勞動生產率方面

當工程發生變更時，施工作業的順序就會被打亂，經常會出現加班施工，或短時間歇工的現象，使得勞動力資源得不到合理的安排，這樣就會使極大的降低勞動生產率，增大人力成本。

1.5 索賠和合同糾紛

由于工程變更具有很大的不可預測性，很多時候甲乙雙方在簽訂承包合同時并不能完全將出現工程變更的責任劃分清楚，因此當實際發生工程變更時，就很容易出現合同糾紛，并牽涉到索賠問題。當出現索賠和合同糾紛時，就會激化甲乙雙方之間的矛盾，這對雙方的經濟利益都是非常不利的。

2 目前電力建設項目工程變更管理中存在的問題

為了能夠減小工程變更對電力建設項目的不良影響，提高建設方和施工方的經濟利益，保證電力建設項目庫的安全順利實施，就需要對電力建設項目工程變更實施一定的管理。但是目前我國在電力建設項目的工程變更管理中，卻還存在著一定的問題與不足，具體體現在以下幾點：

2.1 信息化程度較低

受技術限制的影響，我國在處理電力建設項目的工程變更時，一般都還是采用人工作業的方式進行管理，并沒有充分利用當前先進的信息技術。很多文件都是以紙質檔案進行記錄和傳閱，這在很大程度上降低了處理效率，也容易造成信息的丟失。目前我國還沒有建立起一個健全完善的電力建設項目工程變更管理軟件，嚴重影響了管理效率。

2.2 缺乏對工程變更全過程的管控

一般來講，工程變更的控制和管理是需要貫穿在整個工程項目實施全過程中的，但是目前人們普遍將工程變更的重點放在了施工階段，這顯然不是最佳的管控手段。因為施工前期的勘查和設計階段才是控制工程變更的重要階段，施工過程和施工竣工階段都需要根據施工設計來安排作業施工和管理控制。

2.3 工程變更缺乏有效的評審環節

在電力建設過程中，所發生的工程變更大多數并沒有進行相應的評審，尤其是對工程變更方案的技術、成本、工期、安全以及質量等方面沒有進行有效評審。使得有些工程變更后反而成為錯誤變更，或變更效果較差，起到適得其反的效果。

2.4 沒有建立嚴格的工程變更責任追究制

當工程需要發生變更時，勢必是因為某些因素的影響而引起的，大多數情況下，這些影響因素都是有責任人可以追究的。但是由于沒有建立健全的責任追究制，而使得所涉及人員沒有應有的壓力，在設計或施工或管理中都不夠用心，這樣就會很容易引發工程變更，造成變更管理失控。

2.5 合同變更條款設定不夠完善

對于工程變更的管理與控制來講，最有效的控制方法就是在合同中對變更條款做出詳細的約定，并將責任劃分清楚，這樣當出現工程變更時，就可以按照合同約定的要求進行處理，而不至于發生索賠或糾紛。但事實上，很多電力建設項目的甲乙雙方在訂立合同時，并沒有對合同變更條款給予應有的重視。因而造成了很多合同糾紛。

3 如何提高電力建設項目工程變更管理控制水平

3.1 實施工程變更的分類控制

在電力建設項目工程變更的管理實踐中，按照工程變更的性質和費用影響實施分類控制，有利于合理區分業主和監理工程師在處理不同屬性的變更問題上的職責、權限及其工作流程，有助于提高工程變更管理的效率和效益。實施分類控制可把工程變更分為3個重要性不同的等級：即重大變更、重要變更和一般變更。重大變更一般由監理工程師初審、總監理工程師復審，報送業主后，由業主組織勘察、設計、監理審核。重要變更一般由監理工程師初審，總監理工程師批準后實施。一般變更由監理工程師審查批準后實施。

3.2 合理確定工程變更價款

工程變更價款的確定，既是工程變更方案經濟性評審的重要內容，也是工程變更發生后調整合同價款的重要依據。一般情況下，承包商在工程變更確定后的規定時間內，應提出工程變更價款的報告，報監理工程師批準后方可調整合同價款。

國內現行建設工程施工合同條件和相關研究文獻均有關于工程變更價款的確定方法和原則主要有：①合同中已有適用于變更工程的價格，按合同已有價格變更合同價款；②合同中只有類似于變更工程的價格，可以參照類似價格變更合同價款；③合同沒有適用于或類似于變更工程的價格，由承包商提出適當的變更價格，經監理工程師確認后執行；④承包商在雙方確定變更后14天內不向監理工程師提出變更工程價款報告時，視為該項變更不涉及合同價款的變更；⑤監理工程師應在收到變更工程價款報告之日起14天內予以確認，監理工程師無正當理由不確認時，自變更工程價款報告送達之日起14天后視為變更工程價款報告已被確認；⑥監理工程師不同意承包商提出的變更價款，按合同爭議的約定處理；⑦因承包商自身原因導致的工程變更，承包商無權要求追加合同價款。

3.3 實現工程變更管理信息化

我國電力建設項目變更管理信息化尚處于起步階段，而制造業對工程變更管理的信息化研究起步較早。制造業工程變更管理應用系統一般基于產品數據管理系統（PDM）和支持團隊工作的工作流技術平臺開發，實現ECM功能與PDM的集成，以充分利用PDM的產品信息管理模塊和流程管理模塊。制造業有關工程變更管理的概念、模型和方法為電力建設項目工程變更管理信息化搭建了高起點的研究平臺，有助于加速我國電力建設項目工程變更管理的信息化進程，縮短相關應用系統開發周期。

根據實際的工程變更需求，可以將EC過程分解為請求、評估、和實施3個環節。其中：EC請求包括描述問題的癥狀，發出正式的變更請求和提出解決建議方案3個步驟，EC評估包括技術評估、造價評估、工期評估和價值分析4個步驟，EC實施包括矛式的工程變更指令和實施工程信息更改。實現工程變更管理信息化，必須構建以人員組織、變更流程和數據管理3大要素為核心的工程變更管理信息系統。建立以數據管理為基礎，以變更流程為主線的工程變更管理策略是實施有效工程變更管理的關鍵所在。

4 結語

總之，在電力建設的項目管理工作中，必須要對工程變更管理與控制給予一定的重視。從電力建設立項開始就應該加強工程變更預防控制，并在合同中對變更條款作出詳細的約定，劃分工程變更所引起的經濟責任。同時，面對當前我國電力建設項目工程變更管理信息化水平較低這一現狀，還要進一步加強工程變更管理的信息化建設，提高工程變更管理和控制水平。

參考文獻：

第8篇：項目變更管理流程和方法范文

關鍵詞：公路工程；變更；索賠

在高速公路的施工過程中，因為工程變更引發的索賠情況越來越多，正確的對索賠進行管理不僅能夠提高索賠的成功率，保護和維護承包單位的合法權益，也有利于提高承包單位的社會信譽。在公路工程建設當中承包單位如何利用合同條款和權利向業主索取標準以外的額外經濟補償或正常支付后的追加支付，是承包商在施工過程中需要解決的一個重要問題，要想達到索賠的目的，承包商只有熟悉掌握索賠的理由，熟練的運用各種索賠的方法才能達到提高合同管理水平和企業經濟效益的目的。

一、公路工程變更管理中應該注意的問題

在公路工程建設當中，工程設計變更是引起索賠的主要原因，設計上的變更產生的原因主要有以下幾點：合同文件變更、設計方案變更、工程的延期及暫停引起的變更、不可抗拒的自然條件和特殊風險引起的變更等等。雖然引起變更的原因各不相同，但是其產生的后果是一樣的，那就是導致索賠的產生。對于承包商來說這是一個非常嚴肅的問題，關系到企業的切身利益，在工程變更索賠的管理上應該注意一些基本的問題。具體內容如下：

1.公路工程變更的嚴肅性

公路工程建設是一項龐大的復雜的建設工程，業已形成的設計方案如果發生變更，將對整個工程建設的進度與質量造成嚴重影響。不僅如此，設計變更該關系到承包商與業主兩方的直接利益，在工程變更當中應該注意變更的嚴肅性。這就需要施工單位在進行工程變更的時候，要組織技術人員認真分析原圖紙，領會原有設計方案的設計意圖，詳細研究變更以后可能出現的問題，權衡變更與不變更之間的利弊關系。在分析的過程中應該是以能不變就不變、能少變就少變為原則，認真細致地理解合同通用條款及專用條款。保持公路工程變更的嚴肅性。非變不可的情況下，應該嚴格履行變更的手續、程序，要保證變更相關的文字表格、圖標、數字的準確無誤、收集好相關的影像資料。

2.公路工程變更要有預見性

公路建設項目施工從計劃到實施完成，一般會有足夠的施工期，但是一旦發生施工變更將會直接打亂原有的施工計劃，進而影響到施工工期，這將對公路項目建設產生重要影響。這就要求施工單位在施工過程中應該對工程變更有一定的預見性，具體來說就是在單位工程、分部工程開工以前，詳細審核工程設計圖紙，通過分析預測在施工過程中會不會、需不需要進行工程變更，對于可能發生變更的項目，施工單位應該及時立項并準備變更所需的相關材料，準備報批相關手續，變更能發生在施工之前要盡量在施工之前完成，這樣能夠減少變更成本，保證施工進度及工期的計劃要求，同時也能避免很多不必要的糾紛。

3.工程變更的原始記錄及變更組價

由于公路工程施工工期比較長，在施工過程中管理人員因為工作上原因不可避免的發生變化，管理人員的變化可能會影響到變更的完整記錄。這就要求施工管理人員在變更的過程中要建立起完整的記錄，必須按照時間順序或工程項目分門別類的整理歸檔，一旦發生變更管理人員必須做好變更統計臺賬，一旦管理人員發生變化，要及時移交相關的材料和記錄，保證工程變更原始記錄的連續性、完整性。工程變更常常會導致工程量或工程難度發生變化,導致工程投資發生變化進而影響到施工成本。因此，施工單位在工程變更發生后，要及時進行分析，與原設計的工程量進行比較，確定增減量；對工程數量變更比較大的項目，按合同條款的規定進行變更組價，以此作為工程竣工決算的主要依據。

二、工程變更索賠的方法與技巧

工程變更索賠的方法有很多，在實踐當中需要根據變更的時間確定最佳的方法，只有這樣才能達到施工索賠的目的，具體來說應該注意以下幾點

1. 投標階段變更與索賠的方法

投標階段是工程變更與索賠的基礎，投標階段會對工程變更與索賠構成重要影響，既能影響承包人的工程當中的利益，也將影響業主的工程投資總額。一般情況下在投標階段，業主主要是以合同價作為主要考核指標，在投標中也就是總承包價。在這一階段的中是以清單單價計算結果為主要依據，因此在這一階段承包方可以在總價保持不變的前提下，采取分享不平衡報價法，對合同價進行細致的分解，對工程實地進行細致深入地勘察了解，對于施工過程中可能會發生變更、索賠的地方或數量會有所增加的項目單獨列出，在這些項目上適當的提高單價。對于其它發生變更、索賠幾率較小或工程數量有所刪減的項目可以適當的降低單價，達到索賠向投標階段滲透的目的。

2. 進度計劃中的變更索賠方法

一般情況下業主會要求承辦商在簽訂承包合同以后，根據合同的基本要求編制詳細的施工進度、設備、人力、材料、貨幣使用計劃，這些施工計劃一般需要經過監理人員及業主的審查和批準，一旦批準通過以后，該計劃就成為施工單位在施工過程中必須遵守的指導性文件。而這也將成為工程違約索賠的主要依據。為此，施工單位可以根據可能出現的變更與索賠問題，編制超前的施工進度計劃，將征地、拆遷、圖紙的提交,樁號標志的清點等緩解作為重點控制的內容，適當的減少前期作業時間，增強前期施工進度，此時如果某項單項工程因為變更不得不延期的時候，對企業作業項目的影響將會增加，這也有利于施工單位達到索賠的要求。

3. 施工工藝方案實施過程中索賠方法

在這一方面施工單位可以根據合同條款及其它規范性文件的要求，編制詳細的施工工藝方案，該方案需要經過工程師及業主審批，批準以后該施工工藝方案就作為施工過程中的工藝流程指導文件，需要施工單位嚴格遵守。在編制施工工藝方案的過程中，施工單位可以增加一些必要的施工過程，尤其是一些可能出現變更的項目，擴大這些項目的工作流程，在總額相對不變的情況下，提高其單價計算的定額分項，使這些項目的費用相對提高。

總之，在施工過程中變更隨時隨地都有可能發生，成功的索賠在于承包商能夠完整的做好變更記錄，包括施工日讠志、記工卡片、窩工記錄、影像資料等等，收集足夠的變更材料和依據，及時向監理工程師及業主書面報告施工過程中存在的問題，以及需要及時準確地把相關口頭指令轉為書面指令，深入透徹地審閱合同的通用條款及合同專用條款，多了解工程相關的法律法規及相應的司法解釋，掌握好變更索賠的時機，才能提高變更索賠的成功率。

第9篇：項目變更管理流程和方法范文

關鍵詞：電力施工；需求變更；管理策略；控制流程

在電力施工過程中，需求變更的問題是不可避免的，它是通過流程把變更納入可管理的范圍內，避免產生這種混亂，但是如果需求變更的發展失控的話，就會使項目陷入一種混亂且不穩定的狀況，從而嚴重破壞了整個項目的管理過程，如何正確進行需求變更的控制，是一個很重要的管理過程。所以，為了能更好地控制電工管理中的需求變更，我們必須做一些措施來使需求變更有計劃的、有目的、更順暢的進行，從而使電工施工過程進行良好的變更控制。

1 電工施工中引起需求變更的主要因素

在電力施工過程中，引起需求變更的因素有很多，例如增減工程量的清單的內容和工作量，包括施工進度計劃的變動，施工程序的改動，質量標注的調整，技術要求的修改和補充，這些都是在電力施工過程中引起需求變更的因素，可以分為：

1、從需求變更的性質來看，引起需求變更的因素分為主觀因素和客觀因素。

①主觀因素。例如電力設計工作的不細致，從而使工程實施過程中發現了很多在設計文件中沒有考慮到或估算不準確的工程量，致使必須改變施工項目或增減工程量。

②客觀因素。這就是指在電力施工中因為一些自然災害或不可預見的事故、社會因素引起的停工和工期拖延等，這樣的工程變更是不可避免的，也是無法預料到的。

2、從引發需求變更的對象來看，引起需求變更的主要因素

①某些施工單位主動提出工程變更。某些施工單位會向設計單位提出對圖紙、設計說明不明確的問題的詢問，或是提出技術修改圖，對施工方法、施工議案提出修改，或是要求修改圖紙等問題，這些都是施工單位主動提出的需求變更。

②由監理單位提出的工程變更。在電力施工過程中監理工程師要經常在施工現場巡視，憑借著他們自身的豐富實踐經驗，他們往往會發現工程中存在著很多問題，并針對這些問題提出工程變更的建議。

③設計單位提出需求變更。在施工過程中，設計單位或者是其駐工代表對原設計中存在的一些錯、漏、缺、碰等問題，提出一些設計的修改和完善。

④由該工程的業主提出的工程變更。為了更好地完善使用功能，從而保證工程的質量、加快工程進度等原因，在施工過程中，業主時常提出一些工程變更的要求。

在電力施工管理中，由于需求變更會引發工程量現場簽證、設計、進度的變化、合同變化等問題，我們需要對需求變更進行嚴格控制，從而將項目變更的影響降低到最小。

2 對需求變更的控制策略

對于在電力施工過程中，對需求變更的控制，如果僅僅按需求加強監督執行是不夠的，因為這樣的做法會造成項目各方對變更控制的乏力和被動，從而引發工程質量、工程成本等一系列問題的產生，甚至可能使在發展中發生變更失控的現象，這是要絕對避免的。要想在電力施工管理中，使需求變更得到控制，就要確定一個選擇、分析和決策的流程，使所有的需求變更都要遵循和支持改流程，從而通過這個流程對需求變更進行控制。但是在遵循這個流程中還需要注意幾方面的問題：

1、要有明確的授權。在電力施工管理之前，要事先明確工程各方有權提出變更申請的人員和有權受理變更的人員，決不允許未授權的人員進行私下協商，只有這樣做才可以對需求變更有整體的控制。

2、對需求變更進行必要的審核。對電力施工管理中的需求變更不是所有的變更都要執行和立刻執行，審核的目的是決定是否需要變更和何時變更。

3、評估變更的代價和影響。在電力管理中的需求變更都是有代價和影響的，所以在確定變更之前，必須事先評估變更所帶來的代價和影響，使工程雙方了解了變更的后果之后，再一起做出判斷和認可。

4、要嚴格執行需求變更的管理流程。小的變更也會引起變更最終的不可控制，所以小的變更也要進行正規的需求管理流程，并且施工單位要嚴格避免在變更確認之前，要按變更設想進行施工，否則可能會造成需求變更的整體失控。

3 需求變更的控制流程

在電力施工管理中，需求變更控制的主要手段是要明確定義流程并且可以嚴格的執行，主要分為提出、評估和實施的三個步驟。首先，要由授權的人員進行提出需求變更，無論是哪一方提出的需求變更，都要履行工程變更的手續，并以書面形式交給總監。其次，要由總監召集專業的建立工程師來進行審查，認為可行后，設計單位根據業主要求的設計變更進行設計，變更要求必須以書面形式給出，然后設計單位簽署意見和設計出圖。設計單位完成施工圖的設計后，業主需要把圖紙給專業的職能部門和審圖機構審核，審核通過交還業主，再由業主組織設計、施工、監理各方一起對圖紙進行會審，盡可能地把存在的問題提出來，進行研究和探討，并由設計單位做出解答，形成文字資料后作為日后施工的依據。最后要由總監給出確認后的工程變更通知后，才可以交由施工單位進行執行，按照施工圖進行施工。

需求變更實施之前，是要經過工程各方的審核、評估和確認的，在進行電力實施過程中要跟蹤與驗證，確保變更的正確執行，在變更實施的整個過程中，在沒有拿到工程變更通知前任何一個步驟出現異議，整個流程都要重頭開始，并且施工單位也不會進行施工，這樣是為了確保整個需求變更始終是可以控制和管理的。

4 應注意的問題

目前，很多企業都在遵循質量與健康、安全和環境管理體系的互相補充、相輔相成，在電力施工過程中，他們為了在需求變更中遵循質量、安全和環境管理的一體化，為了更好地實施“ISO9000質量管理體系”和“HES-MS”的管理，他們將“ISO9000-QMS”、“HSE-MS”、“ISO14000-EMS”整合成一個系統，但是在具體操作中會遇到很多問題：

1、對“ISO9000質量管理體系”和“HES-MS”的管理范圍必須明確劃分，對于它倆的共用文件和資料應按所屬管理的范圍劃分到所屬的系統中，對影響二者的的文件應確定與“HES-MS”的接口，制定出明確的管理文件。

2、機構要統一，發揮資源優勢。很多企業把質量、安全、環保等職能部門都分開屬于不同部門管理，這樣日程工作中協調減少了，增加了管理費用，造成了資源的浪費，因此各個部門機構要配備管理人員，從實際出發，健全管理機構。

3、體系要統一，工作重點要有所側重。針對企業的具體情況，不同性質的企業需要遵循的管理體系是不同的，在電力施工管理過程中，是必須要遵循安全、質量、環境體系的一體化的，從而確保施工過程都有序進行，保障勞動者的安全和健康，實現經濟效益、社會效益和環境效益的統一。

5 結論

在電力施工管理過程中的需求變更的發展如果得不到很好的控制，項目就可能會陷入不能正常進行的狀態，變更的控制對項目正常有序的施工有著重要的影響，所以，如何正確的進行需求變更的控制，是一個重要的管理過程。定義需求變更是保證變更正常有序的一個有效的措施，并且需求變更流程使得變更施工能夠有計劃、有目的地進行，也只有這樣才能對整個施工過程進行良好的變更控制。

參考文獻

[1]范偉健.淺議電力施工管理中的需求變更管理[J].現代企業文化，2010（18）

[2]羅韋軍.淺析電力施工管理中的需求變更控制[J].中國電力教育，2006（5）