转载

SaaS是形，数据应用是本

编者按：本文作者王华，互道信息 CEO，授权36氪发布。

自打投资焦点转向企业服务领域之后，出现了很多关于SaaS的讨论。其实这个问题至少十几年以前就在业内争论过。现在很多的关于SaaS的讨论还是集中在商业模式创新上，甚至还扯到是不是只有基于公有云才算“正宗”SaaS。可事实上，这几年来，以Salesforce为代表的SaaS公司自然是做得不错，而以SAP为代表的“传统”企业软件厂商也还是活得挺滋润。这不是软件形态和商业模式孰对孰错的问题，其本质还是新的产品和服务能否满足新兴业务场景的问题。

SaaS是形，数据应用是本

我曾和Salesforce的研发高管在美国做了深入交流。Salesforce和SAP CRM 的核心用户都是大中型企业。2015年，Salesforce收入的80%来自于不到2%的客户，这些大客户同样需要不短的销售周期和不小的定制化。但Salesforce以SAP没有做好的产品作为切入点，同样取得了成功。可是，最近Salesforce又为什么要收购Demandware呢？Demandware并不是一家符合流行的SaaS定义的公司，既不是真正的Multi-Tenant，也没有PaaS。这难道意味着SaaS潮流的倒退？

让我们在争论商业模式创新（SaaS与否）的同时，不妨从产品和技术创新的角度来看看目前企业服务市场所面临的变局。

这几年新兴起的有影响力的众多企业技术服务公司中，如果从产品角度看，我觉得可以分成两类。一类是把传统厂商没有做好的事情，利用新技术、新用户体验把产品做好，以满足客户需求并取得成功的，如CRM；另一类就是随着企业经营环境、业务模式的变化带来的新需求，如数据分析、数据驱动型应用。

第一类产品自不必多说。这里我花点篇幅分析一下第二类产品，因为这涉及到对趋势的判断。

过去几十年来，企业软件基本上都是在强调“管理”。大家耳熟能详的，不管是企业资源管理、办公自动化、分销管理，还是简单的进销存软件，都是围绕着流程管理展开的。而在这些流程性业务系统中流转的，都是“单据(Document)“。大到“Order to Cash“，小到一个“公文会签“流程，都是围绕着若干个Documents进行的。即使这几年提出来的C2B, C2M等等，大家的关注点还是在单据的流转。说“单据”好像有点low，可是本质上不就是把原来纸质的单据电子化了，然后通过计算机系统(加上后来的网络），在不同岗位间传递。这好像看着有点眼熟，是不是很象上世纪80到90年代的一个高频词：电算化？

诚然，现在还有不少企业可能连这一点“电算化”都没有做到，但这也恰恰是互联网技术首先能够帮助企业解决的。互联网的强大“连接”能力，极尽方便又近乎免费。各种广义的“通信工具”，让企业可以无需自建系统，就完成单据的流转。这也是为什么今天的微信和钉钉会对一些简单的传统企业软件带来最直接的冲击的原因。

而除了OA等系统之外，现代的企业还需要会员管理、营销管理、物流管理和商品管理。和销售订单管理、采购订单管理以及发票管理等不同的是，会员、商品、物流、营销等的管理必然是基于数据的管理。很难想象，一次营销活动是基于某个单据或指令的。而物流也应该是基于全网、全渠道的实时库存和动态销售情况，来达成全公司整体利益的优化，而不是物流部门自身费用的局部优化。商品的企划、试销、改款、铺货和补货，在全渠道经营业务场景下，无一不需要全网的数据支撑，而且数据反馈一定要及时。所以，在这样的经营模式中，部门和部门之间，公司和公司之间，都已经不再是简单地基于流程、单据或指令的协作，而必然是基于数据的协作。

这是一个从基于流程的商务协作，向基于数据的商务协作转型的时代。这是互联网普及后，倒逼企业去做全网、全渠道经营时所推动的转型。新兴的业务场景寻求新的企业产品和服务。

这样的数据驱动的商务协作模式，其实早已拉开序幕。做数字化营销时，广告主和广告商之间不就是基于数据的协同么？教小孩子画画和教舞蹈的商家之间的异业联盟，不就是基于数据的协同么？

有了数据的驱动，原有的流程性业务系统才摆脱了简单的“执行“角色，才变得开始有了”智能“。由此，企业信息系统才从“电算化”进化到“数据化”及“智能化”。这样的进化，不管对企业本身，还是对技术服务商而言，都不是一件容易的事情，丝毫不亚于当年ERP兴起的时候带来的冲击。也正是因此，才创造出一个巨大的市场空间。

过去几年中，基于对这个趋势的预判，对基于数据的商务协作技术，我和很多客户及同行一起有过很多的交流和实践。从中，我大致归纳了以下三个方面的问题：

一、数据在哪里？

企业在经营活动中自然产生很多数据，包括ERP、WMS、CRM等业务系统中流转的单据，当然线上业务产生的数据更多（浏览、点击、收藏夹、购物车、评论等）。还有一类数据不是在自己的经营活动中产生的，而是从外部数据平台“买”来的，如第三方数据平台以及外来的流量。

这几年，出现很多很好的产品，可以帮助企业去抓取数据，特别是线上数据的采集的技术门槛大大降低。线下数据的抓取也有很多新技术在持续推动，包括WiFi，iBeacon，RFID，视频识别等等。

可惜的是，这些数据要么是在各个孤立的业务系统中，在完成流程处理的使命之后就在数据库里睡大觉（特别是ERP）；要么就是用了之后就没有留存下来，如“买”来的流量，成为“一次性数据”。

与此同时，很多企业在前些年花了不少钱，买了大量服务器和网络设备，建设了所谓的企业“数据中心”。可是，我相信，实际上包括这些企业自己的IT部门在内，往往还是习惯性地称其为“机房”。这，才是真相：这个“数据中心”只是一个物理上的中心，把服务器设备放在一起，让领导看得见，安心而已。

而企业需要的是一个真正的数据中心，把分散在各个系统中的数据整合起来。不仅仅是要消除各个业务系统之间的流程孤岛，更要消除数据孤岛。

而随着各种新业务“触点“和“端”的不断增加，数据量和计算量都是飞速增长的。比如，一个门店每天通过WiFi、RFID等设备采集的客流和试衣数据就可达到几十万条。总数据量比交易数据高至少3-4个数量级。因此，企业数据中心要有能力高并发地接收海量数据。同时，通过即插即用的数据对接能力，把来自外部的数据也留存在数据中心。数据中心还要能实时加工，完成数据的清洗、拼接等工作，才能为其它的应用所用。

这一切，对于传统的基于交易事务的软件系统架构来说，改动代价极高，风险很大。

二、数据怎么看？

企业应用离不开图表。经常有客户提出要我们定制几个报表或图表。我都会先追问一下，这个图表用以解决什么问题？绝大部分情况下，图表是用来帮助决策的，图表的终极目标是直接形成决策建议甚至业务指令。所以，数据不是用来看的，而是要“用“的。有兴趣的，不妨去看看Tableau的股价走势，我的看法是，数据光看不用，没用。

三、数据怎么用？

数据本身没有价值，只有用到了才体现其价值，而且，一定是“数到用时方恨少”。数据的应用价值，是通过数据的流通和应用输出能力来体现的，即数据应用(Data App)。

比较常见的数据应用场景之一是广告营销。现在有了数据中心以后，可以让精准的营销能力延伸到每个触点。比如，让每个导购员通过数据中心获取会员的完整知识图谱，将该会员分散在各个系统中的事件、行为序列等杂乱的信息整理出来，以便于浏览和使用的方式推送给导购员。导购员就从“单兵”变成了拥有全方位战场情报支持的“特种兵”。

而更深层次的数据应用场景，是通过数据中心和流程中心的耦合形成的闭环应用。并且，根据数据中心独立于流程中心的特点，这类数据应用可以通过数据的全流通，实现跨流程节点的实时联动和全局优化。

例如，在全渠道经营模式下，当线上订单蜂拥而至，仓库不堪重负的时候，通过对订单的地址、商品需求数据与门店库存、门店位置、客流量、动销率等实时数据的分析与整合匹配，再结合来自于客服中心以及社交媒体的该消费者的数据，可能在原订单中添加和该消费者权益有关的服务项目之后，订单再被快速分配到最合适（不一定是最近）的门店进行打包，并同时通知快递公司进行派送。对于商家来说，仓库配送压力大大减轻了，门店空闲时刻的人力被利用起来，整体资源利用效率得到提高；对于消费者来说，配送的效率提高了，还得到了一致的会员权益服务，品牌消费体验自然也得到了提升。在这个例子中，基于数据中心的全渠道OMS系统就是一个数据应用，能够综合源自各个业务系统的数据，做出全局优化的决策，并通过发出指令到相应的业务系统（零售POS、TMS）去执行流程。这是数据中心和流程中心之间的一个闭环应用。

这样的数据应用场景还存在于配送中心。例如，把零售分销系统中所有门店的实时销售和客流数据，反馈给在路上行驶并承担区域配送中心（RDC）角色的物流车，达到快速动态调整库存的目的。据我所知，一家著名服装品牌公司已经在这方面取得显著的效果。

即使在营销方面，我们还可以把传统的DSP广告投放，通过和企业自有数据中心的DMP、全渠道OMS的结合，形成从会员分层、广告投放、展现效果到交易转化的完整闭环，并根据各渠道量化指标动态调整渠道投放策略。

类似的数据中心结合流程中心的闭环应用场景还有很多。有了数据中心的驱动，企业的业务系统才可以变得有智能。数据中心是企业运营真正的大脑，而流程性业务系统是五官和四肢。

说完数据中心，再回到本文开头的问题。作为SaaS企业的代表，Salesforce为什么要收购Demandware呢？因为Salesforce需要Demandware这样的业务流程系统，通过CRM和OMS系统的后台整合，形成一个兼具数据中心和流程中心的大后台。SAP这几年也频频收购公司，也是为了进一步增强后台系统，结合投入多年研发的新数据库平台，提供整合的产品。不同厂商之间的系统打通不是件容易的事情，看看当年IBM、SAP大力倡导的SOA架构有没有真正起作用就会知道，历史总是有相似之处的。不同SaaS之间的整合打通也面临同样的问题。而企业用户恰恰不喜欢面对一堆碎片化的云应用。企业是需要用于不同业务场景的多个应用，但是这些应用应该是基于一个大平台。所谓，“大平台，小应用”，才能确保企业应用的延展性和一致性。

所以，企业要转型数据驱动的管理模式，需要的是一个尽量整合的系统，让数据中心和流程中心之间可以更方便地打造更多闭环应用场景。而这样的系统不可避免会有定制工作，包括行业特性以及特定客户的。对于企业服务领域的新创公司，必须要走产品化道路，就要控制定制化所占的比例在30%以下。而要达到这个目标，必须依托一套标准化技术和开发平台。这个技术平台本身就是一个门槛。好在也没有必要非得一开始就把这个技术平台当做“PaaS”开放出去。一来，一旦开放了，就束缚了革新的手脚，要知道把接口定义清楚也是一门技术活；二来，新公司也没那么快具有公信力，让别人愿意在这个平台上开发应用。Salesforce也是推出第一个CRM之后，过了6年之久才开放Force.com作为开发平台的。所以，我们选择的道路是：要打造PaaS，但先仅供内部使用，要求所有产品功能的开发都基于这个PaaS；同时，联合一家有技术能力的行业龙头企业，和我们共同开发基于此PaaS的行业应用。藉此，我们既不盲目背上太早开放PaaS的包袱，又能通过上层的应用加速倒逼PaaS的形成。

犹记得，当年很多论调，称B/S架构比C/S架构先进，代表着“未来”。可如今还不是Web和App应用并存么？所以，起决定因素的还是产品本身的创新点是否符合这个增长的市场趋势，满足新兴的企业业务场景。而SaaS模式是商务上的助推器；云计算的特点也恰恰天然地符合企业对数据中心的需求。

“在云端用人工智能的方式处理大数据“，马化腾先生不是随便说说的。

原文 http://36kr.com/p/5049532.html

正文到此结束