保險公司IT變更管理流程設計說明書

1、變更管理流程設計說明書 目錄目錄 目錄目錄.3 1流程目的流程目的 .7 2流程主要內(nèi)容流程主要內(nèi)容 .7 3與其他流程的關系與其他流程的關系 .8 4關鍵角色、職責定義關鍵角色、職責定義 .8 4.1變更請求者.8 4.2變更主管.9 4.3變更經(jīng)理.9 4.4變更委員會變更委員會（cab） 、緊急變更委員會 e 變更委員會（cab）.10 4.5變更實施人員.11 4.6變更管理流程負責人.11 5執(zhí)行原則執(zhí)行原則 .12 5.1常規(guī)原則.12 5.2流程關聯(lián)原則.12 5.3變更實施記錄原則.13 5.4變更分類執(zhí)行原則.13 5.5審批上報原則.13 5.6所有權原則.13 5.7變更

2、通知原則.13 5.8緊急變更處理原則.13 5.9變更測試原則.14 5.10變更文檔控制原則.14 6流程相關定義流程相關定義 .14 6.1變更信息項.14 6.2變更來源.19 6.3變更類型.19 6.4變更是否中斷業(yè)務.20 6.5變更是否需要測試.20 6.6風險等級.20 6.7變更所屬系統(tǒng)類型.21 6.8變更分類.23 6.9是否啟動總公司審批或備案.24 6.10變更狀態(tài).24 6.11回顧代碼.27 6.12變更結束代碼.27 6.13變更實施單信息項.28 7流程概要設計流程概要設計 .28 7.1緊急變更子流程.31 8流程詳細設計流程詳細設計 .32 8.1（40

3、0.1）變更發(fā)起.32 8.2（400.2）直管領導進行需求審批.33 8.3（400.3）檢查、測試和計劃.34 8.4（400.4）評估審批.36 8.5（400.5）變更委員會（cab）評估審批.37 8.6（400.6）總公司審批.38 8.7（400.7）收集審批意見.39 8.8（400.8）安排和分派任務.40 8.9（400.9）實施變更任務.41 8.10（400.10）回顧變更.42 8.11（400.11）關閉變更.43 9關鍵衡量指標關鍵衡量指標 .44 1綜述綜述 1.1 設計設計目的目的 本文檔是在cf 保險股份有限公司信息技術管理制度 v1.1基礎上，結合 cf

4、保險股份有限公司信 息技術部維護管理的特點，制定的變更管理流程詳細設計文檔。本文檔的目的是： 規(guī)范所有 it 變更，從而保證由于變更而引起的對生產(chǎn)的影響降到最小，提高 it 系統(tǒng)和服務的質(zhì) 量，為業(yè)務的快速發(fā)展提供更優(yōu)質(zhì)的 it 服務 指導與 it 變更的相關人員有一套規(guī)范的流程去執(zhí)行變更 指導 it 管理平臺項目的建設 本文檔是依據(jù)目前 cf 保險股份有限公司的信息技術日常運維狀況而制定的，以后進一步的更新和優(yōu) 化將由 cf 保險股份有限公司信息技術部負責。 1.2 適用范適用范圍圍 本文檔作為本次項目的變更管理流程詳細設計的交付物，讀者對象為與變更管理流程相關的所有技 術與管理人員。 1.

5、3 相關相關術語術語 itil（基礎架構庫 it infrastructure library ） 是英國政府在 1987 年制定的有關 it 服務管理的方法論，現(xiàn)已成為事實上的 it 管理標準。 服務臺（helpdesk） 服務臺從根本上來說是提供了用戶和 it 部門的唯一接口。此項功能常通過集中方式提供服務。服務 臺的根本目的是提供初始支持，并通過變通方法、解決方案或升級到二線支持等手段幫助用戶恢復到正 常工作狀態(tài)。 事件管理（ incident management） itil 流程之一，事件管理負責解決所有的 it 事件、問題和用戶請求。它的目的是盡快恢復被中斷或 受到影響的 it 服

6、務，所以它的特點往往是以解決表征現(xiàn)象為目的，而不在于查找根本原因。 問題管理（problem management） itil 流程之一，問題管理負責解決重大緊急事件或具有相同癥狀的一組事件。它的目的是找出事件 的根本原因，并通過解除該根本原因從而防止類似事件的再次發(fā)生。同時問題管理流程也負責預防事件 的發(fā)生。 配置管理（configuration management） itil 流程之一，配置管理負責描述，跟蹤和匯報所有 it 基礎架構中的每一個設備或系統(tǒng)的管理流程。 這些設備和系統(tǒng)被稱為配置項(ci) 。每一個 ci 必須有效管理，跟蹤和控制以支持公司的 it 服務和基礎 設施成功運行。

7、 配置管理數(shù)據(jù)庫（cmdb - configuration management database） 是在配置管理流程中用于記錄企業(yè)所有 it 相關配置項信息及其相互關系而建立的數(shù)據(jù)庫。 變更管理（change management） itil 流程之一，變更管理通過控制和管理 it 相關的變更， 使變更對生產(chǎn)環(huán)境可能的影響和風險降到 最小，從而提高 it 環(huán)境的整體穩(wěn)定性。 2變更管理流程設計變更管理流程設計 2.1 流程目的流程目的 變更管理流程將通過標準統(tǒng)一的方法和步驟來管理和控制所有對 it 生產(chǎn)環(huán)境有影響的變更。主要的 目的包括： it 部門可以管理和引導用戶變更需求部門可以管理和引

8、導用戶變更需求 通過對所有變更的正確評估，可以維護通過對所有變更的正確評估，可以維護 it 生產(chǎn)環(huán)境的完整性生產(chǎn)環(huán)境的完整性 變更和變更實施得到正確記錄，并提供審核統(tǒng)計變更和變更實施得到正確記錄，并提供審核統(tǒng)計 減少或消除由于變更實施準備不當?shù)仍虺霈F(xiàn)的對減少或消除由于變更實施準備不當?shù)仍虺霈F(xiàn)的對 it 環(huán)境的破壞作用環(huán)境的破壞作用 提高資源使用率提高資源使用率 2.2 流程主要內(nèi)容流程主要內(nèi)容 變更管理流程始于變更的接收，結束于變更的實施和回顧。該流程包含下述主要內(nèi)容： 提出變更請求（提出變更請求（rfc） 、評估、分類、評估、分類 變更申請人提出變更請求（rfc） ，由變更主管負責檢查和

9、完善其內(nèi)容，通過查詢配置管理數(shù)據(jù) 庫，進行風險等級的初步評估；并盡量提出可能與業(yè)務發(fā)生的關聯(lián)的影響，已供決策參考。變更主 管并對變更進行分類；如為緊急變更，則按照緊急變更子流程執(zhí)行；如為簡單變更，直接制定變更 計劃，并安排實施。 變更主管負責組織制定變更計劃、測試變更主管負責組織制定變更計劃、測試 變更主管安排并協(xié)調(diào)相應資源制定變更計劃，包括實施計劃、測試計劃、回退計劃、配置項更 新計劃等。應安排對實施計劃和回退計劃進行測試，隨后將測試結果、實施計劃、回退計劃、配置 項更新計劃等提交給變更經(jīng)理審核。 變更經(jīng)理評估、審批變更經(jīng)理評估、審批 變更經(jīng)理接受變更請求（rfc） ，如果確定是緊急變更，則

10、快速完成評估、審批。對標準變更， 確定變更風險等級，審閱變更實施計劃、測試報告、回退計劃和配置項更新計劃，批準或駁回變更 申請，如需要更高級別管理層的審批，則根據(jù)不同風險級別報批。 變更委員會（變更委員會（cab）/緊急變更委員會（緊急變更委員會（ec）評估、審批）評估、審批 變更經(jīng)理將根據(jù)特定的變更請求成立特定的變更委員會（cab）/ec，成員包括對該變更的評估 和批準提供應有附加價值的技術人員和管理人員，審閱工作包括變更的風險、對現(xiàn)有服務的影響、 實施計劃、回退計劃和配置項更新計劃等，并做出批準與否的決定。如為緊急變更，則快速完成以 上評估、審批。 管理層審批管理層審批 對于風險等級為“重

11、大”的變更，在變更委員會審批通過后，必須再由變更經(jīng)理報請至管理層 審批。 協(xié)調(diào)變更實施協(xié)調(diào)變更實施 變更主管負責協(xié)調(diào)資源，準備實施前相關工作，組織人員按計劃實施變更，變更主管監(jiān)控實施 過程和結果，并在必要時進行協(xié)調(diào)或做出決定 。在這階段可能需要變更經(jīng)理和變更委員會成員的 幫助。 回顧和關閉回顧和關閉 實施變更后，變更主管確保配置項及時得到更新，并協(xié)同變更經(jīng)理負責從技術、管理、業(yè)務角 度去回顧變更，確保變更請求（rfc）得到了預期效果，并尋找改進機會或行動計劃，在回顧過程 中可能會需要得到變更委員會中相關領域的技術人員的幫助，隨后更新變更記錄并關閉變更請求 （rfc） 。 2.3 與其他流程的關

12、系與其他流程的關系 變更管理流程可以從其他的服務管理流程接收到變更請求(rfc)。 和配置管理流程的關系和配置管理流程的關系 變更管理涉及到的配置改變應當在配置管理數(shù)據(jù)庫中得到體現(xiàn)，改變的數(shù)據(jù)可能包括配置項、 配置項間的關系或配置項的某些屬性 ； 變更的評估需要從配置管理數(shù)據(jù)庫中獲取相關的信息進行分析。 和事件管理流程的關系和事件管理流程的關系 事件的解決涉及到需要對基礎架構、應用系統(tǒng)及操作系統(tǒng)等進行變更的需要觸發(fā)變更管理流程 來實現(xiàn)，變更成功實施后應當通知事件管理流程。 和問題管理流程的關系和問題管理流程的關系 問題管理流程中對于錯誤的修正涉及到需要對基礎架構、應用系統(tǒng)及操作系統(tǒng)等進行變更的

13、需 要觸發(fā)變更管理流程，變更成功實施后應當通知問題管理流程。 2.4 關關鍵鍵角色、角色、職責職責定定義義 流程的實現(xiàn)是通過不同的流程角色以及其所賦有的職責來實現(xiàn)的，因此流程的每一個角色可以被定 義為一系列職責的集合，在實際的管理操作中，不同的人員將被賦予不同的職責，也可能一個人被賦予 多個職責。 變更管理流程的角色為：變更請求者、變更主管、變更經(jīng)理、變更實施人員、變更委員會 cab/緊急 變更委員會 ec、變更管理流程負責人。以下描述每個角色的職責。 2.4.1 變更請求者變更請求者 根據(jù)工作的需要，發(fā)起變更請求的 it 人員，主要負責： 必要時提出變更申請，創(chuàng)建變更請求（rfc） ，并提交

14、給相關技術領域的變更主管 在變更處理過程中提供必要的信息 技能要求：技能要求： 了解對于所處業(yè)務需求與環(huán)境 了解所處的 it 生產(chǎn)環(huán)境與組織結構 了解 it 技術架構從而可以向變更主管、變更經(jīng)理詮釋所提及變更對于運行的影響 人員安排說明：人員安排說明： 所有 it 維護人員 2.4.2 變更主管變更主管 變更主管通常由與變更請求內(nèi)容相關的具體技術領域的負責人擔任。可以根據(jù)不同的變更種類，分 派不同的人員作為變更主管。對于某些重要變更，還可以將變更主管和變更實施人員合并在一起；變更 主管主要關注在實施方案、詳細實施計劃等方面。 職責：職責： 檢查由變更申請人提交的每一個變更請求變更請求（rfc）

15、 ，檢查變更的正確性和必要性，必要 時拒絕無關、無法實施或沒有必要的變更請求 確定和檢查變更請求（rfc）的分類、變更時間要求、分析風險等 作為具體變更的項目經(jīng)理，負責領導變更的構建測試，實施和參與回顧 制定變更實施計劃、測試計劃、回退計劃等 針對具體變更請求，評估并分派相應資源 確保變更在預定的時間，資源和成本內(nèi)完成 在必要時，確?；赝擞媱潱╢allback plan）得以正確實施 負責收集與該變更有關的部門或小組的意見，綜合變更對于應用的影響 技能要求：技能要求： 充分了解 it 生產(chǎn)環(huán)境的結構 了解公司組織結構和業(yè)務與客戶之間的關系 較強的技術背景，項目管理技能 分析能力 以用戶為導向、

16、良好的溝通能力 人員安排說明：人員安排說明： 通常由負責具體技術領域的人擔任，如負責 8 版系統(tǒng)的人、分公司負責某一分公司系統(tǒng)的人、 負責網(wǎng)絡方面的人等 2.4.3 變更經(jīng)理變更經(jīng)理 變更經(jīng)理全面負責變更管理流程中的所有具體活動執(zhí)行，保障所有變更依照預定流程順利執(zhí)行。通 常由具有決策權的人員擔任。 職責：職責： 幫助變更主管協(xié)調(diào)必要的變更時間、人員等方面的協(xié)調(diào)工作 審批變更請求，確保只有授權和必要的變更才被實行，并使該種變更影響最小化 成立變更委員會，并領導和主持變更委員會(變更委員會) 定期召開變更會議，回顧變更 參與流程評估，對流程改進提出意見和建議，與流程負責人共同制定流程改進建議 技能

17、要求：技能要求： 在信息技術部門的足夠級別 (鑒于變更經(jīng)理的工作職責包括主持變更委員會（cab）會議、與 管理層交互、駁回不合理變更請求以及對于變更流程的運行進行指導等，所以變更經(jīng)理必須在 組織內(nèi)部擁有足夠的權威且受到尊重) 決策力和判斷力 深入了解企業(yè)文化 項目管理技能 有效的會議管理、部門管理和組織能力 充分了解 it 生產(chǎn)環(huán)境、組織結構以及 it 服務對業(yè)務與客戶的影響 以用戶為導向、良好的溝通能力 社交能力和良好的信用，能夠與變更流程相關的角色進行有效地交涉和交流 人員安排說明：人員安排說明： 通常由負責決策權的人擔任，一般為部門相關領導 2.4.4 變更委員會變更委員會 cab、緊急

18、變更委員會、緊急變更委員會 ecab（總公司）（總公司） 變更委員會( change advisory board ， cab)是 it 組織中對變更進行評估和決策、批準或者拒絕某 個變更請求的虛擬組織。 職責：職責： 針對具體變更請求，評估潛在影響和風險，并分派相應資源 協(xié)助變更經(jīng)理對變更做出審批、決策 參加變更委員會會議和緊急變更委員會會議 回顧失敗或重大的變更，以確保今后不再發(fā)生類似情形 回顧已執(zhí)行的重大變更，確保滿足變更的目的 對流程改進提出意見和建議 技能要求：技能要求： 足夠的權威 充分了解生產(chǎn)環(huán)境結構 it 組織結構 充分了解公司組織架構和業(yè)務與客戶的關系 技術背景和洞察力 分析

19、能力 以用戶為導向、良好的溝通能力 社交能力和良好的信用，能夠與變更流程相關的角色進行有效的交涉和交流 業(yè)務需求的了解 人員安排說明：人員安排說明： 變更委員會是由總部信息技術中心的管理人員組成的虛擬小組。主要由各相關領域的領導、各 個 it 維護小組的資深人員或者組長組成，有時也會包括發(fā)起變更請求的業(yè)務部門的代表、第三 方廠商集成商等參與。變更委員會應當由該專業(yè)有較高技能的人員組成，同時，這些成員對于 業(yè)務需求、業(yè)務邏輯、it 系統(tǒng)技術、應用開發(fā)、測試、支持等方面也較為熟悉。 注：緊急變更委員會通?？梢詫儆谧兏瘑T會的一個子集，擔當緊急變更委員會（ecab）的職責。分公司沒 有變更委員會，只

20、有總公司有。 2.4.5 變更實施人員變更實施人員 變更實施人員負責變更在生產(chǎn)環(huán)境中的實施，實際情況下現(xiàn)場廠商經(jīng)常參與變更實施過程，其責任 包括： 協(xié)助變更主管制定變更實施方案、變更實施計劃 記錄變更實施相關的信息，確保文檔的完整性 負責實施和測試 變更完成后，進行監(jiān)控，并記錄監(jiān)控結果 與變更主管溝通，通報變更實施的進度和結果 技能要求：技能要求： 充分了解生產(chǎn)環(huán)境的 it 架構，是某一領域的技術專家 充分了解公司的組織架構和業(yè)務與客戶的關系 較強的學習、溝通、協(xié)調(diào)能力 分析能力 人員安排說明：人員安排說明： 由 it 部門人員擔任，及運維廠商人員 2.4.6 變更管理流程負責人變更管理流程負

21、責人 流程負責人通過從宏觀上監(jiān)控流程，來確保變更流程被正確地執(zhí)行。當流程不能夠適應公司的情況 時，流程負責人必須及時對此進行分析、找出缺陷、進行改進，從而實現(xiàn)可持續(xù)提高。 職責：職責： 確保變更流程能夠取得管理層的參與和支持 確保變更流程符合公司實際狀況和公司 it 發(fā)展戰(zhàn)略 總體上管理和監(jiān)控流程，建立變更流程實施、評估和持續(xù)優(yōu)化機制 確保變更流程實用、有效、正確地執(zhí)行，當流程不能夠適應公司的情況時，必須及時對此進行 分析、找出缺陷、進行改進(比如增加或合并流程的角色)，從而實現(xiàn)可持續(xù)提高流程效率 保持與其他流程負責人的定期溝通 技能要求：技能要求： 深刻理解變更管理流程 能夠很好地理解業(yè)務對

22、于變更管理的需求 對質(zhì)量控制與保障有很深入的了解 有決策權，能夠確保變更管理流程設計要求在變更執(zhí)行中得到貫徹和執(zhí)行 具有良好的溝通技能，能夠取得公司高層的支持，獲得所需資源 人員安排說明：人員安排說明： 通常由總公司負責決策權的人擔任，一般為部門相關領導 2.4.7 實際崗位與方案角色的映射實際崗位與方案角色的映射 變更管理流程變更管理流程 角色角色角色細分角色細分說明說明成員成員 總公司 職責：負責受理與總公司應用系統(tǒng)、 基礎設施等相關的各種變更請求，并 發(fā)起變更 崗位說明：由總公司信息技術部技術 人員擔任，包括總公司服務臺人員 變更請求者 分公司 職責：負責受理與分公司自有應用系 統(tǒng)、基礎

23、設施等相關的各種變更請求， 并發(fā)起變更 崗位說明：各分公司 it 部門技術人 員擔任，包括分公司服務臺人員，對 應崗位包括分公司信息技術部各技術 崗位 基礎設施組 職責：負責總公司小型機、pc 服務器、 存儲設備、網(wǎng)絡交換機、路由器、防 火墻、網(wǎng)絡鏈路等系統(tǒng)硬件及操作系 統(tǒng)、中間件、數(shù)據(jù)庫等系統(tǒng)軟件的維 護變更工作 崗位說明：由總公司信息技術部門各 基礎設施領域維護工作的資深技術人 員或相關處室處長、副處擔任 應用系統(tǒng)組 職責：負責總公司自有應用系統(tǒng)維護 支持工作 崗位說明：由總公司負責各類應用系 統(tǒng)維護變更工作的資深技術人員或相 關處室處長、副處擔任 桌面組 職責：負責總公司桌面維護變更工作

24、 崗位說明：由總公司代理服務處、服 務支持處資深技術人員或相關處室處 長、副處擔任 變更主管總公司 開發(fā)組 職責：負責總公司應用系統(tǒng)開發(fā)、修 改、優(yōu)化工作 崗位說明：由總公司開發(fā)類處室資深 開發(fā)人員或開發(fā)類處室處長、副處擔 任 應用系統(tǒng)組 職責：負責分公司自有應用系統(tǒng)維護 變更工作 崗位說明：由分公司負責各類應用系 統(tǒng)維護變更工作的資深技術人員或分 管領導擔任，對應崗位包括應用管理 崗、地市分公司應用管理崗、數(shù)據(jù)管 理崗 基礎設施組 職責：負責分公司基礎設施（包括小 型機、pc 服務器、存儲設備、網(wǎng)絡交 換機、路由器、防火墻、網(wǎng)絡鏈路等 系統(tǒng)硬件及操作系統(tǒng)、中間件、數(shù)據(jù) 庫等系統(tǒng)軟件）的維護變

25、更工作 崗位說明：由分公司信息技術部門各 基礎設施領域維護工作的資深技術人 員或分管領導擔任，對應崗位包括設 備管理崗、系統(tǒng)管理崗、安全崗、網(wǎng) 絡管理崗、運行維護崗、地市分公司 設備管理崗 桌面組 職責：負責分公司桌面維護變更工作 崗位說明：由分公司負責桌面維護工 作的資深技術人員或分管領導擔任， 對應崗位包括服務支持管理崗 分公司 開發(fā)組 職責：負責分公司自有應用系統(tǒng)的開 發(fā)、修改、優(yōu)化工作 崗位說明：由分公司資深開發(fā)人員或 分管領導擔任，對應崗位包括應用開 發(fā)崗 變更實施人總公司 職責：負責對總公司應用系統(tǒng)、基礎 設施、桌面等方面的變更實施工作 崗位說明：由總公司 it 部門技術人 員及代

26、維廠商組成 分公司 職責：負責對分公司自有應用系統(tǒng)、 基礎設施、桌面等方面的變更實施工 作 崗位說明：由分公司 it 部門人員及 代維廠商組成 總公司 職責：負責督導與監(jiān)控總公司變更流 程的正常運轉，對標準變更進行審批 和對重大變更進行上報等 崗位說明：在總公司設置變更經(jīng)理 1 人，由運行管理處處長、副處擔任 變更經(jīng)理 分公司 職責：負責督導與監(jiān)控分公司變更流 程的正常運轉，對標準變更進行審批 和對重大變更進行上報等 崗位說明：在分公司設置變更經(jīng)理 1 人，由分管基礎設施方面的信息技術 部副總經(jīng)理擔任 變更管理流 程負責人 職責：負責確定管理流程的衡量指標， 從宏觀上監(jiān)控流程，當流程不能夠適

27、應 cf 發(fā)展需要時，流程負責人必須 及時的對此進行分析、找出缺陷、進 行改進，從而實現(xiàn)可持續(xù)提高 崗位說明：在總公司設置變更管理流 程負責人 1 名 說明：說明：變更主管分組可進行擴充，各分公司可將現(xiàn)有分組提交到總公司，由總公司統(tǒng)一協(xié)調(diào)配置 2.5 執(zhí)執(zhí)行原行原則則 2.5.1 常規(guī)原則常規(guī)原則 所有影響生產(chǎn)環(huán)境配置項的變更都必須嚴格遵循變更管理流程 所有的變更請求記錄都應被記錄和追蹤 所有變更實施過程都應記錄在 it 服務管理平臺 應每月產(chǎn)生變更管理報表，對失敗的變更和風險等級重大的變更進行回顧和檢查，以更好地管 理變更流程 應半年對流程進行回顧，回顧內(nèi)容包括流程關鍵衡量指標、流程執(zhí)行效率

28、和流程支持工具的有 效性，以改進變更管理流程 2.5.2 流程關聯(lián)原則流程關聯(lián)原則 和配置管理的關聯(lián) 在制定變更計劃時通過查詢配置管理數(shù)據(jù)庫，評估變更可能影響的系統(tǒng)，制定變更計劃時 需制定配置項更新計劃，變更實施完成后需確保配置項信息及時更新，只有配置項更新完 成后，才能關閉變更請求單 配置項信息的變更需要通過變更管理流程控制 和事件管理的關聯(lián) 解決事件的過程中涉及到需要對基礎架構、應用系統(tǒng)及操作系統(tǒng)等進行變更的需要觸發(fā)變 更管理流程，如果變更管理流程是由事件管理流程觸發(fā)，則事件記錄必須與變更記錄相關 聯(lián) 和問題管理的關聯(lián) 解決問題的過程中涉及到需要對基礎架構、應用系統(tǒng)及操作系統(tǒng)等進行變更的需

29、要觸發(fā)變 更管理流程，如果變更管理流程是由問題管理流程觸發(fā)，則問題記錄必須與變更記錄相關 聯(lián) 2.5.3 變更實施記錄原則變更實施記錄原則 所有變更實施過程都必須記錄在 it 服務管理平臺，以體現(xiàn)出變更實施中的主要執(zhí)行環(huán)節(jié)和執(zhí)行 情況，比如各關鍵步驟的起始時間、結束時間、執(zhí)行人、執(zhí)行結果、異常情況等。具體記錄方 式可采用在該變更請求單上增加填寫信息項，或新增任務單等其他方式，記錄的信息項參見變 更實施單信息項定義 2.5.4 變更分類執(zhí)行原則變更分類執(zhí)行原則 簡單變更采用預授權的方式，由變更主管直接安排實施，并通告變更經(jīng)理 標準變更由變更經(jīng)理總體負責，通過與各相關方面協(xié)同，采取多種方式（例如

30、cab 會議） ，嚴 格管理其計劃、測試、評估、審批、實施 緊急變更提供變更快速實施處理的機制 2.5.5 審批上報原則審批上報原則 風險等級為重大的變更必須提前三個工作日提交總公司審批，變更實施結束以后將變更執(zhí)行結 果上報至總公司備案 省分公司提出的風險等級為高的變更必須提前上報總公司備案 變更委員會負責審批風險等級為高和重大的變更；對于風險等級重大的變更，變更委員會會議 建議部門領導參加，對于風險等級高的變更，變更委員會會議建議維護主管參加 變更經(jīng)理負責審批風險等級為中和低的變更 2.5.6 所有權原則所有權原則 變更主管負責審核變更請求的有效性和正確性，制定相應的變更計劃，并處理各種變更

31、執(zhí)行時 的日程安排和協(xié)調(diào)，必要時可以得到變更經(jīng)理的幫助 變更經(jīng)理負責關閉緊急變更，變更主管負責關閉其他變更 對于不在變更經(jīng)理審批權限內(nèi)的變更，由變更經(jīng)理負責提交至變更委員會審批 對風險等級為重大的變更，在變更委員會審批完成后，由變更經(jīng)理負責提交至總公司審批 2.5.7 變更通知原則變更通知原則 對現(xiàn)有業(yè)務系統(tǒng)產(chǎn)生影響的變更，例如因實施變更而需要停機或者中止業(yè)務，均需在變更執(zhí)行 前提前通知有關人員做好業(yè)務調(diào)整，減少對業(yè)務的影響，待實施完成后再次通告 2.5.8 緊急變更處理原則緊急變更處理原則 緊急變更必須通過 e-mail 等書面方式申請，但可以口頭獲得緊急變更委員會（ec）審批，事 后必須在

32、 it 服務管理平臺補變更申請單及相關測試和審批文檔，其中變更申請單信息項中必須 填寫變更實施記錄、變更測試記錄和變更觀察記錄，這三項內(nèi)容即為緊急變更操作日志 緊急變更應該制定變更計劃，并快速審批和進行必要的評估，實施前需進行必要的測試，測試 需包含完整的測試案例，只有測試成功后方可在生產(chǎn)環(huán)境進行變更。對由于緊急變更而無法完 成的測試應在實施后安排補測 緊急變更委員會（ec）成員一般為公司領導、部門領導，各級主管等管理層人員，為了提高執(zhí) 行效率，需要事先制定緊急變更委員會（ec) 的人員 緊急變更應越少越好，因為它們對業(yè)務的干擾最大，而且有很高的失敗風險 2.5.9 變更測試原則變更測試原則

33、對生產(chǎn)系統(tǒng)進行變更時，需根據(jù)變更的性質(zhì)、影響面等情況在變更請求單中選擇是否需要在測 試環(huán)境進行測試。如果需要，則按照測試計劃進行測試，測試后需有相關測試人員確認并提供 測試報告 2.5.10變更文檔控制原則變更文檔控制原則 變更計劃通常包括實施計劃、測試計劃、回退計劃、配置項更新計劃等 對應用軟件版本上線類的變更，除變更計劃外，還需包括變更功能說明文檔、變更技術說明文 檔、包含完整測試用例的測試文檔，并提供由執(zhí)行測試人員確認的測試報告 對數(shù)據(jù)遷移類的變更，除變更計劃外，還需包括轉換方案，該方案一般包含數(shù)據(jù)轉換策略、數(shù) 據(jù)轉換測試、數(shù)據(jù)備份及恢復方案、數(shù)據(jù)轉換結果核對等方面的內(nèi)容 對總公司要求上

34、報審批的變更，提交的文檔具體內(nèi)容說明如下: 變更總體方案（包括變更原因、變更前后系統(tǒng)拓撲、配置或功能對比、變更總體計劃、具 體方案、進度安排、人員分工、測試標準、風險評估等） 測試報告（提供系統(tǒng)在變更前的測試范圍、測試步驟、測試項目、測試情況等） 變更回退/應急方案 2.6 流程相關定義流程相關定義 2.6.1 變更信息項變更信息項 變更單必須包含如下變更信息項： 序序 號號 信息項信息項 是否必是否必 填填 說明說明 變更發(fā)起時填寫變更發(fā)起人 1 實際請求人信息是 記錄實際變更請求人的信息，包括：姓名、省/分公司、部門、電子郵 件、辦公電話、手機（手工填寫） 2 關聯(lián)的事件單號否如果變更來源

35、是事件，則關聯(lián)到相應的事件單（手工填寫） 3 關聯(lián)的問題單號否 如果變更來源是問題，則關聯(lián)到相應的問題單（由變更請求者手工填 寫） 4 變更來源是參見“變更來源”定義 5 變更簡要描述是簡單描述變更請求（手工填寫） 6 變更描述是詳細描述變更的內(nèi)容（手工填寫） 7 變更所屬系統(tǒng)類型是參見“變更所屬系統(tǒng)類型”定義 8 變更分類是參見“變更分類”定義 9 變更需求單位是兩級目錄樹（省、地市；成員公司、養(yǎng)老金公司） 10 關聯(lián)配置項否記錄出現(xiàn)故障的配置項代碼（手工填寫） 11 附件否上傳附件 12 分配對象是將問題分配到各組變更主管（手工填寫） 變更發(fā)起時，系統(tǒng)自動填寫 序序 號號 信息項信息項 是

36、否必是否必 填填 說明說明 13 變更 id是為每個變更請求分配一個唯一的序列號（系統(tǒng)自動產(chǎn)生） 14 建單人（受理人）是變更請求的記錄人 15 登記時間是變更請求創(chuàng)建的時間（系統(tǒng)自動產(chǎn)生） 16 變更狀態(tài)是參見“變更狀態(tài)”定義 檢查、測試和計劃階段填寫變更主管 序序 號號 信息項信息項 是否必是否必 填填 說明說明 17 風險等級是參見“風險等級”定義 18 變更類型是參見“變更類型”定義 19 所影響的應用系統(tǒng)、部門否 實施該變更將對哪些應用、部門產(chǎn)生影響，用于評估變更（手工填寫） 20 變更是否中斷業(yè)務是參見“ 變更是否中斷業(yè)務“定義 21 變更是否需要測試是參見“變更是否需要測試“定義

37、 22 需通知部門否需要通知的部門名稱（手工填寫） 23 變更計劃否 使用附件形式。變更計劃通常包括變更的實施計劃、測試計劃、回退 計劃、配置項更新計劃等（手工填寫） 24 計劃開始時間是變更計劃開始時間 yyyy-mm-dd hh:mm（手工填寫） 25 計劃完成時間是變更計劃完成時間 yyyy-mm-dd hh:mm（手工填寫） 26 中斷關鍵業(yè)務 1 名稱否 描述該變更所中斷的關鍵業(yè)務系統(tǒng) 1 的名稱，填寫內(nèi)容參見“變更所屬 系統(tǒng)類型”中的子類定義，如“營銷管理”。 （手工填寫） 27 關鍵業(yè)務 1 中斷時長否 描述該變更所中斷的關鍵業(yè)務系統(tǒng) 1 的時長，按分鐘計算。 （手工填寫） 28

38、 中斷關鍵業(yè)務 2 名稱否 描述該變更所中斷的關鍵業(yè)務系統(tǒng) 2 的名稱，填寫內(nèi)容參見“變更所屬 系統(tǒng)類型”中的子類定義，如“營銷管理”。 （手工填寫） 29 關鍵業(yè)務 2 中斷時長否 描述該變更所中斷的關鍵業(yè)務系統(tǒng) 2 的時長，按分鐘計算。 （手工填寫） 30 中斷關鍵業(yè)務 3 名稱否 描述該變更所中斷的關鍵業(yè)務系統(tǒng) 3 的名稱，填寫內(nèi)容參見“變更所屬 系統(tǒng)類型”中的子類定義，如“營銷管理”。 （手工填寫） 31 關鍵業(yè)務 3 中斷時長否 描述該變更所中斷的關鍵業(yè)務系統(tǒng) 3 的時長，按分鐘計算。 （手工填寫） 32 中斷關鍵業(yè)務否描述該變更所中斷的所有關鍵業(yè)務系統(tǒng)名稱。 （手工填寫） 33 關

39、鍵業(yè)務中斷總時長否 描述該變更中斷的所有關鍵業(yè)務系統(tǒng)的時長，按分鐘計算。 （手工填寫） 34 變更測試記錄是描述測試的情況、測試結果（手工填寫） 序序 號號 信息項信息項 是否必是否必 填填 說明說明 同 9關聯(lián)配置項否記錄出現(xiàn)故障的配置項代碼（手工填寫） 序序 號號 信息項信息項 是否必是否必 填填 說明說明 同 10附件否上傳附件 35 變更主管是變更主管姓名（系統(tǒng)填寫） 36 變更實施單位是兩級樹形目錄 37 變更主管接受變更時間是變更主管接受變更請求的時間（條件觸發(fā)自動填寫） 38 是否啟動總公司審批或備 案 否參見“ 是否啟動總公司審批或備案“定義（分公司特有） 需求審批階段填寫變更

40、經(jīng)理 39 變更審批記錄是 記錄變更審批的歷史記錄，包括如下信息：審批人姓名、審批結果、 原因、時間等（手工填寫） 序序 號號 信息項信息項 是否必是否必 填填 說明說明 同 11分配對象是將變更分配到各組變更主管（手工填寫） 審批階段填寫變更委員會 序序 號號 信息項信息項 是否必是否必 填填 說明說明 同 16變更審批記錄是 記錄變更審批的歷史記錄，包括如下信息：審批人姓名、審批結果、 原因、時間等（手工填寫） 實施階段填寫變更實施人 40 派發(fā)變更任務否派發(fā)變更任務給變更實施人員 41 變更實施記錄是用于描述實施時的現(xiàn)場情況（手工填寫） 42 實際開始時間是變更實際開始時間 yyyy-m

41、m-dd hh:mm（手工填寫） 43 實際完成時間是變更實際完成時間 yyyy-mm-dd hh:mm（手工填寫） 回顧階段填寫變更主管 44 變更觀察記錄否描述變更結束后，觀察期間的情況（手工填寫） 45 回顧意見否變更委員會對變更進行回顧后得出的意見（手工填寫） 46 回顧代碼否參見“回顧代碼”定義（手工填寫） 關閉時填寫變更主管 47 變更結束代碼是參見“變更結束代碼”定義 48 關閉人是關閉人的姓名（系統(tǒng)填寫） 49 關閉時間是變更關閉的時間，關閉人手工填寫。yyyy-mm-dd hh:mm 其他 50 備注否留用 2.6.2 變更來源變更來源 變更來源用于區(qū)分觸發(fā)變更的其他流程或需

42、求，以便進行有效地關聯(lián)。 編號編號代碼代碼描述描述 1事件變更來源于事件 2問題變更來源于問題 3配置變更來源于配置項信息的調(diào)整 4其他變更來源于其他方面，如項目建設等 5業(yè)務部門 2.6.3 變更類型變更類型 變更類型用于區(qū)分變更，提高變更處理的效率。 編號編號代碼代碼描述描述 1簡單變更 指頻繁發(fā)生、影響范圍較小、緊急程度較低、實施風險較小（不會帶來重大后果） 、 實施較簡單的變更，如庫表大小的改動，crontab 時間的修改，文件的刪除等。 2標準變更 指涉及影響范圍較大（影響客戶、業(yè)務部門、分公司或者社會影響較大） 、實施風 險較大、實施較復雜的變更。這些變更可以進行充分的計劃和測試。

43、如業(yè)務割接、 機房搬遷、軟件升級等。 （需求審批；上線審批） 3緊急變更 指如果不進行變更，會立即或正在嚴重影響業(yè)務運行、導致嚴重影響服務等級或 者帶來重大影響的變更，應當?shù)玫奖M可能快速的處理，減少流程的復雜性，但是 又要有良好的控制。如緊急事件引發(fā)的緊急變更。 2.6.4 變更是否中斷業(yè)務變更是否中斷業(yè)務 變更可能會引起業(yè)務中斷，需要在變更評估時加以說明。 編號編號代碼代碼描述描述 1是變更會引起業(yè)務中斷 2否變更不會引起業(yè)務中斷 2.6.5 變更是否需要測試變更是否需要測試 變更實施前需進行必要的測試。 編號編號代碼代碼描述描述 1是變更需要測試 2否變更不需要測試 2.6.6 風險等級風

44、險等級 除簡單變更外，變更主管、變更經(jīng)理、變更委員會/緊急變更委員會對標準變更和緊急變更根據(jù)下表 所列的衡量因素來量化評估實施變更可能帶來的風險，該評估結果用于決定是否批準變更，是否需要更 高級別的審批，以及實施完成后的觀察期。該評估由變更主管進行初步評定，再由變更經(jīng)理或變更委員 會進行最終確定。 風險等級量化評估表如下： 衡量因素衡量因素條件條件得分得分 影響一個以上關鍵省或半數(shù)以上省1 影響一個以上省但未達到半數(shù),并沒有關鍵省受影響2 影響一個省的全部用戶3 地區(qū) it 用戶數(shù)量（受到 實施或取消的影響） 影響一個省的部分用戶4 3 個或更多支持小組1 2 個支持小組2 超過 1 人，相同

45、的支持小組3 準備/實施必需的資源 1 人4 衡量因素衡量因素條件條件得分得分 無法測試，變更失敗可能性很高1 能實現(xiàn)部分測試，變更失敗可能性較高2 有成熟的變更方案，變更失敗可能低3 變更成功的可能性 無需測試，變更失敗可能性沒有4 6 天或更長1 2-6 天2 1-2 天3 變更規(guī)劃時間 小于 1 天4 超過 2 小時或在線/服務斷供期1 1-2 小時2 不到 1 小時3 變更實施時間 不到 30 分鐘4 回退時間超過 2 小時1 回退難度中等以上（1-2 小時）2 回退難度適中（1 小時或更短）3 回退時間 易于回退（30 分鐘或更短）4 根據(jù)上表對每個變更進行評估，最終得出風險等級。風

46、險分為四個等級：重大、高、中、低。不同 的風險等級分別有對應的審批級別和實施完成后的觀察期，具體定義如下表： 總得分總得分對應風險等級對應風險等級對應審批級別對應審批級別實施完后的觀察周期實施完后的觀察周期 6 9重大變更委員會、總公司5-7 天 10 13高變更委員會4-5 天 14 17中變更經(jīng)理2-3 天 18 +低變更經(jīng)理1 天 2.6.7 變更所屬系統(tǒng)類型變更所屬系統(tǒng)類型 定義變更所屬的業(yè)務系統(tǒng)。 業(yè)務系統(tǒng)分類業(yè)務系統(tǒng)分類子業(yè)務系統(tǒng)分類子業(yè)務系統(tǒng)分類簡稱簡稱 it 服務管理系統(tǒng)itsm 綜合辦公系統(tǒng)辦公管理 電子郵件系統(tǒng)請?zhí)顚懞喎Q 電子商務網(wǎng)上招聘系統(tǒng)cors 團體年金報表子系統(tǒng)ga

47、rs 財務計算機管理系統(tǒng)claf管理決策 集團財務計算機管理系統(tǒng)gclaf cf 財務報表輔助系統(tǒng)easy- report 大中城市業(yè)績考核分析系統(tǒng)csis 財務分析系統(tǒng)lifa 基礎率分析系統(tǒng)eas 精算系統(tǒng)atms 每日業(yè)務快報系統(tǒng)zhcx 統(tǒng)計信息系統(tǒng)tjxx 審計系統(tǒng)ams 綜合業(yè)務處理系統(tǒng) 7 版cbps7 集團綜合業(yè)務處理系統(tǒng) 7 版nbps 老業(yè)務處理系統(tǒng)obps 綜合業(yè)務處理系統(tǒng) 8 版cbps8 出單管理系統(tǒng)(七版)printpro 檔案影像管理系統(tǒng)cims 單證管理系統(tǒng)cvms 打印管理系統(tǒng)cpms 數(shù)據(jù)清理系統(tǒng)cleaner 投連萬能處理系統(tǒng)ubps 團體年金核心業(yè)務處理

48、系統(tǒng)gaps 中介業(yè)務處理系統(tǒng)abps 統(tǒng)括業(yè)務處理系統(tǒng)unite 再保險系統(tǒng)rbps 健康意外險系統(tǒng)hdps 核心運營 互聯(lián)網(wǎng)銷售系統(tǒng)iss 團體年金大客戶支持子系統(tǒng)gacs 團體年金報價子系統(tǒng)gaps 團體年金銷售支持系統(tǒng)ga3s 個人代理人管理信息系統(tǒng)amis 講師管理系統(tǒng)tmis 會員管理系統(tǒng) 2005 mmis 個人代理人營銷支持系統(tǒng)e-mss 大客戶支持系統(tǒng)anntsuport 網(wǎng)絡查詢系統(tǒng)netquery cf 呼叫中心系統(tǒng)call center 銷售客服 cf 短信系統(tǒng)sms 其他非業(yè)務系統(tǒng)類ots 說明說明：第一層為”其它”的話，分公司可以對其子類可以擴充并提交到總公司，由總

49、公司統(tǒng)一協(xié)調(diào)配置 2.6.8 變更分類變更分類 一級分類一級分類二級分類二級分類三級分類三級分類 服務器 sr小型機（eps） pc 服務器（spc） 磁盤陣列（rad） 磁帶庫（tap） 存儲設備 rd 其他存儲設備（otr） 網(wǎng)絡交換機（swt） 交換機（swt） 光纖交換機（fst） 路由器（rut） 防火墻（frw） vpn 網(wǎng)關（vpg） 安全網(wǎng)關（seg） 鏈路（lnk） 網(wǎng)絡 nw 其他網(wǎng)絡設備（otn） 臺式機（com） 筆記本（ntb） 字符終端（ctr） 終端 tr 圖形終端（gtr） 打印機（prt） 掃描儀（scn） 繪圖儀（drw） 外設（ddv） 其他（sso） 監(jiān)

50、控系統(tǒng)（） 機房（dce） 消防系統(tǒng) 外設及其 他 pr 其他（otr） 自主開發(fā)（sdv） 外包開發(fā)（odv） 應用軟件 app 商業(yè)軟件（frd） 數(shù)據(jù)庫（sdb） 操作系統(tǒng)（ops） 中間件（smd） 軟件 sw 系統(tǒng)軟件 sys 其他（syo） 管理文檔（adc） 技術文檔（tdc） 維護文檔（odc） 工程文檔（pdc） 產(chǎn)品購買合同（pus） 文檔 dc 合同 crt 維護合同（man） 應用系統(tǒng)名稱（api） 應用系統(tǒng)模塊（apm） 應用系統(tǒng) ap 其他應用（apo） 2.6.9 是否啟動總公司審批或備案是否啟動總公司審批或備案（分公司）（分公司） 對風險等級為重大的變更，變更經(jīng)

51、理需啟動總公司審批 對風險等級為高的變更，變更經(jīng)理需啟動總公司備案 編號編號代碼代碼描述描述 1是需要總公司審批或備案 2否不需要總公司審批或備案 2.6.10變更狀態(tài)變更狀態(tài) 變更從提出到最后被關閉，會歷經(jīng)各個階段。變更處于不同的處理階段具有不同的狀態(tài)，需要不同 的角色參與。以下是變更請求從提出、實施到結束的整個生命周期中的不同狀態(tài)： 編號編號代碼代碼描述描述 1已登記變更請求已登記入系統(tǒng)，變更主管還未受理 2接收需求變更主管接收變更申請人的變更請求 3需求審批變更經(jīng)理對變更請求（rfc）進行需求審批 4計劃中 變更主管對變更進行規(guī)劃，檢驗變更單的分類和信息是否正確， 提交必要的變更文檔 5

52、等待審批變更請求提交給變更經(jīng)理或變更委員會、或總公司等待審批 6已批準變更單得到批準（或簡單變更預先批準） 7處理中 變更主管在此狀態(tài)下，進行任務的創(chuàng)建、分發(fā)，變更實施者實施 變更 8已完成變更實施完成，進入觀察期 9關閉變更關閉，關閉變更時需指定關閉代碼（成功，失敗，已取消） 2.6.11回顧代碼回顧代碼 回顧代碼用于描述變更計劃和實施過程的質(zhì)量，以便更好地改善未來的變更。 編號編號代碼代碼描述描述 1實施正常變更實施計劃、操作沒有問題 2計劃不全變更實施計劃有缺陷，不完善 3實施操作有誤變更實施人員在實施過程中操作有誤 4不可預料情況其他不可預料的意外情況，如系統(tǒng)突然無法啟動 2.6.12

53、變更結束代碼變更結束代碼 變更結束代碼用來描述其完結時的不同狀態(tài)。 編號編號代碼代碼描述描述 1成功變更成功完成 2失敗變更不成功，執(zhí)行了回退計劃 3已取消變更因為各種原因被取消 2.6.13變更實施單信息項變更實施單信息項 序號序號信息項信息項描述描述 1實施單 id 為每個變更實施單分派一個唯一的序列號（系統(tǒng)自動產(chǎn)生） 2變更請求單號 該變更實施單所屬的變更請求單號，來源于變更信息項（系統(tǒng)自動關聯(lián)） 3標題 簡單描述變更請求，來源于變更信息項 4實施內(nèi)容 描述變更實施的內(nèi)容（手工填寫） 5關聯(lián)的配置項 變更實施關聯(lián)的配置項信息 6記錄登記時間 變更實施單創(chuàng)建的時間（系統(tǒng)自動產(chǎn)生） 7實施單

54、狀態(tài) 該變更實施單的狀態(tài)，由各省自行定義 8實施人員信息 姓名、手機、辦公電話、郵件地址、聯(lián)系方式、 地域、機構、部門 （手工填寫） 9核查人信息 姓名、手機、辦公電話、郵件地址、聯(lián)系方式、 地域、機構、部門（手工填寫） 10計劃開始時間 該實施單的計劃開始時間（手工填寫） 11計劃完成時間 該實施單的計劃完成時間（手工填寫） 12實際開始時間 該實施單的實際開始時間（手工填寫） 13實際完成時間 該實施單的實際完成時間（手工填寫） 14實施任務記錄 實施任務的工作日志、系統(tǒng)日志（手工填寫） 15核查結論實施任務的核查結論（手工填寫） 2.7 流程概要設計流程概要設計 概要設計流程圖 變變更更

55、主主管管 變變更更主主管管 變變更更委委員員會會 變變更更委委員員會會 變變更更經(jīng)經(jīng)理理 變變更更經(jīng)經(jīng)理理 變變更更實實施施人人員員 變變更更實實施施人人員員 變變更更請請求求者者 變變更更請請求求者者 外外部部流流程程/用用戶戶 外外部部流流程程/用用戶戶 變更請求 變更請求提交人、 服務臺人員 事事件件管管 理理流流程程 問問題題管管 理理流流程程 配配置置管管 理理流流程程 400.1 變更發(fā)起 各類處室、崗位 處長、副處 分公司部門副總 部門分管副總、處 室領導、總公司司 副總、技術資深人 各類處室、崗位 經(jīng)驗豐富人員 400.2 檢查、測試、計劃 401 緊緊急急變變更更子子流流程程

56、 400.7 安排、分派任務 400.8 實施 變更任務 400.3 評估審批 400.4 cab評估審批 400.6 收集、綜合 審批意見 400.9 回顧變更 400.10 關閉變更 簡單變更 標準變更 批準或駁回 風險等級為 重大或高 批準或駁回 駁回批準 簡單變更 緊急變更 非 簡 單 變 更 簡單變更 配配置置管管 理理流流程程 事事件件管管 理理流流程程 取消 400.5 總公司審批分公司 重大變更 分公司內(nèi)風險等級為重大的變更 需提交總公司審批 批準或駁回 問問題題管管 理理流流程程 變更管理概要設計流程圖如下： 序號序號步驟名稱步驟名稱責任人責任人說明說明 400.1 變更發(fā)起

57、變更請求者 變更申請人根據(jù)來自維護自發(fā)或其他 it 人員、項目建設提出的、或 事件、問題、配置管理流程提出的需求，收集信息，跟相關部門或 用戶確認 創(chuàng)建變更請求記錄 初步為變更分配類型、風險等級等 保證變更信息項的完整性和正確性 400.2 檢查、測試和 計劃 變更主管 判斷變更類型，對簡單變更，制定變更計劃，直接轉 400.7 安排和分 派任務 對標準變更，提交本部門變更經(jīng)理，進行需求審批 對緊急變更，確認后立刻提交給變更經(jīng)理按照 401 緊急變更子流程處 理 查詢配置管理數(shù)據(jù)庫 初步評估變更的類型、風險等，必須提出可能會影響哪些業(yè)務系統(tǒng) 和部門，以供決策參考 對標準變更，協(xié)調(diào)資源，制定變更

58、計劃，包括實施計劃、測試計劃、 回退計劃、配置項更新計劃等 實施計劃要求有詳細的操作命令，并包括實施變更的具體時間、操 作執(zhí)行人、核查人以及實施變更后觀察期內(nèi)的監(jiān)控人員等 配置項更新計劃包括配置項屬性和關系的更新等 對變更進行必要的測試，即對實施計劃以及回退計劃進行測試，提 供測試報告，確保系統(tǒng)變更的正常進行及回退的有效性 變更主管將實施計劃、測試報告、回退計劃、配置項更新計劃等提 交給變更經(jīng)理審批 400.3 評估、審批變 更 變更經(jīng)理 變更經(jīng)理接受變更請求，評估和確定變更的類型、風險等級等 審閱所有提交的計劃，包括實施計劃、測試報告、回退計劃、配置 項更新計劃等 變更經(jīng)理將風險等級為重大或

59、高的變更報送變更委員會審批，變更 委員會的成員由變更經(jīng)理確定 變更經(jīng)理可以做出駁回或批準的意見 400.4 變更委員會 評 估、審批 變更委員會 變更委員會由各領域的專家、領導、用戶或相關廠商組成，對變更 實施計劃、測試報告、回退計劃、配置項更新計劃等審閱 變更委員會可以做出駁回或批準的意見 對于分公司的變更如果是重大變更，必須提前至少 3 個工作日報請總 公司審批，轉 400.5 由變更經(jīng)理提交至總公司審批 400.5總公司審批總公司 總公司可以做出駁回或批準的意見 400.6收集審批意見變更經(jīng)理 變更經(jīng)理收集審批意見，駁回或批準變更。對于駁回的變更請求， 可以建議變更主管取消變更或重新計劃

60、等 如果審批意見是批準，轉 400.7 安排和分派任務，并將高風險等級變 更提交至總公司備案 否則，轉 400.2 檢查、測試和計劃，可以取消或重新計劃 400.7 安排和分派任 務 變更主管 變更主管負責日程安排和變更實施人員安排，分派任務給實施人員 提前向相關部門發(fā)出變更通告 如取消變更，也需提前向相關部門或總公司發(fā)出通告 400.8實施變更任務變更實施人員 變更主管監(jiān)控整個變更實施過程 變更實施人員按照實施計劃，在生產(chǎn)環(huán)境實施變更 在必要時啟動恢復計劃 實施完成后，通知變更主管，變更主管需填寫由該變更所引起業(yè)務 中斷的關鍵系統(tǒng)名稱和中斷時長，最多填寫三個關鍵系統(tǒng)的名稱和 各自的中斷時長