受発注システムのデモを見ると、仕事がきれいに流れていきます。
注文が入り、担当者が確認し、在庫が引き当てられ、出荷と請求へ進む。
紙やFAXから解放される未来が見えます。
ところが導入後、現場の横には以前と同じ電話メモとExcelが残っていることがあります。
システムに入らない注文変更や急ぎ対応を処理するためです。
受発注オンライン化が止まるのは、通常の注文を登録するときではありません。予定どおりに進まない注文が来たときです。
この記事について
Growth Securityでは、中小企業のDX・業務改善・セキュリティについて、ツール導入の前段にある「判断・整理・設計」を支援しています。
今回は、受発注をオンライン化するときに見落とされやすい「例外処理」を取り上げます。
はじめに
通常の受発注は、システムへ載せやすい業務です。
商品、数量、価格、納期、送付先が決まっていれば、必要な項目を入力して次へ渡せます。
しかし、実際の取引では次のようなことが起きます。
- 確定後に数量や納期が変わる
- 一部の商品だけキャンセルになる
- 特別価格に上長の承認が必要になる
- 取引先が指定形式を使えない
- 在庫不足のため代替品を提案する
これらを単なる「現場のイレギュラー」として残すと、オンライン化した範囲と従来運用の境界が曖昧になります。
先に結論
受発注オンライン化では、正常な流れより先に、例外がどこへ戻るかを決めておく必要があります。
ツールが処理できない事態をゼロにするのではなく、誰が判断し、どこへ差し戻し、結果を何に残すかを業務として扱います。
正常系は、項目と順番を決めれば自動化しやすい部分です。
例外系には、顧客との関係、金額、納期、在庫、社内権限など、その会社の判断が入ります。
ここは製品の標準機能だけでは決められません。
なぜ、例外だけがシステムの外へ出るのか
1. 導入時の業務フローがきれいすぎる
システム選定では、代表的な注文を一本の流れにして比較することが多いです。
説明しやすい一方、月末だけの処理、特定顧客の指定、担当者が経験で吸収している訂正は表に出にくくなります。
その結果、導入後に初めて「このケースは入力できない」と分かります。
2. 判断と入力が同じ作業だと思われている
数量を修正するだけに見えても、出荷準備後の変更であれば、倉庫、営業、経理への影響を確認する必要があります。
入力欄を追加すれば解決するのではなく、誰が変更を認めるかという判断が先にあります。
この判断者が曖昧なままだと、システム上の承認を増やしても処理は速くなりません。
3. 従来運用が「一時的」に残る
導入直後は、困ったときだけメールや電話で対応することがあります。
しかし、その記録を誰がシステムへ戻すか決まっていなければ、例外処理は永続的な別ルートになります。
数か月後には、システム、メール、Excelのどれが正しいのか分からない状態になります。
例外が多いこと自体が悪いわけではない
例外処理というと、なくすべき無駄な仕事のように聞こえるかもしれません。
しかし、急な納期変更へ対応することや、長い取引のある顧客に合わせることが、その会社の強みになっている場合もあります。
大切なのは、すべてを標準化して例外を禁止することではありません。
価値のある特別対応と、単に昔から続いているだけの処理を分けることです。
この区別をしないままオンライン化すると、現場の強みまで消してしまうか、反対に過去のやり方をすべてシステムへ持ち込んで複雑にしてしまいます。
また、例外のたびに上長承認を増やすだけでは、判断待ちの列ができるだけです。
残す例外、減らす例外、いったん人が判断する例外を分ける。
この線引きができると、システムへ合わせる部分と、自社の業務として設計する部分が見えてきます。
数量変更が一本入っただけで起きること
例えば、取引先から「発注数を100個から80個へ変えたい」と電話が入ったとします。
営業担当者は電話メモへ残し、受注担当者へチャットを送ります。しかし、倉庫ではすでに100個分の出荷準備が始まっているかもしれません。
請求データが作成済みなら、経理側にも修正が必要です。
例外の入口が複数ある状態
電話では80個、チャットでは変更依頼、システムには100個。各担当者は自分の情報を正しいと思って動きます。
必要なのは、例外を受け付ける場所と状態をそろえること
変更を受けた、判断を待っている、関係部署へ反映した、という状態が一つの流れで確認できれば、システム外の連絡が残っても判断は分散しにくくなります。
どの画面を使うかより先に、変更を誰が確定させるか、どの時点から倉庫や経理へ影響するかを決める必要があります。
オンライン化の前に合わせたい三つの問い
- どこからを例外と呼ぶのか
金額、納期、数量、取引先ごとの指定など、通常処理から外れる条件をそろえます。 - 誰の判断が必要なのか
営業、上長、倉庫、経理のうち、変更内容ごとの判断者を考えます。 - 処理後にどこへ記録を戻すのか
メールや電話で受けた内容を、最終的に何へ反映するかを決めます。
ここで大切なのは、考えられる例外を無制限に洗い出すことではありません。
発生頻度が高いもの、止まったときの影響が大きいものから対象にする方が、現場へ定着しやすくなります。
どこまで最初に対応するかは、会社ごとに違う
すべての取引先、商品、例外を初日からオンライン化する必要はありません。
注文件数が多い取引先から始める会社もあれば、運用が単純な商品だけで試す会社もあります。
一方で、件数は少なくても売上への影響が大きい取引先を外せない場合もあります。
どの例外をシステムへ組み込み、どれを人の判断として残すか。残した処理を誰が管理するか。
この線引きは、現場の件数、担当者数、取引条件、既存システムによって変わります。
一般的な機能一覧だけで決めると、必要以上に複雑な仕組みを作るか、重要な例外を取りこぼすことになります。
まとめ
受発注オンライン化は、通常の注文を速く処理するだけでは完成しません。
訂正、キャンセル、納期変更、特別価格などが起きたとき、誰が判断し、どこへ戻し、何を正しい記録とするか。
受発注DXの成否は、正常系の美しさより、例外時に迷わず戻れるかで決まります。
例外が見えると、ツールに任せる範囲と、人が判断する範囲も決めやすくなります。
もし「これ、うちも同じだな」と思ったら
今回書いたような、
- オンライン化したいが、取引先ごとの違いが多い
- 訂正や特別対応がメール、電話、Excelへ分散している
- ツールを入れた後に現場が戻ってしまわないか不安
こういった相談も受けています。
Growth Securityでは、実際の受発注業務を確認しながら、例外の範囲、判断者、差し戻し先、最初にオンライン化する対象を整理します。
高額なツール導入や全取引先への一斉展開を前提にせず、今の運用から無理なく移せる範囲を決めるところから支援しています。気になったら、まずは状況整理だけでも声をかけてもらえればと思います。
