编辑导读：区别于普通业务，中台能让系统更好地满足业务需求，提升系统效率，建设业务中台最直接的目的一般是为了帮助产品快速且低成本的提效。本文作者从自身工作实践出发，总结分享了如何建设业务中台，希望能够给你带来一定的启发。

本文主要记录为公司搭建业务中台的前期过程，由于摸着石头过河，如有不足之处，恳请指出。

一、发现问题，分析猜想

领导：“最近公司同事都反馈内部的多个系统很难用，操作效率低，你看怎么解决下呢？”

作者：“好的，我研究下，明天上午给您一个回复。”

和领导沟通后发现，随着公司业务线开拓，输出各种产品，后台需要不停的新增对前台的功能支撑，而功能需求有些大同小异，有些大相径庭，同事们需要登陆不同的后台处理不同的业务流程，甚至会碰到系统无法满足业务需求的情况。

因此，可以初步判断，这不仅是内部系统效率低下，更涉及对公司资源的浪费问题。而追本溯源，是业务线开拓，后台系统需要支撑各类服务导致的。于是，作者对公司的业务体系进行梳理。

1. 业务梳理

首先梳理公司当前的服务模式。

公司作为综合服务提供商，为各类客户提供数据、评价、咨询、科技以及培训服务，以下业务线为例：

“数据服务”、“评价体系”、“研究咨询”作为成熟度较高的业务线，涉及的部门及业务流程已经具有完整的闭环，而“资管科技”和“培训服务”有以下特征：

• 近年核心业务，产品推陈出新，迭代快、定制化需求极多；
• 多方领导重点照顾，后台部门必须积极响应这两条线的各种要求；
• 业务方向大相径庭，但都需要其他业务线的大量支撑；
• 产品形式多样，涉及PC、移动端、嵌入外部系统等方式；

于是，“罪魁祸首”找到了。接下来需要对业务线进行内部调研。

2. 业务调研

调研对象：两条业务线里涉及的部门业务人员，由于分身乏力而且只是初步了解，因此根据领导提供的反馈截图找对应同事沟通；

调研目的：了解业务流程上的问题、了解操作流程上的问题、了解运营流程上的问题；

可事先准备部分调研问题例如：

• “你们在操作过程中遇到了什么问题”
• “你在做什么事的时候感觉系统不能满足你们的业务流程”
• “你们当前运营重点是什么呢？”
• “系统是不是没有足够的数据支撑，哪些内容没有得到有效的处理”
•    ······

这部分由于时间关系，只是想初步了解同事们对当天业务流程的看法，顺便试图找出他们的真实诉求，如果想更调研具体，可灵活参考《产品汪的“野蛮生长”复盘（2）》（右键-新标签页打开）第二节“需求”里的“用户调研”。

同事们的反馈如下：

进而整理得到同事们的真实诉求：

• 定制化需求里复用率高的业务模块避免重复设计与开发，消耗人力；
• 报告的上传、审核、上线、分发进行统一，保证在一个系统上实现对所有内容的管理；
• 对各类产品统一管理客户信息（CRM系统）；
• 内部信息跨部门管理，实现文档的及时更新和传阅；
• 数据统计维度统一，避免不同系统出来的数据结果不一致；
• ······

结论：公司需要一个小型的业务中台

二、设计规划，小心论证

作者：“经过分析我发现这两条业务线产生了这些问题······，经过和大家的友好沟通，同事们的真实诉求是······，因此，我认为公司需要一个小型的业务中台，以提高同事工作效率，响应前台高频变化需求、降低后台人力成本、进而提升业务整体效率，应对两条业务线不断变化的发展需求。”

领导：“不错，可以写一份关于中台的规划方案，下周一可以吗？”

作者：“可以的”

为了规划中台，借用5W2H方法对两条业务线进行分析，得到中台的业务目标、业务流程以及业务迭代。

1. 业务目标

Who：梳理每条业务线的参与角色（从用户到运营，最后到技术支撑），这些角色将会是受到中台影响最直接的角色，后续的功能逻辑梳理也要围绕ta们进行；

When：业务线里产品的生命周期，中台的搭建需要即时应用到实际生产中，因此需要考虑产品的实际生命周期，以“逐步迭代、每个版本都能产生价值”作为中台建设节奏；

What：业务线里，前、中、后台涉及到哪些功能，主要找出具有共性的功能，这些功能往往就是复用率高的，优先加入中台搭建的功能；

2. 业务解析

Where：梳理出业务共通的功能，体现在复用性、业务逻辑一致性等；

Why：自问自答，为什么选择它纳入中台；

How：如果纳入中台，大概会以什么样的逻辑实现。可以结合流程参与角色画出业务流程图；

How Much：该功能的优先级评估；（图中是定性，也可以用定量的方法，即通过和以往的实现方式对比，人力成本节约了多少百分比）

通过业务解析，最终得到中台的功能框架，样例如下：

3. 业务迭代

关于版本规划，一方面除了“How Much”里的分析外，另一方面可以从以下4点考虑：

1. 保证“每次迭代都能为业务线创造价值”，即每个版本都能提供一个核心功能满足某个需求；
2. 避免过度设计，不想被蚊子叮，蚊帐即可；不想听蚊子声，蚊香/驱蚊液不香吗，别去练用筷子夹蚊子的功夫；
3. 暂时不去改动目前成熟且运转无误的业务流程，先解决问题，再考虑优化；
4. 同等优先级时，可考虑“用户高频使用的功能＞用户强烈要求的功能＞支持业务生产的功能＞内部同事期望解决的功能”

三、集体沟通，细化需求

作者：“领导，这是业务中台的初步规划，一共涉及了2条业务线，涉及的部门和角色分别是······，对应的中台功能架构是······，之所以这么设计是因为······，目前规划的优先级是······”
领导：“我找时间协调下部门相关业务负责人，你给他们讲讲”

与各个业务线涉及的部门沟通中台方案，需要解决战略讲解、认知统一、业务边界等细节问题，以便快速无误地进入项目启动阶段。

1. 战略讲解

主要讲解中台和公司战略的紧密程度和对业务线的有利，让各个领导达成共识。

其次确定中台目标，不是做阿里那种以电商为核心的共性业务中台，也不是做滴滴那种围绕打车业务延展的复用业务中台，而是做契合公司本身业务发展的中台。

最后阐述中台主要涉及的业务线，需要对应部门提供人力支持。

2. 认知统一

• 大家对当前业务线和对应产品的目标认知统一；
• 业务概念、指标定义、系统规则、数据规则的认知统一；
• 业务标准执行流程上的认知统一；

3. 业务边界

主要基于中台功能架构，把每个功能的流程与参与角色的实际操作进行对比，确定中台业务边界，避免过度开发、错误开发和无用开发。

总结

和其他业务线的团队沟通并细化需求后，基本上就进入正常的项目阶段，后续流程可参考《产品汪的“野蛮生长”复盘（2）》。

期间其实也碰到不少问题，例如：

1. 项目开发团队是从其他开发中的项目抽调的人员，导致中台搭建时，开发人员的理解更倾向原本业务，无法一碗水端平；
2. 花了很多时间在给项目团队讲解各个业务流程，需要持续的把控进度，避免开发跑偏；
3. 由于有部分产品已经开发完成投入使用，中台搭建的同事，需要同步调整往期产品的部分内容，开发成本远超预期；
4. 需要持续的投入维护和迭代，以便跟上整体业务线进度，让本就秃头的开发同事雪上加霜；

而最终效果很明显，定制化产品的开发周期普遍缩短了、内部运营效率提升了，技术同事拍头叫好，运营同事喜极而泣，市场同事老来欣慰，而我也激动地记录下这次搭建流程，抛砖引玉，希望对大家有所帮助。

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

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