您的问题管理 Data 模板

BMC Helix ITSM

您的问题管理 Data 模板

此模板为您在 BMC Helix ITSM 中分析根本原因调查 workflow 提供了全面的结构。它概述了构建详细 event log 所需的核心属性和流程活动，并附带实用的提取指南。通过遵循此指南，您可以识别隐藏的瓶颈，并优化通往永久解决事件的路径。

根本原因分析的基础 data 字段
用于追踪的标准流程里程碑
针对 BMC Helix ITSM 的特定提取指南

不熟悉事件日志？了解如何创建流程挖掘事件日志.

下载模板

问题管理属性

本表包含了为全面分析问题管理生命周期而填充 event log 所需的推荐 data 字段。

5 必填 9 推荐 5 可选

	名称	描述
	Event 时间 EventTime	特定活动发生的 timestamp。
描述此属性记录活动发生的精确日期和时间。在 BMC Helix ITSM 中，这对应于“Submit Date”、“Last Modified Date”等字段，或历史记录表中记载的状态变更特定 timestamp。在分析中，此属性用于按时间顺序排列 event 并计算时长。它支持测量流程中任意两点之间的周期时间，例如“调查周期时间”或“Workaround 发布前置时间”。精确的 timestamp 对于识别瓶颈至关重要。通过计算连续 event 之间的时间差，分析人员可以精准定位延迟发生的环节，无论是初始分派阶段还是最终评估阶段。为何重要它支持计算所有基于时长的 KPI 以及 event 的排序。获取方式与 PBM:Problem Investigation 关联的历史表或审计日志示例 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:10Z
	活动 Activity	发生的特定任务或状态更改事件。
描述此属性代表问题管理生命周期中执行的具体步骤，如“问题记录已登记”、“根本原因已查明”或“解决方案数据库已更新”。在 BMC Helix 中，这些通常源自状态历史、审计日志或问题调查模块中的特定交易 timestamp。此属性是流程发现的核心。通过分析这些活动的序列，Process Mining 工具可以构建流程图，揭示实际工作流与设计流程的差异。它会突出显示循环、返工以及偏离标准操作规程的情况。准确的活动名称对于理解生命周期中发生的真实情况至关重要。这些 data 支持测量特定步骤之间的转化时间，例如从查明根本原因到发起变更请求所耗费的时间。为何重要它定义了流程图中的节点，并实现了工作流的可视化。获取方式源自 PBM:Problem Investigation 状态历史或 PBM:AuditLogSystem 示例问题记录已登记指派给支持小组调查开始已识别根因
	问题记录 ProblemRecord	问题调查 case 的唯一标识符。
描述此属性作为问题管理流程的核心 case 标识符。在 BMC Helix ITSM 中，这通常是 PBM:Problem Investigation 表单上的“Problem ID”字段（如 PBI00000012345）。它关联了从初始登记到最终关闭及实施后评估的所有活动。在 Process Mining 分析中，此属性用于将分散的 events 归组为单个流程实例。它允许分析人员可视化特定问题调查的端到端路径。如果没有这个标识符，就无法关联不同支持组和协调员采取的行动序列。此字段作为 event log 的主键，对于所有 case 级别的聚合分析（如计算每个问题的总周期时间或按优先级统计问题数量）都不可或缺。为何重要它是构建流程视图和追踪特定问题生命周期所需的根本密钥。获取方式 PBM:Problem Investigation 表单，“Problem ID” 字段示例 PBI00000004512PBI00000004513PBI00000004514
	最后数据更新 LastDataUpdate	数据提取或上次刷新的时间戳。
描述此属性表明 data 上次加载到 Process Mining 应用的时间，确保分析人员了解所查看 data 的时效性。它通常由提取脚本或 data 流转工具生成。在分析中，这有助于防止基于陈旧 data 做出决策。例如，当管理者查看“未结问题记录”时，了解 data 是一个小时前更新的还是一个星期前更新的，会显著改变对当前工作量的评估。它还用于增量 data 加载。通过追踪上次更新时间，ETL 过程可以仅抓取自上次提取以来发生变化的记录，从而优化性能并降低系统负载。为何重要它确保了 data 的新鲜度，并辅助执行增量 data 加载策略。获取方式提取时刻的系统时间示例 2023-11-01T00:00:00Z2023-11-01T12:00:00Z
	源系统 SourceSystem	数据来源的系统。
描述此属性识别流程 data 提取自哪个软件系统，在本例中为 “BMC Helix ITSM”。在 Process Mining 可能聚合来自多个 ITSM、开发或外部供应商工具 data 的多系统环境中，这一点尤为重要。在分析中，此字段充当验证记录来源的元数据标签。如果分析视图结合了来自 BMC Helix 的问题管理 data 和来自另一个系统（如 Jira）的软件开发 data，此属性有助于按来源工具切分分析。它还有助于技术排障。如果出现 data 质量问题，了解源系统可让 data 工程师追溯到具体的提取程序或源数据库。为何重要它提供了可追溯性和上下文背景，尤其是在多系统流程视图中。获取方式在提取过程中硬编码示例 BMC Helix ITSMRemedy OnDemandBMC ITSM 生产环境
	SLA 到期日期 SLADueDate	问题必须解决的目标日期和时间。
描述此属性包含基于服务级别协议的问题解决截止日期。在 BMC Helix 中，这通常是“Target Resolution Date”或计算出的 SLA 里程碑 timestamp。此属性是“SLA 合规与超期趋势”dashboard 的基准。通过将此 timestamp 与“解决方案验证”活动的 timestamp 进行对比，系统可以计算出是否满足或违反了 SLA。通过可视化该日期，分析人员可以观察团队的工作节奏：是提前几天解决问题，还是总是踩在超期前的最后几分钟完成？这些洞察有助于驱动容量规划。为何重要它是计算所有合规性和时效性指标的参考点。获取方式 PBM:Problem Investigation 表单，“Target Resolution Date” 字段示例 2023-12-01T17:00:00Z2023-12-02T09:00:00Z
	优先级 Priority	根据影响度和紧急度计算出的问题优先级。
描述此属性表示问题记录的优先级（如：Critical、High、Medium、Low）。在 BMC Helix 中，这通常是根据影响度和紧急度选择计算出的字段。在分析中，此属性用于“吞吐量与优先级规模”dashboard。它允许企业验证资源是否与业务需求正确匹配。例如，从理论上讲，“Critical”问题的初始分派时间应更快，整体周期时间应比“Low”优先级的问题更短。按优先级过滤有助于聚焦改进工作。在“Low”优先级流程中的瓶颈或许可以接受，但在“Critical”流程中的相同延迟则意味着业务连续性和 SLA 合规面临重大风险。为何重要它根据业务关键性对分析进行分段，并支持 SLA 分析。获取方式 PBM:Problem Investigation 表单，“Priority” 字段示例严重高中低
	关联事件数量 RelatedIncidentCount	关联至此问题记录的事件数量。
描述此属性通过统计关联事件的数量来量化问题的影响力。在 BMC Helix 中，这通常是 HPD:Help Desk 表单中与 PBM 记录相关的记录总数。此属性驱动“事件关联密度”KPI。高关联数表明该问题影响巨大，正给服务台带来大量压力。将其与“优先级”关联分析，可以确保高频率发生的问题确实得到了关键级别的对待。它还有助于排列待办事项的优先级。一个关联了 500 个事件的问题记录通常应比一个仅关联 1 个事件的“Critical”问题优先处理，因为解决前者能释放更多的服务台人力。为何重要它量化了与问题相关的运营影响和用户痛点。获取方式通过计算 HPD:Associations 或 HPD:Help Desk 中的相关行数得出示例 15120
	支持组 SupportGroup	当前负责问题调查的技术团队。
描述此属性反映了在 event 发生时负责该问题记录的特定支持组（如“服务器管理组”、“数据库支持组”）。在 BMC Helix 中，这对应“Assigned Group”字段。此属性对于“支持组工作量分布”和“支持组重分派分析”dashboard 至关重要。它允许分析人员按团队切分流程图，揭示哪些小组处理量最大，以及哪些小组是调查流程中的瓶颈。分析支持组之间的交接有助于识别“乒乓”行为（工单在团队间反复跳转却未解决）。这通常指向职责不明或组织内部知识管理不善。为何重要它支持在团队层级进行组织分析和瓶颈检测。获取方式 PBM:Problem Investigation 表单，“Assigned Group” 字段示例一线服务台后台支持网络管理
	是否发生SLA违约 IsSLABreached	表示问题解决是否超出允许时间的标记。
描述此布尔属性表示问题记录是否违反了服务级别协议。它通过对比“解决方案验证”timestamp 与“SLA 到期日期”计算得出，或直接从 SLM 状态中提取。此属性对于“SLA 合规与超期趋势”dashboard 至关重要。它支持对流程进行简单的二元切分：合规 vs. 违规。这使得隔离失败流程的特征变得容易（例如：“违规 case 是否总是涉及支持组 X？”）。它是流程失败根本原因分析的主要过滤器。分析人员可以过滤出“IsSLABreached = True”的记录，然后查看流程图以确定时间损耗在哪里（如：等待供应商审批的时间过长）。为何重要它简化了合规报告和故障分析。获取方式 SLM:Measurement 表单或计算值示例 truefalse
	服务 CI ServiceCI	受影响的主要业务服务或配置项。
描述此属性识别与问题相关的服务配置项 (CI)，如“邮件服务”、“SAP ERP”或“Wi-Fi 网络”。在 BMC Helix 中，这通常是“Service+”字段或主要的 CI 关联。在分析中，这可以按产品或服务对问题记录进行维度切分。它能帮助 IT 领导层了解哪些服务最脆弱且产生的问题调查最多。通过增加产品维度，它为“吞吐量与优先级规模”dashboard 提供数据。将此属性与“调查周期时间”相关联，可以揭示某些复杂服务（如核心银行系统）是否天生比通用服务（如打印服务）需要更长的调查周期。为何重要它将流程绩效与特定的业务产品或服务关联。获取方式 PBM:Problem Investigation 表单，“ServiceCI” 或 “CI Name” 字段示例邮件服务工资系统企业VPN
	根因类别 RootCauseCategory	对问题潜在原因的分类。
描述此属性包含识别根本原因时选择的类别（如“软件错误”、“硬件故障”、“流程缺失”）。在 BMC Helix 中，通常从“Root Cause”或“通用分类”菜单中选择。此属性对于“修复有效性与质量”视图至关重要。它允许企业将特定类型的根本原因与返工率或漫长的调查时间关联起来。例如，它可能揭示“软件错误”问题的解决时间始终是“硬件故障”的两倍。它还用于计算“根本原因分类率”。如果此字段中“未知”或“其他”值的比例很高，说明需要加强技术培训或提供更细致的分类选项。为何重要它支持对系统性问题进行趋势分析，并辅助主动式问题管理。获取方式 PBM:Problem Investigation 表单，“Root Cause” 或分类页签字段示例软件模块网络基础设施人为错误
	调查驱动因素 InvestigationDriver	启动问题调查的原因。
描述此属性对问题记录的触发因素进行分类，如“事件量”、“重大事件”、“供应商通知”或“主动趋势分析”。在 BMC Helix 中，这对应“Investigation Driver”字段。此属性支持“主动识别趋势”dashboard。它允许企业衡量从响应式救火（处理事件）向主动式问题管理（在风险显现前识别）的转变。按“Investigation Driver”分析流程流向可以揭示不同的行为模式。例如，“主动型”问题在队列中停留的时间可能更长，因为它们未造成即时停机；而由“重大事件”驱动的问题则会快速推进。为何重要它区分了被动工作和主动工作，这是衡量成熟度的关键指标。获取方式 PBM:Problem Investigation 表单，“Investigation Driver” 字段示例响应型主动型重复性事件
	问题协调员 ProblemCoordinator	负责协调调查的具体人员。
描述此属性指明负责该问题记录的具体人员。在 BMC Helix ITSM 中，这对应“Problem Coordinator”字段。即使任务委派给他人，此人仍负责该问题的整个生命周期。此属性支持“支持组工作量分布”dashboard。它帮助管理者识别某些人是否调查任务过重，而其他人尚有余力。它还支持个人层面的绩效分析，有助于识别培训需求或表现优异者。在 Process Mining 中，此字段充当资源属性。它有助于可视化工作在个人之间的流转情况，并能突出显示由于流程过度依赖某一位专家而导致的单点故障风险。为何重要它支持在个人层级进行资源分析和工作量平衡。获取方式 PBM:Problem Investigation 表单，“Problem Coordinator” 字段示例 John DoeJane Smith系统管理员
	Workaround 状态 WorkaroundStatus	指示是否已识别并发布有效的临时方案。
描述此属性追踪临时方案 (Workaround) 的状态。它可以是简单的布尔值（是否有 Workaround）或状态字符串。在 BMC Helix 中，这通常根据“Workaround”字段中是否存在文本或特定的状态标记来推断。此属性是“Workaround 发布绩效”dashboard 的关键。它反映了团队在研究根本原因时缓解影响的效率。通过“无 Workaround”过滤的流程视图可以突出显示那些在调查期间业务正承受全面影响的 case。它还支持质量审计。在没有永久修复（变更请求）且没有 Workaround 的情况下关闭问题记录，通常被视为需要审查的流程失败。为何重要它衡量了调查期间影响缓解措施的有效性。获取方式 PBM:Problem Investigation 表单，“Workaround” 字段内容检查示例在职无已停用
	关联变更请求 ID RelatedChangeRequestId	为修复问题而发起的变更请求标识符。
描述此属性包含与问题记录关联的变更请求 ID（如 CRQ0000...）。它代表了从调查到实施永久修复的过渡。此属性对于“从根本原因到变更的前置时间”KPI 必不可少。它允许 Process Mining 工具衡量查明根本原因与启动变更流程之间的延迟。这是一个常见的容易丢失进度的交接点。它还有助于验证“流程完整性”。如果一个问题记录以“已完成”状态关闭，但没有关联的变更请求（或 Workaround），可能表明存在流程违规，即根本原因已查明但从未真正修复。为何重要它将问题管理流程与变更管理流程联系起来。获取方式 PBM:Investigation Associations 或关系选项卡示例 CRQ00000021345CRQ00000021346
	区域 Region	与问题相关的地理区域。
描述此属性指定问题发生或被管理的地理位置（如“北美”、“欧洲中东非洲”）。在 BMC Helix 中，这通常位于与请求者或受影响资产相关的“Region”或“Site”字段中。在分析中，这支持地理维度切分。它有助于识别特定区域是否面临更高的问题量或更慢的解决速度，从而揭示不同地点在支持人员配置或基础设施质量方面的差异。对于全球化组织而言，这对于确保一致的服务交付极具价值。如果“亚太区”的“调查周期时间”是“北美区”的两倍，则会触发对该区域资源分配或流程执行情况的调查。为何重要它支持对不同地理区域的流程绩效进行比较。获取方式 PBM:Problem Investigation 表单，“Region” 字段示例美洲欧洲、中东和非洲亚太
	调查周期时间 InvestigationCycleTime	从调查启动到根本原因识别的持续时间。
描述这是一个计算得出的时长属性，测量“调查已开始”活动与“根本原因已查明”活动之间的时间。它代表了问题管理流程中最核心的增值时间。此指标为“根本原因调查周期时间”dashboard 提供数据。它帮助管理者了解问题的技术复杂性以及调查团队的效率。此处的异常值（如时间极短）可能暗示凭空猜测，而时间极长则表明调查停滞。通过跨“支持组”和“优先级”对比此指标，企业可以识别哪些团队需要更好的工具、培训或供应商支持，以便更快地诊断问题。为何重要它是技术调查阶段的主要效率指标。获取方式基于 Activity timestamp 计算示例 4500000120000
	重新分配次数 ReassignmentCount	支持组变更的总次数。
描述此属性统计单个 case 中“分派至支持组”活动发生的次数。它是衡量流程摩擦和路由效率的直接指标。此属性填充“支持组重分派分析”图表。高数值（乒乓效应）表明初始分拣失败，或者复杂问题缺乏明确的所有权。它是周期时间增加的前导指标。管理者可以利用此指标发现培训机会。如果服务台总是先将“数据库”问题分配给“网络组”，随后“网络组”又发回给“数据库组”，那么重分派计数就会飙升，凸显了改进初始诊断脚本的必要性。为何重要它识别了流程中的浪费、阻力和权责不明。获取方式基于 Activity 历史计算示例 015

必填推荐可选

问题管理活动

这些是您应当追踪的核心流程步骤和状态变更，以实现调查和解决阶段的全面透明化。

9 推荐 4 可选

	活动	描述
	Workaround 已定义	在问题记录的 Workaround 字段中输入或更新文本。此 event 表明临时方案已被记录。
为何重要支持“Workaround 发布前置时间”KPI，体现了对事件影响的缓解能力。获取方式 PBM:Problem Investigation 表单，“Workaround” 文本字段的变更。捕获针对非空更新比较“Workaround”字段内容事件类型 inferred
	变更请求已发起	将基础设施变更请求与问题调查进行关联，标志着实施阶段的开始。
为何重要对于“根本原因到变更提前期”KPI 以及识别问题与变更流程之间的孤岛至关重要。获取方式 PBM:Investigation_Associations 表或“Infrastructure Change ID”字段填充。捕获在 PBM:Investigation_Associations 中创建关联时记录事件类型 explicit
	已识别根因	问题记录转入表明原因已查明状态的时刻。当 Status 变为“Root Cause Identified”时推断得出。
为何重要 “根本原因调查周期时间”仪表板的关键里程碑。标志着从分析阶段转向解决方案阶段。获取方式 PBM:Problem Investigation 表单，“Status” 字段 = “Root Cause Identified”。捕获针对状态字段向“根本原因已确定”的转换进行比较事件类型 inferred
	指派给支持小组	将问题记录分派给特定的技术团队。通过监控“Assigned Group”字段的变更来捕捉。
为何重要对于衡量交接、乒乓效应以及“平均初始分配时间”KPI 至关重要。获取方式 PBM:Problem Investigation 表单，“Assigned Group”字段历史或审计日志。捕获比较更新前后的“Assigned Group”字段事件类型 inferred
	解决方案已验证	永久修复被确认成功的节点。从 Status 变为“Solution Implemented”或“Completed”推断得出。
为何重要用于“问题 SLA 达成率”。确认技术工作已完成。获取方式 PBM:Problem Investigation 表单，“Status” 字段 = “Solution Implemented” 或 “Completed”。捕获针对状态字段向“解决方案已实施”的转换进行比较事件类型 inferred
	调查开始	问题记录进入活跃分析阶段。当 Status 字段变为“Under Investigation”时推断得出。
为何重要标志着实际工作阶段的开始，支持“调查周期时间”KPI。获取方式 PBM:Problem Investigation 表单，“Status” 字段 = “Under Investigation”。捕获针对状态字段向“调查中”的转换进行比较事件类型 inferred
	问题记录已关闭	问题记录的最终行政关闭。此 event 标志着该流程 case 的终结。
为何重要标准结束 event。对于全周期时间分析和“事件关联密度”计算至关重要。获取方式 PBM:Problem Investigation 表单，“Status” 字段 = “Closed”。捕获针对状态字段向“已关闭”的转换进行比较事件类型 inferred
	问题记录已取消	问题解决前的提前终止。当状态变为“Cancelled”或“Rejected”时捕捉。
为何重要识别无效工作或有效的重复项。代表另一个流程终点。获取方式 PBM:Problem Investigation 表单，“Status” 字段 = “Cancelled” 或 “Rejected”。捕获针对状态字段向“已取消”的转换进行比较事件类型 inferred
	问题记录已登记	在系统中初始创建问题调查记录。当在 PBM:Problem Investigation 表单中保存新条目时，会明确捕捉到此 event。
为何重要标志着流程实例的开始。对于计算整体周期时间和初始响应指标至关重要。获取方式 PBM:Problem Investigation 表单，“Submit Date” timestamp 或 “Status” = “Draft” 的创建日志。捕获在 PBM:Problem Investigation 记录创建时记录事件类型 explicit
	协调员已重新分配	支持组内单个问题协调员的变更。通过监控“问题协调员”字段进行捕获。
为何重要有助于分析工作负荷分布和个人资源瓶颈。获取方式 PBM:Problem Investigation 表单，“Problem Coordinator”字段历史。捕获比较更新前后的“Problem Coordinator”字段事件类型 inferred
	已执行实施后评审	PIR 阶段的完成。通过状态移出 PIR 阶段或关闭关联的 PIR Task 来捕捉。
为何重要直接支持“实施后评审合规性”和流程质量审计。获取方式 PBM:Problem Investigation 表单，特定标记 “PIR Required” 或已关联的 “PIR” 类型 Task 的完成情况。捕获源自 PIR 状态完成或 PIR 任务关闭事件类型 inferred
	已知错误已提升	创建与问题调查关联的已知错误记录。这属于关联记录创建 event。
为何重要标志着问题的正式化，以便进行更广泛的沟通和长期跟踪。获取方式在 PBM:Known Error 中创建与 PBM:Problem Investigation ID 关联的记录。捕获在 PBM:Known Error 记录创建时记录事件类型 explicit
	解决方案数据库已更新	记录转入“Solution Database”状态，表明永久修复方案已被提出或查明。
为何重要在实施前追踪解决方案定义的进展。获取方式 PBM:Problem Investigation 表单，“Status” 字段 = “Solution Database”。捕获针对状态字段向“解决方案数据库”的转换进行比较事件类型 inferred

推荐可选

提取指南

如何从 BMC Helix ITSM 提取您的问题管理 data

步骤

登录 BMC Helix ITSM 使用具有 Problem Master 或 Report Administrator 权限的凭据访问 mid-tier 或 Smart IT 界面。
导航至报表控制台 从 Applications 菜单中选择 AR System Report Console。如果使用 Smart IT，请导航至 Reporting 仪表板并选择 'Web Report'。
创建新报表 点击 New 按钮（绿色加号图标）启动报表向导。
选择数据源（表单） 在 'Form Name' 字段中，搜索并选择 PBM:AuditLogSystem（或根据版本选择 PBM:Problem Investigation_AuditLog）。注意：虽然 PBM:Problem Investigation 表单包含当前 case data，但审计日志表单对于生成 data 要求中必需的逐行 event 历史（例如重新分配、状态变更）是必不可少的。
定义报表名称和类型 输入描述性名称（例如“问题管理事件日志”），并确保格式设置为 Web Report。
添加列（属性） 从 Available Fields 列表中选择以下字段并移动到 Selected Fields 列表：
- Original Request ID（映射到 ProblemRecord）
- Submit Date（映射到 EventTime）
- Fields Changed（映射到 Activity）
- User（映射到 User/Coordinator）
- Log Key 1（通常保存原始状态值）
配置过滤器（限定条件） 点击 Filter 或 Qualification 选项卡。构建查询以限制范围：
- 将 Form Name 设置为 "PBM:Problem Investigation"（以排除 Incident/Change 审计）。
- 将 Submit Date 设置为您所需的范围（例如 >= 01/01/2023）。
保存并运行 保存报表配置。点击 Preview 验证 data 是否正常返回，然后点击 Export。
导出为 CSV 选择 CSV (逗号分隔值) 作为导出格式。确保包含表头。
二次导出（属性推荐操作） 针对 PBM:Problem Investigation 创建第二个简单报表。导出 Problem Investigation ID、Priority、ServiceCI 和 Description。此“Case 属性”文件可以在您的分析工具中与事件日志合并，以填充审计日志行中缺失的静态属性（如优先级、服务配置项）。
数据转换（导出后） 在上传至 ProcessMind 之前：
- 将 Fields Changed 值映射到标准 Activity（例如：如果 Field Changed = "Status"，则使用 Log Key 1 中的值来确定其为“调查开始”还是“根本原因已确定”）。
- 过滤掉不需要的非流程更新（例如格式字段更新）。

配置

Form Selection: PBM:AuditLogSystem 是主要数据源。直接提取 PBM:Problem Investigation 仅能获取“当前”状态，无法捕获“协调员已重新分配”或“已定义临时方案”的历史记录。
Date Filtering: 过滤 Audit 表单中的 Submit Date，而不仅仅是 case 创建日期，以便捕获旧 case 的近期活动。
Field 'Form Name': 关键过滤条件。Audit System 表单在整个 ITSM 中通用。您必须通过 Form Name = "PBM:Problem Investigation" 进行过滤，以避免混入事件 (Incident) 或变更 (Change) 日志。
Performance: 审计日志表非常庞大。建议将导出限制在 3-6 个月的时间窗口内，或严格通过 Original Request ID 前缀（如 PBM%）进行过滤。
Permissions: 需要查看 System Audit 表单的权限。如果权限受限，必须由系统管理员执行此导出操作。

a 查询示例 config

Form: PBM:AuditLogSystem
Type: Web Report (AR System Report Console)

// === SELECTION COLUMNS ===
// These fields form the raw event log structure
1. Original Request ID   (Alias: ProblemRecord)
2. Submit Date           (Alias: EventTime)
3. Submitter             (Alias: User)
4. Fields Changed        (Alias: Activity_Type)
5. Log Key 1             (Alias: New_Value)
6. Log Key 2             (Alias: Previous_Value)
7. Form Name             (Alias: Source_Module)

// === SEARCH QUALIFICATION (FILTER) ===
// Copy this logic into the Advanced Search or Qualification builder

('Form Name' = "PBM:Problem Investigation") AND
('Submit Date' >= "2023-01-01 00:00:00") AND
('Fields Changed' != $NULL$)

// === POST-EXPORT LOGIC (Context for Analyst) ===
// The Audit Log captures changes generically. You must map them:
// IF 'Fields Changed' CONTAINS "Status" AND 'Log Key 1' = "Under Investigation" -> Activity = "Investigation Commenced"
// IF 'Fields Changed' CONTAINS "Work Around" -> Activity = "Workaround Defined"
// IF 'Fields Changed' CONTAINS "PBM Coordinator" -> Activity = "Coordinator Reassigned"
// IF 'Fields Changed' = $NULL$ (Create Event) -> Activity = "Problem Record Logged"

步骤

必备条件验证: 确保您拥有对 AR System 数据库的读取访问权限（SELECT 权限），特别是 PBM_Problem_Investigation 和 PBM_Problem_WorkLog 视图。确认您的用户帐户有权访问相关的公司/支持组 data。
数据库连接: 打开您首选的 SQL 客户端（如 SSMS, DBeaver 或 Oracle SQL Developer），并连接到 BMC Helix AR System 数据库副本或报表数据库。
了解数据模型: 识别您实例中的特定表名或视图名称。虽然 PBM_Problem_Investigation 是标准名称，但某些定制环境可能使用 PBM_Problem_Investigation_Join 等。验证 Problem_ID 和 Submit_Date 的列名。
准备查询: 复制下方“查询”部分提供的 SQL 语句。该脚本将主问题记录 data 与工作日志历史记录相结合，从而创建事务性事件日志。
配置过滤器: 找到脚本中的 WHERE 子句（带有类似 /* Filter by Date */ 的注释），并将日期范围更新为您所需的提取窗口（例如 Submit_Date >= '2023-01-01'）。
执行提取: 运行完整查询。根据问题记录和工作日志的数量，这可能需要几分钟时间。请确保您的数据库客户端不会超时。
Data 验证: 检查特定关键列的结果：ProblemRecord、Activity 和 EventTime。确保这些必填字段中没有空值 (NULL)。
导出 Data: 将查询结果保存为 CSV 文件。使用标准编码 (UTF-8) 并确保包含表头。
格式化上传: 打开 CSV 并验证日期格式是否一致（ProcessMind 建议使用 ISO 8601 YYYY-MM-DD HH:MM:SS）。如果发现文本字段中有二进制字符或过多空格，请将其删除。
导入 ProcessMind: 将清理后的 CSV 上传至 ProcessMind，并按照“设置概览”中的定义映射各列。

配置

Timeframe: 建议提取 3-6 个月的 data，以平衡性能与流程可见性。
System Views: 主要视图为 PBM_Problem_Investigation（表头 data）和 PBM_Problem_WorkLog（Activity 历史）。
Date Filtering: 主要针对 Problem Investigation 的 Submit_Date 进行过滤以保留完整的 case，或针对 EventTime 进行过滤以获取严格的时间范围快照。
Company Filter: 如果托管多个租户，请在所有 WHERE 子句中添加 AND Company = 'YourCompany' 以防止 data 泄露。
Performance: 查询使用 UNION ALL 虽然高效，但在 WorkLog 中连接大型 CLOB/文本字段可能会很慢。请确保利用了 Problem_ID 上的数据库索引。

a 查询示例 sql

/* Part 1: Problem Record Logged (Creation) */
SELECT
    P.Problem_ID AS ProblemRecord,
    'Problem Record Logged' AS Activity,
    P.Submit_Date AS EventTime,
    'BMC Helix' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    P.Assigned_Group AS SupportGroup,
    P.Priority AS Priority,
    P.PBM_Coordinator AS ProblemCoordinator,
    P.Generic_Category AS RootCauseCategory,
    P.ServiceCI AS ServiceCI,
    P.Investigation_Driver AS InvestigationDriver,
    P.Target_Date AS SLADueDate,
    (SELECT COUNT(*) FROM HPD_Help_Desk_Associations A WHERE A.Problem_ID = P.Problem_ID) AS RelatedIncidentCount,
    CASE WHEN P.Target_Date < P.Closed_Date THEN 'Yes' ELSE 'No' END AS IsSLABreached
FROM PBM_Problem_Investigation P
WHERE P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 2: Investigation Commenced (Status Transition) */
SELECT
    P.Problem_ID,
    'Investigation Commenced',
    /* Prefer explicit status history timestamp if available, else estimate from Last_Modified if current status matches */
    COALESCE(P.Status_History_Under_Inv_Time, P.Last_Modified_Date),
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
WHERE P.Status_History_Under_Inv_Time IS NOT NULL
   OR (P.Status = 1 AND P.Last_Modified_Date IS NOT NULL) /* Status 1 = Under Investigation */
   AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 3: Root Cause Identified (Status Transition) */
SELECT
    P.Problem_ID,
    'Root Cause Identified',
    COALESCE(P.Status_History_Root_Cause_Time, P.Last_Modified_Date),
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
WHERE P.Status_History_Root_Cause_Time IS NOT NULL
   OR (P.Status = 2) /* Status 2 = Root Cause Identified */
   AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 4: Solution Database Updated (Status Transition) */
SELECT
    P.Problem_ID,
    'Solution Database Updated',
    COALESCE(P.Status_History_Solution_Time, P.Last_Modified_Date),
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
WHERE P.Status_History_Solution_Time IS NOT NULL
   OR (P.Status = 3) /* Status 3 = Solution Database */
   AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 5: Resolution Verified (Inferred from Completed Status) */
SELECT
    P.Problem_ID,
    'Resolution Verified',
    COALESCE(P.Status_History_Completed_Time, P.Last_Modified_Date),
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
WHERE P.Status_History_Completed_Time IS NOT NULL
   OR (P.Status >= 4) /* Status 4 = Implemented/Completed */
   AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 6: Problem Record Closed */
SELECT
    P.Problem_ID,
    'Problem Record Closed',
    P.Closed_Date,
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
WHERE P.Status = 5 /* Status 5 = Closed */
  AND P.Closed_Date IS NOT NULL
  AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 7: Problem Record Cancelled */
SELECT
    P.Problem_ID,
    'Problem Record Cancelled',
    P.Last_Modified_Date,
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
WHERE P.Status = 6 /* Status 6 = Cancelled */
  AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 8: Workaround Defined (From Worklog) */
SELECT
    P.Problem_ID,
    'Workaround Defined',
    W.Submit_Date,
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
JOIN PBM_Problem_WorkLog W ON P.Problem_ID = W.Problem_ID
WHERE W.Work_Log_Type = 'Workaround' OR W.Description LIKE '%Workaround%'
  AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 9: Assigned to Support Group (From Worklog) */
SELECT
    P.Problem_ID,
    'Assigned to Support Group',
    W.Submit_Date,
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
JOIN PBM_Problem_WorkLog W ON P.Problem_ID = W.Problem_ID
WHERE W.Description LIKE '%Assigned to Group%'
  AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 10: Coordinator Reassigned (From Worklog) */
SELECT
    P.Problem_ID,
    'Coordinator Reassigned',
    W.Submit_Date,
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
JOIN PBM_Problem_WorkLog W ON P.Problem_ID = W.Problem_ID
WHERE W.Description LIKE '%Coordinator%' AND W.Description LIKE '%Change%'
  AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 11: Change Request Initiated (From Worklog or Description) */
SELECT
    P.Problem_ID,
    'Change Request Initiated',
    W.Submit_Date,
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
JOIN PBM_Problem_WorkLog W ON P.Problem_ID = W.Problem_ID
WHERE (W.Description LIKE '%Change Request%' OR W.Description LIKE '%CRQ%')
  AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 12: Known Error Promoted (From Worklog) */
SELECT
    P.Problem_ID,
    'Known Error Promoted',
    W.Submit_Date,
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
JOIN PBM_Problem_WorkLog W ON P.Problem_ID = W.Problem_ID
WHERE (W.Description LIKE '%Known Error%' OR W.Work_Log_Type = 'Known Error')
  AND P.Submit_Date >= '2023-01-01'

UNION ALL

/* Part 13: Post-Implementation Review Conducted */
SELECT
    P.Problem_ID,
    'Post-Implementation Review Conducted',
    COALESCE(P.Status_History_Completed_Time, P.Last_Modified_Date),
    'BMC Helix',
    GETDATE(),
    P.Assigned_Group,
    P.Priority,
    P.PBM_Coordinator,
    P.Generic_Category,
    P.ServiceCI,
    P.Investigation_Driver,
    P.Target_Date,
    NULL,
    NULL
FROM PBM_Problem_Investigation P
WHERE (P.Status_Reason = 'PIR' OR P.Investigation_Driver = 'PIR')
  AND P.Status >= 4
  AND P.Submit_Date >= '2023-01-01'

步骤

必备条件: 确保您的提取设备上已安装 Python 3.x。您需要 requests 和 pandas 库，可以通过 pip install requests pandas 进行安装。
API 访问: 向您的 BMC Helix ITSM 管理员申请一个专门的集成用户帐户。该用户需要具有 'Problem Viewer' 和 'AR System Administrator'（或同等的 API 访问权）权限。
识别 API 网关: 获取 BMC Helix AR System REST API 的基础 URL。通常格式为 https://[your-instance].onbmc.com/api/arsys/v1。
字段 ID 映射: BMC Helix 使用内部字段 ID。虽然脚本使用 useLabels 功能尝试获取易读名称，但您仍应通过 Developer Studio 或执行测试 GET 请求，验证您部署中 'Status'、'Assigned Group' 和 'Workaround' 的具体字段 ID。
脚本配置: 更新提供的 Python 脚本中的 CONFIG 字典。设置您的 URL、用户名、密码以及提取日期范围。
主 Data 提取: 脚本首先查询 PBM:Problem Investigation 表单。这将检索基本问题记录详情，根据 Submit Date 创建“问题记录已登记”的 event，并捕获当前属性。
历史 Data 提取: 脚本会迭代获取审计追踪记录。在 BMC Helix 中，历史记录通常存储在 PBM:AuditLogSystem 中或通过关联访问。提供的脚本会查询 Audit 表单以捕获状态转换（如“调查开始”）和字段更新（如“分配至支持组”）。
数据转换: 脚本包含将 BMC 状态代码（如 'Under Investigation'、'Root Cause Identified'）映射到流程定义所需的特定 Activity 名称的逻辑。
验证: 以空运行模式运行脚本（仅获取少量记录）以确保字段名称与您的定制一致。检查控制台输出是否有连接错误。
执行: 运行完整提取。脚本使用 offset 和 limit 参数自动处理分页，以避免超时。
生成输出: 脚本将所有 event 聚合到一个 DataFrame 中，并将其导出为名为 problem_management_event_log.csv 的文件。
最终检查: 在上传至 ProcessMind 之前，打开 CSV 文件并验证 'EventTime' 列格式是否正确（建议使用 ISO 8601），并确保所有 13 种 Activity 类型均已包含。

配置

API Endpoint: AR System REST API 是标准接口。请确保相关端口（通常为 443）的流量已放行。
Pagination: 脚本默认批处理大小为 1000。请根据网络延迟和服务器超时设置进行调整。
Date Filtering: 提取时会根据主记录的 Submit Date 进行过滤。请确保查询中的日期格式与 AR System 格式一致（通常为 epoch 或特定字符串格式，具体取决于版本）。
Field Selection: 仅请求必要的字段以减小数据载荷。添加描述或附件字段会显著降低提取速度。
Authentication: 使用 JWT (JSON Web Token) 身份验证。由于令牌会过期，脚本包含在请求前获取令牌的逻辑。
Status Mapping: BMC 使用整数 ID 表示状态值（例如 0, 10, 20）。脚本会将这些 ID 映射为易于理解的 Activity。请根据您的 ITSM 具体配置核对这些映射关系。

a 查询示例 python

import requests
import json
import pandas as pd
from datetime import datetime
import time

class=class="hl-string">"hl-comment"># Configuration
CONFIG = {
    class="hl-string">"base_url": class="hl-string">"https://[your-instance].onbmc.com/api/arsys/v1",
    class="hl-string">"username": class="hl-string">"[API_User]",
    class="hl-string">"password": class="hl-string">"[API_Password]",
    class="hl-string">"start_date": class="hl-string">"2023-01-01T00:00:00.000+0000",
    class="hl-string">"output_file": class="hl-string">"problem_management_event_log.csv",
    class="hl-string">"batch_size": 1000
}

class=class="hl-string">"hl-comment"># Status Map (Standard BMC Helix PBM Status values)
STATUS_MAP = {
    class="hl-string">"Draft": class="hl-string">"Problem Record Logged",
    class="hl-string">"Under Investigation": class="hl-string">"Investigation Commenced",
    class="hl-string">"Root Cause Identified": class="hl-string">"Root Cause Identified",
    class="hl-string">"Solution Database": class="hl-string">"Solution Database Updated",
    class="hl-string">"Solution Implemented": class="hl-string">"Resolution Verified",
    class="hl-string">"Completed": class="hl-string">"Resolution Verified",
    class="hl-string">"Rejected": class="hl-string">"Problem Record Cancelled",
    class="hl-string">"Cancelled": class="hl-string">"Problem Record Cancelled",
    class="hl-string">"Closed": class="hl-string">"Problem Record Closed"
}

class=class="hl-string">"hl-comment"># Global Session
session = requests.Session()

def login():
    url = fclass="hl-string">"{CONFIG['base_url']}/jwt/login"
    headers = {class="hl-string">"Content-Type": class="hl-string">"application/x-www-form-urlencoded"}
    data = {
        class="hl-string">"username": CONFIG[class="hl-string">"username"],
        class="hl-string">"password": CONFIG[class="hl-string">"password"]
    }
    response = session.post(url, headers=headers, data=data)
    if response.status_code == 200:
        session.headers.update({class="hl-string">"Authorization": fclass="hl-string">"AR-JWT {response.text}"})
        print(class="hl-string">"Authentication successful.")
    else:
        raise Exception(fclass="hl-string">"Login failed: {response.text}")

def fetch_records(form_name, fields, query_string):
    all_entries = []
    offset = 0
    
    while True:
        url = fclass="hl-string">"{CONFIG['base_url']}/entry/{form_name}"
        params = {
            class="hl-string">"q": query_string,
            class="hl-string">"fields": fclass="hl-string">"values({','.join(fields)})",
            class="hl-string">"offset": offset,
            class="hl-string">"limit": CONFIG[class="hl-string">"batch_size"],
            class="hl-string">"useLabels": class="hl-string">"true"
        }
        
        resp = session.get(url, params=params)
        if resp.status_code != 200:
            print(fclass="hl-string">"Error fetching data: {resp.text}")
            break
            
        data = resp.json()
        entries = data.get(class="hl-string">'entries', [])
        if not entries:
            break
            
        for entry in entries:
            all_entries.append(entry[class="hl-string">'values'])
            
        offset += len(entries)
        print(fclass="hl-string">"Fetched {len(all_entries)} records from {form_name}...")
        
    return all_entries

def generate_event_log():
    class=class="hl-string">"hl-comment"># 1. Fetch Main Problem Records
    print(class="hl-string">"Fetching Problem Investigations...")
    pbm_fields = [
        class="hl-string">"Problem ID", class="hl-string">"Submit Date", class="hl-string">"Last Modified Date", class="hl-string">"Status", 
        class="hl-string">"Assigned Group", class="hl-string">"Priority", class="hl-string">"Problem Coordinator", 
        class="hl-string">"Description", class="hl-string">"Workaround", class="hl-string">"Investigation Driver"
    ]
    class=class="hl-string">"hl-comment"># Query syntax: class="hl-string">'Submit Date' > class="hl-string">"start_date"
    pbm_query = fclass="hl-string">"'Submit Date' > \"{CONFIG[class="hl-string">'start_date']}\class="hl-string">""
    
    problems = fetch_records(class="hl-string">"PBM:Problem Investigation", pbm_fields, pbm_query)
    
    event_log = []
    
    class=class="hl-string">"hl-comment"># Map of Problem ID to attributes for enrichment
    pbm_lookup = {}

    for p in problems:
        pid = p.get(class="hl-string">"Problem ID")
        pbm_lookup[pid] = p
        
        class=class="hl-string">"hl-comment"># Event 1: Problem Record Logged (Creation)
        event_log.append({
            class="hl-string">"ProblemRecord": pid,
            class="hl-string">"Activity": class="hl-string">"Problem Record Logged",
            class="hl-string">"EventTime": p.get(class="hl-string">"Submit Date"),
            class="hl-string">"SupportGroup": p.get(class="hl-string">"Assigned Group"),
            class="hl-string">"Priority": p.get(class="hl-string">"Priority"),
            class="hl-string">"ProblemCoordinator": p.get(class="hl-string">"Problem Coordinator"),
            class="hl-string">"SourceSystem": class="hl-string">"BMC Helix ITSM",
            class="hl-string">"LastDataUpdate": datetime.now().isoformat()
        })

    class=class="hl-string">"hl-comment"># 2. Fetch Audit Logs / History
    class=class="hl-string">"hl-comment"># Note: Fetching PBM:AuditLogSystem or PBM:Problem Investigation_AuditLog
    class=class="hl-string">"hl-comment"># We filter by the Problem IDs we just fetched to optimize
    print(class="hl-string">"Fetching Audit Logs...")
    
    class=class="hl-string">"hl-comment"># In a real scenario, chunk this query if too many IDs, here simplified
    class=class="hl-string">"hl-comment"># We look for field changes relevant to our activities
    audit_fields = [class="hl-string">"Original Request ID", class="hl-string">"Fields Changed", class="hl-string">"Log Date", class="hl-string">"User", class="hl-string">"New Value"]
    
    class=class="hl-string">"hl-comment"># Iterate through problems to get history (Alternative: fetch bulk audit if API allows complex ORs)
    class=class="hl-string">"hl-comment"># For this script, we assume we fetch audit based on the main form query logic mapping
    class=class="hl-string">"hl-comment"># WARNING: Fetching audit for all records can be slow. 
    
    class=class="hl-string">"hl-comment"># For demonstration, we simulate fetching audit entries. 
    class=class="hl-string">"hl-comment"># In production, query class="hl-string">'PBM:Problem Investigation_AuditLog' where class="hl-string">'Original Request ID' IN (...)
    
    class=class="hl-string">"hl-comment"># Placeholder for audit data retrieval logic
    class=class="hl-string">"hl-comment"># Simulating a loop over retrieved problems to get their specific audit trails
    class=class="hl-string">"hl-comment"># This is a logical representation; in high volume, use a bulk export method
    
    for p in problems:
        pid = p.get(class="hl-string">"Problem ID")
        
        class=class="hl-string">"hl-comment"># Query specific audit form for this problem
        class=class="hl-string">"hl-comment"># Using PBM:Problem Investigation_AuditLog as the standard history container
        audit_query = fclass="hl-string">"'Original Request ID' = \"{pid}\class="hl-string">""
        class=class="hl-string">"hl-comment"># We only need specific fields changed
        audit_entries = fetch_records(class="hl-string">"PBM:Problem Investigation_AuditLog", audit_fields, audit_query)
        
        for audit in audit_entries:
            fields_changed = audit.get(class="hl-string">"Fields Changed", class="hl-string">"")
            new_val = audit.get(class="hl-string">"New Value", class="hl-string">"")
            log_date = audit.get(class="hl-string">"Log Date")
            
            activity = None
            
            class=class="hl-string">"hl-comment"># Map Fields to Activities
            if class="hl-string">"Status" in fields_changed:
                class=class="hl-string">"hl-comment"># Map status string to activity
                activity = STATUS_MAP.get(new_val)
                
            elif class="hl-string">"Assigned Group" in fields_changed:
                activity = class="hl-string">"Assigned to Support Group"
                
            elif class="hl-string">"Workaround" in fields_changed:
                activity = class="hl-string">"Workaround Defined"
                
            elif class="hl-string">"Problem Coordinator" in fields_changed:
                activity = class="hl-string">"Coordinator Reassigned"
                
            elif class="hl-string">"Infrastructure Change ID" in fields_changed or class="hl-string">"Change Request" in fields_changed:
                activity = class="hl-string">"Change Request Initiated"
                
            elif class="hl-string">"Known Error" in fields_changed:
                activity = class="hl-string">"Known Error Promoted"

            class=class="hl-string">"hl-comment"># PIR Inference: If status moves to class="hl-string">'Closed' and PIR task exists (simplified here to Status)
            if activity == class="hl-string">"Problem Record Closed" and p.get(class="hl-string">"PIR Required") == class="hl-string">"Yes":
                 class=class="hl-string">"hl-comment"># Insert PIR event just before close if not explicitly found
                 event_log.append({
                    class="hl-string">"ProblemRecord": pid,
                    class="hl-string">"Activity": class="hl-string">"Post-Implementation Review Conducted",
                    class="hl-string">"EventTime": log_date, class=class="hl-string">"hl-comment"># Same time as close for this logic
                    class="hl-string">"SupportGroup": p.get(class="hl-string">"Assigned Group"),
                    class="hl-string">"SourceSystem": class="hl-string">"BMC Helix ITSM",
                    class="hl-string">"LastDataUpdate": datetime.now().isoformat()
                })

            if activity:
                event_log.append({
                    class="hl-string">"ProblemRecord": pid,
                    class="hl-string">"Activity": activity,
                    class="hl-string">"EventTime": log_date,
                    class="hl-string">"SupportGroup": p.get(class="hl-string">"Assigned Group"), class=class="hl-string">"hl-comment"># Use current or historical if parsed
                    class="hl-string">"Priority": p.get(class="hl-string">"Priority"),
                    class="hl-string">"ProblemCoordinator": p.get(class="hl-string">"Problem Coordinator"),
                    class="hl-string">"SourceSystem": class="hl-string">"BMC Helix ITSM",
                    class="hl-string">"LastDataUpdate": datetime.now().isoformat()
                })

    class=class="hl-string">"hl-comment"># Convert to DataFrame
    df = pd.DataFrame(event_log)
    
    class=class="hl-string">"hl-comment"># Sorting
    if not df.empty:
        df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'])
        df = df.sort_values(by=[class="hl-string">'ProblemRecord', class="hl-string">'EventTime'])
        
        class=class="hl-string">"hl-comment"># Export
        df.to_csv(CONFIG[class="hl-string">'output_file'], index=False)
        print(fclass="hl-string">"Extraction complete. Data saved to {CONFIG['output_file']}")
    else:
        print(class="hl-string">"No events extracted.")

if __name__ == class="hl-string">"__main__":
    try:
        login()
        generate_event_log()
    except Exception as e:
        print(fclass="hl-string">"An error occurred: {e}")

您的问题管理 Data 模板

您的问题管理 Data 模板

问题管理属性

问题管理活动

提取指南

BMC Helix AR System 报表控制台导出

步骤

配置

a 查询示例 config

对 AR System 数据库视图直接进行 SQL 查询

步骤

配置

a 查询示例 sql

通过 AR System REST API 进行 Python 提取

步骤

配置

a 查询示例 python

准备好开始了吗？

立即解决问题管理瓶颈

您的问题管理 Data 模板

您的问题管理 Data 模板

问题管理属性

问题管理活动

提取指南

BMC Helix AR System 报表控制台导出

步骤

配置

a 查询示例 config

对 AR System 数据库视图直接进行 SQL 查询

步骤

配置

a 查询示例 sql

通过 AR System REST API 进行 Python 提取

步骤

配置

a 查询示例 python

我们重视您的隐私

准备好开始了吗？

立即解决问题管理瓶颈