编辑导语：在你对中台有了具体的了解之后，你也需要对中台的产品规划有自己的想法，这样才能更好的工作。笔者结合一些案例，从四个方面进行分析，希望大家能从更广阔的角度对中国台湾的规划有更深入的了解。 　　

　　之前我们用一篇文章介绍了中国台湾，让我们对中国台湾有了非常具体的了解。今天，我们继续讨论中国大陆和台湾的产品规划理念。 　　

　　前面我们说过，不管你负责哪个中间站，都要对这个模块中中间站对应的业务有很好的了解。所以，这篇文章的前提是，如果你来了中办，默认就知道业务。 　　

　　文章框架如下： 　　

　　1.从行业层面梳理业务方向 　　

　　2.从公司层面梳理产品边界 　　

　　3.站在中层，梳理中层的能力。 　　

　　4.从数据流的角度梳理依赖关系 　　

　　今天的文章有很多概念和抽象，结合一些案例，希望大家能从更广阔的角度去理解中国台湾的规划。 　　

　　#一、从行业层面梳理业务方向。 　　

　　从行业层面梳理业务方向的目的，就是要能从业务产品端了解他们在做什么产品，市场的切入点是什么，未来他们会为什么用户做什么功能。这样，作为一个中间站，我们可以清楚地知道我们服务的是什么产品，他们的核心竞争力是什么。有利于中台产品提前界定中台能力边界，也有利于推出业绩。作为中台产品，我们应该为业务端研发提供什么样的服务，才能更好地满足业务在功能拓展方面的需求，拥有更强更广的能力？ 　　

　　产品定位和功能梳理已经有了成熟的方法论。这个详细的知识点在很多书籍和文章中都有描述，在中国台湾的规划中是无法大篇幅介绍的。写多了会以主人自居，这里就不细说了。 　　

　　但是，我必须强调，拥有行业意识是中台产品最必备的技能，不是一两天就能完成的。需要入驻一个行业，不断探索这个行业应该怎么做、怎么切入、怎么赚钱，为这个产品在行业内的发展探索一条道路。这条路不一定是对的，但至少是清晰的、有方向的。它可以让人们一句话就知道它在做什么，值得探索。 　　

　　比如我深入探索了社交电商行业。最后，我认为这个行业是通过经销商销售我们自己公司的产品。那么，在我们产品方向之初，分销员工的家具产品就足够了。这个工具产品侧重于如何通过分销商与客户打交道，然后可以衍生出很多相关的功能，让中台的原型更加生动。 　　

　　# 2.从公司层面梳理产品边界 　　

　　为什么在公司层面梳理产品边界也是规划中办非常重要的前提？因为在第一次介绍中办的时候，我们说每个公司会因为自身业务范围的业务复杂程度不同，以及组织架构的平衡等原因，将不同的业务划分为不同的模块，中办的划分也是如此。 　　

　　一般来说，核心交易流程的边界是比较清晰的，因为核心交易流程在市场上是成熟的，大家都完全知道怎么做，所以一般会分为业务中心、商品中心、交易中心、订单中心、绩效中心、售后中心、促销中心等等。但现阶段一些创新性或价值较低的中间站的划分，会受到组织结构和产品规划的很大影响，如配送中间站(销售中间站)、评价中间站。 　　

　　如果以业务员为媒介的销售流程管理工具和从商家角度进行客户管理的CRM的业务产品线属于同一个部门，用户会员中办会和销售中办合并吗？两者在能力上有很多重叠和相似之处，只能区分用户角色。 　　

　　如果商品评价是产品相关业务线学生做业务成长的重要模块和重要工具，评价中心会不会被商品中心拿走，而不是被商家中心砍掉？这是因为公司注重不同部门的业务，自身小团队的利益是平衡的。 　　

　　对于基于saas的产品，产品评价可能在很长一段时间内无法发挥应有的商业价值，因此评价中心可能会被忽视，最终会承担起工具库的角色。 　　

　　#三。从中国和台湾的层面梳理中国和台湾的能力领域。 　　

　　在我们参与具体的功能之前，我们要理清中间办公室的能力边界。目的是要有一个清晰的思路，对产品架构有一个直观的、结构化的认识，从框架层面看中办应该如何拆分和运营。先有框架再有细节也是常见的工作方法。 　　

　　梳理哪些能力域由中办构成，每个能力域拥有哪些核心能力，并不是一个简单的过程，因为每个中办都有不同的特点和不同的产品方案。但是，我们可以尝试通过梳理对象、目标和流程节点三个要素来梳理业务功能，划分中层能力域。但无论什么方法论，熟能生巧。有时候，有些人可能不需要任何方法论。只要看看菜单，你就可能知道如何划分中间站。 　　

　　先试试对象、目标、过程节点三要素结合的方法。 　　

　　对象：在业务端完整的业务闭环中，这些功能主要服务于哪些角色、哪些人。 　　

　　目标：服务对象希望在这个系统功能中实现什么目标，然后这个大目标是否可以分解成几个小目标？ 　　

　　流程节点：服务对象要完成一个关键目标，我们把一个关键目标拆分成几个小目标之后，每个小目标需要哪些流程节点？ 　　

　　这样，对于我们来说，围绕一个服务对象和作为节点的每个小目标来关闭流程就是一个领域。 　　

　　我们试着拆解并列出以上三个要素。 　　

　　像往常一样，给我举个例子 　　

前面一篇中台入门的文章里我们介绍过，销售中台是为：服务于销售员的，为不同销售主体下，以销售员为主要服务对象的销售过程管理工具，提供销售员入离职管理、线索分配与回收、线索营销触达、销售工具与资源分配、考核任务与目标创建、考核结果计算等的通用能力的中台。

服务对象：销售员。

目标：销售员的目标是通过系统成交客户，并依拒系统计算自己的成交记录，以自己获得提成奖励最终赚到钱为最大目标。

流程节点：录入或申请成为销售员-审核-获得销售员账号-邀请客户-推荐产品成交客户-计算业绩-计算提成奖励-获得提成奖励

我们把整个流程节点拆解下来，我们发现我们可以把整个流程分解为多个阶段小目标，然后这些阶段小目标可以有各自的流程节点闭环。

这样我们就把这个销售员赚钱的整个流程拆解成了三个小目标，我们再把这三个小目标的各自闭环起一个领域名字就可以了，这就是我第一篇文章中的一幅图：

当面对不同业务方时，可以再将领域的描述业务化，以便于业务方理解。

在这个环节我们要注意的是，我们拆解出来的流程节点并不一定都是在我们的中台实现的，比如签订合同和发放提成奖励，签订合同对于电商来说就是订单交易流程，这里势必是会独立到订单交易中台中去，发放提成奖励可能就是在其他与账单相关的中台，但是这并不影响各自中台的领域能力，只要处理好系统交互即可。

# 四、从数据流角度梳理依赖关系

先划分好能力域之后，就要梳理好各个能力域之间的数据流，也就是依然从业务角度，梳理用户完成一个主要目标的完整数据流程，进而整理出系统依赖关系。

梳理数据流和系统依赖关系的主要目的，我们可以除了基于第 3

点的功能层面梳理出来的能力外，还能够在数据流和系统依赖关系中，看到我们可以抽象出来的其他能力，这样我们的中台才能更加完整，我们可以从产品层面搭建一个完善的中台产品架构，技术也就能基于产品的梳理，完善自己的技术架构。

因为我们已经划分完能力领域了，在划分好的领域基础上再去梳理数据流就会更加得心应手。

梳理数据流依然是基于领域划分的流程节点，我们需要知道要完成每个流程节点，需要哪些数据，这些数据来自于哪里，在各自的领域内又是经过了什么处理，然后给到了哪个领域去。

老规矩还是举个例子，以销售中台任务业绩域的数据流为例，任务和业绩的考核本质上是在对于销售员相关的数据，按照任务业绩域的功能设定的逻辑进行数据运算，那么我们就把所有我们需要的数据沉淀到中台，并根据我们的能力生成数据聚合的模板，进而根据模板进行数据运算即可。

并且我们发现，在其他领域，比如销售员域，在计算销售员等级的时候，也是需要很多条件型数据的，那么这些领域也可以使用我们的数据聚合模板。

基于这个发现，我们再探索一下其他领域，也就发现，很多领域都可以利用我们的数据聚合模板，这样我们就梳理出了完整的带数据流和处理方案的产品架构图。

至此一个中台规划的入门就说完了，下一步我们讲解一下，如何落地去做一个中台的需求，如何把业务的需求用中台语言翻译给中台的研发。

但是对于本篇总结的内容来说，我现在写总结，我是站在过来人的角度，看起来仿佛一切都是成立的都是简单的，但是当你初入中台的时候，还是会经过一段痛苦磨砺的过程，希望切入中台的同学都能够顺利进入自己的角色，在产品的道路上打怪升级，成就自己的产品梦。

作者：初愚，公众号：产品杂谈录

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

题图来自 Unsplash，基于CC0协议