お客様の契約管理データテンプレート
お客様の契約管理データテンプレート
- 収集を推奨する項目
- 追跡すべき主要アクティビティ
- 抽出の手引き
契約管理属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ名
ActivityName
|
契約ライフサイクルで発生した特定のビジネスイベントまたはタスクの名称。 | ||
|
説明
この属性の分析により、プロセスフローが明らかになり、一般的および代替パスが特定され、各アクティビティの頻度を測定するのに役立ちます。これは、プロセス適合性、リワーク、および異なるステージ間のサイクルタイムに関連するKPIを計算するための基本です。
その重要性
プロセスのステップを定義し、プロセスマップの基盤を形成することで、ワークフロー、逸脱、アクティビティ頻度の分析を可能にします。
取得元
これは多くの場合、Conga CLMの
例
契約書作成済み法務レビュー実施済み契約実行済み/署名済み契約更新済み
|
|||
|
イベントのタイムスタンプ
EventTimestamp
|
アクティビティが開始または発生した正確な日時。 | ||
|
説明
この属性は、アクティビティ間の期間、全体のケースサイクルタイム、および待機時間を計算するために使用されます。ボトルネックの特定、SLAコンプライアンスの監視、および契約管理プロセスの時間的ダイナミクスの理解に不可欠です。ケース内のイベントの主要なソートキーとして機能します。
その重要性
イベントの時系列を提供し、所要時間系の指標計算、ボトルネックの発見、プロセスパフォーマンスの把握に不可欠です。
取得元
このデータは通常、関連するタスクまたはイベントオブジェクト上の『
例
2023-04-15T10:05:00Z2023-05-20T14:30:00Z2023-06-01T09:00:00Z
|
|||
|
契約ID
ContractId
|
各契約合意のユニークな識別子であり、主要なケース識別子として機能します。 | ||
|
説明
プロセスマイニング分析では、各契約のジャーニーを再構築するために、すべてのイベントが
その重要性
これは、契約の完全なライフサイクルを追跡するための不可欠なキーであり、関連するアクティビティを単一のケースに接続することで、すべてのプロセスマイニング分析を可能にします。
取得元
これは通常、Conga CLMのメイン
例
a015g00000_12345a015g00000_67890a015g00000_ABCDE
|
|||
|
ソースシステム
SourceSystemName
|
データが抽出されたソースシステムを特定します。 | ||
|
説明
この属性は、イベントデータの記録システムを指定します。このケースではConga CLMです。特に複数のシステムからデータがマージされる環境では、データガバナンスとトレーサビリティにとって重要です。 単一システム分析では静的に見えるかもしれませんが、データの出所に関する重要なコンテキストを提供し、データ整合性を確保し、データ抽出の問題をトラブルシューティングするのに役立ちます。CRMやERPなどの他のシステムからの情報と契約データを組み合わせる際には、不可欠となります。
その重要性
データ系列とガバナンスのための不可欠なコンテキストを提供し、プロセスデータの発生源を明確にすることで、検証と信頼のために重要となります。
取得元
これは通常、データセットの出所をラベル付けするために、データ抽出および変換(ETL)プロセス中に加えられる静的な値です。
例
Conga CLMCongaCLM-ProdSalesforce-CongaCLM
|
|||
|
最終データ更新
LastDataUpdateTimestamp
|
このレコードのデータがソースシステムから最後に更新された日時を示すタイムスタンプ。 | ||
|
説明
この属性は、Conga CLMからの最新のデータ抽出の日時を記録します。これは、分析の鮮度を理解し、意思決定が最新の情報に基づいていることを確実にするための重要なメタデータです。 ダッシュボードやレポートでは、このタイムスタンプがデータの最新性をユーザーに伝えます。これは、データガバナンスと、プロセスマイニングツールによって提供されるインサイトの適時性に関するユーザーの期待を管理するために不可欠です。
その重要性
このタイムスタンプはデータの鮮度を示し、あらゆる分析や意思決定が理解され許容される時間枠に基づいていることを保証します。
取得元
これは通常、データ取り込みプロセス中にETL(Extract, Transform, Load)ツールまたはスクリプトによって生成および投入されるメタデータフィールドです。
例
2024-07-20T02:00:00Z2024-07-21T02:00:00Z
|
|||
|
イベントの終了時刻
EventEndTime
|
`アクティビティ`が完了した正確な日時です。 | ||
|
説明
この属性はパフォーマンス分析にとって極めて重要であり、各ステップに要する時間を測定することを可能にします。これにより、どの活動が最も時間がかかっているかを特定するのに役立ち、次のイベントの開始時刻を使用するだけの場合と比較して、リソース使用率と効率性のより正確なビューを提供します。
その重要性
アクティビティの処理時間を正確に計算することを可能にし、これは期間ベースのボトルネックを特定し、リソース効率を分析するために不可欠です。
取得元
このタイムスタンプは、メイン契約に関連するタスクまたはアクティビティオブジェクト上の『
例
2023-04-15T18:35:00Z2023-05-21T11:00:00Z2023-06-01T17:45:00Z
|
|||
|
契約ステータス
ContractStatus
|
『ドラフト』、『承認中』、または『実行済み』など、契約の現在のライフサイクルステージ。 | ||
|
説明
契約ステータスは、契約ライフサイクルにおける現在の契約の状態を示します。イベントベースの活動名とは異なり、特定の時点での契約がどこにあるかのスナップショットを提供します。 イベントログが過去の活動のシーケンスを示す一方、ステータスは契約の現在の状況に関するコンテキストを提供します。これは、たとえば、現在有効な契約のみを分析したり、なぜ多くの契約が「承認中」ステータスで停滞しているのかを調査したりする際に役立ちます。活動データを補完し、状態情報を提供します。
その重要性
契約の現在の段階のスナップショットを提供し、アクティブなケースのフィルタリングや分析、プロセス状態の分布を理解するのに役立ちます。
取得元
これは
例
下書き内部レビュー中実行済み期限切れ
|
|||
|
契約形態
ContractType
|
NDA、MSA、またはSOWなど、契約の分類。 | ||
|
説明
契約タイプは、法的目的または性質に基づいて契約を分類するカテゴリ属性です。一般的な例には、秘密保持契約(NDA)、基本契約(MSA)、および作業範囲記述書(SOW)などがあります。 このディメンションは比較分析の基本です。異なる種類の契約が異なるパスをたどるか、または異なるサイクルタイムを持つかをプロセスマップでフィルタリングして確認できます。これは、特定の契約タイプに適したプロセスバリエーションと、真の逸脱であるバリエーションを区別するために不可欠です。
その重要性
プロセスをセグメント化することで、NDAとMSAのような異なる契約カテゴリのワークフロー、サイクルタイム、およびボトルネックを比較することを可能にします。
取得元
これは通常、
例
秘密保持契約(NDA)マスターサービス契約(MSA)作業明細書(SOW)
|
|||
|
契約担当者
ContractOwner
|
契約のライフサイクル全体を管理する責任を負うユーザーまたは従業員。 | ||
|
説明
その重要性
ユーザーごとのパフォーマンス分析を可能にし、優秀な担当者、トレーニング機会、およびワークロード配分の問題を特定するのに役立ちます。
取得元
これはConga CLMのメイン
例
Alice Johnsonロバート・チェンMaria Garcia
|
|||
|
契約金額
ContractValue
|
契約に関連する総金銭的価値。 | ||
|
説明
契約金額は、合意の金銭的価値を表します。これは、総契約額、年間経常収益、またはビジネスコンテキストに応じてその他の主要な財務指標である可能性があります。 この属性の分析は、価値ベースのプロセス最適化にとって重要です。高価値契約の優先順位付けを可能にし、高価値契約がより速く処理されるのか、または特定の段階でより頻繁に停滞するのかといった疑問に答えるのに役立ちます。「契約金額スループット分析」ダッシュボードの鍵となります。
その重要性
これにより、価値ベースの分析が可能になり、高価値契約のプロセス改善を優先し、ビジネスへの影響を理解するのに役立ちます。
取得元
これは通常、Conga CLMの
例
500002500001200000
|
|||
|
有効期限
ExpirationDate
|
契約が満了する日付。 | ||
|
説明
この属性は、『今後の更新と満了』ダッシュボードおよび『適時更新率』KPIにとって極めて重要です。この日付を分析することにより、組織は契約の満了をプロアクティブに管理し、タイムリーに更新プロセスを開始し、意図しないサービスや収益の失効を防ぐことができます。
その重要性
この日付は、プロアクティブな契約管理にとって重要であり、今後の満了を追跡するダッシュボードを可能にすることで、更新の見落としや収益損失を防ぎます。
取得元
これは
例
2025-12-312026-06-302024-08-15
|
|||
|
コンプライアンス状況
ComplianceStatus
|
契約が必要なコンプライアンスレビューに合格したかどうかを示します。 | ||
|
説明
コンプライアンスステータスは、内部ポリシーまたは外部規制に関する契約の状態を追跡します。「未開始」、「レビュー中」、「合格」、「不合格」などの値を持つことがあります。 この属性は、「コンプライアンスおよび義務監視」ダッシュボードおよび関連するKPIにとって不可欠です。これにより、コンプライアンス遵守状況を直接的に可視化し、すべての契約が実行または有効化される前に必要なチェックを受け、合格することを保証することで、法的および財務的リスクを軽減するのに役立ちます。
その重要性
コンプライアンスプロトコルへの準拠を直接測定し、契約ポートフォリオ内の法的および財務的リスクを特定し、軽減するのに役立ちます。
取得元
これは
例
合格レビューが必要該当なし不合格
|
|||
|
ビジネスユニット
BusinessUnit
|
契約が所属する組織内の特定の事業部門。 | ||
|
説明
その重要性
組織部門別にプロセスパフォーマンスをセグメント化することを可能にし、企業全体の効率性や手順における変動を浮き彫りにします。
取得元
これは、
例
北米営業EMEAサービスAPAC製品部門
|
|||
|
処理時間
ProcessingTime
|
アクティビティにアクティブに費やされた時間の計算された期間。 | ||
|
説明
処理時間とは、アクティビティの開始から終了までの経過時間を測定します。これはアクティビティ間の待機時間とは異なり、実際の作業期間を表します。このメトリックは この属性は、プロセス内でどの特定のステップが最も時間のかかるものかを特定するために不可欠です。『レビューフェーズボトルネック』ダッシュボードをサポートし、アクティビティ期間の詳細な分析を可能にします。処理時間と待機時間を区別することは、遅延の根本原因を理解するための鍵となります。
その重要性
各アクティビティのアクティブな作業時間を測定し、非効率なステップ(長い処理時間)とプロセス遅延(長い待機時間)を区別するのに役立ちます。
取得元
これは、
例
864001728003600
|
|||
|
取引先名
CounterpartyName
|
契約に関与する外部の当事者、企業、または個人の名称。 | ||
|
説明
取引先名は、合意のもう一方の署名者を特定します。これは通常、顧客、ベンダー、またはパートナー組織です。 取引先別にプロセスメトリクスを分析することで、重要なパターンを明らかにできます。たとえば、特定の取引先との交渉が常に長くかかったり、より多くの改訂が必要になったりすることが示される場合があります。この洞察は、交渉戦略を策定し、主要なビジネスパートナーとの関係管理に役立ちます。
その重要性
外部関係者に基づいたプロセス変動の分析を可能にし、どの顧客やベンダーがより長い交渉サイクルや高い改訂率を持つかを特定するのに役立ちます。
取得元
これは多くの場合、Salesforceの
例
`Global Tech Inc.`Innovate Solutions LLCAcme Corporation
|
|||
|
地域
Region
|
『北米』または『EMEA』など、契約に関連付けられた地理的地域。 | ||
|
説明
この属性により、契約プロセスの地政学的分析が可能になります。『EMEAでの契約は、異なる規制のため承認に時間がかかりますか?』や『APAC地域での契約は、修正(レッドライニング)率が高いですか?』といった疑問に答えるのに役立ちます。これは、グローバルオペレーションにとって価値のあるコンテキストを提供します。
その重要性
地域別にセグメント化することで、サイクルタイム、コンプライアンス要件、またはプロセスパスにおける地理的変動を特定するのに役立ち、これはグローバルビジネスにとって重要です。
取得元
これは多くの場合、
例
北米EMEAAPACLATAM
|
|||
|
手戻り
IsRework
|
活動が手戻りループの一部であるかどうかを示す計算済みのフラグです。 | ||
|
説明
リワークとは、法務レビュー後に『契約書作成済み』段階に戻るなど、プロセスにおける後戻りを表すアクティビティである場合に『true』に設定されるブールフラグです。これはソースシステムには存在せず、プロセスマイニングのためのデータ変換中に計算されます。 このフラグは、プロセスの非効率性を数値化する上で非常に価値があります。『契約リワーク率』KPIを直接サポートし、プロセスマップ内のプロセスループを視覚化するのに役立ちます。リワークの頻度と原因を特定することは、多くのプロセス改善イニシアチブの主要な目標です。
その重要性
この計算されたフラグにより、無駄なリワークループの一部であるアクティビティを強調表示することで、プロセスの非効率性を定量化し、分析することが容易になります。
取得元
この属性はソースシステムにはありません。アクティビティのシーケンスに基づいて、プロセスマイニングツールまたはETL層で計算されます。
例
truefalse
|
|||
|
承認サイクルタイム
ApprovalCycleTime
|
契約が承認フェーズで費やす合計時間。 | ||
|
説明
承認サイクルタイムは、契約が「内部レビュー開始」などの承認プロセスに入ってから、最終的な内部承認を受けるまでの期間を測定する計算済み指標です。これは、すべての関連する承認ステップにわたる時間を集計します。 この属性は、「契約承認サイクルタイム」ダッシュボードおよび「平均契約承認時間」KPIの主要な測定値です。承認ワークフロー全体の効率性を高レベルで把握でき、目標に対するパフォーマンス追跡やシステム的な遅延の特定を容易にします。
その重要性
このKPIは、承認ワークフローの効率を直接測定し、契約ライフサイクルの重要なフェーズにおける遅延を特定し、対処するのに役立ちます。
取得元
これは、各契約の最初の承認アクティビティと最終承認アクティビティ間の時間差を見つけることによって導出される計算メトリックです。
例
259200604800432000
|
|||
|
担当部門
OwnerDepartment
|
『営業』、『法務』、または『調達』など、契約の所有者の部門。 | ||
|
説明
これは分析のための強力な側面であり、異なる部門間でのプロセスパフォーマンスの比較を可能にします。法務部門がボトルネックになっているか、営業チームが異なるプロセスに従っているか、または特定の部門が著しく長いサイクルタイムを持っているかを特定するのに役立ちます。このインサイトは、部門横断的なプロセス改善イニシアチブにとって価値があります。
その重要性
ビジネス機能ごとのプロセス分析を可能にし、営業部門と法務部門のような部署間のパフォーマンス差異やボトルネックを明らかにします。
取得元
このデータは通常、Salesforceの
例
営業法務調達財務
|
|||
|
更新日
RenewalDate
|
契約の更新プロセスを開始するための目標日。 | ||
|
説明
この属性は、チームが更新パイプラインを効果的に管理するのに役立ちます。契約更新に関連するアラートをトリガーし、タスクを自動化するために使用でき、プロセスが十分なリードタイムで開始されることを保証します。これは、『適時更新率』KPIの重要な要素です。
その重要性
更新活動のトリガーポイントを提供し、契約が期日通りに更新されることを確実にするのに役立ち、プロアクティブなライフサイクル管理をサポートします。
取得元
これは、
例
2025-10-022026-04-012024-05-17
|
|||
契約管理活動
| アクティビティ | 説明 | ||
|---|---|---|---|
|
内部承認取得済み
|
このマイルストーンは、契約が必要なすべての内部承認を受け、実行準備が整ったことを示します。これは通常、多段階のSalesforce承認プロセスの最終ステップです。 | ||
|
その重要性
これは、内部レビューと承認サイクルを締めくくる重要なマイルストーンです。『平均契約承認時間』KPIを測定するための終点となります。
取得元
契約オブジェクト上のSalesforce承認履歴関連リストからキャプチャされます。イベントは、プロセスにおける最終的な「承認済み」ステータスのタイムスタンプです。
取得
関連する承認プロセスにおける最終承認ステップのタイムスタンプをキャプチャします。
イベントタイプ
explicit
|
|||
|
契約実行済み/署名済み
|
これは、すべての当事者が法的に契約に署名し、拘束力のある合意となる極めて重要なアクティビティです。Conga CLMと統合された電子署名ソリューション(Conga Signなど)は、明示的なタイムスタンプ付きイベントを作成します。 | ||
|
その重要性
このアクティビティは、署名前プロセスの成功裏の完了を表し、『契約実行率』のようなパフォーマンスメトリックにとって重要なマイルストーンです。これはしばしば、主要な『ハッピーパス』終了イベントと見なされます。
取得元
統合された電子署名ツールの監査証跡またはステータスからキャプチャされます。最終的な「完了」または「署名済み」ステータスが正確なタイムスタンプと共に記録されます。
取得
統合された電子署名サービスAPIまたはステータスオブジェクトから完了イベントを記録します。
イベントタイプ
explicit
|
|||
|
契約書有効化済み
|
契約が組織内で有効かつ運用可能となり、義務と権利が発動されることを表します。これは通常、『実行済み』から『有効』へのステータス変更から推測されます。 | ||
|
その重要性
このアクティビティは、署名後のライフサイクルの始まりを示します。これは、義務管理とパフォーマンス監視のトリガーとなります。
取得元
契約オブジェクトのステータス項目履歴から推測されます。イベントは、ステータスが「有効」または同等の用語に変更されたタイムスタンプです。
取得
ステータスが「実行済み」から「有効」に変更されたタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
契約期限切れ
|
契約が更新または終了されることなく、有効期限に達した際の自然な契約ライフサイクルの終了を表します。このイベントは明示的に記録されず、契約データから派生します。 | ||
|
その重要性
このアクティビティは、契約ライフサイクルの計画された終了を定義します。満了した契約を分析することは、更新機会と全体的な契約ポートフォリオ管理を理解するのに役立ちます。
取得元
これは計算されたイベントです。アクティビティは、システムの日付が
取得
「契約終了日」フィールドを現在の日付と比較して導出します。
イベントタイプ
calculated
|
|||
|
契約終了
|
このアクティビティは、特定の行動に基づいて、契約が有効期限前に早期終了することを示します。これは、契約のステータスが『終了済み』に変更されることで捕捉されます。 | ||
|
その重要性
主要な最終状態として、終了イベントは契約不履行率やキャンセル理由を理解する上で重要です。これにより、しばしば否定的ではありますが、プロセスに対する明確な結論が提供されます。
取得元
契約オブジェクトのステータス項目履歴から推測されます。イベントは、ステータスが「終了」または「キャンセル済み」に更新されたタイムスタンプです。
取得
ステータスが「終了」に変更されたタイムスタンプをキャプチャします。
イベントタイプ
inferred
|
|||
|
契約要求開始
|
このアクティビティは、契約ライフサイクルの正式な開始を示し、システム内に新しい契約レコードが作成されることを表します。これは通常、ユーザーがConga CLMで新しい`Contract`オブジェクトを作成した際の明示的なイベントとして捕捉されます。 | ||
|
その重要性
すべての契約の開始点として、この活動はエンドツーエンドのサイクルタイムを測定する上で不可欠です。開始されている契約の量と種類を分析することができます。
取得元
このイベントは、Conga CLMが構築されているSalesforceプラットフォーム内の
取得
主要な契約オブジェクトの作成イベントを追跡します。
イベントタイプ
explicit
|
|||
|
法務レビュー実施済み
|
このアクティビティは、法務部門が契約のレビューを完了したことを示します。これは、ワークフロー内の明示的な承認ステップとして捕捉されるか、または『法務レビュー完了』のようなステータス変更から推測することができます。 | ||
|
その重要性
法務レビューフェーズを切り分けることは、一般的なボトルネックを分析するために重要です。これは『平均法務レビュー時間』KPIをサポートし、法務部門のリソース最適化に役立ちます。
取得元
これは、Salesforce承認を使用している場合、承認履歴関連リストに記録できます。あるいは、
取得
ステータスが「法務レビュー完了」に変更されたタイムスタンプ、または法務キューからの最終承認ステップをキャプチャします。
イベントタイプ
inferred
|
|||
|
コンプライアンスレビュー実施済み
|
契約が有効化された後、コンプライアンス要件または規制に対してレビューされる活動です。これは、関連するタスクまたはチェックリスト項目が完了とマークされたときにキャプチャされる場合があります。 | ||
|
その重要性
このアクティビティは、ガバナンスとリスク管理の監視に不可欠です。これらのチェックがいつ、どのように行われるかを追跡することにより、『コンプライアンスレビュー遵守率』KPIをサポートします。
取得元
契約にリンクされた関連する
取得
定期的なタスクまたは関連するコンプライアンスレコードの完了日をキャプチャします。
イベントタイプ
inferred
|
|||
|
修正条項要求済み
|
既存の有効な契約を正式に変更するプロセス開始を示します。これは通常、元の契約に関連する新しい「修正条項」レコードの作成によってキャプチャされます。 | ||
|
その重要性
修正条項は、重要なプロセス上の差異を示します。その頻度とサイクルタイムを分析することで、当初の契約範囲設定の問題や変化するビジネスニーズを明らかにすることができます。
取得元
主要な契約オブジェクトへのルックアップ関係を持つ「修正条項」または同様の名前のオブジェクト上の新規レコードの作成日からキャプチャされます。
取得
契約に関連付けられた「修正」レコードの作成イベントを追跡します。
イベントタイプ
explicit
|
|||
|
内部レビュー開始
|
起草された契約が、財務や事業部門マネージャーなどの社内関係者によるレビューのために提出された時点を示します。これは通常、『内部レビュー中』などのステータス変更から推測されます。 | ||
|
その重要性
このアクティビティは、内部レビューサイクルタイムを測定するための出発点です。契約がレビューを待つ時間と、レビュープロセス自体にどれだけの時間がかかるかを特定するのに役立ちます。
取得元
契約オブジェクトのステータス履歴フィールドから推測されます。ステータスが内部レビューフェーズの開始を示すように変更されたときにイベントにタイムスタンプが付けられます。
取得
契約ステータスが「内部レビュー中」または同等の値に変更されたタイムスタンプをキャプチャします。
イベントタイプ
inferred
|
|||
|
取引先からの承認受領済み
|
外部当事者が条件に同意し、署名する準備ができたことを示します。これはしばしば手動で更新されるステータスであり、使用されている場合はポータルからキャプチャすることも可能です。 | ||
|
その重要性
これは、アクティブな交渉フェーズの終了を示します。『平均交渉サイクルタイム』を測定し、契約がいつ実行されるかを予測するための重要なイベントです。
取得元
契約オブジェクトのステータス変更、例えば『署名待ち』への移行から推測される可能性が高いです。これは契約の所有者によって手動で更新されます。
取得
ステータスが「取引先による承認済み」または「署名待ち」に変更されたタイムスタンプをキャプチャします。
イベントタイプ
inferred
|
|||
|
取引先へ契約書送付済み
|
契約文書を外部関係者にレビューと交渉のために送付するという明示的なアクションを表します。Conga CLMは多くの場合、『交渉のために送付』という特定のログ記録されるアクションを提供します。 | ||
|
その重要性
このアクティビティは、内部プロセスから外部交渉への移行を示します。これは、交渉サイクルタイムを測定するための出発点です。
取得元
通常、契約に関連付けられたログに記録されたアクティビティまたはタスクレコードとしてキャプチャされ、多くの場合、システムアクションによって自動的に作成されます。
取得
「交渉のために送信」または「取引先に送信」イベントログを特定します。
イベントタイプ
explicit
|
|||
|
契約更新済み
|
契約の成功裏の更新、つまりそのライフサイクルの延長を表します。これは、元の契約のステータス変更、または更新として指定された新しい契約レコードの作成によって捕捉されます。 | ||
|
その重要性
更新を追跡することは、収益維持と事業継続に不可欠であり、「適時更新率」KPIをサポートします。これは、契約ライフサイクルにおける肯定的な結果を示します。
取得元
ステータスが「更新済み」に変更されたことから推測できます。あるいは、新しい契約レコードが作成され、「更新元」フィールドが古い契約を指している場合も考えられます。
取得
ステータスが「更新済み」に変更されたこと、または新しいリンクされた契約レコードの作成を特定します。
イベントタイプ
inferred
|
|||
|
契約書作成済み
|
初期契約文書の作成完了を表します。これは多くの場合、契約レコードのステータス変更、例えば『依頼済み』から『作成中』または『レビュー中』への変更から推測されます。 | ||
|
その重要性
このアクティビティを追跡することで、初期ドラフト作成に費やされた時間を測定できます。ここでの遅延は、テンプレート、データ収集、またはリソース配分に関する問題を示している可能性があります。
取得元
契約オブジェクトのステータス項目履歴から推測されます。ステータスが「内部レビュー」のような下書き後の値に変更されたタイムスタンプを探します。
取得
ステータスが「下書き」からワークフローの次の論理的な状態に変更されたことを特定します。
イベントタイプ
inferred
|
|||
|
契約書赤字修正/改訂済み
|
このアクティビティは、交渉中に契約文書の新しいバージョンがチェックインまたはアップロードされるたびに発生します。Conga CLMのバージョン管理機能は、各ドキュメントバージョンについてレコードを作成します。 | ||
|
その重要性
修正の頻度を追跡することで、交渉の強度を定量化し、「修正回数」KPIをサポートします。これは、過度に複雑な契約や困難な交渉を浮き彫りにする可能性があります。
取得元
Conga CLMに保存されている契約文書のバージョン履歴からキャプチャされます。取引先に送信後に作成された各新しいバージョンは、別個のイベントです。
取得
メジャーバージョン番号の変更を伴う新しいドキュメントバージョンが作成されるたびに、イベントを記録します。
イベントタイプ
explicit
|
|||