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

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

BMC Helix ITSM

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

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

このテンプレートでは、サービスリクエスト管理プロセスで収集する重要なデータ属性と、追跡すべき主要なアクティビティを確認できます。BMC Helix ITSMからデータを効率よく抽出するための手順も紹介しています。データの準備を進め、プロセスマイニングを始める際にお役立てください。

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

イベントログを初めて作成する方はこちら：プロセスマイニング用イベントログの作成方法.

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

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

これらのデータ項目は、サービスリクエスト管理プロセスを詳しく分析するためのイベントログを作成するうえで欠かせません。

5 必須 6 推奨 9 任意

	名前	説明
	アクティビティ ActivityName	サービスリクエストのライフサイクルにおいて、特定の時点で発生したイベントまたはタスクの名称です。
説明この属性は、「リクエストのレビュー中」「対応中」「サービスリクエストの解決」など、サービスリクエストのプロセスにおける具体的なステップやステータス変更を表します。各アクティビティは、サービスリクエストの一連の流れを構成する個々のイベントです。アクティビティの順序や発生頻度の分析は、プロセスマイニングの中核です。プロセスマップの作成、ボトルネックの特定、プロセスのバリアント分析に役立ちます。どのアクティビティが、どの順序で、どのくらいの頻度で発生するかを把握することは、プロセス改善に欠かせません。重要な理由アクティビティはプロセスマップを構成する要素です。追跡することでプロセスの流れを可視化して分析でき、実際の業務の進め方が明らかになります。入手先通常、「SRM:Request」フォームの「Status」および「Status Reason」フィールドの変更、または関連する対応アプリケーションのログ（例：Incident、Work Order）から取得します。例承認待ちのリクエスト対応中サービスリクエストの解決サービスリクエストのクローズ
	サービスリクエストID ServiceRequestId	各サービスリクエストを一意に識別するIDです。ライフサイクル全体を追跡するための主キーとして使われます。
説明サービスリクエストIDは、ユーザーまたはシステムから送信された個々のサービスリクエストを一意に識別します。最初の記録から最終的なクローズまで、後続のすべてのイベントを結び付ける軸となり、各サービスリクエストの経過を最初から最後まで分析できます。プロセスマイニングでは、このIDを使って各ケースのアクティビティの順序を再構成します。「リクエストの送信」「リクエストの割り当て」「サービスリクエストのクローズ」など、関連するイベントを1つのプロセスインスタンスにまとめられるため、あらゆるプロセス分析の基礎となります。重要な理由これは基本となるケース識別子です。このIDがないと、サービスリクエストの一連の流れを追跡できず、プロセスの発見や分析もできません。入手先通常、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	ユーザーが依頼したサービスのカテゴリまたは種別です。
説明サービス種別はリクエストの内容を分類するもので、「新しいソフトウェアの申請」「パスワードのリセット」「新入社員の受け入れ」などがあります。プロセスデータの絞り込みや分類に使う基本的な属性です。プロセス分析では、この属性を使ってリクエストの種別ごとにパフォーマンスを比較します。「解決に最も時間がかかるサービス種別はどれか」「手戻りが最も多いサービス種別はどれか」といった問いに答えるのに役立ちます。「解決時間」や「SLA遵守状況」のダッシュボードで重要な項目です。重要な理由サービスリクエストを種別ごとに分類し、プロセスの流れを比較できます。種別固有の問題を特定し、改善策を適切に調整するのにも役立ちます。入手先多くの場合、「SRM:Request」フォームの「Title」またはカテゴリ分類フィールドにあり、カタログで選択したサービスから取得します。例新しいハードウェアの申請ソフトウェアアクセスの申請VPNアクセスの設定
	リクエストのステータス RequestStatus	イベント発生時点でのサービスリクエストのステータスです。「In Progress」「Pending」「Closed」などがあります。
説明この属性は、ライフサイクルの各時点におけるサービスリクエストの状態を記録します。ステータスは各アクティビティの背景情報となり、「アクティビティ」属性の導出元となることもよくあります。ステータス別に分析すると、「Pending Customer」や「Waiting for Approval」などの状態にリクエストがどれだけの時間とどまっているかを把握できます。外部への依存や社内の待ち行列によるボトルネックや遅延の特定に欠かせません。「ボトルネックの特定」ダッシュボードにも直接役立ちます。重要な理由リクエストの状態を把握し、待機状態と対応中の状態に費やした時間を比較できます。ボトルネックの特定に役立ちます。入手先「SRM:Request」フォームの「Status」フィールドです。過去の値は監査ログで確認できます。例計画中進行中保留中解決済みクローズ済み
	優先度 Priority	サービスリクエストに設定された優先度です。業務への影響度と緊急度を示します。
説明優先度によって、リクエストを処理する順序や速さが決まります。一般的な値には「重大」「高」「中」「低」があります。通常、業務への影響度と緊急度を組み合わせて設定します。優先度別の分析は、優先度の高いリクエストが低いものより早く処理されているかを評価するうえで欠かせません。解決時間やSLA遵守状況のダッシュボードで重要な分析軸となり、業務上の重要度に応じてリソースが適切に配分されているかを確認できます。重要な理由プロセスで作業の優先順位が適切に設定されているか、業務への影響度が異なるリクエストに対して期待されるサービスレベルを満たしているかを評価できます。入手先「SRM:Request」フォームの「Priority」フィールドです。例重大高中低
	担当チーム AssignedTeam	現在、サービスリクエストを担当しているサポートグループまたはチームです。
説明この属性は、ヘルプデスク、ネットワークチーム、データベース管理など、リクエストの対応を担う機能グループを示します。この項目が変わると、チーム間で担当が移ったことを意味します。担当チームに基づく分析により、チーム単位のボトルネックやチーム間の引き継ぎを特定し、各サポートグループの効率を評価できます。リクエストの手戻りと再割り当て、およびトリアージ効率のダッシュボードに欠かせない属性であり、組織内で業務がどのように振り分けられているかを把握できます。重要な理由機能グループ間のプロセスの流れを分析し、振り分けの非効率な点を特定するとともに、チーム単位のパフォーマンスを測定できます。入手先サービスリクエストに関連付けられた対応レコード（作業指示書やインシデントなど）の「割り当てグループ」項目に相当します。例サービスデスクインフラストラクチャサポートアプリケーションサポート第2階層
	担当者 AssignedAgent	現在、サービスリクエストの対応を担当しているユーザーです。
説明この属性は、特定の時点でリクエストを担当しているITエージェントまたはサポート担当者を示します。1件のリクエストの処理中にこの項目が変わった場合、担当者の引き継ぎまたは再割り当てが行われたことを示します。この属性は、エージェントのパフォーマンスや業務量を分析するうえで重要です。各エージェントの対応件数、平均解決時間、再割り当ての頻度を追跡できます。このデータは、リソース管理や研修機会の特定に役立ちます。重要な理由担当エージェントを追跡することで、引き継ぎの分析、個人のパフォーマンス測定、サポートチーム内の業務量の把握が可能になります。入手先サービスリクエストに関連付けられた対応レコード（作業指示書やインシデントなど）の「担当者」または「割り当て先」項目に相当します。例ボブ・スミスアリス・ジョンソンチャーリー・ブラウン
	終了時刻 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パフォーマンスを簡単に分析し、遵守率を測定・可視化できます。入手先計算項目です。判定ロジックは次のとおりです：「Resolution Timestamp」>「SlaTargetDate」の場合はtrue、それ以外はfalse。例 truefalse
	エスカレーション済み IsEscalated	サービスリクエストがエスカレーションされたかどうかを示す真偽値です。
説明機能上または階層上のエスカレーションが行われた場合、このフラグはtrueになります。リクエストの進捗が想定どおりでない場合、SLA違反が迫っている場合、または承認や対応に上位の権限が必要な場合などに、エスカレーションが行われます。この属性は、リクエストのエスカレーション効率分析ダッシュボードの要となります。エスカレーションされたリクエストのプロセス経路を絞り込んで分析し、発生のきっかけ、エスカレーション後の解決時間、エスカレーションプロセスの有効性を把握できます。重要な理由エスカレーションが必要だったリクエストを抽出して分析できます。標準プロセスの弱点や、複雑な問題につながるきっかけの特定に役立ちます。入手先通常、単一の項目として記録されるものではありません。監査ログ内のエスカレーション関連アクティビティや、エスカレーション手順に沿った優先度・担当者の変更を確認して判定します。例 truefalse
	クローズコード CloseCode	サービスリクエストを終了した理由または最終結果を示すコードです。
説明クローズコードを使うと、サービスリクエストの解決結果を標準化して分類できます。例として、「サービスデスクで解決」「ユーザーがキャンセル」「重複リクエスト」などがあります。クローズコードを分析すると、リクエストでよく見られる結果を把握できます。ユーザーによるキャンセルが多い場合はプロセスが長すぎる可能性があり、重複が多い場合はシステムやコミュニケーションに問題がある可能性があります。この属性は、解決カテゴリの正確性ダッシュボードを支えます。重要な理由リクエストの結果を構造化データとして記録し、解決の有効性や未完了・キャンセルの理由を分析できます。入手先通常、サービスリクエストに関連付けられた対応チケットの「解決」または「終了コード」項目に記録されています。例正常に解決ユーザーによるキャンセル不要になったため終了自動解決
	引き継ぎ回数 HandoffCount	サービスリクエストが異なるエージェントまたはチームに再割り当てされた回数の合計です。
説明この計算指標は、1件のサービスリクエストについて「AssignedAgent」または「AssignedTeam」が変更された回数を数えます。引き継ぎ回数が多い場合、プロセスの分断、初回対応での解決不足、非効率な振り分けが考えられます。この属性は、リクエストあたりのエージェント平均引き継ぎ回数の重要業績評価指標（KPI）の基礎となり、リクエストの手戻りと再割り当てダッシュボードでも使われます。引き継ぎ回数の多いケースを分析すると、トリアージの改善、研修の充実、解決プロセスの効率化による遅延の削減や顧客満足度の向上につながる機会を見つけられます。重要な理由プロセスの分断やコミュニケーションにかかる負担を測定します。引き継ぎ回数が多い場合、解決時間が長くなり、プロセスの効率が低下する傾向があります。入手先一意のサービスリクエストIDごとに、「AssignedAgent」または「AssignedTeam」属性の異なる値の数を数えて算出する指標です。例 0135
	手戻りあり IsRework	サービスリクエストが前の段階に戻るなど、手戻りが発生したかどうかを示す真偽値です。
説明このフラグは、プロセスの流れにループや手戻りが発生したサービスリクエストを特定します。たとえば、「対応中」から「リクエストの確認」に戻った場合は、手戻りとみなされます。具体的な定義は、業務プロセスのロジックによって異なります。この属性は、リクエストの手戻りと再割り当て分析ダッシュボード、およびリクエスト手戻り率の重要業績評価指標（KPI）に直接役立ちます。手戻りの頻度や、最初の評価の誤り、情報不足などの主な原因を数値化して分析し、プロセスの非効率な点を明らかにできます。重要な理由理想経路から外れたケースにフラグを付けてプロセスの非効率さを数値化し、ループや作業の繰り返しにつながる根本原因を特定できます。入手先イベントログ内のアクティビティの順序から算出する属性です。プロセスの流れが前の段階に戻ったことを検出するロジックが必要です。例 truefalse
	申請チャネル SubmissionChannel	サービスリクエストの申請に使われた方法またはチャネルです。
説明この属性には、セルフサービスポータル、メール、サービスデスクへの電話、システムによる自動アラートなど、サービスリクエストの申請方法が記録されます。チャネルによって、プロセスのバリアントや解決時間が異なる場合があります。申請チャネル別にプロセスを分析すると、特定の受付方法に伴う非効率な点や優れた対応方法が見えてきます。たとえば、セルフサービスポータルからのリクエストは、最初に入力されるデータの品質が高いため、より早く解決できる場合があります。一方、メールで届いたリクエストは、手作業でのトリアージが必要になることがあります。重要な理由受付方法がプロセスの効率、データ品質、全体のサイクルタイムに与える影響を把握し、チャネルごとに改善を進めるのに役立ちます。入手先「SRM:Request」フォームまたは関連する対応チケットの「クライアント種別」や「報告元」などの項目から推定できる場合があります。例セルフサービスポータルメール電話システムによる自動生成
	申請者の部門 RequestorDepartment	リクエストを申請したユーザーが所属する事業部門または組織単位です。
説明この属性は、サービスを申請した人が所属する部門を示します。たとえば、財務、人事、ITなどです。通常、システムに登録されたユーザープロフィールから取得します。部門別にプロセスを分析すると、部門固有のニーズやリクエストの傾向を把握し、対象を絞った研修やサービス改善の機会を見つけられます。たとえば、「財務部門では、リクエストの待ち時間が長くなっていないか」といった問いに答えるのに役立ちます。重要な理由事業部門ごとにサービスの利用状況やプロセスのパフォーマンスを分析でき、部門固有の問題や傾向を把握できます。入手先通常、「SRM:Request」フォームの「依頼対象」ユーザーに関連付けられたプロフィールから取得します。例財務営業人事情報技術
	解決カテゴリ ResolutionCategory	リクエストの解決に用いた方法の分類です。
説明この属性では、ソフトウェアの修正、ユーザー研修、データ修正など、リクエストの解決方法を体系的に分類します。単純なクローズコードよりも、解決内容を詳しく示します。解決カテゴリの正確性ダッシュボードでは、最初に申請されたサービスの種類と照合し、一貫性を確認できます。解決カテゴリを分析すると、問題の傾向を把握し、問題管理を先回りして進められます。たとえば、ユーザー研修によって解決されるリクエストが多い場合、その傾向を特定できます。重要な理由解決方法の内容を把握し、繰り返し発生する問題の傾向や、問題管理・ユーザー研修を先回りして行う機会を見つけられます。入手先対応チケットの運用分類や製品分類の項目に含まれ、通常は「解決カテゴリ」と表示されます。例アカウント管理ハードウェア障害ソフトウェアのアップグレード情報提供済み

必須推奨任意

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

プロセスを正確に発見して可視化するには、これらの主要な手順や節目をイベントログに記録する必要があります。

6 推奨 8 任意

	アクティビティ	説明
	サービスリクエストのキャンセル	対応が完了する前に、依頼者またはサービスデスクがサービスリクエストを取り下げた状態です。リクエストの終了状態にあたります。
重要な理由キャンセルを追跡すると、誤ったリクエストの送信や、サービスが不要になったケースなどの傾向を把握できます。サービスカタログの改善にも役立ちます。入手先 SRM:Requestフォームのステータスが「Canceled」に変更されたことから推定します。記録 SRM:Requestの「Status」フィールドが「Canceled」に変更された更新イベントのタイムスタンプです。イベントタイプ inferred
	サービスリクエストのクローズ	サービスリクエストが正式にクローズされ、読み取り専用のアーカイブ状態に移行した状態です。解決後、確認期間が終了すると発生します。
重要な理由プロセスの最終的な終了を示すアクティビティです。「Resolved」から「Closed」までの時間を確認すると、クローズ手順の非効率な点が明らかになる場合があります。入手先 SRM:Requestフォームの最終ステータスが「Closed」に変更されたことから推定します。記録 SRM:Requestの「Status」フィールドが「Closed」に変更された更新イベントのタイムスタンプです。イベントタイプ inferred
	サービスリクエストの解決	サービスリクエストへの対応が完了し、依頼者に解決内容が伝えられた状態です。最終確認を待つか、設定された期間の経過後に自動でクローズされます。
重要な理由サービス提供サイクルの終了を示す重要な節目です。解決時間とSLA遵守状況を測定する際の主な終点となります。入手先 SRM:Requestフォームのステータスが「Resolved」または「Completed」に変更されたことから推定します。記録 SRM:Requestの「Status」フィールドが「Resolved」または「Completed」に変更された更新イベントのタイムスタンプです。イベントタイプ inferred
	サービスリクエストの送信	ユーザーが新しいサービスリクエストを作成して送信したことを示すアクティビティです。SRM:Requestフォームに初期ステータス（通常は「Submitted」）の新しいレコードが作成された時点で記録されます。
重要な理由すべてのサービスリクエストケースの開始点です。ライフサイクル全体の所要時間の測定や、リクエスト受付件数の分析に欠かせません。入手先 SRM:Requestフォームのレコード作成時刻と初期ステータス（例：「Submitted」）から、このイベントを推定します。記録 SRM:Requestフォームでステータスが「Submitted」の新しいサービスリクエストIDを特定し、その作成時刻を取得します。イベントタイプ inferred
	リクエストの割り当て	サービスリクエストの対応を担う特定の担当者またはチームに割り当てられた状態です。トリアージ段階の終了を示します。
重要な理由この節目は、トリアージ時間の測定や担当者の業務量の分析に欠かせません。再割り当てが頻繁に発生する場合、振り分けの問題やスキル不足が考えられます。入手先 SRM:Requestまたは関連する対応アプリケーションフォーム（例：WOI:WorkOrder）の「Assigned Group」または「Assignee」フィールドの監査ログから、明示的に記録できます。記録監査ログで「Assignee」フィールドに初めて空でない値が設定された時刻です。イベントタイプ explicit
	対応中	割り当てられた担当者またはチームが、サービスリクエストへの対応を開始した状態です。リクエストが待ち行列から実作業に移ったことを示します。
重要な理由付加価値を生む対応作業の開始を示します。この段階にかかる時間を分析すると、リソースの生産性や対応の複雑さを把握できます。入手先 SRM:Requestフォームのステータスが「In Progress」に変更されたことから推定します。記録 SRM:Requestの「Status」フィールドが「In Progress」に変更された更新イベントのタイムスタンプです。イベントタイプ 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
	解決策の実装完了	サービスリクエストへの対応に必要な技術作業が担当者によって完了し、正式に解決済みとする前にユーザーの確認を待っている状態です。
重要な理由技術作業の完了と正式な解決を分けて確認できます。作業完了からユーザー確認までの遅延を特定するのに役立ちます。入手先親となるSRM:Requestが「Resolved」になる前に、バックエンドの対応チケット（例：Work Order）のステータスが「Completed」に変わったことから推定できます。記録 SRM:Requestに関連付けられたバックエンドチケット（Work Order、Incidentなど）が完了と記録された時刻です。イベントタイプ inferred

推奨任意

データ抽出ガイド

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

ステップ

Smart Reportingにアクセス：BMC Helix ITSM環境にログインします。レポートのセクションに移動し、Smart Reportingを起動します。バージョンによっては、「レポート」または「Smart Reporting」と表示されます。
新しいレポートを作成：Smart Reportingの画面で、新しいレポートを作成するオプションを選びます。種類として「レポート」を選択します。
データソースとビューを選択：データソースの選択画面が表示されたら、主に使用するAR Systemデータソースを選びます。ビューは、通常SRM:Requestフォームを基にしたService Requestビューを検索して選択します。
フォームを追加（結合）：ライフサイクル全体を把握するには、メインのSRM:Requestフォームを関連フォームと結合します。「データ」タブで、次のフォームを結合します。
- SRM:WorkInfo（SR ID+ = Request Numberで結合）：対応アクティビティや作業ログの詳細を取得します。
- AP:Signature（Request = SRInstanceIDで結合）：承認や却下など、承認に関するイベントを取得します。この結合にはカスタム設定が必要な場合があります。
レポートの列を設定：結合したフォームから必要な項目をドラッグし、「列」エリアに配置します。SRM:RequestのRequest Number、Submit Date、ステータス、説明、Priority、Assigned To、Assigned Groupのほか、結合したフォームの関連項目も含めます。
アクティビティ用の計算フィールドを作成：この方法では、各アクティビティのタイムスタンプを表す計算フィールドを複数作成します。「データ」タブで、アクティビティごとに計算フィールドを作成します。例：
- 申請日時：Submit Dateフィールドをそのまま使います。
- 承認日時：AP:SignatureフォームのSignature Dateを使います。
- 作業開始日時：SRM:WorkInfoのSubmit Dateをリクエスト番号ごとにグループ化し、MIN(Submit Date)を使います。
UNION用にレポートを構成：Smart Reportingには、SQLのような単純な「UNION ALL」ボタンはありません。1つのレポートを作成し、高度な関数やサブクエリを使ってデータをピボットします。一般的な方法は、各アクティビティのタイムスタンプに対応する計算列を複数作成することです。最終的なエクスポートでは、これらの列をアクティビティごとの行に変換する必要があります。
フィルターを適用：データ範囲を絞り、処理速度を高めるため、レポートにフィルターを追加します。最低限、SRM:RequestフォームのSubmit Dateで特定の期間を指定します。複数テナント環境の場合は、「会社」のフィルターも追加します。
レポートを実行してデータを確認：レポートを実行し、データが正しく取得されていることを確認します。結合が正しいか、列に値が入っているか、計算フィールドが想定どおりのタイムスタンプを返しているかを確認します。
レポートをエクスポート：内容を確認したら、データをエクスポートします。プロセスマイニングツールに取り込みやすいCSVまたはMicrosoft Excel形式を選びます。
データを最終変換：エクスポート後、データを横持ち形式（サービスリクエストごとにタイムスタンプ列が複数ある形式）から縦持ち形式（アクティビティごとに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か月分のデータを推奨します。
重要なフィルター：期間に加え、「会社」で絞り込み、特定の事業体のデータを抽出します。プロセス分析に不要な「下書き」などのリクエスト種別やステータスも、必要に応じて除外してください。
処理速度に関する注意：複数のフォームを広い期間にわたって結合するレポートは、生成に時間がかかる場合があります。大量のデータを扱う場合は、利用の少ない時間帯に実行するようスケジュールすることを強く推奨します。タイムアウトが発生する場合は、抽出期間を月単位などに分割してください。

クエリの例 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データベースサーバーに接続します。
クエリを準備：この文書の「クエリ」セクションにある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などの大きなテーブルや監査ログに対する直接クエリは、システムリソースを多く消費する場合があります。システムへの影響を抑えるため、利用の少ない時間帯に抽出を実行してください。

クエリの例 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を1件ずつ処理します。各IDについて、設定した監査ログフォームに2回目のAPI呼び出しを行い、そのリクエストのステータス変更履歴を取得します。
データをイベントログに変換：監査ログの各レコードについて、STATUS_ACTIVITY_MAPを使い、ステータス変更を標準的なアクティビティ名に対応付けます。対応付けたアクティビティごとに、サービスリクエストID、アクティビティ名、変更日時を含む行を作成します。
申請イベントを作成：メインのSRM:RequestフォームにあるSubmit Dateを使い、各リクエストの最初の「サービスリクエスト申請」アクティビティも作成します。
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件に設定されています。

クエリの例 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 Smart Reporting

ステップ

設定

クエリの例 sql

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

ステップ

設定

クエリの例 sql

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

ステップ

設定

クエリの例 python

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

サービスリクエスト管理を改善し、業務効率を高める