千万不要搞生态啊，除非...

千万不要搞生态啊，除非不得不。

但凡能活着，千万不要搞生态啊。

（1）过去：快速起步发展

中国企业服务产业过去没什么风险投资进入，主要靠IT商自己滚动发展：

• 赶快做个能销售的东西

• 销售出去赶快回款

• 借助大客户来打磨功能，经过几个大客户项目打磨，说这就是产品，可以大规模开卖了

所以在没有资金的情况下，想快速做大，只有：全国招募分销网络、压货。

这时候的分销网络，本质上是：充当了资金池。

(2）过去：覆盖广大三四级城市

除非要要深入到中国广阔的、数量众多的三四级城市，需要当地的销售和服务网络。

尤其在中国三四级小城市，竞争模式相对比较滞后，讲个：

关系社会：关系搞定

霸权市场：地头蛇

线下秘密交易/贴身服务：明天就来我办公室一趟

所以他们还充当着白手套的角色。

（3）过去：人才支出大于收入

在中国目前弥漫着一种潮流：数字化技术能力，开始成为企业的核心竞争能力。

所以，现在互联网、电子商务厂商高薪抢人，现在获得巨量风投的创业IT公司也在高薪抢人，就连承担着国家卡脖子创新突破、新旧动能转化的巨型大型央国企，也都纷纷成立独立的科技公司，以灵活的社会化岗位编制与岗位薪资来抢人。

都抢人，那自然IT人才成本高企。但中国企业服务的涨价，却跟不上IT人才成本的飞涨速度。

所以说，怎么区隔核心能力与非核心能力，怎么区隔固定成本和可变动成本？于是，社会化生态....

（4）过去：巨型企业高要求解决方案服务

SAP从1971年成立，一直聚焦巨型大型企业，中型和小型的应用收入在SAP几乎可以忽略不计。但就是这样，SAP还不断地剥离自己，让自己成为一个单纯的产品软件研发公司：

1976年R/1成熟了，把SAP分离成两个公司，一个是SAP软件公司，一个是SAP销售与服务公司

1982年R/2发布，SAP乘机把定制开发业务剥离出去，SAP专注标准产品研发，不搞客户定制开发了。不过SAP为了剥离，在1979年发明了ABAP低代码开发语言，而且为了剥离专门成立了固定的开发者支持部门

1993年R/3发布，SAP乘机把服务剥离出去，SAP寻找到了埃森哲，和埃森哲紧密合作，埃森哲来负责：业务咨询、IT咨询、生态集成解决方案设计与销售、安装部署、ERP配置实施、数据清洗、客服支持、技术支持、现场运维服务。

你看，就连成立50年来一直定位巨型大型客户的SAP，自己也做不了巨型大型客户，还得靠：麦肯锡咨询+SAP标准产品+IBM系统软硬件与生态解决方案总包+埃森哲实施服务运维服务+汉得定制开发服务这套组合...

（5）未来：平台

随着云平台的产生，现在产生了一系列平台：

大数据平台

低代码开发平台

开放集成平台

应用中台：如电子合同、电子发票、电子档案、企业支付、银企联云...

协同平台

这些平台，都不是中国企业的业务部门直接能拿来用的，必须基于这些平台之上搞具体的应用，才能真正被中国企业的业务部门用户可感知可理解可使用。

所以，搞这些平台的IT厂商，必须发展生态，不发展生态，它们自己一个就没多少价值。

（6）未来：产业互联网

在过去，垂直行业业务应用软件厂商、OA厂商、ERP厂商，三者河水不犯井水，各卖各的。在客户项目处，该做ERP集成、该做OA集成，一个个客户项目一个个做呗。这是中国的过去和现状。并没有一个公司，既有自己主打的软件产品，还搭配代售别人的产品。（除非是一家系统集成公司，没有自己的主力产品，只好东市买骏马西市买鞍鞯来给客户提供集成解决方案）

但是，如果要涉入到产业互联网，没办法，每个产业互联网必然是个垂直产业特色极其鲜明的，所以，不搞生态，光靠自己的力量来给客户这种鲜明特色做定制开发，那简直是自己累死、亏钱、客户还不满意。所以有搞产业互联网项目的IT厂商，要么退出产业互联网平台建设这种业务，要么鸡贼地外包给外包开发公司。外包开发公司干了段时间发现也是累死、亏钱、客户还不满意，于是也不做了。于是，中国产业互联网平台建设项目全都不搞了。

正确的玩法必须是生态套路：

• 业务服务：如数字营销业务、电商代运营业务、供应链金融保险业务等等，由业务服务公司负责
  

• 定制开发：由外包开发公司负责
  

• 行业业务应用：由行业业务ISV公司负责
  

• 产业互联网平台：由产业互联网平台商负责
  

• 云技术平台：由云巨头负责
  

（7）未来：高门槛技术

现在中国特别流行新技术，号称数字化转型。什么智能硬件IoT、AI服务、区块链、云原生弹性计算/四地五中心分布式私有云平台....，能上的都上。

可是，谁会做智能硬件啊？

可是，谁会做AI服务啊？

可是，谁会做社会化大数据服务啊？

没办法，只好生态产品集成了。