お客様の契約管理データテンプレート

Conga CLM
お客様の契約管理データテンプレート

お客様の契約管理データテンプレート

このテンプレートは、契約管理プロセスを最適化するために必要な重要なデータを収集するための明確なロードマップを提供します。これにより、主要な属性、追跡すべき重要なアクティビティを概説し、データ抽出に役立つガイダンスが含まれています。これらの推奨事項に従うことで、包括的なプロセス分析のためにデータを効率的に準備し、貴重なインサイトを発見できます。
  • 収集を推奨する項目
  • 追跡すべき主要アクティビティ
  • 抽出の手引き
イベントログについて初めての方へ: プロセスマイニングのイベントログ作成方法.

契約管理属性

これらは、包括的な契約管理分析と主要業績評価指標の特定に不可欠な、イベントログ用の推奨データフィールドです。
5 必須 6 推奨 9 任意
名前 説明
アクティビティ名
ActivityName
契約ライフサイクルで発生した特定のビジネスイベントまたはタスクの名称。
説明

Activity Nameは、『契約書作成済み』、『法務レビュー実施済み』、『契約実行/署名済み』など、契約管理プロセス内のステップまたはマイルストーンを記述します。この属性はプロセスマップを構築するために使用され、実行されたアクションのシーケンスを示します。

この属性の分析により、プロセスフローが明らかになり、一般的および代替パスが特定され、各アクティビティの頻度を測定するのに役立ちます。これは、プロセス適合性、リワーク、および異なるステージ間のサイクルタイムに関連するKPIを計算するための基本です。

その重要性

プロセスのステップを定義し、プロセスマップの基盤を形成することで、ワークフロー、逸脱、アクティビティ頻度の分析を可能にします。

取得元

これは多くの場合、Conga CLMのContractオブジェクトに対して記録されたステータス変更、完了したタスク、または特定のイベントをマッピングすることによって導出されます。

契約書作成済み法務レビュー実施済み契約実行済み/署名済み契約更新済み
イベントのタイムスタンプ
EventTimestamp
アクティビティが開始または発生した正確な日時。
説明

Event Timestampは、特定のアクティビティが発生した瞬間を記録します。これは、各契約のプロセスフローを再構築するために必要な時系列順序を提供します。タイムスタンプは、すべての時間ベースのプロセスマイニング分析に不可欠です。

この属性は、アクティビティ間の期間、全体のケースサイクルタイム、および待機時間を計算するために使用されます。ボトルネックの特定、SLAコンプライアンスの監視、および契約管理プロセスの時間的ダイナミクスの理解に不可欠です。ケース内のイベントの主要なソートキーとして機能します。

その重要性

イベントの時系列を提供し、所要時間系の指標計算、ボトルネックの発見、プロセスパフォーマンスの把握に不可欠です。

取得元

このデータは通常、関連するタスクまたはイベントオブジェクト上の『CreatedDate』のような履歴追跡フィールド、またはメインのContractオブジェクト上の特定の期日フィールドに見られます。

2023-04-15T10:05:00Z2023-05-20T14:30:00Z2023-06-01T09:00:00Z
契約ID
ContractId
各契約合意のユニークな識別子であり、主要なケース識別子として機能します。
説明

Contract IDは、単一の契約のライフサイクルに関連するすべてのイベントとアクティビティをリンクする決定的なケース識別子です。これにより、契約の初期要求から起草、交渉、実行、そして最終的な終了または更新までのエンドツーエンドの追跡が可能になります。

プロセスマイニング分析では、各契約のジャーニーを再構築するために、すべてのイベントがContract IDに関連付けられている必要があります。これにより、プロセス全体の包括的なビューが可能になり、個々の契約または契約のセグメントのサイクルタイムを分析し、ボトルネックを特定し、適合性を監視することが可能になります。

その重要性

これは、契約の完全なライフサイクルを追跡するための不可欠なキーであり、関連するアクティビティを単一のケースに接続することで、すべてのプロセスマイニング分析を可能にします。

取得元

これは通常、Conga CLMのメインAgreementまたはContractオブジェクトの主キーであり、多くの場合『Apttus_Config2__AgreementId__c』のような名前です。

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
`アクティビティ`が完了した正確な日時です。
説明

Event End Timeは、特定のタスクまたはプロセスステップの完了を示します。Event Timestamp(開始時刻)と組み合わせることで、各アクティビティの処理時間を正確に計算することが可能になります。

この属性はパフォーマンス分析にとって極めて重要であり、各ステップに要する時間を測定することを可能にします。これにより、どの活動が最も時間がかかっているかを特定するのに役立ち、次のイベントの開始時刻を使用するだけの場合と比較して、リソース使用率と効率性のより正確なビューを提供します。

その重要性

アクティビティの処理時間を正確に計算することを可能にし、これは期間ベースのボトルネックを特定し、リソース効率を分析するために不可欠です。

取得元

このタイムスタンプは、メイン契約に関連するタスクまたはアクティビティオブジェクト上の『CompletedDate』または『ActualEndDate』のようなフィールドで見つけることができます。

2023-04-15T18:35:00Z2023-05-21T11:00:00Z2023-06-01T17:45:00Z
契約ステータス
ContractStatus
『ドラフト』、『承認中』、または『実行済み』など、契約の現在のライフサイクルステージ。
説明

契約ステータスは、契約ライフサイクルにおける現在の契約の状態を示します。イベントベースの活動名とは異なり、特定の時点での契約がどこにあるかのスナップショットを提供します。

イベントログが過去の活動のシーケンスを示す一方、ステータスは契約の現在の状況に関するコンテキストを提供します。これは、たとえば、現在有効な契約のみを分析したり、なぜ多くの契約が「承認中」ステータスで停滞しているのかを調査したりする際に役立ちます。活動データを補完し、状態情報を提供します。

その重要性

契約の現在の段階のスナップショットを提供し、アクティブなケースのフィルタリングや分析、プロセス状態の分布を理解するのに役立ちます。

取得元

これはAgreementオブジェクト上の標準的な選択リストフィールドであり、多くの場合『Apttus_Config2__Status__c』または『Apttus_Config2__Status_Category__c』です。

下書き内部レビュー中実行済み期限切れ
契約形態
ContractType
NDA、MSA、またはSOWなど、契約の分類。
説明

契約タイプは、法的目的または性質に基づいて契約を分類するカテゴリ属性です。一般的な例には、秘密保持契約(NDA)、基本契約(MSA)、および作業範囲記述書(SOW)などがあります。

このディメンションは比較分析の基本です。異なる種類の契約が異なるパスをたどるか、または異なるサイクルタイムを持つかをプロセスマップでフィルタリングして確認できます。これは、特定の契約タイプに適したプロセスバリエーションと、真の逸脱であるバリエーションを区別するために不可欠です。

その重要性

プロセスをセグメント化することで、NDAとMSAのような異なる契約カテゴリのワークフロー、サイクルタイム、およびボトルネックを比較することを可能にします。

取得元

これは通常、Agreementオブジェクト上の選択リストまたはルックアップフィールドであり、多くの場合『Apttus_Config2__Contract_Type__c』またはそれに類する名前です。

秘密保持契約(NDA)マスターサービス契約(MSA)作業明細書(SOW)
契約担当者
ContractOwner
契約のライフサイクル全体を管理する責任を負うユーザーまたは従業員。
説明

Contract Ownerは、契約の主要な責任を割り当てられた個人です。この担当者は通常、契約の作成、交渉、および承認プロセスを通じて契約を進める責任を負います。

Contract Ownerごとのプロセスパフォーマンスを分析することで、効率性、標準プロセスへの遵守、およびワークロード配分の変動を明らかにすることができます。これにより、ベストプラクティス、トレーニングニーズ、およびリソース配分の潜在的な不均衡を特定するのに役立ちます。これは、パフォーマンスと生産性分析の主要な側面です。

その重要性

ユーザーごとのパフォーマンス分析を可能にし、優秀な担当者、トレーニング機会、およびワークロード配分の問題を特定するのに役立ちます。

取得元

これはConga CLMのメインAgreementオブジェクト上のユーザー検索フィールドである可能性が高く、多くの場合『OwnerId』またはカスタムの『Contract_Owner__c』フィールドという名前です。

Alice Johnsonロバート・チェンMaria Garcia
契約金額
ContractValue
契約に関連する総金銭的価値。
説明

契約金額は、合意の金銭的価値を表します。これは、総契約額、年間経常収益、またはビジネスコンテキストに応じてその他の主要な財務指標である可能性があります。

この属性の分析は、価値ベースのプロセス最適化にとって重要です。高価値契約の優先順位付けを可能にし、高価値契約がより速く処理されるのか、または特定の段階でより頻繁に停滞するのかといった疑問に答えるのに役立ちます。「契約金額スループット分析」ダッシュボードの鍵となります。

その重要性

これにより、価値ベースの分析が可能になり、高価値契約のプロセス改善を優先し、ビジネスへの影響を理解するのに役立ちます。

取得元

これは通常、Conga CLMのAgreementオブジェクト上の通貨フィールドであり、例えば『Apttus_Config2__Total_Contract_Value__c』です。

500002500001200000
有効期限
ExpirationDate
契約が満了する日付。
説明

Expiration Dateは、契約期間の終了を示す重要な日付フィールドです。これは、契約実行後のライフサイクルを管理するために不可欠です。

この属性は、『今後の更新と満了』ダッシュボードおよび『適時更新率』KPIにとって極めて重要です。この日付を分析することにより、組織は契約の満了をプロアクティブに管理し、タイムリーに更新プロセスを開始し、意図しないサービスや収益の失効を防ぐことができます。

その重要性

この日付は、プロアクティブな契約管理にとって重要であり、今後の満了を追跡するダッシュボードを可能にすることで、更新の見落としや収益損失を防ぎます。

取得元

これはAgreementオブジェクト上の標準的な日付フィールドであり、多くの場合『Apttus_Config2__EndDate__c』です。

2025-12-312026-06-302024-08-15
コンプライアンス状況
ComplianceStatus
契約が必要なコンプライアンスレビューに合格したかどうかを示します。
説明

コンプライアンスステータスは、内部ポリシーまたは外部規制に関する契約の状態を追跡します。「未開始」、「レビュー中」、「合格」、「不合格」などの値を持つことがあります。

この属性は、「コンプライアンスおよび義務監視」ダッシュボードおよび関連するKPIにとって不可欠です。これにより、コンプライアンス遵守状況を直接的に可視化し、すべての契約が実行または有効化される前に必要なチェックを受け、合格することを保証することで、法的および財務的リスクを軽減するのに役立ちます。

その重要性

コンプライアンスプロトコルへの準拠を直接測定し、契約ポートフォリオ内の法的および財務的リスクを特定し、軽減するのに役立ちます。

取得元

これはAgreementオブジェクト上のカスタム選択リストフィールドである可能性が高く、特定のコンプライアンス関連のアクティビティまたは承認によって更新されます。

合格レビューが必要該当なし不合格
ビジネスユニット
BusinessUnit
契約が所属する組織内の特定の事業部門。
説明

Business Unit属性は、契約を『エンタープライズソフトウェア』や『コンシューマーハードウェア』など、会社の特定の部門またはセグメントに割り当てます。これにより、組織の異なる部分における契約管理プロセスのより詳細な分析が可能になります。

Business Unit別に分析することで、異なる部門が独自のプロセスバリアント、パフォーマンスレベル、または契約タイプを持っているかどうかを示すことができます。これは、有効な事業部門固有のニーズに対応しながらプロセスを標準化しようとしている大規模な組織にとって価値があります。

その重要性

組織部門別にプロセスパフォーマンスをセグメント化することを可能にし、企業全体の効率性や手順における変動を浮き彫りにします。

取得元

これは、Agreementオブジェクト上のカスタムフィールドであるか、契約所有者のユーザープロファイルから派生している可能性があります。

北米営業EMEAサービスAPAC製品部門
処理時間
ProcessingTime
アクティビティにアクティブに費やされた時間の計算された期間。
説明

処理時間とは、アクティビティの開始から終了までの経過時間を測定します。これはアクティビティ間の待機時間とは異なり、実際の作業期間を表します。このメトリックはEvent TimestampEvent End Timeを使用して計算されます。

この属性は、プロセス内でどの特定のステップが最も時間のかかるものかを特定するために不可欠です。『レビューフェーズボトルネック』ダッシュボードをサポートし、アクティビティ期間の詳細な分析を可能にします。処理時間と待機時間を区別することは、遅延の根本原因を理解するための鍵となります。

その重要性

各アクティビティのアクティブな作業時間を測定し、非効率なステップ(長い処理時間)とプロセス遅延(長い待機時間)を区別するのに役立ちます。

取得元

これは、EventEndTimeからEventTimestampを引いて導出される計算属性です。Conga CLMには保存されません。

864001728003600
取引先名
CounterpartyName
契約に関与する外部の当事者、企業、または個人の名称。
説明

取引先名は、合意のもう一方の署名者を特定します。これは通常、顧客、ベンダー、またはパートナー組織です。

取引先別にプロセスメトリクスを分析することで、重要なパターンを明らかにできます。たとえば、特定の取引先との交渉が常に長くかかったり、より多くの改訂が必要になったりすることが示される場合があります。この洞察は、交渉戦略を策定し、主要なビジネスパートナーとの関係管理に役立ちます。

その重要性

外部関係者に基づいたプロセス変動の分析を可能にし、どの顧客やベンダーがより長い交渉サイクルや高い改訂率を持つかを特定するのに役立ちます。

取得元

これは多くの場合、SalesforceのAccountオブジェクトへのルックアップであり、Conga CLMのAgreementオブジェクトにリンクされています。

`Global Tech Inc.`Innovate Solutions LLCAcme Corporation
地域
Region
『北米』または『EMEA』など、契約に関連付けられた地理的地域。
説明

Region属性は、相手方の所在地、販売地域、または準拠法に基づいて、契約に関連する地理的地域を示します。

この属性により、契約プロセスの地政学的分析が可能になります。『EMEAでの契約は、異なる規制のため承認に時間がかかりますか?』や『APAC地域での契約は、修正(レッドライニング)率が高いですか?』といった疑問に答えるのに役立ちます。これは、グローバルオペレーションにとって価値のあるコンテキストを提供します。

その重要性

地域別にセグメント化することで、サイクルタイム、コンプライアンス要件、またはプロセスパスにおける地理的変動を特定するのに役立ち、これはグローバルビジネスにとって重要です。

取得元

これは多くの場合、Agreementオブジェクト上のカスタムフィールドであるか、リンクされたAccountまたはUserオブジェクトから派生しています。

北米EMEAAPACLATAM
手戻り
IsRework
活動が手戻りループの一部であるかどうかを示す計算済みのフラグです。
説明

リワークとは、法務レビュー後に『契約書作成済み』段階に戻るなど、プロセスにおける後戻りを表すアクティビティである場合に『true』に設定されるブールフラグです。これはソースシステムには存在せず、プロセスマイニングのためのデータ変換中に計算されます。

このフラグは、プロセスの非効率性を数値化する上で非常に価値があります。『契約リワーク率』KPIを直接サポートし、プロセスマップ内のプロセスループを視覚化するのに役立ちます。リワークの頻度と原因を特定することは、多くのプロセス改善イニシアチブの主要な目標です。

その重要性

この計算されたフラグにより、無駄なリワークループの一部であるアクティビティを強調表示することで、プロセスの非効率性を定量化し、分析することが容易になります。

取得元

この属性はソースシステムにはありません。アクティビティのシーケンスに基づいて、プロセスマイニングツールまたはETL層で計算されます。

truefalse
承認サイクルタイム
ApprovalCycleTime
契約が承認フェーズで費やす合計時間。
説明

承認サイクルタイムは、契約が「内部レビュー開始」などの承認プロセスに入ってから、最終的な内部承認を受けるまでの期間を測定する計算済み指標です。これは、すべての関連する承認ステップにわたる時間を集計します。

この属性は、「契約承認サイクルタイム」ダッシュボードおよび「平均契約承認時間」KPIの主要な測定値です。承認ワークフロー全体の効率性を高レベルで把握でき、目標に対するパフォーマンス追跡やシステム的な遅延の特定を容易にします。

その重要性

このKPIは、承認ワークフローの効率を直接測定し、契約ライフサイクルの重要なフェーズにおける遅延を特定し、対処するのに役立ちます。

取得元

これは、各契約の最初の承認アクティビティと最終承認アクティビティ間の時間差を見つけることによって導出される計算メトリックです。

259200604800432000
担当部門
OwnerDepartment
『営業』、『法務』、または『調達』など、契約の所有者の部門。
説明

Owner Department属性は、契約の所有者が所属するビジネス機能を指定します。この情報は通常、システム内のユーザープロファイルから派生します。

これは分析のための強力な側面であり、異なる部門間でのプロセスパフォーマンスの比較を可能にします。法務部門がボトルネックになっているか、営業チームが異なるプロセスに従っているか、または特定の部門が著しく長いサイクルタイムを持っているかを特定するのに役立ちます。このインサイトは、部門横断的なプロセス改善イニシアチブにとって価値があります。

その重要性

ビジネス機能ごとのプロセス分析を可能にし、営業部門と法務部門のような部署間のパフォーマンス差異やボトルネックを明らかにします。

取得元

このデータは通常、SalesforceのUserオブジェクトから取得され、Agreementオブジェクト上のContract Ownerフィールドを介してリンクされます。

営業法務調達財務
更新日
RenewalDate
契約の更新プロセスを開始するための目標日。
説明

Renewal Dateは、契約の更新プロセスを開始すべき時期を示す、計算または手動で設定された日付です。これは通常、Expiration Dateの90日前など、ある期間前に設定されます。

この属性は、チームが更新パイプラインを効果的に管理するのに役立ちます。契約更新に関連するアラートをトリガーし、タスクを自動化するために使用でき、プロセスが十分なリードタイムで開始されることを保証します。これは、『適時更新率』KPIの重要な要素です。

その重要性

更新活動のトリガーポイントを提供し、契約が期日通りに更新されることを確実にするのに役立ち、プロアクティブなライフサイクル管理をサポートします。

取得元

これは、Expiration Dateに基づいたカスタム数式フィールドであるか、Conga CLMのAgreementオブジェクト上の別の日付フィールドである可能性があります。

2025-10-022026-04-012024-05-17
必須 推奨 任意

契約管理活動

正確なプロセス発見とボトルネック特定のため、イベントログに記録すべき主要ステップとマイルストーンは次のとおりです。
7 推奨 8 任意
アクティビティ 説明
内部承認取得済み
このマイルストーンは、契約が必要なすべての内部承認を受け、実行準備が整ったことを示します。これは通常、多段階のSalesforce承認プロセスの最終ステップです。
その重要性

これは、内部レビューと承認サイクルを締めくくる重要なマイルストーンです。『平均契約承認時間』KPIを測定するための終点となります。

取得元

契約オブジェクト上のSalesforce承認履歴関連リストからキャプチャされます。イベントは、プロセスにおける最終的な「承認済み」ステータスのタイムスタンプです。

取得

関連する承認プロセスにおける最終承認ステップのタイムスタンプをキャプチャします。

イベントタイプ explicit
契約実行済み/署名済み
これは、すべての当事者が法的に契約に署名し、拘束力のある合意となる極めて重要なアクティビティです。Conga CLMと統合された電子署名ソリューション(Conga Signなど)は、明示的なタイムスタンプ付きイベントを作成します。
その重要性

このアクティビティは、署名前プロセスの成功裏の完了を表し、『契約実行率』のようなパフォーマンスメトリックにとって重要なマイルストーンです。これはしばしば、主要な『ハッピーパス』終了イベントと見なされます。

取得元

統合された電子署名ツールの監査証跡またはステータスからキャプチャされます。最終的な「完了」または「署名済み」ステータスが正確なタイムスタンプと共に記録されます。

取得

統合された電子署名サービスAPIまたはステータスオブジェクトから完了イベントを記録します。

イベントタイプ explicit
契約書有効化済み
契約が組織内で有効かつ運用可能となり、義務と権利が発動されることを表します。これは通常、『実行済み』から『有効』へのステータス変更から推測されます。
その重要性

このアクティビティは、署名後のライフサイクルの始まりを示します。これは、義務管理とパフォーマンス監視のトリガーとなります。

取得元

契約オブジェクトのステータス項目履歴から推測されます。イベントは、ステータスが「有効」または同等の用語に変更されたタイムスタンプです。

取得

ステータスが「実行済み」から「有効」に変更されたタイムスタンプを特定します。

イベントタイプ inferred
契約期限切れ
契約が更新または終了されることなく、有効期限に達した際の自然な契約ライフサイクルの終了を表します。このイベントは明示的に記録されず、契約データから派生します。
その重要性

このアクティビティは、契約ライフサイクルの計画された終了を定義します。満了した契約を分析することは、更新機会と全体的な契約ポートフォリオ管理を理解するのに役立ちます。

取得元

これは計算されたイベントです。アクティビティは、システムの日付がContractオブジェクト上の『契約終了日』または『有効期限』フィールドを超過し、そのステータスがまだ『有効』である場合に発生します。

取得

「契約終了日」フィールドを現在の日付と比較して導出します。

イベントタイプ calculated
契約終了
このアクティビティは、特定の行動に基づいて、契約が有効期限前に早期終了することを示します。これは、契約のステータスが『終了済み』に変更されることで捕捉されます。
その重要性

主要な最終状態として、終了イベントは契約不履行率やキャンセル理由を理解する上で重要です。これにより、しばしば否定的ではありますが、プロセスに対する明確な結論が提供されます。

取得元

契約オブジェクトのステータス項目履歴から推測されます。イベントは、ステータスが「終了」または「キャンセル済み」に更新されたタイムスタンプです。

取得

ステータスが「終了」に変更されたタイムスタンプをキャプチャします。

イベントタイプ inferred
契約要求開始
このアクティビティは、契約ライフサイクルの正式な開始を示し、システム内に新しい契約レコードが作成されることを表します。これは通常、ユーザーがConga CLMで新しい`Contract`オブジェクトを作成した際の明示的なイベントとして捕捉されます。
その重要性

すべての契約の開始点として、この活動はエンドツーエンドのサイクルタイムを測定する上で不可欠です。開始されている契約の量と種類を分析することができます。

取得元

このイベントは、Conga CLMが構築されているSalesforceプラットフォーム内のContractレコードの作成日とタイムスタンプから捕捉されます。レコードを作成したユーザーも通常記録されます。

取得

主要な契約オブジェクトの作成イベントを追跡します。

イベントタイプ explicit
法務レビュー実施済み
このアクティビティは、法務部門が契約のレビューを完了したことを示します。これは、ワークフロー内の明示的な承認ステップとして捕捉されるか、または『法務レビュー完了』のようなステータス変更から推測することができます。
その重要性

法務レビューフェーズを切り分けることは、一般的なボトルネックを分析するために重要です。これは『平均法務レビュー時間』KPIをサポートし、法務部門のリソース最適化に役立ちます。

取得元

これは、Salesforce承認を使用している場合、承認履歴関連リストに記録できます。あるいは、Contractオブジェクトのステータス変更から推測することも可能です。

取得

ステータスが「法務レビュー完了」に変更されたタイムスタンプ、または法務キューからの最終承認ステップをキャプチャします。

イベントタイプ inferred
コンプライアンスレビュー実施済み
契約が有効化された後、コンプライアンス要件または規制に対してレビューされる活動です。これは、関連するタスクまたはチェックリスト項目が完了とマークされたときにキャプチャされる場合があります。
その重要性

このアクティビティは、ガバナンスとリスク管理の監視に不可欠です。これらのチェックがいつ、どのように行われるかを追跡することにより、『コンプライアンスレビュー遵守率』KPIをサポートします。

取得元

契約にリンクされた関連するTaskまたはカスタムのCompliance Reviewオブジェクトの完了から推測される可能性が高いです。このレコードの完了日がイベントのタイムスタンプとして機能します。

取得

定期的なタスクまたは関連するコンプライアンスレコードの完了日をキャプチャします。

イベントタイプ inferred
修正条項要求済み
既存の有効な契約を正式に変更するプロセス開始を示します。これは通常、元の契約に関連する新しい「修正条項」レコードの作成によってキャプチャされます。
その重要性

修正条項は、重要なプロセス上の差異を示します。その頻度とサイクルタイムを分析することで、当初の契約範囲設定の問題や変化するビジネスニーズを明らかにすることができます。

取得元

主要な契約オブジェクトへのルックアップ関係を持つ「修正条項」または同様の名前のオブジェクト上の新規レコードの作成日からキャプチャされます。

取得

契約に関連付けられた「修正」レコードの作成イベントを追跡します。

イベントタイプ explicit
内部レビュー開始
起草された契約が、財務や事業部門マネージャーなどの社内関係者によるレビューのために提出された時点を示します。これは通常、『内部レビュー中』などのステータス変更から推測されます。
その重要性

このアクティビティは、内部レビューサイクルタイムを測定するための出発点です。契約がレビューを待つ時間と、レビュープロセス自体にどれだけの時間がかかるかを特定するのに役立ちます。

取得元

契約オブジェクトのステータス履歴フィールドから推測されます。ステータスが内部レビューフェーズの開始を示すように変更されたときにイベントにタイムスタンプが付けられます。

取得

契約ステータスが「内部レビュー中」または同等の値に変更されたタイムスタンプをキャプチャします。

イベントタイプ inferred
取引先からの承認受領済み
外部当事者が条件に同意し、署名する準備ができたことを示します。これはしばしば手動で更新されるステータスであり、使用されている場合はポータルからキャプチャすることも可能です。
その重要性

これは、アクティブな交渉フェーズの終了を示します。『平均交渉サイクルタイム』を測定し、契約がいつ実行されるかを予測するための重要なイベントです。

取得元

契約オブジェクトのステータス変更、例えば『署名待ち』への移行から推測される可能性が高いです。これは契約の所有者によって手動で更新されます。

取得

ステータスが「取引先による承認済み」または「署名待ち」に変更されたタイムスタンプをキャプチャします。

イベントタイプ inferred
取引先へ契約書送付済み
契約文書を外部関係者にレビューと交渉のために送付するという明示的なアクションを表します。Conga CLMは多くの場合、『交渉のために送付』という特定のログ記録されるアクションを提供します。
その重要性

このアクティビティは、内部プロセスから外部交渉への移行を示します。これは、交渉サイクルタイムを測定するための出発点です。

取得元

通常、契約に関連付けられたログに記録されたアクティビティまたはタスクレコードとしてキャプチャされ、多くの場合、システムアクションによって自動的に作成されます。

取得

「交渉のために送信」または「取引先に送信」イベントログを特定します。

イベントタイプ explicit
契約更新済み
契約の成功裏の更新、つまりそのライフサイクルの延長を表します。これは、元の契約のステータス変更、または更新として指定された新しい契約レコードの作成によって捕捉されます。
その重要性

更新を追跡することは、収益維持と事業継続に不可欠であり、「適時更新率」KPIをサポートします。これは、契約ライフサイクルにおける肯定的な結果を示します。

取得元

ステータスが「更新済み」に変更されたことから推測できます。あるいは、新しい契約レコードが作成され、「更新元」フィールドが古い契約を指している場合も考えられます。

取得

ステータスが「更新済み」に変更されたこと、または新しいリンクされた契約レコードの作成を特定します。

イベントタイプ inferred
契約書作成済み
初期契約文書の作成完了を表します。これは多くの場合、契約レコードのステータス変更、例えば『依頼済み』から『作成中』または『レビュー中』への変更から推測されます。
その重要性

このアクティビティを追跡することで、初期ドラフト作成に費やされた時間を測定できます。ここでの遅延は、テンプレート、データ収集、またはリソース配分に関する問題を示している可能性があります。

取得元

契約オブジェクトのステータス項目履歴から推測されます。ステータスが「内部レビュー」のような下書き後の値に変更されたタイムスタンプを探します。

取得

ステータスが「下書き」からワークフローの次の論理的な状態に変更されたことを特定します。

イベントタイプ inferred
契約書赤字修正/改訂済み
このアクティビティは、交渉中に契約文書の新しいバージョンがチェックインまたはアップロードされるたびに発生します。Conga CLMのバージョン管理機能は、各ドキュメントバージョンについてレコードを作成します。
その重要性

修正の頻度を追跡することで、交渉の強度を定量化し、「修正回数」KPIをサポートします。これは、過度に複雑な契約や困難な交渉を浮き彫りにする可能性があります。

取得元

Conga CLMに保存されている契約文書のバージョン履歴からキャプチャされます。取引先に送信後に作成された各新しいバージョンは、別個のイベントです。

取得

メジャーバージョン番号の変更を伴う新しいドキュメントバージョンが作成されるたびに、イベントを記録します。

イベントタイプ explicit
推奨 任意

抽出ガイド

Conga CLMからデータを取得する方法