システム連携というと、連携ツールを利用するのが効率的だと考えられている。しかし、選択を間違えるとプロジェクトは混乱することになる。
システム連携をさせる際に、双方のシステムのインターフェイス開発を最小限にするのに有効なのは連携ツールを活用することです。
複数社のシステムを接続して電子取引を行うために共通フォーマットを定義して、会社ごとにインターフェイス開発をするのを抑えようというのがEDIですが、会社間取引ではなく社内システム間の接続の場合はEAIと呼ばれます。システム間連携に変わりありませんが、前者は公衆回線(付加価値通信網:VAN)経由、後者はLAN環境というのが一般的です。
新たにR/3を導入するプロジェクトで、R/3と社内のほかのシステムを連携するにはどのようなツールが最適なのでしょうか。各社から提供されているツールは、接続ルート定義GUIの操作性、フォーマット変換機能、接続先システムへのアダプタ機能の豊富さ、通信パフォーマンスなど、いろいろな特徴があり、それぞれ性格が違います。
しかし、こうした機能の比較検討に時間を費やすより、R/3へのアドオンダメージを最小限にする設計ができるベンダ(SIer、ISV)を探すことの方が重要です。
前回も触れましたが、システム連携で大事なのはEnd to Endのアプリケーション間プロセスフロー設計です。しかし、ユーザー環境に依存した業務プロセスフローを簡単に設計できるツールは存在しません(事前に設計した範囲で、業務プロセスフロー変更を簡単に行える環境を提供するツールはあります)。
業務連携の設計さえしっかり行うことができるのなら、バックグラウンドで動くデータ転送ツールは基本となる転送機能が信頼でき、運用管理がしやすいものであれば何でもよいのです。逆に高価な連携ツールを入れて、SAPアダプタも購入しているのに、R/3の導入をしているSIerがアドオンでインターフェイスを取っていたのでは、ツール導入の意味はありません。
システムごとにインターフェイスを開発するのではなく、標準的なインターフェイスを定めて、システム統合を短期間かつ低コストで行うというのがEAI/EDIの考え方です。そこで、カタログ上のツール機能比較をする前に、全社システムのアーキテクチャがどうあるべきか、そしてそれを支える体制をどのように作っていくかという部分を考える必要があります。
そのためには、連携導入実績などを参考にして、インターフェイスの知識がある人をアサインする方法を検討し、その人が推奨あるいは使えるツールを導入するという方法が安全です。長期的なIT戦略の中で考える場合であれば、定めた標準インターフェイスの専門家を内部で養成するということを考えてもよいかもしれません。
この辺りのノウハウは、会社ではなく人に依存します。良いツールを探すより、適任者を探す方が数倍難しいのですが、逆にいえば知識のある人を1人プロジェクトに加えるだけで、生産性は大幅に変わるはずです。もちろん、どんな形であれ期限までにつながれば良しとするのであれば、人海戦術での開発でいくらでも解決できますが……。
システム連携ツールの導入検討を始めるときは、その目的と優先すべき課題を絞り込むことをお勧めします。以下は、私が過去にコンサルティングを行った際に、ユーザーの方々に伺った質問です。
1と2では選定対象となるツールの種類が違います。
レガシーシステムをR/3に順次置き換えていくプロジェクトで、最終的にレガシーが廃止・縮小されるのであれば、その連動に多大な開発工数・費用を掛けないような設計にしなければなりません。
既存の対外通信用サブシステムがあるなら、それを社内連携に流用できるかどうか検討すべきです。ユーザーが運用管理に慣れている、新たなコストが発生しないといったメリットがあります。既存対外接続を残したまま、別の連携ツールを導入すると初期投資が必要なだけではなく、メッセージ管理を二重にしなければならなくなります。
連携ツールのアダプタ機能が使えない場合は、双方にインターフェイスアドオンプログラムを開発することになります。この場合はEAIツールではなく、単純なファイル転送ツールで代用した方が導入は簡単です。
「連携ツール導入の目的」と重複しますが、EAIサーバの導入はそれなりのコストが掛かるので、ファイル転送などの手段に比べてどれだけメリットがあるかを判断することが重要です。
例えば、R/3とリアルタイム接続したいシステム(帳票システムや入出庫システムなど)が1つあり、バッチでファイル接続したいレガシーホストが1つあるといったケースでは、新規にEAIサーバを立ててメッセージルーティングする必要がない場合も少なくありません。また、R/3のデータベースからデータをわざわざXMLに変換した後、転送先システムに理解できるフラット構造にもう一度戻してFTP転送なんて無駄なプロセッシングを行うことになりそうなツールは、システム資源活用(=コスト/パフォーマンス)面からもお勧めできません。
◇
「社内システム連携」イコール「EAIツール導入」と考え、ある種のカテゴリの連携ツール導入を前提に製品比較からプロジェクトを始めてしまうと、後で苦労することになります。実際、見てきたプロジェクトで、EAIツール導入を行ったのですが、「これをやるために、このツールは要らなかったのでは」というのもありました。
ツール連携を勧めておいて、ツールを前提にするなという展開で混乱させてしまいそうですので、最後にスムーズなERP連携導入のポイントを整理してみます。
システムの初期設計の段階で、当該プロジェクト(フェイズ)においてR/3で実現する機能、レガシーに残す機能、新たに追加する外付け機能を、それぞれ機能ボックスに機能分掌とI/Oデータを記述すること。担当者不在のグレイゾーンを作らない工夫をしておかないとプロジェクト後半にトラブルを招きます。
導入スケジュールを引く際は、カットオーバーの2カ月以上前から実データ転送テストができるように全体調整すること。
パフォーマンスチューニング期間は、追加ハードウェアの納品リードタイムを考慮しなければなりません。特にR/3サーバのパフォーマンスは要注意です。また、本番データの送受信テストでは設計時に想定していなかった例外データが必ず受信されるため、場合によってはインターフェイス仕様の変更をしなければならなくなることもあります。最終連携テスト時にマスタデータ系の不備があると、データ受信処理がアプリケーションエラーだらけでインターフェイス機能のテストになりません。
連携ツールは業務連携要件を実現し、インターフェイスアドオンを最小限にできる機能を持つ、シンプルで使いやすいものを選択するか、メッセージ連携設計からサポートしてくれるベンダを探して選定を任せる。
インターフェイス設計担当者が不在のままプロジェクトが進んで、最後に何でもEAIサーバで解決しようとすると、ツール本体価格よりアプリケーションアドオン開発フィーの方が膨らむようなことになりかねません。
◇
連携プロジェクトで時間をかけるべき、あるいはどうしても時間がかかる工程は、業務連携設計と接続テストです。特に気になるのは、多くのプロジェクトで本稼働直前までマスタ移行が終了できずに、本番データでの接続テストや大量データの送受信によるパフォーマンステストが十分に行えていない点です。
R/3導入プロジェクトでは、初期の段階で社内外の連携の有無を確定し、プロジェクトスコープ、予算、スケジュールに反映させてください。これはSIerではなく、ユーザーシステム部門の意思決定者の方々へのメッセージです。
※本連載は今回で終了です。ご愛読ありがとうございました。
この記事に対するご意見をお寄せください managemail@atmarkit.co.jp
名倉 愛美(なぐら まなみ)
株式会社エス・アイ・サービス コンサルティンググループ マネージャー
名倉 愛美(なぐら まなみ)
株式会社エス・アイ・サービス コンサルティンググループ マネージャー
国内ITベンダでネットワーク系SEを経験後、1992年からドイツSAP社の日本市場を狙ったシステムR/3ダブルバイト化プロジェクトチームに参加。1993年に日本法人 SAPジャパン設立により、本社から移籍。引き続き、R/3日本語化とSAPジャパントレーニングセンター開設作業を行う。1995年には日本での外部システム連携認定センターの設立作業および各種インターフェイスの認定を実施。1999年、SAP社退社後、SAP R/3のインターフェイスコンサルティング専門会社を設立。SAPのパートナーとしてR/3導入EDI、EAIを中心に事業展開している。
Copyright © ITmedia, Inc. All Rights Reserved.