声明:本文来自于微信公众号小毅职场(ID:xiaoyizhichang),作者:邹毅,授权tag知识库转载发布。
中台这个概念,最近被吵得热火朝天,网上文章满天飞,这阵风都快让人以为中台建设才是企业发展之道,但是大部分文章都还停留在讲中台概念,很少人在讲中台的实践。
殊不知,从 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 周作为一个迭代周期,快速满足部分业务场景。交付一部分系统能力,满足一部分业务长,赢得一部分业务接入;再交付一部分系统能力,再满足一部分业务长,再赢得一部分业务接入。不断的通过这种方式循环,即丰富了系统能力,又能赢得大多数业务的满意度。
总之,用工匠的精神、成就前台业务的思想、永不停歇的努力,总会“精诚所至,金石为开”,实现中台建设的愿景。(完)
文章评论 本文章有个评论