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

はじめに

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

イベントを定義する

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

The following illustration shows an example of an event log for the Invoices process.

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

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

命名規則

For activity names, the best practice is to use the Verb Noun format, such as Create document. The following table contains some advice on activity naming.

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

エンティティを定義する

The events take place on one or more entities in the process. Use the set of desired events to determine which entities are needed for a business process. The following illustration shows an example of a set of events and their corresponding entities.

各エンティティには、そのエンティティに固有のプロパティがあります。たとえば、発注書エンティティには purchase_order_type、請求書エンティティには payment_due_date があります。

イベント ログを定義する

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

In more complex processes, multiple entities can be of interest. For example, a Purchase-to-Pay process which starts with purchasing a product up to paying an invoice covers a set of events related to multiple entities. To create an event log for such processes, the relations between the entities have to be defined. The following illustration shows an example relationship diagram Purchase-to-Pay entities.

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