PR
BPM:筋肉質で俊敏な企業になるために(第2章中編)
2. BPMとは
1) ビジネスプロセスの整理
ここでもう少し詳しくビジネスプロセスについて整理をしておきたいと思います。前回(第2章前編)の図1では、以下の注文処理を対象としたビジネスプロセスを図示しました。
- A.お客様から注文書をいただく。+お客様に注文確認書を送る
- B.社内で商品の手配と発送の手続きを取る。
- C.お客様に納品書をお送りする。
- D.お客様に商品が届き検収していただく。
- E.社内で売り上げ計上の手続きを取る。
- F.お客様に請求書をお送りする。
- G.お客様からの入金を確認する。
このビジネスプロセスは、「見積」「与信」「受注」「出荷」といった作業から構成されます。ビジネスプロセスを構成する作業はサブプロセスと呼びます。
次に、ビジネスプロセスを構成するそれぞれのサブプロセスについて、順序、内容、関係する組織、人、物といった観点から、それを構成する要素を以下のように明確にしておきます。
- 開始条件:サブプロセスが開始されるきっかけ。「受注」であれば「注文書」の受領が開始条件になります。サブプロセスがそのビジネスプロセスの最初のサブプロセスであれば、この開始条件はビジネスプロセスの開始条件と同一になります。
- 入力:サブプロセスにおいて、そのサブプロセス外からもたらされ、サブプロセスの遂行に必要となる情報あるいは物。例えば「受注」においては「注文書」が入力となります。入力がない場合もあります。
- 入力元:入力が送られてくる元。通常、人や組織、あるいは別のサブプロセス(先行サブプロセス(後述))。「受注」においては「顧客」が入力元です。
- 出力:サブプロセスの結果としてそのサブプロセス外に渡されるもの。「受注」においては「出荷指示」となります。
- 出力先:出力の渡し先。別のサブプロセス(後続サブプロセス(後述))、あるいは人や組織など。「受注」においては「出荷」が出力先となります。
- 作業内容:サブプロセスで「出力」を得るために行う一連の作業の内容。「受注」においては「注文書」から「出荷指示」を作成するための作業となります。
- 作業リソース:上記の作業内容を行う担当者や組織。「受注」においては「営業管理部門」となります。どの部門や担当かのみでなく、人数、作業予定時間も明確にしておきます。
- 先行サブプロセス:当該サブプロセスを実行するための前提となる先行するサブプロセス。「受注」においては「見積」となります。先行サブプロセスは必須の場合とそうでない場合があります。例えば「与信」は「受注」の先行サブプロセスですが、見積もりの金額が一定額以上でなければ実行されないこともあります。
- 後続サブプロセス:当該サブプロセスの実行を前提とする後続のサブプロセス。「受注」においては「出荷」となります。上記先行サブプロセスの場合と同様に必須の場合とそうでない場合があります。
以上のように各々の作業内容・作業順序などを明確に捉えることで、ビジネスプロセスが誰にでも分かるように「可視化」されます。またサブプロセスも、さらに粒度の小さい一連の作業として捉えることができる場合があります。これに対しても上記と同じ整理作業を繰り返して、入れ子構造になったビジネスプロセスとして整理することができます。このようにして全体から詳細へと対象範囲を区切りながら順次BPMに取り組んでゆくことができます。
2)BPMとは
ここから再びBPMの説明に戻りたいと思います。
「ビジネスプロセス:その1」にある「B.社内で商品の手配と発送の手続きを取る。」の場面を再度想定してください。皆さんは管理職の方々だと思いますので、営業事務などの担当のかたに、「この注文の発送手続きお願いね」で済んでしまうのではないでしょうか?ではその人がお休みだったときはどうしますか?しかも急ぎの注文だった場合に。だれか替わりの人に頼みますか?自分でやりますか?でもだれもやり方を知りません。今日中に手続きしないと他社に頼むとお客様には言われています。
「B.社内にて商品の手配と発送の手続きを取る。」は前述のようにビジネスプロセスを構成するサブプロセスとして捉えることができるものですから決まった進め方はあるはずです。しかしその進め方が、担当者以外の人にも理解できるように文書などに整理されていなければ業務に支障をきたしてしまいます。
皆さんの会社にも仕事を熟知したベテランの方々がいらっしゃることと思います。その方々が退職した後でも滞りなく業務が進められるような仕組みを持っていますか? それを可能にするためには業務をビジネスプロセスとして捉え、それを明確化した上でマニュアルや規程として文書化し、組織の中で共有してゆく必要があります。これが「可視化」と「共有化」です。
では実際に業務をビジネスプロセスとして捉えて整理して行く「可視化」を皆さんの会社で行う場面を考えてみてください。この作業はBPMの第一歩です。業務の中に存在する作業を洗い出し、作業の相互の関連やそれぞれの作業業務の順序、必要なリソースなどを明確にして行きます。
そのとき「可視化」を担当する人はいろいろな業務の担当者に話を聞いたり、業務規程などの文書を調べたりすることになります。多分そのときにいろいろな疑問にぶつかることと思います。「何でこの順序で作業を行うのだろうか?」「似た作業を何回か行っているが、同じやり方に統一できないのだろうか?」などです。
もちろん、それぞれに理由や経緯があることと思いますが、単にいままでのやり方を踏襲してそうなっているだけかも知れません。もっとよい作業の順序があるかも知れないことに皆さんは気づくはずです。つまりビジネスプロセスには改善の可能性が多分にあるということです。重複している作業や無駄な作業をなくし、業務の効率化を図ることができます。これが「最適化」です。また、ビジネスプロセスの中の類似した作業については、皆が同じやり方でできるように統一してゆきます。こうして、一連の作業を皆が同じ進め方でできるようにします。これが「標準化」です。
このようにBPMでは業務をビジネスプロセス(前述したようにそう捉えることができるものを対象としますが)として整理することで、誰にでもわかるように「可視化」・「最適化」し、「標準化」して、その上で「共有化」を進めて行きます。こうして重複した作業や無駄な作業をそぎ落として行くことができるのです。またこの活動は一過性のものではなく、継続してゆかなければ意味がありません。ビジネスは刻々と変化します。それに合わせてビジネスプロセスも変化する必要があるからです。
ここでBPMについて整理してみます。
BPMとは:事業戦略を効果的・効率的に実現する為に、ビジネスプロセス(BP)を継続的に改善してゆく手法
BPMを構成する基本要件は以下の4つです。
- 「可視化」:一連の作業を誰にでもわかるようにすること
- 「最適化」:一連の作業から重複や無駄を省き、最大の効果が得られるように作り変えること
- 「標準化」:誰が行っても同じに進めることができるように一連の作業を決めること
- 「共有化」:可視化され標準化された一連の作業が関係者に理解され利用できるようにすること
なお、BPM自体は情報システムの存在を前提にしていませんが、現在では情報システムを抜きにしたビジネスプロセスの実現を考えることは困難です。情報システムをうまく活用することでBPMは最大限の効果を得ることが可能になります。「標準化」されたビジネスプロセスは情報システムの適用には非常に相性のよいものとなるからです。
3)BPMの進め方
ここでBPMの進め方の概略を整理してみましょう。以下のステップが典型的な進め方です。
(1)業務に係る問題認識と目標の設定
これはBPMを始める契機です。通常であれば何も課題がなければBPMを始める必要性を誰も感じないはずです。 実際には多くの問題が業務に潜んでいる場合が多いのですが、認識されていなければ経営幹部はBPMを始めようとは思いません。 まず問題が認識されて、BPMを行うための目標が設定されなくてはなりません。あるいは問題意識とまではいかなくても今の仕事のやり方をBPMにより見直すことは非常に有用であり、それをBPMの契機としている会社も多数あります。
(2)現状の業務の可視化:As is Model
現在行われている業務を「(1)ビジネスプロセスとは」で説明した定義に従って分解・整理し可視化(業務フロー図などを作成)します。
(3)問題の明確化・マッピング
現状のビジネスプロセス上に、業務上の問題点をマッピングして、どの部分・プロセスに問題があるかを明確にします。
(4)あるべきビジネスプロセスの作成:To Be Model
把握した問題点に対し、作成したプロセスのどの部分にどのような対応策を施すか、あるいはどのようにプロセスを修正するかを検討します。そして、あるべきビジネスプロセスを作成します。またここでは作成したプロセスが正しく運用できるか検証しておく必要があります。そのためにはそれぞれのプロセスの遂行に必要となるリソース(人員)と、そのプロセスで処理できる仕事量を算定します。その上で実際の業務が流れた場合にボトルネックが発生しないかなどについて検証しておきます。
上記(2)、(3)、(4)の詳細については、第4章にて詳述します。
(5)あるべきビジネスプロセスの実業務への適用
新しいビジネスプロセスを実際の業務の局面に適用して運用します。現在の仕事の進め方をあるべきビジネスプロセス(To Be Model)に置き換え、あるいは修正していく作業です。尚、ここは、ビジネスプロセスの実体の多くを担うことになる情報システムへの対応(第2章完結編「BPMと情報システム」参照)が大きな割合を占めるケースが多くなります。つまり、「あるべきビジネスプロセスのためにどのような情報システムを導入するのか」あるいは「既存のシステムをどう改変すべきか」などの情報システムの構築面も含めて進めて行きます。これについては第5章にて詳述します。
(6)評価とモニタリング
「問題は解消されたか、あるいは改善されたか」の効果の測定を行い、BPMの効果を検証します。ここで正しく効果を検証するためには、効果の測定方法を何らかの手段で定量化しておく必要があります。「(4)あるべきビジネスプロセスの作成」のシミュレーションで算出した効果との比較を行うのが有効な方法です。また評価は一度行って終わりではありません。効果を随時検証すること、つまりモニタリングが必要になります。
ビジネスプロセスは経営環境の変化や事業構造の変化などにより常に変更が起こります。したがってこれに対応すべきBPMは継続的な活動です。上記のステップを繰り返し行うことで、ビジネスプロセスを継続して改善して行きます。
4)BPMとBPR
BPMとよく似た概念として認識されているビジネスプロセス・リエンジニアリング(BPR)について少し言及しておきます。BPRはその名のとおり、プロセス改革を行うものです。プロセスを良いものにしようという点ではBPMとBPRは共通していますが、BPRが「改革」をねらいとしている一方BPMは「改善」をねらっています。では具体的にどのように異なるのでしょうか?表1に相違点をまとめています。
| BPR | BPM | |
|---|---|---|
| 変化の度合い | 抜本的 | 漸進的 |
| 始め方 | 白紙から | 既存プロセスから |
| 変化の頻度 | 一回 | 継続的 |
| 期間 | 長期 | 短期の繰り返し |
| 進め方 | トップダウン | ミドルアップダウン |
| リスク | 高い | 低い |
| 成功要因 | 情報技術 | 情報技術+組織能力 |
BPRではプロセスを抜本的に見直して、白紙の状態から新しいプロセスを一度に構築してゆくのに対し、BPMでは既存のプロセスを出発点として漸進的に継続的なプロセス改善を進めてゆきます。また、BPRはトップダウンで進めますが、BPMでは上から下まで一体となって進めることが必要となります。抜本的な改革である分だけBPRはBPMに比べてリスクは高くなります。情報技術を活用する点では共通しますが、BPMではそれだけでなく、組織としての能力を高めてゆくことが必要とされます。
本コラムは、ビジネスプロセス革新協議会(BPIA)で活動するビジネスプロセスマネジメント(BPM)研究会のメンバーが協力して執筆しました。BPIAは、次代の企業にふさわしい組織・業務革新の「あるべきモデル」「導入活用定着手法」を究明し、企業競争優位性の確立とビジネスの生産性向上を目指して1999年に設立されました。また、BPM研究会はITベンダー、ITコンサルタント会社、ユーザー企業で実際に業務革新に取り組んできた専門家が、最も効果的/実践的な業務革新の手法を探求しているグループです。
- データセンター見積もりは「DC完全ガイド」
最新iDCやテクノロジ・製品情報が満載。iDC事業者・サービスカタログで見積もり資料請求にも対応 - レンタルサーバー比較検索「RS完全ガイド」
共用・専用・VPS、国内1600以上のレンタルサーバー/ホスティングから最適なサービスを比較検索 - クラウド比較検索「クラウドサービス完全ガイド」
企業に役立つクラウド関連記事、製品・サービス情報



