SAPシステム導入の失敗 食品メーカーの事例から見える失敗回避のヒント
INDEX LINK
はじめに
2024年4月に発生した有名食品メーカーのSAPシステム障害。
社名は伏せますが、さまざまなメディアでニュースになっているため、ご存じの方も多いと思います。
本件では、複数の商品で出荷遅延が起こる、業績を大幅に下方修正するなど、事業運営に大きなダメージを与えました。
なぜここまで大きな障害になったのでしょうか。
また失敗を回避する手段はあるのでしょうか。
1.SAPシステム障害の概要
まず、システム障害の概況を把握しておきましょう。
今回システム障害が起きた有名食品メーカーでは、2024年4月に新システムへの移行を行ったそうです。
新システムは「SAP S/4HANA」で構築されており、「顧客への継続的価値創出を可能にするバリューチェーン構築と経営の迅速な意思決定を目的とした、調達・生産・物流・ファイナンスなどの情報を統合する基幹システム」と同社では説明しています。
システム障害の影響により同社の冷蔵食品17品目（乳製品、洋生菓子、果汁、清涼飲料など）の受発注および出荷業務に影響が出ました。
また、同社が販売受託している37品目も同様に出荷停止の状況となり、物流センターから小売店へ配送ができない状況となりました。
システム障害発生直後は基幹システムを利用せず手作業にて出荷業務を継続。
しかし、倉庫内とSAP ERP内の在庫管理機能の数量が一致しない事象が発生。
冷蔵食品は入出荷の期間が短く、手作業での修正作業では対応が追い付かなくなったことから、業務の一時停止という判断に至りました。
1-1.障害発生以後の時系列
・2024年4月初旬 システム障害発生
・同月中旬、自社の冷蔵食品17品目の受発注および出荷業務が一時的に停止を余儀なくされる
・同月中旬、受託販売の37品目も同様の事象が起こる
・同月中旬、手作業で出荷業務を継続したがシステム上の在庫との不整合が発生し、修正不可と判断して業務停止
・2024年6月～8月にかけて影響があった品目の出荷を順次再開
製造・小売りにおける基幹システムは、まさに事業の柱です。
受発注、出荷、在庫管理というサプライチェーンの重要なタスクを集中的に管理しています。
今回の事例では、業績の下方修正を実施しており、その金額は150億円ほどとされています。
基幹システムの障害が、いかに甚大かがわかりますね。
2.なぜ障害が起こったのか？
障害原因の詳細は公開されていません。しかし、システム障害の問題個所の特定は済んでいるとのこと。
また、外的要因（サイバー攻撃や不正アクセス）によるものではない回答しています。
となれば、新システムへの移行過程に何らかの問題があったことになりますね。
ちなみに、システム移行の概要は下記のとおり。
・移行プロジェクトは2019年から2024年3月まで足掛け5年を要した
・当初の切り替えは2022年の予定だったが、2024年3月まで延期
・工期延長に伴い、投資費用は215億円から342億円とへ増額
・移行に関しては複数のITベンダーが関与（社名は非公表）
当初予定で3年、延長で5年というかなり大規模なプロジェクトです。
品目の数が多いことや出荷の頻度が高いことが絡み、高度な受発注・出荷・在庫管理が求められたことは間違いありません。
技術的に何が起こっていたかは断定できませんが、一般論で言えば、「急な配送先、数量変更に耐えうる仕様ではなかった」というのが原因になりそうです。
常温や冷凍の品目には問題がおこらず、冷蔵品目のみで障害が発生したことから、おそらくリアルタイム性を要求される品目の動きにシステムがついていけなかったのでしょう。
また、非公式な情報ではありますが、システム導入作業の一部を内製で行ったことが原因との見方もあるようです。
2-1.S/4 HANA移行の難しさが露呈した
ECC6.0からS/4 HANAへの移行では、いくつかのハードルがあります。
特にS/4 HANAの売りである「インメモリデータベースによる高速処理」の恩恵を受けるためには、品目や取引先のデータ整理を厳格に行わなくてはなりません。
S/4 HANAでは、外部のHDDやSSDにあったデータベースを、内部メモリ内に列志向型として格納し、集計速度を上げます。
さらに取引先マスタの刷新に合わせてのデータ統合も必須になることから、今までのバージョンアップとは性質・難易度が大きく異なるわけです。
在庫や出荷のような同時に大量のトランザクションをさばくにあたり、瞬間的な負荷の大きい業務ではデータ更新が追いつかなくなった可能性が示唆されます。
2-2.ビジネスモデルがSAPに適していなかったという見方も
本件では、導入/移行作業の技術的な問題が未解決であったことに加え、「ビジネスモデルとシステムの不整合」も指摘されています。
同社に限らず、基本的に日本の製造・小売業は受注生産型です。
さらに少量生産、多品種生産のパターンが多く、直前に数量を変更されると対応が難しいのです。
海外のように見込み生産であれば、急な変更に対して一定の柔軟性は持ちます。
そして、そもそもSAPをはじめとした海外のERPパッケージは、見込生産方式をベースとして設計されています。
わかりやすいのがMRP（Material Requirements Planning System）ですね。
「資材所要量計画」という名称のとおり、見込生産量に対する「所要量」を事前に計算します。
これを成立させるためには見込生産が適切です。
一方で日本企業の場合、数量や品目に細かい変更が起こると、システムの値を調整して対応するケースがあります。
こういったアナログな業務慣習を無理やりSAPに組み込んでしまうと、カスタマイズやアドオン設計が複雑になり、障害が発生するリスクが高まるのです。
3.障害防止のカギは「ビジネスモデルと標準仕様のギャップ」を埋めること
以上のことを総合すると、「いかにSAP S/4 HANAが高機能なパッケージであるとはいえ、ビジネスモデルとの不整合を吸収することは難しいのかもしれない」と感じます。
もちろん、SAPはあらゆるビジネスモデルに対応しており、生産方式の違いは吸収できます。
しかし、「そもそも向いていないビジネスモデル」に特化した仕様にカスタマイズしていく段階で、クライアント企業やITベンダーのコミュニケーションに齟齬が生じたり、テストが複雑化しすぎてエラーを予見できなかったりといった可能性もあります。
少量・多品目で、受発注や出荷の変更が頻繁に行われるような分野では、精密な移行作業が必須です。
しかし、大枠としてのビジネスモデルは変えずに、システムだけを無理にフィットさせようとすると、どうしても障害のリスクがあがります。
SAPが「Fit to Standard」を標榜している背景には、こうしたリスクの低減があるはずです。
まとめ
今後は伝統的な日本企業でも、海外展開を見越してSAP ERPを導入する企業が増えるかもしれません。
「そもそもSAPが必要なのか」という観点もあります。
しかし、「現状のビジネスモデルに合わないから導入しない」のでは、事業の拡張性を奪ってしまいます。
我々SAP人材も、こうしたクライアント企業の事情を理解しておくべきかもしれません。
なかなか難しいことですが、「ビジネスモデル自体をSAPにすり合わせる」という観点で提案していきたいですね。
