企业如何建设有自身特色的中台?

1 评论 5832 浏览 30 收藏 11 分钟

编辑导读:自从阿里提出中台概念后,各行各业不断推出了中台的应用与落实。关于中台的概念和应用已经有很多文章都讲过了,但是具体的企业建设的文章还是比较少。本文作者就以自身工作实践为基础,分享了自己关于企业中台建设的一些思考和实践,与大家分享。

最近开始做中台产品经理了,中台这个词是这两年很火的词,市面上也听到很多企业在说中台,有虚的有实的,有人对此嗤之以鼻,觉得只是一个噱头,不过在我做我们企业中台一些从0到1的建设时候,的确感受到了实实在在的一些变化。

比如业务接入速度,可以帮助某些从0-1的业务,在人力投入比较少的情况下,很快的上线。本来想写一个系列文章,从中台是什么开始写,不过正好最近在做下半年规划,在某些建设方法论上已经有所沉淀,所以先把这个比较深的感悟,先写出来。

总体概述

这个方法论是看了阿里中台建设方法论,结合自身公司实际落地,进行了一些修改,还是比较适用的,借此一些实际操作,对于如何有公司特色的中台,做一些说明:

中台建设方法论流程图:

以下从能力地图、需求结构化、业务清单、业务度量、能力发布几个方面进行阐述。

一、能力地图

1. SOP流程

什么是SOP流程:SOP流程是一个标准作业程序,以统一的格式描述一个事件的标准作业程序和要求,以指导和规范日常工作(百度)。

简单的说,就是把一件事情通过流程图的方式表示出来,如果在企业中,很多不同的部门都在做同一件事情,可能会有不同的流程,但是不同的流程中都会涉及到一些相同的部分,那这个部分就是可以被中台化沉淀的部分。

举例,比如对于一个电商下单流程一般是这样的(做了删减):

通过上面的流程图,就可以抽取出,如果要做一个支撑电商的中台,可能需要的中心层会包含商品中心、营销中心、交易中心等等。业务也需要有对应的前后端做自己的业务逻辑的判断。

那可以看出,为什么要梳理企业的SOP流程:

  • 明确边界:通过SOP流程的梳理,可以更好地知道业务的边界在哪里,同时对于中台来说流程梳理下来,将共用的能力就可以进行抽象,根据业务优先级,进行中台化的沉淀。
  • 帮助企业提效及规范:中台产品与B端产品类似的点在于很多时候是为企业服务的,所以标准SOP流程,可以规范企业的一些做法,有时候做系统并不是单纯的做系统,更多要站在组织的角度考虑

2. 梳理自身中台能力列表/能力地图

对于中台来说,我们已经有什么能力,业务方可以如何去接入。

我对于我们公司中台分为了管理后台与服务中心能力,这个和每个公司自身情况有关,比如我们公司小一些,需要又做能力,又做后台,所以分为两层:

管理后台是运营使用的,服务中心是底层一些能力的抽象。针对电商平台,业务大部分中台提供的能力地图可能是这样的:

通过我们的能力地图,可以更好的与外界进行沟通,作为中台的产品或者业务的负责人,需要更好的做到一个桥梁的作用,将我们的中台能力在内部推广出去,赋能业务。

二、 需求结构化

业务商业化需求提过来之后,很多业务方是不关心对接逻辑的,所以中台建设初期,需要进行需求结构化,就像滚轮子一样,边做业务边做中台。看哪些是可以进行沉淀的,是中心化能力,哪些用配置就可以了。将沉淀的能力,全部变成可配置的方式,让下次接入更快。

刚刚可以看到中台需要做的内容很多,可能支撑企业电商业务,就需要商品中心、交易中心、营销中心等等,那如果停下了直接做中台,没有对应的业务,可能很多企业如果看不到成效会放弃继续做下去。比如我们在建设我们企业中台时候,则是根据业务的迭代需求,比如需要先售卖再营销,那就先把商品中心、交易中心做了。做的时候发现我们会员业务比较多,那就再去做权益中心。

所以中台建设的初期,不能用业务接入速度去衡量,但是建设相对稳健一段时间后,越来越多的业务通过配置即可上线,就可以看出成效。

三、业务全景图

业务列表和业务清单,应该是对于一个公司业务全景图的梳理。我们有哪些业务,这些业务有什么能力,接下来他们要发展成什么样子。

目的主要是需要清楚知道自己能力输出后,对于业务的价值在于什么。而不是闷头进行能力建设。

这里需要有一个符合公司特色的业务全景图。

四、业务度量

业务的优先级是什么,我认为需要评估两点:

  • 每个业务的目标和KPI是什么:目标是否清晰可量化,在公司总体目标里面,他占据了什么比重。在接下来进行中台化支持的时候,可以用此作为优先级。
  • 业务的靠谱程度:也许每个业务提了很多需求,但是需求不是提完就结束的,产品需要做闭环就需要持续关注,比如支持了某个业务,他数据效果如何,好和不好的原因,这些也是评估业务的方式

五、能力发布

中台作为业务侧强大的炮火团,在技术上要求应该需要满足以下几点:

  • 丰富度:像产品一样,是可以逐步迭代的。不是一下子就是一个很丰富但没人用的中台,而是像滚轮子的方式,边做业务边做中台,只是需要有预判性的提前做一些内容
  • 质量:即使速度放慢,也需要对于质量有所保证,这个可能和一些流程上的要求密不可分。测试流程、发布流程、迭代流程
  • 可读性:除了接口的可读性,还需要对于接入文档有相关可读性,除了开发速度,怎么减少沟通成本和技术联调速度
  • 架构稳定性与规划:稳定性想指的在于架构上面的稳定性,可能中台建设后,由于接入业务方变多了,你的一点点小小改动,都会造成业务方接口的更换,所以架构上也需要保持相对的稳定性。

总结:做中台需要怎样的能力?

1. 业务架构/技术架构考虑

从技术的角度上,考虑到面的角度更多,怎么从架构的角度让代码更加优雅。从产品的角度上,不管是中台产品还是前台产品,也需要考虑到业务全景图,产品规划不是一个虚的东西,而是自己要知道至少半年,产品形态是什么。

对于产品来说,产品稳定性是一个很好地验证产品力的方式,像微信,这么多年那4个tab还是没怎么变过,可以支持到各种功能的叠加和承载。所以很多东西不是一个点,修改一下UI就解决的事情。

2. 作为一个桥梁

对于能力侧,如中台、企业IT等团队,对于产品或者业务负责人来说,需要有一个桥梁的作用,定期同步中台能力,与业务侧定期沟通他们后续一个规划,不要蒙头做能力。

对于业务来说产品是需要运营的,对于中台来说,其实也是需要运营的,需要和公司内部推广出去,更好的赋能业务。

3. 不要当工具人

如果不主动思考就会成为一个工具人,比如代码的搬运工、产品的抄袭者。除了做支持,更多的还需要往前再走一步,每一个产品/技术主要思考做什么事情可以对业务产生价值。

有了业务感觉的产品/开发/测试,可以更好的对业务说不。拒绝不合理的需求和临时方案,做更多有价值的事情。这一些其实是在于赋能的同时可以更往前走一步,反推动业务。

 

作者:周玥,微信公众号:粥dayday的脑细胞

本文由 @周玥  原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自Unsplash,基于CC0协议。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 公众号更名为:B端周玥

    回复