四、集团型连锁酒店运营模式

　　比会员卡管理再高一级的连锁型酒店，就是集团型的运营模式。注意，笔者这里只是从管理的角度来讲，并不是代表法律意义上的集团控制。相比会员卡管理而言，集团型运营的连锁酒店，总部对各个门店的管理级别可能会比较高。如像速八等商务连锁型酒店，其定价权在与总部，而不在于各个门店。至少各个门店如果自行调整价格，需要有总部的审批。如不少商务型酒店，其在全国的价格是同一的。还有不少酒店，其在各个地区的价格是统一的。为了加强管理，总部会对各个门店的数据要求提出比较高的标准。如各个门店不能够私自更改价格，只有总部或者地区一级的价格部门才能够更改价格或者折扣率。以避免同一个地区之间的恶性竞争。

　　还有一种情况就是真的具有集团运作的背景。如外婆家连锁型酒店，其采用的是直营的方式。各个地区的外婆家虽然都有独立的法人身份，但是同属于一个集团。从信息化管理的角度讲，就会设计到财务报表的合并要求。其实类似的对于信息化管理的要求，最终大部分要求都是直接反映在数据库上的。

　　1、集团型运营模式的连锁酒店，一般情况下不会在各个门店设置单独的数据库。如此的话，数据比较难以控制。最多只是在门店设置一个数据的缓冲区。以免因为网络堵塞造成不必要的麻烦。集团总部往往是在一个地区设置一个数据库。如可能将这台数据库服务器委托给当地的电信部门托管。然后各个门店的管理系统直接连接到地区一级的数据库，进行数据的交互。每隔一定时间，如每隔4个小时，地区一级的数据库会将数据与总部之间的数据进行交互。可见，在集团型运作模式下，其数据库的选型主要是集中在地区一级和总部一级。为了提高数据交互的效率，通常情况下，地区一级的数据库产品与集团总部的数据库是相通的。这主要是因为其不但要保障数据的即时性，同时也需要考虑数据的安全性。如总部的数据库与地区一级的数据库除了数据同步的需要之外，还肩负着“冗余备份”的要求。如华东区的数据库如果出现问题，那么华东区下面各个门店的管理系统会自动连接到华北区或者总部的数据库管理系统。对于用户来说，这个切换的过程是透明的。同时因为以前有冗余备分，所以华北区数据库中的数据与华东区数据库中的数据其实是相同的(可能有一定的时间差，这主要看其数据同步的频率)。从而最大程度的降低因为华东区数据库的崩溃，给其下面各个门店带来的负面影响。

　　2、要能够满足兼并的需要。集团型的连锁酒店，有不少是通过兼并来扩展市场的。而很少像外婆家那样，通过直营方式来拓展市场份额。因为后者不仅拓展的速度慢，而且对于企业的资金有比较高的要求。通过兼并来扩展市场，就会碰到不同管理系统之间的整合问题。如集团A兼并了另外一个连锁型酒店B。此时连锁型酒店B往往有自己的管理系统。出于平滑过渡的需要，在短时间内是不会更换连锁型酒店B的管理系统的。这就要求数据库能够支持这种兼并的需要。通常情况下，一般是集团公司采用一些平台工具，将连锁型酒店B中的数据抽取出来，再放到他们自己的数据库中去，进行统一的分析，包括报表的集成。当然，这么操作有一个前期，即这个平台与对方所使用的数据库要能够整合。利用专业的术语来说，要有数据库的接口，如ODBC等等。否则的话，就很难抽取数据。

　　其实对于集团型的连锁型企业来说，数据库的选型还是比较简单的。这主要是因为其选择的范围比较窄。如只有Oracle、DB2等几个有限的数据库可供选择。再说集团型的连锁酒店，其资金并不是大问题。为此他们更多的是考虑性能、安全性与稳定性。所以选型相对来说，比起上面两种情况，会更加的简单。

        总结

　　最后笔者需要强调一点。随着云计算平台的普及，数据库及应用软件开始走向SaaS的模式。即作为企业一方，并不需要关注到底其实用的是什么数据库系统。因为数据库以及信息化管理系统被人已经搭建好，连锁型酒店只要看着合适直接租过来用即可。做一个形象的比喻。在云计算平台下，企业不用自己造房子、也不用装修房子，而是直接租房子。最多就只是买些家具就可以拿来使用了。简单的说，就是服务提供商已经搭建起了一个平台(数据库选型、配置和应用软件的部署等工作在这个平台上已经实现)。连锁型酒店只需要在这个平台上，进行一些简单的个性化配置即可。这也就是说，数据库的选型等工作将交给专业的团队来完成。不需要由企业去关心。