ビジネスプロセス志向の組織体制とITプラットフォーム
2006/3/30
Agile Enterpriseに向けたBPMの活用
|
|||
Agile Enterpriseとは何か。KIU研究会第1回の貞金氏の話にもあったが、俊敏な企業だけが生き残る時代になった。変化への迅速な対応とリスク回避、PDCAのスピードが勝負の決め手となっている。機能中心からプロセス指向へ、そして顧客視点で優れたサービスを提供することが競争優位を築くことになる。
ご存じのとおり、米国のSOX法を基にした日本版SOX法（J-SOX法）の要件が決まりつつある。構成要素は、「統制活動」「情報と伝達」「監視活動」「統制環境」「リスクの評価と対応」に加え、「情報技術を利用した統制（IT統制）」の6つの柱で構成される。先に挙げた5つは米国でも柱になっているが、日本で考えたときにITの果たす役割が大きいだろうということで、IT統制を柱の1つに加え、検討を重ねている段階だ。
- - PR -
Agile Enterpriseに向けた業務改革を考えるとき、自社の経営陣および従業員の視点で、いかに業務プロセスを改善し、効率化していくかが重要なポイントになる。業務プロセスのライフサイクル（PDCAサイクル）では、戦略に基づいて計画・実行していかなければならないが、そこにはいくつかのボトルネックがある。例えば、10年前に基幹システムを作ったときといまの業務フローが違うといったような、現状の業務がどうなっているのか分からないケースだ。その場合、あらためて業務フローから精査していくことが少なくない。業務の設計をなんとかクリアしても、システム対応について「3年がかりで」といわれるケースがある。3年たったら業務の実態と合っていないことが考えられる。そして、システムが稼働しても、業務プロセスの改善の効果が分からないことがある。例外処理がどれだけ発生しているか、それをシステムで分かる仕組みになっていかなければいけないし、またどこにボトルネックがあり、うまく流れていないかも分からなければならない。
具体的な事例としては、購買業務は資材部が担当していて、お客さまは社内部門というケースがある。依頼に対し、約7日で処理されているが、10日かかることもある。顧客満足を高めるために、それを7日以内にしたいのだができないという相談があった。顧客満足度を高めるためには、どれだけ依頼があり、処理されたかのプロセスを見えるようすることが大事ではないかと提案した。このように、リスクにうまく整合させていくかが大事だ。
改革を進めていく場合、戦略を決めていく経営企画、それに対して業務を設定していくオペレーション、そしてさらに実行していく部門という体制で行われてきた。このとき、各部門の思惑がうまくかみ合うかどうかが課題となる。ビジネスプロセスを中心に考えていくことにより、これらをうまく連携させる仕組みを作ることが経営とITの融合につながっていくのだが、現状はなかなかうまくいっていない。
BPCCを中心とした取り組み
それを解決する1つの試みとしてBusiness Process Competence Center（BPCC）がある。これは、先ほどの戦略、オペレーション、実行という3つの分断された組織の階層を1つにまとめるもので、それぞれの組織から人を出し、「ビジネスのアーキテクチャ」「プロセスのエンジニアリング」「標準」「手法」などの定義をやっていこうというものだ（図1）。
 |
| 図1 BPCCは、3つの組織階層を結び付ける組織 |
BPCCは、企業の戦略をビジネスプロセスに落とし込み、効果的なオペレーションとして具現化するための専門組織として位置付けられる。専門組織とする意味は、いろんな組織にクロスファンクショナルなプロジェクトを立ち上げることもできるが、BPCCという形で継続的、恒久的に実施することで、知識やノウハウを1カ所に蓄えていくことが可能になる。
BPCCのもう1つの役割は、分断されたビジネスとITを連携する橋渡しだ。分断されている部分を、プロセス設計および手法、テクニカルアーキテクチャおよび手法により、ビジネスのコンポジットアプリケーションのような形でITを構築していくことで、分断されているところを融合していく試みだ（図2）。
 |
| 図2 BPCCは、ビジネスとITを橋渡しする手法やアーキテクチャを集約するものでもある |
BPCCのミッションを簡単にいえば、戦略上では、きちんと方針を決め、みんなで一致協力してやっていくこと、オペレーション上では、具体策を練り上げること、実行上では、小さいことからでもやり、改善し、確実にやっていくことだ。
ビジネスプロセス・アーキテクチャを定義するとき、どの程度の詳細までプロセスを設計すればよいかが課題になる。第3のレイヤまで設計すれば、業務担当者は「この辺でOK」と思うし、プログラマは「もう少し細かくしてほしい」ということになろう。価値の高いプロセスをどうやって抽出すればよいかといった疑問に答える基本設計方針として、ビジネスプロセス・アーキテクチャを定義する必要がある。そして、「標準」「手法」「ツール」を統一し、すべての関係者の共通言語として機能する必要がある。
BPCCは、“社内顧客向けにサービスを提供する組織”としてとらえることができる。提供されるサービスを社内のユーザー部門が抵抗なく受け入れるために、BPCCには標準を押し付けるのではなく、サービスを売り込む姿勢が必要だ。また、トップダウンが効きづらい大企業では、BPCCは1つの方向に動かす旗振り（チェンジリーダー）としての役目を担っている（図3）。その包括的な役割を実行するために、オーナーシップはCEOが取るべきで、ソリューション・アーキテクト／ストラテジスト、プログラムマネージャなど多様なスキルセットを有するメンバーで構成する必要がある。
 |
| 図3 BPCCは、サービス提供という視点を持つことも大切となる |
重要成功要因は図4のとおり。目新しいものはないと思うが、戦略上の優先順位と連動して計画を立てること。将来におけるビジネス上および技術上のニーズを理解し、短期的・長期的に想定される改善を考慮して適切な打ち手を検討・実行すること。プログラム／プロジェクトの品質とリスクの管理手法を組み込んでおくことなどが挙げられる。BPCCに配属されたときの評価やキャリアパスをどうするかを含めて、人事にも踏み込み、上っ面ではない取り組みが不可欠だ。
 |
| 図4 BPCCの重要成功要因 |
関連記事
- アジャイル・エンタープライズとは何か？（アジャイル・エンタープライズ）
 |
Page 1 Agile Enterpriseに向けたBPMの活用 BPCCを中心とした取り組み |
| Page2 ESAとそれを支えるプラットフォームSAP NetWeaver ビジネスシナリオの視点を提供 |
