システム上では、
一つの注文は一つの注文です。

商品が7品あれば、
7品が一つの注文にまとまっています。

しかし、
実際の配送現場はそんなにきれいではありません。

---

7品すべてが、同じタイミングで揃うとは限らない

たとえば、
7品の注文が入ったとします。

5品は朝までに準備できた。

しかし2品は加工が必要で、
今日の便には間に合わない。

ではどうするか。

5品だけ先に届けて、
残り2品を翌日に届けます。

現場では、
特別珍しいことではありません。

問題は、
システム側です。

---

「配送完了」の意味が曖昧になる

5品を届けた時点で
注文全体を「配送完了」にすると、

まだ届けていない2品まで
完了したように見えてしまいます。

逆に、
注文を未完了のまま残すと、

今日届けた5品が
まだ配送されていないように見える。

紙や人の記憶で運用している間は、

「残りは明日ね」

で済みます。

しかし、
システムにするとそうはいきません。

---

現場では「注文」より細かい単位で仕事が動いている

実際の業務を見ていると、

注文
↓
ピッキング
↓
出荷
↓
配送
↓
納品
↓
請求

という一方向の流れだけではありません。

途中で、

数量変更、
欠品、
代替品、
翌日配送、
一部キャンセル、

さまざまな変更が起こります。

つまり、

最初に受けた注文と、最後に納品した内容は同じとは限らない。

ここを正しく管理できないと、
後ろにある請求までズレていきます。

---

だから「納品したもの」を基準にする

私たちが運用しながらたどり着いたのは、

注文単位だけを見るのではなく、

実際に何を、いつ、どれだけ届けたのか

を残すことでした。

一つの注文から、
複数回の納品が発生してもいい。

それぞれの納品に、
何の商品が含まれていたかを残す。

そして、
その納品情報を請求につなげる。

言葉にすると当たり前ですが、
実際のシステムではここが非常に重要です。

---

現場の例外を消すことはできない

業務システムを作るとき、

「例外をなくせばシンプルになる」

と考えたくなります。

しかし食材の現場では、
例外そのものをなくすことは難しい。

天候で入荷が変わる。

加工に時間がかかる。

品質を見て商品を変更する。

当日になって数量が変わる。

こうしたことは、
今後も起こります。

だから必要なのは、

例外を禁止するシステムではなく、

例外が起きてもデータが壊れないシステム

なのだと思います。

---

現場をシステムに合わせるのではなく、
現場で実際に起きていることを
そのまま扱える構造を作る。

毎日運用していると、
この違いの大きさを感じます。

---