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

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

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

总体概述

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

中台建设方法论流程图：

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

一、能力地图

1. SOP流程

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

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

举例，比如对于一个电商下单流程一般是这样的（做了删减）：

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

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

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

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

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

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

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

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

二、 需求结构化

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

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

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

三、业务全景图

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

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

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

四、业务度量

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

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

五、能力发布

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

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

总结：做中台需要怎样的能力？

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

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

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

2. 作为一个桥梁

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

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

3. 不要当工具人

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

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

作者：周玥，微信公众号：粥dayday的脑细胞

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

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