案例复盘从0搭建业务中台Word文档格式.docx

案例复盘从0搭建业务中台Word文档格式.docx

《案例复盘从0搭建业务中台Word文档格式.docx》由会员分享，可在线阅读，更多相关《案例复盘从0搭建业务中台Word文档格式.docx（6页珍藏版）》请在冰豆网上搜索。

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

因此，可以初步判断，这不仅是内部系统效率低下，更涉及对公司资源的浪费问题。

而追本溯源，是业务线开拓，后台系统需要支撑各类服务导致的。

于是，作者对公司的业务体系进行梳理。

1.业务梳理

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

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

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

∙近年核心业务，产品推陈出新，迭代快、定制化需求极多；

∙多方领导重点照顾，后台部门必须积极响应这两条线的各种要求；

∙业务方向大相径庭，但都需要其他业务线的大量支撑；

∙产品形式多样，涉及PC、移动端、嵌入外部系统等方式；

于是，“罪魁祸首”找到了。

接下来需要对业务线进行内部调研。

2.业务调研

调研对象：

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

调研目的：

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

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

∙“你们在操作过程中遇到了什么问题”

∙“你在做什么事的时候感觉系统不能满足你们的业务流程”

∙“你们当前运营重点是什么呢？

∙“系统是不是没有足够的数据支撑，哪些内容没有得到有效的处理”

∙ 

·

这部分由于时间关系，只是想初步了解同事们对当天业务流程的看法，顺便试图找出他们的真实诉求，如果想更调研具体，可灵活参考《产品汪的“野蛮生长”复盘

（2）》（右键-新标签页打开）第二节“需求”里的“用户调研”。

同事们的反馈如下：

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

∙定制化需求里复用率高的业务模块避免重复设计与开发，消耗人力；

∙报告的上传、审核、上线、分发进行统一，保证在一个系统上实现对所有内容的管理；

∙对各类产品统一管理客户信息（CRM系统）；

∙内部信息跨部门管理，实现文档的及时更新和传阅；

∙数据统计维度统一，避免不同系统出来的数据结果不一致；

∙·

结论：

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

二、设计规划，小心论证

“经过分析我发现这两条业务线产生了这些问题·

，经过和大家的友好沟通，同事们的真实诉求是·

，因此，我认为公司需要一个小型的业务中台，以提高同事工作效率，响应前台高频变化需求、降低后台人力成本、进而提升业务整体效率，应对两条业务线不断变化的发展需求。

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

“可以的”

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

1.业务目标

Who：

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

When：

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

What：

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

2.业务解析

Where：

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

Why：

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

How：

如果纳入中台，大概会以什么样的逻辑实现。

可以结合流程参与角色画出业务流程图；

HowMuch：

该功能的优先级评估；

（图中是定性，也可以用定量的方法，即通过和以往的实现方式对比，人力成本节约了多少百分比）

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

3.业务迭代

关于版本规划，一方面除了“How 

Much”里的分析外，另一方面可以从以下4点考虑：

1.保证“每次迭代都能为业务线创造价值”，即每个版本都能提供一个核心功能满足某个需求；

2.避免过度设计，不想被蚊子叮，蚊帐即可；

不想听蚊子声，蚊香/驱蚊液不香吗，别去练用筷子夹蚊子的功夫；

3.暂时不去改动目前成熟且运转无误的业务流程，先解决问题，再考虑优化；

4.同等优先级时，可考虑“用户高频使用的功能＞用户强烈要求的功能＞支持业务生产的功能＞内部同事期望解决的功能”

三、集体沟通，细化需求

“领导，这是业务中台的初步规划，一共涉及了2条业务线，涉及的部门和角色分别是·

，对应的中台功能架构是·

，之所以这么设计是因为·

，目前规划的优先级是·

“我找时间协调下部门相关业务负责人，你给他们讲讲”

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

1.战略讲解

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

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

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

2.认知统一

∙大家对当前业务线和对应产品的目标认知统一；

∙业务概念、指标定义、系统规则、数据规则的认知统一；

∙业务标准执行流程上的认知统一；

3.业务边界

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

总结

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

（2）》。

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

1.项目开发团队是从其他开发中的项目抽调的人员，导致中台搭建时，开发人员的理解更倾向原本业务，无法一碗水端平；

2.花了很多时间在给项目团队讲解各个业务流程，需要持续的把控进度，避免开发跑偏；

3.由于有部分产品已经开发完成投入使用，中台搭建的同事，需要同步调整往期产品的部分内容，开发成本远超预期；

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

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