[新製品・サービス]
業務を壊さずビジネスを「Disrupt」、SAP Business Suite 4 SAP HANAのインパクト
2015年2月17日(火)田口 潤（IT Leaders編集部）
移行計画を立てるか、しばらく待つか、それとも見送るか−−。SAPジャパンが2015年2月6日に発表した「SAP Business Suite 4 SAP HANA」は、同社製品のユーザー企業にとって悩ましい製品だ。インメモリーDBを核に内部構造を刷新するなど製品自体の魅力は強い。一方で、カスタマイズして導入している日本企業にとっては、移行の難度は高く、使いこなせるかどうかが問題になる。
そこで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ジャパン）とする。
