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

篇1

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

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

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

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

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

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

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

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

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

D (i)為修正因子。

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

篇2

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

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

[中圖分類號] F830.33；TP315 [文獻(xiàn)標(biāo)識碼] A [文章編號] 1673 - 0194（2014）03- 0030- 04

1 概 述

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

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

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

2 變更管理

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

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

2.2 管理流程

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

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)進(jìn)行充分設(shè)計(jì)，采用原型化方法進(jìn)行系統(tǒng)建模，系統(tǒng)建設(shè)者與變更制度制定者、變更執(zhí)行者不斷調(diào)整原型各要素使其更貼近真實(shí)場景，各方試用后進(jìn)入下一步開發(fā)。

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

3.3 團(tuán)隊(duì)架構(gòu)

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

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

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

其次針對各模塊可能遇到的技術(shù)瓶頸、所需公共控件，由公共控件組研究相應(yīng)的技術(shù)解決手段。變更管理涉及復(fù)雜的文檔管理過程，需要建立文檔解析引擎及文件傳輸控制引擎；變更操作及驗(yàn)證涉及向服務(wù)器發(fā)送及解析信令的過程，需要建立遠(yuǎn)程主機(jī)通信自動解析調(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 實(shí) 踐

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

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

5 總 結(jié)

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

主要參考文獻(xiàn)

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

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

篇3

4M變更管理辦法最新版

1、目的

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

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

2、適用范圍

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

3、4M定義：

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

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

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

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

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

4、職責(zé)

4.1變更提出

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

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

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

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

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

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

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

4.2 變更評審實(shí)施

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

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

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

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

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

5.1 送樣：變更前須試制樣品，并向客戶送樣認(rèn)可。

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

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

5.2 申請：變更須啟動4M變更管理流程進(jìn)行評審實(shí)施。

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

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

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

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

6.1 客戶提出的4M變更

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

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

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

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

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

6.5 變更品的首次交貨

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

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

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

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

篇4

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

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

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

 二、典型處理流程

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

 （一）事件管理流程

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

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

 （二）問題管理流程

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

（三）配置管理流程

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

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

 （四）變更管理流程

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

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

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

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

 四、結(jié)語

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

參考文獻(xiàn)

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

 [2]孫強(qiáng)，左天祖，劉偉．IT服務(wù)管理——概念、理解與實(shí)施[M]．機(jī)械工業(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è)計(jì)關(guān)系模式并建立如下數(shù)據(jù)庫表和其中字段：1、合同信息表（合同ID，合同名稱，合同簡介，合作伙伴ID，合同類別ID，合同年份，項(xiàng)目ID，總金額，經(jīng)辦人，經(jīng)辦部門，合同履行開始時間，合同履行結(jié)束時間，歸檔人，歸檔日期，工作流序號，工作流狀態(tài)，驗(yàn)收終止日期，企業(yè)編碼）。2、合同類別表（合同類別ID，合同類別名，識別碼，說明，修改人，是否使用）。3、合同變更申請表（合同變更ID，合同變更編號，合同ID，經(jīng)辦人，申請部門，變更類型，原合同金額，現(xiàn)合同金額，變更理由，備注，工作流序號，工作流狀態(tài)，起草人，起草日期，企業(yè)編碼）。4、合作伙伴信息表（合作伙伴ID，合作伙伴性質(zhì)ID，重要程度ID，行業(yè)ID，合作伙伴編號，合作伙伴名稱，公司負(fù)責(zé)人，基本介紹，業(yè)務(wù)范圍，主要業(yè)績，公司地址，聯(lián)系電話，電子郵箱，公司網(wǎng)址，法人代表，納稅人資格，開戶銀行，帳號，注冊資金，備注）。5、用戶信息表（用戶ID，用戶工號，用戶姓名，是否使用，企業(yè)編碼）。

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

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

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

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

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

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

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

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

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

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

篇6

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

中圖分類號：C93文獻(xiàn)標(biāo)識碼： A

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

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

1.1 調(diào)運(yùn)管理

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

1.2 運(yùn)銷計(jì)量管理

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

1.3 計(jì)劃管理

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

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

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

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

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

1.6 日指定

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

2 運(yùn)行維護(hù)管理體系

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

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

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

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

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

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

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

2.2 運(yùn)行維護(hù)流程

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

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

2.3 運(yùn)行維護(hù)理論

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

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

2.4 運(yùn)行維護(hù)平臺

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

2.5 運(yùn)行維護(hù)的實(shí)施

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

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

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

參考文獻(xiàn)：

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

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

篇7

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

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

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

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

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

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

2.2 SOC管理人員用分析

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

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

3管理流程設(shè)計(jì)

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

jBPM是一個靈活的、易擴(kuò)展的開源工作流管理系統(tǒng),也是一個基于J2EE的輕量級工作流管理系統(tǒng)。jBPM的另一個特色是它使用Hibernate來實(shí)現(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ù)邏輯的實(shí)現(xiàn)。

3.2 SOC流程實(shí)例的獲取

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

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

//獲取實(shí)例類JbpmSessionFactory的唯一一個實(shí)例

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();//進(jìn)行其他業(yè)務(wù)操作

}Catch(Exception e){}

finally{

//關(guān)閉jbpmSession

jbpmSession.close(); }

通過在數(shù)據(jù)庫中查詢已部署的流程定義,利用該流程定義創(chuàng)建新的流程實(shí)例,此方法用于流程定義已被部署,要開始一個新的流程實(shí)例的情況。由于要與數(shù)據(jù)庫打交道,必然要跟事務(wù)相聯(lián)系,所以應(yīng)將對流程的操作放在單獨(dú)的事務(wù)操作中,此處放在jbpmSession.省略mtiTransaction()范圍中,事務(wù)操作完后,不管它成功如否,都要將事務(wù)進(jìn)行關(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)限。其中項(xiàng)目申請人只能查看具有權(quán)利的項(xiàng)目,而系統(tǒng)管理員可通過工作流引擎獲取當(dāng)前全部流程實(shí)例的信息,對SOC管理流程進(jìn)行監(jiān)控和督辦。

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

4結(jié)語

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

參考文獻(xiàn)

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

篇8

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

對此，F(xiàn)orrester Research指出，近20%的業(yè)務(wù)核心應(yīng)用軟件的癱瘓，是因?yàn)橛?jì)劃中變更的相關(guān)性，沒有考慮IT部件和核心業(yè)務(wù)之間的關(guān)聯(lián)而引起的。另據(jù)Gartner Group調(diào)查顯示，40%意想不到的應(yīng)用程序癱瘓是由應(yīng)用程序的故障造成的;40%是因?yàn)椴僮麇e誤;只有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），它們都具有自動部署并維護(hù)的特點(diǎn)，這是企業(yè)進(jìn)行管理所必不可少的。面對如此眾多的產(chǎn)品，如何選擇？

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

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

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

變更管理核心為CMDB

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

因?yàn)樗械牟僮鞫紩纬梢粋€核心的CMDB。為了達(dá)到數(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)，這三個組件都是以基于標(biāo)準(zhǔn)的CMDB為基礎(chǔ)的。

篇9

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

0 概述

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

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

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

1.1 賬戶管理模塊

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

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

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

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

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

1.3 定期試驗(yàn)日常/大修項(xiàng)目管理模塊

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

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

1.4 項(xiàng)目審批流程模塊

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

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

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

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

1.4.2 部門審批子模塊

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

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

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

1.4.4 不合格/待定子模塊

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

1.4.5 個人待審批子模塊

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

1.5 結(jié)果查詢模塊

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

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

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

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

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

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

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

1.7 項(xiàng)目變更模塊

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

2 總結(jié)

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

篇10

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

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

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

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

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

2 IT運(yùn)維管理平臺的功能模塊

缺陷管理模塊中可以創(chuàng)建關(guān)聯(lián)的變更單，此時有缺陷的被管理設(shè)備的狀態(tài)被標(biāo)記為“擱置”，缺陷問題被創(chuàng)建后，一旦缺陷問題被成功關(guān)閉，則可以根據(jù)缺陷的解決狀態(tài)進(jìn)行設(shè)備的狀態(tài)變更，解決的缺陷其狀態(tài)被變更為“已解決”。缺陷的記錄一般由發(fā)現(xiàn)缺陷的人員進(jìn)行，缺陷驗(yàn)收合格后，設(shè)備管理平臺的運(yùn)維人員需要注明缺陷處理的相關(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è)備變更單，對于處理完成的變更單，如果其達(dá)到預(yù)期目標(biāo)，那么此變更單相關(guān)的設(shè)備變更流程即可關(guān)閉，否則此變更處理流程需要被返回。檢修人員作出的檢修申請形成變更申請單，如果此變更申請單涉及到的是通信的檢修或停退，需要判斷此檢修過程是否存在檢修計(jì)劃，目的是讓用戶明確的知曉，從而指導(dǎo)設(shè)備管理[2]。安裝人員提交安裝調(diào)試的變更申請，只有當(dāng)所有變更資料都提交完后，才去驗(yàn)收安裝調(diào)試過程是否合格；如果安裝調(diào)試過程達(dá)到預(yù)期目標(biāo)，則可以關(guān)閉此變更申請單。配置管理變更申請一般是由用戶提出，配置管理人員會判斷是否需要備份處理。

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

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

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

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

參考文獻(xiàn)

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

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