关于ITSM

IT服务管理(IT service management，简称ITSM)是一套为最终用户设计和交付IT服务的政策和程序。其范围超越了IT支持/帮助台，扩展到持续改进IT服务以满足业务需求所需的所有监控、管理和故障排除功能。

ITSM起源于IT基础架构标准库(IT Infrastructure Library，简称ITIL)——由英国政府部门中央计算机和远程通信局(CCTA)在20世纪80年代末开发的一套IT服务管理标准库，旨在提高IT资源的利用率和服务质量。

ITSM的三大要素：

• 人员：设计服务，定义流程;
• 技术：实现流程的自动化、电子化，并监测服务;
• 流程：对服务的规划、开发和部署进行管理和支持;

有效的ITSM需要确定哪些技术组件(如服务器和数据库)支持哪些应用程序，正确地将这些知识文档化并调整优化支持流程。随着时间的推移，这些关系和依赖项正变得愈发复杂，ITSM可能会变得过于昂贵，并且过于关注技术而非业务。

ITSM常见错误

以下是ITSM可能出错的一些常见方式以及相应地解决方案：

1. 好高骛远，搞假大空

哥本哈根机场IT资产及服务管理负责人Christian Hjortjaer解释称：

ITSM实践过程中切忌好高骛远，不要贪多求快。以我们自身为例，在使用ServiceNow的ITSM管理平台时，我们先从核心ITSM(例如事件管理和变更管理)开始，并将使用范围限制在笔记本电脑和软件等平台内。随后再逐步将其扩展到其他服务，例如门禁卡和停车许可证等。可以肯定地说，如果我们从一开始就提供所有服务，一定会惨败收场，因为这个过程需要大量时间和资源提供支持。

Hjortjae补充道，不过，我们在创建用户知识库方面确实是操之过急了，以至于未能制定适当的升级和维护流程。在处理问题的过程中，筛选不准确和过时的信息并予以纠正可能都需要耗费大量的时间和精力。

Gartner高级研究总监Chris Matchett建议：

从核心功能入手，并定期对其进行审查。在开始更高级的活动(如人工智能)之前，一定要确保这些成为IT组织文化的一部分。务必要先记录和优化流程，然后再考虑自动化它们。如果流程本质上是存在缺陷的，那么自动化也只会一遍又一遍的输出错误的结果。

Hjortkjaer的第一步行动就是利用ServiceNow来创建一个通用数据源，通常被称为配置管理数据库(CMDB)，具有与业务应用程序的详细记录链接。例如，使用CMDB来追踪哪些服务依赖于哪些服务器，有助于IT人员判断哪些服务中断是最关键的，以便快速恢复它们并及时通知用户相关问题。

Applus(一家检测和测试服务公司)CTO Ruben Avila Calvo表示，使用ITIL框架做ITSM的客户应该确保创建一个清晰、定义明确的IT服务目录和管理流程。ITIL的应用前提是您对流程、角色和职责都有明确的定义，其中每个阶段都有完善的文档记录，保持职责分明，并且有适当的流程来确保服务按约定的服务级别协议(SLA)交付，否则会因服务问题被导向错误的人员而导致更高的成本和更低的服质量。

2. 忽视业务

人们很容易将ITSM的核心聚焦在“IT”，但其实它的真正目标是提供业务服务。未能在设计ITSM时充分考虑业务因素，并且无法用业务语言来描述其技术优势，可能会影响ITSM的采用率，并增加使用过程中的混乱度和困难度。

Hjortkjaer表示：

如果我在业务部门，我不会关心IT有多少个故障要处理，我只关心我的应用程序——我的应用程序有多少个故障，我应该如何解决？我需要给CEO提供有意义的报告，这需要我把故障和正确的配置项关联起来，然后将其联系到正确的业务应用程序，并说明这些服务如何帮助改善整个机场的运营。

Corteva公司业务服务集成负责人Kshitij Bahadur介绍称，Corteva使用ServiceNow ITSM解决的其中一个挑战就是将不相干的IT组件关联起来，以便应用程序所有者不必为了给业务构建应用程序而四处去追服务器、数据库、和防火墙团队，这样无疑会浪费大量时间。

亚利桑那州Gilbert镇的代理CTO Eugene Mejia和他的团队将改善该镇1600名员工的体验作为其ITSM活动的关键业务驱动力。他和IT领导团队利用月度员工调查来评估新开发功能的成功度，例如Web界面或是支持远程工作的移动应用的质量。他们使用Cisco Unified Communications Manager和Webex Contact Center来管理服务请求以及故障排除服务的呼叫队列。

Forrester分析员Will McKeon-White表示，对那些需要给ITSM提供资金支持的C级高管来说，这种对员工体验的关注非常具有说服力。

3. 无效的沟通

不明确的沟通会增加向业务部门解释ITSM的价值、合理组织ITSM活动、为系统部署设定预期以及获取资金支持的困难度。

Hjortkjaer建议使用CMDB将IT组件映射到业务应用程序，将这些应用程序的所有权分配给IT和业务负责人，并要求这些负责人来解释每个应用程序对业务的作用、如何最好地使用它以及何时需要更换它。

Service Corp International公司电信及IT支持总监Thomas Smith建议，要对日程安排保持坦率。他解释称：

我们曾经犯过的，并且还在犯的最大的错误之一，就是说‘我们将在三个月内搞定它。’结果四个月后，每个人仍然希望再有三个月。你需要了解自己的ITSM工具和服务的所有不足，然后告诉业务流程负责人‘我们有解决它的计划’。

Calvo表示，服务级别协议(SLA)中定义的条款，例如用BMC的Helix ITSM平台所创建的那些，可以帮助设定预期并降低“认为所有问题都应该尽快解决”的用户的挫败感。

McKeon- White认为，清晰的沟通还可以帮助业务负责人就定制化和由此产生的维护难题达成共识。每一个人都试图以自己理解的方式来满足组织的需求，但这可能会与客户成果、降低风险管理等方面产生冲突。

Smith说，在ITSM支持工具上(例如他使用的Ivanti Neurons for ITSM平台)描述清楚用户究竟需要什么，同样非常重要。例如，这可能包括用户在他们的W-9表格上看到的内容，或者他们所说的“屏幕总是崩溃”是什么意思。这些需求可能难以确定，例如，一个人力资源工作者可能不理解故障和服务申请之间的区别。为了解决这些问题，Smith与IT和业务用户协商并分享关于这些术语和定义，以确保每个人对每一个需求都充分理解并在优先级上达成一致。

4. 过度定制

McKeon- White认为，过度定制是他在ITSM项目中遇到的最大挑战之一。客户会根据“他们认为的正当理由”去修改ITSM系统。随着对系统修改次数不断增加，并且那些进行修改的员工相继离开公司，想要重构这些变更或者理解为什么进行修改，几乎成了不可能的事，这也使得ITSM系统的管理和升级变得愈发困难……

问题不在于被定制的单一功能，而是所有这些定制如何协同工作。鉴于ITSM平台中各组件之间接口的数量和复杂性，你可能没有办法实施你需要的变更，因为这会牵一发而动全身。

Bahadu也同意这一观点，并表示：

我们曾经犯过的，并且还在犯的最大的错误之一，就是说‘我们将在三个月内搞定它。’结果四个月后，每个人仍然希望再有三个月。你需要了解自己的ITSM工具和服务的所有不足，然后告诉业务流程负责人‘我们有解决它的计划’。

5. 缺乏可持续性

Matchett表示，ITSM不能作为一个有时间限制的项目来一次性完全实施。缺乏持续的管理和培训会降低ITSM的效率，尤其是在业务需求和ITSM工具本身发生改变的情况下。

大多数ITSM工具以“软件即服务”(SaaS)的方式提供，这就意味着由软件供应商而非客户来维护底层基础设施。但是McKeon- White认为，客户应该安排一到两个人员来进行持续的优化工作，无论是服务客户、提高弹性、降低变更风险、更好的事件管理流程，还可以确保每一个协助解决问题的人都能获得准确的信息，并理解正在进行的工作状态。

Hjortkjaer认为，ITSM需要对用户进行有关新流程的持续教育和培训工作，尤其是在迁移至更先进的平台时。这可以展示很酷炫的功能，以及ITSM可以对你日常工作产生的积极作用，从仪表板到报告到快捷方式……你可以通过很多方式设置自己的ITSM界面，以提升你的工作效率和日常使用体验。

和许多IT活动一样，服务管理要做到最好，需要围绕业务需求进行设计，清晰明确沟通价值，不要制造长期的、隐藏的“技术债务”，并随着时间的推移不断完善管理机制。

本文翻译自：https://www.cio.com/article/305067/5-itsm-hurdles-and-how-to-overcome-them.html