中台产品经理实战（6）：业务边界的划定

一、中台业务边界的划定是干什么？

在前面的中台实战章节中，我们先后谈过了中台的概念、中台产品设计的核心思路模块化设计、数据剥离思路，在学习了这些中台的“屠龙”技术之后，距离我们真正去进行中台建设还有一个很重要的问题，就是我们要如何识别各个业务线中的功能是否都为需要中台化的部分？

比如说我们在某个业务线中新推出了付费会员体系，那么我们如何判断是否要把这一模块进行通用化，进行中台化呢？可能你会说付费会员体系属于变现的基础功能肯定要进行中台化啊，这是由于我举的这个例子比较直观，所以我们能快速地判断出。

但是如果在看一些不是很直观的模块：地址标签、会员个性化头像，你觉得还要中台化吗？是不是我们就需要分别进行论证了？

中台也是一个软件产品，因此整个建设流程和我们的一般性产品设计一样，可以很粗略分为如下4步：

用设计一般化产品的环节来说，前面我们一直在学如何进行需求分析，甚至提到了一部分的中台项目管理，而本章我们其实就是要去探讨中台的需求范围如何定义。而在中台的建设历程里我们又称之为中台业务边界的划定。

这个问题本质上有两个核心难关：

• 需要我们中台的产品经理能判断出该流程是否为整个公司的核心业务的标准环节，也就是80%的业务日常都会触达这些个节点；
• 在企业下一步战略中上一步的分析结果是否还为整个公司的核心业务的标准环节。

为什么要这么做呢？

我们知道中台也是一个软件系统，而软件系统的最大优势就是低边际成本。就拿一个OA软件的单次开发成本来说，它的在研发阶段的资本投入很大，为一个人开发出来需要交34万元，但是一旦它投入大批量的生产，它的信息复制成本几乎为零，10个人34万元人均3.4万元，100万个人用呢？每人的成本可以低到不计了。我们也就可以近似看到边际成本几乎为零。

同样的作为承载着企业效率提升的中台，如果设计出的模块被各个业务线都没有进行服用的话，那么这个中台首先就是设计失败的，其次这些模块设计的成本也就变得非常高，所以我们必须要清楚的知道，划归到中台内部开发的模块必须是企业中各个业务线高频的业务服务，只有这样我们将它沉淀到中台中，才会为各个业务线的研发带来效率提升。

二、企业业务SOP梳理

因此我们在中台需求边界的梳理过程中，第一步就是要进行业务流程标准化，这里也有一个专用名词，称之为企业业务SOP，也就是我们要去梳理企业业务SOP。

梳理前，首先让我们先搞懂SOP是什么？

先来看下定义，所谓SOP就是 Standard Operating Procedure三个单词中首字母的大写 ，即标准作业程序，指将某一事件的标准操作步骤和要求以统一的格式描述出来，用于指导和规范日常的工作。

通俗来讲SOP就是对某一程序中的关键控制点进行细化和量化。从管理学的角度,标准作业程序能够缩短新进人员面对不熟练且复杂的事务所花的学习时间,只要按照步骤指示就能避免失误与疏忽。

在正常每个公司中，每个固定环节我们都会有一些SOP，最经典的就是我们进行活动运营制定的那一套模板，而中台产品经理要做的就是将整个公司业务的SOP梳理出来。

那么怎么发现SOP呢？具体来说我们分为两步得到整个公司级的SOP。

要梳理SOP就不得不先谈两个概念：

• 每个业务线中的现有日常流程，我们称之为工作流；
• 服务/产品的作业流程中产生的信息流转，我们称之为信息流；

也就是说SOP在实际工作中​我们可以这样去理解：

SOP = 工作流 + 信息流

我们以电商商品中心为例子来看看怎么去梳理出一个SOP：

（1）工作流：日常工作的节点获取

这一步我们的得到了日常操作的每一个重要阶段是什么，也就是关键业务活动。接下来我们要去梳理每一个业务活动中有哪些信息流。

（2）信息流：信息流转的节点获取

如上我们得到的就是一个完整的信息流，这两部合并起来我们就将抽象的业务活动定义为标准的信息流程，我们可以清楚看到业务线是如何实现商品管理的。

当我们将不同事业线中的信息流与工作流都梳理出来后，我们就可以统一来看哪些部分是各个业务线都重叠的，从而提取到中台来。

三、公司级战略评估

在前面我带大家完成了业务线内部的关键节点拆分与定义，总结出了各业务线的SOP，但是前面的方法主要是在模块内部拆分还不够全面，接下来我们要上升一个维度进入业务线间的抽象，去评估这些SOP哪些是符合当前公司战略走向的。

具体来说我们的评估维度整体范围如下表所示：

在这个层级的分析我们重点是要：

找到企业的问题域 -> 再定义解决能力

每个软件系统都有自身立项的原因，就拿我所经历的中台业务来说，当时我们的数据中台推动原因：

在我们准备引入第三轮Pre A投资时，也就是Ts签完（投资意向书），但是资本方给了个问题我们如何证明我们的商业模式是成立的，作为一家电商企业在规模增长融资阶段，我们定义了以GMV与复购率作为商业模式验证指标，最终就这个问题我们签定了对赌协议并约定了这两个核心指标的在2年内的增长目标。

所以这个时候我们整个公司对于数据需求就很明确了，也就是找到了我们的问题域：

• 如何定义下一步运营战略；
• 如何精准获客；
• 如何推动用户复购；
• 现有用户交易情况跟踪。

我们也找到了现在与未来的企业发展方向，此时就可以对上一步得到的SOP进行一个再次评价，哪些是公司当前战略所需要的，将其归类到中台需求范围中，至此我们整个中台业务需求边界就可以说梳理完了。

四、拓展

这里稍微拓展下，其实这里的两个分析我们已经悄悄的得出了业务流程架构，没错业务流程架构本质就是业务线流程+企业战略两个部分，我将上面的案例稍微的拓展下：

怎么样？不知不觉我们产品经理实际已经完成了一个企业架构的设计，所以大家看看产品经理是企业CEO学前班这句话还真不是骗人的。

PS：你的收藏、点赞就是对我最大的支持！

#相关阅读#

中台实战（0）：最近处处惹人爱的中台到底是什么

中台实战（1）：看懂企业业务演进路线

中台实战（2）：中台的建设核心原则

中台实战（3）：数据中心中台化案例

中台实战（4）：业务的抽象建模

中台实战（5）：数据指标体系创建思维

#作者#

三爷，微信公众号：三爷茶馆。曾万达高级产品、MBA特约讲师、独立创业者，现某支付公司产品线负责人，拥有多款集团项目从零到一经验并带领实现商业化布局。

本文

版权声明

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