導入目的の明確化

まず現状の課題と将来どのようなことをしていきたいか要望を洗い出し、どの課題、どの要望を実現していくか検討して、自社内でERPの導入目的を明確化します。

1. ‣現状の課題の洗い出し
2. ‣将来どういうことをしていきたいか要望の洗い出し
3. ‣どの課題・どの要望を実現していくか検討

製品・ベンダー選定

目的を明確化したら、ベンダー・製品を選定します。 ベンダー・製品を選定する際は、RFI(情報提供依頼書)及びRFP(提案依頼書)を作成し、ベンダー各社より情報を得て検討します。
RFPには、以下のような情報を記載します。

1. ‣スケジュール
2. ‣予算
3. ‣プロジェクトの体制
4. ‣As-Is・To-Be像
5. ‣スコープ
6. ‣機能要件
7. ‣非機能要件(セキュリティやパフォーマンスなど)

要件定義

要件定義では、選定したベンダーと共に、現状および要件を整理していきます。 SAPはパッケージシステムであるため、ユーザ要件がSAPにフィットするのか、ギャップなのかを整理が必要です。 業務プロセスごとに「SAP標準機能を使う or アドオンを使うなど」 を明確にした業務プロセスフローを作成する必要があります。

設計・開発

設計・開発フェーズでは、要件定義フェーズでギャップとなった業務プロセスで、アドオンで対応するとなった機能に対して、設計・プログラム開発を実施していきます。
設計は、要件定義で明確にした業務要件に合わせて、ベンダーを中心に進めます。
ユーザ企業側はベンダーが作成した設計書をレビューし、機能要件を満たしているか、ロジックに誤りがないか確認します。
レビューが終われば、ベンダー側でプログラム開発を進めます。

テスト

設計・開発が終わると、単体テスト、結合テスト、総合テスト、受入テストを実施し、SAPを利用して問題なく業務できるかテストをします。
単体テスト(ベンダーメイン)
開発フェーズで開発したプログラムの動作確認をします。
単体テストは、ベンダー側のみで確認し、バグがあれば、プログラムを修正します。

結合テスト(ベンダーメイン)
結合テストは、複数のプログラムを結合した状態でそれぞれが設計書通りにきちんと動作するか確認します。
設計書を基にベンダーが事前にどういうテストをするかというテストシナリオを作成し、テストを実施します。
ユーザ企業側は、テストシナリオに抜け漏れがないか、テスト結果をレビューします。

総合テスト(ベンダーメイン)
総合テストでは、要件定義フェーズで作成した業務プロセスフローを頭からお尻まで実施します。
業務プロセスフローをベースにテストシナリオをベンダーが作成し、SAP標準機能・アドオン機能が問題なく実施できるかテストします。
ユーザ企業側は、テストシナリオに抜け漏れがないか、テスト結果をレビューします。

受入テスト(ユーザ－メイン)
総合テストが終われば、ユーザ企業側で受入テストを実施します。
受入テストは、総合テストで使用したテストシナリオや、実際の業務に合わせてSAPを使って問題なく業務できるかをテストします。

リリース・運用

テストが完了後は、システム的に大きなバグが残っていないかを確認します。 テストが完了し、問題なく稼働ができると判断されれば、リリース(本番稼働)をします。

リリースの判断基準は、

1. ‣システム的に大きなバグが残っていないか
2. ‣業務的に運用が回るか

リリース後は、実際に現場ユーザも含め、実業務をSAPでするため、システムの使い方や障害の問い合わせが殺到することが予想されます。
そのため、リリース後2、3カ月はベンダーに残ってもらい、障害対応や問い合わせ対応を実施してもらいます。
またリリース数カ月後に、当初立てた「ERP導入の目的」を実現できているかの振り返り・評価を関係者全員で行います。