在庫管理システムを導入するときに大切なのは、画面に機能が多いかどうかだけを比べることではありません。商品をどの単位で登録し、どの状態を販売可能と見なし、どの拠点からどのチャネルへ配分するのかを、現場の流れに沿って決めることです。SKU、店舗間移動、EC連携を別々の機能として導入するのではなく、同じ在庫履歴でつなげる設計が求められます。
この記事では、アパレル業で在庫が合わなくなる理由を整理し、色・サイズを含むSKUマスタ、店舗間移動、ECの販売可能数、入荷・返品・棚卸し、権限と分析に必要な機能を解説します。既存のExcelやAccessを活用する場合、クラウドサービスを選ぶ場合、業務に合わせて個別に開発する場合の比較ポイントと、導入を小さく始める手順も紹介します。
この記事で分かること
- アパレルで商品単位ではなくSKU単位の在庫管理が必要になる理由
- 色・サイズ・シーズン・商品状態をマスタへ登録する設計の考え方
- 店舗間移動の依頼、承認、出荷、輸送、入荷検品を追跡する機能
- ECと店舗の販売可能在庫をそろえ、受注や返品を重複計上しない方法
- 入荷、販売、取り置き、返品、不良、棚卸し差異を履歴に残す方法
- アパレル向けの在庫管理システムを比較するときの確認項目
- データ整備から代表店舗での試験、全社展開までの進め方
アパレルの在庫管理が難しい理由
商品名ではなく色とサイズごとに売れ方が変わる
アパレルでは、同じデザインの商品でも、色とサイズの組み合わせごとに販売状況が変わります。黒のMサイズが足りない一方で、白のSサイズは残っているというように、商品全体の数量を見ても補充が必要なSKUを特定できません。商品を親商品、カラー、サイズ、SKUのような階層で扱い、販売や移動、棚卸しは最小単位のSKUへ記録することが基本です。
画面の一覧で親商品の合計を表示することは、企画や仕入れの確認に役立ちます。しかし、店舗の補充担当者が必要とするのは、どの色のどのサイズを何点動かすかという情報です。集計表示と実在庫の記録単位を分け、集計結果から個別SKUの履歴へたどれるようにすると、発注や店舗間移動の判断が速くなります。
シーズンと販売期間で在庫の意味が変わる
春夏、秋冬、通年、限定企画など、アパレルの商品には販売期間や企画上の区分があります。同じ数量が残っていても、販売開始前の新商品、シーズン中の定番、終了間近の商品では、必要な施策が違います。商品マスタにシーズン、発売日、販売終了の予定、値下げ区分、仕入れ先などを持たせ、在庫一覧で絞り込めるようにすると、滞留を早めに確認できます。
販売期間を過ぎた商品を通常商品と同じルールで補充すると、店舗の売場や倉庫に古い在庫が残る可能性があります。移動やEC掲載を止めるのか、別の販路へ回すのか、値下げを適用するのかは会社ごとに異なります。システムで自動判断を固定する前に、商品区分と判断者を決め、変更理由を履歴へ残せる状態にしておくことが重要です。
店舗、倉庫、ECで見ている数量が一致しない
店舗の売場にある数量、バックヤードにある数量、物流倉庫の数量、移動中の数量、ECの受注で確保した数量は、同じ「在庫」に見えても利用できるタイミングが違います。出荷が決まった商品や取り置き中の商品まで販売可能数へ含めると、注文を受けた後に商品を用意できない事態が起きます。
最初に、帳簿上の在庫、引当済み、移動中、検品待ち、不良、販売可能という状態を定義します。そのうえで、どの状態を店舗の在庫一覧に表示し、どの状態をECへ配信するかを決めます。現在庫を一つの数字で上書きする運用ではなく、在庫が変わった取引と状態を保存し、必要な表示だけを計算する構成にすると、差異の調査も行いやすくなります。
SKUマスタに必要な項目と運用
親商品と販売SKUを分けて登録する
商品マスタは、企画やデザインを表す親商品と、実際に販売・出荷するSKUを分けて管理します。親商品には商品名、ブランド、カテゴリ、シーズン、素材などを持たせ、SKUにはカラーコード、サイズコード、バーコード、販売単位、原価や価格の適用区分を持たせる考え方です。会社の業務によって項目は変わりますが、販売や棚卸しの対象がどのレベルかを先に確定すると、後の連携設計がぶれにくくなります。
コードは、人が読んで意味を推測できることよりも、重複せず変更に強いことを優先します。商品名や色名が変更されても、過去の販売履歴と同じSKUを追跡できるようにします。新しいカラーやサイズを追加するときは、既存SKUを上書きせず新しいレコードとして登録し、適用開始日や販売区分を残します。廃番のSKUも履歴を確認するために削除せず、販売停止の状態で保持する方法が適しています。
色・サイズの表記ゆれをなくす
カラーを「黒」「ブラック」「BLK」のように自由入力すると、集計やEC連携で同じ色が分かれてしまいます。サイズも「M」「Ｍ」「ミディアム」の表記が混在すれば、サイズ別の在庫や売れ方を比較できません。カラーコード、表示名、外部連携用コードをマスタ化し、入力候補から選ぶようにします。サイズについても、表示順や対象カテゴリを登録し、画面でXSからXXLのように業務で分かりやすい順序を保ちます。
サイズ展開がカテゴリによって違う場合は、全商品へ同じサイズを持たせるのではなく、商品ごとの取扱いサイズを管理します。靴やアクセサリー、フリーサイズなど、衣料品と異なる規格を同じ項目へ無理に当てはめないことも大切です。ECの商品ページで表示する名称と、倉庫や店舗でスキャンするコードは別に持てるようにすると、表示変更が在庫履歴へ影響しません。
在庫状態と販売チャネルをマスタで表す
新品、検品待ち、展示品、修理中、返品確認中、販売不可など、商品の状態が複数ある場合は、状態を数量の調整数へまとめないようにします。販売可能数から除外する理由を状態として保存すれば、返品を受けた後に再販売へ戻したのか、廃棄や修理へ回したのかを確認できます。状態を変更した担当者と日時も履歴に残します。
店舗、EC、自社催事、卸など販売チャネルごとに在庫を確保する運用では、チャネル別の引当を管理します。チャネルごとに固定枠を設ける方法と、共通在庫を販売状況に応じて配分する方法があり、どちらが適切かは商材と販売計画によって変わります。複数チャネルの合計が合っているだけでは、あるチャネルの販売可能数が過大になっていないか分からないため、配分ルールと解除条件を明文化します。
| 管理対象 | 登録する情報の例 | 確認したい場面 |
|---|---|---|
| 親商品 | 商品名、カテゴリ、ブランド、シーズン、企画区分 | 企画・仕入れ・商品一覧の集計 |
| 販売SKU | カラー、サイズ、バーコード、価格区分、販売単位 | 販売、出荷、棚卸し、店舗間移動 |
| 拠点 | 店舗、倉庫、売場、バックヤード、移動先 | 現在地と利用可能数量の確認 |
| 在庫状態 | 販売可能、引当、移動中、検品待ち、不良、返品確認中 | EC配信、補充、返品、差異調査 |
店舗間移動を正確に管理する機能
移動依頼の理由と優先度を記録する
店舗間移動は、売れ行きの差を埋めるだけでなく、イベントや撮影、顧客の取り寄せ、返品商品の戻しなど、さまざまな理由で発生します。依頼元と依頼先、SKU、数量、希望日、理由、依頼者を一つの伝票に記録し、後からどのような移動が多いかを確認できるようにします。緊急度や販売予定日を持たせると、本部が処理の順番を判断しやすくなります。
依頼を登録した時点で移動元の在庫を減らすのか、承認後に引き当てるのか、出荷時に減らすのかは、実際の店舗手順に合わせて決めます。重要なのは、画面の表示と現場の認識が一致することです。依頼だけで販売可能数から除外すると、キャンセルされた依頼が戻されない問題が起きます。申請、承認、出荷、輸送中、入荷、検品完了、差戻しなどの状態を持たせ、状態ごとの在庫計算を定義します。
出荷と入荷検品を別の処理にする
移動元の店舗が出荷した時点で、移動元の利用可能在庫から数量を減らし、移動中の在庫へ振り替えます。移動先が受け取った後、SKUと数量を確認して検品を完了すると、移動先の販売可能在庫へ反映します。出荷と入荷を一回の操作で同時に処理すると、輸送中の所在が分からず、片方の店舗だけが先に在庫を増やすことになります。
分納や数量違い、破損、誤配送が起きる場合も想定します。依頼数量、出荷数量、入荷数量、検品合格数量を別々に持ち、差異の理由と対応者を記録できるようにします。バーコードやハンディ端末を利用するときも、読み取り結果を画面で確認して確定できる手順を設けます。SKUが似ている商品を扱う現場では、カラーやサイズの表示を同時に見せることが入力ミスの抑制につながります。
在庫配分と移動の判断を分ける
店舗間移動が多いとき、個別の依頼を素早く処理するだけでは問題が繰り返されます。店舗別の販売、現在庫、入荷予定、取り置き、EC受注を合わせて見て、初回配分や補充ルールが適切かを確認します。移動先の売れ行きだけを見ると、移動元の販売機会を失う可能性があるため、移動前後の両店舗を同じ画面で比較できることが必要です。
店舗の特性によって、売れ筋のカラーやサイズは変わることがあります。全店舗へ同じ数を配るのではなく、販売履歴と売場の計画を参考に配分し、例外は担当者が理由付きで上書きできるようにします。自動配分を導入する場合も、どのデータを使って候補を出したか、担当者が何を変更したかを残せると、運用を見直しやすくなります。
EC連携で販売可能在庫をそろえる
ECへ配信する数量の基準を決める
ECサイトに表示する在庫数は、倉庫や店舗にある数量の単純な合計ではありません。受注済みで未出荷の商品、取り置き、返品確認中、撮影や検品に使っている商品を販売可能数へ含めるかを決める必要があります。販売可能数の計算を「帳簿在庫から引当と除外状態を差し引く」のように定義し、店舗とECで同じ基準を参照します。
店舗在庫をECへ公開する場合は、店舗の売場から出荷できるのか、店舗スタッフが取り置き分を除外できるのか、注文後にいつ引き当てるのかを確認します。全店舗の在庫を公開する方式が適するとは限らず、出荷可能な拠点だけを対象にしたり、一定の余裕を残したりする場合もあります。どの数量を公開したかと、公開後に変わった取引を履歴に残すことで、注文時の表示と実在庫の差を調べられます。
受注、キャンセル、出荷、返品を一つの流れにする
EC連携では、注文を受けた時点で引当を行い、支払い確認やキャンセル、出荷、配送完了などの状態を在庫へ反映します。注文を受けたが在庫確保に失敗したケース、分割出荷、注文変更、キャンセル後の再販売なども起こり得ます。注文番号と明細番号を連携キーとして保存し、同じ通知を再受信しても二重に在庫を減らさない仕組みが必要です。
返品は、倉庫へ戻った時点で販売可能になるとは限りません。検品が終わるまで返品確認中とし、再販売できる商品だけを販売可能へ戻す運用にすると、ECの表示数が実態に近づきます。返品理由や状態を記録すれば、サイズ交換が多い商品や、商品説明の見直しが必要な商品を検討する材料になります。複数モールや受注管理を連携する全体像は、EC在庫管理と複数チャネルを連携する記事も参考にできます。
連携エラーと商品コードの変換を管理する
ECの商品コードと在庫システムのSKUコードが同じとは限りません。商品ページのコード、バリエーションのコード、倉庫で使うバーコードの対応表を用意し、変換に失敗した商品を一覧で確認できるようにします。新しいカラーやサイズ、再入荷、商品ページの統合があるたびに対応表を更新し、更新者と反映日を残します。
APIや定期ファイルによる連携では、最後に成功した時刻、未処理の件数、エラーの内容、再送の結果を確認できる管理画面が必要です。連携が止まったまま古い在庫を配信すると、注文を受けられると誤認します。自動再送を設定する場合も、何度失敗したら担当者へ通知するか、手動で補正したデータをどう保護するかを決めます。連携方式の選択は、技術的な速さよりも、担当者が毎日確認し、異常時に復旧できるかを基準にします。
自社の商品の持ち方や店舗・倉庫の運用に合わせて連携方法を検討したい場合は、在庫管理システムの開発案内で対象業務を整理できます。ECだけを先に変えるのではなく、商品マスタの責任者と在庫の正となるシステムを決めてから、連携範囲を段階的に広げます。
入荷・販売・返品・棚卸しを同じ履歴で扱う
入荷と検品で在庫状態を分ける
仕入先や物流拠点から商品が届いた時点で、すぐに販売可能とするか、受入数量や品質を確認してから販売可能とするかを決めます。納品書の数量と実際に届いた数量が違う場合、入荷予定、受領、検品合格、差異処理を別の状態で保存します。入荷予定をそのまま現在庫に含めると、まだ届いていない商品を店舗やECへ販売してしまうためです。
検品で見つかった汚れ、傷、付属品の不足などは、通常の在庫調整だけで済ませず、商品状態と理由を残します。再検品を通過した商品を販売可能へ戻せるようにし、戻せない商品は修理、返品、廃棄などの処理へつなげます。入荷担当者と検品担当者を分ける場合は、誰がどの判断をしたかをログで追跡できるようにします。
販売・取り置き・予約を区別する
店頭販売はレジの売上データから在庫を減らし、取り置きは一定期間の引当として管理するなど、取引の種類に応じて在庫への影響を分けます。予約商品や入荷待ちの商品を、店舗の販売可能在庫と同じ一覧へ表示すると、接客時の案内を誤ることがあります。画面の利用者が迷わないよう、販売可能、引当、予約、移動中の数量をラベル付きで表示します。
売上取消や返品を受けた場合は、元の取引番号を参照して処理します。数量を現在庫へ直接加算するだけでは、どの商品がどの理由で戻ったかを確認できません。元取引、処理日時、担当者、商品状態、再販売の可否を履歴に残し、取り消し処理そのものも追跡できるようにします。
棚卸しの差異を原因とともに記録する
棚卸しは、システムの数量と現物を照合し、日常の登録漏れや保管場所の間違いを見つける機会です。アパレルでは、似たカラー、サイズの取り違え、売場とバックヤードの移動漏れ、返品の置き忘れが差異の原因になることがあります。計数対象のSKUと場所を明確にし、計数済み、再確認、確定の状態を管理します。
差異を確定するときは、帳簿数量、実数、差異、理由、承認者を保存します。すぐに現在庫だけを書き換えると、数字は合っても原因が残りません。登録漏れ、誤出荷、返品未処理、商品状態の誤り、計数ミスなどの理由を選択できるようにすると、店舗や工程ごとの改善点を見つけやすくなります。棚卸し後に必要な再発防止の確認まで、業務手順として定着させます。
本部と現場が使う画面・権限・分析
現場の画面は作業順に設計する
店舗スタッフが毎日使う画面では、商品検索、SKU確認、数量入力、状態の選択、確定という順番を短くします。カラーやサイズが近い商品を扱う場合は、商品画像や表示名、バーコードの一部を組み合わせて確認できると、選択を誤りにくくなります。入荷、店舗間移動、返品、棚卸しを同じ入力フォームへ詰め込まず、作業ごとに必要な項目だけを表示します。
本部の画面では、全店舗の数量、ECへの公開数、移動中、受注引当、欠品候補、滞留の兆候を切り替えて見られるようにします。詳細画面では、数量の合計だけでなく、入荷、販売、返品、移動、調整の履歴へ進めることが大切です。数字が違ったときに担当者が履歴を検索できなければ、結局別の表やメッセージで確認することになります。
店舗・本部・物流で操作権限を分ける
店舗スタッフは自店の入荷や販売、棚卸しを登録し、店長は差異や移動を承認し、本部は商品マスタや全店舗の配分を管理するなど、役割ごとに閲覧・登録・承認・取消の権限を分けます。物流担当者は倉庫と移動の検品を扱い、EC担当者は商品ページや公開在庫を確認するなど、業務の境界に合わせて権限を設計します。
異動や退職があったときに、利用者をすぐ停止できる管理画面も必要です。共有アカウントを使うと操作した人を特定できないため、個人アカウントと役割を紐づけ、変更履歴を残します。新店舗を追加したときの権限、応援勤務時の閲覧範囲、繁忙期の臨時担当者なども想定し、権限設定を一度決めたままにしない運用を作ります。
見るべき指標を業務の判断につなげる
アパレルの在庫分析では、在庫総量だけでなく、SKU別の販売の進み方、色・サイズの偏り、店舗別の欠品、移動の完了状況、返品の状態、販売期間を過ぎた商品の残り方を確認します。指標は、何を改善したいかと結び付けて選びます。例えば店舗間移動を減らしたいなら、移動件数だけでなく、移動前の配分や移動後の販売状況まで見ます。
季節商品を扱う場合は、期間を区切った一覧を保存し、現在の在庫と過去の販売状況を混ぜないようにします。色やサイズの構成が崩れている商品は、全体の数量が十分でも販売しにくいことがあります。親商品の合計、SKU別の内訳、店舗別の保有数を行き来できる画面にすると、商品企画、仕入れ、店舗運営、EC担当者が同じデータを使って判断できます。
システムの選び方と開発前の確認
候補の標準機能を業務フローで試す
システムを比較するときは、商品登録と在庫一覧があるかだけでなく、色・サイズのSKU、店舗と倉庫、店舗間移動、ECの引当、返品確認、棚卸し、権限、操作履歴、CSVやAPI連携を確認します。カタログやデモに通常の入出庫だけを見せてもらうのではなく、分納、誤配送、売上取消、サイズ交換、連携停止など、実際に起きる例外をどう処理するかを質問します。
候補ごとに、標準機能で使える部分、設定で対応する部分、追加開発が必要な部分、業務を変更して合わせる部分を分けて一覧化します。標準機能に見えても、店舗ごとの権限やECの公開在庫を細かく分けられないと、別の台帳が残ります。入力端末、通信環境、担当者の教育、導入後の問い合わせ窓口も含めて、毎日継続できるかを評価します。
ExcelやAccessを残す範囲を決める
既存のExcelやAccessに商品、販売、仕入れ、棚卸しの履歴がある場合は、すべてを捨ててから始める必要はありません。使っている項目、更新者、計算式、マクロ、外部連携、過去データの保存場所を確認し、商品マスタや履歴のうち移行できる部分を分けます。移行期間だけ旧台帳を参照用に残し、登録は新しいシステムへ集約する方法もあります。
一方で、ファイルが担当者のパソコンに分散している、同時編集で上書きが起きる、マクロの保守担当がいない、SKUの対応が不明といった場合は、機能追加より先に構造の診断が必要です。現在の仕組みを修正するか、Web化するか、専用システムを作るかを判断する際は、開発前のシステム診断で業務とデータの依存関係を整理できます。
費用だけでなく変更と運用の負担を比べる
サービスを選ぶ場合は利用料、初期設定、連携費用、教育、サポートの範囲を確認します。個別開発では、要件整理、画面、データ移行、外部連携、テスト、保守の作業を見積もります。安価に始められる方法でも、SKUや店舗が増えたときに手作業が急増すれば、別の費用が発生します。現在の負担だけでなく、商品の追加、店舗の開設、ECの販路追加、担当者交代にかかる作業も比較対象にします。
導入を進める手順
業務と在庫の定義を書き出す
最初に、商品企画、仕入れ、入荷、検品、倉庫入庫、店舗配分、販売、EC受注、出荷、返品、棚卸し、値下げ、廃棄までの流れを書き出します。それぞれの場面で、誰が、どの画面や帳票を使い、どの数量を増減させ、誰が確認するのかを整理します。現状のファイルやメッセージも並べると、二重入力や更新されない台帳を見つけやすくなります。
次に、「在庫あり」の意味を決めます。倉庫に物理的にある数量、販売可能な数量、受注で確保した数量、移動中の数量を分け、画面とECでどの数字を使うかを明文化します。商品コード、店舗コード、場所、カラー、サイズ、状態、取引種別の表記も統一し、マスタ変更の責任者を決めます。
マスタと履歴を整えて代表ケースを選ぶ
過去データを移行する前に、同じ商品が複数のコードで登録されていないか、カラーやサイズの表記が揃っているか、販売停止の商品をどう扱うかを確認します。すべての履歴を一度に正規化しようとすると時間がかかるため、現行商品、在庫が残る旧商品、頻繁に動くSKUなど、業務に必要な範囲から優先します。
試験には、通常の衣料品だけでなく、色やサイズが多い商品、返品が多い商品、店舗間移動が発生する商品、ECと店舗の両方で売る商品を含めます。入荷から販売、取り置き、返品、棚卸し、店舗間移動、EC受注までを一周させると、各状態の定義とデータのつながりを確認できます。
小さく試してから店舗とチャネルを広げる
最初から全店舗と全ECチャネルを切り替えるのではなく、協力を得やすい代表店舗、主要倉庫、対象SKUを選びます。旧台帳と新システムの数量を一定期間比較し、差異が出たら、マスタ、入力、連携、在庫状態、タイミングのどこに原因があるかを調べます。差異を手で合わせるだけではなく、原因と再発防止策を記録してから対象範囲を増やします。
本番展開では、商品マスタの締切日、初期在庫を確定する時刻、EC連携の開始、移動伝票の扱い、問い合わせ窓口を明確にします。店舗スタッフ向けには、長い仕様書だけでなく、入荷、移動、返品、棚卸しという作業ごとの短い手順を用意します。操作ログや連携エラーを誰が毎日確認するかを決め、導入後の改善会議で現場の負担を見直します。
導入後に起きやすい失敗と対策
リアルタイム連携だけを目的にしない
更新頻度を高めても、SKUコードや販売可能在庫の定義が揃っていなければ、間違った数量を早く配信するだけになります。まず取引の正となるシステム、連携キー、引当と解除の条件、連携停止時の表示を決めます。その後、欠品を防ぎたいチャネルや商品から更新頻度を選びます。すべての情報をリアルタイムにすることが、必ずしも現場にとって最も管理しやすいとは限りません。
例外を別ファイルへ逃がさない
返品、サイズ交換、誤配送、紛失、展示品、修理品などを別のメモや表計算へ逃がすと、在庫数だけが修正され、理由と担当者が分からなくなります。通常の取引履歴に状態と理由を登録し、承認が必要な処理には承認者を持たせます。例外の種類が増えたら、入力項目を増やす前に、業務で本当に必要な状態か、別工程の管理対象かを見直します。
本部が決めたルールを現場で検証する
本部で決めた配分や権限が、店舗の忙しい時間帯や売場の導線に合わないことがあります。試験運用では、入力にかかる時間、検索のしやすさ、誤入力の起き方、通信が不安定な場所での代替手順を確認します。現場から出た要望をすべて個別機能へ変えるのではなく、複数の店舗で共通する課題か、運用ルールで解決できるかを整理して優先順位を決めます。
よくある質問
アパレルの在庫は商品名だけで管理できますか？
商品名だけでは、色やサイズ別の欠品、補充、棚卸しを正確に扱いにくくなります。親商品で企画やデザインをまとめ、販売・出荷・棚卸しはカラーとサイズを含むSKU単位で記録する方法が基本です。画面で親商品の合計を表示する場合も、個別SKUの数量と履歴へたどれるようにします。
店舗間移動は、出荷時と入荷時のどちらで在庫を動かしますか？
出荷時に移動元の利用可能在庫から減らして移動中へ振り替え、入荷検品の完了時に移動先の販売可能在庫へ反映する方法が分かりやすいです。依頼や承認の時点で引当を表示する場合は、キャンセルや数量変更で引当を戻す条件も決めます。依頼、出荷、入荷、検品の数量を別々に保存することが大切です。
ECと店舗の在庫を同じ数量で公開すればよいですか？
倉庫や店舗にある数量のすべてを公開するのではなく、受注引当、取り置き、検品待ち、不良などを除いた販売可能数を配信する必要があります。店舗から出荷する運用なら、店舗スタッフが対象商品を確保できるか、在庫をいつ引き当てるかも確認します。公開した数量と、その後に受けた注文や返品を履歴で追跡できる構成にします。
既存のExcelやAccessを使いながら導入できますか？
商品マスタや過去の履歴を移行し、参照用として旧台帳を一定期間残すなど、段階的に進められる場合があります。まず、誰がどの表を更新しているか、計算式やマクロ、ECやPOSとの連携がどうなっているかを確認してください。同じデータを新旧両方へ入力する期間を長くしすぎないよう、登録先と切替日を決めることも必要です。
まとめ
アパレルの在庫管理では、商品名の合計を把握するだけでは、色・サイズごとの欠品や店舗間の偏りを判断できません。親商品と販売SKUを分け、カラー、サイズ、バーコード、シーズン、販売状態を共通のマスタで管理し、販売、入荷、移動、返品、棚卸しの履歴をSKU単位で記録することが出発点です。
店舗間移動は、依頼、承認、出荷、輸送中、入荷、検品を別の状態として扱い、移動中の数量を店舗やECの販売可能数へ誤って含めないようにします。EC連携では、受注引当、取り置き、返品確認、検品待ちを考慮した販売可能数を定義し、商品コードの対応と連携エラーを管理します。本部と店舗の画面は役割に合わせて分け、色・サイズの内訳と取引履歴まで確認できる状態を作ります。
導入時は、現在の業務と在庫の定義を整理し、マスタの表記ゆれと二重入力を減らします。色やサイズが多い商品、店舗間移動がある商品、ECと店舗で販売する商品を代表ケースに選び、入荷から販売、返品、棚卸し、連携まで試験してから範囲を広げます。必要な機能と現場の運用が整理できれば、既存システムの改修、クラウドサービス、個別開発を条件に沿って比較できます。
