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

システム導入方法論

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

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

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

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

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

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

その中で今回は、ERP導入プロセスの概要（前編）として、「全体構想策定」と「業務要件定義」について概要をご説明します。

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

基幹システム刷新の全体構想（グランドデザイン）策定フェーズは、一般的に基幹システムの主管部門であるユーザー部門の中長期的な目指す姿や、一定のゴールで実現したい要件、そこまでに何をすべきかとその時間軸などを描くフェーズです。基幹システムは、全体構想を実現するための手段（HOW）として位置付けられます。

全体構想は、ユーザー部門の今後の目指す姿と実現したい要件などを描くわけですから、ユーザー部門しか策定できません。また、ERP導入の失敗は、この全体構想が曖昧なまま進めたことによることが少なくありません。
従って、ユーザー部門はしっかりとした体制を作って全体構想を策定することが重要です。

現状業務分析

現状概要分析では、ユーザー部門の現状業務と現状システムの概要を把握し、課題点を把握します。
現状業務概要分析では、ユーザー部門の業務範囲を整理したうえで、業務量分析と業務レベル分析、イキイキ度分析を行い、現状の業務課題を分析します。
現状システム概要分析では、対象となる基幹システムの機能概要（各サブシステム含む）、関連システムの機能概要等を整理します。

目指す姿検討

目指す姿検討では、現状概要分析の課題を踏まえ、ユーザー部門の中長期的な目指す姿を検討します。
会社として中長期的にミッションやビジョンに対して、ユーザー部門の存在意義は何か、どんなミッションを果たすべきか、どんな姿を目指すべきか、大切にすべき価値観は何かなどを検討します。
次に、特定の期限（3年～5年）において、目指す姿を実現するための取り組みテーマや改革施策を明らかにしていきます。

全体ロードマップ策定

全体ロードマップ策定では、目指す姿実現のための取り組みテーマについては、優先順位付けを行い、その優先順位にしたがって、通常3年～5年のロードマップを検討していきます。

プロジェクト計画策定

プロジェクト計画策定では、本格的なプロジェクトとして立ち上げるためのプロジェクト計画を策定します。
次フェーズに進むためには、一般的に社内承認が必要です。プロジェクトの規模等によって承認プロセスが異なるため、各社の社内ルールに則ってプロジェクト計画の承認を得ます。

全体構想フェーズ推進上のポイント

• • 目指す姿を明確化する
    基幹システム刷新プロジェクトで問題となるのは、この目指すべき姿が不明確なまま、HOWであるシステム刷新自体が目的化するケースです。
    一般的に、システムを入れ替えたからといって劇的に生産性が向上するわけではありません。システム投資に見合うだけの効率化効果がだせないため（システム投資はコスト削減だけしか考えない経営者が少なくないのも事実ですが）、何年も刷新が停滞している会社も多く見受けられます。

• • グループ全体最適を考える
    全体構想が、単体の会社のことしか考えていないケースもあります。
    グループ全体の基幹システムをどうすべきかを考えなければならないはずですが、プロジェクトが大きくなることの躊躇から、グループ会社を巻き込めていないケースもあります。

• • 全体俯瞰で検討する
    全体構想策定では、現状業務の分析を行いますが、この分析が網羅的でなかったり、現場の困りごとだけの分析にとどまっていたりするケースもあります。
    現状分析は、目指す姿と現状の姿のギャップ、そのギャップをどう解消するかを検討することが目的ですから、そのことに十分留意して進めることが重要です。

• 部門の壁を超える
  基幹システムには様々な部門が関連します。
  しかし、部門の壁を超えることの躊躇から、自部門領域内にとどまり、抜本的な検討が疎かになっているケースも少なくありません。

以上のように、基幹システム刷新における全体構想策定においては、システム刷新が目的化しないように検討することが重要です。

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

業務要件定義は、ユーザー部門の今後の目指す姿と実現したい要件を、具体的な業務として定義するわけですから、ユーザー部門は現状業務から新業務へなぜ変革しなければいけないかを、現場を含めて腹落ちして検討を進めることが重要です。

現状詳細分析

現状詳細分析では、現状の業務とシステムを詳細に分析し、課題を整理します。
業務要件定義フェーズで重要なのは、現状業務（As-Is）を網羅的に押さえることです。
全体を押さえずに、現在の基幹システムで実施している業務やオペレーション上の課題だけを洗い出し、それが実現できるERPや会計パッケージを選定しているケースもよく見受けられます。このような場合、新しくシステムを刷新したのにもかかわらず、Excel作業に人員が忙殺され続け、ユーザーにとって何もメリットがなく、結果として導入ベンダーを儲けさせただけといった笑えない話もあます。

業務要件定義では、業務全体を棚卸し、全体観の中でどこを変革すればいいのか、その変革のために基幹システムにはどのような要件が備わっているべきかを考える必要があります。

新業務定義（業務改革施策検討）

新業務定義では、全体構想策定フェーズを踏まえ、経理財務業務の高度化や効率化を実現する業務改革施策を具体化し、新業務プロセスとして設計していきます。ERPには様々な製品・サービスがありますが、概ね機能は類似している部分が少なくありません。したがって、基幹システム刷新をFit to Standardで導入するためには、まずはERPの標準機能を理解したうえで、業務要件定義を行うことが必要です。せっかく検討した新しい業務が標準機能で実現できない場合、結果として手戻りが起こるからです。

標準機能を理解したうえでの検討としては、ERPの標準機能に詳しいコンサルタントが当初から参加し、彼らの知見の提供を受けながら業務要件を検討する方法や、いくつかのERPを決めてERPベンダーから情報提供を受けながら業務要件を決めるという方法があります。

システム化方針検討

システム化方針検討では、基幹システム刷新プロジェクトとしてのシステム化に係わる全体方針、例えばシステム化の目的、範囲、システム構成、業務要件、インターフェース要件、非機能要件、スケジュール等を検討します。また、システム化方針においては、システム化の目的や範囲を定めます。販売管理システム、生産管理システム、購買管理システム、会計システム等の機能がそれぞれ関係するため、基幹システムとしてのシステム機能配置も検討します。

その機能配置を前提に、基幹システムにおける各システムのインターフェース要件も検討します。基幹システムに属するシステムが数多く存在している場合、刷新対象と刷新対象外のシステム間でのインターフェース要件が非常に複雑になるので注意してください。特に、スクラッチ開発のシステムが残っている場合、そのシステムに追加開発できない、そのシステムの仕様を誰も知らないといったこともよく見受けられるので、これらの検討は早い段階から取り組む必要があります。

システム化方針では、ユーザーのシステムに対する機能要求事項だけでなく、セキュリティやレスポンス等の非機能要件も検討します。また、新システムにどのように移行していくか（データも含めて）といった移行要件も検討します。

製品・導入ベンダー選定

製品・導入ベンダー選定では、業務要件はRFP（提案依頼書）にまとめます。このRFPを導入ベンダーに発出して提案依頼を行い、各社からの提案を受けます。その提案の中から自社にあったERPを選定します。またこの段階で、導入ベンダーから導入までに費用も出てくる場合もありますが、概算見積もりとして提示されることが一般的です。

次フェーズ移行判定

次フェーズ移行判定では、業務要件定義の完了と次フェーズへの移行を意思決定機関（例えば、ステアリングコミッティ、経営会議等）で審議し、承認します。この移行判定承認を得るためには、ユーザー部門としての現状と目指す姿、そのための取り組み、投資対効果などをしっかり経営層に説明できることが重要です。

今回は、「ユーザー主導のERP導入」として、基幹システム刷新におけるERP導入プロセスの概要（前編）をご紹介いたしました。次回は、 ERP導入プロセスの概要（後編）として、システム要件定義、システム開発、業務運用整備、移行・展開についてご紹介します。

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