ロケーション設定の課題とストッククラウドの改善策

Stockclowd/ストッククラウド活用事例
システム導入前編-1

現場から始まったロケーション設定の挑戦 ― ストッククラウド開発の原点

在庫管理システム「ストッククラウド」の開発を振り返ると、
最初の大きな壁は「ロケーション設定」でした。

■ 既存システムの限界

当時の既存システムでは、
「製品冷蔵庫」「製品冷凍庫」「原料冷蔵庫」「原料冷凍庫」
といった大きなカテゴリ単位でしか在庫ロケーションを設定できませんでした。

つまり、庫内のどこにあるかまでは分からない。
入庫データ上は「冷凍庫」となっていても、実際にどのラックにあるのか――
これは現場スタッフの“記憶”と杜撰なエクセルデータ頼るしかない状況でした。

■ 最大の課題は、430パレット分のラック型冷凍庫

特に在庫差異の多くを生んでいたのが、430パレット分を格納できるラック型冷凍庫です。
そこには約50種類の製品と原料が保管され、段ボール換算では15,000CS以上。
（システムとの理論在庫差異に金額にすると、うん千万円の差異がでてしまっていました。）

在庫差異の発生も、必然でした。なぜなら運用はほぼフリーロケーション方式。
「空いているラックに順にしまう」という運用のため、
同じ製品でも毎回置き場所が変わる。それも数十パレットも・・・。

■食品という罪深い製品特性

いざ、製品を必要とする時は、見取り図を片手にマイナス25度の極寒の冷凍庫の中に入って
現物を探さなければいけなく、取扱製品や原料は「食品」であったため、
古い賞味期限から使用しなければいけないという制約がありました。

防寒着を着ていても、マイナス25度の中で扱うフォークリフト作業は
体が5分と持ちません。庫中に入ってのんびり在庫を探し回るなど到底不可能なのです。

■シンプルすぎて意味のない在庫管理

筆者がこの管理に携わる前に、運用管理はどうしていたかというと
430ほどあるパレットラックの見取り図をエクセルで起こして、
そこにメモ書きして残しておくという超シンプルなものでした。

そのシンプルすぎる管理が大きな在庫差異を生みだし、
在庫照合や棚卸のたびに大きな負担となって
負のスパイラスを繰り返すという現実がありました。

■ 「番地設定」をしても現実に追いつかない

既存システムにも“番地設定”の機能はありました。
しかし1製品につき1ロケーションしか登録できず、
回転率の高い冷凍製品には対応しきれませんでした。

たとえば、ある製品を1回生産すると約640CS（1パレット40CS × 16パレット）。
これを430ラックのどこにどう配置するのか――
1ロケーションでは到底管理しきれません。

■ 紙とExcelからの再出発

そこでまず行ったのが、紙とExcelによるロケーション管理の再構築でした。
具体的には、まず430パレットを収容できるラックスペースの1つ1つに
ロケーション（パレットを格納するラックの住所のようなもの）を設定していきました。
そして、製品を生産して格納するたびに、どのパレットがどのラック（番地）に置かれたのかを
スタッフが手書きで記録し、Excelに転記。

それと同じタイミングで、管理レベルを一気に上げて「品目名」のみの情報から、
1.「番地」2.「品目CD」、3.「品目名」、4.「生産日」、5.「賞味期限」6.「残数量」を
控えておき、一日の荷役作業が終わった後に、それらを全部エクセルに
打ち込んでいくという地獄の作業が発生しました。

結果的に、管理レベルを急に上げたことにより、オペレーションに作業員が追いつかず、
入力も追い付かない、管理ルールが守られないということが多々起きてしまいました。

いわば、「デジタル移行前夜」の絵にかいたようなトライ＆エラー。
この段階では、まだPower Appsを使ったストッククラウドの導入までは至っていませんでした。
しかし、この“面倒な手作業の蓄積”こそが後のシステム設計の礎となったのです。

（次回へ続く）