适用于高速团队的 ITSM
寻找解决 ITSM 系统升级季节难题的方法
产品负责人从传统 ITSM 系统升级的替代方案中学到了什么。
我曾是一个 Scrum 团队的产品负责人，该团队使用传统的 ITSM 系统为多种服务管理实践开发功能。在日历年的最后一次冲刺结束时，我的团队享受了一次创新冲刺，在这次冲刺中，我们可以学习和尝试新的功能。我利用这次创新冲刺查看了我们 ITSM 系统的新版本。乍一看，似乎有很多新功能。但仔细了解后会发现，这些新功能对我们的利益相关者并无用处，而且会导致更多的技术债务。
发现我们的传统 ITSM 系统存在固有的支持性问题后，我意识到我有两个选择：接受这个事实并准备好胃药和头痛药，或者寻找更强大、更灵活的解决方案。
想到要与我们的流程负责人和其他利益相关者举行多次会议，我就开始头疼。想到解释新版本的内容、我们开发日程的中断以及所有这些新工作最终只会产生很小的有用影响，我就感到压力很大。不管我们能使用多少功能，升级季节的繁琐流程和工作效率损失都是一样的。
升级传统 ITSM 系统的痛点
对于那些还没有处理过这个问题的人来说，我描述的一些内容可能显得有些夸张，所以下面是我团队升级流程的快照，其中涉及许多任务，我将其提炼成预发布、发布和发布后三个阶段，分为 11 个大步骤。
光是看这个我就觉得累，而且它甚至都无法全面概括整个流程。管理升级的团队花费大量时间和精力来解决组织变更管理问题。终端用户对每年两次的服务部署中断感到沮丧，他们认为这种中断几乎没有什么价值。
我曾经认为只有我的团队在升级方面遇到了问题，但是在参加了用户组会议和阅读博客之后，我意识到痛苦的升级流程无处不在。一些客户抱怨升级花了八个多星期，并抱怨这降低了他们团队的工作效率。
在某些情况下，组织甚至会“重启”其传统 ITSM 系统以简化升级。例如，客户仍在努力弄清楚如何使用 ServiceNow 的 Next Experience 用户界面，而 2022 年 3 月圣地亚哥版本中就已采用该用户界面。一些企业客户选择关闭该功能，直到他们能够确定对用户的影响。
在我寻找解决方案时，我发现有解决这个问题的灵丹妙药——利用合作伙伴服务进行升级、放弃任何系统修改、使用逐个自动化测试功能等。不幸的是，这些选项都不够全面，有些只是向另一个方向引入了更多工作。
寻求救援 — ITSM 系统的更好方法
在我看来，我有两种选择。我可以接受我们 ITSM 系统的固有挑战，并在我的办公桌抽屉里放些抗酸剂和布洛芬片剂，也可以寻找更稳健、更灵活的解决方案。灰心之下，我使用 Google 搜索，阅读分析师报告并咨询 ITSM 领域的朋友，这使我找到了 Atlassian 的 ITSM 解决方案 Jira Service Management。
坦率地讲，我怀疑它能否缓解我们的问题。我已使用企业 ITSM 系统很多年，我还使用了几年 Jira Software。因此，我确信 Jira Service Management 无法解决我们的问题。
我探察了 Jira Service Management 中的“资产”功能一段时间，配置和加载数据看似很容易。然后我开始创建项目和服务任务群组。经过短短几个小时的配置（并浏览了全部文档），我就开发了一个工作服务目录和服务台，其中包含 IT 资产和 CI 以及重大事件功能。
Jira Service Management 融合了敏捷开发方法中的元素，例如“从当前开始”，并提供开箱即用的 ITIL 实践。显然，Atlassian 采用了以团队为中心的方法，而不是侧重于工具的解决方案。
Atlassian 的 Jira Service Management 升级方法 | 传统 ITSM 供应商的系统升级方法 |
|---|---|
| 敏捷与瀑布式 | |
| Atlassian 遵循敏捷开发方法进行 Jira Service Management 升级，优化灵活性、协作和效率。 | 传统 ITSM 供应商的系统升级方法 传统 ITSM 供应商使用瀑布式方法进行升级，侧重于结构化顺序发布。 |
| 时间表变更与所需的年度更新 | |
| Jira Service Management 客户可以通过设置环境所需的发布跟踪来控制变更速度。连续产品会在变更和功能发布后立即收到变更和功能。捆绑产品在每月的第二个星期二以群组形式收到变更。 | 传统 ITSM 供应商的系统升级方法 传统 ITSM 供应商通常每年提供两次包含新功能的软件发布。 |
| 正在进行的功能发布与可用的缺陷修复 | |
| Atlassian 的方法通过更短、可预测的发布周期；更小、更高质量的代码集；以及更透明、响应更快的功能交付，为客户提供更高的商业价值。 | 传统 ITSM 供应商的系统升级方法 传统 ITSM 供应商根据需要/可用情况提供代码补丁和修补程序。通常，这些补丁和修补程序包含缺陷修复，但没有新功能。 |
| 松散耦合的架构与紧密耦合的代码集 | |
| Jira Service Management 基于松散耦合的架构，其中各个组件是相互独立构建的。团队可使用松散耦合的应用开发独立部署和扩展的功能，从而提供更有效的代码交付/升级。 | 传统 ITSM 供应商的系统升级方法 传统 ITSM 系统架构紧密耦合，因此功能僵化且相互依存。当一个组件变更时，整个应用中就会存在更多变更的“多米诺效应”，这会增加整体代码修改和风险。 |
| 真正的云产品与孤立的 SaaS 产品 | |
| Jira Service Management 专为 Atlassian 的云平台设计和创建，因此客户可以通过嵌入式安全性、内置合规性、多个实例（每个产品最多 150 个）和简化的按用户许可来放心地进行扩展。 | 传统 ITSM 供应商的系统升级方法 传统 ITSM 系统通常设计为在本地运行，供应商只需远程托管应用即可。这些不是真正的云解决方案，无法为您提供与真正的云系统相同的好处（扩展、升级、定价和安全）。 |
一种更健康的 ITSM 系统升级方法
谈到升级问题，Atlassian 计划进行技术改进，这样当有新功能可用时，可以将功能无缝引入平台和产品。Atlassian 的云路线图是公开的，因此客户可以随时看到即将发生的情况。Jira Service Management 基于云的系统意味着客户可以持续或按计划使用这些功能。客户可以：
- 订阅每周发布说明，获取有关即将到来的变更的最新说明
- 创建一个隔离的环境（又名沙盒），在投入生产之前尝试功能变更
- 通过设置生产环境的发布跟踪（连续和捆绑）来控制他们的变更速度
- 从提供连续改进的少量逐步更新中获益
由于 Jira Service Management 基于松散耦合的代码集，因此它提供了更高的代码灵活性/可重用性以及更高效的应用升级。
我们都希望加快数字化转型，以便我们的组织能够“更智能、更轻松地开展工作”。我发现使用 Jira Service Management 的敏捷逐步变更和改进升级方法，我们能够以更持续、更快和无中断的节奏继续验证发布并与最终用户互动。
如果您正要踏上数字化转型之旅，我建议查看每个应用的核心架构和实施方法以及总拥有成本。考虑您正在努力实现的业务计划，选择一个既能满足您的需求，又能为每次客户互动增加价值的系统。
详细了解 Atlassian 的服务管理方法《Atlassian for ITSM 完整指南》。