案例复盘：从0搭建业务中台

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

一、发现问题，分析猜想

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

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

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

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

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. 需要持续的投入维护和迭代，以便跟上整体业务线进度，让本就秃头的开发同事雪上加霜；

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

本文作者 @汐_

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！