椿正明のdoa人生40年 - airnet.ne.jp · copyrightdri, 2008 all rights reserved. 1...

Copyright DRI, 2008 All rights reserved. 1

椿正明のＤＯＡ人生４０年

ＳＣＭとＩＴ経営－実践研究会

２００８．９．２７

データ総研椿正明

１．ビジネスデータ構造

２．椿正明ＪＯＢ年表

３．ＤＲＩのＤＯＡの６つの特徴

４．２１世紀の情報戦略


１．ビジネスデータ構造－６業種分類

Ａ．建設：見積－受注－建設計画－建設－検収

建設、造船、印刷、エンジニアリング、

ＳＩ、ＥＲＰ、コンサルティング

Ｂ．生産財製造業：受注－生産計画－生産－出荷

鉄、窯業、紙、繊維、半導体、石油化学、重機、機械部品

Ｃ．消費財製造業：販売計画－生産計画－生産－受注－引当ー出荷

燃料、酒類、食品、薬、雑貨、車、家電、ﾊﾟｿｺﾝ、ｿﾌﾄﾊﾟｯｹｰｼﾞ

Ｄ．小売業：販売計画－手配－販売

デパート、コンビニ、アパレル、鉄道、航空、宅配、映画、

野球、代理店、広告、リクルート、放送

Ｅ．卸業：販売計画－仕入－受注－出荷

商社、販社、特約店、卸、証券

Ｆ．サービス：契約－設定（工事／担保）－サービス－検収

電力、ガス、通信、不動産、学校、銀行、信託

ＡＳＰ（ Application Service Provider ）、

物流系

工事系

契約系

ＥＤＣ

ＦＡＢ


ビジネスの一般構造（消費財製造業の場合、他の場合は若干異な

る）

調達・買掛生産・原価物流・原価販売・売掛回収・原価保守・原価

人・組織設備取引先品勘定科目その他

人材調達・育成・原価

市場開発・保守・原価

情シ開発・保守・原価

資金調達・投資・原価

設備建設・保守・原価

商品開発・改良・原価

メタデータ

利益

：ＥＤＨ：リソースデータ

バリューチェーン系／基幹系／オペレーショナル系／ＳＣＭ軸：イベントデータ

共用メッセージ抽出・加工

在庫・要約共用ＭＳＧ

計画・原価

リソース整備系（ＨＦＭＰＣＩ）：イベントデータＤＷＨ系

Human Facility Market Product Capital Information


調達（預金）

販売（貸付）

回収（金利）

保守

人・組織店・ＡＴＭ顧客契約勘定科目その他

人材調達・育成

市場開発・保守

情シ開発・保守

短期資金調達・投資

設備建設・保守

商品開発・改良

オンライン

利益

イベント・要約リソースデータ

バリューチェーンイベントデータ

基幹系（オペレーショナル・ＳＣＭ軸）

貸付コントロール（客、金利、額、期間）

共用メッセージ抽出要約

共用ＭＳＧ要約データ

計画

リソース整備系ＤＷＨ系

Ｆ．銀行業

ＡＤＷ

ＥＤＨ

ＥＤＨ：［勘定．金利．通貨．支店．ＹＭＤ］－（末残）


産業の生態系

個人コンシューマ

建築・プラント

卸・運送

電力・通信

コンシューマ一般

小売業

製品業

部品業

素材業

情報

銀行・保険

車・家電

レストランスーパー

米・豆腐・野菜アパレル

モーター・電池肥料

鉄板・半導体

布・チャック

石油・ガス繊維・パルプ

ディーラー

Ｌ１

Ｌ２

Ｌ３

Ｌ４

Ｌ５

発注／支払のレベル

産業サンプル

Ａ

Ｂ

Ｃ

Ｄ

Ｅ

Ｆ

狩猟民族的

農耕民族的


動植物の生態系

人間

マグロ

植物プランクトン

小魚

草・果物・実

松・ぶな

牛・馬象・熊・猿

動物プランクトン

鶏

鷲

バッタ

蛙

蛇

太陽と水

ライオン

鯨

Ｌ１

Ｌ２

Ｌ３

Ｌ４

Ｌ５


椿正明ＪＯＢ年表

＠千代田化工建設

１９６２ Natural Gas工業化研究報告書サウジ政府に提出

１９６５プロセスシミュレーターＣＨＥＬＭ開発

ＣＨＥＩＳ（Chiyoda Engineering Information System）企画

１９７０ Information Algebraを参考にＴＨデータモデルおよび

ＤＰＬＳ（Database Programbsase Languagebase Support）開発開始

１９７５ＤＰＬＳ第１回ＶＬＤＢ国際学会に発表

１９７９ＩＰＦチャート開発

＠日本システミックス

１９８０ＤＢＣＭＳ（Database Complex Management System）設計書ＩＰＡに納入

１９８３ＳＰＦチャート考案

＠データ総研

１９８６第１回データベース特別研究会開催

ＰＬＡＮ－シリーズ開発

１９９４「データ中心システム入門」出版

１９９５「データ中心システム設計の実際」監修

２０００「データ中心アプローチによる情報システムの構築」出版

２０００ THeRepository開発

２０００ＢＡＳ（Business Application School）開発

２００４ THeEDWアーキテクチャ発表

２００５「名人椿正明が教えるデータモデリングの技」出版

２００６「名人椿正明が教えるシステム分析モデリング１００の処方箋」出版

２００６「名人椿正明が教える帳票分析５０のケーススタディ」出版

２００８ THeSOAアーキテクチャ、ＰＬＡＮーＩＯ研究

ＤＯＡ研究開始

フェデレーションアーキテクチャ

２．

Ｖ＝Ａ（Ｅ）

東京首都（日本）北京首都（中国）


千代田化工建設ーマルチプロジェクトが独立に走る

ＥｎｇＰｒｏｃＣｎｓｔ





標準ＤＢ

全社ＤＢ

ＰＪＴ１

ＰＪＴ２

ＰＪＴ３

ＰＪＴ４

ＰＪＴ５

化工計装機器配管土建電気

ポイント

・ラフ設計に基づく早期手配

・設計分野間の整合性管理

・ＪＩＴのリソース調達・投入

・常時発生する変更の管理ー先読み能力

・世界各国から集まるｎ千人の現場要員の管理

要員、顧客、協力会社、資材など

人事、売上、経費など


プロジェクトトータルシステムのニーズを分析

・上流工程の変更は下流工程の変更を発生させる。

・プログラムの問題ではなく、データの関連・構造の問題。

・各種Ｅｎｇ－Ｐｒｏｃ－Ｃｎｓｔのデータはどう関連しているか。

・Ｖ＝Ａ（Ｅ）で帳票を分析。

・実装独立、サイエンス志向、ＫＪ法的抽象化→ＴＨモデル。

・プロジェクトファイル－当時ＤＢという言葉がなかった－が必要。

・ＯＳとアプリケーションをつなぐミドルウエア（ＤＢＭＳ＋）が必要

→ＣＨＥＩＳ（Chiyoda Engineering Information System）企画。

ＣＨＥＩＳ００：ＤＢＭＳ＋ →ＤＰＬＳ

ＣＨＥＩＳＥ１０ＣＨＥＩＳＥ２０ＣＨＥＩＳＥ３０・・

化工設計配管設計調達


ＤＰＬＳ－Database Programbase Langagebase Support

・物性定数、資材単価表は共通→リソースＤＢはインフラ（35年前にＭＤＭ実現）。

・内蔵リポジトリによって、アプリＰＧは概念モデルでアクセスする。

・Dynamic Link機能－CALL L(X)としてXにプログラム名を定義－を用意。

・ユーザはアプリにUnified Interface（ＸＭＬ的コマンド言語、サービス相当）

でアクセスする。

・開発言語は移行性を配慮して９９％ＦＯＲＴＲＡＮ。

・第1回ＶＬＤＢ国際会議で発表（ＥＲモデルと同時）。

・Du Pont やBoeing Computerが関心を示し、情報交換。

・社内でデモアプリ開発。


ＲＥＪＥＣＴ

・情シトップはシステム関係者の声を聞いて、「ＤＰＬＳを使わない」と意思決定。

・技術的評価はなし。

・ＩＢＭのＩＭＳを使いたい。社内開発のミドルウエアは不可。

・本音は多分

－いままでどうりに仕事をしたい

－椿の路線に乗りたくない

－椿の構想についていけない

・「データモデリングしなければ使えないＤＢＭＳはおかしい。ＩＭＳはデータモデリングしなくても使える」

純技術的にあるべき

アーキテクチャを考えた失敗


ＰＲＩＤＥの日本システミックスに入社

・米ＭＢＡ社のＩＲＭ指向のシステム開発方法論を販売。

・ＴＨデータモデルで方法論を補強。ＴＨ／ＳＰＦ法。

・日揮、協和発酵、横河電機等で成功事例。

・学んだこと

－情報要求はＩＯにあり、ＩＯで情報誘導設計を進める

－情報要求にはタイミングが重要

－ノウハウは売れる


１９８５年データ総研創立

・ＰＬＡＮ－ＤＢライセンス、教育、コンサルテーション。

・開発方法論カスタマイズ・コンサル。

・実装独立のビジネスモデル構築－ユーザニーズ反映、整合性保証。

・ＴＨモデラー、ＩＰＦモデラー、THeRepository販売。

・ＥＡ構築コンサル。

・ＭＤＭ構築コンサル。

・ＥＤＨによるＳＯＡ実現（後述）。


ＤＲＩのＤＯＡの６つの特徴

ボトムアップ実証主義

・ＤＢ＝Ｆ（ＩＯｓ）

＝Ｆ（Ｓｅｒｖｉｃｅｓ）

フェデレーションアーキテクチャ

・リソース独立による一元化

・ＳＩＬＯ化しない・ＥＤＨ通信場による全社連携

ＥＡパターン

・処理系５階層

・ＩＰＦ＆ＩＯで処理とデータを連携

ビジネス構造パターン

・バリューチェーンと

リソース整備系・６業種分類

実装独立での整合性

・加工データのＳＰＦ表現

・基本４ドキュメント・リポジトリとの整合性

意味論データモデル・レイアウトルール

・ファイル類型・データ機能コード・サブタイプ／サブストラクチャ

概念ＤＢはユーザニーズから決まる

記法習得と現状・問題点共有達成トップダウンはＫＫＤ方法論放棄の危険あり

ＲＤＢ設計ではない

概念ＤＢ構造図

データ定義書ＩＰＦチャートＩＯ定義書

業務ドメイン

システム／サブシステム業務プロセス業務／ＩＯ業務データ

建設業生産財製造業消費財製造業小売業卸業サービス業

ビジネスを図と表で可視化

同じＬＯＯＫ＆ＦＥＥＬ

３．


販売・物流システム概念ＤＢ構造図上（リソース系）

部署(1,4,5,6,7,8,9,10)□

［部署Ｃ］

－（部署名、＜人数＞）

社員 (1,5,6)□

［社員＃］

－（社員名、所属部署Ｃ）

社員・所属異動 (1)■

［社員＃．異動＃］

－（配属年月日、配属部署Ｃ）

業種 (2)□［業種Ｃ］

－（業種名）

１：卸業(商社）

２：運輸業３：製造業

売上ランク (11)□［売上ランクＣ］

－（年間上限売上金額）

Ａ：－Ｂ：１０００万Ｃ：５００万

取引先 (2,3,5,6,11)□［取引先＃］

－（取引先名、住所、電話＃

業種Ｃ、顧客Ｆ、社内外区分Ｃ）

顧客 □

［取引先Ｃ］－（担当営業所Ｃ

売上ランクＣ）

商品分類 (8)□

［商品分類Ｃ］－（商品分類名）

１：一般食品２：ソフト・ドリンク３：業務用食品

商品ロット (4,6)□

［商品Ｃ．ロット＃］

－（製造年月日）

商品 (4,5,6,7,9,10,11)□

［商品Ｃ］

－（商品名、商品分類Ｃ、標準単価、単位Ｃ）

勘定科目 (6)□

［勘定科目Ｃ］

－（勘定科目名）

勘定科目明細 (6)□

［勘定科目Ｃ、明細Ｃ］

－（明細名）

単位 (4,5,6)□［単位Ｃ］

－（単位名）

１：ケース２：ツツミ３：ケ

処理区分 (5)□

［処理区分Ｃ］－（処理区分名）

１：売り２：テスト

概念ファイル名

帳票＃

リソースファイル

ＫＥＹ（識別コード）

従属データ

ＲＫＥＹ(参照コード）マーク

イベント・ファイル

顧客Ｆ

＝Ｙ

抽象的なリソース

Ａ人事 2Ｂ経理 1Ｃ営業 1

1 田中Ａ人事2 佐藤Ｂ経理3 鈴木Ａ人事4 山本Ｃ営業

［部署Ｃ］－（部署名人数）

［社員＃］－（社員名所属部署Ｃ（所属部署名））

Ｓ←

凡例：

具体的なリソース（レコード数が多い）

社内組織

だれが

社外組織

だれに

その他製商品、原材料

なにを

管理対象の役割管理対象の抽象度／粒度

矢線（分類階層）は上から下へ

３．１


販売・物流システム概念ＤＢ構造図下（イベント／要約系）

商品在庫 (9)

［営業所Ｃ．商品Ｃ］

－（＜実在庫数量＞＜引当済在庫数量＞、＜引当可能在庫数量＞）

×

営業所入庫 (4)■

［入庫＃］

－（入庫営業所Ｃ、入庫年月日）

営業所入庫明細 (4)■

［入庫＃．入庫行＃］

－（入庫商品Ｃ、ロット＃

数量、（入庫営業所Ｃ））

受注明細 (5)■

［受注＃．受注行＃］

－（受注商品Ｃ、処理区分Ｃ、受注数量、受注単価、＜受注明細金額＞、摘要、（担当営業所Ｃ））

受注 (5)■

［受注＃］

－（顧客Ｃ、届先ｃ、（社内外区分ｃ）受注担当者＃、受注年月日、納期、＜受注金額＞、（担当営業所Ｃ））

ﾛｯﾄ別商品在庫 (9)

［営業所Ｃ．商品Ｃ．ロット＃］

－（＜実在庫数量＞）

×

月末商品在庫 (10)

［営業所Ｃ．商品Ｃ．年月］

－（＜実在庫数量＞）

出荷 (6)■

［出荷＃］

－（受注＃、配送業者Ｃ

出荷年月日）

出荷明細 (6)■

［出荷＃．出荷行＃］

－（（受注＃、受注行＃

（出荷商品Ｃ）、ロット＃、出荷数量、＜出荷金額＞、（担当営業所Ｃ））

顧客別商品分類別売上計画・実績 (7,8)

［顧客Ｃ．商品分類Ｃ．年月］

－（計画金額、＜実績金額＞）

／

顧客別商品別売上計画・実績 (7)

［顧客Ｃ．商品Ｃ．年月］

－（計画金額、＜実績金額＞、（商品分類Ｃ））

／

社外出荷明細 (6)■

［出荷＃．出荷行＃］

－（（顧客Ｃ、商品Ｃ

出荷年月日）、＜出荷金額＞）

在庫型ファイル

断面ファイル

商品ｆ

要約ファイル

＝社内

子イベント

社内外区分Ｃ

＝社外

処理区分ｆ

親イベント

先行イベント後続イベント

取引先ｆ

リソースとの矢線は省略

１／１０に減る

＋－Ｓ

ＪＳ

Ｅ

世代交代

再出発

２

４

３

７

６

５１

８

９


３．２ＴＨ図の特徴

・レイアウトに個人差が出ないため

・概念ファイルやデータ項目がさがしやすい

・概念ファイルの抜けが分かる

・イベントとリソースの矢線は例外を除き省略可（参照ＫＥＹ値が関係を表現）

・重要な矢線（約１／１０）だけ書けばよく見やすい

・ボトムアップに統合、再統合をくり返すとき、これがやさしくできる。

・葉（データ項目）→木（概念ファイル）→森（概念ＤＢ）が自然に見えてくる

・結合、要約などの処理がトレースできるため、

加工データのトレースからサブタイプが見え

・自然に高品質が得られる

・処理設計の先取りができる

通常ＥＲモデルとの違い

・レイアウト規則

・リソース分離表現（孤島回避）・処理をトレース（品質アップ）・概念にこだわる（ユーザ参画）・ＩＲＭ（情報資源管理）指向・ＩＯや物理ＤＢとひもづける

ＥＰ（Entity Processing）モデル！


操作タイトル操作基本法例

（１）

射影（Ｐｒｏｊｅｃｔｉｏｎ）

［Ａ］－（ｘ，ｙ）

Ｐ

［Ａ］－（ｘ）

［社員＃］－（氏名、生年月日）

Ｐ

［社員＃］－（氏名）

（２）

結合（Ｊｏｉｎ）

［Ａ］－（ｂ，ｘ）［Ｂ］－（ｙ）

Ｊ

［Ａ］－（ｂ、ｘ、ｙ）

［発注＃］－（品番、数量）［品番］－（単価）

Ｊ

［発注＃］－（品番、数量（単価））

（３）

加工（Ｇｅｎｅｒａｔｉｏｎ）

［Ａ］－（ｘ，ｙ）

Ｇ被加工属性（加工元データ）

［Ａ］－（ｘ，ｙ，ｚ）

［発注＃］－（品番、数量、単価）

Ｇ金額

［発注＃］－（品番、数量、単価、＜金額＞）

（４）

要約（Ｓｕｍｍａｒｉｚａｔｉｏｎ）

［Ａ］－（ｂ，ｘ）

Ｓ操作種別

［Ｂ］－（ｎ(A)，Ｓ(X)）

［社員＃］－（氏名、所属部署Ｃ、年齢）

Ｓカウント、平均年齢

［部署Ｃ］－(<人数>、<平均年齢>)（５）

抽出（Ｅｘｔｒａｃｔｉｏｎ）

［Ａ］－（ｘ，ｙ）

Ｅ

［Ａ‘］－（ｘ，ｙ）

［社員＃］－（氏名、職種Ｃ）

Ｅ職種Ｃ＝営業

［社員＃］－（氏名、職種Ｃ＝営業）

ＳＰＦチャート記法（操作子は11種）

記法の法則・レコード・タイプは［ＫＥＹ］－（Ａ１、Ａ２・・・・・）のように書く。ＫＥＹ：識別子（キー）Ａ１、Ａ２：データ項目（アトリビュート）

・ＫＥＹはレコード・タイプ（あるいは概念ファイル）を代表するものとして大文字で書く（例：Ａ，Ｂ）。・ＫＥＹ以外の属性は小文字で書く（例：ｘ，ｙ，ｂ）。・ダッシュは部分集合を表す（例：Ａ‘⊂Ａ）。・ｎは個数、Ｓは要約オペレータ（カウント、平均、合計、大、近、ＫＥＹ変換等）を表す。

抽出条件


ＳＰＦチャートによる処理（概念プログラム）記述Ｂｏｄｙ

ｆ４［発注＃］－（品番、発注先＃、メーカ＃、数量、発注日、納入予定日

ｆ２［取引先＃］－（取引先名）

正規化Ｊ

［発注＃］－（品番、発注先＃、（発注先名、）メーカ＃、数量、発注日、納入予定日）

ｆ２［取引先＃］－（取引先名）

正規化Ｊ

［発注＃］－（品番、発注先＃、（発注先名）、メーカ＃、（メーカ名、）数量、発注日、納入予定日）

ｆ１［品番］－（品名、単価）

正規化Ｊ

［発注＃］－（品番、（品名、単価、）発注先＃、（発注先名、）メーカ＃、（メーカ名、）数量、発注日、納入予定日）

Ｇ金額＝ｆ（数量、単価）

［発注＃］－（品番、（品名、単価）、発注先＃、（発注先名）、メーカ＃、（メーカ名、）数量、＜金額＞、発注日、納入予定日）

ＤＢ設計Ｅ品番＝Ｐ３

の方向［発注＃］－（品番＝Ｐ３、（品名、単価）、発注先＃、（発注先名）、メーカ＃、（メーカ名）、数量、＜金額＞、発注日、納入予定日）

製品

・生産ラインに似ている！・処理についてユーザとシステム・アナリストがコミュニケーションする言語！・処理についての要求仕様≠製造仕様（モジュール分割までは踏み込まない）

注Ｊ：統合（Ｊｏｉｎ）Ｅ：抽出（Ｅｘｔｒａｃｔｉｏｎ）Ｇ：加工（Ｇｅｎｅｒａｔｉｏｎ）

加工データのマーク

冗長データのマーク（カッコ内カッコ）


受注生産のイベントモデル

受注 ■

［受注#］－（顧客C、納入日、商品C、①受注数）

生産指図 ■

［生産指図#］－（商品C、指示日、

（累計所要数）、④生産指図数!）

生産検収 ■

［生産指図#］－

（検収日、⑤実生産数）

出荷 ■

［出荷#］－（受注#、(顧客C)、(商品C)、出荷日、

（受注数、生産実績数）、

⑦出荷数!）

実績集計／

［商品C ．生産日］－（<⑥生産実績数>）

受注生産出荷

所要集計＼

［商品C ．所要日］－（<②所要数>、<③累計所要数>）

Ｓ

ＳＪ

Ｊ

意思決定データ

意思決定元データがあるので加工データの１種とする

ＥＰモデルｎｏｔＥＲモデル


• 計画ファイル「期別製造計画」とマスタファイル「原料展開」を元に、期別原料別の所要量「期別原料購入」を求めます。

事例2：スケルトンファイルを用いて加工デ－タを読む（ＭＲＰ展開）

［原料期］＜使用量計＞

ミルク 20期

20期

20期

20期

カカオ

砂糖

卵

［製品期］生産量

チョコレ－ト２０期

２０期ビスケット

２００,０００

２５０,０００

［製品原料］原単位

チョコレ－トミルク

カカオ

砂糖

ミルク

ビスケット砂糖 30

ビスケット卵 5

50

チョコレ－ト 20

チョコレ－ト 40

ビスケット 60

［製品原料期］（生産量）（原単位）＜使用量＞

期別原料購入原料展開期別製造計画

？？

25,000,000

4,000,000

15,500,000

1,250,000

10,000,000

4,000,000

8,000,000

15,000,000

7,500,000

1,250,000

50

20

40

60

30

5

２００,０００

２００,０００

２００,０００

２５０,０００

２５０,０００

２５０,０００

①：まず、「期別製造計画」と「原料展開」を関連付けるために、両ファイルの全てのレコードを組み合わせることによって、スケルトンファイルを作成します。

期別製品別原料購入

チョコレ－トミルク 20期

チョコレ－トカカオ 20期

チョコレ－ト砂糖 20期

ビスケットミルク 20期

ビスケット砂糖 20期

ビスケット卵 20期

②：「期別製造計画」から生産量をスケルトンファイルに結合します。

③：「原料展開」から原単位をスケルトンファイルに結合します。

④：使用量を計算します（使用量＝生産量×原単位）。

⑤：使用量計を計算します。

OK


概念≠概要

概要詳細

概念（実装独立） ① ②

物理（実装従属） ③

ＤＯＡデータ項目識別標準化

ＰＯＡ

機能分割・ＰＧ仕様書

ＤＢ構造図

データ定義業務フロー図ＩＯイメージ（整合性解決）

物理レコードアクセスパス業務マニュアル物理ＩＯ仕様画面遷移バッチジョブリカバリ方式移行方式

ＳＩ業

ユーザ企業

要件定義基本４

ドキュメント

Conceptual About


３．３データモデルとは－実証主義

・データを整理する－形にはめる、分析する－ための標準的枠組／表現形式・いわゆる、３層スキーマのＣｏｎｃｅｐｔｕａｌＳｃｈｅｍａ作成機能（ＤＭＦ＝ＤａｔａＭｏｄｅｌｉｎｇＦａｃｉｌｉｔｙ）

ＵｓｅｒＳｃｈｅｍａ

ＣｏｎｃｅｐｔｕａｌＳｃｈｅｍａ

ＩｎｔｅｒｎａｌＳｃｈｅｍａ

ＤａｔａＭｏｄｅｌｉｎｇ

ＯｂｊｅｃｔｓｏｆＩｎｔｅｒｅｓｔｔｏＴｈｅＥｎｔｅｒｐｒｉｓｅ

ＳｔｏｒａｇｅＤｅｖｉｃｅｓ

ＬｏｇｉｃａｌＰｈｙｓｉｃａｌ

ＬｏｃａｌＧｌｏｂａｌ

Ｕｓｅｒ

ＲｅａｌＷｏｒｌｄ

（実務の世界のデータ）（ＴＨ，ＥＲ，ＳＩＭｅｔｃ）ＤａｔａＭｏｄｅｌｉｎｇＦａｃｉｌｉｔｙ

ＡＮＳＩ／Ｘ３／ＳＰＡＲＣＡｒｃｈｉｔｅｃｔｉｒｅ（１９７５）

ビュー

Create文

ＤＲＩの攻め方証拠物件と凡人合議

欧米流の攻め方スーパーマン主導


試行錯誤小・ユーザ参画の方法論

現行ＩＰＦ＆ＩＯＩＯデータ概念ＤB（Entity&Attribute)

問題・課題

解決策暫定概念ＤＢ（仮置き不変標準データ）

新規ＩＰＦ＆ＩＯＩＯデータ概念ＤB（Entity&Attribute)

① ② ③

④

⑤ ⑥

⑦ ⑧ ⑨

現状と問題点の共有はペイする！

現状の共有を重視してＩＯＤＢのすくみを解消

主要ＩＯに絞る

主要データに絞る

テンプレートで代替する

トップダウン

トップダウン

ボトムアップ

ボトムアップ

トップダウン

ボトムアップ

トップダウン

ボトムアップ

ボトムアップ：決まる

トップダウン：決める

高品質・低コストの鍵

ソフトウエア

自動化ツール

変化予測


企業内ＤＢ（概念）の一般的構造

受注出荷

■ 営業

受払

■ 物流

生産検収

■ 生産

会計資金

■ 経理

異動給与

■ 人事

管理系□ 計画・実績

支店工場顧客商品

部署設備勘定科目

社員機器

□ リソース：システム広辞苑

共用インフラＤＢ

－共用インフラＤＢが核－

ＲＡ+ＲＢ+‥=Ｒ(Ａ+Ｂ+‥)

用語ＴＥＲＭ（全社問題）

と記録ＦＡＣＴ（部門問題）

３．４


完全なアプリケーションにはＲ＆Ｒが不可欠

業務アプリＤＢ（イベント系）

リソースＤＢ

業務モデルリポジトリ

営業・生産・経理・・

Ｒｅｐｏｓｉｔｏｒｙ

＆

Ｒｅｓｏｕｒｃｅ

参照

統制

≒ファイルフォーマット（形式と意味）［受注＃］-（顧客＃、品＃、数量、・・）受注＃：ＫＥＹ、５桁顧客＃：ＲＫＥＹ、８桁

≒コード説明（値と意味）１２３４：東京支店１２３５：大阪支店２３４５：上海支店

データ流通を保証するもの：標準

ＦＡＣＴ(記録）

ＴＥＲＭ（用語）

システム広辞苑

（形式の標準）

（値の標準）

有限の文化圏を作る


データインフラによる全社統合の環境

リソースデータ

ＤＡ（データ管理者）

ＢＥ（ビジネスエンジニア）

Ｒ／３レガシーＤＷＨ

ＥＵ

データインフラ

ＥＵＥＵ

アウトソーサの

守備範囲


メタデータ／リポジトリ

リソースデータリソースデータ

Ｒ＆Ｒｅｓｏｕｒｃｅ

ｅｐｏｓｉｔｏｒｙ

ＣＲＭ、ＳＣＭへ

ＥＲＰにはリソースはついてこない


ＤＯＡの本質

システム ①サブシステム

②インターフェース

Peer to Peern(n-1)/2個

③実行順序

通信場通信

Hub & Spoken個

n個

ＤＯＡリソースＤＢ、ＥＤＨ、リポジトリのための標準化

分解


健保有効チェックのためのＳＯＡ

バンドエイドＳＯＡ正解のＳＯＡ

健保Ａ健保Ｂ健保Ｂ健保Ａ

病院１病院１病院１病院１病院１病院１

健保センター

・・

・・・・

・・

パス：ｎ＊ｍパス：ｎ＋ｍ

：健保データのあるべき場所

ストレージなくても標準化必須

データアーキテクチャが重要・Ｎ＊Ｍ→Ｎ＋Ｍ・データ標準化が不可欠

Two-sided Network の場合

（参照系）


アーキテクチャの進化（ｌＰＯＡ→ｈＤＯＡ）

f１ f2

１．lＰＯＡ（バケツリレー）

Ｐ１Ｐ２Ｐ３

４．hＤＯＡ＝リアルタイムＤＷＨ

Ｒ＆Ｒ

ＥＡＩＥＳＢＢＰＭ

ＥＡＩＥＳＢＢＰＭ

２．lＤＯＡ

３．hＰＯＡ（孤島を連携）

Ｐ１Ｐ２Ｐ３

ＤＢ

Ｒ＆Ｒ

Ｐ１Ｐ２Ｐ３

ＤＢ

Ｒ＆Ｒ

Ｐ１Ｐ２Ｐ３

ＤＢ

Ｒ＆Ｒ

Ｐ１Ｐ２Ｐ３

ＤＢ

Ｒ＆Ｒ

Ｐ１Ｐ２Ｐ３

ＤＢ

Ｒ＆Ｒ

Ｐ１Ｐ２Ｐ３

ＤＢ

Ｒ＆Ｒ

Ｐ１Ｐ２Ｐ３

ＤＢ

Ｒ＆Ｒ

標準データを共有する文化圏

Repository & Resource

low level high levelＳＯＡは３ねらい？４ねらい？

Ｐ２Ｐの通信場

Ａ２Ａの通信場

lＤＨ

アプリに先行して決める

ＤＢ

ＤＢＤＢＤＢ

ＤＢＤＢＤＢ

ＥＤＨ


企業内分野統合のとき

ＰＰＰＰ

ＤＢ

Ｒ＆Ｒ

ＰＰＰＰ

ＤＢ

Ｒ＆Ｒ

ＤＢ

Ｒ＆Ｒ

ＣＣ

１

１

２

２

０

０

生産営業

生産完成などハイレベルメッセージ

疎結合by ＥＤＨ

高速道路網／新幹線相当必要な変換インターチェンジ相当

Ｒ＆Ｒは全社統合を実現：全社標準これがないと通信場にならない

密結合by OLTP-DBMS一般道路網／在来線相当

エンティティ、データ項目、概念ＩＯ、ＩＯデータ、物理データ形式のみ


リポジトリ

ロウレベルメッセージ

それぞれ文化圏

ハード・ソフトも違うことが多い


Ｒｅｓｏｕｒｃｅ

ＥＤＨ

ＤＢ１

ＤＢ２

ＭＳＧハンドラー

ＡＰ１

ＡＰ２

ＡＰ３

ＡＰ４

Ｕ１

Ｕ２

Ｕ３

Ｕ４

ハイレベル・メッセージ

もうひとつのインフラ

ハイレベル（Ａ２Ａ）通信場

計画・在庫・要約・

イベントコピー

参照のみ

［ＤＢ＃．Ｅｎｔｉｔｙ種別ｃ．Ｅｎｔｉｔｙ＃］

‐（・・）

Ｒｅｐｏｓｉｔｏｒｙ

ロウレベル（Ｐ２Ｐ）通信場

ＥＤＨによるシステム疎結合

アーキテクチャはＤＢ／標準化の範囲

によって決まる。→ＤＯＡによって決まる。

ハイレベル

ロウレベル


ＥＤＨ

バーチャル明示

バーチャル

暗示

ＷｅｂサービスｉｎＳＯＡ

ＳＱＬ

オブジェクト

パッケージやレガシー

ＥＤＨ

アクセス

Ｄｙｎａｔｒｅｃｋ方式

ＥＤＨのストレージ構造（一部仮想化）

ＥＳＢは完全仮想化前提の実装手段


ビジネスの一般構造（消費財製造業の場合、他の場合は若干異な

る）

調達・買掛生産・原価物流・原価販売・売掛回収・原価保守・原価

人・組織設備取引先品勘定科目その他

人材調達・育成・原価

市場開発・保守・原価

情シ開発・保守・原価

資金調達・投資・原価

設備建設・保守・原価

商品開発・改良・原価

メタデータ

利益

：ＥＤＨ：リソースデータ

バリューチェーン系／基幹系／オペレーショナル系／ＳＣＭ軸：イベントデータ

共用メッセージ抽出・加工

在庫・要約共用ＭＳＧ

計画・原価

リソース整備系（ＨＦＭＰＣＩ）：イベントデータＤＷＨ系

Human Facility Market Product Capital Information


4種のＤＢから成るアーキテクチャモデル（実装独立）

プラットフォーム物理メタ概念メタ

リソース

ＥＤＨ

データマート

ＡＤＷ

データマート

データマート

人事管理

設備管理＊ｋ

商品・部品開発＊ｍ

購買

販売・生産計画＊ｎ

ＣＲＭ

資金管理経理

販売＊ｎ

生産＊ｎ

バリューチェーン

リソース整備

＊ｑ＊ｐ

事業部の数

工場の数

商品の数


３．５ＥＡのニーズと解決の方向

孤島（ＳＩＬＯ）・暗黙システム

・ＴＯＰとして会社のステイタスが見えない

・ミドルとして関連業務が見えない

・ＳＣＭやＣＲＭに迅速に対応できない

・保守するとトラブルが発生する。対応が遅い。

大陸・可視化システム

・データ標準化によるデータインフラ構築

・ＩＴ独立によるＩＴ横断の接続

・図面言語によるコミュニケーション


業務モデルが情報システムの核

経営ニーズ

業務モデル（ＢＡ・ＤＡ）

（プロセスモデル+データモデル）

業務モデル業務モデル

アプリケーションソフト（ＡＡ）（ＤＢ＆プログラム）

プラットフォーム（ＴＡ）（ハード・ＮＷ・ＯＳ・ミドルソフト）

ＥＤＨＥＡ

楽々・ＧｅｎｅＸｕｓ・ＷｅｂＰｅｒｆｏｒｍｅｒなど暗黙知？冗長・不整合？

冗長や死骸！

１／３－１／１０に？

ＩＴＢＡ

ＤＡ

ＡＡ

ＴＡ

ＥＡ

垂直統合

水平統合


業務モデルコンポーネント

論理組織製品／処理系コンポー

ネント業務ドメイン

システム／サブシステム

業務プロセス

業務／画面・帳票

画面・帳票データ

原料／データ系コンポー

ネント概念データ

ベース・タイプ

エンティティタイプ

データ項目

データモデル図

ＩＰＦチャート

ＢＡ（Business Architecture）ＤＡ（Data Architecture）

処理レベル１

２

３

業務モデル・コンポーネントと図表現

４

５

ＢＡ

ＤＡ

ＡＡ

ＴＡ

ＥＡ

ＷＢＳ


製品群

化成品、建材、繊維、

医薬、食品重電、家電、半導体

市場

日本、欧米、中国；

法人、個人；量販店、通販；子供、中高年

事業

基本機能計画、生産、購買、営業、物流、会計、人事、設備、

マーケ、Ｒ＆Ｄ、情報

業務ドメイン（ＢＤ）

業務ドメイン（ＢＤ）を決める３要素

業務ＤＢ


ＩＰＦ（Information Process Flow）チャート例

購入予定

発注

発注伝票

発注買掛

支払リスト

買掛出金ＤＢ

本社

1/M 起動支払い支払入力

発注担当

1/D 発注条件

入庫入力

購入先

R/D 納品書

IO-H2040

IO-H2051

IO-H2050

IO-H2052 IO-H2053

IO-H2039IO-H2042

IO-H2041

ＴＰ７支払いＴＰ６検収ＴＰ５発注

人とＩＯの世界

ＴＰ：Task Process／業務プロセス

（ＩＯトリガ）

製品物流相当（Ｌ３）

ＴＰトリガ（カレンダートリガ）

情報、大きさ一定

処理線プログラム

通信線

ＴＫトリガ


ＩＰＦチャートの特徴

• 全ＩＯ（製品）を明示－抜けなし・順序正しく

• ＰＬＡＮ（朝方）－ＤＯ（日中）－ＳＥＥ（夕方）の順に

• いつ誰が作り、誰に（目的）渡すか

• トリガは適切か（不適切だと使われない）

• タイミングはＯＫか（１／Ｍでなく１／Ｗ？）

• データベースアプローチ（ＤＢに反映が原則、共有・処理に便）

• 個人差の出ない文法（４コンポーネント（トリガ、処理、情報、通信線）順次）

• 開発ボリュームが見える

• 業務プロセス（ＴＰ）を客観的処理部品として識別


処理系コンポーネント業務ドメインシステム／サブシステム業務プロセス

処理レベル 5 4 3

資材購買購買計画購買計画

購買依頼購買依頼

見積発注発注先決定

発注

入庫予定確認入庫予定確認

入庫検収入庫

検収

業務機能ＷＢＳ（資材購買の場合）


４．２１世紀の情報戦略

・ＩＴは多様化、データインフラを標準化

・企業情報モデルの骨格はユーザ企業情企が握れ

・発注者と受注者は業務モデルを共有

・ＰＭＯ＋ＤＭＯの体制確立・維持

情報システムは有機体ビジネス環境に対応して随時変化する

取替部品で迅速対応


システムスコープの拡大

１：アプリプログラム

ＰＧＭ

２：アプリシステム

ＳＹＳＴＥＭ

ＥＮＴＥＲＰＲＩＳＥＳＹＳＴＥＭ

天動説的世界観地動説的世界観

アプリＤＢ←同じ文化

フェデレーション的世界観

統合リソース

ＥＤＨ←異なる文化

３：企業システム

多くの人の意識がまだ２のレベルに留まっている


■ＩＴの進化

・オープン系

・ネットワーク技術・ＲＦＩＤ・Ｗｅｂ２．０

要件の難度上昇

■ビジネスニーズの進化

・全体適化、大規模化、標準化

脱孤島、Ｐ２Ｐ→Ａ２Ａ、Ｂ２Ｂ・スピード対応・規制緩和、Ｍ＆Ａ・Ｊ－ＳＯＸ、トレーサビリティ

■ＩＴとビジネスの接近

・ＥＲＰ、ＳＣＭ、ＣＲＭ、ＢＩ、ＢＰＭ、ＣＰＭ、ＫＰＩ、ＳＯＡ

・ＰＤＭ、ＰＬＭ・ガバナンス要求、可視化、ＥＡ・コストダウン、人員削減、丸投げアウトソース・暗黙知、レガシーシステムの負債→システム開発プロジェクトの成功率２６％

Pgm to PgmAppl to ApplBiz to Biz


システム化の歴史認識

１９８５バブル、Main Frame、ＲＤＢでシステム化（lＤＯＡ、第１次ＤＯＡ）

１９９０Ｃ／Ｓ、ＥＵＣ、分散化、孤島システム化、ガバナンスダウン、

物理テンプレート修正開発（ＤＯＡ氷河期）

１９９５ＥＲＰ、Ｙ２Ｋ、要件定義技術ダウン

２０００不況、システムコストダウン、情報システム部門スリム化、

アウトソーシング

２００５全体適、ＭＤＭ、孤島システム連携、可視化、ＥＡ、ＢＰＭ、ＳＯＡ、Realtime DWH（EDW)、

ＲＦＰ、要求開発、セキュリティ、Ｊ－ＳＯＸ（hＤＯＡ、第２次ＤＯＡ）２０１０進行基準、ＳａａＳ、ＰａａＳ、ＢＰＰ、仮想化、

クラウドコンピューティグ、？？

５年ごとの激変！Platform as a Ｓervice Business Process Platform


第２次ＤＯＡスタート（仮説）ＤＯＡ１．０ＤＯＡ２．０＝ＳＯＡ

１９８５－２００５－

個別業務（Ｐ２Ｐ）業務横断（Ａ２Ａ）

観測・発生データ意思決定データ

オペレーショナルユーザＬＯＢ（Line of Business）One Fact in One Place One Fact to All MembersＯＬＴＰ型ＤＢＭＳＢＰＭ、ＥＳＢ、ＳＯＡ、ＥＤＨ

省力化、守り事業パーフォーマンス、攻め

ＳＱＬ、ＲＰＣＷｅｂサービス

モノリシックアーキテクチャフェデレーションアーキテクチャ

（一般道／在来線）（＋高速道路／新幹線）

開発までが勝負寿命２０年、開発・運用・保守が問題

スクラップ＆ビルト不断の部分再構築、計画的に少しずつ

部品の再利用不変部品と取替部品の管理

アプリＰＧデータインフラ（メタ、リソース／ＭＤＭ、ＥＤＨ）

ＳＥ、ＤＢＡＢＵ、ＤＭ

Ｐ２Ｐ：Program to ProgramＡ２Ａ：Application to ApplicationＢＰＭ：Business Process ManagementＥＳＢ：Enterprise Service BusＳＯＡ：Service Oriented ArchitectureＥＤＨ：Enterprise Data ＨｕｂＲＰＣ：Remote Procedure CallＭＤＭ：Master Data ManagementＢＵ：Business UserＤＭ：Data Manager


ＤＯＡ２．０のインパクト

・企業とは部品組み立て型の情報生産工場

データ部品→画面・帳票（製品）

・変化対応

不変部品と取替部品の分別対応

個別アプリ、処理指向のＯＯには要注意

・人材開発

システム開発は人材開発の貴重なチャンス

ＳＩ丸投げはもったいない

椿正明のdoa人生40年 - airnet.ne.jp · copyrightdri, 2008 all rights reserved. 1...

Documents