应急指挥由简入繁遵从循序渐进

        【中安网讯】从两千年前的匈奴入侵到今天的地震台风、SARS、H1N1，从两千多年前的万里长城到今天的政府应急指挥IT系统建设，应急事件改变了，但应急事件的属性和特点没有改变；应急方法和建设内容改变了，但需要具备的能力和需要考虑的方面却非常类似。以古观今，也许对现代应急指挥系统的建设有别样的启发。
 

　　图1 应急事件与应急事件特征

　　在今天我们谈到应急指挥IT系统的时候，最终极的一个困惑就是描述不清楚它的边界。“应急指挥”的外延可以非常宽广，深入社会的各个维度，所以曾经有人说：应急指挥IT系统是有史以来最复杂的IT系统。从技术实现的角度看这个结论，这无疑是一个灾难，因为这意味着这个史上最复杂的IT系统几乎是不可实现的，至少是成本的黑洞。但凡是应急系统，都具有养兵千日、用兵一时的特点，连长城都不例外，所以不能堆砌过于高昂的成本而“无急”时无用。因此，应急指挥IT系统究竟要建成什么样子，核心正如标题，简单or不简单，是道难以回答的选择题。

　　简单or不简单，代表了当今对应急指挥的两种典型建设思路。一种是往低看，往简单化建设。在极简的情况下，应急指挥IT系统可以剥皮去肉、只剩骨架，简化为一套视频会议加上一个应急指挥办公场所的显示大屏，这种冠以“应急指挥”名头的建设，在真正的应急事件到来的时候，是起不到太大的作用的；另外一种极端是往高端看，往复杂化建设。智能分析、智能联动、模糊决策，各种软硬件有条件的都装上，没条件的创造条件也要装上。这种方式的弊端一目了然，一是技术条件未必具备，二是成本高昂。面对这样一个课题，极度简单和极度复杂都不是可取之道，我们必须回归到问题的本质，即：

　　“应急指挥IT系统”和“应急指挥”二者的关系是怎样构成的？

　　“应急指挥IT系统”最核心要解决的问题是什么？

　　“应急指挥”和“应急指挥IT系统”正如抵御外敌和万里长城的关系一样，前者是目标，而后者是手段。手段服从且同步于目标。“应急指挥”不是一个技术的概念，而更接近一个管理的概念。

　　若以效果来反朔，则有效的应急指挥应该至少具备这样的特征：信息掌握足够准确、反应足够迅速、应对措施足够全面得力。如果以管理的三段论来划分，则应急事件发生时包含信息汇集、决策生成和指挥执行三个关键阶段。再放大一点看，一个完整的应急指挥大周期不应局限在应急事件爆发后的一段时间内，而是由应急前的信息汇集分析阶段、应急事件发生时的应急指挥阶段、应急指挥实施完成后的信息积累和分析阶段构成一个完整的循环，每一次应急事件的发生和处置不仅针对当次的环节，更应自动成为下一次类似事件的经验值和素材库。

　　比如2003年发生的SARS疫情对于今年的H1N1疫情来讲，就构成了信息和预案的先导输入。从手段和目标的关系来论，“应急指挥IT系统”狭义的看应该是支撑应急事件发生的三大阶段，而广义的看应该是支撑应急全流程的三大阶段。就前者而言，映射到技术实现上，重心在于与应急相关的信息获取、通讯、通讯支撑。而对广义而言，则有更多的资源和力量应该放在非应急事件爆发状态下的信息获取、信息分析等相关方面。必须看到的一点是，应急指挥不是一个一次性的系统，从狭义逐渐演进到广义，避免好高骛远不可实现，也避免鼠目寸光短视近视，是很多时候，能够把应急指挥真正落到实地的关键。从另一个角度，“应急指挥”和“应急指挥IT系统”一个是形而上的，一个是形而下的。形而下的东西往往受限于现实的技术条件，在一定时间内，必须划定一定的实现边界，否则是不可操作的。IT系统领先、管理措施没有跟上，IT系统就会形同虚置；IT系统过于低下，管理措施无法获得足够的技术支撑，就会导致动作变形、结果滑坡。此外，IT系统从规划到建设到运行，需要较长的时间周期，如果以规划作为时间点基准，则还必须考虑到“应急指挥IT系统”相对于应急指挥管理操作制度应具有一定的提前性，否则在上线运行的时候就会反过来成为管理操作的桎梏。