工廠的製造執行系統

先用榔頭敲下去再說…

大約近一年前，我在歐洲的遠端工作，接手了一個很特別的軟體專案，而該專案讓我覺得有點回天乏術、幾乎不知道該怎麼治療。

該專案是玻璃工廠的製造執行系統 (Manufacturing Execution System)，它的功能是：「協調於工廠現場的生產活動，從接收生產訂單開始，到產品完成入庫為止的整個製造過程。」

投資開發該軟體的公司是一間玻璃製造工廠，人數約 50 人左右。而開發該軟體的工程師則是一位 Clojure developer ，他一個人花費了若干年，在拼湊之中把整個系統建置出來。他打算開始新的事業時，就將該軟體轉介給我老闆。

軟體的功能與狀況

1. 生產排程與調度: 根據訂單需求和產能，優化切割、成型等工序的排程。

2. 生產執行監控：即時調整每一生產步驟（如熔窯、切割機、鋼化爐）的參數與生產結果。

3. 品質與數量報表：即時呈現現在產品、半成品的品質與數量。

如果跟超過 1000 人的工廠的製造執行系統比較的話，該軟體可以說極度地簡化，因為機台的資料都還沒有跟串接，甚至可以說，數位化只做了一半而已。甚至拿該軟體去跟一些 50 人以下的中小企業的企業內部系統比較的話，該軟體表面上也沒有特別複雜，因為大概就是 7~8 個主要的 UI 、資料庫裡 10 多張 tables 。

然而，很不幸的事情是，該軟體是此生我所見過最多 bug 的系統、情況最糟的系統之一。比方說：

1. 軟體剛轉手時，布署 dev 版本的機器名稱叫做 prod，布署 prod 版本的機器名稱叫做 dev。這種東西為什麼可以不修改？

2. 程式碼裡有許多 hardcoded 的東西，比方說，寄 Email 使用的帳號、密碼。通常這些東西應該會透過環境變數載入吧？

3. 產品料號與生產工序之對應關系延遲了半年而沒有更新。為什麼呢？更新產品料號與生產工序之對應關系，沒有任何的管理介面可讓工廠的員工自行維護。根據工廠的員工表示，他們通常就是用 Excel 畫出一張產品料號與生產工序的對應表格，交給之前的工程師，而該位工程師會設法寫入資料庫。我跟同事在該專案所做的第一項大改進，就是在有限的預算裡，先做出一個命令列式的管理介面，至少日後要更新資料庫，可以有一些基本的檢查。

4. 它的 UI 幾乎有 1/4 的頁面都有 bug 。我幫該公司修復的其中一個 bug 就是 UI 的 bug 。UI 用單頁式應用程式 SPA 的方式做，而且用了可拖曳元件 (drag and drop)，我修復的就是可拖曳元件。

5. 它有一個模組會週期性地呼叫 API ，同步遠端的資料。與第三方整合的部分，只要第三方的 API 不穩定就會出錯。但是，要了解 API 的運作只能透過看 API 呼叫的 Logs 。很不幸地，又是只有工程師有辦法看這些介面。

6. 資料庫裡沒有設置夠嚴格的限制 (constraints) ，所以一旦有少數的品項繞過了 UI 的檢核，就在資料庫裡發生了重覆。然後，在使用者的前端就會看到異常。

投資不足與榔頭模式

首先，能夠造就狀況如此糟的軟體，自然跟案主的態度極有關。玻璃工廠也許是因為創業的初期缺乏資金，所以東省西省，把品質也省掉了。

雪上加霜的，則是一種十分普遍的解決問題模式：「過度應用熟悉工具」模式，可以簡稱為榔頭模式，因為不管是什麼問題，就是用熟悉的程式語言先硬刻再說。

這個模式主要表現在三個方面：

1. 製造執行系統裡，其實有報表的部分，這些報表的本質是一種 BI (business intelligence) 問題，可以考慮用現代資料棧 (Modern Data Stack) 來處理。然而，原作者還是用 Clojure 硬刻。

2. 製造執行系統裡，其實有生產排程相關的部分，這些生產排程問題的本質是一種工程流程 (workflow) 問題，可以考慮用專門的工作流程軟體來處理。當然，原作者還是用 Clojure 硬刻。

3. 製造執行系統是一種企業內部系統，既然是企業內部系統大可不必有極度精美的 UI ，換言之，可以用多頁面應用程式 (MPA) 來開發 UI 即可。

後記

我並沒有成功地讓該專案變得更好。我跟玻璃工廠的客戶提案來對軟體專案做大幅地改進之後，似乎被客戶認為我收費過高，於是客戶主動結束了合作關系。