【実務解説】SAP EWMとマテハンの境界線（デマケーション）をどう引くか？4つの実装パターンと推奨構成

自動倉庫やソーターなどのマテハン機器を導入する際、避けて通れないのが「どこまでをSAP EWMで管理し、どこからを他社ベンダー（マテハンメーカー等）のシステムに任せるか」という、いわゆる「境界線（デマケーション）」の引き方です。

この境界線を間違えると、導入コストが跳ね上がったり、本稼働後に「システムが複雑すぎて、現場で何が起きているか分からない……」という最悪の事態に陥るリスクがあります。

倉庫制御の「3つの階層」を整理しよう

まず、議論の前提として倉庫を動かすシステムの3つの階層を整理します。これを理解しておかないと、ベンダーとの会話が噛み合いません。

1. WMS（倉庫管理システム）： 在庫の場所、誰が何をすべきかという「作業指示」を出す司令塔。
2. WCS（倉庫制御システム）： 司令塔からの指示を受け、どのコンベアを通すか、どのクレーンを動かすかといった「搬送ルート」を制御する。
3. PLC（プログラマブル・ロジック・コントローラ）： モーターを回す、センサーに反応してストッパーを動かすといった「物理的な動作」を司る。

SAP EWMを導入する際、この3層のうち「どこまでをEWMが担当するか」によって、大きく4つのパターンに分かれます。

EWM導入における4つの選択肢

具体的にどのような選択肢があるのかを詳しく見ていく前に、まずは全体像を視覚的に捉えておきましょう。

ここでのポイントは、「EWMでどこまで現場の動きに踏み込むか」という管理範囲の違いです。EWM（IT側）が責任を持ち連携する範囲を青、マテハンベンダー（物理側）が責任を持ちEWMと連携されない範囲をオレンジで色分けすると、その境界線の変化が一目でわかります。

自社の運用体制や将来の拡張性をイメージしながら、どの「青の深さ」が理想的か比較してみてください。

① EWM ＋ 外部WMS（管理レベルでの連携）

このパターンは、SAP EWMとマテハンメーカーのWMS（倉庫管理システム）を並列で動かす構成です。EWMは「何を、いくつ入出庫するか」という大まかな指示（配送指示など）を送るだけで、倉庫内の「どの棚に入れるか」「どの順番で動かすか」といった詳細な制御は、すべてマテハンメーカー側（国内ではD社やM社などが代表的）のシステムに委ねます。

• メリット：
  • 導入ハードルの低さ： SAP側の設定は「外部システムへの指示送信」に特化できるため、非常にシンプルに済みます。
  • メーカーの知見を最大化： 「その機械を最も効率よく動かすロジック」はメーカー製WMSに組み込まれているため、マテハンの性能をフルに引き出せます。
  • 保守負担の軽減： 倉庫内のトラブルやエラー対応をマテハンベンダーに一任できるため、自社のITリソースが少なくても運用可能です。
  • ライセンスコストの最適化：
    SAP S/4HANAでは、基本的な倉庫管理（Basic EWM機能）は標準ライセンスに含まれますが、マテハンを直接制御するMFS（マテリアルフローシステム）などの高度な機能を使用すると、追加ライセンスが必要な「Advanced EWM」の対象となります。このパターン①は、複雑な制御を外部に逃がすことでAdvanced機能の使用を回避しやすく、ライセンス費用を抑制できる可能性が高まります。
  • S/4HANAとの親和性： 構成がシンプルなため、S/4HANAに内蔵された「Embedded EWM」との相性が良く、基幹システム（ERP）と密に連携した運用が可能です。
• デメリット：
  • 在庫データの二重持ちと同期ズレ： SAPと外部WMSの両方に在庫データを持つため、情報の不一致が起きやすくなります。棚卸や差異発生時の調査には、両方のシステムを突き合わせる手間がかかります。
  • マスタの二重管理： 商品コード、荷姿（パレット・ケース等）、保管条件などの情報を、SAPと外部WMSの両方で常に最新の状態に保つ必要があり、運用負荷が増大します。
  • ブラックボックス化とベンダーロックイン： 倉庫内の詳細な進捗がSAPからは見えません。また、現場の運用変更やエラー対応がマテハンベンダーに依存するため、自社でコントロールできる範囲が狭まります。

このパターンが推奨されるケース

• すでに他社WMSで安定稼働している既存の自動倉庫があり、SAP導入にあたって現場の混乱やリスクを最小限に抑えたい場合。
• とにかく短期間での稼働を優先し、複雑なアドオン開発や設定を避けたい場合。

② EWM（WMS） ＋ 外部WCS（制御レベルでの連携）

この構成は、SAP EWMが「倉庫の司令塔（WMS）」として、物理的な棚番（ビン）レベルまで在庫を完全に管理する形です。マテハンメーカー側は、コンベアやクレーンの搬送ルートを制御する「実行役（WCS：倉庫制御システム）」に専念します。
EWMから「パレットAを棚番01-01-01から出庫口Bまで運べ」という、具体的な場所を指定した指示を飛ばすのが一般的です。

• メリット：【筆者推奨】
  • 「在庫の真実（SAP界隈ではよく『Single Source of Truth：信頼できる唯一の情報源』と言われます）」の実現： SAPがすべての在庫場所をリアルタイムで把握するため、外部システムとの在庫同期ズレが根本的に解消されます。
  • 圧倒的な透明性とトレーサビリティ： 「どのロットが、どの棚の、どのパレットにあるか」をSAP画面一つで即座に特定できます。これは品質管理や監査対応が厳しい現場では強力な武器になります。
  • ERPとの高度な連携： 出荷の優先順位変更や欠品時の振替対応など、ERP側の判断をダイレクトに現場の動きへ反映させることが可能です。
  • 柔軟なリソース戦略（ベンダーロックインの回避）： 倉庫管理のロジックがSAP側にあるため、保守や改修を特定のメーカーに依存せず、自社やSAPに強いITベンダーで対応できる領域が広がります。
• デメリット：
  • ライセンスコストの変動：
    SAP S/4HANAのライセンス体系において、自動倉庫との高度な連携（MFS機能の利用）や、詳細な在庫最適化を行う場合、追加ライセンスが必要な「Advanced EWM」の対象となります。パターン①のBasic機能と比較すると、高機能な分だけライセンス費用が増加する可能性が高いため、事前のコストシミュレーションが不可欠です。
  • 構築難易度とインターフェース開発： EWM内に物理的な倉庫レイアウトを詳細に定義（棚番マスタ等）し、WCSと通信するためのインターフェース（RFCやIDoc、API等）を作り込むための高い技術力が必要です。
  • マスタの同期管理： 物理的な棚の増設やレイアウト変更があった際、SAP EWMと外部WCSの両方の棚番マスタを常に一致させておく運用負荷が発生します。
  • トラブル切り分けの複雑化： 万が一クレーンが止まった際、「EWMの指示ミスか」「WCSの制御ミスか」を特定するために、双方のシステムログを突き合わせて調査できる知見者が求められます。

このパターンが推奨されるケース

• 「在庫の正確性」を最優先し、システム間のデータの不一致による現場の混乱をゼロにしたい場合。
• 将来的にマテハン機器のリプレースや増設を予定しており、管理ロジック（WMS）を自社の資産として中立に保っておきたい場合。
• 法規制や品質管理の観点から、詳細な在庫履歴（トレーサビリティ）の保持が必須な業界（食品・医薬・精密機器など）。

③ EWM（WMS＋WCS） ＋ 外部PLC（直接制御レベルでの連携）

この構成は、SAP EWMが「倉庫の司令塔（WMS）」と「搬送ルートの制御（WCS）」の両方の役割を担います。マテハンメーカー側にはシステムを置かず、EWMが直接、コンベアやクレーンのモーターを動かす「PLC（プログラマブル・ロジック・コントローラ）」に対して、「右へ曲がれ」「止まれ」といった電気信号に近いレベルの電文（Telegram）を直接送る形です。

• メリット：
  • 究極のシンプル構成（システム図の上では）： 中間システム（WCS）が存在しないため、理論上は最もシステム構成がシンプルになり、サーバー費用などのインフラコストを抑えられます。
  • 外部ベンダーへの依存度を最小化： 搬送ロジックそのものをSAP側で定義するため、マテハンメーカーによるソフト改修を待たずに、自社で制御ルールを柔軟に変更・更新できる可能性があります。
• デメリット：【ハイリスク・要注意】
  • ライセンスコストの確定：
    この構成で必須となる「MFS（Material Flow System）」機能は、SAP S/4HANAにおいて明確に「Advanced EWM」のライセンス対象です。パターン①のようにBasic機能で運用する選択肢は一切なくなるため、ライセンス費用は確実に発生します。
  • 物理的なタイミング制御の難しさ（レイテンシのリスク）： 本来、ミリ秒単位のレスポンスが求められるマテハンの挙動を、基幹システムであるSAPが制御することには物理的な限界があります。ネットワークの遅延やSAP側の負荷増大により、「コンベア上でパレットが止まる・詰まる」といった事態が起きやすく、安定したスループット（処理能力）の確保が極めて困難です。
  • 責任分界点の消失： マテハンメーカーは「自社の制御ソフト（WCS）を通さないなら、本来の機械性能（時間あたりの搬送個数など）は保証できない」というスタンスを取ることが一般的です。トラブル時に「SAPが遅いのか、機械が悪いのか」の判断ができず、板挟みになるリスクがあります。
  • 保守の極端な属人化： SAPの知識だけでなく、PLC電文や機械制御の深い知識を併せ持つ「超・専門家」が必要になります。そのような人材は市場に少なく、保守が特定のコンサルタントやエンジニアに完全に依存してしまいます。

このパターンを検討する際の条件

システム構成を究極までシンプルに統合できる一方、導入・運用には非常に高いハードルが存在します。このパターンが現実的な選択肢となるのは、以下のような条件下に限定されるのではないかと思われます。

• 搬送ロジックがシンプル： 分岐や合流が少なく、複雑なタイミング制御を必要としない単純な搬送ラインであること。
• 自社主導の保守体制： SAP MFSとPLC電文の両方に精通した専門エンジニアを自社（あるいは専属のパートナー）で確保でき、トラブル時の切り分けから修正までを迅速に行える体制があること。
• ベンダーロックインの完全排除を最優先： 初期コストや構築難易度のリスクを取ってでも、将来的な拡張や制御ルールの変更を、自社主導で自由に行いたいという明確な戦略がある場合。

一般的な大規模自動倉庫に適用するには、スループット（搬送能力）の保証や保守の継続性の観点から、非常に高度なプロジェクト管理能力が求められる「玄人向けの構成」と言えます。

④ EWMを入れない（全部他社ベンダーにお任せ）

SAP EWMという階層を作らず、SAP ERP（S/4HANA等）から直接、マテハンメーカー製のWMSや外部倉庫業者のシステムへ指示を送る構成です。ERP側からは倉庫の中身がひとつの「大きな箱（保管場所）」としてしか見えず、詳細な棚管理や作業制御はすべて外部システムに任せきりにします。

• メリット：
  • 初期導入コストの抑制（ライセンス面）： SAP EWMのライセンス（Basic / Advanced共に）が不要になるため、初期投資を最も低く抑えることができます。
  • 導入スピードの速さ： EWMの設定や要件定義のプロセスを丸ごとカットできるため、とにかく早く立ち上げたい場合には有利です。
  • 現場特化の運用： その倉庫・その機械に特化した外部WMSの機能をそのまま利用できるため、現場レベルでの最適化は図りやすくなります。
• デメリット：【現場のブラックボックス化】
  • 情報の解像度が低い： SAP側からは「倉庫の中に在庫がある」ことしか分からず、具体的な棚番や作業の進捗状況（今まさにピッキング中なのか等）がリアルタイムで見えません。
  • 在庫不一致（同期ズレ）のリスク： ERPと外部WMSの間で在庫データの不一致が日常的に発生しやすくなります。不一致が起きた際、「どちらが正しいのか」を突き止めるために外部システムへログインして照合する手間が絶えず発生します。
  • トレーサビリティの断絶： 「特定のロットが、今、倉庫内のどこにあるか」をSAPから追跡できないため、緊急時の在庫ロックや品質不備への対応スピードが落ちるリスクがあります。
  • インターフェース開発の負担： EWMを入れないからといって開発がゼロになるわけではありません。ERPと外部WMSを繋ぐためのインターフェース（アドオン）は依然として必要であり、その構築とメンテナンスには相応の手間がかかります。

このパターンを検討する際の条件

小規模拠点： EWMのライセンス費用や導入工数をかけるほどの規模ではなく、外部システムの標準機能で十分に運用が回る場合。

倉庫の役割がシンプル： 入れて出すだけの単純な保管がメインで、SAP側から詳細な作業進捗を管理する必要性が低い場合。

3PL（外部委託）メインの運用： 自社で倉庫を管理せず、業者側にすべての運用と在庫責任を委ねている場合。

大規模・複雑な倉庫こそ、EWMを「外出し」してはいけない理由

「マテハンメーカーが優れたWMSを持っているなら、SAP EWMは不要（パターン④）ではないか？」と考える方も少なくありません。しかし、現場が大規模で、かつ自動倉庫のような複雑な設備を持つほど、EWMをあえて介在させるべき明確な理由があります。

それは、現代の物流において不可欠な「情報の解像度」と「経営のレスポンススピード」を担保するためです。

「大きな箱」管理の限界

マテハンメーカー独自のWMSに全てを任せると、SAP（ERP）側からは、倉庫が単なる「中身の詳細は不明だが、在庫が入っている大きな箱」としてしか見えなくなります。
この状態で、例えば品質不備によるロット指定の出荷停止や、特定の在庫を探し出す指示が出た場合を想像してみてください。担当者は外部システムにログインしてデータを探し、それをSAPのデータと突き合わせ、整合性を確認する……。この「二つのシステムを跨ぐ手間」こそが、有事の際の致命的なタイムロスを生むのです。

「在庫の真実」がもたらすリスク管理能力

一方で、パターン②（EWM＋外部WCS）のような構成であれば、SAPの画面一つで「どのロットのパレットが、今どのクレーンの上にあり、中身は何であるか」までをリアルタイムに可視化できます。

これが先ほど述べた「在庫の真実（Single Source of Truth）」の真価です。
在庫の情報がSAPに集約されていれば、現場に問い合わせることなく、ERP側で即座に出荷制限をかけたり、在庫の再配置を検討したりすることが可能になります。この透明性と情報の鮮度こそが、不確実性の高い現代の物流に求められるリスク管理能力そのものなのです。

「現場が勝手に動いている状態」から「経営が現場をリアルタイムに把握している状態」へ。大規模な倉庫こそ、この解像度の差が数年後の運用効率に大きな差となって現れます。

まとめ：自社に最適な「境界線」を引くために

SAP EWMの導入は、単にソフトウェアをインストールする作業ではありません。マテハンメーカーという「物理のプロ」と、SAPという「情報のプロ」の守備範囲をどう設計するかという、戦略的なパズルのようなものだと、私は感じています。

今回ご紹介した4つのパターンを改めて整理すると、選択の指針は以下のようになります。

• 保守性と安定性を最優先するなら：パターン①
  （外部WMSに任せ、SAP側の構成をシンプルに保つ。Basicライセンス活用の道も残る）
• 情報の透明性と戦略的な在庫管理を目指すなら：パターン②【筆者推奨】
  （「在庫の真実」をSAPに集約し、高度なトレーサビリティを実現する。Advancedライセンスの検討が必要）
• 技術的な統合を極めるなら（ハイリスク・玄人向け）：パターン③
  （MFSによる直接制御。システムは集約されるが、保守難易度とライセンスコストが最大化する）
• コストとスピードを重視し、現場の解像度を割り切るなら：パターン④
  （EWMなし。小規模拠点や3PL委託には有効だが、大規模倉庫ではブラックボックス化のリスクがある）

検討の第一歩として、ぜひ「万が一のトラブル時に、どこまで自社（または自社側のベンダー）で切り分けと復旧を行いたいか？」という運用保守の観点から議論を始めてみてください。それが、自社にとっての「現実的な落としどころ」を見つける一番の近道です。

さて、制御の境界線が決まれば、次はいよいよ実務レベルの話に踏み込みます。EWMの中で具体的にどのような「プロセス」を定義していくべきか。次回は、EWM導入のキモである「入庫・棚入れプロセスの基本設計」について詳しく解説します。