- リリース ノート
- はじめる前に
- アクセス権を管理する
- 基本情報
- Integrations
- プロセス アプリを使用する
- アプリを作成する
- データを読み込む
- データ変換中
- ダッシュボードをカスタマイズする
- プロセス アプリをパブリッシュする
- アプリ テンプレート
- 通知
- その他のリソース

Process Mining
models\
[] フォルダーは、変換ステップの構造に従って編成されています。
イベント ログとカスタム プロセスのアプリ テンプレートのデータ変換の構造が簡素化されています。これらのアプリ テンプレートを使用して作成されたプロセス アプリは、このフォルダー構造を持ちません。
「オブジェクト」ステップでは、入力テーブルをオブジェクト・テーブルに変換します。予期されるイベントに必要なオブジェクトごとに専用のテーブルを用意する必要があります。「 イベント ログを定義する」をご覧ください。さらに、サポート オブジェクトもここで定義できます。
Invoices_input
、Invoice_types_input
、Customers_input
の 3 つの入力テーブルが結合され、オブジェクト テーブル「Invoices」が作成されています。
ガイドライン
オブジェクト テーブルを作成する際は、以下のガイドラインに従ってください。
- オブジェクト ID フィールドが 1 つあり、各データ レコードで一意である。
- データ分析に必要なすべてのオブジェクト フィールドが存在する。
- すべてのオブジェクト フィールドに分かりやすい名前が付いている。
Invoice_ID
フィールドを介して請求書オブジェクトに関連しています。
その他の変換
すべての入力テーブルがオブジェクト テーブルに変換されるわけではありません。また、他の入力テーブルに関連情報が含まれる場合もあります (この例では Customers テーブル)。オブジェクトの手順でそれらを別個のテーブルとして定義し、データ変換で再利用できるようにしておくと便利です。
命名規則
オブジェクト テーブルの名前が後で競合する場合は、テーブルにサフィックス「_base」を追加します。
この変換手順では、各オブジェクトに対してイベント テーブルを作成します。「イベント ログをデザインする」をご覧ください。イベント テーブルの各レコードは、実行される 1 つのイベントを表します。データを構造化する方法には次の 2 つのシナリオがあります。
- タイムスタンプ フィールド: イベントのタイムスタンプが付いたオブジェクト テーブルのフィールドです。たとえば、
Invoices
テーブルのInvoice_created
フィールドです。 - トランザクション ログ: イベントのリストです。
データがどのように構造化されているかによって、イベント テーブルを作成するための変換は異なります。
タイムスタンプ フィールド
このシナリオでは、タイムスタンプ フィールドの値をイベント テーブルの別個のレコードに変換する必要があります。以下の例は、3 つのタイムスタンプ フィールドを含む Invoices テーブルです。
各タイムスタンプ フィールドを使用して、別個のイベント テーブルを作成します。タイムスタンプ フィールドに値が含まれるすべてのレコードに対して、請求書 ID (Invoice ID)、イベントの名前 (Activity)、イベントが発生したタイムスタンプ (Event end) が含まれるテーブルを作成します。
Invoices_input table
は、Invoice_events_Create_invoice
、Invoice_events_Delete_invoice
、および Invoices_events_Change_invoice_price
に分割されます。
Invoices_events
)。
トランザクション ログ
イベントがトランザクション ログに保存されている場合は、オブジェクトごとの関連イベントを特定する必要があります。オブジェクトごとのテーブルを作成し、対応するオブジェクト ID、イベントの名前 (Activity)、イベントが発生したタイムスタンプ (Event end) を格納します。
以下のフィールドは、イベント テーブルで必須です。イベント テーブルのすべてのレコードに、これらのフィールドに対応する値が含まれる必要があります。
フィールド |
説明 |
---|---|
オブジェクト ID |
イベントが発生するオブジェクトの ID です。たとえば、Invoice ID です。 |
アクティビティ |
アクティビティでは、オブジェクトで発生したアクションを記述します。 |
Event end |
[Event end] フィールドは、特定のイベントが完了したタイミングを示します。日付フィールドではなく日時フィールドであるのが理想的です。 |
命名規則
[Activity] + _events
に従ってテーブルに名前を付けます。オブジェクトごとに 1 つのイベント ファイルを作成するには、[Object] + _events
に従って名前を付けます。たとえば、Purchase_order_approved_events
や Purchase_order_created_events
という名前にしたり、すべての発注アクティビティを 1 つのファイルにまとめて Purchase_order_events
という名前にしたりすることができます。
最後の変換手順では、データ分析に必要なビジネス ロジックが追加されます。ここでは、追加の派生フィールドを既存のテーブルに追加できます。たとえば、ダッシュボードの KPI で使用する特定のスループット時間フィールドや Boolean フィールドです。
Tags
と Due dates
があります。
タグ
タグはオブジェクトのプロパティで、特定のビジネス ルールを表します。通常は、ビジネス ルールを簡単に分析できるようにするためにタグを追加します。以下に例を示します。
- 請求書の支払と承認が同じユーザーによって行われている。
- 請求書の承認時間が 10 日を超えている。
- 請求書を確認するアクティビティがスキップされている。
Object ID
と Tag
です。すべてのオブジェクトにタグが付くわけではありません。一部のオブジェクトには複数のタグが付く可能性もあります。次の図に、Tags テーブルの例を示します。
イベントと同様に、データ モデルには複数のタグ テーブルが存在する可能性があります。
命名規則
[Tag] + _tags
、オブジェクトごとに 1 つのファイルを作成するには [Object] + _tags
構造に従ってテーブルに名前を付けます。たとえば、 、 Invoice_approval_too_late_tags
Invoice_approved_and_paid_by_same_person_tags
、またはすべての請求書タグが Invoice_tags
組み合わされた 1 つのファイルなどです。
期限日
期限日はプロセスの期限を表します。期限日をデータに追加して、アクティビティが期限内に実行されているかどうかを分析します。
期限日テーブルの各レコードは、特定のオブジェクトの 1 つの期限日を表します。期限日の例は次のとおりです。
- 支払の支払期限。
- 発注書の承認期限。
Object ID
、Due date
、Actual date
、Expected date
です。
イベントと同様に、データ モデルには複数の期限日テーブルが存在することができます。
命名規則
[Due date] + _due_dates
(期限日ごとに 1 つのファイルを作成するか、オブジェクトごとに 1 つのファイルを作成するには [Object] + _due_dates
) に従ってテーブルに名前を付けます。たとえば、 Payment_deadline_due_dates
、 Payment_deadline_with_discount_due_dates
、またはすべての請求書の期限日が Payment_due_dates
組み合わされた 1 つのファイルなどです。