棚卸については一度も当社は行ったことはありません。
なぜなら必要がないからです。在庫が狂わないからです。
当社のシステムは商品管理に、Janコードだけではなく、マイナンバーでの管理を導入しています。つまり、マイナンバーを持っていると、誰がいつどのように発注し、今どこに置いているかなぜどのように出庫したか販売したか などのユニーク管理が可能になりフリーロケーションにより保管された商品は、理由なき移動はできず、また保管期間というタイムスタンプを使えば、賞味・消費期限の管理や保管期間の制限による販売設定や保管期間が長いものの販売促進などあらゆることでIDやログを使って商品を管理することが可能になります。
倉庫に関していえば、スペースという課題がございます。棚の足元に車輪がついていれば、棚からやってくるような倉庫を作ることも可能です。そうなれば、テトリスのように棚は埋まっている倉庫となります。XYZ軸の倉庫の位置情報を管理できれば、近い棚から順に棚自体がやってくるような倉庫は、アマゾン社が実践しだしております。
倉庫は、梱包して配送するだけでしょと、安易に考えている人は、おそらく生涯ＥＣで儲けることはできないでしょう。配送する個数が、何千個なら、１個当たりの１００円単位の経費削減が、１０万円になります。数万個なら数百万円になります。物流は、どっかの組合の会費みたいなものと私は表現しています。会員数が多ければ、会費が１０００円でもとんでもない金額が集まってしまいます。それを、安易に研究をせずに依頼をするということは、お金だけではなく、それだけの大事なものが毎年委ねてしまうということになりかねません。もし、自分たちが、ＥＣショップと自覚して商売をするならば、必ず倉庫は、自社物流を選択する方向でぜひ検討をしてみてください。
在庫更新の行くつく先は
このたび、楽天市場が大がかりなデータ更新の仕様変更を行ったように、ベストなデータ更新ははたしてどのようなものかということばかり考えて難しく難しくしているのは、結局は自分たちだということに気づく時期までは少し時間を要します。
なまじっか賢いSEたちは、きっちり在庫を更新したいとなり、無駄なSQL文やクエリが増える結果となります。現在、サーバー容量は大きくなり、通信速度も処理速度もかなり早くなった時代にはなおさらデータ更新に関しては、ミラーリング的な更新方法が一番シンプルで早いものになる場合が多いです。また、精度もそのほうがよっぽど良くデータ更新がされないゴミデータが蓄積するという最悪な結果もなくなります。データ更新は、ピンポイントに更新するというロジックを確立をするよりも、ALLデータを上書きするミラーリング式を私は総括するとおすすめいたします。
商品マスタ管理
文字数の制御など制御系は、出力時よりも入力時に制限をかけた方がよい
各モールで出品データにかけられている制御や制限は、アウトプット時に振り分け処理をするのではなく、オペレーターが使うI/Fのブラウザ内で、Javascriptなどで直接入力時にかける方がよいです。それは、アウトプット時に制限をかけると、オペレーターが制限の内容を把握できず的外れなデータを作ってしまうからです。オペレーターが制限を把握し、または、制限の変更を把握し、現場がその回避をノウハウにしてしまうようなものでないとシステムエンジニア側で理解し制御しても、いずれある仕様の変更を把握し、対応することすら難しい状況になります。つまり、メンテナンスも含め、現場が毎日、肌で触れなけばいけない状況を作る、すなわち、Ｉ／Ｆ側で制御する方が私は、良いと考えています。
出品データのアップロードは、現場に任せログを見てエラーを取り除く
各モールの出品データに対するログ、すなわちエラーに関しては現場によりデバッグをするほうがよいです。先ほども申し上げたように、現場オペレーターが理解し、デバッグを販売向上を見込まなければ、システム担当は、カスタムや開発に追われており、出品ログまでを把握し、メンテナンスをし続けるわけはいかないというのが現実でございます。現場が売上向上を目指し戦う場所であり、その現場が販売棚に関してきちんと整理整頓された品質のよいものが表示されているかどうかを確認することは当たり前のことでございます。システムの改良が必要な場合も、現場から担当SEに、我々の成績がおかげで下がったくらいのクレームを入れる気持ちで、ＳＥの尻を叩きデバッグや改良の指示を出すような現場づくりが望ましいです。