ROI事件ファイル No.536『二つの倉庫は、同じ商品を別々に数えていた』
二つの倉庫は、同じ商品を別々に数えていた
第一章：同じ在庫を、二度数えている
「自社ECサイトと楽天市場、二つのサイトの在庫管理が別々なんです。二重管理を解消したい」
Globex社の代表、海老原誠一氏は、そう言いながら画面を見せた。「楽天が売上の約九割を占めています。自社ECは最近本格稼働したばかりで、商品点数も少ない。でも、二つを別々に管理していることで、問題が出ている」
「二重管理で、どんな実害が出ていますか」とClaudeが尋ねた。
「繁忙期に在庫がズレます」と海老原氏が答えた。「片方で売れたのに、もう片方の在庫数が更新されない。結果、在庫切れの商品を売ってしまって、お客様に謝罪する。これが頻発する。商品を掲載するときも、二つのサイトに別々に登録する二重作業が発生している」
「顧客情報の管理は」と私が確認した。
「これも分断しています」と海老原氏が答えた。「楽天のリピート情報は二年分しか見られない。それ以前は手作業で管理。同じお客様なのに、サイトをまたぐと別人として扱われる。とにかく、同じものを二度管理する作業が、あちこちにある」
「同じ仕事を二度やるのは、典型的なムダですね」と私が応じた。「LEANで流れを整えましょう」
第二章：LEANが問う、どこにムダが潜んでいるか
「この案件には、LEANが必要です」
Claudeがホワイトボードに「LEAN」と書いた。
「LEAN——リーンとは、価値を生まないムダを徹底的に取り除き、仕事の流れをなめらかにする考え方です」と私が説明した。「トヨタ生産方式が源流で、在庫の二重管理、待ち、手戻り、二度手間——こうしたムダを特定して削る。重要なのは、個々の作業を速くするのではなく、流れ全体を整えること。同じ商品を二度数えるムダを、流れの設計で消す道具です」
「まず現状のコストを測りましょう」とGeminiがROI Polygraphを開いた。海老原氏から提供されたデータを入力する。
「月間の二重管理コストが出ました」とGeminiが読み上げた。「二重在庫管理の手作業工数が月平均百九十時間、時給三千四百円で月六十四万六千円。在庫ズレによる欠品・謝罪対応コストが月平均七十万円。商品掲載の二重作業工数が月平均四十五万円。顧客リピート情報の手動管理工数が月平均三十万円。在庫切れによる販売機会の逸失が月平均五十五万円。合計で月二百六十四万六千円。年間換算で約三千百七十五万円」
海老原氏が数字を見つめた。「在庫管理の手間だけだと思っていました。欠品の謝罪対応や、販売機会の逸失まで入れると、二重管理がこれだけ削っていたとは」
「では、LEANで設計します」と私が続けた。
[価値の定義——顧客にとっての価値は何か]
「最初に、価値を定義します」とClaudeが言った。「お客様にとっての価値は、注文した商品が確実に届くこと。在庫がズレて欠品の謝罪をするのは、価値を損なうムダの最たるものです。何が価値で、何がムダかを定義することが、改善の起点になります」
[ムダの特定——流れのどこで二度手間が起きるか]
「次に、ムダを特定します」とGeminiが続けた。「在庫データの流れを可視化すると、二重管理、在庫ズレ、掲載の二重作業、顧客情報の分断——同じ仕事を二度やるムダが連なって見える。点ではなく、流れのどこで価値が損なわれているかを特定します」
[流れの設計——一元化でムダを消す]
「特定したムダを、流れの設計で消します」と私が続けた。「在庫管理と受注管理を一元化し、二つのサイトの在庫をリアルタイムで連動させる。商品情報は一括管理し、自動更新する。二度数える作業そのものを、流れの設計で発生させない構造にします」
[改善の継続——回しながら整える]
「最後に、改善を続けます」とClaudeが続けた。「導入して終わりではなく、定期的にモニタリングし、新たなムダを見つけて削る。従業員へのトレーニングも継続する。LEANは一度の大改革ではなく、ムダを見つけて消し続ける運動です」
[投資回収を試算する]
「ROI Proposal Generatorで試算しましょう」とGeminiが提案した。
- 初期費用：在庫・受注一元管理システム構築・自社EC/楽天連携・商品情報一括管理・データ移行・研修費用合計六百四十万円
- 月次費用：システム利用料・運用継続費合算月二十二万円
- 月次削減効果：二重管理工数削減＝月五十二万円（八割削減想定）、欠品・謝罪対応削減＝月五十万円、掲載二重作業削減＝月三十六万円、販売機会逸失の回復＝月四十二万円、合計月百八十万円
- 月次純削減：百八十万円－二十二万円＝月百五十八万円
- 投資回収期間：六百四十万円÷百五十八万円＝約四・〇ヶ月
「四ヶ月の回収です」とGeminiが整理した。「効くのは、作業を速くするのではなく、二度やる作業そのものを消す点です。在庫を一元化すれば、二重管理という作業が発生しなくなる。ムダを減らすのではなく、ムダの発生源を流れの設計で断つ。これがLEANの効き方です」
海老原氏が数字を確認しながら言った。「在庫管理を効率化する、としか考えていませんでした。流れを整えて、二度数える作業をなくす。発想が違いました」
「LEANは、ムダの発生源を流れの設計で断つ道具です」と私が応じた。
第三章：流れを整える導入計画
「進め方を整理します」と私がホワイトボードの前に立った。
「第一ヶ月——現在の在庫・受注管理のヒアリング、データの流れの可視化。第二ヶ月——ムダの特定、一元管理システムの選定。第三・四ヶ月——在庫・受注一元管理システムの構築、自社EC・楽天市場の連携。第五ヶ月——商品情報の一括管理機能の実装、データ移行。第六ヶ月——本番稼働、従業員トレーニング。第七ヶ月以降——モニタリングと改善、顧客情報の統合、新たなムダの除去」
「楽天が九割の売上です。連携でトラブルが起きませんか」と海老原氏が確認した。
「だから流れを可視化してから設計します」とClaudeが応じた。「いきなり繋ぐのではなく、データの流れのどこでズレが起きるかを特定してから一元化する。売上の主軸である楽天との連携は、最も慎重に設計する。ムダを消すために新たなトラブルを生んでは本末転倒です。流れを見てから、断つ」
海老原氏がメモを取りながら言った。「二度数えるのが当たり前になっていました。なくせるものだったんですね」
第四章：在庫が、一つの数字になった日
九ヶ月後、海老原氏から報告が届いた。
二重在庫管理の手作業は、一元管理システムの稼働三ヶ月後に従来比で八割削減。「二つのサイトの在庫が一つの数字に統合された。片方で売れれば、もう片方も即座に反映される。二度数える作業が消えた」と海老原氏は記していた。
在庫ズレによる欠品も大幅に減少した。繁忙期の在庫切れ謝罪が激減した。「在庫がリアルタイムで連動するから、売れないものを売ってしまうことがなくなった。謝罪のメールを書く時間が消えた」と報告書にあった。
最も大きな変化は、繁忙期の現場に表れた。最も混乱していた時期が、最も恩恵を受けた。「繁忙期こそ在庫がズレて謝罪に追われていた。今は繁忙期でも在庫が合う。一番きつい時期が、一番楽になった」と海老原氏は記していた。
商品掲載の二重作業も解消された。一括管理と自動更新により、二つのサイトへの登録が一度で済むようになった。「同じ商品を二回登録する作業がなくなった。新商品の投入が速くなった」と報告書にあった。
副次効果として、顧客情報の統合も進み始めた。サイトをまたいだリピート把握の基盤ができた。「同じお客様を、サイトをまたいで一人として見られるようになりつつある。次の打ち手が見えてきた」と海老原氏は記していた。
海老原氏の報告書の最後にはこう書かれていた。「在庫管理を効率化する、と考えていた。だが本質は、二度数えるムダを流れから消すことだった。LEANでデータの流れを可視化した瞬間に、どこで価値が損なわれているかが見えた。ムダは、減らすのではなく、発生させない設計で断てる」
二つの倉庫が同じ商品を別々に数えていた会社が、在庫を一つの数字で管理する会社に変わった日、在庫管理は二度手間の労働から、なめらかに流れる仕組みに変わっていた、と記されていた。
「業務効率化の相談は、たいてい『作業を速くしたい』として持ち込まれる。だが速くする前に問うべきことがある。その作業は、そもそも必要かだ。LEANが問うのは、流れのどこにムダが潜んでいるかだ。同じ在庫を二度数え、同じ商品を二度登録し、欠品のたびに謝罪する——価値を生まない作業を特定し、流れの設計で発生源ごと断つ。二つの倉庫が同じ商品を別々に数えていた会社が、在庫を一つの数字にできた日、変わったのは在庫管理システムではなく、ムダを減らすのではなく断つという視点そのものだった」
関連ファイル
使用ツール
- ROI Polygraph — 二重管理工数・欠品謝罪対応・販売機会逸失の可視化
- ROI Proposal Generator — 流れの設計による在庫一元化の投資回収シミュレーション
