石基产品研发总监张立彬：攻坚产品云化、平台化、国际化三大战略，打造行业数字化转型的核心驱动力
过去二十年，石基在酒店信息化服务市场一路高歌猛进，成功实现三次转型。今天的石基致力于构建一个云技术服务平台，在不同业态之间建立横向和纵向的联系，实现数据的流动和交换。石基产品研发总监张立彬先生将石基这个云技术平台以及平台之上的产品和服务比作成一个产品层次清晰、战略目标精准、角色分工明确的联合舰队：为整个行业构建分层次的产品和服务体系，在不同业态间建立横向和纵向的联系，实现数据流动和交换，来给这个行业的包括上下游参与者甚至最终消费者在内的客户提供高附加值服务。而指引这个联合舰队不断加速向前的，有三大产品发展战略：云化、平台化和国际化。
在我看来，石基集团的酒店信息化产品线就像一艘以航母为核心的海空一体“联合舰队”，而不是一个个独立作战的“战列舰”或者“驱逐舰”。
目前在酒店信息化技术服务市场上，大多数产品的现状是：第一，整个产品线构成不分层次；第二，各产品功能定位没有清晰边界；第三，产品核心优势构建和强化战略缺失。如果一家酒店信息化企业不重视这些问题，不仅会给企业造成围绕产品研发、销售、运营大量资源的低效使用率，还无法为公司形成整体真正的核心竞争力和长期优势。
在酒店信息化生态圈里，我们认为核心思路是要分层次构建产品线，即：首先，在产品垂直细化领域，针对酒店行业本身业务形态不同（度假、商务、综合体、长租公寓等）、组织形态的不同（单体、集团、连锁等）以及行业发展趋势变化（集团化和中央化趋势，运营服务智能化趋势、直销工具社交媒体化趋势、分销渠道聚集化趋势等）的影响，我们都能够生产和快速迭代出对应的产品组件+功能服务去适应与满足客户需求，并且每个对应的产品组件都有专业且专注的团队去投入资源完成设计和开发迭代，保证每项产品交付的先进性、专业性、及时性。
同时，在产品横向切分领域，对于直接面向客户使用的产品服务和提供平台运营和技术支撑的服务，并不是眉毛胡子一把抓都冲到前方做业务功能和场景实现，而是通过分层次的方式，即依靠底层龙骨级的支撑系统体系、中间层甲板级的平台支持服务或管道级内外连接服务、以及最顶层的面向客户业务场景的各应用程序进行组合但又保持足够深度的集成和协调，从而最终实现石基整个应用平台为酒店客户全线业务运转提供高效、可靠和强劲的支持。
今天，我们将从石基集团自身产品线出发，通过技术战略视角来谈谈石基的云化、平台化和国际化。
云化战略：在云化浪潮中继续领航
应用软件的云化，事实上是将传统产品软件的研发运维和实施服务方式通过云技术来重构实现。SaaS化更多是指软件即服务的新业务模式，从前客户购买的是软件功能或者知识资产的使用权模式，而现在变成了一种按需按时使用功能服务付费的模式。石基选择将产品云化和SaaS化作为当前和未来产品战略上的发展重点，云化战略可以简单描述为：以高开放性、高可用性、高安全性的软件平台产品服务为手段，帮助整个酒店行业的客户构建包括B端和C端在内的全业务场景服务，来最终为酒店企业和酒店消费者输送价值。
在石基集团的众多产品序列中，我从以下四个典型云应用产品组件来着重谈石基在云化应用上的布局：
1、云PMS
酒店应用中最核心的应用就是PMS。那么究竟云PMS和传统的本地部署PMS或者Hosting模式部署PMS的本质区别是什么？我的理解是：
考量云PMS的关键因素
从技术架构层面，对PMS应用平台服务商来讲，云PMS应用程序各个模块功能所需要的存储、计算、网络等系统资源可以根据客户的发展规模按需灵活伸缩；对酒店客户来讲，在使用这些资源之上的业务应用软件本身也像使用水电煤一样，可以按需订阅、使用和付费。
因此，考量云PMS，首先需要看能否满足客户可持续性的业务增长需求以及酒店某些业务原生的波峰波谷特性对系统资源占用的的弹性伸缩要求，而且这种业务增长变化并不是导致资源占用的简单线性增长，而是架构上实现可靠可用性与经济性的完美平衡。
其次还有一点很关键，要辨别整个平台运行是维护多套应用系统实例与多版本相互隔离的应用，还是单应用系统实例、单一可用版本之上的快速线性升级。如果说是前者，那么本质上就跟传统PMS本地分发式部署一样，没有利用到云PMS产品本身快速迭代和资源综合利用等优势，而且这样的模式也必然造成研发和运维团队受累于开发实施维护的高昂代价，因此就无法保证统一的服务水准，难以支撑产品功能快速迭代和满足客户变化多端的业务需求。
Cambridge PMS是目前石基集团里真正按照云架构设计和开发并按照SaaS模式运营服务的应用产品之一；是建立在完全开放的技术架构理念和对酒店业知识深度沉淀的基础上，历时两年多的研究心血；也是石基中国研发团队在融合了中国和亚太市场的中高端酒店的业务运作需求，在产品定位、技术架构、服务理念上多次迭代和升级后的产品。同时Cambridge PMS是一个应用平台型产品，以单平台实例、多酒店租户的形式提供酒店管理核心业务应用功能。在隔离性上，我们同时使用物理存储和应用逻辑两个层次的隔离保证了酒店在业务功能和数据拥有及访问上相互隔离。同时我们维护了单一平台业务实例快速线性升级，持续为客户提供可用的新版本。我们所有的开发和维护，包括权限修复以及接入的更多资源，都能够在第一时间高水准地交付到客户面前。同时，随着客户体量增加以及业务在不同特殊时期的波动特性，Cambridge PMS平台应用的使用资源始终处于自动弹性伸缩的状态，保证对客户应用功能的高性能和高可用，也最大程度降低总拥有成本。
好的产品，需要能够先讲明白，它不能做什么
从功能边界层面：一般来讲，在软件技术领域，一个好的应用产品，或一种技术手段或技术框架，有一个通用的理念：首先说它不是什么，然后再说它是什么。说不清自己做什么不做什么，甚至宣称自己系统是万能的，那基本可断定是不靠谱的产品。我们相信，只有边界清楚才能度量好坏成败，只有专注才能精准交付核心价值。
因此对于Cambridge 云PMS产品，我们定义它为一套部署和运行在云端基础设施平台的、单一平台实例而又快速持续迭代升级，面向中高端酒店按照SaaS模式提供的酒店管理系统软件。在设计功能架构时，相比传统PMS不断臃肿的堆积模块的做法，我们在功能边界上反而做了很多减法，其功能定位理念是把握住酒店运营最基本最核心的诉求并做深做活，然后通过与酒店行业的生态系统接入和开放API平台的方式来实现业务扩展。
API First这个理念不仅是软件开发的构建过程，也是设计软件核心指导思想，因为业务是不断变化的，不同类型客户又有不同的功能、流程甚至用户体验方面的独特诉求，所以要靠简单功能拼凑或来回修改的角度上看，这将是无穷无尽的工作，而我们API First这个理念讲的是把酒店业务涉及的核心对象如Profile,Reservation以及围绕核心对象的各种常规场景行为(Create,Modify,Availability Checking,CI/CO等)进行分层次的抽象化和可消费化，使得任何一次功能迭代都不会触碰底层的破坏性改造而只是重用或者组合，甚至整个应用的用户体验设计和实现（UI/UX）都完全变成灵活的松耦合的或者可配置的。酒店用户或者行业伙伴可以消费这些API按照自己的需求去构建场景和功能。
位于杭州阿里巴巴集团自建自营的未来酒店(Flyzoo Hotel)，可以说就是这方面典型的案例，移动APP, 自助机，机器人、客房智能设备接入等等都是阿里巴巴自己的研发团队基于Cambridge的开放API和阿里生态内部的平台API来进行开发，从终端用户来讲好像根本感觉不到Cambridge的存在，但是灵活好用简单易用的前端应用就是靠强大而灵活的后端和API来支撑的。前端越简单，后端越复杂，这是所有平台型产品的原生本质。
所以，从最终酒店客户的角度来讲，一个PMS必须要做好酒店业务里最核心的功能并能提供足够的灵活性，而其他外围应用部分或者非核心业务场景的部分应该开放给酒店集团自己的研发团队或者酒店选择的行业解决方案提供商，实现合作共赢，这也是酒店信息化行业发展的必然趋势。
其实在石基产品线整体平台化步骤里，为了满足不同组织形态，业务形态和不同业务特性的品牌酒店运营要求，我们在云PMS领域内部，其产品布局也是分层次的，这里值得一提的是石基中国和石基德国两个研发团队也正在研发下一代的Hetras Plus，除了同样坚持云化和开放API 核心理念外，在用户场景构建和功能边界定义方面，完全面向非固定前台的移动端（平板、手机、自助设备等）模式交互，市场定位在全球范围内追求创新的中高星酒店，在与Cambridge重合市场的部分客户里，我们的策略是Cambridge客户全都可以免费升级到Hetras Plus。
另外，还有一个石基重型的核武级别PMS产品也正在同步研发进程中，一个完全按照国际标准规范，国际化团队设计并交付的，专注面向国际大型连锁集团企业级的PMS平台解决方案。 石基在这个PMS领域的资源投放和产品序列规划经过了至少5年的有序准备和实践的，所以Cambridge, Hetras Plus以及国际企业级PMS平台等产品的不断推出，充分体现了石基在宏观战略布局和微观市场细分都是分层次规划并且遵循专注领域+专业团队=交付专业产品的思路。
SHIJIBOX：让集成更容易
例如：在我们开发石基整个云平台的过程中，我们设计开发了SHIJIBOX这个设备，实际上这个设计理念就是将非核心业务功能外置化和抽象化，SHIJIBOX的设计目标是帮助酒店用户在通过云模式使用PMS时，同时满足了PMS等系统与酒店本地设备、第三方非云端本地部署的系统的对接集成需求，比如酒店门锁系统和设备、宽带电话系统设备、智能设备控制系统、酒店本地部署的POS系统等。也就是说，Cambridge PMS是酒店核心业务系统，所有酒店本地的附加应用和设备集成，都可以通过SHIJIBOX这个独立的应用来完成，Cambridge PMS和SHIJIBOX之间都是通过API来松耦合集成的，升级迭代相互不影响。正如之前所述，Cambridge PMS就像一艘主力驱逐舰，而SHIJIBOX则是一艘补给舰或扫雷舰，他们各自的使命和功能设计是完全不同的，充分证明了“专注才能专业”的意义。
虽然相较核心PMS业务系统而言，SHIJIBOX属于边缘的小巧应用，但SHIJIBOX的设计和开发仍耗费了我们团队大量心血：首先设备本身成本要低，可大规模分发；其次硬件要可靠耐用；另外使用和维护管理要简单方便。SHIJIBOX本质上是一个智能硬件盒子，外形为一个手机大小的树莓派设备，盒子本身也是依靠云端技术的，即云端管理配置控制台和本地设备固件程序能够相互通信，来实现设备的云端监控和管理、自动安装和升级、即插即用。作为石基云PMS、云POS等产品外围应用，其设备小巧易操作，酒店现场无需复杂的实施安装配置，插上网线即可使用，内置软件升级和配置数据导入初始化都可自动完成。
目前，借助SHIJIBOX，石基Cambridge PMS已对接了上百种酒店门锁系统，数十种电话或网络计费系统，多种主流本地POS系统，以及石基产品体系内的昆仑Smart Hotel智能应用和第三方房间智能控制系统等。
值得指出的是，如果说酒店使用的PMS不是来自石基云PMS，而是第三方PMS产品（不管是云PMS的还是本地部署的PMS）, 但酒店使用了石基云化产品线体系的POS（下文将有介绍），仍然可以通过SHIJIBOX来实现云POS和PMS的对接。目前SHIJIBOX已成为石基云PMS/云POS对接酒店外围应用的内部默认标准技术方案，这也是体现石基产品线完整性和开放性的一项重要标志。
2、云POS
石基的云POS产品即Infrasys Cloud POS。我们对于云POS产品的定义：首先我们认为一个云POS必须是有清晰定位、有细分市场的。Infrasys Cloud POS专注面向全球范围内的高端酒店和酒店集团以及大型社会餐饮连锁。其底层架构设计和平台功能构成决定了无论是面对一百家、一千家还是一万家酒店客户，其云POS系统都可以满足业务运营要求和总部管理要求指标，并且始终可在云端平滑升级和自动伸缩扩容，保证了连锁企业的规模增长要求。
在这个具有业务终端强交互性、高操作效率的餐饮服务业务场景中，Infrasys Cloud POS拥有架构上云端管理配置平台和终端工作站的松耦合设计，无论是在云端应用还是在本地终端程序，Infrasys Cloud POS都遵循了功能场景化、API开放化，技术实现多样化的设计理念。与云PMS一样，云POS通过开放API为各场景构建前端应用服务，同时不拘泥于某种技术从而灵活选择实现手段，终端应用的快速迭代和分发受控但不受限，云端平台的管理配置和监控日志的审计目的是为让终端应用实现对客服务的业务场景，云端平台不仅支持自己的终端应用，也支持和鼓励合作伙伴甚至客户自主构建特殊场景应用。例如客房点餐服务、酒店早餐控制管理、人脸识别自助服务设备、APP客户自助预订自助点单、Pay@Table、石基OGS餐饮分销和外卖等对接应用等。
目前Infrasys Cloud POS已被数家国际知名酒店集团认证为全球下一代餐饮管理系统，目前正在大规模的部署实施中。
3、云CRS/CRM
云CRS/CRM迭代更新更快更可控，软件价值交付客户的频率和效率也将更高
PMS和POS属于酒店层面日常运营层面的核心应用，而CRS／CRM属于酒店集团总部层面的核心应用。由于酒店集团的核心竞争力本质在于品牌价值、管理标准和资源共享的输出能力，其管理形态和资源控制上必然追求中央化和集中化（而不是以 “世界是平的 “口号形而上地鼓吹的去中心化），所以对集团酒店来讲，不管行业怎么发展，中央预订、分销直销、客户忠诚度管理、大客户管理等从诞生第一天开始就是集中模式运营，而且不管横向来看（中国和世界的比较），还是纵向来看（今天和过去比较），趋势是越来越集中，而不是越来越分散。
石基在此领域的发展思路也充分体现了行业特点对管理软件工具的要求：我们把传统Hosting中央CRS/CRM解决方案升级到云技术平台的SaaS模式CRS/CRM解决方案时，更加强化中央化思路，即管理运营集团中心化、资源配置中心化、渠道打通和渠道管理集中化的特点，同时由于引入云技术的各种优势，使我们的云CRS/CRM在保持开放性和伸缩性方面做得更游刃有余，更吸引人的是，云CRS／CRM迭代更新也更快更可控，软件价值交付客户的频率和效率更高了。
CRS是酒店集团负责分销和直销的产品库存及价格控制中心，也是酒店业务来源入口和场景核心入口。CRM是酒店集团管理围绕客人资料的完整数据信息库和忠诚度管理工具。因此相对来讲，CRS支撑的分销直销预订业务比CRM支撑的客户忠诚度计划业务在对外触点和对接需求上表现得更多、更宽、更扁平，更敏捷，对库存和价格数据分发和预订交互实时性及性能要求也更高。而集团对CRM在客户忠诚度管理所需的客户资料安全性、完整性，数据清理合并的合理化、常态化，以及客户贡献数据的动态性要求很高，包括目前由大数据技术驱动通过各种内部数据和外部多维数据来实现客户标签化管理。
基于这些方面的理解和我们多年构建总部级别应用的实战经验，石基云CRS/CRM在这方面更加强化与酒店生态链和石基产品线体系的协同，特别是对那些处于底层的龙骨级和甲板级支撑平台的石基技术产品采用和集成，如大数据存储和处理技术平台+BI建模和数据可视化技术平台(SDP)，酒店分销通道对接技术平台(SDS), 这两个平台直接在同一个云基础设施平台对云CRS/CRM提供支持，这比以往分布式本地部署的CRS/CRM更稳定，也具有更强悍的计算能力和存储能力以及更可靠的网络带宽。
PMS云化集中化了，还需要集团CRS/CRM么？（或者反过来问这个问题）
云化集中化之后的PMS和CRS/CRM的关系，是一个不得不提的额外话题。好像各种意见都有，争论并没有太大意义。我们的理解是：其实不必关注软件系统名称定义被泛化与否，而是要关注真实业务形态的表现形式和内容，而且既要动态和发展的眼光来看问题，也要基于酒店行业和各细分市场特有的现实性和阶段性来看问题。比如在以国际化、规模化运营并品牌输出管理为核心的高端酒店集团领域是和一个自建和自营的紧凑型扁平化管理小型酒店集团在这个问题上可能完全两种思路。只谈功能场景和业务边界的语境下，最直白通用的理解PMS云化是指它的开发和部署形式在云端，但业务的具体应用场景仍在酒店本地。
同样都是酒店，甚至一个集团内部的不同品牌酒店，由于市场和客户群体定位不同，酒店的服务形态和关注点也不同，高端奢华品牌关注的给客人提供极致尊贵和超值消费体验以及无微不至的人性化优质服务，而精品商务品牌酒店关注的是专业便捷无干扰以及价格适度的舒适服务，而时尚文化主题酒店、综合度假服务酒店等各个特色酒店都有各自对运营流程和执行标准的要求，这就会使得在酒店端的业务场景实现诉求千差万别，集团端和酒店端的业务管理边界和轻重分配是要配合这个诉求的。
酒店集团职能所代表的核心业务如分销直销和客户忠诚度管理，对集中化要求并不是说数据集中了就达到目的了，最终还是要落实到具体的功能场景，事实上管理功能和场景设计本身还是集团做集团的事情，酒店做酒店的事情。企业与企业员工的组织形式和资源管理运营方式的分离就决定了软件工具边界定义的分离，这是管理对技术的要求，不是反过来。应用软件系统设计必须要考虑这一点：技术永远是手段不是目的，技术手段的改变并不是要求业务和组织管理形态产生对应改变，而是要技术主动适应业务可能变成产品形态的改变。从微观上讲，一个软件内部功能模块之间的边界定义和相对隔离也是遵循这种思路，再比如，目前很流行的微服务架构理念也是体现了同样的道理。高内聚，低耦合，今天内聚高到什么程度，明天耦合低到什么程度，一样都必须遵循动态和发展的规律。
因此，定义一款系统是什么和不是什么是最重要的。 软件迭代过程中，重新定义过程总是思想开放和严肃认真的结合。不争论，做实事，常自省，看效果。如果一定要向维基百科查PMS，CRS，CRM的定义然后再去做事，或者直接颠覆改名叫HMS ，那就是另一个范畴的见仁见智的话题了。比如漆哥的神器：“这看起来是一个电吹风，实际上是一个刮胡刀…”
4、大数据和商业智能应用
在石基酒店业务产品线中，Snapshot和ReviewPro是两类关键的酒店数据分析和商业智能应用软件，他们从诞生第一天起就是以云的技术架构和运营、以SaaS商业模式来服务酒店行业客户，都是利用酒店内部/外部的各种数据源（包括结构化数据和非结构化数据）进行数据处理、数据加工和可视化(App)和可消费化(API)，帮助酒店对自身业务的内外部环境状况进行建模分析并提供商业智能决策评估等等。
本身来讲，ReviewPro核心产品ORM和Snapshot并不是数据的产生者，更多是数据聚集者和处理加工者以及提供数据模型产品化应用，当然ReviewPro的GSS、Auto Case Management、Message HUB等产品与酒店核心业务系统在某些业务事件触发机制集成的功能本身也产生围绕客人或者酒店的数据，比如客人满意度反馈，客人通过社交媒体与酒店即时通信记录、特殊事件如客人在线投诉触发的内部服务Case工作流数据等等。
相对来讲，ReviewPro里的数据更多是非结构化客人反馈数据和用户行为数据，属于UGC范畴，需要进行语义分析、关键字分析、Benchmark定义等。而Snapshot则更多是对酒店PMS/POS业务系统产生的关键结构化数据的处理和分析。由于这两个产品从最开始时就是云化运营也具有开放API平台，也就使得上文提到的石基酒店软件产品线内诸如PMS/POS/CRS&CRM等一系列云应用系统与ReviewPro和Snapshot深入紧密的完成集成和对接，同时这也和后面要提到的石基大数据平台，能更好地结合和服务于酒店用户。
平台化：大消费行业应用服务平台运营商
SaaS软件中系统平台的作用，就好比舞台之于演员，航母之于舰载机，其作用是搭建一个安全的、可靠的、可用的、中立的平台，打造支撑空间+外部通道+预警中心，为各种上层业务应用提供基础服务。那么从产品技术的角度来谈，我将石基的平台化战略分为几个层次：
1、云基础设施安全平台(SHIJI Cloud Infrastructure Service)
这是最底层的平台，SHIJI Cloud云技术设施服务，其核心目标是保证各种SaaS业务的底层技术基础设施稳定、可靠和安全。
那么为了实现这个目标：首先，在基础设施服务商选型上，我们不依赖于任何一个云厂商，也不依赖于任何一个硬件厂商，我们根据实际情况选择了全球范围内行业顶尖的基础供应商，包括亚马逊AWS、阿里云、微软Azure。结合全球各地区不同的政策、法律、成本等实际情况和我们应用业务发展程度要求，选用最合适的技术保障合作伙伴或者两个合作伙伴组合。
第二，主动建立并自主管理的综合安全标准体系要求，保证平台符合各项安全指标标准，例如PCI-DSS数据安全标准认证、CSL/GDPR和SOC3等严苛安全认证。
第三，打造内部管理体系，在全球五大区域，我们配置了专业可靠的SOC/NOC团队来保障SHIJI Cloud数千个存储资源、计算资源和网络资源正常服务。通过日复一日的基础设施监控、网络运行监控、应用运营监控，团队积累了长期的实战案例和一线经验，建立了经过验证的工具体系和方法论。
所以说，SHIJI Cloud云基础设施平台主要是由基础设施、安全运维标准和专业团队三者紧密结合而成的，缺一不可，为石基各类SaaS应用软件提供了坚实的基础支撑。
2、云应用运营数据支撑平台(SHIJI Application Performance Monitor)
首先需要提到的是APM，即应用健康监控预警平台。对SaaS业务而言，我们不仅我们自己要云监控基础设施本身，还要运营团队甚至客户自己也能够监控云基础设施之上的真正支撑客户业务的各应用系统的运行状况。
比如说：要监控到在东南亚的某酒店里使用PMS/POS的情况，是否有报错，报了什么错误，API的调用响应速度和流量是否达标，人员操作UI的响应速度和功能使用频率等；要了解某家酒店最近一个月PMS 的移动端使用频率超过了PC端，而且大部分都是Check-in而不是Check-out，又或者是总经理使用移动端的频率大于客房部的使用频率，其原因在于移动报表功能上线后促使总经理使用率提高；还可以监控到华东区域典型的五星级酒店过去一周某渠道的订单请求量和下单成功率陡升或者陡降，未来30天库存和价格配置不合理达到预警线。
目前，APM已经在石基PMS／POS，CRS/CRM，SDS/PNG等各种应用运营团队开放了监控窗口，通过制定不同层次的监控指标，及时获取自身SaaS产品业务运行讯息，从而及时给客户提供更准确的建议和改善措施，保证让客户不仅用得安全可靠，而且用得更精细更有价值。
APM监控平台本身就是云应用生态数据的收集者和生产者，也是加工者。平台的建设目的，除了坚持提供可靠可用的应用软件这个原则外，我们还要让客户使用的软件有温度，有感知，有思想。当业务应用运行产生指标偏离时，不管是业务问题、系统问题还是人的问题，APM都会及时发现并提出更好的解决办法，这是我们业务应用软件本身不断迭代的重要驱动力之一，从这个意义上来说，APM可视为平台业务内部的BI，当然并不是有日志数据就可以称为BI，而是需要专业团队对日志数据进行收集加工，业务行为分析，应用分析以及终端用户场景分析等，以此建立模式和优化应用本身，帮助客户为他们的客人或者上下游提供更加的服务。
3、云应用大数据支撑平台(SHIJI Data Platform)
石基在大数据领域也投入了研究和开发，2016-2017年进行了大数据项目基础研究和个别产品化尝试，2018年初集团成立了跨产品领域的大数据研发中心。我们发现，目前该行业对大数据的实践普遍还停留在数据收集和存储，而真正利用大数据为市场提供产品和服务，进而为行业赋能的大数据公司是很少见到的，有的甚至成为了倒卖数据的平台。
石基在行业大数据战略上是分三步来走：
第一步，建设行业数据聚集和存储支撑平台，因为SaaS应用本身就是应用数据生产者，这一步是天然的存在和必然的过程。
第二步，研发各种具有垂直业务倾向性的计算分析模型和可视化工具，即面向客房、餐饮、直销分销、支付、客户忠诚度等业务范畴的BI&ER工具，让客户不仅限于集中存储数据，还能利用数据得出对业务有意义的结论和决策支持。
第三步，AI人工智能的引入，通过把数据科学家和算法工程师在平台内的分工合作，充分利用石基本身大规模的数据存储能力、行业领先的计算能力以及长期积累的行业分析建模能力，不断迭代各种高阶分析模型和深度学习方法，再反哺我们的应用软件、客户以及促进行业的发展。
举一个直观的例子：如何分析得出在正常情况下，北京CBD地区一家街边咖啡店，在夏季的周末需要为什么样消费水平的群体准备什么价位和品类的菜单。再比如，如何分析阿布扎比的某五星级酒店在面对来自中国OTA渠道的商务客人，应该制定怎样的客房和餐饮(比如周末酒吧消费)促销打包价格才最合理。这要求算法的数据不仅包含业务数据、行业数据，还有公共数据，例如天气、温度、人均收入、汇率、出生率、人口、宗教分布、大事件等等，公共数据采集可以通过数据联盟实现。广泛的数据来源可保证数据的宽度和深度，然后在此基础上建立分析模型和算法，支撑数据分析，同时还通过深度学习，不断自动调整预测模型、分析模型和实施模型。
除公共数据之外，大数据平台主要有两类数据：一类是内部数据，应用数据经过规范处理之后的脱敏数据或者聚合统计数据。第二类是外部数据，比如用户行为统计数据，会通过与合作伙伴共享数据实现，比如说某个小区消费者在周边叫外卖的数据统计；或某个地区的酒吧数量和平均消费水平。任何一个行业大数据发展的最终目的是要将数据模型进行服务化输出，为行业赋能。在整个AI引入酒店行业的过程中，当然会遇到多重挑战，一方面有在技术研发投资上的难度，也有追风赶时髦而人工智能被庸俗化走歪的风险，同时还有行业客户的认知接和受过程的挑战。石基对此既有清醒认识，又有清晰目标和可靠实力。
谈及石基大数据战略的落地情况：我们已完成了第一步基础搭建，数据在持续快速增长；其次，在各垂直业务应用之上构建BI/ER工具处于正在进行中，目前石基大数据平台正在支持餐饮领域Infrasys Cloud POS的BI/ER的开发，对第二阶段六个业务应用领域支持也都已经启动，并都已经安排好路线图。
4、云应用通道连接平台(SHIJI Cloud Application Connectivity)
在金融行业，资金发生流动才能产生价值。而在B2B的 SaaS领域，数据也只有流动才能产生价值。在酒店行业有两类数据的流动场景是最广泛的也是相对高频的：一是分销领域，另一个是支付领域。前者是消费者与酒店产品结合产生订单的场景，后者是消费者对酒店产品最终完成消费的支付场景。这两者本身还会有大量重合场景和先后关系，特别是过去5年的变化，重叠得眼花缭乱。
既然有数据流动，就一定需要有数据流动的管道。在这个领域石基拥有两类大家非常熟悉的通道型业务平台：石基分销业务平台(畅联SDS)和石基支付业务平台(Shiji Payment Service)。石基畅联负责分销上下游的产品和订单的连接，左手是酒店客户，右手是各种OTA分销和直销渠道； 石基支付负责上下游支付交易的连接，左手是酒店和餐厅等各业务应用系统，右手是各支付公司，比如微信、支付宝、银行等第三方体系。两个连接通道都是将酒店业务和外部进行可靠安全的打通，因此它们也是石基大消费生态技术平台两个关键的上层业务。通道型业务为了更好地体现价值，需要做得更有温度、更智能。例如石基畅联，当监测到在某个地区某个渠道的访问量和成功率出现异常时，系统不仅可以自动预警，还可以根据具体原因，自动调整产品库存信息的智能刷新频率。
总的来说，平台的使命是为石基核心上层应用(PMS/POS/CRS/CRM)构建底层基础支撑、运营业务支撑的和通道连接支撑，并不是孤立存在和发展的。
国际化战略：放眼全球，拥抱星辰大海
石基的国际化战略是坚实而且稳健的。从技术和产品上来讲，国际化首先是团队和人才的融合，我们不仅要将国际上的卓越产品带到中国来，还要将石基的优秀产品推广到全球去。其次，服务的国际化和产品的国际化是一脉相承的。我们的集团技术架构团队、研发管理团队、安全审计团队、支持服务团队都是由中国、亚太、欧洲、北美多个区域的人才构成的，这使得石基在品牌推广、市场销售和运营服务上能够很好地与当地文化和客户真正地融合，也能够在产品功能设计和技术架构、研发管理上保持足够的领先和国际化视角。
比如说，Cambridge PMS从一开始就是由欧洲团队给中国研发团队提供了大量技术支持，Hetras Plus本身就是中国和德国两个团队共同研发的，而Cambridge产品在各地区的落地和实施服务也是欧洲、亚太、中国三个团队有层次配合的结果。SHIJIBOX产品的设计和开发以及运维更是如此，目前SHIJIBOX已经在中国、欧洲、亚洲三地都成功落地部署，并且服务的产品不限于石基生态体系下的产品。Infrasys Cloud POS产品已在欧洲和美国相继落地，由于软件产品在欧洲落地需要符合大量的Fiscal/Legal方面的合规要求以及传统生态大型集团系统的对接要求，因此从专业顾问公司的引入需求收集管理、产品架构设计和最终的代码开发，我们是依靠欧洲、美国、中国（香港）三个团队共同合作完成的。
在石基，产品开发和技术架构设计从来不是各个团队的闭门造车。我们在2015年成立了石基技术架构顾问委员会 (STAC)，来自全球的委员会成员每半年会聚集在一起进行集中交流，随着石基集团规模的扩大，这个STAC的成员构成也越来越多样化、国际化。另外在日常工作中，不仅有技术路线图和产品路线图的沟通协同，还有即时项目上的沟通和专案沟通，比如石基大数据平台项目就是经过STAC核心成员进行初步研究和内部案例分析后立项启动的。
总之，石基的国际化是人才和团队的国际化引导了产品的国际化，进而促使了销售和服务的国际化。在此战略上，石基的步伐是清晰稳健而又迅速有力的。
