変換の構造

概要

次の図に、Process Mining アプリ テンプレートの変換手順を示します。

[データ変換] の [変換] セクションの models\ フォルダーは、変換手順の構造に従って編成されます。

注:

イベント ログとカスタム プロセスのアプリ テンプレートでは、データ変換の構造が簡素化されています。これらのアプリ テンプレートで作成されたプロセス アプリには、このフォルダー構造はありません。

1. オブジェクト

オブジェクトの手順では、入力テーブルをオブジェクト テーブルに変換します。予期されるイベントに必要なオブジェクトごとに専用のテーブルを用意する必要があります。「 イベント ログをデザインする」をご覧ください。さらに、サポート オブジェクトもここで定義できます。

以下の例では、Invoices_input、Invoice_types_input、Customers_input の 3 つの入力テーブルが結合され、オブジェクト テーブル「Invoices」が作成されています。

ガイドライン

オブジェクト テーブルを作成する際は、以下のガイドラインに従ってください。

• オブジェクト ID フィールドが 1 つあり、各データ レコードで一意である。
• データ分析に必要なすべてのオブジェクト フィールドが存在する。
• すべてのオブジェクト フィールドに分かりやすい名前が付いている。

これに該当する場合、オブジェクト テーブルは ID フィールドを介して別のオブジェクトに関連しています。以下の例では、請求書明細 (invoice_lines) は、Invoice_ID フィールドを介して請求書オブジェクトに関連しています。

その他の変換

すべての入力テーブルがオブジェクト テーブルに変換されるわけではありません。また、他の入力テーブルに関連情報が含まれる場合もあります (この例では Customers テーブル)。オブジェクトの手順でそれらを別個のテーブルとして定義し、データ変換で再利用できるようにしておくと便利です。

命名規則

オブジェクト テーブルの名前が後で競合する場合は、テーブルにサフィックス _baseを追加します。

2. イベント

注:

イベント ログとカスタム プロセスのアプリ テンプレートの入力データは、既に Process Mining 用に適切に定義されたイベント ログです。ソース システムのデータを Process Mining のイベントに変換する必要はありません。

この変換手順では、各オブジェクトに対してイベント テーブルを作成します。「イベント ログをデザインする」をご覧ください。イベント テーブルの各レコードは、実行される 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 に分割されます。

その後、別個のイベント テーブルをオブジェクトごとに 1 つのイベント テーブルにマージできます (例: Invoices_events)。

トランザクション ログ

イベントがトランザクション ログに保存されている場合は、オブジェクトごとの関連イベントを特定する必要があります。オブジェクトごとのテーブルを作成し、対応するオブジェクト ID、イベントの名前 (Activity)、イベントが発生したタイムスタンプ (Event end) を格納します。

以下の例では、トランザクション ログに Purchase Order オブジェクトと Invoice オブジェクトのイベントが含まれています。

イベント テーブルでは、次のフィールドが必須です。イベント テーブルのすべてのレコードに、これらのフィールドの値が含まれている必要があります。

フィールド	説明
オブジェクト ID	イベントが発生するオブジェクトの ID です。たとえば、Invoice ID です。
アクティビティ	アクティビティでは、オブジェクトで発生したアクションを記述します。
Event end	[Event end] フィールドは、特定のイベントが完了したタイミングを示します。日付フィールドではなく日時フィールドであるのが理想的です。

命名規則

アクティビティごとに 1 つのイベント ファイルを作成するには、[Activity] + _events に従ってテーブルに名前を付けます。オブジェクトごとに 1 つのイベント ファイルを作成するには、[Object] + _events に従って名前を付けます。たとえば、Purchase_order_approved_events や Purchase_order_created_events という名前にしたり、すべての発注アクティビティを 1 つのファイルにまとめて Purchase_order_events という名前にしたりすることができます。

3. ビジネスロジック

最後の変換手順では、データ分析に必要なビジネス ロジックが追加されます。ここでは、追加の派生フィールドを既存のテーブルに追加できます。たとえば、ダッシュボードの KPI で使用する特定のスループット時間フィールドや Boolean フィールドです。

Process Miningでは、この変換手順で定義される標準的な 2 つの追加テーブルとして、Tags と Due dates があります。

タグ

タグはオブジェクトのプロパティで、特定のビジネス ルールを表します。通常は、ビジネス ルールを簡単に分析できるようにするためにタグを追加します。以下に例を示します。

• 請求書の支払と承認が同じユーザーによって行われている。
• 請求書の承認時間が 10 日を超えている。
• 請求書を確認するアクティビティがスキップされている。

タグ テーブルの各レコードは、特定のケースのデータで発生した 1 つのタグを表します。このテーブルの必須フィールドは、 Object ID と Tagです。すべてのオブジェクトにタグが付くわけではありません。一部のオブジェクトには複数のタグが付く可能性もあります。次の図に、Tags テーブルの例を示します。

注:

イベントと同様に、データ モデルには複数のタグ テーブルが存在する可能性があります。

命名規則

タグごとに 1 つのファイルを作成するには構造 [Tag] + _tags 、オブジェクトごとに 1 つのファイルを作成するには [Object] + _tags 構造に従ってテーブルに名前を付けます。たとえば、 、 Invoice_approval_too_late_tagsInvoice_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 つのファイルなどです。