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

目前行业关于中台建设的文章随着热度已经非常多了，尤其是阿里、Thoughtworks、云徒等都拿出自己的理论体系和实践方法。这些理论给行业带了明灯，使得中台建设有一个清晰方法论。

笔者总结目前这些方法论，主要集中在大企业的实践，很多也是基于EA架构建设方法论的进一步延展和创新。比如王健老师的D4模型，融入设计思维，融入DDD领域驱动设计。

D4模型将中台规划方法论分为4个步骤：

1. 企业战略分析和调研（Discovery）；
2. 企业数字化全景规划（Define）；
3. 中台的规划与设计（Design）；
4. 中台的建设与接入（Delivery）。

图  王建老师的4D模型

笔者所处的企业是一家从0-1的中小型互联网汽车企业。对于中小企业，尤其0-1的企业，并不适合完整的进行企业战略分解、自上而下调研和分析、然后进行企业架构设计、然后再进行详细的规划和计划。 因为中小企业面临市场变化很快，资源有限，必须快速调整战略和业务，如果经过复杂而又冗长的系列至上而下的讨论和规划，得出来后的方案，已经不适应新的市场了。

经过笔者实践总结，有以下几步：

第一步：模式识别

首先，作为企业的负责人需要清晰认识自己商业模式，清楚自己的用户，不能一上来想到的就是如何数字化转型、如何构筑中台。

中台适用的场景是什么？

根据王健老师的定义企业级能力复用平台，也就是说企业的模式是前提。最近笔者也接到很多大型装备制造业数字化转型以及建设中台的咨询，但笔者认为对于大型装备制造业的数字化转型应该有自己的侧重点，比如智能制造，而不一定非要加上一个中台的概念。中台本身来自阿里的电商，面向的是激烈竞争下的流量时代，所以“以用户为中心”的企业更加适合。

第二步：问题诊断

笔者实践中认为，从问题出发，快速解决业务问题，然后再逐步连接起来和归纳出来，更适合小企业的中台建设。

首先，可以通过鱼骨图等问题分析工具，分析目前存在的业务难点；

图  问题诊断示例

比如图中笔者的团队在建设中就发现，前端有各种结算和支付场景，在自有APP、电商 、线下体验店系统及第三方电商渠道，都有自己的结算和支付需求。

由于各系统都对应开发了结算和支付功能：

1. 各系统重复开发，尤其是结算逻辑复杂情况下，开发成本就会增加；
2. 一旦计算的逻辑和支付功能修改，就需要同步给各系统，并逐个验证；
3. 业务方由于不同系统都要操作一遍，造成他们非常的抱怨，且很容易由于人工配置的疏忽导致结算结果不一致的情况。

这就是一个很典型的业务问题，基于这样一个业务问题，我们规划了结算和支付中心，为前端各场景系统提供API。这样各系统结算和支付时，通过调用结算和支付中心，将总价、折扣、积分、支付渠道等输入给结算和支付中心，结算和支付中心完成结算和支付并返回结果。这样则只需要维护一个结算和支付中心即可，不仅开发量大大减少，同时业务也仅需要在一个地方配置结算和支付逻辑，且能够保证一致性。

根据不同业务问题，逐步完善中台建设；如果一开始就有一个宏大规划，不仅仅难以落地，而且由于见效慢，很难得到业务和领导的支持。

图  系统架构对比

第三步：组织建设

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

原因有二：

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

图   中台组织建设

第四步：服务梳理

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

统一标准：这里说的统一标准，包括三个层面：

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

基于以上三个原则能够满足，则可以进一步通过MVP来验证。

MVP（最小化可行产品）：创业团队永远是基于MVP出发的，所以中台建设也不例外。尽管我们的中台建设是基于业务问题的，但程序猿都很容易陷入到追求全面和完美。 中台关键是复用两个字，但是哪些能够复用呢，这需要基于业务问题出发去抽象。

整车订单和备件订单例子，如果要强硬去整合就会存在很多问题，因为整车订单的下订流程和备件订单差异很大，所以抽象成一个完整的订单中心把订单的下订、选配、拆单、物流、状态等以及正、逆向流程抽象化是非常困难。但是我们可以基于MVP，想把订单状态标准化，作为订单状态中台，可以让其他系统订阅这个服务，从而解决订单状态统一维护问题。

价值优先：很多中台建设花费很多精力和成本，最终的却没有产生有价值的成果，甚至反而成为拖累。所以，建设中台必须要考虑结果。基于业务问题出发，梳理出来的中台建设方案，能不能解决业务问题。这里的结果，笔者强调必须是能够量化的，这个量化目标维度，既可以是业务维度，也可以是技术维度。以下就是笔者在进行支付中心建设时的目标：

图   目标看板

总结

（1）一般行业内的做法是在EA框架的基础上进一步优化和创新。

（2）中小企业应该通过模式识别、问题诊断、组织建设、服务梳理4步完成业务中台构想、规划与设计。