数据模板:事件管理
您的事件管理数据模板
- 建议收集的属性
- 需要追踪的关键活动
- Jira Service Management数据导出指引
事件管理属性
| 名称 | 描述 | ||
|---|---|---|---|
|
事件ID
IncidentId
|
Jira Service Management 中每个事件工单的唯一标识符。 | ||
|
描述
Incident ID(在Jira中常称为 Issue Key)是每个上报事件的唯一标识。从创建到最终关闭,它串联起所有相关活动、评论与状态变更。在流程挖掘中,该ID用于重建每个事件的端到端生命周期,从而支持对整个流程的全面分析。
为何重要
这是用于将所有相关事件关联为单个案例的核心标识,是开展任何流程挖掘分析的基础。
获取方式
这是Jira Service Management问题的标准“Key”字段(如“ITSM-123”)。
示例
INC-10234HELPDESK-5678OPS-9901
|
|||
|
开始时间
EventTimestamp
|
活动发生的精确日期和时间。 | ||
|
描述
该属性记录事件生命周期中每个活动的时间戳。它是计算各阶段时长、周期时长与等待时间的关键。准确的时间戳支持细致的绩效分析、SLA监控与瓶颈识别。所有绩效指标(如解决时长与诊断耗时)都源自这些时间戳。
为何重要
时间戳是计算各类时间指标、理解流程耗时并发现性能瓶颈的基础。
获取方式
这是与Jira问题变更日志或历史中每条记录关联的“created”日期。
示例
2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
|
|||
|
活动
ActivityName
|
具体活动或状态变更的名称。 | ||
|
描述
“活动”表示事件管理生命周期中的一个具体步骤或事件,例如“Incident Created”、“Incident Assigned”或“Resolution Proposed”。这些通常来源于Jira事项的历史或变更日志中记录的状态流转或特定更新。分析这些活动的顺序与持续时间是流程挖掘的主要目标,可揭示实际流程、瓶颈与偏差。
为何重要
活动构成流程图的骨架,便于可视化并分析事件的全生命周期。
获取方式
源自 Jira 的问题历史与变更日志数据,涵盖状态流转与关键字段更新。
示例
事件已指派调查已开始事件已解决
|
|||
|
最后数据更新
LastDataUpdate
|
用于指示数据上次从源系统刷新的时间戳。 | ||
|
描述
该属性记录数据集的最近更新时间,为分析者提供数据新鲜度的关键信息。对于持续监控的仪表板尤为重要,最新信息关系到及时决策。同一批次的数据抽取中,该值通常对所有事件一致。
为何重要
告知用户数据的时效性,这对分析的相关性与准确性至关重要。
获取方式
这是数据抽取运行的时间戳,在数据转换过程中添加。
示例
2023-10-27T08:00:00Z2023-10-28T08:00:00Z
|
|||
|
源系统
SourceSystem
|
数据提取来源系统。 | ||
|
描述
该属性标识数据来源,此处为Jira Service Management。在需要整合多系统数据以获得端到端流程视图的场景中尤为重要。明确源系统可确保数据血缘清晰,并有助于定位数据质量或抽取过程中的问题。对本模型而言,该值是静态的。
为何重要
提供数据来源的关键信息,确保清晰可追溯,尤其适用于多系统联合分析。
获取方式
这是一个静态值,应在数据抽取过程中添加。
示例
Jira Service ManagementJira Cloud
|
|||
|
优先级
Priority
|
事件的优先级,用于表示处理的紧迫性。 | ||
|
描述
优先级决定事件处理速度,通常由影响度与紧急度共同定义,并直接影响SLA目标。按优先级分析事件,可判断高优先级事件是否确实比低优先级处理更快,以及优先级是否被一致执行。它是过滤和比较流程绩效的关键维度。
为何重要
这对于评估SLA表现,并核实资源是否优先投入最关键的事件,至关重要。
获取方式
Jira事项中的标准 'Priority' 字段。
示例
最高高中低
|
|||
|
分配组
AssignmentGroup
|
负责处理该事件的团队或小组。 | ||
|
描述
Assignment Group(分配组)表示被指派处理该事件的团队,可能是“L1帮助台”等支持层级、“网络运维”等专业团队,或开发团队。分析分配组之间的流转是理解流程升级与交接的关键,可用于衡量团队绩效、定位团队层面的瓶颈,并分析跨团队依赖。
为何重要
对于分析团队绩效、吞吐量,以及不同支持层级或专门小组之间的工作流转至关重要。
获取方式
这通常在Jira中以自定义字段实现,如“Team”或“Assignment Group”。有时也可由Jira Components或Project Roles推导而来。
示例
一线支持基础设施团队数据库管理员
|
|||
|
创建日期
CreatedDate
|
事件在系统中首次创建的日期和时间。 | ||
|
描述
该属性标记事件生命周期的正式起点。它是计算总解决时长等总体指标的基准时间戳。创建日期对每个事件都是固定值,并作为流程挖掘分析中整个案例的起始点。
为何重要
作为所有端到端周期时间计算与 SLA 度量的起点。
获取方式
Jira事项中的标准 'Created' 字段。
示例
2023-10-26T09:58:12Z2023-11-01T15:20:05Z
|
|||
|
受理人
Assignee
|
当前被指派处理该事件的用户。 | ||
|
描述
Assignee(经办人)是在某一时点负责该事件的坐席或用户。跟踪经办人的变更对于分析交接、了解工作量分布,以及识别具体步骤涉及哪些人员至关重要。该属性有助于评估个人绩效并优化支持团队的资源分配。
为何重要
用于跟踪个人工作量,识别与特定坐席相关的瓶颈,并分析交接对解决时长的影响。
获取方式
Jira事项中的标准 'Assignee' 字段。
示例
约翰·史密斯Emily JonesServiceDeskAgent1
|
|||
|
状态
Status
|
事件当前所处阶段。 | ||
|
描述
Status 字段表示事件在既定工作流中的当前状态,如“Open”、“In Progress”、“Pending Customer”或“Resolved”。状态变更是生成流程挖掘活动日志的主要来源。分析各状态的停留时长,是识别瓶颈并了解事件耗时所在的基础。
为何重要
直接反映事件推进情况,是识别流程步骤与等待时间的主要来源。
获取方式
Jira事项中的标准 'Status' 字段。
示例
进行中等待客户已解决已结案
|
|||
|
解决周期
IncidentResolutionCycleTime
|
从事件创建到解决的总耗时。 | ||
|
描述
这是一个计算指标,表示从“CreatedDate”到“ResolutionDate”的时长。它是事件管理中最重要的KPI之一,直接衡量整个流程的效率。按优先级、分派组或组件等维度分析此指标,有助于识别影响绩效的关键因素。
为何重要
直接衡量事件管理流程的端到端效率,是进行绩效跟踪的核心 KPI。
获取方式
计算方式:('ResolutionDate' - 'CreatedDate')。
示例
2h 30m1d 4h5d 1h 15m
|
|||
|
解决日期
ResolutionDate
|
事件被标记为已解决的日期和时间。 | ||
|
描述
该属性记录事件首次进入已解决状态的时间戳。它标志着主动处理阶段的结束,也是计算“Time to Resolution”的终点。将解决日期与创建日期对比,是衡量流程效率的主要方式之一,同时也是评估SLA达标的重要依据。
为何重要
标记解决流程的结束,用于计算整体周期时间和SLA绩效。
获取方式
Jira事项中的标准 'Resolved' 字段。
示例
2023-10-28T11:20:30Z2023-11-02T10:00:00Z
|
|||
|
SLA违约
SlaBreach
|
用于标记事件解决时间是否超出 SLA 目标。 | ||
|
描述
该计算型布尔属性表示事件是否违反了“Time to Resolution”SLA。当“IncidentResolutionCycleTime”大于“TimeToResolutionTarget”时为真。此标记可简化分析与可视化,便于筛选与汇总以计算整体SLA违约率KPI。它是SLA绩效监控仪表板的关键结果指标。
为何重要
为SLA绩效提供明确的二元结果,便于计算违约率并定位问题环节。
获取方式
计算方式:('IncidentResolutionCycleTime' > 'TimeToResolutionTarget')。
示例
truefalse
|
|||
|
严重性
Severity
|
衡量事件对业务影响程度的指标。 | ||
|
描述
严重度用于衡量事件对业务的影响范围,从影响单个用户到关键系统中断不等。Priority决定处理顺序,Severity体现业务影响程度。按严重度分析有助于洞察最关乎业务的事件的流程表现,通常结合Priority进行更细致的分析。
为何重要
呈现业务影响视图,便于聚焦分析对业务运行影响最大的事件。
获取方式
在Jira中通常是自定义字段,非系统标准字段。请查看Jira Service Management的项目配置。
示例
严重重大次要无关紧要
|
|||
|
交接次数
HandoffCount
|
事件被重新指派到不同组或用户的次数。 | ||
|
描述
该计算指标统计事件生命周期内“Assignee”或“AssignmentGroup”字段被更改的次数。交接频繁通常意味着流程低效、一次性解决率偏低或存在知识缺口,导致解决时间延长。分析该KPI有助于精简分派流程并提升团队协作。
为何重要
量化因多次转派造成的流程摩擦与低效,帮助发现可改进的切入点。
获取方式
计算方式:统计问题变更日志中对 'Assignee' 或 'AssignmentGroup' 字段的变更次数。
示例
015
|
|||
|
关联Problem ID
LinkedProblemId
|
与此事件关联的问题单标识符。 | ||
|
描述
当某个事件只是更大潜在问题的外在表现时,通常会关联到一张 Problem 工单。此字段存储该关联 Problem 的ID。分析这些关联有助于理解事件与问题之间的关系,评估问题管理流程的有效性,并识别需要永久修复的重复性事件。
为何重要
将事件与背后的问题相连接,便于分析组织在根因处置上的有效性,从源头预防后续事件。
获取方式
该信息存放于Jira问题的“Issue Links”区域。
示例
PROB-123PROB-456无
|
|||
|
客户请求类型
CustomerRequestType
|
客户通过服务门户提交的具体请求类型。 | ||
|
描述
该字段按客户视角对请求进行分类,展示于Jira Service Management门户(如“报告系统问题”)。它提供面向用户的事件分类,可能与内部的“Issue Type”不同。分析此属性可洞察客户如何感知与上报问题,从而优化门户设计与服务提供。
为何重要
从客户视角展示事件类别,有助于分析需求并提升客户体验。
获取方式
Jira Service Management项目特有的'Customer Request Type'字段。
示例
获取IT帮助 > 报告系统问题邮件 > 访问请求
|
|||
|
报告人
Reporter
|
最初创建或上报该事件的用户。 | ||
|
描述
Reporter(报告人)是最先记录该事件的个人,通常为终端用户或其他系统。按报告人分析事件有助于识别频繁遇到问题的用户或部门;在分析如“Waiting for Customer”、“Customer Responded”等活动时,也可用于洞察沟通模式。
为何重要
用于分析事件来源,识别与特定用户或部门相关的模式,并洞察客户互动中的延迟。
获取方式
Jira事项中的标准 'Reporter' 字段。
示例
爱丽丝·约翰逊鲍勃·威廉姆斯monitoring-tool@example.com
|
|||
|
是否返工
IsRework
|
用于标记事件是否发生返工(例如被重新打开)。 | ||
|
描述
该计算型布尔属性用于识别被打回到前一阶段的事件,最常见的是已解决后被重新打开。返工循环是造成低效和客户不满的重要来源。通过此标记可方便地量化返工率,并聚焦分析为何无法一次性正确解决。
为何重要
标记并定位需返工的事件,直接支撑返工分析,进而揭示流程质量问题与低效环节。
获取方式
计算方式:检测事件日志中的特定状态流转序列,例如 'Resolved' -> 'Reopened'。
示例
truefalse
|
|||
|
根因类别
RootCauseCategory
|
对事件根本原因的分类。 | ||
|
描述
该属性记录事件发生的根本原因,如“Software Defect”、“Hardware Failure”或“User Error”。通常在调查后填写,对有效的问题管理与预防未来事件至关重要。分析根因分类有助于识别系统性薄弱环节并为改进举措设定优先级。若“Unknown”占比偏高,可能意味着需要改进调查流程。
为何重要
支持根因分析,通过识别并处置事件源头,让团队从被动响应走向主动预防。
获取方式
这在Jira中几乎总是自定义字段,其名称与选项高度依赖于组织的具体配置。
示例
配置错误网络中断软件缺陷
|
|||
|
组件
Component
|
受该事件影响的系统、应用或基础设施组件。 | ||
|
描述
组件是 Jira 项目的子模块,用于把问题划分为更小的部分,例如“用户界面”“数据库”“API”。按组件分析事件有助于定位系统中更容易出问题的部分。这些信息对根因分析十分有价值,也能指导服务改进或技术债治理。
为何重要
可按受影响的具体产品或系统区域进行筛选和分析,帮助识别技术热点。
获取方式
Jira事项中的标准 'Components' 字段。
示例
认证服务报表仪表板移动应用
|
|||
|
解决时限目标
TimeToResolutionTarget
|
解决该事件的SLA目标时长。 | ||
|
描述
该属性用于定义特定优先级或类型的事件应在多长时间内解决的预期上限。它是衡量实际解决耗时并判断SLA是否达标的基准。此值通常会依据优先级、严重程度或问题类型等规则动态设定。它是任何SLA绩效监控仪表板的基础要素。
为何重要
作为衡量SLA合规的基准,是“事件SLA违约率”KPI的计算基础。
获取方式
此值来源于Jira Service Management中的SLA配置,需要明确具体目标(如“Time to resolution”)。
示例
4h8h3d
|
|||
|
解决结果
Resolution
|
将事件标记为已解决的最终结果或原因。 | ||
|
描述
“Resolution”字段说明事件为何被转入已解决状态。常见取值包括“Fixed”、“Duplicate”、“Won't Do”或“Cannot Reproduce”。分析解决结果类型的分布,有助于评估来件质量与解决流程的有效性。例如,“Duplicate”占比偏高可能意味着事件创建或分诊阶段存在问题。
为何重要
为事件结果提供背景,便于对解决方案分类,并识别事件关闭方式的趋势。
获取方式
Jira事项中的标准 'Resolution' 字段。该字段通常在事项流转到 'Done' 状态类别时设置。
示例
已完成已修复重复不予修复
|
|||
|
问题类型
IssueType
|
事项类型,如 Incident、Service Request 或 Problem。 | ||
|
描述
Jira使用Issue类型区分不同任务。在事件管理场景中,主要类型是“Incident”,但“Sub-task”等也可能相关。该属性用于过滤出仅包含事件的数据集,确保流程挖掘聚焦于正确的流程。
为何重要
确保分析范围准确聚焦于事件,与服务请求或变更等其他工作类型区分开来。
获取方式
Jira事项中的标准 'Issue Type' 字段。
示例
事件IT帮助Bug
|
|||
事件管理活动
| 活动 | 描述 | ||
|---|---|---|---|
|
事件已关闭
|
表示事件解决并验证后进行的最终行政性关闭。通常由状态流转为'Closed'来推断。 | ||
|
为何重要
这是流程的终止事件。分析“Resolved”与“Closed”之间的时间,可揭示行政收尾或用户确认环节的延迟。
获取方式
基于问题状态变更历史推断:当状态切换至最终的 'Closed' 状态时的时间戳即为该事件。
捕获
识别状态流转至“Closed”的时间戳。
事件类型
inferred
|
|||
|
事件已创建
|
标记事件生命周期的正式开始:提交事件报告并在Jira中创建新Issue。当系统记录到新建“Incident”类型Issue时,会显式捕获该事件。 | ||
|
为何重要
这是流程的主要起始事件。分析从此活动到“解决”的时间,是衡量整体周期时长与SLA达标情况的基础。
获取方式
这是一个显式事件,取自Jira问题的“created”时间戳。问题创建事件会记录在问题历史中。
捕获
使用Issue的创建时间戳。
事件类型
explicit
|
|||
|
事件已解决
|
该活动标记事件已成功解决且服务已恢复,通常与流转到“Resolved”状态同时发生。 | ||
|
为何重要
这是流程中的核心成功里程碑。达到该节点的耗时是最常见的KPI,即Time to Resolution(TTR)。
获取方式
根据状态变更为 'Resolved' 推断。在许多工作流中,此事件与 'Resolution Proposed' 相同,表示关键的解决节点。
捕获
识别状态流转至“Resolved”的时间戳。
事件类型
inferred
|
|||
|
事件已重分派
|
事件在初次分派后,从一位坐席或小组转交到另一方时触发。凡“Assignee”或“Assigned Group”字段发生变化,均可据此推断。 | ||
|
为何重要
跟踪重新分派对交接分析至关重要。高频率的重新分派常常意味着流程低效、存在知识缺口或初始路由不当,从而造成解决延迟。
获取方式
从问题历史中推断:在首次填充后,'Assignee' 字段任何后续更新均记为一次重新分派事件。
捕获
识别初次指派后对“Assignee”字段的后续变更。
事件类型
inferred
|
|||
|
已提出解决方案
|
该活动表明解决方案已确定并实施,事件正等待确认或最终验证。通常可从状态流转到“Resolved”推断。 | ||
|
为何重要
这是一个重要里程碑,标志着支持团队的实际处理工作结束,通常也会在此停止SLA计时。
获取方式
基于问题状态变更历史推断:当状态切换为 'Resolved' 或等效状态时的时间戳即为该事件。
捕获
识别状态流转至“Resolved”的时间戳。
事件类型
inferred
|
|||
|
等待客户
|
标记支持团队正在等待客户提供信息或采取行动的节点。通常由状态流转到专用等待状态(如“Waiting for customer”)推断得出。 | ||
|
为何重要
将这段“挂起”时间单独统计对准确衡量SLA至关重要,因为它通常不计入解决时长。此举有助于分析客户响应延迟。
获取方式
基于问题状态变更历史推断:当状态变为 'Waiting for customer' 或类似状态时的时间戳即为事件时间戳。
捕获
识别状态流转至“Waiting for customer”的时间戳。
事件类型
inferred
|
|||
|
调查已开始
|
表示已指派的处理人员开始实际进行事件诊断。通常在问题状态从 'Open' 或 'New' 变更为 'In Progress' 时据此推断。 | ||
|
为何重要
这一关键里程碑标志着进入主动处理阶段。衡量到达此活动所用的时间,有助于识别初始排队延迟与资源可用性问题。
获取方式
基于问题状态变更历史推断:当状态切换为表示主动处理的状态(如 'In Progress')时的时间戳即为该事件。
捕获
识别状态流转至“In Progress”的时间戳。
事件类型
inferred
|
|||
|
事件已指派
|
该活动表示事件首次被指派给支持人员或团队处理。可通过跟踪 'Assignee' 或 'Assigned Group' 字段首次被填充来识别。 | ||
|
为何重要
衡量首次响应与分派用时,这是SLA指标的关键组成部分,有助于发现进入主动排查前的延迟。
获取方式
从问题历史中推断:识别 'Assignee' 字段前一值为 'Unassigned' 的首次变更。
捕获
检测问题历史中对 'Assignee' 字段的首次更新。
事件类型
inferred
|
|||
|
事件已设定优先级
|
表示对事件优先级和/或严重度的设定,用以界定紧急性与业务影响。通常通过事件创建后首次填写或更新'Priority'或'Severity'字段来推断。 | ||
|
为何重要
跟踪优先级评定有助于判断事件是否得到及时且一致的评估。此步骤的延误会直接影响SLA计算与资源分配。
获取方式
基于问题历史日志(追踪所有字段变更)推断:在问题创建后,查找对 'Priority' 或自定义 'Severity' 字段的首次更新。
捕获
检测问题历史中对 'Priority' 字段的首次变更。
事件类型
inferred
|
|||
|
事件已重新打开
|
表示先前已解决的事件因问题复发或修复无效而被重新激活。通常由状态从'Resolved'或'Closed'变回开放状态推断。 | ||
|
为何重要
被重新打开的事件直接反映解决质量,也是返工的主要信号。分析此类事件有助于识别过早关闭和无效方案。
获取方式
基于问题状态变更历史推断:当状态从 'Resolved' 或 'Closed' 等终止状态回退至 'Open' 或 'In Progress' 时记录该事件。
捕获
检测状态从 'Resolved' 或 'Closed' 变为开放状态。
事件类型
inferred
|
|||
|
升级至专家团队
|
表示事件已升级至专业团队(如二线、研发)进行高级支持。通常通过自定义'Support Team'字段的变更或特定转派来推断。 | ||
|
为何重要
标记需要专业知识的事件,并跟踪不同支持层级之间的流转,帮助识别专家团队内的瓶颈并分析升级模式。
获取方式
从问题历史中推断:通过跟踪代表负责团队的自定义字段变更,或识别 'Assignee' 变更为已知专家组成员。
捕获
检测自定义字段 'Assigned Team' 的变更,或检测特定经办人的变更。
事件类型
inferred
|
|||
|
客户已回复
|
表示客户已提供所需信息,事件可继续处理。通常在问题状态从 'Waiting for customer' 切换回活动状态时据此推断。 | ||
|
为何重要
该活动表示由客户导致的等待已结束。分析从“Waiting For Customer”到该事件的时长,可衡量客户的平均响应时间。
获取方式
基于问题状态变更历史推断:当状态从 'Waiting for customer' 切换为 'In Progress' 等活动状态时发生,通常由客户添加评论所触发。
捕获
检测状态从 'Waiting for customer' 变为 'In Progress'。
事件类型
inferred
|
|||
|
已关联到Problem工单
|
当事件为开展根因分析而关联到“Problem”类型Issue时触发。创建指向“Problem”类型Issue的“relates to”或“caused by”链接时,会显式记录该事件。 | ||
|
为何重要
跟踪该链接对于评估组织从事件缓解过渡到根因分析与预防的有效性至关重要。
获取方式
这是一个显式事件,记录在问题的链接历史中。每次创建链接都会带有时间戳,可筛选出指向“Problem”问题类型的链接。
捕获
使用创建指向“Problem”问题类型的Issue链接时的时间戳。
事件类型
explicit
|
|||
|
已提供临时方案
|
表示在制定永久解决方案期间,为恢复服务而实施的临时修复。可通过状态变化或特定评论推断。 | ||
|
为何重要
衡量提供临时解决方案所需时间,是评估服务恢复速度的关键指标,可区分临时缓解与永久修复。
获取方式
这通常需要推断。可能体现为状态流转到“Workaround Provided”,或新增一条包含“workaround”等关键词的公开评论。
捕获
识别特定的状态流转,或在评论中定位关键词。
事件类型
inferred
|
|||
|
已添加评论
|
表示用户在事件工单中添加评论的任何沟通或记录行为。每次发表评论都会显式记录为一次事件。 | ||
|
为何重要
分析评论频次可洞察沟通模式、协作效率和事件复杂度,并能找出沟通过度的事件。
获取方式
这是一个显式事件。Jira会为每条评论保存时间戳与作者,可通过问题的评论历史或API获取。
捕获
使用该Issue中每条评论的时间戳。
事件类型
explicit
|
|||