ビジネスを可視化するモデル記述言語「BPMN」BPMNを活用したビジネスプロセス・モデリング(1)

 ビジネスプロセスをモデル化するのに、UMLは難しすぎると考える人がいる。そもそも、顧客にUMLで記述したビジネスプロセス(のモデル)をみせてもなかなかわかってはもらえない。UMLはもう少し実装寄りのモデルを記述するのに使えばいい。ビジネス寄りのモデルを記述するために、もっと簡単で、しかも表現豊かな言語はないものか。簡単にいえば、そんなニーズのもとにBPMNは誕生したのである。(@IT編集部)

» 2005年03月05日 12時00分 公開

連載を開始するにあたって

 経営戦略とITが密接に結び付き、ビジネス環境の変化に合わせてビジネスプロセス(業務手順)を変更すれば、直ちにシステムが動き出す――。そんな夢のようなパラダイム・シフトが近づいています。その中心にあるのが最近注目されている2つのキーワード、BPM(ビジネスプロセス管理)とSOA(サービス指向アーキテクチャ)です。いま、その大きな流れの中に、BPMNというモデル記述言語が合流しようとしています。

 BPMNは、Business Process Modeling Notation(ビジネスプロセス・モデリング表記法)の略で、業務手順を分かりやすく図示して可視化するための表記ルールを定めたものです。抽象的な表現ですが、BPMNで図示したモデルを起点としてBPMとSOAが活躍するのです。本連載では、なぜBPMNに注目すべきかを説明することから始め、その後数回にわたってBPMNを活用した具体的なモデリング方法を解説し、最後にはBPMNを取り巻く最新動向について紹介したいと思います。

BPMN登場の背景(BPM、SOA、そしてBPMN)

 2004年5月、米国非営利団体BPMI(Business Process Management Initiative)から標準仕様「BPMN 1.0」が公表されました。BPMIは、BPM関連企業50社(2005年2月15日時点)が参加し、各種標準の策定を進めている団体で、BPMを普及させることを目的としています。そのBPMIがBPM普及のために必要だと考えて策定したBPMNは、UMLアクティビティ図、UML EDOC、IDEF、ebXML BPSS、RosettaNetなど、多くの表記法を参考としながら2年以上の時間をかけた成果です。なぜ既存の表記法ではなく新たな表記法が必要だったのか、少し遠回りしますがBPM、SOA、そしてBPMNの順で説明していきます。

■ BPM(Business Process Management)

 ビジネスプロセスとは、例えば「受注→出荷指図→出荷……」など、業務の一連の流れを表すもの、すなわち業務手順のことです。このビジネスプロセスを管理するためのPDCAサイクル(図1)を確立し、経営戦略に基づき最適なプロセスの実現を目指すのがBPMと呼ばれる概念です。

ALT 図1 ビジネスプロセスのPDCAサイクル

  PDCAサイクルとはビジネスプロセスの定義、実装、実行、モニタリング、分析、最適化を循環させるもので、変化し続けるビジネス環境に対応するためには、このサイクルを繰り返して回す継続的な改善努力が必要です。まずはビジネスプロセス・モデルとして図示しながら業務を把握、整理して定義します。そして、定義されたプロセスをITに実装して実行します。実行状況はリアルタイムにモニタリングされ、遅延発生時の迅速な対処、リソース再配分によるボトルネックの解消などの対応が取られるとともに、モニタリングされた遅延状況や処理時間などの情報が蓄積されます。蓄積された情報を分析しながらプロセスの最適化を図り、プロセスを再定義します。すでに導入が進められているBPMソリューションにおいては、プロセスを定義する計画段階でのシミュレーション機能、KPI(重要業績評価指標)など経営に密接な評価基準を定義、モニタリング、分析する機能など、高機能なPDCAサイクルが実現されています。

 さらにBPMは、PlanとDoを対象とするソリューション、WF(Workflow)、ERP(Enterprise Resource Planning)、EAI(Enterprise Application Integration)を統合し、PDCAサイクルによって柔軟性を持たせるとの方向性を持っています。プロセス主導型のBPMに統合することで、

  • WFの固定的なプロセスを経営戦略即応型の変動プロセスに変える
  • ERPが提供するベスト・プラクティスを選択性の高いベスト・プラクティス群に変える
  • EAIが実現するデータ連携をプロセス連携に変える

などの高度化を目指しています。これらの方向性は、著名なWFベンダ、ERPベンダ、EAIベンダがBPMIに参画していること、各ベンダが自らのソリューションにBPM機能(またはBPM連携機能)を付加しつつあることから今後の主流になるものといえます。

■ BPMとSOA(Service‐Oriented Architecture)の関係

 ビジネスプロセスのPDCAサイクルをスムーズに循環させるためには、ITへの実装コスト(時間・金)がボトルネックとなってタイムリーな改善ができないといった問題を解決する必要があります。この問題を解決するITアーキテクチャがSOAなのです。

 SOAは、サービスと呼ばれるソフトウェア部品を組み合わせてアプリケーションを構築する概念です。サービスとは、自由に組み合わせることができるように他のサービスに依存しない独立性と規格化されたインターフェイスを持つもので、汎用性を考慮して業務上の意味を持つ単位にまとめられたものです。

 冒頭で述べた「ビジネス環境の変化に合わせてビジネスプロセスを変更すればただちにそのとおりにシステムが動き出す」というBPMが目指す理想は、サービスの順序を入れ替えたり、サービスを交換したり、新たなサービスを追加したりすることで、自由にビジネスプロセスを変更したり、新たなビジネスプロセスを構築したりできることを表しています(図2)。さまざまな業務に対応するサービスが共通部品として流通すればするほど、理想に近づいていくのです。

ALT 図2 プロセスの組み替えイメージ

 一方、SOA側の視点からBPMをとらえると、SOAにビジネスにおける利用価値を付加するものとしてBPMが位置付けられます。Webサービス、CORBAなどは、注目されましたが普及との点ではいま一歩といえる実装技術です。その実装技術に活用するための枠組みを与えるのがSOAであり、さらに経営戦略と結び付けるのがBPMであるといえます。BPMとSOAが連携することで、ビジネス・ニーズと実現手段が結び付き、この2つの流行語が単なる流行として終わらない可能性が高くなるのです。

■ 新たな表記法BPMNの必要性

(1)共通言語としてのBPMN

 ビジネスプロセスのPDCAサイクルでは、まずはビジネスアナリストがビジネスプロセス・モデルを定義し、次にIT技術者が実装のためにモデルの詳細化を図って実装します。そして、業務管理者がモデル上でビジュアル化されたプロセスの実行状況をモニタリングし、見つかった改善点はモデルを使ってビジネスアナリストと協議しながら最適化が図られます。BPMではビジネスプロセス・モデルがコミュニケーションの道具になるのです。そのためには、IT技術者ではなくても理解できるシンプルで分かりやすい表記法が必要になります。

 また、企業間でのプロセス連携を実現するためには、どのように連携するかの取り決めが必要です。同様にSOAのサービスが汎用性の高い共通部品として流通するためにも、サービスを提供する各ベンダ間での統一的な取り決めが必要です。それらの取り決めの指針となるのが、業務別に標準化されたビジネスプロセス・モデル、すなわちビジネス参照モデル(プロセステンプレート)です。そのビジネス参照モデルを整備、流通させるためには、モデルを記述する表記法が企業間、ベンダ間の壁を越える共通言語であることが求められるのです。

(2)BPMNを起点としたモデル駆動型開発

 ビジネスプロセスの実装は、自由に組み合わせられるSOAのサービスがあってもまだ不十分で、サービスを呼び出す順序、条件など、サービスを実行するロジックを実装する必要があります。プロセスを実行するBPMエンジンは、そのロジックに従ってサービスを実行、制御するのです。定義されたプロセスに従って制御することをオーケストレーションと呼びますが、プロセスを定義したら即実装可能とするためには、ビジネスプロセス・モデルからオーケストレーションのための実行言語が自動生成される必要があります(図3)。オーケストレーションはビジネスプロセス固有の複雑性を持つものであり、その複雑性を記述できる能力を持つ表記法が必要になります。

ALT 図3 モデル駆動型開発イメージ

 IT技術者ではなくても理解できるシンプルさ、オーケストレーションを表現する能力、両方を兼ね備えるものがUMLなどの既存の表記法には存在せず(コラム参照)、現在のBPMソリューションではベンダ独自の表記法でビジネスプロセス・モデルを記述しています。このままでは企業間、ベンダ間の壁を越える連携が図れないとの判断から、標準的な表記法としてBPMNが開発されたのです。

コラム UML ではビジネスプロセスを記述できないのか?

 UMLのアクティビティ図は、単なるワークフローを記述するには充分な能力を持っていますが、企業間のプロセス連携をうまく表現できない、ビジネスプロセス特有のイベントを簡潔に表現できないなど、ビジネスプロセスの記述においては不足する点があります(企業間プロセス連携、イベントとは具体的にどのようなものか。その詳細は今後の連載で解説します)。

 表現上の問題だけではなく、アクティビティ図がビジネスプロセスの記述に向かないとされているもう 1つの理由として、IT技術者ではない人には難しすぎる点が挙げられます。アクティビティ図の何が難しいのかについては「百聞は一見にしかず」、BPMN開発メンバーであるStephen A. White氏(IBM)が記述したドキュメント『Process Modeling Notations and Workflow Patterns』を確認してみてください。このドキュメントは、21個のワークフローパターンについてBPMNとUMLアクティビティ図を併記して比較した資料です。その翻訳版『プロセスモデリング表記法とワークフローパターン』を日揮情報ソフトウェア岩田研究所で公開しています。BPMNとアクティビティ図の表記法を知らなくても、併記されている両者の見た目を比べることで、BPMNのシンプルさとアクティビティ図がIT技術者寄りであることが実感できると思います。このドキュメントの結論でも「BPMNはビジネスマンが使うための記法」、「UMLはソフトウェア開発のモデリングを標準化することが目的」、UMLは「技術色が残っている」と述べられています。


BPMNの特徴

 新たな表記法に求められる要件をすべて満たすために、BPMNには2つの重要な特徴が与えられています。

(1)シンプルでありながら豊かな表現能力

 分かりやすくシンプルであること、ビジネスプロセス固有の複雑性を表現できること、この相反する2つを同時に実現するため、図形要素を体系化して基本要素とさらに詳細なバリエーションでの構成としています(図4)。基本要素だけでもシンプルに記述ができ、基本的な見た目を変えずにバリエーションを追記して詳細化が図れるようにしています。

ALT 図4 体系化された図形要素

(2)実行言語の生成が可能

 オーケストレーションを記述するための実行言語として、XMLベースの言語であるBPEL4WS(Business Process Execution Language For Web Services)が業界標準になるといわれています。このBPEL4WSとのマッピングを規定し、BPMNからBPEL4WSを生成するための変換ルールを明確にしています。

 以上のような特徴を持つBPMNにはモデリングツール・ベンダをはじめとした多くのBPM関連ベンダが注目しており、BPMIのWebサイトによると「20社がサポート済み、5社がサポートを計画」(2005年2月17日時点)となっています。しかも、UMLモデリング推進協議会(UMTP/Japan)において「BPMN研究会」が発足されるなど、BPMNへの期待はすでにBPMの枠を超えている感さえあります。

 次回から、早速BPMNの具体的な説明に移ります。そして、連載の最後にはBPMNへの期待が本物なのかを現状での課題や最新動向を踏まえて考察してみたいと思います。本物なのかを探る気持ちで、ぜひともBPMN探検に挑んでみてください。

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ