ERPパッケージ導入では，どこまで標準機能で実現できるかによって，プロジェクトの成否が決まるところがある。この標準機能での実現性を検証するうえで，「プロトタイプ」が重要な意味を持つ。

　なお，ここでは「実機を使用してERPの標準機能を確認しながら，ERPの機能で業務運用が実現できることを確認する作業」とプロトタイプを定義する。プロトタイプと同様の作業をCRP（Conference Room Pilot）と呼ぶケースもある。

　プロトタイプ・フェーズの目的は「新業務プロセスの決定」「標準機能とアドオン機能の切り分け」「パラメータ設定の決定」などがある。この目的を達成するために，プロトタイプで「何を」「どこまで」「どのようにして」決めるかを明確にしておかないと，プロジェクトは失敗する。

　ここでは，ERPパッケージを導入するコンサルタントの立場で，プロトタイプに関する留意点について説明する。

いきなりプロトタイプを始めると大量のアドオンが発生

　よくある失敗は，プロジェクト開始時点から業務部門の担当者を集めて，プロトタイプを始めるケースだ。コンサルタントが「ERPの標準プロセスに業務を合わせてください。合わない部分をギャップとして課題化し，解決策を検討します」と説明する。

　このように唐突な始め方をすると，最初の反応は「？？？」。ERPの標準機能が現在の自分の業務とかけ離れていて，自分の業務がどう変わるかの想像ができない。そこで，標準機能の説明を一通り実施することになる。しかし，業務担当者の目線で満足できる説明には時間がかかる。あっという間に2カ月は経過してしまう。

　また，日本の大企業の多くは担当者の役割を細分化し，それぞれの担当者はプロセスの全体像を把握していないことが多い。業務全般を熟知したスーパーユーザーを集めることは難しいし，指示された新しい業務プロセスで作業することを受け入れる土壌もあまりない。

　その状態で，担当者を一堂に集め，「このプロセスであなたの業務が実現できるでしょ」とやってしまうと，個別業務の視点での「ギャップ」が多数見つかるという失敗に陥る。ギャップが多いから，コンサルタントはパッケージの特殊機能を不自然に組み合わせたソリューションを提案する。こんなふうに提案されたソリューションは，シンプルなプロセスをとても複雑な手順で実現していることが多い。複雑な手順を押し付けられた業務担当者は満足するわけもなく，「パッケージなんて不便なだけ」との印象を強くする。パッケージ機能に精通したアプリケーション・コンサルタントほど，この落とし穴に陥りやすい。

　そして結論。「御社の業務は，固有の機能が多くあり当ERPの適合率は50％以下です。もっと標準機能に合わせる努力をするか，大量のアドオン機能を開発するか選択してください」。こうして，数カ月かけた作業が暗礁に乗り上げる。

業務運用を確認しておかないと後で変更が発生

　もう一つよくある失敗は，「主要プロセス」をざっくりと流して「大丈夫」と安心してしまうケース。「標準プロセス」に沿ってシステムの機能だけをつなげて見せていく。請求書もどうにか作成でき，会計伝票も転記されている。これならなんとかなりそうだと，顧客もSEも何となく安心してしまう。

　このケースでは，ユーザー受入テストの段階で問題が発覚し，慌てるはめになる。実際の業務パターンに準じてテストを実施すると，「消費税の端数処理は複数のパターンがあり，得意先ごとに設定できないといけない」「得意先からの問い合わせ時に，先方の請求書番号での検索ができない」「自動計算の明細が多数あるが，どの計算によるものか見分けがつかない」などの問題が見つかる。

　ささいなパラメータ設定の追加だけで対応できるケースもあるが，影響の大きいパラメータ設定の変更やマスター項目の追加，パッケージの別機能の使用にまで影響が及ぶと，開発済みのプログラムやテスト済みの別の業務にも影響が及ぶ。最悪の場合，開発済みプログラムの修正やシステムテストの再実施にまで発展する。もちろんプロジェクトは大幅な遅延となる。

　実施できて当たり前の「主要プロセス」に終始するうちに，実業務から離れてしまったことが失敗の原因だ。ここにも改善の余地がある。