BPM

出典: Q-BPM

BPMとは、業務プロセスの変更改善を継続的に行い、それを管理し、そしてあるべきプロセスに近づけると言う経営管理概念。Business Process Management。

BPMサイクル

1 BPMの概要
- 1.1 BPMの特徴
- 1.2 BPMサイクル
2 BPMの目的
- 2.1 BPMの副次的な効果
3 BPMの種類
- 3.1 BPMの方法論
- 3.2 プロセス定義の方法論
4 BPM関連の沿革(世界)
5 BPM関連の沿革(日本)
6 BPMの現実
7 BPMの邦訳
8 関連記事
9 関連英語記事
10 参考文献

BPMの概要

BPMとは、業務プロセス（Business Process）の変更改善を継続的に行い、それを管理し、そしてあるべきプロセスに近づける経営管理活動を指す。

具体的には、各プロセス内のタスクを「定義設計」し（Process Modeling）、その定義に従った「業務実施」を統制し（Process Operation）、業務実績を「モニタリング」する（Process Monitoring）。そしてそれらを循環的に反復する事で、事業環境に適したプロセスを模索し続ける活動を指す。言いかえれば、社内業務プロセスに関する改善サイクル（PDSサイクル／PDCAサイクル）そのものとも言える。BPM活動は、成果だけを管理対象とするのではなく、成果に至る「各タスクの順序」や「各タスクの入出力内容」や「担当者や担当コンピュータシステム」と言ったプロセス定義（プロセスモデル）だけではなく、その実行状況実態である「処理中のプロセス/完了したプロセス」（プロセスインスタンス）についても管理対象とする。

BPMの循環的な管理活動

なお、業務プロセスへの着眼は、1993年に発表されたBPR（Business Process Re-engineering）において最初に行われたが、必ずしも多くの成功事例を導いた訳ではなかった。すなわち、BPRもBPM同様に企業内業務プロセスをあるべき姿に変更する経営管理概念であったが、“一度きりの大々的な改革”と言う認識が強く、投資対効果を疑問視される傾向が強かった。その後、2002年ごろになって「継続的なBPR」としてBPMが概念化されるに至る。

まれに「Business Process Modeling」の略ととらえ、プロセスモデルの作成の事を指しているケースもある。

BPMの特徴

循環反復：　業務プロセスの改善は単発プロジェクトではなく、改善サイクル（PDSサイクル／PDCAサイクル）に則って、反復して実施される。
モデル化：　社内にある様々な業務プロセスを管理する事に主眼が置かれるため、その「俯瞰的な把握」や「新しいプロセス定義」のためのモデル表記（業務プロセス図(Business Process Diagram)）が多用される。
権限管理：　ワークフローが対象としてきた手順の定義だけでなく、各タスクの実行者や実行者権限についても管理し、その最適化を図る。
ＩＴ支援：　「プロセスモデルの管理」あるいは「実行状況(プロセスインスタンス)の把握」等は、情報システムを活用した実現を前提としている事が多い。なお有効な支援機能を備えたコンピュータシステムを、BPMシステム（BPM System：BPMS）あるいはBPMスイート（BPM Suites：BPMS）あるいはBPMソフト（BPM Software：BPMS）と言う。実際にBPMSで支援される機能例はこちら。

BPMサイクル

Model(Plan)：　プロセスモデルを定義する。情報システムの調達を含め必要な環境を整える。
Operate(Do)：　定義に従って、また環境を利用して、業務を実行する。
Monitor(Check)：　業務処理状況を把握する。業務処理結果を集計する。目標達成度を確認する。分析を通じて課題とその改善案を列挙する。
Optimize(Act)：　資源(人・装置・材料)配置、時間変更等、可能な範囲で課題改善を実践する。（プロセスモデルの設計までは行わない）

※なおBPMサイクルの個々のステップについて、様々な捕えられ方がある。例えば、支援システムの導入をDoステップの中核と考えAutomateやImplementと呼ぶことがある。改善案の列挙や新しいプロセスモデルの創造をActステップに含めImproveと呼ぶ例もある。また、Planステップは「仮説検証のためのシミュレーション」が第一義的にとらえる例、CheckステップをAnalyzeと呼ぶ例などがある。BPMの対象がプロセスモデルだけではなく、実行状況の把握も含まれている事に、根源的な原因がある。

BPMの目的

プロセス改善活動を通じて「企業に潜む問題やリスクを顕在化させる事」が第一目的と言える。（巨視的に言えば「企業を事業環境に適用させ続ける事」が目的であると言っても間違いではない）

現実には、弱点の改善と言う意味だけでなく、強みの強化と言う意味を含むものと言える。すなわち、「弱点の改善」の観点で言えば、定義されたプロセスに従って実行された業務処理について、例えば、処理コストのバラツキ、処理停滞、不正処理などが発生した場合には、その再発を防ぐために、第三者確認タスクの追加などの業務プロセスの変更を行う。場合によっては、業務プロセス図をもとに、事前にリスク想定を行い、業務プロセスの改変を行う。「(可視化に基づく)、ガバナンスの強化」と言っても良い。例えば単に「財務計算に関する書類その他の情報の適正性を確保する」様なコンプライアンス目的も含められる。

他方「強みの強化」の観点で言えば、例えば、自社の強みとなっている短納期配送を更に短くするための改良を検討するなど、競争力を強化させる活動を行う。一般的には、洗練されたビジネスプロセスの成果物QCDは担保され（成果物QCD担保・新人教育）、過去成果物の再利用が促進され（高業績者特性(ナレッジ)の共有）、定式化に伴う組織内競争（個人業績比較）が期待できる。

BPMの副次的な効果

リアルタイム監視：　成果達成までの乖離が常に把握できるだけでなく、異常や障害の発生を迅速に把握できる。
監査証跡の記録：　誰が、いつ、どのような決裁を行ったのか、記録する事ができ、実行責任の所在を明らかにできる。
ステークホルダ信頼の獲得：　社内プロセスがホワイトボックス化され、不正処理などの事故発生確率が下がる。
組織モチベーションの向上：　改善や変更が継続的に実施され、多くがその一躍を担う。「現状を打破できない」とあきらめてしまう組織とは本質的に異なる。

BPMの種類

業務プロセス内の各タスクが、「評価書作成」や「決裁」など人間に委ねられたタスクは「ヒューマンタスク（human task）」と呼ばれることがある。他方、「集計計算」や「物流センターの荷物仕分け作業」などのコンピュータシステムによって自動化されているタスクは「システムタスク」と呼ばれる事がある。

EAIとは
複数の企業情報システムを有機的に連携させるべく統合する事。Enterprise Application Integration。EAIを実現するソフトウェアとして、BEA Systems、Sun Microsystems、IBMなどのミドルウェアが利用されるケースが多い。

「ヒューマンタスク」の最適化を中心に考えるBPM活動を「Human-Centric BPM（HC BPM）」と呼び、「システムタスク」の最適化を中心に考えるBPM活動を「Integration-Centric BPM（IC BPM）」（あるいは「システムセントリックBPM」）と呼ぶ。「Human-Centric BPM」を支援するITはワークフローシステムから進化したものが多く、また「Integration-Centric BPM」を支援するITはEAIツールからの発展したものが多い。

BPMの方法論

トップダウンアプローチ：　経営者視点、上級管理職視点で、基幹プロセスから業務プロセスを改変させていくアプローチ。現状プロセス(As-Isプロセス)にとらわれることなく、事業戦略や経営計画に基づくあるべきプロセス(To-Beプロセス)を設計できる。全体最適化を実現させやすい。

ボトムアップアプローチ：　従業員視点、作業実施者視点で、組織末端の業務プロセスから改変させていくアプローチ。現状プロセス(As-Isプロセス)の小さな改良に注力される傾向が強く、業務プロセスを日々改善させる事ができる。局所最適化を実現させやすい。

※当然ながら、トップダウンアプローチも、ボトムアップアプローチもともに必要な手法である。前者だけでは中央集権的な機能不全に陥る可能性が高く、他方、後者だけでは各部署の自由発散にともなって全体最適の実現が困難となる。業種業態や会社規模、会社文化に依存する話ながら、

「事業戦略・経営方針の共有」
「ボトムアップアプローチ」によるBPMサイクル実践
「トップダウンアプローチ」による是正

が一つの現実的な解であると考えられる。

プロセス定義の方法論

フローモデル：　業務プロセスの流れ方に関する定義。業務プロセスは、人から人、人からコンピュータ、コンピュータからコンピュータなど、場合によっては分岐や併合を伴って流れていく。

データモデル：　業務プロセス成果物の情報フォーマットに関する定義。業務プロセスは、最終的に何らかの成果物や副生成物を生み出す。逆に言えば成果物データの状態が遷移しているに過ぎない。稟議書で言えば、申請文、申請日、決裁フラグと言ったデータが投入される事になる。

権限モデル：　業務プロセスに関与する人々の権限に関する定義。業務プロセスは、様々な人間(担当者)が関与するケースが多い。

BPM関連の沿革(世界)

ビジネスフレームワーク	ワークフロー設計
1987年：　JAザックマン(IBM)、EAを提唱（PDF:17p） 1992年：　JAザックマン(IBM)、EAを拡張（PDF:27p） 1992年：　COSO、「COSO Control Framework」を発表 1993年：　Mハマー(MIT)ら、BPRを発表 1994年：　ITGI、内部統制フレームワーク「COBIT1.0」を公開 1994年：　COSO、「COSO Control Framework」の追記 2000年：　流行語「Webサービス」 2002年：　米国SOX法成立 2004年：　流行語「SOA」 2005年：　ITGI、内部統制フレームワーク「COBIT4.0」を公開	1970年代：エンティティによるモデル化活動(DFD、ER図) 1980年代：ビジネス要件のモデル化活動（CASE） 1997年：　OMG、「UML1.0」を公開 2002年：　WfMC、「XPDL1.0」を公開 2004年：　BPMI、「BPMN1.0」を公開（05月） 2004年：　OMG、「UML2.0」を公開 2005年：　OMGとBPMI、合併統合（06月） 2005年：　WfMC、BPMNに対応する「XPDL2.0」を公開（10月） 2007年：　OASIS、「WS-BPEL2.0」を公開 2008年：　OMG、「BPMN1.1」を公開（01月）

ビジネスフレームワーク

ワークフロー設計

1987年：　JAザックマン(IBM)、EAを提唱（PDF:17p）
1992年：　JAザックマン(IBM)、EAを拡張（PDF:27p）
1992年：　COSO、「COSO Control Framework」を発表
1993年：　Mハマー(MIT)ら、BPRを発表
1994年：　ITGI、内部統制フレームワーク「COBIT1.0」を公開
1994年：　COSO、「COSO Control Framework」の追記
2000年：　流行語「Webサービス」
2002年：　米国SOX法成立
2004年：　流行語「SOA」
2005年：　ITGI、内部統制フレームワーク「COBIT4.0」を公開

1970年代：エンティティによるモデル化活動(DFD、ER図)
1980年代：ビジネス要件のモデル化活動（CASE）
1997年：　OMG、「UML1.0」を公開
2002年：　WfMC、「XPDL1.0」を公開
2004年：　BPMI、「BPMN1.0」を公開（05月）
2004年：　OMG、「UML2.0」を公開
2005年：　OMGとBPMI、合併統合（06月）
2005年：　WfMC、BPMNに対応する「XPDL2.0」を公開（10月）
2007年：　OASIS、「WS-BPEL2.0」を公開
2008年：　OMG、「BPMN1.1」を公開（01月）

BPM関連の沿革(日本)

2005年09月：　情報システム学会(日本)、「業務プロセスの可視化」第一回分科会
2006年01月：　日本BPM協会、設立
2006年06月：　日本版SOX法の施行
2007年12月：　日本内部統制研究学会、設立

BPMの現実

パイロットプロセスの設定：　既に品質管理活動を実践している生産プロセスをBPMS上で管理する。
ホワイトカラープロセス：　多くが統制されていない業務プロセスにBPMNを導入し、決裁証跡を取得する。
プロセスオーナーの任命：　各業務プロセス毎にプロセスオーナーを設定し、当該業務プロセスの改善サイクルに責任をもたせる。
フレームワーク活用：　COSO、COBIT、ITILあるいはCMMIや各種ISOなどのフレームワークをBPMサイクルに取り入れる。
社会基盤活用：　XBRL、SOX法対応などを契機に、BPMサイクルを開始する。
属人的プロセス：　業績管理、顧客管理(CRM)、事業計画立案と言った極めて俗人的だった業務プロセスを整備する。

モデリング(Plan)による改善

共通化：　多部署で同じプロセスを利用し、業務処理ノウハウを共有する。
自動化：　「規定に基づく回付先の判断」や「累積金額の算出」など、人間でなくても良い処理はシステムに処理させる。
冗長排除(集約化)：　部署内で閉じていたプロセスを横断させ、データの一元管理など「二重タスクの回避」や「停滞の無い業務処理」を実現する。

モニタリング(Check)による改善

人員配置：　熟練者を分散して配置する。処理時間がかかる新人を分散して配置する。
警告監視：　一定時間以上の処理滞留時には当人および上司にアラートを流す。

BPMの失敗

実装の失敗：　モデリングした業務プロセスに従って業務を推進すべく、システム化(実装)しようとするも、時間がかかりBPMサイクルが回らなくなる。
詳細度不足：　社内の業務プロセスを網羅的に文書化することに注力した結果、いずれの業務プロセスも詳細な記述が無い。
コンサルタント任せ：　モデル化や分析をすべてコンサルタントに委任してしまい、BPMサイクルに無関心になる。
方針の不明瞭：　あるべき業務プロセスを議論するベースとしての事業戦略や経営計画が無い。
IT知識不足：　IC BPMを推進を行うエンジニアが少ないにも関わらず、全社システムにSOAの概念を取り入れる。

BPMの邦訳

日揮情報ソフトウエア社による標準化団体BPMN仕様書訳やワークフローパターン文献訳等において「Business Process Management」の邦訳は「ビジネスプロセス管理」とされ、また、「Business Process」の邦訳は「ビジネスプロセス」に統一されている（その他「ビジネスプロセス図」など）。

他方、金融庁による意見書やＱ＆Ａ文書等においては、「Business Process Management」に直接的に該当する表現はなく、「業務プロセスに係る内部統制」や「業務プロセスの評価」と言った記載となっている。なお「Business Process」に該当する表現は、全て「業務プロセス」に統一され、また「Business Process Diagram」に該当する表現については「業務の流れ図」あるいは「フローチャート等」と記載されている。