Локальная системы бронирования гостиничных услуг на основе субд

 

Одним из наиболее мощных, гибких и доступных средств по работе с БД является на сегодняшний день СУБД Access от компании Microsoft. Она обла­дает широким диапазоном средств для ввода, ана­лиза и представления данных. Имея наряду с навы­ками работы в Access некоторые базовые знания встроенного языка программирования Visual Basic for Applications (VBA), можно самостоятельно со­здавать мощные бизне-приложения для своего предприятия.

Структура АСУ представляет собой однополь­зовательский вариант для размещения на рабочей станции портье и состоит из нескольких связан­ных таблиц, представляющих из себя основу со­ответствующих функциональных модулей: «клиен­ты», «номерной фонд», «бронь» и «отчеты». Каждая из таблиц, будучи отображена в стандартном виде конструктора Access, имеет следующую структуру:

	Клиенты ФИО № паспорта Пол Возраст д/рождения организация статус адрес телефон e-mail количество заездов примечание		Номера № комнаты Тип Класс Всего комнат Всего мест Фото Описание Стоимость Состояние Постоялец Примечание		Бронь № брони Клиент Дата заезда Дата выезда № комнаты примечание

 

Таблица «Клиенты» представляет собой набор ин­формации, аналогичный карточке гостя и служащий для более полной работы с ним службы маркетинга (если таковая имеется). Поле «№ Паспорта», будучи изначально уникальным, введено для удобства ра­боты с базой данных и исключения путаницы (ведь имена могут повторяться). Поле «возраст» не вво­дится пользователем, а рассчитывается как разница системной даты и даты рождения гостя. Поле «ко­личество заездов» служит для отображения частоты посещения гостем гостиницы. Его значение увели­чивается на единицу каждый раз, когда оформляет­ся очередной заезд, и не редактируется. На основе количества заездов может определяться статус гостя (например, «обычный гость», «постоянный клиент», «привилегированный клиент» и т.п.) и ставка скидки. Постоянные контакты, хранение как можно более полной информации о гостях способствует добро­желательным с ними отношениям и определенно склоняет их к последующему выбору именно вашей гостиницы. Так, один из наиболее эффективных инс­трументов упоминания о себе - поздравления с днем рождения и другими праздниками по электронной почте - многими АСУ осуществляется автоматически без всякого участия оператора АСУ.

Таблица «номерной фонд» по большей части предназначена для гостей и содержит необходи­мую для них информацию. Здесь пояснения может потребовать поле «состояние». Это, по сути, отмет­ка о занятости номера. Ему лучше присваивать одно из четырех значений: свободен, занят, заброниро­ван и снят с продажи. От значения «забронирован» можно было бы и отказаться, поскольку его текущее состояние - «свободен», однако такое представле­ние номеров можно использовать для обособления части номерного фонда, предназначенной для сво­бодной продажи, а не для бронирования.

Но основой такой АСУ является именно модуль бронирования. В нем принципиально необходимо присутствие информации о датах заезда и выез­да, привязка к конкретному номеру (размещенное бронирование) и данные для идентификации бро­ни, которые, в принципе, может играть и номер паспорта гостя.

Таблица брони представляет собой список оформленных броней, на базе которых создается таблица с сортировкой по номерам гостевых ком­нат и датам заезда-выезда. В ней система в соот­ветствии с введенным запросом ищет подходящие комнаты по принципу «попадания в окно», то есть дата запрашиваемого заезда должна быть больше даты предыдущего выезда в этом номере, а дата выезда - меньше следующей даты въезда (если та­ковая имеется). Такое решение не отличается кра­сотой, но занимает меньше памяти и требует мень­ше операций от АСУ.

Последней таблицей является таблица отчетов системы. Она не является базовой, поскольку генерируется запросом, осуществляющим сводку и анализ информации из других таблиц, а именно, оперативные показатели работы средства разме­щения. Это прежде всего количество проданных номеров, занятых койко-мест, общий доход от но­мерного фонда, загрузка гостиницы, средняя цена номера, среднее количество гостей на один номер, коэффициент двойной загрузки ((число гостей - число проданных номеров)/число проданных но­меров), коэффициент занятости койко-мест (чис­ло занятых коек/число свободных коек)). Данные рассчитываются на каждый день и, привязываясь к дате, сохраняются в БД. По запросу операто­ра АСУ строит и печатает графики и диаграммы, что позволяет судить о динамике развития гости­ницы во времени.

Такая простейшая информационная структу­ра создается с помощью конструктора (мастера) Access и не вызовет затруднений даже у начина­ющего пользователя. Сложности начинаются при разработке интерфейса системы, по большей час­ти берущего на себя обязанности по вводу, сохра­нению и анализу информации. Реализовать некото­рые функции возможно здесь только посредством встраивания программных модулей на языке VBA.

Конкретное воплощение интерфейса зави­сит лишь от фантазии заказчика и программиста. Однако именно этому этапу разработки следует уделить особое внимание. Нередки случаи, когда чрезмерная сложность и отсутствие наглядности в системе пагубно влияло на эффективность рабо­ты персонала.

Единовременно на экран должна выводиться только самая необходимая информация. На наш взгляд, это должна быть карта отеля, то есть список всех номеров, их постояльцев, состояния заселен­ности, статуса гостей и количество дней до выез­да. В зависимости от состояния гостевой комнаты соответствующая ей строка должна окрашиваться в заданный цвет, к примеру, занятый номер отобра­жается красным цветом, забронированный - жел­тым, свободный - зеленым, снятый с продажи - пе­речеркнутым шрифтом.

Ниже окна с таблицей находятся поля запроса параметров брони. По минимуму запрос должен состоять из дат заезда и выезда, но если возмож­ности и объем услуг отеля позволяют, то можно ввести и дополнительные элементы, как-то: тип помещения, дополнительные услуги и прочее. Пос­ле активизации запроса на экране монитора появ­ляется всплывающее окно с результатами поиска. В нем оператор выбирает подходящий вариант и вводит необходимую для идентификации брони информацию. Предлагается использовать номер паспорта гостя, поскольку имена могут повторять­ся, а номер брони гость с большой вероятностью забудет, что приведет к нежелательной путанице.

После сохранения брони строчка соответству­ющей гостевой комнаты приобретает заданную окраску. Можно предусмотреть функцию, при кото­рой система считает, за сколько дней до предпола­гаемого въезда произошло бронирование, и при­сваивает этой брони определенный коэффициент скидки. При заселении клиента базовая цена номе­ра умножается на этот коэффициент и получается конечная цена под конкретного клиента.

Заселение производится следующим образом: при двойном щелчке мыши по строке гостевой комнаты в таблице состояния номерного фонда открывается интерфейсное окно номера, где отобра­жены текущие постояльцы, состояние помещения, вкладки с фотографиями, календарем бронирова­ния, заметками и кнопки «Заселить» и «Выселить». В специальном поле вводим номер паспорта гостя, и если о нем есть запись в БД, то в окне состояния номера появляется запись о госте, если до этого гость не пользовался услугами гостиницы и инфор­мации о нем нет в БД, всплывает окно карточки гос­тя. В нем набираются требуемые данные, и после нажатия кнопки «ОК» БД пополняется новой запи­сью, а гость заселяется в номер. Выселение проис­ходит после нажатия кнопки «Выселить», влекуще­го за собой удаление информации о проживающих в номере гостях.

На основную панель интерфейса также помеща­ются кнопки, открывающие доступ непосредствен­но к таблицам системы, а также к сектору отчетов, где отображаются характеристики работы средства размещения и строятся диаграммы. Необходимы также элементы управления, позволяющие управ­лять построением отчетов и их распечаткой.

Среди автоматических возможностей системы чрезвычайно полезным может оказаться ежеднев­ная распечатка предстоящих заездов и выездов, осуществляемая системой самостоятельно в начале каждого рабочего дня. Созданные отчеты распро­страняются среди обслуживающего персонала отеля для увеличения оперативности работы с клиентами. Защита хранимой в БД информации, ее шифро­вание и ограничение доступа может осуществляться встроенными процедурами Access, однако не ос­ведомленному пользователю легче будет восполь­зоваться специализированными средствами: шиф­ровальным ПО, электронными ключами и прочими инструментами, в изобилии появившимися в послед­нее время на рынке программного обеспечения.

Рекомендуется при работе с АСУ пользовать­ся так называемой исполняемой версией Access

(Access Runtime), не потребляющей лишние сис­темные ресурсы и не позволяющей случайно или намеренно изменить структуру и базовую ин­формацию системы.

Вопрос об установке автоматизированной сис­темы управления гостиничным фондом в конеч­ном итоге решать все же владельцу (управляюще­му) гостиничного предприятия. Вполне вероятно, что в условиях средства размещения малого типа с незначительными по объему информационными потоками компьютеризация процесса управления отелем лишь неоправданно усложнит работу пер­сонала, однако с каждым годом становится все более очевидным необходимость внедрения таких систем на предприятиях, осуществляющих много­плановое и высокоуровневое обслуживание боль­шого объема клиентов.

Точность и быстрота работы профессиональ­но разработанной и отлаженной PMS позволяет значительно снизить время обслуживания и коли­чество ошибок, улучшить качество обслуживания, что влечет за собой минимизацию накладных рас­ходов на лишний персонал, облегчает аудит и спо­собствует росту положительного имиджа средс­тва размещения среди потенциальной клиентуры и партнеров, что, несомненно, наилучшим образом скажется на конкурентоспособности предприятия.

В современном информационном обществе адаптация потоков данных к компьютерным моде­лям становится не только хорошим тоном, но и ус­ловием выживания на сверхдинамичном рынке. До­ступ к информационным технологиям все более упрощается и удешевляется, а окупаемость их ред­ко можно поставить под сомнение.

Особую ценность АСУ представляют при интег­рации средства размещения в глобальную систему бронирования (GDS), при этом создается единая для всех членов сети информационная модель, использующаяся удаленными операторами (сис­тема Ь2Ь - business to business) и туристами (Ь2с - business to client) для бронирования услуг отеля (временами даже без участия самой гостиницы). Это значительно упрощает действия предпри­ятия по привлечению клиентов и сокращает рас­ходы на рекламу. Часто расходы на рекламу берет на себя владелец GDS.

Большинство фирменных PMS предусматрива­ют подключение к GDS, что значительно упрощает дальнейшее расширение планов руководства.

Концепция APS. Особенностью этой концепции является возмож­ность решать такие задачи, как «проталкивание» срочного заказа в производственные графики и распределение заданий с учетом приори­тетов и ограничений. В системах, реализующих концепции APS, широ­ко используются современные методы оптимизации (математические, эвристические). В настоящее время концепция APS часто применяет­ся при создании специализированных модулей в ERP-системах.

Одним из центральных элементов всего процесса создания АИС является разработка технического задания, структура которого, со­гласно ГОСТ 34.602-89, содержит следующие разделы:

- общие сведения;

- назначение и цели создания (развития) системы;

- характеристика объектов автоматизации;

- требования к системе;

- состав и содержание работ по созданию системы;

- порядок контроля и приемки системы;

- требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;

- требования к документированию;

- источники разработки.

Суть технического задания как основного документа в процессе со­здания ИС заключается в проработке, выборе и утверждении основ­ных технических, организационных, программных, информационно-логических и лингвистических решений, которые устанавливаются в разделе «Требования к системе». Данный раздел, в свою очередь, со­стоит из трех подразделов [14, с 125]:

- требования к системе в целом;

- требования к функциям (задачам), выполняемым системой;

- требования к видам обеспечения.

Требования к системе в целом отражают концептуальные параме­тры и характеристики создаваемой системы, среди которых указыва­ются требования к структуре и функционированию системы, к надеж­ности и безопасности, к численности и квалификации персонала и т. д.

Требования к функциям (задачам) содержат перечень функций, за­дач или их комплексов; временной регламент каждой функции, зада­чи или комплекса задач; требования к качеству реализации каждой функции; к форме представления выходной информации; характери­стики необходимой точности и времени выполнения, требования од­новременности выполнения группы функций; достоверности выдачи результатов.

Для большинства разновидностей ИС особое значение имеют требо­вания к информационному обеспечению. В данном подразделе, в част­ности, определяются требования:

- к составу, структуре и способам организации данных в системе (информационно-логическая схема);

- к информационному обмену между компонентами системы;

- к информационной совместимости со смежными системами;

- по использованию общероссийских и других классификаторов, унифицированных документов;

- по применению систем управления базами данных;

- к структуре процесса сбора, обработки, передачи данных в систе­ме и представлению данных;

- к защите данных от разрушений при авариях и сбоях в электро­питании системы;

- к контролю, хранению, обновлению и восстановлению данных;

- к процедуре придания юридической силы документам, проду­цируемым техническими средствами ИС.

На основе установленных в техническом задании основных требо­ваний и технических решений на последующих этапах конкретизи­руются и непосредственно разрабатываются компоненты и элементы системы.

Таким образом, АСУ гостиниц - это уже не просто мода, но назревшая обусловленная требованиями времени необходимость, и степень соответствия этому веянию может означать процветание пред­приятия либо его упадок.