掌握卓越技能,更胜一筹
8.2 如何收购一家公司
一家大公司常常会在项目初始阶段收购一家较小公司,这样就拥有了一个已经武 装好的团队。一个软件项目主管也常常会为了解决问题或者更快进入市场而寻找可能 的收购机会。但收购通常都不简单,懂得如何恰如其分地运用它很重要。
通常考虑收购一家公司会出于四个目的。
知识产权
你能使用这家公司构建的技术、内容和专利。
人才
你能使用这家公司雇佣的人才。
客户
你能凭借这家公司的客户来加快业务增长。
防御
你买这家公司是为了让别人没法买它。
关于这四个目的,在微软和迪士尼做过收购工作的迪士尼工程副总裁迈克·史密 斯说:“你可以期望能达到其中一个目的,如果运气好,两个也有可能,但如果想通过 收购达到两个以上的目的,那你十有八九会大失所望。”
8.2.1 知识产权收购
在正式开始考虑收购技术或内容之前,你需要简单计算下是自己构建的成本低还 是买别人的成本低。算法很简单:多少个工程师需要花多少个月才能开发、测试并交 付类似的软件?将所需工程月数乘以一个工程师满负荷工作一个月所需的成本,再减 去因整合被收购公司的知识产权而产生的成本——这个成本也可以用工程人月为单位 来衡量。最后算出的结果就是你可以接受的收购金额,这里假定进入市场的时间并不 重要。
但是,进入市场的时间通常都是很重要的,因此你需要粗略计算下收购并完成整 合所需的时间能比自己开发少多少,潜在销量的价值有多大。你也可以直接取6 个月 的销量,这差不多等于你能取得的收益。将这个数字加入到你的第一次评估中去,你 就能知道交易的全部价值了。
如 果 你 觉 得 可 以 低 于 刚 才 计 算 的 金 额 达 成 交 易, 那 么 继 续 推 动 收 购 就 是 明智之选。
接下来需要仔细检查即将收购的软件。你不能相信这家公司的的代码质量,就算 能相信他们的代码质量,但还是需要验证。你需要找一个未来不会涉足这个业务的高 级工程师去检查代码。创业公司会因为他们的秘密武器被揭开而焦虑不安,你的律师 也会担心万一收购不成会给团队带来污点。但这些担心对你没有任何帮助。你必须让 自己和团队信任的人去检查代码和架构。如果不这样做,你就等于在机械师都未检查 过的情况下买了一辆租赁车。
如果你检查完代码后觉得它的质量还是可以的,接下去就需要拟定一个计划来确 保团队和技术的整合。整合项目与大部分项目一样,所花的时间会超出你的预期,甚 至还会远远地超出你的预期,因为你需要与新的成员、外部的服务器、不同的软件授 权以及各种没有文档的细节打交道。
8.2.2 人才收购
人才收购是所有收购中最复杂的,这并不奇怪,人是复杂的生物,而人才收购全 部与人相关。你必须像平时那样通过面试来评估打算收购的人才。你面试的人越多,
得到的信息就越充分,收购的风险就越小。但与之相对的是,你面试的人越多,对双 边业务造成的干扰也就越大。所以你必须谨慎地进行面试。
这里有一点需要告诫你:不要在人们不知情的情况下进行面试。这样会产生适得 其反的效果,我知道曾经发生过至少一例这样的事情。负责交易的团队最终不得不重 新面试一轮,这为交易笼上了阴云。
面试还会帮助你了解雇员适合的岗位。我将这些人才分成三大类。
关键人才
他们是那些闪闪发光的人,缺了他们,你就得马上找人替代。但他们的专业功底 深厚,你都很难找到类似的人来填补他们遗留的空缺。
好的雇员
他们是一群你乐于招进来做当前业务的人。他们是一流的候选人,但这种人你自 己花个把月也能找得到。
多余人才
他们是一群达不到雇佣要求的员工,你需要二选一:和他们续约一段时间以使你 能平稳将他们开掉,或者立即终止与他们的雇佣关系。这看起来是个艰难的过渡,但 收购的现实就是这样。
流程、面试和交易估值的主观性使得人才的批量收购非常艰难,即使收购成功,
人才的整合也会非常不容易。迈克·史密斯分享了一个他在微软经历的悲惨往事。
我曾经推动收购了一家名为Conversagent 的公司(成为 Microsoft Windows Live 的代理商)。在人才评估时,我们清晰地意识到再雇佣20 ~ 30 名工程师才能满足业 务运作的需要。收购在附加该约束条件的情况下通过了,但随后对方财务却决定拖延 扩充人员编制以抵制再雇佣新人,整整拖延了9 个月。核心人才在第 12 个月离开了,
没有人员填补。收购最终失败了,它目前的价值还不足当初收购价格的十分之一。
这个故事告诉你获得所有合作方的支持是多么重要,你需要在交易结束之前就让 他们(包括HR、法务、财务)参与到你的人才收购中来。
8.2.3 客户群收购
如果你能从每个用户身上赚到2 美元,而且正要收购一家拥有 1 千万用户的公司,
你应该能借此获得2 千万美元的收入,对吗?错,你只能获得其中很小一部分。这一 部分的大小取决于你借助这家公司的业务做什么。
如果打算收购的业务是自我维持的,你可以让它保持现有规模运作下去,并尝试 对该业务的客户追加销售你的新产品。然而转化率可能会很低。如果这1 千万用户有 约20% 的转化率,那么这笔交易就值不到 4 百万美元。
如果打算关闭这个业务并将它的用户转移到你这儿来,你可能要付出相当大的成 本来关掉它,且在这个过程中还会流失客户。预计按照这种方式完成的交易最后的价 值只有其潜在价值的50% 左右,即大约 5 百万美元。
这些收益都太低了,所以更大的可能是,你将收购客户的交易看做加速销售的手 段,以应对市场高度竞争因而快速扩张成为当务之急的局面。如果身处这样的局面,
你也许希望赶紧跳出苦海以免被压垮。或者至少吃点泰诺,这样你的胃会感谢你的。
假如不打算跳出苦海,你就需要通过预估销售增长来对这笔交易估值,这种算法充满 了不确定性。
不管你对这笔交易如何估值,确保你正在使用的是正确的数据基线。这意味着你 需要查看日志。除了查看印象数和注册用户数,你还要查看“7 天活跃”用户数。你 还想要回头客,因此你需要测量回访客户数和参与度(网站停留时间或者App 使用时 间)。让你的团队检查日志数据,或者至少你要了解生成报表的系统,不管这个系统 是Webtrends 还是 Google 分析。
8.2.4 防御性收购
我从未主导过防御性收购。在我看来防御性收购不见得很好,这种决策带有一股 恐惧的味道。如果你有钱进行防御性交易,请不要故意作恶。
如果正在考虑进行一次防御性交易,你可能需要想一想什么行为会涉嫌垄断。你 最好习惯在说话前申明“我不是个律师”,这样至少你发表的意见有一层保护。我不 是个律师,所以无法告诉你什么是不能做的。
8.2.5 收购的陷阱和最佳实践
最后这里还有一些建议和警告,你在考虑收购一家公司时需铭记在心。
1. 计划将你团队的部分人员调入他们团队
将你的一些高级职员调入收购的团队十分重要,而且会发挥很大的作用,因为 这样会把你的商业文化、商业实践和商业政策带进这支新团队。除此之外,一个优 秀的精力旺盛的开发主管还能破开坚冰,并帮助这支团队更快地提高效率。效率提 高了,人的幸福感就会增加,结果这个新团队就会成为一个愉快的团队。你应该按 照大约10:1 的比例来为收购而来的工程师配备高级工程师。如果无法匀出任何人,
你就需要想办法从新团队调人到你现有团队做开发主管,然后把原先的主管调到新 团队去。
不要低估文化适应的重要性,也不要低估新人适应领导风格所需要的时间。如果 你不管不顾,就会催生出一个难以驾驭的工程师团体,他们一心打算熬完一年后将股 份变现走人。这些人工作在痛苦中,还会对其他业务产生恶劣影响。所以你要确保新
老团队紧密融合。将最优秀的工程师调到新的团队会对此产生巨大的助力。
2. 计划整合产品
你不仅需要知道如何将他们的服务器架设在于你的虚拟IP 之下,还需要知道如 何处理他们的品牌以及如何将双方的计费系统打通。很多收购原本可以更为成功,可 惜在业务整合上收购者们付出了太多的工程成本。清晰的计划还有助于团队的过渡。
3. 了解之前所有的交易和负债
在交易晚期才发现创始人欠了别人一百万美元可不是件令人愉快的事。这不是你 的问题,但出于某种原因,创始人总是希望你能帮他解决这类问题,所以这也变成了 你的问题。在确定收购金额之前,通过会谈了解清楚该公司的欠款、负债以及任何签 署过的交易是非常重要的。一个好的律师会帮助你做这些事,但你最好也做一下这方 面的功课。