中小企业的业务中台构想、规划与设计( 二 )

本文插图

图系统架构对比
第三步：组织建设
那有了中台的建设目标，要不要建立一个中台组织呢。很多企业一开始就规划了一个业务中台，然后成立了对应的中台组织，用于完成中台产品的设计、开发和运维。中台团队很容易就陷入一个备胎定位，前台系统有什么脏活累活都会成为中台的锅，成了一个备用资源中心。但是我前面提到，对于小企业或者创业型企业来说，资源是有限的。所以笔者认为，以服务中心为基础，形成跨组织的项目团队，才是更好的方式。
原因有二：

一是，由于中台团队解决的是实际问题，所以能够得到业务和前端团队的有力支持；
二是，随着对应服务中心建设，能力会沉淀到相应的人员，这些人员也就成为服务中心OWNER ，随着服务中心的逐步建设，中台组织就慢慢自我形成和连接。

【中小企业的业务中台构想、规划与设计】

本文插图

图中台组织建设
第四步：服务梳理
一旦我们明确目标，以及有对应团队，就可以进入业务中心梳理，很多中台负责人遇到第一个问题就是：什么样的原则来划分服务中心？这里基于笔者的实践，我给出三条建议：
统一标准：这里说的统一标准，包括三个层面：

第一是业务标准，即通常我们说的业务流程的标准化，这需要抽象业务的时候进行分析，并对部分业务进行标准化处理，比如：整车的订单和备件订单，他们的物流状态本身是不同，这个时候就需要做一些标准化。
第二是技术标准，即不同的服务中心不管建设方是谁，必须是一套技术框架来进行，同时接口也必须统一；
第三是数据标准：包括元数据、维度等等。这三个标准越往后，难度越大，这也是为什么要基于业务问题出发，这样能够减少统一这三个标准的难度。

基于以上三个原则能够满足，则可以进一步通过MVP来验证。
MVP（最小化可行产品）：创业团队永远是基于MVP出发的，所以中台建设也不例外。尽管我们的中台建设是基于业务问题的，但程序猿都很容易陷入到追求全面和完美。中台关键是复用两个字，但是哪些能够复用呢，这需要基于业务问题出发去抽象。
整车订单和备件订单例子，如果要强硬去整合就会存在很多问题，因为整车订单的下订流程和备件订单差异很大，所以抽象成一个完整的订单中心把订单的下订、选配、拆单、物流、状态等以及正、逆向流程抽象化是非常困难。但是我们可以基于MVP ，想把订单状态标准化，作为订单状态中台，可以让其他系统订阅这个服务，从而解决订单状态统一维护问题。
价值优先：很多中台建设花费很多精力和成本，最终的却没有产生有价值的成果，甚至反而成为拖累。所以，建设中台必须要考虑结果。基于业务问题出发，梳理出来的中台建设方案，能不能解决业务问题。这里的结果，笔者强调必须是能够量化的，这个量化目标维度，既可以是业务维度，也可以是技术维度。以下就是笔者在进行支付中心建设时的目标：