失敗しないERP導入プロジェクトの進め方（導入編）：中堅製造業のためのグローバルERP入門（6）（2/3 ページ）

スクラッチ開発とERPの違い

初期トレーニング

　ERP導入で特徴的なのが、導入工程の最初にERP製品に関するトレーニングを受講することです。ERPの導入では、導入ベンダーがユーザーの要望に合わせてシステムを開発してくれるわけではなく、導入ベンダーとユーザー企業が協力して、ERPの標準機能を業務で活用する方法を考えることになります。従って、ユーザー側も導入するERPの基本的な構造について理解しておく必要があるため、プロジェクトの初期段階でトレーニングを受講します。

　初期トレーニングでは、プロジェクトの主要メンバーを対象に、ERP製品のコンセプトや機能の概要、主要なマスターの構成などについて学びます。1〜4週間程度の期間をかけてトレーニングを受講し、製品の概要について理解した上で、後続の要件定義の作業に着手します。

要件定義（Fit＆Gap分析）

　ERP導入の要件定義では、Fit＆Gap分析と呼ばれる手法が用いられます。スクラッチ開発では、業務要件を実現するために必要なシステム機能を検討・定義して、定義された全てのシステム機能をゼロから開発していきます。一方、ERPでは多くの標準機能があらかじめ用意されているため、適切に製品選定を行っていれば、大部分の業務は標準機能で対応することができます。そのため、業務要件に対してERPの標準機能が「適合（Fit）」するのか、それとも「乖離（かいり）がある（Gap）」のかを検証し、Gapの部分について解決策を検討するような進め方になります。

　ERPは出来合いのパッケージ製品なので、標準機能ベースであれば画面を見ながらシステムの動きを確認することができます。スクラッチ開発では、開発とテストの工程が終わるまでは実物のシステムの動きを確認することができないので、システムが出来上がってからイメージが違うなどの問題が生じることがあります。ERP導入では、Fit＆Gap分析の段階から実際にシステムを動かしながら、処理のイメージを確認することができます。

　ERPは多くの企業で利用できるよう汎用的に設計されているため、導入企業に固有の業務にまで完璧に適合できることはありません。そのため、通常は何らかのGapが発生します。Gapを解消するには、必要な機能を追加開発（「アドオン開発」と呼びます）する方法と、業務運用で回避する方法があります。ここで重要なのは、全てのGapについてアドオン開発を検討するのではなく、メリハリを付けて対応することです。ERPは、一通りの業務を運用できるように機能が構成されています。ある程度の我慢をすれば標準機能でもほとんどの業務は遂行することができます。

　一部の画面では多少、入力効率が落ちたとしても、業務全体から見ればそれほど影響がない場合も多いです。現状の業務を基準に考えるのではなく、その機能が実現することで得られる効果とコストのバランスを考慮する必要があります。多くの部署が毎日使用する機能と、特定の部署が年度末だけ使用する機能では、会社としての重要度が全く異なります。一方で、その会社の競争優位を保つために必須の機能もありますし、それがプロジェクトの目的達成のために必要な機能であれば、アドオン開発を選択することになるでしょう。業界特有の商慣習や法制度に対応するために必須の機能についても、アドオン開発することになると思われます。

　前回の繰り返しになりますが、アドオン開発する機能が多くなればなるほど、開発期間が長くなってコストも膨らみますし、品質的な問題が生じるリスクも高まります。安易にアドオン開発を選択するのではなく、本当に必要な機能なのか、標準機能で代替することができないのかを慎重に見極めた上で判断する必要があります。

構築／導入準備

　要件定義が完了すると、その結果に基づいてシステムを構築します。設計やプログラミングの作業はアドオン開発する部分に限られるので、スクラッチ開発に比べて短期間で済みます。システム構築は導入ベンダーが主体で実施されますが、並行してユーザー企業が主体となり、業務マニュアルの作成やユーザートレーニングの実施、移行用のデータ整備など、システム稼働に向けた各種の準備作業を行うことになります。

　その中でも特に重要になるのが、ユーザーによる検証作業です。ERPでは、標準機能を利用している部分に関しては、基本的な動作は保障されています。従って、各機能が仕様通りに開発されているかを確認するシステム的な検証よりも、構築したシステムを使って業務を遂行できるか、という業務的な視点での検証に力点を置くことになります。また、ERP標準機能に業務を合わせることによって、システム稼働後の新業務が現行業務と大きく変わることも多いので、実際にシステムを利用するユーザー部門によって十分な検証が実施することが、本番稼働後の混乱を避けることにつながります。

　そのため、ユーザー部門から検証に必要な工数を捻出してもらうことが不可欠なのですが、工数が確保できないためにユーザー部門による検証が不十分なまま本番稼働を開始してしまい、大きなトラブルに発展するケースが数多く存在します。そのような状況に陥らないためにも、プロジェクトの開始当初から、いつの時期にどのような作業が発生し、どの程度の要員が必要になるのかを明確にしておき、計画的に検証の工数を確保しておくことが重要になります（図3）。

ユーザー部門のリソースプランの例（クリックで拡大）※出典：スカイライト コンサルティング

本番稼働

　ERPの標準機能を利用していても、マスター登録の不備や入力ミスなどにより、想定通りに動作しないことも結構な頻度で起こります。また、ERPの標準機能に合わせることにより業務が大きく変更になる部分もあるので、稼働直後の新システムに慣れていない段階では、現場が混乱することも考えられます。そのため、最短でも2回目の月次決算が完了する時期（稼働から2.5カ月程度）までは、プロジェクトとしての体制を維持・継続して、エンドユーザーをサポートすることが推奨されます。導入ベンダーにも、提案段階から本番稼働後のサポートまでを対象範囲としてもらいましょう。

　重要なことは、計画段階から要員と費用の両面であらかじめ考慮しておくことです。費用を惜しんで要員を確保しておかない場合、トラブルが発生した場合に現場の混乱が収まらず、ビジネスに支障が出てしまう恐れがあります。