Twitter
Facebook
Hatena
SAP 2025年保守切れ対応とDX推進の両立について考える(後編)

前編では、2025年保守切れ問題を抱えるSAPユーザー企業様のとるべき方法を中心にお話ししました。後編では、SAPユーザー企業様が保守切れへの対応を行いつつ、いかにDXの実現を両立させるかについてお話しします。

DXによる労働生産性の向上を目指す

前編では、コロナ収束後の景気回復による人手不足に対応するため、DXに取り組む必要があると述べました。しかし、本コラムを執筆している時点(2022年3月)においては状況が一変し、コロナは収束するどころか爆発的に蔓延している状況です。

このコロナ感染者の増加により、さらに人手不足が発生し、飲食業をはじめ、小売業、建設業がその影響を受けています。このような労働集約型サービスは、コロナの状況にかかわらず人手不足となるため、生産性の向上が必要です。つまり、コロナが収束しようと拡大しようと、以下の図式が成り立ちます。

・ コロナ収束 → 景気回復 → 人手不足 → 生産性向上が必要
・ コロナ拡大 → 感染者増 → 人手不足 → 生産性向上が必要

前編で述べた通り、日本の労働生産性はOECD加盟35カ国の中では21位、G7各国の中では最下位です。(総務省:「日米比較を通して日本の労働生産性向上の方策を考える」より)また、諸外国に比べて日本の平均賃金がバブル期と比較して上昇していないのは、労働生産性が低いことに原因があるとの指摘もあります。よって、日本企業は早急に生産性向上に取り組む必要があり、DXは生産性向上のための有効な方策の1つと言えるでしょう。

※ 参考:平成29年度 年次経済財政報告 
「技術革新と働き方改革がもたらす新たな成長」 第1章 緩やかな回復が続く日本経済の現状 
第1節 今次景気回復局面の特徴 3 四半世紀ぶりの人手不足感の高まり
(6)バブル期との労働指標の比較より

レガシーからの脱却でDXを実現

少々古い引用になりますが、ガートナー社の 「ポストモダンERP」コンセプトの戦略ロードマップによると、今後は第4世代のERPとして、疎結合型のクラウドとオンプレミス・アプリケーションのハイブリッド連携が続くと予想されています。

従来の基幹システムの導入は、ユーザーの業務内容に沿って行われていました。すなわち、要件定義フェーズで、業務内容と導入する基幹システムとのFit & Gapを行い、Gap部分についてはアドオン開発を行うものです。

この方法だと、システムを既存の業務内容に合わせるために多くのアドオン開発が必要とされる場合も多く、標準仕様から大きく変更された基幹システムは柔軟性を欠き、バージョンアップの対応も手間がかかってしまうことがあります。

この要件定義の方法を進めるのであれば、疎結合型ERPでなければ急速に変化するビジネスニーズに対応できず、周辺システムとの連携も困難となり、システムの運用コストが膨大となってしまいます。これでは生産性の向上どころか、悪化させる原因となります。

DXを実現するには、基幹システムと周辺システムが柔軟かつ迅速に連携できることが必要です。そのためには柔軟性を欠くレガシーから脱却し、疎結合型ERPの導入が急務となります。レガシー化した従来の基幹システムの見直しを早急に行わないと、経産省の「DXレポート」で指摘されているように、2025年の崖から転落してしまうことになります。

※経産省 DXレポート ~ITシステム「2025年の崖」克服とDXの本格的な展開~

レガシーシステムの技術的負債について

従来の基幹システムは安定稼働しているため、一見すると問題がないように見えますが、「技術的負債」が隠れていて、DXの実現を妨げる要因になっています。

ここで言う技術的負債とは、「短期的観点でのシステム改修を繰り返した結果、長期的に保守・運用費が高騰すること」(経済産業省 デジタルトランスフォーメーションに向けた課題の検討より)であり、本来不必要であった保守・運用費を支払い続けることを、一種の負債ととらえています。短期的な観点でシステムを開発し続けた結果、カスタマイズやアドオンが増加し、長期的に保守費や運用費が高騰している状態となってしまいます。

よく例え話にされるのは古い温泉旅館です。古い温泉旅館では、長年の増築で複雑な構造になっていることがあります。1階のフロアから迷路のような渡り廊下を越えるといきなり3階になっていて、自分はいったいどこを歩いているのかわからず迷子になってしまいます。そこで、旅館のスタッフに「自分は今どこにいるのか」と尋ねますが、案内を聞いてもピンときません。そんな状況を温泉旅館のオーナーもなんとかしたいのですが、複雑な構造ゆえに維持費が高くかかり、建て替える費用も捻出できない状態となっています。

この例え話を基幹システムに置き換えるとわかりやすいかもしれません。長年に渡りユーザーからのシステムの仕様変更の要求に応えた結果、基幹システムが複雑な構造になっています。さらに仕様変更を要求されても、どこをどう変更していいのか、どんな影響が出るのか、誰も把握できない状態です。そのシステムを維持する保守・運用コストも高額です。DXを目指すためには、現行の基幹システムを入れ替えざるを得ないのですが、現状維持だけで手いっぱいで、新しいシステムの費用のことを考えると今すぐに実行することは困難な状態です。

技術的負債は過度なカスタマイズやアドオンが原因

基幹システムが複雑な構造になってしまった原因は明白です。ユーザーの仕様要求にきめ細かく対応した過度なカスタマイズやアドオンに原因があるからです。複雑な構造の基幹システムは柔軟性を欠き、急速に変化するビジネスニーズに対応できず、周辺システムとの連携が困難になり、その結果としてDXに対応できない状態になります。

DXを目指して基幹システムと周辺システムを連携するためには、将来にわたってERPのもつ標準機能を利用し続けることを前提に、基幹システム自体のアドオンを極力排除するべきです。そのためには、要件定義ではあえてGap分析を行わずに、ERPの標準機能を使い倒すにはどのようにすればよいかの観点、すなわちFit to standard アプローチで要件定義を行います。

S/4HANAへの移行とDX対応は同時に行う

日本の古いことわざに、「二兎を追う者は一兎をも得ず」というものがあります。しかし、保守切れ対応を迫られていて、かつ、DXの対応も同時に行いたいSAPユーザー企業様は、ぜひ二兎を追って下さい。その方が確実にDXを実現できます。

このことを証明するためには、まずは一兎ずつ追う方法、つまりS/4HANAの移行を行ってからDXの対応を行う場合について見てみましょう。この場合、S/4HANAの移行時にはまだDX対応を行わないわけですから、現行踏襲型で移行が実施されます。移行がBrownfield(システム・コンバージョン)の場合は、ERP 6.0と移行後のS/4HANAの間では、実現範囲に差がない状態となります(図1)。

S/4HANAへの移行がGreenfield(新規導入)の場合は、Fit to Standardアプローチで移行するため、現行のアドオンの一部をS/4HANAの標準機能に置き換えることが可能です。よって、アドオンはある程度削減されると想定できます(図2)。

S/4HANAに移行した後、現行踏襲型で導入したS/4HANAにDX対応を行います。既に、S/4HANAのカスタマイズは現行踏襲型で完了してしまっているため、新たな要件となるDX対応部分のほとんどはアドオンになる可能性があります(図3)。

それでは次に、二兎を追う方法すなわち、S/4HANAへの移行とDX対応を同時に行う場合について見ていきましょう。この方法では、S/4HANA移行は現行踏襲型ではありません。DXのために現行のビジネスプロセスそのものの見直しが必要になるため、S/4HANAの機能を最大限活用し、必要なアドオンのみが実施されます。その結果、Fit to Standard の効果も最大化され、アドオンは逆に最小化されます(図4)。

S/4HANA移行後にDX対応を行う2段階方式(図3)と、S/4HANA移行とDX対応を同時に行う方式(図4)を比べてみますと、Fit to Standardの効果、アドオンのボリューム及び、導入期間短縮の3点において、同時に行う方式にメリットがあることが分かると思います。しかも、S/4HANAへの移行後にDX対応を行う2段階方式の場合、古いプロセスがアドオンのまま残ってしまう可能性があります。(図5)

現実的には、このように明確な差は出ないかもしれません。しかし、S/4HANAへの移行とDX対応は同時に行う、つまり二兎を追うべきということに納得いただけたのではないでしょうか?

DX支援サービスのご案内

当社イデア・コンサルティングでは、お客様のDXを支援するためのコンサルティングサービスを展開しています。特に、中堅企業様を対象としたテーラーメイドなきめ細かいサービスは好評をいただいています。

DX支援サービスに関するお問い合わせはこちら
DX支援サービスに関するパンフレットのダウンロードはこちら

イデア・コンサルティング株式会社について

ITコンサルティング(イデア・コンサルティング株式会社)
コラム  : https://service.ideacns.co.jp/column/
サービス : https://service.ideacns.co.jp/service/
導入事例 : https://service.ideacns.co.jp/case/

この記事の執筆者

板井 実Minoru Itai

イデア・コンサルティング株式会社
SAP推進部
部長

SAP デジタルトランスフォーメーション