需要予測だけでは足りない、自動発注の業務設計

店舗や倉庫の発注業務では、「昨日までの売れ方」「曜日」「天気」「最近の客足」といった情報を見ながら、担当者が発注数を決めていることがあります。経験を積んだ担当者ほど判断材料は多くなりますが、その判断をそのまま他の人へ引き継ぐのは簡単ではありません。

そこで候補になるのが、販売実績などのデータから需要を予測し、発注案を自動で作る仕組みです。ただし、予測モデルを作っただけで発注業務が回り始めるとは限りません。異常な発注を止める仕組み、人が確認する範囲、既存の基幹システムへの連携まで含めて考える必要があります。

担当者の勘と経験による発注は、ばらつきと抜けを生みやすい

担当者の経験による発注そのものが問題というわけではありません。問題になりやすいのは、その判断方法を他の人が再現しにくいことです。

たとえば同じ商品を担当していても、「欠品を避けるため多めに持つ人」と「在庫を増やさないため発注を絞る人」では、発注数が変わります。同じ売上データを見ても判断が違えば、在庫の持ち方も担当者によって変わります。

さらに、担当者が休んだときや引き継ぎが発生したときには、普段どの数字を見て、どの条件なら発注数を増減させていたのかが分からなくなることがあります。日々の発注対象が多ければ、確認漏れや発注忘れも起こり得ます。

販売実績などから需要を予測して発注案を作る仕組みは、こうした判断を一定の手順にそろえる手段になります。ただし、「需要予測ができれば発注業務を任せられる」とは限りません。

自動発注ツールを入れても手間が残る理由

既製の自動発注ツールを導入しても、期待していたほど業務が減らないことがあります。

たとえば、システムが発注案を作ってくれても、最後に担当者が全件を確認して確定ボタンを押す運用が残れば、毎日の確認作業は続きます。通常時は問題なくても、例外が発生するたびに担当者が手作業で修正する運用では、自動化する範囲が広がりません。

既製ツールでそのまま対応できる業務もあります。一方、自社独自の商品分類や発注ルール、既存システムとの連携方法まで含めると、追加の作り込みが必要になる場合があります。

PoCやデモでは需要予測や発注案の生成まで確認できても、本番運用では例外処理、既存システムとの連携、担当者がどの場面で確認するかといった部分まで決める必要があります（「AI導入がPoCで止まる3つの理由」で書いた構図と同じです）。

普段と違う発注量を止めるガードを用意する

自動発注への不安として分かりやすいのが、異常な発注です。

普段の発注量と桁の違う発注案が、何らかの理由で出たとします。需要予測モデルがその数量を出したとしても、そのまま基幹システムへ送る運用には不安が残ります。

そこで、予測結果とは別に発注量を確認するルールを設けます。たとえば品目ごとに発注量の上限を設定したり、前回の発注量との差が大きい場合は自動処理を止めたりする方法があります。

つまり、需要を予測する処理と、その結果を発注してよいか確認する処理を分けます。予測値が出たからそのまま注文するのではなく、通常の範囲から外れた発注案だけを別の扱いにすることで、人が確認すべき対象も絞りやすくなります。

人が確認する範囲を先に決める

発注業務では、すべての発注案を人が確認すると手作業が多く残ります。一方、すべてを機械処理にすると、例外時の不安が残ります。

その間に、「通常の発注案はそのまま処理し、判断に迷う発注案だけ人へ回す」という設計があります。

たとえば、予測の確信度が低いもの、設定した発注量の上限に近いもの、前回から数量が大きく変化したものだけを確認対象にします。それ以外は発注処理へ進めることで、人は例外への判断に時間を使えます。

ここで決めるべきなのは、AIやシステムに任せる割合そのものではありません。「どの条件なら自動処理し、どの条件なら担当者へ戻すのか」という境界です。

この境界が曖昧なままだと、結局すべてを人が確認する運用に戻りやすくなります。

予測結果を基幹システムへつなぐ部分も発注業務の一部

需要予測モデルが発注数を計算できても、それだけでは発注は完了しません。

発注案を既存の基幹システムへ渡し、必要な形式で登録し、異常値があれば止め、人の確認が必要なら確認後に処理を再開するところまでつながって、初めて日々の業務として使えるようになります。

この部分は、自動発注ツールの標準機能だけで対応できる場合もあれば、自社側の基幹システムや業務ルールに合わせた連携が必要になる場合もあります。

守りの設計 — 発注を任せるAIに渡す権限

予測結果から発注まで自動にする場合、AIや自動化の仕組みが基幹システムへ書き込む権限を持つことになります。誤った発注や、意図しないデータの書き換えを防ぐには、次の点を決めておきます。

• 実行できる操作を絞る: 発注案の作成と確定を分け、確定の権限は人に残す
• ガードと承認: 普段と桁の違う数量や金額は、確定前に人の承認を必須にする
• 記録: 誰が・いつ・どの発注案を承認したかを残し、あとから追えるようにする

フォースネットのセキュリティFDEは、自動発注ツールそのものを提供する立場ではありません。既製ツールで対応できる範囲を確認したうえで、基幹システムへの書き込み権限、異常な発注を止めるルール、承認と記録の流れを含めて設計します。

自動発注を検討しているものの、「既製ツールで足りるのか」「自社向けの開発が必要なのか」「どこまで機械処理にしてよいのか」が決まっていない場合は、まず現在の発注業務を分解するところから始める方法があります。初回の見立て（無料・30分・オンライン）で、現在の業務や利用中のシステムをうかがいながら、既製ツールで対応できそうな範囲と、追加の作り込みを検討したほうがよい範囲を整理します。