Автоматизоване робоче місце Логістика ЗАТ Пріосколье

Зміст

Введення

Глава I. Постановка завдання та опис предметної області

1.1 Постановка завдання

1.2 Опис предметної області (бізнес-процеси)

1.3 Обгрунтування для розробки нового ПЗ

1.4 Технічне завдання

Глава II. Розробка ПЗ та побудова БД

2.1. Функціональні вимоги до системи

2.2. Схема роботи складу підприємства

2.3. Вибір та обгрунтування технології проектування та інструментальних засобів розробки

2.4. Постановка завдань по підсистемах

2.5. Обгрунтування вибору СУБД Access для розробки БД

2.6. Розробка структури бази даних і відносин атрибутів

2.6.1. Нормалізація бази даних

2.6.2. База даних автоматизованої системи управління складом

Глава III. Система АРМ «Логістика»

Глава IV. Розрахунок економічної ефективності

4.1 Аналіз ринкових можливостей продукту

4.2 Розрахунок одноразових витрат на розробку ПЗ

4.3 Одноразові витрати організації замовника ПЗ при впровадженні автоматизованих робочих місць (АРМ)

4.5 Поточні витрати користувача ПЗ при експлуатації АРМ

4.6 Економія поточних витрат користувача ПЗ

4.7 Фінансовий план проекту

4.8 Показники економічної ефективності проекту

Глава V. Обгрунтування вибору Delphi

Введення

У даній дипломній роботі планується розглянути розділ логістики складування, як один з найбільш важливих і значимих у діяльності підприємства - виробника.

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

Логістика підрозділяється на кілька основних напрямків:

- Інформаційна логістика;

- Закупівельна логістика;

- Логістика виробничих процесів;

- Збутова логістика;

- Логістика запасів;

- Логістика складування;

- Транспортна логістика;

- Організація логістичного управління.

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

Сучасний великий склад - це складне технічне спорудження, яке складається з численних взаємозалежних елементів, має певну структуру і виконує ряд функцій з перетворення матеріальних потоків, а також накопиченню, переробки та розподілу товарів між споживачами. При цьому можливе різноманіття параметрів, технологічних і об'ємно-планувальних рішень, конструкцій обладнання та характеристик різноманітної номенклатури товарів, що переробляються на складах, відносить склади до складних систем. У той же час склад сам є лише елементом системи більш високого рівня - логістичного ланцюга, яка і формує основні та технічні вимоги до складської системі, встановлює цілі та критерії її оптимального функціонування, диктує умови переробки товару.

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

При цьому необхідно мати на увазі, що в кожному окремо взятому випадку, для конкретного складу, параметри складської системи значно відрізняються один від одного, так само як її елементи і сама структура, заснована на взаємозв'язку цих елементів. При створенні складської системи завжди потрібно керуватися наступним основним принципом: лише індивідуальне рішення з урахуванням всіх факторів, що впливають може зробити її рентабельною. Передумовою цього є чітке визначення функціональних завдань і грунтовний аналіз переробки вантажу і в середині, так і поза складу. Розкид гнучких можливостей необхідно обмежити розсудливими практично вигідними показниками. Це означає, що будь-які витрати повинні бути економічно виправданими, тобто впровадження будь-якого технологічного і технічного рішення, пов'язане з інвестиціями, має виходити з раціональної доцільності, а не з модних тенденцій і запропонованих технічних можливостей на ринку.

Основне призначення складу - концентрація запасів, їх збереження і забезпечення безперебійного і ритмічного постачання замовлень споживачів.

Глава I. Постановка завдання та опис предметної області

1.1 Постановка завдання

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

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

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

Загальна концепція рішення складської системи повинна бути економічною. Економічний успіх забезпечується у випадку, якщо планування і реалізація складської системи розглядаються з точки зору інтересів всього підприємства, будучи лише частиною загальної концепції складу. А рентабельність складу і буде, в кінцевому рахунку, основним критерієм вибраної загальної концепції.

Система складування припускає оптимальне розміщення товару на складі і раціональне управління ім. При розробці системи складування необхідно враховувати всі взаємозв'язки і взаємозалежності між зовнішніми (вхідними на склад і виходять із нього) і внутрішніми (складськими) потоками об'єкту і пов'язані з ними фактори (параметри складу, технічні засоби, особливості вантажу і т.д.). Розробка системи складування грунтується на виборі раціональної системи із всіх технічно можливих систем для вирішення поставленої задачі методом кількісної і якісної оцінки. Цей процес вибору і оптимізації передбачає виявлення зв'язаних між собою факторів, систематизованих у кілька основних підсистем.

Кожна підсистема в себе цілий ряд можливих елементів. При цьому число елементів, що становлять основні підсистеми, може бути досить значним, а поєднання їх у різні комбінації ще більше збільшує багатоваріантність системи. Це означає, що альтернативний вибір всіх конкурентних варіантів повинен здійснюватися в певній послідовності з урахуванням техніко-економічної оцінки кожного з них.

Вибір раціональної системи складування має здійснюватися в наступному порядку:

визначаються місце складу в логістичній ланцюга і його функції;

встановлюється загальна спрямованість технічної оснащеності складської системи (механізована, автоматизована, автоматична);

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

вибираються елементи кожної складської підсистеми;

створюються комбінації обраних елементів усіх підсистем;

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

проводиться техніко-економічна оцінка кожного конкурентного варіанта;

здійснюється альтернативний вибір раціонального варіанта.

Вибір елементів складських підсистем ведеться за допомогою схем і діаграм чи розроблених програм на ЕОМ. Це забезпечує методичний підхід з урахуванням всіх можливих варіантів.

Логістичний процес на складі дуже складний, оскільки вимагає повної узгодженості функцій постачання запасами, переробки вантажу і фізичного розподілу замовлень. Практично логістика на складі охоплює всі основні функціональні області, що розглядаються на мікрорівні. Тому логістичний процес на складі набагато ширше технологічного процесу і включає (рисунок 1):

Функціонування всіх складових логістичного процесу має розглядатися у взаємозв'язку і взаємозалежності. Такий підхід дозволяє не тільки чітко координувати діяльність служб складу, він є основою планування і контролю за просуванням вантажу на складі з мінімальними витратами. Умовно весь процес можна розділити на три частини:

1) операції, спрямовані на координацію служби закупівлі;

2) операції, безпосередньо пов'язані з переробкою вантажу та його документацією;

3) операції, спрямовані на координацію служби продажів.

Постачання запасами. Основне завдання постачання запасами полягає у забезпеченні складу товаром (або матеріалом) відповідно до можливостей його переробки на даний період при повному задоволенні замовлень споживачів. Тому визначення потреби у закупівлі запасів повинно узгоджуватися зі службою продажу та наявної потужністю складу.

Контроль за поставками. Облік і контроль за надходженням запасів і відправкою замовлень дозволяє забезпечити ритмічність переробки вантажопотоків, максимальне використання наявного обсягу складу та необхідні умови зберігання, скоротити терміни зберігання, скоротити терміни зберігання запасів і тим самим збільшити оборот складу.

Розвантаження і приймання вантажів. При здійсненні цих операцій необхідно орієнтуватися на умови постачання укладеного договору.

Проведені на даному етапі операції включають:

розвантаження транспортних засобів;

контроль документального та фізичної відповідності замовлень постачання;

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

формування складської вантажної одиниці.

Внутрішньоскладське транспортування. Внутрішньоскладське транспортування передбачає переміщення вантажу між різними зонами складу. Транспортування вантажів усередині складу повинна здійснюватися за мінімальної протяжності в часі і просторі за наскрізними «прямоточним» маршрутами.

Складування і зберігання. Процес складування полягає в розміщенні та укладанні вантажу на зберігання. Основний принцип раціонального складування - ефективне використання обсягу зони зберігання.

Процес складування і зберігання включає:

закладку вантажу на зберігання;

зберігання вантажу і забезпечення відповідних для цього умов;

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

Комплектація (комісіонування) замовлень і відвантаження. Процес комплектації зводиться до підготовки товару відповідно до замовлень споживачів. Комісіонування замовлень клієнтів проводиться в зоні комплектації. Підготовка та оформлення документації здійснюється через інформаційну систему. При цьому вибирається оптимальний маршрут доставки замовлень.

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

Збір і доставка порожніх товароносітелей грають істотну роль у статті витрат. Ефективний обмін товароносітелей можливий лише в тих випадках, коли достовірно визначена їх оптимальна кількість і чітко виконується графік їх обміну зі споживачами.

Інформаційне обслуговування складу передбачає управління інформаційними потоками і є сполучною стрижнем функціонування всіх служб складу.

Інформаційне обслуговування охоплює:

обробку вхідної документації;

пропозиції по замовленнях постачальників;

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

управління прийомом і відправленням;

контроль наявності товарів на складі;

прийом замовлень споживачів;

оформлення документації відправлення;

диспетчерську допомогу, включаючи оптимальний вибір партій відвантаження і маршрути доставки;

обробку рахунків клієнтів;

обмін інформацією з оперативним персоналом і верхнім ієрархічним рівнем організації;

різну статистичну інформацію.

Контроль за виконанням замовлень та забезпечення обслуговування клієнтів.

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

1.2 Опис предметної області (бізнес-процеси)

Вся відповідальність в управлінні підприємством лежить на Генеральному директорові. Основною метою діяльності при управлінні є максимізація прибутку і мінімізація ризиків. Саме ці завдання є основними при роботі в цій сфері діяльності. Цілі діяльності можна охарактеризувати таким чином:

- Забезпечити створення відповідної організаційної структури продажів;

- Забезпечити ефективне управління персоналом;

- Планувати розміщення і асортимент товарів;

- Сегментувати ринок за покупцям.

Основними завданнями є:

підвищення оперативності та достовірності інформації про стан підприємства;

підвищення контролю виконання управлінських рішень і планів;

зниження ризику зловживань з боку персоналу;

оптимізація використання фінансових, трудових і матеріальних ресурсів;

розробка та впровадження нових інформаційних технологій, PR-акції, реклама;

планування та проведення спеціальних заходів;

просування товару;

ціноутворення;

оцінка ефективності управління.

Основні функції:

- Безпосередня участь у розробці та управлінні продажами;

- Ведення БД клієнтів та товарів;

- Складання та оформлення замовлень клієнтів;

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

- Надання необхідної інформації клієнтам;

- Надання необхідної інформації постачальникам;

- Здійснення заходів з розробки стратегії продажів;

- Мотивація співробітників;

- Пропозиція нових товарів;

- Ефективність управління.

Вся вищевказана інформація характеризує систему управління складською логістикою. Співробітниками даного відділу є:

Генеральний директор;

Працівники відділу збуту, головна функція яких полягає в роботі і зв'язку з клієнтами;

Працівники складу: їхня головна задача - забезпечення і контроль товарів.

Розробка даного автоматизованого робочого місця призначена для закритого акціонерного товариства (ЗАТ) «Пріосколье», яке на даний момент часу займає велику нішу на Російському ринку виробничих товарів. «Пріосколье» - це великий птахівничий комплекс, який почав свою діяльність в 2004 році, а вже в 2005 році підприємство вийшло на виробничу потужність. На даний момент обсяг виробленого м'яса птиці доведено до 50 тисяч тонн на рік. На даний момент у виробничій роботі зайнято близько двох тисяч чоловік.

Завдання, які ставить перед собою ЗАТ «Пріосколье» наступні:

створення вертикально-інтегрованого птахівничого комплексу із замкнутим циклом з виробництва м'яса бройлерів шляхом збільшення існуючих виробничих потужностей;

заняття міцної позиції вітчизняного товаровиробника курячого м'яса високої якості в існуючій сьогодні ніші продовольчих товарів, використовуючи:

знання і досвід провідних зарубіжних компаній для організації та технологічного ведення проекту перші 2-3 роки;

підтримку птахівництва Росії Урядом;

можливість отримання субсидій з федерального і обласного бюджету для компенсації відсоткової ставки за кредитом;

дозвіл урядом РФ безмитного ввезення в Росію соєвого шроту, найважливішого компонента корму птиці, виробленого в Росії в недостатній кількості;

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

1.3 Обгрунтування для розробки нового програмного забезпечення

При виборі способів власної автоматизації у кожної компанії існують такі альтернативи:

Придбати готове рішення.

У даній ситуації організація купує налаштовану модель ведення бізнесу. Плюсами такого рішення можна вважати: низьку вартість системи, універсальний набір пов'язаних бізнес процесів, високу надійність. Як мінусів слід відзначити: необхідність перебудови власної діяльності під придбану модель, відсутність специфічної управлінської звітності.

Придбати адаптируемой рішення і послуги з настроювання.

При такому підході організація отримає універсальне програмне забезпечення, адаптоване під його специфіку. Якість адаптації дуже сильно залежить від вартості додаткової настройки. Таке рішення буде враховувати специфіку даної організації, як в плані процесів, так і звітності. Надійність даного рішення буде менше, тому що в ході налаштування неминуче буде внесено якусь кількість помилок. Вартість володіння буде істотно вище, ніж у першому випадку.

Найняти власних фахівців, які створять рішення.

Даний підхід повинен мати право на життя тільки у випадку досконалої унікальності поставлених завдань. Аргументами за використання такого підходу може служити тільки повна відповідність рішення поставленим завданням.

Порівняльна характеристика існуючих

програмних продуктів.

На даний момент на російському ринку існує дуже багато різноманітного ПЗ для автоматизації складської логістики. Деякі з них представлені в таблиці 1, де описуються основні їх характеристики:

Таблиця 1

Для автоматизації складом ЗАТ «Пріосколье» мною був вибраний третій підхід. Таке рішення було прийнято з таких причин:

1) висока вартість тих програм, які вже існують на ринку. Я вважаю, що не кожне підприємство може дозволити собі програмне забезпечення вартістю від 15 до 50 тисяч доларів;

2) мала вірогідність того, що куплене програмне забезпечення буде повністю задовольняти вимогам конкретного підприємства. Можливо, доведеться «дописувати» деякі модулі програми.

Тобто автоматизована система управління складом буде створена саме для цього підприємства і буде унікальним у своєму роді. Даня програма буде виконувати такі операції як:

1. Адресний облік товарно-матеріальних цінностей на складі.

2. Розбиття складних складських процедур на найпростіші технологічні операції.

3. Управління діями співробітників на складі.

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

5. Отримання інформації про виконавця кожної технологічної операції.

Основними перевагами пропонованого нами рішення є:

1. Простота у впровадженні та використанні.

2. Унікальність і повну відповідність всім вимогам підприємства.

3. Невисока вартість.

1.4 Технічне завдання

Перш ніж приступати до розробки автоматизованої системи необхідно визначити основні критерії, за якими буде розроблена система і виявити основні вимоги. Для цього необхідно скласти технічне завдання, на підставі якого буде розроблена конкретна автоматизована система для підприємства.

1. Підстава для розробки.

Ця технічне завдання поширюється на розробку автоматизованої системи управління складом підприємства, призначеної для надання найбільш повної інформації про послуги та роботу ЗАТ «Пріосколье». Передбачається, що використовувати дану систему будуть співробітники складу.

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

Ця система забезпечить оперативний доступ до необхідної інформації.

2. Призначення.

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

3. Вимоги до програми або програмного виробу.

Вимоги до функціональних характеристик.

Система повинна забезпечувати можливість виконання наступних функцій:

Реєстрація в системі;

Аутентифікація;

Відображення, введення та корекцію інформації про товари, що є на складі;

Відображення, введення та корекцію інформації про клієнтів;

Введення і корекцію інформації про замовлення, надання клієнту його примірника договору, виведення на друк примірника договору підприємства;

Обробка замовлень і ведення фінансового журналу виконання замовлень;

Надання статистики з бухгалтерського обліку для клієнта;

Вихідні дані:

Список товарів;

Ціни на товари;

Інформація про клієнта (ПІБ, адресу, номер і серія паспорта);

Інформація про замовлення (код цікавить договору, дата і термін виконання замовлення).

Результати:

Список договорів;

Фінансовий звіт керівнику (прибуток і збитки за певний проміжок часу);

Електронні та надруковані екземпляри договорів.

Вимоги до надійності.

Передбачити контроль введеної інформації.

Передбачити блокування некоректних дій користувача при роботі з системою.

Забезпечити цілісність зберігається.

Забезпечити захист від несанкціонованого доступу до інформації.

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

Система повинна працювати на IBM сумісних комп'ютерах.

Мінімальна конфігурація:

Тип процесора ... ... ... Pentium II або Athlon і вище;

Частота процесора ... ... ... ... ... ... ... .. 333 Mhz і вище;

Обсяг оперативного запам'ятовуючого пристроїв ... 64 Мб і більше;

Обсяг вільного простору на жорсткому диску ... ... 5 M б і ​​вище.

Вимоги до інформаційної та програмної сумісності.

Система повинна працювати під управлінням операційних систем сімейства Win 32 (Windows 95, Windows 98, Windows Me, Windows 2000, Windows NT, Windows XP).

Вимоги до програмної документації.

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

Програмна система повинна включати довідкову систему про роботу і підказки користувачеві.

До складу супроводжуючої документації повинні входити:

Пояснювальна записка, яка містить опис розробки.

4.3.2 Керівництво системного програміста.

4.3.3 Керівництво користувача.

4.3.4.1. Схема структурна програмної системи.

4.4.3.2. Форми інтерфейсу користувача.

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

Глава II. Розробка ПЗ та побудова БД

2.1 Функціональні вимоги до системи

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

Для роботи у відповідності з даними принципами база повинна забезпечувати наступну функціональність:

А. Інформаційні.

Робота з інформацією про товар на складі.

Робота з адресною інформацією про клієнта.

Робота з ринковою інформацією.

Інформаційна підтримка продажів.

Б. Функції підтримки при роботі з клієнтом.

Поточна ситуація при роботі з клієнтом.

Потреби клієнта в товарах підприємства.

Робота по етапах угоди.

Забезпечення функцій з продажу при роботі з клієнтами.

В. Функції підтримки при управлінні відділом.

Планування роботи відділу.

Постановка завдань перед працівниками відділу.

Контроль виконання завдань працівниками відділу.

Контроль поточних показників роботи відділу.

Отримання фактичних показників за підсумками періоду.

Г. Функції аналізу і прогнозування.

Аналіз продажів.

Прогнозування динаміки продажів.

Аналіз результатів роботи співробітників.

Аналіз ринкової ситуації.

Д. Функції наявної інформації.

Оперативна обробка наявного масиву інформації при зміні окремих атрибутів (наприклад, при зміні територіального розподілу компаній).

Оперативне створення груп клієнтів для роботи за спеціальними програмами.

Інші групові дії над записами.

Перераховані функції є основними, для забезпечення яких і створюється база. Зрозуміло, в залежності від рівня реалізації, перелік функцій може мінятися - скажімо, у найпростішому випадку БД може забезпечувати тільки інформаційні функції, а інші тільки частково.

2.2 Схема роботи складу підприємства

Для проектування автоматизованого робочого місця «Логістика» використовується програма BPwin 4.0, яка є потужним інструментом для створення моделей, що дозволяють аналізувати, документувати і планувати зміни складних бізнес-процесів. BPwin пропонує засіб для збору всієї необхідної інформації про роботу підприємства і графічного зображення цієї інформації в вигляді цілісної і несуперечливої ​​моделі.

BPwin підтримує три методології: IDEF0, DFD та IDEF3, що дозволяють аналізувати бізнес з трьох ключових точок зору:

З точки зору функціональності системи. У рамках методології IDEF0 (Integration Definition for Function Modeling) бізнес-процес представляється у вигляді набору елементів-робіт, які взаємодіють між собою, а також показується інформаційні, людські і виробничі ресурси, що споживаються кожною роботою.

З точки зору потоків інформації (документообігу) у системі. Діаграми DFD (Data Flow Diagramming) можуть доповнити те, що вже відображено в моделі IDEF3, оскільки вони описують потоки даних, дозволяючи простежити, яким чином відбувається обмін інформацією між бізнес-функціями всередині системи. У теж час діаграми DFD залишають без уваги взаємодія між бізнес-функціями.

З точки зору послідовності виконуваних робіт. І ще більш точну картину можна отримати, доповнивши модель діаграмами IDEF3. Цей метод привертає увагу до черговості виконання подій. У IDEF3 включені елементи логіки, що дозволяє моделювати й аналізувати альтернативні сценарії розвитку бізнес-процесу.

B Pwin вміє перевіряти створювані моделі з точки зору синтаксису обраної методології, перевіряє посилальну цілісність між діаграмами, а також виконує ряд інших перевірок, щоб допомогти створити правильну модель, а не просто малюнок. При цьому зберігаються головні переваги малюнка - простота створення і наочність.

Як видно з контекстної діаграми (рисунок 2), що управляє інформація входить у блок зверху (Ліцензія на заняття торгівлею), в той час як вхідна інформація (Бланк заявки постачальнику, Бланк замовлення клієнта, Список про кількість запасів на складі), яка піддається обробці, показана з лівого боку блоку, а результати (вихід) показані з правого боку блоку (Заповнений і засвідчений бланк заявки, Договору, контрольні документи). Механізм (Працівники відділу складу, Працівники відділу продажів), який здійснює операцію, надається дугою, що входить в блок знизу.

Малюнок 2. Контекстна діаграма.

Далі блок «Автоматизована система управління складом» розбивається на три процеси, які представлені на діаграмі декомпозиції процесу (малюнок 3):

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

Формування замовлення клієнта;

Оформлення договору на продаж.

Малюнок 3. Діаграма декомпозиції процесу.

На підставі вищенаведених діаграм визначаються основні завдання і функції розробляється автоматизованої системи управління складом підприємства.

Основними завданнями системи є:

підвищення оперативності та достовірності інформації про стан підприємства;

підвищення контролю виконання управлінських рішень і планів;

зниження ризику зловживань з боку персоналу;

оптимізація використання фінансових, трудових і матеріальних ресурсів;

розробка та впровадження нових інформаційних технологій, PR-акції, реклама;

планування та проведення спеціальних заходів;

просування товару;

ціноутворення;

оцінка ефективності управління.

Основні функції системи:

- Безпосередня участь у розробці та управлінні продажами;

- Ведення БД клієнтів та товарів;

- Складання та оформлення замовлень клієнтів;

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

- Надання необхідної інформації клієнтам;

- Надання необхідної інформації постачальникам;

- Здійснення заходів з розробки стратегії продажів;

- Мотивація співробітників;

- Пропозиція нових товарів;

- Ефективність управління.

Вся вищевказана інформація характеризує систему управління складською логістикою. Співробітниками даного відділу є:

Генеральний директор;

Працівники відділу збуту, головна функція яких полягає в роботі і зв'язку з клієнтами;

Працівники складу: їхня головна задача - забезпечення і контроль товарів.

2.3 Вибір та обгрунтування технології проектування та інструментальних засобів розробки

Будь-який проект розробки програмного забезпечення в своєму розвитку проходить певний життєвий цикл - послідовність етапів і сукупність дій, в результаті яких створюється перша версія продукту. Реалістична модель життєвого циклу спрощує виконання проекту і гарантує, що в проекті з кожним наступним етапом реалізується все більше запланованих завдань. Перш ніж приступити до розробки системи необхідно мати чіткий опис методології розробки, адаптованої до конкретного проекту. На основі обраної методології проводиться вибір конкретних проектних інструментів і програмних засобів (таблиця 2):

Таблиця 2

Грунтуючись на всьому вищевказаному, було прийнято рішення використовувати в якості інструментального засобу розробки проекту Rational Rose Enterprise Edition, який повністю підтримує об'єктно-орієнтований підхід.

Rational Rose - CASE-засіб фірми Rational Software Corporation (США) - призначено для автоматизації етапів аналізу і проектування ПЗ, а також для генерації кодів на різних мовах і випуску проектної документації.

Структура та функції

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

Засоби автоматичної генерації кодів програм на мові С + +, використовуючи інформацію, що міститься в логічній та фізичної моделях проекту, формують файли заголовків і файли описів класів та об'єктів. Створюваний таким чином скелет програми може бути уточнений шляхом прямого програмування на мові С + +. Аналізатор кодів С + + реалізований у вигляді окремого програмного модуля. Його призначення полягає в тому, щоб створювати модулі проектів у формі Rational Rose на основі інформації, що міститься в визначених користувачем вихідних текстах на С + +. У процесі роботи аналізатор здійснює контроль правильності вихідних текстів і діагностику помилок. Модель, отримана в результаті його роботи, може цілком або фрагментарно використовуватися в різних проектах. Аналізатор має широкі можливості налаштування по входу і виходу. Наприклад, можна визначити типи вихідних файлів, базовий компілятор, задати, яка інформація повинна бути включена в формовану модель і які елементи вихідний моделі слід виводити на екран. Таким чином, Rational Rose / С + + забезпечує можливість повторного використання програмних компонент.

В результаті розробки проекту з допомогою CASE-засоби Rational Rose формуються наступні документи:

діаграми класів;

діаграми станів;

діаграми сценаріїв;

діаграми модулів;

діаграми процесів;

специфікації класів, об'єктів, атрибутів і операцій

заготівлі текстів програм;

модель розробляється програмної системи.

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

Тексти програм є заготовками для подальшої роботи програмістів. Вони формуються в робочому каталозі в вигляді файлів типів. H (заголовки, що містять описи класів) і. Cpp (заготівлі програм для методів). Система включає в програмні файли власні коментарі, які починаються з послідовності символів //##. Склад інформації, що включається в програмні файли, визначається або за замовчуванням, або за бажанням користувача. Надалі ці вихідні тексти розвиваються програмістами на повноцінні програми.

Взаємодія з іншими засобами і організація групової роботи

Rational Rose інтегрується із засобом PVCS для організації групової роботи і управління проектом та із засобом SoDA - для документування проектів. Інтеграція Rational Rose і SoDA забезпечується засобами SoDA.

Для організації групової роботи в Rational Rose можливо розбивка моделі на керовані подмодели. Кожна з них незалежно зберігається на диску або завантажується в модель. Як подмодели може виступати категорія класів чи підсистема.

Для керованої подмодели передбачено операції:

завантаження подмодели в пам'ять;

вивантаження подмодели з пам'яті;

збереження подмодели на диску у вигляді окремого файлу;

установка захисту від модифікації;

заміна подмодели в пам'яті на нову.

Найбільш ефективно групова робота організовується при інтеграції Rational Rose зі спеціальними засобами управління конфігурацією і контролю версій (PVCS). У цьому випадку захист від модифікації встановлюється на всі керовані подмодели, крім тих, які виділені конкретному розробникові. У цьому випадку ознака захисту від запису встановлюється для файлів, які містять подмодели, тому при зчитуванні "чужих" подмоделей захист їх від модифікації зберігається і випадкові впливу виявляться неможливими.

2.4 Постановка завдань по підсистемах

Вище були визначені функціональні вимоги до системи. Всі ці функції включають в себе реалізацію конкретних завдань.

Використання діаграми Use Case (рисунок 4) - це можливість побачити систему з її функціями і підфункції з точки зору користувача.

«Генеральний директор» з огляду на постійних зовнішніх і внутрішніх змін коригує бізнес-план. У ході написання цих коригувань слід дати достовірну оцінку макроекономічної ситуації і поточного стану ринку в цілому, а також положення на ньому галузі, динаміки її розвитку і наявних у неї перспектив, за умови незмінності підходів. Крім того, оцінюється внутрішня ситуація галузі і позначаються назрілі проблеми

Малюнок 4. Діаграма Use Case.

Розглянемо кожну функцію:

Проведення цінової політики - оптимальна цінова політика вимагає певної інформаційної підтримки. Ця функція є основною, тому що саме за допомогою неї можна значно підняти рівень продажів, знижуючи ціни. За допомогою неї ми враховуємо всі фактори і приймаємо рішення.

Порівняння наявних ресурсів - за допомогою цієї функції порівнюємо і аналізуємо вже наявні ресурси. За допомогою них можна охарактеризувати ефективність управління продажами.

Зниження витрат і ризиків - завдяки зниженню витрат можна підвищити попит і навпаки. Від цієї функції залежить багато чого, тому що ризик є прихованим перешкодою і може знизити рівень продажів.

Використання фінансових і матеріальних ресурсів - необхідно пов'язати наявні в нас ресурси з необхідними вимогами ринку.

«Склад» Від того, наскільки правильно і точно буде виконуватися і будуватися робота складу підприємства залежить дуже багато чого. Це грунтується на тому, що основною і головною функцією складу є контролювання і поповнення вже наявних товарів, а також закупівля нових. Поряд з цим розглядаються наступні функції:

Формування заявки (формування замовлень постачальникам) - необхідно оформити замовлення на основі планів закупівель. При цьому проводиться аналіз вже наявних товарів. Також виробляється точний аналіз ринку пропонованої продукції. Необхідно вибрати тих постачальників, які б відповідали нашим вимогам і запитам (наприклад, вибираємо прийнятні ціни та гарна якість замість дешевого товару, але зате низьких цін.)

Вхідний інформацією є:

ID постачальника;

Найменування товару;

Кількість одиниць;

Дата і час доставки;

Залишок товару на складі.

Вихідною інформацією є оформлення заявки.

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

Виконання зобов'язань за договорами - тут працівник Складу обумовлює точні терміни поставки і відвантаження товару. Виписує необхідні для цього документи.

Контроль взаєморозрахунків з постачальниками - необхідно своєчасно розраховуватися з постачальниками. В іншому випадку підприємство не застраховане від того, що постачальник не підведе і вчасно здійснить виконання нашої заявки. Це важлива функція, тому що мати одних і тих же постачальників протягом тривалого часу, з якими налагоджена робота набагато зручніше, ніж постійно від заявки до заявки налагоджувати контакти з новими.

«Відділ продажів» Який би вигідний товар не отримав Склад, як би добре не розпланував весь процес Генеральний директор в кінцевому підсумку все впирається у Відділ продажу та його працівників. Від того, наскільки добре вони знають і вміють виконувати свою роботу, залежить, як продаватиметься товар, і, як наслідок, благополуччя управління продажами. У системі, вважається, що працівник Відділу продажів сам заповнює форму замовлення. Форма заповнюється кожен раз, коли приходить новий клієнт.

Формування замовлення - замовлення формується грунтуючись на БД наявних товарів.

Вхідний інформацією є:

№ замовлення;

ID клієнта;

Найменування товару;

Кількість одиниць товару;

Вартість товару;

Дата замовлення.

Вихідною інформацією є оформлене замовлення.

Облік і контроль за виконанням замовлень клієнтів.

Ведення договорів з покупцями - обумовлюються умови доставки товару, а також умови розрахунку.

Аналіз продажів - на підставі аналізу продажів здійснюється вивчення споживчого попиту.

«Бухгалтерія» Головною задачею є автоматизація складського обліку, аналіз стану складів, контроль руху товарно-матеріальних цінностей; бухгалтерський та податковий облік в повній відповідності з національним законодавством; формування податкової, бухгалтерської та іншої регламентованої звітності в різні органи; бухгалтерський облік і контроль кошторисів витрат бюджетних організацій в повній відповідності з законодавством та відомчими інструкціями; збір зведеної звітності бюджетних організацій

«Клієнти» (споживачі) - підприємством вивчається споживчий попит на вироблений вид товару, розробляється гнучка система цін.

«Постачальники» - юридична або фізична особа, що забезпечує будь-якими товарами іншу особу на певних умовах. Постачальником може бути виробник і посередник.

Важливо знизити вартість матеріальних ресурсів для збільшення прибутку (при незмінних накладних витратах).

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

Критерії оцінки постачальника:

- Прийнятна ціна;

- Якість продукції, що поставляється;

- Якість обслуговування споживачів;

- Гнучкість поставок;

- Обмеження розміру замовлення;

- Дороги;

-Віддаленість постачальника від споживача;

- Психологічний клімат у колективі;

- Кредитоспроможність та фінансове становище.

Критерії вибору постачальника:

- Визначення кількості можливих постачальників (визначення всіх можливих постачальників, включаючи і тих, чиїми послугами наша компанія раніше не користувалася);

- Визначення позиції постачальників на ринку;

- Визначення професіоналізму і надійності постачальників;

- Попередня оцінка всіх можливих постачальників (порівняння показників сервісу та якості, пропонованих постачальниками видаткових матеріалів з ​​показниками, необхідними внутрівиробничими споживачами);

- Проведення переговорів з постачальниками;

- Оцінка рівня ціни;

- Надійність поставок.

Діаграма класів (class diagram) (малюнок 5) служить для представлення статичної структури моделі системи в термінології класів об'єктно-орієнтованого програмування. Діаграма класів може відбивати, зокрема, різні взаємозв'язки між окремими сутностями предметної області, такими як об'єкти і підсистеми, а також описує їхню внутрішню структуру і типи відносин.

Дана діаграма класів дозволяє побачити взаємовідносини між об'єктами системи, зв'язки і залежності.

Малюнок 5. Діаграма класів.

Діаграма Use Case і діаграма класів є підставою для побудови структури БД.

2.5 Обгрунтування вибору СУБД Access для розробки БД

Додаток Microsoft Access є потужною і високопродуктивної 32-розрядної системою управління реляційною базою даних (далі СКБД).

База даних - це сукупність структурованих і взаємозалежних даних і методів, що забезпечують додавання вибірку і відображення даних.

Реляційна база даних. Практично всі СУБД дозволяють додавати нові дані в таблиці. З цієї точки зору СУБД не відрізняються від програм електронних таблиць (Microsoft Excel), які можуть емулювати деякі функції баз даних. Існує три принципові відмінності між СУБД та програмами електронних таблиць:

СУБД розробляються з метою забезпечення ефективної обробки великих обсягів інформації, набагато більших, ніж ті, з якими справляються електронні таблиці.

СУБД може легко пов'язувати дві таблиці так, що для користувача вони будуть представлятися однією таблицею. Реалізувати таку можливість в електронних таблицях практично неможливо.

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

Access - потужна програма Windows. При цьому продуктивність СУБД органічно поєднуються з усіма зручностями та перевагами Windows.

Як реляційна СУБД Access забезпечує доступ до всіх типів даних і дозволяє одночасно використовувати декілька таблиць бази даних. Можна використовувати таблиці, створені в середовищі Paradox або dBase. Працюючи в середовищі Microsoft Office, користувач одержує у своє розпорядження повністю сумісні з Access текстові документи (Word), електронні таблиці (Excel), презентації (PowerPoint). За допомогою нових розширень для Internet можна безпосередньо взаємодіяти з даними World Wide Web і транслювати уявлення даних на мові HTML, забезпечуючи роботу з такими програмами як Internet Explorer і Netscape Navigator.

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

Незважаючи на те, що Access є потужною й складною системою, його використання не складно для непрофесійних користувачів.

Елементи бази даних.

Таблиці. У базі даних інформація зберігається у вигляді двовимірних таблиць. Можна так само імпортувати і зв'язувати таблиці з інших СУБД або систем управління електронними таблицями. Одночасно можуть бути відкриті 1024 таблиці.

Запити. За допомогою запитів можна здійснити вибірку даних з якого-небудь критерію з різних таблиць. У запит можна включати до 255 полів.

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

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

Макроси

Модулі. Модулі містять VBA-код, що використовується для написання процедур обробки подій, таких як наприклад натискання кнопки у формі або звіті, для створення функцій налаштування, для автоматичного виконання операцій над об'єктами бази даних та програмного управління операціями, тобто додавання VBA-коду дозволяє створити повну базу даних з налаштованим меню, панелями інструментів та іншими можливостями. Модулі знімають з користувача програми на необхідності пам'ятати послідовність вибору об'єктів бази даних для виконання тієї або іншої дії і підвищують ефективність роботи.

База даних може містити до 32768 об'єктів.

До складу Access входить безліч майстрів, розбудовників і надбудов, які дозволяють спростити процес створення об'єктів бази даних.

2.6 Розробка структури бази даних і відносин атрибутів

Здійснюється деталізація сховищ даних, а також документально обгрунтовуються сутності системи і способи їх взаємодії, включаючи ідентифікацію об'єктів предметної області (сутностей), властивостей цих об'єктів (атрибутів) та їх зв'язків (відносин).

Сутність представляє собою безліч екземплярів реальних або абстрактних об'єктів, що мають загальні атрибутами або характеристиками. Будь-який об'єкт системи може бути представлений тільки однією сутністю, яка повинна бути унікальною ідентифікована. Ставлення в узагальненому вигляді являє собою зв'язок між двома і більше сутностями. Ставлення повинне бути однозначно пойменовані.

Для ідентифікації вимог, відповідно до яких сутності залучаються у відносини, використовуються зв'язку. Кожна зв'язок єднає сутність і відношення і може бути спрямована тільки від ставлення до сутності. Значення зв'язку характеризує її тип і вибирається з множини: "0 або 1", "0 або більше", "1", "1 або більше", "діапазон p: q". Пара значень зв'язків, що належить одному і тому ж відношенню, визначить тип цього відношення.

Для більшості додатків досить використовувати такі типи відносин:

один до одного (використовується на верхніх рівнях ієрархії моделі даних, на нижніх зустрічається рідко);

один до багатьох (відносини такого типу є найбільш часто використовуваними);

багато до багатьох (використовується на ранніх етапах проектування з метою прояснення ситуації).

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

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

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

Розробка структури бази даних включає такі основні етапи, як:

ідентифікація сутностей, їх атрибутів, а також первинних і альтернативних ключів;

ідентифікація відносин між сутностями і вказівка ​​типів відносин;

дозвіл неспецифічних видів відносин (багато до багатьох).

Етап 1 є визначальним при побудові моделі. Вихідною інформацією для цього етапу служить зміст сховищ даних, визначається входять і виходять з нього потоками. Спочатку здійснюється аналіз сховища, що включає порівняння вмісту вхідних і вихідних потоків і створення на основі цього порівняння варіанта схеми сховища. На наступному кроці здійснюється спрощення схеми шляхом усунення надмірності. Наступний крок - спрощення схеми за допомогою нормалізації (видалення повторюваних груп). Єдиним способом нормалізації є розщеплення даної схеми на дві більш прості. Далі виробляється визначення ключових атрибутів для ідентифікації сутності.

Для кроку нормалізації існують концепції і методи, розроблені Коддом (Codd). Він встановив три типи нормалізованих схем, званих першої, другої і третьої нормальною формою.

Згідно Кодда будь-яка нормалізована схема (схема без повторюваних груп) автоматично знаходиться в першій нормальній формі (1НФ), незалежно від того, наскільки складний її ключ і який взаємозв'язок може існувати між її елементами. За визначенням схема знаходиться в другій нормальній формі (2НФ), якщо всі її ключові атрибути повністю залежать від ключа. Схема знаходиться в третій нормальній формі (3НФ), якщо вона знаходиться у 2НФ, і жодної неключових атрибут не залежить від іншого неключових атрибута.

Етап 2 служить для виявлення і визначення стосунків між сутностями, а також для ідентифікації типів відносин. На цьому етапі допускаються неспецифічні відносини "багато до багатьох".

Визначення відносин включає виявлення зв'язків, для цього ставлення має бути підтверджено в обох напрямках наступним чином: вибирається примірник однієї з сутностей і визначається, скільки різних примірників другий суті може бути з ним пов'язано.

Етап 3 призначений для вирішення відносин "багато до багатьох". Для цього кожне таке неспецифічне ставлення перетворюється на два специфічних з введенням нових.

2.6.1 Нормалізація бази даних

Нормалізація таблиць бази даних - перший крок на шляху проектування структури реляційної бази даних. Строго кажучи, звичайно, не найперший - спочатку треба вирішити, що ж ми взагалі будемо зберігати в базі, тобто визначитися зі структурою полів, їх типами і розмірністю, сенсом зберiгається в них інформації.

Теорія реляційних баз даних була розроблена в кінці 70-х років 20 століття. Відповідно до неї, виділяються шість нормальних форм, п'ять з яких так і називаються: перша, друга, третя, четверта, п'ята нормальна форма, а також нормальна форма Бойса-Кодда, що лежить між третьою і четвертою.

База даних вважається нормалізованої, якщо її таблиці (принаймні, більшість таблиць) представлені як мінімум в третій нормальній формі. Часто багато таблиці нормалізуються до четвертої нормальної форми, іноді, навпаки, проводиться денормализация.

Головна мета нормалізації бази даних - усунення надмірності та дублювання інформації. В ідеалі при нормалізації треба домогтися, щоб будь-яке значення зберігалося в базі в одному примірнику, причому значення це не має бути отримано розрахунковим шляхом з інших даних, що зберігаються в базі.

Перша нормальна форма

Перша нормальна форма:

забороняє повторювані стовпці (що містять однакову за змістом інформацію)

забороняє множинні стовпці (що містять значення типу списку тощо)

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

Друга нормальна форма

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

Третя нормальна форма

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

Нормальна форма Бойса-Кодда

Нормальна форма Бойса-Кодда вимагає, щоб в таблиці був тільки один потенційний первинний ключ. Найчастіше в таблиць, що знаходяться в третій нормальній формі, так і буває, але не завжди. Якщо виявився другий стовпець (комбінація стовпців), що дозволяє однозначно ідентифікувати рядок, то для приведення до нормальної форми Бойса-Кодда такі дані треба винести в окрему таблицю.

Четверта нормальна форма

Для приведення таблиці, що знаходиться в нормальній формі Бойса-Кодда, до четвертої нормальної формі необхідно усунути наявні в ній багатозначні залежності. Тобто забезпечити, щоб вставка / видалення будь-якого рядка таблиці не вимагала б вставки / видалення / модифікації інших рядків цієї ж таблиці.

П'ята нормальна форма

Таблицю, що знаходиться в четвертій нормальній формі і, здавалося б, уже нормалізовану до межі, в деяких випадках ще можна буває розбити на три або більше таблиць, з'єднавши які, ми отримаємо вихідну таблицю. Отримані в результаті такої, як правило, дуже штучної, декомпозиції таблиці і називають перебувають у п'ятій нормальна формі. Формальне визначення п'ятого нормальної форми таке: це форма, в якій усунуті залежності з'єднання. У більшості випадків практичної користі від нормалізації таблиць до п'ятої нормальної форми не спостерігається.

Розроблено спеціальні формальні математичні методи нормалізації таблиць реляційних баз даних. На практиці проектувальник баз даних, детально ознайомившись з предметною областю, як правило, досить швидко створить структуру, в якій більшість таблиць знаходяться в четвертій нормальній формі:.

Головне, чого ми доб'ємося, провівши нормалізацію бази даних - це усунення (або, принаймні, серйозне скорочення) надмірності, дублювання даних. Як наслідок, значно зменшується ймовірність появи суперечливих даних, полегшується адміністрування бази та оновлення інформації в ній, скорочується обсяг дискового простору.

2.6.2 База даних автоматизованої системи управління складом

Після того як всі таблиці системи відповідають принципам нормалізації БД, слід визначити набори зв'язків між таблицями для функціональної взаємопов'язаної роботи бази даних в системі (рисунок 6):

Малюнок 6. Схема даних.

Для цих цілей система в загальному вигляді умовно поділяється на три складові:

Клієнти та оформлення їх замовлень;

Постачальники, оформлення заявок;

БД товарів.

В розділ «Клієнти та оформлення їх замовлень» включено 2 таблиці:

«Клієнти»;

«ОформленіеЗаказа».

Зв'язуються таблиця «Клієнти» з таблицею «ОформленіеЗаказа» по ключовому полю «ID клієнта», використовуючи відношення типу «один до багатьох». Схема зв'язків показана на малюнку 7:

Малюнок 7. Схема зв'язку «Клієнти та оформлення їх замовлень».

В розділ «Постачальники, оформлення заявок» включені наступні таблиці:

«Постачальники»;

«ОформленіеЗаявкі».

Пов'язуємо ці таблиці використовуючи тип ставлення «один до одного», за ключовим полем «ID постачальника». Схема даних зв'язків показана на малюнку 8:

Малюнок 8. Схема «Постачальники, оформлення заявок».

У розділі «БД товарів» використовуються вже вищезазначені таблиці:

«ОформленіеЗаказа»;

«ОформленіеЗаявкі».

Ці таблиці зв'язуються між собою за допомогою за допомогою третьої таблиці «БД товарів» типом ставлення «один до багатьох». Це видно з малюнка 9:

Малюнок 9. Схема «БД товарів».

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

Для умов вимог Третьої нормальної форми в таблицях передбачений складовою ключ, що включає в себе два поля {номер замовлення та ідентифікатор клієнта}, унікальний, достатній і ненадлишковим, однозначно визначає кожний запис у таблицях.

Одному замовленому товару відповідає один номер замовлення, але якщо клієнт у процесі роботи з системою замовляє ще один товар, то на кожну запис з цього клієнту присвоюється один номер замовлення.

Якщо замовлення оформлено, то є, прийнятий на виконання в роботу, а клієнт бажає замовити додатковий товар, тоді оформляється нове замовлення, використовуючи ті ж ідентифікатори клієнта.

Основою для розробки бази даних служать таблиці, в яких міститься необхідна інформація.

У даній БД використовуються наступні таблиці:

1. «Клієнти» (таблиця 3):

ID Клієнта: ідентифікатор клієнта. Є ключовим полем даної таблиці. По ньому виконується пошук конкретного клієнта;

ПІБ клієнта: вводяться прізвище, ім'я, по батькові нового клієнта;

Місто: підприємству необхідно знати те місто, в якому проживає клієнт;

Адреса: адреса клієнта;

Телефон: телефон клієнта;

e - mail: необхідний для того, щоб підприємство в будь-який момент могло в'язатися з клієнтом і уточнити його замовлення;

Паспортні дані: необхідні для підприємства, тому що саме паспорт є головним засвідчує особистість клієнта документом.

Всі перераховані вище поля вкрай необхідні для того, щоб внести в БД найбільш точну й достовірну інформацію про клієнта.

Таблиця 3.

«Клієнти»

«ОформленіеЗаказа» (таблиця 4):

№ замовлення: є ключовим полем даної таблиці. За номером замовлення можна відстежити та ідентифікувати клієнта;

ID Клієнта: ідентифікатор клієнта;

НаіменованіеТовара: дається перелік товарів;

КолічествоЕдініцТовара: вибирається кількість товару;

СтоімостьТовара: ціна за одиницю товару;

ДатаЗаказа: число оформлення замовлення;

БДТоваров: звернення до БД товарів.

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

Таблиця 4.

«Оформлення замовлення»

«Продаж» (таблиця 5):

№ замовлення: є ключовим полем даної таблиці. За номером замовлення можна відстежити та ідентифікувати клієнта;

ФІОКліента: вводяться прізвище, ім'я та по батькові клієнта;

НаіменованіеТовара: вибирається зі списку всіх товарів;

СтоімостьТовара: ціна за одиницю товару;

КолічествоЕдініцТовара: кількість товару, що купується;

ДатаЗаказа: число оформлення продажу.

Для того, щоб продати товар необхідно знати те що ми продаємо і в якій кількості. Це найбільш докладно представлено в таблиці «Продаж» даної БД.

Таблиця 5.

«Продаж»

«БДТоваров» (таблиця 6):

НаіменованіеТовара: предлается весь перелік наявних товарів;

КолічествоТовараНаСкладе: кількість всіх товарів, які є на складі;

ЦенаЗаЕдініцуТовара: ціна за одиницю обраного товару;

ОстатокТовараНаСкладе: залишок певного товару на складі.

Продаючи товар або купуючи товар через постачальників нам необхідно керуватися якимись даними. Ці дані ми отримуємо з таблиці «БДТоваров».

Таблиця 6.

«БДТоваров»

«ОформленіеЗаявкі» (таблиця 7):

ID Постачальника: ідентифікатор постачальника, в даній таблиці є ключовим полем;

НаіменованіеТовара: той товару, який необхідно включити до списку заявки;

КолічествоЕдініц: колічесво товару, що замовляється;

ДатаВремяДоставкі: обумовлюються дата і час коли товар буде доставлений.

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

Таблиця 7.

«ОформленіеЗаявкі»

«Постачальники» (таблиця 8):

ID Пставщіка: ідентифікатор постачальника, в даній таблиці є ключовим полем;

ЮрідіческійАдрес: адреса, за яким можна зв'язатися з постачальником;

ПІБ: прізвище, ім'я, по батькові постачальника;

№ РасчетногоСчета: один з важливих атрибутів, необхідний для того, щоб підприємство могло переводити кошти на рахунок постачальника.

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

Таблиця 8.

«Постачальники»

Глава III. Система АРМ «Логістика»

Система АРМ «Логістика» призначена для автоматизації роботи з клієнтами, постачальниками, а також для отримання достовірної інформації про всі товари складу, про операції, вироблених на складі.

Для входу в систему АРМ «Логістика» Вам необхідно виконати наступні вказівки:

Включити комп'ютер;

в меню «Пуск» вибрати необхідну програму і запустити її;

запустити файл програми «ProjectLogistika»;

Після чого з'явиться форма «Безпечний вхід», на якій службовець підприємства (Працівник Відділу Продаж, Працівник Складу, Бухгалтер, або Генеральний Директор) - користувач системи АРМ «Логістика» - повинні будуть ввести індивідуальний пароль: Користувач і Пароль;

Це необхідно для того, щоб захистити систему від несанкціонованого доступу сторонніх осіб. У даній програмі пароль не може містити менше 6 і більше 20 символів (літери, цифри, або букви + цифри), не повинен містити пробілів. У коді програми прописаний так званий «лічильник», який блокує програму після 5 неправильних введень пароля.

Після цього на екрані користувача з'явиться головна форма програми «Головна форма», на якій користувач може виконати такі операції як: можливість зареєструвати клієнта і працювати з базою даних товарів, а також перейти на форму ведення бухгалтерського обліку та оформлення замовлень і заявок. Для всіх працівників підприємства визначена і обмежена область користування даною програмою. Тільки Генеральний директор та Бухгалтерія мають доступ до «Клієнтам», «Постачальникам», «БД товарів», «Бухгалтерії». Інші ж працівники можуть працювати тільки з конкретними, які стосуються їх безпосередньої сфері роботи додатками. Наприклад, працівники Складу можуть працювати з додатками «БД товарів» і «Постачальниками», а працівники Відділу Продаж з додатками «БД товарів» і «Клієнти».

Передбачається, що кнопка «Клієнти» призначена для працівників Відділу продажів, в обов'язки яких входить наступне:

зареєструвати нового клієнта і ввести про нього всю необхідну інформацію;

виконати нові операції для вже існуючих клієнтів (оформити замовлення клієнта);

продати товар.

Перш ніж почати роботу з клієнтом необхідно визначити статус конкретного клієнта: Новий клієнт або Існуючий клієнт.

Також є можливість з цього вікна перейти до додатків «Постачальники» і «Бухгалтерія», але це може зробити лише начальник Відділу Продаж, у якого є доступ.

Тут же на закладці "Товари" будь-який працівник Відділу Продаж може отримати достовірну інформацію про всіх наявних товарів. Для цього необхідно зайти на закладку «БД товарів». Також є можливість дізнатися в якій кількості (залишок) конкретний товар є на складі. Це можна побачити на вкладці «Товари» - «Залишок на складі».

Також тут автоматизовано число реєстрації клієнта. Працівник Відділу Продаж просто вибирає число і система автоматично зберігає його для подальшої роботи.

Після того, як будуть заповнені всі поля, такі як: Статус клієнта, Дата реєстрації, Інформація про клієнта працівник Відділу Продаж «Створює» клієнта. Також є можливість редагувати вже наявні записи, а також видаляти їх.

Після того, як клієнт зареєстрований при натисканні на кнопку «Створити» з'являється вікно «Оформлення замовлення».

Тут автоматично проставляється № замовлення та з попередньої таблиці переноситься ID клієнта. Працівник Відділу продажів повинен позначити всі товари, які хоче придбати клієнт. При виборі товару ціна конкретного товару визначається автоматично, кількість ж товару прописується вручну працівником Відділу Продаж.

Дата замовлення визначається автоматично на день оформлення замовлення.

Після заповнення полів «№ замовлення», «ID клієнта», «Найменування товару», «Кількість одиниць товару», «Вартість товару» працівник Відділу продажів повинен «Виконати пошук по БД товарів ...» і переконається в тому, що товар дійсно мається на наявності і в достатній кількості для здійснення конкретної продажу. При натисканні на кнопку «Виконати пошук по БД товарів ...» з'явиться наступне вікно:

Для того щоб отримати інформацію про конкретний товар необхідно не вкладці «Найменування товару» вибрати товар, що цікавить. Кількість товару вказується певним числом і вводиться вручну. На вкладці «Ціна за одиницю товару» з'явиться ціна в рублях, в залежності від того який товар обраний ціна з'являється автоматично. Також тут можна подивитися, скільки товару залишилося на складі і чи вистачить його для того, щоб оформити замовлення.

Після виконання всіх необхідних операцій з'являється вікно:

Замовлення вважається оформленим.

Повертаючись до нашої головної формі можна почати роботу з постачальниками. Передбачається, що кнопка «Постачальники» призначена для працівників Складу, в обов'язки яких входить наступне:

зареєструвати нового постачальника і ввести про нього всю необхідну інформацію;

виконати нові операції для вже існуючих постачальників (оформити заявку для клієнта);

Перш ніж почати роботу з клієнтом необхідно визначити статус конкретного клієнта: Новий клієнт або Існуючий клієнт.

Також з цього вікна можна перейти до додатків «Клієнти», «Бухгалтерія», але таку можливість має лише начальник Складу.

На вкладці «Товари» можна звернеться до БД товарів, а також отримати інформацію про будь-якому товарі (залишок), який є на складі.

На вкладці «Документи» з переліку ми вибирає конкретний документ: Заявка, Надходження ТМЦ (купівля-продаж), Надходження ТМЦ (комісія), Надходження ТМЦ (імпорт).

Далі заповнюються всі поля, завдяки яким ми отримуємо найбільш достовірну інформацію про постачальника. Створюємо нового постачальника або редагуємо вже існуючого. Після заповнення всіх полів з'являється вікно:

У «Найменування товару» галочкою позначаємо ті товари, які хочемо включити до заявки, а в «Кількість одиниць товару» вручну цифрами прописуємо то кількість товару, який нам необхідно. Після цього погоджуємо дату і час доставки товару і заповнюємо всі залишилися поля. Заповнивши всі поля натискає кнопку «Оформити заявку» і завершуємо роботу з постачальниками.

Також на головній формі є кнопка «БД товарів». Зайшовши на неї можна отримати повні відомості про всі товари. Які є в наявності. По натисненню на цю кнопку з'являється вікно:

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

Глава IV. Розрахунок економічної ефективності

4.1 Аналіз ринкових можливостей продукту

На ринку автоматизованих систем для великих організацій і фінансово-промислових груп на сьогодні можна виділити два основних суб'єкта: це ринок автоматизованих банківських систем (АБС) і ринок корпоративних інформаційних систем промислових підприємств. Незважаючи на сильний взаємозв'язок цих двох ринків систем автоматизації, пропоновані на них рішення, поки ще не достатньо інтегровані між собою, чого слід очікувати в недалекому майбутньому. Створюючи свої відділи та управління автоматизації, підприємства і банки намагалися облаштуватися своїми силами. Однак періодичне "перетрушування" інструкцій, складнощі, пов'язані з різними уявленнями користувачів про одних і тих же даних, безперервна робота програмістів щодо задоволення все нових і нових побажань окремих працівників і як наслідок - невдоволення керівників своїми програмістами кілька остудило запал як тих, так і інших . Отже, перший підхід до вирішення цієї проблеми зводився до проектування "знизу-вверх". У цьому випадку, за наявності кваліфікованого штату програмістів, цілком стерпно були автоматизовані окремі, важливі з точки зору керівництва робочі місця. Загальна ж картина "автоматизованого підприємства" проглядалася недостатньо добре, особливо в перспективі. Швидке зростання кількості акціонерних і приватних підприємств і банків дозволив деяким компаніям побачити тут майбутній ринок і інвестувати кошти у створення програмного апарату для цього зростаючого ринку. З усього спектру проблем розробники виділили найбільш помітні: автоматизацію ведення бухгалтерського аналітичного обліку та технологічних процесів (для банків це в основному - розрахунково-касове обслуговування, для промислових підприємств - автоматизація процесів проектування і виробництва, мається на увазі не конкретних верстатів і т.п. , а інформаційних потоків). Враховуючи той факт, що ядром АІС безумовно є апарат, який забезпечує автоматизоване ведення аналітичного обліку, більшість фірм почали з детального опрацювання даної проблеми. Системи були спроектовані "зверху", тобто у припущенні, що одна програма повинна задовольняти потреби всіх користувачів.

Розглянутий в даній роботі програмний продукт позиціонується як засіб, здатний усунути недоліки кожного з двох перерахованих вище підходів і вирішити задачу управління складом ЗАТ "Пріосколье".

4.2 Розрахунок одноразових витрат на розробку ПЗ

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

Фактична трудомісткість за стадіями проектування представлена ​​у вигляді таблиці (табл.4.1).

Таблиця 4.1.

Зміст стадій науково-дослідної роботи (НДР).

Отже, загальна фактична трудомісткість розробки ПЗ становить:

,

де - Загальна трудомісткість розробки, дні; Т i - трудомісткість за стадіями, дні; n - кількість стадій розробки.

До кошторису витрат на розробку ПО включаються:

матеріальні витрати;

основна і додаткова зарплати;

відрахування на соціальні потреби;

вартість машинного часу на підготовку та налагодження програм;

вартість інструментальних засобів;

накладні витрати.

Матеріальні витрати.

Під матеріальними витратами розуміють вартість усіх матеріалів, що використовуються в процесі розробки та впровадження ПЗ (в тому числі вартість паперу, дискет, картриджа чи фарбувальної стрічки і інших матеріалів) у діючих цінах.

У процесі роботи використовувалися матеріали й приналежності, представлені в таблиці 4.2.

Таблиця 4.2.

Матеріали та приладдя, використані в процесі розробки.

Основна і додаткова заробітні плати.

Основна заробітна плата при виконанні НДР включає зарплату всіх співробітників, які беруть безпосередню участь у розробці ПЗ. У даному випадку необхідно враховувати основні зарплати розробника (студента), керівника дипломного проекту, консультанта з економічної частини.

Таким чином, основна заробітна плата З _осн при виконанні НДР розраховується за формулою:

,

де З _{ср.дн. j} - середньоденна зарплата j-го співробітника, руб. / день; Т _{об. j} - загальна трудомісткість проекту j-го співробітника, дні; n - кількість співробітників, які беруть безпосередню участь у розробці ПЗ.

Основна зарплата розробника визначена з розрахунку 8000 руб. на місяць при середній кількості робочих днів, рівних 24:

.

Заробітна плата дипломного керівника становить 60 руб. / год, причому на консультацію заплановано 23 години. Отже, основна зарплата керівника дипломного проекту за весь період розробки дорівнює:

.

Заробітна плата консультанта з економічної частини складає 50 руб. / год, причому на консультацію заплановано 3 години. Отже, основна зарплата консультанта з економіки за весь період розробки дорівнює:

.

У результаті основна заробітна плата при виконанні НДР дорівнює:

.

Додаткова заробітна плата дорівнює 10% від основної:

.

Разом основна і додаткова заробітна плата складають:

.

Відрахування на соціальні потреби.

Відрахування на соціальні потреби становлять на сьогоднішній день 26% від загального фонду заробітної плати, отже:

.

Вартість машинного часу на підготовку та налагодження програм.

Вартість машинного часу З _ОМВ залежить від собівартості машино-години роботи ЕОМ З _МЧ, а також часу роботи на ЕОМ Т _ЕОМ, і включає амортизацію ЕОМ та устаткування, витрати на електроенергію, зарплату обслуговуючого персоналу.

Собівартість машино-години ЕОМ і принтера рівні відповідно:

,

.

Час роботи на ЕОМ і принтері рівні відповідно:

.

Витрати на обладнання.

,

де А _М - амортизаційні відрахування, руб.; Про _ф - вартість ЕОМ та устаткування, руб.; Н _ам - Норма амортизації,%; Т _м - час використання обладнання, дні

Витрати на електроенергію.

,

Витрати на обслуговуючий персонал.

Даний вид витрат відсутня. Таким чином, вартість машинного часу на підготовку та налагодження програм одно:

Вартість інструментальних засобів.

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

Таблиця 4 .3.

Вартість СПО.

Витрати на амортизацію інструментальних засобів:

руб.

Розрахунок вартості машинного часу

;

руб / год.

Накладні витрати.

Накладні витрати складають 30% від основної заробітної плати розробників ПЗ, а значить:

.

Отже, кошторис витрат на НДР наведена у таблиці 4.4.

Таблиця 4.4.

Кошторис витрат на розробку ПЗ.

4.3 Одноразові витрати організації замовника ПЗ при впровадженні автоматизованих робочих місць (АРМ)

До одноразовим затратам користувача програмного забезпечення K _заг відносяться витрати на оплату:

програмного забезпечення Ц _по;

інструментальних засобів Ц _ис;

ЕОМ, інших апаратних засобів і мережевого обладнання До _ЕОМ;

навчання персоналу До _осв.

Вартість програмного забезпечення.

Вартість програмного забезпечення, спеціально розробленого для замовника, розраховується за формулою:

,

де С _за - Собівартість ПЗ, витрати на розробку за кошторисом з таблиці 4.4; П - прибуток розробника 20-30% до витрат; ПДВ - податок на додану вартість 18%.

Отже, вартість програмного забезпечення дорівнює:

Вартість інструментальних засобів.

Вартість інструментальних засобів і річних сум амортизації наведені в таблиці 4.5.

Таблиця 4.5.

Розрахунок вартості та амортизаційних відрахувань інструментальних засобів.

Вартість ЕОМ, інших апаратних засобів і мережевого устаткування.

Вартість всього необхідного обладнання і річних сум амортизації наведені в таблиці 4.6.

Таблиця 4.6.

Розрахунок вартості та амортизаційних відрахувань обладнання.

Витрати на навчання персоналу.

Витрати організації на освоєння ПЗ та навчання персоналу роботі з програмою і ЕОМ здійснюються за формулою:

До _осв = З _годину * Ч _пр * Т _осв = 23.8 * 5 ​​* 42 +23.8 * 1 * 50 = 6188,00 (грн.),

де З _годину - годинна зарплата програміста (З _годину = 23,8 руб. / год);

Ч _пр - чисельність персоналу на навчання (Ч _пр = 5 чол.);

Т _осв - Тривалість навчання та освоєння (Т _осв = 42 годин).

Таким чином, на навчання чотирьох чоловік необхідно затратити 42часов. Для керівника необхідний 50-годинний курс навчання.

Отже, загальна сума одноразових капітальних вкладень розраховується за формулою:

Ра спределение інвестицій за часом реалізації проекту здійснюється на основі попередніх розрахунків часу необхідного для розробки ПЗ по окремих стадіях проектування (табл. 4.7), витрат на розробку і загальної суми одноразових капітальних вкладень.

Таблиця 4 .7

Графік реалізації проекту.

Результати розрахунків оформлені у вигляді інвестиційного плану (таблиця 4.8).

Таблиця 4 .8

Інвестиційний план.

Джерела фінансування проекту

Загальні інвестиції проекту складають 183285 рублів 19 копійок. Джерелами фінансування є власні кошти - 80% (146 628 рубля 19 копійок) і кредит комерційного банку, під 12% річних - 20% (36 657 рубля 00 копійок) на 2 роки.

Повернення кредиту здійснюється в кінці другого року, а з другого місяця виплачуються відсотки (12%). Наведемо розрахунки в таблиці 4.9.

Таблиця 4 .9

Розрахунки за кредит.

Сума всіх виплат після закінчення терміну складе 41055 рублів 84 копійки.

4.5 Поточні витрати користувача ПЗ при експлуатації АРМ

Поточні витрати користувача при впровадженні АРМ враховують витрати на рік на:

амортизацію обладнання, програмне забезпечення та інструментальних засобів;

матеріали (картриджі і папір);

електроенергію;

обтиральні та мастильні матеріали;

ремонт обладнання.

Амортизацію обладнання, програмне забезпечення та інструментальних засобів.

Дані по амортизації обладнання, ПЗ розташовані в таблицях 4.5, 4.6.

Матеріали.

При експлуатації будуть використовуватися матеріали, представлені в таблиці 4.10.

Таблиця 5.10

Матеріали, що використовуються в процесі експлуатації.

Електроенергія.

Витрати на електроенергію порахуємо за формулою:

де С _ЕОМ, З _принт. - вартість машино-години ЕОМ і принтера відповідно;

Т _{сут.ЕВМ,} Т _{сут.прінт.} - Добовий час роботи ЕОМ і принтера відповідно;

Т _рік - час робочих днів у році.

Обтиральні та мастильні матеріали.

Вартість обтиральних матеріалів дорівнює 50 рублів 00 копійок.

Ремонт обладнання.

Ремонт обладнання становить 5% від вартості. Значить:

До _5% = До _ЕОМ * 0.05 = 37532 * 0.05 = 1876,6 (рублів).

На основі проведених розрахунків складемо кошторис поточних витрат за рік (таблиця 4.11).

Таблиця 5.11

Кошторис поточних витрат.

4.6 Економія поточних витрат користувача ПЗ

Основними джерелами економії організації при створенні АРМ фахівців є:

економія витрат за рахунок прискорення документообігу;

економія за рахунок швидкої реакції на зміну уподобань покупців

економія витрат на заробітну плату;

економія матеріальних ресурсів за рахунок скорочення кількості витратних матеріалів

а також забезпечується економія за рахунок:

Економія витрат за рахунок прискорення документообігу.

У результаті впровадження АРМ відбувається прискорення документообігу, що є "вузьким" місцем будь-якій торговельній організації, а значить і збільшення клієнтської бази та обсягів продажів. Це дійсно серйозна проблема, особливо у світлі поступового виходу компанії на ринок роздрібних продажів. За оцінками фахівців економія складе не менше 19000 рублів на місяць або не менше 228 тисяч на рік. Більш оперативна робота з постачальниками дозволить знизити відсоток виплат за товарним кредитом і знизити ймовірність штрафних платежів за несвоєчасну поставку - при самому несприятливому збігу обставин порядку 27000 рублів на місяць. Значить, економія становитиме мінімум 300000 рублів на рік.

Економія за рахунок швидкої реакції на зміну уподобань покупців

Впровадження автоматизованої системи дозволить скоротити витрати, пов'язані з вимушеним зниженням ціни на товар в результаті падіння попиту на нього, тобто дозволить уникнути покупок і зберігання незатребуваною техніки. За найбільш песимістичними оцінками це дозволить заощадити від 7000 рублів щомісячно, тобто не менше 84000 на рік.

Економія витрат на заробітну плату за рахунок скорочення чисельності персоналу.

Оцінити прямий ефект від впровадження АРМ з цієї позиції дуже просто, так як в даному конкретному випадку воно призведе до звільнення одного робочого місця. Це пов'язано з тим, що функції нового АРМу дозволяють виконувати більше число операцій з меншою трудомісткістю. Розрахуємо економію по заробітній платі за формулою:

,

де D Ч - скорочення чисельності;

З _міс - оплата праці на місяць, (4000 руб.);

Т _еф - ефективний фонд робочого часу в рік, (12 місяців);

Х - розмір доплат, премій, (100%);

Y - відрахування на соціальні потреби, (26%).

З урахуванням звільнення комп'ютерної техніки та господарського інвентарю економія складе Е = 120960 +38532 = 159253 руб.

Економія матеріальних ресурсів за рахунок скорочення кількості та уніфікації звітних форм.

У результаті впровадження АРМ з'явиться можливість економії матеріальних витрат за рахунок скорочення кількості витратних матеріалів у розмірі 4700 рублів.

Таким чином, загальна економія після впровадження АРМ складе:

Е _заг. = 552000 +84000 + 120960 + 4700 = 761660 (рублів).

4.7 Фінансовий план проекту

Інвестиційний проект з фінансової точки зору об'єднує два протилежні процеси - створення виробничого об'єкта та отримання доходу. Тому для оперативного управління фінансами необхідно скласти таблицю грошових потоків відповідно до графіка реалізації проекту.

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

Оцінка ліквідності проекту грунтується на плануванні руху грошових коштів по кожному періоду. Для чого окремо розглядаються доходи і витрати об'єкта і різниця між ними в грошовому вираженні.

З позиції бюджетного підходу під ліквідністю, розуміють позитивну різницю (сальдо) надходжень і платежів протягом всього терміну життя проекту. Негативне значення сальдо надходжень і платежів говорить про дефіцит грошових коштів

Для оцінки фінансової спроможності проекту представимо вихідні та розрахункові дані в таблиці 5.12.

Так як сальдо готівки наростаючим підсумком є по всіх періодах позитивною величиною, перейдемо до визначення чистої поточної вартості проекту, що характеризує ефективність проекту.

Таблиця 5.12

Оцінка фінансової спроможності проекту.