システム導入の前にBPRが要るのはどんなときか｜見極めの4条件

ベンダーに要件定義を頼んだら、打ち合わせの大半が例外処理の説明で埋まった——そんな経験はないでしょうか。「この場合はこう」「あの部署だけ違う」と話が広がるほど、システムの話をしているはずが、業務の説明会になっていきます。導入前にBPR（ビジネスプロセス・リエンジニアリング、業務プロセスの見直し）が要ると言われても、正直どこまで本気で受け止めればいいのか、判断がつかない方は多いはずです。

物流・製造の現場でシステム導入を何度も見てきた立場から言うと、この違和感は正しいです。BPRが要るかどうかは、システムの出来不出来ではなく、今の業務がどういう形をしているかで決まります。順番を間違えると、高いシステムを入れたのに現場は前と同じだけ紙とExcelに頼る、という結果になりがちです。

BPR、まず1分だけ

BPRとは、今のやり方を疑い、業務の手順を組み直すことです。似た言葉に業務改善がありますが、業務改善は今の手順を保ったまま部分を良くする活動、BPRは手順そのものを作り直す活動という違いがあります。システム導入はその後に来る道具の話で、順番が逆になると、今のやり方をそのまま高価な仕組みに置き換えるだけで終わります。ここでは深追いせず、見極め方に進みます。

システム導入の前にBPRが要るか：見極めの4条件

全部の導入にBPRが必要なわけではありません。業務が単純で一様なら、今のやり方をそのままシステムに乗せてよい場合もあります。逆に、業務が複雑で人によって判断が違う状態のまま乗せると、システムは複雑さを固定するだけの箱になります。基幹システム刷新は“新しくすれば解決”じゃないと以前書いたのは、この順番を飛ばした失敗を何度も見てきたからです。

たとえば、受注ルートが一本で納品先も数社に限られる会社なら、今のやり方をそのままシステムに乗せても大きな支障は出ません。逆に、受注経路が何本もあり、取引先ごとに条件が違う会社では、乗せる前に整理が要ります。見極めどころは次の4つです。

この境目がいちばんはっきり表に出るのは、要件定義の場です。要件定義とはで書いたとおり、要件定義は本来、これから作るシステムに何をさせるかを決める場です。ところが例外処理の説明が止まらない現場では、要件定義の時間が業務の棚卸しに化けていきます。ベンダーが悪いわけでも、担当者の説明が下手なわけでもありません。業務そのものが、システムに乗せる前の形をしていないだけです。

部門をまたぐ回数と帳票の重複も、根っこは同じです。受注情報を営業がExcelに書き、製造が紙に転記し直し、出荷伝票をもう一度物流が作る——転記のたびに数字がずれる余地が増え、システムを入れても「入力を1回で済ませる」という一番効くはずの効果が出ません。転記が多い業務は、まず転記を減らす設計が先です。

人依存の判断も、現場でよくぶつかる壁です。受発注の優先順位を決めているのが、システムのルールではなく特定のベテランの経験だけ、という会社は珍しくありません。その人が休むと出荷順が決められません。この状態のままシステムを入れても、ルールが無いところに新しいルールを作る作業をシステムが代わりにやってくれるわけではありません。先に、その人の頭の中にある判断基準を言葉にする作業が要ります。

4条件は、それぞれ単独で見るより、重なりで見たほうが判断しやすくなります。例外処理が多いだけなら運用でしのげることもありますが、そこに部門をまたぐ回数の多さと人依存の判断が重なると、システムを入れ替えても不具合や問い合わせの多くは残ります。逆に言えば、4条件がどれも軽ければ、今のシステム選定をそのまま進めて問題ありません。

一段深く：なぜこの4条件で見えるのか

私が要件定義の場に立ち会っていていつも気づくのは、例外処理の話がいつまでも終わらない現場ほど、直すべきはシステムではなく業務側だという構図です。例外が多いこと自体は悪いことではありません。ただ、その例外を生んでいる判断基準が誰の頭の中にもない状態のまま、システムだけを新しくしても、例外への対応は結局その人に頼ることになります。

デザイン思考の考え方では、目的に立ち返って手順を疑うことを先にします。今ある業務フローを「動いているから正しい」と見るのではなく、「何のためにこの手順があるのか」から見直します。4条件は、その見立てを現場で使える形に落としたものです。先に業務を直すと決めたら、次に効くのはBPRの進め方で書いた、流れを一枚の紙にして詰まる一点から直す手順です。

ここでBPRを飛ばしてシステムだけ入れ替えると、起きるのはたいてい属人化の温存です。画面や帳票の見た目は新しくなっても、「誰が・どんな基準で判断するか」は旧来のまま個人に残ります。すると新しいシステムの周りに、結局その人しか触れないExcelや紙のメモが増えていきます。システムを変える工事より先に、判断の基準を組織のものにする工事が要る、ということです。

よくある質問

Q. 4条件のうち1つでも当てはまれば、BPRが必要ですか？

A. 目安は「複数の条件が重なっているか」です。例外処理が多くても部門をまたぐ回数が少なく、判断基準が明文化されているなら、そのまま乗せて様子を見られる場合もあります。逆に3つ以上重なっているなら、先に業務を直したほうが導入後の手戻りが少なくなります。1つだけ極端に当てはまる、というケースもあります。たとえば部門をまたぐ回数だけが突出して多い会社では、システムより先に「誰から誰へ何を渡すか」の受け渡しルールを整理するほうが効きます。

Q. ベンダーから「BPRは御社の仕事です」と言われました。何をすればいいですか？

A. まず4条件に沿って今の業務を書き出してみてください。例外処理の一覧、部署をまたぐ回数、同じ情報を書いている帳票、判断が特定の人に集中している場面——この4つを紙に出すだけで、どこから手をつけるべきかが見えてきます。全部を一度に洗い出す必要はありません。いちばん業務が滞っている一箇所、たとえば毎回問い合わせが発生する工程や、締め作業のたびに残業が出る工程から始めれば、成果が見えやすく、次の見直しにもつながります。

まとめ

全部の導入にBPRが要るわけではありません。例外処理の多さ、部門をまたぐ回数、帳票の重複、人依存の判断。この4条件に照らして、今の業務がシステムに乗せてよい形をしているかを、まず確かめてみてください。直すべき業務が見つかったら、慌てて多機能なシステムを探す前に、業務の流れを直すところから始めれば十分です。順番さえ間違えなければ、システムは今より働きやすい道具になります。

この記事を書いた人

小林悠真（こばやし・ゆうま）／LF&L株式会社 代表取締役。九州大学で音響設計・音楽マネジメントを学びデザイン思考を培った後、ヤマトシステム開発・バンテックで物流／生産管理、ラクスル等のITスタートアップで事業開発・SCM構築を経験。製造業・物流業のDXコンサルタントとして、現場の1歩から経営システムまでの全体最適を支援する。テューバ奏者・LFコンサート代表理事も兼務。