全社IT最適化のカギは「データ体系の統一」：何かがおかしいIT化の進め方（5）

前回に引き続き、「情報システムの最適化」という問題について考えてみる。今回は「アプリケーション」と「データ体系」について取り上げよう。

　情報システムの最適化を求めて、前回はハードウェア設備やソフトウェアの標準化という、技術標準＝システムの“器”の問題について記した。今回はこの上で動くアプリケーション・システムと、その基盤となるデータの体系の問題について考えてみよう。

情報システムは業務プロセスを固定化する―― 情報システムが合理化の対象に？

　多くの企業では事業別、機能別の組織体制が取られている。このような縦割りの体制の中では、部門固有の業務や組織内部についての効率化や最適化の意識は働いていても、部門を超えた業務の流れ全体の効率化や、関係組織全体をとらえた最適化の意識はなかなか働きにくい。長い間同じ体制を続けているうちに、部門間の業務の重複や調整業務が無視できない規模になっていたり、誰も手を付けようとしない部門間のすき間問題があったりして、全体から見れば人・物・金の経営資源が無駄に使われていることがよくある。

　今日では経営にかかわる多くの情報をコンピュータ情報システムに依存しているが、それらの多くは、部門別・機能別の縦割りの管理体制にある部門の要請に応じる形で、時々の状況に合わせて開発された「縦割りのシステム」であろう。業務や組織の管理体制と同様、情報システムも部門完結・部分最適になっている。

　全体（全社やグループ企業全体）の整合性が考えられているわけではないから、システム相互間に重複部分があったり、連携運用するためのシステム間インターフェイス・システムに多大のメンテナンス・コストが発生している。実体組織上で起こっている問題点が、そっくり情報システムの上に持ち込まれている。合理化のツールであるべき情報システムが実は合理化の対象になってしまっているのだ。

　情報システムには、良くも悪くも業務プロセスを固定化する特性がある。業務プロセスの革新が求められる昨今、業務の見直しや改革をしないまま情報システムを作っていたなら、情報システムが改革・革新の足を引っ張る存在になっている可能性がある。部門間をまたがる問題について検討を怠ると、個々の情報システムの範囲や構成といった基本部分での問題の要因につながる場合があるので、特に留意しておかなければならない。情報システム構築は、業務改革と表裏一体・同時並行に進めなければならない。

　目前のユーザーニーズは、確かに大切ではある。しかしこれだけを実現しようとする姿勢では、上記のような部分最適のわなに陥る。情報システムの企画担当には、「ユーザーニーズの実現」という遠心力に対するサービス機能と、「全社最適の実現」という求心力である統括機能とのバランスが求められる。このためには業務プロセスの最適化に対する概念や将来の方向性への理解・認識が必須になる。

　「何が重要か」の内容は、業界の構造や自社の戦略によって異なる。例えば、サプライチェーン管理の問題でも「競争力の確保にどのように重要な問題か」といった観点から考えてみると、業種によってその位置付けはかなり異なってくる。具体的には、

• 財務や物流問題として在庫の適正化が中心課題と考えておけばよい業種
• ライフサイクルの短い業種で新製品の発売立ち上げを円滑に行うという、販売戦略をサポートする道具と位置付けている企業
• 製品の安全性からトレース管理が重要な製品

など、同じ“サプライチェーン管理”という言葉であっても、その狙いの違いが内容や運用の違いに表れてくる。

　自社の主な業務プロセスについて、業界の構造や自社の戦略を基に、その方向性について“あたらずといえども遠からず”のレベルででも検討・整理してみると見えてくることがいろいろあると思う。

　多くの情報システムが、テーマごとのプロジェクト体制で企画・開発された結果、システム間でのデータの整合性に問題が起こる。情報システム部門には、全社の統括機能（求心力）として、データ体系の統一、標準化を全システムに徹底していく責任がある。

データや情報は相互連携により価値が生まれる

　職場で「戸棚や机の引き出しの中を整理しましょう」「重複した資料は廃棄しましょう」といったプロジェクトがときどきある。各自の机の引き出しにあった機器やソフトのカタログは、最新版1部が資料室のしかるべき場所に保管され、残りは廃棄される。各種資料類も正式資料1部だけを残し、そのほかは焼却やシュレッダー行き。廃棄資料の山を前にオフィスの大掃除、ファイリング作戦は大成功となるのだが、翌日から「これじゃ仕事にならないよ」といった状況になるケースがよくある。ファイリング・システムのコンサルタントなどが指導に入り、話を真に受けて徹底的にやったときなどには、特に悲惨になる。

　机の引き出しが、「各自のパソコンのディスク」に変わった今日でも問題は同じであろう。例えば機器のカタログは、この機器を使うシステムの計画書や設計書、プロジェクトの議事録などの関係書類と一緒に問題別のファイルにとじられているところに意味がある。

　つまり、計画書にある機器リストの参照用の具体データとして保管されたり、あるいは設計書の場合、設計仕様の前提条件のデータとして同じファイルに綴じられていることによって、関連付けや情報補完が暗黙的になされる。書類の組み合わせを見て、初めて設計者の意図が「なるほど」と納得できるような場合があったりする。つまり、この“組み合わせ（リンク）”こそが知識や知恵としての大切な情報であり、情報活用とはこのリンクを作ることにほかならない。上記のケースで「仕事にならなくなった」のは、情報の「活用」より「保管」の効率性を優先させた結果、リンク＝知識や知恵の情報が消失してしまったためである。

　裏返せば「単体では事実を表しただけの単なるデータが、ある特定の目的とつながり（リンク）を持ち、またほかのデータや知識と組み合わされた（リンクされた）ときに、情報として大きな価値を持つ」こととなる。これは情報やデータの持つ基本的な性格である。

　こんな情報活用の観点から情報システムを考えてみよう。

情報システムの在り方

　データ・情報の活用には、

1. 業務上の必要性
2. 「データや情報の組み合わせによって何が分かるか」という、これに携わる人の知恵や知識と分析力
3. 必要なデータの整備
4. データ検索や分析ツール

　これらがバランスよく保たれていることが条件だ。この「業務」「人」「データ」「コンピュータ」の4つがワンセットというのが、情報システム本来の姿であろう。

　効果を出す条件として重要なのは、1→2→3→4の順だ（番号が大きくなるほど代替手段がある）。だが「情報共有」や「情報活用」などの掛け声の下、この逆の順の発想や行動で、回収のめどのないコスト先行型になってはいなかったであろうか。

　まず1について説明しよう。企業環境が変われば新しいニーズが発生する。組織の管理レベル（経営習熟度）が上がれば、それに応じて情報活用の幅も広がる。こうして循環プロセスをたどりながら、企業の時々の条件で変化していく。しかし具体的なニーズのないことをいくらやっても評価されないし、たとえ結果的に役に立つことであっても恐ろしく効率の悪い作業になる。

　2については、かなり属人的な面は残るが、1の強い業務ニーズがあれば、経験によりあるレベルまでは向上していくという面がある。実際には、管理レベルが高くない状態においては意欲的な特定の個人の努力や実績が引き金になり、やがて組織全体のレベルが上がるが、あるレベルにまで達すると、より高度の問題に対して資質のある特定の個人の活躍に期待するといったパターンをたどるように思う。

　3のデータの整備では「安心して使えるデータ」が必須要件となる。この問題を以下のテーマとしたい。4の道具立てについては、目的や用途によって適切なものが異なってくるし、また時々でさらに優れた商品も出てくるが、ある水準に達していれば、使う人にとって「使い慣れた道具や手法を使いこなすのが最良」という問題である。少なくとも「最新の道具や新手法を適用したから成功した」といったケースはまれである。多くの場合、成否を分ける鍵は道具や手法の外にある。次々発表される道具や手法に振り回されないことだ。

データ体系の整備は避けて通れない

　 組織の管理レベルの向上とともに「問題を幅広く、より深くとらえよう」とするようになる。1つの業務機能や部門の枠を超えて問題をとらえる、つまり1つの情報システムの枠を超えて複数の情報システムからデータや情報を得て問題を検討し、業務を管理したいという要求が生まれてくる。

　例えば、「顧客情報管理（CRM）システムの顧客特性と、販売管理システムの販売状況や、営業支援システム（SFA）の顧客訪問内容を突き合わせて営業の作戦を考えたい」、あるいは「購買・生産管理システムと販売・物流システムのデータを組み合わせ、SCMを実現したい」……などなど。このとき複数のシステム間でデータの整合性、さらにいえば人の頭の中にあるデータの概念との整合性が問題になる。

　“今日の在庫”と一口にいっても“現在倉庫にある物理的な数量”のことなのか、“先日付で受けた明後日出荷分を引き当て後の数値”を指すのか、データの意味の定義が明確でないと安心できない。同じ対象でも分類の仕方やコード体系が統一されていないとデータ使用が困難になる。このようなことが方々で起こってくるので、全社のすべてのデータ間で整合性が結果的に必要ということになる。

　人事システムと経理システムで組織のとらえ方が違う、生産部門と販売部門で品目のくくり方が異なる、異なる事業部門間や購買部門との間で取引先のコードが異なる……などになってはいないだろうか。メンテナンス頻度の高いシステムなどで、納期に追われ、便宜的なつじつま合わせでお茶を濁していた結果、データファイルの“XX区分”といったフィールドが本来とは違った目的に使われていたりはしないだろうか。

　また、“リアルタイム経営”などといった言葉がささやかれる昨今、今後ますますシビアな管理が求められるようになれば、データの収集タイミングの整合性を意識しなければならなくなる。片方のシステムでは日次データが合っても、もう一方のシステムは週次のデータしかなければ意味はない。あるいは同じ日次データであっても、一方が3日遅れのデータなら、レベルの低い方に合わさざるを得ない。情報活用のレベルが上がってくればいろいろのシステム間でこのような問題が顕在化してくる。大げさにいえば、全社の最もレベルの低いシステムやデータが全体のレベルを決めてしまうことになる。

　グループ経営が前提の時代である。グループ内でのデータ整合性が必要になるわけであるが、グループ内の関係会社はそれぞれの成り立ちにより、さまざまな管理体系や情報システムを有している。情報化の歴史の長い関係会社を持つところほど苦労が多いのは、このためだ。

　会計分野でも、それぞれが独自の会計規準や費目の体系を持ち、独自の情報システムを運用している。もちろんコード体系の統一とはほど遠い状態にある。こんなバラバラな状況でも4半期の“連結決算”までなら、連結決算システムを使って経理担当者が苦労しながら何とかこなせるだろう。しかし製造と販売が別会社のようなケースで、リアルタイムに近い形でデータ交換が必要になる日常業務の“連結経営（管理）”といった問題までを真剣に考えると、グループ内でのデータ体系の整合性は避けては通れない問題になると思う。

現在データ体系の標準化ががなされていない場合は

　まず着手すべきは、

• マスタデータ項目の統一・標準化
• 上記を基にしたコード体系の標準化
• 上2つの取り組みに基づき、現行システムに対する最小限のシステム修正の計画的実施

である。かなり時間を要する作業となり、また社内各部門との調整が必要になるが、これだけでも現行システムの将来への適応性は相当に高まるはずだ。また、今後さらに情報化を進めていこうとする企業にとって、標準化は避けて通れない問題である。

　マスタデータ設定のポイントは、組織なら会社の組織図上の具体的組織に、品目なら具体的（物理的）な製品に1対1で対応させること。運用に際しては、「機能的に同じ扱いになるから」といった発想に基づく便宜的な扱いや例外を一切排除することである。情報システム上のデータは“処理”より“活用”を優先する考え方を中心に据え、厳格なマスタ管理の徹底が必須である。

　情報システム企画や全社統括の立場にある人と実務のベテランが協力して、ある時期、全業務のうち10％程度の時間を割いてでも、情報化のグランドデザイン作りの手始めとしてぜひ進めてほしい課題である。「目前の仕事に忙しくてそれどころではない」と思う人は「なぜ、いまそんなに忙しいのか」、その理由を考えてみていただきたい。要は、「先を見越したこのような整備を怠ってきたため」という要素ではないだろうか。「目先にこだわってやっているいまの仕事が、将来の忙しさを作っている」ことにはならないだろうか。悪循環を断ち切るのは、いましかない。