您的事件管理数据模板

事件ID是系统中用于区分不同事件的唯一字母数字代码。新事件创建时生成，在事件被永久归档或删除前保持不变。

在流程挖掘中，事件ID是分析的基础，充当Case ID。它可以将所有相关事件、状态变化和活动串联为一个完整的流程实例。将所有事件归入同一事件ID后，分析人员便能准确绘制每个事件从首次报告到最终解决和关闭的端到端历程。

它对于关联所有相关活动和事件至关重要，可用于重建事件的端到端生命周期并开展流程挖掘。

这是事件的主键，通常位于每个事件表或对象的表头或主记录中。

事件时间戳标记活动发生的准确时刻。事件生命周期中的每项活动都应有对应时间戳，以建立事件的时间顺序。

该属性是所有基于时间的流程挖掘分析的关键。它支持计算活动之间的周期时间、特定步骤的持续时间以及事件的整体解决时间。通过分析时间戳，组织可以识别瓶颈、衡量SLA遵循情况，并了解流程绩效如何随时间变化。它也是计算平均解决时间等关键绩效指标的基础。

它提供事件的时间顺序，对于计算持续时间、识别瓶颈和分析流程绩效随时间的变化至关重要。

可在事件日志、审计历史表中找到，也可能作为相关记录中的“最后修改时间”或“创建日期”存在。

活动名称描述事件管理流程中的一个独立步骤或任务。这些活动构成流程图的基本节点，既可以是“SLA违规已检测到”等自动化系统事件，也可以是“已分配代理”或“已提供临时替代方案”等手动用户操作。

对于流程挖掘分析，该属性至关重要。它定义流程图中的节点，使分析人员能够可视化工作流、识别常见路径、发现瓶颈，并分析偏离标准流程的情况。活动名称的粒度和清晰度会直接影响所得洞察的质量和深度。

此属性定义流程中的步骤，从而支持事件生命周期流转的可视化与分析。

通常由事件日志、审计轨迹、状态变更记录或事件管理系统中的任务描述字段组合生成。

最后数据更新时间戳表示数据最近一次从源系统提取或同步的时间。这是一个元数据字段，用于反映待分析数据的新鲜度。

在流程挖掘分析中，该属性有助于了解所生成洞察的时效性。它可以帮助用户判断当前查看的是实时信息，还是此前某个时间点的快照。这一背景对于运营监控以及确保决策基于当前有效数据非常重要。

它反映数据的新鲜度，帮助分析人员了解当前流程分析所依据的数据是否最新。

通常在数据提取和转换（ETL）过程中生成，并写入每条记录。

源系统属性用于标识数据来源。在包含多个ITSM工具或集成系统的环境中，该字段有助于区分来自不同来源的记录。

虽然该属性不会直接用于绘制流程图，但对数据验证和治理非常有价值。它帮助分析人员追溯数据来源、了解系统间可能存在的差异，并对分析进行分组。例如，可以在同一组织内比较ServiceNow和Jira中实施的事件管理流程。

它提供数据来源的背景信息，对于多系统环境中的数据验证、问题排查和对比分析至关重要。

通常是在数据提取过程中添加的静态值，或源系统表中已有的字段。

严重性定义事件对业务造成的影响程度，回答问题的严重程度，而不考虑其紧急性。例如，全系统中断属于高严重性事件，而轻微的界面显示缺陷属于低严重性事件。

按严重性分析事件，有助于组织了解哪些类型的问题造成的干扰最大。流程挖掘可以揭示高严重性事件是否遵循不同且更精简的解决路径。该属性对于根因分析以及为主动问题管理分配资源至关重要，有助于防止最严重的事件再次发生。

它有助于对事件进行分组，了解高影响问题是否采用不同方式解决，或是否比低影响问题解决得更高效。

事件记录中的标准字段，通常与紧急程度结合使用以确定优先级。

事件状态表示事件在特定时间点所处的阶段，提供事件解决进度的概览。常见状态包括新建、已分配、处理中、待处理、已解决和已关闭。

该属性是流程分析的基础，因为状态变化通常定义了流程图中的活动。分析每种状态下的停留时间，有助于识别瓶颈，例如事件在“待处理”状态下长时间等待。它还用于计算未关闭事件的积压量，并跟踪解决进度。

它是了解事件进展的关键，通常用于生成流程图中的活动。分析各状态下的停留时间，有助于定位延迟。

通常可在主事件记录的主要字段或事件历史日志中找到。

事件类别提供了根据事件性质进行结构化分类的方式。它通常是层级字段，支持逐级细化分类，帮助将事件整理到逻辑清晰的分组中，以便报告和分析。

分类对于根因分析和趋势分析非常重要。通过按类别筛选流程图，组织可以识别与特定事件类型相关的重复问题和模式。例如，“软件”事件的解决流程可能与“硬件”事件大不相同。这些数据可用于支持初始分类准确率和重复事件率等KPI。

它对于根因分析、识别重复事件趋势以及了解不同类型问题的处理方式至关重要。

这是事件记录中用于分类的一组标准字段，通常为必填项。

优先级是确定事件相对重要性和所需响应速度的关键属性，通常根据事件的影响和紧急程度综合得出。级别一般从严重到低分布。

在流程挖掘中，按优先级分析事件，可以更深入地了解流程如何处理不同紧急程度的事件。分析人员可以比较高优先级和低优先级事件的解决时间，检查SLA是否达标以及资源分配是否有效。这有助于回答“最严重的事件是否确实得到了最快处理”等问题。

它支持按不同紧急程度分析流程绩效，帮助验证严重事件是否比非严重事件处理得更快。

可作为主事件记录中的标准字段使用，也可以由系统根据影响和紧急程度自动计算，或由人工设置。

分配代理用于标识负责某个事件的具体人员。分配组代表团队，而代理则是实际负责解决问题的个人。

该属性支持更细粒度的绩效和工作负载分析。通过跟踪代理级别的分配，管理人员可以评估个人生产力、识别培训需求，并确保工作分配均衡。在流程挖掘中，它还可以揭示组级别分析可能隐藏的复杂重新分配模式，帮助了解个人对解决时间的影响。

它支持详细分析团队内部或团队之间的个人工作负载、绩效和重新分配模式。

该字段位于主事件记录中，在代理接手或被分配处理事件时更新。

分配组表示在任一时间点负责事件的团队。事件通常会在不同组之间流转，例如一级服务台、二级网络团队或三级应用支持团队。

该属性对于交接和工作负载分析至关重要。流程挖掘可以利用这些数据可视化事件在团队之间的流转，衡量事件在各团队队列中的停留时间，并识别频繁重新分配造成的瓶颈。它有助于分析团队效率、协作情况以及工作负载分布，并为交接与重新分配分析仪表板提供基础。

它对于分析团队间交接、衡量队列等待时间以及了解团队绩效和工作负载分布至关重要。

该信息通常存储在事件记录中，每次事件分配给新团队时都会更新。

报告渠道表示事件提交的来源。该属性记录用户与支持职能的交互方式，包括电话等直接联系渠道，以及系统监控告警等自动化方式。

按报告渠道分析流程，可以发现效率方面的重要差异。例如，通过自助服务门户报告的事件可能解决得更快，因为提交时通常包含更结构化的信息。这类分析有助于组织优化支持渠道，并推动用户采用更高效的方式。

它支持根据事件来源分析效率和解决路径，为渠道策略和资源分配提供依据。

该信息通常由系统自动记录，或由代理在创建事件时选择。

解决方法描述事件的结果及其解决方式，可以是标准化代码，也可以是对所采取措施的自由文本描述。例如“用户指导”“已应用软件补丁”“未发现故障”或“重复事件”。

该属性为流程末端提供了重要背景。在流程挖掘中，按解决方法分析事件，有助于了解不同解决方案的有效性。它可以突出没有真正修复就关闭的案例，或识别特定事件类别的常见解决模式，进而用于构建知识库并提高首次联系解决率。

它揭示问题的解决方式，对于发现自动化、知识库改进和培训机会至关重要。

通常由支持代理在将事件状态改为“已解决”或“已关闭”时填写。

SLA状态用于概览事件相对于预定义时间目标的表现，例如响应时间或解决时间。常见状态包括“处理中”、“有风险”和“已违反”。

该属性可直接衡量服务质量，也是SLA绩效概览仪表板的重要输入。在流程挖掘中，您可以比较已违反SLA与未违反SLA事件的流程。这样有助于识别导致SLA失败的具体活动、延迟或返工循环，从而开展有针对性的流程改进。

它直接衡量绩效是否达到目标。分析已超标事件，有助于定位导致服务交付质量不佳的流程问题。

通常是ITSM工具中的计算字段，根据事件的优先级、持续时间和定义的SLA规则动态更新。

受影响的服务将事件关联到IT基础设施中的特定组件，例如业务应用、服务器或网络设备，通常与配置管理数据库（CMDB）关联。

该属性为事件提供关键的业务背景。在流程挖掘中，它支持针对特定服务或资产可靠性的分析。组织可以识别产生事件最多的服务，分析其解决流程，并优先开展问题管理，以提升关键业务服务的稳定性。这是了解IT事件更广泛业务影响的重要元素。

它将事件关联到具体业务服务或IT组件，从而分析哪些服务最容易出现问题及其影响。

通常从配置管理数据库（CMDB）关联，或在事件表单的服务目录列表中选择。

请求人是遇到问题并发起事件报告的人员，可以是内部员工或外部客户。该属性还可以记录请求人的部门或组织。

按请求人或请求人部门分析事件，有助于识别某些用户群体是否比其他群体遇到更多问题，从而发现培训需求或局部环境问题。在流程挖掘中，它支持以用户为中心分析支持流程，帮助了解不同用户群体的体验。

它支持以用户为中心的分析，帮助识别某些用户、部门或地点是否产生了比例过高的事件。

事件记录中的标准字段，通常填入创建工单的用户，或代表其创建工单的用户。

重新分配次数用于跟踪事件在生命周期内经历的交接次数。次数较多通常表明效率低下、初始路由不准确或支持团队知识不足。

这是流程挖掘分析中的重要属性。流程挖掘可以可视化重新分配过程，而预先计算的次数则便于筛选和衡量KPI。该指标直接用于交接与重新分配分析仪表板，并有助于识别工单在团队之间来回传递的“乒乓”场景，这会延长解决时间并降低用户满意度。

该指标直接量化流程低效程度。次数较多通常与较长的解决时间相关，也表明路由或团队能力存在问题。

通常作为事件记录中的标准计数器字段提供。如果没有该字段，也可以通过统计事件审计日志中的分配变更次数得出。