▼ この記事の内容
案件管理・採算管理のデモでは、案件の進み具合と利益の見込みを同じ案件で追い、条件が変わったときに対応を決められるかを確認します。画面の見やすさに加え、売上・原価の集め方、見積変更の扱い、更新を担う人まで確かめることが大切です。この記事では、管理方法ごとの比較、自社の案件を使う確認手順、導入を判断する基準を整理します。営業だけでは確かめにくい実績原価や会計との関係も含め、社内で検討を進めるための見方を解説します。
案件管理・採算管理のデモは、利益が変わる場面で確かめる
案件管理と採算管理を検討するなら、デモで見たいのは、案件の一覧から利益が変わった理由までたどれるかです。受注の見込みが分かっても、追加作業や仕入れの増加が反映されなければ、営業会議では順調に見える案件の利益が減っている可能性があります。反対に、採算の数字だけがあっても、顧客との合意内容が分からなければ、何を調整すればよいか決められません。
そのため、用意された画面を順に見るだけでなく、商談中の案件が受注し、作業が進み、売上と原価が確定するまでを通して見せてもらいます。途中で見積金額や作業内容を変えたとき、どの数字が変わり、誰が気づき、どこで対応を記録するのか。その流れが、自社で使えるかを判断する材料になります。
案件管理と採算管理では、答えたい問いが違う
案件管理で答えたいのは、誰がどの顧客に何を提案し、どこまで進み、次に何をするかです。営業マネージャーは、受注予定のずれ、提案の停滞、担当者への支援の必要性を見ます。営業担当者にとっては、顧客との約束や次回までの宿題を引き継げることも欠かせません。
採算管理で答えたいのは、その案件でどれだけの売上を見込み、どの費用がかかり、どの利益が残るかです。ただし、利益という言葉が指す範囲は会社によって異なります。仕入れや外注費を差し引いた数字を見るのか、社内の作業時間に応じた人件費まで含めるのかによって、必要な情報も判断も変わります。
デモの前に、この違いを社内でそろえておきます。営業が見積時の利益を見ている一方で、経理が確定後の利益を見ているなら、同じ案件でも数字が異なることがあります。どちらが誤りかを決める前に、対象の費用と集計時点が同じかを確認する必要があります。
利益の表示より、判断できる状態を求める
案件別の利益が表示されても、それだけで管理ができるとは限りません。原価が未入力なのか、まだ発生していないのか、予定より安く収まったのかが区別できなければ、数字を見誤るおそれがあります。最終更新日や未入力の状態が分かるかも、画面の見やすさと合わせて確認したい点です。
例えば、受注後に顧客から追加作業を依頼された場面を考えます。追加の売上が合意済みか、作業時間だけが増えるのかによって採算は変わります。デモでは、依頼内容を残す場所、見積を変更する場所、原価の見込みを直す場所を確認し、それぞれが同じ案件につながるかを見ます。
管理画面を見た担当者が、顧客への条件確認、社内の作業調整、上長への相談へ進めることが到達点です。数字が悪化した事実だけでなく、対応する人と期限、判断の根拠まで残せるかを確かめると、導入後の会議で使う場面を想像しやすくなります。
管理方法を比較し、自社に必要な範囲を決める
案件管理と採算管理をどこまで同じ仕組みにまとめるかは、現在の困りごとから決めます。案件の抜け漏れを減らしたいのか、原価の超過に早く気づきたいのか、営業と経理の転記を減らしたいのか。目的が違えば、比較する選択肢も変わります。
既存の管理方法を整理するだけで改善できる部分もあれば、複数の仕組みをつなぐ必要がある部分もあります。次の表は製品の優劣ではなく、自社がどの方法から検討するかを選ぶための比較です。実際の機能や対応範囲は、候補となるサービスごとに確かめてください。
| 選択肢 | 向いている場合 | 向かない場合 | デモや試用で確かめる点 |
|---|---|---|---|
| 表計算で案件と採算を管理する | 担当者と更新方法が明確で、管理項目を調整しながら運用を固めたい | 同時編集や転記が多く、変更履歴や閲覧制限を細かく管理したい | 入力規則、計算式の保護、更新履歴、担当交代後の引き継ぎが維持できるか |
| SFA（営業支援システム）を中心にする | 商談の進捗と見積時の採算をつなぎ、営業判断に使いたい | 日々の作業時間や複雑な実績原価まで、営業の入力だけで集めようとしている | 原価情報を持てる範囲、受注後の管理、会計や作業管理との連携方法 |
| 案件別の原価・作業管理を中心にする | 受注後の工数や外注費が利益に影響し、進行中の採算を把握したい | 主な課題が商談の追客や受注見込みの整理にあり、その管理まで単独で担わせたい | 見積時の予定と実績の比較、追加作業の扱い、営業への情報共有 |
| 販売・会計などをまとめて管理する | 受注、発注、請求、原価のつながりを部門横断で整えたい | 部門ごとの管理ルールが未整理で、運用を決める担当者も定まっていない | 自社の取引形態への対応、承認手順、導入時の設定と日常業務への影響 |
| 既存の仕組みを連携する | 現在の営業・経理・作業管理を生かし、同じ案件の情報をつなぎたい | 案件を照合する番号やデータの管理責任が決まっていない | 連携対象、更新のタイミング、失敗時の通知、重複や修正への対応 |
営業が使う範囲と、他部門が使う範囲を分けて考える
営業の案件管理に原価欄を追加しても、営業担当者がその数字を取得できなければ更新は止まります。外注費は発注担当、作業時間は実務担当、確定原価は経理が持っているなら、それぞれの情報がどう集まるかを考える必要があります。
まず、営業が入力する情報、他部門が入力する情報、別の仕組みから取り込む情報を分けます。そのうえで、営業マネージャーが見る画面には何を集めるかを決めます。全員が同じ画面を使うことと、全員の情報が同じ案件につながることは、別の要件です。
商談の進捗や入力項目の整理から始めたい場合は、SFA案件管理の始め方｜Excel限界を超える必須項目と失敗回避策も参考になります。採算の情報を追加する前に、案件の担当者、進捗、更新のルールをそろえておくと、比較の前提を作りやすくなります。
機能の数ではなく、業務が完結するかで選ぶ
見積、原価、分析といった機能名が並んでいても、実際の業務がつながるかは別に確認します。見積の変更を原価計画へ手入力し直す必要がある、受注後に別の案件を作り直す必要がある、といった場合は、その作業量と誤りが起きる場所も評価に含めます。
一方、すべてを同じ仕組みに集めることが目的になると、自社では使わない機能の設定まで増えることがあります。比較では、必要な判断ができるか、入力を続けられるか、運用を担当する人が管理できるかを軸にします。追加機能は、その不足を埋める必要があるときに検討します。
デモの前に、自社の案件と採算の定義を用意する
自社に合うかを確かめるには、デモで再現してほしい業務を先に整理します。完成した要件書がなくても、現在の管理表、見積書、原価の集計方法を見ながら、どこで判断が遅れているかを言葉にすることはできます。問い合わせの時点で困りごとを伝えると、確認したい場面を準備してもらいやすくなります。
典型的な案件と、判断に迷う案件を選ぶ
最初は、自社でよく発生する案件を選びます。営業から受注後の担当へ渡す流れや、売上と原価の集め方が分かる案件が適しています。担当者だけが事情を知っている特殊な案件から始めると、その例外に対応できるかだけで選びやすくなります。
通常の流れを確かめる案件に加えて、見積の変更、追加作業、外注費の増加、受注時期の延期など、自社で判断に迷いやすい場面を用意します。実際に起きた変更の内容を整理し、変更前に何が分かっていて、変更後に何を判断したかったのかを説明できる形にします。
外部に見せる資料は、顧客名や担当者名、契約上の秘密情報を伏せ、業務の確認に必要な範囲に絞ります。実際の取引情報を共有する場合は、社内の取り扱いルールや提供先との条件も確認します。画面で業務を再現するために、原本の全項目を渡す必要があるとは限りません。
利益の計算に含めるものを決める
採算の定義では、利益の名前だけを合わせず、売上から何を差し引くのかを具体的にします。社内の作業時間を原価に含めるなら、誰の時間を対象とし、どの単価を使い、どこから実績を取得するのかまで確認します。まだ決まっていない部分は、未決定としてデモの確認事項に残します。
| 整理する項目 | 社内で確かめること | デモでの確認につながる点 |
|---|---|---|
| 管理する単位 | 商談、契約、作業、請求のどれを案件として扱うか | 分割や統合が起きても、売上と原価の対応を追えるか |
| 売上の状態 | 見積、受注、売上計上の金額をどう区別するか | 予定と確定が混ざらず、比較する時点を選べるか |
| 原価の範囲 | 仕入れ、外注費、人件費、経費のどこまで含めるか | 必要な項目を管理でき、含めていない費用も分かるか |
| 更新のタイミング | 誰が、どの業務の時点で更新するか | 判断に使う会議までに情報がそろうか |
| 費用の割り振り | 複数案件に共通する費用をどう配分するか | 配分のルールと結果を後から確認できるか |
| 閲覧と編集の権限 | 担当者、上長、経理に何を見せ、何を変更させるか | 機密情報を守りながら必要な判断ができるか |
比較に使う質問を、候補ごとに変えない
候補によって異なる説明を受けると、印象に残った機能で比較しやすくなります。自社で確認したい案件と変更の場面は共通にして、同じ質問を使います。標準でできること、設定が必要なこと、追加開発が必要なこと、別の仕組みで補うことを分けて記録します。
例えば、追加作業が決まったら誰がどこを直すのか、修正前の見積は残るのか、未入力の原価はどう表示されるのか、といった質問です。対応可能という回答だけで終えず、実際の画面で確認できたか、資料による説明だけだったかも残すと、検討後の認識のずれを減らせます。
参加者は、自社の確認事項に応じて決めます。営業だけで進捗管理を見る場面と、経理や受注後の担当者が原価の流れを見る場面を分けても構いません。大切なのは、実際に入力する人と数字を使う人の両方が、自分の業務として確かめられることです。
自社に合うかを判断するデモの確認手順
デモは、案件の登録から採算の確認までを順に追い、各場面で次へ進める条件を確かめます。画面でできることだけでなく、社内の担当者と更新方法が決まるかも合わせて判断します。途中で不明点が出た場合は、確認できた範囲と未確認の範囲を分けて残します。
案件の登録から、同じ案件を追えるか確かめる
まず、商談を登録し、見積や受注の情報へつなげる流れを確認します。顧客名が同じでも契約が異なる場合や、提案の一部だけを受注する場合に、どの単位で案件を分けるかを見ます。案件名だけで照合していると、同名の案件や名称変更が起きたときに扱いが曖昧になるため、識別に使う番号なども確認します。
次へ進める目安は、営業の案件と売上・原価の対応を、担当者以外も追えることです。受注後に別の番号が付く場合でも、元の商談へ戻れるなら運用を検討できます。手作業で対応表を作る必要があるなら、その作成と修正を誰が担うのかが残る確認事項です。
見積時の売上と原価から、採算を確認する
次に、見積金額と予定原価を登録し、自社が確認したい利益が表示されるかを見ます。外注費だけを入力した状態と、社内の作業時間を含めた状態を区別できるか、まだ見積もれていない費用を未確定として扱えるかも確認します。
ここでの判断は、画面上の利益が、自社の計算範囲と合っているかです。自社で確認した元の資料と照合し、差がある場合は項目や計算条件までたどります。差の理由が分からないまま見栄えで評価せず、計算の前提を説明できる状態になってから次へ進みます。
見積変更と追加作業を、その場で反映する
通常の登録を見たら、見積金額を変更し、作業や外注の予定も変えてみます。その結果が案件の一覧、利益の表示、承認の状態へどう反映されるかを確かめます。変更前の条件が残るか、誰がいつ何を変えたかが分かるかも確認します。
特に見たいのは、顧客への追加請求が未合意の状態です。期待している売上を確定した売上と同じように扱うと、採算を楽観的に見るおそれがあります。追加原価は発生するが追加売上は未確定、という状態を区別し、顧客との確認事項として残せるかを見ます。
次へ進む条件は、変更による採算への影響を確認でき、以前の条件と現在の条件を取り違えないことです。修正のたびに別の管理表を作るなら、情報が分かれる理由と、最終的にどの情報を判断の基準にするかを決める必要があります。
作業中の実績と、完了までの見込みを分ける
受注後の採算では、発生済みの費用だけを見ても、完了時に利益が残るか判断できない場面があります。作業が残っているのに未発生の費用を考慮しなければ、進行中の案件が実態より良く見えるためです。実績原価と、これから発生する費用の見込みを分けて確認します。
デモでは、作業時間や外注費を追加したあと、残りの作業を見直した場合の表示を見せてもらいます。実績の増加と残りの見込みを重複して数えないか、予定の総額を更新したのか残額だけを更新したのかが分かるかも、確認したい点です。
次へ進めるのは、現在までの実績と完了時の見通しを区別でき、その更新担当が決められる場合です。完了までの見込みを計算する機能がない場合は、別の管理方法で補えるか、その手間を含めて採用できるかを検討します。
数字の変化から、対応を決めるところまで進める
採算の変化が確認できたら、営業マネージャーが一覧から対象案件を開き、原因を調べ、担当者へ確認する流れを試します。変化の原因が値引きなのか、作業の増加なのか、原価の入力遅れなのかを区別できるかを見ます。
そのうえで、条件交渉、作業範囲の確認、社内の担当調整など、次の対応を記録します。通知する機能がある場合は、誰に何が届き、確認後の対応をどこへ残すのかまで確かめます。通知が届くことと、問題が解決することは分けて考えます。
次へ進む目安は、数字を見た人が元の情報を確認し、対応する人と期限を決められることです。分析画面から別の資料を探し回る必要があるなら、必要な情報へたどる手順と、会議中に扱えるかを確認します。
普段使う担当者が操作し、導入判断を残す
説明担当者の操作が分かりやすくても、自社の担当者が使えるかは別に試します。試用できる場合は、案件の登録、見積の変更、原価の更新、一覧からの確認を、普段の業務を担う人が行います。迷った箇所は操作の問題か、自社のルールが未決定なのかを分けます。
最後に、必要な業務を確認できた、追加確認が必要、現時点では運用が難しい、という形で判定を残します。追加確認がある場合は、確認する内容と担当者、回答がそろえば判断できる条件を記録します。期待する機能があるという理由だけで、未確認の連携や設定を解決済みにしないことが大切です。
デモの依頼内容や進行を整理する際は、営業デモを成功に導くコツ｜顧客の業務場面から進める準備と進行も参考になります。提供側の説明の順序を知っておくと、自社が確認したい業務場面を具体的に伝えやすくなります。
導入後に困らないための失敗の見分け方
デモで業務が再現できても、日々の入力や部門間の受け渡しが続かなければ、採算の数字は古くなります。導入判断では機能の確認と合わせて、情報が集まらなくなる条件、数字を誤読する条件、管理を引き継げなくなる条件を見ておきます。
予定と実績、未入力と原価なしを混ぜる
見積時の売上と確定した原価を並べた数字と、確定した売上と原価から求めた数字では、意味が異なります。案件ごとに使っている時点が違うまま比較すると、利益の良し悪しを判断しにくくなります。画面の項目名だけでなく、どの状態の数字かを見分けられる表示が必要です。
未入力の費用が原価なしとして扱われる場合も注意します。登録が済んでいない案件ほど利益が高く見えてしまうからです。未入力の表示、更新状況の一覧、締め前の確認など、自社で欠損に気づける方法を用意できるか確かめます。
更新を営業担当者だけに任せる
営業担当者に原価の入力を求めても、発注や作業の情報が営業へ届かないなら、正確に更新することは難しくなります。入力漏れを注意する前に、その人が情報を取得できるのか、既存の業務で同じ内容を別の場所へ入力していないかを確認します。
導入前には、入力項目ごとに、情報を持つ人、登録する人、内容を確認する人を決めます。兼務する場合でも役割を分けておくと、数字が合わないときに確認先が分かります。入力の負担を見積もる際は、画面への記入だけでなく、元の情報を集める時間も含めます。
連携できるという説明だけで判断する
会計や作業管理と連携できても、自社が必要とする項目や更新方法まで対応しているとは限りません。案件番号、金額、取引日、部門など、何がどちらからどちらへ渡るのかを確認します。自動で更新される範囲と、ファイルの取り込みなど人の操作が必要な範囲も分けます。
さらに、取り込み後に元の情報を修正した場合、連携に失敗した場合、同じデータを再度取り込んだ場合の扱いを確かめます。重複や上書きの確認を誰が行うかまで決めておくと、連携が止まったまま古い数字を使い続ける事態に気づきやすくなります。
採算が悪い理由を、数字だけで決めつける
利益が減った案件でも、値引き、見積もり漏れ、顧客都合の変更、社内の手戻りなど、原因は異なります。利益率だけで担当者を評価すると、改善すべき業務の違いが見えなくなるおそれがあります。数字の変化と、合意内容や作業の経緯を合わせて確認する運用が必要です。
また、原価の入力が遅れているだけなら、営業上の交渉を変えても問題は解決しません。会議では、数字が正しくそろっているかを確認し、次に変化の理由を見て、対応を決める順に進めます。デモでも、その根拠へ戻れるかを確かめておくと判断に役立ちます。
追加費用と、運用を変える手間を見落とす
費用の比較では、利用料金に加え、初期設定、データの移行、必要な連携、追加機能、導入後の支援がどこまで含まれるかを確認します。料金表にある金額だけでなく、自社がデモで確認した業務を実現する条件で見積もりをそろえます。
社内で担う作業も残します。案件の分類を整理する、古いデータを修正する、入力ルールを説明する、といった準備です。システム側でできることと、自社で決めることを分け、担当者が確保できるかを確認してから導入の範囲を決めます。
試用の合格条件を決めずに終える
試用期間を設けても、触ってみた印象だけでは採用を決めにくくなります。自社の案件を追える、予定と実績を照合できる、変更の理由を確認できる、普段の担当者が更新できる、といった条件を事前に決めます。条件を満たした根拠として、確認した画面や操作、残った課題を記録します。
試用で難しさが分かった場合は、設定で解消できるのか、運用を変える必要があるのか、別の選択肢を検討するのかを分けます。導入対象を一部に絞るなら、対象外の案件をどう管理するかも決めます。部分的に始めることで管理が分散し、全体の数字が分からなくならないようにします。
採算の変化が値引きや追加作業の合意に関わる場合は、数字の確認に加えて商談の振り返りも役立ちます。FAZOMを使い、AIを相手にした営業ロープレや商談の振り返りを続ける方法も、条件確認の進め方を社内で練習する選択肢になります。
まとめ
案件管理・採算管理のデモでは、案件の進み具合と利益の見込みがつながり、条件の変更に応じて対応を決められるかを確認します。利益が表示されることに加え、何を含めた数字か、いつ更新されたか、元の情報へ戻れるかまで見ることが大切です。
検討を始める際は、自社でよくある案件と採算が変わる場面を選び、売上・原価の範囲と入力担当を整理します。その資料を使い、登録、見積変更、実績の更新、完了時の見込み、対応の記録まで、候補ごとに同じ流れで確かめます。
- 管理方法は、商談の把握、原価の把握、部門間の連携のどこに課題があるかで比較する。
- 予定と実績、未確定と確定、未入力と原価なしを区別して確認する。
- 機能だけでなく、情報を集める人、入力する人、判断する人まで決める。
- 試用では合格条件を決め、確認できたことと残った課題を記録する。
最初に着手したいのは、最近、採算の判断に迷った案件を選び、どの時点で何が分かれば対応できたかを書き出すことです。それをデモの確認事項にすると、自社が必要とする管理の範囲と、導入前に解消したい課題を具体的に比較できます。
