業務プロセス改善の進め方｜ツールを入れる前に決める5フェーズと判断基準の作り方

業務プロセス改善を進めようとして、まずツールの比較検討から入る会社は多い。ワークフローシステム、RPA、生成AI。どれも役に立つ道具だが、道具から入ると高い確率で途中で止まる。止まる理由ははっきりしていて、そのプロセスで誰が何を根拠に決めているのかが、まだ誰にも書き出せていないからだ。

この記事では、ツールを選ぶ前にやるべきことに絞って、業務プロセス改善の進め方を5つのフェーズで整理する。中小企業の現場に入って業務とデータのつなぎ目を設計する仕事をしているなかで、うまく回った現場と止まった現場の差がどこにあったかを中心に書いていく。特定の製品を薦める記事ではないので、どのツールを使う場合でも下敷きとして読めるはずだ。

業務プロセス改善とは—「業務改善」との違いと、ツールから入ると止まる理由

まず言葉を切り分けておきたい。業務改善と業務プロセス改善は、日常会話ではほぼ同じ意味で使われるが、対象が違う。

この違いは、実務ではかなり大きい。ある会社で、見積書作成に時間がかかるという相談を受けたことがある。作業そのものを速くする方向で考えれば、テンプレートの整備や入力補助の話になる。ところが流れを書き出してみると、実際に時間を食っていたのは作成作業ではなく、営業が出した見積もりを上長が確認するまでの待ち時間と、条件の認識違いによる作り直しだった。

つまり、作業時間を半分にしても、全体のリードタイムはほとんど変わらない構造になっていた。こういう場合に必要なのは、作業を速くすることではなく、どの条件なら上長確認を省けるかという基準を先に決めることだ。これが線を見るということになる。

業務プロセス改善という言葉を使うときは、この線の話をしているのだと意識しておくと、打ち手を選び間違えにくくなる。逆に、単独で完結する作業であれば、わざわざプロセスの話に広げる必要はない。1人で完結する作業を軽くしたいだけなら、流れの設計まで踏み込まずに済むことも多い。

ツールを入れても業務プロセス改善が進まない、3つの理由

業務プロセス改善の入口としてツール導入から始めるやり方は、失敗するわけではないが、成功率が明確に落ちる。理由は3つある。

理由1：標準の流れだけが載って、例外が人に残る

どんなツールも、設定画面で表現できるのは決まった流れだ。申請が出たら課長が承認し、金額が一定以上なら部長にも回る。ここまでは設定できる。

問題は、実務の相当な割合が例外で回っていることだ。急ぎだから口頭で先に了解を取る、この取引先は過去の経緯があるので先に別の担当に相談する、この案件だけは条件が特殊なので通常の枠から外す。こうした処理は誰かの頭の中にあり、設定画面には現れない。

結果として何が起きるか。標準の案件はシステムを通り、例外の案件はこれまでどおり人が処理する。二重管理になる。しかも、システムに載っていない例外のほうが金額が大きかったり、トラブルにつながりやすかったりする。

理由2：現状の流れを、誰も全体としては知らない

これは何度も見てきた。各担当者は自分の持ち場のことは詳しく説明できる。しかし、案件が着手から完了まで社内をどう通っているかを最初から最後まで説明できる人は、たいていいない。社長でも知らないことが多い。

全体を知らない状態でツールを選ぶと、要件が自分の持ち場の都合で決まる。導入後に、隣の部署がその仕様では回らないと言い出す。ここから調整が始まり、当初の計画から半年遅れる。

理由3：無駄な工程ごとシステムに載せてしまう

既存のやり方をそのままシステム化すると、本来なくせたはずの工程が固定される。しかもシステムに載った工程は、紙のときより変えにくくなる。設定変更に費用がかかったり、他の機能との整合を取る必要が出たりするからだ。

なくせる工程はシステム化の前に消しておく。この順番を守るだけで、導入後の運用がかなり軽くなる。

3つに共通しているのは、ツールが悪いわけではないという点だ。順番の問題でしかない。ここから先は、その順番の話をしていく。

業務プロセス改善の進め方【5フェーズ】

全体像を先に置いておく。5つのフェーズで、うち4つはツール選定より前にある。

ツールの選定は、フェーズ4の後半に来る。フェーズ3が終わっていない状態で製品を比較しても、何を比較すべきかが決まっていないので判断ができない。逆にフェーズ3まで終わっていれば、必要な機能はかなり具体的に言えるようになっている。デモを見たときに、これはうちの分岐を表現できないという判断がその場でつく。

期間の目安は1プロセスあたりのものだ。フェーズ5を除けば1か月強で、そこから運用に入る。全社の全プロセスを一度に扱うと、この期間では収まらない。だからフェーズ1で絞る。

フェーズ1：対象プロセスを1つに絞る

最初にやるのは、どのプロセスを扱うかを1つに決めることだ。ここで全社的に業務プロセス改善を進めますという打ち出し方をすると、ほぼ確実に止まる。関係者が増え、調整の量が指数的に増え、誰も全体を握れなくなるからだ。

選ぶ基準は3つ

この3つを満たすものは、多くの会社で似た顔ぶれになる。受注から請求までの流れ、見積もりの作成と承認、問い合わせの受付から対応完了まで、採用の応募から入社まで。まずはこのあたりから選べばよい。

始点と終点を先に決める

プロセスを選んだら、次に範囲を決める。ここを曖昧にしたまま進めると、書き出しの途中で範囲がどんどん広がる。受注処理を扱うつもりが、気づけば商談前のリード獲得から入金消込まで書いていた、ということが起きる。

決め方はシンプルで、何が起きたら始まり、何が起きたら終わりかを一文で書く。たとえば、顧客から発注書を受け取った時点で始まり、社内システムに受注が登録された時点で終わる、という具合だ。この一文が書けないうちは、まだ対象が定まっていない。

なお、どのプロセスがあるのかを把握できていない場合は、その前に業務全体の洗い出しが要る。手順は業務棚卸しのやり方にまとめている。棚卸しは業務の一覧を作る作業で、この記事で扱うプロセス改善は、その一覧から1本選んで深く掘る作業だ。役割が違うので、順番に通してもらうとちょうどよい。

フェーズ2：現状のプロセスを書き出す（As-Is）

対象が決まったら、今どう流れているかを書き出す。理想の姿ではなく、現実に起きていることを書く。ここで理想を書き始めると、後で必ず食い違う。

1工程につき5つの情報を取る

工程名だけを並べた図では、改善の材料にならない。1つの工程につき、次の5つを取る。

最も抜けやすいのは待ち時間と差し戻しだ。しかも、この2つが改善の効果を最も左右する。作業時間を合計すると1件あたり40分なのに、着手から完了まで実際には5営業日かかっている、という状態はよくある。差の大部分は待ちだ。

待ち時間は本人に聞いても出てこない。自分が待たせている時間は認識されないからだ。渡した側と受け取った側の両方に、いつ渡していつ着手したかを聞くと出てくる。数件分の実例を追いかけるのが一番早い。

図にするか、表にするか

書き出し方は図でも表でもよい。関係者が3部署以上にまたがる場合は、横軸に時間、縦軸に担当者を置いた図にすると、受け渡しの回数が一目で分かる。受け渡しの回数はそれ自体が改善の指標になる。多いほど待ちと認識違いが増えるからだ。

図の描き方に迷う場合は、工程を並べた具体例を見たほうが早い。業務フロー図のテンプレートでは製造業の受注から出荷までを5工程で描いた例を置いている。業種が違っても、粒度の取り方と記号の使い分けはそのまま参考になる。

ひとつ注意しておくと、この段階できれいな図を作り込む必要はない。手書きでも表計算ソフトでも構わない。目的は関係者が同じ絵を見て、ここが詰まっているという合意を作ることであって、清書された資料を残すことではない。作図に時間をかけすぎて本題に入れない現場を何度か見てきた。

書き出したら、その場で3つ数える

図ができたら、関係者が集まっているうちに3つ数えておく。受け渡しの回数、承認が入る回数、同じ情報を人が入力し直している回数だ。3つ目は特に効く。同じ内容が転記されている箇所は、そのぶん間違いが入る余地があり、しかも大半はなくせる。

フェーズ3：判断基準を言語化する—プロセス改善の本体

ここがこの記事で一番書きたいところだ。業務プロセス改善の成否は、このフェーズをやったかどうかでほぼ決まる。そしてツールの導入手順を説明した記事には、ここがほとんど書かれていない。

プロセスの中には必ず分岐がある。承認するか差し戻すか、通常対応か特急対応か、標準価格か個別見積もりか。分岐があるということは、そこで誰かが判断しているということだ。ところが、その判断の根拠は文書化されていないことがほとんどで、担当者自身も判断しているという自覚がない。

判断を引き出す4つの質問

判断基準を書いてくださいと頼んでも出てこない。こちらから質問を当てる。

引き出した判断は、もし〜なら〜する、という形にそろえて書く。金額が一定額を超えたら上長の確認を取る、初回取引の相手なら与信を先に見る、納期が翌営業日ならまず電話を入れる。この形にしておくと、後でツールの条件設定にほぼそのまま移せるし、移さない場合でもチェックリストとして使える。

担当者ごとに答えが割れたら、それが本命

同じ質問を複数の担当者に当てると、答えが違うことがある。これは失敗ではなく、最も価値のある発見だ。同じ工程で人によって判断が違うということは、その工程の結果が担当者によってばらついているということになる。

こういう場合、その場でどちらが正しいかを決めようとしないほうがよい。まず両方の理由を聞く。多くの場合、どちらにも根拠がある。過去のトラブルを踏まえた人と、スピードを優先する人で基準が分かれている、といった構造が見えてくる。そのうえで会社としてどちらを取るかを決める。ここは現場ではなく経営の判断になる。

判断が特定の人に貼りついたまま放置されると、その人の不在で業務が止まる状態になる。症状としての属人化への対処は属人化を解消する方法で3ステップにまとめているので、そちらもあわせて読んでほしい。この記事はプロセスの設計側から同じ問題に触れているので、視点が違う。

書き出せない判断もある

正直に書いておくと、すべての判断が言語化できるわけではない。長年の取引関係の機微、相手の表情や言い回しから読み取る温度感、業界特有の空気。こうしたものは条件式にならない。

大事なのは、書き出せないものを無理に書き出すことではなく、書き出せる部分と書き出せない部分の境界をはっきりさせることだ。この境界が、次のフェーズで引く自動化の線とほぼ一致する。境界を曖昧にしたまま自動化を進めると、機械に任せてはいけない判断まで載せてしまう。

フェーズ4：どこまで自動化するかの線を引く

判断基準が並んだら、次にやるのは線引きだ。全部を自動化しようとしないし、逆に自動化を怖がって何も変えない、という結論にもしない。工程を3つに分ける。

実務でよくある失敗は、Bを飛ばしてAとCだけで考えることだ。判断が入るから自動化できない、と一括で結論を出してしまう。しかし判断そのものは人が持ったまま、判断に必要な材料をそろえる部分だけ渡すことはできる。この切り分けができると、自動化できる範囲が想定よりかなり広がる。

線を引き終えたら、ここで初めてツールの話に入る。必要な機能は、A層の工程一覧と、フェーズ3で書いた条件式から具体的に出てくる。この条件分岐が表現できるか、この受け渡しがつながるか、という観点で製品を見れば、デモの場で判断できる。

自前で進めるか外部に頼むかを迷う段階でもある。判断の材料は業務改善の外注と内製化の判断軸に整理している。ひとつだけ先に書いておくと、フェーズ1から3までを外部に丸ごと任せるやり方はおすすめしない。判断基準は自社の資産で、外に出したままにすると次の改善のたびに外注が必要になる。

フェーズ5：新しい流れを回しながら直す（To-Be）

新しいプロセスを設計したら、いきなり全面切り替えはしない。小さく走らせて、詰まった箇所を直す。

最初の2週間は並行運用にする

旧プロセスを止めずに、新しい流れを一部の案件だけで走らせる。二重になるので現場の負荷は増えるが、期間を区切っておけば耐えられる。並行期間があると、新しい流れで処理できなかった案件が出たときに旧ルートで救えるので、業務が止まらない。

対象は、件数の多い標準的な案件から選ぶ。難しい案件で試したくなるが、逆だ。標準で回ることを先に確認してから、例外を足していく。

詰まった箇所は、その場で記録する

並行運用の期間中に出てくる詰まりは、ほぼすべてフェーズ3の書き漏らしだ。想定していなかった条件、聞き出せなかった判断、誰も知らなかった例外。これを都度、条件式の形で追記していく。

記録する場所は決めておいたほうがよい。担当者の記憶や個別のやり取りに散らばると、切り替え後に同じ問題が再発する。1枚の表でよいので、日付、詰まった内容、どう処理したか、恒久対応をどうするかの4列で並べていく。

効果は3つの数字で測る

効果測定を作業時間の削減だけで見ると、実態より良く見える。最低限そろえたいのは次の3つだ。

この3つは、改善前に取っておかないと後から比較できない。フェーズ2の書き出しのときに、あわせて実測しておく。数件でよいので、実際の案件を追いかけて記録する。

投資対効果の形で経営に説明する必要がある場合は、時間削減を人件費に換算する計算が要る。その手順は業務改善の費用対効果の測り方にまとめている。この記事では改善そのものの進め方に絞るので、金額換算の詳細はそちらに譲る。

業務プロセス改善のフレームワーク—ECRS・BPMN・バリューストリームマップ

業務プロセス改善の文脈では、いくつかのフレームワークが紹介される。全部を使う必要はない。それぞれ得意な場面が違うので、使い分けだけ押さえておけばよい。

ECRS—工程を減らすときに使う

排除、統合、並べ替え、簡素化の4つを、この順番で当てていく考え方だ。中小企業の現場で最も実用になる。順番に意味があって、なくせるかを先に考えるのが要点になる。簡素化から入ると、本来なくせた工程を上手にこなす方向に努力してしまう。

実際にやると、排除だけで工程数が2割前後減ることが珍しくない。長く続いている会社ほど、目的を失った工程が残っている。

BPMN—分岐が多い業務を正確に描くときに使う

業務プロセスを描くための国際的な記法で、分岐、並行処理、例外、タイマーといった要素を厳密に表現できる。システム開発の要件を固める場面では強い。

一方で、記法を覚えないと読めないという弱点がある。現場の担当者に見せて意見をもらう場面には向かない。使うなら、現場との合意形成は簡易な図で行い、開発ベンダーへの受け渡し用にBPMNへ起こす、という二段構えがよい。最初からBPMNで書き始めると、記法の議論に時間を取られる。

バリューストリームマップ—待ち時間を可視化するときに使う

製造業で発展した手法で、工程ごとの作業時間と待ち時間を並べて描き、全体のリードタイムに対して価値を生んでいる時間がどれだけかを見る。事務作業に応用すると、多くの場合、価値を生んでいる時間は全体の1割から2割程度にとどまる。

この手法が効くのは、作業を速くする方向の議論を止められるところだ。全体の8割が待ちだと数字で見えると、作業効率の話ではなく受け渡しの設計の話に議論が移る。フェーズ2の書き出しで待ち時間を取っておくと、この形にすぐ持っていける。

3つのうちどれか1つを選ぶなら、ECRSでよい。特別な記法も道具も要らず、書き出した工程表にそのまま当てられる。BPMNとバリューストリームマップは、必要になった場面で足せばよい。

業務プロセス改善が失敗する5つのパターン

支援に入った現場で繰り返し見てきた失敗を挙げておく。どれも事前に知っていれば避けられる。

5つに共通しているのは、業務プロセス改善を一度きりのプロジェクトとして扱っている点だ。実際には、業務は環境が変われば変わる。取引先が増える、法改正が入る、人が変わる。そのたびにプロセスは少しずつ実態とずれていく。

だから、見直しの引き金を業務側のイベントに紐づけておく。定期的に見直しましょうという約束は守られないが、条件が変わったらその条件式を直す、トラブルが起きたら該当箇所に一行足す、という形なら続く。書き出した図と条件式は、改善が終わったら捨てる資料ではなく、運用しながら育てる資料として置いておきたい。

まとめ—業務プロセス改善は、ツールを選ぶ前に8割が決まる

業務プロセス改善の進め方をまとめると、5つのフェーズになる。対象を1つに絞り、現状の流れを待ち時間と差し戻しごと書き出し、分岐点の判断基準を条件と行動の形にし、自動化する範囲と人が持ち続ける範囲に線を引き、小さく回しながら直す。ツールの選定が出てくるのは4つ目の後半で、それより前が全体の大半を占める。

なかでも効くのはフェーズ3だ。分岐点で誰が何を根拠に決めているかが書き出せていれば、どのツールを選んでも設定に落とせるし、仮にツールを入れないという結論になっても、チェックリストとして機能する。逆にここが空白のままだと、どんなに高機能な製品を入れても、標準の流れだけがシステムに載って例外は人に残る。

最後にひとつ。業務プロセス改善は、効率を上げるためだけの作業ではないと思っている。判断の根拠を言葉にしていく過程で、会社として何を大事にしているかが見えてくる。どの取引先を優先するか、どこまでのリスクを取るか、何を確認せずに進めてよいとするか。これらは本来、経営が決めることだ。それが現場の判断として日々行われていたことに気づくのが、この作業の一番の収穫だったと言う経営者は少なくない。1つのプロセスからで構わないので、まずは1本、最後まで通してみてほしい。