» 【第12号】DOAとERP

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

DRI通信12号 「DOAとERP」         1997.9.1
DRI通信もおかげさまで12号を数えることになりました。1年続いたわけで
す。EMAILアドレスを頂いた方には、とりあえず発信しておりますが、いま
500名くらいになっています。さらに転送していただいている方もありますの
で600名くらいの方に届いているのかもしれません。「非常に面白い」といっ
て下さる方もありますが、「難しくて読みきれない」などの声も頂いています。
雑音と思われる方は遠慮なくご連絡ください。すぐストップいたします。
最近いろいろな方から質問されるので、今回は「DOAとERP」について私の
きわめて個人的な見方を述べて見たいと思います。話としては、まずDOAの狙
う情報システムのあるべき姿を述べ、これをERPがどう実現しているかという
観点からみることにします。


■DOAはリポジトリを活用してイージーオーダーをねらう
DOAは、単にRDBを設計し、CASEツールを使ってプログラムを自動生成
しようというものではありません。データ項目を中心にシステムを構成する部品
を標準化し、その組み合わせによって、オーダーメイドでなくイージーオーダー
で迅速にビジネスニーズに対応するソフトウエアを作ろうというものです。
標準部品は共用のためにデータベースにストアします。エンドユーザだけでなく
システム関係者も紺屋の白袴をやめてデータベース技術を活用しようというわけ
です。このデータベースは最近リポジトリと呼ばれることが多くなってきました。
部品にはOSやDBMS、プログラム言語などの実装環境に影響されるソフトウ
エア部品(プログラムや物理ファイルなど)と、これには独立で純然と販売や生
産などのビジネスにのみに従属するビジネス部品(データ項目やエンティティ)
とにわけることができます。
実装環境はメインフレーム、オフコン、PCなどに応じて多種多様であり、ソフ
トウエア部品は、これらの実装環境ごとにつくられたn個のソフトウエアリポジ
トリに分割ストアするのが自然です。逆にビジネス部品は全社一括で1個のビジ
ネスモデルリポジトリにストアして整合性をとらなければなりません。
前者はITにより、また後者はビジネス環境により改訂を要請されますが、この
ようにn個のソフトウエアリポジトリと1個のビジネスモデルリポジトリに分割
することによって、保守の負担を最小化することができます。
ソフトウエアリポジトリはソフトウエア開発の上流から下流への工程統合を実現
する容れ物です。標準ソフトウエアリポジトリとインターフェースをもつCASE
ツールによってシームレスな工程統合が実現されます。一方ビジネスモデルリ
ポジトリは、販売、生産、経理、人事など分野統合を実現する容れ物です。デー
タモデリングによってデータ項目を一元化し、からみを制御することによって分
野統合が実現されます。
■データの地図とビジネスモデルリポジトリを活用
1社5千から5万といわれるデータ項目のからみを制御するのは簡単ではありま
せん。個人差の出ないエンジニアリング図面−−データの地図−−上にビジブル
に示して、関係者でいろいろな角度から検討して対処いたします。それはちょう
どビルを建てるとき平面図を、またプラントを建設するとき配管計装線図を使う
ようなものです。いまは図面のないブラックボックス化したビルをたくさんかか
えてメンテお手上げのようになった会社がたくさんあります。
一般企業がどうしても管理しなければならないのは、ビジネスモデルリポジトリ
です。その企業の戦略や戦術を反映したものだからです。近い将来、ビジネスモ
デルが規定され、実装環境が決められれば、ソフトウエアはほとんど自動的に生
成されるようになるのではないかと思われます。運用における信頼性はますます
重視されますから基幹システムのソフトウエアは原則としてソフトウエア専業社
にアウトソースされるのではないでしょうか。WWWが普及し、一般企業のユー
ザはイントラネット経由、ビジネスモデルのみを意識してソフトウエアを利用す
るようになると思われます。
BPRとはビジネスモデルの変更検討にほかなりませんから、DOAを実現でき
たところは日常茶飯事としてBPRを実施し競争優位を勝ち取るようになるでし
ょう。
■ERPの3つの心配
このようなDOA到達点イメージがどの程度当たるかは分かりませんが、仮に当
たったとして今のERPはどう評価できるのでしょうか。ERPパッケージにも
いろいろあり、一律に論ずる危険はありますが、敢えて言うならば私は次の点が
気になります。
(1)ビジネスモデルがビジブルでない。
(2)ビジネスモデルとソフトウエアが分離されていない
(3)プログラムプレハブである
(1)はユーザに分かりやすく個人差の出ない図面での表現が不十分ではないか
ということです。ほとんどの企業システムは固有の戦略を実装する部分、既存シ
ステムを生かしたい部分などを持ち、ERPパッケージで全とっかえすることが
できません。そのときどこまでをERPにすべきか境界線を引く必要が出てきま
す。このときビジネスモデル図上に線を引いて区分けしたい。しかしこれはいま
難しい。また「世界最高のビジネスモデルを実装したERPである」といっても、
それは十分説明されていません。ユーザとしては信じるしかないわけです。
(2)はまだビジネスモデルの概念が未熟なところから来ているものと思われま
す。管理対象としてソフトウエアしか念頭にないように見えます。ERPとして
分野統合をねらうとどうしても大規模になりますが、これを実装従属のソフトウ
エアの世界で実現しようとすると変更ニーズはビジネスとITとの掛け算で発生
する。ある1個のアプリケーションの変更が他にも影響する。アプリケーション
ごとに違った実装環境を用意することが難しい。これがERPにとって大きな課
題であると認識されてくるのはそう遠くないと思います。
(3)はDOAの追及が足りないところから来るものかと思われます。ビジネス
モデルを実現するために、どこまでをデータとして規定し、どこからをプログラ
ムで扱うべきかと、徹底的に追及していくとアプリケーションによらず汎用的に
用意できるロジックがかなり切り出されてきます。DBMS機能も、元はといえ
ばこうして切り出され、OSを支援すべく位置付けられたものです。この追及の
程度によっては、データで規定できるものをプログラムとして規定することにな
ります。データの仕様ならばカスタマイズは容易ですが、プログラムであると用
意されたパラメータを選択するといった方法でのカスタマイズになり限界があり
ます。プログラムプレハブで間に合うときは安直で良いのですが、将来的にはデ
ータプレハブが主流となってくるのではないでしょうか。
■ERPはひとつの実装手段
現状のビジネスルールが枝葉末節に囚われたもので、各地のユーザがこれに固執
し統一できないといった場合は、いまの融通のきかないERPがかえって統一化
に有効ということがあると思われます。しかし正統的にはビジネスモデルを描き
これに位置付けて、ERPはひとつの実装手段として活用すべきものと思われま
す。さもないとERPのパラメータを変更する達人−−それも悪くすると外注−−
だけがいて、経営の要求を情報システムに的確に反映する人が育たなくなり、
5年、10年経つうちに、ビジネスモデルが空洞化してしまう心配があります。
わたしはビジネスモデルを外注するのは人事管理を外注するのと同じくらい危険
なことのように思うのですが、皆さんどう思われますでしょうか。
                                椿正明
追伸
先回、「平松さんのご意見」を紹介しましたが、私の大変な勘違いで、東レの平
松さんではなく川鉄情報システムの平松さんでした。彼は1980年台初めに川
鉄のDOAを推進し富士通のYPSにも貢献した大変な論客ですが、最近は東レ
の平松さんとばかりやり取りしていたもので失敗しました。失礼しました。