【IT168 专稿】
滴...滴...滴...系统的报警声突然响起。“快，快，系统报错，1分钟后就有4驾飞机需要降落或起飞，问题必须尽快解决。”第一次做服务交付经理，我和另一位服务交付经理守在监控屏幕和客户经理身边，除了催他们赶紧将影响航班正常起降的故障通知服务台，不知道自己还能做些什么？！
这是一个模拟体验活动的现场——BMC飞机场模拟工作坊。这一角色扮演体验活动的目的就是让每个人都能贴近BSM的流程和服务管理，亲身体验ITIL的非常好的实践。BSM不是一个漂亮的口号，它是经过检验的、实实在在的有效方法。在这个活动里，我们12个人分饰4种不同角色，在机场运营总监的带领下，经营着一家小机场。随着业务的发展，我们这个不大的机场现在也有了4座航站楼，同时为2家不同的航空公司提供客运和货运服务。同时，机场还提供十几种额外的附加服务，比如雷达监测服务、安检服务、行李装运服务等，支撑这些服务的就是机场复杂的IT系统。
和所有机场一样，我们机场的目标是盈利！要想实现这一目标，我们最重要的任务就是确保飞机能够正常起降。为此，机场各个工种的工作人员必须尽全力保证各项服务和各个设备的正常运行，从而保证每一驾飞机的准时起降，最终赢得应有的收益和用户的肯定。
简单介绍一下角色：
客户经理：每一家航空公司都有一名专职客户经理，代表各个航空公司的利益，可以看作机场运营团队的客户（甲方）。他们关心的是航班的正常起降，以及航空公司的收入，因此，客户经理会密切关注机场服务的可用性，如发现任何影响航班正常起降的故障，他们会立即通知机场服务台，以便第一时间解决问题。
机场服务台：服务台是连接业务和IT的桥梁，他们负责把描述故障的业务语言转换成IT语言，并提交给IT专家。
IT专家：即技术部门，负责建造和维护IT基础架构。根据机场IT系统的配置管理图，IT专家需要在最短的时间内定位并解决服务台上报的问题故障。
服务交付经理：负责整个流程的沟通有效、流程规范；同时掌握着IT预算，在必要时向厂商购买解决方案和更换设备等；服务交付经理还要负责变更的顺利实施，从而最终确保机场服务的可用性达到服务协议的标准。
机场运营总监：负责机场的整体运行情况，以及与用户的沟通。
从航班安排表上，可以清楚地看到每隔1分钟甚至半分钟，都有会3～5架不等数目的飞机需要起降。在这段时间内没有解决机场系统出现的问题，每架飞机都可能造成几千至上万不等的损失。整个模拟的过程从客户经理发现问题，并将问题类型、紧急程度、解决期限、问题影响到的航站楼号反映给服务台；服务台则根据对应表，将问题类型转换为IT代码，并将其传达给技术部门；技术部门则根据问题代码以及影响到的航站楼号定位问题，并予以解决；只有在给定期限内成功解决问题，才能避免系统整体崩溃，并成功起降航班。
第一轮：IT管理就是救火队
第一轮模拟从14：00准时开始，很快第一个警报响起。客户经理看着屏幕上警报闪烁的位置，开始寻找问题所在。1分钟之后，飞机就将降落，但问题工单还没有到达服务台。服务交付经理只能着急地在旁边看着。好在，很快，服务台将问题代码等相关信息送达技术部。技术部三位工程师一起围上来，手忙脚乱地在沙盘上定位问题，进行解答。这边厢问题还没答案，那边厢警报此起彼伏，很快问题工单雪片一般飞来，技术部这边一团乱麻......
眼看着有一个问题很快就到解答期限而迟迟没有答案，操作员老师提醒服务交付经理：“应该赶紧解决这个问题，否则造成系统整体瘫痪，损失更大。你们不是还有技术费用吗？可以买答案。”一语惊醒梦中人！“怎么买？”“看你要永久答案，还是延迟时间。永久答案要1000元，延时要300元。”衡量一下，我们购买了永久答案。这个问题虽然解决，可是其他问题一个接着一个。我们耳边回想着一架一架飞机被取消的声音。
此轮演练中，作为服务交付经理的职责之一，我们还需增加一个新应用——生物检测系统。通过航班安排表，首先我们选定一个更新“窗口”，这个时间段里没有飞机需要起降，同时也足够更新系统之用。其次，服务交付经理需注意在“窗口”到来之前的10秒提前通知操作员，添加上该应用。当然，我们也没有忘记通知技术部，将该应添加到机场IT系统的沙盘中，以方便他们定位问题。就在我们以为此次新增应用工作滴水不漏时，该新增应用系统亮起警报，这次我们才发现既没有通知客户经理也没有通知服务台有此项新增应用，结果从源头上他们无法确定问题类型，更无法传递到技术部门来解决。唉，更新应用居然都没有通知客户，真是无语！
第一轮结束，整个机场的成功起降率只有63%，亏损金额就不提了。居然还成功起降了63%的航班，我们以为80%都被取消了呢。只见整个过程中，两个服务交付经理在客户经理、服务台、技术部和操作员之间跑来跑去、大呼小叫，还是无法阻止飞机被取消的厄运。
对第一轮模拟进行回顾总结，我的最大感受就是：角色选错啦。本以为服务交付经理是最清闲的活，掌握着预算，买买解决方案（答案）就行，没想到却是一个救火队，哪儿有问题就冲到哪儿，上传下达、口干舌燥。对应不到问题代码要找我们，问题定位错了也要找我们，解决了问题要通过我们给操作员输入解决，没解决问题也要通过我们来购买答案......
哦，这就是IT管理！
第二轮：流程构建就是雪中炭
第二轮开始前，我们进行了四项改进措施。
第一，明确分工。虽然在第一轮开始前，老师已经提醒过我们要进行分工，但我们两眼一抹黑，完全没有明确的方向应该如何来分工。经过一轮演习，哪些环节容易出现问题，哪个环节是瓶颈，逐一浮现。上一轮最混乱的两个组织——服务交付经理和技术部——被明确地分工，服务交付经理A负责操作台、客户经理和服务台之间的沟通，服务交付经理B负责服务台、技术部和操作台之间的沟通。技术部则派出工程师A专门作为问题工单接口，进行问题定位，并分配问题给其他工程师。
第二，预警与延迟。客户经理主动提出问题预警需求，在操作员的提示下，我们才发现问题延迟和问题预警对于期限紧迫的故障其实是相当有意义的。于是，在第二轮模拟中，首先就花钱买了3个故障预警，并约定：如果技术部反馈一级优先的问题难以解决，优先考虑购买延迟。
第三，变更管理。鉴于上一轮没有做到位的配置/变更管理，本轮模拟开始前，作为服务交付经理的我就和所有相关人员，从运营总监、客户经理、服务台、技术部直至操作员说明了本次新增应用的名称、代码、功能和时间。而本次更新窗口，选择在17分30秒开始到19分30秒的一个2分钟的空挡时间。
第四，问题管理。从流程上，问题工单将起到重要作用，并特别突出问题的优先级。同时，我们也发现故障有重复出现的可能，将已出现问题的解决方案记录形成知识库，能极大地帮助我们提高解决问题的速度，节约时间，减少损失。
第二轮开始，各部门有条不紊地展开工作。警报响起，客户经理迅速确定问题类型、影响航站楼号和严重程度，并通过服务交付经理A转给服务台。服务台根据对应列表，将问题转换为相应代码，通过服务交付经理B转给技术部。技术部接口人根据代码确定具体问题，并分配问题给技术部人员予以解答。如果能够顺利找到答案，则有驻守在技术部的服务交付经理B告知操作员，若答案正确，操作员会告知问题解决、警报解除，同时技术部接口人会将题号和答案统一记录到知识库；若答案错误，操作员会告知答案错误或问题定位错误，则技术人员继续寻求答案或重新进行问题定位。如果一时不能顺利找到答案的，服务交付经理B和A之间会进行沟通，根据问题紧急程度，决定是否需要延时或者购买答案。
很明显，以上四项改进措施首先让现场安静了很多，不像第一轮大家都在跑来跑去，大声喊话；其次就是，运营总监闲了下来。本以为最悠闲的总监在上一轮也忙得够呛，不停地在各个部门询问情况，大家却都忙着顾不上理他；这一轮流程顺利地竟让他喝起了可乐，还不时地各处慰问一下大家，果然有了总监的派头。
第二轮结束，整个机场的成功起降率上升至79%，并且开始盈利啦。而解决问题的平均时间也从8分30秒大幅下降至2分30秒。每一个参与其中的人都非常、非常有成就感。
同样，对第二轮模拟回顾总结，各个部门都对理顺的流程感到满意，同时也对一些工作中的小细节提出了修改建议。比如，大家质疑，为何本轮我们解决了报警的大部分问题，也多次购买延迟，但飞机的成功起降率和实际盈利却并不高呢？80％是客户要求的成功起降率的最低值，这一指标我们都没有完成。
统计数据和图表帮助我们看到，问题恰恰出在我们错误地使用了延时。更有效的做法是综合考虑到问题的优先程度以及后续影响航班的收益金额，在下一轮航班起降前（可能是1分钟也可能是半分钟）就马上决定是否购买延迟。如果能够及时购买延迟，则最开始的2分钟是不会有飞机受到影响的，而问题也可能在这2分钟内得以解决，这样将能极大的提高成功起降率和盈利。所以，是服务交付经理没有把本就不多的预算用好。
第三轮：IT协调业务是锦上花
第三轮开始前，两番热烈的讨论占用了中间短暂的休息时间。
第一场讨论集中在与业务部门（即客户经理）签订的服务协议上。前两轮，由于大家对成功起降率和平均问题解决时间无甚概念，两次服务协议都是与用户签订的最低标准。鉴于大家还是处于磨合期，客户也未对服务提出苛刻要求。随着这两轮的彼此熟悉与成绩进步，客户对本轮的服务协议提出了更高要求：99％的成功起降率和2分钟的平均解决问题时间。对于这两个指标，不论是技术部还是服务交付经理都觉得很难达到，特别是平均解决问题时间。不算因问题难易而不同的思考答案时间，光是从问题出现到写工单、定位问题的流程1分钟都不够，2分钟的平均解决问题时间简直是不可能完成的任务。经过与客户经理的“讨价还价”，最后服务协议定为：总共96架飞机至少有90架成功起降，平均解决问题时间则是2分15秒。
第二场讨论则围绕着是否要扩容、是否要灾备展开。在这一场讨论中，显然技术部的人最有发言权，而最后拍板的则是服务交付经理和总监。临时客串设备厂商的老师信誓旦旦表示，扩容肯定能解决很多问题，而相比于1000元的花费一定是物超所值。于是，我们首先购买了扩容方案。然后，围绕是否要灾备，对哪台服务器灾备又展开激烈辩论。考虑到前两轮中，服务器S多次出现严重问题，最终灾备方案的对象落在它的身上。但是，我们只有4000元的预算，考虑到购买延时、预警和预留一个永久答案的花销，所剩无几，根本不够购买灾备方案的。这时，操作员又适时提出建议，根据系统统计数据，其实整个系统中有一个路由设备是完全冗余的，可以将其卖个厂商，已抵灾备方案的费用。很快，这个建议获得所有人的认同，无用的路由换回了灾备。
第三轮很快开始。果然，在整个过程中，由于扩容和灾备系统，好多本该发生问题被成功拦截。而由于知识库的建立，很多时候，问题一经定位，无需思考答案，技术接口人直接从知识库中就能找到答案，连技术人员都开始喝起了可乐。但是，新的问题又暴露出来。比如，由于服务交付经理的失误，用于扩容的非常好的时间窗口被错过，只能等待下一个时间窗口的到来，而显然这段时间没有让扩容方案发挥应有的作用，加大降低了购买这一方案的价值。
最后，我们以成功起降88架航班，平均解决问题时间58秒的成绩结束了最后一轮模拟演练。没有达到成功起降的目标让我们遗憾，而超额完成的平均解决问题时间连我们都不敢相信，确实预警、延时、扩容、灾备等手段的应用起到相当大的作用。相信如果我们还有第四轮、第五轮的演练，一定会有更多进步，也会发现其他问题，最终在不断地改进中趋于完善。
IT从未如此高效和轻松
这是一场虚拟的模拟演练，却让参与者全心投入其中，既感受到气氛的紧张也体会到合作的愉快，并通过思考和教训而有所收获。机场模拟运营过程中，各个部门间的相互依存，以及保持机场正常运转所需要的沟通交流、所使用的方式方法以十分真实的方式展现了业务与IT之间的联系。在这个让人体验到真实的模拟游戏中，每一位参与者都真切感受到业务和IT部门面临的诸多问题，也实际体验了通过IT管理的非常好的实践，应用适当的工具和方法，最终解决这些问题的过程。
从最初的一头雾水，到后来的融会贯通，作为服务交付经理，我从内心而不是口头上体验了一个流程的构建对于提高效率、管理成本和保持一致性的重要作用；体会到业务需求与优先级别、IT服务的密切协调对业务价值扩展的深刻意义；甚至领略到预算的合理使用对服务可用性的重大影响。这确实是一次有价值的体验课程，是一次ITIL理论与实践完美结合，让我们真正开始了解如何从业务的角度管理IT和服务。
相关背景：
作为首个获得“ITIL流程合规”证书的企业，BMC的BSM机场模拟课程试图通过让参与者亲身体验业务部门在日益依赖IT来满足企业和业务需求的今天所面临的真实挑战，来分析BSM和ITIL非常好的实践如何帮助企业改进IT服务、客户满意度和生产效率。ITIL提供了一个通过构建流程从而提高效率、控制管理成本和保持一致性的框架；而BSM则通过IT延伸和实现IT与业务的密切协调来扩展这种价值。
“ITIL流程合规”证书是唯一一个由英国商务部（OGC）和APM集团（ITIL的所有者和官方授权者）共同认可的证书。获此认可意味着，产品和方案都将遵从ITIL（IT基础架构库)）非常好的实践，并切实推进IT流程改进和效率提高。
