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

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

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

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

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

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

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

システム化目的

プロジェクトとしてのシステム化の全体目的を定めます。
具体的には、グランデザインで描いた経理財務部門としての目指す姿の背景や目的（Why・What）をブラッシュアップし、特にシステム化で実現したい目的（例えば、意思決定の高度化、ガバナンス強化、業務の生産性向上など）を決定します。

ここで重要なことは、プロジェクトで実現したい目的とシステム化の目的の関連性を明確にすることです。例えば、グループ全体としての経理財務部門の生産性向上のために、グループシェアードサービスセンター（SSC）を作り、そのためのシステムとしてグループ共通会計システムを導入する場合、グループ共通会計システムの導入は手段であり、目的ではありません。

得てしてグループ共通会計システムの導入が目的化し、その前提の会計ルールや勘定科目の統一が不十分だったり、SSCの設立との時間軸が異なったりするケースもあります。グループ経理財務部門として本当になにがやりたいのかを考えて、システム化目的を明確化にすることが重要です。

システム化範囲

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

会計システムでは、刷新対象となるサブシステムを決定します。ここでは、刷新対象のサブシステムが何か、残置するサブシステムは何か、といったことを明確化します。

また、今回のプロジェクトがグループ企業を対象とする場合、どこが含まれるか、含まれる場合どのシステムが対象か、についても決定します。

システム機能配置方針

会計システムと関連システムでの機能配置方針を定めます。
会計システム刷新プロジェクトでは、債権管理、債務管理、原価管理、固定資産管理、経費管理などの機能配置が問題になることが多くあります。販売管理システム、購買管理システム、生産管理システム、設備予算管理システムなどとの関連性や、将来的な機能拡張や運用保守なども考慮して決定します。

全体システム構成

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

業務機能要件

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

インターフェース要件

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

非機能要件

性能、可用性、セキュリティ、保守性、拡張性、運用性といった非機能要件を定めます。

• 性能（処理速度、同時アクセス数）
• 可用性（稼働率、障害対応）
• セキュリティ（アクセス制御、ログ管理）
• 保守性、拡張性、運用性など

移行・展開方針

旧システムから新システムへの移行方法やデータ移行範囲などの移行方針を定めます。
過去の会計データ（仕訳データ、残高データ等）の必要性等を考慮し、移行データの範囲を定めます。
また、拠点やグループ企業へ展開は、展開方針（展開対象、展開順序、タイミング等）を定めます。

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

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

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

RFP作成

RFPはシステム化方針を元に作成します。RFPへの一般的な記載項目は下記となります。
複数社から提案があっても、Apple to Appleで比較可能なRFPを作る必要があります。

提案依頼とベンダー対応

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

提案内容の評価・選定

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

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

上記を踏まえて、最終的に特定のERPや会計パッケージと導入ベンダーを決定します。

プロジェクト計画更新

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

今回は、ERPや会計システムパッケージによる「会計システム刷新」のキホンのキ、として、会計システム刷新における業務要件定義フェーズの秘訣（後編）についてご紹介いたしました。業務要件定義フェーズは、全体構想策定フェーズで検討した目指す姿を具体的な業務プロセスに落とし込んでいく重要なフェーズです。具体的なご説明や他社事例のご紹介も可能ですので、ご興味をお持ちでしたら是非レイヤーズ・コンサルティングにお問い合わせください。