SAP EWMの導入形態を考える前に知っておきたいこと

SAP EWMを導入する際、多くの人が最初に悩むのが「Embedded EWMとDecentralized EWMのどちらを選ぶべきか」という問題です。

インターネットで調べると、「コストならEmbedded」「可用性ならDecentralized」といった比較記事が数多く見つかります。しかし実際のプロジェクトでは、そんな単純な話ではありません。

私自身、これまで複数のSAP EWM導入プロジェクトに携わってきましたが、経験した案件はすべてDecentralized EWMでした。その理由は、24時間稼働の物流センターであったり、大量のマテハン設備と連携していたり、ERP停止による物流停止を許容できない環境だったからです。

実際に私が担当した案件では、データセンターの火災によってSAP ECCが約2週間停止するという事態が発生しました。しかし、Decentralized EWMを採用していたおかげで、物流センター自体は稼働を継続することができました。もちろん一部の業務は手作業による対応が必要でしたが、出荷や入荷、マテハン設備の運用を止めずに済んだのです。

この経験を通じて私は、「EmbeddedとDecentralizedのどちらが優れているか」という議論よりも、「その物流センターに本当に必要な構成は何か」を考えることの方が重要だと感じています。

この記事では、Embedded EWMとDecentralized EWMの違いを整理しながら、実際のプロジェクト経験も交えて、それぞれがどのような現場に向いているのかを解説していきます。

Embedded EWMとDecentralized EWMの違い

SAP EWMには、大きく分けて「Embedded EWM」と「Decentralized EWM」という2つの導入形態があります。

まずは、それぞれの違いを簡単に整理しておきましょう。

Embedded EWMとは

Embedded EWMは、SAP S/4HANAの中にEWM機能を組み込む構成です。

ERPとEWMが同じシステム上で動作するため、マスタデータやトランザクションデータをシステム間で連携する必要がありません。

そのため、

• システム構成がシンプル
• インターフェースが少ない
• 導入・運用コストを抑えやすい

といったメリットがあります。

近年のSAPプロジェクトでは、Embedded EWMを採用するケースも増えており、多くの企業にとって有力な選択肢となっています。

Decentralized EWMとは

一方のDecentralized EWMは、ERPとEWMを別システムとして構築する形態です。

ERP側で作成された受注や出荷指示などの情報を、インターフェースを介してEWMへ連携し、倉庫業務を実行します。

システム構成は複雑になりますが、

• ERPとEWMを独立して運用できる
• 倉庫業務への影響を最小限に抑えられる
• 大規模物流センターや自動倉庫との相性が良い

といった特徴があります。

比較だけでは見えてこない現実

ここまで見ると、

「コスト重視ならEmbedded」

「可用性重視ならDecentralized」

というよくある結論になりそうです。

しかし、実際のプロジェクトではそこまで単純ではありません。

例えば、1時間物流センターが停止しただけで数百万円、場合によっては数千万円規模の損失が発生する現場もあります。

そのような環境では、システム導入費用よりも「止まらないこと」の価値の方が圧倒的に大きくなります。

私がこれまで経験したEWM案件も、まさにそのような物流センターばかりでした。

次の章では、私が担当したプロジェクトでなぜDecentralized EWMが選ばれたのか、その背景についてお話しします。

私が経験した案件はすべてDecentralized EWMだった

これまで私が携わったSAP EWMプロジェクトは、すべてDecentralized EWMを採用していました。

そのため、正直なところ、プロジェクトの中で「Embeddedにするか、Decentralizedにするか」をゼロから議論した経験はあまりありません。

なぜなら、顧客の業務要件を見た時点で、ほぼ自動的にDecentralized EWMが選択されるような案件ばかりだったからです。

24時間365日稼働する物流センター

私が担当した物流センターの多くは、24時間体制で稼働していました。

工場への部品供給や店舗への商品配送など、物流が止まるとその先の業務にも大きな影響が発生します。

そのため、

「システム停止のため出荷できません」

という状況は極力避けなければなりません。

ERPのメンテナンスや障害が発生したとしても、倉庫業務だけは継続できる構成が求められていました。

大量のマテハン設備との連携

また、これらの物流センターでは多くのマテハン設備が導入されていました。

例えば、

• 自動倉庫（AS/RS）
• コンベヤ
• ソーター
• AGV
• 各種搬送設備

などです。

これらの設備は、EWMからの指示によって動作します。

物流センター全体が高度に自動化されている場合、EWMが停止することは設備全体の停止につながります。

そのため、ERP側で問題が発生したとしても、倉庫業務やマテハン設備への影響をできるだけ切り離したいという考え方がありました。

「5分も止められない」という現場

特に印象的だったのは、顧客との打ち合わせでよく出てきた言葉です。

「1時間止まったら大変な損失になる」

「5分でも止めたくない」

「物流を止めるくらいなら多少の手作業は受け入れる」

このような考え方を持つ企業は少なくありません。

物流センターが停止すると、出荷遅延だけでなく、生産ライン停止や店舗欠品など、さまざまな影響が連鎖的に発生します。

その損失額は、システム導入費用の差額を簡単に上回ることもあります。

グローバルテンプレートとして採用されているケースも多い

もう一つの理由として、グローバル企業では本社主導でDecentralized EWMが標準構成として採用されているケースもありました。

その場合、日本だけEmbeddedを採用するという選択肢は現実的ではありません。

既に海外拠点で運用実績のあるアーキテクチャをそのまま展開する方が、保守や運用の観点でもメリットが大きいからです。

このように、私が経験した案件では「Decentralized EWMを選ぶ理由」が複数存在していました。

そして、その選択が正しかったと感じる出来事が実際に発生します。

次の章では、データセンターの火災によってSAP ECCが約2週間停止した際の実体験についてお話しします。

ECCが2週間停止。それでも物流センターは止まらなかった

ここからは、私が実際に経験した出来事についてお話しします。

ある案件で稼働していたSAPシステムは、ECCとDecentralized EWMで構成されていました。

ある日、データセンターで火災が発生し、ECCが停止してしまいました。

当初は数時間で復旧するのではないかと考えられていましたが、状況は想像以上に深刻で、結果としてECCは約2週間利用できない状態となりました。

物流業務に関わるシステム担当者としては、かなり緊張感のある状況だったことを覚えています。

もしEmbedded EWMだったらどうなっていたか

もちろん実際に検証したわけではありませんが、もしEmbedded EWM構成だった場合、ERPとEWMは同一システム上で稼働しています。

つまり、ECC（あるいはS/4HANA）が停止すれば、倉庫業務も同時に停止してしまう可能性があります。

出荷指示の確認もできない。

入荷予定も確認できない。

マテハン設備への指示も出せない。

物流センター全体が大きな影響を受けていたかもしれません。

実際にはどう対応したのか

幸いにも、この案件ではDecentralized EWMを採用していました。

そのため、ECCは停止していても、EWM自体は継続して稼働することができました。

もちろん完全に通常運転というわけではありません。

本来であればECCから連携される伝票情報が届かなくなるため、そのままでは業務を継続できません。

そこで現場では、必要な伝票情報を手作業でEWMへ投入する運用を実施しました。

手間は増えましたが、一度EWMへ伝票を登録してしまえば、その後の倉庫業務は通常通り進めることができます。

ピッキング。搬送。入庫。出庫。そしてマテハン設備との連携。

これらの業務は継続することができました。

「止まらないこと」の価値を実感した瞬間

この時に強く感じたのは、「完全自動であること」よりも「業務を継続できること」の重要性です。

確かに手作業は発生しました。

現場の負荷も増えました。

しかし、物流センターそのものが停止する状況と比較すれば、その影響は限定的でした。

顧客がプロジェクト中に繰り返し話していた、

「5分も止めたくない」

という言葉の意味を、この時に改めて実感しました。

Decentralized EWMの価値は平常時には見えにくい

普段システムが正常に稼働している時は、Embedded EWMとDecentralized EWMの違いを意識する機会はあまりありません。

むしろ、

• システムが増える
• インターフェースが増える
• 運用が複雑になる

といったデメリットの方が目につくかもしれません。

しかし、本当に価値が問われるのは障害発生時です。

ECCが約2週間停止したこの経験を通じて、私はDecentralized EWMが持つ事業継続性（Business Continuity）の重要性を強く認識しました。

もっとも、だからといってすべての企業がDecentralized EWMを選ぶべきだとは思っていません。

次の章では、私が考える「Embedded EWMを選ぶべきケース」についてお話しします。

Embedded EWMを選ぶべきケース

ここまで読むと、

「それならDecentralized EWM一択なのでは？」

と思われるかもしれません。

しかし、私はそうは考えていません。

実際のところ、物流センターの規模や業務要件によっては、Embedded EWMの方が合理的な選択になるケースも十分にあります。

物流センターがそこまで大規模ではない場合

私がこれまで経験してきた案件は、24時間稼働かつ大量出荷を行う大規模物流センターが中心でした。

しかし、世の中の倉庫がすべてそうとは限りません。

例えば、

• 出荷件数がそれほど多くない
• 自動倉庫やソーターがない
• 日中のみ稼働
• システム停止時に業務を一時的に止められる

といった環境であれば、Decentralized EWMが持つ可用性のメリットを十分に活かせない可能性があります。

その場合は、シンプルな構成で運用できるEmbedded EWMの方が適しているかもしれません。

システムはシンプルな方が運用しやすい

Decentralized EWMでは、ERPとEWMの間でデータ連携が発生します。

そのため、

• インターフェース監視
• キュー管理
• 障害時の切り分け

といった運用業務が必要になります。

プロジェクト中はもちろん、本番稼働後も継続的な運用コストが発生します。

一方、Embedded EWMはERPとEWMが同一システム上で稼働するため、構成がシンプルです。

運用担当者の負荷やシステム管理の複雑さを抑えられるというメリットがあります。

そもそもEWMは必要なのか？

ここは少し踏み込んだ意見になりますが、私は導入形態を議論する前に考えるべきことがあると思っています。

それは、

「本当にEWMが必要なのか？」

ということです。

SAP EWMは非常に高機能な倉庫管理システムです。

その反面、

• 導入コスト
• ライセンス費用
• 保守費用
• 運用負荷

も決して小さくありません。

もし倉庫業務が比較的シンプルであれば、

• SAP MMの標準機能を利用する
• ローカルWMSを利用する
• 一部業務を紙運用で補完する

といった選択肢の方が費用対効果に優れるケースもあるでしょう。

もちろん業務要件次第ですが、「EWMを導入すること」が目的になってしまうのは避けるべきだと思います。

私が考える判断基準

私自身はDecentralized EWM派です。

ただし、それはEWMを導入するような規模の物流センターを前提とした話です。

大規模物流センターで、

• 24時間稼働
• 高い出荷量
• 多数のマテハン設備
• 停止許容時間が極めて短い

という条件であれば、私は今後もDecentralized EWMを選ぶと思います。

一方で、小規模な倉庫や比較的シンプルな物流業務であれば、Embedded EWM、あるいはEWM以外の選択肢も十分に検討する価値があります。

重要なのは、「どちらが優れているか」ではなく、「自社の物流にどちらが適しているか」を考えることです。

まとめ

SAP EWMの導入形態としてよく比較されるEmbedded EWMとDecentralized EWM。

一般的には、

• コストやシステム構成のシンプルさを重視するならEmbedded EWM
• 可用性や事業継続性を重視するならDecentralized EWM

と言われることが多いでしょう。

もちろん、その考え方自体は間違っていません。

しかし、実際のプロジェクトでは比較表だけでは判断できない要素が数多く存在します。

私がこれまで携わった案件では、

• 24時間稼働の物流センター
• 大量のマテハン設備
• 停止による大きな機会損失
• グローバル標準アーキテクチャ

といった理由から、すべてDecentralized EWMが採用されていました。

そして実際に、データセンターの火災によってECCが約2週間停止するという障害も経験しました。

その際、Decentralized EWMだったからこそ、手作業による対応を挟みながらも物流センターの稼働を継続することができました。

この経験から、私は現在もDecentralized EWMを支持しています。

ただし、それはあくまで大規模物流センターを前提とした話です。

物流センターの規模や業務内容によっては、Embedded EWMの方が合理的な選択になることもありますし、場合によってはEWMそのものが過剰投資になるケースもあるでしょう。

大切なのは、

「EmbeddedかDecentralizedか」

を先に考えることではなく、

「自社の物流に求められる要件は何か」

を整理することです。

その結果として、可用性を重視するのであればDecentralized EWM、シンプルな構成を重視するのであればEmbedded EWMという選択につながります。

この記事が、これからSAP EWMの導入や構成検討を行う方の参考になれば幸いです。