流通在庫管理システム
店舗ごとに分散していた在庫を本部基準で統合し、リアルタイムで同期しました。
- 開発期間
- 約7か月
- 体制
- 5名
- 対応プラットフォーム
- ウェブ · サーバー
- 連携システム
- 既存の会計システム
背景
店舗ごとに在庫台帳が別々に運用されていました。本部が全体の在庫を把握するには店舗に電話をかけて回るかExcelを集約する必要があり、その間に実在庫と台帳がずれることが繰り返し起きていました。
実装範囲
- 店舗別の入出庫登録
- 本部での統合在庫照会
- 店舗間の在庫移動申請・承認
- 在庫不足のしきい値通知
- 既存会計システムとの連携
- 店舗担当者向けモバイル画面
技術選定
その状況で何をなぜ選んだか既存の会計システムはそのままにし、在庫データはAPIのみで同期
会計システムを新規に作り直すと税務処理まで再検証する必要が生じ、リスクが大きくなります。在庫管理の領域だけを新しく構築し、締め時点で会計側に必要な数値だけをAPIで渡す方が安全でした。
在庫の変動を状態値の更新ではなく入出庫イベントとして記録
今の在庫が何個かだけを保存すると、なぜそうなったのかを追跡できません。入庫・出庫・移動をそれぞれイベントとして積み上げ、現在の在庫はその合計として計算するようにしたことで、在庫の不一致が起きた際にどの時点・どの店舗でずれたのかを遡れるようになりました。
技術課題
課題
店舗スタッフが在庫移動を登録するだけで、受け取り側の店舗が確認しないと台帳と実物がずれてしまう問題がありました。
アプローチ
移動申請と受領確認を別の段階に分け、受領確認が済むまでは両方の店舗の在庫に「移動中」の状態が表示されるようにしました。
結果
移動中の在庫がどちらの店舗の所管かが画面上ですぐ確認できるようになり、受領漏れによる台帳の不一致を減らせました。
課題
既存の会計システムは夜間バッチでしかデータを受け取れない構造で、在庫システムがリアルタイムで送り出すイベントと周期が合いませんでした。
アプローチ
在庫システム側に日次締めのスナップショットを別途蓄積し、会計システムのバッチ周期に合わせてそのスナップショットだけを渡す中間層を設けました。
結果
在庫システムはリアルタイムのイベント構造を維持しつつ、会計システムは従来どおりの方式でデータを受け取れるようになりました。
引き継ぎと運用
店舗担当者向けの利用マニュアルと本部管理者向けの運用ガイドを別々に作成して提供しました。ソースコードと配布インフラの構成を引き継ぎ、最初の3か月間は店舗拡張時に発生する問題に限って保守を支援しました。