2022-01-17 15:42:42
阅读 1081
前面我们用一篇文章介绍了中台，让大家对中台有了一个非常具象的认知。今天再接上篇，讲一下中台产品规划的思路。
前面我们说过，不管你负责哪个中台，一定要很懂这个模块中台对应的业务。所以这篇文章的前提是，你来做中台默认你懂业务。
文章框架如下：
- 站在行业层面梳理业务方向
- 站在公司层面梳理产品边界
- 站在中台层面梳理中台能力
- 从数据流角度梳理依赖关系
今天这篇文章有很多概念和抽象的东西，再结合了一些案例，希望大家从更广的视野上对中台的规划有所了解。
一、站在行业层面梳理业务方向
站在行业层面梳理业务方向的目的是，我们要能够知道，站在业务产品侧，他们做的到底是个什么产品，在市场上的切入点是什么，未来会对什么样的用户做什么样的功能。这样我们作为中台就很清楚的知道我们服务的是什么产品，他们的核心竞争力是什么。有利于中台产品事先明确中台能力的边界，也能够推演出，我们作为中台应该提供什么样的服务给业务侧产研，在功能扩展性上做到更贴合业务诉求，能力更强更广。
业务产品定位和功能梳理已经有比较成熟的方法论，这块的详细知识点在很多书和文章里都有讲过，不能放在中台规划中做大篇幅介绍，写多了就喧宾夺主，我这里就不过多赘述。
但是我一定要强调的是，具备行业认知，是一个中台产品最应该具备的技能，不是一天两天就能修炼完成的，需要在一个行业沉淀并持续探索行业该如何做该怎么切入该怎么赚钱，并且探索出一条本产品在行业上发展的路径来，这个路径不一定对，但是至少是清晰的，有方向的，能够一句话让人知道是做什么的，能够值得去探索的。
比如我深入探索的社交电商行业，最后我认为这个行业就是以分销员为媒介销售自己公司的产品，那么我们的产品方向初期就是个分销员工具产品就可以了，这个工具产品围绕的就是如何通过分销员成交客户，进而可以衍生出很多相关功能，这样中台的雏形也就比较形象了。
二、站在公司层面梳理产品边界
为什么现在公司层面梳理产品边界也是一个很重要的做中台规划的前提呢，因为在前面第一篇中台入门中我们说到，每个公司会因为自己的业务范围业务复杂度不同，再加上权衡组织架构等原因，将不同的业务分成不同的模块，同样中台的划分也是如此。
一般核心交易流程的划分边界都是比较清晰的，因为核心交易流程市场上已经很成熟，大家完全知道该怎么做，所以一般一定会划分为商家中台，商品中台，交易中台，订单中台，履约中台，售后中台，营促销中台等。但是一些创新性的或者当前阶段没太发挥出价值的中台的划分就会受组织架构和产品规划影响较大，比如分销中台（销售中台）和评价中台。
如果以销售员为媒介的销售过程管理工具和以商家视角进行客户管理的CRM的业务产品线归属于同一个部门，那么用户会员中台会不会和销售中台合并？从能力上他们有很多重合和相似，只是用户角色加以区分即可。
如果商品评价是一个重要模块，是商品相关业务线产品同学做业务增长的重要利器，那评价中台会不会被商品中台拿去做，而不是被商家中台切走？这都是因为公司内部对不同板块的业务重视程度，自己各个小团队之间利益平衡的结果。
对于 saas 型产品来说，商品评价可能在很长一段时间都无法发挥出应有的业务价值，那么评价中台可能就会被忽视，最终就是承担了一个工具的底座的角色。
三、站在中台层面梳理中台能力领域
我们在没有介入到具体功能之前去梳理中台能力边界，目的是要做到心中有数，能够有个形象化的结构化的产品架构认知，从框架层面看到中台应该如何拆分如何运行，先有框架再落细节也是常用的工作方法。
梳理中台都由哪些能力域构成，每个能力域有哪些核心能力并不是一个简单的过程，因为每个中台特性不同，产品方案也不同。但是我们可以尝试用对象、目标、流程节点的三要素梳理方法，来梳理业务功能并分割中台能力域。但是无论是什么方法论，都是熟能生巧，有时候有些人可能不需要任何方法论，只要看一下功能表就大概知道这个中台应该如何划分。
我们还是先来尝试一下对象、目标、流程节点的三要素梳理方法。
对象：在业务侧整个完整的业务闭环中，这些功能主要服务于哪些角色，哪些人。
目标：服务的对象希望在这个系统功能上，希望达成什么目标，然后这个大目标是否可以拆解成几个小目标。
流程节点：服务对象要完成某个关键目标，并且我们把一个关键目标拆解为多个小目标后，各个小目标各自需要的流程节点是什么。
这样我们就以围绕一个服务对象，以每小目标为节点进行流程闭环的，就是一个领域了。
我们尝试将上面的三元素进行拆解罗列
还是老规矩，举个例子，比如销售中台。
前面一篇中台入门的文章里我们介绍过，销售中台是为：服务于销售员的，为不同销售主体下，以销售员为主要服务对象的销售过程管理工具，提供销售员入离职管理、线索分配与回收、线索营销触达、销售工具与资源分配、考核任务与目标创建、考核结果计算等的通用能力的中台。
服务对象：销售员。
目标：销售员的目标是通过系统成交客户，并依拒系统计算自己的成交记录，以自己获得提成奖励最终赚到钱为最大目标。
流程节点：录入或申请成为销售员-审核-获得销售员账号-邀请客户-推荐产品成交客户-计算业绩-计算提成奖励-获得提成奖励
我们把整个流程节点拆解下来，我们发现我们可以把整个流程分解为多个阶段小目标，然后这些阶段小目标可以有各自的流程节点闭环。
这样我们就把这个销售员赚钱的整个流程拆解成了三个小目标，我们再把这三个小目标的各自闭环起一个领域名字就可以了，这就是我第一篇文章中的一幅图：
当面对不同业务方时，可以再将领域的描述业务化，以便于业务方理解。
在这个环节我们要注意的是，我们拆解出来的流程节点并不一定都是在我们的中台实现的，比如签订合同和发放提成奖励，签订合同对于电商来说就是订单交易流程，这里势必是会独立到订单交易中台中去，发放提成奖励可能就是在其他与账单相关的中台，但是这并不影响各自中台的领域能力，只要处理好系统交互即可。
四、从数据流角度梳理依赖关系
先划分好能力域之后，就要梳理好各个能力域之间的数据流，也就是依然从业务角度，梳理用户完成一个主要目标的完整数据流程，进而整理出系统依赖关系。
梳理数据流和系统依赖关系的主要目的，我们可以除了基于第 3 点的功能层面梳理出来的能力外，还能够在数据流和系统依赖关系中，看到我们可以抽象出来的其他能力，这样我们的中台才能更加完整，我们可以从产品层面搭建一个完善的中台产品架构，技术也就能基于产品的梳理，完善自己的技术架构。
因为我们已经划分完能力领域了，在划分好的领域基础上再去梳理数据流就会更加得心应手。
梳理数据流依然是基于领域划分的流程节点，我们需要知道要完成每个流程节点，需要哪些数据，这些数据来自于哪里，在各自的领域内又是经过了什么处理，然后给到了哪个领域去。
老规矩还是举个例子，以销售中台任务业绩域的数据流为例，任务和业绩的考核本质上是在对于销售员相关的数据，按照任务业绩域的功能设定的逻辑进行数据运算，那么我们就把所有我们需要的数据沉淀到中台，并根据我们的能力生成数据聚合的模板，进而根据模板进行数据运算即可。
并且我们发现，在其他领域，比如销售员域，在计算销售员等级的时候，也是需要很多条件型数据的，那么这些领域也可以使用我们的数据聚合模板。
基于这个发现，我们再探索一下其他领域，也就发现，很多领域都可以利用我们的数据聚合模板，这样我们就梳理出了完整的带数据流和处理方案的产品架构图。
至此一个中台规划的入门就说完了，下一步我们讲解一下，如何落地去做一个中台的需求，如何把业务的需求用中台语言翻译给中台的研发。
但是对于本篇总结的内容来说，我现在写总结，我是站在过来人的角度，看起来仿佛一切都是成立的都是简单的，但是当你初入中台的时候，还是会经过一段痛苦磨砺的过程，希望切入中台的同学都能够顺利进入自己的角色，在产品的道路上打怪升级，成就自己的产品梦。
