【第3回】基幹システム刷新の進め方（後編）

システム導入方法論

システム導入方法論には、ウォーターフォール型とアジャイル型があります。

基幹システム開発はウォーターフォール型がメインなので、ここではウォーターフォール型の導入手法をご紹介します。

※ソフトウェアパッケージやクラウドサービス
ソフトウェアパッケージやクラウドサービスでは、機能の一部をお試しで導入できるものもあります。
例えば、経費精算クラウドサービスなどを一部導入する場合です。このような場合は、厳格な導入方法論に基づかずに導入することもあります。しかし、基幹システムの場合、企業の基本情報であり、かつ内部統制上の要件を満たす必要があるため、しっかりとした導入方法論で推進することを推奨します。

ウォーターフォール型の導入プロセス

ウォーターフォール型では、一般的に下記のプロセスでシステム導入を進めます。

• 全体構想策定フェーズは、主管部門であるユーザー部門の中長期的な目指す姿、一定のゴールで実現したい要件と時間軸などを描きます。
• 業務要件定義フェーズは、今後目指す新しい業務を具体化し、それを実現するためのシステム化方針を明確化するとともに、導入対象となるERPと導入ベンダーを選定します。
• システム要件定義フェーズは、導入対象となるERPを前提に、今後目指す新しい業務プロセスを検証しながら、標準機能設定やアドオン要件などを具体化し、プロジェクト計画を詳細化します。
• システム開発フェーズでは、システム要件定義で決まった要件をシステムとして実装するとともに、システムの品質を確保するための各種テストを行って検証します。
• 業務運用整備フェーズは、新システム稼働前ならびに新システム稼働後の安定した業務運用を支えるために業務運用を具体化、教育等を実施します。
• 移行・展開フェーズは、新システムの導入企業・拠点において、既存システムから新システムへシステムを切り替え、新業務での運用を開始します。

今回は、ERP導入プロセスの概要（後編）として、システム要件定義、システム開発、業務運用整備、移行・展開をご紹介します。

※導入プロセスは、ITベンダーによって独自の方法論があり、用語や内容が異なることがあるため、ベンダーごとに確認が必要です。

システム要件定義フェーズは、導入対象となる製品・サービスを前提に、今後ユーザー部門が目指す新しい業務プロセスを検証しながら、標準機能設定やアドオン要件、インターフェース要件を具体化し、今後のプロジェクトのQCD計画を詳細化するフェーズです。

標準機能検証

標準機能検証では、選定したERPの標準機能で、ユーザー部門の目指す業務要件をどのように実現するかを検討します。

スクラッチ開発では、この段階において製品は見ることができませんが、ERPや会計パッケージの場合、実際に画面や処理プロセス、出力データなどを確認することができます。したがって、ERP導入ではユーザー部門が参加して、実際の製品を使いながら標準機能を確認する実機検証を行うことが一般的です。この実機検証を、デモ、CRP（Conference Room Pilot）、POC（Proof of Concept）、プロトタイプ検証などということがあります。選定したERPや導入ベンダーによって用語や意味が異なることから、どういう言葉を使うかや、その概念は期待していることと同じかを確認することが必要です。

また、この実機検証を有効に行うためには、ユーザー部門が実現したい業務について業務シナリオを作って、そのシナリオに基づいて実際にシステムがどういう振る舞いをするかを確認していくことが重要です。ユーザー部門がこの業務シナリオをしっかり作らず、情報システム部門や導入ベンダーに丸投げして実機検証を行った場合、大きな要件が漏れていたり、期待したことができなかったりするので注意してください。

アドオン開発要件定義

アドオン機能要件定義では、標準機能ではカバーすることができない機能要求に対して、追加開発が必要なアドオン機能を決定し、アドオン機能要件を具体化します。

CRP等を実施した結果、標準機能で対応できない場合、アドオン開発を行うかどうかの検討が必要になります。しかし、Fit to Standardでの導入をするためには、ユーザー部門が主体となってアドオン開発をできるだけ認めない方針で進めることが重要です。例えば、有償支給から無償支給に変えるなど、取引条件を見直すくらいの抜本的な変革を行うことが重要です。私どもの経験でも、なぜそんなことを後生大事に守っているのか不思議に思う慣習も少なくありません。

Fit to Standardによる導入を目指すなら、ユーザー部門はERP導入の責任部署として、TOPや関連部門を巻き込んで聖域なき改革を行い、こうした旧態依然の因習を打破することも重要です。

インターフェース要件定義

インターフェース要件定義では、刷新対象の基幹システムと連携する全ての外部システムとのデータの流れ、形式、タイミングを明確にし、データ連携における要件を具体化します。

インターフェース要件として、どのシステムから、どのデータが、どのような形式で、いつインターフェースされ、そのデータをいつどのようにERPが求める形式に編集し、どうERPに渡すかといったことを具体化していきます。同様にERPから関連システムのインターフェースも具体化します。特に、関連システムが数多く存在している場合、インターフェース開発のボリュームが多くなるため、その開発規模の見積もりも重要になります。

こうしたインターフェースの設計・開発の範囲は、ERPでカバーするシステム範囲が広いほど、小さくなるのが一般的です。また、インターフェースの設計・開発は、関連システムに大きく依存し、ERPの導入ベンダーの支援範囲外になるため、一般的に自社の情報システム部門が行います。

プロジェクト計画更新

システム要件定義の結果として、プロジェクト計画を更新します。

システム要件定義が完了すると、ERPの導入ベンダーから導入費用の提案がでます。導入費用の内訳は、ライセンス、システム開発費用、保守費用等などがあります。また、ベンダーからの見積もりが当初の想定開発費を超える場合には、要求機能の一部を削減するといった調整もこの段階で行います。

システム要件定義の完了と次フェーズへの移行を意思決定機関（例えば、ステアリングコミッティ、経営会議等）で審議し、承認します。特に Fit to Standardでの導入の場合、アドオン開発は経営層からその必要性の説明を求められるため、ユーザー部門はしっかりとした根拠提示することが必要です。

システム環境構築

システム環境構築では、主に選定したERPについて、システム要件定義としての実機検証ができるようにシステム環境を構築します。

また、システム開発フェーズにおける開発環境、テスト環境、本番環境などの構築準備を行います。
これらの環境は、ERP・会計パッケージ環境、アドオン環境、インターフェース環境ごとに用意する場合があるので、情報システム部門や導入ベンダーと連携して進めます。

システム開発フェーズは、システム要件定義で決まった要件をシステムとして実装するとともに、システムの品質を確保するための各種テストを行い、それらを検証するフェーズです。システム開発フェーズは、情報システム部門と導入ベンダーが中心となって進めますが、ユーザー部門としても、しっかりとしたQCD管理を行うことが重要です。

標準機能設定

標準機能設計では、ERPにおいて最終化されたシステムフロー等をベースに、標準機能に対して設定するパラメーター設定や、マスタ設定などの標準機能設計書（パラメーター設計書など）を作成するとともに、実際にERPへの設定を行いながら、システムの動作をチューニングしていきます。

アドオン設計

アドオン設計では、アドオン要件に関する基本設計（画面や帳票などを具体的に決める）や、詳細設計（システムへの実装方法を決める）を行います。

インターフェース（IF）設計

インターフェース設計では、インターフェース要件に関する（処理や編集などを具体的に決める）詳細設計（システムへの実装方法を決める）を行います。

開発テスト

開発テストでは、ERPの標準機能設計書、アドオンやインターフェースのアドオン・インターフェース詳細設計書に基づいてシステムに実装するとともに、システムの品質を確保するための単体テスト、結合テスト、システムテストを行います。

※開発テストの種類
開発テストは、一般的に単体テスト、結合テスト、システムテスト、ユーザー受入テストがあります。

1. 単体テスト
個々の機能やプログラムが仕様どおりに動作するかを確認。
2. 結合テスト
複数の機能やモジュールが連携して正しく動作するかを検証。
3. システムテスト
システム全体としての動作確認と、業務フローに沿ったテストを実施。
4. ユーザー受入テスト（UAT）
実際のユーザーが業務シナリオに基づき操作し、要件が満たされているかを確認。

また、導入ベンダーが主体的に行うのはシステムテストまでです。UATはユーザーが主体的に行うため、ここでは業務運用整備フェーズとして扱います。

システム環境構築

開発フェーズのシステム環境構築では、開発環境、テスト環境（結合テスト環境、システムテスト環境、業務運用テスト環境）、本番環境を準備します。

業務運用整備フェーズは、新システム稼働前ならびに新システム稼働後の安定した業務運用を支えるためのフェーズであり、基本的にユーザー部門が主体的に進めます。

業務改革推進（ルール・プロセス・組織の変革）

業務改革推進では、ユーザー部門が全体構想で策定した目指す姿を実現するために、業務要件定義フェーズで検討した業務改革施策を具体化し、実行していきます。例えば、調達リードタイムを短縮するために、取引先との取引条件（MOQ、発注タイミング、納入タイミング、リードタイム等）を見直す場合、新しい取引ルールの制定、取引先への説明、取引先との基本契約の変更などをユーザー部門は行う必要があります。システム稼働後におけるルール・プロセス・組織などに係わる業務改革施策を具体化し、実行に移すだけではなく、システム稼働前であっても実行できる施策は準備して実行していきます。

業務運用設計（業務マニュアル・手順書等の整備）

業務運用設計では、ユーザー部門が新システムを前提として行う業務を具体的に設計します。
ユーザー部門は業務運用設計において、新システムを直接操作する業務だけでなく、その周辺の業務についても含めて具体的に設計し、業務マニュアル等に体系的にまとめることが重要です。

マスタ定義

マスタ定義では、既存システムから新システムへの移行の際に、新たに各種マスタを定義する必要があります。こうしたマスタ定義は、マスタの主管部門であるユーザー部門が行います。ERP導入においては、特に品目マスタやBOMなどが問題になります。従来の体系とERPが標準機能で持つ体系が異なるからです。こうしたマスタ定義は非常に時間がかかることから、早めに検討を行うことが重要です。また、グループで共通したERPを導入する場合、グループで品目マスタやBOM、取引先マスタ、勘定科目マスタなどを統一することも必要になってきます。

ユーザー教育

ユーザー教育は、新システムの円滑な導入と安定稼働を支えるために、新システムのユーザーに必要な知識・技能を習得させる重要な活動です。ユーザー教育は、ユーザーのタイプに応じて、座学や実機研修などを含めた教育プログラムを作成し、計画的に実施していきます。ユーザー教育は、ERP導入の主管部門であるユーザー部門が、教育計画、準備、実施をしっかり行い、導入時の混乱をできるだけ少なくすることが重要です。

業務運用テスト

業務運用テスト（ユーザー受入テスト：UAT：User Acceptance Test）は、開発されたシステムがユーザーの業務要件や期待に合致しているかを確認する最終段階のテストです。業務運用テストは、実際の業務をイメージした業務シナリオに基づき、ユーザー部門が中心となって実施していきます。

移行・展開フェーズは、新システムの導入企業・拠点において、旧システムから新システムへシステムを切り替え、新業務での運用を開始するフェーズです。

移行

移行には、新しい業務（ルール・プロセス・組織）とシステム移行に方針や計画を策定する移行計画策定、既存システムから新システムへの切り替え手順をまとめた移行手順書作成、既存システムから新システムへのデータ移行等を効率的に進めるための移行ツール開発、新システムへの移行を模擬的に試行する移行リハーサル、新しい業務（ルール・プロセス・組織）とシステムに移行する本番移行があります。

基幹システムには、各種の取引データ（発注、発注残、検収、受注、受注残、出荷等）があります。
これらを既存システムから新システムにどのように移行するかが問題になります。例えば、今後の取引にかかわる発注残データや、受注残データだけ移行するといったことです。移行については、ERPで条件や制約があるため、詳細な確認が必要です。

また移行においては、実際に新システムに移行するデータを用意し、既存システムから新システムへの切り替え手順を具体的に決め、本番前に何回かリハーサルすることが一般的です。特に、関連システムが多い場合、「基幹システム→関連システム」と「関連システム→基幹システム」について、タイミングやデータ形式等が異なるため、入念なリハーサルを行うことが重要です。ユーザー部門は、データ移行の範囲決定、移行データ準備、移行などに主体的に参画することが重要です。

展開

展開とは、システムを複数拠点に導入することをいいます。生産管理システムの導入などでは、工場ごとにタイミングを変えて導入することがありますが、全社一括で導入することもあります。また、ERPを複数のグループ会社に展開する場合には、どのように展開していくのかを展開計画として策定し、順次導入していく必要があります。こうしたERPの展開は、ユーザー部門の目指す姿を実現するためにどうすべきかを、ユーザー部門が主体となって検討していくことが重要です。

今回は、「ユーザー主導のERP導入」として、基幹システム刷新におけるERP導入プロセスの概要（後編）をご紹介いたしました。次回以降、ERP導入プロセスにおけるそれぞれのフェーズの内容とポイントをご紹介します。

今後の基幹システム刷新は、情報システム部門やベンダーへ丸投げはできません。ユーザー部門が主導して、ERPを Fit to Standard導入していくことが成功の秘訣といえます。詳細な Fit to Standard でのERP導入のポイントについては、是非レイヤーズ・コンサルティングにお問い合わせください。