進化するERPはどのようにデジタルに向き合っているのか？：第2回

2019年11月13日(水)磯谷元伸（NTTデータグローバルソリューションズ代表取締役社長）

リスト

前回は、基幹系システムのアーキテクチャ上の進化として「バッチ処理からリアルタイム処理へ」「定型業務データからビッグデータへ」「オンプレ密結合からクラウド疎結合へ」の3つの視点を挙げさせていただいた。今回は、これらの進化が基幹系システムで中核をなすERP製品の進化、ロードマップに与えた影響について解説していきたい。

ポストモダンERPとは？

　皆さんは「ポストモダンERP」という言葉をどこかで聞いたことがあるのではないか。米ガートナーが定義する「ポストモダンERP」とは、クラウド、AI（人工知能）、インメモリーDBなどの最新テクノロジーを取り込んだ“次世代ERP”のことである。

　単に新しいテクノロジーを取り込むだけではない。これまでの国内外のERP製品で一般的だったのは、すべての業務アプリケーションをオンプレミスで単一アーキテクチャ上に密結合させる統合基幹業務システム。これに対して、クラウド上の製品（SaaS）を含む複数の業務アプリケーションを疎結合で連携するアーキテクチャに進化してきているのもポストモダンERPの大きなポイントである。

　以下、SAPを例に次世代ERP製品の特長を記載する。同様の動きは他のベンダーによるERP製品においても多かれ少なかれ、ほぼ同様の方向性や機能拡張が図られているので、ぜひ参考にしていただきたい。

クラウド疎結合による製品ラインナップ拡充

　日本企業へのERP導入が始まった1990年代ごろ、ERPは「販売や会計など基幹業務で発生する多くの伝票を大福帳型データベースで一元的に管理するシステム」と説明されていたのをご記憶の方もいらっしゃるだろう。いまでも、この基本的な考え方は変わらないが、国内外のERP製品開発競争とその後の周辺製品企業のM&Aにより、各社のカバーする業務領域は格段に拡がってきている。

　SAPにおいても、購買や人事、経費精算、情報分析など、それぞれの領域に特化した製品ベンダーのM&Aをしたり、自社で開発したりしながらカバー領域を拡げてきた。近年では有力な競合がいるCRMやRPAといった領域への進出にも精力的に取り組んでいる。これにより、提供する製品群としては企業活動を取り巻く主要な業務プロセスをほぼすべてカバーしてきている。

　当然、周辺業務領域の業務ソリューションが他社製品であってもEAIやコネクター等を介して連携は可能だ。ただし、その場合はお互いのインターフェースやデータ項目を意識したコード変換が必要となる。SAPでは、これらの製品間の連携はいまも進化の途中だ。今後も会計・在庫といったコア業務と購買や営業フロントといった周辺領域間のスムーズな連携とさらなる有機的な結合を目論んでいる。（図1、図２）

図1：これまでの基幹系システム群のイメージ
拡大画像表示

図2：拡張された業務領域イメージ（SAPの例）
拡大画像表示

　また、クラウド連携の別の側面として、ERPコア領域においても、本社・主要拠点とグループ会社・海外拠点で異なる「2層ERPモデル」を導入・検討する企業が多くなっている。例えば、本社・主要拠点では拡張性が高く機能豊富なSAP S/4HANAを使い、グループ会社や海外拠点ではSAP Business ByDesignやSAP S/4HANA Cloud、場合によってはBiz∫（ビズインテグラル）やMicrosoft Dynamics 365を導入して連携させるといったものだ。

　「クラウドで疎結合させる」アーキテクチャを取り入れたことにより、ERPや業務アプリケーションのクラウド製品（SaaS）の中から、それぞれの企業活動に合ったものを選択できるようになった。まさに「適材適所=Best of Breed」が可能になったのだ。

リアルタイム処理とビッグデータ対応

　さて、アーキテクチャ上の進化として、残り2つの「リアルタイム性」と「ビッグデータ対応」についてもSAPを例にどのように製品を進化させたのかを解説したい。

　SAPが次世代アーキテクチャの中核として開発したHANA DBは、従来のリレーショナル型DB（ローストア型）とは異なるカラムストア型DBを採用している。大規模データに対しては、データ圧縮と同時に検索や集計処理を強化した。さらにインメモリーDBを使ったデータ処理の高速化を実現している(図3)。

図3：インメモリーDB（HANA DB）によるシステム・アーキテクチャの変化
拡大画像表示

　本来、技術的には大規模データ処理とリアルタイム性（高速化）とはトレードオフの関係にあるのだが、HANAのアーキテクチャは両者を同時に実現させようという試みとなっている。

　一方で、既存ソフトウェア製品においてDB構造を変えるインパクトは計り知れない。SAPが提供する製品上のほとんどのアプリケーションにおいてプログラムの書き直しが発生し、膨大な工数と投資が必要となったはずだ。彼らがそこまでして実現したかったことは何だったのだろう？

　従来の基幹系システムのデータですら、過去分を含めた伝票明細レベルでは膨大なデータ量となってしまう。情報系システムは別システム・別アーキテクチャで用意せざるを得なく、その瞬間のリアルタイムな実績データと分析用の蓄積したデータの間に、どうしても月次や日次といったタイムラグが発生する。

　経営情報分析やS&OP（Sales & Operations Planning：販売・業務遂行計画）など生産計画立案の情報系システムのために、基幹系システムのデータからETLで中間ファイルを抽出し、そこから情報系専用のDWH（データウェアハウス）を構築する。さらに利用部門別のデータマートに分けて個別分析用にシステム構築するといった方式は多くの企業情報システムで採用されてきた。オンプレミスでもハードウェア性能が進化し続けているとはいえ、依然としてディスクアクセスや処理能力の制約があり、この方式は汎用機・COBOL時代のファイル抽出・バケツリレー方式と根本的なところであまり変わりがない。

●Next：もしオンプレからクラウドのデータ転送が容易になったら？

この記事の続きをお読みいただくには、
会員登録（無料）が必要です