フィットギャップ分析の手法

　あるパッケージソフトを利用して、自分たちの業務ができるかどうかをチェックするのに、フィット＆ギャップ分析を行う。さてそこで、フィット・ギャップ分析をやる方法なのだが、だいたい、こーいう感じじゃないだろうか？

（１）そのパッケージソフトが想定する業務の流れの、アクティビティ図を作成する 　→これは、オペレーションマニュアルで分かるのが普通である 　　(リファレンスをみると混乱する。チュートリアルがある場合は、それでもOK。 　　チュートリアルというのは、コメディアンではない） 　　ちなみに、SugarCRMの場合、「実践！オープンソースCRM　アプリケーション入門」の 　　２章（主にP70からP98)から作成できる。 （２）そのアクティビティ図から想定される、エンティティとその関連をおさえておく 　　　（あとで、データレベルでチェックするので、そこにもどれるように） 　　　→これは、アクティビティを行った入力画面項目を、正規化処理することによって、 　　　　求めることが出来る。 　　ちなみに、SugarCRMの場合、「SugarCRM　Developer's Manual」の５章 　　９４ページから１０３ページにER図が書いてある （３）自社のアクティビティ図と、アクティビティに関するER図を作成する。 　→対象としようとしている業務の。 　　なお、（１）、（２）も、対象部分だけ分析すればよい （４）まず、（１）と（３）のアクティビティ図を比べ、業務レベルでの違いをチェックする 　→まったく違っている場合は（６）へ、 　→時間的な流れに注意。同じ在庫たな卸しでも、月次でやっているか、年次でやっている 　　かでは、かならずしも同じ業務にはならない（期間が長いだけで同じってこともあるけど） 　　 （５）同じと思われる業務に対して、（２）と（３）のER図で、出力データをとくに注意して 　　その差異をしらべる （６）（４）、（５）の差異、（３）で全然違う場合に関して、既存のパッケージの機能、 　　あるいは他のソフトを組み合わせて出来ないかを考える 　　→グラフ機能がないとき、データをExportして、Excelに流し込み、グラフを作成するなど （７）それでもできないとき、どこをどのようにカスタマイズすれば、OKになるかを考える （８）そのカスタマイズは可能なのかどうかを考える 　　→既存パッケージの入出力口をチェック。 （９）（６）で、他のソフトを組み合わせるようなもの、 　　　（８）で可能なカスタマイズ 　　が、　カスタマイズ対象となり 　　　（７）でなにをカスタマイズすれば良いか分からなかったり、 　　　（８）で方法がないの 　　が、現実とのギャップになる。 　　→現実とのギャップは、実際のワークフローをかえることで、可能かどうかを考える

＊パッケージに業務を合わせることは、不可能である。
　そんな急激な変化をしたら、みんな会社をやめてしまう（＞＿＜！）
　→逆に言うと、社員がみんな辞めちゃうほどの、劇的なリストラをするなら可能。
　　また、合併で、組織自体が大幅に変わる場合は可能になる。