浅谈应急信息系统的功能需求和规划 5900字_第1页
浅谈应急信息系统的功能需求和规划 5900字_第2页
浅谈应急信息系统的功能需求和规划 5900字_第3页
浅谈应急信息系统的功能需求和规划 5900字_第4页
免费预览已结束,剩余1页可下载查看

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

浅谈应急信息系统的功能需求和规划5900字一、前言

经过SARS等一系列公共卫生突发事件后,应急信息系统的建设受到了空前的重视。我国各级政府、各部门都把应急信息系统或应急指挥中心的建设提上了议事日程。示例,北京市公共卫生信息应用系统的建设,就是在以往的经验教训根底上,把应对公共卫生突发事件作为一个主要建设目标;卫生部应急指挥中心向社会公开招标,征集建设计划,等等。在政府推动下,应急信息系统建设已经进入一个顶峰期。

应急信息系统的建设受到全社会范围的重视,这是一件好事。但同时也带来了问题:系统建设的目标到底是什么?多个相关工程如何统筹?怎样处理应急信息系统建设与业务处理系统的关系?应急信息系统的功能边界应该如何划分?等等。对这些问题如果没有一个正确的思路,应急信息系统建设的大规模投入就难以收到应有的社会效益,甚至象以前办公自动化和门户网站一样,变为一场“运动〞。

本文试图对应急信息系统给出一个目标,描述“理想〞情况下的系统模型和需求;在此根底上给出对整个应急信息系统规划的看法。

二、应急信息系统的目标和功能需求分析

应急信息系统的目标,就是配合危机管理的全过程,应用信息技术,实现大面积的、跨专业和部门的信息资源、处理资源和通讯资源的实时调度,使应急指挥过程更加科学化和可视化。

这里用到了一个超越“应急〞的概念——危机管理,我们把支持危机管理作为应急信息系统的目标。这是因为,要最大限度减少各种突发或紧急事件带来的损失,不仅仅要求我们在事件发生后做出迅速、准确的应对和处理,还要求我们在事件前期进行预警和辨识、在后期进行常态恢复。“危机管理〞的三阶段理论更能指导我们运用信息技术对突发或紧急事件全面、全程的支持。

显然,这一目标,不是一个单纯的信息系统可以到达的。它要依赖根底性的网络和多个专业化的应用系统,要依赖多种技术的支持。但是,越是复杂,我们就越应该分析分明,那些是核心、哪些是根底、哪些是锦上添花;哪些应该先建,哪些可以后建。否那么眉毛胡子一把抓,不利于复杂系统的建设和统一的规划。

我们用如下的三层逻辑模型表示应急信息系统及其支持系统的关系。

……

应急信息系统

信息处

理系统

通讯调

度系统

信息

采集

信息

调度

资源

调度

信息

表现

根本网络和通讯系统

辅助

决策

应用支持层

集成应用层

根底设施层

GIS

应急信息系统的三层逻辑模型

各层的关系如下:最高层即是应急信息系统的核心功能,它是一种集成式应用;专业化的信息处理系统和各种相对成熟的技术系统〔如GIS和CallCenter系统〕是构建应急信息系统的撑持性应用,我们称之为应用撑持层;而根本网络和通信系统是以上所有应用的根底。相邻层次之间有着双向的信息供求关系。

我们从对信息的处理角度来分解应急信息系统的功能目标。

任何类型和目的的应急指挥系统,都具有下列功能特性:

1、信息会聚:从应急事件现场或监测网络采集到的各种信息,将被传输到信息会聚点〔应急指挥中心〕。这些信息可能是直接事件现场的视音频信息,也可能是来自传感设备、监控设备的信息或信号,还可能是来自相关的专业化信息处理系统的数字化信息。

2、信息表现:应急信息系统应该有直观而准确的信息表现形式,为指挥员进行指挥调度和辅助决策提供最大的帮忙。GIS是一项广泛使用的技术,可以将危机管理所波及的信息〔如危机态势、应急指挥相关资源分布、应急计划等〕在根底的空间地理图形上形象地表现出来,便于指挥和决策人员直观地进行形式判断、形成决策或进行资源调度;各种信息还可能要借助一定的显示设备和显示控制系统表现出来。

3、信息调度:所有信息在会聚点被组合和集中呈现,供指挥中心的指挥决策人员作为决策和调度依据;有时还要将信息分发下级指挥中心〔或分中心〕的不同的专业化处理系统进行处理,或从这些系统收集处理结果。

4、通讯和物资资源调度:应急指挥最终都表现为通过一定的通讯伎俩,完成一定的人力、物力资源调度。示例警力的调度、救灾物资和设施调度、对事件现场的疏导和部署,等等。

5、辅助分析决策:在应急指挥过程中,提供一些逻辑分析模型、统计模型或预案,以及案例库中的参考案例,帮忙指挥员进行理性决策;同时,应急信息系统还应记录下整个指挥调度的过程,形成完整案例,丰盛案例库,为实现知识化、智能化的危机管理作积累。

以上是一个较为抽象的逻辑功能模型,它有助于我们把握应急信息系统的核心建设目标,合理运用各种技术和各种“物理的〞系统。

三、应急信息系统与其它信息系统的周边关系

1、技术型应用系统与应急信息系统的关系

在应急信息系统建设领域的最大误区,在于信息系统功能需求分析的缺失——从需求的陈说〔实质上是一种需求定义〕直接跳到技术计划,甚至成为技术计划或产品的简单堆砌。以技术计划代替功能需求,这似乎已经成为了一种应急信息系统建设中的普遍现象。

示例,我们经常能在招标书或所谓规划中看到这样的做法:即直接把“数字录音系统〞、“大屏幕显示系统〞、“地理信息系统〞等作为“需求〞本身的内容,对具体的技术实施计划和产品型号进行招标,甚至还有的招标书把“数据库系统〞也作为应急信息系统需求的一部份提出来。这里面短少了对应急信息系统的实质内容和目标的把握,短少了一个理性的论证和分析过程。这样的“需求〞拿出来招标,多半会造成建设的混乱和失控。

并不是说以上的技术系统不能作为应急信息系统的一局部,相反,逻辑的功能最终都会落实为一系列“物理〞的技术子系统。但是我们在进行技术子系统的划分和分包之前,有必要对有机信息系统的“原始〞功能需求作一定义和陈说,为技术计划的展开提供理性的约束,而不会被技术牵着鼻子走。

示例,GIS是一种广泛使用的、成熟的技术,也已经形成相对独立运行的系统。独立运行的GIS甚至可能成为整个应急信息系统中最主要的操作平台。这也是一些工程直接把GIS作为一种“默认〞的“需求〞的原因。但是,应急信息系统是否要采纳GIS,还要看具体的应用领域是否具备了应用GIS的数据条件和环境。而且,即使有必要和有条件使用GIS,也要从整个应急信息系统的总体目标出发进行分析,提出技术应用需求:

第一,要实现应急信息系统与GIS的双向联动。GIS虽然可以独立运行,但在应急信息系统环境下,应该可以实现应急信息系统与GIS的多种联动方式——包括双向的相互驱动和基于数据共享的独立操作,等等;

第二,要实现应急信息系统与GIS的底层整合。GIS系统与应急信息系统应共同遵循一定的数据规范,产生和传递一致的数据;底层应实现数据库共享或公用。

第三,GIS与其他系统的数据整合。GIS的根底数据来自测绘部门,而应急指挥所需的“活〞的应用数据往往来自其他业务部门,如建设、交通、气象、卫生,等等。为让信息系统能够运行起来而“一劳永逸〞地导入数据的做法是不可取的。应该充沛利用这些“活〞的地理数据,建立与数据源进行同步更新的完整机制,贯彻专用属性数据“谁使用、谁负责〞和合理共享的原那么,防止产生新的信息孤岛。

以上是应急信息系统中对GIS的需求分析应该考虑的内容。只有对这些问题都分析分明了,才可能对应急信息系统中GIS的必要性、可行性和技术计划和造价作一正确判断。而这种全局的、客观的、中立的分析,恐怕要在请GIS厂商提供技术计划之前完成。

在应急信息系统领域,类似的成熟技术系统还有CallCenter、知识管理系统、视频会议和视频监控系统等。对这些相对成熟、“自成一体〞的技术应用系统,都要作类似的分析,才能保证最后的应急信息系统是一个有机的、完整的、体现建设初衷的系统,而不是一组不分主次、繁复、独立的技术系统。

无视需求分析或不足正确的需求分析办法,是存在于信息化建设的通病。对于应急信息系统建设而言,这种只有计划,没有需求分析的现象尤其有害。因为应急信息系统的建设几乎成了一种潮流,而且它同时承载着政府危机管理和电子政务信息资源整合的双重重任。不足对需求的分析和规划,会使应急信息系统建设失去理性,导致盲目建设和重复建设,与信息资源整合的精神背道而驰。

2、专业化信息处理系统与应急信息系统的关系

我们对应急信息系统的需求认识往往是始于“混沌〞的。尤其是当因为信息系统缺位造成重大损失的时候,更是希望通过一个工程、甚至一个系统的建设毕其功于一役。但是,应急信息系统的主要目标是实现危机管理中的决策支持,离开了专业领域的知识和专业化的信息处理系统的支持,应急信息系统对科学决策的支持就会落空。另一方面,应急信息系统往往是跨管理部门、跨专业领域的系统,波及多个专业系统。处理这种兼具“宽度〞和“深度〞的复杂需求的合理做法,是把工程进行分解,把应急信息系统建设与专业化信息处理系统进行合理划分。

一般来说,专业化信息系统负责专业化的信息监测和预警、信息处理;应急信息系统那么负责信息的会聚、分析,以及对会商、决策和资源调度的支持;二种系统之间通过共同认可的规范来实现信息传递和工作协同。应急信息系统从专业化信息处理系统中收集预警监测的结果;应急信息系统那么向专业化信息处理系统提交信息加工请求并收集信息处理结果。

检验是否较好划分了专业化信息处理系统和应急信息系统界限的直接方法,是看二者之间是否有足够的独立性。一个好的规划和设计应该是这样的情形:应急信息系统本身不一定很“专业〞,但它能与很专业化的信息处理系统高效地协同工作。应急信息系统的核心价值,在于它对跨专业的、公用资源的调度能力;专业的判断和业务流程应该留给专业化的信息处理系统。从这点上来说,应急信息系统其实需要有一定的“通用性〞。通用性越好,它动态“接入〞不同专业信息系统的能力就越强,整个大系统的“应急〞能力也就越好。

举个例子,若我们针对SARS的预防和控制建设了一个公共卫生应急信息系统,如果它不能百分之八十、九十,甚至更高比例地应用到其它公共卫生突发事件的处理上,则它的规划和需求定义就是失败的。相反,如果我们在进行需求分析的时候,能把专业化事件处理的差别性需求尽可能地体现在“应用支持层〞的专业化信息处理系统中,则无论是作为通用应急指挥平台的公共卫生应急信息系统,还是专业化的传染病管理信息系统、医院管理信息系统、以及各种科研信息系统,等等,都能沿着相对巩固的需求轨迹开展。

四、应急信息系统的规划与规范化

现在我们跳出单个应急信息系统的需求分析,来看看多个系统——或者说整个城市级别的应急信息系统——的需求,或者说一种规划。

根据上面的分析可知,我们如果采用一个相对通用的“应急信息系统〞和一系列专业化信息处理系统,可以构成一个完整的、面向各种突发事件的应急信息系统“两层〞构架。也即从理论上说,可以构建城市级别的唯一的、集中的、公用的应急信息系统平台。但在实际操作中,有两个因素制约这种“两层架构〞模式。一是系统的规模和负载问题;二是现有的行政管理体制的制约。

根据系统论的原理和系统项目实践经验,每个系统下辖的子系统个数是有限的,超出这一限度,不仅系统的业务负载和复杂度会难以承受,为保障系统运行可靠性所付出的代价也会十分巨大。我们通常采用系统分级的方法来解决这一问题。在应急信息系统建设中,就是通过建立一些区域的或“领域〞分中心来分担“总中心〞的负载和复杂性。

但是,采用分中心的“三层〞构架,应该满足两个先决条件。否那么,就有可能使整个城市的应急信息系统更加混乱和难于管理,操作起来无所适从,甚至变成一盘散沙,为信息资源综合增加新的负担。

第一个条件,还是比拟、分析和论证。在具体的城市危机管理环境中采用三层构架,一定要有与两层构架的比照分析。三层系统的优势在于其上的业务操作流程通常可以更好吻合现有管理体制;劣势是分级处理带来了额外的信息分配和汇总的效率开销,甚至为一些导致低效的“门槛〞发明了条件。我们对架构进行分析的结果,应该不仅仅是一个构架的模式,而且有具体的构架实施计划,包括对弱点的分析,以及弥补的办法,作为系统后续建设的前提条件。这是应该在决定建分中心之前完成的。

在实际建设过程中,对于城市应急信息系统的构架模式选择,盲目模仿或是“拍脑袋〞的情况还是很多的。构架的选择往往不是对流程科学性、系统运行效率、系统建设周期和投入、系统的可操作性等因素进行分析比拟的结果,而是避开业务整合的深层困难、对现有管理体制过分迁就和妥协的结果。这对于整个城市的危机管理和信息化建设都是非常不利的。

第二个条件,无论是二层还是三层构架,都离不开规范化根底。统一的数据规范制定应该在应急信息系统的总体规划层面,而不是某个具体的应急信息系统建设的层面来进行。在某个具体应用系统中谈统一规范的意义是十分有限的。即使每个系统都实现了“内部〞的统一规范,也可能导致多个系统之间无法沟通。

对于规范化的认识,也是信息化建设

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论