top of page
P-01.jpg

DX、SAPシステムの移行などに必ず付きまとう予算の壁。
経営陣への説明やスムーズな予算承認のためには、どんなアクションが必要なのか?
大手サービス企業のプロジェクトチームのみなさまがお悩み相談にやってきました。









KT係長:S/4HANA移行の具体的な予算を見積るにあたって何か工夫されたことはありますか?
JSUG加藤:アセスメントをまず実施して、そのうえでPoCを上手く活用して、現システムの評価やコストの全体像を把握したことですかね。
KD担当部長:PoC のイメージといえば、一つの機能をやるにあたって検証するイメージがあります。

JSUG加藤:今回会計だけではなくて、人事やグループ会社の一部業務システムも対象だったのですが、ワンインスタンス、つまりひとつの同じ環境で全て稼働しているので、やるなら一斉にやらなきゃいけなかった。だから、日頃から付き合いさせて頂いてITパートナー企業の1社でサンドボックス環境を作っていただいて、Azureの上に一部現状のECC6.0をコピーして、実際に最低限だけS/4HANAをストレートコンバージョンでやってみました。プログラムの改修の部分も全てをやるのではなくて、影響ありそうなところだけを部分的にやってみたんです。その際にPanaya Japanさんのアセスメントサービスを使いました。アセスメントとS/4HANA化するときにコードを自動修正する機能を活用して、効率化を図れないか検証しました。そして、この結果をパートナー会社に公開して、「このボリュームだったら、この程度の規模の改修で済みそうだ」というのを共有して体制を組んでもらいました。どんなスキルを持っている人が何人ぐらい必要で期間的にはどれくらいか。そうやって予算や体制、スケジュールを組んでいきましたね。

KT係長:PoC自体はどのくらいの期間でできるようなものなんですか。

JSUG加藤:3ヵ月くらいでしょうか。PoC自体はすでに環境がAzureにあったのでそのデータをコピーして環境の準備をして1カ月弱、加えて2カ月ぐらいでざっとやれました。

KT係長:すごい効率的な方法だと思います。非常に参考になります。その充実した材料を見せていただいたらベンダーさんもかなり具体的な検討ができますよね。

JSUG加藤:そうですね、全体の作業量や、今回影響のある改修範囲、移行にあたっての問題はここで、こういったコストがかかる。事前に明らかになったので、そういったものは予算審査の時にも説得材料になりました。

IE次長:往々にして、開発工数なんかで予算が膨らみがちですよね。こちらも「何が起きるか分かりません」と言われると追加予算をとらざるを得ない。







JSUG加藤:PoCの結果の資料がここにありますが、まずアセスメントでは現状のSAP資産の総数や利用状況、特に利用頻度等々が棚卸しされます。その中から今回のS/4HANAのソースと見比べて移行に影響があるトランザクションがどれだけあるかが、ざっと出てくるような形になっています。標準機能ではまず、アクティブ状態になっている総数が2616トランザクション、そのうち未使用620トランザクションありますよと教えてくれました。

IKグループリーダー:未使用ってけっこうありますね。

JSUG加藤:もっとびっくりしたのがアドオンのところです。本当に細かい単位に出てくるのですが、自分が思っていた以上にアドオンの数も多くて、更にその過半数が使っていませんと出てきて正直非常にショックでした(汗)。さすがにびっくりして、上司への言い訳の為にもいろいろと詳細調査したのですが、実はSAPを導入する際にFI(財務会計)やRE(不動産管理)モジュールの領域にテンプレートを購入して被せていたのですが、テンプレートは当然ながらすべてアドオン扱いで、我々が購入したテンプレートの機能を全てつかっていたわけではないのでそれが未使用として多く含まれていました。もちろんそれだけではなかったですが(笑)。

JSUG福嶌:実はアドオンの4割くらいがほとんど使われてなかったという事実も出てきたりしましたね(笑)。

IE次長:そういったものも含めて概算見積り出してもらうと、とんでもない予算が出てきてビックリしますよね。

JSUG加藤:アセスメントやPoC実施前に、ざっくりと一度概算で移行費用を見積もってもらった事があるのですが、想定をはるかに上回る見積が出てきました。そういった経緯もあってアセスメントとPoCをやって作業内容を精査したんです。PanayaのアセスメントではS/4HANAになったら標準機能でなくなる機能、消失しないけれど一部影響があるもの、コードの修正が必要な部分などのリストがでてきます。ここから我々もどう修正するかパートナーと一緒になって勉強して、何よりも我々自身がS/4HANA化の影響や作業内容を理解して、パートナーさんと共有していった感じです。あと、メインベンダーさん1社だけでなく、マルチベンダー方式を採用し、各ベンダーさんの強みを生かして役割分担を決め、体制をスリム化すると共に、より確実に達成出来る体制を構築しました。

MF主任:作業内容を明らかにして、やることを絞って現実的な費用にしていったんですね。

JSUG加藤:やはりベンダーさんはこちらが何も分かっていない状態で見積りをお願いすると、全部盛りで持ってくる(笑)。しかし、予想以上の結果でS/4HANAに持っていく範囲も狭められたし、工数、予算もかなり減らせたかなと。

JSUG加藤:アセスメントは本当に重要でSAPさんが用意している標準アセスメントもありますが、今いろいろな会社さんからアセスメントサービスがでているので、パートナー企業さんとどのアセスメントツールやサービスを使っていくべきか、相談してみるのもいいと思います。現行システムのムダもよく見えてくる。我々が活用したPanayaだとアドオンとか標準モジュールとか1年以上使っていないトランザクションとかざっーと出てくるんです。特にアドオンだったら、使っていないものは移行・改修対象から外す判断ができる。全部の資産を移行するのではなく、断捨離して移行できるんです。また極端に使用の少ないものもユーザー部門と交渉して業務での活用を止めてもらうとか見直しをしました。そういった部分にもアセスメントは活用できますね。これに基づいて予算や承認までの道筋を立てるのはありだと思います。

IE次長:御社でこれをやられたっていうのは、それがすごいなと。アイデアも一緒にやられたベンダーさん。それは貴重なノウハウですよね。実証実験付きですからね。すごくありがとうございます。ここまで教えていただいて恐縮です。

JSUG加藤:さらにこれは稟議審査の資料ですが、中には2027年まで待たずにS/4HANAにしたほうがいい理由を会社の成長スピードの合わせるという点やサーバーリプレース期限や費用などを絡めて展開していますね。だから今、S/4HANAにさせてくださいという流れです。

IE次長:大変貴重なものをたくさん拝見させていただきまして光栄です。いろいろお話を伺って、いろいろ光が見えました。まずはシステム移行の方針をしっかり練って、今日の話を生かしながら方々にアプローチしていきたいと思います。本日はお時間ありがとうございました。




<< To the first part
bottom of page