IT服务管理(ITSM)已经存在了很长时间，而IT管理人员提出了一个关键问题：采用IT服务管理(ITSM)要从哪里着手?
Boomi公司全球企业营销主管Myles Suer表示，在他在2005年入职Peregrine Systems公司时，令他惊讶的是， Peregrine Service Manager的嵌入式数据库是非关系的数据库。Peregrine公司成立于1981年，比IBM将DB2推向市场还要早几年。1989年，随着ITSM的引入，英国政府的ITSM和ITSM的许多概念得到了明确的更新。IT基础设施库(ITIL)本身已经进行了一些更新。例如，Suer是ITIL第3版的审阅者。去年刚刚推出的版本4旨在使ITSM更容易与DevOps、敏捷和精益工作方法集成。问题是ITSM要从哪里着手?这是Suer提出的问题。
公共云使用和DevOps如何改变ITSM?
首席信息官Rick Osterberg认为：“部署ITSM的最大好处就是使所有人都使用一种通用语言。在云计算/DevOps环境中，仍然需要每个人都了解P1事件和P4服务请求之间的区别。” 首席信息官Joanna Young对此表示认同，并建议说，“ITSM的基本要素仍然相关。我认为它们是很好的指导和基础。如果我们想谈论ITSM系统的实现。将ITSM构建到交付过程中可以鼓励/推动关于持续运营支持的对话。” 首席信息官Carrie Shumaker认同Young的观点。她指出，“理解所有组件、依赖关系仍然至关重要。此外，对于重大事件，制定流程和进行沟通也是至关重要的。最后，变化仍在发生，而且仍会令人兴奋。” 首席信息官David Seidl说，“人们在ITSM的工作地点以及如何执行ITSM的细节可能会改变，但我认为核心概念仍然存在。用户可能需要为DevOps进行敏捷所需的相同类型的更改，而当进行另一项更改时，将需要再次进行更改。假设用户所做的一切都使用DevOps，但通常情况并非如此。与其相反，在很多时候是在像ITIL这样的组织或其他混合/组件化模型中将DevOps作为容器。”
DevOps改变了ITSM的面貌
Seidl声称，“DevOps可以改变ITSM的面貌。尽管ITSM的票务方面可能仍然存在，但它提供的过程以及部署能力的方式和位置将具有更轻的治理结构。” 首席信息官Jason James说，“我们已经从服务器扩展到虚拟机扩展，现在又转向了云蔓延。当令人困惑的账单来自供应商时，ITSM可以有效地用于配合部门的请求和批准，以帮助了解云计算资源的使用。ITSM可以帮助用户进行内部审核。” 首席信息官Isaac Sacolick对此持有不同的观点。他认为，“服务台主要是处理最终用户的计算。但是，随着数字化转型使技术/数据业务变得至关重要;服务台的重要性只会增加。在冠状病毒疫情发生之后，ITSM就变得至关重要。”话虽如此，Sacolick建议变更管理现在必须成为转型管理的一部分。此外，配置管理数据库(CMDB)一直混乱不堪，现在考虑到云计算弹性计算、无服务器和SaaS时，这几乎站不住脚。考虑到这一点，Sacolick说：“ITSM应该为用户提供支持，为应用提供帮助，并弥补实施/选择不佳的技术。” Splunk公司首席信息官Andi Mann对此表示：“DevOps通过使用数据和人员来解决问题，从而解决了问题。如今，服务台已经成为记录系统。”
尽管如此，Forrester公司的ITSM/DevOps分析师Charlie Betz建议：
(1)桌面支持(边缘计算/最终用途计算)永远是一回事。
(2)对于大规模数字化来说，信息管理是一个重要问题，但配置管理数据库(CMDB)从来不是解决问题的办法。在配置管理数据库(CMDB)是否有用的问题中，有一些子集是有用的。
(3)将变更管理作为一个主要的自动化过程需要保留。
(4)变革咨询委员会不是必不可少的，如果在其他地方进行协调，则可以取消。例如，它可以是Scrum of Scrums议程中的常设项目。
从历史上看，ITIL将ITSM分为离散流程。是否需要更系统的观点?
首席信息官Jason James说：“ITSM需要现代化。需要实现更多的自动化，以便在需要时提供更大的自助服务，包括云计算服务。此外，所有工作流程都必须设计为支持响应能力，并消除不必要的批准和延误。对人工智能驱动的ITSM的需求是存在的，但我们仍有一段路要走，使之成为现实。” Seidl对此表示，“我一直将ITIL视为有用的语言，不一定是完全不同的孤岛。概念与实现的现实意味着这些都是模糊的，并且该语言可作为一种句柄，可以确保我们在行动时离目标很近。” Osterberg说：“这仍然是语言的问题。不管其后端是什么，仍然有中断、更深层的问题、更改和事务性请求，这些都是交叉和重叠的。并需要有一种共同的语言来解释这一切。”
ITIL事情太复杂了吗?
Sacolick认为，ITIL使事情变得过于复杂，并且术语和过程过多。如今的工具，尤其是集成的DevOps和Agile以及AIOps极大地简化了事件支持。而Agile与扩大规模无关。这是关于文化和思维方式的。组织需要做出明智的决定，以决定Agile团队可以在何处进行自我组织以及制定了哪些标准。因此，他说：“ITSM应该专注于云计算世界中的主要问题，并且正确地采用自助服务。” 对于这一点，James建议说，“ITSM必须高度自动化和可移动。如今，ITSM的许多功能都可以用机器人来完成。这些包括密码重置、设备配置和基本的问答。这些都可以实现自动化，以便服务台团队可以集中精力处理更复杂的问题。许多现有的ITSM解决方案仍然缺乏这些功能。聊天机器人如果得到有效的实施，比起等待或与人员交谈要轻松得多。去年我与亚马逊公司的几次互动都是通过他们的机器人程序完成的，每次我提出的问题都很快得到回应。”
关于ITSM中还包含哪些功能，还收到了不同的答复：
Young说，“ITSM需要在问题、变更、服务请求、资产、供应商和配置方面拥有主数据管理和集成流程”。然而，Pitt将清单缩小为“事件、问题、变化和请求”。首席信息官Carrie Shumaker从更全面的角度看待事情，他说，“变更导致了事件发生，并且周而复始。我认为统一因素是服务，有时是配置管理数据库(CMDB)元素。” 关于变更管理，Betz说：“问题是我们将变更管理等同于变更咨询委员会(有时是批准的)。CAB是效率低下、节奏受限、同步的面对面专用通信通道。需要有更好的方法来解决协调问题。” 尽管如此，首席信息安全官Michael Oberlaender建议说，“添加一个专注于价值创造/价值链的端到端概念是绝对必要的。我们在ITSM中做了很多没有增加足够价值的事情。”
在ITSM中，对于消费性数字商务服务的目录是否有着广泛的作用?
Seidl说：“对于某些组织来说是这样的。诀窍在于挑选和选择适合组织、目标和能力的组件和模型。我看到越来越多的组织未能推出ITSM，更多的组织成功地解决了如何工作的问题。” 首席信息官Martin Davis认为，“这取决于组织定义ITSM的方式。它的范围应该只限于帮助人们解决与IT相关的问题、服务，还是比这个范围更广。那么其边界在哪里?随着业务的发展和IT的发展，如果组织有很强的纪律性和远见的话，目录是一个很好的方法，如果发生脱节，而且是对任何事情都有例外的组织，那么就很可能出问题。而组织需要成为一家以流程为导向的公司，才能使这项工作取得成功。” Young有相似的观点，他说，“这是可能的。然而，许多组织甚至没有能力或负担得起。对他们来说，DevOps和敏捷性仍然是一种新生事物或愿望清单。问题是，供应商正在采取什么措施来提供一种途径，特别是为中小型企业提供这种途径。” 同样，James认为，“ITSM可能发展并与更多系统和云计算服务交互，从而在提供更多洞察力和响应能力的同时提供更多服务。”但仍然存在一个悬而未决的问题，那就是，服务目录是否成为API和消耗品业务服务的目录? Sacolick建议：“从SOAP到微服务，IT团队一直在尝试通过许多技术来开发消耗性数字业务服务的目录。我相信，除非有简单的方法，否则它不会大规模发生。”
结语
显然，随着越来越多的工作负载转移到公共云，IT运营的许多方面都在经历变化。ITIL和ITSM并没什么不同。很多首席信息官认为ITIL和ITSM有做更多事情的机会。未来五年，ITSM将经历更多的变化。
Constellation研究公司的Dion Hinchcliffe表示，ITSM必须并且将不断发展，以便与DevOps保持良好的协调。这意味着要包含所有IT技术，包括SaaS、公共云和影子IT。这意味着，ITSM将成为一个积极的支持和管理网络，同时使选择和竞争成为可能。这样做将创建一个高度可用的方法，包括潜在扩展的服务目录概念。
