BPIと従来のワークフローとの違い
BPIと従来のワークフローとの違い
前項の業務処理のプロセス化を見て、「従来のワークフローと同じではないか」と思われた方もいるだろう。確かにワークフローも「複数の部門の人がか かわる業務の流れを、全体的または部分的にコンピュータを利用して自動化すること」と定義されるので、結果的にBPIと同様のビジネスプロセスになるケー スもある。では、BPIによるプロセス化と従来のワークフロー化がどう異なるのか。
ワークフローは主に人が処理を行う業務の流れを電子化したものであることが多いため、帳票ワークフローなどのように、ある一定の粒度のデータがフロー上を流れるデータ志向（Data Oriented）的なフローになる傾向がある。
| ワークフロープロセス | BPIプロセス | |
|---|---|---|
| 主な処理者 | 人やプログラム | サービス（システム処理） |
| 処理フロータイプ | データフロー | プロセスフロー |
| プロセスの粒度 | アプリケーション間統合レベル（例：帳票ワークフロー） | アプリケーション内統合 〜 アプリケーション間統合 〜 ビジネス間統合 |
BPIによるプロセスは主にサービス（システムによる処理）による処理の流れを統合するため、サービス 志向（Service Oriented）的なフローとする傾向が強く、このプロセス自身も1つのサービスとみて、他のより大きなプロセスにより統合される対象となる。つまりプ ロセスの粒度は、コンポーネント内統合のような小さなものから、ビジネス間統合のような大きなものまで様々である。
これらのプロセスは業務の目的に応じて使いわけられることが多い。つまり、帳票ワークフローを実現した い場合には、帳票ワークフローに特化した機能を豊富に持つ帳票ワークフロー製品を使用し、システム連携を行いたい部分にはBPIプロセス用のエンジンを使 用するといった具合である。
BPIとEAIの違い
次に、「BPIがシステム間の統合なら、エンタープライズ・アプリケーション・インテグレー ション（EAI：Enterprise Application Integration）もアプリケーション間の統合であってシステム間の統合といえるが、実際どう違うのだろう」という疑問がわくだろう。この違いは、 システム間連携パターンの違いとして捕らえることができる（表3）。
（画像をクリックすると別ウィンドウに拡大表示します）
現在行われているシステム連携パターンとしては、大きくわけて表4の3つがあげられる。
- 直接接続型
- EAI型（メッセージブローカ型）
- BPI型
「直接接続型」は連携するシステム間をPoint to Pointで直接接続する。また「EAI型（メッセージブローカ型）」は複数のシステム間をn対nで接続するEAIサーバをかいして、メッセージのやり取 りを行える。これら2つの場合は、他のシステムとの連携する手順やタイミングが各システム内部の動きに依存しており、外からは制御することができない。
上記2つに対して「BPI型」は、このシステム間連携部分をプロセスとして外にだしたタイプである。そしてEAI型のようにシステム間の連携が密で はなく、BPI型ではプロセス部分が外部にあり、システム間は疎結合連携となっているため、プロセス部分や連携部分を変更することが比較的容易である。
表4の3つのシステム連携タイプのうち、時代の流れとしてはBPI型に移行しつつあるが、実際、企業内に残存するシステムにはレガシーなものも多く、現実には直接接続型やEAI型も組み合わせて全体のシステムが構築されることが多い。
企業戦略を支える技術としてのBPI
さて、BPIを従来の類似技術と比較しつつ技術的な側面を解説してきたが、今注目されているアーキテクチャであるSOAとBPIとの関連を明確にすることで、企業戦略を支える技術としてのBPIを考えてみる。
既にご存知の方も多いと思うがSOAは、「顧客や市場の変化を捉え、迅速に対応するための統合されていて、かつ柔軟性のあるシステム構築のための アーキテクチャ」と定義される。従来のシステムアーキテクチャが、一時点のシステムの構築のためのアーキテクチャであるのに対し、SOAは変化に対応できるシステムの構築のためのアーキテクチャという点が大きく異なる。
企業戦略も顧客や市場の変化に対応して、目標とそれを実現するための計画が策定されるが、顧客や市場の変化に対して迅速に対応することができるSOAは、システムの側面から経営戦略を支えるためのアーキテクチャということができる。
SOAはBPIよりも広範囲なシステム全般の柔軟性を目指しているが、その柔軟性のあるシステムを構築するために、重要な1つの技術としてBPIが存在するといえる。一方で、より柔軟性のあるBPIを実現するうえでもSOAを考慮することは重要である。
図3：SOA Reference Architecture
図3は、SOA化されたシステムが最終的にどのようなコンポーネントで構築されるかをあらわしている。BPIの部分は「プロセス・サービス」（青い箱の部分）のコンポーネントとして、ビジネスプロセス部分が他のサービスから切りだされて配置される。
「プロセス・サービス」では、前述のBPIの説明のようにSOAで定義される各コンポーネントを連携させて、プロセスとして統合することにより、ビジネス的に意味のある一連の作業の「End To End」での自動化を実現するのである。
このように、BPIはSOAを実現するうえでも必要不可欠な技術であり、企業戦略を支える技術として重要なのである。
図4：BPIのメリット
（画像をクリックすると別ウィンドウに拡大図を表示します）
以上のようにBPIを単なる業務システム構築のための技術としてだけでなく、SOAを基盤とした企業戦略を支える技術として捉えることで、継続的にメリットを享受できるようになるのである。
バックナンバー
この記事の筆者
筆者の人気記事
Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。
