イベント - 有効化および応答

これまで、当社のプロセスには孤立した焦点がありました。プロセス開始時を除いて、得意先からのメッセージなどの外部入力を考慮したり、それに対応したりしませんでした。章全体では、イベントをプロセスフローの一部として使用し、ビジネス環境に対応することです。

イベントは、少なくとも開始時と終了時に、プロセスの状態を示します。BPMN 2.0 表記では、60 を超えるさまざまなイベントがカウントされるため、ビジネスプロセスモデリングでの重要性が強調されます。

イベントは、ビジネスプロセスが外部入力が適切に対応するのを待つ必要がある場所を示すために必要です。これらのイベントには、以下のものがあります。

• 顧客からの応答。
• 到達した時点。
• 承認された予算などの特定の条件。

イベントの世界を見ていく前に、イベント使用の背後に3つの側面があることを知っておくことが重要です。これらの側面は、イベント動作を理解し、正しく使用する際に役立ちます。

1. 開始イベント、中間イベント、および終了イベントがあります。イベントはどこで使用されますか。
2. イベントは、キャッチまたはスローイングが可能です。イベントの使用方法
3. イベントは、タイプ別に固有にすることができます。どのイベントが使用されますか。

プロセス内での発生に基づいて、イベントが開始イベント、中間イベント、および終了イベントとして分類されます。開始イベントと終了イベントはすでにわかっています。それらをレビューし、中間イベントについて詳しく見ていきましょう。

これらのイベントは、トリガを表すため、プロセスの開始時にのみ発生します。したがって、1 つの出力シーケンスフローのみを持つことができます。

中間イベントには、入力シーケンスフローと出力シーケンスフローが必要です。これらは、プロセスフローに影響を与えずにプロセスの状態をマークします。トークンは "通過" するだけで、ステータスを示します。

これが有用である理由空白の中間イベントを使用して、プロセスフローで特定の進捗 (マイルストーン) を強調表示することができます。たとえば、

• ステージを "フェーズ 2 完了" としてマークします。
• 製造ステータス "構成品目 X 製造済" をマークします。

このイベントは、プロセス目標を表すため、プロセスの終了を示します。したがって、入力シーケンスフローのみを持つことができます。

一部のプロセスでは、特定のマイルストーンに達したときにステータスをマークすると便利です。プロセスが技術環境で適用される場合、さまざまなマイルストーン間の時間をより具体的に測定することができます。ただし、このようなマイルストーンは常にオプションです。これらの重要性は、プロセスで実際に説明している内容によって異なります。

イベントにより、プロセスはそれぞれの環境で柔軟に行動し、対応することができます。

これまで、不特定イベント (いわゆる "プレーンイベント") のみを使用しました。ここで、プロセストリガまたは終了イベントについてより具体的に説明します。イベントの指定がより具体的になる必要があるため、イベントがトリガされるのか、イベント自体がトリガであるのかは区別される必要があることを考慮する必要があります。

1. 開始イベント、中間イベント、および終了イベントがあります。イベントはどこで使用されますか。
2. イベントは、キャッチまたはスローイングが可能です。イベントの使用方法
3. イベントは、タイプによって指定できます。どのイベントが使用されますか。

すべてのイベントには 1 つの共通点があります。つまり、プロセスをトリガまたは終了する特定のステータスを定義します。しかし、イベントがこのような状態に到達するにはどうしたらよいでしょうか。以下の 2 つのオプションがあります。

1. イベントは、トリガされるために "待機" します (外部からのトリガを "捕捉" します)。
2. イベント自体はトリガです (トリガを外部に "スローします")。

これは、イベントをキャッチおよびスローするコンセプトです。これが理論的すぎる場合は、例を使用します。

開始イベントは、オーダーの到着時にプロセスを開始するために、常に "待機中" ステータスです。これにより、トリガが "捕捉" され、プロセスが開始されます。

終了イベントがトリガを "スロー" し、ステータスを設定しました。

キャッチングイベントは、プロセスフローに影響します。以下のことが可能です。

• プロセスがトリガされたときに、プロセスを開始します。
• プロセスフローがトリガされたときに続行します。

スローイングイベントは、プロセスの最後にトリガすることができます。

とてもいい。かなり理論的な 2 つの側面を念頭に置いて、最終の側面に取り組むことができます。幸い、これは視覚的であり、新しい BPMN 要素を学習します。

すべてのイベントは、実際の性質に基づいて指定することができます。時間内に応答することができ、メッセージまたはその他の外部条件によってトリガされます。現実の世界では、すべてのイベントがトリガとなるわけではなく、外部の影響によってトリガされるわけでもなく、イベントタイプによって異なります。

ほとんどのビジネスプロセスでは、外部参加者との通信がプロセスの重要な部分です。ただし、用語および記号 "message" は、レター、電子メール、または電話に限定されません。メッセージイベントは、受信または送信可能なすべてを表します。通常、"インタラクション" を表します。

BPMN は、メッセージを受信するか送信するかに応じて、4 つの異なるメッセージイベントをカウントします。

ピザの受信はメッセージイベントによって示され、メッセージイベントを使用してモデル化する必要があります。それ以外の場合は、ピザが注文された直後に「ピザを食べる」タスクが開始されます (時間切れなし)。

したがって、以下を表すためにメッセージイベントが必要です。

• 注文と食事の間には待った状況がある。
• このプロセスは、ピザが到着すると続行されます。つまり、外部条件 (受入ピザ) が真になるまでプロセスフローが停止されます。

中間スローイングメッセージイベントを使用して、オーダーが送信されたステータスをモデル化することもできます。状況「ピザオーダー送信済み」はタスクを意味するため、実際のタスク「オーダーの送信」は必ずしも必須ではありません。

スローイング中間メッセージイベントは、ピザを注文するタスクを暗示しています。

順序タスクとスローイングメッセージイベントのモデリングは誤りです。この場合、2 回オーダーします。

この例では、4 つの異なるメッセージイベントをすべて確認できます。

そのため、プロセスは新しいチラシを受け取ることから始まり、フィードバックの提供で終わります。

ここでは、メッセージで以下の処理を行うことができます。

1. プロセスを開始します。たとえば、他のトリガを使用します。
2. プロセス内で送信されます。
3. プロセスの実行中にプロセスを遅延させます。
4. プロセスを終了し、他のプロセスをトリガします。

タイマーイベントは、柔軟に使用できるため、BPMN による実用的なモデリングでよく使用されます。これは、固定、相対、または繰返時点でプロセスを開始するために使用することができます。

タイマーイベントはプロセスによってトリガできないため、常に "捕捉" します。

このルールの背景には、実際のロジックがあります。

1. プロセス自体は時間に影響しません。
2. プロセスは、現在または過去の時点にのみ対応することができます。

プロセスの開始が特定の時点に依存する場合は、タイマー開始イベントを使用する必要があります。時間基準開始の定義には、いくつかのオプションがあります。これは、間隔、固定時点、または特定のイベントに対する相対ポイントにすることができます。

タイマーイベントがどのように使用されるかを確認するために、ピザのプロセスを再度見てみましょう。

タイマー開始イベントを使用すると、夕食時にプロセスを柔軟に開始し、ピザを注文することができます。10 分後、ピザの入荷と食事を準備するためにテーブルの設定を開始できます。

そのため、プロセスは以下のとおりです。

• 特定の時点における時間ベースの開始。
• は 10 分遅れます。ただ、とにかくピザを待たなければならないので、この遅れは関係ない。

どちらにも、プロセスを開始または続行することが判明している時点が共通しています。

一部のプロセスは、外部条件に基づいて開始されます。これらの条件はプロセスの制御対象外です。つまり、条件が完全に満たされた時点では不明ですが、プロセスはその場合いつでもそれに対応することができます。これは、タイマーイベントに関して説明したものと同じ動作であるため、同じルールでもあります。

すべてが満たさなければならない条件ではないだろうか。はい。ただし、ピザの例では、プロセスに以下の 2 つの不確実性があります。これらの不確実性は、プロセスでは制御できません。

• オーブンが１８０度に達すると制御できない。
• ピザが燃えているときだけ、準備ができているかどうかはコントロールできない。

イベントとその充足の不確実性は、条件付きイベントの良い指標です。実際には、プロセスが条件に影響を与えない例が他にもいくつかあります。

1. 職務ポジションが空席になった場合 (採用プロセスをトリガするため)。
2. アイデアが利用可能である場合 (イノベーションプロセスをトリガするため)。
3. 在庫品目が最小数量に達した場合 (オーダープロセスをトリガするため)。
4. ほとんどの投票が利用可能である場合 (プロセスを続行するため)。

リンクイベントは、ある程度特殊なケースです。コンテンツに関しては意味がなく、技術的な構造要素にすぎません。シーケンスフローは 2 つのリンクで置き換えることができます。この側面は、特に異なるレーンにまたがる長いシーケンスフローによってモデルが読みにくくなる大規模なプロセスモデルで役立ちます。

コンテンツに関連する重要性はありませんが、ダイアグラム作成プロセスが容易になります。マッチングに従うには、適切な名前を順番に付けてください。

• プロセスダイアグラムを複数のページに分散する必要があります。リンクイベントにより、これらのさまざまなプロセスモデルをリンクし、"左から右" のナビゲーションを有効化することができます。
• 多数のシーケンスフローを持つプロセスがあり、プロセス全体にわたる場合もあります。リンクイベントは、長いシーケンスフローを置き換え、プロセス設計を理解しやすくするのに役立ちます。

表に示すように、すべてのイベントタイプにすべてのイベントディメンションでオカレンスがあるわけではありません。反応性のみ（捕捉）、アクティブ（投げ）、さらには両方という彼らの性質によって異なる。たとえば、開始イベントはキャッチすることしかできないことを覚えておくかもしれません。

BPMN の一般的なイベントを知っているため、もう 1 つのイベント専門に焦点を当てます。これらは、タスクのキャンセル条件として使用することもできます。それはどのような仕組みですか? またピザの例を使おう。

添付されたタイマーイベント: タイマーイベントをキャンセル条件として使用します。

この例では、ピザを決めることができません。そのため、10分後に諦めて代わりにパスタを料理することにする。

つまり、中間イベント (タイマー) をタスクに添付すると、以下のようになります。

• 時間に基づいて取消条件を定義します。
• 取り消されたタスクの代替方法をモデル化し、プロセスを続行することができます。

ピザを選ぶという中止条件があれば、ピザをピザと呼ぶとピザが使えないこともあります。このプロセス例では、まだパスタを食べることができ、飢えないようにします。

要約:

• すべてのキャッチング中間イベントは、タスクのキャンセル条件として使用できます。
• 添付された中間イベントごとに、同じ代替パスが存在する必要があります。

これまでは、プロセスの一部として行われた決定を検討し、XOR ゲートウェイを使用して結果をルーティングしました。顧客またはその他の外部参加者が関与する場合は、プロセスを進める前にその決定に対応する必要があります。

BPMN には、このようなケースをモデル化するために使用される専用のゲートウェイ (イベントベースのゲートウェイ) があります。

現在のメソッドでは、捕捉メッセージイベントでプロセスがスタックします。要求した内容が得られなかったり、応答が全く得られなかったりした場合は、代替手段を検討して、プロセスが続行でき、行き詰まらないようにする必要があります (また、イベントを永久に待機します)。

イベントベースのゲートウェイは、プロセスフローを誘導する前に、以下の中間イベントが発生するのを待機します。どのイベントが最初に発生しても、ゲートウェイで取得されるパスです。決定はプロセス外で行われ、プロセスまたはイベントベースのゲートウェイがそれに応答します。

前の例では、まだピザを受け取っていない場合があります。どのくらい待てますか。以下のプロセスは、ループの終了をモデリングする方法を示しますが、ピザを受信する可能性は失われません。

具体的には以下のとおりです。

• ピザはいつでも受け取れる
• ピゼリアを3度呼ぶ方法がある。
• 3回（合計90分）電話でピザが手に入らなければ、出口があります。

イベントベースのゲートウェイは、イベントに対する "応答" 方式で動作するため、接続されたキャッチング中間イベントのみが存在します。続行するには、トークンは次のイベントが発生するのを待機します。

MyStore Inc. の管理は前のプロセスに不満であり、多数の注文がまだ支払われていないという問題にも直面しています。まもなく受注は、前払後にのみ出荷する必要があります。また、受注後に支払が不足している場合にも、プロセスが拡張されます。そのため、これらの新しい結果を考慮して、既存のプロセスモデルを再度調整する必要があります。

プロセスに以下の変更が反映されるように、既存のプロセスモデルを修正します。

オーダー受入部門は、以前と同様に請求書を作成しません。財務部門は請求書を登録して送信します。7 日以内に支払が受領された場合、倉庫は得意先に商品を送付し、財務部門は得意先への支払受領を確認します。顧客が支払を行わずに支払期間が 7 日経過すると、支払催促が送信されます。さらに 5 日経過しても支払が受領されない場合は、受注が取り消され、顧客に通知されます。

• プロセスの説明を準拠した BPMN 2.0 モデルに変換します。パート 1 の演習問題のモデルを使用および編集することをお奨めします。コピーを登録して、初期バージョンを保持することもできます。
• MyStore Inc. 社の観点から、すでに学習およびモデル化した要素のみを使用してください。外部プロセス参加者を含める必要はありません。

推定所要時間：約 45 分。

モデリングヒント 1: 2 つのイベントベースのゲートウェイを使用して、顧客の "反応" に基づいて発生するさまざまなイベントをキャプチャします。

モデリングヒント 2: この空白の形状モデルをデザイン方向として考えます。

終了したと思われる場合は、構文、セマンティック、および命名規則についてソリューションを再度確認してください。また、ダイアグラムのユーザフレンドリで読みやすいルックアンドフィールについて考えてください。

結果に自信がある場合は、サンプルソリューションを表示して、自分のソリューションと比較します。