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

Проектирование реализации операций бизнес-процесса Складской учет (Выбор комплекса задач автоматизации.)

Содержание:

ВВЕДЕНИЕ

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

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

Поставленная цель достигается путем решения следующих задач:

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

Глава 1. Аналитическая часть.

1.1 Выбор комплекса задач автоматизации.

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

- определиться c организационной структурой;

- произвести выделение основных технологических процессов;

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

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

1.2 Характеристика существующих бизнес – процессов.

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

1.3 Характеристика документооборота, возникающего при решении задачи.

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

-Введение полного электронного документооборот;

- Обучении более широкого круга персонала;

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

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

1.4 Обоснование проектных решений по информационному обеспечению.

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

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

-Совместная разработке системы с пользователями, в том числе и в рахработке программного обеспечения;

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

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

1.5 Обоснование проектных решений по программному обеспечению.

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

Имеется большое число разных методологий. Средь их отделяют тяжелые и упругые методологии. С целью тяжелых методологий следует подробное составление плана значительного размера исследований, огромный размер документации, и такого рода отношение функционирует - но вплоть до тех пор, пока не возникнут изменении. Таким образом, с целью данных методологий бороться любым переменам абсолютно безусловно. Эластичные ведь методологии, наоборот, перемены приветствуют. В различие с тяжелых, они существовали запланированы равно как движения, какие приспособят перемены и только лишь выигрывают с их, в том числе и в этом случае, если перемены совершаются в их самих. Более популярными и распространенными эластичными методологиями в наше время период считается RUP (Rational Unified Process) и XP (eXtreme Programming).

Итак что же это такое. RUP - это система процессных компонент, методов и техник, которые вы можете применить в любом конкретном программном проекте. Предполагается, что пользователь будет адаптировать RUP. С другой стороны XP - более ограниченный процесс, требующий дополнений для того, чтобы соответствовать полному циклу разработки проекта. Эта разница объясняет предпочтения в сообществе разработчиков программного обеспечения. Разработчики крупных систем рассматривают RUP в качестве решения своих проблем, в то время как сообщество разработчиков малых систем решение своих проблем видит в XP. XP это упрощенный, ориентированный на кодирование процесс, для небольших проектов. Эта технология основана на итерациях, объединяющих некоторые приемы, такие как небольшие релизы, простое проектирование, тестирование и постоянная интеграция. RUP – это итеративная методология, основанная на шести признанных в отрасли лучших технологиях. Основной целью RUP является сокращение рисков. Методология RUP уточнялась в ходе тысяч проектов, выполненных тысячами клиентов и партнеров компании Rational.

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

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

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

- Определение требований (Requirements);

- Проектирование и тнализ (Design & Analysis);

- Разработка (Development);

- Тестирование (Testing);

- Развертывание и сопровождение (Deployment & Operations).

Каждый из этих этапов должен тщательно отслеживаться и контролироваться. Правильно организованная ALM-система позволяет:

- Сократить сроки вывода продуктов на рынок (разработчикам приходится заботиться лишь о соответствии их программ сформулированным требованиям);

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

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

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

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

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

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

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

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

ASP (англ. Active Server Pages — «активные серверные страницы») — технология, предложенная компанией Microsoft в 1996 году для создания Web-приложений, эта технология основана на внедрении в обыкновенные веб-страницы специальных элементов управления, допускающих программное управления. технология ASP получила своё развитие в виде ASP.NET — новой технологии создания веб-приложений, основанной на платформе Microsoft .NET.

ASP.NET — технология создания веб-приложений и веб-сервисов от компании Майкрософт. Она является составной частью платформы Microsoft .NET и развитием более старой технологии Microsoft ASP. На данный момент последней версией этой технологии является ASP.NET 4.0b.

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

Хотя ASP.NET берёт своё название от старой технологии Microsoft ASP, она значительно от неё отличается. Microsoft полностью перестроила ASP.NET, основываясь на Common Language Runtime (CLR), который является основой всех приложений Microsoft .NET. ASP.NET имеет преимущество в скорости по сравнению со скриптовыми технологиями, так как при первом обращении код компилируется и помещается в специальный кэш, и впоследствии только исполняется.

Глава 2. Проектная часть.

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

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

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

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

- выявляются основные риски;

Фаза завершается формулировкой целей проекта.

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

Продавец – лицо, работающее на контрольно-кассовом аппарате.

Администратор – лицо, ведущее количественный учет товаров.

Менеджер – управляющий компанией.

Затем были выделены функции каждого пользователя Рисунок 2.

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

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

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

Состав реквизитов справочника приведен в Рисунке 5.

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

Описание результатных документов Рисунок 6.

2.4. Общие положения (дерево функций и сценарий диалога).

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

На этом основание разработан сценарий диалога, реализованные как Рисунок 8.

2.5. Характеристика базы данных.

Иcпользуя MS SQL Server 2008 мы делаем следующею ER-модель, описывающая взаимосвязь таблиц в БД Рисунок 9.

2.6. Структурная схема пакета (дерево вызова программных модулей).

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

2.7 Описание программных модулей.

Блок-схема добавления данных о проекте Рисунок 11.

2.8. Контрольный пример реализации проекта и его описание.

Итак, вот мы подошли к финалу который я начну подробным описанием который начнётся с модуля авторизации в системе Рисунок 12.

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

Для ввода состояния нового объекта необходимо нажать кнопку с изображением плюса зеленого цвета, ввести наименование и нажать кнопку с изображением дискеты Рисунок 14.

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

Для получения полного списка всего, что есть на складе необходимо перейти во вкладку «Товары» и выбрать даты, в периоде, который которые нас интересует. Рисунок 15.

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

Глава 3. Эффективности проекта

3.1 Экономической эффективности проекта.

На данном этапе мы подведём первичные итоги расходов (рабочие и трудовые) в работе в базовом виде и после нашего внедрения автоматизации.

Расчет, расходов затрат труда согласно базовому и проектируемому виду.

А) До введения.

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

Норма формирования демонстрирует, какое количество за определённое количество времени (возьмём час) эксперт способен подвергнуть обработке бумаг присутствие базисном виде постановления проблемы. В нашем случае мера формирования документов в один час было 1,5документа.

Трудоёмкость до (Тд) обусловливается разделением объёма деятельность в норму выработки.

Тд =1800 /1,5 = 1200 час.

Б.)После введения.

Нормой обработки после проектного варианта стала составлять 12,0 документов в час.

Трудоёмкость после (Тп) определяется делением объёма работы на норму выработки:

Тп = 1800 /12,0 = 150 час.

Абсолютный показатель снижения трудовых затрат(∆T ) по формуле:

∆T=Tп-Tд,

∆T= 1200-150=1050 час.

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

Кт=∆T/Tд

Кт=1050/1200 x 100%=87,5%

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

Yт =1200/150=8

Расчет показателей стоимости до и после:

До-1.Материальные затраты

Затраты материалов на производство обработки документов включает затраты на канцелярские товары таки как: ручки, карандаши, линейки, бумага А4, дырокол, печати и чернила для них. Подсчитав все это выясним что ежемесячно на их закупку тратиться 550 рублей, плюс картриджи чья стоимость 500 рублей за штуку. Итого 1050 рублей в месяц, в год же

1050x12=12600 рублей.

2.Затраты труда.

Число сотрудников - 1 лица. Фонд оплаты труда составляет 250руб./час. x 100 час. = 25000 рублей в месяц.

Заработной платы за год составляет:

25000 х 12 = 300000 руб.

Общие затраты до составляли:

Сб =12600+300000=312600 рублей.

После-1. Материальные затраты

Материальные затраты уменьшились до закупки картриджи(500рублей за штуку.) и бумага(200 рублей за пачку).

Итого=700рублей.

Это в месяц, соответственно в год будет уходить

700 х 12 = 8400 рублей.

2.Затраты труда

Число сотрудников -1. Фонд оплаты труда составляет 250руб./час. x 12,5 = 3125 рублей в месяц.

Заработной платы за год составляет:

3125 x12= 37500 рублей.

3.Расходы на электроэнергию (Накладные)

2500Кв/ч*1,50руб.=37500,00 рублей.

Срок действия гарантии 7лет, и в таком случае отчисления в фонд будут составлять 14,28% (100% / 7) от капитальных вложений (инвестиции).

Суммарный вложение в проектный план подобным способом, составит 207750,00 рублей, плюс сумма демпферных начислений 14,28% с важных инвестиций:

207750,00 х 0, 14 = 29085,00 рублей.

Всего расходы в автоматизирование обрабатываемых данных будет равна

Сп = 7260+37500+37500+30000+29085= 141345 рублей.

Рассчитаем значимость стоимостных характеристик:

Абсолютное понижение стоимости расходов (∆С):

∆С=Сб-Сп,

∆С =310200- 141345= 168855 рублей.

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

Кс=∆С/Сб*100%

Кс=168855/310200*100%=54,4%

Показатель перемены стоимостных расходов (Yc):

Yc=Сб/Сп.

Yc=310200/141345=2,19

Установим финансовую результативность от концепции. Это самое отношение финансового результата, приобретенного после установленный промежуток периода с инвестиции денежных средств, к объёму приложенного денежных средств, гарантировавшего введение событий и приобретение финансового результата.

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

Экономическая эффективность имеет формулу:

Е=∆С/Кз=1/Т

где: ∆С - чистый доход (прибыль), полученный в течение года от эксплуатации внедрённого проекта;

Кз – это те вложений, за счёт которого обеспечен доход.

Е =168855/207750=0,81

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

Этот срок определяется, обратной величиной E

Т = 1 / Е

Т = 1 /0,81 = 1,2

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

СПИСОК ЛИТЕРАТУРЫ

1. Ведение нормативно-справочной информации в крупных организациях. Линцер Л.А., Москва, ООО "Газоил пресс", 2006, 19-21 стр.

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

3. Теория и практика построения баз данных: Д. Крёнке. – Питер, 2003.

4. Автоматизация управления производством/Баронов В.В. и др. - М.: ИНФРА-М, 2000

5. Макарова Н.В Информатика: Учебник, М.: Финансы и статистика, 2003, 691-768 стр.

6. Якобсон А., Г. Буч, Дж. Рамбо, Унифицированный процесс разработки программного обеспечения, СПб. Питер , 2002. - 496 стр.

7. Студенческая библиотека онлайн http://studbooks.net .

8. Свободная энциклопедия-википедия https://ru.wikipedia.org/wiki

9. Сайт мир технологий http://www.m-te.ru/index.php?vib=21&id_stat=2129

ПРИЛОЖЕНИЕ

Рисунок 1. Схема документооборота предприятия

Рисунок 2.

Пользователь	Функция	Описание
Продавец	Авторизация	Вход в Систему по своему логину и паролю
	Запрос помощи	Обращение к сетевому администратору в случае технических неполадок
	Расход	Создание и изменение расходной накладной
Администратор	Авторизация	Вход в Систему по своему логину и паролю
	Запрос помощи	Обращение к сетевому администратору в случае технических неполадок
	Приход	Создание и изменение приходной накладной
	Редактирование накладных	Управление уже сохранёнными расходными и приходными накладынми
	Редактирование списка "Поставщики"
	Редактирование списка "Каталог"
	Редактирование списка "Магазины"
Менеджер	Авторизация	Вход в Систему по своему логину и паролю
Запрос помощи	Обращение к сетевому администратору в случае технических неполадок
Создание отчета об остатках	Просмотр количественной информации по остаткам на складах
Создание отчета об оборотах	Просмотр финансовой информации по оборотам компании

Рисунок 3.

Рисунок 4.

№ пп	название справочника	ответственный за ведение	средний объём справочника в записях	среднюю частоту актуализации	средний объем актуализации, %
1	Сотрудники	Администратор	100	1 раз в месяц	10
2	Фирма	Администратор	50	1 раз в месяц	10
3	Клиенты	Пользователь	50	1 раз в месяц	10
4	Состояние проектов	Пользователь	50	1 раз в месяц	10

Рисунок 5.

№ пп	Наименование	Перечень реквизитов
1.	Сотрудники	·Фамилия, имя, отчество · Дата рождения · Должность
2.	Фирма	· Наименование · Город · Орг-форма · Контактное лицо
3.	Клиенты	· Фирма ·Фамилия, имя, отчество · Дата регистрации · Адрес · E-mail · ФИО руководителя
4.	Состояние объекта	·Наименование состояния