北海道の中小企業が業務システム化を進める時のよくある失敗|8 つのパターン

現状の帳票と業務フローを提示しただけで要件定義フェーズを飛ばしてしまい、デモが上がってきてから「これじゃない」の繰り返し。追加修正の見積が重なり、最初の予算の 1.5〜 2 倍になった。

Excel は人間の判断・暗黙知を前提に動いています。それをシステムに置き換えるには、「何をどう入力し、何をどう計算し、何をいつ誰に出すか」のルール化が必要。これを飛ばすと、作るたびに現場から「違う」が出ます。

発注前に、現場の 1 業務を 1 枚紙にフローとして書き出す。項目名・判断分岐・例外ケース・頻度まで。要件定義フェーズに最低 1 ヶ月は使う前提で予算を組む。

リリースした瞬間に「現場でこんな使い方してないよ」と総スカン。例外処理や緊急時の運用がシステムで想定されておらず、現場は結局 Excel を併用。

経営陣が把握している業務は、ドキュメント化された 60% の「正常系」。残り 40% の「例外対応・差し込み・臨時対応」は現場にしかわかりません。

要件定義フェーズに、現場の中核メンバー 1〜 2 名を必ず入れる。その人の工数も予算に含める。発注先には「経営陣の説明と現場実態にギャップがあるかもしれない」と最初に伝える。

初期費用 50 万円のパッケージを選んだはずが、自社業務に合わせたカスタマイズ見積で+ 400 万円。保守費も比例して上がり、スクラッチ開発と変わらない総額になった。

汎用パッケージは「業界平均の業務フロー」を前提に設計されています。独自ルールが多い業務ほど、カスタマイズでパッケージの原型が崩れ、保守の難易度も上がります。

カスタマイズ率 20% を超えるなら、スクラッチ開発や SaaS 選択を再検討。パッケージ採用時は「自社業務をパッケージの流儀に合わせる」覚悟をセットで持つ。

発注してから半年、ほぼノータッチ。納品デモで「思っていたのと違う」と気づくも、手戻りが大きすぎて予算追加もできず、妥協した状態でリリース。

発注先は、仕様書に書かれたとおりに作ります。仕様書に書かれていないことは「発注先の解釈」で埋められ、そのギャップが納品時に顕在化します。

月 1 回以上の定例と、月末のデモ確認を契約に組み込む。デモで気になった点は「違う」と言う。黙っていると発注先は「問題ない」と判断して進めます。

リリース後、簡易マニュアルだけ配布して導入完了としたら、現場は結局 Excel に戻ってしまった。システムは半年後にほぼ稼働停止。

人は、慣れたやり方を変えるのに大きな心理的抵抗があります。新システムが現行比 10% 便利なだけでは、学習コストに負けて移行しません。

リリース後 1 ヶ月は、現場に「必ずシステムを使う」ルールを設定し、質問対応窓口を用意する。社内に「システム推進担当」を置き、現場からの小さな不満をキャッチして改修サイクルを回す。

受発注・在庫・会計を同時にリリースした途端、エラーで業務停止。原因究明に 3 日かかり、その間は手書きで対応することに。

複数の業務を同時に切り替えると、障害の切り分けが困難になり、ロールバック(元に戻す)が難しくなります。

部門別・業務別に段階的リリース。先行チームで 1〜 2 週間の運用テストを行ってから全社展開。並行稼働期間を 1〜 3 ヶ月設定。

初期開発費 600 万円は補助金で手当てしたが、年間保守料 100 万円の予算を事前に組んでいなかった。翌年の予算確保に経営会議で苦労。

システム投資は「導入費」ではなく「導入費+ 5〜 10 年の保守運用費」で考える必要があります。保守費は一般的に初期費用の年 15〜 20% が目安。

発注前に 5 年合計のトータルコスト(TCO)で見積を取る。経営会議の予算承認も TCO ベースで取り付ける。

10 年分の既存データを新システムに移行したところ、重複・表記ゆれ(「株式会社○○」と「(株)○○」など)が原因で、顧客マスタに同一企業が複数件登録される事態に。

Excel 時代は「人間の判断」で重複を回避していたのが、システム化すると機械的に処理されて露呈します。

データ移行前にクレンジング(表記統一・重複排除)の工程を必ず予算化。移行後 1 ヶ月は目視チェック期間を設ける。