ERPパッケージ導入における要件定義の方法と成功のポイント

ERPパッケージ導入の考え方

ERPは「販売管理」「会計管理」「在庫購買管理」「生産管理」「人事給与管理」など業務範囲が広いシステムです。各企業で一からERPを構築しようとすると膨大な工数や費用が必要になるため、自社で構築せずに既に各機能が備わっているパッケージ製品を採用することが一般的です。

ERPパッケージを導入する際の基本的な考え方として、以下の2通りが存在します。

業務をERPパッケージ製品に合わせる

1点目は自社の業務をERPパッケージに合わせる考え方です。この考えであればERPパッケージに対してカスタマイズを加える必要がないため、システム導入費用を抑えることが可能です。一方、業務の流れや運用ルールなどを変更する必要があるため、業務を担当する従業員への影響が考えられます。なお、パッケージ製品に対するカスタマイズは、パッケージ製品に機能を加えることから「アドオン（Add-on）」と呼ばれています。

ERPパッケージ製品を業務に合わせる

ERPパッケージ製品をカスタマイズし、自社業務に合わせる方法もあります。ERPパッケージ製品に対して、システム改修（アドオン開発）を行うことで業務の流れや運用ルールなどを大きく変更することなく運用可能です。しかし、システム導入費用にカスタマイズ費用が加算されるため、費用が高額になる可能性があります。

要件定義とは

要件定義とは、システム開発や導入において、ユーザーの要求をまとめ、これから構築・導入するシステムの仕様やプロジェクトの具体的な進め方を決めることを指します。なお、システム開発の場合、「企画」→「要件定義」→「実装（開発）」→「運用・サービス」という工程順で進みます。

要件定義とフィット&ギャップ分析の違い

システムの導入において要件定義と並んで重要視されている「フィット&ギャップ（Fit＆Gap）分析」。両者はどのような違いがあるのかを説明します。

要件定義は、開発や導入前に行われる「工程（フェーズ）」の一つであるのに対し、フィット&ギャップ分析は要件を明らかにするための「手法」です。

「フィット＆ギャップ分析」とは、通常要件定義フェーズに行われ、パッケージ製品が持つ機能と自社の業務がどの程度あっているのか、もしくはあっていないのかを調査することです。フィット（Fit）は適合、ギャップ（Gap）は乖離度を表します。要件定義における重要な手法です。

要件定義の進め方

パッケージ製品の導入における要件定義は、スクラッチ開発と呼ばれるイチから作るシステム開発とは進め方が異なります。

要件定義の最終的なゴールは、発注会社が提示した「業務要件」及び「要求仕様」をもとに、システム提供会社がシステムに実装すべき機能やその仕様をまとめた「要件定義書」を作成し、その内容について発注会社とシステム提供会社で合意することです。

ここでは、一般的なERPパッケージ導入における要件定義の進め方を解説します。下記の手順は発注側の視点で記載しています。

①業務要件を整理する

要件定義を始める前に、まずは自社の現状の業務を整理し、今後どのような業務フローとするのかを明確にする必要があります。これを「業務要件」と言います。

業務要件をまとめる際、「As Is/To Be」というフレームワークを使用するといいでしょう。「As Is」は現状の状態を、「To Be」は理想の状態を意味します。双方を比較することで、その間にあるギャップや解決すべき問題の分析に役立ちます。

②要求仕様に落とし込む

業務要件を元に、これから導入するERPパッケージに求める機能、どのように業務を回すのか等について「要求仕様」という形でまとめます。

要求仕様を定めずに要件定義自体を行うこと自体は可能ですが、そのような手法を取ってしまうと、システム提供会社への丸投げとなってしまい、自社の意向が正しく伝わらないままに開発が行われる可能性が高くなります。その結果、いざシステムを導入したとしても、「自社の業務にマッチしない」「使いにくい」などといった不都合が生じてしまう恐れがあります。

要求仕様を決めるためには、情報システム部門だけでなく、導入するシステムを利用する部門にも積極的に協力を仰ぎ、意見を反映することが重要です。

③要件定義の打ち合わせを実施

要件定義は打ち合わせ形式で行われます。昨今ではWeb上での会議であることも一般的になっています。導入規模にもよりますが、2～3か月程度の期間、複数回の打ち合わせが行われます。

要件定義の主体者は発注側であり、システム提供会社ではありません。要求仕様をまとめたときと同様、自社の意向が反映されるように打ち合わせを進めることが重要です。

要件定義の打ち合わせでも情報システム部門だけでなく、利用部門にも入ってもらうのがよいでしょう。システムの利用者目線の意見を反映させることで、業務にマッチしたシステムを導入することが可能です。

ERPは業務領域が広いため、各打ち合わせの議題を明確にし、その議題に関係のあるメンバーに絞って実施するのがよいでしょう。例えば、議題を「ERP導入の要件定義」という風に漠然とした形にするのではなく、「人事労務業務における要件定義」に絞ったうえで、自社からの参加者をシステム導入部門とその領域の業務での利用者となる人事部に絞るイメージです。

また、要件定義ではシステム提供会社に自社の業務を正しく理解してもらうことが重要です。現在利用しているシステムや帳票など、実際のデータを用いながら業務の流れ、役割分担を中心に業務を説明します。業務の流れや役割分担が、なぜそのようになっているかの理由や背景などを共有することで、業務への理解がより深まるでしょう。

④フィット＆ギャップ（Fit & Gap）分析

パッケージ製品と自社の業務が完全にマッチすることはほとんどありません。製品と業務のマッチ度を把握するために、パッケージ製品導入における要件定義では「フィット＆ギャップ分析」が必要です。

フィット＆ギャップ分析のやり方はさまざまですが、例えば、自社側で必要とする機能を一覧にまとめ、システム開発会社側で一覧上にある必要機能がパッケージ製品に有しているのか否かを評価します。有する場合は一覧に「○」、ない場合は「×」をつけます。「×」が付いた機能については、前述の「ERP導入の考え方」に記載のとおり、「業務をパッケージ製品に合わせるのか」、それとも「パッケージを業務に合わせるのか」を機能ごとに決めていく必要があります。

Fit&Gap分析の段階では、標準的なパッケージ機能をもとにトライアル運用を行うこともあります。実際に機能や使い勝手を体験し、自社とのマッチ度を判断できるのは、パッケージ製品の大きな優位点と言えるでしょう。

パッケージを業務側に合わせる場合はアドオン開発が必要となり、開発コストが増加するため、費用対効果や予算状況を意識しながら判断するとよいでしょう。

⑤要件定義書のレビュー

自社の要望を汲み取ったうえで、システム開発会社が要件定義書を作成します。要件定義書が提出されたら、内容に対して必ずレビューを行いましょう。レビューを行うことで双方の認識している仕様に認識齟齬がないかどうかを確かめることが可能です。

レビューはシステム導入部門だけでなく、要件定義の打ち合わせに参加した利用部門のメンバーも行いましょう。関係者同士の認識の齟齬を減らし、合意形成を図りながら進められます。

レビューは打ち合わせ形式でも問題はありませんが、限られた時間でシステム開発会社からの口頭説明のみだと、要件定義書を全て確認することが難しいです。自社が望まない形で仕様が解釈されたりすることがあるため、口頭の説明で終わらず時間をかけて要件定義書の内容を細部まで確認しましょう。

要件定義で失敗しないためのポイント

要件定義、ひいてはERP導入を失敗しないために重要なことは以下の3点です。

利用部門の協力を得ながら進める

ERPに限った話ではありませんが、システムを導入する際はシステム導入を担当する部門だけでなく、システムを実際に利用する現場メンバーの協力を得ながら進めることが重要です。

現場の業務を深く理解しているメンバーからの声を反映することで、システムを導入しても現場が本来必要としていた機能が入っていなかったり、既存業務の運用を大きく変更しなければならなかったりなどの問題が発するリスクを抑えることができます。

実際の業務にマッチしないシステムを導入してしまうと、現場からの「使いにくい」「使えない」などといったクレームにつながる可能性もあります。最悪の場合、導入失敗と評価されかねないため、現場の業務を深く理解するメンバーの参画は非常に重要であると言えるでしょう。

システム提供会社任せにしない

システムを導入する際、発注先のシステム提供会社に「丸投げ」してしまうケースが少なくありません。具体的には、要件定義工程で発注側が既存業務を伝えるための資料をあらかじめ用意しなかったり、実現したい機能について全く検討していなかったりするなど、発注側で実施すべきことをやっていないケースです。

システム提供会社に丸投げをしてしまうと、システム提供会社側も発注側の業務を全て理解できるわけではないため、現状のヒアリングに多くの時間を費やしてしまいます。そのため、本来検討すべき内容を詰めることができず、システムに対する要求仕様が固まらなくなる可能性があるでしょう。その状態で導入プロジェクトを進めると、必要な機能が実装されなかったり、業務に合致しない仕様となってしまったりする恐れがあります。それにより業務が不完全な状態での運用となり、せっかくシステムを導入したにも関わらず、システム外で手作業が発生するといった手間がかかり、現場にとって使いづらいものになってしまいます。

仕様が決まっていないものは管理表などにまとめておく

要件定義フェーズの期間中にどうしても仕様が決まらないケースが発生するかもしれません。導入プロジェクトの期間に調整がきく場合は要件定義フェーズを延長するという判断もありますが、場合によっては使用開始時期が決まっているがためにスケジュールを後ろにずらせない状況もあります。

どうしても課題が残った状態で次フェーズに進めないといけない場合は、課題管理表を作成し、決まっていない事項を一覧にして残し、対応担当者と対応期限を定めていくことが重要です。

まとめ

ERPパッケージ導入では特に「要件定義」と「フィット＆ギャップ分析」がポイントです。

要件定義を行うことで、自社に必要なシステムの機能や特性が明らかになります。そのうえで「フィット＆ギャップ分析」を行い、パッケージ製品が持つ機能と自社の業務がどの程度あっているのか、どの程度不足しているかを明確にします。不足している機能に対して、アドオン開発をするのか、または業務のやり方を変えるのか、企業に合った方法を検討していきましょう。