売上100億円未満の小売企業向けのデータ一元管理SaaS「ストアレコード」をリリースしました
株式会社Bizgemの樋口です。昨日プレスリリースを出しましたが、売上100億円未満の小売企業向けのデータ一元管理SaaS「ストアレコード」のβ版をリリースしました。
今回はストアレコードというサービス開発に至った背景やどんな課題に実際に遭遇したのかご紹介しながら、ストアレコードというサービスの設計思想までお伝えできればと思っています。
サービス開発の根本にあったのは子供服D2Cブランド「ペアマノン」経営時代の苦労
私自身は前職は子供服D2Cブランド「ペアマノン」を運営する株式会社オープンアンドナチュラルの取締役として、製品づくり以外のECオペレーション・経営管理・物流・バックオフィスと幅広く担当していました。
Tシャツ1枚790円で提供するような低価格帯の子供服ブランドであったため、業務を極限まで効率化しローコストオペレーションを徹底する必要がありました。
一方でいざ取り組もうと思っても、年間およそ2万SKUを管理する必要があったためスプレッドシートでの管理には早い段階で限界を感じていました。ワークブック内のセルが上限を超えたエラーを見るたびに取得するデータを減らして、行・列が減るように工夫して、そのたびに構築した関数を変更するなど、業務効率化をしても度々変更する必要があり、システム化が急務だなと思っていました。
具体的な業務負荷1：商品登録の煩雑さ
年間2万SKUもある上にその商品登録を使っている業務システム、販売先には全て登録する必要がありました。登録が必要システムは下記の通り最大11個あり、登録作業も大きな負荷となっていました。
ネクストエンジン、Shopify、楽天、ZOZO TOWN、楽天ファッション、MAGASEEK、SHOPLIST、スーパーデリバリー、Qoo10、au PAY マーケット、Amazon
商品登録フローを効率化するために、スプレッドシートのマスタSKUのシートに必要情報を登録すると、上記それぞれのシステムの商品登録フォーマットに合わせた形で出力するシートなどを作っていました。
具体的な業務負荷2：リピート発注における必要データの整理
ペアマノンのビジネスモデルとしては小ロット・短納期生産を実現し、どの商品が売れるかわからない初回発注では薄く広くSKUを発注し、シーズン初期の立ち上がりの売上データを元に各SKUのリピート数量を決めることで売れる商品だけで在庫を構成するというものでした。
そのためリピート数量の決定は売上・粗利を左右する重要な業務でしたが、リピート発注のためのデータ収集とスプレッドシートの作成はかなり負荷が大きく、下記のような作業をしていました。
①委託先倉庫の在庫数を把握するためにネクストエンジンから在庫データをダウンロード
②ZOZO TOWNに委託している在庫数を把握するためにZOZOの管理画面から在庫分析データをダウンロード
③発注残を把握するために発注・納品管理しているスプレッドシートの対象シートをCSVでダウンロード
④商品の販売データを取得するためにZOZO、ネクストエンジンから販売数のデータをダウンロード
⑤季節による販売トレンドを考慮するためにカテゴリーごとの昨年の月ごとの販売数をまとめたシートを作成
⑥上記①〜⑤のシートを一つのスプレッドシートにシートをわけてインポートする
⑦発注対象のSKUを縦に並べて、それぞれのSKUの下記項目が横に並ぶようにスプレッドシートで表示
・フリー在庫数
・発注残
・販売数
・販売予測数=直近の販売数に対して昨年のカテゴリーの月ごとの販売数を係数にしてかけて算出
・発注推奨数（販売予測数 - フリー在庫数 - 発注残）
⑧発注推奨数をみながら各SKUの発注数量を決めて入力する欄に入力
上記のデータをまとめて間違っていないか確認して運用するのですが、①〜⑦のシート作成・確認に数時間かかっており、肝心の発注数量を決める前に疲弊していたのを覚えています。
中小の小売企業は同様の課題を抱えているのを感じたコンサルティング時代
ペアマノン時代の経験に加えて、2022年に設立した株式会社Bizgemでは中小小売企業を中心に経営コンサルティング業務から、ECオペレーションの運用代行まで提供しています。
コンサルティング業務を行う中で私自身が想像した以上に、中小小売企業ではデータ管理・データ周りの業務に課題があることがわかりました。
具体的な課題1：商品登録がモール・サイトごとに属人化しサイトごとに異なるSKUで登録
同一商品、同一SKUにも関わらず、サイトごとに異なる品番・SKUで登録されているケースがありました。サイトごとに商品登録方法が異なるため、各サイトの担当者の裁量で商品登録をしていたら、微妙に登録する品番・SKUが異なり、各サイトの独自ルールに合わせる形でどんどん異なるSKUで登録されるようになってしまったようです。
こうしたケースではどの商品がどれだけ販売されたのか、どれだけ在庫があるのか集計するのに大きな手間がかかってしまいます。マスタSKUを作成し、各サイトのSKUがどう一致するのか対応表を作成した上でデータ集計を行う必要があります。この作業はかなり大きな手間となりました。
具体的な課題2：全てのデータをエクセルで管理、10MB超えのエクセルばかりで分析の生産性が低い
エクセルは汎用性が高く、データウェアハウスとしても活用できるし、データ分析ツールとしても優秀だし、データ入力フォームとしても優秀で、汎用的にデータを扱うことができます。一方で優秀すぎるために、大量のデータ処理やデータ同士の関連性を示すといった苦手分野に関しても、エクセル上で無理やり処理をして出そうとしてしまうとかなり分析の生産性が低くなります。
例えば、先程述べたように、商品ごとの販売数・在庫数・発注残のデータを調べようとすると、それぞれのシートにエクセルの生データを貼り付けて、VLOOKUPやSUMIFなどを駆使してデータの統合を行うのですがその時点でかなり大規模なデータになってしまいます。
フォーマットを決めて運用する分には一度気合をいれてエクセルシートを作れば問題ないのですが、フォーマットを変更したい、新しくこの項目をみたいといった要望に応えようとすると大きな工数がかかってしまいます。データ分析は小回りよく、様々な角度で分析を行うことが業務・経営の解像度を高めるため、そういった時にエクセルでの管理には限界があると感じました。
具体的な課題3：発注残や商品ごとの原価のデータが未整備
売上や在庫データに関してはOMSが浸透してきたこともあり、API連携でしっかり管理できるようになってきている一方、発注と納品に関してはまだスタンダードとなるようなサービスがなく、管理が進んでいないように思います。ある企業では発注と納品は担当者のローカルPCにエクセルファイルとして残っているのみで発注残の管理ができていない & 原価となる納品単価もそのファイルで管理してるのみで商品ごとの原価管理ができていませんでした。
そのような状況だと今後いくらの納品予定があり、いくら支払う必要があるのかといったキャッシュフローの管理もできません。また商品ごとの原価管理ができていないと、日次・週次・月次での粗利や限界管理の確認をすることができず、ちゃんと利益が出ているのか、販促の効果が出ているのか確認することができません。
粗利や限界利益を正しく把握することで、どの販促が効果が高かったのか、どの販促は効果が見られなかったかの可視化に繋がり、その振り返りの回数の多さが企業経営を強くすることを子供服ブランド経営していた時も、アダストリアグループにジョインしてPMIしているときも感じていました。
こうした管理をしっかりとすることは失敗の確率を下げ、長期的に生き残る可能性を高めると考えているので多くのブランドが手軽に管理できるようにしたいと思ってストアレコードは作っています。
ストアレコードが解決する課題
ここまでご紹介した課題に対してストアレコードを使うことで下記のような課題解決が行えます。
①ストアレコードに商品データを登録することで各種ECサイトフォーマットに転換が可能
登録された商品マスタを元に、ZOZO TOWN・楽天市場・Shopify・ネクストエンジンなど各種システムに登録するフォーマットに転換してCSVなど各社の形式に合わせたフォーマットでダウンロードできる機能を提供しています。
ストアレコードに商品のマスターデータを登録していただくことでワンクリックで各社の商品登録フォーマットデータに転換してダウンロードすることが可能です。対応可能なプラットフォームは順次拡大していく予定です。
②直近の販売数・発注残・在庫数・過去の販売トレンドに基づく販売予測数から発注推奨数量を自動算出
ペアマノン時代にリピート発注は、売上・粗利を最大化する上で重要な役割を担っていました。ストアレコードではその際にスプレッドシートで苦労して出していたことを瞬時に算出することができるようにしています。
①委託先倉庫の在庫数を把握するためにネクストエンジンから在庫データをダウンロード
②ZOZO TOWNに委託している在庫数を把握するためにZOZOの管理画面から在庫分析データをダウンロード
③発注残を把握するために発注・納品管理しているスプレッドシートの対象シートをCSVでダウンロード
④商品の販売データを取得するためにZOZO、ネクストエンジンから販売数のデータをダウンロード
⑤季節による販売トレンドを考慮するためにカテゴリーごとの昨年の月ごとの販売数をまとめたシートを作成
⑥上記①〜⑤のシートを一つのスプレッドシートにシートをわけてインポートする
⑦発注対象のSKUを縦に並べて、それぞれのSKUの下記項目が横に並ぶようにスプレッドシートで表示
・フリー在庫数
・発注残
・販売数
・販売予測数=直近の販売数に対して昨年のカテゴリーの月ごとの販売数を係数にしてかけて算出
・発注推奨数（販売予測数 - フリー在庫数 - 発注残）
⑧発注推奨数をみながら各SKUの発注数量を決めて入力する欄に入力
ストアレコードを導入して日々の運用をしていただくことで、先ほどあげた上記業務のうち①〜⑦は不要になり、推奨発注数量ダッシュボードで毎日確認いただけます。
追加発注は売上を大きく左右する業務で、その業務が効率化され、確認する回数が増えることで売上・粗利の最大化にも貢献できるのではないかと思っています。
③平均原価・月末棚卸資産の原価自動計算
発注・納品データをストアレコードに登録すると、月末の棚卸資産についてSKUごとに納品された商品の平均原価計算を元に自動計算を行います。月末の棚卸資産は倉庫がAPI・RPA連携の対象となっていれば自動で数量を取得し、平均原価計算も自動で行うことが可能です。
小売企業の経理業務はSKUが多く、平均原価の計算をしようとすると煩雑な作業が必要になり、工数がかなりかかってしまいますがシステム化することで効率的に正確な経理業務を行うことができます。棚卸資産と納品金額を正確に把握することがブレの少ない月次ごとの粗利・粗利率の締め作業につながり、正確な経営状況の把握に繋がります。
④限界利益の自動計算
小売業においてはEC・店舗のどちらにおいても原価・販売手数料・広告宣伝費・物流費と売上に連動する費用を除いた限界利益の把握が重要な経営指標になります。ストアレコードにおいて商品データの登録に際に原価データを登録し、店舗ごとの販売手数料や物流費用を登録しておくと、限界利益を自動で計算することが可能です。
日々の限界利益の推移を見ながら販促の効果や店舗ごとの販売状況を把握することが可能です。
ストアレコードのサービス設計思想
このようにストアレコードを導入することで、まずは商品登録や月末の経理締めなど、リピート発注・データの取りまとめといったMD関連業務などの現場の業務が楽になります。その上で商品ごとの粗利、消化率、在庫日数、限界利益など経営上の重要な指標の管理も簡単に行えるようになります。
経営管理の効率化のために現場の負荷をあげるサービスではなく、現場の作業が楽になった上で、経営管理業務も効率化されるサービス設計を心がけています。それは私自身が前職および現職で経営管理業務だけでなく、小売の現場に紐づいた業務を自分自身でもかなり行っていることに基づいたサービスの思想の一つと言えます。そうはいっても導入に際して負荷はかかるものではあるので、導入サポートと導入が楽になる開発は今後も継続的にしていきたいと思っています。
まだまだ足りない部分があるため、ベータ版で提供していますが、すでに多くの課題を解決できることまた開発チームも整いお客様のご要望にも素早く対応できる体制が整いつつあるので、ぜひ今回ご紹介したような課題をお持ちの企業様はご連絡いただければ幸いです。
またサービスをグロースさせるための人員も募集しています。下記ページよりお気軽にお申し込みください！
この記事が気に入ったらサポートをしてみませんか？