企業には様々なビジネス・プロセスがある。例えば，製造業なら「計画・開発・製造」「販売・調達・配送」「請求・売掛・回収」「サービス」といったものだ。このビジネス・プロセスは固定的なものではなく，ビジネスを取り巻く環境や企業の戦略によっても変わってくる。例えば，Webの登場によって顧客との注文のやり取りは電話による直接的なものから間接的なものへと変わった。その他にも，業務アプリケーションの効率化・最適化のため，他事業部とのサービス共有，在庫最適化のためのVMI（ベンダー・マネジメント・イ ンベントリ）導入，配送のプロセスでの3PL使用，業務のアウトソーシングなど様々な変更が発生している。
一方，業務アプリケーションを見ると，現在，多くの企業で見られるのがEAIを使ったアプリケーション間のデータを共有する仕組みである。しかし「この仕組みには問題がある」と吉田氏は指摘する。というのも，EAIではデータの流れは一方通行でメッセージの標準化もされておらず，また個々のアプリケーションが提供している機能という考え方がないからだ。「これではビジネス・プロセスの変化に合わせてアプリケーションの組み換えが容易にできない。つまり，EAIではビジネスの変革は難しい。そこで重要になるのがSOAとBPMの適用なのです」と吉田氏は力説する。
EAIとは異なり，SOAによるアプリケーション統合は，エンタープライズ・サービス・バス（ESB）基盤上で行われる。ESBにより個々のアプリケーションが提供している機能は，アプリケーションに依存しないWebサービスとして定義され，実際のアプリケーションが提供しているインタフェースに変換される。つまり，個々のアプリケーションは「ビジネス・プロセスから呼び出されるコンポーネントになります。例えば，配送計画を自社からサードパーティに変えた場合は，この配送計画というアプリケーションだけを差し替えれば済むのです」と吉田氏は説明する。
「BPMには3つの目標があります。第1に企業を構成する組織・機能をまたがり，顧客視点での中核となるビジネス・プロセスを管理すること。第2に様々な経営資源を割り振ることで，戦略的なビジネスの目標を達成すること。第3に組織や機能をまたいだ統合や中核となる業務を最適化し，ビジネスにおいて成功することです」と吉田氏は前置きしたうえで，「いちばん忘れてはならないのは，BPMは継続的な改善を必要とするものであるということです。つまり，これまで日本の製造業などが得意としてきたTQCという名の改善活動をビジネス・プロセスに適用したものなのです。ビジネス・プロセスを顧客のニーズに合わせつつ，最適なものにもっていくという企業活動の目標にもなり得るのです」と強調する。
BPMによって競争力や株主にもたらされる価値は，その成熟度によって異なる。業務のプロセス･モデリングのレベルでは価値は低いが，プロセスの実行，プロセスの監視が実現でき，さらにプロセスの最適化ができるようになり，初めて大きな価値がもたらされるというわけだ。このような大きな価値をもたらすBPMを達成するために必要となるのが，ソフトウエアとビジネスのノウハウの組み合わせ。その中でもSOAは最も欠かせないアーキテクチャーとなる。
BPMへの一歩は，ビジネス・プロセス・モデリングから始まる。「ビジネス・プロセス・モデリングとは，単なるタスクの順番や画面のフローを記述することではありません。あるひとつの形式に従って人や組織にまたがったビジネス・プロセスを標準化することなのです」と吉田氏は解説する。これによって人や組織に依存しない知識として活用が可能になる。つまり，「IT部門とユーザ部門の共通言語がこれにより実現でき，双方の担当者が異動しても後任に容易に引き継ぐことができるのです」と吉田氏。またビジネス･プロセス・モデリングにより，複数のビジネス･プロセスが分析されるので，サービスの切り出しも可能になるという。
ビジネス・プロセス・モデリングを行う際のポイントとして吉田氏は，「ビジネス・プロセス・モデリングを描く目的，スコープ，観点，聴衆，詳細のレベル，内容という6点を明確にすることが大切です」と語る。さらに，ビジネス・プロセスの設計にあたっては，「IT部門の人たちはas-isプロセスを描く際に,ついつい見た目を最適化する傾向があります。それでは，正しいas-isプロセスにおける現状分析ができなくなるため,正しいto-beプロセスも描けなくなってしまいます。ですから，完成するまではビジネス・プロセスを見せないことが重要となります」と注意を促す。
IBMでは，BPMを達成するためのフレームワークを提供している。それが「BPM Methodology Framework」である。「これは新しい開発手法ではありません。これを参考に開発の局面で足りないアクティビティのみを追加すればよいのです」と吉田氏は述べる。
ビジネス・プロセスの実装法として考えられるのがワークフロー（BPEL）を使ったものである。to-beプロセスの中からBPELで実装する部分のプロセス・モデリングを行い，BPELを生成する。「BPELの中には，呼び出されるサービスの物理アドレスやバインドプロトコルを一切記述しないことが大事です」と吉田氏。Service Component Architecture（SCA）の枠組みで開発されるBPEL の中では，呼び出すサービスのサービス・インタフェース（オペレーションと入出力のパラメータ）だけを記述するのである。こうすることで，BPELを変更することなく，柔軟なサービスの組み合わせや実装が可能になるというわけだ。
しかし，「BPELでプロセスを実装すると複雑化してしまうこともあります」と吉田氏は受注プロセスを例に，顧客への商品配送を手配する際，どの宅配便を使うか様々な条件文をBPELに埋め込んでいくと複雑化する問題点を指摘。それを解決する仕組みとして，呼び出されるサービスと呼び出される条件を一緒に管理し，その情報を使い動的にサービスを呼び出す「WebSphere Business Services Fabric」を紹介 した。このプラットフォームを使えば，ビジネス・プロセスを単純化し，BPELを変更・停止させることなく，呼び出されるサービスの追加やその条件を変えられる。これにより，BPELを用いたビジネス・プロセスを，ビジネスのニーズに合わせて維持することが一層容易になるという。また吉田氏は，BPMソリューションのリアルタイム監視ツールとして「WebSphere Business Monitorを用意している」 と語った。
最後に吉田氏は，IBMを始めとする複数企業のBPM適用実例を紹介。「先に触れたように，改善活動は日本が得意としていること。改善活動のひとつであるBPMをこれから多くの企業が推進してくれることを期待しています」と語り，講演を締めくくった。
日本アイ・ビー・エム株式会社 SOAポータルサイト
