変更要約: 初版
4.4業務プロセス改革（BPR/BPM）
業務プロセスを抜本的に再設計するBPRと、業務プロセスを継続的に可視化・改善し続けるBPMの違いを核に、DFD・BPMN による業務モデリング、ワークフローとRPAによる自動化、可視化と継続的改善のサイクルを学びます。ボトルネックに対し「抜本的な再設計（BPR）が要るのか、既存プロセスを前提とした部分的な改善・自動化（BPM/RPA）で足りるのか」を見極める判断が要点です。
業務プロセスの改善には大きく2つのアプローチがあります。既存のやり方を根本から見直し、業務の流れそのものをゼロベースで再設計するBPR（ビジネスプロセスリエンジニアリング）と、既存プロセスを可視化しながら継続的に測定・改善し続けるBPM（ビジネスプロセスマネジメント）です。ここで陥りやすいのは、抜本的な作り直しが必要な構造的問題に対して小手先の自動化を重ねてしまう、あるいは逆に、部分的な改善で足りる問題に大がかりな全面再設計を持ち込んで過剰なコストとリスクを負う、という判断のミスマッチです。この節では、BPR と BPM の違い、DFD/BPMN による業務モデリング、ワークフローと RPA による自動化を押さえたうえで、ボトルネックの性質に応じて抜本改革と漸進的改善のどちらを選ぶかというストラテジストの判断を学びます。
4.4.1BPRとBPMの違い
- BPR＝業務プロセス・組織・情報システムを抜本的（ラディカル）に再設計し、コスト・品質・スピードなどを劇的に改善する取組み。既存のやり方を前提とせずゼロベースで問い直すため効果は大きいが、変更範囲が広く投資・リスク・現場への影響も大きい。
- BPM＝業務プロセスを継続的に可視化→測定→分析→改善（PDCA）し続けるマネジメント手法。既存プロセスを土台に漸進的に磨き上げる。BPR が一度きりの大改革だとすれば、BPM は継続的な改善サイクルであり、両者は排他ではなく組み合わせて使う。
4.4.2業務モデリングと自動化（DFD/BPMN・ワークフロー・RPA）
- DFD（データフロー図）はデータの流れの観点で、BPMN（ビジネスプロセスモデリング表記法）は業務の流れ・分岐・担当（レーン）を標準記法で、業務プロセスを可視化する。可視化はBPR・BPMいずれの前提でもあり、現状（As-Is）を正しく見える化しないと改善点も改革の要否も判断できない。
- ワークフロー＝申請・承認などの業務の流れをシステム化して回す仕組み。RPA（ロボティックプロセスオートメーション）＝定型的な PC 操作（データ入力・転記・照合等）をソフトウェアロボットで自動化する。いずれも既存プロセスを前提とした部分的な効率化・自動化の手段であり、プロセスの構造そのものを作り替える BPR とは目的の水準が異なる。
「BPR＝抜本的な再設計（ゼロベース・効果大・リスク大）」「BPM＝継続的な可視化と改善（PDCA・漸進的）」「RPA/ワークフロー＝既存プロセス前提の部分的自動化」の区別が最頻出です。「RPA を導入すれば BPR になる」という取り違え（RPA は既存プロセスの自動化であって抜本再設計ではない）に注意。可視化（DFD/BPMN）は改善・改革いずれの前提でもあります。
ある保険会社のITストラテジストが、保険金支払業務のリードタイムが競合に比べ著しく長いという課題に取り組んでいます。BPMN で現状（As-Is）を可視化したところ、次のことが分かりました。書類が受付→査定→医務照会→再査定→支払承認と5つの部門を順に紙で回覧され、部門間の受け渡し待ちだけで全リードタイムの7割を占めている。各部門の作業自体は速いのに、部門をまたぐ直列の受け渡しと重複チェックが滞留の主因です。ここでストラテジストが問うべきは、「この滞留は、各部門内の作業を自動化すれば解けるのか、それとも業務の流れ（プロセス構造）そのものを作り替えなければ解けないのか」です。もし各部門内の定型作業（システムへの転記や書類の突合）に時間がかかっているのなら、既存プロセスを前提に RPA やワークフロー で部分的に自動化すれば足ります。しかし本ケースの主因は部門間の直列受け渡しと重複査定というプロセス構造そのものにあります。この構造を温存したまま各部門内の作業だけを RPA で速くしても、滞留の7割を占める部門間待ちは残り、リードタイムはほとんど短縮しません——これは「抜本改革が必要な問題に部分自動化を重ねる」典型的な判断ミスです。適切なのは、受付から支払までの業務プロセスをゼロベースで再設計する BPR——たとえば直列の5部門回覧を、査定と医務照会を並行処理に組み替え、重複していた再査定を廃し、単純案件は自動査定で支払まで直結する、といったプロセス構造の作り直しです。そのうえで、再設計後のプロセスを回すためにワークフローで承認フローをシステム化し、残る定型作業を RPA で自動化する、というように BPR と部分自動化を組み合わせます。さらに、再設計して終わりにせず、稼働後は各工程のリードタイムを継続的に測定・分析して改善し続ける BPM の PDCA サイクルに乗せます。逆に、もし課題が「特定の1部門で担当者が手作業の転記に追われている」程度の局所的なものであれば、大がかりな BPR は過剰投資であり、その部門に RPA を入れる漸進的改善で足ります。このように、ボトルネックがプロセス構造に根ざすのか、局所作業に留まるのかを可視化で見極め、抜本改革（BPR）と漸進的改善・自動化（BPM/RPA）を使い分けるのが、業務プロセス改革におけるストラテジストの中核的な判断です。
| 観点 | BPR | BPM／RPA |
|---|---|---|
| 変える範囲 | プロセス構造をゼロベースで再設計 | 既存プロセスを前提に漸進的に改善・自動化 |
| 効果とリスク | 効果は大きいが投資・リスク・影響も大 | 効果は限定的だが低リスク・低コスト |
| 適する場面 | 滞留がプロセス構造に根ざす構造的問題 | 局所作業の非効率・定型作業の自動化 |
ひっかけ： 「部門間の直列受け渡しが滞留の主因（＝プロセス構造の問題）なのに、各部門内の作業を RPA で自動化すれば解決する」は誤りです——構造に根ざす滞留は、部分自動化を重ねても残り、プロセスをゼロベースで作り替える BPR が必要です。逆に「局所的な作業の非効率にまで大がかりな全面 BPR を持ち込む」のも誤り＝過剰投資とリスクを招き、その場合は RPA 等の漸進的改善で足ります。RPA の導入自体は BPR ではない（既存プロセスの自動化）点にも注意。
4.4.3この節のまとめ
- BPR＝プロセス構造をゼロベースで抜本再設計（効果大・リスク大）／BPM＝可視化と継続的改善のPDCA（漸進的）
- DFD／BPMNで現状を可視化して初めて改善点・改革の要否を判断できる。RPA・ワークフローは既存プロセス前提の部分自動化
- ボトルネックがプロセス構造に根ざすならBPR、局所作業ならBPM/RPA——RPAの導入自体はBPRではない
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 保険金支払業務をBPMNで可視化すると、5部門を紙で順に回覧する部門間の受け渡し待ちが全リードタイムの7割を占めていた。各部門内の作業自体は速い。ITストラテジストの対応として最も適切なものはどれか。
Q2. BPR・BPM・RPAの位置づけの説明として最も適切なものはどれか。