今回のHelp Net Securityインタビューでは、MIGNOWのCOOであるGuilherme Joventino氏に話を聞きました。一部の大企業が2027年の期限を過ぎてもECCを使い続け、2030年までの延長サポートをSAPに支払う計画を立てている理由について解説してもらいます。インタビューでは、その選択にかかるコスト、予算よりも「業務停止への恐れ」がプロジェクトを停滞させることが多い理由、そして段階的な移行における最初の90日間で何が行われるのかを取り上げます。また、旧システムについて長年の知識を持つスタッフの処遇や、あらゆる品質ゲートをクリアしながらも本番稼働が難航した中米でのプロジェクト事例にも触れます。
2027年の期限を単なる「保険」として扱った企業の例を教えてください。それは具体的に、金額面、時間面、あるいは機会損失としてどれほどのコストになりましたか。
この話は、ロールアウト案件のクライアントから最もよく聞かれます。そのうちの1社、大手グローバルメーカーが少し前に相談に来ました。彼らはどの国がどの順序で本番稼働するかを定めた正式な企業ロールアウト計画を持っており、2027年はそもそもその議論の対象になっていません。理由は単純で、SAPは追加費用を支払う意思があれば追加年数のサポートを販売しており、2030年まで現状のまま留まることができるからです。大企業にとって、追加サポート費用は移行プロジェクト自体のコストに比べれば小さなものであり、日程に合わせてすべてを圧縮するよりも、ロールアウトの順序を守ることを優先したいと考えています。
ただし、それがどれほどのコストになったかについては慎重に述べたいと思います。まだ2027年に到達していないため、現時点で信頼できる数字を示せる人はいないと考えているからです。言えるのは、答えはほぼ完全にその企業がシステムをどう使っているかに左右されるということです。もしERPがイノベーション、新製品の発売、新しいビジネスモデルを支えているなら、たとえ請求書に表れなくても、遅延の1年ごとにコストが発生します。一方、システムが実質的に財務のバックオフィス業務にすぎない場合、リスクは実際のところ低いといえます。そうした業務プロセスは年ごとにほとんど変わらないからです。この変数こそが、待つことに何らかのコストが生じるかどうかを決めます。
とはいえ、実際に見られるパターンは一つの方向を指し示しています。SAPを戦略的に扱っている企業はすでに移行を終えています。待つことを選んだ企業は、ほぼ例外なくバックオフィスとしてシステムを運用している企業です。そのため、2026年の時点では財務的な影響を完全に測定できず、それが見えてくるのは今後のことになりますが、戦略的に活用している企業は先行したことによる実質的な価値をすでに得ていると確信しています。他社がまだ移行を計画している段階で、彼らはすでに新しいプラットフォーム上で構築を進めているのです。
現時点で具体的な数字が出ているのはサポート面です。SAPは保守を延長する際、標準のエンタープライズサポート料金に上乗せしておよそ2%を課しており、その料金自体もすでにライセンス価値に対する年間の割合となっています。100万単位のライセンスであれば年間およそ22%を支払っている計算になるため、延長は実質的なコスト項目ではありますが、それ単独で多くの企業の判断を覆すほど大きくはありません。だからこそ私たちは、これを期限直前の「保険購入」の問題にしてしまうのではなく、クライアントとともに戦略的な意思決定として位置づけているのです。
クライアントから「まだ移行の準備ができていない」と言われたとき、その言葉の裏にある本当の理由は何でしょうか。遅延は通常、予算の問題、人員の問題、それとも業務停止への恐れの問題なのでしょうか。その中で最も解決が難しいのはどれで、それはなぜですか。
予算が本当のボトルネックであることはめったにありません。それは単に口に出しやすい理由であることが多いのです。その裏にある、より一般的な要因は業務停止への恐れであり、具体的には、移行が事業にとって止められない何かを中断させてしまうという恐怖です。実際には、その恐れはごく具体的な数少ない場面に集中する傾向があります。決算日、繁忙期の業務ウィンドウ、すでに進行中の在庫やロジスティクスに関するコミットメントなどです。各チームは、システムが本番稼働した日に、スケジュールを動かせないタイミングで何かが壊れてしまうことを恐れているのです。
人員不足も現実の問題ですが、通常はもっと後になって表面化します。つまり、意思決定が下された後になって、過去10年、20年にわたって積み重なってきたカスタマイズの全容を社内で理解している人がいかに少ないかに気づくのです。
3つの中で業務停止への恐れが最も解決が難しいものです。安心させる言葉だけでは解消しないからです。この判断を動かすのは証拠です。同程度の規模と複雑さを持つ別の企業が、事業を破綻させることなく移行を乗り越えるのを目にすること、そして最も重要な業務ウィンドウそのものについて検証済みの計画を持つことです。その証拠がない限り、ビジネスケースだけではそのギャップを埋めることはできません。そこで私たちの実績が、どんな議論よりも大きな役割を果たすのです。
中堅企業における段階的移行の最初の90日間は、タスクレベルでどのようなものになりますか。
最初の90日間は移行そのものではなく、私たちが「プレプロジェクト」と呼ぶセットアップおよび探索フェーズです。そして私たちの経験では、この期間がプロジェクトの残りの成否を決めます。アップグレード案件の場合、期間はさらに短く、最初の30日間に近くなります。これらのプロジェクトはより速く進むためです。
最初のタスクは、手法そのものに関するナレッジトランスファーです。環境の準備から最終的な納品まで、コンバージョンがどのように行われるかをクライアントとともに段階的に確認していきます。単なる形式的なプロセスのように聞こえるかもしれませんが、これは私たちが持つ最大の成功要因です。すべての関係者を同じ手順に沿って足並みを揃えさせ、プロジェクトが停滞するのを防ぐからです。これによって私たちのAIが中断なく稼働できるようになり、本当の意味での高速化はそこから生まれます。テクノロジーがその本来の速度を発揮できるのは、周辺のプロセスが止まらない場合に限られるのです。
そこから先は技術面・機能面での準備作業に入ります。プロジェクトを詳細に計画し、プレプロジェクトで定義された内容に沿って環境を構築・設定し、対象範囲についての機能的な理解を築いていきます。ここではテスト計画も策定されます。どのプロセスを検証する必要があり、誰がそれを承認するのかを決めるのです。というのも、テストこそが本番稼働の静けさを左右する部分であり、コンバージョンがすでに走り出してから組織しようとするのでは遅すぎるからです。これが予定通りに進むかどうかを決めるのは、ほぼ常にクライアント側の要因です。クライアント自身の時間と関与、そしてプロジェクトを遂行するために必要な人員、インフラ、システムアクセスといったリソースの可用性です。
だからこそ私たちは、序盤の日々を手法の説明に費やします。クライアントがコンバージョンの仕組みを理解すれば、なぜプレプロジェクトが重要なのかも理解できるようになります。そうなれば準備作業はもはや余計な負担としてではなく、移行の一部として扱われるようになるのです。
移行完了後、旧ECCシステムを隅々まで知り尽くしていた人材はどうなるのでしょうか。企業はそれをあらかじめ計画しているのでしょうか、それとも慌ただしい対応になってしまうのでしょうか。
正直なところ、計画的に対応されるよりも慌ただしい対応になることの方が多いです。旧システムを最もよく知る人材は、たいていその知識が最も文書化されていない人でもあります。長年にわたってシステムの癖を回避しながら仕事をこなし、財務、ロジスティクス、レポーティングの間のギャップを手作業で埋めてきた経験が、その人の頭の中にしか存在しないからです。
よくある、そして示唆に富む例があります。長年にわたり、さまざまな部門からデータを手作業で集めて一つのスプレッドシートにまとめ、経営陣が統合された一つの数字を確認できるようにする仕事をしていた人物です。この作業にはかつて数日かかっていました。移行後、同じアウトプットが数分で得られるようになります。その人の旧来の仕事は事実上消滅しますが、それが得なのか損なのかは、企業がそれをあらかじめ計画していたかどうかに完全にかかっています。
これをうまく処理する企業は、そうした人材を早期に特定し、プロジェクト期間中は運用業務と移行チームのための「組織の記憶」役という二重の役割を担ってもらいます。そして手作業が自動化された後は、意図的により付加価値の高い分析業務へと配置転換します。一方、これを計画していない企業は、プロジェクトの途中でその専門知識を離職によって失ってしまい、なぜある特定のカスタマイズが存在するのかを説明できる人が他にいないために遅延を招くか、あるいはもはや必要のない役職にその人を留め置いてしまい、それ自体が静かなコストとなってしまいます。
技術的には成功したものの、それでも「残念だった」と言わざるを得ない移行プロジェクトはありますか。それはなぜですか。
思い浮かぶのは、中米の製造・流通企業です。結果的にはうまくいった関係で、彼らは今も私たちのクライアントであり、現在まさにアップグレードを実施している最中です。書類上、当初のプロジェクトは成功でした。納品も完了し、本番稼働もしており、私たちの手法におけるすべての品質ゲートをクリアしています。それでも私がこれを「残念だった」と呼ぶのは、本番稼働が本来必要以上に困難なものになったからです。そしてその理由は、テクノロジー自体とはほとんど関係がなく、すべてはプロジェクトを取り巻く環境がどれだけ準備できていたかにありました。
端的に言えば、環境がその規模のコンバージョンに見合った形でサイジングされていなかったため、本来1回で済むはずの本番稼働が2回に分かれてしまいました。また、クライアント側のチームは小規模で、日常業務と並行してプロジェクトを担っていたため、いくつかの業務領域におけるテストカバレッジは、当時私たちの誰もが気づいていなかったほど薄くなっていました。本番稼働直後の数日間に発生した問題は、ほぼすべてその領域に集中していました。
そこから学んだのは、本番稼働の質は本番稼働のはるか前に、準備によって決まるということです。私たちのAIはコンバージョンを予測可能なものにし、私たちの手法はその周辺のすべてを予測可能なものにします。スムーズな本番稼働には、その両方が必要です。コンバージョンがスムーズに見えるのは、環境が整い、テストが事業を支える業務プロセスを網羅しており、そのテスト結果が何かを物語る形で記録されている場合に限られます。クライアントがそれを自ら担うだけの技術的な深さと余力を持っている場合、本番稼働は静かなもので、通常は最初の数時間で1件か2件のチケットが上がる程度です。そうでない場合、それはキャパシティのギャップであり、それを早期に見抜いて埋めるのが私たちの仕事です。カバーされることを前提にしてはいけません。この案件でまさにそれを実行したからこそ、関係が続き、彼らがアップグレードで再び私たちを選んでくれたのです。だからこそ今、私たちはエンゲージメントの初期段階でレディネス(準備状況)の確認に十分な時間を費やし、テストフェーズには自社の人員を投入するようにしています。
組織は、コンバージョンにおけるテスト作業の大部分を自動化できるソリューションを探すべきです。狙いは、テストカバレッジを自動的に生成・実行し、何が検証済みかについて双方に真の可視性をもたらすことです。そうすれば、深い技術チームを持たない組織が、そのリスクを一手に背負い込むことがなくなります。そのような状況にある企業にとって、これは移行における最大の変動要因を、はるかに予測可能なものに変えてくれるのです。
翻訳元: https://www.helpnetsecurity.com/2026/09/21/guilherme-joventino-mignow-sap-ecc-migration/
