探索完成後，中小企應繼續開發，還是就此停步？

先決定是否值得做，再談採購

探索階段最有價值的成果，有時是一個有根據的「不做」。對尚未採購軟件的香港小型專業服務公司而言，如果痛點不大、現有流程稍作調整已能解決，或關鍵限制令新系統無法發揮作用，就應停止原定開發。若欠缺的資料足以左右決定，便先查清；只有問題、可行性和投入理由都站得住腳，才進入開發決策。已付的探索費用，不應成為繼續花錢的理由。

英國 GOV.UK Service Manual 把探索定位為了解使用者、問題及限制，並比較其他做法，再決定是否進入 alpha 階段；研究顯示不值得繼續時，可以停下來。香港企業可借用這種決策方法，毋須把它當成本地法規或指定程序。原指引中的 alpha 是進一步驗證方案，也不等於批准正式系統開發。以下的決策表和個案，是供企業自行使用的建議做法。

沿着個案找出真正的阻塞點

假設一家八人顧問公司覺得新客戶開案太慢，負責人因此想建客戶平台。先抽出一宗近期個案，從收到查詢開始，逐步追到工作範圍獲批：客戶何時交資料、同事何時查核、何時再追問、合夥人何時批准？要把實際處理時間與等候時間分開記錄。若文件早已齊全，卻一直無人決定由誰批核，加一個上載介面也不會令個案自然前進。這是虛構情境，並非客戶成效紀錄。

取樣時不要只挑最順利的個案。可包括習慣中文溝通的客戶，以及分幾次、經不同渠道交資料的客戶，請前線同事說明例外怎樣處理。在這個例子中，可先統一中英雙語收件清單、指定每宗個案的跟進人，再安排每日固定批核時段，文件繼續存放於公司已批准的位置。試行期間記錄追補資料次數及開案所需時間，同時註明個案難度；不能因某星期工作較少，就斷定新做法有效。

用一張表交代決策依據

決策會議應有業務負責人、實際處理文件的同事，以及日後負責系統運作的人參與。填表時附上個案編號、紀錄位置及負責人，不要把功能清單當作證據。限制也須分清楚：客戶協議真的指定文件存放位置，與合夥人習慣沿用舊文件夾，是兩回事。前者須核實能否符合，後者可以討論調整。尚未查證的說法，應放在待查事項中。

計算改流程後還剩多少價值

估算應採用自己公司的數據，並記下來源。以下全是虛構填表示例，並非香港市價，也不是實測結果：假設負責人填入每月可避免的處理工作為十二小時，每小時內部成本為港幣二百五十元，代表每月三千元的人手容量價值。若改流程已消除八小時，剩下四小時，即每月最多一千元、十二個月一萬二千元。釋出工時不等於公司真的少付薪金，必須說明這些時間將如何被有效運用。

再假設這位負責人在表上填入三萬六千元開發預算，以及首十二個月六千元支援費；兩項合共四萬二千元。即使系統一啟用便完全消除餘下工時，首年一萬二千元的容量價值仍不足以支持這筆投入，而且尚未計搬資料、培訓、內部審核及轉換期間的影響。若負責人要求十二個月內回本，而理由只有節省工時，這個方案便應停止。若真正收益是減少錯漏或加快開單，須另附證據及計算，不能重複計入同一批時間，更不能靠虛構新增收入令數字好看。

寫下結論，訂明下一步

決定停止開發後，仍要把有用的流程改善落實下來，指定負責人，並寫明甚麼變化值得重新評估，例如餘下工作量持續增加。若決定繼續調查，就要清楚交代花這筆錢是為了回答甚麼。這家顧問公司可能只需用測試資料，確認現有文件庫能否做到所需的權限安排。若無論答案如何都不會改變是否投資的結論，便沒有理由再延長探索。

若決定繼續，應確認試行改流程後仍有值得解決的問題，其他方案亦已按同一組限制評估，並有人承擔預算及日常運作。接着只批准範圍明確的下一階段，訂出何時必須停下；技術仍未證實時，先做驗證原型，不宜直接承諾整個正式系統。下次管理會議可帶三宗已匿名化的個案時間線及填妥的決策表，指定最後拍板的人。會議結束時，應留下單一結論、支持證據、有負責人的行動及完成日期。

確定仍有軟件需求後，可參閱現成軟件與訂製開發的比較指南，再選擇合適方向。至於訂製軟件服務頁，適合在投資理由成立後，用來準備後續交付討論。眼前這一步，仍是由公司根據證據決定應否繼續投入。