假設一家 B2B SaaS 公司正在做下一季 Forecast。

去年同期營收是 1 億。業務團隊認為市場還不錯,管理層先用一個常見的 shortcut:去年 + 10%。於是 1.1 億被拆到三個月,再分到各產品線。表格看起來很完整。

一個月後,事情開始對不上。Qualified pipeline 比預期少,win rate 沒有明顯惡化,幾個大客戶延後簽約,churn 高於原先假設,原本預計到職的 sales headcount 又晚了兩個月。

此時 Finance 當然知道 Forecast 錯了。麻煩的是,top-line 數字本身沒有告訴你該往哪裡查。需求變弱?conversion 變差?留存出了問題?價格變動?還是 capacity 根本沒如期到位?

Forecast 真正要支援的是這種判斷。管理層需要知道數字怎麼形成、多久需要更新,以及 miss 發生後哪些假設值得重看。

先找出數字背後的機制

把去年營收乘上 1.10 沒有數學錯誤。它的資訊量很低,因為多個 business mechanics 被壓成同一個 growth rate。

假設最後營收比 Forecast 少 8%,背後可能是完全不同的組合:

  • pipeline 少了 15%,win rate 反而優於預期;
  • pipeline 正常,Average Contract Value 下滑;
  • 新客戶正常,但 churn 拉低續約收入;
  • demand 沒有明顯變化,sales headcount 延後到職,sales capacity 因此不足;
  • 簽約數量沒有少,只是 revenue timing 往後移了一期。

只有 top-line growth assumption 時,團隊很容易在下一版直接換掉 top-line,然後繼續等下一次 miss。

IMA 的 FP&A 資料把 planning model 和 operating drivers 接在一起,目的就是讓財務結果能回到實際業務活動。IMA 在 managerial costing 的材料裡也把資源消耗與因果關係放在成本模型核心,而非任意 allocation basis。放到 Forecast,這兩個來源共同支持一個很實用的篩選方式:候選 Driver 應該能解釋結果是透過什麼營運機制被推動。

所以看到一個和 Revenue 高度相關的 KPI 時,先別急著把它塞進 Driver Tree。問它一個問題:如果這個值改變,能不能說清楚它如何改變 outcome?相關性可以提供線索,機制才決定它是否適合作為 Driver。

Driver Tree 要能回到可觀察的營運關係

Forecast 裡最常混在一起的,其實是 Driver、Assumption、Observed KPI 和 Output。把角色先分開,後面才知道 Actuals 到底在驗證什麼。

角色它在模型裡回答什麼B2B SaaS 例子
Driver哪個營運機制會推動結果?qualified pipeline、win rate、churn、ramped sales capacity
Assumption模型目前對 Driver 採用什麼估計?下季 win rate 22%、churn 1.5% / 月
Observed KPI現在實際量到什麼?pipeline coverage、實際 conversion、實際 churn
Output模型最後算出什麼?new ARR、renewal revenue、Opex、cash burn

新客收入可以從一條很簡單的關係開始:

Qualified Pipeline × Win Rate × Average Contract Value → New Revenue

續約收入則可以拆成:

Renewal Base × (1 − Churn) → Retained Revenue

Capacity 與 Cost 也各自有關係:

Sales Headcount × Ramped Productivity → Sales Capacity

Engineering Headcount × Loaded Cost → Engineering Opex

Cloud Usage × Unit Infrastructure Cost → Infrastructure Cost

這些都只是示意,不是 SaaS 公司應該照抄的標準公式。價值在於每個 output 都能往上追,直到找到可觀察、可被 challenge 的關係。

GFOA 的 planning guidance 原本服務公共財務,但其中對 leading / lagging drivers 與 decision horizon 的提醒可以有限轉用到企業規劃:哪些訊號先變,哪些結果後發生,兩者中間隔多久。這能避免 Driver Tree 只是一張漂亮的因果箭頭圖。

接下來看 Assumption。Win rate 如果藏在某個 cell、hiring date 默默沿用去年、churn 寫在沒有人負責的 tab,模型即使有 Driver Tree,也很難治理。ICAEW 的 spreadsheet guidance 要求 input、logic 與 assumptions 清楚可見;Fed/OCC 的 model-risk guidance 則提供另一個可轉用的原則:material assumption 應該能被客觀挑戰。後者是金融監管語境,不能整套搬到一般 FP&A。

一般公司做到下面四件事,通常就已經比「把假設藏在 Excel 裡」前進很多:

  • 目前假設值;
  • 支撐它的資料或 judgement;
  • 上次更新時間;
  • 當現況改變時,誰負責提出修正。

這些欄位讓 miss 有地方可查。Win rate 錯了,就查 win-rate assumption;capacity 錯了,就查 headcount、ramp 或 productivity,而不是直接重寫 Revenue。

Driver Tree:Qualified Pipeline、Win Rate 與 Average Contract Value 導向 New Revenue;Renewal Base 與 Churn 導向 Retained Revenue。

Rolling Forecast 要先決定公司需要看多遠

Driver model 會過期,問題在於過期的速度並不一致。

AICPA & CIMA 對 rolling plans / forecasts 的描述,是讓 planning window 持續往前移。假設管理層一直需要看未來六季,一開始是 Q1–Q6;Q1 結束後,Q1 變成 actual,尾端補上 Q7,於是視窗變成 Q2–Q7;下一季再往前成為 Q3–Q8。

這是 rolling horizon。Refresh cadence 則回答另一件事:哪些 Driver 要在什麼時候重新估。

AFP 的 rolling forecast guidance 把 horizon、time increment 和 update design 視為 company-specific choice。它的 implementation guidance 也提醒,如果把 annual Budget 的完整工作量改成一年重做 4 次或 12 次,團隊只是把行政成本倍增。

Cadence 可以從五個條件判斷:

  1. Decision lead time:決策需要提前多久?下一季要決定 hiring,兩季後才更新 headcount driver 已經失去作用。
  2. Volatility:Driver 變動多快?Pipeline 和一年才重談一次的辦公室租金,不需要相同 cadence。
  3. Data availability:可靠資料何時成熟?一個月才成熟一次的 signal,每天 refresh 只會製造假精準。
  4. Materiality:變化多大才值得重開 Forecast?小波動不必每次都牽動整份模型。
  5. Cost of refresh:一次更新會占用多少 Finance、Sales、Ops 與 management 時間?

因此,同一家公司可以每週監控某些 Driver、每月 reforecast,另一些成本每季更新,而 rolling horizon 始終維持六季。Horizon 是決策視窗,cadence 是維護視窗,兩者可以不同。

年度 Budget 也可以留著。Ekholm 與 Wallin 對 annual budgeting 的研究顯示,flexible / rolling instruments 可以和 annual budget 並存。這裡只需要保留這個邊界,AOP、Budget、Forecast 的角色分工留在上一篇處理。

保留舊版本,Actuals 才能成為測試

很多 Forecast process 有一個看似無害的習慣:新版本一出,上一版就被蓋掉。

例如一月預測三月營收 3,000 萬。二月拿到新資訊後改成 2,700 萬,三月 Actual 是 2,680 萬。如果只拿二月底版本比較,miss 是 20 萬,看起來非常漂亮。

但管理層若想知道「我們在一月時,對兩個月後到底看得多準」,就必須把一月版本留下來。

這就是 forecast origin。每一版至少要知道三件事:Forecast 是什麼時點做的、當時可用的資訊有哪些、預測距離 Actual 有多遠。Hyndman 與 Athanasopoulos 在《Forecasting: Principles and Practice》區分真正的 forecast error 與模型在已知資料上的 residual,商業上的含義很直接:評估一月 Forecast 時,不能偷偷帶入二月、三月才知道的資料。

對這家 SaaS 公司,一月版本至少要留下當時的 qualified pipeline、win rate assumption、churn assumption、sales hiring / ramp,以及由這些 inputs 算出的 revenue / cost output。Actuals 進來後,再逐項對照。

如此一來,Actuals 同時在測三件事:Driver Tree 有沒有抓到對的 mechanics、Assumption 是否合理、Refresh cadence 是否太慢。

Horizon 也要跟著保存。公司可能對 1 個月 ahead 很穩,3 個月 ahead 開始偏,6 個月 ahead 幾乎失去決策價值。把它們壓成「Forecast accuracy = 87%」,會把這個形狀整個藏掉。

Accuracy 要拆成四個診斷面向

有了 genuine prior forecast 和 Actuals,才輪到 Accuracy。這裡先不要急著選一個公司級 KPI,因為不同指標回答不同問題。

面向管理問題可用的觀察方式
MagnitudeMiss 到底多大?MAE 保留原始單位;RMSE 對大 miss 給更高權重
Direction / Bias是否長期往同一方向錯?signed error / mean error 與 Driver 層級的持續偏差
Horizon離現在越遠,誤差怎麼變?1、3、6 個月 ahead 分開看
SegmentAggregate 底下哪一塊在錯?產品、地區、客群、Driver 分拆

Magnitude 很適合先回答「差多少」。例如月營收用 MAE,可以直接看到平均差多少金額;headcount Forecast 則直接看到平均差多少人。RMSE 會放大少數大 miss 的影響,如果巨大 miss 對決策特別危險,這個性質就有用。兩個指標沒有固定勝負。

Bias 的用途不同。假設 Revenue error 有正有負,aggregate MAE 看起來普通,但 win rate 連續幾個月都估太高,管理問題已經很明確。Sales 可能長期高估 late-stage pipeline,也可能是 Finance 長期為了保守低估收入。平均誤差相近,不代表組織行為相同。

Horizon 則要把 1 個月 ahead、3 個月 ahead、6 個月 ahead 分開。Hyndman 與 Athanasopoulos 在 time-series cross-validation 使用 rolling forecast origins,就是為了觀察不同 horizon 的表現。企業不需要照著寫統計程式,卻可以直接採用這個管理習慣。近兩個月可靠、半年後快速惡化的 Forecast,可以支援短期 hiring 或 working-capital 決策,但半年後的數字就不適合被當成精準承諾。

Segment 會抓出 aggregate 的互相抵消。總 Revenue 只差 3%,可能同時包含 Enterprise 高估 15%、SMB 低估 12%。總 ARR 也可能剛好接近 plan,背後卻是 new logo 高估、expansion 低估、churn 也低估。總數看起來很準,不代表 Driver 層級沒有問題。

FPP 對 forecast accuracy measures 的討論指出,不同 metrics 衡量不同性質,也可能對兩套 Forecast 給出不同排名。MAPE(Mean Absolute Percentage Error)要特別留意:它把 error 除以 Actual,Actual = 0 時沒有定義,Actual 很接近 0 時也可能被小分母放大。Hyndman 與 Koehler 對 forecast accuracy measures 的研究正是常被引用的警告之一。

如果要跨不同尺度比較,MASE 這類 scaled measure 可能比機械式套用 MAPE 更合適。選 metric 前,先確定要回答的是 magnitude、bias、horizon 還是 cross-scale comparison。

進階:Range Forecast 的 Calibration 是另一個更嚴格的統計問題。 例如反覆提供 80% prediction interval,可以觀察 realised outcomes 是否大致以相應頻率落在區間內。這和管理上根據 point-forecast miss 去調整 assumption 的「recalibration」不是同一個概念。Quantile、interval 與 distributional forecast 可以另外深入,不需要塞進每份企業 point Forecast。

Miss 出現後,沿 Driver Tree 往回查

回到開頭那家公司。Actuals 到齊後,團隊發現 qualified pipeline 確實低於預期,但不足以解釋全部 revenue miss;realised win rate 已連續三個月低於模型 assumption;churn 稍高;另外兩位 sales hires 延後到職,讓預計的 ramped capacity 晚了一季。

如果下一季 Revenue 直接下調 8%,表面上完成了 reforecast,真正的問題仍留在模型裡。

沿 Driver Tree 往回查,可以把討論拆成幾個具體問題:

  • 22% 的 win-rate assumption 還有足夠證據嗎?
  • pipeline stage 的定義是否改過,讓歷史 conversion relationship 失效?
  • hiring delay 是一次性事件,還是 recruiting lead time 長期估得太短?
  • churn 上升集中在某個 segment,還是 broad-based?
  • cadence 是否太慢,Driver 已經 material change 一個月後 management 才看到?

答案可能落在不同層。Assumption 要改,Driver relationship 要重建,input data 品質要處理,或 cadence 要調整;也可能只是遇到真的難以預測的 external shock。Forecast 沒有能力消除 uncertainty。

這一輪診斷完成後,下一版 Forecast 才從更新過的 mechanics 重新生成。整個流程可以寫成:

Drivers → Forecast → Actuals → Error / Bias → Recalibration → Next Forecast

這條 loop 不承諾下一次一定更準。它提供的是可追查性:這次 miss 發生在哪一層,團隊改了什麼,以及下一個決策現在建立在哪些 assumptions 上。

Forecasting as a Learning Loop:Drivers、Forecast、Actuals、Error / Bias、Recalibration、Next Forecast 形成閉環。

最後用三個檢查決定這份 Forecast 能不能拿來管理

拿到一份 Forecast 時,可以先做三個很快的檢查。

Explain:從 Revenue、Cost、Cash 等 output,能不能一路追到重要 Driver 與 Assumption?如果追到最後只剩「去年 + 10%」,管理者只能看到答案,看不到可診斷的 mechanics。

Stay Current:Horizon 與 cadence 是否匹配決策速度?三個月內要做的 hiring decision,不能等六個月後才更新;一年才改一次的 assumption,也沒必要每週重建。

Learn:Miss 發生後,有沒有保留 forecast origin,並從 magnitude、bias、horizon、segment 往回定位?最後應該知道要動的是 Driver、Assumption、data 還是 cadence。

References