SOA/BPMの現場から - 日本のお客様事例
第2回 BPMとは？ - いまさら聞けない？BPM
日本オラクル株式会社 テクノロジーコンサルティング統括本部
市川 義規 (いちかわ よしのり)
目次
序文
自己紹介
皆さん、はじめまして！日本オラクルの市川です。本稿では、BPMの基本的な内容をご説明します。BPMについてご説明する前に、まずは簡単に自己紹介をさせてください。私は、日本オラクルのTechnology Architectコンサルティング部SOA/BPMチームという部署に所属しています。 私たちのチームでは、1人当たり年間数件から10件程度、SOAやBPMに関連する製品を使ったお客様のシステム開発のプロジェクトに参画しています。 コンサルティング部という部署名ではありますが、企画や要件定義と言った工程だけではなく、システム設計や開発、お客様によってはテスト、運用まで幅広い工程に参画します。 私たちは、いわゆる製品のプリセールスを担当しているわけではありません。製品のサポート担当でもありません。プロジェクトに参画し、プロジェクトを成功させることに責任を負っています。
この文章について
本稿は、 Oracle Direct Seminar で行った下記のセミナーから内容を抜粋し、記事としてまとめたものです。
- 本邦初公開！現場担当オラクルコンサルタントが語るBPM - BPA Suiteの活用
- オラクルコンサルタントが語る最新BPM事例！！業務プロセスのモデリング方法論
- オラクルコンサルタントが語る最新BPM事例！！BPMとBAMの関係
これまでの私たちの経験と実績から、BPMプロジェクトの現場についてまとめております。実体験を元にしているので、一般的なコンセプトと比較すると偏りがあるかも知れませんが、ご了承いただきたく思います。
BPMとは？ - いまさら聞けない？BPM -
BPM超入門
この記事は、BPMという概念の有効性について説明しています。私たちの目的は、BPMが企業の業務改善に対して有効な手法であることを、読者の皆さま（この記事を読んでいる貴方！です）にご理解いただくことです。 私たちはBPMの有効性を確信していますが、読者の皆さまの認識はそれぞれだと思います。BPMに一定の効果を認めている方、BPMは知っているものの有効性には半信半疑の方、BPMという言葉をはじめて聞く方…皆さまにBPMの有効性をご理解いただくには、まず原点に立ち返り、「BPMとは何か」というところから、話を始める必要があると思います。
「はじめに言葉があった、…」といったら原点に立ち返りすぎかもしれませんが、まずはBPMという言葉を考えたいと思います。 BPMはBusiness Process Management（業務プロセス管理）の略語です。Business Process Modeling（業務プロセスモデリング）、Business Performance Management（企業パフォーマンス管理）という単語もありますが、今回は別の話です。 ビジネスプロセス管理としてのBPMは、その言葉の通り、業務プロセスに着目して業務を改善する手法です。
BPMの歴史と再定義
業務プロセスに着目する考え方や手法は、何年も何十年も前から、様々な提案が行われています。高名な「シックス・シグマ」は1980年代から実践されている方法です。シックス・シグマの元になったQC活動は1960年代まで遡ることができます。 あるいは、プロセスを中心に据えたARISフレームワークで有名なIDS Scheer社の設立は1984年です。他にも、1990年代に提唱されたBusiness Process Re-engineering: BPRのことも、1993年のマイケル ハマーによって著された書籍「リエンジニアリング革命―企業を根本から変える業務革新」とともに思いだされるかもしれません。
上記のように、BPMには複数のルーツがあります。そして、現在のBPMに対しても、複数の視点があります。実際、BPMについて述べた書籍は少なくありません。 日本語の代表的な文献は例えば下記のとおり、
- BPM BASICS FOR DUMMIES(日本語版), Software AG, 2008
- BPMがビジネスを変える, 日沖 博道, 2006
- BPM? (BPM Story), Questetra Inc., 2009
英語の代表的な文献は、例えば下記です。
- Business Process Management Enabled by SOA, IBM Redpaper, 2009
- BPM Technology Taxonomy: A Guided Tour to the Application of BPM, SAP/Accenture White Paper, 2009
様々な視点を持つことは重要ですが、視点によってはニュアンスに違いもあるので、BPMという概念が曖昧になってしまいます。そこで私たちは、これまでの様々な取り組みを踏まえて、「BPMとは下記の3つの特徴を持つもの」と定義します。
- プロセス指向
- モデル駆動
- 継続的改善運動
プロセス指向 - BPMの特徴 (1) -
ひとつめの特徴である「プロセス指向」は、「プロセスを中心にして考える」という意味です。「データ中心」でも「画面中心」でもありません。 また、誤解しやすいところですが、「プロセスだけを考える」というのも異なっています。プロセスを中心にして、業務に関連する様々な情報を収集、分析、改善します。
なお、「データ中心」というのは、1980年代頃から大きく注目され、多数のシステム開発プロジェクトに適用されたData Oriented Approach、略してDOAのことを指しています。DOAという手法は、システム開発をする上でとても有効であり、今なお現役でシステム開発に適用されています。 しかし、DOAには、エンドユーザーに対して敷居が高い側面があります。DOAではデータフロー・ダイアグラムなどのモデルを使用しますが、システム開発の担当者ならばともかく、実際にシステムを使うエンドユーザーには読み解くことがしばしば困難になります。
また、「画面中心」というのは、画面を使用した要件定義を指しています。「ペーパー・プロトタイピング」という手法を聞いたことがある方も多いのではないでしょうか。画面を提示することでユーザーにシステムのイメージを想起させることができ、これも非常に有効な手法です。 しかし、ここで確認できるのはシステムを使った業務のみであり、業務改善を考えると、人だけで行われる作業など業務全体の把握に、やや不安が残ります。
そこで、データ中心の難解さ、画面中心の網羅の不十分さを改善するために、プロセスを中心に据えます。決してプロセスだけに注目するわけではなく、プロセスの周辺の情報（プロセスを実行する人や組織、システム、情報の入出力など）も対象です。 業務プロセス、すなわち業務の手順は、エンドユーザーがまさに日常的に実施している作業を明文化したものであり、業務改善に必要なユーザーの理解を深め、業務に関わる情報の網羅を実現できます。
図1 プロセスを中心に据えた業務分析のイメージ
ひとつの業務を実施する場合、図のように様々な人／システムが関わります。電子メールの受信を起点とする、システム間で連携を行う、人がシステムを操作する、人と人がコミュニケーションを行う…プロセスを中心に分析することで、こういった様々な相互作用を明らかにすることができます。
モデル駆動 - BPMの特徴 (2) -
二つ目の特徴の「モデル駆動」では、モデルと呼ばれる特定の図を用いて業務の情報をまとめます。モデルは様々な種類が存在します。例えば、先ほど言及したDOAでは、データフロー・ダイアグラムというモデルを使用します。情報をまとめる上でモデルを使用することは、BPMに限らず様々な手法で利用されています。BPMでは、プロセス指向に適したモデルを使用します。
ここで「モデル駆動」という場合、単にモデルを使用するだけではなく、使用したモデルから様々な成果物に派生することを想定しています。 BPMのモデル駆動では、モデルを使って業務の情報をまとめるだけではなく、作成したモデルをシステム上で動作させることを指しています。BPMで使用されるモデルの中で、代表的な位置を占めるBPMNでは、モデルをシステム上で動作させるための取り組みがなされています。
図2 モデル駆動によるシステム化のイメージ
業務分析や改善検討の集まりで行われた議論は、上述したようにモデルに集約します。この図で紹介しているモデルは、業務プロセスを中心として組織、データ、機能、プロセス、製品／サービスといった情報を関連付けてモデルを構成します。作成したモデルを基にして、適切な情報付与を行い、システムで稼動させます。
継続的改善運動 - BPMの特徴 (3) -
最後の特徴は「継続的改善運動」です。BPMでは、業務改善への取り組みを継続的に実施し、段階的に改善を進めます。これは、広く知られているPDCAサイクルの考え方に似ています。
PDCAサイクルはPlan（計画）、Do（実行）、Check（効果確認）、Act（課題の解消）の４つのステップの頭文字を取って名づけられています。PDCAサイクルで重要なことは、最後のActで課題の解決に取り組み、その取り組みを次のPDCAサイクルのPlanにつなげることです。こうすることで、PDCAサイクルは循環し、業務は螺旋状に改善されます。
継続的なアプローチは、物事を段階的に進める上でも効果的です。全ての業務を一度に改善することは難しく、一部の業務を改善して、その取り組みを周辺の業務に波及させることは、より容易です。継続的改善運動であれば、小さな業務からはじめることができます。
継続的な取り組みで注意すべきことは、高名なラショナル統一プロセスでも指摘されているように、ひとつのサイクルを明確に定義することです。反復が可能であるということは、問題を先延ばしにできるということとは異なっています。 BPMでは、Planのフェーズで対象となる業務領域、効果測定の手段を定義し、それに基づいてDo、Check、Actと続けることが求められます。
図3 PDCAサイクルによる継続的改善運動のイメージ
BPMにおける継続的改善運動のサイクルは、BPMを紹介する文書によって細部が異なっています。共通しているのは、4つから5つのステップを繰り返して実施することで、継続的に業務を改善するということです。本稿では、QC活動などで馴染みが深いPDCAサイクルをご紹介しています。
BPMのメリットは何か？ - プロジェクト事例から -
BPMの基本的なメリット（改善効果）
ここでは、BPMの概要に続いて、BPMのメリットを述べたいと思います。「BPMは業務改善手法」と述べましたが、実際にどのように業務が改善し、どんな改善効果が得られるかを整理したいと思います。 まず申し上げたいことは、「BPMでは、業務プロセスの課題点が解消される」ということです。「業務プロセスの課題点」とは、例えば下記のようなものです。
- 適切な権限を持った人に限定される作業に、権限を持たない人が従事している
- システムが自動的に行えるような定型的な作業を人が行っており、作業効率が悪い
- 業務の手順や進捗状況の把握が属人的であり、可視化されていない
- 作業を実施する上で、人が何度も重複した行動を行う必要があり、作業に無駄が多い
図4 業務プロセスの課題のイメージ
この図では、業務プロセスにまつわる様々な課題とリスクを紹介しています。「機会損失」「非効率」「改ざん」「ミス」をリスクの例として挙げています。ここで挙げられている課題は、いずれも基本的なものであり、読者の方には幼稚に映るかもしれません。しかし、これらは実際にお客様が抱えていた課題であり、 BPMプロジェクトで解決してきたという事実があります。
BPMでは、これらの課題点に対して、BPMの特徴に基づいた改善を行います。例えば、下記のように実施されます。
- 業務プロセスとそれを実行する役割を整理し、適切なアクセス制限をかける
- 業務プロセスの作業について、人が行えるもの、行うべきものと、システム化できるものを分離し、システム化を進める
- 業務プロセスの情報と、業務プロセスを実行／管理する上で必要な情報を整理し、実行者／管理者に提供する仕組みを作る
- 複数の業務プロセスの作業の重複を整理し、集中化して重複を排除する
このように、BPMによる業務改善の内容は、決して特別なものではありません。ただし、BPMには先に述べた3つの特徴が存在するため、従来の業務改善の手法よりもユーザーに近く、より業務プロセスの課題点に迫った分析と改善案の検討が可能です。
効果拡大へのヒント - 応用編 -
前章でBPMの基本的なメリットについて述べましたが、これらはプロジェクトの効果として十分であるとは限りません。一般にBPMプロジェクトを実施するには、BPMに詳しいコンサルタントや、BPMシステムに詳しいエンジニアが必要です。加えて、エンドユーザー側から業務知識を提供する必要もあり、プロジェクトに対する投資額は小さくないケースが多いでしょう。
BPMプロジェクトは、改善効果が期待しやすい領域（Low Hanging Fruits - 手の届く高さに実った果実 -）から小さくスタートすることが推薦されますが、小規模の導入段階から効果の拡大を意識することは重要です。 ここでは、実際のBPMプロジェクトで適用された、BPMプロジェクトの効果拡大の仕組みを2つ挙げて、解説します。
誤解を受けやすいところですが、BPMは贅沢なソリューションではありません。以前、米国の情報サイト"TechRepublic"にあった面白いエントリ"10 best practices for business process measurement"では「BPMはアイスクリーム・サンデーの頂上のチェリーのように言われている。チェリーはあれば見栄えがするが、無くてもそれほど困らない。しかし、これは誤解であり、事実とは異なる」とありましたが、全く同感です。BPMを頂上のチェリーにすることがないように、業務改善効果の達成を計画するべきです。
プロジェクト事例 (1) - コスト削減 -
BPMプロジェクトの基本的な改善策の1つとして、「業務プロセスの情報と、業務プロセスを実行／管理する上で必要な情報を整理し、実行者／管理者に提供する仕組みを作る」という項目を挙げました。この項目では、属人的な業務の手続きを明文化すると同時に、業務の進捗状態も明らかにします。この考え方は、業務のやり方を標準化し、地域や慣習の違いを乗り越えて業務を進められることを意味しています。
あるプロジェクトでは、業務の標準化について、さらに深く踏み込みました。いままでは各地に点在していた営業事務を集中化することで、営業事務に費やしていた販管費を低減しています。BPMプロジェクトで業務プロセスを整理しただけでは、プロジェクトの効果は業務の品質向上にとどまったかもしれません。 しかし、このケースでは組織変更や人員の再配置まで踏み込んで実施したことで、販管費を低減しコスト削減まで達成しています。
プロジェクト事例 (2) - サービス品質の向上 -
もうひとつの事例では、お客様へ提供するサービスの品質向上がテーマになっています。この事例では、BPMプロジェクトの基本的な改善策の1つである「複数の業務プロセスの作業の重複を整理し、集中化して重複を排除する」がベースになっています。多くの場合、対象となる業務プロセスは、ユーザー企業の社内に重点が置かれますが、このプロジェクトでは、ユーザー企業にとってのお客様の動きに着目しています。
お客様の手続きの重複に着目し、お客様の手続きの重複を取り除くために、業務プロセスを再定義しています。社内の業務の無駄を排除するだけでなく、お客様へ提供するサービスの内容に踏み込むことで、提供サービスの品質向上を達成しています。
ハウ・ツー・BPM？ - どうすればBPMができるか？ -
BPMプロジェクトを準備する
これまでに、「BPMとは何か？」、そして「BPMのメリットは何か？」についてご紹介しました。BPMは歴史ある手法を引き継いだ概念で、基本から応用まで様々なメリットがあることがご理解いただけたと思います。 ここでは、実際のプロジェクト経験に基づき、BPMの進め方についてまとめたいと思います。まず、BPMを実施するにはBPMプロジェクトを立ち上げる必要があります。BPMプロジェクトは、一般的なプロジェクト同様に、体制やスケジュールを策定する必要があります。体制には、業務に詳しいユーザー、BPMに詳しいコンサルタント、BPMシステムに詳しいエンジニアの参画が求められます。スケジュールも、既存のBPMプロジェクトに基づいた見積りを根拠に策定されるべきでしょう。特に「BPM」プロジェクトで重要なことは、上記に加えて3つあります。
ひとつは、対象業務の選定です。上でも触れたLow Hanging Fruitsの考えに従って、効果が見込みやすい業務を選定し、それらの業務を優先して取り組むべきです。
2つめのポイントは、プロジェクト評価指標の定義です。上でも挙げたように、BPMプロジェクトには基本から応用まで様々なメリットがあります。 今回のプロジェクトで期待すべき効果を選定し、評価指標を定義することで、プロジェクトの目的がぶれないようにするべきです。評価指標は定量的に計測できるものが望ましく、計測の方法まで定義できれば最善です。
最後のひとつは、BPMプロジェクトを実施する上でのフレームワークを決定するべきです。フレームワークは、例えばこの記事の冒頭で触れたシックス・シグマのような広範な方法論もありますし、BPMNやEPCといったモデル記述言語に関するものもあります。 モデルを描くためのツールを含めても良いと思います。対象とする業務の属性に基づき、適切なフレームワークを選定することで、BPMプロジェクトを円滑に進めることができます。
BPMシステムを使いこなす
多くのBPMプロジェクトでは、BPMシステムを必要とします。BPMシステムは、上で挙げたBPMの改善策を、システムの視点から支えるものです。BPMシステムを実現するために、様々な製品が販売されていて、日本オラクルでもBPMを実現するための製品をご提供させていただいております。
製品／技術情報
- Oracle Business Process Analysis Suite 業務モデルを作成するためのモデリングソフトウェア。
- Oracle Business Process Management 特に人と人とをつなぐBPMに効果を発揮するソフトウェア。
- Oracle BPEL Process Manager BPMシステムとして、業務モデルを実行するエンジン。
- Oracle Business Activity Monitoring 業務プロセスの実行状況を可視化するモニター。
BPMシステムを構築する上では、BPMシステムや、それを構成する製品に詳しいエンジニアの存在が不可欠です。また、BPMシステムに限らず、一般的なシステム開発全般に必要なことですが、プロジェクトで定義された新業務プロセスや効果測定の仕組みについて、BPMシステムが担当すべき箇所を特定し、スムーズなシステム開発につなげることで、システム開発に関するリスクの低減が求められます。
成功要因は人、失敗要因も人
BPMを実現するために、BPMプロジェクトの準備や、BPMシステムの開発について述べました。これらを成功させる助けとして、フレームワークや製品といったツールが提供されており、効果的に運用することで、プロジェクトの成功に貢献します。しかし、過大な期待は禁物です。これらは所詮、ツールでしかありません。プロジェクトが成功させるのも、期待はずれに終わらせるのも、最大の寄与は人にかかっています。
ゴルフを例にあげて考えてみましょう。ゴルフのスコアに貢献するのは、良いゴルフ用品でしょうか？それとも、優れたキャディでしょうか？…良いゴルフ用品も、優れたキャディも、使い方次第で得がたい価値を享受できます。しかし、いずれも脇役の域を出ることはありません。プレイヤーが使い方を理解し、実践することなくして、スコアの向上は見込めません。
BPMについても同様のことが言えます。BPMに詳しいコンサルタントやエンジニアと契約したり、BPMに関連する製品を購入したりすることは、BPM成功の第一歩です。しかし、それだけでは十分ではありません。ユーザーがBPMを理解し、上のプロジェクト事例でも触れたように、BPMの内容に踏み込んでいかなくては、成功は難しいといえます。
BPMに限らず、どんなプロジェクトでも主役は人ですが、特にBPMはユーザーがキーパーソンになる領域であるといえます。まとめ
この記事の目的は、BPMが企業の業務改善に対して有効な手法であることを、読者の皆さまにご理解いただくことでした。そのために、「BPMとは何か？」という問いかけを皮切りにし、「BPMのメリットは何か？」、「どうすればBPMができるか？」という質問に答える形で、BPMについて記述してきました。
日本オラクルが提供するBPMソリューションについて、ご興味を持っていただけた方には、ぜひ下部のリンクからOracle Directにお問合せいただきたく思います。プロジェクト事例をはじめ、BPMプロジェクトのはじめ方など本記事の詳細について、ご説明させていただければと思います。
本連載は、引き続きSOA/BPMに関連したコンテンツをご提供させていただく予定です。今後とも、「 SOA/BPMの現場から - 日本のお客様事例 -」をよろしくお願いいたします。
日本オラクルのコンサルティングサービス部門（Oracle Consulting Service Japan [OCSJ]）の中で、テクノロジーコンサルティング統括本部では、約200名 のコンサルタントが年間約200プロジェクトでテクノロジー製品全般に関する支援を行っています。
支援対象のシステムには、本稿で紹介したBPMの業務改善プロジェクト、SOAのシステム設計のほか、Oracle WebLogic Server／Oracle データベースを使ったシステム基盤に求められる高可用性、大規模システム、新機能実装システムなどが数多く含まれており、これらシステムの実践的な構築スキルやノウハウを日々蓄積しています。企業システムにおける最適な戦略の企画・策定から、迅速なインプリメンテーション、安定稼働まで、日本オラクルのコンサルティングサービスは、お客様特有のニーズを満たしたサービスを提供します。
日本オラクルのコンサルティングサービスに関するお問い合わせは、 Oracle Direct 0120-155-096 まで。
"SOA/BPMの現場から - 日本のお客様事例 -" インデックスに戻る
Copyright © 2009, Oracle Corporation Japan. All rights reserved. 無断転載を禁ず
> この文書はあくまでも参考資料であり、掲載されている情報は予告なしに変更されることがあります。日本オラクル社は本書の内容に関していかなる保証もいたしません。また、本書の内容に関連したいかなる損害についても責任を負いかねます。
Oracleは米国Oracle Corporationの登録商標です。文中に参照されている各製品名及びサービス名は米国Oracle Corporationの商標または登録商標です。その他の製品名及びサービス名はそれぞれの所有者の商標または登録商標の可能性があります。
市川 義規 (いちかわ よしのり)
SOA/BPMチームのBPM担当コンサルタント。
お客様の成功に寄与するBPMを提供いたします。