您的变更管理数据模板
您的变更管理数据模板
- 建议收集的属性
- 需要追踪的关键活动
- Freshservice 数据提取指南
变更管理属性
| 名称 | 描述 | ||
|---|---|---|---|
|
Event 时间
EventTime
|
特定活动或事件发生的准确日期和时间。 | ||
|
描述
流程中的每个活动都有对应的时间戳,标记其发生时间。这些时间数据对于计算活动间的持续时间、识别等待时间以及分析流程的总周期至关重要。它支持进行绩效分析、瓶颈识别以及 SLA 遵守情况的监控。
为何重要
此时间戳是所有基于时间的分析的基础,包括计算周期时间、持续时长以及步骤间的等待时间。
获取方式
Freshservice 变更记录审计日志或活动流中每个条目关联的时间戳。
示例
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:15:00Z
|
|||
|
变更请求 ID
ChangeRequestId
|
在 Freshservice 系统中提交的每个变更请求的唯一标识符。 | ||
|
描述
变更请求 ID 是单个变更案例从发起至关闭的主要标识符。它将所有相关活动、审批和日志串联成一条连贯的时间线,实现端到端流程分析。在流程挖掘中,此 ID 对于重建每个变更的生命周期以了解其路径、时长和结果至关重要。
为何重要
这是核心 Case ID,它将所有相关事件分组合并,从而能够追踪并分析单个变更请求的全流程。
获取方式
这是 Freshservice 变更对象上的一个主要字段。
示例
CHG-10234CHG-10235CHG-10236
|
|||
|
活动名称
ActivityName
|
变更管理流程中发生的特定事件或任务的名称。 | ||
|
描述
此属性描述了变更生命周期中的单个步骤或里程碑,如“已创建变更请求”、“已请求审批”或“实施已完成”。特定变更请求 ID 的活动序列构成了流程图的基础。分析这些活动有助于识别流程路径、检测偏差并测量各阶段所耗时长。
为何重要
它定义了流程中的步骤,支持变更生命周期的可视化以及流程变体和瓶颈的分析。
获取方式
生成自 Freshservice 变更记录的审计日志、活动流或状态变更历史。
示例
变更已批准风险评估已完成开始实施变更已关闭
|
|||
|
最后数据更新
LastDataUpdate
|
指示此 record 数据上次从源系统刷新的 timestamp。 | ||
|
描述
此属性记录每个事件最近一次数据提取或更新的日期时间。这对于了解所分析数据的新鲜度至关重要,确保分析基于最新信息,有助于维护数据完整性并提供洞察及时性的背景。
为何重要
确保用户了解数据的时效性,并有助于验证 Process Mining 分析的现势性。
获取方式
此时间戳通常在数据摄取或 ETL 过程中生成并添加。
示例
2024-05-20T08:00:00Z2024-05-21T08:00:00Z
|
|||
|
源系统
SourceSystem
|
用于标识数据提取自哪个系统。 | ||
|
描述
此属性指定流程数据的来源。在此视图中,该值始终为“Freshservice”。包含此属性是最佳实践,尤其是在可能整合多个系统数据的情况下,它提供了必要的上下文,有助于数据治理和故障排除。
为何重要
提供清晰的数据来源信息,这在分析来自多个企业系统的数据时至关重要。
获取方式
这是在数据提取过程中设置的静态值,用于标记数据来源。
示例
Freshservice
|
|||
|
变更优先级
ChangePriority
|
分配给变更请求的优先级,指示其业务重要性。 | ||
|
描述
优先级通常由影响程度和紧急程度共同决定,用于指导资源分配和排期。通过分析优先级对周期时间和 SLA 达成率等流程指标的影响,可以揭示高优先级变更的处理速度是否优于低优先级,有助于评估优先级策略的有效性。
为何重要
有助于判断流程是否有效地优先处理高重要性变更,并相应地分配资源。
获取方式
这是 Freshservice 变更对象中的“优先级 (Priority)”字段。
示例
低中高紧急
|
|||
|
变更状态
ChangeStatus
|
变更请求的当前或最终状态。 | ||
|
描述
此属性指示变更请求在特定时间点的状态或其最终结果,如“已关闭”、“已取消”或“已拒绝”。它对于结果分析至关重要,有助于区分成功完成的变更与失败或放弃的变更。按状态筛选可以针对特定变更群体进行深度分析。
为何重要
支持分析变更结果,有助于了解成功率、失败率和取消率。
获取方式
这是 Freshservice 变更对象中的“状态 (Status)”字段。
示例
已结案已取消已驳回未结
|
|||
|
指派小组
AssignedGroup
|
负责实施该变更的团队或小组。 | ||
|
描述
此属性指定分配执行变更工作的团队,如“网络团队”或“数据库管理员”。按指派组分析流程绩效是了解团队负载、效率及识别资源瓶颈的关键。它可以揭示哪些团队实施时间较长或实施后问题发生率较高。
为何重要
支持分析各实施团队的绩效和工作量,以识别资源限制或发掘最佳实践。
获取方式
这是 Freshservice 变更对象中的“组 (Group)”或“指派组”字段。
示例
基础设施团队应用支持安全运营
|
|||
|
更改类型
ChangeType
|
变更的分类,例如标准、常规或紧急。 | ||
|
描述
“变更类型”根据其性质、风险和审批要求对变更请求进行分类。“标准变更”是预先批准的,“常规变更”遵循标准流程,而“紧急变更”需要加急处理。按“变更类型”分析流程对于理解不同类型的变更是否遵循不同的路径以及是否具有不同的绩效特征(如周期时间或成功率)至关重要。
为何重要
按变更类型细分流程,有助于揭示标准、常规和紧急变更在流程行为和绩效水平上的差异。
获取方式
这是 Freshservice 变更对象中的“变更类型 (Change Type)”字段。
示例
标准常规紧急重大
|
|||
|
申请人姓名
RequesterName
|
发起变更请求的人员姓名。 | ||
|
描述
请求人是提交变更申请的人。按请求人分析数据有助于识别模式,例如哪些人员或角色频繁提交变更,或者来自某些用户的请求是否更容易被拒绝或需要返工。结合部门信息,也可用于工作负载分析。
为何重要
识别变更需求的来源,并能突出培训需求或变更量较大的特定用户群体。
获取方式
这是 Freshservice 变更对象中的“请求人 (Requested by)”字段,链接到用户记录。
示例
爱丽丝·约翰逊Robert SmithMaria Garcia
|
|||
|
目标完成日期
TargetCompletionDate
|
计划完成日期或服务级别协议 (SLA) 规定的变更截止日期。 | ||
|
描述
此日期代表关闭变更请求的最后期限,是衡量 SLA 达成情况的主要基准。通过比较实际结束时间与目标完成日期,可以判定变更是否准时、提前或逾期,它是“变更 SLA 达成率”KPI 的核心输入。
为何重要
作为衡量准时交付和 SLA 合规性的基准,这是反映流程绩效的关键指标。
获取方式
这可能是 Freshservice 变更对象上专用的“截止日期”或“SLA 目标”字段。
示例
2023-11-10T17:00:00Z2023-11-15T17:00:00Z
|
|||
|
结束时间
EndTime
|
该变更请求案例最后一次记录事件的时间戳。 | ||
|
描述
结束时间标志着变更请求生命周期的终点,通常对应“变更关闭”或“变更取消”活动。它与开始时间配合使用,计算每个案例的端到端总周期。分析此属性有助于了解变更管理流程的整体时长和吞吐量。
为何重要
这对于计算变更请求的总周期时间(流程效率的核心 KPI)至关重要。
获取方式
这是特定变更请求 ID 在事件日志中最后一项活动的时间戳。
示例
2023-11-05T18:00:00Z2023-11-06T09:45:00Z
|
|||
|
风险等级
RiskLevel
|
评估与实施该变更相关的风险等级。 | ||
|
描述
风险等级对变更失败可能产生的负面影响进行分类,通常分为低、中、高。此属性对于合规分析至关重要,有助于了解高风险变更是否遵循了更严谨的流程路径(如需要更多审批或更彻底的测试),确保风险管理控制得到正确执行。
为何重要
这对于合规与风险分析至关重要,确保高风险变更受到适当审查并遵循更稳健的流程。
获取方式
这对应 Freshservice 变更对象中的“风险 (Risk)”字段。
示例
低中高非常高
|
|||
|
关联事故数量
AssociatedIncidentsCount
|
实施后与此变更请求关联的事件数量。 | ||
|
描述
此指标通过统计因部署变更而导致的后续事件数量,量化了变更的下游影响。数值过高表明在计划、测试或实施质量方面可能存在问题。它是“实施后问题率”KPI 的直接输入项,对于衡量变更的稳定性和成功率至关重要。
为何重要
直接衡量已实施变更的质量和稳定性,有助于识别导致服务中断的变更。
获取方式
通过统计 Freshservice 中关联到特定变更工单的事故(Incident)工单数量得出。
示例
015
|
|||
|
关闭代码
CloseCode
|
一个代码或原因,说明变更请求关闭的原因。 | ||
|
描述
关闭代码提供已关闭变更结果的具体详情,例如“成功实施”、“已回滚”或“已拒绝”。这些数据提供了最终状态之外的宝贵上下文,支持对流程中的成功和失败模式进行更细致的分析。
为何重要
提供变更结果的细微详情,以便深入分析变更成功、失败或撤销的原因。
获取方式
请查阅 Freshservice 文档或在变更表单中查看“Closure Code”或类似字段。
示例
成功成功但存在问题失败回滚
|
|||
|
实施时长
ImplementationDuration
|
变更实施阶段所花费的时间。 | ||
|
描述
此指标计算核心实施工作的时长,通常从“实施开始”活动到“实施完成”活动进行测量。它用于分析技术执行阶段的效率,并为“变更实施阶段效率”仪表板提供支持。耗时过长可能意味着技术复杂、资源短缺或遇到不可预见的挑战。
为何重要
衡量实际技术工作的效率,将其与规划和审批延迟分开分析。
获取方式
计算方式为“已开始实施”与“实施已完成”活动之间的时间差。
示例
4 小时1 小时 30 分钟8 小时
|
|||
|
审批时长
ApprovalDuration
|
变更请求处于审批阶段的时长。 | ||
|
描述
此计算出的时长衡量从请求审批到获得批准或被拒绝的时间。它对于“变更审批阶段时长”仪表板至关重要,有助于发现审批流中的瓶颈。分析此指标可以揭示审批慢、组间交接效率低或系统性的决策延迟问题。
为何重要
直接衡量审批阶段的效率,有助于识别并解决延误变更的瓶颈。
获取方式
计算方式为“已请求审批”活动与“变更已批准”或“变更已拒绝”活动之间的时间差。
示例
1 天 2 小时5 小时 30 分钟3 天
|
|||
|
影响等级
ImpactLevel
|
评估如果变更失败或导致服务中断对业务产生的影响。 | ||
|
描述
影响级别指示对业务运营的潜在影响,范围从低(影响单个用户)到高(影响整个组织)。它与紧急程度共同决定了整体优先级。按影响分析有助于了解流程是否正确处理了那些对业务连续性构成重大威胁的变更。
为何重要
有助于风险分析,并确保对具有潜在高业务影响的变更进行更审慎的管理。
获取方式
这对应 Freshservice 变更对象中的“影响 (Impact)”字段。
示例
低中高
|
|||
|
总周期时间
TotalCycleTime
|
从创建到关闭变更请求的总经过时间。 | ||
|
描述
此指标计算特定变更请求的首末事件之间的时间间隔,代表了端到端处理时长,是衡量整体流程效率的基础 KPI。分析总周期有助于识别耗时过长的案例,并为改进计划提供基准。
为何重要
这是衡量变更管理流程从开始到结束整体速度和效率的核心 KPI。
获取方式
通过从每个“变更请求 ID”的最后一个事件的时间戳中减去第一个事件的时间戳计算得出。
示例
2 天 4 小时 30 分钟10 天 0 小时 0 分钟1 小时 15 分钟
|
|||
|
是否发生SLA违约
IsSlaBreached
|
一个布尔标志,指示变更请求是否在目标日期之后才完成。 | ||
|
描述
此属性是 SLA 合规性的二元标识:若变更的结束时间晚于目标完成日期,则为“true”,否则为“false”。它简化了 SLA 达成率相关仪表板和 KPI 的创建,支持快速筛选和聚合逾期变更,直接服务于“变更 SLA 达成率”指标。
为何重要
为 SLA 表现提供清晰的二元结果,简化了准时变更与逾期变更的筛选和报告工作。
获取方式
通过对比 EndTime 和 TargetCompletionDate 计算得出。如果 EndTime > TargetCompletionDate,则为 true。
示例
truefalse
|
|||
|
紧急程度
Urgency
|
从业务角度指示变更实施的紧急程度。 | ||
|
描述
紧急程度反映了变更的时间敏感性。例如,安全补丁可能具有高紧急性。此属性通常与影响程度结合以设定优先级,有助于分析流程是否对时间紧迫的业务需求做出了恰当反应,揭示紧急变更在流程中是否真的处理得更快。
为何重要
提供变更时间敏感性的上下文,可与周期时间关联以评估流程响应速度。
获取方式
这是 Freshservice 变更对象中的“紧急程度 (Urgency)”字段。
示例
低中高
|
|||
|
部门名称
DepartmentName
|
发起变更请求的用户的所属部门。 | ||
|
描述
此属性通过识别发起变更请求的业务部门来提供组织上下文。按部门分析可以发现哪些部门变更最频繁、拒绝率最高或周期时间最长。这些洞察对于针对性的流程改进和资源规划非常有价值。
为何重要
支持分析来自不同业务单元的流程绩效和需求,助力实施针对性改进。
获取方式
此信息通常源自 Freshservice 中请求人的用户个人资料。
示例
财务人力资源信息技术市场营销
|
|||
变更管理活动
| 活动 | 描述 | ||
|---|---|---|---|
|
变更已关闭
|
这标志着变更管理流程正式成功完成。当变更工单状态进入最终的“已关闭”状态时,此事件会被捕获。 | ||
|
为何重要
这是流程的主要结束事件。它是计算端到端“平均变更周期时间”和“变更 SLA 达成率”的最终数据点。
获取方式
此事件是从变更工单历史记录中最终状态改为“已关闭”的时间戳中捕获的。
捕获
状态最终更改为“已关闭”的时间戳。
事件类型
explicit
|
|||
|
变更已批准
|
一个关键里程碑,即指定机构(如变更咨询委员会 CAB)正式批准变更请求继续进行。这通常是记录在系统中的明确操作。 | ||
|
为何重要
标志着审批阶段结束和实施规划开始。此活动对于衡量“平均变更审批时间”和“一次审批通过率”至关重要。
获取方式
当审批人点击“批准”按钮时,Freshservice 会将其记录为一个明确事件。该事件会带有时间戳记录在工单的活动日志中。
捕获
审批选项卡或活动日志中“已批准”操作的时间戳。
事件类型
explicit
|
|||
|
变更已调度
|
为已批准变更的实施分配特定开始和结束时间。通常在填写“计划开始时间”和“计划结束时间”字段时推断此活动。 | ||
|
为何重要
这是触发实施阶段开始的关键里程碑。对于计算“平均实施时间”和分析排期效率至关重要。
获取方式
根据进度相关日期字段被填充且状态变为“已调度”或类似状态的时间戳来推断。
捕获
根据“计划开始日期”的填写以及相应的状态更新来推断。
事件类型
inferred
|
|||
|
变更请求已创建
|
这标志着变更管理流程的正式启动,即在 Freshservice 中正式记录一个新的变更请求。当用户保存新的变更工单并生成唯一的变更请求 ID 和创建时间戳时,此事件会被明确捕获。 | ||
|
为何重要
这是流程的主要开始事件。分析从该活动到“变更已关闭”的时间可获得端到端周期,这是衡量流程效率的关键 KPI。
获取方式
这是从变更记录审计历史中捕获的明确事件,对应于变更工单的创建时间戳。
捕获
变更请求记录的创建时间戳。
事件类型
explicit
|
|||
|
实施已完成
|
表示变更实施的技术工作已完成。这通常根据状态更改为实施后状态(如“待评审”)来推断。 | ||
|
为何重要
此里程碑标志着核心实施工作的结束。它是计算“平均实施时间”的终点,并预示着测试或评审活动的开始。
获取方式
根据状态更改为“待评审”、“等待测试”或“已完成”等值来推断。
捕获
根据状态字段更改为“待评审”或类似状态来推断。
事件类型
inferred
|
|||
|
变更已取消
|
表示变更请求在完成前终止。这是一种可选的结束状态,在工单状态设为“已取消”或“已撤回”时捕获。 | ||
|
为何重要
分析已取消的变更可以揭示初始规划或审批阶段的问题,例如不再需要的请求或缺乏有效业务案例的提案。
获取方式
根据状态更改为“已取消”或非“已关闭”的等效终结状态的时间戳捕获。
捕获
状态更改为“已取消”的时间戳。
事件类型
explicit
|
|||
|
变更已拒绝
|
表示审批人已正式拒绝变更请求,阻止其继续进行。此操作会被明确记录,通常会导致流程进入返工循环。 | ||
|
为何重要
此活动对于分析返工和识别流程失败原因至关重要。拒绝频率过高通常指向请求质量问题或风险评估不足。
获取方式
当审批人点击“拒绝”按钮时,Freshservice 会将其记录为一个明确事件。该事件记录在工单的活动日志中。
捕获
审批选项卡或活动日志中“已拒绝”操作的时间戳。
事件类型
explicit
|
|||
|
变更已重新开启
|
指之前已关闭或解决的变更恢复为开启状态,通常是由于实施后发现了问题。这根据状态从关闭变为开启来推断。 | ||
|
为何重要
此活动是返工或变更失败的强信号。追踪其频率对于理解变更质量和测试有效性至关重要。
获取方式
通过在工单活动日志中检测到状态从“已关闭”或“已解决”跳回“开启”或“进行中”状态来推断。
捕获
检测状态是否从终结状态(如“已关闭”)变回非终结状态(如“开启”)。
事件类型
inferred
|
|||
|
实施后评审已完成
|
表示完成了实施后评估 (PIR),以评估变更的成功情况并记录经验教训。当实施后添加了评审备注或更新了状态时,通常会推断出此活动。 | ||
|
为何重要
确保遵循正式的评审流程。分析此活动有助于了解变更的有效性,并支持流程的持续改进。
获取方式
根据实施日期后变更表单中 PIR 相关字段的填写,或状态更改为“评审完成”等状态来推断。
捕获
根据 PIR 备注字段的填写或特定状态更新来推断。
事件类型
inferred
|
|||
|
已为变更添加备注
|
表示在变更请求中添加了评论或备注,体现了沟通或记录活动。Freshservice 会在每张工单的活动源中明确记录这些事件。 | ||
|
为何重要
虽然不是核心流程步骤,但追踪备注可以提供延迟背景,特别是在审批或计划阶段。备注频率过高可能预示着需求不明或沟通不畅。
获取方式
在变更请求工单的“活动”或“审计”部分有明确记录,包含时间戳和添加备注的用户。
捕获
在工单活动日志中记录为“已添加备注”事件。
事件类型
explicit
|
|||
|
开始实施
|
标志着变更实际部署或执行的开始。当变更请求的状态更新为“进行中”或类似的活跃状态时,即可推断出此活动。 | ||
|
为何重要
为追踪实际实施时长提供清晰的起点,有助于区分等待时长与实际工作时长。
获取方式
根据在计划开始时间状态更改为“进行中”或“实施中”等值来推断。
捕获
根据状态字段更改为“进行中”来推断。
事件类型
inferred
|
|||
|
测试已完成
|
表示所有必要的测试和验证活动已完成,确保变更成功且未产生负面影响。这通常可以从任务关闭或状态更改中推断出来。 | ||
|
为何重要
追踪此活动有助于衡量“测试完成率”KPI,确保变更在最终关闭前经过妥善验证,从而减少实施后的问题。
获取方式
这可能难以直接捕获,或许需要从关联“测试”任务的完成情况或“测试完成”的状态更改中推断。
捕获
根据与变更关联的测试相关任务的关闭来推断。
事件类型
inferred
|
|||
|
计划已完成
|
表示变更的所有必要计划(包括实施和回滚方案)均已定稿。通常根据审批后的状态更改推断。 | ||
|
为何重要
标志着从规划到执行的转变。分析规划阶段的时长有助于发掘精简实施前活动的机会。
获取方式
根据状态从规划相关状态(如“待发布”)更改为实施状态(如“已调度”)来推断。
捕获
根据状态脱离“正在规划”或类似状态的变化来推断。
事件类型
inferred
|
|||
|
请求审批
|
表示变更请求正式提交审批的节点。通常在变更请求状态转为“等待审批”或分配给审批人时推断此事件。 | ||
|
为何重要
此活动标志着审批阶段的开始。测量从该点到“变更已批准”的时长,对于识别审批周期中的瓶颈至关重要。
获取方式
通过活动日志或追踪状态字段更改为“等待审批”来推断。此状态更改的时间戳将用作事件时间。
捕获
根据状态字段更改为“等待审批”来推断。
事件类型
inferred
|
|||
|
风险评估已完成
|
表示已完成对变更相关潜在风险的正式评估。当风险级别字段被填写/更新或相关任务完成时,通常会推断出此活动。 | ||
|
为何重要
追踪此活动有助于确保符合强制要求风险评估的变更策略,支持对“风险评估覆盖率”及这一关键步骤所耗时长的分析。
获取方式
这可能是根据变更表单中“风险”字段的时间戳更新,或风险分析相关特定任务的完成情况推断出的。
捕获
根据“风险”字段被填写或相关检查清单项目被标记为完成的时间戳来推断。
事件类型
inferred
|
|||