Fit and gap analysis

ERP導入ですが、そもそも

・データモデルをフィットギャップして、導入可否判断をする

・業務フローは、パッケージに埋め込まれたもの（ベストプラクティスという名前の他社業務フロー）を前提に業務改革する

なんじゃないかなあと。

きっと、エライ人のドキュメントにはそう書いてあるはず！

フィットギャップ分析（Fit and gap analysis）を業務フローもしくは業務機能でやったら、フィットしているか、ギャップだらけになるに決まっているのではないかなあ…

パッケージのデータモデルは変更できないからねえ…

ググってみたらみんなそんなこと言ってる気がする。以下は、オラクルの小田さんのブログから引用

一部の方々は、ERPの導入の評価にも、この「データをベースとした分割やフィットギャップ」という手法を使っています。通常、ERPのフィットギャップといえば、欲しい業務機能をどれだけ網羅しているかという観点になりますが、データをベースとしたフィットギャップについては、どれだけ欲しいデータ(エンティティ)を持っているか、リレーションがどれだけ会社のビジネスモデルに近いか、という観点で評価します。データを持っていれば(データがフィットしていれば)、その上のアプリケーション開発は容易という考え方です。業務アプリケーションでは、データが重要ですから、このような方法も十分あります。

サーバー分割の考え方(高可用性やアプリの開発の観点から)　データベースコンサルタントのノウハウちょい見せ　2008/12/31 

これからのERP提案は、すべてデータのフィットギャップを前提にしようと思っています。データを入れて動かしてみれば、機能のフィットギャップは、お客様が見ればわかる…ハズ。