0条评论
还没有人评论过~
黑马智库，创业必读
更多创业内容请访问www.iheima.com
产业互联网时代，数字化成为企业的核心战略，如何实现业务数据化？如何使数据赋能企业推动业务转型升级？如何提升企业数字资产的价值？这些都成为制约企业发展的难题。在此背景下，数字中台成为指导企业数字化转型、实现数字营销的主流方法。
对于大部分企业来说，数字营销和企业中台还是新鲜事物。阿里巴巴集团从2009年开始启动，直到2015年才揭开其最终的面纱。企业中台是为端业务应用变化服务的，比如，阿里巴巴集团前端应用有很多，包括：天猫、淘宝、咸鱼、聚划算、盒马、高德地图、菜鸟、饿了么、支付宝等。
未来，传统企业的营销应用端也会有很多，比如：抖音、今日头条、bilibili，微信公众号、微商城、App、线下门店、官方商城、第三方商城、广告互动、自媒体等。
不同的人在用不同的端，例如，某汽车企业下个星期要在深圳国际展览中心办一个车展，营销部门需要一个连接参加车展的端，按照以前的方法，需要提前5个月开发，而有了中台，只需要提前3天就可以了。
什么是中台
那么中台到底是什么？中台是一个新的概念，但却是一个旧有名词。在中国古代东汉时期，尚书台成为政府的中枢，号称中台。唐朝所完善的三省六部制，以门下省为西台，中书省为东台，也将尚书省称为中台。尚书省作为执行机构，辖吏、户、礼、兵、刑、工六部。
在新时期我们赋予了中台新的内涵。中台，通过对业务、数据和技术的抽象，对服务能力进行复用，构建了企业级的服务能力，消除除了企业内部各业务部门、各分子公司间的壁垒，适应了企业，特别是大型企业集团业务多元化的发展战略。基于中台，可快速构建最终消费者和客户的前台应用，从而满足各种个性化特征的前台需求，为企业的数学化转型提供明确的道路。
数字中台是基于企业级互联网及大数据架构打造的数字化创新平台，包含业务中台和数据中台。
一方面，数字中台可以在云厂商提供的运行机制和基础架构之上，支撑企业营销业务应用的标准化及快速定制化，同时为企业提供大数据数据采集、清洗、管理和分析能力，实现数据精细化运营。
数据中台可以将企业内外割裂的数据进行汇聚、治理、建模加工，消除数据孤岛，实现数据资产化，为企业提供客户立体画像、商品智能推荐、业务实时监控，助力企业实现数据驱动业务。
另一方面，业务中台不仅可以将原本不同系统相同功能的服务聚合起来，统一标准，统一规范，统一出口，实现企业业务的整合；还可以通过服务的聚合实现资源与能力共享，支撑新应用与新业务的快速开发与迭代，以满足快速变化的用户需求。
数字中台模式是将共性业务服务和技术予以沉淀，避免相同功能重复建设和维护带来的资源浪费。集合了技术和产品能力的业务中台能快速、低成本地完成业务创新，数据中台则能实现数据资源的共享。
未来，全面建立一个服务化架构的数字中台将会成为传统大型企业全面数字化转型的最佳解决方案，甚至成为未来数字营销的主导方案。
同时，企业数字中台将朝着跨终端、全渠道、全域运营方向发展，基于云原生技术实现中台弹性扩容，依靠平台能力为各个系统产品输出统一管理能力，帮助企业实现业务数据化、数据业务化，赋能企业智能化营销。
中台实施需要持续迭代
阿里巴巴中台建设很成功，某地产企业的中台建设很成功，某白酒企业的中台建设也很成功，这些成功的案例吸引着越来越多的企业关注并接纳中台理念，但别人的成功并不意味着自己的成功，实际上，在项目建设过程中，存在各式各样的问题与困难。
中台建设不像传统套装软件那样成熟，是在探索已知世界的未知问题，面对未知的领域，困难在所难免。而面对这个不确定性的世界，成功和失败的界限并不是那么清晰：也许今天遇到的困难，明天再看就是成功，反之亦然。重要的是，信心和持续创新的环境。
企业要快速成长，需打造以面向交互对象为核心的特种部队型前台、交互作战单元，以快速响应、迭代交互。事实上，中台组织就是前台交互作战单元的航空母舰，它以聚合的方式帮助前台快速匹配所需的能力及资源，进而实现敏捷响应用户快速变化的需求。同时中台能帮助领先企业将现有核心能力产品化、业务化，在中长期延展现有业务生态，开拓全新的收入及利润来源。
中台实施要避免的错误
坑1：团队组织错误
某个项目的研发团队进行了两次调整。研发团队最初分成三大项目组，其中一个项目组负责大中台的所有服务与前台应用的开发；另一个项目组负责采购、仓储等供应链体系的开发，与SAP关系紧密；还有一个项目组负责测试。
每个项目组内又按职能细分为若干个小组，如Java小组、H5小组、App小组等。而产品小组是一个独立中心项目组，他们设计好产品原型后直接交由技术部门评估、开发并实施。产品组负责整体项目的进度，并验收成果。
第一次调整，将各职能全部打散，划分两个大的项目组—数字供应链项目组与数字商城项目组，各项目组是一个完成的实施主体，包含了各种职能，产品小组负责将产品的《需求规格说明书》提交到两大项目组，统一由项目组进行项目管控。
第二次调整，按产品线分为6个小组，每个小组由7人左右的敏捷团队组成。
其中，中台是敏捷开发组之一，2周上线一个迭代版本。当一个迭代在开发时，原则上不允许需求变更，若有需求，放到下一个迭代版本完善。业务架构师们负责迭代规划、原型设计以及《需求规格说明书》的编写。
所有产品线统一测试，由测试人员宣布迭代上线的时间点。经过这一次的调整，无论是项目进度还是效果都将得到大幅提升。敏捷开发这种小组作战的形式，以及谁开发谁负责的原则，能培养每个小团队成员的主人翁意识和积极主动的精神，打造目标一致而又松耦合的、快速响应的团队。
许多管理人和领导者都陷入一种迷思，认为增加更多的人力是好的，因为人是最宝贵的资产，所以投入人力应该是提升整体效能的最好方法。但事实是，大规模组织让人们变得过度自信。
这是因为人们倾向于在团体规模扩张时，低估完成工作的时间。有这样一个实验，当被要求完成相同的乐高模型时，两人小组花费了36分钟的时间，四人小组却花了52分钟，比两人小组所花的时间整整多出44%。
坑2：业务拆分不清
对业务理解不透，导致业务梳理和系统规划的时候抓不住重点，设计出的系统不能满足实际需求。例如，某企业的业务复杂度高，同时存在各种销售模式，有直销、经销、预售等；存在多业态，有商业地产、泊寓、教育、酒店；存在多种会员类别，有家庭会员、个人会员。
在业务设计之初为了能够快速响应业务需求，将用户中心与会员中心的服务进行了整合，但随着业务的发展，在迭代开发过程中造成了大量的混乱信息，使团队的管理和维护成本大大增加。
后续还是将用户中心与会员中心分开才解决问题，过程中走了很多弯路。
坑3：微服务被滥用
中台一定是企业级的，这里的企业级不是说难度而是指范围。企业级也不一定就是一个企业的范围，甚至可以是跨企业的。中台的建设过程虽然可以自下而上、由点及面，但驱动力一定是自上而下、从全局出发的，并且需要一定的顶层设计。
企业级也是区分企业中台化与应用系统服务化的关键点，简而言之，中台化是企业级、全局视角的，微服务化更多是系统级、局部视角的。从组织架构模式的角度，“中台”突出的是规划控制和协调的能力，而“前台”强调的是创新和灵活多变。
微服务不是越多越好，一定要根据实际的业务做相应的匹配，设置一个独立的业务单元，单独提供一个系统服务。
某个项目中台设计之初，整体拆分出了80个微服务，16个共同组件，需要应用服务器86台，人员维护成本相当高。优化以后，微服务缩减到了26个，应用服务器只需要33台。
坑4：系统过度设计
大部分微服务案例只能看到微服务架构的“演进结果”，而看不到微服务架构的“演进过程”。这就像每个人看到一个架构的高峰，却看不到攀登高峰的路径。这就给很多架构师一个假象：微服务的架构是通过能力极高的架构师一步到位设计出来的。
在中台建设过程中，往往也会陷入这样的误区。软件架构的最基本规律是解决当前的需求和痛点，无法对没有出现的问题和痛点进行设计。因此，一步到位的整体的微服务架构设计完全没有必要。
况且一个集中化的设计很难体现微服务的轻量级优势，因此也违背了创新工作法的原则，结果会导致业务真正需要创新的时候，把之前设计的内容又推翻重来。
——本文摘编自《中台战略》
*i黑马，让创业者不再孤独。
i黑马，让创业者不再孤独。
2019黑马产业加速大会广州站·消费产业专场
文章来源: https://www.toutiao.com/group/6734024520438383115/