» 【第54号】データ流通の条件

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第54号】データ流通の条件

DRI通信54号「データ流通の条件」 2001.3.1
3月の声を聞いて、陽射しが一段と明るくなってまいりました。政治・経済
の低調を吹き飛ばしていきたいものです。広域データ流通は、広域のデータ
標準化・調整、すなわち政治・マネージメント・人間的努力の継続が要求さ
れます。即効を求める風潮の中にあって、これを業とする弊社の経営はなか
なか難しいものがありますが、皆様のご理解に支えられて今期もなんとか乗
り切れる見通しがついてまいりました。今後とも頑張ってまいりますのでよ
ろしくお願いします。
先回は、「アプリケーションソフトウエアには、非常に性質の違った2種類
すなわち、a.業務アプリケーション、およびb.システムアプリケーション
がある」という話題をとりあげましたが、次のようないろいろなご意見をいた
だきました。
(1)OOAとDOAの適用という面から考えてみましたが、この点だけ考え
ると2種類に分類してもあまり意味はないように思われます。
(2)a,bのアプリケーションの分類とOOAとの適用性は最近の私の認
識と一致しています。「DOAとOOAは対峙するものではないのではないか」
そして
1)事柄の認識(DOAはそのひとつ)
2)プログラム開発の都合による事柄の設定(OOAはそのひとつ)
のように考えたい。
(3)大きくは確かにこの分類でよいと私も思います。しかし、DOAの適
用領域という考え方をしますと、業務アプリケーションは、もう少し細分
化する必要があると私は思っています。近年の動きを見ますと、従来型の基
幹系、情報系のほかに、ワークフロー等を取り扱う報連相系ともいうべきも
の、さらにはこれらを包含した、B2BやB2Cが登場してきています。こ
れらのものも、業務アプリケーションに含まれます。
さて今月はERP、SCM、CRMなどによって追求されている「データ流
通」について考えてみます。データの流通は、自と至とのインターフェース
が一致することによって可能となります。インターフェースはデータ項目か
ら構成されますから、これらデータ項目の一つ一つの意味・仕様が一致しな
ければなりません。またそれさえ満たされれば十分であり、処理仕様は問い
ません。すなわちインターフェースと処理仕様は独立に扱うことができます。


システム開発の歴史は、省力化と全体最適化のための、新しいITの取り込
みとシステム大規模化/データ流通範囲の拡大の歴史であったと言えますが、
インターフェースと処理仕様の独立化にはあまり頓着せず、無用な複雑さを
背負い込んできたのではないでしょうか。
■イベントを扱うインター統合
ERPは、ローカル・クローズドアプローチで作られた孤島システムをリプ
レースする、一企業内のイントラ統合を狙うものと言えます。出荷に基づく
在庫データのリアルタイム更新など、整合性を重視するOLTP処理を含む
こともあって、現在のERPは規模は大きくてもいぜんローカル・クローズ
ドアプローチの影を色濃く残しています。一企業を越えたSCMやCRMの
ための統合には、もはやこのアプローチは無理でしょう。確定した静的な
イベントデータ(トランザクション)を扱うグローバル・オープンアプロー
チのインター統合が要求されているものと思われます。
イベントは、本来「誰が、いつ、どこで、何を、どれだけ」といったデータ
からなる1レコードから構成されるものと考えられます。そして情報処理や
物流、決済などの便宜から、たとえば「誰が、いつ、どこで」が共通なもの
を括って親レコードを作り、階層構造化する。このため「イベントにはネッ
トワーク構造はない(?)」ものかと思われます。XMLの適用が騒がれる
ゆえんでもあります。
以下イベントにおけるデータ流通を検討しますが、分かりやすさのため、発
注・受注を事例に考えます。
■データの意味
文章が正しく伝わるためには、文章の構造と単語の意味が正しく伝わらなけ
ればなりません。同様にイベントが正しく受け止められるためには、そのイ
ベント種別と「誰が、いつ、どこで、何を、どれだけ」などを表すデータ項
目(のコード化された値)の意味が正しく伝わらなければなりません。
まずイベント名とデータ項目名が、取っ掛かりになりますが、文化の違う二つ
の組織の間、たとえば企業B1と企業B2の間では、たとえ名前(たとえば
「品種」)が同じでも同じ意味を表すとは限らず、また逆に異なった名前(
たとえば「顧客」と「帳合先」)でも同じ意味を表していることが多々あり
ます。一般にはイベント種別については、他のエンティティとの関係が同じ
かどうかで総合的に判断し、データ項目については同じイベントにおいて、
同じ役割(誰が、何を、など)を果たしているか否かから判定!することに
なります。
データタイプや桁数など物理的な仕様は変換によって明快に解決できますが、
意味の伝達は思ったより難しい。「いつ、どこで、どれだけ」は比較的簡単です
が、「誰が、何を」が特に難しいものです。
■イベントの種別
注文と言うイベントを、買う側から見たものが発注であり、売る側から見たも
のが受注で、本来同じイベントです。その意味では、引当や出荷指図は別と
して、受注入力と言う作業は極めて不合理で、発注者の作ったデータをその
まま受けるEDIはシステムとしての本来の姿と言えます。
この注文にも次のようにいろいろな種類があり、それぞれ独自のデータ項目
が必要となります。
・物品注文と工事やサービスの注文
・社内、国内、海外、3国間
・出荷をカンバンなどで別途指示する契約に近い注文
・商社、帳合いなど流通チャネルのからむ、最終ユーザや用途を意識するもの
・受入検査の厳しいもの
・売掛け金決済、手形決済
・要担保
・インセンティブあり、ペナルティあり
・材料支給あり
・返品
これらは注文のサブタイプとすることができますが、企業によってはあるサ
ブタイプしか扱っておらず、そのような企業同士ではインターフェースの調
整が難しくなることがあります。「いつ、どこに、何を、どれだけ」以外の
データは、特にB2Bでは変更が少ないので、都度のイベントデータからその
詳細を外し、基本契約データないしリソース(標準)データとして扱うのが
得策と考えられます。これによって多様なサブタイプの発生を押さえること
ができるでしょう。
■データ項目値の範囲と制約の考慮
同じイベント種別で、同じ役割のデータ(たとえば品名)だが、カバーする
範囲が違うということがあります。受注側のカバーする範囲が大きければ、
すべてに対応できますが、逆ならばカバーできる範囲についてのみ対応でき
ることになります。ビジネスとしては問題があるとしても、情報システムと
しては問題が無いと言えます。
発注側企業において、たとえば発注部署と品種にある制約があるとしても、
受注側はこれを意識する必要はないようです。すなわちイベントに含まれる
リソースについての認識(KEYと実体の対応およびサブタイプに切り分け
るときの本質分類)は同じでなければなりませんが、そのリソース間の制約
関係などは両者で同じである必要はない(共用の必要はない)わけです。
■物品コード
注文イベントにおいて、最も問題となる物品コードについて考えます。コー
ドは1物1価が原則ですが、タイプリソースである物品については、何が1
物かが難しい。物品は一般に
・機能(形状)
・材質(コーティング、色も含める)
・寸法(縦・横・高さ・厚さ)
によって規定されます(注参照)が、どこまで同じなら同じ物、1物と見る
かが決めにくい。
一般にユーザは粗く、サプライヤーは細かくみます。菊正と大関は明らかに
違う物品ですが、ある飲ん兵衛にとっては同じ物品−代替物品−です。した
がってユーザの指定する1商品に対しサプライヤーのn製品が対応すること
になります。ユーザの指定する商品のレベルは粗い場合もあるし細かい場合
もあるので、いくつかのレベルのサブタイプについて物品コードを用意し、
関連付けて対応する必要があります。
(商品) (製品)
粗い 細かい 各種代替品
A−−−A1−−−−−A11、A12、A13

・−−−A2−−−−−A21、A22
このサプライヤーはまたその部品の購入についてはユーザの立場に立ちます
から、1部品についてn種の代替部品を持つことになります。厳密に言えば
どの代替部品を使用するかによって原価の異なる別の製品となりますが、こ
れをどう扱うべきかは難しいようです。
(注)機能、材質、寸法では、パソコンなどはうまく表現できない。もう少し
抽象化して、機能、性能、大きさにすれば、パソコンのスピードは性能、メ
モリサイズは大きさとして扱えそう。
■組織コード
組織はオカレンスリソースであり、識別しやすいように思われますが、合併、
分割、マネジャー交代、メンバー交代などにより、実体が変化します。一般
には注文レコードの発生から引退までは十分短く、また相手企業を法人レベ
ルで把握しているため、日常的な問題にはならないようですが、通常、組織
の変更はシステム的に通達されないため、リソースファイルの劣化を引き起
こし、寿命の長い契約ファイルや、時系列で見る要約ファイルなどの処理に
問題を生じます。