一套「快好了」很多年的系統
蕬域方舟是一家頭皮養護連鎖診所，門市分布台北、竹北、台中、高雄。
他們很早就想要一套自己的診所管理系統——客戶檔案、療程套餐、治療紀錄、多門市庫存。該想的都想到了，也找了廠商做。
問題是，這套系統做了好幾年，始終停在「建置中」。從來沒有真正上線營運過。
每次問進度，答案都是「快好了」。但「快好了」維持了好幾年。客戶的整個數位化命脈，就卡在一個自己掌控不了的廠商手上——你看得到系統，但你動不了它、拿不回它、也不知道哪天才會好。
我的診斷：問題不是系統爛，是客戶沒有「擁有權」
我接這個案子的時候，第一個判斷不是技術問題。
是擁有權問題。
數位轉型最大的隱形風險，不是系統做得好不好，是——你的命脈被鎖在一個你掌控不了的地方。系統的原始碼、網域、第三方服務帳號，只要這些不在你手上，你就不是這套系統的主人，你只是租客。租客是不能決定房子什麼時候蓋好的。
所以這個案子，我們做的事分兩步。順序很重要。
第一步：先把系統「拿回來」
我們做的第一件事，不是寫任何新功能。
是脫鉤——把系統的控制權還給客戶：
- 移除舊廠商埋在系統裡的私有套件依賴，讓代碼不再綁死在那家廠商身上
- 把網域轉移到客戶自己的主機
- Firebase、Google Calendar 這些第三方服務，全部改用客戶自己的帳號重建
- 程式碼倉庫從廠商的 git 完整 clone 出來，放到客戶自己的 GitHub org
- DB schema 從廠商 PostgreSQL dump 出來，部署到客戶自己的 instance
做完這一步，蕬域方舟才第一次真正「擁有」自己的系統。從租客，變成屋主。
第二步：重做一次，做對
拿回控制權之後，我們把整套系統現代化重寫——新系統叫 Sylvarc（Next.js 16 + Prisma + PostgreSQL）。
從一個客戶第一次走進診所，到他每一次療程的紀錄、簽名、套餐扣課、後續追蹤——整條軌跡，現在都在一套客戶自己掌控的系統裡閉環。
實際模組共 23+ 資料表串成 11 個後台頁面，涵蓋三大塊：
組織管理：4 家門市 / 員工含職稱與組織架構 / GPS 定位打卡 / 請假申請與審批。
業務管理：顧客 CRM 含動態標籤（活躍／沉睡／密接／絲域 等分群）、療程套餐管理（含扣課追蹤與贈品收據）、每次治療紀錄＋客戶電子簽名確認、動態表單系統（初診表／頭皮健康評估問卷，可後台拖拉設計）、標籤管理。
庫存管理：商品（含規格／廠商／售價成本）、批號與效期追蹤、進貨／出貨／調撥、出入庫記錄、盤點明細、警戒清單（庫存預警）。
每個資料表都按真實診所工作流設計——例如套餐使用紀錄不只記次數，還記是哪位員工、哪家門市、哪次治療紀錄使用的，可向上追溯到原始套餐與該客戶完整療程史。
第三步：上線後持續迭代
Sylvarc 上線後持續隨客戶的真實反饋迭代。例如：
- 客戶提出要管理同一商品的不同規格 → 我們把 ProductStockSetting model 切出來，每家門市可獨立設定庫存警戒值
- 出勤模組原本只記打卡，客戶提出要支援補打卡與請假關聯 → 我們把 AttendanceRequest model 加進去，補打卡與請假合併在同一審批流
- 動態表單原本只有靜態 schema，客戶提出新患者要不同問卷 → 把 FormTemplate / FormInstance 拆出來，後台可拖拉設計新表單版本
系統不是交付完就結束，是跟著診所的營運一起長。
川輝交付了什麼
| 項目 | 內容 |
|---|---|
| 起點 | 一套多年「建置中」、從未上線、客戶掌控不了的系統 |
| 第一步 | 代碼脫鉤、網域與第三方服務轉移——把系統還給客戶 |
| 第二步 | 現代化重寫為 Sylvarc（Next.js 16 + Prisma）：23+ models / 11 dashboard 頁 / GPS 考勤 / 電子簽名 / 動態表單 / 多維庫存 |
| 第三步 | 上線後持續迭代（庫存 Phase 2 進行） |
| 規模 | 4 門市 / 10 員工 / 170 顧客 / 18 療程項目（系統概覽實數） |
| 現況 | 客戶完全掌控、主導權在自己手上 |
蕬域方舟怎麼說
「以前那套系統永遠『快好了』，我們卻什麼都不能做。川輝先讓我們真正擁有自己的系統，再把它做好——這次，主導權在我們手上。」 — 蕬域方舟 Sylvarc（川輝代擬，已授權公開）
熊董的話
很多老闆挑系統，只看功能。但功能再多，如果原始碼、網域、帳號不在你手上，你就不是這套系統的主人。
我接蕬域方舟這個案子，做的第一件事不是開發，是先把系統還給客戶。因為數位轉型真正的地基，不是功能，是擁有權。一套你掌控不了的系統，做得再好，都是別人的。