変換の構造

概要

Process Mining アプリ テンプレートの変換手順の概要は以下のとおりです。

models\ フォルダーは、変換手順の構造に従って編成されます。

1. 入力

入力手順を使用して生データを読み込みます。通常は、次の操作を行って、データを次の変換手順用に準備します。

• 任意および必須のマクロが含まれるフィールドを選択します。任意のマクロが使用される場合、フィールドを生データに含める必要はありません。
• フィールドを適切なデータ型に型キャストします。

• テーブルをフィルター処理し、変換の早い段階でデータ サイズを減らします。

注: 可能な場合は、抽出時までにデータ サイズを減らしておくことをお勧めします。

命名規則

次の変換手順でテーブル名の競合が予想される場合のベスト プラクティスは、入力テーブルにサフィックス _input を追加することです。

2. エンティティ

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

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

ガイドライン

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

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

該当する場合、エンティティ テーブルは ID フィールドを介して別のエンティティに関連付けられます。 以下の例では、請求書明細行が Invoice_ID フィールドを介して請求書エンティティに関連付けられています。

その他の変換

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

命名規則

エンティティ テーブルの名前が後で競合する場合は、テーブルにサフィックス「_base」を追加します。

3. イベント

注: TemplateOne-SingleFile および TemplateOne-MultiFiles のアプリ テンプレートの入力データは、Process Mining 用に既にきちんと定義されたイベント ログです。ソース システムのデータを Process Mining のイベントにこの段階で変換する必要はありません。つまり、TemplateOne-SingleFile および TemplateOne-MultiFiles のプロセス アプリの変換には、「3. イベント」は存在しません。

この変換手順では、各エンティティに対してイベント テーブルを作成します。「イベント ログを定義する」をご覧ください。イベント テーブルの各レコードは、実行される 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] フィールドは、特定のイベントが完了したタイミングを示します。日付フィールドではなく日時フィールドであるのが理想的です。

命名規則

テーブルの名前は、[エンティティ] + _events の構造に従います (例:  Purchase_order_events、Invoice_events)。

4. イベント ログ

単一のエンティティ プロセス

プロセスに含まれるエンティティが 1 つである場合、このステップでさらに変換を行う必要はありません。単一のエンティティ テーブルと複数のイベント テーブルで既に正しい形式になっています。

複数のエンティティ プロセス

プロセスに複数のエンティティが含まれる場合、すべてのエンティティのイベントを、プロセスの「ケース」と見なされるメイン エンティティにリンクする必要があります。 詳細については 、「イベント ログを定義する 」をご覧ください。 以下の手順では、すべてのイベントをメイン エンティティに関連させる方法と、そのイベントを単一のイベント ログに結合する方法について説明します。

エンティティのリレーション

「entity-relations」テーブルを作成して、すべてのエンティティ間の関係を一元管理します。この entity-relations テーブルに、関連するエンティティの ID フィールドを格納します。

entity-relations テーブルを作成するには、すべてのエンティティ テーブルを ID フィールドに基づいて結合します。

• メイン エンティティから開始します。
• 関連するエンティティを左結合でメイン エンティティに結合します。
• エンティティがメイン エンティティに直接関連していない場合は、それらのエンティティを、既にメイン エンティティに結合されている関連エンティティに左結合します。

以下の例では、Purchase order、Invoice line、Invoice の 3 つのエンティティがあります。Purchase order はプロセスのメイン エンティティと見なされます。Invoice line は Purchase order に直接リンクされ、Invoice は Invoice line を介して間接的にリンクされます。

生成される entity-relations テーブルは以下のとおりです。

リレーション テーブル

メイン エンティティと他の各エンティティ間の個々のリレーションは、エンティティ リレーション テーブルの情報を結合して、別個のテーブルに保存されます。

イベント ログ

次の手順では、これらのリレーションを使用して、対応する「ケース ID」を各イベント テーブルに追加します。「ケース ID」はリレーション テーブルを介して取得し、イベント情報はイベント テーブルから取得します。完全なイベント ログを作成するために、各エンティティのイベント テーブルを和集合にします。

命名規則

イベント ログ テーブルの名前が後で競合する可能性がある場合は、イベント ログ テーブルの名前にサフィックス _base を追加します。

5. ビジネス ロジック

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

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

タグ

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

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

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

期限日

期限日はプロセスの期限を表します。期限日をデータに追加して、アクティビティが期限内に実行されているかどうかを分析します。

期限日テーブルの各レコードは、特定のイベントの 1 つの期限日を表します。期限日の例は次のとおりです。

• 支払イベントの支払期限。
• 承認イベントの承認期限。

このテーブルの必須フィールドは、Event ID、Due date、Actual date、Expected date です。

すべてのイベントに期限日が設定されているわけではありません。また、複数の期限日が設定されているイベントもあります。