本ウェブサイトでは、JavaScriptおよびスタイルシートを使用しております。
お客さまがご使用のブラウザではスタイルが未適応のため、本来とは異なった表示になっておりますが、情報は問題なくご利用いただけます。
2009年12月7日
前回は、ビジネスプロセスマネジメントの参画者と、作成するビジネスプロセスモデルの種類についてのお話でした。
その中で、ハイレベル・ミドルレベル・ローレベルという、3レベルビジネスプロセスモデルという考え方を示しました。
| 参画者（モデラー） | モデル名称 | 目的 |
|---|---|---|
| ビジネスアナリスト | ハイレベル | ビジネス環境の可視化・分析・改善 |
| プロセスデザイナ | ミドルレベル | 業務アサイン（ワークフロー）、 シミュレーション、モニタリング |
| システムアーキテクト | ローレベル | サービスオーケストレーション |
今回は、ハイレベル・ビジネスプロセスモデルを作成するポイントについて考察します。
ビジネスプロセスモデルを作成するときに、決まって問題となるのが「ビジネスプロセスをどこまで詳細に記述するのか」ということです。
例えば、
［注文を電話で受け付ける］
という作業をひとつのタスクとして表現するのか、
［電話で注文を聞く］→［メモをとる］→［注文画面に入力する］
という担当者の一連の作業をそれぞれのタスクとして記述するのか、という判断に悩むことがよくあります。
![[図] タスクの違い](images/cons_column02_03.gif)
こういった一つ一つのタスクが意味する作業の範囲（大きさ）を「タスクの粒度」と呼びます。
上記の例では次のように考えます。
ひとつのビジネスプロセスモデルの中では、タスクの粒度が揃っているほうが描きやすく見やすい、ということが経験的にわかっています。
タスクの粒度が大きいと、描くほうも読むほうも楽チンですね。
しかし、「販売する」というタスクを一個描いても、販売管理業務の可視化にも分析にもならないことは明らかです。
ハイレベルモデルはビジネスアナリストにより作成され、コンサルタントやビジネスユーザによってビジネス環境の分析を行い、ビジネスの手法やパフォーマンスの改善を目的としていることは前にお話しました。
つまり、「この目的に合致した粒度まで、タスクを細分化しないと駄目だ」ということになります。
では、すべてのプロセスを、担当者の一連の作業の粒度で描けば良いのでしょうか？
そんなことをやっていたら、モデリングの作業量が膨大なものになってしまうことはお分かりだと思います。
大切なのは、プロセスの粒度の基準を定める（標準化する）ことです。
そして、どうしても必要な業務に関してのみ、基準より小さい粒度のプロセスを描くことにすれば良いのです。
明確にタスクの粒度を定義できるものに「ハンドオフ」という概念があります。日本語で言うと「手渡し」を意味します。
一般的に企業におけるビジネスプロセスは担当者から担当者へ、また部署から部署へ渡されて進んでいきます。
この点に着目して、ハンドオフされてからハンドオフするまでの業務を、ひとつのタスクとして表現するのです。
日本UML推進協議会のBPMN研究会では、このプロセスの粒度によるビジネスプロセスモデルの階層を「レイヤ（層）」と呼んでいます。
| レイヤ名 | タスクの粒度 | モデルで表現すること | レーン | 他の作成手段 |
|---|---|---|---|---|
| プロセスマップ | End-to-Endプロセスを単位とする粒度 | End-to-Endプロセスの種類と、相関関係 | 設定しない | バリューチェーンタスク一覧表 |
| ハンドオフ | 役割間における責務、情報、物の移転を単位とする粒度 | プロセスの順序、実施条件、同時並行性 | 部門 または 担当 |
（なし） |
| マイルストーン | 業務アサインや、パフォーマンス測定を単位とする粒度 | 同上 | 担当 | （なし） |
| プロシージャ | 担当者の作業を単位とする粒度 | 作業の順序、実施条件、同時並行性 | 担当 | 作業手順書、産能式フローチャート |
ビジネスプロセスモデリングの準備作業としてプロセスの粒度の標準化を行う場合、まず「部門ハンドオフ」を基準として全てのタスクを定義することをお奨めします。
次回は、ハイレベルモデルにおける、他のレイヤについて考えてみたいと思います。
NECネクサソリューションズ
シニアコンサルタント 冨澤 雅彦
［日本UML推進協議会 BPMN研究会副主査］
