一条朋友圈引发的订单中台大讨论!

昨天晚上,我在朋友圈发了一条关于中台的小探讨,本意是想看看问题描述的情况下,大家的选择如何,没想到发出后收到了很多干货回复,让我自己也受益匪浅,因此整理后贴出来,分享给更多的朋友。也欢迎您将自己的观点留言探讨。

一条朋友圈引发的订单中台大讨论!

以下是题目:

关于中台的一个小探讨:
如果某个新业务的开展(还不确定能否成功),需要对已有的、可复用的中台做一定程度的改造(例如对订单中台要做10%的改造),但是可能会影响核心业务的稳定性(核心业务依赖于订单中台),请问,是否应该让订单中台承接新业务?
欢迎大家留言陈述看法!

一条朋友圈引发的订单中台大讨论!

我将大家回复的观点总结为三类:

  1. 明确表达不应该接入(或初期不接入,后期再考虑接入)
  2. 明确表达应该接入
  3. 没有明确给出结论,或有其他观点。

整体来看,选择1的同学较多(13票),后两个票数接近(分别是5和6),注意,该分类是我主观进行的划分,也许并不准确,另外文中部分同学的名字做了模糊处理。

下面我们一起来看看同学们精彩的回复!

建议中台初期不承接新业务(后期可以视情况接入)

Aaron

不需要,新业务没有定型前,流程没有固化,不能太着急上平台,否则会不断修改。可以让子弹多飞一会。

小飞

我基于我的过往经验聊一下。

  1. 对于新业务进行可量化衡量,判断新业务带来的效益是否明显
  2. 将新业务依赖的平台功能单独抽离出,独立运行,对原有中台影响降到最低,弊端就是资源浪费 重复开发 浪费人力
  3. 将新业务的粒度进行细化拆分,拆分为多个子模块和业务,中台逐步支持新业务的单独子模块,观察一定周期内运行如果顺利就继续承接新业务的下一个子业务。

通过这样的方式即满足业务需求也将影响与风险降到最低。

蓝野

大概率是不建议承接,除非这个新业务的需求,对于中台的改造,再将来同样支持其他新业务的发展。新业务也可以先尝试业务流程跑起来验证市场可行性,再考虑产品化。

闻小聪

不建议订单中台承接新业务。从权衡利弊角度考虑:

此时接入会造成的弊端有:

  1. 新业务可能后期停止,那么10%的改造成本投入会造成浪费
  2. 新业务的业务形态还不稳定,很难预估未来是否会有大变动,到时对中台会是很大挑战
  3. 对中台来说稳定性是第一要义,若对核心业务造成影响,是得不偿失的。

而利的点为:

  1. 减少了新业务的开发成本,能更快的实现上线运转
  2. 后期如果新业务发展顺利,减少了重构成本。

综上来说,弊端存在的风险>有利点,所以不太建议接入。

比较建议的做法是,让新业务尝试mvp的方式,探索是否存在不改动中台接口情况下的简易方案(可能会存在一定程度影响用户体验,但这个阶段最重要的还是验证业务存在用户需求)。当新业务确定是可跑起来后,再投入中台资源进行改造会更合理。

二十

不应该。既然业务不确定能成功,那说明还在尝试阶段,这个阶段业务模式通常会反复变化试错,接入中台系统很可能跟不上业务的调整节奏,何况改造还影响到了核心业务稳定性。

公司打造中台体系成本很高的,业务不稳定或者规模不够大都不用着急接入中台。可以利用中台当前可复用部分,其他业务逻辑的部分业务团队自己搭建,但产品架构要尽量匹配中台,保证有一天业务稳定后可以最小成本的与中台对接。

当然还要考虑当然公司业务线有多少,如果当前已有的业务线数十条,10%的改造成本就太高了,如果本来就两三条业务线,就可以视对核心业务稳定性影响大小考虑。不过业务线少的公司应该也不会有中台体系

Gf

首先结论是B端产品稳定性是第一位,任何新业务变化都不能影响现有上线业务的稳定性。

如果是我的话,个人建议新业务的开展先按照独立的形式进行迅速发展,快速投入市场看反响。再进行讨论。

第二点是,同时新业务在迅速投入市场的过程中,无论是设计及开发都需要遵守中台相应的规范,以便于之后更好的进行整合。

第三点是,个人认为并不一定要整合成一个订单中台。按照公司统一的通用规范设计,能够在其他业务所需要的时候,能够快速对接使用就可以了。

TaoX

倾向于暂时不承接。

  1. 一个还未验证的业务需要保持灵活性,尽量低成本,对核心业务低风险。新业务的话,感觉初期订单模块不会做太复杂,可以尝试先自己做一下。
  2. 因为有订单中台,所以必须走中台的这种想法,可能让中台变得有些被动和臃肿。中台是抽象和归纳的结果,不太适合为了未被验证的个例就直接改变自身。

Nie

新业务规模小风险大,改造原订单中台的收益确定性不高,且对已有核心业务造成风险。可以先让新业务做独立订单库,技术架构复用订单中台,待新业务验证模式成功且具有一定规模后再考虑融合

JH

不建议承接,原因是风险大于收益,可以用更性价比的方案来验证新业务能否跑通。通过线下和简单的线上工具先去验证业务能否跑通,再去接入中台。

浅浅淡淡

  1. 理论上不建议,如果一定要仔细评估那10%是不是必要的,要把改造比例降到最低先支持垂直业务主流程走通。
  2. 分析那10%是不是中台应该有的能力,继续完善中台,做通用

短腿欧巴

不应该,核心系统的依赖部件应该只依赖于核心系统的诉求功能上是闭环,其他的功能需求应当以扩展模块或者插件的形式引入,大中台一定要有支持的扩展槽,模块与核心订单中台之间应当是以松耦合的方式完成(消息队列等),web端进行逻辑整合,使得用户在体验上觉得功能得到了扩展升级,但是中后台是相对独立的设计

小妞

菜鸟拙见,既然是还不确定是否会成功的新业务,又需要对已有的中台核心模块改造,初期不应该承接。新业务先脱离中台试验一个mvp,经过初步验证可行再去向中台提出需求做改造,否则中台改造风险有点大,可能也会影响已有业务。期待他人的精彩回答[捂脸]

王者浩荡

基于中台做一个分支的独立流程,与主流程剥离,单独部署

建议中台初期承接新业务

徐蒸鱼

如果是我决定我会承接。中台的核心任务我认为是提供快速尝试能力,稳定的业务支持是次要的目标。新业务需要改造中台本身就说明原本设计兼容性不足够,而且现在有了明确的升级方向,那么升级以提升未来业务兼容能力顺理成章,此时推进事倍功半。至于改造与稳定性的关系本身就存疑,如果10%的改造会造成稳定性问题说明本来的架构设计是存在不足的,借此机会正好调整,短期的不稳定是可以克服的

热心群众

我们假设这个中台已经稳定运行了很长时间,支撑了多类业务,这个中台的设计规划没问题,满足了规划中的需求。现在的业务超出规划是一个信号,意味着业务在变化,需重新整体设计中台。这种情况下本次项目中仓促改动中台收益不大,应该以新业务为出发点,整体扩展中台能力。

钱飞

中台应该是拆分的积木,可以任意组装。之后如果新业务不做可以快速恢复和还原。

WML

还是缺少一些更多的背景因素来帮助判断,比如新业务对比核心业务的成长性或者空间有多大?新业务开展的迫切性(核心业务是不是已经快支撑不住公司了?)核心业务受影响的可能性在什么范围?造成影响的范围有多大?稳定性受破坏后造成的影响是什么等等,如果就仅有的信息直接判断的话,建议承接,核心出发点是,灵活支持前台开展业务本就是中台的应有之意,就这一点。

LIN

本质上怎么权衡新功能及稳定性,结论:订单中台需要承接新业务,观点如下:

  1. 前提:订单中台,微服务部署,数据一致性已接近
  2. 假设:系统迭代时,总会出现新业务的实现,需要更改以前的核心模块
  3. 方案:订单中台微服务请求处理,进行灰度路由

需要进一步明确背景评估后判断

咸鱼
也许这个前提就有问题。可复用的部分就是可复用的部分,另外10%可以开发新的微服务先跑。中台就节省了,90%的开发量。后面成了再说呀。

张于刚

先说结论,承接新业务和中台改进不矛盾,新业务是不断推进中台产品演进的动力。

  1. 新业务方面,尝试性业以核心稳定为主,做最小闭环设计,分阶段推进,并且要做价值评估。
  2. 核心业务方面,充分评估影响的范围和关键点,进行同步改造。
  3. 制定兜底预案,比如预警监控,异常回退和切换。
  4. 发布阶段,可以核心改造先上线观察一段时间后,新业务在上线。
  5. 最后复盘,做预实评估,投入产出评估。

一蓑烟雨

不应该被“是否应该让订单中台承接新业务”束缚住,可以尝试应该与不应该之间的第三条路。

首先,需要考虑新业务未来是否会成为一个独立的业务,如果有较大可能成为一个独立的业务,那么就不应该让中台继续进行承接,中台更多的是承担企业大多数“共通”的功能,对于独立业务中后期发展中的个性化需求很难提供支持;

其次,需要考虑对中台改造程度的风险与收益,对订单中台10%的改造会影响大概多少中台的稳定性,会因此造成多少损失,新业务又会因此获取多少收益,风险与收益,是否可以接受;

最后,回到问题的最初起点,新业务的开展是否一定需要对中台进行改造,对于订单中台的功能模块,是否可以找到其他替代选择,在不改动中台的前提下,先进行业务模式的跑通,如果跑通之后,确实需要进行改造,那么有商业数据支撑,中台改造也会更加顺理成章。

子良

1.原核心业务是否属于增长期?如果处于快速增长期,不建议对原有的状态进行改动。如果处于存量市场的稳定阶段,可以考虑对原有系统中台进行扩充。可能影响核心业务的稳定性,影响到底有多大,评估好以后可以开展工作。

2.新业务处于什么阶段?是否已经过市场验证,必须得要公司的中台系统来进行支持?现阶段没有中台的支持会造成什么影响?

我的基本思路是,判断原业务系统是否有发展空间,如果没有,考虑改造带来的负面影响及对应的措施,坚决执行。同时需要考虑到新业务的发展阶段,判定是否存在更优的整体方案。

达尔文

1、这需要结合新业务对公司未来发展的影响、与核心业务的关联关系、改造对核心业务的影响程度、市场窗口对时间的紧迫性等因素来考虑。

2、规定两个基本原则:1是先生存后发展,2是不给那些不明朗不相干的新业务干跨核心业务的机会

3、初步设想是可以基于现在的中台改造一个新中台独立运行试试看,然后再考虑将核心业务逐渐过渡到新中台。

4、给核心业务留一个稳妥的回滚方案。

嫣然

观点:可以承接,但是不是全部承接。

具体做法:

  1. 在不改造现有中台的情况下,对新业务的逻辑进行抽象.
  2. 把现有中台能承接的部分放到中台。个性化的部分放在新业务侧单独维护!
  3. 持续关注新业务发展,后期稳定再考虑对中台进行改造

和一名专业从事订单中心建设的PM同学的探讨

最后,是某知名电商公司,具有5年订单中心建设经验的飞同学的观点,该观点具备较为明确详细的落地方案,因此我和飞同学单独做了一些沟通,希望对大家有所启发。应飞同学要求,对公司和署名进行了模糊处理。

飞:工作中确实常遇到这样的权衡。这实际上也是对业务需求ROI的考核。

基于题干,我做了以下假设及分析。该公司已初具规模,因为行业内能搭建中台的公司并不多,因此核心业务对该公司意味着稳定的收入,从这种层面上来讲,影响核心业务代价很大。做10%的改造来换取一个前景不明的业务开展,不太值得。

然而,中台不应该成为业务开展的制肘,搭建中台的意义就是为了快速响应业务的开展。因此不做该业务,势必在公司内部对中台在企业中的组织地位产生挑战(这一点在业务和IT分离的公司中尤为明显)。所以,还是要做,那么问题来了该怎么做?

题干中以订单中台为例,那基于订单中台的角度来讲,是不是可以只复用订单中台的部分共性能力来支撑该业务的开展,而降低业务对系统的侵入性。因为基于题干不知道具体改造点,我做出以下猜测,比如订单中台提供的订单履约能力是直接适用的、订单与财务端的流程是适配的等。那么是不是可以在业务开展的初期,由小前台来完成订单的提交、支付等交易动作。

达成交易之后与再与订单中台打通来复用履约支撑和财务记账能力,从而将订单中台的改造降低,规避对核心业务的影响。当然,这种临时方案的设计中必须得为未来标准接入做提前的考量(我认为这是体现优秀的产品设计能力的关键)。例如,在设计订单模型的业务实体信息、确定订单类型及其对应的交易模式时就需要做标准的考量,以防未来业务稳定后有标准化接入的必要时,业务融合起来十分困难。

综上,我的观点是:订单中台应该承接该业务需求。但是在业务初期可以只做部分能力的接入,且在临时方案的设计中需要为未来标准化接入做相应的提前预判性设计。对于该业务开展初期订单中台无法支撑的流程及功能,应当由该业务对应的小前台来临时提供。后期该不该标准化接入,如何接入又是另一个话题了。

杨堃:你提到的两个订单中心的方案很有意思,不过我没有见过类似的实践(见过订单数据中心,只是做了数据集成,但是并不支撑订单作业),是否有实践中这样做过的呢?很好奇[抱拳]

飞:我在A公司的订单中台工作了五年,A公司的整个订单中心的设计中包括了:订单交易、订单履约、订单查询。

订单交易定位是需要支撑各种业态的正逆向交易模式。

订单履约的定位是作为订单履约的调度平台,包括订单作业的履约和财务的履约等。履约模式识别后调度相应的平台做履约操作,您说的实际的订单作业是由物流及其他平台提供的,比如自营物流、开放物流平台和商家订单中心等。

订单查询的定位是作为订单对外提供查询服务的系统,有些类似于你说的订单数据中心,但实际上是不提供数据报表类能力的。查询系统的设计是为了解决业务量大时的一个读写分离的问题,但目前来看这种设计在数据同步过程中常出现延迟以及数据同步异常deq问题,所以这种设计有一定的弊端。但是好处是完完全全把订单数据查询模块隔离出来了,在支撑各前台查询服务时,可以完全不侵入业务流程。

您给出的题目,实际上我在16年做的拼购业务融合项目就是类似的实践。只不过我是负责的业务发展强劲后的融合项目。16年之前,在我司拼购的业务开展就是类似于我说的临时方案。拼购的营销系统搭建了一个前置的订单中心,在拼团成功(也就是订单生效)后,下发订单数据给订单中心,实现订单履约。这种模式映射在我们订单交易中设计的一步式接单模式(一步式接单即提交到订单交易的订单是一个生效完成的的订单,只需保存订单数据,不做任何的资源处理,然后下发订单履约)。而实际上订单履约只需要提供标准自营的履约能力即可支撑该业务,所以可以标准化无差异接入。

16年之后拼购成为品牌业务,订单中心考虑标准化接入拼购业务。这种接入实际上对订单履约中心是无感知的。只是订单交易需要调整交易模式(从一步式调整为两布式),当然还有一些其他的改造比如支付不生效拼团成功才生效,比如需要调度营销系统处理拼团资格等。订单查询系统的改造只不过是接入了一个订单的辅助状态(拼团状态),改造也不大。

这是我说的实践的实例。从您的题目再衍生一下。您给的题目确实是工作中的一个痛点,在19年初我们对订单交易做了中前台模式的改造来规避你说的影响核心业务的问题。目前灰度了线上业务,希望有机会能跟您碰撞。[呲牙]

杨堃:说的很清楚,学习了。不过还是有个疑问,因为其实很多人理解的订单中台,实际上应该是指你提到的订单交易部分,我感觉听起来你们将订单拆成几块,又再一次做了抽象

飞:是的

杨堃:明白了,这个方法挺好,应该也是实践积累了很久才打造出来的吧

飞:因为之前的规划是做自营店铺化。订单履约的前身是作为自营订单中心,交易订单对接商家订单和自营订单,自营订单类似于商家erp的存在

后面大佬们的规划又变了,自营订单演变成了大的履约订单中心。

杨堃:哈哈,怎么做都有道理,没有研发干不出来的

结语

这道题目是开放性问题,结论并不重要,更希望引起大家的思考。另外,中台建设很多时候更是个技术方案问题,因此必须和RD同学一起深入探讨。此处给出我的一个小答案(其实不算答案,是一段虚构的情景分析,纯属为博一笑,请勿当真)

面对这个难题,几位相关负责人的想法如下...

核心业务负责人:新业务怎么做我不管,我的底线是不能影响我们核心业务的稳定性!否则就是千古罪人!我必须得diss!

新业务负责人:用不用中台我不关心,我关心的是如何快速能实现功能,支持业务尽快跑起来。但是如果我们自己评估认为接入中台对于我们反而有很高的不可控风险,那么我更信任自己的研发团队来做一个粗糙版快速上线。反正不论如何,如果中台出了问题,甩锅是必须的!

中台负责人:这个问题好难,如果不接入,就违背了中台快速支持创新业务的大背景,如果接入,我们确实认为有很高的改造风险,可能影响核心业务。哎,难难难!要么我克隆一份中台出来单独部署,等稳定后再做项目合并呢?哎,这不就不是中台了么?咳,不管了,为了不违背集团中台降本增效的正确政治决策,还能一定程度控制风险,就这么搞了!

本文由 新媒体之家 作者: PM杨堃 发表,其版权均为原作者所有,文章内容系作者个人观点,不代表 新媒体之家 对观点赞同或支持,未经许可,请勿转载,题图来自Unsplash,基于CC0协议。
0

发表评论