新しい基幹システムの話が社内で持ち上がった。そのとき、経営者の集まりで聞いた「システム導入は7割が失敗するらしい」という言葉が頭をよぎる。投資額が大きいだけに、踏み出すのをためらう方は少なくありません。
ただ、怖がって止まる必要はありません。システム導入の成否は、製品の性能より、着手前の意思決定でおおむね決まるからです。
「7割」という数字も、調査ごとに失敗の定義や対象が違うため、うのみにしないほうが安全です。うまくいかない導入に共通するのは、次の3つの要因です。目的が言葉になっていない。現場の業務を変えない前提で始めている。決める人が決めていない。
たとえば失敗の定義を先に書くと、予算超過・稼働遅れ・定着不足のどれを最も避けたいかに順位がつきます（失敗の理由を着手前に消していく進め方）。
着手前に3つを決めておくと、たとえば次のことが変わります。
- 完成の基準があるので、プロジェクトの終わり方が分かる
- 標準に合わせる業務を決め、作り込みが膨らむのを抑えられる
- 部門の意見が割れても、裁定の場で結論が出る
- Odooで進めるなら、版に合わせて運用を誰が持つかを先に決められる
ただし、着手前の整理を進めるうちに、Odooより別の選択肢が合うと分かることもあります。進め方の良い点と負担は、この進め方の良い点と、気をつけることに並べました。
では、経営者は着手前に何を決めておけばよいのか。答えは、3つの要因を裏返した経営者が着手前に決める3つのことにあります。
CommunityとEnterpriseの区別について
機能の比較ではなく、導入の進め方の話です。無料のCommunity版と有償のEnterprise版で運用体制の持ち方がどう変わるかは、Odooの版による違いにまとめました。
「7割が失敗する」という数字の正体
失敗率を示す調査はいくつもあります。ただし、前提が一致していません。
ある調査は「当初予算の超過」を失敗と呼び、別の調査は「稼働の遅れ」を失敗に数えます。「現場が使っていないこと」を失敗とする定義もある、という具合です。
定義が違えば、数字は簡単に動きます。厳しく取れば7割にも8割にもなり、緩く取れば半分以下にもなる。
とはいえ、多くの企業が苦戦している実感は否定できません。
問うべきは「7割が失敗するか」ではなく、「自社は何をもって失敗と呼ぶか」です。これに答えられる会社は、そもそも迷走しにくいのです。
システム導入がうまくいかない3つの要因
現場で起きていることは、次の3つに分けられます。
要因1：目的が言語化されていない
「DXを進めたい」「業務を効率化したい」。この段階で止まったまま動き出すプロジェクトが、少なくありません。
完成の基準がないため、いつまでも終われない。要望は出るたびに追加され、判断材料のないまま作業だけが続きます。
目的が曖昧なプロジェクトは、途中で止まるのではありません。終わり方が分からなくなるのです。
要因2：現場の業務を変えない前提で始めている
「今のやり方は変えずに、システムだけ新しくしたい」。稼働中の業務を止めたくない気持ちは、自然なものです。
ただ、現在のやり方をそのまま再現しようとすると、作り込みが一気に膨らみます。帳票の体裁、承認の順番、例外処理。ひとつずつは小さくても、積み上がれば費用も期間も伸びます。
しかも、そうして作ったものは変更に弱くなる。どこまで標準に合わせるかは、標準機能に合わせる考え方として先に議論しておく価値があります。
要因3：決める人が決めていない
部門ごとに希望が出て、互いに譲らない場面は必ず訪れます。3つの中で、これがいちばん見えにくい要因です。
営業は柔軟さを求め、経理は正確さを求めます。どちらの言い分も正しいため、担当者同士では決着しません。
裁定する人がいないと、プロジェクトは気づかないうちに止まります。会議は開かれているのに結論が出ず、日程だけがずれていく。
経営者が着手前に決める3つのこと
3つの要因は、裏返せば経営者が先に決めるべき項目です。完成の基準、作り込みの線をどこに引くか、最終の裁定者。この3つが空欄のまま始めると、要因1〜3をそのまま踏むことになります。
決めること1：何ができたら成功とするか
後から測れる形で書きます。「月次の締めが翌月の何日までに終わる」「在庫の数量を見るのに現場へ電話しなくて済む」。この粒度まで落とし込みます。
この作業が、要件定義のはじめの一歩です。進め方は要件定義の考え方にまとめました。
決めること2：どこまで標準に合わせ、どこは譲らないか
すべてを標準に合わせる必要はありません。競争力の源になる業務には、手を入れる価値があります。
その一線を先に引いておくことが重要です。線がないと、あらゆる要望が同じ重さで並びます。
目安は、「他社と同じでよい業務」なら標準に寄せることです。「この会社ならではの強み」だけを、作り込みの候補に残します。線の引き方は、どこを標準に合わせ、どこを自社流で残すかで詳しく扱っています。
決めること3：誰が最終的に決めるか
裁定者を1人決め、その名前を開始時に全員へ伝えます。多くの中小企業では、経営者自身が担うのが現実的です。
裁定者の仕事は、詳細を理解することではありません。割れた論点に期限を切って結論を出すことです。この役割が空席だと何が起きるかは、Odoo導入の失敗パターンと回避策でも触れています。
着手してよいかの自己診断
次の5つを、役員会でそのまま確認してみてください。ひとつでも□が残るなら、製品選びより先に埋める価値があります。
- □ 成功の基準を、稼働日ではなく「稼働後にできていること」で書けている
- □ その基準を、後から数字や事実で確かめられる形にしている
- □ 標準に合わせる業務と、作り込みを検討する業務の一覧がある
- □ 裁定者の名前が決まり、関係部門の全員に伝わっている
- □ 裁定者が出る定例の場があり、そこで結論を出すと決めている
Odooで進める場合、版によって何が変わるか（Community版とEnterprise版）
ここまでの3つは、製品を問いません。ただしOdooの場合、無料のCommunity版と有償のEnterprise版で、先に決めるべきことが変わります。
| 観点 | Community版 | Enterprise版 |
|---|---|---|
| ホスティング | 自社で用意する。Odooオンラインは対象外 | Odooオンライン・Odoo.sh・自社サーバーから選べる |
| 保守・障害対応 | 自社または委託先が担う | 公式サポートの対象 |
| バージョンアップ | 自社の判断と作業で行う | サブスクリプションに含まれる |
| 着手前に決めること | 運用体制を誰が持つかを先に決める | 社内の担当範囲を決めておく |
| 認証・権限の仕組み | 基本的な仕組みは共通 | 基本的な仕組みは共通 |
版ごとの対応範囲は、改定されることがあります。導入を検討する段階で、Odoo公式のエディション比較ページで最新の内容をご確認ください。
差が出るのは、機能より運用面です。Community版を選ぶなら、サーバーの面倒を誰が見るかを着手前に決めておく必要があります。
海外拠点や連結決算が視野に入る規模なら、NetSuiteなど上位のERPが合います。要件が複雑なら、SAPも選択肢です。
パッケージに乗らない固有業務が中心なら、AIスクラッチ開発も選択肢の一つです。ただしライセンスが不要でも、開発費と保守費が別途かかります。
失敗の理由を着手前に消していく進め方
ERP導入支援を手がけるベンチャーネットは、製品選びの前に、経営者が着手前に決める3つのことが決まっているかを経営者と一緒に確かめます。進め方は次の4段階です。
- 「失敗」の定義を先に書く：経営者に、この投資で1年後に何が変わっていれば成功かを伺います。予算超過・稼働遅れ・定着不足のうち、どれを最も避けたいかも順位をつけます。
- 3〜5年後の姿から範囲を決める：人数や拠点、取扱商品が今後どう変わるかを伺います。今の業務だけでなく、その姿から逆算して、今回の対象範囲を絞ります。
- 標準機能に合わせられるかを業務ごとに仕分ける：Fit to Standard（標準機能に業務を合わせる考え方）を使います。業務を「合わせる」「作り込みを検討する」に分け、後者が多すぎる場合は、そもそも製品が合っているかを見直します。
- 裁定の場を先に日程に入れる：裁定者と月1回の判断の場を、着手前にカレンダーへ入れます。ERPはIT部門の案件ではなく、経営のプロジェクトだからです。
この過程で、Odooより別の選択肢が合うと分かることもあります。その場合は、合わないことを率直にお伝えする方針です。
この進め方の良い点と、気をつけること
4段階の進め方は、製品選びの前に手間をかけるやり方です。得られることと、先に覚悟しておきたい負担を並べます。
良い点は、次の5つです。
- 終わり方が分かる：完成の基準を後から測れる形で書くので、要望が出るたびに足され続ける状態を避けやすい
- 作り込みが膨らみにくい：業務を「合わせる」「作り込みを検討する」に分け、標準に寄せる業務を先に決める
- 意見が割れても止まりにくい：裁定者と月1回の判断の場を、着手前にカレンダーへ入れておく
- 範囲を絞りやすい：今の業務だけでなく、3〜5年後の姿から逆算して今回の対象範囲を決める
- 合わない製品に早く気づける：作り込みを検討する業務が多すぎれば、製品が合っているかを見直す
気をつけることは、次の4つです。
- 今のやり方を変える業務が出る：標準に寄せる業務では、帳票の体裁や承認の順番を見直すことになる
- 準備に時間がかかる：目的の言語化には、数週間から1か月程度を見込む
- 経営者の時間が要る：裁定者は役職で決めるだけでは働かず、判断の場に出ることが要る
- Community版なら運用体制も決める：サーバーの面倒を誰が見るかを、着手前に決めておく
目的の言語化を急ぐと、後工程で何倍もの時間を使います。負担のうち、とくにつまずきやすい2つは着手前の決めごとでよくある2つの失敗で扱っています。
着手前の決めごとでよくある2つの失敗
失敗1：成功の基準を稼働日そのものにしてしまう
「4月に稼働する」を目標に置くと、稼働した時点で全員の関心が切れます。現場が使いこなせていなくても、予定どおりという扱いになる。
稼働日は通過点です。基準は「稼働してから何ができているか」で書きます。
失敗2：裁定者を役職で決めて、実際には出席しない
「決裁は社長」と紙に書いてあっても、会議に出ていなければ機能しません。判断が要る場面は、たいてい細かい業務の話として現れます。
月1回でよいので、論点を持ち込む場を作る。そして、その場で結論を出すと決めておきます。
今のシステムを入れ替える場面で同じ失敗を繰り返さない進め方は、ERP導入はなぜ失敗するのか｜リプレイスで同じ轍を踏まないための進め方で扱っています。
システム導入の失敗に関するよくある質問
「7割が失敗する」という数字に根拠はないのですか？
根拠のない話ではありません。ただ、調査ごとに失敗の定義と対象が違い、予算超過で測るか定着で測るかで数字は動きます。比率より、自社の基準を書くほうが役に立ちます。
目的を言語化するのに、どのくらい時間をかけるべきですか？
数週間から1か月程度が現実的です。関係者への聞き取りと、経営者の意思決定の両方が要るためです。急ぐと、後工程で何倍もの時間を使います。
裁定者は社長でなければいけませんか？
必須ではありません。ただし、部門をまたいで結論を出せる権限が要ります。権限のない人を立てると、結局そのたびに経営者へ戻ってきます。
小さく始めれば失敗は避けられますか？
範囲を絞るのは有効です。ただ、3つの要因は範囲の大小と関係なく起きます。小さく始める場合も、完成の基準と裁定者は同じように決めておくことが必要です。
システム導入が失敗する主な原因は何ですか？
着手前の意思決定にかかわる3つの要因です。
目的が言語化されていない、現場の業務を変えない前提で始めている、決める人が決めていない、の3つです。どれも製品を問わず起きます。中身はシステム導入がうまくいかない3つの要因で説明しています。
まとめ：システム導入の成否は着手前に決まる
システム導入の成否は、着手前の意思決定でおおむね決まります。
「7割が失敗」という数字は、調査ごとに定義が違うため、うのみにしないほうが安全です。問うべきは比率ではなく、自社が何をもって失敗と呼ぶかです。
目的が言語化されていないと、完成の基準がなく終われません。現状をそのまま再現しようとすると、作り込みが膨らみます。そして裁定者が不在なら、意見が割れた時点でプロジェクトは止まります。
違いを生むのは製品の性能ではなく、着手前に引いた線の有無です。1年後の月例会議で、着手前に書いた成功の基準を読み上げ、一つずつ「できた」「まだ」と印をつけられる。そこに「7割」の数字を気にする人はもういません。
もう少し詳しく知りたい方へ
ベンチャーネットは、ERP導入支援を手がける会社です。NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しているため、特定の製品に偏らない立場でご提案できます。
「着手前に、何をもって成功とするかを言語化したい」という整理から、ご相談を承っています。
関連記事
