前陣子我跟我的會計師聊天。他手上一堆中小企業的帳，看過的系統比我多。
聊到一半他講了一句話，我到現在還常想起來：
「我現在已經不敢跟客戶介紹系統了。」
不是他不懂系統，是他看過太多次同一個結局。客戶花幾十萬買一套小型 ERP，上線半年後，員工不學，那套系統最後只拿來開發票。內帳回到 Excel 手動記，外帳整包丟給事務所。錢花了，系統也還掛在那裡，只是沒人在用。
我一開始想說，那就是買錯了嘛——通用型的系統硬套在服務業上，本來就不合。這樣講也沒錯，但不是全部。
後來我看多了才發現，更常見的死因是另一個：沒有人在養它。
買車的錢你會算，養車的錢呢
你要買一台車，牌價多少、標配有什麼、選配要不要加，你一定會問清楚。可是真正決定這台車開不開得下去的，是牌價以外的那些——保養、保險、停車位、油錢、每年驗車。這些沒有印在型錄上，但每個開過車的人都知道要算。
系統這件事，大家只看表面的價錢。
報價單上寫的是導入費用。上線之後呢？誰看它有沒有在跑？資料庫滿了誰會知道？某個外部服務改規格，你的自動對帳悄悄停掉，你可能一個月後才從數字不對發現。這些都不在報價單上，但它們就是這套系統的維護費。
不算，不代表不用付。只是換一種方式付——通常是哪天出事了，一次補回來。
做出來變快了，「養」沒有
現在 AI 讓「做出來」這一段變得非常快。以前要三個月要養團隊要幾十萬起跳的東西，現在一兩週就有能用的版本。這是真的，我自己在做，我知道有多快。
但 AI 只縮短了「做出來」這一段。上線之後每天要看著它、出事要有人修的那一段，一天都沒有變短。
前陣子網路上有個很紅的例子——一個做影片的團隊用 AI 寫程式做了個工具，上線當天爆紅、伺服器掛掉，第二天被挖出資安漏洞，同時一堆長得很像的競品冒出來，全公司在救火的只有寫程式的那個人。
我看那件事沒有在看熱鬧。那只是把很多老闆接下來會遇到的事，用比較快的速度演了一遍給大家看。
我旁邊就有一個現在進行式
我有一個做汽車零件批發的朋友，正在自己建一套新系統。外面的系統商報過價，他嫌貴，決定自己來。
他的系統將來要給公司幾十個人天天用，資料量不小，庫存、報價、採購、銷售、會計、退貨全部要串起來。
他跟我講過一句很實在的話：「如果沒有一次把這些做完，完整的 ERP 不能 run。」
我懂他的意思，但我一直在拉他回來——先把庫存這個核心做上線，其他的當功能模組一個一個加。
為什麼？不是因為我覺得他做不完。是因為一次做完的東西，出事那天你不知道錯在哪。
六個模組同時上線，某天對帳數字不對，你要從哪裡查起？六個地方都有嫌疑，而且它們互相牽動。反過來，如果庫存已經穩穩跑了兩個月你才接上採購，那出事的那一天，答案幾乎是寫在臉上的。
分批上線不是為了做得比較輕鬆，是為了讓未來的你查得出問題。
他還有一個時間壓力：舊系統的合約年底就要續約了。這種 deadline 反而是好事——它逼著你面對「能不能上線」這個真問題，而不是無限期地再多加一個功能。
那「養」到底要養什麼
講三件我認為最該先做的。三件都不用花什麼錢，但沒做的話，之後補的代價很高。
第一，自動化只能填單給你簽，不能自己動手。
現在很多人在系統裡放 AI 或自動化，讓它自己抓資料、自己更新、自己跑排程。方便，但你要問一句：它有沒有可以直接改資料的權限？改了誰會知道？
正確的做法是給它讀的權限，不給它寫的權限。它想改什麼，一律變成一張待審的單子，你按下去才生效。
這件事你其實早就懂。你公司的會計不能批自己的請款單，出納跟記帳要分開——這是幾百年前就發明好的規矩。現在只是把對象換成 AI 而已。
而且重點不是「規定它不准改」，是它手上根本沒有那把鑰匙。有鑰匙而靠自律，總有一天會出現「這次比較急，先跳過」。
第二，從來沒響過的警示，先不要相信它。
大部分系統都會跟你說「我們有監控」。這句話本身沒有錯，但你要再往下問兩個問題：這些警示，上線到現在有沒有真的響過？它的條件是照什麼設的？
我幫老闆看系統的時候常常碰到這種情況：警示是有設，但從來沒響過。不是系統真的都沒事，是條件設得太寬——例如硬碟要滿到 99% 才通知，等它通知的時候早就當了；或者通知是寄到一個沒人在看的信箱。壞掉的檢查跟正常的檢查，在螢幕上長得一模一樣，都是一片安靜加一個綠色勾勾。
所以我自己的習慣是，每個警示設好之後，找個時間故意讓它觸發一次，看通知有沒有真的送到人手上。沒響過的警示，我一律當成還沒設好。
第三，報表要會說「這裡我看不到」。
這一題最容易被跳過，也最容易出事。
你每個月看的那份報表，如果它有一段資料抓不到，它會告訴你嗎？還是就默默跳過，然後結論還是寫「一切正常」？
一台死掉的監控機器，跟一個完全健康的系統，交出來的報告是一樣的——都說沒問題。
所以報表的第一行不該是結論，該是「我現在確實看得到這些資料來源」。看不到的部分要明講出來，不能安靜地漏掉。
安靜看起來很像健康。這是我看過最貴的一個誤會。
最值錢的修理，常常只是一個數字
還有一種狀況，我在客戶現場遇過很多次：系統一直卡、一直當、一直要重開，問廠商，廠商說「大家都這樣用」。
可能真的大家都這樣用。可是大家的量不是你的量啊。
軟體的預設值是照著開發者見過的環境調的，不是照著你的生意調的。同一個預設值在別人那裡很寬鬆，在你這裡可能剛好卡在邊緣——差別不在系統有沒有壞，而在你一分鐘跑幾筆單。
這件事最近有位工程師 Ping-Lin Chang 寫過一篇很精采的紀錄。他有個服務兩週內壞了五次，每次都要人工重建。查到最後發現，是一個保留筆數的預設值，換算成他自己的流量之後，只夠撐九分鐘——所以任何一次超過九分鐘的延遲，那台機器就必死，不是意外，是必然。他把那個數字調大，撐的時間變成九十幾分鐘，成本是幾百 MB 的硬碟空間，同類事故從此歸零。
他那兩週做過最有價值的工程，是改了一個數字。
而且那個數字在任何說明書上都查不到，因為那個預設值只在他那裡是錯的。只有實際去量自己的流量，才看得見。
（原文在這裡：https://pinglin.tw/blog/the-cluster-you-do-not-watch ，寫給工程師看的，但那個思路每個老闆都用得上。）
回到我的會計師
他不敢跟客戶介紹系統，不是因為市面上的系統都很爛。
是因為他知道，賣完之後就沒人管了。買的人不會養，賣的人養完保固期就走，中間那段沒有人。
我做的事情，講白了就是站在那個中間。
sprint 是把東西做出來，月費是陪你把它養活。第一件事現在很多人能做，第二件事願意做的人不多——因為它不性感，沒有 demo，成果是「什麼事都沒發生」。
可是回頭看那些活下來的系統，靠的都是第二件。
你們公司現在跑著的那套系統，如果今天晚上它悄悄停了，明天早上誰會第一個發現？
常見問題
AI 讓開發變快，系統維護也會變快嗎？
不會。AI 縮短的是「做出來」那一段；上線之後每天要有人看著它、出事要有人修的那一段，一天都沒有變短。導入預算老闆會算，維護預算沒人算，而那筆帳才決定系統三年後還在不在。
系統上線後最該先做的三件事是什麼？
一、自動化只給讀的權限，想改資料一律變成待審的單子，人按下去才生效。二、每個警示設好之後故意觸發一次，確認通知真的送到人手上；從來沒響過的警示先當成還沒設好。三、報表第一行不寫結論，先寫「我現在確實看得到這些資料來源」，看不到的要明講。
ERP 應該一次全部上線，還是分模組上線？
分批。一次上線六個模組，出事那天你不知道錯在哪；先讓核心（例如庫存）穩穩跑兩個月再接下一個，出問題時答案幾乎寫在臉上。分批不是為了輕鬆，是為了讓未來的你查得出問題。