概算発注フロー(仮発注 → 正式発注)
一言: 仕様・金額が未確定でも仮発注で先行着手し、後から正式確定できる「先に走るフロー」。
関連ドキュメント: 見積購買フロー(RFQ) | フロー一覧
仕様・数量・価格がまだ確定していない状態でも先に発注を進めることができるフローです。工事・システム開発・デザイン制作など、「詳細が固まるまで着手できない」ではビジネスが止まるケースに対応します。
概算の見積で仮発注し、サプライヤが先行着手。仕様確定後に再見積を取って正式発注(補充)します。注文書は「当初」と「補充」の2枚構成になります。
登場人物(ロールコード)
Section titled “登場人物(ロールコード)”| ロール | コード | 役割 |
|---|---|---|
| 依頼者 | K001 | 概算見積依頼申請・仮発注申請・正式発注申請・検収入力 |
| 依頼承認者 | KS01 | 見積依頼承認・発注承認・検収承認 |
| 購買担当者 | K002 | サプライヤ選定・見積依頼・再見積依頼・見積先選定 |
| 購買承認者 | KS02 | 見積先選定承認・再見積選定承認 |
| サプライヤ | S001 | 概算見積回答・仮受注・着手・再見積回答・正式受注・納品 |
| 経理担当者 | K003 | 支払締め処理(当初+補充の合計) |
フロー全体像
Section titled “フロー全体像”業務シーケンス(スイムレーン)
Section titled “業務シーケンス(スイムレーン)”このフローの核心は「仮発注で先行着手し、後から正式確定する」2段構えの発注構造です。
sequenceDiagram
box バイヤー企業グループ
actor K001 as 依頼者
actor K002 as 購買担当者
actor KS01 as 依頼承認者
actor KS02 as 購買承認者
participant J2 as システム(J2)
actor K003 as 経理担当者
end
actor S001 as サプライヤ
rect rgb(230, 240, 255)
Note over K001,J2: 📋 フェーズ1:概算見積
K001->>J2: ① 概算見積依頼申請(仕様未確定・概算条件)
J2-->>KS01: 📧 見積依頼承認依頼
KS01->>J2: ② 見積依頼承認
K002->>J2: ③ サプライヤ選定・見積依頼
J2-->>S001: 見積依頼通知
S001-->>J2: ④ 概算見積回答(概算金額・概算納期)
J2-->>K002: 📧 見積回答通知
K002->>K001: ⑤ 見積確認・相談(予算感・着手可否)
K002->>J2: ⑥ 見積先選定
J2-->>KS02: 📧 見積先選定承認依頼
KS02->>J2: ⑦ 見積先選定承認
K001->>J2: ⑧ 選定結果確認(OK)
end
rect rgb(255, 245, 220)
Note over K001,S001: 🔨 フェーズ2:仮発注・先行着手
K001->>J2: ⑨ 仮発注申請(概算金額・概算仕様)
J2-->>KS01: 📧 発注承認依頼
KS01->>J2: ⑩ 発注承認
J2-->>S001: 仮発注通知(注文書〈当初〉発行)
S001->>J2: ⑪ 仮受注
Note over S001: 先行着手(設計・部材調達・工事準備など)
end
rect rgb(240, 255, 230)
Note over K002,S001: 📐 フェーズ3:仕様確定・再見積
Note over K001,S001: 時間経過後、仕様・数量が確定したら
K002->>J2: ⑫ 再見積依頼(確定仕様・確定数量)
J2-->>S001: 再見積依頼通知
S001-->>J2: ⑬ 再見積回答(正式金額・正式納期)
J2-->>KS02: 📧 見積選定承認依頼
KS02->>J2: ⑭ 見積選定承認(正式内容確認)
end
rect rgb(255, 235, 235)
Note over K001,S001: 📦 フェーズ4:正式発注・納品・検収
K001->>J2: ⑮ 正式発注申請(確定金額・確定仕様)
J2-->>KS01: 📧 発注承認依頼
KS01->>J2: ⑯ 発注承認
J2-->>S001: 正式発注通知(注文書〈補充〉発行)
S001->>J2: ⑰ 正式受注
S001->>K001: 納品完了(帳票・納品書付き)
K001->>J2: ⑱ 検収登録
J2-->>KS01: 📧 検収承認依頼
KS01->>J2: ⑲ 検収承認
end
rect rgb(240, 230, 255)
Note over J2,K003: 💰 フェーズ5:支払
J2->>J2: 支払予定通知を自動作成(当初+補充)
J2-->>S001: 📧 支払予定通知
K003->>J2: ⑳ 支払締め処理(合計金額)
end
フロー概要(プロセス図)
Section titled “フロー概要(プロセス図)”flowchart TD
START(["💡 購買ニーズ発生\n仕様・金額が未確定でも着手が必要"]) --> S1
subgraph Phase1["📋 フェーズ1:概算見積"]
S1["① 概算見積依頼申請\nK001(仕様未確定・概算条件)"]
APP1["② 見積依頼承認\nKS01"]
S3["③ 見積依頼\nK002"]
S4["④ 概算見積回答\nS001(概算金額)"]
S5["⑤ 見積確認・相談\nK002 ↔ 依頼者"]
S6["⑥ 見積先選定\nK002"]
APP2["⑦ 見積先選定承認\nKS02"]
S8["⑧ 選定結果確認\nK001"]
end
subgraph Phase2["🔨 フェーズ2:仮発注・先行着手"]
S9["⑨ 仮発注申請\nK001"]
APP3["⑩ 発注承認\nKS01"]
S11["⑪ 仮受注\nS001\n注文書〈当初〉発行"]
S12["先行着手\nS001\n設計・部材調達・工事準備"]
end
subgraph Phase3["📐 フェーズ3:仕様確定・再見積"]
S13["⑫ 再見積依頼\nK002(確定仕様)"]
S14["⑬ 再見積回答\nS001(正式金額)"]
APP4["⑭ 見積選定承認\nKS02"]
end
subgraph Phase4["📦 フェーズ4:正式発注・納品・検収"]
S15["⑮ 正式発注申請\nK001"]
APP5["⑯ 発注承認\nKS01"]
S17["⑰ 正式受注\nS001\n注文書〈補充〉発行"]
S18["納品\nS001"]
S19["⑱ 検収登録\nK001"]
APP6["⑲ 検収承認\nKS01"]
S20["⑳ 支払締め\nK003(当初+補充)"]
end
S1 --> APP1
APP1 -->|差戻し| S1
APP1 -->|承認| S3
S3 --> S4
S4 --> S5
S5 --> S6
S6 --> APP2
APP2 -->|差戻し| S6
APP2 -->|承認| S8
S8 --> S9
S9 --> APP3
APP3 -->|差戻し| S9
APP3 -->|承認| S11
S11 --> S12
S12 --> S13
S13 --> S14
S14 --> APP4
APP4 -->|差戻し| S13
APP4 -->|承認| S15
S15 --> APP5
APP5 -->|差戻し| S15
APP5 -->|承認| S17
S17 --> S18
S18 --> S19
S19 --> APP6
APP6 -->|差戻し| S19
APP6 -->|承認| S20
S20 --> END(["✅ 完了"])
注文書の2枚構成
Section titled “注文書の2枚構成”概算発注では、1件の発注に対して注文書が最大2枚発行されます。
| 注文書 | 発行タイミング | 金額 | 役割 |
|---|---|---|---|
| 注文書〈当初〉 | 仮発注承認後(フェーズ2) | 概算金額 | 先行着手の根拠書類。仮受注の証明 |
| 注文書〈補充〉 | 正式発注承認後(フェーズ4) | 差額・追加分 | 確定した追加費用・変更分の正式書類 |
例:
| 項目 | 金額 |
|---|---|
| 仮発注(当初)金額 | 1,000,000円 |
| 正式確定金額 | 1,300,000円 |
| 補充注文(差額) | 300,000円 |
| 支払総額 | 1,300,000円 |
画面に表示されるステータス
Section titled “画面に表示されるステータス”概算発注のステータス表示は見積購買と同じです。概算見積の段階は「回答待ち(担当者未定/交渉前/交渉中)」「選定相談中」「決定承認待ち」、仮発注以降は「発注承認待ち」「受注待ち」「納品待ち」「未検収」「検収完了」「支払締め済み」の順に進みます。一覧は 見積購買フロー(RFQ) のステータス表を参照してください。
通常見積購買との違い
Section titled “通常見積購買との違い”| 観点 | 通常見積購買(RFQ) | 概算発注 |
|---|---|---|
| 仕様の確定 | 発注前に確定必須 | 未確定のまま着手可能 |
| 金額の確定 | 発注前に確定必須 | 概算で仮発注、後から正式確定 |
| 発注回数 | 1回 | 2回(仮発注+正式発注) |
| 注文書枚数 | 1枚 | 最大2枚(当初+補充) |
| サプライヤ着手 | 受注後 | 仮受注後、すぐ着手可能 |
| 主な用途 | 仕様確定済みの調達 | 工事・開発・試作など仕様変動が多い案件 |
重要ポイント
Section titled “重要ポイント”- 「先に走って後で精緻化」の設計: 仕様が固まるまで動けない状況を回避するためのフローです。不確実性が高い案件に有効です。
- 仮発注は「着手許可」: 仮発注は正式契約ではなく「概算ベースで作業を始めてよい」という許可証の意味を持ちます。
- 再見積の精度が重要: フェーズ3の再見積は、確定仕様をもとに正式金額を取得するステップです。概算との乖離が大きい場合は関係者への説明が必要です。
- 承認者が2種類: 依頼部門の承認者は見積依頼・発注・検収を承認し、購買部門の承認者(購買担当者&承認者)は見積先の選定を承認します。
- 支払締めは合計金額で実施: 経理担当者は注文書〈当初〉と〈補充〉の両方を対象に支払締めを行います(検収済みの明細がすべて対象になるため)。
実際の利用シーン
Section titled “実際の利用シーン”ケース① 店舗改装工事(設計前に着工が必要)
Section titled “ケース① 店舗改装工事(設計前に着工が必要)”施設部の田中さんが、開店3ヶ月前に内装工事業者への概算発注が必要なケースです。設計図面はまだ完成していませんが、工期確保のために先に着手を依頼します。
| フローステップ | 担当 | 実際の操作・内容 |
|---|---|---|
| ① 概算見積依頼申請 | 依頼者 田中さん | 「A店舗(100㎡)内装改装。設計図面は2ヶ月後に確定予定。概算500〜700万円と想定」と申請 |
| ② 承認 | 承認者 | 概算金額・必要性を確認して承認 |
| ③ 見積依頼 | 購買担当者 | 内装工事業者2社(X社・Y社)へ概算見積を依頼 |
| ④ 概算見積回答 | サプライヤ X社・Y社 | X社:概算550万円、Y社:概算620万円(概算のため±20%の誤差あり) |
| ⑤ 相談 | 購買担当者 ↔ 依頼者 | X社の方が価格・実績ともに良好。田中さんもX社希望 |
| ⑦ 見積先選定承認 | 購買承認者 | X社への概算発注を承認 |
| ⑨ 仮発注申請 | 依頼者 田中さん | X社・概算550万円・工期3ヶ月で仮発注申請 |
| ⑩ 発注承認 | 承認者 | 承認 → 注文書〈当初〉550万円 発行 |
| ⑪ 仮受注・着手 | サプライヤ X社 | J2上で仮受注。現場調査・下地工事・資材発注を開始 |
| (2ヶ月後)設計図面確定 | — | — |
| ⑫ 再見積依頼 | 購買担当者 | 確定図面をX社へ共有し正式見積を依頼 |
| ⑬ 再見積回答 | サプライヤ X社 | 正式金額:580万円(当初比+30万円。追加工事が発生) |
| ⑭ 選定承認 | 購買承認者 | 30万円増額の理由を確認し承認 |
| ⑮ 正式発注申請 | 依頼者 田中さん | 差額30万円分を正式発注申請 |
| ⑯ 発注承認 | 承認者 | 承認 → 注文書〈補充〉30万円 発行 |
| ⑱ 検収登録 | 依頼者 田中さん | 工事完了後、内容・品質を確認して検収登録 |
| ⑳ 支払締め | 経理担当者 経理 | 550万円(当初)+30万円(補充)= 580万円 の支払締め |
ケース② システム開発(要件定義中に着手が必要)
Section titled “ケース② システム開発(要件定義中に着手が必要)”情報システム部の山本さんが、ECサイトリニューアルをシステム開発会社に依頼するケースです。要件定義はまだ進行中ですが、リリース日が決まっているため先に開発会社を確保する必要があります。
| フローステップ | 担当 | 実際の操作・内容 |
|---|---|---|
| ① 概算見積依頼申請 | 依頼者 山本さん | 「ECサイトリニューアル。機能要件は確定中。概算2,000〜3,000万円。リリース日:6ヶ月後固定」と申請 |
| ③ 見積依頼 | 購買担当者 | 開発会社3社へ概算見積を依頼。「要件定義中のため概算で可」と明記 |
| ④ 概算見積回答 | サプライヤ 3社 | A社:2,200万円、B社:2,800万円、C社:2,000万円(実績が弱い) |
| ⑥ 見積先選定 | 購買担当者 | A社を選定(技術力・実績・概算価格のバランス) |
| ⑨ 仮発注申請 | 依頼者 山本さん | A社・概算2,200万円・6ヶ月工期で仮発注申請 |
| ⑪ 仮受注・着手 | サプライヤ A社 | 仮受注。要件定義支援・基本設計から着手開始 |
| (2ヶ月後)要件定義完了 | — | — |
| ⑫ 再見積依頼 | 購買担当者 | 確定要件書・画面設計書をA社へ共有し正式見積依頼 |
| ⑬ 再見積回答 | サプライヤ A社 | 正式金額:2,450万円(追加機能・API連携コスト) |
| ⑮ 正式発注申請 | 依頼者 山本さん | 差額250万円分を正式発注申請 |
| ⑳ 支払締め | 経理担当者 経理 | マイルストーン別の分割払いで支払締め処理(2,200万+250万 = 2,450万円) |
ポイント: 概算フェーズで選定したベンダーが要件定義から参加するため、仕様の認識齟齬が少なくなります。リリース日固定案件では特に有効です。