Разработка автоматизированной системы управления производственными процессами ресторана "Альянс"

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

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 27.11.2012
Размер файла 2,3 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

GROUP BY [Запрос Заказы]. Код Заказа;

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

Рис. 3.9. Запрос Заявка План Меню в режиме конструктора

В формате SQL запрос имеет вид:

SELECT [План-меню]. Дата , Блюда Состав Поставщики. Код Продукта, Блюда Состав Поставщики. Самый Дешевый Поставщик. Название, Блюда Состав Поставщики. Количество, Блюда Состав Поставщики. Поставщики. Название, Блюда Состав Поставщики. [Min-Цена], Sum([План-Меню. Количество]*[Блюда Состав Поставщики. Количество]) AS Заказ Продукта

FROM [План-меню] INNER JOIN Блюда Состав Поставщики ON [План-меню]. Код Блюда = Блюда Состав Поставщики. Код Блюда

GROUP BY [План-меню]. Дата , Блюда Состав Поставщики. Код Продукта, Блюда Состав Поставщики. Самый Дешевый Поставщик. Название, Блюда Состав Поставщики. Количество, Блюда Состав Поставщики. Поставщики. Название, Блюда Состав Поставщики. [Min-Цена];

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

SELECT Заявка План Меню. Дата , Заявка План Меню. Код Продукта, Заявка План Меню. Поставщики. Название, Заявка План Меню. [Min-Цена], Заявка План Меню. Заказ Продукта, [Min-Цена]*[Заказ Продукта] AS Сумма

FROM Заявка План Меню;

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

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

PARAMETERS [Forms]![Продажи по годам]![Начальная Дата ] DateTime, [Forms]![Продажи по годам]![Конечная Дата ] DateTime;

SELECT Sum(Стоимость Заказа. Цена Расчета) AS [Sum-Цена Расчета]

FROM Заказы INNER JOIN Стоимость Заказа ON Заказы. Код Заказа = Стоимость Заказа. Код Заказа;

В результате выполнения такого запроса будет выдана итоговая сумма всех продаж ресторана за промежуток между введенными в управляющую форму начальной и конечной датой, т. е. сумму заказов клиентов, дата регистрации которых находится между значениями Forms![Продажи по годам]!Начальная Дата и Forms![Продажи по годам]!Конечная Дата .

Для того, чтобы получить анализ продаж за предыдущий 2011 год, сформируем запрос Продажи товаров в 2011 вида:

SELECT Блюда. Код Блюда, Блюда. Название Блюда, Sum(CCur([Блюда Цена]. [Цена]*[Количество]*(1-[Скидка %])/100)*100) AS Продажи Товаров, "Кв " & DatePart("q", [Дата Заказа]) AS Квартал Размещения

FROM (Блюда INNER JOIN (Заказы INNER JOIN Заказано ON Заказы. Код Заказа = Заказано. Код Заказа) ON Блюда. Код Блюда = Заказано. Код Блюда) INNER JOIN Блюда Цена ON Блюда. Код Блюда = Блюда Цена. Код Блюда

WHERE (((Заказы. Дата Заказа) Between #1/1/2011# And #12/31/2011#))

GROUP BY Блюда. Код Блюда, Блюда. Название Блюда, "Кв " & DatePart("q", [Дата Заказа]);

Запрос Товары с ценой выше средней можно сформировать следующими инструкциями:

SELECT Блюда. Код Блюда, Блюда. Название Блюда, Блюда Цена. Цена

FROM Блюда INNER JOIN Блюда Цена ON Блюда. Код Блюда = Блюда Цена. Код Блюда

WHERE (((Блюда Цена. Цена)>(SELECT AVG([Цена]) From Блюда Цена)));

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

SELECT Сотрудники. Код Сотрудника, Сотрудники. ФИО, Заказано. Код Заказа, Заказы. НомерСтолика, Обслуживание. ВремяОбслуживания, Заказы. Дата Заказа, СтоимостьЗаказа. ЦенаРасчета

FROM (Сотрудники INNER JOIN ((Заказы INNER JOIN Заказано ON Заказы. Код Заказа = Заказано. Код Заказа) INNER JOIN Обслуживание ON Заказы. Код Заказа = Обслуживание. Код Заказа) ON Сотрудники. Код Сотрудника = Обслуживание. Код Сотрудника) INNER JOIN СтоимостьЗаказа ON Заказы. Код Заказа = СтоимостьЗаказа. Код Заказа

GROUP BY Сотрудники. Код Сотрудника, Сотрудники. ФИО, Заказано. Код Заказа, Заказы. НомерСтолика, Обслуживание. ВремяОбслуживания, Заказы. Дата Заказа, СтоимостьЗаказа. ЦенаРасчета

HAVING (((Заказы. Дата Заказа) Between [Начальная дата ] And [Конечная дата ]));

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

SELECT Заказы. Код Заказа, Заказы. Дата Заказа, Заказы. Номер Столика, Обслуживание. Код Сотрудника, Обслуживание. Время Обслуживания, Заказано. Код Блюда, Блюда. Название Блюда, Заказано. Количество, Заказано. [Скидка %], [План-меню]. Отпускная Цена

FROM (Блюда INNER JOIN ((Заказы INNER JOIN Обслуживание ON Заказы. Код Заказа = Обслуживание. Код Заказа) INNER JOIN Заказано ON Заказы. Код Заказа = Заказано. Код Заказа) ON Блюда. Код Блюда = Заказано. Код Блюда) INNER JOIN [План-меню] ON (Заказы. Дата Заказа = [План-меню]. Дата ) AND (Блюда. Код Блюда = [План меню]. Код Блюда);

Рисунок 3. 10. Запрос Счета в режиме конструктора

Последний необходимый запрос Квартальные обороты по товарам. Это должен быть сложный перекрестный запрос. В режиме конструктора запрос будет иметь вид:

Рисунок 3. 11. - Перекрестный запрос Квартальные обороты по товарам

Его SQL-код :

TRANSFORM Sum(CCur([План-меню]![ОтпускнаяЦена]*[Заказано]![Количество]*(1-[Заказано]![Скидка %]/100))) AS Сумма По Товару

SELECT Блюда. Название Блюда, Заказы. Код Заказа, Year([Дата Заказа]) AS Год Заказа

FROM (Блюда INNER JOIN (Заказы INNER JOIN Заказано ON Заказы. Код Заказа = Заказано. Код Заказа) ON Блюда. Код Блюда = Заказано. Код Блюда) INNER JOIN [План-меню] ON Блюда. Код Блюда = [План-меню]. Код Блюда

WHERE (((Заказы. Дата Заказа) Between #1/1/2005# And #12/31/2009#))

GROUP BY Блюда. Название Блюда, Заказы. Код Заказа, Year([Дата Заказа])

PIVOT @Rd @ & DatePart(@q@?[LfnfPfrfpf]?1?0) In (@Rd 1@?@Rd 2@?@Rd 3@?@Rd 4@)$

3.2.2 Разработка системы отчетов базы данных ЭИС АСУПП ресторана «Альянс»

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

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

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

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

4. Отчет Суммы продаж по кварталам строится на основе одноименного отчета.

5. Отчет Счет формирует для каждого заказа счет на оплату. Ранее для его построения был сконструирован запрос Счет.

6. Отчет Продажи по сотрудникам строится на основе одноименного запроса.

Начнем конструировать отчеты. Отчет Стоимость Заказов имеет наиболее простую структуру. Она представлена на рисунке 3. 12.

Рис. 3. 13. Структура отчета Стоимость заказов

Рис. 3. 13 Структура отчета о блюдах, предлагаемых рестораном

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

Рис. 3.14. Меню ресторана на заданную дату в режиме конструктора

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

Рис. 3. 15. Заявка на поставки продуктов в режиме конструктора

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

Рисунок 3. 16. Структура отчета Продажи по сотрудникам

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

Option Compare Database ' Сортировка базы данных для сравнения строк.

Option Explicit ' Обязательное описание переменных перед их применением.

Private Sub Заголовок Группы0_Format(Cancel As Integer, FormatCount As Integer)

' Задание номера страницы 1 в начале новой группы.

Page = 1

End Sub

Private Sub Заголовок Группы2_Format(Cancel As Integer, FormatCount As Integer)

' Отображение строк Оптимальный Результат Надпись и Продавец Надпись,

' итоги продавца удовлетворяют условиям отбора.

If Me!Итоги Продавца > 50000 Then

Me!Оптимальный Результат Надпись. Visible = True

Me!Продавец Надпись. Visible = True

Else

Me!Оптимальный Результат Надпись. Visible = False

Me!Продавец Надпись. Visible = False

End If

End Sub

Private Sub Report_NoData(Cancel As Integer)

' Отображение сообщения, если пользователь ввел диапазон дат, для которого отсутствуют записи, вместо просмотра и печати отчета.

Dim strMsg As String, strTitle As String

Dim intStyle As Integer

strMsg = "Необходимо ввести дату с 01 января 05 г. по 31 декабря 08 г."

intStyle = vbOKOnly

strTitle = "Данные отсутствуют"

MsgBox strMsg, intStyle, strTitle

Cancel = True

End Sub

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

SELECT Заказы. Дата Заказа, Заказано. Код Заказа, Стоимость Заказа. Цена Расчета

FROM Заказы INNER JOIN (Заказано INNER JOIN Стоимость Заказа ON Заказано. Код Заказа = Стоимость Заказа. Код Заказа) ON (Стоимость Заказа. Код Заказа = Заказы. Код Заказа) AND (Заказы. Код Заказа = Заказано. Код Заказа)

GROUP BY Заказы. Дата Заказа, Заказано. Код Заказа, Стоимость Заказа. Цена Расчета;

Сам отчет имеет вид:

Рисунок 3. 17. Структура отчета Суммы продаж по кварталам

В конструкции отчета мы используем функцию вида =DatePart("q";[Дата Заказа]) для определения квартала размещения заказа. Функция =Format(Date();"dd-mmm-yyyy") задает текущую дату.

Источником записей для отчета Продажи по годам является одноименный запрос. Для определения уровней группировки отчета воспользуемся функцией сортировка и группировка Microsoft Access. Конструкция отчета имеет вид:

Рисунок 3. 18. Структура отчета Продажи по годам

Наконец, структура отчета Счет имеет вид:

Рисунок 3. 19. Структура отчета Счет

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

Рисунок 3. 20. Структура макроса, осуществляющего фильтрацию поставщиков по алфавиту

Сама форму имеет следующий вид:

Рисунок 3. 21. Форма Телефоны поставщиков в режиме конструктора

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

PARAMETERS [Дата Заказа] DateTime;

SELECT Анализ Выполнения Плана. Дата Заказа, Анализ Выполнения Плана. Код Блюда, Анализ Выполнения Плана. Название Блюда, Анализ Выполнения Плана. Количество, Анализ Выполнения Плана. [Sum-Количество], [Количество]-[Sum-Количество] AS Отклонение, ([Количество]-[Sum-Количество])*100/[Количество] AS [Процент отклонения]

FROM Анализ Выполнения Плана

WHERE (((Анализ Выполнения Плана. Дата Заказа)=[Дата Заказа]));

Внешний вид построенного отчета в режиме конструктора имеет вид:

Рис. 3.22. Отчет, отражающий фактическое выполнение плана работы, в режиме конструктора

3.3 Технологическое обеспечение работы программного комплекса ЭИС АСУПП ресторана «Альянс»

3.3.1 Организация сбора, ввода данных и выдачи информации в базе данных

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

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

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

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

4. Таблица Продукты формируется технологами цехов и старшим технологом ресторана. Все они должны иметь неограниченный доступ к данным этой таблицы.

5. Таблицы Состав и Рецепты формируют также технологи цехов и старший технолог ресторана.

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

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

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

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

Рис. 3. 23. Главная кнопочная форма

Заметим, что кнопки этой формы пока что вызывают еще несозданные формы: при нажатии кнопки Сотрудники будет открыта форма Сотрудники, при нажатии кнопки Поставщики будет открыта форма Поставщики, при нажатии кнопки Продукты будет открыта форма Продукты при нажатии кнопки Заказы произойдет открытие формы Заказы.

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

Рисунок 3.24. Форма Сотрудники базы данных ООО «Альянс»

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

Рисунок 3.25. Форма Товары базы данных ООО «Альянс»

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

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

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

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

Рисунок 3.26. Форма Поставщики базы данных ООО «Альянс»

Теперь для правильной работы кнопки Ввод товаров необходимо корректно написать процедуру обработки событий нажатия этой кнопки на языке Visual Basic в отладчике VB для базы данных ООО «Альянс». Соответствующий листинг с комментариями имеет вид:

Private Sub ВводТоваров_Click()

On Error GoTo Err_ВводТоваров_Click

Dim strDocName As String

strDocName = "Товары"

' Открытие формы "Товары" в режиме ввода данных.

' Сохранение значения поля Код Поставщика в аргументе OpenArgs формы.

DoCmd. OpenForm strDocName, , , , acAdd, , Me!Код Поставщика

' Закрытие формы "Список товаров".

DoCmd. Close acForm, "Список товаров" ' Передача фокуса элементу "Название".

Forms![Товары]!Название. SetFocus

Exit_Ввод Товаров_Click:

Exit Sub

Err_Ввод Товаров_Click:

MsgBox Err. Description

Resume Exit_Ввод Товаров_Click

End Sub

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

Рисунок 3.27 Форма Список товаров в режиме конструктора.

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

Private Sub ПросмотрТоваров_Click()

On Error GoTo Err_ПросмотрТоваров_Click

Dim strMsg As String, strTitle As String

Dim intStyle As Integer

Dim strDocName As String, strLinkCriteria As String

' Если элемент "Название" пуст, выдается сообщение.

If IsNull(Me![Название]) Then strMsg = "Перейдите на запись поставщика, чьи товары нужно просмотреть, и вновь нажмите кнопку ""Просмотр товаров"". "

intStyle = vbOKOnly

strTitle = "Выберите поставщика"

MsgBox strMsg, intStyle, strTitle

Me![Название]. SetFocus

Else

'Иначе форма "Список товаров" открывается для товаров текущего поставщика.

strDocName = "Список товаров"

strLinkCriteria = "[Код Поставщика] = Forms![Поставщики]![Код Поставщика]"

DoCmd. OpenForm strDocName, , , strLinkCriteria

DoCmd. MoveSize (1440 * 0. 78), (1440 * 1. 8)

End If

Exit_Просмотр Товаров_Click:

Exit Sub

Err_Просмотр Товаров_Click:

MsgBox Err. Description

Resume Exit_Просмотр Товаров_Click

End Sub

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

Форма продукты в режиме конструктора имеет вид:

Рис. 3.28 Форма Продукты в режиме конструктора

Форму Заказы целесообразно выполнить в виде двух вкладов: Заказы по сотрудникам и Содержание заказа. В первой вкладе будут отражены все заказы, выполненные данным сотрудником ресторана с основными сведениями по этим заказам, а вторая вкладка позволяет вносить свeдения по каждому заказу. Фактически с данной вкладкой будут работать оперативные работники зала и вносимые ими сведения должны стать основой для выписки счетов посетителям. В режиме конструктора форма имеет вид:

Рис. 3.29 Форма Заказы в режиме конструктора

Форма План-меню служит для ввода данных для формирования плана-меню, её конструкция приведена на рисунке внизу:

Рис. 3. 20. Форма План-меню в режиме конструктора

При нажатии кнопки Печать отчетов пользователь может просмотреть или напечатать все построенные в предыдущих разделах отчеты. Форма навигации по системе отчетов имеет вид:

Рис. 3. 21. Форма Отчеты в режиме конструктора

3.3.2 Схема технологического процесса сбора, передачи, обработки и выдачи информации

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

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

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

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

4. Экономическое обоснование проекта

4.1 Оценка затрат на внедрение автоматизированной системы управления производственными процессами ресторана «Альянс»

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

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

Таблица 4.1 Трудоемкость работ по разработке проекта

Наименование работ

Трудоемкость, чел/дни

Руководитель проекта

Ведущий программист

Инженер-программист

Разработка технического задания

2

2

-

Разработка методов решения задачи. Выбор ПО

2

1

2

Разработка структуры решения задачи

1

3

2

Создание интерфейса программного модуля

-

5

-

Организация рабочих мест пользователей

-

3

4

Тестирование и отладка основных модулей комплекса

-

2

5

Тестирование и отладка всего комплекса в сетевом варианте

1

2

5

Составление технической документации

1

2

4

Сдача проекта

1

1

1

ИТОГО:

8

21

23

Стоимость рабочего дня, руб

900

750

700

Расходы

7200

15750

16100

Итого совокупные расходы на зарплату составляют 39, 05 тыс. руб. Отчисления в фонды социального страхования составят 10, 15 тыс. руб. Получаем итоговую сумму в размере 49, 2 тыс руб. После разворачивания комплекса становятся неизбежными текущие затраты на его обслуживание, которые отражены в таблице 3. 3. При расчете исходим из того, что для оперативного обслуживания АСУПП необходимо привлечение еще одного сотрудника с окладом 17 тыс. руб в месяц.
Таблица 4.2 Текущие затраты на обслуживание АСУПП «Альянс» за месяц

Наименование

Сумма

Количество

Общая сумма расходов (тыс. руб)

Зарплата дежурного инженера

17

1

17

Социальные платежи

15, 08

1

7, 5

Техобслуживание (1, 66% от стоимости)

14

1

14

ИТОГО

63, 08

Итого текущие затраты за год составят 462 тыс. руб.

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

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

Эффект от автоматизации от внедрения нового программно-технологического комплекса, как известно, возникает в сфере управления процессом производства и сфере самого производства. Сегодня эффект в сфере управления может быть достаточно точно определен и полученная оценка будет достоверна. А вот эффект от компьютеризации управленческого труда в сфере производства проявляется опосредствовано. В большей части методик расчета экономической эффективности от применения ИТ используются экспертные оценки влияния ИТ на те или иные показатели деятельности самого объекта. На этих принципах базировалась большая часть методик расчета экономической эффективности применения компьютерных ИТ. Степень достоверности таких расчетов невелика. Необходим поиск методов повышения достоверности расчетов экономического эффекта применения ИТ и разработка наглядной и убедительной методики его расчета [12, стр. 77-78].

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

Таблица 4.3 Вариант классификации основных источников экономической эффективности применения ИТ [53, стр. 112]

Источники эффективности

Косвенные

Прямые

Измеримые

Неизмеримые

Измеримые

Неизмеримые

1 Улучшение использования трудовых, материальных и финансовых ресурсов.

2 Снижение и ликвидация трудовых, материальных и финансовых потерь от недостатков управления.

3 Рост выпуска продукции, производительности труда, повышение эффективности производства.

1 Совершенство-вание управления социально- экономического развития.

2 Улучшение социально - психологического климата в трудовом коллективе.

1 Снижение трудоемкости работ по управлению.

2 Снижение затрат на управление.

3 Рост производительности управленческого труда.

4 Снижение удельного веса управленческого персонала в общей численности работающих.

5 Оперативность получения информации о ходе производства.

1 Повышение культуры управленческого труда.

2 Облегчение труда.

3 Повышение качества информации.

4 Углубление и совершенствование методов управления.

В условиях инфляционных процессов при оценке эффективности инвестиционных проектов используют методы дисконтирования. Существующие варианты дисконтирования исходят из предположения, что деньги, расходуемые в будущем, будут иметь меньшую ценность, чем в настоящее время. Для этого все затраты, связанные с осуществлением проекта, приводят к масштабу цен, сопоставимому с имеющимися сегодня. Такой пересчет называют дисконтированием (уценкой). Расчет коэффициентов приведения производится на основании ставки сравнения (коэффициента дисконтирования или нормы дисконта). Коэффициент пересчета характеризует темп снижения ценности денежных ресурсов с течением времени. Значение коэффициента пересчета всегда меньше единицы. Дисконтирование осуществляют к определенному году (как правило к году внедрения). В этом случае показатель называют коэффициентом дисконтирования. В том случае, если приведение осуществляется к сегодняшнему моменту времени, расчетный показатель называют коэффициентом отдаленности. При дисконтировании интересующий нас показатель умножается на указанные коэффициенты [12, стр. 92-94].

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

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

Годовая экономия затрат на обработку информации, связанная с внедрением ПС ВТ определяется по формуле [11, стр. 99]:

С = Ср - См ,

где С - годовая экономия затрат на обработку информации, связанная с внедрением ПС ВТ;

Ср - затраты на подготовку и обработку информации в базовом варианте, т. руб;

См - затраты на обработку информации при внедрении ЭИС АСУПП, т. руб.

Составляющие формулы определяются следующим образом.

Ср = (Qвх, б + Qвых, б) Цр Гд / Нвыр, р ,

где Qвх, б , Qвых, б - объем входной и выходной информации, обрабатываемой в базовом варианте соответственно, в тыс. док. ;

Цр - стоимость одного часа ручной обработки информации, руб / час;

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

Нвыр, р - норма выработки при ручной работе, док. / час.

Стоимость одного часа ручной обработки информации определяется следующим образом [12, стр. 109-111]:

Цр = Зм W Кн / T ,

где Зм - среднемесячная заработная плата пользователя, руб;

W - коэффициент начисления на заработную плату;

Т - среднемесячный фонд рабочего времени, час;

Кн - коэффициент, учитывающий накладные расходы.

Затраты на обработку информации при использовании внедренного ПС ВТ определяется следующим образом [11, стр. 117]:

См = Сп + Соб ,

где Сп - затраты на подготовку информации и ввод информации для реализации функций, автоматизированных в ПС ВТ, т. руб;

Соб - затраты на машинное время для реализации функций, автоматизированных в ПС ВТ, т. руб.

Компоненты, входящие в последнюю формулу, определяются следующим образом:

Сп = (Цр + Цмч) Qвх, н / Нвыр, а ,

где Qвх, н - объем входной информации, обрабатываемой с помощью ПС ВТ (новый вариант), тыс. док. ;

Нвыр, а - норма выработки пользователя при подготовке и вводе информации в ЭВМ, тыс. док. / час;

Цмч - стоимость одного машинного часа работы ЭВМ, руб.

Соб = Тм Цмч ,

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

Тм = (Qвх, н + Qвых, н) Тз ,

где Qвых, н- объем выходной информации, получаемой при использовании ПС ВТ, тыс. док. ;

Тз - среднее время обработки 1000 знаков и вывода информации с использованием ПС ВТ, час / тыс. зн.

Единовременные затраты на создание и внедрение ПС ВТ рассчитываются по формуле:

К = Кп + Кк ,

где К - единовременные затраты на создание и внедрение ПС ВТ с учетом фактора времени, т. руб.

Кп- предпроизводственные затраты ПС ВТ, т. руб. ;

Кк- капитальные вложения (приобретение оборудования, строительно-монтажные и прочие расходы), необходимые для реализации ПС ВТ.

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

Внедрение ПС ВТ будет эффективным, если расчетный коэффициент эффективности капитальных вложений (Ер) будет больше выбранного граничного значения. При этом Ер определяется как:

Ер = С / К Е ,

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

Срок окупаемости капитальных вложений (Ток) рассчитывается по формуле:

Ток = К / С.

Источники формирования исходных данных для расчета эффективности применения ПС ВТ приведены в таблице 4. 4.

Таблица 4.4 Источники формирования исходных данных

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


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.