[ザ・プロジェクト]

2009年2月6日(金)田口 潤（IT Leaders編集部）

友光徹治氏
オリンパス コーポレートセンター IT改革推進部
SCMグループ グループリーダー
オリンパス入社後、伊那工場における現場改善活動やCAD／CAM導入に携わった後、本社に異動しIT企画を担当。1999年からの香港駐在を経て2005年に帰任し、BPI支援及びOLIVEプロジェクトを展開した。

 

堀口昌宏氏
オリンパス コーポレートセンター IT改革推進部
SCMグループ チームリーダー
1995年にオリンパス入社後、技術系情報システムの開発/保守を担当。2001年からドイツに駐在し、ERPの導入を手がけた。2004年帰任後、中国営業所のERP導入に携わった後、BPI支援及びOLIVEプロジェクトを展開した。

 

─ オリンパスの海外事業を教えてください。

友光　 売上比率でいえば日本が37％、欧州が27％、北米が21％、アジアその他が15％といった構成で、一般になじみが深いデジカメやICレコーダー、世界で75％のシェアを持つ内視鏡など医療機器、非破壊検査装置などを製造・販売しています。そのために製造・販売の子会社を世界各地に置いているんですよ。

─ 海外比率がかなり高い。それでどんな問題があったんでしょうか？

友光　 いろいろありますが、端的に言えば海外で作ったものを海外で売るなど日本を通さない商流が増えてきたことですね。本社から海外の事業実態が見えにくくなってきたんですよ。事業ごと、製品ごとにサプライチェーン上の物流と商流、つまりPSI（Production, Sales, Inventory：生産・販売計画・在庫）情報を、取引1件ごとの生データの状態で収集、蓄積して分析できるようにする必要が生じました。

─ 海外展開している多くの企業に共通する課題ですね。しかし当然、そのためのシステムは前からあったのでは？

友光　 ええ、もちろん。比較的新しいところで言うと、2003年に海外拠点のPSI実績を蓄積するSCMデータベースを稼働させています。しかし現場のユーザーの使い勝手はあまり良くなかった。特に、データの精度に問題がありました。このデータベースに蓄積したのは、生の取引データではなく集計済みのものだったんですよ。

堀口　 例えば、商品Aを顧客8社に4個、10個…と出荷しますよね。集計済みというのは「商品Aを日次で80個出荷した」というふうに現地側で計算して、送信してもらうことです。集計した時点で何の在庫がどこに何個あるかは分かりますが、在庫の中身やなぜそうなったのかを分析することはできませんでした。

─ ということは、顧客ごとの販売量が分からないのが問題？

堀口　 それだけではありません。実は製品在庫には新品の在庫のほかに、リースバックされた中古在庫、デモ用の預託在庫といった区分けがあります。中古在庫を新品として売れないのは当たり前ですが、集約すると見えなくなるんです。

友光　 加えて、そもそもデータの精度を保証できませんでした。システム上では「在庫は合計10個」となっていても、本当は8個かもしれない。「どうもおかしい」というデータがあっても、製品1つひとつのPSIデータまでさかのぼれなかったんです（図1）。

─ なるほど。しかし、そもそもなぜ現地法人から集約前の生データをもらわないんですか。

友光　 そこなんですよ。各国の現地法人は、それぞれIFSやJDEdwards、MOVEXなど異なるERPパッケージで業務システムを構築しています。データの形式がバラバラだったので、生データをもらっただけでは使えなかったんです。

─ SCMデータベースの問題点は明らかだったが、そのままにしていた？

友光　 2002年から2006年にかけて、SAP R/3の国内導入という大仕事を進めていました。その間は、それ以外の案件を棚上げにせざるを得ませんでした。

─ もう一つ聞いていいですか？ 各国の現地法人にR/3を導入させる選択肢もあったと思いますが、検討はしなかった？

友光　 それは理想型ですよ。でも、実際にやるとなると現地法人の負担が大きいし時間もかかります。将来的にはともかく、まず現状の課題を放置するわけにはいきません。

ユーザー自身が開発し、ベンダーの努力を引き出した

─ 現地法人が使っているシステムをそのままに、生データを吸い上げたかった。そのためのアプローチというか、仕組みはどのようなものですか。

友光　 各拠点のシステムから生データをEAIツールで取得し、データウエアハウスに格納する仕組みです（図2）。

─ それはまた非常にシンプルな。

堀口　 ええ（笑）。でも国が違うと言語が違いますし、通貨単位も計上のタイミングも違います。先ほどお話しした在庫の意味も、微妙に異なります。この違いを吸収するために、現地法人が独自に定義しているデータの意味をグローバル定義に変換するデータ辞書を作成しました。

─ プロジェクトの経緯を教えていただけますか。

友光　 2006年からのIT基本戦略の一環として、2006年7月に検討を開始し、同年11月にプロジェクトを実質的にキックオフしました（図3）。その後、技術検証やデータベース設計、データ辞書や検索画面の開発などに取りかかり、2007年6月に新システムを本番稼働させました。

─ すると、開発期間は8カ月。ベンダーはさぞ大変だったでしょうね。

友光　 いや、各国のシステム改修に関わる作業も含めて、さっき言ったことは全部自分たちでやりましたよ。インテグレーションをお願いしたNECには、主にデータウエアハウスの設計・実装を担当してもらいました。

─ ちょっと待ってください。ユーザー自ら開発を担当したんですか。

堀口　 そうです。画面も検索機能も、こちらで開発しました。

─ というと、オリンパス側のメンバーは友光さんと堀口さん以外に何人いたんですか。

友光　 あと1人です。

─ たった3人？ 会社はメンバーを追加してくれなかったんですか。

友光　 要求すれば増やしてくれたとは思います。でも、小回りが利かなくなるので大人数ではやりたくなかった。3人なら常に即断即決。懸案事項を翌日に持ち越さない方針で、何か起きたときはその場で対策を決めました。

─ 「すべてベンダーにお任せ」というスタンスはとらない。

堀口　 「あれをやれ、これをやれ」と言うだけでは、短期間でいいシステムは構築できません。自分たちが主導しないと。

─ 確かに、ユーザーがそこまで頑張ったら、ベンダーは必死にならざるを得ませんよね。

友光　 実はね、着手して間もないころ、ベンダー側のリーダーを3人替えてもらいました。プロジェクトは計画段階で成否が80％決まると思うんですよ。自分たちが主導するといっても、ベンダー側の担当者も重要です。「この人ではだめだ」と感じたらすぐ手を打たないと取り返しが付かなくなります。

─ ベンダーにとってはいやな客だったのでは（笑）。

友光　 そうかも知れません。でも付け加えると、4人めのリーダーは大変優秀な人でした。今でも飲みに行く仲ですよ。

─ EAIなどのツールは何を使った？

堀口　 EAIツールは社内標準であるe*Gate、データウエアハウスはNettezaの製品を使っています。

─ Nettezaは技術的に面白い製品ですが、実績が少ないですよね。

友光　チューニングや集約表の作成、インデックス設計など、データベースの保守運用に割ける人的リソースは全くありませんでした。Nettezaは、これらの作業をしやすく、性能も高いということで、目をつけたんです。

堀口　 ただ実際、社内でも不安視する声があり、検証テストを繰り返しました。