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

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Зміст

Вступ

Розділ 1. Загальна частина

1.1 Опис предметної області

1.2 Організаційна структура управління підприємством

1.3 Особливості обліку матеріалів і сировини

1.4 Постановка задачі

1.5 Висновки

Розділ 2. Спеціальна частина

2.1 Загальна характеристика сучасних напрямків розвитку ІСТ

2.2 Технології побудови ІС

2.3 Реляційна модель даних

2.4 Підготовка специфікацій

2.5 Можливості MS Access та обґрунтування його вибору для БД та СУБД

2.6 Розробки ІС в середовищі MS Access

2.7 Висновки

Розділ 3. Економічна ефективність

3.1 Характеристика господарсько-фінансової діяльності підприємства

3.2 Розрахунок показників ефективності

Розділ 4. Охорона праці та техніка безпеки

4.1 Аналіз шкідливих та небезпечних факторів, які діють на працюючих при експлуатації ПК

4.2 Технічні засоби і організаційні заходи із усунення дії шкідливих і небезпечних виробничих факторів

4.3 Заходи пожежної безпеки

4.4 Інженерні рішення з охорони праці та техніки безпеки

4.4.1 Розрахунок звукового тиску

4.4.2 Проектування робочого місця оператора ПК

Висновки

Література

Додатки

Вступ

облік підприємство сировина розвиток

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

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

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

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

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

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

Завданням дипломного проекту є:

- Дослідити існуючу систему управління сировиною та виготовленою продукцією;

- Вдосконалення бази даних та СУБД;

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

- Оцінка фінансових витрат на впровадження;

- Оцінка отриманого економічного ефекту;

- Розробити заходи з охорони праці.

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

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

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

* аналіз вихідної інформації, що підлягає обробці;

* постановку задачі;

* розробку, або адаптацію програм і їх машинного рішення;

* вибір і організацію технічного збору і обробки даних;

Розділ 1. Загальна частина

1.1 Опис предметної області

Сьогодні користувачі ділових комп'ютерних програм обчислюються, напевно, сотнями тисяч. Як би ні були гарні комп'ютери і програми, серед такої кількості людей завжди найдуться незадоволені результатами автоматизації. Для ринку в цілому відсоток невдалих проектів не настільки великий. Але для кожного конкретного споживача невдача часом обертається великими проблемами. Відзначимо, що і для постачальника програм невдалі проекти несуть додаткові турботи і підривають репутацію. Проблеми і конфлікти в ході автоматизації нікому не потрібні. Аналіз критичних ситуацій показує, що майже завжди винуваті не програми або комп'ютери, а люди. Набагато легше виправити програму, чим змінити точку зору людини. До моменту конфлікту в проект вже вкладено безліч грошей. Закрити проект - виходить, викинути витрачені засоби і сили на вітер. Але і далі так продовжуватися не може. Найчастіше за допомогою експертного висновку люди сподіваються довести провину протилежної сторони. Але насправді, пошук винних не розв'язує проблему. Найкраще, щоб проблеми не виникало зовсім. Для цього дуже важливо вміти подивитись на проект очима іншої сторони. Відразу обмовимося, що випадок дійсно слабких і недороблених програм ми тут не розглядаємо. Багато потенційних проблем закладаються ще на етапі вибору програми або фірми-розроблювача. Тиражні недорогі бухгалтерські або торговельні програми, що мають найбільшу популярність, розраховані, як правило, на невеликі і в окремих випадках на середні підприємства. Їхнім поширенням займаються дилери. Такі програми завжди дешеві, інакше вони не були б масовими. Доход від простого продажу таких програм невеликий. Тому дилери намагаються заробити на послугах по впровадженню і настроюванню, для чого вони беруть контракт на комплексну автоматизацію. Сума контракту звичайно пропорційна величині підприємства, і деякі дилери намагаються роздобути клієнта більш масштабного - завод або навіть холдинг. Але, як сказано вище, програма - розрахована зовсім на інший розмір підприємства. У результаті закладається міна уповільненої дії. Проблеми виникнуть не відразу, а в міру введення в експлуатацію все нових і нових робочих місць. Система почне працювати з недозволенними затримками. Виникнуть проблеми з одержанням зведених результатів, з розмежуванням повноважень, зі специфікою обліку на окремих ділянках. Як не дивно, але претензії замовника можуть виникнути не до дилера, а до розроблювача і до його "поганої" програми. Але розроблювач чесно попереджав у рекламі, у документації і навіть у написі на коробці, що програма орієнтована на такий-то розмір і такий-то профіль діяльності підприємства. З погляду розроблювача, винуваті дилер і сам клієнт. У нашій практиці зустрічалися випадки, коли корпорація ламала голову, що краще вибрати систему R/3 або купити багато програм "1С: Бухгалтерія". У першому випадку проект обійдеться в мільйон доларів. В другому - витрати зменшаться на кілька порядків, а програми фірми "1С" відомі своєю високою якістю. Не завжди великому підприємству всякий раз потрібно купувати R/3 або "Галактику". Але надані кошти і розглянуті програми повинні бути порівнянні з масштабом поставленої мети. До числа помилок клієнта можна віднести також недоречну економію на впровадженні, настроюванні, навчанні. Дорогі програми упроваджуються власними силами протягом довгих місяців і в результаті працюють лише на 5-10% своїх можливостей. Найчастіше підводить бажання бути цілком незалежним від розроблювача. Для цього здобуваються самі гнучкі програми, щоб можна було самостійно настроїтися на будь-які зміни в законодавстві. Але іронія полягає в тому, що для такого настроювання залучаються випадкові програмісти, залежність від яких ще гірше, ніж від розроблювача або офіційного дилера. Припустимо, що вибір зроблений. Обрано і встановлена гідна програма. При цьому контракт передбачає навчання, але до початку досвідченої експлуатації персонал замовника поняття не має, як працювати із системою. Директор і головний бухгалтер самі програму не вибирали, але вони були в курсі, що на проект витрачені чималі гроші. Вони майже повірили в те, що автоматизація - це не модне віяння, а справа, що приносить результат. Раптом виявляється, що комп'ютери і програми стоять самі по собі, а персонал працює по старинці. З погляду цих керівників, в усьому винуваті розроблювачі. Їм заплачені гроші, а результату немає. На думку розроблювачів, винуватий замовник, що не тільки не зміг організувати процес навчання, але і взагалі не бажав додавати ніяких організаційних зусиль. Перехід на комп'ютерний облік для великого і навіть середнього підприємства - це дуже непростий процес, що вимагає перегляду буквально всіх звичних операцій, проведення ревізії всіх документів, понаднормової роботи персоналу, подвійної навантаження від рівнобіжного ведення ручного і комп'ютерного обліку. Без залізної волі керівництва такий процес не може бути проведений у стислий термін. А розтягування цього процесу в часі може відбити бажання до автоматизації в будь-якого співробітника. Кожне досить велике підприємство по-своєму унікальне. Починаючи від способу розподілу облікових функцій між персоналом і закінчуючи тим, як територіально розташовані робочі місця з комп'ютерами і яким чином вони з'єднані в мережу. Автоматизація найчастіше ведеться поетапно і з метою економії попереднє повномасштабне обстеження не проводиться. Тому через рік - інший після початку робіт раптом з'ясовується, що продуктивність вже обраної системи недостатня. Прикладна розробка цілком гарна з погляду набору функцій, але інструментальна платформа слабенька. Розроблювач затверджує, що необхідно переходити на Oracle і докупити трохи більш могутніх комп'ютерів. Але замовник не згодний нести додаткові витрати. Таким чином, знову виникає конфліктна ситуація. Припустимо, що проект доведений до логічного кінця. Система встановлена, дороблена, персонал навчений. Але напередодні здачі проекту з'ясовується, що, на думку замовника, ряд задач вирішені не так. Виконавець у свою чергу затверджує, що за результатами досвідченої експлуатації ці задачі були визнані цілком відповідним вимогам технічного завдання. Окремі елементи комплексу цілком задовольняють окремих користувачів. Але хтось повинен прийняти усе в цілому. Для цього замовник терміново призначає нового відповідального, котрий зовсім не в курсі справ. Відповідальний з метою підстрахування починає придумувати нові вимоги, щоб відтягнути момент підписання акта приймання. Ще частіше нам приходилося зіштовхуватися з проблемами, що виникають через зміну керівництва. У цьому випадку майже завжди змінюється мета, стратегія, а іноді навіть і напрямок діяльності. Розроблювачі в цей час закінчують останній етап автоматизації і зненацька виявляють, що результат їхньої праці безнадійно застарів. Треба сказати, що найчастіше нове керівництво в таких випадках не має претензій до розроблювачів, але і доводити до кінця проект теж не погоджується. Нерідко воно наполягає на установці іншої програми, більш знайомої їм за місцем попередньої роботи. Персонал підприємства, що витратив півроку на освоєння і запуск однієї програми, природно, не хоче ще півроку освоювати іншу. До речі, чим комплексним буває впровадження програм, тим сутужніше неї замінити. На одному великому заводі довгий час упроваджували вітчизняну розробку. Розроблювачі разом з аудиторами виступали при цьому ще й у ролі консультантів по постановці обліку і фінансового планування. Проект був удало довершений. Але через півтора року завод був перекуплений іноземцями, що настояли на покупці західної програми замість цієї. А ще через 10 місяців марних зусиль по її впровадженню знову повернулися до вітчизняної розробки. Як пояснили нам аудитори, весь облік і навряд чи не всі управлінські технології на заводі були побудовані під ту першу програму. Перемінити програму було неможливо без зміни всієї технології обліку і керування. А західну програму не викинули. Раз або два в році з її допомогою друкували довідки для іноземних співвласників. Вище приведено лише кілька прикладів, позначивши в кожнім випадку причину виникнення проблеми і думка кожної сторони. Розібравшись з причиною будь-який конфлікт можна перебороти. При одній умові - для цього повинна бути добра воля обох сторін. Але в житті, на відміну від статті, кожен частіше бачить тільки свою правоту.

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

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

- орієнтація на розмір підприємства;

- локальні і мережні версії;

- вітчизняні і закордонні програми.

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



Рис. 1.1 Класифікація програм бухгалтерського обліку.

1.2 Організаційна структура управління підприємством

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

Структура підприємства вказана на схемі що зображена нижче (Рис. 1.2).

Рис. 1.2 Організаційна структура підприємства

Директор підприємства керує підприємство, а також контролює інші підрозділи підприємства.

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

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

У відділі кадрів (ВК), при прийнятті на роботу працівника складається особиста картка. Вона включає в себе відомості, отримані з трудової книжки, яка ведеться у ВК, диплому, паспорту. При прийомі на роботу, у відповідності з професією і кваліфікацією працівника, призначають йому посаду, відділ, в якому він буде працювати, а потім по цим даним у документі «Штатний розклад» визначають оклад. Посада, відділ, оклад, а також прізвище, ім'я та по-батькові, дата зарахування на роботу, табельний номер, який працівникові присвоюють у ВК, вказують у « Наказі про прийом на роботу». Підтверджений директором наказ передається у бухгалтерію. Форма цього документу наведена у додатку 1. Інспектор ВК попереджує керівника відділу, в який призначено працівника на роботу.

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

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

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

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

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

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

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

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

Вихід кожного виду готової продукції або напівфабрикатів з виробництва оформляється відповідною первинною документацією: прийомно-здавальними накладними. У них вказують №, дату, цех, склад, найменування продукції, одиницю виміру, кількість та інші реквізити. Тут також відображають підписи осіб того, хто здав і того хто прийняв готову продукцію. Накладні надходять до бухгалтерії для обліку випуску готової продукції. Крім накладних складають « Відомість надходження готової продукції по цехах «, де вказують скільки і яких видів прийнято від цеху. На підприємствах з масовим випуском готову продукцію передають із цеху на склад кілька разів за зміну, а інколи ці операції здійснюються безперервно. В окремих випадках готову продукцію передають на склад один раз за зміну.

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

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

1.3 Особливості обліку матеріалів і сировини

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

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

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

Дебет субрахунку «Інші матеріали».

Кредит рахунка «Брак у виробництві».

1.4 Постановка задачі

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

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

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

Також потрібно буде підібрати оптимальне середовище створення СКБД для виконання поставленої задачі, щоб мінімізувати затрати на впровадження і навчання персоналу, що в свою чергу вплине на кінцеву ефективність від впровадження ІС. Далі нам буде потрібно підібрати конфігурацію комп'ютера для створеної БД та СКБД.

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

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

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

Висновки

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

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

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

Розділ 2. Спеціальна частина

2.1 Загальна характеристика сучасних напрямків розвитку ІСТ

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

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

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

Можна виокремити такі сучасні вимоги до даних і їх обробки:

* дані мають значний обсяг;

* характеризуються різнорідністю (кількісною, якісною, текстовою);

* результати обробки мають бути конкретними й зрозумілими;

* інструменти для обробки первинних даних -- простими в користуванні.

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

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

До третього, одного з найпоширеніших типів ІС, застосовуваних в управлінні, належать такі:

* АСУ -- автоматизовані системи управління;

* СППР -- системи підтримки прийняття рішення;

* ЕС -- експертні системи.

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

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

Системи підтримки прийняття рішень. СППР призначені допомагати робити обґрунтований вибір із певного переліку альтернатив. Перш ніж набула поширення клієнт-серверна архітектура, застосовували два типи СППР: ІС для керівництва (управлінські) -- Executive Information System (EIS), та системи підтримки рішень -- Decision Support System (DSS). EIS створювались на великих ЕОМ і призначалися для керівництва верхнього рівня. DSS виконувались на робочих станціях і призначалися для менеджерів середньої ланки. Але останнім часом завдяки делегуванню повноважень із прийняття рішень середній та нижній ланці відмінності між цими типами СППР поступово зникають. У загальному випадку СППР складаються із СУБД, системи управління банком моделей та інтерфейсу користувача.

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

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

2.2 Технології побудови ІС

Сучасні концепції створення ІС ґрунтуються на таких підходах:

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

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

CASE (Computer Aided System Engeneering) -- технологія комп'ютерного проектування ІС, призначена для розробки складних ІС у цілому. Під CASE-технологією розуміють програмні засоби, що підтримують процеси створення та супроводження ІС (зокрема, аналіз і формулювання вимог), проектування прикладного програмного забезпечення (додатків) і баз даних, генерування коду, тестування, документування, конфігураційне керування, управління проектом та інші процеси.

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

SADT (Structure Analyse and Design Technic) -- технологія структурного моделювання, призначена для побудови функціональної моделі об'єкта певної предметної області. Головна мета SADT-технології -- описувати складні об'єкти як ієрархічні, багаторівневі модульні системи за допомогою невеликого набору типових елементів. До найістотніших властивостей SADT-технології належать:

* принцип побудови моделі згори вниз;

* реалізація ієрархічного, багаторівневого моделювання;

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

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

* Data Warehouse -- концепцію побудови сховища даних;

* Data Mart -- вітрини даних;

* OLAP (On-Line Analitical Processing) -- багатовимірний оперативний аналіз даних;

* Data Mining (DM) -- інтелектуальний аналіз даних.

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

У своїй дипломній роботі я удосконалюю існуючу ІС підприємства шляхом розробки БД.

Під час розв'язання наочних завдань доводиться реалізовувати алгоритми обробки масивів даних, які є не одноманітними масивами (безлічами) числових значень або текстів, а важливими структурними відносинами між елементами даних. Простіше всього структура - це вектор елементів. У загальному виді це можуть бути двох - або N-просторові масиви.

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

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

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

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

За допомогою СУБД забезпечується рішення таких основних завдань:

* Створення бази даних;

* Занесення, коректування й вилучення даних;

* Упорядкування даних;

* Вибір сукупності даних, що відповідають заданим критеріям;

* Оформлення вихідних даних і т.д.

Сукупність СУБД і бази даних - це банк даних. До достоїнств підходу, що ґрунтується на концепції банку даних, належить:

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

* Вірогідність і не протиріччя інформації, що зберігається;

* Санкціонований доступ до даних;

* Адаптаційної моделі до змін предметної області;

* Видача інформації у формі встановленій користувачем;

* Одноразове введення даних і багаторазове їхнє використання;

* Можливість виключення надмірності даних, що зберігаються, і т.д.

2.3 Реляційна модель даних

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

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

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

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

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

Кінцева безліч атрибутів, що визначають суть, є схемою відносин.

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

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

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

Основу такої моделі становлять двовимірні таблиці, які мають такі властивості:

* Кожний осередок таблиці є елементом даних;

* Кожний стовпець таблиці має унікальне ім'я;

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

* У таблиці не повинне бути однакових рядків;

* Рядки повинні мати однакову довжину, їхнього поля різнорідні й взаємозалежні;

* Порядок проходження рядків і стовпців довільний.

Ці нормалізовані відносини виділяють у форми:

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

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

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

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

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

* "один-до-одного"- це такий зв'язок, коли одного запису однієї таблиці відповідає не більше як один запис іншої таблиці.

* "Один-до-багатьох"- це такий зв'язок, коли одного запису головної таблиці відповідають кілька записів підлеглої таблиці.

* "багато-до-одного"- це такий зв'язок, коли багатьом записам головної таблиці відповідають кілька записів підлеглої.

* "багато-до-багатьох"- це такий зв'язок, коли одного запису однієї таблиці відповідають кілька записів іншої таблиці.

2.4 Підготовка специфікацій

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

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

Вимоги до даних:

* Сировину завозять і потрібно вести її облік.

* Вести облік виготовленої продукції, а також її відвантаження на склад.

В обов'язок начальника зміни входить:

* реєструвати надходження сировини;

* реєструвати випущену продукцію;

* реєструвати відвантаження її на склад.

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

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

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

* типи сутностей;

* типи зв'язків;

* атрибути;

* домени атрибутів;

* потенційні ключі;

* первинні ключі.

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

* начальник зміни;

* облік продукції;

* облік сировини;

* вид продукції;

* вид сировини.

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

Таблиця 2.1 Таблиця зв'язків представлення "Інспектор відділу кадрів"

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

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

Наступний крок - визначення кардинальності і рівня участі для кожного типу зв'язків, наведених у Таблиці 2.1

Кардинальність будь-якого зв'язку може мати значення або "Один до одного" (1:1), або "один до багатьох" (1:М), або "багато до багатьох" (M:N). Для кожного зв'язку потрібно вказати його кардинальність і, якщо це можливо, верхній або нижній ліміти груп "М". Участь кожного з членів зв'язку може бути визначена або як повна (тотальна), або як часткова. Якщо зведень, що утримуються в специфікаціях, не досить для однозначного визначення властивостей деяких зв'язків, для прояснення ситуації варто звернутися до користувачів.

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

Таблиця 2.2 Атрибути які належать сутностям

начальник зміни	Номер начальника
	Прізвище
	І'мя
	По-батькові
	Телефон
	Адреса
облік продукції	Номер
	Серія
	Номер начальника
	Номер виду продукції
	Довжина
	Відвантажено( Так, Ні)
	Дата
облік сировини	Номер
	Номер начальники
	Номер виду сировини
	Кількість
	Дата
	Використано (Так, Ні)
вид продукції	Номер виду продукції
	Назва виду продукції
вид сировини	Номер виду сировини
	Назва виду сировини

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

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

Таблиця 2.3 Документування доменів атрибутів

Домен	Атрибут
Номер начальника	Числовий до99999
Прізвище	Символьний до 50
Ім'я	Символьний до 50
По-батькові	Символьний до 50
Телефон	Символьний до 50
Адреса	Символьний до 50
Номер	Числовий до 15
Серія	Числовий до 15
Номер виду продукції	Числовий до 15
Довжина	Числовий до 15
Відвантажено( Так, Ні)	Так, Ні
Дата	Дата
Номер виду сировини	Числовий до 15
Кількість	Числовий до 15
Назва виду продукції	Символьний до 15
Назва виду сировини	Символьний до 15

Визначення атрибутів, що є потенційними і первинними ключами

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

Таблиця 2.4 Сутності і їх первинні й альтернативні ключі

начальник зміни	Номер начальника	Прізвище Ім'я По-батькові
облік продукції	Номер	Серія
облік сировини	Номер
вид продукції	Номер виду продукції	Назва виду продукції
вид сировини	Номер виду сировини	Назва виду сировини

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

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

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

Після завершення процесу перетворення структури концептуальної моделі з метою задоволення вимог, пропонованих до структури даних з боку реляційних СУБД, ми будемо посилатися на перетворену модель як на логічну модель даних. Кінцевою метою виконання даного етапу є створення коректної, повної і точної локальної логічної моделі даних для представлення користувача "начальник зміни".

Перетворення локальної концептуальної моделі даних у локальну логічну модель

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

* Видалення зв'язків типу M:N.

* Видалення складних зв'язків.

* Видалення рекурсивних зв'язків.

* Видалення зв'язків, що мають атрибути.

* Видалення множинних атрибутів.

* Повторний огляд зв'язків типу 1:1.

* Видалення надлишкових зв'язків.

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

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

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

Створення діаграм «сутність-зв'язок», вид модифікованої моделі даних, з обліком усіх внесених до неї змін, показаний нижче на ER - діаграмі. Отриману в результаті внесення змін модель даних правильніше буде називати локальною логічною моделлю даних представлення "начальник зміни" рис. 2.1.