徐克紅 上海鐵路局辦公室

1 引言

在計算機網絡技術的迅猛發(fā)展及對信息化的重視程度大幅提高的雙重作用下，我國企業(yè)的電子公文也蓬勃發(fā)展起來。近年來，鐵路政務網站也因國家對電子政務建設的關注度和投資水平的提高而逐步成為各鐵路單位政務公開、信息傳遞、服務旅客的重要窗口，同時電子公文系統(tǒng)也在轉變工作方式、提高辦公效率過程中發(fā)揮著至關重要的作用。電子公文不僅僅是鐵路的有關職能部門進行公文信息傳遞以及與路外單位信息溝通的重要載體和窗口，同時還是鐵路內部信息共享的重要平臺以及促成鐵路辦文模式轉型的有效手段之一。然而各級鐵路部門在電子公文的建設過程中，因地域發(fā)展的不平衡性加上各鐵路局以及各鐵路單位各自為政等多種因素綜合作用形成信息孤島等問題，這些問題已構成了電子公文系統(tǒng)可持續(xù)發(fā)展的障礙。由此看來，怎樣有效解決信息孤島和數據整合以及公文傳遞高效、流暢問題已成為電子公文持續(xù)健康發(fā)展的關鍵所在。而與這些問題相對應的是，廣大鐵路干部職工對政府與鐵路企業(yè)及各鐵路部門之間的協(xié)同能力以及公文信息傳遞的一站式服務要求逐漸提高。在這種情況下，怎樣解決公文系統(tǒng)建設的“后遺癥”，尤其是信息孤島的問題，如何進行跨地區(qū)、跨部門業(yè)務協(xié)同就成為當務之急。當前，SOA（service-orientedarchitecture），即面向服務的體系結構的提出及日趨完善則是開辟了一條解決上述問題新的思路。所謂面向服務的體系結構，也就是一個敏捷、開放、可組合、可擴展的系統(tǒng)構架，是能夠用原有的已建成的電子公文系統(tǒng)，把辦文流程及應用轉換成服務，然后通過特定的規(guī)范與協(xié)議對外提供統(tǒng)一的Web服務接口，這既能夠適應不斷變化的辦文需求，提升部門應急能力，又可使服務自治，服務間以松耦合的狀態(tài)在整個系統(tǒng)中存在，這無疑對服務重用、減少重復開發(fā)、信息冗余、節(jié)約開發(fā)成本是有利的；采用面向服務架構來構建電子公文模型，能有效避免“信息孤島”問題；同時，該模型是將提供公文信息作為核心，采用面向服務的方式來構建，能夠十分準確地體現(xiàn)各使用單位的需求。

2 國內外應用及研究現(xiàn)狀

電子公文的架構經歷了由C/S到B/S，再到分布式多層Web架構的演變，直至目前出現(xiàn)的面向服務架構。面向服務架構是一種新的規(guī)劃與構建軟件方式，Gartner公司在 1996年最先提出SOA的概念，到2002年，Gartner再次提出SOA是"現(xiàn)代應用開發(fā)領域最重要的課題"，并提出SOA的遠景目標就是讓IT變得更具有彈性。到目前為止，SOA早己成為行業(yè)信息化的首選方法，在國內外已涉及電信、金融、醫(yī)療、煙草、石油化工、電子以及公共服務等行業(yè)和領域。但是從總體來看，該架構在國內仍處于初期部署階段。

3 現(xiàn)有公文處理存在的問題

公文處理是日常辦公和管理活動的重要內容之一。在OA系統(tǒng)中占有十分重要的地位。由于組織管理改革與創(chuàng)新的發(fā)展，公文管理的運作模式和對信息化的內在需求相應地發(fā)生了質的變化，而以Internet/Intranet為核心和代表的當代信息技術體系結構、計算機模式等必需與Intranet融合。因此，實現(xiàn)公文管理的業(yè)務操作模式，結合基于SOA模式的信息系統(tǒng)開發(fā)方法和技術，反映公文信息管理本質和共性的系統(tǒng)模型，實現(xiàn)對整個公文運作過程的信息化管理，提高辦公效率。

3.1 人工工作方式與管理需求的差異

公文處理過程中，對公文的收發(fā)與辦理情況的掌握和控制，主要是通過各部門掌握的收文登記薄及公文處理單來實現(xiàn)的。主要存在以下問題：

（1）掌握信息不夠完整：人工方式由于人力和手段的局限，往往難以得到既簡明扼要又全面的有關公文辦理情況的信息，從而影響辦文質量和效率。

（2）掌握信息不夠及時：由于信息生成點較為分散，信息傳遞途徑不足，帶來了及時查詢公文信息的困難。為了提高查詢的時效，往往采用置備復印件的辦法，如此不僅增加了辦公成本，而且由于公文傳閱信息的大量冗余，增加了公文檔案管理困難。

（3）對辦文過程控制的手段不足：催辦是管理人員對公文辦理過程進行控制的主要手段，但在人工方式中，特別是在辦公工作量急劇增加的情況下，管理人員往往難以確切掌握公文的當前狀態(tài)，如哪些公文需要催辦，該公文當前在哪，部門作何辦理等，從而削弱了各級管理人員對公文辦理過程的控制。

（4）大量的冗余信息和重復勞動：由于各部門都需要掌握各自的收發(fā)文情況，在信息統(tǒng)計難以共享的額情況下，只能是公文每流經一個部門，就由該部門對公文文號、公文名等進行薄式登記。這樣的大量重復勞動，實際并未增加信息或者使信息增值，相反，大量冗余信息往往增加了管理上的麻煩，使工作人員無法從事更多的創(chuàng)造性的勞動。

（5）對辦文效率的監(jiān)管缺乏有效依據：人工難以對數以萬計的公文辦理環(huán)節(jié)進行定量的統(tǒng)計，只能依賴直覺發(fā)現(xiàn)效率的瓶頸，改善效率的入口只能靠典型的實例，缺乏必要的定量分析，從而影響了辦文效率改善的速率和實效。

3.2 現(xiàn)有計算機公文管理系統(tǒng)在系統(tǒng)技術上的局限性

目前，市場上已有一些有關公文信息管理的應用軟件產品，也在一些部門得到了一定的應用，但應用范圍和效果很有限。原因在于系統(tǒng)本身的局限性：

（1）規(guī)范化、標準化程度較低：系統(tǒng)處理公文信息的內容、范圍與公文處理的有關規(guī)范和標準存在一定的距離，系統(tǒng)共享性和普遍性較差。

（2）系統(tǒng)功能的局限性：大多數的現(xiàn)有系統(tǒng)，局限于公文的收發(fā)和登記，以及簡單的查詢，不能支持公文運作的全過程。

（3）系統(tǒng)體系結構和操作性方面的問題：大多應用系統(tǒng)的結構都是基于B/S模式上，有的甚至工作在C/S模式，而沒有轉向SOA體系結構。另外，由于沒有采用先進的SOA技術，使得系統(tǒng)在系統(tǒng)兼容性、數據共享性、資源復用性等方面不能滿足現(xiàn)在公文管理的需要。

4 系統(tǒng)模型

4.1 公文處理的工作流程分析-系統(tǒng)業(yè)務模型

4.1.1 管理層次

以鐵路局為例，從管理組織結構的角度，可將公文管理劃分為如圖1所示的管理層次。

圖1 鐵路局管理層次

4.1.2 工作流程圖

公文信息處理工作包括兩個方面：發(fā)文和收文處理，其過程用工作流程圖表示如圖2所示。

圖2 公文處理流程

4.1.3 SOA體系結構

SOA是基于“服務”來進行構造的，“服務”間的交互與組合是通過一種基于“服務中介平臺”的方式來實現(xiàn)松耦合的，“服務”被提供及使用過程。

4.2 基于SOA的電子公文結構圖

電子公文系統(tǒng)建模目標是通過連接和整合現(xiàn)有政府、鐵路各單位內外網以及各種廣域/局域數據庫和應用系統(tǒng)，統(tǒng)一平臺接入與資源調配，把公文信息傳遞從各分散的公文系統(tǒng)抽取出來，從而形成電子公文應用服務，構建集成到該模型的 Webservice層，并由本單位的電子公文系統(tǒng)呈現(xiàn)出來。該模型既著眼于為鐵路系統(tǒng)內的公文辦理服務，又可以通過互聯(lián)網向社會公眾和路外單位提供一站式服務，樹立了鐵路"服務型"的新形象，還能進行公文信息資源（涉密文件除外）整合以實現(xiàn)資源共享和管理。其體系結構如圖3所示。

圖3 基于SOA的電子公文結構圖

4.3 基于面向服務的電子公文系統(tǒng)的網絡結構設計

電子公文網絡依據公文傳遞所轄的范圍和密級的不同可將其劃分成三部分：第一部分是互聯(lián)網，即外網。它的功能是對路外單位傳遞公文，是為鐵路企業(yè)和路外單位提供服務和溝通交互的窗口；第二部分是專網，其功能是各鐵路局之間和鐵路部門之間開展政務協(xié)作、及時傳遞公文、實時辦公以及信息共享；第三部分是內網。是指鐵路部門內部主要涉及公文辦理以及公文傳遞的過程。當前電子公文的基本網絡構架都是統(tǒng)一部署為“三網一庫”，它主要是指“內網、專網、外網”和信息資源庫。內網，即為電子公文系統(tǒng)。主要是涉及鐵道部與鐵路局、鐵路局間及局內單位間有關公文信息傳遞，它是鐵路內部的網上辦公系統(tǒng)。因其存在文件及公文檔案信息，依據國家的相關規(guī)定，該網絡是必須同另外兩部分網絡進行物理隔離。

5 結論

本文將 SOA構架設計與提高辦文效率理念為電子公文模型設計思想，設計出面向服務的電子公文系統(tǒng)結構?；诿嫦蚍盏碾娮庸南到y(tǒng)是在保持現(xiàn)有系統(tǒng)平臺可用的前提下，對鐵路部門內部提供協(xié)作辦公以及公文傳遞，對鐵路部門以外單位提供“快捷式”服務。在此基礎上實現(xiàn)各個部門、相異位置、各種不同格式的公文數據共享及交換，并可有效解決電子公文發(fā)展中存在的信息孤島及數據整合等問題。本文構建的系統(tǒng)架構可普遍適用于各單位的電子公文系統(tǒng)建設。但是，在真正應用了基于 SOA的架構以后，公文流程得到梳理，內控能力也得到了加強，但實際上這種架構是需要一個程序來對這些流程進行統(tǒng)一管理。假如管理程序一旦出錯或造成混亂的話，會產生極其嚴重的后果。作為提供統(tǒng)一接口標準的服務平臺（Webservice層）此時就相當于一個堡壘 ，若想做出一個能夠接入所有數據格式并能提供準確服務的平臺是非常困難的，也會產生新的安全問題。