应《网络安全法》要求，自2017年10月1日起，未进行实名认证将不得使用互联网跟帖服务。为保障您的帐号能够正常使用，请尽快对帐号进行手机号验证，感谢您的理解与支持！

24小时热门版块排行榜    

小木虫论坛-学术科研互动平台» 网络生活区» 有奖问答 » 有奖问答完结子版 » 有关酒店连锁经营的分析，要具体的哦、、、、
31/1返回列表
查看: 951  |  回复: 2
只看楼主 @他人 存档 新回复提醒 (忽略) 收藏    在APP中查看

风忧

银虫 (初入文坛)

[求助] 有关酒店连锁经营的分析，要具体的哦、、、、

有关连锁经营的，最好是有关外婆家的，没有也无妨，只要有细致的内容即可，谢谢！！！！！
回复此楼

» 猜你喜欢

» 本主题相关价值贴推荐，对您同样有帮助:
1楼 2012-04-08 21:46:15
已阅   关注TA 给TA发消息 送TA红花 TA的回帖

ljpassport

铜虫 (正式写手)

【答案】应助回帖

您好 不明白最好是关于外婆家的是什么意思，但是可以小分析一下。
首先，连锁连锁经营的优点是宣传上可以起到花一个钱宣传多家店的作用。
其次，不知道您所说的连锁经营是加盟还是自己的分店，加盟的话收取加盟费用后的营业额是与您没有直接联系的。所以生意的好坏是由加盟制控制的。
再次，作为连锁的话，前期的投入是很大的，而其作为一个起步的企业，对于连锁加盟社会认可度是很低的，这个应该有同感吧，很多店动不动就是全国连锁，其实就一家。
最后，连锁加盟的话宣传力度特别大，可能你的宣传费用可以在另一个地方开一家新店。
就这些吧，不是专业的只是朋友做加盟连锁的，小认识上不了台面。
赞一下 回复此楼
2楼2012-04-08 22:20:17
已阅   关注TA 给TA发消息 送TA红花 TA的回帖

xinmor

至尊木虫 (职业作家)

优秀版主

【答案】应助回帖

参考：https://tech.hexun.com/2011-09-07/133171179.html

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

连锁酒店因为其成本、市场竞争等优势，迅速扩张，逐渐形成了与传统酒店相抗衡的局面。确实，连锁酒店行业，比起传统酒店，在运行的成本、市场认可度等方面具有很大的优势。从管理成本与管理效率的角度考虑，信息化的应用在这里起着很重要的角色。当然，任何一个信息化系统，后台都离不开数据库的支持。在这篇文章中，笔者会结合实际的项目经验，谈谈在连锁酒店行业中，该如何选择数据库。

　　一、连锁酒店运行的业务模式

　　在谈到数据库选型之前，笔者需要先介绍一下连锁型酒店其主要的业务模式。因为后续数据库的选型就是根据业务模式来展开的。总的来说，其连锁型酒店运营主要有三种模式：集团式运营、会员卡式运营和独立性运营。不同的业务模式，对于信息化的要求是不同的。所以对于后台数据库的选型，也有很大的差异。在后续的分析中，笔者将结合不同业务模式的特点，针对性的提出数据库选型的要点。希望这些内容，能够对各位读者有所帮助。

　　二、独立性运营连锁型酒店的数据库选型要点

　　独立性运营的连锁酒店，其实只是花钱买了一块牌子。当然，有时候也会引进一套管理方法，包括信息化管理软件。独立性运营的连锁酒店，其核心的特点就是，无论从业务上，还是财务上，与总部都是独立的。如具有独立的法人资格、有独立的定价权、总部不用在线查看酒店的财务状况等等。由于其业务特性的不同，反映在信息化管理软件，也有不同的要求。各个连锁型酒店的管理系统，基本上不需要进行数据的同步。酒店总部也不需要在线查询酒店的运营状况。再某些情况下，这种业务模式下的连锁型酒店，可能需要根据业务量，给总部一定比例的提成。此时也只是每个星期或者每个月，给总部一个财务报表即可。此时一般的做法是，连锁型酒店的财务人员，按一定的周期从系统中拉出一张报表，然后发送给总部。由于各个连锁型酒店使用的是相同的信息化管理系统，报表导出的格式是相同的。在总部可以很方便的将他们导入系统，进行业务分析和费用的计算。
这种业务模式的示意图如上图所示。各个连锁型酒店的信息化管理系统相互独立。彼此之间不需要进行数据的同步。针对这种情况，笔者给出的数据库选型意见如下：

　　1、开源、免费的数据库。

　　以降低成本、提高数据库的稳定性。针对某个特定的连锁企业，一般只需要一台数据库服务器即可，即没有分布式部署的需要。为此根据笔者的经验，认为开源的免费的数据库已经够用了。如MySQL等等，已经可以满足日常工作的需要。这些开源的数据库，不仅免费。而且因为开源，其稳定性也比较高。可以帮助连锁型企业降低信息化管理的成本。其实做技术的人都知道，一般黑客等进行攻击，都有一定的目的性。如喜欢攻击那些商业性的软件。像微软的操作系统等等。但是对于一些开源的系统，往往不会进行攻击。这有多方面的原因。如使用范围比较窄、出于对支持开源的技术人员的尊重(其实很多黑客本身可能就是开源圈子里的人)、没有利益可图等等。所以开源的软件，包括操作系统、数据库管理系统等等，比起商业软件来说，安全性都是比较高的。以MySQL和SQL Server为例，前者的安全性与稳定性比后者要高。

　　2、方便管理。

　　众所周知，连锁型企业出于成本的考虑，往往不会单独设置信息化团队。其信息化实力是比较薄弱的。根据笔者的经验，这种独立运营的连锁酒店，一般都没有专业的数据库管理员。其信息化的日常运维也往往是外包给其他公司来做。在这种情况下，数据库的选型就需要考虑维护成本的问题。选择的数据库应该是比较容易维护的。笔者企业的一部分客户就是这种独立运营的连锁型酒店。笔者给他们配套的数据库一般都是小型的数据库，可以直接嵌入到应用程序中的。简单的说，这个数据库可能只是应用程序中的一个文件。在应用程序安装过程中，会直接安装并进行相关的配置，而不需要单独安装。相关的维护工作，如数据备份、数据恢复等等，都是在应用程序界面上直接完成，而不需要在数据库中进行维护。对于用户来说，这个数据库就好像是不存在的。
　3、跨平台的考虑。

　　独立运营的连锁型酒店，总部对于其的控制力量是比较薄弱的。从信息化上考虑，其最多只提供一套信息化管理系统。至于其硬件的投资、操作系统的使用等等都没有限制。如笔者以前遇到过一个连锁型酒店的客户，其下面各个酒店，在操作系统上有使用微软的，也有使用Linux或者CentOS操作系统的。有的酒店为了充面子，给前台使用的还是苹果的电脑与操作系统。由于缺乏统一的采购与控制，导致各个酒店所使用的操作系统与硬件平台各有不同。这对于信息化管理软件来说，也提出了一个很大的条件。其中对于数据库来说，就要求其能够支持不同的操作系统平台。如至少要在微软、Linux、苹果等操作系统内核上，都可以使用。否则的话，就可能会对一些连锁型酒店造成不利的影响。

　　总之对于这种独立性比较高的连锁型企业，对于数据库的技术要求是比较低的。并不要求有分布式部署、数据库冗余、数据同步等高级的功能。其核心的需求就是稳定、维护方便、成本低廉、易于使用。为此笔者推荐使用开源的数据库系统。甚至就是文件数据库，可以很好的与应用系统进行整合。数据库对于用户来说，是透明的。
三、会员卡管理的连锁型酒店

　　通过会员卡充值、然后消费，这种连锁型酒店的运营模式也越来越普遍。因为通过会员卡消费，可以吸引很多回头客。而且在促销方案的管理上，也非常的方便，如充1000元实际消费1200元等活动。在实际工作中，会员卡的消费又可以分为三种情况。一种情况是哪里办卡、哪里消费的情形。如在酒店A充的值，只能够在酒店A消费。这种情形由于不能够对客户带来很大的吸引力，所以现在使用的比较少。第二种情况是在某个地区内通用。如在浙江地区内的所有连锁型酒店，会员卡内的金额可以通用。这第一种情形稍微好一点，扩大了使用的范围。但是其地区限制还是比较严重。如在浙江办的会员卡并冲值，但是到广州去出差就不能够使用了。所以这种情形在实际项目中也逐渐在淘汰。最后一种情况是全国通用。简单的说，只要在国内任何一家连锁型酒店办的会员卡，在国内其它的同品牌的连锁型酒店，都可以进行消费或者冲值。这种情形由于没有地域的限制，很受经常需要出差人员的欢迎。而且现在不少的企业，为了加强对出差人员的管理，都是以企业的名义办会员卡的。其市场的效益正在不断的显现出来。

　　这种会员卡消费的模式，对于信息化系统也提出了比较高的要求。简单的说，其在酒店A进行会员卡冲值，在酒店B中要能够马上体现出来。这酒店A与酒店B可能在同一个城市，也有可能天南地北，一个在北京、一个在广州。可见，会员卡的管理模式，对各个酒店的信息化系统之间的协作提出了比较高的要求。并且随着第三方支付平台的普及，用户也可以通过第三方支付平台，直接往会员卡中冲值。这就好像通过支付宝给手机冲值一样，对于数据的即时性会有比较高的要求。其实这种即时性的要求，最终是体现在对数据库的要求。如下图所示，是对会员卡管理模式数据库架构的示意图。针对会员卡消费模式的连锁型酒店，笔者提出如下的选型意见。
　1、对数据的同步有一定的要求。

　　由于会员卡冲值与消费的存在，对于数据库的数据同步有一定的要求。这里需要注意，笔者用了一个限定词“一定”。简单的说，其数据的同步往往只限于“会员卡”的冲值消费记录。由于这种运营模式的连锁性酒店，总部对于下面各个酒店的管理权利还是非常有效的。如下面各个酒店，可能有独立的定价权，或者独立的促销活动。会员卡在这里，可能只是起到一个“银行卡”的刷卡作用，而不不是代表总部对下面各个酒店就有很高的控制权限。针对这个特点，就要求各个酒店的数据库与总部的数据库有对接的要求，但是由于其数据量的传输是比较小的，所以对于数据库的性能要求并不是很大。如只需要酒店与总部的数据库数据能够对接，而对于如何进行对接、双方的数据库品牌并没有很高的限制。笔者以前做过一个项目。其总部使用的是Oracle数据库系统，而下面各个门店则使用的是MySQL数据库。这就好像长江与各个支流之间的关系。长江就好像是总部，其吞吐能力要比较大。不仅要有“海量”，能够迅速的将数据注入到各个门店的数据库中。而且还要有“度量”，各个门店的数据在短时间内汇集到总部的数据库，要能够迅速的作出反应。从这个分析中可以看出，会员卡消费的连锁型酒店，对于总部的数据库要求比较高，但是对于各个门店的数据库要求还是比较低的。为此门店从部署的成本考虑，没有必要选择与总部相同的数据库系统。

　　2、不同品牌数据库的兼容性。

　　在第一点说过，会员卡消费的连锁型酒店，从经济效益的角度考虑，并不需要追求门店与总部数据库的统一。毕竟总部一般是使用Oracle等大型的数据库系统，而门店一般都是使用小型的、甚至是免费的数据库。而另外一方面，门店的数据库系统与总部的数据库系统之间又要进行一定量的数据交换，虽然说这个量并不是很大。这对于门店的数据库系统也提出了一定的要求。至少要求门店的数据库系统，能够与总部的数据库系统相互兼容。在实际项目中，一般会采取两种方式。一是对数据库提出比较苛刻的要求，即两者要求完全的兼容。如两个数据库全部采用国家通用的字符编码格式，并且在数据库设计过程中，也遵循相同的规则。一般采取这种方式的企业，都是在加盟的同时提供信息化管理软件。并且这个信息化管理软件，是集团统一进行设计开发的。只有如此，才能够具有相同的设计规格。另外一种方式，就是采取中间件的方式。如集团的数据库与门店的数据库可以有不兼容的规则。不过无论是从总部发出数据，还是从门店发出数据，都需要有一个转换的过程。如总部在接受门店的数据时，需要有一个转换的过程。如将精度的转换等等。然后再更新数据库中的数据。由于中间多了一个转换的过程，就可能导致数据的丢失。笔者是比较倾向于第一种处理方式。当然这个处理方式对于数据库的选型提出了一定的要求。至少两个数据库，都要能够支持国际化标准。如此的话，就可能将一些文件型的小型数据库排除在外。
四、集团型连锁酒店运营模式

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

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

[ Last edited by xinmor on 2012-4-9 at 15:50 ]
赞一下 回复此楼
一切恩爱会,无常难得久.生世多畏惧,命危于晨露。
3楼2012-04-09 15:48:04
已阅   关注TA 给TA发消息 送TA红花 TA的回帖
相关版块跳转 我要订阅楼主 风忧 的主题更新
31/1返回列表
信息提示
关闭
请填处理意见
关闭