変更管理データテンプレート

アクティビティ名は、変更依頼のライフサイクルにおける個別のステップや節目を示します。たとえば、「リスク評価の完了」や「変更の承認」などです。各アクティビティは、操作や判断が行われた時点、またはプロセスが次の段階に進んだ時点を表します。

この属性は、プロセスマップの作成に欠かせません。プロセスグラフのノードを定義するため、イベントの順序を可視化し、よくある経路を特定し、標準手順からの逸脱を検出できます。アクティビティを分析すると、ボトルネックや手戻りのループ、変更プロセスの各段階における非効率な引き継ぎを見つけられます。

プロセスの各ステップを定義し、フローを可視化することで、ボトルネックや手戻り、逸脱を分析できます。

通常、変更依頼に関連付けられたアクティビティログ、イベント履歴、または監査証跡テーブルにあります。

イベント開始時刻は、変更依頼のライフサイクルにおけるアクティビティの開始時点を示します。このタイムスタンプは、イベントを時系列に並べ、各アクティビティとケース全体の所要時間を算出するうえで重要です。

プロセス分析では、アクティビティを正しい順序に並べてイベントログを作成するために使います。また、アクティビティ間のサイクルタイムや待ち時間、ケース全体の所要時間など、時間に関する指標の算出にも欠かせません。タイムスタンプを分析すると、時間を要しているステップを特定し、プロセスを迅速化できる箇所を見つけられます。

イベントの順序付けやプロセスフローの把握、サイクルタイムや待ち時間などのパフォーマンス指標の算出に欠かせません。

変更依頼のイベントログまたは監査証跡にあります。「作成日」「開始日」、または単に「タイムスタンプ」と表記される場合があります。

変更依頼IDは、変更依頼の作成時に割り当てられる一意の英数字コードです。1件の変更ケースを識別する主キーとして機能し、開始から完了までに関連するすべてのタスク、承認、ログを結び付けます。

プロセスマイニングでは、この属性を使って変更ごとの一連の流れを再構成します。共通の変更依頼IDでイベントをまとめることで、プロセスフローを可視化し、ケースの所要時間を算出し、変更のライフサイクルごとの違いを分析できます。個々の変更がシステム内でどのように進むかを把握する、ケース単位の分析の基盤となります。

このIDは、1件の変更に関するすべてのイベントを追跡して関連付けるうえで欠かせません。プロセスの発見と適合性チェックの基盤となります。

通常、変更依頼のヘッダーまたは主要レコードにあります。

ソースシステム属性は、イベントデータの取得元を示します。複数のITSMツールや連携システムを使う環境では、この項目によってデータの出所を区別し、データの整合性と適切なコンテキストを保てます。

プロセスフローの主要な分析に常に使うわけではありませんが、データの検証とガバナンスに役立ちます。データ取り込みの問題を調査する際に役立つほか、異なるシステムや事業部門でプロセスのパフォーマンスを比較するためにも使えます。たとえば、インフラストラクチャの変更とアプリケーションの変更で、別々のシステムを使っている場合があります。

データの出所を示すため、データの検証や問題の調査、複数のシステムにまたがるプロセスの分析に役立ちます。

この情報は、ソースデータの項目として保存されている場合と、データの抽出・変換（ETL）時に追加される場合があります。

最終データ更新日時のタイムスタンプは、特定のレコードがソースシステムから最後に取得された時点を示します。データパイプラインの管理と分析データの鮮度維持に欠かせないメタデータ属性です。

この属性により、データエンジニアやアナリストは、扱っているデータがいつ時点のものかを把握できます。データ抽出プロセスの状態を監視し、プロセスマイニングの分析が新しく関連性の高い情報に基づいていることを確認するために使います。通常、プロセス自体の分析には使いませんが、データガバナンスと信頼性の確保に欠かせません。

データの鮮度を保ち、データパイプラインの状態を監視することで、プロセス分析の信頼性を支えます。

通常、データの抽出、変換、読み込み（ETL）の過程で生成、追加されるタイムスタンプです。

イベント終了時刻は、アクティビティの終了時点を示します。イベント開始時刻と組み合わせることで、変更のライフサイクルにおける各ステップの処理時間を正確に算出できます。

この属性は、パフォーマンス分析の基礎となります。開始時刻と終了時刻の差からアクティビティの「処理時間」がわかり、あるアクティビティの終了から次のアクティビティの開始までの時間から「待ち時間」がわかります。この区別により、遅延の原因が長時間のタスクなのか、タスク間の待機なのかを特定し、改善策を絞り込めます。

アクティビティの所要時間を正確に算出し、価値を生む処理時間と価値を生まない待ち時間を区別できます。

多くの場合、アクティビティログまたは監査証跡テーブルにあります。取得できない場合は、次のイベントの開始時刻から算出できることがあります。

リスクレベルは、変更が失敗する可能性と、その場合に想定される悪影響を評価したものです。この評価に基づいて、必要なテスト、精査、承認の水準が決まります。リスクの高い変更は通常、低い変更より厳格なレビューが必要です。

この属性を使うと、リスクに基づくプロセス分析ができます。たとえば、リスクの高い変更が変更諮問委員会（CAB）によるレビューなど、適切な審査を受けているかを確認できます。また、リスクレベルと結果を関連付け、リスクの高い変更で失敗率が高いかどうかを調べることもできます。その結果から、リスク評価や軽減策の改善が必要かを判断できます。

プロセスの統制や承認ワークフローが、評価された変更リスクに適切に対応しているかを分析できます。

変更依頼のヘッダーデータまたはリスク評価の詳細にあります。

変更優先度は、変更依頼の相対的な重要度を示す分類です。チームがスケジュールを組み、リソースを適切に割り当て、重要度の高い変更から対応できるようにします。優先度は通常、変更が業務に及ぼす影響と実施の緊急度に基づいて決まります。

プロセスマイニングでは、優先度を分析対象の絞り込みや比較に使えます。優先度の高い変更が、低い変更より実際に迅速に処理されているかを調べられます。差が見られる場合は、リソース配分の問題、重要な変更の承認におけるボトルネック、優先順位付けルールの適用のばらつきが考えられます。

優先度の高い変更が低い変更より迅速に処理されているかを分析し、優先順位付けの方針が機能しているかを確認できます。

変更依頼の主要レコードまたはヘッダーデータにあります。

変更ステータスは、特定の時点における変更依頼の段階、または最終結果を示します。ステータスは通常、プロセスの主要な節目に対応し、進捗を大まかに把握するために使います。

この属性は2通りの方法で使えます。スナップショット属性としては、未完了の変更の現在の状態を示し、処理量や滞留を追跡する運用ダッシュボードに役立ちます。イベント属性としては、ステータスの変更自体をアクティビティとみなし、詳細なアクティビティデータが少ない場合にイベントログを補完できます。ステータスの遷移を分析すると、ライフサイクルを把握し、変更が滞留している箇所を特定できます。

変更の進捗を把握し、ボトルネックや処理量、変更の滞留状況を分析できます。

変更依頼のヘッダーレコードにあります。過去のステータス変更は監査ログで確認できる場合があります。

変更タイプは、変更依頼に必要なワークフロー、承認ステップ、緊急度を決める重要な分類です。標準変更は通常、事前承認済みでリスクが低く、通常変更は評価と承認の全工程を経ます。緊急変更は、業務上の緊急性に応じて迅速に処理されます。

変更タイプ別のプロセス分析は、変更管理分析の中心的な作業です。変更タイプごとにパフォーマンスとコンプライアンスを比較できます。たとえば、緊急変更が実際に迅速な経路をたどっているか、標準変更が簡略化された事前承認済みのフローに従っているかを確認できます。この分類により、プロセスの違いを把握し、適切なガバナンスが適用されているかを確認できます。

変更タイプごとに定められたプロセスフロー、承認要件、パフォーマンスの基準が異なるため、分析の分類に欠かせない属性です。

変更依頼の主要レコードまたはヘッダーデータにあります。

影響を受ける業務サービスは、変更によって内容が変わる中核的な業務機能を示します。「メールサービス」や「オンラインバンキング」などが該当します。また、業務サービスを支えるサーバーやアプリケーションなど、特定の技術的な構成アイテム（CI）を指す場合もあります。

この属性は、変更管理プロセスに重要な業務上のコンテキストを加えます。ITの作業だけでなく、業務への影響を踏まえて分析できます。たとえば、変更が頻繁に行われるサービスを特定し、不安定さやイノベーションの頻度の高さを把握できます。また、技術的な変更を、それが支える業務機能と結び付けることで、変更の優先順位付けやリスク評価にも役立ちます。

ITの変更を業務上のコンテキストと結び付け、変更作業や関連リスクの影響を最も受ける業務サービスを分析できます。

変更依頼の主要レコードにあります。構成管理データベース（CMDB）から参照される場合もあります。

担当チームは、特定の段階で変更作業を割り当てられたグループを示します。評価チーム、CABなどの承認委員会、または実施を担当する技術チームなどが該当します。

この属性は、リソース配分や作業負荷の分布、チーム間の引き継ぎを分析するうえで欠かせません。ソーシャルネットワーク分析により、グループ間のコミュニケーションのパターンやボトルネックを明らかにできます。各チームでの所要時間を測定すると、負荷が集中しているグループや、責任の引き継ぎで遅延が頻発する箇所を特定できます。

チーム間の引き継ぎやリソースのボトルネックを分析し、組織全体の作業負荷の分布を把握するうえで欠かせません。

変更依頼レコードまたはアクティビティの詳細にあります。「割り当てグループ」や「チーム」と表記される場合があります。

担当者は、変更依頼またはアクティビティを割り当てられた個人を示します。この属性を使うと、チーム単位の割り当てより細かく、作業負荷と責任を把握できます。

担当者単位のデータ分析は、パフォーマンス管理や研修機会の特定に役立ちます。プロセスに詳しい人や、特定のタスクに苦労している人を把握できます。また、手戻りの分析にも使えます。たとえば、特定の担当者が処理した変更で、却下や修正が多く発生していないかを確認できます。ただし、懲罰ではなく建設的な目的で利用する必要があります。

個人ごとの作業負荷とパフォーマンスを細かく分析し、チーム内の専門家や研修が必要な領域を特定できます。

通常、変更依頼レコードまたはタスクの詳細にあり、「担当者」や「割り当て先」と表記されます。

変更理由は、変更依頼の背景にある業務上の動機を説明するテキストです。「なぜこの変更を行うのか」という問いに答えるもので、「重大な脆弱性に対するセキュリティパッチ」や「顧客体験を向上させる新機能」などの背景を示します。

自由記述欄として使われることが多い属性ですが、分類したりテキストマイニングの手法で分析したりすると、定性的なインサイトが得られます。業務の各部門から寄せられる変更の需要を把握するのに役立ちます。たとえば、変更の多くがバグ修正によるものだとわかれば、ソフトウェア品質に課題がある可能性があります。一方、別の期間に戦略プロジェクトに関連する変更が多ければ、その傾向を把握できます。

変更を開始する業務上の背景を示し、組織内で変更を促す主な要因の分析に役立ちます。

通常、変更依頼の初回申請フォームまたはヘッダーの詳細にあります。

完了予定日は、変更の期限として設定される日付です。業務要件やサービスレベル合意（SLA）に基づいて決まることがよくあります。変更管理プロセスの適時性とパフォーマンスを測る基準となります。

この属性は、SLAパフォーマンスの分析に欠かせません。実際の完了日と予定日を比較すると、期限内完了率という重要業績評価指標を算出できます。予定日に間に合わなかった変更を分析すると、承認のボトルネック、リソースの制約、無理のある計画など、遅延の根本原因を特定できます。

SLAの遵守状況と期限内の納品を測る重要な属性です。プロセスの遅延の根本原因を特定するのに役立ちます。

通常、変更依頼のヘッダーデータにあります。

変更の影響度は、業務運営、サービス、インフラストラクチャに及ぼす潜在的な影響を示します。緊急度とともに、変更全体の優先度を決める重要な要素です。たとえば、顧客向けの重要なサービスに影響する変更は、影響度が高くなります。

影響度別に分析すると、重要なサービスに関わる変更が適切な注意を払って管理されているかを確認できます。適合性チェックでは、影響度の高い変更が特定の承認やテストの段階を必ず経ているかを検証できます。また、影響度の高い変更はレビューやテストがより広範になるため、実施に時間がかかるかどうかなど、パフォーマンスの比較にも役立ちます。

業務への影響が大きい変更が、より厳格なレビューとテストの経路をたどっているかを確認し、適切なガバナンスを確保できます。

変更依頼の主要レコードまたはヘッダーデータにあります。

変更結果の理由は、変更依頼がその結果に至った背景を示します。成功した変更では「成功」、失敗した変更では「失敗、ロールバックを開始」などが記録されます。却下またはキャンセルされた変更では、「正当な理由が不十分」「依頼者によるキャンセル」など、その理由が示されます。

この属性は、失敗または却下された変更の根本原因分析に欠かせません。理由を分類して分析すると、よくある失敗のパターンを特定できます。たとえば、「情報不足」を理由に却下される変更が多い場合、変更の申請プロセスを改善する必要があるとわかります。このデータは、変更失敗率や初回承認率などの重要業績評価指標の算出と把握にも役立ちます。

失敗、却下、キャンセルされた変更の根本原因分析に必要なデータを提供し、今後の変更依頼の品質向上に役立ちます。

変更依頼レコードのクローズ時の詳細にあります。「クローズコード」「解決内容」「却下理由」などの名称が使われます。

変更の緊急度は、業務要件を満たすために、どれだけ早く変更を実施する必要があるかを示します。潜在的な影響度とは別に、時間的な切迫度を表します。たとえば、影響度は低くても、マーケティングキャンペーンの開始前に軽微な問題を修正する必要がある場合、緊急度は高くなります。

緊急度は優先度の算出に欠かせない要素であり、変更管理プロセスが適時に進んでいるかの分析にも使います。緊急度の高い変更が実際に迅速に処理されているかを調べられます。緊急度ごとにサイクルタイムを比較すると、プロセスが業務ニーズに応じて対応できているか、時間的な切迫度にかかわらずすべての変更を同じ速度で処理しているかがわかります。

緊急度ごとのサイクルタイムを比較し、時間的制約のある業務ニーズにプロセスがどれだけ迅速に対応できているかを分析できます。

変更依頼の主要レコードまたはヘッダーデータにあります。