お客様の契約管理データテンプレート
お客様の契約管理データテンプレート
こちらは契約管理向けの汎用プロセスマイニングデータテンプレートです。より具体的なガイダンスが必要な場合は、システム固有のテンプレートをご利用ください。
特定のシステムを選択- 契約管理プロセス用の汎用データモデル。
- 徹底的な分析のための推奨属性と活動。
- ソースシステムに関わらず、イベントログを抽出するためのガイダンス。
契約管理属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | 契約ライフサイクル内で発生した特定のビジネスイベント、タスク、またはマイルストンの名称。 | ||
| 説明 活動名は、契約管理プロセスにおけるステップを説明します。これらの活動は、「契約書作成済み」、「法務レビュー完了」、「契約締結済み」などの個別 この属性は、プロセスマイニングにおける その重要性 プロセスのステップを定義し、契約ライフサイクルの可視化、およびプロセス逸脱とボトルネックの特定を可能にします。 取得元 通常、主要な契約レコードに関連付けられたイベントログ、監査証跡、またはステータス履歴テーブルで見つかります。 例 契約書作成済み社内承認完了署名のために契約書を送信 | |||
| イベント開始時刻 EventStartTime | 特定のアクティビティまたはイベントが開始した正確な日時を示すタイムスタンプ。 | ||
| 説明 イベント開始時刻は、契約ライフサイクルにおける活動の開始を示します。このタイムスタンプは、イベントを時系列 分析では、このタイムスタンプはプロセス その重要性 このタイムスタンプは、イベントの順序付け、プロセスサイクルタイムの計算、および時間ベースのボトルネック特定のために不可欠です。 取得元 システム監査ログ、トランザクションレコード、またはプロセスステップのタイムスタンプをキャプチャするイベント履歴テーブルで利用可能です。 例 2023-03-15T09:00:00Z2023-05-20T14:30:15Z2023-06-01T11:22:05Z | |||
| 契約ID ContractId | 各契約の一意の識別子であり、関連するすべてのアクティビティと文書をリンクする主要なケース識別子として機能します。 | ||
| 説明 契約 プロセスマイニング分析において、契約 その重要性 この識別子は、契約ライフサイクル全体を追跡し、正確なプロセス発見とパフォーマンス測定を可能にするために不可欠です。 取得元 通常、契約ライフサイクル管理(CLM)システム内の契約オブジェクトのヘッダーまたは主要レコードで見つかります。 例 CTR-2023-00123MSA-98765-ACMENDA-GLOBAL-4510 | |||
| ソースシステム SourceSystem | 契約データが抽出されたITシステムまたはアプリケーションの名称。 | ||
| 説明 ソースシステム属性は、イベントデータの発生源を特定します。多くの組織では、契約ライフサイクルは、CLMプラットフォーム、開始用のCRM、財務データ用のERPシステムなど、複数のシステムにまたがることがあります。各イベントのソースシステムを特定することは、データ検証とプロセスの技術的ランドスケープを理解する上で非常に重要です。 プロセスマイニング分析において、この属性は異なるシステム間でのプロセス分断を特定するのに役立ちます。特定のアプリケーション間のデータ引き継ぎに関連する遅延や問題があるかどうかを明らかにすることができます。また、データガバナンスやデータ品質の問題の発生源を追跡するためにも重要です。 その重要性 データの 取得元 この情報は、データ抽出プロセス中にしばしば追加されるか、システムログの標準フィールドとして利用できる場合があります。 例 AgiloftSAP AribaDocuSign CLM | |||
| 最終データ更新 LastDataUpdate | この`イベント`の`データ`が`ソースシステム`から`最終的`に`更新`または`抽出`された`時刻`を示す`タイムスタンプ`です。 | ||
| 説明 最終データ更新タイムスタンプは、分析対象データの最新性を示します。これは、データ抽出、変換、ロード(ETL)プロセスが最後に実行された日時を示し、分析の鮮度に関するコンテキストを提供します。これは、ビジネス活動が発生した日時を記録するイベントタイムスタンプとは異なります。 分析目的において、この属性はデータガバナンスにとって非常に重要であり、利害関係者にインサイトの鮮度を伝えるためにも不可欠です。ユーザーがリアルタイムの情報を見ているのか、それとも過去の日や週のスナップショットを見ているのかを理解するのに役立ちます。このコンテキストは、プロセスマイニングのダッシュボードに基づいてタイムリーかつ情報に基づいた意思決定を行う上で不可欠です。 その重要性 データの 取得元 このタイムスタンプは通常、データ統合ツールまたはETLツールによってデータロードプロセス中に生成され、保存されます。 例 2023-10-26T02:00:00Z2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| イベントの終了時刻 EventEndTime | 特定のアクティビティまたはイベントが完了した正確な日時を示すタイムスタンプ。 | ||
| 説明 イベント終了時刻は活動の完了を示します。イベント開始時刻 この属性は、ボトルネック分析の基礎となる活動期間を計算するために使用されます。「承認 その重要性 活動レベルの期間計算を可能にし、プロセスボトルネックの正確な場所を特定するために不可欠です。 取得元 システム監査ログまたはイベント履歴テーブルで確認できます。明示的に記録されていない場合は、後続のイベントの開始時刻から導出する必要がある場合があります。 例 2023-03-15T17:30:00Z2023-05-22T10:15:45Z2023-06-01T11:55:10Z | |||
| ユーザー名 UserName | 契約活動を実行または担当したユーザー、従業員、またはリソースの名称またはID。 | ||
| 説明 ユーザー名は、契約ライフサイクルにおける特定のタスクを完了する責任を持つ個人を識別します。これは、契約担当者、法務審査担当者、承認者、または署名者である可能性があります。この属性は、プロセス活動を実行する人物とリンクします。 プロセスマイニングにおいて、この属性はチームおよび個人のパフォーマンスに関する視点を提供します。「チームの作業負荷と生産性」のようなダッシュボードで使用され、作業がどのように分散されているかを分析し、過負荷になっている従業員やチームを特定し、パフォーマンスを評価します。また、異なるユーザー行動がプロセスバリエーションや遅延につながる可能性を理解するのにも役立ち、的を絞ったトレーニングやリソース配分を可能にします。 その重要性 プロセス活動を個人に接続し、ワークロード配分、チームパフォーマンス、およびリソース配分の分析を可能にします。 取得元 通常、ソースシステム内のトランザクションレコード、監査ログ、またはタスク割り当てフィールドで利用可能です。 例 John Smithj.smith@example.comUSER12345 | |||
| 契約ステータス ContractStatus | 「`ドラフト`」、「承認中」、「実行済み」、「有効期限切れ」など`の`契約の現在のライフサイクル段階または状態。 | ||
| 説明 契約ステータスは、特定の時点 この属性は、契約 その重要性 契約の現在の段階の 取得元 これは、CLMシステムの主要な契約レコードにある主要なステータスフィールドです。 例 下書き審査中締結済み終了済み | |||
| 契約形態 ContractType | 包括的サービス契約(`MSA`)、秘密保持契約(`NDA`)、作業明細書(`SOW`)など`の`契約の分類。 | ||
| 説明 契約タイプは、法的性質と目的に基づいて契約を分類するカテゴリ属性です。一般的なタイプには、NDA、MSA、SOW、および販売または調達契約が含まれます。この分類は、契約ライフサイクルに不可欠なビジネスコンテキストを提供します。 この属性は、比較分析のための強力な側面です。アナリストはプロセス その重要性 プロセスのセグメンテーションと比較を可能にし、異なる契約タイプがサイクルタイム、複雑性、リスクにどのように影響するかを明らかにします。 取得元 これは、任意のCLMシステムの主要な契約レコードにある標準フィールドです。 例 秘密保持契約(`NDA`)包括的サービス契約(`MSA`)作業明細書(`SOW`) | |||
| 契約金額 ContractValue | 契約に関連する総金銭的価値。これは収益、費用、またはコミットメントを表すことができます。 | ||
| 説明 契約金額は、契約の財務的意義を定量化します。この金額は、契約の優先順位付け プロセスマイニングでは、この属性はプロセスパフォーマンス その重要性 契約の財務的影響を定量化し、優先順位付け、およびプロセス非効率性が高価値契約にどのように影響するか 取得元
例 100000.0025000.505000000.00 | |||
| 相手方名 CounterpartyName | 契約に関与する外部関係者(企業、クライアント、ベンダー、パートナーなど)の名称。 | ||
| 説明 相手方名は、組織が合意を結ぶ外部 分析のための その重要性 外部の当事者を特定し、顧客またはベンダー 取得元 契約レコード上の標準フィールドで、顧客またはサプライヤーのマスターデータレコードにリンクされていることが多い。 例 Acme Corporation`Global Tech Inc.`Innovate Solutions LLC | |||
| 部署 Department | 営業、法務、調達など、契約`を`所有する社内事業単位または部門。 | ||
| 説明 部門属性は、契約に責任を持つ、または契約に関連する社内 これは、社内 その重要性 異なる事業単位間でのプロセスパフォーマンスの比較を可能にし、内部のボトルネックを特定し、 取得元 通常、契約担当者のユーザープロフィールに関連付けられているか、契約レコード自体のフィールドとして指定されています。 例 営業法務調達IT | |||
| 改訂回数 RevisionCount | 交渉およびレビューサイクル中に契約書が改訂または修正された回数のカウンター。 | ||
| 説明 リビジョンカウントは、契約が実行されるまでにどれだけ手直しされたかを追跡します。文書が編集され、新しいバージョンが作成されるたびに、このカウントは増加します。これは、交渉プロセスの複雑さと紛争性の代理指標となります。 この属性は効率の直接的な測定値であり、「契約手直し率」KPIの計算に使用されます。「交渉と手直しの効率」ダッシュボードは、このデータを使用して、過剰な数の改訂を必要とする契約、取引先、または契約タイプを特定します。高いリビジョンカウントは、サイクルタイムの長期化と相関することが多く、要件の不明確さ、積極的な交渉戦術、またはより良い標準テンプレートの必要性を示している可能性があります。 その重要性 手戻りと交渉の複雑性の 取得元 契約書のバージョン番号フィールドから取得するか、各ケースの「契約改訂」活動数をカウントすることで導出できます。 例 135 | |||
| 有効期限 ExpirationDate | 更新または解除されない場合に、契約が有効期限切れとなる日付。 | ||
| 説明 有効期限は、契約期間の終了を示す重要な日付 プロセスマイニングでは、この属性は「義務 その重要性 更新管理とリスク軽減に不可欠なこの日付は、契約 取得元 これは、CLMシステムの主要な契約レコードにある重要な日付フィールドです。 例 2024-12-312025-06-302026-01-15 | |||
契約管理活動
| アクティビティ | 説明 | ||
|---|---|---|---|
| 契約リクエスト開始 | これは契約ライフサイクルにおける最初の活動であり、新しい契約の正式な要求を表します。通常、システム内で新しい契約レコードまたはワークスペースが作成されることで取得されます。 | ||
| その重要性 この活動はプロセスの公式な開始を示し、そのタイムスタンプは総契約サイクルタイムを計算する上で不可欠です。リクエストの量を分析することは、リソース計画と需要管理に役立ちます。 取得元 このイベントは通常、ソースシステムの主要契約テーブルまたは監査ログ内の主要な契約レコードまたはオブジェクトの作成タイムスタンプから取得されます。 取得 ユニークな契約 イベントタイプ explicit | |||
| 契約更新済み | 契約期間満了時の成功的な契約更新を表します。これは、契約の有効期間を延長する重要なビジネス`アウトカム`です。 | ||
| その重要性 更新率は、顧客維持と満足度の直接的な尺度です。このイベントを追跡することは、長期的なビジネス成功と収益継続性を理解するために不可欠です。 取得元 これは多くの場合、契約ステータスを更新するか、元の契約に続く更新期間の新しい契約レコードを作成する明示的なユーザーアクションです。 取得 「更新済み」へのステータス変更、または元の契約に更新としてリンクされた新しい契約の作成を探します。 イベントタイプ explicit | |||
| 契約有効化済み | 契約が有効`かつ`強制力を持つようになることを表します。これは実行日`当日`またはそれ以降に発生する可能性があります。このイベントは、義務管理とパフォーマンス追跡の開始を`トリガー`します。 | ||
| その重要性 契約プロセスから契約管理プロセスへの移行をアクティベーションが示します。これはコンプライアンス、更新、および義務を追跡するための真の開始日です。 取得元 これは多くの場合、システム内でステータスが「実行済み」から「アクティブ」または「ライブ」に変わることで記録され、場合によっては指定された「発効日」フィールドに紐付けられます。 取得 ステータスが「アクティブ」に変更されたタイムスタンプを使用するか、可能であれば契約発効日を使用します。 イベントタイプ inferred | |||
| 契約期限切れ | このイベントは、契約が更新または早期終了されることなく、終了日に達したことを意味します。これは、契約ライフサイクルの自然で計画された完了を表します。 | ||
| その重要性 期限切れの追跡は、更新管理や意図しないサービスまたは契約の失効を避ける上で極めて重要です。更新されなかった期限切れの数が多い場合、ビジネス機会の喪失を示唆する可能性があります。 取得元 このイベントは通常、明示的にログに記録されませんが、契約の有効期限フィールドを現在の日付と比較することで計算されます。 取得 システム日付が契約レコードの「有効期限」フィールド以上であるときにタイムスタンプを作成することで、このイベントを導出します。 イベントタイプ calculated | |||
| 契約締結済み | これは、すべての当事者が契約に署名し、法的に拘束力を持つようにする主要なマイルストーンです。これは、契約ライフサイクルの署名前フェーズの成功裏の完了を表します。 | ||
| その重要性 主要な成功結果として、実行日はリクエストから実行までの全体サイクルタイムを計算するために不可欠です。これはパフォーマンスおよびスループット分析の主要なイベントです。 取得元 これは通常、電子署名プラットフォームとの統合を通じて明示的に取得されるか、ユーザーが手動でステータスを「実行済み」に更新し、実行日を入力するときに取得されます。 取得 電子署名システムからの完了タイムスタンプ、またはステータスが手動で「実行済み」に変更された日付を使用します。 イベントタイプ explicit | |||
| 契約解除済み | アクティブな契約が予定された有効期限前に早期解除されることを表します。これは、契約条件によって許可される原因または便宜による場合があります。 | ||
| その重要性 このイベントは、ビジネス関係の早期終了を示します。終了の頻度と理由を理解することは、リスク管理とビジネス健全性にとって不可欠です。 取得元 これは明示的なイベントであり、通常、ユーザーが契約ステータスを「終了済み」に変更することで記録され、多くの場合、理由コードやメモが添付されます。 取得 アクティブな契約のステータスが「解除済み」に変更されたときのタイムスタンプをキャプチャします。 イベントタイプ explicit | |||
| 社内承認完了 | このマイルストーンは、必要なすべての内部利害関係者が契約の最終バージョンを承認したことを示します。これは、組織が合意し、外部に契約を提示する準備が整ったことを意味します。 | ||
| その重要性 これは、内部交渉の終了を示すプロセス内の主要なゲートです。この段階に達するまでにかかる時間は、内部効率の主要なパフォーマンス指標となります。 取得元 これは通常、契約ステータスが「完全に承認済み」や「署名準備完了」のような最終承認状態に移行したとき、または最後の承認タスクが完了したときに推測されます。 取得 全体的な承認ステータスが完了に変更されたとき、または最終的に必要な承認がログに記録されたときのタイムスタンプを特定します。 イベントタイプ inferred | |||
| 署名のために契約書を送信 | この活動は、最終的に承認された契約がすべての当事者による実行のために発送されることを示します。これにより、すべての交渉が終了し、最終的な実行段階が開始されます。 | ||
| その重要性 これは、最終署名サイクルの開始を告げる重要なマイルストーンです。この時点から実行までの時間を分析することで、署名プロセスの遅延が明らかになることがあります。 取得元
取得
イベントタイプ explicit | |||
| 交渉開始 | 相手方との往復交渉が開始されたことを示します。これは多くの場合、外部当事者から最初に応答または修正されたドキュメントが受領されたことで`マーク`されます。 | ||
| その重要性 交渉開始の追跡は、交渉サイクルタイムを分析し、取引先が応答にどれくらい時間がかかるかを理解するために不可欠です。 取得元 これは多くの場合、新しい文書バージョンが外部関係者によってアップロードされたとき、または契約ステータスがアクティブな交渉を反映するように変更されたときに推測されます。 取得 取引先から最初に受領した文書のタイムスタンプ、またはステータスが「交渉中」に変更された時点を使用します。 イベントタイプ inferred | |||
| 修正開始 | このイベントは、既存の有効な契約に対する正式な修正プロセスの開始を示します。これは、合意の元の条件への変更要求を意味します。 | ||
| その重要性 頻繁な修正は、元の契約が十分に包括的でなかったことを示している可能性があります。修正を分析することで、ビジネス関係の変化する性質を把握できます。 取得元 これは多くの場合、元の契約にリンクされた新しい「修正」レコードまたはワークスペースの作成によって取得され、システムの主要データテーブルで見つかります。 取得 親契約 イベントタイプ explicit | |||
| 契約撤回済み | 契約リクエストまたは進行中の契約が、実行前に意図的にキャンセルされたことを示します。これはプロセスを停止する終端状態です。 | ||
| その重要性 契約が撤回される理由を分析することで、資格認定プロセスやビジネス優先順位の変化における問題が明らかになることがあります。これは監視すべき重要な負の結果です。 取得元 これは明示的な終了状態であり、通常、ユーザーがシステムのステータス履歴ログで契約ステータスを「キャンセル済み」または「取り下げ済み」に変更することで取得されます。 取得 契約ステータスが「キャンセル済み」または「撤回済み」の最終状態に更新されたときのタイムスタンプをキャプチャします。 イベントタイプ explicit | |||
| 契約改訂済み | 交渉または社内レビュー中に契約`ドキュメント`が改訂または修正された`インスタンス`を表します。各改訂は`ドキュメント`の新しい`バージョン`を作成します。 | ||
| その重要性 改訂の頻度、つまり手戻り率は、プロセス効率と契約複雑性の主要な 取得元 これは通常、主要な契約文書の新しいバージョンがシステムの文書リポジトリにアップロードまたは保存されるたびに明示的に取得されます。 取得 初版ドラフト後にアップロードされた各新しいドキュメントバージョンのタイムスタンプをキャプチャします。 イベントタイプ explicit | |||
| 契約書作成済み | 最初の契約`ドラフト`の完了を表します。これは多くの場合、契約`ドキュメント`の最初の`バージョン`がアップロードまたは生成され、契約レコードに関連付けられたときにキャプチャされます。 | ||
| その重要性 リクエストからドラフト作成までの時間を追跡することで、初期設定と作成効率に関するインサイトが得られます。この段階での遅延は、プロセスのボトルネックの初期兆候となる可能性があります。 取得元 通常、契約レコードに関連付けられた文書管理または添付ファイルログで見つかります。「ドラフト作成完了」のようなステータス変更から推測することもできます。 取得 最初の文書バージョンアップロードのタイムスタンプ、またはステータスが「ドラフト済み」に変更された時点を使用します。 イベントタイプ inferred | |||
| 法務レビュー完了 | 法務部門が契約のレビューを完了したことを示します。これは、契約がより広範な承認または外部交渉に進む前の重要な`チェックポイント`です。 | ||
| その重要性 法務レビューの期間を測定することは、法務 取得元 多くの場合、法務 取得 法務部門に割り当てられたタスクの完了タイムスタンプ、または法務承認を示すステータス変更を探します。 イベントタイプ explicit | |||
| 相手方に契約書を送信 | この活動は、契約が外部の取引先に審査と交渉のために送付される瞬間を示します。これにより、内部プロセスから外部とのやり取りへの移行がマークされます。 | ||
| その重要性 このイベントは、外部交渉サイクルを測定するための出発点です。契約の送付遅延は、取引サイクル全体を長期化させる可能性があります。 取得元 これは、「交渉のために送信」のような明示的なユーザーアクションであるか、「交渉中」または「外部審査中」へのステータス変更から推測される場合があります。 取得 「相手方に送信」イベント、または外部レビュー状態へのステータス変更のタイムスタンプをキャプチャします。 イベントタイプ explicit | |||
| 社内レビュー開始 | この活動は、作成された契約が正式に内部の利害関係者に審査とフィードバックのために送付される時点を示します。これは、内部コラボレーションと承認フェーズの開始を表します。 | ||
| その重要性 これは、内部審査サイクル全体を測定するための出発点です。このフェーズに費やされた時間を分析することで、利害関係者の調整におけるボトルネックを特定するのに役立ちます。 取得元 これは通常、ワークフロー内のステータス変更(例:「ドラフト」から「内部審査」への移行)や、審査タスクの作成によって取得されます。 取得 契約ステータスが「レビュー中」に変更されたとき、または最初のレビュータスクが割り当てられたときのタイムスタンプをキャプチャします。 イベントタイプ explicit | |||
| 義務`モニタリング`開始 | この活動は、実行後の管理の開始を示し、主要な期日、成果物、およびその他のコミットメントが積極的に追跡されます。これは、授与後のコンプライアンスを確保するための最初のステップです。 | ||
| その重要性 この活動は、署名後のガバナンスを理解するために極めて重要です。これらのタスクを追跡することで、契約からの価値実現とリスク軽減が確実になります。 取得元 これは、契約上の義務を監視するためのタスク、チェックリスト、またはサブプロセスが作成または開始されたときに取得され、多くの場合、タスク管理ログで見つかります。 取得 アクティブな契約に対する義務またはコンプライアンス追跡に関連するタスクまたはイベントの作成タイムスタンプをキャプチャします。 イベントタイプ explicit | |||