给一家只卖软件的公司估值,可以直接套PE或DCF,逻辑很清晰。但当这家公司同时经营电商平台、云计算服务、物流网络、数字娱乐,还持有一家金融科技独角兽的股权——该怎么办?
硬套一个整体PE,你会把不同成熟度、不同风险特征的业务全部混在一起,最终得出一个平均数,而平均数往往是最没有信息量的结论。
分部加总估值法(Sum-of-the-Parts,缩写 SOTP)就是为了解决这个问题而生的。它不是一种新发明,高盛、摩根士丹利的分析师每天都在用它拆解 Alphabet、Meta 和阿里巴巴。今天我们把这套方法论彻底讲清楚。
一、定义:什么是 SOTP 估值法
SOTP 的核心思想只有一句话:把一家多元化企业拆成若干独立业务单元,分别用最合适的方法给每个单元估值,再把各部分价值加总,得到企业整体价值。
这背后有一个朴素的财务逻辑:一家企业的内在价值,等于它所有资产产生未来现金流的折现值之和。当不同业务的增长率、利润率、资本密集度差异显著时,用统一倍数估值会产生严重偏差,而逐一拆解则能还原真实价值。
SOTP 并非万能,但在以下场景中它是首选工具:
- 集团公司旗下有多条差异化业务线(如阿里、腾讯)
- 公司持有未上市子公司或关联公司的重要股权(如软银持有阿里股份)
- 部分业务尚未盈利,无法用PE,但可以用收入倍数或DCF单独处理
- 投资者评估"分拆价值"——如果拆开卖,每块各值多少钱
纽约大学 Damodaran 教授在《估值》(Investment Valuation)中专门指出:当企业各板块的风险与增长特征存在系统性差异时,单一倍数估值会产生"均值幻觉",SOTP 是更诚实的分析方式。[1]
二、核心框架:5步拆解流程
无论分析哪家公司,SOTP 的操作流程都遵循以下五步:
-
识别并界定业务板块
依据公司财报的分部披露(Segment Reporting)拆分。原则是:每个板块应具有独立的商业模式、可识别的竞争对手,且财务数据可单独获取。避免人为拆分过细(导致重复计算)或过粗(丢失差异信息)。 -
为每个板块选择合适的估值方法
成熟盈利业务用 EV/EBITDA 或 P/E;高增长但未盈利业务用 EV/Revenue 或 DCF;资产驱动型业务(如房地产、金融)用 P/B 或 NAV;早期投资/期权价值用 VC 估值法或二叉树期权模型。 -
逐一计算各板块企业价值(EV)
将选定的估值倍数乘以对应的财务指标,得到每个板块的 EV。此步骤需要参考同类上市公司的可比倍数(Comps),或自建 DCF 模型。 -
加总得到集团整体 EV
将各板块 EV 相加。如适用,需考虑控股公司折价(Conglomerate Discount),通常为 15%–30%。集团总部运营成本(Corporate Overhead)也应作为负值单独列示。[2] -
减去净债务,得到权益价值
权益价值 = 集团 EV − 净债务(总有息负债 − 现金及等价物)。再除以总股数,得到每股内在价值,与当前股价对比,判断高估或低估。
一个简化公式:
股权价值 = Σ(各板块 EV)× (1 − 控股折价率) − 净债务 − 集团总部成本现值
三、真实案例1:阿里巴巴 SOTP 拆解
以 2025 财年数据为基础,对阿里巴巴进行示意性 SOTP 拆解。
阿里的主要可识别板块包括:中国电商(淘天集团)、国际电商(速卖通/Lazada)、阿里云、菜鸟物流、本地生活(饿了么/高德)、大文娱(优酷)以及对蚂蚁集团的股权投资。
| 业务板块 | 关键财务指标 | 估值方法 | 参考倍数 | 估算 EV(亿元人民币) |
|---|---|---|---|---|
| 淘天集团(中国电商) | Take Rate × GMV ≈ 3,200亿收入 | EV/EBITDA | 8–10× | 18,000–22,000 |
| 阿里云 | 收入约1,200亿元,EBITA转正 | EV/Revenue | 4–6× | 4,800–7,200 |
| 国际数字商业 | 收入约900亿元,仍亏损 | EV/Revenue | 1.5–2.5× | 1,350–2,250 |
| 菜鸟物流 | 收入约1,000亿元 | EV/Revenue | 1–2× | 1,000–2,000 |
| 本地生活(饿了么/高德) | 亏损收窄中 | EV/Revenue | 1–1.5× | 500–800 |
| 大文娱(优酷) | 收入约250亿元 | EV/Revenue | 0.5–1× | 125–250 |
| 蚂蚁集团(33%股权) | 蚂蚁整体估值约7,000亿–1万亿 | 股权估值折算 | — | 2,300–3,300 |
| 各板块合计(含15%控股折价前) | — | — | — | 28,075–37,800 |
| 减:控股折价(约15%) | — | — | — | −4,200–5,700 |
| 减:净债务(约为负,即净现金约+4,000亿) | — | — | — | +4,000 |
| 权益价值估算区间 | — | — | — | 约27,875–36,100亿元 |
对比阿里2025年约2万亿港元(约1.8万亿人民币)的实际市值,SOTP 拆解结果暗示市场给出了远低于内在价值的估价——这正是部分价值投资者持续关注阿里的核心逻辑。[3] 当然,上述数据为估算示意,真实分析需逐项建模验证。
关键洞察:阿里云单独比照 AWS(亚马逊云)的 EV/Revenue 倍数(市场峰值曾达8–10×)来估值,其价值可能相当于整个阿里市值的一半以上——这就是为什么华尔街曾一度热烈讨论阿里云分拆上市的"解锁价值"逻辑。
四、真实案例2:Alphabet SOTP 拆解
Alphabet 是 SOTP 分析的教科书案例,因为其业务形态横跨成熟现金牛(Google Search)与未来期权(Waymo、DeepMind 商业化)。
2025年,Alphabet 主要板块的财务规模大致为:Google Search 及其他广告收入约 1,800 亿美元、YouTube 广告约 400 亿美元、Google Cloud 约 450 亿美元、Google 订阅/硬件/其他约 350 亿美元,以及 Other Bets(Waymo、Verily 等)合计亏损约 50–60 亿美元/年。
如何分别估值?
- Google Search:互联网广告行业最成熟的现金牛,可类比 Meta 广告业务,用 EV/EBITDA(约12–15×)或 P/E(约20–25×)估值,EV 约在 1.2–1.5 万亿美元区间。
- YouTube:流媒体+短视频混合体,可类比 Netflix(EV/Revenue ≈ 5–7×),EV 约 2,000–2,800 亿美元。
- Google Cloud:云计算第三名,增速高于 AWS/Azure 但规模较小,EV/Revenue 4–6×,EV 约 1,800–2,700 亿美元。
- Other Bets(Waymo):Waymo 最新融资估值约 450 亿美元,加上其他资产,Other Bets 整体期权价值可能在 500–1,000 亿美元,但折扣极大,通常按 NAV 打五折估算。
各板块加总后减去约 –700 亿美元净现金(Alphabet 是净现金状态),最终权益价值大约在 1.8–2.2 万亿美元,与 Alphabet 2025年约 2.0 万亿美元的实际市值基本吻合——说明市场对 Alphabet 的定价基本反映了各业务的内在价值,并没有明显的折价或溢价。[4]
这个案例告诉我们:SOTP 不仅用于"发现低估",也用于验证市场定价是否合理。
五、常见误区
SOTP 看起来逻辑严密,但实践中有三个陷阱最容易踩到:
误区1:双重计算(Double Counting)
最典型的场景是:把母公司的合并报表收入用于估值,同时又把子公司单独估了一遍。例如,阿里合并报表中已包含菜鸟的收入,如果你再给菜鸟单独估值,就会计算两次。解决方案:用分部报告中的独立财务数据,或手动剔除内部交易。
误区2:忽略控股公司折价(Conglomerate Discount)
实证研究(包括 CFA Institute 引用的多项研究)显示,多元化集团相比各业务独立上市的加总价值,普遍存在 15%–30% 的折价。[2] 原因包括:集团管理成本、资本配置效率损失、信息不透明等。巴菲特的伯克希尔·哈撒韦是一个有趣的反例——因为其资本配置能力被市场高度认可,长期以净资产的 1.3–1.5 倍交易,折价极小。但这是例外,不是常态。
误区3:过度精确的幻觉(False Precision)
SOTP 可以算出小数点后两位的"每股内在价值",但这个精确数字是虚假的安全感。每个估值倍数都有区间,每个业务的未来现金流都存在不确定性,叠加之后误差会放大。正确做法:给出估值区间(悲观/基准/乐观三情景),而不是一个单点数字。华尔街分析师把这种三情景分析称为"Scenario Analysis",它是 SOTP 的标配。
六、SOTP vs. 整体法(DCF/PE):适用场景对照
SOTP 不是要替代 DCF 或 PE,而是在特定场景下更优的补充工具。
| 维度 | SOTP | 整体 DCF | 整体 P/E |
|---|---|---|---|
| 适用公司类型 | 多元化集团、控股公司 | 单一业务或高度协同集团 | 成熟、盈利稳定的单一业务 |
| 数据要求 | 分部财务披露 | 集团合并报表 + 长期预测 | EPS 历史与预测 |
| 优势 | 揭示各业务真实价值,识别隐藏资产 | 理论最严谨,考虑协同效应 | 简单快速,便于横向对比 |
| 劣势 | 数据依赖性高,折价假设主观 | 对长期预测极敏感,操纵空间大 | 忽略资本结构和业务差异 |
| 典型应用场景 | 阿里、腾讯、伯克希尔、软银 | 苹果、贵州茅台 | 银行股、消费蓝筹快速筛选 |
一个实用经验:SOTP 往往用来建立估值"地板"和"天花板",而 DCF 用于建立核心情景。两者结合,才能得出更可靠的判断区间。高盛和摩根大通的研究报告中,对大型平台公司通常会同时呈现 SOTP 和 DCF 两套分析。[5]
七、FAQ
Q: 如果公司没有充分的分部财务披露,SOTP 还能做吗?
A: 可以做,但精确度会下降。实践中常见两种处理方式:第一,用公司投资者关系材料、行业数据和竞品类比来估算各板块收入——这叫"自下而上重建";第二,直接参考卖方研究报告(如高盛、中金的深度报告),这些报告通常已经包含了分析师重建的分部财务数据。核心是记录你的假设,让读者能评估误差来源。
Q: 控股公司折价为什么是15%–30%,有没有更精确的方法?
A: 15%–30% 是基于学术研究和市场观察的经验区间,具体数值因公司而异。更精确的做法是分析驱动折价的具体因素:集团管理费用有多高(可以现值化后单独扣除)?各业务之间有无真正的协同效应(如有,可部分抵消折价)?市场对管理层资本配置能力的信心如何?对伯克希尔这样有传奇资本配置记录的公司,折价接近于零;对普通多元化集团,25% 是较保守的假设。
Q: Waymo 这种没有收入的业务,SOTP 里该怎么处理?
A: 对尚未商业化的业务,有三种常见处理方式:(1)用最近一轮融资估值作为参考,并打一定折扣(流动性折扣 20–40%);(2)用实物期权模型(Real Options),把商业化的可能性和时间价值建模;(3)如果你认为不确定性太大,直接赋值为零,把它当作"免费期权"看待。大多数卖方分析师选择方式(1)或(3)。方式(2)理论最严谨,但参数假设难以验证。
Q: SOTP 和 NAV(净资产价值法)有什么区别?
A: NAV 是 SOTP 的一个特例,主要用于资产密集型公司(房地产、PE 基金、资源公司)。NAV 的核心是评估资产的市场重置价值或清算价值。SOTP 更广义,它可以对每个业务单元使用不同的估值方法——有的板块用 DCF,有的用可比公司倍数,有的用 NAV——然后加总。投资控股公司(如软银、阿里健康的母公司)分析中,两种方法经常混用。
Q: 个人投资者做 SOTP 分析,最容易在哪一步出错?
A: 最常见的错误是选错可比倍数。很多人会用目标公司所在整个行业的平均 EV/EBITDA,而忽略了该板块在同行中处于哪个位置(成长阶段 vs. 成熟阶段?市占率领先 vs. 追赶?)。建议做法:为每个板块找2–3个真正可比的上市公司,取中位数而不是平均数,并做敏感性测试——把倍数上下各浮动20%,看结论是否根本性改变。如果结论对倍数变化极其敏感,说明你的分析依赖于一个强假设,需要特别标注。
小结:SOTP 的本质是一种"分而治之"的思维方式。它迫使你真正理解一家企业的每一块业务,而不是把它当作一个整体黑盒。这个过程本身就是价值所在——即使最终的估值数字有误差,你对企业的理解深度已经远超大多数投资者。正如 Damodaran 所说:估值不是关于得出正确答案,而是关于提出正确的问题。
参考来源
- [1] Damodaran, A. (2012). Investment Valuation: Tools and Techniques for Determining the Value of Any Asset (3rd ed.). Wiley Finance. Chapter 24: Valuing a Firm with Multiple Business Lines.
- [2] CFA Institute. (2023). Equity Asset Valuation (4th ed.). CFA Institute Investment Series. Section on Conglomerate Discounts and Sum-of-the-Parts Analysis.
- [3] 阿里巴巴集团2025财年年报(2025年5月)及投资者关系材料,数据经m8编辑部整理与估算。实际数据以公司官方披露为准。
- [4] Alphabet Inc. Form 10-K FY2024/Q4 2024 Earnings Release. Google LLC, 2025. 收入数据经m8编辑部整理,估值为示意性区间。
- [5] Goldman Sachs Equity Research. (2024). Asia Internet: SOTP Framework Update. Goldman Sachs Global Investment Research. [内部研究报告,引自公开摘要及媒体报道。]
站内延伸阅读
如果要把这篇文章放回 m8 的研究框架,可以继续沿着以下入口阅读: