TailorMed — 多地區系統架構評估
此文件記錄 TailorMed 海外擴展（US / JP）情境下，Airtable 系統共用方案的風險評估、說明框架與架構建議。
1. 背景與情境
現況
- TailorMed TW 的 CRM / OMS / FIN 三套 Airtable Base 已建置完成或正在開發中
- 正籌備海外獨立法人事業體（TailorMed US、TailorMed JP）
- 海外前期業務：承接原本要交給當地 Agent 的業務，由海外投資事業體直接接單
- TailorMed 初步想法：直接沿用台灣已建好的 Base + Interface，以 Filter 隔離各地區可視資料
法律、財務與股權確認事項
- 海外事業體為獨立法人（非台灣公司的辦公室）
- 各法人財務必須獨立（各自申報稅務、產出財務報表）
- TailorMed TW 為部份出資，非獨資——台灣與海外之間存在合夥關係
- 海外人員需要自行填單操作（不只是查看），必須成為 Airtable 付費 Member
- 業務流程與作業邏輯與台灣相同（故認為無需另建系統）
2. TailorMed 想法的問題核心
誤解：流程一樣 → 系統可以共用
正確認知：流程一樣 ≠ 資料可以混在一起
比喻：台灣公司和美國公司的會計作業流程完全一樣——都要開發票、收款、對帳——但不會把兩家公司的帳本合成一本。Airtable 這套系統同時扮演 CRM、OMS、 FIN 會計帳本三個角色，三個都混在一起的問題比單純帳本更複雜。
Filter 方案的致命缺點
認為用 Filter 隔離資料即可，但這個方案在「部份出資 + 海外人員需要操作」的前提下，結構上無法成立：
Filter 是 Interface 層的設計，不是 Base 層的權限控制。 只要對方是 Base Member，就可以繞過 Interface 直接在 Base 看到所有資料。 部份出資的合夥關係下，台灣的客戶資料、財務數字、報價內容對海外合夥人完全透明—— 這個風險不能靠「相信對方不會亂看」來管理，而是架構上就不應該讓這種可能性存在。
3. 風險矩陣
| 風險項目 | 發生可能性 | 影響範圍 | 整體風險等級 | 說明 |
|---|---|---|---|---|
| FIN 財務無法分拆 | 高 | 高 | 🔴 高風險 | 法人財務獨立為必要條件，混用 Base 必然發生。Debit Notes / SoA / 損益摘要全部混算，無法產出單一法人報表。此為優先考量，因涉及財務合規。 |
| 資料主權無法保障 | 高 | 高 | 🔴 高風險 | 部份出資情境下，海外合夥人成為 Base Member 後可繞過 Interface Filter 直接存取台灣所有資料。Filter 不是權限控制，是顯示設計。 |
| Automation 跨法人觸發 | 高 | 中 | 🟠 中高風險 | OMS→FIN 全局觸發，多地區共用時無法區分。誤觸發可發現並修正，但需人工回溯驗證歷史記錄。初期業務量少時影響有限，業務增長後難以控管。 |
| Job No. 無地區識別 | 高 | 中 | 🟠 中風險 | 現有 Formula 不含地區前綴，單號外觀完全相同。客戶文件混淆；補前綴後歷史單號無法追溯修改。越晚處理歷史資料斷層越嚴重。 |
| Record-level 權限隔離 | 高 | 中 | 🟠 中風險 | Airtable 預設權限以 View 為單位，非 Record 為單位。共用 Base 下海外人員可見台灣資料；Record-level 權限需 Business plan，且仍無法解決跨法人資料混存的根本問題。 |
| Staffs / 文件抬頭法人歸屬 | 中 | 低 | 🟡 低中風險 | 初期員工少，衝突尚不明顯。主要影響文件外觀（公司名稱、地址、稅號）。加 Branch 欄位即可解決，成本低。 |
4. 成本比較
| 現在分開建 | 共用後再拆 | |
|---|---|---|
| 工作量 | 建立獨立 Base 結構 | 遷移歷史資料 + 修改所有 Formula + 驗證財務數字 + 清查資料主權歸屬 |
| 風險等級 | 低 | 高（有真實財務與合夥人資料在裡面） |
| 系統影響 | 幾乎不影響現有台灣作業 | 可能需要凍結系統進行資料遷移 |
| 合夥關係風險 | 低，各法人資料天然隔離 | 高，資料混存期間合夥人對彼此資料有潛在存取能力 |
| 整體費用 | 開發費用（一次性，相對可控） | 開發費用 + 資料清理人工 + 財務驗證成本 + 潛在法律風險（難以預估） |
5. 建議架構路徑
結論：建議直接分開建，不走「先共用再拆」路線
考量到以下三個條件同時成立：
- 各地區為獨立法人，財務必須獨立
- TailorMed TW 為部份出資，存在合夥關係，資料主權需要明確隔離
- 海外人員需要自行填單操作，必須成為 Base Member
「先共用、用 Filter 隔離、之後再拆」的方案在架構上無法同時滿足以上三點。建議直接為各地區建立獨立 Base，共用資料以 Sync 橋接。
各地區 Base 架構
共用資源（如有此需求，擬由 TW 主 Base 管理，Sync 至各地區，唯讀）
├── Partners（所有地區客戶，可視需求改為各地區獨立管理）
├── Charge Catalog（費用目錄）
└── Locations（城市/國家對照）
TW Base（TailorMed TW，獨立法人）
├── CRM — Quotations(TW)
├── OMS — Orders(TW)
└── FIN — Debit Notes(TW)
Member：TW 員工
對外：不開放海外 Member 存取
US Base（TailorMed US，獨立法人）
├── CRM — Quotations(US)
├── OMS — Orders(US)
└── FIN — Debit Notes(US)
Member：US 員工（+ TW 指定人員若有需要）
JP Base（TailorMed JP，獨立法人）
└── 同上
費用影響
- 各地區 Base 各自計費，費用由對應法人承擔
- 海外員工人數直接影響該地區的 Airtable 月費，需在海外籌備階段一併評估
- 若 TW 有人需要跨地區查看，以受邀方式加入對應 Base，不影響資料主權
開發工作量說明
台灣現有的 Base 結構、Interface 設計、Automation 邏輯可以直接作為範本複製，海外 Base 不需要從零設計——主要工作是：
- 複製 Base 結構與 Interface
- 設定 Sync（如有需求，共用資料橋接）
- 調整文件抬頭（法人名稱、地址、稅號）
- 建立各地區的 Automation
6. 會議說明建議
開場定錨
「用 Filter 隔離資料這個方向沒有錯，短期內確實可以運作。我想花一點時間說明，在你們目前的股權結構和財務需求下，這個做法有幾個地方在架構上做不到你們要的東西。」
核心論點一：Filter 不是權限控制
「Filter 是介面層的設計——它控制的是『預設顯示什麼』，不是『誰有資格看什麼』。只要海外人員是這個 Base 的 Member，他就可以繞過 Interface，直接在 Base 裡看到台灣所有的客戶資料、報價、財務數字。」
「這在一般的分公司情境下也許還好。但你們是部份出資的合夥關係——台灣不是百分之百控股海外。這種情況下，資料隔離不能靠信任，要靠架構。」
核心論點二：流程一樣不代表資料可以混在一起
「就像兩家公司的會計流程完全相同，但帳本一定分開——因為它們是不同法人。Airtable 這套系統同時是 CRM、訂單系統、財務帳本，三個都混在一起的複雜度遠高於單純的帳本。」
切入點：用 Job No. 跳號問題引導「越晚處理代價越高」
背景：客戶目前 Job No. 由業務手動填入
#欄位，Formula 組出單號。因業務手動填寫造成跳號，目前無法補救（Autonumber 無法從指定數字起跳，加入後只會從 1 重算）。此為客戶親身經歷的痛點，適合作為切入點。注意：Job No. 補救方案技術上可行，但窗口期已過，現階段不在服務範圍內。此案例僅作為說明素材，不主動提出解法。
說明順序：先問，不要先講：
「目前 Job No. 的跳號問題，你們有沒有想過未來要怎麼補救？」
讓客戶自己說出「補不了」或「不知道怎麼辦」，再接：
「跳號補不回來的原因，是資料一旦存入就有了生命週期——你不能回頭改它的起點。這不是 Airtable 的問題，是所有資料庫系統的共同特性。」
「財務混用是同一個道理，只是規模放大十倍。Job No. 跳號影響的是作業方便性，你們選擇接受。財務資料混在一起之後要拆，影響的是財務合規和稅務申報的正確性——那個代價不是不方便，是法律風險。」
「而且財務資料要拆，不是關機重來，是邊開車邊換輪胎——系統還在跑、業務還在進來，同時要把每一筆 Debit Note、每一張 SoA 確認法人歸屬、搬移、重算、驗證。」
處理「權限開多大」的問題
當客戶問「那可不可以開一個很嚴格的權限，讓海外人員只能看自己的東西？」：
「可以做到一定程度，但有兩個限制。第一，Airtable 的 record-level 權限需要 Business plan，每人每月費用更高，而且設定維護成本不低。第二，更根本的問題是：只要資料在同一個 Base 裡，權限就是在同一個容器裡劃線——容器破了，線就沒了。分開建 Base 是讓每家公司有自己的容器，這才是真正的隔離。」
「而且隨著合夥關係的發展，你們之間需要共享的資訊和需要保密的資訊邊界會不斷移動。用獨立 Base + 指定 Sync 的方式，你可以精確控制『哪些資料對方看得到』；用共用 Base 加權限的方式，每次邊界移動都要重新調整權限設定，維護成本會隨時間累積。」
結論收尾
「台灣這套系統已經建好，不是浪費——它直接就是海外 Base 的範本。複製結構、調整抬頭、設定 Sync，開發工作量比從零開始小很多。現在做這件事的成本，遠低於等到有真實業務資料之後再來拆。」
7. 尚待確認事項
在進行海外 Base 開發之前，需與客戶確認以下問題：
| 問題 | 影響範圍 |
|---|---|
| 海外員工人數（各地區） | 各地區 Airtable 費用估算 |
| Airtable 費用由哪個法人承擔 | 影響 Workspace 歸屬設計 |
| 海外 Quotation/Debit Note 的公司抬頭（法人名稱、地址、稅號） | CRM/FIN 文件模板設計 |
| TW 是否有人需要跨地區查看海外 Base | 決定 TW 人員的跨 Base 存取方式 |
| Partners 資料是否共用或各地區獨立管理 | 決定共用資源 Sync 的範圍 |
建立日期：2026/04 | 版本：v1.2 此文件由萬能數維有限公司整理，供 TailorMed 系統架構決策參考使用