基幹システム・ERP前に社内で確認すべきこと【チェックリスト付き】

基幹システムやERPの検討を始めると、つい製品比較や問い合わせから入りたくなります。ですが、最初にそろえるべきなのは製品名ではありません。比較や相談の前に、少なくとも「①目的・課題」「②対象業務・導入範囲」「③社内体制・意思決定」が仮置きできていないと、話が広がるだけで前に進みにくくなります。

この記事は、基幹システム・ERPの社内初回整理用・問い合わせ前確認用のガイドです。7領域で何を確認すべきかを順番に整理し、読後には「今相談・比較に進めるか」「先に社内整理を優先すべきか」を判断できるようにします。最後の到達点はひとつです。まず1枚サマリーを作るところまで進めてください。

基幹システムやERPの検討を始めると、つい製品比較や問い合わせから入りたくなります。ですが、最初にそろえるべきなのは製品名ではありません。比較や相談の前に、少なくとも「①目的・課題」「②対象業務・導入範囲」「③社内体制・意思決定」が仮置きできていないと、話が広がるだけで前に進みにくくなります。

この記事は、基幹システム・ERPの社内初回整理用・問い合わせ前確認用のガイドです。7領域で何を確認すべきかを順番に整理し、読後には「今相談・比較に進めるか」「先に社内整理を優先すべきか」を判断できるようにします。まずは1枚サマリーを作るところまで進めてください。

比較や問い合わせの前に、まず7領域を整理します。特に「目的・課題」「対象業務・導入範囲」「社内体制・意思決定」の3つを先に仮置きすると、初回相談に進む土台を作りやすくなります。

01Sectionこの記事は「社内初回整理用・問い合わせ前確認用」のチェックリスト

まず前提をそろえます。ここでいう「基幹システム」は、販売・購買・在庫・会計などの基幹業務を支えるシステム群の広い呼び方です。「ERP」は、その中でも財務・販売・調達などの中核業務を共通データで横断的に統合する代表的な考え方として読むと理解しやすいです。定義を厳密に切り分けるより、この記事では比較前整理の共通論点として扱います。ERPの基本像は SAPの解説 が参考になります。

比較や問い合わせの前に社内整理が必要なのは、上流での抜けや曖昧さが後工程の手戻りにつながりやすいからです。IPAの要件定義解説でも、要件定義の前に企画・構想の整理が重要だと説明されています。先に前提をそろえておくほど、初回相談での往復が減り、比較軸もぶれにくくなります。

基幹システムとERPの読み方をそろえる

この記事では、基幹システムとERPを対立概念として扱いません。基幹業務を支える仕組み全般を広く見ながら、その中でERPは「共通データで業務をつなぐ統合型の代表例」として位置づけます。これで十分、比較前整理には入れます。

なぜ比較や問い合わせの前に社内整理が必要か

比較を先に始めると、機能一覧の見比べに流れやすくなります。すると、「何を解決したいのか」「どこまでを対象にするのか」「誰が決めるのか」が曖昧なままになり、提案の前提が各社でずれてしまいます。問い合わせ前に完璧な要件定義は不要ですが、相談の土台になる情報は必要です。

7領域の全体像を先に見る

02Sectionまず最優先で整理するのは「①目的・課題」「②対象業務・導入範囲」「③社内体制・意思決定」

初回相談に進めるかどうかは、要件を完璧に固めたかよりも、目的・範囲・体制などの前提をどこまで言語化できているかで見ます。

7領域すべてが重要ですが、最初から全部を細かく埋める必要はありません。着手順としては、まず「①目的・課題」「②対象業務・導入範囲」「③社内体制・意思決定」を仮置きするのが先です。ここが曖昧だと、現状棚卸しや問い合わせ準備を進めても判断が止まりやすくなります。

最初の3営業日で仮置きしたい項目

最初の数日でよいので、次の3点だけは言葉にしておくのがおすすめです。

• ①目的・課題: なぜ今見直すのか、どの業務で何が困っているのか
• ②対象業務・導入範囲: まずどこを対象にし、何を対象外に置くのか
• ③社内体制・意思決定: 誰が情報を集め、誰が承認し、誰に確認すれば進むのか

相談に進める最低ライン

IPAの要件定義解説では、要件定義の前に企画・構想を整理する重要性が示されています。実務上は、次の判定フローで進行可否を見ておくと判断しやすくなります。

1. 1①目的・課題が言語化できているか

できている → 2へ / できていない → Hold

1. 1②対象業務・導入範囲で、対象業務・対象外業務・後続フェーズ候補を仮置きできるか

できている → 3へ / できていない → Caution

1. 1③社内体制・意思決定で、主担当と承認者が見えているか

見えている → 4へ / 見えていない → Caution

1. 1⑤現行システム・データ・連携で、主要システムと主要データの所在が分かるか

分かる → 5へ / 分からない → Caution

1. 1⑥予算・スケジュールと⑦問い合わせ前準備で、希望時期と相談したい内容を説明できるか

できる → Ready / まだ弱い → Caution

このフローは、初回相談に進めるかどうかの目安です。導入可否や製品適合までを決めるものではありません。完璧な要件定義より、何が決まっていて何が未整理かを言える状態のほうが、初回の会話は進みやすくなります。

先に社内整理を優先したい状態

逆に、次の状態なら先に整理を優先したほうが安全です。

• 何を解決したいのかが「古い」「不便」以上に言語化できない
• 対象部門が未定で、誰が最終判断するかも決まっていない
• 利用中システムやデータの所在がほとんど分からない

03Section①目的・課題は「業務事実」と「成功指標」で整理する

基幹システム・ERPの導入目的は、「便利そう」「統合したい」だけでは比較軸になりません。Microsoftの導入戦略ガイドでも、vision、business drivers、success metrics の整理が重視されています。実務では、目的を業務事実と成功指標につなげておくと、社内説明と初回相談の両方で使いやすくなります。

課題を「業務事実」で書く

課題は印象語ではなく、次の3点で書くと具体化しやすくなります。

• 業務事実: どの部門の、どの業務で、何が起きているか
• 優先順位: 頻度・影響度・緊急度のどれが高いか
• 成功指標: 改善できたかを何で見るか

たとえば「月次締めが遅い」だけでは粗すぎます。代わりに「経理と営業管理でExcel回収後の手修正が毎月発生し、月次締め確定が遅れる」のように書くと、相談相手にも社内関係者にも伝わりやすくなります。

システムで解く課題と運用改善で済む課題を分ける

ここで大切なのは、すべてをシステム課題にしないことです。現行運用をそのまま再現しようとすると、不要なカスタマイズや設計・テストの増加につながりやすいと fit-to-standard の考え方 でも示されています。

切り分けの目安はシンプルです。データの一元化、二重入力の解消、部門横断の整合性確保が必要ならシステム対応寄りです。一方で、承認順や例外ルールが整理されていないだけなら、先に運用改善で済むこともあります。

1枚で説明できる目的整理シートにする

目的整理は、複雑な様式よりも1枚で説明できる形が向いています。最低限、次の列があれば十分です。

• 課題名
• 発生部門
• 対象業務
• 業務事実
• 影響
• 優先順位
• システム対応か運用改善か
• 目標状態
• 仮の成功指標

優先順位は、まず「頻度 × 影響度 × 緊急度」の簡易式で仮置きすれば足ります。成功指標も最初から多くはいりません。月次締め日数、転記回数、在庫差異件数、受注から請求までのリードタイムなど、1つでも置ければ比較の前提がそろいます。

04Section②対象業務・導入範囲は「対象・対象外・後続フェーズ候補」で切る

導入範囲は広げる前に切り分けることが重要です。一括導入と段階導入は優劣ではなく、自社の業務依存や連携複雑度、拠点差異などとの相性で見ます。

対象範囲は、広げるより先に切り分けることが大切です。Microsoftの業務プロセス起点の考え方では、業務プロセスが機能スコープを定義し、対象外も明示して扱うことが勧められています。一次スコープ案では、対象業務・対象外業務・後続フェーズ候補の3つに分けておくと、議論がぶれにくくなります。

対象業務の候補を洗い出す

最初は精密な業務一覧でなくて構いません。たとえば受注、発注、在庫、会計、請求、原価などの大きなくくりで候補を出し、そのうえで「今すぐ扱う」「今回は対象外」「後続フェーズ候補」に置いていきます。ここで利用部門、対象拠点、必須連携先も一緒に仮置きできると、初回相談の前提がかなり整います。

一括導入と段階導入の判断軸で比べる

一括導入と段階導入は、どちらが優れているかではなく、自社条件との相性で考えます。 特に、業務間依存・標準化受容性・連携複雑度・拠点差異・稼働制約の5軸で見ると判断しやすくなります。

fit-to-standard の考え方に沿って見ると、標準へ寄せやすい領域は先に対象化しやすく、差異が大きい領域は後続フェーズ候補に回す判断もしやすくなります。

利用部門・拠点・必須連携を仮置きする

範囲の議論で抜けやすいのが、機能ではなく利用条件です。どの部門が使うのか、何拠点が対象か、会計・物流・EC・BIなど何との連携が必須か。この3点を仮置きしておくと、あとで「対象範囲のつもりだったのに前提に入っていなかった」というずれを減らせます。

05Section③社内体制・意思決定は「誰が集め、誰が決めるか」を先に決める

問い合わせ前に必要なのは、大きなプロジェクト体制図ではありません。最小限でもよいので、誰が情報を集め、誰が承認し、誰に確認すれば進むのかを見える化することです。Microsoftのプロジェクトアプローチでも、顧客側にスコープ、社内リソース、データ品質、UAT、予算、変革管理などの責任があると示されています。体制不足は、外部に相談しただけでは埋まりません。

最低限巻き込む関係者を決める

初回整理の段階で最低限見える化したいのは、次の役割です。

簡易RACIで役割を置く

この段階では、役職名まで厳密でなくて構いません。「主担当は誰か」「承認者は誰か」「業務確認先はどの部門か」「情報システム確認先はどこか」「協力部門はどこか」が一枚で見えれば十分です。 これがあるだけで、初回相談での宿題の持ち帰り先が明確になります。

意見が割れたときの判断軸を持つ

社内で意見が割れたときは、好みではなく次の順で見ます。全社課題への影響が大きいか、法対応や監査対応に関わるか、締め処理や受発注のように止めにくい業務か、現場負荷と定着可能性に無理がないか。この軸があると、議論が「誰の声が大きいか」に寄りにくくなります。

06Section④現行業務・運用 と ⑤現行システム・データ・連携 は分けて棚卸しする

「どう回っているか」と「何で回しているか」を分けると、運用改善の論点とシステム刷新の論点を整理しやすくなります。

現状把握で最も多い失敗は、業務の回し方とシステムの構成を一緒にしてしまうことです。④現行業務・運用は「どう回っているか」、⑤現行システム・データ・連携は「何で回しているか」を見る領域です。ここを分けるだけで、運用改善の論点とシステム刷新の論点が整理しやすくなります。

④現行業務・運用で見るべき項目

④現行業務・運用では、現場がどう業務を回しているかを確認します。標準フローだけでなく、例外処理、締め処理、承認、紙やExcelの介在、帳票の使い方まで見てください。ここで重要なのは、機能名ではなく実務の流れで把握することです。

最低限、業務名、主担当、困りごと、例外処理の4点があれば、現行業務一覧として使えます。業務フロー図がなくても、一覧で始めれば十分です。

⑤現行システム・データ・連携で見るべき項目

⑤現行システム・データ・連携では、利用中システム、主要マスタ、オープントランザクション、主要連携先、残したいシステムを見ます。Microsoftのデータ移行ガイドでは、移行データをマスタデータとオープントランザクションに分けて考える整理が示されています。

あわせて、IPAの合意形成ガイドが挙げる帳票、データモデル、バッチ、外部インタフェースのような論点も早めに確認しておくと、後からの抜け漏れを減らせます。データ移行や検証は終盤だけの作業ではなく、初期から前提を置く必要があります。

見落としやすい論点を先に押さえる

Microsoftのセキュリティガイド や day one priority の考え方でも、権限設計やデータ分類を初期から扱う重要性が示されています。

ここまでの整理を、相談前に使いやすい形へ圧縮すると次のチェックリストになります。

07Section⑥予算・スケジュール と ⑦問い合わせ前準備 は「前提条件」と「持ち物」をそろえる

予算やスケジュールは、数値だけを先に置くと判断を誤りやすくなります。公開情報だけでは、同じ条件での費用比較や期間比較は難しいためです。利用規模、対象範囲、連携要件、支援範囲、社内体制で大きく変わるので、まずは構造で整理します。中小機構の調達準備 でも、情報収集の前にシステム要件や調達要件の下地を持つ重要性が示されています。

費用と期間は「数値」より「構造」で見る

費用は、少なくとも「利用料・ライセンス系」「初期設定・導入支援」「連携開発・追加開発」「データ移行」「テスト・教育」「運用保守」「社内工数」に分けて考えると見通しが立ちやすくなります。製品費用だけでなく、移行や教育、社内側の参加工数まで入れて見ないと、後で不足しやすくなります。

スケジュールも同じです。希望稼働日だけでなく、社内確認、要件・スコープ確認、データ整備、テスト参加、切替準備を含めて考える必要があります。特に、担当者の確保、繁忙期、制度変更、組織改編、現行契約の更新期限は、実行可能性を左右する代表的な社内制約です。

初回相談前の4点パッケージを作る

未整理でも相談できることと、先に仮置きしたいことを分ける

未整理でも相談できるのは、「どこで迷っているか」が言える論点です。たとえば、一括導入と段階導入のどちらが向くか、標準でどこまで吸収できるか、連携や移行の難所がどこにありそうかは、初回相談で詰めやすい論点です。

一方で、先に仮置きしておきたいのは、①目的・課題、②対象業務・導入範囲、③社内体制・意思決定です。ここが空白だと、相談相手も前提を置けず、提案の幅が広がりすぎます。

08Section最後に、自社は今問い合わせや比較に進めるかを判定する

ここまで整理できたら、最後に Ready / Caution / Hold の3段階で現在地を判定します。重要なのは、無理に Ready と判断することではありません。Caution や Hold と出た場合も、次にやることが明確なら十分前進です。

Ready: 今相談に進める状態 / Caution: 未整理論点を明示して相談する状態 / Hold: 先に社内整理を優先する状態

Ready でなくても、Caution なら十分に相談可能です。ただしその場合は、未整理論点を隠さず共有することが前提です。逆に Hold なら、比較を急ぐより、社内整理のほうが先です。

まず作るのは1枚サマリーです。 背景、課題、対象範囲、希望時期、相談したいこと。この5点が1枚にまとまれば、社内打診にも問い合わせにも使える土台になります。