SFA導入失敗あるある「データ準備の軽視」
今回は、SFA導入が計画通りに進まず、想定以上のコスト（工数・費用）が発生してしまうケースをご紹介いたします。
おそらく、昨今のSFA構築（主にリプレース）の失敗原因の大半は、「データ準備作業の軽視」にあると言っても過言ではないと考えております。
そこで今回は、その背景・デメリット、そして対策についてご紹介します。
データ準備作業の軽視の背景
感覚値ではありますが、現在のSFA（ローコード・ノーコードツールを含む）の構築作業は、7〜8割が管理画面からの設定ベースで行われており、残りがプログラム開発となっています。そのため、10年以上前と比べて構築自体にかかる工数は格段に少なくなり、結果として期間も短縮されています。
以前は、この構築作業が導入プロジェクトで最も期間を要するタスクだったため、仕様変更・追加による手戻りが、プロジェクト遅延の最大の要因となっていました。私が新卒のころは、項目を1つ追加するだけでも1週間の遅延が発生することもありました。
しかし現在では、途中で仕様変更や追加があったとしても、比較的早く柔軟に対応できるようになっており、手戻りによる遅延のリスクは小さくなっています。
また、データ導入作業に関しても、以前はデータベースに直接データを導入する必要があり、エンジニアによるスクリプトの開発やテストが必要でしたが、現在では、SFAにほぼ100％一括導入機能が備わっており、データさえ準備すれば、誰でも管理画面から導入できるようになっています。そのため、移行スクリプトの開発・テスト作業自体が不要となっています。
一方で、“データ準備”については、データを見ながら都度人の判断が求められるケースが多く、効率化が難しいため、10年前から状況は変わっていません（いわゆるExcel作業ですね）。
データ準備遅延のデメリット
次に、「言わずもがな」ではありますが、“データ準備”の遅延によるデメリットについて、改めて整理いたします。
新たにSFAを導入する場合、たとえ“データ準備”が遅れても、利用者側に大きなデメリットはありません（SFAベンダーやコンサルティング会社にとっては、売上計上が遅れるため影響がありますが）。
その理由は、SFAが業務上必須のツールではない場合、そもそもSFAを使用していなかったことから、導入が遅延しても業務には影響せず、従来の運用がそのまま継続されるためです。
もちろん、たとえば特定の役員の強い意向により「○○年度からSFAを本格活用する」といった方針が定まっている場合、導入遅延によってプロジェクト責任者の評価に影響が出るなど、個人レベルでの損失が生じる可能性はあります。しかし、企業全体として見た場合、たとえ無償期間が終了したとしても、発生する費用は数万円程度にとどまるケースが多く、損失は限定的です。
一方、リプレースの場合は状況が異なります。以下では、リプレースにおける“データ準備”遅延のデメリットを2点に整理してご説明いたします。
不必要な費用が発生する
リプレースプロジェクトの多くは、新旧SFAの二重支払いを回避するため、現行SFAの契約更新時期を考慮してスケジュールが組まれます。そのため、プロジェクトが遅延すると、現行SFAを継続利用せざるを得なくなり、引き続き利用料を支払う必要が生じます。
SFAが月単位で契約延長可能な場合は、追加コストの影響は比較的軽微ですが、契約が年単位での支払いとなっている場合、利用していないシステムにもかかわらず、年間利用料を全額支払わなければならないケースもあります。たとえば、5万円／人・年で100人が利用している場合、500万円の無駄なコストが発生することになります。
作業量が増える
現行SFAは日常的に利用されているため、データは常に追加・変更・削除が行われています。したがって、移行対象データの一部の準備が間に合わず切替を延期した場合、準備が完了していた他のデータについても、その間に変更が加わることになります。その結果、再度データ移行の準備作業が必要となる可能性があります。
データ準備による遅延を防止するためには
我々がご支援する際は、必ず上記のことを予めお伝えします。ただ伝えるだけでは、プロジェクト開始時点では実感が湧かないため、あまり効果がないのが現状です。
そこで、具体的な防止策（絶対検討事項）として提示するのが、下記の二つです。
- 移行対象を“絶対必要”なものだけに絞る。それ以外は旧システムデータとして参照用に別の箱に入れておき、見たければ見てくださいという状態にする。
- 必要なデータも、運用開始時点で移行するデータと、開始後に移行するデータに分ける。
どうしてもリプレースの場合、「誰かが使っているかもしれないから」という理由で、過去のデータをすべて移行する方向に進みがちです。
ただし、過去データをすべて移行するという考えは、例えるなら「もしかしたらその中から宝が見つかるかもしれない」という理由で、ゴミ屋敷化した家の物をそのまま新しい家に持って行くのと同じです。
当然、引っ越し自体にもコストがかかりますし、その“ゴミ”があることにより、新しい物が入れられない、掃除がしたくてもできない、そもそも掃除をする気がなくなる――といったデメリットを考えると、「もしかしたら宝があるかもしれない」という望みは捨てて、まずは必要最低限の状態で引っ越し、足りないものを増やしていく。今度は、増やす際に不要なものを捨てていく体制をつくっていくことが重要だと考えています。
幸い、実際の世界では捨てられない物を一時的に保管するために倉庫を借りると莫大なコストがかかりますが、データの世界では倉庫をつくるのはほぼ無料に近いコストで済むため、システム切り替え時に破棄するのではなく、独立して過去データを保管しておくことが可能です（経験上、その倉庫に置いたデータが使われたことはありませんが）。
このように、必要最低限なものに絞ることで、今回の“データ準備”に必要な工数も難易度も最小化され、プロジェクト遅延リスクも低減されるでしょう。
