4008-588-669

中台实验室

THE MID-PLATFORM LABORATORY

中台实施的1个经验和4个教训 | 《中台战略》领读

发布日期:2020-06-03 来源:《中台战略》

导语:阿里巴巴中台建设很成功,某地产企业的中台建设很成功,某白酒企业的中台建设也很成功,这些成功的案例吸引着越来越多的企业关注并接纳中台理念,但别人的成功并不意味着自己的成功,实际上,在项目建设过程中,存在各式各样的问题与困难。

 

经验:持续迭代完善

中台建设不像传统套装软件那样成熟,是在探索已知世界的未知问题,面对未知的领域,困难在所难免。而面对这个不确定性的世界,成功和失败的界限并不是那么清晰:也许今天遇到的困难,明天再看就是成功,反之亦然。重要的是,信心和持续创新的环境。

 

企业要快速成长,需打造以面向交互对象为核心的特种部队型前台、交互作战单元,以快速响应、迭代交互。事实上,中台组织就是前台交互作战单元的航空母舰,它以聚合的方式帮助前台快速匹配所需的能力及资源,进而实现敏捷响应用户快速变化的需求。同时中台能帮助领先企业将现有核心能力产品化、业务化,在中长期延展现有业务生态,开拓全新的收入及利润来源。

教训1:团队组织错误

某个项目的研发团队进行了两次调整。研发团队最初分成三大项目组,其中一个项目组负责大中台的所有服务与前台应用的开发;另一个项目组负责采购、仓储等供应链体系的开发,与SAP关系紧密;还有一个项目组负责测试。每个项目组内又按职能细分为若干个小组,如Java小组、H5小组、App小组等。而产品小组是一个独立中心项目组,他们设计好产品原型后直接交由技术部门评估、开发并实施。产品组负责整体项目的进度,并验收成果。

 

第一次调整,将各职能全部打散,划分两个大的项目组—数字供应链项目组与数字商城项目组,各项目组是一个完成的实施主体,包含了各种职能,产品小组负责将产品的《需求规格说明书》提交到两大项目组,统一由项目组进行项目管控。

 

第二次调整,按产品线分为6个小组,每个小组由7人左右的敏捷团队组成。其中,中台是敏捷开发组之一,2周上线一个迭代版本。当一个迭代在开发时,原则上不允许需求变更,若有需求,放到下一个迭代版本完善。业务架构师们负责迭代规划、原型设计以及《需求规格说明书》的编写。所有产品线统一测试,由测试人员宣布迭代上线的时间点。经过这一次的调整,无论是项目进度还是效果都将得到大幅提升。敏捷开发这种小组作战的形式,以及谁开发谁负责的原则,能培养每个小团队成员的主人翁意识和积极主动的精神,打造目标一致而又松耦合的、快速响应的团队。

 

许多管理人和领导者都陷入一种迷思,认为增加更多的人力是好的,因为人是最宝贵的资产,所以投入人力应该是提升整体效能的最好方法。但事实是,大规模组织让人们变得过度自信。这是因为人们倾向于在团体规模扩张时,低估完成工作的时间。有这样一个实验,当被要求完成相同的乐高模型时,两人小组花费了36分钟的时间,四人小组却花了52分钟,比两人小组所花的时间整整多出44%。

教训2:业务拆分不清

对业务理解不透,导致业务梳理和系统规划的时候抓不住重点,设计出的系统不能满足实际需求。例如,某企业的业务复杂度高,同时存在各种销售模式,有直销、经销、预售等;存在多业态,有商业地产、泊寓、教育、酒店;存在多种会员类别,有家庭会员、个人会员。在业务设计之初为了能够快速响应业务需求,将用户中心与会员中心的服务进行了整合,但随着业务的发展,在迭代开发过程中造成了大量的混乱信息,使团队的管理和维护成本大大增加。后续还是将用户中心与会员中心分开才解决问题,过程中走了很多弯路。

 

教训3:微服务被滥用

中台一定是企业级的,这里的企业级不是说难度而是指范围。企业级也不一定就是一个企业的范围,甚至可以是跨企业的。中台的建设过程虽然可以自下而上、由点及面,但驱动力一定是自上而下、从全局出发的,并且需要一定的顶层设计。

 

企业级也是区分企业中台化与应用系统服务化的关键点,简而言之,中台化是企业级、全局视角的,微服务化更多是系统级、局部视角的。从组织架构模式的角度,“中台”突出的是规划控制和协调的能力,而“前台”强调的是创新和灵活多变。微服务不是越多越好,一定要根据实际的业务做相应的匹配,设置一个独立的业务单元,单独提供一个系统服务。

 

某个项目中台设计之初,整体拆分出了80个微服务,16个共同组件,需要应用服务器86台,人员维护成本相当高。优化以后,微服务缩减到了26个,应用服务器只需要33台。

 

教训4:系统过度设计

大部分微服务案例只能看到微服务架构的“演进结果”,而看不到微服务架构的“演进过程”。这就像每个人看到一个架构的高峰,却看不到攀登高峰的路径。这就给很多架构师一个假象:微服务的架构是通过能力极高的架构师一步到位设计出来的。在中台建设过程中,往往也会陷入这样的误区。软件架构的最基本规律是解决当前的需求和痛点,无法对没有出现的问题和痛点进行设计。因此,一步到位的整体的微服务架构设计完全没有必要。况且一个集中化的设计很难体现微服务的轻量级优势,因此也违背了创新工作法的原则,结果会导致业务真正需要创新的时候,把之前设计的内容又推翻重来。

1591192099615740.png

Copyright © 2021 广州云徙科技有限公司All Rights Reserved 浙ICP备16028793号备案号33010802007501

市场合作:zhao.jing@dtyunxi.com媒体合作:markting@dtyunxi.com[page]      友情链接  [InfoQ]

您好:

您在有任何问题和需求,欢迎随时和我们联系,人工客服在线时间:9:00-18:00(工作日),感谢您对云徙科技的支持和信赖!

公司:

姓名:

电话:

邮箱:

业务需求: 业务中台 数据中台 技术平台 全域会员 全触点营销 全渠道交易 全链路服务

需求描述: