企業の成長を支える基幹システムは、多くの課題に直面しています。特に2027年のSAP保守期限の問題などにより刷新の必要性が高まる一方、業界の人手不足といった市況変化が起きています。ケンブリッジ・テクノロジー・パートナーズによるセミナー「『後悔しない』基幹システム刷新の走り出し方～これからの基幹システム刷新～」で行われたセッションの前半を紹介する当記事では、特にERPからERPへの乗り換え時に発生するリスクや注意点など、基幹システム刷新プロジェクトにおける“落とし穴”を詳細に解説します。
このコミュニティのログ一覧はこちら基幹システムを取り巻く環境
滝川佑次氏（以下、滝川）：では改めて、「『後悔しない』基幹システム刷新の走り出し方」ということで、私と阪田からいきたいと思います。
本日のねらいは、基幹システムの刷新が走り出したあとに「これを知っておけばよかったなぁ」などの後悔がないように、我々が重要だと思っているポイントを厳選していくつかお伝えしたいと考えております。
ラインナップは下に書いてあるとおりです。基幹システムの刷新を検討するために、我々が置かれている環境を説明して、こんなことがあって、こんな内容に気をつけていますといった具体例をご説明できればなと思っております。
さっそく、1つ目のテーマです。前提として、基幹システムを取り巻く環境から話をしたいと思います。
まず刷新を考える時に、「今ってどうなっているの？」と。SIの状況、市況を含めてプロジェクト計画を作っていかないと大変なところがあるので、ここから入りたいと思っています。
まずはIT予算なんですけども、傾向としては、各社増加傾向にあるかなと思っています。理由としては、老朽化している基幹システムの機能改善や運用に関わる人件費やライセンス料の増加、円安による値上げなんてところもよく聞こえてきています。
あとは、コロナ禍を通じてリモートワークを進めるための基盤整備ですね。セキュリティだったり、ネットワーク運用、電帳法対応、諸々の環境整備でデジタル化の加速によってIT費用が増加している状況だと思っています。
みなさんの中に、まさにこの問題に直面して頭を抱えていらっしゃる方もいるかと思います。物価高がニュースでも話題ですけれども、ITシステムにおいても同じような状況で、IT予算が会社の中でも問題視されがちな状況だと思っています。
基幹システムやメンバーの「期限切れ」問題
滝川：続いては、保守切れの問題です。基幹システムの保守期限やハード、ミドルウェアの保守切れラッシュが各社で発生していて、なおかつシステム部門のみなさんが高齢化したり、勇退が間近だったりという話もよく出てきます。
そのあたりを補うために外部リソースに相談したところ、人が枯渇していて……という状況が情報システム部門に畳み掛けられていると思っています。
みなさんは、基幹システムなどの大規模システムをオンプレミスで導入している場合が多いと思います。大量のハードウェア機器があるということで、いっぺんにそれらの機器がEOSLを迎えることがよく問題視されていると思います。
前回の基幹システムの刷新を支えてきたメンバーも、10年使っていると、もういい年齢、ポジションになってきて、人の期限も迫ってきてしまいます。
業界の状況ですと、SAPの2027年問題を通じて、大手SIerさんのSAP部隊やSE要員の取り合いが始まっちゃっていまして。そもそもSAPを入れられていると、そこの技術者確保が問題になってくるのが業界としても問題視されている点だと思っています。
SAPさんについては国内で2,000社くらい導入されているという発表があります。そこに向けて、全国の2,000社が2027年、2030年に向けて刷新を進めている状況なので、そりゃ人もいないよねと思います。
このあたりの懸念を持って、このセミナーに登録いただいた方もいらっしゃると思います。なので、こういった観点で議論を進めていければと思っています。
もう1つ、次回の基幹システム刷新はどうなるのかということなんですが。我々としては、前回のERPパッケージの導入を視野に入れたBPRという取り組みから、ERPパッケージの更改を前提としたBPRを進めるための基幹システム刷新プロジェクトになると考えています。
これは、表現がなかなか悩ましいんですけど。新規で入れるのか、更改かといった点が違うかなと。
スクラッチ開発された個別のシステム群をSAPやオラクルのERPパッケージに切り替える、ということが、2000年頃にはあったかなと思っています。当時はBPRという言葉が併せて流行って、基幹システムを統合ERP、BPRパッケージに入れていきましょうという流れがありました。
このときに導入したERPパッケージが、だいたい20年経って、さらにSAPの2027年問題や、経産省が警鐘を鳴らして話題になった「2025年の崖」もありました。基幹システムの刷新ラッシュが各社で始まっているところだと思っています。
基幹システム刷新プロジェクトにおけるポイント
滝川：直近で、何社かから基幹システム刷新直後に大問題になって出荷が……みたいなニュースが出てしまったように、多くの会社で基幹システムの刷新が行われていることもあります。
そのときの会社も、なにかしらERPからSAPへの流れだったのかと思います。そういった意味ではERPパッケージからERPパッケージへ刷新という流れは、ほぼ変わらずみなさんのところでも発生すると思います。
ERPをばらしてオンプレ個別システムに戻すことは、まぁそうそうないと思います。なのでまずは、ERPパッケージの更改にフォーカスを当ててお話をしていければと考えています。
このあたりの、基幹システム刷新のプロジェクトにおける特徴となるポイントを今日のセミナーではそれぞれ解説していきたいと思います。
先のページでご説明したとおり、前回の基幹システム刷新と構築ではレガシーからBPRを経てのERP導入に焦点が当たっていました。しかし、今回は基幹システムのERPのバージョンアップ、または更改に焦点が当たります。
これまで利用してきた基幹システムの、刷新バージョンアップと状況が異なってくることを、十分理解していないと、いろいろな問題にぶちあたってしまいます。
まず、Aについて。前回の基幹システムの刷新では、個別のスクラッチをERPに統合していました。今回は何度も申し上げているとおりERPからERPなので、同じもの使っているのだから簡単でしょ、と捉えがちなのですが、実はそこに難しさがあると思っています。
BとCは、Aを進めるために考慮すべき点です。前回のシステム刷新と大きく異なる点のため、特徴としてお話ししなければいけないと思っています。
続いてBの売り手市場についてです。このあたりは業界が長い方はお分かりのとおり、以前は買い手市場でした。しかし冒頭でお話したとおり、現在はSAPや人の問題もあって、人手不足なのが市況としてあります。
なので、売り手市場ということを理解した上で、じゃあ刷新するために我々はどういう行動を取らなきゃいけないのかを考慮すべきだと思っています。
社員は「業務への影響」を語るのが難しい
滝川：Cはスクラッチのシステムをベースにしていたり、対応していなかったりする業務をどう統合するかという話をするために、Fit&Gapが主流に行われていました。前回は、ERPパッケージで合わない部分は業務に合わせるためにアドオンやスクラッチをしながら互換していました。
ERPパッケージがどういうもので、何に差があるかを理解することが、システム刷新プロジェクトの肝だったんです。今後の刷新については、Fit to Standardという言葉を聞いたことがあると思いますが、システムに業務を合わせていくことが極力求められるタイミングに来ていると思います。
システムを使うために、今度はどう業務を工夫するのかを議論しないといけないというのが、次回の更改に向けたポイントです。
社員はすでに会社に入った時からERPシステムがある状態で業務をしています。なので、現在のシステムの操作はわかるんですけど、背景にどういう業務があって、なぜこの業務をやっているんだっけということが理解しきれていない部分もあるので、業務への影響を語るのが難しくなっているのかなと思っています。
そこを踏まえて、じゃあどういう刷新と体制にするかを考えていくことが肝になってきます。
そう考えると、前回の基幹システム刷新よりも簡単というわけではなく、別物のプロジェクトとして、改めて視点を変えて取り組まなければいけないと我々は考えています。このあたりのポイントについては、このあと詳しくお話をさせていただきます。
今日お話することと、しないことを改めて整理します。今回のセミナーでは、プロジェクトの現場で我々が実感した、得られた気づきを先ほどの3点に沿ってお伝えしていきます。
みなさんのプロジェクトの状況や会社の事情によって、多少の温度感の違いはあると思います。なので、1つの参考事例として捉えていただけると助かります。
今回のセミナーでは、一般的なプロジェクトマネジメントや、我々が他のセミナーで話しているような推進方法といった内容は盛り込まれていません。ちょっと特殊な事例の話題になりますのでご理解いただければと思います。
では改めて、具体的な話にいきたいと思っています。1つ目は、ERP to ERPです。このあたりを把握しなければいけませんので、まずは大前提から整理をしていきます。
ここから先はバトンタッチで、阪田さんお願いします。
「現行踏襲」でRFPをまとめるリスク
阪田祐介氏（以下、阪田）：ありがとうございます。「こんなことみなさんの周りで起きていませんか？ ご経験ありませんか？」という現場感のある生々しい事例で、実際にどう解決を図るかという話をしていきたいと思っています。
稼働中のERPパッケージがEOSL（メーカーのサポート終了）に近づいている状況を想定していただくと、1つの例として良いと思っています。このような思惑があったということで、ここにいろいろと書いています。
例えば、情報システム部門からすると、「ようやく安定稼働、運用してきたところなのに、またビッグバンか……」。ユーザーからすると、システムに慣れて業務をするのが前提なので、そうなると「今より悪くならない程度でいいんだけど」。
とはいえ経営側のみなさんからすると、「最新のERPに載せ替えるんだったらこういうことができたらいいよね」っていうことで、多少横文字にキャッチーな言葉を並べて、できるんじゃないかというご期待があったりという。
こういう視点や思惑がいろいろとある中で、いったん次期基幹システムの構想がスタートする。こういうものを取り込もうとするプロジェクトが始まるというのがまず1つです。
次のスライドにいきますと、そうなった場合によく「あれ、こんなはずじゃなかったのに……」という場面に出くわすんじゃないかなと。もしかすると、みなさんの中にも「うっ！」と思ってしまう方がいらっしゃるかもしれませんが。
例えばですけれども、このままでいいんだという話があった時に、現行踏襲という言葉を呪文のように使ってRFP（提案依頼書）をまとめてしまうと、後で見誤るリスクがけっこう高い開発計画になってしまう。蓋を開けると「現行って何だっけ？」と。そこから詰めていく話になることがあります。
下に書いてあるように、例えばその1つが、現行業務よりも現行システムの挙動が実は必要だったり、あるいは画面のレイアウトがこうでなければいけなかったり。そこを踏襲しようとすると、想定以上のアドオンやスクラッチが増加しちゃう、なんて話があります。
EOSLは“きっかけ”にすぎない
阪田：あとは、先ほど言っていたキャッチーな言葉、例えばデータドリブン経営、プロセスマイニングなどと書いても、結局は、具体的にそれで何がうれしくて、どうしたいのか、という話を構想レベルできちんと落とし込んでおく必要があります。業務要求をいきなり問われても、「はて、何を決めればいいんだ？」「正直そこまで大変なことをする想定ではなかったんだけど」となってしまう。
EOSLが来たから載せ替えようという話を最初にしてしまうと、そう思われてしまうこともあると思います。
次のスライドで、例えばですけれど、その落とし穴をよくよく考えた時のことを私たちなりに3つ挙げています。
1つは、EOSLはあくまできっかけなので、そもそもどういうゴールを目指すのかということを明確化する。きっかけを目的化してしまい、甘く考えていたというのが出発点です。
もう1つは、To Beの実現レベルまで。言ってみれば、それこそオンプレからクラウドなのか、あるいはどの業務領域をどう載せ替えるのか、そこまで構想はいらないでしょうと思っていた。そういう考え方もあるかなと思います。
最後は、現行踏襲や現行通りといった内容の意味合いをきちんと定義しておく。これは、どこまで言葉を定義するかによって、あとあとのリスクを当然低減できます。独りよがりになりがちな言葉をそのままにしておかない。
つまり、構想レベルから複数の解釈ができる状態にしておかない、ということが大事だと思います。
次のパートにいきます。その落とし穴を回避するために大事なことの具体策を私たちの考え方や進め方とともにご説明していきます。
ここの具体策は2つあります。ここでブレイクして、滝川さんにバトンを渡したいと思います。
端的なゴールステートメントだけでは不十分
滝川：具体策の1つ目は、関係者が納得できるゴール文への落とし込みです。全社の取り組みとなる基幹システムの刷新では、ゴールステートメントだけを端的に書くだけでは不十分だと思っています。
よく物の本などでスマートなゴールという話がありますが、これだけだと実は言葉足らずで伝わりにくいです。
システムの刷新は、IT部門だけでなくチャットにもいただいていますけども、業務部門にも理解を得られるように、さまざまな角度からゴールイメージをしつこく捉えて伝える仕掛けや工夫が必要になってきます。
なので、これからみなさんが取り組む大きな刷新についても、いろいろな関係者に伝わるような工夫を仕掛けていく必要があると思っています。
ERPからERPだからといって、IT部門に任せてしまうような経営層や現場の雰囲気は、実際これからお話する中身を踏まえると、やはりそうではありません。気持ちはわかるんですけど。業務部門の参加を巻き込めるようなゴール文にするための努力が必要だと考えています。
具体的にどうするのか？ ゴール文は、プロジェクトの結果やリリース後の状態をシンプルに書くだけではなくて、ゴールに至る背景、なぜこの取り組みをするのかといった内容を細かく表現する必要があります。
本来求めたい記載は、ここにありますとおり、ERPパッケージの標準プロセスに適合できるような業務改革を進め、〇〇年に業務とシステムを刷新する、のように。ちょっと極端な例で、ゴールだけではなくて背景も書いていますが、これくらい書いておくとイメージがつきますし、誤解を招きにくくなるんじゃないかと思っています。
Howの領域にまで踏み込んで書いていますが、今回のERP to ERPの取り組みでは、ちゃんとBPRに取り組む必要があります。ゴールは一文で済ませずにしっかり文章化して、かつ、補足資料も後ろに付けながら、なぜこの取り組みをやらなければならないのかを丁寧に伝える必要があります。
資料にある「ケンブリッジのご支援ポイント」については、我々はこういう支援をいろいろやっています。セールスポイントなので、ここを見れば、ケンブリッジにここを頼めば助けてくれるんだとご理解いただければと思っています。
山に上った先で何をしたいかが重要
滝川：話を戻しまして、よくプロジェクトは山に例えられますけど、ただ単純に頂上に登るだけじゃなくて、どういうルートで登って、さらに頂上で何が見えるのか、何をしたいか。ケンブリッジが推奨するゴールとして示す範囲というのは、そういうところまで盛り込みたいと考えています。
例文がありますけども、このあたりが細かくしつこく書いていくところです。なので「ERPの更新なんだから情シス主体でよろしく」と思われないように、これだけ大変でこういうことを考えないといけないんというゴールに盛り込むところまで書いていただけると良いと思います。
山を登って何をしたいのか。花を見たいのか、コーヒーを飲みたいのか、パーティーがしたいのか。そのくらいまでゴール文に盛り込むと、具体例が出てきますので、そこまで書いていただきたいと思います。
とは言いながらも、「じゃあそれをどうやって作るのか？」だと思います。その作り方のステップがありまして、グレーの矢印はたまに見かけるゴール作りのステップです。ここで言う2までのところで止めているケースというのは、みなさんのところでもありますか？
経営層からの発言を印籠のように掲げたものがゴール、といった状態にしないようにしていただきたいと思います。
ITに明るい経営者からすると、もう少し理解してズバッといろいろ言えるかと思うのですが、みなさんがそうではありません。多くの人にわかるように作っていかないといけないと思います。
ゴール作りについては、3つ目のステップにあるとおり、想定される施策や実現したあとのシステム像、運用、コストのイメージ作りまでした上で、それを踏まえてどういうゴールにするのかを言語化していただきたいです。「クラウド化します！」などのゴールをあっさりと定めるだけではなくて、なぜそれなんだ、というところまで議論していくのがポイントです。
基幹システムや個別システムをERP化した、前回の刷新の時のように統合パッケージをまとめるような大きなメリットがあると、業務のプロセス変更などの多少のデメリットには目を瞑ってもよかったと思います。
なんですけど、今回はERPが導入されている状態での更改なので、メリットだけじゃなくてデメリットの可能性も出てきます。そこまで踏まえてどういうゴールにすべきかをこのタイミングで明示しておくのが、今回のシステム刷新の肝だと思います。
抽象度の高い言葉をしっかり定義する
滝川：4つ目の箱は、これまで検討した結果を言い表せるゴールの一文の作り方です。3つ目のステップまででいろいろな角度からシステムをどうするのか議論をした上で、ここで作っていく、最終化していくイメージです。
プロジェクトの立ち上げのタイミングで仮のゴールをいったん決めていたとしても、検討の結果、見直して良いゴールにすべくチャレンジしていくのもありだと思っています。
抽象度の高い言葉の解釈を定義しておきましょうというのが、ゴール作りの注意点です。先ほど阪田から申し上げましたように、飛び交ういろいろな言葉の定義は大丈夫ですか？
先ほど挙げた「現行通り」という言葉についても、各階層の人が使うことで、その名が示す内容が違ってくることがあります。ToBeとありますけど、ここについても〇〇改善と言う人と、〇〇改革、〇〇変革で考え方や捉え方が変わってきますので、しっかりとこのタイミングで1個1個の単語が何を指すのかを議論していただきたいです。
特にSAPを利用されている場合は、現行で使われていたECCの画面と、今後検討されるS/4HANAやRISEの環境で使われる画面は大きく変わってきますので、同じSAPでしょと油断するとかなり痛い目を見てしまいます。言葉の定義を大事に、十分注意してゴールを作っていくことをのをこのフェーズでは検討いただきたいです。
次はERP to ERPのマップですね。今まで話をしていたところなのですが、BPRの必要性が、次回のシステム構成の刷新で発生してきますので、このような図を示しながら、何が変わるのかを考えていただきたいです。
かつての、統合するといった内容から、今後は個別開発ではなく、いろいろなシステムやソリューションを使いながら機能を作っていくことになります。この業務で使うためのBPRなどが出てくるので、この中心がバージョンアップされるかもしれませんが、システム全体の構成としては変わってくるので、油断せずに議論を進めていただきたいと思います。
ということで、2つ目のテーマにいきます。1つ目の感想などありましたら、ぜひ上げていただければと思います。ではここからはまた阪田さんにバトンタッチします。
PR
