クラウドERPは何をもたらすのか 　　第2回　~ SAP S/4 HANA~ の世界

Option2の場合は、ERPの既存データベースをHANAにマイグレーションします。

当然工数はOption1に比べると大きくなりますが、

ERPのトランザクションデータも含めてHANAに一元化されるため、

余計なデータ連携が無くなり、よりシンプルなシステム構造になります。

ただし、HANAへのリプレイスの作業は相当の負荷がかかるはずです。

HANA DBをクラウド環境で提供し、移行サービスを行っていたり、

SQLWaysなどの移行ツールを使ったソリューションを提供しているベンダーがありますので、

そうしたベンダーのソリューションをいくつか比較検討するとよいでしょう。

また、このアプローチの場合、データの移行だけでなく

既存のERP側にも影響があるので注意が必要です。最新のEnhancement Package (EHP)の適用はもとより、

これまでのRDBへのIn/OutとインメモリDBへのIn/Outではロジックが異なるため、

HANAの特徴である、カラム型データベースの特性を最大限に生かすためには、コードの変換が必要になります。

しかし、これまでのERPの機能が高速のHANAベースで処理可能なため、月次で実施していた配賦処理を即座に処理できるなど、HANAの性能をうまく引き出せば、業務改善に対する実感は大きいのではないでしょうか。

ただ、カラム(列)型データベースはデータ抽出には効力を発揮しますが、データ更新はロウ(行)型データベースに比べて弱いと言われています。

HANAについては、更新は一旦仮にロウ型で処理した後にバックグラウンドでメモリ上にカラム型に変換するという手法でその弱点を克服する工夫がされていますが、既存ERPの更新処理のパフォーマンステストは十分にしたほうがよいでしょう。

こうした負荷を考えると、単純に現ERPで使用しているOracleなどのデータベースをHANAにリプレイスするというよりは、将来の拡張性を見据えたOptionと言えるでしょう。

HANAをプラットフォーム全体としてとらえ、将来的にはS/4 HANAへの置き換えや、

PaaS型で提供されるHANA プラットフォームのソリューション群を活用を前提とした場合の1つのステップという位置づけです。

敢えて簡単に判断ポイントを申し上げると、

レポーティング、分析に特化した革新をてっとり早く目指すのであればOption1を

既存のERPにおける処理機能そのものの頻度や粒度を変える必要があるようなビジネスニーズがある場合はOption2をということになるでしょうか。