动态紧急事件响应管理信息系统(DERMIS)的设计

原文:Murray Turoff, Michael Chumer, Bartel van De Walle, Xiang Yao
翻译:宋艳 (Yan Song), 姚翔 (Xiang Yao), 王蒙蒙 (Mengmeng Wang)

Initial Translation : August 4, 2006
Last
Revision : May 14, 2008

Murray Turoff  turoff@njit.edu
Michel Chumer  m.chumer@att.net
Xiang Yao  xiang.yao@gmail.com

Information Systems Department
College of Computing Sciences
New Jersey Institute of Technology

Bartel Van de Walle bartel@uvt.nl

Information Systems and Management Department  
Tilburg University
The Netherlands

Yan Song songyan@hrbeu.edu.cn 
School of Economics and Management
Harbin Engineering University

Mengmeng Wang  wang2@stevens.edu 
School of Technology Management
Stevens Institute of Technology

 

 

摘要:

本文通过对设计前提的总结和对设计概念的定义,系统地阐述了一套用于支持“动态紧急事件响应管理信息系统”(DERMIS )设计的通用原则和注意事项。设计前提源于对“紧急事件响应管理信息系统与参考索引”(EMISARI)的应用,设计概念则来自对以往相关文献的全面调查研究。危机事件,不论大小,都暗含对通信与信息的需求,这正是现代信息与通信技术可提供帮助的领域。现在的当务之急是将这些前提及概念整理成一套通用的设计原则,并在此基础上提供一个构架用以开发紧急响应信息系统。

本文提出的构架将有助于设计和开发既满足第一时间响应人员的通信与信息需求,也满足指挥及控制人员的决策制定需求的系统。该构架同时兼顾分散于各地的专家的见解与信息的价值,考虑了如何引入专业知识来支持危机决策。基于历史经验,本文提出九条设计前提,并辅以五项从以往相关研究中总结出来的设计概念。在此基础之上,本文提出八项通用设计原则及三项注意事项,并建议将它们融入到DERMIS详细说明书的编写中。最终的DERMIS设计模型用图表表述了本文所提及的经验,它预见应用这些设计原则和注意事项的结果将会得到一个足够灵活、可靠、动态的紧急响应系统,用以支持各层次紧急事件和危机响应人员对于通信与信息的需要。另外,该模型还可用于开发动态紧急事件响应管理信息系统,通过可适灵活性来支持和整合不同规模和类型的组织。

本文为系统分析员和设计者、系统工程师、第一响应者、专家团体、紧急指挥和控制人员,和MIS/IT研究人员提供了指导方针。

本文贡献:

这是一篇在紧急响应管理信息系统专门应用领域建立基准的论文。主要写给以下三类读者:

·      从业者:有关这些系统设计的

·      用户与管理者:有关这些系统开发与使用的

·      研究人员:感兴趣于紧急响应信息系统领域的进一步研究的

本文的首位目标是在以上群体中触发专业知识交流,以期产生新一代信息系统。

本文贡献为以下5个方面:

1. 收集此领域有关需求分析的多种文献,试图从已被今天遗忘的早期文献和经验中,复原已有的重要发现。

2. 阐述了一套紧急响应系统的设计需求。

3. 表述了基于上述需求的概念设计。

4.强调了一个单独整体化企业类型系统的需要,这里绑定了紧急响应的所有功能,从规划,经过执行和恢复,直到培训。

5.指出我们的研究机会与以下方面相关:

·      智能系统需求

·      协作知识库

·      虚拟指挥与控制中心

·      信息过滤的人性化

·      此环境下应用PDA的界面设计挑战

·      仿真,游戏需求,培训机会

1. 绪论

911”以来,涌现出大量提高紧急事件响应能力的探索。然而,绝大部分努力仍集中于通过改进基本设施来减轻人为或自然灾害带来的影响。在用于灾难响应的通信及信息系统领域,绝大多数的努力则集中于通过基础技术的改进来可靠地保障网络与物理设施的生存能力 Kunreuther and LernerLam 2002; Mork 2002)。“911”事件中,基础技术严重受损及指挥中心完全丧失长达48小时的事实,使之成为一个可以理解的结果。此后,商业企业立即为紧急事件响应人员提供了有效运作的商业寻呼和数字邮件系统 Michaels 2001; Vatis 2002),这说明,基础技术的修正在很大程度上来说是一个建立整合标准的过程和下决心为更新陈旧系统进行必要投资。

911”事件真正体现出的是一个战略和技术失误,即要求不匹配系统(比如消防,警察,医疗)的通信整合依赖于单一物理集中之指挥控制中心。这样的指挥中心容易因蓄意破坏而受损。如果 911”事件能够带来任何强有力的技术结论的话,那就是需要开发一种集成通信能力,可以作为一个分布式虚拟系统来响应,从而不需要相关人员必须集中在同一地点(Smith and Hayne 1991)。这样的虚拟指挥中心的建立要求把责任机构、决策与汇报职责、职权追踪、监督管理功能明确地体现在用以建立人际网络的通信支持软件中。事实上,涉及到的响应人员应该能够在任何地方开展工作,不管危机事件发生时他们身在何处。这就是本文基本的技术目标假设,也是文中将讨论的需求的基本目标之一。

本文主要关心的是用于支持规划和执行紧急事件响应管理功能的人员的软件的功能需求

近来少有讨论紧急状况的第一响应者所需要的特殊功能需求的文章发表。同时,我们也注意到“911”之前的大量紧急事件响应文献所关注的商业企业对紧急事件或者危机事件的响应,主要限于本企业内环境(Barton and Hardigree 1995; Braverman 2003; Kim 1998; Lukaszewski 1987; Massey 2001; Mork 2002; Pearson, Misra, Clair, and Mitroff 1997; Smart and Vertinsky 1977 1984),或者危机事件的公共关系层面(Coombs 2000; Dyer 1995)。当涉及某个组织的紧急事件具有宏观社会影响并对公民或者公共设施造成了潜在的或现实的物理危害的时候,它通常会超越该单一组织的掌控,并将会根据其涉及的范围和性质,演化成当地、本州或联邦政府的关注焦点(e.g. Bhopal, Three Mile Island, Tylenol, and Exxon Valdez)。另外,本领域已积累了大量的可以应用于不同组织危机情况的重要观察发现。

功能需求的一个重要来源是紧急事件预备署(OEP)过去的运作及其他方面的经验,这个机构到1973年已经有25年的历史,它先于新的国土安全部,是当时唯一的负责紧急事物处理的公共管理机构,它通过总统颁布命令承担危机事件或者灾难情型的总控任务,对其他联邦机构,包括军队,行使指挥和控制职能。本文的余下部分首先集中于总结OEP提供的经验和考察其他讨论危机事件响应人员所需功能的文献。然后,本文为整合的动态紧急事件响应管理信息系统(DERMIS)开发了概要设计。既往的大量的从紧急事件响应中获取的经验知识,应当在紧急事件响应系统的功能需求设计中得到反映。


1   DERMIS设计模型 3-6节)

设计前提(第3节)

1. 系统训练与仿真

2. 信息焦点

3. 危机记忆

4. 例外既常规

5. 危机事件的范围与本质

6. 角色转换能力

7. 信息的有效性与及时性

8. 信息的自由交换

9. 协作

通用设计原则及细则(第5节)

1. 系统目录

2. 信息来源与及时性

3. 开放的多向通信

4. 用内容作地址

5. 最新的信息与数据

6. 链接相关的信息与数据

7. 职能、职责与责任

8. 心理与社会需求

概要设计(第4节)

1. 比喻

2. 人员角色

3. 通知

4. 上下文可视性

5. 超文本

设计注意事项及细则(第6节)

1. 资源数据库与团体协作

2. 集体记忆

3. 在线专家团体

 

1DERMIS设计模型)给出了本文的进程:从设计前提(第3节)和概要设计(第4节),到通用设计原则及细则(第5部分)和设计注意事项及细则(第6部分)。本文的一个目标就是发展这些智慧及其联系,并在此基础上将它们转化为依靠现有技术可行的设计需求。

 

2. 来自EMISARI的历史领悟

OEP期间,它主要的资源之一就是大规模的由企业界和学术界的专家组成的顾问网络。他们能够帮助OEP发现应急计划中的隐患以及尚未得到充分保护的的弱点。同时他们熟悉关键工业,例如能源、通信或者重要物资(汽油、石油、氯气,铁合金等等)。

1970年,一个计算机德尔菲系统的原型被开发并证实由25人组成的团体可以通过计算机网络展开协作德尔菲过程。德尔菲过程(Linstone and Turoff 1975)原本是设计成使用纸和笔,通过反复的结构化问卷调查,从而允许由分散在各处的专家组成的大型专家团体(15500人)对复杂问题进行知识和观点交换。现在,德尔菲通信结构也可通过互联网进行(Cho and Toroff 2003; Turoff and Hiltz 1995; Wang Li, Turoff, and Hiltz 2003)。OEP曾计划安装该系统,以便更好的利用一千名左右与OEP相联系的专业志愿顾问。1971年,OEP负责处理了一项新的紧急事件,工资价格冻结,即冻结所有工资和价格变更。对涉及既定合同的也不例外。OEP的职责是监测全国范围内的执行情况,审查并裁定免责请求。一周之内,该德尔菲系统得以调整,成为了处理工资价格冻结危机的“紧急事件管理信息系统与参考检索(EMISARI)”。选用该名字,意在向全国数以百计的相关工作人员传递一种感觉,即这个系统和OEP正在提供他们所需的帮助。

OEP之前没有既定的处理工资价格冻结的计划,但由于EMISARI系统被设计为可将人员和数据集中到单一数据库的通信系统,并允许非技术管理人员动态地调整所有对象(人员和数据),其结果是EMISARI成为唯一一个能够跟进工资价格冻结处理程序和流程演变过程的系统。EMISARI系统被设计为通信系统(不包含特定内容),设计上不与工资价格危机或其他任何危机类型挂钩,因此,它可以应用于任何危机种类。他的设计侧重于工作组通信过程(Hiltz and Turoff 1978,1993; Lewin 1958; Ruben 1992; Turoff 1993),以及在时间急迫状态下人们如何集中、贡献和使用数据。

EMISARI提供动态调整能力,可对人员,对象,各种数据、信息、讨论和行动项目的进行裁剪,以适应必要的模板,也可随时对模板本身的进行修改。这些模板被系统管理员分配给系统成员(联系人),系统管理员可以是不需要任何技术培训的管理人员。大约1/3的软件用于使操作更简单易用。例如,创建模板和象专业接线员一样,把用户连接到模板预先定义好的功能。即使单一数据项目也有全面文本描述,使用户通过内容描述就可以搜索他们所需。数据和其他功能模板可以被管理员在很短时间内创建和分派。最后,内部标志允许用户自己在系统中重新配置当前信息,为特定形势定制动态报告。最后这项功能的实现是通过使用简便易用的超文本(类似互联网的链接)来连接已有的数据或文本模板。当这些带有链接的报告被检索的时候,总可以获取并结合已定义模板的最近更新(Hiltz and Turoff 1978,1993)。EMISARI是一个高度结构化的工作组通信过程,遵照德尔菲方法的基本概念(Linstone and Turoff, 1975)。它同时内置计算机会议功能和可用于延时或即时通信的消息系统(Turoff 1971, 1972)。

1973年以后,EMISARI继续(在国家年收入服务-IRS和通用服务管理-GSA被使用了15年多,用于运输业罢工、煤炭业罢工,石油短缺,氯气短缺,天然气短缺,以及其他一些更为严重的自然灾害(Macon and McKendree 1974,1975; McKendree 1977,1978)。对经历过一系列灾难的组织,其经验知识或者隐形知识的积累,通常无法被这些组织显性地获取并保留下来,理由我们将在后面讨论。然而,自然灾害对于发展组织记忆和作为“组织自省的契机”,还是有价值的(Weick 1993,1995)。从这个意义上说,EMISARI已纳入了许多今天被称为知识系统的特征(Bieber et al. 2002)。

基于20世纪70年代的技术,EMISARI可以支持2-3百个遍布全国的用户作为一个小组对危机事件的进行协作响应。这些年来,关于EMISARI的著述陆续被发表在专业文献中(Hiltz and Muroff, 1978, 1993; Kupperman and Wilcox 1972; Kupperma, Wilcox and Smith 1975; Price 1975; Renner, et al. 1972; Rice, 1987, 1990; Toroff, 1971, 1972, 2002, Wilcox and Kupperman 1972)。

 

3. OEP的紧急事件响应氛围

隶属于总统执行办公室的紧急事件应对署(OEP),最初是由二战时期的特别事务署(OSS)的职能发展而来。OEP是独立的民间机构,当联邦紧急事件被宣布时,它有权指挥和控制联邦资源(包括军队)。当联邦紧急事件发生时,它还可以对紧急状态涉及的企业进行管制和采取必要行动。这通常出现在如下领域,比如运输工人罢工,日用品短缺,自然灾害或人为灾害。OEP的任务就是评估威胁,制定,并在必须的时候执行应对方案。它有责任确保政府在任何紧急事件发生时都能够有效地行使职能。实践中,它是总统层面的一个独立机构,用以保证企业、联邦、州和当地政府各部分处理紧急事件的问题会引起重视并得到处理。

1973年,OEP被解散,它的原有各项职能,或者被转移到其他政府机构,或者被从国民政府中去除。若干年之后,FEMA(联邦紧急事件管理署)作为统一机构诞生了,但在联邦灾难基金管理方面,它很大程度上仅扮演反应性角色。而在威胁评估、政府范围的响应计划整合、以及最重要的紧急情形下的集中命令与指挥方面,它却没有明显的功能。然而,集中权利并不意味着那些负责采取行动和制定决策的人就必须在同一个地点或者同属于一个组织。如同在军事行动中一样,在处理紧急事件时,中央权利机构可以授权给直接响应人员去制定决策。

OEP曾经拥有的一个显著优势就是在具体的危机事件中,它能够征募任何联邦雇员,只要它认为危机响应团队需要。这意味着在任何情形下,原则上讲,它都能组成尽可能好的团队。大多数时候,在人才需求方面,这是一个快速协商的过程,OEP很少需要做人事调整。

OEP的运营过程中积累了大量的经验和智慧。一些二战期间OSS的高级社会工作者和顾问,还帮助建立了该机构运转的特征和氛围(Hiltz and Turoff 1978; Kupperman and Wilcox 1972)。

关于信息系统,尤其那些系统的指挥和控制的部分,我们试图用以下这组设计前提来阐述OEP的哲学思想。

前提1    系统培训与模拟:在紧急事件发生前不能用于处理常规事务的紧急系统,将永远不会被真正的紧急事件使用。

这不仅仅是培训的问题,而是发掘出紧急事件系统能够执行的日常功能,这样就不需要在危机发生的时候还要培训如何使用系统。任何一种需要建立团队来应对周围环境的意外情况,都提供了这样的培训机会。尽管许多组织不愿意承认这些事件的存在,它们似乎发生得还相当频繁。除此以外唯一可能的培训方式就是快速学徒制了,即坐在某个知道如何在危机中响应和如何使用现有设施的人的旁边观摩学习。我们在60年代末建立一个非常简单的支持多种选择的计算机辅助指令系统(CAI),它能够对特定状况提供情景描述,并提示一系列在危机响应环境下可能的备用行动。系统中总有“其他”选项。OEP中的高级和初级成员都可以使用该选项,如果他们感到某些未被提及的情形可能提供新的情景,他们可以选择“其他”选项来解释那些情形。这个非常简单的功能允许响应者交换他们的经验和知识。那时,我们把这看作是附加在CAI系统上的如此简单的一个的通信特征,以至于关于这个特征我们从没有发表过文章;而现在人们会认识到CAI实际就是一个基本的集中式记忆系统。举个例子,销售人员可以用同样的方法来交流经验。对于自然灾害而言,即使是同样类型,它们在相似环境下的具体情形可能千差万别。没有一个人的经验会与别人精确地一致,哪怕这些经验来自于同一个的灾难事件。

商业和政府组织中的确存在许多事件可以被称做是“微型紧急事件”,例如罢工,法院诉讼,成本超支,交付延期,事故,新规则,供应短缺,自然灾害,预算不足,生产延期,产品或者服务故障,合约谈判,重要员工流失,重要客户流失,设计或响应RFP(建议请求书),竞争行为,等等。基于我们正在考虑的紧急事件响应系统的定义,上述所有各种事件都可“服务于日常训练”。事实上,CAI是一个理想的供大型、分散、异步的(例如虚拟的)项目团队使用的系统。

先前的美东北停电事件之后,美东北的电力设施安装了一个紧急事件专用电话系统,用以协调行动和预防此类事件的再度发生。2003年,美东北再度大面积停电,在这一事件中,从最初两条俄亥俄州的主要电力线路出现故障,到纽约地区电力崩溃的最后90秒之间,有超过一小时的时间差。可是直到电力崩溃最终横扫美东北以后,该电话系统才被启用。人们怀疑这是一个在两个灾难之间没有被经常使用的系统的案例。

另外,在技术普及期间,已有的用户社区是对帮助新用户和不期而至用户了解技术起关键作用的支柱。这样的用户在现实危机事件中比比皆是。应对危机包括复杂的操作,涉及必要领域的相关专家,因此,“易学”取代“易用”成为主要设计目标。复杂的应用环境要求为应对这样环境而设计的系统必须提供与之相适应的灵活性。

前提2    信息焦点:紧急事件的响应人员每天工作14-18小时,他们对与处理危机无关的事情没有任何耐心或时间。

这个前提对于如何设计支撑系统,如何重新考量预防信息过载的过滤器的特性,以及如何制定获取相关信息的搜索过程有显著影响。身处危机前线的响应人员(物理地或者虚拟地)没有时间读报纸、听电台、看电视或接电话,当他们还未清楚做这些事确有必要之前。身处紧急情况之下,他们必须能够获得围绕着当前情况的全部的相关信息,作为他们正在使用系统的整体流程的一部分。这也意味着在此之前,没有人能够精确地预测他们会对什么感兴趣。

同时,这也意味着,那些在系统中承担角色的个体,需要有途径获取与正在发生的危机事件相关的全部信息;我们不能假定信息流能被限定,根据“威胁僵化症”(Rice 1990)的行为假设,这在危机响应情况下确实会发生。在缺乏必要信息或协作状态的压力之下,人们通常依赖于执行公式化的响应计划,而它们对于给定的情形,可能全然不恰当。危机中不同地点正在发生的情况,可能会影响响应者采取何种行动的决策。

前提3    危机记忆:学习和理解危机前、危机中和危机后发生的实际情况,对改善响应过程是极其重要的。

在危机环境中收集的响应者和系统表现的信息,应该被结合到系统的设计当中去,而不是亡羊补牢。系统应当被设计成能够根据使用中新的理解不断发展和完善(Keen 1980; Zuboff 1988)。另外,在不给使用者增加额外负担的情况下,记录发生的紧急事件的历史,是设计目标的一个关键部分。这个设计目标涉及下一项的观察结果。

前提 4    例外即常规:几乎每一件危机中发生的事都是常规的例外情况。

在危机环境中,指挥与控制层没法精确预测谁将做什么,何时做,为何做,和/或如何做。危机促使那些在现场必须立刻采取行动的人做出更多的决策。当上层下放权利时,他们期待接受授权的人会为此负责,这样他们才能对资源和其他需要整体考虑的的要素之间的冲突进行统筹监督。问题的解决方案和资源的重新分配是持续的不可预测的过程。比如,当急诊医生滞留现场,而不是随救护车返回时,这就对救护车资源整体,一个可以被派往其他地方的满配医疗单元,制造了使用上的限制。特定个体关心和感兴趣的具体数据和信息是快速变化着的。

考虑不同于既定计划的响应方案是决定每时每刻行动的关键要素。在处理危机情形时,任何事先未被考虑到但发生的事情,是给处理流程中各级别响应者带来问题的关键因素。危机响应系统是一个整合了通信和数据系统的人的信息系统,他们的智慧、关注、切身问题、采取的行动、计划的行动、状况信息、结果信息都是构成其底层数据库和数据结构的一部分。数据处理不能从通信处理或人的处理中分离出来,人的处理是与数据和通信处理过程共存的。

这意味着在危机响应过程中的任何时刻,最终用户都必须能够动态地对系统的交互性、优先级、过滤器及信息发送选项进行调整。这也意味着系统必须动态地跟踪这些变化,并让其他需要了解这些变化的人获得最新信息。

前提5    危机的范围和本质:当前的关键问题是了解危机的本质,其关键是需要把人、权、物在特定时间内为特定目的集中到一起。

危机响应团队是一个真实而虚拟的专家社区,彼此必须能够不受限制地沟通并像一个集体一样行动(Hardeman, Pauwels, Palma, and Van de Walle 1998; Weick 1993,1995)。在处理某个具体问题时,由具备合适才干和背景的人组成的子团队要能够随时成立并行动。当团队成员在响应过程中受损,或者被迫重新分配他们的注意力,或者精疲力尽时,这个系统必须支持工作的持续性和个体的即时替换,这也就谈到下列两个必要性:训练响应者在危机情形下承担多种角色的必要性,和应付大范围长时间危机的足够人力的必要性 Danowski and Swift 1985)。

前提6    角色转换能力:在危机情况下预测谁会承担什么角色是不可能的。角色的行为和权利需要在系统的软件中很好地定义。人们必须为可能承担的多重不同角色进行培训。

知道谁在需要时就位,是必须被确认和作为灾难响应的关键要素及指挥控制的关键需求的。知道哪些与问题相关的数据是最新的,来源何处,正确程度或数据状态如何,跟数据本身一样重要。诸如角色,责任,明确的数据和角色的状态变量(比如优先级、准确性、信息源、行动、兴趣、担忧等等)这样的概念,需要成为支撑操作的协作数据库的组成部分。

前提7    信息有效性和实时性:通过提供尽量及时的信息,在制定决决策时建立和保持信心,对于那些冒着失去物资和生命危险采取行动的人而言,是至关重要的。

紧急响应系统必须能够精炼数据和信息,使得数据资源集中于对决策起关键作用的方面。系统必须允许在不同级别的解释人员和行动人员之间的间接的和隐性的通信渠道。例如,工资价格冻结事件发生期间,OEP系统记录了未被成功找到的关键字,这些被查询的关键字在各种文件,如政策解释文件,中都没有找到。那些没有被找到的关键字列表,被呈报给政策委员会的周例会,用以审查政策解释需要和确定会议议题。这是一个该系统在一线人员和政策制定委员会之见提供间接通信渠道的例子。一线人员不必浪费时间为此做专门的交流。危机中采取的行动总是基于不完全信息的,因此我们必须尝试每个努力来获取可以得到的信息,并将它们保存在统一的共享式数据库结构中。该数据库结构可能需要根据输入数据的性质和结构进行意想不到的调整。

从通信流和数据流中抽取线索建立间接通信,为知识获取系统提供了有效的输入方法(Hiltz and Turoff 1978; Wieck 1995)。在紧急状况的恢复阶段或当面临长时间的紧急状态时,通常有必要成立重要政策委员会,这样有可能引起在不同机构或者政府不同实体之间的明显的不同观点。另外,还可能需要在更高层次成立快速反应委员会,它们负责处理和应对可能的资源短缺,或者负责整合外部智慧使之成为危机响应行动的一部分。

前提8    信息的自由交换:危机要求成百上千来自不同组织的个体,能够自由地交换信息、下放权利、行使监督,而免于信息过载的负面影响。

所有事件相关人的响应一致性被认为是主要的需求。响应一致性的问题源于“专业宽度理论”(Massey 2001)。一个组织在某环境范围内或是专家,或是全才,专家组织在制定战略战术时,往往更局限和具体。尽管专家机构通常在他们的专业领域拥有更准确的知识,往往是全才机构更能影响政策制定。这一发现适用于许多危机事件涉及的组织和机构。一个很好的例子就是,FBI是一个全才机构,而疾病控制中心则是一个专家机构。这两个机构在瘫疽病紧急事件中的不同反应,就是危机形势下典型的协调问题的例证。每个机构在运作时都有关于其真实使命的不同假设,由于缺乏明确的权利机构的快速仲裁,会导致过错及政策中公开的不一致性,并因此破坏公众对政府作为的信任。为了避免疾病的进一步蔓延,疾控中心希望公众了解正在发生的所有细节。然而FBI并不想让那些传播疾病的人知道某些信息,因为那样会妨碍他们抓住嫌犯。在提交给国会的有关成立新的国土安全部的说明中,多次提及危机事件涉及的众多机构之间的协调问题。这个挑战被Hale1997, p.5 of 15)阐述得非常清楚:

高效危机响应的主要障碍是通信,用于获取相关数据或者专业知识的,并将其拼接成反映现实的正确的、可理解的画面的通信。

当面对极度不确定的状况时,决策者往往会加强对信息的搜索 –– 经常是为了象征性的目的,并采用自我满足方式 –– 与此同时,他们会关闭某些通信渠道,而依赖熟悉的或正式的信息和途径 Rice 1987)。另外,当信息过载(Hiltz and Turoff, 1985)发生时,工作小组倾向于限制自身的信息处理,而将控制权沿命令链向上转移,仅给较低层次保留很少的灵活性。高不确定性和信息过载对可靠的灾难响应有非常大的危害。幸运的是,对大多数危机情况,在响应的本地和具体事件层面,我们并不必担心语义的模糊性会引起数据恶化问题。在负责监控和资源分配的更高的响应层面,可能会存在大量的不确定性和相关的语义模糊性。然而,由于语言和通信系统的使用而带来的模糊性,可以通过系统设计和使用培训使之最小化。

只要响应者接受过所承担角色的职责培训,并且在核心的形势报告员和决策制定者之间,曾有过相互沟通的历史,就应该不会存在显著的语义模糊性问题。而且,如果通信系统是基于计算机的,我们就会有更强的能力,为那些还未接受充分训练就被投入到危机情况中的人,提供快速学习的辅助工具。如果系统知道他们是谁,就有可能为他们提供更多的反馈,诸如别人将会如何理解他们的用词、请求和行动。系统也将促成学徒制度的建立,通过为“新兵”配备教练,对新手的所有通信进行实时监控。

911”事件中许多第一响应者的死亡,很大程度上归咎于因通信丧失而造成的上述情况之组合。由于无法知道何事正在发生,因现场指挥和控制中心损失而造成的协调不足,以及周遭的直接刺激所造成的信息过载,第一响应者中很多人遵循了他们被教导过的规则,却未对这些规则进行再考察。其结果是,我们有了“威胁-僵化”假设的一个悲惨案例。

前提9    协调:对大型危机响应团体而言,协调问题的关键是无法预先确定个体的精确行为和责任。

正如我们即将看到的,这是每个危机情况独特性的结果,是在这种独特性基础之上的即兴响应需要的结果,是对于隐性信息依赖的结果,以及决策过程时间关键性特征的结果。

另外,在处理危机事件时,与商业企业相比,政府存在一定的劣势。他们无法轻易地掩盖所发生的事件,这反过来这就导致了政府机构特有的4个要素(Horseley and Barker 2002):

1.危机会引发政府无能的疑问;

2.危机期间政府行为的频率不保证它们总是有效的或者有利的。

3.政治能把危机事件从“决策场合”演变成“权利关系重构场合”。

4.危机中被调遣的军方和民方组织,在极度关键的情况下可能会暴露出致命弱点,尤其是出乎他们预料或者没有计划到的情况。

理论上,正是由于政府机构更容易控制和限制信息,他们不大会象企业那样被欺骗。

处理不可预见事件的新方法随着危机事件的性质变化而发展。决策制定者必须确信任何与决策相关的东西都能及时被找到,但同时他们也需要了解,正因为这是危机事件,那些被认为是最相关的信息可能根本不存在。人是能够处理高度不确定性并做出及时决策的(例如抽取线索),只要他们知道不确定性不是源于未公开信息,并由此使得他们此后的的行动变成错误。可是向低层提供所有相关信息,并不总是政府组织的态度。

决策权在危机情况下被下放到第一线。然而,状态信息和职责数据必须对等地向上和横向传递。事实上,团队的职责也同等重要(King 2002)。角色附带相应的行动决策权,不同角色聚合在一起便构成处理特定相关事件的临时团队,因此也就带来了团队的职责。这暗含了很多紧急事件响应系统的功能性要求。例如,它暗示这种系统的数据和操作必须能够被人清晰地识别,这些人可能正在献计献策、制定计划、发表观点、提供数据,并且/或者正在执行操作。

上世纪670年代出现了大量的学术探索,以解释危机情况下个体和组织的行为。有一篇出色的报告(Dynes and Quarantell 1977)把大量相关的研究编辑成一份独立文档。在总结之处,该报告提到 Page 26):

基于此处描述的内容,以规范化计划模型为主导,强调基于计划的协调,最好来说,也是可疑的。危机事件自身会产生的某些状态,使得这种协调不再合适。然而,这种不合适却不大可能被灾后有关组织功能的评论所挑战,因为其采用的是基于反馈的协调。通信的增加通常被当作协调失败的结果,而不是必要条件。但是,紧急预案计划,也能够被指导用来改进和支持基于反馈的协调,因为这种协调方式很可能成为紧急条件下的主导模式,而不是混乱的超常情况。

基于计划的协调的极端情况,是对于前线人员的完全外部控制。而基于反馈的协调则假定处于危机前线的人员内部拥有控制权。OEPEMISARI系统的实质就是一种专门为基于反馈的协调设计的系统,这种运作模式也是以下被提议设计的本质。

拒绝承认危机的现实性,即权利下放和快速响应的需求,经常导致不充分的系统设计,无法以及时的和有效的方式完成监督功能。因为许多严肃的决策都是不可逆的(Pauwels, Van de Walle, Hardeman and Soudan 2000),这可能会导致无法挽回的错误决策,或者在决策时造成延迟,从而丧失了找到更优方案的时机。

如果将上述危机事件性质看作是系统设计的假设,很清楚,紧急事件响应信息系统必须被看作是结构化的工作组通信系统。该系统除了提供通信协议和结构,并不包含具体危机的任何内容,除了集中了外部数据库和其他信息源的电子图书馆之外。其他人也赞成,依赖于计算机的群族通信,对于解决需要很多人输入的复杂问题,可能是的最恰当的媒体。(McKendree 1978; Price 1975)。

有关危机通信挑战的最近一次考察突出了一些相同的性质(Horseley and Barker 2002):

·         信息过载很典型;

·         不同类型的群体和个人必须协调他们的行动;

·         人们必须一起工作,尽管正常情况下不是这样;

·         无法精确地预测,在危机时刻或在响应序列的某给定时刻,谁可用并参与;并且

·         在处理许多危机事件中,社区和公共通信是极其重要的。

 

4. 紧急事件响应的需求和概要设计说明

上述9个前提以及到目前为止到所讨论的在其之下的目标和需求,跨越了所有类型的危机和紧急情况。我们需要的是不对具体灾难种类有任何假定的系统,不管它是火灾、炸弹、有害物质、交通阻断,或是其他。正是因为不需依赖于特定内容,一旦使用者经过培训和经验积累,能够熟练使用,这样的紧急响应系统就能成为可以应用在任何紧急情况下强有力的工具。可能有支持数据库包含内容信息,比如,用于特定危机类型的特定资源的位置和可用性信息,或者有关诸如有害物质等事物的信息和知识。那些数据库资源可能在任何地方,所需要的仅仅是当地响应者知道它们存在,并且知道在必要情况下如何使用。然而,执行响应并允许相关人员协调和执行各层面的指挥控制的系统,一定要是一个为紧急响应任务量身定做的通信系统。幸运的是,在所有危机形势下,都存在协调过程的通信通用性,我们能够根据它来设计必要的结构。

我们主要关心的是一个紧急响应管理信息系统的设计,该系统将直接支持当地危机响应者,并提供涵盖所有相关团体和机构的协调结构。我们也假定存在通信网络和计算技术,支持由个人计算机、服务器,便携式电脑,掌上电脑,移动电话和无线通信组成的可靠的网络。我们关注的是支持软件和其必备的功能。目前的巨大挑战是,这些功能既要能适应PDA的小屏幕,也要能在台式机和笔记本的更大的屏幕上使用。尽管多模式人机界面,例如增加语音输入输出(让手得到解放可以执行其他任务) ,是令人满意和有用的,它并不会得到明确的关注,除非PDA有限的图形化能力,使得为双手都要从事响应工作的人增加语音输入输出作为替代的交互模式,确实变得非常关键 Pyush et al., 2002)。记录情况报告细节的能力也需要具备传递有用的情感内容的能力,来表达诸如严肃、紧迫、确信等感情。将声音流和情感图标合并到任何文本位置的能力,以及对图形、颜色的要求,也是系统明显的假设。由此得出的系统基本需求就是:

  • 通过培训和练习极其容易掌握,因为系统与任务需求是一致的;
  • 方便对在紧急环境中的角色和责任有理解的人使用;
  • 注重简单自明的设计,满足小屏幕和学习最小化的要求;
  • 允许个体用户对人机界面拥有高度的裁剪、筛选以及聚焦的能力,使之符合他们特定的角色和职责;
  • 在危机事件之间,支持计划、评价、培训、练习和系统更新与维护;
  • 响应功能的运作不需要依赖单独的物理的运行指挥中心,为支持响应运作而对服务器和分布式资源数据库等计算机软硬件进行的操作和备份除外;
  • 将被设计成结构化的通信过程,不依赖于特定危机事件的性质。

为达到上述目标,我们将专注于五项明确的群组通信系统界面设计标准,他们使系统极其适合紧急响应环境。他们是比喻,角色,通告,上下文可视性和超文本。

1.比喻:一个系统的比喻是该系统的思维模型,依靠它,用户能够很容易地学习该系统并建立认知地图,从而使理解该系统变得更加容易。比喻让用户能将任务目标翻译成实现目标的界面操作。这类比喻,有时被称作边界对象,可以让用户形成信息系统的 “路线图”或模型,(Star 1989)。

2.角色:将人的角色概念内置于群组通信软件系统中 Turoff 1993),由特定的权限和工具支持角色所能执行的操作。

3.通告:通告是向用户提出的有关状态、数据、和/或用户关注信息发生变化的相关警示,外部事件和/或其他用户的行动会造成这些变化(Turoff 1993)。

4.上下文可视性:上下文可视性指的是把有用的数据元素的组成部分,通过与用户理解有关的背景环境表现出来。通过用户对特殊数据元素的选择,系统能即时推断出用户想做什么。而当用户不确定需要什么数据或者想要改变选择时,他们需要能够在子菜单中获取所有可能的选择。这就产生了一个符合常识的对象界面,它使选择变得不言自明,并可以根据具体用户进行调整。

5.超文本:按照超文本的最初概念(Nelson 1965),通过带有语义内涵的多重双向链接,使得人们可以把系统内容中的任意部分变成一组选项菜单,去链接其他内容或界面上的其他功能。

通过将以上五个概念捆绑到一起,我们能够假定一些非常具体的自明式紧急响应管理信息系统的设计需求。

4.1 比喻

在一篇关于比喻的奠基文章中,比喻被描绘成:它不仅对用户培训有用,正确的比喻还能为系统设计,人机界面,及系统需求建立标准。没有任何其他的环境,能比紧急响应给这个概念以更好的注释。有一个概念或数据结构能够被所有处理危机管理和响应的人所理解:那就是记录危机过程的“事件日志”。它是在危机发生后,分析已发生事件的主要数据结构概念(Hale 1997)。那些参与到危机处理中去的,和那些事后试图去理解真相的人,通常都会用到某种事件日志。事件日志是我们介绍的设计的一个基础比喻。

不要让日志变成马后炮般的事后报告,我们可以把它变成紧急事件的动态演进记录。每个个体响应者都应能得到全部日志不同层次的总结。在最高层次,应当仅保留根或触发事件,它们来自外部环境,引发相应的处理反应行为。当点击其中任何一个事件时,就会打开该事件的子日志。事件的子日志是相关信息的集合,用来记载该事件,该事件的响应,以及被记录的行动所使用的资源。点击日志中的任何实体,将获取所有相关链接指向各种形式的相关信息。日志是紧急情况的发展线路图,通过它可以得到所有后续事件的发展路径。用户能迅速地去到他们所关心的任意方向。响应者可以对他们需要追踪的事件做标记,以开展他们的角色和责任。被标记事件引起的任何行动,都将被传递给该用户。

为达到上述目标,系统需要允许用户为一整套日志建立模板。随着时间推移,条件变化,单个用户也可以建立独立的根日志,它包括相关事件日志的完整序列。一个根/父日志和它的可能的分枝/子日志的典型例子是:

请求资源根事件日志(位置、情况)

- 分配 (或者拒绝、延迟、部分分配) 资源

- 触发“资源维护”,生成一个新的根事件

- 正运往目的地的资源

- 资源到达指定位置

- 资源条件的状态改变

- 环境条件的状态改变

- 重用当前事件来定义更多的同类事件

- 未完成的资源再分派

- 此资源的原始根事件交易已完成

- 正运往平常位置的资源

例如,以上序列或者日志模板可能用于医疗单元,一般来说,它由一辆救护车、一名司机、一名急救护理人员和包括油料在内的各种给养组成。然而,任何给定的单元可能有所不同(比如,有的单元有医生)。另外,在整个事件过程中,急救护理人员或医生都可能留在原地,而不随救护车运送病人返回。当由于唯可用一的救护车,需要先加油,才能出发去满足最初的调遣要求时,延迟的响应就有可能发生。

911期间,事先的计划并不包括用渡船作为救护车,运送病人到泽西市建起的紧急室外医疗区域。可能有一类事件需要保持通用性,使得某些概念,如医疗单元,才能够被动态地重新定义,这样才能满足特殊资源请求事件的要求。这种情况下,新的医疗单元类型可能只有在危机其间才会在资源数据库中建立。是结构和过程组成了软件,而不是内容。用这种方式,系统就可以适用于任何类型的危机事件。

上述资源请求模板,当用于某个具体资源实例时,可能会要加盖时间戳,并提供有关原因、形势和位置的信息,以解释请求的依据(在可以获得的信息的范围内,资源定义表应该允许多重贡献,因为不同位置的个体,将有不同的原因、情况等等)。上诉信息,伴随请求的处理,需要相应更新。所有的更新都应当标明处理人和更新的时间。可能有大量资源请求,会共享基本的情况信息元素。细节能在任何时候被更新,反过来,细节更新也会对资源请求和充盈性产生影响。除此以外,系统需要具备在危机存在期间定义新的事件模板的能力。

作为角色履行的一部分,不同的人都有启动一个特定事件类型的权利,它可能是模板中的一个根事件或响应事件。由此引发了对同样重要的二级比喻的使用,即“检查清单”(Hale 1997; Lukaszewski 1987)。触发一个事件就会生成一份检查清单,用户需要在其中填入恰当数据并确认合适的选项;而对于那些不期而至的 “其它”无法预测的因素,用户则采用自由形式输入。其它所需角色也总会被准确找出,查明他们是否在彼时已被派发,并显示出那些需要考虑的条件性障碍,如推迟的可能性及原因。如果不能立即派遣一个医疗队伍到达危机现场,那将导致现场的人们另做选择(比如,用其它车辆迅速转移伤者)。

创建一个事件的人必须要有足够的事件信息,使事件通过合理的派遣可以进展下去。在原始的EMISARI系统中,如果需要的数据暂时无法获得,有一个代码会在输出域明示这一情况。同时,系统会显示关于提供和更新此数据的负责人的信息。

一种典型性操作模式应该是,任何人都可以接收到他感兴趣的根事件的事件类型、方位和其它一些条件(即,对它们做出清晰的标记或将它们链接到标记的事件中)。并且只有在用户对追踪的事件做出标记以后,才会当该事件模板有其它日志产生时收到信息。一旦事件发生,危机响应者就是用以上方式为自己建立起过滤机制。显然,创建根日志事件的人会自动接收到其后的所有加载在该事件中的日志条目。系统还需要提供一个越权功能,允许一个人可以决定他人是否要标记追踪此事件,如果尚未标记,是否为他触发一个事件重发命令。这也为督察者提供机会,就人们忽略的某些条目发出警示。使用代码指明丢失的信息,可以使用户去搜索、识别并努力获取丢失的数据。

事件日志模板的使用功能随后被加载到了EMISARI系统(PREMIS)的衍生系统中。当二十世纪七十年代,由于大量商品短缺,美国联邦政府一度宣布进入紧急状态的时候,它被用作追踪那些违反联邦命令的行为(McKendree 1978)。这样的系统具体规定了在一个特定事件或程序步骤中,责任方可以采取什么样的行动,并根据该行动通知适当角色(人)对这一特定事件适时承担起应有的责任。关于危机决策单元(Smart and Vertinsky)的建议概念是危机情况下事件模板的子概念。

典型性一般事件类别可包括:触发事件、资源请求、信息请求、情况报告、完成、状态改变、角色改变、警告/警示、引导/推测。

4.2 角色

角色一直是所有结构化团体在通讯过程中的关键部分(Turoff 1993; Turoff, Hiltz, Bieber, Whitworth, and Fjermestad 2001)。在最初的EMISARI危机管理系统中,角色已经成为一个关键概念(Hiltz and Turoff 1978; Mckendree 1977, 1978)。那其中的所有数据总是由负责提供和更新它的人来定义。谁能够启动什么类型的行动/事件是可以非常清晰地显示出来和被检索到的。一个人在目录中录入的时候,会看到一个包括所有责任的动态(实时)列表,它能被系统中的每个成员按责任进行搜索。

在一个危机事件中,谁将承担某个角色或角色组合是从来都无法确定的。人们被期望训练成为具有资格承担各类不同的角色。当人们意识到警察不可能承担消防员的角色时,当汇报、请求资源、分配资源的角色出现时,他们就希望交叉训练应该是灵活的。在危机情况下,首位被系统激活的人士能够立刻承担具有最高优先级的角色或是那些他已经预先被考查可以合格担当的角色。在另一些紧急形势下,如果当时没有更合适的人选,个人可能会被迫承担他并不完全胜任的角色。如果这是可能发生的情形,那么我们有必要考虑系统设计中的模糊性、实时训练、训练辅助以及更为积极的督察需求。

有权利分配角色的个人应该基于当时的需求,向系统中处于激活状态的任何成员分配角色。有经验表明,大规模的危机事件情况下至少有11个基本角色。每个角色都应该受到来自软件功能的支持(Turoff, Hiltz, Bahgat, and Rana 1993)。针对紧急响应功能的角色包括:

基本角色:

1、请求资源::医疗、警务、消防、军事、工程、公用设施等;:医疗机构,运输、燃油、设备等;

2、分配、推迟或否决资源;

3、汇报和更新局势;

4、分析局势;

5、编辑、组织和总结信息;

6、维护资源(物流);

7、获取更多或新资源;

8、预见、顾问、建议;

9、向所有需要知情的人员发出警示;

10、必要时分派角色和工作责任;

11、协调不同资源区域;

12、进行优先化和战略化设置(例如指挥和控制)。

在任何危机事件中都会出现资源请求,其他人必须决定该请求是否能被立刻满足或否决或推迟。另外,也需要就不同方位情况为不同维度(医疗、消防、警务等)作出报告,同时,其他人员也会分析这些信息以确定下列涵义:

  • 分配资源;
  • 维护当前资源;并
  • 获取额外资源以供不时之需。

另外,在很多情况下,我们需要定位资源,获取一些特殊知识(如有害物质)或提升/降低当前危机响应的水平。在最初的EMISARI系统中,人们可以动态地建立报告形式,包括定性及定量输入,将其分派到负责汇报情况的个人。

事件和角色之间具有直接关系。事件类型应该是一个开放式结尾,用户社区可以定义具体的事件类型及其关系。下列是对可能发生的事件做一般性归类:

  • 触发型事件:引发对某种行为或响应的需要;
  • 资源请求:请求分派任何类型的资源,包括人或设备;
  • 信息请求:表达对更多信息的需要;
  • 情况报告:就任意细节程度或范围对当前情况进行描述;
  • 事件完成:一系列事件的终结或总结;
  • 状态变化:某一具体事件系列的状态发生显著改变;
  • 警告/警示:需要被观测或者调查的事件;
  • 引导/推测:需要在当前情况下考虑的问题、关注或发生的可能性;
  • 角色转换:临时或永久性承担的角色发生改变;
  • 结束事件:事件进程完成;
  • 中断事件:事件处理过程中的暂停;
  • 暂缓事件:事件暂停,开始时间无法预测;
  • 存档事件:自动态修改中退出的事件(冻结)。

上述分类适用于所有事件。与上述事件类型直交的是对一个指定角色会负责的具体事件的分类。它可能包含下列类型:

  • 新建/等待:用户未曾见过或处理过的事件;
  • 事件任务追踪:角色目前负责处理的事件;
  • 事件监视:追踪感兴趣的事件;
  • 行为要求:角色必须采纳行动的任务;
  • 响应要求:角色需要提供信息;
  • 优先级改变:角色正在处理的一个条目发生优先级改变;
  • 状态改变:角色正在处理的一个条目发生状态改变;
  • 信息需求:针对该角色;
  • 结束事件:不需要进一步追踪,此角色的进程已完成;
  • 中断事件:角色处理的事件进程发生停滞;
  • 暂缓事件:角色处理的事件暂停,开始时间无法预测。

对于处在角色中的用户,以上分类结果会形成一个二维选择表,它将显示每个类别中的事件数量,用户通过点击类别中的数字可以获取事件集合清单。各个类别对于用户社区应该是可扩展的。

人们处理的内容通常会包括医疗、火警、法律执行、军事、公用设施与建筑资源,这些基本角色中的大部分需要考虑的资源类型会成倍增加。这意味着合作者必须承担责任确保来自那些倍增资源的响应之间不会相互妨碍。尤其是现在,不同地区的响应系统是彼此独立的,其中各个系统的进展细节是所有涉及方无法共知的。在第二次世界大战中,美国的陆军和海军分别在不同时间破译了日军电报,并报告给总部。如果分析员可以接触到陆军和海军的所有文件,那么袭击珍珠港的可能性则更是显而易见。只是我们对此已经了解得太晚。

根据对使用动态日志的比喻,被依次授权的各个角色都具有一些特权,比如:

  • 为一个具体事件创建日志录入;
  • 对特殊类型的事件日志录入的响应;
  • 提供特定事件的信息或数据;
  • 提供关于事件集的形势说明报告;
  • 提供修改他人录入资料的特权。

总之,一个人可以定义大约50个初始数字通讯特权,包括允许某人在其他人的资料中设置链接,或在其不能查看的文件中插入资料(Turoff 1993)。

角色在数据库中是一个清晰的对象,它对系统中的所有其它数据对象都有具体的殊链接,这些链接在对系统的数据的处理中负有特权(Turoff 1993)。无论怎样,在真实的紧急情况中,承担角色并执行有关角色特权任务的都是人类。这已在德尔菲演练中的首次集体通讯系统(Turoff 1972)和EMISARI中得到了验证。角色能够得到计算机辅助,也可以对角色进行录音,用以特定的情景模拟游戏训练。我们也并不排除,在真实的紧急情况下,当人类承担角色时也曾想把决策责任托管给计算机代理。

4.3 通知

在设计一个危机响应集体通讯系统的时候,其中的计算机通讯环节的一般性关键属性是,只有借助计算机,通讯信息的内容才可以成为“传送地址”(Hiltz anf Turoff 1978; Turoff 1993, Turoff, et. Al. 2001)。危机中的人们必须专注于那些必需的信息,以及那些影响他们做出决定和行动的情况因素的当前状态。由于他们需要知道的内容很大程度上依赖于其他人的行动和知识,我们因此应就一些特别条目的影响通知用户,这些特别条目关系着用户的角色、行动、责任,以及他们当时决定在系统中追踪的内容。当我们把用户和其动态属性纳入整体系统数据结构之后,计算机才能够决定给谁发什么通知。其它所有非结构化的替代方式,如电子邮件,会迅速导致信息过载(Hiltz and Turoff 1985)。如果一个危机的性质无法预测,而形势的发展又要求一些隐性(独特的)知识(Hayek 1945),人们就无法应用或开发算法规则用以信息传递。系统必须允许用户通过他们的行动自组信息。隐性知识惟有通过经验才能获得,比如观察、模仿和实践。

例如,当前已被指派和能够被指派的救护车数量是一个动态变量,由请求使用救护车的事件和维护救护车所需资源的消耗而决定。我们需要在某一点上通知个人或团体,基于对当前消耗速度和因未来可能发生的损坏而带来的额外随机性消耗的预测,该资源在某一特定时间将被用尽。因此,必须有人开始为资源库寻找另外可供指派的救护车或交通工具,并指派它们的分布地点。隐性知识在角色分派的过程中也得到了体现。比如,在危机环境中的特定时间和特定地点条件下,了解谁是最好的汇报者。其实,当信息不完整或非期望时,决策者正是在运用隐性知识或直觉作出判断。

伴随危机的性质和程度,资源终将开始用尽。因此,我们需要发掘一个动态功能来警示那些资源消耗的应对者。人必须决定什么时候需要采取行动。当地道路情况、危机程度、以及其它大量因素,都使得自动分派只能成为空想。即使救护车资源将要用尽,也只有人才能决定,在特定危机下这样的消耗率和需求率是否需要重新补给。

另一种典型的通知是来源于军事自动指挥控制系统的“录音性通知”(Turoff 1993)。它包括很多不同类型,比如确认式响应或植入式响应。

确认式响应的通知,是指当有人表示他想就一个特定条目作出响应时,即可收到一系列选项,他从中选择的那个响应会与原始条目链接,所有接收该原始条目的人都会接收到他的响应。例如:

-我同意/不同意

-我正在看管它

-推迟此行动

-给予更高/更低优先级

由于通知是标准化的,并且链接着与之相关的所有条目,因此需要把接收者的模糊性降到最小。创建和发送通知只需要几次鼠标点击就可完成。

植入式响应是指接收者能够运用通知值入一个定性或定量数据的特定条目。

-需要关于(主题)的信息(数据,如伤者人数)?

-截至(时间),会有更多信息出现

-我们会需要(数量)更多的 (供给项目)

-你对伤者情况的最可靠估计是什么(数字)?

那些在各类通知中出现的具体措辞其实并不重要,因为系统是要被设计成为一个演进过程,当地用户可以在其中随时定义和改变措辞。真正重要的是要捕获那些可能会在任何危机情况中都会反复出现的短信息,最终使得人们借助各种预先格式化的通讯条目,即可实现最少输入操作条件下的沟通。

通知也可用于追溯处理,点击该通知就会出现所有与之相关的条目细节。这就为我们带来了“上下文识别”概念,它是系统成功的又一关键部分。

4.4 上下文识别

一个日志事件录入与跟它相关的信息类别之间已具备联系,例如:

  • 日志编号;
  • 资源类型;
  • 作者与/或责任方;
  • 相关位置;
  • 相关环境;
  • 下一个或一些预期事件,行动的角色责任;
  • 状态(根日志序列中的相关事件);
  • 允许或产生分支日志(新的根事件日志);
  • 允许或产生通知;
  • 脚注或其它链接。

一个产生对现有医疗单元维护或重新供给的事件,或是一个获取更多医疗资源的事件,都应该与所有还未经处理的医疗资源请求相链接。

一个日志所附带的元素应该以菜单选择的形式呈现给用户,以便他们从中找到更多的特定条目信息。例如,点击日志中的一个条目,就会出现关于这个条目的各种信息,如表2所示。

2   替代对象链接(超文本关系)

上下文条目

追溯到的可能性

日志编号

所有当前日志的子事件日志

母或根事件日志

事件日志分支(兄弟日志)

资源类型

单元的当前状态

所有未使用单元的状态

所有单元的位置状态

所有使用单元的状态

所有单元的状态

新单元来源

作者或责任方

当前责任和状态

后备人员

日志或通知条目完成的预期时间

环境

事件需要的所有相关状态和定量信息

位置

区域位置图,以及区域内有什么和我们所知道的区域内有什么

关于区域内有什么的文本或列表

状态

序列中已完成事件列表

序列中未完成事件列表

序列中所有事件列表

链接

特定事件链接的通知

事件序列链接的通知

与事件相关的更新和报告

期望事件

作为此事件结果,谁要在哪些事件上采取行动

脚注

事件所有相关人员用以添加解释的脚注

 

一个事件日志具体上下文中的文字和缩写,使用起来就象是一个启动功能的界面图标。它较之图标的优势在于,我们所采用的语义记忆(见6.2 集体记忆)具有更大的词汇选择。此概念与单纯的帮助功能(例如网页鼠标指向性提示、或MTV画面中弹出的评论)不同,它是上下文提示功能(例如Apple界面的气球帮助)的扩展,运用到主要的交互式界面设计中。

该设计一方面采用情景式记忆(见6.2 集体记忆),使得人们有意识地及时追踪正在发生的事件,另一方面采用语义记忆为采取行动带来必要的数据或信息。人们承担的角色决定了他/她将会接收到什么样的根事件,系统中的一个功能会允许用户对该事件引发的各个子日志或同伴日志作出指明,是否这就是他希望跟踪的。这种自我过滤的方式首先应用在电子信息交换系统(EIES)的TOPIC系统(Turoff, Hiltz, Bahgat, Rana 1993)中,EIES70年代末期,作为一个单独的集体通讯处理结构,曾为数百人提供了交换信息的服务。在该系统中,任何人能可以发送对信息的简短需求,但是只有用户对他的问题进行了“标注”,如同我们在电子邮件中采用的方式那样,他才能得到回复。

4.5超文本

超文本概念远比当前的网页操作更大众化。遗憾的是,大多数人还是仅把它当作“超文本”。为了使其用于危机管理功能,我们必须回头认识到超文本的一些原始属性,它们包括:

  • 所有链接都是双向的,在两个端点都有锚点。因此,如果一个人被链接指向了另一个位置,他/她也总可以寻回链接。
  • 链接是语义类型的,它们总有特定的含义。
  • 个人可以拥有来自同一锚点的很多链接,每个链接都有各自的语义含义;
  • 来自同一锚点的所有当前链接的集合是一个上下文提示的动态菜单,提供上下文识别功能。
  • 链接是动态的,作为集体事件和行动的结果,它可以随时自动变化。

而标准的网页功并不包括上述各项。尼尔森(1965),在他早期关于超文本的著作中指出,链接具有维度排序性。一个在事件日志录入中来自类似医疗机构的链接,具有不同程度上的一般性和特殊性。极端的特殊性会产生一个具体医疗机构的细节。极端的一般性会就危机事件涉及的所有医疗机构的状态产生报告。而位于这其中的一个链接,就可以显示在这个特别医疗机构所要达到的位置上,所有其它医疗机构的状态。

无论用户何时创建一个链接,他们既可以指明想要的最近似链接,也可以请求一个来自锚点的可能性链接菜单。对比喻、事件日志和检查清单、链接的语义输入等各方面的全面整合,带来了自明晰用户界面的设计(Balasubramanian and Turoff 1995),它允许并向或分叉连接,避免了信息过载(Hiltz and Turoff 1985)。

上下文识别与超文本两个概念的结合,为危机响应系统的所有方面创建了一个有力的整合因素。事实上,供给用户的选择会就危机状态和已录入的事件进行动态调整。具有这些特征的一个典型应用是一些电子台历,点击录入或某个录入主题可以追溯到这个时间安排下的更多细节。如今,循此线路而生成的网页已经以“语义网页”这一新称谓出现了(Berners-Lee, Hendler, and Lassila, 2001)。

支持上述所有内容的应该是一个高度灵活而强大的列表处理交互能力,并可为每个用户、角色和筛选类型量身订做。这一列表处理功能也可以运用到系统所产生的所有列表类型中去。用户可以通过建立有利于自己的过滤、组织和分类规则,来操纵和精炼列表。用户显示的偏好将成为角色和角色的问题解决方式的一个功能。一个与系统相符并适用于其下所有列表的通用列表处理基础,是帮助用户减少信息过载的关键。系统之中的列表都是非常动态的,这是因为当一个人正在使用列表时,其他人可能也在对该列表进行修改。

 

5. 一般性设计原则

以下是一些适用于所有紧急响应系统的一般性设计原则:

设计原则1 -  系统目录:系统目录应该为存在于当前系统中的所有数据和信息提供一个层次化结构,并为所有或选定资料的子目录提供一个完整的文本搜索。

一个可能发生的系统结构可以描述如下:

目录:

-

   -背景和专长

   -团体成员

   -会议成员

   -信息公告栏编辑

   -角色

      -工作责任

        -日志事件的创立权

        -当前激活的日志事件

        -已完成的日志事件

        -通知

        -资源关注

      -权利

-角色

-事件

-团体(例如医疗、消防员、志愿者等)

-大会(主题讨论)

-信息公告栏(制度、计划等)

-数据库(资源、信息、地方性、国家性等)

-学习资料和情景游戏发生器

-其它紧急系统

显然,这其中需要一种方法来组成特殊的团体,专注于某些需要关注的区域,或负责团体会议和团体信息列表。信息公告栏会发布语义资料,并由一个小组负责更新。

系统中有很多智能软件在为系统用户服务:

  • 让用户了解谁是在同一状况和时间下被关注的子团体。
  • 发现某一特定用户还没有意识到但应该引起其注意的信息。
  • 帮助用户适应他们的联系过滤器,以应对变化的形势和需求。

系统的长期成功显然要依靠 “智能”方面的特征,它会伴随来自现实用户和实际应用的反馈意见而演变成为持续发展过程中的一部分(Gervasio and Iba 1997; Iba and Gervasio 1000; Van de Walle 2003)。

设计原则2  -  信息源和时效性: 在紧急情况下有一点很关键,即系统中的每一条用于应对紧急情况的定量或定性数据都应该就它的来源(人或数据)、发生时间和状态这三方面作出定义。在恰当时候,还应就数据位置、与系统其它已存在的参考数据的关连作出定义。

这种类型的系统不能是匿名数据库:在很多情况下数据来源是重要的,提供数据的人员需要被联络。例如,在紧急事件的进程中,有些资源需要被多次分配。在其被重新分配之前需要更新它当前的释放状态,以决定是否要对一个完成任务所需时间更长的相似资源进行托管。此外,还应该提供一个状态报告,说明为什么有些事情没有按预期进行(特例报告),为什么预期的数据还没有得到。当信息不完整时,信息来源允许其她人与信息来源者或报告者进行联系,从而获得更完整的信息。信息的早期报告者可能无暇提供额外的更新,或没有意识到对已有信息更新的紧急需求。

准备对发生事件的某方面做出报告的人,应该把数据或其它评论链接到自己的报告当中。因此,当人们察看报告时,那些链接的内容会重新生成,该报告产生之后出现的最新数据会有显示。为了清楚获知各条目的所有相关因素,系统中的所有用户都应该对每个条目进行脚注链接。这也使得我们就每一个具体数据有一个贯穿式的讨论。其结果是,很快明确了系统中谁在对该数据所体现的具体情况进行关注。

设计原则3  -  多方位的开放式通讯:此系统在灾难响应涉及的所有方面都应该是一个开放和扁平式的通讯过程。

我们无法预测需要的信息,以及谁会需要这样的信息。事实上,人们在紧急事件过程中经常需要转换角色,去执行原本不负责的任务。一个紧急情况可能会持续数日,但鉴于个人的有限能力和个人“回报递减”概念,其中的一些角色在不同时间将由不同人员承担。另外,在多数的危机情况下,正常的层次型组织结构都会缩减为扁平式通讯网络,并导致其中的个体状态发生变化(Dynes and Quarantell 1977)。但由危机中处于低层的人们所做出的决策数量却随之增加。

设计原则4  -  内容即是地址:一条信息的内容决定了它的地址。

这就是由计算机系统给数据和信息加入一个不同的维,使其它通讯方式难以复制(Hiltz and Turoff 1978; Turoff 1993)。参与紧急事件处理的个人,除了向他人发送和接收信息以外,还要输入和追溯由内容决定的信息。一个鲁棒性目录结构可以为人们提供一个全面的搜索空间,去发现他们所需要的内容并相应创建自己的过滤器与链接。当人们出于兴趣或重要性而标记了一个事件或数据的时候,系统可以允许他们仅就感兴趣的资料进行开发和组织。通过添加非常简单的特征,使得危机人员可以追溯出一份所有重要条目的标识者的名单,然后用此名单作为通讯地址,就可以以一种非常动态的方式形成一些“共同关注”之下的子团体。此类即兴团体的形成和性质是难以预测或计划的。在危机情况中,那些担当分析或报告角色的人员是非常具有价值的。

设计原则5  -  当前信息与数据:无论是用户从屏幕看到或口头接收的数据都应在抵达用户界面设备时已处于更新状态。

这是一种可能会被称为“动态”的连接形式,作为一个主拷贝而保存在系统某处的所有数据,也可以追踪到它在用户网络中存在的位置。主拷贝会知道用户是否在查看这些数据,任何时候发生的数据变化都将被传送到显示数据的地方。这意味着用户所需要的资源状态肯定是当前的。甚至有这样的情况发生,当某一数字在被用户查看时,它都有可能出现变化。对于那些被个人用户标记追踪的事件,所有关于其标记时的原始状态、信息或新的子事件的变化通知都会放到用户的待查看队列中。尽管用户没有时间搜索关注的事件,但此事件的状态变化仍应被传递和呈现给用户。因此,可能很有必要引入程度标注,允许用户通过指示哪些事件应该直接插入而不是在队列中等候,来控制要递送的资料数量。

设计原则6  -  链接相关信息与数据:一个数据条目及它与其它数据的语义链接应该被视为一个同时创建或更新的信息单元。

链接数据的概念对于紧急响应操作是至关重要的。数据的任何一个条目都关联着大量的属性和其它数据。用户没有时间来思索和设计复杂的搜索查询。因此,每个单独的数据条目都必须具备所有表示它与其它数据之间关系的链接。而且,这些链接都有不同含义(链接类型),为双向链接(不同于现在的因特网)。当一条数据被创建或更新时,所有相关的链接也会被创建或更新。如何一个人通过一系列链接最终找到某条感兴趣的数据,那么仅按相同顺序向他提供“返回键”是不够的。当他了解到还有其它数据需要检查的时候,应该可以有其它查询路径可供选择。所以,系统需要提供选择链接,允许用户直接到达他们现在想去的位置。

设计原则7  -  权利、工作责任和权利责任:在紧急情况下,权利总是向下流动,去到行动发生的地方。

这正强调了在紧急事件现场我们需要万事具备。处于远程的指挥中心人员的工作是确保那些一线人员所作的决策不会导致一些负面效应累积到必须要加以更正的程度。在紧急事件应对中,上层指挥起到的是对地方性行动的督察和处理其中特例的作用。他们需要注意到某个已采取的行动可能是错误的,因为它与其它各地的行动相背或发生冲突。行动权应该属于一线角色,而上级更多地是要处理监督、勘漏、资源可用性和危险评估等方面的工作。决策会启动一个事件,进而要求对此采取行动。当出于可能发生的冲突或困难而需要下令停止行动时,除非命令来自于督察人员,否则行动仍会继续。必须对“谁正在采取什么行动”有清晰的权利责任划分,所有参与人员都应该了解冲突发生的时间及应对的方法。在灾难情形下,权利总是向下流动的(Dynes and Qarantell 1977)。

设计原则8  -  心理和社会因素:鼓励和支持危机响应队伍在心理和社交方面的需要。

允许活跃的社交关系出现并利用系统对其进行维护和发展是十分必要的。它在减轻压力程度,协助角色交接和进行督察方面都具有正面影响。系统必须允许“团队精神”的发展。个人要对他人有足够了解,以便放心地移交角色。个人必须要培养出对他人的信任感,对彼此的能力有充分了解。当一个人值班到第十四个小时,仍然如同他在第一个小时那般清楚自己被要求做的事情,是一个重要的设计因素。用于追踪每位用户值守时间的那些措施将变得意义重大。

由于越来越多的人作为日常组织团队的外援而出现,为了快速发展信任关系,通过安排有“咖啡休息时间”的大会和聊天室来完成社交网络的建设会显得愈发重要。相对于填写僵化表格时使用的那些非开放文本注释,我们要在通讯中鼓励使用非正式语言,这也是另外一个设计因素。没有人会想到要阻止现实中相互照面的团队社交,但是一个典型的信息系统环境仍然是被设计考虑排除在外。当紧急事件系统作为一个分散型虚拟指挥中心出现时,这样的考虑就很关键了。我们非常需要系统内的个人之间相互依靠,普遍接受坦白的观点。这样的现象仅在社交网络中才会出现。

在这方面,界面设计中最具挑战之处在于,减少信息过载,并使用户将系统视为助手,而不是限制用户仅靠单一方法去解决问题。用户应该能够对系统作出调整,以适应她/他自己认知的问题解决方法,而不是任其呈现一个僵化的问题解决方法给所有用户。僵化的界面在具体的问题环境下,会阻碍创造性和即兴发挥。危机环境下的人们受来自任务的道德驱使能够在压力下工作;但是,当他们的工具与想要达到的表现水平不符时,会导致“僵化-威胁症”的出现。这一界面设计在当前的研究领域中仍为一项基本挑战。

 

6. 支持设计的一些考虑

以下是创建一个全面紧急响应管理信息系统所需要的一些通用要求和支持功能及支持系统。

6.1资源数据库和社区协作

资源数据库是所有紧急响应系统的一个关键组成部分。它可以是一个数据库集合,负责提供不同类型的物理、信息或人力资源。一些关于有害物质的国家性数据库所提供的及时而清楚的信息,对于任何地方数据库都具有参考性。一个地方性数据库的关键组成内容必须覆盖非常广泛的领域,从而适用于各类可能会遭遇的灾难情况。例如:

  • 可能在灾难情况下用到的各类建筑设备和设备操作人员。
  • 医疗设施和医务人员,包括退休志愿者。
  • 具备特殊知识的专家,如有害物质、水处理、建筑构造,道路修复、爆破处理等。
  • 船舶和任何可能用于运输的车辆和卡车。
  • 材料检测设备(如,生态、化学等方面)。
  • 公共设施:养护机构和人员。
  • 有害物质信息。

如今,设计一个承载多样化资源的数据库并不是一件难事。但是,如果当地政府机构需要斥资去维护和更新这一数据库以确保数据的即时性,那将成为一项花费高昂的运营工作(Eichenbaum 2002)。当地社区或地方性区域能够维护一个资源数据库的唯一方式,就是把数据库设计为协作类型。

那些拥有紧急情况下需被借用、租用、补偿性征召、或志愿征用的资源的人们或组织,应该能够随意使用数据库,并在其中输入和维护他们所负责的数据。数据库必须作为社区资源来建设。它可以是一个拥有所有可能会用到设备的清单的承包商,在线进入数据库进行录入维护,也可以是不同组织在非紧急状态下找到的一些资源。这样的数据库才能服务于社区,进行资源的潜在共享、交换或租用。”911”事件中,业界在集中时间内提供了大量的紧急支援(Michaels 2001),这意味着如果方法得当,是完全可能获得社区支援的。在许多反复发生自然灾害的地区,我们总是能看到来自社区的支援。

该数据库的维护会成为特定区域内的社区成员需要协同进行的分散性责任。每个提供可能资源的个体都可以直接进入数据库更新其负责的数据。我们也希望该区域内的政府组织如州机构、国家防卫队和军事部门,能够成为这一合作资源数据库的重要贡献者。显然,同一区域内的各地社区应该可以进入彼此的资源数据库,去查询那些欠缺或用以处理大规模灾难情况或极端事件的资源信息。一个协作式分散性数据库系统的成功案例就是内部图书馆的借阅系统。

一个资源数据库应该是呈地理式分布,整合了所有公共设施、建筑物和道路方面的数据。纽约市非常幸运,它在布鲁克林拥有一个已建成的数据库,但其负责机构却座落在市中心。数据库的如此分布对城市复苏的计划和行动具有无价的帮助(Eichenhaum 2002; Thomas, Cutter, Hodgon, Gutekunst, and Jones 2002)。这样的数据库对处理诸如有害气雾扩散危机的协助也是无法衡量的。

对于负责处理危机的组织而言,一旦危机真正发生,在前期的计划阶段即引入公众参与是很有价值的(Dyer 1995)。大量的自然灾害情况一再显示,公众在灾害响应阶段的合作可以排除大量可能的复杂状况并提供额外的人力资源。一旦人们参与到计划工作中,他们也会愿意参与评估计划的演练。大部分缺乏地方和社区资源的小型城区几乎是强制各个社区参与到危机响应计划和执行任务中去。

6.2 集体记忆

语义记忆或者摘要记忆提供了关于事件、事件之间的交互和依赖性以及如何与对象或者数据组相联系等一系列的规则。集体记忆由那些现实世界案例当中的普遍性演变而来。可描述的发生事件与其惯常响应之间存在着动态关联的过程,事件日志比喻使得这一过程以一种灵活但不模糊的方式在进展,于是产生了集体记忆的认知方法(Warren 1996)。

集体记忆和集体学习的部分行为已经超出我们对认知心理的理解,有时过分专注于上下文组织。因此,如果把集体记忆的属性与认知联系在一起,这样的系统对于集体成员可能更加直观。从而使得集体中的个体认知能力更专注于紧急事件的集体响应任务。首先结合情节(事件)记忆与语义(键入式联系)记忆,然后增加群体能力,使其通过标记和行为模式形成共同关心的内容,我们就此提供了形成动态集体记忆的可能。

事件日志对追踪危机和建立组织记忆(Hale 1997)的过程可能是极有帮助的。Hale并进一步建议,这些内容甚至应该出现在控制中心的演示板上。在对地方或区域紧急事件的处理中,我们似乎普遍缺乏对技术作用的全面了解。当前紧急事件响应通讯更多是集中在电话、收音机以及面对面的口头通讯技术方面。”911”事件中,紧急事件响应者在失去了通讯中心和口头通讯设备之后,尝试使用寻呼机的文本信息进行沟通。据报道这种方式在当时发挥出非常好的作用(Michaels 2001)。如今,我们对影响新数字媒体(Rice 2002)使用的因素已经具有一定的了解,基于这些了解而产生的合理化管理策略很容易带动技术的迅速传播。

通常情况下,我们很难对一些仅适用于特定情况的知识进行编撰并加以传播。这就是为什么情景描述更能够表达隐性知识(Kim 1998)。由于发生事件较少,因此并不是所有人都会先后经历同样的危机局势(King 2002)。即使是自然界发生的危机事件比如台风、飓风或地震,也是会产生非常不可预测的特殊影响(Barton and Hardigree 1995)。

细微调节、消除模糊、同化源于经验成员的知识(隐性知识)、发现差别、构建团队凝聚力、提升演练的现实性和合理性,这些都是系统与其相关演练的重要功能(Nyblom, Reid, Coy and Walter 2003)。任何危机处理时的集体记忆均可在事件模板、通知类型、角色责任、资源数据库内容和演练情景的描述中找到。当隐性知识的一些形式不可能明确时(Hayek 1945),我们通常仍就可能捕捉到其结果,比如决策或行动(Belardo et al. 1984, Belardo and Harrald 1992; Bieber et al. 2002)。

富有经验的人们是信息的重要来源。我们当前的最大问题就是,同一组织内的各机构抵制对信息的公开和共享。其原因在于,信息所揭示的先前发生的错误可能令组织陷入窘境。我们需要培养来自不同组织的经验人士之间的持续性合作,相互沟通和交换信息。这其中一些最关键的知识其实是来自于对先前错误的检查。

6.3 专家在线社区

鉴于美国目前面临的形势以及一些特殊专家不是能够去到任意地方的事实,我们应该重提在二十世纪七十年代由OEP发起的网络专家概念。这是OEP紧急事件计划的基础,也是EMISARI初期工作的前提(Linston and Turoff 1975; Turoff 1972,2002)。该系统集中OEP的大量专家,通过对在线德尔菲系统的开发来辅助危机事件的计划。在线社区的想法随着互联网的出现得以很好实现。联邦政府应该鼓励这样的社区,作为此鼓励的回报,当危机发生时,这些专家应该出现在当地社区中。

3列举了一些正式和非正式的专家社区网。他们都是典型的加入当地紧急响应计划和响应工作的专业人士,彼此分享和交换一些源于各自经验的极具洞察力和实践性的论文。这类日益增多的文献对发展那些完善后的细节需求是非常难能可贵的(Cameron, 2003)。另外的一个要例,则是我们目前对网络病毒响应的处理。产业界的各个集体会相互从对方寻找关键供给和资源,以适应某一需求高峰。在诸如少量偏门二手书市场的无数合作领域中,专业人士其实是由于共同的利益而在彼此帮助。为支持上述专业社区活动而建立的一个协作系统所需要的设计工作是非常少量的。很多人认定,早期的集体通讯比如线性讨论列表和电子邮件即已囊括所有必要方面,而且在上述大部分案例中被用到。事实上,我们阐述的量身定做式结构化通讯系统,才更适合用作紧急响应区域的在线团体的支持系统。

3   专业化社区

国际应急管理者协会(International Association of Emergency Managers

http://www.iaem.com/index.shtml

国际应急管理协会(The international Emergency Management Society

http://www.tiems.orgl

公共实体风险研究学会(Public Entity Risk Institute

http://www.riskinstitute.org

公共安全无线网络(Public Safety Wireless Network

http://www.pswn.gov

国际公共安全通讯官员协会

Association of Public-Safety Communications Officials, International

http://www.apco911.org

国家紧急号码协会(National Emergency Number Association

http://www.nena.org

美国内部防御协会(The American Civil Defence Association

http://www.tacda.org

技术补给: 非营利性技术园地(Techsoup: The Technology Place for Non-Profits

http://www.techsoup.org

人道主义援助团体(Humanitarian Relief Community

http://www.reliefweb.int/w/rwb.nsf

 

这样的专家社区,平时即使用与紧急状态下相同的系统,使得应对真实紧急事件所需要的大量训练最小化。而且,在大部分企业或政府组织中,总会出现一些明显意外的紧急情况:资源短缺、罢工、预算超标、负面公众印象、客户不满等等。一个具有良好设计的紧急事件响应系统,能够满足正常通讯的基本需求,随着短期内的典型组织性危机情况出现得越多,则更多具体的的紧急响应功能可以得到演练。

 

7. 结论与最终观察

在紧急事件响应领域,我们极其幸运地拥有“事件日志”比喻,大部分紧急响应专业人士对此都非常熟悉,并且它在计算机上的工作与实际方法类似。另外,该比喻还提供了“上下文识别”,使得系统必须运行的许多功能,通过直接联系到比喻中的各个元素而呈现。这将大大降低用户学习系统的困难性,并使得对执行操作的认知负担减少到最小。

而更重要的是,“事件”和“角色”的概念已经转换为非危机行为,例如会议、计划发展、委员会功能、项目功能以及演习操练。我们很容易就可以想象,真实危机涉及的所有组织和那些来自组织的联络人将运用这一系统进行所有的计划和协作活动。

计划功能将通过不同团队对系统的运用,很好地得以实现。其中包括风险识别、风险评估、危机计划与准备、动员和恢复工作(NyBlom, Reid, Coy, and Walter 2003)。所有这些为系统的演进带来了改善。

针对任何形式的项目任务,在日常基础上使用本系统,甚至由参与组织自行设置限制级内部版本,能够确保人们保持演练,有能力应对真实危机。任何组织随时都有可能面临细小危机,它们通常会使得一些特殊的团队或团体必须合作寻求一个合适的解决方案。现在,他们可能在地理位置上呈分散分布,但依旧能够毫无困难地从我们描述的这个系统中受益。

将事件发生器纳入通讯系统之中是一件容易的事,该发生器由时钟时间驱动,使系统转化成仿真游戏系统,就当前状况下的资源数据库和可用人力来对各类危机事件的计划进行演练(Van de Walle and Turoff 2001, Van de Walle 2003)。如果来自其它机构的人员在演练中时不能到位,则可以由相同类型的人员角色事件进行模拟。在真实的时钟时间内开展演练,使其增加了真实性(Turoff 1997)和加强了训练效果。如果演练诱发了会在现实危机中出现的相同的心理过程,仿真就是真实的(Sniezek, Wilkins, Wadlington, and Baumann 2002)。这也是很好的理由,可以解释为什么这样的演练应该是出其不意的,而没必要提前策划排期。对“角色-事件”模拟游戏的先前研究显示,它们是用以学习复杂经验的最好机制之一(Hsu 1989)。为进一步提高心理感受过程,我们应该引入位于不同地点的危机响应团队,在相同的游戏场景彼此竞争。这也会促使国内范围的响应者“实践社区”的建立(Wenger and Snyder 2000)。

这些演练都可以根据用户的反馈意见,对系统进行评估和演进。如果用户已习惯于把改进系统作为演练的一部分,他们更可能避免因受到威胁和其产生的压力因素而带来的反应僵化(Rice 1990; Staw, Sandelands and Dutton 1981)。人们愿意看到的一个危机响应系统,是对处于某一意料之外情况(例如罢工、丑闻、环境问题、代理权争夺、合同不作为)下的团队成员的创造性反映的模拟。

我们定义的系统是一个虚拟组织(Mowshowitz 1997, 2002),由正式和非正式的组织过程和调整结构的元过程组成。

1   工作流程的通讯过程

 

 

 

 

 

 

 

 

 

 

 


2   元通讯过程

 

 

 

 

 

 

 

 


根据Mowshowitz1997)对虚拟组织结构的论述,“不可控事件(危机/紧急事件)”是需求,资源则是满足者。“角色”是发生转换的单元,将资源分配给需求方并进行管理,收集必要信息来执行交换,以达到缓解危机的目标,并保持充足的资源用以分配。“角色”既有非正式机制,允许个人假定所需的角色,也有正式机制,分派权利 (可以被代表) 和督察角色,以确保资源的最优化使用。采用本系统,允许它作为虚拟组织在危机当中的各个响应阶段运行,将赋予系统“虚拟化”的定义(Turoff 1997)。它意味着在响应过程中,系统自身会作为进化过程去影响变化乃至改进。

在一篇由BigleyRoberts写于 2001年的精彩文章中,由一系列就实际消防情况的访谈和调查,引发了大量对潜在紧急事件响应的组织结构的重要研究。文章呈现出大量优秀的结论和研究,尤其是角色的概念以及集体理解和权利代表的需要。文章的结尾是对“事故指挥系统(ICS)”的建议,它是一个高度结构化、自上而下的官僚式设计却又具有某些灵活性元素,允许即兴发挥和权利代表。它的基础在于口头式交互和总是身处紧急事件现场的人。它在某些方面是本系统的替代,由此突出了进一步开发紧急响应结构的需要。

ICS可能对单维的紧急事件很有效,例如,火警情况之下的每个人都接受了高水平的训练,响应小组在实质上是相同的。但是多维危机的情况则大不相同,其中的即兴发挥和灵活性所需要的口头调解将由于信息过载和参与的个体机构性质不同而丧失。如果我们了解那些基于系统,尤其是基于通讯系统之上的计算机设计,会发现将物理世界的普遍实践加以自动化并不是一种最佳应用技术的方式。

极有可能出现的“威胁-僵化症”是最令人关注的问题。这一假设由Staw, SandelandsDutton1981年提出,经Rice1990进一步阐述。那些经受压力、焦虑和心理唤醒的个体更趋向于越来越依赖自己的内心假定,着力于显著线索来展现充分了解的响应行为。简而言之,对危机情况的潜在响应只是照本宣科,仅使用自己已知的响应方法。然而,如果需要响应的状况不似先前的演练,则可能导致完全错误的行为。因此当实际情况发生时, 更需要确保鼓励人们认真思考形势,并检查他们的潜在行动,允许一定程度内的即兴发挥或创造性。

通讯和组织结构以及信息的流动,对于鼓励或阻止僵化是非常关键的。我们认为,扁平的组织结构,允许个人可以平等获取他们感觉可能需要的任何信息,将鼓励响应的灵活性。在大部分组织结构中,负面信息在向指挥层上方传递时会变得愈加正面。扁平结构的组织试图减轻发生在信息传递方面的这个问题,尤其当报告源是数字型的,并且所有任何程度的参与者都可获用的时候。此组织对响应者的态度也有所影响,他们会由此感到自己是这个充满凝聚力的团队的一部分,所有人都一样在尽最大努力来缓解危机。这些对于危机的响应态度和参与团队的自身凝聚力,是工作成功的关键(Braverman 2003; King 2002)。至少有一项调查组织性危机响应性质的实验研究表明,那些贯穿于组织机构间的友谊和信任使得危机响应者团队更加具有效率(Krackhardt and Stern 1988)。当我们提及一个重大的危机事件时,我们总是谈到来自不同组织机构的人组成了一个团队。这也同样适用于响应者与一个持续社区的形成及简化之间的正常交互需要。

最近一项针对州政府在各种危机中的响应调查(Horseley and Barker 2002)发现,各政府机构之间处理事件的最成功的通讯形式是内部电子邮件。不同机构的不曾在一起工作的人们之间的通讯可能包含着大量的模糊性。模糊性的结果就是人们经常认为他们已就某方面进行了沟通并达成一致,而事实上并不是这样。一旦被问起,他们显然以为沟通进展得很好。这是普遍性的“一致模糊”,常发生在集体会议后,每个人都事后惊讶于报告说他们已经取得一致。显然,用于文本处理的集体通讯系统,对于此任务而言可能已经是更好的技术了。

有各项细致研究表明,即使是在对如飓风这样非极端事件的地方紧急响应中,不同参与机构之间的主要问题出在协作方面,而这些机构中的很多政府官员和专业人士并不能记起或熟悉紧急事件程序(McEntire 2001; Parker, LeDuc and Lynn 2002)。虽然协作问题是紧急事件响应中的主要隐含问题,但却被大大的忽略了。物理形式上的机构重组始终都不是处理协作问题的解决方案。而提供技术,使得人们围绕危机动态成组,才是我们将要研究的处理协作问题的方法。

如今,大量不同水平的专业人士借助处于同一通讯网络中的计算机,可以对正在发生的事情进行观察和审查,因此使得督察工作比在分层指挥的口头环境下能更大程度地发挥作用。其间的权利责任属性也促使人们更可能合理地考虑自己需要做出的决定。一个在口头环境里出现的普遍现象是,谁负责决策经常很模糊。而且,在标准数据库的方式中,决策贡献者的身份和决策内容的依据很快就会丢失。在传统的信息系统中,由于权利责任的缺乏而为组织所带来的问题早已被认知。

当前,我们很少关注地方区域性危机事件的命令控制系统的认知和设计。对于紧急事件计划的建议仍然集中在成立紧急事件响应中心和援助中心方面(NyBlom, Reid, Coy and Walter 2003)。我们也仍然没有建立一个全方位分布式系统的概念,对于大多数小社区而言,有形中心的建设成本还是很昂贵的。

军队和一些大型公司,比如美国银行和威尔士远运,正在投资建立虚拟指挥控制中心,既虚拟紧急事件处理中心(Davis 2002; Roos 2002)。通讯的虚拟性质使其具备潜力,为决策者提供在虚拟现实空间中的不同程度的危机情况可视化。虚拟指挥中心能够身处各地工作站,运用互联网技术发挥作用。

“危机”一词在中文里由两个意义组成:危险和机会。现在我们有机会对紧急事件响应系统的设计和功能进行显著改善,但如果不着手行动,未来将会有大量危险出现。

 

8. 参考文献

1.        Alles, M. G., A. Kogan and M. Vasarhelyi, “Black Box Logging and Tertiary Monitoring of Continuous

Assurance Systems,” Information Systems Control Journal, 2003, 1, pp. 37-39.

2.        Balasubramanian, V. and Turoff, M., “A Systematic Approach to User Interface, Design for Hypertext Systems,” Proceedings of the 28th Annual Hawaii International Conference on System Sciences HICSS, 1995, Volume III, IEEE Computer Society Press, pp. 241-250.

3.        Barton, L., and D. Hardigree, “Risk and crisis management in facilities: Emerging paradigms in assessing critical incidents,” Facilities Journal, 1995, 13:9, pp. 10-11.

4.        Belardo, S. and Harrald, J., “A framework for the application of decision support systems to the problem of planning for catastrophic events,” IEEE Transactions on Engineering Management, 1992, 39:4, pp. 400-411.

5.        Belardo, S., K.R. Karwan and W. Wallace, “An investigation of system design considerations for emergency management decision support,” IEEE Transactions on Systems, Man, and Cybernetics, 1984, 14:6, pp.795-804.

6.        Berners-Lee, T., J. Hendler and O. Lassila, “The semantic web,” Scientific American, May 2001, p. 279.

7.        Bieber, M., S.R. Hiltz, E.A. Stohr, D. Englebart, J. Noll, M. Turoff, R. Furuta, J. Preece and B. Van de Walle, "Towards Virtual Community Knowledge Evolution", Journal of Management Information Systems, Spring 2002.

8.        Bigley, G.A. and K.H. Roberts, “The Incident Command System: High-Reliability Organizing for Complex and Volatile Task Environments,” Academy of Management Journal, 2001, 44:6, pp. 1281-1299.

9.        Braverman, Mark, “Managing the human impact of crisis,” Risk Management, May 2003, 50:5, 10-.

10.     Cameron, D., “Technology Planning for Civil emergencies: Prepare your organization to deal with the unthinkable,” TechSoup Article, 12 November 2003, http://www.techsoup.org

11.     Coombs, W.T., “Designing post crisis messages: Lesson for crisis response strategies,” Review of Business, 2000, 21:3/4, pp. 37-41.

12.    Carroll, J.M., and Thomas, C., “Metaphor and the Cognitive Representation of Computing Systems,” IEEE Transactions on Man, Systems and Cybernetics, March-April, 1982, SMC-12, pp. 107-116.

13.     Cho, Hee-Kyung and M. Turoff, “Delphi Structure and Group Size in Asynchronous Computer-Mediated Communications,” Proceedings of AMCIS 2003, Association for Information Systems, http://www.aisnet.org, last accessed 9 February 1993.

14.     Danowski, J., and P.E.-Swift, “Crisis Effects on Intraorganizational Computer Based Communications,” Communications Research, 1985, 12:2, pp. 251-270.

15.     Davis, S., “Crisis Management Series: Virtual Emergency Operations Centers” Risk Management Magazine, 2002, 49:7.

16.     Dyer, S.C., “Getting People into the crisis communication plan,” Public Relations Quarterly, 1995, 40:3, pp. 38-.

17.     Dynes, Russell, and E.L. Quarantell, “Organizational Communications and Decision Making in Crises,” Disaster Research Center Report 17, January 1977, Ohio State University.

18.     Eichenbaum, Jack, “CAMA, GIS, and the Recovery of New York City,” Assessment Journal, 2002, 9:3, pp. 17-22.

19.     Gervasio, M.T. and W. Iba, “Crisis response planning: A task analysis,” Proceedings of the Nineteenth Annual Conference of the Cognitive Science Society, 1997, p. 929.

20.     Hale, Joanne, “A layered communication architecture for the support of crisis response,” Journal of Management Information Systems, 1997, 14:1, pp. 235-255.

21.     Hardeman, F., N. Pauwels, C.R. Palma and B. Van de Walle, "The role of experts in decision making upon urgent countermeasures in nuclear emergency situations,” Proceedings of the Society for Risk Analysis –Europe Conference on "Risk Analysis: Opening the process,” 1998, Paris, France.

22.     Hayek, F.A., “The Use of Knowledge in Society,” The American Economic Review, September 1945, 35:4, p. 519-530.

23.     Hiltz, S.R., and M. Turoff, “Structuring Computer mediated Communication Systems to Avoid Information verload,” Communications ACM, 1985, 28:7, pp. 680-689.

24.     Hiltz, S.R., and Turoff, M., The Network Nation: Human Communication via Computer, 1978, Addison esley, Revised edition: MIT press, 1993.

25.     Horseley, J.S. and R.T. Barker, “Toward a synthesis Model for Crisis Communication in the Public Sector: An Initial investigation,” Journal of Business and Technical Communication, 2002, 16:4, pp. 406-440.

26.     Hsu, Enrico, ”Role Event Gaming Simulation in Management Education,” Simulation and Games,” December 1989, 20:4, pp. 409-438.

27.     Iba, W. and M. Gervasio, “Adapting to user preferences in Crisis Response,” Proceedings of IUI 99, ACM 1999.

28.     Keen, Peter G.W., “MIS Research: Reference Disciplines and a Cumulative Tradition,” Proceedings of the First International Conference on Information Systems, December 8-10, 1980, Philadelphia, PA, 9-18/

29.     Kim, Linsu, “Crisis Construction and organizational learning: Capability building in catching-up at Hyundai otor,” Organization Science, July-August 1998, 9:4, pp. 506-521.

30.     King III, Granville, “Crisis management and team effectiveness: a closer examination,” Journal of Business thics, December 2002, 41:3, pp. 235-249.

31.     Krackhardt, D. and R. Stern, “Informal Networks and Organizational Crisis: An experimental simulation,” ocial Psychological Quarterly, 1988, 51:2, pp. 123-140.

32.     Kunreuther, H., and A. Lerner-Lam, “Risk Assessment and Risk Management Strategies in an Uncertain World, Executive Summary,” Columbia/Wharton Roundtable, April 12-12, 2002.

33.     Kupperman, R., Wilcox, R., and Smith, “Crisis Management: Some Opportunities," Science, Feb. 7, 1975, 187, pp. 404-410.

34.     Kupperman, R., Wilcox, R., “EMISARI - An On line Management System in a Dynamic Environment,” Proceedings 1st International Conference on Computer Communications, 1972, IEEE, pp. 117-120.

35.     Lewin, K. “Group Decision and Social Change” In Readings in Social Psychology Ed. Newcombe, T. and Hartley, E., New York: Holt 1958.

36.    Linstone, H. and Turoff, M. eds., The Delphi Method: Techniques and Applications, Addison Wesley Advanced Book Program, 1975, now on line via http://is.njit.edu/turoff, last accessed 9 February 2003.

37.     Lukaszewski, J.E., “Anatomy of a Crisis Response: A Checklist,” Public Relations Journal, November 1987.

38.     Macon, N., and J.D. McKendree, EMISARI Revisited: The Resource Interruption Monitoring Systems,” Proceedings 2nd International Conference on Computer Communications, 1974, IEEE, pp. 89-97.

39.     Macon, N., J.D. McKendree, and R. Wynn, “Computer Conferencing in Emergencies: Some Reliability Considerations,” Proceedings of the IEEE Conference on Computer Networks, 1975, pp. 69-73.

40.     Massey, J.E., “Managing Organizational Legitimacy: Communication Strategies for organizations in crisis,” The Journal of Business Communications, April 2001, 38:2, pp. 153-182.

41.     McEntire, D., “Multi-organizational Coordination During the Response to the March 28, 2000, Fort Worth Tornado: An Assessment of Constraining and Contributing Factors,” Quick Response Report 143, 2001, National Hazards Research and Applications Center, University of Colorado.

42.     McKendree, J., “Project and Crisis Management Applications of Computerized Conferencing,” Bulletin of the American Society for Information Science, 1978, 4:5, pp. 3-15.

43.     McKendree, J., “Decision Processes in Crisis Management: Computers in a new role,” Encyclopedia of Communications Science and Technology, 1977, 6, pp. 115-156.

44.     Michaels, Sarah, “Digital Disaster Assistance: How and Why selected Information Technology Firms Contributed to Recovery Immediately after the September 11 Terrorist Attack,” Quick Response Report 141, 2001, National Hazards Research and Applications Center, University of Colorado.

45.     Mork, L., “Technology Tools for Crisis response,” Risk Management, October 2002, 49:10, pp. 44-50.

46.     Mowshowitz, A., Virtual Organization: Toward a Theory of Societal Transformation Stimulated by Information Technology, 2002, Quorum Books, Westport, Connecticut.

47.     Mowshowitz, A., “On the Theory of Virtual Organization,” Systems Research and Behavioral Science, 1997, 14:6, pp. 373-384.

48.     Nelson, T.H., “A File structure for the Complex, The Changing, and the Indeterminate,” ACM 20th National Conference, 1965, pp. 84-99.

49.     NyBlom, S.E., J. Reid, W.J. Coy, and R. Walter, “Understanding Crisis Management,” Professional Safety, March 2003, 48:3, March 2003, pp. 18-.

50.     Parker, Robert, A. LeDuc, and K. Lynn, “Oregon Emergency Management: Evaluating Interagency Communication in the Post Disaster Environment,” Quick Response Report 149, 2002, National Hazards Research and Applications Center, University of Colorado.

51.     Pauwels, N., B. Van de Walle, F. Hardeman and K. Soudan, “Irreversible decision making for nuclear emergency planning,” Theory and Decision, 2000, 49:1, pp. 25-51.

52.     Pearson, C.M. S.K. Misra, J.A. Clair, and I.I. Mitroff, “Managing the Unthinkable,” Organizational dynamics, 1997, 26, pp. 51-64.

53.     Price, C., “Conferencing via Computer Cost-Effective Communication for the Era of Forced choice,” in H. Linstone and M. Turoff eds., The Delphi Method, 1975, Addison Wesley available on the Web via http://is.njit.edu/turoff, last accessed 9 February 2003.

54.     Pyush, I.R., I.S. Fuhrmann, H. Wang, R.S. Agrawal, A.M. Brewer, C. Guoray, “Designing a Human-Centered, Multimodal GIS Interface to Support Emergency Management,” Proceedings GIS’02, 8-9 November 2002, McLean, Va., ACM Press, pp. 119-124.

55.     Renner, R.L., R.M. Bechtold, C.W. Clark, D.O. Marbray, R.L. Win, and N.H. Goldstein, “EMISARI: A Management Information System to Aid and Involve People,” Proceedings of the International Symposium on Computer and Information Science, COINS, 1972.

56.     Rice, R.E., and J. “Webster, Adoption, Diffusion, and Use of New Media,” in C. Lin and D. Atkin, eds., Communication Technology and Society, Cresskill, NJ: Hampton Press, 2002.

57.     Rice, R.E., “From Adversity to Diversity: Applications of Communication Technology to Crisis Management,” Advances in Telecommunications Management, 1990, 3, pp. 91-112.

58.     Rice, R.E., “Information, Computer Mediated Communications and Organizational Innovation,” Journal of Communication, 1987, 37:4, pp. 65-94.

59.     Rogers, E., Diffusion of Innovations 4th Ed, 1995, New York: Free Press.

60.    Ruben, B., Communication and Human Behavior, 1992, Prentice Hall.

61.     Roos, J., “More Than an Ounce of Prevention: A Virtual Command and Control Center, Other Crises Management Tools, For Homeland Security” Armed Forces Journal International, February 2002.

62.     Smart, C.F., and Vertinsky, I., “Strategy and environment: A study of corporate response to crises,” Strategic Management Journal, 1984, 5, pp. 199-213.

63.     Smart, C.F., and I. Vertinsky, “Designs for Crisis Decision Units,” Administrative Science Quarterly, December 1977, 22, pp. 639-657.

64.     Smart, C., W. Thompson, and I. Vertinsky, “Diagnosing Corporate Effectiveness and susceptibility to Crises,” Journal of Business Administration, 198, 9:2, pp. 57-96.

65.     Smith, C.A.P., and S. Hayne, "A Distributed System for Crisis Management," Proceedings of the 24th HICSS, 1991, 3, pp. 72-81.

66.     Sniezek, J.A., D.C. Wilkins, P.L. Wadlington, and M.R. Baumann, “Training for Crisis Decision Making: Psychological Issues and Computer Based Solutions,” Journal of Management Information Systems, spring 2002, 18:4, pp. 147-168.

67.     Star, S. L., “The structure of ill-structured solutions: boundary objects and heterogeneous distributed problem solving,” in L. Gasser and M. N. Huhns eds., Distributed artificial intelligence, 1989, pp. 37-54.

68.     Staw, B., I. Sandelands, and J. Dutton, “Threat-Rigidity Effects in Organizational Behavior: A Multilevel Analysis,” Administrative Science Quarterly, 1981, 26, pp. 501-524.

69.     Thomas, Deborah, S. Cutter, M. Hodgson, M. Gutekunst, and S. Jones, “Use of Spatial Data and Geographic Technologies in Response to the September 11 Terrorist Attack,” Quick Response Report 153, 2002, National Hazards Research and Applications Center, University of Colorado.

70.     Turoff, M., “Past and Future Emergency Response Information Systems,” Communications of the ACM, April 2002, 45:4, pp. 29-33.

71.     Turoff, M., S.R., Hiltz, M. Bieber, B. Whitworth, and J. Fjermestad, “Computer Mediated Communications for Group Support: Past and Future,” in J. Carroll ed., HCI in the New Millennium, 2001, Addison Wesley.

72.     Turoff, M., “Virtuality,” Communications of the ACM, September 1997, 40:9, pp. 38-43.

73.     Turoff, M., “Computer Mediated Communication Requirements for Group Support,” in Ron Baecker ed., Readings in Groupware and Computer Supported Cooperative Work, 1993, Morgan Kaufmann Publishers, originally published Journal of Organizational Computing, 1990, 1:1.

74.     Turoff, M., S.R. Hiltz, A.N.F. Bahgat, and A. Rana, “Distributed Group Support Systems,” MIS Quarterly, December 1993, pp. 399-417.

75.     Turoff, Murray and S.R. Hiltz, Computer Based Delphi Processes, in Michael Adler and Erio Ziglio, editors., Gazing Into the Oracle: The Delphi Method and Its Application to Social Policy and Public Health, 1995, London, Kingsley Publishers, pp. 56-88.

76.     Turoff, M., “Party Line and Discussion: Computerized Conference Systems,” Proceedings of the International Conference on Computer Communications, 1972, pp. 161-171, IEEE Press.

77.     Turoff, M., “Delphi Conferencing: Computer Based Conferencing with Anonymity,” Journal of Technological Forecasting and Social Change, 1972, 3:2, pp. 159-204.

78.     Turoff, M., “Delphi and Its Potential Impact on Information Systems,” Proceedings AFIPS Fall Joint Computer Conference,” 1971, 39, pp. 317-326.

79.     Van de Walle, B., and M. Turoff, “Towards group agreement: the significance of preference analysis,” Proceedings of Eurofuse 2001, Workshop on Theory and Applications of Preference Modeling Granada, Spain, pp. 85-92.

80.     Van de Walle, B., “A relational analysis of decision makers' preferences,” International Journal of Intelligent Systems, 2003, 18:7, pp. 775-791.

81.     Vatis, M.A., “The first line of Defense: Tools and Technology Needs in the Aftermath of September 11, 2001,” Draft Report, Institute for Security Technology Studies, May 28, 2002,http://www.ists.dartmouth.edu.

82.    Wang, Yuanqiong, Zheng Li, M. Turoff, and S.R. Hiltz, “Using a Social Decision Support System Toolkit to Evaluate Achieved Course Objectives,” AMCIS 2003 Proceedings, Association for Information Systems, http://www.aisnet.org, last accessed 9 February 2003.

83.     Waren, Yvonne, “Collective Learning, and Collective Memory for Coping with Dynamic Complexity,” Cotech Workshop for ECSCW 95, SIGCHI Bulletin, July 1996, 28:3, pp. 34-41.

84.     Weick, K., “The collapse of sensemaking in organizations: The Mann Gulch disaster,“ Administrative Sciences Quarterly, 1993, 38, pp. 628-652

85.     Weick, K., Sensemaking in Organizations, Thousand Oaks, CA: Sage, 1995.

86.     Wenger, E. C., and W.M. Snyder, “Communities of Practice: The Organizational Frontier,” Harvard Business Review, January 2000.

87.     Wilcox, Richard H. and R. Kupperman, “An on-line Management System in a dynamic environment,” Proceedings of the 1st International Conference on Computer Communications, 1972, IEEE Computer Society, pp. 117-120.

88.     Zmud, R.W. “Individual differences and MIS success: A review of the empirical literature,” Management Science, 1979, 25:2, pp. 966-979.

89.    Zuboff, S., In the age of the smart machine, New York: Basic Books, 1988.