受注管理の例外処理設計｜変更・取消・分納・承認を状態遷移表にする

受注管理は、注文を登録する通常フローだけなら単純に見える。実際に詰まるのは登録後だ。納期が変わる、数量が減る、一部だけ先に出す、値引の承認を待つ、出荷後に取消依頼が来る。例外を担当者の判断へ寄せるほど、最後は管理職がメールと伝票を見比べることになる。

販売管理と、取引先から注文を受け取る仕組みの違いは販売管理と受発注システムの境目で整理している。この記事は注文が入った後の例外を、状態遷移表へ落とす方法に限定する。

例外を「担当者が頑張る仕事」にしない

例外処理が属人化するのは、判断力の差だけが原因ではない。現在の状態と、変更してよい範囲が見えないことが大きい。同じ納期変更でも、出荷指示前なら受注を直せる。出荷指示後なら物流への連絡が要る。出荷後なら変更ではなく返品や再出荷の処理になる。

そこで例外名を並べる前に、通常取引の状態を決める。状態は「営業処理中」のような担当部署名ではなく、その時点で何が完了し、次に何を実行できるかが分かる名前にする。

1. 受付済み：注文内容を受け取ったが、引当や承認は未完了
2. 確定済み：単価、数量、納期、納品先が確定
3. 出荷指示済み：物流側が作業へ着手できる
4. 一部出荷済み：残数があり、受注は継続中
5. 出荷完了：受注数量の出荷が完了
6. 請求確定：請求内容が確定し、受注側の直接変更を禁止

状態遷移表の列を固定する

状態遷移表は、現在状態と次の状態だけでは足りない。誰が実行できるか、何を更新するか、後工程へ何を伝えるかまで同じ行へ置く。

さらに更新項目、変更理由、履歴、実行者を列に加える。表が横に広くなっても、例外ごとにメールや口頭のルールを持つより、確認する場所は一つになる。

変更は項目ごとに締切状態を決める

「確定後は変更不可」と一括で決めると現場に合わない。納品先は出荷指示まで変更できても、単価は承認後に変えられないかもしれない。項目ごとに、直接変更できる最終状態と、それを過ぎた場合の処理を決める。

• 数量：引当や出荷済み数量を下回れない。減数は在庫引当を戻す。
• 納期：出荷指示後は物流側の可否確認を必須にする。
• 単価：承認済み条件から外れる場合は再承認へ戻す。
• 納品先：送り状作成後は変更ではなく再発行として扱う。
• 請求先：請求確定後は元取引の上書きを禁止し、訂正処理へ分ける。

上書きできない状態を決めると、履歴の残し方も決まる。変更前後、理由、受付者、実行者、承認者、日時を残す。誰が間違えたかを探すためではなく、後工程がどの情報を前提に動いたかを確認するためだ。

取消は削除ではなく、影響を戻す処理にする

受付直後なら削除に見える取消でも、在庫引当、発注、出荷、売上、請求が進んでいれば、それぞれを戻す必要がある。受注レコードだけ消すと、後工程に取り残された処理が見えなくなる。

取消の完了条件を「受注画面で取消になった」にしない。影響する後工程が整合した時点を完了とする。そうすれば、営業側は取消済みなのに請求だけ届く、といった事故を追いやすい。

分納は親受注と実行単位を分ける

分納では、一つの受注に複数の出荷と請求がぶら下がる。受注全体の数量と、各回の実行数量を同じ状態で持つと、「一部出荷済みなのに受注完了」「残数があるのに請求完了」といった食い違いが起きる。

• 親受注には受注総数、出荷累計、残数、全体状態を持つ
• 出荷単位には出荷日、数量、納品先、出荷状態を持つ
• 請求単位が出荷と一致しない場合、対応関係を持つ
• 残数取消は親受注の総数を上書きせず、取消数量を履歴に残す
• 完了は残数と未処理の出荷・請求がないことで判断する

承認待ちを受注の外へ追い出さない

値引、与信超過、特別納期などの承認をメールだけで行うと、受注画面は確定に見えるのに実際は止まっている状態が生まれる。承認待ちを状態として持ち、申請理由、基準値、申請者、決定者、期限を受注へ結びつける。

IPAの「機能要件の合意形成技法」は、要件の抜けや認識のずれを防ぐため、システムの振る舞いやデータモデルを図表に書き、発注者と開発者が一緒にレビューする考え方を示している（IPA公式資料）。受注例外も文章で「柔軟に対応」と書かず、状態と許可する遷移を表で合意する。

権限は役職名ではなく、遷移ごとに決める

「管理者はすべて変更できる」という権限では、緊急対応は早くても履歴と責任が曖昧になる。状態遷移表の各行へ、申請できる役割、承認できる役割、実行できる役割を置く。同じ人が複数役割を持つ場合でも、どの役割で操作したかを残す。

• 受付担当は変更依頼を登録できるが、確定値を直接上書きしない
• 営業責任者は値引や条件変更を承認する
• 物流担当は作業着手後の変更可否を回答する
• 管理担当は請求確定後の訂正方法を決める
• システム管理者は権限を設定するが、業務承認を代行しない

緊急時に通常承認を待てない場合は、緊急遷移を別行にする。使える条件、実行者、事後承認の期限、通知先を定める。「急ぎだったから管理者が直した」を通常運用へ混ぜない。

例外キューに期限と次の一手を持たせる

状態を作っても、承認待ちや変更確認中が一覧で見えなければ放置される。例外キューには受注番号、現在状態、止まっている理由、次に動く人、期限、顧客へ回答した内容を持たせる。担当者別だけでなく、期限超過と後工程への影響で並べ替えられるようにする。

管理職が見るのは全受注ではなく、基準を超えた例外だけでよい。現場で判断できる行を増やし、承認が必要な行には必要な材料をそろえる。これにより「どうしますか」という相談ではなく、現在状態と選択肢を付けた判断依頼へ変えられる。

来週作るなら、実例から一枚にする

1. 直近に起きた変更、取消、分納、承認待ちを集める。
2. 各事例で、依頼時点に何が完了していたかを書く。
3. 現在状態、イベント、次状態、更新項目、通知先へ分解する。
4. 現場担当と後工程担当が同じ表をレビューする。
5. 判断が割れた行だけ責任者へ上げ、基準と決定者を固定する。

販売管理ソフトを選ぶ前の比較軸は中小企業の販売管理ソフト選定も参考になる。製品機能を確認するときは、通常受注の登録画面だけでなく、この状態遷移表の各行を実演してもらう。例外が処理できるかだけでなく、履歴、通知、権限、後工程の整合まで確認する。

改善効果は、例外件数を無理に減らすことではなく、処理中の例外が一覧で見えるか、責任者への確認往復が減ったか、出荷・請求との不一致を追えるかで測る。例外を消すのではなく、誰でも同じ状態から判断できるようにするのが受注管理の役割だ。