数据模板：事件管理

事件ID是区分系统中各个事件的唯一字母数字编码。它在新建事件时生成，并在该事件被永久归档或删除之前始终保持不变。

在流程挖掘中，事件ID是分析的基石，同时充当案例ID。借助它，系统可以将所有相关的事件、状态变更与活动串联为一个完整的流程实例。将所有事件记录归集到同一事件ID下，分析人员即可准确还原每个事件从首次上报到最终解决与关闭的端到端历程。

用于串联所有相关活动与事件，重建端到端的事件生命周期，是开展流程挖掘的基础。

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

事件时间戳用于标记某个活动发生的精确时刻。事件生命周期中的每个活动都应有对应的时间戳，以便建立按时间排序的事件序列。

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

提供事件的时间序列，是计算时长、识别瓶颈与开展时序绩效分析的关键。

可在事件日志、审计历史表或相关记录上的'last modified'或'creation date'字段中找到。

活动名称用于描述事件管理流程中的具体步骤或任务。这些活动构成流程图的基本单元，既可以是自动化系统事件（如 'SLA Breach Detected'），也可以是人工操作（如 'Agent Assigned'、'Workaround Provided'）。

在流程挖掘分析中，该属性是基础。它定义流程图中的节点，便于直观呈现工作流、识别常见路径、发现瓶颈并分析与标准流程的偏差。活动命名的清晰度与颗粒度，直接影响洞察的质量与深度。

该属性用于定义流程步骤，支持可视化并分析事件生命周期的流转情况。

通常由事件日志、审计轨迹、状态变更记录或任务描述字段等多种来源综合得出。

“最后数据更新”时间用于指示最近一次从源系统抽取或同步数据的时刻。这是反映所分析数据新鲜度的元数据字段。

在流程挖掘分析中，该属性对于理解洞察的时效性很重要。它能帮助用户判断自己看到的是接近实时的信息，还是某个历史时点的快照。这一背景对于运营监控以及基于最新、相关数据做决策至关重要。

指示数据的新鲜度，确保分析人员了解当前分析的时效性。

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

“来源系统”属性用于标识数据的出处。在同时使用多套ITSM工具或存在系统集成的环境中，该字段可区分不同来源的记录。

虽然不会直接用于绘制流程图，但对数据校验与治理非常关键。它帮助分析师回溯数据来源、理解跨系统的潜在差异，并进行分组分析。例如，可在同一组织内对比ServiceNow与Jira上实施的事件管理流程。

提供数据来源的上下文信息，在多系统环境中的数据校验、故障排查与对比分析中至关重要。

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

上报渠道表示事件提交的来源。该属性用于追踪用户如何与支持团队交互，无论是通过电话等直接方式，还是通过系统监控告警等自动方式。

基于上报渠道分析流程可揭示重要的效率差异。例如，经自助门户上报的事件通常包含更结构化的信息，因此可能更快被解决。这类分析有助于优化支持渠道，并引导用户采用更高效的方式。

按来源分析事件的处理效率与解决路径，为渠道策略与资源配置提供参考。

该信息通常在创建事件时自动采集，或由处理人手动选择。

严重性用于衡量事件对业务的影响程度，独立于紧急性回答“问题有多严重”。例如，全系统宕机属于高严重性，而轻微的界面瑕疵则为低严重性。

按严重性分析事件，有助于识别最具破坏性的类型。流程挖掘还能揭示高严重性事件是否走了更精简的解决路径。该属性对根因分析至关重要，也能帮助优先配置资源，开展前瞻性问题管理，避免最严重的事件反复出现。

有助于对事件分层，判断高影响问题是否比低影响问题采用了不同或更高效的解决方式。

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

事件状态用于表示事件在特定时间点所处的阶段，提供其解决进度的整体视图。常见状态包括：新建、已分配、处理中、挂起、已解决、已关闭。

此属性是流程分析的基础，因为状态变化往往定义了流程图中的活动。分析各状态的停留时间可识别瓶颈，例如长期处于“挂起”状态的事件。此外，它也用于计算未结事件积压量并跟踪解决进度。

这是理解事件进展的关键字段，常用于生成流程图中的活动。分析各状态的停留时长有助于定位延误。

通常作为主事件记录的核心字段提供，或记录在事件历史日志中。

事件类别提供一种基于问题性质对事件进行结构化分类的方式。该字段通常为层级结构，支持逐步细化，便于将事件归入逻辑清晰的分组用于报表与分析。

分类对根因分析与趋势分析至关重要。按类别筛选并查看流程图，组织可以识别特定类型事件的重复问题与共性模式。例如，“软件”类事件的解决流程可能与“硬件”类截然不同。这些数据支撑“初始分类准确率”“重复事件率”等KPI的计算。

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

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

优先级是衡量事件相对重要性与响应速度的关键属性，通常由影响度与紧急度综合评定，级别一般从关键到低。

在流程挖掘中，按优先级分析事件有助于理解流程如何应对不同紧急程度。分析师可比较高优先级与低优先级事件的解决时长，检验SLA是否达标、资源分配是否有效，也能回答“我们是否真的把最关键的事件处理得最快？”

支持按不同紧急程度分析流程绩效，验证关键事件是否比非关键事件处理更快。

主事件记录中的标准字段，可手动设置，或根据影响度与紧急度自动计算。

Assigned Agent用于标识负责该事件的具体人员。与指向团队的Assigned Group不同，agent是实际执行解决工作的个人。

该属性支持更细粒度的绩效与工作量分析。按人员维度跟踪指派，管理者可评估个人产能、识别培训需求并均衡分工。在流程挖掘中，它还能揭示在组级别容易被忽视的复杂转派模式，并帮助理解个人对解决时长的贡献。

支持对个人工作量、绩效以及团队内外的重新指派模式进行细致分析。

位于主事件记录中，当处理人接手或被指派该事件时，该字段会更新。

分配组用于标明在任何时刻由哪个团队负责该事件。事件常在不同分配组之间流转，例如一级服务台、二级网络团队或三级应用支持团队。

此属性对交接与工作负载分析至关重要。流程挖掘可用这些数据可视化事件在团队间的流转，衡量事件在各团队队列中的停留时长，并识别因频繁转派造成的瓶颈。它有助于评估团队效率与协作，也是“交接与转派分析”仪表板的基础。

对分析团队间交接、衡量排队时间，以及了解各团队绩效与工作量分布至关重要。

该信息通常存储在事件记录上，每次事件被指派到新团队时都会更新。

解决方式描述事件的处置结果以及如何解决。它可以是标准化编码，也可以是记录具体操作的自由文本。示例包括：“用户培训”“应用补丁”“未发现故障”“重复事件”。

此属性为流程的结束阶段提供关键背景。在流程挖掘中，按解决方式分析事件有助于理解不同方案的有效性。它还能识别未真正修复就关闭的事件，或找出特定类别事件的常见解决模式，以此构建知识库并提升首次接触解决率。

揭示问题的解决路径，有助于发现自动化、知识库完善与培训的机会。

通常是在将事件状态置为'Resolved'或'Closed'时由支持人员填写的字段。

SLA状态用于概览事件相对于既定时间目标（如响应时间、解决时间）的达成情况。常见状态包括'In Progress'、'At Risk'或'Breached'。

该属性是衡量服务质量的直接指标，也是“SLA绩效总览”仪表板的重要输入。在流程挖掘中，它可用于对比违约与未违约事件的流程路径，进而定位导致SLA失效的具体活动、等待或返工环节，支持有针对性的流程优化。

用于直接衡量与目标的偏差。分析已违约的事件有助于定位导致服务交付不佳的流程失效点。

这通常是ITSM工具中的计算字段，会依据事件优先级、事件时长及已定义的SLA规则动态更新。

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

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

将事件与具体业务服务或IT组件关联，可分析哪些服务更易出问题及其影响。

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

请求者是发起报障并实际遇到问题的个人，可以是内部员工，也可以是外部客户。该属性也可记录请求者所属的部门或组织。

按请求者或其部门分析事件，有助于发现是否存在问题集中在特定用户群的现象，从而定位培训需求或局部环境问题。在流程挖掘中，它支持以用户为中心的视角，帮助理解不同用户群体的体验。

便于从用户视角进行分析，识别是否某些用户、部门或地点产生的事件数量异常偏高。

事件记录中的标准字段，通常为建单用户或代其建单的目标用户。

“转派次数”用于统计事件在生命周期内经历的交接或转派的数量。数值过高通常意味着低效、初始分派不当，或支持团队知识不足。

这是流程挖掘分析中非常有力的属性。尽管流程挖掘可以可视化转派，但预先计算的次数更便于筛选和KPI度量。该属性直接用于“交接与转派分析”仪表板，并有助于识别“乒乓式”的来回转派，这类情形会拉长解决时间并让用户感到沮丧。

该指标可直接量化流程低效。高次数通常伴随更长的解决时长，也指向路由或团队能力方面的问题。

通常在事件记录中作为标准计数字段提供；若没有，可通过统计审计日志中的转派变更次数来计算。