> 継続的なプロセス改善 > 契約管理 > Icertis > データテンプレート

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

Icertis

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

このテンプレートは、契約管理プロセスを分析するために必要な重要なデータを収集するための包括的なガイドを提供します。収集すべき主要な属性、追跡すべき重要なアクティビティ、およびソースシステムからこの情報を抽出するための実用的なガイダンスを概説しています。このリソースを活用して、効果的なプロセスマイニングに必要なすべてのデータを確実に捕捉してください。

収集を推奨する項目
追跡すべき主要アクティビティ
ソースシステムからのデータ抽出ガイダンス

イベントログについて初めての方へ：プロセスマイニングのイベントログ作成方法.

テンプレートをダウンロード

契約管理属性

これらは、契約管理プロセスを包括的に分析するための堅牢なイベントログを構築するために必要な、必須のデータフィールドです。

3 必須 6 推奨 12 任意

	名前	説明
	契約ID ContractId	Icertisプラットフォーム内で管理される各契約の一意の識別子です。
説明契約IDは、特定の契約に関連するすべてのイベントとアクティビティを一意にリンクする決定的なケース識別子として機能します。これにより、各契約の開始から解決までのジャーニーを包括的にエンドツーエンドで分析できます。プロセスマイニングにおいて、この属性はすべての契約のライフサイクルを再構築するための基本です。これにより、作成、審査、承認、実行などのすべての関連アクティビティが適切な契約に正しく関連付けられ、サイクルタイムの正確な測定とプロセスバリエーションの特定が可能になります。その重要性これはプロセス分析の主キーであり、契約の完全なジャーニーを追跡し、データ整合性を確保することを可能にします。取得元これはIcertisにおける契約合意オブジェクトの主要な属性です。例 CTR-2023-00123MSA-2024-589ANDA-FN-00451
	アクティビティ名 ActivityName	契約ライフサイクルのある時点で発生した特定のイベントまたはタスクの名称です。
説明アクティビティ名とは、契約管理プロセスにおける特定のステップまたはマイルストーンを説明するものです。これらのイベントは、各契約のプロセスフローを構築するためにタイムスタンプによって順序付けられます。この属性の分析により、操作の順序、異なるアクティビティの頻度、およびプロセス全体の構造が明らかになります。これは、一般的なプロセスパス、標準手順からの逸脱、および複数の改訂サイクルなどの手戻りや遅延を引き起こすアクティビティを特定するために使用されます。その重要性プロセスのステップを定義し、プロセスマップの可視化、プロセスフローの分析、ボトルネックの特定に不可欠です。取得元この情報は通常、Icertis内のイベントログまたはワークフロー履歴テーブルから生成されます。これらは契約のステータス変更と実行されたタスクを追跡します。例契約書作成済み法務審査実施済み契約締結済み修正契約開始済み
	イベント日時 EventTime	特定の契約アクティビティが発生したことを示すタイムスタンプです。
説明この属性は、アクティビティが開始または完了した正確な日時を記録します。これはプロセスマイニングの時間的基盤であり、各契約ケースのイベントの時系列順序を提供します。イベントタイムは、すべての時間ベースの分析にとって重要です。アクティビティ間のサイクルタイムの計算、待機期間の特定、交渉や承認などの特定のフェーズの期間測定、契約が長期間滞留するボトルネックの特定に使用されます。その重要性このタイムスタンプは、サイクルタイムや期間などのすべてのパフォーマンスメトリックを計算し、イベントの順序を理解するために不可欠です。取得元これはIcertisの監査証跡またはワークフロー履歴ログにある標準フィールドであり、記録されたすべてのイベントに関連付けられています。例 2023-05-15T10:22:00Z2023-06-02T14:05:30Z2024-01-10T11:00:00Z
	アクティビティ所有者 ActivityOwner	契約アクティビティの実行を担当するユーザーまたはリソースです。
説明この属性は、特定のアクティビティを実行した個人、チーム、または自動化されたユーザーを識別します。特定のユーザー名、従業員ID、またはシステムアカウントである場合があります。アクティビティオーナーの分析は、リソースの割り当て、ワークロードの分散、およびパフォーマンスを理解するために不可欠です。どのユーザーまたはチームがボトルネックになっているか、誰が最も効率的な審査員か、作業がどのように分散されているかといった質問に答えるのに役立ちます。これは「審査員ワークロード分散」ダッシュボードを直接サポートします。その重要性ユーザーまたはチームごとのパフォーマンス分析を可能にし、ワークロードの不均衡やトレーニング機会の特定に役立ちます。取得元この情報は通常、Icertis内のワークフロー履歴または監査証跡データで利用可能であり、各イベントにリンクされています。例 John SmithLegal.Review.QueueSystem.AutoApproveサラ・チェン
	契約ステータス ContractStatus	契約のライフサイクルにおける現在の状態または段階です。
説明この属性は、契約ケースの全体的なステータス（例：「ドラフト」、「審査中」、「署名待ち」、「実行済み」など）を示します。これは通常、到達した最後の主要なマイルストーンを反映するケースレベルの属性です。これは、「契約ステータスとスループット」のような運用ダッシュボードにとって不可欠であり、契約パイプラインのリアルタイムスナップショットを提供します。これにより、管理者は各ステージの契約数を理解し、作業が滞留している箇所を特定でき、契約ポートフォリオのプロアクティブな管理を可能にします。その重要性契約パイプラインの俯瞰的なビューを提供し、運用監視とスループット管理に不可欠です。取得元これはIcertisにおける契約合意オブジェクトの主要なステータスフィールドです。例下書き内部審査中実行済み終了済み
	契約形態 ContractType	マスターサービス契約や秘密保持契約など、契約の分類です。
説明契約タイプは、法的またはビジネス上の目的に基づいて合意を分類します。これは、契約ライフサイクルをセグメント化し、比較するための基本的な属性です。異なる契約タイプは、しばしば異なるプロセスパスをたどり、異なる複雑性レベルとSLAを持っています。契約タイプ別にプロセスを分析することで、NDAのような高ボリューム・低リスクの契約と、複雑で高価値のMSAのような契約に対して最適化されたワークフローを作成するなど、的を絞った改善が可能になります。これは「契約バリアント分析」および「ポリシーコンプライアンススコア」KPIにとって不可欠です。その重要性さまざまな種類の合意間でのライフサイクルとコンプライアンスを比較するためのプロセスセグメンテーションを可能にします。取得元これはIcertisにおける契約合意オブジェクトに構成されている標準属性です。例マスターサービス契約（MSA）秘密保持契約（NDA）作業範囲記述書（SOW）
	契約金額 ContractValue	契約の総金額です。
説明この属性は、契約の財務価値（総契約金額や年間化価値など）を表します。これは、契約を優先順位付けし、財務的影響を理解するための重要なビジネス指標です。プロセスマイニングにおいて、契約価値は分析をセグメント化し、高価値の合意に焦点を当てるために使用されます。例えば、高価値の契約が承認または交渉に時間がかかるかどうかを分析できます。また、高価値の契約の遅延は収益に大きな影響を与える可能性があるため、リスク評価にも役立ちます。その重要性優先順位付けと価値ベースの分析を可能にし、最も経済的に重要な契約に改善努力を集中させるのに役立ちます。取得元これはIcertisにおける契約合意オブジェクトの標準通貨フィールドです。例 50000.001250000.002500.00
	担当部門 OwnerDepartment	アクティビティの担当者が所属する部門です。
説明この属性は、アクティビティを実行したユーザーに関連する法務、営業、調達などのビジネス部門を特定します。プロセスにおけるリソースの関与を集合的に表示します。部門別に分析することは、部門間の連携と引き継ぎを理解する上で重要です。これにより、営業提出後の法務審査に長い時間がかかるなど、部門間のシステム的な遅延を特定するのに役立ちます。これは「部門間引き継ぎ遅延」ダッシュボードの焦点です。その重要性部門パフォーマンスと引き継ぎ効率の分析を促進し、部門横断的なボトルネックを明確にします。取得元このデータは、アクティビティオーナーをキーとして使用し、HRシステムまたはユーザーディレクトリと結合することで充実させる必要があるかもしれません。Icertisのユーザープロファイルに直接保存されている場合もあります。例法務営業調達財務
	終了日時 EndTime	特定の契約アクティビティが完了したことを示すタイムスタンプです。
説明この属性は、アクティビティの完了時刻を捕捉します。StartTimeが開始を示し、EndTimeが終了を示すことで、アクティビティの個別の期間が定義されます。開始時刻と終了時刻の両方を持つことは、各個別アクティビティの処理時間または期間を正確に計算するために不可欠です。これにより、どのステップが最も時間を消費しているかを分析し、アクティブな処理時間とステップ間のアイドル待機時間を区別することができます。「承認プロセスボトルネック」や「ドラフト作成と改訂の効率性」のようなダッシュボードにとって重要です。その重要性アクティビティ期間の正確な計算を可能にし、処理時間と待機時間の区別を助けます。取得元 StartTimeと同様に、Icertisの監査証跡またはワークフロー履歴ログに記載されています。一部のイベントは、StartTimeとEndTimeが同じ瞬時イベントである場合があります。例 2023-05-15T18:30:00Z2023-06-03T09:00:15Z2024-01-10T11:00:00Z
	SLAステータス SLAState	活動またはケースがサービスレベル契約（SLA）の条件内にあるかどうかを示します。
説明この属性は、特定のプロセスフェーズの期間を事前定義されたSLA目標と比較することで導き出されます。例えば、法務審査が標準の48時間リードタイムを超えた場合、「遅延」とフラグ付けされることがあります。 SLAステータスは、コンプライアンス監視とパフォーマンス管理に不可欠です。これにより、「契約コンプライアンス概要」のようなアラートやダッシュボードを作成でき、違反を即座に強調表示します。これはチームが期限切れのタスクを優先し、管理者が主要な目標に対するパフォーマンスを追跡するのに役立ちます。その重要性サービスレベル目標へのコンプライアンスを即座に可視化し、作業の優先順位付けとパフォーマンス管理に役立ちます。取得元これは、プロセスマイニングツールでビジネスルールを定義し、タイムスタンプを事前定義されたSLAしきい値（例：法務審査期間が2日を超える場合）と比較することで計算されます。例期日どおりリスクあり遅延
	ソースシステム SourceSystem	契約データが抽出されたシステムです。
説明この属性は、データの発生源を識別し、このプロセスでは「Icertis」です。特に複数のシステムからデータが集約される環境では、データガバナンスとトレーサビリティに役立ちます。分析では、データを特定のソースシステムにフィルタリングしたり、該当する場合は異なるシステム間のプロセスを比較したりするために使用できます。このビューでは、すべてのイベントの定数識別子として機能します。その重要性データリネージとトレーサビリティを保証し、データ検証と複数のソースからのデータ管理に重要です。取得元データの出所を示すために、抽出・変換の過程で付与される固定値であることが一般的です。例 IcertisIcertisCLM
	ビジネスユニット BusinessUnit	契約に関連する社内事業部門です。
説明この属性は、「北米エンタープライズ営業」や「グローバル調達」など、契約を所有またはリクエストした社内の部門または事業単位を識別します。部門と同様に、これによりプロセスデータをより高いレベルで集計できます。組織の異なる部門間のプロセス効率とコンプライアンスを比較するのに役立ち、上級管理職に貴重なインサイトを提供し、戦略的なリソース配分決定をサポートします。その重要性異なる組織単位間での高レベルのプロセスパフォーマンス比較を可能にします。取得元これはしばしば、契約合意上の主要なメタデータフィールドであり、組織構造にリンクしています。例北米事業部グローバルサービス製品開発
	最終データ更新 LastDataUpdate	プロセスのデータが最後に更新されたタイムスタンプです。
説明この属性は、分析されているデータの鮮度を示します。ソースシステムからの最終データ抽出日時を記録します。この情報は、ユーザーがダッシュボードに表示されるインサイトの適時性を理解するために重要です。リアルタイムの情報を見ているのか、数時間または数日前のデータを見ているのかを知るのに役立ち、意思決定のための適切なコンテキストを設定します。その重要性データの鮮度に関するコンテキストを提供し、ユーザーがプロセス分析の最新性を理解できるようにします。取得元このタイムスタンプは、各データ更新サイクルの正常終了時にデータパイプラインまたはETLツールによって生成されます。例 2024-07-27T08:00:00Z2024-07-26T23:59:59Z
	処理時間 ProcessingTime	アクティビティに実作業として費やした時間。
説明処理時間とは、アクティビティの開始時刻から終了時刻までの計算された期間です。これは、タスク間で費やされた待機時間とは異なり、リソースがタスクに従事していた実際の時間を表します。この指標は、パフォーマンス分析の基本となります。プロセス全体でどの特定のアクティビティが最も時間を消費しているかを特定するのに役立ちます。例えば、法務審査フェーズ全体は長いが、文書審査に実際に費やされた時間は短く、時間の大部分がキューで費やされていることを示すことができます。これは、ほぼすべてのダッシュボード、特にサイクルタイムと効率に焦点を当てたダッシュボードにとって不可欠です。その重要性実際の作業時間と待機時間を分離することで、効率改善のためのより正確な目標を提供します。取得元これはデータセット内の「EventTime」（StartTime）と「EndTime」属性から計算されます。例 2時間15分3日4時間30分
	取引先名 CounterpartyName	契約における顧客やベンダーなど、外部当事者の名称です。
説明この属性は、合意に関与する相手方を識別します。これは、相互作用と交渉を分析するための不可欠なコンテキストを提供します。相手方別にプロセスを分析することで、交渉サイクルのパターンを明らかにすることができます。例えば、特定のベンダーとの契約が常に交渉に時間がかかったり、より多くの改訂が必要であったりするかどうかを示すことができます。このインサイトは、戦略的関係管理や交渉戦略の調整に役立ち、「交渉サイクルタイムと手戻り」ダッシュボードを直接サポートします。その重要性特定の外部関係者との交渉パターンと関係パフォーマンスの分析を可能にします。取得元この情報は、契約のメタデータの一部として保存されており、通常はIcertis内の取引先またはベンダーマスターデータオブジェクトにリンクされています。例 Acme株式会社`Global Tech Inc.`Innovate Solutions LLC
	地域 Region	契約に関連する地理的地域です。
説明この属性は、EMEA、APAC、北米など、契約が適用される地理的地域を特定します。これは、プロセスに地域差があるグローバル組織にとって重要です。地域別に分析することで、現地の法律やビジネス文化に起因するプロセスパフォーマンス、コンプライアンス要件、または交渉戦術の違いを明らかにすることができます。これにより、地域固有のベンチマーキングや、グローバルに共有できるベストプラクティスの特定が可能になります。その重要性プロセスパフォーマンスとコンプライアンスの地域差を特定するのに役立ち、グローバル企業にとって極めて重要です。取得元これは通常、Icertisの契約オブジェクト上のメタデータフィールドであり、しばしば標準構成の一部です。例 EMEA北米APACLATAM
	改訂回数 RevisionCount	契約が受けた改訂の総数です。
説明この計算されたメトリックは、各契約ケースにおける「契約の朱書きまたは改訂」などの改訂関連アクティビティの数をカウントします。これはプロセス摩擦のシンプルで強力な指標となります。高い改訂回数は、要件の不明確さ、初期ドラフトの品質の低さ、交渉の困難さなど、ドラフト作成または交渉フェーズにおける潜在的な問題を示唆します。このメトリックは「契約改訂率」KPIへの直接的な入力であり、過度の手戻りを伴う契約やプロセスバリアントを特定するためにダッシュボードで使用されます。その重要性契約ライフサイクルにおける手戻りを定量化し、作成および交渉段階の効率性を直接測定します。取得元これはイベントログ内の各「ContractId」に対して、特定の改訂アクティビティの発生回数をカウントすることで計算されます。例 1503
	文書バージョン DocumentVersion	契約文書のバージョン番号です。
説明この属性は、契約文書がドラフト作成、朱書き、改訂を経ていく際のイテレーションを追跡します。通常、整数またはメジャー.マイナーバージョン番号で表されます。文書バージョンは、手戻りの直接的な指標となります。契約のバージョン数が多いことは、複数回の変更が行われたことを示唆しており、その根本原因を調査するために活用できます。これは「契約改訂率」KPIを計算するための主要なインプットであり、「ドラフト作成と改訂の効率性」ダッシュボードで使用されます。その重要性契約がどれだけ手戻りや改訂を経験したかを直接測定し、ドラフト作成や交渉の非効率性を浮き彫りにします。取得元 Icertisは、すべての契約文書のバージョン履歴を保持しています。この属性は、文書のメタデータまたはイベントログから抽出できます。例 1.02.34.00.5
	有効期限 ExpirationDate	契約が有効期限切れとなる日付です。
説明この属性は、契約期間の終了日を保存します。これは、契約の実行後のライフサイクルを管理し、更新または終了アクティビティをトリガーするための重要な日付です。この日付は、ライフサイクル終了管理の有効性を監視するために不可欠です。これは「期限内更新/終了率」KPIのベースラインとして機能し、更新または終了プロセスがタイムリーに開始および完了しているか、不要な自動更新やサービスの中断を回避しているかを測定します。その重要性契約の更新と終了を管理するために重要であり、ライフサイクル終了プロセスがプロアクティブに処理されることを保証します。取得元これはIcertisにおける契約合意オブジェクトの標準日付フィールドです。例 2025-12-312026-06-302024-08-15
	標準テンプレートである IsStandardTemplate	契約が標準の企業テンプレートから作成されたかどうかを示すフラグです。
説明このブール属性は、契約が事前に承認された標準テンプレートから作成されたものか、非標準のオーダーメイド契約として作成されたものかを示します。これはリスクとコンプライアンスを評価する上で重要な要素です。標準テンプレートに基づく契約は通常、サイクルタイムが短く、リスクも低いです。この属性は「契約テンプレート遵守率」KPIの基礎となり、非標準文書の使用がプロセスに与える影響を分析するのに役立ちます。これにより、標準から頻繁に逸脱する部門や契約タイプを浮き彫りにし、テンプレート使用の改善努力を導きます。その重要性企業標準への遵守度を測定し、これはプロセス効率とリスク低減に直接的に関連します。取得元これは契約上のチェックボックスフィールドであるか、またはIcertis内の文書の発生源やメタデータに基づいて導出される場合があります。例 truefalse
	義務履行期日 ObligationDueDate	特定の契約上の義務が履行されるべき期限です。
説明この属性は、契約が実行された後に定義された主要な義務、コミットメント、および成果物の期日を追跡します。単一の契約には、それぞれ独自の期日を持つ複数の義務が含まれる場合があります。これらの期日を追跡することは、実行後のコンプライアンスとリスク管理にとって極めて重要です。この属性は「義務遵守率」KPIの基盤であり、組織がコミットメントを期限内に履行しているかを監視し、潜在的な違反に積極的に対処することを可能にします。その重要性実行後のコンプライアンス監視を可能にし、罰則を回避し、良好なビジネス関係を維持するために不可欠です。取得元 Icertisには、義務管理のためのモジュールがあります。このデータは、契約に関連する義務から取得されます。例 2024-09-302025-01-152024-11-01

必須推奨任意

契約管理アクティビティ

これらは、契約ライフサイクルの正確な発見と分析のために、イベントログ内で追跡すべき主要なプロセスステップとマイルストーンです。

6 推奨 8 任意

	アクティビティ	説明
	内部承認取得済み	必要なすべての内部関係者が契約を承認し、外部交渉または署名のために準備が整ったマイルストーンを示します。これは、承認ワークフロー全体のステータスが最終的な「承認済み」状態に達したことから推測されます。
その重要性これは内部審査サイクルを締めくくる重要なマイルストーンです。「平均承認フェーズ期間」KPIを測定するための終点となります。取得元ワークフローのステータスが「完全承認済み」または類似の状態に変わったことから推測されます。これはすべての承認タスクが完了したことを示します。取得最終的な内部承認タスク完了または全体的なワークフローのステータス変更のタイムスタンプ。イベントタイプ inferred
	取引先の承認受領	このアクティビティは、外部の取引先が条件に同意し、契約の最終バージョンを承認したことを意味します。これは共同ポータルからの明示的なイベント、または契約担当者による手動ステータス更新の場合があります。
その重要性このマイルストーンは交渉フェーズを締めくくります。「平均交渉サイクルタイム」KPIを計算するための終点として機能し、外部とのやり取りの効率性を浮き彫りにします。取得元相手方がIcertisポータルを使用して承認した場合、これは明示的なイベントになり得ます。そうでなければ、「取引先承認済み」への手動ステータス変更から推測されます。取得取引先ポータルから記録されたイベント、または内部ユーザーによる手動のステータス更新です。イベントタイプ explicit
	契約リクエスト開始済み	このアクティビティは、ビジネスユーザーが正式に新しい契約をリクエストする、契約ライフサイクルの公式な開始を示します。これは通常、ユーザーがIcertisプラットフォーム内で契約リクエストフォームを送信した際の明示的なイベントとして捕捉されます。
その重要性プロセス開始として、このイベントは全体の契約サイクル時間を測定するために不可欠です。リクエストの量と種類を分析することで、リソース計画と需要管理に役立ちます。取得元これはIcertisで「契約リクエスト」オブジェクトが作成・提出された際にログに記録される明示的なイベントです。取得契約リクエストフォームの提出時にログに記録されたイベントです。イベントタイプ explicit
	契約終了または期限切れ	契約のライフサイクルが、能動的な解約プロセスまたは有効期限の到達によって終了する時点を示します。解約は明示的なイベントであり、有効期限切れは契約メタデータに基づいて計算されるイベントです。
その重要性これは契約ライフサイクルの終端イベントです。更新率を分析し、「期限内更新/終了率」KPIを測定するために重要です。取得元ユーザーが終了アクションを実行すると、終了イベントが明示的にログに記録されます。有効期限は、現在の日付を「有効期限日」属性と比較することで計算できます。取得システム日付と契約の有効期限を比較するか、手動の終了イベントから計算されます。イベントタイプ calculated
	契約締結済み	このアクティビティは、すべての当事者が署名した時点での契約の正式な実行を示します。これは署名前プロセスの主要な成功終点であり、電子署名プラットフォームとの連携を通じて捕捉されます。
その重要性主要な完了イベントとして、これは「平均契約サイクル時間」KPIのエンドポイントです。契約が法的に拘束力を持つ有効な状態になる瞬間を示します。取得元電子署名プラットフォームから明示的なイベントが受信され、すべての当事者の署名プロセスが完了するとIcertisに記録されます。取得電子署名プラットフォーム統合からのコールバックイベントです。イベントタイプ explicit
	法務審査実施済み	法務部門が契約の審査を完了したことを示します。これは通常、法務担当者が承認ワークフローで割り当てられたタスクを完了したときに記録される明示的なイベントです。
その重要性このアクティビティは、法務審査のリードタイムを測定し、法務チーム内の潜在的なキャパシティ制約を特定するために重要です。これは「法務審査待機時間」KPIをサポートします。取得元 Icertisワークフローで法務レビュータスクが「完了」とマークされたときに明示的にログに記録されます。「法務承認済み」のようなステータス変更から推論することもできます。取得ワークフローエンジンからのイベントで、「法務レビュー」タスクの完了を示します。イベントタイプ explicit
	修正契約開始済み	有効な契約を修正するための正式なプロセスの開始を表します。これは、ユーザーが元の実行済み合意にリンクされた修正記録を作成したときに捕捉されます。
その重要性修正は、大幅な手戻りや範囲の変更を意味します。その頻度とサイクル時間を追跡することで、契約の安定性と管理効率に関する洞察が得られます。取得元「Amendment」オブジェクトまたは類似のレコードが作成され、既存の契約に関連付けられたときに、明示的なイベントがログに記録されます。取得 Icertisシステムでの修正レコードの作成です。イベントタイプ explicit
	内部審査開始	このアクティビティは、内部審査および承認ワークフローの開始を示します。これは、契約ドラフトが部門長や財務などの内部関係者によって正式に審査のために提出された際に捕捉されます。
その重要性これは承認フェーズの開始を示します。このフェーズはしばしばボトルネックの原因となります。このイベントからの時間を分析することで、内部協力開始における遅延を特定するのに役立ちます。取得元 Icertisワークフローで「レビューのために提出」アクションがトリガーされたときに明示的なイベントとして捕捉されるか、またはステータスが「内部レビュー中」に変更されたことから推論されます。取得ユーザーが内部審査ワークフローを開始した際にログに記録されます。イベントタイプ explicit
	取引先との交渉開始	契約が外部の取引先に審査および交渉のために共有された時点を表します。これは、契約ステータスが「交渉中」に変わったこと、または文書が最初に外部に送信された際の監査ログから推測されることがよくあります。
その重要性このアクティビティは交渉フェーズの開始を示します。これは「平均交渉サイクルタイム」KPIを計算するための出発点となります。取得元ステータスが手動で「交渉中」に変更されたか、または文書が初めて外部ポータルを介して共有されたイベントを追跡することによって推測されます。取得ステータスが「交渉中」または「取引先へ送付済み」に変更された際のタイムスタンプ。イベントタイプ inferred
	契約更新済み	既存の契約が別の期間で正常に更新されたことを示します。これはシステム内で実行される明示的なアクションであり、多くの場合、新しい契約記録を開始したり、既存のものを更新したりします。
その重要性このアクティビティは、更新管理プロセスの有効性を評価するための鍵となります。これは「期限内更新/終了率」KPIを計算するために使用されます。取得元 Icertis内でユーザーが契約記録に対して「更新」アクションを実行したときに生成される明示的なイベントです。取得ユーザーが開始した「更新」トランザクションからログに記録されたイベントです。イベントタイプ explicit
	契約書に朱書きまたは改訂済み	このアクティビティは、内部審査中または外部交渉中に契約文書が変更されるたびに発生します。Icertisは文書のバージョンを追跡するため、チェックインされた新しいバージョンごとに改訂イベントとして捕捉できます。
その重要性契約ごとのこれらのイベントを数えることで、「契約改訂率」KPIを計算できます。改訂回数が多い場合、不明瞭な文言、非効率な交渉、または認識のずれを示唆する可能性があります。取得元 Icertisの文書管理モジュールに、契約文書の新しいバージョンがアップロードまたはチェックインされるたびに明示的にログに記録されます。取得新しい文書バージョン番号ごとにイベントが作成されます。イベントタイプ explicit
	契約書作成済み	テンプレートから、または新規ファイルとして、初期契約文書が作成されたことを表します。このイベントは、契約ワークスペースに関連付けられた主要契約文書の作成または最初のアップロードから推測されることがよくあります。
その重要性このアクティビティを追跡することで、初期ドラフト作成にかかる時間を測定できます。これはドラフト作成効率とテンプレート使用の遵守を分析するための重要なステップです。取得元 Icertis契約ワークスペースまたは合意オブジェクト内の主要契約文書の作成タイムスタンプから推測されます。取得主要契約文書の最初のバージョンの作成タイムスタンプを特定する。イベントタイプ inferred
	契約書署名のために送付済み	最終承認された契約が、電子署名または手書き署名のために送付されたことを示します。これはDocuSignやAdobe Signなどの電子署名プラットフォームとの連携を通じて捕捉される明示的なイベントです。
その重要性このイベントを追跡することで、最終実行ステップの効率性を分析できます。承認から署名送付までの遅延は、管理上のボトルネックを明らかにします。取得元 Icertis内から署名プロセスが開始されたときに、電子署名ソリューションとのAPI統合を介して明示的にログに記録されます。取得電子署名コネクタからのイベントで、署名リクエストが送信された時です。イベントタイプ explicit
	義務監視有効化	この実行後アクティビティは、契約上の義務とコミットメントがシステム内で追跡のために有効化されたことを意味します。これは通常、実行時に自動的に、または契約管理者によって手動でトリガーされる明示的なイベントです。
その重要性このイベントは、実行後管理の時計をスタートさせます。「義務遵守率」KPIを通じてコンプライアンスを測定し、確保するために重要です。取得元契約のステータスが「Active」または「Executed」になったときに、Icertis義務管理モジュールに明示的にログに記録されるイベントです。取得契約に関連する義務レコードの自動的または手動による有効化。イベントタイプ explicit

推奨任意

抽出ガイド

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

ステップ

Icertisレポートモジュールへのアクセス: Icertis ICIプラットフォームにログインします。メインアプリケーションメニューにあることが多い「Analytics」セクションまたは「Reporting」モジュールに移動します。レポートを作成および実行するには、適切なユーザー権限が必要です。
新規レポートの作成: 新しいレポートを作成するプロセスを開始します。レポートの主要ビジネスオブジェクトを選択します。契約管理の場合、これは通常「Contract Agreement」オブジェクト、またはコアとなる契約ワークスペースを表す同様のエンティティです。
レポートデータソースの定義: 必要なすべての情報にアクセスするために、関連するデータオブジェクトをレポートに追加します。バージョン管理の詳細には「Agreement Documents」、レビュー状況には「Approval Workflow」、ステータス変更には「Audit History」、実行後のアクティビティには「Obligations」などのオブジェクトを含めます。
レポートフィールドの選択: レポートの列を設定します。これは最も重要なステップであり、Icertisのフィールドを必要なイベントログ構造にマッピングします。各主要アクティビティに対して個別の行を生成するユニオンまたは複合レポートを作成する必要があります。各アクティビティの詳細なフィールドマッピングについては、「query」セクションで提供されている設定を参照してください。
アクティビティとタイムスタンプロジックの設定: 各アクティビティについて、「ActivityName」と「EventTime」の列を埋めるロジックを定義します。たとえば、「Contract Executed」の場合、「ActivityName」は静的テキスト値になり、「EventTime」は「Contract Agreement」オブジェクトの「Execution Date」フィールドにマッピングされます。ステータス変更から派生するアクティビティの場合、そのステータスが設定された時期を記録する対応する日付フィールドを使用します。
レポートフィルターの適用: 抽出の範囲を定義するフィルターを設定します。データセットを管理しやすくするために、たとえば過去6〜12ヶ月間の「Contract Creation Date」で日付範囲をフィルタリングすることが重要です。必要に応じて、「Contract Status」（例：ドラフトを除く）や「Contract Type」のフィルターを追加することもできます。
レポートの実行とプレビュー: Icertis UI内でレポートを実行します。最初の数百行をプレビューして、列が期待どおりに表示されているか、および同じ契約IDに対して異なるアクティビティが個別の行として表示されているかを確認します。
レポートのエクスポート: プレビューを確認したら、完全なレポートをエクスポートします。プロセスマイニングツールで簡単に取り込めるCSVをエクスポート形式として選択します。
データの結合とフォーマット（必要に応じて）: Icertisレポートツールがすべてのイベントを含む単一のレポート作成をサポートしていない場合、アクティビティタイプごとに個別のレポートを作成してエクスポートする必要がある場合があります。この場合、スクリプト言語やスプレッドシートアプリケーションなどの外部ツールを使用してレポートを垂直に積み重ね、すべてのファイルで列名が一貫していることを確認します。最終的な出力は単一のCSVファイルである必要があります。
アップロードの準備: 最終的なCSVファイルを確認します。ContractId、ActivityName、EventTime、EndTime、ActivityOwnerなど、必要な属性の列ヘッダーが一致していることを確認します。日付と時刻の値がISO 8601などの一貫した形式であることを確認します。これでファイルはProcessMindへのアップロード準備が整いました。

設定

前提条件: Icertis ICIプラットフォームへのアクセスと、契約合意および関連オブジェクトに関するレポート作成および実行を許可するユーザーロールおよび権限が必要です。
レポートタイプ: 複数の関連オブジェクト（合意、文書、ワークフロー、監査証跡）からデータを抽出し、単一のアクティビティログとして構造化できる複合レポートまたはユニオンレポートが必要です。これが不可能な場合は、複数の個別レポートが必要になります。
主要データオブジェクト: レポートは「契約合意」に基づいて作成し、「合意文書」、「承認ワークフロー」、「ユーザー」、および場合によっては「監査履歴」と結合して、必要なすべてのイベントタイムスタンプと詳細をキャプチャする必要があります。
日付範囲フィルタリング: エクスポートサイズとパフォーマンスを管理するために、常に日付範囲フィルターを適用してください。推奨される開始点は、過去6〜12ヶ月の「契約作成日」または「実行日」でフィルターをかけることです。
アクティビティフィルタリング: 特定のアクティビティがいつ発生したかを正確に識別するために、ステータスフィールド（例：「契約ステータス」、「承認ステータス」）に基づくフィルターを使用する必要がある場合があります。プロセスの全体像を把握するために、有効な契約と完了した契約の両方をデータスコープに含めるようにしてください。
フィールド選択: 必要なフィールドのみを明示的に選択してください。列が多すぎると、レポートの生成およびエクスポートプロセスが遅くなる可能性があります。イベントログに必要な属性と推奨される属性に焦点を当ててください。

a クエリ例 config

/*
 This is a configuration guide for building the extraction report in the Icertis Reporting Module UI.
 Icertis reports are configured through a graphical interface, not a script.
 Create a single composite report that generates one row for each of the following activity blocks.
 The common fields should be mapped for every block.

 Common Field Mappings:
 - ContractId: Map to 'Contract Agreement'.'ID' or 'Contract Number'
 - OwnerDepartment: Map to 'Contract Agreement'.'Owning Department'
 - ContractType: Map to 'Contract Agreement'.'Agreement Type'
 - ContractStatus: Map to 'Contract Agreement'.'Status'
 - ContractValue: Map to 'Contract Agreement'.'Contract Value' or 'Total Value'
*/

// Block 1: Contract Request Initiated
{
  "ActivityName": "Contract Request Initiated",
  "EventTime": "'Contract Agreement'.'Request Date'",
  "ActivityOwner": "'Contract Agreement'.'Created By'"
}

// Block 2: Contract Drafted
{
  "ActivityName": "Contract Drafted",
  "EventTime": "'Primary Agreement Document'.'Created On'",
  "ActivityOwner": "'Primary Agreement Document'.'Created By'"
}

// Block 3: Internal Review Started
{
  "ActivityName": "Internal Review Started",
  "EventTime": "'Approval Workflow'.'Workflow Start Date'",
  "ActivityOwner": "'Contract Agreement'.'Owner'"
}

// Block 4: Legal Review Conducted
{
  "ActivityName": "Legal Review Conducted",
  "EventTime": "'Legal Review Task'.'Completion Date'",
  "ActivityOwner": "'Legal Review Task'.'Assigned To'"
}

// Block 5: Contract Redlined Or Revised
{
  "ActivityName": "Contract Redlined Or Revised",
  "EventTime": "'Agreement Document Version'.'Created On'",
  "ActivityOwner": "'Agreement Document Version'.'Created By'"
}

// Block 6: Internal Approvals Obtained
{
  "ActivityName": "Internal Approvals Obtained",
  "EventTime": "'Approval Workflow'.'Workflow End Date'",
  "ActivityOwner": "'Approval Workflow'.'Last Approver'",
  "FilterCondition": "'Approval Workflow'.'Status' = 'Approved'"
}

// Block 7: Counterparty Negotiation Started
{
  "ActivityName": "Counterparty Negotiation Started",
  "EventTime": "'Contract Agreement'.'Negotiation Start Date'",
  "ActivityOwner": "'Contract Agreement'.'Owner'"
}

// Block 8: Counterparty Approval Received
{
  "ActivityName": "Counterparty Approval Received",
  "EventTime": "'Contract Agreement'.'Counterparty Approval Date'",
  "ActivityOwner": "'Contract Agreement'.'Owner'"
}

// Block 9: Contract Sent For Signature
{
  "ActivityName": "Contract Sent For Signature",
  "EventTime": "'E-Signature Package'.'Sent Date'",
  "ActivityOwner": "'E-Signature Package'.'Sent By'"
}

// Block 10: Contract Executed
{
  "ActivityName": "Contract Executed",
  "EventTime": "'Contract Agreement'.'Execution Date'",
  "ActivityOwner": "'Contract Agreement'.'Owner'"
}

// Block 11: Obligations Monitoring Activated
{
  "ActivityName": "Obligations Monitoring Activated",
  "EventTime": "'Obligation'.'Activation Date'",
  "ActivityOwner": "'Obligation'.'Owner'"
}

// Block 12: Amendment Initiated
{
  "ActivityName": "Amendment Initiated",
  "EventTime": "'Amendment Agreement'.'Request Date'",
  "ActivityOwner": "'Amendment Agreement'.'Created By'"
}

// Block 13: Contract Renewed
{
  "ActivityName": "Contract Renewed",
  "EventTime": "'Contract Agreement'.'Renewal Date'",
  "ActivityOwner": "'Contract Agreement'.'Owner'"
}

// Block 14: Contract Terminated Or Expired
{
  "ActivityName": "Contract Terminated Or Expired",
  "EventTime": "COALESCE('Contract Agreement'.'Termination Date', 'Contract Agreement'.'Expiry Date')",
  "ActivityOwner": "'Contract Agreement'.'Owner'"
}

ステップ

前提条件とセットアップ: Python 3.6以降とpandasおよびrequestsライブラリがインストールされていることを確認してください。Icertis管理者から、Client ID、Client Secret、およびIcertisインスタンスのベースURLを含むAPIクレデンシャルを取得してください。これらのクレデンシャルは、契約および監査ログデータへの読み取りアクセス権を持つユーザーまたはサービスアカウントのものである必要があります。
Pythonスクリプトの初期化: 新しいPythonファイルを作成します。必要なライブラリ（requests、pandas、json、datetime）をインポートし、IcertisベースURL、APIクレデンシャル、および抽出に必要な日付範囲のプレースホルダー変数をスクリプトの冒頭で定義します。
認証の実装: Icertis APIとの認証を処理する関数を作成します。この関数は、Client IDとSecretを受け取り、IcertisトークンエンドポイントにPOSTリクエストを送信してベアラートークンを取得します。このトークンは、その後のすべてのAPIリクエストのヘッダーに含める必要があります。
契約リストの取得: 指定した日付範囲内で作成または変更された契約のリストを取得する関数を作成します。これには、たとえば/api/v1/contractsなどの主要な契約APIエンドポイントにGETリクエストを送信することが含まれます。日付でフィルターするためにクエリパラメータを使用します。
ページネーションの処理: Icertis APIは、オブジェクトのリストを返すエンドポイントに対して結果をページネーションします。スクリプトはAPI応答で「nextLink」または同様のページネーショントークンをチェックし、すべてのページをループして契約の完全なリストを収集する必要があります。
契約履歴の反復と取得: 前のステップで取得した各契約IDについて、/api/v1/contracts/{id}/historyなどの詳細な履歴または監査証跡を提供するエンドポイントに個別のAPI呼び出しを行います。このエンドポイントには、プロセスマイニングに必要な生イベントデータが含まれます。
イベントとアクティビティのマッピング: これは主要な変換ステップです。各契約の履歴項目をループします。条件ロジック（if/elifステートメント）を使用して、APIからの生イベント記述をイベントログに必要な標準化されたアクティビティ名にマッピングします。たとえば、説明が「Status changed to Executed」であるAPIイベントは、ActivityName「Contract Executed」にマッピングされるべきです。
データの構造化: 各関連イベントを処理する際に、必要な属性（ContractId、ActivityName、EventTime）を含む辞書を作成します。また、契約マスターデータとイベントデータから抽出して、ActivityOwnerやContractTypeなどの推奨属性も追加します。
集計とDataFrameの作成: 各イベント辞書をマスターリストに追加します。すべての契約とその履歴を処理した後、この辞書のリストをpandas DataFrameに変換します。これにより、イベントログの構造化された表形式が提供されます。
最終フォーマットとエクスポート: DataFrameをクリーンアップし、すべての列が正しいデータ型、特にタイムスタンプであることを確認します。必要に応じてヌル値を処理します。最後に、to_csvメソッドを使用してDataFrameをCSVファイルにエクスポートし、index=Falseを設定します。このCSVファイルはProcessMindへのアップロード準備が整いました。

設定

APIクレデンシャル: APIユーザーまたはサービスアカウントが必要です。このアカウントには、関連するすべての契約タイプにおける契約オブジェクト、関連文書、および契約の完全な監査履歴に対する読み取り権限が必要です。
日付範囲: スクリプトにはSTART_DATEとEND_DATE変数が含まれています。データ検証とパフォーマンス管理のため、3～6ヶ月のような短い範囲から始めることを推奨します。全履歴データをロードするには、スクリプトをバッチで実行する必要がある場合があります。
APIエンドポイント設定: スクリプトは、/api/v1/contractsや/api/v1/contracts/{id}/historyのようなプレースホルダーAPIエンドポイントを使用しています。Icertis APIドキュメントで正しいエンドポイントURLとバージョンを確認する必要があります。
アクティビティマッピングロジック: スクリプト内の生イベント記述を標準化されたアクティビティ名にマッピングすることは非常に重要です。このセクションは、Icertisインスタンスで構成されている特定のイベント記述、カスタムステータス、ワークフローに基づいてカスタマイズが必要になる場合があります。
レート制限: Icertisによって課される可能性のあるAPIレート制限に注意してください。スクリプトには、HTTP 429（Too Many Requests）応答に対する基本的なエラー処理を含めるべきであり、スロットリングが問題となる場合は、呼び出し間のスリープ間隔で強化することもできます。

a クエリ例 python

import requests
import pandas as pd
import json
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration: Update these placeholders --- #
ICERTIS_BASE_URL = class="hl-string">"https://[your-instance].icertis.com"
API_CLIENT_ID = class="hl-string">"[Your_Client_ID]"
API_CLIENT_SECRET = class="hl-string">"[Your_Client_Secret]"
class=class="hl-string">"hl-comment"># Date range for extraction (YYYY-MM-DD)
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-12-31"

class=class="hl-string">"hl-comment"># --- Main Extraction Logic --- #

def get_access_token():
    class="hl-string">"""Authenticates with Icertis and returns an access token."""
    class=class="hl-string">"hl-comment"># This is a representative authentication flow. Refer to Icertis documentation.
    auth_url = fclass="hl-string">"{ICERTIS_BASE_URL}/api/v1/oauth/client-credentials/token"
    payload = {
        class="hl-string">'grant_type': class="hl-string">'client_credentials',
        class="hl-string">'client_id': API_CLIENT_ID,
        class="hl-string">'client_secret': API_CLIENT_SECRET
    }
    try:
        response = requests.post(auth_url, data=payload)
        response.raise_for_status()
        return response.json().get(class="hl-string">'access_token')
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error authenticating: {e}")
        return None

def extract_icertis_data():
    class="hl-string">"""Main function to extract, transform, and save contract data."""
    access_token = get_access_token()
    if not access_token:
        print(class="hl-string">"Could not retrieve access token. Exiting.")
        return

    headers = {class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}'}
    event_log = []

    class=class="hl-string">"hl-comment"># 1. Fetch all contracts within the date range
    contracts_url = fclass="hl-string">"{ICERTIS_BASE_URL}/api/v1/contracts?search_created_date_from={START_DATE}&search_created_date_to={END_DATE}"
    all_contracts = []

    while contracts_url:
        try:
            response = requests.get(contracts_url, headers=headers)
            response.raise_for_status()
            data = response.json()
            all_contracts.extend(data.get(class="hl-string">'results', []))
            contracts_url = data.get(class="hl-string">'nextLink') class=class="hl-string">"hl-comment"># Handle pagination
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching contracts: {e}")
            break

    print(fclass="hl-string">"Found {len(all_contracts)} contracts to process.")

    class=class="hl-string">"hl-comment"># 2. For each contract, fetch its history
    for contract in all_contracts:
        contract_id = contract.get(class="hl-string">'id')
        contract_type = contract.get(class="hl-string">'contractType', {}).get(class="hl-string">'name')
        contract_status = contract.get(class="hl-string">'status', {}).get(class="hl-string">'name')
        contract_value = contract.get(class="hl-string">'monetaryValue')

        if not contract_id:
            continue

        history_url = fclass="hl-string">"{ICERTIS_BASE_URL}/api/v1/contracts/{contract_id}/history"
        try:
            history_response = requests.get(history_url, headers=headers)
            history_response.raise_for_status()
            history_items = history_response.json().get(class="hl-string">'results', [])
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching history for contract {contract_id}: {e}")
            continue

        class=class="hl-string">"hl-comment"># 3. Map history events to activities
        for event in history_items:
            activity_name = None
            event_time = event.get(class="hl-string">'timestamp')
            activity_owner = event.get(class="hl-string">'user', {}).get(class="hl-string">'name')
            owner_department = event.get(class="hl-string">'user', {}).get(class="hl-string">'department') class=class="hl-string">"hl-comment"># Placeholder field
            description = event.get(class="hl-string">'description', class="hl-string">'').lower()
            event_type = event.get(class="hl-string">'eventType', class="hl-string">'').lower()
            
            class=class="hl-string">"hl-comment"># --- Activity Mapping Logic --- #
            if class="hl-string">'request initiated' in description or class="hl-string">'created' in event_type:
                activity_name = class="hl-string">'Contract Request Initiated'
            elif (class="hl-string">'document uploaded' in description or class="hl-string">'draft created' in description) and event.get(class="hl-string">'version') == 1:
                 activity_name = class="hl-string">'Contract Drafted'
            elif class="hl-string">'status changed to' in description and class="hl-string">'internal review' in description:
                activity_name = class="hl-string">'Internal Review Started'
            elif class="hl-string">'task completed' in event_type and class="hl-string">'legal review' in description:
                activity_name = class="hl-string">'Legal Review Conducted'
            elif class="hl-string">'new version created' in description or class="hl-string">'document revised' in description:
                activity_name = class="hl-string">'Contract Redlined Or Revised'
            elif class="hl-string">'status changed to' in description and class="hl-string">'internally approved' in description:
                activity_name = class="hl-string">'Internal Approvals Obtained'
            elif class="hl-string">'status changed to' in description and class="hl-string">'in negotiation' in description:
                activity_name = class="hl-string">'Counterparty Negotiation Started'
            elif class="hl-string">'status changed to' in description and class="hl-string">'counterparty approved' in description:
                activity_name = class="hl-string">'Counterparty Approval Received'
            elif class="hl-string">'sent for signature' in description:
                activity_name = class="hl-string">'Contract Sent For Signature'
            elif class="hl-string">'status changed to' in description and class="hl-string">'executed' in description:
                activity_name = class="hl-string">'Contract Executed'
            elif class="hl-string">'obligations activated' in description:
                activity_name = class="hl-string">'Obligations Monitoring Activated'
            elif class="hl-string">'amendment initiated' in description or class="hl-string">'amendment created' in description:
                activity_name = class="hl-string">'Amendment Initiated'
            elif class="hl-string">'renewed' in event_type:
                activity_name = class="hl-string">'Contract Renewed'
            elif class="hl-string">'status changed to' in description and (class="hl-string">'terminated' in description or class="hl-string">'expired' in description):
                activity_name = class="hl-string">'Contract Terminated Or Expired'

            if activity_name:
                event_log.append({
                    class="hl-string">'ContractId': contract_id,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventTime': event_time,
                    class="hl-string">'EndTime': event_time, class=class="hl-string">"hl-comment"># For point-in-time events, EndTime is the same as EventTime
                    class="hl-string">'ActivityOwner': activity_owner,
                    class="hl-string">'OwnerDepartment': owner_department,
                    class="hl-string">'ContractType': contract_type,
                    class="hl-string">'ContractStatus': contract_status,
                    class="hl-string">'ContractValue': contract_value
                })
    
    class=class="hl-string">"hl-comment"># 4. Create and save the event log
    if not event_log:
        print(class="hl-string">"No events were extracted. The output file will be empty.")
        return

    df = pd.DataFrame(event_log)
    df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'])
    df[class="hl-string">'EndTime'] = pd.to_datetime(df[class="hl-string">'EndTime'])
    df.sort_values(by=[class="hl-string">'ContractId', class="hl-string">'EventTime'], inplace=True)

    output_filename = class="hl-string">'icertis_contract_event_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%f%z')
    print(fclass="hl-string">"Extraction complete. Event log saved to {output_filename}")

if __name__ == class="hl-string">"__main__":
    extract_icertis_data()

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

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

契約管理属性

契約管理アクティビティ

抽出ガイド

Icertis ICIプラットフォームレポーティングモジュールのエクスポート

ステップ

設定

a クエリ例 config

Icertis REST APIを使用するPythonスクリプト

ステップ

設定

a クエリ例 python

今すぐ始めますか？

Icertis契約を変革：今すぐボトルネックを削減

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

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

契約管理属性

契約管理アクティビティ

抽出ガイド

Icertis ICIプラットフォーム レポーティングモジュールのエクスポート

ステップ

設定

a クエリ例 config

Icertis REST APIを使用するPythonスクリプト

ステップ

設定

a クエリ例 python

お客様のプライバシーを大切にしています

今すぐ始めますか？

Icertis契約を変革：今すぐボトルネックを削減

Icertis ICIプラットフォームレポーティングモジュールのエクスポート