ОСТАЛОСЬ ФОРМАТНУТЬ. Служба доставки (клиенты, график доставки, транспорт, маршрут)
Скачать 1.08 Mb.
|
Характеристика документооборота, возникающего при решении задачиОсновными документами в рассматриваемой задаче являются Заказ, Путевой лист и Получение заказа. Схема документооборота приведена в таб. 1.1 Таблица1.1 - Схема документооборота
Существующий способ учета связан с большой трудоемкостью, разрозненностью сведений, что с большой вероятностью ведет к их утере или неправильной интерпретации. На сегодняшний день невозможно получить сведения о загрузке транспортных средств, о своевременности доставки заказов, провести анализ основных причин проблем с доставкой и выявить ответственных. Кроме того, в отчетный период необходимо составление аналитических отчетов, включающих в себя анализ работы за определенный период, что очень затруднительно. Временные характеристики описанных процессов приведены в таблице 1.2. Таблица 1.2 - Характеристики описанных процессов
Таким образом, ежедневно, в среднем, 300 минут или 5 часов минут, сотрудник занят занесением необходимых сведений в книги учета, а также, при необходимости анализом и поиском нужных сведений. Учитывая, что продолжительность рабочего дня составляет 8 часов, делаем вывод, что на выполнение остальных обязанностей остается менее 35 % рабочего времени, что крайне неэффективно. Для данного способа также характерны следующие недостатки: • невысокая скорость и точность выполнения расчетов; • неэффективное использование рабочего времени; • слабый контроль работы сотрудника; • бюрократия – увеличивающийся «поток» бумажной работы. В результате проводимой автоматизации предполагается постоянно иметь точнейшие сведения о количестве поступившего и отпущенного товара, сократить время на подготовку аналитических отчетов и передачу документов за счет их электронной формы. Очевидно, что для автоматизации необходимо использовать такие средства, как персональные компьютеры, принтеры, а также специальное программное обеспечение и, возможно, локальную вычислительную сеть. Проведем расчет ожидаемого эффекта от внедрения средств автоматизации. В таблице 1.3 произведен расчет эффекта внедрения. Таблица 1.3 - Расчет эффекта внедрения
Таким образом, ожидаемая экономия рабочего времени составляет около 5 часов ежедневно, что позволяет увеличить эффективность работы сотрудников. Разработка и реализация проектных решений 2.1 Логическое моделирование предметной области Перед непосредственной разработкой базы данных построим информационно-техническую модель системы после осуществления входа в нее, в которой фиксируются последовательности и взаимосвязи решения всего комплекса задач по проекту.
Рисунок 2.1 – Информационно-технологическая модель Подробное описание представлено далее, в проектировании базы данных. В функционал экономиста входят вопросы учета поступающих заявок на перевозки, формирование аналитической отчётности в рамках процесса оказания услуг пассажирских перевозок, а также учета затрат на ГСМ. Функционал диспетчера предполагает учет параметров автопарка, пробега автотранспорта, а также данные о фактическом использовании ГСМ. Функционал Администратора включает ведение внутренних классификаторов, а также установку прав доступа к системе. Разработка базы данных На основании определенных сущностей информационной системы по учету перевозок построим диаграмму «Сущность - Связь» Каждый оператор вводит множество заявок. Связь 1:N. Каждой модели ТС соответствует множество автомобилей в автопарке. Связь 1:N. Каждому виду топлива соответствует множество моделей ТС. Связь 1:N. Каждому пункту назначения соответствует множество путевых листов. Связь 1:N. Каждому автомобилю соответствует множество путевых листов. Связь 1:N. Каждый водитель вводит множество путевых листов. Связь 1:N. Каждый сотрудник использует транспортные средства множество раз. Связь 1:N. Каждый сотрудник делает множество заявок на перевозки. В результате работы системы учета перевозок, формируются несколько таблиц, отражающих процесс работы транспортного отдела. Данные для построения этих таблиц берутся из справочников, а также журнала работы с заявками. Таблица 1.4 – Таблица «Операторы»
Таблица «oper» служит для хранения информации об операторах системы и разграничения доступа. Средний объем записей – 20. Таблица 1.5 – Таблица «Перевозки»
Таблица «plist» служит для хранения информации о путевых листах. Средний объем записей – 100000. Далее приведем описание кодирования ключевых сущностей проектируемой ИС и их свойств. Таблица 1.6 – Описание систем классификации и кодирования
Код вида услуги перевозки. Длина кода ХХ, где ХХ – порядковый номер вида услуги перевозки в картотеке транспортной компании. Код клиента. Длина кода ХХХ ХХХХХ, где ХХХ – порядковый номер категории, ХХХХХ – порядковый номер клиента. Код ТС. Длина кода ХХХ, где ХХХ – порядковый номер транспортного средства, зарегистрированного в системе. Код перевозки. Длина кода ХХ ХХХХХ, где ХХ – порядковый номер ТС, ХХХХХ – порядковый номер услуги перевозки. Код ГСМ. Длина кода Х, где Х – порядковый номер вида ГСМ. Физическое моделирование АИС Архитектура АИСВ качестве архитектуры решения будет применяться многослойная клиент-серверная архитектура, поскольку уже используемые на АТП решения на базе 1С: Предприятия организованы на базе такой архитектуры. Для клиент- серверной архитектуры, характерно отделение процессов представления, обработки и управления данными. Модель клиент-серверной архитектуры помогает создавать гибкое программное обеспечение. Изменения в данной модели осуществляются не во всем приложении сразу, а лишь в конкретных слоях, что позволяет сократить количество потенциальных ошибок и времени на модернизацию. Для клиент-серверных систем характерно наличие самостоятельно взаимодействующих процессов, выполнение которых, в общем случае, может производиться на разных вычислительных системах путем обмена данными по сети. Слой клиента – это компонент комплекса, реализующий интерфейс конечного пользователя. Данный слой не имеет возможности взаимодействовать с базой данных напрямую, на него обычно выносится простая бизнес–логика, такая как: интерфейс организации, контроль вводимых значений, сортировка, группировка и другие простые операции. В случае решения 1С может быть как полновесной программой клиентом, так и «тонким» и даже веб-клиентом.
Слой клиента Слой логики Слой данных Рисунок 2.6 – Модель многослойной архитектуры Слой логики – реализует большую часть бизнес-логики. Вне этого уровня реализуются элементы логики, экспортируемые на клиента, а также хранимые процедуры в БД. Данный компонент реализуется связующим программным обеспечением, на предприятии это платформа 1С: Предприятие. Слой данных – как правило представляет собой СУБД, обеспечивающую хранение данных. Взаимодействовать с третьим уровнем может только второй уровень. Слой данных на предприятии уже реализован на базе MS SQL Server 2008. В созданной конфигурации имеются следующие справочники (таб 1.7) Таблица 1.7 Сводная таблица справочников
В таб. 1.8 описаны характеристики справочника Договоры Таблица 1.8 Договоры
В таб. 1.9 описаны характеристики справочника Заказчики Таблица 1.9 Заказчики
В таб. 2 описаны характеристики справочника Автомобили Таблица 2 - Автомобили
В таб. 3 описаны характеристики справочника Водители Таблица 3 - Водители
На рисунках 2.1-2.4 отражены формы справочников данной конфигурации Рисунок 2.1 Справочник Договоры Рисунок 2.2 Справочник Автомобили Рисунок 2.3 Справочник Водители Рисунок 2.4 Справочник Заказчики Экранные формы размещения данных описаны в таблице 4 Таблица 4 - Описание входных документов
Экранные формы (макеты) документов и экранные формы для их ввода в систему изображены на рисунках 2.5-2.7 Рисунок 2.5 Документ Заказ Рисунок 2.6 Документ Путевой_Лист Экранные формы отчетов описаны в таблице 5 Таблица 5 - Описание выходных документов
|