ETL機能でユーザーの負荷を軽減、導入後3年で1億4000万円を削減へ【日本製紙】

─ 日本製紙は2006年、BIシステムを導入。ユーザーによる情報活用を進めているそうですね。新システムは、グループ全社に共通なんですか。

井田： まだ全社というわけではありません。今のところ、日本製紙のほか安田が所属する日本大昭和板紙など6社が活用しています。

─ 情報分析用のシステムは、これが初めて？

井田： いえ。2000年にTeradataのデータウェアハウスを導入して、販売や製造といった基幹業務データを、ユーザーが自由に分析できる仕組みを構築しました。

萩原： 約2000人いる営業担当者向けには、日本テラデータのAccess Navigatorを、経理担当者向けにはOLAPツールのEssbaseを、経営層向けには経営ダッシュボード製品のDecision Webを使っていました。

─ 3つのツールを導入していた。

井田： 利用者の属性や目的別に、最適なツールをと考えた結果です。当社は財務会計システムにSAPのERPパッケージを使っているので、財務会計データを分析するためにSAP BWも導入していました。

─ それらを刷新することにした。きっかけは何ですか。

井田： 1つは、情報分析用のシステムが4系統あったので、2重3重の運用管理の手間がかかっていたことです。より大きいのは、営業担当者向けの分析機能はユーザー数が最も多いはずだったんですが、限られた人しか使っていなかった。

─ 高価なツールが使われていなかった？

勝呂： 営業部門を対象にアンケートを実施したところ、生データをそのまま提供するがゆえの使い勝手の悪さを指摘する声が多かったんです。

─ 具体的にはどういうことですか。

勝呂： 従来のシステムでは、取引データを明細レベルのまま蓄積していました。データを開くと、取引先コードや売上金額、販売数量などがずらっと並んでいるだけ。顧客や製品の切り口で分析するには、ユーザー自身が必要なデータをデータウェアハウスから抽出し、それぞれが作ったテーブルと結合する、といった手間をかけなければならなかったんです。

─ ちょっといいですか。それは特殊な分析をするケースですよね？ユーザーの多くが利用できる定型的な帳票は、あらかじめ用意していたんでしょう？

勝呂： そうではなかったんですよ。帳票類はすべてユーザー自身に必要に応じて作成する、という方針でしたから。例えば、月次売り上げ明細もユーザーごとに作ってもらっていました。

─ それは徹底している。データ加工は簡単にできたんですか。国井さんは2009年3月までユーザー部門に勤務していたそうですが、どうでした？

国井： それなりにIT知識を持つ人でないと、難しかったですね。一部のパワーユーザーに帳票作成の負荷が偏っていたと思います。

─ ユーザーからは、さぞかし不満が出ていたでしょう。

井田： それが、そうでもなかった。

─ 「使いにくかったら使わないだけ」ということ？

井田： まあ、そういうことでしょう（苦笑）。その一方で、旧システムではデータの増加にともない、データウェアハウス自体を拡張する必要が出てきていたことや、OLAPのレスポンスが遅い、といった問題もありました。

製品選択の決め手はETL機能

─ 利用率の低さに加えて性能面に限界が見え始めたことで、システム刷新を決めた。プロジェクトが実際に動き出したのはいつですか。

井田： 2005年10月に、システム統合・再構築を検討開始。2006年1月に、従来のシステムから新たなシステムへのデータ移行に着手しました。

─ なるほど。その間を、コンペやベンダー選定に充てたんですね。

井田： いいえ。この段階ではもう、SAS Institute JapanのSAS Enterprise Intelligence Platform（SAS EIP）で行くと決めていましたよ。

─ あ、そうなんですか。

井田： 実は、ベンダー各社が提供する分析ツールを事前に調べておいたんですよ。

─ SAS EIPの何を評価したんですか。

井田： 1つがETL、つまり基幹系からデータを抽出したり、適切な形に変換する機能です（本誌注：ELTはExtract/Transform/Loadの略）。以前のシステムにおいて、ユーザー側にデータ加工の手間が発生したのは、このETL機能がなかったからでした。機能や実績も、もちろん大きいですけどね。

─ ほかには？

井田： ETLと分析ツールを1つのプラットフォーム上で運用できるところも魅力でした。4つの分析ツールを個別に動かしていた従来に比べて、運用管理の手間を大幅に削減できますから。

萩原： SAS製品を選んだ理由はもう1つあります。ユーザーごとのライセンス費用が発生しないという点です。SAS EIPの価格体系は、ユーザー数に関係なく「サーバー1台でいくら」なんですよ。

─ プロジェクト開始前に製品選定はほぼ済んでいた。となると2005年10月からの3カ月間、何を検討したんですか。

井田： 情報分析用のシステムを全面的に入れ替えるという方向性が、ユーザーのニーズと本当に合致しているのかについて、議論を尽くしました。多くの社員が活用しないと、意味がありませんから。最終的に、社内の情報活用を進めるにはシステム刷新が不可欠だという結論を出したわけです。

─ なるほど。では2006年1月のプロジェクト開始では何から着手？

萩原： データ移行です。Teradata上の過去データをいったんCSV形式に変換して、それをSASに取り込んだんですよ。

─ データ量はどれくらいでしたか。

萩原： そうですねえ、400〜500ギガバイトくらいだったでしょうか。

─ 日々新たに発生するデータは？

萩原： TeradataとSASの両方に蓄積するようにしました。

─ そう聞くと、あっさりできたようですが、実際は大変だったでしょう。

井田： 一通り移行を終えたのが2006年10月ですからね。販売予算や実績、在庫といった営業向けデータの完全移行は2007年3月に延期しました。

─ どうして？

萩原： 営業向けデータを作り直す必要が出てきたんですよ。先ほど話に出たように、ユーザーは従来、帳票のテーブルをそれぞれ個別に作っていました。このため、データ項目名がユーザーによってばらばらだったんです。

勝呂： 例えば、取引先の社名です。その会社の正式名称を使う担当者もいれば、略称を使う担当者もいました。略称も、3ケタだったり5ケタだったり。

─ システム刷新を機に、1つの名称に統一すればよかったのでは。

井田： それはそうなんですが、ユーザーからすると、自分たちが慣れた様式で帳票を作って分析をしたいんです。

勝呂： このため、営業関連データの移行をいったん中止。データ項目名を追加する作業を進めました。追加した項目名は、数百あったと思います。

─ 使い勝手を考えると、重複するとわかっている部分も切り落とせなかった。でもそれってユーザーに優しすぎるというか、過保護ではないですか？

勝呂： 項目を無理やり一本化しても、ユーザーとしては抽出したデータを自分たちのこれまでのやり方に合うよう加工するでしょう。それでは、システム刷新の意味がありませんから。

─ 営業向けデータの整備を終えるまで新システムの稼働を延期した？

井田： いいえ、新システムは当初の予定どおり、2006年10月に運用を開始しました。その後、2007年3月に整備済みの営業向けデータをシステムに流し込んだということです。

1年かけてユーザー自身が帳票を移行

─ 新システム導入に伴うユーザー教育も、もちろん実施したんですよね。

井田： 全国各地の工場など、各拠点でユーザー説明会を実施しました。みんなで手分けして全国の工場を回り、実際の操作演習を含めて半日ほどの説明会を開いたんですよ。ユーザーマニュアルは、勝呂が作りました。

─ 1つお聞きしたいのですが、旧システムで作った分析用の帳票類があったと思います。それらはどうしたんですか。

井田： ユーザー各自で新システム用に作り直すよう、お願いしました。

─ システム部門は何もしなかった？

井田： はい（笑）。以前の帳票を手元に持っているのはユーザーなので。

─ それはそうですが。

井田： システム部門がすべて面倒を見るのが、一般的なのかも知れません。でも、当社のユーザーは気持ちよく協力してくれた。助かりました。

─ 日本製紙と同時に新システムを導入した日本大昭和板紙でも、帳票類の移行をユーザーに任せた？

安田： いえ、当社では我々、システム部門が主に担当しました。ユーザーの「こういう帳票がほしい」というニーズを1つひとつ調査し、「これは全社共通で使える」という帳票を100種類くらい作っています。

─ なるほど。安田さんのところのユーザーのほうが楽でよかった（笑）。

安田： 当社は日本製紙に比べて会社の規模が小さくユーザーも少ないので、そこまでできたんですよ。

─ 全国でユーザー教育を実施した。データや帳票の移行も済んだ。全面的に新システムに切り替えたのはいつ？

井田： 2007年11月、大きな混乱もなく旧システムを廃止できました。

64ビット対応で処理速度を向上へ

─ BIシステムは導入フェーズもさることながら、社内に定着させるまでが難しいと聞きます。全国の拠点で説明会を実施したとはいえ、その後もユーザーに“使ってもらう工夫”が必要だと思いますが。

萩原： おっしゃる通りです。そこで、システム部門内に「ビジネス・インテリジェンス・コンピテンス・センター」、略してBICCを設置しました。ユーザー教育や分析支援を、継続的に実施する組織です。現在、モデル職場から現状やニーズを聞き取り、テコ入れをしているところです。

─ 利用は広がっていますか。

井田： はい。従来は分析作業を人任せにしていたユーザーも、徐々に新システムを使い始めています。コスト削減効果も大きい。導入初年度に、運用保守費を3500万円削減できました。2009年度までに、累積で1億4000万円のコスト削減を見込んでいます。

─ 課題も見えてきたのでは。

国井： レスポンスが遅いことが気になりますね。

安田： 同感です。ちょっと複雑な処理だと、数分かかることもあるんですよ。

─ それはなぜですか。

萩原： まず、サーバーOSとSAS EIPが32ビットであることが大きいですね。

─ 64ビットではない？

井田： 導入当時、SAS EIPは64ビットに対応していなかったんです。2009年4月に64ビット版がようやく出たので現在、サーバーの入れ替えを検討中です。数千万円かかりそうですが…。

萩原： しかも、サーバーを入れ替えるだけでは根本的な解決策にはならないようです。SASにボトルネック解析を頼んだところ、ストレージ自体の仕組みを変える必要があるという結論でした。SAS EIPの性能は、ストレージ速度に大きく依存するんですよ。

─ ストレージの仕組みを変えるというと、どんなこと？

萩原： ストレージとサーバーをつなぐファイバーチャネルの帯域を広げる必要があるそうです。

─ これまたお金がかかりそうな話だ。

井田： 頭の痛いところです。

萩原： レスポンス改善策としてはこのほか、部門ごとに必要なデータを抜き出したデータマートを構築していきます。データウェアハウス上の膨大なデータを検索・処理するのに比べて、はるかにレスポンスがよくなるはずですから。

井田： こうした性能向上策と並行して、今後はグループ各社への展開をさらに進めていきますよ。