補助金を前提にすると、判断の軸が「どれだけ受け取れるか」に寄ります。そこから失敗が始まることがあります。
補助金を使えば、同じ予算でもっと良いシステムが入る。それ自体は、確かにそのとおりです。
現場で見てきた落とし穴を、発注する側の立場で整理します。
※ 制度の要件・補助率・対象経費は、年度や公募回によって変わります。具体的な可否は、必ずその回の公募要領で確認してください。ここでは、制度が変わっても共通する考え方を書いています。
落とし穴① 交付決定の前に発注してしまう
多くの補助金には、交付決定前に発注・契約・支払いをしたものは対象外というルールがあります。
これを知らずに、採択の知らせが来た段階で発注してしまう。あるいは、先に発注してしまってから補助金を探す。
この順番を間違えると、どんなに良い計画でも受け取れません。交付決定通知の日付を確認し、それ以降に契約書を交わす。ここだけは絶対に守ってください。
落とし穴② 補助金に合わせて要件が膨らむ
一番多い失敗です。
本来は300万で足りるはずだったものが、「どうせ半分戻ってくるなら」と800万の提案になる。自己負担は400万で、300万より多い。
さらに問題なのは、使わない機能が増えることです。使わない機能にも保守費はかかります。初期費用は補助金で圧縮できても、保守費は毎年全額自社負担です。
判断の順番は、こうです。
- 補助金がなかったとしても、やる価値があるかを先に決める
- その前提で見積を取る
- そのあとで、使える補助金を探す
落とし穴③ 対象外の費用を見落とす
補助の対象は、制度ごとに細かく決まっています。一般に、次のようなものは対象外になりやすい項目です。
- 汎用のパソコンやタブレットなどのハードウェア
- 補助期間を超えた分の保守費・利用料
- 自社内で発生する人件費（データ整備、マスタ登録、テストなど）
特に3つ目。データ移行やマスタ登録を「貴社作業」とされている場合、その工数は補助の外です。見積書の前提条件を読んで、自社の工数を先に見積もってください。
落とし穴④ 実績報告の工数を計算に入れていない
補助金は、採択されたら終わりではありません。
支払いを証明する書類、導入したことを示す証拠、場合によっては効果の報告。この事務に、担当者の時間が実際にかかります。
ここを誰がやるのかを決めずに進めると、稼働直後の一番忙しい時期に、定着支援をすべき人が書類を作っているということになります。
落とし穴⑤ ベンダー選びが「補助金に詳しいか」になる
申請を手伝ってくれることは、確かに助かります。
でも、選ぶべきは自社の業務に合うシステムであって、申請書類が上手な会社ではありません。システムは年単位で使いますが、申請は一度きりです。
補助金の対象ツールに登録されているという理由だけで選択肢を狭めるのは、本末転倒です。
落とし穴⑥ 採択されなかったときの計画がない
補助金には採択率があります。必ず通るものではありません。
落ちたときに「じゃあ今年はやめよう」となるのなら、その投資はもともと必要なかったのかを考え直したほうがいいと思います。
逆に、落ちても規模を縮めてやるつもりなら、その「縮めた版」を先に描いておく。これがあると、採否の結果に振り回されずに進められます。
補助金を使うべき場面
否定的なことばかり書きましたが、使う価値は十分にあります。
- やると決めていた投資の、自己負担を軽くする
- 上位プランに手が届く（同じ自己負担で、将来の拡張に耐える構成にできる）
- 社内の合意形成が早くなる（稟議が通りやすい）
要は、決めたことを安くやるために使うのは正しい。何をやるかを補助金に決めさせるのが間違いです。
まとめ
補助金は、判断の後に使うものです。先に持ち出すと、要件もベンダー選びも、制度の都合に引っ張られます。
「補助金がなくてもやるか」。この一問に答えてから、制度を探してください。
株式会社nullkyotoは、発注する側の立場で、投資判断とベンダー選定の支援を行っています。補助金の可否とは別に、その投資が必要かを一緒に見ます。初回相談は無料です。
IT CONSULTING
コメント