Автоматизация бизнес-процессов продажи билетов ООО "Зритель" (стр. 12 из 17)
В третьем случае ставится болезненная задача перераспределения ресурсов, найти решение которой необходимо менеджеру. Ниже предлагается один из возможных подходов к перераспределению, согласно которому выполняются следующие шаги:
Выделить работы, которые можно отложить, не нарушая сетевого графика проекта (возможны сдвиги времени планируемого начала работы, изменение фактической продолжительности работы, когда это сокращает ресурсную потребность работы).
Выделить работы, которые можно отложить, c нарушением времени выполнения проекта и за счет этого сократить ресурсную потребность, как это делается на шаге 1. Согласовать с заказчиком перенос сроков.
Выделить части операционных маршрутов сетевого графика, соответствующие работы которых относительно замкнуты и допускают независимую разработку, и оценить их финансовую потребность. Определить наиболее ресурсоемкие из таких частных маршрутов и результирующие работы, выполнение которых не может быть осуществлено без прохождения каждого из них. Установить и согласовать с заказчиком, какими из этих работ можно пожертвовать с незначительной потерей достигаемых целей проекта.
Частный случай предыдущего: произвести переоценку значимости достигаемых целей и соответствующих им работ. Быть может, в проекте чрезмерное внимание уделено демонстрационным задачам, повышению эффективности. Возможно, что проект перегружен за счет работ, ориентированных на переиспользование в будущем. Этот список легко продолжить.
Выделить максимально большую часть работ проекта, которая выполнима при заданном финансировании.
Общий принцип любой стратегии распределения финансов состоит в том, чтобы максимально полно обеспечить финансовую потребность решения ближайших задач проекта.
2.2 Информационное обеспечение задачи
2.2.2 Информационная модель и её описание
Задача использует одну БД, которая размещена вместе с сайтом системы. Ниже (табл. 2.3) приведена таблица наборов данных задачи.
Таблица 2.3.
Перечень и описание структурных единиц входных документов
| Наименование структурной единицы | Точность числового значения | Источникинформации (документ, массив) | Идентификатор источника |
| Окончательная ведомость | |||
| Дата ведомостиКод билетаНаименование билетаКоличество билетаЦена билетаСтоимость билета | 99.X(8).9999999999X(150)9999999999999,9999999999,99 | Состав | Sclad |
На рис. 2.6 приведена информационная модель логического уровня БД.
При формулировке требований в БД было определено: БД должна быть свободно переносимой, хранить данные о клиентах, заказах клиентов, характеристиках билетов и обеспечивать некоторые возможности для динамического формирования документа.
При проектировании БД необходимо обеспечить формирование таблиц в порядке от файлов НИИ к оперативным файлам. При заполнении данными файлов, нужно вводить данные в такой же последовательности, то есть, заполнить данными файлы НИИ, а только потом предоставить возможность пользователям наполнять данными файлы оперативной информации.
Рис. 2.6. Информационная модель логического уровня БД
Так как программа реализует учетные функции, то такой экономико-математической модели решения задачи не существует. Но можно выделить некоторые показатели, которые рассчитываются при формировании реестра заказов.
Сумма заказа клиента – складывается из суммы стоимостей билетов, учитывая их количество.
Формула 2.1.
,где,
Sum- сумма j-го заказа клиента;
Price - цена i-того билета в j-м заказе;
Count- количество i-того билета в j-м заказе;
n - количество разновидностей билетов.
Сумма заказов за день – складывается из общей суммы всех заказов клиентов на определенную дату.
Формула 2.2.
,где,
Sum- сумма заказов за день;
m - количество заказов за день.
2.2.3 Используемые классификаторы и системы кодирования
Анализируя алгоритм решения задачи можно сказать, что он носит учетный характер. Клиент последовательно проходит этап регистрации, добавление билетов в корзину и регистрацию заказа в БД.
Таблица 2.4.
Описание системы кодировки
| Наименование признака | Значительность | Система кодировки | Структура кодового обозначения |
| Код покупателя | 5 | последовательная | 99999 |
| Код билета | 6 | последовательная | 999999 |
| Код заказа | 6 | последовательная | 999999 |
| Код вида оплаты | 1 | последовательная | 9 |
| Код категории билета | 2 | последовательная | 99 |
| Код характеристики | 2 | последовательная | 99 |
Алгоритм решения задачи необходим для формирования реестра подтвержденных заказов клиентов, поэтому в программе реализуются методы поддержки ведения справочника клиента и его заказов.
Для решения задачи требуется наличие всех данных о билетах и их характеристиках. Также от СУБД требуется сохранение всех видов целостности БД при функционировании задачи.
Таблица 2.5.
Словарь данных
| №данных | Название элемента данных | Идентификатор | Тип, длина иточность | Назначение |
| 1. | № платежного поручения | Por_id | 9999 | Для однозначной идентификации поручений |
| 2. | Банк получателя | Por_bnk_pol | Х(50) | Наименование банка получателя |
| 3. | Банк плательщика | Por_bk_plt_naim | Х(50) | Наименование банка плательщика |
| 4. | Вид оплаты | Ps_id | Х | Код вида оплаты |
| 5. | Дата ведомости | vdata | 99.X(8).9999 | Для разделения остатков|на дату |
| 6. | Дата получения банком | Por_bk_date | 99.X(8).9999 | |
| 7. | Дата оформления поручения | Por_date | 99.X(8).9999 | Дата оформления поручения |
| 8. | Дата прайс-листа | Pr_date | 99.X(8).9999 | Дата прайс-листа |
| 9. | Дата проведения банком | Por_bnk_prov | 99.X(8).9999 | Дата проведения банком |
| 10. | Дата реестра | Re_date | 99.99.9999 | Дата реестра |
| 11. | Дебет счета № | Por_deb_c | Х(14) | Дебет счета № |
| 12. | Код банка получателя | Por_bnk_pol_id | Х(6) | Для однозначной идентификации банка |
| 13. | Код банка плательщика | Por_plat_bnk_id | Х(6) | Для однозначной идентификации банка |
| 14. | Код клиента | id | 99999 | Для однозначной идентификации клиента |
| 15. | Код получателя | Por_pol_id | Х(14) | Для однозначной идентификации получателя |
| 16. | Код плательщика | Por_plat_id | Х(14) | Для однозначной идентификации плательщика |
| 17. | Код билета | pr_id | 999999 | Для однозначной идентификации |
| 18. | Кредит счета № | Por_cred_c | Х(14) | Кредит счета № |
| 19. | Наименование категории билета | Cat_naim | X(50) | Для различения |
| 20. | Наименование билета | name | X(150) | Для пользователей билетов |
| 21. | Номер заказа | o_id | 99999 | Для однозначной идентификации заказа |
| 22. | Получатель | Por_pol_naim | Х(50) | Наименование получателя |
| 23. | ФИО клиента | fio | Х(70) | ФИО клиента |
| 24. | Плательщик | Por_plat_naim | Х(50) | Наименование латника |
| 25. | Назначение платежа | Por_nazn | Х(80) | Назначение платежа |
| 26. | Сумма платежа | Por_sum | 99999,99 | Сумма платежа |
| 28. | Цена билета | price | 99999,99 | Для оценки остатков| |
| 29. | Наименование характеристики билета | Prop_naim | X(80) | Наименование характеристики билета |
| 30. | Значение характеристики билета | Value_ | X(100) | Значение характеристики билета |
2.2.4 Характеристика нормативно-справочной, входной и оперативной информации
Таблица 2.6.
Перечень входных и исходных сообщений (документов)
| Код документа | Название документа | Входной или исходный|выходной| |
| 0805704 | Окончательная ведомость | Входной |
| 0811301 | Прайс-лист | Выходной |
| 0811902 | Реестр подтвержденных заказов | Выходной |
| 0811903 | Платежное поручение | Выходной |
Таблица 2.7.
Список входных документов
| №данных | Название реквизита | Фактический илирассчитанный | Назначение |
| 1. | Стоимость билетов | рассчитанный | Для оценки остатков| |
| 2. | Дата ведомости | фактический | Для разделения остатков за датой |
| 3. | Кол-во билетов | рассчитанный | Для оценки остатков |
| 4. | Код билетов | фактический | Для однозначной идентификации билетов |
| 5. | Наименование билетов | фактический | Для покупателей билетов |
| 6. | Цена билетов | фактический | Для оценки остатков| |
2.2.5 Характеристика результатной информации