成功的BSM(业务服务管理)意味着，IT的角色从过去纯粹的技术运营，向与业务和用户合作转变，并有助于让IT部门摆脱成本中心的形象。
■ 沈建苗 编译
在很多IT管理杂志和厂商的营销资料里，经常提到BSM(业务服务管理)这个话题，而且大家对BSM的理解并不完全一致。那么，BSM到底是个噱头，还是具有真正的成效？用户该如何着手开展BSM？怎样让BSM的成效最大化？
BSM众说纷纭
1. 厂商们的说法
BMC软件公司的Peter Armstrong可谓是BSM方面的先驱，他认为："用户买不到即开即用的BSM，BSM是一种理念，而不是一套产品。"
但大多数IT厂商通常是从基础架构管理的角度来看待BSM。厂商A表示： "BSM的任务就是管理服务的健康状况。"厂商B表示： "BSM的任务是解决当前的棘手问题。"厂商C表示： "BSM专注于实时服务的健康状况和完整性。"
上述这些观点的一个共同之处就是，都关注流程自动化，并从IT部门内部衡量面向资源的服务(Resource Facing Services，RFS)。遗憾的是，拿IT服务来说，内部衡量标准只能预测潜在的质量和价值，而衡量实际业务价值和服务质量的最终标准还是最终用户。所以，单单预测性的内部衡量标准不足以衡量IT服务的价值和质量。
2. 用户们的说法
从用户的角度来看，业务价值是IT部门在独特的时间点创造的，这个时间点通常是指用户使用服务。无论厂商喜不喜欢，用户在使用IT服务时对服务的看法是客观现实的。如果用户觉得某项服务具有高价值、但又觉得这项服务没有达到预期的质量级别，他们就会另找厂商来获取这种服务。
考虑到这一点，要准确衡量IT服务实际产生的业务价值，惟一的办法就是与最终用户进行坦诚的交谈，这是无法用流程自动化软件来获取的，也是无法通过在数据中心后台召开孤立的规划会议来衡量的。
3. 谁对谁错？
用户直接面对的IT产品是面向客户的服务(Customer Facing Services ，CFS)。普通的电话服务和电子邮件就是CFS的两个典型例子，用户能察觉到CFS，也知道自己在使用这种服务。CFS是由RFS组成的，而RFS是一些IT系统，把这些系统组合起来就形成了CFS。用户在使用时察觉不到RFS，也不直接面对它们。
尽管RFS的内部流程自动化是BSM成功的一个必要方面，但是RFS是为支持高价值CFS而存在的。正因为如此，任何BSM项目的起点都应当是CFS，而不是RFS，也不是支持RFS的那些系统或流程。BSM要真正取得成功与面向业务的坦率交谈有很大的关系，这种交谈侧重于实现IT服务的业务价值最大化，同时使用最少量的IT资源。
可以这么说，成功的BSM能实现业务与IT相协调，还会让CIO在企业上下广受欢迎。
BSM的成效
成功的BSM拥有许多近期和长期的成效。
其中最明显的近期成效就是，让IT部门摆脱成本中心的形象。BSM可以充当一种机制，以便用非技术的业务术语向业务部门表述IT战略及IT资源如何分配。这有助于IT部门和服务提供方摆脱由来已久的成本中心这个形象。BSM便于进行富有成效、面向业务的交谈，并且提供了IT与业务相协调的确凿证据。借助BSM，业务与IT相协调变得可以实现、可以衡量了。
成功的BSM还便于IT部门和项目经理通过与用户共同评估IT服务的业务价值，搞清楚哪些服务是必须的、哪些只是用户的愿望，从而进行目标需求管理。我们开始明白，如果只是因为存在差距或客户提出了请求，未必就意味着有必要投入资源。
在经济衰退期间，BSM还有一个成效凸显出来，那就是更加客观地重新分配有限的资源，把有限的资源从低价值服务中抽取出来，又不至于疏远了用户。有时候，"够好"就很完美了。从业务价值和财务的角度来看，显然不是每个差距都是值得弥补的; 也不是每个快速见效的措施都值得采取的。即便我们能做到，也并不意味着应当去做。
BSM意味着IT的角色从过去纯粹的技术运营向与业务和用户合作转变。BSM方面取得成功的那些人大都经历了这样一种转变： 原来是支持业务用户的IT经理，由于懂得如何实现技术资源的业务价值最大化，变成了值得信赖的业务合作伙伴。
确保BSM成功的四个步骤
1. 定义服务
如果你明确了CFS的内容，并且分析了CFS、RFS及支持性流程和资源之间的关系，清楚的层次关系就会显露出来。你应当很容易地表述清楚后台支持CFS的活动之间的联系。正如IT基础设施库(ITIL)、信息及相关技术的控制目标(COBIT)、共享信息与数据模型(SID)及其他众多标准和最佳实践反复强调的那样，这是所有服务改进计划的基础。
这一步得到的成果为下一步构建服务目录、实施配置管理数据库(CMDB)、洽谈服务级别协议(SLA)以及进行成功的服务组合管理提供了素材。
2. 评估服务的业务价值
可以使用系统化、可重复的方法评估CFS的业务价值，不应该只用经济衡量标准来评估业务价值，还应当考虑其他因素。不应该一味地关注交付成本，还要对服务进行结构化的风险评估，以此来衡量"未能交付"的成本。通常来讲，较高的风险意味着较高的业务价值。
除了了解用户的观点外，还可以趁此大好机会来搞清楚哪些服务是必须的、哪些只是用户的愿望，这样就能揭示出哪些服务是最重要的、为什么。这需要IT人员与用户进行坦诚的交谈，并且站在客观的立场，积极主动地倾听用户。目的倒不是要证实IT部门对服务价值的猜测，而是了解与IT服务有关的业务价值，并结合财务预算对这些预期目标进行排序和管理。
3. 衡量服务质量和绩效
鉴于服务已定义完毕，并且根据业务价值进行了排序，现在可以衡量质量和绩效了。这时我们需要结合之前提到的两种观点： 应当从内部和外部同时衡量绩效，寻找能力(内部)和质量(外部)方面存在的差距，这一点必不可少。外部差距的重要性再怎么强调都不过分，对服务提供方来说，预期目标(包括主观和客观)的表述出现问题常常是带来麻烦的根源。
服务质量、能力成熟度集成模型(CMMI)、六西格玛和ITIL都认为，差距比较大意味着对用户而言的质量和效用都比较低。从另一方面来看，这些差距也为改进提供了潜在的机会。
4. 确定服务改进计划，并证明其必要性
现在是实际检验BSM的时候了。我们已经定义了服务内容，并根据业务价值对服务进行了排序，进行了差距分析以找出不足，还罗列了我们需要开展的一系列活动。这自然引出了下一个问题----该从哪里开始入手？
首先应当为部署或改进高价值的服务分配资源，同时把资源从低价值服务中抽出来。如果我们结合差距分析数据、服务排序数据(基于业务价值的)以及服务层次，差距和服务之间的关系就会显露出来。根据这些数据，我们就可以把有限的资源集中到部署业务价值很高的新服务或改进业务价值很高的现有服务上，并根据从业务部门的最终用户那里获取的数据来做出这种决策。
转播
分享
淘帖
()
