昨天我大体分析了Oracle的现状，现在我还想总结一下甲骨文在云产品上的商业模式。

甲骨文以Cloud Computing 为现阶段的发展目标，全球都在大力发展云的市场。虽然第三季度财报上看，全球的云收入达到了12亿美金，但是实际上中国区的云做的并不好。

当然中国区的市场和政策环境有很大的关系，也起了很大部分的决定性因素。

那么甲骨文的云是怎么做的呢？如何做到一个季度的云业务收入就达到了10亿美金这个数字？

甲骨文的云从第SaaS层往下推，再到PaaS和IaaS。SaaS的对标的就是SalesForce，成功方式和SalesForce很像，国外对于这种模式的接受程度很高，并且在使用体验等等方面都很好。SaaS的成功不需要有任何疑问。当然，回到国内来看，必然也是受限制于国内的市场环境，也有政策制约，使用习惯等问题。还有国内的公司想要用到SaaS，一定要访问海外节点才行，延迟高，核心数据还要出海，这些问题也制约了发展。

再到PaaS这一层，甲骨文提供了非常丰富的组件，包装了原有的一些软件，以服务的方式提供出来。比如Java开发环境，Oracle数据库服务免License，数据备份服务，移动云开发平台。

但是实际PaaS产品提供的Revenue根本不高。原因有两点，首先如果占比很高，财报上会体现出来，因为SaaS和PaaS根本不是同一个东西，合在一起说根本没有理由，或者是只是想给投资人看，反正投资人只知道SaaS和PaaS都是Cloud。第二个原因，甲骨文全球有19个数据中心，但是主要以SaaS为主，难道将PaaS和SaaS集合在一个数据中心？这理由也说不通吧，关联确实有一些，但不是一个东西。PaaS的机房很少，也没什么有量。

再往下到IaaS，因为这一层做的时间是最晚的，也没什么好说的，对收入几乎没有贡献，财报里面也没有体现。

再来分析下甲骨文在中国的云发展进程和战略。

甲骨文在两年前就开始推SaaS了，随着甲骨文全球云战略方向的明确，这两年SaaS在中国是越做越好。但是SaaS毕竟是业务上的东西，业务流程复杂度高，相对重型一些，我相信ERP EBS等SaaS服务肯定相对CRM等SaaS服务难推一些。在国内能用上SaaS的企业应该也是以外资企业为主，或者中小型在意成本的企业。

PaaS服务就更难推了，几乎在中国没有Real Case，这一点上也包括了在去年下半年开始推的IaaS。PaaS在中国的推广是很不成功的。现在所有卖database的named account销售或者commercial销售都可以卖PaaS和IaaS，并且都是在原有op上割一块下单，或者有的还会通过打盗版，让客户不得不买一些PaaS和IaaS。没有real case，无法帮客户解决实际的问题，也无法验证PaaS和IaaS是好还是坏。

从上致下，分配这些政治任务，理性地分析下，这些是很正常的，中国区的datacenter要落地，肯定需要得到老外高管的支持，那么就需要拿数字来证明中国区的云市场很大，销售也有能力做出成绩。最后很大程度上就不关心是不是Real Case了。

但是大家都明白，为什么要做real case ，只有实际存在业务场景，客户才会真的想为这个东西掏钱，这也是传递价值的过程。所以老冯和售前一直在主推几个Sales Play，一定程度上也是为了解决这个问题，传递价值。实际能不能真的起到作用，也因客户而异，这些Sales Play对一些传统客户来说，还是有用的。

并且公司为了拿出real case，也招了像我们这样的专业的做过云的团队，去主攻云的单子。

但是我们如何做real case呢？

早期的思路是以技术support为主，和传统Sales一起去做单子，teamwork。这样有个好处，利益不冲突，能把市场铺开，毕竟甲骨文的优势就在于大客户多，肯掏钱的客户也多，而且这些客户肯定是有业务场景的，比如和业务应用的结合等等。而且这样的teamwork也适合利益的分配，不会产生买了op，不买云的情况。

后来思路有变化，认为还是要独立成立Sales Team，单独抗业绩指标。也许因为甲骨文向来以产品线划分事业部，也就是中国区各个事业部管了不同的产品线和不同的客户群。有政治因素在里面，当然某些程度上也是因为甲骨文在发展中收购了非常多的公司，客户很早就有归属，比如中间价BEA的客户和dababase的客户是同一个，如何处理这种冲突，也只能按照产品线划分了。所以也导致了多个甲骨文销售跑同一个客户的情况。

把IaaS团队放在database事业部下面，这个很正常，因为产品都是基础产品，集合度很高。但是思路第一次改变的时候，就开始倾向于单打独斗，team背指标，其他销售完成的业绩和team没有关系，team单独name客户，自己做自己的单子，客户数量是30个commercial客户，并且找这些客户的pipeline。Named Account客户不能碰，这个时候主要怕引起内部冲突，并且Commercial的客户关系相对浅一点，我们在挖关系的时候好挖一些。

现在又做了次调整，做事的方式没有变化，但是客户有改变。为了做real case，并且不希望和其他commercial 的部门有业务客户的冲突，把风险降到最低并且可控。需要我们在原有MRD的named account 客户里面每个人找15个客户，或者自己有明确的业务关系的，也可以name到这15个客户里面。为的也是尽快出数字，并且出real case。

但是问题来了，客户关系好的，都在老销售里面，客户关系一般的，需要死磕。我们怎么做，对公司都有好处的，云业绩和real case都有了。但是对这个team的价值在哪呢？

甲骨文的销售讲究谁own客户，谁提forecast，谁拿credit和commission；如果我也name这个客户，但是关系不在我手上，我只能拿commission。所以在name这15个客户的时候，你真的能报多少个forecast，能在公司体现多少价值？最后就落到了无尽的抢客户发邮件走流程扯皮中。

自身的优势和价值在哪？team未来走什么路线？夹缝中求生还是大刀阔斧干一场？