« よしよし! | メイン | BPMオフ会 »

ビジネスプロセスパターン研究~BPMツールとは~

最近、かなりの数のBPMツールが登場してきて、まさに百花繚乱といった趣ですが、BPMツールというのはいったいどんなものなのかが明確には定まっていないようだ。

しかし、ぼくは別にこうでなくてはいけないと定める必要はないと思っているが、「ビリオネアの華麗なるIT」でそのことに言及しているので一緒に考えてみる。

その記事ではBPMツールの定義を「人やシステムが行うビジネスプロセスの管理・監視を自動化するためのソフトウェア」としている。うーんちょっと自動化するソフトウェアというのが気になる。

IBMなんかも、BPA(Business Process Automation)というような言い方をするが、以前、「自動化のワナ」というエントリーでも書いたのだが、“自動化”をあえて言うのはちょっと無理があるように思える。

ここは、軽く“BPMを実行するソフトウェア”でいいのではないだろうか。そうなると、BPMの定義をちゃんとしなくてはいけないのと、どこまでできるかはそれを導入する会社の成熟度によって変わるということをみておくことが大事である。

まずは、BPMの定義では、よく使われるガートナーと日本BPM協会のものをあげておく。

ガートナーの定義

「BPMとは、経営における俊敏性の改善やオペレーション上の業績改善といった経営目標を実現するために、ビジネスプロセス環境を統括していこうとする経営手法である。BPMとは、組織内のアクティビティやプロセスをマネジメントし、継続的に最適化させるための経営手法、施策、経営指標、経営慣行、ソフトウェアを利用した構造的アプローチである。」

日本BPM協会の定義

「企業活動の俊敏性・業績・コンプライアンスの改善といった経営目標の改善に向けて、ビジネスプロセスの改善サイクルを、人とITにより迅速に実現する新しいマネジメントの考え方・領域」

これらの定義から導かれるBPMSの機能はビジネスプロセスを管理・改善できるツールということになります。うーん難しそうですね。ただ、BPMには次に示すようなライフサイクルがあるということがわかります。

1. プロセスを作る
2. プロセスを動かす
3. プロセスを制御する
4. プロセスを維持する
5. プロセスを監視する
6. プロセスを改善する

では、実際のBPMSの機能にはどんなものがあるのでしょうか。一般にBPMS(BPM Suite)と呼ばれる製品が出回っていますが、その装備している機能はだいたい下記のものが含まれています。

■BPM実行エンジン
■プロセスモデラー
■シミュレーション機能
■組織モデラー
■ワークフロー機能
■ビジネスルール管理
■ソフトウェア開発
■システム連携機能
■プロセスモニタリング機能

「ビリオネアの華麗なるIT」ではつぎのようにしています。だいたい似てますね。

1. モニタリング(プロセス監視、イベント発生時の通知)
2. ワークフロー(プロセス定義、実行)
   1. モデリング(ビジネスプロセスの定義)
   2. プログラム呼出(プロセスからWebサービスなどのプログラムを実行)
   3. フロー実行(BPELなどで記述されたフローを実行)
3. EAI(システム統合)

ではこれらの機能とライフサイクルの関係を見ていきましょう。

最初のプロセスを作る段階では、プロセスモデラーや組織モデラーを使って設計します。それを単純に動かすのは、BPM実行エンジンです。そしてワークフロー機能で制御します。ここでツールにない必要機能はシステム開発します。

さらに業務ルール管理とシステム連携機能を使いプロセス全体をオペレーションします。そして、プロセスモニタリング機能で監視し、その結果から改善策を引き出し、シミュレーション機能で確認して、改善プロセスを再設計するということになります。

確かに、そうなのですが、一度にこんなことはできませんから、段階的にならざるを得ません。ざっくり言うと、最初は何でもいいからプロセスを動かしてみるということが重要ではないでしょうか。

ToBeモデルではなくてもいいから動かしてみると、自分たちの業務の動きが見えてきますし、何か改善の芽が出てくると思います。そこから発展させればいいのであって、最初からきれいにPDCAサイクルをまわそうというのはやめた方がいいと思います。

ということは言い換えると企業の成熟度に応じて導入していくことと同じだと言えます。これについても、以前「成熟度に応じたBPM導入」というエントリーをしているのでそれを見てください。

結局、何を言いたいかというと、BPMの最も大事なことはまずは自分たちのプロセスを動かすことなのです。ですから、ビジネスの実体をそのまま動かして、しかもそれをみなに共有的に見せることができるツールが最も望まれるでしょう。

極論すると、それができさえすれば、BPMSであろうとなかろうと、BPMNで書かれていようがいまいが、BPELで動こうがそうでなかろうが、どうでもいいように思うのです。

なぜなら、BPMはシステムを開発してナンボではなく、動かしてナンボ、すなわち、BPMライフサイクルがきちんと機能することが最大の目的だから、そうしたControl、Operation、Monitoringといったところにシステムのポイントが移っているからである。

ここも、ITを外してプロセス設計したあとの実現方法の議論として重要になるのでみなさんもよく考えてもらいたいと思うのです。
 

トラックバック

このエントリーのトラックバックURL:
http://kamawada.com/~masanori/blog/mt/mt-tb.cgi/962

コメント (1)

ビリオネアです。記事を取り上げていただき、ありがとうございました。

「BPMツールとは何か」ということを考えれば考えるほど、「BPMツールはあくまでもツールでしかないな」という思いが強くなっています。BPMを実践して業務プロセスを回していくことと、BPMツールを導入することは別物だと最近考えています。(ただ、完全に別物というわけではなくて、mark-wadaさんのおっしゃる「企業の成熟度」によってBPMツールと組織の関わり方がクロスオーバーしてくる部分はありそうです。この点は、個人的に今後の研究対象にさせてください。^^)

BPMツールありきでツールに合わせて業務を回すよりは、業務に合わせてツールを拡張していくことの方が本来は望ましい姿ですよね。ベンダーの立場としてはそのように製品をブラッシュアップしていけたらいいなーとも思っています。(一方で、ツールはツールとして割り切って使うという方向性もありだと思っていて、その方向性でのブログ記事も書きたいです。)

また、ツールの機能とか制約はいったん置いておいて、BPMを回していくための方法論や業務設計のあり方を模索していきたいというのも一つのテーマです。次回のBPP研に向けて、業務の構造化についてアイデアをまとめていきたいと思います。

コメントを投稿

(いままで、ここでコメントしたことがないときは、コメントを表示する前にこのブログのオーナーの承認が必要になることがあります。承認されるまではコメントは表示されません。そのときはしばらく待ってください。)

About

2009年03月30日 10:51に投稿されたエントリーのページです。

ひとつ前の投稿は「よしよし!」です。

次の投稿は「BPMオフ会」です。

他にも多くのエントリーがあります。メインページアーカイブページも見てください。

Powered by
Movable Type