В постіндустріальному суспільстві розроблення сучасних ІС стало масовим видом діяльності. За таких обставин свiтове суспiльство дійшло висновку, що технологiя розробки ІС потребує свого оформлення як самостiйного iнженерного фаху, який мусить забезпечити у свiтi вiдповiдний кадровий потенцiал для постiйно зростаючого обсягу програмних розробок. Розроблення ІС визначається як iнженерна дiяльнiсть. Разом з тим, корисно навести її досить значнi вiдмiнності вiд традицiйної iнженерiї:
· традицiйнi гiлки iнженерiї мають високий ступiнь спецiалiзацiї, а в програмній інженерії спецiалiзацiя помiтна тiльки у досить вузьких застосуваннях (приміром, ОС);
· об'єкти традицiйної iнженерiї чітко визначенi, i манiпуляцiї з ними вiдбуваються у вузькому контекстi ТПР та деталей, що вiдповiдають типовим потребам замовникiв, де проблеми прийняття рiшень стосуються окремих деталей, а не загальних питань, тоді як у програмній інженерії подiбна типiзацiя вiдсутня;
· окремi проблеми традицiйної iнженерiї та вiдповiднi їм готовi рiшення добре класифiкованi та каталогiзованi, а у програмній інженерії кожна нова розробка – це нова проблема, у якiй досить важко розглядiти аналогiї з системами, побудованими ранiше.
Словосполучення “ програмна інженерія ” (ПІ) (Software Engineering) вперше вжито в 1968 р., коли створення ПЗ досягло такого ступеня розвитку, що дозволяє застосовувати інженерні технології. Зараз розроблення ПЗ стало справді масовим явищем.
Методи ПІ – це способи розроблення ПЗ, які містять рекомендації щодо послідовності обробки інформації, нотації, правила опису ІС тощо.
Основні проблеми, що постають перед ПІ, пов’язані з інтеграцією створеного раніше ПЗ у нові розробки (legacy challenge), роботою в розподіленому гетерогенному середовищі (heterogeneity challenge) та обмеженнями часу, що відводиться на розроблення інформаційного продукту (delivery challenge).
Основні роздiли програмної інженерії:
· аналiзування вимог до ІС, яку треба створити;
· детальний проект ІС;
· кодування;
· тестування системи;
· процес супроводження програмного продукту;
· керування конфiгурацiєю;
· забезпечення якостi розроблення;
· забезпечення вiдповiдностi розроблення вимогам її замовникiв та забезпечення вiдповiдностi кодiв проекту;
· процес удосконалення отриманого програмного продукту.
Виникнення ПІ визначено кількома факторами:
· появою різноманітних складних методів аналізування та моделювання ПрО;
· великою кількістю помилок в ПЗ;
· потребою в організації роботи великих колективів розробників ПЗ;
· необхідністю використання високотехнологічних засобів керування розробкою ПЗ.
Програмна інженерія робить акцент на оцінку якості ПЗ, що створюється, та повторне застосування програмних компонентів з метою прискорення та підвищення якості ІС.
Інформаційні системи управління за ступенем завершеності розробки поділяються на групи:
1) системи під замовлення (унікальні системи);
2) адаптовані системи.
Системи під замовлення (унікальні системи) – це системи, створені для конкретного підприємства, не мають аналогів і не підлягають подальшому тиражуванню. Розроблення унікальних систем є доречним або для автоматизації діяльності підприємств з унікальними характеристиками, або для вирішення обмеженого кола спеціальних задач. Сфера застосування систем даної групи здебільшого обмежується органами державного управління, освіти, охорони здоров'я, військовими організаціями. Системи під замовлення або взагалі не мають прототипів, або використання прототипу потребує його значних змін.
Основою АСУ адаптованих, є базова система, яка містить у собі ППП для вирішення задач управління; засоби комплексування задач у необхідні конфігурації; засоби сполучання з іншими системами. Базова система дає змогу створювати для підприємства гнучку, придатну до модифікації ІС, в якій сполучаються типові підходи до рішення задач управління та специфічні особливості підприємства. Базові системи здебільшого орієнтовані на певний клас підприємств і функціональну структуру ІС управління підприємством. Ці ознаки впливають на вибір базової системи і на процес створення ІС.
За повнотою функцій управління, автоматизованих в ІС управління підприємством, організацією, можна виділити такі групи:
1. Системи нижнього рівня Low-End – прості системи, призначені для автоматизації малих підприємств. У системах цієї групи практично повністю відсутнє налаштовування на параметри підприємства. Основні функції систем не є глибоко розгалуженими і розраховані на виконання досить обмеженої кількості стандартних бізнес-процесів. Здебільшого такі системи працюють на одному комп'ютері або в мережі з чотирьох – воcьми комп'ютерів.
Прикладами систем Low-End є невеликі бухгалтерські, торгові та складські системи (фірми “Інфін”).
2. Системи середнього рівня Middle-End характеризуються більшою (порівняно з попередньою групою) глибиною і широтою охоплення функцій. Вони потребують налаштовування, яке здебільшого здійснюють спеціалісти фірми-розробника, а також навчання користувачів. Можливості систем цього рівня охоплюють автоматизацію десятків бізнес-процесів.
Системами середнього рівня є облікові системи, що дають змогу вести облік діяльності підприємства за багатьма напрямами: фінанси, логістика, персонал, збут (системи фірми “Парус”).
3. Системи вищого рівня High-End мають розвинені механізми налаштовування з великою кількістю встановлених параметрів, досить складні генератори звітів і призначені для застосування на середніх підприємствах або в організаціях, що не висувають особливих вимог до функціональності та гнучкості систем управління. Проте функціональність таких систем вже є досить розгалуженою і передбачає автоматизацію сотень бізнес-процесів. Кількість користувачів системи може досягати кількох десятків. Прикладами систем High-End є “ІТ-підприємство” та “Галактика”.
4. ЕRР-системи (Enterprise Resource Planning) забезпечують управління всіма ресурсами організації, містять описи тисяч бізнес-процесів, можуть мати до 100 тис. налаштовуваних параметрів. Здебільшого у разі впровадження таких систем здійснюються моделювання існуючих на підприємстві бізнес-процесів і тривале налаштовування параметрів системи відповідно до вимог бізнесу. Системи можуть застосовуватись як на середніх, так і на дуже великих підприємствах і потребують упровадження на підприємстві спеціального підрозділу або групи спеціалістів, які здійснюватимуть переналаштовування системи відповідно до змін бізнес-процесів.
Концепції створення ІС породжені практикою бурхливого розвитку широкого застосування обчислювальної техніки в плануванні й управлінні виробничою діяльністю та беруть свій початок із середини 70-х років минулого століття.
Розробка АСУ висунула на порядок денний дві взаємопов’язані проблеми: з одного боку – це формалізація і стандартизація методів розроблення проектів; з другого – стандартизація методів прийняття управлінських рішень, які б відповідали визначеним цілям.
Процес розробки та застосування програмного виробу має назву його ЖЦ. Життєвий цикл – це безперервний процес, що починається з моменту прийняття рішення про необхідність створення програмного виробу і закінчується в момент його повного вилучення з експлуатації. Основні етапи циклу: проектування, програмування, налагодження, дослідна експлуатація, зберігання, промислова експлуатація, супроводження.
Структура ЖЦ за стандартом ICO/IEC 12207 базується на трьох групах процесів:
1) основні процеси ЖЦ (придбання, поставка, розробка, експлуатація, супроводження);
2) допоміжні процеси, що забезпечують виконання основних процесів (документування, управління конфігурацією, забезпечення якості, верифікація, атестація, оцінення, аудит, вирішення проблеми);
3) організаційні процеси (управління проектами, створення інфраструктури проекту, визначення, оцінення й поліпшення самого ЖЦ, навчання).
Розробка включає в себе всі роботи зі створення ПЗ та його компонентів відповідно до заданих вимог, навіть оформлення проектної та експлуатаційної документації; підготовку матеріалів, необхідних для перевірки працездатності й відповідної якості програмного продукту, матеріалів, необхідних для організації навчання персоналу, і т. ін. Розробка ПЗ включає в себе аналізування, проектування, кодування (програмування), тестування.
Експлуатація передбачає роботи з впровадження компонентів ПЗ в експлуатацію, в тому числі конфігурацію БД і робочих місць користувачів, забезпечення проектно-експлуатаційною документацією, проведення навчання персоналу і т. ін., і безпосередньо експлуатацію, в тому числі локалізацію проблем і усунення причин їх виникнення; модифікацію ПЗ в рамках встановленого регламенту; підготовку пропозицій до вдосконалення, розвитку й модернізації системи.
Управління проектом пов’язане з питаннями проектного планування й організації робіт, створення колективів розробників і контролю термінів і якості виконання завдань. Технічне та організаційне забезпечення виконання проекту включає вибір методів та інструментальних засобів для його реалізації, визначення методів опису проміжних станів розробки, розробку методів і засобів випробувань ПЗ, навчання персоналу й т. ін. Забезпечення якості реалізації проекту пов’язане з вирішенням проблем верифікації, перевірки й тестування ПЗ. Верифікація – це процес визначення відповідності поточного стану розробки, досягнутого на даному етапі, вимогам цього етапу. Перевірка дає можливість оцінити відповідність критеріїв розробки початковим вимогам. Перевірка частково збігається з тестуванням, пов’язаним з ідентифікацією відмінностей між дійсними та очікуваними результатами й оцінкою відповідності характеристик ПЗ початковим вимогам. У процесі реалізації проекту важлива роль належить питанням ідентифікації, опису та контролю конфігурації окремих компонентів і всієї системи у цілому.
Управління конфігурацією є одним з допоміжних процесів, що підтримують основні процеси ЖУ ПЗ, передусім процеси розробки й супроводження ПЗ. При створенні проектів складних ІС, складених з багатьох компонентів, кожний з яких може мати різновиди (версії), виникає проблема обліку їхніх зв’язків і функцій, створення уніфікованої структури та забезпечення розвитку цілої системи. Управління конфігурацією дозволяє організовувати, систематично враховувати і контролювати внесення необхідних змін до ПЗ на всіх стадіях його ЖЦ.
Кожен процес характеризується певними задачами і методами їх вирішення; початковими даними, отриманими на попередньому етапі, і результатами. Життєвий цикл ПЗ носить ітераційний характер: результати чергового етапу часто викликають зміни в проектних рішеннях, здійснених на більш ранніх етапах.
Життєвий цикл ПЗ починається з розуміння необхідності та потреби в такому програмному виробі, з вивчення та визначення завдання. Після того як сформулювана постановка задачі, починається проектування, тобто визначення структури даних, алгоритмів рішення задачі, структури програми та порядку взаємодії складових компонентів і комплексів програмного виробу. Кожен компонент кодується мовою програмування, налагоджується спочатку окремо, а далі у комплексі, після чого програмний виріб є готовим до експлуатації. У процесі експлуатації можуть бути виявлені помилки, не знайдені раніше.
У зв’язку зі зміною умов застосування програми користувач усвідомлює потребу або в її модернізації, або розробки цілковито нової програми — і цикл повторюється.
Життєвий цикл ПЗ поділяється на стадії. Першою стадією є технічне завдання. На цій стадії мають бути визначені вимоги до розроблюваної програми. За допомого аналізування існуючих аналогічних систем проводять дослідження здійснювання та обґрунтовують ефективність розроблюваної програми.
Одночасно необхідно з’ясувати істотні обмеження на програму (вони повинні бути сформульовані докладно) та встановити їх пріоритетність. Також необхідно виробити компроміс між конфліктуючими вимогами.
Наступною стадією ЖЦ програми є пояснювальна записка. Ця стадія робіт присвячена зовнішньому проектуванню програмного виробу, розробці його архітектури. Зовнішні специфікації, які є результатом зовнішнього проектування, описують очікувану поведінку програмного виробу з погляду користувача, тобто всі можливі вхідні дані системи – як допустимі, так і ні, та відповідне реагування системи на ці дані. На цьому етапі починається тестування усього програмного виробу.
Розробка архітектури програмного виробу є процесом розбивання великої системи на менші складові: програми, підпрограми, модулі, функції.
Технічний проект – третя стадія ЖЦ програми. На цій стадії робіт здійснюється проектування архітектури програми, яка включає визначення всіх модулів програми, їх взаємозв’язки.
Модуль – це послідовність логічно пов’язаних фрагментів програми, що оформляються як її окремі складові. Модуль має відповідати таким вимогам:
· кожен модуль може компілюватися окремо;
· модулі незалежні один від одного, тобто змінювання в одному модулі не вимагають змін в інших;
· модуль реалізує одну функцію або групу взаємопов’язаних функцій.
Робоче проектування. Дана стадія завершує розробку програми. Виконується кодування алгоритму мовою програмування, здійснюється індивідуальне налагодження модулів, об’єднання їх у комплекс і налагодження всього комплексу, перевірка працездатності за допомогою розроблених тестів.
Налагодження [debugging] – процес виявлення, локалізації та усунення помилок у програмі.
Суть налагодження полягає в тому, що користувач підготовляє систему тестів, з допомогою якої перевіряється робота програми в різних можливих режимах. Кожен тест містить набір початкових даних, результат яких відомий. Якщо в результаті роботи програми з даним тестом виходять результати, які відрізняються від очікуваних, то це свідчить про наявність помилки. Тест необхідно побудувати так, щоб він не лише встановлював сам факт помилки, а й локалізував цю помилку, тобто звузив підозрювану складову програми, яка містить помилки.
Налагодження великих і складних програм є процесом трудомістким внаслідок складності їх структури, тому варто підбирати не один, а кілька тестів, щоб перевірити найбільше число можливих ситуацій, які можуть виникнути в процесі роботи програми. Тож кожна програма під час налагодження вимагає ретельного підбору системи тестів.
Налагодження починається із запуску програми з введенням найпростіших даних. Далі перевіряється поводження програми при максимальних і мінімальних введених значеннях, з подальшим здійсненням перевірки поведінки програми при введенні значень, на які вона не розрахована. Далі перевіряються дані, виведені програмою.
На стадії впровадження виконуються підготовка та передача програми та програмної документації для супроводження користувачеві.
Стадія експлуатації не є стадією розробки; тут виконуються роботи, пов’язані з виправленням програмних дефектів або з незначними змінами в програмі.
Держстандарт 19.102—77 “EСПД. Стадії розробки” передбачає такі стадії розробки: технічне завдання, ескізний проект, технічний проект, робоче проектування, впровадження.
На стадії технічного завдання виділяють такі етапи:
1) обґрунтування необхідності розробки програми: постановка задачі; збір вихідних даних; вибір і обґрунтування критеріїв ефективності та якості розроблюваної програми; обґрунтування необхідності проведення науково-дослідних робіт;
2) науково-дослідні роботи: визначення структури вхідних і вихідних даних; попередній вибір методів рішення задачі; обґрунтування доцільності застосування програм, розроблених раніше; визначення вимог до технічних засобів; обґрунтування принципової можливості виконання поставленого завдання;
3) розробка та затвердження технічного завдання: визначення вимог до програми; розробка техніко-економічного обґрунтування розробки програми; визначення стадій, етапів і термінів розробки програми та документації до неї; вибір мови програмування; визначення необхідності проведення науково-дослідних робіт на наступних стадіях; погодження та затвердження технічного завдання.
Стадія ескізного проекту складається з таких етапів:
1) розробка ескізного проекту: попередня розробка структури вхідних і вихідних даних; уточнення методів рішення задачі; розробка загального опису алгоритму рішення задачі; розробка техніко-економічного обґрунтування;
2) затвердження ескізного проекту; розробка пояснювальної записки; погодження та затвердження ескізного проекту.
На стадії технічного проекту варто виділити такі етапи:
1) розробка технічного проекту: уточнення структури вхідних і вихідних даних; розробка алгоритму рішення задачі; визначення форм подання вхідних і вихідних даних; визначення семантики та синтаксису мови; розробка структури програми; остаточне визначення конфігурації технічних засобів;
2) затвердження технічного проекту: розробка плану заходів з розробки та впровадження програми; розробка пояснювальної записки; погодження та затвердження технічного проекту.
На стадії робочого проектування визначаються такі етапи:
1) розробка програми: розробка та налагодження програми;
2) розробка програмної документації: розробка програмної документації відповідно до вимог Держстандарту 19.101—77;
3) випробування програми: розробка, погодження та затвердження програми та методики випробувань; проведення попередніх державних, міжвідомчих, приймально-здавальних та інших видів випробувань; коригування програми та програмної документації за результатами випробувань.
На стадії впровадження здійснюються підготовка та передача програми: підготовка та передача програми та програмної документації до неї для супроводження та (або) виготовлення; оформлення та затвердження акта про передачу програми на супроводження та (або) виготовлення; передача програми у фонд алгоритмів і програм.
Для використання програмних засобів, крім власне програми, необхідна розробка повної та якісної програмної документації. Програмні документи містять відомості, необхідні для розробки, виготовлення, експлуатації та супроводження програми. До них відносять специфікацію, відомість тримачів оригіналів, текст програми, опис програми, програму та методику випробувань, технічне завдання, пояснювальну записку, експлуатаційні документи.
Eксплуатаційні документи містять відомості для забезпечення функціонування та експлуатації програми: відомість експлуатаційних документів, формуляр, опис застосування, посібник системного програміста, посібник програміста, посібник користувача, опис мови, посібник з технічного обслуговування.
Стандарт ICO/IEC 12207 не пропонує конкретну модель ЖЦ і методи розробки ПЗ. Він описує структуру процесів ЖЦ ПЗ, але не конкретизує в деталях, як реалізувати або виконати дії та задачі, включені в ці процеси. Під моделлю ЖЦ розуміється структура, що визначає послідовність виконання і взаємозв’язки процесів, дій і завдань, виконуваних протягом ЖЦ. Модель ЖЦ залежить від специфіки ІС і специфіки умов, у яких остання створюється і функціонує. Виділяють такі моделі ЖЦ:
· традиційна (кустарна);
· модель швидкого прототипу;
· модель, базована на повторному використанні компонентів;
· модель, базована на автоматизованому синтезуванні програми;
· каскадна;
· спіральна;
· CASE-метод.
Згідно з традиційною моделлю кодування та налагодження програми виконуються на початку розробки, а потім програму доводять до вимог користувача. В традиційній моделі відсутні етапи аналізування та проектування, і, як наслідок, програмний виріб має низькі характеристики якості; високу трудомісткість модифікації таких програм; процесу управління проектом взагалі не існує.
Метод швидкого прототипу передбачає розробку в доволі стислі строки діючого макета найкритичнішої до вимог користувача частини ПЗ і проведення дослідної експлуатації макета перед тим, як перейти до розробки повномасштабного зразка. Зазвичай, насамперед, прототипуванню підлягає інтерфейс користувача з майбутньою системою. Це дозволяє залучити кінцевих користувачів до активної співпраці на початкових стадіях розробки програми і таким чином уникнути доробок уже закінченої системи, що потребує значних коштів. Основне призначення даної моделі – полегшити виявлення всіх вимог користувача. Тому, як правило, прототип після розробки технічного завдання більше не використовується, і решта моделі ЖЦ збігається з каскадною.
Модель, базована на повторному використанні її компонентів, є основою так званого “ монтажного програмування ”, яке дозволяє суттєво скоротити тривалість розробки ПЗ, підвищити надійність при одночасному скороченні затрат на супроводження. Найбільшого ефекту під час використання цієї моделі досягається в тому разі, коли значну частину завдань можна сформулювати в термінах порівняно невеликої кількості підзавдань, які відповідають стандартним підпрограмам. Тоді розробка ПЗ зводиться до написання порівняно нескладної програми, яка викликає ці підпрограми в потрібній послідовності та організує обмін даними між ними. Такий методичний підхід передбачає вивчення понять і відношень відповідної сфери і розробку ППП, що реалізує ці поняття і відношення, а також вивчення технології застосування цього пакета під час формалізації завдання. Однак унікальні алгоритми обробки інформації складних завдань за допомогою стандартних програм описати практично неможливо. Тому модель, базована на повторному використанні її компонентів, у чистому вигляді не застосовується.
Модель, базована на автоматизованому синтезі програм, основана на представленні знань стосовн ПрО, так і процесів створення програмних засобів. Реалізація цієї моделі потребує достатньо високих початкових витрат на побудову моделей знань та створення інструментальних засобів для їх підтримки, що пов’язано з ризиком значного подорожчання саме розробки.
Основною характеристикою каскадної моделі є розбиття всієї її розробки на етапи, причому перехід від одного етапу до наступного відбувається тільки після того, як буде повністю завершена робота на поточному етапі (рис. 3.14.). Кожен етап завершується випуском повного комплексу документації, достатнього для продовження розробки іншою командою розробників.
Рис. 3.14. Каскадна модель розробки програмного забезпечення
Каскадний підхід найбільш придатний для побудови ІС, для яких на самому початку розробки можна досить точно і доволі повно сформулювати всі вимоги для надання розробникам можливості реалізувати їх якнайкраще. До цієї категорії належать складні розрахункові системи, системи рішення задачі в режимі реального часу.
Однак при використанні цього підходу виявилося, що реальний процес створення ПЗ ніколи повністю не вкладався в таку жорстку схему, постійно виникає потреба в поверненні до попередніх етапів і уточненні чи перегляді раніше прийнятих рішень.
Основним недоліком каскадного підходу є істотне запізнювання з отриманням результатів. Узгодження результатів з користувачами виконується тільки після завершення кожного етапу робіт; вимоги до ІС у вигляді технічного завдання на весь час її створення не змінюються. Таким чином, користувачі можуть внести свої зауваження лише після повного завершення роботи над системою. У разі неточного викладення вимог або зміни протягом тривалого періоду створення ІС користувачі отримують систему, що не задовольняє їхнім потребам.
Для подолання недоліків каскадної моделі була запропонована спіральна модель ЖЦ, що робить наголос на початкових етапах ЖЦ: аналізування і проектування. На цих етапах можливість реалізації проектних рішень перевіряється шляхом створення прототипів. Кожен виток спіралі відповідає створенню фрагмента чи версії відповідного ПЗ, на ньому уточнюються кінцеві цілі та основні характеристики проекту, визначається його якість і плануються роботи наступного обкрута спіралі (рис. 3.15). Таким чином, заглиблюються і послідовно конкретизуються деталі проекту, й у результаті вибирається обґрунтований варіант, який доводиться до реалізації.
Рис. 3.15. Спіральна модель життєвого циклу системи
Розробка ітераціями відображає об’єктивно існуючий спіральний цикл створення системи. Неповне завершення робіт на кожному етапі дозволяє перейти до наступного етапу, не чекаючи повного завершення робіт на поточному. При ітераційному способі розробки роботу, якої бракує, можна буде виконати на наступній ітерації. А основним завданням є якнайшвидше показати користувачам системи працездатний продукт, тим самим активізуючи процес уточнення та доповнення вимог.
Основним недоліком спіральної моделі є визначення моменту переходу до наступного етапу. Для цього визначення необхідно ввести тимчасові обмеження на кожний з етапів ЖЦ. Перехід здійснюється відповідно до плану, навіть якщо не вся запланована робота закінчена. План складається на основі статистичних даних, отриманих у попередніх проектах, і особистого досвіду розробника. Ще одним недоліком спіральної моделі є значні затрати ресурсів під час розробки великих проектів. Тому цю модель використовують тоді, коли масштаби проекту невеликі, але існує значна невизначеність щодо вимог до моделі користувача. Якщо ж проект достатньо великий, то в ньому можна виділити обмежену за обсягом підсистему, яку, вочевидь, доцільно розробляти, використовуючи спіральну модель. У зв’язку з труднощами планування робіт цю модель найчастіше застосовують у разі, коли розробник і користувач — одна й та ж сама організація.
У теперішній час розробці ПЗ притаманний високий ступінь автоматизації всіх робіт і перехід до індустріалізації цього процесу. Це виражається, передусім, у впровадженні CASE-систем, яке реалізує певну методологію розробки ПЗ, що охоплює весь його ЖЦ. Термін CASE (Comрuter Aided Software Engineering) набув вельми широкого змісту. Початкове значення терміна CASE, обмежене лише питаннями автоматизації розробки ПЗ, нині набуло нового змісту, який охоплює процес розробки складних ІС у цілому. Тепер під поняттям CASE-засобу розуміють програмні засоби, що підтримують процеси створення й супроводження ІС, включаючи аналізування та формулювання вимог, проектування прикладного ПЗ і БД, генерацію коду, тестування, документування, забезпечення якості, конфігураційне управління і управління проектом, а також інші процеси. Під засобами проектування ІС варто розуміти комплекс інструментальних засобів, що забезпечують у рамках вибраної методології проектування підтримку повного ЖЦ ІС. CASE-засоби разом із системним ПЗ і технічними засобами утворюють повне середовище розробки інформаційних систем. CASE-технологія являє собою методологію проектування програмного забезпечення, а також передбачає набір інструментальних засобів, що дозволяють у наочній формі моделювати ПрО, аналізувати цю модель на всіх етапах розробки й супроводження ПЗ та розробляти програми відповідно до вимог користувача. Більшість існуючих CASE-засобів базується на методологіях структурного або об’єктно-орієнтованого аналізування і проектування, що використовують специфікації у вигляді діаграм або текстів для опису зовнішніх вимог, зв’язків між моделями системи, динаміки поводження системи й архітектури програмних засобів. CASE-методологія припускає, як правило, наявність таких етапів: стратегічне планування, аналізування, проектування, реалізацію, впровадження, експлуатацію та супроводження. Кожен етап характеризується певними задачами і методами їх рішення, а також початковими даними, отриманими на попередньому етапі, й результатами.
На етапі стратегічного планування розробляється узагальнена модель організації, що описує її інформаційні потреби і (або) процеси, що тривають у ній. Розроблена модель стає основою процесу автоматизації даної організації та джерелом планування цього процесу. Планують розподіл усіх видів ресурсів, визначають послідовність робіт та їх пріоритети. Даний етап у CASE-системах відсутній. Результатом роботи на цьому етапі є концептуальна модель, що послужить основою етапу аналізування, і план розробки.
Етап аналізування починається з деталізації концептуальної моделі. На цьому етапі визначається, що, власне, підлягає розробці, і передбачається розробка сукупності моделей, які відображають різні аспекти проблеми. Процеси й потоки інформації відображаються діаграмами потоків даних; інформаційні потреби розроблюваної системи – діаграмами суть-зв’язок; тимчасові аспекти функціонування – діаграмами станів-переходів. Усі три типи діаграм застосовуються і на етапі стратегічного планування, але на узагальненішому рівні.
На діаграмах потоків даних відображаються потоки даних, процеси, що перетворюють вхідні потоки у вихідні, сховища інформації, зовнішні відносно до системи. Кожен з процесів може бути представлений діаграмою більш низького рівня. Надалі ці діаграми служать основою формування структури розроблюваного ПЗ. На діаграмах суть-зв’язок показуються так звані “сутності” (інформація, що представляє інтерес з погляду подальшого зберігання) і зв’язки між сутностями з відображенням характеру зв’язків. Ця діаграма є основою проектування БД. На діаграмі станів-переходів відображаються стани, в яких може знаходитися система, і можливі переходи з одного стану до іншого. На основі діаграми далі проектується інтерфейс користувача. Даний етап закінчується вибиранням попередньої архітектури системи з сукупності моделей, і ця інформація передається на наступний етап. Формується так званий “словник даних” – перелік описів усіх елементів моделей. Результатом є модель ПЗ, що являє собою сукупність моделей потоків даних, суть-зв’язок, станів-переходів; словник даних з описом усіх елементів моделей: потоків даних, СД, процесів, сутностей та їхніх атрибутів, а також зв’язків між сутностями, станів і переходів; план тестування; попередня архітектура системи.
Отримана інформація носить називу “структурної специфікації” розроблюваного ПЗ і відображає вимоги користувача до його розробки.
Етап загального проектування починається з аналізування попередньої архітектури, сформованого на попередньому етапі, і ґрунтується на критеріях якості, визначених для розроблення архітектури. Архітектура має логічний характер у тому сенсі, що вона не прив’язана до конкретних мов програмування, ОС та особливостей комп’ютера. У результаті отримуємо архітектуру системи у вигляді так званої “структурної схеми”, на якій відображені програмні модулі та зв’язки між ними, а також дані, що передаються від одного модуля до іншого; проект БД і інтерфейсу користувача; словник даних, що містить опис цих даних та їхньої структури; специфікації модулів з описом їх призначення та особливостей; проект архітектурних тестів.
Вся ця інформація передається на етап детального проектування. Тут розробляються алгоритми програмних модулів на основі їх специфікацій, отриманих на попередньому етапі проектування, а також проекти модульних тестів з урахуванням їхньої структури; все це переходить на етап реалізації.
На етапі реалізації програмні модулі кодуються вибраною мовою програмування відповідно до розроблених алгоритмів і налагоджуються. Далі за планом тестування проводиться тестування програмної системи. Після цього розроблене ПЗ передається на етап супроводження. Життєвий цикл розробки на цьому закінчується, і починається саме ЖЦ ПЗ.
CASE-технологія – потужний засіб, при правильному використанні якого процес розробки ІС спрощується завдяки використанню певного комплексу програм (CASE-засобу) та нового підходу до методології та правил, за якими відбувається створення ІС розробниками. За CASE-технологією інформаційні системи створюються ітераційним шляхом, при якому кілька разів відбувається процес проходження одних і тих самих етапів розробки. Це стає можливим завдяки використанню автоматизованих засобів зберігання інформації про попередній стан розробки кожної з робіт, з яких складається процес розробки системи. При зміні у форматі або переліку вхідних (вихідних) даних однієї зі складових для всіх інших, пов’язаних зі зміною, автоматично вставляється “прапор”, який вказує на те, що відбулася така зміна, і розробники повинні звернути увагу на цей факт.
Але варто дуже обережно підходити до проблеми переходу на нову систему проектування. Це пов’язано не тільки з проблемою вивчення можливостей та функцій нових програмних пакетів, з допомогою яких і відбувається процес розробки проекту, а й з тим, що проектувальниками затрачатимуться досить значні зусилля на вивчення нових технологій та ознайомлення з методиками проектування.
CASE-засоби забезпечують такі основні можливості з проектування та модифікації ІС:
1) швидкої побудови структурно-логічного опису складних комплексів та систем об’єктів, що взаємодіють між собою, динамічних процесів, потоків та БД під час побудови архітектури модельованої ІС. Швидкість розробки є принципово важливою, оскільки моделювання має бути не гальмом, а навпаки, – прискорювачем процесу проектування системи;
2) представлення логічно-динамічних процесів обробки інформаційних і матеріальних потоків системи на різних рівнях деталізації її архітектури з використанням узагальнень, адекватних даним рівня деталізації. Можливо описувати одні й ті ж самі процеси з різною мірою деталізації, а також вносити до моделі алгоритми функціонування організації у вигляді бізнес-правил, сформульованих експертами. Під час опису архітектури ІС є можливість наводити в моделі узагальнені правила логічної організації процесів обробки даних, обмеження та властивості архітектур модельованих систмеми;
3) створення єдиного прототипу динамічних моделей архітектур ІС, тобто представлення їх у формі, яка є відкритою, модифікованою, деталізованою. Для великих організацій процес створення прикладних моделей може розпочинатися та паралельно розвиватися в різних точках. Тому необхідно забезпечити єдину форму створення моделей на базі одного прототипу. Така форма представлення моделей відіграє також роль прототипу архітектури інформаційної системи, після чого послідовно уточнюється та деталізується до отримання результативних рішень. Важливо, щоб цей процес не супроводжувався кожного разу перепрограмуванням моделей, а полягав у коригуванні та деталізації простих структурно-візуальних компонентів, логічних зв’язків та правил функціонування моделей;
4) створення бібліотек типових об’єктів та моделей типових процесів, за допомогою яких можуть бути створені моделі нових проектів. Повинна бути забезпечена можливість інтеграції результатів моделювання однієї з ІС, що взаємодіють між собою, до імітаційних експериментів з іншою ІС з метою спрощення процесу дослідження їх сумісного функціонування;
5) інтелектуальної обробки результатів динамічного моделювання для оперативного отримання необхідних оцінок метрик та характеристик архітектури досліджуваних ІС за результатами імітаційних експериментів протягом великих відрізків модельного часу;
6) побудови динамічних моделей, орієнтованих на розробників ІС та експертів організацій, виконуючих не лише формування та оцінення вимог до ІС, а й реінженіринг бізнес-процесів автоматизованої організації.
3.4. Системи планування матеріальних ресурсів виробничого підприємства MRP, MRP II
У США на початку 60-х років XXст. проводились роботи з автоматизації керування запасами. Після Другої світової війни активне зростання багатосерійного й масового виробництва товарів народного споживання та торгівлі спонукали виробників до використання математичних моделей планування попиту й управління запасами, що веде до істотної економії коштів, заморожених у вигляді запасів і незавершеного виробництва. Було встановлено, що вибір оптимального обсягу партії замовлення – одна з найважливіших умов підвищення ефективності виробництва, тому що недостатній обсяг запасів веде до зростання адміністративних витрат у разі повторних замовленнь, а надлишковий – до заморожування засобів.
Середину 60-х років XX ст. можна назвати періодом розвитку методик управління підприємством та початковим етапом у зародженні та становленні ІС. Саме у цей час почалися роботи з автоматизації управління підприємствами на базі великих ЕОМ і централізованої обробки інформації та створювати ІС для управління окремими підрозділами чи видами діяльності, інтегровані з часом в комплексні автоматизовані системи.
Перші АСУ запасами в промисловому виробництві ґрунтувалися на розрахунках виходячи зі специфікації складу виробу (Bill of Materials). За планом випуску виробів формувалися плани виробництва деталей і складальних одиниць, плани діяльності допоміжного виробництва та розраховувався обсяг закупівлі матеріалів і комплектуючих виробів.
На період від кінця 60-х до кінця 80-х років XX ст. припадає новий етап у розвитку ІС пов’язаний з роботами американського вченого О. Уайта, який за умов автоматизації промислових підприємств пропонував розглядати в комплексі виробничі, постачальні та збутові підрозділи. Такий підхід і застосування обчислювальної техніки вперше дозволили оперативно коригувати планові завдання в процесі виробництва в разі зміни потреб, коригування замовлень, нестачі ресурсів, відмови обладнання тощо. У публікаціях О. Уайта й Американського товариства з управління запасами і виробництва (АPICS) було сформульовано методологію планування, відому нині як MRP (Material Requirements Planning) — планування потреби в матеріалах.
На відміну від методів теорії управління запасами, що припускають незалежний попит на всю номенклатуру, MRP часто називають “методом розрахунків для номенклатури залежного попиту”, тобто формування замовлень на деталі та комплектуючі вироби залежно від замовлень на готову продукцію. Практично MRP-система стала стандартом під час побудови ІС. Після появи цієї концепції почали активно створюватись і впроваджуватись комп’ютерні програми, що реалізують її нехитрі принципи. Згодом у процесі аналізування існуючої у світовому бізнесі ситуації та його розвитку з’ясувалося, що, окрім виробничих витрат, значна частина їх у собівартості продукції не пов’язана з обсягом і процесом виробництва. Потрібна була нова ідеологія, яка б поєднувала маркетинг і планування продажів безпосередньо з плануванням виробництва.
У подальшому вдосконалення системи привело до трансформації системи MRP із замкненим циклом у розширену модифікацію, яка згодом одержала назву MRPII (Manufactory Resours Planning) – планування ресурсів підприємства.
У цей період, окрім методологій MRP і MRPII, розвиваються й інші концепції планування та управління виробництвом. На японських підприємствах використовувався метод планування і управління Just-in-time (JIT) – “точно і вчасно”, який охоплює проектування виробів, вибір постачальників, забезпечення якості, планування, облік виробництва і його контроль з використанням спеціальних бирок-ярликів Kanban (“вчасно зробити”). Одна з найважливіших особливостей методу “точно і вчасно” пов’язана з мінімалізацією страхових і міжопераційних заділів за рахунок стабілізації поставок, а також забезпечення резерву виробничих потужностей. Метод Just in time не суперечить MRP і MRPII і часто пропонується в сучасних системах як одна з форм організації виробництва.
Метод ОРТ (Optimised Production Technology) — оптимізаційна технологія виробництва — було створено в Ізраїлі в 70-х роках XXст. На його базі було розроблено ряд програмних пакетів. Цей метод призначений для максимізації випуску продукції за скорочення обсягу запасів і виробничих витрат. У його основу покладено визначення дефіциту виробничих потужностей і матеріальних ресурсів і якнайточніший їх облік під час планування.
Концепція комп’ютеризованого інтегрованого виробництва (CIM – Computer Integrated Manufacturing) виникла на початку 80-х років минулого століття і пов’язана з інтеграцією гнучкого виробництва й систем управління ним та широким використанням MRP і MRPII-систем. З погляду них CIM припускає інтеграцію всіх підсистем: управління поставками, проектування і підготовки виробництва, планування і виробництва, управління виробничими ділянками й цехами, транспорно-складськими системами, забезпеченням, обладнанням, інструментом і оснащенням, якістю, збутом, фінансами і т. ін.
У 80-х роках у військовому відомстві США було розроблено методи CALS (Computer-aided Acquisition and Logistics Support) – комп’ютерна підтримка процесу поставок і логістики для підвищення ефективності управління і планування в процесі замовлень, розроблення, організації виробництва, поставки й експлуатації військової техніки. CALS довела свою ефективність і нині переноситься на цивільні галузі виробництва. Низка проектних рішень CALS стандартизується в міжнародній організації ISO і використовується в системах MRPII/ERP.
Отже, на 70-ті-80-ті роки XX ст. припадає другий етап у розвитку ІС, характерною особливістю якого є розроблення програмних продуктів відповідно до концепцій MRP/MRPII і централізованої обробки інформації в середовищі відповідних СУБД. За цих умов бізнес-процеси мали внутрішню сфокусованість на традиційних виробничих структурах, сегментованих за відділами й виконуваними функціями. Інтеграція програмних і апаратних засобів означала розробку прикладних програм, які використовували той самий програмний код, виконуваний на єдиній апаратній платформі (на одній машині). Практично можливості апаратних засобів визначали розробку програмних систем. Тому на цьому етапі програмні системи, такі як MRP і MRPII, обмежувались вимогами до апаратури, підтримкою єдиної технічної платформи, мали ускладнені процедури супроводження і підтримки системи.
Орієнтація на двоспрямований вільний потік інформації між покупцем і виробником прийшла пізніше завдяки впровадженню відкритих технологій.
Системи планування матеріальних ресурсів МRР з'явилися приблизно на початку 70-х років XX ст. і переважали до кінця 70-х років. Інакше абревіатуру МRР розшифровують як планування матеріальних потреб. Системи планування матеріальних ресурсів реалізують основні положення концепції МRР, сформульованої APICS:
· виробнича діяльність описується як потік взаємопов'язаних замовлень;
· за виконання замовлення враховуються обмеження ресурсів;
· забезпечується мінімізація виробничих циклів і запасів;
· замовлення поставок і виробництва формуються на основі замовлень реалізації й виробничих графіків;
· прямування замовлень ув'язується з економічними показниками;
· виконання замовлення завершується до необхідног моменту.
Надалі розвиток концепції МRР здійснювався в напрямку розширення функціональних можливостей підприємства задля повнішого задоволення потреб клієнтів і зниження виробничих витрат. Це привело до того, що наприкінці 70-х років концепцію МRР було доповнено положеннями про формування виробничої програми в масштабах усього підприємства і контроль її виконання на рівні підрозділів.
Основна ідея цієї концепції – потреба вдосконалення функції планування матеріальних ресурсів, обумовлена в основному тим, що основна маса збоїв і затримок у процесі виробництва пов’язана з затримками й нерегулярними надходженнями матеріалів і комплектуючих виробів, внаслідок чого ефективність виробництва падає. Крім того, відсутність узгодженого плану поставок матеріальних цінностей з технологічним ланцюжком виготовлення продукції, а також порушення балансу поставок в багатьох випадках призводять, з одного боку, до накопичення надлишків матеріалів на підприємстві, а відтак – до замороження оборотних коштів на деякий період; з другого, не дають можливості вести моніторинг їхнього стану у виробництві й ефективно управляти цим процесом. Тому низкою зарубіжних недержавних організацій, серед яких провідне місце належить APICS, сформулювано ідеологію планування потреби в матеріалах, яку згодом було зведено в ранг стандарту для розроблення комп’ютерних програм класу MRP.
Варто зауважити, що це не юридичний чи державний стандарт, а, швидше, стандартна ідеологія управління, яка на теперішній час прийнята всіма зарубіжними виробниками програмного продукту і реалізована в усіх системах масштабу підприємства.
Реалізація системи, працюючої за цією ідеологією, являє собою комп’ютерну програму, яка дозволяє оптимально регулювати поставки матеріальних цінностей у виробничій процес, контролюючи при цьому запаси на складі та саму технологію виробництва. Основним завданням MRP-системи є забезпечення гарантії наявності необхідної кількості матеріалів і комплектуючих виробів у будь-який відрізок часу в рамках планового періоду й надання можливості зменшення постійних запасів, що водночас сприяє розвантаженню складів.
MRP-система – це комп’ютерна програма, працююча за алгоритмом, регламентованим MRP методологією.
У системі MRP поточний стан матеріалу визначається його статусом, який охоплює такі показники: наявність даного матеріалу на складі, наявність (відсутність) його резервування для інших цілей, наявність його в поточних замовленнях чи замовлення на нього лише планується, ціна, можливі затримки поставок, реквізити постачальників тощо. Отже, статус матеріалу однозначно описує ступінь готовності кожного матеріалу бути запущеним у виробничий процес.
Потреба в матеріалі в MRP-системі являє собою визначену його кількість за відповідною одиницею виміру, що відображає виниклу в деякий момент часу протягом планового періоду виробництва необхідність у замовленні даного матеріалу.
Розрізняють поняття “чистої потреби” в матеріалі, яка дорівнює кількості, що безпосередньо йде на виробництво, і “повної потреби”, під час обчислення якої враховується наявність страхового й зарезервованого запасів. Страховий запас, як відомо, необхідний для підтримання процесу виробництва в разі виникнення непередбачених затримок у поставках матеріалу. В ідеальному випадку, якщо механізм поставок вважати бездоганним, MRP-система не орієнтується на обов’язкову наявність страхового запасу, для підтримання якого необхідно відволікати відповідні кошти. Це одна з важливих особливостей концепції MRP, оскільки MRP-система має бути гнучкою стосовно зовнішніх чинників і вчасно вносити зміни до плану замовлень у разі непередбачених затримок поставок. Але щодо українських умов, коли затримка в процесах поставок є, швидше, правилом, аніж винятком, на практиці доцільно застосовувати планування з урахуванням страхового запасу, обсяги якого встановлюються для кожного конкретного випадку залежно від реальної ситуації з надходженням матеріалів.
Процес планування в MRP-системі містить функції автоматичного створення проектів замовлення на закупівлю матеріалів або внутрішнє виробництво необхідних комплектуючих, що значно підіймає ефективність виробництва. Основні переваги використання MRP-системи у виробництві такі:
· гарантована наявність необхідних матеріалів і комплектуючих виробів у виробництві, зменшення тимчасових затримок у їх доставці, а отже, забезпечення ритмічного випуску продукції;
· наскрізне планування і диспетчеризація виробництва за рахунок формування збалансованого за ресурсами плану;
· безперервний контроль витрат і собівартості продукції;
· упорядкування виробництва через контроль статусу кожного матеріалу, що дозволяє вести моніторинг його конвеєрного шляху, починаючи від формування замовлення на цей матеріал до його стану у вже зібраному готовому виробі. Завдяки цьому досягається повна вірогідність і ефективність виробничого обліку.
MRP-система забезпечує синхронну роботу виробничого циклу з доставкою матеріалів і створення кінцевого продукту без додаткових затримок. Вона прискорює доставку першочергових матеріалів і затримує передчасність надходження в такий спосіб, щоб усі матеріали й комплектуючі надходили у виробництво одночасно відповідно до технологічного ланцюжка.
Розглянемо детальніше роботу MRP-системи, яка, як і будь-який програмний продукт, містить вхідні дані та результати їх оброблення. Інформаційну модель цієї системи унаочнює рис. 3.16.
Рис. 3.16. Інформаційна модель MRP-системи
Масив опису стану матеріалів (ISF – Inventory Status File) є основним вхідним елементом MRP-системи. У ньому максимально повно відображена інформація про всі матеріали й комплектуючі вироби, необхідні для виробництва кінцевого продукту. У масиві має бути зазначено статус кожного матеріалу, його запаси, розташування на складі тощо.
Масив виробничої програми (MPS – Master Production Schedul) містить інформацію про обсяг виробництва й оптимізований графік розподілу часу для виробництва необхідної партії готової продукції на запланований період. Система передбачає створення спочатку пробної програми виробництва, яка згодом тестується на можливість її виконання за допомогою програми CRP (Capacity Reguirements Planning). Програма CRP визначає, чи достатньо виробничих ресурсів для виконання пробної програми виробництва.
У процесі роботи CRP-програми розробляється план розподілу виробничих потужностей для виконання кожного конкретного циклу виробництва протягом планового періоду. Також установлюється технологічний план послідовності виробничих операцій відповідно до пробної програми виробництва, визначається ступінь завантаження кожної виробничої одиниці на термін планування.
Якщо аналіз показує, що виробнича програма забезпечена ресурсами й може бути виконана, то вона автоматично набуває статусу основної та стає вхідним елементом MRP-системи. Така попередня перевірка необхідна для того, щоб уникнути неузгодженості між показниками забезпеченості програми виробництва необхідними матеріалами і графіком виникнення потреб у матеріалах, який формує MRP-система і в якій не передбачено механізму аналітичних розрахунків щодо забезпечення виробничої програми ресурсами.
У свою чергу, у разі браку ряду матеріалів або неможливості виконання плану замовлень, з погляду СRP-програми, MRP-система вказує на необхідність внести в неї корективи.
Масив складових елементів виробу (BMF – Bills of Material File) містить інформацію про матеріали, складальні одиниці, деталі, покупні комплектуючі вироби та їхню кількість, необхідну для виробництва кінцевого продукту. Поряд з описом структури кінцевого продукту масив містить повну інформацію з технології його виготовлення, тобто на яких операціях технологічного процесу, які елементи і в якій кількості використовуються під час складання виробу. Для масиву складових елементів виробу надзвичайно важливим є підтримання його в актуальному стані, тобто своєчасне внесення змін до масиву в разі змін у структурі чи технології виробництва.
Масиви-довідники містять інформацію про назви реквізитів (виробів, матеріалів і т.д.), розшифровку й детальний опис показників тощо.
Маючи необхідні вхідні дані, MRP-система виконує відповідні логічні кроки роботи, які подано на рис. 3.16 у вигляді п’яти взаємопов’язаних програмних модулів.
У другому модулі аналізуються і включаються в план окремим пунктом матеріали, не включені до виробничої програми, але наявні в поточних замовленнях.
Третій модуль на основі затвердженої програми виробництва й замовлень на матеріали та комплектуючі, що не входять до неї, визначає для кожного окремо взятого матеріалу чисту його потребу відповідно до переліку складових елементів кінцевого продукту.
Чиста потреба 
розраховується за такою формулою:
,
де Wсvh – план виробництва v -x виробів (складальних одиниць) на h -й період для с -го цеху;
Mjvco – норма витрат j -го матеріалу на v -й виріб в с -му цеху на о -й технологічній операції.
У четвертому модулі на основі чистої потреби та з урахуванням поточного статусу матеріалу для кожного періоду часу й кожного матеріалу обчислюється повна його потреба (Pjh):
Pjh = Hjh + Sjh + Zjh,
де Hjh – чиста потреба j -го матеріалу на h -й період;
Sjh – страховий запас у h -му періоді;
Zjh –зарезервований запас для h -го періоду.
При цьому повна потреба в матеріалах порівнюється з рівнем його запасу на складі; якщо рівень запасу знизився до відповідної межі так званої “точки замовлення матеріалу”, то автоматично створюється проект замовлення на поставку матеріалу.
Сутність методу автоматичного формулювання замовлення на поставку матеріалів відображено на рис. 3.17.
Рис. 3.17. Схема формування потреби в матеріалах за точкою замовлення
Точкою замовлення називається мінімальний рівень запасу матеріалу, який складається зі страхового й зарезервованого запасів та очікуваної середньої потреби в матеріалі в період відтворення запасу матеріалу. Відповідно до цього під час визначення точки замовлення необхідно враховувати страховий і зарезервований запаси, а також середньоденну потребу в матеріалі та кількість робочих днів на відтворення запасу матеріалу.
Отже, мінімальний рівень запасу, страховий і зарезервований запаси є основними параметрами управління під час планування потреби в матеріалах за точкою замовлення. Переваги такого методу полягають у тому, що мінімальний рівень запасу враховує стан витрат і поставок матеріалів, а відтак, запаси на зберігання матеріалів наближаються до оптимальних.
Поточний контроль складського запасу здійснюється під час кожного відпуску матеріалу перевіркою, чи не знизився рівень запасу матеріалу нижче мінімального рівня. Якщо це має місце, то створюється проект замовлення на поставку.
П’ятий модуль аналізує всі замовлення на матеріали й вибирає ті з них, які створені раніше поточного періоду планування, і в разі потреби вносить зміни, щоб запобігти передчасним поставками матеріалу.
Модуль формує певні зміни до наявних замовлень і у разі потреби створює нові для забезпечення оптимальної динаміки ходу виробничого процесу. Ці зміни автоматично модифікують масив “Опис стану матеріалу”, що, у свою чергу, веде до зміни статусу матеріалу й відображення реального стану забезпечення виробничої програми ресурсами.
Вихідні повідомлення MRP-системи:
1. План замовлень матеріалів (POS – Planned Order Schedule) містить кількісні показники на замовлення у відповідний період часу протягом терміну планування. Він є документом, що регламентує подальшу роботу відділу маркетингу з постачальниками, а також визначає забезпечення виробничої програми для внутрішнього виробництва комплектуючих, якщо таке має місце.
2. Зміни до плану замовлень (CPO – Changes in planned orders) містять уточнені (модифіковані) показники до раніше спланованих замовлень. Окремі замовлення можуть бути затримані або перенесені на інший період.
Крім того, формуються деякі додаткові звіти, мета яких — звернути уваги менеджерів на ті проміжки часу, коли потрібен додатковий контроль за поточними замовленнями, а також щоб вчасно сповістити про можливі системні помилки, виниклі у роботі програми. Такими є виконавчий звіт, звіт про забезпеченість “вузькі місця”, звіт про прогнози.
3. Виконавчий звіт (PR — Performance Report) є основним індикатором конкретної роботи MRP-системи, який сповіщає користувача про виниклі у процесі планування критичні ситуації, наприклад про повну витрату страхового запасу з окремих матеріалів, а також про всі системні помилки в процесі роботи MRP-системи.
4. Звіт про забезпеченість “вузькі місця” (ER – Exception Report) призначений для завчасного інформування користувача про передбачені запізнювання в замовленні матеріалів, надлишки матеріалів на складі тощо.
5. Звіт про прогнози (PR – Planning Report) містить інформацію про можливу майбутню зміну обсягів і характеристик випущеної продукції; на його підставі можна сформувати довгострокові планові потреби в матеріалах.
Як видно з зазначеного, MRP-система являє собою алгоритм оптимального управління замовленнями на готову продукцію, її виробництвом і запасами матеріальних ресурсів; дозволяє оптимально завантажувати виробничі потужності та при цьому закуповувати стільки матеріалів, скільки необхідно для виконання поточного плану, і саме стільки, скільки можливо опрацювати за відповідний цикл виробництва. Власне методологія MRP є практичною реалізацією двох принципів – Justintime (вчасно замовити) і KanBan (вчасно зробити). Зрозуміло, що ідеальна реалізація методології MRP у реальному житті майже неможлива, наприклад через можливість зриву термінів поставок з різноманітних причин і внаслідок цього – зриву виробництва продукції. Тому в життєвих ситуаціях застосування MRP-системи на кожний випадок, передбачений заздалегідь, визначається страховим запасом матеріалів і комплектуючих (safety stock), обсяг якого встановлюється компетентним керівництвом компанії.
На перших порах упровадження концепції MRP здавалося, що всі основні проблеми виробництва й забезпечення матеріалами вирішені, тому активно почали створюватися і продаватися комп’ютерні програми, що реалізують найпростіші принципи цієї ідеології. Але з часом у процесі подальшого аналізування існуючої у світовому бізнесі ситуації з’ясувалося, що все більша частка в собівартості продукції належить витратам, безпосередньо не пов’язаним з процесом і обсягом виробництва. У зв’язку з конкуренцією, що зростає з року в рік, відчутно збільшуються витрати на рекламу й маркетинг, зменшується ЖЦ виробів, кінцеві споживачі продукції стають усе вимогливішими до показників “якість – вартість”. Усе це потребує перегляду поглядів на планування бізнесової діяльності. Відтепер потрібно намагатися робити те, що продається, а не навпаки — виробляти що завгодно й намагатися потім продати. Отже, маркетинг і планування продажів мають бути безпосередньо пов’язані з плануванням виробництва.
З метою вдосконалення системи планування за методологією MRP наприкінці 70-х років XX ст. відомі американські вчені О. Уайт і Д. Плосл запропонували ідею відтворення замкнутого циклу (closed loop) у MRP-системах уведенням для розгляду ширшого спектру факторів і функцій під час проведення планування. До базових функцій планування виробничих потужностей і планування потреб у матеріальних ресурсах було запропоновано додати низку додаткових, а саме: проведення контролю відповідності кількості виробленої продукції кількості використаних у процесі збирання матеріалів і комплектуючих і виявлення відхилень між нормативними й фактичними даними; складання регулярних звітів про затримки замовлень, про обсяги й динаміку продажів продукції, про постачальників тощо.
Основна особливість модифікації системи на основі замкнутого циклу полягала в тому, що створені в процесі її роботи звіти аналізуються і враховуються на подальших етапах планування, змінюючи, в разі потреби, програму виробництва, а отже, і план замовлень, і в такий спосіб здійснюючи зворотний зв’язок у системі, що забезпечує гнучкість планування стосовно зовнішніх факторів, таких як рівень попиту, стан справ у постачальників і т. ін.
Надалі вдосконалення системи MRP із замкнутим циклом привело до її модифікації, що згодом отримала назву MRPII (Manufacturin Resouce Planning) – планування ресурсів виробництва, в якій римську цифру “II” використано для ідентифікації нової системи, що має ідентичну абревіатуру з попередньою системою. Вона охоплює планування всіх ресурсів виробничого підприємства, зокрема фінансових, кадрових, основних фондів і т.д.
У системі класу MRPII можна виокремити три базові блоки.
1. Формування основного плану на основі замовлення клієнтів і прогнозу попиту. Система охоплює процедури швидкої комп’ютерної перевірки можливості виконання. Це так зване “приблизне планування потужності” (Rough Cut Capacity Planning).
2. Планування потреб, тобто формування плану-графіка виготовлення партій комплектуючих одиниць власного виробництва і плану-графіка закупівлі матеріалів і комплектуючих у постачальників. При цьому визначається розмір замовлень та їх дати, а також розраховується завантаження ресурсів за допомогою процедури планування потужності (Capacity Planning).
3. Оперативне управління способом перевірки укомплектованості та запуску замовлень, керування ходом виробництва через механізми виробничих циклів, пріоритетів, розмірів замовлень; оперативний облік виконання операцій і замовлень, облік ресурсів на складах і всіх ділянках виробництва.
Крім того, система класу MRPII здатна адаптуватися до змін яких-небудь зовнішніх чи внутрішніх умов і сформувати відповідь на питання “що, якщо...”, тобто заздалегідь “програти” реальність, яка очікує підприємство в майбутньому, і вибрати кращий варіант дій.
Стандартна система MRPII містить опис 16 груп функцій системи організаційного управління: планування продажів й виробництва, управління попитом, складання плану виробництва, планування потреб у матеріалах, специфікації продуктів, управління складським господарством, планові поставки, управління цехом, планування виробничих потужностей, контроль входу/виходу, матеріально-технічне постачання, планування розподілу ресурсів, планування та контроль виробничих операцій управління фінансами, моделювання, оцінення результатів діяльності.
Подальший розвиток системи MRPII і накопичення досвіду моделювання виробничих і невиробничих процесів постійно уточнює функціональність цієї системи, поступово охоплюючи все більше її функцій. Вона має на меті інтеграцію всіх основних процесів, реалізованих підприємством, а саме: планування, постачання, запаси, виробництво, програми, контроль виконання плану, витрати, фінанси, основні засоби і т.д.
MRPII-система побудована в такий спосіб, що результати роботи кожного модуля аналізуються всією системою в цілому, що й забезпечує її гнучкість стосовно зовнішніх чинників. Саме ця властивість є визначальною для сучасних систем планування, оскільки основна маса виробників виготовляє продукцію на короткий ЖЦ, таку, що потребує регулярного оновлення й модернізації. У такому разі виникає потреба в програмних продуктах, які б на БД аналізу поточного попиту і становища на ринку в цілому дозволяли оптимізувати обсяги й характеристики випущеної продукції.
Для того щоб ПЗ відповідало класу MRPII, воно має виконувати певний обсяг необхідних функцій (процедур).
Розглянемо логіку роботи MRP-системи на конкретному прикладі. На рис. 3.18 наведено структурну схему планування ресурсів виробничого підприємства.
Рис. 3.18. Структурна схема планування ресурсів виробничого підприємства за методологією MRPІІ
1. Планування розвитку бізнесу.
Упорядкуванням плану діяльності підприємства визначаються місія підприємства, його ніша на ринку, оцінюються й визначаються прибутки, фінансова забезпеченість. Фактично підтверджується, що підприємство збирається зробити і продати, та оцінюється, які кошти треба інвестувати в розробку й розвиток продукту, щоб вийти на плановий рівень прибутку.
Вихідними елементами цього модуля є план діяльності підприємства (план виробництва виробів у натуральних одиницях) і бізнес-план. Під час визначення плану діяльності зважають на такі показники:
· залишок готових виробів на складі на початок планового періоду;
· необхідна кількість підтримувального запасу готових виробів на складі в той чи інший момент протягом періоду планування;
· прогнози продажів виробів на плановий період.
З погляду MRP-системи, план діяльності та бізнес-план не є незалежними, і щоразу в разі відновлення плану діяльності вносять зміни в бізнес-план.
2. Визначення необхідних матеріалів і комплектуючих.
На підставі плану виробництва MRP-система складає інвентарний список (Bill of materiall file) матеріалів і комплектуючих, потрібних для виробництва
