52｜思考实例（上）：中台既不是银弹，也不是哑弹

思考题很难，我说说我自己的。我负责业务架构，对下是现成基建，对上是业务抽象，一般意义上的中台，我要做的事情就是提高业务能效，主要职责是流程编排优化，也就是怎么做的问题，我自己决策依据是业务价值：效率，规模，赋能，这是主线。至于每个节点做什么，是采购，是自建，还是妥协，反而不是我关注的焦点。我自己认为中台在能效上既是成本，也是壁垒，这取决于这个流程编排是否能自主进化。借用一下老师的直播例子，泛娱乐与社交，类似，但本质还是有区别的，直播中台用在1v1 社交业态，是天然的不合脚，前期是比光脚要好得多，中后期就限制了发力，转型，重来阵痛是免不了的。

中台与创新的关系，既矛盾有统一。 1.对于做改进或迭代型的创新，中台提供基座支持，以快速灵活试错与推进。 2.对于突破性或者革新型的创新，因为从本质差异大，从原有的业务复用少，中台就变得不适用。 中台的构建，对于业务视角的要求非常高，选择中台做哪些，不做哪些是非常关键的，技术实现倒是排第二的。

我们公司也尝试过规划做中台，但正如老师所言，当业务要快速迭代升级的时候，要去把有限的研发资源投入到这么庞大的中台建设中，真的是很难寻求到平衡点的。基本只能优先保障业务的快速迭代交付。所以对于业务成长型或转型升级期的企业，基本上是不具备做中台的条件的，很大原因在于这个阶段基本公司的组织架构都可能半年就调整一次，业务战略也不断调整转换。所以，我的判断大部分时候中台是一个伪命题，很难证真，反而很容易证伪。

文章还没读，先生的课我得用pc来读才行，不过之前对中台做了一些了解，先试着聊聊。 我的理解： 首先中台是企业级复用，相当于做出一些通用的业务组件。 业务可以重用和组装这些组件，当然有些个性化的还是需要自己做。 这样的好处： 有新的类似业务，就可以快速的搭建并跑起来。所谓大中台小前台。 缺点： 能做到渐进式创新，不支持颠覆式创新。 业务团队需要和中台团队频繁沟通，效率无法保证。尤其现有中台无法满足业务需求，需要做调整时，就更不可控了。 内部政治斗争就不提了。 数据中台 上面聊的是业务中台，关于数据中台，只提一点，我的感觉最好是企业内部人来做，不熟悉企业业务的人怎么能真正发现挖掘出企业数据的价值呢，而且是企业几乎全部的业务。 因此对于一些第三方做数据中台的公司，我一定程度上报以怀疑态度。

第一份工作，我被要求独立负责一款游戏后台。我需要找中台对接一些用户登录接口，结果就是几乎找了别人一周，人家都没搭理我。我就是那个被中台饿死的后台。现在想来，当时的企业文化也是真的糟心。出现事故，后端组只要发现不是自己，那就几乎要拍手叫好了。

郭老师，take away~~~抄袭别人的灵魂还是皮毛，阿里是不是抄袭了别人的灵魂？，或许是因为大部分公司没有技术和创新，业务中台是唯一亮点~~~ 很长时间找不到工作，找了个临时工，打包某电商平台的订单商品，每小时22元，每天12小时。提升了对技术优势和生存优势的认知，对《数字化转型》、《产品设计》、《业务中台》、《数据中台》，《复盘方法论》的逻辑，有了亲身体验~~~ 我没有经历过中台建设，就一条业务线，只是业务拆分为聚合Web层和业务能力层，技术抽象为服务治理能力PAAS层，IAAS层~~~ 我对中台的理解是对业务模式的抽象，业务泛化和具象化的平衡，中台的目标是创新和效率的平衡~~~

背景：本人主要从事toB方面零售领域的软件开发工作，公司拳头产品是后台的ERP，围绕ERP构建了一套业务中台，围绕中台构建相关前台应用。问题一： 认为合理的板块： 1. 用户中心、报表中心这两类。 2. 用户中心是业务足够明确和稳定；报表中心偏向技术型，从功能角度也足够明确和稳定。 3. 新行业客户使用公司产品时，这两个必备且基本无需求。（业务能力共享） 不合理的板块： 1. 商品进销存，从源头的商品资料，底层模型大差不差，但不同行业都有其特殊的属性和行为，比如标品和生鲜品；这些特性会对商品流通过程中的各个业务环节产生不同的影响。每次上线新行业领域的业务（对公司产品来说是新，业务上来说是红海），意味着996+大改，即做不到期望中业务能力的共享。 2. 从成本的角度，确实能实现快速迭代上线,但也导致产品后续维护成本变大，灵活性降低。 3. 从竞争的角度，只能说公司产品拥有了这个行业领域的基本能力，并不能在这个行业领域内带来绝对性优势；或许对公司产品来讲，最大的优势就是能力全、覆盖的行业板块多。 问题二： 面临过中台or自建的选择，最终选择了完全自建。原因如下： 1. 业务层面，它属于完全新的一项业务产品的开拓，公司已有的业务中台和它搭不上边。 2. 协作层面，我所在团队和中台团队分属不同部门，沟通协作成本大，且初期中台方面的人力也很难协调到。 最后结果，由于是新业务尝试，公司对这个新产品初期规划完全不care，也不愿意投入大量人力，选择自建对我带领的团队来说灵活性、适应性更高。最后满足了几个客户的诉求并顺利完成快速上线。N年后，公司想合并这块业务到已有的业务中台产品，由于初期在架构层面也考虑到这点，因此仅需做小部分的对接改造工作即可。

个人认为。有两种情况下适合上中台： 1.业务发展已经相对稳定。业务模式相对固定。不再有剧烈的变化。 2.早期看到对手已经出现一个新的业务模式。而自己方的中台，在当前可以快速搭建出来。这个仅在业务早期有用，因为随着业务的发展变化。尤其是复杂度提高，中台迟早跟不上这种剧烈变化的。 反正我认为中台只适合用在相对稳定的领域。

目前公司在做的ToB的统一设备管控的业务，正在将管控的用户设备各种数据从分散的收集方集中到一个集中的数据接受，决策平台。 o 目前看到的好处，有了集中的数据，确实能挖掘出分散数据平台所欠缺的统一协作的场景和进一步的想象空间。 o 但是明显的代价，就是不同设备管理应用平台自身的的关于数据决策，AI驱动的业务活动的创新和实现变慢了。管理应用平台的开发人员需要花费更多的时间来与集中的数据接受，决策平台来沟通，协调数据的传输格式，这个新数据是否与已有数据兼容，以及是否能适应其他的设备管理应用平台，两个平台的开发接口对接，进度协调等。设备管理应用平台的开发人员反而没有更多的时间关注最早的业务活动本身的需求，快速实现试错等方面。

在即将进入 2024 年的现在来看，中台依然在大大小小的招标文件上被奉为圭臬，只不过从互联网转移到了传统行业，政企数字化改革还能看到大量使用中台来营销产品的广告，也许不那么重视体验、更在意合规、安全的政企业务可能土壤相对更优质一点，整合、成本相对迭代速度、外部适应性优先级更高