> 持续流程改进 > 变更管理 > 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中的状态转换、工作流步骤或特定日志条目，例如“Change Submitted For Review”或“Implementation Started”。分析这些活动的顺序和频率是流程挖掘的核心。它有助于发现实际流程路径、识别步骤之间的瓶颈，并将流程变体与标准操作规程进行比较。为什么重要它定义流程步骤，对于发现流程图、分析变体和识别瓶颈至关重要。获取位置通常取自Jira问题历史记录，具体来自代表流程里程碑的状态转换或自定义字段更新。示例变更请求已批准已完成风险评估变更已实施已完成实施后评审
	最后数据更新时间 LastDataUpdate	表示该记录数据最近一次刷新或提取时间的时间戳。
说明此属性记录数据最近一次从源系统提取的日期和时间，反映流程挖掘工具中数据的新鲜度。分析此属性有助于了解流程数据的时效性，这对于运营仪表板和实时监控十分重要。它为分析提供背景信息，确保决策不会基于过时数据。为什么重要反映数据的新鲜度，确保分析具有时效性并基于最新信息。获取位置这是数据提取工具在提取数据时填充的元数据字段。示例 2024-01-15T02:00:00Z2024-01-16T02:00:00Z
	源系统 SourceSystem	用于标识提取变更管理数据的系统。
说明此属性指定流程数据的来源系统。在当前场景中，该值始终为“Jira Service Management”。在更广泛的企业场景中，如果数据来自多个系统并需要合并，此字段对于追溯数据来源、排查问题以及了解不同系统的流程差异至关重要。它有助于明确所分析数据的来源。为什么重要提供清晰的数据来源信息，这对于合并多个系统的数据或开展审计至关重要。获取位置这是数据提取过程中添加的静态值，用于标记数据集来源。示例 Jira Service Management
	SLA状态 SLAStatus	表示变更请求是否在目标完成日期内完成。
说明这是一个计算属性，用于比较变更请求的实际解决日期与其“Target Completion Date”。结果为简单状态，例如“Met”或“Breached”。它为“Change SLA Performance Monitor”仪表板提供清晰的概览式性能指标。通过预先计算每个案例的状态，可以简化“Change SLA Adherence Rate”等KPI的创建，并轻松筛选和汇总最常发生SLA逾期的变更类型、团队或服务。为什么重要为每个案例提供清晰的二元SLA绩效结果，简化SLA遵从情况的报告和分析。获取位置通过比较最终“Change Closed”活动的时间戳与“TargetCompletionDate”属性计算。示例已达标已逾期
	优先级 Priority	分配给变更请求的优先级，表示其业务重要性。
说明 Priority字段帮助团队确定处理变更请求的顺序。它综合反映影响和紧急程度，并指导排期和资源配置。分析优先级可以比较高优先级和低优先级变更的性能。例如，可以检查高优先级变更是否确实具有更短的周期时间，或是否同样受困于其他变更面临的瓶颈。这有助于优化资源投入并满足业务预期。为什么重要支持根据业务优先级分析流程性能，确保关键变更按预期加速处理。获取位置这是Jira问题的标准`priority`字段。示例最高高中低
	变更状态 ChangeRequestStatus	事件发生时变更请求的当前状态或历史状态。
说明此属性表示变更请求的状态，例如'Awaiting Approval'、'In Progress'或'Closed'。Jira中的状态字段是其工作流引擎的基础，该字段的变化是流程顺序的主要驱动因素。分析状态可以跟踪活跃变更的进度，并了解已完成变更的结果，例如区分'Closed - Successful'和'Closed - Failed'。它对于构建吞吐量仪表板，以及分析状态退回先前状态的返工循环至关重要。为什么重要清晰呈现变更请求的进度和最终结果，对于吞吐量和返工分析至关重要。获取位置这是Jira问题的标准`status`字段。可用状态由项目的工作流配置定义。示例规划中等待审批实施中已关闭已取消
	变更类型 ChangeRequestType	变更的分类，例如Standard、Normal或Emergency。
说明 Change Type根据变更的性质、紧急程度和影响进行分类。常见类型包括：预先批准且风险较低的“Standard”、需要完整审批的常规变更“Normal”，以及用于快速修复事件的紧急变更“Emergency”。此属性对于流程分析至关重要，因为不同变更类型通常遵循不同的流程路径，并具有不同的SLA。它用于计算“Emergency Change Rate”KPI，也可用于筛选仪表板，比较各类型变更的性能和风险。为什么重要支持按流程进行细分，以分析不同的工作流，例如Standard和Emergency变更，因为它们具有不同的性能要求和风险。获取位置这通常是Jira Service Management项目中的自定义字段。字段名称可能有所不同，但通常命名为“Change Type”。示例标准普通紧急
	目标完成日期 TargetCompletionDate	变更请求计划完成日期或Service Level Agreement（SLA）截止日期。
说明此属性存储为满足SLA，变更请求预计完成的日期，也是衡量实际完成时间的基准。该日期是监控承诺履行情况的基础，支持“Change SLA Performance Monitor”仪表板和“Change SLA Adherence Rate”KPI。通过比较实际解决日期与目标日期，组织可以衡量服务交付的有效性。为什么重要这是计算SLA遵从率并识别可能逾期变更的主要数据点。获取位置这通常对应Jira中的`duedate`字段，或Jira Service Management中已配置SLA指标的值。示例 2023-11-15T17:00:00Z2023-12-01T23:59:59Z2024-01-10T09:00:00Z
	经办人 Assignee	当前负责处理变更请求的用户。
说明 Assignee是变更管理工作流中负责当前步骤或活动的用户。变更请求在生命周期内转交给不同人员和团队时，经办人可能多次变更。此属性用于分析工作负载分配、识别特定用户的瓶颈以及了解资源配置。“Change Team Activity Workload”仪表板依靠这些数据展示哪些人员或群组处理的活动最多。为什么重要有助于分析资源绩效和工作负载分配，识别个人或团队瓶颈。获取位置这是Jira问题的标准`assignee`字段。示例 Alice JohnsonBob WilliamsCharlie Brown
	风险等级 RiskLevel	与变更相关的评估风险等级，例如Low、Medium或High。
说明 Risk Level是大多数变更管理流程中的必填评估项，用于对变更可能造成的负面影响进行分类。该等级在风险评估阶段确定，并通常会影响所需的审批工作流。在流程挖掘中，此属性对于基于风险的分析至关重要。它支持“Risk Assessment Accuracy & Outcome”仪表板，将初始风险与实际结果进行关联。它也是“Change Failure Rate by Risk Level”KPI的主要维度，有助于评估高风险变更是否得到有效管理。为什么重要支持分析不同风险特征下的流程控制和审批工作流是否有效，并帮助关联风险与变更失败率。获取位置这通常是Jira Service Management中的自定义字段，常见名称包括“Risk Level”或“Impact”。示例低中高严重
	业务服务 BusinessService	受变更影响的业务服务或应用程序。
说明此属性将变更请求关联到配置管理数据库（CMDB）中定义的特定业务服务，例如“Email Service”或“Customer CRM”。这是理解变更业务影响的关键概念。按业务服务分析变更，有助于确定工作优先级并向相关方传达影响。您可以了解哪些服务变更最频繁、哪些服务风险最高，以及与变更相关的事件集中在哪些服务上。这对于从业务视角管理技术变更至关重要。为什么重要将技术变更与业务影响关联起来，支持根据受影响服务的重要性确定优先级并开展风险分析。获取位置这通常是JSM中的自定义字段，常与Jira Assets（原Insight）或其他CMDB关联。示例企业网站SAP ERP内部Wiki
	变更原因 ChangeReason	提出变更的依据或业务原因。
说明此属性记录变更背后的根本原因，例如“New Feature Implementation”“Bug Fix”或“Infrastructure Upgrade”。相比摘要或描述，它提供了更重要的背景信息。在分析中，可以将变更原因与周期时间、失败率和风险等级等指标关联起来。这有助于回答以下问题：“与新功能实施相比，缺陷修复相关变更是否审批更快？”或“基础设施升级的失败率是否更高？” 为什么重要提供业务背景，支持将变更目的与其性能和结果关联起来，开展更深入的分析。获取位置这通常是Jira Service Management中的自定义字段，常见类型为选择列表或文本字段。示例安全补丁软件升级新硬件安装
	团队 Team	负责变更请求或特定活动的团队或群组。
说明此属性用于标识负责处理变更的团队。Jira通过“Assignee”字段分配个人，而“Team”字段通常用于将工作分配给职能群组，例如“Network Operations”或“Database Administrators”。这对于“Change Team Activity Workload”仪表板至关重要。它支持在团队层面而非仅在个人层面分析性能和瓶颈，通常更适合资源规划和管理。为什么重要支持在团队或部门层面分析工作负载和性能，突出系统性瓶颈。获取位置这通常是Jira中的自定义字段，因为Jira没有标准的“Team”字段。字段类型可以是“Group Picker”或简单的选择列表。示例基础设施团队核心服务应用支持
	实施后问题 PostImplementationIssue	用于标记实施后是否有事件或问题与此变更关联。
说明此属性表示变更是否导致负面结果，例如生产环境事件。通常需要将变更请求问题与Jira中的一个或多个事件问题关联。这些数据对于计算“Post-Implementation Issue Rate”和“Change Failure Rate”KPI至关重要。它直接衡量变更质量，以及规划、测试和风险评估流程的有效性。分析哪些变更会引发问题，有助于完善控制措施并防止未来失败。为什么重要通过跟踪变更是否导致后续运营问题，直接衡量变更的质量和成功情况。获取位置通常通过检查Jira中的关联问题得出，具体判断Change问题是否存在来自Incident问题的“is caused by”链接。示例 truefalse
	报告人 Reporter	最初创建或提交变更请求的用户。
说明 Reporter是在Jira中创建变更请求问题的人员，通常是变更负责人，或代表团队发起变更的人员。分析报告人有助于识别发起变更最多的部门、团队或个人。还可以发现变更来源趋势，并为经常提交不完整或低质量变更请求的群体提供反馈或培训。为什么重要帮助识别变更请求的来源，并据此改进初始提交的质量。获取位置这是Jira问题的标准`reporter`字段。示例 David MillerEva GreenFrank Wright
	是否返工 IsRework	布尔标记。如果变更请求经历过返工循环，则值为true。
说明此计算属性用于识别被退回上一阶段修改的变更请求，例如从“Awaiting Approval”退回“Planning”。这表明初始提交不完整、有误或未满足必要条件。此标记是“Change Rework Rate”KPI和“Change Rework and Rejection Analysis”仪表板的基础。标记返工案例后，分析人员可以轻松筛选并调查根本原因，例如初始规划不足、需求不明确或风险评估不充分。为什么重要通过明确标记需要额外非计划工作的案例，突出流程低效，并支持分析返工的根本原因。获取位置通过分析事件日志中的活动顺序计算。如果后续阶段的活动之后又出现前一阶段的活动，则判定为返工。示例 truefalse
	解决结果 Resolution	已关闭变更请求的最终结果，表示其解决方式。
说明变更请求关闭后，Resolution字段会提供具体结果信息。例如，“Done”表示成功，“Won't Do”或“Duplicate”表示其他关闭原因。相比仅有“Closed”状态，该字段提供了更多背景信息。此属性对于分析变更成功率和失败率至关重要。例如，筛选Resolution为“Failed”或“Rolled Back”的变更，可以更好地理解“Post-Implementation Issue Rate”KPI。它有助于区分成功实施的变更，以及获批后被取消或拒绝的变更。为什么重要提供变更最终结果的详细背景信息，对于准确计算成功率和失败率至关重要。获取位置这是Jira中的标准`resolution`字段，通常在问题进入“Done”状态类别时设置。示例已完成不实施重复已取消已回滚

必需建议可选

变更管理活动

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

5 建议 8 可选

	活动	说明
	变更已关闭	表示变更请求最终关闭，说明所有相关活动均已完成。当Jira问题状态变更为“Closed”或“Done”等最终解决状态时记录。
为什么重要这是流程的主要终点，用于计算整体周期时间并确定SLA遵循情况。获取位置通过识别“status”字段变为最终关闭状态的时间戳，从Jira问题历史记录中推断。此时通常也会设置resolution字段。采集跟踪状态变更为“Closed”或“Done”的时间戳。事件类型 inferred
	变更已实施	这是一个关键里程碑，表示与变更相关的工作已完成。通常通过Jira工作流中的状态变更记录，例如变为“Implemented”或“Pending Verification”。
为什么重要该事件标志着实施阶段结束，对于计算实施周期时间至关重要，同时也是实施后评审和验证活动的触发点。获取位置通过识别“status”字段变为“Implemented”或“Pending Post-Implementation Review”的时间戳，从Jira问题历史记录中推断。采集跟踪状态变更为“Implemented”或类似状态的时间戳。事件类型 inferred
	变更等待审批	表示变更请求已通过初步评审，正在等待变更咨询委员会（CAB）或指定审批人的正式决策。通常通过工作流中的状态变更记录，例如变为“Pending Approval”或“Awaiting CAB”。
为什么重要该活动是衡量审批等待时间和识别决策阶段瓶颈的关键，并直接影响变更审批周期时间KPI。获取位置通过识别“status”字段变为“Pending CAB Approval”或“Awaiting Approval”等审批状态的时间戳，从Jira问题历史记录中推断。采集跟踪状态变更为指定“Awaiting Approval”状态的时间戳。事件类型 inferred
	变更请求已创建	表示在Jira Service Management中首次创建变更请求工单。当新的“Change”类型问题首次保存时，系统会使用创建时间戳明确记录此事件。
为什么重要这是所有变更请求的起点，对于衡量整体周期时间和分析一段时间内的变更流入量至关重要。获取位置取自Jira问题对象的“created”时间戳。这是每个问题都具备的标准系统字段，可通过问题历史记录或API获取。采集使用Jira问题中的“created”字段时间戳。事件类型 explicit
	变更请求已批准	这是一个关键里程碑，表示变更已正式获批，可以实施。通常通过推断Jira工作流中的状态变更来记录，例如变为“Approved”或“Ready for Implementation”。
为什么重要该事件标志着审批周期结束和实施阶段开始，对于衡量审批周期时间及跟踪未经授权的变更至关重要。获取位置通过识别“status”字段变为“Approved”状态的时间戳，从Jira问题历史记录中推断。采集跟踪状态变更为“Approved”或“Ready to Implement”的时间戳。事件类型 inferred
	变更已取消	表示变更请求在实施或完成前终止。当Jira问题状态变更为“Canceled”或“Withdrawn”等终止状态时记录。
为什么重要这一替代终点有助于分析变更被放弃的原因。取消率较高可能表明初始规划不佳或业务优先级发生变化。获取位置通过识别“status”字段变为“Canceled”状态且设置了相应resolution的时间戳，从Jira问题历史记录中推断。采集跟踪状态变更为“Canceled”或“Withdrawn”的时间戳。事件类型 inferred
	变更已排期	表示已批准的变更被分配了具体实施时间窗口。通常通过Jira问题中“Planned start date”和“Planned end date”字段的填写或更新来推断。
为什么重要该活动让您了解变更的后续规划，有助于资源管理，并评估审批与计划实施之间的时间。获取位置通过捕获“Planned start date”或“Change window”等日期字段被填写的时间戳，从Jira问题历史记录中推断。采集跟踪“Planned start date”字段被填写的时间戳。事件类型 inferred
	变更已提交审核	表示变更请求的初始信息已完整，并已正式提交评估。通常通过推断Jira工作流中的状态变更来记录，例如从“Draft”变为“Pending Review”。
为什么重要该活动启动审批周期。衡量从此时到审批完成的时间，对于计算审批周期时间KPI和识别早期瓶颈至关重要。获取位置通过识别“status”字段变为“Pending Review”或“Awaiting Assessment”等评审状态的时间戳，从Jira问题历史记录中推断。采集跟踪状态变更为“Pending Review”、“Submitted”或类似状态的时间戳。事件类型 inferred
	变更请求已拒绝	表示正式拒绝变更请求，通常会将其退回请求人以补充信息，或直接取消。通过Jira工作流中的状态变更记录，例如变为“Rejected”或“Needs More Info”。
为什么重要跟踪拒绝对于分析变更返工率至关重要。该活动频繁发生，通常表明初始变更提交的质量存在问题。获取位置通过识别“status”字段变为“Rejected”或类似终止状态的时间戳，从Jira问题历史记录中推断。采集跟踪状态变更为“Rejected”或“Declined”的时间戳。事件类型 inferred
	实施已开始	标志着已批准变更的技术实施开始。通常通过Jira状态从“Approved”或“Scheduled”变更为“In Progress”或“Implementing”来记录。
为什么重要该活动启动平均实施周期时间的计时，有助于识别执行阶段的瓶颈。获取位置通过识别“status”字段变为“In Progress”等实施中状态的时间戳，从Jira问题历史记录中推断。采集跟踪状态变更为“In Progress”或“Implementing”的时间戳。事件类型 inferred
	已完成实施后评审	表示已完成正式评审，用于评估变更成效并总结经验。通常通过工作流中的状态变更记录，例如从“Post-Implementation Review”变为“Verified”。
为什么重要该活动对于流程改进至关重要。衡量评审周期时间有助于确保及时总结经验。获取位置通过识别“status”字段离开“Post-Implementation Review”状态的时间戳，从Jira问题历史记录中推断。采集跟踪状态从“PIR”变更为后续状态的时间戳。事件类型 inferred
	已完成测试	表示已完成实施后测试，以验证变更。它可能对应“In Testing”等独立状态，也可能根据“Change Implemented”事件后QA团队的评论或更新进行推断。
为什么重要分析测试时长和结果，有助于评估实施质量及测试流程的有效性，也是计算实施后问题率的重要输入。获取位置可以根据状态变更为“Testing”或“Under Test”进行推断，也可以分析实施后问题历史记录中的评论和负责人变更。采集跟踪状态变更为“In Testing”的时间戳，或从评论中获取。事件类型 inferred
	已完成风险评估	表示已完成拟议变更的风险和影响分析。通常通过问题历史记录推断，例如风险等级或影响等风险相关自定义字段被填写或更新时。
为什么重要分析该活动有助于评估风险评估的准确性，并确保符合变更政策。它对于计算按风险等级划分的变更失败率等基于风险的KPI至关重要。获取位置通过捕获“Risk Level”、“Impact”或“Urgency”等特定字段首次设置或变更的时间戳，从Jira问题历史记录中推断。采集跟踪“Risk Level”或“Impact”等字段首次填写的时间戳。事件类型 inferred

建议可选

提取指南

如何从Jira Service Management获取数据

步骤

访问Jira的问题导航器：登录您的Jira Service Management实例。在主导航栏中选择“Issues”，然后选择“Search for issues”，打开问题导航器。
切换到JQL搜索：如果当前处于“Basic”搜索模式，请点击“JQL”（某些版本中显示为“Advanced”）切换到高级模式。这样您就可以输入自定义的Jira Query Language（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。删除所有中间列或源数据列。将最终转换后的数据保存为CSV文件，确保采用UTF-8编码，然后上传到流程挖掘工具。

配置

JQL筛选器：JQL查询是选择正确数据集的主要工具。关键筛选条件包括project、issuetype以及针对created字段的日期范围，用于限定提取范围。
日期范围：建议先使用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”等流程属性对应的自定义字段准确名称。

a 示例查询 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实例，运行此查询可能影响数据库性能。最好在业务低峰期执行，并确保应用日期范围筛选条件限制查询范围。

a 示例查询 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返回每个问题所有字段变更的完整历史，这是大多数活动的数据来源。

a 示例查询 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

步骤

配置

a 示例查询 config

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

步骤

配置

a 示例查询 sql

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

步骤

配置

a 示例查询 python

准备好开始了吗？

提升变更管理成效：立即实现95%的成功率

您的变更管理数据模板

您的变更管理数据模板

变更管理属性

变更管理活动

提取指南

Jira Service Management内置问题导出为CSV

步骤

配置

a 示例查询 config

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

步骤

配置

a 示例查询 sql

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

步骤

配置

a 示例查询 python

准备好开始了吗？

提升变更管理成效：立即实现95%的成功率

我们重视您的隐私