《從 Excel、Line、紙本卷宗，到一套自己的案管系統：一間法律事務所的六個月》

一、一開始的問題，不是「沒有系統」

六個月前我接到的需求，聽起來很單純：「我們想要一個可以看案件的系統。」

但坐下來問了幾輪之後，真正的問題長這樣：

• 案件資訊散在 Excel、通訊軟體、紙本卷宗，三份資料互相矛盾，沒有人知道哪一份是對的。
• 執行合夥人想知道的是「這個案子做了多久、賺不賺錢」；助理每天面對的是「這份文件要歸到哪」。這兩件事之間沒有任何一條線把它們接起來。
• 每個月結算時，大家憑印象回想，回想出來的數字沒有人敢負責。

所以真正的問題不是「缺一套系統」，而是：事務所的工作流程從來沒有被寫下來過。 它活在每個人的習慣裡，而每個人的習慣都不一樣。

系統只是把這件事逼出來的工具。這是整個專案裡我學到最貴的一課寫在最前面。

二、怎麼拆流程：不要從功能表開始，要從一天開始

很多人做內部系統的第一步是列功能清單：案件管理、客戶管理、文件管理、報表……列完看起來很完整，做完沒有人用。

我改成問一件事：「事務所的一個案子，從進門到收到錢，中間經過哪些人的手？」

拆出來是這樣一條線：

洽詢進來 → 利益衝突檢核 → 建檔給案號 → 分派承辦

   → 每天執行、記錄工時 → 產生費用與代墊

   → 開請款單 → 收款 → 入帳核銷 → 分潤結算

有了這條線之後，功能就不用「想」了，功能就是這條線上的每一個交接點。而且更重要的是——我知道哪裡可以先不做。

第一版上線的時候，這條線上我只做了兩格：登入，和一張建檔表單。就這樣。

三、怎麼設計：三個決定影響了後面六個月

技術棧我選 Next.js + Supabase + Vercel。原因很務實：一個人要同時做開發跟顧問，部署和權限這兩件事不能吃掉我的時間。Supabase 的 RLS（資料列級權限）讓「誰能看到哪些案子」變成資料庫層的規則，而不是散落在程式碼裡的 if 判斷——這件事後來救了我很多次。

但真正關鍵的不是技術選型，是這三個設計決定：

1. 案號用民國年，不用西元年。
聽起來很小。但事務所所有的紙本卷宗、法院文書、既有檔案櫃都是民國年。如果系統用西元年，每個人每天都要在腦中換算一次——而人每天要做的換算，最後一定會變成拒絕使用的理由。系統要遷就既有習慣，不是反過來。

2. 填寫成本必須低於原本的做法。
如果助理原本在 Excel 填三格，我的系統要她填八格，那這套系統就已經輸了，不管介面多漂亮。所以每一個欄位我都要能回答「不填會怎樣」，答不出來的就砍掉。

3. 下拉選單不准寫死。
早期我把律師名單寫死在程式碼裡，結果每次人事異動我就要改一次 code、重新部署一次。後來全部改成從「律師管理」頁動態載入。任何會變的東西，都要讓客戶自己能改。 否則你不是在交付系統，你是在把自己綁成人肉客服。

四、上線之後才發現的事

這段是我覺得最值得寫下來的部分，因為沒有人在專案開始前會告訴你這些。

第一，最先暴露的不是 bug，是流程本身的矛盾。
系統一上線，同一筆錢兩個單位都主張是自己的收入——這個矛盾在 Excel 時代一直存在，只是因為兩邊各自有一份表格，沒有人會去對。系統逼你只能有一個答案。於是我花了很多時間做的不是寫程式，是坐在會議室裡讓兩邊把規則講清楚。上線的前三個月，我有一半時間在當翻譯，不是在當工程師。

第二，四月我 commit 了 180 次，五月掉到 43 次——那不是專案停擺。
那是使用者在消化。新功能丟出去之後需要時間變成習慣，這期間你要做的是閉嘴、觀察、記錄他們卡在哪，而不是繼續丟新功能進去淹死他們。後來我學會把節奏排成：衝刺 → 沉澱 → 修正 → 再衝刺。你看 7 月又回到 119 次，那就是第二波。

第三，66 個資料庫 migration，說明需求是長出來的，不是規劃出來的。
我一開始還想「要不要先把 schema 設計完整再開工」。現在的答案很明確：不用，也不可能。真實的需求只有在有人真的用了之後才會浮現。你要做的是讓改動變便宜，而不是讓規劃變完美。

第四，最有價值的功能，通常是最不像功能的那個。
系統裡我自己最滿意的一頁，是「財會基本功」的科普說明頁——它沒有任何互動邏輯，就是解釋代收代付、事務費、應收帳款是什麼意思。因為我發現助理填錯欄位不是因為介面難用，是因為他們不知道這個欄位在會計上代表什麼。 補知識比補 UI 有效。

五、第二章：財務模組，現在正在打

七月開始，我把重心移到財務。這一塊比案件管理難十倍，原因是：律師的語言和會計師的語言不一樣，而系統必須同時對兩邊負責。

目前做出來的幾件事：

• 支出與代墊的審核關卡：登錄 → 審核（核准／駁回）→ 隔兩個工作日出款，出款日自動跳過國定假日。把原本靠人情和催促跑的流程，變成有狀態、有紀錄、有時間軸的流程。
• 銀行交易核銷：可以直接上傳銀行對帳檔解析入帳，和系統裡的應收比對。
• 科目表對齊會計師：不是我自己設計一套科目，是拿會計師的版本進來對。系統的帳最終要能交給會計師，那就從第一天開始講同一種語言。

而這個模組真正的地基，其實是一句話的決定：以銀行流水為準。

聽起來像廢話，但在做出這個決定之前，同一筆錢有三種說法——收據上的、手寫帳上的、銀行上的。定下「銀行說了算」之後，所有的爭議瞬間都有了裁判。系統設計裡最重要的東西，往往不是功能，是這種你必須先讓所有人同意的那一句話。

六、如果重來一次

1. 先做最小可用的一格，不要先做完整的架構。 我的第一版只有一張表單，這是對的。
2. 把「誰負責填」當成技術問題一樣認真對待。 沒有負責人的欄位，永遠是空的。
3. 每一次上線後，去坐在使用者旁邊看他填一次。 你會看到你在螢幕前永遠想不到的東西。
4. 凡是會變的，都讓用戶自己能改。
5. 做內部系統，你交付的從來不是程式，是一套被講清楚的工作方式。 程式只是它的載體。