前例なき「ビッグバン導入」はいかにして成し遂げられたのか? ライオンの基幹システム刷新プロジェクト

数十年間使い続けたレガシーシステムを一気に刷新するという、多くの企業が頭を悩ませる難題に、ライオンは真正面から挑んだ。会計から生産、物流まで全てのシステムを同時に入れ替える「ビッグバン導入」。一歩間違えれば事業停止のリスクを伴うこの手法を、なぜ同社は選択したのか。

6月17日に開催されたWebセミナー「TECH+セミナー ERP 2025 Jun. 自社に適したERP実現へⅢ」に、ライオン デジタル戦略部長の木下陽児氏が登壇。同社の基幹システム全面刷新プロジェクトについて講演を行った。1891年創業、134年の歴史を持つ老舗企業が敢行した壮大なプロジェクトの実体験を基に、ERP導入の成功要因と課題を解説した。

40年使い続けたシステムからの脱却

ライオンの旧基幹システムは、1980年のライオン歯磨とライオン油脂の2社合併時に構築されたメインフレーム上のシステムが起源となっていた。「2012年にオープン化したものの、基本的なアーキテクチャはずっと引き継がれてきた」と木下氏は説明する。生産購買管理や需給管理などのSCM関連システムも1988年以降に構築され、20年以上にわたって使用されてきた。

• 

  旧システム構成図

同社グループの事業特性として、オーラルヘルスケアから産業用洗浄剤まで幅広い製品を扱い、多種多様な顧客に販売している点が挙げられる。この製品数と顧客種別の多さによりシステム開発の難易度が上がる一方、「基本的には物を売って、その瞬間で取引が終わる商売であるため、1つの取引が何日、何か月もかかったり、長期にわたるアフターサービスを提供したりするなどはあまりない」（木下氏）という特徴は逆にERP導入のハードルを下げる部分となる。

• 

  ライオングループの国内におけるサプライチェーン体制

2016年時点では、「ERPについては少し先になってから考えよう」というコンセンサスが社内にあったという。しかし、2017年から2018年までにかけての好景気による需要増などを受け、新工場建設などの大型設備投資計画が具体化したことでシステム投資の方針にも変化が生じる。工場建設などの大規模な設備投資と、システムの投資と償却のタイミングが重ならないよう調整する必要が生じたのだ。

さらに、SCM部門から老朽化した計画系システムの更新提案がなされた際、基幹システムを同時に更新することを検討すべきとの指示が出された。「今振り返ると、部分的な更新では結局モグラ叩きの状態になっていたと思う。一気に更新するという決断ができてよかった」と同氏は振り返る。

こうして、2016年時点では「先送り」だったERP導入は、2018年には「投資対効果があるなら早く導入し、他の大型投資との順序も考慮して先に実施する」方針へと転換。2021年の稼働を目指してプロジェクトがスタートした。

未曾有の「ビッグバン導入」のポイントは、Fit to Standardの徹底

通常のERP導入プロジェクトでは一般的に数年がかりで業務プロセスの再定義や製品選定を行うが、ライオンは比較的短期間で進めた。すでに会計でSAPを使用していた実績から、「SAPの採用を早期に決定し、実際に導入してまともに動くかという視点で、業務プロセスとの適合性の評価を進めた」（木下氏）という。

プライムベンダー選定では、当時の「SAPの2025年問題」（旧バージョンのサポート期限、現在は2027年に延期されている）を背景に各社ともリソース確保が難しい状態で、大規模スコープの提案依頼に対し引き受け手が見つからず難航したが、木下氏によると最終的には「周辺部分のプロジェクトマネジメントも含めて自社グループのリソースにて引き受けていただけるベンダーが見つかった」という状況だった。

ライオンが選択したのは、会計・販売だけでなく、生産・計画・購買・物流まで含む全面的なシステム刷新だった。「一般的にビッグバン導入と言われる範囲を超えていた。まさにビッグバン中のビッグバン」と同氏は表現する。

• 

  新基幹システムの対象範囲

これだけの規模になると、段階的移行は現実的ではない。木下氏は「関係会社も含めて同じ旧基幹システムを使用していたため、一斉に移行・稼働する必要があった」と説明する。多種多様な顧客への販売という事業特性により、SAP標準機能への適用も難航することが予想された。

この大規模開発におけるコスト抑制のため、ライオンはFit to Standardを徹底した。特に注目すべきは「アドオン審査会」の設置である。「SAPのベストプラクティステンプレートをベースに、アドオン開発は本当に必要かを議論し尽くした」と同氏は明かした。

結果として、SAP導入範囲での標準適合率は67%、アドオン数としては約240本となった。同社ではSAP旧バージョンの会計機能だけを2006年から利用していたが、会計機能における新旧アドオン本数の比較では23%の削減となっている。

「他社事例でSAPの更新時に劇的にアドオン数を減らしたという話がよく聞かれますが、そういった事例と比較してもこれだけの導入規模で約240本のアドオン数というのは、絶対数として非常に少なく仕上げることができたと言えます」（木下氏）

稼働までの道のり

社内推進体制では、既存IT部門とは別に専任組織を設置した。開発チームは機能領域別に編成。各チームはベンダーのメンバーと同じ部屋で机を並べて一緒に業務を進めたという。

意思決定機関としては、社長を含む役員とベンダー、SAPのメンバーによるステアリングコミッティを設置。3社での意思決定スキームをつくり、重要な節目での判断を行った。各部門には「ビジネスプロセスリーダー（BPL）」を配置し、テストや教育を自律的に実施する体制を構築した。

当初2021年稼働予定だった新システムは、開発工数の膨らみやコロナ禍の影響を受け、1年4か月の延期を余儀なくされたが、2022年5月に本格稼働を迎えた。

• 

  新旧システム構成図

稼働後の現実～本番稼働はゴールではなく……

新システムは全体としてはおおむね順調に稼働を開始したが、さすがにこれだけの範囲のシステムの一斉切替で全くのノートラブルということはなく、稼働後しばらくは大小さまざまなトラブルへの対応を余儀なくされた。木下氏は実体験に基づき「トラブルは遅れて発生するもの」と語る。例えば、旧システムで入力された受注データに対して稼働初日の出荷が全てトラブルなく済んだとしても、初日に新システムで入力された受注データに対して行う2日目の出荷が全てうまくいくとは限らない。

同様に、工場から配送センターへの商品の輸送、発注した原材料の工場への納品、1～2か月先の生産計画など、新しいシステムでの操作ミスやシステム自体の不具合が実際のトラブルとして現れるには時間差があるケースが多い。さらに、長期連休中のシステム切替では工場が長期間停止するため、生産機能特有のトラブルは工場の稼働開始後に顕在化するし、返品や赤黒処理、取引先への締日処理と請求／支払、月次／期末の決算処理など、初めて現れる業務処理のパターンそれぞれにトラブルの種が潜んでいると考え、何が起きても冷静かつ迅速に対処できるよう体制を構えてく必要がある。

トラブル対応に加え、「開発は終わらないという認識も重要」と木下氏は指摘する。稼働後も不具合対応やインボイス制度などの法令対応は必ず発生するため、継続的に工数が発生することは見込んでおかなければならない。パッケージソフトやOS、ミドルウェアの保守ライフサイクルに合わせたバージョンアップも必要になる。特にERPは導入期間が長くなる傾向があるため、本番稼働時点でサポート期間が残りわずかになる場合もあり、実際に同社も2024年にSAP S/4HANAのバージョンアップに着手し、2025年1月に本番稼働を実施した。

なぜビッグバン導入を成し遂げられたのか

木下氏は、この困難なビッグバン導入を成功に導いた要因として、以下を挙げた。

• 旧システムの状況：老朽化が著しかったため、全てを新規構築する決断がしやすかった
• 初期フェーズの効率化：要件定義や製品選定に過度な時間とコストをかけずにスタートできた
• マスタデータの品質：既存のマスタデータの設計品質が高く継続利用できた
• 広範なスコープのメリット：圧倒的な広範囲での刷新だったため、コード体系や機能配置の自由度が高く、メンバーのモチベーション向上にも繋がった
• フルクラウド構成：2018年当時は珍しかったサブシステムを含む基幹システムの全てをクラウド上に展開する構成を選択した。導入・運用コストの削減や柔軟なリソース調整が可能となったほか、コロナ禍でのリモートワーク推進の“命綱”にもなった
• 専任組織の設置：既存IT部門とは別に専任組織を立ち上げたことが効果的だった
• 「ワンチーム」ポリシー：所属会社を問わないチーム編成と、コロナ禍でも維持されたフラットなコミュニケーションと信頼関係が力になった
• メンバーの資質：「ストレス耐性、楽観主義、大局観、緻密さ」を持つメンバーが集まり、強固な信頼関係を維持できた

講演の最後に同氏は、自社に適したERP実現への示唆を提供した。レガシーシステムとERPの関係を道具箱に例えて、「レガシーシステムは長年使い込まれた工具が置いてある作業部屋のようなもの。一方、ERPはきれいに整った新しい工具セット」と表現。重要なのは、その工具セットをどの範囲で使うかという判断だ。

「全部入りのセットを買うのか、基本セットだけにして別の専門工具を外付けするのか、さまざまな選択肢があります。しかし、ERPベンダーが推奨する機能が実際に使いものになるかは別問題です。突き詰めて検証すると『あれ?』というものもある。重複機能への対応や、本当に使える機能かの見極めも必要です」（木下氏）

そのため、業務プロセスの詳細確認をどこまで行うか、どこで割り切るかが重要になる。木下氏は「非常に悩ましい問題だが、どこかで決断することも必要」と結んだ。

• 

  「自社に適したERP」とは