なぜ、R/3と外部システムの接続は失敗するのか：パッケージ活用とシステム連携のススメ（1）

ERPをはじめ、パッケージ・ソリューションが利用されるようになってきた。パッケージソフトの中には、標準的に外部連携インターフェイスを装備するものが少なくないが、それはあまり有効活用されていないという。この連載では、SAP R/3コンサルタントの筆者がパッケージ活用とシステム連携を成功に導くヒントを解説する

　パッケージに限らず、すでに何らかのシステムが稼働している企業に新しいシステムを導入する場合、データ移行とシステム連携は必ず考えなければならない重要な課題です。どの部分を新システムに移行し、どの時点でレガシーを終了するのか、新システムは1つのパッケージで済ますのか、組み合わせソリューションにするのか、各システム間でのマスタ同期の仕組みはどうするのかなど、プロジェクト初期段階でのシステム連携デザインによって最終的な全体システムの出来栄えはかなり変わってきます。

　パッケージ・ソリューションが一般的になりつつある昨今、大企業のみならず中堅企業でもERPパッケージを検討し始めています。しかし各社の導入成功事例の紹介記事などでは、そのパッケージと社内外のシステム間連携に関しては詳しくは触れられておらず、システム概要図などでは“何らかの連携がある”と分かる程度の表現になっていたりします。

　ここでは、パッケージソフトとして代表的なSAPソリューションを例に、システム連携という観点から、実際現場ではどのような問題が起きているのかを紹介し、それはどうしたら防げるのかを考えていきたいと思います。

開発作業のすき間と連携への意識不足

事例1：専門商社A社のケース

　A社は、汎用機のレガシーシステムをR/3の商社モデルに置き換えるダウンサイジングを目的としたプロジェクトをスタートさせました。その業務形態から、受発注データのほとんどがEDIによるもので、当然新システムのR/3でも現行取引先との接続は必須要件でした。

　このプロジェクトではカットオーバー時期が決まっており、全体スケジュールを考えると何十社もある取引先との接続テストを行う時間はないことが明らかだという理由から、通信機能としてレガシーホストを存続させ、ホストとR/3サーバの間に通信パッケージを導入して、新EDIシステムを開発するという設計になりました。

図1　運用開始時には汎用機を併用し、順次EDIサーバへ移行の予定だったが……

　社内システム間接続と違い、EDIは取引先の協力なしには実現しない機能です。システム開発そのものよりも、調整に多くの時間が必要になるということは開発経験者でなくてもご理解いただけるでしょう。また、このケースのように、先にシステムの稼働時期が決定されているため、システムとしてどんなデザインが良いかでなく、スケジュールに間に合わせるための設計になってしまうというのもよくある話です。

　この事例の場合でも、運用コストの高い汎用機FEPごときに使用する期間はなるべく短くして、新EDIサーバでの外部通信サポートへ徐々に移行していく予定でした。

　しかし、R/3への移行プロジェクトの予算には新EDIサーバ用の開発費が入っていないという理由で、途中からレガシーホスト側にR/3インターフェイスを開発するという方向に変わりました。汎用機からオープン系システムに移行するプロジェクトで、撤廃予定のホスト上に膨大なプログラムを開発するというのは、ちょっと珍しいケースです。もちろん、R/3側にも入出力アドオンプログラムが大量に作成されることになります。

　なぜ、R/3標準インターフェイスを使った“パッケージ組み合わせソリューション”が普及しないのか──という問いへの回答の１つがこれです。

発注時の開発体制に問題

　ユーザー企業が新システム開発の予算を組むときに見えているのは、ハードウェア購入（リース）費、ERPパッケージ・ライセンス、SIベンダ費（開発費）の3つです。システムの規模が大きければSIベンダも複数社になり、それぞれが担当部分の見積もりを出して積み上げることになります。こうした場合、そのまま放っておくとだれもシステム連携の部分は考えないため、結局導入費用にはアプリケーション単体インプリのコストしか入れていないということになります。

　本来は外付けパッケージの組み合わせにした方が機能、導入費用、運用コストなどにおいて優れていたとしても、SIベンダが見積もり段階で組み合わせ提案をしていなければ予算外となり、開発積み残しかアドオン開発で取り繕うかになってしまいます（ユーザー企業のシステム部門社員による開発工数は導入コストと見なされないので、予算外のツール購入ではなく、内製で解決しようとする場合もあります）。こうした事態になってしまった場合、残念ながら特効薬はありません。

　予防策は「初期設計をきちんとしましょう」というしかありませんが、全社システム像を描く際に、各機能ボックスを線でつなぐだけでなくそのライン上を流れる（送受信する）メッセージ種別を列挙しておくという簡単なひと手間を加えることで、その後の工程で常に全体連携が意識できるようになります。

　新システム概要図はあっても、レガシーシステムと新サーバの間に漠然としたインターフェイスボックスのようなものがある──といった描き方（図2）では、レガシー担当者、ERP導入担当者は、それぞれ自分の枠の外は担当ではないという意識を持ってしまい、担当部分内部の開発が一段落するまで、連携部分は放置されるという結果になってしまいます。

図2　“連携”の内容が漠然としたシステム概要図では、各担当者は自分のシステムのことしか考えない

　これに対してプロジェクト期間中、常に図3のようなシステム関連図を目にしていれば、各担当者の連携やインターフェイスに関する認識が明らかに変わるのではないでしょうか。

図3　これはかなりラフなサンプルだが、こうした図があれば各担当者も担当が異なるシステムとの関係が意識できる

　インターフェイスがブラックボックスになっているということは、当然その部分の概要設計もできていないため費用の見積もりもできません。そろそろボックスのフタを開けなければならないという時期になって、びっくりするくらい工数（費用）が掛かる積み残しを発見し、慌ててそのパンドラの箱を閉じて地中に埋めたくなるというわけです。

　しかし、この辺りはユーザー個別の事情によりますので、R/3プロジェクトで常に予算がネックになるわけではありません。　多くのプロジェクトで見受けられる問題点は次の事例で説明します。

パッケージの機能を知らないSE

事例2：石油関連メーカーB社のケース

　B社はR/3を会計とロジスティクスの新システムとして導入し、生産システムと人事システムはレガシーを残すというシナリオで導入するプロジェクトで、事例1同様やはり複数社による導入サポート体制になりました。

　R/3の導入プロジェクトでは、一般的にR/3のコンサルタントを会計、販売、購買などアプリケーションごとにグルーピングして設計開発を進めていくようです。各グループの要件が形になるころにパッケージでは足りない機能や標準ではうまくいかない部分が切り出され、R/3へのアドオン開発の工数見積もりが行われます。この時点でプロジェクト予定期間の半分近くを経過している場合がほとんどです。

　B社の場合はR/3プロジェクトの経験豊富なコンサルタントが現場をリードしていたため、比較的早い段階でレガシーインターフェイスと対外インターフェイス（EDI）も開発検討対象として上がってきました。

　EDIによる受発注をR/3に移行するために、新たにEDIサーバを立てて通信制御パッケージソフトを導入することが決定され、R/3と汎用機上のレガシー生産システムおよび人事システムとはこのEDIサーバを介してデータ交換をする設計になりました。このように、社内システム間連携でもシステム間のデータ交換に変わりはありませんので、特殊な場合を除いてEDIツールのほかに別途EAIツールを用意する必要はないはずです。

　このプロジェクトの大きな問題は、R/3側のコンサルタントが担当モジュールの対外インターフェイス機能を知らないこと、そしてエンドユーザーが多数のベンダに機能を分担させて作業発注したため連携部分の面倒を見る技術者がおらず、だれも担当していない部分があるという2点でした。

　これは多くのR/3プロジェクトでもよく見受けられる一般的な課題です。たとえSIベンダが1社で一括受注をしていたとしても、プロジェクトの開発体制がR/3のモジュール単位に組織されることが多いので問題の根は同じです。

　EDIサブシステムとしてSAPの認定を受けている製品（注1）を選択したにもかかわらず、結局R/3側にアドオンプログラムを作ってデータの入出力をすることになってしまうのは、R/3の導入を行っている技術者がR/3のインターフェイス機能を知らないことが原因のほとんどです。そのため、現場で外部接続の必要性が認知されたとき、SEは次のように考えてしまうわけです。

• いまからR/3の機能を勉強していたのでは間に合わないから開発してしまう
• 前回も開発したので、今回も開発すればよい
• どうせ標準インターフェイス機能では足りない部分があるのだから、全部開発したい

ドキュメントは英語ばかり

　実際、A社のような事例より、B社の問題の方が日本でのパッケージ組み合わせソリューションの普及を阻害しています。

　欧米では、認定製品による組み合わせソリューションとR/3標準インターフェイス使用のメリットが広く認知されているので、R/3コンサルタントはもとより、エンドユーザー企業のシステム部門の技術者もR/3標準インターフェイスを使いこなしています。

　では、日本ではなぜR/3標準インターフェイスの機能とメリットが知られていないのでしょうか。システムインターフェイス機能ですので、日本の商習慣とはあまり関係ありません。

　一番大きな原因は情報不足です。

　R/3が日本に紹介されてからリリース4.0ぐらいまでは、インターフェイスに関する記述はほとんど英語でした。現在でも、読んで機能の内容を理解できるようなドキュメントはアメリカの出版物ぐらいです。

　日本でも標準インターフェイスに関する基礎トレーニングコースはあるようですが、プロジェクトにアサインされている技術者がその知識を必要としているときに、ちょうどコースが開講されていたというラッキーな場合を除き、トレーニングで知識習得というのは難しいようです。

　トレーニングで基礎知識を得たときにすぐ実際のジョブで活用していかないと、使えるノウハウの習得はできません。一度習得しても次のプロジェクトで活用できる場がないと、せっかくのノウハウも失われてしまいます。R/3はある特定の機能だけを取り出してきてもかなりのボリュームがあり、各部分それぞれに専任担当者を置くのは現実的に不可能といえるでしょう。

標準インターフェイスを利用するコツ

　では、どうしたら標準インターフェイスが使えるようになるのでしょう。

　システム間接続にはそれなりの専門知識と職人芸的な要素がありますので、私は個人的には接続設計の上流工程をプロに任せるというのが最善策だと思っています。

　SAP R/3のインターフェイス・コンサルタントの数は日本ではかなり限られてはいますが、専門家に入ってもらって設計した場合、開発工数の削減ができるだけでなく本稼働までのテスト工程、運用に入ってからの保守工数などが大幅に違ってくるため、単価の安いABAP（注2）開発者を大量導入して問題を解決するのに比べて、数十倍から数百倍のトータルコストメリットがあります。

　また専門家にすべて委託するのではなく、インターフェイスチームを構成すれば、そこに参加したエンジニアは、次に活用できる現場のノウハウが獲得できるでしょう。こうしたノウハウはトレーニングやマニュアルで学習してもなかなか習得できませんので、実際に現場で使ってみるのが一番の勉強方法です。

　ユーザーの観点から見ると、システム間連携での失敗の予防策は、使用する通信プロトコルはもとより通信ツールに精通している技術者、接続するアプリケーションシステム側のインターフェイスごとの特徴を熟知している技術者をそろえることが重要です。

　選定したベンダが、使用するツールの仕様を外国の製造元へ問い合わせしなければならなかったり、SAP R/3のインターフェイス調査から始めていたのでは最適な連携設計は難しいと判断してよいでしょう。

パッケージ利用のメリットを享受するには

事例3：医薬化学薬品メーカーC社のケース

　C社は外資系日本法人で、R/3サーバは本社管理下にあり、日本オフィスも各国共通の業務処理形態を取らざるを得ないという事情がありました。日本だけ勝手にアドオン機能を開発することが不可能だったのが幸いして、R/3標準インターフェイスを使ったパッケージ連携ソリューションに目を向けたわけです。

　C社の日本法人では、社内業務はよいとしても、取引先への帳票類はどうしても日本独自のフォーマットで出したいという要件がありました。そこで掛け合った結果、本社からはR/3標準インターフェイス連携でなら日本の帳票ツールを組み込んでよいという許可が下りたのです。

　本国のR/3サーバと日本オフィスとの間には専用線が敷かれており、日本にあるR/3のクライアントPCから本国のR/3へ伝票登録をして、当該データを折り返し日本に送信、日本側の帳票ツールサーバで受信してローカルプリンタへ出力するという設計になりました。

　R/3側には伝票登録をトリガーにIDoc（注3）を出力する設定、帳票ツールサーバ側にコンパクトなALE（注4）アダプタソフトを導入し、SAPプロトコルによるデータ送受信とフォーマット変換を実行させて帳票ツールと連携させるというシナリオで、R/3へのアドオン開発をせずにパッケージの組み合わせで要件を満たしました。

図3　C社のグローバルなシステム連携事例

　実際には標準出力では足りなかった項目の拡張（EXIT）コーディングが多少入ったようですが、6種類のIDoc出力設定で120種類の帳票フォームに対応し、ツール選定から本稼働まで3カ月足らずで導入できました。R/3側の出力設定と開発は、本国のシステム部門技術者が担当したという点が大きな勝因でしょう。

　このケースでは、R/3へのアドオンが許されないという状況からパッケージ組み合わせによるソリューションの採用が決定され、結果的に導入費用、期間の圧縮ができました。さらに、効果はそれだけでなく、R/3本体のアップグレード時にインターフェイス見直しにコストが掛からないで済むことになります。

　用意されている機能を適切に利用することが、パッケージ活用の大原則なのです。

　次回は、R/3でのアドオン開発におけるリスクについて述べていきます。

※SAP R/3のインターフェイス、用語に関する簡単な解説はエス・アイ・サービスのWebサイトに掲載しています。