Автоматизация бизнес-процессов продажи билетов ООО "Зритель"

Распределение предоставляемых финансовых средств:

Как бы точно ни была рассчитана финансовая потребность проекта, реальная жизнь вносит свои коррективы в априорный план. В этой связи задача распределения финансовых средств возникает независимо от того, какого типа проект выполняется.

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

Основой стратегии распределения финансовых средств служат календарный план, сетевой график и рассчитанные финансовые потребности проекта. По ним менеджер составляет смету проекта с привязкой затрат к срокам их проведения. Утвержденная смета -- есть фиксированное распределение финансовых ресурсов. Неутвержденная смета требует своего пересмотра, иными словами, перераспределения финансовых ресурсов.

Неутверждённые сметы возможно в трех случаях:

· при обнаружении в ней разного рода ошибок;

· при нарушении общего баланса: суммарные расходы превышают суммарные плановые доходы;

· при локальном (в какие-либо периоды) расхождении предоставляемых средств с объявленной в смете потребностью.

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

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

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

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

Выделить работы, которые можно отложить, c нарушением времени выполнения проекта и за счет этого сократить ресурсную потребность, как это делается на шаге 1. Согласовать с заказчиком перенос сроков.

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

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

Выделить максимально большую часть работ проекта, которая выполнима при заданном финансировании.

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

2.2 Информационное обеспечение задачи

2.2.2 Информационная модель и её описание

Задача использует одну БД, которая размещена вместе с сайтом системы. Ниже (табл. 2.3) приведена таблица наборов данных задачи.

Таблица 2.3.

Перечень и описание структурных единиц входных документов

На рис. 2.6 приведена информационная модель логического уровня БД.

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

При проектировании БД необходимо обеспечить формирование таблиц в порядке от файлов НИИ к оперативным файлам. При заполнении данными файлов, нужно вводить данные в такой же последовательности, то есть, заполнить данными файлы НИИ, а только потом предоставить возможность пользователям наполнять данными файлы оперативной информации.

Рис. 2.6. Информационная модель логического уровня БД

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

Сумма заказа клиента - складывается из суммы стоимостей билетов, учитывая их количество.

Формула 2.1.

,

где,

Sum - сумма j-го заказа клиента;

Price - цена i-того билета в j-м заказе;

Count - количество i-того билета в j-м заказе;

n - количество разновидностей билетов.

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

Формула 2.2.

,

где,

Sum - сумма заказов за день;

m - количество заказов за день.

2.2.3 Используемые классификаторы и системы кодирования

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

Таблица 2.4.

Описание системы кодировки

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

Для решения задачи требуется наличие всех данных о билетах и их характеристиках. Также от СУБД требуется сохранение всех видов целостности БД при функционировании задачи.

Таблица 2.5.

Словарь данных

2.2.4 Характеристика нормативно-справочной, входной и оперативной информации

Таблица 2.6.

Перечень входных и исходных сообщений (документов)

Таблица 2.7.

Список входных документов

2.2.5 Характеристика результатной информации

Таблица 2.8.

Список исходных документов

2.2.6 Формализация расчётов показателей

Таблица 2.9.

Формализация таблиц БД и расчет приблизительного объема БД

Страницы: 1, 2, 3, 4, 5