业务中台之我见
一、什么是业务中台
1. 中台体系之间的关系
正所谓一千个人有一千个哈姆雷特，一千个公司也会有各自不同的中台，但归类到中台体系下主要还是分为三大部分：
- 数据中台
- 业务中台
- 技术中台
其中数据中台以及业务中台在整个体系内的关系可以说是互相依靠、互相支撑的异父异母的亲兄弟，互相支撑着一线业务的推动和发展，至于技术中台则与业务关联性较弱，本文中暂且不提。
2. 业务中台的定义
回到正题，什么样才算是业务中台呢？
我个人对其的一个定义，是这样的，首先业务中台需要满足中台的基础概念，那么中台的基本概念我们从“中台”这两个字也就能分析出来了：“中”是中心化的能力复用，“台”是平台型产品，总结下也就是所谓的“能够为不同的前台业务提供可以重复使用的能力，形成一次建设多次使用的平台产品。”
了解了中台的定义之后，我们也可以同理知道“业务中台”相比“中台”而言，最大的不同就是在“业务”上，那么怎么理解这个“业务”呢？这个就很简单了，了解下你的公司目前在做什么产品（形态），它解决了什么用户的什么问题（问题），通过什么样的方式盈利（盈利），就马上能知道这个业务是什么了。
在原本公司只有一条业务线的时候，只需要业务后端去做一套轮子就行，但后续公司发展到一定阶段，需要有多条增长曲线时，为了解决资源损耗的问题，业务中台也就应运而生了。
而业务中台，也不外乎是把多个业务会重复做的事情，在一个地方统一做了，通过一次开发解决多个业务线重复“造轮子”的问题，只是面向的对象从一条业务线变成了多条业务线。
举例：如果是电商业务那么业务中台就会包括了订单中台、支付中台、商品中台、促销中台等。
二、业务中台方法论
1. 发掘共性需求
做产品多年，如何挖掘需求这个点我想每个产品应该都有自己的一套成熟的方法论了，不过做中台会比较特别一点，发掘的共性需求不止是一条业务线，而是多条业务线。
1）市场预判&公司期望
我们在进行中台建设前必须要进行大量前期的建设调研，我们要做的就是了解企业的战略，知道企业当前的发展重心是什么，以及即将进军的下一个发展中心是什么？
业务中台因为涉及到比较复杂的多业务线对接，所以在每个公司基本上都是从上至下地推动，所以我们就需要在立项之初去预判出未来企业的发展方向。
可能是哪个地方我们优先去做对应的功能，并且在中台建设过程中，实时跟踪企业发展动向，补足中台能力，这样的情况下才能让我们的中台顺利地去接入到企业的各个系统之间。
2）现状&问题
当然，在了解市场和公司之后，公司当前的现状肯定也是你在做具体的产品设计的时候需要了解的。当前的业务流程是怎么流转的？有哪些关键节点？有哪些节点可以从业务后台下沉到中台？哪个部分需要从0到1中台开发的……这些都是你需要了解的，只有了解了之后，你才好做需求的合并，把握好中台的产品节奏。
在梳理完多个业务线的业务流程以及节点之后，下一步就是要将节点分为可标准化的部分与个性化部分。
具体来说这两类的节点定义如下：
- 可标准化节点：各业务相同承载部分
- 个性化节点：各业务个性化部分
一般来说可标准化节点就像是大学的必修课，个性化节点就像是大学的选修课一样，必修课选逃，选修课必逃。可标准化节点选着做，做重要的有影响力能解决问题的，个性化节点不做都交由各业务线来做。
（该图引用自《中台产品经理宝典》）
2. 评估需求痛点
评估需求痛点的方法，想必大家都有各种的方法，例如ICE需求评估法等等，我这边就不赘述，只说明以下几个点：
- 公司战略：该需求需要符合公司的战略规划，能够影响到战略的发展
- 业务价值：该业务在公司的价值几何，能够为公司带来多少日活和营收
- 用户分析：解决了什么用户的什么问题，给用户带来了什么价值
3. 定制标准，设计模块
在该环节时，我们要记住的一个核心准则就是：场景化驱动，业务抽象下沉。
1）场景化驱动
设计中台产品时的一个重点就像是业务产品一样，不只关注于自己设计的产品能够给予用户什么功能，还要关注到在当前条件下业务是如何运转的，系统+人工两个部分在业务过程中是如何互相支撑推动一个场景实现的。
场景举例：外卖场景下，用户看到商品→注册登录→下单→外卖送达，这四个部分合起来是一个完整的业务流程，分开就是每一个不同的业务场景。
2）业务抽象下沉
什么是业务抽象下沉？我们做的一个产品的时候一般都是只做自己项目的内容，但是做业务中台产品的时候，需要改变下思考方式：先思考一个大的框架，你的中台位于该框架什么位置，和其他部分的关系是什么样的？然后再去思考如何在这个框架内将自己的设计做的更通用化，例如支持多端多角色，多态等等。
4. 持续推广，价值复盘
业务中台顾名思义是服务于业务的中台，它需要从业务中汲取养分，最终也要落地到业务中去。在我做中台设计的过程中，很明确的一个考核指标一定是业务接入的速度以及广度，不能自己设计了一个产品然后自嗨。
所以这个时候你就要像是个推销员一样不断地宣导让更多的人来用你的设计，也就是所谓的，持续推广，价值复盘。
三、实操一个业务中台
具体实操方案都比较敏感不便赘述，也不一定会符合你公司对业务中台的期望，但基于我对于业务中台的理解有一点是可以说的：并不是所有业务节点都需要解耦成为中台，中台也不能解决所有问题。
随文附中台建设中容易遇到的一些问题：
1）内部对中台的预期过高，什么事情都推给中台去做
中台化本身的目标是一个为不同的前台业务提供可以重复使用的能力，形成一次建设多次使用。
那么一个新的中台团队刚建设的时候，就很容易面临一个问题，新的没有旧的好用，但是新的很有发展前景。
然后就会出现一种情况，被催着赶开发，而我的策略就是先满足能满足的，不能满足的业务先行，中台后行（保持自己的节奏）。
2）局限于某一个业务线，设计的不够通用
中台化的一个重点就是服务于多条业务线，若为某一条业务线冗余很多专属的设计，那就很容易失去了中台的意义，沦落成为业务系统/后台。
3）大家不使用中台/把中台当业务后台
和上面“持续推广，价值复盘”说的一致，重点是宣导，让企业内部其他业务线使用该产品，明确中台的产品边界，深刻理解中台在业务发展过程中发挥的作用是什么。
本文作者 @东航Channel 。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
