数年前からIT業界の中でキーワードになっていた「BPM(Business Process Management)」が、ユーザー企業側に浸透してきた。多様な製品がBPMを名乗る中、次世代BPMはさらに「人間系業務」に近づこうとしている。
ここ数年、IT雑誌やメディアで「BPM(Business Process Management)」という用語が聞かれるようになった。調査会社のガートナーによると、BPMとは「明確なプロセス管理(例えばプロセス分析、定義、実行、モニタリングおよび管理)をサポートするサービスあるいはツール」とし、そのプロセスの中には「人およびアプリケーション・レベルのインタラクションに対するサービスも含まれる」としている。一般的には、調達・製造・出荷・販売といったビジネスプロセスを統合・管理するITの仕組み/取り組みを意味する。ITですべてのフローが管理されているため、人的ミスが削減され、またプロセスの迅速化が図れるという利点がある。
BPMツールは複数の業務システムを統合・連携するもので、例えば「在庫の引当」といったイベントをトリガとして、ほかのシステムに通達・アラートを出すミドルウェアである。ERPやSCMパッケージのようにあらかじめビジネスプロセスが実装されているものではなく、自社のやり方に自由に合わせることができる。機能でいえば、大きく4つに分けられる。1番目に、メインフレームやパッケージ、自社開発システムなど各システム間をつなぐ通信機能のレイヤ。2番目に、データ変換を行うレイヤ。次に、「どういうイベントが起こったらどのシステムにどのような通知を出すか」というメッセージング用のプログラムレイヤ。最後に、システム全体の監視を行うモニタリングレイヤだ。
ちなみに前述のガートナーでは、BPMに必要な機能として(1)プロセスの分析・可視化を担うグラフィカルツール層、(2)定義されたプロセス・フローを実行するエンジン、(3)フローやワークリストの管理および優先順位を調整する機敏性機能、(4)フローの監視・管理機能、(5)1つのフロー完了後、分析を行うための機能の5つを定義しているが、この5つの機能を完全に備えている製品はほとんどない。例えば現状のビジネスプロセスを分析する場合には、専用のモデリングツールを使用するのが一般的だ。BPMツールに同梱されているドローイングツールは、プログラム実装のためのGUIツールとして使われるケースが多い。
BPMを分かりにくくしている原因の1つに、この多機能性が挙げられる。多様なベンダが「BPM」というキーワードを用いているため、製品のくくりが見えにくいのだ。大まかに分けると、(1)データ連携/アプリケーション連携(EAI)、(2)ワークフロー、(3)Javaアプリケーションサーバ、(4)ビジネスプロセス・モデリングなどのドローイングツール、(5)ポータルツールといった製品群が、「BPM」または「ビジネスプロセス連携」と銘打っている。特にEAIツールから派生した製品にこの傾向が強い。もともと「アプリケーション間連携」を標ぼうしていた製品なので、メッセージングやデータ連携機能に強いという特徴があるからだ。接続するシステムの環境が違っても、両方のシステム側に何らかのアドオン開発を施す必要はなく、すべてツールが吸収する。そのため、開発工数もコストも削減できるというメリットがある。
|
||||||||||||
表 系統別BPMツールの特徴 |
またJavaアプリケーションサーバの動きも見逃せない。Java APIが進化し、Javaを介したアプリケーション連携が現実的になってきたことで、アプリケーションサーバによるBPMも注目されている。最大の特徴は、業務アプリケーションそのものを構築できる点だ。例えば、最適なBPMのためにアプリケーションのリプレースが必要ならば、アプリケーションサーバを導入すれば、BPMも新規アプリケーションの問題も両方解決できる。ただし「Java APIによるアプリケーション連携は、接続するシステム側にも受け口を用意しなければならないほか、実行速度も改善の余地がある」という声もある。
BPMが取り上げられてきた背景には、2つの理由が考えられる。
1つは、ERPやSCMパッケージが提供するビジネスプロセスをそのまま導入する企業が少なかった点。特に海外製品の場合、日本独自の機能やビジネスプロセスなどが実装されていないため、そのまま使いたくても使えないという状況があった。また、パッケージに実装されている“お仕着せ”のビジネスプロセス導入を現場が受け入れないという問題もあった。そのため企業はパッケージをカスタマイズするか、既存のシステムをそのまま使い続けるかという選択を迫られたわけだ。例えばSAP R/3でも、人事・会計・製造・販売に至る全モジュールをノンカスタマイズで導入した企業はほとんどない。だがBPMツールなら、「どういうプロセスでどのシステムをどう動かすか」といったことが自分たちで決められる。
もう1つは、「既存のIT資産を生かす」という選択肢が台頭してきたこと。ERPブームが収まると同時に、既存資産を最大限に活用し、ビジネスプロセスを強化しようという動きが出てきた。EAI系のBPMツールならば、既存システムにそれほど手を加えることなく、最適なビジネスプロセスにのっとってシステム連携できる。
また前述したツール群が、単なるデータ連携・メッセージング機能だけでなく、ビジネスプロセス統合機能がこなれてきたという点も大きい。設定したフローに従ってトランザクションをハンドリングし、アラートや通知を出すことで、より業務効率が図れるようになる。
そして2004年、次のBPMツールが向かうのは“人”のビジネスプロセス管理にあるという。例えばサヴィオン・テクノロジーでは、次バージョンの「Savvion BusinessManager5.0」で、人の業務をシミュレーション・モニタリングする機能を搭載し、実際のフローの可視化と管理を実現する予定だ。具体的には、個々の社員の処理能力をパラメータとしてツールにインプットし、業務時間を設定すれば、ボトルネック部分が表示されるという仕組みだ。ボトルネックを解消するために、新たな人員を増やしたり、またシステムの強化を図ったりといった策も打てるようになる。これにより、システムだけにとどまらず人間系の業務フローも加味した最適なビジネスプロセスを実現できるという。
BPMツールの利点は、(1)自社のビジネスプロセスを迅速化し、(2)さらに人間系の処理フローを加えることで、最適なプロセスが実現できるようになることだ。ただし、いくつかのデメリットもある。
最大のデメリットは価格が高いこと。ツールそのものの価格は数千万円でも、ハードウェアや実際の開発プロジェクトの費用を加えると、軽く1億円を超えてしまう。特に高いのはコンサルティング費用だ。現状のビジネスプロセスの分析から始まり、最適なフローの設計や実装に期間もコストも膨大に掛かる。特にビジネスプロセス設計をコンサルタント任せにすると、費用が掛かるだけでなく、現場から不満の声が上がった際に対処できないという問題もある。
また、EAI系のBPMツールを使っても、やはりシステム連携にはそれなりの開発作業が伴う。例えばメインフレームとパッケージを連携させる場合、データが読めるように変換しなければならない。多くのツールには汎用データフォーマットのインターフェイスが備わっており、ベンダも「ソケットを差し込むように、簡単にシステム間連携が可能」というが、実際にはけた数やコードの違いを吸収するためEAIツール側に変換用プログラムを組む必要がある。そのため、後々になって「接続先やフローを変更したい」といっても、簡単には変えられない。前述のように、すべてコンサルタント任せでプロジェクトを進めると、こうした不測の事態に対応し切れないのだ。
BPMツール導入の際には、自社のビジネスプロセスの現状(As Isモデル)と、理想的な姿(To Beモデル)の両方をシステム部門主導でしっかりと描き出す必要がある。またAs IsとTo Beが描ければ、パッケージを導入した方がいいか、それともBPMツールがいいか、各種BPMツールの中で最適な製品はどれかといった選択もできるようになる。
Copyright © ITmedia, Inc. All Rights Reserved.