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

はじめに

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

イベントを定義する

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

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

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

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

命名規則

アクティビティ名のベスト プラクティスは、「ドキュメントを作成」のように名詞 + 動詞の形式を使用することです。アクティビティの命名に関するアドバイスは、以下の表をご覧ください。

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

エンティティを定義する

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

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

イベント ログを定義する

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

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

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