> 持续流程改进 > 变更管理 > Jira Service Management > 数据模板

您的变更管理数据模板

Jira Service Management

← 返回改进指南

变更管理属性(19) 变更管理活动(13) 数据提取指南(3)

您的变更管理数据模板

此模板将指导您收集分析变更管理流程所需的数据，涵盖关键属性、需要跟踪的主要活动，以及从Jira Service Management提取数据的实用方法。您可以据此构建准确的事件日志，深入了解变更流程。

建议收集的属性
流程中需要跟踪的关键活动
Jira Service Management数据提取指南

刚接触事件日志？了解如何创建流程挖掘事件日志.

下载模板

变更管理属性

为全面分析变更管理流程，建议在事件日志中加入以下数据字段。

5 必填 7 建议填写 7 选填

	名称	说明
	变更请求ID ChangeRequestId	用于唯一标识单个变更请求案例，并将从创建到关闭的所有相关活动归集在一起。
说明变更请求ID是Jira Service Management中唯一标识每项变更工作的主键。在流程挖掘中，它作为案例标识，将所有事件、状态变化和更新关联起来，形成完整的端到端流程视图。分析时，此ID可用于还原每项变更的完整生命周期，对于跟踪变更经过风险评估、审批、实施和评审等阶段至关重要。所有指标、KPI和仪表板都依赖此属性，正确汇总并关联特定变更的事件数据。重要性这是基本的案例标识，可用于追踪变更请求的完整历程并分析其表现。获取途径这是标准的Jira问题键，位于变更请求类型问题的`key`字段中。示例 ITSM-1024CHG-2023-001CR-5921
	开始时间 EventTime	表示特定活动或事件发生时间的准确时间戳。
说明开始时间，也称事件时间戳，表示变更请求活动被记录的准确日期和时间。事件日志中的每项活动，从创建到关闭，都有对应的时间戳。此属性是流程挖掘中所有时间分析的关键依据，可用于计算周期时间、活动间隔时长和等待时间，并确定事件顺序。它也是绩效监控、SLA达成情况计算和瓶颈识别的基础。重要性此时间戳是所有绩效和时长分析的基础，可用于计算周期时间并识别延误。获取途径 Jira问题历史记录中每条记录的时间戳。对于创建事件，此值来自`created`字段。示例 2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-05T09:00:00Z
	活动 ActivityName	变更管理流程中某个具体业务事件或任务的名称。
说明此属性记录变更请求在特定时间发生的活动名称。活动信息来自Jira中的状态转换、工作流步骤或特定日志条目，例如“已提交变更以供评审”或“实施已开始”。分析这些活动的顺序和频率是流程挖掘的核心。借此可以发现实际流程路径、识别步骤间的瓶颈，并将流程变体与标准操作规程进行比较。重要性它定义了流程的各个步骤，是发现流程图、分析变体和识别瓶颈的基础。获取途径通常从Jira问题历史记录中提取，具体包括状态转换或代表流程里程碑的自定义字段更新。示例变更请求已批准已执行风险评估变更已实施实施后评审已完成
	数据上次更新时间 LastDataUpdate	表示此记录数据上次刷新或提取时间的时间戳。
说明此属性记录上次从源系统提取数据的日期和时间，反映流程挖掘工具中数据的时效性。分析此属性有助于了解流程数据的更新程度，这对运营仪表板和实时监控十分重要。它为分析提供背景信息，确保决策不依赖过时数据。重要性显示数据的时效性，确保分析基于最新信息并具有参考价值。获取途径这是数据提取工具在提取数据时填写的元数据字段。示例 2024-01-15T02:00:00Z2024-01-16T02:00:00Z
	源系统 SourceSystem	标识变更管理数据的提取来源系统。
说明此属性用于说明流程数据的来源系统。在此场景中，其值始终为“Jira Service Management”。在更广泛的企业场景中，数据可能来自多个系统，此字段对于追踪数据来源、排查问题和了解系统特有的流程差异至关重要。它能明确标示正在分析的数据来自何处。重要性清楚标示数据来源，在合并多个系统的数据或进行审计时尤为重要。获取途径这是数据提取时添加的静态值，用于标记数据集的来源。示例 Jira Service Management
	SLA状态 SLAStatus	表示变更请求是否在目标完成日期前完成。
说明此计算属性将变更请求的实际解决日期与“目标完成日期”进行比较，结果为“已达成”或“已逾期”等简单状态。它能在“变更SLA绩效监控”仪表板中清晰呈现绩效状态。通过预先计算每个案例的状态，简化了“变更SLA达成率”等KPI的创建。您可以轻松筛选和汇总数据，查看哪些变更类型、团队或服务最常出现SLA逾期。重要性为每个案例提供清晰的SLA绩效结果，简化SLA达成情况的报告和分析。获取途径通过比较最后一次“变更已关闭”活动的时间戳与“TargetCompletionDate”属性计算得出。示例已达成已逾期
	优先级 Priority	分配给变更请求的优先级，体现其业务重要性。
说明优先级字段帮助团队确定处理变更请求的先后顺序。它综合反映影响和紧急程度，并为排期和资源分配提供依据。分析优先级有助于比较高优先级和低优先级变更的绩效。例如，您可以检查高优先级变更的周期时间是否确实更短，或是否也会遇到与其他变更相同的瓶颈。这有助于优化资源投入，并满足业务预期。重要性支持根据业务优先级分析流程绩效，确保关键变更按预期加快处理。获取途径这是Jira问题的标准`priority`字段。示例最高高中低
	变更状态 ChangeRequestStatus	事件发生时变更请求的当前状态或历史状态。
说明此属性表示变更请求的状态，例如“等待批准”“处理中”或“已关闭”。在Jira中，状态字段是工作流引擎的基础，状态变更也是推动流程前进的主要因素。分析状态有助于跟踪进行中变更的进度，并了解已完成变更的结果，例如“已关闭-成功”或“已关闭-失败”。这也是构建吞吐量仪表板、分析状态退回到先前阶段所形成返工循环的关键。重要性它能清晰呈现变更请求的进度和最终结果，这对吞吐量和返工分析至关重要。获取途径这是Jira问题的标准`status`字段。可用状态由项目的工作流配置定义。示例规划中等待批准实施中已关闭已取消
	变更类型 ChangeRequestType	变更的分类，例如标准、普通或紧急。
说明变更类型根据变更请求的性质、紧急程度和影响对其进行分类。常见类型包括“标准”，指预先批准的低风险变更；“普通”，指需要完整审批的常规变更；以及“紧急”，指为解决事件而进行的紧急变更。此属性对流程分析至关重要，因为不同变更类型通常遵循不同的流程路径，并适用不同的SLA。它用于计算“紧急变更率”KPI，也可用于筛选仪表板，以比较各类变更的绩效和风险。重要性它支持按类型细分流程，分析不同工作流，例如标准变更与紧急变更，因为两者的绩效预期和风险各不相同。获取途径这通常是Jira Service Management项目中的自定义字段。字段名称可能有所不同，但通常称为“变更类型”。示例标准普通紧急
	目标完成日期 TargetCompletionDate	计划完成变更请求的日期，或其服务级别协议（SLA）规定的截止日期。
说明此属性记录变更请求应完成的日期，以满足其SLA要求。实际完成时间将以此日期为基准进行衡量。此日期是监控承诺履行情况的基础，也是“变更SLA绩效监控”仪表板和“变更SLA达成率”KPI的依据。通过将实际解决日期与目标日期进行比较，组织可以衡量服务交付成效。重要性这是计算SLA达成情况、识别可能逾期变更的主要数据点。获取途径这通常是Jira中的`duedate`字段，或Jira Service Management中已配置的SLA指标值。示例 2023-11-15T17:00:00Z2023-12-01T23:59:59Z2024-01-10T09:00:00Z
	经办人 Assignee	当前负责处理变更请求的用户。
说明经办人是负责变更管理工作流当前步骤或活动的用户。变更请求在不同人员和团队之间流转时，经办人可能会多次变更。此属性用于分析工作量分布、识别个人层面的瓶颈并了解资源分配情况。“变更团队活动工作量”仪表板依靠此数据，展示哪些个人或群组处理的活动最多。重要性这有助于分析资源绩效和工作量分布，并识别个人或团队的瓶颈。获取途径这是Jira问题的标准`assignee`字段。示例艾丽丝·约翰逊鲍勃·威廉姆斯查理·布朗
	风险等级 RiskLevel	变更的评估风险等级，例如低、中或高。
说明在大多数变更管理流程中，风险等级都是必需的评估项，用于对变更可能造成的负面影响进行分类。风险等级在风险评估阶段确定，并通常会影响所需的审批工作流。在流程挖掘中，此属性对基于风险的分析至关重要。它支持“风险评估准确性与结果”仪表板，可将初始风险与实际结果关联起来。它也是“按风险等级划分的变更失败率”KPI的主要维度，有助于评估高风险变更是否得到了有效管理。重要性支持分析流程控制和审批工作流是否适用于不同的风险情况，并帮助将风险与变更失败率关联起来。获取途径这通常是Jira Service Management中的自定义字段，常见名称包括“风险等级”或“影响”。示例低中高严重
	业务服务 BusinessService	受变更影响的业务服务或应用。
说明此属性将变更请求关联到配置管理数据库（CMDB）中定义的特定业务服务，例如“电子邮件服务”或“客户关系管理系统”。这是了解变更业务影响的关键概念。按业务服务分析变更，有助于确定工作优先级并向相关方说明影响。您可以了解哪些服务变更最多、哪些服务风险最高，以及与变更相关的事件集中在哪些服务上。这对于从业务角度管理技术变更至关重要。重要性将技术变更与业务影响关联起来，支持根据受影响服务的重要性确定优先级并分析风险。获取途径这通常是JSM中的自定义字段，常与Jira Assets（原Insight）或其他CMDB关联。示例公司网站SAP ERP内部维基
	变更原因 ChangeReason	提出变更的依据或业务原因。
说明此属性记录变更的根本原因，例如“实施新功能”“修复缺陷”或“升级基础设施”。相比摘要或说明，它能提供关键背景信息。分析时，可以将变更原因与周期时间、失败率和风险等级等指标关联起来。这有助于回答诸如“缺陷修复类变更是否比新功能实施更快获批？”或“基础设施升级的失败率是否更高？”等问题。重要性提供业务背景，支持将变更目的与绩效和结果关联起来，开展更深入的分析。获取途径这通常是Jira Service Management中的自定义字段，常见形式为下拉列表或文本字段。示例安全补丁软件升级安装新硬件
	团队 Team	负责变更请求或特定活动的团队或群组。
说明此属性用于标识负责处理变更的团队。Jira提供面向个人的“经办人”字段，而“团队”字段通常用于将工作分配给职能群组，例如“网络运营”或“数据库管理员”。此属性对“变更团队活动工作量”仪表板至关重要。它支持从团队层面而非仅从个人层面分析绩效和瓶颈，这通常更有助于资源规划和管理。重要性支持在团队或部门层面分析工作量和绩效，并揭示系统性瓶颈。获取途径这通常是Jira中的自定义字段，因为Jira没有标准的“团队”字段。字段类型可以是“群组选择器”，也可以是简单的下拉列表。示例基础设施团队核心服务应用支持
	实施后问题 PostImplementationIssue	用于标记实施后是否有事件或问题与此变更相关联。
说明此属性表示变更是否导致了负面结果，例如生产环境发生事件。通常需要将变更请求问题与Jira中的一个或多个事件问题关联起来。此数据对于计算“实施后问题率”和“变更失败率”KPI至关重要。它直接衡量变更质量，以及规划、测试和风险评估流程的成效。分析哪些变更导致了问题，有助于完善控制措施并防止未来发生故障。重要性通过跟踪变更是否引发后续运营问题，直接衡量变更的质量和成效。获取途径通常通过检查Jira中的关联问题得出，具体来说，是检查变更问题是否存在来自事件问题的“由其导致”链接。示例 truefalse
	报告人 Reporter	最初创建或提交变更请求的用户。
说明报告人是在Jira中创建变更请求问题的用户，通常是变更负责人，或代表团队发起变更的人员。分析报告人有助于识别哪些部门、团队或个人发起的变更多。您可以据此发现变更来源趋势，并为经常提交信息不完整或质量较低的变更请求的群组提供反馈或培训。重要性有助于识别变更请求的来源，并据此改进初始提交的质量。获取途径这是Jira问题的标准`reporter`字段。示例大卫·米勒伊娃·格林弗兰克·赖特
	是否返工 IsRework	布尔标记；如果变更请求经历过返工循环，则值为true。
说明此计算属性用于识别被退回到先前阶段修改的变更请求，例如从“等待批准”退回到“规划中”。这表明初始提交的信息不完整、有误，或未满足必要条件。此标记是“变更返工率”KPI和“变更返工与拒绝分析”仪表板的依据。标记返工案例后，分析人员可以轻松筛选并调查根本原因，例如初始规划不充分、需求不明确或风险评估不足。重要性通过明确标记需要额外计划外工作的案例，揭示流程效率问题，并支持分析返工的根本原因。获取途径通过分析事件日志中的活动顺序计算。如果后续阶段的活动之后出现了较早阶段的活动，则判定为返工。示例 truefalse
	解决结果 Resolution	已关闭变更请求的最终结果，说明变更如何解决。
说明变更请求关闭时，“解决结果”字段会提供具体结果信息。例如，“已完成”表示成功，“不予处理”或“重复”则说明了其他关闭原因。与仅查看“已关闭”状态相比，这些信息能提供更多背景。此属性对分析变更成功率和失败率至关重要。例如，按“失败”或“已回滚”结果筛选变更，可以更准确地解读“实施后问题率”KPI。它有助于区分成功实施的变更，以及批准后被取消或拒绝的变更。重要性提供变更最终结果的详细背景信息，这对准确计算成功率和失败率至关重要。获取途径这是Jira中的标准`resolution`字段，通常在问题进入“已完成”状态类别时设置。示例已完成不予处理重复已取消已回滚

必填建议填写选填

变更管理活动

为准确发现变更管理流程，建议在事件日志中记录以下关键步骤和里程碑。

5 建议填写 8 选填

	活动	说明
	变更已关闭	表示变更请求已最终关闭，所有相关活动均已完成。当Jira问题状态变为“已关闭”或“已完成”等最终解决状态时，即可记录此事件。
重要性这是流程的主要终点，用于计算整体周期时间并确定SLA达成情况。获取途径通过检查Jira问题历史记录，识别“status”字段变为最终关闭状态的时间戳来推断。此时通常也会设置解决结果字段。采集跟踪状态变为“已关闭”或“已完成”的时间戳。事件类型 inferred
	变更已实施	这是一个关键里程碑，表示变更相关工作已完成。可根据Jira工作流中的状态变化记录，例如变为“已实施”或“待验证”。
重要性此活动标志着实施阶段结束，是计算实施周期时间的关键，也是触发实施后评审和验证活动的依据。获取途径通过检查Jira问题历史记录，识别“status”字段变为“已实施”或“待实施后评审”的时间戳来推断。采集跟踪状态变为“已实施”或类似状态的时间戳。事件类型 inferred
	变更等待审批	表示变更请求已通过初步评审，正在等待变更咨询委员会（CAB）或指定审批人的正式决定。可根据工作流中的状态变化记录，例如变为“待审批”或“等待CAB审批”。
重要性此活动是衡量审批等待时间和识别决策阶段瓶颈的关键，直接影响变更审批周期时间KPI。获取途径通过检查Jira问题历史记录，识别“status”字段变为“待CAB审批”或“等待审批”等审批状态的时间戳来推断。采集跟踪状态变为指定“等待审批”状态的时间戳。事件类型 inferred
	变更请求已批准	这是一个关键里程碑，表示变更已获正式批准，可以实施。通常可根据Jira工作流中的状态变化推断，例如变为“已批准”或“准备实施”。
重要性此事件标志着审批周期结束、实施阶段开始。它对于衡量审批周期时间和跟踪未经授权的变更至关重要。获取途径通过检查Jira问题历史记录，识别“status”字段变为“已批准”状态的时间戳来推断。采集跟踪状态变为“已批准”或“准备实施”的时间戳。事件类型 inferred
	已创建变更请求	表示在Jira Service Management中首次创建变更请求工单。首次保存“变更”类型的新问题时，系统会记录创建时间戳。
重要性这是所有变更请求的起点，对于衡量整体周期时间和分析一段时间内的变更请求量至关重要。获取途径从Jira问题对象的“created”时间戳获取。这是每个问题都具备的标准系统字段，可通过问题历史记录或API读取。采集使用Jira问题中的“created”字段时间戳。事件类型 explicit
	变更已取消	表示变更请求在实施或完成前终止。当Jira问题状态变为“已取消”或“已撤回”等终止状态时，即可记录此事件。
重要性此替代终点有助于分析变更被放弃的原因。取消率较高可能意味着初始规划不充分，或业务优先级发生变化。获取途径通过检查Jira问题历史记录，识别“status”字段变为“已取消”状态且设置了相应解决结果的时间戳来推断。采集跟踪状态变为“已取消”或“已撤回”的时间戳。事件类型 inferred
	变更已排期	表示已批准的变更已安排具体实施时段。可根据Jira问题中的“计划开始日期”和“计划结束日期”字段被填写或更新来推断。
重要性此活动有助于了解变更的后续规划，支持资源管理，并帮助评估从批准到安排实施之间的时间。获取途径通过检查Jira问题历史记录，记录“计划开始日期”或“变更窗口”等日期字段被填写的时间戳来推断。采集跟踪“计划开始日期”字段被填写的时间戳。事件类型 inferred
	变更请求已拒绝	表示变更请求被正式拒绝，通常会退回给请求人补充信息，或直接取消。可根据Jira工作流中的状态变化记录，例如变为“已拒绝”或“需要更多信息”。
重要性跟踪拒绝情况对于分析变更返工率至关重要。此活动频繁发生，通常说明首次提交的变更质量存在问题。获取途径通过检查Jira问题历史记录，识别“status”字段变为“已拒绝”或类似终止状态的时间戳来推断。采集跟踪状态变为“已拒绝”或“未获批准”的时间戳。事件类型 inferred
	实施后评审已完成	表示已完成正式评审，用于评估变更成效并总结经验。通常可根据工作流中的状态变化记录，例如从“实施后评审”变为“已验证”。
重要性此活动对于流程改进至关重要。衡量评审周期时间有助于确保及时总结经验。获取途径通过检查Jira问题历史记录，识别“status”字段离开“实施后评审”状态的时间戳来推断。采集跟踪状态从“PIR”变为后续状态的时间戳。事件类型 inferred
	实施已开始	表示已批准变更的技术实施开始。通常可根据Jira状态从“已批准”或“已排期”变为“进行中”或“实施中”来记录。
重要性此活动启动平均实施周期时间的计时，有助于识别执行阶段的瓶颈。获取途径通过检查Jira问题历史记录，识别“status”字段变为“进行中”等实施状态的时间戳来推断。采集跟踪状态变为“进行中”或“实施中”的时间戳。事件类型 inferred
	已完成测试	表示已完成实施后测试，以验证变更效果。此活动可能对应“测试中”等独立状态，也可能根据“变更已实施”事件后QA团队的评论或更新推断。
重要性分析测试时长和结果，有助于评估实施质量和测试流程的有效性，也是计算实施后问题率的重要依据。获取途径可根据状态变为“测试中”或“正在测试”推断，也可分析实施后问题历史记录中的评论和负责人变更。采集跟踪状态变为“测试中”的时间戳，或根据评论确定时间。事件类型 inferred
	已执行风险评估	表示已完成拟议变更的风险和影响分析。通常可通过问题历史记录推断此事件，例如风险相关的自定义字段“风险等级”或“影响”被填写或更新时。
重要性分析此活动有助于评估风险评估的准确性，并确保符合变更政策。这也是计算基于风险的KPI（例如按风险等级统计的变更失败率）的重要依据。获取途径通过检查Jira问题历史记录，记录“风险等级”、“影响”或“紧急程度”等字段首次设置或更改的时间戳来推断。采集跟踪“风险等级”或“影响”等字段首次填写的时间戳。事件类型 inferred
	已提交变更以供评审	表示变更请求的初始信息已填写完整，并正式提交评估。通常可根据Jira工作流中的状态变化推断，例如从“草稿”变为“待评审”。
重要性此活动标志着审批周期开始。衡量从此时到获批所需的时间，对于计算审批周期时间KPI和识别早期瓶颈至关重要。获取途径通过检查Jira问题历史记录，识别“status”字段变为“待评审”或“等待评估”等评审状态的时间戳来推断。采集跟踪状态变为“待评审”、“已提交”或类似状态的时间戳。事件类型 inferred

建议填写选填

数据提取指南

如何从Jira Service Management获取数据

步骤

打开Jira问题导航器：登录您的Jira Service Management实例。在主导航栏中选择“Issues”，然后选择“Search for issues”，打开问题导航器。
切换到JQL搜索：如果当前使用“Basic”搜索模式，请点击“JQL”（部分版本中显示为“Advanced”）切换到高级模式，以输入自定义Jira查询语言（JQL）查询。
筛选变更请求：在搜索栏中输入本文档“query”部分提供的JQL查询。根据您的项目键、变更问题类型名称和所需日期范围调整占位值。
执行搜索并导出数据：运行搜索。显示变更请求问题列表后，找到通常位于右上角的“Export”按钮，然后选择“Export Excel CSV (all fields)”。该格式至关重要，因为它包含重建流程所需的详细问题历史记录。
加载CSV以进行转换：使用Power Query、基于pandas库的Python脚本或其他ETL工具打开下载的CSV文件。原始导出文件每个问题占一行，但其中包含历史数据列。
整理基础数据：针对源文件的每一行，创建初始“Change Request Created”事件。将“Issue key”用作ChangeRequestId，将ActivityName设为“Change Request Created”，并使用“Created”列作为EventTime。
展开状态历史记录：找到包含状态转换历史记录的列。每次状态变更都代表一个事件。针对每个变更请求，为每次相关状态转换新增一行，例如从“Draft”变为“Pending Review”，或从“Pending Approval”变为“Approved”。将这些转换映射到相应的ActivityName，例如“Change Submitted For Review”、“Change Awaiting Approval”和“Change Request Approved”等。状态变更时间作为EventTime。
展开字段更新历史记录：某些活动依据字段更新而非状态变更推断。处理“Risk Level”、“Planned start date”和“Planned end date”等字段的历史记录。为“Risk Assessment Performed”和“Change Scheduled”事件新增行，并使用这些字段首次填写或更新的时间。
映射并补充属性：针对创建的每个事件行，将相应的Jira字段映射到所需属性，例如ChangeRequestStatus、ChangeRequestType、Assignee和Priority。属性值应为事件发生时的当前值。
添加元数据列：添加名为SourceSystem的列，并将其固定值设为“Jira Service Management”。再添加LastDataUpdate列，填入执行数据提取的时间戳。
计算派生指标：创建完整事件日志后，计算需要多个数据点的属性，例如ApprovalCycleTime。具体做法是针对每个ChangeRequestId，计算“Change Submitted For Review”与“Change Request Approved”事件之间的时间差。
完成并导出以供上传：确认最终表格包含所需列：ChangeRequestId、ActivityName和EventTime。删除中间列或源数据列。将转换后的数据保存为UTF-8编码的CSV文件，并上传至流程挖掘工具。

配置

JQL筛选条件：JQL查询是筛选正确数据集的主要工具。关键筛选条件包括project、issuetype，以及针对created字段的日期范围。例如：created >= "-180d"。
日期范围：建议先选择3至6个月的数据，以确保数据具有代表性，同时避免影响性能。例如：created >= "-180d"。
问题类型：必须指定Jira实例中用于变更管理的问题类型准确名称，例如issuetype = "Change"或issuetype = "Change Request"。
导出格式：始终使用“Export Excel CSV (all fields)”。此选项可确保导出文件包含所有自定义字段，尤其是状态和字段的完整变更历史记录。仅导出有限字段将无法提供构建事件日志所需的数据。
Jira权限：执行导出的用户必须拥有指定项目的“Browse Projects”权限，以及查看所有相关问题字段所需的权限。
识别自定义字段：转换数据前，必须确认Jira实例中与“Risk Level”、“Planned start date”和“Change Type”等流程属性对应的自定义字段准确名称。

查询示例 config

project = "[Your_Project_Key]" AND issuetype = "Change" AND created >= "[Start_Date_YYYY-MM-DD]" AND created <= "[End_Date_YYYY-MM-DD]" ORDER BY created ASC

步骤

连接数据库：获取Jira Server或Data Center底层数据库的只读访问凭据。数据库可能为PostgreSQL、MySQL、SQL Server或Oracle。使用DBeaver、SQL Developer或pgAdmin等标准SQL客户端连接数据库。
确认Jira配置：运行查询前，必须确认Jira Service Management配置中使用的具体名称。登录Jira并打开您的变更管理项目，记录以下信息：
- 项目键：项目的简短标识，例如“CSM”。
- 问题类型名称：变更请求的准确名称，通常为“Change”。
- 工作流状态：变更工作流中各状态的名称，例如“Pending Review”、“Pending Approval”、“In Progress”和“Closed”等。
- 自定义字段名称：“Change Type”、“Risk Level”、“Planned start date”和“Planned end date”等自定义字段的名称。
自定义SQL查询：在SQL客户端中打开提供的SQL查询。将占位值替换为上一步收集的信息。需要更新的主要占位值包括[Your_JSM_Project_Key]、[Your Change Type Field Name]、[Your Risk Level Field Name]、[Your Planned Start Date Field Name]、[Your Planned End Date Field Name]，以及WHERE子句中的所有状态名称。
设置日期范围：在初始公用表表达式（CTE）中找到AND i.created >= '[YYYY-MM-DD]'这一行。修改日期以设定数据提取的起始时间。这有助于限制数据量并提升查询性能。
执行查询：对Jira数据库运行修改后的SQL查询。根据Jira实例规模和所选日期范围，查询可能需要几分钟才能完成。
检查结果：查询完成后，在SQL客户端中快速检查输出，确认结果包含数据行，且ChangeRequestId、ActivityName和EventTime等列已按预期填充。
将数据导出为CSV：在SQL客户端中将完整结果集导出为CSV文件。确保导出设置包含列标题，使用逗号分隔符和UTF-8编码。
准备上传：为文件取一个清晰易懂的名称，例如jira_change_management_log.csv。现在即可将该文件上传到流程挖掘工具进行分析。

配置

数据库访问权限：需要拥有Jira生产数据库只读权限的用户账户。仅Jira Server和Jira Data Center实例支持直接访问数据库，Jira Cloud不支持。
Jira项目键：必须使用Jira Service Management项目的具体键配置查询。请在p.pkey IN ('[Your_JSM_Project_Key]')子句中填写。
变更问题类型：查询默认变更请求的问题类型名称为“Change”。如果您的配置使用其他名称，必须更新issuetype.pname = 'Change'筛选条件。
工作流状态映射：事件日志的准确性完全取决于查询WHERE子句中的状态名称是否与项目实际工作流状态正确对应。请仔细检查并更新每个'Status Name'字符串。
自定义字段映射：查询依赖自定义字段名称来跟踪特定活动（“Risk Assessment Performed”和“Change Scheduled”）及属性。请核实并更新'[Your Risk Level Field Name]'等名称，使其与您的Jira配置一致。
日期范围：建议先使用有限的日期范围，例如3至6个月（i.created >= '[YYYY-MM-DD]'），以便控制数据量并保证查询性能。提取多年的数据可能非常耗时。
性能：对于包含数百万个问题的Jira实例，运行此查询可能影响数据库性能。建议在业务低峰时段执行，并应用日期范围筛选条件限制查询范围。

查询示例 sql

WITH ChangeRequestAttributes AS (
    SELECT
        i.id AS issueid,
        i.pkey AS ChangeRequestId,
        i.created,
        i.duedate AS TargetCompletionDate,
        istat.pname AS ChangeRequestStatus,
        u.display_name AS Assignee,
        prio.pname AS Priority,
        ct.customvalue AS ChangeRequestType,
        rl.customvalue AS RiskLevel
    FROM
        jiraissue i
    JOIN
        project p ON i.project = p.id
    LEFT JOIN
        issuestatus istat ON i.issuestatus = istat.id
    LEFT JOIN
        priority prio ON i.priority = prio.id
    LEFT JOIN
        app_user au ON i.assignee = au.user_key
    LEFT JOIN
        cwd_user u ON au.lower_user_name = u.lower_user_name
    LEFT JOIN (
        SELECT cfv.issue, cfo.customvalue
        FROM customfieldvalue cfv
        JOIN customfield cf ON cfv.customfield = cf.id
        JOIN customfieldoption cfo ON cfv.stringvalue = cfo.id
        WHERE cf.cfname = '[Your Change Type Field Name]'
    ) ct ON i.id = ct.issue
    LEFT JOIN (
        SELECT cfv.issue, cfo.customvalue
        FROM customfieldvalue cfv
        JOIN customfield cf ON cfv.customfield = cf.id
        JOIN customfieldoption cfo ON cfv.stringvalue = cfo.id
        WHERE cf.cfname = '[Your Risk Level Field Name]'
    ) rl ON i.id = rl.issue
    WHERE
        p.pkey IN ('[Your_JSM_Project_Key]')
        AND i.issuetype = (SELECT id FROM issuetype WHERE pname = 'Change')
        AND i.created >= '[YYYY-MM-DD]'
)
-- 1. Change Request Created
SELECT
    cra.ChangeRequestId,
    'Change Request Created' AS ActivityName,
    cra.created AS EventTime,
    'Jira Service Management DB' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    cra.ChangeRequestStatus,
    cra.ChangeRequestType,
    cra.Assignee,
    cra.RiskLevel,
    cra.Priority,
    cra.TargetCompletionDate,
    NULL AS ApprovalCycleTime,
    NULL AS SLAStatus
FROM
    ChangeRequestAttributes cra

UNION ALL

-- All subsequent events from issue history
SELECT
    cra.ChangeRequestId,
    CASE 
        WHEN ci.field = 'status' AND ci.newstring = 'Pending Review' THEN 'Change Submitted For Review'
        WHEN ci.field = 'status' AND ci.newstring = 'Pending Approval' THEN 'Change Awaiting Approval'
        WHEN ci.field = 'status' AND ci.newstring = 'Approved' THEN 'Change Request Approved'
        WHEN ci.field = 'status' AND ci.newstring = 'Rejected' THEN 'Change Request Rejected'
        WHEN ci.field = 'status' AND ci.newstring = 'In Progress' THEN 'Implementation Started'
        WHEN ci.field = 'status' AND ci.newstring = 'Implemented' THEN 'Change Implemented'
        WHEN ci.field = 'status' AND ci.newstring = 'In Testing' THEN 'Testing Performed'
        WHEN ci.field = 'status' AND ci.newstring = 'Verified' AND ci.oldstring = 'Post-Implementation Review' THEN 'Post-Implementation Review Done'
        WHEN ci.field = 'status' AND ci.newstring = 'Closed' THEN 'Change Closed'
        WHEN ci.field = 'status' AND ci.newstring = 'Canceled' THEN 'Change Canceled'
        WHEN ci.field = (SELECT id FROM customfield WHERE cfname = '[Your Risk Level Field Name]') AND ci.oldvalue IS NULL THEN 'Risk Assessment Performed'
        WHEN ci.field = (SELECT id FROM customfield WHERE cfname = '[Your Planned Start Date Field Name]') AND ci.oldvalue IS NULL THEN 'Change Scheduled'
    END AS ActivityName,
    cg.created AS EventTime,
    'Jira Service Management DB' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    cra.ChangeRequestStatus,
    cra.ChangeRequestType,
    cra.Assignee,
    cra.RiskLevel,
    cra.Priority,
    cra.TargetCompletionDate,
    NULL AS ApprovalCycleTime,
    NULL AS SLAStatus
FROM
    changegroup cg
JOIN
    changeitem ci ON cg.id = ci.groupid
JOIN
    ChangeRequestAttributes cra ON cg.issueid = cra.issueid
WHERE
    (
        ci.fieldtype = 'jira' AND ci.field = 'status' AND ci.newstring IN (
            'Pending Review', 'Pending Approval', 'Approved', 'Rejected', 
            'In Progress', 'Implemented', 'In Testing', 'Verified', 'Closed', 'Canceled'
        )
    )
    OR
    (
        ci.fieldtype = 'custom' AND ci.fieldid IN (
            (SELECT id FROM customfield WHERE cfname = '[Your Risk Level Field Name]'),
            (SELECT id FROM customfield WHERE cfname = '[Your Planned Start Date Field Name]')
        ) AND ci.oldvalue IS NULL
    )
ORDER BY
    ChangeRequestId, EventTime;

步骤

设置Python环境：确保已安装Python 3.6或更新版本。运行以下命令安装所需库：用于发送API请求的requests和用于数据处理的pandas：pip install requests pandas。
生成Jira API令牌：登录Jira账户，进入个人资料设置，选择“Account settings”，再打开“Security”选项卡并点击“Create and manage API tokens”。创建新令牌并妥善保存。该令牌将用作API身份验证密码。
配置Python脚本：使用编辑器打开提供的Python脚本。将JIRA_URL、JIRA_EMAIL和JIRA_API_TOKEN的占位值替换为您的Jira实例URL、电子邮件地址和生成的API令牌。
自定义JQL查询：修改脚本中的JQL_QUERY变量，指定正确的Jira Service Management项目和问题类型。例如，将project = "CSM"改为您项目的键。调整查询中的日期范围，以限定数据提取时间并提升性能。
映射自定义字段和状态：检查脚本中的STATUS_TO_ACTIVITY_MAPPING和FIELD_TO_ACTIVITY_MAPPING字典。您必须将Jira状态名称（例如“Pending Approval”）和自定义字段名称（例如“Risk Level”）更新为Jira工作流中使用的准确名称。请在Jira自定义字段管理页面查找customfield_10050等字段的正确ID。
运行脚本：在终端中运行命令python your_script_name.py。脚本将连接Jira API，获取变更请求问题及其历史记录并进行处理。
监控脚本运行：脚本会在控制台输出进度信息，显示已获取和处理的问题数量。处理大型数据集可能需要较长时间。
检查输出：脚本运行完毕后，会在同一目录下生成名为jira_change_management_event_log.csv的CSV文件，其中包含提取的事件日志。
准备上传：在电子表格应用中打开CSV文件，确认数据结构正确，并包含ChangeRequestId、ActivityName和EventTime等列。随后即可将文件上传到流程挖掘工具。

配置

JQL查询：JQL_QUERY变量是数据提取的主要筛选条件，至少应指定project、issuetype = 'Change'以及created字段的日期范围（例如，使用created >= -180d提取最近180天的数据）。筛选特定日期范围对控制数据量至关重要。
状态和字段映射：脚本的准确性完全取决于STATUS_TO_ACTIVITY_MAPPING和FIELD_TO_ACTIVITY_MAPPING字典。必须根据组织的Jira工作流状态和自定义字段名称准确配置这些字典，才能生成正确的活动。
API凭据：脚本需要有效的JIRA_URL、JIRA_EMAIL和JIRA_API_TOKEN进行身份验证。令牌关联的用户必须拥有指定项目及所有相关字段的读取权限。
数据分页：脚本使用maxResults参数（设为100）分批或分页获取API中的问题。这对于可靠提取大量问题、避免请求超时至关重要。
展开变更历史：API请求中的expand=changelog参数至关重要，它会指示Jira返回每个问题所有字段变更的完整历史记录，这是大多数活动的数据来源。

查询示例 python

import requests
import json
import pandas as pd
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration Settings --- #
class=class="hl-string">"hl-comment"># Replace with your Jira instance details
JIRA_URL = class="hl-string">"https://[your-domain].atlassian.net"
JIRA_EMAIL = class="hl-string">"[your-email@example.com]"
JIRA_API_TOKEN = class="hl-string">"[your_jira_api_token]"

class=class="hl-string">"hl-comment"># JQL to select Change Management issues. Itclass="hl-string">'s recommended to add a date filter, e.g., 'AND created >= -180d'
JQL_QUERY = class="hl-string">'project = "CSM" AND issuetype = "Change" ORDER BY created DESC'

class=class="hl-string">"hl-comment"># --- Mappings - CRITICAL: Customize these to match your Jira workflow --- #
class=class="hl-string">"hl-comment"># Map Jira status names to standardized Activity Names
STATUS_TO_ACTIVITY_MAPPING = {
    class="hl-string">'Pending Review': class="hl-string">'Change Submitted For Review',
    class="hl-string">'Pending Approval': class="hl-string">'Change Awaiting Approval',
    class="hl-string">'Approved': class="hl-string">'Change Request Approved',
    class="hl-string">'Rejected': class="hl-string">'Change Request Rejected',
    class="hl-string">'In Progress': class="hl-string">'Implementation Started',
    class="hl-string">'Implemented': class="hl-string">'Change Implemented',
    class="hl-string">'Post-Implementation Review': class="hl-string">'Post-Implementation Review Done',
    class="hl-string">'Closed': class="hl-string">'Change Closed',
    class="hl-string">'Canceled': class="hl-string">'Change Canceled',
    class=class="hl-string">"hl-comment"># Add other custom statuses from your workflow
}

class=class="hl-string">"hl-comment"># Map Jira field updates to standardized Activity Names
class=class="hl-string">"hl-comment"># Use field names as they appear in the API changelog. Custom fields might have different names.
FIELD_TO_ACTIVITY_MAPPING = {
    class="hl-string">'Risk Level': class="hl-string">'Risk Assessment Performed',
    class="hl-string">'Planned start date': class="hl-string">'Change Scheduled',
    class="hl-string">'Testing Status': class="hl-string">'Testing Performed', class=class="hl-string">"hl-comment"># Example for a custom class="hl-string">'Testing Status' field
}
class=class="hl-string">"hl-comment"># --- End of Configuration --- #

def get_issues(auth):
    class="hl-string">"""Paginates through JQL results to fetch all issues."""
    all_issues = []
    start_at = 0
    max_results = 100

    while True:
        api_endpoint = fclass="hl-string">"{JIRA_URL}/rest/api/3/search"
        params = {
            class="hl-string">'jql': JQL_QUERY,
            class="hl-string">'startAt': start_at,
            class="hl-string">'maxResults': max_results,
            class="hl-string">'fields': class="hl-string">'*all',
            class="hl-string">'expand': class="hl-string">'changelog'
        }
        try:
            response = requests.get(api_endpoint, auth=auth, params=params, headers={class="hl-string">'Accept': class="hl-string">'application/json'})
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raises an error for bad responses (4xx or 5xx)
            data = response.json()
            issues = data.get(class="hl-string">'issues', [])
            all_issues.extend(issues)

            print(fclass="hl-string">"Fetched {len(issues)} issues, total so far: {len(all_issues)}")

            if len(issues) < max_results:
                break class=class="hl-string">"hl-comment"># Exit loop if this is the last page
            start_at += len(issues)
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching issues: {e}")
            break

    return all_issues

def parse_issues_to_event_log(issues):
    class="hl-string">"""Parses issues and their changelogs into a structured event log."""
    event_log = []
    source_system = class="hl-string">"Jira Service Management"
    last_data_update = datetime.utcnow().isoformat() + class="hl-string">'Z'

    for issue in issues:
        case_id = issue[class="hl-string">'key']
        fields = issue.get(class="hl-string">'fields', {})
        
        class=class="hl-string">"hl-comment"># 1. Handle class="hl-string">'Change Request Created' event
        event_log.append({
            class="hl-string">'ChangeRequestId': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Change Request Created',
            class="hl-string">'EventTime': fields.get(class="hl-string">'created'),
            class="hl-string">'SourceSystem': source_system,
            class="hl-string">'LastDataUpdate': last_data_update,
            class="hl-string">'ChangeRequestStatus': fields.get(class="hl-string">'status', {}).get(class="hl-string">'name'),
            class="hl-string">'ChangeRequestType': fields.get(class="hl-string">'customfield_10037', {}).get(class="hl-string">'value'), class=class="hl-string">"hl-comment"># Example custom field ID
            class="hl-string">'Assignee': fields.get(class="hl-string">'assignee', {}).get(class="hl-string">'displayName') if fields.get(class="hl-string">'assignee') else None,
            class="hl-string">'RiskLevel': fields.get(class="hl-string">'customfield_10039', {}).get(class="hl-string">'value'), class=class="hl-string">"hl-comment"># Example custom field ID
            class="hl-string">'Priority': fields.get(class="hl-string">'priority', {}).get(class="hl-string">'name'),
            class="hl-string">'TargetCompletionDate': fields.get(class="hl-string">'duedate'),
            class="hl-string">'ApprovalCycleTime': None, class=class="hl-string">"hl-comment"># Requires post-processing to calculate
            class="hl-string">'SLAStatus': None class=class="hl-string">"hl-comment"># Requires post-processing to calculate
        })

        class=class="hl-string">"hl-comment"># 2. Parse changelog for all other events
        changelog = issue.get(class="hl-string">'changelog', {}).get(class="hl-string">'histories', [])
        for history in changelog:
            event_time = history[class="hl-string">'created']
            for item in history.get(class="hl-string">'items', []):
                activity_name = None
                class=class="hl-string">"hl-comment"># Map status changes
                if item.get(class="hl-string">'field', class="hl-string">'').lower() == class="hl-string">'status':
                    activity_name = STATUS_TO_ACTIVITY_MAPPING.get(item.get(class="hl-string">'toString'))
                class=class="hl-string">"hl-comment"># Map field updates
                elif item.get(class="hl-string">'field') in FIELD_TO_ACTIVITY_MAPPING:
                    activity_name = FIELD_TO_ACTIVITY_MAPPING.get(item.get(class="hl-string">'field'))

                if activity_name:
                    event_log.append({
                        class="hl-string">'ChangeRequestId': case_id,
                        class="hl-string">'ActivityName': activity_name,
                        class="hl-string">'EventTime': event_time,
                        class="hl-string">'SourceSystem': source_system,
                        class="hl-string">'LastDataUpdate': last_data_update,
                        class="hl-string">'ChangeRequestStatus': item.get(class="hl-string">'toString') if item.get(class="hl-string">'field', class="hl-string">'').lower() == class="hl-string">'status' else fields.get(class="hl-string">'status', {}).get(class="hl-string">'name'),
                        class="hl-string">'ChangeRequestType': fields.get(class="hl-string">'customfield_10037', {}).get(class="hl-string">'value'),
                        class="hl-string">'Assignee': fields.get(class="hl-string">'assignee', {}).get(class="hl-string">'displayName') if fields.get(class="hl-string">'assignee') else None,
                        class="hl-string">'RiskLevel': fields.get(class="hl-string">'customfield_10039', {}).get(class="hl-string">'value'),
                        class="hl-string">'Priority': fields.get(class="hl-string">'priority', {}).get(class="hl-string">'name'),
                        class="hl-string">'TargetCompletionDate': fields.get(class="hl-string">'duedate'),
                        class="hl-string">'ApprovalCycleTime': None,
                        class="hl-string">'SLAStatus': None
                    })

    return event_log

if __name__ == class="hl-string">"__main__":
    print(class="hl-string">"Starting Jira data extraction...")
    jira_auth = (JIRA_EMAIL, JIRA_API_TOKEN)
    
    issues_data = get_issues(jira_auth)
    
    if issues_data:
        print(fclass="hl-string">"\nProcessing {len(issues_data)} issues into an event log...")
        event_log_data = parse_issues_to_event_log(issues_data)
        
        class=class="hl-string">"hl-comment"># Create DataFrame and save to CSV
        df = pd.DataFrame(event_log_data)
        df_sorted = df.sort_values(by=[class="hl-string">'ChangeRequestId', class="hl-string">'EventTime'])
        
        output_filename = class="hl-string">'jira_change_management_event_log.csv'
        df_sorted.to_csv(output_filename, index=False)
        print(fclass="hl-string">"\nExtraction complete. Event log saved to {output_filename}")
    else:
        print(class="hl-string">"No issues found for the given JQL query.")

准备好开始了吗？

使用此数据模板，快速启动变更管理流程挖掘。立即开始将原始数据转化为可执行的洞察。

返回改进指南

下载模板

提升变更管理成效：将成功率提高至95%

轻松减少变更失败，将成功率提高至95%。

立即开始免费试用

无需信用卡，几分钟即可完成设置。

您的变更管理数据模板

您的变更管理数据模板

变更管理属性

变更管理活动

数据提取指南

使用Jira Service Management内置功能将问题导出为CSV

步骤

配置

查询示例 config

通过Jira Server/Data Center直接查询数据库SQL

步骤

配置

查询示例 sql

通过Jira REST API和JQL使用Python脚本提取数据

步骤

配置

查询示例 python

准备好开始了吗？

提升变更管理成效：将成功率提高至95%