WMS の go-live について誰も教えてくれないことがあります。問題はソフトウェアではありません。問題は最初の1週間です。
システムがあらゆるテストに合格し、すべてのインターフェースが緑で返ってきて、カットオーバープランが40ページもある go-live を、私は見てきました。それでも初日の午前9時には現場が火事でした。新しいプロセス、新しいロケーションコード、新しいデバイスが同じ朝に一斉に着陸し、相手にするのは3週間前の2時間のトレーニングで新しいフローを学んだ人たち。ウォールームは、その混乱と出荷カットオフの未達の間に立ちはだかる唯一のものです。しかし私が見てきたウォールームの多くは、電話に応対する数人が座っているだけでした。火事は結局燃え続けます。最初の1週間が実際どうなるかを、誰も事前に決めていなかったからです。
あなたが戦うことになる3つの火事、確実に
1つ目の火事はマスタデータです。スキャンできないバーコード、一致しないロケーションコード、間違った単位換算。2023年、私はカリフォルニア州オンタリオの120,000平方フィートの3PL倉庫の go-live を支援しました。期限に間に合わせるため、チームは200以上の低回転SKUのバーコード登録を「go-liveの後」に先送りしました。1週目の毎朝、スキャンすべきバーコードがないために十数件のウェーブ注文が監査ステーションで詰まり、監査担当者はカートンを手で探し回らなければなりませんでした。技術的な難しさはゼロ、不完全な準備作業が原因——それでいてその週で最も精神を削る火事でした。それがあなたを殺すことはありません。ただ毎日燃え続けるのです。
2つ目の火事はインターフェースです。WMSからOMSへ、運送業者へ、EDIへ——1週目には必ず何かが不調になります。注文が降りてこない、ステータス更新が失われる、ウェーブリリースが途中で死ぬ。厄介なのは、現場にはこの手の問題が見えないことです。ピッカーが知っているのは「ピックする注文がない」だけ。ウォールームがインターフェースキューを監視していなければ、滞留が数千件になった2時間後に初めて気づくことになります。そして肝心なのは——多くの場合、WMSのせいではまったくないということです。相手側がフィールドを1つ変えて、連絡するのを忘れたのです。だからウォールームには、ログを読めて、相手側のエンジニアに1回の電話でつなげる人間が必要です。
3つ目の火事は人です。新しいフローは違和感があるので、作業者は静かにシステムを迂回します。まず紙でピックして、後で入力する。手書きの方が速いからRF端末をスキップする。こうしたシャドウプロセスを1週目に潰さなければ、二度と潰せません。データが一度汚れたら、在庫精度は二度と回復しません。go-liveから3か月経っても在庫の照合を続けているプロジェクトのうち、9割が1週目に問題を埋めていました。私のウォールームのルール：最初にシステムを迂回した時は、その日のうちに話をする。2回目は、倉庫マネージャー直送です。厳しいように聞こえます。これがデータを守る唯一の方法です。
ウォールームは、どこにあるかより誰がいるかが重要です
最もうまくいく構成は、3つの側から1〜2人ずつです。オペレーションからは倉庫スーパーバイザー——プロセスを理解し、「この注文は手動で出荷できる」と判断できる人。ITからはインターフェースとインフラの担当——ログを読めて、チケットを切らずにサービスを再起動できる人。導入ベンダーからは設定を知っているコンサルタント——その場で間違ったパラメータを直せる人。3者とも必須です。オペレーションがいなければ、問題をトリアージできません。ITがいなければ、インターフェースの問題に呆然とされるだけです。導入ベンダーがいなければ、1つの設定項目で半日足止めされます。
シフトは3交代ではなく2交代で回します。早番がウェーブリリースから夕方のピークまでをカバーし、遅番が夜間のクローズをカバーして、引継ぎのために2時間オーバーラップします。シフト表はgo-liveの3日前に確定し、印刷して壁に貼ります。休みを取りたい人は、自分で交代要員を探します。「電話サポート」はカウントしません。1週目では、部屋にいる人と電話の向こうの人は、火力としてまったく別のレベルです。
最も重要なのは、意思決定者を1人指名すること。通常はビジネス側のプロジェクトマネージャーです。ウォールームの最も致命的な病気は、3人いて決断がゼロの状態です。P1が来たら、意思決定者は一言だけ言います——ラインを止めて直すか、迂回して出荷を守るか。その人は出荷を止める権限と、「2時間は手動でいく」と言う権限を持っていなければなりません。権限が曖昧なウォールームは、明確な意思決定者が一言で解決することを2時間かけて議論します。
ダッシュボードの数字は6つ。それ以上は不要。
1週目のダッシュボードは絞ります。私が見る数字は6つです。未リリース注文の滞留、ウェーブリリース成功率、稼働中のRF端末数、インターフェースキューの深さと最長待ち時間、監査例外率、当日出荷予定遵守率。それぞれにレッドラインを引く——例えば、15分間動きのない200件超のインターフェースキューは、報告不要で自動的にP1に昇格します。3者はgo-live前にレッドラインに合意し、紙に書いて壁に貼り、その週は一切触りません。毎日変わるレッドラインは、レッドラインではありません。
P1/P2/P3の重要度レベルは初日から存在し、定義はシンプルで具体的にしなければなりません。P1：出荷できない、またはデータが汚れる。P2：スループットが半分以下に落ちるが、出荷はできる。P3：出荷に影響しない使い勝手の問題。重要度が明確でないウォールームでは、すべてが「なんとなく緊急」になり、何も優先順位づけされません。もう1つの鉄則：P1を発見してから誰かがオーナーになるまで、15分以内。タイムアウトしたら、意思決定者の電話が直接鳴ります。
ロールバックプランは恥ではありません。保険です。
go-liveの前に、2つのものを用意しなければなりません。1つ目は、紙のバックアップ注文書と手動プロセスです。システムが本当にダウンしても、倉庫は止まりません。紙でピックし、手で記録し、後で入力する。フォームは事前に印刷して現場に置いておく——壊れた状態でプリンターを探し回らない。手動フローは少なくとも1回リハーサルする。シフトリーダーは紙のプロセス全体を自分の手で歩むべきです。でないと、悪い日に、手にした紙の使い方すら分からなくなります。
2つ目は、データの復旧ポイントです。毎晩のフルバックアップに加えて、重要なマスタデータ変更の前に個別のバックアップ。ロールバックとは、システムをアンインストールすることではありません——「今日の設定変更が何かを壊したので、昨夜の状態に戻せる」ということです。正直に言えば、1週目に実際にロールバックプランを使うプロジェクトは少ないです。でも、あるかないかでチームの心理は完全に変わります。計画のあるチームは設定に触ります。計画のないチームはパラメータ1つ変えず、P2の問題をP1になるまで引きずります。
つまり：go-live週の前に、P1/P2/P3の定義とエスカレーションの電話リストを印刷してウォールームの壁に貼り、その横に紙のバックアップフォームの束を置きます。1週目の最終日には、3つの質問で振り返りをします。どの火事が一番熱かったか、どの指標が最初にアラームを出したか、どの手動の回避策を恒久的なシステムプロセスにすべきか。そしてウォールームを解散します——開き続けているということは、まだシステムを信頼していないということです。
最後に1つ質問です。初日の朝、旧システムを自分の手で止めなければならないとしたら——あなたはできますか。できないなら、あなたのロールバックプランは未完成です。今直してください。まだ時間はあります。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
