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

アクティビティ名は、「リスク評価完了」や「変更承認済み」など、変更リクエストのライフサイクルにおける個別のステップまたはマイルストーンを記述します。各アクティビティは、アクションが実行され、決定が下され、またはプロセスが新しい段階に移行した時点を表します。

この属性は、プロセスマップを構築するための基本的なものです。プロセスグラフ内のノードを定義し、アナリストがイベントのシーケンスを視覚化し、共通の経路を特定し、標準手順からの逸脱を検出することを可能にします。アクティビティを分析することで、ボトルネック、再作業ループ、および変更プロセスの異なる段階間の非効率な引き継ぎを明らかにすることができます。

プロセス内のステップを定義し、プロセスフローの可視化と、ボトルネック、再作業、逸脱の分析を可能にします。

通常、変更リクエストに関連付けられた活動ログ、イベント履歴、または監査証跡テーブルにあります。

イベント開始時刻は、変更リクエストのライフサイクル内でのアクティビティの開始を示します。このタイムスタンプは、イベントを時系列に並べ、アクティビティの期間とケース全体の期間を計算するために不可欠です。

プロセス分析において、この属性はアクティビティを正しく順序付けし、イベントログの基盤を形成するために使用されます。アクティビティ間のサイクルタイム、待機時間、ケース全体の期間など、すべての時間関連メトリクスを計算するために不可欠です。これらのタイムスタンプを分析することで、組織はどのステップが最も時間を消費しているかを特定し、プロセスの加速の機会を pinpoint できます。

このタイムスタンプは、イベントの順序付け、プロセスフローの発見、サイクルタイムや待機時間などのすべてのパフォーマンス指標の計算に不可欠です。

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

変更リクエストIDは、各変更リクエストが作成された際に割り当てられる一意の英数字コードです。これは単一の変更ケースの主キーとして機能し、開始から完了までの関連するすべてのタスク、承認、ログをリンクします。

プロセスマイニングにおいて、この属性は各変更のエンドツーエンドのジャーニーを再構築するために不可欠です。共通の変更リクエストIDの下にすべてのイベントをグループ化することで、アナリストはプロセスフローを視覚化し、ケース期間を計算し、異なる変更ライフサイクル間のバリエーションを分析できます。これはすべてのケースレベル分析の基盤であり、個々の変更がシステム内でどのように進行するかを明確に把握することを可能にします。

このIDは、単一の変更に関連するすべてのイベントを追跡し、関連付ける上で重要であり、プロセスの発見とコンフォーマンスチェックの基礎となります。

通常、変更リクエストトランザクションのヘッダーまたはプライマリレコードにあります。

ソースシステム属性は、イベントデータの発生元を識別します。複数のITSMツールや統合システムが存在する環境では、このフィールドは異なるソースからのデータを区別し、データの整合性と適切なコンテキストを確保するのに役立ちます。

主要なプロセスフロー分析には必ずしも使用されませんが、データ検証とガバナンスにとって非常に貴重です。データ取り込みの問題のトラブルシューティングに役立ち、異なるプラットフォームを使用している場合、異なるシステムや事業部門間でのプロセスパフォーマンスを比較するために使用できます。例えば、ある企業はインフラ変更に1つのシステムを使用し、アプリケーション変更には別のシステムを使用するかもしれません。

データの出所を特定します。これはデータ検証、トラブルシューティング、複数のシステムにまたがるプロセスの分析にとって非常に重要です。

この情報は、ソースデータ内のフィールドとして保存されるか、データ抽出および変換（ETL）プロセス中に追���される場合があります。

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

この属性は、データエンジニアとアナリストが扱っているデータの適時性を理解するのに役立ちます。データ抽出プロセスの健全性を監視し、プロセスマイニング分析が最新かつ関連性の高い情報に基づいていることを確認するために使用されます。通常、プロセス分析自体には使用されませんが、データガバナンスと信頼性には不可欠です。

データの鮮度を保証し、データパイプラインの状態を監視するのに役立ちます。これはプロセス分析の信頼性にとって極めて重要です。

このタイムスタンプは通常、データ抽出、変換、ロード（ETL）プロセス中に生成され、追加されます。

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

この属性はパフォーマンス分析の基本です。開始時刻と終了時刻の差はアクティビティの「処理時間」を明らかにし、あるアクティビティの終了から次のアクティビティの開始までの時間は「待機時間」を示します。この区別は、遅延が長いタスクによって引き起こされているのか、タスク間のアイドル期間によって引き起こされているのかを特定し、ターゲットを絞った改善努力を導く上で重要です。

正確な活動期間の計算を可能にし、付加価値のある処理時間と付加価値のない待機時間を区別するのに役立ちます。

アクティビティログまたは監査証跡テーブルによく見られます。利用できない場合は、次のイベントの開始時刻から導出できる場合があります。

リスクレベルは、変更が失敗する可能性と潜在的な負の影響を評価したものです。この評価は、必要なテスト、精査、および承認のレベルに影響を与えます。高リスクの変更は、通常、低リスクの変更よりも厳格なレビュープロセスを必要とします。

この属性により、リスクベースのプロセス分析が可能になります。高リスクの変更が、変更諮問委員会（CAB）によるレビューなど、適切なレベルのレビューを受けているかを確認するために使用できます。また、リスクレベルと結果を関連付けることも可能で、例えば、高リスクの変更の失敗率が高いかどうかを判断し、リスク評価または緩和プロセスに改善が必要であることを示唆する場合があります。

プロセス制御と承認ワークフローが、評価された変更リスクと正しく整合しているかどうかを分析できます。

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

変更の優先度は、変更リクエストの相対的な重要性を決定するために使用される分類です。これはチームがリソースを効果的にスケジュールし、割り当てるのに役立ち、最も重要な変更が最初に対応されるようにします。優先度は、多くの場合、ビジネスへの潜在的な影響と実装の緊急性に基づいて計算されます。

プロセスマイニングでは、優先度はフィルタリングと比較のための強力なディメンションです。アナリストは、高優先度の変更が低優先度の変更よりも実際に速く処理されているかを調査できます。不一致がある場合、リソース割り当て、重要な変更における承認のボトルネック、または優先順位付けルールの一貫性のない遵守に問題があることを示唆している可能性があります。

優先度の高い変更が優先度の低い変更よりも迅速に処理されているかを分析し、優先順位付けポリシーの有効性を検証できます。

変更リクエストのメインレコードまたはヘッダーデータにあります。

変更ステータスは、特定の時点での変更リクエストのフェーズまたはその最終的な結果を示します。ステータスは通常、プロセスの主要なマイルストーンに対応し、進捗状況の概要を提供します。

この属性は2つの方法で使用できます。スナップショット属性としては、すべてのオープンな変更の現在の状態を示し、スループットとバックログを追跡する運用ダッシュボードに役立ちます。イベント属性としては、ステータスの変更自体がアクティビティと見なすことができ、詳細なアクティビティデータが不足している場合にイベントログを充実させるのに役立ちます。ステータス遷移を分析することで、ライフサイクルを理解し、変更がどこで停滞しているかを特定できます。

変更の進捗のスナップショットを提供し、ボトルネック、スループット、および変更バックログの現在の状態の分析を可能にします。

変更リクエストのヘッダーレコードにあります。履歴ステータスの変更は監査ログで見つかる場合があります。

変更種別は、変更リクエストに必要なワークフロー、承認ステップ、および緊急度を決定する重要な分類です。標準変更は通常、事前承認済みで低リスクであり、通常変更は完全な評価および承認プロセスに従い、緊急変更は差し迫ったビジネスニーズのために迅速な処理を必要とします。

変更種別によってプロセスを分析することは、変更管理分析における中心的な活動です。これにより、異なる変更ワークフローのパフォーマンスとコンプライアンスを比較できます。例えば、アナリストは緊急変更が実際に高速なパスをたどっているか、または標準変更が簡素化された事前承認済みフローに準拠しているかを確認できます。このセグメンテーションは、プロセスのバリエーションを理解し、適切なレベルのガバナンスが適用されていることを確認するための鍵となります。

この属性は、分析のセグメンテーションに不可欠です。異なる変更タイプには、それぞれ異なる事前定義されたプロセスフロー、承認要件、およびパフォーマンスの期待値があるためです。

変更リクエストのメインレコードまたはヘッダーデータにあります。

影響を受けるビジネスサービスは、「メールサービス」や「オンラインバンキング」など、変更によって修正される主要なビジネス機能を特定します。これは、ビジネスサービスをサポートするサーバーやアプリケーションのような特定の技術的構成アイテム（CI）である場合もあります。

この属性は、変更管理プロセスに重要なビジネスコンテキストを提供します。これにより、分析がIT活動だけでなくビジネス影響の観点から行われるようになります。例えば、アナリストはどのサービスが最も頻繁に変更されているかを特定でき、それは不安定性や高いイノベーション率を示す可能性があります。また、技術的な変更をそれらがサポートするビジネス機能にリンクさせることで、変更の優先順位付けとリスク評価にも役立ちます。

IT変更をビジネスコンテキストに紐付け、どのビジネスサービスが変更活動と関連リスクによって最も影響を受けるかを分析できるようにします。

変更リクエストのメインレコードにあり、多くの場合、構成管理データベース（CMDB）からリンクされています。

担当チームは、特定の段階で変更作業に割り当てられた人々のグループを特定します。これは、評価チーム、CABのような承認委員会、または実装を実行する技術チームである可能性があります。

この属性は、リソース割り当て、ワークロード分散、およびチーム間の引き継ぎを分析するために不可欠です。ソーシャルネットワーク分析は、異なるグループ間のコミュニケーションパターンやボトルネックを明らかにできます。各チームで費やされた時間を測定することで、組織はどのグループが過負荷になっているか、または責任の移管中に遅延が頻繁に発生する場所を特定できます。

これは、チーム間の引き継ぎの分析、リソースのボトルネックの特定、および組織全体のワークロード分散の理解に不可欠です。

変更リクエストレコードまたはアクティビティレベルの詳細にあります。「割り当てグループ」または「チーム」と呼ばれる場合があります。

担当ユーザーは、変更リクエストまたはアクティビティに割り当てられた特定の人物です。この属性は、チームレベルの割り当てよりもワークロードと責任をきめ細かく把握できます。

ユーザーレベルでデータを分析することは、パフォーマンス管理やトレーニング機会の特定に役立ちます。これにより、プロセスエキスパートである個人や、特定のタスクに苦労している可能性のある個人を浮き彫りにできます。また、手戻りを分析するためにも使用され、例えば、特定の個人が処理した変更が拒否されたり、修正が必要になったりする可能性が高いかどうかを確認できます。ただし、この情報は建設的に使用し、懲罰的な目的で使用しないよう注意が必要です。

個々のワークロードとパフォーマンスを分析するための詳細なビューを提供し、チーム内の専門家や潜在的なトレーニングニーズを特定するのに役立ちます。

通常、変更リクエストレコードまたはタスクレベルの詳細にあり、「担当者」または「割り当て先」としてラベル付けされていることが多いです。

変更理由は、変更リクエストの背景にあるビジネス上の要因を説明するテキスト記述です。「なぜこれを行うのか？」という問いに答え、「重大な脆弱性に対するセキュリティパッチ」や「顧客体験を向上させる新機能」といった文脈を提供します。

これは自由記述のフィールドであることが多いですが、テキストマイニング技術で分類または分析すると、貴重な定性的インサイトが得られます。ビジネスのさまざまな部門からの変更要求を理解するのに役立ちます。例えば、分析により、多くの変更がバグ修正によって引き起こされていることが明らかになり、ソフトウェア品質の潜在的な問題を示す一方で、別の期間では戦略的プロジェクトに関連する変更が多数を占める可能性もあります。

変更が開始されるビジネスコンテキストを提供し、組織内の変更の主な推進要因を分析するのに役立ちます。

通常、変更リクエストの初期提出フォームまたはヘッダーの詳細にあります。

変更影響度とは、変更がビジネス運用、サービス、またはインフラストラクチャに与える潜在的な影響を測定するものです。これは、緊急度とともに、変更の全体的な優先順位を決定するための主要なインプットとなります。例えば、重要な顧客向けサービスに影響を与える変更は、影響度が高いとされます。

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

ビジネス影響度の高い変更がより厳格なレビューおよびテストパスに従っていることを検証し、適切なガバナンスを確保するのに役立ちます。

変更リクエストのメインレコードまたはヘッダーデータにあります。

変更結果理由は、変更リクエストがどのように終了したかについての背景を提供します。成功した変更であれば「成功」、失敗した変更であれば「失敗 – ロールバック開始」、却下またはキャンセルされた変更であれば「理由不十分」や「申請者によるキャンセル」といった正当化理由が挙げられます。

この属性は、失敗または却下された変更の根本原因分析に不可欠です。これらの理由を分類し分析することで、組織は共通の失敗パターンを特定できます。例えば、「情報不備」を理由に多くの変更が却下されている場合、それは変更申請プロセスの改善が必要であることを示唆します。このデータは、変更失敗率や初回承認率といったKPIの計算と理解に役立ちます。

失敗、却下、またはキャンセルされた変更の根本原因分析に不可欠なデータを提供し、将来の変更リクエストの品質向上に役立ちます。

変更リクエストレコードのクローズ詳細にあります。「クローズコード」、「解決策」、または「却下理由」と呼ばれる場合があります。

変更の緊急度は、ビジネス要件を満たすために変更をどれだけ迅速に実装する必要があるかを示します。これは、潜在的な影響とは別に、変更の時間的切迫性を反映しています。例えば、マーケティングキャンペーン開始前に軽微な問題を修正するなど、影響は小さいが緊急度が高い変更もあります。

緊急度は優先度を計算する上で重要な要素であり、変更管理プロセスの適時性を分析するために使用されます。アナリストは、緊急度の高い変更が実際に迅速に処理されているかを調査できます。異なる緊急度レベル間でサイクルタイムを比較することで、プロセスがビジネスニーズに迅速に対応しているか、あるいはすべての変更が時間的制約に関わらず同じ速度で処理されているかを明らかにすることができます。

異なる緊急度レベル間でサイクルタイムを比較することで、時間的制約のあるビジネスニーズに対するプロセスの応答性を分析できます。

変更リクエストのメインレコードまたはヘッダーデータにあります。

計画完了日は、変更の期限であり、多くの場合、ビジネス要件やサービスレベル契約（SLA）によって決定されます。これは、変更管理プロセスの適時性とパフォーマンスを測定するためのベンチマークとして機能します。

この属性は、SLAパフォーマンス分析に不可欠です。実際の完了日と計画日を比較することで、組織は主要な業績評価指標である定時完了率を計算できます。計画日を逃した変更を分析することで、承認のボトルネック、リソースの制約、非現実的な計画など、遅延の根本原因を特定するのに役立ちます。

これはSLAコンプライアンスと定時納品を測定するための重要な属性であり、プロセスにおける遅延の根本原因を特定するのに役立ちます。

通常、変更リクエストのヘッダーデータにあります。