AIエージェント・ストラテジスト › Web参考書 › 第2章

BPR(業務改革)の基礎:汚いプロセスの自動化を避ける、ECRSの順序

第2章 業務の基礎 / 節 2

シラバスのキーワード: BPRマイケル・ハマー改善と再設計汚いプロセスの自動化ECRSEliminateCombineRearrangeSimplify順序

本文を読んだあと、覚えているか確認してください。

承認を5回通す経費精算を、AI で速くした結果

経費精算に承認が5段階ありました。AI を入れて各段階の入力と確認を自動化したところ、1段階あたりの時間は確かに短くなりました。しかし全体の工数はほとんど変わりませんでした。なぜか。本来2段階で済む承認を5段階のまま速くしただけだったからです。

これが 「汚いプロセスの自動化」 です。非効率な手順をそのまま自動化すると、非効率を高速に回す装置ができあがります。どれだけ高性能な AIエージェントでも、動かすプロセスが非効率なら、非効率を速く正確に繰り返すだけです。試験で「自動化したのに全体工数が変わらない」問題の根本原因を問われたら、ここです。

BPR:改善ではなく、問い直す

BPR(Business Process Reengineering、業務改革) は、いまあるプロセスを少しずつ良くするのではなく、「この業務はなぜ存在するのか」から問い直して根本から作り直す手法です。1990年代にマイケル・ハマーとジェームズ・チャンピーが提唱しました。

ECRS:この順番に意味がある

BPR の実践的な道具が ECRS です。4つの問いをこの順序で検討します。順序そのものが本質で、効果の大きい改善から着手し、本来不要な業務を丁寧に効率化する無駄を防ぎます。

順 問い 考え方 例
E: Eliminate(排除) そもそも必要か 最初に、最も厳しく問う。排除できれば自動化も不要で、効果は最大、コストはゼロ。存在理由を担当者が答えられない工程は廃止の有力候補 少額の交通費について領収書の原本提出を廃止し、申告だけにする
C: Combine(結合) 複数の工程を1つにまとめられないか 分かれている理由が部署の縦割りやシステムの制約なら、統合の余地がある 紙への記入と提出を、フォーム送信と自動通知に統合する
R: Rearrange(順序変更) この順序に根拠があるか 慣習や思い込みなら、順序を変えるだけで手戻りや待ち時間が減る 全項目を入力してから承認を得る流れを、先に概要で方向性の承認を得てから詳細を入力する流れに変える
S: Simplify(簡素化) これ以上削れないか 工程は残したまま、摩擦を下げる 自由記述 10 項目を、必須3項目とテンプレートの選択に変える

Eliminate から始めるのは、「要らない工程」を Simplify で丁寧に磨いても意味がないからです。排除・結合・順序変更を経て残った工程にだけ、Simplify を適用します。試験では、業務フローを示して「ECRS の観点で最初に検討すべき改善はどれか」と問われ、答えは Eliminate にあたる選択肢になります。3つの改善案を E・C・R・S に振り分ける組み合わせ問題も定番です。

順序:As-Is → BPR(ECRS) → To-Be

前の節の As-Is 分析と To-Be 設計の間に、ECRS が入ります。現状を記録し、ECRS で工程を取捨選択し、残った工程であるべき姿を設計する。この順番です。

BPR の限界と、いまの使い方

1990年代の BPR ブームでは、「根本から作り直す」原則が大規模な人員削減と結びつき、現場の抵抗と混乱を招きました。BPR への批判の多くはこの文脈から来ています。

いまの BPR は、白紙からの作り直しではなく、**「プロセスの存在意義を問い続ける姿勢」**として運用します。全社一括ではなく対象業務に絞り、小さく検証しながら広げます。

現実には、ECRS をやりたくても「その工程は社内規則で決まっているので外せない」とスキップせざるを得ない場合があります。その場合は、始める前に関係者と2点を合意しておきます。本来は排除すべき工程を含めた理想像を共有すること、そして理想を適用できない分だけ成果が出るまでに時間がかかり、難しさが上がるというトレードオフを明言することです。責任の分かれ目を明確にし、うまくいかなかったときに個人の責任に単純化せず、次の改善につなげるためです。

試験で問われる観点

この節の練習問題(4問)

答えを見る前に選んでから開いてください。同じ問題は章別演習でランダム出題されます。

  1. 問1
    経費精算の業務にAIエージェントを導入したところ、処理は速くなったが、不要と思われる承認ステップまで自動化されており、全体の工数はほとんど変わらなかった。この問題の根本原因として最も適切なものはどれか。
    1. 1AIエージェントの精度が低く、承認ステップで人間の再確認が必要になっていた
    2. 2非効率なプロセスをそのまま自動化したため、非効率を速く回すだけの仕組みになった
    3. 3選んだワークフローツールの処理速度が遅く、承認ステップの自動化が効果を発揮しなかった
    4. 4承認者への通知方法が適切でなく、承認までの待ち時間が発生していた
    答えと解説

    正解: 2

    既存のプロセスを問い直さずに自動化すると、本来不要な工程まで高速に回す装置ができあがります。これが「汚いプロセスの自動化」の罠です。正しい順序はAs-Is分析 → BPR(ECRS)→ To-Be設計で、まずEliminate(排除)でその工程が必要かを最も厳しく問います。ツールの速度、通知方法、AIの精度は、不要な工程が残っていること自体の原因ではありません。

  2. 問2
    経費精算の3つの改善案を、ECRSの原則(Eliminate・Combine・Rearrange・Simplify)に分類した組み合わせとして正しいものはどれか。(ア) 少額の交通費について領収書原本の提出を廃止し、申告のみにする。(イ) 申請書の記入と提出を、フォーム送信と自動通知に統合する。(ウ) 自由記述だった10項目を、必須3項目とテンプレートの選択に変える。
    1. 1(ア) Eliminate、(イ) Rearrange、(ウ) Combine
    2. 2(ア) Combine、(イ) Simplify、(ウ) Rearrange
    3. 3(ア) Eliminate、(イ) Combine、(ウ) Simplify
    4. 4(ア) Simplify、(イ) Rearrange、(ウ) Eliminate
    答えと解説

    正解: 3

    工程そのものをなくす(ア)はEliminate(排除)、複数の工程を1つにまとめる(イ)はCombine(結合)、工程を残したまま摩擦を下げる(ウ)はSimplify(簡素化)です。Rearrange(順序変更)は、全項目入力後の承認を先に概要で方向性の承認を得る形に変えるような、順序の見直しを指します。ECRSはこの順序で検討することに意味があり、Eliminateから始めます。

  3. 問3
    ある申請業務のフローをECRSの観点で見直すことになった。最初に検討すべきこととして最も適切なものはどれか。
    1. 1入力フォームの項目を減らして、各工程の作業を簡単にできないかを検討する
    2. 2前後の工程を入れ替えて、承認待ちの時間を短縮できないかを検討する
    3. 3複数の担当者に分かれている工程を1人にまとめられないかを検討する
    4. 4各工程がそもそも必要かを問い、存在理由を担当者が答えられない工程の廃止を検討する
    答えと解説

    正解: 4

    ECRSはEliminate(排除)→ Combine(結合)→ Rearrange(順序変更)→ Simplify(簡素化)の順序で検討することに本質的な意味があります。排除できれば自動化も不要で効果が最大、コストはゼロだからです。先に簡素化や順序変更を検討すると、本来不要な工程を丁寧に効率化する無駄が生じます。Simplifyは排除・結合・順序変更を経て残った工程にだけ適用します。

  4. 問4
    BPR(Business Process Reengineering)に関する説明として、最も適切なものはどれか。
    1. 1既存のプロセスを漸進的に改善するのではなく、なぜその業務が存在するのかを起点に根本から再設計する手法で、1990年代に提唱された
    2. 2既存のプロセスの各工程を現場の提案で少しずつ効率化していく手法で、日本の製造業の改善活動を体系化したものとして1980年代に普及した
    3. 3業務プロセスは変えずに基幹システムだけを刷新する手法で、システムの入れ替えによって処理速度を上げることで生産性を高めることを狙う
    4. 4組織の人員配置と役割分担を見直す手法で、業務の内容や手順は変えずに担当者の数と権限を再配分して人件費を抑えることを目的とする
    答えと解説

    正解: 1

    BPRは1990年代にマイケル・ハマーとジェームズ・チャンピーが提唱した、既存プロセスを根本から問い直して再設計する手法です。今あるものをより良くする「改善」と異なり、今あるものが本当に必要かを問うことから始めます。初期のブームでは大規模な人員削減と結びついて批判を招いたため、現代では白紙からの作り直しではなく、対象業務に絞ってプロセスの存在意義を問い続ける姿勢として運用します。