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

篇1

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

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

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

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

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

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

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

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

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

D (i)為修正因子。

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

篇2

[關鍵詞] 商業(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)定性高、風險可控性高、數據安全性高以及業(yè)務影響?。ā叭咭恍　保┑奶攸c，將程序和數據變更的管理過程通過信息系統(tǒng)實現(xiàn)信息化、自動化的過程。通過變更管理信息化建設可以有效減少因硬軟件問題造成業(yè)務中斷，降低操作風險[1]，實現(xiàn)變更管理自動化，全程可控可回退。

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

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

2 變更管理

2.1 組織結構

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

2.2 管理流程

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

3.2 開發(fā)模式

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

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

3.3 團隊架構

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

3.4 技術實現(xiàn)

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

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

4 實 踐

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

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

5 總 結

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

主要參考文獻

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

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

篇3

4M變更管理辦法最新版

1、目的

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

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

2、適用范圍

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

3、4M定義：

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

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

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

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

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

4、職責

4.1變更提出

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

4.1.1制造部技術組：負責產品工藝流程、模具、工裝、檢具及方法等變更的實施。

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

4.1.3供應鏈：材料(含構成零部件)變更的申請?zhí)岢龊蛯嵤肮痰淖兏芾?

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

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

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

4.2 變更評審實施

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

注：評審部門包括但不限于技術部門/生產部門/質量部門/采購部門/設備管理部門。

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

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

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

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

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

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

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

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

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

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

6 變更管理內容

6.1 客戶提出的4M變更

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

6.2 供應商的4M變更

供應商提出的4M變更，由供應商向采購部門提出，向公司內部傳達;

6.3 公司內部的4M變更

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

6.5 變更品的首次交貨

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

6.5.2變更品與原來產品在同一批交貨時，需：

1.原來產品與變更品的外包裝分開;

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

篇4

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

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

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

 二、典型處理流程

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

 （一）事件管理流程

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

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

 （二）問題管理流程

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

（三）配置管理流程

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

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

 （四）變更管理流程

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

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

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

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

 四、結語

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

參考文獻

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

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

篇5

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

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

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

其中合同會簽管理又可分為合同會簽起草，合同會簽審批，合同會簽查詢三個子模塊。

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

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

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

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

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

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

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

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

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

篇6

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

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

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

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

1.1 調運管理

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

1.2 運銷計量管理

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

1.3 計劃管理

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

1.4 能耗及周轉量管理

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

1.5 天然氣用氣需求預測

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

1.6 日指定

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

2 運行維護管理體系

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

2.1 運行維護工作內容

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

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

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

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

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

2.2 運行維護流程

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

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

2.3 運行維護理論

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

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

2.4 運行維護平臺

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

2.5 運行維護的實施

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

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

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

參考文獻：

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

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

篇7

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

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

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

2業(yè)務角色設計

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

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

2.2 SOC管理人員用分析

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

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

3管理流程設計

3.1 SOC管理流程的設計

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

3.2 SOC流程實例的獲取

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

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

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

static JbpmSessionFactory jbpm SessionFactory=

JbpmSessionFactory.buildJbpm SessionFactory();

JbpmSession jbpmSession jbpm SessionFactory.openJbpmSession();

Try{

jbpmSession.beginTransaction};//開始一個事務

//從數據庫中查詢流程定義

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

}Catch(Exception e){}

finally{

//關閉jbpmSession

jbpmSession.close(); }

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

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

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

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

4結語

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

參考文獻

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

篇8

變更配置保證應用效率

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

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

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

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

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

變更管理核心為CMDB

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

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

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

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

篇9

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

0 概述

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

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

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

1.1 賬戶管理模塊

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

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

1.2 數據庫模塊

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

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

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

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

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

1.4 項目審批流程模塊

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

1.4.1 數據/報告上傳子模塊

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

點擊“報告上傳”生成《定期試驗報告頁》?！抖ㄆ谠囼瀳蟾骓摗钒ǎ喉椖炕拘畔?、試驗數據及判定結果、必要的文字說明、部門審批路徑設置、試驗規(guī)程上傳、重要附件上傳等。其中，“試驗數據及判定結果”包括：該項試驗對應試驗參數、各參數對應的試驗值、各參數判定結果；“部門審批路徑設置”包括：報告類別、部門審批賬戶、審批時間、意見、審批結果。

1.4.2 部門審批子模塊

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

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

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

1.4.4 不合格/待定子模塊

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

1.4.5 個人待審批子模塊

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

1.5 結果查詢模塊

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

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

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

“趨勢分析”可查詢定期試驗任意關鍵參數對應試驗結果在選定區(qū)間內的趨勢圖。

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

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

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

1.7 項目變更模塊

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

2 總結

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

篇10

關鍵詞：IT運維；管理平臺；設備管理

1 設備管理平臺的需求及流程設計

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

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

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

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

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

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

圖1 設備變更管理的內容

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

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

3 基于IT運維的設備管理平臺

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

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

參考文獻

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

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