戸井 雄一朗 / クイックウィンズ株式会社

写真拡大 (全3枚)

第1回 では ERPのクラウド化を語るうえで、SAP S/4 HANA を例に、この製品が持つ特徴とその意味について簡単に触れてみました。

それでは、既にSAP ERP稼働しているユーザー企業さんとしては、どのように考えればよいでしょうか。

新しい製品/コンセプトはもちろん魅力的ですが、当然現行システムがきちんと効果を出していて、

ソフトウェア資産として償却も完了していない状態でいきなりS/4 HANAに乗せ換えるという性急ですし、

何よりコストがかかりすぎます。

「ECC導入したばかりなのに、そんな新製品アピールされても・・・」という声が聞こえてきそうです。

そりゃあそうです。洋服のように簡単に衣替えが出来るはずもありません。

まず考えるべきは、既存ERPの機能拡張では対応出来ないビジネスニーズがあるかどうかです。

例えば膨大な在庫更新データを営業マンが外出先からリアルタイムでタブレット端末から見れるようにしたい。

リアルタイムで売上や収益情報を色々な切り口でフレキシブルに見たい、といった今までにはない、

データ量/粒度/頻度のレポーティングによって競争優位を出すためには、既存のリレーショナルデータベース (RDB)では限界があるため、HANAのようなインメモリーデータベースへの導入をまず実施するというシナリオが考えられます。

この場合、大きく

Option1.　分析用DBとして別途HANA DBを設置、

Option2.　既存DBをHANA DBへ移行

という、2つのアプローチがあると考えられます。

Option1の場合は既存ERPとクラウド環境に設置したHANA DBを連携させ、

高速の分析機能をERPのDBとは別で持たせる形となります。

分かり易く言うと、これまでのBW SolutionをHANAを中心にしたプラットフォームでより高速化し、

拡張性を持たせたイメージです。

既存DBを切り替えるよりも先に、まずはデータをHANAに持っていき、

そのパフォーマンスのメリットを享受しようという考え方です。

NECなどハードウェア企業がHANA DBを標準装備した専用サーバーをクラウド上で提供しているので、

それを活用してERPからのデータ連携、分析アプリケーションの実装を行うのがわりと一般的ではないでしょうか。

メリットは何と言っても既存ERP側への影響が最少に抑えられる点です。

反面、ERPとのデータ連携が生じてしまうところが難点です。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をということになるでしょうか。

繰り返しになりますが、新しいコンセプトに直ぐに飛びつく必要はありません。むしろそうした新しいコンセプトや製品を既存（ないしは導入中）のシステムを再評価するきっかけに、まずはすべきと考えます。

確かにビックデータの高速処理やモバイル端末からのリアルタイムでの情報取得等のニーズは確かに高まっていますが、自社の競争優位要因には何か？ 最新のテクノロジーがそうした要因にどのように寄与するかを

見極め、適切なシステム・エンハンスメントのロードマップを描くことが重要です。

次回は導入をサポートするベンダー側の視点での考察をしてみたいと思います。

お付き合いくださり有難うございました。