情報処理学会連続セミナー第3回情報システム構築アプローチ ジネス.ppt

?ＮＰＯ法人技術データ管理支援協会＆手島 歩三2006 情報処理学会連続セミナー第３回　情報システム構築アプローチ情報システム統合の目標－ビジネス?アーキテクチャ－ ２００６年９月５日 NPO法人技術データ管理支援協会 手島 歩三 ビジネス?アーキテクチャ １．情報システムのビジネス整合 情報システム構造改革アプローチＥＡの困難 ２．事例：ビジネスを混乱させる機能指向アプリケーション構築 ３．ビジネス?アーキテクチャを捉える ４．製造業のビジネス?アーキテクチャ 製造業の異質なビジネス?アーキテクチャ 製番管理、ＥＲＰ／ＭＲＰ、ＴＰＳ、ＴＯＣ／ＤＢＲ、気配り生産 事例研究から得たこと ５．ビジネス?アーキテクチャ把握の意義と改革の限界 ビジネス?アーキテクチャの意義 ビジネス?アーキテクチャ改革の限界 １．情報システムのビジネス整合 BPR（情報技術によるビジネスプロセス改革）の壁 難航する情報システム構造改革への取り組み サプライチェーンのメンバー企業は一様でない サプライヤーへのパッケージ導入では解決できない プロセス改革案そのものの問題 ほかに考慮すべき要素がある ビジネス?アーキテクチャ 「モジュール」と「摺り合わせ」 製品構造 製造プロセス 公開されていないトヨタ生産情報システムの内部 どうすればビジネス?アーキテクチャを捉えることができるのか？ システム統合とソフトウェア開発の異質性 システム?インテグレータが中心となって取り組んだシステム統合の失敗例続出 少数であるがユーザ企業の情報システム部門が主体性を持ったシステム統合／構造改革の成功 システム?インテグレータの経営不振 ソフトウェア技術者に欠如する「情報システム技術」 失敗を招く安易なシステム統合アプローチ 片寄せ Ｍ銀行の事例 顧客データ仕様の相違 取り込み失敗 顧客に入力データ作成を依頼 データの重複 混乱 良いとこ取り 個別ＡＰにとっては「片寄せの組合せにすぎない」 できるところだけ再構築 Ｎ航空の事例 データ移植が必要なアプリケーションは後回し マスターデータ移植が不要なミッションクリティカル?アプリケーションを優先して再構築 「ＣＥＯのリーダーシップによるシステム統合で成功」と報道 統合しなかったアプリケーション分野でトラブル続発 ＣＥＯの辞任 システム統合失敗の原因 失敗の原因追求方針 「プロジェクト?マネジメントの失敗」は結果にすぎない。 技術的原因を見極め、「失敗の危険性（リスクと不確実性）」をできるだけ少なくする。 原因１．目標像の欠如 「システム統合の成功」とはどのようなことか、明確な目標像を持たない。政治的駆け引きの中で目標像が失われる。 原因２．システムの構造化不足 良い情報システム?アーキテクチャを持たない。 原因３．業務改革との連動不足 情報システム再構築を目的とするプロジェクト活動 業務改革計画への無関心 原因４．移行計画の不備 データ移植の軽視 ビッグバン?アプローチ 本稼働体制でのテスト計画を立てない 原因５．ユーザ不在のプロジェクト 専門家集団のブラックボックス 利用者教育計画不足 情報技術技術者のためのソフトウェア開発方法論にこだわる システム統合の目標と必要性 目標 ビジネス?アーキテクチャと情報システム?アーキテクチャの整合 必要性 ソフトウェア品質低下と保守の遅れに伴う構造悪化　→　継続的システム統合 組織改革に伴う情報システム構造改革 システム統合の要件 情報基盤整備 アプリケーション?システム統合を可能にする情報基盤の整合 情報整合 アウトプットデータの無矛盾 ビジネスの事実を捉えるトランザクション?データとデータベース 情報システム費用の削減 情報基盤 情報システム運用?保守 業務改革支援 情報供給と情報処理 ビジネス改革に即応する情報システム変更?拡張 問題解決アプローチ ソフトウェア工学から情報システム工学へ 情報システムを理解し活用できるだけでなく、タイムリーかつ的確に変更要求を出せる利用部門組織の形成 分かり易く、変更?拡張が容易な構造を持つ情報システム 新しい役割を持つ情報システム部門 問題解決の範を示そうとする政府 電子政府?電子自治体の情報システム構造改革 ＥＡ（Enterprise Architecture） ビジネスの仕組と情報システムの整合 要求分析?要求定義からの脱却 ２．事例：ビジネスを混乱させる機能指向アプリケーション構築 ビジネス上の必要性に応じて個別にアプリケーションを構築してきた アプリケーション間のデータ仕様は特に意識しなくても、食い違いはなかった 運用過程でデータ仕様に関する利用者側の解釈が入り込みデータの食い違い生じた このことに気付かなかったた