だが人事制度になると、社内の問題とはいえ、パッケージに合わせて一方的に変えるわけにはいかない。
ましてや他企業や顧客と接触する、販売・物流や顧客管理の部署となれば、相手先の都合も考慮する必要がある。社内の業務生産性が向上しても、それが原因でサービスレベルが低下したり、サプライチェーン全体の効率が低下することは避けねばならない。
塩野義製薬の考える業務プロセスを実現できるようにするため、R/3の適用は会計と生産管理だけに止めた。そして人事はワークスアプリケーションズの「Company」、顧客管理はシーベルの「Siebel Sales」を採用。販売・物流については、パッケージでは対応不可能と判断し、スクラッチ開発に踏み切った（図1参照）。
図1 システム間連携
増え続けるインタフェースを一元管理するツールが必要
プロジェクトは、各業務分野ごとに進められ、情報システム部だけではなく各業務部門担当のエキスパートや社外コンサルが参画した。各プロジェクトは順調に推移し、一つひとつ着実にカットオーバーを迎えていった。
システムが稼働すれば、その部分を担っていたホストシステムは「お役ごめん」となるわけだが、ここで問題が生じた。ホストシステムが担っていたのは業務処理だけではなかった。業務間を結ぶデータ交換の役割を持っていたのだ。
開発中はホストシステムを中心に据え、各パッケージや独自開発システム同士は、メインフレームを介して連携するようにしていた。各業務システムがメインフレームにぶら下がるイメージだ。いわばホストシステムが「Hub」の役割を果たしていたわけだ（図2参照）。
図2 ホストを中心とした連携からWaha!をHUBにした連携への移行
だが、パッケージを立ち上げて業務処理機能を移管した以上は、いつまでもホストにデータ交換を任せておくわけにもいかない。いずれは完全撤廃する計画であり、それまでには代替案を用意しなければならない。
もちろん、連携を必要とする部分を個別に開発し、スパゲティ状態を作り出すなどは愚の骨頂だ。
システム連携ツールは、当時からさまざまなものが提供されていた。また塩野義製薬の情報システム部門では、自主的な勉強会を開催し、そうしたツールの機能やコストを調査していた。
こうした流れから当初、国産のEAIツールを一部で先行導入した。
これはかなり高機能なもので、データ交換や編集、マッピングといった機能はもちろんのこと、帳票開発ツールまでもバンドルしてあり、出力帳票の一元管理もできるものだった。
だが、開発コストがかかるのが難点だった。開発作業の大半はプログラミングによるもので、相応のスキルを持った開発者のアサインが必要だった。コーディングの時間もかかるため、1つのインタフェースを開発するのに、数十万円程度を要する計算だったという。
「今後、システムの拡張や強化に伴い、インタフェースがどんどん増えていくのは、日を見るよりも明らかでした。となれば、インタフェース開発コストは、かなりの金額に膨らむことが懸念されました」（野添課長）。
そこで、より廉価に開発できるシステム連携ツールはないか、メインフレーム時代から付き合いのあるビーコンITに相談を持ちかけたという。
ビーコンITでは、独自開発のETLツール「Waha! Transformer」（Waha!）を提案した。その際に、いくつかの競合商品との機能比較表を持参したが、西森課長は「自社製品のところに○や◎が多くついており、そのまま鵜呑みにすることはできませんでした」と当時を振り返る。
だが、デモを見て実際に触っていく中で、「これは良い！」と感じたという。
