能力中台是发展趋势

在前面的文章中，我曾经谈到了为企业构建一个基于核心福利场景，即衣食住行，吃喝玩乐全部覆盖的福利能力中台。

为何要做这个能力中台服务？

简单来说就是一个企业的福利要想全面化，灵活和有弹性，你如果一家一家地去对接冲话费，加油卡，各大电商平台，美团和大众点评，携程和去哪儿网等会相对麻烦。而我现在告诉你我现在能够提供一个统一的能力API平台给你免费使用，你感兴趣不？

包括我会进一步告诉你订机票，你也不用几个平台到处查了，能力平台给你的就是综合比较后的最低价格，是否能帮你节约成本？

也就是说这个福利能力中台不是简单地提供API接口服务，而是真正的多外围多个能力提供商和服务能力的适配和聚合，让你能够采用同样一个方法和标准对接口进行消费和使用，并进行后续的接口运行管控。

我始终坚持一个观点，即：在当前数字化转型和企业边界越来越弱化的情况下，API能力开放平台，特别是能力聚合平台一定会得到更加快速的发展。

从早年的ifttt说起

在多年以前，国外就推出了一个叫ifttt的应用，在这里我们先看下这个应用的介绍。

ifttt是“if this then that”的缩写，事实上是让你的网络行为能够引发连锁反应、让你使用更为方便，其宗旨是“Put the internet to work for you”（让互联网为你服务）。ifttt旨在帮助人们利用各网站的开放API，将Facebook、Twitter等各个网站或应用衔接，完成任务，使“每个人都可以成为整个互联网不用编程的程序员”。ifttt通过流程将各种信息串联起来，然后再集中把你要的信息呈现给你。解决了信息的冗杂，收取或关注重要信息的问题。

是否看了上面的介绍还是不太清楚。

实际上从if this then that的字面就容易理解是如果满足什么条件就做什么事情，也就是我们常说的基于规则触发的事件或消息订阅机制。

比如我们可以定义一个规则事件，即如果我在头条文章的阅读量超过了1万，那么就自动将我把文章同步发送到新浪博客。再比如我们可以定义，如果明天的天气有雨，那么就给我打一个语音电话提醒我出门带伞。

如果再简单点来讲，ifttt实际解决两个方面的问题。

其一是消息订阅和事件推送：也就是只要我按规则定义了事件，那么当规则满足了时候我就能收到事件同时，而不再需要我不断的去轮询我关心的事件有无结果。从技术上来说个人消费者应该处于一种非阻塞状态。

比如常见的如果我买的股票跌幅超过了5%，那就及时发短信通知我，或者按我预订的规则系统自动帮我平仓止损。

其二就是当前各类SaaS应用，云服务分散化，而这些应用之间往往很难通过某种规则进行联动。而ifttt刚好解决了这个问题，完成了多个云服务能力间的协同，这种协同可以是API接口级别的，也可以是类似RPA方式的都可以。

比如我出差时候，预订机票在携程，去机场打车用滴滴打车。而这里有一个通用性的规则，即应该是在我预订完机票后，自动去滴滴平台帮我预约一个提前3小时出发的车辆。两个云服务通过某种规则完成自动衔接。

也就是说最终的用户或消费者，更多的是希望通过某种规则来完成一些复合场景，以减少在多个应用或云服务中的大量的手工操作。这个实际和我们当前说的API组合和服务编排思想也类似，就是要基于原子API服务能力，在充分理解场景化需求后，提供给用户更多的组合服务能力实现一站式服务。

这也是我在讲能力中台时候提到的一个高阶能力，即基于接入和聚合的服务进一步进行组合和编排，实现满足场景化需求的组合服务的能力。

几个线下和线上群给我的思考

最近几年，可以看到知识经济，知识变现，自媒体，在线教育发展迅猛。首先要承认知识本身是有价值的，但是你同时还要承认有价值的知识毕竟是少部分，对于大部分知识往往并没有价值，而且还耽误你的时间。

因此要看到对于任何一个人来说，难的不是知识付费，真正的难的往往在于如何快速地选择和鉴别到真正对你有用的知识并受益。如果你知识付费多年，连这种最基本的鉴别能力都没有，那么你就完全是一种自我的知识焦虑在作怪，被经常性的割韭菜也是正常。

由于我自己也长期写作，我个人实际是比较讨厌哪种知识拼凑类写作者的，网上文章，多个书本的内容这里摘录一点，那里揉一段进来就拼凑成一篇文章，这类文章本身很少有自己的观点，仅仅是知识的二次贩卖。

但是如果一个人确实可以帮助你整理信息，规整信息，并大量减少你自己的搜索，整理时间，实际上这个事情仍然是有价值的。

我们举两个最近的线下和线上群的例子来进行说明。

第一个例子是我同学相关的，自己小孩要考广州的好初中，前面几年各个好的初中都会有自己命题考试，自主进行拔尖招生。因此这里面就需要有人时刻的关注学校发布的信息，有可能还需要现场去打听，去咨询一下具体没有写清楚的问题点，或者还需要找往届家长打听复习的重点，考试的一些要点等。

这些内容你想简单地在网上全部搜索到绝对不可能，因此有往届的家长就自己搞了一个微信群，专门为家长提供给出咨询答疑服务，消息发布服务。这个服务本身大部分家长都愿意付费加入，也节省了家长的时间。

第二个例子是最近深圳买房，你会发现出现了很多大V搞的购房微信群，在群里面答疑买房的问题，帮助你解答打新的流程，帮助你审核和上传资料，这个群当前也存在市场，有很多人加入，简单来说这个群收费的金额和房价比九牛一毛，同时大大节约你的时间。

大家有没有思考过，在互联网信息如此发达的情况下，为何还会出现上面的收费群。简单来讲主要原因如下：

信息的进一步加工和整合有价值，能够基于个人定制个性化的信息有价值，有些需要人员亲自线下去验证和检验后才确认的信息更加有价值。

很多时候在卖方市场的时候你会发现，卖方往往并不关心自己发布的信息是否写得足够清楚，如果没有写清楚你自己去问，最终的消费者是否要多跑几趟路才能搞清楚，才能够准备完整需要的资料并不是卖方关心的事情。

你如果没有加入这些群，那么就需要你随时都在搜索甲方发布的信息，随时都在搜索网上的消息，或者随时都需要到现场去问情况。否则你稍微不关注，就错过了关键的信息，也就是说你关注的信息并不会基于你的要求第一时间推送给你。

解决之道-面向C端用户的KPI定制平台

首先我们来看下是否有真正的业务需求和场景驱动，举例来说，比如你关注某个地区或城市的房价，你一定希望能够看到最新的房价，交易数量，供求比，租售关系等关键指标的时间趋势。或者说你关注某个股票，你可能需要看到股票本身的周期K线图，同时看到该股票本身的类似市盈率，市净率，股东户数，基金持股等各个季度的变化趋势。在看到变化趋势后，同时你可以设置当某个关键的KPI指标达到某个值的时候提醒你。

对于电商平台和购物，往往存在同样的道理，在早期购物比较常见的是比价平台，而实际上当你真正关注某种商品的时候，你仅仅是需要当商品有大的促销或折扣，或者说当特定型号的商品价格低于多少的时候能够提前通知你，这就是一种典型的基于事件和消息渠道。

如果我们要做分析和决策，最高效和最节约时间的往往就是读图，而任何可视化图形的形成本身又是基于大量带有时间属性维度的数据构成，即数据仍然是最根本的。有了读图，才有能如果在图形上显示出明显的上升或下降趋势，指标的跳跃或中断的时候，我们应该如何去分析和查找隐藏在数字后面的深层次原因。

上面的需求是否已经满足？

实际上你可以看到一个炒股软件本身是可以定制事件通知的，比如跌幅超过多少预警或发短信通知；一个电商平台可能也有事件通知，比如你收藏或加入购物车的某一个商品如果降价第一时间通知到你。

但是你会发现关键问题在于这些垂直化的云服务应用之间很难真正地联动起来，其次你需要在多个APP里面自己去完成这些定制，而不是一个统一的平台来完成。

所以一个KPI定制平台首先是一个API能力接口的聚合平台

其次要实现这种基于KPI的定制，在第一阶段实现的时候完全可以是预设指标库，比如房价趋势，汇率趋势，国家宏观KPI趋势，学校的升学率趋势，大学的就业趋势，医院的各个专业的排名趋势等，这些都可以作为预设指标进行自动化的数据采集和加工，作为形成KPI图形展示的基础。

而到了第二阶段，如果有更好的AI人工智能和大数据处理技术，那么就是应该实现任何C端用户希望的KPI指标，都能够形成自动化的定向数据采集和加工，然后在最终呈现给用户使用。

我们可以想下，实际在我们日常生活里面经常有很多类似这种信息都需要经常到处问，到处打听，或者上网搜索，搜索一个地方还不行，还需要搜索很多地方的结果自己再进行整合，这些都是实际的对于KPI指标库的潜在需求。面向C端的KPI定制，完全可以理解为一个个人轻BI应用，前端展现是移动端的报表展现工具，而后端是大数据采集，处理。里面实现的关键仍然是不同的指标体系下模型的自动快速创建，数据的实时加工和整合效率。

也就是说一个KPI定制平台是一个数据采集和整合平台，需要采用各种自动化的技术来完成数据的采集，数据的清理和加工，乃至关键信息你还需要人工进行验证和确认其正确性和真实性，最终完成一个信息采集，数据整合过程。

最后，一个好的KPI定制平台，完成关键业务场景下的多个API能力或数据联动，才是这类平台真正提供的最有价值的服务能力。

我们还是拿一个简单的出差场景来进行举例，即当我已经预定了明天早上8点的飞机从深圳到上海浦东出差的时候，这实际就是一个基于出差的复合场景。里面不仅仅是机票的预定，还包括了送车，接车的滴滴车辆的预定，也包括了浦东附近酒店的预定。

而这里我们预设的规则也很简单。

• 送车预约：航班出发时间提前三小时，家或公司
• 接车预约：只需要提供日期和航班号
• 酒店预约：目标地点周边3km，价格400以内商务酒店

这些规则里面有些是提前确定的，比如酒店预订约束，而有些是你在预订了机票后确定的，比如时间和航班号等。而我个人希望的即是在我预订完成酒店后，后续的动作应该基于规则帮我自动完成。同时如果飞机本身有变更或延误，也能够短信提前通知我。

基于以上需求，我们就可以定义一个组合场景KPI来满足。这个场景将彻底打破传统的各个云服务APP间的信息孤岛，实现基于规则的动态联动。

在我前面谈B端企业数字化转型，数字中台建设的时候，经常会说到企业前端应用应该基于中台能力服务层提供的服务能力灵活组装来完成。而实际上回归到C端消费者，你可以看到在日常的工作和生活中，有大量的这种场景是可以进行规则驱动的，事件驱动的。

API能力聚合+大数据采集整合共同支撑了上面的关键需求实现。同时强大的规则引擎能力和API可视化组装能力进一步拓展了应用的深度和广度。

这个最初构想我是在18年提出，即使到今天当前产品构思仍然成立。

你可以理解为这么一个应该是面向C端的KPI内容定制和聚合平台，你能够加工和整合的指标越多，采集和积累的数据越多，那么这个平台产生的数据和内容的价值越大。当前这个想法只是一个雏形，有很多细节还不成熟，具体想法仍然需要进一步验证整体框架的合理性。