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

アクティビティ名は、「Risk Assessment Completed」や「Change Approved」など、変更リクエストのライフサイクルにおける個別のステップやマイルストーンを表します。各アクティビティは、アクションが実行された時点、判断が下された時点、またはプロセスが新しい段階に移行した時点を示します。

この属性は、プロセスマップの作成に欠かせません。プロセスグラフのノードを定義し、分析担当者がイベントの順序を可視化し、一般的な経路を特定し、標準手順からの逸脱を検出できるようにします。アクティビティを分析すると、ボトルネック、手戻りループ、変更プロセスの各段階間で発生する非効率な引き継ぎを明らかにできます。

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

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

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

プロセス分析では、この属性を使ってアクティビティを正しい順序に並べ、イベントログの基盤を作ります。アクティビティ間のサイクルタイムや待機時間、ケース全体の期間など、時間に関するすべての指標を算出するために必要です。これらのタイムスタンプを分析すると、どのステップに最も時間がかかっているかを特定し、プロセスを短縮できる箇所を見つけられます。

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

変更リクエストのイベントログまたは監査証跡にあります。「Creation Date」、「Start Date」、または単に「Timestamp」と呼ばれる場合があります。

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

プロセスマイニングでは、この属性が各変更のエンドツーエンドの流れを再構成するために欠かせません。共通の変更リクエストIDの下にすべてのイベントをまとめることで、分析担当者はプロセスフローを可視化し、ケース期間を算出し、変更ライフサイクルごとの差異を分析できます。個々の変更がシステム内でどのように進行するかを明確に把握できる、ケース単位の分析の基盤です。

このIDは、1件の変更に関連するすべてのイベントを追跡・関連付けるために欠かせず、プロセスディスカバリーと適合性チェックの基盤となります。

通常は、変更リクエストのヘッダーまたは主要レコードにあります。

ソースシステム属性は、イベントデータの取得元を示します。複数のITSMツールや統合システムがある環境では、このフィールドによって異なるソースのデータを区別でき、データの整合性と適切なコンテキストを確保できます。

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

データの取得元を示すため、データ検証、トラブルシューティング、複数のシステムにまたがるプロセスの分析に欠かせません。

ソースデータのフィールドとして保存される場合や、データの抽出・変換（ETL）処理中に追加される場合があります。

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

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

データの鮮度を保ち、データパイプラインの状態を監視するのに役立ちます。プロセス分析の信頼性を支える重要な情報です。

通常は、データの抽出、変換、ロード（ETL）処理中に生成・追加されます。

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

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

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

アクティビティログや監査証跡テーブルにあることが多い項目です。利用できない場合は、後続イベントの開始時刻から算出できることがあります。

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

この属性により、リスクに基づくプロセス分析が可能になります。高リスクの変更が、Change Advisory Board（CAB）によるレビューなど、適切なレベルのレビューを受けているか確認できます。また、リスクレベルと結果を関連付けて、高リスクの変更で失敗率が高くなっていないかを調べることもできます。これは、リスク評価や軽減プロセスの改善が必要かどうかを判断する手がかりになります。

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

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

変更優先度は、変更リクエストの相対的な重要度を決めるための分類です。チームがリソースを適切にスケジュール・配分し、最も重要な変更から対応できるようにします。優先度は、変更がビジネスに与える可能性のある影響と、実施の緊急度に基づいて算出されることが多い項目です。

プロセスマイニングでは、優先度はフィルタリングや比較に使える有効な分析軸です。高優先度の変更が低優先度の変更より実際に速く処理されているかを調査できます。差異がある場合は、リソース配分の問題、重要な変更に対する承認のボトルネック、優先順位付けルールの遵守状況に関する問題が考えられます。

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

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

変更ステータスは、特定の時点における変更リクエストの段階、または最終的な結果を示します。通常、ステータスはプロセスの主要なマイルストーンに対応し、進捗を大まかに把握するために使います。

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

変更の進捗を把握できるため、ボトルネック、処理量、変更バックログの現在の状態を分析できます。

変更リクエストのヘッダーレコードにあります。過去のステータス変更は監査ログに記録されている場合があります。

変更タイプは、変更リクエストに必要なワークフロー、承認ステップ、緊急度を決める重要な分類です。Standard変更は通常、事前承認済みでリスクが低く、Normal変更は完全な評価・承認プロセスに従い、Emergency変更は緊急のビジネスニーズに対応するため迅速に処理します。

変更タイプ別にプロセスを分析することは、変更管理分析の中心的な作業です。異なる変更ワークフローのパフォーマンスとコンプライアンスを比較できます。たとえば、Emergency変更が実際により速い経路をたどっているか、Standard変更が簡略化された事前承認フローに従っているかを確認できます。この分類は、プロセスの差異を理解し、適切なレベルのガバナンスが適用されていることを確認するうえで重要です。

変更タイプごとに、あらかじめ定められたプロセスフロー、承認要件、期待されるパフォーマンスが異なるため、分析を分けるうえで欠かせない属性です。

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

影響を受けるビジネスサービスは、変更によって変更される中核的なビジネス機能を示します。「Email Service」や「Online Banking」などが該当します。ビジネスサービスを支えるサーバーやアプリケーションなど、特定の技術的な構成アイテム（CI）の場合もあります。

この属性は、変更管理プロセスにビジネス上のコンテキストを加えます。ITの作業だけでなく、ビジネスへの影響という観点から分析できます。たとえば、変更頻度が最も高いサービスを特定し、不安定さやイノベーションの頻度が高い可能性を確認できます。また、技術的な変更を、それが支えるビジネス機能に結び付けることで、変更の優先順位付けやリスク評価にも役立ちます。

ITの変更をビジネスのコンテキストに結び付け、変更アクティビティと関連リスクによって、どのビジネスサービスが最も大きな影響を受けているかを分析できます。

変更リクエストの主要レコードにあります。構成管理データベース（CMDB）からリンクされていることが多い項目です。

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

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

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

変更リクエストのレコードまたはアクティビティレベルの詳細にあります。「Assignment Group」や「Team」と呼ばれる場合があります。

担当ユーザーは、変更リクエストまたはアクティビティを割り当てられた特定の担当者です。この属性により、チーム単位の割り当てより詳細な作業量と責任の状況を把握できます。

ユーザー単位でデータを分析すると、パフォーマンス管理やトレーニング機会の特定に役立ちます。プロセスに精通した担当者や、特定のタスクに苦労している担当者を明らかにできます。また、手戻りの分析にも使えます。たとえば、特定の担当者が処理した変更で、却下や是正対応が多く発生していないかを確認できます。ただし、この情報は懲罰目的ではなく、建設的に利用する必要があります。

個人の作業量とパフォーマンスを詳細に分析できるため、チーム内の専門家やトレーニングが必要な領域を特定するのに役立ちます。

通常は、変更リクエストのレコードまたはタスクレベルの詳細にあります。「Assignee」や「Assigned To」と表示されることが多い項目です。

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

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

SLAコンプライアンスと期限内の提供を測定するための重要な属性であり、プロセス遅延の根本原因を特定するのに役立ちます。

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

Change Reasonは、変更リクエストの背景にあるビジネス上の理由を説明するテキスト項目です。「なぜこの変更を行うのか」という問いに答えるもので、「重大な脆弱性に対するセキュリティパッチ」や「顧客体験を向上させる新機能」などの背景を記録します。

多くの場合は自由記述欄ですが、分類したりテキストマイニングの手法で分析したりすることで、有益な定性的情報を得られます。組織のさまざまな部門から寄せられる変更需要を把握するのに役立ちます。たとえば、変更の大部分がバグ修正によるものだと分析から分かれば、ソフトウェア品質に潜在的な問題がある可能性を示します。一方、別の期間では、戦略プロジェクトに関連する変更が多いことが分かる場合もあります。

変更が開始される理由を示すビジネス上の背景情報を提供し、組織内で変更を生み出している主な要因の分析に役立ちます。

通常、変更リクエストの初回提出フォームまたはヘッダー情報に記録されています。

変更の影響度は、変更が業務、サービス、インフラに及ぼす可能性のある影響を測定します。緊急度とともに、変更全体の優先度を決める重要な入力情報です。たとえば、顧客向けの重要なサービスに影響する変更は、影響度が高くなります。

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

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

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

変更結果理由は、変更リクエストがその結果に至った理由を示します。成功した変更では「Successful」、失敗した変更では「Unsuccessful - Rollback initiated」、却下またはキャンセルされた変更では「Insufficient justification」や「Canceled by requester」などの正当な理由が記録されます。

この属性は、失敗または却下された変更の根本原因分析に欠かせません。理由を分類・分析すると、失敗の共通パターンを特定できます。たとえば、「Incomplete information」を理由とする却下が多い場合、変更申請プロセスの改善が必要だと分かります。このデータは、変更失敗率や初回承認率などのKPIを算出・理解するためにも役立ちます。

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

変更リクエストレコードのクローズ詳細にあります。「Close Code」、「Resolution」、「Rejection Reason」と呼ばれる場合があります。

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

緊急度は優先度の算出に使う重要な要素であり、変更管理プロセスの適時性を分析するためにも利用します。緊急度の高い変更が実際に速く処理されているかを調査できます。緊急度ごとにサイクルタイムを比較すると、プロセスがビジネスニーズに対応できているか、時間的な制約に関係なくすべての変更を同じ速度で処理していないかを確認できます。

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

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