ビジネスプロセスモデリングの実践の概要 (BPMN 2.0)

インターネット上には数百の定義がありますが、プロセスには開始と終了が必要であることに全員が同意できます。その過程で、完了すべきタスクがあります。昼食取得は日常的なプロセスですが、ビジネスプロセスではありません。このレッスンでは、ビジネスプロセスとその分析方法に焦点を当てます。

ビジネスプロセスは組立ラインのようなもので、タスクは最終製品を登録するためにさまざまなステージで完了します。

ビジネスプロセスモデリング表記法 (BPMN)。長年のプロセス開発および改善を対象としています。現在、これは世界中の企業におけるビジネスプロセスのモデリングの一般的な標準として知られています。これは、オブジェクト管理グループ (OMG) によって標準化された、プロセスモデリングのグラフィック表記 (シンボル/要素形状のコレクション) です。

BPMN 2.0 仕様は、OMG の公式 Web サイトからダウンロードできます。 https://www.omg.org/spec/BPMN/2.0.2/PDF

BPMN は、グローバルに受け入れられているモデリング表記法であり、さまざまな業種で使用されます (SAP Signavio では、これを必ず確認することができます)。お客様のビジネスプロセスはすべて異なり、さまざまなレベルの複雑性が含まれていますが、BPMN 2.0 には、手順を簡略化するための記号とモデリング要素のセットが付属しています。

導入が成功する正当な理由は以下のとおりです。

• プロセスモデリング要素の広範な選択

  EPC (ARIS からのイベント駆動型プロセスチェーン) などの他の表記と比較して、BPMN では、プロセスの特定のシナリオをモデル化するためのさまざまな要素が提供されます。たとえば、特定のイベントタイプ、外部主導の決定、より適切な責任の割当などです。

• 直観的

  BPMN プロセスモデルは自然にフロー指向であり、プロセスビューアは直感的に理解できます。これは、企業および従業員にとって重要な採用要因です。

• 実行可能

  BPMN プロセスモデルは BPMN XML として想定できます。BPMN XML は、仕様でも定義されます。このファイルは、SAP Signavio Process Governance などのプロセスエンジンによって実行されます。

• 国際標準

  国際的な ISO 標準化により、BPMN はグローバルに使用されており、大きなサポートコミュニティがあります。公式規範はISO/IEC 19510:2013である。

• 認定プログラム

  BPMN 2.0 を含む OMG による BPM の知識に関する認定を取得できます。

椅子の施工マニュアルが文章では書かれず、画像で説明されているのはなぜか。視覚的な指示が分かりやすくなるからです

受注から出荷プロセスの説明を読み、以下の質問を自問してください。

得意先から新規オーダーを受信すると、オーダーの受信が確認されます。顧客サービスチームは、可能な割引を計算してから、請求書の登録を開始します。一方、倉庫チームは商品の出荷を準備します。シップメントの優先度をチェックした後、商品は緊急出荷 (優先度の高いシップメントの場合) または標準出荷 (標準優先シップメントの場合) によって発送されます。商品が発送されると、出荷ステータスを追跡できるように、商品が出荷中であることを示す通知が得意先に送信されます。

1. いくつのタスクが表示されていますか。
2. プロセスにギャップはありますか。
3. いくつの責任がありますか。
4. 説明で取得されないその他の情報は関連しますか?
5. どこで意思決定を行う必要がありますか。

1. 目標: 得意先への受注の出荷
2. タスク: プロセスを完了するには、6 つのタスクを実行する必要があります。
3. 責任: 1 つの得意先、2 つの内部部門
4. 引き渡しとインタラクション: 2 つの内部引き継ぎ (倉庫への顧客サービス)。顧客に 4 回連絡します。
5. 決定: "シップメント優先度" に関する 1 つの決定が含まれます。

これは単純な例であり、ほとんどのビジネスプロセスはより複雑です。ただし、この単純なプロセスでは、プロセスを視覚的に表現することの重要性と真の力が強調されています。また、プロセスが複雑であるほど、プロセスの視覚化がより関連性が高いことを知っておくことが重要です。

次のセクションでは、BPMN プロセスモデルの要件を確認します。

毎日の通勤の地図を描きたいと想像してみてください。

あなたは、方向性を示すために建物、公園、場所、さらには他の要素も考慮する必要があることをすでに知っています。そのため、別の人がルートを理解します。たとえば、道路や橋などで正しく接続する必要があります。さらに重要なのは、接続に地名も含まれている必要があることです。最後に、ルートが明確に定義され、理解可能であるため、他のユーザもルートに従うことができます。

BPMN 2.0 によるビジネスプロセスモデルの作成には、多くの場合、組織内の多数の人が関与します。これにより、品質を維持し、全体にわたって標準を設定することの重要性が高まります。BPMN の形状と要素 (またはマップの例に類似) を把握しても、適切に設計されたプロセスモデルが自動的に生成されるわけではありません。場合によっては、サブプロセスなどで複雑さのレベルが隠されていたり、プロセスのパスを再編成してプロセスの知識を向上させたりする必要があります。

すべてのエレメントが正しく接続されている (構文的に正しい) 場合でも、タスクが正しい順序であるかどうか、またはロール/部門の名称が正しい (意味的に正しい) かどうかをチェックできません。整合性を確保するには、内部モデリング規則が必要です。たとえば、ロールとシステムに対して同じ用語を一貫して使用します。

実際には、特に複雑なビジネスシナリオをモデリングする場合、新しいビューアに対してプロセスモデルが理解しやすいようにすることは困難です。BPMN 2.0 は、さまざまなビジネスプロセスをモデル化するための幅広い要素を提供します。ただし、すべてのプロセスビューアがプロセスの図を見ることでこれらの要素を直感的に理解できるわけではありません。

これは、組織内の業務オペレーション、構造、およびプロセスの複雑さを指します。ビジネスの複雑さは、以下のようなさまざまな要因によって発生する可能性があります。

• あります。
• さまざまなチーム。
• グローバルオペレーション。
• 規制要件。
• ビジネスユニット間の複雑な相互依存性

ビジネスプロセス管理のコンテキストでは、モデル簡易とは、通常、ビジュアルモデルでビジネスプロセスを表す明確さ、理解しやすさ、および効率性を指します。シンプルなモデルは理解と保守が容易であり、関係者間のコミュニケーションが促進され、改善または最適化が必要な領域の特定が容易になります。

見積の登録および送信の一般的なプロセスについて説明するビジネスシナリオを見てみましょう。このシナリオには、問題が発生した場合に開始までループバックするレビュー、承認、およびプロセスが含まれます。

以下のプロセス例を使用します。

販売見積が顧客に送信される前に、販売品質チームが見積をレビューおよび承認する必要があります。承認された見積を顧客に送信した後のプロセスの次のステップは、顧客に委ねられます。

• 見積が受け入れられると、新しいサービスサブスクリプションが有効化されます。
• さらに交渉が必要な場合は、販売品質チームが調整済見積をレビューおよび承認する必要があります。これは、見積が再送信される前に行われます。そのため、プロセスの一部が繰り返されます。
• 得意先が見積を拒否すると、得意先に追加の照合が求められます。結果は、見積または実際の拒否に対する追加の調整です。

これは、前述のプロセスに基づくプロセス例です。プロセスフローを明確に把握できますか、それとも分かりにくいですか。すべての情報は正しく考慮されていますが、プロセスモデルは過負荷で混乱しているように見えます。これは、プロセス設計が適切に考慮されておらず、プロセスモデリングにおいて重要な役割を果たしているためです。

視覚的な問題につながるものは何ですか。

• スペースの浪費が多すぎる。
• タスクが整列されていません。
• シーケンスフローが整列されていません。
• シーケンスフローは相互に交差しています。
• オブジェクト使用フローとメッセージフローの組合せは、実際のプロセスフローから気をそらします。

実際のプロセスをモデリングし、使用フロー、データオブジェクト、IT システムなどの詳細をすべて表示しないことをお奨めします。プロセスフローは、ビューアが簡単にたどれる必要があります。

以下に、プロセス設計を改善する方法の例をいくつか示します。

• 可能な場合は不要なスペースを削除してください。
• 複雑なプロセスでの視覚的な分離を改善するには、色を賢く使用します。たとえば、成功したプロセス終了と失敗したプロセス終了などです。
• 詳細エレメントが必要な場合は、有用なヒントを追加して、他のビューアが読んで理解できるようにします。
• プロセスフローを横断することは避けてください。レーンを切り替えたり、可能な場合は再配置したりします。

詳細レベルと複雑さはターゲットグループによって異なるため、一般的な回答はありません。どの程度詳細である必要があるかを決定するには、以下の質問に答えてください。

• モデルのターゲットグループは誰ですか。たとえば、管理、分野別エキスパート、新規従業員などです。
• このターゲットグループの適切な詳細レベルは何ですか。たとえば、概要概要、コアタスク、詳細ステップなどです。
• モデルの目的は何ですか? たとえば、プロセス全体を理解したり、システム導入の詳細な説明を行ったりします。

必要な抽象化のレベル

異なるステークホルダに対応する必要がある場合、プロセスモデルを 1 つだけ使用することは困難です。実際には、必要な抽象化のレベルを決定する際に、プロセスについて考慮すべき点がいくつかあります。

• 概要ビュー
• 詳細ビュー

経営陣は、短い事実と起こっていることの概要に関心を持つ可能性が高いです。この大まかな概要は、プロセスに関連するロールに十分ですか。

セマンティックの不正確性または矛盾は、モデルが誤って解釈されるリスクを常に伴います。将来のモデルを作成し、それを技術的に導入するために IT 担当者に引き渡すと、このリスクは高くなります。

IT 関連のステークホルダ (特に技術実行チーム) は、通常、ビジネスプロセスを自動化したり、システムでビジネスプロセスをサポートしたりするために、より詳細な情報を必要とします。

実行のためにプロセスモデルをプロセスエンジンまたは ERP システムに直接フィードする場合、正確かつ一貫して正しくモデリングするしかありません。

ビジネスケースにとって重要なすべてのファクトが含まれるように、特定のターゲットグループに対して個別のモデルを登録する必要がある場合があります。

プロセスモデルの要件は、モデルおよび関係者の目的に応じて異なります。