今まで紹介されてきた知識マネジメント的な目新しいサービスというよりも、今回は企業等で使われている商品情報データベースやナレッジマネジメントサービスの潮流を中心にした、別の角度からの事例紹介をします。
データを記録するものをこのように分類をして、各々の相関関係や類似性・特徴などを考えて行きます。
これらの中でも、今回はデータベースが話の中心です。
データベースには一般に知られ使われているものとしてリレーショナルデータベース、即ち、ACCESSやSQLserver、Oracleなどと、それ程知られていないけれどMAC系のソフトウェアだった、ファイルメーカーのようなカード型データベースがあります。
(*最近稀に企業でも部分的にファイルメーカーを導入している事例をみるようになりました。)
このなかのeBASEはACCESS及びSQLserverをカード型データベースのように運用させたソフトウェアです。
データベースの構造的な側面から比較してみます。
RDB以外は、実はよく似ていています。
それはデータベースの正規化が不要なので、データベース項目の追加が可能である点です。
RDBではデータベースの正規化をしなければなりませんが、一度正規化を経て構築されたデータベースに項目を追加することはできません。項目を追加する場合には、もう一度初めからデータベースを構築し直して、データを移行せねばならず、大きな作業負荷がかかります。
しかし、最近は社会的環境、経済的環境、法律的環境の変化が早く、すぐに項目追加の必要がでてきます。
例えば、エコロジーに関する法律が施行されたり、取引先からエコロジーに関する項目の提供を新たに求められるようになるなど、様々です。
ですから商品情報データベースなどでは、伝統的なＲＤＢは使いにくくなっています。
eBASEは、RDBのデータベース項目を「項目名」と「値」と定義しているだけなので、自由に項目を追加できます。実質的なデータは縦に長い１つのテーブルに収められることになります。
(ひたすら縦に長く書き連ねるだけでは、検索速度が遅くなるのですが、それを回避する構造は別途持っています。)
このように１枚のテキストファイルに<項目名>値と縦にデータを書き連ねるXMLとデータベースのテーブルに縦に長く書き連ねるeBASEは非常によく似た構造だと言えます。
情報を管理するＤＢとしては、テキスト以外のデータ、画像、動画、音声、Officeなど様々なアプリケーションで作られたファイル、などもＤＢに格納し管理する必要があります。
・これらのファイルをＤＢの外のフォルダで管理する方がＤＢ自身のファイルサイズは小さくて済みます。
またＤＢの項目は用途に応じて、必要な項目を、用途に応じて理解しやすいレイアウトで表示する方が合理的です。
次にデータの入力について考えます。
多くの商品情報ＤＢは構築運用に失敗します。
(1)社外(仕入先)などから帳票(手書き、EXCEL)などで貰った商品情報を、社内の担当者がＤＢに入力する場合。
・入力ミス、入力のタイムラグが発生する。
・入力負荷やコストパフォーマンスから、取引会計上最低限の情報(価格、仕入値等)、物流上最低限の情報(サイズ、重量等)までが入力運用できる限度なので情報量が少ない。
(2)社内のＤＢ構築担当部門が入力する。
・単純作業なので、入力担当者のモチベーションが上がらない。
・商品情報が確定し、入力可能になる頃には、商談等の活用の場は殆ど終了していて、情報として役に立たない。
↓
タイミングが遅れた、最低限の情報しかないので、誰も閲覧しなくなる。
誰も閲覧しないから、入力も疎かになる。
だから外部による情報登録が有効になります。
仕入先から帳票ではなく、直接商品情報の登録データを貰う。
印刷会社がカタログやパンフレット制作用に作成したデジタルデータを貰う。
などの方法です。
この時に、データ登録はWEBブラウザの入力画面を通じた登録が良く考えられますが、これは実際の運用上難しい面が実はあります。
WEB画面での入力では、まず回線の問題があります。まだまだ地方の取引先ではISDNなどの回線しか使えない地域があり、このように回線が細いと、画面表示が遅い、データ登録処理が遅いなどの問題が発生します。
また実際の業務上では来客などで登録業務を中断させられた時に保存を忘れると、経時でセッションアウトし、登録データを失うことがあります、(このBloggerは自動保存機能が強力でいささか驚いていますが、稀な対応です。)
また登録データは入力者側(C社)ではなく、登録先(A社やB社)にあるので、登録データの閲覧の不自由さと、登録先が複数(A社とB社など)あると、何度も類似のデータを登録しなおす必要があります。
入力者側(D社)のローカルでデータを登録して、そのデータを複数の登録先に振り分けて送信する形にすると、入力は一度で、複数の登録先の登録ができ、入力者側にもデータが残ります。
送信もHTTPなどでバッチで送るので、回線の太さの影響もありません。
このようにして構築されたＤＢに以下のような例があります。
＜補遺＞
1. HyperCard
・http://www011.upp.so-net.ne.jp/PARK/
・http://ja.wikipedia.org/wiki/HyperCard
2.ファイルメーカー
・http://www.filemaker.co.jp/
3.Gamedios
・http://www.gamedios.com/
4.eBASE
・http://www.ebase.co.jp/
5.LotusNotes
・http://www-06.ibm.com/software/jp/lotus/
・http://e-words.jp/w/Lotus20Notes.html
6.サイボウズ
・http://cybozu.co.jp/
0 件のコメント:
コメントを投稿