[原创]IT服务留单超标快速响应方案总结

说明：这份方案总结是对一次应急方案启动的事后评估，目的是为了改进应急方案。

1、信息传递

留单超标快速响应方案（以下简称“方案”）自开始启动，至2007-09-24 16：00解除，历时6天。×××部对方案的执行过程做了一次跟踪。此次跟踪从信息传递、组织协调、流程规范、状态控制、应对措施和资源调用等方面进行总结。

从留单响应方案来看，对于信息的传递虽有要求但是细致程度还不够。比如，信息应该以何种方式进行传递并如何反馈等等。方案的描述上，信息传递多是单向的操作。在“方案”实际执行过程中也产生了信息从一个岗位传递到另一个岗位没有后续反馈带来的沟通问题。

2、组织协调

缺少组织协调的另一个弊端是对“方案”规定的流程缺乏监督。这一点在执行5.5监督阶段条款时很突出地表现出来。“响应式任务管理在计划实施过程中，每一小时向快速响应方案审批者进行状态更新（每小时通报当前留单情况）”实际情况是无人按照条款执行，也无人对此进行监督。

应急事件的组织协调很可能会牺牲局部的快速及时，对此大家仍然存在不同的认识。究竟是片面强调快速反应，还是有计划，有组织地有限快速进行风险控制？这需要事先的充分沟通才能够达成行动上的一致。

3、流程规范

“方案”中并未明确具体的应对流程。虽有文字和流程图的简要描述，但流程的执行缺少明确的指导。在执行过程中相关人员还需要和“方案”的编制人进行再次确认。在流程这一块的分析里，还发现部分流程没有考虑到实际情况，教条要求留单超标一定要走计划任务管理这个环节，结果带来的不仅是效率降低，而且计划任务管理这个环节所做的计划都是无用功。因为计划任务管理目前不具备安排派单计划的能力，其制定的计划无法作为被动式任务管理派单的依据，最后仍然依靠被动式任务管理的经验派单。

4、状态控制

“方案”在讨论会上确定了应急状态的启动和停止标志。但在实际执行过程中发现应急状态的停止标志存在弊端，而且对于停止的标准判断存在两条不同的说法“当日16：00时，留单量小于15单”和“当日工作结束后至次日工作开始前，留单量小于15单，×××部计划审核者确认后，宣布快速响应期结束”。无论哪一个条款在实际工作中都会因为当日上午的正常留单积累造成“快速响应期”始终无法达到结束标准的可能。这也是此次快速响应期一直延续6天才得以解除的原因之一。同时也会影响因“快速响应期”而暂停的其他工作，如保养。

在实际执行过程中无法区分正常留单和超标留单是“方案”的一个问题所在。因为“方案”对于留单超标这个风险的识别和控制都是基于一种假设情况：在当日某时的留单数量。过于简单的识别和控制手段在面对复杂多变的留单情况显得有些力不从心。

根据留单超标发生、发展和解除的周期分析，“方案”在不同的阶段应该有不同的、动态变化的识别方式和应对措施。而不是采用单一的、固定不变的判断标准。

5 应对措施

由于识别标志和控制手段的单一，因此“方案”对于留单超标发生后的应对措施也是略显单薄。“方案”执行中采用的应对措施依然和日常派单一致。对于库存数量任务管理无法得到准确的数据，工程师需要向资源准备和××仓库两个渠道领取资源等等。在人力资源出现急缺的情况下派单原则和日常派单没有区别，没有体现出应急方案和日常处理的不同。

综合前面4点所提到的信息传递、组织协调、流程规范和状态控制，留单超标的应急方案应该采用逐级对应的原则进行设计。不同的留单状态应该有不同的应对措施。

6 资源调用

“方案”中对于资源的涉及，仅考虑到××××部的配件资源准备。对应急状态下的人力资源考虑不足。在设计“方案”时没有考虑到当工程师都外派之后出现应急状态的情况应该如何处理。这次的“方案”演练就发生在此类情况之下。因此出现即使及时启动了应急方案但是由于人力资源的短缺导致有单派不出的情况。

在分析了以上6点之外，大家对“方案”的认识也存在差异。具体执行人员认为这次的应急启动没有体现出应急状态和日常状态的区别，反而在某些流程上比日常处理更加复杂。而在配件资源和人力资源存在的一些目前无法解决的问题也导致了应急方案在配件需求和人力需求方面无法做到快速及时，影响了执行人员对此次“方案”最终作用的看法，进而产生没有必要设计应急方案的认识。

另外，在解释“方案”的执行中发现仍有一些流程和操作需要向编制人咨询，这从一个侧面说明“方案”未能对应急方案做到完整、准确的描述。

综上所述：“方案”的演练让我们开始做到IT服务管理的有章可循。虽然在实际执行过程中看到了种种不足，但是出现的问题为“方案”进一步改进提供了参考。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友