以业务服务管理提高IT运营的效率

申请免费试用、咨询电话：400-8352-114

席卷全球的金融海啸在给各个企业带来营收和利润冲击的同时，也对企业的IT运营提出了更高的挑战。停止新增IT雇员，减少IT投入，降低IT运营成本等成为了CIO们正在面对的难题。

与此同时，随着IT和业务的融合更加紧密，企业对于IT运营又有了一系列更高的要求：IT必须能灵活地响应业务需求，例如新业务的推出，企业的并购和合并，某些低效业务的退出和出售，都要求IT部门能快速做出响应；同时，在国际金融危机时刻，业务的稳定性和可持续性直接影响到客户和供应商的信心，而一次信心的缺失，就可能让企业在危机中倒闭或者遭受沉重打击，因此对IT服务可用性的要求比以往更高。

CIO解决这些问题的有效途径是从现有的IT人员和基础架构中挖掘出更多的业务价值。这就要求CIO对于IT的运营绩效有着更深刻的洞察力，能在战略上把握IT投入的方向和重点，并全面掌控IT运营对业务带来的影响。但实际的情况却是企业的IT投资越来越大，CIO却越来越无法掌握真实的运营情况，他必须依赖很多会议和报告才能粗略地了解现实中业务受到的影响。

对几种情况的举例可以帮助大家理解为什么会造成这种现象：比如说，孤立的组织、应用和系统往往使用户无法从整体上全面了解企业运作情况。如果拥有跨越这些不同系统的复杂流程，就可能无法对这些流程进行查看或者了解它们的影响。而且，如果依赖于众多供应商的话，每个供应商都有自己的系统，对业绩的跟踪将变得更加困难。

解决这些问题的有效手段其实是业务服务管理解决方案，很遗憾的是，尽管国内业务服务管理的概念相当热门，但多数企业还是停留在系统管理和资源监控的层面，目前还缺乏真正的成功案例以借鉴。笔者结合IBM在国外的成功经验以及目前正在国内实施的项目尝试做一些分析，希望能帮助更多的企业在困难的时刻能够成功变革，真正提升IT部门的运营效率。

业务服务管理的实施重点

为什么业务服务管理项目很容易“挂羊头，卖狗肉”呢？除了下一节要谈到的实施困难外，很大程度是由于客户在软件销售人员的诱导下，在实施过程中把关注点又重新放在了IT资源的监控上，忽视了业务服务管理项目的实施目标。业务服务管理项目的实施应该围绕着三个重点进行，决不能在实施时避重就轻，重新走入系统管理项目越做越复杂的误区。

第一个重点就是虚拟化。所谓虚拟化就是要屏蔽IT基础架构层次的复杂性和技术细节，使得IT组件和服务能从业务的角度重新诠释和展现。从IT发展的长期目标来看，IT基础架构未来将被设计成和水、电一样，让用户可以方便地使用，云计算、SOA等新技术对IT服务的虚拟化同样有着很高的要求。而业务服务管理中虚拟化的实施关键在业务服务的建模，以及业务组件和IT组件的映射关系。

第二个重点是帮助确定IT工作的优先顺序。前面提到了CIO需要从现有的IT人员和基础架构中发掘更多的业务价值。在资源有限的情况下，要达到此目的，CIO需要充分的管理信息帮助他了解业务受到的影响。因此业务服务管理不是要把IT事件呈现给管理层看，而是要按照业务影响和故障的严重程度，帮助CIO一目了然地了解各项业务的重要性和紧迫性。

第三个重点是加强与业务部门沟通的透明度。随着信息系统越来越复杂，业务部门往往更加难以了解业务行为是如何在信息系统中实现的。我们在实践中发现，由于这种不了解以及IT部门缺乏对外的SLA（服务水平协议），业务部门对IT的期望值往往差异很大，难以协调。业务服务管理通过将业务流的可视化，可以更好地帮助IT部门和业务部门沟通，获得较高的客户满意度。

业务服务管理的实施困难

前面谈到了业务服务管理在实施时需要关注的几个重点，但在实际的项目实施中，我们发现中国企业还存在一些特殊的情况，使得业务服务管理在企业难以获得满意的效果。

一、IT运营部门和开发部门的分割。在中国的电信、金融等大型企业，分管IT运营和开发的领导往往具有职业上的竞争关系。和国外的很多企业不同，中国企业的IT运营部门往往缺乏懂得业务的技术人员。笔者帮助外企实施IT服务管理项目时发现，外企IT部门和业务部门的人员经常可以相互调动，但国内的企业这方面的人员交换就比较少。当然，这个情况正在好转，有一些电信企业和银行已经开始了这方面的尝试。

由此导致的问题就是在IT运营部门实施业务服务管理时，往往很难对业务进行正确的建模和分析。目前我们的解决方法主要是通过CIO的推动，使开发部门的人员能积极参与业务服务管理项目；或者是帮助客户进行一些组织架构的设计，使得运营部门由技术导向逐渐向业务导向过度。

二、业务系统的变更非常频繁。这也是中国企业的一大特色，例如移动运营商经常搞的资费套餐和促销活动，银行推出的新中间业务或者是突发性交易高峰，都使他们的IT系统需要经常进行升级扩容或者新版本的应用上线。这直接导致了业务服务管理的服务模型和相关规则有可能需要经常性调整，以正确应对基础架构的变化。笔者在项目中经常会帮助客户完善变更管理的流程，并建立周期性的回顾机制，以使业务服务管理系统总是能正确地分析IT故障的业务影响。

三、应用监控的实施挑战。缺少了应用监控的业务服务管理，就像一个人只有躯壳而没有灵魂。在实际的项目中，由于缺乏开发部门的配合以及合适的应用管理工具，往往只能做到系统和中间件的监控告警可以及时进行传递，而对于业务运行最为重要的应用程序却束手无策。

目前在国内比较流行的做法是选择模拟终端机器人的方式对应用进行测试，以验证交易是否能顺利进行，这方面的软件也比较成熟。但此方法的问题是即使发现了应用故障，也需要长时间的人工诊断，才能明确应用故障的位置，而且由于国内的软件开发商往往缺乏维护方面的考虑，所开发的应用往往缺乏诊断代码和相应的日志，这也大大延长了应用故障恢复和修正的时间。

如何正确实施业务服务管理

针对前面的困难和实施重点，有没有一套成熟的方法论可以帮助企业减少实施业务服务管理的风险，带来更多的效率提升呢？IBM全球信息科技服务部结合全球业务服务管理项目的实施经验，对业务服务管理项目的生命周期和实施内容都进行了归纳总结。这里重点介绍一下业务服务管理实施的几方面内容：

业务服务管理项目往往包含有系统监控、事件管理、CMDB（配置管理数据库）实施、业务建模（穿插在事件管理和CMDB实施中）、管理界面设计五大内容。大多数企业其实都购买了各种系统监控的工具，但国内的现状是这些工具都是在部门级甚至只有个别人员使用，工具之间缺乏整合，也无法提供业务服务需要的管理信息。因此业务服务管理项目中的系统监控并不是从零开始，而是结合企业现有监控工具的使用情况，按照业务服务管理的要求进行优化和增强。

事件管理是业务服务管理项目的实施难点。由于不同厂商的监控工具告警方式和告警内容的不同，有一些企业甚至还缺乏事件管理的概念。所谓事件管理，其实包含四个部分的实施内容：首先是事件的标准化和整合，它是要将来自不同事件源的事件，按照标准的格式重新进行封装，并传递到集中的事件处理器；其次是重复事件的压缩，我们都知道如果故障没有被解决，那么事件将按照一定的频率反复发送，所以对于重复的事件需要重新定义它的传递和处理方式；再次是相关事件的关联和过滤，一个大型的数据中心，其每天的原始告警数目可以多达数十万条，对所有的原始告警进行人工处理这是不可想象的。因此具有较低业务影响的绝大多数告警需要被过滤掉，由于IT的基础架构相当复杂，因此一个事件往往会引发相关的IT组件纷纷发出事件告警，对这些互相关联的事件也需要重新定义传递和处理的方式，以保证初始事件被准确呈现；最后则是根源事件的分析，对于经过前三个步骤处理的事件，其数量已经大为减少，但究竟故障的源头在哪里？还需要根据IT组件的关系和业务模型进行分析。

最后再简要地介绍一下剩下的三部分内容。CMDB目前在国内还没有实施特别成功的客户，其缘由一部分来自于商业化的CMDB软件成熟度和功能的限制，另一部分则是由于CMDB即需要自动采集IT设备的配置信息，以保持和生产环境的同步，同时又需要包含设备责任人、资产价值等无法自动采集产生的内容，在自动采集和人工干预之间目前还没有找到特别合适的办法。

业务建模相对来说反而好一点，通过对业务应用自上而下地分析，其产生的模型基本还是可用的，但如何维护业务模型反而成为业务服务管理项目实施完成后的问题。目前我们正在探索将业务建模和CMDB结合起来，尽可能在IT组件的配置信息中保存业务模型的关系，这种方法已经取得一些成果，但还需要在后续项目中进一步优化。管理界面的可视化现在主要是通过实时仪表盘（Real-time Dashboard）技术进行展示，从已经实施的项目效果看还是很不错的。

总结下来，业务服务管理首先是一个管理项目，它着重于帮助企业从现有的IT资产中发掘更多的业务价值。其次，选择富有经验的实施团队可以帮助企业降低实施风险和成本，真正达到IT运营效率的提升，帮助企业在变化多样的业务环境中更灵活、更高效地实现业务服务的目标。（来自互联网）