序言：寫作是分享個人見解和探索未知領域的橋梁，我們為您精選了8篇的電子政務系統論文樣本，期待這些樣本能夠為您提供豐富的參考和啟發，請盡情閱讀。

第1篇

關鍵詞：電子政務；體系結構

0引言

電子政務e-Governmentaffair是政府在其管理和服務職能中運用現代信息和通信技術，實現政府組織結構和工程流程的重組優化，超越時間、空間、和部門分割的制約，全方位地向社會提供優質、規范、透明的服務，使政府管理手段的變革。這里，介紹一下這個信息系統體系的結構，并提出自己的一點看法，旨在拋磚引玉，與各位導師、同學、同仁商榷。

1該市電子政務信息系統的技術介紹

導師與本小組接手的該市電子政務公共信息平臺的建設規劃，這個電子政務系統通過采用當前的先進技術，將軟硬件集成起來，以克服體系結構不同及軟件自身不成熟造成的影響。具體技術路線是：采用J2EE技術，保障系統的可伸縮性、可擴展性和開放性；系統采用框架體系設計，數據庫采用高可用容技術，應用中間件采用cluster（集群）技術，保證平臺從信息存儲到信息都具有較高的穩定性、開放性和高集成性；系統采用B/S+C/S結構，底層為數據層，存取關系型數據、文檔型數據和其他業務系統數據，中間層基于應用服務器，各種業務組件注冊在應用服務器上進行管理，采用XML進行數據的組織，通過JSP構造好用戶訪問界面并把各種業務邏輯連接起來，通過WEB服務層響應客戶端的請求，客戶端采用瀏覽器方式進行訪問。該電子政務系統的主要建設過程和結構如下：

2該市電子政務信息系統的功能結構介紹

該市國產化電子政務平臺正常運轉一年多，平臺上已經實現了市政府門戶網站及90多個部門的分網站的、“誠信企業”企業信用數據交換系統、公務員的電子郵件系統、遠程辦公信息交換系統、辦公信息資源管理系統、網上市民對話服務系統、網上電子表單下載系統等多項應用。

2.1政府門戶網站。政府門戶網站是該市國產化電子政務平臺上第一項應用，網站分簡體中文、繁體中文、英文、日文、韓文五種語言版本，設有煙臺概況、政務、經濟、投資、生活、科教、擇業、旅游、參政、在線服務、縣市區、數字地圖、政府信箱等13個主欄目；今日新聞、政務動態、誠信動態、市民手冊、政府文件、政務公開、電子商務等18個板塊欄目和市民、企業、農民、投資者、旅游者、學生、公務員、弱勢群體等8個定制頻道。總信息量達兩百多萬條，日訪問量超過兩萬多人次。

2.2該市政府部門網站。該市電子政務平臺上運行著90多個政府部門和單位的網站。政府門戶網站與各部門網站之間統一通過平臺進行連接、與管理。各部門的對外的數據、信息由平臺統一管理，形成較完整的政務公共信息資源數據庫。這種數據的高度集中存放，為信息資源的深度開發和綜合利用打下了良好的基礎。

2.3“誠信企業”企業信用數據交換系統。該市電子政務平臺上運行的“誠信煙臺”企業信用數據交換系統，實現了與工商局、人民銀行、國稅局、地稅局、質監局、海關、法院、公安局、環保局、勞動保障局、建設局、信息產業局等部門和單位的實時數據交換，初步形成全市統一的企業信用信息數據庫。

2.4遠程辦公信息交換系統。該市電子政務平臺上運行的遠程辦公信息交換系統，解決了分布辦公的部門之間、部門內部的文件及資料傳遞問題，實現了辦公信息交換無紙化。遠程辦公信息交換系統具有用戶管理、發文管理、收文管理、系統設置、文件庫管理、在線幫助等功能。

2.5辦公信息資源管理系統。該市電子政務平臺上運行的辦公信息資源管理系統是針對各類管理部門的具體業務需求而開發的，集文件管理、信息管理、業務管理、協同管理、知識管理等辦公功能于一體，是具備與業務系統、門戶網站接口的新型管理信息系統。該系統是實現辦公信息資源的整合、提高辦公效率和領導決策支持的有效工具。

2.6公務員電子信箱服務。該市電子政務平臺采用國產的紅旗WebMail分級多域的郵件系統，為70多個部門和單位的3000多用戶提供電子郵件服務，日完成數萬封郵件的收發和傳遞。

2.7網上市民對話服務系統。該市電子政務平臺上運行的網上市民對話服務系統是政府部門與市民溝通、交流的平臺。

2.8網上電子表單下載系統。該市電子政務平臺上運行的網上電子表單下載系統，提供了30多個部門的280多項行政審批事項的表單下載服務，50多個部門的580多項辦事指南，實現了網上納稅和部分業務網上申報等功能。

3該市電子政務信息系統的層次結構

考慮到政府門戶建設的現在和發展需求，系統應用平臺具備跨平臺、支持多種數據庫環境的能力，采用構件化設計方式，易于擴展和維護。

從邏輯體系架構來看，如上圖，辦公信息系統分為多個層次：

3.1用戶層：與系統連接的外部實體。用戶通過瀏覽器訪問管理信息系統。具有交互功能，進行填寫信息、提交請求的操作，請求結果返回在客戶端顯示。

3.2權限控制層：按照用戶管理和權限控制列表，審核用戶的合法性和訪問權限，保證系統和信息安全。用戶個性化界面控制。

3.3表示層：對最終用戶提供友好的界面，更好地為系統用戶提供優質服務。

3.4信息接入層：這層中的Web服務器用于對外提供基本的靜態信息傳遞服務，向后臺應用服務器提供客戶請求信息并接收返回的信息。

3.5應用層：完成業務的邏輯控制和流程處理，進行初步的應用安全控制和權限檢查，記錄原始的交易日志，進行交易的存儲轉發等。

3.6數據訪問層：采用統一的方法訪問后臺數據。這層中的數據庫系統用于結構化信息的存儲和處理，是系統的數據核心。郵件服務器用于提供系統的郵件支持。

3.7系統層：提供應用系統的運行環境平臺和對硬件系統的管理操作。

3.8硬件層：提供整個系統的硬件平臺，確保系統正常運行。

4總結

該市電子政務公共信息平臺按照“以實際應用為主導，以資源整合為主線，優先使用國產產品，全面引入市場機制”的建設思路，注重實效，力求實現政府部門通過一個統一的平臺，及時各類政策法規和政務信息，提高政府公共服務水平和社會管理能力。

參考文獻：

第2篇

經過SARS等一系列公共衛生突發事件后，應急信息系統的建設受到了空前的重視。我國各級政府、各部門都把應急信息系統或應急指揮中心的建設提上了議事日程。例如，北京市公共衛生信息應用系統的建設，就是在以往的經驗教訓基礎上，把應對公共衛生突發事件作為一個主要建設目標；衛生部應急指揮中心向社會公開招標，征集建設方案，等等。在政府推動下，應急信息系統建設已經進入一個高峰期。

應急信息系統的建設受到全社會范圍的重視，這是一件好事。但同時也帶來了問題：系統建設的目標到底是什么？多個相關項目如何統籌？怎樣處理應急信息系統建設與業務處理系統的關系？應急信息系統的功能邊界應該如何劃分？等等。對這些問題如果沒有一個正確的思路，應急信息系統建設的大規模投入就難以收到應有的社會效益，甚至象以前辦公自動化和門戶網站一樣，變為一場“運動”。

本文試圖對應急信息系統給出一個目標，描述“理想”情況下的系統模型和需求；在此基礎上給出對整個應急信息系統規劃的看法。

二、應急信息系統的目標和功能需求分析

應急信息系統的目標，就是配合危機管理的全過程，應用信息技術，實現大面積的、跨專業和部門的信息資源、處理資源和通訊資源的實時調度，使應急指揮過程更加科學化和可視化。

這里用到了一個超越“應急”的概念——危機管理，我們把支持危機管理作為應急信息系統的目標。這是因為，要最大限度減少各種突發或緊急事件帶來的損失，不僅僅要求我們在事件發生后做出迅速、準確的應對和處理，還要求我們在事件前期進行預警和辨識、在后期進行常態恢復。“危機管理”的三階段理論更能指導我們運用信息技術對突發或緊急事件全面、全程的支持。

顯然，這一目標，不是一個單純的信息系統可以達到的。它要依賴基礎性的網絡和多個專業化的應用系統，要依賴多種技術的支持。但是，越是復雜，我們就越應該分析清楚，那些是核心、哪些是基礎、哪些是錦上添花；哪些應該先建，哪些可以后建。否則眉毛胡子一把抓，不利于復雜系統的建設和統一的規劃。

我們用如下的三層邏輯模型表示應急信息系統及其支持系統的關系。

……

應急信息系統

信息處

理系統

通訊調

度系統

信息

采集

信息

調度

資源

調度

信息

表現

基本網絡和通訊系統

輔助

決策

應用支持層

集成應用層

基礎設施層

GIS

應急信息系統的三層邏輯模型

各層的關系如下：最高層即是應急信息系統的核心功能，它是一種集成式應用；專業化的信息處理系統和各種相對成熟的技術系統（如GIS和Call Center系統）是構建應急信息系統的支撐性應用，我們稱之為應用支撐層；而基本網絡和通信系統是以上所有應用的基礎。相鄰層次之間有著雙向的信息供求關系。

我們從對信息的處理角度來分解應急信息系統的功能目標。

任何類型和目的的應急指揮系統，都具有以下功能特性：

1、信息匯聚：從應急事件現場或監測網絡采集到的各種信息，將被傳輸到信息匯聚點（應急指揮中心）。這些信息可能是直接事件現場的視音頻信息，也可能是來自傳感設備、監控設備的信息或信號，還可能是來自相關的專業化信息處理系統的數字化信息。

2、信息表現：應急信息系統應該有直觀而準確的信息表現形式，為指揮員進行指揮調度和輔助決策提供最大的幫助。GIS是一項廣泛使用的技術，可以將危機管理所涉及的信息（如危機態勢、應急指揮相關資源分布、應急方案等）在基礎的空間地理圖形上形象地表現出來，便于指揮和決策人員直觀地進行形式判斷、形成決策或進行資源調度；各種信息還可能要借助一定的顯示設備和顯示控制系統表現出來。

3、信息調度：所有信息在匯聚點被組合和集中呈現，供指揮中心的指揮決策人員作為決策和調度依據；有時還要將信息分發下級指揮中心（或分中心）的不同的專業化處理系統進行處理，或從這些系統收集處理結果。

4、通訊和物資資源調度：應急指揮最終都表現為通過一定的通訊手段，完成一定的人力、物力資源調度。例如警力的調度、救災物資和設施調度、對事件現場的疏導和部署，等等。

5、輔助分析決策：在應急指揮過程中，提供一些邏輯分析模型、統計模型或預案，以及案例庫中的參考案例，幫助指揮員進行理性決策；同時，應急信息系統還應記錄下整個指揮調度的過程，形成完整案例，豐富案例庫，為實現知識化、智能化的危機管理作積累。

以上是一個較為抽象的邏輯功能模型，它有助于我們把握應急信息系統的核心建設目標，合理運用各種技術和各種“物理的”系統。

三、應急信息系統與其它信息系統的周邊關系

1、技術型應用系統與應急信息系統的關系

在應急信息系統建設領域的最大誤區，在于信息系統功能需求分析的缺失——從需求的陳述（實質上是一種需求定義）直接跳到技術方案，甚至成為技術方案或產品的簡單堆砌。以技術方案代替功能需求，這似乎已經成為了一種應急信息系統建設中的普遍現象。

例如，我們經常能在招標書或所謂規劃中看到這樣的做法：即直接把“數字錄音系統”、“大屏幕顯示系統”、“地理信息系統”等作為“需求”本身的內容，對具體的技術實施方案和產品型號進行招標，甚至還有的招標書把“數據庫系統”也作為應急信息系統需求的一部份提出來。這里面缺少了對應急信息系統的實質內容和目標的把握，缺少了一個理性的論證和分析過程。這樣的“需求”拿出來招標，多半會造成建設的混亂和失控。

并不是說以上的技術系統不能作為應急信息系統的一部分，相反，邏輯的功能最終都會落實為一系列“物理”的技術子系統。但是我們在進行技術子系統的劃分和分包之前，有必要對有機信息系統的“原始”功能需求作一定義和陳述，為技術方案的展開提供理性的約束，而不會被技術牽著鼻子走。

例如，GIS是一種廣泛使用的、成熟的技術，也已經形成相對獨立運行的系統。獨立運行的GIS甚至可能成為整個應急信息系統中最主要的操作平臺。這也是一些項目直接把GIS作為一種“默認”的“需求”的原因。但是，應急信息系統是否要采納GIS，還要看具體的應用領域是否具備了應用GIS的數據條件和環境。而且，即使有必要和有條件使用GIS，也要從整個應急信息系統的總體目標出發進行分析，提出技術應用需求：

第一， 要實現應急信息系統與GIS的雙向聯動。GIS雖然可以獨立運行，但在應急信息系統環境下，應該可以實現應急信息系統與GIS的多種聯動方式——包括雙向的相互驅動和基于數據共享的獨立操作，等等；

第二， 要實現應急信息系統與GIS的底層整合。GIS系統與應急信息系統應共同遵循一定的數據標準，產生和傳遞一致的數據；底層應實現數據庫共享或公用。

第三， GIS與其他系統的數據整合。GIS的基礎數據來自測繪部門，而應急指揮所需的“活”的應用數據往往來自其他業務部門，如建設、交通、氣象、衛生，等等。為讓信息系統能夠運行起來而“一勞永逸”地導入數據的做法是不可取的。應該充分利用這些“活”的地理數據，建立與數據源進行同步更新的完整機制，貫徹專用屬性數據“誰使用、誰負責”和合理共享的原則，避免產生新的信息孤島。

以上是應急信息系統中對GIS的需求分析應該考慮的內容。只有對這些問題都分析清楚了，才可能對應急信息系統中GIS的必要性、可行性和技術方案和造價作一正確判斷。而這種全局的、客觀的、中立的分析，恐怕要在請GIS廠商提供技術方案之前完成。

在應急信息系統領域，類似的成熟技術系統還有Call Center、知識管理系統、視頻會議和視頻監控系統等。對這些相對成熟、“自成一體”的技術應用系統，都要作類似的分析，才能保證最后的應急信息系統是一個有機的、完整的、體現建設初衷的系統，而不是一組不分主次、繁復、獨立的技術系統。

忽視需求分析或缺乏正確的需求分析方法，是存在于信息化建設的通病。對于應急信息系統建設而言，這種只有方案，沒有需求分析的現象尤其有害。因為應急信息系統的建設幾乎成了一種潮流，而且它同時承載著政府危機管理和電子政務信息資源整合的雙重重任。缺乏對需求的分析和規劃，會使應急信息系統建設失去理性，導致盲目建設和重復建設，與信息資源整合的精神背道而馳。

2、專業化信息處理系統與應急信息系統的關系

我們對應急信息系統的需求認識往往是始于“混沌”的。尤其是當因為信息系統缺位造成重大損失的時候，更是希望通過一個項目、甚至一個系統的建設畢其功于一役。但是，應急信息系統的主要目標是實現危機管理中的決策支持，離開了專業領域的知識和專業化的信息處理系統的支持，應急信息系統對科學決策的支持就會落空。另一方面，應急信息系統往往是跨管理部門、跨專業領域的系統，涉及多個專業系統。處理這種兼具“寬度”和“深度”的復雜需求的合理做法，是把項目進行分解，把應急信息系統建設與專業化信息處理系統進行合理劃分。

一般來說，專業化信息系統負責專業化的信息監測和預警、信息處理；應急信息系統則負責信息的匯聚、分析，以及對會商、決策和資源調度的支持；二種系統之間通過共同認可的標準來實現信息傳遞和工作協同。應急信息系統從專業化信息處理系統中收集預警監測的結果；應急信息系統則向專業化信息處理系統提交信息加工請求并收集信息處理結果。

檢驗是否較好劃分了專業化信息處理系統和應急信息系統界限的直接辦法，是看二者之間是否有足夠的獨立性。一個好的規劃和設計應該是這樣的情形：應急信息系統本身不一定很“專業”，但它能與很專業化的信息處理系統高效地協同工作。應急信息系統的核心價值，在于它對跨專業的、公用資源的調度能力；專業的判斷和業務流程應該留給專業化的信息處理系統。從這點上來說，應急信息系統其實需要有一定的“通用性”。通用性越好，它動態“接入”不同專業信息系統的能力就越強，整個大系統的“應急”能力也就越好。

舉個例子，假設我們針對SARS的預防和控制建設了一個公共衛生應急信息系統，如果它不能百分之八十、九十，甚至更高比例地應用到其它公共衛生突發事件的處理上，那么它的規劃和需求定義就是失敗的。相反，如果我們在進行需求分析的時候，能把專業化事件處理的差異性需求盡可能地體現在“應用支持層”的專業化信息處理系統中，那么無論是作為通用應急指揮平臺的公共衛生應急信息系統，還是專業化的傳染病管理信息系統、醫院管理信息系統、以及各種科研信息系統，等等，都能沿著相對穩固的需求軌跡發展。

四、應急信息系統的規劃與標準化

現在我們跳出單個應急信息系統的需求分析，來看看多個系統——或者說整個城市級別的應急信息系統——的需求，或者說一種規劃。

根據上面的分析可知，我們如果采用一個相對通用的“應急信息系統”和一系列專業化信息處理系統，可以構成一個完整的、面向各種突發事件的應急信息系統“兩層”構架。也即從理論上說，可以構建城市級別的唯一的、集中的、公用的應急信息系統平臺。但在實際操作中，有兩個因素制約這種“兩層架構”模式。一是系統的規模和負載問題；二是現有的行政管理體制的制約。

根據系統論的原理和系統工程實踐經驗，每個系統下轄的子系統個數是有限的，超出這一限度，不僅系統的業務負載和復雜度會難以承受，為保障系統運行可靠性所付出的代價也會十分巨大。我們通常采用系統分級的辦法來解決這一問題。在應急信息系統建設中，就是通過建立一些區域的或“領域”分中心來分擔“總中心”的負載和復雜性。

但是，采用分中心的“三層”構架，應該滿足兩個先決條件。否則，就有可能使整個城市的應急信息系統更加混亂和難于管理，操作起來無所適從，甚至變成一盤散沙，為信息資源綜合增加新的負擔。

第一個條件，還是比較、分析和論證。在具體的城市危機管理環境中采用三層構架，一定要有與兩層構架的對比分析。三層系統的優勢在于其上的業務操作流程通常可以更好吻合現有管理體制；劣勢是分級處理帶來了額外的信息分配和匯總的效率開銷，甚至為一些導致低效的“門檻”創造了條件。我們對架構進行分析的結果，應該不僅僅是一個構架的模式，而且有具體的構架實施方案，包括對弱點的分析，以及彌補的方法，作為系統后續建設的前提條件。這是應該在決定建分中心之前完成的。

在實際建設過程中，對于城市應急信息系統的構架模式選擇，盲目模仿或是“拍腦袋”的情況還是很多的。構架的選擇往往不是對流程科學性、系統運行效率、系統建設周期和投入、系統的可操作性等因素進行分析比較的結果，而是避開業務整合的深層困難、對現有管理體制過分遷就和妥協的結果。這對于整個城市的危機管理和信息化建設都是非常不利的。

第二個條件，無論是二層還是三層構架，都離不開標準化基礎。統一的數據標準制定應該在應急信息系統的總體規劃層面，而不是某個具體的應急信息系統建設的層面來進行。在某個具體應用系統中談統一標準的意義是十分有限的。即使每個系統都實現了“內部”的統一標準，也可能導致多個系統之間無法溝通。

對于標準化的認識，也是信息化建設中誤區多多的一個領域。如把統一數據規劃甚至統一數據庫設計等同為數據標準化，把標準化局限于管理標準化而無視應用標準化，把應急信息系統的標準化局限于應急事件的分級，等等。應用標準化是我國信息化建設的一個弱點和緊迫點，也是應急信息系統建設的一項基礎性工作。如果能在國家層面整合專業化研究資源，組織面向應急指揮和危機管理的統一的標準化研究，則能有效促進整個國家的應急信息系統的建設；反之，如果我們不抓住應急信息系統這一建設背景，則不僅應急信息系統的建設不能進入有序狀態，標準化建設本身也將擺脫不了滯后于信息系統建設的狀況。（參考《把標準做“實”》）。

參考文獻：

1.

《把標準做“實”》 黃以寬，《信息化建設》2005-1，2

2.

《淺論應急指揮系統的基礎性研究》，黃以寬，第一屆中國政府電子政務論壇交流論文，2004-10