事例で見るデータ連携の実際

1. クラウドとオンプレミスの連携

まずは、オンプレミスで運用しているERP（SAP）とクラウドで利用しているCRM（Salesforce.com、以下Salesforce）との連携させた医療機器メーカーA社の例から見ていきましょう。

A社では注文管理や財務処理などをSAPで処理しています。一方、営業チームはCRMとしてSalesforceを採用しています。しかし、SAPとSalesforce間のビジネスプロセスが連携していなかったため、情報が隔離されているような状態になっていました。

例えば、Salesforceから請求や注文といった情報へと直接アクセスすることができず、SAPで管理されている情報もリアルタイムでSalesforceには反映されていませんでした。そのため、営業チームが重要な情報にアクセスできるようにして、業務効率を高めることが重要な課題となっていました。

A社は、SalesforceとSAP間でデータを連携させるプログラムの開発を検討しましたが、A社のような規模では膨大な時間とコストがかかり、さらにはメンテナンスやサポートの負荷も大きいことが予想されたため、実現するには至りませんでした。

そこでA社では、規模や将来の拡張性を考慮した結果、データ連携ソリューションを採用することにしました。プロジェクトは2段階で進められ、最初のプロジェクトではわずか2週間で請求情報や注文情報といったSAP上のデータを双方向で接続できる仕組みを実現し、Salesforceの画面からリアルタイムで情報へとアクセスできるようになりました。

次に最初のプロジェクトで得た成果をテンプレートとして再利用し、手間をかけることなく顧客マスターと製品マスターといったデータを、次々にSalesforceとSAP間で同期することに成功しています。

A社では、Salesforceの使いやすいユーザーインターフェースを使って顧客情報をリアルタイムに活用できるようになり、営業チームの生産性向上やセールスサイクルの短縮化、顧客からの信頼アップといった成果を得ることができました。

なぜ、このように短期間でのデータ連携が実現できたのでしょうか？それは冒頭に紹介したConcord の“プログラミングを必要としない”かつ“簡単な”定義作業によるデータ連携の実現にあります。

データ連携の3要素（プロトコル、フォーマット、ルール制御）別に見ていきましょう。

（a）プロトコル

A社の例では、SAPとSalesforceに接続する必要があります。
Concord では、両者へのコネクタを標準装備していますので、接続のために必要となるのは、接続情報（IPアドレス、アカウント等）のみとなります。

（b）フォーマット

正しい接続情報の定義により、接続先のフォーマットをGUI上で見ることができるようになります。後は、図2のイメージで「どの項目とどの項目をマップさせるのか」、「マップの際に必要な変換は何か」を定義していけばよいのです。
技術的な視点では、Concord内部では、処理するデータは全てXML形式に変換されています。XMLを経験している皆さんはよくお分かりのように、XMLはデータ変換の基本機能である“解析”や“変換”に対して柔軟に処理が可能である特徴を持っています。
Concordも内部的には「DOMやXPathによるデータ解析」や「XSLTによるデータ変換」を行っているわけですが、Concordを使用してデータ連携定義を行う際には、それらを全く意識することなく活用することができるというわけです。

（c）ルール制御

最後はルール制御による調整です。例えば、「想定外のデータが含まれていた場合、どう処理するか」＝例外処理（Exception Handling）や、「特定の条件によって処理を分岐させる」＝条件分岐（Conditional Branching）の定義を加えて、一連のデータ連携処理を実運用のフローに耐えられるようにする作業です。
ルール制御部分はプログラミング処理に比較的近い部分と言えますが、ここにおいても全てをプログラミングレスで定義することが可能となっています。

Concordを使用するメリットは、開発フェーズのコスト削減だけにとどまりません。運用フェーズにおいて、接続先APIのバージョンアップや変更が行われた際に、Concordにおいて変更に関する作業を吸収することが可能になります。これは、データ連携を行うシステム間がLoose Coupling されていることによるメリットにほかなりません。このメリットは、連携するシステムが増えていくにつれて、さらに大きなものになっていきます。