您的变更管理数据模板
您的变更管理数据模板
- 建议收集的属性
- 需要追踪的关键活动
- 来自 Ivanti Cherwell 的提取指南
变更管理属性
| 名称 | 描述 | ||
|---|---|---|---|
|
Event 时间
EventTime
|
表示变更请求的特定活动或事件发生的时间戳。 | ||
|
描述
事件时间(也称为时间戳)记录了活动发生的准确日期和时间。此时间数据对于按时间顺序排列事件至关重要,是所有基于时间的 Process Mining 分析的基础。 此属性用于计算活动之间的时长、衡量整体个案周期时间,并识别流程中的等待时间或延迟。它是创建仪表板以监控基于时间目标的绩效(如变更审批周期时间)的基础。
为何重要
此时间戳是所有绩效和时长分析的基础,支持计算周期时间、识别瓶颈以及监控 SLA。
获取方式
通常位于 Ivanti Cherwell 中与“变更请求”对象关联的状态更改日志、审计追踪或日记账分录时间戳中。
示例
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
|
|||
|
变更请求 ID
ChangeRequestId
|
单个变更请求案例的唯一标识符,将从启动到关闭的所有相关活动归为一组。 | ||
|
描述
“变更请求 ID”是唯一标识每个变更计划全生命周期的主键。在流程挖掘中,它作为案例标识符,将提交、评估、审批和实施等所有事件链接到一个完整且内聚的流程实例中。 利用变更请求 ID 分析数据,可以获得变更管理流程的完整端到端视图。这有助于追踪单个变更、计算总周期时间,并识别每个请求特有的流程偏差或瓶颈。
为何重要
这是核心案例标识符,它链接了所有相关事件,使得追踪变更请求的全过程并分析其绩效成为可能。
获取方式
这通常是 Ivanti Cherwell 中“变更请求”业务对象的主要标识符。
示例
CR-105421CR-105422CR-105423
|
|||
|
活动名称
ActivityName
|
在变更管理流程中某个时间点发生的特定事件或任务的名称。 | ||
|
描述
“活动名称”描述了变更请求生命周期中的特定步骤或里程碑,例如“提交变更评估”或“CAB 批准变更”。这些活动构成了所发现流程图中的节点。 在分析中,此属性对于可视化流程流向、识别事件顺序以及检测偏离标准程序的行为至关重要。它用于计算活动间的流转时间,并了解延迟发生的具体位置。
为何重要
此属性对于发现和可视化实际流程流至关重要,从而能够识别瓶颈、返工循环和违规路径。
获取方式
根据 Ivanti Cherwell 中与变更请求对象相关的状态变更、日志条目或特定事件日志生成。
示例
变更已提交评估变更等待审批变更已实施
|
|||
|
最后数据更新
LastDataUpdate
|
指示此事件数据上次从源系统提取或刷新的时间戳。 | ||
|
描述
此属性记录上次从 Ivanti Cherwell 提取数据的日期和时间。它不代表流程本身的事件,而是关于数据实时性的元数据。 这对于仪表板使用者了解分析的时效性非常重要。它有助于管理数据刷新计划,并确保决策是基于已知账龄的数据做出的。
为何重要
指示数据的实时性,这对于用户信任分析结果并理解其与当前业务状态的相关性至关重要。
获取方式
此时间戳是在数据提取、转换和加载 (ETL) 过程中生成并标记在每条记录上的。
示例
2024-05-21T02:00:00Z
|
|||
|
源系统
SourceSystem
|
提取数据源的记录系统。在此视图中,显示为“Ivanti Cherwell”。 | ||
|
描述
此属性标识事件数据的来源系统。在异构环境中,它有助于区分来自不同源的数据。对于此特定数据模型,它将是一个常量值,表示数据来自 Ivanti Cherwell。 虽然在单数据源模型中它看起来是静态的,但对于数据治理、可追溯性和未来与其他系统的集成至关重要。它确保了数据来源的清晰性,并有助于管理数据质量。
为何重要
提供有关数据来源的基本背景信息,这对于数据治理、故障排除和确保可追溯性至关重要。
获取方式
这通常是在 data 提取和 transformation 过程中添加的静态值,用于标记 dataset 的来源。
示例
Ivanti Cherwell
|
|||
|
变更团队
ChangeTeam
|
当前负责该变更请求的团队或小组。 | ||
|
描述
“变更团队”是分配给变更请求的组或部门。与变更负责人类似,这在流程中可能会发生变化,表示团队间的责任转移,例如从服务台转到网络工程团队。 此属性对于分析团队间的交接以及识别由特定团队引起的系统性延迟至关重要。它有助于解答哪些团队超负荷或哪里出现了沟通中断,直接支持“变更交接与资源利用率”分析。
为何重要
识别团队层面的职责,这是分析流程瓶颈、衡量团队绩效以及了解小组间交接延迟的关键。
获取方式
此信息通常存储在“变更请求”对象上的“所属团队”或类似的组分配字段中。
示例
网络运维数据库管理应用支持
|
|||
|
变更所有者
ChangeOwner
|
当前负责该变更请求的用户或个人。 | ||
|
描述
“变更负责人”是在特定阶段分配并对变更请求负责的人员。随着请求在生命周期中推进,此属性经常发生变化,表示人员间的交接。 分析变更负责人有助于了解资源工作量并识别与特定个人相关的瓶颈。它也是分析交接(延迟的重要来源)的基础。此属性支持“变更交接与资源利用率”仪表板。
为何重要
追踪个人职责,支持分析工作量分布、交接频率以及特定于资源的瓶颈。
获取方式
通常是“变更请求”业务对象中的“负责人”或“分配给”字段。
示例
爱丽丝·约翰逊鲍勃·威廉姆斯Charlie Brown
|
|||
|
变更状态
ChangeStatus
|
变更请求的当前或最终状态,例如“已关闭”、“已驳回”或“正在进行”。 | ||
|
描述
变更状态表示变更请求在特定时间点的状态或其最终结果。它是理解个案解决情况和识别异常的关键属性。 在流程分析中,此属性用于筛选特定结果,例如仅分析被驳回或取消的变更。它驱动了诸如“变更请求驳回率”等 KPI,并且对于理解变更管理流程的整体健康状况和效率至关重要。
为何重要
定义变更请求的结果,从而能够对驳回率、完成率以及开启与关闭个案的分布进行关键分析。
获取方式
这对应于 Ivanti Cherwell 中“变更请求”业务对象上的“状态”字段。
示例
已批准已驳回已结案已取消等待审批
|
|||
|
变更风险等级
ChangeRiskLevel
|
与变更相关的已评估风险等级,例如“低”、“中”或“高”。 | ||
|
描述
变更风险等级是在评估阶段分配的分类,用于量化变更可能带来的负面影响。此评估通常会影响审批流程和所需的审查级别。 在 Process Mining 中,此属性用于分析风险评估的一致性,并将风险与流程行为相关联。例如,可以检查高风险变更是否遵循了更严格的审批路径,或者是否具有更长的实施时间。它直接为“变更风险评估一致性”仪表板提供支持。
为何重要
可以分析风险如何影响流程流、审批周期和成功率,有助于确保高风险变更得到适当的审查。
获取方式
此值存储在“变更请求”对象上的“风险等级”或类似字段中,通常在风险评估活动期间填充。
示例
低中高严重
|
|||
|
更改类型
ChangeType
|
变更的分类,例如“标准”、“普通”或“紧急”。 | ||
|
描述
变更类型根据变更的性质、紧急程度和影响对请求进行分类。常见类型包括标准变更(预先批准、低风险)、常规变更(需要全面评估和批准)以及紧急变更(需要立即实施)。 此属性允许进行细分分析,以比较不同类别下的流程绩效。例如,它可以帮助确定紧急变更是否确实遵循了不同的快捷路径,或者标准变更是否真正以极低的摩擦力被处理。它是“问题变更类型绩效”仪表板的关键要素。
为何重要
按变更类型对流程进行细分对于比较绩效至关重要,有助于识别特定类别(如“紧急”)是否导致了瓶颈或偏差。
获取方式
对应于变更请求业务对象上的一个分类字段,可能命名为“变更类型”或“类别”。
示例
标准普通紧急
|
|||
|
目标完成日期
TargetCompletionDate
|
计划或商定的变更实施完成期限。 | ||
|
描述
“目标完成日期”是预期变更完成实施并经过验证的时间戳。此日期通常是服务水平协议 (SLA) 的一部分,是衡量绩效的主要基准。 此属性对于监控及时性和截止日期的遵守情况至关重要。通过与实际完成日期对比,可以计算“变更按时完成率”和“变更 SLA 达成率”等 KPI。它有助于主动识别有错过目标风险的变更。
为何重要
为衡量按时绩效和 SLA 达成情况提供基准,这些是流程效率和可靠性的关键指标。
获取方式
这通常是“变更请求”对象上的一个特定日期字段,通常标记为“目标日期”、“截止日期”或“SLA 目标”。
示例
2023-11-15T17:00:00Z2023-12-01T23:59:59Z2024-01-10T12:00:00Z
|
|||
|
业务单元
BusinessUnit
|
请求变更或将从变更中受益的业务单元或部门。 | ||
|
描述
此属性将变更请求与组织的特定部分(如“财务”、“营销”或“运营”)关联起来。这为技术流程提供了业务背景。 按业务单元分析可以查看变更需求的来源。这有助于内部计费模型、理解 IT 变更对不同业务职能的影响,并识别某些单元是否比其他单元有更复杂或更延迟的变更。
为何重要
提供业务背景,支持从组织角度分析变更需求、影响和绩效。
获取方式
这可以是“变更请求”对象上的一个字段,也可以从请求者的用户资料中继承。
示例
财务人力资源销售与市场运营
|
|||
|
受影响的服务
ServiceAffected
|
受变更影响的主要业务服务或配置项 (CI)。 | ||
|
描述
此属性识别变更请求针对的主要 IT 服务、应用程序或基础设施。它将变更管理流程与更广泛的 IT 服务管理版图联系起来。 按“受影响的服务”分析对于“最成问题的变更类型”KPI 至关重要,因为它有助于精准定位哪些服务变更最频繁,以及哪些服务与高驳回率或延迟相关。这为服务负责人提供了改进稳定性和管理技术债的宝贵见解。
为何重要
将变更关联到具体的业务服务,从而能够分析并识别哪些服务最不稳定或产生了最多有问题的变更。
获取方式
这通常是从配置管理数据库 (CMDB) 链接而来,并存储在“变更请求”对象上的“主要 CI”或“服务”字段中。
示例
电子邮件服务 (Exchange)ERP 系统 (SAP)核心网络交换机 (CISCO-4500X)
|
|||
|
变更优先级
ChangePriority
|
变更请求的优先级,表示其紧急程度和业务影响。 | ||
|
描述
变更优先级是通过结合变更的紧急程度和影响程度确定的分类。它帮助团队确定工作重点并有效分配资源,确保最关键的变更得到优先处理。 在分析中,优先级可用于观察高优先级变更是否比低优先级变更处理得更快。任何偏离预期的结果都可能表明在优先级划分或执行过程中存在效率低下或瓶颈。
为何重要
有助于分析流程是否正确优先处理了高影响力的变更,以及这些变更是否确实按预期得到了加速处理。
获取方式
通常是“变更请求”对象上名为“优先级”的字段。它可以手动设置,也可以由影响和紧急程度字段推导得出。
示例
1 - 紧急2 - 高3 - 中4 - 低
|
|||
|
变更提交者
ChangeSubmitter
|
最初创建或提交变更请求的用户。 | ||
|
描述
此属性标识启动变更请求的人员。这可能与变更负责人(在流程后期负责实施的人员)不同。 分析“变更提交者”有助于识别与请求质量相关的模式。例如,它可能会揭示某些个人或团队经常提交不完整的请求,从而导致驳回或返工。此洞察可用于提供针对性培训并提升整体提交质量。
为何重要
有助于追溯变更请求的来源,从而可以按个人或团队分析提交质量,并识别培训机会。
获取方式
这通常是“变更请求”对象上的“创建者”或“请求者”字段。
示例
Susan Miller陈大卫Maria Garcia
|
|||
|
实施周期
ImplementationCycleTime
|
计算得出的从变更实施开始到完成的持续时间。 | ||
|
描述
此指标量化了变更实施阶段所花费的时间。它计算为“开始实施变更”活动与“变更已实施”活动之间的时长。 此属性用于计算“平均变更实施时间”KPI,并支持“变更实施流向与延迟”仪表板。它有助于区分规划延迟与执行延迟,让团队能够将改进工作集中在技术实施工作本身。
为何重要
隔离实际实施阶段的绩效,有助于识别独立于审批延迟之外的技术或资源瓶颈。
获取方式
通过在 Process Mining 工具中或在数据转换期间查找实施开始和结束事件时间戳之间的时间差计算得出。
示例
4 小时 15 分钟1 天 2 小时30 分钟
|
|||
|
实际完成日期
ActualCompletionDate
|
变更实际实施并验证完成的时间戳。 | ||
|
描述
“实际完成日期”标志着变更请求的实施工作完成的时刻。这是一个关键里程碑,通过与计划期限进行对比来衡量绩效。 此属性与“目标完成日期”配合使用,以确定变更是否按时完成。它是计算“变更按时完成率”等 KPI 以及分析实施阶段延迟原因的核心输入。
为何重要
捕获实际完成时间,这对于计算按时交付率和分析延迟程度是必需的。
获取方式
当变更请求状态转为“已实施”或“已完成”时,通常会记录此日期。它可能是一个专用字段,也可能从该状态更改的时间戳中推断。
示例
2023-11-14T16:30:00Z2023-12-03T10:00:00Z2024-01-10T11:45:00Z
|
|||
|
审批周期时间
ApprovalCycleTime
|
计算得出的从提交变更审批到获得最终批准的持续时间。 | ||
|
描述
此指标衡量关键审批里程碑之间经过的时间。它在案例层面通过计算“提交变更评估”事件与“CAB 批准变更”事件之间的时间差得出。 此计算时长是“变更审批周期时间”仪表板及相关 KPI 的核心指标。分析其分布有助于精准定位审批阶段的瓶颈,无论这些瓶颈是源于特定的审批人、团队还是变更类型。
为何重要
直接衡量审批阶段的效率,有助于识别并消除在获取变更实施授权时的延迟。
获取方式
通过在数据后处理期间或在 Process Mining 工具中测量特定审批相关活动的时间戳之间的时长计算得出。
示例
2 天 4 小时18 小时 30 分钟5天
|
|||
|
拒绝原因
ChangeRejectionReason
|
解释变更请求为何被驳回的文本描述或类别。 | ||
|
描述
当变更请求被拒绝时,此属性会记录批准人提供的理由。这可以是从预定义列表中选择,也可以是自由文本说明。 这些信息对于“已拒绝变更请求分析” dashboard 至关重要。通过对拒绝原因进行分类和分析,企业可以识别变更提交中的常见问题,例如信息不完整、风险评估不足或业务冲突。这些见解可用于提高未来变更请求的质量。
为何重要
直接深入了解变更失败的原因,从而针对提交和评估流程进行定向改进,降低整体驳回率。
获取方式
此数据通常在专门的“驳回原因”字段或在状态更改为“已驳回”时填充的注释字段中捕获。
示例
实施计划细节不足风险评估不完整与其他排期变更冲突
|
|||
|
是否按时完成
IsOnTimeCompletion
|
一个计算出的标记,如果变更在目标日期当天或之前完成,则该标记为 true。 | ||
|
描述
这是一个通过比较“实际完成日期”与“目标完成日期”得出的布尔属性。它通过为每个变更请求提供清晰的“是否按时”指示,简化了分析。 此标记是计算“变更按时完成率”KPI 的基础。它可用作仪表板中的过滤器,以轻松隔离和分析延迟的变更,帮助识别导致延迟的常见根本原因。
为何重要
通过提供明确的期限达成结果(成功或失败),简化绩效分析,直接为按时完成率 KPI 提供数据支持。
获取方式
源系统中没有此属性。它是在数据转换期间通过比较 'ActualCompletionDate' <= 'TargetCompletionDate' 计算得出的。
示例
truefalse
|
|||
变更管理活动
| 活动 | 描述 | ||
|---|---|---|---|
|
变更已关闭
|
此活动是变更管理流程最终成功的终点。当变更请求状态设为“已关闭”时捕获,表示所有工作已完成。 | ||
|
为何重要
作为主要的成功终点,此活动对于计算成功完成变更的端到端周期时间至关重要。它确认了所有流程步骤均已结束。
获取方式
根据“变更请求”对象审计历史中最终状态更改为“已关闭”的时间戳推断得出。
捕获
根据最终状态更改为“已关闭”推断得出。
事件类型
inferred
|
|||
|
变更已实施
|
此里程碑表示变更的技术工作已完成。当变更请求状态更新为“已实施”或类似的待验证状态时捕获。 | ||
|
为何重要
这是一个关键的成功里程碑,也是“按时变更完成率”和“平均变更实施时间”KPI 的核心输入。它标志着执行阶段的结束。
获取方式
从“变更请求”对象的审计日志中推断,使用状态更改为“已实施”或“待验证”时的时间戳。
捕获
根据状态更改为“已实施”推断得出。
事件类型
inferred
|
|||
|
变更已排期
|
此活动标志着变更实施日期和时间正式确认并记录的时刻。在状态更新为“已排期”时捕获。 | ||
|
为何重要
这是一个关键的承诺里程碑。它将变更从已批准的概念转为已计划的操作,是实施的前提条件。
获取方式
通过获取“变更请求”对象历史中“状态”字段更新为“已排期”的时间戳来推断。
捕获
根据状态更改为“已排期”推断得出。
事件类型
inferred
|
|||
|
变更已由 CAB 批准
|
一个关键里程碑,即变更咨询委员会 (CAB) 或指定机构授予变更执行许可。当变更请求状态更新为“已批准”时,即可推断出该活动。 | ||
|
为何重要
此活动是衡量审批周期时间的终点。它解除了流程阻塞,使规划和实施得以开始,对“变更审批周期时间”KPI 至关重要。
获取方式
通过“变更请求”对象的审计历史推断,特别获取“状态”字段更改为“已批准”时的时间戳。
捕获
根据状态更改为“已批准”推断得出。
事件类型
inferred
|
|||
|
变更请求已创建
|
此活动标志着系统中新变更请求的启动。通常在“变更请求”业务对象中创建新记录时捕获,确立了整个流程的起点。 | ||
|
为何重要
这是流程的主要启动事件。分析从该活动到其他活动的时间,可以揭示总生命周期时长,并有助于识别流程前期的延迟。
获取方式
此事件是从“变更请求”记录的创建时间戳中捕获的。在 Ivanti Cherwell 中,这通常存储在“变更请求”业务对象的 'CreatedDateTime' 字段中。
捕获
直接从记录创建时间戳中获取。
事件类型
explicit
|
|||
|
已执行实施后审查
|
此活动表示已对完成的变更进行了正式审查,以评估其成功情况并总结经验教训。通常根据状态更改为“实施后审查”推断得出。 | ||
|
为何重要
追踪此项可确保变更形成闭环反馈。这对于持续改进至关重要,并直接支持“实施后审查率”KPI。
获取方式
通过“变更请求”对象的审计历史获取“状态”进入“实施后审查”等状态时的时间戳来推断。
捕获
根据状态更改为“实施后审查”推断得出。
事件类型
inferred
|
|||
|
影响与风险已评估
|
此活动表示变更请求的风险和影响分析已完成。通常在变更请求状态转换为表示准备好审批的状态(如“待审批”)时推断得出。 | ||
|
为何重要
追踪此活动有助于衡量评估阶段的时长,并确保在审批前始终执行风险分析,从而支持“风险评估合规率”KPI。
获取方式
从“变更请求”对象历史中推断。这是在“状态”字段从“评估中”更新为“等待 CAB 审批”等状态时获取的时间戳。
捕获
根据状态更改为“等待 CAB 审批”推断得出。
事件类型
inferred
|
|||
|
变更实施开始
|
代表变更技术执行的开始。通常在变更请求状态转为“正在进行”或“实施中”时推断得出。 | ||
|
为何重要
此活动标志着实施窗口的开始。此活动与“变更已实施”之间的时间间隔即为实际实施时长,是整体周期时间的关键组成部分。
获取方式
从“变更请求”对象的审计历史中推断,即“状态”字段更新为“正在进行”或“实施中”等值时的时间戳。
捕获
根据状态更改为“正在进行”推断得出。
事件类型
inferred
|
|||
|
变更已取消
|
代表一种终结状态,即已批准或正在进行的变更请求在完成前被撤回。此事件在状态更新为“已取消”时捕获。 | ||
|
为何重要
这是一个替代流程终点。分析变更被取消的原因和时间,可以揭示规划、资源分配或业务优先级转移方面的问题。
获取方式
通过获取审计历史中“变更请求”对象的“状态”字段更新为“已取消”的时间戳来推断。
捕获
根据状态更改为“已取消”推断得出。
事件类型
inferred
|
|||
|
变更已提交评估
|
代表正式提交新创建的变更请求进行初步评估。通常在变更请求状态从“新建”或“草稿”状态转为“评估中”等状态时推断得出。 | ||
|
为何重要
此活动标志着初始数据录入后正式变更流程的开始。创建和提交之间的时间间隔可以反映出用户培训需求或流程摩擦。
获取方式
通过识别“变更请求”对象的审计日志或历史中“状态”字段更改为“评估中”或“已提交”等值的时间戳来推断。
捕获
根据状态从“新建”更改为“评估中”推断得出。
事件类型
inferred
|
|||
|
变更已驳回
|
此活动代表审批阶段驳回变更请求的最终决策。在变更请求状态设为“已驳回”时捕获。 | ||
|
为何重要
这是一个关键的失败终点。分析被驳回的变更及其原因,有助于提高初始请求的质量,并支持“变更请求驳回率”KPI。
获取方式
根据审计历史中“变更请求”对象的“状态”字段更新为“已驳回”时的时间戳推断。
捕获
根据状态更改为“已驳回”推断得出。
事件类型
inferred
|
|||
|
变更等待审批
|
此活动代表变更请求正式等待变更咨询委员会 (CAB) 或其他审批机构决策的阶段。根据“待审批”或“等待 CAB”等状态推断得出。 | ||
|
为何重要
这是一个关键的等待活动。分析其持续时间有助于识别审批流中的瓶颈,而审批流是变更管理中常见的延迟来源。
获取方式
从变更请求业务对象的“状态”字段更新为“等待审批”或等效值的时间戳中捕获。
捕获
通过进入“等待审批”状态来识别。
事件类型
inferred
|
|||
|
已制定实施计划
|
标志着变更详细规划的完成,包括定义任务、资源和回滚计划。这通常在变更从“已批准”转为“已排期”时推断得出。 | ||
|
为何重要
此活动的持续时间揭示了变更规划阶段的效率。即使在获得批准后,此处的延迟也会影响整个变更时间线。
获取方式
这可以根据从“已批准”到“已排期”的状态更改时间戳推断得出。或者,它可以与特定规划字段的填充相关联。
捕获
根据状态从“已批准”更改为“已排期”推断得出。
事件类型
inferred
|
|||
|
执行变更验证
|
代表测试和验证阶段,以确认变更已成功且未产生任何负面影响。这根据状态更改为“验证”或“测试”推断得出。 | ||
|
为何重要
分析此活动的频率和持续时间可确保质量保证步骤不被跳过。这是防止变更引发事故的关键步骤。
获取方式
从变更请求对象上状态变更的时间戳中捕获,例如移动到“验证”或“用户验收测试”状态。
捕获
根据状态更改为“验证”推断得出。
事件类型
inferred
|
|||