前两天，创业期的小胖哥在群里谈到一个新词儿，“数据中台”。
胖哥是 Python 界玩得比较资深的人士，他都在打磨的产品，肯定是很有市场的。所以特意找了些文章来学。大家都知道的，现阶段只要跟数据挂上钩，跟 Python 有搭界，那就准有看头。知乎上关注 Python 的人已经有 33万了。
知识星球已经成为我自身记录灵感的地方。有好的理念，陌生的知识，我都选择在知识星球落下一笔。回头复盘的时候，如果有兴趣就深入的写写笔记。回头再选择发表在公众号上，所以星球变成了最先发表的平台。公众号则更加注重排版和正式的完稿。
以下是契机：
在综合了多方资料后，慢慢形成了这篇文章。
首先中台战略存在的前提条件，便是要响应业务的需求。
而业务的需求为什么非要一个中台来解决，而不是单纯的软件系统解决呢。比如 MES, ERP, Pos, CRM.
很大程度上，业务是建立在企业整体发展上提出的需求，比如工业4.0（智能制造），订单方式一改以往的批量生产，而采用了定制化生产。多个工艺路线或者多组设备可以交叉执行任务，8英寸，12英寸芯片可以同时下产线生产，设备完全自动化。此时客户希望看到的是自己下单之后，可以清晰的看到自己的产品已经在生产线的哪个工艺了。
而我们的 MES, ERP， CRM 通常都是三套系统，互相之间并没有灵活的调用接口来满足查询。前端的想象力永远是前卫的，多样的和丰富的，有时候甚至是来势汹汹的。毕竟前端负责的是业务，是流量，是转化。
所以满足前端的想象力，后端要求更快捷的部署和实现。而作为后端的这些系统，往往上线周期并没有前端那么快，一个小程序，一个 app, 一个网页窗口，可能 2-3 天做好了，但 ERP/MES 却要在破坏原有稳定性的基础上增加这些功能，作为各自的负责人，是不愿意买单的，即使愿意做这项事情，上线之前经历的开发，部署，测试也会有很长时差。往往上线了，但风口已经过去了。
第二，中台的概念以及应用场景已经描述清楚了。接下来，到底该怎么实施中台呢，中台应用到的技术栈到底是什么？ 一旦供应商说，我有个中台卖给你，你会觉得靠谱吗？
既然中台的产生，是因为前台的善变，后台的渐变造成的，那么统一这些后台资源，加上抽象，为前台制造一些快捷的接口，就变得十分自然了。应运而生的中台，是各个企业自身业务系统的综合，显然，买个中台产品是无稽之谈。 只能靠自己的建设，满足前台多变的需求。
数据仓库，知识图谱，元数据，数据字典，数据湖等等数据治理的手段便成了中台技术的实现。大部分的技术现今已非常成熟了。所以我们 SQL 技术人的强项可以在这一层发挥很大的作用。但知识图谱，数据湖等建设技术基础，我们还是要适当跟进，毕竟那个 RDBMS 一统江湖的年代，渐行渐远了，而分布式计算，机器学习和人工智能离我们越来越近。技术的保质期正在缩短，想要更好的服务于企业，体现自己的价值，多些技能装备，百利无一害。
往深远一点的方向延伸，数据中台并不是企业信息化建设的最终目标。
最开始，企业建立信息化，自研或者外包实现了多种信息系统，为的是能够将企业的数字沉淀下来，让丰繁的统计工作变得顺畅。这一时期，是为企业的运营服务。换句话说，信息系统的实现以企业流程在电子化平台的顺利走通为完成目标。
业务发展越来越好了，客户对企业的数字化提出越来越高的要求，企业满足不了，我们引入了数据中台。弥补了后台稳定且不接受多变需求的短板。
比如客户对产能的把握没有信息，而企业自身也拿不出从前道，中道到后道这套流程的产能效率图。虽说产品品质好，但提供不了踏实的数字证明自己的能力，在中标几率上是大大的降低。引入元系统管理，数据仓库技术之后一切证据都立刻呈现在客户的浏览器上，几个数字一拍，客户立马懂了。业务也就好做了。
但数据中台建立之后，发现了更多数据的价值。比如原先没有发现的规律都在利用数据的过程中发现了，工程师拿出了更优的解决方案来管理现有的生产。这就是知识管理的另一个方向。通常技术人员只埋头于技术实现上，并不能很好的引导公司管理组织在数据上要效益。而业务架构就有这份能力与责任了。
创造业务便是数据中台之后的阶段要完成的事情。机器学习，人工智能等技术用在这些方面，完成了原本一一对应的输入与输出到一份输入，多份产出的转变。为创造更多业务提供了方向上的可能。
猜你喜欢：
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
