ERPパッケージの機能をサービスの集合体ととらえ、サービスを組み合わせてシステムを構築する--。パッケージ・ベンダーが、「サービス化」を実現しつつある。先行するSAPの「Enterprise SOA」とオラクル「Application Integration Architecture」を中心に、ERPパッケージのサービス化の実像に迫る。
03年のSAPを皮切りに、パッケージ・ベンダーは相次いでサービス化に乗り出した。オラクルは、米ピープルソフトを傘下に収めた05年1月、新ERPパッケージの開発計画「Project Fusion」を発表。08年に登場する次世代製品「Oracle Fusion Applications」は「完全にサービス化されたものになる」と宣言した。
サービスとしてERPパッケージを扱えるようになれば、利用企業のメリットは大きい。オリンパスのように既存の業務プロセスを変更せずに、パッケージを導入できる。新規の業務が発生したら、必要なサービスを追加するだけでよい。パッケージ・ベンダーが進めるサービス化の狙いは、「堅く」「導入が大変」というERPパッケージのイメージからの脱却だ（図1）。
 |
| 図1●サービス化によってERPパッケージが生まれ変わった [画像のクリックで拡大表示] |
第3位の米インフォア・グローバル・ソリューションズ（インフォア）もアプリケーションのサービス化戦略を打ち出している。同社の主力製品である「Infor ERP LN（旧製品名SSA Baan ERP）」や「Infor ERP LX（同SSA BP CS）」を連携するのが目的だ。
この5月には富士通が国産製品で初めて、本格的にサービス化したERPパッケージを提供すると発表した（図2）。「社内には数多くのシステムがある。単一のERPパッケージですべてを処理するのは無理がある」と気付いたことが理由だという。
 |
| 図2●SOAの考えを取り入れたERPパッケージや動作基盤となるミドルウエアの開発が進んでいる [画像のクリックで拡大表示] |
既存製品にサービス化ツールを追加
まず06年5月にSAPが、同社の提唱する「EnterpriseSOA」に基づいて、本格的にサービス化したERPパッケージであるSAP ERP 6.0を出荷。今年4月には、オラクルがProject Fusionに向けた施策として、傘下の製品をサービスとして連携させるためのアーキテクチャ「Application Integration Architecture（AIA）」と連携用ツール「Process Integration Pack（PIP）」を発表した。2社の動きから、ERPパッケージのサービス化の具体像が見えてきた。
SAPは「2層構造」を採用することで、アプリケーションのサービス化を実現している。図3がその全ぼうである。 1層が「アプリケーション層」だ。これまで通り、複数の機能のまとまりであるモジュール形式で、ERPパッケージなどのアプリケーションを提供する。
 |
| 図3●独SAPが推進するERPのサービス化の概要 [画像のクリックで拡大表示] |
ポイントは、新たに追加された2層目の「サービス層」にある。2層は、アプリケーションを「サービス」として、利用者が取り扱えるようにする仕組みを備えている。具体的には、サービスを定義する「エンタープライズ・サービス（ES）」と、ESを管理するための「エンタープライズ・サービス・レポジトリ（ESR）」だ。1層と2層を連携させるために用いるのが、SAP製アプリケーションの動作基盤となるミドルウエア群「NetWeaver」である。NetWeaverには、アプリケーション・サーバー「WebAS」や、ESB（エンタープライズ・サービス・バス）「XI」、複数のアプリケーションのマスターデータ統合ツール「MDM」など、サービスを連携するために必要なミドルウエアが含まれる。
ESは「売り上げ伝票を作成する」「顧客情報を登録する」といった粒度で提供される。「ESの単位は利用部門の担当者が実際に行う業務。業務の実行に必要なシステムの処理とデータを定義している」（SAPジャパンの松本潤エンタープライズSOA推進室マネージャー）。例えば、「顧客情報を登録する」というESは、「顧客の基本情報を読み込む」「顧客情報を変更する」という処理と、「顧客の基本情報」というデータで構成する。
ただし、ESが定義した業務を実現する処理を実行するのはあくまでも、ERPパッケージやCRM、SCMソフトなど1層にあるアプリケーションだ。
ESRは、ESとアプリケーションを連携する役目を果たす。顧客情報を登録するESを実行する場合、顧客情報を読み込むアプリケーションにアクセスし、データベースに登録している顧客情報を返すといった処理を実行する。必要な処理を正確に実施しているかどうかも管理する。
組み合わせのお手本も提供
モジュール単位の導入では実現できなかった細かい単位の処理が、ESを介することで可能になる。サービス化したERPパッケージを利用してシステムを構築する場合、利用企業はシステム化したい業務の流れに沿ってESを並べる。この時、ESが実際にどのアプリケーションを呼び出すかを考える必要はない。
この際、業務プロセスに沿ってESをならべる順番を、利用者自身がゼロから考えるのは簡単ではない。場合によっては10個以上のESを組み合わせる必要がある。
SAPは07年から、お手本となるESの組み合わせ「エンタープライズ・サ ービス・バンドルズ（ESバンドルズ）」を提供し始めた。利用企業がサービスを選ぶ手間を減らすことが目的だ。
ESバンドルズは、「受注から支払いまでの一連を業務プロセスを支援するのに必要なESの種類と順番」などのように、目的別にESの組み合わせを示したものだ。具体的には、ESの利用方法を記述した文書などで構成する。
受注から支払いまでの業務をシステム化する場合、利用者はESバンドルズを参考にESを並べることになる。ESバンドルズの定義している業務の手順が自社の業務に合わなければ、ES単位で業務の手順を入れ替えたり、ESそのものを変更することも可能だ。
現在、SAPはESやESバンドルズの拡充を続けている。1000種類を超すESと22種類のESバンドルズを提供済みだ。同社は昨年10月に、10年までSAP ERP 6.0のメジャー・バージョンアップを実施しないと発表。その代わりに、「エンハンスメント・パック」と呼ぶSAP ERP 6.0の機能拡張パッケージを1年に2回のペースで出荷しており、パックの提供と同時にESを追加している。同社のWebサイトからダウンロードも可能だ（図4）。
 |
| 図4●独SAPがWebサイト上で提供しているエンタープライズ・サービスの画面 「社員情報の入力」というエンタープライズ・サービスは「社員情報の基本情報の読み込み」「社員の名前の読み込み」など複数の処理から成る |
オラクルも2層でサービス化
オラクルもSOAに基づき、既存のERPパッケージのサービス化を進めている。07年4月に発表したAIAでは、Oracle EBSやPeopleSoft EnterpriseなどのERPパッケージや、Siebel CRMなどの業務パッケージを、PIPを介してサービス化し、連携させる。
サービスの連携には、同社のミドルウエア群である「Fusion Middleware」を動作基盤として用いる。オラクルは、買収した製品をFusion Middleware上で動作するように開発を進めてきた。
PIPは、「Oracle EBSの販売管理機能とSiebel CRM On Demandの顧客管理機能を連携させる」といったことを実現するのに必要な、業務プロセスとデータの連携機能を提供する。現在は、Oracle EBSとSiebel CRM On Demand、銀行向けパッケージ「FLEX-CUBE」とSiebel CRMなど、10種類のPIPを発表済みである。
オラクルは特定のアプリケーションに依存しない2つのモデルを用意したうえで、PIPを開発している。1つは、業務で扱う情報のあるべき姿を定義した「Enterprise Business Object（EBO）」というデータ・モデル。
もう1つは、銀行業やプロセス製造業といった業種別に、カギとなる業務プロセスやデータ・モデルを定義した「業種別レファレンスモデル」である。 重要なのがEBOだ。EBOは「顧客」「注文」「請求書」といった単位でデータ・モデルを定義している。EBOが中心となって、提供するサービスの粒度を決定していると言い換えることもできる。
オラクルは、EBOで定義したデータと、データに対する処理を持つアプリケーションをマッピングさせることで、ERPパッケージやCRMソフトをサービス化する。EBOは、SAPのESとほぼ同じ役割を果たすものと考えてよいだろう（図5）。
 |
| 図5●米オラクルが推進するサービス化戦略「Oracle Application Integration Architecture」の概要 [画像のクリックで拡大表示] |
SAPとの相異点もある。米オラクルでアプリケーション戦略担当バイス・プレジデントを務めるパコ・オーブルホァン氏は、「オープンな標準に準拠するのが当社の基本戦略。業種別レファレンスモデルもEBOも、オープン・アプリケーション・グループといった標準化団体が策定したモデルに基づいて作成している。業務アプリケーションをサービス化したいと考えている企業なら、どこでも自由に利用できる」と説明する。
特集冒頭のページで記したように、SAPとオラクルの両社は08年に、さらにサービス化を徹底させた製品の提供を予定している。
増えつつあるサービス指向製品
SAPやオラクルに続くのがインフォアや富士通である（表1）。
 |
| 表1●サービス化に対する主なパッケージ・ベンダーの取り組み [画像のクリックで拡大表示] |
インフォアはオラクルと同様、大量の業務アプリケーションを買収している。現在、500種類程度のアプリケーションが傘下にある。これを「12年までに、モジュールよりも細かい機能単位でサービス化する予定だ」と日本インフォア・グローバル・ソリューションズの長衛毅エンタープライズソリューショングループ ビジネスコンサルティング本部 ビジネスコンサルティングマネジャーは話す。
インフォアはその過程で、Webサービスを介して、モジュール単位あるいは製品単位で同社のパッケージを連携できるようにしている。そのために、同社製品の利用者にSAPのXIに当たるESB「Infor ESB」を無償で提供。「基盤への投資をなくして、優位性を確保する」（長衛マネジャー）という。
もう1社忘れてはならないのが米マイクロソフトである。日本では今年6月からERPパッケージの提供を始めた。同社もサービス化の流れは意識しており、中堅企業向け製品「Dynamics AX」には、Webサービスを介してデータを連携するためのツール「Application Integration Framework」を用意している。本格的なサービス化は次期版以降で進める。
国産ERPパッケージもサービス化に向けて動き出した。
富士通は今年5月、自社ブランド「GLOVIA」傘下のERPパッケージを整理・統合し、順次、業務機能単位でサービス化していくと発表した。合わせて、SAPやオラクル製品が提供するサービスと連携して利用可能にする。
富士通はGLOVIA製品群の動作基盤としてESB「Interstage Service Integrator」を採用している。だが、SAPやオラクルの製品と連携する場合は、「基盤は自社製品にこだわらない」（富士通産業・流通ソリューション本部の東純一本部長代理）姿勢だ。
「開発作業は膨大なものだし、過去の似たような構想はうまくいかなかった。処理性能や信頼性の確保も簡単ではない。だが今回は業界トップのSAPが本腰を入れているから、サービス化は進むのではないか」。ERPパッケージ「COMPANY」を開発・販売するワークスアプリケーションズの牧野正幸CEO（最高経営責任者）はERPパッケージの動向をこうみる。「パッケージのサービス化が浸透したら、当社の製品をSAPやオラクルのミドルウエア上でサービスとして扱えるようにするといった具体策を考える」（牧野CEO）という。
サービスを組み合わせて新たに作ったアプリケーションを「コンポジット（複合）アプリケーション」と呼ぶ。ERPベンダー各社は、コンポジット・アプリケーションの実現に向け、それぞれが歩みを進めている。
