基于WEB的酒店前台管理信息系统1Word格式.docx

基于WEB的酒店前台管理信息系统1Word格式.docx

《基于WEB的酒店前台管理信息系统1Word格式.docx》由会员分享，可在线阅读，更多相关《基于WEB的酒店前台管理信息系统1Word格式.docx（21页珍藏版）》请在冰豆网上搜索。

（6）数据的安全性：

不同用户有对数据查看，修改等处理不同的权限。

（7）打印退宿报表、结帐报表等报表。

1.1.3用户功能需求

（1）密码设置：

每个用户均有自己的密码，能够防止非本系统人员进入本系统；

又因每个用户的权限不一致，故可防止用户越权操作。

（2）权限设置：

设置每个用户的权限，使各用户在自己的操作范畴内工作，不得超出自己的操作范畴。

只有系统治理员才能进行权限设置。

（3）数据输入：

能够进行酒店各种原始数据的输入。

（4）数据查询：

要求能够分别按房间编号，房间类型等进行数据查询。

（5）数据输出：

按照需要打印退宿报表、结帐报表等报表

（6）其它要求：

能够修改用户密码，有系统的关心文件。

1.2可行性研究

酒店行业的进展差不多达到一定程度，然而有关的基于B/C模式的治理系统软件尚未达到与之习惯的程度，同时，在开发过程中，我们为了尽量给用户以方便，考虑到用户需求的实际情形，建立较为简单易明的系统服务，开发此系统不管在经济上，操作上，依旧在技术上差不多上可行的。

具体的功能研究如下：

1.2.1经济层面

（1）必要性。

如果不采纳该治理信息系统，其业务过程中所产生的数据将得不到及时、有效的储备和处理，显得比较杂乱无章，难以分析、归纳和比较，阻碍企业的治理和决策，造成企业效率低下，白费人力资源、时刻和金钞票！

（2）有益性。

以较低成本开发出来的治理信息系统将整个业务流程数据进行系统的整合治理，从而能够有效地提升企业内外的信息沟通效率，节约大量的人力、时刻和金钞票，从而降低成本，加快业务流程，提升企业效益，给企业带来庞大的经济回报！

（3）可能性。

本系统的开发成本少，时刻短，无需投入太多的人力、物力和财力，完全能够以最短的时刻、最少的人力和最低的成本开发出该系统。

1.2.2技术层面

该酒店从事酒店业务已有十年，其职员本身就对电脑设备和操作有一定的认识，该系统简单，不用过多培训。

该公司也拥有充足的电脑设备作为实施该治理信息系统的硬件，且所有的运算机装有Window98操作系统，两套完整的服务器以及装有Window2000的操作系统，本人开发的基于B/S模式的酒店客房治理信息系统能，有良好的兼容性和易于在该操作系统实现，针对该公司业务流程相对简单和清晰明了的特点，完全能够开发出适合该公司应用的治理信息系统平台。

1.2.3社会层面

如果不采纳该系统，将会给公司的内外沟通造成严峻的障碍，不利于公司的客户关系治理和企业文化的形成，在社会上也会造成一定的阻碍！

（2）可能性。

由于该系统能以较低的成本，较短的时刻开发出来，且能极大地提升企业的效率，便于公司治理，必定能得到宽敞职员和公司领导的支持。

但不容忽视的是由于新系统的投入使用会造成职员的不习惯，必定会引起这些职员的抵触。

因此公司要做好这些职员的工作。

（3）有益性。

由于该系统能极大地提升企业的效率和效益，从而能提升客户和职员的中意度，进而在社会上形成一定的声誉。

从以上可行性分析可知，该系统开发具备技术上、经济上和社会上的可行性。

1.3开发目标

按照现状分析，用户需求分析和可行性分析，设置本系统的开发目标，其目标如下：

（1）建立一套功能完整、高效、安全、稳固的酒店前台治理信息系统。

（2）系统能够对职员日常操作进行快速、安全地反映。

（3）实现对预订、入住、退宿、调房、房态设置等信息的方便迅速录入、查询及治理，了解酒店日常业务的有关信息。

（4）界面简洁、操作方便、简单易学，用户不需要有太多的专业知识。

（5）能够方便用户、酒店治理人员通过内部网或外部网了解有关信息。

1.4现状调查

1.4.1组织架构

该酒店属于典型的国有企业，其组织架构是直线职能制，最顶层的是总经理，在总经理的管辖下的各科室完成日常的事务，其各科室有副经理，行政室，人事部，工程部，修理部，客房部，前厅部，娱乐部，餐饮部，消防部，财务部，采购部，商务中心，总台等，副经理要紧协助总经理，分别治理各部门；

行政室负责日常的行政工作，公布通知和消息；

人事部负责日常的人事调动，绩效考核，工资设置等；

工程部负责酒店的装修，重建和扩建等；

修理部负责酒店各种设备的修理工作；

客房部负责客房的治理，房间的清理和整理；

前厅部负责酒店的预订、接待和日常结账等工作；

娱乐部负责日常的娱乐治理工作；

餐饮部为酒店客人提供就餐和酒水服务；

消防部负责酒店的消防工作；

财务部负责酒店日常的会计审核，会计出纳等；

采购部购置酒店日常之需，为酒店提供充足的物品；

商务中心提供复印、打印和咨询等工作。

其组织结构图如图1-1：

图1-1组织结构图

1.4.2工作现状调查

酒店前台日常的业务有客房预订，接待，客人结账，调房登记，客人挂账等，所用的有关单据票证报表有预订登记表，住宿登记表，结账单，调房单等原始资料。

（如下图）

图1-2住宿单

图1-3客房价目单

图1-4预订登记单

图1-5调房登记单

图1-6退宿报表

1.5业务流程分析

本系统所涉及的要紧业务是客房治理，预订治理，接待治理，调房治理和结账治理，各个部分的业务流程具体如下：

（1）客房治理：

同意职员的客房信息单，审核信息单，若正确无误，则对客房信息登记，记录到总帐。

（2）预订治理：

客户查找是否有合适房间，若有则填写预订登记单，职员审核登记单，若正确无误，则对预订登记，产生预订登记表。

（3）接待治理：

职员查找客户是否提早预订，若有则填写入住登记单，职员审核登记单，若正确无误，则对入住登记，客人入住；

若没有提早预订，则查找是否有合适房间，若有则填写入住登记单，职员审核登记单，若正确无误，则对入住登记，客人入住；

客人退宿，职员清点房间，若客人结账，则职员进行接待登记，并填写收据和打印报表给客户。

若客人打算挂账，则填写挂账登记单，职员审核登记单，若正确无误，则对挂账登记，产生挂账登记单。

（4）调房治理：

按照客户的需要，职员查找同等类型的房间，若有则填写调房登记单，职员审核登记单，若正确无误，则对修改客房信息表和入住登记表。

（5）结账治理：

客人到前台对挂账进行结账，职员进行结账登记，并并填写收据和打印报表给客户。

具体的业务流程图如下：

图1-7业务流程图

1.6系统功能分析

酒店前台治理信息系统的要紧功能有预订、接待、结账、调房服务、客房治理和查询服务等。

每个功能模块都和来宾直截了当有关，其采纳酒店治理信息系统的目的是提升就店服务的质量，提升信息治理的精度，进而提升酒店在客户心目中的信誉，树立良好的酒店服务形象。

各子功能分析如下：

（1）预订功能需求：

其要紧目的是提升酒店的开房率，为客人预留房间，并提供良好的预订服务。

其功能需求包括预订查询，可用房确认，预订记录建立，预订确认，预订记录爱护等；

（2）接待功能需求：

其要紧目的是以最快的速度为客人开房。

其功能需求包括来宾登记、可用房确认、修改来宾信息、删除来宾信息和查询来宾信息等；

（3）结账功能需求：

其功能需求包括客人结账、打印报表和客人挂账等；

（4）调房功能需求：

其要紧目的是满足客人调房的需要。

其要紧功能是查询客房，调房登记，调房确认等；

（5）客房治理功能需求：

其要紧目的是对客房的信息化治理，提升客房治理的精度和准确度，同时减轻酒店客房中心职员的工作负担，从而提升客房治理的效率和服务质量。

其要紧功能是房态爱护，费用记录和客人查询等；

（6）查询功能需求：

其要紧目的是满足客人的需要，快速查找相应的房间和信息，提升服务的效率和树立酒店良好的企业形象。

其要紧功能包括房态查询，房间类型查询和房间价格查询等；

酒店客房治理信息系统的功能图如下：

图1-8系统功能图

1.7数据流程图分析

按照业务流程图，画出顶层图、0层图和第一层图

图1-9酒店前台治理信息系统顶层图

图1-10酒店前台治理信息系统的0层DFD

图1-11预订治理第一层图

图1-12接待治理第一层图

1.8目标分析

1.8.1事项分析

在酒店前台治理中，客人的入住登记单、挂账登记单、结账报表、发票、预定登记单、客房信息单、客房类型单和职员登记表等资料都能够成为数据项。

各资料的数据项列举如下：

预定登记单：

姓名、联系电话、工作单位、房间号、预定日期、预定天数、押金、预住人数、备注、日期、预订服务员和时刻

入住登记单：

凭证号码、姓名、性别、年龄、证件名称、证件号码、房间号、工作单位、住宿日期、预住天数、退宿日期、备注、日期、来宿服务员、退宿服务员

退宿登记单：

凭证号码、姓名、房间号、住宿日期、住宿时刻、实际宿费、结款方式、折扣、应收宿费、金额总计、押金、退还宿费、退宿日期、退宿时刻、备注、操作员

挂账登记单：

日期、挂账单位、摘要、住宿金额、欠款金额、还款金额、金额累计、姓名、证件名称、证件号码、凭证号码、时刻、是否结清

客房信息单：

房间号、类型编号、房态、配置、使用设置、营业时刻、备注

客房类型单：

类型编号、客房类型、价格、备注

职员登记表：

职员编号、职员姓名、职员性别、职员类别、职务、聘用日期、薪金、备注

汇总所有数据项，去掉重复。

数据项的汇总如下：

在登记单中，实际宿费可由房间价格和住宿天数导出，应收宿费可由实际宿费和折扣导出，所有这些是导出项，不作差不多项。

在退房单中，住宿天数可由退宿日期和住宿日期导出，实际宿费可由房间价格和住宿天数导出，应收宿费可由实际宿费和折扣导出，金额总计可由应收宿费、杂费、电话费、会议费、存车费和赔偿费导出，所有这些是导出项，不作差不多项。

从酒店客房治理信息系统的业务流程图中找出有关单证、票据、账簿、报表、文档等原始资料，从原始资料中抽出系统要储存使用的有关事项，按照上面的分析，去掉组合项、导出项、泛指项，得到如下差不多项：

1.9初始设计

1.9.1初始局部E-R图

按照对上面差不多项的分析构思E-R图的差不多原则：

原则1：

操作员（职员）、客房、客房类型等能独立存在的事物，当其有多个由差不多项描述的特性需要关注时，就应把作为实体。

原则2：

两个或多个实体间的关联与结合，如预订、查询、登记入住、客房信息、客房类型、结账等，当需要关注时，应作为联系。

原则3：

实体的属性是实体的本质特点，实体应有标识属性（能把不同个体区分开来的属性组），并指定其中一个作为主标识，如证件号码、凭证号码、单位编号、房间号、类型编号、职员编号等。

联系的属性是联系的结果或状态。

属性具有如下几个特点：

非多值性、非复合性、非导出性，而实体属性还应有非关联性。

原则4：

所有差不多项在同一E-R图中作为属性要在且仅在一个地点显现，即一事一地原则。

图1-13预定登记的初始局部E-R图

图1-14入住登记的初始局部E-R图

图1-15退宿登记的初始局部E-R图

图1-16挂账登记的初始局部E-R图

图1-17查询登记的初始局部E-R图

图1-18房间所属的初始局部E-R图

图1-19系统全局ER图差不多结构

1.9.2初始局部E-R图的改进

图1-20引进联系实体后的预订E-R子图

图1-21引进联系实体后的入住E-R子图

图1-22引进联系实体后的退宿E-R子图

图1-23引进联系实体后的挂账E-R子图

图1-24引进联系实体后的查询E-R子图

图1-25引进联系实体后的房间所属E-R子图

图1-26引进联系实体后的全局E-R子图

1.9.3由E-R图导出一样关系模型

A差不多原则

E-R图中的每一个独立实体变换为一个关系，其属性变为关系的属性，其主标识变为关系的主码。

如本系统中，独立实体“客房”、“职员”分别变换为旅客关系、前台关系如下：

客房（房间号、类型编号、房态、配置、使用设置、营业时刻、备注）

职员（职员编号、职员姓名、职员性别、职员类别、职务、聘用日期、薪金、备注）

E-R图中的从实体及相应的“的”联系变换为一个关系，从实体的属性加上主实体关系的主码构成那个关系的属性。

如果“的”联系是1：

1的，则以主实体关系的主码（作为外来码）为那个关系的主码；

M的，则以主实体关系的主码加上同一主实体个体联系的不同从属实体个体赖以相互区分的属性组，组成该关系的主码。

1：

M联系通过在“多”实体关系中增加相联系的“1”实体关系的主码及联系本身的属性来表达。

其中“1”实体主码为外来码。

M：

M联系转换成一个独立的关系，被联系实体关系的主码（作为外来码）和联系本身的属性作为该关系的属性，被联系实体关系的主码组成其复合主码。

B导出一样关系模型

在本酒店客房治理信息系统中，“客人”联系与“客房”联系是多对多联系，其被联系实体关系的主码为外码和该联系本身的属性一起组成关系的属性，被联系的主码组成该关系的复合主码。

将它们转换为关联模式如下：

预订（房间号、日期、姓名、联系电话、工作单位、预订日期、预住天数、押金、预住人数、备注、预订服务员和时刻）

由E-R图及由其导出一样关系模型的差不多原则，可得以下数据关系模型：

入住（凭证号码、姓名、性别、年龄、证件名称、证件号码、房间号、工作单位、住宿日期、预住天数、退宿日期、备注、日期、时刻、押金、来宿服务员、是否结账）

退宿（凭证号码、姓名、房间号、住宿日期、住宿时刻、结款方式、折扣、押金、酒水费、电话费、赔偿费、其他费用、退宿日期、退宿时刻、备注、操作员）

挂账（凭证号码、日期、挂账单位、摘要、住宿金额、欠款金额、还款金额、姓名、证件名称、证件号码、时刻、是否结清）

客房（房间号、类型编号、房态、配置、使用设置、营业时刻、备注）

房间类型（类型编号、客房类型、价格、备注）

职员（职员编号、姓名、性别、密码、职务、聘用日期、薪金、备注）

C初始一样关系模型的改进与优化

　　对上面的关系的改进，关于预订关系中由房间号、日期、姓名三个属性作为复合属性构成主键，实际实现比较困难，使用不方便，故增加凭证号码这一属性作为主标识，预订关系改进为：

预订（凭证号码、房间号、日期、姓名、联系电话、工作单位、预订日期、预住天数、押金、预住人数、备注、预订服务员和时刻）

在入住关系中，由于实际中有双人房要记录客人的信息，故增加姓名、性别、年龄、证件名称、证件号码、工作单位这些属性，该关系改进为：

入住（凭证号码、姓名、性别、年龄、证件名称、证件号码、工作单位、姓名1、性别1、年龄1、证件名称1、证件号码1、工作单位1、房间号、住宿日期、预住天数、退宿日期、备注、日期、时刻、押金、来宿服务员、是否结账）

退宿关系中，由于实际需要了解实际宿费、应收宿费、金额总计、住宿天数以及退还宿费，期望在关系中体现，故增加这几项属性。

该关系改进为：

退宿（凭证号码、姓名、房间号、住宿日期、住宿时刻、实际宿费、结款方式、折扣、应收宿费、金额总计、押金、住宿天数、退还宿费、酒水费、电话费、赔偿费、其他费用、退宿日期、退宿时刻、备注、操作员）

　　同理，在挂账关系中实际需要直截了当了解金额累计，在该关系中增加这一属性，该关系改进为：

挂账（凭证号码、日期、挂账单位、摘要、住宿金额、欠款金额、还款金额、金额累计、姓名、证件名称、证件号码、时刻、是否结清）

按照以上调整后的关系，重新对前面分析的E－R图进行改进，基于前面的关系不变，只是在原有的基础上，增加属性和调整主属性，故不再画出，下面的分析参照改进后的各关系。

1.10业务流程再造

业务流程再造（BPR，BusinessProcessRe-engineering）的定义是：

以业务流程为改造对象和中心、以客户需求和中意度为目标、对现有业务流程进行全然的再摸索和完全的再设计，利用先进的制造技术、信息技术以及现代化的治理手段、最大限度地实现技术上的功能集成和治理上的职能集成，以打破传统的职能型组织结构，建立全新的过程型组织结构，从而实现企业在经营成本、质量、服务和速度等方面的庞大改善。

目前，国内企业进行的所谓的BPR，并非上述标准意义上的业务流程再造，只是对现有业务流程的优化、改进或调整，即一样意义上的流程改变或调整，并没有对现有的业务流程进行“全然的再摸索和完全的再设计”、“建立全新的过程型组织结构”。

我国企业的治理水平决定了BPR的中国特色。

对国内企业来讲，应该勇于面对这种特色。

不能完全用市场化的治理软件“硬套”自己的业务流程。

应用企业治理软件是提升企业治理水平的重要过程，按照企业特色找到合适的“再造”途径，是企业需要逐步探究的过程。

按照以上的理念在实施业务流程再造时所采取的实施策略：

先固化、后优化。

即第一留符合现代企业治理要求的业务流程，对那些不符合的，通过改进、调整或重建等手段进行再造，使业务流程初步满足企业信息化的差不多要求；

第二步，在初步实现企业信息化的基础上，再对业务流程进行优化，提升治理水平。

采取如此的BPR实施策略，既可防止显现盲目一刀切的BPR倾向，也能够防止显现固守现有业务流程、将手工流程电子化的倾向。

本系统在业务改造之时，引入运算机，差不多保留原有的业务流程，关于房态的修改，以往在客人退宿结账之后，负责客房清扫的职员对房间进行清扫，清扫完毕再打电话告知前台，增加前台的工作量，也不能即刻反映，对工作中带来不便，现在在每层楼增加一个客户端，各楼层的职员可对已清扫完毕的房间修改其房态，而前台的职员只要对房态界面进行刷新即可迅速获得信息，提升工作效率，减轻工作量，减少出错。

其业务流程改造如图1-27：

图1-27业务流程改造图

业务流程改进后的顶层DFD图与现状的顶层DFD图一样，在此就不在给出了。

下面给出改进后的0层DFD图如图1-28：

图1-28改进后的0层DFD图

1.11功能层次图

按照业务流程图和数据流程图的分析，得出系统的详细的功能层次图，如下图：

图1-28功能层次图

1.12数据字典分析

按照数据流程图，构思数据流表：

数据流表（表1-1）

编号

数据流名

来源

结构

去向

从属讲明

P001

客房预定表

预订登记单

凭证号码＋房间号＋姓名…

接待治理

P002

登记表

入住登记单

客房信息表

凭证号码＋房间号＋姓名＋押金…

退宿治理

P003

退宿表

退宿登记单

凭证号码＋房间号＋姓名＋金额总计…

客人

P004

挂账信息表

挂账信息单

凭证号码＋挂账单位＋还款金额…

P005

客房信息单

房间号＋类型编号＋房态＋配置＋使用设置…

预订治理

调房治理

P006

客房类型表

类型编号+客房类型+价格+备注

客房治理

P007

挂账单位信息表

P008

职员登记表

职员登记单

职员编号＋姓名＋性别＋密码＋职务＋聘用日期＋薪金＋备注

人力资源治理

2系统设计

2.1总体设计

2.1.1一样关系模型设计

一样关系模型的导出在上面差不多叙述，此处设计的一样关系模型同上面的差不多一致，就不再论述。

A处理功能总体结构设计

模块结构图（MSD）也称操纵结构图，是用来表示系统的模块划分与层次分解关系，表示模块的调用关系、模块间数据流与操纵流的传关系以及外界或数据储备信息接口的规范化图形，它是结构化系统设计的一种重要的图表描述工具。

以变换为中心进行分析

在本系统中，表现为线状数据流的是客房处理、接待处理和挂账处理，它们可分为输入、处理和输出3个部分，处理功能是系统的变换中心。

客房处理的输入是职员的客房信息单，处理是职员对此客房信息单的有关处理与操作，输出要紧是打印表单。

接待处理的输入是客户的预订登记单或者入住登记单，处理是职员的有关操作，输出是收据和报表。

挂账处理的输入是客户的挂帐登记单，处理是职员的有关操作，输出是收据和报表。

因此，它们的分析方法适合利用变换为中心的分析方法。

它们的线状流程图如下图：

图2-1客房处理的变换型数据流图

图2-2挂账处理的变换型数据流图

图2-3接待处理的变换型数据流图

按照线状数据流图导出系统结构的3个要紧步骤，找出变换中心（主处理）、逻辑输入和逻辑输出，设计系统最上两层的模块，再设计中、下、层模块。

从上面的数据流图能够清晰地看出主处理、逻辑输入、逻辑输出。

通过分析设计，得到退货处理和进货处理的模块结构图如下：

图2-4客房处理的模块结构图

图2-5接待处理的模块结构图

图2-6挂账处