技术尽职调查：投资者和收购方所错过的

目前，75% 的投资者将数字化成熟度列为企业价值的三大驱动因素。该数字来自贝恩公司的 2025 年全球私募股权报告。 这意味着技术不再是收购过程中后台关注的问题； 它是一个主要的估值杠杆。

然而，大多数技术尽职调查审查发生得太晚，涵盖范围太少，并且错过了交割后爆发的风险。 标准剧本会指派一名初级分析师浏览架构图、检查开源许可违规情况，并生成一份 40 页的 PDF，除非出现问题，否则没人会阅读。

本文介绍了完整的技术 DD 流程是什么样子的、大多数评论的不足之处以及您在签署之前应评估的具体领域。

为什么技术 DD 现在比五年前更重要

五年前，一家私募股权公司收购了 5000 万美元的收入业务，可以将技术堆栈视为一个项目。 如果产品有效，那么代码就“足够好”。 价值在于收入、客户合同和品牌资产。

这种计算方式已经发生了变化。 当买家发现需要 12-18 个月修复的技术债务时，SaaS 倍数就会压缩。 当 API 没有文档记录或与单个供应商紧密耦合时，集成时间会加倍。 当基础设施是通过猜测而不是负载测试来配置时，云成本会急剧上升。 这些意外削弱了证明收购价格合理性的价值论点。

麦肯锡 2024 年的一项研究发现收购后40%的技术改造超出原预算50%以上。 大多数情况下的根本原因是：交割前存在但尽职调查中未发现的风险。

标准 DD 审查遗漏的五个隐藏风险

1. 负载下的脆弱架构

该产品在当前的流量水平下运行良好。 但收购理论假设 24 个月内增长 3 倍。 架构能处理它吗？ 大多数 DD 评论从未回答这个问题，因为他们从未测试过它。 他们审查图表。 他们不运行负载模拟。

常见的故障模式：应用程序使用没有只读副本、没有缓存层以及扫描全表的查询的整体数据库。 每日活跃用户数为 10,000 时，响应时间低于 200 毫秒。 在 30,000 DAU 下，这些相同的查询需要 2-4 秒。 在 50,000 时，数据库因写入争用而锁定，并且产品出现故障。 这是 50 万至 200 万美元的补救成本，卖方团队不会自愿承担。

2. 不可预测的云成本

目标公司报告的云支出为每月 8,000 美元。 DD 团队注意到了这一点并继续前进。 他们不检查的内容：基础设施没有自动扩展策略，没有预留实例，也没有成本警报。 三个开发环境按生产层规格 24/7 全天候运行。 一个被遗忘的 Kubernetes 集群每月费用为 1,200 美元，而且没有任何服务。

收购后，当新所有者推动增长时，云成本跃升至每月 25,000 美元，因为没有人优化基础。 实际数字始终是 25,000 美元； 8 000 美元的数字反映了利用不足，而不是效率。

3. 未记录的依赖关系和部落知识

CTO 四年前构建了原始系统。 随后有两名工程师加入。 他们三人的头脑中掌握着所有的建筑背景。 不存在架构决策记录。 没有操作手册。 没有事件响应手册。 部署过程涉及通过 SSH 连接到服务器并运行一个人编写且一个人理解的 bash 脚本。

当 CTO 在收购后离开时（CTO 经常在交易结束后 12 个月内离开），剩下的团队就无法在没有进行数月逆向工程的情况下发布功能、调试生产问题或雇用新工程师。 这不是技术问题。 这是业务连续性风险，应该在DD期间进行量化。

4、容灾能力薄弱

问目标公司两个问题：“您上次从备份恢复是什么时候？” 以及“您的恢复时间目标是多少？” 如果答案是“从不”和“我们还没有定义”，那么灾难恢复的姿态就是一种负担。

许多公司在初始部署期间设置了自动备份，但从不验证它们。 数据库每晚都会备份到 S3，但没有人测试过这些备份是否恢复到工作状态。 备份可能已损坏。 恢复脚本可能引用不再存在的基础设施。 直到需要时您才会知道，到那时您就已经失去了数据和收入。

5. 整合阻碍因素

收购价值通常取决于目标公司产品与买方现有平台的整合。 企业套件获得的 CRM 工具需要插入 SSO、共享计费和统一分析。 如果目标的身份验证系统是硬编码到一个身份提供商的定制解决方案，则集成需要 6 个月而不是 6 周。

DD 审查应该映射每个集成表面：API、Webhook、身份验证流程、数据格式和事件系统。 每个人都需要诚实地评估连接到买方堆栈需要多少工作。 “我们有一个 API”与“我们有一个有文档记录的、版本化的、速率受限的 API，具有标准身份验证和错误处理功能”不同。

技术 DD 清单

该表涵盖了彻底的技术 DD 审查应评估的领域。 每个领域都包含需要回答的具体问题以及未经检查的风险级别。

该清单涵盖了技术领域。 完整的DD参与还包括与工程团队的访谈、对冲刺速度和交付节奏的审查以及对产品路线图的商业评估。

何时运行技术DD（提示：比你想象的更早）

大多数公司在签署意向书后安排技术DD。 到那时，这笔交易就有了动力。 合作伙伴都投入了情感。 目标公司知道他们处于有利的谈判地位。 在这个阶段发现 200 万美元的补救成本会产生一个令人不安的选择：重新谈判价格（这可能会终止交易）或吸收成本（这会侵蚀回报）。

在意向书签署前或与商业尽职调查同时进行技术DD。轻量级技术评估需要 5-10 个工作日，成本只占交易价值的一小部分。 它为您提供从一开始就正确定价交易所需的信息。

早期的技术 DD 做了三件事。 首先，它会在您投入资本和法律费用之前识别交易破坏者。 其次，它为您提供了具体的数据点来协商与修复成本相关的价格调整。 第三，减少交易摩擦； 当双方尽早看到技术现实时，就不会有迟来的意外事件阻碍成交。

优秀的技术 DD 输出是什么样的

有用的 DD 报告不是充满架构图和术语的 60 页文档。 它是一个决策工具。 阅读本书的人是需要了解财务风险的合作伙伴、董事会成员和交易团队。

强大的技术 DD 可交付成果包括：

• 执行摘要（1 页）：进行/不进行建议，包含前 3 个风险及其估计的补救成本。
• 风险登记册：每个风险均按严重程度（严重、高、中、低）进行分类，并提供修复费用估算和修复时间表。
• 可扩展性评估：当前的架构能否支持增长计划？ 如果不是，需要进行哪些更改以及费用是多少？
• 整合路线图：将目标产品连接到买方平台的现实时间表，并指出依赖性和阻碍因素。
• 团队评估：关键人员风险、技能差距和招聘计划（如果收购后路线图需要当前团队缺乏的能力）。
• 100天计划：交易结束后前 100 天内最优先的技术行动，按影响和紧急程度排序。

每项发现都应该与资金和时间表联系起来。 “测试覆盖率为 23%”是一个观察结果。 “测试覆盖率为 23%，这意味着每个新功能发布都会带来 30-40% 的回归风险；将其修复到 70% 的覆盖率将需要 6-8 周的时间，成本为 40,000-60,000 美元”是可行的情报。

收购方在技术 DD 过程中常犯的错误

依赖于目标的自我报告指标。卖家表示，他们每周部署两次，测试覆盖率达到 80%。 验证一下。 拉取部署日志。 运行测试套件。 自我报告的工程指标通常是理想的，而不是实际的。

将“它有效”与“它构建得很好”混淆了。一款产品可以产生 1000 万美元的收入，并且仍然在未来三年维护成本为 300 万美元的代码库上运行。 工作软件和可维护软件是不同的东西。 DD 需要评估两者。

跳过团队面试。代码告诉您系统今天做了什么。 团队会告诉你系统是否可以进化。 与个别工程师交谈，而不是与演示幻灯片的首席技术官交谈。 问他们：“如果有 3 个月的时间，你会重建什么？” 他们的回答揭示了他们每天背负的科技债务。

将技术 DD 视为一个复选框。一些公司聘请了尽职调查提供商，接收报告，将其归档，然后继续进行交易。 DD 的目的是告知交易条款。 如果报告确定修复成本为 150 万美元，则该数字应出现在价格谈判中。 如果没有，您就支付了 DD 费用，然后忽略了它。

底线

技术尽职调查不是合规活动。 它是一个估值工具。 那些认真对待它、配备经验丰富的工程师（而不是通才顾问）、在交易过程的早期运行它、并将每项发现都与美元数字挂钩的公司，才能避免交易结束后出现破坏回报的意外情况。

彻底的技术DD参与的成本是交易价值的0.1-0.3%。 错过关键风险的成本是交易价值的 10-30%。 数学很简单。

常见问题