導語：如何才能寫好一篇技術變更流程，這就需要搜集整理更多的資料和文獻，歡迎閱讀由公文云整理的十篇范文，供你借鑒。

篇1

一、變更管理的標準流程

商業(yè)銀行在不斷發(fā)展中，不可避免地會存在各種各樣的變更活動，無論是自行開發(fā)的軟件版本投產(chǎn)，還是修改供應商提供的軟硬件參數(shù)，或是改變系統(tǒng)、網(wǎng)絡部署模式、搬遷機房等操作，如何對以上各類變更活動進行有效管理？一般情況下，建議通過規(guī)范化、標準化變更管理流程的方式，對變更申請、審批、準備、實施等全流程進行精細化管理以減小變更可能引發(fā)的生產(chǎn)事件及對業(yè)務連續(xù)性產(chǎn)生的影響。具體流程如圖1所示。（1）變更申請變更申請作為變更流程的第一步，應由需求方向?qū)嵤┓教岢稣降淖兏暾?，通常要填寫統(tǒng)一的變更申請表并注明申請人、申請時間、詳細的變更需求、原因及內(nèi)容、期望變更完成時間等。對于中高風險變更，需求方還應評估該變更可能產(chǎn)生的影響。最后，變更申請表經(jīng)由需求方的負責人審核后提交給實施方。（2）變更準備實施方接收到變更申請后，根據(jù)變更需求制定詳細的實施方案，內(nèi)容應包括：實施過程的詳細步驟、實施完成的驗證方案、實施不成功的回退方案等。實施方案應由技術部門負責人進行審批。對于中高風險變更，還應由技術專家對實施方案進行評審后提交給管理人員進行審批。（3）變更實施實施部門應安排有經(jīng)驗的技術人員實施變更，實施人員應嚴格按照實施方案實施，并保障雙人操作，一人實施，一人復核。實施完成后，必須認真審核結(jié)果并進行技術驗證。（4）變更反饋變更實施完成后，由需求方進行需求驗證，驗證通過后，應反饋給實施人。對于未成功實施的變更，應及時聯(lián)系實施人，分析變更失敗原因，準備進行下次變更。

對于以上標準流程，還應重點關注以下幾點：（1）準確定義變更風險度不同的變更風險引起的關注程度是不一樣的，對于高風險變更需要各方面的業(yè)務骨干、技術專家，甚至高層領導一同研究實施方案，確認實施步驟。但是對于低風險變更，一個技術人員即可確定如何進行操作。因此，準確定義變更風險度對于提供所需的技術及人力資源極其重要。同時，如果一個高風險變更被定義成了低風險，并未引起大家的足夠重視，則可能會引起重大的生產(chǎn)事故。（2）變更實施時間的選擇對于有計劃的變更，應充分考慮時間安排的合理性，應選擇在基本不影響業(yè)務的情況下實施，例如一些重要柜面業(yè)務系統(tǒng)的變更，為保障不影響正常業(yè)務的開展，應選擇在周末的夜間進行。對于緊急變更，也應盡可能的在滿足時間要求的情況下，選擇在對系統(tǒng)影響最小的時候?qū)嵤缭谡９ぷ魅找獙嵤┚o急變更以解決某個業(yè)務系統(tǒng)的bug，此時，應在該業(yè)務系統(tǒng)交易量最小的時刻進行操作，以防止由于高峰時段業(yè)務的突然中斷而產(chǎn)生巨大影響。（3）高度重視變更審批變更審批決定著做不做變更，以及怎樣做。在變更申請中，需求的審批應在進行了充分的業(yè)務影響分析的情況下完成，以保障變更確實能在風險可控的情況下達到預期目標。在變更準備中，審批者需盡職盡責，嚴格審核實施方案，以保障實施結(jié)果的正確性并保障在產(chǎn)生問題時能及時回饋。對于由方案不完善、不準確這類原因所導致的變更失敗等問題，變更審批人員甚至應承擔比實施方案制定人員及實施人員更多的責任。（4）緊急變更應參照標準流程執(zhí)行對于緊急變更，可通過郵件或電話先進行審批，實施完成后可再按照正式流程進行加補申請。但是對于變更方案的制定、實施及反饋仍需按照標準流程進行，并需要有資質(zhì)的人員進行把關審核，保障緊急變更能以對業(yè)務影響程度最小的形式進行。

二、變更管理中應關注的其他方面

1.建立一套全面完善的制度規(guī)范體系為提高變更管理的有效性，規(guī)范變更的處理流程，合理有效地調(diào)配資源，防范變更風險，建立一套廣泛適用于全行的變更制度規(guī)范體系是不可或缺的。其中，應包括以下強制規(guī)定：（1）各個變更相關部門及崗位的職責；（2）變更各個階段的活動內(nèi)容及相關要求，并細化到針對不同類型、不同風險程度的變更管理，采用不同流程；（3）變更實施方案的編寫要求與具體步驟，比如實施方案中不能含有客戶敏感信息，網(wǎng)絡類實施方案應精確到指令級等；（4）應明確各種例外情況的處理方法，特別是對緊急變更要給出一套行之有效的流程方案。通常，變更管理作為一個單獨完整的制度被提出，但有時可能也與問題管理、事件管理等IT服務共同組成一套體系規(guī)范。

2.培訓的重要性在變更管理的過程中，加強人員培訓是必不可少的關鍵環(huán)節(jié)。不論是對制度規(guī)范的理解，還是技術水平的提高，都應該有規(guī)劃、有組織地進行系統(tǒng)化的培訓。同時，還應進行安全意識的培訓，重點關注變更管理中的安全方面，例如保護客戶信息敏感性的重要性，關注生產(chǎn)環(huán)境與測試環(huán)境的網(wǎng)絡隔離、防止變更人員的客戶端感染病毒等。

3.對變更的審計為保障變更管理按照制度流程執(zhí)行的規(guī)范性，需要指定專人定期對變更進行審計。審計主要關注以下方面：（1）變更申請、準備、審批、實施、驗證、反饋等各環(huán)節(jié)的合規(guī)性；（2）變更實施方案的質(zhì)量，包括生產(chǎn)變更方案是否細化到指令級，應急方案和回退方案是否具有可操作性，變更內(nèi)容是否符合變更需求，變更實施方案是否審批到位等；（3）緊急變更流程，重點審計變更實施未經(jīng)任何形式的審批，也就是未經(jīng)變更流程實施變更，這種情況極易產(chǎn)生生產(chǎn)事件，對于這種情況，審計程序應先找到發(fā)生變更的事實，可通過信息系統(tǒng)日志記錄，然后從中去尋找是否有變更申請，是否有未經(jīng)過變更審批就進行操作實施的不符合項。需要注意的是，變更審計人員應保持獨立性，不能執(zhí)行自己所參與變更的審計任務。此外，變更審計結(jié)果應引起各級領導的高度重視并積極加以整改。

篇2

關鍵詞：醫(yī)院信息系統(tǒng) 信息系統(tǒng)項目變更管理

中圖分類號：F062.5　文獻標識碼：A

文章編號：1004-4914(2011)09-233-01

隨著新醫(yī)療改革的進行，醫(yī)院面對的市場競爭日益激烈，各大醫(yī)院為了降低成本，提高效率，紛紛采用信息技術來加強醫(yī)院管理，各種醫(yī)院信息系統(tǒng)項目紛紛上馬。但目前醫(yī)院信息化建設項目管理大致狀況是不太遵循項目管理的標準，項目管理水平低下，特別是在醫(yī)院信息系統(tǒng)項目初期雖能制定詳細的項目計劃，但在項目實施過程中要么拒絕項目變化，要么隨意項目變化，由此帶來了醫(yī)院信息系統(tǒng)項目的變更管理問題。

一、醫(yī)院信息系統(tǒng)項目變更的原因與形式

1.醫(yī)院信息系統(tǒng)項目的變更原因。由于醫(yī)院信息系統(tǒng)項目面臨的內(nèi)外環(huán)境不斷變化，形成了醫(yī)院信息系統(tǒng)項目變更的多方面原因，如醫(yī)院信息系統(tǒng)項目合同內(nèi)容不完整、客戶要求修改工作范圍、客戶的功能需求改變、項目進度延期或提前、項目預算增加或減少、國家的醫(yī)療政策發(fā)生改變等等。

2.醫(yī)院信息系統(tǒng)項目變更的形式。醫(yī)院信息系統(tǒng)項目的變更形式有三種：項目內(nèi)容的減少，如項目客戶需求變少、如項目范圍縮小、項目有的內(nèi)容不需要等等。項目內(nèi)容的轉(zhuǎn)換，如項目一部分內(nèi)容由新的內(nèi)容取代。項目內(nèi)容的增加，如項目范圍擴大、項目需求增多等等。不論醫(yī)院信息系統(tǒng)項目變更屬于哪種原因與形式，都會對項目的進度、成本、風險、質(zhì)量和合同等產(chǎn)生影響。

二、醫(yī)院信息系統(tǒng)項目變更管理的對策

1.事前對醫(yī)院信息系統(tǒng)項目中的可能變更進行預測。在醫(yī)院信息系統(tǒng)項目的評估階段，項目經(jīng)理可以依據(jù)個人的項目管理經(jīng)驗，或公司既往的醫(yī)院信息系統(tǒng)項目管理成果來對項目中可能出現(xiàn)的變更進行預測，預測主要可以從以下三方面人手：服務提供商可能出現(xiàn)的變更。硬件產(chǎn)品供應商缺貨導致的變更。另外，醫(yī)院信息系統(tǒng)項目組也可以聘請專家對項目可能出現(xiàn)的變更進行評估，對項目變更進行有效的指導。客戶在需求方面可能的變更。

2.確定醫(yī)院信息系統(tǒng)項目的變更流程?？蛻籼岢鲠t(yī)院信息系統(tǒng)項目變更請求時，項目成員必須向項目經(jīng)理報告，由項目經(jīng)理來處理。通常處理項目變更的流程分為以下幾步：評估。設立醫(yī)院信息系統(tǒng)項目變更管理機構。對項目中的變更進行評估，評估內(nèi)容包括是否屬于變更、變更對項目的結(jié)果、時間進程、預算的影響等。項目變更在軟件上主要是軟件內(nèi)容和技術變更。對硬件來說，市場價格、時間變化是造成項目變更的主要原因；對軟件來說，項目變更的主要原因是技術難度、新功能需求等。分析和處理。對醫(yī)院信息系統(tǒng)項目變更的分析和處理，可根據(jù)項目變更對項目影響的大小靈活掌握。對項目影響小的變更，可以不追加費用，但一定要讓客戶明白我們作了讓步，并犧牲了利潤。這樣做是為了使小的變更不至于影響項目的進展。但對大的變更，醫(yī)院信息系統(tǒng)項目經(jīng)理一定要堅持重新談判、重新審定時間、預算、人力資源的成本。一些軟件項目增加功能時，看上去提高了項目的完美度，實際上卻不容易完成。在增加功能時，一定要認真評估項目在技術、時間、成本和可操作性上的難度。最好的辦法就是把增加的部分從原項目中分離出來單獨立項，這樣不至于影響到原項目的時間進程和驗收、收款工作。規(guī)范醫(yī)院信息系統(tǒng)項目變更的流程。處理醫(yī)院信息系統(tǒng)項目變更的過程一定要規(guī)范。要制作項目變更確認書，由雙方合同負責人和項目負責人簽字。附在原有合同后面。合同書要寫明，涉及項目變更的應以變更書為準。這對按時收款極為有利。項目變更中的時間進程和成本一定要重新核算。并交與客戶簽字確認。如項目變更中遇到系統(tǒng)擴展或人員調(diào)整等情況時，要注意代碼管理、文檔管理和人員管理等。要加強對軟件工程師的管理，提高他們的變更管理意識，改變技術人員輕視成本費用重視技術的習慣。驗收時，要由客戶重新確認。規(guī)范化的流程帶來標準化的服務，一且客戶認識到這樣的好處。最后雙方都會感到滿意，項目也就能順利進行。不斷總結(jié)提高。項目變更的原因、變更的方法和經(jīng)驗教訓要及時總結(jié)和整理，并把這些資料記錄存檔，為今后的項目提供參考。

篇3

關鍵詞：運維體系、服務臺、事件管理、問題管理、變更管理、管理、配置管理

運行維護方案

1.1 方案設計思路

本方案的設計思路是：按照IT服務管理理論、方法和標準，結(jié)合用戶實際和建設需要，遵循立足需求、統(tǒng)一規(guī)劃、保障重點、分步實施、務求實效的原則，建立一套融合組織、制度、流程、人員、技術為一體的IT服務管理體系，建立組織機構，制定規(guī)章制度，規(guī)范管理流程，明確職責分工，強化技術支撐，使技術團隊能夠以此為依托，實現(xiàn)對用戶應用的綜合管理監(jiān)控和日常技術支持，快速響應和及時解決信息系統(tǒng)運行過程中出現(xiàn)的各種問題和故障，確保用戶應用的正常、穩(wěn)定、高效運行。

建立一個完善的IT服務管理體系，首先需要切合用戶需求和用戶特點。

本方案運行維護的用戶群可歸納為兩大類：

 內(nèi)部用戶：包括用戶、相關單位等；

 外部用戶：進行用戶業(yè)務辦理、查詢的單位和個人。

在方案實施時，將進行詳細調(diào)研，系統(tǒng)整理和規(guī)劃服務對象類型和數(shù)量，制定針對性的服務設計，滿足不同用戶的服務期望。

維護對象包括機房、網(wǎng)絡、主機和服務器、應用軟件等。

在需求調(diào)研中，需要規(guī)劃配置管理方案，確定配置屬性，梳理配置關系。同時對于不同維護對象，各有技術特點，需要制定針對性的運維技術手冊。

運維團隊由用戶信息中心、（總）集成商、集成商、應用開發(fā)商共同組成，可概括為三個服務團隊體系：服務臺、內(nèi)部運維團隊和外部運維團隊。

1.1.1 本項目運維體系設計重點

在本項目運維服務體系設計中，重點投入在服務支持建設上，服務支持描述了所提供的IT 服務日常支持和維護活動相關的過程，是在實現(xiàn)運維支撐平臺中最常用到的模塊。

服務支持主要功能模塊有：服務臺與事件管理、問題管理、變更管理、管理、配置管理。

1.1.1.1 服務臺與事件管理

服務臺是組織機構內(nèi)為所有IT 用戶所提供的單一、集中的聯(lián)系點，它處理所有事故、查詢和請求。它為所有其它服務支持過程提供了一個接口。

事件管理負責管理所有事故從檢測和記錄到解決和完成的所有內(nèi)容。事故管理的目標是快速有效地響應最終用戶，使它們能夠迅速恢復工作，以減小對最終用戶的影響。

事件管理涉及主要活動如下：

(1) 事件查明和記錄

(2) 分類和初步支持

(3) 調(diào)查和診斷

(4) 解決和恢復

(5) 關閉

1.1.1.2 問題管理

問題管理的目標是最小化事故和問題對業(yè)務的負面影響。為了達到這個目標，問題管理通過管理所有主要事故和問題來輔助事故管理，問題管理盡力記錄所有的工作環(huán)境并對相應已知錯誤進行“快速修補”，并且在可能時產(chǎn)生變更以實施持久的結(jié)構性的解決方案。問題管理也對事故和問題進行分析和趨勢分析，以預見性的預防進一步事故和問題的發(fā)生。

問題管理涉及主要活動如下：

(1) 問題識別、記錄和歸類

(2) 問題評審

(3) 調(diào)查和診斷

(4) 解決和關閉

(5) 已知錯誤識別和記錄

(6) 已知錯誤分類和評估

(7) 已知錯誤解決和關閉

1.1.1.3 變更管理

一個單一的集中化的有效和高效地處理變更的變更管理過程，是任何IT 機構成功運營的關鍵。在變更從啟動和記錄到過濾、評估、分類、授權、調(diào)度、建設、測試、實施以及最終的審核和收尾的整個生命周期中，必須謹慎仔細地對其進行管理。此過程的一個關鍵成果是前向變更調(diào)度（FSC-Forward Schedule of Change），它是基于業(yè)務影響和緊急性的所有領域都同意變更的一個中央程序。

變更管理涉及主要活動如下：

(1) 啟動、接受和分類

(2) 評估和審批

(3) 安排和分配

(4) 建設

(5) 實施

(6) 關閉

1.1.1.4 管理

管理過程采用了對IT 服務變更的整體全局視野，它考慮的所有技術和非技術方面。管理負責組織機構內(nèi)所使用的所有硬件和軟件的所有法律和合同義務。為了實現(xiàn)此目標并保護IT 資產(chǎn)，管理為定義硬件庫（DHS-Definitive Hardware Store）中的硬件和定義軟件庫（DSL- Definitive Software Library）中的軟件建立了一個安全的環(huán)境。

管理負責控制版本變更的頻度。這涉及到對變更的整合或?qū)⒆兏植鸪筛〉陌姹灸K。這些舉措基于一系列對業(yè)務需求、員工需求（開發(fā)、測試、實施、運作）和用戶/業(yè)務影響的權衡考慮。

管理涉及主要活動如下：

(1) 啟動、接受請求

(2) 策略制定

(3) 實施計劃制定

(4) 方案審批

(5) 構建測試環(huán)境

(6) 實施

(7) 對實施結(jié)果測試

(8) 結(jié)束

1.1.1.5 配置管理

配置管理提供了成功的IT 服務管理的基礎，它支持著所有其它過程。其基礎成果是配置管理數(shù)據(jù)庫（CMDB)，在數(shù)據(jù)庫中包含了一個或多個綜合數(shù)據(jù)庫詳細描述了組織機構中的所有IT 基礎設施組件以及其它重要的相關的資產(chǎn)。就是這些資產(chǎn)提供了IT 服務，它們也被稱之為配置項（CIs)。CMDB 同普通的資產(chǎn)注冊所不同之處在于那些關系、或鏈接，它們定義了每個配置項（CI）如何互連以及如何同其鄰居相互依賴。這些關系允許執(zhí)行例如影響分析和“如果..將會…”等的活動。理想情況下，CMDB 也包含了同每個CI 相關的所有事故、問題、已知錯誤和變更的細節(jié)。

配置管理涉及主要活動如下：

(1) 登記組成服務的資產(chǎn)信息；

(2) 登記這些資產(chǎn)之間的關系；

(3) 確保配置管理信息庫中的各類相關信息能夠得以及時更新。

1.2 運維體系設計內(nèi)容

運維體系設計內(nèi)容包括：運維組織架構、角色與職責、運維相關流程、運維工作表單、服務度量指標。

1.2.1 運維組織架構

運維組織架構包括涉及運維管理的所有單位、部門、人員的組織信息，用樹形層次結(jié)構記錄，作為運維系統(tǒng)基礎數(shù)據(jù)管理。

為確保整個運維工作的協(xié)調(diào)運轉(zhuǎn)，建議采用分級管理模式規(guī)劃運維組織架構，即組建運維服務臺，三級運維支持部門協(xié)同工作，共同完成運維工作。

建立統(tǒng)一接入的服務臺，實行中央控制，分級授權的集中式加分布式的服務臺設計。當最終用戶提出請求或者需對應用系統(tǒng)進行主動運維時，運維服務臺作為呼叫受理反饋部門接受服務請求，并提供一線幫助。對于無法解決的問題，提交二線也即系統(tǒng)運維組處理，運維服務臺同時進行跟蹤和催辦。

系統(tǒng)運維組包括內(nèi)部運維團隊和外部運維團隊，作為核心團隊負責運行維護和管理工作，針對應用系統(tǒng)進行主動運維，并解決運維服務臺轉(zhuǎn)交的請求，在必要時協(xié)調(diào)供應商、開發(fā)商等外部資源。

供應商、開發(fā)商作為三線支持，對運維中心提供二線不能解決的問題支持。

采用上述分級管理的工作模式，可以按照運維人員的不同技術能力分配到一、二、三線，實現(xiàn)了運維人員的專業(yè)化分工；對于技術要求相對較低的一線可根據(jù)工作量的增長及時增加，確保服務呼叫處理率，對于承擔核心運維工作的二線人員，避免了初級服務請求的直接處理，保證其對關鍵應用和緊急故障的處理，可以大大提高運維服務效率和質(zhì)量；同時，分級管理的工作模式充分發(fā)揮不同人員的技術能力，克服了高能低用情況的發(fā)生，降低了運維服務總體成本。

1.2.2 角色與職責

本方案運維管理的角色與職責設置，將以ITILV3標準為參考，結(jié)合總集成商歷年來大量的運維服務實踐，針對本項目用戶進行設計。所涉及的角色及職責的定義，主要包括服務臺、事件管理、問題管理、變更管理、管理、配置管理各個角色和職責。例如，服務臺、一線工程師、二線工程師、事件經(jīng)理、問題經(jīng)理、問題分析工程師、變更經(jīng)理、變更咨詢委員會、配置管理員等角色。

各類角色在運行維護過程中承擔不同的職責，并將在方案實施時根據(jù)用戶特點進行完善。

1.2.3 運維相關流程

運維相關流程的定義和設計，根據(jù)用戶的業(yè)務需求特點進行定義，主要包括服務臺、事件管理、問題管理、變更管理、管理、配置管理、知識管理等流程。

在本方案實施時，將進行運行服務流程設計。主要流程設計工作內(nèi)容包括：

1、服務臺/事件管理流程設計

2、問題管理/知識管理流程設計

3、變更管理流程設計

4、配置管理流程設計

1.2.4 運維文檔體系

建立文檔體系是進行運行維護服務中持續(xù)進行的工作。完善的文檔體系有助于維護團隊工作持續(xù)性，維持穩(wěn)定的客戶服務能力。如運維流程類文檔（事件報障信息表單、發(fā)起問題信息表單、變更申請表單、管理申請表單、配置信息記錄表單等）、服務器、數(shù)據(jù)庫日常維護操作類文檔；日常檢查模板；日常溝通工作模板、應用流程等等，這類標準化文檔的建立，將規(guī)范運維管理，改善運維效率。

文檔體系的建立并非易事，因此需要從思想上重視并不斷更新文檔，嚴格按文檔實施操作，要監(jiān)督文檔質(zhì)量等。

文檔體系的建設包括兩方面內(nèi)容：

1、文檔體系完善

2、規(guī)范梳理和固化

在實際運維中，由于運維活動具有多樣性、復雜性，規(guī)范的制訂往往跟不上運維實際的要求。但結(jié)合客戶業(yè)務需要，有選擇地制訂關鍵的運維規(guī)范不失為一種有效方法。

定義：這里的規(guī)范指運維過程中應該遵循的、客戶導向的行為約定。包括操作方法、結(jié)果提交方式、運維過程控制點的確認等。以升級為例：故障出現(xiàn)后，故障的等級判斷標準，處理時長與升級的關系，升級的途徑和相關人等，都受升級規(guī)范的約束。

流程的梳理是一個漸進的過程，規(guī)范內(nèi)容也會隨用戶系統(tǒng)生命周期、運維局勢不同而及時調(diào)整。對于規(guī)范梳理，需關注兩方面的內(nèi)容：

 其一是目前運維中影響較大、問題較多急需明確的流程；

 其二是明確確認規(guī)范的主體。

另外和規(guī)范相關的接口有客戶和項目組，需分別進行梳理，并區(qū)分其各自不同的特點。明確責任，合理分工。這部分工作是服務持續(xù)改善計劃的難點所在。

1.2.5 服務度量指標

制定服務度量指標，對運維系統(tǒng)制定內(nèi)部和外部服務管理級別，對員工制定員工績效考核標準。

規(guī)劃的工作內(nèi)容如下：

 配合用戶技術支持部門梳理所有現(xiàn)有SLA相關資料編制服務目錄；

 完善和鞏固服務目錄，同時加強客戶溝通和宣傳，讓更多客戶充分了解服務團隊目前提供的服務內(nèi)容；

 基于ITIL建立標準的服務水平管理流程，規(guī)范定義包括服務水平管理計劃、客戶需求管理、服務水平確定、OLA磋商、UC需求確定、SLA簽署、監(jiān)控和回顧等在內(nèi)的各項服務水平管理活動；

 建議采用需求調(diào)研表和訪談的方式對客戶的IT服務需求進行收集、整理和分析，從而確定服務水平需求；

 由客戶服務部依據(jù)與客戶簽訂的SLAs將相關的具體指標細化為各分相關職能部門的OLA，并與分解相應UC到對應供應商；

 利用工具監(jiān)控和收集實際的服務水平管理數(shù)據(jù)，并通過與SLA的比較發(fā)現(xiàn)差距生成報告，交由OLA和UC支持團隊進行改進；

 建立服務水平協(xié)議回顧和檢查過程；

篇4

【關鍵詞】核電工程設計；變更技術；變更技術澄清

1前言

核電工程現(xiàn)場設計變更文件是對原設計文件的修改、補充、完善和優(yōu)化，與施工圖紙一樣是施工的重要依據(jù)。設計變更文件的管理則是極為重要的技術管理工作，是保證工程質(zhì)量、加強工程管理的重要環(huán)節(jié)。

2電力工程的設計變更

2．1設計變更分類

長期以來國內(nèi)電力工程的設計變更管理遵循的是國家電網(wǎng)公司2003年頒發(fā)的《電力建設工程施工技術管理導則》中的《設計變更管理》制度。設計變更分為以下三種:(1)小型設計變更。不涉及變更設計原則，不影響質(zhì)量和安全、經(jīng)濟運行，不影響整潔美觀，不增減概(預)算費用的變更事項。由現(xiàn)場設計、建設單位代表簽字同意后生效。(2)一般設計變更。工程內(nèi)容有變化，但還不屬于重大設計變更的項目。經(jīng)建設單位審核后，由設計代表簽發(fā)設計變更通知書并經(jīng)建設單位會簽后生效。(3)重大設計變更。變更設計原則，變更系統(tǒng)方案，變更主要結(jié)構、布置、修改主要尺寸和主要材料以及設備的帶環(huán)等設計變更項目。由項目部總工程師組織各方充分論證后，設計單位出具設計變更通知書，經(jīng)建設、監(jiān)理、施工單位會簽后生效。

2．2設計變更管理不足之處

隨著建筑業(yè)市場經(jīng)濟的建立、設備組合程度的提高和施工技術的發(fā)展，這項制度逐漸暴露出了一些不足之處，列舉如下:(1)變更分類不科學，界限不清。《設計變更管理》將設計變更的內(nèi)容按大、中、小原則來劃分，即分為:小型設計變更、一般設計變更、重大設計變更。但要界定大、中、小卻不是容易的事，如圖紙尺寸的差錯更正屬于小型變更，那么高電壓設備的對地距離小了，直接威脅到人身和設備的安全，并將引起一系列的設計變更。(2)《設計變更管理》將設計變更的發(fā)起者指的是施工單位或項目工地，實際在施工過程中設計單位本身也會對設計圖紙?zhí)岢鲎兏?，該制度缺少這方面的規(guī)定。因此有的設計單位將施工單位提出的變更稱為“變更設計”，將設計人員提出的變更稱為“設計變更”。(3)《設計變更管理》缺少設計變更的處理流程?，F(xiàn)場設計變更文件是施工的重要文件，從變更的提出、審批、執(zhí)行、檢查、驗收、改圖、簽證和關閉應有一套嚴格的管理程序，哪一環(huán)節(jié)都不能出現(xiàn)問題，這樣才能真正避免同類型的不同工程犯同樣的錯誤，才能保證整體工程的質(zhì)量。

3中廣核集團設計變更文件的分類及處理流程

3．1澄清要求

澄清要求(CR)是施工承包商對文件中某些不清楚或不完整或不理解的地方提出的要求澄清的文件，它不需要修改文件/圖紙，但設計單位可能針對CR提出的問題答復發(fā)DEN或要求施工承包商發(fā)TA或FCR。CR由現(xiàn)場設計工程師答復，設計經(jīng)理批準，抄報業(yè)主。

3．2技術變更

技術變更(TA)是施工承包商為適應某些特殊的資源或方法或某些特殊的現(xiàn)場條件而對設計單位/供應商的文件提出的修改。施工承包商提出TA，在TA中寫明修改的理由和進行修改的建議，列出所涉及的文件/圖紙編號，經(jīng)施工承包商內(nèi)部審查后交設計單位批準并報業(yè)主備案即可。如業(yè)主有不同意見，仍可要求施工承包商停止執(zhí)行TA。

3．3現(xiàn)場變更申請

現(xiàn)場變更申請(FCR)是施工承包商或業(yè)主提出的修改建議。當施工承包商或業(yè)主發(fā)現(xiàn)現(xiàn)場實際情況不允許完全按照原設計圖進行施工時，他們先與設計單位的現(xiàn)場代表協(xié)商解決方案，然后由施工承包商提出FCR。

3．4設計改進通知

設計改進通知(DEN)是設計單位給業(yè)主和施工承包商發(fā)出的通知，表示需要對已宣布生效的施工文件進行修改。

4國家核電變更文件的分類及處理流程

4．1信息請求

信息請求(RFI)回復文件僅僅是技術咨詢文件，嚴格來講不是設計變更文件，信息請求程序僅被限于問題的澄清。也有可能通過信息請求(RFI)，WEC會發(fā)出設計變更文件，但信息請求絕不能代替沒有經(jīng)WEC批準的任何設計變更文件。信息請求(RFI)不適用于由于承包商不遵守設計文件而造成的不符合項(NCR)。

4．2現(xiàn)場變更申請

現(xiàn)場變更申請是施工承包商在現(xiàn)場根據(jù)已供使用的設計文件施工時發(fā)現(xiàn)圖紙與實際有沖突、不符合等情況不允許完全按照原設計文件施工時提出的包含有修改建議的變更申請。一份完整的現(xiàn)場變更請求(FCR)還不是一個可執(zhí)行的設計文件。現(xiàn)場變更請求(FCR)一旦被批準，負責回復的設計部門必須設計變更申請(EDCR)。施工承包商在收到通過文控中心的已批準的FCR和EDCR后才能進行安裝，并要確認所完成的工作符合FCR和其相對應的可使用的EDCR的要求。

4．3設計變更申請

由設計單位對已批準的設計文件提出的變更申請。施工承包商在收到通過文控中心的已批準的EDCR(或帶修改圖紙)才可進行施工。

4．4設計變更關閉

各類技術文件(圖紙、程序、質(zhì)量計劃等)在編制、審查、執(zhí)行及竣工的各個階段有不同的狀態(tài)，即PRE(Preliminary，初步)、CFC(CertifiedForconstruction，施工)、CAE(CertifiedAsExecuted，竣工)、DES(Design，設計)等四種狀態(tài)。CFC狀態(tài)的文件由設計單位發(fā)出后，經(jīng)業(yè)主向施工承包商發(fā)出供使用通知，才能在現(xiàn)場正式使用。一個變更文件關閉的標志是現(xiàn)場執(zhí)行和文件圖紙修改全部結(jié)束，改圖是變更文件關閉的最后一道工序。改圖完成后，要改變圖紙的版次。國家核電和中廣核集團采用的設計變更程序代表了我國目前核電站建設變更文件管理的二種不同的做法，其共同特點是思路相似，分類科學，表達準確，流程清晰，管理嚴密，基本滿足了現(xiàn)場施工管理的需要。但我們還能看到二者存在著粗細程度的差別。核電站工程建設采用的是與國際接軌的工程管理模式，其現(xiàn)場變更管理具有一定的先進性，可以借鑒。通過以上的歸納、對比和總結(jié)，提出亮點建議:一是國家電力建設的主管部門在充分調(diào)查研究的基礎上，吸收各核電集團設計變更程序的有點，該制定適合國情的新的《設計變更管理》制度，作為指導類文件;二是在常規(guī)電力工程建設中，也可以研究并適度采用核電站工程建設的設計變更管理辦法。

參考文獻:

［1］秦宏偉．淺議核電站設計變更管理［J］．建筑設計管理，2009(7):16～18．

篇5

（一）ITIL簡述

1986年英國政府中央計算機和電信局（C—TA，后來并入英國商務部OGC）實施名為“政府信息技術基礎設施管理方法論（GITMM）”的研究項目，目標是根據(jù)各個行業(yè)在IT管理方面的最佳實踐中總結(jié)歸納出一套規(guī)范化的、可量化的IT資源使用的管理方法，以提高IT資源的利用率和服務質(zhì)量，項目的最終成果就是ITILv1版。OGC將I-TILv1逐漸擴充成為龐大的ITSM方法論知識體系，并于1999年了ITILv2版。2001年英國標準協(xié)會（BSI）正式基于ITIL的ITSM英國國家標準BS15000。2005年12月，國際標準化組織（ISO）和國際電工委員會（IEC）正式以BS15000作為藍本的第一個ITSM國際標準ISO/IEC20000。OGC在整合了v1和v2版的精華并融入了當前ITSM的最佳實踐后，于2007年5月正式了ITILv3版。目前應用最成熟的ITILv2版的體系架構如圖1所示，包括服務管理、IT服務管理規(guī)劃和實施、業(yè)務管理、應用管理、IT基礎設施管理、安全管理等六大模塊。服務管理模塊是ITIL的核心模塊，它把IT管理活動梳理歸納為服務支持和服務提供兩組流程及一些輔助流程。服務支持流程組屬于基礎性的運營級（或稱操作級）管理流程，包括一個服務臺職能和事件管理、問題管理、配置管理、變更管理、管理5個流程。服務提供流程組屬于提高性的戰(zhàn)術級管理流程，包括服務級別管理、IT服務財務管理、IT服務持續(xù)性管理、可用性管理、能力管理5個流程。

（二）運營級的服務支持流程

服務支持流程主要面向IT基礎設施和應用系統(tǒng)，用于規(guī)范IT服務的“前端”，負責日常服務工作中對各種故障和問題的處理，側(cè)重于對客戶的技術支持和設施維護，目的是使客戶有一個穩(wěn)定運行的IT環(huán)境。運營級管理流程把服務臺作為與外部聯(lián)系的單一入口，以配置管理的核心———配置管理數(shù)據(jù)庫（CMDB）為中心把事件管理、問題管理、變更管理及管理作為節(jié)點構成一個管理閉環(huán)。在ITILv2中，“服務請求”是指IT服務提供者與客戶前期已經(jīng)協(xié)商好、需要提供給用戶的服務，屬于標準操作?！笆录笔侵冈谀骋环罩胁粚儆跇藴什僮髑乙呀?jīng)導致或可能導致該項服務中斷或服務質(zhì)量下降的任何事情，它往往是臨時發(fā)生的，具有突發(fā)性?！皢栴}”是指導致一起或多起事件的潛在原因。事件是表征，問題才是本質(zhì)。事件的發(fā)生并不一定就表明IT系統(tǒng)存在問題，而問題也不一定要等事件發(fā)生后才能發(fā)現(xiàn)。服務臺是IT服務管理的核心功能，所有服務支持流程都要通過服務臺為客戶提供單點聯(lián)系，接受客戶服務請求和故障報告、IT基礎設施和應用系統(tǒng)的故障報警，為客戶提供一線技術支持，回復客戶的相關問題和需求，協(xié)調(diào)客戶與二線或三線支持之間關系，全程監(jiān)控服務請求和事件處理進展狀態(tài)并向客戶報告。事件管理流程目標是采取應急措施或臨時修復方案使被中斷或受影響IT服務盡快恢復正常運行，盡量減少對業(yè)務的負面影響。它的特點是以盡快解決突發(fā)事件為目的，屬于“被動”、“治標”行為。若事件反復出現(xiàn)或?qū)儆谥卮笫录?，則必須提交給問題管理流程。問題管理流程的目標是深入分析問題存在的根本原因，提供有效解決方案解決問題避免類似事件再次發(fā)生。實施主動問題管理，在事件發(fā)生前發(fā)現(xiàn)和解決問題。它具有“預防”、“主動”、“治本”的特點。配置管理處于服務管理的中心位置，CMDB是實施配置管理的基礎，CMDB中最基本的信息單元是配置項，包含了IT基礎設施、應用系統(tǒng)等IT資源所有精確信息。配置管理通過識別和確認配置項，記錄和報告配置項的狀態(tài)、變更情況、版本信息及配置項之間關系信息，控制配置項訪問權限，驗證配置項的正確性和完整性等活動為其他管理流程的執(zhí)行提供支持。變更管理流程使用標準化的變更控制過程處理對IT基礎設施和應用系統(tǒng)所做的變更，目標是以對服務最小的干擾實現(xiàn)有益的變更。變更控制過程使用標準的方法和步驟：提出變更請求、評估變更的風險和影響以及業(yè)務收益、批準或拒絕變更請求、盡快實施已獲批準的變更、驗證變更是否已正確實施。管理流程負責對IT基礎設施和應用系統(tǒng)的規(guī)劃、設計、構建、配置、測試，以便為實際運行環(huán)境提供一系列的組件，并將新的或變更的組件遷移部署到運行環(huán)境中，目標是保證正確的組件被以及運行環(huán)境的完整性。變更管理和管理均需要對CMDB的相關配置項進行更新，它們與配置管理是緊密結(jié)合的。

（三）戰(zhàn)術級的服務提供流程

服務提供流程，主要用于規(guī)范IT服務的“后端”，負責定制IT服務，規(guī)范IT服務應達到的工作目標、服務水平和服務質(zhì)量，目的是解決IT服務的規(guī)劃、設計、實現(xiàn)、持續(xù)性問題，并優(yōu)化IT服務的成本績效。服務級別管理主要負責與客戶協(xié)商就所要提供的IT服務的類型和質(zhì)量水平，簽訂服務級別協(xié)議（SLA），并確保協(xié)議得以執(zhí)行。此外，IT服務提供商還需與內(nèi)部人員簽訂運營級別協(xié)議（OLA），與外部供應商簽訂支持合同（UC）。OLA與UC用來支持實現(xiàn)SLA中的服務級別。服務級別管理還監(jiān)控并報告服務級別，定期進行評審以便改進，確保服務級別協(xié)議的更新和持續(xù)有效。IT服務財務管理負責為IT服務提供者對所提供的IT服務編制預算和核算服務運營成本，并向客戶收取相應服務費用，目標是如何經(jīng)濟節(jié)約地提供IT服務，合理平衡服務質(zhì)量、成本、客戶需求三方關系。主要包括預算編制、會計核算和服務計費三個子流程，產(chǎn)生的預算和核算信息可為服務級別管理、IT服務持續(xù)性管理、能力管理等流程提供決策依據(jù)。IT服務持續(xù)性管理負責災難預防、增強IT基礎設施的恢復能力和容錯能力，它需要在災難發(fā)生后有足夠的技術、資金和管理資源來確保應用系統(tǒng)運行所需的IT基礎設施和IT服務在限定時間內(nèi)得到恢復，保證服務的持續(xù)性。能力管理負責在當前和未來的業(yè)務需求和運營成本的雙重約束下，適時部署相應IT資源，提升服務能力以確保服務品質(zhì)滿足約定的服務級別目標的要求，同時使組織的IT資源發(fā)揮最大效能并與運營需求相匹配，主要包括業(yè)務能力管理、服務能力管理、資源能力管理三個子流程?？捎眯怨芾硎峭ㄟ^前瞻性分析客戶的可用性需求，使用適當?shù)馁Y源、技術和方法優(yōu)化IT基礎設施和應用系統(tǒng)的可用性，設計適當措施將突發(fā)事件發(fā)生頻率降到最低，從而確保以合理的成本達成服務級別協(xié)議的可用性目標。（四）ITIL應用的六大要素實施ITIL需要綜合人員、流程、技術三大方面因素，還可進一步細分為六個要素。1.領導力：主管領導的支持，可在資源投入、組織架構整合、部門間協(xié)同方面發(fā)揮重要作用。負責ITIL運作的執(zhí)行團隊主管和核心骨干能夠領導和激勵整個團隊積極推進工作。2.組織文化：全員參與ITIL培訓，培養(yǎng)服務意識，逐漸把“以客戶為中心、以流程為導向、提供高質(zhì)量低成本服務”的ITIL理念變成一種組織文化。3.人員組織包括合理設置職能部門的組織架構、人員的角色和職責及技能要求、人員績效考核標準等。4.流程是為實現(xiàn)一個特定目標按照既定的方法進行一系列有序活動的過程，一個完整的流程包含目標、范圍、輸入（處理的對象）、輸出（期望的結(jié)果）、活動（執(zhí)行的動作）、角色（流程負責人、流程經(jīng)理、流程執(zhí)行人）和職責、關鍵績效指標KPI、與其他流程之間接口、激活條件等基本元素。5.工具對于實現(xiàn)ITIL具有非常重要的作用，能夠提高服務質(zhì)量和效率，主要包括IT系統(tǒng)運行監(jiān)控和診斷優(yōu)化工具、流程自動化工具兩類。監(jiān)控工具的監(jiān)控對象是IT基礎設施和應用系統(tǒng)，流程化工具是對各項管理流程的電子化實現(xiàn)。6.信息：對ITIL運作中產(chǎn)生和積累的大量信息進行分析，發(fā)現(xiàn)潛在問題，持續(xù)改進服務質(zhì)量和提升客戶滿意度。

二、基于ITIL的電子政務IT運維服務管理體系

運維管理組織架構和角色及職責設置、運維服務管理流程、運維服務支撐系統(tǒng)、運維服務管理對象（IT資源、IT用戶、供應商等）、提供的運維服務等五個要件構成了完整的IT運維服務管理體系。在基于ITIL的電子政務IT運維服務管理體系中，IT運維服務提供者與政府客戶的IT運維服務管理部門（政府信息化辦公室）簽署服務級別協(xié)議，運維服務團隊中各司其職的運維人員通過執(zhí)行符合ITIL規(guī)范的服務管理流程和使用信息化支撐工具為IT用戶提供針對電子政務系統(tǒng)（IT資源，包括IT基礎設施和應用系統(tǒng)）的運維服務，確保電子政務系統(tǒng)正常穩(wěn)定、安全可靠、高效經(jīng)濟地運行。根據(jù)IT運維服務提供者和政府客戶之間是否存在組織上隸屬關系，運維服務管理模式有自主模式、完全外包模式和介于前兩者之間的混合模式。如果IT運維服務提供者是政府內(nèi)部IT部門，則屬于自主運維；若IT運維服務全部由外部提供商負責，則屬于完全外包模式；既有自主也有外包的屬于混合模式。我國的政府部門和大多數(shù)企業(yè)的組織架構一般都是按照職能進行縱向的部門和崗位劃分，而在ITIL應用實踐卻是按照流程進行橫向劃分，是徹底按照ITIL規(guī)范重組還是按照實際情況適度調(diào)整，這需要根據(jù)運維管理模式、領導支持度等多方面情況綜合衡量。這個問題也是ITIL在我國落地應用的難點之一。從IT運維服務提供者的視角看，運維人員在管理流程的角色設置有流程負責人、流程經(jīng)理、流程執(zhí)行人。流程負責人對特定的流程負責，權責涵蓋了整個流程的生命周期，在流程設計、確定流程目標和關鍵績效指標、宏觀上監(jiān)控流程的執(zhí)行、評估流程實際達到的目標和運行績效、對流程持續(xù)改進優(yōu)化、與其他流程的協(xié)同等方面負起全責，通常由IT運維服務提供者的業(yè)務主管擔任。流程經(jīng)理的職責是全程督導、協(xié)調(diào)和監(jiān)控流程的執(zhí)行，確保其正常運轉(zhuǎn)，通常由IT運維服務團隊的主管和技術骨干擔任。流程執(zhí)行人的職責是按照既定規(guī)范執(zhí)行預定動作，由具備相應專業(yè)技能的運維人員擔任，他們可以是來自IT運維服務提供者內(nèi)部組織，也可以來自軟硬件系統(tǒng)供應商、電子政務應用系統(tǒng)開發(fā)商和集成商等外部組織。IT運維服務支撐系統(tǒng)是開放式集成軟件平臺，一方面，把IT運維服務提供者制定的符合ITIL規(guī)范的服務管理流程實現(xiàn)信息化處理，可以更高效地向IT用戶提供高質(zhì)量IT運維服務，同時實現(xiàn)對整個IT運維服務的監(jiān)督、評估和績效考核；另一方面，支撐系統(tǒng)能夠?qū)λ蠭T資源進行管理和實時運行監(jiān)控。ITIL是IT服務管理的標準框架，它只告訴我們要做些什么（What），而沒有告訴如何去做（How）。要真正實現(xiàn)ITIL在電子政務IT運維服務管理體系的落地，首先必須與客戶進行現(xiàn)場訪談，分析現(xiàn)狀，并與最佳實踐進行差距分析，進而確定合理的目標和達到目標的實施路徑，進行人員組織架構、流程、技術支撐系統(tǒng)的規(guī)劃和設計，上線運行，持續(xù)對每個流程和整個體系的運行績效進行回顧評審，進而優(yōu)化改進，這個過程不斷循環(huán)往復。

三、電子政務運維服務管理體系中服務管理流程的具體實現(xiàn)

筆者長期從事電子政務系統(tǒng)運維工作，所在單位是XX市政府電子政務系統(tǒng)的運維外包服務商，逐步分階段初步構建基于ITILv2的電子政務運維服務管理體系。第一階段首先實現(xiàn)了服務臺職能、事件管理、問題管理、變更管理、配置管理、知識管理和對部分IT基礎設施和應用系統(tǒng)的分散監(jiān)控。第二階段全部實現(xiàn)了完整的服務支持流程以及運行管理、供應商管理，同時進一步完善、優(yōu)化、整合管理流程和工具，對重要IT基礎設施和核心應用系統(tǒng)實現(xiàn)了集中監(jiān)控。規(guī)劃將在第三階段實現(xiàn)所有的服務提供流程，采用運維服務開放式集成管理平臺。筆者曾參與了該外包項目前期規(guī)劃階段的客戶服務需求捕獲、服務管理流程梳理和設計等部分工作，現(xiàn)作為運維團隊主管。在不改變原組織架構前提下經(jīng)單位領導授權，筆者通過角色—職責分配矩陣將原來屬于基礎設施維護組、應用系統(tǒng)支持組、網(wǎng)絡維護組、系統(tǒng)維護組、安全管理支持組等職能部門的人員映射到運維服務管理流程的角色中，并賦予相應責任，同時一些重要角色設置了A、B角。單位分管領導是所有流程的負責人，筆者負責該市政府電子政務系統(tǒng)的日常運維服務管理工作，擔任事件管理、問題管理和變更管理的流程經(jīng)理，同時兼任變更顧問委員會（CAB）副主管，參與重要變更審批工作。XX市政府與作為外包商的單位通過在電子政務運維服務體系中實施ITIL，大大地提高了運維服務水平，客戶滿意度獲得很大提升，同時降低了運營成本，外包商公司也實現(xiàn)商譽大幅增值，實下面從運維外包商視角論述兩個關鍵的服務支持流程的設計實踐。

（一）服務臺職能/事件管理流程

所有服務支持流程都通過服務臺為客戶提供單點聯(lián)系，服務臺設值班經(jīng)理1名，熱線人員2名。服務臺人員負責記錄并受理客戶的服務請求、故障報告、咨詢、投訴和技術人員定期巡檢發(fā)現(xiàn)的系統(tǒng)故障以及運行監(jiān)控系統(tǒng)報警，回復客戶的相關問題，進行初級支持，或派單給合適技術人員為客戶提供一線支持服務，在事件升級后協(xié)調(diào)客戶與二線或三線支持之間聯(lián)系，全程監(jiān)控服務請求和事件處理進展狀態(tài)并向客戶報告。服務臺職能與事件管理流程集成在一起。事件管理流程目標是盡快恢復被中斷或受影響IT服務，主要執(zhí)行活動包括：事件的檢測識別、記錄、分類、優(yōu)先級排序、初步支持、事件的調(diào)查和診斷、事件的解決和恢復以及事件的關閉。事件管理流程概略設計樣例如圖6所示。事件管理流程運行階段的角色設置分為：事件經(jīng)理：由筆者本人擔任，負責全程監(jiān)控和協(xié)調(diào)每個事件的執(zhí)行，特別是事件升級、重大事件處理等與流程運行績效密切相關的活動，確保服務質(zhì)量，滿足與客戶約定的要求；對執(zhí)行人員實施績效考核；主持重大事件的事后回顧評審會議，參與定期的流程回顧會議，把流程執(zhí)行中存在的不足和改進建議向事件管理流程負責人報告，以便以后改進優(yōu)化；定期撰寫事件管理分析報告。一線支持人員：包括機房值班人員、部分專業(yè)維護組成員，負責日常處理大量相對簡單、重復出現(xiàn)的事件和服務請求。二線支持人員：由資深技術專家領銜的專業(yè)維護團隊組成，負責處理復雜度較高或一線支持無法解決的事件。三線支持人員：由來自軟硬件系統(tǒng)供應商、電子政務應用系統(tǒng)開發(fā)商和集成商的技術人員擔任，負責處理與這些供應商產(chǎn)品或服務相關的事件。

（二）問題管理流程

問題管理流程目標是深入分析導致事件發(fā)生的根本原因，提供有效解決方案解決存在的問題，避免類似事件再次發(fā)生，或是在事件發(fā)生前發(fā)現(xiàn)和解決問題。執(zhí)行的主要活動有：問題的識別、記錄、分類、優(yōu)先級排序，問題的調(diào)查和診斷、問題的解決以及問題的關閉等活動。問題管理流程概略設計樣例如圖7所示。問題管理流程運行階段的角色設置分為：問題經(jīng)理：由筆者擔任，負責協(xié)調(diào)問題管理活動的日常執(zhí)行和流程中的工作調(diào)度，將提交來的問題進一步識別、審核和分類，根據(jù)問題緊迫性和影響程度確定優(yōu)先級，根據(jù)技能和工作負荷把問題分派給合適的問題專家小組處理，并為其調(diào)配必要的資源；監(jiān)控已分派問題隊列，特別關注重大問題和需升級問題；監(jiān)督流程執(zhí)行確保遵循相應標準和步驟；對執(zhí)行人員實施績效考核；主持重大問題的事后回顧評審會議，參與定期的流程回顧會議，把執(zhí)行中存在的不足和改進建議向問題管理流程負責人報告，以利改進優(yōu)化；定期撰寫問題管理統(tǒng)計分析報告。問題專家：由資深技術專家領銜的專業(yè)維護團隊組成，負責問題的調(diào)查和診斷，找出問題產(chǎn)生的根本原因，提出解決方案或規(guī)避措施并實施。

四、結(jié)語

篇6

關鍵詞：電力通信工程；設計質(zhì)量；作業(yè)流程階段；標準化

一、設計作業(yè)內(nèi)容及流程階段質(zhì)量控制

在電力通信工程施工開始之前要經(jīng)歷設計作業(yè)流程，這一流程的質(zhì)量把控直接影響工程項目全局。具體來說，設計作業(yè)流程應該包括工程設計管理、施工圖設計、設計變更這3大主要作業(yè)流程，以下作出一一解讀。

1.工程設計管理設計作業(yè)流程解讀。工程設計管理設計作業(yè)流程應該基于PDCA質(zhì)量環(huán)科學方法來進行解讀，它特別強調(diào)對設計作業(yè)過程的計劃、執(zhí)行、檢查與糾正，目前在電力通信工程設計中較為常見，以下給出該階段的設計作業(yè)流程質(zhì)量控制簡析。首先電力通信公司會創(chuàng)設項目待上級審批后向社會組織招標投標，然后對投標施工團隊進行篩選與合同簽訂，在確立施工方以后評審合同，并對他們下達設計任務書，編制設計計劃，這也是設計階段（Plan）的主要內(nèi)容。其次在執(zhí)行階段（Do），它的主要流程分為現(xiàn)場勘查、專業(yè)設計、內(nèi)部審查和設計文件出版4大部分。其中現(xiàn)場勘查包括勘查計劃的制定與施工現(xiàn)場相關數(shù)據(jù)勘查，這其中包括地質(zhì)勘查、建筑環(huán)境勘查以及周圍環(huán)境勘查等等子項目；專業(yè)設計階段則包括了基于現(xiàn)場狀況的初步設計和涉及項目全局的施工圖設計；內(nèi)部審查則以兩查（施工方審查、監(jiān)理方審查）和三審（投標方資格預審、投標方資格后審、投標文件符合性審查）來為設計流程奠定基礎，最后是設計文件出版，它分為設計文件校對和出版文件檢驗兩方面。在檢查階段（Check）和處理階段（Action），主要包括以下基于質(zhì)量控制的設計流程：設計文件交付（設計文件歸檔）設計審查會設計收口工程回訪持續(xù)改進。

2.施工圖設計作業(yè)流程解讀。施工圖設計作業(yè)流程涉及項目整體的所有技術環(huán)節(jié)，因此要加強該階段質(zhì)量管理，做到詳細閱讀設計計劃書，施工圖紙，并根據(jù)現(xiàn)場勘測隊施工設計圖進行隨時更正，以避免施工開始后質(zhì)量把控，減少意外事故所造成的二次返工現(xiàn)象出現(xiàn)。3.設計變更作業(yè)流程解讀。在電力通信工程項目中，設計變更作業(yè)一般實施閉環(huán)管理方法，它的具體變更內(nèi)容主要交由設計單位來行使完成，并由監(jiān)理單位和企業(yè)進行流程監(jiān)督。如果施工圖紙有變更需要，電力企業(yè)要首先交出設計變更內(nèi)容申請，由設計單位和監(jiān)理單位進行共同審核，最后交由施工建設單位審核。這其中如果單項工程設計變更內(nèi)容累計不大于10萬，要在設計單位認可后備案交由建設單位發(fā)文作為變更憑證；如果單項工程設計變更內(nèi)容累計大于10萬，則要向企業(yè)申請審核批準并發(fā)文，審批后將企業(yè)發(fā)文作為設計變更憑證。最后由施工單位實施已變更設計內(nèi)容，由建設施工、設計、監(jiān)理和企業(yè)共同進行質(zhì)量流程監(jiān)督。

二、設計流程各階段質(zhì)量有效控制策略

電力通信工程設計除規(guī)范具體設計作業(yè)流程外，還要對設計內(nèi)容進行有效質(zhì)量控制，下文主要從設計階段和后期服務階段兩方面展開分析。

1.設計階段質(zhì)量控制策略電力通信工程設計階段要在電力行業(yè)領域技術指導及國家質(zhì)量標準的背景下來完成設計文件，使其起到指導工程建設及實施的重要作用。因此，設計階段質(zhì)量控制要做到全面把控，主要圍繞組織技術接口、設計過程兩大大控制點展開。首先看組織技術接口，考慮到電力通信工程內(nèi)容設計跨越多專業(yè)領域，涉及多部門聯(lián)合因素，所以在組織與技術實施方面要做到接口多元化，確保設計內(nèi)容在工程項目中的正確輸入。就目前諸多電力通信工程的組織接口設計過程來看，他們通常以圖紙會簽作為各部門之間的組織接口技術控制手段之一，它實現(xiàn)了施工圖紙的全員化審批同意過程，在一定程度上也打下了后期施工質(zhì)量的有效穩(wěn)定基礎。其次是設計過程，它包括“設計輸入——過程轉(zhuǎn)化——設計輸出”3大流程，這一過程對說明書、圖紙和概預算進行了全面分析，也實現(xiàn)了對工程資料、現(xiàn)場勘查內(nèi)容的全面整理。作為項目設計中最為關鍵核心的環(huán)節(jié)，設計階段的質(zhì)量控制主要追求質(zhì)量合理化和設計控制完全技術化，希望以設計過程質(zhì)量有效控制提高技術含量和項目決策水平，將項目內(nèi)容設計具體化。一般來說，電力通信工程項目的設計階段主要由兩部分組成，首先是項目內(nèi)容設計方案編制，它主要完成了項目設計所涉及全部內(nèi)容的技術構思，包括多設計方案比對選擇，進而明確最終設計內(nèi)容。另一方面則強調(diào)繪制設計圖紙與編制工程的概預算分析，根據(jù)所需成本來編寫設計說明書，選擇應用哪種技術流程展開施工，這是質(zhì)量控制與成本控制融合的過程，它們共同組成了一整套完整的設計文件。

2.后期服務階段質(zhì)量控制策略。后期服務階段主要是對前期設計內(nèi)容的補正工作，由于受到各種條件變化及技術變化影響，設計圖紙可能并不完美，所以必須通過后期服務來加以解決，后期服務質(zhì)量也決定了工程項目的整體設計質(zhì)量，應該引起企業(yè)及工程項目各方的足夠重視。后期服務應該配合工程建設有效展開，所以它基本貫穿于施工、項目試運行、運行以及項目使用階段。要做好每一階段內(nèi)容的設計驗證和質(zhì)量檢查工作，隨時為工程內(nèi)容質(zhì)量改進提出技術參考依據(jù)。在施工完畢，項目投入使用的后期服務階段中，回訪工作必不可少。重大電力通信工程項目通過及時有效回訪來實現(xiàn)對項目設計建設中問題的補缺，也是企業(yè)及建設方對項目成功經(jīng)驗及教訓的再學習過程，這不但利于用戶，更對電力企業(yè)維持穩(wěn)定高效發(fā)展具有利好。因此，電力企業(yè)及建設方應該積極接受用戶反饋意見，隨時做好對項目問題的改進工作準備，同時認真歸納和總結(jié)用戶意見，以為以后的同類工程項目積累經(jīng)驗，不斷精煉技術經(jīng)驗。

3.推行設計質(zhì)量標準化理念。推行設計質(zhì)量標準化理念對電力通信工程來說，設計規(guī)范規(guī)程能夠衡量項目設計及其文件內(nèi)容的素質(zhì)高低，所以設計質(zhì)量標準化理念推行也是為了解決工程項目中所存在的設計深度不足、設計表達差錯等現(xiàn)實質(zhì)量問題。電力企業(yè)為了全面推行設計質(zhì)量標準化概念，迎合時展，應該搭建FTP服務器，將電力通信工程項目中所涉及的所有技術規(guī)范、標準及相關內(nèi)容double上傳到FTP服務器中，確保企業(yè)內(nèi)員工能夠隨時瀏覽學習。該標準化工作作為電力通信工程設計質(zhì)量管控的基礎策略，其建設目的就是為了有效消除行業(yè)間技術規(guī)范理解差異，解決在項目設計中可能存在的校對及審核矛盾，最大限度降低返工工作量，實現(xiàn)提高工程效率及設計質(zhì)量控制的目標，從而適應新技術的現(xiàn)實發(fā)展及應用過程。

三、結(jié)語

電力企業(yè)建立科學全面的通信工程設計體系是十分有必要的，它提高了項目設計過程中參與全員的責任心，也形成了針對工程設計的嚴格和細致把控原則，強大了電力企業(yè)在市場中的核心競爭力。但企業(yè)也要意識到，工程項目設計質(zhì)量控制與提高并非一蹴而就的短期目標，它也要經(jīng)過漫長的質(zhì)量管理內(nèi)容調(diào)整和科學發(fā)展過程，在不斷更新設計技術及質(zhì)量管理實踐理論的基礎上發(fā)展電力通信工程，實現(xiàn)階梯漸進性提高。

參考文獻：

[1]雷曉.電力通信工程設計和質(zhì)量控制[J].數(shù)字化用戶,2013(25):13-13.

[2]桂曉明,雍蓉.論電力通信工程設計質(zhì)量的有效控制[J].中國新通信,2015(18):50-50.

篇7

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

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

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

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

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

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

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

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

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

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

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

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

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

2 對需求變更的控制策略

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

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

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

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

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

3 需求變更的控制流程

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

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

4 應注意的問題

目前，很多企業(yè)都在遵循質(zhì)量與健康、安全和環(huán)境管理體系的互相補充、相輔相成，在電力施工過程中，他們?yōu)榱嗽谛枨笞兏凶裱|(zhì)量、安全和環(huán)境管理的一體化，為了更好地實施“ISO9000質(zhì)量管理體系”和“HES-MS”的管理，他們將“ISO9000-QMS”、“HSE-MS”、“ISO14000-EMS”整合成一個系統(tǒng)，但是在具體操作中會遇到很多問題：

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

2、機構要統(tǒng)一，發(fā)揮資源優(yōu)勢。很多企業(yè)把質(zhì)量、安全、環(huán)保等職能部門都分開屬于不同部門管理，這樣日程工作中協(xié)調(diào)減少了，增加了管理費用，造成了資源的浪費，因此各個部門機構要配備管理人員，從實際出發(fā)，健全管理機構。

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

5 結(jié)論

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

參考文獻

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

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

篇8

交通銀行是中國第一家全國性的國有股份制商業(yè)銀行，也是中國五大主要商業(yè)銀行之一。隨著業(yè)務的不斷發(fā)展、技術不斷更新、項目規(guī)模不斷擴大、開發(fā)人員數(shù)量不斷增加，特別是交行貸記卡及數(shù)據(jù)大集中項目的開發(fā)和上線，使得交行在軟件資源控制和生產(chǎn)維護管理上遇到了前所未有的挑戰(zhàn)。在項目實施過程中，會使用各種技術、采用不同的程序語言、數(shù)據(jù)庫、中間件等，從而導致種類繁多的文件產(chǎn)生，文件的變化和不同的狀態(tài)都直接影響了最終產(chǎn)品的和維護。

這已不單純是技術問題，而是管理的問題。隨著軟件技術的發(fā)展，變更管理越來越成為管理的重點，其中更為注重的是對變更控制流程的強化。交行信息科技部正面臨提供更高質(zhì)量產(chǎn)品以及更短開發(fā)生命周期和更簡便維護的壓力。

尋找癥結(jié)

為了加強程序版本的管理，交行在項目初期就開始嘗試使用操作系統(tǒng)自帶的版本管理工具，但隨著業(yè)務的發(fā)展，其功能已不能滿足需要。交通銀行版本管理的負責人說:“分散在各分行的數(shù)據(jù)集中到總行數(shù)據(jù)中心來管理，生產(chǎn)變更的風險比較大。而相對而言，程序變更是生產(chǎn)系統(tǒng)方面最大量的變更。所以，交行要保證全行生產(chǎn)變更的安全，首先要對程序的變更進行有效的管理?！?/p>

CA應用開發(fā)生命周期管理的觀點進入了交行的視野。作為一套全面的解決方案，AllFusion的引入策略非常重要，其應用需要循序漸進地逐步引入才能確保投資能夠得到有效的回報?；趯ψ陨砬闆r的科學評估，交行找到對自身影響最大的不成熟點―版本管理―進行改進。交通銀行版本管理的負責人認為:“程序版本管理混亂可能會導致項目進度延遲，甚至不能按時完成，頻繁的變更以及需求變化，給安全生產(chǎn)的效率和質(zhì)量都產(chǎn)生了不可估量的后果?！?/p>

為了保證貸記卡和數(shù)據(jù)大集中項目的順利實施，工程進度緊，管理人員在每批人做完項目之后再做整理，辛苦自不必說，還很難保證質(zhì)量。通過有效地軟件版本管理，不僅可幫助軟件開發(fā)團隊提高軟件開發(fā)過程的穩(wěn)定性，而且還保證軟件產(chǎn)品具有良好的可維護性和可重用性，為當前形勢下要求的快速建立高質(zhì)量應用提供必要的支撐。

2004年9月，交行正式上馬AllFusion Endevor Change Manager變更管理解決方案，對所管理的對象集中受控。需要對受控的對象進行編輯的時候，將對象檢出系統(tǒng)，在開發(fā)環(huán)境中經(jīng)過修改后再檢入到系統(tǒng)中，在檢入時系統(tǒng)將比較檢入的對象與檢出的對象之間是否存在不同。當存在不同時，系統(tǒng)將以一個新的版本號對變更進行標識，所標識的變更將被以增量的方式存儲下來。在后續(xù)的技術發(fā)展中，又在版本主干的基礎上增加了分支及歸并的支持，以支持對受管理的對象的并發(fā)的修改工作。

“銀行業(yè)務開發(fā)需求總是層出不窮，建設版本管理系統(tǒng)的真正挑戰(zhàn)就是在不影響生產(chǎn)力的情況下將控制引入應用軟件的運維過程?！眳⑴c進行交行版本管理系統(tǒng)建設的CA技術顧問郭進說。

另外，還有一個磨合的問題。貸記卡和數(shù)據(jù)大集中是兩個不同的項目，用同一個流程把這兩個項目涉及的不同理念、操作習慣、人員等都真正用標準的流程化管理起來，難度可想而知?！?002年交行才使用了大型機，所以我們?nèi)狈@方面的經(jīng)驗，必須從零開始。建立版本變更控制的流程，組織架構、人員配備等要和技術工具相結(jié)合，是個新的挑戰(zhàn)。”

版本管理自動化

如今，交行的版本管理系統(tǒng)，能夠提供檢出、檢入、分支的創(chuàng)建與分支的歸并等功能。通過這些功能，交行實現(xiàn)了對受控對象的變更的歷史變更軌跡的記載和變更的控制和管理，同時支持團隊的并發(fā)工作需求。

第一，有效的安全控制和備份保護機制保護軟件資產(chǎn)。之前因缺乏相關工具，交行信息建設的項目出現(xiàn)過一些意想不到的“干擾”，目標程序和源碼不能相互對應的情況時有發(fā)生，一些運行時間較長的應用都不敢輕易變更的狀況。同時抵御風險的能力也大大降低。通過CA的變更管理解決方案，交行可方便地對不同階段、不同用戶的版本進行統(tǒng)一的管理，保障了目標程序和源碼的一致性、完整性。

第二，自動化版本管理與管理系統(tǒng)。交通銀行通過AllFusion Endevor Change Manager變更管理解決方案，在應用系統(tǒng)的開發(fā)、測試和投產(chǎn)過程中，實現(xiàn)了自動化的版本控制，并且能在短時間內(nèi)提供其它分支機構的任何版本，確保軟件產(chǎn)品能夠正確地運行在目標機器上面。通過提供全面的安全策略，使得不同的用戶只能訪問修改不同的環(huán)境，進一步保障了數(shù)據(jù)的安全性。

第三，保證各項目最終更新至生產(chǎn)系統(tǒng)流程的合理性及一致性。在AllFusion Endevor Change Manager的功能中可配合AllFusion Change Manager Enterprise Workbench軟件與AllFusion CCC HARVEST集成，實現(xiàn)Mainframe平臺的應用系統(tǒng)的變更與相對應的前置系統(tǒng)的應用系統(tǒng)的一致性管理，從而保證各項目最終更新至生產(chǎn)系統(tǒng)流程的合理性及一致性，達到最大的一體性。

篇9

關鍵詞 WCDMA；站址選擇；隔離度；初勘；復堪；設計變更

中圖分類號TP39 文獻標識碼A 文章編號 1674-6708（2013）92-0192-03

1背景及范圍

WCDMA網(wǎng)絡的建設在中國通信市場中是一種新型的應用，由于其網(wǎng)絡本身的自干擾特性及功率控制性能要求造成了網(wǎng)絡規(guī)劃的特殊性與復雜性，尤其在無線網(wǎng)絡的規(guī)劃與選址過程中，須充分考慮當?shù)氐匦?、地貌特點及與現(xiàn)有網(wǎng)絡的結(jié)合；在工程建設過程中須進一步嚴格站址變更審核、審批流程，確保規(guī)劃方案的落實，保障網(wǎng)絡效果。

1.1站址選擇原則

基站選址是網(wǎng)絡規(guī)劃中的一項最重要的基礎工作?；疚恢玫倪x擇，關系到基站能否實現(xiàn)設計要求達到的覆蓋、質(zhì)量指標；對于CDMA等自干擾系統(tǒng)，同時也會影響到本基站和周邊基站的容量、數(shù)據(jù)業(yè)務速率，進而影響到整個網(wǎng)絡的覆蓋、容量、質(zhì)量指標。因此，基站位置的選擇務必謹慎、合理。以下是站址選擇的相關要求：

1.2必須保障的選址要求

3）站址周圍應比較開闊，50m半徑范圍內(nèi)無高層建筑或障礙阻擋；對于定向天線，在天線主瓣覆蓋方向100米內(nèi)應無高于基站天線高度的高大建筑物阻擋；

4）根據(jù)設站目的確定站址高度，市區(qū)基站天線掛高比周圍建筑物平均高度高10m～15m，最少不得少于5m；郊區(qū)基站天線掛高根據(jù)地形、覆蓋要求等確定，一般要比覆蓋目標高40m～60m，并在滿足技術要求的前提下盡量利用地形減少鐵塔高度，降低配套投資；

9） 基站的站址不宜設在易燃、易爆及有腐蝕性物品的倉庫和材料堆積場，以及在生產(chǎn)過程中容易發(fā)生火災和爆炸危險的工業(yè)、企業(yè)附近。

1.4站址選擇流程

基站覆蓋的目標場所選取應符合聯(lián)通移動網(wǎng)發(fā)展的需求。根據(jù)聯(lián)通的市場與業(yè)務發(fā)展需求，由設計院編制可研與設計文件，提出工程建設的設計目標，提供基站規(guī)劃和選址的原則，指導工程的建設實施。聯(lián)通移動網(wǎng)絡建設部門組織網(wǎng)優(yōu)部、市場部等相關部門，通過投訴資料收集分析、網(wǎng)絡摸查、實地調(diào)研等工作，篩選和論證建設需求的目標場所。

對于所提出的目標場所，應通過初勘、業(yè)主談判、復堪、施工圖紙設計4個主要環(huán)節(jié)開展設計工作；在方案實施過程中根據(jù)需要選擇設計變更環(huán)節(jié)。工作流程如下圖所示。

1） 初堪階段

根據(jù)設計目標區(qū)域和基站站址、站高要求，在合理區(qū)域內(nèi)選定意向站址，要求有1個主用站址和1～2個備用站址。輸出結(jié)果為勘查選站單，選站單要包含位置、天線安裝方式、天線安裝高度、天線方位角和下傾角、周圍環(huán)境等信息，并盡量附帶地圖信息（見附件1）。

2）業(yè)主談判階段

根據(jù)初堪選站單和業(yè)主進行談判，優(yōu)選主用站點。談判時，要明確機房、天面可以使用區(qū)域、是否可以建設樓等增高架等。

3）復堪階段

根據(jù)談判階段確定下來的站址，進行詳細勘查。復堪階段要明確機房內(nèi)所有設備、走線架、饋線窗的位置和安裝方式，要明確天線安裝方式、高度、方向角、下傾角，并根據(jù)復堪結(jié)果，能提供詳細而準確的施工圖紙和材料清單，并對特別事項進行說明（如加固）。

4）施工圖紙設計階段

設計院根據(jù)復堪結(jié)果繪制施工圖紙，圖紙要求能反映現(xiàn)場情況并指導施工；設計院提交圖紙后，建設單位負責組織建設、優(yōu)化、維護等部門進行施工圖設計會審。會審通過后再提交給施工單位進行施工。

2基站安裝及站址變更管理要求

由于WCDMA網(wǎng)無線站址位置的變化會影響到整體網(wǎng)絡信號的強度分布、網(wǎng)絡干擾等，在工程施工過程中，須嚴格按照設計圖紙規(guī)范施工，如因施工現(xiàn)場發(fā)生變化，或因業(yè)主原因需要對設備、天線等的安裝位置、安裝方式發(fā)生變化，須履行設計變更審批流程。

2.1基站安裝及站址變更管理要求

1）設計文件批準后，就具有一定的嚴肅性，不能隨意進行修改和變更；

2）在移動工程施工過程中，設計部門、主要設備廠家應配備常駐現(xiàn)場技術人員，配合工程施工，及時上報設計文件的執(zhí)行情況；

3）站址變更可由建設單位自行提出，也可由承包單位提出。施工圖設計文件交付建設單位使用后，如果出現(xiàn)由于建設單位要求或現(xiàn)場施工條件的變化等原因而引起設計變更，必須辦理書面變更手續(xù)；

4）在無線基站設備安裝工程開工之前，設計人員必須到施工現(xiàn)場進行二次勘察，填寫《二次勘察確認單》，對設計位置及工藝要求進行核實，經(jīng)當?shù)胤止竟こ讨鞴懿块T簽認后方可開工。如工程現(xiàn)場與施工圖紙設計要求不符，須立即通知當?shù)胤止竟こ讨鞴懿块T提出設計變更申請；

5）移動網(wǎng)工程設計變更發(fā)生后，必須視變更內(nèi)容所涉及的范圍經(jīng)由相關部門批準同意后方可實施。具體要求如下：

（1）盟（市）分公司在進行無線基站選址及物業(yè)談判過程中，由于業(yè)主干擾或其他原因需對站址位置、天線掛高、天線方位角、下傾角進行調(diào)整，須按照如下流程處理：

①選定的樓宇、站址變化挪動在1/4站距之內(nèi)，須由分公司建設主管部門提出設計變更需求，并組織網(wǎng)優(yōu)、主設備廠家督導及設計人員審核，如移動后的站點位置比較合理，須填寫《設計變更現(xiàn)場確認單》，由設計院負責重新勘察出圖；

②基站站址位置沒有變化，由于現(xiàn)場條件的限制，需對天線掛高、天線方位角、下傾角進行調(diào)整，須由當?shù)毓窘ㄔO主管部門提出設計變更需求，并組織優(yōu)化、主設備廠家督導及設計人員審核，如不影響網(wǎng)絡規(guī)劃效果，須填寫《設計變更現(xiàn)場確認單》，由設計院負責重新勘察出圖；

③由于工程設計方案變更，造成配套工程建設投資增加，如追加投資額在批復概算范圍之內(nèi)，額度在5萬元之內(nèi)的，須由分公司建設主管部門填寫《設計變更審批單》，并經(jīng)分公司主管領導確認后實施；

④如屬上述范圍之外的設計變更，須由分公司建設主管部門填寫《設計變更審批單》，并經(jīng)分公司主管領導審批同意后，通過OA系統(tǒng)“通用流程”報省公司建設主管部門審批。

（2）在工程施工過程中，工程承包單位、主要設備廠家、現(xiàn)場設計人員負責對基站位置及工藝要求進行核實，如遇業(yè)主干擾或現(xiàn)場施工條件不符，需對施工設計方案進行變更，須于24小時之內(nèi)通知分公司建設主管部門發(fā)起設計變更需求。分公司組織進行現(xiàn)場查勘后，參照上述（1）決定是否報上級主管部門審批。

5）建設單位和承包單位在提出設計變更要求時，要進行統(tǒng)籌考慮，確定其必要性，同時將設計變更對網(wǎng)絡建設效果、工程造價及工期的影響分析清楚，報上級主管部門審批；

6）省公司建設部門對盟（市）分公司上報的設計變更申請進行歸口管理，視變更內(nèi)容所涉及的范圍及規(guī)模組織有關部門進行審核，并報主管領導批示同意后，進行設計變更。

2.2移動工程站址變更及審批流程圖

篇10

關鍵詞：變更管理；版本管理；CMDB；ITIL

中圖分類號：TP311.52

二十一世紀全球信息化增速顯著，信息系統(tǒng)的地位已經(jīng)從原先的為了取代紙筆的環(huán)保目的，逐步融入到生產(chǎn)生活的方方面面中去，成為新產(chǎn)業(yè)的推動力。企業(yè)信息化的程度決定著企業(yè)在行業(yè)中的競爭力水平。高度信息化催生出的對信息系統(tǒng)的高度依賴也給企業(yè)的日常生產(chǎn)帶來了風險。如何建立一套適合大型企業(yè)的應用系統(tǒng)變更管理成為了企業(yè)IT部門規(guī)劃工作中的焦點問題。在實施變更管理的過程中，我們主要關心三點：（1）如何與現(xiàn)有工作流程進行結(jié)合，使工作有序高效的持續(xù)進行。如果要修改現(xiàn)有流程，怎樣才能更科學合理的定義各類用戶角色；（2）如何利用CMDB的特點及CMDB中的配置項數(shù)據(jù)資源來實施變更管理；（3）如何將版本管理和變更管理相互結(jié)合。

1 綜述

1.1 CMDB。20世紀80年代末，英國政府部門CCTA指定了ITIL（Information Technology Infrastructure Library）。ITIL經(jīng)歷了近四十年的發(fā)展，現(xiàn)如今最新的版本3已經(jīng)相當成熟，它整合了前兩個版本的精華[1]，并且擴展內(nèi)容，融入了IT服務管理領域的最佳實踐。ITIL為IT部門提供了科學的框架管理方案，指導IT工作更科學、有效地開展。

ITIL的核心模塊是“服務管理”，而這個核心模塊又被劃分為“服務提供”和“服務支持”，其中配置管理、變更管理、管理、事件管理、問題管理和服務臺屬于“服務支持”流程。[2]配置管理數(shù)據(jù)庫（Configuration Management Database，簡稱CMDB）是以配置管理為基礎，通過信息技術手段實現(xiàn)變更管理、管理、事件管理等多種功能的信息平臺。CMDB在“服務支持”流程中占據(jù)著核心地位，也是企業(yè)信息工作的核心。ITIL定義了CMDB必須追蹤六個方面的內(nèi)容，硬件、軟件、網(wǎng)絡通信、工作人員、位置以及文檔等等，這些都被稱為CMDB的配置項。雖然CMDB名字里有個“數(shù)據(jù)庫”，但它并非傳統(tǒng)意義上的數(shù)據(jù)庫。CMDB不僅僅存儲了所有的IT元素，還可以存儲并以層次結(jié)構的方式展示它們之間的相互聯(lián)系。CMDB的特殊之處在于它必須擁有4個至關重要的功能，即聯(lián)邦性、協(xié)調(diào)性、同步性、可視化。只有遵守了這四大原則，CMDB才能實現(xiàn)對IT資產(chǎn)的梳理，減少故障產(chǎn)生幾率提高響應時間，有效提高工作效率與用戶滿意度，更好的理解業(yè)務降低新項目的成本[3]。

1.2 變更管理。軟件工程中信息系統(tǒng)的需求被定義為用戶對應用系統(tǒng)實現(xiàn)的想法及目標要求，通俗的講就是使用該應用系統(tǒng)或軟件最終可以做什么。變更管理可以定義為：合理的收集、整理、篩選需求之后，安排制定開發(fā)計劃，在開發(fā)的項目階段對需求的滿足情況進行跟蹤，在代碼層面對版本進行管理，保證軟件在生命周期內(nèi)的穩(wěn)定運行。需求變更管理是ITIL模型的一部分，也是企業(yè)IT部門日常工作的核心。需求管理包括：需求控制、需求跟蹤、版本管理等。變更管理的目的是控制需求提交、審核、篩選、安排計劃等環(huán)節(jié)，將變更可能對生產(chǎn)造成的影響降到最低。變更管理的目標是高效的控制，快速的響應，科學的安排，可查詢可回溯。

1.3 版本管理。在應用系統(tǒng)的開發(fā)過程中，多人參與開發(fā)、分階段開發(fā)、修正系統(tǒng)錯誤等等原因，使得代碼必須進行反復的修改而非徹底重寫，為了節(jié)約人力成本縮短系統(tǒng)開發(fā)周期，引入了應用系統(tǒng)的版本。版本管理，或版本控制就是在應用系統(tǒng)的聲明周期里對上述的應用系統(tǒng)涉及到的不同版本進行管理控制。版本管理是是變更管理的核心。版本管理的核心思想是：科學的定義軟件版本號，對不同版本的源代碼進行備份，按照計劃對軟件版本進行升級，遇到突況對版本進行回退。

1.4 SVN與SVNKIT。SVN是Apache軟件基金會的一款開源、免費的版本管理軟件，SVN支持各種主流的編程語言。SVN由客戶端和服務器端兩部分組成。用戶在服務器端先建立代碼庫（repository），而后將代碼通過客戶端的add和commit操作提交到服務器端。用戶可以通過客戶端的update操作獲取最新版本的代碼。每個版本的代碼都在服務器端留有備份，如果需要回退版本，可以在客戶端使用update to revision回退到指定版本。SVN也支持Tag和分支（branch），開發(fā)人員可以通過使用SVN實現(xiàn)運維和項目的同時進行。SVN具有集成簡單、加密存儲、合理利用帶寬等特點。

SVNKIT是一種開源、免費的純java開發(fā)工具庫，它支持各種操作系統(tǒng)。通過使用SVNKIT可以在自己開發(fā)的java應用中實現(xiàn)與SVN客戶端相同的各種功能。

2 角色職責定義

為了維持大型企業(yè)數(shù)量眾多的信息系統(tǒng)的穩(wěn)定運行，明確的角色職責定義是必要的。

2.1 應用負責人的職責為自始至終地負責信息系統(tǒng)項目的立項、開發(fā)、運維，來自用戶的需求首先將會被提交到應用負責人，由應用負責人進行整理、篩選，并在變更管理系統(tǒng)中登記。參與項目生命周期的全過程。對于信息系統(tǒng)的技術運用及業(yè)務需求均有深層次的理解。

2.2 系統(tǒng)開發(fā)人員負責對信息系統(tǒng)進行開發(fā)。項目開發(fā)階段和運維階段的開發(fā)人員可以由不同人員擔任，但都必須對信息系統(tǒng)開發(fā)的技術運用有一定的認識。系統(tǒng)開發(fā)人員可以自行搭建開發(fā)環(huán)境部署應用系統(tǒng)。

2.3 開發(fā)運維委員會由各節(jié)點工作人員組成的開發(fā)運維委員會每周召開例會，將應用負責人篩選過的在系統(tǒng)中登記的需求進行優(yōu)先級排序，并賦予批次號、核對生產(chǎn)計劃時間等信息。系統(tǒng)開發(fā)人員和應用負責人可以根據(jù)批次號展開工作。測試、生產(chǎn)人員可以根據(jù)系統(tǒng)中的記錄做好工作計劃，保證工作的準時、順利進行。

2.4 代碼檢查人員對信息系統(tǒng)開發(fā)設計的技術有相當?shù)牧私?，并且會根?jù)企業(yè)對于信息系統(tǒng)的編碼標準規(guī)范對代碼、數(shù)據(jù)庫腳本、測試用例等是否符合規(guī)范進行檢查。

2.5 測試人員負責將開發(fā)完成，且已經(jīng)在開發(fā)環(huán)境完成測試的應用系統(tǒng)部署到測試環(huán)境，在測試環(huán)境數(shù)據(jù)庫執(zhí)行數(shù)據(jù)庫腳本的專職人員。除此之外，測試人員還需要維護測試環(huán)境的日常運行，參數(shù)調(diào)整等等。生產(chǎn)前的各項手續(xù)，各類申請驗收單據(jù)也都是由測試人員保管，是審核流程中的關鍵節(jié)點。

2.6生產(chǎn)人員負責將在測試環(huán)境通過各項測試，且手續(xù)齊全的應用系統(tǒng)部署到測試環(huán)境，在生產(chǎn)環(huán)境數(shù)據(jù)庫執(zhí)行數(shù)據(jù)庫腳本的專職人員。企業(yè)內(nèi)部除生產(chǎn)環(huán)境人員以外，無人可以直接接觸生產(chǎn)環(huán)境。

3 流程設計

應用負責人填寫應用系統(tǒng)問題數(shù)據(jù)及相關的信息，并上傳此次變更涉及的代碼及文檔；開發(fā)運維委員會安排變更開發(fā)計劃，對本次變更賦予變更號；由代碼檢查人員檢查代碼是否符合相關規(guī)范標準，并給予打分；如檢查結(jié)果不通過，則退回由開發(fā)人員重新修改代碼直到檢查通過。與此同時，測試人員到測試環(huán)境中間件；測試人員根據(jù)變更號從SVN上獲取對應的代碼，編譯代碼打包部署到測試環(huán)境中間件，然后由應用負責人和開發(fā)人員進行系統(tǒng)功能測試；在測試通過后且代碼檢查人員檢查通過后，應用負責人提交相關經(jīng)領導簽字確認的驗收文檔；在確認生產(chǎn)所需停機時間后，由生產(chǎn)人員將應用系統(tǒng)到生產(chǎn)環(huán)境中間件，完成后通知應用負責人。如發(fā)現(xiàn)生產(chǎn)環(huán)境在升級到新版本之后存在問題，可由生產(chǎn)環(huán)境人員將生產(chǎn)環(huán)境回退到上一個版本，確保生產(chǎn)環(huán)境應用的穩(wěn)定性及可用性。應用負責人進入系統(tǒng)修改對應此次變更的應用系統(tǒng)問題記錄的狀態(tài)，將open狀態(tài)改為close，并錄入生產(chǎn)的日期。

4 系統(tǒng)相關設計實現(xiàn)

系統(tǒng)主要實現(xiàn)了應用負責人錄入信息并將本地文件同步到SVN服務器生成記錄，開發(fā)運維委員會修改記錄狀態(tài)維護記錄信息下載SVN服務器上的增量文件，應用負責人最后修改記錄狀態(tài)的功能。即變更從申請?zhí)岢觯介_發(fā)測試，直到開發(fā)完成、生產(chǎn)、變更申請被關閉的變更管理的整個流程。

4.1 使用SVNKIT的步驟。（1）導入開發(fā)所需的SVNKIT類；（2）聲明客戶端管理類；（3）初始化版本庫；（4）設置版本庫的訪問鏈接、用戶名、密碼等參數(shù)，用以連接SVN服務器訪問代碼庫；（5）創(chuàng)建客戶端管理類實例；（6）進行SVN操作。

4.2 使用SVNKIT實現(xiàn)系統(tǒng)功能。用戶創(chuàng)建需求申請時選擇或輸入的信息，系統(tǒng)統(tǒng)一中間件服務器與SVN服務器上對該應用的標識，根據(jù)用戶輸入或選擇的頁面控件值獲取字符串拼接出中間件服務器的上傳文件名，然后轉(zhuǎn)換為對應SVN服務器的版本庫路徑。

使用SVNKit后，有如下優(yōu)點：（1）預先設定的目錄結(jié)構使得代碼與文檔的管理更科學高效；（2）在每一次執(zhí)行此功能時首先執(zhí)行一次刪除操作，是為避免上次執(zhí)行上傳操作的過程中刪除中間件服務器目錄下文件未能完成；（3）以用戶每次錄入變更申請時自動產(chǎn)生的序號與變更標題組成SVN代碼庫中的文件夾名，與頁面上的申請記錄一一對應，一目了然便于管理；（4）系統(tǒng)自動判定文件在SVN服務器端是否已經(jīng)存在，如果已經(jīng)存在則進行commit操作，如不存在則先執(zhí)行add操作再進行commit。

5 結(jié)束語

隨著時代的發(fā)展，科技的進步，信息系統(tǒng)的發(fā)展有目共睹。企業(yè)規(guī)模的大幅提升，業(yè)務邏輯的變化催生出越來越多的變更。在這樣的情況下，版本管理與變更管理在IT項目中也變得越來越重要，在企業(yè)中實施基于SVNKit的變更管理是一個非常具有挑戰(zhàn)性的項目。本文根據(jù)ITIL的體系規(guī)范，結(jié)合企業(yè)的實際情況，制定合理的流程，編寫高效的應用系統(tǒng)，設計并實現(xiàn)了變更管理。此變更管理系統(tǒng)已經(jīng)在企業(yè)IT部門進行日常使用，從兩年的使用情況來看，系統(tǒng)大大提升了員工的工作效率及質(zhì)量，節(jié)約了人力成本，有效的提升了IT部門的影響力以及在企業(yè)中的作用。這對于致力于建設IT的國內(nèi)企業(yè)具有極大的參考價值。

參考文獻：

[1]張述冠.ITIL3.0 一個更趨完美的烏托邦[J].CIO Weekly，2007（26）：41-44.

[2]朱瑋.IT服務變更管理設計與實現(xiàn)[J].軟件導刊，2013（09）：38-39.

[3]趙成棟.構建統(tǒng)一精準的CMDB[J].軟件世界，2006（06）：76.