SAP 2027年問題の本質は、システム移行ではなく「企業の記憶」を継承できるかにある
データでは移せない、例外処理と判断の理由をどう残すか
新しいERPへの移行計画が動き出すと、会議室には一覧表が増えていきます。
移行対象となるマスタ、トランザクション、帳票、インターフェース、権限、周辺システム。どこまでを新環境へ持ち込み、どこから整理し直すか。計画表が具体的になるほど、プロジェクトは前へ進んでいるように見えます。
その一方で、一覧表には載りにくい言葉が、会議の途中で出てきます。
「この処理は、月末だけ止めないでください」
「その承認ルートは、一度標準化しようとして失敗したんです」
「このエラーはシステムの問題ではなく、前工程で確認が抜けたときに起きます」
どれも、データ移行の対象としては扱いにくい情報です。しかし、移行後も業務を止めずに回すためには、むしろこちらの方が重要になることがあります。
SAPのBusiness Suite 7の対象コアアプリケーションでは、標準保守が2027年末までとされ、その後は2030年末まで任意の延長保守が提供されます。したがって、「2027年末ですべて使えなくなる」という話ではありません。ただ、移行や刷新を検討する企業にとって、残された時間を何に使うべきかという問いは、すでに現実のものになっています。
このとき、移行の難しさを「古いシステムを新しいシステムへ移すこと」とだけ捉えると、見落としが生まれます。
本当に引き継ぐべきものは、データだけではありません。長年の業務の中で積み上がった例外処理、承認の順序、担当者どうしの役割分担、月末や決算期にだけ必要になる確認、障害時の連絡順序。そうした仕事の背景には、企業が時間をかけて作ってきた判断の理由が残っています。
それを、ここでは「企業の記憶」と呼びます。
2027年問題は、保守期限だけの話ではない
SAP移行を考える際、最初に意識されるのは保守期限や製品ロードマップです。これは当然の出発点です。既存環境をどこまで維持するのか、S/4HANAへ移行するのか、周辺システムを含めて再設計するのか。経営としても、投資判断を先送りにはできません。
ただ、期限を起点に計画を急ぐほど、現行業務の理解を飛ばしてしまう危険があります。
ERPは、会計、人事、購買、販売、生産、物流といった業務をまたぎます。画面や帳票の数だけではなく、それぞれの部門がどのタイミングで何を確認し、どの条件では通常の流れから外れるのかまで含めて動いています。
標準機能へ寄せる判断が必要な場面もあります。しかし、現行のやり方を「古いから不要」と整理する前に、なぜその処理が残ったのかを確かめなければなりません。
以前に標準化を試みたものの、取引先との関係や月次の締め方、法務・監査上の要請、現場の作業順序との不整合によって戻された処理かもしれません。単に担当者の慣れで残っているだけの場合もあります。両者を区別しないまま移行すると、新環境で同じ混乱を繰り返すことになります。
ERPリプレイスで探すべきなのは、「何があるか」だけではない
移行プロジェクトでは、現行システムに何が存在するかを調べます。
どのマスタがあるか。どの帳票が使われているか。どのインターフェースがつながっているか。どのロールにどの権限が付いているか。
もちろん、どれも必要な確認です。
ただ、それだけでは、「なぜこの状態になっているのか」が残りません。
たとえば、承認経路が複雑になっている場合を考えます。単純に承認者が多すぎるのかもしれません。しかし、過去に誤発注が発生し、その再発防止として確認者が追加された可能性もあります。あるいは、組織変更が繰り返されるなかで、古い承認者が残り続けているだけかもしれません。
同じように見える設定でも、背景によって移行時の扱いは変わります。
削るべきものなのか。新しい運用で置き換えるべきものなのか。それとも、理由を確認したうえで別の形で残すべきものなのか。移行プロジェクトで必要になるのは、現行仕様を写し取ることではなく、仕様の背後にある業務判断を見つけ直すことです。
企業の記憶は、どこか一つの文書にまとまっているとは限りません。
設計書に残っているものもあれば、手順書の注記にしか書かれていないものもあります。障害報告や問い合わせ履歴を追うと初めて見えてくることもありますし、長く運用に関わってきた担当者に聞かなければ分からないこともあります。
だから移行前の整理は、データを移す準備であると同時に、企業の歴史を掘り起こす作業に近くなります。
例外処理には、当時の判断が残っている
ERPの運用では、例外処理が悪いものとして扱われがちです。
標準化できておらず属人化し手作業が残っている。そうした状態は、確かに見直すべきです。ただし、例外処理を見つけた時点で削除対象と決めてしまうと、移行後に困ることがあります。
月末だけ実施する確認や特定の取引先にだけ必要な帳票の出し分け、障害時にシステム担当より先に業務部門へ連絡するルールといった対応には、過去に起きたトラブルや、現場で守る必要があった約束が埋め込まれている場合があります。
江崎グリコは、2024年4月3日に切り替えた基幹システムで障害が発生し、チルド食品の出荷業務に影響が生じたと公表しました。その後、段階的に出荷を再開し、同年11月5日出荷再開分をもって、障害発生前の全品出荷状態へ復旧したとしています。公開情報だけから原因を単純化することはできませんが、基幹システムの切り替えが、日々の事業運営に大きな影響を及ぼし得ることは、この事例からも分かります。
移行プロジェクトで問うべきなのは、「例外があるか」だけではありません。
その例外が生まれた背景には、誰を守るための判断があったのか、どのような業務上の失敗を避ける意図があったのかを確認する必要があります。また、それが単に現場の負担を増やしているだけなのか、それとも廃止する前に代替手順を整えるべきものなのかも見極めなければなりません。
こうした問いを置くことで、例外処理は単なる技術的な負債ではなく、次の業務設計を考える材料になります。
AI支援型の移行が進んでも、業務の背景までは自動で移らない
移行作業の自動化は進んでいます。
2026年5月、SAPとPalantirは、SAPの移行・モダナイゼーション支援とPalantir AIPを組み合わせ、AI支援型のデータ移行を進める提携強化を発表しました。Accentureも共同イノベーションパートナーとして位置づけられています。複雑なデータ移行を速く、より安全に進めるための取り組みとして、AIが移行支援に入る場面は今後も増えていくでしょう。
ただ、AIが設計書、問い合わせ履歴、手順書、会議メモを整理できるようになっても、それだけで企業の記憶を理解できるわけではありません。
文書に書かれている内容と、現場で実際に守られている判断は一致しないことがあります。古い手順書が残っている一方で、担当者間では別のやり方が定着している場合もあります。会議メモに記録されていない前提が、特定の人の経験にだけ残っていることもあります。
AIは、散らばった情報を比較し、似た事象や繰り返し出てくる論点を見つける補助にはなります。
一方で、その情報を移行対象に含めるべきか、標準化すべきか、廃止してよいかを決めるのは人です。業務部門、情報システム部門、運用担当、外部支援会社が、それぞれの立場から確認しなければなりません。
生成AIやRAGを使って資料を整理する場合も、顧客情報や営業秘密を無自覚に扱わないことが前提です。IPAは、クラウドAIへ営業秘密を入力しないことや、RAG利用時に情報を安易に混在させないことへ注意を促しています。便利な検索環境を先に作るのではなく、何を対象にし、誰が見られ、どの契約や規程に従うのかを決める必要があります。
現場を知る人の役割は、業務の背景を翻訳することにある
ERP移行では、技術者だけでも、業務部門だけでも進めにくい場面があります。
業務部門は、なぜその処理が必要なのかを知っています。しかし、それがシステムのどこに影響しているかまでは見えないことがあります。情報システム部門は、設定や連携の構造を把握していますが、例外処理が現場でどのように使われているかを把握し切れないことがあります。
そこで必要になるのが、業務とシステムの間にある説明を翻訳する仕事です。
「この帳票は必要です」と言われたとき、必要な理由を聞く。
「この承認ルートは残したい」と言われたとき、誰が何を確認しているのかを確かめる。
「月末だけ触れないでほしい」と言われたとき、どの処理とどの責任がつながっているのかを整理する。
現場に入る人材や運用支援会社には、こうした背景に触れる機会があります。
ただし、その経験を顧客の外へ持ち出すことが価値なのではありません。顧客の中にある業務理解を、よりよい引き継ぎ、運用改善、移行後の安定稼働へ戻せるかどうかが、支援会社に求められる役割です。
移行を成功させるために必要なのは、「現行を知っている人」を囲い込むことではありません。その人の頭の中にある判断を、顧客自身が次の運用でも使える形にして残すことです。
SAP移行前に確認したい「企業の記憶」5項目
移行対象を整理する際は、マスタや帳票の一覧と並行して、次のような点を確認しておくと、後からの手戻りを減らしやすくなります。
例外処理が存在する理由
手作業や個別対応が残っている理由を、単なる非効率として片付けずに確認します。過去の障害、取引先との約束、法令対応などが背景にある場合があります。標準化しようとしても残った業務手順
過去に統一や簡素化を試みたものの、戻された手順がないかを確認します。失敗した理由には、次の設計で避けるべき条件が残っています。月末・決算・締め処理など、変更リスクの高い時期と作業
通常時には問題がなくても、特定の時期だけ業務量や確認手順が変わることがあります。移行やテストの計画にも影響します。障害時の連絡順序と、顧客が重視する説明の仕方
障害対応は技術的な復旧だけでは終わりません。誰に、どの順番で、どの粒度で説明するかという運用も、長年の関係の中で形づくられています。特定の担当者に依存している判断と確認作業
「あの人に聞かないと分からない」という業務を洗い出します。属人化を責めるのではなく、何を知っているのかを一緒に整理することが出発点になります。
移すべきものを、移行プロジェクトの前に見つける
SAP 2027年問題を、保守期限だけの話として扱うと、移行は急ぐほど危うくなります。
本当に難しいのは、新しいシステムを選ぶことだけではありません。現行業務の中に残っている判断の理由を見つけ、不要なものは整理し、残すべきものは次の運用へ引き継ぐことです。
データは移せます。
しかし、「なぜこの処理があるのか」「なぜこの順番で確認するのか」「なぜこの時期だけ触れてはいけないのか」といった理由は、意識して掘り起こさなければ移りません。
移行前に必要なのは、仕様を集めることだけではなく、企業がこれまで何を守ろうとしてきたのかを確かめることです。
その整理ができていれば、新しいERPは単なる置き換えではなく、次の業務をよりよく回すための基盤になります。
移行計画の前に、現行業務の背景を整理する
ERP移行では、マスタや帳票、インターフェースを洗い出すだけでは、移行後の業務を安定して回せないことがあります。
例外処理が残った理由、月末や決算期だけ必要になる確認、障害時の連絡順序、特定の担当者に依存している判断。こうした情報は、設計書やデータ一覧だけでは把握しきれません。
ディーシステムでは、SAP・ERPの運用支援で蓄積した知見をもとに、現行業務の整理、問い合わせ・障害記録の分析、属人化した判断の可視化を支援しています。
移行対象を決める前に、何を残し、何を見直し、どの判断を次の運用へ引き継ぐべきか整理したい方は、ご相談ください。
【ERP移行前の業務整理について相談する】
関連記事
ERP導入後は、どんな仕事が続くのか。運用保守で行う8つの業務
移行後の安定稼働を支える、問い合わせ対応、障害対応、変更管理などの実務を紹介しています。
製薬業界のヘルプデスク支援から見えた、知識資産経営の可能性
問い合わせ履歴や現場の判断を、組織の知識資産として活用する考え方を紹介しています。
