WMSとERPが合わないとき：インターフェース障害、在庫の差異、そして数字の責任者は誰か

まず結論から言うと、WMSとERPの在庫が合わないとき、その原因は通常、システムが計算を間違えたことではない。2つのシステムが同じものを違うように定義していることだ。壊れたインターフェースは最も目立つ種類の失敗にすぎない。もっと多いのは、ロット、単位、ステータスのマッピングがずれているケースで、現物在庫がまったく動いていないのに、帳簿が1件分だけ食い違ってしまう。倉庫のWMS・ERP連携の仕事では、トリアージに厳密な順序がある。まずインターフェースが流れているかを確認し、次にマッピングが正しいかを確認し、それから初めて差異の責任が誰にあるかを話すのだ。この順序を逆にすると、間違った場所の修正に1か月を費やすことになりかねない。

私はこの落とし穴を3回見てきた。最も最近の事例は、稼働開始から3週目のある消費財メーカーだった。経理は、ERPでは紙製品が2千単位以上不足していると言った。倉庫は現物在庫はすべてあると言い、循環棚卸も倉庫の言い分を裏付けた。双方とも相手が間違っていると確信し、プロジェクトチームはインターフェースを一から作り直す寸前だった。本当の原因はほとんど恥ずかしいほど単純だった。ERPはケース単位で在庫を管理し、WMSはピース単位で管理しており、インターフェースが送ったケース数量を、受信側がピースとして計上していたのだ。1ケース24ピースなら、1件の注文で23単位の差異が生まれる。何も壊れてはいなかった。単位マッピング表に1行欠けていただけだった。

WMS・ERP連携におけるインターフェース障害：4種類を順に

インターフェースが失敗したとき、まずサービスを再起動してはいけない。再起動で直るのは一時的な中断だけだ。設定の誤りは直らない。私はインターフェース障害を4種類に分け、1つずつ切り分けていく。第一に、メッセージがそもそも出発していない。WMS内の保留キューに送信文書が滞留している場合で、多くの場合そのステータスが間違っている。たとえば未承認の注文は、インターフェースが決して拾い上げない。第二に、出発したが到着していない。ミドルウェアのキューが詰まっているか、証明書の期限が切れており、キューの深さとエラーログを見れば明らかだ。第三に、到着したが却下された。項目の欠落や、相手システムのマスタデータに存在しないコードがあると、メッセージは跳ね返される。第四に、最も危険なのが、到着して計上されたが、誤って計上されたケースだ。たとえば単位換算の誤りや倉庫コードの不一致で、帳簿は静かにずれていき、問題は数日後に爆発する。

稼働開始の夜のチェックリストには、私は必ず3項目を入れる。インターフェースキューの滞留に対するアラート、失敗文書のための再試行ボタンと再試行履歴、そして相手側に却下された文書の日次クリーンアップ担当者だ。この3つがないインターフェースは、丸裸で稼働しているようなものだ。かつて、毎晩同じ時刻にインターフェースが壊れるクライアントがいた。原因は、定期送信が相手システムの夜間メンテナンス時間帯と衝突していたことだった。送信時間帯を移すことで解決した。コードを疑う前に、タイミングとログを確認すること。

WMS・ERP連携のマッピング表：ロット、単位、ステータス

インターフェースが流れても帳簿がまだ合わない場合は、3つのマッピング表を確認する。第一は単位マッピングだ。ケース、パレット、ピース、内装、どのシステムが基本単位を持つのか、換算はどこにあるのか、例外となる製品カテゴリはあるのか。第二はロットマッピングだ。ERPのロット番号はWMSのロット番号と同じものか。ERPでは製造日をロットとして使い、WMSでは入荷ロット番号を使う企業もあり、両者は似ているのに一致しない。第三はステータスマッピングだ。検査待ち、輸送中、凍結、破損といったWMSの在庫ステータスはそれぞれERPで何に対応するのか、破損在庫は利用可能として数えるのか、凍結在庫は帳簿に残るのか。

私が見た最も典型的な失敗は、「検査待ち」ステータスの欠落だった。品質検査待ちの商品がWMSでは保留ステータスにあったのに、ERPでは利用可能在庫として数えていたため、営業はその数字に対して受注し、結局出荷できなかった。修正は複雑ではなかった。ステータスマッピング表を印刷し、両側の業務責任者に1行ずつ署名してもらい、保留、凍結、破損の在庫をそれぞれ別の区分に入れ、営業には利用可能ステータスだけを見せるようにしたのだ。口頭の合意ではなく、稼働開始前に表に署名してもらうこと。

差異調整には、問題が起きるたびにデータを新たに引っ張ってくるのではなく、固定の差異表が1つ必要だ。その表には少なくとも4列が必要だ。製品、WMS数量、ERP数量、差異理由だ。理由列に許される値は5つだけ。インターフェース未着、単位換算、ステータスマッピング、ロット差異、現物差異だ。「その他」と記された行は再調査に戻される。その表を1か月回すと、差異理由が大きく偏っていることが分かる。通常は1つか2つのカテゴリが繰り返される。その規律こそが、倉庫のWMS・ERP連携の差異調整を長期にわたって成立させるものだ。その1か所か2か所を直せば、差異の合計は急激に下がる。

数字の責任者は誰か：議論の前にルールを決める

帳簿が合わないとき、最もコストがかかるのはたいてい数字の修正ではない。双方が互いを非難し合うことだ。倉庫はシステムが誤って送ったと言い、ITは業務が誤って入力したと言い、経理はどちらも信用できないと言う。だから責任は、問題が現れる前に決めておかなければならず、事後の議論ではなく、稼働開始文書に書き込んでおくのだ。

私たちが使う分け方はシンプルだ。インターフェースの伝送問題はITの責任で、伝送ログで判断する。ログに送信済みとあり、相手側が受信していなければ、中間層の責任だ。マッピングルールの問題はプロジェクトチームの責任で、署名済みのマッピング表で判断する。表に書かれていることが、数え方だ。現物の問題は倉庫の責任で、棚卸結果で判断する。棚卸とWMSが合わなければ、まず現物在庫を確認する。データ入力の問題は、文書を入力した者の責任で、元の文書の値で判断し、変更には必ず痕跡を残す。ルールができれば、差異はまず分類され、責任者に振り分けられ、誰のせいかを決めるのに会議の半分を費やすことはなくなる。

ここで直感に反する判断がある。差異が小さいほど、真剣に受け止めるべきだということだ。2千単位の差異は誰もが調査する。3単位や5単位の差異は、十分に近いと感じられるため、手動調整で片付けられてしまう。しかし小さな差異は、しばしばマッピング誤りの早期信号だ。今日の3単位が、来月には3千になることもある。私たちのルールは、棚卸中の余分なスキャン1回だったと判明した場合でも、すべての差異を理由カテゴリ付きで表に入れることだ。小さな差異を記録しておかなければ、大きな差異が来たとき、どこから探し始めればよいかすら分からなくなる。

倉庫のWMS・ERP連携 稼働開始チェックリスト

締めくくりとして、直接使えるチェックリストを示す。稼働開始の夜に各項目にチェックを入れること。単位マッピング表は例外カテゴリをカバーしているか、ステータスマッピング表は両側の責任者に署名されているか、ロット番号のルールは両システムで同じものか、インターフェースには障害アラートと再試行の仕組みがあるか、差異表は毎日自動で回っているか、差異理由はその5カテゴリに限定されているか、責任文書は3者すべてに送付済みか。7項目すべて合格なら、稼働開始だ。1つでも欠ければ、稼働開始後に修正するコストは、今の何倍にもなる。

率直な真実はこうだ。WMSとERPの帳簿が合わないのは、ほとんど決して技術の問題ではない。経営が決着をつけなかった定義の問題だ。定義を書き出し、署名してもらい、毎日調整すること。それはシステムを置き換えるよりもはるかに効果がある。私はこの落とし穴を3回見てきたが、原因は毎回違った。しかし解決策は同じだった。まずトリアージ、次に責任の割り当て、最後にシステムの修正だ。

Lin Xiao（WMS導入コンサルタント）著

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