イベント ログをデザインする

はじめに

Process Mining 用の変換を設定する場合、プロセスについてよく理解しておくことが重要です。最初の手順は、発生するイベントと、そのイベントが発生するオブジェクトを定義することです。

イベントを定義する

価値の高いアクティビティの定義から始めます。アクティビティの発生頻度と、エンド ユーザーにとってのアクティビティの重要性に基づいて、アクティビティの追加に優先順位を付けます。アクティビティの定義は、反復プロセスである必要があります。

次の図に、請求書プロセスのイベント ログの例を示します。

1 つのプロセスを記述するためのアクティビティの理想的な数は 10 から 20 の間です。アクティビティが増えるほど分析の可能性が広がりますが、プロセスのバリエーションが増え、複雑度も高くなります。

アクティビティ数	結果
<10	分析の複雑さが低く、潜在的な改良点の数が少ない。
10-20	分析の複雑さと潜在的な改良点の数のバランスが最適である。
20	分析の複雑さが高く、細かい改良点の数が多い。

命名規則

アクティビティ名には、Create document などの動詞名詞形式を使用することをお勧めします。次の表に、アクティビティの命名に関するアドバイスを示します。

アクティビティ名	アドバイス	ベスト プラクティス
Order Order	あいまいなアクティビティ名を避けます。	Order material
Ticket	単数形のアクティビティ名は避け、何に対して何が発生したかを記述します。	チケットを作成
Document cancelled	受動態は避けます。	Cancel document
Approve credit control check on the sales order	長すぎるアクティビティ名は避けます。	Approve SO credit check

オブジェクトを定義する

イベントはプロセス内の 1 つ以上のオブジェクトで発生します。目的の一連のイベントを使用して、業務プロセスに必要なオブジェクトを決定します。次の表に、一連のイベントと、それに対応するオブジェクトの例を示します。

イベント	オブジェクト
発注書を作成	Purchase order
発注書を承認	Purchase order
請求書を作成	請求書 (Invoice)
支払い条件の変更	請求書 (Invoice)

各オブジェクトには、そのオブジェクトに固有のプロパティがあります。たとえば、発注書オブジェクトには purchase_order_type、請求書オブジェクトには payment_due_date があります。

イベント ログを定義する

プロセスで分析対象となるオブジェクトの数はプロセスの複雑さによって異なります。プロセスによっては、Incident Management プロセスのチケットなど、必要なオブジェクトが 1 つだけである場合もあります。

より複雑なプロセスでは複数のオブジェクトが分析対象になることがあります。たとえば Purchase-to-Pay プロセスです。この場合、製品の購買から請求書の支払いまでのプロセスに含まれる一連のイベントには複数のオブジェクトが関連しています。このようなプロセスのイベント ログを作成するには、オブジェクト間の関係を定義する必要があります。以下の画像は、リレーションシップ ダイアグラムの Purchase-to-Pay オブジェクトの例を示しています。

イベント ログには、全オブジェクトのイベントをカバーするエンドツーエンドのプロセスが記述されています。プロセス全体で追跡されるメイン オブジェクトとして機能できるのは、プロセス内の 1 つのオブジェクトのみです。このメイン オブジェクトには、プロセス内で「Case」という名前が付けられ、その「Case ID」で識別されます。