scm改革とit/erp導入の統合への4フェーズ方法論...

経営

ＩＴ

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

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

渡辺和宣

SCMとIT経営研究会

2005年5月発表から体系化と適用事例

ＳＣＭ改革とIT/ＥＲＰ導入の統合への４フェーズ方法論とビジネス

経営

ＩＴ


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

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

我々が提供できるサービス□ ＳＣＭ改革とＥＲＰ/IT導入またはＥＲＰ改善の全体計画策定□ ＳＣＭ改革とＥＲＰ/IT導入プロジェクトにおける、多くのタスクの統合マネジメント支援□ 経営戦略を踏まえたＥＲＰ導入企画の立案支援、ＲＦＰ作成支援□ ＳＣＭ改革やＥＲＰ/IT導入の基本構想や企画書への第３者評価□ 業務プロセス（中位、下位）設計結果への第３者評価□ ＪＳＯＸ対応のための、業務プロセスの文書化、IT全般統制

代表取締役渡邉和宣 [email protected]

［略歴］中小企業診断士、公認システム監査人、ＩＴコーディネータ、ＰＭＰ、ＰＭＳ、ＳＣＯＲアドバイザー、カリフォルニア州立工科大学鎌倉セミナー客員教授。大阪大学理学部卒業。大興電子通信（株）でシステムエンジニアとして情報システムの企画・開発業務に20数年従事した後、ＥＲＰパッケージの導入コンサルティング部門を立ち上げ、経営企画部門にて中期経営計画を策定、かつプロジェクトマネジャーとして自社へのCRM/ERP導入の完了後、2001年４月独立。2001年７月マネジメント＆ＥＲＰ社設立、同社代表取締役。産業車両メーカへのERP導入構想立案、製薬メーカのＰＭＯ支援、楽器メーカのERP導入統合マネジメント支援、産業機器メーカのＥＲＰ導入企画・選定支援、楽器メーカのサプライチェーン分析ガイドの作成支援、素材メーカのSCM改革構想とIT戦略の策定など。

[講演]法政大学エクステンションカレッジ、ITコーディネータ研修、データ総研共催セミナー、システム監査人協会、電子情報通信学会他［所属団体］中小企業診断協会、日本システム監査人協会、電子情報通信学会、ＰＭＩ、サプライチェーンカウシル（ＳＣＣ）など。[発表論文] 「ビジネスプロセス参照モデルを利用したサプライチェーン改革と情報システム構築の統合」ビジネスプロセス改革構想の立案

(2007)、プロセス上位設計(2006)、プロセス中位設計(2006)（以上、電子情報通信学会）［主な著書］『SAP革命』『SAP R/3 ハンドブック』『システムコンサルタントになる本』『情報システム部』

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

経営

ＩＴ



私の問題意識・追及テーマ

経営

ＩＴ


私の問題意識・追及テーマ

■ 米国は生産性パラドックスを脱却したか

■ 日本企業の情報化ステージはなぜ導入期に留まるのか

■ 戦略はなぜ誤るのか

■ 大規模ITプロジェクトはなぜ失敗するのか

■ SCMプロジェクトはなぜ失敗や長期化するのか

■ 経営トップ、ミドル、業務部門、IT部門はなぜ課題と解決を共有できないか

■ ITへの要求定義がなぜできないのか（ユーザ企業理容部門、IT部門、IT企業）

■ SCM全体適とものづくり個別適との折り合いをどう付けるか

経営

ＩＴ


1980年代後半、『生産性パラドックス』「新しい情報技術が、企業の純利益の段階で生産性や利益を向上させた明白な証拠はない。米国においては、新しい技術に対する投資が、全体の生産性と収益性の低下と時間的に一致しているという正反対の事実がある。」

1990年代前半、『BPR』リエンジニアリング以前には、「生産性に関してマクロ経済的にみた場合、情報技術が機能面で飛躍的に発達してきたにもかかわらず、今まで企業はその根本的変革に情報技術をあまり採用してこなかった。」

米国における『生産性パラドックス』研究

戦略アラインメント・フレームワーク［ボストン大学、ジョン・ヘンダーソン］1993

経営

ＩＴ


融合期

拡張エンタープライズ

ＩＴによる経営戦略

ITはビジネスモデルのための基盤

2%

経営とＩＴの統合

統合期部門の壁を超えた企業内統合

ＥＲＰ/ITは統合のためのツール

24%経済産業省2005調査による割合

74%

効果

部門レベルでの自動化

導入期

ITは部門業務の省力化のためのツール

ＩＴ投資が限定的効果

出所：渡辺和宣他「情報システム部」日本能率協会マネジメントセンター、2000に加筆・修正

ＩＴ投資の３つのステージ業務プロセスを統合へ改革しないSCMやERP/ＩＴ導入は、「導入期」段階

ＩＴによる企業内改革の限界

新たなビジネスモデル

＊

経営

ＩＴ


戦略はなぜ誤るのか

１.成長限界２.問題のすり替え３.成長と投資不足

０.問題認識の誤りで事態を悪化させる

出典：『インナーワーク』ティモシー・ギャロウェイ

経営

ＩＴ


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

プロセス設計、要求定義

原因

５億円以上のITプロジェクト納期遵守率は 51.0%コスト遵守率は 55.0%品質遵守率は 38.0%全部の遵守率は 10.7%コスト超過額加重平均 22.9%

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

経営

ＩＴ


ＳＣＭプロジェクトの効果と難しさ

サプライチェーン改革の効果事例京セラ、電子部品事業：メーカとの協働計画による週次生産と在庫一元管理で、部品在庫を４割削減。富士フィルム、記録メディア事業部：週次生産と工程改善、在庫拠点廃止で、リードタイム１／３、在庫６割削減。エプソン：事業部間でのコード統一「見える化」、設計時の共通部品化と集中購買で、調達コストを４割削減。松下：創生21ＳＣＭ関連（調達革新、週次生産計画）に326億投資で、在庫３割（3,000億円)削減など効果は513億。シャ－プ、家電製品：世界的ＳＣＭ稼動で６割（約1,500億）の在庫圧縮。累計投資額は200億。

４年間でのＲＯＩは約６倍（私が試算）ハウス食品：週次生産計画による在庫補充、ロット適正化（生産、配送、資材）など５億円の投資を１年で回収。

サプライチェーン改革において業務プロセス設計において、苦戦した企業が多い。例１：24カ月での稼動予定に対して、業務プロセス設計がほぼ５カ月遅延（約20%）・・・・電機例２：14カ月での稼動予定に対して、業務プロセス設計がほぼ４カ月遅延（約30%）・・・・電機例３：業務プロセス設計からIT要件定義までに14カ月、ほぼ６カ月遅延（全体の約20%）・・・・業務用資材

ＳＣＭプロジェクトの長期化傾向

稼動後、年間ＲＯＩは約1.5倍、投資は約８カ月-１年以下の期間で回収（上記例）

ＳＣＭ戦略における主な問題■ ＳＣ全体を分かる人がいない、戦略設計自体が不十分。■ 制約条件が残ったままで、SCM戦略の実効性が出ない。

業務プロセス設計・テストでの主な問題■ 用語の相違によるコミュニケーションギャップが発生。■ 自分のビジネスプロセスの変更や標準化への抵抗が多く発生。■ 目標達成へのビジネスプロセス詳細の設計に時間がかかる。■ 業務プロセスの設計の不十分さが、テスト時に判明する。

＊

経営

ＩＴ


ステークホルダの合意形成がむずかしい

出所：渡辺和宣「ビジネスプロセス参照モデルを利用したサプライチェーン改革と情報システム構築の統合」に加筆・修正電子情報通信学会、信学技報Vol.105 No.519, 2006

トップマネジメント

システム部門

ミドルマネジメント

業務部門実務担当者システム担当者

改革すべき現状

フル統合への壁

・組織、文化・制度・ルール・プロセス・人のスキル、意識・情報と情報システム

＊

経営

ＩＴ


要求定義トラブルをめぐる構造的背景

高度成長期・安定時代

グロ｜バル競争期

個別開発､ＥＲＰによる大規模開発

レガシーによる基幹システム構築

限定的範囲の保守作業が中心

明確な要求業務知識が不足

保守が中心開発は小規模

改善的要求を出すだけ

ＳＥは業務知識が欠如、ITスキル偏重

利用部門は情報ｼｽﾃﾑ部門はＩＴベンダーは

３者共、業務知識が不足したまま取り組まざるを得ない

CSS、Web等の新技術対応に追われる

ほとんどの大企業は20年以上前に開発が完了

部分効率化部門システム個別開発

業務引継ぎでブラックBOX化

不完全な要求定義になる可能性が高い

企業/システムの規模が

小さい

企業/システムの規模が

大型化

要求定義トラブル多発

関係する３者共に業務知識が不足

経営

ＩＴ



ＳＣＭ改革とＥＲＰ/ＩＴ

導入の統合（体系編）

階層型プロセスモデルを活用した

Methodology of "Top-Down & Bottom-Up bisynchronous approach“convergence

経営

ＩＴ


上流失敗事例より

事例１：IT系コンサル会社は上流成果物であるプロセス(上位)設計が何も完成せず、下流工程のERP導入作業への突入をはかる。

事例２：戦略系コンサル会社の上流SCM構想アウトプットが、プロセスとプロジェクトにに落とし込まれておらず、着手できずに棚上げとなる。

事例３：IT系コンサル会社は、提案した構想成果物を完成できずに(定量効果も算出できず）、途中からＥＲＰ導入へ誘導を図る。

事例４：メインフレーム系コンサル会社は、SCMプロセス設計を自社パッケージをベースに作成、顧客はIT選定できず。

＊

経営

ＩＴ


事業戦略と情報システムの整合性ヘンダーソンの戦略アラインメント・フレームワークを分解すれば

事業戦略情報戦略

情報システム基盤組織基盤とプロセス

＊

事業戦略

マーケティング戦略等

SCM戦略等

戦略課題

戦術（CSF）

戦略要素の構造化

ITへの要求ソリューション探索

ITへの要求

情報戦略

ソリューション探索

組織、ルール、プロセス、人

組織、プロセスの構造化

レベル２

レベル３

レベル４

レベル５

改革要求設備、組織、業務ルール、プロセス機能、人のスキルと意欲、情報と情報システム

ITインフラ、アプリケーション、データ、利用者のリテラシー

情報システム資産への分解

ＲＦＰ、ソリューション選定

情報システム資産構築

改革要求情報と情報システム

経営

ＩＴ


プロジェクトライフサイクルによるフェーズ分割の考え方

プロジェクトフェーズ(プラントの場合）

ﾌｰｼﾞﾋﾞﾘﾃｨｽﾀﾃﾞｨ（構想）

基本計画

（企画）

開発・導入運用(施工、引渡)

実行計画

(設計)

運用

大規模プロジェクトにおけるリスクと費用・工数（大規模かどうかは、絶対額ではなく組織の規模と投資額の比率で考えるべき）

工数・費用の割合

プロジェクト成功 20%/80%の法則NASAの経験則では、全工数の20%を構想・企画で消費することで、潜在成功率を70-80%に確保できる

プロジェクトリスク

パッケージ

＊

経営

ＩＴ


プロセス改革の５つのフェーズと目的主な内容

Ⅰ プロセス改革構想

＜フィージビリティスタディ＞

プロジェクト機会の発見即ち、プロセス改革の事業価値を見つけ出す

トップダウンアプローチによって、短期間で

・事業戦略の構造化による改革構想の立案

・費用と効果の算出（超概算見積り）

・改革ロードマップの策定

Ⅱ プロセス改革企画（プロセス上位設計）

＜基本計画＞

プロジェクトとしての基本計画の立案これには事業価値の検証を含む

トップダウンとボトムアップアプローチを組合せて

・ボトムを交えて、改革構想のより詳細化・具体化

・費用と効果の算出（概算見積り）

・組織全体の合意形成とプログラム計画の立案

Ⅲ プロセス改革計画（プロセス中位設計）

＜実行計画＞

プロセスの概要設計によるプロジェクトの詳細な実行計画の立案これにはIT選定を含む

プロセスの概要設計を行って

・改革構想を具体的にプロセスに落とし込む

・プロセス標準化、ITへの要求の明確化と選定

・プロジェクトの実行計画の立案（詳細見積り）

Ⅳ プロセス改革実施（プロセス下位）情報システム開発

＜開発・導入＞

プロセスの詳細設計、IT導入・開発の実施

プロセスの詳細設計と構築を行って

・新たなプロセスの構築、業務ルール集などの整備（人間系プロセス）

・ITの導入・開発（IT利用プロセス）

Ⅴ 改革プロセスの運用＜運用＞

プロジェクト価値の発現即ち、投資の回収

改革されたプロセスや導入されたITを実際に運用して、計画された効果をあげる。

プロセス改革にプロジェクトライフサイクルを導入する

＊

経営

ＩＴ


戦略から業務プロセス・情報システムへ４つの一貫した方法論によって、成果物（プロセスとプロジェクト）が連携

プロセスレベル

利用するモデル

開発し利用する方法論

０

１

２

３

４

５

プロジェクト管理ﾌﾟﾛｼﾞｪｸﾄﾌｪｰｽﾞ

フェーズ名上段：ホール下段：ＩＴＣプロセス

出所：渡辺和宣「入手可能なビジネスプロセス参照モデルの紹介および利用による効用」電子情報通信学会、信学技報Vol.107 No.128 , 2007 に加筆・修正

業務体系図：企業全体の業務を網羅業務モデル：経営管理、経理・財務、販売・マーケティングなどＳＣＯＲモデル：SC計画、購買、生産、受注・出荷DCORモデル：製品開発、技術開発CCORモデル：顧客開拓、販売

同技法

木

森

太枝

枝

細枝

葉

プロセス改革構想SCM戦略IT戦略

事業戦略業務体系図

戦略課題業務モデル/ＳＣＯＲモデル

経営機能別課題

スキームプロジェクト（P2M)

ﾌｨｰｼﾞﾋﾞﾘﾃｨｽﾀﾃﾞｨ(経営戦略)

業務要求業務課題

業務モデル/ＳＣＯＲモデル

業務プロセス改革テーマ

業務モデル/ＳＣＯＲモデル

基本計画(情報化企画)

プロセス改革企画プロセス(上位)設計

全体計画

業務プロセス改革解決策

業務プロセス・テンプレート

実行計画(資源調達)

プロセス改革計画プロセス(中位)設計業務プロセスとIT

プロジェクト個別計画

プロセス改革実施プロセス(下位)設計

IT導入・開発

業務プロセス情報システムなし

↓ＥＲＰ→業務プロセス中心

ERP導入方法論開発→クラス設計＆

オブジェクト指向開発

システムプロジェクト（P2M)PMBOK3

開発・導入(開発)

分解方法論

論文電子情報通信学会、信学技報SWIM2005-23（2005)

論文２本電子情報通信学会、信学技報SWIM2006-2(2006)

論文電子情報通信学会、信学技報Vol.107 No.128 , 2007

論文電子情報通信学会、信学技報SWIM2007-14(2007)

論文電子情報通信学会、信学技報2008予定

＊

経営

ＩＴ


Ｌ２

Ｌ１

Ｌ３

Ｌ４

Ｌ５

プロセスタイプ

プロセスカテゴリー

プロセスエレメント

アクティビティ

トランザクション

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

SCOR他

プロセス階層レベル

ＥＲＰ・IT

プロセス分析全体計画作成改革要求、テーマ改革の全体計画プロセス設計/詳細計画プロセス/SCM改革プロジェクト実行

Ｌ３’

Ｌ０

全体構想

実装

実装

実装

IT/ERP新規導入・開発既存修正

意思決定支援ITによる情報共有ITによるプロセス支援

実装

プロセス

設備・工程他組織・ルールプロセス人のスキル・意識ITによらない情報

/SCM改革

業務プロセス概要設計ＩＴ/ＥＲＰ導入プロジェクト

IT/ＥＲＰ詳細設計ＩＴ/ＥＲＰ開発

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

ＩＴ/ＥＲＰ機能概要設計

業務ｼﾅﾘｵ

As-Is概要ﾌﾟﾛｾｽ

To-Be概要ﾌﾟﾛｾｽ

設計

To-Be詳細ﾌﾟﾛｾｽ

As-Is詳細ﾌﾟﾛｾｽ設計

設計

全体計画

As-Is分析

As-Is分析

プロセス以外の

改革

プロセス改革

To-Be設計実現策

To-Be設計

戦略CSF

戦術

非ﾌﾟﾛｾｽ系戦略課題

ﾌﾟﾛｾｽ系戦略課題

経営戦略事業戦略


メリット・戦略を業務プロセスに落とし込める・フェーズに沿った階層レベルの分析・設計に集中できる・プロジェクトマネジメントが容易になる・外部コンサル工数が、かなり少なくて済む・ヒアリングでなくモデル利用のインタビューによる高い品質

業務プロセスの観点から、プロセス/ＳＣＭ改革とIT/ＥＲＰ導入・改善は統合できる

戦略は、段階的詳細化によって業務プロセスへ落とし込める＊

経営

ＩＴ


要求の階層化

プロセスレベル要求例要求の種類

事業戦略０

戦略課題１

業務要求業務課題２

業務プロセス改革テーマ３

事業部顧客要求納期遵守製品在庫の削減

営業系、工場系見込生産から受注生産へ

特定営業、工場半製品見込生産製品受注生産

(大)業務プロセス有効在庫管理在庫引当納期回答

業務プロセス改革実現策と標準化

４

業務プロセス情報システム

５

情報システム６

(中)業務プロセス週次生産在庫精度ITによる納期回答

(小)業務プロセス週次需給計画ATPロジック

利用可能在庫計算

業務要求ユーザ要求

ＲＦＰ（提案依頼書）→ﾍﾞﾝﾀﾞと契約

ERPﾌｨｯﾄ&ｷﾞｬｯﾌﾟ

要求定義書

ｿﾌﾄｳｴｱ要求仕様書（SRS)

自力、または情報子会社

ERPｿﾘｭｰｼｮﾝ設計

ERPﾊﾟﾗﾒｰﾀ設定ERPｱﾄﾞｵﾝ開発

ｵﾌﾞｼﾞｪｸﾄ指向分析、設計

ｵﾌﾞｼﾞｪｸﾄ指向ﾌﾟﾛｸﾞﾗﾐﾝｸﾞ

上位要求

中位要求

下位要求

Business Requirements

User Requirements

Requirements

日本企業の評判（インドIT企業）・要求仕様が曖昧・丸投げしてくる・変更を押し付けてくる・日本が嫌い

部長

課長

係長

担当

統括部長

事業部長

オペレータのためのERP（日本）

事業戦略、マネジメント

一般ユーザ

パワーユーザ

外部・間接

業務プロセス標準化

経営

ＩＴ


出所：渡辺和宣「ビジネスプロセス参照モデルを利用したサプライチェーン改革と情報システム構築の統合（詳細計画フェーズ）」電子情報通信学会、信学技報Vol.106 No.85, 2006 に加筆・修正

情報活動設計活動

検討活動

情報活動選択活動

プロダクト確認

意思決定ニーズの把握

対象の認識と制約条件やギャップ等の把握

代替案の選択意思決定ニーズと制約条件のバランシング

意思決定案の確定選択した代替案で意思決定ニーズが達成可能かを確認

複数の代替案の設計・立案

プロセス構成要素 ①プロセス機能②インプット③アウトプット④リソース⑤コントロール⑥人・組織

ビジネスルール

オブジェクト

オブジェクトプロダクト/リソース

意思決定者、実行者

オブジェクトプロダクト/リソース

① ③

⑤② ⑥

④

製造指図

原材料旋盤加工処理

部品

②④

業務プロセスの基本構造と構成要素ＳＣプロセスにも、H.A.サイモンによる意思決定プロセスを拡張

＊

経営

ＩＴ


出所：渡辺和宣「ビジネスプロセス参照モデルを利用したサプライチェーン改革と情報システム構築の統合」電子情報通信学会、信学技報Vol.105 No.519 , 2006 に加筆・修正

４アクティビティＥＲＰ/ITプロセス

５トランザクション

ＥＲＰト/ITトランザクション

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

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

ＥＲＰ/ITの範囲

３プロセスエレメント

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

D1.1：引合と見積

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

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

２プロセスカテゴリー

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

Plan：P1-5、EP、Source：S1-3、ES、Make：M1-3、EM、Deliver：D1-4、ED、Return：R1-4

P1,P2,P3,P4

S1

S2

S3

M1

M2

M3

D1

D2

D3

1プロセスタイプ

プロセスのタイプを指定する。Plan：計画、Source：調達、Make：製造、Deliver：受注・出荷、Return：返品

Plan

Source Make Deliver

Return

ＳＣＯＲの範囲

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

人間系プロセス（意思決定、手作業）

論理モデル

物理モデル

・・・

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

SCOR拡張

業務ﾌﾟﾛｾｽﾃﾝﾌﾟﾚｰﾄ

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



＊

経営

ＩＴ


業務プロセステンプレ｜トとは

SCOR Level-1Level-2

Level-3

フローチャート例

Level-4

プロセス定義書例

業務プロセステンプレートとはSCORレベル４に位置する計画、購買、生産、受注出荷プロセスSCCJ-WGで研究したものを(株）マネジメント＆ERP社で拡張①プロセス構成要素の拡張②Enabel系プロセスを全て定義、合計約500以上のプロセス③SCOR8.0対応④SCC加入を条件として販売中

業務プロセステンプレートの利用局面①プロセス群の整理・文書化、要求定義②プロセス個別の改善、欠落したプロセスの整備、業務ルール整備など③プロセス個別の強化、ベストプラクティスやソリューション選定④プロセス群の標準化、ベンチマーキング⑤新事業への進出などによる、新たなプロセス群の設計

＊

経営

ＩＴ


階層型プロセスモデルを利用した技法による効用一覧

戦略・戦術に対して<階層レベル１～３>01 対象ドメイン全体を可視化し鳥瞰できる02 モデルを使った「見える化」で課題や考えを「引き出せる」03 戦略・戦術をプロセス階層レベルに沿って「構造化」することでレビューできる04 トップダウンとボトムアップ融合による合意形成ができ, 戦略・戦術を「品質向上」させる05 階層レベルに沿う段階的詳細化によってプロセス分析・設計作業を「生産性向上」させる06 モデルを使って議論や検討を集中することで「生産性向上」させる

業務プロセス設計とIT導入に対して<階層レベル３、レベル４>07 戦略・戦術をプロジェクト計画と業務プロセスに「反映」できる08 プロセスの統一の際に中立的モデルとして利用できる09 プロセスの標準化の際にモデルのプロセス要素を利用できる10 精度の高い情報システムのRFPや要求仕様書（ＳＲＳ）を作成できる11 モデルは業務知識や実務経験が浅い開発者を支援・教育できる12 モデルを利用して、業務アプリケーションの再エンジニリング、再利用化に取り組める13 優先順位付けによってスコープクリープと要求の進化へ対応できる14 段階的詳細化によって業務改革とIT導入の同時進行と統合マネジメントが可能となる

<SCOR独特の効用>A SCMやIT導入の効果を定量化できるB プロセス改革やIT施策について、ベストプラクティスやITソリューション例から選定できる

＊

経営

ＩＴ


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

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

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

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

工場管理

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

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

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

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

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

装置（製造の実施）

６

５

４

３

２

１

機器群管理

設備自動化機器制御機器

エリア

メジャ｜工程

マイナー工程

作業（作業実施）

帳票、画面指示設備指示

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

SCOR

分散システム

FA

制御システム

NC、MCロボット

製品別

計画系

工場別製品別

計画系

工場別製品別工程別

製造実行系

工場別製品別工程別

製造制御系

相互調整プロセス

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

分散プロセス

分権化プロセス

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

ＥＲＰ機能

計画・実績機能

製造実行機能

ＭＥＳ

ＳＣＰ機能

または

相互調整プロセス

分散プロセス

分権化プロセス

Ａ工場Ｂ工場

全社共通

製品・工場・製造工程

共通化と個別化の切り分け

Ｌ２

Ｌ３

Ｌ４

Ｌ５

Ｌ６

＊

経営

ＩＴ



何を困っているかベンチャー研究開発型企業と共通

経営

ＩＴ


見込顧客が少ない

■ 言われることは分かるが・・・・－自分の仕事は、IT部門だけやっていればよい－SCMは工場でやっている－自分のSCMは需給調整だけでいい●他部門のことには口を出さない、お互いの幸福のため●全体を見るのは、社長と事業部長だけ

■ そんなの知らないな・・・・・－マネジメント＆ERPなど聞いたことがない－SCOR？我社は独特なのだ、モデルなど使える訳がない－知らない会社で聞いたことがない手法で失敗したら●改革に苦労するよりも無難に●問題は皆が分っているが、私の組織の責任ではない

経営

ＩＴ


受注顧客（実績)が少ない

■ 不信●過去にコンサルティング会社で失敗した（トラウマ）

●コンサルを入れたいと言えない（自分でできないのかと言われる）

■ 不要●社内だけでやる（社内コンサル制度がない、ファシリテータも不要）

●情報子会社があるのでやってくれるだろう（過剰な期待）

■ 不急●自分達のニーズと提示された価格が合わない●効果が今一つ見えない

■ 不適●知名度がない（ブランドコンサル会社を採用）

●コンサルと相性が合わない

４つの「不」（栗山氏）で整理すると

欲求

契約

経営

ＩＴ


コンサルがコンサルティングを受けて

□ 課題を客観的体系的に整理できた○４Ｐを知ってはいる、お客のは整理するが○パートナー分類

□ 気付かせてくれた、提案してくれた○ＨＰ、プレスリリース○顧客ランク分類

□ 時間を節約できた○パートナー活用方針○方法論などの開発に時間を使いたい（ベンチャーのサガ）

□ 信じてくれた○信念はあるが、常に不安な気持ち○自分のコンセプトを支持してくれた（説明は未だ、人を信じた）

経営

ＩＴ



ＳＣＭ改革とＥＲＰ/ＩＴ

導入の統合（理論編、事例編）

階層型プロセスモデルを活用した

経営

ＩＴ


本社系部門本社系部門本社系部門本社系部門工場工場工場本社系部門

事業部戦略事業部戦略事業部目標事業部目標

事業部戦略事業部目標工場

主要課題改革施策

設備、組織、業務ルール、プロセス、人、システム

改革投資対効果

改革全体構想

戦略が不明確戦略が戦術より下の詳細レベル戦略が個別、相互に不整合部門にまたがる戦略課題が出にくい

リファレンス

業務モデル

特長

改革構想方法論

効果的かつ効率的手順

当社独自

リファレンス

SCOR

SCM課題分析方法論


当社独自

SCOR実現策

特長

SCORアドバイザー

レベル１、レベル２

ベストプラクティス

経営機能別業務要求

戦略課題の抽出

ＳWOT分析

業務課題ｲﾝﾀﾋﾞｭｰ

営業系課題

工場系課題

SCM課題

管理系課題

SCM課題分析

改革施策/構想

IT戦略構想ﾍﾞｽﾄﾌﾟﾗｸﾃｨｽ

他社事例

SCM効果算出改革投資概算

ロードマップ

広範囲な課題インタビュー

複合した課題の抽出

事業戦略を構造化

コンサル工数少かつ高品質な構想立案

戦略コンサルと業務・ITコンサルの組み合わせ

業務/SCORモデルの階層に沿って戦略,戦略課題を構造化→MECE、効率的

プロセス分析/全体計画

レベル２・３分析・設計へトップダウンとボトムアップの融合

「サプライチェーン改革とIT構築の統合」（改革構想）トップダウン戦略分析＆戦略構造化

＊

経営

ＩＴ


SWOT分析・戦略課題の抽出市場環境分析、SWOT分析、戦略課題と経営機能別業務要求の抽出、確認

事業戦略戦略課題

経営機能別業務要求

105

経営

ＩＴ


工場系業務課題の抽出各工場の全般、SC上の課題、業務課題から全工場共通の業務課題へ

工場別全般課題

工場長インタビュー

工場全体の視野から工場課題を抽出

工場をめぐるモノと情報の流れ

工場と他の関係から生販在課題を抽出するため54個の質問項目（SCORベース）

全工場共通かを検討

課題が与える工場や営業への悪影響

各工場の計画系、製造実行系業務インタビュー結果から課題と原因(仮説)を抽出する

計画系、製造系、品質系の業務診断

工場個別業務を診断するため60個の質問項目（業務プロセステンプレートをベースに）

110

経営

ＩＴ


工場全体計画

調達計画生産計画出荷計画

原料調達生産出荷

購買全体計画

調達計画出荷計画

原料調達納入

営業全体計画

仕入計画販売計画

仕入販売・納入

生販在課題特定

業務要求/業務課題の内容特定

課題の根本原因の特定

＊SCOR（米国SCCのサプライチェーンモデル）

生販在課題の調査準備（現状調査）

仮説

レベル2プロセスチェックリスト（対工場）

参照モデルに基づき、モノと情報の流れに潜む地理、商品、組織面からの問

題点の検証

SCORに基づいた

工場別診断表（対工場）

工場における課題全般ならびに業務・品証に関する問題の洗い

出し

PLANプロセスチェックリスト（対工場、営業）

参照モデルに基づき、全体計画としての影響度、実行計画としての機能レベルを評価

要件と制約に関するINPUT情報の精度や充足度要件と制約のギャップを調整するメカニズムの有無や有効性などOUTPUT情報に基づく現場の成果や効率

SCORに基づいた

生販在課題抽出方法SCORに基づく２種類のチェックリストから生販在の主要課題を抽出

130

経営

ＩＴ


改革全体構想(IT戦略）書の例

投資対効果の大きなシステム構築

経営計画事業戦略

あるべき経営機能

システムへの要求

長期的情報戦略

事業部長、本部長

市場環境分析強み･弱み・機会・脅威（SWOT)事業戦略と戦略目標

部門長（本社、工場）

確認

経営管理、購買、会計・財務、経営情報生販在全体、工場別（生産、品質、原価）、営業・マーケティング

情報システム支援要求グループ連結会計、一般購買、経営情報分析、需要予測、生販在計画、原料購買、工程計画・実績、品質管理、原価（標準、実際）、受注・販売、出荷物流、マーケティング等

全体構想（IT戦略）プロセス改革と情報システムへの要求と現状とのギャップを解消するためのIT戦略やロードマップを策定

明確化業務プロセス改革要求営業系、SCM系、工場系、管理系*組織・業務ルール、

業務プロセス、スキル向上

分解

業務課題

全体計画（IT、プロセス改革）全体構想を詳細機能に落とし込み、具体的な計画立案

構想

戦略課題（業務要求）

第1章-1

第1章-2

第1章-3

第４章第４章

第５章

第６章次

事例190-01

経営

ＩＴ


ベストプラクティスを含む実現策

ＳＣＭ戦略ＳＣＭ目標

改革テーマ付きレベル３プロセスレベル３’プロセス

段階的な全体計画

目標が定量化されていない戦略が詳細過ぎて戦略でない戦略間の不整合戦術がアンバランス・ITに頼り過ぎ・組織・業務ルールから逃避

リファレンス

SCOR

特長特長

SCM事例集

SCORベストプラクティス

実現策

上流方法論


当社独自

レベル２、レベル３

ＳＣＣ

ＳＣＣ

レベル２As-Is分析To-Be設計

レベル３As-Is分析To-Be設計

改革テーマと実現策

ＳＣＭ戦略の構造化

ＳＣＭ改革目標の定量化

改革への全体計画の策定

戦略課題

戦術

修正・補完・補足、検証された戦略

体系化された目標

トップダウンとボトムアップの融合

検証された戦術

複数手法

複数手法

見える化

ERP機能から選定整合性の確保

リスクが小さく実現可能な計画SC改革、IT計画

ＳＣＭ戦略・戦術によって全体適を具体化

戦略・戦術をプロセスへ具体化

ＳＣＭ改革への組織全体の合意形成業務プロセス設計

コンサル工数少かつ高品質な構想・企画

マネジングコンサルと業務別コンサルの組み合わせ

プロセスモデルの階層に沿って分析・設計を進める→MECE、効率的

「サプライチェーン改革とIT構築の統合」（企画、プロセス上位設計）トップダウン＆ボトムアップ融合

＊

経営

ＩＴ


Ｌ２階層化

Ｌevel１

Ｌ３階層化

ＳＣＭ戦略

プロセス階層レベル

【210-01】事業戦略の確認【210-03】SCM戦略の確認

ミドル要求

スポンサー要求

整合性確認

ＳＣＭ戦略展開【210-04】SCM戦略の階層化(レベル２）

【210-07】スポンサー要求の引き出し

【210-08】ミドル要求の引き出し

【210-09】目標との整合性の確認

【220-01】現状レベル２プロセス調査

【220-02】課題・問題点出し【220-04】改革アプローチ【220-05】機能・課題展開アプローチ

【220-06】仮説・検証アプローチ【220-07】分析まとめとレビュー

分析レビュー

レベル２階層化分析結果

Ｌ２分析

ToBeプロセス

【230-01】現状レベル３プロセス調査【230-02】課題・問題出し【230-04】課題分析・分類アプローチ【230-05】機能展開アプローチ【230-06】メトリクスアプローチ【230-07】分析まとめとレビュー分析レビュー

【225-01】レベル２設計とレビュー

Ｌ３分析

レベル３階層化分析結果

ToBeプロセス【235-01】レベル３設計とレビュー

【235-02】レベル３設計の実現策選定

ＳＣＭ戦略の確認・修正・補完

ＳＣＭ戦略の検証

プレーヤごとのレベル２ＳＣＭ戦略を実現するためのレベル３分析

トップダウン

ボトムアップ

戦略

戦術Ｌ３設計

ToBeプロセス実現策

実現策

（改革テーマ）

（ベストプラクティス）

ＳＣＭ戦略を補足トップダウンとボトムアップの融合

Ｌ２設計

ＳＣＭ戦術の検証

【210-02】SCM目標の確認ＳＣＭ目標

レベル１目標

レベル２目標

【210-04】SCM目標の階層化

レベル３目標

【210-05】SC改革効果の定量化

目標体系化

レベル２・３分析・設計の各ステップの関係


＊

経営

ＩＴ


P1

P2|P5

SMD

PLAYER 工場本社販売･物流部門

スレッドダイアグラム全体計画

全体計画

全体計画

調達計画

調達計画

調達計画

出荷計画

出荷計画

出荷計画

生産計画

汎用品調達

標準品調達

標準品出荷

見込生産

標準品出荷

標準品調達

標準品出荷

【1-6】⑨1.適正在庫の設定と出荷

【1-6】③1.小ロット生産⑨2.半製品から

の受注生産M2

【1-6】⑥1.出荷リクエストに基づく

生産計画⑦3.週次生産計画

【1-6】④3.半製品在庫計画⑩2.仕販在計画のチェック

【1-6】⑤1.輸送混載の見直し⑤2.生産計画連動した船積計画⑦3.船積計画⑨1.適正在庫の設定と出荷

【1-6】⑩1.需要予測精度の向上

【1-6】①1.材料計画在庫（Ｐ２）

【1-6】①2.調達ＬＴの短縮（ＥＳ）、②2.外注化（ＥＳ）

レベル２プロセス（モノと情報の流れ＋戦略）

【1-6】SCM戦略の階層化【1-7】④半製品の在庫・生産計画⑦販社と事業部の計画統合

【1-7】④半製品の在庫・生産計画

【1-7】⑦販社と事業部の計画統合

【1-7】スポンサー要求

【1-7】④半製品の在庫・生産計画

【1-7】④半製品の在庫・生産計画【1-8】⑥1.出荷リクエストが揃わない⑥2.新モデルの歩留まりを

考慮していない⑨2.半製品の生産計画のための出荷リクエストが揃わない

【1-8】ミドル要求

メリット・スポンサーの思いを引き出せる・ミドル要求を引き出せる

スポンサー要求やミドル要求の引き出しの際に利用するケース


ＳＣＭ戦略の見える化例210-09

経営

ＩＴ


仮説－検証アプローチ

P4

2

3

1

P1

P2|

P5

SMD

PLAYER

2

1

3

S1 M1 D1 S1 D1 S1 D1

P1

工場・サプライヤ本社・メーカ販社・顧客

P4

P1

P4

P1

P3

P1

P4P2

P2 P4P3 P2

P2

P2

Ｐ２、Ｐ４は今回評価せず

3

1Ｐ｜Ｅ

2 ＥＰＥＰＥＰ

P4

予想結果１：納期遵守の責任を持てない。

ＷＳからの結果カード販社・顧客に対する精度の良い納期回答が、船積直前になるまで出せない。(工場・サプライヤ)

P1

予想結果２：供給計画が市場状況に連動しない。

ＷＳからの結果カード欠品や過剰在庫が発生することがある。（販社・顧客)

メリット・クロスファンクショナル・チーム

から問題やアイデアを引き出しやすくなる

220-06

経営

ＩＴ


現状業務プロセスの見える化例（変形SWIMチャート）サプライチェーンの基本業務プロセスを、A3 １枚に書く

海外販売会社

日本本社

海外製造会社

調達計画

サプライチェーン全体計画

出荷計画

在庫品出荷

見込生産

在庫品調達

■■製品グループ

調達計画

生産計画

出荷計画

在庫品調達

在庫品出荷データ業務ルール

実需としてのデータ精度が悪い

ルールを遵守していない

現地製造能力の把握が不十分

製造能力とアンバランスな生産計画

正確な納期回答ができない

メリット・１枚に全てのプロセスが書ける・プロセス間の影響関係が見える・データの連携が見える

事例230-01

経営

ＩＴ


P1.1 サプライチェーン全体の要件の特定、優先順位付け、及び集約

P1.2 サプライチェーン全体のリソースの特定、評価、及び集約

P1.3サプライチェーン全体の要件とリソースのバランス度合いの把握

P1.4サプライチェーン計画の確立と通知

(海外A工場) 計画決定方針：新規設備投資を必要とし

ない範囲で販社の要求を受ける(本社事業部)工場平準化／年間負荷調整（海外A工場)サプライチェーンパフォーマンス改善計画

（米国販社）月次生産リクエスト（米国販社）現地仕販在計画(本社事業部)事業部全体売上

金額換算（海外A工場)受注残、出荷情報

計画済みデータ

確定案内/APO(米国販社)製品生産連絡（A工場生産計画)

(購買部）（事業部営業）

事業部売上予算見通し確認データ（経営管理）

(海外A工場)材料調達計画(購買)KD材料、現地MaskROM等の

専用材の調達計画（海外A工場)外注含む人員・設備計画(海外A工場)生産調整計画(本社事業部）前回の生産連絡(米国販社)販社を含む在庫値

レベル３分析：Ｐ１需給計画の問題はどこに原因があるか

P1需給計画プロセスが標準化されていない・業務ルールが遵守されない、実態と合わない・インプットデータの欠落、精度の悪さ

このままSCMソフトを導入しても問題は解決しない

事例

エンディングパーツしか計画していない

生産リソースを考慮せず（設備、材料、人員）

期中では存在せず

守られていない（海外A工場は言えば作ってくれる）

キャパシティを１万台超過出荷オーダ遅れ

出荷オーダが直前にしかこない（ルール違反）

生産平準化の限界

事業部のデータ把握が不十分

在庫情報の精度が悪い

230-04

非公開

経営

ＩＴ


業務の標準化内部統制構築

リスクコントロールの組み込み

To-Beレベル４概要プロセス

レベル４As-Is概要プロセス

情報システム詳細計画

ＳＣＭ戦略

ＳＣＭ目標上位設計実現策

合併しても業務プロセスは複数が残ったままさらに個人によっても異なる人間系を含めたプロセスが標準化されないままIT導入しようとする（非整流）内部統制・法規制を考慮してない

JSOXリスクチェックリスト

SCOR拡張

業務プロセステンプレート

リファレンス

リファレンス

中流方法論


特長特長

レベル４当社独自

当社独自

当社独自

SCORベストプラクティス

実現策

ＳＣＣ

戦略・戦術が反映標準化された

効率的な対象絞込み費用対効果に優れた

明確になったIT要求優先順位付けルール

コンサル工数少かつ高品質なプロセス設計

プロセスコンサルと業務別コンサルの組み合わせ

ＳＣＭ戦略とＪＳＯＸを業務プロセスに設計


プロセスモデルの階層に沿って分析・設計→標準化､要求の

優先順位付けＲＦＰへ

「サプライチェーン改革とIT構築の統合」（計画、プロセス中位設計）業務プロセスに戦略・戦術を落とし込み、標準化する


実現策の業務シナリオへの反映

企業資産としての標準的プロセス

簡素化、標準化、完全化、効率化

財務報告の信頼性リスク識別,リスクコントロール設計

法規制の遵守リスク識別,リスクコントロール設計

ユーザ要求定義

現状プロセスの整理・文書化

業務シナリオ

要求の優先順位付け

RCMリスクコントロールマトリクス

JSOX会社法

出所：渡辺和宣「ビジネスプロセス参照モデルを利用したサプライチェーン改革と情報システム構築の統合（詳細計画フェーズ）」電子情報通信学会、信学技報Vol.106 No.85, 2006 に加筆・修正

＊

経営

ＩＴ


業務プロセスの標準化の流れ

簡素化、標準化完全性、効率性(プロセスイノベーション）

As-Is概要業務プロセス

業務シナリオとのベストプラクティスベンチマーキング

As-Is同士のインターナルベンチマーキング

SCORベース業務シナリオ

To-Be概要業務プロセス

改善方法の検討（SCORのベストプラクティスを参考）改善を反映

（業務シナリオの向上）

レベル４プロセス

ＳＣ別物理モデルとしての構成ステップ(アクティビティ）

改善すべきアクティビティプロセス要素

①機能②INPUT③OUTPUT④リソース⑤コントロール⑥組織・人

330

経営

ＩＴ


Ⅲ. レベル４プロセスToBe設計の成果物Ⅲ-１．個別プロセス記述書例

標準化・簡素化され、ベストプラクティスにより効率化された新たな業務プロセス記述書が作成できる。承認された後は、プロセス/IT構築のレベル５プロセスに移る。

プロセスの構成要素 ToBe設計された業務プロセス詳細記述（アクティビティ）

プロセス番号 D1.1-6

ステークホルダ顧客

見積回答の送付

作成した見積回答を顧客に送付するプロセス。必要に応じ、関連部署に情報を提供する。見積伝票をこれ以降の受注伝票、出荷伝票、請求書伝票に連携させる。

(下段)ＩＴシステム機能商談管理システムにおいて、見積プロセスと見積書を履歴管理。

②インプット１見積書(D1.1-5)

見積拒否、不能連絡

③アウトプット１オーダ見積り(顧客)

顧客見積(D1.2-1)

オーダ見積り(ED.3)

顧客情報(ED.7)

出荷時点で (売掛金) / (売上)

(売上原価) / (棚卸資産)"

引合ルール(ED.1)

引合回答率引合と見積タイプ毎コスト

見積書の上司承認

営業第１部

プロセス名称

①目的・機能

(上段）人間系を含めた全て

②インプット２

④発生する仕訳

⑤コントロール（パフォーマンス）

⑤コントロール（ルール）

⑤コントロール（財務報告）

⑤コントロール（法規制）

⑥担当責任（組織、人）

標準化・簡素化、ベストプラクティスが反映されたプロセス機能

ベストプラクティスが反映されたシステム機能案＝機能要求

整備すべき業務ルール

プロセスの評価指標＝非機能要求

組み込むべきJSOXコントロール

組み込むべき会社法コントロール

担当組織または新たに設置すべき組織

不足しているインプットを追加

作成すべきアウトインプットを網羅

RFP作成

355

経営

ＩＴ


SOAサービス設計、コンポーネント設計の流れ

業務プロセスの構造化

業務プロセスの標準化（プロセス機能、Input、Output、

業務ルール）

ソフトウエアコンポーネント開発・運用

ソフトウエアサービス機能のコンポーネント化

ソフトウエアサービス機能の共通利用設計

プロセスレベル

１

２

３

４

５

SOAサービス設計、コンポーネント設計の要点

アクティビティ

支援する方法論・ツール

業務プロセス（上位）分析・設計方法論

業務プロセス(中位）の標準化＆分析・設計方法論業務プロセステンプレート（ヒナ型）

成果物

事業戦略を反映したレベル３SWIMチャート(プロセスにマッピングされた改革テーマと実現策)

レベル４業務フローチャート業務プロセス詳細記述書(プロセス、システム機能)

レベル５ビジネスユースケースシステムユースケース

レベル５分解方法論（粒度）

トランザクション

業務プロセス(下位）の標準化＆分析・設計方法論

６トランザクション機能

レベル６システム分析モデル・静的構造図（コンポーネント図、クラス図他）

７業務部品、クラスライブラリ

レベル７システム設計モデル・動的振る舞い図（シーケンスダイアグラム他）・プログラム

オブジェクト指向分析プロセス（コンポーネント化）

オブジェクト指向設計プロセス

オブジェクト指向開発プロセス

経営

ＩＴ


業務プロセステンプレートを参考に、現状プロセスを整理する

個別プロセス記述書

業務プロセスフローチャート

業務記述書

現状のレベル４業務プロセス

レベル３単位

レベル４

人間系だけのプロセス

情報システムを利用するプロセス

情報システムが２系統

人間系プロセスは、部・グループ・個人でバラバラ

パッケージ

業務プロセスの標準化例

■ 人間系を含めた全体の生産性は向上しない（整流化されていないので）情報システムへ例外処理要求が多く出てくる

■ プロセスが標準化されていないので、JSOX対応では９種類以上の文書化、９×２５個の運用評価が必要（毎年）

事例330-01

経営

ＩＴ


構想検討

システム構築（ERPパッケージの導入）本稼動運用この部分で標準モデルを

使用して新業務プロセス設計、業務ルールの整理を実施した（約６ヶ月）

ERP要件定義ソリューション

設計構築テスト

業務プロセス設計（生産・購買・販売、会計）業務プロセス標準化と業務ルールの整理

ERPへの要求定義

システムニーズの確認・企画構築・運用戦略策定プロジェクト体制の確立

稼動導入・実行フェーズ計画フェーズ

実施計画

RFP作成、ERP選定予算案の策定と承認

構想・検討フェーズの効果①ベンダーからの提案見積の

精度が高い各ERPベンダー提案金額の差は5%以下

②ベンダー決定後のFit&Gapコンサル工数が従来の2/3

③導入金額の見直し発生せず

②

③

①

事例

売上700億円の中堅企業

現在

機械工具メーカーにおける業務プロセス標準化、RFP作成とERP選定

経営

ＩＴ


現状分析に関するＳＥ研修例

□ １チームは６人、チーム内の分担①機械部品製造業の営業部門ユーザ(２人）営業経験か引合・見積システム経験ある人。②開発側（システム部かベンダー）(４人) 引合・見積システム経験がない。

現状分析インタビュー担当（２人）、記録担当（２人）

□ 演習の進め方・分析インタビュー担当は質問することによって現状分析セッションをリードする。（要求アナリスト）・ユーザ側は、開発側から質問を受けたことしか答えない。

即答できないことは、部内の他メンバから聞いて、必ず回答すると答える。・開発側は、ユーザ側より回答された事について、What(業務で何をしなければならないか）を記録

する。How(システムでどうしている、どうしたい）は、現状分析が完了するまで無視する。

□ 現状分析の手順・開発側インタビュー担当は、業務プロセステンプレートをもとに引合・見積業務について、ユーザ側

にインタビュー（質問）する。質問項目は、プロセス機能、インプット、アウトプット、業務ルールなど。・ユーザ側が回答する。・回答した内容を記録担当が青字、回答保留は赤字で記録。

制限時間内で高成績チームにおいて、インタビュー担当はSE経験が全くない広報担当の女性。本人曰く「インタビューには慣れてますから」。

インタビューでは、ユーザは回答せざるを得ない。ヒアリングではダメ。

事例

未経験の業務について、ＳＥは如何にユーザから現状に関する情報を引き出すか（カリフォルニア州立工科大学の鎌倉セミナーで研修を担当）

310-02

経営

ＩＴ


レベル5As-Is概要プロセス

「サプライチェーン改革とIT構築の統合」（プロセス改革実施、IT導入）

下位プロセスを設計・構築し、ITを同時に開発・導入する

To-Beレベル4概要プロセス

IT詳細計画ＲＦＰ(IT要求)提案書


リファレンス

特長

当社独自

業務ルール内容と一覧

サンプル

レベル５分解技法

下流方法論

ERP導入方法論

特長

当社独自

当社独自

業務ルール業務運用ﾏﾆｭｱﾙ

To-Beレベル5詳細プロセス

新しい情報システム

Input/Outpuｔ、業務ルール整備

新業務プロセス運用のための準備

IRMの観点(情報システム、データ、ユーザ)

ＳＣＭ戦略を業務プロセスに実装する

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

（標準WBS)



プロセスモデルの階層に沿って設計・構築→要求の

変更管理



レベル５プロセス設計

業務運用設計

RCMリスクコントロールマトリクス

レベル５へ分解

提案書をもとにIT詳細計画を修正

IT分析・設計

レベル５要求定義

業務運用準備 IT開発・導入

業務とIT運用テスト

業務移行 IRMの移行ERP導入個別開発

＊

経営

ＩＴ


ＥＲＰ/IT導入における成果物作成と役割分担

業務プロセス設計 ERP/IT開発・実装移行

業務プロセス

1.業務プロセス詳細設計・業務プロセスフロー・業務要求定義（ユーザ要求）・ＥＲＰ機能要件

（組織、アドオン要件他）

ERPｼｽﾃﾑ 2.システム設計書3.システム詳細設計書

・プログラム仕様書

・テーブル設計書

I/F関連ｼｽﾃﾑ

4.インタフェース設計書・インタフェース定義書・Ｉ／Ｆ外部仕様書

マスタ移行

5.移行設計書・項目マッピング・移行手順・マスタ・データ移行設計書

ユーザ教育

6.ユーザ教育設計・教育コース、運営体制・教育マテリアル設計

10.統合テスト・テスト計画・テスト仕様・ユーザ検収8.関連システム変更設計

・レガシー、分散システム

2.ERP開発・パラメータ設定・アドオン開発

3.IT開発・プログラム開発

4.インタフェース開発・Ｉ／Ｆ内部仕様書・Ｉ／Ｆプログラム

5.マスタ･データ移行システム開発・プログラム仕様・プログラム開発

8.関連システム変更・レガシー、分散システム

7.サーバ環境・開発環境

7.サーバ環境・テスト環境

7.サーバ環境・本稼動環境

11.システムテスト

・パフォーマンス・技術項目

5.マスタ・データ移行

・パイロット移行・クリーニング、追加入力

5.マスタ・データ移行

・本稼動前移行・本稼動直前移行

システム運用・権限設定・障害／バックアップ

本稼動運用準備・ヘルプデスク・保守・変更管理他

結合テストまで完了

1.業務運用設計・業務運用フロー・権限決定・マスタ運用規定

12.運用テスト

1.業務移行・社内各部門・外部業者

6.ユーザ教育準備・教育マテリアル作成・教育運営体制構築

業務チーム

開発チ｜ム

ベンダ｜

本稼動計画

6.ユーザ教育実施・層別教育実施、開発チームへのＦＢ・教育マテリアル変更

＊

経営

ＩＴ


要求定義レビューの手順

レビュー前要求定義書


業務課題取りまとめ

業務課題整理表

業務フロー

レビュー１

レビュー２

レビュー２後要求定義書

記述内容を要求定義書の要素へ転記しながら、レビュー（5W2H追記)

要求定義書の要素を確認しながら、（業務ルール名他）①フロー確認（通常、代替、例外）②トランザクションについて、FPごとの機能確認

レビュー３

疑問点は赤色

業務モデル業務ルールSCOR他

レビュー５後要求定義書

レビュー５

業務要求や業務課題を反映

①業務モデル→要求を補足（業務ルール、非機能要求、追加的要求）

②JSOXチェックリスト→コントロールを補足③ベストプラクティス→機能要求を見直し

共同レビュー４

共同レビュー６

レビュー完了要求定義書

コメント付き業務フロー


Excel

ベストプラクティス（プロセス、IT)

ビジネス要求

ユーザ要求

構想企画ﾌｪｰｽﾞ

事例

モデル類をリファレンスするメリット・個人でいくら経験・知識が有っても

-指摘し忘れる-すぐに経験・知識が出てこない-所詮、個人で習得できた範囲の中

・そもそも、若年は経験・知識が乏しい

非公開

経営

ＩＴ


要求定義レビューの成果物事例

非公開メリット・曖昧な表現の排除・不完全な不足している要求を補足・記述されていない要求の指摘（現状維持）・業務要求とユーザ要求の矛盾の指摘・ベストプラクティスなどの機能の提案・非機能要求の指摘・パワーユーザからの金メッキ要求の指摘・関連する業務ルール、要求の抽出

さらに可能なこと（レビュー後の取り組みで）・要求のテスト（テストケース、受入適合基準）・要求の優先順位・要求からの規模見積もり

経営

ＩＴ


「ビジネスプロセス参照モデルを利用したサプライチェーン改革と情報システム構築の統合」電子情報通信学会、信学技報Vol.105 No.519, 2006

「ビジネスプロセス参照モデルを利用したサプライチェーン改革と情報システム構築の統合（詳細計画フェーズ）」電子情報通信学会、信学技報Vol.106 No.85, 2006

「日本版SOX法対応へのリスクの階層型トップダウンアプローチとアセスメント手法」電子情報通信学会、信学技報Vol.106 No.218, 2006

「入手可能なビジネスプロセス参照モデルの紹介および利用による効用論文」電子情報通信学会、信学技報Vol.107 No.128 , 2007

「事業戦略の構造化によるサプライチェーンや情報システムなどのビジネスプロセス改革構想の立案」電子情報通信学会、信学技報Vol.XXX

「経営的効果を上げるための５フェーズERP導入方法論」経営システム学会、200712

電子情報通信学会の論文をご希望の方は上記にメール下さい。PDFをお送りします。

（株）マネジメント＆ＥＲＰ http://www.merpi.com渡邉和宣 [email protected]

ご清聴ありがとうございました。

scm改革とit/erp導入の統合 への4フェーズ方法論...

Documents

scm改革とit/erp導入の統合への4フェーズ方法論...