itsm（it服务管理）建设通常被认为仅仅把几个核心itil流程设计好，并通过工单系统来承载流程的审批和流转即可。这种方式可能是大多数企业的最初做法，用于满足运维管理的合规性需求，以确保工作过程有审批和记录可查。在这种要求下，一个itsm系统确实只要具备了提单、审批、处理等基本的流程功能就已足够，相当于一个电子工单系统。
然而，随着企业数字化转型的深入，对it运维和服务的效率要求日益提升。如果企业继续沿用传统的工单系统思维来构建itsm，仅仅考虑合规而没有兼顾效率，那么长远来看容易陷入比较被动的局面。因此，如何在建设初期就打好itsm的基座，能灵活应对未来业务侧数字化转型不断发展所带来的挑战就非常重要了。
本文将介绍什么是平台化思维，以及如何在itsm中应用平台化理念，以更好支撑数字化时代下的服务管理建设。
01. 关于平台化思维
1）什么是平台化思维？
通俗来讲，平台化思维就是在构建业务场景之前，先把“舞台”搭好，而不是一开始就堆场景功能。平台应该具备两个核心能力：
- 允许业务场景横向扩展，而不需侵入到系统核心代码。
- 支持将公共能力抽象到下层，供上层场景复用。
实际上，这种理念并非新颖独特，是相当常见的。操作系统、paas、业务中台等，各种新名词背后本质上都是同样的逻辑，也就是软件工程中经常提到的“高内聚、低耦合”的设计原则，用于构建模块化的、可维护性和可扩展性更高的软件系统。
2）itsm为什么要平台化？
① 系统复杂度因素
如果一个软件系统所需承载的业务不复杂，功能很简单，那当然不需要考虑“平台化”这个事情。过往itsm建设的复杂度在于管理规范的建立和落地，而不在工具系统。也就是如何基于itil实践来设计贴合自身管理诉求的流程，并能够很好落地运转，这是管理者头疼的问题。咨询团队会给出大量的文档和规则，而这些大部分并不需要落地到系统中。对itsm工具的要求更多是类似工单系统，有提单、有记录，能满足合规审计即可。所以过往很多企业甚至没有itsm系统，仅仅是线下纸质或者在类似oa等具备流程功能的系统上跑运维流程也问题不大。整体来说，itsm工具的要求通常是简单的，复杂度并不在这里。
数字化时代下，不仅业务侧需要积极推进数字化转型，运维侧也同样面临着转型的迫切需求。业务系统架构正逐渐趋向敏捷化，而在各类互联网服务的冲击下，员工对于工作的认知和审美标准也悄然发生了转变，这无疑进一步加速了运维侧的转型步伐。最简单的例子是，难道你的系统还不支持移动端吗？那简直是不可思议。itsm作为运维管理的重要部分，其数字化转型也是非常重要的，最新的行业实践itil4、verism等的到来也印证了这一点。
所以，在it运维数字化、敏捷化、自动化、智能化的趋势下，itsm工具系统不仅变成了刚性需要，而且建设的复杂度远比过往要高很多。那么，在构建百层的高楼大厦之前，相应平台的基座是不是得先建设好？
② 甲乙方协同因素
甲乙方一直存在一个矛盾，乙方作为服务的提供方，更希望标准化交付。甲方作为服务的消费方，更希望个性化服务，这是显而易见的。尤其itsm这类管理型软件更为明显，每个企业有不同的发展阶段、团队文化和管理诉求，虽然有类似itil这样权威最佳实践的指导，但细节是千差万别的，因此也带来了很大协同建设的挑战。
为满足甲方个性化诉求而定制的软件版本，会在后续难以跟随软件的主版本进行持续升级换代。且不谈功能更新的复用，当出现一些疑难缺陷问题，双方投入的维护成本都是很高的，如：旧版本可能存在一个严重的缺陷隐患，当这个问题出现时，乙方需要投入重复的成本去修复它。即使甲方无需为此缺陷的修复付费，也会为此带来业务上、用户满意度上的损失。无论如何，最终的结果大概率是双输的。
所以，我们提出以下建议：
软件设计中有个经典的原则叫“开闭原则”，即“对于扩展是开放的，但是对于修改是封闭的”。这是一种绝佳的平衡之术，可以在软件稳定性、质量和个性化定制扩展之间取得平衡。对修改核心代码的封闭，保障了软件的稳定，而对扩展是开放的，则又满足了个性化场景的要求，平台化的设计理念则能很好地匹配这一软件设计原则。
从业务视角看：
技术和平台是行业通用的，企业没必要重复建设，也难有相应的资源和能力进行建设。业务场景是个性化的，企业可以自主建设或寻求第三方渠道，不应该被固定的供应商捆绑束缚。因此，从市场需求和发展来看，itsm也应该考虑平台化的建设思路。
02. itsm平台化架构参考
1）架构参考
通过前面的介绍，我们对平台化理念和必要性有了一定的理解。那么这个平台具体应该怎么搭建呢？如图4所示，提供了一种架构设计的参考。这个架构的特点是不仅仅考虑了场景可扩展和能力复用，还引入了低代码引擎能力，用以进一步提高平台的灵活性。
- 平台核心引擎能力：主要将“管理场景”高度复用的能力抽象到平台下层，使得平台上层的管理场景构建能够更加敏捷、成本更高。
- 场景层与平台层完全解耦，并提供应用模块级的扩展开发框架，以实现复杂业务场景扩展或与第三方系统打通融合。
- 提供插件商店，作为持续沉淀海量集成插件，用户按需自助安装/卸载。
2）扩展模式
以上的架构设计最终强调的是平台需要提供极致的可扩展性和灵活性，我们将这种特性抽象成3种模式，参考如下表格可以判断一个itsm平台能力的成熟度。
03. itsm复杂应用场景
如前面章节所述，itsm平台是为了实现更复杂的服务管理场景而生，那么我们通过几个典型场景的前后对比来感受下。
1）运维请求服务化
基于itsm平台，我们可以将单一的请求流程进行场景化拆分，以结构化服务目录的方式对外提供，这种转变带来的好处是运维服务一目了然，用户也能够更好地找到自己所需。这里的复杂度变化是由“单一流程”变化为“成千上百个流程”。
另外很重要的一点是，流程进行场景化拆分后，如图7所示，存储扩容申请需求的描述可以由非结构化变为了结构化，也为后续实现请求履行的自动化做好准备。这里的复杂度变化是由“手工填写的简单表单”变化为“集成度更高的复杂表单”。
2）工作流端到端自动化
所谓工作流的端到端，是指将某个工作目标实现过程中涉及的人与系统进行连接，以高效地完成最终价值交付。如果是工单系统思维，更多只是体现审批、处理等人工流程环节，如图8所示，仅仅是满足一种管理规范。
基于平台之上实现端到端的流程，我们仍然以存储扩容场景为例，如下图9所示，此过程利用itsm平台的可扩展性、可集成性来将cmdb（获取主机信息）、运维人员（填写主机信息）、存储系统（新建存储实施）进行连接，端到端地完成存储扩容的价值场景交付，避免“流程孤岛”。这里的复杂度变化是由“几个流程环节”变化为“数十个流程环节”。
3）管理策略数字化
管理过程不仅仅是固定的工作流程，还有人思考和决策。例如：变更管理的风险评估环节、事件管理的影响分析环节、请求管理的任务分派环节，都涉及运维人员在线下进行沟通、判断和决策，而这类动作过往在过itsm工单系统上是很难实现线上化的，或者说成本非常高，it部门要么内部拥有开发团队，要么依赖厂商高价定开，这样不仅建设成本高，后续的持续维护成本也很高。
基于平台化的架构，我们可以在低成本地扩展更多的能力组件，以承载这些管理细节。
以变更风险评估为例，我们可以将专家经验沉淀到系统中，实现风险的自动计算。
以事件分派为例，我们可以将规则沉淀到系统中，实现事件处理的自动派发。
04. 总结
在数字化时代，服务管理的需求已经发生了显著变化，对itsm工具的要求也随之升级。我们不再满足于仅仅将审批和协同等少数动作进行线上处理，而是需要将服务管理过程中的更多环节，如任务分配、问题跟踪、知识共享等，全面线上化，摆脱对传统文档和人力记忆的依赖，以提高效率、减少错误，并更好地适应快速变化的业务需求。
因此，如果继续以工单系统的传统思维，仅仅局限于满足管理合规性的基本要求来构建itsm，那么在未来，这样的系统将难以适应业务侧对效率和用户体验日益增长的需求。为了保持竞争力并应对这些挑战，将平台化理念融入itsm建设中将是一个更为明智和前瞻性的选择。这样的做法能够更好地支撑业务增长，提升运维效率，并为用户提供更优质的体验。
