功能可以一直加，但誰來整理、誰來顧
過去企業常見的困擾是系統太少。接下來較常見的，會是系統太多、全貌無人掌握。
增加功能變得很容易
業務部以 AI 做了一個報價工具。倉庫做了一個盤點的小程式。會計委託外部製作對帳的外掛。經營者自己做了一個檢視業績的儀表板。每一項都解決了當時的問題，花費也不高。
兩年後，公司內有十幾套工具同時運作。這時常會遇到幾個基本的問題：
- 客戶資料以哪一份為準？
- 製作報價工具的同仁離職後，由誰負責修改？
- 儀表板的數字與會計報表不一致時，以哪一個為準？
- 哪些系統有備份？最近一次確認備份可以還原是什麼時候？
- 其中一套突然無法使用時，會影響到哪些人？
這些問題往往沒有人能回答，因為從來沒有人被指定負責回答。
成本移到了維運
過去開發系統的成本集中在撰寫程式，企業因此相當謹慎，一套系統使用十年。現在撰寫的成本降低，成本移到以下幾項：
- 理解。每一套工具都需要有人了解它的用途與做法。
- 銜接。系統之間的資料需要對得起來，這件事需要有人安排。
- 日常作業。帳號、權限、資料修正、使用上的詢問，每一套都有。
- 變動。法規、流程或合作廠商改變時，受影響的系統都要調整。
- 異常處理。出事時需要有人知道從哪裡查起。
這些成本不會出現在報價單上，因此容易被忽略。它們通常以另一種形式呈現：幾位同仁越來越忙，卻不容易說明忙碌的內容。
維運是資源調度的問題
企業的人力與注意力有限。每增加一套系統，就需要從中分出一部分來維護。
以現在的工具，功能幾乎都做得出來。因此更需要評估的是以下幾點：
- 新增的系統之後由誰維護？這位同仁目前還有多少餘裕？
- 它與現有的哪一套重疊？能否以現有系統調整來滿足？
- 是否有系統已經可以停用，把人力移過來？
- 哪一套系統故障時影響最大，值得投入較多的維護資源？
這屬於管理層面的判斷，需要一位掌握全貌的人。在許多公司裡，這個位置目前是空缺的。
企業需要的顧問型態有好幾種
過去委託軟體公司，是請對方製作一套系統，完成驗收後合作即告一段落。這個模式在撰寫程式成本很高的年代相當合理。
現在企業在不同階段有不同的需要：
- 尚未開始：協助判斷是否需要開發、現成產品是否足夠、先做哪一段。
- 內部自行開發中：協助檢視方向與資料結構，提醒日後可能出現的問題。
- 委託他人開發：站在企業這一邊驗收，確認交付的成果日後維護得動。
- 上線之後：長期掌握全貌，系統增加時協助維持秩序。
- 已經雜亂：協助盤點、整理，並決定保留哪些。
這幾種需要的共同點是判斷，包括在適當的時候建議暫緩開發。
信任的來源
顧問關係建立在信任上。信任來自幾件具體的事：
- 顧問會建議暫緩某些項目，即使開發這些項目對顧問有收入。
- 顧問的說明清楚易懂，不以術語造成隔閡。
- 顧問提出的時程與範圍，事後都如實完成。
- 出問題時找得到人，顧問也願意承擔責任。
- 顧問記得公司的狀況，不需要每次從頭說明。
這些都需要時間累積。因此如新科技通常建議從一件小事開始合作，例如一次需求的釐清，或一次現有系統的盤點，雙方合適再繼續。
一個簡單的起點：列出公司目前使用的所有系統、試算表與小工具，並在每一項後面註明維護者。註明不出維護者的項目，通常是風險最高的地方。
常見問題
公司的系統越來越多，該怎麼整理？
通常從盤點開始。列出目前有哪些系統與工具、各自管理什麼資料、由誰使用、由誰維護、彼此如何交換資料。這張清單完成後，重複的、無人維護的、故障時影響最大的系統，多半已經看得出來。
AI 開發的系統，維護成本會比較低嗎？
開發的成本降低了，維護的成本大致不變。系統上線後仍需要有人處理帳號、修正資料、因應流程改變、確認備份，並在出事時查明原因。AI 可以協助其中一部分，仍需要一位了解全貌的人判斷與負責。
什麼是開發顧問？和外包廠商有什麼不同？
外包廠商依規格交付一套系統，交付後合作通常告一段落。開發顧問長期站在企業這一邊：協助判斷該不該做、如何安排順序、驗收他人或 AI 完成的成果，並在系統增加時協助維持整體的秩序。
中小企業需要專職的資訊人員嗎？
視規模而定。許多公司的規模尚不需要一位全職的資訊主管，卻已經需要有人負責。這個階段可以採用每月固定時數的長期顧問，需要時再增加。