PR

1つのビジネスプロセス全体を対象とする第2ステップ(特定ビジネスプロセスプロジェクト)でのプロジェクトを完了できたら、第3ステップ(全社展開プロジェクト)を実施します。ここでは複数の業務プロセスを対象としてBPMシステムを構築します。

第2ステップでのプロジェクトで説明した、設計・開発・運用のBPMシステム導入プロジェクトはここでも同じですので、説明を省略します。第3ステップでは、複数のビジネスプロセスに対してBPMシステムをどう導入し、どう活用し、どう展開するかがポイントとなります。

5. 第3ステップ「全社展開・プロジェクト」(本格導入と業務改善の実現)

1) プロジェクトの規模

通常このプロジェクトは、以下のプロジェクト規模で実施します。第2ステップでのプロジェクトの2倍以上の規模です。

表1 第3ステップ(全社展開・プロジェクト)で計画する項目
体制 15~30名(社外3~5名)
業務部門3名×2(プロジェクトマネジャー1名含む)
情報システム部門3名×2(基盤系1名×2、開発2名×2、IT側のリーダー)
社外3名×2(システムインテグレータ上級SE1名×2、プログラマー2名×2)
期間 20~25カ月
費用 5000万円~
業務範囲 会社の複数の業務分野を連携
システムの特徴 インフラ・DBとも基幹連携してBPMをSOA環境で導入
想定するソフトウェア及びハードウェア 全社標準とするBPMシステムツールとBPMモデリングツール
プロセスをリアルタイムに監視するBAM(Business Activity Monitoring)
ハードウェアとして、開発環境としてのサーバーと品質保証サーバー、商用サービス(本番)サーバーが必要

2) 計画、設計、開発、運用

第3ステップの進め方には、具体的には以下の2つがあります。

  1. 第2ステップ(特定ビジネスプロセス・プロジェクト)でのプロジェクトの実行ステップのうち、「検証」ステップを除いた導入ステップを複数事業部に展開する方法
  2. ある特定の1つの事業部でBPM導入すべき全てのビジネスプロセスを対象に実施し、他の事業部に展開していく方法

どちらの進め方でも、会社の規模によっては全社展開するためにはおおよそ20カ月以上かかります。プロジェクトチームも大規模になるので、チームを分割して効率よく進めることが重要です。その際、どのチームにも第2ステップでのプロジェクトを経験したメンバーが入るようにしてください。

BPMシステムは1つひとつ導入・運用し、PDCAサイクルを回し、継続的改善を実施することが可能です。複数の事業部または複数の業務で、BPMシステムの導入効果を短期間で確認できるため、小さな成功を積み上げていき、全体として成功に導くという理想的な進め方ができます。またこの進め方の最大のメリットは、複数のビジネスプロセスへのBPMシステム導入そのものが、会社全体にプロセス指向の風土を生み出していくと期待できることです。

3) SOA (Service Oriented Architecture)

ここまでBPMシステムの構築について説明してきましが、本章の最後に少しSOAについても説明をしておきたいと思います。最近SOAという言葉を耳にする機会が増えてきたのではないでしょうか?またBPMとの関連でSOAが語られる場面が非常に多いことに気づかれたのではないでしょうか。BPMとの関連は後述しますが、まずSOAについて考えてみます。

SOAでは文字どおりサービスを中心に考えることになります。ではそのサービスとは何を意味するのでしょうか?

前述したように、従来のアプリケーション開発ではユーザー要件を機能用件に分解しました。そして機能用件を持ったプログラム群を開発し、それらを組み合わせてユーザー要件を満たすアプリケーションを完成させました。つまり、プログラムの集まりが開発の成果物となり、ユーザーに提供されていたわけです。一方、サービスという概念では、皆さんもご存知のように物は提供しません。必要な作業のみを提供してくれます。アプリケーションでのサービスで言えば、それを作り上げているプログラム群を提供するのではなく、アプリケーションの機能のみを提供することになります。これがアプリケーションサービスと言う考えです。この考えの下では、アプリケーションサービスを提供してくれる業者(ASP:アプリケーションサービスプロバイダ)がいれば、アプリケーションを所有する必要はなくなるわけです。

ではSOAとはどのような考えなのでしょうか?必要なアプリケーションをASPに全部任せることではなく、サービスの概念を中心としてアプリケーションを構築することです。

もう少し説明しましょう。サービスとは機能を提供してくれるものでした。つまり入力に対して何か作業をして出力を返してくれるものです。入力の与え方と出力の仕方(これをインタフェースと呼びます)が明示されていれば、サービスを呼び出したりサービス同士を連携したりして要件を満たすアプリケーションが構築できるわけです。このとき、実際にサービスを提供してくれるプログラムを自分が持っているか、他からサービスのみを提供してもらうかは問題にはしていません。サービスを呼び出したり連携させてアプリケーションを構築するという概念がSOAなのです。

SOAの概念を実際の例にしたがって少し見てみましょう。ここでは簡単ですが、出張旅費精算を例にとってみました。旅費精算では使った交通機関ごとに運賃を調べて記入し、宿泊手当などを会社の規定に基づいて計算して記入する、という手順で精算書を作ると思います。下図はこの旅費精算アプリケーションをSOAで構築した例になっています。

図 SOAによる旅費精算アプリケーション
図 SOAによる旅費精算アプリケーション(図をクリックで拡大)

運賃計算サービスは入力の「交通機関、出発地、到着地」に対して、計算した運賃を付加して出力します。宿泊手当て計算サービスでは、入力の「宿泊区分、開始日、終了日、役職」に対して会社の規約に則った手当て金額を付加して出力します。精算書作成サービスでは、入力の「部署、名前」と「項目、内容、金額」に対して、合計金額を精算書のフォームにして出力します。これらのサービスを組み合わせて、図のように連携させることで旅費精算アプリケーションが構築できます。大事なポイントは、それぞれのサービスは独立していて、入力と出力というインタフェースのみで連携しているということです。つまり、お互いの中身についてはまったく干渉していません。入力に対して必要な作業して出力を返してくれればそれでよいということです。例えば、ここでの運賃計算サービスは自社で作ったサービスでなく、Webサイトでよく見かけるものを呼び出して使うことができるかもしれないということです。

従来のアプリケーション開発でも、機能を分割してその組み合わせにより全体を構築することはありました。しかしそれは、そのアプリケーション内に閉じたものでした。SOAでは、サービスは入力や作業内容、出力をアプリケーションの境界に縛ることなく公開していて、皆が利用できるようになっています。もちろん公開する範囲は一律ではなく、部署内専用や社内専用、社外公開用といったサービスごとに異なるものになります。

SOAでアプリケーションを構築することには次のようなメリットがあります。

  • アプリケーションをサービスで組み立てるので、アプリケーション全体の構造が明確で理解しやすい
  • サービスはそれぞれ独立しているので、アプリケーションの変更は影響を受けるサービスの作り変えや取り替えによって可能になる
  • 利用できるサービスが既にあれば、それを再利用してアプリケーションを構築することができる

4) SOAとBPM

BPMとSOAにどういった関連があるのでしょうか?

SOAはアプリケーションの作り方の概念ですから、ビジネスプロセスについての考えであるBPMと直接関連性があるわけではありません。しかし前節で述べたように、BPMシステムはアプリケーションを構築していくものです。したがって、BPMシステムとしてのアプリケーション構築に、SOAの考えが適用できます。実はBPMシステムとSOAは非常に相性がよいものなのです。ビジネスプロセスはサブプロセスから構成され、それぞれのサブプロセスが明確な入出力を持って繋がれていることは第2章で説明しました。サービスを組み合わせてアプリケーションを構築することは、ビジネスプロセスをサブプロセスから構成することと概念的にはまったく同じです。とはいえ、単純にサブプロセスが1つのサービスによって実現できるわけではありません。業務上の作業という観点から捉えたサブプロセスと、アプリケーションに必要な機能という観点から捉えたサービスでは、粒度が異なります。サブプロセスでの作業には人の作業も含むでしょうし、システム化できるものだけとは限らないからです。しかし、ビジネスプロセスをシステム化するに当たってSOAの考えを用いることは、大きなメリットがあります。前述のSOAのメリットをもう一度見てください。

SOAの考えでビジネスプロセスをシステム化すれば、

  • ビジネスプロセスに変更が起きた場合、影響範囲を限定し、関係するサービスのみ直修正すればよいので迅速に対応できる
  • ビジネスプロセスに新しい要件が追加された場合、サービスを追加して対応することができる
  • 新しいビジネスプロセスをシステム化する場合に、社内外を問わず利用できる既存のサービスがあれば、それを活用して迅速にシステム化できる

といったように、迅速かつ柔軟にビジネスプロセスの変化に対応できるからです。SOAによる実際のアプリケーションの構築方法についての詳細はここでは述べませんが、BPMシステムにとっては非常に相性のよい概念であることは理解していただけたのではないでしょうか。

6. まとめ

以上、BPMの導入実践編として具体的な手順を説明しました。

BPMを成功させるのに大事なのは、プロジェクトに対する経営トップの強力なバックアップと、その下でより多くの社員の方々にアピールして効果を実感してもらい、プロジェクトへの理解を得ることです。

BPMシステムの構築はビジネスプロセスの継続的な改善に不可欠です。実際に多くの人に理解してもらい、携わってもらうことにより、企業風土がよりプロセス指向になっていきます。実際に何年もBPMシステムを構築し、展開・運用しているある企業では、業務改善に関する様々な話を、ビジネスプロセスに置き換えて話しをする場面に何回か立会いました。企業文化が大きくプロセス指向に変わっていることを実感した瞬間です。

見逃せない効果として、情報システム部門に対するものがあります。情報システム部門の方々が、BPMシステム構築プロジェクトを一度経験すると、今までのシステム構築では得られない、実際に情報システムが業務改善に役立つことを感じることができます。そのため、BPMシステム構築に対するモチベーションが大きく向上するのです。

本コラムは、ビジネスプロセス革新協議会(BPIA)で活動するビジネスプロセスマネジメント(BPM)研究会のメンバーが協力して執筆しました。BPIAは、次代の企業にふさわしい組織・業務革新の「あるべきモデル」「導入活用定着手法」を究明し、企業競争優位性の確立とビジネスの生産性向上を目指して1999年に設立されました。また、BPM研究会はITベンダー、ITコンサルタント会社、ユーザー企業で実際に業務革新に取り組んできた専門家が、もっとも効果的/実践的な業務革新の手法を探求しているグループです。

執筆 執筆協力
渥美 懋(ビジネスモデル)
田岡 賢輔(富士ソフト
吉岡 亮(三井物産
赤城 宣幸(協和エクシオ
松尾 光
串田 昭治(クシダ経営研究所)
濱田 隆一郎(シグマクシス
安田 正義(アガトン
福田 雅人(三技協
青山 修二・臼井 琴美(BPIA事務局)

IT Leaders 毎月無料でお届けいたします

本誌は、読者登録いただくことにより、毎月無料でみなさまのお手元まで直接お届けいたします(書店などでは販売していません)。

企業の情報システムを担当する方々や事業部門のIT担当の方々、およびIT関連プロフェッショナルの方々を対象に、実践的に役立つ情報を掲載、幅広く業務にご活用いただけます。

IT Leaders新規購読お申し込みはこちらから
Ads by Google