您的变更管理数据模板
您的变更管理数据模板
- 建议收集的属性
- 准确进行流程发现需要追踪的关键活动
- 从 ServiceNow 提取数据的指南
变更管理属性
| 名称 | 描述 | ||
|---|---|---|---|
|
Event 时间
EventTime
|
特定活动或事件发生的精确时间戳。 | ||
|
描述
事件时间记录了活动执行或状态变更登记的确切日期和时间。此时间戳对于按时间顺序排列事件以及进行所有基于持续时间的分析至关重要。 在流程挖掘中,此属性支持计算活动之间的周期时间、处理时间和等待时间。这对于分析绩效的仪表板(如“变更审批周期时间”和“端到端变更流程流转”)是必不可少的。准确的时间戳是识别延迟和根据 SLA 衡量流程效率的基石。
为何重要
此时间戳对于正确排列事件顺序以及计算所有基于时间的指标(包括周期时间、持续时长和 SLA 达成情况)至关重要。
获取方式
ServiceNow 表: sys_audit, 字段: sys_created_on。这为每项记录的变更提供了时间戳。
示例
2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:05:00Z
|
|||
|
变更请求 ID
ChangeRequestNumber
|
变更请求的唯一标识符,作为用于对所有相关事件进行分组的主要 case ID。 | ||
|
描述
变更请求 ID 是变更管理流程分析的基石。它是分配给每个变更请求的唯一编号(例如 'CHG0030001'),将所有活动、审批和任务联系在一起。 在流程挖掘中,此属性用于重构每个独立变更的端到端旅程。它使分析师能够追踪从创建到关闭的完整生命周期,提供变更在系统中进展的连贯视图。按此 ID 分组分析流程对于计算周期时间、识别返工循环和理解流程变体至关重要。
为何重要
此 ID 对于追踪变更的整个生命周期至关重要,支持对每个请求的流程流、持续时间和合规性进行完整分析。
获取方式
ServiceNow 表: change_request, 字段: number
示例
CHG0030001CHG0030045CHG0030112
|
|||
|
活动名称
ActivityName
|
变更管理流程中发生的特定事件或任务的名称。 | ||
|
描述
活动名称描述了变更请求生命周期中的一个离散步骤或状态变更。示例包括“变更待评估”、“已请求审批”和“变更已实施”。这些活动构成了发现的流程图中的节点。 通过分析这些活动,可以对流程流进行详细检查。通过追踪活动的顺序和频率,组织可以识别常见路径、与标准流程的偏差以及变更经常停滞的瓶颈。这对于可视化流程以及计算步骤间转换时间等指标至关重要。
为何重要
它构成了流程图的骨干,支持可视化流程流、识别瓶颈以及分析偏差。
获取方式
源自
示例
变更已批准实施已开始变更已关闭变更已取消
|
|||
|
优先级
Priority
|
变更请求的优先级,由其影响力和紧急度决定。 | ||
|
描述
优先级表示变更请求的重要性,并决定了处理它们的顺序。它通常由变更的影响力和紧急度派生而来,值包括“危急”、“高”、“中”和“低”。 按优先级进行分析对于确保高优先级变更比低优先级变更处理得更快至关重要。它支持“关键变更绩效”仪表板,使分析师能够专门追踪最重要变更的周期时间和失败率。任何低优先级变更比高优先级变更完成得更快的偏差都表明资源分配或流程执行存在问题。
为何重要
对于评估资源是否正确分配给最关键的变更,以及分别监控其绩效至关重要。
获取方式
ServiceNow 表: change_request, 字段: priority
示例
1 - 紧急2 - 高3 - 中等4 - 低
|
|||
|
变更状态
ChangeState
|
变更请求的当前或历史状态,如 'Assess'、'Authorize'、'Implement' 或 'Closed'。 | ||
|
描述
变更状态属性表示变更请求在特定时间点的状态。它提供了变更在其生命周期中所处位置的高级摘要。与代表特定事件的“活动”不同,“状态”是该事件产生的结果。 在分析中,变更状态用于对 case 进行分类并了解其结果。它是过滤变更的基础,例如,仅分析“已关闭”的变更或调查为什么许多变更卡在“授权”状态。当存在“失败”状态时,它直接支持诸如变更失败率之类的 KPI。
为何重要
提供变更请求状态的快照,支持对结果的分析、case 过滤以及识别停滞的变更。
获取方式
ServiceNow 表: change_request, 字段: state
示例
AssessAuthorize已计划实施 (Implement)评审 (Review)已结案已取消
|
|||
|
指派组
AssignmentGroup
|
负责该变更请求的团队或小组。 | ||
|
描述
分配组指示当前负责该变更请求的团队,如“CAB 审批”、“网络工程”或“数据库管理员”。这是分析跨不同职能领域流程绩效的关键维度。 此属性用于衡量团队级别的效率,识别特定组内的瓶颈,并分析团队间交接的有效性。“跨职能交接效率”和“变更实施吞吐量”等仪表板高度依赖这些数据,以精准定位由团队间依赖关系引起的延迟。
为何重要
支持按团队进行绩效分析,突出显示各小组特有的瓶颈,并衡量不同职能领域之间交接的效率。
获取方式
ServiceNow 表: change_request, 字段: assignment_group
示例
CAB 审批网络团队服务器支持数据库管理员
|
|||
|
更改类型
ChangeType
|
变更的分类,如“标准”、“普通”或“紧急”。 | ||
|
描述
变更类型根据变更请求的性质、风险和审批要求对其进行分类。标准 (Standard) 变更是预先批准的,常规 (Normal) 变更遵循完整流程,而紧急 (Emergency) 变更则使用加急路径。 这是流程分析的基础维度,因为不同的变更类型具有截然不同且合法的流程模型。比较常规变更与紧急变更的绩效,可以揭示有关流程合规性和效率的重要见解。它还用于“风险评估标准化”等仪表板中,以确保类似的变更得到一致处理。
为何重要
允许进行细分分析,因为不同的变更类型遵循不同的授权流程,并具有独特的性能预期。
获取方式
ServiceNow 表: change_request, 字段: type
示例
标准普通紧急
|
|||
|
结束时间
EndTime
|
活动结束的时间戳。通常源自后续活动的开始时间。 | ||
|
描述
结束时间标志着一项活动的完成。虽然源系统通常记录事件的开始,但结束时间通常是推断出来的。它通常计算为同一 case 序列中下一项活动的时间戳。 此属性对于计算每项活动的持续时间(即处理时间)至关重要。了解每一步花费的时间是识别流程中瓶颈和低效环节的基础。对于 case 中的最后一项活动,结束时间与开始时间相同。
为何重要
支持计算活动处理时间,这对于识别瓶颈和衡量特定流程步骤的持续时间至关重要。
获取方式
此属性通常在数据转换期间通过获取同一 CaseId 的下一事件的 StartTime 计算得出。
示例
2023-10-26T10:05:12Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
|
|||
|
配置项
ConfigurationItem
|
作为变更对象的特定 IT 组件、服务或系统。 | ||
|
描述
配置项 (CI) 是配置管理数据库 (CMDB) 中将受变更影响的资产。这可以是一台服务器、一个软件应用程序、一个网络设备或一项业务服务。 此属性为变更提供了关键背景。在流程挖掘中,它支持按所变更资产的类型进行细分分析。例如,“变更测试时长分析”仪表板使用此属性来比较不同应用或系统的测试时间,从而帮助识别哪些 CI 与更长的测试周期相关联。
为何重要
提供必要的业务背景,支持按受影响的应用、服务或系统进行过滤分析,以识别特定组件的问题。
获取方式
ServiceNow 表: change_request, 字段: cmdb_ci
示例
SAP ERPOracle Database 19c邮件服务WebServer-01
|
|||
|
风险等级
RiskLevel
|
评估的变更风险级别,如“高”、“中”或“低”。 | ||
|
描述
风险级别是变更请求风险评估过程的输出。它量化了实施变更可能产生的负面后果,有助于确定所需的审查和审批级别。 此属性是“风险评估标准化”仪表板的关键,用于检查类似变更是否获得一致的风险评级。按风险级别分析流程流还可以揭示高风险变更为是否与低风险变更相比正确遵循了更严格的审批和测试路径,这是关键的合规性检查。
为何重要
对于合规性分析至关重要,确保高风险变更得到应有的审查并遵循更严格的流程。
获取方式
ServiceNow 表: change_request, 字段: risk
示例
高中低
|
|||
|
SLA 状态
SlaState
|
变更请求相对于其服务级别协议 (SLA) 的状态,如“正常推进”、“有风险”或“已违约”。 | ||
|
描述
SLA 状态指示变更请求是否在 SLA 定义的时间范围内进行。可以在流程的每个阶段追踪此状态。 此属性对于监控对服务级别承诺的遵守情况至关重要。它是“变更 SLA 绩效概览”仪表板和“变更 SLA 达成率”KPI 的主要数据源。分析 SLA 在何处以及为何被违反,可以让组织解决系统性延迟并提高服务交付的可预测性。
为何重要
提供针对截止日期的绩效直接衡量,支持对 SLA 违规情况的主动监控和分析,以改善服务交付。
获取方式
这可以源自 ServiceNow 中的 'task_sla' 表(该表追踪与变更请求等任务相关的 SLA),或根据截止日期字段计算得出。
示例
正常推进存在风险已超期
|
|||
|
关闭代码
CloseCode
|
指示变更请求关闭时结果的代码,例如“成功”或“失败”。 | ||
|
描述
关闭代码为已完成的变更请求提供最终处理结果。它正式记录了变更实施是成功、存在问题还是已回滚。 此属性是“变更失败率”KPI 的直接输入。通过分析关闭代码的分布,组织可以量化其变更计划的成功程度。在流程图中过滤关闭代码为“不成功”的变更是一种强大的根因分析技术,可以揭示导致失败的常见流程模式。
为何重要
直接衡量变更结果,为计算变更失败率和分析失败根本原因提供核心数据。
获取方式
ServiceNow 表: change_request, 字段: close_code
示例
成功成功(存在问题)不成功 / 已回滚
|
|||
|
最后数据更新
LastDataUpdate
|
指示此 record 数据上次从源系统刷新的 timestamp。 | ||
|
描述
此属性提供最后一次数据提取的时间戳。它是一个元数据字段,对于了解所分析数据的新鲜度至关重要。 分析师使用此时间戳来确认他们正在处理最新信息,并了解数据的时效性。对于监控持续流程绩效的运营仪表板而言,这尤为重要,可确保决策不是基于陈旧数据做出的。
为何重要
指示数据新鲜度,确保分析和仪表板基于最新且相关的信息。
获取方式
这是在数据提取和转换 (ETL) 过程中生成的元数据字段,指示抓取数据的时间。
示例
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
周期时间
CycleTime
|
从变更请求创建到关闭所经过的总时间。 | ||
|
描述
周期时间 (Cycle Time) 是一个案例级别的指标,用于衡量变更请求生命周期的总持续时间。其计算方法是给定变更请求的最后一个事件的时间戳与第一个事件的时间戳之差。 这是衡量整体流程速率的关键 KPI。它被用于“端到端变更流程流转”仪表板中,以提供流程绩效的高层视图。分析周期时间趋势并按变更类型或优先级等不同维度进行比较,有助于组织发现战略性流程改进的机会。
为何重要
衡量变更流程的端到端持续时间,为整体流程速度和效率提供关键指标。
获取方式
在数据分析期间按案例级别计算,方法是从每个 CaseId 的最大 StartTime 中减去最小 StartTime。
示例
60480012096002592000
|
|||
|
处理时间
ProcessingTime
|
单个活动的持续时间,计算为结束时间与开始时间之差。 | ||
|
描述
处理时间(也称为活动持续时间)衡量的是积极执行特定任务所花费的时间。它的计算方法是用活动的结束时间减去开始时间。 这一计算指标是进行性能分析的基础。它允许识别流程中最耗时的步骤,这些步骤通常是优化工作的主要目标。分析测试时长或风险评估周期时间的仪表板直接基于相关活动的这一指标。
为何重要
衡量单个活动的持续时间,从而能够精准定位那些最耗时且急需优化的步骤。
获取方式
在数据转换期间计算:EndTime - StartTime。
示例
259200360086400
|
|||
|
影响
Impact
|
变更对业务运营的潜在影响,分级如“高”、“中”或“低”。 | ||
|
描述
影响力衡量了如果变更请求处理不当对业务产生的潜在影响。它与紧急度一起,是确定变更整体优先级的关键输入。 分析影响力有助于确保影响关键业务的变更得到妥善管理。它被用于“关键变更绩效”仪表板,以隔离和监控具有高业务影响的变更。它还用于验证风险评估的一致性,确保高影响力的变更在没有正当理由的情况下不会被分配为低风险级别。
为何重要
帮助根据潜在的业务影响对变更进行优先级排序,并用于验证高影响力的变更是否得到了妥善管理。
获取方式
ServiceNow 表: change_request, 字段: impact
示例
1 - 高2 - 中等3 - 低
|
|||
|
是否返工
IsRework
|
一个布尔标志,如果某项活动代表同一案例中先前步骤的重复,则为 true。 | ||
|
描述
此计算属性识别构成返工的活动。当流程必须循环回到已完成的步骤时(例如变更审批后被拒绝并退回重新评估),就会发生返工。 该标志对于量化流程低效至关重要。它直接支持“变更返工率”KPI 和“变更失败与返工分析”仪表板。通过过滤“是否返工”为真的活动,分析师可以隔离并研究返工的原因(如初始评估不完整或需求变更),并采取行动减少浪费。
为何重要
通过标记重复工作直接量化流程低效,有助于识别并解决流程循环和无效劳动的根本原因。
获取方式
在数据转换期间计算,方法是检测给定 CaseId 是否已发生过相同的活动(或标准流中较早的活动)。
示例
truefalse
|
|||
|
源系统
SourceSystem
|
提取数据的系统,通常为 'ServiceNow'。 | ||
|
描述
此属性标识流程数据的来源。虽然在此案例中预计来源为 ServiceNow,但它对于数据治理以及可能合并多个系统数据的情况而言是一个关键字段。 在分析中,它确保数据血缘清晰,并有助于验证数据源。对于拥有多个 ITSM 工具或集成系统的组织,此属性允许跨不同平台过滤和比较流程。
为何重要
提供清晰的数据血缘,确保记录流程数据的来源,这对于数据治理和多系统分析至关重要。
获取方式
这通常是在数据提取和转换 (ETL) 过程中添加的静态值。
示例
ServiceNowServiceNow_PRODSNOW_ITSM
|
|||
|
紧急程度
Urgency
|
变更需要解决的速度,分级如“高”、“中”或“低”。 | ||
|
描述
紧急度定义了变更实施的紧迫程度。它从业务角度反映了请求的时间敏感性。它与影响力一起,用于计算整体优先级。 虽然优先级是分析的主要字段,但紧急度提供了额外的背景。它可以用来调查为什么某些变更被标记为紧急,以及流程是否能在不牺牲稳定性的前提下有效处理它们。它有助于解答组织是否过于频繁地处于被动、高紧急处理模式的问题。
为何重要
提供变更时间敏感性的背景,有助于分析流程是否能有效处理具有时效要求的请求。
获取方式
ServiceNow 表: change_request, 字段: urgency
示例
1 - 高2 - 中等3 - 低
|
|||
|
被分配用户
AssignedToUser
|
在特定时间点负责该变更请求的个人用户。 | ||
|
描述
此属性标识被指派处理该变更请求的具体人员。随着请求在不同阶段和团队之间流转,此人员在整个生命周期中可能会变更多次。 按用户进行分析有助于了解任务量分布、个人绩效并识别培训需求。它也是分析交接的关键,特别是与分配组结合使用时,可以查看人员之间工作的传递效率。
为何重要
帮助跟踪个人用户的任务量和绩效,对于分析不同资源之间的交接延迟至关重要。
获取方式
ServiceNow 表: change_request, 字段: assigned_to
示例
Beth AnglinDavid LooAbel Tuter
|
|||
变更管理活动
| 活动 | 描述 | ||
|---|---|---|---|
|
变更已关闭
|
变更请求已成功完成并通过评审,现在被视为已结束。这是流程的主要成功终点,在变更状态变更为 'Closed' 时捕获。 | ||
|
为何重要
此活动标志着变更生命周期的成功完成。它是衡量端到端流程持续时间和 SLA 达成情况的结束事件。
获取方式
根据 change_request 表中的 'state' 字段被设置为 'Closed' 推断得出。时间戳取自该最终状态变更的审计历史。
捕获
捕获 'state' 字段更新为 'Closed' 的时间戳。
事件类型
inferred
|
|||
|
变更已取消
|
变更请求在实施完成之前的某个时间点被撤回或终止。这是在状态被设置为 'Canceled' 时捕获的另一种结束状态。 | ||
|
为何重要
分析已取消的变更可以揭示流程中的低效之处,例如不必要的请求创建,或者审批停滞时间过长导致请求失效。
获取方式
根据 change_request 表中的 'state' 字段被设置为 'Canceled' 推断得出。时间戳从该状态变更的审计日志中获取。
捕获
捕获 'state' 字段更新为 'Canceled' 的时间戳。
事件类型
inferred
|
|||
|
变更已实施
|
实施工作已完成,变更已准备好进行评审、验证或测试。当变更请求的状态从 'Implement' 转换为 'Review' 时推断得出。 | ||
|
为何重要
这是一个结束实施阶段的关键里程碑。它是计算“变更失败率”和“变更返工率”KPI 的关键事件。
获取方式
根据从 'Implement' 退出并进入后续状态(如 'Review')的转换推断得出。时间戳从 change_request 表中 'state' 字段的审计历史中获取。
捕获
识别 'state' 字段何时从 'Implement' 变更为 'Review'。
事件类型
inferred
|
|||
|
变更已批准
|
变更请求已获得所有必要的授权,可以进入排期和实施阶段。这是一个关键里程碑,在最终批准授予且 'approval' 字段设置为 'approved' 时捕获。 | ||
|
为何重要
此里程碑标志着审批阶段的结束。这对于衡量审批周期时间以及识别决策过程中的瓶颈至关重要。
获取方式
根据 change_request 表的 'approval' 字段变更为 'approved' 推断得出。时间戳源自该项变更的审计历史。
捕获
捕获 'approval' 字段变为 'approved' 的时间戳。
事件类型
inferred
|
|||
|
变更已排期
|
已批准的变更已被分配了计划的开始和结束日期,现在正式列入实施日历。这在变更请求状态变更为 'Scheduled' 时推断得出。 | ||
|
为何重要
此活动将计划和审批阶段与实际实施阶段分开。在此状态下花费的时间可能表明审批通过与开始工作之间的延迟。
获取方式
根据 change_request 表中 'state' 字段更改为 'Scheduled' 推断得出。时间戳从相应的审计日志条目中获取。
捕获
在 change_request 表的审计历史中,追踪状态字段更改为 'Scheduled' 的记录。
事件类型
inferred
|
|||
|
变更请求已创建
|
此活动标志着系统中新变更请求记录的创建。它是变更管理流程的正式开始,在 change_request 表中插入新条目时捕获。 | ||
|
为何重要
这是流程的主要开始事件。分析从该活动到其他活动的时间可以揭示总交付周期,并有助于识别流程最开始阶段的延迟。
获取方式
此事件对应于 ServiceNow change_request 表中的记录创建时间戳 (sys_created_on)。
捕获
使用 change_request 表中的 sys_created_on 时间戳。
事件类型
explicit
|
|||
|
风险与影响已评估
|
代表变更请求的风险和影响分析已完成。这是寻求审批前的关键里程碑,通常在变更从 'Assess' 状态转入 'Authorize' 或 'Awaiting Approval' 状态时推断得出。 | ||
|
为何重要
追踪评估阶段的持续时间是“平均风险评估周期时间”KPI 的关键。它有助于标准化评估流程,并识别哪些分析环节耗时过长。
获取方式
根据 change_request 表中的 'state' 字段从 'Assess' 转换为 'Authorize' 推断得出。事件时间戳从该状态变更的审计日志中获取。
捕获
识别 'state' 字段何时从 'Assess' 变更为后续状态(如 'Authorize')。
事件类型
inferred
|
|||
|
变更已重新开启
|
变更请求在达到较后阶段后被移回之前的状态,如 'Implement' 或 'Assess'。该事件是从非线性状态转换中推断出来的,表示发生了返工。 | ||
|
为何重要
此活动对于识别返工循环和计算“变更返工率”至关重要。频繁的重新打开事件表明实施质量、测试或计划存在问题。
获取方式
通过分析 change_request 审计历史中的状态变更顺序推断得出。从较晚的状态(如 'Review')切换回较早的状态(如 'Implement')即表示发生了重新打开事件。
捕获
检测 'state' 字段历史记录中的非顺序逆向流转。
事件类型
inferred
|
|||
|
变更等待评估
|
变更请求已提交,目前正在等待技术和业务评估。通常在变更请求的状态转换为 'Assess' 或类似状态时推断得出,表明它已离开草稿阶段。 | ||
|
为何重要
此活动有助于衡量从请求者到评估团队的初始交接时间。此处的延迟可能表明初始数据质量存在问题,或评估资源可用性不足。
获取方式
根据 change_request 表中 'state' 字段的变更(通常变更为 'Assess' 之类的值)推断得出。时间戳取自该字段变更的审计历史记录 (sys_audit)。
捕获
在 change_request 表的审计历史中,追踪状态字段更改为 'Assess' 的记录。
事件类型
inferred
|
|||
|
变更被拒绝
|
变更请求已被审批人或 CAB 拒绝。除非经过返工并重新提交,否则此活动代表请求的终止状态。当 'approval' 字段被设置为 'rejected' 时捕获。 | ||
|
为何重要
追踪拒绝情况有助于识别被否决的常见原因,如信息不全或高风险。此类分析可以提高未来变更提交的质量。
获取方式
根据 change_request 表中的 'approval' 字段变更为 'rejected' 推断得出。时间戳从审计历史中获取。
捕获
捕获 'approval' 字段变为 'rejected' 的时间戳。
事件类型
inferred
|
|||
|
实施已开始
|
变更实施工作已正式开始。当变更请求的状态更新为'Implement'时,系统会捕捉到这一状态,这标志着流程从规划阶段转向执行阶段。 | ||
|
为何重要
这标志着实际实施工作的开始。它是衡量“平均实施时长”KPI 和分析团队效率的起点。
获取方式
根据 change_request 表中的 'state' 字段变更为 'Implement' 推断得出。时间戳取自该状态转换的审计日志。
捕获
从 change_request 审计历史中捕获状态更改为“Implement”的时间戳。
事件类型
inferred
|
|||
|
正在评审
|
正在执行实施后评审 (PIR),以确定变更是否成功并达到了预期目标。这在变更请求状态设置为“Review”时捕获。 | ||
|
为何重要
分析评审阶段的持续时间有助于识别在验证变更成功方面的延迟。它还能突出显示跳过此步骤的违规变更。
获取方式
根据 change_request 表中的 'state' 字段变更为 'Review' 推断得出。时间戳源自该状态变更的审计日志。
捕获
从 change_request 审计历史中捕获状态更改为“Review”的时间戳。
事件类型
inferred
|
|||
|
请求审批
|
此活动表示变更请求已正式提交审批,通常提交给经理或变更咨询委员会 (CAB)。当变更请求的审批状态被设置为 'requested' 时捕获此事件。 | ||
|
为何重要
这标志着审批周期的开始。衡量从该事件到“变更已批准”的时间,可直接计算“平均变更审批时间”KPI。
获取方式
根据 change_request 表中的 'approval' 字段变更为 'requested' 推断得出。时间戳记录自 sys_audit 表中的该字段记录。
捕获
change_request 表中的 'approval' 字段设置为 'requested' 时的时间戳。
事件类型
inferred
|
|||