「モデリングで力尽き、肝心のプロセス改善まで至らなかった」「プロセスを可視化したものの、粒度がばらばらで使い物にならない」——。なぜ、多くのBPMプロジェクトは失敗に終わったのか。どうすれば成功させられるのか。数多くのBPMプロジェクトを見てきた筆者が、6事例からあぶり出した実践テクニックを明かす。
BPMプロジェクトを検討中の方々が一様にこぼすのは、国内事例の少なさである。各ベンダーから提供される海外事例は背景となる文化の違いが気になって、そのまま参考にするには抵抗があるようだ。そこで本稿では、筆者が調査または体験した国内の成功事例、失敗事例からの考察を提示したい 。
考察のベースとしたのは、精密部品メーカーや消費財メーカー、金融サービスなど6社の事例である。このうち3社は、細かい揺り戻しはあれど、当初方針が見直されることなく継続している成功事例だ。残る3社は失敗事例である。ヒアリングの結果、残念ながら取り組みが頓挫、あるいは大幅な見直しを余議なくされていることから失敗と判断した。
これら6事例の成功と失敗の分岐点を詳細に分析した結果、成功事例に共通する13の取り組み姿勢・行動が明らかになった(図4-1)。筆者はこの結果をさらに煎じ詰め、BPM実践の成否を分ける7つの勘所にまとめた。以下で順に解説しよう。
ポイント1:目的図で狙いを明確化
BPMを成功させるうえで最も重要なのは、狙いや目標を明確化してプロジェクト内で共有することである。BPMを成功させた3社はいずれも、その狙いを達成するための業務改革手法としてBPMを選択し、システム導入はその実現手段である、というコンセンサスが、初期段階において主要関係者の間で成立していた。失敗事例では全く逆で、BPMによって何を達成できるかが曖昧なまま取り組みを始めており、システム導入または業務プロセスの可視化自体が目的化してしまっていた。
狙いを明確化するには、「目的図」を初期段階で作成するとよい。図4-2に例を示す。描き方に厳密なルールがあるわけではなく、プロジェクト全体の目的と優先度が一目で分かるようにする。作っただけで満足するのではなく、関係者が共通理解できるか否が肝要である。
ポイント2:部門目標にKPIを設定
目的図を作成したら、どの事業領域の、どういったプロセス領域から取り組むかを検討する。優先すべき事業領域は、自社のバリューチェーンに沿って考えればおのずと決まってくるはずだ。筆者が携わった成功事例では、「経営課題を構造化してそれらの因果関係を分析し、本質的かつボトルネック部分に注力する」というアプローチが有効だった。明らかに広範すぎる領域に対して同時並行的に取り組むと失敗しやすい。
次に、選定したプロセス領域ごとに、何を重視し具体的にどう改善すべきかの基準点を設定する。具体的には、経営戦略を部門目標まで落とし込んだ戦略マップを策定。さらに、それぞれの目標にKPIを設定したKPIツリーを作成する。図4-3は、ある企業の製造部門が作った戦略マップ/KPIツリーの一部である。「自社の競争力を高めるためには、リードタイム短縮と納期遵守が最優先だ」という具合に、改善ターゲットが明確になっていることをご理解いただけるだろうか。
こうした戦略マップ/KPIツリーにより、メンバーは「BPMとは、ビジネス全体に対する個別の業務プロセスの貢献度を継続的に測定し、改善していくための仕掛けなのだ」と納得し、プロジェクトへの「参加しがい」を得られる。
ポイント3:経営トップの関与を引き出す
業務を抜本的に見直すBPMの取り組みは、現場からの抵抗を受けやすい。これを避けてBPMの意義を社内に浸透させるには、経営トップの関与が不可欠である。プロジェクトの初期段階で、経営トップが業務改革とBPMの必然性を強烈な危機感とともに表明する場を設けたい。
併せて、取り組みの進捗や成果をイントラや社内広報誌などで随時開示する。これにより、「一体何が始まったのか」「自分たちにとって危険なプロジェクトではないのか」といった社内各部門の疑心暗鬼を取り除けるし、「次は自分たちも」とその気になってもらえる。
抵抗への対処方法をあらかじめ検討しておくことも重要である。失敗したケースではそうした事前検討が薄く、問題が起こってから事後的に対処する傾向があったため、プロジェクトが迷走したり頓挫したりする結果となった。
ポイント4:全社からメンバーを集める
プロジェクトの人選は、ことのほか重要である。全体リーダーには、社内各部門の協力体制を得るための人脈や政治力を備える役員クラス(またはその有力候補)が望ましい。いくら老獪でも、退任間近の役員では“にらみ”が利かないので避けるべきである。
一方、プロジェクトのスピードや成果を左右するのは、事務局の説得力や心配りだ。そこで、事務局長には「あいつの言うことなら」と人望があり、粘りが身上のような人材を据えたい。
このほか、プロジェクトが全社横断的な位置づけにあることを示すために、メンバーはシステム部門に偏らないよう考慮すべきである。
会員登録(無料)が必要です
- 1
- 2
- 次へ >