SFA導入の社内承認の通し方｜経営層・財務・IT・現場、各部門を説得する4つの戦略と資料作成術

SFAの導入を検討しているにもかかわらず、稟議がなかなか通らず推進が止まっている状況に直面している担当者は少なくありません。「経営層にROIを説明しても響かない」「IT部門からセキュリティを懸念された」「現場から反発が出て話が前に進まない」といった行き詰まりのパターンは、SFA稟議に固有のものです。この記事では、誰を・どの順番で動かすか、各部門の反論にどう答えるか、稟議書に何を書けば通るか、という3つの問いに実務的な手順で答えます。なお、SFA導入全体の流れについてはSFA導入の進め方で整理しているので、承認後を含む全体像はそちらを参照してください。

SFA稟議が通らない本当の理由

稟議が通らない原因は、「ROIが不明確なまま提案している」「コスト面だけが先行して費用対効果が伝わっていない」「現場の反発が承認者に届いている」のいずれか、あるいは複数が重なっているケースがほとんどです。「SFAは便利です」という定性的な訴求だけでは予算承認は得られません。承認者が「費用に見合う成果が出るか」を判断するための材料が提案書にないからです。

以下では、稟議を止める4つの典型的な原因を整理します。それぞれの対処法は次節以降で説明します。

「ROIが不明確」が最大のブロッカー

承認者が投資判断をする際に必要なのは、削減できる工数・改善できる受注率・増やせる商談数など、変化を裏づける数値です。これらが提案書にない場合、承認者は「効果がありそう」とは思っても「予算を通す根拠」を持てません。

「営業が楽になります」という言い方が典型的な失敗パターンです。承認者の視点では、楽になることが目的ではなく、その先に何が起きるかが問題です。楽になった時間で商談数が増えるのか、受注率が改善するのか、という事業上の変化まで結びつけて語らなければ、ROIの議論に入れません。特に経営層・財務部門は「投資した金額が何倍になって戻ってくるか」を問うため、定性的な訴求だけでは判断の俎上に乗りません。

コストが一人歩きして費用対効果が伝わっていない

初期費用とランニング費用だけが目立ち、「それで何が変わるか」がセットで提示されていないと、承認者の印象はコストの大きさだけに残ります。月額ライセンス費用×ユーザー数×12ヶ月という数字を先に見せると、「高い」という感覚だけが先行します。

TCO（総所有コスト）の考え方を使うと整理しやすくなります。ライセンス費用・導入支援費・運用工数・教育コストの合計が分母で、削減できる工数と改善する売上が分子です。この構造で提示しないと、コストだけが印象に残って費用対効果の議論ができません。

現場の反発が経営層に伝染するパターン

現場の営業担当者が「入力が増える」「また新しいツール」と感じた反応が、経営層の耳に届くことがあります。「現場が嫌がっているなら無理に入れなくていい」という結論を経営層が出すと、稟議は実質的に終わります。

このパターンを防ぐには、経営層へのアプローチより前に、現場への根回しを済ませておく必要があります。現場が「自分たちの課題を解決するために入れる」という理解になっていれば、経営層への伝言内容が変わります。根回しの順序設計は次節で整理します。

「タイミングと根回し不足」で消える稟議

期末・次期予算策定の直前・組織改編直後のタイミングは、新規投資の稟議が通りにくい時期です。期末は既存コストの削減が優先されやすく、予算策定の直前は来期への先送りになりやすく、組織改編直後は担当者が変わっており意思決定者の優先順位が揃っていません。

また、キーマンへの事前の一対一の対話なしに「いきなり会議で提案する」ことも稟議が消える原因です。会議の場で初めて提案を聞いた承認者は、その場では判断を保留します。保留が続くと優先度が下がり、稟議は自然消滅します。「会議で説明した＝伝わった」ではないため、事前の個別アプローチが必要です。

承認ルートを設計する：誰を・どの順番で動かすか

稟議の成否は「誰を最初に動かすか」の順番設計で大きく変わります。「経営層から攻める」と現場の反発で頓挫し、「現場から攻める」と予算権限がないまま時間だけ過ぎる、というジレンマがあります。このジレンマを抜けるには、自社の意思決定構造を先に見極めたうえで、キーマンを特定し、協力者を段階的に形成していく必要があります。なお、SFA推進の体制と役割分担では、承認後の推進組織をどう設計するかを詳しく解説しています。

キーマンの特定：最初に動かすべき1人はどの部門か

最初に動かすべきキーマンは、組織の意思決定構造によって異なります。典型的なパターンは3つです。

• 経営層（トップダウン型の組織） 経営判断が速く、トップが「やる」と言えば下が動く組織では、経営層への先行アプローチが有効です。
• 情報システム部門長（IT予算を持つ組織） システム投資の予算がIT部門に集約されている組織では、IT部門長が事実上のキーマンになります。
• 営業部長（現場の声が強い組織） 「現場が使わないツールは入れない」という文化が根強い組織では、営業部長や現場の責任者を動かすことが優先されます。

自社のキーマンを見極めるうえで機能する問いは、「前回、システム系の投資が承認された経緯はどうだったか」という確認です。誰が最初に動いて、誰が最終的に決裁したかを遡ると、キーマンが特定できます。

キーマンが1人では動かない組織（複数部門の合意が必要な構造）もあります。この場合は「誰が反対すると否決されるか」を逆算し、その人を早期に巻き込む設計をとります。

根回しの順序：現場→中間管理職→経営層 vs 経営層→現場の使い分け

組織タイプによって根回しの順序は変わりますが、どのタイプでも「現場への説明をいつかやる」という前提は共通しています。SFAは現場が使わないと意味がないため、現場の理解と協力は避けられません。

トップダウン型では、経営層に先に当たります。経営層が「やれ」と決めれば現場は動く構造なので、まず経営層への個別アプローチで理解を取り付けます。現場への説明は経営層承認後でも機能しますが、反発を最小化するために事前に情報共有しておくことを推奨します。

ボトムアップ型では、現場ユーザーの賛同を先に固めます。「現場が使いたいと言っている」という状態を作ってから経営層に上げると、「現場の声」が推進力になります。現場の数名に試用版を触らせてフィードバックをもらうことが有効です。

混合型では、中間管理職（営業マネージャー・部長クラス）を最初に動かして橋渡し役にします。中間管理職が「推薦する」という立場になると、経営層への説明も現場への周知も動きやすくなります。

「協力者」を増やす社内巻き込みの実務手順

稟議を通すための社内巻き込みは、会議での説明だけでは不十分です。具体的なアクションとして有効なものを以下に挙げます。

• 競合他社の導入事例を共有する少人数のランチミーティングを設ける
• 現場担当者に試用版を触らせ、「入力が思ったより楽だった」というフィードバックを引き出す
• 社内のインフルエンサー（声が大きい・信頼されているベテラン営業）を早期に味方にする

「反対派」への対応は、口を塞ごうとするよりも懸念を早期に引き出して個別に対処する方が実質的です。稟議の場で初めて反論が出ると議論が止まります。事前に懸念を吸い上げ、資料や説明に盛り込んでおくと、本番の審議が前に進みやすくなります。

部門別説得戦略（4部門×反論と切り返し）

経営層・財務・IT・現場では、それぞれ「何を不安に思っているか」が異なります。同じ資料を全部門に持ち込んでも響きません。財務部門にROIだけ語っても「セキュリティは大丈夫か」と聞かれ、IT部門にセキュリティだけ答えても「運用保守の工数はどうなるか」を問われます。4部門それぞれの典型的な懸念と、それに対応する論点を以下で整理します。

経営層：売上・生産性・競合優位の文脈で語る

経営層が聞きたいのは「この投資で何が変わるか」の一点です。訴求すべき軸は3つあります。

第一の軸は商談数・受注率・単価の改善です。 営業生産性は「商談数×受注率×単価÷工数」で表せます。SFAの導入がこの方程式のどこを改善するかを具体的に示します。例えば、属人化していた商談情報が共有されることで受注率が上がる、AIによるリスク検知で案件の取りこぼしが減る、報告書作成工数が減った分を商談に充てられる、といった因果関係を描きます。

第二の軸は組織の再現性です。 優秀な営業担当者の退職や異動によって顧客情報やノウハウが引き継がれない状態は、人材流動リスクとして経営課題になります。SFAで営業情報やデータを組織に蓄積することで、この再現性リスクを下げられることを伝えます。

第三の軸は競合他社との比較です。 競合他社がSFAを導入済みである場合、導入しないことのコストを外圧として示せます。

注意すべきは「DXのために」「トレンドだから」という文脈です。経営層はトレンドでは動きません。P/Lと商談パイプラインの改善という事業の言葉で語ることが必要です。

数値の作り方は後述の稟議書セクションで説明しますが、骨格を先に示すと、「営業担当者1人が週に何時間を報告・会議準備に使っているか」を計測し、SFA導入後の削減分を試算することが起点になります。

財務部門：TCOとROI計算で先手を打つ

財務部門の典型的な懸念は3点です。費用の総額が不明確であること、SaaSモデルで費用が発生し続けること、使われなかった場合の埋没コストです。

これらに対して先手を打つには、ランニングコストの年間総額（ライセンス費×人数×12ヶ月）を最初から明示することです。「月額いくら」だけを伝えると、財務部門は自分で計算して「年間でこれだけかかる」と認識します。こちらから先に出すことで「隠していた」という印象を避けられます。

ROI計算の骨格は、（削減できる工数×人件費単価）+（増加が見込まれる売上）−（年間コスト）です。このうち工数削減の試算は比較的数値が作りやすく、「月間の報告書作成・会議準備・情報収集にかかる時間×人数×人件費単価×12ヶ月」で試算できます。

「費用対効果が出るまでの期間」を正直に提示することも重要です。導入から定着、効果の可視化まで6ヶ月から12ヶ月程度かかることが多く、最初の半年は入力データの蓄積期間になります。この点を隠すと、半年後に「まだ効果が出ていない」という評価につながります。

根拠のない楽観的な数値は財務部門に見抜かれます。保守的な下限値で示し、「これ以上の効果が出れば上積みになる」という示し方が財務部門には響きます。

IT部門：セキュリティ・既存システム連携・保守負荷に答える

IT部門の懸念は3つに集約されます。データセキュリティとクラウド利用の可否、既存システムとの連携、自社IT担当の運用保守負荷です。

セキュリティについては、選定したSFA製品が取得している認証と実装している対策を事実として提示することが有効です。例えばMazrica Salesのような SFAでは、ISO 27001（ISMS認証）・ISO 27017（クラウドセキュリティ認証）・プライバシーマーク取得、通信のSSL/TLS常時暗号化、IDS/IPS・WAFの導入、SSO・多要素認証対応、IPアドレス制限（Growth以上のプランで対応）、サービス稼働率99.9%以上・国内複数拠点での冗長化といった仕様を持つ製品もあります。IT部門が確認したいチェックリストを事前に把握し、それに対応できる情報を準備することが基本です。

既存システムとの連携については、標準連携の対象（Gmail・Outlook・Slack・Chatwork等）と、iPaaS（Workato・BizteX・Yoomなど）経由であれば1,000以上のアプリと接続できること、またGrowth以上のプランではAPIも利用できることを示すと、「つながらない」という懸念に答えられます。

運用保守負荷については、SaaSモデルのため自社IT担当がインフラ管理をする必要がない点を明確に伝えます。IT担当が行う主な作業はユーザー管理・権限設定の範囲です。

IT部門を「使わせれば終わり」と見なすと協力が得られません。運用体制の設計段階からIT部門を相談相手として巻き込むことで、懸念を持つ側から「自分ごと」として関与する側に変わります。

現場（営業担当者）：入力負荷と「使わされる」懸念を解消する

現場の懸念は3つのパターンに分かれます。「また入力が増える・今のExcelで十分」「管理されたくない・マイクロマネジメントに使われる」「使い方を覚える時間がない」です。

入力負荷の懸念に対しては、「入力が増えるのではなく、入力が楽になる機能がある」という事実を伝えます。例えばMazrica Salesのような SFAでは、名刺OCRスキャンや手書きメモOCRで入力を省力化したり、AIが活動履歴を自動要約して案件情報の更新候補を提案するアシスト機能があるため、「毎回ゼロから入力する」という作業を大きく減らせます。現場が体験するまで信じにくいため、試用機会を作ることが説得より効果的です。

管理への抵抗に対しては、「マネージャーが監視するためではなく、自分の案件リスクを自分で早く察知するための仕組み」という文脈で伝えます。AIが行動リスクや傾向リスクを案件単位で示す機能は、本人にとっても「このままでは受注を取り損なう」という早期警告として機能します。「自分のための機能」として伝えることで、管理ツールというイメージを変えられます。

学習コストの懸念については、直感的なUIを実際に触って確認してもらうことが最も早い解決です。「慣れれば使える」という言い方ではなく、実際に触らせる機会を作ることが説得の代わりになります。

現場への説明を「経営が決めたから使え」という形にすると、使われても入力が形骸化します。「あなたの営業活動が楽になる・成果が出やすくなる」という個人ベネフィットを最初に伝えることが、定着への最初の一歩です。

稟議書・社内資料の構成と書き方

稟議書に盛り込む6つの要素（課題の定量化・解決策・選定理由・費用とROI・リスクと対策・導入スケジュール概要）が揃っていれば、承認者が判断するのに必要な情報はほぼ網羅できます。特に「リスクと対策」を先に書いておくことで、承認者が「問題点は何か」と聞かずに済み、議論が前に進みやすくなります。各要素の書き方と、費用対効果の数値の作り方を本節で説明します。なお、SFA導入スケジュールの立て方では、スケジュール概要に盛り込む工程設計の詳細を確認できます。

稟議書に必須の6要素

稟議書に必ず含めるべき要素は以下の6つです。これらが揃っていると、承認者が自分で判断できる材料が揃います。

• 課題の定量化 現状どんな問題があり、それが数値でどのくらい大きいか（例：週次の集計作業にX時間、受注率Y%、情報共有の遅延による失注件数Z件）
• 解決策の概要 SFAで何ができるか、どの課題がどう解決されるかの対応関係
• 選定理由 他ツールと比較してなぜこのツールを選ぶか（評価基準と比較結果）
• 費用とROI 総コスト（初期費用＋年間ランニング費用）と投資回収期間の試算
• リスクと対策 定着しないリスク・コスト超過リスクへの先手対応
• 導入スケジュール概要 いつから・どの部門で・どのフェーズで進めるか

この6要素のうち「課題の定量化」と「費用とROI」が最も差が出るセクションです。次の項で説明します。

費用対効果（ROI）の計算式と数値の作り方

ROI計算は3ステップで構成します。

ステップ1：削減できる工数を金額換算する

（月間の報告書作成・会議準備・情報収集にかかる工数）×（営業担当者数）×（人件費単価/時間）×12ヶ月

まず現状の工数を計測します。1日単位での計測が難しければ、週単位で「何時間を管理業務に使っているか」を数名にヒアリングするだけでも起点になります。人件費単価は月収を160時間で割った時給換算が一般的です。

ステップ2：増加が見込まれる売上を試算する

（現在の月間商談数）×（SFAで改善が見込まれる受注率の増加幅）×（平均受注単価）

「SFAで受注率が何%改善するか」という数値は、外部の統計を使うよりも自社の現状から「改善の余地」を試算する方が説得力があります。現在の受注率が20%で、案件情報の共有不足による取りこぼしが一定数あると見込まれるなら、その分を改善余地として示せます。

ステップ3：年間コストと比較する

（ライセンス費用×ユーザー数×12ヶ月）＋（導入支援費）＋（社内工数コスト）

ステップ1の削減額＋ステップ2の増収試算がステップ3の総コストを上回るとき、ROIがプラスになります。何ヶ月で回収できるかを「投資回収期間」として提示すると、財務部門への説明が具体的になります。

定量根拠が取れないときの代替フレーム

自社の現状データが不足していて工数や受注率の数値が出せない場合、次の3つのアプローチを代替として使えます。

• 「現状の課題コスト」アプローチ SFAがなければ生じ続けるコストを積算します。引き継ぎ失敗による失注・情報散在による重複対応・報告書作成工数といった「やめられない作業」のコストを積み上げます。
• 「機会損失」アプローチ 現状の商談数・受注率が保守的に改善した場合の上積み額を最低ラインで試算します。「もし受注率が2%改善したら年間でいくらの売上増になるか」という問いは、自社の受注単価と商談数があれば計算できます。
• 「競合比較」アプローチ 競合他社のSFA導入状況を根拠に、「未導入の場合の相対的な劣化」を示します。業界内でSFA活用が進んでいる場合、導入しないことの説明コストが高まります。

いずれのアプローチでも、架空の数値は使いません。自社の現状データ（日報・Excel・既存CRM等から取れる範囲）から積算することが前提です。根拠のない数値は財務部門に見抜かれ、提案全体の信頼を損ないます。

資料に「リスクと対策」を先に書くべき理由

承認者は必ずリスクを聞いてきます。これは稟議のプロセスとしてほぼ不変です。資料に先に書いてあれば「リスクを考えている」という評価になり、後から質問されて答えるより印象が良くなります。

典型的なリスクと対策の書き方は次のとおりです。

• 定着しないリスク 対策として、試験導入で検証する・現場担当者を選定プロセスに参加させる・運用ルールを事前整備する
• コスト超過リスク 対策として、PoC期間を設けて初期費用を最小化する・不要機能を除いたプランから始める
• セキュリティリスク 対策として、セキュリティ認証取得済みの製品を選定する・IT部門と連携した権限設計を行う

リスクを資料に書くと稟議が通りにくくなると思われがちですが、逆です。リスクを隠して承認後に発覚すると信頼を失い、次回以降の稟議にも影響します。「リスクを把握しており、対策を考えている」という姿勢が承認者の安心感につながります。

小さく始めてフルスケールに広げる承認戦略

全社一括の大型稟議が通らない場合、「1部門・数名でのPoC（試験導入）」として予算を小さく切り出す方法が有効です。PoC予算は全社展開の費用の5分の1から10分の1程度に抑えられ、承認ハードルが下がります。成功した試験導入の実績は、全社展開の稟議における最大の説得材料になります。PoC設計のポイント・評価指標の立て方・全社稟議へのつなぎ方を以下で整理します。

PoC・部門試験導入で予算と反発のハードルを下げる

PoC設計の基本は、対象部門・参加人数・期間・評価指標を事前に定義することです。「とりあえず使ってみよう」で始めると、終了時に「なんとなく良かった」という結論しか出ません。

参加者の選定は、最初から全員に使わせようとしないことが原則です。前向きで新しいツールへの適応が早い数名（アーリーアダプターに当たる層）から始め、彼らの声を次のユーザー拡大に使います。

ベンダーに対しては、「無料トライアルの期間」「PoC支援の内容と費用」「試験導入から本契約への移行条件」を事前に確認します。多くのSaaSベンダーはPoC支援を提供しており、これを活用することで試験導入のコストと工数を抑えられます。

PoC承認は通常の稟議より意思決定のラインが低いことが多く、部門長の承認だけで動けるケースがあります。全社稟議を通す前に動ける選択肢として、組織の決裁フローを確認しておく価値があります。SFA要件定義の進め方では、PoC後の本格導入に向けた要件整理の手順も確認できます。

試験導入の成功条件と評価指標の設定

評価指標は定量と定性の両方を設定します。

定量の例として、商談入力の件数・アクション記録率・週次レポート作成時間の変化・受注率（期間が短い場合は参考値として）があります。定性の例として、現場メンバーの使用感アンケート・マネージャーの情報把握状況の変化があります。

失敗パターンは評価指標を決めずに始め、振り返りで「使いにくかった」「慣れるのが大変だった」という定性評価しか出ないケースです。承認者が「良かったのか悪かったのか判断できない」という結論になると、全社展開の稟議に使えません。

評価指標はPoC開始前に承認者と合意しておくことが前提です。「この指標を達成したら全社展開を検討する」という合意を事前に作っておくと、PoC後の全社稟議が前に進みやすくなります。後出しの評価基準は「また別の条件が出てくる」という印象を与え、意思決定が先送りされます。

試験結果を全社展開の稟議につなげる流れ

PoC終了後の報告書に盛り込む内容は、設定した評価指標の達成状況・定性フィードバック・発生した課題と改善策・全社展開の費用とスケジュール案の4点です。

全社稟議では「PoCで検証済み」という実績が最大の説得材料になります。「やってみたらこうだった」という自社のデータは、外部の統計や他社の事例より説得力があります。特に現場担当者の肯定的なフィードバックは、経営層が最も懸念する「定着しないリスク」への反証になります。

全社展開のSFAプロジェクトの進め方については小さく始めるアプローチを、体制設計についてはSFA推進の体制と役割分担も参照してください。

まとめ：承認を得た後にすること

SFA導入の社内承認を通すには、「誰を最初に動かすか」「各部門の懸念に何を答えるか」「稟議書に何を書くか」の3点を整理することが出発点です。

部門ごとの動かし方を端的にまとめると、経営層には売上・生産性・競合優位の文脈で話す、財務部門にはTCOとROI計算で先手を打つ、IT部門にはセキュリティと連携と保守負荷に答える、現場には個人ベネフィットを最初に伝える、という4つの軸になります。稟議書には6要素を揃え、特にリスクと対策を先に書くことで議論を前に進めます。全社一括の大型稟議が通らない場合は、PoC・部門試験導入から始めて実績を作り、全社展開の稟議に使う2段階の戦略をとることが有効です。

承認後の最初のアクションとして、現状の週次工数を1日分だけ記録してみることを推奨します。報告書作成・情報収集・会議準備にかかった時間を合計するだけで、稟議書の「課題の定量化」に使える根拠ができます。大掛かりな調査をしなくても、1週間のログが出発点になります。

承認を得たら、次はベンダー選定と要件定義のステップに移ります。SFAベンダーの選び方と自社導入とSFA要件定義の進め方を参考に、稟議で定義した課題と評価基準を選定・設計に引き継いでください。稟議以外の導入プロセス全体はSFA導入の進め方で確認できます。

よくある質問

Q SFA導入稟議に最低限必要な準備期間はどのくらいですか？

A

部門長レベルの承認であれば2〜4週間程度で準備できます。経営会議への上程が必要な場合は、会議のスケジュールに合わせて逆算すると6〜8週間程度が目安です。キーマンへの個別アプローチ・現状工数の計測・費用試算・選定理由の整理という工程を考えると、最低でも4週間は確保することを推奨します。現状データが揃っていない場合はさらに時間がかかるため、「稟議を上げたい時期」の2〜3ヶ月前から動き始めるのが現実的です。

Q 稟議が一度否決されました。再提案までどのくらい間を置くべきですか？

A

否決の理由によって異なりますが、同じ内容で間を置かずに再提案しても否決される可能性が高いです。否決後にやるべきことは、否決理由を承認者から直接確認し、その論点に対応した形で提案を作り直すことです。「ROIの根拠が弱い」という理由なら工数計測を追加し、「タイミングが悪い」という理由なら次の予算策定サイクルを待ちます。間隔としては最低1〜2ヶ月、根拠データの収集が必要な場合は1四半期程度を目安にする組織が多いです。

Q SFAとCRMを同時に提案すべきか、片方に絞るべきですか？

A

承認ハードルを下げるためには、最初から「SFA/CRM一体型」として提案する方がシンプルです。実務では両機能を統合して扱う形が一般的で、「SFAは営業プロセスを前に進める仕組み、CRMは顧客との長期的な関係を築く仕組み」として同一の基盤上で動かすことが多くなっています。ただし、自社の課題が「受注率の改善（SFA寄り）」か「顧客リピート・LTVの向上（CRM寄り）」かによって訴求の軸が変わります。最初の稟議では自社の優先課題を軸に絞り、反論が出た際に「将来的に両方を使える基盤」という拡張性を補足する形が整理しやすいです。

Q 経営層に「今のExcelで十分では？」と言われました。どう答えますか？

A

Excelで十分かどうかは、「今の規模・今のメンバー・今の課題」に対してであって、組織が変化したときの話ではないことを伝えます。具体的には「引き継ぎが発生したとき」「担当者が複数名になったとき」「数字の集計・報告が毎週必要になったとき」という将来のコストを問いとして投げかけます。また、現状のExcel運用に費やしている週次の集計・転記・修正工数を計算し、「Excelで十分」に見えているのは、その工数を誰かが吸収しているからであることを示します。コストが可視化されていないだけで、すでに十分ではない状態にあることが多いです。

Q 無料トライアルを試してから稟議を上げるべきですか？

A

可能であれば試してから上げることを推奨します。現場担当者に実際に触ってもらうことで、「入力が思ったより楽だった」「案件の見通しがよくなった」というフィードバックが得られ、稟議書の定性根拠として使えます。また、推進担当者自身がツールを理解していると、IT部門・財務部門からの技術的な質問や費用の詳細質問に対して具体的に答えられます。ただし、無料トライアルの期間中に社内の主要メンバーを巻き込む工程を設計しておかないと、期間が終わったあとに「誰も使わなかった」という状態になるため、トライアル設計は先に決めてから開始します。

Q SFAは導入承認後に失敗するケースが多いと聞きます。承認時点でできる対策は？

A

承認時点でできる最大の対策は、稟議書に「定着のための体制」を明記することです。具体的には、社内の推進担当者を誰にするか・現場向けの操作説明をいつ行うか・入力ルールをどう整備するか・3ヶ月後の利用状況をどの指標で確認するかを、スケジュール概要に含めます。承認後に別途検討するのではなく、承認段階でこれらが決まっていると「承認したら終わり」という状態を防げます。また、現場担当者を選定プロセスに参加させていると、承認後の当事者意識が高くなります。詳しくはSFA導入の失敗事例と原因も参照してください。