商業分析師面試問題

框架: 目標 → 利害關係人 → 決策 → 資料 → 需求 → 驗證

我會先釐清商業目標。儀表板應該是用來支援決策，而不只是把資料攤出來。我會問：這個儀表板要協助哪些決策、誰會使用、多久看一次、看完會採取什麼行動，以及目前有哪些痛點。 接著找出利害關係人：高階主管、中階主管、第一線作業人員、財務、資料工程、法遵，以及所有負責來源系統的人。不同利害關係人可能需要不同的檢視畫面、指標定義和更新頻率。 再來是定義指標和資料需求。每個指標我都會記錄定義、負責人、來源資料表或系統、計算邏輯、篩選條件、資料粒度、更新頻率，以及已知的限制。我也會確認存取權限、匯出需求、向下鑽取（drill-down）、警示，以及歷史趨勢的需求。 需求草稿完成後，我會用模擬畫面或線框圖跟利害關係人確認，確保儀表板真的能回答原本要支援的決策，而且指標定義和唯一可信的資料來源一致。最後定義驗收標準和 UAT 情境，讓儀表板在上線前就能完成測試。

框架: 先談問題，再談解法

我會先了解這個解法背後要解決的問題。目前的簽核流程長什麼樣子？痛點在哪裡：速度、錯誤、法遵、透明度、工作量、客戶體驗，還是稽核軌跡？誰提出申請、誰負責簽核、核准之後又會發生什麼事？ 接著我會把整個流程畫出來：申請建立、必填欄位、資料驗證、分派規則、簽核層級、逐級呈報、退回、重新送出、通知、報表、稽核紀錄和例外狀況。我也會問案件量、SLA 期望、法遵要求、使用者角色，以及要怎麼和既有系統整合。 重要的需求包括簽核規則、權限模型、業務邏輯、邊界情況、報表，以及資安、效能、系統運作時間和可稽核性等非功能需求。 我不會直接把「自動化簽核系統」當成需求本身。真正的需求是商業成果和規則。自動化也許是對的解法，但前提是流程和決策邏輯都已經釐清。

框架: 釐清變動 → 評估影響 → 排定優先順序 → 溝通

我會先釐清改了什麼、為什麼改。是新的業務需要、先前漏掉的需求、法規變動、利害關係人的偏好、技術限制，還是測試時才發現的問題？原因很重要，因為有些變動非做不可，有些則是可以取捨的選項。 接著評估影響：範疇、時程、成本、相依關係、使用者體驗、資料模型、系統整合、測試、教育訓練和風險。我會和產品、工程、QA 以及業務端的利害關係人一起估算影響程度。 然後決定怎麼處理：現在納入、延後處理、替換掉另一項需求，或是在它無助於目標時直接婉拒。這個決定要連同理由一起記錄在變更紀錄裡。 最後是清楚溝通。最糟的情況是範疇在沒人察覺的狀況下不斷膨脹。優秀的 BA 會讓取捨攤在檯面上，讓利害關係人對於哪些會交付、哪些不會交付有一致的認知。

框架: 現況 → 瓶頸 → 根本原因 → 未來流程 → 指標

我會先把目前從客戶註冊到完全啟用的導入流程畫出來，找出每個步驟、負責人、系統、交接點、相依關係、簽核、文件要求和例外路徑。接著蒐集每個步驟的處理時間，而不是只看總天數。 我會依客戶類型、產品、地區、風險等級和通路把導入流程分群來看。10 天的平均值，可能掩蓋了簡單客戶 2 天就完成、複雜客戶卻要花 20 天的事實。 根本原因可能包括人工輸入資料、客戶文件缺漏、法遵審查積壓、權責不清、重複簽核、系統整合缺口，或客戶在等待操作說明。每個瓶頸我都會評估影響程度和可行性。 未來流程的選項可以包括：事先驗證文件、自動提醒、讓法遵審查與帳戶設定同步進行、自助填寫表單、依風險分流、更清楚的進度追蹤，以及拿掉不必要的簽核。成功指標則包括導入時間的中位數與 p90、完成率、重工率、客戶滿意度、法遵例外件數和客服工單數。 我會建議先挑一個客群試行改善後的流程，再全面推行，尤其是牽涉到法遵或系統變更的時候。

框架: 範圍 → 參與者 → 流程 → 例外 → 控管

我會先界定範圍：流程從哪裡開始、到哪裡結束、涵蓋哪些團隊和系統，以及這個流程要支撐什麼商業成果。 現況流程的部分，我會記錄參與者、步驟、系統、輸入、輸出、決策點、交接點、等待時間、痛點和例外狀況。泳道圖很好用，因為它能清楚呈現跨團隊的權責歸屬。我也會找實際執行這個流程的人來確認，而不是只問主管。 未來流程的部分，我會標出有變動的步驟、被拿掉的工作、自動化的步驟、新增的控管機制、系統變更、角色調整和例外處理方式。另外也會記錄假設、待確認問題、相依關係和成功指標。 最終的流程文件要讓業務使用者、技術團隊、QA、教育訓練和營運人員都看得懂。如果不同對象需要不同的詳細程度，就同時準備一份給高層的摘要和一份詳細的流程圖。

框架: Join → 篩選 → 依月份和類別 group by → 加總營收

假設我們有 orders、order_items 和 products 三張資料表。第一步最重要的是確認資料粒度。營收可能存在訂單層級，也可能存在品項層級。如果產品類別是在品項層級，就應該把品項營收依類別加總，而不是直接把類別 join 到訂單層級的營收上，否則總數會被重複計算。 這段查詢應該用 product_id 把 order_items 和 products join 起來，再 join orders 取得訂單日期和狀態，篩選出已完成的訂單，接著用 date_trunc 取月份，依月份和產品類別 group by，最後加總品項營收。如果有退款或折扣，要先釐清營收應該算總額還是淨額。 好的回答還會提到驗證：把查詢算出的每月總營收和財務報表或唯一可信來源的營收報表比對，檢查有沒有缺漏的產品類別，並確認已取消的訂單和測試訂單都有排除。

框架: 目標 → 服務品質 → 效率 → 客戶成果 → 防護指標

我會先釐清客服團隊的目標：縮短處理時間、提升客戶滿意度、控制成本、減少升級案件，還是支撐業務成長。KPI 應該在客戶體驗和營運效率之間取得平衡。 核心指標可以包括首次回應時間、平均解決時間、SLA 達成率、積壓案件量、重開率、升級率、首次聯繫解決率、CSAT、每位客戶的進線率、每張工單成本，以及各類別的工單量。 我會依問題類型、優先等級、通路、客戶等級、產品、地區，以及客服人員或團隊來分群。平均值可能掩蓋高優先等級工單或企業客戶的嚴重問題。 防護指標很重要。如果只要求客服人員縮短處理時間，品質可能會下滑；如果只追求 CSAT，成本可能會上升。一個平衡的儀表板應該同時呈現速度、品質、工作量和根本原因，讓團隊能從流程、產品和人力配置三方面改善。

框架: 驗證 → 拆解 → 分群 → 診斷 → 建議

我會先驗證這個數字。檢查資料是否為最新、來源系統有沒有變動、篩選條件、日期區間、退貨與退款、匯率換算，以及儀表板的定義有沒有改過。 接著把業績拆解成各個驅動因子：流量或潛在客戶名單、轉換率、平均客單價、價格、銷量、產品組合、地區、通路、新客與舊客，以及個別業務或門市的表現。把下滑的部分分群來看非常關鍵。整體下滑 15%，可能只來自某一個通路、某一條產品線、某一個地區，或某一群客戶。 再來診斷可能的原因：季節性、行銷預算變動、競爭對手動作、缺貨、價格調整、銷售 pipeline 品質、網站問題、經濟環境，或報表本身出錯。 建議要看是哪個驅動因子造成的。如果流量是在付費行銷預算縮減後下滑，就檢討各通路的投放預算；如果是行動裝置上的轉換率下滑，就檢查結帳流程或網站效能；如果是產品組合改變，就調整促銷或庫存。我也會說明自己對結論的把握程度，以及下一步還需要哪些資料。

框架: 使用者 → 目標 → 價值 → 可測試的條件

一則實用的使用者故事要說清楚：誰需要什麼、需要的是什麼，以及為什麼重要。常見格式是：身為 [使用者]，我想要 [功能]，以便 [效益]。其中價值的描述很重要，因為它能幫助團隊做取捨。 驗收標準要具體且可以測試，用來定義這則故事要達到哪些條件才算完成。好的驗收標準會涵蓋主要成功路徑、資料驗證、權限、錯誤狀態、邊界情況、資料規則，必要時也包含非功能需求。 舉例來說：身為客服主管，我想要依優先等級和 SLA 狀態篩選工單，以便找出緊急的工作。驗收標準可以包括有哪些篩選條件、預設狀態、多個篩選條件的組合、沒有資料時的畫面呈現、權限規則、匯出行為，以及效能要求。 優秀的 BA 也會在開發開始前，先和利害關係人、工程、QA 及設計一起確認使用者故事。

框架: 商業上的為什麼、系統上的做什麼、可交付的切片

商業需求文件（BRD）說明商業問題、目標、範疇、利害關係人、高層次需求、假設、限制和成功指標。它回答的是這項工作為什麼重要，以及需要達成什麼商業成果。 功能需求文件（FRD）則更詳細地描述系統必須做到什麼：工作流程、業務規則、欄位、權限、系統整合、報表和例外狀況，幫助技術團隊理解系統應有的行為。 使用者故事是敏捷團隊使用的較小交付單位。它描述一項使用者需求，以及能在一個 sprint 或一次增量內開發並測試完成的驗收標準。 實際要寫哪些文件，每家公司都不一樣。重點是文件要配合交付模式和風險程度。受到嚴格監管的銀行作業流程，需要的文件可能就比內部儀表板的小改動多很多。

框架: 範圍 → 使用者 → 情境 → 資料 → 缺陷 → 簽核

我會先定義 UAT 的範圍：要測哪些流程、使用者、系統、整合、報表和業務規則。UAT 應該驗證的是業務端是否準備就緒，而不是把每一項 QA 測試再做一遍。 接著確認 UAT 的參與者：理賠承辦人員、主管、法遵、營運和報表使用者。然後根據真實的業務案例設計情境：一般理賠、文件不齊、高額理賠、拒賠、升級處理的案件、重複申請，以及例外處理。 準備能反映真實狀況的測試資料，涵蓋邊界情況、權限、狀態轉換、通知、稽核軌跡、報表和下游系統整合。每個情境都要有預期結果和驗收標準。 UAT 進行期間，我會追蹤缺陷、嚴重程度、負責人、狀態和業務影響，並區分哪些是真正的缺陷，哪些其實是教育訓練不足或變更需求。最後簽核時要確認：關鍵情境全數通過、已知問題都已獲得接受，而且使用者已經準備好上線。

框架: 建立共識 → 限制 → 方案 → 文件

我會先確保商業問題和期望成果都很清楚，再和工程團隊一起了解技術限制、相依關係、整合點、對資料模型的影響、效能需求和資安考量。 如果某項需求在技術上很複雜，我會把它拆成比較小的部分：業務規則、使用者流程、資料需求、API 行為、權限邏輯、錯誤處理和報表需求。我會用圖表、實例和範例資料來減少模糊地帶。 我也會請工程團隊提出不同方案和各自的取捨。也許有更簡單的 MVP、可以分階段交付的做法，或是某個技術限制讓需求必須調整。我的工作不是自己一個人設計系統，而是確保解決方案仍然符合業務需求，並讓利害關係人看得到其中的取捨。 文件應該記錄已達成共識的決定、待確認問題、假設和驗收標準，讓團隊不必靠記憶做事。

框架: 衡量 → 分群 → 診斷 → 改善

我會先定義什麼叫「採用」。是登入、使用功能、完成整個流程、重複使用，還是達成商業成果？接著依使用者群組、部門、地區、角色、受訓梯次和上線後經過的時間來衡量採用率。 然後診斷原因。使用者可能不知道有這個功能、不了解它的價值、覺得不好用、沒有權限、仍然依賴舊流程，或是這個功能根本沒解決真正的問題。客服工單、使用者訪談、操作過程錄影、實地觀察流程，以及使用漏斗，都能幫上忙。 可以採取的行動包括教育訓練、更好的溝通、改善 UX、調整流程、由主管持續推動、從舊工具轉移、修正權限，或修改需求。如果採用率低是因為解決方案沒有切中需求，就要坦白承認，回頭重新做需求探索。 成效不該只看使用量，還要看是否達成預期的商業成果：節省的時間、減少的錯誤、SLA 的改善、對營收的影響，或客戶滿意度。

框架: 商業價值 → 急迫性 → 風險 → 工作量 → 相依關係

我會先釐清這段期間的商業目標。排定優先順序應該回扣到具體成果，例如營收、法遵、客戶體驗、降低成本、降低風險或營運效率。 接著從商業價值、急迫性、法規或營運風險、對使用者的影響、工作量、相依關係和把握程度來評估每一項需求。簡單的評分模型會有幫助，但我不會盲目套用。有些需求因為法遵或重大事件，是非做不可的。 我會把需求分成必做、高價值、速效型、有相依關係和延後處理幾類，再公開透明地和利害關係人取得共識：選了哪些、延後哪些、為什麼，以及出現什麼證據會讓這個決定改變。 優秀的 BA 也會找出重複的需求或背後的根本原因。20 項需求，可能其實只反映了 5 個根本問題。解決根本原因，往往比交付一堆彼此不相干的需求更有價值。

框架: 現行成本 → 錯誤風險 → 自動化成本 → 效益 → 建議

我會同時評估量化和質化的價值。現行成本是每月 40 小時乘以含所有附加費用的人力成本，再加上錯誤成本、延遲成本、稽核風險和機會成本。如果這個流程會影響財務報表或法遵，降低風險可能比單純節省人力更重要。 接著估算自動化的成本：工程或外部廠商的費用、維護、例外處理、控管機制、測試、教育訓練，以及與來源系統的整合。有些對帳流程單純又重複，有些則需要人為判斷，可能只能做到部分自動化。 我也會分析業務量的成長。今天要花 40 小時的流程，隨著業務擴張，可能會變成 100 小時。即使短期的投資回收普普通通，從未來的處理量能和準確度來看，自動化仍然可能值得。 我的建議是：如果流程穩定、有明確規則、量大、容易出錯，而且來源系統清楚，就自動化。如果流程經常變動或需要人為判斷，就先從標準化和部分自動化做起，再考慮完整開發。

框架: 定義生產力 → 基準 → 採用 → 成果 → 防護指標

我會先定義業務生產力。它可能是每位業務完成更多有效的業務活動、銷售週期縮短、轉換率提高、建立更多 pipeline、預測更準確，或每位業務實際成交更多營收。哪個指標才對，取決於這個工作流程的目標。 在上線前先建立基準，上線後再比較，最好搭配對照組或分階段推行。也要追蹤採用狀況：業務有沒有正確使用這個流程，還是使用率很低？如果沒有人採用，成果上的變化就無法歸因於這個工作流程。 指標可以包括花在行政工作上的時間、完成的追蹤聯繫數、潛在客戶的回應時間、商機階段的推進、轉換率、銷售週期長度、pipeline 的資料整潔度、預測準確度，以及每位業務的營收。防護指標則包括資料品質、業務的滿意度、客戶體驗，以及刷數字的行為。 我會依團隊、地區、年資、客群和主管來分群，因為採用程度和成效往往差異很大。最後的建議應該說明：要擴大推行、調整教育訓練、簡化工作流程，還是修改需求。

框架: 釐清目標 → 攤開取捨 → 用證據說話 → 做出決定

我會先了解每位利害關係人背後真正的目標。需求互相衝突，往往反映的是誘因不同，而不只是意見不同。例如業務希望保有彈性，法遵則希望加強控管。 接著把衝突講清楚：每項需求代表什麼、會影響到誰、有哪些風險，以及能不能透過系統設定、權限、分階段交付或流程調整，讓兩邊都滿足。 盡可能用證據說話：使用者人數、對營收的影響、法遵風險、錯誤率、對客戶的影響、成本或營運負擔。如果這個決定需要有權做取捨的人拍板，我會帶著選項和建議往上呈報，而不是把一場沒有結論的爭論丟給主管。 最後記錄決定、理由，以及任何延後處理的需求。BA 的角色是創造清晰度和共識，而不是私下選邊站。

框架: 商業影響、選項、取捨

我會把技術限制轉換成商業影響。與其說「API 不支援這個功能」，我會說明這代表什麼：成本更高、時程更長、穩定性較差、資安風險、需要人工的替代做法，或是上線時間延後。 接著提出選項。舉例來說：方案 A 在八週內交付完整需求；方案 B 在三週內交付核心流程，例外狀況改用人工處理；方案 C 沿用現有工具，但報表功能有限制。每個選項都要附上取捨。 視覺化和實例很有幫助。一張簡單的圖、一段範例流程或模擬資料，都能讓限制變得具體。除非必要，我會避免使用技術術語，也會確認對方真的理解了。 目的不是要讓利害關係人變得懂技術，而是幫助他們在充分了解狀況下做出決策。

框架: 問題 → 分析 → 解法 → 執行 → 影響

挑一個改善前後差異明顯的流程。先從問題講起：處理週期太長、錯誤率高、大量人工作業、缺乏透明度、客訴，或法遵風險。 接著說明你是怎麼分析的。你有沒有畫出現況流程、訪談使用者、量測瓶頸、檢視資料、找出根本原因，或比較不同系統？要讓面試官看到你的建議是有證據支持的。 然後說明解決方案，以及你在執行過程中扮演的角色：需求、利害關係人共識、流程再設計、系統變更、UAT、教育訓練和上線推行。最後用可衡量的成果收尾，例如節省的工時、減少的錯誤、SLA 的改善、成本降低，或客戶滿意度提升。 好的回答也會提到你學到了什麼，以及你會如何進一步改善這個流程。

框架: 模糊狀況 → 假設 → 驗證 → 決策

挑一個「如果等到資訊完整才行動，進度就會被耽誤」的故事。說明當時有哪些未知、這個決定為什麼重要，以及你手上有哪些資訊。 接著描述你如何負責任地往前推進：把假設記錄下來、優先補齊最有價值的缺漏資訊、諮詢利害關係人、建立不同情境、使用替代資料，或建議分階段進行。 關鍵在於展現判斷力。你不能聽起來很草率，但也不能聽起來像是卡住動不了。商業分析師常常需要一邊推動專案，一邊把不確定性攤開讓大家看到。 最後交代結果，以及在取得更多資訊之後有哪些改變。

框架: 背景 → 細節 → 風險 → 行動 → 結果

挑一個「因為注重細節，而避免了重工、法遵風險、資料錯誤、對客戶的影響或上線問題」的故事。先交代專案背景，以及這個細節為什麼重要。 接著說明你是怎麼發現的：檢視需求、測試邊界情況、核對資料、梳理流程中的例外狀況，或和使用者確認假設。這個故事要展現的是方法，而不是運氣。 然後描述你採取的行動。你是更新了驗收標準、暫停了一次上線、讓利害關係人取得共識、修正了報表，還是新增了控管機制？最後用結果收尾：避免了缺陷、省下了成本、預防了稽核問題，或改善了使用者體驗。 別把故事講成在展現完美主義，而是要聚焦在守護商業成果。