1什麼是變更管理？
我們先看看CMII對變更管理的定義吧： “變更管理是變更已發布文檔和數據的閉環過程”。這裡面有兩層意思：
首先，變更的對象是文檔(或數據)，而非實物。我們通常的做法是直接針對“有問題”的實物，這種做法缺少變更的分析與實施方案的確認，採取的措施可能不是針對問題根本原因的解決方案。看似是在解決問題，卻不知不覺帶來新的、更多的問題。
而且，不修改相關的文檔，這個問題還有可能在其它產品或類似產品中出現。只有更新文檔，才能徹底根除這一類問題的發生。
其次，這個閉環過程是一個自我修正的過程，也是一個重要的溝通過程。CMII把變更看出一種特殊的產品開發過程，變更請求就是產品開發的需求、變更的實施方案就是產品開發方案，這個方案同樣需要經歷提出、驗證和發布這個閉環過程，這個閉環確保了結果(變更實施方案)與需求(變更請求)的一致。
變更的過程不是孤立的，受變更影響的信息能否被有效的識別、結構化、關聯和所有(owned)，是變更過程能否快速和高效重要的前提。換句話說，如果產品的信息混亂、無序、不完善，就談不上變更和變更管理，這是因為變更的基礎不存在。所以要提高和改善變更管理，通常從建立產品層級結構(或基線)、建立零件與文檔的命名、編號規則、建立文檔所有權等配置(或構型)管理的基礎業務流程著手。
2變更的種類和來源
變更有好壞之分，糾正錯誤的變更是壞變更，因為持續的糾錯不是持續的改善。真正改進是好的變更，這類變更不是我們的結果和要求不一致，也不是因為之前工作的失誤或錯誤，而是對現有設計和工藝的再提升和再改進，這類變更的唯一目的是真正改進，也就是我們說的好變更。另一類變更是新產品開發的初次發布。
糾錯、改進和新產品開發是變更的三個主要來源。因為變更的對象是文檔或統一的已發布資料庫，所以無論是新信息的初次發布，還是對已發布信息的修改和再次發布，都可以使用統一的變更流程。
有些企業有多個變更流程存在變更流程，原因是缺乏統一配置(或構型)管理流程基礎，沒有統一的信息識別、關聯、結構化和所有的標準，市場與研發脫節、研發與生產製造脫節，生產製造與運行維護脫節，誰都掌握一部分信息，誰都沒有全部完整的信息，可想而知，在這樣的環境中，糾錯的變更將層出不窮。變更流程必須符合整個企業的目標，使用統一的變更流程、實現信息在整個企業的持續一致和持續改善。 換句話說，我們可以使用一套統一的變更流程服務整個企業，貫穿整個產品生命周期。
3變更的生命周期
使用表單發起和控制變更。變更請求首選進入分析階段，在變更 分析階段要做變更的技術評審和變更的成本估算，技術建議，是變更成本估算的依據。如果變更請求獲得批准，則進入變更的實施階段。 變更實施階段需要規劃變更的實施計畫以及變更的生效方式，工程師和設計人員按照變更規劃的要求創建新文檔或修改相關的文檔、數據，並按照文檔發布的流程確認、發布文檔，在實施最後階段還要按照變更實施計畫套用文檔，並按照規定的生效方式在設計或生產等環節導入變更。
當所有需要的工作都完成後，批准的變更請求才能結束。
4閉環變更流程
我們之前已經說到，正確的變更控制流程是一個閉環過程，而且變更的對象是已發布的文檔或文檔庫，這個閉環過程確保整個變更過程的可控和可追溯。
閉環變更流程中有4個關鍵控制點：
第一個控制點，評審和處理變更請求(ECR)，就是批准或否決ECR。
第二個控制點，規劃和實施已批准的變更請求。
第三個控制點，確認變更中將要發布的新的和/或修訂的信息。
第四個控制點，套用已發布的信息。
簡單的講，第一個控制點就是變更做不做？第二個控制點就是變更怎么做？第三個控制點就是具體的變更中文檔的創建、修訂和確認。最後就是套用新文檔進行相關的工作。
這四個控制點同樣適用於新產品的開發環節。
在閉環變更流程中，基線隨著每次新信息發布和已發布信息修訂而更新。4個變更控制點，是整個變更流程的關鍵點。 變更狀態統計也是通過變更控制點，來判斷一個或多個變更的狀態。
5變更控制委員會
變更控制委員會(CCB)的職能與閉環變更流程緊密結合， 通常每個變更都涉及CCB的三個方面職能： 技術評審(費用估算)、商議決定和實施規劃。依據CCB的三個職能，CCB又可分成：技術評審委員會、變更評審委員會(CRB)和變更執行委員會(CIB)。
傳統的配置管理委員會CCB，經常把技術評審與商業決定或詳細實施規劃混淆在一起。這也是產生變更混亂的一個原因，就是職責不清。
技術評審：由受變更影響最高層階文檔的創建者來組織。我們之前提過，變更的對象是文檔，換句話講，變更影響到哪個層級的哪個文檔，那么這個文檔創建者，就是這個變更技術評審的負責人，要給出變更前後技術優劣的分析。能夠這么做的前提是產品信息已經按照要求被識別、結構化、關聯和所有。
變更評審委員會(CRB)，基於技術建議和成本做出商業決定。CRB除了做變更的審批，還需要為閉環變更制定3套標準：
第一，在多個CRB的環境中，如何為不同的ECR分配CRB。
第二，如何區分快速授權變更(fast track)和全流程變更(full track)。
第三，當費用超過多少時，在實施技術分析前，需要CRB的審批。換句話說， 在ECR提交CRB審批之前，解決方案應該已經被驗證，但如果驗證這個解決方案需要一定的費用，而且這個費用超過一定的數額，那么在開始方案驗證之前，需要得到CRB的審批。有些企業有ECR和ECO，將這個過程分解成兩步，其實只要知道之間流程的關係和羅輯，具體的操作和流程設定就容易理解了。
快速授權變更和全流程變更
在這裡我們要解釋一下快速授權變更(Fast Track Change)和全流程變更(Full Track Change)，這兩個概念和分類都是來自於CMII模型，我們在一些PLM軟體的變更流程中也可以看到。
那么為什麼要將變更分為快速授權變更(Fast Track Change)和全流程變更(Full Track Change)，它們在實施過程中的區別有什麼呢？
我們希望創建的閉環變更流程，能夠讓所有的變更，都以可靠和高效的方式進行實施。但因為的我們的資源是有限的，因此我們需要按變更的複雜程度、緊迫性和風險，進行分類並採取相應的措施。在企業中，大部分變更(75%-85%)是相對簡單和低風險的變更，對於低風險的變更，技術評審和CRB的職能，由個人完成，而非正式的CRB，技術負責人被授權批准他們自己的建議，說明他們的實施計畫，並且執行這個計畫，而非有正式的CIB去規劃和實施，這類變更稱之為快速授權變更(Fast Track Change)， 快速授權變更快就快在變更的審批和實施都是由個人完成，而非正式的CRB和CIB。
將變更分為快速授權變更(Fast Track Change)和全流程變更(Full Track Change)的目的是將企業有限的資源用於處理那些少量但複雜和高風險的變更。 判斷變更是否屬於快速授權變更(Fast Track Change)的標準是由CRB制定的，由變更專家I(CSI)實施執行的。具體的原則和標準各個企業有所不同，有些企業將不涉及生產和製造的變更，歸為快速授權變更，有些企業將變更費用低於某個數量的，歸為快速授權變更。這裡要強調一句的是，不論是快速授權變更(Fast Track Change)和全流程變更(Full Track Change)，相關的文檔都需要通過CSIII的審核才能發布和使用。
變更執行行員會(CIB)，規劃和實施已批准的變更 。對於CIB成員來說，面臨的第一個挑戰就是，準確地規定實施計畫中的所有需要完成的任務。其次，就是要承諾完成每項任務的時間表，並在實際實施過程中驗證時間表是否有效。CIB成員要在處理當前工作的同時，確保其他各種不同的工作都能按期完成。
在企業中，技術評審人員通常是直接的設計人員或工程師，他們是文檔或設計的創建者，CIB成員通常是部門經理或負責人，他們掌握資源的實際狀態，制定的變更實施計畫也最為可行。CRB成員通常是企業或項目的決策層。
6三個變更專家的職能
在CMII的閉環變更流程中，有三個變更專家(Change Specialist，CSI，CSII，CSIII)，這三個變更專家分別負責閉環流程的一部分，在主流的PLM系統的變更流程中，都有對應的角色設定。
那么我們來解釋一下這三個專家的職能：
變更請求從發起到被處理(批准或否決)，是變更專家I(CSI)的職能。CSI必須確保每個變更請求(ECR)包含充分的信息，以便變更評審委員會做出恰當的商業決定。這個角色需要同時具備一定的管理和專業技能。
所有的PR和ECR，首先匯總到CSI這裡，CSI要對PR或ECR進行記錄、分類，為每個PR和ECR，並安排給恰當的創建者，做技術評審、並給出技術建議。CSI負責匯總全流程變更的重複性成本和一次性成本。CSI還負責準備CRB的會議議程，並主持CRB會議。
變更專家II(CSII)的職能是，管理已批准變更的執行工作。
CSII負責匯總合併實施相關的ECR，由一個ECN來統一執行。那么，什麼時候可以用一個ECN來執行多個ECR呢？這還是需要基於變更的影響分析，當多個變更影響同一個最高層級文檔時（這個文檔我們也稱之為變更的控制文檔），就可以用一個ECN來實施多個ECR。CSII另外一個職責就是協調CIB制定變更的詳細實施計畫，並分配變更的生效方式。所謂生效方式，就是變更的切入點，這是變更的有一個複雜點，生效方式的種類有按日期、按批次、按序列號或按舊庫存耗盡等方式，究竟該選擇哪一種呢？主要是基於變更的緊迫性、成本費用和對生產平穩性等方面的考慮。這個話題這次就不展開了，想和大家說明一點的是，不管採用哪種生效方式，變更中需要創建、修改和發布的文檔都是一樣的。
變更專家III(CSIII)的職能是，審查變更通知單和發布已更新的文檔。
當文檔按照變更實施計畫都完成創建或修訂後，CSIII負責審核相關的文檔，這裡CSIII原則只做形式的審核，文檔是不是按要求創建、修改、確認，文檔的內容正確性並不是有CSIII負責，如果熟悉CMII標準，文檔的完整性和正確性，是由文檔的創建者和使用者共同負責的。CSIII將新創建或修改的文檔發布後，還負責分發工作授權（工作授權，CMII的六個基本表單之一），相關的部門按照工作授權的內容對實物進行相關的改造、報廢工作。
在CMII的閉環變更工作流程中，所有的工作都是受控的。 針對文檔變更是通過ECR/ECN授權修改的，針對任何實物的修改是通過WA(work authorization 工作授權)授權的，WA中要做的工作在ECN中都有清晰的規定。最後還有完工記錄，這個完工記錄要符合WA的要求，完工記錄也是CMII閉環變更中結果和需求一致的證據記錄。完成工作包括完成工作相關的記錄和表單。
在CMII的閉環變更流程中雖然引入了三個變更專家，但在實際工作中不一定需要三個不同的人來參與，具體是三個人、還是一個人，或者5個、10個人，需要根據企業的規模和實際情況而定，但三個專家的角色、職能和工作次序不能混亂。
7制定變更的實施計畫
實施計畫，是變更實施過程中最重要的部分，然而，許多組織在發布他們變更的時候，卻沒有正式的實施計畫。制定詳細ECN的實施計畫，分成6個步驟，當然也是一個不斷疊代完善的過程，見下圖。
在制定ECN的6個步驟中，第一步就是“定義所有的實施任務”，這裡的任務包含兩大類，一類是針對實物的，一類是針對文檔的。產品的基線是制定變更實施任務的工作框架，我們來看一個例子：通過變更影響分析，變更的可互換性存在於部件2345-1,2345-1下階的多個部件需要更改，也有多個文檔需要創建或修改。下圖方框裡的部件編號，是將被廢棄的部件編號，方框外的部件編號，是新替換的部件編號。
那么，ECN的影響列表，就要包含被廢除和新替換部件和文檔，還要說明被廢除部件的處理意見，這就是變更的影響列表，這裡面所有要做的事情就是變更實施的任務，如果加上時間和任務人，就是變更的詳細實施計畫。下表就是上面實物部件層級的一個轉換。
變更影響列表和產品的基線格式是一致的，在最左邊還是產品的層級，中間是支持文檔，不過分成了新替換和被廢除部件和文檔，還有部件的處置意見。這些所有新文檔創建或文檔的修訂，以及部件的處置工作，共同組成了變更實施計畫中的任務。
8PR、ECR與ECN
PR、ECR和ECN是我們在變更管理中經常用的的幾個表單，但在實際工作中，有經常相互混淆，有的公司所有的變更都由PR發起，有的公司只有ECR或只有ECN，將ECR和ECN合併成一個表單。產生的主要原因是對PR，ECR和ECN的定義和用途不清晰，對變更的流程也有混淆，我們先來看看對PR，ECR和ECN的定義吧:
問題報告(PR)用於定義問題，其他人員可以依據問題報告，重複相同的問題步驟，並準確地復現問題。通常寫問題報告的時候，問題的根本原因或解決方案還不明確。
ECR既闡明問題，和問題的解決方案，也用於發起改進 。使用ECR，定義和驗證PR中問題的解決方案。PR與相應的ECR關聯。所有在PR的流程中，PR的最後的狀態大多不是“關閉/closed”,而是“pending”，PR的結束通常是以ECR的批准作為最終的關閉。
ECN則用於規劃實施已批准的一個或多個ECR。如果ECR和ECN合併，除了將決策和實施混淆了，另一個問題就是顯著降低了用一個ECN實施多個ECR的可能。
我們來看看CMII的PR、ECR的表單模板吧：
PR表單的上半部分，提出問題，說明問題。
PR表單的下半部分，主要是說明問題是怎么驗證和解決的。那么PR審批，批准什麼呢，主要是批准對問題的描述、定義和驗證，以及針對問題的臨時解決方法，最終解決方法就是修改相關設計或文檔，通過ECR提出。
ECR表單的上半部分要包含的內容：
ECR編號，通常來自ECR日誌
變更專家I的接收日期(和登記日期)
申請者姓名 （?）批准的簽名
申請者地址和/或電話
問題說明和需要的改進
申請者建議的解決方案和改進方法(如有)
是否歸類為快速授權變更，是或否？
技術評審和建議的優先權
指定創建者，提供技術評審和建議
變更專家I給創建者分配的任務日期
創建者的技術建議
1.ECR編號，通常來自ECR日誌
2.變更專家I的接收日期(和登記日期)
3.申請者姓名 （?）批准的簽名
4.申請者地址和/或電話
5.問題說明和需要的改進
6.申請者建議的解決方案和改進方法(如有)
7.是否歸類為快速授權變更，是或否？
8.技術評審和建議的優先權
9.指定創建者，提供技術評審和建議
10.變更專家I給創建者分配的任務日期
11.創建者的技術建議
ECR表單的下半部分要包含的內容：
12. 創建者提交技術建議的日期
13. 估算的一次性成本
14. 估算的重複成本
15. 是否需要客戶批准
16. 實施的關鍵時間因素
17. 提供商業決定的CRB
18. CRB成員的實際決定
19. 分配變更的優先權(如果被批准)
20. 否決的原因或需要的具體信息
21. CRB主席的簽名
22. 處理日期
23. ECN編號和生效(如果是快速授權變更)
24. 頁碼
9變更的複雜性
需求管理和變更管理是CM(配置或構型)的兩個重要的方面，如果需求沒有管理好，變更管理很難做好，如果變更流程繁贅、遲緩，又很難保持需求的清晰、簡潔和有效，兩種相輔相成，這也是變更管理的難點。通常我們改善變更和最佳化變更流程的努力和工作是從變更流程之外的需求管理開始的，就是建立規範的需求的識別(identification)、關聯(linked)、結構化(structuring)和所有(owned)的原則和流程，這些都屬於CM的範疇。
CM(配置或構型管理)是產品開發和研製的基礎，因為沒有一套規範的CM，團隊的工作成果很難共享協同，工作成果也很難沉澱積累。 創新很重要，但是積累也同樣重要，如果創新需要靈感和火花，那么積累則更多需要的是方法和流程，這些方法和流程就是構型管理或配置管理。從CMII的角度，CM系統的基礎或根基就是以下這七個方面，基線管理、產品開發流程、命名與編號規則、數據的完整性、驗證和發布流程、變更和修訂流程，以及已製造記錄，我們構型管理或配置管理就是要把這7個方面做好，這是CM的基礎，也是整個企業研發管理的基礎。歡迎拍磚留言，期待您的真知灼見！
