倉庫ピッキング用ビン・トートロボット：棚を動かすより箱を動かす方が勝つとき

結論から先に言う。ビン・トートロボットによる倉庫ピッキングは、注文ラインが多く、商品が小さく、SKUが数千ある倉庫に適している。一方、数ラインで大きく重い商品を出荷する倉庫には適さない。この判断を誤ると、レイアウトからROI計算まで、その後の判断がすべて一緒に誤る。私はこの問題で正反対の方向に進んだ倉庫を2つ見てきた。一方はピッキング要員をおよそ半分に減らし、もう一方は3か月でロボットを止めて手作業ピッキングに戻った。設備が違ったのではない。注文プロファイルが違ったのだ。

ビン・トートロボットのピッキングが節約するのは歩行であり、ピッキングそのものではない

手作業ピッキングでは、歩行が税金である。棚移動ロボットは棚全体をピッカーの元へ運ぶ。ビン方式はトートを1つだけ運ぶ。デモ動画を見ればどちらも優雅に見える。実際の注文プロファイルに当てはめれば、違いはすぐに現れる。

2023年の秋、寧波にある家電アクセサリーの倉庫から選択肢の評価を依頼された。その倉庫は1万SKUをはるかに超え、典型的な注文は3〜5ライン、1ラインあたり1〜2個だった。システムの記録によれば、ピッカーは1日あたり10キロメートル級の距離を歩いていた。棚移動型の設計には具体的な欠陥があった。1つの注文の5ラインが3つの異なる棚に分散している場合があり、棚全体を動かすことは注文ごとに大量の無関係な商品を運ぶことになるからだ。ビン方式は実際に注文された商品の入ったトートだけを動かすため、作業量は棚の中身ではなく注文ラインに比例し、ミスも棚全体ではなく1つのトートの中に収まった。

東莞の小型家電部品倉庫はその鏡像だった。注文あたりのライン数は少なく、1ラインあたりの数量は多い。1つの注文に同じ商品が数十個入ることも珍しくなかった。トートを行ったり来たりさせても何の節約にもならなかった。ピッカーはトートの到着を次々と待つばかりで、稼働率はビジネスケースの想定に届かなかった。私はビン方式を買わず、そのお金をプットウォールと検証に使うよう助言した。彼らは当初反対したが、2週間のトライアルを行い、自ら提案を却下した。私はこのまったく同じ間違いをこれまで3回見てきたが、原因はいつも同じだった。判断が注文ライン分布ではなくデモに基づいて下されていたのだ。

選別方法は単純で、シミュレーションソフトは不要である。1か月分の注文を取り、注文あたりのライン数で分類する。単一ライン、2〜5、5〜10、10超である。次にラインあたりの平均数量を見る。ラインあたりの数量が少ない2〜10ラインの注文の割合が高いほど、導入の根拠は強い。単一ラインのバルク注文の割合が高いほど、根拠は弱くなる。この区分表がビジネスケースの最初の証拠である。これなしにベンダーの話をしてはいけない。

ここが直感に反する点である。このシステムはピッキング動作そのものを速くするわけではない。ステーションに立つピッカーの動きは同じ速さのままである。スループットが上がるのは、待ち時間、歩行、正しいビンを探す時間が機械の時間に吸収されるからだ。裏返せば罠が見える。真のボトルネックが下流、すなわち検証、梱包、ラベリングにある場合、ピッキング面が速くなっても総出荷量は変わらない。まずボトルネックを測り、次にお金の行き先を決める。この順序は譲れない。

稼働前チェックリスト：スイッチを入れる前の12項目

ビン・トートロボットによる倉庫ピッキングを評価するチームは通常まず速度を聞くが、以下の失敗は速度ではなく例外処理に関するものである。ビンのプロジェクトが失敗するのは、めったにロボットのせいではない。WMS連携、トート管理、フロアレイアウトで失敗する。これが私が稼働前夜に毎回確認するリストであり、未チェックの項目がある状態でスイッチを入れることはしない。

トートとハードウェア。第一に、トートのサイズは最大の商品に緩衝材を加えた大きさで決め、ラベルとクリーンなスキャン角度の余地を残すこと。第二に、空トートの返却ルートをフロアプランに描くこと。ピックステーションの脇に空きトートが山積みになるのは、私が見る中で最も多いフロアの失敗である。第三に、すべてのトートIDをWMSのコンテナレコードに一対一で対応させること。そうすればスキャンがそのトートの商品詳細に直接着地する。

システムとデータ。第四に、WMSが波（ウェーブ）を解放したら、ロボットのタスクは最寄りのトートの都合ではなく波の優先順位に従うこと。第五に、在庫切れ、棚卸ロック、破損の各トートにはそれぞれ保留状態が必要であり、保留されたタスクが後ろのキューを塞いではならない。第六に、ネットワーク切断と再接続の後、タスクの状態は誰かが1つずつ確認しなくても自動的に再開すること。第七に、ERPへ戻すピック確定メッセージには数量、ロット、シリアルの各フィールドが欠けなく含まれていること。

人とフロア。第八に、ステーションの高さ、照明、スキャン角度は実際の身長の実際のスタッフでテストすること。デモで快適なのと8時間快適なのとは同じではない。第九に、充電ゾーンとメンテナンスゾーンは立入禁止として区画し、充電待ちの列がメイン通路を塞がないようにすること。第十に、新入社員は研修で動画を見るだけでなく、実際の注文でフルシフトをこなすこと。第十一に、例外対応の責任者をシフトごとに指名し、夜間も含めて電話番号を壁に掲示すること。第十二に、停電、ネットワーク断、システムアップグレードはそれぞれ1回ずつリハーサル済みであること。一度もリハーサルされていない計画は計画ではない。

2024年の春、蘇州の生活用品倉庫が稼働前夜に項目6にぶつかった。切断・再接続テストで、すでに回収済みのトートのタスクが十数件、状態を失った。ロボットは止まったまま、WMSはタスクを完了と表示していた。ベンダーは状態遷移の修正に現地で2日を要した。もしあの夜にスイッチを入れていたら、朝のシフトはシステムがピック済みと思い込んでいる注文のトートが届く事態に直面していた。チェックリストとはそういうものだ。稼働日の混乱を、まだ修正できる前夜へ移すためのものなのだ。

ビン・トートロボットのピッキングが失敗する場面

最初の失敗はトートの混同である。複数の注文のトートが1つのステーションで交互に現れると、ピッカーは記憶に頼って作業し、誤ピックが増える。解決策は意図的に退屈なものだ。ステーションに置く保留中のトートは常に1つだけ、画面にはそのトートの注文ラインだけを表示し、スキャン検証はピックの前ではなく後に行う。記憶を信じてはいけない。1人に1つの仕事だけを与えれば、間違えることはない。

2つ目の失敗は、波を大きく切りすぎることである。波を大きくすればロボットの稼働が上がると考えられがちだが、波が大きいと、詰まったトート1つが波全体の確定を遅らせ、梱包は波全体が揃うまで開始できない。私のルールは、波を小さく切り、ステーション数に合わせてサイズを決め、例外トートをメインキューから外に置くことで、1つのトートが後ろのすべてを止められないようにすることだ。

3つ目の失敗は、設備の予算だけを組み、改造を忘れることである。床の水平出し、棚の間隔、充電器の容量、WMSインターフェース作業、スタッフ研修。これらを合わせると、設備の見積もりに routinely 大きな上乗せが加わる。設備価格と理想的なスループット数値だけを示すビジネスケースのROIは架空のものだ。改造の各項目をすべて列挙し、スループットをトライアルの実測値まで割り引けば、経営層に持ち込む数字は現実との接触に耐える。

最後に率直な一言。ビン・トートロボットによる倉庫ピッキングは、倉庫近代化の既定の答えではない。特定の注文プロファイルに対する特定の答えである。ラインが多く、商品が小さく、SKUが多いなら、真剣な評価に値する。ラインが少なく、商品が大きく、プロファイルが日々変わるなら、まず手作業プロセスと波管理を直し、設備は後で再検討することだ。この判断を正しく下せば、プロジェクトは半分できたも同然である。

Lin Xiao（WMS導入コンサルタント）著

英語版からの翻訳。内容に相違がある場合は英語版を優先します。