
本記事のテーマ
ECサイト運営の在庫一元管理システム(在庫一括、在庫連動、各種連携)
本記事で得られる知識
ネットショップ(EC)運営上必須となってくる在庫一元管理システムのメリットを理解することができます。
また、最初の設定で後々の業務負担が決まってくる性質があるため、失敗しない設定の仕方、管理における重要ポイントを実務レベルで解説します。
記事の前提
本記事はB2B並びにB2Cのネットショップ運営を前提としたバックヤード業務に関する記事です。
1. 在庫一元管理システムとは
1-1. 他モール間の在庫管理を一括管理
在庫一元管理システムとは、複数のモールや自社サイトで設定する在庫設定を1つの管理画面で済ますためのシステム、ツールです。
例えば、1つのある商品100個をアマゾン、楽天、ヤフー、自社サイト内で販売して、1個アマゾンで売れた場合、アマゾンはそのまま設定在庫数が99個となりますが、それ以外の楽天、ヤフー、自社の在庫数については、何もなければ手動で99に変更する必要があります。
これを、統一の管理画面を設けて、統一の管理画面の中で在庫数を変更するとヒモ付している全てのモール内の在庫数が変更され、またどこかで注文が入れば、入った個数の在庫を他のモールでも自動的に変更してくれるツールのことです。
これが在庫管理の一元化です。
1-2. とにかく業務効率が高い
在庫一元管理システムを利用すると、とにかく業務効率が非常に高いです。
上記の例えでアマゾン、楽天、ヤフー、自社サイトで販売をしている場合に1つのアイテムの在庫数を変更するためにも、
- 管理画面にログイン
- 在庫管理ページへ移動
- 検索
- 変更
たった1つのアイテムの在庫数を変更するだけでも、上記のプロセスを全てのモールの管理画面で変更する必要がありますから、最低でも2分程度はかかる計算になります。
筆者が過去の運営経験では、最大で取り扱っていたアイテム数はアマゾン、楽天、ヤフーでそれぞれ15万アイテム。ということは全てのアイテムを変更するのに30万分もかかることになり(1日は1440分しかないので)、そうなると実務上は必ず在庫管理は手を抜きます。
これが自動化されるとなるといかに効率がいいかが分かると思います。
1-3. 実在庫管理の徹底が大前提
誰がどう見ても聞いても試しにいじってみても在庫管理の一元化は非常に業務効率がいいのですが、これを最大限にうまく利用するとなると、大前提は「実在庫管理の徹底」というアナログ管理が不可欠になります。
その理由は、在庫管理一元化の本質は業務効率化ではなく、実在庫とデータ在庫差異をなくして、その前提となる販売戦略に役立てる、販売戦略に費やす時間を確保する、顧客満足度を向上する」という目的の達成こそ重要なためです。
一元化ができても、一元化されるデータ在庫数と、実在庫数にデータ差異がない状態こそ、徹底的に管理されていることを意味します。
この前提にたった販売戦略は、いい加減な在庫管理による販売戦略に勝ります。
この前提にたった時間確保は、いい加減な在庫管理による後手後手の時間確保より、計画性で勝ります。
この前提にたった顧客満足度は、いい加減な在庫管理によるクレームや低評価の状態より圧倒的に勝ります。
差のない実在庫管理とデータ在庫数への反映(最新性の維持)は全ての業務において、効果を発揮しますので、一元化よりも実在庫の管理が重要であり、その上にたって一元化を利用すると、他社を圧倒できます。特にこれからの時代は(2019年はもちろん、5Gが始まる2020年以降は特に)商品についてどれだけ知識を深めてシェアするかが重要になってくる時代ですので、「管理を徹底し、さらにそれをキープすることを前提に」販売戦略が必要になります。
2. 実在庫管理に必要なこと
2-1. 実在庫が変動する要素とは
実在庫はいろんな理由によって増減します。入荷のようにわかりやすく多くの数量が変化することもあれば、1つ1つとちみちみと増減する場合もあります。
実在庫が増減するタイミングとデータ在庫が増減するタイミングは異なります。この異なる時間差が積もり積もって、実在庫とデータ在庫の差異に繋がります。
実際のタイミングの違いを増減要素別に見ていきましょう。
2-1-1. 注文商品をピッキングした時
データ在庫は注文が入った時点で数が変わりますが、注文商品の実在庫が減るのは注文商品の梱包用に商品をピッキングした時になります。
アマゾンやモノタロウのような大手の場合には、リアルタイムでピッキング作業をしているとは思いますが、大多数のショップは「ピッキング処理は1日で2,3度」がほとんどではないでしょうか。
注文は24時間受け付けていますが、その24時間分の注文のピッキング処理が1日で2,3回しかないので、実在庫とデータ在庫の減るタイミングが大幅に違います。
2-1-2. 返品された時
商品が返品された場合は実在庫数は増えることになります。返品による商品の戻しも、データ在庫の変更も手動で行うことになります。
意識的には、商品が目の前にあれば戻すのは自然ですが、データ在庫も戻す作業は怠りがちなので、ここを怠ることで実在庫とデータ在庫がずれることになります。
2-1-3. 商品が入荷した時
商品入荷時は数が大幅に増えることになります。
お店により異なりますが、商品の予定数が確定数とみなして、そのままデータ在庫数変更するとなれば、実数確認をしていませんので(数量的に不可能な場合もありますが)、この時点で実数とデータ数との差異が発生する可能性が出てきます。
2-1-4. 交換のために商品を抜いた時
お客様から不良や破損の連絡を受け、商品の交換対応となったときは、実在庫数をピッキングすることになりますが、ここでデータ在庫数を更新しないと差異が発生することになります。
2-1-5. 検品時に不良が発生した時
単純に商品の検品作業をしている時に不良が発生すれば、その分数が減ることになります。
判明した不良品数分をデータ在庫から引かないと差が発生することになります。
2-1-6. それ以外(盗難など)
上記以外でもなぜか実在庫チェックをすると減っていることがあります。
考えられる理由としては、ピッキングの戻し場所の間違いや、盗難などが考えられます。
ピッキングの戻し間違いというのはかなり問題で、戻し間違いをした時点で間違って置いた在庫棚内の数も間違う可能性があり、更に次回ピッキングの時に商品を間違う可能性さえ出てきます。
盗難ですが、逐一実在庫数の最新性を維持する徹底をしない、差が出たときに徹底的に原因を追求しない、管理がずさんな倉庫というのは、抜いたところですぐに気づきませんし、意図的に商品をとったところで全く気づきません。
ですので、意外と窃盗による在庫の減りは存在することになります。
2-2. 定期的な棚卸し
実在庫数の最新性を維持するために大切なのは「地道な数のチェック」に他ありません。つまり、棚卸しです。
2-2-1. 月単位の場合
月単位でやる場合には、1日まるまる全スタッフ投入で行うなどしないと作業量が圧倒的に多いので、とてもではないですが徹底は不可能です。
2-2-2. アイテム別の場合
ネット販売用在庫としての棚卸しは、筆者としては少量のアイテム数に絞って毎日実数チェックすることが望ましいと思います。
アナログの紙で管理している場合には、まず全ての商品についてのチェックする順番を決めておくのと、その日の注文商品(つまり増減があったものを優先的に)毎日チェックするというものです。
その日に注文があったものについてはその日に実数チェックをすることで実在庫数がある程度最新性を保ちますし、注文が少ない商品もチェックする順番を決めておくことで、一定期間に1度はそのアイテムのチェックする順番が回ってきますので、売れる商品は売れた段階、売れない商品も一定期間に一度で実数確認することができるためです。
2-3. 売れ筋を梱包場所の近く
売れ筋商品を定期的に梱包する場所の近くに移動させておくのも、実数確認の効率化のためには必要です。
倉庫では「移動時間の短縮」が重要です。一番売れる商品が一番遠い場所にあれば、取りに行く時間でロスが発生します。ロスが発生すれば時給分の労務費がかかります。つまり、それだけで経費が高くなるためです。
2-4. 整理整頓
倉庫内作業は全て整理整頓が大前提になります。
商品なのか、資材なのか、ゴミなのか何がどこにあるのかが、ひと目で全くわからない倉庫は意外と多いです。
筆者が経験した中で一番ひどかったのは、ただ商品がダンボールつみになっているだけのものでした。
棚を輸入して棚組みし、ロケーションをふって、そこに商品を入れ込み、ロケーションをデータ化、商品もデータ化、そして商品とロケーションを紐づけして初めて、商品を管理する状態にもっていったことがありますが3000アイテム全てに対して実際に棚を組むところから始めめ、システムもオリジナルで組んだため1ヶ月要しました。
が、その後の作業効率は当然ながら大幅にあがり、改善前よりも改善後の売上が1.1倍に対して、梱包投入時間前年の2/3になるという効果を得ました。
2-5. 原因追求の徹底(条件付き)
原因追求については、なぜ在庫が減ったのか増えたのか、差異が発生したのかという原因を、ケースが発生するたびに追求して対策を施すということです。
想定した原因と実際の原因が一致していた場合、対策を施せば基本的にそれ以降は同じ要因によるミスがなくなりますので、これを繰り返すことでより品質の高いオペレーションが可能になります。
但し、これは目に見えない作業の内容をきちんと理解しているものが原因追求をして対策を施すからこそ効果のあるものです。
計算書類しか見ていない現場を知らない運営者や経営者が、原因追求すると全く検討違いの原因追求をしてしまい、間違った要因を元に改善をし(たと勘違いして実施し)、その結果として結局現場の負担が別のところで増えてしまったというケースは、圧倒的に多いです。
もし現場作業が「机上の空論」的な実際に経験をしたわけでもなく、思い込みによってでしか把握できていない場合には、この原因追求は逆に牙をむくことになります。
3. 一元管理のために必要あデータ在庫知識
3-1. 在庫最小単位を理解すること
一元管理のサービスを利用するにあたっては、先に一元処理するために「マスタ」と呼ばれる商品情報を一元管理のシステムに登録していく必要があります。
これ、、、、かなりの手間ではありますが、かなり手間である上に理解力不足なのが「在庫最小単位」の存在です。
在庫というのは、基本的に在庫最小単位で管理します。在庫最小単位とモールなどで登録しているSKUの構成内容は違いますし、SKUと仕入れ時のアイテムの構成単位も全て同じなわけではありませんし、在庫最小単位とJAN商品の構成内容も異なります。
3-2. 数種類の商品マスタの違い
これが理解できていないと後々になってマスタの登録のし直しをしたり、例外としてモール内でのアナログ修正が必要だったり、エクセルをもって編集したものを一括でアップロードするなど、一元管理システムを利用しているのにも関わらずなぜか余計に手間が増えることになります。
3-2-1. 在庫最小単位とSKUの違い
例えば、セット販売をするとなったときに、在庫最小単位でいうAとBで組み合わせた商品をセット販売する場合、在庫最小単位Aと在庫最小単位Bを組み合わせたものSKUになるので、構成単位が全くことなります。
セット品で注文が入った場合は、モール上の在庫は1減るとすると、倉庫ではAからもBからも1つずつ数を引く必要があります。
他にも、セット品が在庫最小単位Aが2つと在庫最小単位Bが1つで構成されているとして、Aが28個、Bが30個あった場合、 SKUとしてモールに反映させるべきデータ在庫数は14になります(Aが2個セットのため14,Bは30となり、このうち少ない数がセット品で売れる最低数量なので14。)。
この計算の必要性さえ理解していないスタッフが圧倒的だと思います。
3-2-2. 在庫最小単位と入荷商品の構成の違い
例えば、Aという商品が入荷する場合に、Aは本体と付属品によって構成されているとします。この時、付属品に不良が多いので多めに発注していて入荷した場合は、Aという1つの商品が入荷したにも関わらず、在庫管理は最小で行うので、Aの本体とAの付属品の2種類を倉庫で管理することになります。
3-2-3. 在庫最小単位とJANの構成違い
JANが発行された商品であっても、在庫最小単位で管理する場合には、上記の本体と付属品と同じ概念になるので、在庫最小単位はずれることになります。
3-2-4. 一元管理ではこの構成差の管理が重要
一元管理システムではまず商品マスタと呼ばれるものがあり、ここに登録をしていくことになりますが、システムによってはセット品に対応している場合があり、その場合の元になる商品マスタは「在庫最小単位」で登録する必要があります。
間違っても出品しているSKUを基準にやると、あとあと困ることになります。
例えば、2個でAという商品を出品しているからという理由で、一元管理の商品マスタにこのSKU情報を入れてしまうと、後々になって1個で販売しようとなっても、最小単位のマスタに1個単位のものがないので、参照する対象を新たに作り直さないといけません。
商品マスタの構成の修正とSKUの紐づけの修正を行う手間が増えますし、何十というSKUで結びついてしまっている場合は修正が聞きませんので、そうなるとこの商品だけアナログで管理するという一元化のためのシステムを利用しているのに例外を自ら作るはめになります。
3-3. 優先モール
在庫数の決定は、モールごとに優越を決めることもできます。
在庫数が100ある商品を、アマゾンでは30個、楽天では50個、ヤフーでは20個と設定することもできますし、残り1個の数量の分け方をモールで決めることも可能です。
3-4. 適した一元化サービスを探すこつ
3-4-1. 相見積もりが前提
大前提は「相見積もりをとること」です。
当たり前といえば当たり前なのですが、受注処理件数、在庫管理アイテム数に数によって金額が変動するためです。
これを読んでいただいている読者のお店のアイテム数を、業者に投げて月にいくらかかるのかを聞いて見るといいでしょう。
在庫一元管理は、受注処理の一元化と同一の場合も多いので、モールごとの過去1年間の、月別の注文件数、注文個数を出した上で、見積もりを出すといいと思います。
アイテム数が多ければそれなりの金額になるでしょうし、受注量が多くてもそれなりの金額にはなります。
重要なのは1社ではわからない点。必ず相見積もりをとるようにしましょう。
3-4-2. セット品概念は必須の項目
最近はどこもセット品に対応してきていますが、新規事業などの場合はまだ対応していないところもありますので、ここは機能としてマストです。
今は利用していなくても後々必ず必要になってくる概念で、一度設定すると一旦連携を破棄した上で修正する必要があります。
3-4-3. 最新性が何分なのか
注文が入った時点で他のモールの在庫数を変更するのが一元化のメリットです。
これはシステム側の話になりますが、注文が入ったから瞬時に在庫を変更するのではなく、正確には「5分に1度」や「30分に1度」一元化サービス側で、各モールの管理画面にアクセスし、そこから注文情報を引き出して、新規注文かどうかを判断しています。
この頻度が多ければ多いほど最新性が高いのですが、アクセス数が多ければ多いほど、一元化システムを提供している会社側のサーバーの負担が大きくなるので、通常は5分に1度、30分に1度などの間隔を置いているところがほとんどです。
選ぶこつとしては、この頻度が低くて安いところを選ぶことになります。
余談ですが、筆者が独自にプログラミングで作ったシステムでは5分に1度にアクセスして注文情報を引き出し、在庫情報の更新は変動したものだけを1分間隔で行っていました。
4. 一元化サービス一覧
4-1. ネクストエンジン
業界では最も利用されている一元化システムの一つ。
業者の中では一番はやくセット品と在庫最小単位の紐づけ機能を設けているので、現場主体での改善では改良力が高いといえます。
受注処理や商品情報処理も含んでいますが、料金体系は月額の固定費と、月の受注件数で変動します。
但し、取り扱いアイテム数が予想以上に多いと別途見積もりになる可能性もありますので、見積もりは必ず取りましょう。
4-2. 助ネコ
手軽に利用できるところから始まっている、一元化システム。
セット品構成に対応しており、在庫管理・受注管理・商品管理の3種類から何を選ぶかによって料金が変わります。
5000アイテムまでは月5000円が基本ですが、それ以上は見積もりが必要になります。
通常は30分に1度のアクセスで情報引き出しですが、追加料金で5分に1度にすることができます。
4-3. クロスモール
こちらもかなり大手といえる一元化システムの1つ。
クロスモールの強みは、在庫連動に対応するモール・ショップ・決済カートだけでなく、委託在庫や運送会社の送り状印刷ツールが幅広い点です。
長期的な視点においての業務拡大の際に大きく役立つ対応力です。
4-4. GoQSystem
在庫一元化、受注処理、商品管理などの一元管理が可能。
この会社の強みは、なんといっても大和運輸・日本郵便と連携した送り状・納品書一体型の印刷システム。
バックヤード業務においては、受注処理が一元化されても、運送会社の送り状システムに対応していても、結局は印刷された送り状と納品書の印刷順を一致させた上で、アナログで「照らし合わせ」「ヒモ付」と呼ばれるアナログ作業をしているところが未だに圧倒的多数と思いますが、これがはじめから送り状と納品書がくっついた1枚の用紙に印刷することで、照らし合わせ字の「テレコミス」がほぼ撲滅できることになります。