見積管理システムの要件整理で先に決める項目と業務の境界

見積管理システムの要件は、見積書を出力できることだけでは決まりません。作成中の見積と提出済みの見積を区別し、改訂の経緯をたどれ、受注時に正しい内容を引き渡せることが重要です。まず一つの案件が相談から受注・失注へ進む流れを書き出します。

管理する単位を明確にする

顧客、案件、見積の違いを決めます。同じ顧客に複数の案件があり、一つの案件に別案の見積があるなら、それぞれを別の識別子で扱う必要があります。見積番号だけで顧客や案件を代用すると、追加提案や再提出の関係が分かりにくくなります。

要件メモには「案件に複数の見積を紐付ける」「同じ提案の修正版は版として残す」「比較用の別案は別見積として関連付ける」など、自社で使う言葉の定義を記載します。取引先から指定される書式がある場合は、書式の違いとデータの違いを分けて調べます。

現在使っている帳票を集める際は、完成した見積だけでなく差し戻しや再提出の例も確認します。通常経路だけでは、実際に負担が大きい例外を取りこぼします。

商品マスターの現在の単価と、提出済み見積の単価を同じものとして更新してよいか確認します。過去の提出内容を再現するには、見積時点の値を保持する設計が必要になる場合があります。マスターを直したら過去帳票まで変わる状態は避けます。

端数、税区分、値引き、明細ごとの計算、合計欄の表示も、実際の帳票で比較します。計算方法は自社の取引や会計処理との整合を確認し、推測で統一しません。画面表示と出力帳票で結果が食い違わないことを受け入れ条件へ含めます。

下書きは編集できても、提出後の内容は新しい版を作って変更するなど、状態に応じた操作を決めます。「承認機能が必要」という言い方だけでは不十分です。誰がどの条件で確認し、不在時に誰へ引き継ぎ、差し戻し後にどこから再開するかを記載します。

小さな組織では、同じ人が作成と確認を兼ねる場面もあります。役割と担当者を切り離して整理しておくと、担当変更に対応しやすくなります。閲覧だけできる人、編集できる人、確定できる人の違いを操作単位で確認します。

想定例として、複数案を提示した案件で一部の明細だけが採用される場合があります。単純に案件全体を受注へ変えるだけでは、採用されなかった項目も後工程に流れます。採用範囲を確定する操作が必要か、現場の実例で確かめます。

提出済みの版を誤って書き換える、同じ番号が別案件へ付く、取り消した見積が集計に残る、といった操作を試します。正常に作成できることに加え、誤った操作を防げるか、誤った場合に履歴から戻せるかを検証します。

要件表には、項目名、入力する人、必須となる状態、変更できる期限、確認方法を記入します。利用頻度の低い機能は後回しにできても、提出内容を再現できない問題は運用の信頼性に関わるため優先して解消します。

現在の引き継ぎが支障なく行えるなら、見積管理の範囲を先に固める方法があります。二重入力が残る境界は明示します。

確認用の試作として有効です。ただし番号や版の意味を決めず、見た目だけで完成と判断しないようにします。

運用開始時のデータも要件に含めます。過去見積をすべて取り込むのか、継続中の案件だけにするのかで準備が変わります。移行対象、添付資料の置き場所、移行後に帳票を再現できるかを確認し、旧資料を参照する手順も用意します。導入の区切りを先に決めれば、不要な転記作業を増やさずに済みます。