発注判定アプリを小さく試す。発注点一覧から候補を出す実務

発注点を下回ったら注文する――このルールは簡単に見えます。しかし、実際の発注点一覧には、ケースと個数の単位違い、曜日ごとの締切、最低ロット、送料、季節変動などが同居します。表をそのままアプリに渡すと、担当者が普段補っている判断が抜け落ちます。

社内で発注判定の試作版を作る際は、すべてを自動発注するのではなく、数値で判定できる一部の商品から始めました。この記事では、発注点一覧の整理、現在庫データによる限定テスト、人が確認するための候補表まで、実施した範囲と未実装の範囲を分けて紹介します。取引先・商品・社内の具体的な条件は特定できない形に置き換えています。

発注点一覧を、そのまま自動判定に使わない

最初にしたのは、商品ごとの発注点と発注数量を、在庫データと対応させることです。発注点は「どこで発注候補にするか」、発注数量は「候補になったら何をどれだけ頼むか」で、同じ数字ではありません。商品コード、品名、単位、曜日や締切などを列に分け、重複や空欄を調べました。

一覧には「数ケース程度」のような幅のあるメモや、時期によって変える条件もあります。こうした文を都合よく一つの数値へ置き換えると、意図しない発注量になります。数値が確定する商品だけを試作版の対象にし、曖昧な条件は「要確認」として人に戻す方針にしました。仕入先や商品の実名を外しても、この切り分けは他社の実務にも応用できます。

実施したのは、現在庫から候補を出す第一段階

PC内で動く試作版に、在庫一覧のCSVやExcelを読み込ませました。商品コード、商品名、現在庫を発注点一覧と対応させ、判定できる商品について「発注候補」または「発注不要」と候補数量を出します。サンプルデータでの判定と起動確認はできましたが、実際の在庫業務と並行して全件の結果を照合する工程は残っています。運用開始や削減時間の実績としては扱いません。

試作中は、商品コードの先頭の0を落とさないこと、ケース・箱・個の換算を揃えること、同名でもコードが違う商品を混ぜないことを確認しました。入力日の異なる在庫を混ぜれば、計算式が正しくても判断は古くなります。まず「入力した現在庫とルールから何を出したか」を追える状態にすることが先です。

未実装の条件を、次の段階として明示する

第一段階は現在庫の比較です。発注判断に必要な予定入荷や未出荷注文、販売予定をまだ反映していないため、候補が出ても「今すぐ発注すべき」とは言えません。次の段階では、現在庫に入荷予定を加え、未出荷の引当分を差し引いた将来の有効在庫を考えます。その後で最小ロット、梱包単位、送料、保管上限、季節性、期限などによる数量調整を扱う計画です。

段階	判定内容	現時点の扱い
1	発注点一覧と現在庫から候補を出す	限定した商品で試作・サンプルテスト済み。実在庫との並行比較はこれから
2	入荷予定と未出荷注文を含む有効在庫	設計段階
3	ロット・送料・期限などを踏まえた数量調整	設計段階
4	理由付き候補を人が確認し、既存システムへ渡す	運用ルールを整える段階。自動注文はしない

発注は自動確定せず、理由付き候補を人へ戻す

最終的な出力は注文書ではなく、担当者が確認する候補表として設計します。「発注点を下回った」「対象外の条件がある」「コードが対応しない」といった理由と、参照した在庫日・単位・数量を残す必要があります。担当者が取引先の条件や直近の受注を確認し、必要なら候補を修正してから既存の発注手続きへ進む流れです。

並行比較では、担当者の判断と候補が違った行を単純な「アプリの誤り」とせず、一覧のルール不足、古い在庫、例外条件、単位換算のどこに原因があるかを記録します。こうした差分をルールへ戻してから対象商品を広げる方が、誤発注の危険を抑えられます。

PC内で処理しても、情報管理は別に決める

試作版はPC内で動かしましたが、それだけで情報管理が完成するわけではありません。在庫一覧や価格条件は社内情報です。読み込む原本、候補の保存先、ログの残し方、閲覧できる人、削除時期を決め、実データを使う前に社内ルールを確認します。公開記事には元データや具体的な取引条件を載せていません。

まとめ

発注判定アプリは、一覧を丸ごと自動化するより、判定できる範囲と人へ戻す例外を先に分けることが重要でした。現在庫から候補を出す限定テストまでは行いましたが、有効在庫や発注量の調整、実在庫との並行比較はこれからです。候補の理由を残し、担当者の判断と照らして育てる道具として考えています。

在庫の増減を数値で捉える別の視点は、在庫回転率を資料化する記事でも紹介しています。分析で状況を把握することと、発注候補を判定することは役割を分けると整理しやすくなります。