ゲートウェイ - プロセスフローの制御

通常、ビジネスプロセスでは、必ずしもすべてのタスクが実行されるわけではありません。ほとんどのビジネスシナリオでは、決定は特定のケースでの処理方法を制御するプロセスの一部です。これらのシナリオは、明らかにプロセスモデルの設計および構造に影響します。つまり、まず、プロセスモデル内でシーケンスフローを異なるパスに分割する必要があります。

前のレッスンでは、イベントおよびタスクを使用して最初の独自のプロセスモデルを登録する方法を学習しました。必要性、飢えを表すスタートイベントと、食事を購入、準備、食事するいくつかの活動を結び付け、もはや空腹ではない満足感に達しました。

ただ、われわれが選んだ食事を用意して食べる方が、さらに満足できるものではないだろうか。

これまでの食事例をもとに、家庭で食料品が違って、おいしいものを作っていると仮定してみましょう。飢えに駆られ、何を食べたいか決定しなければならない。

専用ゲートウェイは、意思決定の結果（食事を選択）を読み取り、次のタスクへと導きます。プロセスフローは複数のプロセスフローに分割されていますが、一度に選択できるパスは 1 つのみです。

つまり、これはどちらか一方の決定です。

前の例で重要な要素が不足していることに気付いたかもしれません。食事の準備後にプロセスが終了したため、食べることはありませんでした。我々の当初の目標（空腹ではなくなった）は達成されなかった。より正確には、プロセスが完全にはモデル化されていません。

そのため、タスクを追加して、プロセスの終了時に空腹にならないようにします。

以前のソリューションでは少なくとも目標を達成できますが、プロセスの複雑さが増します。

• "食事" タスクは食事に依存しませんが、同じことがすべての異なる食事に適用されます。
• 分岐ごとに同じプロセス目標 (終了イベント) を複数回作成しました。

上記の問題を回避するには、すべての分割ブランチを元のプロセスフローとマージする方法を見つける必要があります。上記の図に示すように、排他ゲートウェイを再度使用することができます。マージに排他ゲートウェイ (XOR 結合) を使用します。

分割する場合は、マージします。

排他ゲートウェイ:

• には、特定の条件に基づいて、次の必要なタスクにルーティングするための分割動作があります。
• プロセス内のさまざまなブランチをメインフローと結合するために、マージ動作があります。
• はペアワイズで使用する必要があります。つまり、プロセスフローが XOR ゲートウェイで複数の分岐に分割されている場合、結合ゲートウェイも XOR ゲートウェイである必要があります。
• これには例外があります。シーケンスフローが別の終了イベントに移動する場合、分割ゲートウェイをマージする必要はありません。つまり、単一のパスは異なるパスに移動されるため、マージする必要はありません。

排他ゲートウェイは意思決定ではありません。なぜですか? これは、タスクではなく、以前に行われた決定の結果に基づいて次のタスクをルーティングするためのコントロールエレメントであるためです。

排他ゲートウェイ自体は決定ではありません。

食事選択は、XOR ゲートウェイでいずれかの送信パスを選択する前に完了する必要があるタスクです。

このプロセス例には決定があるように見えますが、実際には決定はありません。ゲートウェイは、情報に基づいて次のステップを制御するための手段にすぎないため、ステートレスです。タスクとは異なり、個人はゲートウェイを "所有" (責任者) することはできません。

上記のプロセス例を参照すると、これは以下を意味します。

• 実際の決定 (食事の選択) が欠落しているため、行われていません。
• 選択した食事の情報は、最初から "単に利用可能" ですが、プロセスの一部として決定されません。
• XORのゲートウェイはティムの車線にあるものの、ゲートウェイは単なるステートレスな楽器であるため、「ルーティング」の責任を負わない。さらに、ゲートウェイが配置されているレーンは関係ありません。次のタスクが割り当てられているユーザのみが重要です。

排他ゲートウェイの分割とマージを使用する場合に、プロセスがどのように適用されるかを見てみましょう。

タスクやイベントで見てきたように、BPMN の要素は、迅速かつ直感的に理解するために、特定の命名規則に従います。

XOR ゲートウェイ、およびプロセス内で結果/条件を処理する特定のゲートウェイには、命名規則もあります。これらは以下のとおりです。

1. 排他ゲートウェイには質問のラベルを付ける必要があります。
2. 出力条件 (シーケンスフロー) には、質問への回答のラベルを付ける必要があります。
3. すべての送信条件は、相互に除外する必要があります。たとえば、はい/いいえです。
4. ゲートウェイのマージにはラベルが付けられません。

タスクを並列で実行できるため、ビジネスプロセス全体の効率が向上します。

現在、ほとんどのビジネスプロセスには複数のタスクが含まれており、これらは異なる部門/従業員によって相互に独立して実行されます。このプロセスは、特定のタスクが実行された後にのみ、特定の時点を過ぎて続行することができます。このような動作をプロセスでモデル化するために、並列ゲートウェイ ("AND" ゲートウェイとも呼ばれます) を使用することができます。

前の例では、複数の料理を同時に選択して食べる選択肢はありませんでした。サラダをおかずとして欲しいとき、実際にどうするか。

サラダとステーキを食べられるようにするために、プロセスに並列ゲートウェイを追加しましょう。

AND ゲートウェイを使用する場合は、いくつかの考慮事項があります。

1. AND-Split：常に両方を用意し、食べなくてはなりません。選択肢はなくなりました。
2. ; AND-Join: 両方用意したあとでなければ食べ始められない。

提供されるプロセス例は、実行時間を記録するために使用した、タスクの BPMN 要素 (テキスト) アノテーションを示しています。テキスト注釈は、任意の BPMN 要素でいつでも有用なヒント/情報を提供するために使用できますが、プロセスモデルを過負荷にしないために、ほとんど使用しないでください。

実際にタスクを並列で実行する必要がある場合、プロセスを実行するリソースの数は重要になります。1 人が複数のタスクを同時に実行することはできません。これは、そのようにモデル化されている場合でも同様です。1 つの責任のみに並列タスクを割り当てる場合、実行順序は重要ではありません。より視覚的な説明を使用します。

Tim は単独で行動しています。

• Tim は、すべてを順番に実行する必要があるため、サイクルタイムを短縮することはできません。
• タスクが並列で割り当てられている場合でも、Tim は両方を同時に実行することはできませんが、少なくとも開始するタスクを決定することができます。

Tim は Robert のサポートを受ける:

• ティムはステーキが燃えないよう配慮するが、ロバートはその間にサラダを準備する。
• 両方のタスクが一緒に食事を始める前に、両方のタスクを完了する必要があります。

選択できるオプションが 1 つしかないため、ビジネスタスクに柔軟性が必要になることがあります。

通信プロバイダで働いており、顧客はインターネットと電話の主要契約に追加料金でさまざまな製品を追加することができます。これには、以下のものがあります。

• インターネットセキュリティパッケージ。
• Wi-Fi 接続を改善するための追加のルーター。
• 別のモバイルホットスポットでどこからでも接続できます

ビジネスプロセスは、選択したオプションのセットに基づいて、これらのオプションをすべて選択し、関連するビジネスタスクが実行されるように設計する必要があります。すべての顧客が契約に 3 つのオプションすべてを毎回追加するとは限らないため、これらを必須にすることはできません。また、異なる製品を常に組み合わせることができるため、排他的にすることもできません。

包含ゲートウェイ (OR ゲートウェイとも呼ばれる) では、前述の状況をモデリングすることができます。または、より具体的には、少なくとも 1 つのオプションを選択しながら、さまざまなオプションを組み合わせることができるビジネスシナリオをモデル化します。

このゲートウェイは、排他ゲートウェイと並列ゲートウェイの組合せとして動作するため、最も柔軟なゲートウェイです。

分割側では、1 つの出力シーケンスフロー (XOR など) のみをトリガすることも、複数の出力シーケンスフロー (AND など) を同時にトリガすることもできます。また、可能なすべての条件の一部のみを組み合わせたり、すべての条件を組み合わせたりすることもできます。柔軟性のこの側面は、プロセスモデルの OR ゲートウェイを見るだけで理解しにくい場合があります。ただし、特定のシナリオでは、ネストされた XOR ゲートウェイと AND ゲートウェイのセットを置き換えることが有用な場合があります。

マージ側では、OR ゲートウェイは異なるトークン (AND など) を同期するか、他のトークン (XOR など) がない場合はトークンだけを渡すことができます。特殊性は、すべての入力シーケンスフローのトークンを (AND と同様に) 待機せず、実際に進行中であるもののみを待ちます。

一部のプロセスでは、すべての担当ロールおよびペルソナを事前に把握していますが、他のプロセスについては、状況に応じて責任者が異なる場合があります。

以下のプロセスを見てみましょう。

• メンバー全員が一緒に食事を選ぶ（ただし、ティムはこのタスクのメインドライバーとして全員が一堂に会するようにしている）。
• 事例A：パスタとサラダを持つことに全員が同意します。ティムとロバートが 準備しなければならない
• ケース B の例: ステーキとサラダがあることに全員が同意します。サラとロバートが 準備しなければならない
• 例 C例：パスタを持っているだけで全員一致する。パスタの専門家として、ティムはグループのおいしいパスタ食の料理を担当する。
• 結局、ティムは全員で一緒に食べるようにしている。

以下のビデオでは、特定のケース (ステーキとサラダ) に基づいてトークンが作成される方法を示します。

ここで、ゲートウェイの不適切な組合せが使用された場合に発生する可能性がある一般的な誤りを詳しく調べます。

ゲートウェイの組合せが不適切であると、意図しないプロセスフローが発生する可能性があります。

ゲートウェイによる制御方法をすでに学習している場合、意図しないプロセスフローはどのようにして発生しますか。通常、パスの分割、フローの正しいマージ、ゲートウェイの使用、常にペア処理、および命名規則に従うルールを考慮する場合、これは行われません。しかし、特に複雑なビジネスプロセスをモデル化する必要がある場合、人間であり、間違いを犯すことによる学習は私たちの性質にあります。幸い、よくある落とし穴とその回避方法をご紹介できます。

トークンコンセプトは、不適切なプロセス動作の分析およびプロセスフローの修正に役立ち、トークンがプロセスにスタックしないようにします。

並列マージゲートウェイが複数のトークンの同期を待機しても、少なくとも 1 つのトークンが存在しない場合に、デッドロックが発生する可能性があります。奇妙に見えますか? 上記のプロセス例をチェックして、(誤って) これがどのように発生するかを確認してください。

説明:

• 並列分割ゲートウェイにより、2 つのトークンが登録されます (緑色のフロー)。
• トークン 1 は "出荷準備" を横断し、(同期するために) 並列マージゲートウェイに到着します。トークン 2 は、"顧客ステータスのチェック"、"プレミアムメンバーシップの提供" を横断し、(同期するために) 並列マージゲートウェイに到達します。

問題: 並列マージゲートウェイでは、すべての入力シーケンスフローでトークンが常に待機するため、3 番目のトークン (赤のフロー) が想定されます。残念ながら、このトークンは存在しないため、プロセスはこの時点でスタックします (デッドロック)。

この問題を解決するには、不足している排他ゲートウェイを追加して、2 つのシーケンスフローを 1 つに結合する必要があります。

マルチマージは、BPMN に関して必ずしもエラーではありませんが、通常は意図しないプロセス動作を作成します。これらは、複数のトークンが (1 つに) 同期されていない場合、つまり、並列マージゲートウェイがない場合に発生する可能性があります。

説明:

• 並列分割ゲートウェイにより、2 つのトークンが登録されます (緑色のフロー)。
• トークン 1 は "出荷準備" を横断し、排他マージゲートウェイに到着し、"オーダーの送信" に転送されます。トークン 2 は、"顧客ステータスのチェック"、"プレミアムメンバーシップの提供" を横断し、排他マージゲートウェイに到着し、"受注送信" に転送されます。

問題: 並列分割によって作成されたトークンを同期しない場合、タスク "送信順序" が 2 回実行され、終了イベントにも 2 回到達します。

この問題を解決するには、不足している並列ゲートウェイを追加して、プロセスの 2 つのトークンを 1 つに同期する必要があります。最終的にオーダーを送信するために、同期されたトークンが転送されます。

これは、SAP Signavio Process Manager で実行するアクティブなプロセスモデリングの演習問題です。すでにライセンスを持っている場合は、すぐに開始できます。そうでない場合は30日間の試用版を無料で登録し、3分後に開始することもできる。

このコースの 3 つのモデリング演習問題はすべてオプションではありません。ただし、この演習問題では、知識を応用し、SAP Signavio Process Manager のグラフィックエディタについて理解することができます。

e ラーニングコース SIG120 Introduction to SAP Signavio Process Manager がまだ完了していない場合は、グラフィックエディタを使用して演習問題を完了するために必要なすべてのスキルを取得してください。

30 日間のトライアルバージョンに登録して、SAP Signavio Process Manager をお試しください。クレジットカード/支払は必要ありません。リンク：登録

MyStore Inc. は、中規模のメール注文会社です。受注数が増加したため、経営陣は在庫から出荷までのビジネスプロセスを記録することを決定しました。また、内部プロセスに関する透明性の高い知識を提供することで、新入社員のオンボーディングの改善も期待しています。

MyStore Inc. が注文を受け取った場合、注文受入チームの従業員が最初に注文データを入力します。その後、得意先が注文請書を受信します。次に、倉庫チームの従業員が受注の出荷優先順位をチェックします。

得意先がプレミアムステータスの場合、商品は緊急出荷用に準備され、そうでない場合は通常の標準出荷用に準備されます。

シップメントのすべての準備が行われている間に、受注受入チームによって請求書が登録されます。最後に、受注受入チームによって請求書が得意先に送信され、倉庫チームによって受注が出荷されます。

• "オーダー処理" の説明を、準拠した BPMN 2.0 モデルに変換します。
• すでに学習した要素のみを使用し、MyStore Inc. のパースペクティブをモデル化します。外部プロセス参加者をまだ含める必要はありません。
• 推定所要時間：約 45 分。

モデリングヒント 1: プロセスをモデル化するには、少なくとも 1 つの XOR および 1 つの AND ゲートウェイが必要です。

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

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

準備ができたら、サンプルソリューションを表示し、それを独自のソリューションと比較します。