华住:移动时代,自主可控的架构秘密

简介:

华住酒店集团有6万多名员工,8000万位活跃会员,3000多家门店,合作的精选酒店也达500余家,显然,这些数据还在继续增长。

任何一个店客的投诉,30分钟必须响应妥办。

客人退房后的0秒,楼层服务员收到打扫任务信息,自主安排作业。房态保持实时更新,净房信息0秒同步给客人以便于自助选房,支持在满房状态下的选房;

客房出租率保持85%左右,有些门店甚至要在110%以上;

支持包括积分、优惠券、第三方支付、银行卡等在内的混合支付;

几分钟内需要完成调价手续;

要取消酒店里的对讲机、客房的电话机;

官方渠道订房率约90%;

系统是完全中央化的,所有门店及分支机构都没有本地的应用与数据存储。十几个互相耦合的子系统协同工作;

支持从“住宿”到“住宿+X”的升级。

……

要实现以上集成技术及系统功能,他们是如何做基础设施选型的?华住酒店集团CIO又是如何带领300号人的团队和业务线特别是一线进行协同创新的?

前不久,牛透社主笔如约拜访了华住酒店集团CIO刘欣欣女士。主笔第一次和她见面是在2016年9月份,崔牛会在苏州主办全国CIO论坛的时候,她当时做了主旨演讲,是关于如何带领团队支撑“胖线上,快线下”业务战略的。那次三个多小时与她及核心团队成员的访谈,让我在现场感知到这样强韧的支撑力量。

攫取一部分访谈内容与大家分享。

“胖线上,快线下”的业务/技术战略是如何实现的?

移动互联网大潮之下,如何通过移动应用来承载、巩固业务角色之间的业务关系,是众多企业的重要问题,华住也不例外。华住的业务系统最初基本都是基于PC的,在前几年迫切需要迁徙到移动端的时候,面临重要的选择,是多个移动应用,还是一个移动应用?最终确定下来的是两个,一个对内,一个对外。回头看一下这个决策,是非常英明的。从另外一个角度看,对外的其实是服务“供给侧集团”,对内的则用于服务“需求侧集团”。

两个App的安排,有助于各个业务系统的自然生长,也有利于系统之间的交互。实际上这都是架构委员会的功劳。

基于“胖线上,快线下”的基本业务/技术战略,实际上是要构造出一个以客人(会员)为中心的连续场景服务体系,更多的事情交由系统(线上)去完成,而且大部分是客人驱动的。这样的话,就可以形成可靠的自助服务体系,关键是提高了门店各个岗位的效能与协同价值。目前有些酒店可以实现全程自助,除了需要前台人工验证身份证之外。

这样许多典型的传统场景线上化的比例就逐年上升,同时为其他场景的线上化或者线上化比例的提高创造条件。“胖线上”就显得非常可靠与实际。

比如,客人退房信息确认后,楼层服务员立即收到提醒,进行打扫或者做好打扫的安排。而不需要前台通过对讲机进行通知,这是线上的系统替代线下工作的典型场景,对于基本满租的华住旗下酒店来说,前台话务量的减少,直接意味着对客人服务的品质保证。尤其在退房与入住相对集中的时段。这个工作的线上化也直接为“自助选房”创造了条件。显然,自助选房比例的扩大,也在减少前台的工作量。

线下的服务就是敏捷的,就是快的。“胖线上,快线下”相辅相成,客人的体验得以增强。

这样的敏捷业务以及更大想象空间的敏捷业务上从哪里来的呢?这得益于自主可控的优秀的“华通H-Tone”(华住内部App的名称)。

为什么选择世纪奥通的Simba作为华通的“基础设施”?

打造华通是华住充分顺应移动互联网大势,保持健康增长的重要举措。显然是战略级的事情。从基本的诉求来看,涉及到这样几个方面:

1、打造内部办公门户

把已有的多个App全部统一,所有员工只需面向一个App,就可以完成内部所有协作事宜。让每一个员工都拥有自己的账号和权限,并可以利用同一个身份在各类系统中自由切换。

2、构建消息总线

以IM平台为消息总线,将内部各业务系统打通。无论是来自于沟通协作中的消息,还是来自于审批过程中的消息,都需要统一到一个终端消息界面,方便组织中的角色随时查看、阅读、转发审批。

3、融合通信

除了IM平台、业务、消息,还需连接各门店的电话系统,为华住打造新总机,以更好的让门店和住客之间的联系、互动,以及总部的服务监督。

4、打造类微信的沟通、协作平台

以IM、UC为核心,连接组织架构、应用、门店总机,客房电话,呼叫中心

5、App快速开发框架

App框架兼容性好,能够适应90%以上的安卓手机机型。提供各种丰富的原生能力,IM,语音通话,视频通话,LBS位置,日历等等。开发周期短,能够快速叠加新应用。

6、私有化部署

处于长远发展,以及数据安全角度,不考虑完全的公有云服务方式。

7、连接住客(会员)端App

华住会员目前已达8000万,会员端的APP主要以商城以及订房为主,在未来需要和HTone打通(IM、语音、业务、投诉等),需要将HTone的IM以及音视频的SDK剥离出来集成到会员端APP。

这些都是众多大中型企业的典型场景需求,随着企业的持续发展,在这个基础上,需求还要持续升级。

根据当下及未来服务体量来选型,这样电信级的移动端系统,可选的方案居然寥寥,在2014年他们甚至和BAT中的一家讨论将其IM及架构能力移植到华住,因为各种原因,最后未考虑此合作。显然,如果让不擅长业务场景的企业来开发这样的底层系统,也不是朝夕之功!巧合的是,经介绍,北京世纪奥通接洽上了华住IT团队。世纪奥通的一个Simba系统(取名来自于着名的电影《狮子王》),其貌不扬,最初是从音视频会议的价值角度去切入合作的。在深度研究了产品之后发现,这款“早产”于2006年移动IM产品,原来大有来头,曾经以“中国Skype”的身份挺过了因用户指数级增长而导致的服务器持续崩溃境地,并历经多次SOA化的升级,扛过数百万并发,最终满足了C端苛刻的体验需求。

奥通在2006年也确实为某运营商提出合作开发IM的方案(这段历史在另外的篇章中将详述),结果运营商没有同意,没有同意怎么办?就自己做了。

这样炼狱后重生的Simba,恰是华住IT业务创新改进阶段所需要的较为合适的伙伴。

2015年春节后,双方团队一起打磨两年,支撑“胖线上、快线下”战略的华通诞生并运用于千余家酒店。

华通在酒店及集团内部应用两年多以来,用户数近六万,有效安装度达91.2%,用户活跃度95.86%,平均月新增安装用户超过1500次,承载能力:可接受并发2500人,同时在线3万多人,包含20余个主要应用,包括易系列、培训、审批、店长/城区管理、IM、帮助、BI、差旅、签到、任务、提醒、通讯录等等。核心业务覆盖度超90%,应用月使用次数超过77万次。

华通架构委员在干什么?

华住在立业之初的定位就不是一个传统的酒店连锁企业,而是一个科技企业。现在看来,其实是一个完完全全的互联网企业,如果用一个未竟的认知来描述,那就是“O2O”,这个被疯狂资本摧毁了的新经济形态,其实还远远没有露出真容。实际上它的真身也只能由实业基础的品牌企业来描绘。

华住的发展史其实就是互联网背景下的技术化水平不断提升的发展史。在内部有一个秘密的团队在不停地升级IT内功,让IT&互联网手段持续地为一线和二线业务赋能。

从整体的业务架构和技术架构来看,不管业务如何变化,技术与系统必须保证四个统一:

1、组织架构统一。所有的信息化应用,基本第一步就是由系统管理员导入企业组织架构,让每一个员工都拥有自己的账号和权限。而在原有PC端,原来部署的OA、ERPCRM等各类应用都会涉及组织架构,可以利用同一个身份在各类系统中自由切换。

2、消息统一。无论是来自于沟通协作中的消息,还是来自于审批过程中的消息,都需要统一到一个终端消息界面,方便组织中的角色随时查看、阅读、转发审批。

3、应用模块统一。自有移动化信息门户,必须将企业内部的应用、信息流互相打通,整合其他H5的移动APP,最终形成一个兼容各类应用模块的应用池,让用户有个一致化的体验过程。

4、通信统一。除了业务和消息,还需连接各门店的电话系统,打造新总机,更好的让门店和住客之间产生联系、互动,以及落实总部的服务监督。同时对于“屏”的价值开发也列入通信统一的范畴。

上面四项,既是架构的原则,也是具体的任务。

华住的架构委员会由无线研发总监担任主任,CIO担任秘书长,各品牌及业务线负责人、“小CIO”们参加。每个月有两次工作会议。实际上也构成了华住信息化工作团队-两三百号人组成的盟广信息团队的日常工作决策体系。

架构委员会的工作机制不同于传统的项目委员会。它是完全以业务驱动型为纲的决策机构。

“小CIO”扮演什么角色?

上面我们提到了架构委员会里面有一个重要角色叫做“小CIO”,为什么叫做“小CIO”呢?刘欣欣解释道:

华住的每个品牌、业务线(如行政与HR业务线、财务业务线)等,都由盟广信息委派一人到那里驻点办公(兼职,不是专职),这样的角色目前有8人。实际上他们承担着业务与技术的“翻译”工作,许多一线的需求是否具有项目化的条件,必须要“小CIO”做精确的调研分析。新的功能上线,自然也是由他们负责实施。当然这还不止,最有挑战的是,他们的KPI和所服务的品牌或者业务线是紧密关联的。区别于一般企业在类似情况下设立二级CIO的普遍做法,华住这样就可以从制度上避免技术与业务两张皮的情况。

这样的安排也和华住的信息化大集中的特性完全一致,涉及到门店及分支机构现场服务的,他们还有一个叫做“蚂蚁兵团”的社会化部队来履行。

我们可以发现,支撑华通(H-Tone)的有三个架构,一是基于Simba的技术架构,二是一线为先的业务服务架构,三是支持高度集中的IT力量的组织架构。恰是这三驾马车,构造出支撑华住业务可持续创新与发展的发动机。

这个发动机的引擎启动之后,以住宿为中心的商旅生活方式平台应运而生,“住宿+”大平台生态也呼之欲出,也期待未来的华住带给我们更多的想象空间。





本文出处:畅享网
本文来自云栖社区合作伙伴畅享网,了解相关信息可以关注vsharing.com网站。
目录
相关文章
|
13小时前
|
负载均衡 监控 算法
微服务架构下的API网关模式与实践
在现代的后端开发中,微服务架构因其灵活性和可扩展性而受到青睐。本文深入探讨了API网关模式在微服务架构中的应用,并结合实例分析了API网关如何提高系统的可维护性和安全性。通过对比分析,文章展示了API网关在处理跨域请求、负载均衡、认证授权以及日志记录方面的显著优势。
8 0
|
19小时前
|
运维 Kubernetes 云计算
云计算时代的运维革新:容器化与微服务架构的融合之道
在云计算技术飞速发展的当下,企业IT运维面临前所未有的挑战与机遇。传统的运维模式已难以满足现代业务对敏捷性、可伸缩性和自动化的需求。本文深入探讨了容器化技术和微服务架构如何共同推动运维领域的革命,通过数据支持和科学分析,揭示了这一融合趋势如何提高运维效率、降低风险并促进创新。
|
19小时前
|
设计模式 监控 测试技术
后端开发中的微服务架构:优势、挑战与实践策略
在现代软件开发领域,微服务架构已成为一种重要的设计范式,特别是在后端系统中。本文旨在深入探讨微服务架构的核心优势、面临的主要挑战以及实施该架构的策略。通过引用最新的研究成果和行业案例,文章将提供对微服务架构实际应用的深刻见解,并指导开发者如何有效地采用和优化微服务架构以提升系统性能和可维护性。
|
20小时前
|
安全 Java 数据安全/隐私保护
Spring Boot中的微服务安全架构
Spring Boot中的微服务安全架构
|
20小时前
|
Kubernetes Java 微服务
使用Spring Boot构建微服务架构
使用Spring Boot构建微服务架构
|
2天前
|
Kubernetes 测试技术 持续交付
深入理解微服务架构及其在现代后端系统中的应用
本文将深入探讨微服务架构的核心概念、设计原则以及如何在现代后端系统中实现和优化它。我们将从微服务的定义开始,逐步展开讨论其优势、面临的挑战,以及如何克服这些挑战。同时,文章还会涉及微服务与容器化技术、持续集成/持续部署(CI/CD)的协同作用,以及微服务架构的未来发展趋势。读者将获得对微服务架构全面而深刻的理解,并能够识别在实施过程中可能遇到的陷阱和解决方案。
21 1
|
2天前
|
存储 监控 负载均衡
深入理解微服务架构中的服务发现机制
【6月更文挑战第25天】在微服务架构中,服务发现是确保各独立服务组件能够高效、可靠通信的关键环节。本文将探讨服务发现的基本原理、核心组件以及在现代云原生应用中的最佳实践,旨在为读者提供一套系统化理解和实现服务发现机制的指导思路。
|
2天前
|
消息中间件 负载均衡 持续交付
探索后端开发:微服务架构的演进与实践
【6月更文挑战第25天】本文深入探讨了微服务架构的概念、发展以及在现代后端开发中的应用。我们将通过一个虚构案例,展示如何将传统的单体应用重构为基于微服务的架构,并讨论在此过程中遇到的挑战和解决方案。文章旨在为读者提供从理论到实践的全面指导,帮助理解微服务架构的优势及其在企业级系统中的应用。
|
2天前
|
消息中间件 监控 Java
使用Java构建微服务架构的最佳实践
使用Java构建微服务架构的最佳实践
|
2天前
|
监控 Java 持续交付
构建Java微服务架构的CI/CD流程
构建Java微服务架构的CI/CD流程

热门文章

最新文章