WESにおける動的ウェーブサイズ設計：波を現場の人員に合わせる

結論を先に言います。波（ウェーブ）サイズは固定値であるべきではありません。現場に何人いるか、その人数分だけオーダーをリリースする。私は長年これを考え続けてきましたが、今ではますます確信しています。

2019年、私はフォンタナにあるECフルフィルメントセンターにいました。120,000平方フィート、1日約18,000オーダー。彼らのWESではウェーブが固定でプログラムされていました。1波400オーダー、45分ごとにリリース、年間を通して変更なし。第一シフトには60人以上のピッカーがいて、波を20分で消化し、残りの25分は通路をうろうろし、おしゃべりし、次の波をシステムが落としてくれるのを待っていました。第二シフトは28人。1つの波に2時間半かかり、キャリアの締め切り前にオーダーが山積みになり、スーパーバイザーは手作業で波を分割し、カスタマーサービスの電話は鳴りっぱなしでした。私は彼らのオペレーション責任者と数字を計算しました。第一シフトは「波待ち」でピッキング生産性の20%近くを失っていたのです。人が遅いのではありません。システムが人を遊ばせていたのです。

端的に言えば、固定ウェーブサイズとは、今日のクルーを昨日の計画で回すことです。ミスマッチは保証されます。どの倉庫も見たことがあるでしょう。オーダーが最も少ないときに現場の人員が最も多く、オーダーがピークのときに人員が最も少ない。

解決策は、気持ちとしては4語にまとめられます。動的ウェーブサイズ設計。WESは固定ウェーブのリリースをやめ、リアルタイムの現場人員数から各波を計算します。私がクライアントに通常設定するのは3段階です。数字は拠点ごとに調整しますが、ロジックは同じです。

設定ロジックは単純です。15分ごとにWESがタイムクロックまたはハンディ端末のログインシステムから現在の現場人員数を読み取り、移動平均を取って、人数が段階を下回れば波を自動で縮小し、上回れば拡大します。キャリアの締め切り1時間前には小波のみに固定し、すべてを当日中にクリアして翌日に持ち越さないようにします。

その波サイズは勘ではありません。人員数から導出されます。平均ピック率が1人1時間あたり120ユニット、現場に30人のピッカーがいるとします。1時間あたり3,600ユニットです。1オーダー3ユニットの600オーダー波なら1,800ユニットで、30分でクリアできます。つまり30分のリリース間隔でリズムがぴったり合います。15人に減ると、同じ600オーダーの波に丸1時間かかり、締め切りが突然危うくなります。式はこうです。波サイズ ≈ 現場ピッカー数 × 1時間あたりのユニット数 × リリース間隔 ÷ 1オーダーあたりのユニット数。人員数が動けば、波サイズもそれに追従します。

2022年のピークシーズンには、アパレルの3PLで動的ウェーブの裏側を見ました。機能はオンになっていたのですが、ITが「理想の人員数」に対して設定していたのです。システムは現場に45人いると表示して45人分の波サイズを決めていたのに、実際にいたのは36人だけ。9人は打刻して喫煙所にいたままでした。波は大きすぎ、第二シフトは3日連続でクリアできず、翌朝の第一波はまだ前日の残りをこなしている状態でした。私は彼らのスーパーバイザーに言いました。動的サイジングの入力が汚れていれば、出力が間違うのは保証されます。まず実際に現場に誰がいるかを検証する。リアルなピック実績のあるハンディのログイン数を数えて、それから動的化の話をしてください。

初回設定でほとんどの人が見落とす設定上の注意点が2つあります。1つ目はフォールバックです。WESが人員データをまったく読めなくなったらどうするか？ネットワークの一時断やタイムクロックのメンテナンスは起こります。正しい対応はフォールバックルールです。リアルタイムの人員数が取れない場合は、停止するのではなく、前のシフトの同じ時間帯の人員数を自動的に再利用する。これを省いた現場を見たことがあります。タイムクロックのサーバー再起動で波のリリースが40分間凍結され、数十人のピッカーが立ち尽くしていました。2つ目は、サンプリング窓をどれくらいにするか。15分サンプリング＋30分移動平均が私のいつもの出発点です。短すぎると波が激しく振れてしまいます。ピッカーがようやく慣れたころにまた変わって、リズムは台無しです。長すぎると、昼食後の20人から45人への急増が30分間気づかれず、その間にオーダーが山積みになります。万能の答えはありません。2週間回して、データを見て、それから調整してください。

ここでコインの裏側です。どんな解決策にも代償があるからです。1つ目、派遣作業員は正社員ではありません。ピークシーズンには派遣は通常、ベテランの約60%のペースでしかピックできません。つまり人員数に割引をかけなければ、波は依然として大きすぎます。2つ目、小さいことが常に良いとは限りません。WESが波を構築し、タスクを割り当て、ラベルを印刷するオーバーヘッドは固定です。波を約50オーダー以下に切ると、システムのスケジューリング時間がピッキング自体より大きな割合を食い始めます。ピッカーは貨物を待つよりシステムを待つ時間が長くなる。底はあるのです。小ささを追いかけないでください。3つ目、閑散時間の小波は素晴らしく聞こえますが、梱包ステーションと監査台が同じリズムを保てなければ、上流で気持ちよくリリースして下流で全部詰まらせます。

動的ウェーブの機能にお金を払いながら、スーパーバイザーが勘で波をリリースし続ける倉庫を、私はたくさん見てきました。システムが200オーダーと計算しても、「今日は人手が足りない気がする」と350に上げてしまう。それは機能がないのと同じです。動的ウェーブの最大のコストはソフトウェアではありません。スーパーバイザーにダッシュボードを見させ、データを信じさせることです。データが現場に22人いると言うなら、それを受け入れてください。「30人くらいいる気がする」には従わないでください。

直感に反する部分はこちらです。オーダーを溜めずに閑散時間に小波をリリースするのはやりすぎに見えますが、実際には一人あたりの生産性が上がります。ピッカーが最も恐れるのは忙しさではなく、手持ち無沙汰です。リズムが一度崩れると、温まり直すのに20分かかります。全員の手に仕事を絶やさないことが、スループットの本当の秘訣です。

さて、あなたのWESでは、波は生きていますか、死んでいますか？死んでいるなら、システムの置き換えを急がないでください。まずスーパーバイザーに1つ質問してください。最後の波をリリースしたとき、実際に現場に立っていたのは何人でしたか？

Lao Mi（サプライチェーンのベテラン、20年）著

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