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

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

BMC Helix ITSM

サービスリクエスト管理の属性 (20) サービスリクエスト管理のアクティビティ (14) 抽出ガイド (3)

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

このテンプレートでは、サービスリクエスト管理プロセスで収集すべき主要なデータ属性と、追跡すべき重要なアクティビティをわかりやすく整理しています。BMC Helix ITSMからデータを効率的に抽出する方法も説明しています。この資料を使ってデータ準備を効率化し、安心してプロセスマイニングを始めてください。

収集を推奨する属性
追跡すべき主要なアクティビティ
BMC Helix ITSMからの抽出方法

イベントログを初めて扱いますか。学ぶプロセスマイニングのイベントログを作成する方法.

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

サービスリクエスト管理の属性

サービスリクエスト管理プロセスを詳細に分析するため、完全なイベントログの作成に欠かせないデータ項目です。

5 必須 6 推奨 9 任意

	名前	説明
	アクティビティ ActivityName	サービスリクエストのライフサイクル中に、ある時点で発生した特定のイベントまたはタスクの名称です。
説明この属性は、「Request In Review」、「Fulfillment In Progress」、「Service Request Resolved」など、サービスリクエストプロセスにおける具体的な手順またはステータス変更を示します。各アクティビティは、サービスリクエストの開始から終了までの流れにおける1つのイベントを表します。アクティビティの順序と頻度の分析は、プロセスマイニングの中心です。プロセスマップの発見、ボトルネックの特定、プロセスバリアントの分析が可能になります。どのアクティビティが、どの順序で、どの程度の頻度で発生するかを把握することは、プロセス改善に欠かせません。重要な理由アクティビティはプロセスマップを構成する基本要素です。追跡することでプロセスフローを可視化・分析し、実際の作業の進み方を明らかにできます。入手先通常、「SRM:Request」フォームまたは関連する履行アプリケーションのログ（例：Incident、Work Order）にある「Status」および「Status Reason」フィールドの変更から導出されます。例承認待ちのリクエスト履行中サービスリクエスト解決済みサービスリクエストクローズ済み
	サービスリクエストID ServiceRequestId	各サービスリクエストを識別する一意の識別子であり、ライフサイクル全体を追跡する主キーです。
説明サービスリクエストIDは、ユーザーまたはシステムから送信された個々のサービスリクエストを一意に識別します。初回の記録から最終クローズまで、後続するすべてのイベントをつなぐ中心的な識別子です。これにより、各サービスリクエストの一連の流れを最初から最後まで分析できます。プロセスマイニングでは、このIDが各ケースのアクティビティの順序を再構成するために欠かせません。ツールは、「Request Submitted」、「Request Assigned」、「Service Request Closed」など、関連するすべてのイベントを1つのプロセスインスタンスにまとめられます。これが、プロセス分析の基盤になります。重要な理由基本となるケース識別子です。これがなければ、サービスリクエストの開始から終了までの流れを追跡できず、プロセスの発見と分析も行えません。入手先通常、BMC Helix ITSMの「SRM:Request」フォームにある「InstanceId」または「Request Number」フィールドに該当します。例 SR000010572931SR000010572932SR000010572933
	開始時刻 EventStartTime	特定のアクティビティまたはイベントが開始した時点を示すタイムスタンプです。
説明この属性は、アクティビティが開始した正確な日時を記録します。初回送信から最終クローズまで、ログ内のすべてのイベントに開始時刻が必要です。これにより、プロセスの時系列を確立できます。このタイムスタンプは、時間に基づくプロセスマイニング分析全般に欠かせません。サイクルタイム、アクティビティの所要時間、手順間の待ち時間の算出や、SLAコンプライアンスの確認に使われます。ボトルネックの発見や、時間の経過に伴うプロセスパフォーマンスの分析も可能になります。重要な理由開始時刻によってイベントの時系列が定まり、プロセス期間の算出、遅延の特定、プロセスの時間的な流れの把握が可能になります。入手先「SRM:Request」フォームに関連付けられた監査ログまたはステータス履歴テーブルのタイムスタンプフィールドに対応します。初回イベントでは「Submit Date」などが該当します。例 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	ユーザーが依頼したサービスのカテゴリーまたは種類です。
説明サービスタイプは、リクエストの内容を分類します。例として、「Request New Software」、「Password Reset」、「Onboard New Employee」などがあります。プロセスデータを絞り込み、分類するための基本的な軸です。プロセス分析では、異なる種類のリクエストのパフォーマンスを比較するために使います。「解決に最も時間がかかるサービスタイプはどれか」「手戻りが最も多いサービスタイプはどれか」といった問いに答えられます。Resolution TimeおよびSLA Complianceダッシュボードに欠かせない属性です。重要な理由サービスリクエストを分類し、プロセスフローの比較、種類ごとの問題の特定、改善施策の調整を行えます。入手先通常、「SRM:Request」フォームの「Title」または分類フィールドにあり、カタログで選択されたサービスから導出されます。例新しいハードウェアの申請ソフトウェアアクセスの申請VPNアクセスの設定
	リクエストステータス RequestStatus	イベント発生時点におけるサービスリクエストのステータスです。「In Progress」、「Pending」、「Closed」などが該当します。
説明この属性は、ライフサイクルの各時点におけるサービスリクエストの状態を記録します。ステータスは各アクティビティの背景情報となり、「Activity」属性自体の元データになることもあります。ステータス別に分析すると、「Pending Customer」や「Waiting for Approval」などの状態にリクエストがどれだけ滞在したかを把握できます。外部依存や内部キューによるボトルネックと遅延の特定に欠かせません。Bottleneck Identificationダッシュボードを直接支援します。重要な理由リクエストの状態を切り取って確認でき、待機状態とアクティブな状態に費やした時間を分析できます。ボトルネックの特定に欠かせない情報です。入手先「SRM:Request」フォームの「Status」フィールドです。過去の値は監査ログで確認できます。例計画進行中保留中解決済みクローズ済み
	優先度 Priority	サービスリクエストに設定された優先度であり、ビジネスへの影響と緊急度を示します。
説明優先度によって、リクエストを処理する順序と速さが決まります。一般的な値には「Critical」、「High」、「Medium」、「Low」があります。通常は、ビジネスへの影響と緊急度を組み合わせて設定します。優先度別の分析は、高優先度のリクエストが低優先度のリクエストより速く処理されているかを評価するために欠かせません。解決時間とSLAコンプライアンスのダッシュボードにおける重要な分析軸であり、最も重要なビジネスニーズに適切にリソースを配分できているかを確認できます。重要な理由プロセスが作業を適切に優先付けし、ビジネスへの影響度が異なるリクエストに期待されるサービスレベルを満たしているかを評価できます。入手先「SRM:Request」フォームの「Priority」フィールドです。例緊急高中低
	割り当てチーム AssignedTeam	現在、サービスリクエストを担当しているサポートグループまたはチームです。
説明この属性は、リクエストを処理する機能グループを識別します。例として、「Help Desk」、「Network Team」、「Database Administration」などがあります。このフィールドの変更は、チーム間で責任が移ったことを示します。割り当てチームに基づく分析により、チーム単位のボトルネック、チーム間の引き継ぎ、各サポートグループの効率を評価できます。Request Rework and ReassignmentおよびTriage Efficiencyダッシュボードの基盤となり、組織内での作業の振り分け方に関する傾向を明らかにします。重要な理由異なる機能グループ間のプロセスフローを分析し、ルーティングの非効率を特定するとともに、チーム単位のパフォーマンスを測定できます。入手先サービスリクエストに関連付けられた履行レコード（例：Work Order、Incident）の「Assigned Group」フィールドに対応します。例サービスデスクインフラストラクチャサポートアプリケーションサポート第2層
	割り当て担当者 AssignedAgent	現在、サービスリクエストの対応を担当している個人ユーザーです。
説明この属性は、特定の時点でリクエストを担当するIT担当者またはサポートスタッフを識別します。1つのリクエストのライフサイクル中にこのフィールドが変更された場合、引き継ぎまたは再割り当てが発生したことを示します。担当者のパフォーマンスと作業負荷を分析するために欠かせない属性です。担当者ごとの処理件数、平均解決時間、再割り当て頻度を追跡できます。リソース管理や研修機会の特定にも役立ちます。重要な理由割り当て担当者を追跡すると、引き継ぎの分析、個人のパフォーマンス測定、サポートチーム全体の作業負荷分布の把握が可能になります。入手先サービスリクエストに関連付けられた履行レコード（例：Work Order、Incident）の「Assignee」または「Assigned To」フィールドに対応します。例 Bob SmithAlice JohnsonCharlie Brown
	終了時刻 EventEndTime	特定のアクティビティまたはイベントが完了した時点を示すタイムスタンプです。
説明終了時刻は、アクティビティの終了を示します。ITSMシステムの多くのアクティビティは瞬時のステータス変更ですが、測定可能な期間を持つものもあります。終了時刻があれば、そのようなアクティビティの所要時間を正確に算出できます。分析では、終了時刻と開始時刻を組み合わせて、個々のアクティビティの処理時間を算出します。これにより、手順間の待ち時間だけでなく、どのタスク自体に最も時間がかかっているかも特定できます。重要な理由アクティビティの処理時間を算出できるため、非効率な手順の特定や、リソースがどこに時間を費やしているかの把握に役立ちます。入手先導出できます。同じケースで次に続くアクティビティの開始時刻が、直前のアクティビティの終了時刻になることがよくあります。最後のアクティビティでは、解決またはクローズのタイムスタンプが該当します。例 2023-10-26T10:05:15Z2023-10-26T11:45:10Z2023-10-28T09:00:00Z
	SLA目標日時 SlaTargetDate	サービスレベル契約（SLA）に基づき、サービスリクエストの解決が予定される日時です。
説明 SLA目標日時は、サービスリクエストを完了する期限を示す計算済みのタイムスタンプです。通常、リクエストの優先度や種類などを考慮したサービス契約のルールによって決まります。 SLA Compliance Overviewダッシュボードの基準となる属性です。実際の解決時間を測定する際の基準として使われます。最終解決アクティビティの「EventEndTime」とこの目標日時を比較することで、サービス上の約束を守れたかを判断できます。重要な理由サービス上の約束に対するパフォーマンスを測定する主要な基準であり、SLAコンプライアンスの監視とレポートに欠かせません。入手先この日時はService Level Management（SLM）モジュールによって計算・保存され、サービスリクエストにリンクされた関連SLMフォームで確認できます。例 2023-10-28T17:00:00Z2023-11-01T09:00:00Z2023-10-27T12:00:00Z
	SLA違反かどうか IsSlaBreached	サービスリクエストがSLAの目標日より後に解決されたかどうかを示すブール型フラグです。
説明この計算フラグは、サービスリクエストの最終解決日時が「SLA Target Date」より後の場合にtrueに設定されます。リクエスト単位でSLA達成状況を単純な二値で示します。この属性は、「SLA Compliance Overview」ダッシュボードと「SLA Adherence Rate」KPIに欠かせません。集計して全体のコンプライアンス率を算出しやすくなるほか、SLA違反のリクエストと遵守できたリクエストのプロセス特性を比較するための絞り込みにも利用できます。これにより、SLA違反の根本原因を特定できます。重要な理由日時の比較結果を単純なブール型フラグに変換することで、SLA達成状況を分析しやすくし、コンプライアンス率の測定と可視化を簡単にします。入手先計算項目です。ロジックは次のとおりです：IF 'Resolution Timestamp' > 'SlaTargetDate' THEN true ELSE false。例 truefalse
	エスカレーション済みかどうか IsEscalated	サービスリクエストがエスカレーションされたかどうかを示すブール型フラグです。
説明サービスリクエストが機能上または階層上のエスカレーションを受けた場合、このフラグはtrueに設定されます。通常、リクエストが想定どおりに進んでいない場合、SLA違反が発生しそうな場合、または承認や対応に上位権限が必要な場合にエスカレーションが行われます。この属性は、「Request Escalation Efficiency Analysis」ダッシュボードに欠かせません。エスカレーションされたリクエストのプロセスパスを絞り込み、分析することで、エスカレーションのきっかけ、エスカレーション後の解決までの時間、エスカレーションプロセスの有効性を把握できます。重要な理由エスカレーションが必要だったリクエストだけを抽出して分析できます。これにより、標準プロセスの弱点や、複雑な問題につながるきっかけを特定できます。入手先通常、単一の項目ではありません。監査ログ内の特定のエスカレーション関連アクティビティや、エスカレーション手順に沿った優先度または担当の変更を確認して算出します。例 truefalse
	クローズコード CloseCode	サービスリクエストをクローズした最終結果または理由を示すコードです。
説明クローズコードは、サービスリクエストの解決結果を標準化して分類する方法です。例として、「Resolved by Service Desk」、「Canceled by User」、「Duplicate Request」などがあります。クローズコードを分析すると、リクエストの一般的な結果を把握できます。ユーザーによるキャンセルが多い場合はプロセスが長すぎる可能性があり、重複リクエストが多い場合はシステムやコミュニケーションの問題が考えられます。この属性はResolution Category Accuracyダッシュボードを支援します。重要な理由リクエストの結果に関する構造化データを提供し、解決の有効性や未完了・キャンセルの理由を分析できます。入手先通常、サービスリクエストに関連付けられた履行チケットの「Resolution」または「Closure Code」フィールドにあります。例成功ユーザーによるキャンセル不要になったため自動解決
	依頼者の所属部門 RequestorDepartment	リクエストを送信したユーザーが所属する事業部門または組織単位です。
説明この属性は、サービスを依頼した人の組織上の所属部門を示します。例として、「Finance」、「Human Resources」、「IT」などがあります。通常、システム内のユーザープロファイルから取得されます。部門別にプロセス分析を分類すると、部門固有のニーズやリクエストの傾向、研修やサービス改善の対象領域を特定できます。「Finance部門ではリクエストの待ち時間が長いか」といった問いにも答えられます。重要な理由事業部門別にサービス利用状況とプロセスパフォーマンスを分析でき、部門固有の問題や傾向を明らかにできます。入手先通常、「SRM:Request」フォームの「Requested For」ユーザーに関連付けられたユーザープロファイルから取得されます。例財務営業人事情報技術
	引き継ぎ回数 HandoffCount	サービスリクエストが異なる担当者またはチーム間で再割り当てされた合計回数です。
説明この計算指標は、1件のサービスリクエストについて「AssignedAgent」または「AssignedTeam」が変更された回数を数えます。引き継ぎ回数が多い場合、プロセスの分断、初回対応での解決不足、または非効率な振り分けが考えられます。この属性は、「Average Agent Handoffs per Request」KPIの基礎となり、「Request Rework and Reassignment」ダッシュボードで使用されます。引き継ぎ回数が多いケースを分析すると、トリアージの改善、トレーニングの充実、解決プロセスの効率化によって遅延を減らし、顧客満足度を高める機会を見つけられます。重要な理由プロセスの分断とコミュニケーションにかかる負荷を測定します。引き継ぎ回数が多いほど、解決までの時間が長くなり、プロセス効率が低下する傾向があります。入手先計算指標です。各一意のService Request IDについて、「AssignedAgent」または「AssignedTeam」属性に含まれる異なる値の数を数えて算出します。例 0135
	手戻りかどうか IsRework	サービスリクエストが、以前の段階に戻るなどの手戻りを経験したかどうかを示すブール型フラグです。
説明このフラグは、プロセスフロー内でループや手戻りが発生したサービスリクエストを特定します。たとえば、「Fulfillment in Progress」から「Request in Review」に戻ったリクエストは、手戻りとみなされます。正確な定義は、業務プロセスのロジックによって異なります。この属性は、「Request Rework and Reassignment Analysis」ダッシュボードと「Request Rework Rate」KPIを直接支援します。手戻りの発生頻度を定量化し、初期評価の誤りや情報不足など、プロセスの非効率につながる主な原因を分析できます。重要な理由「理想的な経路」から外れたケースにフラグを付けることで、プロセスの非効率を定量化し、ループや作業の繰り返しの根本原因を特定できます。入手先計算属性です。イベントログ内のアクティビティの順序から算出します。プロセスフロー上の後戻りを検出するロジックが必要です。例 truefalse
	解決カテゴリー ResolutionCategory	リクエストを解決するために提供されたソリューションの分類です。
説明この属性は、リクエストをどのように解決したかを構造化して分類します。例として、「Software Fix」、「User Training」、「Data Correction」などがあります。単純なクローズコードよりも、解決内容の性質を詳しく示します。 Resolution Category Accuracyダッシュボードに欠かせない属性です。初期のサービスタイプと比較して、一貫性を確認できます。解決カテゴリーを分析すると、問題の傾向を特定し、先回りした問題管理に役立てられます。たとえば、多くのリクエストがユーザートレーニングによって解決されていることなどを把握できます。重要な理由解決策の内容を把握し、繰り返し発生する問題の傾向や、予防的な問題管理またはユーザートレーニングの機会を特定できます。入手先この情報は、履行チケットの運用カテゴリおよび製品カテゴリの項目に含まれ、通常は「Resolution Category」と表示されます。例アカウント管理ハードウェア障害ソフトウェアのアップグレード情報提供済み
	送信チャネル SubmissionChannel	サービスリクエストを送信した方法またはチャネルです。
説明この属性は、サービスリクエストがどのように開始されたかを記録します。例として、セルフサービス・ポータル、メール、サービスデスクへの電話、システムによる自動アラートなどがあります。チャネルによって、プロセスバリアントや解決時間が異なる場合があります。送信チャネル別にプロセスを分析すると、特定の受付方法に関する非効率や優れた運用を明らかにできます。たとえば、セルフサービス・ポータルから送信されたリクエストは初期データの品質が高く、メールからのリクエストより速く解決できる場合があります。一方、メールからのリクエストでは手作業のトリアージが必要になることがあります。重要な理由受付方法がプロセス効率、データ品質、サイクルタイムに与える影響を把握し、チャネルごとに改善策を講じられます。入手先通常、「SRM:Request」フォームまたは関連する履行チケットの「Client Type」や「Reported Source」などのフィールドから推定できます。例セルフサービス・ポータルメール電話システム生成

必須推奨任意

サービスリクエスト管理のアクティビティ

正確なプロセスディスカバリーと可視化のため、イベントログに記録する主要なプロセス手順とマイルストーンです。

6 推奨 8 任意

	アクティビティ	説明
	サービスリクエストキャンセル済み	履行が完了する前に、依頼者またはサービスデスクによってサービスリクエストが取り下げられた状態です。リクエストの終端状態になります。
重要な理由キャンセルを追跡すると、ユーザーによる誤ったリクエストの送信や、サービスが不要になったケースなどの傾向を特定でき、サービスカタログの改善に役立ちます。入手先 SRM:Requestフォームのステータスが「Canceled」に変更されたことから推定されます。取得 SRM:Requestの「Status」フィールドが「Canceled」に変更された更新イベントのタイムスタンプです。イベントタイプ inferred
	サービスリクエストクローズ済み	サービスリクエストが正式にクローズされ、読み取り専用のアーカイブ状態に移行した状態です。解決と確認期間の終了後に発生します。
重要な理由プロセスの確定的な終了を示すアクティビティです。「Resolved」から「Closed」までの時間により、クローズ手順の非効率を明らかにできます。入手先 SRM:Requestフォームの最終ステータスが「Closed」に変更されたことから推定されます。取得 SRM:Requestの「Status」フィールドが「Closed」に変更された更新イベントのタイムスタンプです。イベントタイプ inferred
	サービスリクエストの送信	このアクティビティは、ユーザーが新しいサービスリクエストを作成して送信したことを示します。SRM:Requestフォームに初期ステータス（通常は「Submitted」）の新しいエントリが作成された時点で記録されます。
重要な理由すべてのサービスリクエストケースの開始点であり、ライフサイクル全体の期間を測定し、リクエスト受付量を分析するために欠かせません。入手先このイベントは、SRM:Requestフォームのレコードの作成日時と初期ステータス（例：「Submitted」）から推定されます。取得ステータスが「Submitted」のときに、SRM:Requestフォームで新しいサービスリクエストIDの作成日時を特定します。イベントタイプ inferred
	サービスリクエスト解決済み	サービスリクエストの履行が完了し、解決内容が依頼者に伝えられた状態です。最終確認を待つか、設定された期間の経過後に自動的にクローズされます。
重要な理由サービス提供サイクルの終了を示す重要な節目です。解決時間とSLA遵守状況を測定する主要な終点になります。入手先 SRM:Requestフォームのステータスが「Resolved」または「Completed」に変更されたことから推定されます。取得 SRM:Requestの「Status」フィールドが「Resolved」または「Completed」に変更された更新イベントのタイムスタンプです。イベントタイプ inferred
	リクエスト割り当て済み	サービスリクエストが、作業を完了する担当者またはチームに割り当てられた状態です。トリアージ段階の終了を示します。
重要な理由この節目は、トリアージ時間の測定と担当者の作業負荷の分析に欠かせません。頻繁な再割り当ては、ルーティングの問題やスキル不足を示している可能性があります。入手先 SRM:Requestまたは関連する履行アプリケーションフォーム（例：WOI:WorkOrder）の「Assigned Group」または「Assignee」フィールドの監査ログから明示的に取得できます。取得「Assignee」フィールドに初めて空でない値が設定されたことを示す監査ログのタイムスタンプです。イベントタイプ explicit
	履行中	割り当てられた担当者またはチームが、サービスリクエストの履行作業を実際に開始した状態です。リクエストがキューから作業中の状態に移ったことを示します。
重要な理由付加価値を生む履行作業の開始を示します。この段階にかかった時間を分析すると、リソースの生産性と履行の複雑さを把握できます。入手先 SRM:Requestフォームのステータスが「In Progress」に変更されたことから推定されます。取得 SRM:Requestの「Status」フィールドが「In Progress」に変更された更新イベントのタイムスタンプです。イベントタイプ inferred
	ソリューション実装済み	サービスリクエストの履行に必要な技術作業が担当者によって完了した状態です。正式に解決済みとする前に、ユーザーの確認を受けられる状態になっています。
重要な理由技術作業の完了と正式な解決を分けて記録します。作業完了からユーザー確認までの遅延を特定できます。入手先親レコードであるSRM:Requestが「Resolved」になる前に、バックエンドの履行チケット（例：Work Order）のステータスが「Completed」に変更されたことから推定できます。取得 SRM:Requestに関連付けられたバックエンドチケット（Work Order、Incidentなど）が完了と記録された時点のタイムスタンプです。イベントタイプ inferred
	ユーザーによる解決確認	依頼者がサービス提供に納得し、リクエストが解決したことを明示的に確認した状態です。多くの場合、リクエストの最終クローズが開始されます。
重要な理由顧客満足度を示す明確な指標となり、サービスに関するやり取りを正式に終えます。プロセス上の解決と顧客の受け入れを区別できます。入手先ユーザーがポータルまたはメールで確認した際、SRM:Requestの作業ログやアクティビティメモから取得できる場合があります。独立したステータスとして記録されないこともあります。取得作業ログ（SRM:WorkInfo）を確認し、ユーザー確認またはアンケート完了を示す特定のエントリを探します。イベントタイプ explicit
	ユーザーへの情報依頼	履行担当者が作業を進めるため、依頼者に追加情報を求めている状態です。通常は「Pending」状態になります。
重要な理由「外部情報待ち時間」の算出に欠かせないアクティビティです。情報不足によってリクエストが停止する頻度を特定できます。入手先 SRM:Requestフォームのステータスが「Pending」に変更され、ステータス理由が「Customer Hold」や「Awaiting Information」などになったことから推定されます。取得ステータスが「Pending」に変更された時点と、特定のステータス理由を組み合わせたタイムスタンプです。イベントタイプ inferred
	リクエストのレビュー中	サービスリクエストは、内容、優先度、適切な対応チームを判断するため、サービスデスクによる初期レビューとトリアージを受けています。通常は、リクエストレコードのステータス変更で示されます。
重要な理由このアクティビティを追跡すると、トリアージの効率を測定し、送信から割り当てまでの遅延を特定できます。「平均トリアージ時間」KPIの把握に欠かせません。入手先 SRM:Requestフォームのステータスが「In Review」や「Planning」などに変更されたことから推定されます。取得 SRM:Requestの「Status」フィールドが「In Review」に変更された更新イベントのタイムスタンプです。イベントタイプ inferred
	リクエスト再開	サービスリクエストが保留または待機状態から戻された状態です。通常はユーザーから必要な情報が提供された後に発生し、履行担当者が作業を再開します。
重要な理由待機期間の終了を示し、外部待ち時間とSLAコンプライアンスへの影響を正確に測定できます。入手先 SRM:Requestのステータスが「Pending」から「In Progress」に戻った時点で推定されます。取得 SRM:Requestの「Status」フィールドが「Pending」から「In Progress」に変更された更新イベントのタイムスタンプです。イベントタイプ inferred
	リクエスト却下	サービスリクエストが承認段階で拒否された状態です。履行開始前にプロセスを停止する終端状態になります。
重要な理由却下されたリクエストを分析すると、申請理由、適格性基準、承認ポリシーに関する問題を明らかにできます。入手先 SRM:Requestフォームのステータスが「Rejected」に変更されたことから推定されます。取得 SRM:Requestの「Status」フィールドが「Rejected」に変更された更新イベントのタイムスタンプです。イベントタイプ inferred
	リクエスト承認済み	サービスリクエストが必要な承認者によって正式に承認され、履行プロセスを進められる状態です。通常は「Waiting for Approval」ステータスの後に発生します。
重要な理由承認サブプロセスの終了を示す重要な節目です。承認にかかる時間と、解決時間全体への影響を追跡できます。入手先 SRM:Requestフォームのステータスが「Waiting Approval」から「Planning」や「In Progress」などの後続ステータスに変更されたことから推定されます。承認判断そのものは、関連する承認フォームに記録されます。取得承認が可決された後、「Waiting Approval」から別のステータスに変更された時点のタイムスタンプです。イベントタイプ inferred
	承認待ちのリクエスト	サービスリクエストは指定された承認者または承認グループに送信され、履行を開始する前の判断を待っている状態です。費用やアクセス権が関係するリクエストでよく発生します。
重要な理由このアクティビティにより、承認に関する遅延を切り分け、承認サイクルの時間を分析し、承認経路のボトルネックを特定できます。入手先 SRM:Requestフォームのステータスが「Waiting Approval」などに変更されたことから推定されます。取得 SRM:Requestの「Status」フィールドが「Waiting Approval」に変更された更新イベントのタイムスタンプです。イベントタイプ inferred

推奨任意

抽出ガイド

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

ステップ

Smart Reportingへのアクセス：BMC Helix ITSM環境にログインします。レポートセクションに移動し、Smart Reportingを起動します。バージョンによっては、「Reports」または「Smart Reporting」と表示されます。
新しいレポートの作成：Smart Reportingの画面で、新しいレポートを作成するオプションを選択します。種類として「Report」を選択します。
データソースとビューの選択：データソースの選択を求められたら、主要なAR Systemデータソースを選択します。ビューでは「Service Request」を検索して選択します。通常はSRM:Requestフォームに基づいています。
追加フォームの結合（Joins）：ライフサイクル全体を取得するには、メインのSRM:Requestフォームを関連フォームと結合する必要があります。「Data」タブを使い、次のフォームを結合します。
- SRM:WorkInfo（SR ID+ = Request Number）：履行アクティビティと作業ログの詳細を取得します。
- AP:Signature（Request = SRInstanceID）：承認や却下など、承認関連のイベントを取得します。この結合にはカスタム結合が必要になる場合があります。
レポート列の定義：結合したフォームから必要な項目を「Columns」領域にドラッグアンドドロップします。SRM:RequestからRequest Number、Submit Date、ステータス、説明、Priority、Assigned To、Assigned Groupなどの項目を追加し、結合したフォームから関連項目も追加します。
アクティビティ用の計算項目の作成：この方法の中心は、各アクティビティのタイムスタンプを表す計算項目を一連の項目として作成することです。「Data」タブに移動し、アクティビティごとに新しい計算項目を作成します。例：
- 送信タイムスタンプ：Submit Date項目を直接使います。
- 承認タイムスタンプ：AP:SignatureフォームのSignature Dateを使います。
- 処理中タイムスタンプ：Request Numberでグループ化したSRM:WorkInfoのMIN(Submit Date)を使います。
結合用レポートの構成：Smart Reportingには、SQLのような単純な「UNION ALL」ボタンはありません。実現するには、1つのレポートを作成し、高度な関数またはサブクエリを使ってデータをピボットします。一般的な方法は、アクティビティごとに1つのタイムスタンプを持つ複数の計算列を作成することです。その後、最終エクスポートでこれらの列を変換し、アクティビティごとに別々の行にする必要があります。
フィルターの適用：データ範囲を制限し、パフォーマンスを向上させるため、レポートにフィルターを追加します。最低限、SRM:RequestフォームのSubmit Dateで特定の日付範囲を選択します。マルチテナント環境で運用している場合は、「Company」のフィルターも追加します。
データの実行とプレビュー：レポートを実行し、データが正しく取得されることを確認します。結合が正しいか、列に値が入力されているか、計算項目が想定したタイムスタンプを返しているかを確認します。
レポートのエクスポート：レポートの検証が完了したら、データをエクスポートします。エクスポート形式にはCSVまたはMicrosoft Excelを選択します。どちらもプロセスマイニングツールへのインポートに適しています。
最終データ変換：エクスポート後、データを横持ち形式（多数のタイムスタンプ列を持つサービスリクエストごとに1行）から縦持ち形式（アクティビティごとに1行）に変換する必要があります。スクリプト（例：Python、PowerShell）またはExcel Power Queryなどのツールを使い、タイムスタンプ列をActivityNameとEventStartTimeの2列にアンピボットします。この手順は、必要なイベントログ構造を作成するために欠かせません。

設定

前提条件：BMC Helix ITSMでレポート権限を持つユーザーアカウントが必要です。具体的には、スマートレポーティングでレポートを作成・実行する権限が必要です。また、SRM:Request、SRM:WorkInfo、AP:Signatureフォームのデータを読み取る権限も必要です。
主要フォーム：レポートは、次の主要フォームを結合して作成します：
- SRM:Request：サービスリクエストの主要な詳細を含むメインフォームです。
- SRM:WorkInfo：履行アクティビティの算出に使う作業ログのエントリを含みます。
- AP:Signature：承認関連アクティビティの追跡に必要な承認記録を含みます。
期間フィルター：必ずSRM:Request.Submit Date項目に期間フィルターを適用してください。代表性のあるサンプルとレポート性能のバランスを取るため、3～6か月分のデータを推奨します。
重要なフィルター：期間に加えて、「Company」で特定の事業体のデータに絞り込みます。プロセス分析に関係しない「Draft」などの特定のリクエストタイプやステータスを除外することもできます。
パフォーマンスに関する考慮事項：広い期間にわたって複数のフォームを結合するレポートは、生成に時間がかかる場合があります。大量のデータを扱う場合は、レポートを利用の少ない時間帯に実行するようスケジュールすることを強く推奨します。タイムアウトが発生する場合は、月単位などの小さな単位に分けて抽出してください。

a サンプルクエリ sql

/*
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 Systemデータベースサーバーへの接続を確立します。
クエリを準備：このドキュメントの「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 Systemデータベースの読み取り専用ユーザーアカウントが必要です。これにより、誤ったデータ変更を防ぎ、セキュリティのベストプラクティスに沿って運用できます。
期間フィルター：クエリには: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フォームまたはDeveloper Studioで値を確認し、必要に応じてクエリの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を使ってステータス変更を標準アクティビティ名に対応付けます。対応付けたアクティビティごとに、Service Request ID、Activity Name、変更日時を含む行を作成します。
受付イベントを生成：メインのSRM:RequestフォームにあるSubmit Dateを使い、各リクエストの初回「Service Request Submitted」アクティビティも作成します。
CSVにエクスポート：すべてのサービスリクエストと履歴の処理が完了したら、生成した行を1つのリストにまとめ、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パラメーターは、性能とメモリ使用量のバランスを取るため、1回あたり1,000件を取得する設定です。

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()

始める準備はできていますか？

このテンプレートを使ってデータ収集を効率化し、自信を持ってプロセスマイニングを始めてください。今日からサービスリクエスト管理の最適化に取り組みましょう。

改善ガイドに戻るテンプレートをダウンロード

効率を高める：今日からサービスリクエスト管理を最適化

自動化率70％を達成し、履行の遅れをなくして、ユーザー満足度を高めます。

無料トライアルを開始

クレジットカードは不要です。数分で始められます。

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

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

サービスリクエスト管理の属性

サービスリクエスト管理のアクティビティ

抽出ガイド

サービスリクエスト向けBMC Helix ITSMスマートレポーティング

ステップ

設定

a サンプルクエリ sql

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

ステップ

設定

a サンプルクエリ sql

BMC Helix REST APIを使ったPythonスクリプトによる抽出

ステップ

設定

a サンプルクエリ python

始める準備はできていますか？

効率を高める：今日からサービスリクエスト管理を最適化

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

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

サービスリクエスト管理の属性

サービスリクエスト管理のアクティビティ

抽出ガイド

サービスリクエスト向けBMC Helix ITSMスマートレポーティング

ステップ

設定

a サンプルクエリ sql

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

ステップ

設定

a サンプルクエリ sql

BMC Helix REST APIを使ったPythonスクリプトによる抽出

ステップ

設定

a サンプルクエリ python

始める準備はできていますか？

効率を高める：今日からサービスリクエスト管理を最適化

プライバシーを大切にしています