Проектирование информационной подсистемы ОАО "Автобаза №2"

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

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

Полученные данные заносятся в хранилище данных «Сведения о заказе».



Рис. 7. Диаграмма декомпозиции DFD

Управление и механизмы у данных работ одинаковые: правила по оказанию услуг и сотрудники эксплуатационной службы.

В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой.

Создание модели в стандарте IDEF3.

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

Цель IDEF3 - дать аналитикам описание последовательности выполнения процессов, а также объектов, участвующих совместно в одном процессе.

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

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

Связи (Links) показывают взаимоотношение работ. Различают 3 типа связей:

Связь предшествования (Precedence) - показывает, что прежде чем начнется работа-приемник, должна завершиться работа-источник.

Связь отношения (Relational) - показывает связь между двумя работами или между работой и объектом ссылки.

Поток объектов (Object Flow) - показывает участие некоторого объекта в двух или более работах, как, например, если объект производится в ходе выполнения одной работы и потребляется другой работой.

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

Объекты ссылок (Referents) - служат для выражения идей и концепций без использования специальных методов, таких как стрелки, перекрестки или работы [17].

На диаграмме декомпозиции IDEF3 «Выписка путевого листа» видно, как происходит процесс формирования путевого листа.

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

Оформление товарно-транспортной накладной

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

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



Рис.8. Диаграмма декомпозиции IDEF3

Диаграммы дерева узлов (Node Tree Diagram).



Рис. 9. Диаграмма дерева узлов

2.1.3 Технология Erwin

Для представления информационной модели данных используется CASE-средство ERwin.

ERwin - средство концептуального моделирования БД, использующее методологию IDEF1X. ERwin реализует проектирование схемы БД, генерацию описания на языке целевой СУБД.

Основные получаемые преимущества:

существенное повышение скорости разработки за счет мощного редактора диаграмм, автоматической генерации базы данных, автоматической подготовки документации;

нет необходимости ручной подготовки SQL-предложений для создания базы данных;

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

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

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

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

поддержка однопользовательских СУБД позволяет использовать для персональных систем современные технологии, что значительно упрощает переход от настольных систем к системам в технологии клиент- сервер.

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

ERwin создает визуальное представление (модель данных) для решаемой задачи. Это представление может использоваться для детального анализа, уточнения и распространения документации, необходимой в цикле разработки. Однако ERwin далеко не только инструмент для рисования. ERwin автоматически создает базу данных (таблицы, индексы, хранимые процедуры, триггеры для обеспечения ссылочной целостности и другие объекты, необходимые для управления данными) [26].

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

Этапы построения информационной модели:

определение сущностей;

определение зависимостей между сущностями;

задание первичных и альтернативных ключей;

определение атрибутов сущностей;

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

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

задание триггеров, процедур и ограничений;

генерация базы данных.

Построение моделей в ERwin:

Возможны две точки зрения на информационную модель и, соответственно, два уровня модели:

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

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

Выбор, установка типа отображения данных производится при создании новой модели в диалоговом окне Create Model - Select Template переключателем, что изображено на рисунке 10.



Рис. 10 Выбор отображения модели данный в ERwin

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

Для переключения между логической и физической моделью данных служит список выбора в левой части панели инструментов ERwin (рис. 11).

Рис. 11. Переключение между логической и физической моделью

При переключении, если физической модели еще не существует, она будет создана автоматически.

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

Модель данных включает:

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

Клиенты (номер_клиента, номер_объекта, название, адрес, телефон, объекты). Эта сущность предназначена для хранения информации о потенциальных клиентах автобазы.

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

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

Водители (номер_водителя, ФИО, ИНН, адрес, телефон, номер_удостоверения, категория, основной_маршрут). Эта сущность предназначена для хранения информации о водителях автобазы.

Рис.12. Логическая модель представления данных

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

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

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

Связь на диаграмме отображает логическую зависимость одной сущности от другой. В IDEF1X различают зависимые и независимые сущности. Тип сущности определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Экземпляр зависимой сущности определяется только через отношение к родительской сущности. Зависимая сущность изображается на диаграмме прямоугольником со скругленными углами.

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

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

При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности. Эта операция дополнения атрибутов дочерней сущности при создании связи называется миграцией атрибутов. В дочерней сущности новые атрибуты помечаются как внешний ключ - (FK) [16].

Рис.13. Физическая модель данных

2.1.4 СУБД Access

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

Теперь, на основе созданных ранее отношений можно строить таблицы применительно к конкретной СУБД, в нашем случае это Microsoft Access 2000.

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

Подробная схема информационных процессов в базе данных Ассеss приведена в Приложении 1.

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

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

Для автоматизации программного решения необходимо:

составить перечень входной информации;

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

сделать описание полей (реквизитов) входных документов.

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

Рассмотрим процесс создания и заполнения таблиц данных.

При поступлении данных на предоставлении транспортных услуг заполняется следующая таблица:

Таблица 1 Структура таблицы «Путевые листы»

Имя поля	Тип данных	Размер поля	Ключевое поле
Номер путевого листа	Счетчик	Длинное целое	*
Дата	Дата/время	Длинный формат даты
Транспорт	Числовой	Длинное целое
Марка модель	Текстовый	20
Гос. рег. номер	Текстовый	20
Пробег	Текстовый	20
Тариф	Числовой	Длинное целое
Водитель	Числовой	Длинное целое
Время работы	Числовой	Длинное целое
Маршрут	Текстовой	20
Клиент	Текстовой	20
Объект	Текстовой	20

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

Данная входная информация позволяет формировать итоговые таблицы и отчеты, с использованием запросов.

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

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

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

В базе данных Access существуют следующие виды справочников:

Справочник «Водители»;

Справочник «Транспорт»;

Справочник «Клиенты»;

Справочник «Маршрут»;

Справочник «Объекты»;

Документ «Путевой лист».

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

Рассмотрим структуру указанных справочников в виде таблиц:

Таблица 2 Структура таблицы «Водители»

Имя поля	Тип данных	Размер поля	Ключевое поле
Номер водителя	Счетчик	Длинное целое	*
ФИО	Текстовый	20
ИНН	Текстовый	20
Адрес	Текстовый	20
Телефон	Текстовый	Длинное целое
Номер удостоверения	Текстовый	20
Категория	Текстовый	20
Основной маршрут	Текстовый	20

Таблица 3 Структура таблицы «Транспорт»

Имя поля	Тип данных	Размер поля	Ключевое поле
Номер транспорта	Счетчик	Длинное целое	*
Марка модель	Текстовый	20
Гос. рег. номер	Текстовый	20
Вид транспорта	Текстовый	20
Вид топлива	Текстовый	20
Норма на пробег	Текстовый	20
Инвентарный номер	Текстовый	20
Водитель	Числовой	Длинное целое

Таблица 4 Структура таблицы «Клиенты»

Имя поля	Тип данных	Размер поля	Ключевое поле
Номер клиента	Счетчик	Длинное целое	*
Название	Текстовый	20
Адрес	Текстовый	20
Телефон	Текстовый	20
Объекты	Текстовый	Длинное целое

Таблица 5 Структура таблицы «Маршруты»

Имя поля	Тип данных	Размер поля	Ключевое поле
Номер маршрута	Счетчик	Длинное целое	*
Название	Текстовый	20
Клиент	Числовой	Длинное целое
Объект	Числовой	Длинное целое
Водитель	Числовой	Длинное целое
Транспорт	Текстовый	20
Пробег	Текстовый	20

Таблица 6 Структура таблицы «Объекты»

Имя поля	Тип данных	Размер поля	Ключевое поле
Номер объекта	Счетчик	Длинное целое	*
Название	Текстовый	20
Пробег	Числовой	Длинное целое

2.1.6 Описание экранных форм входной и выходной информации

При запуске базы данных Access появляется экран ввода пароля (рис.14).

Рис. 14. Экранная форма ввода пароля

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

Далее нужно ввести соответствующий пароль и нажать кнопку «OK», либо нажать кнопку «ОТМЕНА» и закончить работу с приложением. Если пароль указан неверно, то на экране отобразиться следующее сообщение (рис. 15).

Рис. 15. Неправильный ввод пароля

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

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

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

Справочник «Водители» (рис.16) содержит следующую информацию:

ФИО;

ИНН;

адрес;

телефон;

номер удостоверения;

категория;

основной маршрут.

Рис.16. Экранная форма справочника «Водители»

В справочник «Транспорт» (рис.17) вводятся данные о каждом транспортном средстве Автобазы - от легковых автомобилей до тяжелой дорожно-строительной техники. Эти данные включают в себя:

марка, модель транспортного средства;

вид транспорта;

вид топлива;

норма на пробег;

инвентарный номер;

водитель.



Рис.17. Экранная форма справочника «Транспорт»

Справочник «Клиенты» (рис. 18) содержит следующую информацию:

название клиента;

адрес;

телефон;

объекты.

Рис.18. Экранная форма справочника «Клиенты»

Справочник «Маршрут» (рис.19) содержит следующую информацию:

название;

клиент;

объект;

водитель;

транспорт;

пробег;



Рис.19. Экранная форма справочника «Маршрут»

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

Рис.20. Экранная форма справочника «Объекты»

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

Рис.21. Экранная форма документа «Путевые листы»

Документ «Путевые листы» содержит следующую информацию:

дата;

марка, модель;

гос.рег.номер.;

пробег;

тариф;

водитель;

время работы;

маршрут;

клиент;

объект.

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

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

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

Отчеты предназначены только для отображения данных в нужном формате. Отчет может быть выведен как на экран, так и на печать. Кроме того, отчет можно сохранить в виде документа Word, Web-страницы, а также в виде «моментального снимка», рассылаемого по электронной почте, который можно просматривать на компьютере, даже если на нем не установлен Microsoft Access [23].

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

В соответствии с моделью представления данных, система будет создавать информационные отчеты. Для создания используются отчеты Access. (Приложение 2)

Результативными показателями эксплуатационной службы ОАО «Автобаза№2» являются отчеты по путевым листам:

путевой лист;

отчет пробега автотранспорта;

отчет по клиентам

поиск транспорта по водителю и др.

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

3. Обоснование экономической эффективности проекта

3.1 Выбор и методика расчета экономической эффективности

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

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

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

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

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

Информационный фактор эффективности выражается в повышении уровня информированности персонала и руководства.

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

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

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

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

Экономическая эффективность проекта складывается из двух составляющих:

косвенный эффект;

прямой эффект.

Косвенный эффект - проявляется в конечных результатах деятельности организации и характеризуется:

доступностью информации путем хранения в единой базе;

более быстрой и качественной обработки информации для отчетности;

лучшей наглядностью информации, относящейся к конкретному работнику;

Прямой эффект - экономия материально-трудовых ресурсов и денежных средств, полученная в результате:

сокращения численности управленческого персонала;

фонда заработной платы;

расхода основных и вспомогательных материалов.

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

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

Абсолютное снижение трудовых затрат (T):

Т = T0 - T1,

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

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

Коэффициент относительного снижения трудовых затрат (КТ):

КТ = T / T0 * 100%.

Индекс снижения трудовых затрат или повышение производительности труда (YТ):

YТ = T0 / T1.

К стоимостным показателям относятся следующие:

Абсолютное снижение стоимостных затрат (C):

С = С0 - С1,

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

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

Коэффициент относительного снижения стоимостных затрат (КС):

КС =С / С0 * 100%.

Индекс снижения стоимостных затрат (YС):

YС = С0 / С1.

Помимо рассмотренных показателей целесообразно также рассчитать срок окупаемости затрат на внедрение проекта машинной обработки информации (Ток):

Ток = КП /C,

где КП - затраты на создание проекта машинной обработки информации (проектирование и внедрение).

3.2 Расчет показателей экономической эффективности проекта

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

С помощью разработанной системы, это можно избежать.

В данном разделе рассмотрена методика и специфика расчета экономической эффективности проекта. Конкретные суммы затрат на работу в базовом варианте и на разработку автоматизированной системы приведены в таблице 7.

Объем работы - измеряется количеством записей, которые должен внести в базу работник отдела по работе с поставщиками и клиентами. Под записями понимается вся информация, которая вносится по каждому документу в данной операции.

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

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

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

Таблица 7 Характеристика затрат на обработку информации

№ п/п	Наименование операций технологического процесса	Объем работы в год	Трудоемкость обработки одного документа, час	Трудоемкость за год, час	Стоимостные затраты, руб.
1	2	3	4	5	6
1	Выписка путевого листа	2520	0,85	2142	62 118
2	Общий итог:	2520	Х	Т0 : 2142	С0 : 62 118
				Т1 : 882	C1 : 25 578

Объём работы в год рассчитан исходя из среднего количества выписанных диспетчером путевых листов в месяц и составляет (табл.7):

210*12=2520

Трудоемкость обработки одного путевого листа составляет 0,85 часа. Диспетчеры выписывают в год порядка 2520 путевых листов. До внедрения АРМ диспетчер тратил на составление всей документации 2142 часов в год (графа 5 = графа 3* графа 4).

После внедрения АРМ трудоемкость обработки одного путевого листа составила 0,35 часа. Теперь диспетчеру на составления путевого листа требуется 882 часа в год.

Среднечасовая заработная плата рассчитана исходя из следующих показателей:

средний размер заработной платы менеджера 6000 рублей в месяц;

продолжительность рабочего дня 10 часов;

среднее количество рабочих дней в месяце 21 день.

Диспетчер получает приблизительно 29 рублей в час. Таким образом, затраты на составление путевого листа до внедрения АРМ составляли порядка 62 118 рублей в год. После внедрения АРМ, затраты составили 25 578 рубля в год.

На основе этих данных рассчитываются:

абсолютное изменение трудовых затрат (Т),

коэффициент изменения трудовых затрат (КТ),

индекс изменения трудовых затрат (YT).

Данные по расчетам вышеуказанных показателей представлены в таблице 8.

Таблица 8 Показатели эффективности проекта

Показатели	Затраты, в год	Абсолютное изменение затрат	Коэффициент изменения затрат	Индекс изменения затрат
	Базовый вариант	Проектный вариант
Трудоемкость	Т0 (час)	Т1 (час)	Т (час)	КТ	YТ
	2142	882	1260	58,8%	2,43
Стоимость	С0 (руб)	С1 (руб)	С (руб)	КС	YС
	62 118	25 578	36 540	58,8%	2,43

Сравнив получившиеся показатели YT (индекс изменения трудовых затрат) и YC (индекс изменения стоимостных затрат), можно сделать следующий вывод:

Коэффициент изменения трудоёмкости составил 58,8 % - это значит, что трудоёмкость при проектном варианте уменьшилась на 58,8% относительно базового варианта. Соответственно, коэффициент изменения стоимости, уменьшился на 58,8%.

Индекс изменения трудоёмкости составил 2,43 - это значит, что трудоёмкость при базовом варианте была в 2,43 раза больше проектного варианта. Аналогично индекс изменения стоимости составил 2,43. Следовательно, стоимостные затраты при проектном варианте уменьшились 2,43 раза относительно базового варианта.

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

Проведем расчет срока окупаемости созданной системы. Затраты на создание проекта приведены в таблице 9.

Таблица 9 Затраты на создание проекта

№ п./п.	Наименование этапа разработки подсистемы	Количество часов	Стоимость одного часа работы (руб.)	Стоимость этапа (руб.)
1	Рассмотрение проекта автоматизации	46	70	3220
2	Предварительное проектирование информационной системы	32	70	2240
3	Проектирование информационной системы	81	70	5670
4	Внедрение проекта	15	70	1050
5	Общий итог:	174	Х	12 180

Срок окупаемости проекта (ТОК) можно найти по формуле:

ТОК = КП / C.

Капитальные затраты (КП) =12 180 руб.;

Абсолютное изменение затрат (C) составляет 36 540 рублей. Если данную сумму разбить на количество дней в году (365), то получится значение, отражающее выгодность использования системы за каждый день ее использования (100,2 руб.). Поделив общую сумму проекта на полученное значение, получим:

ТОК = 12 180 / 100,2 ? 121 день

Следовательно в течение 121 дня с момента начала эксплуатации АИС окупятся затраты на ее разработку.

Заключение

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

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

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

- быстрый поиск по справочникам;

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

- оперативная работа диспетчера с данными, хранящимися в базе;

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

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

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

Таким образом, применение данной АИС позволяет сократить затраты трудовых ресурсов на 58,8% или на 1260 часов в год и, следовательно, уменьшить расход денежных средств на 36 540 руб., тем самым повысить эффективность работы диспетчера, что является немаловажным критерием для автотранспортного предприятия с небольшим парком автомобилей.

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

Список литературы

Благодатских В.А. , Волнин В.А. , Поскакалов К.Ф. , «Стандартизация разработки программных средств» - М.: Финансы и статистика, 2005 г.

Бойко В.В., Савинков В.М. “Проектирование информационной базы автоматизированной системы на основе СУБД”. М.: Финансы и статистика, 1982.

Вейцман В.М. Автоматизированная разработка корпоративных информационных систем: Учебное пособие/- Ярославль: МУБиНТ, 2003.

Вейцман В.М. Проектирование экономических информационных систем: Учебное пособие. - Яр.: МУБиНТ, 2002. - 213 с.: ил.

Волков С.И., Романов А.И. Организация машинной обработки экономической информации, 1988.

Глушаков С.В., Ломотько Д.В. Базы данных, 2000.

Гофман В.Э., Хомоненко А.Д. «Работа с базами данных в Delphi», Санкт-Петербург, изд-во «БХВ-Петербург», 2000.

Джексон Г. Проектирование реляционных баз данных для использования с микро-ЭВМ М.: Финансы и статистика, 1991.

Зеленков Ю.А. Введение в базы данных. Центр Интернет ЯрГУ, 1997.

Керри Н. Праг, Майкл Р. Ирвин, Access 2000 - Библия пользователя, Диалектика, 2000.

Крис Дейт. Введение в базы данных, 6-е изд. Киев, Диалектика, 1998.

Маклаков С.В. BPwin и ERwin. CASE-средства разработки информационных систем. Москва: ДИАЛОГ-МИФИ, 1999.

Малыхина М.П. Базы данных: основы, проектирование, использование. Санкт-Петербург. БХВ-Петербург, 2004г.

Мартин Дж. Организация баз данных в вычислительных системах.

Методические указания по написанию дипломного проекта.

Рожнов В.С. АСОЭИ., М., Финансы и статистика., 2000.

Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем, 2002.

Справочник разработчика АСУ. под ред. Федоренко Н.П. и Карибского В.В., М., Экономика, 1978.

Статья в журнале «Грузовое и пассажирское автохозяйство» №10, 2005.

Статья в журнале «Грузовое и пассажирское автохозяйство» №6, 2006.

Статья в журнале «Грузовое и пассажирское автохозяйство» №8, 2006.

Тимошок Т.В. Microsoft Access 2002. Краткое руководство.: - М.: Издательский дом «Вильямс», 2004.

Титоренко Г.А. Автоматизированные информационные технологии в экономике, 2002.

Трубилин И.Т., Семенов М.И., Лойко В.И., Барановская Т.П. Автоматизированные информационные технологии в экономике, 2003.

Устав и Учредительные документы ОАО «Автобаза №2»

Федотова Д.Э., Семенов Ю.Д., Чижик К.Н. Case - технологии. Москва: Горячая линия - Телеком, 2003.

Харитонова И.А., Михеева В.Д. Microsoft Access 2000: разработка приложений. БХВ - Санкт-Петербург. Дюссельдорф - Киев - Москва - Санкт-Петербург 2000г.

Хендерсон К. Руководство разработчика баз данных, 2005.

Приложение 1. Схема физической модели базы данных

Приложение 2 Экранные формы

Продолжение приложения 2 Экранные формы

Продолжение приложения 2 Экранные формы

Продолжение приложения 2 Экранные формы

Размещено на Allbest.ru