scm改革とerp導入統合への方法論 - airnet.ne.jp ·...

1Aｌｌ Rights Reserved,Copyright© M&ＥＲＰｉ，Ｉｎｃ 2005

ＳＣＭ改革とＥＲＰ導入統合への方法論

２００５年５月２８日㈱マネジメント＆ＥＲＰインテグレーション

渡辺和宣


経営とＥＲＰを統合するマネジメント・アンド・イーアールピー・インテグレーション

我々の企業ビジョン1.我が国企業の国際競争力の回復にＩＴ面（ERP導入）から貢献2.構成メンバの学習と自己実現3.次世代やＮＰＯに対する社会貢献

我々が提供できるサービス□経営戦略を踏まえたＥＲＰ導入企画の立案支援□ＥＲＰベンダーおよびパートナー選定のためのＲＦＰ作成支援□ＥＲＰ導入のためのフィット・ギャップ分析＆導入計画の作成支援□ＥＲＰへの教育計画の作成、および操作マニュアル作成などの教育支援□ＥＲＰ導入プロジェクトマネジメント、多くのタスクの統合マネジメント支援□プロセス設計と業務運用設計支援、マスタ移行支援、教育計画の作成と教育支援

代表取締役渡邉和宣 [email protected]［略歴］中小企業診断士、公認システム監査人、ＩＴコーディネータ、プロジェクトマネジメントスペシャリスト（PMS)。大阪大学理学部卒業。大興電子通信（株）でシステムエンジニアとして情報システムの企画・開発業務に20数年従事した後、ＥＲＰパッケージの導入コンサルティング部門を立ち上げ、経営企画部門にて中期経営計画を策定、かつプロジェクトマネジャーとして自社へのERP導入の完了後、2001年４月独立。2001年７月Ｍ＆ＥＲＰ社設立、同社代表取締役。

産業車両メーカへのERP導入構想立案、製薬メーカのＰＭＯ支援、楽器メーカのERP導入統合マネジメント支援、産業機器メーカのＥＲＰ導入企画・選定支援、メーカＳＣＭ改革ガイド作成と適用支援など。

［所属団体］中小企業診断協会、日本システム監査人協会、経営情報学会、ＰＭＩ、サプライチェーンカウシル（ＳＣＣ）など。［主な著書］『SAP革命』『SAP R/3 ハンドブック』『システムコンサルタントになる本』『情報システム部』

『失敗しないＥＲＰ導入ハンドブック』（以上、共著、日本能率協会マネジメントセンター）『ビジュアル解説ＩＴコーディネータテキスト』(監修、日本経済新聞社)『プロジェクトマネジメント大全』『 SAPソリューション完全解説2003』（共著、日経ＢＰ社）など。

マネジメント＆ＥＲＰ社 http://www.merpi.com


ＥＲＰ導入プロジェクトの目標達成度

ＥＲＰ導入結果への満足度と当初の期待度とのギャップの大きな項目（目標設定企業は満足度が高いが）原因の考察

ビジネス面 ①先進ユーザのノウハウ吸収（-2.00）②経営情報のリアルタイム把握（-1.78）③受注以降のリードタイム短縮（-1.62）④在庫の削減（-1.50）⑤業務効率化コスト削減（-1.40）⑥決算日程の短縮（-1.27）⑦情報共有と活用（-1.17）⑧特定業務分野の改革（-1.05）

ＩＴ面 ①IT開発期間の短縮（-1.77）②IT開発コストの削減（-1.67）③IT総コストを削減（-1.64）④データの一元化（-0.90）⑤ITインフラ整備や保守性向上（-0.56）⑥ITのアウトソーシング実現（-0.02）

業務プロセス改革が不十分・部門間の課題が解決しない・個別最適プロセスの踏襲・ＥＲＰ本稼動で終わり

プロジェクトマネジメントの誤り・重要な要求への重点投資でない・多すぎるアドオン開発・ＥＲＰ適用範囲、導入時期が不適切

新しい価値実現の失敗

コスト(資源)投入の失敗

2004年ＥＲＰ研究推進フォーラム調査

かなり期待したのに、期待外れ

そこそこ期待したのに、期待外れ

M&ERP


ＩＴプロジェクトとしてのトラブル原因

５億円以上のITプロジェクト納期遵守率は 51.0%コスト遵守率は 55.0%品質遵守率は 38.0%

全部の遵守率は 10.7%コスト超過額加重平均 22.9%

プロジェクトマネジメントリスクマネジメント

要求定義（要件定義）

原因

M&ERP


従来の情報システムＥＲＰ導入

ギャップ解消方法

成果物個別開発による情報システム

パッケージによる業務プロセス

プロセス、ＥＲＰ、マスタ、利用者を成果物として定義

情報システム部の役割

情報システム部は「作る」（＋下請）

情報システム部の役割は利用部門に「使わせる」

外部パートナーがＥＲＰ開発を担当

利用部門の役割

役割少ない要求を出すだけ

役割多いプロセス設計、業務変更、マスタ移行、教育、各種テスト

経営トップのコミットによる利用部門の主体的参画

システムライフサイクル

開発工程が主運用・保守は従

ＥＲＰ導入計画書と同時に運用・活用計画書を作成

本稼動で50%運用工程が重要

大きなギャップの存在

目的部門効率化部分最適

全体効率化全体最適

プロセス改革の設計を先行ＥＲＰ導入はその次に

プロセス中心の方法論

体制とプロジェクトマネジメント

ＢＳＣの観点からの成果物定義

教育・ヘルプデスク（サービス）

プロジェクトモデル（スキーム）

プロセスとデータを管理

クロスファンクショナル・チーム

ＰＭ

要求明示的要求を実現主に省力化、自動化

暗黙的、潜在的要求も実現

要求定義の方法論要求分析コンサルタント

失敗の原因:ＥＲＰ導入と従来の情報システム開発におけるギャップを認識・対応しないままＥＲＰ導入に走ったこと


コスト削減加重平均で30%の開発関係のコスト超過の防止優先順位に応じたアドオン開発（金メッキの排除）品質目標遵守やユーザ教育による保守工数の削減

導入方法論による十分な成果物の作成周到なプロジェクトマネジメント・リスクマネジメント

業務課題解決とプロセス改革、要求分析に十分な時間業務運用設計やユーザ教育に配分プロジェクトマネジメントに投資額の10%までかける

－15%－10%－10%

コスト削減－20%

＋ 5%＋ 5%＋ 5%

導入方法論とプロジェクトマネジメントによる効果

ソフト超過15%即ち、アドオン増加

本稼動延期

ＰＭ

平均的現状

ビジネス効果の実現

経営情報のリアルタイム把握、情報共有と活用受注以降のリードタイム短縮、在庫の削減業務効率化コスト削減、決算日程の短縮経営的効果ＸＸＸ

対策

ＥＲＰ研究推進フォーラム調査


ＥＲＰ導入の全体＜プロジェクトモデル＞

新業務プロセス機能要求の設計（上位レベル）

ＲＦＰ作成ＩＴ選定

基準

FIT/GAP分析ERPｿﾘｭｰｼｮﾝ選択

導入予算確定

新業務プロセス機能要求の設計（中位レベル）

新業務プロセス機能要求の設計（下位レベル）

業務運用フローの作成（ＥＲＰと非ＥＲＰ）

ＥＲＰ導入パラメータ設定アドオン開発１次

業務運用フローの改善①ＥＲＰ関連の改善②非ＥＲＰ部分の改革

ＥＲＰ運用テスト

アドオン開発２次

概要要求

概要要件

詳細要求

詳細要件

経営･事業課題業務課題

ＥＲＰによる経営的成果

スポンサー要求

１次で解決

ユーザ要求ユーザ要求

要求定義要求詳細定義


提案書によるITｿﾘｭｰｼｮﾝ

ﾊﾟｰﾄﾅｰ選定

整合性

ＥＲＰ導入実行計画書ＥＲＰ導入実行計画の実行・統制

カスタマイズ確定

要求管理

要求の追加・変更

要求

業務プロセス

ＥＲＰによる情報システム

２次で解決

情報化企画書

経営的成果

ＥＲＰ運用活用計画書

ＥＲＰ運用活用の実行・統制

ユーザ要求

マスタ移行マスタ整備統合マスタ運用

導入前教育ＥＲＰ活用教育

マスタ・データ

利用者スキル

・要求分析(スコープ）・プロセスフロー(中位）・プロジェクト計画書

情報化企画ＩＴ選定ＥＲＰ運用活用フェーズ

スキームモデルシステムモデルサービスモデル

ＥＲＰ導入計画プロセス概要設計

ＥＲＰ導入プロセス詳細設計ＥＲＰ構築･テスト

・スポンサー要求・導入ロードマップ・導入期待効果

・要求分析（主要）・ＲＦＰ作成・提案書評価

・要求分析(詳細）・プロセスフロー(下位）・業務運用設計

・ＥＲＰ構築・各種テスト・移行

情報化企画・ＩＴ選定・計画プロセスＥＲＰ導入プロセスＥＲＰ運用･活用

プロセス

ＥＲＰと要求定義

方法論

プロジェクトマネジメント

ＥＲＰ導入プロジェクトマネジメント／リスクマネジメント

マネジメント＆ＥＲＰ社

共通


下位に深入りすると要求詳細分析と同じ

Ｌ２

Ｌ１

Ｌ３

Ｌ４

Ｌ５

プロセスタイプ例）調達

プロセスカテゴリー例）見込生産品調達

プロセスエレメント例）資材受入

プロセス機能例）入庫入力

トランザクション例）発注入庫入力

Ｌ６トランザクション機能

例）入庫数量変更

SCOR例

ＥＲＰ

経営・業務課題

ミドル要求

業務課題

ユーザ要求

業務機能要求

ユーザ要求

プロセス要求概要分析

下位に深入りするとＲＦＰが詳細になり過ぎ

具体化のために必要な場合も

具体化のために必要な場合も

ＥＲＰソリュ｜ション選択

新ビジネスプロセス上位

ＥＲＰによる新ビジネスプロセス中位

プロセス要求詳細分析

ＥＲＰソリュ｜ション設計

ＥＲＰによる新ビジネスプロセス下位

機能設計

ユーザ要求

プロセスを段階的に詳細化

ＥＲＰによる新ビジネスプロセス下位

機能詳細設計

ベ｜スライン開発

サイクル別開発

スコ｜プ

ＥＲＰ導入プロジェクト

優先順位

優先順位

ＥＲＰ導入ＥＲＰ導入計画

要求概要、ERPｿﾘｭｰｼｮﾝ選択

プロセス詳細設計プロセス概要設計

ＥＲＰ導入

ベースライン各サイクル

実現化（実装）

プロセス改革企画

要求詳細、ERPｿﾘｭｰｼｮﾝ設計

プロセス分析ＢＰＲ/ＳＣＭ

プロジェクト計画

ＢＰＲ/ＳＣＭ

プロジェクト実行

プロセス改革とＥＲＰ導入の統合

ＳＣＭ

ＥＲＰ

（効果）プロセス改革から要求の優先順位を決定スコープを絶対に拡大させない、コスト・期限厳守

（効果）ＥＲＰで実現する機能を前提にＢＰＲ/ＳＣＭを計画・実現できる

（経営環境）市場からの厳しい要求

ＰＭ

ＩＴ選定情報化企画

共通


プロセス改革プロジェクト


ＥＲＰ導入のスコープ・コスト決定の流れ

要求詳細分析

選定ＥＲＰとFitGap分析

実現化(実装)

フェーズ３－５

ＥＲＰｿﾘｭｰｼｮﾝ設計

プロセス詳細設計

フェーズ２

ＥＲＰ導入実行計画書

スコ｜プ

承認後ベースラインスコープ

コスト

ベースライン

承認

承認後ベースラインコスト(概算）

本稼動ｻﾎﾟｰﾄ

移行・本稼動

情報化企画ＩＴ選定ＥＲＰ導入計画ＥＲＰ導入ＥＲＰ構築・テスト

フェーズ

求める価値の定義成果物の開発・構築

調整

プロセス､マスタ整備､教育等非ＥＲＰ開発

ＥＲＰシステム

スコープ・コストユーザ企業側ベンダー側

承認

調整

確定後ベースラインスコープ

変更後ベースラインスコープ

確定後ベースラインコスト(詳細）

変更後ベースラインコスト

ベースライン変更

変更管理ﾌﾟﾛｾｽ

ベースライン変更

経営･事業課題業務課題


ユーザ要求

ＩＴの目標定義

成果物目標（Ｓ､Ｑ）

業務プロセス情報システムマスタ・データ利用者スキル

コスト目標（Ｃ､Ｔ）

超概算見積り

ＥＲＰ導入実行計画書（更新版）

ＥＲＰ導入実行計画書（更新版）

ＲＦＰ作成

ＩＴ選定

提案書コスト(超概算）

提案書スコープ

他社事例など


承認

「要求の優先順位付けルール」により一致させる

ベンダー担当分だけ

プロセス概要設計プロセス詳細設計

ＰＭ


ビジネスプロセスとビジネスプロセスモデル

階層化された

ビジネスプロセス

ビジネス情報

リソースデータイベントデータ

企業情報システム

ビジネスモデル

カスタマイズシステム構築

業務プロセス構築

マスタ･データ

情報システム機能

マスタデータ

アプリケーション

①機能②アウトプット③コントロール

④インプット⑤組織⑥データ

ＳＣＯＲ例機能アウトプットメトリクスインプット

①プロセス機能②組織③コントロール④インプット⑤アウトプット

業務プロセス業務機能権限規程運用ルールインプット情報アウトプット情報

情報システム論理データベース

物理データベース

情報システム機能

ＥＲＰ例データ構造

基本機能アウトプット

物理モデル論理モデル（リファレンス）

事業戦略モデル

どこで競争するかいかに競争するか（Ｍポーター：業務プロセスの４形態）

集中、相互調整、分散、分権

事業戦略

ＳＣＭ改革

ＥＲＰ導入

（注意）ビジネスプロセスの物理モデルには、６つのプロセス要素が必要①機能、②アウトプット、③コントロール、④インプット、⑤組織、⑥データ

（注意）ビジネスプロセスの論理モデルには、６つのプロセス要素全ては必要ない最低限は①機能、②アウトプット、④インプット

階層化された


プロセスモデルの階層構造ＳＣＯＲ例

SCC資料より作成

４タスクプロセスエレメントを分解する

ＳＣＯＲとＥＲＰとの架け橋

５アクティビティＥＲＰプロセス

６トランザクションＥＲＰトランザクション

７トランザクション各機能

ＥＲＰトランザクション機能

ＥＲＰの範囲

３プロセスエレメント

各プロセスカテゴリーを構成する下位のプロセス

D1.1：引合と見積

D1.2：オーダ受領と入力

D1.3：在庫引当と納入日設定

２プロセスカテゴリー

見込生産品、受注生産品、受注設計生産品に関するプロセス

Plan1-4、Source1-3、Make1-3、Deliver1-4、Return1-4

P1,P2,P3,P4

S1

S2

S3

M1

M2

M3

D1

D2

D3

1プロセスタイプ

プロセスのタイプを指定する。Plan

Source Make Deliver

Return

ＳＣＯＲの範囲

プロセスの階層プロセス構成要素内容

2005.5.2修正

手作業アクティビティ１

手作業アクティビティ２

手作業アクティビティ３

論理モデル

物理モデル

業務運用フローでは両方を記述する必要あり例．ARIS

・・・


プロセス改革とＥＲＰ導入の統合の流れ

プロセス改革企画

プロセス分析ＢＰＲ/ＳＣＭ


ＢＰＲ/ＳＣＭプロジェクト実行・組織、ビジネスルールの改定・プロセス機能の向上・外部との情報共有、パートナーシップスポンサー要求

の明確化

改革ＣＳＦ

現状システム分析レベル３･４まで含むＩ／Ｆ

ＥＲＰ導入計画

ユーザ要求概要分析ＥＲＰソリューション選択

プロセス概要設計

組織･ルール業務プロセス情報システム

ロードマップ作成

全体計画作成

レベル２･３･４プロセス

レベル５プロセス

分散システム変更計画

分散システム開発

全てのユーザ要求の引き出しと優先順位付けベースライン設定スコープ、スケジュール、コスト、品質

ＥＲＰ導入プロセス詳細設計

ＥＲＰ導入実現化（実装）移行、教育ユーザ要求詳細分析

ＥＲＰソリューション設計

レベル６-７プロセス（含むアドオン）

ＥＲＰ運用

プロセス改革プロジェクト評価･見直し

ＳＣＭメトリクス(在庫・リードタイム）

変更管理で対応大きな変更は再承認の上ベースライン変更

ロードマップの作成（ＳＣＭ改革＋ＥＲＰ導入）期待効果の算出

2005.5.23修正ＰＭ


スポンサー要求の明確化

経営目標の確認ＳＷＯＴ分析事業環境の分析

経営･業務課題のヒアリング

ＣＳＦ分析ＣＳＦの構造化

経営・業務課題プロセスへマッピング

ストラテジーマップ抽出されたＣＳＦ検証

ＫＧＩＣＳＦＣＳＦ→ＫＰＩ

コンテキスト分析課題の具体化

ショートカット

課題解決のための

改革テーマ抽出

構造化された課題･CSF

経営目標との整合性の確認

ＳＣＯＲによるAs-Is分析、To-Be設計の手法

サプライチェーンに関する課題

As-Is レベル２分析

As-Is レベル３分析

As-Is レベル４分析

To-Be設計

レベル３・４

製品グループ

スポンサー要求の確認・構造化

スポンサー要求の検証

サプライチェーン改革の反映

課題の優先順位の決定

ミドルマネジメントのコンセンサス

スポンサー要求とプロセス改革要求は構造化することで、課題として具体化できる。課題を解決するための改革テーマは、５つにカテゴライズできる（情報システムはその一つ）。

サプライチェーンパフォーマンスに関する目標

組織・ルールに関する課題

業務プロセスに関する課題

人の能力・意識に関する課題

情報システムに関する課題

改革テーマ

設備投資にに関する課題

As-Is レベル２分析

As-Is レベル３分析

As-Is レベル４分析

To-Be設計

レベル３・４

製品グループ

課題の完全性課題間の整合性

ミドルマネジメントからの課題ヒアリング


スポンサーからの経営･業務課題の検証


コンテキスト分析

見込み生産計画策定の週次化

生産能力を考慮した生産計画

新規受注時の受注可否判断と回答納期遵守

同一品目の社内外生産複数業者への並行発注

ＣＳＦ分析

Ｍ1.1

Ｄ1.3

生産工程別の部品納入指示棚番指定の保管場所管理

Ｓ1.4ES.９

Ｍ1.2EＭ.4EＤ.4

Ｐ2.4

経営課題事業課題

見込生産品納期確認製品

在庫管理

見込生産日程計画仕掛品

管理

見込生産資材払出

調達計画調達契約

管理

資材移送

業務課題および優先順位

課題検証のポイント□課題が何もマッピングされていないプロセスはないか□プロセスにマッピングされた課題間に矛盾はないか□経営目標とプロセスのパフォーマンス属性が合致しているか□出されたシステム課題より有効なベストプラクティスはないか

トップダウン

ミドルアップ

ＳＣＯＲ

汎用品について、顧客からの短納期化ニーズおよび需要変動にタイムリーに対応する

フレキシブルな生産

スポンサー要求の明確化ー２

プロセスにマッピングされた課題

Ｌ３への課題を明確にするためのヒアリング

Ｌ１

Ｌ２

Ｌ３

Ｌ４

Ｓ1.1


サプライチェーン改革の反映

ＳＣＯＲ

ＡｓＩｓレベル２計画系分析

ＡｓＩｓレベル２実行系管理系

ＧＡＰ分析課題仮説／検証

ＳＣＯＲとの

ＡｓＩｓレベル３ＧＡＰ分析プロセス機能分析INPUTデータ要件分析

ＡｓＩｓレベル４分析プロセス機能分析INPUTデータ要件分析

ToBeレベル４設計

プロセス機能設計INPUTデータ要件設計

ＳＣＯＲとのToBeレベル３設計

プロセス機能設計INPUTデータ要件設計

ＳＣ改革要件

スポンサー要求の明確化ー３

プロセス上の課題・問題

ビジネスルール・守られていない・ルール変更が必要（部門内、部門間、業績評価）・新たなルールが必要（サプライヤ、顧客）

業務プロセス機能・機能遂行が不十分・モレ・パフォーマンスが悪い・判断データの抜け・悪精度・遂行者のスキルが不十分・機能定義自体が不十分

人に関して・個人スキルに依存・スキルが要求に対応できない

情報システムに関して・ルｰル・プロセス機能を自動化・データが欠落・低精度・情報の一元管理、共有化

（社内、社外プレーヤ間）・人の意思決定を支援するツール

2005.5.23修正スキーム

ベストプラクティスの選定ソリューション

Ａｓ-ＩｓＳＷＩＭチャート作成改革スコープ

To-Be ＳＷＩＭチャート作成





改革テーマ

設備、部品にに関する課題

Ｌ１

Ｌ２

Ｌ３

Ｌ４


ロードマップの作成

2005.4.2追加スキーム

前提条件：解決すべき課題の優先順位制約条件：解決すべき課題の難しさ・必要資源・所要期間、および課題間の順序制約代替案：目的（解決できる課題）、スコープ（解決策）、所要リソース、期待効果、影響・リスク





改革テーマ

設備投資にに関する課題

To-Be SWIMﾁｬｰﾄ

ロードマップ案作成

設備投資の金額・時期

組織・ﾙｰﾙ変更の難易度・期間

教育・意識改革の難易度・期間

情報システムのロードマップ案作成

ＳＣ改革の観点

情報システムの観点

制約条件の検討

前提条件の検討

順序制約

優先順位

代替案の設計複数の代替案の設計・立案整合性

代替案の評価スコープ、リソース期待効果、リスク

第１次プロジェクト

複数のプロジェクトから構成されるプログラム計画=多段階投資案

期待効果の算出多段階投資として

改革プログラム

インタフェース開発コード統一マスタ移行

第２次プロジェクト

・・・

第n次

プロジェクト


プロセス改革面からのロードマップ案の作成

スキーム 2005.4.19追加

ローカルに分散

ローカルに分権化

グローバルに集中

グローバルに相互調整

オペレーションのモデル

１

２

グローバル統合ＥＲＰはそのツール

オペレーション（プロセス）を距離・空間・時間を超えて集中化させることで、地球規模のスケールメリットを享受できる。

①製造設備の操業度の向上製造コストの低下②グローバル調達共通部品の集中購買③物流の効率向上輸送コストの低下④研究開発投資の効率新製品開発コストの低下⑤グローバル・ブランド化新市場へのマーケティングコストの低下⑥重複オペレーションの効率化会計、人事、情報システムなど

シェアドサービスやＢＰＯも可能

１．オペレーションのグローバル集中化

スケールメリットを追求することで、経営資源効率を高める

２．ローカルに分散したオペレーションの相互調整

プロセスを相互調整（統合）することで､経営資源効率を高め、かつ顧客満足を得る

世界各国のプロセスを相互調整（統合）することで、グローバル企業として経営効率を高めることで、グローバル・サービスの提供ができる。

①経営資源の調整サプライチェーン全体計画の作成（需要とリソースとの調整）販売・調達・生産・物流プロセスのリードタイム短縮

②サービス提供顧客へのグローバルサービス（在庫、修理、遠隔保守）③知識･技術の共有設計ノウハウ・ナレッジ、市場変化や顧客動向の情報

④プロジェクト分散した要員によるバーチャルなプロジェクト運営

『競争戦略論Ⅱ』（マイケル･Ｅ･ポーター）より作成


情報システム面からのロードマップ例-１

ＩＳＯＣＩＭの階層モデル

階層ＩＳＯＣＩＭモデル機能

企業全体経営管理、財務管理販売計画、生産計画原価計画

工場管理

生産計画、購買計画生産指示･実績管理、品質管理、販売･物流

セクション、エリア(工程管理）

セル(製造ラインの管理）

生産実施の準備生産詳細指示生産進捗と検査実績の収集

ステーション（装置の制御）

装置（製造の実施）

６

５

４

３

２

１

機器群管理

設備自動化機器制御機器

エリア

メジャ｜工程

マイナー工程

作業（作業実施）

帳票、画面指示設備指示

工程の作業定義工程実績収集工程進捗設備監視

ERP

分散システム

FA

制御システム

NC、MCロボット

製品別

計画系

工場別製品別

計画系

工場別製品別工程別

製造実行系

工場別製品別工程別

製造制御系

相互調整プロセス

グローバルに集中プロセス

分散プロセス

分権化プロセス

M.ポーターの分類を適用すると

ＳＣＰ機能

計画・実績機能

製造実行機能

ＭＥＳＣ／Ｓシステム

ＡＴＰ機能

生産情報システムの階層化の考え方

アドオン

または

2005.4.2追加スキーム

相互調整プロセス

分散プロセス

分権化プロセス

Ａ工場Ｂ工場

全社共通

工場・工程ごとに異なる


財務の視点（経営目標）

業務ﾌﾟﾛｾｽの視点（パフォーマンス指標）

学習と成長の視点

顧客の視点（顧客指標）戦

略

顧客リードタイムの短縮

顧客満足の獲得

モノの流れのプロセスを改革

情報の流れのプロセスを改革

ＩＴを導入する

情報を整備する

ビジネスプロセスを支援・自動化：ビジネスルール組込み・情報化：人間の判断を支援

ＩＴ投資の最終的期待効果例

オーダ充足リードタイム

顧客要求納期遵守率

改善値目標値現状値メトリクス

製造計画サイクルタイム

需要予測精度

計画見直しサイクルタイム

改善値目標値自社メトリクス

サプライチェーンプロセスのパフォーマンス目標

顧客満足目標

在庫日数

オーダ充足ＬＴ

ＳＣＭ総コスト

効果金額目標値現状値メトリクス

売上／コスト目標

ＢＳＣ（バランススコアカード）KGI：業績評価指標

KPI：業績向上要因KPI：業績向上要因

2005.4.17修正ＰＭ


ＳＣＯＲモデルの場合

個別プロセスにおける課題解決による効果

2005.5.21修正

プロセス改革へのテーマ

リソース管理

ビジネスルール管理

プロセス遂行者の教育

プロセス機能向上

情報システム整備へのテーマ

ＩＮＰＵＴ情報共有･整備

プロセス自動化

意思決定支援

ＯＵＴＰＵＴ情報伝達･共有

解決すべき課題と

プロセス

プロセス機能

パフォーマンス属性

メトリクス(評価尺度）

ベストプラクティス

機能特性（含ｼｽﾃﾑ）

ＩＮＰＵＴデータ

ＯＵＴＰＵＴデータ

課題解決＝メトリクスの改善

プロセス改善

ベストプラクティス（ソリューション）

プロセス改革

納期遵守率需要予測精度リードタイム計画サイクルコスト在庫日数など

プロセス上の課題

プロセス上の課題解決による効果の算出

ＰＭ


ＩＴ投資への意思決定（多段階投資）デシジョンツリー分析

ｂ%（－Ａ＋Ｂ）

トータルＥＭＶ

期待額ＥＭＶ（Expected Monetary Value）＝確率×期待効果

－ｃ%×Ａ

u% × －Ｕ

例）Ｓ社Ａ＝約200億円（1994年からの累積投資）Ｂ＝約450億円（2001年の在庫削減1500億円と新聞発表）Ｕ＝約100億円、Ｖ＝約200億円（私の仮説）

-70億円

既存ｼｽﾃﾑ改修投資

ＥＲＰ導入か既存システム改修か

ＥＲＰ１次導入

ＥＲＰ２次展開

サプライチェーン改革投資効果ＥＭＶ=ｂ% ×Ｂ

企業成長

現状維持投資しない

b%

c%

インフラ整備投資効果ＥＭＶ=－Ａ

企業成長

現状維持

u%

v%

対応できない

インフラ整備投資効果ＥＭＶ=－Ｕ

対応できる

改修済システム廃棄して、再構築ＥＭＶ=－u% ×Ｕ

＋150億円

－80億円

ＥＭＶ=－Ａ＋b%×Ｂ

＋70億円

ＥＭＶ=－Ｕ＋v%×Ｖ

－40億円

対応効果ＥＭＶ=v% ×Ｖ

+30億円

v% ×（－Ｕ＋Ｖ）

60%

40%

-200億円

-100億円

70%

30%

経営トップの戦略的意思決定はこのデシジョンツリーを直感的に判断しているだけ

最終ゴール

ＰＭ


ＳＣＭプロジェクトの分析

方法論による段階的構築。

【体系的なプログラム計画機能への拡張は必要】・大手量販店との緊密な関係の構築。

(私の意見）このプロジェクトの進め方では、継続への方法論とマネジメントへの教訓は得られない。

問題４

業務改善の継続

・To-Be設計において、論理レベル４から物理レベル５～７への業務運用とITとのつながりを明確にする。

・別のプロセスモデリングツールとの組み合わせ記述。６つのプロセス要素が必要（ARIS）①機能、②アウトプット、③コントロール、④インプット、⑤組織、⑥データ

並行処理に長期間がかかってしまった。

・要件（業務運用、システム機能）の定義モレが多く発生。

例.販売会社からの返品処理がきちんと

規定されていない

・細かな例外処理の実装モレ。

問題３

仕様を網羅できずに、テストで数多くのトラブルが発生。稼動が４カ月遅れる。

・ＳＣＯＲでのAs-Isプロセス記述と可視化。

・合意形成がしやすい。

①改革方針の反映（最初に、目的達成へのメトリクスとL3プ

ロセスを選定する）

②意見でなく仮説で合意仮説設定（結果としての問題点）→仮説検証（結果としての問

題点）

・４社の業務用語が大きく異なり、コミュニケーションギャップが発生。

・目的を達成できるプロセス詳細で意見が分かれ、数百回の議論。

問題２

業務プロセスの議論が円滑に進まない

・ITはソリューション(How)に過ぎない。最初に、何(What)をソリューションすべきか、ＳＣＯＲを使って分析・設計する。

メンバの意識が業務改革ありきではなく、事実上はハード/ソフトの入れ替え作業。

問題１

４社共同化の前は、単なるIT入れ替え

ＳＣＯＲ＆分析・設計実践ガイドでは表現発生した問題

別会社に分かれた個別最適な製造、販売、物流などの業務プロセスを全体最適化。

目的①販売会社に対する納期回答。

②製品在庫は製造（EMCS)に一元化。（以前は各社に在庫を持つ）

③製造からの直送で、納入スピード向上。（以前は必ず物流センター経由）

2002年7月

-2004年4月

Ｓ社[日経コンピュータ2004年７月12日号より作成]


SCC-SCORプロジェクト方法論開発ＷＧ

2005年概要スケジュール

ＷＧ体制確立

立上げ

2005/4 2005/5 2005/6 2005/7 2005/8 2005/9 2005/10 2005/11 2005/12 2006/1 2005/2 2005/3

▲確定キックオフ▲ＳＣＯＲミニワークショップ

▲募集開始

技法・ツール

リファレンス（事例）取りまとめ

雑誌投稿

計画

「ＳＣＯＲ分析･設計実践ガイド」（ヤマハ殿）理解拡張･開発

検討

ＳＣＭプロジェクト現状と課題

ＳＣＭプロジェクトへの適用ライフ

サイクル検討

スコープ確定2005スコープ2006以降スコープ

拡張作業

実証実験・ケーススタディ

設計･開発

▲中間報告

企業への適用

開発作業

２グループに分かれて作業

テスト・開発

修正・追加

修正・追加

作成

終結

▲募集開始

実践ガイド

レビュー

6/10 7/88/19

scm改革とerp導入 統合への方法論 - airnet.ne.jp ·...

Documents

scm改革とerp導入統合への方法論 - airnet.ne.jp ·...