电商平台数据解读「数据中台的概念」

编辑导语：随着如今大数据时代的不断发展，数据中台这几年也颇受各企业的欢迎，不少企业都开始建设中台系统，并且数据中台在很大程度上帮助了互联网业务的发展；本文作者分享了关于数据中台在电商中的应用，我们一起来了解一下。

一、前言

提到了“数据中台”，笔者想先谈一下关于“中台”自己的看法，阿里中台的例子想必大家都已经很熟悉了；那个时候恨不得全民中台，笔者也是在那个时期才开始积极了解中台的，像是抓住了软件行业下一个发展阶段的金钥匙一样，仿佛这把金钥匙能打开所有疑惑的大门。

笔者通过看《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》这本书，对阿里中台有了一个比较清晰的认识，阿里是在参观了游戏公司“Supercell”后，从“Supercell”的游戏开发过程中受到启发，从而启动了中台战略，是阿里“共享业务事业部”在技术层面的实现。

书中关于对中台的讲解，笔者从一个非技术从业者的角度理解一下：把提供重复功能的服务抽象出来，重建成公共服务，在避免重复开发的同时，直接缩短产品的生产周期；让“平台”能够对业务作出迅速的反应，以便在激烈的商业竞争环境中能够更加灵活，让基于中台的阿里产品能够更快地试错，更快地迭代，更快地找到适合这个市场生存的模式，最终提升竞争力。

这其中有几个关键的作用必须要提一下，那便是“复用”和“共享”。

“中台”的概念一度被炒作的很热，很多企业在中台建设中走了弯路，也有很多企业前仆后继地建设中台，花费了精力，却没有带来理想的结果。

虽然如此，但“中台思维”却是值得大家去思考并实践的，阿里中台的出圈，更是给大家普及了“复用”与“共享”的重要性。

我们接下来一起看看“数据中台”给电商企业解决了哪些“复用”与“共享”的难题呢？

二、电商企业的数据痛点

从事过电商信息化的朋友或者在电商企业做过信息化相关工作的朋友应该都理解，电商信息化的解决方案，在当下还是以“拼凑”为主，CRM、客服软件、财务软件、工单、ERP、OMS、WMS、BI等各种各样的信息化工具大多数来自于不同软件企业；由于相互之间不能打通，俗称信息孤岛，企业在做起数据分析来非常繁琐，甚至各个部门的数据统计口径都难以统一。

为了解决上面这些难题，有很多头部电商企业自建了信息化部门，被“逼上梁山”，是呀，如果市面上能够有一家软件企业能够系统性的解决这些问题，电商企业也不必背着高昂的软件研发成本在发展的路上狂奔了。

当然，这里面有很多原因，有业务的多样性问题、专业的深度问题等等；但是又反应了我们电商信息化市场的多样性和包容性，如果有一家企业的产品能够覆盖全部的业务环节和场景，恐怕他又要担心垄断的问题了吧？开个小玩笑，不过笔者还真期待有那么一款产品的出现。

铺垫了那么多，当要说到电商企业都遇到了哪些数据痛点的时候，笔者还真有点慌，实在是太多了，我们先提几个典型的场景，然后通过场景再具体展开分析一下吧。

场景案例：

运营需要按照平台、店铺、支付时间范围、SPU、SKU、链接、链接内SKU等等维度和粒度的数据查询，用来做经营分析；财务需要所有平台、店铺的订单对账信息；采购需要商品的明确销售情况，用来做销售预测并作出采购计划。

总结一下这几个场景的痛点，其实会发现很多共同点，例如运营和采购的两个业务场景，他们都需要销售商品的数据来支撑，并且均需要数据粒度精细到最小。

为什么说这几个数据应用的场景是电商企业的痛点呢？

通常在实际业务中，商品信息在平台的存在形式是以链接为商品（SPU）级，链接内包含很多规格（SKU），但是链接中的SKU对应商家的商品时，有可能并不是代表一个最小销售单元的SKU，有可能是包含多种商品或者是多件同一种商品的一套组合商品，这时候，在商品信息这一级，平台与商家的系统便出现了不统一。

正常情况下，对于商家使用的系统来讲，从商品信息本身的SPU和SKU级别，以及组合商品级别进行统计是目前ERP常见的操作，能够对全平台店铺的商品链接做出销售链路的统计分析基本上是没有能够做到的，更多的是依赖平台的其他工具。

例如我们看下图，百草味的这个商品链接，有可能就是我们上面提到的组合商品形式。

在当下，很多电商ERP中的数据统计功能仅仅是提供了各种数据的统计，流程没有信息化；而数据又很难实际应用到流程中，无论是从数据维度上还是灵活性上，ERP中自带的数据统计功能已经很难支撑实际的业务应用了。

随着现在数据对于业务的重要性被大家逐渐认识，在供应链管理流程中，数据的重要程度更是提升到了新高度。

由于现在的销售业务覆盖了太多的场景，O2O、B2C、B2B等等各种X2C业务层出不穷，随着销售场景的增多，各种场景下对于供应链的要求又不尽相同，以往传统SCM系统的老办法逐渐满足不了新场景的需求了，对新解决方案的需要迫在眉睫。

三、数据中台的横空出世

轰轰烈烈搞中台的劲头慢慢消退了，以前存在的问题仍然存在，该解决的问题却一个也没少，大家逐渐认识到中台可能并不一定适合自身。

上文给大家简单描述了中台的概念，以及一些数据在企业应用中所遇到的一些痛点；我们转换角度思考一下，既然企业搞不清楚自身到底适不适合上中台，那我们只用“中台思维”来解决数据层面的问题不就好了吗？数据不是最适合用来“复用”和“共享”的元素吗？

例如在电商企业的业务中，各个业务模块用着不同产品的软件，数据不互通，无法共享和复用，通过数据中台的建设，正好可以解决数据孤岛的问题；并且，可以避免建设其他中台所需要花费的大量人力物力，这看上去是一个解决问题最实际的方法了。

要特殊说明的一点是，数据中台是通过对数据的收集、清洗、处理、储存，通过数据建模对外提供数据服务的产品，笔者的知识储备量实在很难讲清楚数据中台的发展由来；但是从产品的角度看，数据中台产品的出现，正是顺应了数据服务产品的发展，填补了数据服务这一领域产品的空白，让企业在考虑数据服务解决方案的时候多了一个选择。

四、数据中台在电商中的痛点

1. 数据源的获取

第一个提到了数据源的获取，不像一些互联网产品，在自身产品中做埋点获取数据就可以了，目前对数据应用需求非常大的电商企业的境遇就没那么好了，阿里、京东、拼多多等一些主流电商平台都有自己的服务平台，甚至有些电商平台都搭建了自身的云计算服务，不仅从平台层面杜绝了数据的互通，从物理层面也是严防死守，各大电商软件头部的服务商更是不敢越雷池半步，不敢私自把数据接口提供给商家。

看上去这个痛点的解决方案已经十分明显了，要么自建系统，要么靠其他复杂的方案“曲线救国”。

总之，目前的环境对商家使用数据来讲是很不友好的，而数据中台的落地，数据源问题是必须要解决的问题。

2. 数据中台的落地

信息化产品的落地应用一直都是一个热点话题，数据中台本身是数据应用的一个整体的解决方案，它的作用并不局限于某一个特定场景，它可以用来做业务报表的集成，也可以用来做业务的数据模型应用到业务的流程中。

在很多落地场景中，他只想要一个报表，我却给了一个BI，他想要一个BI，我却给了个数据中台，他想要一个数据中台，我却给他画了一条龙，这种资源错配的情况并不是很少见，出现这种情况，往小了说是对需求的理解不到位，往大了说是企业信息化规划的思路不清晰。

怎么理解？

电商企业区别于技术实力强劲的互联网公司，信息化的基础是比较薄弱的，更无法从企业发展的角度出发，提出能够满足发展的信息化解决方案；业务部门的需求一般都是紧急重要的，但通常情况下，紧急重要的需求都是“积劳成疾”，例如电商财务的对账需求，当流水少的时候，可以通过从平台下载账单，然后用excel的方式进行对账，数据量稍微大一些的时候，把电脑配置升级一下也能凑活过去，但是当数据量大到一定程度的时候，excel就搞定不了了，这时候，业务部门才会火急火燎的寻求技术解决方案；通常这个时候，需求又比较着急，手头又没有成熟的解决方案，就很容易造成资源的错配。

3. 小结

在很多互联网公司中，数据中台或者是类似的数据产品都已经得到了广泛的应用，在电商企业中，信息化的建设也被越来越多的企业重视，但是对于数据中台的应用，笔者还是建议在不了解数据中台能给自身带来哪些帮助，以及如何去应用数据中台的时候，不要盲目跟风地上数据中台。

如果要上线数据中台的产品，务必要搞清楚以下几点：

数据中台能解决的问题：

数据的收集，数据孤岛的解决；数据的复用以及共享；数据应用开发的灵活性。

对于自身要考虑：

明确自身对数据的需求，哪些场景需要数据结果；数据需求场景是否是单一固定场景，未来有没有扩展的需求；多了解数据解决方案，衡量投入产出比；作为数据来源的信息系统是否能够提供稳定的数据来源。

希望以上几条建议能够帮助大家做好充足的准备，选择适合自身的方案，避免“慌不择路”。

五、结语

蹭着最近数据中台的热度，笔者结合自身相对了解的行业谈了谈对于数据中台在电商中应用的看法。

从产品的商业角度来看，数据中台产品和其他ToB软件产品走的路径是差不多的，即头部玩家立项研究；到单一行业规模应用，再到标准化产品普及各行各业，数据产品在ToB领域能够有一席之地，就说明了它的商业价值是被认可的。

从产品自身角度来讲，标准化的数据产品架构，解决了数据开发的灵活性，也解决了数据应用的灵活性，这是数据产品提供的基础服务。

但是区别于数据在ToC产品中的应用，ToB的数据需求更加复杂；在各行各业推广的过程中，通过数据专家的建模，让数据产品能够真正从业务流程中落地，从而让数据产品给企业赋能才是数据产品在ToB中的价值所在，不然，它只能是一个数据存储，生成报表的技术解决方案。

最后，感谢阅读，希望这篇文章能够对大家有所帮助，如此，便是我的快乐！

本文由 @橙子哥哥 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自Unsplash，基于CC0协议