执行摘要
随着组织不断发展且 IT 运营日趋成熟，IT 服务管理 (ITSM) 平台的基础架构对于实现长期敏捷性、高效集成和高水准服务至关重要。
一些 ITSM 解决方案（如 HaloITSM）采用简化的单表模型（将所有服务记录存储在一个统一表中）。相比之下，Ivanti Neurons for ITSM 采用更先进的面向对象架构，将不同的 ITIL 流程（事件、问题、变更和请求）划分为独立的模块化实体。
本白皮书探讨了单表方法的不足，尤其是在复杂企业环境中的局限，并重点介绍采用更结构化、可扩展的 ITSM 架构所带来的优势。
| 特性/能力 | 单表 | 模块 |
|---|---|---|
| 工作流灵活性 | 有限 | 高 |
| ITIL 对齐 | 基础 | 全面 |
| 自定义隔离性 | 低 | 高 |
| 报告粒度 | 中等 | 高级 |
| 集成复杂性 | 高 | 低 |
| 可扩展性 | 中等 | 高 |
| 性能 | 中等 | 高 |
| 安全性 | 复杂 | 简化 |
1. 引言
当前，ITSM领域正在快速演进，对自动化、集成和以用户为中心的服务交付需求不断提升。对于小型团队或初创企业而言，简洁性可能是一项优势，但随着组织发展，它往往会成为负担。本文探讨 HaloITSM 的单表模型与 Ivanti Neurons 模块化设计之间的架构取舍。
2. 了解单表 ITSM 模型
在使用单表的平台中，所有服务记录（无论是事件、服务请求、问题还是变更）都存储在一个“Tickets”表中。
下图展示了一个包含六个字段的单表 ITSM 架构：
| 记录编号 | 记录类型 | 负责人姓名 | 主题 | 机密 | 优先级 |
|---|---|---|---|---|---|
| 1 | 事件 | Don | VPN 错误 | 2 | |
| 2 | 变更 | Jamie | 修补 SQL Server | 低 | |
| 3 | HR 案例 | Harold | 我的薪资有误 | 是 | 紧急 |
| 4 | 事件 | Don | SAP 故障 | 1 | |
| 5 | 请求 | Patricia | 新电脑 | 低 |
首先您会注意到一个名为“记录类型”的字段。该字段决定记录中存储的数据类型，也是用于限制对该字段类型访问权限的主要字段。
安全性
首先，我们来看一下此表的安全框架。以下定义概述了 Harold 的访问权限。
允许 Harold 对表 = “tickets” 且记录类型 = “HR Case” 拥有完全访问权限。
这条安全规则可确保 Harold 能够访问 tickets 表，并且只能查看 HR 案例。
现在，我们再来看一下在 IT 部门工作的 Don 的这条规则……
允许 Don 对表 = “tickets” 拥有完全访问权限。
问题在于，Don 作为 IT 员工，对整个表拥有不受限制的访问权限。这可能会无意中向 Don 暴露机密的 HR 案例数据。
规则应为：
允许 Don 对表 = “tickets” 且记录类型 NOT = “HR Case” 拥有完全访问权限。
当需要授予 Don 对“incident”的完全访问权限，但仅授予其对“changes”的读取权限时，这种复杂性会进一步增加。
配置
统一表环境中的配置也可能很复杂，因为同一表中的字段可能会根据记录类型而有不同的要求。
观察该表可以发现，不同记录类型对应多种优先级类型。事件遵循 ITIL 标准，采用数字体系（1、2、3、4），而变更和请求则被归类为低、中或高优先级。不过，HR 请求被归类为低、高或紧急。
您将如何实施并维护这种复杂性？自由格式字段会降低数据完整性和标准化程度，因此使用带有记录类型筛选器的查找表更为可取。然而，这仍然会带来混合数据类型的挑战，使报告以及字段/表维护变得更加复杂。
共享单表中的配置更为复杂，因为所有配置更改都必须考虑所有记录类型。例如，“机密”字段是 HR 案例所必需的，但其他记录类型并不需要。如果“HR Case”拥有自己的表，您只需在表级别将该字段设为必填即可。如果在单表中进行此更改，那么该字段也会在事件、变更和请求中成为必填字段，而这些记录类型并不需要它。解决方法是通过字段业务规则以编程方式强制其成为必填字段，这需要进行一定定义并增加额外管理工作。
现在，假设我们有一个法务团队希望构建一个用于法务请求的自定义应用。在单表架构中，我们需要将记录类型设为“Legal”，并且可以复用一些字段（例如“主题”“描述”“机密”）。但是，法务还需要其他必填字段：“外部”（是/否）、“法律程序”（是/否）等。这些字段需要添加到 tickets 表、表单和工作流中。对于这些附加字段，需要谨慎规划，以避免影响现有记录类型、安全定义和业务规则。
性能和可扩展性
单表架构在初期可以高效运行，能够容纳较少记录和 OOTB 字段；但随着记录量增长，如果不持续做好数据库卫生和索引维护，其性能可能会下降。此外，加入自定义字段还可能进一步加剧潜在的性能下滑。
一般而言，数据库表的最佳实践包括：
- 避免不必要的表字段。
- 尽可能规范化数据，以减少冗余字段。
- 只查询并返回所需字段。
- 为表中的字段正确建立索引，以优化性能。
采用单表方法的 ITSM 系统如何确保性能和可扩展性？
虽然单表数据模型简化了 IT 服务管理的某些方面，但它确实存在您需要了解的局限。
3. 采用模块化 ITSM 架构的理由
模块化 ITSM 架构是指将每个 ITSM 流程建模为一个独立的业务对象，并与其他业务对象（流程）相关联；例如，事件关联到问题，或问题关联到变更。这种模块化方法紧密遵循 ITSM 流程并确保数据隔离，从而带来多项优势。
特定于流程的工作流
在模块化表设计工作流中，SLA、审批和业务规则可以针对表（流程）独立设置。无需使用特殊筛选来防止工作流针对其他类型（ITSM 流程）的记录运行。例如：在违反 SLA 时，对事件执行升级运行条件。
在这种方法下，可以更顺畅地与 ITIL 最佳实践和治理保持一致，并有效阻止对非 ITIL 流程（如 HR 案例或设施工单）的执行。
提升安全性
通过按流程分隔表，可以增强安全性，降低无意访问敏感数据的风险。在这种情况下，只有获得明确授权的人员才能访问，并且可以轻松调整附加安全措施，以针对特定数据和记录。
此外，独立的表安全性可确保报告和导出遵循标准表安全规则，而不是更复杂的行级安全规则。
增强自定义能力
特定于流程的表提供更高的配置灵活性，确保一个流程中的更改不会影响其他流程（或被广泛使用的字段）。表级别的独特字段配置无需复杂的业务规则，从而支持更复杂的场景，例如变更的 CAB 审批或问题的根因分析。
高级报告和分析
借助包含结构化数据且与流程对齐的表，现在可以更容易地在 ITIL 领域中实现精细化报告、趋势分析和 KPI 跟踪，并且相关数据的整合也得以简化。例如，展示所有由变更解决的事件的报告。
这也有助于跨流程或企业业务对象（例如 HR 案例、设施工单）进行合规报告和构建高管仪表板。
更好的集成和可扩展性
与外部系统的简化集成包括与流程对齐的独立表。这种方法不仅简化了 API 暴露，还增强了安全性（因为 API 需要对表的 API 具有明确访问权限）。
这支持低代码/无代码扩展能力，可加速创新，并提供扩展现有业务对象或创建新业务对象的灵活性。
4. 应提出的问题
单表数据结构可能会限制未来增长。在评估 ITSM 系统时，深入了解底层数据架构至关重要。
请向您的 ITSM 供应商提出以下问题：
- 您的 ITSM 流程是否使用独立的表，还是都在同一个表中？
- 维护和保护其安全有多困难？
- 添加新功能（如法务请求）会产生什么影响？
- 在工具中复制自定义功能有多困难？
- 创建自定义对象需要多长时间？
- 防止未经授权访问数据有多困难？
- 您能否演示如何添加新字段和新对象？
- 需要多少人员？
- 成本是多少？
- 我是否能够进行升级？
5. 哪种 ITSM 架构适合您？
像 HaloITSM 这样的单表 ITSM 解决方案，对于希望凭借简化的用户体验快速启动和运行的组织而言，是一个不错的起点。但对于成熟的企业级 IT 运营来说，这些解决方案可能会带来增长和规模化挑战。
随着组织希望与 ITIL 保持一致、自动化复杂工作流并在整个数字生态系统中实现集成，Ivanti Neurons for ITSM 这样的模块化架构能够提供长期成功所需的灵活性、可扩展性和控制力。