同じ1日8,000件の注文。2つの倉庫。まったく違う2つの現場。
倉庫Aはカリフォルニア州インランド・エンパイアにある。昨年、WESを連続フロー方式のリリースに切り替えた。午後2時にピック現場を歩いたが、不気味なほど静かだった。作業員はカートを押しながら通路を進み、待機することなくピッキングしていた。梱包ステーション前のコンベヤは一定のペースで流れていた。滞留は何もない。走り回る人もいない。同じエリアにあり、同程度の物量の倉庫Bは、今も昔ながらのウェーブ方式で運用している。毎日、キャリアのカットオフの1時間前になると、定刻通りに現場が爆発する——通路の端に立って次のウェーブの投入を待つ作業員、梱包エリアに小山のように積み上がるカートン、無線を片手に消火活動に走り回るスーパーバイザー。
違いは人ではない。リリースのロジックだ。Aでは注文が流れ出す。Bでは一気に投げ出される。
連続フロー方式のリリースとは実際何か
倉庫で働いたことがある人なら、ウェーブ方式の手順を知っている。注文はプールに溜まり、キャリアのカットオフとシフトごとにウェーブに切り分けられ、時刻になるとウェーブ全体が一気に投入される——ピック、検品、梱包をフルスロットルで。1つのウェーブが終わり、次のウェーブが始まる。利点は予測可能性だ。スーパーバイザーは常に先が読める。欠点も同様にはっきりしている。完了した注文が各ウェーブの終わりに集中し、梱包ステーションがパンクし、作業員はウェーブの始めに手持ち無沙汰になる。現場は飽食と飢饉の間を揺れ動く。
ウェーブレスはこのロジックをひっくり返す。ウェーブを組む代わりに、WESは注文プールを継続的に監視する。この注文の優先度は十分に高いか。カットオフは迫っているか。在庫はあるか。労働力のキャパシティはあるか。条件が揃った瞬間、注文はリリースされる。リリースはプルモデルになる——下流のキャパシティが空いた瞬間に仕事がフローに引き込まれる。フルウェーブを組み上げて押し流すのを待たなくなるのだ。
ここでの鍵となる概念はローテーション・バッチだ。WESは常に「進行中タスク」の生きたセットを保持する。1つの注文が完了すれば、プールからすぐ別の注文が引き込まれてそれを置き換える。バッチは回り続けるが、「ウェーブ全体を投入、ウェーブ全体を締める」という瞬間は決してない。完了した注文は、ウェーブの終わりに集中するのではなく、定常的な流れとして出てくる。
これは新しい発想ではない。Manhattan AssociatesはWMSとWESの中でこの機能をOrder Streamingと呼んでいる。WESベンダーのVargoはこれを連続フローシステムと呼び、米国のアパレル小売大手数社の配送センターに導入してきた——Modern Materials Handlingが取り上げた事例だ。名前は違えど中身は同じ。スケジュールされたウェーブ投入をリアルタイムのオーケストレーションに置き換えることだ。
だが名前には騙されてはいけない。「ウェーブレス」は「計画なし」を意味しない。むしろ計画がより必要になる。ただ計画が「人がスケジュールでやる」から「システムがリアルタイムでやる」に移るだけだ。ウェーブレスなら計画をやめられると期待した者は、現場から痛い教育を受けるだろう。
連続フローのための3つの前提条件
注文の流れは安定していなければならない。連続フローの最大の敵は、干上がった注文プールだ。プールにリリース可能な注文がなければ、作業員は結局手持ち無沙汰になる。従来のウェーブは少なくとも注文を溜めることで仕事を保証するが、ウェーブレスではシステムがリリースできるのは条件を満たした注文だけだ——優先度、在庫、カットオフのすべてが揃わなければならない。だから注文のプロファイルは比較的安定している必要がある。1日の物量、1注文あたりの明細行数、SKUの分布が激しく変動してはならない。小口宅配のeコマース事業者にはここで天性の強みがある——物量が多く、注文が細分化され、SKUが集中している。プールは決して干上がらない。だが、ある日は爆発的に増え、翌日は静まり、その翌日は大型商品に襲われるような拠点では、プールは1日おきに干上がり、連続フローは苛立ちの訓練と化す。
リソースは柔軟でなければならない。連続フローではタスクがリアルタイムで引き込まれるため、ピッキングのリソースはタスクについていかなければならない。ゾーンをまたいで応援できる人、決してボトルネックにならない設備だ。殺し屋は硬直した労働力——変更のきかないシフト、自分通路しか知らない作業員、必要なときに見つからない臨時工だ。タスクがゾーンに流れてきたのに誰もいないと、流れ全体が詰まる。連続フロー方式のソフトウェアを動かしながら労働力スケジュールはウェーブ時代のまま、という拠点を見たことがある。毎午後、現場は定刻通りに30分間「干上がった」。ウェーブ時代よりひどかった。システムと人が同じテンポで動かなければならない。
システムは本当にリアルタイムでなければならない。これがWESとWMSの分水嶺だ。WMSも注文をリリースできるが、スケジュール制だ——毎時00分にルールを実行してウェーブを投入する。連続フローのWESは常時評価し、いつでもリリースし、生きた労働力と設備の状態に対して再優先付けする。注文、在庫、労働力、設備の状態を1つのオーケストレーション平面に載せる必要がある。連続フローで動いていると主張しながら、実際には新しい名前をつけたWMS式のスケジュールリリースを回している倉庫を、私はたくさん見てきた。新しいラベル、同じ投げ出しだ。
3つのうち1つでも欠ければ、連続フローは滑らかから破壊工作に変わる。私の結論は率直だ。3つのうち、システムは買うのがいちばん簡単で、次に注文の安定性、労働力の修正がいちばん難しい。労働力が硬直しているなら、そもそも話を始めてはいけない。
導入すべきは誰か — 避けるべきは誰か
向いているのは誰か。高頻度で注文プロファイルが安定した、小口商品のeコマース事業者は、連続フローの生まれ故郷だ。プールが決して干上がらないだけの物量、集中したSKU、ゾーンをまたいで働くことに慣れた作業員だ。こうした拠点では、カットオフ前の混乱がほぼ消え、梱包ステーションの負荷が平準化され、残業が縮む。プロモーション期間中の「安定した」日々も該当する——キーワードは「安定」であって、ピーク当日ではないことに注意だ。
避けるべきは誰か。第1に、激しい山と谷がある倉庫だ。通常日は数千件なのに、プロモの大爆発ではその数倍、注文ミックスもまったく違う。彼らの問題はリリースのロジックではなく、純粋なキャパシティだ。連続フローでは直せない。極端な負荷の下ではスケジューラが限界まで追い込まれるだけ——タスクのリリースは問題ないのに、人がついていけず、欠勤とピックミスが同時に急増し、現場はさらに醜くなる。第2に、極端なロングテールSKUの事業者だ。プールは都合のよいタスクのまとまりを決して生み出さず、システムは仕事をちょろちょろとリリースし、作業員の移動距離は膨らむ。ウェーブを溜めてルートで最適化するほうが賢い。第3に、硬直した労働力だ。固定シフト、ゾーン間応援なし、ピーク時の臨時工の質が不安定。連続フローはウェーブよりもはるかに労働力の柔軟性を要求する。人が柔軟に動けないと、システムが賢いほど現場はひどく見える。
ウェーブから一気に切り替えてはいけない。健全な移行はゾーン単位のパイロットだ。1つのピックゾーン、または1つの注文タイプ——たとえば標準の小口商品注文のみ——を移し、2〜3週間運用して、3つの指標を監視する。フローが干上がる頻度、カットオフ達成率、労働力の稼働率だ。そしてWESにはウェーブモードのスイッチを残しておく。それがロールバック計画だ。ロールバックのトリガーは事前に文書で定義する。プロモ中の注文量が日次ノルムの2倍を超える場合、または許容閾値を超えてゾーンが干上がる場合——シフトマネージャーは承認なしで1つのスイッチでウェーブに戻す権限を持つ。そのスイッチこそ、パイロットに挑む勇気をくれる。
これら3つに照らして判断せよ。
連続フローを検討しているなら、ベンダーの見積もりから始めるな。3つの質問から始めろ。注文プールに、リリース可能な注文がゼロになる時間帯はあるか。人はタスクを追ってゾーンをまたげるか。WESは本当にリアルタイムのオーケストレーションか、それとも新しい名前をつけたWMS式のスケジュールリリースか。
3つともイエス——ゾーンをパイロットせよ。1つノー——まずそのギャップを潰せ。注文プロファイル、労働力の柔軟性、システムだ。潰してから話そう。2つノー——この考えは捨てろ。ウェーブを上手に回すことに恥はない。
リリースのロジックは優劣の問題ではない。適合の問題だ。連続フローは良い道具だが、間違った場所の良い道具は起きるべくして起きる事故だ。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
