WMS リプレースで最も危険な瞬間は、本番稼働の朝ではありません。その直前の静かな数時間——データフリーズのウィンドウです。旧システムは幕を閉じつつあり、新システムはまだ信頼されていない。フリーズのポイントを間違えると、出荷ではなく在庫の照合に稼働初週を費やすことになります。
ソフトウェア選定に6か月、導入に4か月を費やしたチームが、フリーズの判断を切り替え直前の週に先送りするのを何度も見てきました。結果はいつも同じです。本番当日に旧システムに残る数百の未完了ウェーブ、新システムで合わない在庫、炎上するカスタマーサービスのキュー。2019 年、フォンタナの 3PL プロジェクトで間近に見ました。一度で十分でした。
フリーズは1本のラインではなく、3つのリスト
多くの人はフリーズを一つの瞬間として思い描きます。旧システムが止まり、新システムが始まる。しかし実際には、フリーズのポイントは3つのリストであり、それぞれが独自のスケジュールで凍結されます。
最初のリストはマスターデータで、これが最も早く凍結されます。品目マスター、ロケーションマスター、顧客・仕入先マスターは、切り替えの2～3週間前にロックすべきです。理屈はシンプルです。データ移行と検証はスナップショットに対して実行されるため、マスターが変わり続ければ、移行スクリプトは完了した瞬間に古くなります。私のルールは、マスターフリーズ後の追加は例外プロセスのみ——紙のフォーム、私のサイン、そしてシステムへ、です。
2番目のリストは取引残高で、前夜に凍結されます。在庫残高のスナップショット、未完了の販売注文、未完了の発注・入荷、在庫調整の保留分、未完了の棚卸タスク——これらすべては、切り替えウィンドウが開く前に「写真に撮られ」ます。写真を撮った後、旧システム内のこれらの伝票はクローズできても、新規作成はできません。
3番目のリストは仕掛かり作業で、これが厄介です。ピッキング済みだが未検品のウェーブ、トレーラーに積まれたがまだ出荷されていない注文、まだ荷下ろしされていないトラックに載った入荷——これらは2つのシステムをまたぎ、一つ一つにオーナーと判断が必要です。私の鉄則は、閉じられるものは閉じることです。新システムに持ち込むのは例外のみで、すべてに切り替えチェックリスト上の名前付きオーナーの承認サインが付きます。
ウィンドウの長さはカレンダーではなく注文量から決める
標準的なフリーズ期間というものはありませんが、計算する方法はあります。1日の注文量、ウェーブのリズム、チームが伝票をクローズする速さから逆算します。
まず切り替えウィンドウを決め、そこからフリーズのアクションを導きます。1日数千件の注文を扱う e コマースの建屋なら、通常は低稼働のウィンドウを丸ごと1つ——例えば土曜 22 時から日曜 6 時まで——確保するよう求めます。ウィンドウが開く4～6時間前に新しいウェーブの作成を止め、仕掛かりのウェーブが自然に終わるのを待ちます。2時間前には入荷を手書きログに切り替えます。ウィンドウが開いたら在庫スナップショットを取得し、旧システムの書き込みアクセスをロックします。
譲れない条件が一つあります。フリーズの前にカウントを実施することです。全面棚卸ではなく、切り替えが触れる高回転ロケーションをすべて循環棚卸します。スナップショット取得後にシステム在庫と実在庫の間に3ポイントの乖離が見つかり、切り替え全体が1週間ずれたプロジェクトを見たことがあります。カウントはフリーズの前提条件であり、オプションの付加要素ではありません。
そしてチームが忘れがちなことが一つあります。フリーズのウィンドウを事前に顧客と運送会社に伝えることです。特に 3PL の場合は、フリーズ中に顧客が緊急注文を入れてきたら、「その時間帯はなぜ止まっているのか」を説明する標準スクリプトが必要です。電話が鳴ってから書いてはいけません。
並行運用は短く——旧システムはミラーであり、パートナーではない
切り替え後に2つのシステムを並行運用すべきかどうかは永遠の議論です。私の立場は明快です。はい、並行する——ただし旧システムは読み取り専用のバックミラーであり、第二のデータ入力口には決してなりません。
ミラーとは、旧システムが2～4週間、照会アクセスを残すということです。カスタマーサービスはそこで注文履歴を調べ、経理はそこで照合し、切り替え前の返品はそこで処理します。ただし新規取引はすべて新システムに入ります。両方のシステムに新しい注文を入力することは、私が見た中で最悪のやり方です——2つのデータセットは3日で乖離し、照合は悪夢になります。
並行期間は2週間に制限し、最長でも1か月です。1か月経っても旧システムなしでは生きていけないなら、新システムの何かが未完成だったということです。答えは並行を無期限に延ばすことではなく、直すことです。期間が終わったら旧システムはアーカイブされます。データベースをバックアップして封印します。
ロールバック計画は紙に書く——そしてリハーサルする
最後に、ロールバックです。多くのプロジェクトのロールバック計画は、全文で「問題が発生したら旧システムに戻す」と書かれています。それは計画がないのと同じです。
使えるロールバック計画には4つのことが明記されます。トリガー（例：コアの出荷フローが2時間以上停止、または主要顧客の注文が完全に出荷不能）、単独の意思決定者（委員会ではなく1人、通常はプロジェクトリード）、ロールバック中に新システムで作られたデータの扱い（ピッキング済み注文、印刷済みラベル——無効化か手動で書き戻し）、そしてロールバック訓練のタイミング（私の要件：切り替え前に少なくとも1回はフルリハーサル、時間計測付きのリストアを含める）。
ロールバック計画について正直に言います。その真の価値は使われることではありません。切り替え日より前にあらゆる「もしも」を考え抜くことを強制する点にあります。真剣に書かれたロールバック計画を持っていたプロジェクトで、私が指揮したものは一度もロールバックしませんでした。持っていなかった2つのプロジェクトは、真夜中に私に電話をかけてきました。
今週切り替え計画を作っているなら、今夜一つだけやってください。未完了注文リストを引っ張り出し、ウェーブのスケジュールと突き合わせ、計画中のフリーズポイントの前後12時間に「宙に浮く」注文が何件あるかを正確に数えることです。その数が切り替え計画全体の土台です。砂の上に建てれば、その上のすべてが危険になります。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
