レベル: 初級 保坂 大輔, WebSphereテクニカル・セールス, IBM
2009年 3月 17日 本連載ではBPMのアプローチによりお客様の課題をどう解決することができるか、またIBMの提供するBPM製品がどのようにそれを実現するのかを紹介し ます。
今回はビジネスの視点を中心にBPMで何が実現できるかに注目します。
BPMのメリットをビジネスの視点で考える
前回はBPMというのはどういう概念なのかという話でしたが、ここからはいよいよ「どういうメリットがあるのか？」ということを、ビジネス中心、IT中心の視点の2つの視点で、前回ご紹介したIBMのBPMミドルウェア製品WebSphere Dynamic Process Edition(WDPE) を引き合いに出しながら紹介します。まず今回は、ビジネス的な視点で見た時にどういうことが実現できるのかということをお話します。
前回ご紹介したようにBPMは「設計」「実行」「監視」を繰り返し、ビジネスを改善していくというコンセプトです。ビジネス的な視点とはこの中の「設計」「監視」に相当します。（図 1）
図 1 BPMライフサイクル - 設計、監視
設計 – ビジネス・プロセスのモデリング
「設計」では現状のビジネス・プロセス（As-Isプロセスと呼びます）を書いてみて、それを分析し、改善されたビジネス・プロセス（こちらはTo-Beプロセスと呼びます）を導き出します。ビジネス・プロセスはタスク1 とそれらを繋ぐ矢印を使って表現（図 2）します。つまり、「あれをやって、これをやって…」という処理の流れを記述するわけです。この作業をビジネス・プロセス・モデリングといいます。また、その成果物をビジネス・プロセス・モデルといいます。
図 2 ビジネス・プロセス・モデル
前回ご紹介したWDPEに含まれるソフトウェアWebSphere Business Modeler(WB Modeler)を使えば効果的にビジネス・プロセスのモデリングを行うことができます。（図 3）
図 3 WebSphere Business Modeler
As-Isプロセス・モデルの作成
ビジネス・プロセスを改善するためには、まず現状がどうなっているのかを把握しなければなりません。当たり前の話ですが、“改善”するということは現在の状態よりも良くするということですから、現状を知ることが第一歩になります。「見えないものは改善できない」わけです。ビジネス・プロセスの文章化がまず行うべき最初の仕事です。
「では、早速、ビジネス・プロセス・モデリングをやってみよう！」という時に考えないといけないのは「どうやって表記するのか？」という点です。タスクを表す箱（丸でもいいですが）とそれをつなぐ矢印ならば、簡単に何を使っても書けそうです。しかし、これはいかにも危ない香りがします。皆さんも似たようなご経験をお持ちだと思いますが、みんなが好き勝手に自分のやり方で書き始めると、互いの解釈に誤解が生じて収拾がつかなくなることが容易に想像できます。
そのような事態を起こさないためには何らかの表記法に基づいて記述をするべきですが、例えばビジネス・プロセスの表現に特化した表記法としては、ビジネス・プロセス・モデリング表記法(Business Process Modeling Notation; BPMN)があります。BPMNはOMG2 により管理されており、BPMNはビジネス・プロセス表記の標準になるのではないかと期待されていますので、これを採用するのも一つの手でしょう。
何らかの表記法を決めて、ビジネス・プロセスを書いたとしてもそれだけでは十分に現状の分析ができているとは言えません。それはあくまでも“お絵かき”にしか過ぎません。
実際の業務にはタスクの流れだけではなく、考慮すべき要素が他にも沢山あります。「そのタスクを実行するのはどういう組織の人か」「そのタスクの処理にはどれぐらいの時間/コストがかかるのか」など、現状を把握するために知っておきたいことは他にも色々あります。これら分析したい情報を、例えばWB Modelerなどのツールを利用することにより記述できれば、それは“お絵かき”と呼ばれるものではなく”ビジネス・プロセス・モデル”だと言うことができるでしょう。
どうですか？「ずいぶん大変そうだなぁ」というのが感想ではないでしょうか。実際、これらはツールを使ったからといって、サクサクと簡単にできるものではありません。多くの組織ではビジネス・プロセスとそれにまつわる情報は暗黙知になっていたり、システムの中にハードコードされていたりするため、なかなかモデルにするのは簡単ではありません。一般的にはコンサルタントなどのプロフェッショナル・サービスを雇って、そのノウハウを活用しながら、必要であればストップ・ウォッチを使った作業時間の測定やビデオを使った動作研究などを行って泥臭く作成していくものです。
一方で場合によっては“お絵かき”程度で必要十分ということもあるでしょう。大切なのは「目的が何で」「そのためには何を文章化する必要があるか」そして「どのような情報をモデルに入れなければならないのか」ということについて方針を持つことです。
その量と質は別にして、As-Isプロセスのモデルができれば、少なくともビジネス・プロセスの文章化の第一歩は達成できたと言えるでしょう。以前は全くわかっていなかったものが文章化できたわけですから大きな進歩です。
To-Beプロセス・モデルの作成
さて、苦労して（または最初なので簡単に済ませて）作成したAs-Isプロセスのモデルがあります。次はそのモデルを元に、To-Beプロセスを探っていかなくてはなりません。見えないプロセスは改善できませんが、As-Isプロセスを作成した今は見えるので改善できるはずです。
ツールを利用すればTo-Beプロセスが自動的に生成されるのではないかと考える方もいらっしゃいますが、残念ながらそれは幻想です。「改善されたビジネス・プロセス」というものは唯一自明に存在しているわけではありません。様々な制約や条件、達成すべき目標により様々な形を取りうるものです。As-Isプロセス・モデルの作成と同様に泥臭く地道にTo-Beプロセスを探っていかなくてはなりません。
ビジネス・プロセス・モデルの分析には大きく分けて静的分析と動的分析とがあります。静的分析とはモデル自身の持つ情報を元に行う分析です。わかりやすく言うと、モデルとそこに書かれた情報を見て、「う～ん」と唸りながら考え、モデルをいじる、というものです。リソースの平準化ができないか、時間管理をもっと上手にできないか、などと考えます。
一方、動的分析とはシミュレーションを実行し、その結果を元に行う分析のことです。シミュレーションを行う際にはAs-Isプロセスの実行時間やコスト、その作業をする人員の勤務シフトや、条件分岐における分岐確率（この条件になってこちらの分岐に進むのは何パーセントの割合で、という過程）などを入力しておきます。さらに、例えば実行時間に関しては一定ではない場合がほとんどでしょうから、その確率分布（正規分布なのかポアソン分布なのか、など）やその分散がどのぐらいなのかについても入力します。
さて入力が終わったらいよいよ、あるビジネス・シナリオに基づいてシミュレーションを実行（図 4、図 5）し、プロセスの改善を目指します。前述の通り、実行しては条件を修正し、また実行するという非常に泥臭い作業です。
図 4 シミュレーションの実行
拡大図
図 5 シミュレーション結果表示
このように、きちんとしたシミュレーションを実行するのはかなり大変ですが、クリティカル・パスや最短パスがどこなのか、人や機械といったリソースの割り当てやそのコストがどうすればより有効なのか、といったことを知ることができます。ここで目指す“改善”はそのビジネス・プロセスが目指すものによって違います。コストの削減を目指すこともあるでしょうし、サイクル・タイムの削減を目指すことも、スループットの増加を目指すこともあるでしょう。または、それらを複合したゴールの場合もあるでしょう。
いずれにせよ苦労のあとには、少なくとも“机上では”改善されたビジネス・プロセスを手に入れることができているはずです。
ビジネス・プロセスの実装への受け渡し
“改善”したビジネス・プロセスは実行しなければ意味がありません。そのプロセスをマニュアル化して人が実行してもいいですし、それを元に既存のシステムのコーディングを変更させても構いません。
ただ、せっかく作成したわけですから、その“改善”したビジネス・プロセスをできるだけそのままITシステムの上で実行させることができると嬉しいですね？ 手間も省けますし、確かにその”改善”したビジネス・プロセスが動いているということになります。
WB Modeler上にあるビジネス・プロセス・モデルは様々な形式でエクスポートすることが可能ですが、その一つの形態としてSCA3 モジュールの形式が可能です。このSCAモジュールにはWB Modelerで作成したビジネス・プロセスを元にしたBPEL4 が含まれており、“改善”したビジネス・プロセスをそのまま実行することができます。BPMサイクルの「設計」と「実行」を継ぎ目なく移行することができるわけです。
今回はビジネス視点でBPMを見ていますので、「実行」については次回に譲ることにして、次は「監視」について話を続けることにします。
監視 – ビジネス・プロセスのモニタリング
「可視化」や「見える化」という言葉がありますが、上で述べたビジネス・プロセス・モデリングでは「可視化」ができたとは言えません。ビジネス・プロセスの分析により、ある意味、見えていなかったものが見えたわけですが、実際の稼働環境において何が起こっているか見えるわけではありません。「可視化」とは現在実行中のビジネス・プロセスで何が起こっているかを知ることです。
BPMサイクルの「監視」を実践するためにはビジネス・プロセスの実行状況を監視し、場合によっては感知した状況に素早く対処することが求められます。また、「監視」で得た情報を元に再び「設計」を行うことでBPMサイクルを回すことも必要です。以下では、これらの項目についてWDPEに含まれるソフトウェアWebSphere Business Monitor（WB Monitor）(図 6）の機能を紹介しながら、もう少し詳しく見ていくことにします。
図 6 WebSphere Business Monitor
ビジネス・アクティビティー・モニタリング（Business Activity Monitoring ; BAM）
ビジネス・プロセスの実行状況やパフォーマンスを監視することをBAMといいます。KPI5 を定義して、それをダッシュボード6 でリアルタイムに確認するというのが一般的なイメージでしょう。（囲み記事「BPMの枠組み以外でのBAMの活用」参照）
BAMは経営に直接関係する指標に限らず、より現場に近い指標のモニタリングも含んでいます。例えば、社内の事務プロセスで滞留している業務（タスク）があるかどうかを管理者が監視する、営業のマネージャーが配下の営業の今月のここまでの営業成績をチェックする、などです。つまりダッシュボードと一言で言っても経営者向け、ITインフラ部門向け、業務マネージャー向け、一般ユーザー向けなど様々な形態や目的があるということです。（図 7、図 8）
図 7 ダッシュボードの例：KPIの表示
拡大図
図 8 ダッシュボードの例：ビジネス・プロセスの監視
拡大図
 |
BPMの枠組み以外でのBAMの活用：
最近はかなり広く世の中で語られており、BPMとは違う文脈でも見かけることが多くなっています。例えばバランス・スコアカード（Balanced Score Card）で有名なロバート・カプランとデイビッド・ノートンも最近の著書"The Execution Premium: Linking Strategy to Operations for Competitive Advantage"でダッシュボードの活用について述べています。この本では多くの企業の業績不振は戦略と業務の断絶にあると主張しており、業務プロセスを改善するツールがないため戦略目標の実現が難しいことをその原因としてあげています。そして、業績評価指標のダッシュボードを業務評価のツールとして利用することを提唱しています。具体的には、バランス・スコアカードなどを利用した戦略計画を業務計画に落として、ダッシュボードで月次、あるいは日次でモニタリングします。その実績を戦略計画にフィードバックし、年一回や四半期に一回の頻度で策定/更新するというサイクルを回すという方法です。これなどはBAMを経営の改善に活用するわかりやすい例といえるでしょう。 |
|
では、ダッシュボードに表示される情報はどのように定義され、どこから集められるのでしょうか？
これらの情報は、イベントと呼ばれる、システムから投げられるデータを通じて得ることになります。BPELやアプリケーションにイベントを投げるように設定をしておいてWB Monitorはそれを収集してダッシュボードに表示するわけです。イベントはCommon Base Event(CBE)という仕様で定義されており、WB Monitorはこの仕様に準拠していれば誰が投げたイベントでも収集することができます。
具体例で説明しましょう。あるビジネス・プロセスがあってその平均処理時間をダッシュボードで確認したいという要件があるとします。この場合、ビジネス・プロセスの最初と最後にイベントを投げるように設定しておきます。WB Monitorは最後のイベントの日時から最初のイベントの日時を引けば、このビジネス・プロセスの処理時間を知ることができます。これを繰り返して処理時間の和を処理されたビジネス・プロセスの数で割ると平均処理時間を計算することができ、ダッシュボードにそれを表示すればいいわけです。
イベントを投げるための定義はBPEL上に直接設定することもできますし、前述のビジネス・プロセス・モデリングの際にWB Modeler上で設定することもできます。KPIなどはビジネスの分析の段階でWB Modeler上で設定する方が自然でしょうし、よりITに近い内容のイベントであればBPELに設定する方がよい場合もあるでしょう。いずれにせよWB Monitorは誰が投げたイベントかは考慮せず、自分が見るように設定されたイベントのみを収集して処理します。
検知して素早く対応
ダッシュボードでの監視はいわゆる”Pull”型です。こちらから情報を得に行き、何かに気づけばそれに対処する、または単に情報を得るだけ、という性質のものです。
一方で、場合によっては何らかの異常や緊急事態を検知して、それに素早く対応しなければならない”Push”型の監視が必要なケースもあります。わかりやすいのはあらかじめ決められた閾値を超えた時に対応するケースでしょう。お客様からの問い合わせ処理が一定時間経過した場合に管理者に注意を促すメールが飛ぶ、製品の滞留がある閾値を超えるとサービスが呼び出され緊急対応プロセスが起動される、などの状況です。このような場合は誰かがダッシュボードを見て気づくのを待っているわけにはいきません。
WB Monitorはそのような対応が必要になる条件を定義しておくことにより、メールの自動送信で管理者に通知したり、あらかじめ決められたサービスを呼び出したりする機能を持っています。サービスを呼ぶことができるのでサービスの実装次第でどんな対応でも可能になります。
”Push”型の監視で他に考えられるのは、多くの情報からあるパターンを発見し、対応するという場合、例えば、膨大な金融取引情報から不正を検知するといったケースです。この場合は、WDPEには含まれないWebSphere Business Events（WBE）というイベント処理を行うための製品が役立ちます。WBEは膨大なイベントのパターンマッチングを行い、ある決められたパターンを検知するとイベントを投げます。このイベントをWB Monitorが検知して対応を行うといった組み合わせのソリューションとして使用することができます。
監視した情報のフィードバック
さて、”Pull”型、”Push”型に関わらず、監視しても「あーそうか」「ちゃんと動いているな」だけではいけません。BPMを効果的に実践するためには、監視して得た情報を元にビジネス・プロセスを見直したり、商品やサービスを見直したりして、BPMサイクルを回す必要があります。
WDPEは包含するソフトウェア同士でビジネス・プロセスの見直しをスムーズに実行できるような機能を提供しています。WB Monitorは収拾した情報をXMLとしてエクスポートすることができ、そのXMLをWB Modelerで取り込むことができます。ビジネス・プロセス・モデリングを行う時に入力した情報は、ある意味、実際の値ではありませんでした。ストップ・ウォッチで測るなどして得た実測値もあるかもしれませんが、その後、ITシステム上に実装したビジネス・プロセスで実行された値は想定とは違ってきているものも多いはずです。また、ビジネス・プロセスが改善されたことにより以前とは変わってしまったデータもあるでしょう。そのような「今動いている」環境から持ってきた生のデータを元にビジネス・プロセス・モデリングができれば、さらなる改善を見込めます。WB Modelerで実行環境から持ってきた値を元にモデルを書き換えれば、BPMサイクルが一回りしたということができます。
まとめ
今回の記事では主にビジネスの観点からBPMサイクルの「設計」「監視」の部分について見てきました。
前回の記事でも書きましたが、これらの記述の通りに実践しなければBPMを実践していないというわけではありません。「設計」において、“お絵かき”だけで済ませていきなりBPELで実装するケースもあるでしょうし、そもそもビジネス・プロセス・モデリングだけを実行して、あとはITを利用せず人間により改善したビジネス・プロセスを実践するケースもあるでしょう。大切なのは「目標は何なのか」「その手段は何なのか」という点を明確にし、それに基づいてなすべきことを決めることです。
次回は改善したビジネス・プロセスをITシステム上でどのように実行するのか、その仕組みをご紹介します。また、変更に対して、ITがどれだけ柔軟かつ迅速に対応できるのかという点についてもご紹介する予定です。
注釈
1ビジネス・プロセスの処理単位。アクティビティーとも呼ばれる。ビジネス・プロセス記述の抽象度によっては、このタスクがさらにサブプロセスであるという表現も可能であり、その場合はビジネス・プロセスが階層構造になる。
2Object Management Group。UMLやCORBAなどの標準を管理している団体。
3サービス・コンポーネント・アーキテクチャー（Service Component Architecture）。様々に実装されたコンポーネントをSOAのサービスとして結合してアプリケーションを構築する技術仕様。
4前回の記事を参照。
5重要業績評価指標（Key Performance Indicator）。組織の目標の達成度を定量的に表す指標のこと。例えば「既存店舗売上増加率」「設備稼働率」などである。
6自動車の計器盤（ダッシュボード）が由来。ビジネスに必要な指標や現在の状況を表示する画面のこと。
参考文献
著者について | | | IBMソフトウェア事業WebSphereブランドに所属するテクニカル・セールスです。BPM関連製品を担当しており、主にお客様への提案活動やセミナー等での講演を行っています。 |
記事の評価
| 
