現場で使える業務アプリ化で、属人化を解消し可視化。

受発注と在庫の情報が紙・Excel・担当者の記憶に分かれており、誰かが休むと業務が止まる。

在庫数が実態と合わず、出荷のたびに倉庫へ確認の電話が入っている。

仕入先ごとに書式の違う納品書・請求書の突き合わせが、月末に集中している。

在庫が合わない原因は入力ミスではありませんでした。在庫の数字が生まれる場所が複数あることが本質です。紙とExcelと担当者の記憶がそれぞれ別の「正しい在庫」を持ち、どれを信じるかが人によって違っていました。

したがって解くべきは「入力を正確にする」ことではなく、在庫の数字が生まれる場所を1つにすることだと整理しました。

月末に作業が集中するのも、業務量の問題ではありませんでした。締めまで数字が確定しない設計が原因で、日次で確定していく形に変えれば、総量は同じでも山がなくなります。

現場がスマートフォンで扱える業務アプリへ移し、受発注・在庫・入出庫を1つのデータに統合しました。

倉庫別の在庫管理と、発注書・納品予定の倉庫分割に対応しました。

入金・支払の予測、前受金の請求突合、月次棚卸の出力を自動化しました。

商品マスターの更新を、仕入先から届くメールと添付から起こす仕組みを設計しました。

在庫の確認が画面上で完結するようになり、倉庫への確認電話がなくなりました。

月次の棚卸と支払予測が自動で出力されるようになり、月末に集中していた作業が平準化されました。

現在は保守運用フェーズに移行し、日次で稼働しています。

既存の基幹システムは置き換えていません。業務アプリ側で完結する範囲に絞りました。

会計・仕訳の自動化は今回の範囲外としました。

うまくいかなかったことが4つありました。

1つ目は、出荷したのに在庫が減らない事象です。原因はデータの登録順に依存する処理で、画面上は成功しているように見えていました。

2つ目は、仕入先IDの不整合で発注が通らない事象です。マスタ側の表記ゆれが原因でした。

3つ目は、データベースとアプリでタイムゾーンが異なり、日付が1日ずれていたことです。画面では正しく見えるため気づけません。

4つ目は、共有ドライブへ移行する際に参照が切れる箇所が複数あったことです。移行前にチェックリスト化して潰しました。

現場がスマートフォンで入力する運用に変えられること。PCへ戻すと使われなくなります。

商品・仕入先マスタの表記ゆれを、移行前に一度棚卸しできること。

在庫が合わない原因を「アプリのせい」で止めず、登録順・タイムゾーン・権限まで切り分けられる体制。