通販ノウハウ満載の通販・ECブログ | アパレルECサイト・Eコマース担当者必見の通販戦略やファッションコラムが充実

BLOG 通販担当者必見のノウハウや注目事例が満載。あなたのビジネスに貢献する通販ブログ

EC・通販担当者必見!作業負担を大幅に軽減し、売上拡大が図れるPOS・基幹システムの機能要件

2015.06.11:ノウハウ, 事例紹介
EC・通販担当者必見!作業負担を大幅に軽減し、売上拡大が図れるPOS・基幹システムの機能要件

便利なはずのPOS・基幹システムが、足枷になっていませんか?

こんにちは野田 (@KURUZE) です。

本来、業務をサポートするための基幹システムですが、煩わしい入力作業に追われ逆に足枷となってしまう。

特に実店舗中心に設計された基幹システムの多くは、EC担当者にとって悩みの種となっているケースが「ほぼ」だと思います。

なぜこのようなケースが多発するのか、詳しい説明は TKzoe.com の記事に詳しいので是非ご一読いただきたいのですが、私からは実際に基幹システムの改修を行うことで、業務負荷が大幅に軽減された効果的な改修内容をご紹介させていただきます。

 

売上データをアップロードできるようにする

これは基本中の基本。改修前は、各取引先から送られてくる( または管理画面からダウンロードした ) 売上データを手打ちで入力していました。

実店舗はPOSと連携しているので、レジを通せば売上入力は終わり。しかし取引先各社の倉庫からお客様の元へお届けする通販ではPOSを通していないので、1つ1つ売れたものを入力していく必要があります。

当然、月末の締め作業の際に1度で金額が合うはずもなく、何度も見直しを強いられました。

理想は、通販各社のフォーマットにあわせた取り込み口を用意することですが、複数のデータフォーマットに対応すると開発費用がかさみます。そこで各社のデータに共通する最低限の項目だけ取り込めるようにすればOKです。

基幹で売上入力する店舗を指定して取り込む場合は、<JANコードまたは品番などSKUまで特定できるコード><販売数量><販売価格>といったところでしょうか。

店舗登録の際に料率を登録している場合は、店舗指定でその料率を引っ張ってくる仕様にすればOK。料率を登録できない場合は、データ項目に<下代>を追加しましょう。

すべてを取り込むデータに持つ必要がある場合は、<店舗コード><JANコードまたは品番などSKUまで特定できるコード><販売数量><販売価格><下代>といった項目が必要になります。

後は差分データだけ取り込むか、常に上書きして取り込むか、業務内容に応じて選択していきます。

取り込みの際には、取引先から来る売上データの不要な部分をExcelでカットして、並び替えた後にアップロードが基本。

ですが都度、削除して並び替えるのは面倒ですよね。そこでオススメは、Excelで売上データを貼り付けると別シートに必要な項目だけが抽出され並び変わるファイルを作成すること。簡単に作成できますし、置き換え作業がコピペ1発で終わります。

 

商品マスタをダウンロードできるようにする

これも基本中の基本。取引先に商品マスタを提供する際、必要となるデータを基幹から取り出せるとベスト。売上データ同様、各取引先ごとに合わせたデータをダウンロードできれば良いのですが、開発予算を踏まえるとそうもいきません。

そこでポイントとなるのが【 登録されている項目は全てダウンロードする 】ということ。

例えば、サイズコードやカラーコードが必要な取引先や、品番と共にJANコードが必要な取引先、さらには自社で撮影した画像を提供するケースでは、採寸情報や混率、商品コメントまで提供する必要があります。もちろん今後、新規の取引先が増えることも想定されます。

このように、あらゆる状況に対応できるようデータは全て落とすに越したことはありません。

ダウンロードしたデータは、先程の売上データの置き換えファイルと同じ要領で、貼り付けると別シートに各取引先の商品マスタに合わせた項目だけが抽出されるExcelファイルで管理。

ただし、商品コメントやサイトに合わせたカテゴリ情報 (=特に子カテゴリ)など、どうしても基幹に登録されている商品マスタでは足りない項目が出てきます。

取引先の担当者が登録を代行していくれるケースであれば問題ないのですが、自社で管理画面に登録する場合は、どうしても手作業で追加していく地道な作業が求められます。

 

基幹システムと物流システムの連携

商品マスタの登録や仕入れ、売上管理は基幹を使い、商品を動かす際には物流のコントロールシステム(以下WMS)を使う。このようなケースも多いと思います。

この場合、基幹に入力した移動指示をもう1度WMSに入力(またはアップロード)する必要がでてきます。これは本当に不毛な作業です。

しかし自社の基幹システムに入力した指示がWMSと連携すれば、2度手間がなくなり見るべきシステムが1つで済みます。

一方で契約している倉庫に自社の基幹システムを入れる、という考えもあります。しかし倉庫の目線で考えると、使い慣れないシステムで運用することになるので作業が属人化しがち。普段から使い慣れた自社のWMSであれば、オペレーションが統一されるので安全です。

実際の連携方法については、もう千差万別。申し訳ありませんが、ここでは書き切れませんので割愛させていただきます。代わりに理想の移動フローだけ紹介しておきます。

1. 出荷指示をたてる
      ↓
2. 移動が出荷指示に基づき出荷検品を行う
      ↓
3. 移動元が荷物を出荷
      ↓
4. 移動元から出荷確定数が届く
      ↓
5. 移動に出荷確定数と同数の入荷指示がたつ
      ↓
6. 移動先に荷物が着荷
      ↓
7. 移動先が入荷指示に基づき入荷検品を行う
      ↓
8. 移動先から入荷確定数が届く
      ↓
9. 移動先の在庫として計上

という流れで、指示データに対してハンディターミナル等でバーコード検品を行い完了データを返す。このように指示数と実数の付け合わせを出し入れの際に行うことで、差異をなくします。

 

店間移動を劇的にラクにする店間移動機能

EC担当者に限らず日々変化する各店在庫を調整する店間移動というのは重要な業務の1つだと思います。

私が勤務していたアパレルブランドでは当初、この業務は下記のフローで行われていました。

1. 期間指定をして、その期間の販売枚数と現在庫が記載された帳票を呼び出し

2. 表示された帳票をプリントアウトする

3. 無数に並んだ数字の中から在庫が多く残っている店舗や倉庫を見つけ出し、売れている店舗への移動数を検討

4. 検討した内容をプリントした帳票に手書きで記載

5. メモした数字を1つ1つ拾い上げながら、基幹システムに移動指示を入力していく


このようにプリントした用紙に移動元となる店舗の在庫に〇をつけて、移動先となる店舗へ矢印を引いていく(笑)。そして在庫を抜く、つまり移動元となる倉庫や店舗が10箇所あれば10回移動指示を基幹システムに入力していく。そんなアナログな対応をしていました。poslist
↑こんな感じで、プリントアウトに手書きで書いていました

 

そこで思ったのが、この紙で書いている概念をそのまま画面で再現できたら便利すぎる!ということ。時は基幹システムのリプレイス真っ只中。まさに渡りに船。実装に動きます。

まず、期間を指定していきます。移動すべき商品が決まっている場合は、品番も個別指定していきます。指定がなければ全品番。

画面に表示されるのは、各店舗の指定期間の売上と指定期間末の在庫。移動元となる店舗から在庫数をマイナスすると、在庫が仮確保され移動先の店舗へプラスできる仕組み。

1つの画面で各店の在庫数と売上枚数を確認しながら、在庫の抜き差しができます。

pos
↑直感的に指示が出せる店間画面 (クリックで拡大すると在庫移動が行われます)

さらに売り切れている商品は赤、1週間以上動きがない在庫には黄色に塗りつぶされ、在庫がなくなりそうなものは( 販売スピードも考慮して ) 赤字で表示するので、動かすべき在庫がすぐに分かります。

しかもここで移動した在庫は、在庫を抜かれた店舗には出荷指示、在庫が投入される店舗には入荷指示が同時に立ちます。つまり、これまで5つあった行程が1と5だけに簡略化され、さらに直感的に指示が出せるインターフェイスへと変わりました。

 

卸先がネットを通して、いつでも注文できるようにする

通常、基幹システムは商品マスタも在庫情報も持っています。ではその情報を通販サイトのような画面に置き換えてブラウザで見れるようにすれば、卸先の受注システムへ早変わりします。

基幹システムに直接オーダーが入るので、FAXやメールでオーダーシートを回収する必要もありませんし、集めたシートをExcelで集計をする必要もありません。さらには、伝票を発行するために集計した数量を基幹システムに打ち込み直す必要もありません。

いきなりオーダー数の調整というステップから作業を開始することができます。確定した内容は、自動メールで卸先に送付することで都度連絡する手間が省けます。もちろん閲覧するにはパスワードが必要。卸先ごとにランクを設けて掛け率を変えることもできます。

これが実現すると、卸先は在庫状況がいつでも把握できます。倉庫にある在庫を見て客注という新たな販売機会が生まれ、今主流になりつつある在庫一元化が通販各社だけでなく卸先にも広がります。

個人情報の管理やカート機能など、複雑な仕組みが必要なEC機能を基幹システムに実装するのは難しくとも、卸先からのオーダーを集めるという仕組み自体はもう十分に実装が可能ですし、いくつかの基幹システムではパッケージ機能として実装されています。

通販担当者にとっては直接関係ない機能かもしれませんが、全体の最適化という意味で効果の大きい機能の1つです。


以上、皆様の会社でも使えそうな事例はございましたか?

システムは使われるものではなく使うもの。しかし基幹システムの改修や入れ替えは難度を極める業務ですので、少しでもこれらの事例がお役にたてば幸いでございます。

The following two tabs change content below.
野田 大介

野田 大介

株式会社ファナティック代表取締役 / 買い物中毒のファッション通販アドバイザー
月刊誌Ollie magazineの編集者からキャリアをスタート。その後は、フリーライターとしてhoneyee.comやLightningなどでの執筆、複数のアパレル企業で商品企画、生産管理、店舗/卸営業、通販業務を歴任。現場の最前線で培った通販の運用実積に加え、メディア業界で培ったコンテンツ・マネージメント力、そして長年のアパレル経験と、アパレル通販を運営する上で必要な知識と現場経験の両面を網羅。趣味、というか生きがいは「買い物」

この記事を読んだ方へおすすめ

PAGE TOP