結論から：WMSの切り替えでは、新旧システムを最低2週間、理想的には4週間並行稼働させる。在庫差異の許容範囲は0.5%——厳守——、受注ステータスの不一致にはゼロ許容とする。同じ3つのレポートを毎日照合する。許容を超えたら新システムのトランザクションを凍結し、旧システムまで遡って原因を追う。このルールひとつがゴーライブを救う。
並行稼働が本当に照合しているもの
並行稼働とは、両方のシステムを稼働させ続けることだ。旧WMSは実際の業務を回し続け、新WMSは同じトランザクションを並行して記録する。二重の仕事に聞こえる。二重の仕事そのものだ。そして切り替え期間中に安心して眠るための唯一の方法でもある。
理由は二つ。
第一に、移行データがどれほどきれいに見えても、初日は必ず現実と衝突する。旧システムには「見えない在庫」が山ほどある。通路に仮置きされたパレット、誰かのスプレッドシートで管理されている返品、出荷したのにクローズされていない受注。新システムは帳簿上の数値を引き継ぐが、帳簿の数値と現場はすぐに乖離する。この失敗を私は3回見てきた。2024年4月、テキサス州ダラスの自動車部品倉庫は並行期間わずか7日で旧システムを停止した。月末棚卸で在庫が約110,000ドル不足していた。根本原因：ロットレベルの差異が照合の対象に入っていなかった。旧システムはロットをゆるく管理し、新システムは厳密に強制した。1週間照合したが、比べる対象が間違っていた。
第二に、作業者は手の再訓練に時間が必要だ。システム変更後の最初の1週間、ピッキングのスループットは通常20–30%落ちる。これは人の問題ではなく、筋肉の記憶の問題だ。並行期間は緩衝材である。新システムへの入力が間違っていても、旧システムが生産をカバーしてくれる。
つまり並行稼働が照合するのは「データ」ではない。具体的な3つのレポートだ。
- 在庫照合：SKU × ロケーション別の手持ち数量を、明細単位で突き合わせる。
- 受注ステータス照合：オープン、引当済み、出荷済み、キャンセル——受注単位で突き合わせる。
- ロケーション占有照合：どのロケーションが何で占有されているかを、スロット単位で突き合わせる。
この3つだけだ。それ以上照合しようとすると終わらない。終わらないことは、照合しないことと同じだ。
5ステップの日次照合
ステップ1：ベースラインを固定する。並行期間の開始前に、実地棚卸を1回行うか、循環棚卸でSKUカバレッジ95%以上を目指す。きれいな起点がなければ、その後の差異はすべて説明不能になる。経営層が飛ばしたがるステップだ——「とにかく始めよう、時間を無駄にするな」。聞いてはいけない。ベースラインなき照合は茶番だ。
ステップ2：照合の対象範囲を文書で確定する。3つの要素を完全に一致させる。毎日のスナップショット時刻を同じにする（たとえば深夜0時——まず旧システムの夜間バッチジョブの実行時刻を確認すること）、ディメンションを同じにする（SKU + ロケーション + ロットの3つすべて——ダラスは1つ抜かした結果だ）、計量単位を同じにする（バラとケース。旧システムでUOMが混在しているのは例外ではなく常態だ）。
ステップ3：3つのレポートを毎日同じ固定時刻に実行する。朝のシフト開始前、前日の締まった業務を対象にする。結果は例外なく当日出す。一晩寝かせた差異は、翌朝には説明不能になる。
ステップ4：差異を3段階にトリアージする。この手法全体で最も重要な表だ。印刷して壁に貼れ。
| 段階 | 定義 | 対応 |
|---|---|---|
| 致命的 | 受注ステータスの不一致、マイナス在庫、出荷や財務に影響するもの | 新システムの関連トランザクションを即座に凍結。4時間以内に根本原因を特定 |
| 許容範囲 | 1明細あたり0.5%以内または1単位の差異で、原因が明確（輸送中、タイミング） | 原因を記録。翌日、解消したことを再確認 |
| ノイズ | 純粋なタイミングの産物。例：旧システムが23:59に帳簿を締める一方、新システムはリアルタイム更新 | 記録して無視。翌日には自然に相殺される |
致命的段階の対応が凍結するのは新システムであり、旧システムではない点に注意。並行稼働中、旧システムが本番システムだ。新システムは影にすぎない。影が間違っていたら、影を止める。
ステップ5：毎日15分のスタンドアップ。質問は3つだけ。今日の致命的差異は何件か、原因は何か、各件の責任者は誰か。スタンドアップを飛ばすと、照合レポートは誰も読まないExcelファイルになる。
次に数字の話。経営層は必ず並行稼働の費用対効果を聞いてくる。15人規模の現場で考えよう。1人1日あたり2時間の二重入力、時給$25、30日間——15 × 2 × 30 × 25 = $22,500だ。次に失敗した切り替えの値段を見よう。ダラスの倉庫の$110,000の在庫評価損は帳簿上の損失にすぎない。本当の請求書は、2か月にわたる残業棚卸、顧客クレーム、緊急のライン停止、そしてシステムを信じなくなった現場チームだった。$22,500とそれを比べる。相手にならない。これはCFOにも通じる算数だ。
期間の目安と旧システム停止のタイミング
先に答えを言う。最低2週間、理想は4週間、6週間を超えたら金を燃やしているのと同じだ。
直感に反するポイントはここだ。長ければ長いほどいい、ではない。6週間を超えると、作業者は「二頭の馬に乗る」ようになる——両方のシステムに入力するが、どちらも丁寧にはやらない——データ品質は改善どころか劣化する。ある倉庫が3か月間並行稼働したのを見たことがある。両方のシステムがゴミだらけになった。3か月の仕事が無駄になった。
旧システム停止の条件——3つすべて必須、例外なし。
- 3つの照合レポートすべてが7日連続で許容範囲内（在庫は0.5%以内、受注ステータスは差異ゼロ）。
- 致命的差異が7日連続でゼロ。ゼロだ。「許容範囲内」ではない。
- 作業者が新システムで1週間完全に自立稼働しており、旧システムはバックアップとして残すだけ——シャドーモードで、スムーズなことが実証済み。
もうひとつ直感に反する兆候。何日も差異ゼロが続く照合は、安心ではなく疑わしい。本物の倉庫には必ず輸送中の在庫やタイミングのずれがある。連日フラットなゼロは、たいてい誰かがレポートを手で均している。3日連続でゼロを見たら、喜ぶ前に照合作業をしている人を監査せよ。
よくある失敗パターンとゴーライブ前夜のチェックリスト
私が見てきた頻度順だ。
第一に、旧システムの定期ジョブの止め忘れ。2023年11月、カリフォルニア州オンタリオの120,000平方フィートのアパレル3PL、18,000SKU、旧システム歴9年。ゴーライブ前夜の午前2時。日中は200行ほどだった差異レポートが、突然1,400行に爆発した。チーム全員が夜明けまで残り、原因を突き止めた。午前1時に動く旧システムのバッチジョブが「引当済み在庫」を再計上していた——新システムにはないロジックだ。二つのシステムが一晩中喧嘩した。この失敗を私は3回見てきた。いつも深夜、いつも定期ジョブだ。並行期間の開始前に、旧システムの定期ジョブをすべて洗い出し、1件ずつ確認せよ。
第二に、同じ言葉の定義が両者で違う。「手持ち」にQA保留エリアは含まれるか。ステージングレーンは。ステップ2で文書にし、双方の署名を取って確定せよ。
第三に、責任者のいない差異。レポートは回るのに、致命的差異が3日間放置され、誰も動かない——照合していないのと同じだ。ステップ5のスタンドアップはまさにこのためにある。
第四に、旧システムの停止が早すぎる。スムーズな並行稼働を見た経営層は、$22,500の人件費を節約したくなる。停止の3条件で線を守れ。3つすべて、でなければ切り替えない。
最後に、ゴーライブ前夜のチェックリスト。すべての項目にチェックが入らなければ、切り替えは行わない。
- 本日の3つの照合レポートがすべて許容範囲内で、致命的差異ゼロ。
- 旧システムの定期ジョブがすべて無効化済み——リストと1件ずつ照合して確認。
- ロールバックの準備完了。旧DBのフルバックアップ完了、切り替えスイッチの実機テスト済み。
- キーユーザー（入荷、ピッキング、出荷のリーダー）が新システムで1週間完全に自立稼働済み。
- 導入コンサルタントとITの電話は翌日の正午まで電源オン。笑いたければ笑え——ゴーライブの夜に電源を切った現場を知っている。
並行稼働は技術の問題ではない。規律の問題だ。対象範囲、許容値、スタンドアップ、チェックリスト——この4つを押さえれば、切り替え災害の確率はほぼゼロになる。飛ばすなら、切り替え自体をやめよ。
Lin Xiao（WMS導入コンサルタント）著
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
