如何从0到1建设中台?看这一篇就够了!| 三节课深度

2019 年 7 月 9 日 三节课



本文作者邹毅,京东数科中台产品负责人,三节课《中台产品经理实战训练》课程主讲老师。


中台这个概念,最近被吵得热火朝天,网上文章满天飞,这阵风都快让人以为中台建设才是企业发展之道,但是大部分文章都还停留在讲中台概念,很少人在讲中台的实践。

 

殊不知,从0到1建设中台,特别是从N到1(N套系统融合成1套),这个过程非常的艰难。

 

中台建设的早期,公司层面或前台业务层面看到的都是中台产研部门增加了成本,却没有看到明显的效果,所以会引来很多前台业务对中台的不满,甚至还有人在等着看中台的笑话。

 

为什么还有看笑话这心态呢?因为从N到1的融合,你要收编别人的系统,甚至还要收编一些人,这些系统前台研发团队或许已经干了三年、五年甚至更长,前台产研会想:“你一个新成立的中台部门,凭什么来收编我的系统?中台能比我们干得更好吗?你们中台这么激进或者说这么高调(至上而下的干法往往比较高调,不高调干不成^_^),系统一定会出问题”,所以就等着看中台笑话了。

 

大家都知道罗马不是一天建成,中台建设也不会一蹴而就。它是一个循序渐进、逐渐成熟的过程。所以我提出了中台建设的【六六六】,也就是打造一款成熟的中台产品需要3个阶段,每个阶段6个月。通过这3个阶段18个月的时间,来实现一款产品达到去重、复用、沉淀、快速支持前台业务创新的目标。

 

写这篇文章,希望大家对中台的产品打造过程有一个了解,中台的从业者对中台的建设有个心理预期,前台的业务或者研发同学们能给中台产研一些包容、理解和支持。

 

第一个6个月:系统早期建设

 

首先,在讲早期中台产品打造之前,先交代一下京东数科中台成立之初的中台产研部门情况。

 

【别人家的中台 】

  • 有直接把“技术中心”改名为“技术中台“的;

  • 也有将原来的“共享研发部/平台研发部”升级为“中台研发部”的;

  • 也有通过行政手段把原来重复职能的“研发团队和对应的系统”全部合并到中台研发部门的。


如果是通过以上这几种情况来建设中台,那在中台的起步阶段,算是幸福的,因为中台成立之初,中台产研部门就有些家底、有些武器。

 

【我们家的中台 】

我经历的中台建设,没有别人家中台的那几种“幸福”,我们家中台成立之初,只能叫一个“惨”。


  • 系统整合:指定了一些需要整合的系统,这些系统都是基础的不能基础的,各业务条线都不愿意维护的系统,比如登陆注册啊、支付密码啊、数据采集、数据看板之类的,交易啊、商品啊、营销啊暂时不让中台碰。

  • 人员整合:整合人员的时候那更 “惨”,在整合原来对应系统的产品和研发人员时,前台业务部优秀的人想法设法自己留着,交到中台的都是自己部门不想要,或者实在也没有借口留下的人。这种情况就导致了中台成立之初,每个产品线都缺人,有些产品线缺产品经理、有些产品线缺研发、有些产品线缺测试,没有一个产线人员建制齐全。


就以上这种情况,依然有很多前台部门不满:

  • 有些前台部门恨中台瓜分了他的团队;

  • 有些前台部门对基础系统有依赖,需要中台的支持效率;

  • 有些前台团队心想,中台这可是共享研发资源啊,随便找个可共享的需求就往中台提…


总之,局势很“惨”,“惨”得我太好意思继续描述更多悲催场景了。


这样的“惨”,我认为不仅是我们团队有过这样的经历,我想传统企业的中台整合过程,可能会更“惨”…

 

回到正题,为什么中台产品早期的建设需要6个月?

 

如果我们是在那个“惨”的情况下成立的中台,中台不能只甘心于做那些犄角旮旯、基础得不能在基础的系统,中台需要做些可具备共性需求的业务核心系统,才能达到中台建设的快速响应客户需求的目标,否则拓展新业务的时候,核心系统还得重头再来一遍,犄角旮旯的基础系统对一个新业务的开展达不到明显的提速效果。

 

  • 整合重复职能的系统:如果是整合重复职能的系统,你需要选型一套系统按中台标准来进行升级改造,然后再把其他系统逐渐废除掉。或者就是重新做一套来符合中台标准的系统,逐渐废弃掉其他老系统,让存量系统/存量业务逐渐接入到新的中台系统来。

  • 新建中台系统:如果没有成熟的且重复建设的系统存在,这种情况系统建设早期障碍少一些,但也需要逐渐接入不同的业务场景。


我把这种中台系统从无到有的建设过程,称为系统早期建设,这就是第一个6个月要干的事。

 

像营销系统、会员系统、账户系统、商品系统等这样的业务核心系统,从0到1把初版系统开发完成,一般都需要3-4个月的时间。第一版上线之后,引进少量业务进行试用,测试出一堆BUG,一般需要花个2个月左右的时间进行多次迭代,才会有信心让大量的业务开始接入中台系统。这样的过程,就是系统早期建设的6个月。

 

为什么选择6个月?


有人会较真说,系统大小不一样、公司规模不一样,系统的建设周期就不一样。


我这里假设的是稍微成体系的中台系统,比如营销系统、会员系统、账户系统等,这样的系统如果说3-4个月,很难让业务大规模使用,但8-9个月呢?又会超出公司高层的期望,如果一个系统半年时间还没见投产,这么长时间我相信大家都不好向公司交差,超出老板们的期望后果很严重哦……,所以6个月作为一个里程碑,是一个刚刚好的节点。

 

(PS:不由自主的想起岳云鹏那首《五环之歌》,啊 五环 你比四环多一环;啊 五环 你比六环少一环…所有6个月选择也有学问^_^)

 

第二个6个月:业务全面接入


中台系统的建设首先讲的提炼共性需求,那必然会服务于更多的业务条线或业务场景,所以不是系统建设完就达到了中台建设的目标,还有一个漫长的业务场景接入的过程。


特别是整合多套重复业务系统场景,他们当前都有系统可以满足自己的业务需求,并且系统与业务场景耦合很深。重新接入中台系统会增加工作量,可能还会影响到业务的开展,所以前台的研发兄弟们那都是那一万个“不乐意”。这样的全面业务接入,不是一个轻松的过程。


不管推进业务全面接入是多么的艰辛,为了达成中台建设的目标,中台的产研同学们依然需要坚定前行。

 

业务全面接入阶段有两部分工作需要做:

第一部分:持续推进每个业务线/业务系统接入中台系统,在这阶段前台或中台一般都有一定的开发过程。

第二部分:随着新业务/新场景接入的过程中,会有很多业务个性化需求,或者早期隐藏得较深的需求未被满足,这各过程中系统还需要不断的迭代,来满足不同场景的需求,否则前台业务依然可以“找一万个理由”不接入中台系统。

 

在这个过程用6个月,如果有坚定的信念和较强的目标感,基本能完成单条产品线全面接入的目标。6个月的业务接入期,加上6个月的系统早期建设,1年节点又是一个关键的里程碑。并且全部业务接入,也是一个比较好量化的体现中台去重、复用的系统指标。

 

第三个6个月:系统成熟运行


中台的建设的其中一个核心目标是能力沉淀,随着业务的全面接入、系统的不断迭代,系统一定会走向稳定运行。


不是全部业务接入就等于中台系统成熟。业务全部接入之后,会迎来规模化的业务运营,在规模化运行中,中台系统需要进行标准化、组件化、智能化的升级改造,运营需要建立接入标准、培训机制、服务机制等等,才能达到中台建设的最终目标。


这个系统成熟的过程往往也需要6个月,一款产品通过6个月+6个月+6个月,1年半的时间达到去重、复用、沉淀、快速效应客户需求的中台建设目标,将是一个完美结果。

 

如何通过18个月,

打造一款成功的中台产品?

 

以下是我的实战经验分享:

 

1. 产研特功队,快速拿下城池


如果前台重复建设的业务系统已经建了三年、五年甚至更长,且这样的系统还有多套并存,中台凭什么做出一套系统就能将他们全部替换或废除掉?或者让他们将共性功能全部接入中台,与中台一起共建、共享?


对人的要求极高,特别是产品经理。


  • 人脉不熟、心智不熟、套路不熟,结果就是前台业务没认搭理,别说建统一系统,了解业务当前现状都是难题。

  • 产品方法不熟、思考不够全面、做事不稳当,设计完的产品无法全场景覆盖,一旦返工成本高;

  • 信念不够、项目管理能力不够,全面业务接入就会一拖再拖。


所以,在早期组建具备攻坚力量的产品和研发团队,就非常的重要。


不但单兵能力需要很强,每条核心业务线还需要团队作战,2-3名产品经理,5-10名研发,2-3名测试,再加上1名专职项目经理,形成一个作战特供队。再加OKR的工作方法、敏捷的开发模式,18个月打造一款成功的中台产品不是梦。

 

2. 聚焦核心,做精做深


前台的业务系统可能已经做了三年、五年甚至更长,最致命的是那些重复建设的“山头”自己还在不断的自我净化和自我迭代,中台新建的系统怎么能让前台业务接入?


前台业务做广(什么都干),中台做专(共性)和做深(好用),中台集中火力攻击最核心、最基础的系统能力,一个功能单元一个功能单元的让前台业务逐步接入,而不是一口吃一个胖子。


随着前台大部分业务的接入,中台的单元能力会越磨越成熟,形成一个良性循环。


甚至到业务接入的中后期,中台系统一旦聚集了后台部门的支撑能力,实现后台部门支撑的能力闭环,中台将苦尽甘来,前台业务逐渐会由被动变为主动,像中台靠齐。(因为前台业务不仅依赖于中台系统,还依赖后台职能部门的支持)

 

3. 敏捷开发,快速效应/快速投产


前台业务在不断的发展和在迭代,等一个中台系统建设6个月或12个月再投产,前台业务等不起、伤不起…


所以中台建设可以采取敏捷开发方式,当中台的系统MVP版本上线之后,可按2周作为一个迭代周期,快速满足部分业务场景。交付一部分系统能力,满足一部分业务长,赢得一部分业务接入;再交付一部分系统能力,再满足一部分业务长,再赢得一部分业务接入。不断的通过这种方式循环,即丰富了系统能力,又能赢得大多数业务的满意度。

 

总之,用工匠的精神、成就前台业务的思想、永不停歇的努力,总会“精诚所至,金石为开”,实现中台建设的愿景。(完)


关于中台,你还有哪些想要了解的?
欢迎在留言区交流。




—— / 三节课口碑好课推荐 / ——



—— / 你可能错过的精彩内容 / ——



登录查看更多
19

相关内容

用来满足人们需求和欲望的物体或无形的载体。好的产品大家都喜欢
[ICML-Google]先宽后窄:对深度薄网络的有效训练
专知会员服务
34+阅读 · 2020年7月5日
最新《深度多模态数据分析》综述论文,26页pdf
专知会员服务
298+阅读 · 2020年6月16日
华为发布《自动驾驶网络解决方案白皮书》
专知会员服务
125+阅读 · 2020年5月22日
德勤:2020技术趋势报告,120页pdf
专知会员服务
190+阅读 · 2020年3月31日
新时期我国信息技术产业的发展
专知会员服务
70+阅读 · 2020年1月18日
【大数据白皮书 2019】中国信息通信研究院
专知会员服务
137+阅读 · 2019年12月12日
【LinkedIn报告】深度自然语言处理的搜索系统,211页pdf
专知会员服务
107+阅读 · 2019年6月21日
深度 | 推荐系统如何冷启动?
AI100
17+阅读 · 2019年4月7日
业务中台:如何在互联时代,快速响应用户需求?
互联网er的早读课
24+阅读 · 2018年12月26日
【工业大数据】工业大数据层层深度解析!
产业智能官
3+阅读 · 2018年1月20日
深度解析京东个性化推荐系统演进史
CSDN云计算
6+阅读 · 2017年12月11日
一个人的企业安全建设之路
FreeBuf
5+阅读 · 2017年7月7日
Conditional BERT Contextual Augmentation
Arxiv
8+阅读 · 2018年12月17日
Attend More Times for Image Captioning
Arxiv
6+阅读 · 2018年12月8日
Arxiv
8+阅读 · 2018年11月27日
Arxiv
3+阅读 · 2018年2月12日
VIP会员
相关VIP内容
[ICML-Google]先宽后窄:对深度薄网络的有效训练
专知会员服务
34+阅读 · 2020年7月5日
最新《深度多模态数据分析》综述论文,26页pdf
专知会员服务
298+阅读 · 2020年6月16日
华为发布《自动驾驶网络解决方案白皮书》
专知会员服务
125+阅读 · 2020年5月22日
德勤:2020技术趋势报告,120页pdf
专知会员服务
190+阅读 · 2020年3月31日
新时期我国信息技术产业的发展
专知会员服务
70+阅读 · 2020年1月18日
【大数据白皮书 2019】中国信息通信研究院
专知会员服务
137+阅读 · 2019年12月12日
【LinkedIn报告】深度自然语言处理的搜索系统,211页pdf
专知会员服务
107+阅读 · 2019年6月21日
相关资讯
深度 | 推荐系统如何冷启动?
AI100
17+阅读 · 2019年4月7日
业务中台:如何在互联时代,快速响应用户需求?
互联网er的早读课
24+阅读 · 2018年12月26日
【工业大数据】工业大数据层层深度解析!
产业智能官
3+阅读 · 2018年1月20日
深度解析京东个性化推荐系统演进史
CSDN云计算
6+阅读 · 2017年12月11日
一个人的企业安全建设之路
FreeBuf
5+阅读 · 2017年7月7日
相关论文
Top
微信扫码咨询专知VIP会员