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

План-меню составляется специалистами отдела планирования. В основе плана-меню лежат уже сформированные заказы (в среднем, уровень обеспеченности ресторана предварительными заказами составляет сейчас около 70-75% в зависимости от сезона) и анализ статистики заказов, позволяющий выявить сезонные закономерности посещаемости и предпочтений клиентов. Источниками оперативной информации для отдела планирования является информация, поступающая от менеджеров ресторана, работающих с корпоративными и постоянными клиентами. Источниками аналитической информации являются статистические данные, формируемые руководителями смен и содержащие исчерпывающие данные о заказах за смену. Аналитическая обработка производится с использованием программного комплекса «Галактика 5. », которые в настоящее время полностью удовлетворяет всем стоящим перед отделом планирования задачам.

Таким образом, процесс оперативного планирования на ООО «Альянс» можно представить в виде следующей схемы:

Размещено на http://www.allbest.ru/

Рис. 1. 4. Основные информационные потоки на ООО «Альянс»

Анализ данной схемы позволяет выделить наиболее слабые места сложившейся информационной системы на предприятии.

Первой важной проблемой является оперативный учет заказов начальниками смен. Они собирают данные по заказам от официантов и менеджеров зала в течение всего рабочего дня и затем должны сформировать окончательный список всех заказов с учетом их особенностей. В настоящее время, несмотря на то, что рабочее место начальников смен оборудовано компьютерной техникой, отчет за смену выполняется, как правило, в рукописном виде или, некоторыми начальниками смен, в форматах Word или Excel. Понятно, что затраты живого труда на формирование таких отчетов довольно велики. Кроме того, при поступлении отчетов в бумажном или печатном виде, сотрудники отдела планирования должны впоследствии переводить их в электронный вид, внося данные в базу данных системы «Галактика» для последующей аналитической обработки. Так что фактически одну и ту же работу приходится выполнять дважды.

Связана указанная сложность прежде всего с тем, что начальники смен не умеют пользоваться программным комплексом «Галактика» ввиду его высокой сложности для обычного пользователя.

Далее, используемое на предприятии программное обеспечение не позволяет эффективно работать с технологическими картами ресторана. Система 1:С изначально не предназначена для хранения и эффективной работы с массивами информации, имеющими древовидную структуру произвольной длины. Правда, возможна разработка дополнительных программных модулей для 1:С, решающих указанную проблему, но практическая работа с ними оказывается уже более сложной. Автоматизировать в рамках программного комплекса 1:С Предприятие все аспекты технологических процессов в ресторане не представляется возможным. Вот и оказывается, что формирование заказа на поставку продуктов на основании плана-меню специалисты отдела снабжения должны проводить «вручную», опираясь в основном на калькулятор и ручку. Кроме того, что при этом наблюдаются малопроизводительные траты рабочего времени, по мере увеличения объемов обслуживания клиентов всё чаще стали наблюдаться фактические ошибки в расчетах, приводящие зачастую к срыву выполнения дневной производственной программы ресторана и ведущие к вынужденным дополнительным расходам.

Наконец, одна из приоритетных задач, которые сейчас ставят рестораторы, в частности, руководство ООО «Альянс» - добиться того, чтобы система не только помогала обслуживать гостей, но и предусматривала возможности для развития заведения: возможность делать различные дисконтные программы, программы лояльности, обслуживание постоянных клиентов. Понятно, что любой ресторатор хочет видеть в своем заведении постоянных клиентов (именно они дают 80% оборота). К таким посетителям нужно подходить индивидуально, предоставлять скидки, особое обслуживание и т. д. Изменились условия рынка, конкуренция растет, и необходимо прилагать больше усилий на привлечение гостей в свое заведение. Популярны акции по привлечению в кафе и рестораны определенной категории посетителей: предположим, в ресторане объявляются скидки на конкретные позиции блюд в конкретные часы один день в неделю. Поскольку это не банальная процентная скидка, а дисконт, привязанный ко времени и дню недели, реализовать его можно не во всех системах. А когда система автоматизации не предусматривает такую функцию, предоставление скидки гостям отдается на откуп персоналу, а значит, разница в цене благополучно оседает в карманах официантов. Программа по привлечению клиентов выливается в дополнительные непредвиденные расходы.

Поэтому в настоящий момент ресторану «Альянс» необходима эффективная и достаточно простая информационная система, позволяющая решать следующие задачи:

- хранение технологических карт ресторана в удобном для обработки виде и в формате, позволяющем осуществлять доступ к информации с использованием уже работающих на предприятии программных комплексов - 1:С и «Галактика».

- обеспечивать удобный ввод данных по заказам за смену начальниками смен

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

- обеспечивать контроль выполнения дневного задания производственными цехами ресторана

- обеспечивать контроль выполнения дневного задания по обслуживанию клиентов в соответствии со сформированным плановым заданием

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

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

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

2. Обоснование проектных решений по автоматизированному решению задачи управления производством ресторана «Альянс»

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

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

1. объекты информационной системы (сущности в концептуальной модели);

2. их свойства (атрибуты);

3. взаимодействие объектов (связи) и информационные потоки внутри и между ними.

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

Схема формирования информационной модели представлена на рисунке 2. 1.

Рис. 2. 1. Схема формирования информационной модели [65, стр. 144]

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

Для решения задач проектирования сложных систем существуют специальные методологии и стандарты. К таким стандартам относятся методологии семейства IDEF (Icam DEFinition, ICAM - Integrated Computer-Aided Manufacturing - первоначально разработанная в конце 70-х гг. программа ВВС США интегрированной компьютерной поддержки производства). С их помощью можно эффективно проектировать, отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. Стандарты IDEF0- IDEF1X описывают приемы изображения компонентов ИС, связей между ними и построения модели данных ИС [42, стр. 56-57].

При разработке ЭИС “Автоматизированная система управления производством ресторана» (далее сокращенно ЭИС АСУПП) нами будет использован системный структурный подход. Методология этого подхода заключается в разработке модели на основе представления о функциях. Модели ЭИС (активностные модели) согласно методологии представляются в виде диаграмм, которые иерархически упорядочены. Активностная модель представляет собой совокупность активностей взаимосвязанных через объекты (элементы) системы.

Ниже для проведения анализа и организации бизнес-процессов турагенства использовано CASE-средство верхнего уровня BPWin, (AllFusion Process Modeler 4. 1 (Bpwin 4. 1)), поддерживающее методологии:

- IDEF0 (функциональная модель);

- DFD (DataFlow Diagram);

- IDEF3 (Workflow Diagram) [42, стр. 102].

Построение модели ЭИС по автоматизации производственных процессов в ресторане начинается с описания функционирования системы организации производства в целом в виде контекстной диаграммы. На рис. 2. 2 представлена контекстная диаграмма производственного процесса в ООО «Альянс»:

Рис. 2. 2 Первый уровень детализации процесса автоматизации производственного процесса ресторана в нотификации IDEF0

Взаимодействие системы с окружающей средой описывается в терминах входа (на рис. 21 это “Список поваров”, ”Справочная информация о классах блюд и рецептуре (фактически данные технологических карт)» и «Приготовленные блюда»), выхода (основной результат процесса - “Отчеты”, «Системные сообщения», «Представление хранимых данных» и “Справочники”), управления (“Запросы и “Справочник пользователя”) и механизмов (“Пользователь”, “Аппаратно-технические средства”- это ресурсы, необходимые для процесса функционирования системы в целом).

“Список товаров” - те материальные ресурсы, которые используются при обслуживании клиентов ресторана, прежде всего - это составляющие меню.

“Запросы” и “Справочник пользователя” - это правила, которыми управляется процесс функционирования ресторана как предприятия со своими внутренними правилами.

В оказании услуг клиентам ресторана с точки зрения организации производственного процесса принимает участие объект под названием “Пользователь”, формирующий составляющие плана-меню на день в материальном воплощении. Чтобы сформировать план-меню как завершенный ресторанный продукт, в деятельности ООО «Альянс» должны участвовать “Пользователи” и “Аппаратно-технические средства” - сотрудники ресторана, инвентарь, информационные ресурсы и т. д.

На этом уровне модель описывает деятельность ресторана в части плана-меню ресторана, а именно следующие предоставляемые ею услуги:

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

- Обеспечение персонала производственных цехов ресторана необходимыми материально-техническими средствами,

- Администрирование процедур материального производства составляющих плана-меню.

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

Рис. 2. 3. Формирование данных по производственным процессам в ситуации КАК ЕСТЬ

Следующий уровень детализации позволяет представить схему КАК ЕСТЬ обработки данных для формирования отчетов по запросам заинтересованных пользователей.

Рис. 2. 4 Обработка данных при формировании отчетов КАК ЕСТЬ

Сама суть формирования отчетов представляется достаточно простой и ясной, но построенные схемы позволяют глубже взглянуть на стоящие перед менеджментом ресторана проблемы. Рассмотрим подробнее задачи, от решения которых явным образом зависит эффективность решения задач по формированию производственных заданий и заявок на необходимые ресурсы в ресторане «Альянс».

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

2. 2 Обоснование выбора задач, автоматизируемых при создании ЭИС АСУПП

Для решения поставленной в предыдущем параграфе задачи прежде всего необходимо иметь четкую концепцию информационных потоков на ООО, связанную с обслуживанием и регистрацией заказов, учетом ресурсов, необходимых для выполнения план-меню. Рассмотрим общий алгоритм работы менеджеров ООО «Альянс» по обслуживанию плана-меню, который фактически никак не зависит от того, в какой форме собираются и обрабатываются информационные данные. Блок-схема алгоритма представлена на рис. 2. 5.

Наиболее слабыми местами в данной схеме работы являются:

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

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

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

Рис. 2. 5. Алгоритм работы по формированию и выполнению план-меню на ООО «Альянс»

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

1. Создание информационного хранилища данных, содержащего все сведения из технологических карт ресторана «Альянс».

2. Создание информационного хранилища данных, содержащего все план-меню ресторана с данными по их выполнению как в разрезе выполнения производственной программы, так и в разрезе реализации блюд клиентам ресторана.

3. Создание информационного хранилища данных, содержащего сведения по движению товарных позиций на складе ресторана

4. Разработка программного модуля, обеспечивающего автоматизированное формирование плана-заказа на поставку товаров на склад ресторана с учетом задания план-меню и с учетом сведений о товарных остатках на складе.

В результате выполнения задания на разработку ЭИС АСУПП изменится и IDEF-модель ресторана. При автоматизированной обработке информационных массивов, которая будет иметь место на ООО «Альянс» в результате внедрения ЭИС АСУПП, схема обработки данных и порождения результирующих отчетов будет выглядеть следующим образом:

Рис. 2. 6. Формирование данных по производственным процессам в ситуации КАК БУДЕТ

Следующий уровень детализации позволяет представить схему КАК БУДЕТ обработки данных для ведения базы данных ЭИС:

Рис. 2. 7. Схема ведения базы данных ЭИС АСУПП в ситуации КАК БУДЕТ

Схема обработки справочной информации в ситуации КАК БУДЕТ представлена на рисунке 2. 8:

Рис. 2. 8. Обработка справочной информации в ситуации КАК БУДЕТ

2. 3 Обоснование проектных решений по информационному обеспечению комплекса задач автоматизации ресторана «Альянс»

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

Характерными чертами экономической информации [46, стр. 16-18] являются её числовой характер, линейная форма (1) , большая размерность и простые арифметические операции обработки, высокая степень структуризованности и регламентированности форм представления отчетов, табличная форма представления групп показателей, достоверность, регулярность (2) . Исходная и результативная информация в основной массе дискретна и представлена в алфавитно-цифровом виде. Исходная информация, как правило, фиксируется в первичных документах (3) . Полученная результативная информация часто используется в качестве исходной при последующих расчетах.

Необходимо выделить следующие особенности экономических задач:

- высокая алгоритмизуемость;

- иерархичность (вхождение в блоки, функции и т. д. );

- регулярность решения;

- ограниченные сроки решения;

- массовость и возможность типизации схем решения;

- большой объём и структурированность данных на входе и выходе экономической информационной системы.

Экономическая информационная система состоит их набора элементов (подсистем), находящихся в определенных отношениях друг с другом. Множество этих отношений совместно с каждым элементом системы образуют структуру ЭИС. В ЭИС АСУПП ресторана «Альянс» можно выделить две основные части: обеспечивающую и функциональную [48, стр. 29] (рис. 2. 9).

Рис. 2. 9. - Состав экономической информационной системы

Обеспечивающая часть ЭИС состоит из следующих видов обеспечения: 1) информационного; 2) технического; 3) математического и программного; 4) организационного; и 5) правового.

Информационное обеспечение - это совокупность единой системы классификации и код ирования информации, унифицированных систем документации и массовой информации, циркулирующей в системе управления ООО «Альянс», а также построение и ведение баз данных. Для создания информационной базы необходимы:

- анализ потоков и объемов информации;

- создание массивов информации на машинных носителях.

Информационная база ЭИС состоит из двух взаимосвязанных частей: внемашинной и внутримашинной. К внемашинной относится та часть информации, которая существует без технических средств (экономико-технологические документы: договоры, планы-меню, штатное расписание, технологические карты, акты, накладные, счета, ведомости и т. д. ). Внутримашинная информационная база содержится на внутримашинных носителях и состоит из файлов, каждый из которых отражает однородные экономические документы. Файлы базы данных разрабатываются с соблюдением определённых принципов и ориентацией на одну из моделей базы данных (реляционную, иерархическую, сетевую). Файлы обрабатываются с помощью специального программного обеспечения СУБД.

Составные единицы информации в ЭИС обладают определенной структурой [48, стр. 96-99]. Существуют различные способы представления структуры ЭИС; каждый из них отображает состав ЭИС, упорядоченность составляющих, уровни составных и составляющих. Наиболее распространёнными способами представления структуры ЭИС являются табличный, графический и аналитический.

Рассмотрим существенные стороны информационных потоков в сфере управления производственно-технологическими процессами ресторана «Альянс». Во-первых, следует выделить исходные информационные массивы - данные о базовых продуктах меню, которые предоставляются ресторанам клиентам и которые, вообще говоря, не могут быть изменены и не могут быть разделены на более мелкие блоки. Информация, составляющая такой базовый блок, в обязательном порядке должна содержать следующие сведения:

- уникальный код продукта в меню

- краткое наименование (описание)

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

- наименование выпускающего цеха и ответственного исполнителя

- существенные условия изготовления (данные технологической карты на позицию меню)

- стоимость производства единицы продукта меню

- наличие на производственном складе

- используемая наценка ресторана

- итоговая цена реализации

Назовем базисные элементы меню ресторана продуктами нулевого уровня.

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

Далее, продуктами i-го уровня назовем позиции меню, которые получаются комбинацией одного продукта уровня i-1 с единственным другим продуктом уровня i-1, либо комбинацией продукта уровня i-1 с услугой ресторана, предоставляемой самостоятельно.

При описании каждого элемента на уровне i следует в обязательном порядке указывать:

- уникальный код комплексного элемента меню

- краткое наименование (описание)

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

- наименование выпускающего цеха и ответственного исполнителя

- существенные условия изготовления и предоставления (технологическая карта)

- стоимость производства элемента меню или стоимость оказания услуги

- наличие на оперативном складе

- используемая наценка ресторана

- итоговая цена реализации рестораном комплексного продукта

Отметим, что практически не существует разумного алгоритма, который мог бы самостоятельно комбинировать услуги и определять цену комплексной услуги в зависимости от составляющих её компонентов. Эти вопросы являются исключительной компетенцией менеджеров ресторана, которые фактически должны выполнять всю содержательную работу по формированию списка план-меню и характеристик предоставляемых услуг. Таким образом, в исходной форме экономический документ, относящийся в сфере действия ЭИС АСУ, имеет табличную форму представления. Данный документ содержит некоторое количество уровней. С₀, допустим, представляет базовый продукт ресторана, включаемый в план-меню. Далее документы С₁, С₂, и т. д. представляют собой продукты первого уровня. Расположенные на один шаг ниже документы С представляют собой описания продуктов уровня 2 и т. д. В конце построенного таким образом дерева расположены продукты самого высокого уровня сложности, обозначенные на рисунке внизу буквами А. Например, общая часть С1 содержит составляющие А1, А2, А3, А4, А5. Предметная часть С2 содержит С4, С5, С6, А14, С8. Оформительная часть С3 А18, А19. Графический способ представления структуры ЭИС основан на структурном графе [31, стр. 144-155]. Методика построения структурного графа для экономического документа проектируемой ЭИС такова:

1. каждой составляющей в документе ставится в соответствие вершина графа;

2. последовательно выделяемые вершины соединяются линиями, которые указывают на соподчинение выделенных составляющих;

3. вершине, которая является корнем графа, ставится в соответствие название (номер) соответствующей технологической карты;

4. вершинам следующего (второго) уровня ставятся в соответствие выделенные элементы списка технологических карт ресторана (например, С1, С2, С3);

5. следующие уровни заполняются компонентами (простыми составными атрибутами), составляющими эти элементы ЭИС. Теперь можно представить графическую структуру любой сложности (рис. 2. 10).

Рис. 2. 10 - Графическая структура представления экономического документа

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

А) Свяжем висячие вершины графа с условным "нулевым" элементом.

Рис. 2. 11 - Графическая интерпретация документа и связь атрибутов с "0"

Б) Припишем каждой дуге, входящей в определённую составную (составляющую), параметр, характеризующий размерность атрибута или составной.

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

Объём информации по такому графу определяется суммой объёмов информации по каждому пути графа из начальной вершины (0) в конечную [30, стр. 272]:

где qi - объем информации i-го пути, вычисляемый по формуле:

Названию списка и характеристик агентства, которые фактически должны выполнять всех. агентов. Агентство где qj объем информации j-й дуги i-го пути.

Рис. 2. 12 - Пронумерованные вершины графа с размерностями всех компонентов (составных, атрибутов)

По технологии обработки данных базы данных подразделяются на централизованные и распределенные. Централизованная база данных хранится в памяти одной вычислительной системы. Если эта вычислительная система является компонентом сети, возможен распределенный доступ к такой базе. Такой способ использования баз данных часто применяют в локальных сетях ПК.

Распределенная база данных состоит из нескольких, возможно пересекающихся или даже дублирующих друг друга частей, хранимых в различных ЭВМ вычислительной сети. Работа с такой базой осуществляется с помощью системы управления распределенной базой данных (СУРБД).

Поскольку на ООО «Альянс» в настоящее время немного сотрудников (фактически доступ к проектируемой базе данных необходимо обеспечить для девяти человек), а количество записей в базе ограничивается несколькими тысячами, то наиболее приемлемым и простым с точки зрения реализации на данном предприятии способом обработки данных является централизованная база данных. Существующая на предприятии локальная сеть (100 Мб/сек) обеспечивает быстрый доступ всех заинтересованных сотрудников к базе данных, а мощности используемых ПК вполне хватает для быстрой обработки всех возможных запросов. По способу доступа проектируемая база, несомненно, является базой с сетевым доступом. Более того, должна быть реализована возможность работы с базой данных через Интернет, что позволяет решить важную проблему обеспечения работы с базой для удаленно работающих сотрудников.

Наиболее оптимальной архитектурой для проектируемой базы данных является клиент-серверная архитектура. В этой концепции подразумевается, что помимо хранения централизованной базы данных центральная машина (сервер базы данных) должна обеспечивать выполнение основного объема обработки данных. Запрос на данные, выдаваемый клиентом (рабочей станцией), порождает поиск и извлечение данных на сервере. Извлеченные данные (но не файлы) транспортируются по сети от сервера к клиенту. Спецификой архитектуры клиент-сервер является использование языка запросов SQL. Концепция клиент-сервер условно изображена на рисунке 2. 13 [13, стр. 41].

Рисунок 2. 13. - Схема обработки информации в БД по принципу клиент-сервер

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

Если какая-либо прикладная информационная система опирается на некоторую систему управления данными, обладающую этими функциями, то эта система управления данными является системой управления базами данных (СУБД). СУБД основывается на использовании иерархической, сетевой или реляционной модели, на комбинации этих моделей или на некотором их подмножестве [8, стр. 109]. Инфологическая модель должна быть отображена в компьютерно-ориентированную дата логическую модель, "понятную" СУБД. В процессе развития теории и практического использования баз данных, а также средств вычислительной техники создавались СУБД, поддерживающие различные дата логические модели [8].

Сначала стали использовать иерархические дата логические модели. Простота организации, наличие заранее заданных связей между сущностями, сходство с физическими моделями данных позволяли добиваться приемлемой производительности иерархических СУБД на медленных ЭВМ с весьма ограниченными объемами памяти. Но, если данные не имели древовидной структуры, то возникала масса сложностей при построении иерархической модели и желании добиться нужной производительности. Сетевые модели также создавались для мало ресурсных ЭВМ. Это достаточно сложные структуры, состоящие из "наборов" - поименованных двухуровневых деревьев. "Наборы" соединяются с помощью "записей-связок", образуя цепочки и т. д. При разработке сетевых моделей было выдумано множество "маленьких хитростей", позволяющих увеличить производительность СУБД, но существенно усложнивших последние. Сложность практического использования иерархических и сетевых СУБД заставляла искать иные способы представления данных. В конце 60-х годов появились СУБД на основе инвертированных файлов, отличающиеся простотой организации и наличием весьма удобных языков манипулирования данными. Однако такие СУБД обладают рядом ограничений на количество файлов для хранения данных, количество связей между ними, длину записи и количество ее полей.

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

Реляционная модель ориентирована на организацию данных в виде двумерных таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:

- каждый элемент таблицы - один элемент данных;

- все столбцы в таблице однородные, т. е. все элементы в столбце имеют одинаковый тип (числовой, символьный и т. д. ) и длину;

- каждый столбец имеет уникальное имя;

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

- порядок следования строк и столбцов может быть произвольным.

Отношения представлены в виде таблиц, строки которых соответствуют кортежам или записям, а столбцы - атрибутам отношений, доменам, полям. Поле, каждое значение которого однозначно определяет соответствующую запись, называется простым ключом (ключевым полем). Если записи однозначно определяются значениями нескольких полей, то такая таблица базы данных имеет составной ключ. Чтобы связать две реляционные таблицы, необходимо ключ первой таблицы ввести в состав ключа второй таблицы (возможно совпадение ключей); в противном случае нужно ввести в структуру первой таблицы внешний ключ - ключ второй таблицы.

Детально вопросы организации реляционной базы данных для ООО «Альянс» будут рассмотрены в следующей главе при построении инфологической модели ЭИС АСУПП.

2. 4 Обоснование проектных решений по технологии сбора, передачи, обработки и выдачи информации

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

- централизованная использование больших ЭВМ и вычислительных центров;

- децентрализованная использование персональных компьютеров непосредственно на рабочих местах.

Наиболее перспективной следует считать организацию технических средств на базе распределенных сетей из ПК и сервера, мэйнфрейма для хранения баз данных, общих для всех функциональных подсистем, организованных по технологии клиент-сервер. Этот режим предполагает выделение отдельного компьютера и представляет схему взаимодействия рабочих станций (клиентов) и сервера вычислительной сети, при которой рабочая станция получает от сервера и обрабатывает только то подмножество данных, которые соответствуют условию, указанному в запросе [50, стр. 76-]. В отличие от режима "файл-сервер", на данном компьютере находятся не только общие базы данных, но и программы первичной обработки данных. Это позволяет другим программам на удалённых компьютерах запрашивать не всю информацию из базы данных, а только частично или полностью обработанную сервером.

В настоящее время ООО «Альянс» располагает современной локальной сетью, построенной по технологии клиент-сервер и способной обеспечить эффективную работу с разрабатываемой базой данных агентства и прикладным программным обеспечением ЭИС.

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

При работе ЭИС АСУПП основным инструментом извлечения информации является построение структурированных запросов к имеющейся базе данных. Поэтому основным технологическим вопросом является следующий - какой следует выбрать механизм управления базой данных? В соответствии с общими требованиями к проектируемой ЭИС должны выполняться следующие требования:

- программный комплекс должен быть масштабируемым

- программный комплекс должен быть платформонезависимым

- программный с ЭИС использует решения типа «клиент-сервер

- обеспечение доступа к данным через интернет

С этой точки зрения наиболее современным и функциональным вариантом является использование для обслуживания запросов к системе языка запросов SQL. SQL является инструментом, предназначенным для обработки и чтения данных, содержащихся в компьютерной базе данных. SQL (структурированный язык запросов) [8, стр. 55].

Рис. 2. 14. Схема функционирования SQL-сервера базы данных

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

Организация данных. SQL дает пользователю возможность изменять структуру представления данных, а также устанавливать отношения между элементами базы данных.

Чтение данных. SQL дает пользователю или приложению возможность читать из базы данных содержащиеся в ней данные и пользоваться ими.

Обработка данных. SQL дает пользователю или приложению возможность изменять базу данных, т. е. добавлять в нее новые данные, а также удалять или обновлять уже имеющиеся в ней данные.

Управление доступом. С помощью SQL можно ограничить возможности пользователя по чтению и изменению данных и защитить их от несанкционированного доступа.

Совместное использование данных. SQL координирует совместное использование данных пользователями, работающими параллельно, чтобы они не мешали друг другу.

Целостность данных. SQL позволяет обеспечить целостность базы данных, защищая ее от разрушения из-за несогласованных изменений или отказа системы.

Другой важной технологической задачей является организация доступа к данным с использованием простого и понятного неподготовленному пользователю интерфейса. Поскольку объем базы данных, очевидно, оказывается достаточно большим, то для решения задачи наиболее эффективным методом является организация доступа к БД, который осуществляется специальной программой, запускаемой сервером в момент запуска системы и обслуживающей запросы пользователей ЭИС. Эта программа, обрабатывая запрос, просматривает содержимое БД и создает выходной документ, возвращаемый клиенту. Это решение эффективно для больших баз данных со сложной структурой и при необходимости поддержки операций поиска, что должно быть предусмотрено в ЭИС АСУПП при постановке задачи на проектирование. Показаниями такого решения также являются частое обновление данных (происходящее фактически несколько раз в день) и невозможность синхронизации преобразования БД в статические документы с обновлением содержимого. В этом варианте возможно осуществлять изменение БД из интерфейса обслуживающей программы[8, стр. 45-47]. При описании алгоритма работы системы формирования экономической информации в ЭИС АСУПП необходимо обратить внимание на то, что вложенность комплексных продуктов ресторана не ограничена никакими внешними условиями и поэтому при разработке базы данных для ввода и хранения информации необходимо предусмотреть её динамический характер - при необходимости должен автоматически создаваться новый уровень данных, куда должен будет осуществляться ввод данных по элементам меню продуктам соответствующего высокого уровня сложности.

Блок-схема алгоритма формирования комплексных элементов меню в ЭИС АСУПП, осуществляемая менеджерами ООО «Альянс» с использованием доступа к ресурсам ЭИС по локальной сети фирмы, представлена на рисунке 2. 15:

Рис. 2. 15. Блок-схема алгоритма внесения и редактирования информационных блоков в базе данных ЭИС АСУПП

2. 5 Обоснование проектных решений по программному обеспечению комплекса задач автоматизации производственных процессов в ресторане «Альянс»

Логически в современной реляционной СУБД можно выделить наиболее внутреннюю часть - ядро СУБД (часто его называют Data Base Engine), компилятор языка БД (обычно SQL, а в предыдущем параграфе было отмечено, что использование языка запросов является оптимальным решением в случае построения ЭИС ресторана «Альянс»), подсистему поддержки времени выполнения, набор утилит. В некоторых системах эти части выделяются явно, в других - нет, но логически такое разделение можно провести во всех СУБД. Ядро СУБД отвечает за управление данными во внешней памяти, управление буферами оперативной памяти, управление транзакциями и журнализацию. Ядро СУБД обладает собственным интерфейсом, не доступным пользователям напрямую и используемым в программах, производимых компилятором SQL (или в подсистеме поддержки выполнения таких программ) и утилитах БД. Ядро СУБД является основной резидентной частью СУБД. При использовании архитектуры "клиент-сервер" ядро является основной составляющей серверной части системы. Основной функцией компилятора языка БД является компиляция операторов языка БД в некоторую выполняемую программу. Основной проблемой реляционных СУБД является то, что языки этих систем являются непроцедурными, т. е. в операторе такого языка специфицируется некоторое действие над БД, но эта спецификация не является процедурой, а лишь описывает в некоторой форме условия совершения желаемого действия. Поэтому компилятор должен решить, каким образом выполнять оператор языка прежде, чем произвести программу [18, стр. 63]. Требования, предъявляемые к современным СУБД:

1. Поддержка определённой логической модели данных.

2. Наличие встроенных языковых средств, в том числе:

а) язык определения данных - Data Definition Language(DDL).

б) языки манипулирования данных - Data Manipulation Language(DML).

в) язык запросов - Query Language(QL).

3. Наличие графического интерфейса, в котором можно выделить: интерфейс пользователя(User Interface), интерфейс разработчика(Developer Interface), интерфейс администратора(Administrator Interface).

4. Наличие подсистемы словаря данных и системного каталога.

5. Наличие программных средств контроля целостности данных.

6. Наличие средств разграничения доступа к данным.

7. Наличие средств документирования разрабатываемых проектов.

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

Microsoft Access - это функционально полная реляционная СУБД. В ней предусмотрены все необходимые средства для определения и обработки данных, а также для управления ими при работе с большими объемами информации. В Access существуют средства просмотра и манипулирования объектами базы данных [9, стр. 34-37]:

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

- полоса объектов, предназначенная для просмотра объектов БД. Ее вертикальное расположение более удобно в использовании;

- ярлыки в окне базы данных ускоряют создание объектов с помощью Мастеров или открытие новых объектов в режиме Конструктора:

- настройка способов выбора и открытия объектов в окне базы данных;

К существующим возможностям, облегчающим работу с данными и проектирование базы данных, в среде Microsoft Access относятся следующие:

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

- можно свободно перемещаться между диалоговыми окнами поиска, замены и работы с данными;

- возможен просмотр и редактирование связанных записей в режиме таблицы (subdatasheet);

- автоматическое обнаружение ошибок переименования позволяет корректировать общие ошибки, вызванные переименованием форм, отчетов, таблиц, запросов, полей, текстовых боксов (text boxes) и других элементов управления;

- поддержка 16-разрядного стандарта код ировки символов Unicode;

- использование Microsoft ActiveX Data Objects (ADO) для доступа и манипулирования данными в базах данных сервера.

Microsoft Access предоставляет максимальную свободу в задании типа ваших данных (текст, числовые данные, даты, время, денежные значения, рисунки, звук, документы, электронные таблицы). Можно задать также форматы хранения и представления этих данных при выводе на экран или печать. Microsoft Access может работать с большим числом самых разнообразных форматов данных, включая файловые структуры других СУБД. Можно оосуществлять импорт и экспорт данных из файлов текстовых редакторов или электронных таблиц. С помощью Access вы можно непосредственно обрабатывать файлы Paradox, dBASE III, dBASE IV, Btrieve, FoxPro и др. В Microsoft Access для обработки данных ваших таблиц используется мощный язык SQL (Structured Query Language -- Структурированный язык запросов). Используя SQL, можно выделить из одной или нескольких таблиц необходимую для решения конкретной задачи информацию. Access значительно упрощает задачу обработки данных. При любой обработке данных из нескольких таблиц Access использует однажды заданные вами связи между таблицами [4, стр. 82-85].