[G-Tech2015]攻めのIT経営銘柄に選ばれたアサヒグループホールディングス様の基幹刷新への取り組み～MCFrameによる基幹システム刷新事例　Fittingアプローチとは？～ - 株式会社インテック[講演

Copyright © 2015 INTEC Inc. All rights reserved.
2015年10月16日
〜 MCFrameによる基幹業務刷新事例〜
インテックのFittingアプローチとは？
攻めのIT経営銘柄に選ばれた
アサヒグループホールディングス様の
基幹業務刷新への取り組み
SI事業本部 MCFソリューション部
シニアコンサルタント中村浩司
Copyright © 2015 INTEC Inc. All rights reserved. 2
講演者プロフィール
複数プロジェクトの上流⼯程に参画。
(システム化構想〜要件定義)
業務標準化の視点でMCFrame標準導入推進
に携わる。5年前〜現在。主に製造業を担当。
所属：株式会社インテック
氏名：中村浩司(53歳)
経験：30年
現
在
専門：プロジェクトマネジメント
システムグランドデザイン
資格：PMP
ホスト系10年、オープン系1５年のスクラッチ開発
及びERPパッケージ導入を5年経験。
29歳よりプロジェクトマネージャとして大小30の
プロジェクトを経験。PMとして最大の経験は
5年間で30億円の液晶⼯場⽣産管理プロジェクト。
近年は、⼤規模プロジェクトのマネジメント⽀援を
⾏うと共に、基幹システムの企画・構想に参画し、
システムグランドデザインの⽴案に携わる。
個別プロジェクトPMO
システムコンサルタント
MCFrame導入
標準化コンサルタント
システムコンサルタントシステムコンサルタント
プロジェクトマネージャプロジェクトマネージャ
システムエンジニアシステムエンジニア

はじめに
本セミナーの目的：
アサヒグループホールディングス様の基幹業務刷新事例を通して、
基幹業務パッケージの標準導入に必要な考え方をお伝えし、
皆さんの企業における基幹システム再構築の参考にして頂く。
高品質・低コスト・短期間での導入
どのように実現するか、そのためには何が必要かをお伝えする。
特にパッケージの標準導入に必要な要素に焦点を当てる。
導入ポリシーと具体的な導入手法
インテックのFittingアプローチのメリットをお伝えし、
導入プロジェクト、特に要件定義の勘所に焦点を当てる。
目次
１．アサヒグループ様事例
（1）背景と目的
（2）プロジェクト概要
（3）導入効果
（4）グループ標準化
（5）Fittingアプローチ
（6）成功要因まとめ
２．プロジェクト人財育成への取り組み
（1）プロジェクトに必要な人財
（2）職種定義
（3）育成の流れ
（4）要員スキルの現状把握
（5）育成パス
（6）育成メニュー

１．アサヒグループ様
事例
１．アサヒグループ様
事例
（１）背景と目的
【お客様概要】
■社名
アサヒグループホールディングス株式会社様
■導入対象グループ会社(予定を含む)
ニッカウヰスキー株式会社様
天野実業株式会社様
和光堂株式会社様
アサヒフードアンドヘルスケア株式会社様
株式会社エルビー様
■プロジェクト企画・実施主管
アサヒプロマネジメント株式会社様
アサヒビジネスソリューションズ株式会社様
吾妻橋本社
2014年売上⾼（セグメント別）2014年売上⾼（セグメント別）
酒類事業
５2.8％
飲料事業
２６.4％
食品事業
６.２％
国際事業
１3.1％
連結売上高
17,855億円
その他
１.6％

■目的
グループ会社の基幹系システム統合・集約による、ITコスト削減。
■施策
基幹システム再構築＝業務改革であるという考えの基、人的生産性の向上を図る。
グループ会社の業務を根本的に⾒直し、パッケージを原則標準導入する。
これを推進する手法として、インテックのFittingアプローチを採用する。
グループ会社のインフラ基盤を統合し、システム運用コストを削減する。
グループ会社のデータ活用基盤(DWH/BI)を統合し、個社の投資を抑制する。
個社プロジェクトを始める前に、グループ共通機能を検討すると共に、
プロジェクトの進め方を標準化し、個社のプロジェクトコストを抑える。
パッケージ導入ノウハウを、グループ展開を通してアサヒグループ様へ徐々に移管し、
ベンダーの支援コストを段階的に減らす事でトータルのIT投資を抑える。
【基本方針】
生産
調達
原価
販売
物流
財務
会計
ｱｻﾋﾋﾞｰﾙ
ﾆｯｶｳｲｽｷｰ
ｱｻﾋ飲料
ｶﾙﾋﾟｽ
ｱｻﾋﾌｰﾄﾞ&
ﾍﾙｽｹｱ
和光堂
天野実業
ｴﾙﾋﾞｰ
ｱｻﾋｶﾙﾋﾟｽ
ﾋﾞﾊﾞﾚｯｼﾞ
国
内
自社
PKG 自社
自社
ＳＡＰ
自社
ＳＡＰ
PKG
PKG
ＳＡＰ
SS
ＳＡＰ
PKG 自社
SS
PKG
自社 SAP
自社
生産
調達
原価
販売
物流
財務
会計
国
内
自社 PKG
自社
ＳＡＰ
PKG
(MCFrame)
自社
〜２０１２年〜２０１２年２０１5年〜２０１5年〜
■基幹システム構成(Before/After)。⻩緑⻩緑 MCFrame
ｱｻﾋﾋﾞｰﾙ
ﾆｯｶｳｲｽｷｰ
ｱｻﾋ飲料
ｶﾙﾋﾟｽ
ﾍﾙｽｹｱ
和光堂
天野実業
ｴﾙﾋﾞｰ
ｱｻﾋｶﾙﾋﾟｽ
ﾋﾞﾊﾞﾚｯｼﾞ
各社バラバラに構築・運用されて来た基幹システムを、グループ方針として
共通パッケージへの置き換えを図る。
Before After

■プロジェクトの目的、施策、期待効果
Q
品質
確保
C
投資
圧縮
D
期間
短縮
導入体制の
極小化
導入体制の
極小化
開発スコープの
極小化
開発スコープの
極小化
要件ブレの
極小化
要件ブレの
極小化
目的施策
■要件定義でマスタを最大限整備し、
実機による業務検証を前倒しで⾏う。
■ユーザがすべきタスクは自身でやる。
強⼒な推進機能(事務局)を設ける。
・現状調査、マスタ整備
・パッケージ業務検証
・新業務プロセス設計
・業務マニュアル作成
・エンドユーザ教育、運用テスト
●期待効果
マスタ精度の早期向上
パッケージ習熟度の早期向上
業務実効性の早期検証
教育、運用テスト期間の短縮
導入ベンダーの支援工数削減
タスク方針と期待効果
プロジェクト
MCFrame適用範囲年度
販売物流⽣産管理原価管理 2012 2013 2014 2015 2016
標準化指針/グループ標準機能/標準WBS等
ﾆｯｶｳｲｽｷｰ ● －－
天野実業 ● ● ●
和光堂 ● ● ●
ﾍﾙｽｹｱ
● ○(既存) 未定
ｴﾙﾋﾞｰ ○(既存) 未定未定
検討中
検討中
■グループ展開プロジェクトのマイルストーンを示す。
最初に３ヶ月間の標準化タスクを実施し、以下の検討を⾏った。
・グループ標準化指針策定
・グループ共通機能(暫定版)
・プロジェクト標準タスクの詳細定義(成果物/役割分担/進め方)
現在、3社が本稼働済み。プロジェクトのQCDは予定通り確保されている。
個社プロジェクトからのフィードバックを反映

■標準化タスクの概要
導入システムの
標準化指針策定
導入プロセスの
標準化指針策定
標準化
タスクの
⽴上げ
標準化
タスクの
⽴上げ
導入対象
企業との
合意
導入対象
企業との
合意
個社
プロジェクト
への適用
（標準化ﾀｽｸの
活動継続）
個社
プロジェクト
への適用
（標準化ﾀｽｸの
活動継続）
・全体推進PM擁⽴
・推進役ｺﾝｻﾙ参画
・ﾌﾟﾛｼﾞｪｸﾄﾒﾝﾊﾞｰ選定
・導入対象会社の
ｷｰﾊﾟｰｿﾝ選定
・ｸﾞﾙｰﾌﾟ展開計画聴取
・ｺﾞｰﾙ設定
・ｽｹｼﾞｭｰﾙ策定
・役割分担
・ｸﾞﾙｰﾌﾟｶﾞﾊﾞﾅﾝｽの
発動(周知)
・ﾊﾟｯｹｰｼﾞ標準機能の取捨選択
・ﾏｽﾀｺｰﾄﾞの共通化検討
・ｲﾝﾌﾗ基盤の共通化(集約化)検討
・内部統制要件等、
ｸﾞﾙｰﾌﾟ共通非機能要件の定義
・ｱﾄﾞｵﾝ帳票等、
ｸﾞﾙｰﾌﾟ共通利⽤が考えられる
不⾜機能の定義
・ｸﾞﾙｰﾌﾟKPIの定義
・標準WBS(作業＋成果物)の定義
・各種成果物の標準定義
・ﾌﾟﾛｼﾞｪｸﾄﾏﾈｼﾞﾒﾝﾄのｽｷｰﾑ定義
・関連会社への
説明会
・方針合意
・ﾌﾟﾛｼﾞｪｸﾄ体制
検討
・ﾌﾟﾛｼﾞｪｸﾄ⽴上げへ参画
・標準化ﾄﾞｷｭﾒﾝﾄの提供
・標準化ﾀｽｸへの
ﾌｨｰﾄﾞﾊﾞｯｸ(ﾌﾟﾛｾｽ改善)
・個別要件の把握と横展開
・ﾗｲｾﾝｻ(BENG社)への
機能強化の働きかけ
(標準への組み込み等)
タスクへのインプット情報：
・グループ会社への導入プラン(グランドデザイン)
・導入対象各社の要件
３ヶ月間
導入済みプロジェクトにおける、MCFrame標準機能の適合率は下記の通り。
アドオン・カスタマイズ機能数には、アサヒグループ標準機能を含んでいる。
相対的には販売物流のアドオン・カスタマイズ⽐率がやや⾼めではあるが、
多くは受注EDIや専用伝票などの対外サービス維持機能が占めている。
実施済
プロジェクト
MCFrame
適用モジュール
対象業務における
標準機能数
アドオン・カスタマイズ
機能数
(周辺I/Fを除く)
MCFrame
標準適合率
ニッカウヰスキー販売物流 122 20 84%
天野実業
販売物流 166 23 86%
⽣産管理 128 16 88%
原価管理 130 4 97%
和光堂
販売物流 173 34 80%
⽣産管理 128 3 98%
原価管理 130 0 100%

統括
推進責任者
事務局
プロジェクト
メンバー
推進責任者
事務局
プロジェクト
メンバー
推進責任者
事務局
プロジェクト
メンバー
推進責任者
事務局
プロジェクト
メンバー
インフラ基盤・
周辺開発
企画・
マネジメント
個社プロジェクト
インテックメンバーインテックメンバーインテックメンバーインテックメンバーインテックメンバーインテックメンバーインテックメンバーインテックメンバー
【推進体制】
グループ全体のIT化をホールディングス様がコントロール(企画・実施計画・インフラ構築)。
個社プロジェクトはアサヒプロマネジメント様・アサヒビジネスソリューションズ様・インテックの
混成チームとし、パッケージ導⼊ノウハウを徐々に引き継ぎ、インテックの参画度を減らす。
・・・
経営層経営層経営層経営層
プロジェクトオーナー
ステアリングコミッティ
プロジェクトマネージャ
プロジェクトリーダ
アサヒビジネスソリューションズ様アサヒプロマネジメント様
アサヒグループホールディングス様
（3）導入効果
■グループ全体のシステム導入効果は以下の通り。
導入期間１プロジェクト平均15ヶ月⇒10ヶ月に短縮。
IT投資開発・運⽤コストを含めた、５年間のトータル
コストが３０％低減の⾒込み。
■個社効果の事例
天野実業様においては、導⼊から半年後の中間決算にて、期末在庫⾼が前年⽐20%
削減となった。これはMCFrame導⼊を機に、基幹業務をゼロベースで全⾯的に⾒直し、
特に販売部門と生産部門との組織的な需給調整機能を改善した結果である。
具体的施策例）
①需給調整部門を新設し、在庫責任を明確にした。
②販売計画の変更を⽣産計画へ反映させるサイクルを⽉次から２週に⼀度と早めた。
これにより精度の⾼い⽣産調整を可能とした。
③生産計画を製品・半製品・原材料それぞれで⽴てていたため在庫がダブついていたが、
製品から原材料までを⼀気通貫でMRP処理する事で、在庫削減に寄与した。

（3）導入効果
導入期間の短縮と
標準導入の推進
導入期間の短縮と
標準導入の推進
アサヒグループ
標準機能の整備
標準機能の整備
インフラ環境の
仮想化・共通化
インフラ環境の
仮想化・共通化
システム維持運用
体制の集約化
システム維持運用
体制の集約化
プロジェクトキックオフからリリースまで、1社あたり当初
計画から平均５か月短縮。またFittingアプローチによる
業務標準化促進により、間接業務コストを削減。
プロジェクトキックオフからリリースまで、1社あたり当初
計画から平均５か月短縮。またFittingアプローチによる
業務標準化促進により、間接業務コストを削減。
各社システムに対して、それぞれアドオン・カスタマイズされて
いた機能を一本化し、グループ各社で共有する事で、
開発費を削減。
各社システムに対して、それぞれアドオン・カスタマイズされて
いた機能を一本化し、グループ各社で共有する事で、
開発費を削減。
グループのプライベートクラウド環境で、安価かつ汎用性の
ある共通化されたインフラ基盤を構築・運用。
⽉額利⽤料制とする事で、利⽤各社の初期投資を軽減。
グループのプライベートクラウド環境で、安価かつ汎用性の
ある共通化されたインフラ基盤を構築・運用。
⽉額利⽤料制とする事で、利⽤各社の初期投資を軽減。
各社システムあるいは各業務領域ごとに縦割りで存在して
いた運用保守担当者を集約。少人数でサービスレベルを
落とさず運⽤できる体制を構築し、運用保守工数を削減。
各社システムあるいは各業務領域ごとに縦割りで存在して
いた運用保守担当者を集約。少人数でサービスレベルを
落とさず運⽤できる体制を構築し、運用保守工数を削減。
基幹システムの集約化とFittingアプローチにより、様々な観点でのコスト削減を実現。
施策と効果について示す。
■個社展開を⾏う前に、グループ全体の「標準化指針(導入ポリシー)の策定」を⾏った。
これにより、個社の導入プロジェクトにおける「機能開発」と「作業タスク」の重複を排除し、
グループ全体の導入コストを削減した。
標準化指針の対象項目を示す。システム標準化とプロセス標準化の２つの観点による。
【システム標準化】
グループ共通マスタコード体系
グループ共通マスタデータ
グループ共通業務機能
グループ共通インフラ基盤
標準ツール(データ加工/帳票作成/システム運用等)
【プロセス標準化】
プロジェクト全体タスク
プロジェクト成果物
要件定義(Fitting)プロセス
導入プロセス(性能/移⾏/教育/テスト方針)
マネジメントプロセス

■標準化指針策定の流れ
標準化指針
インテック保有の
MCFrame
標準化指針
インテック保有の
MCFrame
標準化指針
導入プロジェクトへ
適用し要件定義実施
標準プロセス定義
標準化指針のテーラリング手順
①システム／プロセスの視点で
自社の標準化対象項目を定義
②グループ共通機能と個社機能の切り分け
③グループ共通インフラ基盤の検討
④アサヒグループ標準化指針の策定
⑤グループ会社への展開
展開計画の共有／標準化指針の啓蒙
個社プロジェクトへの周知・ガバナンス活動
⑥グループ会社からのフィードバック
標準化指針のブラッシュアップ
標準成果物定義
標準タスクマップ
テーラリング周知
■システム標準化(例)
最初に共通要件を仮置きし、アサヒグループ標準機能を暫定的に定義した。
次に最初の２プロジェクトにおいて共通要件となる機能を実装対象とした。
原則として、グループ内の２社以上で利⽤する機能をグループ共通機能とし、
３社目以降のプロジェクトにおいても同様のポリシーで順次実装した。
■アサヒグループ標準業務機能テンプレート（候補）■アサヒグループ標準業務機能テンプレート（候補）■アサヒグループ標準業務機能テンプレート（候補）■アサヒグループ標準業務機能テンプレート（候補）
N
LB AF
H
WK
D
NK AM
N
CA
L
利用用途（背景）
※利用用途及び利用シーン
を記載
外部（社外）への影響
作業ボリューム
（入力件数等）
業務ルール・プロセス
変更を伴う。
※運用回避が可否
効果（定性、定量）
※効果を記載
3 ○ ○ ○ ○ ○ 共通販売受注受注チェックリスト受注チェックリスト　→出力項目は○○、△△、××が中心。プルーフリストと
して使用。
5 ○ ○ ○ × 共通販売受注受注一覧照会
・検索条件を追加する。
　「納品日≠希望納期」検索
　「３ロット（賞味期限）以上引当オーダー」検索
　受注登録者
・表示項目追加　受注登録者
・端数項目を追加する。
・明細エリアに、容積、重量、入数を追加する。
・一覧をEXCEL出力して受注チェックリストとして使用する。
14 ○ ○ ○ ○ ○ 共通販売受注 EOS取込進捗状況照会・EOS取込状況を確認できる新規画面を作成する。
・店別明細表を発行する。
16 ○ ○ ○ ○ ○ 共通販売受注 EOS再取込・EOS取込エラーデータを更新できる新規画面を作成する。
18 ○ ○ ○ ○ ○ 共通販売受注 EOS受注取り込み EOS受注データを取り込む。
19 ○ ○ ○ ○ ○ 共通販売受注 EOS得意先コード変換マス
タ登録
20 ○ ○ ○ ○ ○ 共通販売受注 EOS品目コード変換マスタ
登録
業務No.
選定候補
実装
PRJ
対象
ﾓｼﾞｭｰﾙ
関連
No.
名称
機能要件
（一部現行機能要件を記載）
業務影響
Asahi標準機能として実装予定 b-eng要望個社対応
要検討機能／確認事項あり Asahi標準機能として実装しない
廃番、削除
実装なし⇒個社になったもの
★共通機能として採用するかどうかの判断要素
・２社以上で利⽤
・対象機能を利⽤する業務プロセス・業務ルールが
個社特有のものではない事
・システム機能を実装する事で、
業務コスト削減効果がある事
・業務運用での回避が困難な事

■実装の考え方
MCFrame標準の確⽴された機能・性能を損ねる事無くアドオン・カスタマイズを
⾏うための、実装の考え⽅を⽰す。
開発手法
MCFrameXAに関しては、「EI開発」と「EIクラス開発」の2つの開発手法があるが、
実装モジュールを階層管理し、他社展開をし易くするために、今回は「EI開発」を採用した。
EI開発イメージ
同一グループの複数企業にMCFrameを導入する場合、グループ共通機能をレイヤを分けて
管理する事で共通部分と個社部分の開発を並⾏して⾏える、実装箇所が明確になるなどの
メリットがある。
アサヒグループ様への適用事例
個社レイヤ
標準レイヤ
消費財テンプレートレイヤ
MCFrame
標準レイヤ
機能A’
機能A
機能B
機能B’ 機能C’
機能C
MC標準をアサヒ標準として
カスタマイズする場合
消費財テンプレートを個社機能として
アサヒ標準を個社機能として
個社要件はこのレイヤで実装
グループ共通要件は
このレイヤで実装
アプリ
レイヤを
４つに
分けて
管理
インテックが元々実装している
拡張機能レイヤ
標準レイヤには手を加えない
④
プロジェクト
推進体制
②
導入アプローチ
(⽅法論)
①
適切な
業務
パッケージ
選定
③
トップ
ダウン
方針
標準導入
による
業務標準化
インテックの
Fittingアプローチ！
インテックの
Fittingアプローチ！
強⼒な事務局機能！強⼒な事務局機能！
付加価値を付けた
MCFrame！
付加価値を付けた
MCFrame！
パッケージ標準導入に必要な４大要素の１つが、
Fittingアプローチである。
業務改革方針の徹底！業務改革方針の徹底！

①適切な業務パッケージ選定
グループ各社の基幹業務刷新にあたり、製造業向けに開発された国産パッケージである
MCFrameXAを採用した。
日本のものづくりのノウハウや豊富な経験である
「現場の知」をシステム化した国産パッケージ
現場カイゼンに追従できる柔軟性と拡張性
基幹業務を継続的に支えることができる
導⼊バージョンの永年保守
豊富な周辺システムとの連携インターフェース
ユーザ個人の操作性、使いやすさを実現
開発元：東洋ビジネスエンジニアリング（B-EN-G）
東洋エンジニアリング(TEC)社 IT事業部が独⽴
1991年：⽇本初のSAPパートナー
1993年：国内初SAP導入
SAP Awardを12回受賞
1996年：MCFrame販売開始
インテック、パートナー契約MCFrame
SAP
MCFrameXA 適用業務範囲
原価管理
販売物流経営管理
⽣産管理
MCFrameの導入実績
433社（1996年4⽉〜2014年12月）
プロセス系：180社
組⽴加⼯系：233社
流通・サービス： 20社
iPad
iPhone
BI
MCFrameとは
Manufacturing and Communication Framework
生産・販売・原価統合フレームワーク
内、80社以上を
インテックが導入
会計
Enterpri
se
Imagin
g
Platfor
m
需要予測 EDI スケジューラ MES・POP PDM・PLM 帳票管理 BI
輸出入
⽣産管理販売管理
外注管理
生産計画
製造管理
購買管理
品質管理
需給管理
受注・出荷管理
在庫管理
発注・⼊荷管理
原価管理
標準原価
予算原価
実績原価
実際原価
ツール
帳票発⾏
バーコード⼊⼒
共通機能
自動仕訳
開発環境
FrameManager
履歴管理
権限管理
原価差異分析
在庫管理
債権管理
利益分析
マスタ管理
導入支援
販売計画
債務管理
レポート
債務管理
経営管理
連結データ変換
連結実際原価
連結利益分析
レポート
iPad/iPhone BI
多機能
他システム
連係実績が
多い
パッケージ選定においては、複数社のパッケージソフトでコンペが⾏われた。
中でもMCFrameは、販売管理、⽣産管理、原価管理の領域において、非常に多くの
標準機能が実装されており、また、他システムとの連係実績が多い点も高評価となった。

標準
機能
拡張
・
性能
向上
インテック版消費財向けテンプレート機能
標準機能改善
及び
機能強化要望対応
資料化要望対応
MCFrameXA
【販売物流】
【⽣産管理】
【原価管理】
標準機能
標準機能改善・性能改善・品質向上
インテックが開発した過去のアドオン・カスタマイズ資産の内、
消費財の販売物流業務において、⼀般要件に近いものを
汎用化し実装したもの。
インテックでは、ライセンサへの働きかけを
継続的に⾏っている。
①提供パッチ以外の標準機能改善要求
②一般要件と考えられる機能の実装要望
③性能改善要望
④標準マニュアル類の充実要望
パッケージ製品の付加価値を向上させ、システム品質強化・導入コスト削減に寄与するため、
MCFrameの№１ベンダーであるインテックならではの製品強化アプローチを実践している。
またMCFrameをより良い製品に成⻑させるため、ライセンサとの強いコネクションを維持し、
協業を推進している。
インテック独自の
拡張性・機動性を持たせた
MCFrameの実現！
インテックの保有する、消費財製造業向けテンプレート
帳合管理
輸出管理
業際統一伝票
引当管理
簡易受注
一括引当
受注管理
バッチ管理
マスタ管理
リベート
MCFrameXA販売物流標準機能
消費財製造業向けテンプレート
個別対応(例)
卸
GMS
EOS
業界VAN接続
物流費
直販・通販
EOSフィー
単価計算
重量・容積
添付(景品)
企業間連係
履歴管理
需給調整
与信管理
台貫出荷
無償受注
注文
出荷管理
預け預かり出荷
出荷返品
ＦＢ連係個別対応(例)
テンプレート実装
MCFrameXA標準実装
消費財製造業機能要件
債権管理
製造⽇管理
実績照会複数回請求締
業界
VAN
発注管理
債務管理
生産連係
ロット逆転禁止
配送ルート
在庫管理
輸⼊管理
賞味期限荷姿管理
予約引当禁止
出荷伝票
請求明細書
伝票発⾏
WMS連係
MCFrameXA 販売物流

②導入アプローチ
業務標準化を促進する、基幹業務パッケージ導入アプローチ
高品質
低コスト
短期間
による基幹システム刷新の実現に必要不可⽋なアプローチ
★単なる「導入」ではなく、「業務刷新」を伴うもの！
Fittingとは・・・
新業務プロセス構築を目的として、パッケージ標準機能を最大限に活用し、
業務標準化とコスト極小化を同時に実現する標準導入アプローチ。
パッケージの一般的な「Fit&Gap」と異なり、Fittingでは検討ベースをパッケージ標準業務
とする事が特徴であり、従来手法のAs-IsとTo-Beを逆転させた考え方である。
標準機能の活⽤を⾒逃す事の無いよう、業務⼿順やルールをユーザと一緒に考え検証する
アプローチであり、業務標準化を進めるに際して有効な⽅法論である。
現⾏業務
＆システム
As-Is To-Be
Gapについての
⼤部分は現⾏業務
に合わせてアドオン・
カスタマイズとなって
しまう
Fit＆Gapイメージ
パッケージ
標準機能
Gap
Fittingアプローチ＝業務標準化アプローチ
Fittingイメージ
To-Be
使い方の工夫や
業務運⽤の変更で
パッケージ標準機能を
最大限に活用、
投資すべき対象の
業務優先度を検討
パッケージ
標準業務
＆
標準機能
標準化
された
業務
Gapに対する
システム化ではなく、
業務目線での
アプローチにより、
業務標準化
導入コスト低減
を同時に実現！
独自業務
機能Gap=業務Gapと捉える機能Gap=業務Gapと捉える

■Fittingのメリット
パッケージの
早期習熟
パッケージの
早期習熟
システム品質の
早期確保
システム品質の
早期確保
ユーザ負荷の
平準化
ユーザ負荷の
平準化
システム投資の
最小化
システム投資の
最小化
■要件定義段階で、以下を⾏う。
・お客様の実データを最大限パッケージへ仕込む。
・検討セッションで実機を動かしながら業務検証する。
・キーユーザ自身にパッケージの実機環境に触れて頂く。
■これにより、様々な効果がある。
・早い段階でユーザのパッケージ習熟度が上がる。
・エンドユーザへの教育をキーユーザ自身で実施する事が
できるようになる。
・パッケージを動かしながら不⾜要件を検討するため、
追加機能の仕様に関する齟齬が発生しない。
・プロジェクト後半や運用開始直前の負荷が減り、
プロジェクト期間を通して作業負荷が平準化される。
・パッケージ標準機能の活⽤を⾒逃す事無く、本当に
必要なシステム要件を抽出でき、システム投資を
最小化できる。
・全体的に、プロジェクトリスクが前倒しできる。
■パッケージ導入プロセスの全体像
システム
全体設計
パッケージ
適合性検証
新業務プロセス構築
各種
方針検討
要件定義
システム
実装
業務運用詳細化
マスタ整備
各種方針詳細化
(性能/移⾏/教育/保守運用)
導入
システム
運用テスト
エンドユーザ教育
業務運用テスト
投資
判断
▼
インテックはここに
Fittingアプローチを適用
インテックはここに
Fittingアプローチを適用

■要件定義フェーズのタスクモデル
要件定義フェーズの主要タスクとFittingの位置づけを示す(6ヶ⽉間の例)。
タスクカテゴリ 1ヶ月 2ヶ月 3ヶ月 4ヶ月 5ヶ月 6ヶ月
マイルストーン
▲
キックオフ
▲
中間ｽﾃｺﾐ
▲
ウォークスルー
▲
最終ｽﾃｺﾐ
事務局タスク
(共同)
業務部門
主体タスク
システム部門
主体タスクマスタ移⾏
(暫定)
業務/システム棚卸
業務課題抽出
Fitting
計画
プロジェクト方針検討
(実装可否/性能/移⾏/教育/運用テスト等)プロジェクト
全体計画
MCFrame概要理解
MCFrame
環境構築
⾒積精査
リアルタイムマネジメント、週次課題棚卸/進捗チェック、月次進捗報告
MCFrame Fitting
(課題検討、システム対応案検討)
MCFrame Fitting支援
(課題検討、システム対応案検討)
次フェーズ
計画
MCFrame Fitting(新業務構築)
業務課題検討
新業務フロー検討
システム要件検討
業務分析/
ヒアリング
システム
要件精査
⾒積
要件定義書
まとめ
合同セッション合同セッション
システム全体設計
機能概要設計/インフラ設計
プロセス
概要
実データを使ってパッケージを
動かす準備を⾏う。
現⾏業務とシステムを理解する。
またFitting体制を確⽴する。
業務単位にFittingセッションを
実施。課題表にて業務運用対
応案とシステム対応案を整理す
る。
Fitting実施結果について
業務間の整合性を検証し、
新業務運用全体が回るかを
判断する。
お客様の役割
・現⾏マスタデータ提供
・項目マッピングQA対応
・サーバ、端末準備
・現⾏業務、システム整理
・必要情報提供
・パッケージのマスタ理解
・実機検証、パターン出し
・業務課題検討
・業務ルール/フロー整理
・各部門との調整、合意
・新業務の整合性検証
・業務変更点の合意
・システム投資判断
・新システムの構成決定
インテックの役割
・業務理解
・マスタ項目マッピング
・マスタデータ整備(暫定)
・MCFrame環境構築
・Fittingセッション計画
・Fittingセッションのリード
・MCFrame機能説明
・実機検証支援
・マスタデータ整備
・システム対応案の検討
・ウォークスルーシナリオ案作成
・システム対応案の⾒積
・次フェーズ計画、⾒積
①
Fitting準備
②
Fitting実施
③
Fitting評価
■Fittingの概要
Fittingにおいては、事前に現⾏システムマスタデータを受領し、インテックにて暫定マスタの整備を⾏う。
これにより、MCFrameの実機環境にて実業務をイメージしたFittingを⾏う事を可能とする。

現⾏業務
プロセス一覧
①新業務検討ベース(Fittingシナリオ)の準備
プロセス一覧
MCFrame
標準業務
プロセス一覧暫定)
Fitting
シナリオ
(暫定)
インテックにて
MCFrame標準業務
プロセスをベースにお客様業務
の流れを確認し、過不⾜を
確認しながら、お客様の
新業務プロセスのたたき台
としてFittingシナリオを
作成する。
作成に当たって、
●業務ルール
●業務課題
のヒアリングを⾏う
標準)
新業務フロー
(MCFrame
標準)
業務ルール
定義
業務課題
■Fittingの進め方
(あれば参考・なければヒアリング)
②Fitting実施
新業務フロー
(改)
ユーザにて
実機を使ったFittingを⾏う。
1巡目は操作習得期間とし、
ユーザはインテックの画面操作
を⾒ながら検討する。
2巡目はユーザが操作を⾏う。
Fittingシナリオに対し、
Fitting結果を記入頂く。
パッケージ標準機能でOKの
場合でも、制約条件等が
ある場合は記載する。
何らかのGAPがある場合は、
●業務運用を変更
●Excel等の⼿作業に変更
●システム検討課題
に分類する。
システム検討課題については
システム対応案をインテック
にて検討し⾒積りを⾏う。
標準)
新業務フロー
(MCFrame
標準)
業務ルール
定義(改)
業務課題
(改)
システム
対応案
暫定)
Fitting
シナリオ
(暫定)
Fitting
シナリオ(改)
■Fittingの進め方新業務プロセス
定義を兼ねる

業務
プロセス
(階層)
主管
部門
タイミング業務
パターン
MCFrame
利⽤機能
Fitting
結果
業務
運用
対応案
システム
対応案
優先度
(高中低)
対応
しない
場合の
業務コスト
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
業務プロセスの
条件分岐
最終的な新業務プロセスと
システム機能
(標準利⽤/機能追加変更)を
決定する
利⽤機能の
想定
(インテックで記入)
■Fittingシナリオ
前頁の「Fittingシナリオ」のイメージを示す。
事前準備として左側網掛け部分の情報を整理する。MCFrameの標準業務プロセスを
ベースに業務ヒアリングを⾏い、お客様業務との過不⾜を反映させ業務範囲を網羅する。
次にFittingでMCFrameの標準機能を利⽤して新業務運用が可能かどうか検証する。
システム対応案については優先度を付けた上で、投資効果を鑑み実施可否を決定する。
システム要件の業務効果や
インパクトによるランク付け
結果が○でも、
前提や制約を
明記する
■業務標準化(スリム化)の視点
業務を廃止する
業務を他業務と統合する
業務を他部門へ移管する
要望を出すユーザは、
業務コストを提示する
月火水木⾦
9:00
|
10:30
事務局会
(課題棚卸)
生産計画
①
発注・仕入
①
(予備)
債権・債務
①
10:45
|
12:15
リーダ会
(進捗確認)
生産計画
②
外注管理
①
(予備)
会計IF
①
13:30
|
15:00
受注・出荷
①
製造管理
①
原価管理
①
受注・出荷
②
在庫管理
①
15:30
|
17:00
売上・請求
①
品質管理
①
原価管理
②
売上・請求
②
(予備)
■セッションコマ設定例
業務カテゴリ単位にFittingセッションの
開催曜日を決める。
右記は原則として販物系を月・木、
⽣産系を⽕・⽔、その他を⾦に設定した例。
原則として、事務局メンバー及び
PM/PLは全てのセッションに出席する。
■セッションシナリオ設定例
セッション日程毎の対象Fittingシナリオ
及び業務フローと、準備事項・検討事項・
ゴールを決め、関係者へ周知、適切な
出席者と事前準備を促す。
セッションカレンダーを共有し、
セッションの進捗管理にも利⽤する。
セッションシナリオセッションシナリオセッションシナリオセッションシナリオ 2013/4/02　改訂
MCFrame販売物流MCFrame販売物流MCFrame販売物流MCFrame販売物流
回数日時概要セッション内容対象フローフィッティング以外の成果物
13:00～15:00
15:15～17:00
10:00～12:00
13:00～15:00
4/15(月)
1 4/10(水) 需給管理①
（目的）
　・MCFrame標準フローを元に需給管理の新システム業務フロー（概要）を検討する
（進め方）
１．需給管理のMCFrame業務フローを説明する。
２．MCFrameを用いた需給管理の想定される運用イメージを説明し、下記を検討する。
　　・需給調整の計画スケジュール
　　・各部門の役割の明確化
　　・現状業務の改善課題
３．必要に応じて、関連マスタの説明をする。
（ゴール）
　□業務標準化計画系タスクにおいて、新業務フロー検討時にMCFrame需給管理機能の利用場
面がイメージできる。
　□業務標準化計画系タスクで決まった新業務フローをもとに、需給管理②でMCFrame機能の
Fittingが行えるようになる。
　□検討中に上がった課題を業務課題、システム課題に振り分け、業務課題について検討できる
2
新業務フロー（概要）（業務標準
化計画系タスク）【需給管理②ま
で】
H100-01 販売予算・販売計画
作成
H100-02 販売予実管理
H110-01 月次需給調整
H110-02 日次需給調整
H210-01 受注登録（在庫品）
H210-02 受注登録（手配品）
H210-04 受注変更・取消
H210-05 納期回答
H210-06 保留管理
H210-07 与信枠変更
H210-08 売上返品
H210-09 売上実績
H210-10 売上実績（在庫管理
対象外品）
H210-12 受注登録（出荷指示
対象外)
H220-01 預り品売上
H220-02 預り在庫出荷受付
H220-03 預り返品
H230-01 貸出品受付
H230-02 貸出売上
H230-03 貸出返品
受注管理①
(目的)
　　・MCFrame標準フローを元に受注管理の新システム業務フロー（概要）を検討する
(進め方)
１．MCFrame受注管理機能フロー別に、MCFrame標準の業務フローと各機能を説明し、下記の検
討をする。
　　・決めなければいけない業務ルール項目洗い出し
　　・各業務機能の実施タイミング
　　・MCFrameに不足している画面・帳票・I/Fデータ
　　等
２．必要に応じて、関連マスタの説明をする。
３．課題に対してMCFrame標準での運用イメージと問題点を説明する
　　・終売
　　・荷姿の入り数表記
　　・得意先担当者について
　　・未来在庫の引当(移送中、生産中、発注中？)
(ゴール)
　□受注管理のMCFrame標準フローを理解し、受注管理②でMCFrame機能のFittingをおこなえる
ようになる。
化タスク）【受注管理②まで】
6/1 土
6/2 日
6/3 月（予備）販売釘宮債権管理② 販売釘宮債権管理②
6/4 火原価賀勢・平田実際原価② 原価賀勢・平田実際原価② （予備）
6/5 水（予備）（予備）（予備）
6/6 木
6/7 金
6/8 土
6/9 日
6/10 月生産内田製造管理③ 販売金需給管理③ 販売釘宮受注管理③
6/11 火生産内田購買管理③ 販売金出荷管理③ 販売金在庫管理③
6/12 水生産内田外注管理③ 原価賀勢・平田標準原価① 原価賀勢・平田標準原価①
6/13 木（予備）（予備）（予備）
6/14 金
主担当主担当主担当カテゴリ内容
①午前（9:00-11:45） ②午後１（13:00-15:15） ③午後２（15:30-17:30）
日付曜日カテゴリ内容カテゴリ内容

■Fittingセッションの進め方
■１コマ内での進め⽅例
①当回の検討業務範囲と検討事項、
ゴール、事前準備状況の確認
②前回宿題の確認(議事録参照)、
期限が迫った課題の検討状況確認
③パッケージ実機操作による
業務検証の中で、業務手順説明と
マスタ説明を併せて⾏う
※GAPがある場合、まず業務運用の
⾒直しを検討する
④新フローへ業務変更点、考慮点、
等の検討結果を記載
⑤課題抽出、検討期限と担当設定
業務課題⇒ユーザにて対応案検討
システム課題⇒インテックにて検討
⑥次回宿題確認、内容/日程調整
INPUT OUTPUT
セッション
(１コマ２時間程度)
基礎情報ヒアリングシート/
Fittingシナリオ
方針・課題
ユーザ手持ちの方針・課題等
Fittingシナリオ/新フロー
課題管理表(業務課題/システム課題)
機能・マスタ
MCFrame機能概要説明書
課題管理表(業務課題/システム課題)
MCFrame標準業務フロー
セッションシナリオセッションシナリオセッションシナリオセッションシナリオ 2013/4/02　改訂
MCFrame販売物流MCFrame販売物流MCFrame販売物流MCFrame販売物流
回数日時概要セッション内容対象フローフィッティング以外の成果物
13:00～15:00
15:15～17:00
10:00～12:00
13:00～15:00
4/15(月)
1 4/10(水) 需給管理①
（目的）
　・MCFrame標準フローを元に需給管理の新システム業務フロー（概要）を検討する
（進め方）
１．需給管理のMCFrame業務フローを説明する。
２．MCFrameを用いた需給管理の想定される運用イメージを説明し、下記を検討する。
　　・需給調整の計画スケジュール
３．必要に応じて、関連マスタの説明をする。
（ゴール）
　□業務標準化計画系タスクにおいて、新業務フロー検討時にMCFrame需給管理機能の利用場
面がイメージできる。
　□業務標準化計画系タスクで決まった新業務フローをもとに、需給管理②でMCFrame機能の
Fittingが行えるようになる。
2
化計画系タスク）【需給管理②ま
で】
H100-01 販売予算・販売計画
作成
H100-02 販売予実管理
H110-01 月次需給調整
H110-02 日次需給調整
H210-01 受注登録（在庫品）
H210-02 受注登録（手配品）
H210-04 受注変更・取消
H210-05 納期回答
H210-06 保留管理
H210-07 与信枠変更
H210-08 売上返品
H210-09 売上実績
H210-10 売上実績（在庫管理
対象外品）
H210-12 受注登録（出荷指示
対象外)
H220-01 預り品売上
H220-02 預り在庫出荷受付
H220-03 預り返品
H230-01 貸出品受付
H230-02 貸出売上
H230-03 貸出返品
受注管理①
(目的)
　　・MCFrame標準フローを元に受注管理の新システム業務フロー（概要）を検討する
(進め方)
１．MCFrame受注管理機能フロー別に、MCFrame標準の業務フローと各機能を説明し、下記の検
討をする。
　　・決めなければいけない業務ルール項目洗い出し
　　・各業務機能の実施タイミング
　　・MCFrameに不足している画面・帳票・I/Fデータ
　　等
２．必要に応じて、関連マスタの説明をする。
３．課題に対してMCFrame標準での運用イメージと問題点を説明する
　　・終売
　　・荷姿の入り数表記
　　・得意先担当者について
　　・未来在庫の引当(移送中、生産中、発注中？)
(ゴール)
　□受注管理のMCFrame標準フローを理解し、受注管理②でMCFrame機能のFittingをおこなえる
ようになる。
化タスク）【受注管理②まで】
セッションシナリオ/日程(調整)
〜〜〜
議事録セッション後、ユーザが自席にてセッション後、ユーザが自席にて
パッケージ操作を含めた業務検証
(復習/予習)を引き続き⾏う。
■ウォークスルーとは
業務カテゴリ毎に実機にて進めたFitting(新業務検討)の結果、
新業務全体が新システムを利⽤してスムーズに流れるか、実機を使って業務のつながりを確認する
レビュー⾏為の一種である。MCFrame導入範囲についてはMCFrame実機を使い、
他パッケージ・スクラッチシステム・周辺システムとの連係部分については机上で検証を⾏う。
■ウォークスルーの手順
①業務カテゴリ毎(生産計画/購買/製造/品質/在庫/受注/出荷/売上/請求/⼊⾦、等)の
主要業務について、実施シナリオとデータを事前に準備する。
②業務のつながりを、MCFrame(実機)、周辺システム(机上)の利⽤をイメージしながら、
全体が流れるかを関係者全員で確認・共有する。特に部門間の情報連係を確認する。
③現⾏業務からの変更点について、関係者全員で確認・共有・合意する。
④上記を通して、業務パターンのモレや業務上の問題点がない事を確認する。
ウォーク
スルー
標準機能
検証
（詳細）
追加機能
検証
運用テスト本番運用
■新業務検討の流れとウォークスルーの位置づけ
Fitting
要件定義フェーズ

■作業負荷について
プロジェクト全体を通して、導入ベンダー側とユーザ側に掛ける負荷の目安を示す。
フェーズ要件定義(Fitting) 導入実装運用テスト
導入
ベンダー
ユーザ
標準導入プロセスの特徴は、要件定義フェーズでの導⼊ベンダーとユーザの参画度をプロジェクト
期間中の相対負荷として最も厚くし、導⼊以降のベンダーの作業負荷を従来よりも下げる事にある。
これによる効果としては以下の通り。
マスタ精度の早期向上によるシステム品質の早期確保。
パッケージ習熟度の早期向上による要件ブレの最小化。
業務の標準化と業務実効性の早期検証による要件ブレの最小化。
開発スコープ削減によるコスト圧縮と工期短縮。
運用テスト期間の短縮によるコスト圧縮と工期短縮。
導⼊フェーズ以降のベンダー支援工数削減によるコスト圧縮。
作業負荷のピークをFittingに⽴てる。
前を厚く！
後ろを薄く！
前を厚く！
後ろを薄く！
工数の重心を前に！
前を厚く！
後ろを薄く！
工数の重心を前に！
前を厚く！
後ろを薄く！
■業務サイドとシステムサイドの攻防
標準導⼊においては、ユーザの要求を安易に聞き⼊れず、
パッケージ標準機能を使って何とか
工夫できないかをユーザへ投げ返す。
★システム側メンバーには、
覚悟を持った構えと
粘り強い交渉が必要。
最終的な折り合いは、
業務コストとシステムコストの
投資効果を鑑みた経営判断となる。
★業務側メンバーには、
システム要求を裏付ける
明確な根拠が必要。
業務側業務側
システム側システム側
機能が足りないので
システムの検討をして欲しい
こういう風に使えば
標準機能で運用可能では？
⾏ったり
来たり
⾦は出すから
言う通り作ってくれ
(ユーザ)
意地でも作らんぞ
(事務局・ベンダー)
この機能を実装しなければ、
どのくらいの業務コストが
掛かるのか示して下さい

■Fittingの開始条件
Fitting開始の前提となる必要情報を示す。通常は要件定義開始までにお客様側で整備されるものである。
これらのドキュメントが未整備の場合、要件定義の前段として企画・構想フェーズを設けるなど準備期間が必要となる。
プロジェクトの開始時に、Fitting開始可否の判断が必要である。
フェーズ成果物名称概要/目的
企画
・
構想
経営課題
経営課題と解決の方向性を示したもの。製品戦略/価格戦略/組織改革/業務改革/IT投資/取引先
との関係改善等、様々な施策と計数目標がある。
プロジェクト方針プロジェクトの開始終了目標時期、お客様側の体制、実施優先順位等を⽰したもの。
システム実現方針情報化ポリシーやシステム実現上の制約事項などを示したもの。
業務棚卸表
現⾏業務プロセスを棚卸し、検討対象業務全体のプロセスを網羅的に記載したもの。
現⾏業務をベースに⽅針を踏まえた新業務プロセスが定義されている場合がある。
これがない場合、パッケージ適用の場合はパッケージ標準業務プロセスをベースに検討するが、
スクラッチの場合は要件定義開始前に整理されていないと検討に⽀障が出る。
業務ルール定義書
受注キャンセル、在庫引当、出荷制限、⼊⾦消込、リベート計算、⽣産計画、等々の各業務における基本
ルールを資料化したもの。新業務においてルール変更を伴う場合は、現⾏からの変更点について関係者
と合意を図る。事前に整理されていない場合は、要件定義時に作成が必要。
業務課題表
業務棚卸、業務ルール整理、新業務検討において抽出された検討課題を記録し、解決の⽅向性、
解決までの検討プロセス、解決案等が示されたもの。Fitting時に発生する課題は、新システムを使う
上での課題が多く、そもそもの業務課題とは粒度が異なるため、要件定義開始時に整理が必要である。
現⾏システム各種資料新システム検討のインプットとなる下記情報。
・システム関連図現⾏サブシステムの存在と連係の有無、要件定義における検討対象範囲を⽰したもの。
・インターフェイス一覧現⾏サブシステム間連係データの概要(データ種/連係方向/タイミング/方式等)を示したもの。
・機能一覧現⾏システム全体のシステム機能概要を⽰したもの。機能毎の利⽤頻度が⽰されている事が望ましい。
・帳票一覧
(ローカルツール含む)
現⾏システムの帳票、システムから抽出したCSVデータ、個⼈利⽤のExcel等、システムのアウトプットの
利⽤状況を棚卸し、必要性の判断に利⽤するもの。
・データ件数
(マスタ/トランザクション)
受注件数、受注明細件数、出荷明細件数、売上明細件数、発注/仕入明細件数等、
業務毎の主要データのボリューム把握が可能な情報。
・マスタコード定義書品目、取引先等の主要マスタコードについて、現⾏のコード体系を定義したもの。
③トップダウン方針
経営者からプロジェクトに対して、明確な方針を打ち出す。
以下の２つのメッセージを発信頂く必要がある。
業務改革宣言
「基幹業務パッケージ導入＝業務改革」であるという点を宣言し、現状に
引きずられない体制を構築する。基幹システムの⾒直しは、⻑年の悪習を
一掃する千載一遇のチャンスであり、聖域なく検討すべしという方針を
全社に周知する。
⼒の入れどころの示唆
業務全般、なんでもかんでも標準化と言うのは現実的ではないと同時に
⾃社の良さを失う危険性がある。例えば、対外サービス強化につながるような
業務機能や生産プロセス強化につながる機能についてはシステム投資を
惜しまない、それ以外の付加価値の低い業務についてはパッケージに
合わせて徹底的に標準化を進め、ムダを排除するといった、
メリハリの利いた検討⽅針の⽰唆を⾏う。

トップダウン方針が明確に打ち出された場合でも、実務現場の業務担当者の
標準導入に対するモチベーションが伴わないとうまくいかない。
現状を「正」としない
なぜ現状の業務手順なのか？その必然性は？と自分の業務に対して
距離を置き問いかける姿勢、⼿順変更に対してできない理由を探さない
姿勢が必要。
部分最適に走らない
明確な目的意識(なんのための業務か、どのような情報が必要か)が
大事であり、これを満たせば、部分的に手間が増える事は問題ではない、
業務全体で効率化を図る事ができれば良い、という⼤所⾼所の考え⽅が
必要。現⾏業務のやり⽅が良いとの「幻想」を捨てる。
当事者意識
やらされ感ではなく、会社を変えるのは自分であるという、
プロジェクトメンバーとしての自覚とポジティブな取り組み姿勢が必要。
プロジェクト開始時に、標準導入に近づけるためのFittingのスタンスを
関係者で充分合意しておく必要がある。
システムサイド
パッケージ機能を理解頂いた上で、機能説明で終わるのではなく、
ユーザの業務運用をどのようにできるか、業務手順を一緒に考え提案する。
このためには、業務を深く理解する必要がある。
各業務機能の検討の中で、ユーザがどのようにマスタを変更すると
業務機能の動きが変わるかを併せて理解頂く。
またマスタ登録業務運用の検討が後回しにならないよう留意する。
ユーザサイド(キーユーザ)
Fittingはシステムベンダーがやってくれるという考えではなく、
自分自身でパッケージを操作しながら、新業務イメージを組み⽴てる、
率先してMCFrameの⿊帯になるという目的意識を持って臨む。
機能GAPに対して、現状業務を是とすると議論が進まない場合がある。
いったん現状から離れて業務の目的を再確認した上で業務⼿順を⾒直す。

④プロジェクト推進体制（個社）
基幹業務の再構築プロジェクトでは、業務現場の意思決定者を巻き込んだ推進体制が必須である
事はもちろん、ユーザタスクを確実に実⾏するためには、タスク実⾏を導き後押しするための
強⼒な事務局機能が必要になる。プロジェクトの舵取りに必要な体制を示す。
【プロジェクトオーナー】
方向付け
投資判断
【プロジェクトマネージャ】
【プロジェクトリーダー】
推進責任者
【ステアリングコミッティ】
主要課題解決
【プロジェクト事務局】
推進⺟体
経営⽅針を踏まえ、プロジェクトの⽅向付けを⾏いプロジェクト方針を
トップダウンで全社へ周知する。
またプロジェクトから上申されるシステム投資についての最終判断を⾏う。
プロジェクトで検討される業務課題/システム課題の内、会社方針や
業務分掌に関わる主要課題について協議決定を図る。またプロジェクト
運営に必要な資源(組織・人・予算・時間)についての調整を図る。
プロジェクトの実⾏責任者として、プロジェクト全体の舵取りを⾏う。
社内の各部門及びシステムベンダーとの橋渡し役であると同時に、
プロジェクトタスクの組み⽴てと最終成果に責任を持つ。
業務部門の代表者(業務プロセスの意思決定者)と情報化推進部門で
構成し、業務課題/システム課題の解決と新業務プロセス構築に向けて
現場⽀援を⾏い、プロジェクトを円滑に進める働きかけをする。
作業計画支援
業務課題検討リード
進め方、成果物レビュー
システム課題検討依頼
構成メンバー：6〜7名
●個社
PM/PL
業務部門代表者
情報システム部門
●アサヒグループ
APM/NAiS
ベンダーのPMO
■事務局の位置づけ
【プロジェクト事務局】
・プロジェクト計画(大・中・小)
・セッション計画、セッションリード
・プロジェクトマネジメント
(課題管理/進捗管理等)
・投資コントロール
【業務担当者】
・パッケージFitting検証
・新業務プロセス検討
・業務運用検証、教育
【業務担当者】
・パッケージFitting検証
・新業務プロセス検討
・業務運用検証、教育
【インテック】
・システム導入計画
・パッケージ機能活用提案
・システム機能設計開発
・操作教育、データ移⾏、検証⽀援
【インテック】
・システム導入計画
・パッケージ機能活用提案
・システム機能設計開発
・操作教育、データ移⾏、検証⽀援
アサヒ様事例では、
個社プロジェクトの
事務局機能を充実
させた事で、タスクを
遅延なく推進できた
アサヒ様事例では、
個社プロジェクトの
事務局機能を充実
させた事で、タスクを
遅延なく推進できた

■事務局機能の詳細
システムベンダーの成果チェックや監視・コントロールは事務局が⾏うが、それ以外に、
プロジェクトの業務側タスクをドライブするための事務局機能を示す。
業務側タスクタスク概要左記に対する事務局タスク
パッケージシステム
概要理解
新システムに適用する各種パッケージ製品の機能概要を
把握し新業務検討の準備を⾏う。
パッケージ製品の情報提供、説明会の企画・運営。
現⾏業務棚卸
業務課題検討
新業務プロセス構築
Fittingシナリオ作成
業務運用案検討
パッケージ業務検証
現⾏業務プロセスの情報収集と整理、
現⾏業務の問題分析と新業務に向けた課題設定。
業務⼿順やルールの⾒直しと職務分掌の再検討による
新業務プロセスの定義。
パッケージの実機を使った新業務検証(Fitting)。
現⾏業務整理のスキーム提供。
業務課題の整理分類、解決策の⽅向付け。
要件定義で実施するFittingシナリオ案の作成と、
業務課題/システム課題検討支援。
各種検討セッションのスキーム策定と日程・人員調整。
システム要件検討
システム機能レビュー
業務運⽤の⾒直しで解決できない課題について、どのような
システム機能が必要かを検討しシステム側へ提示する。
またシステム側が検討した結果をレビューし、業務運用が
可能かどうかを判断する。
システム要件の整理、優先度付け、システム対応案の検討。
投資効果判断のための業務コスト把握(システム機能を設け
る/設けないでどの程度業務コストが変わるか)。
対外調整
業務⾒直しにより、得意先や仕⼊先へ影響のある点(例：
請求書や注⽂書変更等)について事前案内をする。
関係先への案内周知事項の起案。
マスタ整備
パッケージのマスタの内、現⾏システムから単純移⾏できるも
の以外についての整備。
マスタ整備手順の提示と業務担当者の整備支援。
業務マニュアル作成
新業務のフロー・手順・ルール・システム機能を含めた
マニュアルを作成し、教育のインプットとする。
業務マニュアルの構成案及び記載レベルの検討。
エンドユーザ教育
キーユーザより現場担当者へシステム操作を含めた新業務
運⽤の教育を⾏う。
教育計画⽴案(実施内容・対象者・実施場所)と実施段取
り。教育結果のチェック(業務習熟度把握等)
運用テスト
運用テストのシナリオを作成し、新業務が回るかどうかを
検証する。
テストシナリオの作成支援。テスト実施状況の把握と進捗管
理。本稼働に向けた課題整理と解決の促進。
プロジェクトマネジメントタスクの中で、特に重要なものが課題管理である。
以下、課題解決に至るまでの運用フローを示す。
各業務検討
セッション(日次)
課題
管理表
管理表
課題
管理表
事務局
セッション(週次)
業務課題
システム
課題
業務部門検討
業務改革委員会決定
システムベンダー
起案(仕様・⾒積)
ステアリング
コミッティ
(随時・月次)
意思決定・合意
得意先
仕入先
経営課題
各種検討で発生する
課題・疑問を記録し、
関係者で共有する。
左記で発生した課題を精査した上で、検討対象とすべき
ものを正規の課題区分とする。
さらに経営課題、業務課題、システム課題に振り分ける。
(対外課題)業務運⽤⾒直し
システム仕様検討
週次で課題棚卸を⾏い、
・課題内容精査
・検討担当アサイン
・期限管理
・課題解決プロセス検討
・課題クローズ判断
を関係者合意の上⾏う。
課題解決状況を定量化し、
プロジェクトで共有する。
振分
エスカ
レーション
■課題管理

MCFrameの
優位性
MCFrameの
優位性
FittingアプローチFittingアプローチ
標準機能の展開
標準機能の展開
コストダウンの
実現
コストダウンの
実現
導入実績、機能性、汎用性、保守性共に優れたシステム
であり、インテック保有のテンプレートと併せて利⽤する事で
業務優位性を実現した。
導入実績、機能性、汎用性、保守性共に優れたシステム
であり、インテック保有のテンプレートと併せて利⽤する事で
業務優位性を実現した。
MCFrame標準機能を最大限活用するFittingアプロー
チにより業務のムダ・ムラを省きながら業務標準化を進める
ことによって、より洗練されたシステムを実現した。
MCFrame標準機能を最大限活用するFittingアプロー
チにより業務のムダ・ムラを省きながら業務標準化を進める
ことによって、より洗練されたシステムを実現した。
MCFrame標準機能では実現できない、各社共通で必要
な機能をグループ標準機能として開発し、MCFrameに
厚みを持たせることで、グループ業務の最適化を実現した。
MCFrame標準機能では実現できない、各社共通で必要
な機能をグループ標準機能として開発し、MCFrameに
厚みを持たせることで、グループ業務の最適化を実現した。
Fittingアプローチによる導入期間の短縮、アサヒグループ
標準機能の開発、インフラ環境の統合、運用人員の圧縮
を進めることで、トータルで大幅なコストダウンを実現した。
Fittingアプローチによる導入期間の短縮、アサヒグループ
標準機能の開発、インフラ環境の統合、運用人員の圧縮
を進めることで、トータルで大幅なコストダウンを実現した。
■アサヒグループ様視点での総括
トップダウン方針の
徹底
トップダウン方針の
徹底
マネジメントの
徹底
マネジメントの
徹底
導入担当者の
粘り強い交渉
導入担当者の
粘り強い交渉
ユーザ部門の
協⼒体制
ユーザ部門の
協⼒体制
「パッケージの機能GAPは業務GAPである」を大方針に、
アサヒグループホールディングス様から導入各社様への
明確な方針(標準導入＝業務改革)の周知徹底により、
プロジェクトの判断軸がブレずに進む事ができた。
「パッケージの機能GAPは業務GAPである」を大方針に、
アサヒグループホールディングス様から導入各社様への
明確な方針(標準導入＝業務改革)の周知徹底により、
プロジェクトの判断軸がブレずに進む事ができた。
各社プロジェクト事務局による、計画策定・課題管理・
進捗管理等のマネジメントタスクが確実に実⾏され、
またユーザタスクのフォローも手厚くされた。
これによりインテックは導⼊作業に専念できた。
各社プロジェクト事務局による、計画策定・課題管理・
進捗管理等のマネジメントタスクが確実に実⾏され、
またユーザタスクのフォローも手厚くされた。
これによりインテックは導⼊作業に専念できた。
Fittingにて発生した機能GAPに対して、ユーザから
システム要件の実装要望があった場合も安請け合いせず、
業務運⽤の変更を⼀緒になって考え標準導入に近づける
事ができた。
Fittingにて発生した機能GAPに対して、ユーザから
システム要件の実装要望があった場合も安請け合いせず、
業務運⽤の変更を⼀緒になって考え標準導入に近づける
事ができた。
現業を持ちつつも、プロジェクト作業を遅延させる事無く
所定のタスクを実⾏頂いた。トップ⽅針を理解した上で、
業務担当者のモチベーション維持による所が大きい。
現業を持ちつつも、プロジェクト作業を遅延させる事無く
所定のタスクを実⾏頂いた。トップ⽅針を理解した上で、
業務担当者のモチベーション維持による所が大きい。
■インテック視点での総括

■パッケージ標準導入になじむ企業
業務標準化に関心がある
基幹業務パッケージ導入をシステム化ではなく業務再構築と捉え、
標準導入(業務改革)を目指す企業
業績の良し悪しに関わらず、お⾦の使い⽅が上⼿
単にIT投資を抑えるという事ではなく、⾃社の強みを認識し
⼒の⼊れどころを⼼得ている企業
トップに会社を変える意識がある
現状を是とせず、常に変革を求める経営体質を持った企業、
またトップダウン⽅針が浸透しやすい、トップと現場の距離が近い企業
自前主義の文化ではない
良いものや良い考え⽅を外部から積極的に取り⼊れ、
活用する文化を持つ企業
２．プロジェクト人財
育成への取り組み
２．プロジェクト人財
育成への取り組み

■インテックにおけるMCFrameプロジェクトの概要と必要人財
プロジェクトに必要な10の職種を定義。
関わるフェーズによって、職種内の適正なスキルレベルの要員をアサインする。
（1）プロジェクトに必要な人財
基本
設計
詳細
設計
単体
開発
内部
結合
テスト
外部
結合
テスト
総合
テスト
要件
定義
(Fitting)
導入
(環境構築/ﾏｽﾀ整備/業務検証/ﾄﾗﾝ移⾏/教育)
運用
テスト
企画
構想
保守
コンサルタント人財(FC/SC)コンサルタント人財(FC/SC)
マネジメント人財(PM/PL)マネジメント人財(PM/PL)
コンサルタント
人財(PC)
人財(PC)
提案
活動
エンジニア人財(IE/SE)エンジニア人財(IE/SE)
エンジニア人財(PG)エンジニア人財(PG)
マネジメント人財(DL)マネジメント人財(DL)
エンジニア人財(ME)エンジニア人財(ME)
開発がある場合⇒
開発がある場合⇒
職種役割定義求められるスキルセット（知識と経験）
マ
ネ
ジ
メ
ン
ト
P
M
プロジェクト
マネージャ
プロジェクト現場の対お客様窓口として、お客様との調整・交渉を
⾏う。また社内においては、事業部門に対するプロジェクト報告・
要員調整・SQCD管理に責任を持つ。小中規模案件においては、
PLが当役割を兼任する場合がある。
MCの概要を踏まえ提案⾒積の推進とレビューができる。また
プロジェクト全体のタスク構築・要員計画・SQCD管理ができ
る。プロジェクトの問題点を早期にキャッチし是正策を図る事
ができる経験が必要。プロジェクト管理全般の知識が必要。
また⼀般的な業務知識が必要。
PL プロジェクト
リーダ
タスク実⾏のリーダ。アプリケーション仕様に関する対お客様窓口。
システム仕様の決定に責任を持つ。またタスク詳細(WBS)の組み
⽴てとタスク進捗管理・課題管理に責任を持つ。
MC全般の知識と導⼊経験を踏まえたプロジェクト推進ができ
る。プロジェクトメンバーへのタスク推進指導ができる。
また⼀般的な業務知識が必要。
D
L
開発リーダアドオン・カスタマイズ開発（請負プロジェクト）における
開発計画の⽴案とSQCD管理。仕様についてコンサルタントと
連係し設計チームへ引き継ぐリードを⾏う。開発要員管理を⾏う。
MC開発経験を踏まえて、MCアドカス機能⾒積のレビューが
できる。通常の開発経験を踏まえて、開発手順と要員の
最適化を図る事ができる。進捗管理・品質管理ができる。
コ
ン
サ
ル
タ
ン
ト
P
C
提案
お客様業務の概要を理解し、MC採用に向けた提案⾒積を実施
する。またお客様へのプレゼンテーション、デモ実施、及びQA対応
を⾏う。FCが当役割を兼ね、プロジェクト実⾏フェーズへ引き続き
参画するケースあり。
MCの専門性と⼀般的な業務知識を背景に、お客様業務に
照らしたMC利⽤イメージを紹介できる。デモデータの設定と
MCのオペレーションができる。
F
C
導入
お客様業務の詳細を理解し、⼀般業務知識及びMC仕様を踏
まえて、Fitting及びMC導入作業全般を推進する。新業務プロ
セス決定におけるMC活用案の検討・決定に責任を持つ。
MCの専門性と⼀般的な業務知識を背景に、MCの適用を
考える。またお客様との窓口になりタスクを計画・推進できる。
マスタ設定とMCのオペレーションができる。
S
C
導入サブ
導入コンサルタントの補助要員として、マスタ整備、MC機能説明、
ドキュメント作成等を⾏う。
MCの専門性と⼀般的な業務知識は少ないが、MCの基本
知識（機能・マスタ）を持ち、FCの補助ができる。
エ
ン
ジ
ニ
ア
IE 基盤
エンジニア
アプリケーションチームと連携し、MCの基盤環境を構築する。また
MCアプリ基盤機能設計ができる。またMC開発技術の提供と設
計・プログラミングの規約監視及びモジュール管理を⾏う。
Oracle,Cosminexus,SVFの環境設定ができる。
FrameManager知識を踏まえたMC環境構築ができる。
インフラサイジングができる（MC標準サイジングツール）。
M
E
移⾏
エンジニア
データ移⾏に関する要件定義、⼿順設計、移⾏実施と検証を
⾏う。中小規模案件ではSCかSEが当役割を吸収する。
移⾏経験を踏まえた詳細の移⾏計画⽴案ができる。
MCのデータベース構造の知識、⾼度なSQL知識が必要。
S
E
設計
エンジニア
MC機能のアドオン・カスタマイズ基本設計、及びシステムテストを
⾏う。詳細設計・結合テストはPG職種へ含める。
MCのクラス・メソッドの知識、FrameManagerの知識。
MC設計経験。
P
G
プログラマ MC環境での詳細設計（実装仕様書）・プログラム開発・
単体テスト・結合テストを⾏う。
FrameManagerの知識。開発⾔語
（Java、SVF、PL/SQL）の知識。MC開発経験。
■MCFrameプロジェクトに必要な職種と役割及びスキルセット
（2）職種定義

要員スキルの
現状把握
要員スキルの
現状把握
育成パスの設定育成パスの設定
育成メニューの整備育成メニューの整備
プロジェクト
経験の蓄積
プロジェクト
経験の蓄積
⾃部門における職種別の要員分布の調査を⾏うと共に、
あるべき要員⽐率を設定し、GAPを踏まえて要員数と
レベル感の育成目標を⽴てる。
⾃部門における職種別の要員分布の調査を⾏うと共に、
あるべき要員⽐率を設定し、GAPを踏まえて要員数と
レベル感の育成目標を⽴てる。
職種毎に必要なトレーニング(技術講習/OJT等)を設定し、
プロジェクト参画時に、よりスキルを定着化させるための
要員別育成計画を⽴てる。
職種毎に必要なトレーニング(技術講習/OJT等)を設定し、
プロジェクト参画時に、よりスキルを定着化させるための
要員別育成計画を⽴てる。
既存の技術トレーニングメニューに加え、業務知識習得に
向けた育成メニューを作成する。またMCFrameプロジェクト
の標準プロセス(タスク/役割/成果物)を理解させる。
既存の技術トレーニングメニューに加え、業務知識習得に
向けた育成メニューを作成する。またMCFrameプロジェクト
の標準プロセス(タスク/役割/成果物)を理解させる。
実プロジェクトにおいて、所定のスキル保有者の指導の下、
サブ担当としてプロジェクト経験を積む。スキル成熟度を
⾒極めた上で、プロジェクトのメイン担当へアサインする。
実プロジェクトにおいて、所定のスキル保有者の指導の下、
サブ担当としてプロジェクト経験を積む。スキル成熟度を
⾒極めた上で、プロジェクトのメイン担当へアサインする。
■プロジェクトに必要な⼈材育成の流れを⽰す。
（3）育成の流れ
各地区要員のMCFrameスキル評価結果を集計し分析を⾏った。
２つの観点から分析し、あるべき職種⽐率との乖離を検証している。
①コンサルタント職種とエンジニア職種の⽐率
②専門分野別のコンサルタント⽐率
（4）要員スキルの現状把握
当事例は
2013年時点
41.2%
29.4%
15.7%
13.7%
XAプロフェッショナル
専門分野の相対分布
販物
生産
原価
会計IF
10.5%
15.0%
21.1%20.3%
24.8%
XAプロフェッショナル
職種の相対分布
PC
FC
SC
IE
ME
SE
PG
7.5%0.8%
仮説：
・コンサルタントとエンジニアが半々
⇒コンサル7：エンジニア3が妥当
・コンサルの中でも特にFCが足りない
⇒現状の2倍以上必要
・ゆえに、下記⽐率が妥当
FC 40%
SC 20%
PC 10%
仮説：
・販物が生産よりやや多い
⇒現状維持
・原価が生産の半分
⇒原価の⽐率を上げるべき
・ゆえに、下記⽐率が妥当
販物 58%
生産 42%
原価 45%
スキル重複度から、
計145% を⺟数と
した
２年後をめどに
あるべき⽐率へ
シフトする

コンサルタント職種、エンジニア職種、マネジメント職種の３系統の育成パスを設定する。
特にコンサルタント職種とマネジメント職種については、⼀般的な業務知識を併せて
習得する必要がある。
MC開発系
トレーニング受講
MCCP取得標準化講習会
コンサルタント職種
マネジメント職種
エンジニア職種
MC業務系
トレーニング受講
MCCP取得標準化講習会
MC動向・概要
マネジメント
研修
標準化講習会
BENG
技術交流会
業務知識習得
（書籍等）
業務勉強会
業務知識習得
（書籍等）
業務勉強会
プロジェクト参画
（継続）
（継続）
（継続）
（5）育成パス
メニュー対象ねらい概要/効果 INPUT OUTPUT
標準化講習会
（各3h程度）
部門⻑
標準化窓口担当
PM/PL
PC/FC/SC
INTEC標準の
MC導入の考え方の
周知
標準化指針と標準成果物を理解し、
メンバーを指導できるようにする。
また提案において標準化の要素を
盛り込めるようにする。
・MC標準化指針
・各種標準成果物
・QA
・標準化指針の改善点
・プロジェクトへの適用
時の留意事項
コンサルタント職種
FC/SC
Fittingの理解と、
Fit&Gapからの脱却
Fittingの考え⽅を理解し、Fitting
タスクの進め方を身につける。マスタ
整備手順と、お客様業務とMCとの
GAP(課題)への対応オプションを増
やす。
・QA
時の留意事項
エンジニア職種
DL
IE/ME/SE/PG
MC基盤環境と
設計開発標準の
理解
MC性能の確保と機能開発に関す
る⼿順を理解する。また開発に伴う
各種規約を理解する。またより効率
的な開発方法のオプションを増やす。
・環境パラメータ
・標準ツール
・規約類
・QA
時の留意事項
MCFrame
トレーニング
FC予備軍
MCスキル向上
業務スキル向上
BENG主催の有償研修。
XAとCS２系統。販物・生産・原価
の３分野別。定期開催及び
INTEC向け特別研修を検討。
・BENGテキスト
・トレーニングにおける
MCのtips
MCFrame
エンジニア
トレーニング
IE/SE予備軍
MCスキル向上
テクニカルスキル向上
BENG主催の有償研修。
XAとCS２系統。定期開催及び
INTEC向け特別研修を検討。
・BENGテキスト
・トレーニングにおける
MCのtips
トレーニング・
フィードバック
講習会
（2h程度）
FC予備軍
MC知識と
ノウハウ共有
研修受講者が、習得し切れなかった
要素を有識者に聞いて補完した上
で、未受講者に対して研修で得た
知⾒を伝える。これにより受講者の
スキル定着と、知識共有を図る。
・BENGテキスト
・有識者知⾒
・MCのtips
・お客様向けMC機能
概要(新規/改訂)
・開発ノウハウ
MCCP受験 FC/SC MCスキル向上
BENG主催の資格試験。
№1ベンダーとしての地位確保。
・BENGテキスト・MCCP資格
人財育成に向けたトレーニング、及びその他施策メニューの一部を示す。
（6）育成メニュー

THANK YOUご清聴ありがとうございました。
ご意⾒ご質問がございましたら、遠慮なく頂けますと幸いです。

[G-Tech2015]攻めのIT経営銘柄に選ばれたアサヒグループホールディングス様の基幹刷新への取り組み～MCFrameによる基幹システム刷新事例　Fittingアプローチとは？～ - 株式会社インテック[講演

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (10)

Similar to [G-Tech2015]攻めのIT経営銘柄に選ばれたアサヒグループホールディングス様の基幹刷新への取り組み～MCFrameによる基幹システム刷新事例　Fittingアプローチとは？～ - 株式会社インテック[講演

Similar to [G-Tech2015]攻めのIT経営銘柄に選ばれたアサヒグループホールディングス様の基幹刷新への取り組み～MCFrameによる基幹システム刷新事例　Fittingアプローチとは？～ - 株式会社インテック[講演 (20)

More from Trainocate Japan, Ltd.

More from Trainocate Japan, Ltd. (20)