fc2ブログ

月別アーカイブ

← 2004年08月 →

こだわりの在庫リアル処理⑫ 

パソコンＰＯＳ回想録⑫（１９９８年）

「ＢＣＰＯＳ」を開発する上で
システム的にもかなりこだわったことがいくつかある。
一つは、すべての在庫処理をリアルに行うことだった。

いままでのＰＯＳシステムというと、
バーコードを当てて販売を行うと
それをすべてトランザクションとして溜め込み
業務が終了後、データ集計を行い、売上や在庫を集計する。
そのために、締め処理というものが必ず存在した。

「ＢＣＰＯＳ」では、
常に売上や在庫や稼動実績やポイントを
販売と同時にリアルに集計を行い
常に最新の情報として見れるように処理を行った。

一番苦労したのは在庫の処理であった。
パソコン１台だけの処理では何ら問題が起きないのだが
ＬＡＮで複数台接続して使用する環境も設計に入れていたため
複数のＰＯＳで同一商品を同時に販売しても
在庫が狂わないようにしなければならなかった。
それには排他制御を行う必要があった。

たとえば、複数台Ａ、Ｂ、ＣのＰＯＳで販売する時
同じ商品を同時にバーコードをスキャンすると
それぞれのＰＯＳはデータベースにアクセスした順番に販売する前は、
Ａ：在庫10、Ｂ：在庫9、Ｃ：在庫8　と表示しなくてはならない。
しかし、店頭ではバーコードをスキャンした順番に販売されるわけではなく
バラバラなタイミングで処理が行われる。

たとえばＣ、Ｂ、Ａと読み込んだ逆に
一個ずつ売った結果は、
Ｃ：在庫9、Ｂ：在庫8、Ａ：在庫7　とならなければならない。
これはすでに在庫を読み込んで来たとしても、
販売時に再度在庫を見直して、再計算をしなければならない。
これは、データベースとのタイミングの調整が非常に大変であった。

これをリアル処理ではなく、後処理でやったら意図も簡単に出来てしまう。
サーバで販売した順番に在庫を減らしていけば済むだけの話だ。
そのためのマシン「ストコン」なる不思議なものが流通業界には存在する。

ちなみになぜ、私がこのリアルな在庫にこだわったかと言うと
お店では在庫が見えると非常に便利なことが多々ある。
ＰＯＳ上で在庫が見れれば、いちいち棚をチェックする必要もなく
適正な在庫、適時な発注、在庫の過不足等を把握することが出来る。
倉庫やバックヤードに保管される在庫も要注意だ。

店によってはいちいち店頭の在庫を確認するために、
しょっちゅう簡易な棚卸を行い、発注の目安にしている店もある。
過剰な仕入を起こすと、破棄しなくてはいけない無駄が出てくる。
それに在庫が切れた時点で即座に発注が出来れば翌日の納品に間に合うが、
業務を終了し、集計した時点で発注かけたのでは、翌々日になってしまう場合もある。

商品の在庫を切らすと、即座に売上のダウンにつながる。
それに、それを調べたり、集計するための人件費は、日々積み重ねると莫大な費用にもなる。

ＰＯＳデータは過去の数字だとよく言われ続けていた。
これは、リアルな処理が出来ず、過去しかデーターが参照できなかったからである。
つねにリアルな情報を見れるようにすることは
お店の経営向上にかなり結びつけることが可能になる。

私は今でも在庫をリアルに表示できるＰＯＳを見たことがない。
他メーカの商品と差別化するには、こういった細やかな情報も必要となる。

究極の目標は「売上を伸ばすことの出来るＰＯＳ」である。パソコンである限りまだまだ可能だ。
スポンサーサイト