ビジネスプロセス・リエンジニアリング（BPR）：手順と実例

ビジネスプロセス・リエンジニアリングとは、壊れたシステムを少しずつ手直しするだけではもう十分ではなくなったときに行う取り組みです。問題を一つずつ修正していく代わりに、BPR（ビジネスプロセス・リエンジニアリング）はより難しい問いを投げかけます。もし今日ゼロからこのプロセスを作るとしたら、どう設計するだろうか、という問いです。

この問い自体はシンプルに聞こえます。しかし、その答えに基づいて行動するには本物の勇気が必要です。なぜなら、その答えはほとんどの場合、既存のものの多くを捨て去ることを意味するからです。

ビジネスプロセス・リエンジニアリングとは

ビジネスプロセス・リエンジニアリングとは、コスト・品質・スピード・サービスといった重要な業績指標において劇的な改善を実現するために、企業のコアプロセスを根本から徹底的に再設計することです。この定義は、1993年の著書『リエンジニアリング革命（Reengineering the Corporation）』でこの概念を提唱したマイケル・ハマーとジェイムズ・チャンピーによるものです。

この定義に含まれる4つの言葉には、それぞれ重要な意味が込められています。

• **根本的（Fundamental）**とは、物事をどうやっているかではなく、そもそもなぜやっているのかを問うことを意味します。
• **抜本的（Radical）**とは、表面的な修正ではなく、プロセスの根っこにまで踏み込むことを意味します。
• **劇的（Dramatic）**とは、10%程度の改善ではなく、桁違いの成果を目指すことを意味します。
• **プロセス（Processes）**とは、個々のタスクや部門ではなく、業務のエンドツーエンドの流れに焦点を当てることを意味します。

BPRは既存のものを改善することではありません。それを置き換えることです。

重要な事実

• BPRに関する2019年の文献レビュー（Al-MashariおよびZairi、『Business Process Management Journal』）によると、大規模なBPRの取り組みのおよそ50〜70%が、変更管理の不備や経営陣のスポンサーシップ不足を主な理由として、掲げた目標の達成に失敗しています。
• 1990年代初頭に行われたフォード・モーター社の買掛金業務における画期的なBPRでは、請求書そのものを廃止し、入荷情報に基づく支払い方式へ切り替えることで、その部門の人員を500人から約125人へと75%削減しました。
• ハマーとチャンピーは、当時BPRに取り組んだ企業のうち、目指した劇的な改善を実際に達成できたのは10〜50%程度にすぎないと推定しており、再設計そのものよりも実行の方がはるかに難しいことを裏づけています。

BPR対継続的改善（カイゼン）対BPM

業務のやり方を変えるための3つの異なるアプローチが、しばしば一緒くたに語られます。これらは同じものではなく、混同すると誤ったツールを選んでしまいます。

プロセスが大手術を必要としているならBPRが正解です。理学療法程度で済むならカイゼンを使いましょう。それらすべてを統括する経営システムが必要なら、それはビジネスプロセス・マネジメントです。

リエンジニアリングの原則

ハマーとチャンピーは『リエンジニアリング革命』の中でいくつかの指針となる原則を示しています。実務においてそれぞれが意味することを分かりやすく説明します。

タスクではなく成果を軸に組織する。 プロセスは、個々の役割を忙しくさせるためではなく、成果を生み出すために設計します。一つのチームが成果全体をオーナーシップを持って担い、5つの部門をまたいで作業を引き渡すようなことをしません。

アウトプットを使う人にプロセスを実行させる。 調達チームが財務データを必要とするなら、財務部門にレポートを依頼するのではなく、直接アクセスできるようにします。仲介者を排除します。

地理的に分散したリソースを一元化されたものとして扱う。 情報技術を使えば、中央集権的な運営の規模の利点と、現地チームの柔軟性を組み合わせられます。すべての拠点に個別の部門を置く必要はありません。

並行する活動の結果を統合するのではなく、活動そのものを連携させる。 2つの独立した作業の流れを走らせて最後に結果をすり合わせるのではなく、全体を通して調整します。これによりサイクルタイムが短縮され、手戻りが減ります。

意思決定の場を、実際に業務が行われる場所に置く。 現場の担当者に、その場で判断できる権限と情報を与えます。すべての例外を上に上げる必要はありません。

情報は一度だけ、発生源で取得する。 顧客が自分の詳細情報を入力したなら、別の部門に同じデータを再入力させる必要はありません。共有データベースと直接アクセスによって、再入力によるミスをなくせます。

BPRのメリット

BPRがうまくいったときの成果は、疑いようがありません。

劇的なコスト削減。 重複したステップ、引き継ぎ、手戻りをなくすことで、どんな効率化プログラムよりも速く運用コストを削減できます。フォードの買掛金業務の再設計は教科書的な事例ですが、物流、カスタマーサービス、注文処理でも同様の成果が見られます。

より速いサイクルタイム。 部門構造ではなく成果を軸に構築されたプロセスは、はるかに速く完了する傾向があります。待ち時間の減少、承認の簡素化、すり合わせ工程の削減がすべて積み重なります。

より良い顧客体験。 エンドツーエンドの成果に対して単一の責任者がいる場合、顧客はたらい回しにされることなく、一つの窓口で対応してもらえます。応答時間は短くなり、エラーも減ります。

競争上のポジショニング。 業界によっては、すでにITを軸にプロセスを再設計しているプレイヤーが存在します。それを行っていない企業は、不利な条件で競争していることになります。BPRは、何年もかけた地道な取り組みではなく、一度の動きでその差を縮められます。

組織の明確化。 再設計のプロセスは、チームに業務の流れの本当のロジックと向き合わせます。多くの場合、長年続いてきたルールや引き継ぎには、まったく合理的な根拠がないことが判明します。それらを取り除くことで、報告系統が単純化され、政治的な駆け引きが減り、責任の所在が明確になります。

リスクとBPRが失敗する理由

BPRには、誰もが軽視すべきではない失敗率があります。ハマー自身もそれを認めていました。実際に失敗を引き起こす要因は次の通りです。

経営トップの関与が続かない。 BPRには、再設計によって自分の仕事や権力基盤が脅かされる中間管理職からの政治的な抵抗を吸収する、経営幹部のチャンピオンが必要です。経営陣がプロジェクトを部下に任せて自分は関わらなくなると、抵抗勢力が勝ってしまいます。

スコープが膨らむ、あるいは縮む。 小さく始めすぎると取り組みは一つの部門内にとどまり、わずかな成果しか生みません。十分なリソースや明確なパイロット対象なしに大きく始めすぎると、何も生まれません。適切なスコープを見極めることは、本当に難しい作業です。

ITが目的として扱われ、実現手段として扱われない。 新しいソフトウェアを導入することはBPRではありません。多くの組織は、ERP導入を「リエンジニアリング」と呼びます。それが高額で混乱を伴うからです。しかし、古いプロセスをそのまま自動化しただけなら、得られるのは壊れたシステムの速いバージョンにすぎません。

人が忘れられる。 すべてのプロセスは人によって運用されています。教育、役割の変化、雇用への影響という感情的な現実を計画に入れずに業務の流れだけを再設計すれば、積極的な抵抗を招きます。

事前の測定がない。 サイクルタイム、エラー率、取引あたりのコストといったベースラインの指標を把握していなければ、再設計がうまくいったかどうかを判断できません。多くのBPRプロジェクトは、事前に何も測定していないために「成功」と報告してしまいます。

パイロット段階を省略する。 再設計したプロセスを、統制されたパイロットなしに組織全体へ一気に展開するのは、連鎖的な失敗を招くレシピです。パイロットは、ホワイトボード上では問題なく見えた前提を明らかにします。

プロセスを再設計する方法

ステップ1：再設計するプロセスを特定する

すべてのプロセスがBPRの取り組みに値するわけではありません。まずは、戦略的に重要でありながら明らかに機能不全に陥っているプロセスを選びましょう。良い候補は、コストが高い、サイクルタイムが長い、顧客からの苦情が頻発している、あるいは競争上の不利に直結しているといった特徴を持ちます。一度に多くのプロセスに手をつけないようにしましょう。

ステップ2：リエンジニアリングチームを結成する

BPRチームには部門横断的な構成が必要です。実際にそのプロセスを運用している人たち（どこで問題が起きるかを知っている）、IT担当者（システムに何ができるかを知っている）、そして実際に意思決定できるだけの権限を持つ少なくとも一人の経営幹部です。これは委員会ではありません。行動する権限を持った実働チームです。

ステップ3：現状を可視化する

何かを再設計する前に、現在の流れを正直に、詳細に理解する必要があります。ビジネスプロセス・マッピングやバリューストリーム・マッピングを使って、すべてのステップ、引き継ぎ、意思決定ポイント、遅延を文書化しましょう。プロセスが自明に見えるからといって、この工程を省略してはいけません。現状マップは、現時点で理由のないステップも含めて、ほぼ必ず意外な発見をもたらします。

現状（as-is）と将来像（to-be）を構造的に文書化するには、現状と将来像のマップが、再設計に関する議論のための共有ビジュアルの基盤になります。

ステップ4：大胆な将来像を設定する

これが白紙の状態を想定するステップです。現在の制約を無視し、理想的な成果がどのようなものかを問いましょう。サイクルタイムを60%短縮する、エラー率を1%未満に抑える、この機能の人員を40%削減するといった、測定可能な形で成功を定義します。「効率を改善する」といった曖昧な目標では、再設計に必要な難しい決断を後押しできません。

再設計後の役割にまたがる責任範囲をマッピングするには、この段階でスイムレーン・ダイアグラム（スイムレーン・ダイアグラムを参照）が役立ちます。

ステップ5：再設計とパイロット

新しいプロセス設計を構築し、本格展開の前に統制された環境でテストします。パイロットの範囲は、本物の課題を浮かび上がらせるのに十分な現実味を持たせつつ、失敗をすぐに修正できる程度に限定しておきます。何が破綻したかを文書化し、設計を調整しましょう。

プロセスの標準化の作業もここで行います。再設計されたプロセスは、教育や運用の徹底ができるよう、標準作業手順書として文書化される必要があります。

ステップ6：導入と測定

規模が大きい場合は、再設計されたプロセスを段階的に展開しましょう。初日からステップ4で定めた目標に照らして測定します。結果は透明性を持って報告します。継続的なパフォーマンスに対する明確なオーナーシップを割り当てます。そして人の側面も計画に入れましょう。影響を受けるチームには早めにコミュニケーションを取り、実質的な教育を提供し、稼働開始日の後ではなく前に役割変更への対応計画を用意しておきます。

ビジネスプロセス・リエンジニアリングの実例

この3つの事例はすべて同じパターンを共有しています。再設計は、より一生懸命働くことでも人員を増やすことでもありませんでした。誰が何を、どの順序で、どんな情報を使って行うかを、根本から考え直すことだったのです。

ベストプラクティス

やるべきこと：

• 抵抗に直面してからではなく、開始前に経営幹部のスポンサーを確保する
• 何かに手をつける前に、現状のプロセスを厳密に測定する
• 本格展開の前にパイロットで前提を検証する
• 社内の組織図のロジックではなく、顧客の成果を軸に新しいプロセスを設計する
• 人の移行（役割、教育、コミュニケーション）を、プロセス設計と同じくらい丁寧に計画する
• RPA（ロボティック・プロセス・オートメーション）やワークフロー自動化とBPRを組み合わせ、成果を定着させ手作業での再入力を減らす

やってはいけないこと：

• ERP導入を「BPR」と呼ぶ。壊れたプロセスの上にソフトウェアを載せても、得られるのは高額な壊れたプロセスにすぎない
• 対応するリソースや権限の増強なしにスコープを拡大させる
• 「みんな分かっているから」という理由で現状マッピングを省略する。実際には十分に分かっていない
• 一度にすべてを再設計しようとする。まず一つの重要なプロセスを選び、モデルの有効性を証明する
• BPRを一度きりのプロジェクトとして扱う。再設計されたプロセスも、健全な状態を保つには継続的なガバナンスが必要

よくある質問

ビジネスプロセス・リエンジニアリングを簡単に言うとどういうことですか？ BPRとは、コアとなる業務プロセスがどう機能するかを、ゼロから考え直して再設計することです。現在のプロセスの問題を修正する代わりに、レガシーな制約なしに今日そのプロセスを作るとしたらどう見えるかを問います。目標は段階的な向上ではなく、劇的な改善です。

BPRはプロセス改善とどう違うのですか？ プロセス改善（カイゼンやリーン手法を含む）は、既存のプロセス構造の中で機能し、それを一段ずつ良くしていきます。BPRは既存の構造を捨てて新しいものを作ります。範囲もリスクも根本的に異なります。BPRは現在のプロセスが構造的に壊れている場合に適しており、改善手法は基本的には健全な場合に適しています。

BPRを提唱したのは誰ですか？ マイケル・ハマーとジェイムズ・チャンピーが、1993年の著書『リエンジニアリング革命』でこの概念を広めました。ハマーはそれ以前に、1990年の『ハーバード・ビジネス・レビュー』に「Reengineering Work: Don't Automate, Obliterate」という基礎となる論文を発表していました。

なぜこれほど多くのBPRプロジェクトが失敗するのですか？ 失敗のほとんどは、次の3つの原因のいずれかにたどり着きます。途中で経営陣の関心や政治的な意志が失われること、必要な人的な変更管理を過小評価すること、そしてIT導入を本物のプロセス再設計の代わりとして扱ってしまうことです。

企業はいつBPRとカイゼン・イベントのどちらを使うべきですか？ プロセスが根本的に壊れている、業界標準を大きく下回る結果しか出せていない、あるいは段階的な改善では妥当な期間内に解決できない戦略目標を妨げている場合はBPRを使いましょう。構造的に健全なプロセスにおける特定の問題に対して、集中的かつ迅速な改善が必要な場合はカイゼン・イベントを使いましょう。

---

BPRはあらゆる状況に向いているわけではありません。しかし、プロセスが根本的に壊れていて競争上の賭け金が高い場合、段階的な改善は単なる緩やかな失敗に過ぎません。1990年代に、組織図ではなく成果を軸にプロセスを再設計した企業は、競合他社が追いつくのに10年を要するほどの優位性を築きました。同じロジックは今日も通用します。特にAIと自動化が、再設計されたプロセスが達成できる限界を押し上げている今はなおさらです。

土台作りに取り組もうとしているチームは、まず正直なプロセス文書化と、現在の流れがどこで破綻しているかの明確なマッピングから始めましょう。それこそが、あらゆる成功したBPRの取り組みが築かれる基盤です。