> 持续流程改进 > 服务请求管理 > 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中通常称为Issue Key，用于唯一标识用户或系统提交的每个服务请求。它是连接后续所有事件的主线，从最初记录到最终关闭，支持对每个服务请求的完整端到端历程进行分析。在流程挖掘中，该ID对于案例关联至关重要。它确保每项活动、状态变更和时间戳都与所属的具体请求正确关联，从而形成可供分析的完整流程实例。为什么重要该ID是连接所有相关活动的基础案例标识符，可将这些活动串联成单一的端到端流程，使流程分析成为可能。获取位置这是Jira Service Management中问题的“key”字段。示例 SR-2023-001IT-45892HELP-105
	活动 ActivityName	服务请求生命周期中发生的具体事件或任务名称。
说明此属性描述服务请求在某个时间点发生的具体操作或状态转换。例如：“请求已创建”“请求已分配”“解决方案已实施”和“请求已关闭”。分析这些活动的顺序和频率是流程挖掘的核心。通过分析可以可视化流程图、识别瓶颈，并发现偏离标准工作流的情况，这对于了解流程效率和合规性至关重要。为什么重要它定义流程中的步骤，支持流程图可视化，以及对工作流模式和偏差进行分析。获取位置通常来自Jira问题的“status”转换历史。问题变更日志中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期限内。
说明 SLA状态是一个计算属性，根据服务请求相对于SLA期限的绩效对其进行分类。可能的值包括“已达成”“已违约”或“处理中”。该属性通过将解决时间戳与“SlaDueDate”进行比较确定。这是“服务请求SLA绩效”仪表板的核心属性，也用于计算“SLA达成率”KPI。它可以直观呈现服务级别合规情况，对于报告、合同管理和保持服务质量至关重要。为什么重要提供清晰、即时的SLA绩效指标，是衡量服务质量和合同合规性的关键依据。获取位置在数据转换过程中计算。如果解决时间早于“SlaDueDate”，状态为“已达成”；否则为“已违约”。示例已满足已超出SLA处理中
	受派团队 AssignedTeam	负责处理服务请求的团队或群组。
说明此属性指定负责处理请求的团队，通常比单个受派人具有更高层级的归属关系。它支持团队层面的绩效分析，例如比较一线支持团队与网络运营团队。该维度对于“代理人工作负载和解决指标”等仪表板至关重要。它支持在团队层面汇总绩效指标，促进公平比较，并了解不同团队对整体服务交付流程的贡献。为什么重要支持在团队或部门层面分析绩效和平衡工作负载，而不仅仅是按单个代理人分析。获取位置可能是Jira中的自定义字段，例如“Team”，也可能根据受派人的用户档案属性推导得出。示例 IT支持，一线基础设施团队应用支持
	报告人 Reporter	最初创建或报告服务请求的用户。
说明报告人是提交服务请求的人员，通常为最终用户或客户。该属性用于标识发起流程的相关方。在分析中，可以利用报告人了解不同用户、部门或客户群体的请求模式，回答“哪些部门提交的请求最多？”或“是否有特定用户反复遇到相同问题？”等问题。这些信息有助于主动开展问题管理并改进用户培训。为什么重要标识请求发起人，支持按用户、部门或客户分析请求量和请求类型。获取位置对应Jira问题中的“reporter”字段。示例 Charles DarwinMarie CurieIsaac Newton
	是否重新打开 IsReopened	用于表示服务请求在解决后是否重新打开的布尔标记。
说明此计算属性是一个true/false标记。当请求的工作流包含“请求已重新打开”活动时，该标记设为true。它通过分析每个案例的活动顺序得出。该标记对于计算“服务请求重新打开率”KPI和驱动“重新打开的服务请求量”仪表板至关重要。较高的重新打开率通常表明首次解决质量较差，导致返工并降低客户满意度。分析与该标记相关的请求类型或解决结果，可以定位改进方向。为什么重要直接衡量返工情况和首次解决质量，是评估流程有效性与客户满意度的关键指标。获取位置在数据转换过程中计算：检查案例的活动序列中是否存在“已解决”转换之后的“重新打开”转换。示例 truefalse
	渠道 Channel	创建服务请求时使用的提交方式，例如电子邮件、门户或API。
说明渠道属性用于标识服务请求进入系统的方式。Jira Service Management中的常见渠道包括客户门户、电子邮件，或代理人直接创建。按渠道分析流程，有助于了解用户行为并优化服务交付。分析可以揭示某些渠道提交的请求是否需要更长时间解决或更多澄清，从而提示改进门户表单或优化电子邮件解析规则。这也支持“服务请求吞吐趋势”仪表板。为什么重要帮助分析提交渠道是否会影响解决时长、请求清晰度或整体流程效率。获取位置 Jira Service Management通过“Request channel type”字段提供此信息。可能需要特定的API访问权限，或该信息存储在自定义字段中。示例门户电子邮件API
	组织 Organization	报告人所属的客户组织或内部部门。
说明此属性将报告人归入组织或部门。Jira Service Management内置“Organizations”功能，支持代理人管理来自多个客户或内部团队的请求。按组织分析可以提供有价值的业务背景，帮助识别哪些客户或部门消耗的支持资源最多、哪些群体反复遇到问题，以及不同业务单元是否持续达到SLA。为什么重要支持按客户或内部部门分析服务需求和绩效，提供关键业务洞察。获取位置该数据来自Jira Service Management中与服务请求关联的“Organizations”字段。示例 Acme Corporation财务部门Global Tech Inc.
	解决结果 Resolution	已解决服务请求的最终结果或结论。
说明 Resolution字段说明服务请求关闭的原因。常见值包括“完成”“不予处理”“重复”或“无法复现”。相比“已解决”或“已关闭”状态，它提供了更具体的关闭信息。分析解决结果有助于了解结果的质量和性质。例如，大量“重复”结果可能表明请求提交流程存在问题；跟踪哪些解决结果会导致请求重新打开，则有助于发现无效解决方案。为什么重要提供请求结果的背景信息，帮助分析解决质量，并识别请求关闭原因的趋势。获取位置对应Jira问题中的“resolution”字段，通常在问题转换到“done”状态类别时设置。示例已完成不处理重复已修复

必需建议可选

服务请求管理活动

以下是需要记录在事件日志中的关键流程步骤和里程碑，用于准确发现和优化流程。

5 建议 8 可选

	活动	说明
	已提出解决方案	在许多服务台工作流中，这是向请求方提供解决方案并等待其批准的独立步骤。通常可根据问题状态变更为“Pending Customer Acceptance”或“Awaiting Confirmation”等状态进行推断。
为什么重要此活动单独记录提供解决方案后等待客户反馈的时间，有助于将其与内部工作时间区分开来。获取位置从问题历史中推断，记录状态变更为表示等待客户验证解决方案的状态时的时间戳。采集识别状态变更为“Pending Customer Acceptance”或等效状态的时间戳。事件类型 inferred
	服务请求已关闭	表示服务请求最终完成管理性关闭，通常在“Resolved”状态保持一段时间后自动发生。这是问题在Jira中的生命周期终点。
为什么重要这是流程的最终结束事件。分析“Resolved”到“Closed”之间的时间，可以了解管理开销或自动关闭政策的影响。获取位置从问题历史中推断。时间戳对应最终变更为“Closed”或等效终止状态的时间。采集识别最终变更为“Closed”状态的时间戳。事件类型 inferred
	服务请求已创建	此活动标志着服务请求生命周期的开始，即用户通过门户、电子邮件或其他渠道正式提交请求。在Jira中，当创建新的“Service Request”类型问题时，系统会明确记录这一事件及其创建时间戳。
为什么重要这是流程的主要开始事件，对于计算整体周期时间以及了解请求量和到达模式至关重要。获取位置这是问题历史表中明确记录的事件。活动时间戳取自Jira问题的“created”字段。采集使用“issues”表或历史记录中的问题创建时间戳。事件类型 explicit
	服务请求已解决	标志着请求被视为已完成且解决方案已记录的正式时间点。当问题首次进入“Done”类别状态时，Jira会填充“Resolution Date”字段。
为什么重要这是流程的主要结束里程碑，对于计算解决时间和SLA达成率至关重要，标志着主动处理阶段结束。获取位置这是一个明确记录的事件。时间戳取自Jira问题的“Resolution Date”字段，该字段在首次转入“Done”类别状态时设置。采集使用Jira问题中的“resolutiondate”字段。该字段会自动填充。事件类型 explicit
	请求已分配	当服务请求被分配给特定代理或团队进行解决时，此活动随之发生。Jira会明确跟踪“Assignee”字段的变更，并提供分配发生的清晰时间戳。
为什么重要这是衡量分诊到分配耗时和代理工作量分布的重要里程碑，标志着请求从排队转入主动处理。获取位置从问题历史中获取，查找“Assignee”字段首次被设置，或从未分配状态发生变更的记录。采集使用问题历史中首次变更“Assignee”字段的时间戳。事件类型 explicit
	已开始供应商协作	表示服务请求已升级至外部供应商或第三方，或需要其采取行动。通常可根据问题转为“Waiting for vendor”或“With Third Party”等状态进行推断。
为什么重要跟踪供应商协作对于识别内部服务台无法直接控制的外部依赖和延迟至关重要。获取位置从问题历史中推断。时间戳对应问题状态变更为指定“vendor”状态的时间。采集识别“status”字段变更为“Waiting for Vendor”等值时的时间戳。事件类型 inferred
	已提供信息	当请求方回复所需信息，使代理能够恢复工作时，此活动发生。通常可根据问题离开“Waiting for customer”状态进行推断，常见触发方式是请求方添加评论。
为什么重要此活动完成与客户之间的请求和响应循环。从请求信息到收到信息之间的时间，是流程等待时间的重要组成部分。获取位置从问题历史中推断。时间戳对应问题状态从“Waiting for customer”变回“In Progress”状态的时间。采集识别“status”字段从“waiting”状态变回“active”状态时的时间戳。事件类型 inferred
	已确认解决方案	当请求方正式接受所提解决方案时发生，通常会自动触发状态变更为“Resolved”。该事件通常根据这一状态变更进行推断。
为什么重要这一里程碑验证解决方案的有效性，并触发SLA计时停止，有助于衡量客户确认修复所需的时间。获取位置从问题历史中推断。时间戳对应状态从“Pending Customer Acceptance”变更为“Resolved”或“Closed”的时间。采集识别状态从“Pending Customer Acceptance”变更为“Resolved”或“Closed”状态的时间戳。事件类型 inferred
	已结束供应商协作	表示外部供应商完成操作，服务请求返回内部团队的时刻。通常可根据问题离开“Waiting for vendor”状态进行推断。
为什么重要衡量供应商协作时长有助于管理供应商绩效，并了解外部参与方对整体解决周期的影响。获取位置从问题历史中推断。时间戳对应问题状态从“vendor”状态变回“In Progress”状态的时间。采集识别“status”字段从“vendor”状态变回“active”状态时的时间戳。事件类型 inferred
	已请求信息	表示代理需要请求方提供更多信息才能继续解决请求的时点。通常可根据问题转为“Waiting for customer”或“Pending Input”等状态进行推断。
为什么重要频繁或持续时间较长的“Information Requested”循环，可能表明初始提交信息不清晰或沟通效率低下，是延迟的重要来源。获取位置从问题历史中推断。时间戳对应问题状态变更为“Waiting for customer”或等效状态的时间。采集识别“status”字段变更为表示流程正在等待客户的值时的时间戳。事件类型 inferred
	解决方案已实施	表示代理已采取必要措施或制定解决方案，以处理服务请求。通常可根据状态变更为“Pending Review”或直接变为“Resolved”进行推断。
为什么重要这一里程碑标志着核心解决工作完成。到达此活动之前的时间，通常代表流程中创造主要价值的阶段。获取位置从问题历史中推断，对应状态变更为“Resolved”、“Pending Acceptance”或类似关闭前状态的时间戳。采集识别“status”字段变更为表示工作已完成的值时的时间戳。事件类型 inferred
	请求已分诊	表示对服务请求进行初步评估，并确定其优先级、类别和影响。该活动通常根据状态变更推断，例如从“New”变为“In Progress”，或变为专门的“Triaged”状态。
为什么重要分析分诊耗时有助于评估请求初始处理流程的效率。此处的延迟可能显著影响整体解决周期和SLA达成率。获取位置通过识别从初始“New”或“Open”状态变为“In Progress”等活动状态的首次时间戳，从问题历史中推断。采集根据项目工作流，识别从“New”或等效初始状态发生的首次状态变更。事件类型 inferred
	请求已重新打开	记录此前已解决的服务请求重新回到活动状态的情况。通常可根据状态从已解决或已关闭状态变回打开或处理中状态进行推断。
为什么重要跟踪重新打开的请求对于衡量解决质量和首次解决率至关重要。较高的重新打开率表明解决方案无效或问题反复出现。获取位置从问题历史中识别状态从“Resolved”或“Closed”类别变为“Open”或“In Progress”类别的转换进行推断。采集查找状态从“Done”类别变为“To Do”或“In Progress”类别的变更。事件类型 inferred

建议可选

提取指南

如何从Jira Service Management获取数据

步骤

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

配置

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

a 示例查询 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 ('[Your Request Type Field Name]', '[Your SLA Field Name]');。记录这些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 ('[Your Project Key]')：这是最重要的筛选器，将数据限制在一个或多个指定的Jira Service Management项目中。
- it.pname = '[Your Service Request Issue Type]'：确保只提取服务请求，而不是事件、问题或其他问题类型。
- i.created >= '[YYYY-MM-DD]'：设置提取的开始日期。首次分析建议使用最近3到6个月的范围。
工作流状态映射：事件日志的准确性完全取决于查询中Jira状态名称的正确映射。您必须将[Status for Triage]、[Waiting for Customer Status]和[Resolved Status]等占位符替换为具体工作流中使用的名称。
性能注意事项：直接对大型且活跃的Jira数据库执行查询可能消耗大量资源，并影响用户的应用性能。强烈建议在只读副本数据库上或业务低峰期执行提取。

a 示例查询 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账户。进入个人资料设置，选择'Account settings'，然后打开'Security'选项卡并创建API令牌。安全复制该令牌，因为它将用于身份验证。
查找自定义字段ID：'Request Type'或'SLA Due Date'等许多Jira属性都是自定义字段。要查找其ID，请进入'Settings' > 'Issues' > 'Custom fields'。搜索所需字段，点击三个点'...' > 'View field information'。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状态的准确名称，例如'Waiting for customer'；值应为事件日志所需的对应活动名称，例如'Information Requested'。
执行提取脚本：打开终端或命令提示符，进入脚本保存目录，并运行命令：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）：要提取“Request Type”或“SLA Due Date”等自定义字段的数据，必须提供其唯一系统ID，例如customfield_10021。必须正确配置这些ID，才能填充相应属性。
日期范围和性能：首次提取建议使用3到6个月的JQL日期范围，以确保性能可控。由于API分页和速率限制，提取数年的数据可能较慢。

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

步骤

配置

a 示例查询 config

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

步骤

配置

a 示例查询 sql

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

步骤

配置

a 示例查询 python

准备开始了吗？

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

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

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

服务请求管理属性

服务请求管理活动

提取指南

Jira Service Management内置CSV/XML导出

步骤

配置

a 示例查询 config

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

步骤

配置

a 示例查询 sql

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

步骤

配置

a 示例查询 python

准备开始了吗？

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

我们重视您的隐私