我們用 SMART——Specific（具體）、Measurable（可衡量）、Achievable（可達成）、Relevant（具關聯）、Time-bound（有時限）——把每個故事拆成五天，作為每次動手造輪子前的五個檢查問題。

本篇是故事二「RFID 天線還沒選型，RD 先要求它配合手上那條饋線」的 Relevant 篇：這項工作與客戶價值、專案目標及交付有什麼關係？

本篇定位：討論局部的成本最佳化如何在系統層級變成更高的總成本，以及方便是如何被轉嫁的。

當時發生了什麼

順序講清楚之後，剩下最後一個、也最難反駁的理由：省錢。

「這條線已經買了，放著也是放著，用它就是省下來的成本。」這句話在任何場合都站得住腳。沒有人想當那個為了理論正確，就要求公司多花錢的菜鳥。

更麻煩的是，現場驗證先一步戳破了它最漂亮的理由。當初的主張是「接頭統一」，聽起來清爽好管；但通過驗證的候選天線只剩另一種接頭型式，「統一」的前提自己先破了。要用那條線，反而得加一顆轉接頭：多一個料號，多一個接點。

於是我們往下走一次那條路。線長固定，讀取器只能擺在這個長度接得到的位置，而那位置原本要放別的東西，機構得改一次配置。剩下的寫上白板：走線槽重開、裸露段加防護件、施工工時、特規備品。

每一項都很小，每一項都要有人畫圖、採購、到現場鎖上去。列完之後，那條線是不是「本來就有」已經不重要了。

真正的問題在哪裡

這裡的錯不是省錢，是把成本算在錯的邊界上。

在料件表這一格上，用庫存確實省下一筆，數字明確、寫得進報告。但為了配合它長出來的成本散落在別人的表上：機構的重畫工時、採購的轉接頭與防護件、施工時間、維修多一個料號，以及最難估的一項——射頻路徑多出的不確定性，往後每次讀取異常都得多排除一個可能。

節省是集中的，代價是分散的。集中的會被記住，分散的沒人統計。於是一個在局部帳面上成立的決定，在系統層級可能是虧的，而且沒有報表會告訴你。

成本轉嫁是同一件事的另一面。對提案的人來說，這決定省去了重新選線、報價、確認交期的工作；而這份方便沒有消失，它變成機構的改圖、採購的請購單、產線的組裝工序，以及維修人員某天在客戶現場對著一顆奇怪的轉接頭愣住。

前一個故事談過好的架構不該讓需求停在入口排隊；硬體版本是：好的料件決策不該讓其他角色排隊替它收尾。判斷一項決定是否 Relevant，不能只問「它幫我省了什麼」，要問「它把工作推給了誰」。

可以怎麼做

不必做精算報表，但有兩個習慣值得養成。

第一，算總持有成本（TCO，total cost of ownership），不是算單價。 列表之前先拆開一件事：那條線的錢無論用不用都已經付掉，它是沉沒成本（sunk cost）。「放著也是放著」聽起來像替專案省錢，實際上是拿一筆收不回來的支出，替未來的決定背書。正確的比較基準只有一個：用它之後未來還要多花什麼，不用它之後未來還要多花什麼——兩邊都只算從今天起才發生的錢。

這張表不必精確到金額，作用是讓分散的成本出現在同一個畫面上。很多決定只要被完整列出來，就不必再爭論。

第二，回頭對一次專案目標。 這套系統存在的理由是讓物品經過時被自動讀到，每項決定都該說得出它與這件事的關聯。用庫存饋線讓讀取更穩定嗎？不會。讓交期更快嗎？線本身是，被牽動的機構變更未必。讓維護更容易嗎？相反。一個決定對主目標沒貢獻，卻對其他環節產生負擔，它就不算最佳化，只是把成本搬個地方。

另一個容易被忽略的是機會成本。為配合線長而固定的讀取器位置，可能剛好是未來改流程時最卡的位置。硬體決策的黏著度比軟體高：程式可以改版重推，鎖進機構裡的走線不會。

真要用庫存料件，也有負責任的用法：讓它以候選身分走完現場驗證，把為它增加的配套列出來，在紀錄裡寫清楚「我們知道多出了什麼，仍然選它」。有這段紀錄，它是決定；沒有，它只是習慣。

今天學到的事

局部最佳化最危險的地方，是它永遠能出示一個真實的節省數字。問題不在數字準不準，在它涵蓋的範圍太小——小到把整個系統為此付出的代價全排除在畫面之外。

有時候我們不是在節省一條線，而是花整個系統的成本，證明那條線沒有白買。話說回來，把選型一直往「再多驗一點」推也不是答案：需求、候選、實測都要時間，專案不會等我們試完每種組合。那麼這件事該花多久，什麼時候必須停下來做決定？這一題還沒有答案。