第二轮：流程构建就是雪中炭

    第二轮开始前，我们进行了四项改进措施。

    第一，明确分工。虽然在第一轮开始前，老师已经提醒过我们要进行分工，但我们两眼一抹黑，完全没有明确的方向应该如何来分工。经过一轮演习，哪些环节容易出现问题，哪个环节是瓶颈，逐一浮现。上一轮最混乱的两个组织——服务交付经理和技术部——被明确地分工，服务交付经理A负责操作台、客户经理和服务台之间的沟通，服务交付经理B负责服务台、技术部和操作台之间的沟通。技术部则派出工程师A专门作为问题工单接口，进行问题定位，并分配问题给其他工程师。

    第二，预警与延迟。客户经理主动提出问题预警需求，在操作员的提示下，我们才发现问题延迟和问题预警对于期限紧迫的故障其实是相当有意义的。于是，在第二轮模拟中，首先就花钱买了3个故障预警，并约定：如果技术部反馈一级优先的问题难以解决，优先考虑购买延迟。

    第三，变更管理。鉴于上一轮没有做到位的配置/变更管理，本轮模拟开始前，作为服务交付经理的我就和所有相关人员，从运营总监、客户经理、服务台、技术部直至操作员说明了本次新增应用的名称、代码、功能和时间。而本次更新窗口，选择在17分30秒开始到19分30秒的一个2分钟的空挡时间。

    第四，问题管理。从流程上，问题工单将起到重要作用，并特别突出问题的优先级。同时，我们也发现故障有重复出现的可能，将已出现问题的解决方案记录形成知识库，能极大地帮助我们提高解决问题的速度，节约时间，减少损失。

    第二轮开始，各部门有条不紊地展开工作。警报响起，客户经理迅速确定问题类型、影响航站楼号和严重程度，并通过服务交付经理A转给服务台。服务台根据对应列表，将问题转换为相应代码，通过服务交付经理B转给技术部。技术部接口人根据代码确定具体问题，并分配问题给技术部人员予以解答。如果能够顺利找到答案，则有驻守在技术部的服务交付经理B告知操作员，若答案正确，操作员会告知问题解决、警报解除，同时技术部接口人会将题号和答案统一记录到知识库；若答案错误，操作员会告知答案错误或问题定位错误，则技术人员继续寻求答案或重新进行问题定位。如果一时不能顺利找到答案的，服务交付经理B和A之间会进行沟通，根据问题紧急程度，决定是否需要延时或者购买答案。

    很明显，以上四项改进措施首先让现场安静了很多，不像第一轮大家都在跑来跑去，大声喊话；其次就是，运营总监闲了下来。本以为最悠闲的总监在上一轮也忙得够呛，不停地在各个部门询问情况，大家却都忙着顾不上理他；这一轮流程顺利地竟让他喝起了可乐，还不时地各处慰问一下大家，果然有了总监的派头。

    第二轮结束，整个机场的成功起降率上升至79%，并且开始盈利啦。而解决问题的平均时间也从8分30秒大幅下降至2分30秒。每一个参与其中的人都非常、非常有成就感。

    同样，对第二轮模拟回顾总结，各个部门都对理顺的流程感到满意，同时也对一些工作中的小细节提出了修改建议。比如，大家质疑，为何本轮我们解决了报警的大部分问题，也多次购买延迟，但飞机的成功起降率和实际盈利却并不高呢？80％是客户要求的成功起降率的最低值，这一指标我们都没有完成。

    统计数据和图表帮助我们看到，问题恰恰出在我们错误地使用了延时。更有效的做法是综合考虑到问题的优先程度以及后续影响航班的收益金额，在下一轮航班起降前（可能是1分钟也可能是半分钟）就马上决定是否购买延迟。如果能够及时购买延迟，则最开始的2分钟是不会有飞机受到影响的，而问题也可能在这2分钟内得以解决，这样将能极大的提高成功起降率和盈利。所以，是服务交付经理没有把本就不多的预算用好。