Подсистемы управления сбыта продукции фирмы ОАО «Сосновскагропромтехника» с использованием Web-технологий

ДипломнаяПомощь в написанииУзнать стоимостьмоей работы

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

Подсистемы управления сбыта продукции фирмы ОАО «Сосновскагропромтехника» с использованием Web-технологий (реферат, курсовая, диплом, контрольная)

Введение

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

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

В связи с этим была предложена тема дипломного проекта «Подсистемы управления сбыта продукции фирмы ОАО „Сосновскагропромтехника“ с использованием Web-технологий»

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

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

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

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

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

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

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

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

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

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

Отдел цен после анализа документации выставляет для каждого изделия ценовую характеристику.

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

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

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

Прайс — лист можно также получить при личной встрече с менеджером, по факсу, через e-mail или скачать с сайта компании.

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

Заявка принимается и обрабатывается менеджером отдела сбыта.

Оформляется договор на продажу определенного вида продукции.

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

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

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

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

1.2.1 Наименование и область применения Наименование: «Подсистема управления сбытом ОАО „САПТ“ с использованием Webтехнологий».

Область применения — отдел сбыта ОАО «САПТ».

1.2.2 Основание для разработки Основанием разработки системы является приказ по НГТУ на дипломное проектирование № 1107/5 от 22.04.2013.

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

— ГОСТ 19.201−78. Техническое задание. Требования к содержанию и оформлению;

— ГОСТ 34.601−90. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания;

— ГОСТ 34.602−89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы

— ГОСТ 34.201−89. Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплексность и обозначение документов при создании автоматизированных систем;

— РД 50−34.698−90. Методические указания. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов.

1.2.4 Цель и назначение разработки Целью разработки является оптимизация процессов управления сбытом продукции на основе заказов потребителей.

Данная подсистема управления предназначена для решения следующих основных задач:

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

автоматизации формирования плана поставок изделий;

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

учет движения готовой продукции по складу;

контроля выполнения плана поставок;

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

формирования отчетов;

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

1.2.5 Функциональные требования В информационной подсистеме «Управление сбытом продукции ОАО „САПТ“» должна быть предусмотрена возможность реализации следующих функций:

возможность получения заказа в формате *.doc или *.xls;

оформлений спецификаций к договору;

формирование портфеля заказов;

формирование плана продаж;

регистрация прихода на склад готовой продукции из производства;

регистрация отгрузки готовой продукции по договору;

регистрация оплаты по договору;

планфактный анализ выполнения договоров;

контроль со стороны пользователя о состоянии заказа;

формирование отчетов.

1.2.6 Количественные требования Так как данная подсистема является web-приложением, то время поиска информации зависит от скорости соединения с Интернетом у пользователя. В целом время поиска информации не должно превышать 1 мин. Доступ к базе данных для редактирования информации должен быть организован как минимум с двух рабочих мест (администратор системы и менеджер из отдела продаж, занимающиеся приемом заказов и редактированием каталога продукции). Подсистема должна обеспечивать одновременный доступ до 100 пользователей, подсистема должна обеспечивать разграничение прав пользователей;

Количество потребителей составляет: 5 основных крупных предприятий, 10 средних и около 100 мелких заказчиков. Номенклатура готовой продукции более 300 позиций.

1.2.7 Требования к совместимости Необходимо обеспечить совместимость сервиса со всеми распространенными web-браузерами (Internet Explorer 6 и выше, Mozilla Firefox 2 и выше, Opera 6 и выше, Google Chrome, Safari).

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

Необходимо обеспечить:

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

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

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

1.2.9 Требования по безопасности и целостности информации Безопасность системы обеспечивается двумя путями:

непосредственно средствами хостинга, на котором размещена данная подсистема;

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

1.2.10 Требования к аппаратному и программному обеспечению Данная подсистема размещается на хостинге.

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

наличие доступа к сети Интернет;

нормальная работа пользователя с сайтом осуществляется при скорости интернет;

соединения не ниже 100 кбит/с;

наличие web-браузера. Версии web-браузеров, совместимых с данной системой перечислены в п. 1.2.7;

наличие поддержки технологии Flash версии 10 и выше в браузере.

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

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

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

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

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

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

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

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

1.3.1 Выбор программных средств Внедрение информационной системы позволит:

вести информацию по изделиям,

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

сократить сроки оформление и получения заказа клиента;

сократить затраты на бумагу и расходные материалы;

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

осуществлять постановку заказа на контроль в режиме реального времени;

оперативно получить статистическую информацию о заказываемой продукции.

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

Так как подсистема имеет клиент — серверную архитектуру, и использует в качестве web-сервера IIS (Internet Information Services, до версии 5.1 — Internet Information Server) необходимо выбрать оптимальное средство разработки. В качестве среды разработки программного продукта был выбран язык PHP. Выбор был сделан исходя из следующих особенностей данного продукта:

традиционность (многие конструкции языка позаимствованы из Си, Perl);

сравнительно простой синтаксис и удобство в практическом использовании;

бесплатность;

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

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

доступность дистрибутивов (дистрибутивы доступны на сайтах разработчиков);

эффективность («движок» PHP является транслирующим интерпретатором. Такое устройство позволяет обрабатывать сценарии с достаточно высокой скоростью.);

гибкость (поскольку РНР является встраиваемым языком, он отличается исключительной гибкостью по отношению к потребностям разработчика).

Apache + PHP + MySQL — набор дистрибутивов («Денвер») и программная оболочка, используемые Web-разработчиками для разработки сайтов без необходимости выхода в Интернет.

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

Для проведения анализа и реорганизации бизнес-процессов Computer Associates предлагает CASE-средство верхнего уровня BPwin, поддерживающее методологии IDEF0 (функциональная модель), IDEF3 (WorkFlow Diagram) и, DFD (DataFlow Diagram). Функциональная модель предназначена для описания существующих бизнес-процессов да предприятии (так называемая модель AS-IS) и идеального положения вещей — того, к чему нужно стремиться (модель TO-BE). Методологий IDEF0 предписывает построение иерархической системы диаграмм — единичных описаний фрагментов системы.

На основе модели BPwin можно построить модель данных. Для построения модели данных Computer Associates предлагает мощный и удобный инструмент — Erwin.

1.3.2 Требования к аппаратному и программному обеспечению Данная подсистема размещается на хостинге. К клиентским компьютерам предъявляются следующие требования:

наличие доступа к сети Интернет;

нормальная работа пользователя с сайтом осуществляется при скорости интернетсоединения не ниже 256 кбит/с.;

наличие web-браузера. Версии web-браузеров, совместимых с данной системой перечислены в п. 1.3.2;

наличие поддержки технологии Flash версии 10 и выше в браузере.

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

Минимальные требования к серверу:

Cервер Unix;

Intel Core 2 Quad, RAM 4 Гб, Lan Card 1 Гбит.

Также необходимо предусмотреть устройства резервного копирования и бесперебойного питания.

Минимальные требования к клиенту:

Windows 98;

Pentium, Celeron 600, RAM 128 МБ, Lan 10 Мбит;

Интернет браузер.

Рекомендуемые требования к клиенту:

Windows XP/;

Pentium IV, RAM 512 МБ, Lan 10 Мбит;

Интернет браузер Internet Explorer 6.0 и выше.

1.3.3 Ошибки персонала при работе с системой Подсистема должна локализовать ошибки персонала при работе с Системой.

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

ввод некорректных данных;

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

отправка на печать отчета, при отсутствии или неисправности принтера.

1.3.4 Актуальность разработки Данный дипломный проект посвящен разработке информационной подсистемы управления сбытом продукции фирмы ОАО «САПТ».

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

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

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

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

Основной целью данной разработки является автоматизация процесса заказа продукции клиентами и сбыта продукции предприятием.

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

1.4 Технико-экономическое обоснование

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

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

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

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

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

1) доступность информации по формуле 365/24/7 — круглогодично, круглосуточно, в любой день недели. Интернет работает без обеда и выходных;

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

3) четкое прослеживание сделанных заказов, а также их состояние;

4) возможность легко собрать информацию о наиболее активных пользователях — покупателях, о наиболее популярных изделиях;

5) престиж предприятия, поскольку имея такой сервис, организация будет выглядеть весьма солидно.

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

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

исключение ошибок при оформлении документов;

ускорение процедуры поиска информации;

ускорение процедуры выборки информации;

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

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

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

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

Таблица 1.1 — Анализ возможных альтернативных вариантов решения проблемы


Вариант решения	Технические характеристики
Покупка готовой программы, позволяющей управлять сбытом продукции в ОАО «САПТ».	1) Купленная информационная подсистема позволит управлять заказами и продажами готовой продукции. 2) Достаточно высокая скорость обработки данных. 3) Программа будет иметь лишнюю функциональность, не нужную для решения поставленной задачи. 4) Высокая цена программного продукта и необходимость обращения к разработчику при изменении отчетности и бизнес-процесса. Сопровождение программного продукта также необходимо оплачивать.
Самостоятельная разработка сотрудниками ОАО «САПТ» информационной системы по управлению сбытом продукции.	1) Разработанная информационная подсистема позволит управлять заказами и продажами готовой продукции. 2) Достаточно высокая скорость обработки данных. 3) Программа ориентирована на особенности предприятия и тонкости эффективного управления в нём. 4) Адаптивность и развиваемость — характеризуется адекватностью системы к настройке существующей в ней функциональности в соответствии с требованиями организации, а также включение в неё новой функциональности, т. е. возможность введения новых функций.

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

2. Разработка системного проекта

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

Рисунок 2.1 — Структура подключения клиентских рабочих мест Клиент-серверная информационная подсистема состоит из трех основных компонентов:

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

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

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

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

Основным пользователем подсистемы является:

— менеджер отдела сбыта,

— кладовщик склада готовой продукции отдела сбыта,

— начальник отдела сбыта.

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

Таблица 2.1 — Перечень исполнителей и их задач


Исполнитель	Задача
Менеджер отдела сбыта	Принимает и регистрирует Заявки. Оформляет договора и формирует спецификацию к каждому договору. Продлевает срок действия договора. Оформляет счет на поставку готовой продукции. Формирует «Портфель заказов». Формирует: — План поставки готовой продукции на год; — План поставки готовой продукции на месяц; — График отгрузки готовой продукции; — Сменное задание на отгрузку; — Заявку на транспорт. Контролирует: — исполнение договоров; — оплату счетов; — выполнение плана поставки, графика отгрузки, сменного задания. Анализирует работу с клиентами.
Кладовщик склада готовой продукции отдела сбыта	— Инвентаризация готовой продукции на складе — Учет сдачи готовой продукции цехами основного производством на склад готовой продукции — Подбор ассортимента продукции согласно заявки и графика отгрузки — Учет отгрузки готовой продукции — Учет движения на складе готовой продукции. Расчет остатков. Формирование оборотной ведомости.
Начальник отдела сбыта	— Согласует договора — Утверждает а) План поставки готовой продукции б) График отгрузки готовой продукции
Начальник отдела сбыта	в) Сменное задание — Формирует отчеты — Контролирует исполнение договоров, планов, графиков, сменных заданий — Контролирует работу менеджеров — Анализирует работу с клиентами
Управляющий директор	— Утверждает договора — Контролирует исполнение договоров.
Бухгалтер	Проводит совместно с кладовщиком инвентаризацию на складе готовой продукции
Начальник ПДО	Согласует Договор клиента Контролирует выполнение графика сдачи готовой продукции на склад готовой продукции.
Директор по производству	Контролирует: — исполнение договоров; — выполнение графика сдачи готовой продукции на склад готовой продукции.
Системный администратор	Управляет безопасностью системы

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

Таблица 2.2 — Перечень исполнителей и их задач на основе анализа внешних событий


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

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

Таблица 2.3 — Перечень элементарных бизнес-процессов и соответствующих им прецедентов


Элементарный бизнеспроцесс	Прецедент
Заключение договора	Сбор первичной информации. Ведение карточки договора. Пролонгация договора.
Обработка договора	Создание спецификации, счета
Контроль за исполнением договора	Контроль за исполнением договора
Управление безопасностью системы	Управление безопасностью системы

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

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

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

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

Менеджер отправляет спецификацию на утверждение руководителю фирмы.

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

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

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

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

По истечении определенно срока (5 лет) подсистема удаляет карточки договоров с пустой историей, перед этим выведя сообщение об истечении срока хранения неактивного договора в архиве.

Директор по производству контролирует правильность результативной информации, следит за загруженностью каждого менеджера, имеет доступ ко всем базам контрагентов и ко всем базам договоров.

Прецедент Управление безопасностью: Доступ к договорам и контрагентам может быть разграничен не только по подразделениям компании, но и по менеджерам. Администратор может наложить любые ограничения для каждого сотрудника — договоры будут отображены или скрыты в зависимости от потребностей и логики бизнес-процессов предприятия.

В соответствии с выделенными прецедентами можно составить диаграмму прецедентов (рисунок 2), которая наглядно иллюстрирует все прецеденты, их исполнителей и взаимосвязи между ними.

Прецедентом, на примере которого будет выполнено объектно-ориентированный программирование, является Заказ.

Развернутое описание прецедента Создание спецификации Основной исполнитель. Менеджер отдела сбыта.

Заинтересованные лица и их требования

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

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

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

— Фирма — Удовлетворить свои сбытовые потребности с получением максимальной прибыли. Удовлетворить все требования покупателя, поставив ему качественную продукцию. Фирма заинтересована в дальнейшем сотрудничестве с клиентом и увеличении объема поставок.

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

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

Рисунок 2.2 — Диаграмма прецедентов

Результаты (Постусловия). Складские данные обновлены. Обновлена База данных в части таблиц Заказов и Заказпродукт. Спецификация сгенерирована и сохранена, распечатана, согласована, является приложением утвержденного Договора. Автоматизация обработки информации по договору выполнена.

Основной успешный сценарий:

«Клиент» выбирает интересующие его товары и добавляет их в корзину, для дальнейшего оформления заказа

«Клиент» вводит логин и пароль или регистрируется для входа в систему

«Клиент» выбирает способ оплаты и доставки

«Клиент» вводит адрес доставки заказа

«Клиент» подтверждает правильность оформления заявки на заказ

Заявка создана

Покупатель получает уведомление о создании заявки на заказ

Альтернативные сценарии:

1(а) пароль не верен — система предлагает повторить попытку ввода

2(а) товары не выбраны — система предлагает выбрать товары

5(а) закрытие системы — сброс введенных данных.

Спецификацию заверяют подписями и печатью.

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

1) Менеджер перезапускает систему, идентифицируется и предлагает восстановить предыдущее состояние.

2) Подсистема восстанавливает предыдущее состояние.

а)Подсистема уведомляет и регистрирует ошибку и переходит в начальное состояние.

б) Менеджер открывает новую спецификацию.

3) Редактирование старой спецификации.

а) Менеджер выбирает номер спецификации (она уже имеется в базе).

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

4) Выбранный договор в состоянии активен.

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

б) Менеджер соглашается с продолжением создания документа.

5) а) Требуемого количества товара нет на складе.

б). Подсистема уведомляет о том, что данного товара нет в требуемом количестве.

в). Менеджер соглашается, изменяет (добавляет) в спецификации количество товара.

5.1 а) Менеджера не устраивает цена товара (от стоимости сделки зависит процент, выплачиваемый менеджеру).

б) Менеджер может вручную изменить цену товара.

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

6) Менеджера не устраивает общая сумма к оплате.

а) Менеджер может вручную изменить цену товара.

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

7. Подсистема уведомляет о незаполненных полях в спецификации.

а). Менеджер устраняет ошибку.

б). Подсистема сохраняет и выводит на печать документ.

Специальные требования

— Сенсорный экран с интерфейсом пользователя для большого плоского монитора.

— Отклик службы авторизации в 90% случаев приходит в течение 30 секунд.

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

Частота использования: почти постоянно.

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

Простой сценарий прецедента Создание спецификации

1) Идентификация менеджера.

2) Менеджер открывает новую спецификацию.

3) Подсистема присваивает номер и дату спецификации.

4) Менеджер выбирает номер договора.

Подсистема выдает номер и дату договора, реквизиты контрагента.

5) Менеджер выбирает товар.

6) Подсистема записывает наименование товара, цену, стоимость, налоговую ставку, сумму налога, общую стоимость.

Менеджер повторяет действия, описанные в п.п. 5−6, для каждого товара.

7) Подсистема выводит общую сумму к оплате. Менеджер вводит срок доставки товара, форму и срок оплаты.

8) Подсистема регистрирует, сохраняет и выводит на печать спецификацию. Спецификацию заверяют подписями и печатью.

Пример, приведенный выше, соответствует основному успешному сценарию прецедента Заказ.

2.3 Оперативно-календарного планирования на производстве Главная задача оперативно-календарного планирования в современных условиях заключается в обеспечении своевременного выполнения разнообразных заказов в соответствии производственными программами при равномерной загрузке всех звеньев производства и наименее коротких производственных циклах выполнения заказа.

Характерной чертой оперативно-календарного планирования является тесная связь календарно-плановых расчётов производства с планированием технической подготовки выполнения каждого заказа.

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

Оформление заказа — необходимо пользоваться укрупнёнными нормативами, определяемыми опытно-статистическими методами. Последовательность оформления заказа на машиностроительном производстве показана на рис 16., основными элементами которого являются портфель заказов, запросный лист (документ, в который заносятся все пожелания, требования, расчёты исполнителей в последовательности, указанной на схеме), карта заказа, договор (контракт) выполнения заказа. Запросный лист каждый исполнитель передаёт в бюро заказов и следующему по циклу исполнителю. Используются следующие сокращения: ОГК — отдел главного конструктора, ОГТ — отдел главного технолога, ОМТО — отдел материально-технического снабжения, ПО — производственный отдел, ПЭО — планово-экономический отдел.

Подготовка выполнения заказа.

Календарно-плановые расчёты в единичном производстве включают:

— расчёт длительности производственного цикла изготовления изделий (выполнения заказов) и построения цикловых графиков по отдельным заказам;

— определение календарных опережений в работе цехов;

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

— проверочные расчёты загрузки производственных площадей и оборудования (объёмно-календарные расчёты и корректировка сводного графика с целью выравнивания загрузки по отдельным плановым периодам.

Таблица 2.4 — Последовательность оформления заказа


Наименование работ	Исполнители
	Бюро заказов	ОГК	ОГТ	ОМПО	ПО	ПЗО
	А)Регистрация заказов в журнале портфеля заказов (ПЗ), оформление запросного листа (ЗЛ). Б)Расчёт показателей (объём, сроки, затраты) конструкторской подготовки производства В) Расчёт показателей технологической подготовки производства Г) Нормирование расходов материальных ресурсов Д) Нормирование труда по стадиям производства Е) Разработка плана поставок ресурсов Ж) Определение сроков выполнения заказа по стадиям производства З) Калькулирование затрат и расчёт цены И) Расчёт прибыли Л) Заполнение карты заказа и проект договора М) Согласование и утверждение договора, его регистрация в журнале

Расчёт длительности производственного цикла выполнения заказа является основным календарноплановым расчётом в единичном производстве. Эта длительность определяется по формуле: [4]

Тц = n? (tк / csq) + m (tмп / sq) + tс Тц — длительность производственного цикла;

n — число деталей в партии;

m — число операций технологического процесса;

tк — полная норма времени на операцию;

c — число рабочих мест, параллельно занятых выполнением операции;

s — число рабочих смен в сутках;

qдлительность рабочей смены;

tмп — межоперационное время;

tспродолжительность естественных процессов;

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

nс — число изделий в серии Тсбдлительность производственного цикла сборки одного изделия При параллельной сборке общий период сборки совпадает с длительностью производственного цикла сборки одного изделия.

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

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

Сроки выпуска изделий устанавливают укрупнено по декадам или неделям на основании реализации.

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

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

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

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

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

Модель процессов помогает понять особенности функционирования системы. Для нашей ИС будем строить модель в программе BPWin. Основным процессом является процесс загрузки конфигуратора в систему и его обработка. На вход поступает конструкторская документация.

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

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

На диаграммах IDEF0 изображаются работы (Activity). Работы обозначают поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Работы изображаются в виде прямоугольников. Вход (Input) — материал или информация, которые используются или преобразуется работой для получения результата (выхода). Управление (Control) — правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Выход (Output) — материал или информация, которые производятся работой. Механизм (Mechanism) — ресурсы, которые выполняют работу.

Рисунок 2.3 — Модель процессов уровень А0

Рисунок 2.4 — Модель процессов уровень А1

Модель процессов имеет иерархическую структуру. Дерево модели показано на рисунке 2.5.

Рисунок 2.5 — Дерево модели

2.5 Модель потоков данных В соответствии с DFD (Data Flow Diagram) методологией, модель системы определяется как иерархия диаграмм потоков данных, описывающих процессы преобразования информации от момента ее ввода в систему до выдачи конечному пользователю. Диаграммы верхних уровней иерархии — контекстные диаграммы, задают границы модели, определяя её окружение (внешние входы и выходы) и основные рассматриваемые процессы. Контекстные диаграммы детализируются при помощи диаграмм следующих уровней.

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

Рисунок 2.6 — Диаграмма уровня систем Диаграмма уровня систем, как правило, является сложной для восприятия и анализа, поэтому ее следует декомпозировать до уровня подсистем. Для данной системы диаграмма уровня подсистем логически состоит из семи блоков (рисунок 2.7)

Рисунок 2.7 — Диаграмма потоков данных 2 уровень Диаграмма уровня систем, как правило, является сложной для восприятия и анализа, поэтому ее следует декомпозировать до уровня подсистем.

2.5 Разработка модели данных

IDEF1X — методология построения реляционных структур баз данных, относится к типу методологий «Сущность-связь». Модель IDEF1X в нотации представляет собой набор сущностей связанных между собой. Сущности отображаются в виде прямоугольников, а связи в виде линий. Внутри прямоугольника перечисляются ключевые поля и атрибуты сущности, разделённые чертой.

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

На основе концептуальной модели данных сформируем реальные таблицы для автоматизированной системы (Таблицы 2.5 — 2.20).

Определение атрибутов каждой сущности:

Таблица 2.5 — Структура таблицы «Заказ»


Имя поля	Тип данных	Описание
Номер заказа	Счетчик (ключ)
Код клиента	Числовой
Дата заказа	Дата/время
Тип заказа	Текстовый
Период заказа	Текстовый
Статус	Числовой
Номер документа	Текстовый
Код сотрудника	Текстовый
Дата доставки	Дата/время
Место доставки

Показать весь текст

Заполнить форму текущей работой

Подсистемы управления сбыта продукции фирмы ОАО «Сосновскагропромтехника» с использованием Web-технологий (реферат, курсовая, диплом, контрольная)

Введение

Заключение