今回の島根富士通プロジェクトのテーマは統合です。
その前に、前回の三つのシステム化方針に沿った開発導入作業の結果をお伝えします。
1, EDIの浸透について
電子機械工業会でのEIAJ標準の策定は終了し、ヒュジュンフォーマットがリリースされ
ました。
これは、それ以前は発注元により電子取引データを受信する端末が別で、帳票も別と言う
状況から、富士通もNECも日立も同じ端末で受信し、注文票や納入書・受領書が同一に
なると言う画期的な結果を生みました。
ただ副作用として、EIAJ標準フォーマット上の品目コードが国際標準の18桁になったた
め、各メーカーのローカルシステムの桁数を減らすと言う大仕事も生みました。
標準化を進めるための課題です。
2, 川崎工場の購買システムの最適化
ここでは長くなるので結果のみをご紹介します。
・必要最低限のアウトプットを得るための処理に絞ると、22Mが900Kに
・処理速度（スループット）は約10時間から15分に
要求される機能を維持して既に稼働実績があるプログラムを使用したためテストも照合のみで終了しました。
3, リードタイムの見直し
これは取引先により条件が違いましたので、一概には言えませんでした。
前回に触れた購買情報システムを使用して、調査課が追跡調査したところ、かなり短くな ったとの事でしたが、数値は社外秘でした。
はっきりしたことは、システム導入後も取引先と定期的な見直しを継続的に進めていくこ とが必須であるという事でした。
今日の本題の社内し合うテム統合です。
富士通には以下の社内システムがありました。
・販売管理システム
・生産管理システム
・購買システム
・物流システム
今回、島根富士通ように大幅に見直したのは購買システムです。
島根に持って行って分かったことですが、生産管理用のコンピューターと購買用のコンッピューターは別に考えていました。それまでがそうだったからです。
良く考えてみると、購買発注データは生産管理の所要量計算の結果ですから、コンピューターを分けて、一日以上時間を空ける理由はなく、生産管理に組み込むことにしました。
処理時間は一日短縮され、コンピューターが一台リストラ出来ました。
その結果、生産管理の処理終了後、発注データを送信すると、取引先では30分後に注文書の印刷が完了しました。
取引先からの電話を受けてプロジェクトは終了しました。
購買発注リードタイムだけに注目すると、郵送期間を含め2週間が30分になった訳です。
ただ、課題もありました。
販売管理と物流管理との統合は現在も続いており、聞いたところでは富士通はSAP/ERPを導入して、この課題を一気に解決しようとしています。
強力なリーダーシップが期待されます。
最後に、文中でご紹介したAA/BRMODELLERとDOAの解説をします。
1, AA/BRMODELLER
(1)「データ中心」思想に基づく開発方式
データに対する徹底的な標準化と冗長性のない最適なデータベースの実現を優先する「データ中心」開発を強力に支援します。これによって、データ整合性の高い、保守が容易なシステム開発が可能になります。
(2)プログラムの自動生成
業務の要件から決まる仕様を表形式のわかり易いドキュメントで表現し、一方ターゲットによって変わる技術的な仕様は別に与えることによって、プログラムを自動的に生成できます。これにより、業務要件の変更が仕様書上で簡単に行え、技術的な仕様を書きかえるだけで、様々なターゲットシステムに適用できるようになります。
(3)一貫した開発手順とドキュメント体系をサポート
上流の業務分析からテスト・保守まで、手順とドキュメント体系が用意されています。 これにより、属人性のない整然とした開発が可能になります。
設計ドキュメント作成支援機能
ニーズ分析・システム分析から業務仕様設計フェーズまでの各種ドキュメントを、表形式で簡単に作成することができます。
ディクショナリによるデータ資源管理機能
エンティティ、データ項目、ドメイン、レコードなどのメタデータを関連づけて、整合性を取りながら管理することができます。このディクショナリから、COBOL COPY句を生成することができます。
プログラム生成機能
業務の要件から決まる仕様を、BRSPECという表形式のわかり易いドキュメントで表現できます。このドキュメントから、構築ツールと連携して、様々なプラットフォーム用のプログラムを自動生成できます。
その他の機能
ドキュメントを作成していくに従い、自動的にドキュメントの関連づけが行われ、編集中に関連するドキュメントを呼び出すことができます。
工程の既存ドキュメントから次工程のドキュメントを自動生成することができます。
ドキュメント間の整合性を確保するために、内容変更時の他のドキュメントへの影響を検索することができます。
ドキュメントの記述内容についてチェックを行うことができます。
2, データ中心アプローチ
DOA」の視点が必要な理由
ビジネスのスピードは年々加速度を増しています。より迅速な経営判断を下せることが、ライバルの一歩先を行く原動力になります。当然、意思決定のための情報単位の価値も高まっています。この情報＝データは、これまで以上に重要な経営資源として認識されるようになっています。
この迅速な意思決定を実現するための手法の1つが、DOAとなります。DOAのアプローチを示す概念図は以下の通りです。
「業務処理の流れ」を中心にした視点でシステムを構築する、「POA（ Process Oriented Approach：処理中心アプローチ）」という考え方があります。ある要求に対して、技術的にどう解決していくかとする、これまで多くの開発者やIT部門単体で実践していた手法と思います。
POAは、求められたシステムを正確に構築するために必要なアプローチですが、その一方で、変化への対応がしにくい課題も生じます。例えば、処理プログラムを新たに構築すると、そのたびにデータを用意する必要が出てきます。そうなると、データが冗長となり、データの整合性を維持するのが困難になるといった課題に発展します。つまり、システム開発当初は順調に稼働していても、時間の経過とともに複雑なシステムになっていく可能性が高く、変化への対応が難しいとなり得ます。
これに対して、DOAは「データ」を中心に考えます。データは不変的なので、ビジネスの変化に対する影響が少ないと言えます。DOAは、変化に影響されにくいデータに視点を置き、システム基盤が全体的に最適な状態になるよう構築する考え方です。
DOAを実現するために、何を実践すればいいのか
では、DOAには何が必要なのでしょうか。まず必要不可欠な手法が「データモデリング」です。
データモデリングとは、企業や組織が管理すべきデータの収集や分析を行い、整理統合して、管理しやすい構造にモデル化することです。
Comments