[新製品・サービス]

2015年2月17日(火)田口 潤（IT Leaders編集部）

リスト

　そこでS/4 HANAである。HANAの利用を前提に、SAP ERPのプログラムコードのうち400万行をゼロから書き換えたという。同時にデータモデルを刷新し、サテライトシステムを含むSAP Business SuiteのDBMSをHANAに一本化した（図2）。

図2：DBMSをHANAに統合
拡大画像表示

　例えば、SAP BWの現行版は、SAP ERPのDBとは別にDBを備えている。これをS/4 HANAでは統一することで、プログラムとデータの両方をシンプルにした。例えばERPとCRMのデータ連携の負荷を40％削減したり、物理インスタンスも削減したりする。一方でSAP ERP独自の開発言語である「ABAP」をサポートするなど、一定の互換性は確保している。

　だが、それにしてもなぜHANAなのかという疑問は残る。シンプルに作り直すことが重要であるにしても、オープン性を犠牲にするのはどうなのかといった点だ。これに関しては「（多くの分野で競合する）Oracleの影響を排除するため」という見方もあるが、そうではないようだ。

　SAPは大きく2つの理由を挙げる。（1）DBMS側で処理するストアドプロセジャーが使いやすくなりシステム性能を高められる、（2）今日のオープン性は、DBMSなどのプラットフォーム非依存ではなくAPIの開放を指す、である（関連記事）。

　これは、垂直統合型システムと同様の考え方。アプリケーションの世界でも、例えばSalesforce.comやGoogle AppsといったSaaS（Software as a Service）では、DBMSを選べないし、そもそも誰も気にかけない。ERPソフトも同じというわけだ。

　実際、垂直統合の効果は小さくない。既存のSAP Business Suiteでは、生の明細データを処理するのに中間集計やインデックスのテーブルを作る。大半の処理をインメモリーで処理するにしても、性能には限界がある。

　これに対し、SAPジャパンは発表会で、「593GBのデータ容量をHANAにすることで、（中間テーブルをなくすなどして）120GBにできた。S/4 HANAなら42.4GBになり、1年かけてエイジングすると8.4GBにできる」ことを示した（図3）。データ量は、おおむね10分の1、処理性能は3〜7倍になるという。

図3：S/4 HANAにおけるデータ量の削減
拡大画像表示

　同発表会でのデモでは、2億5000万件の売り上げデータを即座に集計し、年度比較や地域別、売上推移と旅費の推移を直感的に分析できる特徴を示した。「今現在の売上推移と旅費の比較も瞬時にできる。OLTPとOLAPを統合したメリットであり、業務のシンプル化と、それによる経営への貢献を可能にする」（SAPジャパン）とする。