BPRの進め方｜業務改善との違いと、廃止・統合・再設計の判断例

申請を電子化したのに、確認する人も入力する項目も減らない。便利なツールを入れたはずなのに、以前の表への転記が残っている。こうした状況では、操作を覚え直すより先に、仕事の流れそのものを見直す必要があります。

BPRを進めるときは、達成したい成果から逆算し、業務の廃止・統合・順序・判断権限を検討してから、必要な仕組みを選びます。すべてを一度に変える必要はありません。全体の到達点を決めた上で、影響を限定した範囲で試すことができます。

この記事では、現場の管理職が関係部署と業務を再設計するときの進め方を扱います。架空の発注申請を使い、「どの工程をなくしてよいか」「何を守るか」「試行をどう判定するか」まで整理します。

BPRと業務改善は、何を問い直すかが違う

BPRはBusiness Process Re-engineeringの略です。デジタル庁は、業務フローや組織構造などをプロセスの観点から再構築する業務改革として説明しています。同庁の自治体窓口DXでは、システムの導入だけでは不十分で、窓口の裏側を含めた業務改革が重要とされています。出典：デジタル庁「自治体窓口DX」

現場で使い分ける際は、「いまの手順を上手に回すか」「その手順や役割分担から変えるか」で考えると整理しやすくなります。業務改善という言葉が広い改革を含む場合もあるため、名称より、何を変更対象にするかを合意しましょう。

小さな改善で困りごとが解消するなら、無理に大きな改革にする必要はありません。反対に、部署ごとの改善を続けても顧客の待ちが減らないときは、受け渡しや判断権限まで対象に含める意味があります。

目的を、利用者の成果と守る条件で決める

「工数を減らす」だけでは、自部署の仕事を利用者や別部署へ移す案も成功に見えます。まず、誰の何を良くするかを一文で置き、そのために崩してはいけない条件を並べます。

たとえば、「通常の備品購入について、申請者が発注受付までの見通しを持てる状態にする。あわせて再入力を減らす。ただし予算・権限・取引内容の必要な確認は維持する」とします。速度だけでなく、確認漏れ、申請者の負担、購買担当の負担も評価対象になります。

対象範囲は、申請作成から発注受付までのように、利用者から見たまとまりで決めます。同時に、予算や社内規程を変えられる人、現場の手順を決める人、情報システムや管理部門の確認が必要な人をそろえます。権限者がいない会議で、新しい承認経路を決定しないことが大切です。

現状は「作業」よりも、その工程の目的を調べる

現在の工程、担当、受け渡す情報、処理時間、待ち、差し戻しを整理したら、それぞれに「何を防ぐ・確かめるための工程か」を書き加えます。

同じ申請を2人が見ていても、一方は予算、もう一方は取引条件を確認している場合があります。画面が同じだから重複とは限りません。反対に、違う帳票でも、同じ内容を照合しているだけの場合があります。「誰が見ているか」だけでなく、確認目的、使う情報、判断結果を比較します。

• その情報や成果物を、誰がどの判断に使っているか。
• 工程をやめると、どんな不具合が起こり得るか。
• 規程・契約・制度上の条件か、社内の慣習か。
• 以前の事故への対策なら、いまも同じリスクがあるか。
• 別の工程で同じ目的を達成できないか。

必要性が不明な工程は、作業者の判断だけで削除せず、責任者に根拠と変更条件を確認します。確認できるまでは維持する、または再設計案の未決事項として残します。

廃止・統合・順序変更・権限変更の順に案を比べる

以下は、架空の通常発注業務について検討する比較例です。各変更は未実施であり、効率化の実績を示すものではありません。

「申請の記録を進捗確認にも使う」には、共有範囲の見直しが必要かもしれません。「確認の統合」には、受け持つ部署の負担増もあります。削減時間だけを書かず、増える仕事、必要な学習、確認の維持方法を同じ案に記入してください。

部署間で利害が異なるときは、全体の目的、各部署の負担、選べる案を持ち寄ります。進め方は他部署との協力を進める調整方法で詳しく扱っています。変更案への反対が続く場合は、現場の懸念を整理し、業務改革の実施条件を決める方法で、試せる範囲と支援を合意してください。

ツールは、新しい流れを決めてから選ぶ

必要な機能は、製品の一覧からではなく、再設計した工程から取り出します。申請情報を一度だけ登録する、判断の履歴を残す、不在時に代理へ通知する、例外だけ別の確認へ送る、といった要件です。

同じ流れを紙や既存の環境で試せる部分があれば、先に試すと要件を確かめられます。ただし、情報の共有権限や履歴が必要な業務を、使いやすいからという理由だけで個人の表へ移さないでください。既存環境で安全に成立しない場合は、試行環境を準備すること自体が先行条件になります。

ツール導入時に目的・データ・運用体制が抜ける問題は、MAツール導入が失敗する原因と確認項目にも具体例があります。MA以外の業務でも、製品選定より先に運用を決める視点は使えます。

試行前に、継続・修正・中止の条件を決める

試行の期間だけを決めても、何を見て判断するかがなければ惰性で続きます。対象案件、必要な観察件数、比較する現状、記録担当、判定日を先に決めましょう。件数が少なければ、予定日が来ても効果の結論を急がず、分かったことと分からないことを分けます。

「戻す」は画面を旧版にするだけではありません。試行中の案件を誰が引き継ぎ、どの記録を正本として扱い、重複発注をどう防ぐかまで決めます。取り消せない対外処理は、単純な切り戻しでは解消しないため、実行前の確認と発生時の対応を担当部門と定めてください。

効果を見る際は、案件数や難易度、繁忙期の違いも残します。試行開始時の教育負担と、定着後に残る負担も分けましょう。指標の作り方は、チームKPIの設定方法が参考になります。

定着させるときは、古い仕事の終了も決める

新しい手順を追加しても、旧帳票や旧報告が残れば、現場の仕事は増えます。新方式への移行条件を満たしたら、終了する手順、正本の保存場所、更新責任者、例外の相談先、旧案件の扱いを明文化します。具体的な書き方は業務マニュアルの作り方で確認できます。

BPRの到達点は、新しい仕組みの導入ではなく、必要な品質を守りながら、利用者と担当者の仕事が流れる状態です。最初の打ち合わせでは、ツールの候補ではなく「困っている利用者」「仕事の始点と終点」「変えてはいけない条件」を一枚にまとめてみてください。そこがそろうと、どの工程を残し、どこから再設計するかを話せるようになります。