> 持续流程改进 > 服务请求管理 > Jira Service Management > 数据模板

您的服务请求管理数据模板

Jira Service Management

← 返回改进指南

服务请求管理属性(17) 服务请求管理活动(13) 数据提取指南(3)

您的服务请求管理数据模板

此模板提供了结构化方法，帮助您收集分析服务请求流程所需的关键数据。模板列出了需要收集的重要属性、需要跟踪的关键活动，并说明如何从系统中提取这些信息。您可以使用此资源简化数据准备工作，更深入地了解运营情况。

全面分析所需的推荐属性
流程发现所需跟踪的关键活动
Jira Service Management数据提取指南

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

下载模板

服务请求管理属性

以下是建议纳入事件日志的数据字段，可用于全面分析服务请求管理。

5 必填 5 建议填写 7 选填

	名称	说明
	开始时间 EventTime	某项活动或事件发生的准确日期和时间。
说明开始时间也称事件时间戳，用于记录活动发生的准确时刻。这是流程挖掘分析的重要组成部分，为整个流程提供时间背景。时间戳用于按顺序排列事件、计算活动间隔时长、衡量案例总周期时间，以及分析流程绩效是否达到SLA等时限目标。没有准确的时间戳，就无法了解流程走向、识别延误或衡量效率。重要性该时间戳对于排列事件、计算时长和周期时间，以及识别流程瓶颈至关重要。获取途径这是Jira问题变更日志中每次状态变更对应的时间戳。问题创建时间记录在“created”字段中。示例 2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:20:05Z
	服务请求ID ServiceRequestId	每个服务请求的唯一标识符，也是所有相关事件的主键。
说明服务请求ID在Jira中通常称为问题键，用于唯一标识用户或系统提交的每个服务请求。它将从初始登记到最终关闭的所有后续事件串联起来，便于端到端分析每个服务请求的处理过程。在流程挖掘中，该ID对于案例关联至关重要。它能确保每项活动、状态变更和时间戳都与对应请求正确关联，从而形成连贯的流程实例供分析使用。重要性该ID是关键的案例标识符，可将所有相关活动关联到同一个端到端流程中，从而支持流程分析。获取途径这是Jira Service Management中问题的“key”字段。示例 SR-2023-001IT-45892HELP-105
	活动 ActivityName	服务请求生命周期中发生的具体事件或任务的名称。
说明此属性描述服务请求在某个时间点发生的具体操作或状态变更。例如“请求已创建”“请求已分配”“解决方案已实施”和“请求已关闭”。分析这些活动的顺序和频率是流程挖掘的核心。通过分析可以直观呈现流程图、识别瓶颈并发现偏离标准工作流的情况，从而了解流程效率和合规情况。重要性该属性定义流程中的步骤，支持呈现流程图，并分析工作流模式和偏差。获取途径通常根据Jira问题的“status”变更历史得出。问题变更日志中每条针对状态字段的记录都代表一项活动。示例完成请求分诊请求补充信息实施解决方案服务请求已关闭
	数据最近更新时间 LastDataUpdate	表示数据最近一次从源系统刷新时间的时间戳。
说明此属性记录最近一次从Jira Service Management提取数据的日期和时间，为仪表板和KPI中的分析结果及数据新鲜度提供重要背景。做出有依据的决策，必须了解数据的时效性。此时间戳可帮助用户判断当前查看的是实时信息，还是某个较早时间点的数据快照，这会影响分析结果的参考价值。重要性显示数据的新鲜度，确保分析基于最新信息。获取途径这是数据提取工具或脚本在运行结束时生成并保存的元数据字段。示例 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	源系统 SourceSystem	提取服务请求数据的系统。
说明此属性标识数据来源，本例中为Jira Service Management。分析单一来源的数据时，它可能看似无关紧要；但合并多个系统的流程数据时，这一属性就十分重要。在分析中，它有助于追踪数据来源并确保数据质量，也支持筛选和比较涉及不同软件平台的流程。重要性标识数据来源，对于数据治理以及合并多个企业系统的流程数据至关重要。获取途径这通常是在数据提取和转换过程中添加的静态值，用于标记数据集的来源。示例 Jira Service ManagementJiraSM
	SLA截止时间 SlaDueDate	根据SLA要求，服务请求应在此日期和时间前解决。
说明 SLA截止时间是计算得出的时间戳，表示解决请求的最后期限。该时间由请求的优先级、类型以及Jira Service Management中配置的具体服务级别协议（SLA）策略决定。此属性是“服务请求SLA绩效”仪表板和“SLA达成率”KPI的基础。将实际解决时间与截止时间比较，系统即可判断每个请求是否按时完成、是否逾期，或是否存在违反SLA的风险。重要性这是衡量绩效的基准，直接支持SLA达成情况的计算，并有助于确定工作优先级。获取途径 SLA信息由Jira Service Management管理，可通过API访问，通常存储在会动态更新的自定义字段中。示例 2023-10-28T16:00:00Z2023-11-01T09:00:00Z
	经办人 Assignee	当前负责处理服务请求的用户或客服人员。
说明经办人是负责采取下一步行动或解决服务请求的人员。在请求生命周期中，随着请求在不同客服人员或团队之间转交，该属性的值可能多次变化。此属性对于工作量分析、绩效衡量和资源管理至关重要。您可以按客服人员筛选流程、比较不同人员的解决时间，并识别潜在的培训需求或导致瓶颈的工作量失衡。重要性此属性对于分析客服人员的工作量、衡量个人绩效和了解资源分配至关重要。获取途径对应Jira问题中的“assignee”字段。示例 Alice JohnsonBob Williams未分配
	请求优先级 RequestPriority	服务请求的优先级，例如低、中、高或严重。
说明请求优先级表示服务请求的紧急程度和业务影响。此分类决定请求的处理顺序，通常也决定目标解决时间和SLA要求。在流程分析中，优先级是重要的细分维度。您可以比较不同优先级的周期时间和SLA达成情况，确认高优先级请求是否得到更快处理并达到目标，从而验证优先级机制是否有效。重要性支持按优先级细分分析，确保高优先级请求得到更快处理并达到更严格的服务标准。获取途径对应Jira问题中的“priority”字段。示例最高高中低
	请求状态 RequestStatus	服务请求在生命周期中的当前状态。
说明此属性表示服务请求的当前状态，例如“待处理”“处理中”“等待客户”或“已解决”，让您随时了解请求进展。活动日志记录了历史流程，而当前状态则适用于分析未完成的工作量并识别停滞事项。例如，您可以重点查看处于“等待供应商”状态时间异常长的请求，发现外部依赖和延误。重要性提供每个案例的当前状态快照，便于分析进行中的工作，并识别停滞或积压过久的请求。获取途径这是Jira问题中的“status”字段。示例待处理处理中等待客户已解决
	请求类型 RequestType	服务请求的分类，例如“访问权限申请”或“硬件问题”。
说明请求类型根据服务请求的性质进行分类，是重要的分析维度，因为不同类型的请求通常有不同的解决流程、SLA和资源需求。按请求类型细分流程分析，组织便可针对不同工作流制定改进措施。例如，“重置密码”请求的瓶颈与“配置新服务器”请求的瓶颈可能截然不同。此属性也是构建“按类别划分的解决质量”等相关仪表板的关键。重要性此属性对于比较不同类别服务请求的流程、工作量和绩效至关重要。获取途径通常对应Jira中的“issuetype”字段，或Jira Service Management中的自定义“Request Type”字段。示例申请新账户获取IT支持为新员工办理入职
	SLA状态 SlaState	表示服务请求是否达到、违反或仍在规定的SLA范围内。
说明 SLA状态是一个计算属性，根据服务请求相对于SLA截止时间的绩效进行分类。可能的值包括“已达成”“已违反”或“处理中”。该状态通过比较解决时间戳与“SlaDueDate”得出。这是“服务请求SLA绩效”仪表板的核心属性，也用于计算“SLA达成率”KPI。它能清晰、直观地呈现服务级别达成情况，对于报告、合同管理和维持服务质量至关重要。重要性清晰、直观地显示SLA绩效，这是衡量服务质量和合同履行情况的重要指标。获取途径在数据转换过程中计算。如果解决时间早于“SlaDueDate”，状态为“已达成”；否则为“已违反”。示例已达成已违反处理中
	所属团队 AssignedTeam	负责处理服务请求的团队或小组。
说明此属性指定负责处理请求的团队，通常比单个经办人涵盖的范围更广。您可以据此分析团队层面的绩效，例如比较一级支持团队和网络运营团队。此维度对于“客服人员工作量与解决指标”等仪表板至关重要。它支持汇总团队层面的绩效指标，便于公平比较，并了解不同团队对整体服务交付流程的贡献。重要性支持在团队或部门层面分析绩效和均衡工作量，而不只关注个人客服人员。获取途径这可能是Jira中的自定义字段（例如“Team”），也可能根据经办人的用户资料属性得出。示例 IT支持-一级基础设施团队应用支持
	报告人 Reporter	最初创建或报告服务请求的用户。
说明报告人是提交服务请求的人员，通常为最终用户或客户。此属性标识发起流程的相关方。在分析中，您可以按报告人了解不同用户、部门或客户群体的请求模式。例如：“哪些部门提交的请求最多？”“是否有特定用户反复遇到相同问题？”这些信息有助于主动管理问题并改进用户培训。重要性标识请求发起人，支持按用户、部门或客户分析请求数量和类型。获取途径对应Jira问题中的“reporter”字段。示例 Charles DarwinMarie CurieIsaac Newton
	是否重新打开 IsReopened	布尔标记，用于指示服务请求在解决后是否重新打开。
说明此计算属性为真/假标记。如果请求的工作流中包含“请求已重新打开”活动，该标记就设为真。它通过分析每个案例的活动顺序得出。此标记对于计算“服务请求重新打开率”KPI和生成“重新打开的服务请求数量”仪表板至关重要。重新打开率较高，通常表明首次解决质量不佳，导致返工并降低客户满意度。分析哪些请求类型或解决结果与此标记相关，有助于找到改进方向。重要性直接衡量返工情况和首次解决质量，这些都是流程有效性和客户满意度的重要指标。获取途径在数据转换过程中计算：检查案例的活动顺序中，是否存在“已解决”之后的“重新打开”状态变更。示例 truefalse
	渠道 Channel	提交服务请求的方式，例如电子邮件、门户或API。
说明渠道属性标识服务请求通过何种方式进入系统。Jira Service Management的常见渠道包括客户门户、电子邮件，或由客服人员直接创建。按渠道分析流程有助于了解用户行为并优化服务交付。分析可以发现某些渠道的请求是否需要更长时间才能解决，或是否需要更多澄清，从而判断是否需要改进门户表单或优化邮件解析规则。这也为“服务请求处理量趋势”仪表板提供支持。重要性帮助分析提交渠道是否影响解决时间、请求信息的清晰度或整体流程效率。获取途径 Jira Service Management中的“Request channel type”字段提供此信息。可能需要特定API访问权限，或从自定义字段中获取。示例门户电子邮件API
	组织 Organization	报告人所属的客户组织或内部部门。
说明此属性按组织或部门对报告人进行分组。Jira Service Management内置“组织”功能，客服人员可借此管理来自多个客户或内部团队的请求。按组织分析可提供有价值的业务背景，帮助您识别哪些客户或部门消耗的支持资源最多、哪些群体反复遇到问题，以及不同业务单元是否持续达到SLA要求。重要性支持按客户或内部部门分析服务需求和绩效，提供关键业务洞察。获取途径此数据来自Jira Service Management中与服务请求关联的“组织”字段。示例 Acme Corporation财务部Global Tech Inc.
	解决结果 Resolution	已解决服务请求的最终结果或结论。
说明 “解决结果”字段说明服务请求关闭的原因。常见值包括“已完成”“不予处理”“重复”或“无法重现”。与“已解决”或“已关闭”状态相比，该字段提供了更具体的关闭信息。分析解决结果有助于了解处理结果的质量和性质。例如，“重复”结果数量较多，可能说明请求提交流程存在问题；追踪哪些解决结果会导致请求重新打开，则有助于发现无效的解决方案。重要性提供请求处理结果的背景信息，帮助分析解决质量并发现请求关闭原因的趋势。获取途径对应Jira问题中的“resolution”字段，通常在问题转入“已完成”状态类别时设置。示例已完成不予处理重复已修复

必填建议填写选填

服务请求管理活动

以下是建议记录在事件日志中的关键流程步骤和里程碑，有助于准确发现并优化流程。

5 建议填写 8 选填

	活动	说明
	分配请求	服务请求分配给具体服务专员或团队处理时，会发生此活动。Jira会明确跟踪“受派人”字段的变更，因此可以准确记录分配时间。
重要性这是衡量分诊到分配所需时间和服务专员工作量分布的重要节点，标志着请求从排队等待转入主动处理。获取途径查看问题历史记录，查找“受派人”字段首次被设置或从未分配状态变更的记录。采集使用问题历史记录中“受派人”字段首次变更的时间戳。事件类型 explicit
	创建服务请求	此活动标志着服务请求生命周期的开始，即用户通过门户、电子邮件或其他渠道正式提交请求。在Jira中创建“服务请求”类型的新问题时，系统会明确记录此事件及其创建时间戳。
重要性这是流程的主要开始事件，对于计算整体周期时间以及了解请求量和到达模式至关重要。获取途径此事件会明确记录在问题历史表中。活动时间戳取自Jira问题的“created”字段。采集使用“issues”表或历史记录中的问题创建时间戳。事件类型 explicit
	提出解决方案	在许多服务台工作流中，这是一个独立步骤：向请求者提供解决方案以供其确认。通常可根据问题状态推断，例如状态变为“等待客户验收”或“等待确认”。
重要性此活动可以单独统计提供解决方案后等待客户反馈的时间，帮助您将这段时间与内部处理时间区分开来。获取途径根据问题历史记录推断，记录状态变为表示等待客户验证解决方案的状态时的时间戳。采集找出状态变为“等待客户验收”或同等状态时的时间戳。事件类型 inferred
	服务请求已关闭	表示服务请求最终完成行政关闭，通常在请求处于“已解决”状态一段时间后自动发生。这是该问题在Jira生命周期中的终点。
重要性这是流程的最终结束事件。分析“已解决”到“已关闭”之间的时间，有助于了解行政处理开销或自动关闭策略。获取途径根据问题历史记录推断。时间戳对应最终变更为“已关闭”或其他等效终止状态的时间。采集识别状态最终变为“已关闭”的时间戳。事件类型 inferred
	服务请求已解决	记录请求被视为已完成并登记解决方案的正式时间点。Jira问题首次进入“已完成”类别的状态时，会自动填入“解决日期”字段。
重要性这是流程的主要结束里程碑，对于计算解决时间和SLA达成情况至关重要，也标志着主动处理工作的结束。获取途径这是一个明确事件。时间戳取自Jira问题的“解决日期”字段，该字段在问题首次转入“已完成”类别的状态时设置。采集使用Jira问题中的“resolutiondate”字段。该字段会自动填充。事件类型 explicit
	完成请求分诊	指对服务请求进行初步评估，以确定其优先级、类别和影响。通常可根据状态变更推断此活动，例如状态从“新建”变为“处理中”，或变为专门的“已分诊”状态。
重要性分析分诊所需时间，有助于评估请求初始处理流程的效率。此处的延误可能显著延长整体解决时间，并影响SLA达成率。获取途径根据问题历史记录推断：识别状态从初始的“新建”或“待处理”变为“处理中”等活动状态时的首个时间戳。采集根据项目工作流，找出状态从“新建”或同等初始状态变更的首次记录。事件类型 inferred
	实施解决方案	表示服务专员已采取必要措施或制定解决方案，以处理服务请求。通常可根据状态变更推断，例如状态变为“等待审核”或直接变为“已解决”。
重要性此节点标志着核心解决工作完成。到达此活动之前所花费的时间，通常代表流程中创造主要价值的阶段。获取途径根据问题历史记录推断，对应状态变为“已解决”“等待验收”或类似关闭前状态的时间戳。采集找出“状态”字段变更为表示工作已完成的值时的时间戳。事件类型 inferred
	开始联系供应商	此活动表示服务请求已升级至外部供应商或第三方，或需要其采取行动。通常可根据问题状态推断，例如状态变为“等待供应商”或“由第三方处理”。
重要性跟踪供应商协作情况，对于识别内部服务台无法直接控制的外部依赖和延误至关重要。获取途径根据问题历史记录推断。时间戳对应问题状态变为指定供应商状态的时间。采集找出“状态”字段变更为“等待供应商”等值时的时间戳。事件类型 inferred
	收到补充信息	请求者提供所需信息后，服务专员即可继续处理。通常可根据问题状态推断：问题离开“等待客户”状态，往往是由请求者添加评论触发的。
重要性此活动标志着与客户之间的信息请求和回复环节完成。从请求信息到收到信息之间的时间，是流程等待时间的重要组成部分。获取途径根据问题历史记录推断。时间戳对应问题状态从“等待客户”变回“处理中”的时间。采集找出“状态”字段从“等待”状态变回“活动”状态时的时间戳。事件类型 inferred
	确认解决方案	请求者正式接受所提出的解决方案时，会发生此活动，通常会触发状态自动变为“已解决”。一般可根据此状态变更推断该事件。
重要性此节点用于确认解决方案是否有效，也是停止SLA计时的触发点。它有助于衡量客户确认修复所需的时间。获取途径根据问题历史记录推断。时间戳对应状态从“等待客户验收”变为“已解决”或“已关闭”的时间。采集识别状态从“等待客户验收”变为“已解决”或“已关闭”的时间戳。事件类型 inferred
	结束供应商协作	外部供应商完成处理并将服务请求交回内部团队时，会发生此活动。通常可根据问题离开“等待供应商”状态推断。
重要性衡量供应商协作时长，有助于管理供应商表现并了解外部参与方对整体解决时间的影响。获取途径根据问题历史记录推断。时间戳对应问题状态从供应商状态变回“处理中”的时间。采集找出“状态”字段从供应商状态变回“活动”状态时的时间戳。事件类型 inferred
	请求补充信息	当服务专员需要请求者补充信息才能继续处理时，会发生此活动。通常可根据问题状态推断，例如状态变为“等待客户”或“等待输入”。
重要性频繁或耗时较长的“请求补充信息”环节，可能说明初始提交内容不清楚或沟通效率低下，是造成延误的重要原因。获取途径根据问题历史记录推断。时间戳对应问题状态变为“等待客户”或同等状态的时间。采集找出“状态”字段变更为表示流程正在等待客户的值时的时间戳。事件类型 inferred
	重新打开请求	此活动记录此前已解决的服务请求重新转为活动状态的情况。可根据状态从已解决或已关闭变回待处理或处理中推断。
重要性跟踪重新打开的请求，对于衡量解决质量和首次解决率至关重要。重新打开率偏高，说明解决方案效果不佳或问题反复出现。获取途径根据问题历史记录推断：识别状态从“已解决”或“已关闭”类别变为“待处理”或“处理中”类别的记录。采集查找状态类别从“已完成”变为“待办”或“处理中”的记录。事件类型 inferred

建议填写选填

数据提取指南

如何从Jira Service Management获取数据

步骤

登录Jira Service Management实例并打开主菜单。
选择筛选器，然后选择高级问题搜索。系统将打开问题导航器，您可以在其中创建查询。
在搜索栏中输入“查询”部分提供的JQL（Jira查询语言）语句，筛选出要分析的特定服务请求。根据需要调整项目键和日期范围。
点击搜索运行查询。检查返回的问题列表，确认数据集正确。
在搜索结果页面右上角，点击导出图标（通常是一个带向外箭头的方框）。
在下拉菜单中选择XML。必须使用XML，因为标准CSV导出不包含生成完整事件日志所需的详细变更历史。
将下载的XML文件保存到本地。文件包含查询中的所有问题，以及嵌入各问题数据中的完整变更历史。
导出的XML不是事件日志格式，因此需要进行后处理。使用脚本（例如Python、Powershell或其他语言编写）解析XML文件。
脚本必须遍历文件中的每个问题，根据创建时间戳生成“服务请求已创建”事件。随后解析每个问题的变更日志，识别与所需活动对应的“状态”和“受理人”字段变更。每项识别出的变更都应生成一行记录。
脚本应将数据转换为扁平CSV文件，并创建ServiceRequestId、ActivityName、EventTime及所有其他必需和推荐属性对应的列。
脚本生成的最终结果就是事件日志。保存此CSV文件，并准备将其上传到流程挖掘工具。

配置

JQL项目筛选条件：使用project = "[您的JSM项目键]"指定服务管理项目。请将占位符替换为项目键，例如“JSM”或“HELPDESK”。
JQL问题类型筛选条件：使用issuetype = "Service Request"，或使用您配置中服务请求所对应的问题类型名称。
日期范围：强烈建议按特定时间段筛选，以控制导出规模。可使用类似created >= "YYYY-MM-DD" AND created <= "YYYY-MM-DD"的条件。建议先选择3至6个月的范围。
导出格式：必须选择XML格式。CSV格式不包含创建事件日志所需的变更日志数据。
Jira权限：执行导出的用户必须拥有指定Jira项目的“浏览项目”权限，才能查看和导出问题。
数据量：Jira默认界面通常一次最多导出1000个问题。如果查询结果更多，必须缩小每次导出的日期范围，分批导出数据。

查询示例 config

project = "JSM" AND issuetype = "Service Request" AND created >= "2023-01-01" AND created <= "2023-12-31" ORDER BY created ASC

步骤

获取数据库访问权限：获取Jira实例后端SQL数据库的只读凭据和连接信息（主机名、端口、数据库名称）。通常需要数据库管理员或IT部门协助。
了解Jira架构：使用DBeaver、SQuirreL SQL或SQL Server Management Studio等SQL客户端连接数据库。熟悉以下关键表：jiraissue（问题核心数据）、changegroup（变更历史）、changeitem（每项变更的详细信息）、project（项目信息）、issuetype和priority。
查找自定义字段ID：RequestType和SlaDueDate等属性通常是自定义字段。查询customfield表以确定其ID：SELECT id, cfname FROM customfield WHERE cfname IN ('[您的请求类型字段名称]', '[您的SLA字段名称]');。记录这些ID，以便在主查询中使用。
自定义SQL查询：将提供的SQL脚本复制到SQL客户端。请仔细将方括号中的所有占位符替换为Jira配置中的实际值，包括项目键、问题类型名称、状态名称和自定义字段ID。
设置日期范围：在查询初始issue_base部分中找到WHERE i.created >= '[YYYY-MM-DD]'条件。修改日期以设定数据提取的时间范围。
运行查询：执行修改后的SQL脚本。该查询适用于PostgreSQL、SQL Server和MySQL等常见SQL数据库。对于大型Jira实例，运行可能需要几分钟。
检查结果：查询完成后，简单检查输出，确认返回了数据行，且ServiceRequestId、ActivityName和EventTime等列已按预期填充。
导出数据：通过SQL客户端将完整结果集导出为CSV文件。使用清晰易懂的文件名，例如jira_servicerequest_eventlog.csv。
准备上传：打开CSV文件，确认列标题与所需属性名称完全一致，例如ServiceRequestId、ActivityName和EventTime。请使用UTF-8编码保存文件，以确保与ProcessMind兼容。

配置

前提条件：必须能够直接只读访问Jira生产数据库或副本数据库。仅有标准应用程序访问权限并不足够。您还需要充分了解Service Desk项目的工作流，包括状态、问题类型和自定义字段的准确名称。
关键查询筛选条件：必须正确配置查询，以筛选出所需数据。请特别注意以下WHERE条件：
- p.pkey IN ('[您的项目键]')：这是最重要的筛选条件，用于将数据限定在一个或多个指定的Jira Service Management项目中。
- it.pname = '[您的服务请求问题类型]'：确保只提取服务请求，不包含事件、问题或其他问题类型。
- i.created >= '[YYYY-MM-DD]'：设置数据提取的起始日期。初次分析建议选择最近3至6个月的数据。
工作流状态映射：事件日志的准确性完全取决于查询中Jira状态映射是否正确。您必须将[分诊状态]、[等待客户状态]和[已解决状态]等占位符替换为您实际工作流中的状态名称。
性能注意事项：直接在大型且活跃的Jira数据库上运行此查询会占用大量资源，并可能影响用户使用应用程序的性能。强烈建议在只读副本数据库上运行提取，或安排在非高峰时段执行。

查询示例 sql

WITH issue_base AS (
    SELECT 
        i.id AS issue_id,
        i.issuenum,
        i.project AS project_id,
        p.pkey || '-' || i.issuenum AS ServiceRequestId,
        i.created AS creation_timestamp,
        i.resolutiondate AS resolution_timestamp,
        u.display_name AS Assignee,
        pr.pname AS RequestPriority,
        s.pname AS RequestStatus,
        it.pname AS IssueTypeName, 
        cf_type.stringvalue AS RequestType,
        cf_sla.datevalue AS SlaDueDate
    FROM jiraissue i
    JOIN project p ON i.project = p.id
    LEFT JOIN issuetype it ON i.issuetype = it.id
    LEFT JOIN issuestatus s ON i.issuestatus = s.id
    LEFT JOIN priority pr ON i.priority = pr.id
    LEFT JOIN app_user u ON i.assignee = u.user_key
    LEFT JOIN customfieldvalue cf_type ON i.id = cf_type.issue AND cf_type.customfield = [Your Request Type Custom Field ID]
    LEFT JOIN customfieldvalue cf_sla ON i.id = cf_sla.issue AND cf_sla.customfield = [Your SLA Due Date Custom Field ID]
    WHERE p.pkey IN ('[Your Project Key]') 
    AND it.pname = '[Your Service Request Issue Type]' 
    AND i.created >= '[YYYY-MM-DD]'
),
change_history AS (
    SELECT 
        cg.issueid AS issue_id,
        cg.created AS change_timestamp,
        ci.field AS changed_field,
        ci.oldstring AS old_value,
        ci.newstring AS new_value
    FROM changegroup cg
    JOIN changeitem ci ON cg.id = ci.groupid
    WHERE ci.fieldtype = 'jira' AND ci.field IN ('status', 'assignee', 'resolution')
)
SELECT
    ib.ServiceRequestId,
    'Service Request Created' AS ActivityName,
    ib.creation_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Request Triaged' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Status for Triage]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Request Assigned' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'assignee' AND ch.new_value IS NOT NULL

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Information Requested' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Waiting for Customer Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Information Provided' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.old_value = '[Waiting for Customer Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Vendor Engagement Started' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Waiting for Vendor Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Vendor Engagement Ended' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.old_value = '[Waiting for Vendor Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Solution Implemented' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Solution Implemented Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Resolution Proposed' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Pending Customer Acceptance Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Request Reopened' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'resolution' AND ch.new_value IS NULL AND ch.old_value IS NOT NULL

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Resolution Confirmed' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.old_value = '[Pending Customer Acceptance Status]' AND ch.new_value = '[Resolved Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Service Request Resolved' AS ActivityName,
    ib.resolution_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
WHERE ib.resolution_timestamp IS NOT NULL

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Service Request Closed' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Closed Status]'
ORDER BY 1, 3;

步骤

准备与设置：确保系统已安装Python 3.6或更高版本。在终端中运行以下命令，安装所需的Python库：pip install requests pandas。
生成Jira API令牌：登录Jira Cloud账户，进入个人资料设置，选择“账户设置”，再打开“安全”选项卡并创建API令牌。请妥善保存令牌，后续需要使用它进行身份验证。
查找自定义字段ID：许多Jira属性（如“请求类型”或“SLA到期日期”）都是自定义字段。要查找其ID，请依次进入“设置”>“问题”>“自定义字段”。搜索所需字段，点击三点菜单“...”>“查看字段信息”。ID会显示在URL中（例如customFieldId=10021）。请记录这些ID，以便配置脚本。
配置Python脚本：在文本编辑器中打开提供的Python脚本。填写文件顶部的配置变量，包括JIRA_URL、JIRA_EMAIL、JIRA_API_TOKEN、用于筛选服务请求的jql_query，以及上一步查到的CUSTOM_FIELD_IDS。
将Jira状态映射为活动：请仔细检查脚本中的STATUS_ACTIVITY_MAP字典，并更新映射，使其符合您实际使用的Jira Service Management工作流。键应为Jira状态的准确名称（例如“等待客户”），值应为事件日志所需的对应活动名称（例如“请求信息”）。
运行提取脚本：打开终端或命令提示符，进入脚本保存目录，然后运行命令：python jira_extraction_script.py。脚本将连接Jira API、获取问题数据并进行处理，同时在控制台显示进度。
检查输出文件：脚本运行完成后，会在同一目录下生成名为jira_event_log.csv的CSV文件。在电子表格应用程序中打开文件并检查内容，确认所有列均已生成且按预期填充。
准备上传到ProcessMind：确保CSV文件中的列标题与以下要求完全一致：ServiceRequestId、ActivityName、EventTime、SourceSystem、LastDataUpdate、Assignee、RequestPriority、RequestStatus、RequestType和SlaDueDate。现在即可将文件上传到ProcessMind。

配置

Jira身份验证：脚本需要您的Jira域名URL、与Jira账户关联的电子邮件地址，以及用于安全访问的个人API令牌。
JQL查询（jql_query）：这是提取数据的核心筛选条件。请编写准确的JQL查询以筛选正确的问题。建议按project、issuetype和createdDate指定的日期范围筛选，以控制数据量（例如project = 'SERVICEDESK' AND issuetype = 'Service Request' AND createdDate >= '-6m'）。
状态到活动的映射（STATUS_ACTIVITY_MAP）：此字典用于将Jira状态变更正确转换为有意义的流程活动。您必须根据组织实际使用的Jira工作流自定义映射。未列入映射的状态将被忽略。
自定义字段ID（CUSTOM_FIELD_IDS）：要提取“请求类型”或“SLA到期日期”等自定义字段的数据，必须提供其唯一系统ID（例如customfield_10021）。请正确配置这些ID，才能填充相应属性。
日期范围与性能：初次提取建议使用3至6个月的JQL日期范围，以确保性能可控。提取数年的数据可能较慢，因为API需要分页并受速率限制。

查询示例 python

import os
import requests
import pandas as pd
from datetime import datetime, timezone

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
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 = os.environ.get(class="hl-string">"JIRA_API_TOKEN", class="hl-string">"YOUR_JIRA_API_TOKEN") class=class="hl-string">"hl-comment"># Best practice: use environment variables

class=class="hl-string">"hl-comment"># JQL query to fetch service request issues. 
class=class="hl-string">"hl-comment"># Recommended: Filter by project, issuetype, and a date range.
jql_query = class="hl-string">"project = 'SD' AND issuetype = 'Service Request' AND created >= '-6m' ORDER BY created DESC"

class=class="hl-string">"hl-comment"># Map your specific Jira status names to the desired activity names.
class=class="hl-string">"hl-comment"># This is CRITICAL for capturing the correct process flow.
STATUS_ACTIVITY_MAP = {
    class="hl-string">'In Progress': class="hl-string">'Request Triaged',
    class="hl-string">'Waiting for customer': class="hl-string">'Information Requested',
    class="hl-string">'Waiting for support': class="hl-string">'Information Provided',
    class="hl-string">'Waiting for vendor': class="hl-string">'Vendor Engagement Started',
    class="hl-string">'Vendor Responded': class="hl-string">'Vendor Engagement Ended',
    class="hl-string">'Pending Review': class="hl-string">'Solution Implemented',
    class="hl-string">'Pending Customer Acceptance': class="hl-string">'Resolution Proposed',
    class="hl-string">'Reopened': class="hl-string">'Request Reopened',
    class="hl-string">'Resolved': class="hl-string">'Resolution Confirmed', class=class="hl-string">"hl-comment"># Or could be class="hl-string">'Solution Implemented' depending on workflow
    class="hl-string">'Closed': class="hl-string">'Service Request Closed'
}

class=class="hl-string">"hl-comment"># Map desired attributes to their custom field IDs in Jira.
class=class="hl-string">"hl-comment"># Find these IDs in your Jira instance under Settings > Issues > Custom Fields.
CUSTOM_FIELD_IDS = {
    class="hl-string">'RequestType': class="hl-string">'[customfield_10021]', class=class="hl-string">"hl-comment"># Example ID for Request Type
    class="hl-string">'SlaDueDate': class="hl-string">'[customfield_10030]'    class=class="hl-string">"hl-comment"># Example ID for SLA Due Date
}

class=class="hl-string">"hl-comment"># --- SCRIPT LOGIC --- 
def fetch_jira_issues(url, email, token, jql):
    class="hl-string">"""Fetches all issues from Jira matching the JQL query, handling pagination."""
    headers = {
        class="hl-string">"Accept": class="hl-string">"application/json",
        class="hl-string">"Content-Type": class="hl-string">"application/json"
    }
    auth = (email, token)
    
    issues = []
    start_at = 0
    max_results = 50
    total = -1

    print(fclass="hl-string">"Fetching issues from Jira with JQL: {jql}")
    while total == -1 or start_at < total:
        api_url = fclass="hl-string">"{url}/rest/api/3/search"
        params = {
            class="hl-string">'jql': jql,
            class="hl-string">'startAt': start_at,
            class="hl-string">'maxResults': max_results,
            class="hl-string">'expand': class="hl-string">'changelog'
        }
        
        response = requests.get(api_url, headers=headers, params=params, auth=auth)
        response.raise_for_status() class=class="hl-string">"hl-comment"># Exit if there is an error
        data = response.json()
        
        if total == -1:
            total = data[class="hl-string">'total']
            print(fclass="hl-string">"Found {total} total issues to process.")

        page_issues = data.get(class="hl-string">'issues', [])
        issues.extend(page_issues)
        start_at += len(page_issues)
        print(fclass="hl-string">"Fetched {len(issues)} / {total} issues...")

        if len(page_issues) == 0:
            break

    return issues

def process_issues_to_event_log(issues):
    class="hl-string">"""Processes raw issue data into a structured event log."""
    event_log = []
    now_utc = datetime.now(timezone.utc).isoformat()
    source_system = class="hl-string">"Jira Service Management"

    for issue in issues:
        case_id = issue[class="hl-string">'key']
        fields = issue.get(class="hl-string">'fields', {})
        changelog = issue.get(class="hl-string">'changelog', {}).get(class="hl-string">'histories', [])
        
        class=class="hl-string">"hl-comment"># Helper to get nested field values safely
        def get_field_value(field_data, key):
            return field_data.get(key)
        
        def get_custom_field_value(field_data, custom_field_id):
            custom_field = field_data.get(custom_field_id)
            if isinstance(custom_field, dict):
                return custom_field.get(class="hl-string">'value')
            return custom_field

        class=class="hl-string">"hl-comment"># --- Extract common attributes for all events of this case ---
        assignee = get_field_value(fields.get(class="hl-string">'assignee', {}), class="hl-string">'displayName')
        priority = get_field_value(fields.get(class="hl-string">'priority', {}), class="hl-string">'name')
        status = get_field_value(fields.get(class="hl-string">'status', {}), class="hl-string">'name')
        request_type = get_custom_field_value(fields, CUSTOM_FIELD_IDS[class="hl-string">'RequestType'])
        sla_due_date = get_custom_field_value(fields, CUSTOM_FIELD_IDS[class="hl-string">'SlaDueDate'])

        common_attributes = {
            class="hl-string">'ServiceRequestId': case_id,
            class="hl-string">'SourceSystem': source_system,
            class="hl-string">'LastDataUpdate': now_utc,
            class="hl-string">'Assignee': assignee,
            class="hl-string">'RequestPriority': priority,
            class="hl-string">'RequestStatus': status,
            class="hl-string">'RequestType': request_type,
            class="hl-string">'SlaDueDate': sla_due_date
        }

        class=class="hl-string">"hl-comment"># 1. Activity: Service Request Created
        event_log.append({
            **common_attributes,
            class="hl-string">'ActivityName': class="hl-string">'Service Request Created',
            class="hl-string">'EventTime': fields[class="hl-string">'created']
        })

        class=class="hl-string">"hl-comment"># 2. Activity: Service Request Resolved
        if fields.get(class="hl-string">'resolutiondate'):
            event_log.append({
                **common_attributes,
                class="hl-string">'ActivityName': class="hl-string">'Service Request Resolved',
                class="hl-string">'EventTime': fields[class="hl-string">'resolutiondate']
            })

        class=class="hl-string">"hl-comment"># 3. Process changelog for all other activities
        for history in changelog:
            created_time = history[class="hl-string">'created']
            for item in history[class="hl-string">'items']:
                class=class="hl-string">"hl-comment"># Activity: Request Assigned
                if item[class="hl-string">'field'].lower() == class="hl-string">'assignee':
                    event_log.append({
                        **common_attributes,
                        class="hl-string">'ActivityName': class="hl-string">'Request Assigned',
                        class="hl-string">'EventTime': created_time,
                        class="hl-string">'Assignee': item.get(class="hl-string">'toString') class=class="hl-string">"hl-comment"># Use the new assignee for this event
                    })
                
                class=class="hl-string">"hl-comment"># Activities based on status changes
                if item[class="hl-string">'field'].lower() == class="hl-string">'status':
                    to_status = item.get(class="hl-string">'toString')
                    if to_status in STATUS_ACTIVITY_MAP:
                        activity = STATUS_ACTIVITY_MAP[to_status]
                        event_log.append({
                            **common_attributes,
                            class="hl-string">'ActivityName': activity,
                            class="hl-string">'EventTime': created_time,
                            class="hl-string">'RequestStatus': to_status class=class="hl-string">"hl-comment"># Use the new status for this event
                        })

    return event_log

if __name__ == class="hl-string">"__main__":
    try:
        issues_data = fetch_jira_issues(JIRA_URL, JIRA_EMAIL, JIRA_API_TOKEN, jql_query)
        if issues_data:
            event_log_data = process_issues_to_event_log(issues_data)
            df = pd.DataFrame(event_log_data)

            class=class="hl-string">"hl-comment"># Reorder and format columns for final output
            column_order = [
                class="hl-string">'ServiceRequestId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
                class="hl-string">'Assignee', class="hl-string">'RequestPriority', class="hl-string">'RequestStatus', class="hl-string">'RequestType', class="hl-string">'SlaDueDate'
            ]
            df = df[column_order]
            df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime']).dt.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')

            output_filename = class="hl-string">'jira_event_log.csv'
            df.to_csv(output_filename, index=False)
            print(fclass="hl-string">"\nSuccessfully extracted {len(df)} events to {output_filename}")
        else:
            print(class="hl-string">"No issues found for the given JQL query.")

    except requests.exceptions.HTTPError as e:
        print(fclass="hl-string">"HTTP Error: {e.response.status_code} - {e.response.text}")
    except Exception as e:
        print(fclass="hl-string">"An unexpected error occurred: {e}")

准备好开始了吗？

使用此模板开启流程挖掘之旅，推动服务请求管理取得显著改进。立即着手优化运营。

返回改进指南

下载模板

立即优化Jira中的服务请求管理

实现70%的自动化，告别缓慢的请求处理。立即提升效率！

开始免费试用

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

您的服务请求管理数据模板

您的服务请求管理数据模板

服务请求管理属性

服务请求管理活动

数据提取指南

Jira Service Management内置CSV/XML导出

步骤

配置

查询示例 config

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

步骤

配置

查询示例 sql

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

步骤

配置

查询示例 python

准备好开始了吗？

立即优化Jira中的服务请求管理