コラムカテゴリー：ITコンサルティング
1. いきなりパッケジーソフトのFit & Gapから始めて失敗するのはなぜか？
システム導入を行う際にシステムベンダーは自社のパッケージソフトを掲げ、「このパッケージソフトを導入すれば業務改善のノウハウが盛り込まれているので、貴社も間違いなく業務の改善が行えます。」と提案してくる。
本当だろうか？
下図を見ていただきたい。
縦軸が業務の効率性・迅速性、横軸が時間軸とする。現状業務（As Is）のレベルが限りなく下にある破線のレベルを表すとすれば、ベンダーのいう業務改善のノウハウが盛り込まれているパッケージソフトのレベルはその上方のレベルに位置することになる。この状態で『Fit & Gap』と称して実際の画面等を見ながらプロトタイピングと行うと、ほとんどのユーザは「今のうちのやり方と違う。画面にこの項目を足して、この帳票が出るようにして欲しい。」などといって限りなくパケージソフトは現状のレベルに引きずられていく。気がつくと本来業務をパッケージソフトに合わせるつもりが、パケージソフトを現状の業務水準に合わせただけの効果のないカスタマイズをしてしまっている。
なぜこんなことになるのだろうか？
答えは、ユーザが現状の業務のやり方しか知らないからである。
そこで、『To Beモデル』が必要となる。
下図を見ていただきたい。
2. 『To Beモデル』とは
我々はシステムコンサルティングで「まず業務処理の『To Beモデル』を描きましょう」と提案する。
この『To Be』というのは日本語で「あるべき」と訳される。したがって、『To Beモデル』というのは「あるべき姿」という意味になる。
先ほどと同じように縦軸が業務の効率性・迅速性、横軸が時間軸とする。我々はパッケージが何であろうと、まず本来のBPR（Business Process Reengineering）の視点で業務処理の「あるべき姿」を設計する。これが『To Beモデル』である。この『To Beモデル』を具体的に業務フローチャートのような形でユーザに見せ、本来の業務のやり方を理解していただく。この『To Beモデル』ができたら、限りなく『To Beモデル』に必要な機能を満たすパッケージソフトウエアを選定し、パッケージの基本機能と『To Beモデル』の『Fit & Gap』を行うのである。
3. 『Can Beモデル』』とは
次に『Can Beモデル』の説明をする。
『To Beモデル』というのはあくまでも理想形であり、ある意味「絵に描いた餅」である。パッケージソフトウエアを限りなく『To Beモデル』に近づけるために、膨大なカスタマイズ費用がかかってしまっては意味がない。そこで『To Beモデル』の実現に必要なカスタマイズに優先順位をつけ、現実的なカスタマイズの落としどころ（現実的解）を見つける。この現実的なレベルを『Can Beモデル』という。（下図）
かくして現状の業務レベルの効率性・迅速性は改善され、現実的な費用でシステム導入は成功することとなる。
関連サービス
2004年08月08日 (日)
青山システムコンサルティング株式会社
