まずは卸売ECを小規模でスタートしたい方へ。リーズナブルなSaaS(ASP)版『EC-Rider Primo(プリモ)』誕生! 詳しくはこちら

受注管理を一人で担当している人の欠品対策:運用の見直しでできる範囲と、システム導入を考える条件

◆監修・編集責任者 小園 将隆 

B2B EC-COLUMN

この記事のポイント

  • 欠品は担当者の注意だけの問題ではなく、受注時に有効在庫が見えないこと、引当記録の漏れや時間差、実在庫のずれが重なって起きる。
  • 業務フロー図と引当の確認手順で確認の抜けは減らせるが、注文ごとに在庫数を更新する手間は手作業のまま残る。
  • 受注の入口の数、在庫の置き場の数、受注後の更新の手間、休んだときの代わりの4項目で、見直しにとどめるか導入に進むかを点検する。
  • 注文時の自動予約も、実在庫のずれやシステム外の注文の登録、取り寄せの扱いまでは解かないため、製品ごとに予約の作られ方と戻り方を確かめる。
  • 導入前は棚卸、商品マスタの整理、旧新コードの対応表を整え、並行稼働で有効在庫と受注できる数を突き合わせる。

Professional businessman writing notes while working on a computer in a modern office.
▽ 写真の出典元

注文を受けてから欠品に気づくのは、在庫が見えないまま受けているから

注文を受けたあと、出荷の段になって在庫が足りないと分かる。
顧客へ納期変更や欠品を連絡する場面が続くと、受注管理を一人で担っている人ほど、自分の注意不足だと受け止めがちです。
実際には、欠品は二つのことが重なって起きます。
一つは、注文を受ける時点で有効在庫(手元の在庫から引当済みの分を引いた数)が見えていないこと。
もう一つは、引当の手入力の抜けや遅れです。
まず受注から出荷までの流れと引当の確認手順を書き出して標準化します。
それでも注文のたびの在庫更新が追いつかない部分が残るなら、受注管理システムによる自動の予約を検討します。
この順で考えると、何を直すべきかが見えてきます。

受注時に見るべきは有効在庫

「在庫はありますか」と聞かれたとき、多くの担当者は棚の数や表計算の在庫欄を見て答えます。
ところが、新しい注文に回せる数は、その数そのものではありません。
解説記事の定義では、在庫引当とは、現在ある在庫数から受注した分を差し引いておくことです。
手元の在庫数から引当分を差し引いた数を有効在庫数と呼びます3。
つまり、棚に並んでいる商品の一部は、すでに受けた注文の出荷待ちかもしれません。

受注時に見るべきなのは、この有効在庫です。
手元の在庫数だけを見て受けると、出荷待ちの分まで「ある」と数えてしまいます。
同じ記事も、正確な在庫数管理ができていないと有効在庫数以上の受注を受けてしまう場合がある、と指摘しています3。
受注後に足りないと分かるのは、注文を受けた瞬間に正しい数が目の前になかったからです。
受けた後の作業が遅かったからとは限りません。

ただし、有効在庫は引当の記録が正しく付いていて初めて正しい数になります。
表計算に「在庫」と「引当済み」の列があっても、引当の欄が空いていれば、有効在庫の欄は手元の在庫と同じ数を示します。
見るべき数を決めることと、その数を正しく保つことは、別の作業です。

欠品に気づく典型的な場面

仮の例で考えます。
担当者が電話で注文を受け、表計算の在庫欄を見て「出荷できます」と答えたとします。
実はその前日、別の取引先から同じ商品の注文を受けていて、その引当をまだ表に入れていませんでした。
翌日、出荷の準備で棚を数えて初めて足りないと分かり、後から受けた側の顧客へ納期変更を連絡することになります。

この例で、担当者は在庫欄を見るという確認自体はしています。
抜けていたのは、見た数に前日の注文が反映されていなかったことです。
欠品の連絡が続くと自分の確認不足を疑いがちです。
しかし確認の手順を守っていても、確認先の数が古ければ同じことが起きます。

逆の困り方もあります。
受注時に倉庫へ行かないと在庫が分からない状態では、受注をいったん保留せざるを得ず、取引を逃すおそれがあると解説されています4。
在庫が見えないまま受ければ欠品が起き、見えないから保留すれば機会を逃します。
どちらも根は同じで、受注の時点で有効在庫が分からないことです。

欠品の原因は、大きく二つに分けて考えると手を付ける場所が見えやすくなります。
受注時に有効在庫を確認できないことと、引当の記録が漏れることです。
これは原因を網羅した分類ではなく、日々の作業に当てはめるための整理です。
ほかに、破損や紛失で実在庫そのものが記録とずれている場合もあります。

受注後に欠品が見つかるまでの原因のつながり(模式図)
有効在庫が見えないこと、引当の記録の抜けや遅れ、実在庫と記録のずれが、有効在庫を超えた受注につながり、出荷時に不足が分かる流れを示す図
▼ 図の内容を文字で読む
  1. 有効在庫が正しく見えない
    • 受注時に有効在庫が見えない
    • 引当の手入力の抜けや遅れ
    • 破損や紛失で実在庫と記録がずれる
  2. 有効在庫を超えた受注
    • 出荷待ちの分まで「ある」と数える
  3. 出荷時に不足が分かる
    • 顧客へ納期変更や欠品を連絡する

引当を一人の手作業で回すと、どこで誤りと遅れが出るか

入力ミスと入力忘れ

一人で受注管理を担っていると、一つの注文について次の作業を順に自分で回すことになります。
受注の内容を受け取る、在庫を確かめて回答する、引当を記録する、出荷する、在庫数を更新する、という流れです。
このうち誤りが入りやすいのは、数を手で書き写す場面です。

在庫引当の解説では、人的エラーの例として、入力する桁数の間違いと、システムへの入力そのものを忘れることが挙げられています3。
桁を間違えて引当数を少なく入れれば、有効在庫は実際より多く見えます。
入力を忘れれば、その注文は引当がなかったことになり、同じ在庫が次の注文にも回ります。
厄介なのは、どちらも間違えた時点では何も起きず、後の出荷で初めて不足として表に出る点です。

遅れも、誤りと同じ結果を招きます。
たとえば、電話の合間に受注票へ書き留め、表計算への引当の入力は夕方にまとめて行う回し方をしているとします。
その日のうちに受けた次の注文は、まだ引当が入っていない数を見て回答されます。
入力そのものが正しくても、記録が受注に追いつくまでの時間差の分だけ、有効在庫は実際より多く表示されます。

記録の外で在庫が動くこともあります。
在庫管理の解説記事は、単純な数量確認のミスを防ぐには倉庫作業の手順や作業環境の見直しが必要だとし、破損や紛失による在庫変動は見落としがちだと指摘しています4。
引当が正しくても、元になる手元の在庫数が棚と合っていなければ、有効在庫も同じだけずれます。

一人担当だと見つかりにくい理由

ここからは原典の記述ではなく、一人担当という条件から考えられることです。
担当者が複数いれば、受けた人と引当を入れた人が別になり、どこかで数の食い違いに気づく機会があります。
一人で回していると、入力した本人が後で同じ表を見ます。
そのため、打ち間違えた数も正しい数として読んでしまいやすくなります。

誤りが見つかるきっかけが、出荷時の不足か顧客からの問い合わせに限られる点も見落とせません。
そこまで来ると、すでに回答した納期を変えるしかなく、欠品の連絡という形で表に出ます。
流れの途中に、食い違いに気づける確認の点が置かれていないのです。

件数が増えた日や、担当者が休んだ日には、この弱さがさらに表れます。
忙しい日ほど入力をまとめる時間差が広がり、休んだ日は引当の記録そのものが止まります。
受けた注文を代わりの人が処理できても、引当の付け方が担当者の頭の中にしかなければ、有効在庫は更新されません。

こうして見ると、欠品の連絡が続くのは、担当者の注意だけで説明できる話ではありません。
誰が、どの時点で、どの数を確かめるかが仕組みとして決まっていない。
だから注意を払っていても抜けが残ります。
判断の出発点は、直す対象が手順なのか、注文ごとの更新を人が担うこと自体なのかを分けることです。

手作業の引当で誤りと遅れが入りやすい工程(模式図)
受注の受け取りから在庫数の更新までの五つの工程と、引当の記録で桁の打ち間違い、入力忘れ、時間差が入りやすいことを示す流れ図1受注の内容を受け取る2在庫を確かめて回答する3引当を記録する4出荷する5在庫数を更新する

▼ 図の内容を文字で読む
  1. 受注の内容を受け取る
    • 電話の合間に受注票へ書き留める
  2. 在庫を確かめて回答する
    • 見ている数が有効在庫か手元の在庫か
  3. 引当を記録する
    • 桁の打ち間違い
    • 入力忘れ
    • 夕方にまとめて入れる時間差
  4. 出荷する
    • ここで初めて不足として表に出る
  5. 在庫数を更新する
    • 破損や紛失による変動は見落としやすい

受注管理システムの引当機能が自動化すること、人の判断に残ること

注文時の予約と出荷時の消込

受注管理システムの在庫引当は、手作業の流れのうち二つの工程を、注文の状態に合わせて自動で行う仕組みです。
引当を記録する工程と、出荷後に在庫を更新する工程です。
どこまで自動になるかは製品によって違います。
ここでは、公開されている仕様が具体的なAdobe Commerceの在庫管理機能を例に、その動き方を見ます。

Adobe Commerceでは、注文のステータスがOpenになった時点で予約が保存され、販売可能数量が減ります2。
この予約は、注文がPending、Processing、On Holdにある間も有効なままです。
注文の処理状況に応じて自動で作成・変更されます2。
販売可能数量は、考え方としては有効在庫に近い数です。
システムを通って入った注文には受けた瞬間に引当が付くので、記録までの時間差や入力忘れが入り込む余地が小さくなります。

出荷のときは、出荷ごとに、選択したソース(在庫の置き場)の手持在庫から出荷数量が差し引かれ、予約が消込まれます2。
まだ出荷していない分の予約は出荷まで残ります2。
そのため、出荷待ちの在庫は他の注文に回らない状態に保たれます。
支払い前に注文がキャンセルされると、予約が取り消されて数量が販売可能数量に戻ります。
返金時に「在庫に戻る」を選ぶと在庫数量が増えます2。

手作業に置き換えると、次の一連の転記を、注文の状態の変化に任せている形です。
受注のたびに引当欄へ数を入れる、出荷したら在庫から差し引いて引当を消す、キャンセルが出たら引当を戻す。
手作業の誤りとして挙げた、桁の打ち間違い、入力忘れ、記録が受注に追いつくまでの時間差は、まさにこの部分に集まっていました。

製品ごとに確認すべきこと

一方で、自動の予約が正しく働くには条件があります。
元になる手元の在庫数が正しく、注文がシステムに入っていることです。
破損や紛失で棚の数が記録とずれていれば、予約はずれた数から差し引かれます。
電話やメールで受けた注文を担当者がシステムへ登録する運用なら、その登録が遅れた分だけ、手作業と同じ時間差が残ります。

取り寄せ(バックオーダー)や入荷予定の扱いも、人の判断に残りやすい部分です。
入荷前の商品を受けてよいか、入荷予定の数を受注できる数に含めるか。
これは取引先との約束や仕入れの確実さによって変わります。
システムが自動で決める範囲と、担当者が判断する範囲の線の引き方は、製品ごとに異なります。

製品を比べるときは、機能の有無だけを見ても足りません。
自分の受注の流れのどこで予約が作られ、どこで消えるかを質問の形で確かめると、手作業のどの転記が減るのかが具体的に分かります。
確かめたいのは、次のような点です。

  • 予約(引当)は、注文がどの状態になった時点で作られるか
  • 出荷で予約が消込まれ、手持在庫から差し引かれるか
  • キャンセルや返品で、数量が受注できる数へどう戻るか
  • 電話やメールで受けて手入力した注文にも、同じように予約が入るか
  • 受注の入口が複数あるとき、すべてが同じ在庫数を見るか
  • 在庫の置き場が複数あるとき、どこから差し引くかをどう決めるか
  • 取り寄せや入荷予定を、受注できる数に含めるか

これらの答えが自分の流れと合わない部分は、システムを入れた後も人が担う作業として残ります。
導入の効果を見込むときは、自動になる工程と残る工程を分けておくと、期待とのずれに早く気づけます。

場面 手作業の引当 注文状況に応じた自動予約(Adobe Commerceの例)
注文を受けたとき 担当者が引当を記録するまで有効在庫に反映されない 注文がOpenになると予約が保存され販売可能数量が減る
出荷までの間 記録が漏れると同じ在庫が他の注文に回る Pending・Processing・On Holdの間も予約が有効なまま
出荷したとき 出荷分を在庫から手で差し引き引当を消す 選択したソースの手持在庫から差し引かれ予約が消込まれる
支払い前のキャンセル 引当を手で戻す 予約が取り消され販売可能数量に戻る
引当で自動になること、前提になること、人に残ること(公開仕様の一例にもとづく模式図)
注文時の予約、出荷時の消込、キャンセル時の戻しが自動になる一方、在庫数の正しさと注文の登録が前提で、取り寄せなどの判断は人に残ることを三つに分けた図
▼ 図の内容を文字で読む
  • 自動になること
    • 注文の状態に応じた予約
    • 出荷時の手持在庫からの差し引きと予約の消込
    • キャンセル時の数量の戻し
  • 自動が働く前提
    • 元になる手元の在庫数が正しい
    • 注文がシステムに入っている
  • 人の判断に残ること
    • 取り寄せや入荷予定を受注できる数に含めるか
    • 電話やメールで受けた注文の登録

システムを入れず、運用の見直しで減らせる範囲

業務フロー図と担当の書き出し

システムを検討する前に、今の受注の流れを紙に書き出してみる価値があります。
中小企業向けの経営相談の回答では、業務の属人化を防ぐ方法がいくつか挙げられています1。
業務フロー図の作成、各工程の担当者の明記、専門用語を避けた標準作業手順書(SOP)の作成、定期的な見直し、教育とデジタルでの文書共有です。
受注や在庫引当に限って検証したものではなく、中小企業一般への助言です。
ただ、一人担当の受注管理にも当てはめやすい方法です。

フロー図に描くのは、先に挙げた工程です。
受注の内容を受け取る、在庫を確かめて回答する、引当を記録する、出荷する、在庫数を更新する。
それぞれの工程に、どの表や画面を見て、どの数を書き換えているかを添えます。
描いてみると、自分でも曖昧だった点に気づくことがあります。
回答の前に見ているのは有効在庫なのか手元の在庫なのか。
引当はその場で入れているのか、夕方にまとめているのか。

担当者の欄は、一人担当ならほとんどが自分の名前になります。
それでも書く意味は、自分が休んだ日にどの工程が止まり、代わりの人がどこまで動けるかが見えることにあります。
たとえば、受注の受け付けは代われても、引当の記録と在庫数の更新は誰も代われない。
そうした空白が見えれば、手順書に書くべき場所もそこだと分かります。

引当の確認手順を手順書に入れる

フロー図で見えた空白を埋める方法として、引当の確認を手順書に書き込むことを提案します。
これは原典に書かれた方法ではなく、手作業の誤りの起き方から考えた運用の案です。
表計算で管理している場合なら、たとえば次の順にします。

  1. 在庫を回答する前に、手元の在庫ではなく有効在庫(手元の在庫から引当済みの分を引いた数)の欄を見る
  2. 注文を受けたら、回答した直後に引当を記録する。
    後でまとめて入れない
  3. 出荷したら、その分を手元の在庫から差し引き、同じ行の引当を消す
  4. キャンセルが出たら、引当を戻した日と数を書き残す
  5. 一日の終わりに、その日の受注の件数と、引当を記録した件数を突き合わせる
  6. 棚で破損や紛失を見つけたら、その場で在庫数を直し、理由を書き残す

この手順で減らせるのは、入力忘れと、記録が受注に追いつくまでの時間差です。
一日の終わりの突き合わせは、一人担当に欠けている「別の目で確かめる点」を、時間をずらして自分で置く工夫です。
引当の記録が正しくなれば、補充の判断にも使えます。
在庫量が分からなければ、それを踏まえた発注ができないと指摘されているとおりです4。

効果を確かめるには、手順を回す前と後で、受注した後に不足が見つかった件数を自分で数えてみます。
どの工程の抜けで起きたかも一緒に書き留めておくと、手順で減った部分と残った部分が分かれます。

ただし、手作業である以上、注文のたびの更新は人が行い続けます。
手順書は抜けに気づく点を増やしますが、件数が増えた日や休んだ日に更新そのものが遅れることまでは防げません。
運用の見直しで減らせるのは確認の抜けまでで、更新の手間は残ります。

30代後半の日本人男性が倉庫の棚での在庫確認をしている場面

一人担当で、運用改善にとどめる場合と受注管理システム導入に進む場合の分かれ目

4つの点検項目

運用の見直しとシステムの導入は、同じ問題を別の深さで解く手段ではありません。
解く弱点が違います。
手順の標準化は、人が行う確認の順序と担当を整え、抜けに気づける点を増やします。
注文時の自動の予約は、注文ごとに在庫数を書き換える作業そのものを人の手から外します。
どちらの効果も量で比べられる基準はないので、受注件数などで線を引くより、自分の条件を点検するほうが判断に役立ちます。

次の4つの項目を、今の自分の受注に当てはめてみてください。

  1. 受注の入口の数:注文が電話だけ、あるいはECだけなど一つの入口から入るなら、有効在庫を見る場所も一つで、手順書で回しやすい状態です。
    複数の入口から入り、それぞれの注文を同じ在庫表へ写しているなら、写す回数の分だけ入力忘れと時間差の機会が増えます。
    入口ごとの注文が同じ在庫数を自動で見る仕組みが要るかどうかが、システム側の論点になります。
  2. 在庫の置き場の数:置き場が一か所なら、棚を見に行けば数を確かめられます。
    複数あると、どこの在庫を引き当てるかを決め、その置き場の数を更新する作業が加わります。
    Adobe Commerceでも出荷時には選択したソースの手持在庫から差し引く仕様で2、置き場が複数あること自体が、引当のたびに決めることを増やします。
  3. 受注後に数を更新する手間:手順書を作って回しても、回答の直後に引当を入れることが続かず、夕方のまとめ入力に戻ってしまうことがあります。
    その場合に残っているのは、確認の抜けではなく更新の手間です。
    この部分は手順を書き足しても減りにくく、注文時の自動の予約が対象とする弱点です。
  4. 自分が休んだときに代わりが動けるか:手順書を渡せば代わりの人が引当まで付けられるなら、休む日の備えは標準化で足ります。
    手順書があっても受注・引当・出荷をまとめて代わるのが難しく、休み明けに自分でまとめて直しているなら、代わりの人が行う作業そのものを減らす必要があります。

入口と置き場が一つで、手順書どおりに回して受注後の不足が減っているなら、運用の見直しにとどめる判断に根拠があります。
入口や置き場が複数で、手順を整えても更新の手間が追いつかないなら、システムの導入を検討する段階です。

どちらにも当てはまらないとき

点検の結果が分かれることもあります。
入口は一つだが休む日に代わりがいない、置き場は一つだが入口が増えてきた、といった場合です。
このときは、まず手順の標準化を始めます。
一定期間、受注後に不足が見つかった件数とその原因の工程を記録してから決める順が無理のない進め方です。
標準化は導入後にも必要になる作業なので、最終的にシステムを選んでも無駄になりにくいからです。

記録を見て、不足の原因が引当の記録漏れや時間差に集まっていれば、注文時の自動の予約が対象とする部分です。
原因が破損や紛失、つまり棚の数と記録のずれに集まっているなら、事情が違います。
システムを入れても予約はずれた数から差し引かれるため、先に棚卸と在庫数の直し方を整えるほうが効きます。
記録の外で起きた在庫の動きは、システムには拾えません。

導入を決める人が自分以外にいる場合も、この記録が説明の材料になります。
「欠品が多い」という印象で伝えるのではなく、どの工程の抜けで何回起きたか、手順を整えた後に何が残ったかを示します。
そうすれば、システムで減らしたい作業がどこなのかを、決める側と同じ前提で話せます。

観点 手順の標準化 注文時の自動予約
主に整えるもの 人が行う確認の順序と担当 注文から出荷までの在庫数の更新
減らせること 確認の抜けと休んだ日に止まる工程 引当の記録忘れと記録までの時間差
人に残ること 注文ごとの更新作業そのもの 実在庫の正しさとシステム外の注文の登録と例外の判断
効果の確かめ方 手順の前後で受注後に不足が見つかった件数を比べる 並行稼働で旧運用と引当の結果を突き合わせる
運用の見直しとシステム導入の分かれ目(本文の点検項目にもとづく模式図)
入口と置き場が一つで不足が減っていれば運用の見直し、複数で更新が追いつかなければ導入の検討、どちらでもなければ記録を取って決めることを三つに分けて並べた図
▼ 図の内容を文字で読む
  • 運用の見直しにとどめる
    • 入口と置き場が一つ
    • 手順書どおりに回して受注後の不足が減っている
  • システムの導入を検討する
    • 入口や置き場が複数
    • 手順を整えても更新の手間が追いつかない
    • 休み明けに自分でまとめて直している
  • どちらにも当てはまらない
    • まず手順の標準化を始める
    • 受注後の不足の件数と原因の工程を記録してから決める

受注管理システムの導入前に整える準備と、切り替えの確かめ方

商品マスタの整理

導入に進むと決めたら、最初に手を付けるのは、システムに入れる前のデータです。
引当は商品ごとに在庫から差し引きます。
同じ商品が別の名前やコードで二つ登録されていれば、在庫も二つに分かれて見えます。
片方に引当が付いても、もう片方の有効在庫は減りません。
これでは自動の予約があっても欠品の余地が残ります。

販売管理システムのデータ移行を扱った解説では、商品マスタの移行に、表記の揺れ、全角・半角の混在、廃番商品の残存を整理するクレンジングが欠かせないとされています5。
商品コード体系を変える場合は、旧コードと新コードの対応表を作り、移行の直前まで更新する運用が必要だとも述べています5。
受注管理システムの引当準備を直接扱った記事ではありません。
それでも、商品を一意に識別できなければ在庫を正しく差し引けないという点で、同じ準備が当てはまります。

もう一つ、初期の在庫数を入れる前に、棚卸で実在庫を合わせておくことを提案します。
これは移行の解説にある手順ではなく、自動の予約の仕組みから考えた案です。
自動の予約は登録された在庫数から差し引くため、初期値が棚とずれていれば、そのずれは導入後もそのまま残ります。
順番としては、次のように進めると、後の工程で前の作業をやり直す場面が減ります。
棚卸で数を合わせる、商品マスタの表記とコードを整える、旧コードとの対応表を作る、整えたマスタに合わせて初期在庫を登録する。

並行稼働で確かめること

切り替えの直後は、旧運用と新しいシステムを並べて動かす並行稼働で確かめる方法があります。
先の移行解説も、並行稼働期間を設けることが多いとしています。
判断基準として挙げているのは、日次の受注処理・出荷処理にかかる業務時間を旧システムと比べることです5。
これは同社の目安で、公的な基準ではありません。

欠品対策として導入する場合は、業務時間に加えて、引当の結果を突き合わせることが大切です。
同じ注文を両方に入れ、一日の終わりに、表計算の有効在庫とシステムの受注できる数が商品ごとに合っているかを見ます。
ずれた商品があれば、まずどちらの記録が棚と合っているかを確かめます。
そのうえで、手入力の注文の登録漏れなのか、キャンセルの戻し方の違いなのか、商品マスタの重複なのかを切り分けます。
製品選びで確かめたキャンセルや手入力の注文の扱いが、実際の運用で想定どおりに動くかを見る機会にもなります。

一人担当の並行稼働では、同じ注文を二度入力することになり、その期間は手間が増えます。
件数が多ければ、扱いの多い商品や入口に絞って並べるなど、範囲を決めて行う方法も考えられます。
並行稼働を終える判断は、受注後に不足が見つかった件数とその原因の工程を、手順を整えた時期の記録と比べて行います。
そうすると、システムで何が減り、何が人の作業として残ったかが見えます。

毎日その流れの中で手を動かしていると、自分の受注のどの工程で引当が漏れ、どこで時間差が生じているかは見えにくいものです。

今の受注から出荷までの流れを一緒に書き出し、欠品が手順の見直しで減らせる部分なのか、注文時の自動の予約が必要な部分なのかを切り分けられます。無料相談で要件を整理する

要点の整理

軸 基準
欠品の原因 受注時に有効在庫が見えないこと、引当記録の漏れや時間差、実在庫のずれ
運用の見直しで足りる目安 入口と置き場が少なく、手順書どおりに回して受注後の不足が減っている
システムを検討する目安 入口や置き場が複数で、手順を整えても注文ごとの更新が追いつかない
製品で確かめること 予約が作られる状態、出荷時の消込、キャンセル時の戻し、手入力の注文と取り寄せの扱い
導入前の準備 棚卸、商品マスタの整理、旧新コードの対応表、並行稼働での引当の突き合わせ
オフィスで段ボール箱の中身とタブレットを見比べる日本人の会社員

導入を考える段階では、予約が作られる時点や手入力の注文・取り寄せの扱いが製品ごとに違い、一人で比べながら準備まで進めるのは負担が大きくなります。 自社の受注の入口、在庫の置き場、例外になりやすい注文を前提に、製品側へ確かめるべき点と、棚卸から並行稼働までの準備の順番を整理できます。

BtoB通販システムのご相談

貴社の商習慣に合わせたご提案をいたします。

無料相談はこちら

よくある質問

有効在庫と実在庫は何が違い、受注画面にはどちらを出すべきですか。

実在庫は手元にある在庫の数、有効在庫はそこから引当済みの分を差し引いた数です3。
新しい注文に回せるのは有効在庫なので、受注の回答に使う欄は有効在庫にします。
実在庫も並べて表示しておくと、その差から出荷待ちの量が分かり、引当の記録が漏れていないかを見る手掛かりになります。

一人担当のまま表計算で引当を続けるなら、最低限どんな確認手順を決めておくべきですか。

本文で挙げた手順のうち、特に効くのは四つです。
回答前に有効在庫の欄を見ること、回答の直後に引当を記録すること、一日の終わりに受注件数と引当の記録件数を突き合わせること、破損や紛失を見つけたらその場で在庫数を直すことです。
これで入力忘れと時間差には気づきやすくなります。
ただし、注文ごとの更新を人が行う手間は残ります。

受注管理システムを入れても欠品が残るのは、どんな場合ですか。

まず、手元の在庫数が棚とずれている場合です。
自動の予約は登録された数から差し引くので、破損や紛失、初期在庫のずれは残ります。
次に、電話やメールで受けた注文のシステムへの登録が遅れる場合で、手作業と同じ時間差が生じます。
取り寄せや入荷予定を受注できる数に含めるかどうかも、製品の仕様と設定によって結果が変わります。

導入前の棚卸や商品マスタの整理は、誰がどの順で進めるのがよいですか。

日々の受注と在庫を扱っている担当者が中心になるのが現実的です。
どの商品が別名で重複しているか、どの在庫がずれやすいかを最もよく知っているからです。
順番は、棚卸で実在庫を合わせる、商品マスタの表記揺れ・全角半角・廃番を整理する5、旧コードと新コードの対応表を作る5、初期在庫を登録する、とすると手戻りが減ります。
導入を決める人が別にいる場合は、通常業務と並行するこの作業の時間をあらかじめ確保してもらう相談が必要です。

自分が休む日に備えて、引当の手順をどう残しておくべきですか。

業務フロー図と、専門用語を避けた手順書を作り、誰でも見られる場所に共有しておく方法があります1。
手順書には、どの表のどの欄を見て、どの数を書き換えるかまで書きます。
書いた手順を一度、代わりの人に実際に回してもらうと、自分には当たり前で書き漏らしていた工程が見つかります。

◆監修・編集責任者

小園 将隆

株式会社フライトソリューションズ ECサービス部 マネージャー

BtoB通販のパッケージシステム「EC-Rider B2B Ⅱ」の導入支援をはじめ、製造業、卸売業をはじめとした法人向け通販サイト構築を多数手掛ける。卸売領域の専門知識をもとに、日本の商習慣に固有の課題をパッケージシステムの機能追加によって解決。BtoB流通の販路拡大を支援する。

> プロフィールの詳細を見る

  1. 1 出典:独立行政法人中小企業基盤整備機構(J-Net21)「J-Net21 経営相談Q&A」(2024年)
  2. 2 出典:Adobe「Adobe Commerce 管理者ガイド 在庫管理 注文ステータスと在庫予約」(2026年確認)
  3. 3 出典:ECのミカタ編集部「在庫引当とは?重要性や方法、在庫管理システムを導入するメリット」(2023年)
  4. 4 出典:ITトレンド「中小企業が在庫管理を効率的に行う方法は?失敗例・導入事例も紹介」(2025年)
  5. 5 出典:株式会社ripla「販売管理システムのデータ移行を成功させる5ステップ」(2026年)

画像の出典元

  1. Professional businessman writing notes while working on a computer in a modern office./Photo by Thirdman on Pexels

Photos provided by Pexels

◆この記事について

独自調査以外の一次情報は、省庁・公的機関を中心とした信頼性の高い情報源から引用し、出典を明記しています。
年次更新される統計については、引用元の最新版を確認したうえで掲載しています。

※この記事は上記の監修・編集責任者がAIの協力を得て制作しています。

監修確認日:

記事内容に関するお問い合わせ:お問い合わせフォーム

BtoB EC(受発注)サイト構築システム「EC-Rider B2B Ⅱ」への
各種お問い合わせ

ページTOPへ戻る
無料相談を予約 お見積
平日10:00~18:00
page
top