ERPのデモで何を確認するか｜業務シナリオと質問の作り方
KXSfourthERPのデモは、画面の印象を比べる場ではなく、自社の重要な業務がどう成立するかを確認する場です。ベンダーごとに異なる得意な場面だけを見ると、製品の差を判断しにくくなります。本記事では、共通シナリオの作り方と、実演で確かめるポイントを説明します。
この記事の要点
- 共通の業務シナリオを使い、通常処理と重要な例外を確認する
- 標準機能・設定・追加開発・模擬画面を区別して記録する
- デモで未確認の条件を、検証や契約前の確認へ引き継ぐ
Agenda（この記事の内容）
デモの目的と限界を理解する
デモで確認できるのは、用意された環境とデータでの動作です。本番の処理量、すべての権限、連携、移行データの品質まで証明されるわけではありません。実演で見る項目と、資料・検証で確認する項目を分けます。
特に、標準機能を実演しているのか、事前に作った追加機能なのか、将来の実装イメージなのかを明確にします。同じ見た目でも、費用と導入リスクは違います。録画や画面画像だけで動作確認済みと扱わないことが大切です。
目的は「使えそう」という感想を得ることではなく、要件の実現方法、操作の負担、制約、不明点を残すことです。評価表と要件番号を対応させ、結果を後から追えるようにします。
共通シナリオを作る
シナリオには、開始条件、担当者、入力、処理、期待する結果を記載します。例えば受注登録から出荷、請求、入金確認まで、部門をまたぐ流れを選びます。主要な取引を少数に絞り、同じ条件で各候補を確認します。
架空の卸売会社なら、通常の受注に加えて、一部欠品、分割出荷、返品、請求後の訂正を含められます。すべての例外を一度に入れるのではなく、頻度と影響が大きい場面を優先します。細かい画面指定より、業務上の結果を指定します。
データは説明用の架空データを使い、必要な件数や属性を揃えます。実データを使う場合は、自社の取り扱いルールと利用許可を確認します。製品比較のために不要な個人情報や機密を渡す必要はありません。
| 確認場面 | 質問例 |
|---|---|
| 通常処理 | 前後の業務へ何が引き継がれるか |
| 訂正・取消 | 履歴と残高にどう反映されるか |
| 承認・権限 | 担当者ごとに何を実行できるか |
| 障害・例外 | 失敗をどう検知し復旧するか |
| 実現方式 | 標準か追加対応か、費用に含むか |
操作と情報のつながりを見る
画面の入力項目だけでなく、前工程の情報をどれだけ引き継げるか、後工程で何を確認できるかを見ます。受注の変更が出荷と請求へどう影響するかなど、状態の変化を追います。
業務担当者には、自分の作業だけでなく、必要な情報へたどり着けるかを確認してもらいます。承認者には、何を根拠に承認できるか、差戻しや代理承認の扱いを見てもらいます。管理者には権限設定や履歴の確認方法を質問します。
「何回クリックしたか」だけで使いやすさを評価しないことも重要です。確認すべき情報が一画面に揃うか、誤入力を防げるか、例外から復旧できるかを含めます。日常の反復作業と、頻度が低い重要処理は評価の重みを変えて構いません。
制約と例外処理を質問する
質問は「できますか」で終わらせず、「どの条件で」「誰の権限で」「どの方法で」「失敗したらどうするか」まで確認します。訂正操作では、取消、再登録、会計への反映、履歴がどうなるかを追います。
連携を含む場面では、接続先が実際に動いているか、模擬応答かを確認します。連携が止まった場合にどこで検知し、何を再実行するかも聞きます。デモで成立しても、監視と復旧の設計は別に必要です。
処理量や応答速度は、デモ環境の印象から断定しません。重要なら、想定件数、同時利用、時間帯、測定方法を揃えて検証を計画します。未確認の状態を評価表に残すことで、説明と実証を区別できます。
結果を記録し、次の確認へつなぐ
確認結果は、要件番号、実演内容、実現方法、制約、証拠、追加質問で記録します。参加者の感想は別欄に置くと、主観と事実を混ぜずに扱えます。評価を終えた直後に不明点を整理しましょう。
実演できなかった項目は、理由と確認予定を残します。資料回答で十分か、追加デモや小規模検証が必要かを判断します。重要な必須条件が未確認のままなら、採用判断への影響を明示します。
最終的には、要件の適合性と、業務変更が必要な箇所をまとめます。標準機能へ合わせられる範囲が見えると、追加開発の判断にも役立ちます。デモの結果は選定資料だけでなく、導入時のFit&Gapや受入テストのシナリオへ引き継ぎます。
実演中に確認できない項目の扱い
大量の受注を一括処理する要件があるのに、デモでは数件だけを処理した例を考えます。少件数で正常に動くことは確認できますが、想定する件数や時間内に処理できることまでは確認できません。「デモ済み」という一つの印だけで要件を完了させないことが重要です。
記録を、機能の流れは確認済み、想定件数での性能は未確認、と分けます。次に測定条件、検証環境、必要なデータ、実施者、時期を決めます。標準資料の性能説明を使う場合にも、自社と条件がどの程度異なるかを確認します。
参加者への質問も役割ごとに分けます。現場には作業の成立性、承認者には判断材料、管理者には権限と履歴を確認してもらいます。最後に全員の感想を一度に聞くより、事前に観点を渡しておくと、重要な確認が抜けにくくなります。確認できなかったことを明示できるデモほど、次の判断に役立ちます。
デモの議事録は、ベンダー側にも事実関係を確認してもらいます。意見を一致させるためではなく、何を実演し、何が未確認で、どの条件を説明されたかを揃えるためです。回答待ちの質問は担当者と期限を付け、次の評価会までに必要な情報を集めます。
確認時点も記録します。
よくある質問
最初から自社専用のデモを依頼すべきですか？
初期調査では標準デモで基本を理解し、候補が絞れた段階で共通シナリオを使う進め方が考えられます。目的と準備負担を合わせて判断します。
デモで動けば標準機能と考えてよいですか？
いいえ。設定、追加機能、個別開発、模擬処理のどれかを確認します。提供条件や見積もりへの包含も記録します。
次に確認すること
自社で重要な取引を一つ選び、開始条件・担当者・期待結果・例外を一枚にまとめてください。
- ERP選定前の業務要件整理｜必須条件と優先順位を明確にする
- ERP製品を比較する評価軸と評価表の作り方
- Fit&GapとFit to Standardの進め方｜標準機能と業務の差を判断する
- ERPのテストと受入判定｜業務シナリオ・合否基準・残る問題の扱い
参考情報・編集方針
本文の手順・評価例はERP選定ラボによる整理です。事例・数値例は説明用の仮定です。製品固有の機能・条件は各社の最新資料で確認してください。
参考情報の確認日：2026年10月28日。運営方針・プロフィール
