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

开始时间记录了特定活动开始的具体日期和时间。该时间戳对于按时间顺序排列事件、计算活动时长以及整体案例生命周期至关重要。流程中的每个活动都应有对应的开始时间，以构建准确的事件日志。

在流程分析中，开始时间用于计算关键绩效指标 (KPI)，如周期时间、活动间的等待时间以及活动处理时间。它支持创建基于时间的流程视图，通过突出显示延迟来帮助识别最耗时的步骤。准确的时间戳是任何性能相关分析的基础。

此时间戳对于正确排列事件顺序以及计算周期时间和瓶颈等所有时间相关指标至关重要。

位于事件日志或审计追踪表中，通常记录为每个活动记录的“创建日期”或“事件时间戳”。

“服务请求 ID”是贯穿每个服务请求生命周期的唯一主键。它作为 Case ID，将所有相关的活动、状态更改和属性关联在一起，形成一个连贯的流程实例。

在流程挖掘分析中，此 ID 是重建每个请求端到端路径的基础。通过将所有事件归类在共同的 CaseId 下，分析师可以可视化流程流向、计算案例时长，并识别不同请求处理方式中的变体。它是对服务请求管理流程执行任何分析的基石。

此 ID 对于串联服务请求的所有事件至关重要，从而实现完整的端到端流程视图。

通常位于服务请求的页眉或主交易表中。

“活动 (Activity)”属性描述了针对服务请求采取的具体步骤或操作。这些活动构成了流程的顺序基石，例如“请求已创建”、“请求已分配”、“处理中”和“请求已关闭”。每个活动代表服务请求流转过程中的一个特定时间点。

活动分析是流程挖掘的核心。它能够发现并可视化实际的流程流向。通过检查活动的顺序和频率，分析师可以识别常见路径、偏离标准流程的情况、请求滞留的瓶颈，以及产生不必要重复步骤的返工循环。

它定义了流程中的步骤，从而能够发掘实际流程流向、瓶颈和偏差。

通常衍生自与服务请求对象关联的状态更改日志、事件表或审计追踪。

“最后数据更新”提供了最近一次数据提取或刷新的时间戳。它告知用户所分析数据的时效性，确保其了解分析结果反映的是当前状态还是历史快照。

此属性对于运营监控和报表至关重要，它为生成的洞察提供了时间背景。它有助于用户信任数据，并根据其时效性做出明智决策。例如，显示一周前更新数据的仪表板与一小时前更新的仪表板，在解读上会有很大差异。

指示数据的实时性，这对于确保分析的相关性以及基于最新信息进行分析至关重要。

这是一个元数据字段，通常在数据提取 (ETL) 过程中生成并存储。

源系统 (Source System) 属性指明了提取数据的 ITSM 平台或其他应用程序的名称。在多系统环境中，此字段有助于区分数据来源，确保数据血缘清晰。

虽然在大多数流程流分析中不直接使用，但它对于数据治理、验证和排障至关重要。当整合多个来源的数据时，分析师可以按系统细分流程视图，从而揭示不同平台间在流程执行或数据质量上的差异。

对于数据治理和故障排除至关重要，它明确了数据的来源，尤其是在具有多个集成系统的环境中。

此值通常在数据提取 (ETL) 过程中添加，并非源系统本身固有的字段。

SLA 截止日期是根据与请求关联的服务水平协议计算的目标时间戳。它由请求的优先级、类型和创建时间等因素决定，界定了预期的解决时限。

此属性是所有 SLA 合规性分析的基础。通过对比实际解决时间与 SLA 截止日期，企业可以确定请求是按时完成还是违反了 SLA。这是衡量服务质量的关键 KPI，常用于识别导致延迟和违规的系统性问题。

这是衡量绩效的基准。它用于计算 SLA 合规率并识别违规请求。

通常是服务请求记录中的计算字段，由适用的 SLA 策略决定。

“被指派团队”是指负责该服务请求的特定支持小组。根据所需专业知识，请求经常在不同团队间路由，例如一级服务台、网络团队或软件开发团队。

分析团队间的交接是服务管理流程挖掘的核心部分。此属性支持团队间转移的可视化，有助于识别沟通鸿沟或延迟。它还能实现团队间的绩效基准比对，比较各组的效率、请求量以及无需进一步升级即可解决请求的能力。

对于分析团队间的流程交接、识别转移延迟以及比较团队绩效至关重要。

服务请求记录中的标准字段。此字段的更改会记录在审计日志中。

“被指派代理人”是指在特定时间点负责处理服务请求的具体人员。一个请求在其生命周期内可能会被分配给不同的代理人。

此属性是绩效和工作负载分析的关键。它使组织能够衡量和比较各代理人的表现，包括平均解决时间和处理的请求量。它还用于分析代理人间的重新分配情况，这可能预示着初始分流、代理人专业分工或负载平衡存在问题。

支持分析个人代理人绩效、工作负载分布以及代理人间重新分配的频率。

可在服务请求记录中获取。此字段的更改通常记录在审计日志或历史记录表中。

“服务类型”对服务请求的性质进行分类。范围可能包括新硬件申请、软件访问权限、一般咨询或技术支持。此分类有助于将请求路由到正确的团队，并了解对不同服务的需求情况。

在流程分析中，服务类型是一个强大的数据切分维度。通过按不同服务类型过滤流程图，组织可以发现某些类型的请求遵循完全不同的流程，具有更长的周期时间或经历了更多返工。这一洞察支持针对特定服务类别开展有针对性的流程改进工作。

支持对不同请求类别进行流程过滤和对比，揭示各类请求特有的瓶颈或低效环节。

服务请求记录中的标准字段，通常与服务目录关联。

“请求优先级”是一种分类方式，帮助支持团队确定处理请求的先后顺序。它通常基于请求对业务的影响及其紧迫性综合评定。常见的优先级包括低、中、高和紧急。

此属性对于性能分析和资源分配至关重要。分析师可以比较不同优先级的周期时间及 SLA 合规情况，确保高优先级请求得到妥善处理。它还有助于识别低优先级请求是否被忽视，或者支持团队是否正确遵循了优先级体系。

对于分析请求是否按业务重要性处理，以及理解优先级如何影响解决时间至关重要。

通常是主服务请求记录上的标准字段。

“请求状态”指示服务请求在其生命周期中特定时间点的状态。常见状态包括新建、处理中、等待中、已解决和已关闭。此属性提供了请求在整个流程中所处位置的快照。

分析请求状态是理解流程流转和状态转换的关键。它可以用于过滤案例、识别卡在特定状态的请求，并衡量在每个状态下花费的时间。例如，分析请求在“等待中”状态停留多长时间，可以揭示因等待用户或外部团队信息而造成的延迟。

支持分析请求在每个状态下花费的时间，突出流程中的瓶颈或延迟。

可在主服务请求表或状态历史日志中获取。

提交渠道表示服务请求的创建方式，例如通过自助服务门户、电子邮件、电话或 API。不同渠道可能对应不同的处理流程或用户预期。

按提交渠道分析流程可以获得重要洞见。例如，通过自助门户提交的请求可能比邮件提交的请求更具结构化且解决速度更快，因为邮件可能需要人工录入数据。这种分析有助于企业推广更高效的渠道，或针对低效渠道改进流程。

有助于确定提交方式是否会影响流程效率、解决时间或首次联系解决率。

通常作为服务请求记录上的标准字段。

此布尔属性指示服务请求是否未能在规定的服务水平协议内完成。如果请求解决时间晚于 'SlaDueDate'，则为 true，反之为 false。

该属性简化了 SLA 合规性的报告与分析。您无需在每次查询时进行日期对比，通过该标志即可轻松完成过滤和聚合。它是仪表板衡量 SLA 绩效的核心指标，有助于快速识别未达标请求的数量和比例。

为 SLA 绩效分析提供清晰简单的标记，方便对违规请求进行过滤和报表。

这是一个派生属性，在数据转换过程中通过对比最终解决时间戳与 'SlaDueDate' 字段计算得出。

“结束时间”记录了特定活动完成的精确日期和时间。如果说开始时间标志着起始，那么结束时间则标志着终结，共同定义了单个流程步骤的持续时间。并非所有事件都有明确的结束时间，因为有些事件是瞬间完成的。

此属性对于计算单个活动的执行时间至关重要。通过用结束时间减去开始时间，分析师可以衡量代理人或系统在某项任务上投入的实际工作时长。这有助于精准定位耗时较长的活动，并将其作为优化或自动化的首选对象。

支持计算活动处理时间，帮助识别流程中哪些具体步骤最耗时。

存在于事件日志或审计追踪表中。如果没有显式提供，可能需要通过下一个活动的“开始时间”来推导。

“解决代码”提供了一种结构化的方式来对服务请求的结果进行分类。示例包括“用户自行解决”、“硬件已更换”、“软件已部署”或“重复请求”。此类信息通常由代理人在关闭请求时输入。

这些代码对于根因分析非常有价值。通过分析不同解决代码出现的频率，组织可以识别经常出现的问题、常见解决方案，以及创建知识库文章或自动化解决方案的机会。例如，如果存在大量的“密码重置”解决案例，则可能证明投资自助密码重置工具是合理的。

通过对请求解决方式进行分类来实现根因分析，有助于识别趋势和主动问题管理的领域。

代理人在解决或关闭服务请求时通常手动填写的字段。

此属性标识发起服务请求的人员所属的部门或业务单位，为请求提供组织背景信息。

按部门分析请求有助于识别各部门特有的需求、趋势或问题。例如，如果财务部发起了大量某种类型的请求，可能表明需要针对性的培训或系统改进。它还支持内部核算报告，并帮助了解全公司对 IT 服务的真实需求。

提供组织背景，支持按业务部门分析请求模式和服务需求。

此信息通常从员工目录或 ITSM 系统中的请求者用户档案中提取。

“重新分配计数”是一个衡量服务请求从一个代理人或团队转移到另一个的次数指标。数值过高可能意味着初始路由错误、代理人知识匮乏或流程权责不明。

这是流程低效的关键指标。在流程挖掘中，该指标有助于量化请求经历的“乒乓”效应。通过分析高重新分配计数的案例，可以发现优化分流流程、加强代理人培训或明确团队职责的机会，确保请求能一次性分配正确。

识别流程低效的关键指标。重新分配次数过多通常与解决时间延长和用户不满直接相关。

这是一个计算指标，通过统计特定 'CaseId' 的 'AssignedAgent' 或 'AssignedTeam' 字段更改的次数得出。