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

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

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

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

  通过上面的流程图，就可以抽取出，如果要做一个支撑电商的中台，在大多数情况下要的中心层会包含商品中心、营销中心、交易中心等等

  通过SOP流程的梳理，可以更好地知道业务的边界在哪里，同时对于中台来说流程梳理下来，将共用的能力就能够直接进行抽象，依据业务优先级，进行中台化的沉淀。

  中台产品与B端产品类似的点在于很多时候是为企业服务的，所以标准SOP流程，可以规范企业的一些做法，有时候做系统并不是单纯的做系统，更多要站在组织的角度考虑

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

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

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

  所以中台建设的初期，不能用业务接入速度去衡量，但是建设相对稳健一段时间后，就能够准确的看出成效。

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

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

  像产品一样，是可以逐步迭代的。不是一下子就是一个很丰富但没人用的中台，而是像滚轮子的方式，边做业务边做中台，只要有预判性的提前做一些内容

  即使速度放慢，也需要对于质量有所保证，这个可能和一些流程上的要求密不可分。测试流程、发布流程、迭代流程

  除了接口的可读性，还需要对于接入文档有相关可读性，除了开发速度，怎么减少沟通成本和技术联调速度

  稳定性想指的在于架构上面的稳定性，可能中台建设后，由于接入业务方变多了，你的一点点小小改动，都会造成业务方接口的更换，所以架构上也需要保持相对的稳定性。