導(dǎo)語：如何才能寫好一篇變更管理流程，這就需要搜集整理更多的資料和文獻，歡迎閱讀由公務(wù)員之家整理的十篇范文，供你借鑒。

篇1

按照UCM的方法，我們也將CPMM的組成部分抽象為不同的工作流，其中最重要的工作流程包括：

1、變更預(yù)估流程 （Change Forecast Process，CFP）；

2、變更請求與處理流程 （Change Apply and Manage Process，CAMP）；

3、變更評估流程（Change Evaluation Process，CEP）。

CFP在軟件工程項目的初期對工程中可能產(chǎn)生的變更進行預(yù)估。這是在軟件工程項目中經(jīng)常被忽略的流程。通過這個流程，可以在軟件的時間和經(jīng)費預(yù)算中提前考慮變更所帶來的影響，同時在軟件項目的設(shè)計和規(guī)劃中預(yù)留接納變更的空間。保證在產(chǎn)生變更的情況下軟件工程項目仍然能有序地進行和正常地完成。

變更預(yù)估是軟件工程中比較難以把握的方面，目前的預(yù)估都是依靠個人經(jīng)驗的主觀判斷。這樣的預(yù)估存在準確性低和不能量化的缺點，這對軟件工程本身并不能提供有用的幫助。CPMM中的CFP流程對軟件工程中的變更評估采用定量的計算方式。在進行項目的需求分析時，通過對影響項目變更的因素，如評估項目的創(chuàng)新程度 T(1)、客戶對項目的把握程度 T(2)、我方對項目的把握程度 T(3)和需求調(diào)研的詳細程度 T(4)等方面的數(shù)值，計算出軟件項目的各個過程中可能發(fā)生的變更概率。由此對軟件工程項目的預(yù)算、項目規(guī)劃提供有力支持。

軟件工程步驟i可能產(chǎn)生的變更概率如下面“變更預(yù)估公式”所示：

其中：V (i)為軟件項目過程i完成時可能發(fā)生的變更概率。

C (ij)為各項因素對變更比率產(chǎn)生影響的系數(shù)，這個系數(shù)需要根據(jù)不同的開發(fā)小組情況和項目類型有所不同。系數(shù)的產(chǎn)生和修改則需要根據(jù)變更評估流程產(chǎn)生和修改。

D (i)為修正因子。

CAMP是在項目中接納變更的處理流程，包括變更的提交、審批、實施及完成。CAMP主要強調(diào)通過規(guī)范的方式接納變更，并且通過各種有效的手段嚴格控制變更被引入的方式和時間，確保系統(tǒng)開發(fā)的有序進行。CAMP主要通過圖1所示的流程處理變更：

篇2

[關(guān)鍵詞] 商業(yè)銀行；IT變更管理；信息化

doi ： 10 . 3969 / j . issn . 1673 - 0194 . 2014 . 03. 016

[中圖分類號] F830.33；TP315 [文獻標識碼] A [文章編號] 1673 - 0194（2014）03- 0030- 04

1 概 述

IT變更管理信息化是針對IT項目生存周期中的變更進行管理的過程，而商業(yè)銀行IT變更管理（以下簡稱“商業(yè)銀行變更管理”、“變更管理”）信息化是針對商業(yè)銀行要求系統(tǒng)穩(wěn)定性高、風(fēng)險可控性高、數(shù)據(jù)安全性高以及業(yè)務(wù)影響?。ā叭咭恍　保┑奶攸c，將程序和數(shù)據(jù)變更的管理過程通過信息系統(tǒng)實現(xiàn)信息化、自動化的過程。通過變更管理信息化建設(shè)可以有效減少因硬軟件問題造成業(yè)務(wù)中斷，降低操作風(fēng)險[1]，實現(xiàn)變更管理自動化，全程可控可回退。

目前主要針對管理信息化和變更管理兩方面的研究較多，但對變更管理信息化，尤其是商業(yè)銀行IT變更管理信息化方面的研究較少。由于商業(yè)銀行變更管理對業(yè)務(wù)系統(tǒng)穩(wěn)定性要求高，商業(yè)銀行組織結(jié)構(gòu)復(fù)雜，隨著業(yè)務(wù)發(fā)展各項規(guī)章制度調(diào)整頻繁，信息系統(tǒng)多樣，數(shù)據(jù)管理和共享要求多，信息化需求較多，我們需有針對性地研究其信息化方法，以變更操作信息化、自動化為核心，研究其所需方法、規(guī)劃、架構(gòu)和技術(shù)。

商業(yè)銀行變更管理信息化應(yīng)覆蓋現(xiàn)有變更流程及要素，基于業(yè)務(wù)連續(xù)性及系統(tǒng)穩(wěn)定性要求，達到變更全流程可回退、可控、可驗證，對變更后系統(tǒng)運行情況可跟蹤、可驗證、可評價，對系統(tǒng)變更的原因、方法、效果、問題可記錄、可搜索、可挖掘，建立專家知識庫系統(tǒng)，及時響應(yīng)變更流程及變更要素變化，建立快速響應(yīng)與持續(xù)開發(fā)運維機制。本文結(jié)合商業(yè)銀行IT變更特點，對商業(yè)銀行變更管理信息化建設(shè)過程進行了研究，對層次設(shè)計、開發(fā)模式、團隊架構(gòu)、技術(shù)實現(xiàn)等方面進行探討，并在大型商業(yè)銀行進行實踐。

2 變更管理

2.1 組織結(jié)構(gòu)

商業(yè)銀行變更管理的組織結(jié)構(gòu)涉及科技管理部門、應(yīng)用開發(fā)部門、應(yīng)用保障部門、運維部門以及業(yè)務(wù)部門等多個部門（見圖1），科技管理部門負責(zé)制定變更評審管理制度，組織協(xié)調(diào)變更評審工作開展，制定與變更評審報告；應(yīng)用開發(fā)部門負責(zé)項目研發(fā)、程序數(shù)據(jù)修改與測試、變更申請、變更資源準備與變更文檔填寫；應(yīng)用保障部門負責(zé)安全措施等進行評審，根據(jù)評審結(jié)果對變更進行審批以及特護管理；運維部門負責(zé)制訂變更實施計劃，變更實施，對變更實施結(jié)果進行；業(yè)務(wù)部門負責(zé)組織實施業(yè)務(wù)驗證。

2.2 管理流程

商業(yè)銀行系統(tǒng)變更過程要進行安全審查，采取風(fēng)險控制措施[2]，變更管理流程以變更評審為核心，包括變更申請、變更受理、變更評審、變更實施、變更驗證、變更回顧6個環(huán)節(jié)（見圖2），應(yīng)用開發(fā)部門、應(yīng)用保障部門和運維部門對應(yīng)用系統(tǒng)程序、數(shù)據(jù)和資源發(fā)出變更申請，并準備程序、數(shù)據(jù)、硬件設(shè)施等變更資源以及測試報告、風(fēng)險分析報告、投產(chǎn)變更實施方案、應(yīng)急方案等變更文檔；應(yīng)用保障部門承擔(dān)變更評審受理工作并分配變更評審任務(wù)，變更評審人員對變更進行評審準備；變更評審由評審團隊通過召開會議的方式進行，會議對變更合規(guī)性、風(fēng)險性等方面進行審查，評審團隊一般由來自應(yīng)用開發(fā)部門、應(yīng)用保障部門、運維部門的技術(shù)專家組成；變更實施一般由商業(yè)銀行運維部門（如數(shù)據(jù)中心）承擔(dān)，通過變更評審批準的變更方能授權(quán)進行實施，實施部門根據(jù)評審意見與實施方案制訂完備的實施計劃并對變更進行實施；變更實施完成之后，由業(yè)務(wù)部門和運維部門按照驗證計劃實施驗證，對驗證結(jié)果進行反饋，對不符合驗證計劃要求的變更進行回退；科技管理部門對變更評審與實施情況進行分析，并定期以報告的形式在相關(guān)部門進行，使管理層和變更人員及時了解當(dāng)前變更評審、實施和運行情況。

3.2 開發(fā)模式

商業(yè)銀行由于業(yè)務(wù)多樣性、分行特色、歷史存續(xù)問題等造成系統(tǒng)類型的多樣性，針對不同系統(tǒng)的變更方法多樣，為適應(yīng)業(yè)務(wù)發(fā)展，穩(wěn)定性要求也在不斷演變。商業(yè)銀行變更類型包括程序變更、數(shù)據(jù)變更、硬件變更、架構(gòu)變更、業(yè)務(wù)流程變更等方面，造成需求范圍邊界界定困難。鑒于此，需要對變更管理信息化系統(tǒng)進行充分設(shè)計，采用原型化方法進行系統(tǒng)建模，系統(tǒng)建設(shè)者與變更制度制定者、變更執(zhí)行者不斷調(diào)整原型各要素使其更貼近真實場景，各方試用后進入下一步開發(fā)。

針對建設(shè)周期大于變更制度變化周期的特點，應(yīng)在開發(fā)模式中應(yīng)用敏捷開發(fā)的模式。規(guī)劃建設(shè)周期數(shù)、各建設(shè)周期下的建設(shè)任務(wù)及各任務(wù)的優(yōu)先級，劃分敏捷開發(fā)模式的迭代維度及頻度。變更信息化系統(tǒng)規(guī)劃的初期利用關(guān)鍵成功要素法（Critical Success Factors，CSF），通過變更失敗或成功的原因分析，識別變更信息化的關(guān)鍵要素，確定系統(tǒng)開發(fā)任務(wù)的優(yōu)先順序。再利用目標集轉(zhuǎn)移法（Strategy Set Transformation，SST），識別變更管理的戰(zhàn)略集。首先描繪變更組織中的各類實體結(jié)構(gòu)（如變更申請人、柜員、一般員工、變更評審專家、變更評審責(zé)任人、變更實施人、變更驗證經(jīng)理、變更決策人），其次識別每類變更角色的目標，最后對于每類變更角色識別其使命及戰(zhàn)略。最終利用業(yè)務(wù)系統(tǒng)規(guī)劃法（Business System Planning ，BSP）校核兩個目標，提出建議書與開發(fā)計劃。主要環(huán)節(jié)為調(diào)研變更需求、識別變更流程、變更流程重組、定義變更數(shù)據(jù)類、定義變更信息系統(tǒng)邏輯結(jié)構(gòu)、確定變更信息系統(tǒng)總體結(jié)構(gòu)中的優(yōu)先順序、變更各子系統(tǒng)按先后順序排出開發(fā)計劃、劃分敏捷開發(fā)模式的迭代維度及頻度。

3.3 團隊架構(gòu)

團隊架構(gòu)要確定參與系統(tǒng)建設(shè)人與角色，在商業(yè)銀行變更管理信息化的組織結(jié)構(gòu)中，強調(diào)以變更責(zé)任人為核心，變更制度制定者、變更管理流程執(zhí)行者、信息化系統(tǒng)建設(shè)者全程介入開發(fā)及持續(xù)運維各階段的組織結(jié)構(gòu)模式（見圖4）。商業(yè)銀行IT變更管理信息化項目一般規(guī)模較大，按照項目規(guī)模及迭代維度，建立多團隊敏捷開發(fā)組織框架，每個團隊安排領(lǐng)域產(chǎn)品負責(zé)人（APO）[4] ，此外商業(yè)銀行各系統(tǒng)運行環(huán)境復(fù)雜多樣，其變更自動化，有較強的技術(shù)難度，往往構(gòu)成系統(tǒng)開發(fā)的關(guān)鍵路徑，所以需組成公共控件組先行研究相應(yīng)的技術(shù)解決手段。

3.4 技術(shù)實現(xiàn)

在技術(shù)實現(xiàn)時，首先研究低耦合、高內(nèi)聚功能模塊集，需劃分變更管理信息化模塊及功能最小集合，以完成信息系統(tǒng)邏輯結(jié)構(gòu)定義。因變更管理很重要一環(huán)是對變更流程管理，故需工作流程管理模塊；變更管理涉及復(fù)雜人員組織體系，故需人員機構(gòu)模塊；變更管理是針對系統(tǒng)應(yīng)用或數(shù)據(jù)作出變更，故需應(yīng)用系統(tǒng)模塊；變更管理需對變更實施后業(yè)務(wù)影響驗證及評價，故需業(yè)務(wù)數(shù)據(jù)監(jiān)控模塊；變更管理需對相關(guān)變更場景進行比對檢索過程，故需知識專家?guī)炷K；變更管理需對應(yīng)用進行自動部署回退等，故需變更自動化工具模塊。

其次針對各模塊可能遇到的技術(shù)瓶頸、所需公共控件，由公共控件組研究相應(yīng)的技術(shù)解決手段。變更管理涉及復(fù)雜的文檔管理過程，需要建立文檔解析引擎及文件傳輸控制引擎；變更操作及驗證涉及向服務(wù)器發(fā)送及解析信令的過程，需要建立遠程主機通信自動解析調(diào)用引擎；數(shù)據(jù)變更的自動化，需要建立數(shù)據(jù)庫規(guī)則語義檢查與調(diào)度管理引擎，以完成數(shù)據(jù)變更的安全檢查、自動備份、執(zhí)行、回退；程序變更流程自動化，需要建立應(yīng)用服務(wù)器自動引擎，以完成程序變更的自動備份、、回退；這些技術(shù)模塊與引擎共同構(gòu)成變更管理信息化的技術(shù)要素，通過不同的組合和應(yīng)用，為變更管理各組應(yīng)用場景提供技術(shù)支撐。

4 實 踐

A銀行是一家國有大型商業(yè)銀行，近年來隨著各項業(yè)務(wù)量迅猛增長，變更管理工作日益繁雜。為進一步提高變更保障能力和變更管理工作信息化水平，規(guī)范變更管理工作流程，從變更管理實際工作出發(fā)，結(jié)合變更管理未來發(fā)展需要，特開發(fā)變更管理系統(tǒng)（簡稱S系統(tǒng)），整合變更管理各個環(huán)節(jié)。該系統(tǒng)累計投入人力超過187人月，建設(shè)工期近一年，采用原型法加敏捷開發(fā)模式，以變更評審人為核心，實現(xiàn)變更操作自動化、變更管理流程信息化、變更驗證自動化、專家知識庫等功能模塊。

通過對變更信息化平臺應(yīng)用實踐，A銀行彌補了變更申請、變更評審、變更實施在嚴肅性、合規(guī)性和流程性上的不足，有效防控了投產(chǎn)變更風(fēng)險，提高了變更執(zhí)行成功率，為A銀行在科技風(fēng)險管理與防控方面作出了重要貢獻。以2012年為例，日均用戶1 200余人次，執(zhí)行變更2 157個，變更執(zhí)行成功率持續(xù)提高，變更異常率同比降低50%，目前A銀行在總行層面的變更管理信息化程度相對較高，后期將在一級分行逐步進行推廣執(zhí)行。

5 總 結(jié)

本文就商業(yè)銀行IT變更管理信息化建設(shè)體系進行了研究，提出了信息化方法，并在大型國有商業(yè)銀行進行了初步實踐。本文所提出的方法其應(yīng)用范圍還有待進一步擴大，其通用性、規(guī)模性還有待加強。

主要參考文獻

[1]中國銀行業(yè)監(jiān)督管理委員會.商業(yè)銀行信息科技風(fēng)險管理指引[Z].2012.

[2]中國銀行業(yè)監(jiān)督管理委員會.銀行業(yè)金融機構(gòu)重要信息系統(tǒng)投產(chǎn)及變更管理辦法[Z].2009.

篇3

4M變更管理辦法最新版

1、目的

在生產(chǎn)過程中，對影響產(chǎn)品質(zhì)量的4M要素(人、機、料、法)進行管理和控制，使

這四個因素在保證質(zhì)量的范圍內(nèi)安全合理的變動，從而保證產(chǎn)品質(zhì)量的穩(wěn)定和提高，符合標準及客戶要求。

2、適用范圍

適用于批量產(chǎn)品生產(chǎn)過程中4M(人、機、料、法)要素的管理。

3、4M定義：

是指批量產(chǎn)品生產(chǎn)過程中，涉及的人(Man)、機(Machine)、料(Material)、法(Method)，

(含環(huán)境場所)等給產(chǎn)品質(zhì)量帶來一定影響的變更。

人(Man)：是指生產(chǎn)過程中作業(yè)者因缺勤、調(diào)動、離職、代崗或復(fù)崗時，由另一個新作業(yè)者代替進行作業(yè)時，所產(chǎn)生的變更;

機(Machine)：是指生產(chǎn)過程中的設(shè)備、模具、工裝、夾具、檢具的新增、修理、代用變更; 料(Material)：是指生產(chǎn)過程中的加工原物料、輔料、包裝物資等變更。

法(Method)：是指生產(chǎn)過程中的工藝流程、工藝參數(shù)(設(shè)備參數(shù)、材料配比等)、檢驗方法、作業(yè)方法(制造、整理、包裝、周轉(zhuǎn)等)變更。

4、職責(zé)

4.1變更提出

原則上公司內(nèi)部變更各部門均可提出申請，并根據(jù)變更內(nèi)容對產(chǎn)品質(zhì)量的影響程度進行必要研討，經(jīng)評審后由實施部門負責(zé)執(zhí)行變更;各4M變更實施部門要建立4M變更的臺帳，記錄變更的編號、產(chǎn)品型號和結(jié)果等。

4.1.1制造部技術(shù)組：負責(zé)產(chǎn)品工藝流程、模具、工裝、檢具及方法等變更的實施。

4.1.2制造部生產(chǎn)組：作業(yè)人員晉升變更的申請，并根據(jù)崗位技能要求進行資格驗證，實施變更;內(nèi)部變更引起的呆滯物料變更處理的申請，跟蹤等。

4.1.3供應(yīng)鏈：材料(含構(gòu)成零部件)變更的申請?zhí)岢龊蛯嵤?，及供?yīng)商的變更受理;

4.1.4工程部：機器，方法、設(shè)備變更的申請?zhí)岢龊蛯嵤?

4.1.5市場部：負責(zé)客戶提出的變更受理，負責(zé)收集和內(nèi)部反饋客戶的評審結(jié)果;訂單完成后庫存呆滯料的變更處理的申請，跟蹤等。

4.1.6體系：負責(zé)對所有變更事項進行監(jiān)督及對變更的有效性進行跟蹤確認。匯總4M變更結(jié)果，應(yīng)建立4M變更總臺帳。

4.2 變更評審實施

4.2.1 變更申請通過部門負責(zé)人審核后，由申請部門組織相關(guān)評審部門，根據(jù)變更內(nèi)容對產(chǎn)品品質(zhì)的影響程度進行必要的研討;由各評審部門審查確認后，變更責(zé)任部門執(zhí)行變更;或根據(jù)變更管理類別(送樣、申請，記錄)由市場項目收集客戶意見后實施; 4.2.3 對相關(guān)部門進行變更培訓(xùn)，記錄保存變更履歷。

注：評審部門包括但不限于技術(shù)部門/生產(chǎn)部門/質(zhì)量部門/采購部門/設(shè)備管理部門。

4.2.4 4M變更實施部門對變更過程中可能出現(xiàn)的意外要有應(yīng)對預(yù)案;

4.2.5 4M變更實施部門及相關(guān)部門需修訂變更涉及事項(如工程圖紙、SOP、FMEA、控制計劃,SIP，ECN,BOM，QC工程圖，工藝流程圖等);

5 4M變更管理類別：送樣，申請，記錄

5.1 送樣：變更前須試制樣品，并向客戶送樣認可。

5.1.1 變更前，需向部門內(nèi)部提出變更申請，由實施部門組織評審部門評審，通過后由變更實施部門試制樣品，并向客戶送樣，合格后客戶認可，才能實施變更;

5.1.2 變更申請部門須填寫《(4M)工程更改申請單》并執(zhí)行4M變更管理流程。 變更實施部門審查后，由變更實施人將通過的《(4M)工程更改申請單》和其它相關(guān)評審報告記錄在《(4M)工程更改通知單》中，客戶評價結(jié)果由市場部項目收集客戶評價結(jié)果反饋給變更實施部門等有關(guān)部門，批準生效后，實施工程變更。

5.2 申請：變更須啟動4M變更管理流程進行評審實施。

變更前，需向部門內(nèi)部提出變更申請，變更申請部門須填寫《(4M)工程更改申請單》并啟動4M變更管理流程。由實施部門組織評審部門評審，經(jīng)客戶或責(zé)任部門確認同意后才能實施變更;

5.3 記錄：此類變更須責(zé)任部門記錄并保存。

由責(zé)任部門管理記錄相應(yīng)變更，并保存相關(guān)記錄。為了確保變更的履歷(可追蹤性)，供應(yīng)商應(yīng)自從該變更品的交貨日算起保管3 年。

6 變更管理內(nèi)容

6.1 客戶提出的4M變更

客戶提出的4M變更由市場部向公司內(nèi)部提出申請，按新產(chǎn)品管理流程進行;

6.2 供應(yīng)商的4M變更

供應(yīng)商提出的4M變更，由供應(yīng)商向采購部門提出，向公司內(nèi)部傳達;

6.3 公司內(nèi)部的4M變更

6.4 變更點的區(qū)分管理

6.5 變更品的首次交貨

6.5.1變更品的首次交貨，需在外包裝箱加貼變更后首批次出貨標簽，并連續(xù)3批作出標識。

6.5.2變更品與原來產(chǎn)品在同一批交貨時，需：

1.原來產(chǎn)品與變更品的外包裝分開;

2.在外包裝箱加貼變更后首批次出貨標簽，并連續(xù)3批作出標識。

篇4

關(guān)鍵詞：電力系統(tǒng)；通信；IT服務(wù)管理 

 一、電力系統(tǒng)通信部門的IT服務(wù)管理

 電力系統(tǒng)通信部門IT服務(wù)管理體系包括展現(xiàn)層、功能層、數(shù)據(jù)層。通過對各種系統(tǒng)狀態(tài)進行實時監(jiān)控，將現(xiàn)有軟硬件環(huán)境、網(wǎng)絡(luò)資源、應(yīng)用系統(tǒng)、人力資源、知識庫有機地融為一體，合理調(diào)配資源，切實解決了機構(gòu)人員、管理模式、業(yè)務(wù)流程、技術(shù)集成等方面實際問題，真正實現(xiàn)科學(xué)高效的I T 服務(wù)管理。

 二、典型處理流程

 IT服務(wù)管理是一種面向流程的管理模式。在電力系統(tǒng)通信部門原有的業(yè)務(wù)流程的基礎(chǔ)上，對其進行優(yōu)化和改造，在此提出了IT服務(wù)管理四個典型處理流程，下面分別從流程目的、功能等角度進行說明：

 （一）事件管理流程

 事件是任何不符合標準操作且已經(jīng)引起或可能引起服務(wù)中斷和服務(wù)質(zhì)量下降的事件。在ITSM引入以前，事件管理沒有特定的流程，所有事件都通過通信故障專線通知到通信調(diào)度部門，然后由值班員派工單給檢修班成員，并不區(qū)分事件的“輕重緩急”，也沒有技術(shù)層面的審核，因此故障派修單回單率一直很低，很多單據(jù)由于不具備執(zhí)行條件而在班組和通信科之間來回推諉，降低了故障解決時間，也沒有相關(guān)考核指標。

 事件管理的流程如下：首先，事件通過運行單位填報、用戶填報或者通信檢修部門巡視發(fā)現(xiàn)填報，所有事件記錄進系統(tǒng)，對于已經(jīng)處理的缺陷只要補報即可。接著通信調(diào)度進行分類預(yù)判斷并分派，確定是事件的影響范圍和優(yōu)先等級：如果是事件處理影響范圍小或無影響，則直接進行派單；如果事件處理影響范圍大，則要求檢修部門先進行停服役申請，再進行事件處理。然后，檢修部門消缺完畢后，由用戶和通信調(diào)度分別進行消缺驗收，判斷是否已解決確定問題：如解決，則由檢修班回單給通信科，則納入審核管理或者填報缺陷歸檔，關(guān)閉記錄；如沒有解決，則納入通信科審核管理繼續(xù)診斷，納入下一季度大修工程，必要時轉(zhuǎn)省調(diào)、廠商和集成商、服務(wù)商等進行支持解決等。最后更新文檔，必要時進行回顧，事件支持人員將根據(jù)管理要求定期產(chǎn)生相關(guān)報表。

 （二）問題管理流程

 問題管理流程設(shè)立的主要功能是分析已被列為問題的事件（一組或一個）的根本原因，然后找出和建議永久性解決方案。其目的包括：（1）確保分析并確定事件的根本原因，以防止再次發(fā)生；（2）確保問題分派了正確支持人員，提高解決率。（3）根據(jù)IT資源情況分派問題優(yōu)先級；（4）主動提供預(yù)防性措施；（5）提高IT服務(wù)的可靠性；（5）降低IT支持成本；（6）提高通信部門的整體形象和名譽。

（三）配置管理流程

 通信部門的所有資源都通過手工和電子配置管理是通過手工形式派發(fā)“電路（設(shè)備、線路）投入、改接單”，單據(jù)與實際資源狀況出入較大。待單據(jù)完成后，由專人進行手動的資料更新和管理，而經(jīng)常出現(xiàn)資料忘記更新或資料更新出錯，缺乏必要的考核體系。

 配置管理的流程如下：首先進行配置申請。接著配置管理員根據(jù)需求進行方案設(shè)計，經(jīng)配置管理經(jīng)理審批后生成配置工單。配置工單由配置經(jīng)理審核后進行工單派發(fā)，此時由于工單并未真正實施，配置資源處于預(yù)占狀態(tài)。然后配置管理員根據(jù)班組回單進行完成確認，若確認完成，則將資源預(yù)占狀態(tài)更改為運行狀態(tài)；否則取消資源預(yù)占狀態(tài)。并定期進行資源檢查驗證，流程回顧，每個一個季度由系統(tǒng)自動生成配置管理報告，據(jù)此可進行資源分析、預(yù)警等。

 （四）變更管理流程

 變更管理流程將通過標準統(tǒng)一的方法和步驟管理和控制所有對通信系統(tǒng)運行環(huán)境有影響的變更。其目的在于：通過對所有變更的正確評估，可以維護通信系統(tǒng)運行環(huán)境的完整性；確保變更和變更實施得到正確記錄，并提供審核統(tǒng)計；減少或消除由于變更實施準備不當(dāng)?shù)仍虺霈F(xiàn)的故障；提供一致性的變更實施質(zhì)量控制；提高資源使用率（如未得到正確控制和授權(quán)的變更需要更多的后續(xù)資源）；確保實施的變更不會超出預(yù)定的系統(tǒng)利用限值確保緊急變更請求得到快速實施。

 三、IT服務(wù)管理體系的實施效果評價

 杭州市電力局通信部門I T 服務(wù)管理系統(tǒng)2006 年初上線運行，截止到2007年9 月30 日，IT服務(wù)管理系統(tǒng)的配置項數(shù)據(jù)包括服務(wù)器、客戶端設(shè)備、網(wǎng)絡(luò)設(shè)備、變電站通信機房、變電站通信屏體信息、數(shù)據(jù)采集與監(jiān)視控制系統(tǒng)（SCADA） 采集點以及其他各種設(shè)備信息，總計有36個分類、95000多條記錄。自投運以來總共記錄有效服務(wù)呼叫8546 條，電力通信網(wǎng)和管理信息化共關(guān)閉8492 條，完成比率達99 %。

 杭州市電力局通信部門I T 服務(wù)管理系統(tǒng)固化了18 種處理流程及衡量標準、20項事件流程服務(wù)指標、10 項工作量考核指標、28種事件分類指標等可量化的I T運行維護指標, 電力通信網(wǎng)和管理信息化都分別設(shè)置了流程經(jīng)理, 每個流程又明確了流程負責(zé)人，負責(zé)處理流程時限、效率和質(zhì)量。I T 服務(wù)管理系統(tǒng)提供了可觀、可測、可控、可量化的工作環(huán)境, 工作量考核、系統(tǒng)風(fēng)險識別、流程實施關(guān)鍵績效指標（KPI） 、人員技術(shù)能力等都可用“數(shù)字說話”。通過系統(tǒng)實施，事件處理更加高效, 變更管理更加規(guī)范、問題管理更加可控、IT服務(wù)水平和人員素質(zhì)得到了極大提高，為IT管理人員提供了方便高效的管理手段。

 四、結(jié)語

 IT服務(wù)管理系統(tǒng)運行兩 年的實踐證明了ITSM是一套科學(xué)的方法論。實施效果表明該體系應(yīng)用成效顯著，流程清晰, 責(zé)權(quán)分明, 運行維護內(nèi)容可量化，服務(wù)質(zhì)量可考核，運作模式徹底告別了被動的救火隊式的管理，開始步入主動的有預(yù)案的IT服務(wù)管理良性發(fā)展軌道。通過系統(tǒng)的實施，各流程的關(guān)鍵績效指標越來越好，問題的可控程度也越來越高。因此，有計劃、分步驟地將各流程應(yīng)用在日常的系統(tǒng)運行維護和管理中去是現(xiàn)階段最切實可行的方法。

參考文獻

 [1]曹漢平，王強，賈素玲．現(xiàn)代IT服務(wù)管理——基于ITIL的最佳實踐[M]．清華大學(xué)出版社，2005．

 [2]孫強，左天祖，劉偉．IT服務(wù)管理——概念、理解與實施[M]．機械工業(yè)出版社，2007．

篇5

關(guān)鍵詞：企業(yè)合同 信息管理 系統(tǒng)

該系統(tǒng)采用目前流行的B/S架構(gòu)，支持個人電腦的各類型操作系統(tǒng)，對各類主流瀏覽器都有很好的兼容性。該套系統(tǒng)采用主流的大型數(shù)據(jù)庫管理軟件Oracle管理、存儲合同信息，應(yīng)用程序部署在Tomcat應(yīng)用服務(wù)器之上。

根據(jù)常見的業(yè)務(wù)需求，合同管理系統(tǒng)分為三大模塊，分別是合同會簽管理，合同變更管理，合作伙伴管理。根據(jù)業(yè)務(wù)模塊的劃分和需求分析，設(shè)計關(guān)系模式并建立如下數(shù)據(jù)庫表和其中字段：1、合同信息表（合同ID，合同名稱，合同簡介，合作伙伴ID，合同類別ID，合同年份，項目ID，總金額，經(jīng)辦人，經(jīng)辦部門，合同履行開始時間，合同履行結(jié)束時間，歸檔人，歸檔日期，工作流序號，工作流狀態(tài)，驗收終止日期，企業(yè)編碼）。2、合同類別表（合同類別ID，合同類別名，識別碼，說明，修改人，是否使用）。3、合同變更申請表（合同變更ID，合同變更編號，合同ID，經(jīng)辦人，申請部門，變更類型，原合同金額，現(xiàn)合同金額，變更理由，備注，工作流序號，工作流狀態(tài)，起草人，起草日期，企業(yè)編碼）。4、合作伙伴信息表（合作伙伴ID，合作伙伴性質(zhì)ID，重要程度ID，行業(yè)ID，合作伙伴編號，合作伙伴名稱，公司負責(zé)人，基本介紹，業(yè)務(wù)范圍，主要業(yè)績，公司地址，聯(lián)系電話，電子郵箱，公司網(wǎng)址，法人代表，納稅人資格，開戶銀行，帳號，注冊資金，備注）。5、用戶信息表（用戶ID，用戶工號，用戶姓名，是否使用，企業(yè)編碼）。

其中合同會簽管理又可分為合同會簽起草，合同會簽審批，合同會簽查詢?nèi)齻€子模塊。

1.合同會簽起草頁面由合同起草人對合同信息進行登記，登記完之后可保存、上報給部門會簽和領(lǐng)導(dǎo)審批。登記內(nèi)容包括合同名稱、合同類別、合同登記年月、項目名稱（需要關(guān)聯(lián)項目的合同）、供應(yīng)商、合同履行開始結(jié)束時間、上傳附件等內(nèi)容。

2.合同會簽審批頁面提供可視化的工作流審批查詢功能，實時查詢合同審批節(jié)點信息以及各節(jié)點審批人及審批意見。經(jīng)辦部門提交合同后，根據(jù)合同的不同類別，進行不同的審批流程，流程在各個相關(guān)單位及領(lǐng)導(dǎo)之間流轉(zhuǎn)。在合同審批頁面除了可以查看合同基本信息，還設(shè)計了簽字、會簽表、會簽查詢?nèi)齻€按鈕，分別用于簽字審批，查看會簽表，查看會簽審批流程信息功能。

3.合同會簽查詢由兩個部分組成，即查詢條件和合同列表。查詢條件由合同信息的一些關(guān)鍵字段如登記日期，合同編號，合同名稱，供應(yīng)商，經(jīng)辦人，簽字狀態(tài)構(gòu)成，根據(jù)這些條件可以進行過濾查詢，精確查找到需要的合同。合同列表則把正在審批流程中及已經(jīng)審批結(jié)束的合同按行展示出來，每行顯示合同信息的關(guān)鍵字段，如合同編號、合同名稱、供應(yīng)商、總金額、經(jīng)辦人、會簽狀態(tài)等字段。

合同變更管理模塊支持合同按照要求的變更活動。即可以在固定節(jié)點控制合同是否可以進行變更。支持變更合同的審批。系統(tǒng)記錄合同的變更記錄，如資金變動情況。系統(tǒng)能重新生成變更審批表，合同的變動情況在臺賬和統(tǒng)計功能中自動反映出來。系統(tǒng)記錄合同變更的原因、影響，并將變更依據(jù)作為附件導(dǎo)入系統(tǒng)，從而兼顧了變更過程管理的嚴謹和自動性，關(guān)聯(lián)結(jié)果，有據(jù)可查，權(quán)責(zé)明晰。此模塊分為三個子模塊，即合同變更申請、合同變更審批、合同變更查詢。

1.合同變更申請頁面在進行合同變更時，首先選擇原來的合同，這樣系統(tǒng)就會自動帶出原合同的相關(guān)信息，在此頁面可以對包括合同名稱、合同經(jīng)辦人、合同金額在內(nèi)的一些字段信息進行修改，并填寫變更原因，上傳變更后的合同文本后保存，保存之后即可走合同變更審批流程，此時系統(tǒng)會自動生成合同變更號。

2.合同變更審批頁面是在合同變更之后，根據(jù)企業(yè)制定的審批流程合同變更信息會像上面的合同會簽一樣走一個審批流程。當(dāng)合同變更信息走到對應(yīng)部門負責(zé)人或相關(guān)領(lǐng)導(dǎo)節(jié)點時，其有權(quán)限對合同變更信息進行查詢，進而做出同意或者退回的審批意見。

3.合同變更查詢頁面可以對企業(yè)所有的合同變更信息進行查詢統(tǒng)計。

合作伙伴管理模塊通過對合作伙伴基本信息的錄入保存，提供了統(tǒng)一的準入機制、審核標準，實現(xiàn)了對合作伙伴注冊信息的審核、定期評價、分級歸類的管理。合作伙伴管理模塊分為兩個子模塊，即供應(yīng)商信息登記、合作伙伴綜合管理兩個子模塊。

1. 供應(yīng)商信息登記頁面實現(xiàn)了新增、修改、查詢合作伙伴基礎(chǔ)信息的功能，在此頁面可以對供應(yīng)商全稱，供應(yīng)商級別，公司負責(zé)人，企業(yè)類別，企業(yè)行業(yè)，企業(yè)性質(zhì)，公司簡介，合作經(jīng)歷以及合作伙伴的聯(lián)系方式進行登記。當(dāng)企業(yè)信息發(fā)生變化時，也可在此頁面對企業(yè)相關(guān)信息進行修改。

篇6

關(guān)鍵詞:管道;生產(chǎn)管理系統(tǒng);運行維護;管理

中圖分類號：C93文獻標識碼： A

1 管道生產(chǎn)管理系統(tǒng)

管道生產(chǎn)管理系統(tǒng)主要包括調(diào)運管理、運銷計量管理、計劃管理、能耗及周轉(zhuǎn)量管理、天然氣用氣需求預(yù)測、日指定、輔助功能、統(tǒng)計報表、SCADA數(shù)據(jù)采集、對外接口等10 個模塊。

1.1 調(diào)運管理

實現(xiàn)調(diào)度日報的生成，調(diào)度指令、場站作業(yè)的起草、審批及下達，值班日志的填報，成品油批次計劃的起草及下達、收發(fā)球管理等功能；實現(xiàn)生產(chǎn)調(diào)度過程的監(jiān)管與控制。

1.2 運銷計量管理

從SCADA 系統(tǒng)及相關(guān)系統(tǒng)自動獲取計量交接數(shù)據(jù)，并實現(xiàn)管道計量交接數(shù)據(jù)、氣質(zhì)分析數(shù)據(jù)、原油化驗數(shù)據(jù)的審核和上報、統(tǒng)計報表的匯總、運銷臺帳及銷售結(jié)算單的自動生成。

1.3 計劃管理

實現(xiàn)原油、成品油、天然氣銷售計劃的制定、審批及下發(fā)及計劃完成情況的跟蹤分析。

1.4 能耗及周轉(zhuǎn)量管理

實現(xiàn)輸油氣周轉(zhuǎn)量的自動計算、能耗統(tǒng)計數(shù)的上報、自動匯總及報表展現(xiàn)，實現(xiàn)能源統(tǒng)計指標和工藝參數(shù)的自動計算。

1.5 天然氣用氣需求預(yù)測

根據(jù)歷史用氣量、氣象數(shù)據(jù)、經(jīng)濟模式等因素預(yù)測客戶的天然氣用氣需求，為日指定、銷售計劃、管輸計劃等的制定提供支持。

1.6 日指定

根據(jù)合同要點進行客戶用氣日指定管理，實現(xiàn)氣田、終端供應(yīng)量、儲氣庫吞吐能力及客戶需求量的綜合平衡。

2 運行維護管理體系

管道生產(chǎn)系統(tǒng)以運行維護管理的最佳實踐ITIL（信息技術(shù)基礎(chǔ)架構(gòu)庫）理念為核心，以先進的運行維護管理平臺為手段，開展各項運行維護工作。

2.1 運行維護工作內(nèi)容

運行維護計劃制定：主要包括運行維護工作目錄的確定、運行維護工作進度安排、服務(wù)級別管理、服務(wù)改進計劃、成本及費用預(yù)算。

日常運行維護管理：主要包括用戶支持、系統(tǒng)巡檢、用戶培訓(xùn)、軟硬件維護及配置及變更管理等。

突發(fā)事件處理：主要包括應(yīng)急預(yù)案的編制及演練、災(zāi)備系統(tǒng)建設(shè)、突發(fā)事件的處理等等。

系統(tǒng)拓展：主要包括新投管道及新建組織機構(gòu)的系統(tǒng)實施工作。

功能提升：主要包括新功能的開發(fā)建設(shè)、軟硬件平臺的升級、系統(tǒng)性能優(yōu)化等等。

2.2 運行維護流程

以ITIL v3 體系為藍圖，結(jié)合項目自身特點制定了配置管理、變更管理、事件管理、問題管理、管理、知識管理等6 個操作流程。

配置管理：指識別和確認系統(tǒng)的配置項，記錄和報告配置項狀態(tài)，根據(jù)用戶的請求完成變更及檢驗配置項的服務(wù)管理流程。變更管理：在規(guī)定時間內(nèi)完成基礎(chǔ)架構(gòu)或服務(wù)的變更而對其進行控制的服務(wù)管理流程。事件管理：指對引起或有可能引起服務(wù)中斷或服務(wù)質(zhì)量下降的事件進行處理的管理流程。問題管理：指通過調(diào)查分析查明事件發(fā)生的潛在原因，并制定解決方案和防止再次發(fā)生的措施，將問題對業(yè)務(wù)產(chǎn)生的負面影響降到最低的服務(wù)管理流程。管理：是負責(zé)計劃與實施IT 服務(wù)變更的管理流程，通過規(guī)范的流程控制服務(wù)及測試的過程，確保應(yīng)用系統(tǒng)的質(zhì)量。知識管理：是進行知識庫內(nèi)容收集、更新、檢索以及知識應(yīng)用、知識關(guān)聯(lián)的服務(wù)管理流程。

2.3 運行維護理論

ITIL 是CCTA（英國國家計算機和電信局）于20 世紀80 年代末開發(fā)的一套IT 服務(wù)管理標準庫，其將英國各個行業(yè)在IT 管理方面的最佳實踐歸納起來變成規(guī)范，旨在提高IT 資源的利用率和服務(wù)質(zhì)量。

管道生產(chǎn)管理系統(tǒng)的運行維護工作在借鑒ITIL理念的基礎(chǔ)上，制定了配置管理、變更管理、管理、事件管理和問題管理的具體操作流程，并在服務(wù)規(guī)劃、成本控制、年度總結(jié)等工作中充分吸收了ITIL 的服務(wù)級別管理、能力管理、IT 財務(wù)管理、IT 服務(wù)持續(xù)性管理、可用性管理的理念和方法論，實現(xiàn)了服務(wù)成本、服務(wù)能力與服務(wù)目標（用戶需求）的平衡與統(tǒng)籌規(guī)劃。

2.4 運行維護平臺

系統(tǒng)運行維護平臺主要包括事件報警平臺和運行維護流程管理平臺。事件報警平臺為HPOpenView 平臺中的OVO 和OVIS 軟件套件，能夠?qū)崿F(xiàn)系統(tǒng)狀態(tài)的監(jiān)控和自動化報警。運行維護流程管理平臺主要實現(xiàn)日常運行維護工作的流程化管理。事件報警平臺和運行維護流程管理平臺通過報表平臺進行數(shù)據(jù)展現(xiàn)，并為幫助臺的日常工作提供支持。

2.5 運行維護的實施

以ITIL v3 體系為基礎(chǔ)，對配置管理、變更管理、事件管理、問題管理、管理等進行了深入的梳理與研究，在借鑒最佳實踐的基礎(chǔ)上摸索出了符合項目實際的運行維護方法論，對運行維護工作起到了很大的支持作用。

在處理系統(tǒng)變更請求的過程中，項目組根據(jù)工作類型的不同對變更管理流程進行了細分，針對新建天然氣客戶這一類操作的規(guī)律性和重復(fù)性，制定了新增天然氣客戶的操作流程，作為變更管理的子流程專門用于新增客戶所需完成的基礎(chǔ)信息、權(quán)限、報表、工作流、數(shù)據(jù)流等一系列的操作。同時在運行過程中根據(jù)業(yè)務(wù)發(fā)展變化更新完善業(yè)務(wù)流程，使其運轉(zhuǎn)更加流暢。

通過運用可用性管理、服務(wù)級別管理、成本管理與持續(xù)性管理，對自身的服務(wù)提供能力進行了深入的分析與研究，進而明確了針對不同的服務(wù)所能達到的不同級別，同時將各種服務(wù)級別與對應(yīng)的成本關(guān)聯(lián)起來，進一步量化了運行維護工作，也為運行維護工作的考核提供了科學(xué)的依據(jù)。

參考文獻：

[1] 趙宏振. FLUKE744在天然氣管道控制系統(tǒng)測試中的應(yīng)用[J]. 自動化儀表. 2009(07)

[2] 周中.天然氣管道防腐問題的探討[J]. 煤氣與熱力. 2001(03)

篇7

1運行控制系統(tǒng)的柔性業(yè)務(wù)需求

航站運行控制系統(tǒng)的核心主要是航班飛行計劃,簽派和飛行跟蹤系統(tǒng),載重和平衡系統(tǒng),決策支持系統(tǒng),機組管理系統(tǒng)進,其他功能系統(tǒng)都是在該幾個核心模塊上進行擴展得到的。

航班管理委員會的運力任務(wù)安排將極大優(yōu)化,不在向所有分公司和協(xié)調(diào)運力資源,只向三個生產(chǎn)部門運力計劃進行資源協(xié)調(diào),而總隊、客艙、飛機維修部門能夠?qū)崿F(xiàn)統(tǒng)一資源調(diào)度,進行工作任務(wù)安排,實現(xiàn)集中管理的目標。

2業(yè)務(wù)角色設(shè)計

2.1 系統(tǒng)管理員用分析

系統(tǒng)管理員擁有對設(shè)變流程的所有操作權(quán)限。設(shè)計變更流程開發(fā)完成以后,流程的系統(tǒng)管理人員應(yīng)該能對流程的相關(guān)輸出電子表單進行靈活定義,根據(jù)業(yè)務(wù)需求的變化,系統(tǒng)管理員可以對設(shè)計變更流程進行重新編排基本達到隨需應(yīng)對的目標,包括對新流程及各流程節(jié)點的訪問權(quán)限的設(shè)定,流程關(guān)鍵節(jié)點的運行狀況可以實時監(jiān)控,包括關(guān)鍵節(jié)點運行時間,運行狀態(tài)等。新編排的流程應(yīng)能并運行在流程服務(wù)器上,并與相應(yīng)的監(jiān)控程序相關(guān)聯(lián),以實現(xiàn)對流程的實時監(jiān)控。

2.2 SOC管理人員用分析

SOC管理人員是參與流程運轉(zhuǎn)工作的相關(guān)人員,目前主要包括按照航站管理中的部門中所對應(yīng)的功能模塊等,隨著業(yè)務(wù)需求的改變,可能會發(fā)生一定的變化。

設(shè)計變更流程在運轉(zhuǎn)過程中,會產(chǎn)生一些相應(yīng)的人員交互,主要包括啟動,查看或停止流程,對設(shè)計變更票業(yè)務(wù)進行SOC管理,或轉(zhuǎn)派給其他人員操作,相關(guān)人員對設(shè)計變更票進行會簽,對各種設(shè)計變更票進行歸檔等操作。

3管理流程設(shè)計

3.1 SOC管理流程的設(shè)計

jBPM是一個靈活的、易擴展的開源工作流管理系統(tǒng),也是一個基于J2EE的輕量級工作流管理系統(tǒng)。jBPM的另一個特色是它使用Hibernate來實現(xiàn)流程持久化。Hibernate是目前Java領(lǐng)域最好的一種數(shù)據(jù)持久化層解決方案,它解決了不同數(shù)據(jù)庫SQL dialect差異的問題,使得jBPM能適應(yīng)現(xiàn)有的所有數(shù)據(jù)庫,而且通過Hibernate,jBPM將數(shù)據(jù)的管理職能分離出去,自已專注于業(yè)務(wù)邏輯的實現(xiàn)。

3.2 SOC流程實例的獲取

SOC管理流程的執(zhí)行為SOC管理平臺的核心模塊,負責(zé)SOC管理流程的部署、解析和調(diào)度。

不同情況下獲取流程實例的方法是不一樣的,本文通過從數(shù)據(jù)庫獲取流程實例,其代碼如下。

//獲取實例類JbpmSessionFactory的唯一一個實例

static JbpmSessionFactory jbpm SessionFactory=

JbpmSessionFactory.buildJbpm SessionFactory();

JbpmSession jbpmSession jbpm SessionFactory.openJbpmSession();

Try{

jbpmSession.beginTransaction};//開始一個事務(wù)

//從數(shù)據(jù)庫中查詢流程定義

ProcessDefmition process Definition=jbpmSession.getGraph Session().省略mitTransaction();//進行其他業(yè)務(wù)操作

}Catch(Exception e){}

finally{

//關(guān)閉jbpmSession

jbpmSession.close(); }

通過在數(shù)據(jù)庫中查詢已部署的流程定義,利用該流程定義創(chuàng)建新的流程實例,此方法用于流程定義已被部署,要開始一個新的流程實例的情況。由于要與數(shù)據(jù)庫打交道,必然要跟事務(wù)相聯(lián)系,所以應(yīng)將對流程的操作放在單獨的事務(wù)操作中,此處放在jbpmSession.省略mtiTransaction()范圍中,事務(wù)操作完后,不管它成功如否,都要將事務(wù)進行關(guān)閉,即調(diào)用jbpmSession.close()方法。

3.3 SOC管理流程的監(jiān)控

SOC管理流程的監(jiān)控功能貫穿整個SOC管理平臺,把流程監(jiān)控管理模塊視為一個專用的應(yīng)用程序模塊,在每張頁面中都提供該模塊。在系統(tǒng)中不同的流程操作角色具有不同的流程監(jiān)控權(quán)限。其中項目申請人只能查看具有權(quán)利的項目,而系統(tǒng)管理員可通過工作流引擎獲取當(dāng)前全部流程實例的信息,對SOC管理流程進行監(jiān)控和督辦。

流程監(jiān)控的功能主要由MonitorBean類中的showSerchInstances()、inspectT asklnstance()方法和processI nstanceBean類中的signal(), selectTran sition()方法實現(xiàn)。

4結(jié)語

本文從SOC系統(tǒng)的流程出發(fā),分析了柔性SOC設(shè)計的需要和設(shè)計思想,然后給出了柔性SOC系統(tǒng)的角色控制,并提出了基于工作流技術(shù)的SOC系統(tǒng),分析了工作流引擎是整個系統(tǒng)的核心,最后結(jié)合jBPM工作流引擎的特點,設(shè)計了系統(tǒng)的要求。航空SOC項目如能夠成功實施,將極大改進和優(yōu)化航空運行控制、機組管理的業(yè)務(wù)和流程,較大程度的提高航空在運行控制方面的工作效率和決策水平,從而提高航空的運行水平,通過提高正點率、合理調(diào)配航班、飛機、機組三大資源,使航空公司降低成本、提高服務(wù)水平。

參考文獻

[1] 王寧,王延章,于淼.以知識管理為核心的辦公信息流處理系統(tǒng)研究[J].計算機應(yīng)用研究,2006,23(2):67～69.

篇8

變更配置保證應(yīng)用效率

對此，F(xiàn)orrester Research指出，近20%的業(yè)務(wù)核心應(yīng)用軟件的癱瘓，是因為計劃中變更的相關(guān)性，沒有考慮IT部件和核心業(yè)務(wù)之間的關(guān)聯(lián)而引起的。另據(jù)Gartner Group調(diào)查顯示，40%意想不到的應(yīng)用程序癱瘓是由應(yīng)用程序的故障造成的;40%是因為操作錯誤;只有20%的原因是由于硬件環(huán)境因素以及各種災(zāi)難造成。

目前，市場上相應(yīng)的產(chǎn)品已經(jīng)不少，例如:HP OpenView Application Manager using Radia、 CAAllFusion Harvest Change Manager、BMC 變更和配置管理（Change and Configuration Management,CCM ）解決方案、Microsoft Systems Management Server（SMS），它們都具有自動部署并維護的特點，這是企業(yè)進行管理所必不可少的。面對如此眾多的產(chǎn)品，如何選擇？

惠普在收購了變更和配置管理解決方案供應(yīng)商Novadigm之后，將公司的業(yè)務(wù)資產(chǎn)―包括Radia管理套件成功地整合到其軟件產(chǎn)品事業(yè)部中。該產(chǎn)品的最大特點就是幫助用戶夠把所需要的自動化管理解決方案和最佳實踐轉(zhuǎn)化為資產(chǎn)，增強靈活性。

Microsoft SMS為基于Windows的桌面計算機和服務(wù)器系統(tǒng)提供了具有可伸縮性能的變更和配置管理。它建立在行業(yè)標準管理協(xié)議的基礎(chǔ)上，在任何規(guī)模的網(wǎng)絡(luò)中都容易安裝、配置和維護。

但是，用戶在選型時仍發(fā)現(xiàn)了不少問題，例如:缺少在不同地點和架構(gòu)中，不同層面的標準程序和變更實施的最佳方案;缺少在IT環(huán)境中，可以不斷發(fā)現(xiàn)和執(zhí)行理想狀態(tài)的一種集中、標準的配置管理實踐;手動的執(zhí)行客戶端和服務(wù)器端軟件升級，以及經(jīng)常被置于變更和釋放流程（Change and Release Process）外的安全補丁。

變更管理核心為CMDB

BMC負責(zé)變更和配置管理解決方案的高級經(jīng)理Steve Balentine認為，變更和配置管理最關(guān)注的一點就是要能夠?qū)Ω鱾€組建之間的關(guān)系進行記錄。CMDB就像是一個數(shù)據(jù)模型，裝載著各個要素之間的關(guān)系，是實現(xiàn)變更和配置管理的核心所在。

因為所有的操作都會形成一個核心的CMDB。為了達到數(shù)據(jù)同步化，CMDB應(yīng)該是在ITIL架構(gòu)下，用于增加管理業(yè)務(wù)和技術(shù)變更的效率與可靠性，以及IT環(huán)境的控制能力和安全性，最終統(tǒng)一到一個平臺下，方便用戶操作。

在Balentine看來，一個完整的變更和配置解決方案，除了具有CDMB之外，還應(yīng)該包含用于發(fā)現(xiàn)與察覺業(yè)務(wù)關(guān)聯(lián)的IT資產(chǎn)發(fā)現(xiàn)套件、基于流程的變更管理及決方案和基于策略的配置管理及決方案，這個四個部分必不可少。

IT資產(chǎn)發(fā)現(xiàn)套件用來鑒別業(yè)務(wù)核心的IT環(huán)境，包括:Discovery Express（發(fā)現(xiàn)快車）―讓客戶鑒別哪些業(yè)務(wù)部分組成IT環(huán)境、Configuration Discovery（配置發(fā)現(xiàn)）―用于顯示資產(chǎn)的配置情況、Topology Discovery（布局發(fā)現(xiàn)）―顯示系統(tǒng)是如何連接以及應(yīng)用軟件之間的關(guān)聯(lián)，這三個組件都是以基于標準的CMDB為基礎(chǔ)的。

篇9

【關(guān)鍵詞】定期試驗；軟件開發(fā)；結(jié)果統(tǒng)計

0 概述

2015年4月，海南核電成立了定期試驗管理小組，管理小組以“定期試驗監(jiān)督要求”為上游文件建立了一套定期試驗管理體系。經(jīng)過實踐檢驗，該管理體系可以滿足核安全監(jiān)管當(dāng)局對定期試驗的監(jiān)管要求。但隨著1、2號機組相繼商運，定期試驗管理經(jīng)驗不斷積累，現(xiàn)行管理體系逐漸展現(xiàn)出定期試驗報告線下審批流程繁瑣、管理人員投入大、缺少定期試驗數(shù)據(jù)記錄手段等現(xiàn)實問題。為此，海南核電正在開發(fā)一款定期試驗管理軟件，以解決上述問題。

1 定期試驗管理軟件功能及流程設(shè)計

定期試驗管理軟件主要包括賬戶管理、數(shù)據(jù)庫、定期試驗日常項目、定期試驗大修項目、項目審批流程、結(jié)果查詢、系統(tǒng)維護、項目變更八個模塊。

1.1 賬戶管理模塊

為管理定期試驗賬戶操作權(quán)限，分專業(yè)顯示定期試驗各項目清單，賬戶管理模塊可對賬戶權(quán)限進行分配，權(quán)限包括兩個字段：“權(quán)限等級”、“權(quán)限種類”。

權(quán)限等級包括：管理員權(quán)限、軟件維護權(quán)限、定期試驗管理權(quán)限、定期試驗監(jiān)督權(quán)限、試驗數(shù)據(jù)查詢權(quán)限、定期試驗執(zhí)行權(quán)限、高級閱覽權(quán)限、閱覽權(quán)限。權(quán)限種類包括：“定期試驗管理權(quán)限”細分為QSR、非QSR；“定期試驗執(zhí)行權(quán)限”按處室分類。

1.2 數(shù)據(jù)庫模塊

數(shù)據(jù)庫模塊由預(yù)存在軟件中的定期試驗臺賬、試驗重要信息以及定期試驗歷史數(shù)據(jù)組成。

數(shù)據(jù)庫模塊列表包括：項目編號（唯一）、序號、機組號、系統(tǒng)、試驗物項、試驗項目、準則、周期、規(guī)程代碼、責(zé)任部門、備注、安全等級、PMRQ、零點時間、最近執(zhí)行時間、下次執(zhí)行時間、項目備注1、項目備注2、日常/大修項目、機組狀態(tài)要求、是否可在線執(zhí)行、擴展項（不少于10項）、歷史數(shù)據(jù)。其中歷史數(shù)據(jù)包括：歷史執(zhí)行時間、工單號、判定結(jié)果、未合格原因、《定期試驗報告頁》。

1.3 定期試驗日常/大修項目管理模塊

定期試驗日常/大修項目模塊預(yù)留6臺機組，定期試驗日常項目模塊通過預(yù)存在數(shù)據(jù)庫中的PMRQ查找EAM中已生成的工單，根據(jù)工單觸發(fā)時間進行排序并匹配試驗項目。項目列表僅顯示當(dāng)前日期向后1個月內(nèi)及目前暫未合格的試驗項目信息。定期試驗大修項目模塊軟件提供項目導(dǎo)入模板進行導(dǎo)入，并與EAM系統(tǒng)工單進行匹配。

待某項試驗對應(yīng)EAM系統(tǒng)的工單狀態(tài)為“已完工”時，執(zhí)行人員可將該項試驗的試驗狀態(tài)由“正在執(zhí)行”改為“試驗結(jié)束”，軟件自動將該試驗項目推至“項目審批流程”。

1.4 項目審批流程模塊

項目審批流程模塊的主要功能是在定期試驗項目執(zhí)行結(jié)束后，對定期試驗報告審批情況進行總體展現(xiàn)，同時也可鏈接至各個子流程。不同部門僅能看到各自部門的項目審批情況。

1.4.1 數(shù)據(jù)/報告上傳子模塊

數(shù)據(jù)/報告上傳子模塊是定期試驗完成、報告審批的第一步，也可將試驗退回至試驗未完成狀態(tài)。項目列表由項目基本信息及“報告上傳”、“試驗退回至未完成狀態(tài)”的鏈接窗口。

點擊“報告上傳”生成《定期試驗報告頁》。《定期試驗報告頁》包括：項目基本信息、試驗數(shù)據(jù)及判定結(jié)果、必要的文字說明、部門審批路徑設(shè)置、試驗規(guī)程上傳、重要附件上傳等。其中，“試驗數(shù)據(jù)及判定結(jié)果”包括：該項試驗對應(yīng)試驗參數(shù)、各參數(shù)對應(yīng)的試驗值、各參數(shù)判定結(jié)果；“部門審批路徑設(shè)置”包括：報告類別、部門審批賬戶、審批時間、意見、審批結(jié)果。

1.4.2 部門審批子模塊

部門審批子模塊是根據(jù)《定期試驗報告頁》設(shè)置的審批路徑進行內(nèi)部審批。待審批項目由項目基本信息及“報告審批”鏈接組成。點擊“報告審批”進入審批流程。如部門各級對試驗項目審批結(jié)果為合格，則《定期試驗報告頁》進入“監(jiān)督部門審批”子模塊，并將EAM系統(tǒng)的工單關(guān)閉；如任何一級審批判定為不合格或待定，則《定期試驗報告頁》進入“不合格/待定”子模塊。

1.4.3 監(jiān)督部門審批子模

監(jiān)督部門審批子模塊是對《定期試驗報告頁》進行第三方審批。待審批項目由項目基本信息及“報告審批”鏈接組成。點擊“報告審批”進入審批流程。如監(jiān)督部門各級對試驗項目的審批結(jié)果為合格，則《定期試驗報告頁》保持至軟件數(shù)據(jù)庫中；如任何一級審批判定為不合格或待定，則《定期試驗報告頁》進入“不合格/待定”子模塊。

1.4.4 不合格/待定子模塊

不合格/待定子模塊給定期試驗執(zhí)行處室提供再次判定或重新試驗的選擇。待審批項目由項目基本信息及“報告審批”鏈接組成。點擊“報告審批”進入審批流程。試驗執(zhí)行人員可根據(jù)項目審批人員反饋的意見提供進一步證據(jù)，并將試驗返回至“部門審批”或“監(jiān)督部門審批”子模塊。如試驗確實不滿足定期試驗監(jiān)督要求，則可將該試驗退回至未完工狀態(tài)。

1.4.5 個人待審批子模塊

為提高效率，此模塊可將登陸賬號在“部門審批”、“監(jiān)督部門審批”、“不合格/待定”子模塊的項目進行匯總，并提供審批鏈接。

1.5 結(jié)果查詢模塊

此模塊提供定期試驗項目查詢、結(jié)果統(tǒng)計、趨勢分析及定期試驗報表等功能。

“項目查詢”可根據(jù)指定的項目編號、序號、機組號、系統(tǒng)、試驗物項、周期、規(guī)程代碼、責(zé)任部門、安全等級、PMRQ自動查詢符合條件的清單。

“結(jié)果統(tǒng)計”可根據(jù)指定的時間段、機組號、QSR/非QSR，自動統(tǒng)計不同專業(yè)的計劃執(zhí)行項目數(shù)、實際執(zhí)行項目、未開展項目、已開展未合格項目、利用裕度超A%項目、一次合格項目等，并形成定期試驗統(tǒng)計表。

“趨勢分析”可查詢定期試驗任意關(guān)鍵參數(shù)對應(yīng)試驗結(jié)果在選定區(qū)間內(nèi)的趨勢圖。

“定期試驗報表”可查詢選定時間段內(nèi)定期試驗項目已執(zhí)行清單或計劃執(zhí)行清單。

1.6 系統(tǒng)維護模塊

系統(tǒng)維護模塊可對數(shù)據(jù)庫、定期試驗日常項目、定期試驗大修項目模塊進行維護。維護后需填寫的《維護信息單》。待模塊維護后，《維護信息單》保存至軟件數(shù)據(jù)庫中。

1.7 項目變更模塊

項目變更模塊通過填寫《定期試驗項目變更審批單》執(zhí)行裕度審批、定期試驗大綱變更、大修執(zhí)行機組狀態(tài)變更功能?！抖ㄆ谠囼烅椖孔兏鼘徟鷨巍酚身椖啃畔?、變更類型、變更原因、變更時間、審批路徑設(shè)置組成。待《定期試驗項目變更審批單》審批通過后，自動保存至軟件數(shù)據(jù)庫中。定期試驗管理人員可據(jù)此對軟件數(shù)據(jù)進行調(diào)整。

2 總結(jié)

定期試驗管理軟件通過對工作流程的改進和優(yōu)化，在降低定期試驗管理的人員投入，簡化執(zhí)行處室的項目審批流程和工單關(guān)閉流程，提高定期試驗工作效率方面預(yù)期將起到良好效果。同時，該軟件還將提供定期試驗結(jié)果的統(tǒng)計和趨勢的分析手段，隨著定期試驗結(jié)果的不斷累積，在設(shè)備可靠性分析中將發(fā)揮重要作用。

篇10

關(guān)鍵詞：IT運維；管理平臺；設(shè)備管理

1 設(shè)備管理平臺的需求及流程設(shè)計

從設(shè)備管理的角度來看，整個運維管理平臺應(yīng)該能夠包含[1]：臺帳管理模塊、系統(tǒng)管理模塊、文件管理模塊以及報表統(tǒng)計模塊等。臺帳管理模塊包含設(shè)備的名稱、類型及型號、序列號等疾病信息；系統(tǒng)管理模塊主要對平臺內(nèi)相關(guān)的代碼和權(quán)限等進行管理，以記錄設(shè)備管理平臺使用人員的操作記錄；文件管理模塊可以對設(shè)備的維護記錄、設(shè)備采購、報廢信息等進行管理。

設(shè)計基于IT運維的設(shè)備管理平臺時，可以在遵循上述需求分析的情況下，進行數(shù)據(jù)庫、中間代碼以及前端等的設(shè)計，設(shè)計后同時進行數(shù)據(jù)庫、中間件及客戶端的部署。考慮到以后的管理及維護成本，可以采用B/S架構(gòu)；數(shù)據(jù)庫選擇Mysql，其高性能及高并發(fā)性會給設(shè)備管理平臺提供高效的數(shù)據(jù)引擎支持；為提供報表管理功能，設(shè)備管理平臺也會提供數(shù)據(jù)導(dǎo)入導(dǎo)出工具。

基于IT運維的設(shè)備管理平臺能夠?qū)υO(shè)備管理的全過程進行動態(tài)管理，不論是進行設(shè)備的采購、維修還是報廢等工作，都需要根據(jù)設(shè)備管理的操作流程進行，而且設(shè)備管理流程的每個步驟都要能夠根據(jù)操作人員的角色進行業(yè)務(wù)處理，從而快速、高效的管理設(shè)備。作為平臺的核心功能模塊，設(shè)備故障處理要經(jīng)過故障申報、故障處理以及處理結(jié)果等步驟，每一步驟完成后會顯示步驟的操作人員和處理時間。

2 IT運維管理平臺的功能模塊

缺陷管理模塊中可以創(chuàng)建關(guān)聯(lián)的變更單，此時有缺陷的被管理設(shè)備的狀態(tài)被標記為“擱置”，缺陷問題被創(chuàng)建后，一旦缺陷問題被成功關(guān)閉，則可以根據(jù)缺陷的解決狀態(tài)進行設(shè)備的狀態(tài)變更，解決的缺陷其狀態(tài)被變更為“已解決”。缺陷的記錄一般由發(fā)現(xiàn)缺陷的人員進行，缺陷驗收合格后，設(shè)備管理平臺的運維人員需要注明缺陷處理的相關(guān)信息，并注銷缺陷。

IT設(shè)備經(jīng)常會遇到變更關(guān)聯(lián)設(shè)備的情況，如果某設(shè)備有關(guān)聯(lián)的設(shè)備存在，那么此設(shè)備的關(guān)聯(lián)關(guān)系在被關(guān)閉前，此設(shè)備不能被移除。設(shè)備的變更管理包括用戶接入、安裝調(diào)試、檢修以及配置管理等內(nèi)容，如圖1所示：

圖1 設(shè)備變更管理的內(nèi)容

其中，用戶接入指的是用戶提交設(shè)備變更單，對于處理完成的變更單，如果其達到預(yù)期目標，那么此變更單相關(guān)的設(shè)備變更流程即可關(guān)閉，否則此變更處理流程需要被返回。檢修人員作出的檢修申請形成變更申請單，如果此變更申請單涉及到的是通信的檢修或停退，需要判斷此檢修過程是否存在檢修計劃，目的是讓用戶明確的知曉，從而指導(dǎo)設(shè)備管理[2]。安裝人員提交安裝調(diào)試的變更申請，只有當(dāng)所有變更資料都提交完后，才去驗收安裝調(diào)試過程是否合格；如果安裝調(diào)試過程達到預(yù)期目標，則可以關(guān)閉此變更申請單。配置管理變更申請一般是由用戶提出，配置管理人員會判斷是否需要備份處理。

日常巡檢管理模塊根據(jù)巡檢的設(shè)備來執(zhí)行不同的標準，巡檢記錄可以根據(jù)不同的預(yù)定義規(guī)則生成。設(shè)備管理平臺的運維人員根據(jù)巡檢標準、巡檢周期等進行設(shè)備的定期巡檢，并記錄相關(guān)的巡檢日志。相關(guān)設(shè)備的維護人員對此巡檢日志進行分析，并給出是否正常、是否有缺陷等結(jié)論，如果發(fā)現(xiàn)設(shè)備的缺陷，則依據(jù)前文介紹的缺陷管理模塊進行處理。

3 基于IT運維的設(shè)備管理平臺

基于IT運維的設(shè)備管理平臺的設(shè)備管理流程包括請實現(xiàn)、事件管理以及配置管理，其總共規(guī)劃目標是實現(xiàn)設(shè)備管理的快捷性、全局性以及經(jīng)濟性。從整體結(jié)構(gòu)上而言，設(shè)備管理平臺從上而下分為表示層、業(yè)務(wù)邏輯層以及數(shù)據(jù)訪問層三層。表示層用戶和用戶交互，業(yè)務(wù)邏輯層制定業(yè)務(wù)規(guī)則并實現(xiàn)相關(guān)的業(yè)務(wù)流程，充當(dāng)表示層和數(shù)據(jù)訪問層之間的橋梁；數(shù)據(jù)訪問層的作用是訪問數(shù)據(jù)庫。這三層之間的依賴關(guān)系是向下的，底層無法感知上層的存在，對上層的任何設(shè)計上的改變都不會影響底層。

設(shè)計基于IT運維的設(shè)備管理平臺的目的是對基于IT運維的設(shè)備管理、維護中的各項功能及非功能性需求進行設(shè)計，其中最重要的一部分是數(shù)據(jù)庫，不僅要明確數(shù)據(jù)庫的表名、字段名等數(shù)據(jù)信息，還要進行存儲過程等數(shù)據(jù)庫腳本的擴展。具體設(shè)計數(shù)據(jù)庫時，要考慮系統(tǒng)模塊相關(guān)概念的設(shè)計、數(shù)據(jù)關(guān)系圖設(shè)計以及數(shù)據(jù)的邏輯結(jié)構(gòu)設(shè)計等。使用設(shè)備管理系統(tǒng)的人員主要是系統(tǒng)管理員、維護人員以及一般用戶，不同角色應(yīng)該有不同的操作權(quán)限。數(shù)據(jù)邏輯結(jié)構(gòu)的設(shè)計包括設(shè)備數(shù)據(jù)庫關(guān)系圖、故障信息數(shù)據(jù)庫關(guān)系圖以及系統(tǒng)管理數(shù)據(jù)庫關(guān)系圖等[3]。設(shè)備數(shù)據(jù)庫關(guān)系圖包括設(shè)備的信息表、設(shè)備相關(guān)資料表等；故障信息關(guān)系圖包含發(fā)生故障設(shè)備信息表、設(shè)備備件維修信息表等；系統(tǒng)管理關(guān)系圖包含設(shè)備單位信息表、廠商信息表等等。

參考文獻

[1]李曉禹.基于SOA的設(shè)備管理信息系統(tǒng)平臺的研究與實現(xiàn)[D].南京大學(xué)，2013.

[2]孫藝新.大型電網(wǎng)企業(yè)特高壓設(shè)備運維檢修模式淺析[J].中國設(shè)備工程，2014.