経営視点で真に有益な情報共有は、「情報」ではなく「データの関係づけ」で実現される


Last Updated on 2020年12月1日 by 時代遅れコンサルタント

現状の単なる電子化では、情報共有は失敗する

オフィスでは、協働作業を促進するために様々な情報が飛び交っています。そして、その過程で多くの問題が引き起こされています。

たとえば、営業が海外の顧客から受け取った提案依頼を開発に転送する、などのことがあります。通常、提案依頼は一度では済まず、提案依頼そのものが何度か修正されて伝えられます。

この時に、伝達のズレが起こります。顧客から受け取った修正提案依頼を営業が開発に伝えるのが遅れたり、最悪の場合は忘れてしまったりするのです。

そうなると、開発は最新ではない提案依頼をもとに作業を進めてしまい、ズレに気付いた時の手戻りが大きくなったり、ズレたままの情報をもとに提案してしまったりするなどの問題が生じます。

このような事態を避けるために「情報共有化プロジェクト」が提案されます。電子的に一元化されたデータベースを作り、そこに修正版を遅滞なく入れておけば、常に最新版を検索できるのでこのようなビジネス上の失態は避けられるという訳です。

ところが、この種の情報共有化プロジェクトが成功する確率が極めて低いのです。なぜでしょうか?

その理由は、それらのプロジェクトが現存の情報を電子化しさえすれば問題が解決すると想定しているからです。実は情報共有化には業務の見直しが不可欠であることを見落としているのです。

情報共有プロジェクトに関係するコンサルタントは、このことに気づいていないと思わぬ失敗に巻き揉まれるので、要注意です。

共有できるのはデータ、情報ではない

そもそも、ビジネスで情報共有のメリットが出るのは、どこかの部門で入手・作成された情報が他の部門に伝達され、その部門の目的に合った(新たな)情報が生成されるからです。

情報共有とは、静的な一つの情報が共有されるのではなく、ある情報から別の情報が生成され、それが新たな意味を持つ動的なプロセスです。そして、情報共有の媒介として伝達されるのは情報そのものではなく、その元となるデータなのです。

英語版のWikipediaを見ると情報とデータについて、次のように書かれています。(日本語版のWikipediaは用語の定義が不十分なものが多いので、今の目的には使えず要注意です。)

Data is collected and analyzed to create information suitable for making decisions

データを分析することにより意思決定用の情報が作り出されるのですから、情報にはそれを作り出す人の解釈が伴うことがわかります。同じデータからでも、立場によって求める情報が異なるのです。

つまり、共有すべきはデータであるにも拘らず、共有されるべき同一情報が存在するかのように誤認することが、情報共有プロジェクトの失敗の原因なのです。

このことを、もう少し詳しく検討してみましょう。

同じ「顧客情報」でも、それが意味するものは各部門で異なる

よく見られる「顧客情報共有化」の議論の内容を分析してみましょう。

Aさんという顧客はだれが見ても、Aさんという同一人物です。したがって、部門Pと部門QでAさんに関する情報が重複して存在し、しかもその2つでAさんの住所が異なっていたとすれば、それを解決しようとデータベースを一元化することに反対する人はいないでしょう。

しかし、これだけで情報共有化プロジェクトをスタートさせ躓いてしまうケースが頻発しています。その理由は、各部門の「顧客」に対する興味は大きく違っていることを認識しないからです。

たとえば、Aさんが通信販売で商品を買ったとすると、受付部門は自分の仕事を済ませるためにはAさんが買った商品の番号とクレジットカード番号および氏名・住所が必要です。受付部門にとっては、「顧客」とは購入者なのです。

しかし、出荷部門はこのうちの氏名・住所だけしか必要としません。出荷部門にとっては、「顧客」とは単なる送り先であり、そのためには氏名と住所というデータだけがあれば良いのです。

一方、マーケティング部門は、どのような商品がどのような消費者に売れるのかを調べるため、Aさんの性別、年齢、趣味などの情報を欲しがります。クレジットカード番号には見向きもしません。

マーケティング部門にとっては、「顧客」とは、商品の購入ニーズに関係する属性を持った人なのです。

マーケティング部門のニーズを満たすためには、受付部門は自分たちの受付職務を果たすだけでなく、Aさんの購入ニーズに関する属性データを獲得するように、自分たちのビジネス・プロセスを変える必要が出てくるのです。

このように、受付部門、出荷部門、マーケティング部門は、同じ「顧客」という言葉で異なった情報を必要としています。この人たちが必要としているのは、それらの情報を抜き出す元となる統合データの共有なのです。

情報共有を促進するためには、各部門が必要としている情報を分析し、その情報生成の手がかりとなるデータを獲得・一元管理する必要があるのです。このようなビジネス・プロセスの変革なしに、単に今あるデータを共有しようとしても、「情報共有」は進まないのです。

「情報共有」を促進するのは「データの連携」

この問題の解決策を、もう少しリアルな例で検討してみましょう。製造業における、品質試験の例です。

製品開発においては、設計情報をもとに試作をして、それが求める機能を果たすことを確認する機能試験、大量に生産しても問題なく組み立てられるかを確認する量産試験などを行います。

この試験を品質保証部門が担当し、試験結果を「品質事故連絡表」などといった形式の資料にまとめ、設計にフィードバックします。そして、設計は品質事故を解消するように設計変更を行います。

この時点では、設計及び品質保証の両者の目的は、製品開発を期限内に終了させることです。この目的に従って、品質事故連絡表は、製品開発プロジェクトごとに管理されます。つまり、開発プロジェクトの試験フェーズごとに番号付けするのが自然ということになります。(図①左下部分)

ところが、同じ設計が次の開発プロジェクトに移った時、情報ニーズは一変します。設計は、自分が設計に使用しようとしている部品が過去にどのような品質事故を起こしたかを調べようとします。

調査対象は同じ品質事故連絡表なのですが、それを部品ごとに調査したいのです。同じ品質事故を見る切り口が「部品ごとの品質事故」に変わるのです。 (図①右上部分)

上述の「開発プロジェクトの試験フェーズごとの品質事故」という切り口は、この作業に非常に不向きで設計作業の能率を大幅に下げます。ついつい調査がいい加減になり、その結果過去の起こった品質事故を繰り返してしまうという事態も度々起こります。

このような問題を避けるための「情報共有」はどう実現すればよいでしょうか?

その解決策は、図②のような対応表を作り、複数の切り口で品質事故を見ることを可能にすることです。

この表を作成する作業は概念的には次の1、2のように簡単ですが、技術的には2はデータベース構造の変更を伴うので、それなりの注意が必要な作業となります。(後述)

  1. 品質保証部門がそれぞれの品質事故連絡表にどの部品が関係しているかのデータを記録する
  2. 設計が部品番号からその部品が関係している品質事故連絡表を見つけられるようにする

データ・モデリング

経営視点で重要なのは、全社データの関係付け(データ・モデリング)

この解決策が意味していることは、各部門の「情報共有」を促進するためには、それぞれの部門が自部門の目的にあった情報を抽出するための手がかりとなる「データを共有」することです。

しかし、そこで解決しなければならない別の問題があります。それは、情報を生成する手がかりとなるデータを必要とする部門(データの利用部門)と、そのデータを生成する部門が異なり、後者にはデータ生成の直接の動機はないということです。

購入者の性別、年齢、趣味などのデータは受付部門の仕事の遂行には必要ありません。機能試験や量産試験における品質保証の仕事には、品質自己連絡表と部品番号を紐づけることは必要ありません。

したがって、後続部門が必要とするデータの取得やデータの関連づけを行って「情報共有」を実現するには、全社的な見地からの判断が必要となります。

この中で、通信販売の例での趣味などのデータ取得は、全社的合意が得られれば比較的感単に実現できます。データベース中の顧客データの中に趣味などの項目を格納する場所を追加し、受付業務のプロセスにこれらのデータの取得作業を加えれば良いからです。

しかし、部品番号からの品質事故連絡表の検索は、そう簡単にはいきません。上述のように、部品番号という切り口の追加はデータベース構造の変更を伴うからです。

さらに、このケースで部品には設計変更があるというビジネス上の問題も考慮に入れる必要があります。

たとえば、部品のサイズが少し大きすぎて他の部品と干渉するという事故があったとしましょう。その事故を解決するために部品を小さくしたのですが、その分コストが高くなったとします。後続プロジェクトでそのような大きさ制限がない代わりにコストの制約が強い場合には、設計変更前の部品を流用したいでしょう。

そうなると、部品番号だけではなく、設計変更番号も加えて品質事故を検索できる必要が出てきます。さらに、企業によっては、この設計変更そのものをきちんと管理できておらず、そのやり方を見直す必要が出てくるケースも存在します。

このように、情報を抜き出す切り口としてどのようものを提供するかは、企業のビジネス方針および情報管理方針に関わる大きな問題なのです。

さらに、これらの方針を受けて、データとデータを関連付けてデータベース全体の構造を変革する作業が必要となります。このようなデータとデータの関連付け作業を、ITの世界ではデータ・モデリングと呼びます。

データ・モデリングはデータベース設計の根幹を為すのですが、上述の説明で分かるように、本来はビジネスの本質を理解していないとできない作業です。

ところが、この分野ではビジネス・コンサルタントとIT設計者の相互理解ができておらず、協業がうまく進んでいません。

クライアントの情報共有を促進しようとするコンサルタントは、データ・モデリングに関する基礎的な素養を身につけて、このギャップを克服するように努めるべきなのです。

何を学んだか?

  • オフィスでは、共同作業を促進するための様々な情報が飛び交っている。同時に、その伝達に関する行き違いによるビジネス上のロスが数多く生じている
  • このロスを解決するために「情報共有」プロジェクトが提案されるが、その成功確率は決して高くない。その理由は、共有すべき対象が情報そのものではなく、それを抽出する元となるデータであることを認識しないからである
  • 特に、データの共有で難しいのは、新たな情報を抜き出すための切り口データの追加である
  • どのような切り口の追加が必要かについては、ビジネス・ニーズの分析が必要である。また、具体的に切り口を追加してデータベース構造を変更するにはIT知識が必要である。したがって、「情報共有」プロジェクトの成功のためには、両者の連携が不可欠である
  • コンサルタントは、このビジネス知識とIT知識の連携を図るために、データ・モデリングの基礎知識を仕入れておくべきである