契約管理データテンプレート
契約管理データテンプレート
- 収集を推奨する属性
- 追跡すべき主なアクティビティ
- データ抽出の手引き
契約管理の属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ名
ActivityName
|
契約ライフサイクルで発生した特定の業務イベントまたはタスクの名前です。 | ||
|
説明
アクティビティ名は、「契約書のドラフト作成」「法務レビューの実施」「契約の締結・署名」など、契約管理プロセスのステップやマイルストーンを表します。この属性を使ってプロセスマップを作成し、実行された操作の順序を示します。 この属性を分析すると、プロセスの流れや一般的な経路と代替経路がわかり、各アクティビティの発生頻度を測定できます。プロセスの適合性チェック、手戻り、各段階間のサイクルタイムに関するKPIの算出にも欠かせません。
重要な理由
プロセスの各ステップを定義し、プロセスマップの基盤となります。ワークフロー、逸脱、アクティビティの発生頻度を分析できます。
入手先
通常、Conga CLMのContractオブジェクトに記録されたステータス変更、完了したタスク、特定のイベントを対応付けて導出します。
例
契約書のドラフト作成法務レビューの実施契約の締結・署名契約の更新
|
|||
|
イベントのタイムスタンプ
EventTimestamp
|
アクティビティが開始または発生した正確な日時です。 | ||
|
説明
イベントのタイムスタンプは、特定のアクティビティが発生した時点を記録します。契約ごとのプロセスの流れを再構成するために必要な時系列情報を提供します。タイムスタンプは、時間に基づくあらゆるプロセスマイニング分析に欠かせません。 この属性を使って、アクティビティ間の所要時間、ケース全体のサイクルタイム、待ち時間を算出します。ボトルネックの特定、SLAの遵守状況の監視、契約管理プロセスの時間的な推移の把握にも重要です。ケース内のイベントを並べ替える際の主要なキーとしても機能します。
重要な理由
イベントの時系列を示すため、所要時間に基づく指標の算出、ボトルネックの特定、プロセスパフォーマンスの把握に欠かせません。
入手先
通常、関連するTaskまたはイベントオブジェクトの「CreatedDate」などの履歴追跡項目や、主要なContractオブジェクトの日付項目に記録されています。
例
2023-04-15T10:05:00Z2023-05-20T14:30:00Z2023-06-01T09:00:00Z
|
|||
|
契約ID
ContractId
|
各契約を一意に識別し、主要なケース識別子として機能するIDです。 | ||
|
説明
契約IDは、1件の契約ライフサイクルに関するすべてのイベントとアクティビティを結び付ける、確定的なケース識別子です。契約の最初の依頼から、ドラフト作成、交渉、締結、最終的な終了または更新まで、全工程を追跡できます。 プロセスマイニング分析では、各契約の流れを再構成するため、すべてのイベントに契約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(抽出、変換、ロード)ツールまたはスクリプトによって生成・入力されるメタデータ項目です。
例
2024-07-20T02:00:00Z2024-07-21T02:00:00Z
|
|||
|
イベント終了時刻
EventEndTime
|
アクティビティが完了した正確な日時です。 | ||
|
説明
イベント終了時刻は、特定のタスクまたはプロセスのステップが完了した時点を示します。イベントタイムスタンプ(開始時刻)と組み合わせることで、各アクティビティの処理時間を正確に算出できます。 この属性はパフォーマンス分析に欠かせません。各ステップにかかる時間を測定し、最も時間を要するアクティビティを特定できます。また、次のイベントの開始時刻だけを使う場合と比べて、リソースの利用状況や効率をより正確に把握できます。
重要な理由
アクティビティの処理時間を正確に算出できるため、所要時間に関するボトルネックの特定やリソース効率の分析に役立ちます。
入手先
このタイムスタンプは、メインの契約に関連するタスクまたはアクティビティのオブジェクトにある「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」などが一般的です。
例
下書き社内レビュー中締結済み期限切れ
|
|||
|
契約担当者
ContractOwner
|
契約のライフサイクル全体を通じて管理を担うユーザーまたは従業員です。 | ||
|
説明
契約担当者は、契約の主な責任者として割り当てられた人物です。通常、契約書の作成や交渉を担当し、承認プロセスが滞りなく進むよう管理します。 契約担当者ごとにプロセスのパフォーマンスを分析すると、効率、標準プロセスへの準拠状況、業務負荷の分布にどのような違いがあるかを把握できます。ベストプラクティスや研修の必要性、リソース配分の偏りを特定するのに役立ちます。パフォーマンスと生産性を分析するうえで重要な切り口です。
重要な理由
ユーザーごとのパフォーマンスを分析し、優れた成果を上げている担当者、研修の機会、業務負荷の偏りを把握できます。
入手先
これは、Conga CLMのメインAgreementオブジェクトにあるユーザー参照フィールドと考えられます。通常は「OwnerId」またはカスタムの「Contract_Owner__c」フィールドという名前です。
例
Alice JohnsonRobert ChenMaria Garcia
|
|||
|
契約種別
ContractType
|
NDA、MSA、SOWなど、契約の分類です。 | ||
|
説明
契約種別は、法的な目的や性質に基づいて契約を分類する属性です。一般的な例として、秘密保持契約(NDA)、基本サービス契約(MSA)、作業範囲記述書(SOW)があります。 この切り口は、契約を比較分析するうえで基本となります。プロセスマップを契約種別で絞り込み、種別によってプロセスの経路やサイクルタイムが異なるかを確認できます。特定の契約種別に適したプロセスの違いと、実際の逸脱を見分けるために役立ちます。
重要な理由
NDAとMSAなど、契約の種類ごとにワークフロー、サイクルタイム、ボトルネックを比較できます。
入手先
通常、Agreementオブジェクトの選択リストまたは参照項目です。「Apttus_Config2__Contract_Type__c」などの名前が使われます。
例
秘密保持契約(NDA)基本サービス契約(MSA)作業範囲記述書(SOW)
|
|||
|
契約金額
ContractValue
|
契約に関連する金額の合計です。 | ||
|
説明
契約金額は、契約の金銭的価値を表します。業務の状況に応じて、契約総額、年間経常収益、その他の主要な財務指標が該当します。 この属性の分析は、契約価値に基づいてプロセスを改善するうえで重要です。金額の大きい契約を優先して分析し、高額契約の処理が速いか、特定の段階で滞りやすいかといった点を確認できます。「契約金額別の処理状況分析」ダッシュボードの主要な項目です。
重要な理由
契約金額に基づく分析が可能になり、高額契約に関するプロセス改善の優先順位付けや、業務への影響の把握に役立ちます。
入手先
通常、Conga CLMのAgreementオブジェクトにある通貨項目です。「Apttus_Config2__Total_Contract_Value__c」などが該当します。
例
500002500001200000
|
|||
|
有効期限
ExpirationDate
|
契約の期限が切れる日付です。 | ||
|
説明
有効期限は、契約期間の終了日を示す重要な日付項目です。契約締結後のライフサイクル管理に欠かせません。 この属性は、「更新・期限切れ予定」ダッシュボードと「期限内更新率」の重要業績評価指標(KPI)に使用されます。日付を分析することで、組織は契約の期限切れに先回りして対応し、適切な時期に更新手続きを開始できます。サービスや収益が意図せず途切れる事態の防止にも役立ちます。
重要な理由
契約を先回りして管理するうえで重要な日付です。期限が近い契約をダッシュボードで追跡し、更新漏れや収益の損失を防げます。
入手先
Agreementオブジェクトの標準的な日付項目です。「Apttus_Config2__EndDate__c」などが一般的です。
例
2025-12-312026-06-302024-08-15
|
|||
|
コンプライアンスステータス
ComplianceStatus
|
契約が必要なコンプライアンス審査に合格したかどうかを示します。 | ||
|
説明
コンプライアンスステータスは、社内規程や外部規制に照らした契約の状態を記録します。「未着手」「審査中」「合格」「不合格」などの値が設定されます。 この属性は、「コンプライアンスと義務のモニタリング」ダッシュボードと関連する重要業績評価指標(KPI)に欠かせません。コンプライアンス要件への適合状況を直接確認でき、締結または有効化の前に必要な審査をすべて実施して合格していることを確かめることで、法務・財務上のリスクを抑えられます。
重要な理由
コンプライアンス手順への適合状況を直接測定し、契約ポートフォリオに潜む法務・財務上のリスクの特定と低減に役立ちます。
入手先
Agreementオブジェクトのカスタム選択リスト項目と考えられます。コンプライアンス関連のアクティビティや承認に応じて更新されます。
例
合格要審査該当なし不合格
|
|||
|
事業部門
BusinessUnit
|
組織内で契約が属する特定の事業部門です。 | ||
|
説明
事業部門属性は、「エンタープライズソフトウェア」や「コンシューマーハードウェア」など、契約を会社の特定の部門や事業セグメントに割り当てます。これにより、組織内の各部門における契約管理プロセスを、より細かく分析できます。 事業部門ごとに分析すると、部門によってプロセスのバリアント、パフォーマンス、契約種別に違いがあるかを確認できます。大規模な組織が、事業部門固有の妥当なニーズに対応しながらプロセスを標準化する際に役立ちます。
重要な理由
組織内の部門ごとにプロセスのパフォーマンスを比較し、効率や手順の違いを把握できます。
入手先
Agreementオブジェクトのカスタム項目、または契約担当者のユーザープロフィールから取得する情報が該当します。
例
北米営業EMEAサービスAPAC製品部門
|
|||
|
取引相手名
CounterpartyName
|
契約に関与する外部の当事者、企業、または個人の名前です。 | ||
|
説明
取引相手名は、契約のもう一方の署名者を示します。通常、顧客、ベンダー、またはパートナー組織が該当します。 取引相手ごとにプロセス指標を分析すると、重要な傾向が見えてきます。たとえば、特定の取引相手との交渉に一貫して時間がかかる、または修正回数が多いといった状況を把握できます。こうした情報は、交渉方針の検討や主要なビジネスパートナーとの関係管理に役立ちます。
重要な理由
外部の取引相手ごとにプロセスの違いを分析し、交渉に時間がかかる顧客やベンダー、修正率の高い相手を特定できます。
入手先
多くの場合、SalesforceのAccountオブジェクトへの参照項目です。このAccountオブジェクトは、Conga CLMのAgreementオブジェクトに関連付けられています。
例
Global Tech Inc.Innovate Solutions LLCAcme Corporation
|
|||
|
地域
Region
|
「北米」や「EMEA」など、契約に関連する地理的な地域です。 | ||
|
説明
地域属性は、取引相手の所在地、営業地域、または準拠法などに基づく、契約に関係する地理的な範囲を示します。 この属性を使うと、地域ごとの契約プロセスを分析できます。「EMEAでは規制の違いにより契約の承認に時間がかかるか」「APAC地域の契約では修正依頼の割合が高いか」といった疑問を検証できます。グローバルな業務を理解するための背景情報になります。
重要な理由
地域ごとに比較することで、サイクルタイム、コンプライアンス要件、プロセスの経路における地理的な違いを特定できます。グローバルに事業を展開する企業にとって重要な分析です。
入手先
Agreementオブジェクトのカスタム項目、または関連付けられたAccountオブジェクトやUserオブジェクトから取得する情報が該当します。
例
北米EMEAAPACLATAM
|
|||
|
手戻りの有無
IsRework
|
アクティビティが手戻りループの一部かどうかを示す計算フラグです。 | ||
|
説明
手戻りの有無は、アクティビティがプロセスの後戻りを表す場合に「true」に設定されるブール型フラグです。たとえば、法務審査後に「契約書作成済み」の段階へ戻るケースが該当します。これはソースシステムの項目ではなく、プロセスマイニング用のデータ変換時に算出されます。 このフラグは、プロセスの非効率を定量化するうえで役立ちます。「契約の手戻り率」の重要業績評価指標(KPI)に直接利用でき、プロセスマップ上でループを可視化できます。手戻りの頻度と原因の特定は、多くのプロセス改善施策の主な目的です。
重要な理由
無駄な手戻りループに含まれるアクティビティを明らかにすることで、プロセスの非効率を簡単に定量化し、分析できます。
入手先
この属性はソースシステムにはありません。アクティビティの順序に基づき、プロセスマイニングツールまたはETLレイヤーで算出します。
例
truefalse
|
|||
|
承認サイクルタイム
ApprovalCycleTime
|
契約が承認段階に費やす合計時間です。 | ||
|
説明
承認サイクルタイムは、契約が承認プロセスに入った時点(例:「社内レビュー開始」)から、最終的な社内承認を得るまでの期間を測定する計算指標です。該当するすべての承認ステップにかかった時間を合計します。 この属性は、「契約承認サイクルタイム」ダッシュボードと「契約承認の平均所要時間」の重要業績評価指標(KPI)における主要な測定項目です。承認ワークフロー全体の効率を俯瞰できるため、目標に対するパフォーマンスの追跡や、全体に影響する遅延の特定に役立ちます。
重要な理由
承認ワークフローの効率を直接測定し、契約ライフサイクルの重要な段階における遅延の特定と解消に役立ちます。
入手先
計算指標です。各契約について、最初の承認アクティビティから最終承認アクティビティまでの時間差を算出します。
例
259200604800432000
|
|||
|
担当者の部門
OwnerDepartment
|
契約担当者が所属する部門です。「営業」「法務」「調達」などが該当します。 | ||
|
説明
担当者の部門属性は、契約担当者が所属する業務部門を示します。通常、システム内のユーザープロフィールから取得します。 この切り口を使うと、部門間でプロセスのパフォーマンスを比較できます。法務部門がボトルネックになっているか、営業チームが異なるプロセスに従っているか、特定の部門でサイクルタイムが大幅に長くなっているかを特定できます。部門横断のプロセス改善に役立つ情報です。
重要な理由
業務部門ごとにプロセスを分析し、営業や法務などの部門間におけるパフォーマンスの違いやボトルネックを把握できます。
入手先
通常、このデータはSalesforceのUserオブジェクトから取得します。Agreementオブジェクトの契約担当者項目を介して関連付けられます。
例
営業法務調達財務
|
|||
|
更新日
RenewalDate
|
契約の更新手続きを開始する目標日です。 | ||
|
説明
更新日は、契約の更新手続きを開始する時期を示す日付です。計算によって設定する場合と、手動で設定する場合があります。通常、有効期限の一定期間前(例:90日前)に設定します。 この属性は、更新案件を効率よく管理するのに役立ちます。アラートの通知や契約更新に関するタスクの自動化に利用でき、十分な準備期間を確保して手続きを開始できます。「期限内更新率」の重要業績評価指標(KPI)を算出する際にも使われます。
重要な理由
更新に関する業務を開始するタイミングを示し、契約の期限内更新と先を見越したライフサイクル管理を支援します。
入手先
有効期限に基づくカスタム数式項目、またはConga CLMのAgreementオブジェクトにある別の日付項目が該当します。
例
2025-10-022026-04-012024-05-17
|
|||
契約管理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
契約の有効化
|
契約が組織内で有効になり、業務上の効力を持つことを示します。これにより、義務や権利が発生します。通常、「締結済み」から「有効」へのステータス変更から推定します。 | ||
|
重要な理由
このアクティビティは署名後のライフサイクルの開始を示します。契約上の義務の管理とパフォーマンスの監視を始める起点です。
入手先
Contractオブジェクトのステータス項目の履歴から推定します。ステータスが「有効」または同等の状態に変わった時点がイベントのタイムスタンプになります。
記録
ステータスが「締結済み」から「有効」に変わった時点のタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
契約の満了
|
更新や途中終了がないまま有効期限を迎え、契約のライフサイクルが自然に終了したことを示します。このイベントは明示的に記録されず、契約データから算出します。 | ||
|
重要な理由
このアクティビティは、契約ライフサイクルの予定された終了を示します。満了した契約を分析すると、更新機会や契約ポートフォリオ全体の管理状況を把握できます。
入手先
このイベントは計算によって求めます。システム日付がContractオブジェクトの「契約終了日」または「有効期限」項目を過ぎており、ステータスが「有効」のままの場合に発生します。
記録
「契約終了日」項目を現在の日付と比較して算出します。
イベントタイプ
calculated
|
|||
|
契約の終了
|
特定の操作によって、契約が有効期限前に終了したことを示します。契約のステータスが「終了」に変わった時点で記録されます。 | ||
|
重要な理由
終了は重要な最終状態です。契約の不成立率や解約理由を把握するうえで重要であり、多くの場合は望ましくない結果ですが、プロセスの明確な終点となります。
入手先
Contractオブジェクトのステータス項目の履歴から推定します。ステータスが「終了」または「キャンセル」に更新された時点がイベントのタイムスタンプになります。
記録
ステータスが「終了」に変わった時点のタイムスタンプを記録します。
イベントタイプ
inferred
|
|||
|
契約の締結・署名
|
すべての当事者が法的に有効な契約書に署名したことを示す重要なアクティビティです。Conga Signなど、Conga CLMと連携した電子署名ソリューションでは、タイムスタンプ付きの明示的なイベントが作成されます。 | ||
|
重要な理由
署名前のプロセスが正常に完了したことを示すアクティビティで、「契約締結率」などのパフォーマンス指標を測定する重要なマイルストーンです。通常、理想経路の主な終了イベントとみなされます。
入手先
連携した電子署名ツールの監査証跡またはステータスから取得します。「完了」または「署名済み」の最終ステータスが、正確なタイムスタンプとともに記録されます。
記録
連携した電子署名サービスのAPIまたはステータスオブジェクトから、完了イベントを記録します。
イベントタイプ
explicit
|
|||
|
契約依頼の開始
|
このアクティビティは契約ライフサイクルの正式な開始を示し、システムで新しい契約レコードが作成されたことを表します。通常、ユーザーがConga CLMで新しいContractオブジェクトを作成した時点で、明示的なイベントとして記録されます。 | ||
|
重要な理由
すべての契約の起点となるこのアクティビティは、エンドツーエンドのサイクルタイムを測定するうえで欠かせません。開始された契約の件数や種類を分析できます。
入手先
このイベントは、Conga CLMの基盤であるSalesforceプラットフォーム上のContractレコードの作成日とタイムスタンプから取得します。通常、レコードを作成したユーザーも記録されます。
記録
主要なContractオブジェクトの作成イベントを追跡します。
イベントタイプ
explicit
|
|||
|
法務レビューの実施
|
法務部門が契約書のレビューを完了したことを示します。ワークフローの明示的な承認ステップとして記録するか、「法務レビュー完了」などへのステータス変更から推定できます。 | ||
|
重要な理由
法務レビューの段階を切り分けることは、よくあるボトルネックを分析するうえで重要です。「法務レビュー平均時間」のKPIを算出し、法務部門のリソース配分を見直す際に役立ちます。
入手先
Salesforce Approvalsを使用している場合は、承認履歴の関連リストに記録できます。または、Contractオブジェクトのステータス変更から推定できます。
記録
ステータスが「法務レビュー完了」に変わった時点、または法務キューで最終承認された時点のタイムスタンプを記録します。
イベントタイプ
inferred
|
|||
|
社内承認の取得
|
契約に必要な社内承認がすべて完了し、締結できる状態になったことを示すマイルストーンです。通常、複数段階からなるSalesforce Approval Processの最終ステップにあたります。 | ||
|
重要な理由
社内レビューと承認サイクルを締めくくる重要なマイルストーンです。「契約承認平均時間」KPIを測定する際の終点となります。
入手先
ContractオブジェクトのSalesforce Approval History関連リストから取得します。プロセスで最終的に「承認済み」となった時点のタイムスタンプがイベントになります。
記録
関連する承認プロセスの最終承認ステップのタイムスタンプを記録します。
イベントタイプ
explicit
|
|||
|
コンプライアンスレビューの実施
|
契約の有効化後に、コンプライアンス要件や規制に照らして契約を確認するアクティビティです。関連するTaskやチェックリスト項目が完了としてマークされた時点で記録できます。 | ||
|
重要な理由
このアクティビティは、ガバナンスとリスク管理の監視に欠かせません。チェックの実施有無と時期を追跡し、「コンプライアンスレビュー遵守率」KPIの算出に役立ちます。
入手先
Contractに関連付けられたTask、またはカスタムの「コンプライアンスレビュー」オブジェクトの完了から推定できます。該当レコードの完了日をイベントのタイムスタンプとして使用します。
記録
定期タスクまたは関連するコンプライアンスレコードの完了日を記録します。
イベントタイプ
inferred
|
|||
|
契約の更新
|
契約が更新され、ライフサイクルが延長されたことを示します。元の契約のステータス変更、または更新契約として指定された新しい契約レコードの作成から記録できます。 | ||
|
重要な理由
更新の追跡は、収益の維持と事業継続に欠かせません。「期限内更新率」KPIの算出に役立ち、契約ライフサイクルにおける望ましい成果を示します。
入手先
ステータスが「更新済み」に変わった時点から推定できます。または、新しい契約レコードが作成され、「更新対象」項目が以前の契約を参照している場合、その作成をイベントとして記録します。
記録
ステータスが「更新済み」に変わったこと、または関連付けられた新しい契約レコードが作成されたことを特定します。
イベントタイプ
inferred
|
|||
|
契約変更の依頼
|
有効な既存契約を正式に変更するプロセスの開始を示します。通常、元の契約に関連付けられた新しい「変更」レコードの作成によって記録されます。 | ||
|
重要な理由
契約変更は、プロセスに大きな違いをもたらします。その頻度やサイクルタイムを分析すると、当初の契約範囲や変化するビジネスニーズに関する課題が見つかることがあります。
入手先
主要なContractオブジェクトを参照する「変更」または同様の名前のオブジェクトに、新しいレコードが作成された日付から取得します。
記録
契約に関連付けられた「変更」レコードの作成イベントを追跡します。
イベントタイプ
explicit
|
|||
|
契約書のドラフト作成
|
契約書の初稿作成が完了したことを示します。通常、契約レコードのステータスが「依頼済み」から「ドラフト作成中」または「レビュー中」に変わった時点から推定します。 | ||
|
重要な理由
このアクティビティを追跡すると、初稿の作成にかかった時間を測定できます。ここでの遅延は、テンプレート、データ収集、リソース配分に問題がある可能性を示します。
入手先
Contractオブジェクトのステータス項目の履歴から推定します。「社内レビュー」など、ドラフト作成後のステータスに変わった時点のタイムスタンプを確認します。
記録
ワークフローで「下書き」から次の段階にステータスが変わったことを特定します。
イベントタイプ
inferred
|
|||
|
契約書の修正・改訂
|
交渉中に契約書の新しいバージョンがチェックインまたはアップロードされるたびに発生するアクティビティです。Conga CLMのバージョン管理機能により、文書のバージョンごとにレコードが作成されます。 | ||
|
重要な理由
修正の回数を追跡すると、交渉の頻度を定量化でき、「修正反復回数」KPIの算出に役立ちます。契約内容が過度に複雑な場合や、交渉が難航している場合も把握できます。
入手先
Conga CLMに保存された契約書のバージョン履歴から取得します。相手方への送付後に作成された各バージョンを、個別のイベントとして記録します。
記録
メジャーバージョン番号が変わる新しい文書バージョンが作成されるたびに、イベントを記録します。
イベントタイプ
explicit
|
|||
|
契約書を相手方に送付
|
契約書を外部の相手方に送り、レビューと交渉を依頼する明示的な操作を示します。Conga CLMでは、「交渉のために送信」などの専用操作が記録されることがよくあります。 | ||
|
重要な理由
このアクティビティは、社内プロセスから外部との交渉へ移る時点を示します。交渉サイクルタイムを測定する起点です。
入手先
通常、Contractに関連付けられたアクティビティまたはTaskレコードとして記録され、システム操作によって自動作成されることもあります。
記録
「交渉のために送信」または「相手方に送信」のイベントログを特定します。
イベントタイプ
explicit
|
|||
|
相手方の承認を取得
|
外部の相手方が契約条件に合意し、署名できる状態になったことを示します。手動でステータスを更新する場合が多く、ポータルを使用していればそこから記録できることもあります。 | ||
|
重要な理由
この時点で進行中の交渉が終了します。「交渉サイクルタイム平均」の測定や、契約締結時期の予測に役立つ重要なイベントです。
入手先
通常、Contractオブジェクトのステータスが「署名待ち」などに変わった時点から推定します。契約担当者が手動で更新します。
記録
ステータスが「相手方承認済み」または「署名保留中」に変わった時点のタイムスタンプを記録します。
イベントタイプ
inferred
|
|||
|
社内レビューの開始
|
作成した契約書を、財務部門や事業部門のマネージャーなど社内関係者にレビュー依頼した時点を示します。通常、「社内レビュー中」などへのステータス変更から推定します。 | ||
|
重要な理由
このアクティビティは、社内レビューのサイクルタイムを測定する起点です。契約書がレビュー待ちとなっている時間と、レビュー自体にかかる時間を把握できます。
入手先
Contractオブジェクトのステータス項目の履歴から推定します。社内レビュー段階の開始を示すステータスに変わった時点をイベントのタイムスタンプとして記録します。
記録
契約のステータスが「社内レビュー」または同等の状態に変わった時点のタイムスタンプを記録します。
イベントタイプ
inferred
|
|||
データ抽出ガイド
準備はできましたか?
契約管理プロセスの可能性を引き出すため、今日からデータの準備を始めましょう。ProcessMindを使って、新たな効率化の機会を見つけられます。
契約管理を効率化するために、今できること
ワークフローの見直しを始め、契約サイクルタイムを30%短縮しましょう。
クレジットカード不要、数分でセットアップできます