こんにちは、ウィルダー株式会社の松崎です。
卸売業B社様の販売管理システムの刷新に取り組み、帳簿上の在庫と倉庫の実在庫のズレを、出荷のたびに検知できる仕組みを設計しました。
市販の販売管理パッケージの限界を感じている卸売業や、倉庫を外部に委託している企業の方の参考になる事例です。
この記事では、課題・取り組み・成果の順にご紹介します。
クライアント紹介
| 項目 | 内容 |
|---|---|
| 匿名表記 | 卸売業B社様 |
| 業種 | 卸売業 |
| 地域 | 関東地方 |
| 規模感 | 従業員10〜20名規模 |
こんな課題をお持ちの方におすすめです
- 帳簿の在庫と倉庫の実在庫が合わず、棚卸しで初めてズレに気づく
- FAXや電話、他社のEDIで届く注文を、毎回手で入力し直している
- 店舗別や問屋別など、取引先の単位で売上を見たいのに集計できない
導入前の課題｜販売管理システムの限界と在庫のズレ
出典：https://unsplash.com/ja
導入前の最大の課題は、帳簿上の在庫と倉庫の実在庫が連動せず、ズレが後から判明していたことです。
B社様は、取扱商品が増え、事業が伸びている段階にありました。
一方で、業務を支える仕組みは市販の販売管理パッケージと、外部の倉庫の在庫が別々に動く形でした。
お話を伺うと、課題は次の4つに整理できました。
課題1：在庫が合わない
帳簿の在庫と倉庫の実在庫が連動しないため、差異が出ていました。
その結果、現場での欠品が起きたり、棚卸しで初めて分かった余剰在庫を安く処分したりする場面がありました。
課題2：受注を取り込めない
FAX・電話・他社のEDIで届く発注を、システムに取り込めていませんでした。
手入力で再入力するしかなく、二重入力とミスのもとになっていました。
課題3：パッケージの機能制約
現行のパッケージが、業務に必要な機能の限界に達していました。
たとえば、在庫評価が平均法に固定されていること、1つの商品に複数の品番を持てないことです。
さらに、合計請求書に他社の名前が混ざり、締め処理が止まる問題もありました。
課題4：集計・分析ができない
店舗別・問屋別・親会社別に売上を切り分けられず、どこが伸びているのかが見えない状態でした。
成長を続けるうえで、足かせになりつつあったのです。
ウィルダーに依頼した理由
ご相談のきっかけは、事業の成長とともに、パッケージと倉庫の在庫のズレが現場の負担になってきたことでした。
取扱商品が増え、取引先も広がる中で、在庫のズレによる欠品や、注文の再入力にかかる手間が目立つようになっていました。
パッケージの設定を工夫するだけでは限界があり、業務全体を見直せる開発パートナーを探していたところ、私たちにご相談をいただきました。
決め手となったのは、現場の業務を整理するところから一緒に進める姿勢と、受注から集計までを一気通貫でつなぐ全体像をお示しできたことです。
私たちがご提案で大切にしたのは、次の3点です。
- 受注から在庫・出荷・請求・集計までを、一気通貫でつなぐこと。部分的な改修ではなく、業務全体をつなぐ形を提案しました。
- パッケージを引き継ぐ機能と、新しく作る機能を分けて示すこと。「何が変わり、何がそのままか」を一覧にして、判断しやすくしました。
- 特定の受注システムに縛られない構造にすること。受注システムの選定が途中でも進められるよう、接続部分を差し替えられる設計にしました。
取り組み内容｜販売管理システム刷新の進め方
全体を、受注取込・販売管理・在庫管理・在庫突合・請求入金・集計の6つの仕組みに分けて刷新しています。
プロジェクトの概要を以下の表にまとめます。
| 項目 | 内容 |
|---|---|
| 期間 | 約12か月（想定）。最初の約3か月を第1フェーズとして進行 |
| 体制 | 【要確認：体制（人数・役割）】 |
| 担当範囲 | 要件定義・設計・開発・データ移行・テスト・本番移行・初期サポート、およびリリース後の保守運用 |
| 使用技術 | クラウド（AWS）、BigQuery、Looker Studio ほか |
ステップ1：現状の業務を整理する（ヒアリング・要件定義）
最初に、現在の業務の流れと、パッケージで実際に使っている機能を整理しました。
ここで抜けや漏れがあると、後の開発で手戻りが生じます。
そのため、画面や機能の一覧を作り、業務を担当する方への確認を重ねています。
ステップ2：在庫の「正」を倉庫に一本化する
在庫の正しい数字は倉庫に置き、帳簿の在庫と分けて管理する設計にしました。
帳簿在庫は受注の引当（在庫を確保すること）に使い、実際の在庫は倉庫を基準にします。
出荷が確定するたびに、倉庫の出荷実績と帳簿を突き合わせます。
加えて、毎日、倉庫の在庫全件を取得して照合します。
差異があれば担当者に通知し、倉庫の数字に合わせて帳簿を補正する流れです。
これまで棚卸しで初めて分かっていたズレを、前倒しで見つけるための仕組みです。
ステップ3：受注を自動で取り込む
FAXや手入力に頼っていた受注は、取り込みの仕組みを整えて減らしていきます。
取引先が使っているEDIやCSVのデータを、社内の形式にそろえて取り込みます。
FAXの代わりとして、取引先がWebの入力フォームから直接発注できる画面も用意します。
他社のEDIでJAN（商品コード）が異なる問題は、後述の「別名」の登録で解消します。
ステップ4：パッケージでできなかった機能を新しく作る
パッケージでは実現できなかった機能を、要件として新しく作り込みます。
主なものは次のとおりです。
- 1つの商品に複数の品番を持たせる（デザイン番号、後付けのJAN、取引先別のJANなどを「別名」として紐付け）
- 在庫評価を平均法から先入先出法（FIFO）へ変更。先に仕入れた商品から順に出荷したものとして原価を計算する方法で、為替や輸入にかかる諸経費も反映
- 取引先ごとに正しく締めて請求書を発行（他社名が混ざらない）
- 入金と売掛の消込、未入金のアラート
- 海外の仕入先向けの英文発注書の発行
ステップ5：売上を多角的に見える化する
取引先に親子の階層を持たせ、店舗別・親会社別・問屋別に売上をまとめて見られるようにします。
BigQueryとLooker Studioを使い、売上の分析画面や、在庫の推移・滞留の確認画面も用意します。
将来は、販売予測にもとづく適正在庫の提示も視野に入れています。
ステップ6：テスト・移行・リリース後の運用
リリースの前に、テストとデータ移行、本番への切り替え、初期サポートまでを行います。
リリース後は、不具合対応や軽微な改修、監視、バックアップ、定例報告を含む保守運用に移ります。
Web受注との連動やデジタルカタログなどは、この基幹の仕組みが整った後の拡張として、段階的に進める計画です。
現在は、開発に先立つ要件定義を進めている段階です。
導入後の目標｜期待する変化
導入後の目標は、在庫のズレの早期発見、受注入力の自動化、売上の見える化の3つです。
本プロジェクトは進行中のため、以下は提案時に掲げた目標です。
導入前の状況と、導入後に目指す姿を比較表にまとめます。
| 項目 | 導入前 | 導入後の目標 |
|---|---|---|
| 在庫のズレの発見 | 棚卸しで初めて判明 | 出荷のたび＋日次で検知し、担当者へ通知 |
| 余剰在庫の処分 | 判明後に安く処分 | ズレや滞留を早く把握し、処分に至る前に対処 |
| 受注の入力 | FAX・電話・他社EDIを手入力 | 自動取込と入力フォームに置き換え、二重入力をなくす |
| 在庫の評価方法 | 平均法 | 先入先出法に変更し、為替・輸入の諸経費も反映 |
| 請求・締め処理 | 他社名が混ざり、止まることがある | 取引先ごとに正しく締め、請求書を発行 |
| 売上の集計 | 店舗別・問屋別に切り出せない | 親子階層で、店舗別・親会社別・問屋別に集計 |
※導入後の実際の成果は、リリース後に確認でき次第、追記します。
同じような課題をお持ちの方へ
在庫のズレや受注の手入力にお悩みの卸売業・流通業の企業様は、同じ考え方で改善を進められる可能性があります。
本事例の規模と期間の目安は、次のとおりです。
- 期間：約12か月（最初の約3か月で中核部分を整理）
ただし、業務の範囲や連携先の数、倉庫や受注システムの状況によって、規模は大きく変わります。
まずは現状の課題をお聞かせください。
どこから着手すると効果が出やすいかを、一緒に整理します。
よくある質問
Q. 開発期間はどれくらいかかりますか？
A. 本事例では、全体で約12か月を想定しています。最初の約3か月を第1フェーズとして、要件の整理と中核機能の設計から進める計画です。業務の範囲や連携先の数によって変わるため、まずは現状をお聞かせください。
Q. 費用の目安はどれくらいですか？
A. 受注取込・販売管理・在庫管理・在庫突合・請求入金・集計の6つの仕組みを含む金額で、範囲や機能が変われば金額も変わります。概算は、要件を伺ったうえでご提示します。
Q. 倉庫を外部に委託していても連携できますか？
A. 連携できる可能性は高いです。ただし、倉庫側が在庫のスナップショットや出荷実績を、APIまたはCSVなどの形式で出せることが前提になります。突合の精度と実装範囲を左右するため、最初に倉庫側の出力できるデータの粒度と頻度を確認します。
Q. 導入後のサポートはありますか？
A. はい、保守運用のプランをご用意しています。不具合対応、軽微な改修、監視・バックアップ、定例報告などが範囲です。大規模な改修や新機能の追加は、別途お見積りとなります。
Q. 今使っているパッケージのデータは移行できますか？
A. はい、データ移行も開発の範囲に含めています。取引先や商品などのどのデータをどこまで移すかは、要件定義の段階で整理し、移行後の確認までを一緒に進めます。
Q. 地方の企業でも依頼できますか？
A. はい、可能です。打ち合わせはオンラインでも対応できますので、所在地を問わずご相談いただけます。まずはお問い合わせください。
さいごに
この事例のポイントは、次の3つです。
- 帳簿在庫と倉庫の実在庫を分け、倉庫を「正」にして、ズレを出荷のたびに検知する
- 受注の入り口をそろえて自動で取り込み、二重入力をなくす
- 取引先の親子階層で、店舗別・親会社別・問屋別に売上を見える化する
販売管理システムの刷新や、在庫・受注まわりの業務改善でお悩みの方は、お気軽にご相談ください。
