オムニチャネル・OMO 商品・在庫連携機能のポイント

第３回は
顧客は最終的には、＃D2Cブランド から商品を購入することで、何らかの「＃ベネフィット」を満たす、実現することになります。
それを実現するために必要な、商品情報と、在庫、そして顧客がどうそれを手に入れるかに必要な
＃商品・＃在庫情報統合
についてお伺いしています。
https://fujilogi.net/blogs/news/fujilogi-news-023

オムニチャネル・OMO 商品・在庫連携機能のポイント With Lexica #3

商品と在庫とは

中田様
我々の「＃Lexica:＃レキシカ」は技術的には、＃オブジェクト指向 というのを何より優先して設計しています。
そこで「ドメインモデル」を採用しています。

ドメインモデルとは

リアルは＃在庫管理システム（＃IMS）
在庫管理システムでの商品はあり、それが #SKU 。
SKUにその商品の名前が付いていてユニークに管理されています。
原価とか販売価格は通常価格が登録されているかも知れません。
#Eコマース （#EC）は商品マスター
#PDPに表示するデータ 、カートに表示するために値段などつけて入れといたのが「#商品マスター」になります。
これを連携させようとなります。顧客情報統合と同じで、本当は違うものですよね。
#在庫管理 （倉庫・店舗など）側では、物としてそこにあるのかないのかっていうのを識別しないだけです、
ECの方では商品というのは、別にどこにあるかどうでもいいというがあるわけですよ。
何が売れたのかという「売買契約」をしたいだけなので、値段があって、その他の付帯条件が、「何」という契約が当事者同士でちゃんと合意できること。
その商品がどこにあって、どう渡すかは別の管理になる。
コードが一緒だからっていう理由で連携してしまうから、何か変なことが起きたり、何か複雑な読み替えが必要になってしまいます。
例えば
キャンペーン価格で販売して、コードが変わってしまうと、バックエンド側が受け取れない
価格がマスターと一致しないから全部エラーになる。

商品情報はこう持つ

商品には
SKUに該当する概念「何であるかっていうこと」と
それに対して販売条件「それをどう売りたいか」が付きます。
これを組み合わせて、商品になっています。

一対一で組み付けないとピッキング出来ないではだめ

例えば
#ダイナミックプライシング で同じものに対して複数値段をつけることができないとか、手間がかかったりではいけない。
あとは、在庫は、売り方が違うだけで同じで100ぐらいあるけど、2パターンあるっていうときに割り当てをしなければいけない。
片方だけが売れたときに、そちらだけが在庫切れになってしまう。

Lexica「商品」の管理

解決策は「#在庫の仮想化」
続きはこちらから