第一次做客製系統：需求訪談要準備什麼？
— 四大準備清單＋連鎖零售狀況舉例說明
多數企業第一次做客製化系統時，都會以為「需求訪談」是工程師來問問題、公司負責回答即可。但真正有執行經驗的人會知道，專案能否成功順利，很大的關鍵在於企業在訪談前，是否已將業務流程和實際需求清楚整理出來。
越能提前整理需求的公司，專案越少走錯路；反之，若訪談前完全沒有準備，需求常會越講越發散、越做越歪，甚至導致預算爆掉或時程延誤。
因此，企業在需求訪談前至少要整理四大類資訊：
- 角色與權限
- 操作流程圖
- 欄位與報表清單
- 與既有系統的關聯
這四項不只是文件，而是讓工程師真正理解「你的業務如何運作」的基本材料。
以下我會拆解每一項應準備的內容，並用一間「連鎖零售品牌」的案例，示範實際上該怎麼做。
一、想避免專案延誤，為什麼需求訪談前的準備這麼重要？
專案會 delay，通常不是因為技術能力，而是因為：
- 使用者與工程師對「同一個流程」理解不同
- 訪談內容過度發散、缺乏結構
- 需求在專案中期才被提出
- 欄位不完整，導致資料庫反覆調整
- 忽略與舊系統的關聯，導致規格需要重寫
換句話說：沒有準備，就沒有真正的需求；沒有需求，專案就無法穩定推進。
而需求訪談前的準備，就是把企業內部「隱性的流程記憶」變成工程師看得懂的「顯性規格」。
二、需求訪談必備清單
（1）角色與權限：誰能做什麼，是系統設計的起點
角色與權限決定了整套系統的框架。如果沒有定義清楚，後續幾乎一定會改來改去。下方以連鎖零售狀況舉例，你需要先整理：
- 有哪些使用者角色？（店員、店長、督導、物流、後勤、營運、會計…）
- 每個角色能做什麼？（新增、編輯、刪除、查詢）
- 哪些是敏感操作？（成本、庫存調整、折扣變更）
- 哪些資料只允許特定角色查看？
📌【連鎖零售案例】
某鞋類連鎖品牌共有 12 家門市，訪談前先做了角色清單：
| 角色 | 能做的事 | 限制 |
|---|---|---|
| 店員 | 建立銷售單、查看商品庫存 | 不能查成本、不能編輯庫存 |
| 店長 | 可調整門市庫存、審核折扣 | 不能查他店資料 |
| 督導 | 查看所有門市業績、調貨分析 | 不可直接操作門市庫存 |
| 倉管 | 入庫、出庫、調撥管理 | 不看銷售數據 |
| 營運 | 所有報表、KPI、例外處理 | 不操作銷售 |
工程師一看就知道要如何設計權限結構，省去大量溝通時間。
（2）操作流程圖：把日常流程用「圖」畫出來，而不是用講的
流程圖是專案最關鍵的文件之一。你需要整理：
- 流程的起點與終點是什麼
- 每一步由誰處理？
- 每一步有哪些輸入資料？輸出什麼？
- 有哪些例外情況？（缺貨、錯單、取消、換貨）
- 現行流程有哪些是靠 Excel、Line、紙本補動作？
📌【連鎖零售案例】—以「調撥流程」為例
補充 調撥流程是零售或倉儲業用來管理商品在不同分店或倉庫間移動，並確保庫存準確同步的一套標準作業程序。
- 店員向督導提出調貨需求
- 督導審核 → 通知倉庫
- 倉庫配貨 → 出庫 → 建立物流編號
- 門市收貨 → 確認入庫 → 銷售狀態同步更新
並補充兩個例外狀況：
- 若熱賣商品優先分配給業績較差門市？
- 若倉庫缺貨需從其他門市調貨？
因此你可以針對上述需求先畫出下方流程：
有了初步的流程圖後，工程師就能依需求進行流程調整，加入更明確的細節。
有了更符合實際狀況的流程後，工程師就能依此設計：
✔ 調撥申請表單
✔ 審核流程
✔ 出庫與入庫作業
✔ 即時庫存同步邏輯
✔ 流程例外處理的規則
如果企業沒有提前畫流程圖，通常在專案中期才會想起「啊，我們還有其他調撥流程！」，導致規格重寫。
（3）欄位與報表清單：資料庫能寫什麼，報表就能呈現什麼
這是很多企業最容易忽略的部分。但對工程師而言，這是最重要的資訊之一。
你應先整理：
需要哪些欄位？
例如零售業：
- 商品：SKU (庫存單位)、成本、售價、顏色、尺寸、季節、系列
- 訂單：付款方式、通路、會員、折扣、贈品
- 店員：編號、門市、績效指標
- 庫存：安全庫存、可售量、調撥量
需要哪些報表？
- 每日銷售明細
- 庫存概況
- 調撥紀錄
- 門市 KPI
- 單品周轉率
- 庫存健康程度
- 促銷效果
- 曝倉風險
📌【連鎖零售案例】—報表需求是訪談前就整理好的
當品牌提供了目前使用 Excel 做的報表，能幫助工程師理解哪些數據是重要的，並協助品牌在系統做報表自動化處理，減少人工處理時間。
工程師依此設計：
- 多維度篩選（尺寸、款式、門市、季節）
- 自動合計
- 可匯出給會計部門
- 指標計算（轉換率、周轉率、安全庫存提醒）
因為資料欄位與報表需求在前期就定義清楚，整個系統資料庫一次到位，不必重建。
（4）與既有系統的關聯：避免重複輸入、資料不同步
你需要先盤點目前用的所有工具：
- ERP（財務、庫存）
- POS（門市銷售）
- CRM（會員）
- 電商平台
- Line 官方帳號
要整理：
- 哪些資料要同步？（庫存、訂單、會員、會計）
- 哪邊是主系統？哪邊是副系統？
- 同步頻率：即時？每小時？每天一次？
- 目前是否已有 API？
📌【連鎖零售案例】—與 ERP 串接避免三套資料不一致
連鎖零售品牌可能的常見困擾像是：
- POS 庫存與 ERP 庫存不一致
- 電商訂單需人工匯入 ERP
- 每月底花 3 天對帳
訪談前他們先整理清楚：
| 資料 | 主系統 | 同步方向 | 頻率 |
|---|---|---|---|
| 庫存 | ERP | ERP → 客製系統 → POS | 即時 |
| 訂單 | 客製系統 | 客製系統 → ERP | 即時 |
| 會員 | CRM | CRM ←→ 客製系統 | 即時 |
| 價格 | ERP | ERP → 客製系統 | 每日 |
工程師因此能設計一套乾淨的 API 流程，讓三邊資料一致，不再需要人工補洞。
三、企業第一次做客製化時最常犯的錯誤
- 以為需求訪談是「想到什麼說什麼」
→ 結果工程師越聽越迷茫。
- 只講理想狀態，不講真實流程
→ 寫出來的系統現場不能用。
- 忽略報表與欄位
→ 資料庫缺欄位，後期要重做很痛。
- 忘記其他系統存在
→ 專案到一半才說：「我們 ERP 要一起串。」
- 沒有指定內部窗口，需求越講越多人版本不一致
→ 導致專案停滯。
四、如何判斷準備程度是否足夠？
下方提供你簡單的快速檢查表，方便你快速釐清需求的準備狀況：
✔ 是否能清楚列出所有角色與權限？
✔ 是否能把流程從「開始到結束」畫成圖？
✔ 是否知道每天／每週會用到哪些報表？
✔ 是否知道哪些資料需要跟 ERP/POS/CRM 同步？
✔ 是否能說出目前最痛的流程瓶頸？
只要以上 3 項以上可以回答，訪談就能高效率開始。若 5 項都能回答，工程師幾乎可在此階段就確立明確的系統架構。
五、常見問題解答 (FAQ)
Q1：我們公司沒有技術人員，完全不懂程式也能準備需求訪談嗎？
答： 絕對可以。工程師在訪談階段需要的不是「技術語言」，而是您的「業務邏輯」。您只需要專注於描述：誰在什麼時候會用到系統、目前的作業流程怎麼跑、以及哪些環節最常出錯或最耗時。
Q2：為什麼一定要畫出「操作流程圖」，不能在面談時用口頭說明嗎？
答： 口頭說明容易產生認知誤差（每個人腦中的畫面不同）。流程圖能將隱性的流程顯性化，幫助團隊發現探藏的「例外狀況」（例如：退貨流程、缺貨處理），避免專案進行到一半才發現規格遺漏，導致重做。
Q3：如果我們公司已經有 ERP 或 POS 系統，面談前需要盤點什麼？
答： 您需要盤點「資料流向」。明確指出哪套系統是資料的來源（主系統），哪邊是接收方，以及同步的頻率（即時或批次）。若能提前確認舊系統是否具備 API 接口，將大大加快技術評估的速度。
Q4：「角色與權限」定義得太細，會不會導致系統開發變得很複雜？
答： 初期定義清楚反而能簡化開發。權限定義決定了資料庫的底層架構，若前期模糊，後期才要增加「某些資料店員不能看」的功能，往往需要改動大量原始碼。從營運安全角度出發，建議至少區分管理員、一般操作員與財務稽核。
Q5：如何快速判斷我們的需求準備程度已經可以開始面談了？
答： 您可以參考文章中的「快速檢查表」。只要能清晰畫出「從開始到結束」的流程圖、列出關鍵角色清單，並確認哪些資料需要跟舊系統同步，這三個核心指標達成後，就是非常高效的面談時機。
結語：需求訪談前的準備，決定專案成敗
第一次做客製化系統的企業常會擔心：「我們不是技術背景，怎麼準備？」
但實際上，工程師需要的不是技術語言，而是：
- 你的流程怎麼跑
- 誰負責什麼
- 你每天用什麼工具
- 哪些流程會卡住
- 哪些資料對你重要
只要企業願意把真實作業整理出來，工程師就能有效的協助你，幫你把需求做成系統。
因此請記住一句話：
需求訪談的重要性，在於確保專案方向的精準對焦。
準備越充分，專案才能越快從藍圖走向實踐。