――SAP ERPからS/4HANAへの進化は、業務プロセスベースのERPからデータ中心のERPに変わったという理解は正しいですか？
以前の検索エンジンは、カタログのようなものがありそれを使って目的の情報を見つけるものでした。たとえばカタログには「ニュース」という項目があり、ニュースの中に「スポーツ」があるという形です。これに対し現在の検索エンジンは、サーチボックスに必要なキーワードを入力するだけです。それで自動的に情報を見つけることができます。エンドユーザーの操作に対し、高速に答えが返ってきます。
同じことがS/4HANAでも起きています。エンタープライズのアプリケーションの世界に、新しいサーチエンジンのやり方を組み込んだようなものです。以前のERPは、必要な答えをハードコーディングしていたようなものですが、S/4HANAではデータに対するアルゴリズムだけがあるのです。
受発注のシステムで売り上げを計上することを考えてみましょう。発注番号があり、それに対応する発注金額がERPには記録されます。ここから四半期ごとに売上金額をレポートするために、古いERPでは四半期分の売り上げをあらかじめ集計し結果を1つのレコードとして保持していました。
S/4HANAでは、集計をダイナミックに行います。四半期の集計結果などは、エンドユーザーが求めたときに瞬時に計算しスクリーンに表示できるのです。これができるので、たとえば期の途中で組織構成が変わり集計の単位が変更されるような場合にも、計算をやり直し結果を保存し直す必要はありません。かつてのERPでは、組織の変更に合わせ計算し直し、結果を保存するしかありませんでした。
シンプルなアーキテクチャになり、必要なデータをあらかじめ用意しておくのではなく顧客の要望に応じてデータベースから瞬時に引き出せる。これが大きく変わったところです。この変化により、過去だけでなく、今後どうなるかをシミュレーションしやすくなりました。これはシステムレコードがインテリジェンスを持ち、より良い意思決定をサポートできることにもなります。
日本だけではないアドオン問題
――日本ではERPにたくさんのアドオンを作り込んでいる現状があります。そのERPをアーキテクチャの異なるS/4HANAに移行するのは、ハードルが高くありませんか。既存のアドオンをどう扱うべきだと、SAPでは考えているのでしょうか？
アドオンがあるのは、日本だけではありません。これは世界共通の課題です。この課題に対し、SAPでは専任のサービスコンサルティングのチームを用意しています。そこが、顧客企業のアドオンを分析してアドバイスをします。すべてのアドオンを洗い出して分析し、本当にそれらのアドオンが使われているものかをまずはチェックします。
中には使われていないものもあるので、それについては排除を薦めます。次のステップでは、使っているアドオンの機能を比較し、S/4HANAの標準機能に置き換えられるものを探します。置き換えられるものは、アドオンをやめ標準機能を使うように推奨します。以前のERPにはなくてもS/4HANAには加えられている機能も多いのです。
最後のステップは、標準機能にはないアドオンの再考です。足りずに追加したい機能は、アドオンの形ではなくS/4HANAからは切り離しHANAプラットフォーム上に実装するようアドバイスします。S/4HANAとはAPIを使って接続することで、この機能は永続的に利用できるようになります。
アドオンを分離できれば、ERPの更新ごとにそれをどうするかで頭を悩ませる必要はなくなります。アドオンに引きずられることなく、常に最新のS/4HANAのイノベーションを利用できるのです。
――HANAプラットフォームとS/4HANAの開発はどのような体制になっていますか？ S/4HANAからHANAプラットフォームの開発チームに対し機能追加要求が出るようなことはあるのでしょうか？
開発の組織には、HANAプラットフォームもあればS/4HANAもあり、さらには買収したHybrisやSuccessFactorsのチーム、ユーザーインターフェースのデザインチームなどもあります。これらはミックスチームの体制となっており、すべてのチームが一緒になって開発を進めています。なので、それぞれのチームは、かなり密接に連携し開発を行っています。
――現状ではHybrisやSuccessFactorsなど買収した製品やサービスは、S/4HANAとは独立したサービスとなっています。将来的にこれらの機能がS/4HANAに取り込まれる可能性はあるのでしょうか？
われわれとしては、顧客企業がどのようにしたいかを聞き、それで将来の方針を決めています。その結果としてビジネスプロセスの統合はしていきます。SAPとしては、完璧なビジネスプロセスを構築したいと考えています。ビジネスプロセスは統合しますが、ソフトウェア的に統合しなければならないとは考えていません。
これからは、マイクロサービスのアプローチで行くことになります。マイクロサービスであれば、顧客は自分が必要なものを必要なときに選べば良いでしょう。これが実現できれば顧客の要望も随時取り入れられ、この方が顧客は自分たちのペースで使いたい機能を取り込むことができます。
すべてのモジュールを将来的にはHANAプラットフォームの上で動かし、その上でインテグレーションすることになります。そうすることで、すべての機能がシームレスに使えるようになります。
