【第8回】業務要件定義フェーズの秘訣は何か（後編）

業務要件定義フェーズの位置付け
業務要件定義フェーズは、今後目指す新しい業務を具体化し、それを実現するためのシステム化方針を明確化するとともに、導入対象となるERPと導入ベンダーを選定する重要なフェーズです。

この業務要件定義で、主管部門であるユーザー部門（販売部門、生産部門、調達部門、経理財務部門など）の経理財務部門の目指す姿やプロセスが具体化されます。また、今後導入されるERPも決定されます。したがって、業務要件定義が曖昧だと、次のシステム要件定義で手戻りや開発費用の増大などを招くため、しっかりとしたプロジェクト体制で取り組むことが重要です。

業務要件定義フェーズの進め方
業務要件定義フェーズとしては、現状の業務とシステムを詳細に分析し、課題を整理する現状詳細分析（業務とシステム）、今後の目指す業務を具体化する新業務定義（業務改革施策の具体化）、それを実現する業務要件・システム要件を明確化するシステム化方針策定、導入対象となるERPと導入ベンダーを選定する製品・ベンダー選定があります。

その中で今回は、業務要件定義フェーズの後編として、システム化方針策定と、製品・ベンダー選定を中心に説明いたします。

※上記の進め方は、業務要件定義の後半でERPを選定していますが、昨今では業務要件定義フェーズの前半で候補のERPをいくつか選び、新業務要件の検討と並行して、それらでのFit to Standardの実現性を検証するケースが増えています。こうした並行検証の進め方は別途ご説明します。

システム化方針策定では、基幹システム刷新プロジェクトとしてのシステム化に係わる全体方針を策定します。

システム化目的
プロジェクトとしてのシステム化の全体目的を定めます。
具体的には、グランドデザインで描いた部門としての目指す姿の背景や目的（Why・What）をブラッシュアップし、特にシステム化で実現したい目的（例えば、顧客価値最大化やリードタイム半減など）を決定します。

ここで重要なことは、プロジェクトで実現したい目的とシステム化の目的の関連性を明確にすることです。例えば、グループ全体としての顧客価値最大化のために、グループコンタクトセンターを作り、そのためのシステムとしてグループ統合CRMシステムを導入する場合、グループ統合CRMの導入は手段であり、目的ではありません。得てしてグループ統合CRMの導入が目的化し、その前提の顧客マスタの統合が不十分だったり、コンタクトセンターの設立との時間軸が異なったりするケースもあります。グループ全体として本当に何がやりたいのかを考えて、システム化目的を明確化にすることが重要です。

システム化範囲
プロジェクトとしてのシステム化の範囲を定めます。
システム化対象としては、基幹システムや関連システム、インターフェースサブシステムなどのどこを対象としていくかを決定します。基幹システム刷新に合わせ、関連システムのどこを変更するか、といったことも明確化します。

基幹システムでは、刷新対象となるサブシステムを決定します。ここでは、刷新対象のサブシステムが何か、残置するサブシステムは何かといったことを明確化します。また、今回のプロジェクトがグループ企業を対象とする場合、どこが含まれるか、含まれる場合どのシステムが対象かも決定します。

システム機能配置方針
基幹システムと関連システムでの機能配置方針を定めます。
基幹システム刷新プロジェクトでは、販売管理システム、購買管理システム、生産管理システム、会計システム、人事管理システムなどに関連機能が存在するため、機能配置が問題になることがあります。全てを一つのERPでやる場合を除き、いくつかのシステムを残置するため、残置システムとERPの機能が重複したり、そもそも既存の基幹システムで機能が重複したりしているためです。したがって、それぞれのとの関連性や、将来的な機能拡張や運用保守なども考慮して決定します。

全体システム構成
基幹システムや関連システムを含めて、全体システム構成（ハードウェア、ソフトウェア、ネットワーク）や、システム間連携の方式（API、バッチ処理など）を定めます。
また、システム構成として、オンプレミス、IaaS、PaaS、SaaS等のそれぞれのシステムのインフラ方針も決定します。基幹システムおよび個々のサブシステム、アドオンシステム、インターフェース、周辺システムごとに環境が異なるので、全体像を明確にすることが重要です。

業務機能要件
新業務定義で検討した業務要件（業務改革施策、新業務プロセス）のうち、システム化対象の業務要件を定めます。また、システム化対象の業務要件としては、新業務として必要な新ルール等も合わせて明確化します。

インターフェース要件
今回の対象システムについて、システム間のデータ連携要件を定めます。
システム間のデータ連携方式や、データ連携の種類に応じた個々のデータ連携仕様（データ形式、タイミング、頻度等）を明確化します。

非機能要件
性能、可用性、セキュリティ、保守性、拡張性、運用性といった非機能要件を定めます。
・ 性能（処理速度、同時アクセス数）
・ 可用性（稼働率、障害対応）
・ セキュリティ（アクセス制御、ログ管理）
・ 保守性、拡張性、運用性など

移行・展開方針
既存システムから新システムへの移行方法やデータ移行範囲などの移行方針を定めます。
過去の取引データ（販売データ、購買データ、生産データ、仕訳データ等）の必要性などを考慮し、移行データの範囲を定めます。また、拠点やグループ企業へ展開する場合は、展開方針（展開対象、展開順序、タイミング等）を定めます。

一般的にシステム要件定義フェーズは、特定の製品・サービスであるERPを前提にして行います。
したがって、業務要件定義フェーズでERPならびに導入ベンダーを選定する必要があります。

製品・ベンダー選定では、評価・選定を精緻に行い、自社にとって最適なERPを選定するためにRFP（Request for Proposal：提案依頼書）が作成されます。RFPは予備調査によって選定された数社～10社程度の候補に対して発行されます。ERPベンダーからの提案内容は事前に決められた評価基準によって評価され、その後のプレゼンテーションやデモなどを含めて、最終的なERPと導入ベンダーが決定されるという流れが一般的です。

また、ERPの製品・ベンダー選定は、プロジェクトの成功を左右するものですから、慎重に行わねばなりません。発注側が、導入後のERPの利用イメージを明確に持っているかが、成功・不成功を分けることとなります。このイメージを表現する場が、RFPです。RFPでイメージを表現できても、よいパートナーを選ばなければなりません。これには提案書評価基準が必要です。

RFP作成

RFPはシステム化方針を元に作成します。RFPへの一般的な記載項目は下記となります。

複数社から提案があっても、Apple to Appleで比較可能なRFPを作る必要があります。

提案依頼とベンダー対応

作成したRFPを提案候補のベンダーに発出します。
一般的にRFP発出においては、RFP説明会を開催します。
提案書提出期限までにベンダーからの質問に対しては迅速かつ正確に回答を行い、ベンダーの理解を促すことが、よい提案につながります。また、評価基準を事前に示すことで、提案内容の過不足を防止し、公平な選定を可能にします。

提案内容の評価・選定

ベンダーからの提案書を受領し、提案の書面評価を行います。
製品・ベンダーを適切に選定するためには事前に評価基準を用意することが必要です。
評価基準の一般的な記載事項は下記になりますが、評価基準は定量的であることや評価者間で意見が割れない具体性が必要です。

書面評価を行ったうえで、ベンダーに対しプレゼンテーションやデモを依頼します。
全ベンダーに依頼するか、ベンダーを絞って依頼するかは、ベンダー数や提案内容を考慮して決定します。プレゼンテーションやデモを行った後、さらに質疑応答や書面での質問・回答を行い、評価の適正化を図ることが重要です。

上記を踏まえて、最終的に特定のERPと導入ベンダーを決定します。

プロジェクト計画更新

ERPと導入ベンダーが決定したら、提案された導入作業やスケジュール、体制などを精査し、ベンダーとも協議のうえで導入計画を作成することになります。また、導入計画を元に、次フェーズ以降のプロジェクト計画を更新（精緻化）していきます。プロジェクト計画は、ステアリングコミッティ等での承認といった社内承認手続きに沿って承認を得ます。

今回は、「クラウド時代！ユーザー主導のERP導入とは」として、基幹システム刷新における業務要件定義フェーズの秘訣（後編）をご紹介しました。今後の基幹システム刷新は、情報システム部門やベンダーへ丸投げはできません。ユーザー部門が主導して、ERPを Fit to Standardで導入していくことが成功の秘訣といえます。詳細な Fit to Standard でのERP導入のポイントについては、是非レイヤーズ・コンサルティングにお問い合わせください。