ホーム > プロセスモデリング, BPM, BPMN, SOA > BPMNは人のためか、ロボットのためか?

BPMNは人のためか、ロボットのためか?

BPMNはビジネスプロセスの表記法に過ぎないため、描き手のバックグラウンド、関心事の違いによって可視化したビジネスプロセスモデルは様変わりする。 同じ業務プロセスを可視化した場合、描き手によって「人中心のプロセス」と「システム中心のプロセス」に描き方が分かれてしまうのである。具体的な例示でその傾向を説明し、誤った使い方に警鐘を鳴らしたい。

図1は、一般的に描かれる承認プロセスを示している。このプロセスモデルは誰が、どのような手順で承認を得るか人の作業の流れ(ワークフロー)を示している。 BPMNを使った代表的表記例である。 


TasksOnly
  

図1: 人中心の承認プロセス

ところが、SOA志向のITエンジニアがBPMNを使ってビジネスプロセスを描くと、図2に示すように申請者、管理者(承認権限者)、仲介システムの3者コラボレーションプロセスで描いてしまうケースが見受けられるのである。特にBPELを使った経験のあるITエンジニアは、このような人とシステムのコラボレーションをプロセスモデルの表現に使っている場合がある(例図参照:ここ)。この図ではBPMNの表記ルールに従って解釈すると、申請者、管理者(承認権限者)とその2者を仲介する申請承認システム、3つのビジネスプロセスが独立して存在し、それぞれのプロセスから発信されるメッセージの送受信でそれぞれの活動が同期していることを表している。同じ承認プロセスの図1と比較してどう思われるだろうか?図2は現業部門の方から見るととても難解で、中段に表記した申請承認システムが申請者、管理者(承認権限者)の間に介入し、その関係を支配しているように見えるであろう。これは、ビジネスプロセス中の人対人の関わり合い(interaction)の調整作業にシステムを介入させロボット化した技術中心思考の産物と言えるものだ。私はある特例のビジネスプロセスを除いて、このようなシステム中心の設計をしてはいけないと考えている。なぜなら、これはユーザー視点のビジネスプロセスモデルではなく、BPMNの使用目的のひとつであるビジネスとITのコミュニケーションが達成できないからである。


TasksAndBytes
 

図2: システム中心の承認プロセス

人が介在しないビジネスプロセスのロボット化

株式決済プロセスに代表されるストレート・スルー・プロセッシング(STP: Straight Through Processing)と言われるプロセスパターンがある。これは、95%以上の活動がコンピュータで自動化され基本的に人が介在しないプロセスである。このパターンでは、例外が発生したときプロセスが本流から離れ、人の介入によりその例外が調整される。 図2の表現形式は、このSTPプロセスパターンでのみ許されもので、業務実行ロボットの内部プロセス仕様を表現するためには有効な手段といえる。

システム中心の表現形式が生まれる背景

図2の表現形式の描き手の多くは、BPELを使った経験のあるITエンジニアに見られると言ったが、何故なのか?私なりの見解を述べたい。

原因は2つあると考えている。

一つは、 BPMNで表記するスイムレーン、つまり活動の実行者あるいはロール(役割)がBPELでは定義ができない点にある。BPELでは、実行者は基本的にシステムが前提なので、実行の主体者をシステムにしていまい、活動の実行者あるいはロール(役割)はそれぞれ独立したプロセスを意味するプールで表現しそれぞれのプロセスがメッセージでコラボレーションしながら作業を進める表現になってしまうのである。二つ目は、 BPELはブロック構造のXML記述であるためループバック(差戻し処理)はDo-Whileで記述するしか方法がない点がある。そのため、差戻し処理は図3に示すループに書き換えざるを得ない。

 
DoWhile

図3: ループバックの書き換え

なお、人間系プロセスで頻繁に登場する図4で示すような交差ループバックはBPELでは記述できないので注意していただきたい。これは「
BPEL信奉者の落とし穴」である。 


DoWhile2

図4:  交差ループバック

結論

主題に「BPMNは人のためか、ロボットのためか?」というテーマを提起したが、「BPMNは双方のためにある」が私の結論である。ただし、BPMNは2つの目的によって使い分けねばならない。たとえば、ITを活用する業務システムの場合、図5に示すレイヤーで人中心のプロセス図とシステム中心のプロセス図に分割し、前者は現業部門の作業の流れを中心に表記した業務設計書として、後者はバックエンドのシステムのプロセス設計書(ロボット)として分けて考えよう。くれぐれも、人対人、人対システムの活動を図2の表現形式で記述し、BPELを適用するアプローチは避けたい。BPELのプロセスエンジンを提供するツールベンダーの中には、図4に示す交差ループバック問題に言及せず人中心のプロセスを自動化できるような営業トークをしているので注意が必要である。

  1. 人のため→人中心のプロセス図

    プロセス構成要素: 人対人、人対システムの活動

    適用プロセスエンジン: ワークフロー

  2. ロボットのため→システム中心のプロセス図

    プロセス構成要素: システム対システムの活動(STPプロセスパターン)。

    適用プロセスエンジン: SOA、BPEL


2レイヤー
  

図5: ビジネスとITのプロセスレイヤー分け

最後に

「BPMNは人のためか、ロボットのためか?」は、米国のBPM/SOA関連ブロガー間でも「BPMN for People and Robots」のテーマで次のように論議されていた。

ビジネスアナリストグループ:

プロセス図の目的は何で、何を可視化するか良く考えてほしい。多くのBPMツールがこのようなロボット図を描いている。理論的には詳細データの送信、受信を使ってモデル化できるが複雑になり、可視化のゴールを阻害する要因になる。システムとの情報伝達に関わる方法を隠ぺいし作業の役割、責任に着目しプロセスを描くべきだ。

デベロッパーグループ:

ロボット図面では業務担当者やビジネスアナリストと効率良くコミュニケーションできないことは承知している。チームの内にビジネスアナリストが不在でコミュニケーションする必要がなければ、デベロッパーはロボット図面を描いての良いではないか。

仲介者の決め言葉:

プロセス図は誰のためにあるのだろうか?デベロッパーにとって不可欠なのだろうか?プロセスはアナリストによって設計されるべきでと考えていないなら、答えは簡単だ。トラディショナルなプログラム開発には、BPMは必要ないよ!

岩田

広告
  1. 2009年7月15日09:51

    いつも興味深く拝見させていただいています。一点、これは私のいつも感じている疑問ですが、業務プロセスをBPMNで描くときはEnd-to-Endのプロセス(ひとつの業務のはじめから終わりまで。例えば受注から請求まで)を描くことになるので、人中心の部分とシステム中心の部分が混ざったプロセスになるように思います。私が描くときはそういうケースが多いのですが、実際にはどうなのでしょうか??
    なお、交差ループバックも等価な表現に変換するか、flowとlinkを使用することでBPELで表現が可能だと思います。もっとも、私はBPELを使用しますが、ワークフローにBPELは使用はしません。技術は適切な使い方が重要だと思っています。

  2. 岩田
    2009年7月17日13:54

    非喜子さん!コメントありがとうございます。
    >「人中心の部分とシステム中心の部分が混ざったプロセスになる….実際にはどうなのでしょう」
    とのご質問ですが、BPMN仕様はモデリング方法論までは示していないのでご指摘の点はBPMNに取り組む方々に共通する疑問でしょう。
    さて、BPMNはサービス指向アーキテクチャでアプリケーションを構築する前提のため、システムは「画面とロジックは分離されている」ことが基本になります。このためBPMNではタスクを7つの分類しています(見えてきたBPMN2.0の全貌(http://tech.jsys-soft.jp/iw…)の「アクティビティ・タスクタイプの追加とアイコン統一」を参照)。しかし、BPMN利用者は明確に使い分けていないのがUser、Service、Manual、Scriptです。この4つのタイプの特性は次のとおりです。
    <人のタスク>
    User:人対システムのユーザーインターフェイスを伴うタスク。データ入力、参照作業、決裁などのオペレーションを指す。BPMSはタスク完了の入力要求を必ず求め、業務パフォーマンスの測定対象にする。
    Manual:システムが関与しない人のタスク。BPMSは業務パフォーマンスの測定対象としないのでユーザーインターフェイスも存在しない。
    <システムのタスク>
    Service:人が介入しないシステムタスク一般を指す。
    Script:スクリプト言語で処理する動的タスク。サービス呼び出し側の処理。人の介入はない。
    人中心プロセスはUser、Manual、Scriptの3つのタスク、システム中心プロセスは、ServiceとScriptの2つのタスクで構成されるのが基本です。そして人中心プロセスとシステム中心プロセスを2つのプールに分けメッセージで呼び出し関係を示す方法がユーザーに分かりやすく、実装もしやすいと考えます。
    もし、「画面とロジックは分離されていない」レガシーアプリケーションを取り扱う場合、そのアプリケーションのユーザーインターフェイスをUserタスクに置き換え配置し、ワークフローを描きます。Userタスクとそれをさせるシステムの関連性を示したいならば、同様に2つのプールに分けメッセージで関連を示す方法をお奨めします。
    また、どうしても混在するなら、システム中心プロセスをサブプロセスに抽象化し図面を分け、システム中心プロセスの詳細をユーザーには隠ぺいさせる方法を使います。
    > End-to-Endのプロセス(ひとつの業務のはじめから終わりまで。例えば受注から請求まで)を描くことになる
    とのご意見ですが、プロセスの粒度が大き過ぎませんか?e-shopのオーダーフルフィルメントプロセスは、開始から終了までサイクルタイムが短く(最大でも1週間ぐらいと)、人の介入が少ないので1つのプロセスにできますが、一般的なオーダーフルフィルメントプロセスはサイクルタイムが長いこと(long term transaction)、受注、在庫引当、ピッキング、梱包などの各サブプロセスの起動イベントが異なることから分割するのが現実的と考えます。
    > 交差ループバックも等価な表現に変換するか、flowとlinkを使用することでBPELで表現が可能だと思います。
    可能でしょうが、BPELを駆使できるスキルはユーザーサイドにはないと思います。ビジネスプロセスをユーザーサイドで俊敏に変えられない環境はBPM推進の足かせになるような気がします。

  3. 2009年7月21日09:16

    返信いただきありがとうございます。ありがとうございます!
    >さて、BPMNはサービス指向アーキテクチャでアプリケーションを構築する前提のため、システムは「画面とロジックは分離されている」ことが基本になります。このためBPMNではタスクを7つの分類しています(見えてきたBPMN2.0の全貌(http://tech.jsys-soft.jp/iw…)の「アクティビティ・タスクタイプの追加とアイコン統一」を参照)。
    タスクのタイプで分類する方法は有効ですね。岩田さんもご存知だと思いますが、これまではARISのツールを使ってタスクのタイプを細かく分類する方法を採用していました。BPMN2.0の指針も睨みつつ、より良い記法を考えていこうと思います。
    >> End-to-Endのプロセス(ひとつの業務のはじめから終わりまで。例えば受注から請求まで)を描くことになる
    とのご意見ですが、プロセスの粒度が大き過ぎませんか?
    これは説明不足だったかもしれませんが、End-to-Endで大きなプロセスを描き、詳細度の階層に従ってブレークダウンする方法をとっていました。人もシステムも介在しますが、混在させてしまうと「わかりにくい」というご指摘を頂戴しやすかったかもしれません。分ける方法は重要ですね。「業務ユーザーとシステムユーザーが共有できる」という文言だけを追うのではなく、現実に上手に共有する方法を練磨しないといけないと思いました。
    >可能でしょうが、BPELを駆使できるスキルはユーザーサイドにはないと思います。
    おっしゃる通りだと思います。自分自身としてはBPELで業務プロセスを直に書こう、ということはお薦めしたことはありませんし、今後もお薦めするつもりはありません。既に多くの記事※で指摘を受けており、BPELは業務プロセスを(なるべく形を崩さず、そのまま)システム化する際の実装技術の候補のひとつだというのが個人的な見解です。
    一本一本の記事が非常に読み応えがあり、いつも大変、参考にさせていただいております。
    今後もお教えいただければ幸いです!
    ※ 例えば http://www.infoq.com/articl

  1. No trackbacks yet.

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中