| 日 時: | 2008年7月7日(月) 17:00〜20:00 |
|---|---|
| 場 所: | アーク情報システム(市ヶ谷) AKビル2階「大会議室」 |
研究会の冒頭、『21世紀型情報システムを考える』研究会のナビゲータのインプレスビジネスメディアの田口潤氏は前回までに話し合った内容を振り返った。
繰り返しになるが、本研究会の最終的な目標は、企業が行動する新しい規範(フレーム)を検討していくことである。しかし、そのフレームを検討し、見つけたとしても、情報がきちんと必要なタイミングで取れるような仕組み、つまり「情報の海」がなければ、人は適切な行動がとれない。
本来の「情報の海」には、企業内で生成される情報から、新聞やテレビ、インターネットの情報、さらに人の噂話までいろいろな情報が含まれる。しかし、これまでの2回の研究会では、基幹系情報システムに入力、処理される伝票レベルの情報に絞って検討してきた。伝票レベルの生のデータが企業全体、あるいは事業部門内全体として整合性をもった状態で蓄積されているかどうかが、情報の海の出発点になるからである。
過去の議論では、日本企業においては企業全体はおろか、事業部門でもまだまだ整合性のある形で基幹系の情報が蓄積されている企業は少ないという結論になった。そこで今回は、それはなぜなのか、そもそも企業は情報の海を必要としないのか、必要としたとき、それを持っていない企業が多いのはなぜなのか、という議論を進めていきたい。
その議論を進める前に、前回、問題になった「情報」と「データ」という言葉の定義について、(財)社会経済生産性本部の小林さんから話をしていただく。
(財)社会生産性本部主任経営コンサルタントの小林定夫氏による「データの一元化をめぐる言葉の定義と考察」の講演要旨は以下の通り。
情報とは、単独あるいはいくつかのデータが集合して構成されたものである。あくまでも情報が上位の概念で、データはそれを構成する要素というイメージで捉えている。
データは様々なところに分散して存在している。販売管理システムや会計システムはもちろん、個人が使うパソコンの中にもデータは存在している。
ある企業の例を紹介する。同社では販売管理システムから売上一覧表はでてくるが、そのシステムでは支払い情報の消し込みがうまくできず、担当者のパソコンの表計算ソフトで行っている。「どれだけ消込が終わっているのか」は、担当者のパソコンの中の表計算データにあるため、他の人は販売管理システムでも会計システムでも見ることができない。これはほんの一例である。このように情報が分散していると、情報を探して収集する作業が必要になるので、仕事の能率が落ちる。それだけではない。例えば今日の利益を知りたいと思っても、売上は今日のデータでも原価が昨日のデータであれば、それが真のデータではなくなる。つまり精度も下がってしまう。このようにデータの分散による弊害は様々ある。やはりデータは整合性のある形で一つの場所に蓄積されるべきだと考える。
企業の中で流通する情報は3つに定義づけられる。第一が業務情報である。例えば製造業では開発、生産、販売、保守という業務において、日付や商品コード、数量、品名、口座名、金額などからなる伝票データが流れている。
第二が結果情報。「業務が終わった」という結果を管理し、管理会計や制度会計に活用される。例えば開発部門では、案件が終わるとそれにかかった作業工数を算定する、管理する側ではこれを案件の原価として使用する。先に挙げた業務情報が流れる中で、結果情報が生成されていく。
第三は状況情報である。この情報は社長や部門長・拠点長などの経営者が意思決定するための情報である。開発や生産、営業という各業務の中では、PDCAが回っている。その状況を経営者に知らせるための情報である。(終わった結果でなく。)例えば、経営者がA店:100万円、B店:100万円という各店舗の前日の売上一覧表を見ても有効な意思決定はできない。もし午前中の来店者と購入の状況について、A店:来店者200人中購入者10人、B店:来店者50人中購入者10人という情報がわかれば、午後の対応として、A店の売上を伸ばすために、A店の品揃えを変えたり、店員を増やしたりすることができる。このような情報が見えることが、経営者にとって重要なのである。こういった情報は、伝票レベルの業務情報からは得られない。それとは別に取得、蓄積、共有する必要がある。今を変える情報が、状況情報である。
このように企業には3つのタイプの情報、そしてそれらを構成するデータがあるが、どんな企業でもデータをすべて一元化できるわけではない。データの一元化は、マネジメントの成熟度レベルに左右されるからだ。
ここでデータの一元化を定義しておこう。データの一元化とは、物理的に漏れがなく、複数カ所に同じデータが存在しない状態。データの組み合わせで情報が生成される場合の一元化とは、タイムラグがなく、精度が合っている状態を指す。
さて、私はマネジメントの成熟度を、PDCAを用いて4つに分けている。
最も成熟度の低いレベルがD。日々仕事が来て、それをこなしているだけの組織や企業である。この場合、業務情報や結果情報・状況情報のどのデータについても一元化は難しい。
次はPDレベルで、計画(P)はあるが、必ずしも実施(D)と一致していない状態である。例えば経営が計画(P)を作っても現場の担当者はそれを知らない企業などである。このレベルでは、業務合理化システムの導入がマッチするため、業務情報の一元化は可能になる。
3段階目がPDCレベル。このレベルの企業は、計画で定めた目標の結果はどうだったのか、結果情報を把握したいと考えている。業績評価システムの導入が可能なため、業務情報とそこから生成される結果情報の一元化が可能である。
そしてマネジメント成熟度合いの最高位が、PDCAレベルである。PDCAが回っている状態にある企業である。PDCAレベルの企業になってはじめて、経営情報システムの導入が考えられ、業務情報とそこから生成される結果情報・状況情報の一元化が可能になる。
ある企業を紹介すると、生産から営業、物流などに基幹系情報システムがあり、多くの社員にパソコンが支給されている。業務情報フローの約8割が基幹系情報システムでサポートされていた。しかし、結果情報フローは5割程度しか基幹系情報システムでサポートされてなく、販売管理システムの売上高(結果情報)を見ても、手処理など基幹系情報システム以外で売上計上しているものがあるため、全社や部門毎の正確な売上高を知るのは、経理部門が集計・修正した資料ができあがるまでわからない状態であった。また、社長や部門長などの経営者が必要とする状況情報で、基幹系情報システムを参考としているものは1割程度であった。この企業は、この現状をふまえて、段階を追って情報の流れや一元化に取り組んでいる。
データの一元化に影響を与えるものは、マネジメントレベルだけではない。
システムの構築や運用の体制もその一つだ。一般的に企業情報システムの構築・運用体制は、大きく鉄道型と道路型に分けられると考えている。この表現は私が考えたもので、鉄道型は情報システム部門が主体となって構築・運用体制が築かれているタイプ。マスターデータは情報システム部門が管理し、専用オペレータが運用するためデータ精度も高い。鉄道型であれば、情報システム部門の統制がきいて全体最適も可能である。
一方の道路型は、現場やSIerが主体のタイプ。販売管理システムはA社のパッケージ、生産管理システムはB社がオーダー開発、また現場の担当者がデータベースソフトを使って独自システムを構築することもある。情報の流れやデータも仕事の流れ同様多種多様で、マスターデータも現場が管理していて十分に修正がされてなかったり、十分にオペレーション教育をされてない社員やパートが運用するため、精度が低くなる。部分最適になってしまう。データの一元化において鉄道型が取り組み易いから道路型から戻せと言うわけではなく、これからも技術対応やコストなどから道路型へ移行していくことが予想される中で、どうデータの一元化に取り組んでいくかを考えなければならない。
小林氏のショートレクチャーの後、質疑応答が行われた。
まずアールワークス監査役の山田氏は、「業務情報に関しては、マネジメントの能力に関係なく、技術力によって一元化できるのではないか」という質問が投げかけられた。それに対し小林氏は、「確かに業務情報については可能かもしれない。データの一元化の難易度はマネジメントレベルだけではなく、構築・運用体制によっても変わる。道路型であれば、一元化はより難しくなる」と答えた。
山田氏はまた「状況情報の一元化は経営者だけではなく、現場にとっても重要なのではないか」と問いかけた。「大三紙業という包装フィルムを製造している企業では、現場の誰もが状況情報が見られるように一元化して、PDCAが回り、生産性が向上したから」(山田氏)である。小林氏はそれに同調しながらも、「経営者が意思決定するために欠かせない情報が状況情報である。というのも、経営者には事業の的確な舵取りや継続や中止などを判断することが求められている。しかし現場の担当者であれば自分の関わる仕事に直接関わることができるが、経営者は一部の現場を見ることしかできない。また場面に立ち会うことができないため、情報という形で現場や場面などの取組みを見ることになる。よって、その企業に合った業務情報・結果情報・状況情報の経営情報体系をどう作り上げていくかが企業経営にとって重要となる」と強調した。
次にデータ一元化の事例として、オリンパスが紹介された。オリンパス 執行役員IT統括本部長 西河敦氏の講演要旨は以下の通り。
オリンパスでは2002年、中期基本計画でSAPのERPパッケージ導入を決定した。当時は部門ごとにバラバラのシステムを構築しており、データ配信もタコ足配線状態で、どこがどうつながっているのかも分からない状態だった。変化対応力と成長性に欠けるシステムのままでは将来の成長の足かせになるとの社長の思いも強かった。ERPパッケージの導入を目指し全社業務改革プロジェクト「BPIプロジェクト」をスタートさせた。ERPパッケージで会計、人事、販売、倉庫、修理という基幹業務の統合システムを構築するとともに、マスタの統合、修理サービスシステム(CRMプロジェクト)の構築に着手した。
時系列で説明すると、2002年4月に会計システムが稼働。BPIプロジェクトのスタートは2003年で、2004年10月に人事システムが稼働。2005年1月には映像事業の修理サービスシステム、5月には医療事業他の修理サービスシステムが稼働。2006年5月にはBtoBビジネスである医療系を中心とした販売物流システムと新倉庫管理システム、2007年5月にはBtoCビジネスの映像系販売物流システムが稼働している。
新しく構築した販売物流システムは、販売管理、購買管理、計画管理、物流管理、請求システムから成る。マスタコードを統一し、プロセスごとに整理・統合された形になっている。その上で、情報をさまざまな視点から可視化し、業務改善のアプローチや顧客満足度向上に貢献する仕組みのベースとして「情報基盤システム」を構築した。
情報基盤システムを中心に、以前と今を対比してみよう。従来のシステムでは用途別にデータベースを構築していた。それゆえ、データは増殖する一方であり、目的の情報を得るための検索回数も増えていた。例えば商品の売上状況は、国内営業のシステムと海外営業のシステムに分かれて存在していたし、部品の出荷数を検索するには、また別のシステムを使わねばならなかった。このような硬直化するデータベース構造を解消するため、新システムで採用したのが多次元データベースだ。多次元データベースであれば、業務の目的、用途に合わせて情報を選択するだけ。国内と海外・製品と部品で別なシステムを使うことなく、様々な情報収集、活動分析ができるだけではなく、意思決定者であれば計画管理、担当者であれば業務管理、施策担当者であれば事業分析など、好きな切り口で情報をみることができる。国内と海外・製品と部品で別々のシステムを使うことなく、様々な情報収集、活動分析ができる。意思決定者であれば計画管理、担当者であれば業務管理、施策担当者であれば事業分析など、好きな切り口で情報をみることができる。
このように使える情報基盤は完成したが、まだそれほど使いこなされているとはいえない。実はオリンパスの映像、医療事業の売上の7−8割は海外で、国内の売上比率は小さい。今回、構築したシステムが管理するのは日本国内のデータのみだからである。経営層にとっても事業部門にとっても、グローバルな情報へのニーズが強い。
そこで現在、オリンパスでは、米国や欧州などにあるグローバル拠点の情報が見られるようシステムの連携に取り組んでいる。各現地法人では、それぞれ別々のERPパッケージが導入されている。そのデータを一元化していく。国内の一元化でも大変だったので、グローバル連携はそれを上回る大変さになるが、これはやっていくしかない。データの一元化には、色々な方法があると思うが、オリンパスでは各国のデータはそのままに、日本側で辞書を作って変換する方式で進めている。
事例講演だけに参加者は興味津々で、活発な質疑応答が交わされた。司会の田口氏は、「研究会のテーマがデータの一元化。それに合わせて、興味深い話をしていただいた。しかしそもそもの目的はデータの一元化だったのか。違うのではないか」と、BPIプロジェクトの目的について尋ねた。西河氏は、「その通り。データの一元化は手段であり、事業の実態をスピーディーに把握してPDCAをきちんと回せる仕組みをつくることが目的だ」と回答。次に山田氏が「どのくらいのデータ項目を管理しているのか」と質問した。西河氏に同席し、実際に構築に携わったオリンパスIT改革推進部次長の石橋正行氏は「現地法人の情報系から集めているのは、第一次顧客の売り上げ実績の生データで、数千に及ぶ。地域ごとに辞書を用意し、データを統一している。辞書の数もかなりの数に上る」と回答。またリアルタイム性はどうかという質問に対して、「時差はあるが、ほぼ日次情報として取り出せるようになっている」と石橋氏。小林氏からは「3つの情報のタイプでいうと、このシステムでどういう情報が取り出せるのか」という質問があった。西河氏は「使い人が使いたいような形で取り出せる」と回答。続けて小林氏は「情報のタイミングや精度、範囲についてはどうなっているのか」という問いかけに対して、「船や飛行機で運搬中の在庫についても見られるようにしている。1パーセントに満たない売上しかない国はまだデータの一元化が進んでいないが、販売データについては日米欧、アジアとカバー率は9割に及ぶ。流れてくるデータは正確で、傾向は分かる」と西河氏。
「生産管理をつながなかった理由」(小林氏)については、「今回のシステム化の目的はいろいろあるが、ひとつには事業をコントロールするため。例えば、売れてない国の在庫を売れている国に回すというようなアクションをとれるようにしたかった。このような手をうつための仕組みを早く構築したかったから」(西河氏)と解説した。
「マスタはどこまで統一されているのか」(田口氏)の質問に対しては、「マスタは割り切り、国内の販売系のみ統一している。生産系、特に工場の生産部品マスタは複雑な構成であるため、統合していない。製品そのものとリペアパーツ、得意先のマスタは合わせている。これは国内の映像系システム、国内の医療系システム、輸出用システム、部品管理システム、倉庫システムと複数あったが、比較的出所は近かったのでマスタの統一はそれほど大変ではなかった。製品、リペアパーツは近かったので、古いマスタをクレンジングして統合した」と石橋氏。
シグマクシスの濱田氏からは、「グローバルな情報を一元化し、現場でも共有化するのであれば、辞書を各国に渡す必要はないのでは」という質問があった。西河氏は「確かにおっしゃるとおり。しかしグローバル情報の共通言語ができれば、現地で最初から合わせてもらうことも考えている」と答えた。続けて西河氏は「コードや勘定科目などの根本から統一する方法が難しいのは、世界中のオリンパスが協力しないとできないから。現地には現地の理屈があって、今の仕事のやり方がある。それを説得するのに膨大なエネルギーが必要になる。私たちが採用した辞書方式であれば、日本が頑張ればできるから、確実にできる。私たちが採用した辞書方式であれば、日本サイドが頑張れば確実にできる」と語った。
クシダ経営研究所代表の串田昭治氏は「基本的なことになるが、バラバラのマスタデータをどうやって統合したのか。もう少し詳しく知りたい」と質問。西河氏は「米国でSAPを入れるとすると、SAPに合わせて仕事のやり方を変えることは比較的容易にできる。一方、日本人は仕事にこだわりがあるので、なかなかSAPをそのまま入れることができない。ビジネスのバリューにしたがって、カスタマイズする、しないを決定した」と回答。石橋氏も続けて「アドオン開発は、その費用を2年間で回収できるようなものに限定した。開発費用とそれを効率化することで削減される金額を算出し、それを示すことで現場に納得してもらった」と答えた。「効率化ではなくて仕組みとして必要だという現場の反論もあるのでは」(串田氏)という質問に対しては、「修理サービスシステムを構築した際は、顧客価値を基準に判断した。顧客が本当に求めているのかを徹底的に議論して、必要かどうか決定した」(石橋氏)と回答。「データ入力のタイミングなどが遅れてしまうことを防ぐ手立てはあるのか」という質問に対しては、「誰がどんなタイミングで情報を登録しているか、だれもがチェックできるようになっている。これによりデータ精度が高まっている」(石橋氏)という。
「SAPのERPパッケージに業務プロセスを合わせたというイメージに近いのか」(山田氏)という質問に対して、石橋氏は「アドオン開発がかなりの数に及んだことから考えれば、パッケージに合わせたとは言いがたい」と答えた。「開発ルールやドキュメントの統合などが必要だと思うのだが、そのあたりはどうしたのか」(IT記者会の佃氏)の質問に対し、「プライムベンダーのノウハウにかなり頼った」と石橋氏。「ERP導入は初めてだったため、そのようなノウハウはあまり必要ないと甘く考えてしまい、準備のために2年を要した。プロセスがしっかりしていてマスタ構造ができていれば、ERPの導入は1年もあれば可能だと思う」石橋氏。さらに佃氏からシステム構築に携わった人員構成について質問があった。データの一元化が成功するかどうかは、情報システム部門のかかわり具合によるところが大きいからだという。石橋氏はこの問に対して、「私が携わったCRMシステムは最新モジュールだったため、プライムベンダーを置かず、SAPに入ってもらった。プロジェクト人数は最大で30人規模だったが、そのうち3分の1は社員である。映像の販売物流プロジェクトの人数は、最大で100人程度。そのうち社員が20〜30人である」と答えた。
「今日の講演およびその後の質疑応答は、データの一元化をどうすればできるか悩んでいる企業にとって、非常に参考になったと思う。これからも本研究会ではどんどん、企業に役立つ情報を発信していきたい」と田口氏の言葉で、会は終了した。