> 継続的なプロセス改善 > サービスリクエスト管理 > `BMC Helix ITSM` > データテンプレート

サービスリクエスト管理データテンプレート

BMC Helix ITSM

サービスリクエスト管理における属性 (21) サービスリクエスト管理におけるアクティビティ (14) 抽出ガイド (3)

サービスリクエスト管理データテンプレート

このテンプレートは、サービスリクエスト管理プロセスにおいて収集すべき必須データ属性と、追跡すべき主要アクティビティの明確な概要を提供します。さらに、BMC Helix ITSM からこのデータを効率的に抽出するための実践的なガイダンスも含まれています。このリソースを活用し、データ準備を効率化し、自信を持ってプロセスマイニングを開始してください。

収集を推奨する項目
追跡すべき主要アクティビティ
BMC Helix ITSMのデータ抽出ガイド

イベントログについて初めての方へ：プロセスマイニングのイベントログ作成方法.

テンプレートをダウンロード

サービスリクエスト管理における属性

これらのデータフィールドは、包括的なイベントログを作成し、貴社のサービスリクエスト管理プロセスを深く分析するために不可欠です。

5 必須 6 推奨 10 任意

	名前	説明
	アクティビティ ActivityName	サービスリクエストのライフサイクル内で、ある時点で発生した特定の`イベント`またはタスクの名前。
説明この属性は、サービスリクエストプロセスにおける特定のステップやステータス変更を記述します。例えば、「リクエストレビュー中」、「対応進行中」、「サービスリクエスト解決済み」などです。各アクティビティは、サービスリクエストのエンドツーエンドのプロセスにおける単一のイベントを表します。アクティビティの順序と頻度を分析することは、プロセスマイニングの中核です。これにより、プロセスマップの発見、ボトルネックの特定、およびプロセスバリアントの分析が可能になります。どの活動が、どのような順序で、どれくらいの頻度で発生するかを理解することは、プロセス最適化にとって極めて重要です。その重要性活動はプロセスマップの構成要素です。これを追跡することで、プロセスフローの可視化と分析が可能となり、実際の作業遂行状況が明らかになります。取得元これは通常、「SRM:Request」フォームまたは関連する対応アプリケーションログ（例：インシデント、作業指示）の「ステータス」および「ステータス理由」フィールドの変更から導出されます。例承認待ちリクエスト履行進行中サービスリクエスト解決済みサービスリクエストクローズ済み
	サービスリクエストID ServiceRequestId	各サービスリクエストを一意に識別するもので、そのライフサイクル全体を追跡するための主キーとして機能します。
説明サービスリクエストID は、ユーザーまたはシステムから提出された個々のサービスリクエストを一意に識別するものです。これは、初期ログから最終的なクローズまでのすべての関連イベントを結びつける中心的な役割を果たし、各サービスリクエストのライフサイクルを完全にエンドツーエンドで分析することを可能にします。プロセスマイニングにおいて、この ID は各ケースのアクティビティの順序を再構築する上で不可欠です。これによりツールは、「リクエスト提出済み」、「リクエスト割り当て済み」、「サービスリクエストクローズ済み」といった関連するすべてのイベントを単一のプロセスインスタンスとしてグループ化でき、あらゆるプロセス分析の基盤となります。その重要性これは基本的なケース識別子です。これがなければ、サービスリクエストのエンドツーエンドのプロセスを追跡することは不可能となり、プロセスの発見と分析は行えません。取得元これは通常、BMC Helix ITSM の「SRM:Request」フォームにおける「InstanceId」または「リクエスト番号」フィールドを指します。例 SR000010572931SR000010572932SR000010572933
	開始時刻 EventStartTime	特定のアクティビティまたはイベントが開始されたことを示すタイムスタンプです。
説明この属性は、あるアクティビティが開始された正確な日時を記録します。初期提出から最終クローズまでのイベントログ内のすべてのイベントには、プロセスの時系列順序を確立するために開始時間が必要です。このタイムスタンプは、時間ベースのすべてのプロセスマイニング分析にとって不可欠です。サイクルタイム、アクティビティの期間、ステップ間の待機時間を計算し、SLA 遵守をチェックするために使用されます。これにより、ボトルネックの発見や、時間の経過に伴うプロセスパフォーマンスの分析が可能になります。その重要性開始時間はイベントの時系列順序を示すため、プロセス期間の計算、遅延の特定、およびプロセス全体のタイムラインを把握する上で不可欠です。取得元これは、「SRM:Request」フォームに関連付けられた監査ログまたはステータス履歴テーブルのタイムスタンプフィールドに対応します。例えば、初期イベントの「提出日」などがこれに該当します。例 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
	ソースシステム SourceSystem	`データ`が`抽出`された`システム`を`特定`します。
説明この属性は、プロセスデータの発生源を示します。このビューでは、すべてのサービスリクエスト関連イベントがこのシステムから取得されたことを示すため、静的に「BMC Helix ITSM」と設定されます。複数の統合システムがある環境では、このフィールドはデータのリネージを理解し、ソースに基づいてデータをパーティショニングするために不可欠です。これにより、特に異なるプラットフォームからのデータを統合する際に、データの明確性と追跡可能性が保証されます。その重要性データガバナンス、トレーサビリティ、およびマルチシステム環境でのトラブルシューティングにおいて重要な、データの発生源に関するコンテキストを提供します。取得元これは、データ抽出および変換プロセス中に付加される静的な値であり、BMC Helix ITSM 自体のフィールドではありません。例 `BMC Helix ITSM`
	最終データ更新 LastDataUpdate	このプロセスデータが、ソースシステムから最後に更新された際のタイムスタンプです。
説明この属性は、BMC Helix ITSM からの最新のデータ抽出日時を示します。これによりユーザーは、分析対象データの鮮度に関するコンコンテキストを把握し、分析がカバーする期間を明確に認識できます。これは、あらゆるプロセスマイニングのダッシュボードや分析にとって不可欠なメタデータ属性です。ユーザーは、インサイトがほぼリアルタイムのデータに基づいているのか、それとも過去のスナップショットに基づいているのかを理解でき、導き出される結論の妥当性と関連性に影響を与えます。その重要性データの鮮度をユーザーに知らせることで、最新のプロセスパフォーマンス情報に基づいた意思決定を行うために不可欠な情報を提供します。取得元このタイムスタンプは、データ抽出および読み込みプロセス中に生成され、追加されます。例 2024-05-21T08:00:00Z
	サービスタイプ ServiceType	ユーザーからリクエストされたサービスのカテゴリまたは種類です。
説明サービスタイプは、リクエストの性質を分類するものです。例えば、「新規ソフトウェアリクエスト」、「パスワードリセット」、「新規従業員オンボーディング」などがあり、プロセスデータをフィルタリングし、セグメント化するための基本的な要素となります。プロセス分析において、この属性は異なる種類のリクエストのパフォーマンスを比較するために用いられます。「どのサービスタイプが解決に最も時間がかかっているか」や「どのサービスタイプで再作業が最も多いか」といった問いに答えるのに役立ち、解決時間とSLAコンプライアンスのダッシュボードにとって極めて重要です。その重要性サービスリクエストをセグメント化することで、プロセスフローの比較、タイプ固有の問題の特定、そして最適化の取り組みの効果的な調整が可能になります。取得元このデータは、「SRM:Request」フォームの「タイトル」または分類フィールドによく見られ、サービスカタログで選択されたサービスから派生します。例新規ハードウェアリクエストソフトウェアアクセスリクエストVPNアクセス設定
	リクエストステータス RequestStatus	イベント発生時点でのサービスリクエストのステータスです。例として「処理中」、「保留中」、「クローズ済み」などがあります。
説明この属性は、サービスリクエストのライフサイクルにおける様々な時点での状態を捉えます。ステータスは各アクティビティのコンテキストを提供し、しばしば「アクティビティ」属性自体が派生する源となります。ステータス別に分析することで、「顧客保留中」や「承認待ち」といった特定の状態でリクエストがどれくらいの時間を費やしているかを理解するのに役立ちます。これは、外部要因や内部キューによるボトルネックや遅延を特定するために不可欠であり、「ボトルネック特定」ダッシュボードを直接サポートします。その重要性リクエストの状態のスナップショットを提供することで、待機状態と活動状態に費やされた時間の分析を可能にし、ボトルネックの特定に不可欠です。取得元これは、「SRM:Request」フォームの「ステータス」フィールドです。履歴値は監査ログで確認できます。例計画進行中保留中解決済みクローズ
	優先度 Priority	サービスリクエストに割り当てられた優先度レベルです。ビジネスへの影響度と緊急性を示します。
説明優先度は、リクエストが処理される順序と速度を決定します。一般的な値には、「緊急」、「高」、「中」、「低」などがあります。このアサインメントは、多くの場合、リクエストがビジネスに与える影響とその緊急性の組み合わせに基づいて決定されます。優先度別に分析することは、高優先度のリクエストが低優先度のリクエストよりも迅速に処理されているかを評価するために不可欠です。これは、解決時間とSLA遵守率のダッシュボードにおける重要なディメンションであり、最も重要なビジネスニーズに対してリソースが適切に割り当てられていることを確認するのに役立ちます。その重要性プロセスが作業を適切に優先順位付けし、異なるビジネスインパクトレベルのリクエストに対して期待されるサービスレベルを満たしているかを評価するのに役立ちます。取得元これは、「SRM:Request」フォームの「優先度」フィールドです。例クリティカル高中低
	担当チーム AssignedTeam	現在、サービスリクエストに割り当てられているサポートグループまたはチームです。
説明この属性は、「ヘルプデスク」、「ネットワークチーム」、「データベース管理」など、リクエストの処理を担当する機能グループを特定します。このフィールドの変更は、チーム間の責任の移管を示します。割り当てられたチームに基づく分析は、チームレベルでのボトルネックの特定、チーム間の引き継ぎの分析、および様々なサポートグループの効率評価に役立ちます。「リクエストの再作業と再割り当て」および「トリアージ効率」ダッシュボードにとって重要であり、組織内で作業がどのようにルーティングされているかのパターンを明らかにします。その重要性異なる機能グループ間のプロセスフロー分析を可能にし、ルーティングの非効率性を特定し、チームレベルのパフォーマンスを測定するのに役立ちます。取得元これは、サービスリクエストに関連付けられた履行レコード（例：作業指示、インシデント）の「割り当てグループ」フィールドに対応します。例サービスデスクインフラストラクチャサポートアプリケーションサポート Tier 2
	担当者 AssignedAgent	現在、サービスリクエストの作業を担当している個別のユーザー（担当者）です。
説明この属性は、特定の時点においてリクエストを担当する特定の IT エージェントまたはサポートスタッフメンバーを識別します。単一のリクエストのライフサイクルにおけるこのフィールドの変更は、引き継ぎまたは再割り当てを示します。この属性は、エージェントのパフォーマンスとワークロード分析にとって非常に重要です。各エージェントが処理するリクエスト数、平均解決時間、および再割り当ての頻度を追跡できます。このデータは、リソース管理やトレーニング機会の特定を支援します。その重要性割り当てられたエージェントを追跡することは、引き継ぎの分析、個々のパフォーマンス測定、およびサポートチーム全体のワークロード分布を理解するために不可欠です。取得元これは、サービスリクエストに関連付けられた履行レコード（例：作業指示、インシデント）の「担当者」または「割り当て先」フィールドに対応します。例 Bob SmithAlice JohnsonCharlie Brown
	終了日時 EventEndTime	特定のアクティビティ／イベントが完了したタイムスタンプ。
説明終了時間は、あるアクティビティの完了を示します。ITSM システム内の多くのアクティビティは瞬時のステータス変更ですが、中には測定可能な期間を持つものもあります。終了時間があれば、このようなアクティビティの期間を正確に算出できます。分析において、終了時間は開始時間と組み合わせて個々のアクティビティの処理時間を計算するために使用されます。これにより、アクティビティ間の待機時間だけでなく、どの特定のタスクがプロセス内で最も時間を費やしているかを正確に特定するのに役立ちます。その重要性活動の処理時間計算を可能にし、非効率なステップの特定や、リソースがどこに時間を費やしているかを理解するために不可欠です。取得元これは導出可能です。あるアクティビティの終了時間は、多くの場合、同じケースにおける次のシーケンシャルなアクティビティの開始時間となります。最終アクティビティについては、解決またはクローズのタイムスタンプが該当します。例 2023-10-26T10:05:15Z2023-10-26T11:45:10Z2023-10-28T09:00:00Z
	SLA目標日 SlaTargetDate	サービスレベルアグリーメント（SLA）に基づき、サービスリクエストが解決されるべきとされている日時です。
説明 SLA目標日は、サービスリクエストの完了期限を示す計算されたタイムスタンプです。これは、リクエストの優先度やタイプなどの要素を考慮したサービス契約ルールによって決定されます。この属性は、「SLAコンプライアンス概要」ダッシュボードの基礎となります。実際の解決時間を測定する際のベンチマークとして機能し、最終的な解決アクティビティの「EventEndTime」とこの目標日を比較することで、サービスコミットメントが達成されたかどうかを判断できます。その重要性これは、コミットメントに対するサービスパフォーマンスを測定する主要なベンチマークであり、SLAコンプライアンスのモニタリングとレポート作成に不可欠です。取得元この日付はサービスレベル管理（SLM）モジュールによって計算・保存され、サービスリクエストにリンクされた関連 SLM フォームで確認できます。例 2023-10-28T17:00:00Z2023-11-01T09:00:00Z2023-10-27T12:00:00Z
	SLA違反 IsSlaBreached	サービスリクエストがSLA目標日を過ぎてから解決されたかどうかを示すブール値フラグです。
説明この計算フラグは、サービスリクエストの最終解決タイムスタンプが「SLA目標日」よりも遅い場合に true と設定されます。これは、リクエストごとの SLA パフォーマンスについて、シンプルな二値の結果を提供します。この属性は、「SLAコンプライアンス概要」ダッシュボードおよび「SLA順守率 KPI」にとって不可欠です。これにより、全体の順守率を簡単に集計でき、SLA 違反リクエストと順守リクエストのプロセス特性を分析するためのフィルタリングが可能になり、SLA 失敗の根本原因の特定に役立ちます。その重要性タイムスタンプの比較をシンプルなブール値フラグに変換することでSLAパフォーマンス分析を簡素化し、遵守率の測定と可視化を容易にします。取得元これは計算フィールドです。ロジックは「解決タイムスタンプ」が「SlaTargetDate」より大きい場合 `true`、それ以外は `false` となります。例 truefalse
	エスカレート済み IsEscalated	サービスリクエストがエスカレーションされたかどうかを示すブール値フラグです。
説明このフラグは、サービスリクエストが機能的または階層的なエスカレーションを経た場合に true と設定されます。エスカレーションは通常、リクエストが期待通りに進まない場合、SLA違反の危機にある場合、または承認や対応に上位の権限が必要な場合に発生します。この属性は、「リクエストエスカレーション効率分析」ダッシュボードにとって重要です。エスカレーションされたリクエストのプロセスパスをフィルタリングおよび分析し、何がトリガーになっているのか、エスカレーション後に解決までどれくらい時間がかかるのか、そしてエスカレーションプロセスがどれほど効果的であるかを理解するのに役立ちます。その重要性エスカレーションを必要としたリクエストのサブセットを分離し分析することで、標準プロセスの弱点や複雑な問題の引き金となる要因を特定するのに役立ちます。取得元これは通常、単一のフィールドではありません。監査ログ内の特定のエスカレーション関連アクティビティ、あるいはエスカレーションプロトコルに従う優先度または割り当ての変更を確認することで導出されます。例 truefalse
	クローズコード CloseCode	サービスリクエストの最終的な結果、またはクローズ理由を示すコードです。
説明クローズコードは、サービスリクエストの解決方法を標準的に分類するものです。例えば、「サービスデスクによる解決」、「ユーザーによるキャンセル」、「重複リクエスト」などがあります。クローズコードを分析することで、リクエストの一般的な結末を把握できます。例えば、ユーザーによるキャンセルが多い場合はプロセスの長期化、多くの重複はシステムまたはコミュニケーションの問題を示唆する可能性があります。この属性は「解決カテゴリの正確性」ダッシュボードをサポートします。その重要性リクエストの結果に関する構造化データを提供し、解決の有効性や未完了・キャンセルの理由分析を可能にします。取得元この情報は、サービスリクエストに関連付けられた対応チケットの「解決」または「クローズコード」フィールドで通常確認できます。例成功ユーザーによるキャンセル不要自動解決
	サイクルタイム CycleTime	サービスリクエストの作成から最終解決までに経過した総時間です。
説明サイクルタイムは、エンドツーエンド期間とも呼ばれ、サービスリクエストの総存続期間を測定します。これは、最初のイベント（例：「サービスリクエスト提出済み」）のタイムスタンプと、最後の解決イベント（例：「サービスリクエスト解決済み」）のタイムスタンプとの差として計算されます。これはプロセスマイニングにおける最も基本的なKPIの一つであり、サービスリクエスト解決時間ダッシュボードを直接サポートします。平均サイクルタイムを分析し、サービスタイプや優先度といったディメンションで細分化することで、プロセスの全体的な効率が明らかになり、時間を要しすぎている領域が浮き彫りになります。その重要性これはプロセス効率の主要な指標です。サイクルタイムを理解し、削減することは、プロセス改善活動の重要な目標となることがよくあります。取得元これは計算指標です。各固有のサービスリクエスト ID に対して、「クローズ日」または「解決日」から「提出日」を差し引くことで導出されます。例 2日4時間8 hours 30 minutes15日間
	依頼者部門 RequestorDepartment	リクエストを提出したユーザーの所属部署または部門です。
説明この属性は、サービスを要求している個人の所属部署（例：「財務」、「人事」、「IT」など）を特定します。この情報は通常、システム内のユーザープロファイルから取得されます。プロセス分析を部署別にセグメント化することで、部署固有のニーズ、リクエストパターン、およびターゲットを絞ったトレーニングやサービス改善の潜在的な領域を特定できます。「財務部門は他の部署に比べてリクエストの待機時間が長いのか」といった問いに答えることも可能です。その重要性事業部門ごとのサービス消費とプロセスパフォーマンスの分析を可能にし、部門固有の問題や傾向を浮き彫りにすることができます。取得元この情報は通常、「SRM:Request」フォームの「依頼元」ユーザーに関連付けられたユーザーのプロファイルから取得されます。例財務営業人事情報技術
	受付チャネル SubmissionChannel	サービスリクエストが提出された方法、またはチャネル（経路）です。
説明この属性は、サービスリクエストがどのように開始されたか（例：セルフサービスポータル、Eメール、サービスデスクへの電話、自動システムアラートなど）を記録します。異なるチャネルは、異なるプロセスバリアントや解決時間につながる可能性があります。提出チャネル別にプロセスを分析することで、特定の受付方法に関連する非効率性やベストプラクティスを明らかにできます。例えば、セルフサービスポータル経由で提出されたリクエストは、初期データの品質が優れているためより迅速に解決される可能性がありますが、Eメールからのリクエストはより多くの手動トリアージを必要とする場合があります。その重要性受付方法がプロセス効率、データ品質、全体的なサイクルタイムにどのように影響するかを理解するのに役立ち、特定のチャネルにおける的を絞った改善を可能にします。取得元これは、「SRM:Request」フォームや関連する履行チケットの「クライアントタイプ」または「報告元」といったフィールドから推測できることがよくあります。例セルフサービスポータルメール電話番号システム生成
	引き継ぎ回数 HandoffCount	サービスリクエストが、異なるエージェントまたはチーム間で再割り当てされた合計回数です。
説明この計算指標は、単一のサービスリクエストに対して「AssignedAgent」または「AssignedTeam」が変更された回数をカウントします。引き継ぎ回数が多い場合、プロセスの分断、初回解決率の低さ、または非効率なルーティングを示唆する可能性があります。この属性は「リクエストあたりの平均エージェント引き継ぎ回数 KPI」の基礎となり、「リクエストの再作業と再割り当て」ダッシュボードで使用されます。引き継ぎ回数の多いケースを分析することで、トリアージの改善、より良いトレーニングの提供、または解決プロセスの合理化を通じて、遅延を削減し、顧客満足度を向上させる機会を発見できます。その重要性プロセスの断片化とコミュニケーションのオーバーヘッドを測定します。引き継ぎ回数が多いことは、多くの場合、解決時間の長期化とプロセス効率の低下に関連しています。取得元これは、各固有のサービスリクエスト ID における「AssignedAgent」または「AssignedTeam」属性の異なる値の数をカウントすることで導出される計算指標です。例 0135
	手戻り IsRework	サービスリクエストが前の段階に戻るなどの手戻りを経験したかどうかを示すブール値フラグです。
説明このフラグは、プロセスフロー内でループや再作業が発生したサービスリクエストを識別します。例えば、「対応進行中」から「リクエストレビュー中」に戻るリクエストは再作業とみなされます。正確な定義は、ビジネスプロセスのロジックに依存します。この属性は、「リクエスト再作業および再割り当て分析」ダッシュボードと「リクエスト再作業率 KPI」を直接サポートします。再作業の頻度を定量化し、初期評価の誤りや情報不足など、プロセスの非効率性につながる一般的な原因を分析するのに役立ちます。その重要性「ハッピーパス」から逸脱するケースにフラグを立てることでプロセス非効率性を定量化し、ループや繰り返しの作業の根本原因を特定するのに役立ちます。取得元これは、イベントログにおけるアクティビティの順序から導出される計算属性です。プロセスフロー内の逆行を検出するためのロジックが必要です。例 truefalse
	解決カテゴリ ResolutionCategory	リクエスト解決のために提供されたソリューションの分類です。
説明この属性は、「ソフトウェア修正」、「ユーザー研修」、「データ修正」など、リクエストがどのように解決されたかについて構造的に分類するものです。これは単なるクローズコードではなく、解決の性質を詳しく記述します。「解決カテゴリの正確性」ダッシュボードにとって不可欠であり、初期のサービスタイプと比較して一貫性を確認できます。解決カテゴリを分析することで、問題の傾向を特定し、プロアクティブな問題管理に役立ちます。例えば、多くのリクエストがユーザー研修で解決されているといったケースです。その重要性ソリューションの性質に関する洞察を提供し、再発する問題の傾向や、プロアクティブな問題管理、あるいはユーザー研修の機会を特定するのに役立ちます。取得元この情報は、対応チケットの運用および製品分類フィールドの一部であり、多くの場合「解決カテゴリ」とラベル付けされています。例アカウント管理ハードウェア障害ソフトウェアアップグレード情報提供済み

必須推奨任意

サービスリクエスト管理におけるアクティビティ

正確なプロセスディスカバリと可視化のために、これらの主要なプロセスステップとマイルストーンをイベントログに記録する必要があります。

6 推奨 8 任意

	アクティビティ	説明
	サービスリクエストキャンセル済み	サービスリクエストは、対応が完了する前に依頼者またはサービスデスクによって取り下げられました。これは、リクエストの最終状態となります。
その重要性キャンセルを追跡することは、ユーザーが誤ったリクエストを提出する、またはサービスが不要になるなどのパターンを特定するのに役立ち、サービスカタログの改善に活用できます。取得元 `SRM:Request`フォームのステータスが「Canceled」（キャンセル済み）に変更されたことから推測されます。取得 SRM:Request の「ステータス」フィールドが「キャンセル済み」に変化した更新イベントのタイムスタンプ。イベントタイプ inferred
	サービスリクエストクローズ済み	サービスリクエストは正式にクローズされ、読み取り専用のアーカイブ状態に移行します。これは、問題が解決し、確認期間が経過した後に発生するものです。
その重要性このアクティビティは、プロセスの決定的な終了を示します。「解決済み」と「クローズ済み」の間の時間差は、クローズ手順における非効率性を浮き彫りにすることがあります。取得元 `SRM:Request`フォームの最終ステータスが「Closed」（クローズ済み）に変化したことから推測されます。取得 SRM:Request の「ステータス」フィールドが「クローズ済み」に変化した更新イベントのタイムスタンプ。イベントタイプ inferred
	サービスリクエスト提出済み	このアクティビティは、ユーザーによる新規サービスリクエストの作成と提出を意味します。SRM:Request フォームに初期ステータス（通常「提出済み」）で新しいエントリが作成された際に記録されます。
その重要性これは、すべてのサービスリクエストケースの開始点であり、総ライフサイクル期間の測定とリクエスト受付量の分析に不可欠です。取得元このイベントは、SRM:Request フォーム内のレコードの作成タイムスタンプと初期ステータス（例：「提出済み」）から推測されます。取得ステータスが「Submitted」（提出済み）の場合、`SRM:Request`フォームで新しいサービスリクエストIDの作成タイムスタンプを特定します。イベントタイプ inferred
	サービスリクエスト解決済み	サービスリクエストの対応が完了し、その解決策が依頼者に通知されました。リクエストは最終確認を待つか、あるいは一定期間後に自動的にクローズされます。
その重要性サービス提供サイクルの終わりを示す重要なマイルストーンです。これは、解決時間とSLA遵守を測定するための主要な終点となります。取得元 `SRM:Request`フォームのステータスが「Resolved」（解決済み）または「Completed」（完了済み）に変更されたことから推測されます。取得 SRM:Request の「ステータス」フィールドが「解決済み」または「完了」に変化した更新イベントのタイムスタンプ。イベントタイプ inferred
	リクエストがアサインされた	サービスリクエストは、作業の完了を担当する特定のエージェントまたはチームに割り当てられました。これは、トリアージフェーズの終了を示します。
その重要性このマイルストーンは、トリアージ時間の測定とエージェントのワークロード分析にとって極めて重要です。頻繁な再割り当ては、ルーティングの問題やスキルギャップを示唆する可能性があります。取得元このイベントは、SRM:Request または関連する対応アプリケーションフォーム（例：WOI:WorkOrder）の「割り当てグループ」または「担当者」フィールドの監査ログから明示的に取得できます。取得監査ログからのタイムスタンプで、「担当者」フィールドに初めて NULL ではない値が設定されたことを示します。イベントタイプ explicit
	履行進行中	割り当てられたエージェントまたはチームが、サービスリクエストの対応を本格的に開始しました。これは、リクエストがキューから実際の作業段階へと移行したことを意味します。
その重要性付加価値のある履行作業の開始を示します。このフェーズに費やされた時間を分析することで、リソースの生産性と履行の複雑さを理解するのに役立ちます。取得元 `SRM:Request`フォームのステータスが「In Progress」（進行中）に変更されたことから推測されます。取得 SRM:Request の「ステータス」フィールドが「処理中」に変化した更新イベントのタイムスタンプ。イベントタイプ inferred
	ユーザーからの情報要求	担当エージェントは、作業を進めるために依頼者からの追加情報を必要としています。この際、リクエストは通常「保留中」の状態となります。
その重要性このアクティビティは、「外部情報待機時間」を算出するために極めて重要であり、不完全な情報が原因でリクエストがどれくらいの頻度で停滞しているかを特定します。取得元 `SRM:Request`フォームのステータスが「Pending」（保留中）となり、その理由が「Customer Hold」（顧客保留）または「Awaiting Information」（情報待ち）であったことから推測されます。取得特定のステータス理由と組み合わされた、「保留中」へのステータス変更のタイムスタンプ。イベントタイプ inferred
	ユーザーによる解決確認	依頼者が、サービスが満足に提供され、リクエストが解決されたことを正式に確認しました。この確認が、多くの場合、リクエストの最終的なクローズにつながります。
その重要性顧客満足度を明確に示す指標となり、サービス対応を正式に完了させます。これにより、プロセス解決とお客様の承諾が明確に区別されます。取得元このイベントは、ユーザーがポータルまたはEメールを通じて確認した際に、SRM:Request の作業ログまたはアクティビティノートに記録される場合があります。これは必ずしも明確なステータス変更として扱われるとは限りません。取得作業ログ（SRM:WorkInfo）をスキャンし、ユーザーによる確認やアンケート完了を示す特定のエントリを検出します。イベントタイプ explicit
	リクエストが再開された	サービスリクエストは、通常、ユーザーから必要な情報が提供された後、保留中または待機状態から解除されました。担当エージェントによるリクエスト作業が再開されます。
その重要性待機期間の終了を示し、外部での待機時間の正確な測定とSLA遵守への影響を可能にします。取得元 `SRM:Request`のステータスが「Pending」（保留中）から「In Progress」（進行中）に変わった場合に推測されます。取得 SRM:Request の「ステータス」フィールドが「保留中」から「処理中」に変化した更新イベントのタイムスタンプ。イベントタイプ inferred
	リクエストレビュー中	サービスリクエストは、その性質、優先度、および適切な担当チームを判断するため、サービスデスクによる初期レビューとトリアージが行われています。これは通常、リクエストレコードのステータス変更として記録されます。
その重要性このアクティビティを追跡することで、トリアージの効率性を測定し、提出から割り当てまでの遅延を特定できます。これは「平均トリアージ時間」KPIにとって極めて重要です。取得元 `SRM:Request`フォームのステータスが「In Review」（レビュー中）または「Planning」（計画中）のような値に変化したことから推測されます。取得 SRM:Request の「ステータス」フィールドが「レビュー中」に変化した更新イベントのタイムスタンプ。イベントタイプ inferred
	承認待ちリクエスト	サービスリクエストは、指定された承認者または承認グループに提出され、対応を開始する前の承認決定を待っています。これは、コストやアクセス権に関わるリクエストで一般的なステップです。
その重要性このアクティビティは、承認に関する遅延を分離し、承認サイクルタイムの分析や、承認プロセスにおけるボトルネックの特定を可能にします。取得元 `SRM:Request`フォームのステータスが「Waiting Approval」（承認待ち）のような値に変化したことから推測されます。取得 SRM:Request の「ステータス」フィールドが「承認待ち」に変化した更新イベントのタイムスタンプ。イベントタイプ inferred
	申請承認済	サービスリクエストは、必要な関係者によって正式に承認され、その対応プロセスに進むことが許可されました。このイベントは通常「承認待ち」ステータスの後に発生します。
その重要性承認サブプロセスの終了を示し、承認にかかる時間やそれが全体の解決時間に与える影響を追跡するための重要なマイルストーンです。取得元 `SRM:Request`フォームのステータスが「Waiting Approval」（承認待ち）から「Planning」（計画中）または「In Progress」（進行中）のような後続のステータスに変化したことから推測されます。承認決定自体は関連する承認フォームに記録されます。取得肯定的な承認決定後、「承認待ち」ステータスから変更された際のタイムスタンプ。イベントタイプ inferred
	要求却下	サービスリクエストは、承認フェーズ中に却下されました。これは、対応が開始される前にプロセスを停止する最終状態です。
その重要性却下されたリクエストを分析することで、申請の正当性、資格基準、または承認ポリシーにおける問題点が明らかになることがあります。取得元 `SRM:Request`フォームのステータスが「Rejected」（却下済み）に変更されたことから推測されます。取得 SRM:Request の「ステータス」フィールドが「却下済み」に変化した更新イベントのタイムスタンプ。イベントタイプ inferred
	解決策が実装されました	サービスリクエストを完了するために必要な技術的作業は、担当エージェントによって完了しました。リクエストは、正式に解決される前にユーザーとの最終確認を待つ状態です。
その重要性このアクティビティは、技術的な作業完了と正式な解決を区別し、作業完了からユーザー確認までの間の遅延を特定するのに役立ちます。取得元これは、親 SRM:Request が「解決済み」とマークされる前に、バックエンドの対応チケット（例：作業指示のステータスが「完了」になるなど）におけるステータス変更から推測される場合があります。取得 SRM:Request にリンクされたバックエンドチケット（作業指示、インシデントなど）が完了とマークされた際のタイムスタンプ。イベントタイプ inferred

推奨任意

抽出ガイド

BMC Helix ITSMからデータを取得する方法

ステップ

Smart Reportingにアクセス: BMC Helix ITSM環境にログインします。レポートセクションに移動し、Smart Reportingを起動します。バージョンによっては、「Reports」または「Smart Reporting」と表示されている場合があります。
新規レポートの作成: Smart Reportingインターフェースに入ったら、新しいレポートを作成するオプションを選択します。種類として「Report」を選択してください。
データソースとビューの選択: データソースの選択を求められます。主要なARシステムデータソースを選択します。ビューについては、SRM:Requestフォームに基づいていることが多いサービスリクエストビューを検索して選択します。
追加フォームの追加（結合）: ライフサイクル全体をキャプチャするには、メインのSRM:Requestフォームを関連フォームと結合する必要があります。「Data」タブを使用し、以下を結合します。
- SRM:WorkInfo（SR ID+ = Request Numberで結合）して、履行活動とワークログの詳細を取得します。
- AP:Signature（Request = SRInstanceIDで結合）して、承認や却下などの承認関連イベントを取得します。これにはカスタム結合が必要な場合があります。
レポート列の定義: 結合されたフォームから必要なフィールドを「Columns」領域にドラッグ＆ドロップします。これには、SRM:RequestからのRequest Number、Submit Date、Status、Description、Priority、Assigned To、Assigned Groupなどのフィールドと、結合フォームからの関連フィールドが含まれます。
活動用の計算フィールドを作成: この方法の中核は、各活動のタイムスタンプを表す一連の計算フィールドを作成することです。「Data」タブに移動し、各活動について新しい計算フィールドを作成します。例えば：
- 提出タイムスタンプ: Submit Dateフィールドを直接使用します。
- 承認タイムスタンプ: AP:SignatureフォームのSignature Dateを使用します。
- 進行中タイムスタンプ: Request Numberでグループ化されたSRM:WorkInfoのMIN(Submit Date)を使用します。
UNIONのためのレポート構造化: Smart ReportingにはSQLのような単純な「UNION ALL」ボタンはありません。これを実現するには、単一のレポートを作成し、高度な機能またはサブクエリを使用してデータをピボットします。一般的な手法は、各活動のタイムスタンプごとに複数の計算列を作成することです。その後、これらの列を各活動の個別の行に変換するように最終エクスポートをフォーマットする必要があります。
フィルターの適用: データ範囲を制限し、パフォーマンスを向上させるために、レポートにフィルターを追加します。少なくとも、特定の期間を選択するためにSRM:RequestフォームのSubmit Dateでフィルターをかけます。また、マルチテナント環境で運用している場合は、「Company」のフィルターも追加します。
レポートの実行とデータのプレビュー: レポートを実行して、データが正しく取得されていることを確認します。結合が正しいか、列が入力されているか、計算フィールドが期待されるタイムスタンプを返しているかを確認します。
レポートのエクスポート: レポートが検証されたら、データをエクスポートします。プロセス・マイニング・ツールへのインポート用に簡単に処理できるため、エクスポート形式としてCSVまたはMicrosoft Excelを選択します。
最終データ変換: エクスポート後、データをワイド形式（サービスリクエストごとに1行で多数のタイムスタンプ列）からロング形式（活動ごとに1行）に変換する必要があります。スクリプト（例：Python、PowerShell）またはExcel Power Queryのようなツールを使用して、タイムスタンプ列をActivityNameとEventStartTimeの2つの列にアンピボットします。このステップは、必要なイベントログ構造を作成するために不可欠です。

設定

前提条件: BMC Helix ITSMでレポート作成権限（Smart Reportingでのレポート作成と実行アクセスを含む）を持つユーザーアカウントが必要です。また、SRM:Request、SRM:WorkInfo、およびAP:Signatureフォームからデータを読み取る権限も必要です。
主要フォーム: レポートは以下のコアフォームを結合して構築されます。
- SRM:Request: サービスリクエストの主要な詳細を含むメインフォームです。
- SRM:WorkInfo: ワークログエントリを含み、履行活動を導き出すために使用されます。
- AP:Signature: 承認記録を含み、承認関連の活動を追跡するために不可欠です。
日付範囲フィルタリング: SRM:Request.Submit Dateフィールドには常に日付範囲フィルターを適用してください。代表的なサンプル取得とレポートパフォーマンスのバランスを取るため、3〜6ヶ月間のデータ範囲が推奨されます。
重要なフィルター: 日付範囲に加えて、特定の事業体のデータを分離するためにCompanyでフィルターをかけてください。また、プロセス分析に関連しない特定のリクエストタイプやステータス（「下書き」など）を除外することも検討してください。
パフォーマンスに関する考慮事項: 広範な日付範囲で複数のフォームを結合するレポートは、生成に時間がかかる場合があります。大量のデータの場合、オフピーク時間帯にレポートを実行するようスケジュールすることを強くお勧めします。タイムアウトが発生する場合は、抽出をより小さな月ごとのチャンクに分割することを検討してください。

a クエリ例 config

/*
This is a conceptual SQL query representing the logic you would build in the BMC Helix ITSM Smart Reporting UI.
Smart Reporting uses a graphical interface, so you will create this structure by joining forms and creating calculated fields that correspond to each SELECT block below.
The final step of unpivoting data from columns to rows must be done after exporting the report.
*/

-- 1. Service Request Submitted
SELECT
  'Service Request Submitted' AS "ActivityName",
  req."Request Number" AS "ServiceRequestId",
  req."Submit Date" AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType", -- Or another field representing the service
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:Request" AS req
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'

UNION ALL

-- 2, 3, 4, 14: Approval Steps (Waiting, Approved, Rejected)
SELECT
  CASE sig."Outcome" WHEN 'Approved' THEN 'Request Approved' WHEN 'Rejected' THEN 'Request Rejected' ELSE 'Request Waiting for Approval' END AS "ActivityName",
  req."Request Number" AS "ServiceRequestId",
  sig."Signature Date" AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:Request" AS req
JOIN "AP:Signature" AS sig ON req."InstanceId" = sig."Request"
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'

UNION ALL

-- 5. Request Assigned (based on first Work Info entry)
SELECT
  'Request Assigned' AS "ActivityName",
  wi."Request Number" AS "ServiceRequestId",
  MIN(wi."Submit Date") AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:WorkInfo" AS wi
JOIN "SRM:Request" AS req ON wi."Request Number" = req."Request Number"
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'
GROUP BY wi."Request Number", req."Status", req."Title", req."Priority", req."ASG_Assignee", req."Assigned Group"

UNION ALL

-- 6, 7, 8, 9: Fulfillment Steps from Work Logs
SELECT
  CASE 
    WHEN wi."Work Log Type" = 'General Information' AND wi.Description LIKE '%Fulfillment In Progress%' THEN 'Fulfillment In Progress'
    WHEN wi."Work Log Type" = 'Customer Communication' AND wi.Description LIKE '%Information Requested%' THEN 'Information Requested from User'
    WHEN wi."Work Log Type" = 'General Information' AND wi.Description LIKE '%Request Resumed%' THEN 'Request Resumed'
    WHEN wi."Work Log Type" = 'Resolution Communications' THEN 'Solution Implemented'
    ELSE NULL 
  END AS "ActivityName",
  wi."Request Number" AS "ServiceRequestId",
  wi."Submit Date" AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:WorkInfo" AS wi
JOIN "SRM:Request" AS req ON wi."Request Number" = req."Request Number"
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'
  AND wi."Work Log Type" IN ('General Information', 'Customer Communication', 'Resolution Communications')

UNION ALL

-- 10, 11, 12, 13: Terminal Statuses (Resolved, Confirmed, Closed, Canceled)
SELECT
  CASE req."Status"
    WHEN 'Resolved' THEN 'Service Request Resolved'
    WHEN 'Closed' AND req."Status_Reason" = 'Confirmed' THEN 'Resolution Confirmed by User'
    WHEN 'Closed' THEN 'Service Request Closed'
    WHEN 'Cancelled' THEN 'Service Request Canceled'
    ELSE NULL
  END AS "ActivityName",
  req."Request Number" AS "ServiceRequestId",
  req."Last Modified Date" AS "EventStartTime", -- This is an approximation of when the status change occurred
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:Request" AS req
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'
  AND req."Status" IN ('Resolved', 'Closed', 'Cancelled')

ステップ

前提条件: データベースクライアント（DBeaver、SQL Server Management Studio、Oracle SQL Developerなど）と、BMC Helix AR Systemデータベースへの読み取り専用認証情報があることを確認してください。
データベースへの接続: データベースクライアントを使用して、ARシステムデータベースサーバーへの接続を確立します。
クエリの準備: このドキュメントの「Query」セクションに記載されている完全なSQLクエリを、データベースクライアントのクエリエディターにコピーします。
パラメーターの設定: クエリ内のプレースホルダー値を見つけます。:start_dateと:end_dateを、抽出したい日付範囲（例：'2023-01-01'と'2023-12-31'）に置き換えます。該当する場合は、:company_nameをフィルターしたい特定の会社名に置き換えます。
クエリの実行: 変更したSQLクエリを実行します。日付範囲とシステムサイズによっては、完了までに数分かかる場合があります。
結果の確認: クエリが終了すると、イベントログを含む結果セットが表示されます。データが正しく入力されており、期待される列と活動が含まれていることを簡単に確認します。
タイムスタンプの処理: すべてのタイムスタンプ列、特にEventStartTime、EventEndTime、LastDataUpdateが、「YYYY-MM-DD HH:MI:SS」のような一貫した形式でフォーマットされていることを確認します。データベースが異なる形式で返す場合は、クエリ内のTO_CHARまたはCONVERT関数を適宜調整してください。
データのエクスポート: データベースクライアントのエクスポート機能を使用して、完全な結果セットをCSVファイルとして保存します。互換性を確保するためにUTF-8エンコーディングを選択します。
アップロードの準備: ファイルに適切な名前（例：servicerequest_eventlog.csv）を付けます。このファイルは、ProcessMindプラットフォームにアップロードする準備ができました。

設定

データベース認証情報: ARシステムデータベースへの読み取り専用ユーザーアカウントが必要です。これにより、意図しないデータ変更を防ぎ、セキュリティのベストプラクティスを遵守します。
日付範囲フィルタリング: クエリには:start_dateと:end_dateのプレースホルダーが含まれます。クエリのパフォーマンスとデータ量を管理するため、通常3〜12ヶ月間の特定の妥当な日付範囲を設定することが重要です。フィルタリングはサービスリクエストのSubmit_Dateに適用されます。
会社フィルター: 特定の事業会社のリクエストをフィルターするために、プレースホルダー:company_nameが含まれています。全ての会社のデータを抽出する必要がある場合は、AND req.Company = :company_nameの行を削除するか、サポートされている場合はワイルドカードに設定してください。
ステータス値: クエリは標準のBMC Helix ITSMステータス整数値（例：Submitted = 0, In Review = 1など）を使用します。お客様のシステムではカスタムステータスや異なる整数マッピングが使用されている場合があります。これらの値をシステムのSYS:Statusフォームまたは開発スタジオで確認し、必要に応じてクエリのWHERE句を調整してください。
パフォーマンス: SRM_Requestのような大規模なテーブルとその監査ログに対する直接データベースクエリは、リソースを大量に消費する可能性があります。システムパフォーマンスへの影響を最小限に抑えるため、オフピーク時間帯に抽出をスケジュールしてください。

a クエリ例 sql

WITH ServiceRequests AS (
  SELECT
    req.Request_Number AS ServiceRequestId,
    req.Submit_Date AS SubmitDate,
    req.Status AS CurrentStatus,
    req.Description AS ServiceType,
    req.Priority AS Priority,
    req.Assignee AS AssignedAgent,
    req.Assigned_Group AS AssignedTeam,
    req.Company,
    req.InstanceId
  FROM
    SRM_Request req
  WHERE
    req.Submit_Date BETWEEN TO_TIMESTAMP(:start_date, 'YYYY-MM-DD') AND TO_TIMESTAMP(:end_date, 'YYYY-MM-DD')
    AND req.Company = :company_name
)
-- 1. Service Request Submitted
SELECT
  sr.ServiceRequestId AS "ServiceRequestId",
  'Service Request Submitted' AS "ActivityName",
  sr.SubmitDate AS "EventStartTime",
  sr.SubmitDate AS "EventEndTime",
  'Submitted' AS "RequestStatus",
  sr.ServiceType AS "ServiceType",
  sr.Priority AS "Priority",
  sr.AssignedAgent AS "AssignedAgent",
  sr.AssignedTeam AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
UNION ALL
-- 2. Request In Review
SELECT
  sr.ServiceRequestId,
  'Request In Review' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'In Review' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%In Review%'
UNION ALL
-- 3. Request Waiting for Approval
SELECT
  sr.ServiceRequestId,
  'Request Waiting for Approval' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Waiting Approval' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Waiting Approval%'
UNION ALL
-- 4. Request Approved
SELECT
  sr.ServiceRequestId,
  'Request Approved' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Approved' AS "RequestStatus", -- This status might vary, often transitions to Planning or Assigned
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Planning%' AND audit.Old_Values LIKE '%Waiting Approval%'
UNION ALL
-- 5. Request Assigned
SELECT
  sr.ServiceRequestId,
  'Request Assigned' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Assigned' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Assigned_Group%' AND audit.New_Values IS NOT NULL
UNION ALL
-- 6. Fulfillment In Progress
SELECT
  sr.ServiceRequestId,
  'Fulfillment In Progress' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'In Progress' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%In Progress%'
UNION ALL
-- 7. Information Requested from User
SELECT
  sr.ServiceRequestId,
  'Information Requested from User' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Pending' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Pending%'
UNION ALL
-- 8. Request Resumed
SELECT
  sr.ServiceRequestId,
  'Request Resumed' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'In Progress' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%In Progress%' AND audit.Old_Values LIKE '%Pending%'
UNION ALL
-- 9. Solution Implemented
SELECT
  sr.ServiceRequestId,
  'Solution Implemented' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Completed' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Completed%'
UNION ALL
-- 10. Service Request Resolved
SELECT
  sr.ServiceRequestId,
  'Service Request Resolved' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Resolved' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Resolved%'
UNION ALL
-- 11. Resolution Confirmed by User
SELECT
  sr.ServiceRequestId,
  'Resolution Confirmed by User' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Closed' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Closed%' AND audit.Old_Values LIKE '%Resolved%'
UNION ALL
-- 12. Service Request Closed
SELECT
  sr.ServiceRequestId,
  'Service Request Closed' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Closed' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Closed%'
UNION ALL
-- 13. Service Request Canceled
SELECT
  sr.ServiceRequestId,
  'Service Request Canceled' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Cancelled' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Cancelled%'
UNION ALL
-- 14. Request Rejected
SELECT
  sr.ServiceRequestId,
  'Request Rejected' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Rejected' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Rejected%';

ステップ

前提条件: システムにPython 3.6以降がインストールされていることを確認してください。HTTP API呼び出しに必要となるrequestsライブラリを、ターミナルまたはコマンドプロンプトでpip install requestsを実行してインストールします。
API認証情報の取得: BMC Helix ITSMで専用サービスアカウントの認証情報を作成または取得します。このアカウントには、SRM:Requestフォームおよび対応する監査ログフォーム（通常SRM:Request_AuditLogなど）への少なくとも読み取り専用権限が必要です。ユーザー名、パスワード、およびBMC HelixインスタンスのベースURL（例：https://[your-company].bmc.com）を控えておいてください。
Pythonスクリプトの設定: 提供されたPythonスクリプトを、例えばextract_servicerequests.pyというファイルにコピーします。スクリプトを編集し、冒頭のプレースホルダー変数：BASE_URL、USERNAME、PASSWORD、AUDIT_FORM_NAMEを設定します。組織のサービスリクエストワークフローで使用されている特定のステータス値と一致するようにSTATUS_ACTIVITY_MAP辞書を調整します。
抽出期間の設定: スクリプト内のSTART_DATEおよびEND_DATE変数を変更します。これにより、サービスリクエストの提出日に基づく抽出の時間枠が定義されます。初期テストでは、1日のような短い日付範囲を使用してください。
スクリプトの実行: ターミナルからpython extract_servicerequests.pyコマンドを使用してスクリプトを実行します。スクリプトはまずAPIで認証を行い、トークンを取得します。
初期データフェッチ: スクリプトはSRM:Requestフォームをクエリし、指定された日付範囲内に作成されたすべてのサービスリクエストのリストを取得します。このステップでは、ケースIDと、優先度やサービスタイプなどの関連する静的属性が収集されます。
イベント履歴のフェッチ: スクリプトは、前のステップで取得した各サービスリクエストIDを反復処理します。各IDについて、設定された監査ログフォームへの2回目のAPI呼び出しを行い、その特定のリクエストのステータス変更の詳細な履歴をプルします。
データをイベントログに変換: 監査ログの各レコードについて、スクリプトはSTATUS_ACTIVITY_MAPを使用してステータス変更を標準の活動名にマッピングします。マッピングされた各活動について、サービスリクエストID、活動名、変更のタイムスタンプを含む行を作成します。
提出イベントの生成: スクリプトはまた、各リクエストの最初の「サービスリクエスト提出済み」活動を、メインのSRM:RequestフォームのSubmit Dateを使用して作成します。
CSVへのエクスポート: すべてのサービスリクエストとその履歴を処理した後、スクリプトは生成された行を単一のリストに統合し、そのデータをservicerequest_event_log.csvという名前のCSVファイルに書き込みます。このファイルは、プロセスマイニングツールにアップロードできる形式になっています。

設定

APIエンドポイント: スクリプトは主に2つのAPIエンドポイントを使用します。認証はapi/jwt/loginを介して処理され、ケースのリストはarsys/v1/entry/SRM:Requestから、イベント履歴はarsys/v1/entry/[AUDIT_FORM_NAME]からデータがクエリされます。
サービスアカウント権限: SRM:Requestフォームおよびシステムの監査ログフォームへの読み取りアクセス権を持つ専用のサービスアカウントが必要です。セキュリティと追跡可能性のために、サービスアカウントの使用は不可欠です。
日付範囲フィルタリング: スクリプトはサービスリクエストをSubmit Dateに基づいてフィルターするように構成されています。信頼性の高いパフォーマンスを確保するため、一度に3〜6ヶ月のような管理しやすいバッチでデータを抽出することをお勧めします。
ステータスから活動へのマッピング: スクリプト内のSTATUS_ACTIVITY_MAP辞書は、変換ロジックの中核です。組織のカスタムステータスを反映し、目的の活動名にマッピングするように慎重に設定する必要があります。ワークフロー内のステータスでマップに存在しないものは無視されます。
監査ログフォーム: スクリプトが詳細な活動をキャプチャする能力は、クエリ可能な監査ログに完全に依存します。サービスリクエストのステータス変更履歴を保存する環境内の正しいフォーム名を特定し、それに応じてAUDIT_FORM_NAME変数を更新する必要があります。
ページネーション: スクリプトは、すべてのレコードを取得するためにAPIページネーションを自動的に処理します。API呼び出しのlimitパラメーターは、パフォーマンスとメモリ使用量のバランスを取るために、リクエストごとに1000レコードを取得するように設定されています。

a クエリ例 python

import requests
import json
import csv
import datetime

class=class="hl-string">"hl-comment"># --- Configuration Settings --- #
class=class="hl-string">"hl-comment"># Replace with your BMC Helix environment details
BASE_URL = class="hl-string">"https://[your-company].bmc.com"
USERNAME = class="hl-string">"[your-service-account-username]"
PASSWORD = class="hl-string">"[your-service-account-password]"
class=class="hl-string">"hl-comment"># This is a placeholder; you must identify the correct audit form for SRM:Request in your system
AUDIT_FORM_NAME = class="hl-string">"SRM:Request_AuditLog"

class=class="hl-string">"hl-comment"># Date range for the extraction (YYYY-MM-DD format)
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-03-31"

class=class="hl-string">"hl-comment"># --- Status to Activity Mapping --- #
class=class="hl-string">"hl-comment"># CRITICAL: Customize this map to match your system's status values
STATUS_ACTIVITY_MAP = {
    class="hl-string">"In Review": class="hl-string">"Request In Review",
    class="hl-string">"Waiting for Approval": class="hl-string">"Request Waiting for Approval",
    class="hl-string">"Approved": class="hl-string">"Request Approved",
    class="hl-string">"Assigned": class="hl-string">"Request Assigned",
    class="hl-string">"In Progress": class="hl-string">"Fulfillment In Progress",
    class="hl-string">"Pending": class="hl-string">"Information Requested from User", class=class="hl-string">"hl-comment"># This is a simplification; may need refinement
    class="hl-string">"Completed": class="hl-string">"Service Request Resolved",
    class="hl-string">"Closed": class="hl-string">"Service Request Closed",
    class="hl-string">"Cancelled": class="hl-string">"Service Request Canceled",
    class="hl-string">"Rejected": class="hl-string">"Request Rejected"
    class=class="hl-string">"hl-comment"># Add other custom statuses as needed
}

class=class="hl-string">"hl-comment"># Map specific status transitions for more granular activities
TRANSITION_ACTIVITY_MAP = {
    (class="hl-string">'Pending', class="hl-string">'In Progress'): class="hl-string">'Request Resumed'
    class=class="hl-string">"hl-comment"># You can add other specific transitions here
}

def get_jwt_token(base_url, username, password):
    class="hl-string">"""Authenticates with the REST API and returns a JWT token."""
    url = fclass="hl-string">"{base_url}/api/jwt/login"
    payload = {
        class="hl-string">'username': username,
        class="hl-string">'password': password
    }
    headers = {class="hl-string">'Content-Type': class="hl-string">'application/x-www-form-urlencoded'}
    try:
        response = requests.post(url, data=payload, headers=headers)
        response.raise_for_status()
        return response.text
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error getting JWT token: {e}")
        return None

def get_paginated_results(base_url, token, form_name, query, fields):
    class="hl-string">"""Retrieves all entries from a form, handling pagination."""
    all_entries = []
    url = fclass="hl-string">"{base_url}/api/arsys/v1/entry/{form_name}"
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'AR-JWT {token}',
        class="hl-string">'Content-Type': class="hl-string">'application/json'
    }
    params = {
        class="hl-string">'q': query,
        class="hl-string">'fields': fclass="hl-string">'values({fields})',
        class="hl-string">'limit': 1000
    }
    while True:
        try:
            response = requests.get(url, headers=headers, params=params)
            response.raise_for_status()
            data = response.json()
            all_entries.extend(data[class="hl-string">'entries'])
            class=class="hl-string">"hl-comment"># Check for next page link
            if class="hl-string">'next' in data[class="hl-string">'_links']:
                url = data[class="hl-string">'_links'][class="hl-string">'next'][class="hl-string">'href']
                params = {}
            else:
                break
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data from {form_name}: {e}")
            break
    return all_entries

def main():
    class="hl-string">"""Main function to orchestrate the data extraction."""
    print(class="hl-string">"Starting extraction...")
    token = get_jwt_token(BASE_URL, USERNAME, PASSWORD)
    if not token:
        return

    class=class="hl-string">"hl-comment"># 1. Get all Service Requests within the date range
    print(fclass="hl-string">"Fetching service requests from {START_DATE} to {END_DATE}...")
    srm_query = fclass="hl-string">"'Submit Date' >= \"{START_DATE}T00:00:00Z\class="hl-string">" AND 'Submit Date' <= \"{END_DATE}T23:59:59Z\class="hl-string">""
    srm_fields = class="hl-string">"Request Number,Submit Date,Priority,Assignee,Assigned Group,Title"
    srm_requests = get_paginated_results(BASE_URL, token, class="hl-string">"SRM:Request", srm_query, srm_fields)
    print(fclass="hl-string">"Found {len(srm_requests)} service requests.")

    event_log = []
    current_time = datetime.datetime.utcnow().isoformat() + class="hl-string">"Z"

    class=class="hl-string">"hl-comment"># 2. For each request, get its audit history
    for i, req in enumerate(srm_requests):
        req_values = req[class="hl-string">'values']
        request_id = req_values.get(class="hl-string">'Request Number')
        if not request_id:
            continue

        print(fclass="hl-string">"Processing request {i+1}/{len(srm_requests)}: {request_id}")

        class=class="hl-string">"hl-comment"># Add class="hl-string">'Service Request Submitted' event
        event_log.append({
            class="hl-string">'ServiceRequestId': request_id,
            class="hl-string">'ActivityName': class="hl-string">'Service Request Submitted',
            class="hl-string">'EventStartTime': req_values.get(class="hl-string">'Submit Date'),
            class="hl-string">'EventEndTime': req_values.get(class="hl-string">'Submit Date'),
            class="hl-string">'RequestStatus': class="hl-string">'Submitted',
            class="hl-string">'ServiceType': req_values.get(class="hl-string">'Title'),
            class="hl-string">'Priority': req_values.get(class="hl-string">'Priority'),
            class="hl-string">'AssignedAgent': req_values.get(class="hl-string">'Assignee'),
            class="hl-string">'AssignedTeam': req_values.get(class="hl-string">'Assigned Group'),
            class="hl-string">'SourceSystem': class="hl-string">'BMC Helix ITSM',
            class="hl-string">'LastDataUpdate': current_time
        })

        class=class="hl-string">"hl-comment"># 3. Fetch audit log for status changes
        audit_query = fclass="hl-string">"'Original Request ID' = \"{request_id}\class="hl-string">" AND 'Fields Changed' LIKE \"%Status%\class="hl-string">""
        audit_fields = class="hl-string">"New Value,Old Value,Log Key 1,Create Date"
        audit_entries = get_paginated_results(BASE_URL, token, AUDIT_FORM_NAME, audit_query, audit_fields)
        
        class=class="hl-string">"hl-comment"># Sort audit entries by date to ensure correct order
        audit_entries.sort(key=lambda x: x[class="hl-string">'values'][class="hl-string">'Create Date'])

        for audit_entry in audit_entries:
            audit_values = audit_entry[class="hl-string">'values']
            class=class="hl-string">"hl-comment"># Ensure we are only processing status changes
            if class="hl-string">'Status' not in audit_values.get(class="hl-string">'Log Key 1', class="hl-string">''):
                continue

            new_status = audit_values.get(class="hl-string">'New Value')
            old_status = audit_values.get(class="hl-string">'Old Value')
            timestamp = audit_values.get(class="hl-string">'Create Date')
            activity_name = None

            class=class="hl-string">"hl-comment"># Check for specific transitions first
            if (old_status, new_status) in TRANSITION_ACTIVITY_MAP:
                activity_name = TRANSITION_ACTIVITY_MAP.get((old_status, new_status))
            class=class="hl-string">"hl-comment"># Then check for general status mappings
            elif new_status in STATUS_ACTIVITY_MAP:
                activity_name = STATUS_ACTIVITY_MAP.get(new_status)

            if activity_name:
                event_log.append({
                    class="hl-string">'ServiceRequestId': request_id,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventStartTime': timestamp,
                    class="hl-string">'EventEndTime': timestamp,
                    class="hl-string">'RequestStatus': new_status,
                    class="hl-string">'ServiceType': req_values.get(class="hl-string">'Title'),
                    class="hl-string">'Priority': req_values.get(class="hl-string">'Priority'),
                    class="hl-string">'AssignedAgent': req_values.get(class="hl-string">'Assignee'), class=class="hl-string">"hl-comment"># Note: Assignee is static from the main request
                    class="hl-string">'AssignedTeam': req_values.get(class="hl-string">'Assigned Group'), class=class="hl-string">"hl-comment"># Note: Team is static from the main request
                    class="hl-string">'SourceSystem': class="hl-string">'BMC Helix ITSM',
                    class="hl-string">'LastDataUpdate': current_time
                })
    
    class=class="hl-string">"hl-comment"># 4. Write to CSV
    output_file = class="hl-string">'servicerequest_event_log.csv'
    print(fclass="hl-string">"Writing event log to {output_file}...")
    if event_log:
        with open(output_file, class="hl-string">'w', newline=class="hl-string">'', encoding=class="hl-string">'utf-8') as f:
            writer = csv.DictWriter(f, fieldnames=event_log[0].keys())
            writer.writeheader()
            writer.writerows(event_log)
        print(class="hl-string">"Extraction complete.")
    else:
        print(class="hl-string">"No events to write.")

if __name__ == class="hl-string">"__main__":
    main()

サービスリクエスト管理データテンプレート

サービスリクエスト管理データテンプレート

サービスリクエスト管理における属性

サービスリクエスト管理におけるアクティビティ

抽出ガイド

BMC Helix ITSM Smart Reportingによるサービスリクエスト

ステップ

設定

a クエリ例 config

ARシステムデータベーステーブルへの直接SQLクエリ

ステップ

設定

a クエリ例 sql

BMC Helix REST API を介した Python スクリプト抽出

ステップ

設定

a クエリ例 python

今すぐ始めますか？

効率性を解き放つ：今すぐサービスリクエスト管理を最適化

サービスリクエスト管理 データテンプレート

サービスリクエスト管理 データテンプレート

サービスリクエスト管理における属性

サービスリクエスト管理におけるアクティビティ

抽出ガイド

BMC Helix ITSM Smart Reportingによるサービスリクエスト

ステップ

設定

a クエリ例 config

ARシステムデータベーステーブルへの直接SQLクエリ

ステップ

設定

a クエリ例 sql

BMC Helix REST API を介した Python スクリプト抽出

ステップ

設定

a クエリ例 python

お客様のプライバシーを大切にしています

今すぐ始めますか？

効率性を解き放つ：今すぐサービスリクエスト管理を最適化

サービスリクエスト管理データテンプレート

サービスリクエスト管理データテンプレート