BPMN 2.0の概要とビジネス・プロセス・モデリング
BPMNのビジネス・プロセス・モデリング
前回の図4（BPMIのBPMN開発コンセプト）で示した通り、ビジネス・プロセスのモデリング担当者は3つの職種に分かれます。ビジネス・アナリスト、プロセス・デザイナ、システム・アーキテクトです。
BPMN開発コンセプトでは、これら3者がそれぞれ担当する3つのステップでモデリングを段階的に実施することを想定しています（図5）。記述モデル、分析モデル、実行可能モデルの3つです。以下では、それぞれのステップについて解説します。
|
|
| 図5: BPMNを用いたプロセス・モデリングのステップ（クリックで拡大） |
記述モデル
記述モデルは、作業の流れの大枠を可視化したモデルです。このステップを担当するビジネス・アナリストとは、現場の業務に精通したユーザー部門の人を指します。カタカナで書くとコンサルタントのような肩苦しいイメージを持ちますが、日本ではラインの管理者や業務改革リーダーと言われる方々が想定されます。
ビジネス・アナリストが持っていなければならない知識には、以下のようなものがあります。作業の着手順番、作業を着手するタイミング、作業の難易度／求められる人の能力（専門性）／権限、組織の業務分掌、例外的処理、問題発生時の対処方法、業務ルール、などです。
記述モデルにおいて、BPMNを使ったモデルの記述は容易です。一般的なフロー・チャートで使っていた数種類（丸、矢線、長方形、ひし形、文書図形）の基本図形要素を覚えるだけで済みます。これらの図形を使い、"人の作業"と"システムの作業"の活動順序を、作業の流れとして記述します。
作業の難易度、専門性、権限を考慮しながら、作業を担当するロール（役割）をスイムレーン（Swimlane）として定義し、"人の作業"を、そのレーンにプロット（配置）します。このロールは、BPMでは極めて重要な概念です。図6に示す通り、ロールは組織／人とプロセスの関係を結ぶ独立したオブジェクトであり、組織／人とプロセスを疎結合にすることで、変化に強いモデルを実現します。
|
|
| 図6: 組織／人とプロセスの関係（クリックで拡大） |
モデルの記述では、「プロセスがどのようなイベント（きっかけ）で開始するのか」や「どのような成果をもってプロセスを終了するのか」を明記することも重要です。
プロセスは、情報や時間によって駆動されるのが一般的です。典型的な例として、見積もり依頼が顧客から要求された時点でプロセスを開始し、見積もり回答が顧客に回答された時点で終了する"見積もりプロセス"の例を、図7に示します。
見積もり依頼や見積もり回答などの情報は、文書図形のデータ・オブジェクトを使って表現します。プロセスの改善課題と改善目標が作業の流れのどの個所にあるのかを注釈図形を使ってコメントすることは、ユーザー部門の理解を得るうえで効果があります。
|
|
| 図7: 記述モデルの例（クリックで拡大） |
記述モデルは、次のステップである分析モデルを作成するためのスケッチとなります。記述モデルのモデリングの際にBPMNの表記にこだわる必要はありませんが、分析モデルの成果物をレビューするのに必要なモデル可読力を養ううえでは、BPMN表記を使用した方がよいでしょう。
分析モデル
分析モデルは、ビジネス・アナリストが作成した記述モデルを基に、プロセス・デザイナが作成します。分析モデルの作成はビジネス・アナリストとプロセス・デザイナの共同作業になりますが、主役はあくまでもプロセス・デザイナです。
プロセス・デザイナは、プロセス設計の専門家であり、現場の業務に精通している必要はありません。求められる能力は、作業の順序を論理的に組み立てられるシステム思考能力と、ビジネス・アナリストの間違いを素早く指摘して訂正できる、いわゆるツッコミの能力です。
ビジネス・アナリストが記述したモデルを検証しつつ、BPMNの主要な図形要素を駆使して例外処理や業務ルールを埋め込み、厳密なプロセスの意味（セマンティクス）を定義します。また、提示された改善課題や改善目標を達成するための方案をビジネス・アナリストと一緒に考え、複数のプロセス改善案をモデル化します。
プロセスを改善する具体的な方案には、以下のような定石があります。
- "人の作業"を"システムの作業"に変える。これにより、作業のスピード・アップを図り、人的リソースを軽減する。
- "人の作業"のうち、並行処理できる個所は、同時並行作業に変換する。これにより、プロセスの時間短縮を図る。
- 作業の手戻り（ループバックと呼ぶ）を最小限に抑えるよう、打つべき事前策を作業の流れに盛り込む。
- ロール間の作業移譲行為（ハンドオフまたはタッチポイントと呼ぶ）を最小にするよう、ロールの見直しや手順の見直しを行う。
分析モデルの例を、図8に示します。
|
|
| 図8: 分析モデルの例（クリックで拡大） |
プロセス・デザイナに求められる代表的な能力は、プロセス・モデルとして記述された作業の流れに論理的な矛盾がないかどうかを、BPMSのプロセス・エンジンに成り代わって検証する能力です。
分析モデルは、音楽の楽譜に例えると、メロディに相当します。演奏家（プロセス・エンジン）が演奏（実行）する際に、メロディ（分析モデル）を参照することで、何らかの音楽的内容（プロセスのセマンティクス）を理解できる必要があります。それだけの具体性が、メロディ（分析モデル）には必要です。
分析モデルの最終成果物には、高い詳細度が求められます。具体的には、プロセス・シミュレータを使って疑似的にプロセスを実行し、プロセスの所要時間や所要人的リソース、所要コストを分析できる必要があります。このような、シミュレータを使って複数のプロセス改善案からベストな案を選択する手法を、プロセス・シミュレーションと呼びます。
ただし、この段階では、"人の作業"も"システムの作業"も、ブラック・ボックスのままです。ユーザー・インタフェース画面の設計も、システム・ロジックの詳細設計も、行われていません。これらの設計作業は、次のステップである実行可能モデルで行われることになります。
