基幹システム刷新の道のり：1,000名以上の企業での課題と解決策

どんな記事か

私は現在、株式会社リンクアンドモチベーションで全社CRMシステムの再構築プロジェクトのPMをやっており、今年10月から要件定義をベンダーと開始しています。

この要件定義開始までこぎつけるのに丸一年（予算獲得7ヶ月、ベンダー選定&開始準備4ヶ月）かかったのですが、
従業員1000名以上の複数の事業体と数社のグループ会社を抱える企業において、基幹システムを刷新するために、どのようなプロセスを辿ってプロジェクト開始に至ったのかをまとめたいと思います。

同じようなプロジェクトを社内で担当される方の参考に少しでもなれば幸いです。

プロジェクト発足の背景

2022年時の弊社の状況

弊社は2006年からCRMを利用しており、過去15年の間でM&Aによる事業拡大、新規プロダクト開発のたびにスクラッチ開発を繰り返しながら基幹システムとして拡大させてきました。
営業・顧客管理以外にも、請求管理、購買管理、社内の各種申請管理などスクラッチ開発を重ねることで、CRMとしてよりもERPに近いものとして利用していました。

上記CRM環境では、実は商談管理はできておらず、2018年頃から一部事業の営業管理のために改善を進め、一定の効果を得ていました。

全社基幹システム刷新プロジェクトの発足

一部事業での商談管理による成果創出を見て、他事業の方からも商談管理を利用したいという声が上がってきたのですが、
利用事業が活用しやすいようにカスタマイズして利用してしまっており、他事業では利用が難しい状態になっていました。
加えて、基幹システムとして利用している環境も一部のオブジェクトでカスタマイズ利用できる項目数が上限値ギリギリまできており、このままでは数年以内に立ち行かなくなりそうだという懸念もあったため、商談管理機能だけでなく、基幹システム全体の刷新を検討する運びとなりました。

詳細は省きますが、プロジェクトを通して解決したい課題を整理すると下記になります。

プロジェクト予算獲得に向けたROI検討

上記のような背景で立ち上げたため、プロジェクトとしての全体方針をFit to Standard（標準機能中心に構築することで、拡張性のあるシステムとする）
としました。

とはいえ、現環境は長年のカスタマイズにより、CRMとしての営業管理だけでなく、購買管理や請求管理などの会計システムとしての役割や社内申請管理としてのワークフローシステムとしての役割なども持っているため、標準機能で実現するためにはCRMだけでなく、会計システムやワークフローシステムなども検討する必要があります。

必然的に大規模改修になり、金額も多額になることが想定されるため、まずはプロジェクト予算の獲得に向けて、ROIの試算をすることから始めました。

Returnの試算

Returnの試算をする上では、定量効果を確実性の高い「固定」と不確実性の高い「変動」に分けて試算することにしました。

変動Returnである受注率向上については、先にCRMにて商談管理を行っていた事業がシステム導入前後で商談化以降の受注率がどれだけ向上したかをもとに、他事業が同様に改善した場合にどれだけの利益が出るかの試算しました。

固定Returnとした業務工数の削減については、社内の各部署にヒアリングをすることで業務プロセス上のどこに時間がかかっており、システムを刷新することで削減できる工数を時間をかけて整理しました。
また、削減した工数分で付加価値の高い業務を行うことができるようになるため、「削減工数×時給」ではなく、「削減工数 × 付加価値労働生産性」で金額換算しました。
※付加価値労働生産性 = 粗利 ÷ 対象社員数 ÷ 平均労働時間/日

Investmentの試算

Investmentの試算については、現環境を構成する各機能に合わせて、CRM、ERP、ワークフロー、DWHそれぞれのベンダーに問い合わせて、見積もり出してもらうことにしました。

しかし、各ベンダーに声をかけてみて分かったのは、「要件が曖昧すぎて、見積もりができない」ということでした。

プロジェクトメンバーは私含めて全員、この規模のプロジェクトを経験したことがなく、RFIやRFPはどこまで書けばよいのかわかっていませんでした。

各ベンダーと打ち合わせをさせていただく中で、ある程度の正確性をもって見積もりをしてもらうためには、「システム構成」「機能一覧」「インターフェース一覧」あたりを整理しなければならないことがわかりました。

弊社内のリソースのみでは十分な情報を整理することも難しいと判断し、RFPを作成するにあたる情報整理を概要要件定義フェーズとして、コンサル会社に発注することになりました。

<概要要件定義>
ベンダーから見積もりを提示してもらうために、概要要件定義で作成したものは下記です。

1. AsIs業務プロセス/フロー
機能一覧を作成するための前提情報として、システムが関連する業務プロセス/フローを整理。
詳細は画像を参照。

出典

出典

2.機能配置図
業務プロセスのL2レベルでどの機能がどのシステムに配置されることになるかのAsIs/ToBeを図解する。
発注者-ベンダー間で認識が揃いやすくなり、機能一覧の抜け漏れの確認としても利用できる。

3. 機能一覧
L1-L2-L3レベルで業務プロセスのAsIs/ToBeを整理する。
ベンダーが見積もりをする上で、機能一覧の各機能ごとにベンダーに下記を回答してもらう。
・「標準」「開発」のどちらで対応可能か
・概算工数見積もり（大中小でそれぞれ1人月/0.5人月/0.25人月で評価）

4. インターフェース一覧
システム間のデータ連携が必要なものについて、FROM-TOで下記を整理
・連携データの概要
・データ種別
・トリガー
・連携頻度
・データ量　など

ROI試算をもとに、スコープを調整

概要要件定義を通して、CRM・ERP・ワークフロー・DWHベンダーから見積もりをそれぞれ提示してもらった結果、下記が判明しました。

・プロジェクトの複雑性が高く、プロジェクトマネジメントをするコンサル会社への高額な発注が必要
・Returnの大半はCRMリプレイスで実現可能で、ERP・ワークフロー・DWHは費用対効果が怪しい

そのため、プロジェクトスコープをCRM刷新のみに絞って、他システムについては初期スコープ外として、ROIを整理。

経営会議での予算申請をすることで、無事予算獲得をすることができ、検討開始から約8ヶ月を経てプロジェクトを正式にスタートすることとなりました。

最後に

今回は全社の基幹システムのリプレイスをするにあたって、どのようにプロジェクト予算を獲得したのかまでのプロセスをざっくりご紹介させていただきました。
類似したプロジェクトを進める誰かの参考に少しでもなれば幸いです。

また、今回は省略しましたが実際に承認を得る上では、関係役員の早期巻き込み、経営会議前に主要役員へ説明をしてフィードバックをもらったりと予算獲得までには多くの工夫が必要ですので、そのあたりは各社の事情に合わせていただければと思います。

予算獲得後にはベンダーの選定、要件定義開始前に社内で準備すべきこと、要件定義の進め方など、実現までの壁はまだまだありますが、プロジェクトが一区切りつくころにまたまとめられればと思います。