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

您的变更管理数据模板

Jira Service Management

您的变更管理数据模板

此 template 为收集分析变更管理流程所需的 data 提供了全面指南。它列出了核心属性、需要跟踪的关键活动，以及从 Jira Service Management 提取 data 的实用指导。利用此资源构建准确的 event log，深入洞察您的变更流程。

建议收集的属性
流程需重点跟踪的活动
Jira Service Management数据导出指引

不熟悉事件日志？了解如何创建流程挖掘事件日志.

下载模板

变更管理属性

这些是建议包含在 event log 中的 data 字段，用于对您的变更管理流程进行全面分析。

5 必填 8 推荐 7 可选

	名称	描述
	变更请求 ID ChangeRequestId	单个变更请求 case 的唯一标识符，将从创建到关闭的所有关联活动归组。
描述变更请求 ID 是在 Jira Service Management 中唯一标识每个变更计划的主键。它作为 Process Mining 的 case 标识符，将所有 event、状态变更和更新关联成一个完整的端到端流程视图。在分析中，此 ID 支持重建每个变更的完整生命周期。它对于跟踪单个变更在风险评估、审批、实施和评审等各阶段的表现至关重要。所有指标、KPI 和仪表板都依赖此属性来正确聚合和关联特定变更的 event 数据。为何重要这是基础的 case 标识符，使得追踪变更请求的全过程并分析其绩效成为可能。获取方式这是标准 Jira Issue Key，可在变更请求类型的 issue `key` 字段中找到。示例 ITSM-1024CHG-2023-001CR-5921
	开始时间 EventTime	指示特定活动或 event 发生的准确 timestamp。
描述开始时间（或 event timestamp）标志着为变更请求记录活动的精确日期和时间。event log 中的每项活动（从创建到关闭）都有关联的 timestamp。此属性对于 Process Mining 中所有基于时间的分析都至关重要。它用于计算周期时间、活动间时长、等待时间，并确定 event 顺序。它是绩效监控、SLA 达成计算和瓶颈识别的基础。为何重要此 timestamp 是所有绩效和时长分析的基础，支持计算周期时间并识别延迟。获取方式 Jira issue 历史日志中每个条目的 timestamp。对于创建 event，对应 `created` 字段。示例 2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-05T09:00:00Z
	活动 ActivityName	变更管理流程中发生的特定业务 event 或任务的名称。
描述此属性记录变更请求在特定时间点发生的活动名称。这些活动源自 Jira 中的状态流转、workflow 步骤或特定日志条目，例如“变更已提交评审”或“实施已开始”。分析这些活动的顺序和频率是 Process Mining 的核心。它支持发现真实的流程流向，识别步骤间的瓶颈，并对照标准作业程序分析流程变体。为何重要它定义了流程的步骤，这对于发现流程图、分析变体以及识别瓶颈至关重要。获取方式通常源自 Jira issue 历史记录，特别是代表流程里程碑的状态流转或自定义字段更新。示例变更请求已批准已执行风险评估变更已实施实施后评审已完成
	最后数据更新 LastDataUpdate	表示此记录的 data 上次刷新或提取时间的 timestamp。
描述此属性记录上次从源系统拉取 data 的日期和时间。它代表了 Process Mining 工具中 data 的新鲜度。分析此属性可以帮助用户了解流程 data 的实时程度，这对于运营仪表板和实时监控非常重要。它为分析提供了背景信息，确保决策不会基于陈旧的 data。为何重要指示数据的时效性，确保分析与当前状况相关且基于最新信息。获取方式这是一个元 data 字段，由 data 提取工具在抓取 data 时自动填充。示例 2024-01-15T02:00:00Z2024-01-16T02:00:00Z
	源系统 SourceSystem	标识提取变更管理数据的来源系统。
描述此属性指定流程 data 来源的源系统。在此背景下，该值始终为 'Jira Service Management'。在可能合并多个系统数据的更广泛的企业背景下，此字段对于 data 血缘、故障排除和理解特定系统的流程差异至关重要。它确保了所分析 data 来源的清晰性。为何重要提供清晰的 data 来源说明，这在整合多个系统的数据或进行审计时至关重要。获取方式这是在 data 提取期间添加的静态值，用于标记数据集的来源。示例 Jira Service Management
	SLA 状态 SLAStatus	指示变更请求是否在目标完成日期内完成。
描述这是一个计算属性，用于比较变更请求的实际解决日期与“目标完成日期”。结果是一个简单的状态，如“达标”或“违规”。这为“变更 SLA 绩效监控”仪表板提供了一个直观的绩效指标。它通过预先计算每个 case 的状态，简化了“变更 SLA 达成率”等 KPI 的创建。这样可以方便地进行过滤和聚合，查看哪些变更类型、团队或服务最常涉及 SLA 违规。为何重要为每个 case 的 SLA 达成情况提供明确的二进制结果，简化了 SLA 遵循情况的报告与分析。获取方式通过对比最终“变更关闭”活动的时间戳与 'TargetCompletionDate'（目标完成日期）属性计算得出。示例已达成已超期
	优先级 Priority	分配给变更请求的优先级，表示其业务重要性。
描述优先级字段帮助团队确定处理变更请求的顺序。它反映了影响力和紧急程度的结合，并指导排期和资源分配。分析优先级支持高优先级和低优先级变更之间的绩效对比。例如，可以检查高优先级变更的周期时间是否真的更短，还是与其它变更一样卡在相同的瓶颈上。这对于优化资源投入和满足业务预期非常有价值。为何重要支持基于业务优先级分析流程绩效，确保关键变更能够按预期加速处理。获取方式这是 Jira issue 上的标准 `priority` 字段。示例最高高中低
	受理人 Assignee	当前负责处理变更请求的用户。
描述 Assignee 是指负责变更管理 workflow 中当前步骤或活动的具体用户。在变更请求的生命周期中，随着它在不同人员和团队间流转，Assignee 可能会多次更改。此属性用于分析工作量分布、识别特定用户的瓶颈并了解资源分配情况。“变更团队活动工作量”仪表板依赖此 data 来展示哪些个人或群体处理的任务最多。为何重要这有助于分析资源绩效和工作负载分布，识别个人或团队瓶颈。获取方式这是 Jira issue 上的标准 `assignee` 字段。示例爱丽丝·约翰逊鲍勃·威廉姆斯Charlie Brown
	变更状态 ChangeRequestStatus	event 发生时变更请求的当前或历史状态。
描述此属性表示变更请求的状态，例如“等待审批”、“进行中”或“已关闭”。Jira 中的状态字段是其 workflow 引擎的基础，该字段的更改是流程流转的主要驱动力。分析状态可以跟踪活跃变更的进度，并了解已完成变更的结果（例如“关闭-成功”与“关闭-失败”）。它是构建吞吐量仪表板以及分析状态返回先前阶段的返工循环的关键。为何重要它提供了变更请求进度和最终结果的清晰视图，这对于吞吐量和返工分析至关重要。获取方式这是 Jira issue 的标准 `status` 字段。可用状态在项目的 workflow 配置中定义。示例计划中等待审批正在实施已结案已取消
	审批周期时间 ApprovalCycleTime	从变更提交评审到正式获批的时长。
描述这是一个计算指标，用于测量从“变更已提交评审”活动到“变更请求已批准”活动之间经过的时间。它隔离了变更生命周期的审批阶段以进行专项分析。该指标直接支持“变更审批周期时间”仪表板和相应的 KPI。它用于识别审批流程中的瓶颈，无论这些瓶颈源于特定审批组、变更类型还是风险等级。缩短这段时间可以显著加速整体变更交付过程。为何重要直接衡量审批阶段的效率，有助于精准定位并解决变更授权过程中的延误。获取方式通过计算特定变更请求 ID 在“已提交变更评审”和“变更请求已批准”两个时间戳之间的差值得出。示例 2 天 4 小时8 小时 30 分钟5天
	更改类型 ChangeRequestType	变更的分类，例如标准、普通或紧急。
描述变更类型根据变更请求的性质、紧急程度和影响对其进行分类。常见类型包括：“标准”（预先批准、低风险）、“普通”（需要完整审批的常规变更）和“紧急”（用于修复事故的紧急变更）。此属性对流程分析至关重要，因为不同的变更类型通常遵循不同的流程路径并具有不同的 SLA。它用于计算“紧急变更率”KPI，并用于过滤仪表板以比较每种类型的绩效和风险。为何重要它支持流程分段，以便分析不同的工作流（如标准变更与紧急变更），这些工作流具有独特的性能预期和风险属性。获取方式这通常是 Jira Service Management 项目中的自定义字段。字段名称可能有所不同，但通常命名为“变更类型”。示例标准普通紧急
	目标完成日期 TargetCompletionDate	计划的或服务水平协议 (SLA) 规定的变更请求完成截止日期。
描述此属性存储为满足 SLA 而预期完成变更请求的日期。它是衡量实际完成时间的基准。此日期是监控承诺履行情况的基础。它是“变更 SLA 绩效监控”仪表板和“变更 SLA 达成率”KPI 的核心。通过将实际解决日期与此目标进行对比，组织可以衡量其服务交付的有效性。为何重要这是计算 SLA 达成率和识别哪些变更有逾期风险的核心 data 点。获取方式这通常是 Jira 中的 `duedate` 字段，或者是 Jira Service Management 中配置的 SLA 指标值。示例 2023-11-15T17:00:00Z2023-12-01T23:59:59Z2024-01-10T09:00:00Z
	风险等级 RiskLevel	与变更关联的评估风险等级，例如低、中或高。
描述风险等级在大多数变更管理流程中是强制性评估项，用于对变更的潜在负面影响进行分类。该等级在风险评估阶段确定，并通常影响所需的审批 workflow。在 Process Mining 中，此属性对于基于风险的分析至关重要。它通过将初始风险与实际结果相关联，为“风险评估准确性与结果”仪表板提供支持。它也是“按风险等级划分的变更失败率”KPI 的核心维度，有助于评估高风险变更是否得到了有效管理。为何重要用于分析流程控制和审批工作流对于不同风险概况是否有效，并有助于将风险与变更失败率进行关联分析。获取方式这通常是 Jira Service Management 中的自定义字段。通用名称包括“风险等级”或“影响”。示例低中高严重
	业务服务 BusinessService	受变更影响的业务服务或应用。
描述此属性将变更请求关联到配置管理数据库 (CMDB) 中定义的特定业务服务（如“邮件服务”或“客户 CRM”）。这是理解变更业务影响的关键概念。按业务服务分析变更可以帮助确定工作优先级并向利益相关者传达影响。它能直观展示哪些服务正在经历最多的变更、哪些风险最大，以及变更相关事故集中在何处。这对于从以业务为中心的角度管理技术变更至关重要。为何重要将技术变更与业务影响关联起来，以便根据受影响服务的重要性进行优先级排序和风险分析。获取方式这通常是 JSM 中的自定义字段，经常关联到 Jira Assets（原 Insight）或其它 CMDB。示例公司官网SAP ERP内部 Wiki
	变更原因 ChangeReason	提出变更的理由或业务原因。
描述此属性捕获变更的深层原因，例如“新功能实施”、“Bug 修复”或“基础设施升级”。它提供了摘要或描述之外的关键背景。在分析中，变更原因可以与周期时间、失败率和风险等级等其它指标相关联。这有助于回答诸如“Bug 修复类变更是否比新功能实施获批更快？”或“基础设施升级的失败率是否更高？”等问题。为何重要提供业务背景，通过将变更目的与其表现和结果相关联，支持更深层次的分析。获取方式这通常是 Jira Service Management 中的自定义字段，通常是选择列表或文本字段。示例安全补丁软件升级新硬件安装
	团队 Team	负责变更请求或特定活动的团队或小组。
描述此属性标识分配处理变更的团队。虽然 Jira 有针对个人的 Assignee 字段，但通常会使用“团队”字段将工作分配给职能组（如“网络运营”或“数据库管理员”）。这对于“变更团队活动工作量”仪表板至关重要。它支持在团队层面（而非仅在个人层面）进行绩效和瓶颈分析，这对于资源规划和管理通常更有用。为何重要有助于在团队或部门维度进行工作负载和绩效分析，凸显系统性瓶颈。获取方式这通常是 Jira 中的自定义字段，因为没有标准的“团队”字段。它的类型可能是“组选择器”或简单的选择列表。示例基础设施团队核心服务应用支持
	实施后问题 PostImplementationIssue	一个标记，指示在实施后是否有事故 (incident) 或问题 (problem) 关联到此变更。
描述此属性指示变更是否导致了负面结果，例如生产事故。这通常涉及将变更请求 issue 与 Jira 中的一个或多个事故 issue 关联起来。此 data 对于计算“实施后问题率”和“变更失败率”KPI 至关重要。它直接衡量了变更质量以及规划、测试和风险评估流程的有效性。分析哪些变更会导致问题，有助于完善管控并防止未来发生类似失败。为何重要通过追踪变更是否引发后续运营问题，直接衡量变更的质量和成功率。获取方式这通常是通过检查 Jira 中的关联 issue 来推断的，特别是变更 issue 是否具有来自事故 issue 的“原因在于”链接。示例 truefalse
	报告人 Reporter	最初创建或提交变更请求的用户。
描述 Reporter 是指在 Jira 中创建变更请求 issue 的个人。这通常是变更负责人或代表团队发起变更的人员。分析 reporter 有助于识别哪些部门、团队或个人发起的变更最多。它可用于发现变更来源的趋势，并向经常提交不完整或低质量变更请求的群体提供反馈或培训。为何重要有助于识别变更请求的来源，通过分析来源可以提升初始提交的质量。获取方式这是 Jira issue 上的标准 `reporter` 字段。示例 David MillerEva GreenFrank Wright
	是否返工 IsRework	一个布尔标记，如果变更请求经历过返工 (rework) 循环，则为 true。
描述此计算属性识别被发回前一阶段进行修改的变更请求，例如从“等待审批”退回“计划中”。这信号表明初始提交不完整、不正确或不符合必要标准。此标识是“变更返工率”KPI 和“变更返工与拒绝分析”仪表板的基础。通过标记返工 case，分析师可以轻松过滤并调查根本原因，如初始规划不周、需求不明或风险评估不足。为何重要通过明确标记需要额外计划外工作的案例，凸显流程低效环节，从而支持对返工根源的分析。获取方式通过分析事件日志中的活动序列计算得出。如果后期活动之后紧跟着前期活动，则检测为一次返工 (rework)。示例 truefalse
	解决 Resolution	已关闭变更请求的最终结果，表明其解决方式。
描述当变更请求关闭时，解决结果字段提供有关结果的具体信息。例如，“完成”表示成功，而“不做了”或“重复”则提供其它关闭原因。这比单纯的“已关闭”状态提供了更多背景信息。此属性对于分析变更成功率和失败率至关重要。例如，通过过滤具有“失败”或“已回滚”解决结果的变更，可以更好地理解“实施后问题率”KPI。它有助于区分成功实施的变更与那些获批后被取消或拒绝的变更。为何重要提供变更最终结果的详细背景，这对于准确计算成功率和失败率至关重要。获取方式这是 Jira 中的标准 `resolution` 字段，通常在 issue 移至“完成”状态类别时设置。示例已完成暂不处理重复已取消已回滚

必填推荐可选

变更管理活动

这些是需要在 event log 中捕获的关键流程步骤和里程碑，以便准确进行变更管理流程发现。

5 推荐 8 可选

	活动	描述
	变更已关闭	代表变更请求的最终关闭，表示所有关联活动均已完成。当 Jira issue 状态变更为“已关闭”或“完成”等最终解决状态时捕获。
为何重要这是流程的主要终点。它用于计算整体周期时间并确定对 SLA 的遵循情况。获取方式通过识别“状态 (status)”字段变更为最终关闭状态的时间戳，从 Jira 事宜历史记录中推断得出。此时通常也会设置解决结果字段。捕获跟踪状态流转至“已关闭”或“完成”时的 timestamp。事件类型 inferred
	变更已实施	一个关键里程碑，指示与变更相关的工作已完成。通过 Jira 工作流中的状态变更（如变更为“已实施”或“待验证”）进行捕获。
为何重要这标志着实施阶段的结束，对于计算实施提前期至关重要。它也是实施后评审和验证活动的触发点。获取方式通过识别“状态 (status)”字段变更为“已实施”或“待实施后评审”的时间戳，从 Jira 事宜历史记录中推断得出。捕获跟踪状态流转至“已实施”或类似状态时的 timestamp。事件类型 inferred
	变更等待审批	指示变更请求已通过初步评审，正在等待变更咨询委员会 (CAB) 或指定审批者的正式决定。通过工作流中的状态变更（如移至“待审批”或“等待 CAB”）进行捕获。
为何重要此活动是测量审批等待时间和识别决策阶段瓶颈的关键，直接影响“变更审批周期时间”KPI。获取方式通过识别“状态 (status)”字段变更为“待 CAB 审批”或“等待审批”等审批状态的时间戳，从 Jira 事宜历史记录中推断得出。捕获跟踪状态流转至指定的“等待审批”状态时的 timestamp。事件类型 inferred
	变更请求已创建	代表在 Jira Service Management 中初始创建变更请求工单。当首次保存“变更”类型的 issue 时，此 event 会带上创建 timestamp 被明确记录。
为何重要这是所有变更请求的起点，对于衡量整体提前期和分析随时间变化的变更量至关重要。获取方式从 Jira 事宜对象的 'created'（创建）时间戳中捕获。这是每个事宜都有的标准系统字段，可通过事宜历史记录或 API 获取。捕获使用来自 Jira issue 的 'created' 字段 timestamp。事件类型 explicit
	变更请求已批准	一个关键里程碑，表示变更已正式获准实施。通常是通过捕获 Jira 工作流中状态变更为“已批准”或“准备实施”等状态来实现的。
为何重要此 event 标志着审批周期的结束和实施阶段的开始。这对于衡量审批周期时间和跟踪未经授权的变更是必不可少的。获取方式通过识别“状态 (status)”字段流转至“已批准”状态的时间戳，从 Jira 事宜历史记录中推断得出。捕获跟踪状态流转至“已批准”或“准备实施”时的 timestamp。事件类型 inferred
	变更已取消	代表变更请求在实施或完成前终止。当 Jira issue 状态变更为“已取消”或“撤回”等终止状态时捕获。
为何重要这一替代终点有助于分析变更被放弃的原因。高取消率可能表明初始规划不佳或业务优先级发生了变化。获取方式通过识别“状态 (status)”字段变更为“已取消”状态且设置了相应解决结果的时间戳，从 Jira 事宜历史记录中推断得出。捕获跟踪状态流转至“已取消”或“撤回”时的 timestamp。事件类型 inferred
	变更已提交评审	标志着变更请求的初始信息已完备并正式提交评估。通常通过推断 Jira workflow 中的状态变化（例如从“草稿”变为“待评审”）来捕获此节点。
为何重要此活动启动了审批周期。测量从该节点到获批的时间，对于计算审批周期时间 KPI 和识别早期瓶颈至关重要。获取方式通过识别“状态 (status)”字段变更为“待评审”或“等待评估”等评审状态的时间戳，从 Jira 事宜历史记录中推断得出。捕获跟踪状态流转至“待评审”、“已提交”或类似状态时的 timestamp。事件类型 inferred
	变更已调度	指示已批准的变更已被分配了特定的实施窗口。这是通过 Jira 事宜中“计划开始日期”和“计划结束日期”字段的填充或更新来推断的。
为何重要此活动提供了变更前瞻性规划的透明度。它有助于资源管理，并评估从审批到计划实施之间的时间间隔。获取方式通过捕获“计划开始日期”或“变更窗口”等日期字段被填充的时间戳，从 Jira 事宜历史记录中推断得出。捕获跟踪“计划开始日期”字段填写时的 timestamp。事件类型 inferred
	变更请求已驳回	代表正式拒绝变更请求，通常会将其发回请求者以获取更多信息或直接取消。通过 Jira workflow 状态变更为“已拒绝”或“需要更多信息”来捕获。
为何重要跟踪拒绝情况对于分析“变更返工率”至关重要。此活动的高频发生表明初始变更提交的质量存在问题。获取方式通过识别“状态 (status)”字段变更为“已驳回”或类似终态的时间戳，从 Jira 事宜历史记录中推断得出。捕获跟踪状态流转至“已拒绝”或“驳回”时的 timestamp。事件类型 inferred
	实施后评审已完成	指示正式评审已完成，该评审旨在评估变更是否成功并总结经验教训。通常通过工作流中的状态变更（如从“实施后评审”移至“已验证”）进行捕获。
为何重要此活动对流程改进至关重要。测量此评审的周期时间有助于确保及时汲取经验教训。获取方式通过识别“状态 (status)”字段移出“实施后评审”状态的时间戳，从 Jira 事宜历史记录中推断得出。捕获跟踪状态从“PIR”流转至后续状态时的 timestamp。事件类型 inferred
	实施已开始	标志着已获批变更的技术实施正式开始。通常根据 Jira 中的状态从“已批准”或“待排期”转为“进行中”或“实施中”来捕获此 event。
为何重要此活动启动了衡量“平均实施提前期”的计时，有助于识别执行阶段的瓶颈。获取方式通过识别“状态 (status)”字段变更为“进行中”等活跃实施状态的时间戳，从 Jira 事宜历史记录中推断得出。捕获跟踪状态流转至“进行中”或“实施中”时的 timestamp。事件类型 inferred
	已执行测试	代表为验证变更而进行的实施后测试已完成。这可以是一个独立的状态（如“测试中”），也可以是从“变更已实施” event 后 QA 团队的评论或更新中推断出来的。
为何重要分析测试的时长和结果有助于评估实施质量和测试流程的有效性。这是计算“实施后问题率”的关键输入项。获取方式这可以从状态变更为“测试中”推断，或者通过分析实施后 issue 历史记录中的评论和 Assignee 变更来识别。捕获跟踪状态流转至“测试中”的 timestamp 或通过评论记录的时间。事件类型 inferred
	已执行风险评估	代表针对提议变更的风险和影响分析已完成。当“风险等级”或“影响”等风险相关自定义字段被填写或更新时，通常从 issue 历史记录中推断此 event。
为何重要分析此活动有助于评估风险评估的准确性并确保遵循变更策略。这对于计算基于风险的 KPI（如按风险等级划分的变更失败率）至关重要。获取方式通过捕获“风险等级”、“影响度”或“紧急度”等特定字段首次设置或变更的时间戳，从 Jira 事宜历史记录中推断得出。捕获跟踪“风险等级”或“影响”等字段首次填写时的 timestamp。事件类型 inferred

推荐可选

提取指南

如何从Jira Service Management获取数据

步骤

访问 Jira 事宜导航器：登录您的 Jira Service Management 实例。在主导航栏中选择“事宜”，然后选择“搜索事宜”以打开事宜导航器。
切换至 JQL 搜索：如果您处于“基本”搜索模式，请点击“JQL”（在某些版本中为“高级”）切换到高级模式。这样您就可以输入自定义的 Jira 查询语言 (JQL) 语句。
筛选变更请求：在搜索栏中输入本文档“查询”部分提供的 JQL 语句。根据您的实际情况修改项目键、变更事宜类型名称以及所需的日期范围占位符。
执行搜索并导出数据：运行搜索。显示变更请求事宜列表后，点击通常位于右上角的“导出”按钮。选择“导出 Excel CSV (所有字段)”选项。此格式至关重要，因为它包含了重建流程流转所需的详细事宜历史记录。
加载 CSV 进行转换：使用 Power Query、基于 pandas 库的 Python 脚本或其他 ETL 工具打开下载的 CSV 文件。原始导出文件每行代表一个事宜，但其中包含存有历史数据的列。
构建基础数据：为源文件中的每一行创建初始的“已创建变更请求”事件。将“事宜键 (Issue key)”映射为 ChangeRequestId，将 ActivityName 设置为“Change Request Created”，并将“Created”列作为 EventTime。
逆透视状态历史 (Unpivot Status History)：定位包含状态流转历史记录的列。每一次状态变更都是一个事件。针对每个变更请求，为每一个相关的状态流转（例如，从“草稿”到“待评审”，或从“待审批”到“已批准”）创建新行。将这些流转映射到对应的 ActivityName，如“已提交变更评审”、“变更等待审批”、“变更请求已批准”等。状态变更的时间戳即为 EventTime。
逆透视字段更新历史：某些活动是通过字段更新而非状态变更来推断的。处理“风险等级”、“计划开始日期”和“计划结束日期”等字段的历史记录。根据这些字段首次填充或更新的时间戳，为“已执行风险评估”和“已调度变更”事件创建新行。
映射并增强属性：为您创建的每个事件行，将相应的 Jira 字段映射到所需的属性，如 ChangeRequestStatus、ChangeRequestType、Assignee 和 Priority。属性值应为该事件发生时的当前值。
添加元数据列：添加一个名为 SourceSystem 的列，静态值为 'Jira Service Management'。再添加一个名为 LastDataUpdate 的列，并填入执行数据提取的时间戳。
计算派生指标：在生成完整的事件日志后，计算需要多个数据点的属性，例如 ApprovalCycleTime（审批周期）。这需要计算每个 ChangeRequestId 在“已提交变更评审”和“变更请求已批准”事件之间的时间差。
完成并导出上传：确保最终表包含必需列：ChangeRequestId、ActivityName 和 EventTime。删除所有中间列或源列。将最终转换后的数据保存为 UTF-8 编码的 CSV 文件，并上传到流程挖掘工具中。

配置

JQL 过滤器：JQL 查询是筛选正确数据集的核心工具。关键过滤器包括 project、issuetype 以及针对 created 字段的日期范围过滤，以此来限定提取范围。
日期范围：建议初始选择 3 到 6 个月的数据，这样既能保证数据集的代表性，又不会引发性能问题。例如：created >= "-180d"。
事宜类型 (Issue Type)：您必须指定 Jira 实例中用于变更管理的准确事宜类型名称，例如 issuetype = "Change" 或 issuetype = "Change Request"。
导出格式：请务必选择“导出 Excel CSV (所有字段)”。此选项可确保导出文件中包含所有自定义字段，以及最重要的状态和字段的完整变更日志历史记录。如果导出字段受限，将无法获取构建事件日志所需的数据。
Jira 权限：执行导出的用户必须拥有指定项目的“浏览项目”权限，以及查看所有相关事宜字段的必要权限。
自定义字段识别：在进行数据转换之前，您需要确定 Jira 实例中与流程属性（如“风险等级”、“计划开始日期”和“变更类型”）对应的自定义字段准确名称。

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 并导航至您的变更管理项目，记下以下信息：
- 项目键 (Project Key)：项目的短标识符，例如 'CSM'。
- 事宜类型名称 (Issue Type)：变更请求的准确名称，通常为 'Change'。
- 工作流状态：变更工作流中每个状态的名称，例如“待评审”、“待审批”、“进行中”、“已关闭”等。
- 自定义字段名称：用于“变更类型”、“风险等级”、“计划开始日期”和“计划结束日期”的自定义字段名称。
定制 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。该文件现在即可上传到流程挖掘工具进行分析。

配置

数据库访问 (Database Access)：需要一个指向 Jira 生产数据库的只读用户账号。请注意，只有 Jira Server 和 Jira Data Center 实例支持直接访问数据库，Jira Cloud 暂不支持。
Jira 项目键 (Project Key)：查询必须配置为您 Jira Service Management 项目的特定键。请在 p.pkey IN ('[Your_JSM_Project_Key]') 子句中进行设置。
变更的事宜类型 (Issue Type)：查询默认变更请求的事宜类型名称为“Change”。如果您的配置使用了其他名称，请务必更新 issuetype.pname = 'Change' 过滤器。
工作流状态映射：事件日志的准确性完全取决于查询中 WHERE 子句的状态名称是否与您项目中的实际工作流状态正确映射。请仔细核对并更新每个 'Status Name' 字符串。
自定义字段映射：查询依赖自定义字段名称来跟踪特定活动（如“已执行风险评估”、“已调度变更”）和属性。您必须验证并更新类似 '[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 或更高版本。运行命令 pip install requests pandas 来安装必要的库：用于 API 调用请求的 requests 和用于数据处理的 pandas。
生成 Jira API 令牌 (Token)：登录您的 Jira 账号。进入个人资料设置，选择“账号设置”，然后导航到“安全”选项卡并点击“创建和管理 API 令牌”。创建一个新令牌并妥善备份。该令牌将作为 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 字段的日期范围（例如，过去 180 天为 created >= -180d）。设定特定的日期范围对于管理数据量至关重要。
状态与字段映射：脚本的准确性完全依赖于 STATUS_TO_ACTIVITY_MAPPING 和 FIELD_TO_ACTIVITY_MAPPING 字典。必须根据您组织的 Jira 工作流状态和自定义字段名称对这些内容进行精准配置，以生成正确的活动。
API 凭证：脚本需要有效的 JIRA_URL、JIRA_EMAIL 和 JIRA_API_TOKEN 进行身份验证。与该令牌关联的用户必须拥有指定项目及所有相关字段的读取权限。
数据分页：脚本使用 maxResults 参数（设为 100）通过 API 分批次（分页）获取事宜。这对于在不发生超时的情况下稳定提取大量事宜至关重要。
变更日志扩展 (Changelog Expansion)：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.")

您的变更管理数据模板

您的变更管理数据模板

变更管理属性

变更管理活动

提取指南

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% 的成功率