契約管理データテンプレート
契約管理データテンプレート
- 収集を推奨する属性
- 追跡すべき主要なアクティビティ
- 抽出ガイド
契約管理の属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ名
ActivityName
|
契約ライフサイクルで発生した特定のビジネスイベントまたはTaskの名前です。 | ||
|
説明
Activity Nameは、「Contract Drafted」、「Legal Review Conducted」、「Contract Executed/Signed」など、契約管理プロセス内のステップまたはマイルストーンを表します。この属性を使ってプロセスマップを作成し、実行されたアクションの順序を示します。 この属性を分析すると、プロセスフローや一般的な経路、代替経路が明らかになり、各アクティビティの頻度を測定できます。また、プロセス適合性、手戻り、各ステージ間のサイクルタイムに関するKPIの算出にも欠かせません。
重要な理由
プロセスのステップを定義し、プロセスマップの基盤を形成します。ワークフロー、逸脱、アクティビティ頻度の分析が可能になります。
入手先
通常は、Conga CLMのContractオブジェクトに記録されたステータス変更、完了したTask、または特定のイベントをマッピングして導出します。
例
契約書を作成法務レビューを実施契約を締結・署名契約更新完了
|
|||
|
イベントタイムスタンプ
EventTimestamp
|
アクティビティが開始または発生した正確な日時です。 | ||
|
説明
Event Timestampは、特定のアクティビティが実行された時点を記録します。契約ごとのプロセスフローを再構築するために必要な時系列を提供します。タイムスタンプは、時間に基づくすべてのプロセスマイニング分析に欠かせません。 この属性を使って、アクティビティ間の所要時間、ケース全体のサイクルタイム、待ち時間を算出します。ボトルネックの特定、SLAコンプライアンスの監視、契約管理プロセスの時間的な動きを理解するうえで重要です。ケース内のイベントを並べ替える際の主キーとして機能します。
重要な理由
イベントの時系列を提供します。これは、所要時間に基づく各種指標の算出、ボトルネックの発見、プロセスパフォーマンスの把握に欠かせません。
入手先
通常は、関連するTaskまたはイベントオブジェクトの「CreatedDate」などの履歴追跡フィールド、または主Contractオブジェクトの特定の日付フィールドに記録されています。
例
2023-04-15T10:05:00Z2023-05-20T14:30:00Z2023-06-01T09:00:00Z
|
|||
|
契約ID
ContractId
|
各契約合意を一意に識別するIDであり、主たるケース識別子として機能します。 | ||
|
説明
Contract IDは、1件の契約ライフサイクルに関連するすべてのイベントとアクティビティを結び付ける、確定的なケース識別子です。初回の依頼からドラフト作成、交渉、締結、最終的な終了または更新まで、契約をエンドツーエンドで追跡できます。 プロセスマイニング分析では、各契約の経過を再構築するため、すべてのイベントにContract IDを関連付ける必要があります。これにより、プロセス全体を把握でき、個々の契約または契約セグメントのサイクルタイム分析、ボトルネックの特定、適合性の監視が可能になります。
重要な理由
契約のライフサイクル全体を追跡するための基本キーです。関連するアクティビティを1つのケースに結び付け、すべてのプロセスマイニング分析を可能にします。
入手先
通常は、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は、特定のTaskまたはプロセスステップが完了した時点を示します。Event Timestamp(開始時刻)と組み合わせることで、各アクティビティの処理時間を正確に算出できます。 この属性はパフォーマンス分析に欠かせず、各ステップにかかる時間を測定できます。時間のかかるアクティビティを特定し、次のイベントの開始時刻だけを使う場合よりも、リソースの利用状況と効率を正確に把握できます。
重要な理由
アクティビティの処理時間を正確に算出できます。所要時間に基づくボトルネックの特定や、リソース効率の分析に欠かせません。
入手先
通常は、主契約に関連するTaskまたはアクティビティオブジェクトの「CompletedDate」や「ActualEndDate」などのフィールドに記録されています。
例
2023-04-15T18:35:00Z2023-05-21T11:00:00Z2023-06-01T17:45:00Z
|
|||
|
契約ステータス
ContractStatus
|
「Draft」、「In Approval」、「Executed」など、契約の現在のライフサイクル段階です。 | ||
|
説明
Contract Statusは、ライフサイクルにおける契約の現在の状態を示します。イベントベースのアクティビティ名とは異なり、任意の時点で契約がどの段階にあるかを把握できます。 イベントログが過去のアクティビティの順序を示すのに対し、ステータスは契約の現在の状態に関する背景情報を提供します。現在有効な契約だけを分析したり、多くの契約が「In Approval」ステータスで滞留している理由を調査したりする際に役立ちます。アクティビティデータを補完する状態情報です。
重要な理由
契約の現在の段階を示すスナップショットです。有効なケースの絞り込みや分析、プロセス状態の分布把握に役立ちます。
入手先
Agreementオブジェクトの標準選択リストフィールドで、「Apttus_Config2__Status__c」または「Apttus_Config2__Status_Category__c」であることがよくあります。
例
草案社内レビュー中締結済み期限切れ
|
|||
|
契約担当者
ContractOwner
|
契約のライフサイクル全体を管理する責任を負う利用者または従業員です。 | ||
|
説明
Contract Ownerは、契約に対する主な責任を割り当てられた担当者です。通常は、ドラフト作成や交渉を担当し、承認プロセスを通じて契約が進むよう管理します。 Contract Owner別にプロセスパフォーマンスを分析すると、効率、標準プロセスの遵守、業務量の分布における違いを明らかにできます。ベストプラクティス、トレーニングの必要性、リソース配分の偏りを特定するのに役立ちます。パフォーマンスと生産性を分析するための重要な軸です。
重要な理由
利用者別のパフォーマンス分析が可能になり、高い成果を上げている担当者、トレーニング機会、業務量の偏りを特定できます。
入手先
Conga CLMの主Agreementオブジェクトにあるユーザールックアップフィールドと考えられます。「OwnerId」またはカスタム「Contract_Owner__c」フィールドであることがよくあります。
例
Alice JohnsonRobert ChenMaria Garcia
|
|||
|
契約種別
ContractType
|
NDA、MSA、SOWなど、契約の分類です。 | ||
|
説明
Contract Typeは、法的な目的や性質に基づいて契約を分類する属性です。一般的な例として、秘密保持契約(NDA)、基本サービス契約(MSA)、作業範囲記述書(SOW)があります。 この軸は比較分析に欠かせません。プロセスマップを絞り込み、契約種別によって異なる経路やサイクルタイムがあるかを確認できます。特定の契約種別に適したプロセス上の違いと、真の逸脱を区別するうえで重要です。
重要な理由
プロセスを分割し、NDAとMSAなど異なる契約カテゴリのワークフロー、サイクルタイム、ボトルネックを比較できます。
入手先
通常はAgreementオブジェクトの選択リストまたはルックアップフィールドで、「Apttus_Config2__Contract_Type__c」などの名前が付けられています。
例
秘密保持契約(NDA)基本サービス契約(MSA)作業範囲記述書(SOW)
|
|||
|
契約金額
ContractValue
|
契約に関連する金銭的価値の合計です。 | ||
|
説明
Contract Valueは、合意の金銭的価値を表します。ビジネスの状況に応じて、契約総額、年間経常収益、その他の主要な財務指標を指します。 この属性を分析することは、価値に基づくプロセス改善に欠かせません。高額契約を優先し、高額契約がより速く処理されるか、特定のステージで滞留しやすいかを確認できます。「契約金額スループット分析」ダッシュボードの主要な指標です。
重要な理由
価値に基づく分析が可能になり、高額契約のプロセス改善を優先し、事業への影響を把握できます。
入手先
通常は、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
|
契約が必要なコンプライアンスレビューに合格したかどうかを示します。 | ||
|
説明
Compliance Statusは、社内ポリシーまたは外部規制に照らした契約の状態を追跡します。「Not Started」、「In Review」、「Passed」、「Failed」などの値が設定されます。 「コンプライアンス・義務モニタリング」ダッシュボードと関連KPIに欠かせない属性です。コンプライアンス遵守状況を直接確認でき、すべての契約が締結または有効化の前に必要なチェックを受け、合格していることを確認することで、法的・財務的リスクの低減に役立ちます。
重要な理由
コンプライアンス手順の遵守状況を直接測定し、契約ポートフォリオにおける法的・財務的リスクの特定と低減に役立ちます。
入手先
Agreementオブジェクトのカスタム選択リストフィールドで、コンプライアンス関連の特定のアクティビティや承認によって更新されると考えられます。
例
合格要レビュー該当なし不合格
|
|||
|
事業部門
BusinessUnit
|
契約が属する組織内の特定の事業部門です。 | ||
|
説明
Business Unitは、契約を「Enterprise Software」や「Consumer Hardware」など、企業の特定の部門または事業セグメントに割り当てます。これにより、組織内の各領域で契約管理プロセスをより細かく分析できます。 Business Unit別に分析すると、部門ごとに異なるプロセスのバリエーション、パフォーマンス、契約種別があるかを確認できます。大規模な組織がプロセスを標準化しながら、事業部門固有の正当なニーズにも対応するうえで役立ちます。
重要な理由
組織内の部門別にプロセスパフォーマンスを分けて分析でき、企業全体における効率や手順の違いを明らかにします。
入手先
Agreementオブジェクトのカスタムフィールド、または契約担当者のユーザープロファイルから導出される可能性があります。
例
北米営業EMEAサービスAPAC製品部門
|
|||
|
地域
Region
|
契約に関連する地理的地域です。「North America」や「EMEA」などが該当します。 | ||
|
説明
Regionは、契約に関係する地理的地域を示します。相手方の所在地、営業地域、準拠法などに基づく場合があります。 この属性により、契約プロセスを地理的な観点から分析できます。「異なる規制のため、EMEAの契約は承認に時間がかかるか」「APAC地域の契約では変更履歴の付与率が高いか」といった問いに答えられます。グローバルな業務を理解するための重要な背景情報です。
重要な理由
地域別に分けて分析することで、サイクルタイム、コンプライアンス要件、プロセス経路における地理的な違いを特定できます。グローバル企業に欠かせない分析です。
入手先
Agreementオブジェクトのカスタムフィールド、またはリンクされたAccountオブジェクトやUserオブジェクトから導出されることがよくあります。
例
北米EMEAAPACLATAM
|
|||
|
手戻りかどうか
IsRework
|
アクティビティが手戻りループの一部かどうかを示す計算フラグです。 | ||
|
説明
Is Reworkは、アクティビティがプロセスの後戻りを表す場合に「true」に設定されるブール型フラグです。たとえば、法務レビュー後に「Contract Drafted」ステージへ戻るケースが該当します。ソースシステムのフィールドではなく、プロセスマイニング用のデータ変換時に計算されます。 このフラグは、プロセスの非効率を定量化するうえで非常に役立ちます。「契約手戻り率」KPIを直接支援し、プロセスマップ上のループを可視化できます。手戻りの頻度と原因の特定は、多くのプロセス改善施策における主要な目的です。
重要な理由
この計算フラグにより、非効率な手戻りループに含まれるアクティビティを明らかにし、プロセスの非効率を簡単に定量化・分析できます。
入手先
この属性はソースシステムにはありません。アクティビティの順序に基づき、プロセスマイニングツールまたはETLレイヤーで計算されます。
例
truefalse
|
|||
|
承認サイクルタイム
ApprovalCycleTime
|
契約が承認フェーズに費やす合計時間です。 | ||
|
説明
Approval Cycle Timeは、契約が承認プロセスに入った時点、たとえば「Internal Review Started」から、最終的な社内承認を受けるまでの期間を測定する計算指標です。関連するすべての承認ステップの時間を集計します。 「契約承認サイクルタイム」ダッシュボードと「平均契約承認時間」KPIの主要指標です。承認ワークフロー全体の効率を把握し、目標に対するパフォーマンスの追跡や、全体的な遅延の特定を容易にします。
重要な理由
このKPIは承認ワークフローの効率を直接測定し、契約ライフサイクルの重要なフェーズにおける遅延の特定と解消に役立ちます。
入手先
計算指標です。各契約について、最初の承認アクティビティと最終承認アクティビティの時間差を求めて算出します。
例
259200604800432000
|
|||
|
担当者所属部門
OwnerDepartment
|
契約担当者が所属する部門です。「Sales」、「Legal」、「Procurement」などが該当します。 | ||
|
説明
Owner Departmentは、契約担当者が所属する業務機能を示します。通常は、システム上のユーザープロファイルから取得されます。 この属性は分析に有効な軸であり、部門間のプロセスパフォーマンスを比較できます。Legal部門がボトルネックになっているか、Salesチームが異なるプロセスに従っているか、特定の部門のサイクルタイムが大幅に長いかを確認できます。部門横断のプロセス改善に役立つ情報です。
重要な理由
業務機能別にプロセスを分析でき、SalesやLegalなどの部門間におけるパフォーマンスの違いやボトルネックを明らかにします。
入手先
通常はSalesforceのUserオブジェクトから取得され、AgreementオブジェクトのContract Ownerフィールドを介してリンクされます。
例
営業法務調達財務
|
|||
|
更新開始日
RenewalDate
|
契約の更新プロセスを開始する目標日です。 | ||
|
説明
Renewal Dateは、契約の更新プロセスを開始すべき時期を示す、計算または手動設定の日付です。通常は、満了日の一定期間前、たとえば90日前に設定されます。 この属性により、チームは更新パイプラインを効果的に管理できます。アラートの発信や契約更新に関するTaskの自動化に利用でき、十分な準備期間を確保してプロセスを開始できます。「適時更新率」KPIの重要な要素です。
重要な理由
更新アクティビティを開始する基準点となり、契約を期限内に更新し、ライフサイクルを先回りして管理できるようにします。
入手先
Expiration Dateに基づくカスタム数式フィールド、またはConga CLMのAgreementオブジェクトにある別の日付フィールドと考えられます。
例
2025-10-022026-04-012024-05-17
|
|||
|
相手方名
CounterpartyName
|
契約に関与する外部の当事者、企業、または個人の名前です。 | ||
|
説明
Counterparty Nameは、合意書におけるもう一方の署名者を識別します。通常は顧客、ベンダー、またはパートナー組織です。 相手方別にプロセス指標を分析すると、重要な傾向を明らかにできます。たとえば、特定の相手方との交渉に一貫して時間がかかる、または改訂回数が多いことが分かる場合があります。この情報は、交渉戦略の策定や主要なビジネスパートナーとの関係管理に役立ちます。
重要な理由
外部の相手方によるプロセスの違いを分析できます。交渉サイクルが長い顧客やベンダー、改訂率が高い相手方を特定できます。
入手先
SalesforceのAccountオブジェクトへのルックアップであることが多く、Conga CLMのAgreementオブジェクトにリンクされています。
例
Global Tech Inc.Innovate Solutions LLCAcme Corporation
|
|||
契約管理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
契約を有効化
|
契約が組織内で効力を持ち、運用可能な状態になり、義務と権利が発生したことを示します。通常は、ステータスが「Executed」から「Active」へ変わったことから推定します。 | ||
|
重要な理由
署名後のライフサイクルの開始を示すアクティビティです。義務管理とパフォーマンス監視の起点になります。
入手先
Contractオブジェクトのステータス項目の履歴から推定します。ステータスが「Active」または同等の値に変わった時点がイベントになります。
取得
ステータスが「Executed」から「Active」に変わった時点のタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
契約を締結・署名
|
すべての当事者が契約書に法的な署名を行い、拘束力のある合意となる重要なアクティビティです。Conga CLMと連携するConga Signなどの電子署名ソリューションでは、タイムスタンプ付きの明示的なイベントが作成されます。 | ||
|
重要な理由
署名前のプロセスが正常に完了したことを示すアクティビティであり、「Contract Execution Rate」などのパフォーマンス指標における重要なマイルストーンです。通常、主要な「happy path」の終了イベントとみなされます。
入手先
連携した電子署名ツールの監査証跡またはステータスから取得します。最終的な「Completed」または「Signed」ステータスが、正確なタイムスタンプとともに記録されます。
取得
連携した電子署名サービスのAPIまたはステータスオブジェクトから、完了イベントを記録します。
イベントタイプ
explicit
|
|||
|
契約依頼を開始
|
このアクティビティは、契約ライフサイクルの正式な開始を示し、システム内で新しい契約レコードが作成されたことを表します。通常、ユーザーがConga CLMで新しいContractオブジェクトを作成した際の明示的なイベントとして記録されます。 | ||
|
重要な理由
すべての契約の起点となるこのアクティビティは、エンドツーエンドのサイクルタイムを測定するうえで欠かせません。開始された契約の件数と種類を分析できます。
入手先
このイベントは、Conga CLMの基盤であるSalesforceプラットフォーム上のContractレコードに記録された作成日とタイムスタンプから取得します。通常、レコードを作成したユーザーも記録されます。
取得
主要なContractオブジェクトの作成イベントを追跡します。
イベントタイプ
explicit
|
|||
|
契約満了
|
更新も終了もされないまま満了日に達し、契約ライフサイクルが自然に終了したことを示します。このイベントは明示的に記録されず、契約データから導出されます。 | ||
|
重要な理由
契約ライフサイクルにおける予定された終了を定義します。満了した契約を分析することで、更新機会と契約ポートフォリオ全体の管理状況を把握できます。
入手先
計算によって求められるイベントです。Contractオブジェクトの「Contract End Date」または「Expiration Date」フィールドをシステム日付が過ぎ、ステータスがまだ「Active」の場合に発生します。
取得
「Contract End Date」フィールドと現在の日付を比較して導出します。
イベントタイプ
calculated
|
|||
|
契約終了
|
特定の操作に基づき、契約満了日前に契約が予定より早く終了したことを示します。契約のステータスが「Terminated」に変更されたことで記録されます。 | ||
|
重要な理由
終了状態を示す重要なイベントとして、終了イベントは契約の失敗率やキャンセル理由を理解するうえで重要です。多くの場合は否定的な結果ですが、プロセスの明確な終点になります。
入手先
Contractオブジェクトのステータスフィールド履歴から推測されます。ステータスが「Terminated」または「Cancelled」に更新された時点がイベントのタイムスタンプです。
取得
ステータスが「Terminated」に変更された時点のタイムスタンプを取得します。
イベントタイプ
inferred
|
|||
|
法務レビューを実施
|
法務部門が契約書のレビューを完了したことを示します。ワークフロー内の明示的な承認ステップとして記録するか、「Legal Review Complete」などへのステータス変更から推定できます。 | ||
|
重要な理由
法務レビューの段階を分離することは、よくあるボトルネックを分析するうえで重要です。「Average Legal Review Time」KPIの算出を支え、法務部門のリソース最適化に役立ちます。
入手先
Salesforce Approvalsを使用している場合は、承認履歴の関連リストに記録できます。別の方法として、Contractオブジェクトのステータス変更から推定することもできます。
取得
ステータスが「Legal Review Complete」に変わった時点、または法務キューにおける最終承認ステップのタイムスタンプを記録します。
イベントタイプ
inferred
|
|||
|
社内承認を取得
|
契約に必要なすべての社内承認が完了し、締結の準備が整ったことを示すマイルストーンです。通常は、複数段階のSalesforce Approval Processにおける最終ステップです。 | ||
|
重要な理由
社内レビューと承認サイクルを終える重要なマイルストーンです。「Average Contract Approval Time」KPIを測定する終点になります。
入手先
ContractオブジェクトのSalesforce Approval History関連リストから取得します。プロセス内で最終的に「Approved」ステータスになった時点のタイムスタンプがイベントになります。
取得
関連する承認プロセスの最終承認ステップのタイムスタンプを記録します。
イベントタイプ
explicit
|
|||
|
コンプライアンスレビューを実施
|
契約の有効化後に、コンプライアンス要件や規制に照らして契約をレビューするアクティビティです。関連するタスクまたはチェックリスト項目が完了としてマークされた時点で記録できます。 | ||
|
重要な理由
このアクティビティは、ガバナンスとリスク管理を監視するうえで重要です。これらのチェックが実施されたか、また実施時期を追跡し、「コンプライアンスレビュー遵守率」KPIを支援します。
入手先
関連するTaskの完了、またはContractにリンクされたカスタム「Compliance Review」オブジェクトの完了から推測されます。このレコードの完了日がイベントのタイムスタンプになります。
取得
定期Taskまたは関連するコンプライアンスレコードの完了日を取得します。
イベントタイプ
inferred
|
|||
|
修正依頼
|
既存の有効な契約を正式に変更するプロセスの開始を示します。通常は、元の契約に関連付けられた新しい「Amendment」レコードの作成によって記録されます。 | ||
|
重要な理由
修正は、プロセスにおける大きな変動要因です。その頻度とサイクルタイムを分析することで、元の契約範囲の定義や変化するビジネスニーズに関する問題を明らかにできます。
入手先
主Contractオブジェクトを参照するルックアップ関係を持つ「Amendment」または同様の名前のオブジェクトに、新しいレコードが作成された日時から取得されます。
取得
契約にリンクされた「Amendment」レコードの作成イベントを追跡します。
イベントタイプ
explicit
|
|||
|
契約更新完了
|
契約が正常に更新され、ライフサイクルが延長されたことを示します。元の契約のステータス変更、または更新契約として指定された新しい契約レコードの作成によって記録できます。 | ||
|
重要な理由
更新を追跡することは、収益維持と事業継続に欠かせず、「適時更新率」KPIを支援します。契約ライフサイクルにおける良好な結果を示します。
入手先
ステータスが「Renewed」に変更されたことから推測できます。別の方法として、新しい契約レコードが作成され、「Renewal For」フィールドが旧契約を指している場合は、その新しいレコードの作成から判断できます。
取得
ステータスの「Renewed」への変更、またはリンクされた新しい契約レコードの作成を特定します。
イベントタイプ
inferred
|
|||
|
契約書を作成
|
契約書の初稿作成が完了したことを示します。通常は、契約レコードのステータスが「Requested」から「Drafting」または「In Review」へ変わったことなどから推定します。 | ||
|
重要な理由
このアクティビティを追跡することで、初稿作成にかかった時間を測定できます。ここで遅延が発生している場合、テンプレート、データ収集、リソース配分に問題がある可能性があります。
入手先
Contractオブジェクトのステータス項目の履歴から推定します。ステータスが「Internal Review」など、初稿作成後の値に変わった時点のタイムスタンプを確認します。
取得
「Draft」からワークフロー上の次の論理的な状態へのステータス変更を特定します。
イベントタイプ
inferred
|
|||
|
契約書を修正・改訂
|
交渉中に契約書の新しいバージョンがチェックインまたはアップロードされるたびに発生するアクティビティです。Conga CLMのバージョン管理機能により、文書の各バージョンが記録されます。 | ||
|
重要な理由
修正の頻度を追跡することで、交渉の複雑さを定量化し、「Redline Iteration Count」KPIを算出できます。複雑すぎる契約や難航している交渉を明らかにすることにも役立ちます。
入手先
Conga CLMに保存された契約書のバージョン履歴から取得します。相手先への送付後に作成された各バージョンが、個別のイベントになります。
取得
メジャーバージョン番号が変わる新しい文書バージョンが作成されるたびに、イベントを記録します。
イベントタイプ
explicit
|
|||
|
契約書を相手先へ送付
|
契約書を外部の相手先へ送り、レビューと交渉を依頼する明示的な操作を示します。Conga CLMでは、「Send for Negotiation」操作が記録されることがよくあります。 | ||
|
重要な理由
このアクティビティは、社内プロセスから外部との交渉へ移行したことを示します。交渉サイクルタイムを測定する起点です。
入手先
通常は、Contractに関連付けられたActivityまたはTaskレコードとして記録され、システム操作によって自動的に作成されることもあります。
取得
「Send for Negotiation」または「Send to Counterparty」のイベントログを特定します。
イベントタイプ
explicit
|
|||
|
相手先の承認を取得
|
外部の相手先が条件に合意し、署名の準備が整ったことを示します。手動で更新されるステータスとして記録する場合や、ポータルを利用している場合はポータルから取得する場合があります。 | ||
|
重要な理由
アクティブな交渉段階の終了を示します。「Average Negotiation Cycle Time」の測定と、契約締結時期の予測に役立つ重要なイベントです。
入手先
通常は、Contractオブジェクトのステータスが「Awaiting Signature」などに変わったことから推定します。契約担当者が手動で更新します。
取得
ステータスが「Approved by Counterparty」または「Pending Signature」に変わった時点のタイムスタンプを記録します。
イベントタイプ
inferred
|
|||
|
社内レビューを開始
|
作成した契約書を、財務部門や事業部門のマネージャーなど、社内の関係者によるレビューに提出した時点を示します。通常は、ステータスが「In Internal Review」などに変わったことから推定します。 | ||
|
重要な理由
このアクティビティは、社内レビューのサイクルタイムを測定する起点です。契約がレビューを待っている時間と、レビュー自体にかかる時間を特定できます。
入手先
Contractオブジェクトのステータス項目の履歴から推定します。社内レビュー段階の開始を示すステータスに変わった時点で、イベントのタイムスタンプを記録します。
取得
契約ステータスが「Internal Review」または同等の値に変わった時点のタイムスタンプを記録します。
イベントタイプ
inferred
|
|||
抽出ガイド
準備はできましたか?
契約管理プロセスの可能性を最大限に引き出すため、今日からデータの準備を始めましょう。ProcessMindが新たな効率化の機会を見つけるお手伝いをします。
効率化を実現:今日から契約管理を最適化
ワークフローを効率化し、契約サイクルを30%短縮しましょう。
クレジットカード不要、数分で設定できます