BPR

一言でいうと

いまの業務手順を前提にせず、成果を大きく高めることを目的に、業務のプロセスを根本から見直して作り直す取り組みです。

提唱者と登場年

Michael Hammerが、Harvard Business Reviewの1990年7-8月号に発表した論文「Reengineering Work: Don't Automate, Obliterate」で提唱しました。題名のとおり、既存の業務をそのまま自動化するのではなく、価値を生まない作業そのものをなくすべきだと主張しています。

その後HammerとJames Champyは、リエンジニアリングを「コスト、品質、サービス、スピードといった現代の重要な成果指標を劇的に改善するために、ビジネスプロセスを根本的に考え直し、抜本的に設計し直すこと」と定義しました。英語版Wikipediaは、この手法が1990年代半ばにかけて広く採用された一方、多くの企業が人員削減の根拠として使ったために評判を落としたとも記述しています。

何を解決するか

部分的な改善を積み重ねても成果が大きく伸びない状態を打開します。部署ごとに最適化された業務は、部署の境目で確認や転記が重なり、全体として時間と手間がかかります。システムを導入する際に既存の手順をそのまま載せると、この非効率も一緒に固定されます。

BPRは、顧客に届ける成果を起点にプロセス全体を描き直し、部署の境目で生じる無駄を取り除きます。前提として、部署の役割や権限の変更を決められる経営層の関与が必要です。現場の担当者だけでは、部署をまたぐ手順の変更を決められません。

実際の進み方

対象の業務プロセスを選び、現状の手順、所要時間、関わる部署を洗い出します。次に、顧客にとっての成果から逆算して、あるべきプロセスを描きます。現状との差を、組織、役割、システム、規程の変更として整理し、段階的に移行します。

システムの刷新と同時に行われることが多く、パッケージ製品を導入する場合は、製品の標準の手順に業務を合わせる判断がBPRの一部になります。

導入でよくある失敗

• 業務の見直しを行わず、既存の手順をそのまま新しいシステムに載せる
• 現場の担当者を設計に参加させず、実際の例外処理が抜け落ちたプロセスになる
• 人員削減の手段として打ち出し、現場の協力を得られなくなる

求人票にこの語がある場合に読み取れること

情報システム部門や社内SEの求人にBPRとある場合、システムの導入や運用だけでなく、業務の手順そのものを変える提案と調整まで期待されていると読み取れます。経営層に近い立場で部署をまたいだ合意を取る力が必要になります。候補者には、見直した業務の範囲、削減した工数や期間の実績、反対した部署とどう合意したかを確認してください。

隣接手法との違い