[p=30,2,center]学习资料：IT运维管理社区专家讲堂直播300期视频回放

[p=30,2,center]

站在甲方的角度思考服务目录

引言：服务管理体系梳理可以从以下几个方向开始:服务目录，服务报告，用户体验，服务流程。可能工作内容相同但是效果不同，我选从服务目录开始。年初完成了从乙方到甲方的角色转变，看待问题的角度有些改变，在这里站在甲方的角度和大家探讨服务目录知识模块，还希望能够抛砖引玉，和各位一起交流，共同成长。

文：IT运维管理社区水杉之镜，于2012年7月20日
IT运维管理社区：http://www.ITILxf.com/

作者微博：amyanshan

1.什么是服务目录

谈到信息化的价值一定是以给用户提高了什么，增加了什么，减少了什么为依据的。而不是信息中心服务器的数量是多少，带宽是多少，管理的如何先进，信息部门在做工作汇报的时候要说的是对组织核心业务的支撑和促进作用，如何为组织成员提供生产力工具，这时需要有一个目录来列出信息中心可以为用户提供的服务，这些服务是否收费，获取服务的流程，在申请服务后多久可以获得服务，服务的可用性指标怎么承诺的，服务的支持时间是怎样安排的，这就是业务服务目录的雏形和动机。

现代企业越来越庞杂，一所高中就有30个业务系统，100台服务器，网络设备1000台；IT技术需求面更为广泛，从系统管理、网络管理、桌面管理、互联接入管理、安全管理、服务管理、云计算与虚拟化技术都需要安排人员和工时进行学习和掌握，IT支持人数呈几何倍数增加，基础设施维护支持和设备维保等工作量越来越大，更多组织会选择外包给第三方，这时需要对乙方的服务质量进行统计和监督，同时信息部门也需要知道自己的信息资产的容量和可用性信息，传统方法是在事件记录表中增加一列用以记录你关注的事件类别的故障次数，无故障时间，故障数量，平均修复时间，单位时间内的可用性是多少，这一列信息就是我们的技术服务目录，服务于信息中心所管理的信息资产的可用性监控、资金投入分析决策，供应商付款依据等。

2.业务与技术服务目录之间的关系
2.1.阶段1：没关系

最初始的状态下，两者没有直接联系和对应关系，分别是给用户提供的应用列表和服务合同签订内容。两者的关系体现在事件记录的业务字段和类型字段，用以进行服务报告的故障信息统计。

如下图所示，业务环节就是业务服务目录，最后可以统计某个业务系统支持服务的可用性和修复时间等信息。

故障类型就是技术服务目录的体现，作为乙方和甲方承诺故障解决时限要求的统计信息，SLA监测和核算的依据，如SLA中承诺操作系统类故障响应时间为10分钟，解决时间为30分钟，从而尽可能的保证分拣业务的可用性。

2.2.阶段2：部分包含关系

随着组织对服务目录管理的掌握和运用，管理成熟度不断提高，技术服务目录和业务服务目录的关系会越来越紧密，大家会意识到业务的可用性仅仅是监控到了还不够，需要有技术能力的保障，这时候就要求技术服务目录被业务服务目录引用，二者建立包含或者对应关系，但是此时还不是最理想的状态。

以下引用微博u/1844258170的一段话帮助大家理解二者之间的关系。（技术服务目录是业务服务目录的组成部分。例如，保险行业的“车险保险业务服务”是IT部门提供的一个业务服务项目，由“保险应用服务”“两核接口服务”“集中支付接口服务”等若干应用服务提供支撑（技术服务的一种）；每个应用服务又由“计算资源服务”“存储”等组成）

2.3.阶段3：依赖关系

业务服务目录与技术服务目录由包含关系演变为依赖关系也是必然趋势，简单解释就是一对多和多对多的关系，下面转载两幅图和大家分享下，首先是BMC自己的技术服务目录和业务服务目录关系及其应用图

ITILv3中讲解服务目录章节的一幅图，也是比较简明的大家可以一目了然的看出二者之间的关系，暂时还没实践过，希望有机会去摸索和尝试。

3.服务目录的作用

以下我只是站在甲方的角度考虑服务目录的作用，如果站在乙方的角度会有不同的理解。

首先是通过服务目录梳理和监控，可以对供应商的服务指标进行监控和量化，获得真实的服务质量过程，支撑服务报告有效性；

通过服务目录监控数据，对服务资源能力进行合理的评估，为IT投资提供的基础数据支撑；

通过对服务目录的可用性监控结合业务可用性要求建立合理SLA要求，做到SLA的持续改进；

通过服务目录的梳理和监控完善供应商合同范围及工作内容，建立服务提供商相竞争的基准；

通过服务目录的梳理驱动IT组织内部变革，梳理内部服务的流程，梳理信息部门与供应商直接的关系；

梳理出清晰的业务服务目录，是未来服务计费等精细化管理的前提条件。

4.创建服务目录

通过对现有应用及IT资源进行统计，按照业务类型进行分类，详细描述其特征及获取方法，承诺的服务级别，在用户的角度，关注用户的需求，以用户的语言通过邮件，手册，网站等方式将业务服务目录推送给用户。

对支持业务系统进行统计和分析，并结合供应商服务合同梳理技术服务目录，作为事件类别的字段，进行监控和管理。

通过服务台、自助服务网站有效记录服务目录内服务项的使用频率，使用习惯，不断优化服务目录内容和展现方式。

组织结构允许的条件下可以设服务目录管理经理的岗位，负责服务内容的收集，整理和发布工作，保证及时更新服务目录内容，增加一个信息部门与业务用户的交互界面。

创建的服务目录在条件允许的情况下应该是用户可以直接使用的，而不是简单的一页纸或者一个静态网页，用户在信息中心门户上浏览服务目录后可以直接申请该服务，或者支持跳转到服务申请页，简化用户服务申请过程，提升客户体验。

服务目录发布版被确定下来后，应采用有效的监控手段，对服务级别进行衡量，并根据组织特性定期对服务可用性进行报告，与用户承诺的服务级别相一致。

5.忠告

脱离技术谈管理，那不是管理那是捣乱；脱离业务谈价值，那不是价值那是扯淡；脱离用户谈服务，那不是服务那是欺骗。

总结：脱离技术勿谈管理，脱离业务勿谈价值，脱离用户勿谈服务！

谢谢分享，回头细看：）

好贴，强烈支持，先回复，后看

学习了，，

好帖