[この記事はプレリリース ドキュメントであり、変更されることがあります。]
オブジェクト中心のプロセス マイニング (OCPM) は、すべてのイベントを 1 つのケース ID に強制するのではなく、注文、配送、請求書、支払いなど、相互作用する実際のオブジェクトを追跡することでプロセスを分析します。 これにより、複数のオブジェクトやライフサイクルにわたるインタラクションの真の Web を確認できるため、ケース中心のプロセス マイニングでは隠されがちなボトルネックや依存関係を明らかにできます。
重要
- これはプレビュー機能です。
- プレビュー機能は運用環境での使用を想定しておらず、機能が制限されている可能性があります。 これらの機能を公式リリースの前に使用できるようにすることで、顧客が一足先にアクセスし、そこからフィードバックを得ることができます。
- 詳細については、条件のプレビュー を参照してください。
OCPM では、いくつかの一般的な用語を使用します。 用語に馴染みがない場合は、この記事の「用語集」セクションを参照してください。
オブジェクト中心のプロセス マイニングの重要性
実際のビジネス プロセスが 1 つの直線的なインスタンスとして流れることはめったにありません。 イベントは、異なるタイプの複数のオブジェクトに同時に接触する (たとえば、特定の注文の請求書の作成や、複数の注文のアイテムを含むパッケージの発送など) に日常的に接触します。 OCPM は、多くのオブジェクトとオブジェクト タイプに関連するイベントを 1 つのプロセスに記録し、それらの関係をエンド ツー エンドで保持することで、その現実をモデル化します。
注意
重要な考え方: OCPM では、"1 つのケースは 1 つのイベント シーケンスを意味する" のではなく、1 つのイベントが複数のオブジェクト (およびオブジェクト タイプ) に属することを可能にし、完全なコンテキストを維持します。
ビジネス プロセスの例
単純な小売業のシナリオを考えてみましょう。
- 顧客は 2 つの注文 (O1、O2) を行います。
- その店舗は、品目の補充のために 2 件の仕入発注 (SO1、SO2) を発行します。
- 1 つの仕入先注文が到着し、開梱されます。もう一方は更新が必要です。
- 店舗は 2 つの請求書 (I1、I2) を発行します。 1 つの請求書が更新されます。
- ストア ポリシーには "2 番目の顧客の注文は、請求書が支払われた後にのみ出荷する" と記載されています。
- 支払い (P1) を確認後、2 回目の注文を発送します。
この同じフローを使用して、OCPM とケース中心のプロセス マイニングを比較します。
OCPM がこのプロセスをモデル化する方法
OCPM では、各イベント (たとえば、請求書の作成、商品の受入、出荷オーダー、支払の記録) は、その時点で触れたオブジェクトにリンクできます (たとえば、注文 O1、請求書 I1、仕入先注文 SO1、支払 P1)。 次に、分析画面はオブジェクト中心のプロセス マップを表示し、以下を示します。
- オブジェクトのライフサイクル: オブジェクト タイプごとに開始/終了 (作成/破棄) マーカーを使用します
- 活動ノード: 1 つまたは複数のオブジェクト タイプに属することができます
- 活動間のオブジェクト フローエッジ: 多くの場合、オブジェクト タイプごとに色分けされているため、注文フローをたどり、同じマップ上で、請求書および支払いフローがどのように交差しているかを確認できます。
これにより、"請求書の支払いが完了した後にのみ O2 を出荷する" という重要な依存関係が維持されます。出荷注文イベントは、請求書を介して注文 O2 と支払い P1 に明示的に関連付けられており、すべて同じマップ上に存在するからです。
ケース中心のプロセス マイニングで同じプロセスをモデル化する方法
従来の (ケース中心の) プロセス マイニングでは、イベントが単一ケースの概念 (例: "受注 ID") でグループ化されます。これは強力であり、多くの場合これで十分ですが、このシナリオではトレードオフが生じます。
- ケースが注文の場合、注文のタイムラインに合わせて請求書イベントと支払いイベントを複製またはフラット化する必要があり、カウントが水増しされたり、どの請求書が本当にゲート配送されているかが不明瞭になったりする可能性があります。
- ケースが請求書または出荷の場合、注文ストーリーおよびクロス オブジェクト依存関係の一部が失われます (たとえば、注文 → 請求書 → 支払いにまたがる "支払後にのみ出荷" ルール)。
要するに、単一のケース タイプを強制すると、複数のオブジェクトの関係が隠されたり歪んだりする可能性がありますが、OCPM はそれらを明示的に保持します。 ケース中心のプロセス マイニングに関する一般的な入門情報については、製品概要を参照してください。
サイド バイ サイド: OCPM とケース中心
| Question | ケース中心 (ケース = 順序) | オブジェクト中心 (OCPM) |
|---|---|---|
| O2 のどの請求書と支払いが配送をゲートで処理しているかを確認できますか? | 可能ですが、結合/フラット化が必要であり、二重にカウントされたり、コンテキストが失われたりする可能性があります。 | はい。 イベントは、注文、請求書、支払いに同時にリンクします。ゲート ロジックは 1 つのマップで明らかです。 |
| 1 つのキャンバスでサプライヤーの補充と顧客の注文を分析するにはどうすればよいですか? | ケースの概念 (注文と仕入先の注文) を切り替えたり、オフラインでビューをマージしたりします。 | ネイティブ。 両方のオブジェクト タイプ (注文、仕入先注文) とそのタッチポイントを同じモデルに表示します。 |
| オブジェクトにまたがるポリシー ルール (「支払い後にのみ出荷」など) についてはどうでしょうか? | ログを結合しないと、エンド ツー エンドの検証が難しくなります。 | ファーストクラス。 オブジェクト間の依存関係は、フローが交差する場所に表示されます。 |
| データ シェイプ | インスタンスごとに 1 つのケース。イベントはそのケースに当てはまる必要があります。 | イベントは、複数のオブジェクト/タイプ (オブジェクト中心のイベント データ) に属することができます。 |
OCPM ソリューションの利点
以下に、OCPM の主な利点をいくつか挙げます。
- コンテキストの損失なし: 注文、請求書、支払い、出荷間の完全な関係を、イベントの重複やデータのフラット化なしに維持します。
- 複数オブジェクトのボトルネック分析: フローが収束したときに遅延が発生する場所を確認します (例: 請求書または仕入先注文における注文待機中)。
- オブジェクト全体の明確なガバナンスとコンプライアンス チェック: 本質的に複数のエンティティにまたがるポリシーを検証します (たとえば、出荷前の財務クリアランス)。
OCPM とケース中心のどちらを使用するか
OCPM は、次のシナリオで使用されます。
- イベントは、複数のオブジェクト (注文 - 請求書 - 支払いのチェーンなど) に定期的に接触するため、それらの相互作用を単一のマップ上で確認する必要があります。
- オブジェクトタイプ間の依存関係は、結果 (たとえば、支払を条件とする出荷、仕入先の納入を条件とする補充など) を促進します。
- カウントとパフォーマンスは現実を反映していなければなりません (複数のオブジェクトからなるイベントを 1 つのケースに統合することによって生じる重複したイベント/エッジを避ける)。
次のシナリオでは、ケース中心を維持します。
- 単一ケースの概念は明確に定義されており (たとえば、厳密に範囲が限定されたチケット発行ワークフローなど)、オブジェクト間の依存関係は最小限に抑えられている。
- あるプロセス インスタン スタイプ (たとえば、注文の作成から配送まで) を、分かりやすく順序立てて "レントゲンのように" 分析したいと考えており、データはまさにその分析に自然に適合します。
多くのチームはこの 2 つを組み合わせて、ケース中心から開始して、鮮明な単一インスタンスのビューを実現します。OCPM に移行するのは、重要な分析情報がオブジェクトの関係性にかかっている場合です。
データの詳細を見る
OCPM では、オブジェクト中心のイベント データを扱います。各行はイベント (活動とタイムスタンプを含む) であり、イベントが影響を与えたオブジェクト タイプごとのオブジェクト ID をリストした 1 つ以上の列 (例: Order=O2、Invoice=I1) があります。 この形式では、イベントとオブジェクト間のリンクが保持され、まさにオブジェクト中心のビューが可能になります。
用語集
- オブジェクト/オブジェクト タイプ: ビジネス エンティティ (例: 注文) とそのカテゴリ (例: 注文、請求書、支払い)。
- オブジェクト作成/廃棄ノード: OCPM マップ上のオブジェクトのライフサイクルの開始/終了を示すマーカー。
- オブジェクト フロー エッジ: 特定のタイプのオブジェクトが活動間を通常どのように移動するかを示す接続 (多くの場合、オブジェクト タイプによって色分けされています)。
- プロセス実行: 相互に関連するオブジェクト内のサブグラフを、先頭オブジェクトの単一のインスタンスから開始し、複数オブジェクト タイプのイベントで関連する他のオブジェクトを再帰的に調べるアルゴリズムを使用して処理します。 先行オブジェクト タイプの別のインスタンスが識別された場合、または既に調査されたオブジェクト タイプの別のインスタンスが識別され、先行オブジェクト タイプのインスタンスからの距離が以前に識別されたインスタンスよりも長くなると、再帰は停止します。