「使われないSaaS」はなぜ増えるのか。自社の業務に合うツールを選び抜く6つの手順

「使われないSaaS」はなぜ増えるのか

新しいシステムを入れたのに、現場は元のExcelを使い続けている。

経営者や推進担当者が良かれと思って導入したツールが、定着せずに放置される光景は珍しくありません。

機能は十分に揃っていたはずだ、と思うかもしれません。

なぜ、使われないSaaSが費用だけを残して増えていくのでしょうか。

その原因は、製品の機能不足ではありません。

選ぶ手順を持たないまま、製品情報から検討を始めていることにあります。

丸バツ表は自社で使うかを教えてくれない

ツール選定で陥りやすい失敗は、大きく3つに分かれます。

• 機能一覧だけで選んでしまう
• 現場を巻き込まずに決めてしまう
• 導入した時点で満足してしまう

一つめは、比較サイトの丸バツ表を見て、機能が多い製品を優れていると感じてしまうことです。

しかし、機能の網羅性は、自社の業務に合うかどうかを保証しません。

二つめにも身に覚えがあるかもしれません。

毎日使う現場の担当者が、導入されて初めて画面を見る状態です。

操作感の違和感から、結局元の手段に戻ってしまいます。

三つめは、運用ルールや教育を設計しないまま導入し、効果測定も行われないケースです。

これらはどれも、製品を見る前に自社の要件を固める手順を飛ばしたことで起きています。

ツール選びを成功させるには、製品を探す前に、自社側の情報を整理しなければなりません。

自社に合うツールを見極める6つの手順

失敗を防ぐためには、課題定義から定着までを6つの段階に分けて進めます。

必須要件が10個を超えると選べない

製品を探し始める前に、まずは自社の現状を書き出します。

業務名、担当者と人数、日次や月次といった頻度、月間の概算工数、現在の手段を整理します。

そのうえで、困りごととその発生頻度、放置した場合の工数や金額への影響を言語化します。

ここで、ツールに求める要件を必須要件と歓迎要件に分けます。

各行は、誰の、どの業務の、何を解決するかという形で書きます。

必須要件が10個を超えてしまうことがあります。

しかし、すべてを満たす製品は存在しません。

本当に必須な要件は、通常3から5個に収まります。

予算上限や、既存の会計ソフトなどとの連携必須条件、セキュリティ要件といった制約も、この段階で明確にしておきます。

機械的に落とし、声の大きい人の好みを排除する

要件が固まったら、候補を広く集めてロングリストを作ります。

比較サイトや同業他社の事例、展示会などから、5から10本ほどの候補を一覧にする作業です。

このとき、広告掲載順の可能性がある比較サイトの情報だけでなく、必ず公式サイトや公式デモ動画などの一次情報で裏を取ります。

ベンダーへ問い合わせる際のコツがあります。

要件を整理した内容の要約を先に渡すことです。

そうすることで、一般的な営業トークではなく、自社の要件に対する具体的な回答が返ってきます。

候補が出揃ったら、次はショートリストと呼ばれる2から3候補へ絞り込みます。

この絞り込みは、感覚で残さず、機械的に行わなければなりません。

必須要件と制約に一つでも合わなければ、その候補は落とします。

必須要件で足切りをしたあとに、歓迎要件で順位を付けます。

この順番を守ることで、声の大きい人の好みで決まってしまう事態を防げます。

落とした候補についても、なぜ選ばなかったのかを記録しておきます。

トライアルは気に入るかを確かめる場ではない

候補を絞ったら、実データと実業務で検証するトライアルに進みます。

とりあえず触ってみるだけの検証では、何も確かめられません。

始める前に、期間、参加者、検証シナリオ、合否基準の4つを決めておく必要があります。

期間は2から4週間を目安とし、開始日と判定日をあらかじめ確定させます。

参加者には、管理者だけでなく現場のユーザーを必ず含めます。

検証シナリオは、通常ケースだけでなく、イレギュラーな例外ケースや月次締めなどの繁忙ケースを用意します。

そして、必須要件を満たしているか、現場の評価点が下限を超えているかといった合否基準を事前に定義します。

後出しで基準を変えてはいけません。

トライアルは、ツールを気に入るかどうかを確かめる場ではありません。

事前に決めた合否基準を満たすかどうかを、事実として確認します。

比較表に根拠を添えて稟議へ進む

トライアルが終われば、その結果をもとに稟議へ進みます。

評価基準を軸にして候補を採点し、比較表を作成します。

得点には必ず、トライアルで確認した事実を根拠メモとして添えます。

印象による採点を防ぐとともに、なぜ他を選ばなかったのかという稟議の説明資料としてそのまま使えます。

料金欄は、初期費用、月額、ユーザー数や件数といった課金単位の内訳形式にします。

料金は変動するため、必ず各社の最新の見積もりで記入します。

稟議を通すためには、現状の工数とコスト、導入後の削減見込み、投資回収の目安を3行のサマリとして添えることも有効です。

並行運用を終わらせて定着させる

契約が完了しても、選定プロセスは終わりません。

入力期限や権限などの運用ルールを定め、現場向けの説明会を実施します。

問い合わせ窓口として、誰に聞けばよいのかも明確にしておきます。

移行の設計で忘れてはならないのが、古い手段との並行期間に区切りをつけることです。

新しいシステムと今までのExcelへの二重入力が常態化すると、現場は疲弊してしまいます。

必ず終了日を宣言し、移行を完了させます。

導入から3ヶ月後に、課題定義で算出した月間工数を再計測し、削減効果を数字で確認して初めて、選定が成功したと言えます。

年に1回は、ログイン率や機能の利用率といった利用状況と、契約プランを棚卸しします。

使われていなければ、縮小や解約も選択肢に入れます。

選定の成否は、契約した日ではなく、3ヶ月後の定着で決まります。

手順を型化して選定の失敗を防ぐ

ツール選びで失敗する原因は、製品そのものではなく、選ぶ手順の不在にあります。

課題定義、情報収集、絞り込み、トライアル、稟議、定着という6つの手順を踏むことで、自社に本当に必要なSaaSを見極めることができます。

この一連のプロセスを社内で実践する際は、各工程で基準を書き留めるフォーマットがあると便利です。

弊社で提供しているホワイトペーパーには、そのまま社内で使える要件整理シート、トライアル設計シート、比較表のテンプレート実物が付属しています。

どのカテゴリのSaaSを選ぶ際にも使える型として、ぜひ選定の実務にお役立てください。