如何在云端管理企业数据.docx

特瑞格网络技术（北京）有限公司NetSuite中国战略合作伙伴过去几年中，基于对这个趋势的预判，对基于数据的商务协作技术，我和很多客户及同行一起有过很多的交流和实践。从中，我大致归纳了以下三个方面的问题：一、数据在哪里?企业在经营活动中自然产生很多数据，包括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年之久才开放F作为开发平台的。所以，我们选择的道路是：要打造PaaS，但先仅供内部使用，要求所有产品功能的开发都基于这个PaaS;同时，联合一家有技术能力的行业龙头企业，和我们共同开发基于此PaaS的行业应用。藉此，我们既不盲目背上太早开放PaaS的包袱，又能通过上层的应用加速倒逼PaaS的形成。犹记得，当年很多论调，称B/S架构比C/