最近のパッケージ導入では、プロジェクトの開始当初からユーザーに画面や帳票を見てもらったり、操作してもらったりするプロトタイプ型のアプローチが主流になっている（図1）。
図1●導入アプローチの新潮流
以前のウォーターフォール型のアプローチでは、ITベンダーやパッケージを選定後のシステム構築に時間をかけていた。一方、新潮流ではベンダー選定前に要件を明確化し、選定後はプロトタイプを用いて短期間での稼働を目指すアプローチとなる
[画像のクリックで拡大表示]
プロトタイプ型アプローチでは、パッケージのコンセプトや主要なマスターの構成、各モジュールの基本機能などに関するトレーニングを、ユーザーのプロジェクトメンバーが受講するところから始まる。その後に、ITベンダーが支援しながらフィット・アンド・ギャップ分析やプロトタイプの検証を実施していく。
一般的に開発プロセスは、ウォーターフォール型を採用しているプロジェクトが多い。ウォーターフォール型でパッケージを導入する場合、パッケージはシステム構築のテンプレートの位置づけとなり、要件定義、基本設計、詳細設計、プログラミング、単体テストのようにスクラッチ開発と同様の手順でプロジェクトを進める。
このようなウォーターフォールの考え方で進めた場合、“早く安く作る”というパッケージの特性を生かせず、失敗プロジェクトとなるケースが多い。パッケージ導入では、現行システムと同じ機能を持ったシステムを再構築するイメージで進めると、必ず失敗する。パッケージには設計思想ともいうべき「コンセプト」がある。それに合わない使い方をすると、無理が生じるからだ。