> 継続的なプロセス改善 > サービス依頼管理 > Ivanti Service Manager > データテンプレート

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

Ivanti Service Manager

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

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

このテンプレートでは、サービスリクエスト管理のプロセスマイニングに必要なデータを収集する方法を詳しく説明します。収集する属性や記録するアクティビティに加え、システムからデータを抽出する手順も紹介します。分析に使うイベントログの作成にお役立てください。

詳細な分析に推奨される属性
プロセスの発見に必要な主なアクティビティ
ソースシステムからデータを抽出する手順

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

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

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

サービスリクエスト管理プロセスを詳しく分析するには、これらのデータ項目をイベントログに含めることをおすすめします。

5 必須 9 推奨 7 任意

	名前	説明
	アクティビティ名 ActivityName	サービスリクエストのライフサイクルにおいて、特定の時点で発生したイベントまたはタスクの名前。
説明この属性は、サービスリクエストのプロセスにおける特定のステップやステータス変更を示します。例として、「承認申請の送信」や「サービスリクエストの解決」があります。アクティビティの順序や頻度を分析することは、プロセスの流れを理解し、ボトルネックを特定し、標準手順からの逸脱を見つけるうえで基本となります。重要な理由プロセスマップ上のステップを定義し、プロセスの流れを可視化・分析できます。手戻りやボトルネック、逸脱の特定にも役立ちます。入手先通常、Ivanti Service Managerのステータス変更、ジャーナルエントリ、監査ログのイベント説明から取得します。例サービスリクエストの作成リクエストの承認サービスリクエストの解決サービスリクエストのクローズ
	イベント時刻 EventTime	特定のアクティビティまたはイベントが発生した時刻を示すタイムスタンプ。
説明イベント時刻は開始時刻とも呼ばれ、アクティビティがシステムに記録された正確な日時を示します。イベントを正しい順序に並べるために欠かせないタイムスタンプであり、サイクルタイム、待ち時間、アクティビティの所要時間など、時間に基づくプロセスマイニング分析の基礎となります。重要な理由このタイムスタンプは、イベントを時系列に並べ、所要時間に基づくすべての指標を計算するために必要です。これらの指標はパフォーマンス分析の要となります。入手先監査ログ、ジャーナルエントリ（例：Journal.CreatedDateTime）、またはサービスリクエストに関連付けられたステータス変更レコードに記録されています。例 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
	サービスリクエストID ServiceRequestID	各サービスリクエストを一意に識別するID。
説明サービスリクエストIDは、利用者またはシステムが送信した個々のサービスリクエストを一意に識別します。最初の記録から最終的なクローズまで、後続のすべてのイベントを結び付ける軸となり、各サービスリクエストの流れを最初から最後まで分析できます。重要な理由関連するすべてのアクティビティを1つのプロセスインスタンスに結び付ける、基本となるケース識別子です。プロセス全体を分析できます。入手先 Service Requestビジネスオブジェクトの主キーです。ServiceReqテーブルのServiceReqNumberとして格納されていることがよくあります。例 SR-0012345SR-0012346SR-0012347
	ソースシステム SourceSystem	データの抽出元となるシステム。
説明この属性は、プロセスデータの取得元を示します。このビューでは値は固定で、すべてのデータがIvanti Service Managerから取得されたことを表します。複数のシステムのデータを統合する環境では、データの出所とコンテキストを明確にするために重要です。重要な理由データの出所に関する重要なコンテキストを示し、特に複数のシステムを利用する環境で、分析結果を正しいソースシステムに関連付けられます。入手先通常、データ抽出時にデータセットの取得元を示す固定値として追加されます。例 Ivanti Service Manager
	最終データ更新 LastDataUpdate	ソースシステムからデータを最後に更新した日時を示すタイムスタンプ。
説明この属性は、Ivanti Service Managerからデータを最後に抽出した日時を示します。分析対象データの鮮度を把握できるため、対象期間や次回の更新予定を確認できます。重要な理由データの更新時期を把握できます。利用可能な最新のプロセスパフォーマンス情報に基づいて判断するうえで重要です。入手先データ抽出時に生成され、データセットに記録される値です。例 2024-05-20T12:00:00Z2024-05-21T12:00:00Z
	SLAステータス SLAStatus	サービスリクエストがSLA期限内に解決されたかどうかを示します。
説明この派生属性は、解決時刻とSLA期限を比較し、各サービスリクエストを「達成」または「未達」として示します。「SLA遵守状況」ダッシュボードと「サービスレベル合意の遵守率」という重要業績評価指標（KPI）の基礎となる項目です。各ケースのResolutionDateTimeとSLADeadlineを比較して判定します。重要な理由サービスに関する約束に対するパフォーマンスを直接測定します。サービス品質の評価とユーザーの信頼維持に欠かせません。入手先「ResolutionDateTime」と「SLADeadline」を比較して算出します。ResolutionDateTime <= SLADeadlineの場合は「達成」、それ以外は「未達」です。例達成未達
	SLA期限 SLADeadline	サービスリクエストの解決予定日時です。
説明 SLA期限は、サービスレベル合意（SLA）を満たすためにサービスリクエストを解決すべき日時です。通常、リクエストの優先度や種類などに基づいて設定されます。実際の解決時刻とこの期限を比較することで、SLAの遵守状況を測定できます。重要な理由実際のパフォーマンスを測る基準となり、SLAの遵守率の算出や、期限に間に合わない可能性のあるリクエストの特定に直接役立ちます。入手先 Ivanti内で算出されるフィールドであることが多く、「ResolutionTargetDateTime」など、サービスレベル合意またはサービス提供項目に関連するフィールドに保存されます。例 2023-10-27T17:00:00Z2023-10-28T09:00:00Z2023-11-02T12:00:00Z
	イベント終了時刻 EventEndTime	アクティビティが完了した時刻を示すタイムスタンプです。
説明イベント終了時刻は、アクティビティの完了時刻を示します。イベント時刻（開始）からイベント終了時刻までの時間が、そのアクティビティの処理時間です。どのステップに最も時間がかかっているかを特定し、非効率な箇所や改善点を見つけるうえで重要です。重要な理由個々のアクティビティの所要時間を算出できるため、プロセスのボトルネックや長時間にわたるタスクの特定に役立ちます。入手先独立したフィールドとして存在しない場合があります。同じケース内で次に実行されるアクティビティの開始時刻が使われることもよくあります。例 2023-10-26T10:05:00Z2023-10-26T11:45:00Z2023-10-28T09:00:00Z
	サービスリクエストのステータス ServiceRequestStatus	イベント発生時点でのサービスリクエストのステータスです。
説明この属性は、サービスリクエストの状態を「記録済み」「進行中」「保留中」「解決済み」「クローズ」などで示します。ステータスの変化が、プロセスログ上のアクティビティを定義することもよくあります。各ステータスでの滞留時間を分析すると、たとえばリクエストが「保留中」のまま長時間止まっているなど、ボトルネックを特定できます。重要な理由各時点でのリクエストの状態を把握できます。特定の状態での滞留時間を算出し、プロセスの停滞を見つけるうえで欠かせません。入手先サービスリクエストオブジェクトの標準フィールドで、一般に「Status」という名前です。例記録済みアクティブ顧客待ち対応完了クローズ
	サービスリクエストの種類 ServiceRequestType	サービスリクエストの分類またはカテゴリです。
説明この属性は、サービスリクエストを「ハードウェアの申請」「ソフトウェアのインストール」「パスワードのリセット」などに分類します。サービスの種類ごとにプロセスのパフォーマンス、サイクルタイム、SLAの遵守状況を比較できるため、分析に欠かせない項目です。こうした違いを把握することで、プロセス改善の内容を調整し、リソースをより効果的に配分できます。重要な理由リクエストの種類ごとにプロセスを分けて分析すると、遅延や手戻り、SLA違反が起きやすい種類を特定できます。入手先通常はサービスリクエストのビジネスオブジェクトにあるフィールドで、「Service」や「Category」などの名前が使われます。具体的なフィールド名（「SvcReqTmplLink_Category」など）は、Ivanti Service Managerの文書をご確認ください。例新しいハードウェアの申請ソフトウェアへのアクセスアカウントの変更情報の問い合わせ
	優先度 Priority	サービスリクエストに設定された優先度です。
説明優先度は、サービスリクエストの緊急度を「低」「中」「高」「重大」などの段階で示します。この属性を使うと、優先度の高いリクエストがプロセス内で適切に優先処理されているかを評価できます。優先度ごとにサイクルタイムやSLAの遵守状況を比較し、優先順位のルールが意図どおりに機能しているかを確認します。重要な理由優先順位付けの有効性を評価し、優先度の高いリクエストが低いリクエストより早く解決されているかを確認するうえで重要です。入手先サービスリクエストオブジェクトの標準フィールドで、通常は「Priority」という名前です。例 1 - 重大2 - 高3 - 中4 - 低
	割り当て先チーム AssignedTeam	サービスリクエストを現在担当しているサポートチームまたはグループです。
説明この属性は、各時点でサービスリクエストを担当するチームを示します。チーム間の引き継ぎ、各チームでの対応時間、チームごとの処理件数を分析すると、業務負荷の分布やボトルネック、チームのパフォーマンスを把握できます。SLAの遵守状況や担当者の業務負荷を示すダッシュボードにも直接役立ちます。重要な理由担当チームと引き継ぎを追跡し、チーム間の遅延や業務負荷の偏り、プロセスのボトルネックとなっているチームを分析できます。入手先通常はサービスリクエストオブジェクトの「OwnerTeam」などのフィールド、または関連する割り当てレコードに保存されています。例 ITサービスデスクネットワーク運用人事サポート施設管理
	割り当て先担当者 AssignedAgent	サービスリクエストを担当する個人ユーザーまたは担当者です。
説明割り当て先担当者は、サービスリクエストの対応を担う個人です。この属性を使うと、個人単位でパフォーマンスや業務負荷の配分を分析し、研修が必要な領域を特定できます。担当者間の再割り当てを追跡することは、「リクエストあたりの平均再割り当て回数」などの重要業績評価指標（KPI）の算出や、プロセスの非効率な箇所の把握に役立ちます。重要な理由個人ごとの業務負荷やパフォーマンス、再割り当ての傾向を分析できます。研修やスキル、最初の振り分けに関する問題の把握にも役立ちます。入手先通常はサービスリクエストオブジェクトの「Owner」などのフィールドにあります。再割り当てのたびに値が変わる可能性があるため、イベントログで追跡してください。例アリス・ジョンソンボブ・ウィリアムズチャーリー・ブラウンダイアナ・プリンス
	解決日時 ResolutionDateTime	サービスリクエストが正式に解決された日時です。
説明ケース単位の属性で、サービスの提供または問題の解決が完了した最終時刻を示します。リクエストが正式にクローズされる前の時刻です。このタイムスタンプは、サービスリクエストのエンドツーエンドのサイクルタイムを算出する際の主な終了時点となります。プロセス全体の効率やSLAの遵守状況を測定するうえで重要です。重要な理由主要なプロセスのサイクルタイムを算出する終了時点を定めます。サービス提供の効率を測る重要業績評価指標（KPI）に関わる項目です。入手先サービスリクエストオブジェクトにある専用のタイムスタンプフィールドで、「ResolvedDateTime」などの名前が使われます。例 2023-10-28T10:15:00Z2023-10-29T11:00:00Z2023-11-01T16:30:00Z
	ベンダー名 VendorName	リクエストの解決に関わった外部ベンダーの名前です。
説明この属性は、サービスリクエストの対応や完了を支援する外部ベンダーを示します。ベンダーごとのパフォーマンスを測定・比較できるため、「外部ベンダーの対応時間」ダッシュボードに欠かせません。ベンダーとの関係管理や、外部依存によるボトルネックの特定にも役立ちます。重要な理由外部ベンダーのパフォーマンスと、サービスリクエスト全体の解決時間への影響を分析し、ベンダー管理に役立てられます。入手先サービスリクエストに関連付けられたTaskオブジェクトのフィールド、またはベンダーが割り当てられている場合はサービスリクエスト自体の専用フィールドに記録されている可能性があります。例 DellサポートOracleコンサルティングMicrosoft Premiernull
	再オープン回数 ReopenCount	解決済みのサービスリクエストが再オープンされた回数です。
説明この属性は、サービスリクエストが「解決済み」または「クローズ」から「アクティブ」に戻るたびに増えるカウンターです。再オープン回数が多い場合、初回の解決品質が低い、解決が不十分、または問題が再発している可能性があります。「サービスリクエストの手戻り率」という重要業績評価指標（KPI）の算出に直接役立ちます。重要な理由手戻りを直接測定し、解決品質を示す重要な指標です。回数が多い場合、最初の対応で問題を解決できていない可能性があります。入手先通常はサービスリクエストオブジェクトのカウンターフィールドで、ステータスが所定の条件で変わるとビジネスルールによって値が増えます。「ReopenCounter」などの名前が使われます。例 0123
	割り当て回数 AssignmentCount	サービスリクエストが割り当てまたは再割り当てされた合計回数です。
説明この計算指標は、サービスリクエストごとに割り当て関連のアクティビティ（「チームに割り当て」「担当者に割り当て」など）の回数を数えます。「チケットのたらい回し」とも呼ばれる再割り当てが多い場合、振り分けの非効率、初回の問い合わせで解決できていないこと、またはチームの担当範囲が不明確であることが考えられます。「リクエストあたりの平均再割り当て回数」という重要業績評価指標（KPI）の算出に欠かせない属性です。重要な理由非効率な引き継ぎや振り分けの問題を数値で把握できます。回数が多い場合、解決時間の長期化やユーザーの不満につながっている可能性があります。入手先データ準備時に、各ServiceRequestIDについて割り当て関連のアクティビティの発生回数を数えて算出します。例 12345
	受付チャネル Channel	サービスリクエストの申請に使われた方法またはチャネルです。
説明受付チャネルは、セルフサービスポータル、メール、電話、または別のシステムによる自動登録など、サービスリクエストがどのように作成されたかを示します。チャネルごとのリクエスト件数や解決時間を分析すると、効率のよいチャネルや、プロセスの改善またはユーザー研修が必要なチャネルを把握できます。重要な理由ユーザーの行動やチャネルの効率を把握し、サービス提供の方針や自動化の可能性を検討する際に役立ちます。入手先通常は、サービスリクエストオブジェクトの「Source」や「CreatedBy」に相当するフィールドに保存されています。例セルフサービスメール電話直接入力
	手戻りあり IsRework	サービスリクエストに手戻りが発生したかどうかを示す真偽値フラグです。
説明この計算フラグは、解決後にリクエストが再オープンされた場合や、特定のアクティビティが繰り返されている場合など、手戻りの兆候があるとtrueになります。「サービスリクエストの手戻り率」という重要業績評価指標（KPI）の算出を簡単にし、「手戻りと再割り当てのフロー」などのダッシュボードで非効率なプロセスのケースを絞り込めます。重要な理由予定外の追加作業が必要となったリクエストの件数を簡単に特定・定量化し、品質や効率の問題を明らかにできます。入手先データから算出します。「ReopenCount」属性が0より大きいかどうかを判定する方法や、「担当者に割り当て」イベントが複数回発生するなど、特定のアクティビティの並びを検出する方法があります。例 truefalse
	申請者の部門 RequestorDepartment	サービスリクエストを申請したユーザーが所属する事業部門です。
説明この属性は、サービスリクエストを開始した従業員またはシステムの部門を示します。「営業」「財務」「人事」などが該当します。組織内の部門ごとに、サービスの品質や需要を分析できます。たとえば、特定の部門で解決に時間がかかっているか、リクエスト件数が多いかを把握できます。重要な理由事業部門ごとのサービス利用状況や品質を分析し、部門固有の問題や傾向を特定できます。入手先通常は、サービスリクエストに紐づく申請者のユーザープロフィールから取得します。「Profile.Employee」オブジェクトの「Department」フィールドなどが該当します。例財務営業マーケティング情報技術
	解決カテゴリ ResolutionCategory	サービスリクエストの解決方法を分類したものです。
説明解決カテゴリを使うと、サービスリクエストの最終的な解決方法を体系的に分類できます。通常はカテゴリやサブカテゴリなどの階層で構成され、根本原因の分析や傾向の報告に役立ちます。たとえば、繰り返し発生する問題や、よく行われる対応を特定し、サービスの改善やナレッジベース記事の作成に役立てられます。重要な理由解決内容の傾向を把握し、よくある問題やサービスの改善機会、自動化の候補を特定できます。入手先通常は、解決時に入力する分類フィールドに保存されています。「ResolutionCategory」や、カスタムのクローズコードフィールドなどが該当します。例ユーザー研修が必要ソフトウェアを導入ハードウェアを修理アクセス権を付与

必須推奨任意

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

プロセスを正確に把握して分析するために、これらの重要なステップや節目をイベントログに記録してください。

5 推奨 9 任意

	アクティビティ	説明
	サービスリクエストのクローズ	サービスリクエストが正式にクローズされ、それ以上の対応ができない状態です。「解決済み」の状態が一定期間続いた後に自動でクローズされることが多く、ライフサイクルの最終段階を示します。
重要な理由このアクティビティはプロセスの最終終了点です。「解決済み」から「クローズ済み」までの時間から、確認の遅れやシステムの自動処理にかかる時間を把握できます。入手先 Service Requestレコードの「Status」フィールドが「クローズ済み」に変わったことと、関連するタイムスタンプから推定します。記録監査履歴から「Status」フィールドが「クローズ済み」に更新されたことを検出します。イベントタイプ inferred
	サービスリクエストの作成	新しいリクエストが正式に送信され、Ivantiに記録された時点で、このアクティビティがサービスリクエストのライフサイクルの開始を示します。Service Requestビジネスオブジェクトに新しいレコードが作成され、一意のサービスリクエストIDが付与されたときに、このイベントが記録されます。
重要な理由これはプロセスの主な開始イベントです。この時点から解決までの時間を分析することは、全体のサイクルタイムとプロセス効率を測定するうえで基本となります。入手先 Service Requestレコードの作成タイムスタンプから取得します（例：ServiceReqビジネスオブジェクトのCreatedDateTimeフィールド）。記録 ServiceReqテーブルで、作成タイムスタンプによって識別されるレコード作成イベント。イベントタイプ explicit
	サービスリクエストの解決	サービスリクエストが解決し、解決策が利用者に提示された状態です。ステータスが「解決済み」に変わったときに記録される主要な節目であり、多くの場合、SLAの計測が停止します。
重要な理由解決時間とSLA遵守状況を測定するうえで、重要な終了点です。作成からこのアクティビティまでの時間は、プロセスのパフォーマンスを示す主要なKPIです。入手先 Service Requestレコードの「Status」フィールドが「解決済み」に変わったことと、関連するタイムスタンプから推定します。記録監査履歴から「Status」フィールドが「解決済み」に更新されたことを検出します。イベントタイプ inferred
	チームへのリクエスト割り当て	サービスリクエストが対応を担当する特定のサポートチームに割り当てられた状態です。Service Requestレコードの「OwnerTeam」フィールドに値が設定されたとき、または値が変更されたときに記録されます。
重要な理由このイベントは、チームごとのパフォーマンスや作業負荷の配分、チーム間の引き継ぎ時間を分析するうえで重要です。プロセスのボトルネックとなっているチームを特定できます。入手先サービスリクエストの監査履歴またはジャーナルに記録された「OwnerTeam」フィールドの変更を追跡します。記録「OwnerTeam」フィールドの更新イベント。通常、監査証跡に記録されます。イベントタイプ explicit
	担当者へのリクエスト割り当て	特定の担当者がサービスリクエストを引き受けた状態です。通常、個々の担当者を示す「Owner」フィールドに初めて値が設定されたとき、または値が更新されたときに推定されます。
重要な理由最初の待ち時間やキューでの待機が終わる時点を示します。このアクティビティまでの時間を測定すると、リソース配分の問題を特定でき、担当者の作業負荷ダッシュボードにも役立ちます。入手先監査履歴に記録されたService Requestレコードの「Owner」フィールドへの値の設定または変更から推定します。記録レコード作成後またはチームへの割り当て後に、「Owner」フィールドに担当者名が初めて設定された時点のタイムスタンプ。イベントタイプ inferred
	サービスリクエストのキャンセル	サービスリクエストが解決前に利用者または担当者によってキャンセルされた状態です。ステータスが「キャンセル済み」または「取り下げ」に変わったときに記録される、別の終了状態です。
重要な理由これは標準的な流れとは異なるプロセスの終了を示します。リクエストがキャンセルされた理由を分析すると、リクエストの手順自体の問題や、利用者のニーズの変化が明らかになる場合があります。入手先 Service Requestレコードの「Status」フィールドが「キャンセル済み」に変わったことから推定します。記録監査履歴から「Status」フィールドが「キャンセル済み」に更新されたことを検出します。イベントタイプ inferred
	サービスリクエストの再オープン	解決済みのサービスリクエストが、問題の継続や解決策への不満を理由に再開された状態です。ステータスが「解決済み」から「アクティブ」や「割り当て済み」などに戻ったときに記録されます。
重要な理由このアクティビティは、手戻りや初回解決の品質不足を直接示します。再オープンのイベントを分析すると、プロセスの弱点を特定し、サービスリクエストの手戻り率KPIを改善できます。入手先監査履歴で「Status」フィールドが「解決済み」または「クローズ済み」からアクティブなステータスに変わったことから推定します。記録終了状態（「解決済み」、「クローズ済み」）からオープン状態（「アクティブ」、「割り当て済み」）へのステータス変更。イベントタイプ inferred
	サービスリクエストへの対応完了	サービスリクエストへの対応に必要なすべてのタスクが、担当者またはシステムによって完了した状態です。ステータスが「対応完了」に変わったときに記録され、多くの場合、最終的な「解決済み」になる前に発生します。
重要な理由この節目は、技術面または手順上の作業が完了したことを示します。最終確認とクローズの前に行われる実作業の時間を測定するうえで重要です。入手先 Service Requestレコードの「Status」フィールドが「対応完了」に変わったことから推定します。記録レコードの履歴から検出される、「Status」フィールドの「対応完了」への変更。イベントタイプ inferred
	リクエストの承認	サービスリクエストに必要な承認がすべて完了し、対応を進められる状態です。承認ワークフローが正常に終了してリクエストのステータスが変わったときに、このイベントが記録されます。
重要な理由このアクティビティは重要な節目であり、承認段階の終了と対応段階の開始を示します。承認プロセス自体の効率を測定できます。入手先ステータスが「承認待ち」から「承認済み」または「対応完了」に変わったことから推定します。FRS_Approvalビジネスオブジェクトに明示的なイベントとして記録される場合もあります。記録 Service Requestレコードの「Status」フィールドが、承認中の状態からアクティブな状態に変わったこと。イベントタイプ inferred
	優先度の変更	サービスリクエストの優先度が、最初の作成後に更新された状態です。フィールド単位の変更を記録する監査ログまたは履歴から取得します。
重要な理由優先順位付けの有効性を確認するには、優先度の変更を追跡することが重要です。エスカレーションが適切に管理されているか、最初の優先順位付けが正確かを判断できます。入手先 Service Requestレコードの監査履歴から取得する明示的なイベントです。「Priority」フィールドの変更が記録されます。記録システムの監査証跡に記録された「Priority」フィールドの更新イベント。イベントタイプ explicit
	利用者からの情報提供	依頼者から必要な情報が提供され、担当者が作業を再開できる状態です。リクエストのステータスが「顧客待ち」からアクティブな状態に戻ったときに記録されます。
重要な理由このイベントにより、情報照会から回答受領までの一連の流れが完了します。情報の照会から受領までの時間は、プロセスの遅延や手戻りのループを分析するうえで重要です。入手先 Service Requestの「Status」フィールドが「顧客待ち」から「アクティブ」や「進行中」などに変わったときに推定します。記録「利用者からの回答待ち」の状態からアクティブな状態へのステータス変更を検出します。イベントタイプ inferred
	利用者への情報照会	割り当てられた担当者が対応を進めるために、依頼者から追加情報を得る必要がある状態です。リクエストのステータスが「顧客待ち」などに更新されたときに記録されます。
重要な理由このアクティビティは、最初に提供された情報の不足による遅延を示します。発生頻度と所要時間を追跡することは、情報照会の影響分析やプロセス改善の領域を特定するうえで重要です。入手先 Service Requestレコードのステータスが「顧客待ち」や「保留」などに変わったことから推定します。記録「Status」フィールドが、指定された「利用者からの回答待ち」の状態に変わったことを検出します。イベントタイプ inferred
	外部ベンダーへの依頼	サービスリクエストへの対応が外部ベンダーまたは第三者に引き継がれた状態です。通常、ステータスが「第三者待ち」などに変わったときに記録されます。
重要な理由このアクティビティは、ベンダーのパフォーマンスとサイクルタイム全体への影響を測定するうえで欠かせません。ベンダーに起因する遅延を分析し、外部ベンダーのアクティビティ所要時間ダッシュボードに役立てられます。入手先 Service Requestレコードのステータスが「第三者待ち」や「ベンダー待ち」などに変わったことから推定します。記録「Status」フィールドが、指定された「ベンダー待ち」の状態に変わったことを検出します。イベントタイプ inferred
	承認申請の送信	サービスリクエストの対応を進める前に必要な承認が申請された状態です。通常、リクエストのステータスが「申請済み」または「承認待ち」に変わったことから推定され、承認ワークフローが開始されます。
重要な理由このアクティビティを追跡すると、承認段階での遅延を特定できます。ここでの長い待ち時間は大きなボトルネックとなり、解決時間全体や利用者の満足度に影響する可能性があります。入手先 Service Requestレコードのステータスが「申請済み」や「承認待ち」などに変わったことから推定します。FRS_ApprovalまたはFRS_ApprovalVoteTrackingビジネスオブジェクトから取得する場合もあります。記録 Service Requestレコードの「Status」フィールドが、承認待ちの状態に変わったこと。イベントタイプ inferred

推奨任意

データ抽出ガイド

Ivanti Service Managerからデータを取得する方法

ステップ

サービスリクエストとその監査履歴への読み取りアクセス権を持つロールで、Ivanti Service Managerにログインします。
メインナビゲーションパネルから「Service Request」ワークスペースを開きます。
この手順では、2つのデータを別々にエクスポートし、外部で結合します。1つ目では作成イベントと基本属性を取得し、2つ目では変更履歴の詳細を取得します。
1つ目のエクスポート（作成イベント）：ServiceReqビジネスオブジェクトで新しい保存検索を作成します。CreatedDateTimeにフィルターを設定し、分析対象期間内に作成されたサービスリクエストを選択します。例：過去6か月。
作成イベント用の検索で、RecId、ServiceReqNumber（ServiceRequestID用）、CreatedDateTime（EventTime用）、SvcReqTmplLink_Category（ServiceRequestType用）、OwnerTeam、担当者、Priority、ステータス、ResolutionDateTime、TargetDateTime（SLADeadline用）の列を設定します。
検索を実行し、グリッドのエクスポート機能（通常はディスクまたは矢印のアイコン）を使ってCSVファイルにエクスポートします。ファイル名は ServiceRequests.csv にします。
2つ目のエクスポート（監査履歴イベント）：今度はフィールドの変更を記録する FRS_data_audit_history ビジネスオブジェクトで、新しい保存検索を作成します。
サービスリクエストに関する変更だけを含めるように検索を絞り込みます。ParentObjectType が ServiceReq と等しいフィルターを追加します。また、先ほどと同じ分析対象期間で AuditDate を絞り込みます。
監査検索の列には、サービスリクエストとの紐付けに使う ParentLink_RecID、FieldName、OldValue、NewValue、EventTime用の AuditDate を設定します。このデータを2つ目のCSVファイル AuditHistory.csv にエクスポートします。
データの変換と結合：エクスポートしたCSVファイルを結合し、1つのイベントログに整形します。ExcelのPower Query、Python、データベースツールなどのデータ準備ツールを使い、次の手順を実行します。
- ServiceRequests.csvとAuditHistory.csvの両方を読み込みます。
- ServiceRequests.csvを使い、各リクエストの「サービスリクエスト作成」イベントを作成します。
- AuditHistory.csvを使い、その他のイベントを作成します。FieldNameとNewValueの値を必要なアクティビティ名に対応付けます。たとえば、FieldNameが「ステータス」で、NewValueが「解決済み」の場合、ActivityNameは「サービスリクエスト解決済み」とします。
- 監査ファイルの ParentLink_RecID とサービスリクエストファイルの RecId を使って、変換した監査イベントをサービスリクエストのデータに結合します。これにより、各イベントにケース単位の属性が追加されます。
- 「作成」イベントと監査履歴から作成したイベントを1つのテーブルにまとめます。
最終的な結合テーブルに、必須の列見出し ServiceRequestID、ActivityName、EventTime、SourceSystem、LastDataUpdateと、その他の推奨属性を設定します。すべてのタイムスタンプの形式が統一されていることを確認します。
最終的なイベントログを1つのCSVファイルとして保存します。これでアップロードできます。

設定

ビジネスオブジェクト：この方法では、リクエストの主要データを含むServiceReqと、イベントデータを含むFRS_data_audit_historyの2つのビジネスオブジェクトからエクスポートします。
期間フィルター：データ量を抑えるため、両方のエクスポートに期間フィルターを設定してください。ServiceReqではCreatedDateTimeフィールドを、FRS_data_audit_historyではAuditDateフィールドを使います。初回の分析では、3～6か月分をおすすめします。
監査履歴の主なフィルター：
- サービスリクエストに関連する変更だけを抽出するため、ParentObjectTypeを'ServiceReq'に絞り込みます。
- 必要に応じてFieldNameを絞り込み、'Status'、'Owner'、'OwnerTeam'、'Priority'など、プロセスに関係するフィールドだけを含めることもできます。エクスポートするデータ量を大幅に減らせます。
前提条件：Ivanti Service Managerで保存済み検索を作成し、ServiceReqおよびFRS_data_audit_historyビジネスオブジェクトからデータをエクスポートできる権限を持つユーザーアカウントが必要です。
パフォーマンスに関する注意：FRS_data_audit_historyテーブルは非常に大きくなる場合があります。期間を十分に絞り込まずにエクスポートすると、Ivantiアプリケーションのパフォーマンスに影響し、タイムアウトが発生する可能性があります。必要に応じて、月単位または四半期単位に分けてエクスポートしてください。

クエリの例 sql

-- This script represents the transformation logic to be applied in a data preparation tool (e.g., Power Query, Python, SQL) after exporting the two CSV files from Ivanti.

-- Step 1: Define the 'Service Request Created' events from the ServiceRequests.csv export.
SELECT
    sr.ServiceReqNumber AS ServiceRequestID,
    'Service Request Created' AS ActivityName,
    sr.CreatedDateTime AS EventTime,
    'Ivanti' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    sr.SvcReqTmplLink_Category AS ServiceRequestType,
    sr.OwnerTeam AS AssignedTeam,
    sr.Owner AS AssignedAgent,
    sr.Priority,
    sr.Status AS ServiceRequestStatus,
    sr.ResolutionDateTime AS ResolutionDateTime,
    sr.TargetDateTime AS SLADeadline,
    DATEDIFF(hour, sr.CreatedDateTime, sr.ResolutionDateTime) AS CycleTime,
    CASE WHEN sr.ResolutionDateTime IS NOT NULL AND sr.ResolutionDateTime <= sr.TargetDateTime THEN 'Met' ELSE 'Breached' END AS SLAStatus,
    sr.RecId -- Internal key for joining
FROM
    ServiceRequests_Export sr -- Represents the ServiceRequests.csv file

UNION ALL

-- Step 2: Transform records from AuditHistory.csv into specific activities and join with service request attributes.
SELECT
    sr.ServiceReqNumber AS ServiceRequestID,
    CASE
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Submitted' THEN 'Request Submitted for Approval'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Approved' THEN 'Request Approved'
        WHEN audit.FieldName = 'OwnerTeam' AND audit.OldValue IS NOT NULL THEN 'Request Assigned to Team'
        WHEN audit.FieldName = 'Owner' AND audit.OldValue IS NOT NULL THEN 'Request Assigned to Agent'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Waiting for Customer' THEN 'Information Requested from User'
        WHEN audit.FieldName = 'Status' AND audit.OldValue = 'Waiting for Customer' THEN 'Information Provided by User'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Waiting for 3rd Party' THEN 'External Vendor Engaged'
        WHEN audit.FieldName = 'Priority' THEN 'Priority Changed'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Fulfilled' THEN 'Service Request Fulfilled'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Resolved' THEN 'Service Request Resolved'
        WHEN audit.FieldName = 'Status' AND audit.OldValue IN ('Resolved', 'Closed') AND audit.NewValue NOT IN ('Resolved', 'Closed') THEN 'Service Request Reopened'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Closed' THEN 'Service Request Closed'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Cancelled' THEN 'Service Request Cancelled'
    END AS ActivityName,
    audit.AuditDate AS EventTime,
    'Ivanti' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    sr.SvcReqTmplLink_Category AS ServiceRequestType,
    sr.OwnerTeam AS AssignedTeam,
    sr.Owner AS AssignedAgent,
    sr.Priority,
    audit.NewValue AS ServiceRequestStatus,
    sr.ResolutionDateTime AS ResolutionDateTime,
    sr.TargetDateTime AS SLADeadline,
    NULL AS CycleTime,
    NULL AS SLAStatus,
    sr.RecId
FROM
    AuditHistory_Export audit -- Represents the AuditHistory.csv file
JOIN
    ServiceRequests_Export sr ON audit.ParentLink_RecID = sr.RecId
WHERE
    -- This filter ensures that only rows corresponding to a defined activity are included.
    CASE
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Submitted' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Approved' THEN 1
        WHEN audit.FieldName = 'OwnerTeam' AND audit.OldValue IS NOT NULL THEN 1
        WHEN audit.FieldName = 'Owner' AND audit.OldValue IS NOT NULL THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Waiting for Customer' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.OldValue = 'Waiting for Customer' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Waiting for 3rd Party' THEN 1
        WHEN audit.FieldName = 'Priority' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Fulfilled' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Resolved' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.OldValue IN ('Resolved', 'Closed') AND audit.NewValue NOT IN ('Resolved', 'Closed') THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Closed' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Cancelled' THEN 1
        ELSE 0
    END = 1;

ステップ

前提条件と準備：システムにPython 3.6以降がインストールされていることを確認します。API呼び出し用のrequestsとデータ操作用のpandasを、pip install requests pandasを実行してインストールします。Ivanti Service Managerの管理者から、ServiceReqおよびFRS_Audit_ServiceReqビジネスオブジェクトに対する読み取り権限以上を持つAPIキーを取得します。
スクリプトを設定する：提供されたPythonスクリプトをダウンロードします。テキストエディターまたはIDEでスクリプトを開き、先頭にあるプレースホルダー変数 TENANT_URL、API_KEY、START_DATE、END_DATE を、Ivanti環境と対象の抽出期間に合わせて更新します。
スクリプトを実行する：コマンドラインから python your_script_name.py を実行します。スクリプトはまず、Ivanti APIへの接続と認証を開始したことを示すメッセージを表示します。
サービスリクエストのデータを取得する：スクリプトは指定期間内に作成されたすべてのリクエストについて、ServiceReqビジネスオブジェクトを検索します。APIのページネーションを自動的に処理してリクエスト一覧を取得し、各ページのデータを取得するたびに進捗を表示します。
監査履歴を取得する：取得した各サービスリクエストについて、スクリプトは FRS_Audit_ServiceReq ビジネスオブジェクトを追加で検索します。これにより、対象リクエストのすべてのフィールド変更履歴を取得できます。詳細なイベントログを作成するために必要なデータです。
「作成」イベントを生成する：各サービスリクエストを処理する際、スクリプトは最初に「サービスリクエスト作成」イベントを作成します。このイベントのタイムスタンプには、サービスリクエストレコードの CreatedDateTime フィールドの値をそのまま使います。
監査履歴からイベントを生成する：次に、スクリプトは各サービスリクエストの監査履歴レコードを順に処理します。ステータス、OwnerTeam、担当者、Priorityなどの主要フィールドの変更を特定します。
変更をアクティビティに対応付ける：スクリプト内の定義済みの対応付けロジックにより、フィールドの変更を特定のアクティビティ名に変換します。たとえば、ステータスフィールドが「アクティブ」から「解決済み」に変わった場合、「サービスリクエスト解決済み」アクティビティとして記録します。
イベントログを作成する：最初の作成イベントと、その後の監査履歴から生成した変更イベントをすべて、構造化されたリストにまとめます。各イベントには、サービスリクエストID、アクティビティ名、タイムスタンプ、その他の関連属性が含まれます。
データを変換して整形する：収集したイベントのリストをPandasのDataFrameに変換します。ServiceRequestID、ActivityName、EventTimeなど、ProcessMindで必要なスキーマにすべての列が合うよう、スクリプトが整えます。
CSVにエクスポートする：すべてのサービスリクエストとその履歴の処理が完了すると、スクリプトは最終的なDataFrameを ivanti_servicereq_event_log.csv という名前で、スクリプトを実行したディレクトリに保存します。このファイルはアップロードできます。

設定

APIエンドポイントURL：Ivanti Service Managerのテナントで使用するREST APIのベースURLです。例：https://your-tenant.ivanti.com。スクリプトのTENANT_URL変数に設定します。
APIキー：Ivantiの管理コンソールで作成した有効なREST APIキーが必要です。このキーには、ServiceReqおよびFRS_Audit_ServiceReqビジネスオブジェクトへの読み取り権限を持つロールを関連付けてください。
期間：スクリプトでは、START_DATEとEND_DATEを'YYYY-MM-DD'形式で指定します。初回の分析では、データ量を抑えながら十分なプロセスの違いを把握できるよう、3～6か月の期間をおすすめします。
ページサイズ（TOP_COUNT）：この変数は、API呼び出し1回あたりに取得するレコード数を指定します。初期値は500で、パフォーマンスとメモリ使用量のバランスを考慮した設定です。APIサーバーの性能に応じて変更できます。
必要なフィールド（SELECT_FIELDS_SR、SELECT_FIELDS_AUDIT）：スクリプトでは、データ量を抑えるため、APIから取得するフィールドを指定しています。必要な属性と推奨属性がすべてリストに含まれていることを確認してください。

クエリの例 python

import requests
import pandas as pd
import datetime
import time

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Ivanti tenant URL and API Key
TENANT_URL = class="hl-string">"https://[your-tenant.ivanti.com]"
API_KEY = class="hl-string">"[Your Ivanti REST API Key]"

class=class="hl-string">"hl-comment"># Define the date range for the extraction
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-12-31"

class=class="hl-string">"hl-comment"># API settings
TOP_COUNT = 500
API_BO_URL = fclass="hl-string">"{TENANT_URL}/api/odata/businessobject"
HEADERS = {
    class="hl-string">"Authorization": fclass="hl-string">"rest_api_key={API_KEY}",
    class="hl-string">"Content-Type": class="hl-string">"application/json"
}

class=class="hl-string">"hl-comment"># Fields to select from the API to reduce payload size
SELECT_FIELDS_SR = class="hl-string">"RecId,ServiceReqNumber,CreatedDateTime,OwnerTeam,Owner,Priority,Status,Subject,Resolution,ResolvedDateTime,ResponseTarget,Service"
SELECT_FIELDS_AUDIT = class="hl-string">"FieldName,OldValue,NewValue,ModifiedDateTime,ParentLink_RecID"

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---
def get_paginated_data(url, params):
    class="hl-string">"""Fetches all pages of data from a given Ivanti API endpoint."""
    all_records = []
    page_url = url
    while page_url:
        try:
            response = requests.get(page_url, headers=HEADERS, params=params)
            response.raise_for_status() 
            data = response.json()
            all_records.extend(data.get(class="hl-string">'value', []))
            page_url = data.get(class="hl-string">'@odata.nextLink')
            print(fclass="hl-string">"Fetched {len(all_records)} records so far...")
            class=class="hl-string">"hl-comment"># Parameters are only needed for the first request
            params = {}
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data: {e}")
            break
    return all_records

def map_status_change_to_activity(old_status, new_status):
    class="hl-string">"""Maps status transitions to activity names."""
    class=class="hl-string">"hl-comment"># Normalize statuses by removing spaces and converting to lower case
    old = str(old_status).lower().replace(class="hl-string">" ", class="hl-string">"") if old_status else class="hl-string">""
    new = str(new_status).lower().replace(class="hl-string">" ", class="hl-string">"") if new_status else class="hl-string">""

    if new in [class="hl-string">'submitted', class="hl-string">'pendingapproval']:
        return class="hl-string">'Request Submitted for Approval'
    if new == class="hl-string">'approved':
        return class="hl-string">'Request Approved'
    if new == class="hl-string">'waitingforcustomer':
        return class="hl-string">'Information Requested from User'
    if old == class="hl-string">'waitingforcustomer' and new not in [class="hl-string">'resolved', class="hl-string">'closed', class="hl-string">'cancelled']:
        return class="hl-string">'Information Provided by User'
    if new == class="hl-string">'waitingfor3rdparty':
        return class="hl-string">'External Vendor Engaged'
    if new == class="hl-string">'fulfilled':
        return class="hl-string">'Service Request Fulfilled'
    if new == class="hl-string">'resolved':
        return class="hl-string">'Service Request Resolved'
    if old == class="hl-string">'resolved' and new not in [class="hl-string">'closed']:
        return class="hl-string">'Service Request Reopened'
    if new == class="hl-string">'closed':
        return class="hl-string">'Service Request Closed'
    if new == class="hl-string">'cancelled':
        return class="hl-string">'Service Request Cancelled'
    return None

def main():
    class="hl-string">"""Main function to orchestrate the extraction process."""
    print(class="hl-string">"Starting Ivanti Service Request extraction...")

    class=class="hl-string">"hl-comment"># 1. Fetch all Service Requests within the date range
    sr_url = fclass="hl-string">"{API_BO_URL}/ServiceReqs"
    sr_filter = fclass="hl-string">"CreatedDateTime ge {START_DATE}T00:00:00Z and CreatedDateTime le {END_DATE}T23:59:59Z"
    sr_params = {
        class="hl-string">"$filter": sr_filter,
        class="hl-string">"$select": SELECT_FIELDS_SR,
        class="hl-string">"$top": TOP_COUNT
    }
    print(fclass="hl-string">"Fetching Service Requests from {START_DATE} to {END_DATE}...")
    service_requests = get_paginated_data(sr_url, sr_params)

    if not service_requests:
        print(class="hl-string">"No service requests found for the given date range.")
        return

    print(fclass="hl-string">"Found {len(service_requests)} service requests. Now fetching audit histories...")

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

    class=class="hl-string">"hl-comment"># 2. For each Service Request, fetch its audit history and build events
    for i, sr in enumerate(service_requests):
        print(fclass="hl-string">"Processing SR {i+1}/{len(service_requests)}: {sr.get('ServiceReqNumber')}")
        sr_id = sr.get(class="hl-string">'RecId')
        sr_number = sr.get(class="hl-string">'ServiceReqNumber')
        
        class=class="hl-string">"hl-comment"># Event: Service Request Created
        event_log.append({
            class="hl-string">'ServiceRequestID': sr_number,
            class="hl-string">'ActivityName': class="hl-string">'Service Request Created',
            class="hl-string">'EventTime': sr.get(class="hl-string">'CreatedDateTime'),
            class="hl-string">'SourceSystem': class="hl-string">'Ivanti Service Manager',
            class="hl-string">'LastDataUpdate': current_time,
            class="hl-string">'EventEndTime': None,
            class="hl-string">'ServiceRequestType': sr.get(class="hl-string">'Service'),
            class="hl-string">'AssignedTeam': sr.get(class="hl-string">'OwnerTeam'),
            class="hl-string">'AssignedAgent': sr.get(class="hl-string">'Owner'),
            class="hl-string">'Priority': sr.get(class="hl-string">'Priority'),
            class="hl-string">'ServiceRequestStatus': sr.get(class="hl-string">'Status'),
            class="hl-string">'ResolutionDateTime': sr.get(class="hl-string">'ResolvedDateTime'),
            class="hl-string">'SLADeadline': sr.get(class="hl-string">'ResponseTarget'),
            class="hl-string">'CycleTime': None, class=class="hl-string">"hl-comment"># To be calculated later if needed
            class="hl-string">'SLAStatus': None class=class="hl-string">"hl-comment"># To be calculated later if needed
        })

        class=class="hl-string">"hl-comment"># Fetch audit history for this SR
        audit_url = fclass="hl-string">"{API_BO_URL}/FRS_Audit_ServiceReqs"
        audit_params = {
            class="hl-string">"$filter": fclass="hl-string">"ParentLink_RecID eq '{sr_id}'",
            class="hl-string">"$select": SELECT_FIELDS_AUDIT,
            class="hl-string">"$orderby": class="hl-string">"ModifiedDateTime asc"
        }
        audit_history = get_paginated_data(audit_url, audit_params)

        if not audit_history:
            continue

        class=class="hl-string">"hl-comment"># Process audit history to create events
        for audit_entry in audit_history:
            field_name = audit_entry.get(class="hl-string">'FieldName')
            event_time = audit_entry.get(class="hl-string">'ModifiedDateTime')
            old_value = audit_entry.get(class="hl-string">'OldValue')
            new_value = audit_entry.get(class="hl-string">'NewValue')
            activity_name = None
            current_team = None
            current_agent = None
            current_priority = None
            current_status = None

            if field_name == class="hl-string">'Status':
                activity_name = map_status_change_to_activity(old_value, new_value)
                current_status = new_value
            elif field_name == class="hl-string">'OwnerTeam' and new_value:
                activity_name = class="hl-string">'Request Assigned to Team'
                current_team = new_value
            elif field_name == class="hl-string">'Owner' and new_value:
                activity_name = class="hl-string">'Request Assigned to Agent'
                current_agent = new_value
            elif field_name == class="hl-string">'Priority' and old_value is not None:
                activity_name = class="hl-string">'Priority Changed'
                current_priority = new_value

            if activity_name:
                event_log.append({
                    class="hl-string">'ServiceRequestID': sr_number,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventTime': event_time,
                    class="hl-string">'SourceSystem': class="hl-string">'Ivanti Service Manager',
                    class="hl-string">'LastDataUpdate': current_time,
                    class="hl-string">'EventEndTime': None,
                    class="hl-string">'ServiceRequestType': sr.get(class="hl-string">'Service'),
                    class="hl-string">'AssignedTeam': current_team or sr.get(class="hl-string">'OwnerTeam'), class=class="hl-string">"hl-comment"># Use current if changed, else original
                    class="hl-string">'AssignedAgent': current_agent or sr.get(class="hl-string">'Owner'),
                    class="hl-string">'Priority': current_priority or sr.get(class="hl-string">'Priority'),
                    class="hl-string">'ServiceRequestStatus': current_status or sr.get(class="hl-string">'Status'),
                    class="hl-string">'ResolutionDateTime': sr.get(class="hl-string">'ResolvedDateTime'),
                    class="hl-string">'SLADeadline': sr.get(class="hl-string">'ResponseTarget'),
                    class="hl-string">'CycleTime': None,
                    class="hl-string">'SLAStatus': None
                })

    class=class="hl-string">"hl-comment"># 3. Create DataFrame and save to CSV
    if not event_log:
        print(class="hl-string">"No events were generated.")
        return

    print(class="hl-string">"Extraction complete. Creating CSV file...")
    df = pd.DataFrame(event_log)
    class=class="hl-string">"hl-comment"># Ensure chronological order
    df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'])
    df = df.sort_values(by=[class="hl-string">'ServiceRequestID', class="hl-string">'EventTime'], ascending=[True, True])
    
    class=class="hl-string">"hl-comment"># Forward fill key attributes to provide context for each event
    df[class="hl-string">'AssignedTeam'] = df.groupby(class="hl-string">'ServiceRequestID')[class="hl-string">'AssignedTeam'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'AssignedAgent'] = df.groupby(class="hl-string">'ServiceRequestID')[class="hl-string">'AssignedAgent'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'Priority'] = df.groupby(class="hl-string">'ServiceRequestID')[class="hl-string">'Priority'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'ServiceRequestStatus'] = df.groupby(class="hl-string">'ServiceRequestID')[class="hl-string">'ServiceRequestStatus'].fillna(method=class="hl-string">'ffill')

    output_filename = class="hl-string">'ivanti_servicereq_event_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
    print(fclass="hl-string">"Event log saved successfully to {output_filename}")

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

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

この詳細なデータテンプレートを使って、サービスリクエスト管理プロセスの全体像を把握しましょう。今日から業務の最適化に取り組めます。

改善ガイドに戻る

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

今日からサービスリクエスト管理の最適化を始めましょう

対応の遅れをなくし、利用者の不満を減らして、自動化率70％を目指しましょう。

無料トライアルを開始

クレジットカードは不要です。数分でセットアップできます。

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

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

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

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

データ抽出ガイド

Ivantiの保存済み検索とグリッドデータのCSVエクスポート

ステップ

設定

クエリの例 sql

Ivanti REST APIを使ったPythonスクリプト

ステップ

設定

クエリの例 python

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

今日からサービスリクエスト管理の最適化を始めましょう