中小企業のERP選定基準｜導入するか・どの業務から始めるかを決める選定表

ERPの選定で先に決めるのは製品名ではない。自社はERPを使うほど業務間のデータをまとめる必要があるか、導入するならどこから始めるかだ。ここが曖昧なまま機能比較へ進むと、各部門が欲しい機能を足し、経営者だけが最終判断を抱える。

自社の基幹業務の範囲そのものが曖昧なら、先に基幹業務の線引きを行う。この記事では範囲を決めた後の、ERPの採否、対象モジュール、段階導入、責任者の選び方に絞る。

ERPが必要な会社と、個別改善で足りる会社

ERPが効くのは、一つの処理を速くしたいときより、同じ取引を複数部門が別々に持っているときだ。受注内容を販売が入力し、出荷側が打ち直し、経理が請求用にまた入力しているなら、問題は個別画面ではなくデータの受け渡しにある。

「全部を一つにできるから」だけでは採用理由にならない。まとめる価値があるのは、同じ顧客、商品、取引、金額を部門間で受け渡し、その不一致が経営判断を遅らせている場合だ。

モジュールは機能数ではなく、受け渡しで選ぶ

会計、販売、購買、在庫を横に並べ、境目で何を渡しているかを書く。たとえば販売から在庫へは商品・数量・納期、販売から会計へは請求先・金額・計上日が渡る。転記や照合が起きている境目を含む組み合わせが、最初の導入候補になる。

1. 取引の始点と終点を書く。受注から入金までを実際の順番で並べる。
2. 境目の受け渡しを書く。誰が、どの項目を、どの道具へ移しているかを記録する。
3. 確認待ちに印を付ける。社長や管理職の確認がないと進まない場所を特定する。
4. 一緒に変える範囲を決める。境目をまたいで初めて効果が出る組み合わせを選ぶ。

販売管理と受発注の役割が混ざる場合は、販売管理と受発注システムの境目を先に確認すると、取引先との接続までERPに背負わせる誤解を避けられる。

必須要件と「変えられる慣習」を分ける

IPAの「機能要件の合意形成技法」は、発注者と開発者の認識のずれとして、要件の抜け、伝達漏れ、誤認や拡大解釈を挙げ、目的・範囲・制約を伝え、図表でレビューする考え方を示している（IPA公式資料）。ERP選定でも、要求を文章だけで渡さず、判断表にする。

標準機能に業務を合わせられない理由が「慣れているから」だけなら、追加開発の前に手順を変えられないかを見る。変えられない理由を言語化できない要件は、選定表からいったん外す。

段階導入を選ぶための条件

段階導入は、小さく始めれば安全という意味ではない。先行範囲と後続範囲の間で、同じデータを二重管理する期間が生まれる。段階導入を選べるのは、境界で渡す項目、正とするシステム、照合方法、移行完了の条件を決められる場合だ。

• 先行範囲だけでも業務上の効果を確認できる
• 後続システムへ渡す項目と頻度が決まっている
• 顧客・商品・取引先マスタの管理者が一人に決まっている
• 二重入力が残る期間と、終了条件を合意している
• 障害時に旧手順へ戻す判断者が決まっている

移行データの中身は別の論点になる。既存データの品質を確認する方法は移行前のデータ監査に譲り、ERP固有の持ち込み範囲はERPデータ移行の棚卸しで整理する。

デモでは自社の一取引を最後まで通す

製品デモは、用意されたきれいなサンプルを見るだけでは選定材料になりにくい。自社で実際に起きた一取引を匿名化し、受注、変更、出荷、請求、入金まで通してもらう。通常取引だけでなく、数量変更や承認待ちを一つ含めると、標準機能で回る範囲と追加対応が必要な範囲が見える。

デモの評価欄は「できた・できない」だけにしない。誰が入力するか、どの項目を前工程から受け取るか、例外時にどこで止まるか、履歴を誰が確認できるかを書く。画面の使いやすさも、担当者の感想だけでなく、同じ情報の再入力、画面をまたぐ照合、管理職への確認が残るかで見る。

• 取引開始時に必要なマスタと入力項目
• 前工程の確定内容が後工程へ引き継がれる範囲
• 変更・取消・分納などで元情報と履歴がどう残るか
• 承認待ち、差戻し、却下を一覧で追えるか
• 出荷・請求・入金後に訂正する場合の処理
• 障害時に取り出せるデータと代替手順

この実演を複数製品で同じ順番にすれば、説明の上手さではなく、自社業務への適合で比較できる。追加開発が必要と言われた行には、なぜ標準運用へ合わせられないかを記録し、必須要件か慣習かを選定会議で再確認する。

選定会議は論点ごとに決定者を変える

ERP選定を全員合意だけで進めると、誰も反対しない最大公約数か、声の大きい部門の要望へ寄りやすい。業務要件は業務責任者、データの正は管理責任者、投資範囲と段階導入は経営者というように、論点ごとの決定者を選定表へ書く。

決定後は、採用しなかった要望も削除せず「対象外」と理由を残す。稼働準備中に同じ要望が再提出されたとき、前提が変わったのか、単に議論が戻ったのかを区別できる。選定表は製品を決めたら捨てる比較資料ではなく、導入範囲と運用責任を引き継ぐ台帳になる。

最終選定表に入れる項目

製品名を列、次の項目を行に置く。点数だけで決めず、必須要件を満たさない製品は点数計算の前に外す。

• 対象業務と、対象外に残す業務
• 標準機能で回せない例外と、その処理方法
• マスタと取引データの正を置く場所
• 段階導入中の連携と照合方法
• 日常運用、承認、障害対応の責任者
• 導入後に減ったか確かめる転記・照合・確認待ち

最後の行が重要だ。導入の効果を「便利になった」で終わらせず、選定前に数えていた転記、照合、経営者への確認待ちが減ったかで見る。ERPの採否は、機能の多さではなく、部門をまたぐ詰まりを解けるかで決める。

選定表が完成したら、導入対象外の業務も現場へ説明する。対象外を曖昧にすると、稼働準備の途中で「当然入ると思っていた」という認識差が出る。残す手作業、既存システム、連携しないデータについて、当面の担当者と見直す条件を記録する。

製品決定後に組織や商流が変わった場合は、選定時の前提へ戻る。要望を追加する前に、対象業務、受け渡し、必須要件、責任者のどこが変わったかを特定する。前提の変更と単なる追加希望を分ければ、導入範囲が静かに膨らむのを防げる。