Інформаційні системи і технології на підприємствах

Гужва В. М. Інформаційні системи і технології на підприємствах 1. Основні поняття і проблеми інформаційних систем та інформа- ційних ресурсів організації 3 1.1. Система управління 3 1.2. Інформація і дані 7 1.3. Інформаційні ресурси організації 17 1.4. Інформаційні технології 18 1.5. Інформаційні системи 22 2. Сучасні підходи до розробки і впровадження інформаційних систем на підприємствах 28 2.1. Типова структура та склад інформаційних систем 28 2.2. Моделі життєвого циклу інформаційних систем підприємств та його основні етапи 36 2.3. Сучасні підходи до створення інформаційних систем на підприєм- ствах 44 2.4. CASE-технології — інструментарій підтримки життєвого циклу інформаційних систем 77 3. Сучасні засоби створення автоматизованих інформаційних технологій на підприємствах 80 3.1. Автоматизовані інформаційні технології, їх розвиток і класифі- кація 80 3.2. Автоматизоване робоче місце — засіб автоматизації роботи кінце- вого користувача на підприємстві 86 3.3. Сучасні засоби побудови комп’ютерних інформаційних технологій на підприємствах 90 4. Еволюція стратегічних моделей управління підприємствами в інформаційних системах 133 4.1. Системи планування матеріальних ресурсів (MRP) 133 4.2. Системи планування виробничих ресурсів (MRP II) 141 4.3. Системи планування ресурсів підприємства (ЕRP) 147 4.4. Системи планування ресурсів підприємства, синхронізованого зі споживачами (CSRP) 164 4.5. Розвинуті системи планування (APS) 170 4.6. Деякі особливості подальшого розвитку 174 5. Автоматизація управління проектами на підприємствах 177 5.1. Введення в управління проектами 177 5.2. Базові функціональні можливості автоматизованих систем управ- ління проектами 181 5.3. Загальні характеристики найбільш поширених автоматизованих систем управління проектами 183 5.4. Програмний продукт Primavera Project Planner (Р3) 189 6. Автоматизація процесів бізнес-планування інвестиційних проек- тів та стратегічної оцінки бізнесу на підприємствах 225 6.1. Загальна характеристика програмних продуктів для бізнес-плануван- ня інвестиційних проектів на підприємствах 225 6.2. Програмні продукти COMFAR та РROPSPIN 228 6.3. Програмні продукти фірми «Альт» 233 6.4. Програмний комплекс «Інвестор» 236 6.5. Програмні продукти «Project Expert» 240 6.6. Програмні продукти для стратегічної оцінки бізнесу на підприєм- ствах 256 7. Комп’ютерні системи підтримки прийняття рішень та викорис- тання їх на підприємствах 271 7.1. Еволюція інформаційних систем 271 7.2. Організаційно-технологічні основи прийняття рішень 275 7.3. Розвиток та впровадження систем підтримки прийняття рішень на підприємствах 281 8. Експертні системи та використання їх на підприємствах 296 8.1. Організаційні основи експертних систем 296 8.2. Склад і функції експертних систем 300 8.3. Приклади використання експертних систем на підприємствах 309 9. Інтегровані інформаційні системи управління підприємствами 311 9.1. Загальна характеристика сучасного стану інформаційних систем управління підприємствами 311 9.2. Базова концепція і основні функціональні компоненти інтегрованої інформаційної системи «Галактика» 319 9.3. Інформаційна система управління підприємством Miracle V 358 10. Інформаційні системи для мультинаціональних корпорацій (МНК) 381 10.1. Особливості інформаційних систем для МНК 381 10.2. Організаційна побудова корпорацій 384 10.3. Вимоги до проектування і впровадження інформаційних систем МНК 389 10.4. Інтегрована інформаційна система для управління МНК R/3 392 Література 398 ОСНОВНІ ПОНЯТТЯ І ПРОБЛЕМИ ІНФОРМАЦІЙНИХ СИСТЕМ ТА ІНФОРМАЦІЙНИХ РЕСУРСІВ ОРГАНІЗАЦІЇ На початку висвітлення питань, пов’язаних з управлінням інформаційними ресурсами, створенням інформаційних систем і технологій, слід визначитися в термінології, а також виділити основні проблеми у цій галузі і розглянути методи їх вирішення. Почати обговорення треба з терміна «система управління». При цьому увага зосереджуватиметься не на власне суб’єкті та об’єкті управління, рівнях управління, процесі прийняття рішення тощо. В даному разі метою є показати, де виникають інформаційний контур і інформаційна система і як на них впливають перелічені вище категорії. Зрештою, інформаційна система організації, її інформаційні ресурси є «нервовою системою» будь-якої системи управління. 1.1. СИСТЕМА УПРАВЛІННЯ Існування виробничих і економічних об’єктів визначається призначенням їх задовольняти ті чи інші потреби суспільства. Кожний такий об’єкт вступає у певні відносини з середовищем, що змінюється (з державними органами управління, з іншими об’єктами тощо), і складається з безлічі різних елементів, взаємодія яких і забезпечує його існування і виконання ним свого призначення. Надалі називатимемо будь-який такий об’єкт незалежно від його розмірів, форми власності, організаційно-правового статусу організацією. Організація — це стабільна формальна соціальна структура, яка отримує ресурси з навколишнього світу і переробляє їх у продукти своєї діяльності. У всіх організацій існують як спільні риси, так і індивідуальні особливості. Результатом взаємодії організації із середовищем є зміни різного гатунку, що виникають у ній. Ці зміни можуть мати дві крайні і протилежні одна щодо одної форми: деградацію (руйнування організації) і розвиток (ускладнення організації, накопичення в ній інформації). Крім того, можлива й тимчасова рівновага між організацією і середовищем, завдяки якій організація протягом певного часу залишається незмінною або випробовує лише оборотні зміни. Ці зміни в організації викликають необхідність управління, тобто таких цілеспрямованих дій, які забезпечать досягнення цілей, що стоять перед організацією. Управління дозволяє залежно від особливостей конкретних організацій і цілей управління стабілізувати їх, зберегти їхню якісну визначеність, підтримати динамічну рівновагу з середовищем, забезпечити вдосконалення організації і досягнення того або іншого корисного ефекту. Оскільки здійснення управління виділяється в особливу функ-цію, то на її виконанні спеціалізуються деякі елементи організацій. З огляду на це в межах організації можна виділити керо- ваний процес (об’єкт управління) і керуючу частину (орган управління). Сукупність їх визначається як система управ- ління. Керуюча частина певним чином впливає на керований процес. Щоб керуюча частина могла здійснювати управління, їй необхідно зіставляти фактичний стан керованого процесу з метою управління, у зв’язку з чим керований процес впливає на керуючу частину. Взаємовплив обох частин здійснюється як передача інформації. Таким чином, у системі управління завжди наявний замкнений інформаційний контур (рис. 1.1). Рис. 1.1. Інформаційний контур У межах інформаційного контуру існує і передається інформація про цілі управління, стан керованого процесу, про керуючі впливи. Інформаційний контур разом із засобами збору, передачі, опрацювання і зберігання інформації, а також з персоналом, що здійснює ці дії над інформацією, утворить інформаційну систему даної організації. Зазвичай будь-яка організація є складним комплексом, що об’єднує декілька об’єктів, котрі мають власні керовані процеси і керуючі частини. Тому для узгодженого функціонування комплексу вводиться додаткова керуюча частина, що координує дії інших керуючих частин і керованих процесів (своєрідних локальних систем управління), орієнтуючи їхню діяльність на виконання загальної мети комплексу. За більш складної побудови керованого процесу керуюча частина може мати багаторівневу структуру, що є характерним для більшості систем управління. Традиційно розрізняють три рівні управління в керуючій частині об’єкта: вищий, середній і нижчий. Кожний з них характеризується власним набором функцій, рівнем компетенції і потребує відповідної інформації. На вищому рівні управління реалізується стратегічне управління, визначаються місія організації, цілі управління, довгострокові плани, стратегія їх реалізації тощо. Середній рівень управління — це рівень тактичного управління. Тут складаються тактичні плани, здійснюється контроль за їх виконанням, відстежуються ресурси тощо. На нижчому рівні управління здійснюється оперативне управління, реалізуються об’ємно-календарні плани, оперативний контроль та облік (рис. 1.2). Рис. 1.2. Розподіл інформації за рівнями управління Певний поділ праці на кожному з рівнів управління зумовлює закріплення за окремими елементами керуючої частини організацій окремих функцій управління: планування, організації, обліку й контролю, мотивації, аналізу й регулювання. Ці функції реалізуються в різному обсязі на різних рівнях управління. Наявність функціональних елементів у керуючій частині організацій приводить до появи відповідних підсистем у їхніх інформаційних системах. Виділення планування або контролю як функцій управління породжує відповідні структурні елементи в організаційній структурі організації, а в межах його інформаційної системи — підсистему планування або контролю. Перша забезпечує формування бізнес-планів, планів виробництва, планів маркетингових досліджень, фінансових планів тощо, а друга — інформаційну підтрим¬ку контролю. Залежно від галузі економіки, де функціонує організація, і рів-ня керуючої частини в ієрархії органів управління інформація про зміни в об’єкті управління надходить у цю керуючу части- ну з різною частотою. У машинобудуванні директор підприємства отримує інформацію про виробництво кожного дня, начальник цеху — кожної зміни, майстер спостерігає за цим виробництвом. У будівництві частота отримання інформації про об’єкт управління є меншою. Якщо ж говорити про управління різними технологічними процесами, наприклад у нафтохімії, то там інформація надходить постійно. Таким чином, у різних галузях економіки, на різних рівнях управління дискретність отримання інформації про керований процес є різною. Тож і необхідність у коригуванні цього процесу з боку органу управління організації з огляду на її цілі виникатиме (або не виникатиме) відповідно до частоти отримання інформації. Акт цілеспрямованого впливу на керований процес, заснований на інформації про нього, з метою досягнення визначе- ної раніше мети називається прийняттям рішення, а процес формування рішення — процесом прийняття рішень. Відповідно до поділу праці в межах управління організацією рішення, що приймаються, стосуються тієї чи іншої функції управління. Забезпечення процесу прийняття рішень, а саме: надання потрібної інформації в потрібний час і в потрібному місці, — одне з основних завдань інформаційної системи організації. У зв’язку з цим характер рішень, процес їх прийняття, дискретність їх прийняття істотно впливають на функціонування інформаційної системи організації, а також технології, що застосовується, і навіть викликають необхідність формування нового класу інформаційних систем — комп’ютерних систем підтримки прийняття рішень (СППР). Розглянута вище система управління організації була визначена з позиції кібернетичного погляду на неї. Якщо вести мову про систему управління без певної абстракції, то інформаційна система організації, крім вказаного вище, визначається її організаційною структурою, персоналом, процедурами виконання зав¬дань, внутрішньою культурою організації тощо. Інакше кажучи, йдеться про те, яка інформація і яким чином зберігається в інформаційній системі, як вона опрацьовується, як функціонує ця система і т. ін. 1.2. ІНФОРМАЦІЯ І ДАНІ Фразу про те, що «інформація є критичним ресурсом, який, якщо добре ним розпорядитися, може дати велику конкурентну перевагу», можна почути або прочитати дуже часто. Однак кожен з нас постійно приймає якісь рішення в житті і знає, що за наявності можливості вибору варіанта рішення дуже важко знайти що-небудь справді корисне і відкинути все те, що не стосується справи. Так само важко здійснити це на виробництві або в бізнесі. Тому головне полягає в тому, чи хочемо ми спиратися в своїх рішеннях на випадкову, неповну інформацію, чи регулюватимемо процес надходження інформації і управлятимемо нею як одним із головних ресурсів — так, як управляємо сировиною, персоналом, продажем, фінансами і виробництвом. Проблема в тім, що на перший погляд управління інформацією є завданням менш важливим, а тому більш простим. Будь-яка діяльність людини базується на інформації. Інформація — це відомості про навколишній світ (об’єкти, явища, події, процеси тощо), які зменшують міру існуючої невизначеності, неповноти знань, відчужені від їх творця і які стали повідомленнями (вираженими певною мовою у вигляді знаків, у тому числі й записаними на матеріальному носії), які можна відтворювати шляхом передачі людьми усним, письмовим або іншим способом (за допомогою умовних сигналів, технічних та обчислювальних засобів і т. ін.). У цьому визначенні, побудованому на ряді визначень, для нас важливим є таке: • інформація — це не будь-які відомості, вона несе в собі щось нове, що зменшує існуючу невизначеність; • інформація існує поза її творцем, це — відчуження знання від її творця; знання — це відображення дійсності в мисленні людини; • інформація стала повідомленням, оскільки вона виражена певною мовою у вигляді знаків; • повідомлення може бути записане на матеріальному носії (повідомлення є формою передачі інформації); • повідомлення доступне для відтворення без участі автора; • інформація передається в канали суспільної комунікації. Виходячи з наведеного вище визначення, зазначимо, що для інформації характерними є такі атрибути (рис. 1.3): Рис. 1.3. Атрибути інформації У загальному випадку інформація, що надходить до організації, дозволяє: • визначати стратегічні, тактичні й оперативні цілі і завдання організації; • здійснювати контроль за поточним станом організації, її підрозділів і процесів у них; • ухвалювати обґрунтовані й своєчасні рішення; • координувати дії підрозділів для досягнення цілей. Відсутність інформації викликає інформаційну потребу як усвідомлене розуміння відмінності між індивідуальним знанням про предмет і знанням, накопиченим суспільством. Процес насичення виробництва і всіх сфер життя і діяльності людини інформацією називається інформатизацією. Поступово насичення при¬водить до утворення інформаційного суспільства. Це — таке суспільство, в якому забезпечені всі умови для задоволення інформаційних потреб усіх громадян, організацій і держави; більшість працюючих або зайняті виробництвом, зберіганням, переопрацюванням і реалізацією інформації, або не в змозі виконувати свої виробничі обов’язки без цих процесів. Це означає, що громадяни такого суспільства володіють певною інформаційною культурою — умінням працювати з інформацією і використовувати для її отримання, опрацювання і передачі комп’ютерні інформаційні технології. Наука, що займається вивченням властивостей інформації, питаннями її збору, зберігання, пошуку, переопрацювання, перетворення, поширення і використання в різних сферах діяльності людини, називається інформатикою. Коли ведуть мову про інформацію, то мають на увазі ряд її властивостей, а саме: 1) інформація достовірна, якщо вона не спотворює істинного стану справ; 2) інформація повна, якщо її достатньо для розуміння і прийняття рішень; 3) інформація чітка й зрозуміла, якщо вона виражена мовою, якою спілкуються ті, для кого вона призначена; 4) цінність, якість інформації — це міра розширення, розвит¬ку тезауруса (систематизованого словника понять з указанням смислових зв’язків між ними, тобто сукупності відомостей, що їх має у своєму розпорядженні користувач або система) сприймаючою стороною під час приймання та інтерпретації повідомлення, міра зниження стану невизначеності економічного суб’єкта, міра просування до мети; 5) адекватність інформації — це певний рівень відповідності, що створюється за допомогою отриманої інформації, образу реального об’єкта, процесу, явищу тощо. Рис. 1.4. Ілюстрація співвідношення понять «інформація» та «дані» Дані — це інформація, подана в формалізованому вигляді, прийнятому для опрацювання автоматичними засобами за можливої участі людини. Виходячи з наведених ви¬ще визначень, співвідношення понять «інформація» і «дані» може бути подане такою схе¬мою (рис. 1.4). Оскільки в подальшому мо¬ва йтиме про організації, що працюють у сфері економіки, нас передусім цікавить економічна інформація. Економічна інформація (ЕІ) — це сукупність відомостей про соціально-економічні процеси, що слугують для управління цими процесами і колективами людей у виробничій і невиробничій сферах. До характеристик економічної інформації слід віднести: • великі обсяги; • багаторазове повторення циклів її отримання і перетворення у встановлені часові періоди (місяць, квартал, рік і т. ін.); • різноманіття джерел і споживачів; • значна питома вага рутинних процедур під час її опрацювання. Економічну інформацію (ЕІ) можна класифікувати за цілою низкою ознак, а саме: а) за функціями управління: — планова; — нормативна; — облікова; — аналітична; б) за відношенням до об’єкта управління: в) за моментом виникнення: — первинна; — похідна; г) за сталістю змісту: — умовно-стала; — умовно-змінна; д) за характеризованими сутностями: — інформація про предмети (деталі, вироби, устаткування); — інформація про процеси (технологія опрацювання, технологія виготовлення); е) за елементами структури: — реквізит; — показник; — масив; — інформаційний потік; — інформаційна база. Розгляньмо дещо детальніше останню ознаку класифікації ЕІ, оскільки вона визначає характер можливих дій з цим видом інформації. З погляду логіки управління та розміщення інформації на носіях прийнято розрізняти логічну та фізичну структури інформації. Фізична структура визначається типом відповідного носія (папір, магнітна стрічка, магнітний диск тощо). Під логічною структурою інформації мають на увазі таку структуру, яка враховує погляд користувача (управління). Наведемо приклад — аналогію з процесу природного спілкування (обміну інформацією) між людьми. Серед елементів та рівнів такого спілкування традиційно виділяють такі: літера ? склад ? слово ? речення ? абзац тощо. В ЕІ подібна логічна структура може бути подана таким чином: Символ ? Реквізит ? Показник ? Масив ? Інформаційний потік ? Інформаційна база Під символом розуміють елементарний нетрадиційний сигнал інформації, яка не має самостійного значення (літера, цифра, знак). Реквізит — це найпростіша структурна одиниця інформації, яка є неподільною на смисловому рівні і яка відображає кількісну чи якісну характеристику сутностей (об’єктів, процесів тощо) предметної області. Реквізит-ознака (Rоз) містить якісну характеристику суттєвості, що дозволяє виділити (ідентифікувати) об’єкт із множини різ¬них об’єктів. Реквізит-основа (Rос) містить кількісну характеристику об’єкта, що визначає його стан. Поділ реквізитів на різновиди можна подати таким чином (рис. 1.5): Рис. 1.5. Поділ реквізитів на кількісні та якісні Розрізняють форму і значення реквізитів. Форма реквізиту виявляється в його назві (наприклад професія), а значення реквізиту «професія» — це назва конкретної професії (наприклад токар, фрезерувальник, технолог тощо). У процесі опрацювання інформації реквізити-основи і реквізити-ознаки мають різне призначення, а саме: над реквізитами-основами виконують арифметичні операції, над реквізитами-ознаками — логічні. Економічний показник — це інформаційна сукупність з мінімальним складом реквізитів-ознак (Rоз) і реквізитів-основ (Rос), достатнім для створення елементарного документа. Символічна формула для утворення показника має такий вигляд: . (1) Зазначимо, що характер дій над Rос і Rоз визначає і правила позначення їх за побудови відповідних показників, а саме: а) реквізити-основи позначаються великими літерами алфавіту (зазвичай латинського) і слугують основними елементами під час побудови формули; б) реквізити-ознаки групуючі позначаються маленькими літерами і слугують в якості індексів у формулах; в) реквізити-ознаки довідкові ніяким чином не позначаються і виконують роль, що випливає з їхньої назви (довідкові). Для ілюстрації наведених правил розгляньмо таку інформаційну сукупність, як «Відомість завантаження верстатів механічного цеху машинобудівного підприємства на місяць під виробничу програму». Реквізити, що можуть міститися у цьому доку¬менті, опишемо за допомогою такої таблиці: Таблиця 1.1 Реквізит Ідентифікатор Умовне позначення реквізиту в формулі Характеристика реквізиту Назва цеху NC — Якісний довідковий Код цеху КC с Якісний групуючий Назва місяця NMIS — Якісний довідковий Код місяця KMIS m Якісний групуючий Назва верстата NVER — Якісний довідковий Код верстата конкретного виду KVER i Якісний групуючий Кількість верстатів конкрет¬ного виду в цеху NKVER N Кількісний фактичний Ефективний місячний фонд роботи одного верстата конкретного виду EFOND F Кількісний плановий Трудомісткість місячної виробничої програми цеху в розрізі конкретного виду верстатів TRUD T кількісний плановий Коефіцієнт завантаження конкретного виду верстатів KZAV K кількісний розрахун¬ковий Виходячи з наведеної таблиці та враховуючи наведені вище правила, перелічимо деякі показники: Nicm — кількість верстатів і-го виду в с-му цехові в т-му місяці; Fiсm — ефективний фонд роботи одного верстата і-го виду в с-му цехові в т-му місяці; Тiсm — трудомісткість виробничої програми с-го цеху в т-му місяці в розрізі і-го виду верстатів; Kiсm = Тiсm / (Fiсm • Nicm) — коефіцієнт завантаження і-го виду верстатів в с-му цеху під виробничу програму т-го місяця. Процес перетворення економічної інформації у відповідні дані можна подати таким чином (рис. 1.6): Рис. 1.6. Схема перетворення інформації в дані Під класифікацією розуміють поділ множини об’єктів на час-тини за їхньою подібністю чи розбіжністю згідно з прийнятими методами. Існує два методи класифікації, а саме: а) ієрархічний; б) фасетний. Ієрархічний метод класифікації — це послідовний поділ множини (об’єктів) на підлеглі класифікаційні групування. Множину, яка класифікується, поділяють на підпорядковані підмножини спочатку за певною ознакою (основою поділу) на великі групування, потім кожну з них — на ряд наступних групувань, які в свою чергу поділяють на дрібніші, поступово конкретизуючи об’єкт класифікації. Між цими групуваннями встановлюються відношення підпорядкованості (ієрархії) (рис. 1.7). Рис. 1.7. Ієрархічна схема класифікації Фасетний метод класифікації — це паралельний поділ множини об’єктів на незалежні класифікаційні групування. При цьому множина об’єктів, що характеризується певним набором однакових для всіх об’єктів ознак (фасет), значення яких відповідають конкретним виразам зазначених ознак, може поділятися багаторазово і незалежно. Фасетний метод класифікації є однорівневим, оскільки вхідна множина об’єктів ділиться на підмножини відповідно до значень ознак окремих фасет (рис. 1.8). Рис. 1.8. Фасетна класифікації Під кодуванням розуміють процес створення кодів (набору цифр, букв та цифр і букв) та присвоєння їх підмножинам об’єк-тів, отриманих у ході класифікації. Розрізняють два види методів кодування: а) реєстраційний; б) класифікаційний. До реєстраційних належать порядковий та серійно-порядко-вий методи, до класифікаційних — послідовний і паралельний. Порядковий метод кодування — це створення коду із чисел натурального ряду і його присвоєння. Найбільш простий і повний, однозначний. Серійно-порядковий метод кодування — це створення коду із чисел натурального ряду із закріпленням окремих серій чи діапазонів цих чисел за об’єктами класифікації з однаковими ознаками і його присвоєння. Використовується для двоознакових номенклатур. Послідовний метод кодування — це створення коду класифікаційного групування і (чи) об’єкта класифікації з використанням кодів послідовно розміщених підпорядкованих групувань, отриманих за ієрархічного методу класифікації, і його присвоєння. Паралельний метод кодування — це створення коду класифікаційного групування і (чи) об’єкта класифікації з використанням кодів незалежних групувань, отриманих за фасетного методу класифікації, і його присвоєння. Результати класифікації і кодування фіксуються в документах, що отримали назву класифікаторів. Класифікатор являє собою документ, у якому відображено систематизований перелік назв і кодів класифікаційних групувань або об’єктів класифікації. Під час розв’язання економічних задач слід забезпечити їх порівнянність. Здійснюється це створенням єдиних систем групувань, побудованих за єдиними класифікаційними ознаками, — Єдиної системи класифікації та кодування техніко-економічної інформації (ЕСКК ТЕІ). Залежно від рівня затвердження та сфери застосування класифікатори ТЕІ поділяють на: а) міжнародні; б) загальнодержавні; в) галузеві; в) класифікатори об’єднань, підприємств та установ. Прикладом загальнодержавного класифікатора може слугувати класифікатор продукції (рис. 1.9): Рис. 1.9. Державний класифікатор продукції. Структура коду У процесі перетворення інформації для управлінських цілей часто використовують такий метод наочної інтерпретації, як моделювання елементів інформації. Моделювання дозволяє умов¬но відобразити реальні об’єкти і процеси за допомогою мовних, графічних та інших засобів, аби полегшити сприймання та аналіз їх людиною. Моделі допомагають абстрагуватися від деталей та усвідомити суть проблеми. Процес зберігання даних про економічний об’єкт з певними їхніми зв’язками в сучасних комп’ютерах вимагає застосування відповідних моделей. Основним місцем зберігання економічної інформації в інформаційних системах є бази даних (БД). Вид конкретної бази даних залежить від типу відношень між об’єк-тами інформації; що зберігається в ній. Основними видами (моделями) таких відношень є: а) «один до одного» (1 : 1); прикладом може бути відношення «номенклатурний номер матеріалу — назва матеріалу»; б) «один до багатьох» (1 : N); прикладом є відношення «код виробу — професія працівника, що бере участь у його виготовленні»; в) «багато до багатьох» (M : N); приклад — відношення «код технологічної операції — табельний номер працівника, що її виконує». Залежно від того, які типи відношень використовуються у побудові конкретної бази даних, останні прийнято поділяти на: а) ієрархічні (реалізуються відношення 1 : 1, 1 : N); б) сіткові (реалізуються відношення 1 : 1, 1 : N та N : M); в) реляційні (на основі таблиць відношень). 1.3. ІНФОРМАЦІЙНІ РЕСУРСИ ОРГАНІЗАЦІЇ Словник С. І. Ожегова визначає поняття «ресурс» як запас, джерело чого-небудь. Розглядаючи народне господарство країни, будь-яку галузь, підприємство, тобто організацію будь-якого масш¬табу, ми можемо виділити матеріальні, природні, трудові, фінансові, енергетичні ресурси. Ці поняття є економічними категоріями. Зараз є розуміння того, що для нормального функціонування організації будь-якого масштабу недостатньо мати для виробницт¬ва тільки необхідні матеріальні, фінансові і людські ресурси, — необхідно знати, що з цим усім треба робити, мати інформацію про технології. Тому інформація, інформаційні ресурси нині розглядаються як окрема економічна категорія. Якщо пригадати те визначення інформації, яке було дано вище, то інформаційні ресурси можна визначити як увесь обсяг інформації, що є в інформаційній системі. Для країни це будуть інформаційні ресурси країни, для організації якогось рівня — інформаційні ресурси організації. Що є джерелами формування інформаційних ресурсів організації? Будь-яка організація існує в певному зовнішньому середовищі. Ця ж організація породжує своє внутрішнє середовище, яке формується сукупністю структурних підрозділів підприємства і працюючих там людей, технологічними, соціальними, економічними та іншими відносинами між ними. Залежно від джерела виникнення в межах організації розрізняють внутрішню і зовнішню інформацію, що становить її інформаційні ресурси. Інформація внутрішнього середовища, як правило, точна, повно відображає фінансово-господарський стан. Її опрацювання часто може здійснюватися за допомогою стандартних формалізованих процедур. Зовнішнє середовище — це економічні й політичні суб’єкти, що діють за межами підприємства, і відносини з ними, тобто економічні, соціальні, технологічні, політичні та інші відносини підприємства з клієнтами, постачальниками, посередниками, конкурентами, державними органами тощо. Інформація із зовнішнього середовища, яка є часто приблизною, неточною, неповною, суперечливою, має ймовірнісний характер і через те вимагає нестандартних процедур опрацювання. Які будь-яким ресурсом, інформаційними ресурсами можна управляти. Хоча ще не розроблена методологія кількісної та якісної оцінки інформаційних ресурсів, а також прогнозування потреби в них, однак на рівні організації можна і треба вивчати інформаційні потреби, планувати й управляти інформаційними ресурсами. Управління інформаційними ресурсами означає: 1) оцінку інформаційних потреб на кожному рівні і в межах кожної функції управління; 2) вивчення документообігу організації, його раціоналізацію; стандартизацію типів і форм документів; типізацію інформації і даних; 3) подолання проблеми несумісності типів даних; 4) створення системи управління даними тощо. 1.4. ІНФОРМАЦІЙНІ ТЕХНОЛОГІЇ Під технологією мають на увазі сукупність методів обробки, виготовлення, змінення стану, властивостей, форми сировини, матеріалу або напівфабрикату, здійснюваних у процесі виробництва продукції. Це — уміння щось робити досконало. Коли ми ведемо мову про інформаційну технологію, як матеріал виступає інформація. Як продукт — також інформація. Але це якісно нова інформація про стан об’єкта, процесу або явища. Технологія представлена методами і способами роботи з інформацією персоналу і технічних пристроїв. Інформаційна технологія — це система методів і способів збору, передачі, накопичення, опрацювання, зберігання, подання і використання інформації. Таблиця 1.2 ЗІСТАВЛЕННЯ ОСНОВНИХ КОМПОНЕНТІВ Компоненти технологій для виробництва продуктів матеріальних інформаційних Підготовка сировини і матеріалів Збір даних або первинної інформації Виробництво матеріального продукту Опрацювання даних і отримання результатної інформації Збут вироблених продуктів споживачам Передача результатної інформації для прийняття на її основі рішень У технологічному плані підприємство може розглядатися як сукупність інформаційних, людських і технологічних ресурсів і методів їх взаємодії, організованих для досягнення певної мети (табл. 1.2). Кожна з перелічених у визначенні інформаційної технології фаз перетворення і використання інформації реалізується за допомогою специфічної технології. У цьому розумінні ми можемо вести мову про інформаційну технологію як сукупність технологій — технології збору інформації, технології передачі інформації тощо. Інформаційні технології реалізуються в автоматизованому і традиційному (паперовому) видах. Обсяг автоматизації, тип і характер використання технічних засобів залежать від характеру конкретної технології. Автоматизація — це заміна діяльності людини роботою машин і механізмів. Міра автоматизації може мінятися і в широких межах — від систем, у яких процес управління повністю здійснюється людиною, до таких, де він реалізується автоматично. Коли необхідна автоматизація? Автоматизація управління, а отже, й автоматизація інформаційної системи та автоматизація технологій, необхідні в таких випадках: а) фізіологічні та психологічні можливості людини для управління даним процесом є недостатніми; б) система управління знаходиться в середовищі, небезпечному для життя і здоров’я людини; в) участь людини в управлінні процесом вимагає від неї дуже високої кваліфікації; г) процес, яким треба управляти, переживає критичну або аварійну ситуацію. Автоматизована інформаційна технологія передбачає існування комплексу відповідних технічних засобів, що забезпечують реалізацію інформаційного процесу, і системи управління цим комплексом технічних засобів (як правило, це програмні засоби й організаційно-методичне забезпечення, що пов’язує дії персоналу і технічних засобів у єдиний технологічний процес). Оскільки істотну частину технічних засобів для реалізації інформаційних технологій становлять засоби комп’ютерної техніки, то часто під інформаційними технологіями, особливо під новими інформаційними технологіями (НІТ), мають на увазі комп’ютерні інформаційні технології (хоча поняття «інформаційна технологія» стосується будь-якого перетворення інформації, в тому числі й на паперовій основі). Нова інформаційна технологія (комп’ютерна інформаційна технологія) — це інформаційна технологія з «дружнім» інтерфейсом роботи користувача, що використовує персональні комп’ютери і телекомунікаційні засоби. Інструментарієм нової інформаційної технології є один або декілька взаємопов’язаних програмних продуктів для певного типу комп’ютера, технологія роботи в якому дозволяє досягти поставленої користувачем мети (табл. 1.3). Таблиця 1.3 ОСНОВНІ ХАРАКТЕРИСТИКИ НОВИХ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ Методологія Основна ознака Результат Принципово нові засоби опрацювання інформації «Вбудування» в технологію управління Нова технологія комунікацій Цілісні технологічні системи Інтеграція функцій фахів¬ців і менеджерів Нова технологія опрацювання інформації Цілеспрямовані створення, передача, зберігання і відображення інформації Облік закономірностей соціального середовища Нова технологія прий-няття управлінських рішень Таким чином, автоматизована інформаційна технологія складається з технічних пристроїв, найчастіше — комп’ютерів, комунікаційної техніки, засобів організаційної техніки, програмного забезпечення, організаційно-методичних матеріалів, персоналу, об’єднаних у технологічний ланцюжок. Цей ланцюжок забезпечує збір, передачу, накопичення, зберігання, опрацювання, використання і поширення інформації. Якщо розглядати весь життєвий цикл інформаційної системи, то під автоматизованими інформаційними технологіями розуміють сукупність методологій і технологій проектування інформаційних систем, базових програмних, апаратних і комунікаційних платформ, що забезпечують весь життєвий цикл інформаційних систем і їх окремих компонентів від проектування до утилізації. Мета будь-якої інформаційної технології — отримати потрібну інформацію необхідної якості на заданому носії. При цьому існують обмеження на вартість опрацювання даних, трудоміст¬кість процесів використання інформаційного ресурсу, надійність і оперативність процесу опрацювання інформації, якість інформації, що отримується. (Питання створення інформаційних технологій на підприємствах детальніше розглянуті в розд. 3) 1.4.1. Класифікація інформаційних технологій Можливі різні схеми класифікації інформаційних технологій. В основу кожної з них покладено певні класифікаційні ознаки. Перша ознака класифікації — наявність чи відсутність автоматизації. Зазвичай мова йде про традиційні й автоматизовані технології. Прийнято розрізняти забезпечувальні і функціональні інформаційні технології. Забезпечувальні технології можуть використовуватися як інструментарій у різних предметних галузях для вирішення різних задач. Вони можуть бути класифіковані відносно класів задач, які вирішуються. Зазвичай ці технології виконуються на різних комп’ютерах і в різних програмних середовищах. Основне завдання — поєднання цих технологій у єдиній інформаційній системі. Під функціональними технологіями слід розуміти сукупність забезпечувальних технологій для автоматизації певної задачі чи функції. Наступна класифікаційна ознака — це тип інформації, що опрацьовується. Умовна класифікація комп’ютерних інформаційних технологій залежно від типу інформації, що опрацьовується, наведена в табл. 1.4. Таблиця 1.4 КЛАСИФІКАЦІЯ КОМП’ЮТЕРНИХ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ Види інформації, що опрацьовується Дані Текст Графіка Знання Об’єкти реального світу Види інформа-ційних технологій СУБД, алгоритмічні мови, таб¬личні про-цесори Текстові процесори і гіпер-текст Графічні процесори Експертні системи Засоби мультимедіа ? ? ? ? ? Інтегровані пакети: поєднання різних технологій Залежно від типу користувацького інтерфейсу (тобто від того, як користувач технології взаємодіє з комп’ютером) прийнято виділяти такі технології: пакети, діалогові, мережні. В першому випадку користувач отримує тільки результати роботи технології, в решті — взаємодіє з нею на індивідуальному комп’ютері чи комп’ютері, який підключено до мережі електронних обчислювальних машин (ЕОМ). За ступенем автоматизації функцій людини в процесі управління розрізняють такі технології: електронне опрацювання даних, автоматизація функцій управління, підтримка прийняття рішень, експертна підтримка. 1.5. ІНФОРМАЦІЙНІ СИСТЕМИ 1.5.1. Загальні положення Інформаційні системи, як і інформація і інформаційні технології, існували з моменту появи суспільства, оскільки на будь-якій стадії його розвитку є потреба в управлінні. А для управління потрібна систематизована, заздалегідь підготовлена інформація. Таким чином, місія інформаційних систем — це виробництво інформації, що її потребує організація для забезпечення ефективного управління всіма своїми ресурсами, створення інформаційного і технічного середовища для здійснення управління організацією. Як співвідносяться інформаційна технологія і інформаційна система? Інформаційна технологія реалізується в межах інформаційної системи. Інформаційна технологія — це спосіб перетворення інформації. В інформаційній системі можуть використовуватися багато таких технологій. Ця система є середовищем для реалізації технології. Проте інформаційна технологія ширша від інформаційної системи. Вона може існувати поза нею. Наприклад, інформаційна технологія опрацювання текстів, використана для написання цього підручника, не є частиною інформаційної системи і реалізується поза такою системою. Розглядаючи систему управління, ми виокремили три рівні управління: стратегічний, тактичний та оперативний. Кожний з цих рівнів управління має свої завдання, при вирішенні яких виникає потреба в інформації, тобто інформаційні запити до інформаційної системи. Ці запити звернені до відповідної інформації в інформаційній системі. Інформаційні технології дозволяють опрацювати запити і, використовуючи наявну інформацію, сформулювати відповідь на ці запити. Таким чином, на кожному рівні управління з’являється інформація, що служить основою для прийняття відповідних рішень. Щоб розібратися в роботі інформаційної системи, потрібно зрозуміти суть проблем, які вона вирішує, а також організаційні процеси, в які вона включена. У кожній з таких систем організується і ведеться робота в таких напрямках: • виявлення інформаційних потреб; • добір джерел інформації; • збір інформації; • введення інформації із зовнішніх або внутрішніх джерел; • опрацювання інформації, оцінка її повноти і значущості і подання її в зручному вигляді; • виведення інформації для надання її споживачам або передачі в іншу систему; • організація використання інформації для оцінки тенденцій, розробки прогнозів, оцінки альтернатив рішень і дій, вироблення стратегії; • організація зворотного зв’язку з інформації, переопрацьованої людьми даної організації, корекція вхідної інформації. Усе це здійснюється за допомогою тих або інших інформаційних технологій у межах інформаційної системи організації. Для будь-якої організації істотним є встановлення регламенту функціонування інформаційної системи — від виявлення інформаційних потреб до використання інформації. Йдеться про типізацію завдань, що вирішуються в організації, встановлення періодичності отримання, опрацювання і використання інформації, стандартизацію вхідних і вихідних документів, стандартизацію процедур опрацювання інформації. Запити до інформаційної системи і, отже, процедури формування відповіді на них можна поділити на рутинні й нерутинні. Рутинні процедури характеризуються заданістю початкової і вихідної інформації, а також визначеністю алгоритму отримання останньої з першої. Виділення рутинних задач і процедур опрацювання інформації дозволяє їх формалізувати, а надалі й автоматизувати. Питання лише в тому, чи спроможні інформаційні технології, що використовуються в організації, забезпечити інфраструктуру для цього. Якщо рутинні повсякденні дії автоматизовані, то набагато простіше опрацьовувати нерутинні випадкові запити. В основі будь-якої системи лежить процес. В основі інформаційної системи — процес виробництва інформації. У цьому розумінні ми можемо розглядати інформаційну систему як систему управління, де цей процес є об’єктом управління. І як у будь-якій системі управління, існують органи управління інформаційною системою (табл. 1.5). Таблиця 1.5 ІНФОРМАЦІЙНА СИСТЕМА ЯК ОБ’ЄКТ УПРАВЛІННЯ Об’єкт управління Оперативний рівень управління Тактичний рівень управління Стратегічний рівень управління Інформаційна система організації Персонал інформаційної системи, менеджери підрозділів і функціональних служб Корпоративна рада директорів і головні менедже¬ри інформаційної системи Інформаційні тех¬нології, що застосовуються Персонал інформаційної системи Головні менедже¬ри інформаційної системи Нині склалася думка про інформаційну систему як таку, що реалізується за допомогою комп’ютерної техніки. Проте інформаційні системи, як і інформаційні технології, можуть функціонувати і із застосуванням технічних засобів, і без такого застосування. Це — питання економічної доцільності. Зростання обсягів інформації в інформаційній системі організацій, потреба в прискоренні й більш складних способах її переопрацювання зумовлюють необхідність автоматизації роботи інформаційної системи, тобто автоматизації опрацювання інформації. У неавтоматизованій інформаційній системі всі дії з інформацією і рішення здійснює людина. Автоматизація процесів опрацювання інформації приводить до появи в межах алгоритмів опрацювання правил вирішення задач. Це сприятиме переростанню «чистої» інформаційної системи в інформаційну систему управління. У межах останньої частково реалізовані й функції людини з прийняття рішень. Автоматизована інформаційна система управління організацією є взаємопов’язаною сукупністю даних, обладнання, програмних засобів, персоналу, стандартів процедур, призначених для збору, опрацювання, розподілу, зберігання, видачі (надання) інформації відповідно до вимог, що випливають з діяльності організації. Як правило, це система для підтримки прийняття рішень і виробництва інформаційних продуктів, що використовує комп’ю¬терну інформаційну технологію, і персонал, який взаємодіє з комп’ютерами і телекомунікаціями. Технологія роботи в комп’ютеризованій інформаційній системі повинна бути доступна для розуміння фахівцем некомп’ютерної галузі і може бути успішно використана для контролю процесів професійної діяльності та управління ними. 1.5.2. Класифікація автоматизованих інформаційних систем Автоматизовані інформаційні системи (АІС) різноманітні і можуть бути класифіковані за низкою ознак (рис. 1.10). Оскільки схема на рис. 1.10 дає чітке уявлення про класифікацію систем за сферою функціонування об’єкта управління, розгляньмо наступні ознаки. За видами процесів управління АІС поділяються на: АІС управління технологічними процесами — це людино-машинні системи, що забезпечують управління технологічними пристроями, верстатами, автоматичними лініями. АІС управління організаційно-технологічними процесами являють собою багаторівневі системи, що поєднують у собі АІС управління технологічними процесами та АІС управління підприємствами. Рис. 1.10. Класифікація автоматизованих інформаційних систем АІС організаційного управління об’єктом обслуговують виробничо-господарські, соціально-економічні функціональні процеси, що реалізуються на всіх рівнях управління економікою, зокрема: — банківські АІС; — АІС фондового ринку; — фінансові АІС; — страхові АІС; — податкові АІС; — АІС митної служби; — статистичні АІС; — АІС промислових підприємств і організацій. АІС наукових досліджень забезпечують високу якість та ефективність міжгалузевих розрахунків і наукових дослідів. За методичну базу таких систем правлять економіко-математичні методи, за технічну — різноманітна обчислювальна техніка і технічні засоби для проведення експериментальних робіт з моделювання. Як організаційно-технологічні системи, так і системи наукових досліджень можуть включати в себе системи автоматизованого проектування робіт (САПР). Навчальні АІС набувають значного поширення у підготовці спеціалістів системи освіти, у підготовці та підвищенні кваліфікації працівників різних галузей. Відповідно до третьої ознаки класифікації виділяють галузеві, територіальні та міжгалузеві АІС, які водночас є системами організаційного управління, але вже більш високого рівня ієрархії. Галузеві АІС функціонують у сферах промислового та агропромислового комплексів, у будівництві, на транспорті, вирішуючи завдання інформаційного обслуговування апарату управління відповідних відомств. Територіальні АІС призначені для управління адміністратив-но-територіальними районами. Діяльність територіальних систем спрямована на якісне виконання управлінських функцій у регіоні, формування звітності, видачу оперативних відомостей місцевим державним і господарським органам. Міжгалузеві АІС є спеціалізованими системами функціональних органів управління національною економікою (банківські, фінансові, статистичні та ін.). Маючи в своєму складі потужні обчислювальні комплекси, міжгалузеві багаторівневі АІС забезпечують розробку економічних і господарських прогнозів, державного бюджету, здійснюють контроль результатів та регулювання діяльності всіх ланцюгів, а також контроль наявності і розподілу ресурсів. СУЧАСНІ ПІДХОДИ ДО РОЗРОБКИ І ВПРОВАДЖЕННЯ ІНФОРМАЦІЙНИХ СИСТЕМ НА ПІДПРИЄМСТВАХ 2.1. ТИПОВА СТРУКТУРА ТА СКЛАД ІНФОРМАЦІЙНИХ СИСТЕМ Практично всі розглянуті різновиди інформаційних систем незалежно від сфери застосування їх включають один і той самий набір компонентів (рис. 2.1): • функціональні компоненти; • компоненти системи опрацювання даних; • організаційні компоненти. Рис. 2.1. Декомпозиція інформаційної системи При цьому під функцією управління слід розуміти спеціальний постійний обов’язок однієї або декількох осіб, виконання якого забезпечує досягнення певного ділового результату. Під функціональними компонентами мають на увазі систему функцій управління — повний набір (комплекс) взаємопов’язаних у часі й просторі робіт з управління, необхідних для досягнення поставлених перед підприємством цілей. Справді, будь-яка складна управлінська функція розчленовується на ряд більш дрібних задач і зрештою доводиться до безпосереднього виконавця. Саме від того, як буде виконане те або інше завдання окремим працівником, залежить успіх вирішення кінцевих завдань підприємства загалом. Таким чином, уся складна сукупність управлінських впливів повинна мати своїм кінцевим результатом доведення загальних завдань, що стоять перед підприємством, до кожного конкретного виконавця незалежно від його службового становища. Природно, наведені положення підкреслюють не тільки індивідуальний, а й груповий характер функції управління, а діловий (практичний) результат утворюється не епізодично, а постійно. Увесь процес управління підприємством зводиться або до лінійного (наприклад адміністративного) управління підприємством чи його структурним підрозділом, або до функціонального (матеріально-технічне забезпечення, бухгалтерський облік тощо) управління. Тому декомпозиція інформаційної системи за функціональною ознакою (рис.2.1) містить у собі виділення її окремих частин, які мають назву функціональних підсистем (ПС) (функціональні модулі, бізнес-додатки), що реалізують систему функцій управління. Функціональною ознакою зумовлюється призначення підсистеми, тобто те, для якої сфери діяльності вона призначена і які основні цілі, завдання і функції вона виконує. Функціональні підсистеми істотно залежать від предметної області (сфери застосування) інформаційних систем. На рис. 2.2 наведена функціональна декомпозиція інформаційних систем промислового підприємства. Залежно від складності конкретного підприємства кількість функціональних підсистем коливається від 10 до 50 найменувань. Специфічні особли¬вості кожної функціональної підсистеми містяться в так званих «функціональних задачах» підсистеми. Зазвичай управлінський персонал або пов’язує це поняття з досягненням певних цілей функції управління, або визначає його як роботу, що повинна Рис. 2.2. Узагальнена функціональна декомпозиція інформаційної системи промислового підприємства бути виконана певним способом у певний період. Однак із появою нових інформаційних технологій поняття «задача» розглядається ширше — як закінчений комплекс опрацювання інформації, що забезпечує або видачу прямих керуючих впливів на хід виробничого процесу, або видачу необхідної інформації для прийняття рішень управлінським персоналом. Таким чином, задача повинна розглядатися як елемент системи управління, а не як елемент системи опрацювання даних. Вибір складу функціональних задач функціональних підсистем управління здійснюється звичайно з урахуванням основних фаз управління: планування; обліку, контролю й аналізу; регулювання (виконання). Планування — це управлінська функція, що забезпечує формування планів, відповідно до яких буде організоване функціонування об’єкта управління. Традиційно виділяють перспективне (5-10 років), річне (1 рік) і оперативне (доба, тиждень, декада, місяць) планування. Облік, контроль і аналіз — функції, що забезпечують одержання даних про стан керованої системи за певний проміжок часу, визначення факту та причини відхилення фактичного стану об’єкта управління від його планованого стану, а також виявлення розмірів цього відхилення. Облік ведеться за показниками плану в обраному діапазоні планування (оперативний, середньостроковий і т.ін.). Регулювання (виконання) — це функція, що забезпечує порівняння планованих та фактичних показників функціонування об’єкта управління і реалізацію необхідних керуючих впливів за наявності відхилень від запланованих у заданому діапазоні (відрізку). Відповідно до виділених функціональних підсистем та з урахуванням вимог управління і визначається склад задач функціональних підсистем. Наприклад, інформаційна система управління персоналом підприємства може містити такі функціональні підсистеми: • планування чисельності персоналу підприємства; • розрахунок фонду заробітної плати персоналу; • планування та організація навчання персоналу; • управління кадровими переміщеннями; • статистичний облік і звітність; • довідки за запитом. Вибір та обґрунтування складу функціональних задач є одним із найважливіших елементів створення інформаційних систем. Аналіз функціональних задач показує, що практична реалізація їх в умовах використання інформаційних систем є різноманітною. Одна й та сама задача може бути вирішена (реалізована) різними математичними методами, моделями й алгоритмами (рис. 2.1). Іноді цю функціональну підсистему називають підсистемою математичного забезпечення. Серед багатьох варіантів реалізації є, як правило, найкращий, зумовлений можливостями обчислювальної системи і системи опрацювання даних у цілому. У сучасних системах автоматизації проектування інформаційних систем цей компонент входить до складу так званих банків моделей і алгоритмів, з яких під час розробки інформаційних систем вибираються найефективніші для конкретного об’єкта управління. 2.1.1. Компоненти системи опрацювання даних Основна функція системи опрацювання даних — це реалізація таких типових операцій опрацювання даних (рис. 2.3): • збір, реєстрація і перенесення інформації на машинні носії; • передача інформації в місця її збереження й опрацювання; • уведення інформації в ЕОМ, контроль уведення та компонування інформації в пам’яті комп’ютера; • створення і ведення внутрішньомашинної інформаційної ба-зи; • опрацювання інформації на ЕОМ (накопичення, сортування, коригування, вибірка, арифметичне і логічне опрацювання) для вирішення функціональних задач системи (підсистеми) управління об’єктом; • вивід інформації у вигляді табуляграм, відеограм, сигналів для прямого управління технологічними процесами, інформації для зв’язку з іншими системами; • організація, управління (адміністрування) обчислювальним процесом (планування, облік, контроль, аналіз реалізації ходу обчислень у локальних і глобальних обчислювальних мережах). Система опрацювання даних (СОД) призначена для інформаційного обслуговування фахівців різних органів управління підприємства, що приймають управлінські рішення. Виділення типових операцій опрацювання даних дозволило створити спеціалізовані програмно-апаратні комплекси, що їх реалізують (різні периферійні пристрої, оргтехніку, стандартні набори програм, у тому числі пакети прикладних програм — ППП, за допомогою яких реалізують функціональні задачі ІС). Конфігурація апаратних комплексів утворює так звану топологію обчислювальних систем. Рис. 2.3. Принципова схема системи опрацювання даних (СОД) СОД можуть працювати в трьох основних режимах: пакетному, інтерактивному та в реальному масштабі часу. Для пакетного режиму характерним є те, що результати опрацювання видаються користувачам після виконання так званих пакетів завдань. Недоліком такого режиму є відокремлення користувача від процесу опрацювання інформації, що перешкоджає оперативності прийняття управлінських рішень. За інтерактивного (діалогового) режиму роботи відбувається обмін повідомленнями між користувачем і системою. Користувач обмірковує результати запиту і під час прийняття рішення вводить інформацію у систему для подальшого опрацювання. Режим реального часу використовується для управління швидкоплинними процесами. Практично всі системи опрацювання даних інформаційних систем незалежно від сфери застосування їх включають один і той самий набір складових (компонентів), що називаються видами забезпечення (рис. 2.1). Прийнято виділяти інформаційне, програмне, технічне, правове, лінгвістичне забезпечення. Інформаційне забезпечення — це сукупність методів і засобів розміщення й організації інформації, що включають у себе системи класифікації і кодування, уніфіковані системи документації, раціоналізації документообігу та форми документів, методів створення внутрішньомашинної інформаційної бази інформаційної системи. Від якості розробленого інформаційного забезпечення значною мірою залежить достовірність і якість прийнятих управлінських рішень. Програмне забезпечення — сукупність програмних засобів для створення та експлуатації СОД засобами обчислювальної техніки. До складу програмного забезпечення входять базові (загальносистемні) та прикладні (спеціальні) програмні продукти. Базові програмні засоби служать для автоматизації взаємодії людини і комп’ютера, організації типових процедур опрацювання даних, контролю і діагностики функціонування технічних засобів СОД. Прикладне програмне забезпечення являє собою сукупність програмних продуктів, призначених для автоматизації вирішення функціональних задач інформаційної системи. Вони можуть бути розроблені як універсальні засоби (текстові редактори, електронні таблиці, системи управління базами даних) і як спеціалізовані, тобто такі, що реалізують функціональні підсистеми (бізнес-процеси) об’єктів різної природи (економічні, інженерні, технічні тощо). Технічне забезпечення являє собою комплекс технічних засобів, що застосовуються для функціонування системи опрацювання даних, і містить у собі пристрої, за допомогою яких виконуються типові операції опрацювання даних як поза ЕОМ (перифе¬рійні технічні засоби збору, реєстрації, первинного опрацювання інформації, оргтехніка різного призначення, засоби телекомунікації і зв’язку), так і на ЕОМ різних класів. Правове забезпечення — це сукупність правових норм, що регламентують створення і функціонування інформаційної системи. Правове забезпечення розробки інформаційної системи включає нормативні акти договірних взаємовідносин між замовником і розроблювачем ІС, правове регулювання відхилень. Правове забезпечення функціонування СОД включає: умови надання юридичної чинності документам, отриманим із застосуванням обчислювальної техніки; права, обов’язки і відповідальність персоналу, в тому числі за своєчасність і точність опрацювання інформації; правила користування інформацією і порядок вирішення суперечок щодо її достовірності. Лінгвістичне забезпечення — це сукупність мовних засобів, що використовуються на різних стадіях створення та експлуатації СОД для підвищення ефективності розробки й забезпечення спілкування людини і ЕОМ. 2.1.2. Організаційні компоненти інформаційної системи Виділення організаційних компонентів у самостійний напрям зумовлюється особливою значущістю людського чинника (персоналу) в успішному функціонуванні ІС. Перш ніж упроваджувати дорогу систему опрацювання даних, має бути проведена величезна робота з упорядкування та удосконалення організаційної структури об’єкта; в противному разі ефективність ІС буде низькою. Головна проблема при цьому полягає у виявленні ступеня відповідності існуючих функцій управління та організаційної структури, що реалізує ці функції і стратегію розвитку підприємства. Засобами досягнення цілі — удосконалення організаційних структур — є різні методи моделювання. Під організаційними компонентами ІС мають на увазі сукупність методів і засобів, що дозволяють удосконалити організаційну структуру об’єктів і управлінські функції, які виконуються структурними підрозділами; визначити штатний розклад і чисельний склад кожного структурного підрозділу; розробити посадові інструкції персоналу управління в умовах функціонування СОД. Впровадження інформаційних систем сприяє удосконаленню організаційних структур, оскільки припускає визначення розрахункової, тобто науково обґрунтованої, чисельності апарату управління по структурних підрозділах з обов’язковим вирішенням таких, зокрема, проблем: • достовірне віднесення кожного працівника до відповідного структурного підрозділу (відділу, бюро і т.ін.); • встановлення чітких службових обов’язків кожного працівника в межах підрозділу, в якому він працює. При цьому визначення кола обов’язків припускає, що обов’язки працівників, що обіймають ту або іншу посаду, не залежать від конкретної особи, яка їх виконує, і сукупність спільних обов’язків повинна гарантувати їхню несуперечливість і можливість досягнення загального результату; • визначення нормального завантаження працівника його роботою протягом дня і на календарний період; • розробка посадових інструкцій персоналу в умовах функціонування СОД, зокрема в умовах аварійних ситуацій. 2.2. МОДЕЛІ ЖИТТЄВОГО ЦИКЛУ ІНФОРМАЦІЙНИХ СИСТЕМ ПІДПРИЄМСТВ ТА ЙОГО ОСНОВНІ ЕТАПИ Опис життєвого циклу інформаційної системи передбачає оперування такими поняттями: • процес — ланцюжок робіт, що послідовно виконуються; • етапи — послідовні відрізки часу, упродовж якого виконуються роботи. Протягом етапу можуть виконуватися роботи, що належать до різних процесів. В основі діяльності із створення й використання автоматизованої інформаційної системи управління підприємством (АІСУП) лежить поняття її життєвого циклу (ЖЦ). ЖЦ є моделлю створення і використання АІСУП, що відоб¬ражає різні її стани, починаючи з моменту виникнення необхідності в даному виробі і закінчуючи моментом його повного виходу з використання всіх, без винятку, користувачів. Традиційно виділяють такі основні етапи ЖЦ АІСУП: • аналіз вимог; • проектування; • програмування / впровадження; • тестування і налагодження; • експлуатація і супровід. ЖЦ утворюється відповідно до принципу низхідного проектування і зазвичай має ітераційний характер: реалізовані етапи, починаючи з найперших, циклічно повторюються відповідно до змін вимог і зовнішніх умов, введення обмежень тощо. На кожному етапі ЖЦ породжується певний набір документів і технічних рішень, при цьому для кожного етапу початковими є документи і рішення, отримані на попередньому етапі. Кожний етап завершується верифікацією породжених документів і рішень з метою перевірки відповідності їх вихідним. Існуючі моделі ЖЦ визначають порядок виконання етапів у ході розробки, а також критерії переходу від етапу до етапу. Відповід¬но до цього найбільше поширення отримали такі три моделі ЖЦ: 1. Каскадна модель (70—80-ті роки) передбачає перехід до наступного етапу після повного завершення робіт на попередньому етапі і характеризується чітким поділом даних і процесів їх опрацювання (рис. 2.4). 2. Поетапна модель з проміжним контролем (80—85-ті роки) — ітераційна модель розробки з циклами зворотного зв’язку між етапами. Перевага такої моделі — в тому, що міжетапні коригування забезпечують меншу трудомісткість порівняно з каскадною моделлю; з іншого боку, час життя кожного з етапів розтягується на весь період розробки. 3. Спіральна модель (86—90-ті роки) — загострює увагу на початкових етапах ЖЦ: аналізі вимог, проектуванні специфікацій, попередньому й детальному проектуванні. На цих етапах перевіряється і обгрунтовується реалізовуваність технічних рішень створенням прототипів. Кожний виток спіралі відповідає поетапній моделі створення фрагмента або версії системи, на ньому уточнюються цілі й характеристики проекту, визначається його якість, плануються роботи наступного витка спіралі. Таким чином поглиблюються і послідовно конкретизуються деталі проекту і в результаті обирається обґрунтований варіант, який доводиться до реалізації (рис. 2.5). Рис. 2.5. Спіральна модель життєвого циклу АІСУП Фахівці відзначають такі переваги спіральної моделі: • накопичення і повторне використання програмних засобів, моделей і прототипів; • орієнтація на розвиток і модифікацію системи в ході її прое-к¬тування; • аналіз ризику і витрат у процесі проектування. Розгляньмо детальніше основні етапи ЖЦ. 1) Аналіз вимог. Аналіз вимог є першою фазою розробки АІСУП, на якій вимоги замовника уточнюються, формалізуються і документуються. Фактично на цьому етапі дається відповідь на питання: «Що повинна робити майбутня система?» Саме тут лежить ключ до успіху всього проекту. У практиці створення великих систем відомо чимало прикладів невдалої реалізації проекту саме через неповноту і нечіткість визначення системних вимог. Перелік вимог до АІСУП повинен включати: • сукупність умов, за яких передбачається експлуатувати майбутню систему (апаратні й програмні ресурси, що надаються системі; зовнішні умови її функціонування; склад працівників і робіт, що мають до неї відношення); • опис функцій, що їх має виконувати система; • обмеження в процесі розробки (директивні терміни завершення окремих етапів, наявні ресурси, організаційні процедури і заходи, що забезпечують захист інформації). Метою аналізу є перетворення загальних, нечітких знань про вимоги до майбутньої системи в точні (по можливості) визначення. Результатом етапу повинна бути модель вимог до системи (іншими словами — системний проект), що визначає: архітектуру системи, її функції, зовнішні умови, поділ функцій між апаратною і програмною частинами (ПЧ); інтерфейси і поділ функцій між людиною і системою; вимоги до програмних та інформаційних компонентів ПЧ, необхідні апаратні ресурси, вимоги до бази даних, фізичні характеристики компонент ПЧ, їхні інтерфейси. Модель вимог повинна включати: • повну функціональну модель вимог до майбутньої системи з глибиною опрацювання до рівня кожної операції кожної посадової особи; • специфікації операцій нижнього рівня; • пакет звітів і документів по функціональній моделі, що включає характеристику об’єкта моделювання, перелік підсистем, вимоги до способів і засобів зв’язку для інформаційного обміну між компонентами, вимоги до характеристик взаємозв’яз¬ків системи із суміжними системами, вимоги до функцій системи; • концептуальну інформаційну модель вимог; • пакет звітів і документів з інформаційної моделі; • архітектуру системи з прив’язкою до концептуальної інформаційної моделі; • пропозиції щодо організації структури для підтримки системи. Таким чином, модель вимог містить функціональну, інформаційну і, можливо, подійну (у разі, якщо цільова система є системою реального часу) моделі, що забезпечує ряд переваг порівняно з традиційною моделлю: 1. Для традиційної розробки характерним є здійснення початкових етапів кустарними неформалізованими способами. Тому замовники і користувачі уперше можуть побачити систему після того, як вона вже значною мірою реалізована. Природно, ця система відрізнятиметься від тієї, якої вони очікували. Тож далі матимуть місце ще декілька ітерацій її розробки або модифікації, що вимагає додаткових (і значних) витрат грошей і часу. Ключ до розв’язання цієї проблеми і дає модель вимог, що дозволяє: • описати, «побачити» і скоригувати майбутню систему до того, як вона буде реалізована фізично; • зменшити витрати на розробку і впровадження системи; • оцінити розробку за часом і результатами; • досягнути взаєморозуміння між усіма учасниками роботи (замовниками, користувачами, розробниками, програмістами); • поліпшити якість системи, що розробляється, а саме: виконати її функціональну декомпозицію і спроектувати оптимальну структуру інтегрованої бази даних. 2. Модель вимог повністю незалежна і відокремлена від конкретних розробників, не вимагає супроводження її творцями і може бути безболісно передана іншим особам. Понад те, якщо з яких-небудь причин підприємство не готове до реалізації системи на основі моделі вимог, вона може бути залишена «на полиці» доти, доки в ній не виникне потреба. 3. Модель вимог може бути використана для самостійної розробки або коригування вже реалізованих на її основі програмних засобів силами програмістів відділу автоматизації підприємства. 4. Модель вимог може використовуватися для автоматизованого і швидкого навчання нових працівників конкретного напряму діяльності підприємства, оскільки її технологія міститься в моделі. Етап аналізу вимог є найважливішим серед усіх етапів ЖЦ. Він істотно впливає на всі подальші етапи, залишаючись водночас найменш вивченим і зрозумілим процесом. На цьому етапі, по-перше, потрібно зрозуміти, щo саме треба зробити, а по-друге, задокументувати це, бо якщо вимоги не зафіксовані і не зроблені доступними для учасників проекту, то вони начебто й не існують. При цьому мова, якою формулюються вимоги, повинна бути досить простою і зрозумілою замовникові. 2) Розробка технічного завдання. Після побудови моделі, що містить вимоги до майбутньої системи, на її основі розробляється технічне завдання зі створення системи, що включає в себе: • вимоги до автоматизованих робочих місць, їхніх складу і структури, а також до способів і схем інформаційної взаємодії між ними; • розробку вимог до технічних засобів; • визначення вимог до програмних засобів; • розробку топології, складу і структури локальної обчислювальної мережі; • вимоги до етапів і термінів виконання робіт. 3) Проектування. Етап проектування дає відповідь на питання: «Як (яким чином) система задовольнятиме вимоги, що ставляться до неї?. Завданням цього етапу є дослідження структури системи і логічних взаємозв’язків її елементів, причому тут не зачіпаються питання, по¬в’язані з реалізацією на конкретній платформі. Проектування розглядається як ітераційний процес отримання логічної моделі системи разом зі строго сформульованими цілями, поставленими перед нею, а також написання специфікацій фізичної системи, що задовольняє ці вимоги. Цей етап звичайно поділяють на два підетапи: а) проектування архітектури системи, що включає розробку структури та інтерфейсів компонентів, узгодження функцій і технічних вимог до компонентів, методів і стандартів проектування; б) детальне проектування, яке передбачає розробку специфікацій кожного компонента, інтерфейсів між компонентами, розробку вимог до тестів і плану інтеграції компонентів. Іншими словами, проектування є етапом ЖЦ, на якому визначається, як слід реалізовувати вимоги до АІСУП, що породжені й зафіксовані на етапі аналізу. В результаті повинна бути побудована модель реалізації, що демонструє, як система задовольнятиме пред’явлені до неї вимоги (без технічних подробиць). Фактич¬но модель реалізації є розвитком і уточненням моделі вимог, а саме проектування є мостом між аналізом і реалізацією. 4) Реалізація (програмування / адаптація). На етапі реалізації здійснюється створення системи як комплексу програмно-апаратних засобів, починаючи з проектування і створення телекомунікаційної інфраструктури і завершуючи розробкою та інсталяцією додатків. Зараз існує обширна література, в якій досить докладно розглянуті всі ці процеси, включаючи сучасні методи генерації коду прикладних систем, що використовуються. Тому в цьому підручникові питання реалізації не розглядається. 5) Тестування і налагодження. Коректність АІСУП є її найважливішою властивістю і, без сумніву, головним предметом турботи розробників. У ідеальному випадку під коректністю АІСУП мають на увазі відсутність у ній помилок. Однак для більшості складних програмних продуктів досягти цього неможливо — «у кожній програмі міститься принаймні одна помилка». Тому під «коректним» зазвичай розуміють програмний продукт, що працює відповідно до пред’явлених до нього вимог, іншими словами — продукт, для якого поки ще не знайдені такі умови, в яких він виявиться непрацездатним. Встановлення коректності є головною метою етапу життєвого циклу, що розглядається. Треба зазначити, що етап тестування і налагодження — один із найбільш трудомістких, стомлюючих і непередбачуваних етапів розробки АІСУП. У середньому за роз-робки традиційними методами цей етап займає від 1/2 до 1/3 всього часу розробки. З іншого боку, тестування і налагодження являють собою серйозну проблему: у деяких випадках тестуван-ня і налагодження програми вимагають в декілька разів більше часу, ніж безпосередньо програмування. Тестування — це набір процедур і дій, призначених для де-монстрації коректної роботи АІСУП у заданих режимах і зовніш-ніх умовах. Мета тестування — виявити наявність помилок або переконливо продемонструвати їх відсутність, що можливо лише в окремих тривіальних випадках. Важливо розрізнювати тестування і супутнє поняття «налагодження». Налагодження — це набір процедур і дій, що починаються з виявлення самого факту наявності помилки і закінчуються встановленням точного місця, характеру цієї помилки і способів її усунення. Найважливішим і найчастіше застосовуваним на практиці є метод детермінованого тестування. При цьому як еталони тестів використовуються конкретні початкові дані, що складаються з взаємопов’язаних вхідних і результуючих величин і правильних послідовностей їх опрацювання. У процесі тестування із задани-ми початковими величинами треба встановити відповідність ре-зультатів їх опрацювання еталонним величинам. Для складних систем потрібна велика кількість тестів, і виникає проблема оцін-ки їх необхідної кількості й використання методів їх скорочення. Тому тестування (як і будь-який інший вид діяльності) доцільно планувати. План тестування повинен містити: • формулювання цілей тестування; • критерії якості тестування, що дозволяють оцінити його результати; • стратегію проведення тестування, що забезпечує досягнен-ня заданих критеріїв якості; • потреби в ресурсах для досягнення заданого критерію якос-ті за обраної стратегії. ? Автоматизація тестування і налагодження Система автоматизації тестування і налагодження (САТН) яв-ляє собою складний комплекс алгоритмічних і програмних засо-бів, призначених для автоматизації аналізу АІСУП, тестування, налагодження й оцінок її якості, і дозволяє полегшити модифіка-цію компонент АІСУП, забезпечити виявлення помилок на ран-ніх стадіях налагодження, підвищити процент помилок, що авто-матично виявляються. 6) Експлуатація і супроводження. Основними завданнями етапу експлуатації і супроводжен-ня є такі: • забезпечення стійкості роботи системи і збереження інфор-мації — адміністрування; • своєчасна модернізація і ремонт окремих елементів — тех-ніч¬на підтримка; • адаптація можливостей системи, що експлуатується, до по-точних потреб бізнесу підприємства — розвиток системи. Ці роботи необхідно включати в оперативний план інформа-тизації підприємства, який повинен формуватися обов’язково з дотриманням усіх умов стратегічного плану. В іншому випадку в межах існуючої системи можуть з’явитися фрагменти, які в майбутньому зроблять ефективну експлуатацію системи неможливою. Зараз за рубежем стало загальноприйнятим передавати функ¬ції технічної підтримки і частково адміністрування постачальникам системи або системним інтеграторам. Ця практика одержала назву «аутсорсинг». Часто в межах аутсорсингу стороннім підприємствам передаються й такі функції, як створення і підтримка резервних сховищ даних і центрів виконання критичних бізнес-додатків, які задіюються у разі стихійного лиха або інших особливих умов. Особливу увагу на етапі експлуатації і супроводу потрібно приділити питанням навчання персоналу і, відповідно, плану-ванню інвестицій у цей процес. 2.3. СУЧАСНІ ПІДХОДИ ДО СТВОРЕННЯ ІНФОРМАЦІЙНИХ СИСТЕМ НА ПІДПРИЄМСТВАХ Головна особливість індустрії АІСУП полягає в концентрації складності на початкових етапах ЖЦ (аналіз та проектування) за відносно невисокої складності та трудомісткості наступних етапів. Більш того, невирішені питання та помилки, що мали місце під час аналізу та проектування, породжують на подальших етапах важкі, часто нерозв’язні проблеми і, зрештою, можуть позбавити успіху. Залежно від того, яким чином виконуються аналіз і проекту-вання, прийнято виділяти такі методи створення АІСУП: а) структурно-орієнтовані; б) об’єктно-орієнтовані; в) процесно-орієнтовані. 2.3.1. Структурно-орієнтований підхід 2.3.1.1. Структурні методи аналізу Структурним аналізом називають метод дослідження систе-ми, який починається із загального огляду її і потім деталізуєть-ся, набуваючи ієрархічної структури з дедалі більшим числом рі-в¬нів. Таким методам притаманне: 1) розбиття на рівні абстракції з обмеженням числа елементів на кожному з рівнів (зазвичай від 3 до 7, при цьому верхня межа відповідає можливостям людського мозку сприймати певну кіль-кість взаємопов’язаних об’єктів, а нижня вибрана з міркувань здорового глузду); 2) обмежений контекст, що включає лише істотні на кожному рівні деталі; 3) використання суворих формальних правил запису; 4) послідовне наближення до кінцевого результату. Методи структурного аналізу дозволяють подолати складність великих систем розчленуванням їх на частини («чорні скриньки») та ієрархічної організації цих «чорних скриньок». Це є першим принципом структурного аналізу. Перевага використання «чорних скриньок» полягає в тому, що їхньому користувачеві не потрібно знати, як вони працюють, — треба знати лише його входи й виходи, а також його призначення (тобто функцію, що її він виконує). У навколишньому світі «чорні скриньки» трапляються у великій кількості: магнітофон і телевізор на побутовому рівні, підприємство з позицій клієнта тощо. Проілюструємо переваги систем, складених з них, на прикладі музичного центру. • Конструювання системи «чорних скриньок» істотно спро-щується. Набагато легше розробити магнітофон або програвач, якщо не дбати про створення вбудованого підсилювального бло-ку. • Полегшується тестування таких систем. Якщо з’являється поганий звук однієї з колонок, можна поміняти колонки місцями. Якщо несправність перемістилася з колонкою, то саме вона під-лягає ремонту; якщо ні, тоді проблема — в підсилювачі, магні-тофоні або місцях їх поєднання. • Є можливість простого реконфігурування системи «чорних скриньок». Якщо колонка несправна, то можна віддати її в ремонтну майстерню і продовжувати слухати записи в моноре-жимі. • Полегшується доступність для розуміння і освоєння. Можна стати фахівцем з магнітофонів без поглиблених знань про колонки. • Підвищується зручність при модифікації. Можна придбати колонки більш високої якості і більш потужний підсилювач, але це зовсім не означає, що потрібен програвач великих розмірів. Таким чином, першим кроком спрощення складної системи є її поділ на «чорні скриньки» (принцип «розділяй і володарюй» — принцип розв’язання важких проблем розбиттям їх на безліч не-залежних задач, легких для розуміння і вирішення), при цьому цей поділ повинен задовольняти такі критерії: а) кожна «чорна скринька» має реалізовувати одну єдину фун-кцію системи; б) функція кожної «чорної скриньки» повинна бути легко зро-зумілою незалежно від складності її реалізації (наприклад, у сис-темі управління ракетою може бути «чорна скринька» для розра-хунку місця її приземлення: незважаючи на складність алго-ритму, функція «чорної скриньки» є очевидною — розрахунок точки приземлення); в) зв’язок між «чорними скриньками» повинен вводитися тільки за наявності зв’язку між відповідними функціями системи (наприклад, у бухгалтерії одна «чорна скринька» необхідна для розрахунку загальної заробітної плати службовця, а інша — для розрахунку податків; необхідний зв’язок між цими «чорними скриньками»: розмір заробітної плати потрібен для розрахунку податків); г) зв’язки між «чорними скриньками» мають бути якомога простішими для забезпечення незалежності між ними. Другою важливою ідеєю, що лежить в основі структурних ме-тодів, є ідея ієрархії. Для розуміння складної системи недостат-ньо розбити її на частини, треба ці частини організувати певним чином, а саме — як ієрархічні структури. Всі складні системи Всесвіту — галактики, зоряні системи, планети, молекули, атоми, елементарні частки — організовані в ієрархію. Створюючи склад¬ні системи, людина також йде за природою. Будь-яка організація має директора, заступників із напрямів, ієрархію керівників підрозділів, рядових службовців. Таким чином, другий принцип струк¬турного аналізу (принцип ієрархічного упорядкування) на доповнення до того, що легше розуміти проблему, коли вона розбита на частини, декларує, що упорядкування цих частин також є істотним для розуміння проблеми. Останнє різко підвищується за організації її частин у деревоподібні ієрархічні структури, тобто система може бути зрозумілою і побудованою по рівнях, кожен з яких додає нові деталі. Нарешті, третій принцип: структурні методи широко вико-ристовують графічні нотації, що також полегшують розуміння складних систем. Відомо, що «одна картинка варта тисячі слів». Дотримання вказаних принципів необхідне під час організації робіт на початкових етапах ЖЦ незалежно від типу системи, що розробляється, і методологій, що використовуються при цьому. Керівництво всіма принципами в комплексі дозволяє на більш ранніх стадіях розробки зрозуміти, щo являтиме собою система, яка створюється, виявити промахи і недоробки, що, в свою чергу, полегшить роботи на подальших етапах ЖЦ і знизить вартість розробки. Для цілей структурного аналізу традиційно використовують три групи засобів, які показують: • функції, що їх система повинна виконувати; • відношення між даними; • поведінку системи залежно від часу (аспекти реального ча-су). Серед різноманіття графічних нотацій, що використовуються для вирішення перелічених задач, у методологіях структурного аналізу найчастіше й ефективно застосовуються такі: 1) DFD (Data Flow Diagrams) — діаграми потоків даних разом зі словниками даних і специфікаціями процесів (міні-специфікаціями); 2) ERD (Entity—Relationship Diagrams) — діаграми «суть—зв’язок»; 3) STD (State Transition Diagrams) — діаграми переходів станів. Усі вони містять графічні й текстові засоби моделювання: перші — для зручності відображення основних компонентів мо-делі, другі — для забезпечення точного визначення її компонен-тів та зв’язків. Класична DFD показує зовнішні щодо системи джерела і стоки (адресати) даних, ідентифікує логічні функції (процеси) і групи елементів даних, що зв’язують одну функцію з іншою (потоки), а також ідентифікує сховища (накопичувачі) даних, до яких здійснюється доступ. Структури потоків даних і визначення компонентів їх зберігаються й аналізуються у словнику даних. Кожна логічна функція (процес) може бути деталізована за допомогою DFD нижнього рівня; коли подальша деталізація перестає бути корисною, переходять до вираження логіки функції за допомогою специфікації процесу (міні-специфікації). Вміст кожного сховища також зберігається у словнику даних, модель даних сховища розкривається за допомогою ERD. За наявності реального часу DFD доповнюється засобами опису поведінки системи, залежної від часу, що розкриваються за допомогою STD. Ці взаємозв’язки показані на рис. 2.6. Рис. 2.6. Взаємозв’язок графічних нотацій за структурного аналізу Треба зазначити, що для функціонального моделювання поряд з DFD досить часто застосовується й інша нотація — SADT (точніше, її стандартизована підмножина IDEF0). Порівняльний аналіз цих двох підходів до моделювання функцій системи буде наведений нижче. Таким чином, перелічені вище засоби дозволяють зробити по-в¬ний опис системи незалежно від того, чи є вона існуючою, а чи такою, що розробляється з нуля. Такий докладний опис того, що повинна робити система, звільнений, наскільки це можливо, від розгляду шляхів реалізації, отримав назву специфікації вимог, що дає проектувальникові, який реалізує наступний етап ЖЦ, чі-т¬ке уявлення про кінцеві результати, що їх треба досягти. Перелічені вище графічні нотації використовуються (в тому або іншому наборі) практично у всіх сучасних методологіях структурного системного аналізу. Найістотніша відмінність між різновидами структурного ана-лізу полягає в методах і засобах функціонального моделювання. З цього погляду всі різновиди структурного системного аналізу можуть бути поділені на дві групи: ті, в яких застосовуються ме-тоди і технологія DFD (у різних нотаціях), і ті, що використову-ють SADT-методологію. Порівняльний аналіз цих двох методологій можна здійснити за такими параметрами: а) адекватність засобів проблемі, що розглядається; б) узгодженість з іншими засобами структурного аналізу; в) інтеграція з наступними етапами розробки (насамперед зі етапом проектування). Рис. 2.7. Приклад DFD-діаграми 1) Адекватність. Вибір тієї або іншої структурної методоло-гії безпосередньо залежить від предметної області, для якої ство-рюється модель. У нашому випадку методології застосовуються до автоматизованих систем управління підприємством, а не до систем взагалі, як це передбачається в SADT. Для задач, що роз-глядаються, DFD — поза конкуренцією. На рис. 2.7 та 2.8 наве-дено моделі вимог до системи автоматизації управління підпри-ємством, що займається розподілом товарів за замовленнями. По-перше, SADT-діаграми значно менш чіткі й зручні для мо-делювання АІСУП (порівняйте рис. 2.7 і рис. 2.8). Так, дуги в SADT жорстко типізовані (вхід, вихід, управління, механізм). Водночас стосовно АІСУП стирається смислова відмінність між входами і виходами, з одного боку, і управліннями й механізма-ми — з іншого: входи, виходи, механізми і управління є потока-ми даних і/або управління і правилами їх трансформації. Аналіз системи за допомогою потоків даних і процесів, що їх перетво-рюють, є більш прозорим і недвозначним. Рис. 2.8. Приклад SADT-діаграми По-друге, в SADT взагалі відсутні чіткі засоби для моделю-вання особливостей АІСУП. DFD з самого початку створювалися як засіб проектування інформаційних систем, що є ядром АІСУП, і мають більш багатий набір елементів, які адекватно відображають специфіку таких систем (наприклад, сховища даних є прообразами файлів або баз даних, зовнішні сутності відображають взаємодію системи, що моделюється, із зовнішнім світом). 2) Узгодженість. Головним достоїнством будь-яких моделей є можливість інтеграції їх з моделями інших типів. У цьому ви-падку йдеться про узгодженість функціональних моделей із за-собами інформаційного і подійного (часового) моделювання. Узгодження SАDТ-моделі з ЕRD і/або SТD практично неможливе або має тривіальний характер. У свою чергу DFD, ЕRD і SТD взаємно доповнюють одна одну і є по суті узгодженими подан-нями різних аспектів однієї і тієї самої моделі. У табл. 2.1 відо-бражена можливість такої інтеграції для DFD і SADT-моделей. Таблиця 2.1 Назва ЕRD STD Структурні карти DFD + + + SADT + – – 3) Інтеграція з подальшими етапами. Важлива характерис-тика методології — її сумісність з подальшими етапами застосу-вання результатів аналізу (і передусім з етапом проектування, що йде безпосередньо за аналізом і спирається на його результати). DFD можуть бути легко перетворені в моделі проектування (структурні карти) — це близькі моделі. Більш того, відомий ряд алгоритмів автоматичного перетворення ієрархії DFD в струк¬турні карти різних видів, що забезпечує логічний і безболісний перехід від етапу аналізу вимог до проектування системи. З іншого боку, невідомі формальні методи перетворення SADT-діаграм у проектні рішення АІСУП. 2.3.1.2. Структурне проектування Базовими будівельними блоками АІСУП при використанні структурного підходу є модулі. Всі види модулів у будь-якій мо-ві програмування мають ряд загальних властивостей, з яких істо-т¬ні при структурному проектуванні перелічені нижче: 1) Модуль складається з безлічі операторів мови програму-вання, записаних послідовно. 2) Модуль має ім’я, на яке до нього можна посилатися як до єдиного фрагмента. 3) Модуль може приймати і/або передавати дані як параметри в послідовності виклику або зв’язувати дані через фіксовані осе-редки або загальні області. Під час структурного проектування виконуються два види робіт: 1) проектування архітектури АІСУП, що включає розробку структури та інтерфейсів її компонент (автоматизованих робочих місць), узгодження функцій і технічних вимог до компонентів, визначення інформаційних потоків між основними компонентами, зв’язків між ними і зовнішніми об’єктами; 2) детальне проектування, що включає розробку специфікацій кожного компонента, розробку вимог до тестів і плану інтеграції компонентів, а також побудову моделей ієрархії програмних мо-дулів і міжмодульних взаємодій і проектування внутрішньої структури модулів. При цьому відбувається розширення моделі вимог: • за рахунок уточнення наявних функціональних, інфор-маційних і, можливо, подійних моделей вимог, побудованих за допомогою відповідних засобів структурного аналізу; • завдяки побудові моделей автоматизованих робочих місць, що включають підсхеми інформаційної моделі і функціо-нальні моделі, орієнтовані на ці підсхеми аж до ідентифікації конкретних сутностей інформаційної моделі; • за рахунок побудови моделей міжмодульних і внутріш- ньомодульних взаємодій з використанням техніки структурних карт. У структурному підході для цілей проектування модулів ви-користовується техніка структурних карт (схем), що демонст-рує, яким чином системні вимоги відбиватимуться комбінацією програмних структур. При цьому найчастіше застосовують дві техніки: структурні карти Константайна (Соnstantine), призна-чені для опису відношень між модулями, і структурні карти Джексона (Jackson) — для опису внутрішньої структури мо-дулів. Структурні карти Константайна є моделлю відношень ієрархії між програмними модулями. Вузли структурних карт відповідають модулям і областям даних, потоки відображають міжмодульні виклики (в тому числі циклічні, умовні й парале-льні). Міжмодульні зв’язки по даних і управлінню також моде-люються спеціальними вузлами, прив’язаними до потоків, стрілками вказуються напрями потоків і зв’язків. Фундамен-тальні елементи структурних карт Константайна стандартизо-вані ІВМ, ISO і АNSI. Техніка структурних карт Джексона сходить до методології структурного програмування Джексона і полягає в продукуванні діаграм і схем для графічного ілюстрування внутрішньомодуль-них (а іноді й міжмодульних) зв’язків і документування проекту архітектури АІСУП. При цьому структурні карти Джексона до-зволяють здійснювати проектування нижнього рівня АІСУП і на цьому етапі є близькими до традиційних блок-схем, що моделю-ють послідовне, паралельне, умовне та ітераційне виконання їх вузлів. 2.3.2. Об’єктно-орієнтований підхід 2.3.2.1. Об’єктно-орієнтовані методи аналізу Важливе місце в розробках АІСУП займають об’єктно-орієн-товані методології, засновані на об’єктній декомпозиції предмет-ної області, що подається у вигляді сукупності об’єктів, які взає-модіють між собою за допомогою передачі повідомлень. Даний підхід не є протиставленням структурному підходу, більш того, фрагменти методологій структурного аналізу (а саме його базові моделі: DFD, ЕRD і SТD) використовуються при об’єктно-орієн-тованому аналізі для моделювання структури і поведінки самих об’єктів. Як об’єкти предметної області можуть розглядатися конкретні предмети, а також абстрактні або реальні сутності (наприклад, клієнт, замовлення, підприємство тощо). Кожний об’єкт характеризується своїм станом (точніше, набором атрибутів, значення яких визначають стан), а також набором операцій для перевірки і зміни цього стану. Кожний об’єкт є представником певного класу однотипних об’єктів, що визначає їхні загальні властивості. Усі представники (примірники) одного і того самого класу мають один і той самий набір операцій і можуть реагувати на одні й ті самі повідомлення. Об’єкти і класи організуються з дотриманням таких прин-ципів: 1. Принцип інкапсуляції (приховування інформації) декла-рує заборону будь-якого доступу до атрибутів об’єкта, крім як через його операції. Відповідно до цього внутрішня структура об’єкта прихована від користувача, а будь-яка його дія ініціюєть-ся зовнішнім повідомленням, що зумовлює виконання відповід-ної операції. 2. Принцип успадкування декларує створення нових кла-сів — від загального до конкретного. Такі нові класи зберігають усі властивості класів-батьків і при цьому містять додаткові ат-рибути й операції, що характеризують їхню специфіку. 3. Принцип поліморфізму декларує можливість роботи з об’єктом без інформації про конкретний клас, представником якого він є. Кожний об’єкт може вибирати операцію на основі типів даних, що приймаються в повідомленні, тобто реагувати індивідуально на це (одне і те саме для різних об’єктів) повідом-лення. Таким чином, об’єктно-орієнтований підхід полягає в поданні системи, що моделюється, у вигляді сукупності класів і об’єктів предметної області. При цьому ієрархічний характер складної системи виявляється з використанням ієрархії класів, а її функці-о¬нування розглядається як взаємодія об’єктів. Життєвий цикл та-кого підходу містить етапи аналізу вимог, проектування, ево-люції (що об’єднує програмування, тестування і налагодження, а також комплектацію системи) і модифікації. При цьому на від-міну від каскадної моделі відсутня строга послідовність виконан-ня перелічених етапів. Відомі об’єктно-орієнтовані методології базуються на інтег-рованих моделях трьох типів: • об’єктній моделі, яка відображає ієрархію класів, що пов’язані спільністю структури і поведінки і відображають спе-цифіку атрибутів і операцій кожного з них (при цьому однією із базових нотацій об’єктної моделі є діалект ЕRD); • динамічній моделі, що відображає часові аспекти й по-слідовність операцій (при цьому досить часто використовують SТD); • функціональній моделі, що описує потоки даних (з вико-ристанням DFD). Головними недоліками об’єктно-орієнтованих методологій є такі: • відсутність стандартизації в галузі програмотехніки, що розглядається (наприклад, для подання об’єктів і взаємозв’язків між ними); • відсутність методу, що однаково добре реалізує етапи ана- лізу вимог і проектування (більшість методів призначена для об’єктно-орієнтованого аналізу, деякі передбачають слабко роз-винуті засоби проектування). 2.3.2.2. Об’єктно-орієнтоване проектування Якщо методи структурного проектування мали на меті спро-щення системної розробки на основі алгоритмічного підходу, то об’єктно-орієнтовані методи вирішують аналогічне завдання, ви-користовуючи описи класів і об’єктів, тобто чіткі засоби об’єкт-но-орієнтованого програмування. Г. Буч визначив об’єктно-орі-єнтоване проектування як «методологію проектування, що поєд-нує в собі процес об’єктної декомпозиції і прийоми уявлення як логічної та фізичної, так і статичної та динамічної моделей сис-теми, що проектується». Основою для об’єктно-орієнтованого проектування цілком об-ґрунтовано служать результати об’єктно-орієнтованого аналізу. Проте результат будь-якого з методів структурного аналізу також може бути використаний як вхідні дані для об’єктно-орієнтовано¬го проектування: в цьому разі проводиться інтеграція діаграм потоків даних з класами та об’єктами. На етапі проектування використовуються наступні діаграмні техніки: • успадковані від етапу аналізу вимог і такі, що розвиваються на етапі проектування, діаграми класів і діаграми об’єктів, що є основою статичної логічної моделі; • діаграми модулів і діаграми процесів, що моделюють конк-ретні програмні й апаратні компоненти і є частиною статичної фізичної моделі; • динамічні моделі: діаграми переходів станів, які моделюють часову послідовність зовнішніх подій, що впливають на об’єкти конкретного класу, і часові системні діаграми, що моделюють часовий порядок повідомлень і подій, які стосуються міжоб’єктних взаємодій. 2.3.3. Процесно-орієнтований підхід 2.3.3.1. Реінжиніринг бізнесу як основа процесно-орієнтованого підходу до створення інформаційних систем Сучасний підхід до управління підприємством ґрунтується на конвергенції управлінських і інформаційних технологій. Класики теорії сучасного менеджменту — Хаммер, Чампі, Давенпорт, Джонсон, Морріс, Брандон та інші — сходяться на думці, що ав-томатизоване управління будується на інших принципах, ніж ке-рування підприємствами в передкомп’ютерну епоху, і вимагає докорінної перебудови всієї системи управління. Процес впрова-дження інформаційної системи в організації тісно пов’язаний із перебудовою самої системи управління — оптимізацією органі-заційної структури, процесів і функцій, що описують взаємодію ланок цієї структури, а також із зміною мотивації персоналу. Процес зміни системи управління підприємством є багатоета-п¬ним. В ідеальному випадку на першій стадії варто визначитися з місією підприємства і його стратегічними цілями. Ці задачі вирішуються виходячи з аналізу, насамперед, зовнішнього середовища підприємства за допомогою дослідження ринку, аналізу економіко-політичних та інших чинників. Даний етап виконують фірми, що займаються управлінським консалтингом і аудитом. Слід лише зауважити, що тут криється більшість проблем реновації управління на українських підприємствах. З одного боку, керівники підприємств не усвідомлюють належною мірою важливості цього етапу, а з іншого — не належним чином стоять справи й із самим управлінським консультуванням, оскільки західні експерти, зокрема представники «Великої шістки», використовують підходи, не адекватні реаліям сучасної України (відповідно і рекомендації є неадекватними), а українська управлінська школа перебуває тільки в стадії формування і накопичення досвіду. Наступний етап — аналіз і адаптація внутрішнього середо-вища підприємства з тією метою, щоб його структура і принципи функціонування відповідали місії підприємства і були спрямовані на досягнення поставлених стратегічних цілей. Цей етап нази-вається реінжинірингом бізнес-процесів. Якщо ж необхідне впровадження автоматизованої системи підтримки бізнесу, то даний етап можна назвати визначенням вимог до інформаційної системи (аналізом вимог), коли на основі цільових моделей діяльності підприємства (моделей «як повинно бути») виявляються об’єктивні вимоги до тих задач, виконання яких повинна забезпечувати розроблювана автоматизована система. Бізнес-процеси — це ділові, адміністративні, технологічні процедури функціонування підприємства, до яких належать: до-кументообіг, управління фінансовими, матеріальними потоками, персоналом, організаційно-господарськими і технологічними про¬цесами, процесами проектування виробів і т.ін. Аналіз і оптимізація бізнес-процесів заради досягнення компанією стратегічних цілей і є реінжиніринг, що виконується за допомогою аналізу внутрішнього середовища підприємства. Його методологічною осно¬вою є системний і структурний аналіз, теорія управління великими системами, а також методи керування якістю, промислова інженерія тощо. Відповідна розробка методології дозволила перетворити реінжиніринг в інженерний процес (підкреслюється визначенням!), підтримуваний інструментами і технологіями проектування ділових процесів. Спочатку розглядається існуюча система управління підприємством: виявляються витратні центри, формуються моделі: структурні, функціональні (процесні), моделі даних, а також комплексні — «як є» і «як повинно бути». Потім складається план заходів щодо переходу зі стану «як є» у стан «як повинно бути» і за необхідності проектується інформаційна система, що підвищує ефективність функціонування підприємства. 2.3.3.2. Методика інтегрованого процесно-орієнтованого проектування інформаційних систем (ARIS) Інструментарій, яким користуються інженери з управління, аналітики і проектувальники автоматизованих систем, називаєть-ся CASE-засобами. У найповнішому варіанті CASE-засоби під-тримують усі стадії створення і впровадження інформаційної си-стеми: від постановки задач, що підлягають автоматизації, до ге-нерації машинного коду. На жаль, нині не існує таких систем, які б Рис. 2.9. Склад інструментального середовища ARIS забезпечували генерацію повноцінних програмних модулів, що цілком відповідають установленим вимогам. Для створення ав-томатизованих систем високого класу, здатних справді підвищи-ти ефективність, необхідні «ручне» програмування або адаптація вже готової системи управління підприємством до умов конкрет-ного об’єкта автоматизації. У зв’язку з цим засоби, що дозволя-ють проаналізувати всі аспекти діяльності підприємства (а не тільки принципи опрацювання інформації) і спроектувати відпо-відну автоматизовану систему, можуть не мати засобів генерації робочої програми (приклад — програмний пакет ARIS Toolset компанії IDS Prof. Scheer Gmbh). Реінжиніринг полягає в погодженій оптимізації головних скла-дових системи керування: організаційної структури, функцій, процесів і ресурсів. Щоб оптимізувати систему керування, потрібно її багаторазово переконфігурувати, порівняти конструкції, що утворилися, між собою і вибрати найкращу. Виконати це без інструментальної підтримки з боку комп’ютерних технологій неможливо. ARIS Toolset робить структуру підприємства прозорою для аналізу і настроювання системи управління. На відміну від багатьох інших засобів аналізу й проектування ARIS Toolset забезпечує комплекс¬ний погляд на аналізоване підприємство і проектовану автоматизовану систему і дозволяє працювати з моделями чотирьох типів: функціональними, моделями даних, організаційними та управлінськими. Рис. 2.10. Методологічний «дім» ARIS. Взаємозв’язки моделей Функціональна модель виявляє структуру операцій у контексті досягнення цілей компанії; моделі даних дозволяють структуру-вати інформацію і документи, що використовуються в діяльності компанії; організаційна модель описує вертикальні й горизон-тальні відношення між підрозділами, а також персонал підприєм-ства у прив’язці до штатного розкладу; нарешті, управлінська модель інтегрує перші три моделі одну з одною і являє собою комплексний погляд на діяльність підприємства, що відображає реальні умови виконання функцій, відповідальність апарату управ¬ління за їх виконання, а також використовувані й породжувані при цьому документи. Розходження в типах моделей відповідає розходженню в об’єк¬тах і способах систематизації інформації. Наприклад, за організаційного моделювання визначаються підрозділи (об’єкти) і відношення підпорядкованості між ними. Відношення підпорядкованості в пакеті ARIS Toolset описуються за допомогою призна¬чення типу зв’язків: технічний керівник (керівник з спеціалізації), дисциплінарний керівник (наприклад директор, начальник відділу), організаційний менеджер (менеджер у проектній організації) тощо. Аналіз підприємства і проектування системи управління мож-на розпочинати з розробки будь-якої із чотирьох моделей. Більш того, розробку моделей можна (і навіть рекомендується) здійс-нювати паралельно, поступово виявляючи всі аспекти діяльності підприємства. За внесення змін у будь-яку з моделей інші кори-гуються, при цьому гарантується несуперечність моделей одна одній. З якої моделі починати — залежить від проектованого до-датка або цілей аналізу. Загальні рекомендації такі. У разі проек-тування довідкової системи, що характеризується опрацюванням великих обсягів інформації, варто розпочинати з проектування моделі даних, а після того, як задані запити, будувати функціо-нальну модель. Аналіз та реорганізація бізнес-процесів, а також розробка системи керування зазвичай починаються з функціо-нального моделювання. У цьому випадку можна також почати з моделювання організаційної структури, але це не завжди зручно й виправдано, оскільки зміна організаційної структури базується на аналізі цілей підприємства та функцій, що їх забезпечують. Тому починають, як правило, із подання організаційної структу-ри «якою вона є», а на базі аналізу функцій виробляють рекомен-дації щодо її удосконалення. Процес моделювання спрямований на збір і систематизацію зведень про функціонування підприємства і на виявлення й усу-нення різного роду невідповідностей, у результаті чого формує-ться так зване корпоративне знання — досить повна інформація про внутрішній устрій і принципи функціонування підприємства. Виявлення невідповідностей здійснюється як візуальним аналізом побудованих моделей, так і використанням вбудова- них в інструментальне середовище засобів перевірки моделей. Наприклад, якщо була «змодельована» організаційна структура «якою вона є», визначені всі цілі, розписані функції, що їх за-безпечують, і для кожної функції визначено існуючий розподіл відповідальності (тобто хто виконує функцію, кому передаються результати її виконання), то можна виявити, що, наприклад, за виконання тієї або іншої функції відповідає більша, ніж належить, кількість працівників або, навпаки, для функції не визначено жодної відповідальної особи. За використання інстру-ментального засобу ARIS Toolset подібного роду правила мо-жуть бути «сконструйовані» самостійно під умови конкретного підприємства. При моделюванні можна також задати рівні та «горизонти» планування і керування, вимоги до кваліфікації персоналу для виконання тієї або іншої функції, просторову прив’язку апарату управління, вартість, тривалість, частоту виконання процедур, а також багато інших аспектів. Результатом проектування за допомогою ARIS Toolset є регу-ляризація управління. З одного боку, виключаються будь-якого роду надмірність: дублюючі один одного процеси, а також непо-трібні з погляду цілей компанії функції і процеси, підрозділи, по-сади і виконавці. З іншого — жодна з функцій, жодний із проце-сів не перебуває в «підвішеному» стані, без закріпленої відпові-дальності за виконання. Після того, як закінчено певний варіант моделювання, можна візуалізувати діяльність і управління на підприємстві, тобто «програти» деякі альтернативні варіанти перетворень, імітуючи виконання процесів у часі. У ARIS Toolset для цих цілей викори-стовується модуль імітаційного моделювання ARIS Simulation, що здійснює імітаційне моделювання на основі графічного уявлення послідовності процесів, керованих подіями (EPC — Event-driven Process Changing). На екрані монітора з’являється динамічна сцена, що наочно ілюструє процеси функціонування підприємства, які відповіда-ють побудованим моделям. Під час спостереження можна вноси-ти корективи і переглядати різні варіанти (сценарії) розвитку по-дій за різних початкових умов. При створенні й перепроектуванні бізнес-процесів у якості моделей «як повинно бути» можуть використовуватися готові моделі-прототипи, що описують підприємства конкретної галузі діяльності (машинобудівне виробництво, виробництво меблів, проектування заводів тощо). Далі рух йде в двох напрямках. З одного боку, бізнес-процеси підприємства перебудовуються з урахуванням можливостей ав-томатизованої системи; з іншого — подібні системи володіють тим чи іншим ступенем гнучкості, що дозволяє адаптувати їх до умов конкретного об’єкта автоматизації. Після досягнення подіб-ного компромісу здійснюється впровадження адаптованої авто-матизованої системи на удосконаленому підприємстві. Спеціальні засоби, що входять до складу комплексу ARIS, до-зволяють здійснити автоматичне настроювання інформаційної системи відповідно до розроблених моделей, що описують діяльність підприємства. Схеми з управління можуть бути перенесені з репозитарію (сховища інформації про моделі) та доопрацьовані під умови підприємства. У результаті підприємство одержує готову автоматизовану інформаційну систему, яка надалі може бути легко адаптована у разі виникнення яких-небудь змін у його діяльності. Інструментарій ARIS Promt дозволяє розраховувати вартості процесів за допомогою точного обліку складу операцій, їхньої продуктивності і частки ресурсів, що витрачаються на виготов-лення кожного виробу. Тим самим досягається більш гнучкий облік витрат порівняно з традиційними схемами віднесення на-кладних витрат у фіксованій пропорції до прямих витрат. Звичайно, щоб ефективно застосовувати інструментарій ARIS Toolset, необхідно мати знання і досвід як в інформатиці, так і в менеджменті. Однак моделі, побудовані фахівцями-консультан-тами, є простими і ясними для розуміння, що дозволяє керівни-кам підприємства контролювати процес реінжинірингу системи управління і брати у ньому участь. Останні можуть скористатися також спрощеним інструментом ARIS Easy Design, що підтримує процес моделювання на інтуїтивному рівні, але водночас забез-печує професійне оформлення моделей. Моделі, створені за допомогою ARIS Toolset, є основою для реалізації ділових процедур у системах класу workflow (автома-тизації ділових процесів) і процесів за допомогою стандартного програмного забезпечення. Ці моделі слугують як вхідна інфор-мація для CASE-систем, що використовуються для розробки не-стандартного програмного забезпечення. 2.3.3.3. Процесно-орієнтоване (динамічне) моделювання підприємства на основі мереж Петрі В основі будь-якого моделювання лежить теорія, яка ствер-джує: абсолютна подібність може мати місце лише за умови за-міни одного об’єкта таким самим іншим. А це означає, що при моделюванні подібність не має місця — основна мета моделю-вання полягає в тому, щоб модель досить добре відображала до-сліджуваний аспект функціонування. Класифікація методів моде-лювання детально розглянута в ?12?. З наведеного там переліку нас найбільше цікавитимуть ті методи, які є найприйнятнішими для моделювання бізнесу (наприклад, діяльності підприємства), тобто для побудови бізнес-моделей, що описують функціонуван-ня підприємства. До числа таких методів слід віднести: а) систем¬но-структурне моделювання; б) ситуаційне моделювання; в) імітаційне моделювання. У подальшому основна увага зосереджуватиметься на останньому. 2.3.3.3.1. Методика та елементи імітаційного процесно-орієнтованого (динамічного) моделювання підприємства Загалом процес динамічного моделювання підприємства (Dynamic Enterprise Model) можна виразити таким чином: під-приємство зводиться до ієрархічної моделі, яка формується з еле¬ментарних функціональних модулів (бізнес-функцій), що поєднуються в інформаційні потоки (бізнес-процеси), та організаційної структури підприємства (бізнес-організації). Сукупність моделей бізнес-функцій, моделей бізнес-процесів і моделі бізнес-організації являє собою імітаційну бізнес-модель підприємства (рис. 2.11). Бізнес-моделі складаються з таких компонентів: • Модель бізнес-функцій — до її складу входять: ? дерево бізнес-функцій; ? відношення оптимізації; ? «ноу-хау» в галузі удосконалення бізнесу; ? ключові показники діяльності. • Модель бізнес-процесів складається з: ? основних бізнес-процесів; ? детальних бізнес-процесів. • Модель бізнес-організації. • База даних по певній галузі промисловості. Рис. 2.11. Рівні динамічного моделювання підприємства В основі концепції динамічного моделювання лежить побудо-ва (моделювання) підприємства в термінах і методами мереж Пе-т¬рі. При цьому використовуються такі підходи: ? діяльність підприємства поділяється на види відповідно до функціонально-організаційної структури; ? види діяльності пов’язані двома типами каналів — інфор-маційним і керуючим. Перший передає необхідну вхідну інфор-мацію для ініціації діяльності, а другий передає право дії (знак виконання, під час надходження якого на вхід починається вико-нання бізнес-процесів, які становлять сутність діяльності); ? якщо діяльність має більш ніж одну бізнес-функцію в біз-нес-процесі, керування переходами відбувається таким самим чи¬ном — передачею вхідних даних і знаку каналами, якими пов’я¬зуються бізнес-функції в бізнес-процеси; ? після виконання діяльності і за її результатами знак копію-ється в один (чи декілька) відповідних каналів для передачі факту здійснення діяльності; ? після виконання діяльності і за її результатами (або за су-купністю результатів декількох видів діяльності) визначається один і тільки один новий напрямок знаку. Для розуміння процедури динамічного моделювання підпри-ємства слід розглянути сутність та властивості елементів динамі-ч¬ної моделі підприємства. ? Модель бізнес-процесів Модель бізнес-процесу — це опис загального виробничого процесу в термінах конкретної корпоративної системи. Така мо-дель описує, які бізнес-процеси у певному напрямі діяльності можуть підтримуватися конкретною корпоративною системою і як це може бути здійснено. У моделі можна створити ієрархію, у результаті чого, наприклад, потік замовлень усередині організації може бути змодельований у так звану «основну» процедуру, тимчасом як подробиці про даний потік замовлення рекомендуються в схемах детальних процедур. Модель бізнес-процесу має такі цілі: • дати наочне уявлення того, яким чином корпоративна сис-тема працює з бізнес-процесами найвищого рівня, особливо для певного напряму або виду діяльності (основні процедури), на-приклад: «Потік замовлень основної процедури в моделі комер-ційної діяльності»; • дати наочне уявлення і задокументувати загальні бізнес-про¬цеси (детальні процедури), що підтримуються системою (наприклад: «Надходження від продажу»); • дати наочне уявлення і задокументувати періодичні детальні бізнес-процеси (наприклад: «Рознесення фінансових операцій» і «Підрахунок циклів»); • дати наочне уявлення і задокументувати процедури почат-кового запуску і настановні процедури, необхідні для впрова-дження системи (наприклад: «Ввести модуль опрацювання пові-домлень банку» або «Визначити точки фінансових операцій»); • зафіксувати розробку процесу (особливо для детальних біз-нес-процесів) для надання руху операційному робочому процесові; • задокументувати адміністративні процеси, за яких можливо приписати власників до бізнес-процесів залежно від роду діяль-ності, посади, повноважень, посадових інструкцій тощо; • розробити й задокументувати перетворення корпоративною системою бізнес-процесів, пов’язаних з конкретним проектом. • Бізнес-процеси мають такі характеристики: • бізнес-процеси складаються з ряду компонентів, як-от ста-нів, видів діяльності і контролю. Робота є основною частиною бі-з¬нес-процесів. Стан передує кожному виду діяльності і визначає-ться ним. Діяльність може являти собою сеанс роботи з корпора-тивною системою, бути прикладним програмним забезпеченням, що не належить до неї, та неавтоматизовану діяльність або вмон-тований бізнес-процес; • бізнес-процеси моделюються на основі мереж Петрі і мо-жуть мати декілька ієрархічних рівнів; • посадові інструкції, документи аналогового виводу і коди утиліт (сервісних програм) можуть бути співвіднесені з видами діяльності. Посадові інструкції можуть містити особливу допо-міжну інформацію для сеансу в межах конкретного бізнес-про-цесу. У рамках певного виду діяльності можливе співвіднесення з документом аналогового виводу, створеним у межах даного виду діяльності. Коди утиліт — це блоки сеансів, що можуть бути використані як допоміжні сеанси (сеанс виводу на екран, роздруківки) під час здійснення певного виду діяльності; • вивід бізнес-процесу на екран у графічному вигляді може використовуватися як інтерфейс користувача замість структури меню; • працівники і виконувані ними функції можуть бути співвід-несені з видами діяльності бізнес-процесу; • посилання на інший бізнес-процес можуть бути застосовані до такого компонента, як стан, у результаті чого може бути дане визначення бізнес-процесу з декількох переходів; • будь-який вузол контролю може мати декілька вихідних стрілок. Кожній стрілці може відповідати певна умова. За допо-могою так званих «правил» даним умовам може бути надане зна-чення. Коли бізнес-процес виводиться на екран, відбувається оцін¬ка значення умови, і, якщо умова не виконується, частина діаграми виводиться на екран у затемненому вигляді. Залежно від моделі бізнес-функції або встановлених параметрів схема бізнес-процесу може бути скомпонована динамічно. В результаті з самого початку загальна схема буде конкретно зорієнтована на одну з визначених бізнес-моделей. ? Роботи Роботи є основною частиною бізнес-процесів. Виділяють такі типи робіт: ? ручна робота — робота, не пов’язана з прикладною про-грамою; ? бізнес-процес — робота як процес, що є складовою поточ-ного процесу; ? сеанс; ? прикладна програма — програма, що запускається за до-помогою виклику оболонки операційної системи; ? керуюча робота — позначає момент ухвалення рішення в процесі, після чого процес може розгалужуватися. При описі роботи вибирається тип роботи, тип керуючого елемента (якщо робота є керуючою роботою), код (якщо робота є бізнес-процесом, сеансом, прикладною програмою), аргумент (для сеансу аргумент визначає набір дій користувача, які йому дозволено виконувати під час роботи в потоці робіт), опис, категорія робіт, адміністративно-організаційний документ (пов’язує тип до¬кумента з роботою), утиліта, вибір типу події: подія користувача, зовнішня подія (робота чекає спрацьовування зовнішнього тригера), подія таймера (робота чекає настання визначеного часу), автоматична подія (якщо робота може бути виконана без втручання користувача). ? Класифікація бізнес-процесів В архіві бізнес-процесів розрізняють головні і деталізовані процеси. Головні процеси, відтворюючи загальний товаро- і до-кументообіг, що відповідають концептуальній моделі, визначені спеціалізацією бізнесу і, в принципі, є унікальними. Деталізовані процеси мають узагальнений характер і можуть застосовуватися в багатьох секторах. ? Модель бізнес-функцій Модель бізнес-функції являє собою функціональну ієрархіч-ну декомпозицію бізнес-функцій. Відношення між такими бізнес-функціями утворять бізнес-процеси (рис. 2.12). Бізнес-функції використовуються для досягнення конкретних цілей. У моделі біз¬нес-функції вони описуються термінами, звичними для бізнесу (а не термінами корпоративної системи). На нижчому рівні біз-нес-функції можуть варіюватися залежно від варіанта бізнес-моделі. У цьому разі подібні бізнес-функції називають варіантами бізнес-функції. Даний компонент моделювання призначений для досягнення таких цілей: • модель бізнес-функції може бути використана як перший логічний крок у процесі моделювання, у якому на базі загальних цілей і бізнес-функцій може бути створена модель бізнес-процесу; • модель бізнес-функції може застосовуватися як допоміжний засіб для радників і консультантів під час проведення презента-цій для керівництва, на яких демонструється модель підприємст-ва для певної галузі промисловості; • модель бізнес-функції може слугувати засобом подання га-лузевого «ноу-хау» у сфері удосконалення господарської діяль-ності (наприклад, розширення напрямів оптимізації бізнес-функ-цій), найкращої практики ведення бізнесу і показників діяльності; • модель бізнес-функції може бути використана як інструмент накладання нейтральної бізнес-моделі, визначеної в термінах, звичних у бізнесі, в специфічне для корпоративної системи рішення; Рис. 2.12. Перетворення бізнес-функцій у бізнес-процеси Модель бізнес-функції може бути передана такими характери-стиками: • бізнес-функції подаються як вузли в деревоподібній діагра-мі, якою може переміщатися користувач; • бізнес-функції можуть пояснюватися текстами, у яких опи-суються характеристики окремої бізнес-функції; • з бізнес-функціями можуть бути пов’язані показники дія-льності (ПД). У бізнес-моделях проекту конкретному ПД може бути приписане стандартне значення; • між варіантами бізнес-функції можуть існувати відношення оптимізації, що вказують на можливість поетапного впроваджен-ня даних бізнес-функцій. Відношення оптимізації можуть бути пов’язані з текстами, за допомогою яких описуються організа-ційні аспекти оптимізації процесів; • у моделі бізнес-функції проекту варіанти бізнес-функцій, що об’єднуються з відношеннями оптимізації, можуть бути пов’язані з фазами впровадження. ? Класифікація бізнес-функцій Архів узагальнених бізнес-функцій для усієї промисловості потребує системи класифікації, щоб мати можливість відшукати необхідну структуру при формуванні референтної моделі. У сис-темі динамічного моделювання (DEM) розглядається ієрархічне дерево бізнес-функцій для класифікації, що відповідає стандарт-ній структурі Ернста і Янга [9]. В межах цієї структури визначені чотири ієрархічних рівні: • Мега-функції — кожна компанія може бути класифікована відповідно до шести мега-функцій (табл. 2.2). Ці мега-функції мають узагальнений характер і, отже, не підпорядковуються ви-значеній спеціалізації діяльності. Згадані функції охоплюють і управління, і процеси здійснення (стратегічне планування, розви-ток і виконання). • Головні функції — кожна мега-функція може включати де-кілька головних функцій. Це означає, що має місце функціональ-на декомпозиція. Головна функція тісніше пов’язана зі спеціа- лізацією бізнесу, аніж мега-функція. Саме тому архів головних функцій зростатиме в процесі збільшення кількості спеціалізова-них моделей бізнесу. • Базові функції — кожна базова функція представляє го-ловний процес у процесній моделі. В сукупності вони визна- чені для одного варіанта документопотоку, що буде опрацьо-ваний. • Бізнес-функції, опції та варіанти — базові функції вира-жаються через формування визначених підпорядкованих функ-цій. Крім цього, опції і варіанти можуть бути визначені обслуго-вуючою системою для заміни або доповнення основного змісту бізнес-процесів. У табл. 2.2 наведена стандартна класифікація для бізнес-функцій відповідно до стандарту Консалтингової агенції Эрнста і Янга ?9?. При зовнішньому кодуванні використовується ієрархічність класифікації, наприклад: • мега-функції : 1, 2, 3, ... • головні функції : 1.1, 1.2, 1.3, ... • базові функції : 1.1.1, 1.1.2, 1.1.3 • функції і варіанти : 1.1.1.1, 1.1.2.1, 1.1.3.1, .... Таблиця 2.2 СТАНДАРТНА КЛАСИФІКАЦІЯ БІЗНЕС-ФУНКЦІЙ Мега-функції Головні функції 1. Придбання нового бізнесу 11 Ринкові дослідження 12 Перспективи, клієнтура, співвідношення 13 Рекламування, публікація, зв’язок 14 Технологічні нововведення, системні дослідження 15… 2. Виконання (реалізація) 21 Ділове планування 22 Контроль виконання 23 Діловий контроль (управління) 24… 3. Підтримка 31 Фінансовий бухгалтерський облік 32 Планування і контроль(управління) 33 Казначейське планування 34 Робота з персоналом 35… 4. Новий виріб і проект обслуговування 41 Нововведення виробу 42 Нововведення процесу 43 Нововведення обслуговування (служби) 44… 5. Дії: (підрозділяються) 5a Продаж 5a1 Замовлення і пропозиція 5a2 Комерційне опрацювання замовлення 5a3 Асигнування і фінансова оцінка 5a4 ... 5b Розробка 5b1 Інженерне проектування 5b2 Проведення розробки 5b3 Документація 5b4 ... 5c Планування 5c1 Проектування 5c2 Планування виробництва і керування 5c3 Планування інвентарю 5c4 ... 5d Виробництво 5d1 Керування цехом 5d2 Збір даних 5d3 Реєстрація використовуваних матеріалів 5d4 ... 5e Доставка 5e1 Приймальні іспити 5e2 Транспортування й встановлення 5e3 ... 5f Закупівля 5f1 Придбання матеріалів 5f2 Закупівля товарної продукції 5f3 Укладання субпідрядних договорів 5f4 ... 6. Післяпродажна під-тримка 61 Обслуговування скарг 62 Гарантійне обслуговування 63 Післягарантійний ремонт 64 Планування і контроль системи обслуговування ? Правила Для побудови з бізнес-функцій бізнес-процесів та поєднання останніх у рамках моделі бізнес-організації використовується ни-з¬ка правил, а саме: 1. Правила цілісності Правила цілісності використовуються для перевірки узгодже-ності моделі. (Приклад цілісності: Якщо є в наявності варіант бізнес-функції «Пряме постачан-ня», то бізнес-функції «Опрацювання замовлення на придбання» і «Опрацювання замовлення на збут» повинні бути подані в моде-лі.) Після того, як бізнес-модель створена, можна перевірити її узгодженість, оцінюючи усі правила цілісності. 2. Правила перетворення Модель бізнес-функції може бути автоматично перетворена в модель бізнес-процесу за допомогою правил перетворення. (Приклад правила перетворення: Якщо варіант бізнес-функції «Опрацювання замовлення на придбання з контрактами» був визначений, необхідно вибрати бізнес-процес «Опрацювання контрактів».) Так само за допомогою даних правил перетворення можна по-дати безпосередній зв’язок моделі бізнес-функції з моделлю біз-нес-процесу. 3. Правила конфігурації Правила конфігурації використовуються для присвоєння зна-чення параметра залежно від його наявності в бізнес-функціях, бізнес-процесах або комбінацій останніх у бізнес-моделі. (Приклад правила конфігурації: Якщо був визначений варіант бізнес-функції «Опрацювання замовлення на покупку в ЕОД (Електронний обмін даними)», то значення параметра «Електронний обмін даними» налагоджує-ться на «так».) 4. Правила статичного режиму Контроль є одним із компонентів бізнес-процесу і використо-вується для моделювання варіантів. Під терміном «варіант» слід розуміти умову. В результаті умови з’єднуються з вхідними стрілками на діаграмах мереж Петрі. На додаток до тексту в діаграмі умова може також містити значення, яке встановлюється шляхом використання правил. Якщо значення логічної умови «Хибно», то в результаті така неактивна гілка «дерева» мережі Петрі подається в затемненому вигляді. Оскільки ці правила можуть бути визначені всередині моделі бізнес-функції, то можливим стає динамічне конфігурування біз-нес-процесу. ? Ролі та обов’язки Роль є функцією, що може бути реалізована тільки тими пра-цівниками, за якими ця функція закріплена. Ролі і, якщо необхідно, обов’язки можуть бути пов’язані з роботами, бізнес-процесами, організаційними компонентами і бізнес-функціями. За допомогою ролей визначається, які працівники (групи працівників) уповноважені на виконання певної роботи (або мають відповідні обов’язки). Розрізняють два типи ролей: • «Ролі за організаційними одиницями» є функціями пра-цівників, що пов’язані з організаційними одиницями у специфіч-ній для замовника організаційній діаграмі (проектній моделі), на-приклад: — фахівець із закупівель; — фахівець із продажу; — менеджер; — планувальник; — комірник. • «Ролі за бізнес-функціями» є такими функціями працівників, які виконуються у межах визначених бізнес-функцій, наприклад: а) бізнес-функція: продаж ролі: фахівець із продажу; секретар; б) бізнес-функція: робота із забезпечення матеріалами ролі: менеджер; комірник. Обов’язок являє собою деяку задачу, за допомогою якої спе-цифікується роль (тобто функція, виконувана групою працівни-ків), наприклад: — «Доступність для рекомендації»; — «Необхідність у консультації»; — «Необхідність в інформуванні»; — «Прийняття остаточного рішення»; — «Виконання»; — «Контроль виконання». З роботою можуть бути пов’язані не більше шести ролей. Для кожної ролі можна задати не більше шести обов’язків. Ролі й обов’язки наслідуються на нижніх рівнях бізнес-процесів. Якщо для деякого бізнес-процесу одна роль використо-вується для всіх обов’язків у всіх роботах, то достатньо пов’язати цю роль і відповідні обов’язки з даним процесом. Спадкування ролей і обов’язків не застосовується до організаційних компонентів і бізнес-функцій. ? Модель бізнес-організації Модель бізнес-організації — це опис організаційної структу-ри та структури персоналу організації. Структура персоналу мо-же бути описана на абстрактному рівні за допомогою опису ро-лей або на конкретному рівні — зіставленням працівників і організаційних одиниць. Модель бізнес-організації має такі цілі: • одержати уявлення про поточну і, по можливості, майбутню (цільову) організаційні структури і задокументувати їх; • одержати уявлення про зміни в структурах підрозділів ком-панії залежно від розташування їх у загальній системі й задоку-ментувати їх; • зробити можливим створення інтерфейсу користувача кор-поративної системи в розрізі працівників або виконуваних функ-цій, що полегшується накладанням організаційної моделі на мо-дель бізнес-процесу. Модель бізнес-організації має такі характеристики: • організаційна модель складається з низки організаційних компонентів. З цими організаційними компонентами можна спів-віднести ім’я, тип і текст; • між організаційними компонентами можуть бути встановле-ні функціональні відношення. З такими функціональними відно-шеннями можна співвіднести текст; • організаційна модель може складатися з однієї або біль- ше організаційних схем. Дані схеми можуть співвідноситися одна з одною за допомогою визначення компонентів суб- діаграм; • користувачі й функції, які ними виконуються, можуть спів-відноситися з організаційними компонентами; • організаційні моделі можуть визначатися за фазами оптимі-зації так, щоб створити наочне уявлення про ефект проекту на-кладання бізнес-процесів на організацію. У загальному випадку модель підприємства включає такі об’єкти: а) основні дані; б) референтні моделі; в) проектні моделі. Перш ніж скористатися деякою референтною моделлю та по-будувати на її основі для конкретного підприємства проектну модель, треба спочатку ввести деякі основні дані (рис. 2.13). По-перше, повинна бути визначена версія, на основі якої створюва-тиметься модель. По-друге, компоненти, що використовуються в моделях, мають бути визначені як основні дані. Останні включа-ють такі складові, як бізнес-функції, бізнес-процеси та правила. Ці основні дані розміщуються в так званому архіві, що містить конструктивні блоки для моделей, які створюватимуться. Рис. 2.13. Зв’язок між об’єктами моделювання Потім створюються референтні моделі, що являють собою ви-користання досвіду й типології організацій із найвищою ефектив-ністю моделювання. Кожна референтна модель складається з мо-делі бізнес-функцій, моделі організації і моделі бізнес-процесів. Ці моделі описують бізнес-функції в організації, ієрархічну стру-ктуру організації та робочий стан дій, необхідних для виконання бізнес-функції. Моделі бізнес-функцій і моделі бізнес-процесів референтних моделей побудовані шляхом копіювання з архіву, в якому ці компоненти були визначені. Далі створюються проектні моделі, що являють собою структуру певної організації. Ці моде-лі подібні до референтних моделей, за винятком того, що вони є прив’язаними до однієї конкретної організації. У проектних мо-делях також можна визначити варіанти бізнес-функцій, що пода-ють різноманітні засоби виконання бізнес-функцій. Для цих варіантів можуть бути визначені зв’язки оптимізації, які наводять оптимальні шляхи, що ними потрібно йти, переходячи від одного засобу роботи до більш оптимізованого засобу. Підсумовуючи, можна зробити такі висновки: 1) референтні моделі складаються з ряду компонентів, доступних в архіві (як визначено в бізнес-об’єкті Основні дані); 2) проектні моделі часто засновані на референтних моделях; 3) проектні моделі складаються з ряду компонентів, доступ-них в архіві (або нещодавно включених, або отриманих за допомогою референтних моделей); 4) референтні моделі можуть бути засновані на проектних моделях. Мережі Петрі як засіб побудови динамічних моделей підприємства Метод моделювання «Мережі Петрі» був розроблений Ада-мом Петрі у 60-х роках ХХ ст. З того часу він став одним із най-більш визнаних стандартних методів моделювання процесів. У динамічному моделюванні підприємства метод мереж Петрі слу-гує засобом опису потоків бізнес-процесів. Для здійснення такого опису використовуються чотири базових конструктивних елементи (табл. 2.3). Таблиця 2.3 КОНСТРУКТИВНІ ЕЛЕМЕНТИ МЕРЕЖ ПЕТРІ Конструктивний елемент Характеристика Стани: Стани несуть у собі символи роботи, що повинні опрацюватися в діяльності, яка йде за символом стану. Приклад символу в стані — комерційне замовлення, що буде прийняте і підтверджене. Стан може фіксувати певний тип символу роботи, описаний при визначенні стану Дії управління: Дії управління відповідають за пересування символу роботи в потоці процесу. Є три мо-жливості: • (X) OR-розвилка (напрям 1 або 2); • AND-розвилка (паралельний); • AND-поєднання (синхронізація) Процеси: Ручні або автоматизовані дії, що перетворюють сим¬вол роботи зі cтану входу в інший символ роботи в стані виходу Підпроцеси: Підпроцеси дозволяють структурувати процеси на більш низькому рівні Таблиця 2.4 КОНСТРУКТИВНІ БЛОКИ МЕРЕЖ ПЕТРІ Конструктивний блок Характеристика Розподіл дій: Діяльність розбита на дві дії B і C, виконані у зазначеному порядку Дії, виконані паралель-но: Діяльність розбита на дві дії B і C. Послідовність, у якій виконуються B і C, не має ніякого значення. Про¬те обидві повинні бути ви¬конані до закінчення процесу Спеціалізовані дії: Діяльність розбита на дві альтернативні дії B або C. На підставі визначеної діяльності стану B або C відібрані (не обидві, тому тільки або) OR-поєднан-ням — єдиним місцем ви-ходу наприкінці процесу Закінчення табл. 2.4 Конструктивний блок Характеристика Ітерація дій: Виконання дії припускає виконання діяльності B один або більшу кількість разів. Число ітерацій урегульоване під час визначення стану Моделювання потоку процесу через мережі Петрі базується на декількох принципах: • діяльність починається, коли є принаймні один символ ро-боти у всіх поєднаних станах входу діяльності; • діяльність споживає один символ роботи з кожного стану входу і продукує один символ роботи для кожного поєднаного стану виходу; • дії управління мають спеціальні можливості (табл. 2.4): ? вони можуть множити один символ роботи зі стану входу і поміщати їх у два або більшу кількість станів виходу. Для цього будується конструкція AND-розвилка; ? вони можуть маршрутизувати символ роботи через процес, розміщаючи цей символ в один із поєднаних станів виходу, заснованих на певних станах. Цей засіб реалізується через конструк¬ції OR-розвилки; ? вони можуть синхронізувати дії, виконані в рівнобіжних кроках. Для цього використовується конструкція AND-поєд-нання. На основі досвіду моделювання процесів у потоках мереж Пе-т¬рі можна зробити кілька рекомендацій: • кожен потік процесу починається і закінчується тільки од-ним станом; • вхід і вихід потоку повинні мати чітке й однозначне форму-вання. Потрібно використовувати лише стандартні блоки. Це га-рантує коректні мережі Петрі, що можуть бути реалізовані сис-темою керування потоками; • процес слід обмежувати п’ятьма-десятьма кроками. Якщо потрібна більша кількість кроків — будується підпроцес; • поєднання сторінок не використовується. Достатньо струк-турувати процес ієрархічним методом. Наведемо приклад бізнес-процесу «Циклічна інвентаризація на складах», скориставшись розглянутими вище засобами та правилами побудови мереж Петрі (рис. 2.14). 2.4. САSЕ-ТЕХНОЛОГІЇ — ІНСТРУМЕНТАРІЙ ПІДТРИМКИ ЖИТТЄВОГО ЦИКЛУ ІНФОРМАЦІЙНИХ СИСТЕМ Практично жоден серйозний проект зі створення АІСУП не здійснюється без використання САSЕ-засобів. САSЕ (Computer-Aided Software / System Engineering) являє собою сукупність ме-тодологій аналізу, проектування, розробки і супроводження склад¬них програмних систем, підтриману комплексом взаємо-пов’я¬заних засобів автоматизації. САSЕ — це інструментарій для системних аналітиків, розробників і програмістів, що замінює їм папір і олівець комп’ютером для автоматизації процесу проекту-вання і розробки програмного забезпечення. Основна мета САSЕ полягає в тому, щоб відокремити почат-кові етапи (аналіз і проектування) від подальших етапів розроб-ки, а також не обтяжувати розробників усіма деталями середо-вища розробки і функціонування системи. Чим більший обсяг робіт буде винесений на етапи аналізу й проектування, тим кра-ще. Під час використання САSЕ трансформуються всі етапи життєвого циклу АІСУП, при цьому найбільші зміни стосуються етапів аналізу і проектування. Крім автоматизації методологій і, як наслідок, можливості за-стосування сучасних методів системної і програмної інженерії САSЕ мають такі основні переваги: 1) поліпшують якість системи, що створюється, за допо- могою засобів автоматичного контролю (передусім контролю проекту); 2) дозволяють за короткий час створювати прототип майбут-ньої системи, що дає змогу на ранніх етапах оцінити очікуваний результат; 3) прискорюють процес проектування і розробки; 4) звільняють розробника від рутинної роботи, дозволяючи йому цілком зосередитися на творчій частині розробки; 5) підтримують розвиток і супровід розробки; 6) підтримують технології повторного використання компо-нентів розробки. Зараз існує два покоління САSЕ. Засоби першого покоління призначені для аналізу вимог, проектування специфікацій і стру-ктури системи і є першою технологією, адресованою безпосеред-ньо системним аналітикам і проектувальникам. Вони включають засоби для підтримки графічних моделей, проектування специфі-кацій, редагування словників даних і концентрують увагу на по-чаткових кроках проекту — системному аналізі, визначенні ви-мог, системному проектуванні, логічному проектуванні БД. Засо¬би другого покоління призначені для підтримки повного життєвого циклу розробки. В них насамперед використовуються засоби підтримки автоматичної кодогенерації, а також забезпечується повна функціональна підтримка для створення графічних системних вимог і специфікацій проектування; контролю, аналізу і зв’язування системної інформації, а також інформації щодо управління проектуванням; побудови прототипів і моделей системи; тестування, верифікації і аналізу згенерованих програм; генерації документів з проекту; контролю на відповідність стандартам по всіх етапах ЖЦ. Нижче стисло характеризуються основні функціональні мож-ливості САSЕ-засобів. 1) Спільна графічна мова. САSЕ забезпечує всіх учасників проекту (в тому числі й замовників) спільною мовою, наочною, строгою та інтуїтивно зрозумілою. Це дозволяє залучати замовника до процесу розробки, спілкуватися з експертами предметної області, захищати проект перед керівництвом, поділити діяльність системних аналітиків, проектувальників і програмістів, а також забезпечувати легкість супроводження і внесення змін у цільову систему: Графічна орієнтація САSЕ полягає в тому, що програми є двовимірними схемами, набагато простішими у використанні, аніж описи на кілька сторінок. 2) Загальна БД проекту. Основа САSЕ — це використання БД-проекту (репозитарію) для зберігання всієї інформації про проект, яка може розподілятися між розробниками відповідно до їхніх прав доступу. Зміст репозитарію включає не тільки об’єкти різних типів, але і відносини між їх компонентами, а також правила використання або опрацювання цих компонен- тів. Репозитарій може зберігати понад 100 типів об’єктів, при-кладами яких є діаграми, визначення екранів і меню, проекти звітів, описи даних, логіка опрацювання, моделі даних, моделі підприємства, моделі опрацювання, початкові коди, елементи даних і т. ін. 3) Інтеграція засобів. На основі репозитарію здійснюються інтеграція САSЕ-засобів і розподіл системної інформації між розробниками. При цьому можливості репозитарію забезпечують кілька рівнів інтеграції: загальний інтерфейс користувача по всіх засобах, передачу даних між засобами, інтеграцію етапів розробки через єдину систему подань фаз ЖЦ, передачу даних і засобів між апаратними платформами. 4) Підтримка колективної розробки й управління проек-том. САSЕ підтримує групову роботу над проектом за допомо-гою засобів роботи в мережі, експорту-імпорту будь-яких фра-гментів проекту для розвитку і/або модифікації, а також плану-вання, контролю, управління, взаємодії, тобто функцій, необ-хідних для розробки і супроводження проектів. Ці функції також реалізуються на основі репозитарію. Зокрема, через репозитарій може здійснюватися контроль безпеки (обмеження доступу, привілеї доступу), контроль версій, контроль змін тощо. 5) Прототипування. Важливу роль в автоматизації ранніх етапів ЖЦ відіграють можливості підтримки прототипування. САSЕ дозволяє будувати швидкі прототипи системи, що дає змо-гу на ранніх етапах розробки оцінити, наскільки майбутня систе-ма влаштовує замовника і наскільки «дружня» вона майбутньому користувачеві. 6) Генерація документації. Вся документація з проекту ге-нерується автоматично на базі репозитарію (як правило, на базі вимог відповідних стандартів). Безперечна перевага САSЕ по-лягає в тому, що документація завжди відповідає поточному стану справ, оскільки будь-які зміни в проекті автоматично відбиваються в репозитарії. Відомо, що за традиційних під- ходів до розробки АІСУП документація щонайбільше запізню-ється, а ряд модифікацій взагалі не знаходить у ній відобра-ження. 7) Верифікація проекту. САSЕ забезпечує автоматичну верифікацію і контроль проекту на повноту і спроможність на ранніх етапах розробки, що впливає на успіх розробки в цілому. 8) Автоматична кодогенерація. Кодогенерація здійснюється на основі репозитарію і дозволяє автоматично побудувати близь-ко 80—90% об’єктних кодів або текстів програм мовами високо-го рівня. При цьому різними САSЕ-пакетами підтримуються практично всі відомі мови програмування, однак найчастіше як цільові мови виступають СОВОL, C і АDА. 9) Супроводження і реінжиніринг. Супроводження системи в межах САSЕ характеризується тим, що супроводжується про-ект, а не програмні коди. Засоби реінжинірингу і реверсного ін-жинірингу дозволяють продукувати схеми системи з її кодів та інтегрувати отримання схеми в проект, автоматично оновлювати документацію під час заміни кодів, автоматично змінювати спе-цифікації при редагуванні кодів і т. ін. СУЧАСНІ ЗАСОБИ СТВОРЕННЯ АВТОМАТИЗОВАНИХ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ НА ПІДПРИЄМСТВАХ 3.1. АВТОМАТИЗОВАНІ ІНФОРМАЦІЙНІ ТЕХНОЛОГІЇ, ЇХ РОЗВИТОК І КЛАСИФІКАЦІЯ Створення і функціонування інформаційних систем в управлінні економікою тісно пов’язані з розвитком інформаційної технології — головної складової частини автоматизованих інформаційних систем (АІС). Автоматизована інформаційна технологія (АІТ) — систем-но організована для вирішення задач управління сукупність методів і засобів реалізації операцій збору, реєстрації, передачі, на¬копичення, пошуку, опрацювання і захисту інформації на базі застосування розвинутого програмного забезпечення, засобів обчислювальної техніки і зв’язку, а також способів, за допомогою яких інформація пропонується клієнтам. Всезростаючий попит в умовах ринкових відносин на інформацію й інформаційні послуги зумовив те, що сучасна технологія опрацювання інформації орієнтована на застосування досить широкого спектра технічних засобів, і насамперед електронних обчислювальних машин і засобів комунікацій. На основі їх створюються обчислювальні системи і мережі різних конфігурацій не тільки для накопичення, збереження, переопрацювання інформації, а й для максимального наближення термінальних пристроїв до робочого місця фахівця або керівника, що приймає рішення. Це є досягненням багаторічного розвитку АІТ. З появою і широким розвитком ЕОМ і периферійної техніки настала ера «комп’ютерної» інформаційної технології, яка в своєму розвиткові пройшла три етапи. Перший етап (1950—1960 рр.), що характеризується використанням великих (для того часу) ЕОМ, у своїй основі був зорієнтований на економію машинних ресурсів. Концепція інформаційної технології полягала в тому, що все, що можуть робити люди, вони повинні робити; центральний процесор виконував лише ту частину роботи з опрацювання інформації, яку люди принципово виконувати не могли, наприклад масові розрахунки. Основне завдання інформаційної технології можна сформулювати як підвищення ефективності опрацювання даних на підставі використання формалізованих алгоритмів. Для другого етапу (1960—1970 рр.) визначальним став широкий випуск малих машин (міні-ЕОМ). Оскільки вартість апаратних засобів (машинних ресурсів) істотно знизилась, то метою інформаційної технології стала економія праці програмістів, тобто необхідно було підвищити ефективність програмування, зокрема за рахунок автоматизації програмних розробок. Докорінно змінилась концептуальна орієнтація: все, що можна запрограмувати, повинні робити машини, люди ж зобов’язані виконувати лише те, що не може бути запрограмоване Третій етап інформаційної технології (1970—1990 рр.), відомий під назвою нової (сучасної, безпаперової) інформаційної технології, характеризується масовим випуском персональних електронно-обчислювальних машин (ПЕОМ). Визначальною метою стала економія праці користувачів. Основу нової інформаційної технології становлять розподілена комп’ютерна техніка, «дружнє» програмне забезпечення, розвинуті комунікації. Концепція третього етапу: автоматизувати можна все, що люди спро¬можні описати (програмування без програмістів). Тому централь¬ним завданням технології програмування стала розробка інст- рументальних засобів, які полегшують професіоналам-непрог-рамістам процес самостійної формалізації їхніх індивідуальних знань. Розвиток ринкових відносин сприяв появі нових видів підприємницької діяльності, і насамперед створенню фірм, зайнятих інформаційним бізнесом, розробкою інформаційних технологій, удосконалюванням їх, поширенням компонентів АІТ, зокрема програмних продуктів, що автоматизують інформаційні й обчислювальні процеси. До числа їх відносять також обчислювальну техніку, засоби комунікацій, офісне устаткування і специфічні види послуг — інформаційне, технічне і консультаційне обслуговування, навчання тощо. Це сприяло швидкому поширенню й ефективному використанню інформаційних технологій в управлінських і виробничих процесах, практично привело до повсюдного застосування їх і великого різноманіття. Зараз АІТ можна класифікувати за рядом ознак, зокрема: за способом реалізації в АІС, ступенем охоплення АІТ задач керування, за класами реалізованих технологічних операцій, типом користувацького інтерфейсу, варіантами використання мережі ЕОМ, предметною областю, що обслуговується (рис. 3.1). Рис. 3.1. Класифікація автоматизованих інформаційних технологій на підприємствах За способом реалізації АІТ в АІС виділяють традиційно сформовані й нові інформаційні технології. Якщо традиційні АІТ існували насамперед в умовах централізованого опрацювання даних, до масового використання ПЕОМ були орієнтовані головним чином на зниження трудомісткості під час формування регулярної звітності, то нові інформаційні технології пов’язані з інформаційним забезпеченням процесу керування в режимі реаль¬ного часу. Нова інформаційна технологія — це технологія, що ґрунтується на застосуванні комп’ютерів, активній участі користувачів (непрофесіоналів у сфері програмування) в інформаційному процесі, високому рівні «дружнього» користувацького інтерфейсу, широкому використанні пакетів прикладних програм загального і проблемного призначення, доступі користувача до віддалених баз даних і програм завдяки обчислювальним мережам ЕОМ. За ступенем охоплення АІТ задач керування виділяють елек-т¬ронне опрацювання даних, коли з використанням ЕОМ без пе- регляду методології та організації процесів управління ведеться опрацювання даних із рішенням окремих економічних задач, і автоматизацію управлінської діяльності. У другому випадку обчислювальні засоби, включаючи суперЕОМ і ПЕОМ, використовуються для комплексного вирішення функціональних задач, формування регулярної звітності і роботи в інформаційно-довід¬ковому режимі для підготування управлінських рішень. До цієї ж групи можуть бути віднесені АІТ підтримки прийняття рішень, що передбачають широке використання економіко-математичних методів, моделей і ППП для аналітичної роботи і формування прогнозів, упорядкування бізнес-планів, обґрунтованих оцінок і висновків щодо досліджуваних процесів, явищ виробничо-госпо¬дарської практики. До названої групи належать і широко впроваджувані зараз АІТ, що одержали назву електронного офісу й експертної підтримки рішень. Ці два варіанти АІТ орієнтовані на використання останніх досягнень у сфері інтеграції новітніх підходів до автоматизації роботи фахівців і керівників, створення для них якнайсприятливіших способів виконання професійних функцій, якісного і своєчасного інформаційного обслуговування завдяки повному автоматизованому набору управлінських процедур, реалізованих в умовах конкретного робочого місця й офісу в цілому. Електронний офіс передбачає наявність інтегрованих пакетів прикладних програм, які включають спеціалізовані програми й інформаційні технології, що забезпечують комплексну автоматизацію задач предметної області. Зараз дедалі більшого поширення набувають електронні офіси, устаткування і працівники яких можуть знаходитися в різних помешканнях. Необхідність роботи з документами, матеріалами, базами даних конкретної організації або улаштування в домашніх умовах, у готелі, транспортних засобах привела до появи АІТ віртуальних офісів. Такі АІТ ґрунтуються на роботі локальної мережі, з’єднаної з територіальною або глобальною мережею. Завдяки цьому абонентські системи працівників установи незалежно від того, де вони знаходяться, виявляються включеними в загальну для них мережу. Автоматизовані інформаційні технології експертної підтримки є основою автоматизації праці фахівців-аналітиків. Ці працівники, крім аналітичних методів і моделей для дослідження ситуацій, що складаються в ринкових умовах, із збуту продукції, послуг, фінансового стану підприємства, фірми, фінансово-кредит¬ної організації, змушені використовувати накопичений і такий, що зберігається в системі, досвід оцінки ситуацій, тобто зведення, що складають базу знань у конкретній предметній області. Опрацьовані за певними правилами, такі зведення дозволяють підготовляти обґрунтовані рішення для поводження на фінансових і товарних ринках, виробляти стратегію в галузях менеджменту і маркетингу. За класами реалізованих технологічних операцій АІТ розглядаються, по суті, в програмному аспекті і включають: текстове опрацювання, електронні таблиці, автоматизовані банки даних, опрацювання графічної і звукової інформації, мультимедійні та інші системи. Перспективним напрямом розвитку комп’ютерної технології є створення програмних засобів для виводу високоякісного звуку і відеозображення. Технологія формування відеозображення дістала назву комп’ютерної графіки. Комп’ютерна графіка — це створення, збереження й опрацювання моделей об’єктів та їхніх зображень за допомогою ЕОМ. Ця технологія застосовується в економічному аналізі, моделюванні різного роду конструкцій, у рекламній діяльності, є практично незамінною у виробництві, а також робить цікавим дозвілля. Програмно-технічна організація обміну з комп’ютером текстової, графічної, аудіо- та відеоінформації одержала назву мультимедіа-технології. Таку технологію реалізують спеціальні програмні засоби, що мають вбудовану підтримку мультимедіа і дозволяють використовувати її у професійній діяльності, на-вчально-освітніх, науково-популярних та ігрових сферах. За типом користувацького інтерфейсу можна розглядати АІТ із погляду можливостей доступу користувача до інформаційних і обчислювальних ресурсів. Так, пакетна АІТ виключає можливість впливу користувача на опрацювання інформації, поки воно здійснюється в автоматичному режимі. Це пояснюється організацією опрацювання, що засноване на виконанні програмно-заданої послідовності операцій над заздалегідь накопиченими в системі й об’єднаними у пакет даними. На відміну від пакетної діалогова АІТ дає користувачеві необмежену можливість взаємодіяти з інформаційними ресурсами, що зберігаються у системі, в реальному масштабі часу, одержуючи при цьому всю необхідну інформацію для вирішення функціональних задач і прийняття рішень. Інтерфейс мережної АІТ дає користувачеві засоби теледоступу до територіально розподілених інформаційних та обчислювальних ресурсів завдяки розвинутим засобам зв’язку, що робить такі АІТ широко використовуваними і багатофункціональними. Зараз спостерігається тенденція до об’єднання різних типів інформаційних технологій у єдиний комп’ютерно-технологічний комплекс, що зветься інтегрованим. Особливе місце в ньому належить засобам комунікації, які забезпечують не тільки надзвичайно широкі технологічні можливості автоматизації управлінської діяльності, але й є основою створення найрізноманітніших мережних варіантів АІТ — локальних, багаторівневих, розподілених, глобальних обчислювальних мереж, електронної пошти, цифрових мереж інтегрального обслуговування. Всі види орієнтовані на технологічну взаємодію сукупності об’єктів, утворених пристроями передачі, опрацювання, накопичення і збереження даних, являють собою інтегровані комп’ютерні системи опрацювання даних великої складності, практично необмежених експлуатаційних можливостей для реалізації управлінських процесів в економіці. Інтегровані комп’ютерні системи опрацювання даних проектуються як складний інформаційно-технологічний і програмний комплекс. Він підтримує єдиний спосіб подання даних і взаємодії користувачів із компонентами системи, забезпечує інформаційні й обчислювальні потреби фахівців у професійній роботі. Потреба в аналітичній роботі під час переходу до ринку в умовах перебудови економічних відносин, утворення нових організаційних структур, що функціонують на основі різних форм власності, незмірно зростає. Виникає необхідність у накопиченні фактів, досвіду, знань у кожній конкретній галузі управлінської діяльності. Переважає зацікавленість у ретельному дослідженні конкретних економічних, комерційних, виробничих ситуацій з метою оперативного прийняття економічно обґрунтованих і найприйнятніших рішень. Це завдання вирішується подальшим удосконаленням інтегрованого опрацювання інформації, коли нова інформаційна технологія починає включати в роботу бази знань. Під базою знань мається на увазі складна і така, що детально моделюється, структура інформаційних сукупностей, які описують усі особливості предметної області, включаючи факти (фактичні знання), правила (знання розумів для прийняття рішень) і метазнання (знання про знання), тобто знання, що стосуються способів використання знань та їхніх властивостей. База знань є найважливішим елементом часто створюваної на робочому місці фахівця експертної системи, що виступає в ролі накопичувача знань у конкретній галузі професійної діяльності і порадника фахівцеві під час аналізу економічних ситуацій і вироблення керуючих впливів. 3.2. АВТОМАТИЗОВАНЕ РОБОЧЕ МІСЦЕ — ЗАСІБ АВТОМАТИЗАЦІЇ РОБОТИ КІНЦЕВОГО КОРИСТУВАЧА НА ПІДПРИЄМСТВІ Діяльність працівників сфери управління (бухгалтерів, фахівців кредитно-банківської системи, плановиків і т. ін.) зараз орієнтована на використання розвинутих технологій. Організація і реалізація управлінських функцій вимагає радикальної зміни як самої технології управління, так і технічних засобів опрацювання інформації, серед яких головне місце посідають персональні комп’ютери. Вони дедалі більше перетворюються із систем автоматичного переопрацювання вхідної інформації у засоби накопичення досвіду управлінських працівників, аналізу, оцінки й вироблення якнайефективніших економічних рішень. Тенденція до посилення децентралізації управління тягне за собою розподілене опрацювання інформації з децентралізацією застосування засобів обчислювальної техніки й удосконаленням організації безпосередніх робочих місць користувачів. Автоматизоване робоче місце (АРМ) можна визначити як сукупність інформаційно-програмно-технічних ресурсів опрацювання даних, що забезпечують кінцевому користувачеві автоматизацію управлінських функцій у конкретній предметній області. Створення автоматизованих робочих місць припускає, що основні операції з накопичення, збереження і переопрацювання інформації покладаються на обчислювальну техніку, а користувач виконує частину ручних операцій і операцій, що вимагають творчого підходу у підготуванні управлінських рішень. Персональна техніка застосовується користувачем для контролю виробничо-господарської діяльності, зміни значень окремих параметрів у ході рішення задачі, а також уведення вихідних даних в АІС для вирішення поточних задач та аналізу функцій управління. АРМ як інструмент для раціоналізації й інтенсифікації управлінської діяльності створюється для забезпечення виконання певної групи функцій. Найпростішою функцією АРМ є інформаційно-довідкове обслуговування. Хоча ця функція тією або іншою мірою властива будь-якому АРМ, особливості її реалізації істотно залежать від категорії користувача. АРМ мають проблемно-професійну орієнтацію на конкретну предметну область. Професійні АРМ є головним інструментом спілкування людини з обчислювальними системами, відіграю- чи роль автономних робочих місць, інтелектуальних терміна- лів великих ЕОМ, робочих станцій і локальних мереж. АРМ мають відкриту архітектуру і легко адаптуються до проблемних областей. Локалізація АРМ дозволяє здійснити оперативне опрацювання інформації відразу з її надходженням, а результати опрацювання берегти як завгодно довго за вимогою користувача. В умовах реалізації управлінського процесу метою впровадження АРМ є посилення інтеграції управлінських функцій, і кожне більш-менш «інтелектуальне» робоче місце повинне забезпечувати роботу в багатофункціональному режимі. АРМ виконують децентралізоване одночасне опрацювання економічної інформації на робочих місцях виконавців у складі розподіленої бази даних (БД). При цьому вони мають вихід через системний пристрій і канали зв’язку в ПЕОМ і БД інших користувачів, забезпечуючи в такий спосіб спільне функціонування ПЕОМ у процесі колективного опрацювання. АРМ, створені на базі персональних комп’ютерів, — найпростіший і найпоширеніший варіант автоматизованого робочого місця для працівників сфери організаційного управління. Таке АРМ розглядається як система, що в інтерактивному режимі роботи дає конкретному працівникові (користувачеві) усі види забезпечення монопольно на весь сеанс роботи. Цьому відповідає підхід до проектування такого компонента АРМ, як внутрішнє інформаційне забезпечення, відповідно до якого інформаційний фонд на магнітних носіях конкретного АРМ повинен перебувати в монопольному розпорядженні користувача АРМ. Користувач сам виконує усі функціональні обов’язки з перетворення інформації. Створення АРМ на базі персональних комп’ютерів забезпе-чує: • простоту, зручність і «дружність» стосовно користува-ча; • простоту адаптації до конкретних функцій користувача; • компактність розміщення і невисокі вимоги до умов експлуатації; • високу надійність і живучість; • порівняно просту організацію технічного обслуговування. Ефективним режимом роботи АРМ є його функціонування в межах локальної обчислювальної мережі як робочої станції. Це є особливо доцільним тоді, коли потрібно розподіляти інформаційно-обчислювальні ресурси між декількома користувачами. Більш складною формою є АРМ із використанням ПЕОМ як інтелектуального термінала, а також із віддаленим доступом до ресурсів центральної (головної) ЕОМ або зовнішньої мережі. У даному разі декілька ПЕОМ підключаються по каналах зв’язку до головної ЕОМ, при цьому кожна ПЕОМ може працювати і як самостійний термінальний пристрій. У найскладніших системах АРМ можуть через спеціальне устаткування підключатися не тільки до ресурсів головної ЕОМ-мережі, але й до різних інформаційних служб і систем загального призначення (служб новин, національних інформаційно-пошу¬кових систем, баз даних і знань, бібліотечних систем тощо). Можливості створюваних АРМ значною мірою залежать від техніко-експлуатаційних характеристик ЕОМ, на яких вони базуються. З огляду на це на стадії проектування АРМ чітко формулюються вимоги до базових параметрів технічних засобів опрацювання і видачі інформації, наборів комплектуючих модулів, мережних інтерфейсів, ергономічних параметрів пристроїв і т. ін. Синтез АРМ, вибір його конфігурації й устаткування для реальних видів економічної й управлінської роботи мають конкретний характер, що зумовлюється спеціалізацією, поставленими цілями, обсягами роботи. Однак будь-яка конфігурація АРМ повинна відповідати загальним вимогам щодо організації інформаційного, технічного, програмного забезпечення. Інформаційне забезпечення АРМ орієнтується на конкретну, звичну для користувача, предметну область. Опрацювання документів повинно припускати таку структуризацію інформації, яка дозволяє здійснити необхідне маніпулювання різними структурами, зручне і швидке коригування даних у масивах. Технічне забезпечення АРМ має гарантувати високу надійність технічних засобів, організацію зручних для користувача режимів роботи (автономний, з розподіленою БД, інформаційний, із технікою верхніх рівнів і т. ін.), спроможність опрацювати в заданий час необхідний обсяг даних. Як індивідуальний користувацький засіб, АРМ має забезпечувати високі ергономічні властивості й комфортність обслуговування. Програмне забезпечення орієнтується насамперед на професійний рівень користувача, поєднується з його функціональними потребами, кваліфікацією і спеціалізацією. Користувач з боку програмного середовища повинен відчувати постійну підтримку свого бажання працювати в будь-якому режимі активно або пасивно. Пріоритет користувача в роботі з технікою є очевидним. Тому за їхньої взаємодії передбачається максимальне забезпечення зручностей роботи людини завдяки удосконаленню програмних засобів. АРМи можна розглядати як «архітектурні» елементи у створенні автоматизованих інформаційних технологій та систем на економічних об’єктах. Наприклад, спрощено інформаційну систему виробничого підприємства можна подати як сукупність відповідних АРМів (рис. 3.2). Рис. 3.2. Інформаційна система підприємства як сукупність АРМів 3.3. СУЧАСНІ ЗАСОБИ ПОБУДОВИ КОМП’ЮТЕРНИХ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ НА ПІДПРИЄМСТВАХ 3.3.1. Комп’ютерні мережі Розвиток засобів обчислювальної техніки, а особливо поява персональних комп’ютерів сприяли створенню нового типу інформаційно-обчислювальних систем під назвою локальні обчислювальні мережі (ЛОМ). ЛОМ широко застосовуються у системах автоматизованого проектування і технологічної підготовки виробництва, системах управління виробництвом і технологічними комплексами, в конторських системах, бортових системах управління тощо. ЛОМ є ефективним способом побудови складних систем управління різ¬ними виробничими підрозділами. ЛОМ інтенсивно впроваджуються в медицину, сільське господарство, освіту, науку та ін. Локальна мережа (LAN — Local Area Network) — це об’єднан¬ня комп’ютерів, розташованих на порівняно невеликій території (одного підприємства, офісу, однієї кімнати). Існуючі стандарти для ЛОМ забезпечують зв’язок між комп’ютерами на відстані від 2,5 км до 6 км (Ethernet і ARCNET відповідно). По суті ЛОМ — це набір апаратних засобів і алгоритмів, які забезпечують з’єднання комп’ютерів, інших периферійних пристроїв (принтерів, дискових контролерів і т. ін.) і дозволяють їм спільно використати загальну дискову пам’ять, периферійні пристрої, обмінюватися даними. Зараз інформаційно-обчислювальні системи прийнято ділити на три основні типи: — LAN (Loсal Area Network) — локальна мережа в межах під-приємства, установи, однієї організації; — MAN (Metropolitan Area Network) — міська або регіональна мережа, тобто мережа в межах міста, області тощо; — WAN (Wide Area Network) — глобальна мережа, що з’єднує абонентів країни, континенту, всього світу. Інформаційні системи, в яких засоби передачі даних належать одному підприємству і використовуються тільки для потреб цього підприємства, прийнято називати Мережа Масштабу Підприємства або Корпоративна Мережа (Enterprise Network). Для автоматизації роботи виробничих підприємств часто використовуються системи на базі протоколів MAP/TOP: 1) MAP (Manufacturing Automation Protocol) — мережа для ви-робничих підприємств, заводів (виконується автоматизація робо-ти конструкторських відділів і виробничих та технологічних це-хів). MAP дозволяє створити єдиний технологічний ланцюжок від конструктора, що розробив деталь, до обладнання, на якому виготовляють цю деталь. 2) TOP (Technical and Office Protocol) — протокол автоматизації технічної і адміністративної установи. 3) MAP/TOP — системи, що повністю автоматизують роботу виробничого підприємства. Основне призначення ЛОМ — у розподілі ресурсів ЕОМ: про-грам, сумісності периферійних пристроїв, терміналів, пам’яті. Отже, ЛОМ повинна мати надійну і швидку систему передачі да-них, вартість якої має бути меншою порівняно з вартістю робо-чих станцій, що підключаються. Іншими словами, вартість оди-ниці інформації, що передається, повинна бути значно нижчою за вартість опрацювання інформації в робочих станціях. Виходячи з цього ЛОМ як система розподілених ресурсів повинна заснову-ватися на таких принципах: • єдиного передавального середовища; • єдиного методу управління; • єдиних протоколів; • гнучкої модульної організації; • інформаційної і програмної сумісності. Залежно від способу організації опрацювання даних і взаємо-дії користувачів, який підтримується конкретною мережною опе-раційною системою, виділяють два типи інформаційних систем: — ієрархічні мережі; — мережі «клієнт—сервер». В ієрархічних мережах усі задачі, пов’язані із зберіганням, опрацюванням даних, їх поданням користувачеві, виконує цент-ральний комп’ютер. Користувач взаємодіє з центральним ком-п’ютером за допомогою термінала. Операціями введення / виве-дення інформації на екран управляє центральний комп’ютер. Переваги ієрархічних систем: ? відпрацьована технологія забезпечення надійності та збере-ження даних; ? надійна система захисту інформації і забезпечення секрет-ності. Недоліки: ? висока вартість апаратного і програмного забезпечення, ви-сокі експлуатаційні витрати; ? залежність швидкодії і надійності мережі від центрального комп’ютера. У системах «клієнт—сервер» опрацювання даних поділене між двома об’єктами: клієнтом і сервером. Клієнт — це задача, робоча станція, користувач. Він може сформувати запит для сер-вера: відкрити файл, здійснити пошук запису тощо. Сервер — це пристрій або комп’ютер, що виконує опрацювання запиту. Він відповідає за зберігання даних, організацію доступу до цих даних і передачу даних клієнтові. У системах «клієнт—сервер» наван-таження з опрацювання даних розподілене між клієнтом і сер- вером, тому вимоги до продуктивності комп’ютерів, що використовуються як клієнт і сервер, значно нижчі, ніж в ієрархічних системах. За організацією взаємодії прийнято виділяти два типи систем, що використовують метод «клієнт—сервер»: — рівноправна мережа; — мережа з виділеним сервером. Рівноправна мережа — це мережа, в якій немає єдиного цен-тру управління взаємодією робочих станцій, немає єдиного при-строю зберігання даних. Операційна система такої мережі розпо-ділена по всіх робочих станціях, тому кожна робоча станція одночасно може виконувати функції як сервера, так і клієнта. Користувачеві в такій мережі доступні всі пристрої (принтери, жорсткі диски тощо), підключені до інших робочих станцій. Переваги: низька вартість (використовуються всі комп’ютери, підключені до мережі) і помірні ціни на програмне забезпечення для роботи мережі; висока надійність (за виходу з ладу однієї ро-бочої станції доступ припиняється лише до деякої частини ін-формації). Недоліки: робота мережі є ефективною тільки тоді, коли од-ночасно працюють не більш як 10 станцій; труднощі організації ефективного управління взаємодією робочих станцій і забезпе-чення секретності інформації; труднощі оновлення і зміни про-грамного забезпечення робочих станцій. Мережа з виділеним сервером — у цьому випадку один із комп’ютерів виконує функції зберігання даних загального корис-тування, організації взаємодії між робочими станціями, виконан-ня сервісних послуг — сервер мережі. На такому комп’ютері розміщена операційна система, і всі пристрої (жорсткі диски, принтери, модеми тощо) підключаються до нього, він виконує зберігання даних, друк завдань, вилучення та опрацювання зав-дань. Робочі станції взаємодіють через сервер, тому логічну ор-ганізацію такої мережі можна подати топологією «зірка», де цен-тральний пристрій — сервер. Переваги: вища швидкість опрацювання даних (визначається швидкодією центрального комп’ютера, і на сервер встановлюєть-ся спеціальна мережна операційна система, розрахована на опра-цювання і виконання запитів, що надійшли одночасно від декіль-кох користувачів); володіє надійною системою захисту інфор-мації і забезпечення секретності; простіша в управлінні порівняно з рівноправними. Недоліки: така мережа дорожча через окремий комп’ютер під сервер; менш гнучка порівняно з рівноправною. 3.3.2. Інтегровані технології у розподілених системах опрацювання даних Різноманіття комп’ютерних мереж і форм взаємодії ПЕОМ породжує нагальну проблему інтеграції їх або принаймні з’єднан¬ня на рівні обміну повідомленнями. У розподілених системах використовують три інтегровані технології. 1. Технологія «клієнт—сервер». 2. Технологія спільного використання ресурсів у межах гло-бальних мереж. 3. Технологія універсального користувацького спілкування у вигляді електронної пошти. Основна форма взаємодії ПК у мережі — це «клієнт—сервер». Зазвичай один ПК у мережі володіє інформаційно-обчислю¬вальними ресурсами (як-от: процесори, файлова система, поштова служба, служба друку, бази даних), а решта ПК користуються ними; як зазначалося, комп’ютер, що управляє тим або іншим ресурсом, прийнято називати сервером цього ресурсу, а комп’ютер, що бажає ним скористатися, — клієнтом. Якщо ресурсом є бази даних, то говорять про сервер баз даних, призначення якого — обслуговувати запити клієнтів, пов’язані з опрацюванням даних; якщо ресурс — файлова система, то ведуть мову про файловий сервер, або файл-сервер, і т. ін. Технологія «клієнт—сервер» стає більш поширеною, але реа-лізація технології в конкретних програмних продуктах істотно розрізняється. Один із основних принципів технології «клієнт—сервер» по-лягає в поділі операцій опрацювання даних на три групи, що ма-ють різну природу. Перша група — це введення і відображення даних. Друга група об’єднує прикладні операції опрацювання да-них, характерні для рішення задач даної предметної області. На-решті, до третьої групи належать операції збереження й управ-ління даними (базами даних або файловими системами). Відповідно до цієї класифікації в будь-якому технологічному процесі можна виділити програми трьох видів: • програми подання, що реалізують операції першої групи; • прикладні програми, що підтримують операції другої групи; • програми доступу до інформаційних ресурсів, що реалізу-ють операції третьої групи. Відповідно до цього виділяють три моделі реалізації техноло-гії «клієнт—сервер»: 1. Модель доступу до віддалених даних (Remote Data Access — RDA). 2. Модель серверу бази даних (DatаBase Server — DBS). 3. Модель серверу додатків (Application Server — AS). У RDA-моделі програми подання і прикладні програми об’єд-нані й виконуються на комп’ютері-клієнті, що підтримує як опе-рації введення і відображення даних, так і прикладні операції. Доступ до інформаційних ресурсів забезпечується або операто-рами мови SQL (Structured Query Language — у системах управ-ління базами даних (СУБД) — мова запитів), якщо йдеться про бази даних, або викликами функцій спеціальної бібліотеки. Запи-ти до інформаційних ресурсів спрямовуються по мережі до від-даленого комп’ютера, наприклад серверу бази даних, що опра-цьовує запити і повертає клієнтові необхідні для опрацювання блоки даних (рис. 3.3). Рис. 3.3. Модель доступу до віддалених даних DBS-модель будується за припущення, що програми, викону-вані на комп’ютері-клієнті, обмежуються введенням і відобра-женням, а прикладні програми реалізовані в процедурах бази да-них і зберігаються безпосередньо на комп’ютері-сервері бази даних разом із програмами, що управляють, і доступом до даних — ядра СУБД (рис. 3.4). Рис. 3.4. Модель серверу бази даних На практиці часто використовуються змішані моделі, коли підтримка цілісності бази даних і найпростіші операції опрацю-вання даних підтримуються збереженими процедурами (DBS-модель), а більш складні операції виконуються безпосередньо прикладною програмою, що виконується на комп’ютері-клієнті (RDA-модель). В AS-моделі програма, що виконується на комп’ютері-клієнті, вирішує задачу введення і відображення даних, тобто реалізує операції першої групи. Прикладні програми виконуються одним або групою серверів додатків (віддалений комп’ютер або декіль-ка комп’ютерів). Доступ до інформаційних ресурсів, необхідний для вирішення прикладних задач, забезпечується так само, як і в RDA-моделі, — прикладні програми забезпечують доступ до ре-сурсів різних типів — бази даних, індексованих файлів, черг та ін. В основу RDA- і DBS-моделей покладена дволанцюгова схема поділу операцій. В AS-моделі реалізована трьохланцюгова схема поділу операцій, де прикладна програма виділена як найважливіша (рис. 3.5) (АРІ — Application Program Interface — системне програмне забезпечення з набором функцій та ресурсів для побудови інтерфейсу). Рис. 3.5. Модель серверу додатка Головна перевага RDA-моделі зводиться до того, що вона яв-ляє собою велику кількість інструментальних засобів, які забез-печують швидке створення додатків, що працюють із SQL-орієн-тованими СУБД. Іншими словами, основне достоїнство RDA-моделі полягає в уніфікації та широкому виборі засобів розробки додатків. Переважна більшість цих засобів розробки мовами чет-вертого покоління, включаючи й засоби автоматизації програму-вання, забезпечує розробку прикладних програм і операцій по-дання. Незважаючи на значне поширення, RDA-модель поволі посту-пається місцем більш технологічній DBS-моделі. Остання реалі-зована в деяких реляційних СУБД (Ingres, SyBase, Oracle). У DBS-моделі додаток є розподіленим. Програми подання ви-конуються на комп’ютері-клієнті, тимчасом як прикладні про-грами вирішення задач оформлені як набір збережених процедур і функціонують на комп’ютері-сервері БД. Переваги DBS-моделі перед RDA-моделлю очевидні: це і можливість централізованого адміністрування рішення економічних задач, і зниження напру-женості, і можливість поділу процедури між декількома додатка-ми, і економія ресурсів ПК завдяки використанню заздалегідь створеного плану виконання процедури. Основним елементом прийнятої в AS-моделі трьохланцюгової схеми є сервер додатка. Він реалізує кілька прикладних функцій, кожна з яких оформлена як служба і надає послуги всім програ-мам, що бажають і можуть ними скористатися. Серверів додатків може бути декілька, і кожен із них дає певний набір послуг. Будь-яка програма, що користується ними, розглядається як клієнт додатка. Деталі реалізації прикладних програм у сервері додатків цілком сховані від клієнта додатка. AS-модель має універсальний характер. Чітке розмежування логічних компонентів і раціональний вибір програмних засобів для їх реалізації забезпечують моделі такий рівень гнучкості й відкритості, що поки є недосяжним у RDA- і DBS-моделях. 3.3.3. Глобальні комп’ютерні мережі Протягом останнього десятиліття дедалі ширший розвиток отримують глобальні обчислювальні й інформаційні мережі — унікальний симбіоз комп’ютерів і комунікацій. Відбувається ак-тивне приєднання всіх країн до всесвітніх мережних структур. Світовою системою комп’ютерних комунікацій щодня користую-ться більш як 30 млн людей. Зростає потреба в засобах структу-рування, накопичення, збереження, пошуку і передачі інформації. Задоволенню цих потреб служать інформаційні мережі та їхні ресурси. Спільне використання ресурсів мереж (бібліотек програм, баз даних, обчислювальних потужностей) забезпечується технологічним комплексом і засобами доступу. Глобальні мережі (Wide Area Netwstrky WAN) — це телеко- мунікаційні структури, що об’єднують локальні інформаційні мережі, які мають загальний протокол зв’язку, методи підклю-чення і протоколи обміну даними. Кожна з глобальних мереж (INTERNET, BITNET, DECNET і ін.) організовувалася для певних цілей, а надалі розширювалася завдяки підключенню локаль¬них мереж, що використовують її послуги і ресурси. Найбільшою глобальною інформаційною мережею є INTERNET. 3.3.3.1. Архітектура INTERNET У 1994 році виповнилось 25 років комп’ютерній мережі INTERNET — глобальній всесвітній мережі інформаційного об-міну, яка об’єднує кілька мільйонів людей із більш ніж 100 країн світу за допомогою сучасних і зручних засобів зв’язку. Архітектура мережі INTERNET розроблена на основі концеп-ції взаємопоєднуваності або міжмережного поєднання різнорід-них мереж, побудованих на базі різних фізичних систем зв’язку і комунікаційних технологій. Користувачі мережі INTERNET повинні мати доступ до ре-сурсів кожної підмережі, яка входить до INTERNET. Такий до-ступ має бути забезпечений внутрішніми механізмами (адресами, форматами повідомлень, протоколами) INTERNET. Користувачеві при цьому надаються прості, зручні й прозорі, тобто незалеж¬ні від особливостей підмереж, засоби роботи з кожними мережними компонентами INTERNET. Користувач взагалі не повинен знати, як організована взаємодія мереж, які шлюзи і які маршрути забезпечують доставку інформації. INTERNET спроектована як інтермережа, тобто певна абстра-кт¬на сукупність різнорідних мереж. Загальними для всіх підмереж INTERNET є: ? універсальний адресний простір мережі INTERNET; ? набір комунікаційних протоколів ТСР/ІР і пов’язаних з ними протоколів; ? шлюзи і технологія міжмережної маршрутизації пові- домлень. Архітектурна топологія INTERNET. Окремі мережі поєд-нуються між собою шлюзовою машиною, яка реалізує фізичні поєднання (рис. 3.6, 3.7). Шлюзи зберігають таблиці, в яких фік-суються адреси приєднаних до даного шлюзу мереж. Важливо зазначити, що система адресування мереж і машин INTERNET має чітку ієрархічну структуру, що дозволяє обмежити табличні записи шлюзів тільки адресами мереж, тобто не зберігати адреси хост-машин (головних ЕОМ). Завдяки цьому шлюзи можуть збе-рігати свої таблиці в основній пам’яті й бути реалізованими на бездискових мікрокомп’ютерах. Рис. 3.6. Приклад поєднання двох мереж Рис. 3.7. Приклад міжмережних поєднань за допомогою шлюзів G і Н Адресація INTERNET. Основний принцип адресації — універсальний ідентифікатор хост-машини INTERNET. Кож- ній хост-машині, яка входить до INTERNET, призначається у відповідному реєстраційному центрі універсальний адресний ідентифікатор — 32-бітова адреса. Структура цієї адреси та- ка, що всі хости даної підмережі мають загальний адресний префікс. Адреса хосту мережі INTERNET — це пара чисел (netid, hostid): netid — ідентифікатор мережі; hostid — ідентифікатор хост-машини в цій мережі. Використовують три класи форматів адрес: 0 7 8 31 клас А netid hostid 0 15 16 31 клас В netid hostid 0 0 23 24 31 клас С netid hostid Клас А визначає множину адрес для великих мереж, тобто та-ких мереж, де кількість хост-машин може перевищити 32768. Клас В призначений для середніх за кількістю хостів мереж, і клас С відводить тільки 8 біт для адреси хосту, що відповідає відносно невеликим мережам. Таким чином, адреса в INTERNET не прив’язана до конкрет-ної машини, а ідентифікує деяке поєднання з мережею. Це озна-чає, що якщо дана машина «переїжджає» до нової мережі, її ад-реса повинна змінитися. Друга властивість цієї адресації — машина, яка входить у кілька мереж, повинна мати декілька ад-рес. На практиці ця властивість означає, що машину можна знайти по мережі INTERNET, навіть якщо якась мережа не пра-цює і відомі інші мережні адреси цієї машини. Адреси INTERNET видаються централізовано. Локальним мережам у межах INTERNET видаються звичайно адреси кла- су С. Мережам типу ARPANET видаються адреси класу А. За INTERNET-угодою, якщо поле hostid дорівнює 0, то відповідна адреса ідентифікує мережу, а не хост; якщо ж поле hostid дорів-нює 1, то така адреса використовується для мультиадресної пе-редачі повідомлень. 3.3.3.2. Правила роботи в INTERNET Щоб виконати процедуру реєстрації, адміністрація хост-машини або нової мережі повинна: ? отримати унікальну мережну ІР-адресу, яка видається DDN Net-Work Information Center або іншим реєстраційним агентством, і сконфігурувати хост-машини мережі для використання з виданою ІР-адресою; ? утворити домен; ? визначити характер взаємодії з INTERNET (дослідницьке застосування, комерційне та ін.); ? визначити обчислювальну установку (хост-машину або шлюз) для фізичного підключення; ? встановити необхідні технічні й програмні засоби (адапте-ри каналів, модеми, програми ТСР/ІР); ? встановити необхідні шлюзові програми, які забезпечать маршрутизацію, і відповідні протоколи; ? одержати від Міністерства зв’язку або фірми-поста-чальника ліній зв’язку необхідні канали, тарифи на їх ви- користання та інші умови експлуатації канального устаткування. Регіональний центр видає тільки мережну частину адреси. Право видачі адрес для окремих хостів мережі делегується адмі-ністрації мережі, яка підключається до INTERNET відповідно до загальних правил Доменної Системи Імен (DNS). Ієрархія доменів, тобто адресованих частин INTERNET, утво-рює Єдину для INTERNET систему імен мереж і хост-машин. Утворення нового домену в мережі INTERNET означає, що ім’я цього домену буде включене в розподільну базу даних адрес, які використовуються протоколом розв’язання адрес при виборі маршруту передачі повідомлень. Зазначимо, що в DDN NIC (центральна організація, яка здійс-нює реєстрацію хост-машин США та інших країн) і RIPE NCC (Європейський мережний координаційний центр) реєструються тільки домени верхнього рівня, більша частина доменів другого рівня і деякі домени третього рівня. Домени верхнього рівня визначають цільові класи (табл. 3.1) Група літер наприкінці адреси INTERNET є доменом, який вказує, з яким типом комп’ютера встановлюється зв’я¬зок. Сім доменів, які трапляються найчастіше, наведено у табл. 3.1. Таблиця 3.1 Домен Використання домену com Комерційні, підприємницькі організації edu Освітні заклади (університети, середні школи тощо) gov Державні організації (крім військових) mil Військові організації (армія, флот і т. ін.) net Системи базової мережі int Міжнародні організації org Інші організації та установи Для кожного з цих доменів призначається адміністратор до-мену, який володіє повноваженнями реєстрації мереж, що нале-жить до цього домену. Уся інформація про мережні домени зберігається в DNS у формі Ресурсних Записів. Інтерактивна програма «розпізнавач/ сервер» звертається до DNS у режимі «запит—відповідь» і одер-жує потрібні дані про домени, а також про мережі і хост-машини, які до них входять. Адресна інформація знаходиться в окремих базах даних, розміщених у декількох хост-машинах. 3.3.3.3. Способи доступу до INTERNET Передача даних у мережі організована на основі протоколу INTERNET—IP (INTERNET Protocol), що являє собою опис ро-боти мережі та включає правила налагодження і підтримки зв’язку в мережі, поводження з IP-пакетами та їх опрацювання, описи мережних пакетів сімейства IP. Мережа спроектована та-ким чином, що користувач не має жодної інформації про конкре-т¬ну структуру мережі. Щоб послати повідомлення мережею, комп’ютер розміщує дані в «конверт», який має назву, наприклад IP, із указівкою конкретної адреси мережі. Вузлові машини мережі здійснюють передачу поштових пові-домлень і новин між регіонами і поширення повідомлень на своїй території. Користувацькі персональні машини під керуванням операційних систем UNIX або MS DOS використовують для спілкування з регіональними вузлами протокол UUCP. Розгляньмо види доступу в порядку убування їхньої вартості. 1) Безпосередній (прямий) доступ. Забезпечує доступ до всіх можливостей мережі. Безпосередній доступ пропонує найбільш гнучке підключен-ня. Кожний із комп’ютерів є повноправним членом мережі і може скористатися будь-якою із її функцій. Для обслуговування й експлуатації свого вузла будуть по-трібні персонал і документація. Це збільшує експлуатаційні витрати. 2) Доступ через протоколи канального рівня INTERNET — SLIP і РРР. SLIP і РРР є версіями програмного забезпечення INTERNET, що працюють на звичайних телефонних лініях, ви-користовуючи стандартні високошвидкісні модеми. SLIP і РРР також підходять для підключення до глобальної мережі маленької (до п’яти користувачів) локальної мережі. 3) Доступ «за викликом» (Dial-up Access). Системи з ко- мутованим доступом — найпоширеніший шлях до ресурсів INTERNET для невеликих груп і індивідуальних користува- чів. У цих системах використовуються ресурси чужого ком-п’ютера. Багато організацій надають цей вид послуг за певну плату на місяць. 4) Доступ по стандартних телефонних лініях через UNIX, UUCP. Усі системи UNIX підтримують метод, який має назву UUCP та дозволяє пересилати дані по стандартних телефонних лініях. 5) Доступ через інші мережі, що входять у глобальну мережу. Доступ через інші мережі можна розглянути на прикладі онлайнових систем DELPHI і ВІХ. DELPHI дає повноцінний доступ до INTERNET, електронну пошту, передачу файлів і віддалений доступ до інших комп’ютерів. Це перший випадок, коли велика, орієнтована на споживача онлайнова система дала доступ у INTERNET із таким великим набором послуг. Система забезпечує не тільки шлюзи електронної пошти, а й пряме підключення до всіх можливостей INTERNET. 3.3.3.4. Ресурси INTERNET Оскільки INTERNET пропонує розмаїття методів комунікації і способів доступу до інформації, для значної кількості компаній вона швидко стає невід’ємною частиною їхньої інформаційної системи. Проаналізуймо основні засоби і служби, що їх пропонує INTERNET (рис. 3.8). Рис. 3.8. Логічна схема глобальної мережі INTERNET Електронна пошта. Ця служба найширше використовується INTERNET — 94% корпорацій мають доступ до мережі. Вона забезпечує постійний зв`язок між працівниками самої компанії і дозволяє підтримувати ділові контакти поза її межами. Цей вид послуг дає змогу компаніям здійснювати свої повсякденні кон-такти з іншими організаціями та клієнтами. Порівняно з фак- симільними засобами зв’язку електронна пошта є відносно де-шевою. World Wide Web (WWW) — найновітніша на сьогодні ін-формаційна служба INTERNET, яка дуже швидко розвиваєть- ся. Вона має майже безмежний потенціал збору, поширення і вивчення інформації. Цей графічний інструментальний засіб на основі гіперсередовища набуває дедалі більшої популярності у підприємств, яким необхідно збирати інформацію, обмінюва- тися ідеями і самим пропонувати комерційну інформацію в ІNTERNET. Система World Wide Web вперше була розроблена Тімом Бернерсом Лі з Європейської лабораторії фізики елементарних часток у Женеві (Швейцарія) як спосіб організації інформації для її наукових співробітників. Інформація на Web-серверах зберігає-ться у вигляді набору документів. Кожен документ вміщує гіпер-текстові посилання, за допомогою яких користувач може зверта-тися до інформації в інших документах, пов`язаних з даною темою. Таким чином, вибираючи підсвічені слова, виділені зо-браження і графіку в тексті документа, користувач має змогу пе-реміщуватись у будь-якому напрямку і «перескакувати» на інші документи, які його зацікавили, незважаючи на те, де ці докумен-ти знаходяться. Така технологія дає змогу разом із текстом включати у Web-документи графіку, звук і відеозображення. Переміщуючись величезними масивами електронних документів, що зберігаються на тисячах серверів в INTERNET, користувачі, які розшукують конкретну інформацію, можуть фактично мандрувати по всьому світу. Для цього їм достатньо вибирати посилання в документах і таким чином переходити до потрібної інформації. Дедалі більше компаній починають усвідомлювати ті величезні переваги, які надає їм цей інструментальний засіб для реклами і продажу продукції. Будь-яке підприємство (велика корпорація, невелика фірма) може створити свій Web-вузол, підключившись до INTERNET на один чи декілька серверів. Завдяки онлайновому доступу такі підприємства отримують можливість розміщувати свої документи в World Wide Web, де вони стають доступними для кожного користувача. Уже в 1995 р. кількість WWW-серверів перевищила 100 тис. І кожного дня з’являються сотні нових Web-сторінок. Величезний обсяг і постійне оновлення інформації робить Web дуже корисним інструментом, наприклад, маркетингової діяльності на підприємстві. Він дає змогу отримувати відомості про нову продукцію, легко визначати, чим займаються конку¬ренти, досліджувати тенденції, дізнаватися про нові технології і матеріали тощо. Звичайно компанії починають використання потенціалу Web у рекламі розміщенням на Web-сторінках своїх поточних матеріа-лів — електронних копій друкованих каталогів і прайс-лис-тів, а також інформації про свою діяльність, стратегію під-приємства, свою продукцію. Крім того, підприємства через Web можуть повідомляти про вихід повідомлень у пресі і поширювати новини щодо своєї дія-льності. Розміщення поточних новин — дуже важливий елемент, який привертає увагу користувачів і примушує їх частіше зверта-тися до даного Web-вузла. Web є також дуже ефективним засобом збирання відомостей про покупців, тобто дає змогу застосовувати інтерактивні форми роботи з покупцями. Компанії також можуть відстежувати кількість користувачів, які «побували» на Web-сторінках, і таким чином щоденно контролювати, наскільки успішно діє даний інформаційний канал. Публікація на Web-вузлі адреси елект-ронної пошти компанії надає їй можливість ефективно забезпе-чувати користувачів онлайновою підтримкою і навіть сприяє продажу продукції: користувачі, які електронною поштою наді-слали запит на отримання більш докладної інформації, автома-тично включаються у наступний список розсилки відповідної інформації. На цих сторінках компанії публікують каталоги, прайс-листи, прес-релізи, доповіді представників фірми на різних конференці-ях і виставках, інтерв’ю, анкети для виявлення думки споживачів з того чи іншого питання, розміщують інформацію про фірму, її нову продукцію та послуги. File Transfer Protocol (FTP). Незважаючи на те, що найбіль-ший інтерес сьогодні викликають такі засоби INTERNET, як елект¬ронна пошта і World Wide Web, вона має чимало інших корисних інструментів. Один із них — File Transfer Protocol. Це стандартний механізм, який дає можливість користувачам передавати й отримувати файли з INTERNET. Gopher. Сервери Gopher — також дуже популярний засіб пошуку необхідної інформації. Вони містять каталоги інформації з різних тем. Користувач може порівняно легко знайти і про-читати файли, які є на будь-яких серверах INTERNET, оскільки особа, яка відповідає за певний сервер, здійснює пошук джерел відповідної інформації. Якщо користувач не може знайти спеці-алізований Gopher-сервер з інформацією, яка його цікавить, він може продовжити пошук за одним-двома словами, що належать цій галузі. Використання Gopher дає компанії можливість не тільки отримувати інформацію, необхідну для маркетингових досліджень, а й завдяки створенню приватного Gopher-серверу поширювати інформаційні матеріали про свої продукти чи по-слуги (проспекти, бюлетені, каталоги, прайс-листи). Якщо ком-панія включає в меню свого серверу електронну картку замов-лення, то це дає клієнтам можливість безпосередньо замовляти той чи інший товар. Новини і спеціальні групи за інтересами. Задовго до появи World Wide Web користувачі INTERNET обмінювалися між со-бою новинами та ідеями через групи новин USENET — розподі-лену (в масштабі INTERNET) дошку оголошень. Вона налічує понад 5 тис. постійно підтримуваних конференцій — груп новин, що охоплюють найрізноманітніші теми, і має близько 10 млн ко-ристувачів, наприклад Novell.tech-forum (група новин, за допомогою якої покупці фірми Novell можуть одержати онлайнову підтримку і дізнатися про нові програмні продукти цієї фірми). Групи новин надають компаніям широкі можливості для реклами і просування продуктів і послуг через INTERNET. Нині більш як 35% усіх повідомлень USENET є спеціально підготовленими для поширення в мережі рекламними повідомленнями. Mailling lists. Технологія Mailling lists, або списків розсилки, дає змогу поширювати (розсилати) повідомлення, використову-ючи файл (список розсилки), що вміщує електронні адреси ко- ристувачів, які бажають отримувати інформацію з певної теми і мають на комп’ютері програму електронної пошти. Нині в INTERNET існує більше сотні тисяч списків розсилки з різнома-нітних тем. Механізм Mailling lists дає змогу клієнтам вибирати та отримувати потрібну інформацію, а фірмам, що постачають продукцію та послуги, — створювати і підтримувати свої списки розсилки, за допомогою яких вони можуть підтримувати постійні контакти з клієнтами, реєструвати їхні звернення і проводити опитування. Фірми можуть також одержувати інформацію від експертів, адреси яких занесені у відповідні списки розсилки. Підприємці мають можливість приєднуватися до різних списків розсилки для того, щоб постійно отримувати інформацію з певних питань, що стосуються сфери їхньої діяльності. Завдяки величезному потенціалу для бізнесу, що його має Mailling lists, це і сьогодні — один із найважливіших інструментів маркетингу в INTERNET. 3.3.4. Електронна пошта на базі стандарту Х.400 Комп’ютерні системи почали використовуватися як середо-вище для зв’язку між людьми з середини 70-х років. Однією з перших мереж такого роду була мережа ARPA. В цей же час Hitz i Turoff почали свої експерименти з дослідження можливостей комп’ютерного зв’язку між людьми на базі Електронних Інформаційних Систем Обміну (ЕIES), які були попередниками сучасних систем опрацювання повідомлень типу DIALKOM, GEOMAIL, KOMECX, UNIX MAIL, USENET і комп’ютерних систем телеконференцій типу BLEND, COM, FORUM. З часом стало зрозуміло, що комп’ютерні системи для обміну текстовою інформацією між людьми повинні забезпечити зв’язок користувачів не тільки в межах локальної модемної структури, а й взаємодіяти з іншими системами опрацювання повідомлень. Перші спроби показали, що для індивідуальних систем цю проб-лему можна вирішити за допомогою шлюзів. Проте велика різ-номанітність систем опрацювання вимагала створення значної кількості шлюзів. Тому постало питання кардинального вирі-шення цієї проблеми через розробку універсальних стандартів для комп’ютерних систем опрацювання повідомлень. Роботи в цьому напрямку були розпочаті в 1979 р. Міжнародною федера-цією опрацювання Інформації (IFIP) і підтримані Міжнародною координаційною комісією з Телеграфії і Телефонії (МККТТ), а також — паралельно — Міжнародною організацією стандартиза-ції (МОС). У 1984 р. в Червоній книзі МККТТ подав першу версію стан-дартів з комп’ютерних систем обміну інформацією між людьми, які отримали назву системи опрацювання повідомлень — Реко-мендації МККТТ серії Х.400. 1988 року розширена версія Рекомендацій серії Х.400 була опублікована в Блакитній книзі МККТТ як спільний стандарт МККТТ і МОС. Основною метою рекомендацій цієї серії було визначення концепцій, архітектури, протоколів і служб транспортування тек-с¬тових повідомлень між незалежними системами з різними технологіями передачі й доставки повідомлень. Системи транспортування повідомлень між людьми за допо-могою комп’ютерів відомі під назвою електронної пошти. Далі будемо брати до уваги, що термін «електронна пошта» (ЕП) сто-сується прикладного аспекту систем опрацювання повідомлень взагалі, а не тільки по МККТТ Х.400. В ЕП транспортна служба має справу з файлами, які опрацьовуються комп’ю¬терами, а не з паперами, які транспортуються за допомогою різних технічних засобів (машини, потяги, літаки), як це має місце в класичних поштових системах. З урахуванням цього ЕП визначили як служ-бу поштового зв’язку, в якій доставка повідомлень здійснюється електронними методами за допомогою комп’ютерів. Для корис-тувачів ЕП — це цілком нова служба зв’язку, яка забезпечує більш надійне і якісне обслуговування порівняно із звичайною поштовою службою. Стандарт Х.400 — це стандарт електронного обміну пові-домленнями, що має універсальне значення для організації рі-зних прикладних систем: електронної пошти, служб передачі повідомлень EDIFACT, служб обміну документами на підпри-ємствах. 3.3.4.1. Принципи електронного обміну комерційними та фінансовими даними Традиційна паперова документація, методи її опрацювання і пересилання за допомогою звичайної пошти спричиняються до великих виробничих і комерційних витрат. Експерти оцінюють вартість опрацювання і ведення паперової документації у 3,5—7,0% загальної вартості комерційних операцій і доставки товарів. Виграш від застосування електронного обміну даними (ЕОД) оцінюється, наприклад, у автомобільній промисловості США більш ніж у 200 доларів на один виготовлений автомобіль. В табл. 3.2 наведена загальна традиційна схема поставки товару, яка включає 11 операцій: 1 — запит ціни, умов поставки (телефоном або листом-запитом); 2 — контрактна пропозиція, котирування на біржі (поштою); 3 — видавання замовлення; 4 — постачальник організує внутрішні замовлення; 5 — готується ві-домість комплектування; 6 — комплектування і пакування; 7 — відправка товару; 8 — сповіщення про поставку; 9 — виставлян-ня фактур-накладних; 10 — виставляння рахунка; 11 — оплата. Таблиця 3.2 Фаза Замовник (клієнт) Постачальник Пояснення 1 Запит ціни і умов поставляння Лист-запит або телефон-ні переговори 2 Контрактна пропозиція Лист-запит або телефон-ні переговори 3 Видавання замовлення Лист-запит або форма за¬мовлення (можливе у ком¬п’ютерному вигляді) 4 Видача внутрішніх замовлень Внутрішня технологія 5 Підготовка відомості комплектування Внутрішня технологія 6 Комплектування і пакування 7 Відправка товару 8 Сповіщання про поставку Комп’ютерна форма 9 Виставляння фактур-накладних Комп’ютерна форма 10 Виставляння рахунка Комп’ютерна форма 11 Оплата З цієї схеми видно, що постачальник і замовник, взаємодіючи, обмінюються запитами, повідомленнями, торговельними і поста-чальницькими документами, фінансовими рахунками і квитанці-ями. Цілком ясно, що електронний обмін документами має великі переваги щодо оперативності, достовірності й надійності обміну. Електронний обмін даними (ЕОД) — це міжкомп’ютерний обмін діловими, комерційними та фінансовими електронними документами, наприклад замовленнями, платіжними інструкція-ми, контрактними пропозиціями, накладними, квитанціями. ЕОД забезпечує оперативну взаємодію торговельних партне-рів (клієнтів, постачальників, торговельних посередників, експе-диторів та ін.) на всіх етапах підготовки торговельної угоди, укладання контракту і реалізації поставки. ЕОД для комерційних цілей (ЕОКД) може на етапі оплати контракту і переказу грошових коштів взаємодіяти із службою електронного обміну фінансовими документами (ЕОФД). Така взаємодія ЕОКД і ЕОФД створює для покупців (клієнтів) ефекти-вне середовище під час виконання усіх торговельно-платіжних операцій: • он-лайн — перегляд каталогів торговельних пропозицій, то-варів і послуг на ринку; • вибір в інтерактивному режимі потрібного товару/послуги, уточнення умов (вартості й термінів поставляння, торговельних знижок, гарантійних і сервісних зобов’язань); • он-лайн замовлення товару/послуги або запит контрактної пропозиції, погодження і укладання контракту; • оперативний контроль поставляння товару; • одержання за допомогою електронної пошти супровідних документів (накладних, фактур, комплектуючих відомостей то-що); • підтвердження завершення поставляння товару/послуги, ви-ставляння і оплата рахунків; • виконання банківсько-кредитних і платіжних операцій. Для реалізації цих операцій користувачі служби ЕОД повинні використовувати термінальні станції, модеми або адаптери стан-дарту Х.25, відповідні телекомунікаційні програми. Для забезпечення надійної передачі великих обсягів даних не-обхідні виділені лінії зв’язку, програмне забезпечення передачі файлів, електронної пошти і підключення до мережі Х.25. Потрі-б¬ні також засоби захисту даних від несанкціонованого доступу. Історія виникнення і розвитку ЕОД веде свій відлік від почат-ку 80-х років, коли несумісність окремих фірмових технологій опрацювання комерційних даних не дозволяла інтегрувати їх у єдину систему, яка б забезпечила комплексну механізацію між-народних торговельних операцій. У 1983—1985 рр. міжнародні організації ООН (UN/ECE i ІSO) почали розробку процедур, форматів даних і міжнародних кодо-вих систем для ЕОД. Була створена міжнародна робоча група UN/ECE, яка в жовтні 1988 р. оприлюднила першу версію між- народного стандарту United Nations Eleсtronic Data Interсhange for Administration, Commerce and Transport — UN/EDIFACT (ООН/Електронний обмін даними для адміністрації, торгівлі і транспорту). B EDIFACT були виділені чотири основні компоненти, які підлягають стандартизації при підготовці документів для переда-чі по каналах телекомунікацій. Це елементи даних (data ele-ments), стандартні групи елементів даних (standart data seg-ments), стандартні повідомлення (standart messages) і правила створення форматів документів (syntax rules). Таким чином, був розроблений набір синтаксичних правил і комерційних елементів, який отримав скорочену назву EDIFACT і був оформлений у вигляді двох стандартів ISO: ISO 7372 — Trade Data Element Directory (Довідник комер-ційних елементів даних). ISO 9735 — Appliсаtion Level Syntaх rules (Правила синтакси-су на користувацькому рівні). Стандарти EDIFACT розроблялись для використання у гло-бальних комп’ютерних мережах з широким колом користува-чів — державними установами, виробниками товарів, виробів і послуг, дистриб’ютерами, брокерами, транспортними експедиторами, банками, страховими компаніями та ін. Головними цілями створення і використання EDIFACT було визнано: • визначення стандартних за синтаксисом і семантикою пові-домлень, які відповідають міжнародним стандартам; • заміна звичайних паперових форм і документів електронни-ми документами і відповідними методами їх опрацювання; • прискорення документообігу і, відповідно, оперативності опрацювання комерційних і фінансових трансакцій; • створення для малих, середніх і великих фірм більш сприят-ливих і рівних умов ринкової конкуренції; • поліпшення умов для підготовки і здійснення торговельних угод; • більш широке і масове використання клієнтами сучасних комп’ютерних мереж та їх послуг. На базі стандарту EDIFACT у 1987—1990 рр. інтенсивно розвивається інфраструктура електронного обміну даними. Процес обміну електронними документами підтримується різними комп’ютер¬ними і комунікаційними технологіями, до числа яких входять: — комп’ютерні робочі станції для підготовки електронних до-кументів, контролю вхідних даних і виходу на мережі передачі даних; — бази даних, які містять комерційні й фінансові дані, котирування, класифікатори продукції, дані про постачальників і ринки; — інтерактивні інформаційні системи (системи опрацювання замовлень, біржові інформаційні служби, банки даних, відеотекс тощо); — електронна пошта, системи опрацювання повідомлень, га-лузеві й проблемно-орієнтовані системи EDIFACT, системи об-міну фінансовими документами. Інформаційні й телекомунікаційні системи забезпечують для своїх користувачів комплекс послуг з опрацювання й видачі до-відкових даних, комерційних звітів, замовлень і торговельних пропозицій, рахунків і платіжних квитанцій. Усі ці послуги надаються як прикладні служби (Value additional Services), що створюються технологіями електронного обміну даними. На сучасному етапі розрізняють такі основні ви-ди прикладних служб: 1. Он-лайнові бази даних (ОЛБД) — бази даних, доступні в оперативному режимі з терміналів користувачів; он-лайнові БД цілодобово відкриті для діалогового пошуку інформації і видачі довідок та різних статистичних звітів; користувачами ОЛБД мо-жуть бути спеціалісти комерційних і фінансових організацій, економісти, дилери, постачальники, агенти фінансових і торгове-льних організацій. 2. Електронна пошта (EP — Electronic Post) — система об-міну й опрацювання повідомлень (сукупність електронних пош-тових скриньок, програмних засобів опрацювання, збереження і передачі повідомлень, термінальних станцій для підготовки і введення повідомлень). Користувачі ЕП можуть проводити між-персональний обмін повідомленнями, розсилати повідомлення за списками адрес, затребувати свої повідомлення з поштових скриньок, організовувати проблемні телеконференції та виконувати інші функції опрацювання повідомлень (електронних документів). 3. Електронна передача грошових коштів (EFT — Elect-ronic Funds Transfer) — система передачі фінансових (кредит-них, платіжних) документів між клієнтами і банками, між банка-ми, між банками та іншими фінансовими і комерційними органі-заціями. Міжнародна мережа обміну фінансовою інформацією SWIFT забезпечує багато функцій EFT. 4. Електронний обмін даними (EDI — Electronic Data Inter-сhange) — багатоцільова система обміну документами, які мають розвинуту структуру даних. Зазвичай реалізується на базі стандартних програмних і технічних засобів електронної пошти. 5. Управлінські мережні служби (Managed Network Servi-ces) — виконують різні виробничі, адміністративні й службові функції управління об’єктами, технологічними лініями, транс-портними системами і службовцями підприємств. Реалізуються на базі внутрішньофірмових мереж ЕОМ, розподілених між під-розділами фірми. 6. Телеметричні служби — система оперативного спостере-ження, дистанційного виміру і контролю за нерухомими і рухо-мими об’єктами. Бізнесмени, торговельні агенти, транспортні службовці, бан-ківські спеціалісти, адміністратори, економісти і бухгалтери ви-користовують здебільшого перші чотири служби ЕОД (ОЛБД, ЕР, EFT, ЕОІ). У використанні цих служб важливе значення ма-ють вимоги інтегральності послуг, єдиного мережного доступу (тобто підключення до комп’ютерних мереж за допомогою одно-го терміналу або ПЕОМ), максимально можливої надійності, простоти і комфортності процедур підготовки електронних до-кументів та їх телекомунікаційного опрацювання. Служби ЕОД мають використовуватися через загальнодоступні телефонні ме-режі або мережі передачі даних на базі стандарту Х.25. На сучасному етапі ЕОД діє або впроваджується практично в усіх країнах. Міжнародний статус стандарту EDIFACT сприяє тому, що його використання є обов’язковою умовою адекватного обміну даними із закордонними партнерами для всіх, без винятку, підприємств і організацій України, які здійснюють зовнішньоекономічну діяльність. Для широкого впровадження ЕОД в Україні треба організува-ти: • освоєння світової практики ЕОД, активне прилучення укра-їнських спеціалістів до роботи в міжнародних організаціях, при-йняття вітчизняних програм розвитку ЕОД; • публікацію стандартів ІSO, СCITT, UN/EDIFACT та інших, проведення навчальних курсів і вивчення зарубіжних систем ЕОД; • роботу зі створення базових телекомунікаційних служб (Х.400, он-лайнові бази даних); • координацію проектів з уніфікації торговельних і фінансо-вих процедур, стандартизації форм документів, елементів даних, найменувань організацій; • сполучення вітчизняних систем ЕОД з міжнародними і за-рубіжними фірмовими службами, створення пунктів доступу і шлюзових станцій для взаємообміну електронними документами з іноземними партнерами. 3.3.4.2. Структура даних EDIFACT. Загальні синтаксичні правила (стандарт ІSO — 9735) Повідомлення EDIFACT належать до прикладного (7-го) рівня еталонної моделі OSI/ІSO. Усі повідомлення мають уніфікований формат, який стандартно регламентує розташування управляю-чих полів і спеціальних знаків, сегментів даних, складені й прості значення елементів даних. У структурі повідомлень EDIFACT визначені такі загальні синтаксичні правила (рис. 3.10): а) два рівні кодування повідомлень: рівень А — 7-бітовий код відповідно до ISO 646; рівень В — 8-бітовий код у відповідності з ISO 8859 або ISO 6937; б) управляючий сегмент даних UNA править за ідентифікатор початку кожного блоку повідомлень. Сегмент UNA визначає також типи використовуваних у даному блоці розподільників (управляючих знаків) та їхнє функціональне значення; в) другим за UNA йде UNB — кореневий сегмент даних корис-тувача. У цьому сегменті вказується версія формату EDIFACT, організація, яка відповідає за супроводження даної версії. Також у сегменті UNB визначаються джерело й одержувач повідомлень, дата і час передачі повідомлень, дата погодження паролів та інша службова інформація; г) кожний набір (пакет) повідомлень користувача (набір фі-нансових, комерційних або адміністративних документів) почи-нається з третього сегмента UNG. Сегмент UNG є обов’язковим і містить інформацію про всі наступні повідомлення: джерело й отримувач набору повідомлень, класифікаційні індекси повідомлень тощо; д) кожне окреме повідомлення (документ) починається з сег-мента UNH, який є заголовком повідомлення. Заголовок повідо-млення містить його посилальний номер, тип повідомлення, но-мер версії або редакції; е) кожне повідомлення закінчується сегментом UNT — іден-тифікатором кінця повідомлення; у сегменті UNT дається інфор-мація про кількість сегментів у даному повідомленні, посилаль-ний номер повідомлення; ж) набір повідомлень закінчується сегментом UNE, у якому вказується кількість повідомлень, посилальний номер набору по-відомлень; з) блок повідомлень закінчується сегментом UNZ, у якому вказується кількість повідомлень або наборів повідомлень. Рис. 3.9. Ієрархічна структура повідомлень ЕDIFACT На рис. 3.9 наведена загальна ієрархія повідомлень і структурних елементів EDIFACT. Розподільники, які визначаються в сегменті UNA, можуть ма-ти, наприклад, такий вигляд (табл. 3.3): Таблиця 3.3 Позиція сегмента UNA Тип розподільника Розподіль-ник 1 Розподільник компонентів елементів даних : 2 Розподільник елементів даних + 3 Десяткова крапка . 4 Індикатор відміни синтаксису ? 5 Резерв для майбутнього використання 6 Розподільник сегментів , Деяке повідомлення може мати такий вигляд: UNA:+.?!UNB+UNOA:1+125252+251218+910106:1228+DA1!UNH Ідентичні за змістом сегменти (тобто сегменти з однаковими позначками) можуть отримувати різні значення за допомогою кваліфікаторів або кодів. Наприклад, якщо NAD — позначка ад-ресного сегмента, то в сегменті NAD+BY може міститись адреса покупця (BY — buyer), а в сегменті NAD+SE — адреса продавця (SE — seller). Поле з позначкою PFF (посилальний покажчик) міс-тить покажчик (наприклад BY або SE), який визначає значення полів у цьому сегменті. Наприклад, FII містить дані про банк і рахунок продавця, якщо RFF визначений як SE. Розроблені детальні довідники сегментів, кодів і кваліфікато-рів, довідники елементів даних, які визначають семантику пові-домлень EDIFACT. Наприклад, довідник елементів даних визначає основні платі-ж¬ні реквізити (табл. 3.4). Таблиця 3.4 Сегмент EД Значення EД Формат Код EД NAD Назва, поштова адреса Сим., 1...35 3945 BNK Назва банку, місто Симв., 1...17 3918 BNK Код за SWIFT Симв., 1...11 3957 PAT Строки платежу Симв., 1...35 4276 PAT Строки платежу, кодовані Симв., 1...17 4277 PAI Гарантія платежу, кодована Кодов., 2 4837 PAT Строки платежу, тип Кодов., 2 4839 У стандартному повідомленні визначаються чотири розділи даних: 1. Заголовок. 2. Позиційна секція. 3. Субпозиційна секція. 4. Секція підсумкових даних. До заголовка повідомлення включаються дані, які описують комерційний або фінансовий документ у цілому. Наприклад, для платіжного рахунка або накладної вказуються відомості про банк, вид валюти, дата платежу, ім’я і адреса платника, інформа-ція про сплату податку, дані про транспортування товару, дані про упаковку тощо. У заголовку сегментна група 1 містить загальну адресну ін-формацію про продавця або покупця: NAD — ім’я і адреса; LOC — ідентифікатор району (місцевості); PFF — посилальний покажчик; CTA — контактні дані (адреса, телефон); FII — інформація про фінансову організацію. На рис. 3.10 наведено приклад опису за допомогою стандарту EDIFACT такого комерційного документа, як рахунок. а) Бланк вхідного документа Сегмент EД Значення EД BGM — BEGINNING OF MESSAGE (ПОЧАТОК ПОВІДОМЛЕННЯ) NAD — NAME AND ADDRESS (НАЗВА ТА АДРЕСА) LIN — LINE ITEM (РЯДОК ТОВАРНА ПОЗИЦІЯ) MOA — MONETARY AMOUNT (ГРОШОВА СУМА) FTX — FREE TEXT (ВІЛЬНИЙ ТЕКСТ) б) Приклад подання вхідного документа у вигляді сегментів Рис. 3.10. Подання за допомогою стандарту EDIFACT документа (повідомлення) «Рахунок» ? Стандартні повідомлення Повідомлення — це набір сегментів у послідовності, яка зада-на в довіднику повідомлень. Повідомлення починається із заго-ловка повідомлення і закінчується кінцем повідомлення (службо-вими сегментами UNH і UNT). Довідник повідомлень — це перелік ідентифікованих заданих повідомлень, які описані й мають найменування. Кожному стандартному повідомленню надається ТИП — шестизначний ідентифікатор з латинських літер. Наприклад, INVOIС — рахунок, ORDERS — замовлення, CUSDEC — митна декларація. Цей ідентифікатор обов’язково вказується у службовому сегменті заголовка повідомлення UNH (елемент даних 0065 — an..6). Поряд з типом стандартне повідомлення характеризується ще й статусом (0, 1 або 2): • статус 0 — повідомлення, які пройшли стадію розробки; • статус 1 — повідомлення, які одержали право на експери-ментальне використання; • статус 2 — повідомлення, які рекомендуються для міжнаро-дного застосування. Статус повідомлення пов’язується з роком випуску, наприклад, експериментальне повідомлення (статус 1), яке опубліковане Робочою групою WP4 у 1991 р., матиме номер випуску 911 (три цифри). «Паспортні дані» кожного повідомлення вказуються в довідниках UNSM у тому вигляді, в якому вони обов’язково мали бути наявними в службовому сегменті UNH заголовка повідомлення. ? Довідники міжнародного стандарту Розробка і супроводження стандарту UN/EDIFACT здійснює-ться під контролем двох організацій: 1. Європейської економічної комісії ООН (UN/ECE), в рамках якої створена спеціальна (4-та) робоча група спрощення проце-дур міжнародної торгівлі (WP4). 2. Міжнародної організації з стандартизації (ISO), де функціо-нує спеціальний (154-й) технічний комітет, який займається до-кументами і елементами даних для адміністрації, комерції і вироб¬ництва (ТС 154). Робоча група WP4 здійснює розробку і супроводження стан-дарту UN/EDIFACT у вигляді двох основних складових — сис-тем довідників UNTDED і UNTDID. Довідник комерційних елементів даних UNTDED являє собою основу стандарту, він випускається під редакцією Європейської економічної комісії ООН UN/ECE і конференції ООН з торгівлі й розвитку UNSTAD. Міжнародною організацією із стандартизації (ISO) встановле-но, що розділи 1, 2, 3, 4 і 9 довідника UNTDED мають статус міжнародного стандарту. В п’ятому розділі UNTDED коди назв країн закріплені ISO 3166, а коди валют — ISO 4217. Довідник з обміну комерційними даними UNTDID являє собою повний комплект документації з стандарту. До нього включені: • Єдині правила ведення обміну даними по UN/EDIFACT — UNCID; • Керівні принципи розробки повідомлень UN/EDIFACT — MDG; • Синтаксичні правила UN/EDIFACT — ISO 9735; • Керівництво щодо застосування синтаксису UN/EDIFACT — SIG; • Довідник стандартних повідомлень — UNSM; • Довідник сегментів — UNEDSD; • Довідник складених елементів даних — UNEDCD; • Довідник елементів даних — UNEDED; • Довідник кодів — UNEDCL. Таким чином, довідник UNTDID включає в себе низку розді-лів, які мають статус стандарту ISO, а також містять нову інфор-мацію, необхідну для розробників і користувачів систем елект-ронного обміну даними на базі UN/EDIFACT. 3.3.4.3. Архітектура Х.400-систем Рекомендації МККТТ Х.400 визначають структуру функціо-нальної моделі Системи Опрацювання Повідомлень (СОП), опи-сують основні співвідношення між компонентами системи СОП, служби і протоколи. Модель має багатошарову структуру, подібну до цибулини. На рис. 3.11 подана модель системи СОП, яка відповідає рекомендаціям МККТТ Х.400 (1984 р.). Внутрішня частина системи, що отримала назву Системи Пересилки Пові-домлень (СПП), складається з вузлів — Агентів Пересилки Пові-домлень (АПП). Протоколи пересилки повідомлень між агентами АПП, а також протоколи вводу повідомлень до системи СПП і виводу з системи СПП розглядатимуться далі. Наступний шар складається з систем, що дістали назву Аген-тів Користувачів (АК). Ці системи є сполучним процесом між ко-ристувачем і системою СОП; виконують функції вводу повідом-лення від відправника в систему СОП і доставку повідомлення з системи СОП користувачеві, а також ряд функцій, які пов’язані з опрацюванням повідомлень. Сукупність шару АПП і шару аген-тів АК складає Систему Опрацювання Повідомлень (СОП). Рис. 3.11. Модель Системи Опрацювання Повідомлень відповідно до рекомендацій МККТТ Х.400 (1984 р.) Зовнішній шар системи СОП утворюється самими Користувачами (К), які застосовують систему СОП для обміну повідомленнями. Розгляньмо більш детально основні поняття, які використо-вуються для опису елементів моделі системи. Користувач, К (User), у контексті опису СОП може бути лю-диною або процесом. Агент користувача, АК (User Agent, UA), — прикладний про-цес, який забезпечує доступність служб Системи Пересилки По-відомлень для Користувача. Агент АК реалізується у вигляді прикладної програми, яка забезпечує створення, розміщення по-відомлень у системі СПП, прийом і архівацію повідомлень. Кож-ний агент АК (а отже, і Користувач) ідентифікується за допомо-гою адреси та імені (якщо звернутися за аналогіями до звичної для нас традиційної пошти, то можна вважати, що агент АК ви-конує функцію упакування повідомлення в конверт, заклеювання конверта, введення листа в поштову систему — процес розмі-щення у системі СПП, а також реалізує деякі додаткові процеду-ри для захисту і збереження листа). Агент АК може бути розмі-щений у робочій станції користувача або в комп’ютері, який знаходиться всередині системи СПП. Система Пересилки Повідомлень, СПП (Message Transfer Sys-tem, MTS), пересилає повідомлення від агента АК — Відправника — до агента АК — Отримувача. Повідомлення, які пересила-ються в системі СПП, можуть накопичуватись у проміжних вуз-лах — агентах АПП. Таким чином, у системі СПП, а отже, і в системі СОП, реалізується принцип комутації повідомлень на прикладному рівні незалежно від того, які протоколи передачі мають місце на нижніх рівнях еталонної моделі Всесвітньої орга-нізації Відкритих Систем (ВОС). Агент Пересилки Повідомлень АПП (Message Transfer Agent, MTA) є вузлом СПП і відповідає вузлу в системі традиційної по-ш¬ти, володіючи водночас функціональними можливостями. Агент АПП реалізує механізм комутації повідомлень, який включає приймання, накопичення, визначення маршруту подальшої передачі до інших об’єктів СПП. Агент АПП також перевіряє правильність формату і наявність помилок, а потім передає повідомлення до наступного вузла – агента АПП або до агента АК. Агент АПП — це комп’ютер з відповідною прикладною програмою. У рекомендаціях МККТТ Х.400 1988 р. модель була розширена, і в складі системи СОП з’явилися нові об’єкти — Блоки Доступу для так званих непрямих користувачів та Сховище Повідомлень. Модель 1988 р. подана на рис. 3.12. Рис. 3.12. Модель Системи Опрацювання Повідомлень відповідно до рекомендацій МККТТ Х.400 1988 р. Під непрямими маються на увазі користувачі, які зазвичай входять до складу інших телематичних служб (телекс, телетекс, факс тощо). За допомогою Блоків Доступу (БД) ці користувачі тепер отримують доступ до системи СОП. Спеціальний блок БД — Блок Доступу Фізичного Доставляння (БДФД) — встановлює зв’я¬зок системи СОП із традиційною системою поштового зв’язку. Рекомендації МККТТ Х.400 1988 р., визначаючи перехід від системи СОП до класичної поштової служби, враховують специфічні види поштового сервісу, як-от: рекомендовані листи, спеціальні режими доставляння і т. ін. Перехід від електронної системи СОП до поштової системи здійснюється одержанням твердої копії повідомлення. Особливу роль для користувача мають Сховища Повідомлень (СП). Враховуючи те, що персональний комп’ютер найширше застосовується користувачами як робоча станція, має обмежену пам’ять, а також те, що він може використовуватися для реаліза-ції агента АК або агента АПП, виникає необхідність у створенні буферних накопичувачів достатньої місткості, роль котрих віді-грають сховища СП. Багатошарова модель не передбачає жодних припущень від-носно способу фізичної реалізації різних об’єктів системи СОП. На рис. 3.13а відображено варіант реалізації агента АПП і двох агентів АК в одному комп’ютері. У цьому випадку користу-вачі можуть застосовувати дуже прості термінали, які мають тільки клавіатуру і дисплей. а б в Рис. 3.13. Способи фізичної реалізації опрацювання повідомлень На рис. 3.13б наведена система СОП на два комп’ютери, які розподіляють функції системи опрацювання повідомлень. У пер-шій частині знову агенти АК і агенти АПП суміщені в одному комп’ютері, що дозволяє користувачеві застосовувати простий термінал. Ліворуч система містить агента АПП і один або декілька сховищ СП. У цьому разі функції агента АК будуть реалізовані в терміналі користувача (ТК), який повинен виконувати функції опрацювання повідомлень. Для реалізації цих функцій треба використовувати персональний комп’ютер (ПК). На рис. 3.13в відображено варіант системи СОП, коли комп’ютерна система лівої частини системи СОП реалізує тільки функції агента АК (можливо, більше ніж одного). Система в пра-вій частині містить усі компоненти СОП — агента АПП, сховища СП і агента АК. Такий варіант дозволяє підключити до системи СОП різні класи терміналів. Наведені на рис. 3.13 варіанти не охоплюють усі можливі кон-фігурації системи СОП. Відображені тут структури можуть слу-жити лише ілюстрацією необмеженої кількості варіантів органі-зації системи СОП. 3.3.4.4. Впровадження UN/EDIFACT у діяльність підприємств (організацій) Стислий огляд змісту стандарту показує, що UN/EDIFACT — це сформульована певним чином мова подання комерційних до-кументів, яку доцільно використовувати для зв’язку підприємств із зовнішніми організаціями. Під зовнішніми організаціями тут маються на увазі бізнес-партнери, клієнти, суміжники і т. ін. Ось приклад з матеріалів Робочої групи WP4. Якщо дві ком-панії використовують власні внутрішньофірмові стандарти для подання електронних документів, то під час обміну інформацією їм буде потрібне подвійне перетворення форматів повідомлень (рис. 3.14). Рис. 3.14. Схема перетворення форматів для двох підприємств у різних країнах За збільшення кількості партнерів, які беруть участь в інфор-маційній взаємодії, кількість перетворень зростає згідно з форму-лою (рис. 3.15): С = N (N – 1), де С — кількість необхідних перетворень при використанні різ-них стандартів партнерами; N — кількість партнерів, які беруть участь в інформаційній взаємодії. Рис. 3.15. Графік зростання кількості перетворень форматів для 14 партнерів З рис. 3.16 видно, що ефективність використання UN/EDIFACT є тим вищою, чим більше партнерів обмінюється комерційною інформацією, тому що економічність використання каналів зв’яз¬ку і витрати, пов’язані з перетворенням форматів повідомлень, вищі при більших інформаційних потоках. Водночас немає сенсу вести мову про використання UN/EDIFACT абстрактно. Існують різні версії стандарту, тому на практиці номер версії і статус повідомлень, які використовуються, обов’яз¬ково вказуються в спеціальних угодах між партнерами («Угода про обмін даними»). На сучасному етапі термін UN/EDIFACT (або просто «EDI-FACT») трапляється в зарубіжних і вітчизняних публікаціях до-сить часто. Стандарт широко рекламується як перспективний засіб безпаперової технології. З посиланням на європейських експертів повідомляється про виграш у 50—60 млрд доларів у торговельних відносинах між США і Західною Європою при пе-реході на електронний обмін даними. Європейське співтоварист-во створило спеціальну робочу групу «TEDIS» для координації робіт з питань UN/EDIFACT. Преса інформує про введення еко-номічних санкцій «за подання документів не в стандарті EDI-FACT», виходячи з чого необхідно зробити висновок, що «фір-мам, які працюють на зовнішньому ринку, необхідно або освою-вати EDIFACT, або платити за кожний переклад документа в цей стандарт». Може скластися враження, що впровадження міжнародного стандарту не є актуальним для організацій, які не мають прямого зв’язку із зарубіжними партнерами. Адже вітчизняні підприємст-ва майже не використовують EDIFACT. Проте перехід на вико-ристання UN/EDIFACТ у межах окремого підприємства може бу-ти виправданим не тільки незалежно від виходу на зарубіжний ринок, а й у зв’язку із здійсненням автоматизації управління. Розробникам інформаційних систем управління рекомендується під час проектування власних баз даних використовувати готові структури і синтаксичні характеристики компонентів довідника комерційних елементів даних UNTDED. За виникнення потреб у зв’язках із зарубіжними партнерами це дозволить запобігти не-обхідності адаптації внутрішніх даних до вимог UN/EDIFACT. Якщо ж такої потреби не виникне, все одно краще використати розробки експертів ЄЕК ООН, ніж проектувати власні БД з уні-кальними структурами. Повномасштабне використання стандарту викликає необ-хідність наявності у кожного з учасників обміну комерційними повідомленнями відповідного програмно-апаратного комплексу (рис. 3.16). Рис. 3.16. Взаємодія UN/EDIFACT-транслятора і електронної пошти інформаційної системи підприємства ІСУ підприємства на підставі інформації, зосередженої в БД, за спеціальними запитами виконавців формує документи нале-жної форми. За необхідності пересилання документів суміжни-кам інформація передається трансляторові, який перетворює зміст документа в стандартне повідомлення UNSM, яке, в свою чергу, через електронну пошту передається по каналах зв’язку з кореспондентами. Слід звернути увагу на дві особливості цієї схеми. По-перше, припускається, що АСУ підприємства функціонує на основі «безпаперової технології»: як такі документи на блан-ках у межах підприємства для управлінської діяльності не вико-ристовуються. Разом з тим електронні документи у будь-якій встановленій формі формуються для зв’язку із зовнішніми корес-пондентами, а всередині підприємства враховуються і опрацьо-вуються безпосередньо. По-друге, безпосередньо перетворенням (трансляцією) з внут-рішнього стандарту підприємства в UN/EDIFACT і навпаки зай-мається окремий програмний комплекс — Конвертор, пов’язаний з власною БД довідників стандарту UN/EDIFACT. 3.3.5. Застосування штрихового кодування в інформаційних технологіях на підприємстві Штрихове кодування є одним із типів автоматичної іден-тифікації, що використовує метод оптичного зчитування ін-формації. Воно ґрунтується на принципі двійкової системи чис-лення: інформація запам’ятовується як послідовність 0 і 1. Широким лініям і широким проміжкам привласнюється логічне значення 1, вузьким — 0. У зв’язку з цим штрихове кодування є способом побудови коду за допомогою чергування широких і вузьких та темних і світлих смуг. Існують такі види штрихових кодів: UPC — універсальний товарний код; розроблений у США і застосовується в країнах Америки. EAN — товарний код; створений у Європі на базі UPC. Від-повідає назві Європейської асоціації товарної нумерації, що одержала в даний час статус міжнародної організації (EAN Inter-national). UCC/EAN — єдиний стандартизований штриховий код; ство-рений об’єднаними зусиллями організацій США і Канади (Uniform Code Council) і EAN International. EAN і UCC/EAN застосовуються в багатьох країнах світу, у тому числі й в Україні. Відповідно до видів розрізняють такі штрихові коди: UPC-12, EAN-13, EAN-14, EAN-8, UCC/EAN-128. UPC-12 є дванадцятирозрядним кодом. Структура коду: пер-ша цифра коду — знак системи нумерації; п’ять цифр — номер виробника, п’ять — код продукту; остання цифра є контрольною. Приклад коду UPC-12 поданий на рис. 3.17. Рис. 3.17. Приклад коду UPC-12 EAN-13 є тринадцятирозрядним кодом. Структура коду є та-кою: перші три цифри коду позначають зазвичай країну-вироб-ника, чотири цифри — код підприємства-виробника; потім п’ять цифр — код продукту; остання цифра є контрольною. Приклад коду EAN-13 поданий на рис. 3.18. У наведеному прикладі: 482 — код країни, 0000 — код вироб-ника, 19053 — код продукту, 4 — контрольне число. Рис. 3.18. Приклад коду EAN-13 EAN-8 є восьмирозрядним кодом; використовується для коду-вання малогабаритних упаковок. Структура коду є такою: перші три цифри коду позначають країну — виробника товару, чотири наступні цифри — код продукту, остання цифра є контрольною. Приклад коду EAN-8 поданий на рис. 3.19. Рис. 3.19. Приклад коду EAN-8 EAN-14 — чотирнадцятирозрядний код із прямокутним кон-туром. Він складається з 13 розрядів, що розташовуються за зна-ченням у тій самій послідовності, що і EAN-I3, і одного додатко-вого розряду. Цей додатковий розряд указується першим і відбиває специфіку упаковування цифрами від 1 до 8 (наприклад, 1 — групове упаковування, 2 — упаковування партій у контейнер і т. ін.). Основне призначення EAN-14 — ідентифікація транспортного упаковування. Приклад коду EAN-14 поданий на рис. 3.20. Рис. 3.20. Приклад коду EAN-14 Застосування штрихових кодів UPC-12, EAN-I3, EAN-14, EAN-8 регулюється міжнародними і національними організаціями. Зокрема, в Україні такою організацією є «Україна—ЮНІСКАН». Ця організація встановлює номери підприємств у кодах EAN-I3 і EAN-14 і номери продуктів у коді EAN-8. Код країни привласнюється EAN International. Використання кодів UCC/EAN-128 (Code 39) регулюється відповідними міжнародними і національними стандартами. Мета штрихового кодування інформації полягає у відбитті таких інформаційних властивостей товару, що забезпечують реальну можливість простежити за їхнім рухом до споживача, що пов’язано з підвищенням ефективності управління виробництвом. Необхідність упровадження штрихових кодів продиктована надзвичайно великим обсягом постачань, тобто величезною кількістю товарів (найменувань), що тягне за собою практично некерований потік інформації, територіальною розкиданістю взаємозалежних організацій і підприємств, недостатньою ін-формацією про властивості товару на його упаковці й у супро-відній документації, відсутністю в постачальників продукції достовірної і своєчасної інформації про надходження товару до покупця. Використання штрихових кодів забезпечує діяльність різних виробників і споживачів на єдиному товарному ринку завдяки використанню єдиного коду по всьому ланцюжку взаємозалеж-них партнерів, захист споживача від недобросовісності виробни-ків або продавців продукції, керування потоками інформації що-до запиту й у реальному масштабі часу на основі ідентифікації будь-якого об’єкта, а також обмін інформацією як усередині ор-ганізації, так і між організаціями за допомогою методів і засобів електронного обміну даними (ЕОД). Система штрихового кодування інформації являє собою сукупність виду штрихових кодів і технічних засобів нанесення на носії інформації, верифікації якості друку, зчитування з носіїв, а також попереднього опрацювання даних. Основними технічними засобами нанесення штрихових кодів на носії інформації (папір, плівка, що самоклеїться, метал, кераміка, текстильна полотнина, пластмаса, гума й ін.) є устат-кування для виготовлення майстер-фільмів (шаблонів штри- хових кодів), компактні друкувальні пристрої різного принципу дії. Верифікація, або контроль, якості друку штрихових кодів мо-же бути здійснена спеціалізованим устаткуванням, оснащеним відповідними програмними засобами. Для зчитування штрихового коду з носіїв інформації вико-ристовують пристрої різного типу, що сканують: контактні олівці й сканери; лазерні сканери та мобільні термінали, які зчитують інформацію на відстані. Мобільний термінал, крім зчитування інформації з носіїв, забезпечує попереднє опрацю-вання даних та передачу їх на комп’ютер для подальшого уза-гальнення й аналізу. 3.3.6. Програмні агенти та використання їх в інформаційних системах на підприємствах Останнім часом активно розвивається новий напрям сучасних інформаційних технологій — програмні агенти, які є черговим кроком на шляху автоматизації задач, пов’язаних із пошуком ін-формації за критеріями, що визначаються конкретними потреба-ми кінцевого користувача. По суті програмні агенти — це модулі, здатні автономно ви-рішувати поставлені їм задачі; їх можна вважати особистими «слугами» в комп’ютерному світі. Хоча точне визначення про-грамних агентів ще не сформульоване, ясно, що від звичайних комп’ютерних програм вони відрізняються мірою зворотного зв’язку із зовнішнім світом для відповідної перебудови своєї роботи. Фахівці Інституту інтелектуальних систем Мемфіського університету визначають програмний агент як «систему, що є складовою частиною середовища, сприймає це середовище і діє на нього за своїм власним планом, щоб вплинути на те, що воно сприйматиме в майбутньому». До числа основних характеристик програмних агентів слід віднести: 1. Функції: агент виконує ряд задач за дорученням користу-вача (чи іншого агента). 2. Можливості обміну інформацією: агент повинен мати можливість обмінюватися інформацією з користувачем ( і інколи з іншими агентами) для того, щоб отримувати від нього інструк-ції, повідомляти йому про хід та завершення виконання задачі і надати отримані результати. 3. Автономність: агент працює без прямого втручання ко-ристувача (наприклад, в якості фонового процесу в ті годи- ни, коли на комп’ютері виконуються інші задачі). Виконувані агентом задачі можуть бути досить різними — від щонічного резервного копіювання даних до пошуку (за дорученням кори-стувача) продавця, який пропонує низьку ціну на вказаний продукт. 4. Моніторинг: щоб мати можливість виконувати свої задачі в автономному режимі, агент повинен бути здатним контролю-вати середовище, в якому він діє. 5. Активація: щоб мати можливість працювати в автономно-му режимі, агент повинен бути здатним впливати на своє робоче середовище за допомогою механізму активізації. 6. «Розумність»: агент повинен бути здатним інтерпрету- вати контрольовані ним події, щоб приймати відповідні рі- шення. Окрім перелічених деякі агенти можуть мати ще й такі харак-теристики: а) безперервність роботи: більшість із агентів повинні бути безперервно діючими агентами; б) «індивідуальність»: деякі агенти можуть мати добре ви-ражений «характер» та «емоційний стан»; в) адаптивність: деякі агенти, базуючись на накопиченому досвіді, автоматично пристосовуються до змін середовища; г) мобільність: деякі агенти повинні допускати можливість перенесення їх на інші комп’ютери, в тому числі на системи ін-шої архітектури та інші платформи. Програмні агенти можна грубо поділити на три групи — для настільних систем, для intranet-мереж і для INTERNET. Сьо-годні користувачі комп’ютерів найкраще знайомі з агентами для настільних систем. Найпростішими прикладами таких аген¬тів є «майстри» (Wizards), які автоматично настроюють додатки для персональних комп’ютерів відповідно до побажань користувача, і «офісні помічники» (Offiсe Assistants), які вносять пропозиції щодо підвищення продуктивності на основі спостережень за тим, як використовуються ті або інші програмні блоки. У межах корпоративних мереж програмні агенти можна вико-ристати, наприклад, для автоматизації процесів управління пото-ками даних, пошуку в базах даних і організації взаємодії між різ-ними компонентами системи. Проте найбільш перспективні можливості відкриваються тоді, коли агент виходить у мережу і починає взаємодіяти з іншими комп’ютерними системами. Наприклад, його можна запрограму-вати на пошук інформації по заданих критеріях, а поки він шука-тиме, на комп’ютері можуть вирішуватися інші задачі. За при-клад використання можуть правити такі агенти, як PointCast та EntryPoint, які дозволяють «витягувати» потрібну інформацію з INTERNET і заносити її в пам’ять комп’ютера в потрібний мо-мент і в потрібному форматі. У зв’язку із зростанням інтересу до електронної торгівлі через INTERNET з’явилися програмні агенти, що забезпечують подальшу автоматизацію процесу електронних купівель. Наприклад, агентові можна доручити попередній пошук потрібних товарів. Центр стратегічних технологічних досліджень компанії Ander¬sen Consulting, що розробляє ряд експериментальних агентів, випробував цю ідею на прототипі агента під назвою Bargain Finder. Маючи такий агент, користувач INTERNET може, наприклад, набрати на клавіатурі назву потрібного йому товару і доручити цьому агентові знайти електронний магазин, де такий товар продається найдешевше. Другим перспективним напрямом використання програмних агентів є фінансовий сектор. Наприклад, компанія Logica, що спеціалізується на консультаціях і програмному забезпеченні, пропонує групу програмних агентів для розв’язання проблем, які стоять перед банками. Ефективним може бути використання програмних агентів як складових частин у логістичних інформаційних системах на під-приємствах у ланцюгах постачання та збуту (рис. 3.21). Рис. 3.21. Використання програмних агентів у інформаційних системах на підприємствах Примітка: на рис. 3.21 ERP — один зі стандартів управління підприємствами, що становлять основу сучасних інформаційних систем управління підприємствами. Докладно мова про них йтиме в наступному розділі. ЕВОЛЮЦІЯ СТРАТЕГІЧНИХ МОДЕЛЕЙ УПРАВЛІННЯ ПІДПРИЄМСТВАМИ В ІНФОРМАЦІЙНИХ СИСТЕМАХ Ядром будь-якої інформаційної системи управління підприємством є втілені в ній рекомендації щодо управління виробництвом, що по суті є своєрідним стандартом. Еволюція цих стандартів подана на рис. 4.1. Рис. 4.1. Етапи розвитку стандартів інформаційних систем управління підприємствами Примітка: ВОМ — складання специфікації матеріалів 4.1. СИСТЕМИ ПЛАНУВАННЯ МАТЕРІАЛЬНИХ РЕСУРСІВ (MRP) На початку 60-х років у зв’язку із зростанням популярності обчислювальних систем виникла ідея використати їхні можливості для планування діяльності підприємства, в тому числі для планування виробничих процесів. Необхідність планування зумовлена тим, що основна маса затримок у процесі виробництва була пов’язана із запізненням надходження окремих комплектуючих, внаслідок чого, як правило, паралельно із зменшенням ефективності виробництва на складах виникав надлишок матеріалів, що надходили раніше наміченого терміну. Крім того, через порушення балансу постачання комплектуючих виникали додаткові ускладнення з обліком і відстеженням їхнього стану в процесі виробництва, тобто фактично неможливо було визначити, наприклад, до якої партії належить даний складовий елемент у вже зібраному готовому продукті. З метою запобігання подібним проблемам була розроблена методологія планування потреби в матеріалах MRP (Material Requirements Planning). Реалізація системи, що працює за цією методологією, являла собою комп’ю¬терну систему, яка дозволяє оптимально регулювати постачання комплектуючих у виробничий процес, контролюючи запаси на складі і саму технологію виробництва. Головним зав¬данням MRP було забезпечення гарантії наявності потрібної кількості необхідних матеріалів-комплектуючих у будь-який момент часу в межах терміну планування, поряд з можливим зменшенням по¬стійних запасів, а отже, розвантаженням складу. Перш ніж описувати саму структуру MRP, стисло перелічимо основні її поняття: • Матеріалами називатимемо всю сировину і окремі комплектуючі, що входять до складу кінцевого продукту. Надалі не розрізнятимемо поняття «матеріал» і «комплектуюча». • MRP-система, MRP-програма — це комп’ютерна система, яка працює за алгоритмом, регламентованим MRP-методологією. Як і будь-яка інша комп’ютерна програма, вона опрацьовує файли даних (вхідні елементи) і формує на їх основі файли-резуль¬тати. • Статус матеріалу є основним показником поточного стану матеріалу. Кожний окремий матеріал у кожний момент часу має статус у межах MRP-системи, який визначає, чи є даний матеріал у наявності на складі, чи зарезервований він для інших цілей, чи вказаний у поточних замовленнях або замовлення на нього тільки планується. Таким чином, статус матеріалу однозначно описує міру готовності кожного матеріалу бути запущеним у виробничий процес. • Страховий запас матеріалу необхідний для підтримки процесу виробництва у разі виникнення непередбачених і таких, що не можуть бути усунутими, затримок у його постачанні. По суті, в ідеальному випадку, якщо механізм постачання вважати бездоганним, MRP-методологія не постулювала обов’язкову наявність страхового запасу, і його обсяги встановлювалися різними для кожного конкретного випадку залежно від ситуації, що склалася з надходженням матеріалів. • Потреба в матеріалі в комп’ютерній MRP-системі являє собою певну кількісну одиницю необхідності в замовленні даного матеріалу в певний момент часу протягом періоду планування. Розрізнюють поняття повної потреби в матеріалі, яка відображає ту кількість, яку необхідно пустити у виробництво, і чистої потреби, при обчисленні якої враховується наявність усіх страхових і зарезервованих запасів даного матеріалу. Замовлення в системі автоматично створюється із виникненням відмінної від нуля чистої потреби. Процес планування включає в себе функції автоматичного створення проектів замовлень на закупівлю і/або внутрішнє виробництво необхідних матеріалів-комплектучих. Іншими словами, система MRP оптимізує час постачання комплектуючих, змен¬шуючи тим самим витрати на виробництво і підвищуючи його ефективність. Основними перевагами використання подібної системи у виробництві є такі: 1. Гарантія наявності необхідних комплектуючих і зменшення часових затримок у їх доставці і, отже, збільшення випуску готових виробів без збільшення числа робочих місць і навантажень на виробниче обладнання. 2. Зменшення виробничого браку в процесі збирання готової продукції, що виникав через використання комплектуючих, які не відповідають стандартам. 3. Упорядкування виробництва у зв’язку з контролем статусу кожного матеріалу, що дозволяє однозначно відстежувати весь його конвеєрний шлях, починаючи від створення замовлення на даний матеріал, до його становища у вже зібраному готовому виробі. Завдяки цьому досягається також повна достовірність і ефек¬тивність виробничого обліку. Усі ці переваги фактично випливають з самої концепції MRP, що ґрунтується на тому принципі, що всі матеріали-комплек-туючі, складові частини і блоки готового виробу повинні надходити у виробництво одночасно, в запланований час, аби забезпечити створення кінцевого продукту без додаткових затримок. MRP-система прискорює доставляння тих матеріалів, які в даний момент потрібні насамперед, і затримує передчасні надходження таким чином, що комплектуючі, які становлять повний список складових кінцевого продукту, надходять у виробництво одночасно. Це необхідно для того, щоб уникнути ситуації, коли через затримку постачання одного з матеріалів виробництво змушене припинитися навіть за наявності всіх інших комплектуючих кінцевого продукту. Основна мета MRP-системи — формувати, контролювати й за необхідності змінювати дати необхідного надходження замовлень таким чином, щоб усі матеріали, потрібні для виробництва, надходили одночасно. Формування вхідної інформації для MRP-програми і результати її роботи. На практиці MRP-система є комп’ютерною програмою, логіка роботи якої спрощено може бути подана та-ким чином (рис. 4.2). Рис. 4.2. Вхідні елементи і результати роботи MRP-системи На наведеній вище схемі відображені основні інформаційні елементи MRP-системи. Розгляньмо детальніше елементи MRP-системи. 1) Опис стану матеріалів (Inventory Status File) є основним вхідним елементом MRP-програми. У ньому повинна бути відбита максимально повна інформація про стан матеріалів-комплек¬туючих, необхідних для виробництва кінцевого продукту. У цьому елементі має бути вказаний статус кожного матеріалу, що визначає, чи є він на руках, на складі, в поточних замовленнях, чи його замовлення тільки планується, а також опис його запасів, розташування, ціни, можливих затримок постачання, реквізитів постачальників. Інформація по всіх перелічених вище позиціях повинна бути закладена окремо по кожному матеріалу, задіяному у виробничому процесі. 2) Програма виробництва (Master Production Schedule) являє собою оптимізований графік розподілу часу для виробництва необхідної партії готової продукції за період, для якого здійснюється планування або діапазон періодів. Спочатку створюється пробна програма виробництва, що згодом додатково тестується на можливість виконання прогоном через CRP-систему (Capacity Requirements Planning), яка визначає, чи досить виробничих потужностей для її здійснення. Якщо така виробнича програма визнана здійсненною, то вона автоматично формується в основну і стає вхідним елементом MRP-системи. Це необхідно тому, що рамки вимог до виробничих ресурсів є прозорими для MRP-си¬стеми, яка формує на основі виробничої програми графік виникнення потреб у матеріалах. Однак через недоступність ряду матеріалів або неможливість виконати план замовлень, необхідний для підтримки реалізації з погляду CRP виробничої програми, MRP-система в свою чергу вказує на необхідність її коригування. 3) Перелік складових кінцевого продукту (Bills of Material File) — це список матеріалів та кількість їх, необхідна для вироб-ництва кінцевого продукту. Таким чином, кожний кінцевий продукт має свій перелік складових. Крім того, тут міститься опис структури кінцевого продукту, тобто повна інформація щодо технології його складання. Надзвичайно важливо підтримувати точність усіх записів у цьому елементі й відповідно коригувати їх кожного разу під час внесення змін до структури і/або технології виробництва кінцевого продукту. Нагадаймо, що кожний із згаданих вище вхідних елементів являв собою комп’ютерний файл даних, що використовується MRP-програмою. У даний момент MRP-системи реалізовані на найрізноманітніших апаратних платформах і включені як модулі в більшість фінансово-економічних систем. Не спиняючись на технічному аспекті питання, перейдемо до опису логічних кроків роботи MRP-програми. Цикл її роботи складається з таких осно-в¬них етапів: 1) Передусім MRP-система, аналізуючи прийняту програму виробництва, визначає оптимальний графік виробництва на період, що планується. 2) Далі, матеріали, не включені до виробничої програми, але вказані в поточних замовленнях, включаються в планування як окремий пункт. 3) На цьому кроці на основі затвердженої програми виробництва і замовлень на комплектуючі, що не входять до неї, для кожного окремо взятого матеріалу відповідно до переліку складових кінцевого продукту обчислюється повна потреба за такою схемою. Чиста потреба = Повна потреба – Інвентаризовано на руках – Страховий запас – Резервування для інших цілей 4) Далі, на основі повної потреби, враховуючи поточний статус матеріалу, для кожного періоду часу і для кожного матеріалу розраховується чиста потреба за вказаною вище формулою. Якщо чиста потреба в матеріалі більше нуля, то системою автоматично створюється замовлення на матеріал. 5) І нарешті, всі замовлення, створені раніше поточного періоду планування, розглядаються, і в них, за необхідності, вносяться зміни, щоб запобігти передчасному постачанню і затримкам по¬стачання від постачальників. Таким чином, завдяки роботі MRP-програми вноситься низка змін в існуючі замовлення і за необхідності для забезпечення оптимальної динаміки ходу виробничого процесу створюються нові замовлення. Ці зміни автоматично модифікують Опис стану матеріалів, оскільки створення, скасування або модифікація замовлення відповідно впливають на статус матеріалу, якого він стосується. За допомогою роботи MRP-програми створюється план замовлень на кожний окремий матеріал на весь термін планування, забезпечення виконання якого необхідне для підтримки програми виробництва. Основними результатами MRP-системи є такі: 1) План замовлень (Planned Order Schedule) — визначає, яка кількість кожного матеріалу повинна бути замовлена в кожний розглядуваний період часу протягом терміну планування. План замовлень є керівництвом для подальшої роботи з постачальниками і, зокрема, визначає виробничу програму для внутрішнього виробництва комплектуючих (за наявності остан нього). 2) Зміни до плану замовлень (Changes in planned orders) є модифікаціями до раніше спланованих замовлень. Ряд замовлень можуть бути відмінені, змінені або затримані, а також перенесені на інший період. Окрім цього, MRP-система формує деякі другорядні результати у вигляді звітів, метою яких є звернення уваги на «вузькі місця» протягом планового періоду, тобто ті проміжки часу, коли потрібен додатковий контроль за поточними замовленнями, а також для того, щоб вчасно сповістити про можливі системні помилки, що виникли під час роботи програми. Отже, MRP-систе¬ма формує такі додаткові результати-звіти: а) Звіт про «вузькі місця» планування (Exception report) — призначений для того, щоб завчасно проінформувати користувача про ті проміжки часу протягом терміну планування, які вимагають особливої уваги і в які може виникнути необхідність зовнішнього управлінського втручання. Типовими прикладами си¬туацій, які мають бути відображені в цьому звіті, можуть бути замовлення, що непередбачено запізнилися, на комплектуючі, надлишки комплектуючих на складах тощо. б) Виконавчий звіт (Performance Report) — основний індикатор правильності роботи MRP-системи; має на меті оповіщати користувача про критичні ситуації, що виникли під час планування, як-от: повне витрачення страхових запасів по окремих комплектуючих, а також про всі виникаючі системні помилки в процесі роботи MRP-програми. в) Звіт про прогнози (Planning Report) є інформацією, що використовується для складання прогнозів про можливу майбутню зміну обсягів і характеристик продукції, що випускається, отриману завдяки аналізу поточного ходу виробничого про¬цесу і звітам про продаж. Звіт про прогнози може викорис- товуватися також для довгострокового планування потреб у матеріалах. Таким чином, використання MRP-системи для планування виробничих потреб дозволяє оптимізувати час надходження кожного матеріалу, значно знижуючи таким чином складські витрати і полегшуючи ведення виробничого обліку. Однак серед користувачів MRP-програм існували розходження в думках відносно використання страхового запасу для кожного матеріалу. Прихильники використання страхового запасу стверд¬жували, що він необхідний тому, що часто механізм доставляння вантажів не є досить надійним, і повне витрачення через різні чинники запасів на який-небудь матеріал, що автоматично призводить до зупинення виробництва, коштує набагато дорожче, ніж його страховий запас, що постійно підтримується. Противники використання страхового запасу твердили, що його відсутність є однією із головних особливостей концепції MRP, оскільки MRP-система має бути гнучкою щодо зовнішніх чинників, вчасно вносячи зміни до плану замовлень у разі непередбачених затримок постачання. Але в реальній ситуації, як правило, друга точка зору може бути реалізована під час планування потреб для виробництва виробів, попит на які відносно прогнозований і контрольований і у виробничій програмі може бути встановлено постійний обсяг виробництва протягом деякого, відносно тривалого, періоду. Потрібно зазначити, що в умовах нашої економіки, коли затримки в процесах по¬стачання є швидше правилом, ніж винятком, на практиці до- цільно застосовувати планування з урахуванням страхового запасу, обсяги якого встановлюються у кожному окремому випадку. Планування виробничих потужностей за допомогою CRP-системи (Capacity Requirements Planning). Система планування виробничих потужностей за методологією CRP застосовувалась для перевірки пробної програми виробництва, створеної відпові-д¬но до прогнозів попиту на продукцію, на можливість її здійснення наявними виробничими потужностями. У процесі роботи CRP-системи розроблявся план розподілу виробничих потужностей для опрацювання кожного конкретного циклу виробництва протягом планового періоду. Встановлювався також технологічний план послідовності виробничих процедур і, відповідно до пробної програми виробництва, визначалася міра завантаження кожної виробничої одиниці на термін планування. Якщо після циклу роботи CRP-модуля програма виробництва визнавалась реально здійсненною, вона автоматично підтверджувалась і ставала основною для MRP-системи. В іншому разі до неї вносили- ся зміни, і вона зазнавала повторного тестування за допомогою CRP-модуля. У подальшому еволюційному розвитку систем планування виробництва вони почали являти собою інтеграцію багатьох окремих модулів, які, взаємодіючи, збільшували гнучкість системи загалом. По суті методика MRP декларувала, які процеси обліку та управління мають бути реалізовані на підприємстві, в якій послідовності вони повинні виконуватися, та містить рекомендації стосовно їх виконання. Надалі розвиток концепції MRP відбувався через розширення функціональних можливостей підприємства у бік більш повного задоволення потреб клієнтів та зниження виробничих витрат. Це сприяло тому, що в кінці 70-х років концепція MRP була доповнена положенням про формування виробничої програми в масштабах усього підприємства та контроль її виконання на рівні підрозділів (Closed Loop MRP, або, іншими словами, відтворення замкнутого циклу в MRP-системах). 4.2. СИСТЕМИ ПЛАНУВАННЯ ВИРОБНИЧИХ РЕСУРСІВ (MRPII) На початку 80-х років з’явилася концепція MRPII (Планування виробничих ресурсів — Manufacturing Resourse Planning), основна суть якої зводиться до того, що прогнозування, планування та контроль виробництва здійснюються по всьому циклу, починаючи від закупівлі сировини і закінчуючи відвантаженням товару споживачеві. А це означало, що MRPII є методологією, спрямованою на ефективне управління всіма видами ресурсів виробничих підприємств. У загальному випадку вона забезпечує вирішення задач планування діяльності підприємства в натуральних одиницях та фінансове планування в грошовому вимірі. Така методологія являє собою набір перевірених на практиці дотепних принципів, моделей та процедур управління і контролю, виконання яких мало сприяти поліпшенню показників економічної діяльності підприємства. Стандарти товариства APICS (American Production and Inventory Control Society) на системи класу MRPII містять опис 16 груп функцій системи: 1. Sales and Operation Planning (Планування продажу та виробництва). 2. Demand Mаnаgement (Управління попитом). 3. Master Production Scheduling (Складання плану виробницт-ва). 4. Material Requirements Planning (Планування матеріальних потреб). 5. Bill of Materials ( Специфікація продуктів). 6. Inventory Transaction Subsystem (Управління складами). 7. Scheduled Receipts Subsystem (Планові поставки). 8. Shop Flow Control (Управління на рівні виробничого цеху). 9. Capacity Requirements Planning (Планування потреб у потужностях). 10. Input/output control (Контроль входу/виходу). 11. Purchasing (Матеріально-технічне постачання). 12. Distribution Resource Planning (Планування розподілу ре-сурсів). 13. Tooling Planning and Control (Планування та управління інструментальними засобами). 14. Financial Planning (Управління фінансами). 15. Simulation (Моделювання). 16. Performance Measurement (Оцінка результатів діяльнос-ті). Схеми роботи інформаційної системи, побудованої на базі MRP II-концепції, наведена на рис. 4.3. Рис. 4.3. Схематичний план роботи MRPII-системи З накопиченням досвіду моделювання виробничих та невиро-б¬ничих операцій ці положення постійно уточнювалися, поступово охоплюючи дедалі більше функцій. Однак слід зазначити, що наведений перелік функцій стосується тільки управління виробничими ресурсами підприємства. Стандарт MRPII ділить сфери окремих функцій (процедур) на два рівні — необхідний та додатковий, або опціональний. Щоб програмне забезпечення було віднесене до класу MRPII, воно повинно виконувати певний обсяг необхідних (основних) функцій (процедур). Набір функціональних модулів та їхні взаємозв’язки мають глибоке обґрунтування з погляду теорії управління. Вони забезпечують інтеграцію функцій планування, у тому числі узгодження різних процесів управління в просторі й часі. Важливо зазначити, що наведений набір не є надмірним і саме тому він зберігається переважно в системах наступних поколінь. Понад те, більшість понять, методів та алгоритмів, закладених у функціональні модулі MRPII, залишаються незмінними упродовж тривалого проміжку часу і входять як елементи до систем наступних поколінь. З цієї причини методологію MRPII прийнято вважати базовою. Для кожного рівня планування MRPII характерні такі парамет-ри, як ступінь деталізації плану, часовий горизонт плануван-ня, вид умов та обмежень. Ці параметри для одного й того са-мого рівня MRPII можуть замінюватися в широкому діапазоні залежно від особливостей виробничого процесу на підприємстві. Крім цього, залежно від характеру виробничого процесу можливе використання на кожному окремому підприємстві певного набору функціональних модулів MRPII. А це по суті означає, що MRPII є гнучкою та багатофункціональною системою, використання якої можливе в широкому спектрі умов. Загалом система управління підприємством, побудована від-повідно до стандарту MRPII, має такий вигляд (рис. 4.4). Розгляньмо стислу характеристику перелічених функціональ-них блоків MRPII: 1) Бізнес-планування. Процес формування плану підприємс-т¬ва найбільш високого рівня. Планування довгострокове, план складається в грошовому вимірі. Найменш формалізований про-цес вироблення рішень. 2) Планування попиту. Процес прогнозування (планування) попиту на визначений період. 3) Планування продажу та виробництва. Бізнес-план та план попиту перетворюються в плани продажу основних видів продукції (зазвичай від п’яти до десяти). При цьому виробничі потужності можуть не братися до уваги або враховуватися укрупнено. План має середньостроковий характер. План продажу в розрізі видів продукції перетворює-ться в об’ємний або об’ємно-календарний план виробництва видів продукції. Під видом тут слід розуміти сімейства одно- рідної продукції. В цьому плані вперше як планово-облікові одиниці постають вироби, але уявлення про них має дещо усе-реднений характер (приміром, мова може йти про всі перед-ньопривідні легкові автомобілі, що випускаються на заводі — без уточнення моделей). Досить часто цей модуль об’єднують з по-переднім. 4) План-графік випуску продукції. План виробництва пе-ретворюється на графік випуску продукції. Як правило, це се-редньостроковий об’ємно-календарний план, що визначає кількості конкретних виробів (або партій) зі строками їх виго-товлення. 5) Планування потреб у матеріальних ресурсах. Під час планування на цьому рівні визначають кількість та терміни поставляння матеріальних ресурсів, необхідних для забезпечення графіка випуску продукції. Вхідними даними для планування потреб у матеріальних ресурсах є специфікації виробів (склад та кіль¬кісні характеристики комплектуючих конкретного виробу) та розмір поточних матеріальних запасів. 6) Планування виробничих потужностей. Зазвичай у цьому модулі виконуються розрахунки щодо визначення і порівняння наявних і необхідних виробничих потужностей. З невеликими змінами цей модуль може використовуватися не тільки для виро-б¬ничих потужностей, а й для інших видів виробничих ресурсів, здатних впливати на пропускну спроможність підприємства. По-дібні розрахунки, як правило, здійснюються після формування планів практично всіх попередніх рівнів з метою підвищення на-дійності системи планування. Інколи рішення даної задачі вклю-чають у модуль відповідного рівня. Вхідними даними при плану-ванні виробничих потужностей є маршрутизація виробів, що випускаються підприємством. 7) Управління замовленнями клієнтів. На цьому етапі по-треби клієнтів зіставляються з планами випуску продукції; 8) Управління на рівні виробничого цеху. В межах цього етапу формуються оперативні плани-графіки. Як планово-облі-кові одиниці можуть виступати деталі (партії), складальні одини-ці глибокого рівня, детале-операції тощо. Тривалість планування невелика (від кількох днів до місяця). 9) Оцінка виконання. По суті в даному модулі оцінюється реальне виконання всіх перелічених вище планів з тією метою, щоб у разі потреби внести корективи в усі попередні цикли пла-нування. Зв’язок між рівнями MRPII забезпечується універсальною формулою, на якій будується система. Задача планування на ко-ж¬ному рівні реалізується як відповідь на чотири запитання: 1. Що необхідно виконувати? 2. Що необхідно для цього? 3. Що є в наявності? 4. Що ще необхідно мати? Відповіддю на перше запитання завжди є план більш високого рівня. Завдяки цьому і забезпечується зв’язок між рівнями. Стру-к¬тура відповіді на решту питань залежить від конкретної задачі, що розв’язується. Подальший розвиток MRPII пов’язаний із появою систем управління підприємством у замкненому контурі, тобто із зворо-т¬ним зв’язком (Closed-loop MRP). Ці системи відкривають такі функціональні можливості, як планування і облік запуску-випус-ку, складання оперативних розкладів, вирішення задач первинно-го обліку. Перелічені функціональні можливості не тільки по-глибили систему планування, а й створили умови для ефектив-ного регулювання ходу виробництва, що в кінцевому підсумку сприяло підвищенню стійкості планів верхнього рівня. Сьогодні під системами типу MRPII звичайно мають на увазі саме системи із зворотним зв’язком. Існує декілька напрямів розвитку MRPII. Перший з них — доповнення MRPII функціями управління матеріальними ресур-сами в розподільних системах. Ці функції отримали назву «Пла-нування потреб у розподільних системах» (Distribution Requi-rements Planning — DRP). Тут вирішуються задачі управління запасами в складській мережі. Розвиток DRP поступово сприяв заміні традиційного підходу до визначення рівня запасів за прин-ципом «точки замовлення» (тобто подачі замовлення на попов-нення запасів за досягнення мінімально допустимого рівня) но-вим підходом, в основі якого — визначення потреб залежно від замовлень на продукцію. Цей підхід, поширюваний нині на скла-ди всіх рівнів — від регіональних, оптових до складів на підпри-ємствах, має назву планування залежних потреб. Тривалий процес впровадження MRPII дозволив, з одного бо-ку, досягнути зростання ефективності підприємств, а з іншого — виявив такі, зокрема, властиві цій системі недоліки: • орієнтація системи управління підприємством виключно на існуючі замовлення, що утруднювало прийняття рішень на три-валу, середньострокову, а в ряді випадків і на короткострокову перспективу; • слабка інтеграція з системами проектування і конструю-вання продукції, що особливо важливо для підприємств, які вироб¬ляють складну продукцію; • слабка інтеграція з системами проектування технологічних процесів і автоматизації виробництва; • недостатнє насичення системи управління функціями упра-вління витратами; • відсутність інтеграції з процесами управління фінансами і кадрами. 4.3. СИСТЕМИ ПЛАНУВАННЯ РЕСУРСІВ ПІДПРИЄМСТВА (ERP) Необхідність усунення перелічених недоліків спонукала трансформувати системи MRP II у системи нового класу «Планування ресурсів підприємства» (Enterprise Resource Planning — ERP). Системи цього класу більшою мірою орієн-товані на роботу з фінансовою інформацією для розв’язання задач управління великими корпораціями з розпорошеними те-риторіально ресурсами. Сюди включається все, що необхідно для отримання ресурсів, виготовлення продукції, її транспор-тування і розрахунків за замовленнями клієнтів. Крім перелі-чених функціональних вимог в ERP реалізовані й нові підходи до застосування графіки, використання реляційних баз даних, CASE-технологій для їхнього розвитку, архітектури обчислю-вальних систем типу «клієнт—сервер» і реалізації їх як відкри-тих систем. Системи типу ERP поповнюються такими функціональними модулями: прогнозування попиту, управління проектами, управ¬ління витратами, управління складом продукції, ведення технологічної інформації. У них прямо або через системи обміну даними вбудовуються модулі управління кадрами і фінансовою діяльністю підприємства. У збільшеному вигляді структура управління в ERP показана на рис. 4.5. Далі пояснюються елементи структури управління ERP, дода-ні до системи MRPII. Рис. 4.5. Структура управління в ERP-системах у збільшеному вигляді Прогнозування. Оцінка майбутнього стану або поведінки зо-в¬нішнього середовища чи елементів виробничого процесу. Мета — оцінити необхідні параметри в умовах невизначеності. Недолік інформації пов’язаний звичайно з часовим чинником. Прогнозування може мати як самостійний характер, так і, передуючи плануванню, являти собою перший крок у розв’язанні задачі планування. Управління проектами і програмами. У виробничих систе-мах, призначених для випуску складної продукції, виробництво як таке є одним із етапів повного виробничого циклу. Йому пе-редують проектування, конструкторська і технологічна підготов-ка, а вироблена продукція зазнає випробувань і модифікації. Для складної продукції характерними є велика тривалість циклу, зна-ч¬на кількість підприємств-суміжників, складність внутрішніх і зовнішніх зв’язків. Цим зумовлюється необхідність управління проектами і програмами загалом і включення відповідних функ-цій до системи управління. Ведення інформації про склад продукції. Ця частина систе-ми управління забезпечує управлінців і виробничників інформа-цією необхідного рівня про продукцію, вироби, складальні оди-ниці, деталі, матеріали, а також про оснащення і пристосування. Тут забезпечуються адекватне подання різних структур виробів, повнота даних, фіксація всіх змін. Особливе місце серед вирішу-ваних задач належить задачі розвузлування для багаторівневих виробів. Вона використовується також під час планування по-треб у матеріальних ресурсах. Ведення інформації про технологічні маршрути. Для вирі-шення задач оперативного управління виробництвом необхідна інформація про послідовність операцій, що входять у технологічні маршрути, тривалість операцій і кількість виконавців або робочих місць, необхідних для їх виконання. Управління витратами. Цей фрагмент системи оцінює ро-боту виробничих та інших підрозділів з погляду витрат. Тут виконуються роботи з визначення планових і фактичних витрат. Роль даної підсистеми — забезпечити зв’язок між управлін-ням виробництвом і управлінням фінансовою діяльністю вирі-шенням задач планування, обліку, контролю і регулювання ви-трат. Задача, як звичайно, вирішується в різних розрізах по підрозділах, проектах, типах і видах продукції, виробах тощо. Ця інформація використовується для вироблення управлінських рішень, що оптимізують економічні показники підприємства. Управління фінансами. У цій підсистемі вирішуються задачі управління фінансовою діяльністю. Практично у всіх зарубіжних системах до неї входять чотири підсистеми більш глибокого рів-ня — «Головна бухгалтерська книга», «Розрахунки із замовника-ми», «Розрахунки з постачальниками», «Управління основними засобами». Автоматизація управління фінансами на підприємстві дозволяє: • посилити фінансовий контроль шляхом узагальнення всієї фінансової діяльності; • поліпшити обіг грошових коштів забезпеченням повного управління кредитами і рахунками дебіторів; • оптимізувати управління грошовими коштами за допомогою автоматизації розрахунків із постачальниками; • максимізувати віддачу від капітальних вкладень забезпечен-ням більш ефективного управління основними засобами, орен-дованою власністю, ремонтною базою, незавершеним капіталь-ним будівництвом. Управління кадрами. У даній підсистемі вирішуються задачі управління кадровими ресурсами підприємства, пов’язані з на-бором, штатним розкладом, перепідготовкою, просуванням по службі, оплатою тощо. ERP, таким чином, є поліпшеною модифікацією MRPII. Її ме-та — інтегрувати управління всіма ресурсами підприємства, а не тільки матеріальними, як це було в MRPII. Ще однією особливістю ERP є, по суті, збереження підхо- дів до планування виробництва, прийнятих в MRPII. Основ- на причина полягала в тому, що на первинному етапі пере- ходу від MRPII до ERP потужність обчислювальних систем була недостатньою для забезпечення широкого застосування методів моделювання та оптимізації. Обмеження обчислю-вального характеру призвели, наприклад, до того, що плано- ві рішення формувалися шляхом циклічного повторення двох кроків. На першому кроці формується план без урахування обмежень на виробничі потужності. На другому кроці він перевіряється на допустимість. Процес повторюється доти, доки план, отриманий на черговій інтеграції, не буде допус- тимим. В ERP рішення про включення виробу в графік випуску продукції може прийматися не тільки на основі попиту, що реально існує, а й на основі прогнозу попиту і у зв’язку з ви- конанням великих проектів і програм. Це, безумовно, розширює діапазон застосування системи управління і робить її більш гнучкою та оперативною щодо змін зовнішнього сере- довища. Нижче наводиться опис тих функціональних компонент ERP, які забезпечують управління виробничим процесом на підприєм-стві. Головна увага при цьому приділяється методам управління, що застосовуються у базових системах ERP. ? Прогнозування економічних процесів Потреба в прогнозуванні може виникнути на декількох рівнях системи управління підприємством, оскільки попит на продукцію і послуги може змінюватися з різною періодичністю. Для систем управління підприємством найважливішими мо-ментами є такі: • ієрархія прогнозів; • структура формування прогнозів; • якісні методи прогнозування; • кількісні методи прогнозування; • поєднання прогнозування і планування. Нижче наводяться приклади основних прогнозів. 1. Довгострокові прогнози. Горизонт прогнозування — роки. Об’єкти прогнозування: потреби ринку в нових видах продукції (у вартісному або натуральному вираженні); потреби ринку в старій, тобто тій, що випускається сьогодні, продукції (у вартіс-ному або натуральному вираженні); необхідна продуктивність підприємства; капіталовкладення; потреби у виробничих потуж-ностях підприємства. 2. Середньострокові прогнози. Горизонт прогнозування — мі-сяці. Об’єкти прогнозування: нові типи або групи продукції; про-дуктивність окремих виробництв і підрозділів; потреби в кадрах; потреби в закупівлі матеріалів; оцінка запасів. 3. Короткострокові прогнози. Горизонт прогнозування — тижні. Об’єкти прогнозування: окремі найменування продукції; працівники певних спеціальностей і кваліфікації; продуктивність обладнання в окремих цехах і на дільницях; рівень запасів. На рис. 4.6 показана укрупнена схема формування прогнозу і його використання як першого кроку в плануванні. Якісні методи прогнозування звичайно базуються на виявлен-ні чинників, які визначають обсяги продажу або сервісу. Потім формуються думки відносно ймовірностей прояву цих чинників у майбутньому. Рис. 4.6. Схема формування прогнозу Нижче наводяться основні якісні методи. 1. Мозковий штурм. Робочій групі надається будь-яка необ-хідна інформація з бази даних підприємства і зовнішньої бази да-них. Учасники групи створюють індивідуальні прогнози. Крайні прогнози відкидаються, а роль компромісного виконує прогноз, заснований на індивідуальних прогнозах, що залишилися. 2. Метод Делфі. Згідно з цим методом учасники анонімно відповідають на запитання, отримують інформацію про відповіді всіх учасників, а потім процес повторюється знову до досягнення згоди. 3. Огляд діяльності з продажів. Оцінка продажу в майбут-ньому по регіонах здійснюється тут на основі оцінок окремих продавців. 4. Аналіз інформації від покупців. Оцінки майбутнього про-дажу роблять безпосередньо покупці. Індивідуальні оцінки зво-дяться воєдино. 5. Історичні аналогії. Маркетингові дослідження, опитуван-ня, інтерв’ю, пробний продаж дозволяють сформувати основу для перевірки гіпотез відносно поведінки реального ринку. Якісні методи засновані на нескладних алгоритмах опрацю-вання інформації. Обсяг інформації може бути значним. Роль комп’ютерних систем полягає в інформаційній підтримці. Кількісні методи прогнозування реалізуються за допомогою математичних моделей, що базуються на попередній історії. По-дібні моделі будуються, виходячи з припущення, що дані про поведінку процесу в минулому можуть бути поширені й на май-бутнє. Найчастіше до базових систем і пакетів прикладних програм включаються методи, засновані на часових рядах, отриманих за допомогою вимірювань у певних часових періодах. Як правило, результати вимірювань поведінки процесу в ми-нулому можуть бути розкладені на декілька компонентів. Тренд — це постійна, довготривала тенденція. Циклічна складова описує ту частину процесу, яка повторю-ється з низькою частотою. Сезонна складова описує цикли, що повторюються з висо-кою частотою протягом року. Випадкова флуктуація являє собою випадкове відхилення часового ряду від невипадкової функції, що описується трендом, циклічною і сезонною складовими. Прогнозування на основі кількісних методів полягає переду-сім у визначенні вигляду і параметрів функцій, що описують не-випадкові складові. Здебільшого застосовують такі кількісні моделі прогнозуван-ня: 1. Лінійна регресія. Модель спрямована на виявлення зв’язку між залежною змінною (тобто величиною, що прогнозується) і однією або більшою кількістю незалежних змінних у вигляді да-них про попередню історію. У простій регресії є тільки одна не-залежна змінна, а у множинній регресії їх декілька. Якщо переді-сторія подана у вигляді часового ряду, то незалежна змінна — це часовий період, а залежна — це величина, що прогнозується, на-приклад обсяг продажу. 2. Методи змінного середнього. Прогностична модель для короткострокових прогнозів, заснована на часових рядах. У ній середнє арифметичне фактичних показників, обчислене для при-йнятого числа останніх минулих часових періодів, береться за прогноз на наступний часовий період. 3. Метод зваженого змінного середнього. Ця модель працює подібно до попередньої, але в ній обчислюється не середнє, а се-редньозважене значення, яке і береться за прогноз на найближ-чий часовий період. Менші ваги приписується більш віддаленим періодам. 4. Експоненціальне згладжування. Це модель, що викорис-товує часові ряди і призначена для короткострокових прогнозів. Згідно з даним методом величина, спрогнозована для останнього періоду, коригується на основі інформації про помилку прогнозу в останньому періоді. Скоригований за останній період прогноз стає прогнозом на наступний період. Функції прогнозування і планування можуть перетинатися, оскільки перетинаються періоди прогнозування і планування, а об’єктом прогнозування і планування може бути одна і та сама продукція. При цьому об’єктом планування є продукція, на яку є замовлення. Прогноз же за своєю природою прямо не пов’язаний із існуючим замовленням. У деяких системах передбачена така логіка визначення потреб у продукції за одночасного прогнозування і планування. Горизонт планування ділиться на три часових зони. Для кожної зони використовується свій варіант прийняття рішення про величину потреб у продукції. Варіант 1. Потреби обчислюються на основі фактичного іс-нуючого попиту. Варіант 2. Потреби обчислюються на основі попиту, за який береться максимальне значення з двох величин — прогнозу і фа-к¬тичного попиту. Варіант 3. Матеріальні потреби визначаються на основі по-питу, що прогнозується. Вибір варіанта взаємодії фактичного попиту і попиту, що про-гнозується, залишається за користувачем. Вибір залежить від ти-пу виробництва, номера зони, зовнішніх умов, у яких працює підприємство. ? Управління проектами і програмами Одна з тенденцій розвитку виробництва полягає у зростанні частки продукції, яка не випускається на склад і яка навіть не збирається під замовлення, а проектується за замовленнями. Тра-диційними галузями, де здебільшого практикується така орієнта-ція, є аерокосмічна й оборонна. Будь-який новий виріб у цих га-лузях вимагає виконання великого і досить дорогого комплексу тривалих робіт. Такі комплекси звичайно називають проектами або програмами. Проект у багатьох випадках стає самостійним об’єктом управління і джерелом замовлень, що подаються у виробничі системи. Тому в сучасних системах ERP з’явилися модулі, спеціально призначені для управління проектами або програ-мами. Управління проектом, з одного боку, безпосередньо підпорядковане стратегічним цілям, які насамперед реалізує бізнес-пла¬нування, а з іншого — породжує потреби в продукції, які передаються в модуль планування продажу або безпосередньо в модуль формування графіка випуску продукції. Потреби в продукції можуть у ході реалізації проекту формулюватися з різною мірою точності. Що ж до видів і типів продукції, то зв’язок з виробництвом проходить через модуль «Планування продажу і випуску продукції». Якщо ж мова йде про вироби, то зв’язок з виробництвом проходить через модуль «Складання графіка випуску продукції». Звичайно, і ранні системи ERP містили елементи, необхідні для управління виробництвом складної продукції. Але лише від-носно недавно з’явилися спеціалізовані системи, де функціо-нальні можливості управління проектами різко змінили вигляд системи загалом. В основі управління проектами лежать сітьові моделі. Для ро-боти з сітьовими моделями застосовують два методи — метод критичного шляху (МКШ) і метод оцінки й перегляду програм (ПЕРТ). У цих методах основна увага приділяється календарно-му управлінню роботами. Відмінність методів полягає в тому, що в методі МКШ оцінка тривалості операцій здійснюється в де-термінованих величинах, а в методі ПЕРТ — у випадкових. Зараз обидва методи об’єднані в єдиний підхід, що отримав назву сі-тьового планування і управління (СПУ). У міру розширення сфери застосування метод ПЕРТ дедалі більше почали застосо-вувати й для аналізу витрат. Сітьове планування і управління включає три основних етапи: структурне планування, календарне планування, оперативне планування. До структурного планування входить: розбиття проекту на операції, оцінка тривалості операцій та побудова моделі; аналіз моделі на несуперечність. Календарне планування включає розрахунок критичного шля-ху з виявленням критичних операцій; визначення ранніх і пізніх термінів завершення операцій; визначення резервів часу для нeкpитичних операцій. Оперативне управління передбачає вирішення на сітьовій мо-делі задач обліку, контролю, регулювання. У ході регулювання можуть коригуватися не тільки параметри моделі, але і її струк-тура. Побудова сітьової моделі виконується відповідно до деяких правил. Наприклад, потрібно, щоб кожна операція в мережі була представлена тільки однією дугою. На рис. 4.7 показаний приклад сітьової моделі. У процесі розрахунку визначаються критичні й нeкpитичні операції проекту. Операція вважається критичною, якщо затрим-ка її початку спричиняється до збільшення терміну закінчення всього проекту. Критичний шлях визначає безперервну послі-довність критичних операцій, що зв’язують початкову і завер-шальну подію. Нeкpитична операція має резерв (запас) часу, оскільки проміжок часу між її раннім початком і пізнім закінчен-ням більший за її тривалість. Критичні операції показані в прикладі, що поданий на рис. 4.7: (0,2), (2,3), (3,4), (4,5), (5,6). Рис. 4.7. Сітьова модель управління проектами Для нeкpитичних операцій обчислюються резерви часу. Розрі-з¬нюють два основних види резервів часу: 1. Повний резерв — визначається співвідношенням: повний резерв = (пізній час завершення операції – ранній час початку операції) – тривалість операції. 2. Вільний резерв — визначається виходячи з припущення, що всі операції в мережі починаються в ранні терміни (мається на увазі лівий крайній розклад робіт). У критичних операціях по-вні й вільні резерви дорівнюють нулю. У некритичних операціях повні резерви не рівні нулю, а вільні резерви можуть прибирати як ненульові, так і нульові значення. Резерви важливі, оскільки, зсуваючи роботи в межах резервів, можна добитися задоволення обмежень на ресурси або їх най-більш рівномірного використання. При розподілі ресурсів вини-кає багатоваріантна задача, яка може бути описана як оптиміза-ційна. У низці базових систем ERP і самостійних систем управ-ління проектами є евристичні методи отримання задовільного вирішення задачі. ? Планування виробництва і складання графіка випуску продукції Довгострокові, середньострокові й короткострокові плани створюються на різних організаційних рівнях і охоплюють різні часові періоди. Створені на вищому рівні, довгострокові плани відображають стратегічні цілі організації. Вони стають основою для середньо- і короткострокових планів. Середньострокові пла-ни поділяються на плани зайнятості, укрупнені плани утворення запасів або виробництва, плани завантаження, плани модернізації потужностей, контракти з постачальниками. Ці укрупнені плани є основою для побудови короткострокових планів. Корот-кострокові плани звичайно поширюються на термін від декількох тижнів до декількох місяців і включають графіки випуску продукції, графіки виробництва компонент, графіки матеріально-го постачання, оперативні виробничі графіки та графіки викорис-тання потужностей. Графіки виробництва — це короткострокові плани виробництва товарів або кінцевої продукції. Планування виробництва включає такі кроки: 1. Прогноз продажу і фіксація фактичного попиту для кожно-го виду продукції. Він показує кількості, які повинні бути продані в кожний часовий період (тиждень, місяць, квартал) планового горизонту (звичайно від 6 до 18 місяців). 2. Зведення воєдино в загальний прогноз даних по всіх окре-мих видах продукції і послуг. 3. Перетворення сумарного попиту в кожному періоді в чисе-льність робітників, обладнання та інших складових виробничих потужностей, необхідних для його задоволення. 4. Розробка альтернативних схем використання ресурсів, які б дозволяли забезпечити виробничі можливості, для реалізації су-марного попиту. 5. Відбір з альтернатив такого плану використання потужнос-тей, який дозволяє задовольнити попит і найкращим чином від-повідає цілям організації. Крок 5 передбачає, що виробнича система зобов’язана задо-вольняти попит, який прогнозується. Є, однак, випадки, коли ви-робничі потужності не можуть бути збільшені або коли продук-цію вигідніше виготовляти в обсязі, меншому, ніж прогнозний або фактичний попит. У ERP-системах припускається, що мета підприємства полягає в задоволенні попиту. Центральне місце в плануванні виробництва займають такі питання: • Скільки виробничих ресурсів кожного виду є в наявності? • Який рівень потужності забезпечує ресурс кожного виду? • Яким чином визначається потужність виходячи з існуючих ресурсів? • Скільки коштує зміна потужностей у бік збільшення або зменшення? Основними джерелами для визначення можливостей підпри-ємства під час розробки середньострокових планів є такі: основ-ний і понаднормовий робочий час; запаси продукції, утворені в попередні періоди; субконтракти на постачання продукції або виконання послуг зовнішніми партнерами. Розрізнюють такі види середньострокових планів: збалансо-ваний і план з фіксованим рівнем потужності. Збалансований план. У кожний момент часу існуючі потуж-ності рівні потребам, зумовленим прогнозованим попитом. План з фіксованим рівнем потужностей. Потужності є по-стійними на всьому горизонті планування. Відхилення попиту, що змінюється, від можливостей постійних виробничих потуж-ностей компенсується за допомогою запасів, відкладеного попи-ту, понаднормових робіт і субконтрактів. На практиці доцільно розглядати декілька варіантів планів з різними підходами до компенсації коливання попиту. Для вирішення задач планування виробництва розроблені й застосовуються переважно такі підходи. Лінійне програмування використовується, як правило, для мінімізації сумарних витрат у плановому періоді. У витрати включаються: основна зарплата, понаднормові, на субконтракти, звільнення і найм працюючих, зберігання запасів. Обмеження моделі звичайно включають максимальні потужності й обмежен-ня на міру задоволення попиту в плановому періоді. Лінійні вирішальні правила базуються на застосуванні квад-ратичної функції витрат для конкретної виробничої системи. Функція дозволяє визначати сумарні витрати, що включають: основну зарплату, понаднормові, субконтракти, витрати на зміну чисельності працюючих і зберігання запасів. Як незалежні змінні застосовуються обсяг випуску продукції і чисельність працюю-чих. Функція будується для кожного періоду горизонту плану-вання, що планується. Управляючі коефіцієнти. В основі цього підходу лежить припущення. що ЛПР будує план з урахуванням складного кри-терію і власного досвіду. Цей метод використовує дані про пере-дісторію, пов’язану з рішеннями в минулому, і дозволяє побу- дувати регресію, яка повинна бути використана для побудови плану. Моделювання на ЕОМ дає змогу перевіряти шляхом перебо-ру численні поєднання виробничих ресурсів з метою пошуку найкращого плану на період і на горизонт. Середньострокові плани визначають кількість продукції, яку економічно доцільно проводити на підприємстві. За середньо- строковими планами складаються графіки випуску продукції. У графіку випуску продукції встановлюється кількість кінце-вої продукції, яка повинна бути випущена в кожний період коро-т¬кострокового горизонту планування. Тривалість горизонту пла-нування — від кількох тижнів до кількох місяців. При складанні графіка визначені раніше обсяги виробництва розподіляються у вигляді замовлень на випуск продукції. Графіки випуску продукції в загальному випадку складаються з чотирьох відокремлених одна від одної ділянок: закріпленої, фік¬сованої, заповненої, відкритої. Зміни на закріпленій ділянці звичайно заборонені, оскільки вони спричиняються до зміни планів постачання і виробництва предметів після їх запуску, що призводить до зростання витрат. Фіксована ділянка — це період часу, в який зміни можуть від-буватися, але тільки у виняткових ситуаціях. Заповнена ділянка відповідає часовому інтервалу, на якому всі виробничі потужності розподілені між замовленнями. Зміни на цій ділянці допускаються і можуть зумовити значні зміни термінів виконання замовлень. Відкрита ділянка — це часовий інтервал, на якому не всі виробничі потужності розподілені, і нові замовлення звичайно розміщуються на цій ділянці. Графік випуску продукції створюється на основі інформації про замовлення, прогнози попиту, стан запасів і виробничі поту-жності. Під час побудови графіка виконується перевірка варіан-тів графіка на недовантаження або перевантаження виробничих потужностей. Графік є динамічним і періодично оновлюється. При цьому вирішується завдання обліку ходу виробництва, початок і закін-чення горизонту планування зсуваються праворуч на один тиж-день, наново переглядається оцінка попиту. У зв’язку з тим, що попити, розташовані в далеких періодах, ймовірніше за все, змі-нюються у міру наближення часового інтервалу до фіксованого вигляду, вимога до точності оцінки попиту для початкових пері-одів вища, ніж для віддалених. Планування виробництва на рівні графіка випуску продукції має ряд помітних особливостей залежно від того, працює підпри-ємство на склад чи за замовленнями. Найбільшою мірою змін за-знають управління попитом, розмір партій запуску і кількість продукції, що випускається. У виробництві, що виконує замовлення, в оцінці попиту домі-нують замовлення, що надійшли на даний момент. Графік скла-дається звичайно на основі портфеля замовлень. Розмір партії та кількість продукції, що випускається, як правило, збігаються і визначаються замовленням. Процес складання графіка для таких підприємств є найбільш складним і трудомістким, особливо для багатономенклатурного виробництва. У виробництві, що працює на склад, замовлення надходять зі складу готової продукції. Вони формуються на підставі прогно-зованого попиту з боку потенційних замовників. За цих умов зростає роль прогнозування. У початкові періоди горизонту планування можлива наявність портфеля замовлень, однак їхня питома вага зазвичай є невеликою. Розмір партії тут дуже важливий і визначається виходячи з міркувань економічної ефективності. Змен¬шення розміру партії призводить до зростання частки постійних витрат на одиницю продукції, а збільшення розмірів партії — до зростання запасів і витрат на їх зберігання. Оптимальним є розмір партії, за якого мінімізуються сумарні витрати. Плановий горизонт може змінюватися в широких межах — від кількох тижнів до року і більше. На вибір планового горизон-ту впливають багато чинників, але один чинник є вирішальним. У ERP-системах використовується правило, згідно з яким плано-вий горизонт повинен бути не меншим від найбільшого виробни-чого циклу серед усіх виробів, що розглядаються при складанні графіка. Зараз у практиці планування широко застосовуються ЕОМ і математичні методи. Всі перелічені вище дії виконуються, як правило, за допомогою людино-машинних процедур. Особливо ефективним є застосування ЕОМ в управлінні багатономенкла-турним виробництвом через високу розмірність задачі плану-вання. Значного поширення набув підхід до створення графі- ка, за якого в ході планування певна частина замовлень або пла-ново-облікових одиниць з попереднього графіка фіксується, і новий графік складається на основі двох частин: фіксованої складової колишнього графіка і змін до нього. Всі сучасні при-кладні системи містять модулі для побудови графіка випуску продукції. Планування виробництва на рівні графіка випуску продукції — одна з найважливіших функцій в ERP. Незадовільна її реалізація спричиняється до перевантажень і недовантажень потужностей, надмірного зростання запасів на одні вироби і дефіцит на інші. Навпаки, при задовільній реалізації поліпшується обслуговування замовників, знижується рівень запасів, ефективніше використовуються виробничі потужності. Завдяки рішенню задачі складання графіка стають відомими терміни й обсяги випуску продукції. Управління постачанням, виробництвом деталей і складальних одиниць та іншими скла-довими виробничого процесу залежать від того, які системи організації та управління використовуються. В США у практи- ці управління і в літературі прийнята така класифікація: си- стеми з витратою запасів (pond-draining approach), системи з «проштовхуванням» (push systems), системи з «протягуванням» (pull system) і системи, сконцентровані на «вузьких місцях» (bottlenecks). Системи з витратою запасів сконцентровані на підтримці ре-зервів матеріальних ресурсів, необхідних для виробництва. Оскільки виробники не знають заздалегідь термінів і кількості необхідних замовникові ресурсів, більшість видів продукції в та-ких системах виробляється заздалегідь і складується у вигляді запасів готової продукції або деталей і складальних одиниць; у міру зменшення запасів продукції або її компонентів — виробля-ється для їх поповнення. У системах з «проштовхуванням» увага загострюється на використанні інформації про замовників, постачальників і проду-к¬цію в управлінні матеріальними потоками. Постачання партій матеріалів і напівфабрикатів на підприємство планується якомога ближче до термінів виготовлення деталей і складальних одиниць. Деталі й складальні одиниці виробляються якомога ближче до термінів подачі на складання, готова продукція складається і відправляється як можна ближче до необхідного часу виконання замовлення. Матеріальні потоки «проштовхуються» крізь усі фази виробництва. Системи з «протягуванням» орієнтовані передусім на скоро-чення рівня запасів на кожній виробничій фазі. Якщо в поперед-ній системі роль графіка зводилася до визначення того, що робити далі, то в даній системі переглядається тільки наступна стадія, з’ясовується, що необхідно робити для її виконання, і виробляються необхідні дії. Партії у виробництві переміщаються від ранніх стадій до пізніх без проміжного складування. Існує чимало різновидів і найменувань для подібних систем: «точно-в-термін» (Jast-in-Time), виробництво з коротким циклом, системи з візуальним управлінням тощо. Рис. 4.8. Спрощена схема системи, побудованої на базі ERP-концепції Донедавна підхід до розв’язання задач планування вироб- ництва в системах ERP залишався переважно в тому вигляді, в якому він усталився у системах MRPII. Стисло його можна ви-значити як підхід, що ґрунтується на активному використанні календарно-планових нормативів на виробничі цикли. Недолік такого підходу полягає в тому, що він суперечить необхідності оптимізації планування. Проте елементи оптимізації планування в традиційних MRPII/ERP-системах трапляються лише на ниж-ньому рівні — під час вирішення задач оперативного планування з використанням методів теорії розкладів. З іншого боку, си-стеми, побудовані на базі стандарту ERP, переважно орієнтовані на внутрішню діяльність підприємства — в них була виключена можливість управління розширеним виробничим ланцюгом «постачальник—виробник—споживач», тобто логістичним лан-цюгом (рис. 4.8 та рис. 4.9). Рис. 4.9. Переваги та недоліки ERP-системи 4.4. СИСТЕМИ ПЛАНУВАННЯ РЕСУРСІВ ПІДПРИЄМСТВА, СИНХРОНІЗОВАНОГО ЗІ СПОЖИВАЧАМИ (CSRP) Концепція CSRP (Customer Synchronized Resource Plan¬ning), використовуючи перевірену часом інтегровану функціональність ERP, розширює поняття планування від виробництва далі, на покупця. Ідеологія CSRP надає дійові методики і реалізуючі їх програмні продукти для створення товарів, що модифікуються під конкретного користувача. ? Інтеграція покупця в процес виробництва Надання покупцеві можливості впливати на процес виробниц-т¬ва — це основа ідеології і головне достоїнство CSRP. Порушення виробничого ритму за рахунок вимог покупців, що надходять у реальному часі в системи щоденного планування і виробництва, примушує керівників підприємств не тільки звертати увагу на ви¬робництво, а й враховувати під час оперативного управління кри¬тичні чинники ринку і зміну споживних властивостей продукції. Виробники, що спонукаються взаємодією з покупцем, а не внутрішніми проблемами виробництва, можуть отримати істотні переваги, якщо систематично матимуть відповідь на такі питан-ня: • Які продукти потрібно виробляти? • Які послуги варто пропонувати? • Які нові ринки є перспективними для розвитку? Виробники приймають рішення щодо вибору продуктів і рин-кових ніш, але ці рішення ізольовані від виконавчих підрозділів організацій, які, власне, і займатимуться їх реалізацією. З іншого боку, в класичних системах планування і управління ресурсами «відчуття» ринку і критична інформація про покупця недоступні системі планування бізнесу та ізольовані в різних локальних під-системах, розкиданих по організації. Кожний із цих підрозділів приділяє значну увагу роботі з по-купцем. Але в більшості традиційних виробничих структур ці підрозділи витрачають дуже мало часу на взаємодію з плановими або виробничими відділами. За створення зразків продукції відповідає конструкторський відділ. Відділ обслуговування покупців відповідає тільки за організацію приймання замовлень. Але конструкторський відділ повинен розуміти, що він створює продукт для споживача, який потім продаватиметься комерсантом. Інформація про те, що справді потрібно, що працює, а що ні, що продаватиметься, а що ні, виходить від покупця. Завдання підрозділів продажу й маркетингу: розуміючи, що необхідно по-купцям, пропонувати відповідні рішення і тим самим створювати попит. Крім того, вони володіють цінною інформацією про нові ринкові тенденції, тиск конкурентів, проблеми обслуговування покупців, ціноутворення і попит. Сервісні служби володіють великою кількістю іншої корисної інформації відносно того, які продукти викликають проблеми, які удосконалення найчастіше цікавлять покупців і які послуги, що пропонуються, можуть бути найціннішими для покупця. Нареш-ті, конструкторський відділ, а також відділ досліджень і розробок займаються створенням нових продуктів та їх прототипів, розроб¬ляють продукцію майбутнього. І у зв’язку з цим також виникають питання: як нові продукти будуть прийняті на ринку, що має прийнятну ціну, а що ні. Все це — життєво важливі проблеми. Рис. 4.10. Центри формування інформації про покупців CSRP — це перша бізнес-методологія, яка включає в ядро сис-теми управління бізнесом діяльність, орієнтовану на інтереси покупця (рис. 4.10). Уперше запропонована методологія ведення бізнесу заснована на поточній інформації про покупця. CSRP переміщує фокус уваги з планування виробництва на планування замовлень покупців. Інформація про клієнтів і послуги кладеться в основу діяльності організації (рис. 4.11). CSRP — планування ресурсів, синхронізоване з вимогами покупців Рис. 4.11. Спрощена схема CSRP-системи Виробниче планування не просто розширюється, а замінюєть-ся вимогами клієнтів, відомості про які надходять з підрозділів, орієнтованих на роботу з покупцями. Таким чином, CSRP примушує переглянути всю бізнес-практи¬ку, зосереджуючи увагу на ринковій активності, а не на виробничій діяльності. Бізнес-процеси синхронізуються з діяльністю покупців. Розгляньмо, наприклад, процес опрацювання замовлень, який тепер включає, крім функції введення замовлення, функції про-дажу і маркетингу. Опрацювання замовлень починається не із замовлення, а з роботи з покупцем або навіть з потенційним кліє-нтом. Як міняються ділові процедури в нових умовах? • Продавці більше не розміщують замовлення. Вони форму-ють замовлення спільно з покупцем (можливо, на його робочому місці), виявляючи його потреби, якими динамічно визначаються вимоги до продуктів і до їх виробництва. Технологія конфігуру-вання замовлень дозволяє перевіряти їх здійсненність ще до того, як вони розміщуватимуться. • Опрацювання замовлень включає аналіз інформації про по-тенційних клієнтів. Системи управління контактами і генератори звітів об’єднуються із системами створення замовлень і виробни-чого планування, щоб надати відомості про необхідні ресурси до того, як замовлення буде розміщене. Тенденції ринку, попит на продукцію та інформація про пропозиції конкурентів — усе це пов’язується з ключовими бізнес-процесами. • Статичні цінові моделі замінюються на інструмент ціноут-ворення, який дозволяє визначити «оптимальну» вартість кож-ного продукту для кожного покупця. Збільшується прибутко-вість продукції і точність виготовлення. CSRP розширює значення терміна обслуговування покупців. Тепер це вже не тільки звичайна телефонна підтримка і видача довідок про рахунки. За використання моделі CSRP послуги, що надаються клієн-там, стають важливою ланкою діяльності підприємства, центром управління всією організацією. При цьому підрозділ технічної підтримки відповідає за доведення необхідної інформації про по-купців до виконавчих центрів організації. У цьому випадку: • засоби підтримки користувачів збігаються з ключовими до-датками планування, виробництва й управління. Необхідна ін-формація про покупців і товари заздалегідь надходить до підроз-ділів, що відповідають за виробництво, продаж, дослідження і розвиток, а також до інших підрозділів; • технології, засновані на Web, розширюють можливості під-тримки покупців, надаючи віддалений, цілодобовий сервіс за принципом самообслуговування. Ключові виконавчі системи ав-томатично оновлюються, забезпечуючи оперативну видачу від-повідей на запити покупців; • підрозділи підтримки покупців стають центрами продажу і підтримки. Інтеграція з продажем, опрацюванням замовлень та управлінням забезпечує необхідну базу та інфраструктуру для розширення діяльності з підтримки покупців на область продажу, забезпечуючи просування нових і супутніх продуктів і послуг. Планування діяльності й виробництва продукції також на-повнюється новим змістом — воно стає плануванням замовлень покупців і динамічним виробництвом. Що це означає? • Безпосереднє володіння інформацією про конфігурацію за-мовлень дозволяє виробничим підрозділам поліпшити процес планування завдяки зменшенню повторної роботи і зниженню числа затримок через наплив замовлень. Поліпшене виробниче планування дає можливість більш точно оцінювати терміни по-стачання і виконувати їх вчасно. • Планування виробництва істотно поліпшується завдяки опорі на реальні клієнтські замовлення, а не на прогнози або оцінки. Маючи доступ у реальному часі до точної інформації про наявні замовлення покупців, планові відділи можуть динамічно визначати групування робіт, послідовність виконання замовлень, закупівлі. Така можливість має особливе значення в умовах недостатності ресурсів — матеріальних, фінансових або людських. Маневрування ресурсами забезпечує надання їх у потрібному обсязі в потрібний час. • Сконфігуровані вимоги до продукту можуть передаватися безпосередньо від покупця до субконтрактора або постачальника, тим самим усуваються помилки і затримки, які трапляються при переведенні замовлень покупців у замовлення на купівлю звичайним способом. Зміни в замовленні покупця можуть зумовлювати автоматичні зміни в замовленнях постачальникам через систему оперативного перепланування, що скорочує кількість пере¬робок та усуває затримки. Якість продуктів і точність замовлення основних комплектуючих можуть бути значно поліпшені, а також зменшені періоди їх доставки. Усі ці переваги наочно ілюструють, наскільки вигідною може бути переорієнтація бізнес-функції та інтеграція потреб покупця в ядро виконавчої системи. Результати успішного застосування CSRP — це підвищення якості товарів, зниження часу постачання, підвищення споживної цінності продукції і т. ін. і — як наслідок — зниження виробни-чих витрат, а також — що ще важливіше, — розвиток інфраст-руктури для створення індивідуалізованих рішень, що конфі-гуруються, поліпшення зворотного зв’язку з покупцями і забез-печення оптимального сервісу для покупця. Це не технологічна ефективність, яка забезпечує лише тимчасову перевагу в конку-ренції, а здатність створювати продукти, що задовольняють різ-номанітні потреби покупця, і кращий сервіс, тобто отримання стійкої конкурентної переваги. ? Інтеграція на основі відкритих технологій Здатність взаємодії безлічі додатків, розроблених за допомо-гою різних технологій, — це ключова вимога, що забезпечує ус-піх CSRP. Зараз можлива побудова уніфікованого додатка для управління виробництвом на базі окремих модулів, розроблених різними виробниками. Виробництво, управління, продаж, обслу-говування покупців, технічне обслуговування та інші орієнтовані на покупця бізнес-функції можуть виконуватися у відповідних підрозділах з використанням спеціалізованого програмного за-безпечення, при цьому додатки можуть надавати й отримувати критичну для бізнесу інформацію з центральної бізнес-системи, яка базується на CSRP і використовується іншими підрозділами організації. Розгляньмо звичайну виробничу ситуацію: продавець зустрі-чається з новим покупцем на його робочому місці, разом вони обговорюють поточні та майбутні вимоги до продукту, обгово-рюють варіанти, ціни і послуги, добирають рішення, що відпові-дає унікальним вимогам покупця, рішення, яке жоден інший кон-курент не може зараз запропонувати. Використовуючи додаток CSRP, продавець здатний зареєст-рувати специфічні вимоги до продукту, зафіксувати ціну й авто-матично надіслати цю інформацію до штаб-квартири організації, де інформація динамічно перетворюється в детальні інструкції щодо виробництва та планування. Створюються специфікації на матеріали і комплектуючі для виробництва, автоматично визна-чаються виробничі маршрути, резервуються та замовляються не-обхідні матеріали і, нарешті, створюється наряд-замовлення для виробництва. Ключова інформація про клієнта динамічно вико-ристовується в основній діяльності підприємства. Збереження ін-формації про переваги покупця в загальній базі даних, що вико-ристовується в сервісних підрозділах, відділах технічного обслу-говування, досліджень, планування виробництва, дозволяє досяг-нути необхідного рівня синхронізації діяльності підприємства з потребами покупців. Відкриті технології зробили можливим приймання складних замовлень на відстані: покупець за допомогою ІNTERNET отри-мує доступ до Web-сервера виробника і в будь-який час дня або ночі вводить замовлення — стандартне або видозмінене. Поку-пець може змінити попередні замовлення, перевірити стан ще не виконаних замовлень або запитати нові доповнення. Оскільки та-ка взаємодія інтегрована в основні бізнес-системи підприємства, дії покупця автоматично впливають на планування, виробництво і/або обслуговування покупців. І знову діяльність підприємства синхронізується з покупцем. Відкриті технології роблять обидва ці сценарії і методологію CSRP реальністю. 4.5. РОЗВИНУТІ СИСТЕМИ ПЛАНУВАННЯ (APS) Дещо пізніше з’явилась ще одна концепція, а саме: APS (Advanced Planning System) — «Розвинуті системи плану-вання». Для таких систем характерне використання економіко-математичних методів розв’язання задач планування з по-ступовим зниженням ролі календарно-планових нормативів на виробничі цикли, а також використання оптимізаційних методів на вищих рівнях управління та застосування комп’ютерних інструментальних засобів підтримки прийняття управлінських рішень. Управління в системах четвертого типу сконцентровано на так званих «вузьких місцях», чи стадіях виробничого процесу, що гальмують виробництво, оскільки їхня продуктивність є мен-шою, ніж на інших ділянках виробничої системи. Розвиток ідей, методів і засобів управління виробничими сис-темами сприяв появі систем нового покоління, що отримали наз-ву «Розвинуті системи управління» (Advanced Planning and Sche-duling System — APS). Їх не можна розглядати лише як нові ін-формаційні технології. Навпаки, нові технології в них використо-вуються для реалізації нових методів організації та управління виробництвом. Протягом 1994—1996 рр. ринок систем ERP розвивався ви-сокими темпами. Обсяг продажу зростав приблизно на 40% у рік. Такі темпи вважаються надзвичайно високими в будь-якій галузі. Водночас обсяг продажу АРS-систем зростав удвічі швидше. Починає виявлятися тенденція до фундаменталь- ної зміни тих концепцій управління, на яких будуються сучасні системи ERP. Більшість із цих концепцій суперечать вимогам до управління в динамічних виробничих системах. Замовникам продукції потрібні якомога менша тривалість виконання замовлень і висока точність дотримання термінів. Часто ці ви-моги вимірюються вже не днями або тижнями, а годинами і хвилинами. Крім того, все виразніше виявляється така вимога до систем управління, як поєднання масового характеру виро-бництва з індивідуальним виконанням виробів (mass customi-zation). Можна виділити такі напрями, в яких здійснюється перехід від ERP до АРS: • підвищення міри деталізування при плануванні потуж-ностей, що дозволяє ухвалювати більш обґрунтовані планові рішення; • поява нових інформаційних технологій, що дозволяють одночасно підвищити міру деталізування і вирішувати в ре-альному часі задачі аналізу і моделювання; • включення в системи спеціальних засобів, які пристосо-вані до роботи вищої ланки; • розгляд задач з одночасними обмеженнями на доступні матеріальні ресурси і потужності; • формування планових рішень одночасно для багатьох за-водів; • поліпшення зворотного зв’язку у вигляді задач обліку фа-ктичного стану процесів за рахунок підвищення точності й оперативності; • широке застосування методів оптимізації планових рі-шень; • динамічний підхід до ведення інформації про виробничі цикли. Зазвичай системи АРS являють собою поєднання чотирьох взаємопов’язаних процесів. У всіх чотирьох процесах досить часто використовуються одні й ті самі підходи до планування, але вхідні дані та обмеження розрізняються. На рис. 4.12 показані чотири кроки моделі АРS. Рис. 4. 12. Основні кроки моделі АРS ? Виробничий графік Планування виробничого ланцюга (Supply Chain Planning) — це найвищий рівень системи планування. Підхід до планування передбачає облік необхідних чинників як усередині, так і поза підприємством. Можуть включатися такі зовнішні чинники, як потужності суміжників і постачальників, рівень попиту з боку покупців продукції, варіанти організації транспортування. За допомогою SCP виробляються допустимі плани з ураху-ванням обмежень на виробничі потужності по всьому виробни-чому ланцюжку. Мета даного кроку полягає в забезпеченні ко-ординації планів і графіків, що базуються на використанні цих ресурсів. Планування діяльності підприємства полягає в тому, що біз-нес-плани, виробничі потужності й матеріальні ресурси оптимі-зуються з метою задоволення ринкового попиту або попиту окремих замовників. На цьому рівні розглядаються основні виро-бничі ресурси і матеріальні потреби і виробляється прийнятний план, який потім поліпшується з урахуванням інших обмежень і цілей підприємства. Як обмеження звичайно розглядаються по-тужності виробництва і розподільної мережі, доступність мате- ріальних ресурсів та інших найбільш важливих ресурсів, а як ці- лі — міра задоволення попиту замовників, прибуток, рівень запа-сів тощо. Взагалі цей крок об’єднує і оптимізує виконання функ-цій, що традиційно виконуються модулями ERP верхнього рів- ня (бізнес-планування, планування виробництва, формування графіка випуску продукції, розрахунок потреб на виробничу про-граму). Використовуючи отриманий раніше план роботи підприємст-ва як вхідний, модуль виробничого планування (Production Sche-duling) має справу з доступними матеріальними ресурсами, де-талізованою інформацією про потужності та інформацією про стан ходу виробництва для того, щоб вирішувати задачу кален-дарного планування, маючи за головну мету виконання термінів завершення замовлень. У ході виробничого планування, яке має календарний характер, використовуються ті самі цілі й обме-ження, що і на попередньому рівні, але й інформація більш де-талізована. Матеріальні ресурси для підвищення точності ви-значення короткострокових матеріальних потреб прив’язані до конкретних операцій, на яких вони використовуються. Виробни-че планування виконує також функцію регулювання для більш високого рівня, щоб скоригувати терміни і кількості під час ре-алізації матеріальних потреб всередині підприємства і від су- міжників. Оцінка можливості виконання (available-to-promise-ATP) — це засіб забезпечення функціонування трьох попередніх рівнів. Во-на спеціально введена в систему, щоб підвищити точність визна-чення дат виконання, які обіцяються замовникам замовлень. При вирішенні цієї задачі використовується інформація з існуючого виробничого плану, а також про ресурси, що необхідні для виро-б¬ництва існуючих, але не включених до плану замовлень. Нову концепцію обчислення АТР у реальному часі, тобто на основі не статичного, а динамічно скоригованого виробничого плану, інко-ли називають задачею про можливість виконання замовлень на основі доступних потужностей (capable-to-promise -CTP). Системи АРS являють собою сьогодні швидше узагальнену модель і модулі, ніж інтегровані продукти. Вони використовую-ться спільно з наявними системами планування. У сучасних системах АРS застосовують широкий спектр алгоритмів оптимізації. Найпоширенішими є такі підходи. 1) Лінійне програмування. Задача оптимізації вирішується для лінійної цільової функції при лінійних обмеженнях і обме-женнях на змінні. 2) Алгоритми типу випадкового пошуку. Група методів, заснована на принципі генерування, аналізу й добору кращо- го варіанта плану. При цьому кращий поточний план може бути для наступної ітерації базовим, в околі якого триватиме по-шук. 3) Алгоритми, засновані на теорії обмежень. Теорія обме-жень являє собою підхід до календарного планування, в якому спочатку будується план для «вузького місця» в системі, а потім від нього — для всіх інших елементів системи. 4) Евристичні алгоритми. Група розвинутих методів, досту-п¬на завдяки потужності сучасних ЕОМ. Це, як правило, алгоритми невипадкового пошуку, які полягають у перегляді змінних у позитивному і негативному напрямку для поліпшення плану. При цьому активно використовується специфіка задачі. Одна з особливостей реалізації евристичних алгоритмів: фірми-виробники систем АРS часто продають їх у вигляді «чорних ящиків», не розкриваючи їхнього змісту. Моделювання і підтримка прийняття рішень — один із ос-новних засобів підходу АРS, особливо тих, які орієнтовані на планування найвищого рівня. Практично всі АРS-системи володіють можливостями моде-лювання. Діапазон можливостей широкий: від ведення численних копій планів для покрокового порівняння — до аналізу витрат для різних планів. Більшість систем мають вбудовані панелі, які відображають результати оптимізації та організують їх передачу для імітаційного моделювання. Потенціал систем АРS у галузі моделювання далеко не вичер-паний. Зараз вони орієнтовані переважно на підтримку прийняття тактичних рішень, пов’язаних з появою нової продукції або но-вих замовлень. Потенційні можливості поширюються на такі рі-шення стратегічного характеру, як будівництво нових заводів, об’єднання підприємств, поведінка ринку. Сьогодні більшість фірм-розробників включають модулі АРS у ядро своїх систем типу ERP або вступають в кооперацію з про-відними виробниками. 4.6. ДЕЯКІ ОСОБЛИВОСТІ ПОДАЛЬШОГО РОЗВИТКУ Таким чином, концепції MRPII/ЕRР постійно еволюціонують і вдосконалюються. У кожний момент часу в них умовно можна виділити три шари. Перший шар — це методи й засоби, перевірені практикою і закріплені у вигляді стандартів. У США існує система стандартів, яка підтримується державою, зокрема Міністерством оборони. У цих стандартах сформульовані вимоги до інформаційних систем фірм, що виконують державні замовлення. У результаті на стадії формування контракту підвищується упевненість держави в розумному витрачанні бюджетних коштів, а на стадії його виконання здійснюється всебічний контроль за термінами виконання і фактичними витратами. Як приклад можна навести урядовий документ «Вимоги до систем управління матеріальними процесами» (Material Management and Accounting System — MMAS). Стандарти насамперед визначають вимоги до функціональної насиченості систем управління, методів і результатів отримання звітності про фінансове становище контрактів. Фірми — вироб-ники базових систем — ретельно дотримуються цих стандартів. Саме з цієї причини порівняльний аналіз різних базових систем (особливо крупномасштабний) може вимагати значних зусиль, оскільки, на перший погляд, функціональні можливості практич-но не розрізняються. Другий шар складають досить стійкі, часто застосовувані ме-тоди й прийоми, які, однак, не мають обов’язкового характеру. Ці методи і прийоми можна виявити при більш глибокому аналізі функціональних структур. За приклад можуть правити методологія змінного планування в МРS/МRР, алгоритми утворення партій в МRР, правила пріоритетів в SFС тощо. Цей шар жорстко не регламентується, проте являє собою досить струнку систему взаємопов’язаних ідей і методів. Голо-вна роль у підтримці цієї частини концепцій MRPII /ERP на-лежить, безумовно, Американському товариству управління виробництвом і запасами (АРІСS), заснованому в 1957 р. Сьо-годні АРIСS об’єднує близько 70000 фахівців з багатьох країн світу, що представляють майже 20000 компаній. У їх числі — приблизно 500 компаній США, які працюють у галузі систем MRPII /ERP. Серед напрямів діяльності АРIСS — поширення інформаційних матеріалів; сповіщення про публікації і проекти в сфері утворення і перепідготовки; реалізація двох програм сертифікації фахівців з управління виробництвом і запасами (СРIМ) та інтегрованими ресурсами (СIRM); проведення очних і заочних конференцій. АРIСS періодично видає тлумачний словник «APICS’s Dictionary», який містить сотні термінів, що стосуються MRPII /ERP, і сприяє уніфікації термінології. Цей момент є дуже важливим, особливо для потенційних користу-вачів в Україні на стадії аналізу і вибору базової системи. Зна-чний інтерес становлять списки літератури APICS, які є в INTERNET, з різних питань стосовно MRPII /ERP. В APICS діє гнучка система членства, яка передбачає чотири види членст-ва — для корпорацій, фахівців, студентів університетів і ко- леджів, пенсіонерів. Всередині APICS виділена група, що спеціа-лізується з управління складними галузями промисловості (CI SIG), як-от: аерокосмічна й оборонна. Третій шар ідей і методів MRPII /ERP становить те нове, що вносять у свої базові системи фірми — виробники програмних продуктів. Реалізовані на їх основі нові інформаційні технології являють собою «ноу-хау» фірм-розробників. Як правило, саме в цьому шарі можна виявити значні відмінності продуктів різних фірм. Деякі з нових технологій можуть досить відчутно впливати на ефективність побудови великих інформаційних систем. До та-ких належать, наприклад, «Система динамічного моделюван-ня» (Dynamic Enterprise Modeling — DEM) фірми ВААN — проблемно-орієнтована САSЕ-технологія проектування систем управління підприємствами. Вагоме місце серед ідей і методів систем MRPII /ERP нале-жить спеціально розробленим методикам впровадження систем. Аналіз літератури і досвід спілкування з фахівцями різних фірм показують, що нині склалося стійке уявлення про те, в якій по-слідовності та якими методами треба впроваджувати системи ти-пу MRPII /ERP. Ретельне планування проектів з впровадження, організації діяльності колективів, ставка на перепідготовку пер-соналу всіх рівнів (особливо вищого рівня) — ось далеко не пов-ний перелік умов досягнення позитивних результатів. Цією робо-тою займаються сотні консалтингових фірм різного масштабу, університети, бізнес-школи. Наявність могутньої інфраструктури і методології побудови систем сприяє досягненню високого рівня ефективності при впровадженні систем управління типу MRPII /ERP на промисло-вих підприємствах. За деякими оцінками, впровадження таких систем сприяє скороченню запасів до 30%, підвищенню продук-тивності праці до 25%, зростанню кількості замовлень, викона-них у термін, до 20%. * * * Починаючи з наступного розділу, розглядатимуться конкретні види інформаційних систем, що використовуються на підприємст¬вах. Умовно їх можна поділити на дві групи: а) інформаційні системи для підтримки окремих видів управлінської діяльності, а саме: ? автоматизації процесів управління проектами на підпри-ємствах; ? автоматизації бізнес-планування та оцінки інвестицій на підприємствах; ? автоматизації процесів прийняття управлінських рішень на підприємствах (системи підтримки прийняття рішень, екс-пертні системи); б) інтегровані інформаційні системи управління підприєм-ствами та корпораціями, концептуальну основу яких станов-лять стандарти MRP II-ERP-CSRP. АВТОМАТИЗАЦІЯ УПРАВЛІННЯ ПРОЕКТАМИ НА ПІДПРИЄМСТВАХ 5.1. ВВЕДЕННЯ В УПРАВЛІННЯ ПРОЕКТАМИ Щоденно тисячі керівників підприємств використовують методи управління проектами (УП). Це дає їм змогу контролювати хід виконання і завершення проектів у визначений термін, не перевищуючи запланованих витрат бюджетних коштів та залишаючись на високому технічному рівні. Кожний проект є у своєму роді унікальним, саме тому необхідно точно знати, з чого починати проект і чим завершувати, при цьому суворо дотримуючись бюджету. Звичайно проекти виконуються людьми, що мають малий досвід спільної роботи. Так само ймовірно, що дехто з учасників проекту працюватиме поза місцем реалізації проекту. Все це часто робить управління проектом досить складним. Найзагальніше уявлення про управління проектом включає ретельне обмірковування того, чого користувач хоче досягнути, планування всіх кроків і отримання необхідних для них ресурсів. На практичному рівні управління проектом — це дії користувача, спрямовані на розв’язання проблем, що постають через затримки, зміни, перешкоди та у зв’язку з можливостями, які відкриваються в процесі реалізації проекту. Успішне управління проектом вимагає постійної пильності: визначення того, що реально відбулося, скільки робіт було фактично виконано, що залишилося зробити і хто стане у пригоді у ході розв’язання проблеми. Однак це не все, що необхідно для управління. Використовуючи програмне забезпечення з управління проектами, можна виявити й спробувати вирішити потенційні проблеми. Встановлений порядок проектування гарантує користувачеві можливість кваліфіковано і вчасно інформувати своїх співробітників про вибір, його варіанти і поточні роботи, а також подати проект ясно і переконливо вищому керівництву, завдяки чому можна буде одержати його підтримку у разі необхідності. ? Стислий опис процесу Перед складанням розкладу проекту всі його учасники повинні знати свої функції з урахуванням усіх рекомендацій та порад, що допоможе безперебійній роботі програмного за- безпечення для успішного досягнення мети. Необхідно також розуміти кроки по зміні проекту, коли всі його структури будуть задіяні. Якщо реалізація проекту вже почалася, можна об’єднати чи відрегулювати існуючу методологію планування нового проекту або змінити існуючий проект. У різні періоди життєвого циклу проекту необхідно буде користуватися та- кими ключовими поняттями: планування, контроль, управління. 1) Планування проекту означає, що необхідно виконати добірку відповідних документів, необхідних для: установки і визначення набору робіт, що виконуються, підготовки робочого розкладу, доручення і розподілу ресурсів за умов конкуренції і для розробки прийнятного бюджету. 2) Контроль проекту означає дотримання наміченого курсу, що передбачає: оцінку виконаного в разі потреби вживання коригуючих заходів, оцінку варіантів і планування поточних робіт. При цьому слід проінформувати співробітників про досягнуте і порадити, де їм необхідно поліпшити свою роботу, після чого вони розпочинають виконання. 3) Управління означає здійснення точного сповіщення команди керівників проекту і клієнта про те, що сталося, що може статися, що у зв’язку з цим треба зробити і чого вже не мож¬на змінити. При цьому слід пояснити команді керівників про- екту мотиви того, чому їм потрібно робити все те, що від них залежить. ? Оновлення процесу Коли розклад проекту готовий, його учасники повинні знати свою роль в управлінні проектом. Отже, необхідно вста- новити зв’язок між усіма учасниками проекту для передачі інформації про виникаючі зміни в процесі роботи. Зміна роз- кладу на основі отриманих даних і порівняння його зі складеним планом гарантує ефективне використання ресурсів, відстеження вартості проекту і бюджету, збереже час виконання і вартості робіт з урахуванням виникнення непередбачених обставин. ? Оновлення циклу У процесі реалізації проекту слід встановити частоту, з якою необхідно контролювати процес (приблизно раз на тиждень або на два тижні). Для цього встановлюється точна дата, визначаються порядок і методи звітності про виконані роботи. 1) Введення фактичної інформації. Враховуючи, хто і які роботи виконував та вартість останніх, можна поліпшити кошторис майбутніх робіт. При визначенні фактично виконаної частини проекту записують фактично використаний обсяг ресурсів для кожної роботи і тривалість її виконання, а також те, що ще необхідно для її завершення. Дані, що використовуються для аналізу, повинні бути максимально точні. 2) Складання розкладу проекту. Після збору необхідних даних з різних місць, програм/бази даних складається розклад проекту. 3) Порівняння отриманих результатів з початковим планом — це найкращий спосіб виявити правильність реалізації проекту. Якщо є відставання в роботі, можна усунути його причину, змінивши при цьому розклад робіт і/або відкоригувавши їхній зміст. Якщо коригування за часом зробити неможливо, треба пересвідчитися в тому, що всі учасники проекту оповіщені про затримку для коригування власних планів. Чим раніше це буде зроблено, тим меншими будуть втрати часу в подальшому. 4) Вирівнювання ресурсів вирішує проблеми, пов’язані з плануванням робіт, на які використовуються одні і ті самі ресурси. Для підготовки реалістичного плану необхідно пересвідчитися, що розклад передбачає нормальну витрату ресурсів. Для цього вирівнюють графік використання ресурсів. Якщо на ньому виявляються важко керовані піки і западини, можна використати механізми стиснення, розтягнення і/або розбиття для кращого використання ресурсів на основі поточних вимог. 5) Аналіз продуктивності. Після складання розкладу і вирівнювання ресурсів проводиться аналіз даних: на екрані, у звітах по лінійних і логічних діаграмах, профілях використання ресурсів, а також інших табличних і графічних звітах. Звіти і графіки дозволять відстежувати процес робіт і фактичні витрати, порівнювати прогрес і витрати з директивним планом, а також передбачати тенденції розвитку для більш точного визначення подальших дій. Вони дозволять відповісти на першочергові пи-тання: чи буде проект завершений вчасно в межах бюджету? чи будуть ресурси використані ефективно? 6) Коригування розкладу. Якщо після ретельного планування і введення фактичної інформації з’ясовується, що проект відстає від графіка, то це означає, що ресурси були неправильно розподілені, вартості перевищують існуючий бюджет, змінено графік фінансування або трапилася будь-яка з багатьох інших імовірних подій. У такому разі треба розпочати здійснення резервного плану і/або відкоригувати з урахуванням вимог, що змінилися, розклад. 7) Інформаційні потоки. Проектна документація повинна міс¬тити точну інформацію про те, яким чином здійснюватиметься передача інформації. Якщо робочі групи не знають, що відбувається, вони не зможуть ефективно зробити свою роботу. Тому на стадії проектування визначається, хто відповідатиме за передачу даних, що, де і коли має бути передано. Використання графічних звітів, діаграм і часових шкал полегшує розуміння. Для поліпшення наочності виділяють проблемні області. Проектні розбіжності слід зробити очевидними. Треба пам’ятати, що рівень деталізації в кожному повідомленні повинен відповідати рівню поін¬формованості того, для кого воно призначене. 8) Управління по звітних періодах. Слід забезпечити контроль у розрізі періодів часу. Це дозволяє відстежувати динаміку виконання проекту: що виконано за останній звітний період, за поточний період, на поточну дату тощо. ? План проекту Для розробки плану проекту треба визначити рівень деталізування, набір робіт, а також проаналізувати підходи до управління майбутнього проекту, відповідаючи на такі запитання: ? Якою є загальна тривалість проекту? ? Що треба знати про ресурси в проекті? ? Наскільки є точним план? ? Як часто буде коригуватися план? ? Хто повинен отримувати інформацію про виконані роботи? ? Які типи звітів будуть необхідні? ? Які графіки допоможуть забезпечити найкращий обмін інформацією? ? Скільки часу можна затратити на управління проектом? 1) Набір робіт. Для створення первинного розкладу визначають набір робіт, а також час, необхідний для виконання кожної з них, і залежності між ними. Для визначення виконавців, що надають фактичну інформацію про виконання при коригуванні, призначають відповідальних за виконання кожної роботи. 2) Логічна залежність між роботами. Логіку проекту слід визначати звичайно з технологами або керівниками груп, що виконують роботу, оскільки ніхто, крім них, не знає краще, що має бути зроблене, чому і в якій послідовності. 3) Критичний шлях — послідовність робіт, що вимагає найбільшого часу до завершення. За обмеженого терміну виконання проекту досліджують, чи можна стиснути розклад, виконуючи роботи паралельно, чи достатньо ресурсів для виконання одразу кількох різних завдань тощо. 4) Остаточний план. Коли складений розклад задовольняє всіх учасників проекту, зіставляють графіки споживання ресурсів і виконання робіт. Розклад вказує на необхідні дії і на те, коли вони повинні бути зроблені, на ресурси, необхідні для виконання робіт, — це люди, обладнання, матеріали і гроші. Доцільно пересвідчитися, що ресурси доступні в ті моменти і в тій кількості, коли і наскільки це необхідно. 5) Співвідношення вартості й тривалості проекту. Чи мож¬на забезпечити завершення проекту в більш стислі терміни за наявності більшої кількості грошей або більшого обсягу ресурсів? Якщо остаточне рішення щодо фінансування (графіка й обсягу) прийнято, можна розпочинати роботу. 6) Організація проектної інформації. Для поліпшення інфор-мативності роботам призначають коди по фазах, зобов’язаннях, відділах, місцях розташування і т. ін. Коди робіт дозволяють зосереджувати увагу на ключових елементах для уточнення уявлення про те, що відбувається. 7) Варіанти виконання проекту. Що може трапитися непередбаченого? Що станеться, якщо основні ресурси перерозподіляться на інші роботи? Якщо нова технологія дозволить економити матеріали, чи вдасться зберегти якість виробництва? Скіль¬ки часу піде на зміну цін? Варіанти реалізації проекту допоможуть швидко перебудувати план у разі непередбачених обставин. Планування, контроль, управління, зв’язок і аналіз — усе це і є управлінням проектом. 5.2. БАЗОВІ ФУНКЦІОНАЛЬНІ МОЖЛИВОСТІ АВТОМАТИЗОВАНИХ СИСТЕМ УПРАВЛІННЯ ПРОЕКТАМИ Розвиток інформаційних технологій в останні роки практично звів нанівець розходження між системами за об’ємними показниками потужності (розміри планованого проекту по роботах і ресурсах, швидкість перерахування проекту). Навіть дешеві пакети сьогодні здатні підтримувати планування проектів, що складаються із десятків тисяч задач і використовують тисячі видів ре- сурсів. Вивчаючи матриці порівняння основних функцій систем, також досить важко знайти істотні прогалини в тій або іншій системі. Виявити відмінності в реалізації окремих функцій часто вдається лише за детального вивчення і тестування системи. При виборі програмного продукту користувачеві необхідно, насамперед, зрозуміти, для вирішення яких задач буде потрібна система управління проектами, проаналізувати характер діяльності власної організації з погляду можливості й доцільності застосування проектної форми планування і управління. При цьому необхідно чітко уявляти, яка діяльність може плануватися у вигляді проектів, наскільки детально необхідно планувати й контролювати проекти. До основних функціональних можливостей наявних автоматизованих систем управління проектами слід віднести: 1. Засоби опису комплексу робіт проекту, зв’язків між роботами та їхніх часових характеристик: a) засоби опису і типи планування задач: (виконати Якомога Раніше, Як Можна Пізніше, роботи з фіксованою датою початку/закінчення, можливість прив’язки тривалостей задач до обсягу визначених ресурсів, резерви часу, що обчислюються, — повний, вільний і т. ін.); б) засоби встановлення логічних зв’язків між задачами; в) багаторівневе подання проекту; г) підтримка календаря проекту, підтримка календарів ресурсів. 2. Засоби підтримки інформації про ресурси і витрати за проек¬том і визначення ресурсів і витрат для окремих робіт проекту: a) ведення списку наявних ресурсів, можливість задання нормального і максимального обсягів ресурсу; б) підтримка ресурсів із фіксованою вартістю і ресурсів, вартість яких залежить від тривалості їхнього використання; в) розрахунок необхідних обсягів ресурсів; г) ресурсне планування (виділення перевантажених ресурсів і задач, що їх використовують), автоматичне/командне вирівнювання профілів завантаження ресурсів (з урахуванням обмежень за часом або з урахуванням обмеження на ресурс, з урахуванням пріоритетів задач). 3. Засоби контролю за ходом виконання проекту: a) засоби відстежування стану задач проекту (фіксація плану розкладу проекту, засоби введення фактичних показників стану задач — відсоток завершення); б) засоби контролю над фактичним використанням ресурсів (бюджетна кількість і вартість ресурсу, фактична кількість і вартість ресурсу, кількість і вартість ресурсів, необхідних для завершення роботи). 4. Графічні засоби подання структури проекту, засоби створення різних звітів за проектом: a) діаграма Гантта (часто поєднана з електронною таблицею і дозволяє відображати різну додаткову інформацію); б) PERT-діаграма (мережна діаграма); в) засоби створення звітів, необхідних для планування (звіт про стан виконання розкладу, звіти по ресурсах і по визначенню ресурсів, профіль ресурсу, звіт по вартості. 5.3. ЗАГАЛЬНІ ХАРАКТЕРИСТИКИ НАЙБІЛЬШ ПОШИРЕНИХ АВТОМАТИЗОВАНИХ СИСТЕМ УПРАВЛІННЯ ПРОЕКТАМИ 1) Microsoft Project Система Microsoft Project є на сьогодні найпоширенішою у світі системою управління проектами. У багатьох західних компаніях пакет MS Project став звичним додатком до Microsoft Office навіть для рядових співробітників, що використовують його для планування графіків нескладних комплексів робіт. Останньою версією системи є MS Project 2000. Відмітною рисою пакета є його простота. Розроблювачі MS Project не прагнули вкласти в пакет складні алгоритми календарного або ресурсного планування. Водночас значна увага приділяється використанню сучасних стандартів, що дозволяють ефектив¬но інтегрувати пакет з іншими додатками. Наприклад, підтримка стандартів ODBC і OLE 2.0 спрощує задачі інтеграції бізнес-додатків. Підтримка Microsoft Mail і Microsoft Exchange дозволяє полег-шити і систематизувати групову роботу з проектами. Настроювання повідомлень для команди проекту включає можливість визначення складу проектних даних, що пересилаються учасникам проекту електронною поштою, та встановлення обмежень на корекцію інформації, що пересилається одержувачам. Збереження проектів у папках Exchange забезпечує додаткові засоби розмежування доступу до файлів проектів. Для швидкого освоєння в роботі з боку користувача-початків-ця MS Project надає, крім звичайних засобів допомоги, також можливість покрокової розробки проекту (Create Your First Pro-ject і Cue Cards) та інтелектуального підказування (Answer Wizard). Серед достоїнств пакету слід також відмітити досить зручні й гнучкі засоби створення звітів. Основні типи звітів можуть бути обрані із заготівель (Report Gallery). Можливість одночасно мати до шести планів для кожного проекту дозволяє підвищити ефективність аналізу «що—якщо». Водночас MS Project дає мінімальний набір засобів планування і керування ресурсами. Додаткові можливості MS Project також включають імпорт/експорт даних у форматах ASC II, CSV, Excel, Lotus 1-2-3, dBASE і FoxPro, засоби запису макрокоманд Visual Basic. MS Project може бути рекомендований для планування нескладних проектів користувачами-непрофесіоналами і новачками. 2) Time Line 6.5 (Фірма Time Line Solutions) Основними відмітними рисами Time Line 6.5 є реалізація кон-цепції багатопроектного планування в рамках організації, гнучкі засоби підтримки формування звітів і засоби налагоджування на інформаційне середовище користувача. У Time Line 6.5 немає обмежень на розмірність проектів. Пакет дозволяє берегти всі дані, що стосуються проектів організації, в єдиній SQL-базі даних, що крім опису проектів та єдиного для організації списку ресурсів містить усі елементи налагодженого управлінського середовища, що прийнято в компанії для роботи з проектами. Всі основні об’єкти бази даних об’єднані у вікні OverView у відповід¬них розділах. За допомогою даного вікна можна переглянути структуру бази даних проекту і здійснити доступ до будь-якого елемента, а також створити свої користувацькі елементи в списках. Time Line 6.5 пропонує досить потужні алгоритми роботи з ресурсами, що включають засоби міжпроектного призначення і вирівнювання перевантажень ресурсів, гнучкі можливості щодо опису специфічних календарних графіків роботи ресурсів. Недоліком даних засобів є відсутність можливостей опису і відображення ієрархії ресурсів організації. Стандартні можливості генерації табличних звітів за проектом доповнені можливостями системи створення і генерації звітів Cristal Reports 4, що дозволяє створювати практично будь-які види звітів, які містять дані як із бази даних Time Line, так і з інших баз даних компанії. Більш як 30 заготівель стандартних звітів управління проектами у форматі Cristal Reports включені в систему. Корисною додатковою можливістю системи є засоби створення власних формул в електронній таблиці Time Line. Окремий модуль імпорту/експорту дозволяє обмінюватися даними з іншими па- кетами керування проектами (MS Project, CA-SuperProject, Time Line 1.0 for Windows і 5.0 для DOS), базами даних (dBASE) та електронними таблицями (Lotus). Time Line 6.5 підтримує стандарти ODBC, OLE 2.0, DDE, а також макромову Symantec Basic. Зараз в СНД поширюється англомовна версія системи. Пакет Time Line 6.5 може бути рекомендований для планування проектів середньої складності або комплексів малих проектів. 3) Primavera Project Planner (P3) (Фірма Primavera Systems, Inc.) Детально буде розглянута далі. 4) SureTrak (Фірма Primavera Systems, Inc.) Крім P3 компанія Primavera Systems поставляє полегшену систему для УП — SureTrak. Цей програмний продукт орієнтований на невеликі проекти, підпроекти, роботу конкретних виконавців із фрагментами проектів. SureTrak має ті самі засоби, що й P3 з погляду організації проекту по кодах і фільтрації інформації, встановлення обмежень і розрахунку розкладу, але в той же час існує ряд обмежень і додаткових можливостей. З обмежень слід відзначити відсутність засобів багатопроектного управління і фрагментації проектів, меншу розмірність проектів, більш скромні засоби створення звітів. Однак у SureTrak з’явилися календарі ресурсів і, як наслідок, можливість розрахунку тривалостей робіт з урахуванням узгодження календарів виконавців (очікується, що календарі ресурсів з’являться й у наступній версії P3). Крім того, у ресурсів з’явилася додаткова категорія — прибуток. SureTrak відрізняється від усіх інших продуктів Primavera тим, що він цілком русифікований і поставля¬ється разом із керівництвом для користувача російською мовою. SureTrak здійснює імпорт/експорт файлів у форматах P3 і MS Project. 5) Artemis Views (Фірма Artemis International) Традиційно програмні продукти сімейства Artemis (Arte-mis 2000, Artemis 9000, потім Prestige) використовувалися для управління великими інженерними проектами. На сьогодні корпорація Artemis International поширює під цією торговою маркою серію програм під загальною назвою ArtemisViews. Сімейство Artemis Views складається з набору модулів, що автоматизують різні аспекти управління проектами: ProjectView, ResourceView, TrackView, CostView. Усі модулі сумісні за даними, працюють в архітектурі клієнт/сервер, підтримують ODBC-стан-дарт і легко інтегруються з популярними СУБД Oracle, SQLBase, SQLServer, Sybase. Кожний модуль може працювати як незалежно, так і в комбінації з іншим програмним забезпеченням. Ціна на ці традиційно недешеві системи обчислюється виходячи з того, що замовляється в конфігурації. Модуль ProjectView дозволяє реалізувати мультипроектну, багатокористувацьку систему планування і контролю проектів в організації. Завдяки ProjectView можна розділяти проектні дані (календарі, кодифікатори, списки ресурсів) між користувачами або користувацькими групами, забезпечувати засоби безпеки за одночасної роботи користувачів із проектом. Система дозволяє одержувати значну кількість різних звітів за допомогою власних засобів або з використанням спеціалізованого програмного забезпечення (наприклад Quest). У комбінації із засобами керування ресурсами ResourceView можна реалізовувати інтегрований підхід до управління проектними роботами і поточними операціями. Модуль ResourceView — спеціалізована система для планування і контролю використання ресурсів як у проектному або мат¬ричному середовищі управління, так і для поточних робіт. У системі реалізовані засоби підтримки узгодження керівниками розподілу ресурсів між роботами. Графічна панель управління ресурсами дозволяє менеджерам планувати, контролювати й оптимізувати їхнє завантаження завдяки перерозподілу черги робіт відповідно до наявності ресурсів. Модуль TrackView надає засоби ведення фактичної інформації з виконаних обсягів робіт, контролю за станом виконання і вартістю поточних робіт (проектних і позапроектних). Система дозволяє інтегрувати дані для різних рівнів керування в організації: від рядових виконавців, що ведуть інформацію про виконання своїх завдань, до вищого керівництва, що може одержати укрупнені дані по фактичних витратах і обсягах робіт. Модуль CostView забезпечує підтримку центрального депозитарію для інформації щодо усіх витрат і прибутків проектів. Пакет дозволяє аналізувати економічну ефективність контрактів, будувати таблиці грошових потоків, передбачати витрати та розраховувати показники внутрішньої норми рентабельності проектів. Безумовно, ArtemisViews дозволяє створити потужне інтегроване рішення, однак витрати, пов’язані з придбанням і впро¬вадженням даного програмного забезпечення, істотно обмежують коло потенційних користувачів. 6) Spider Project (Spider Technologies Group, Росія) Російська розробка — Spider Project. За інформацією, отриманою від фахівців, що розробляють і підтримують пакет (Spider Technologies Group), система була інстальована для керування декількома десятками великих проектів. Даний пакет має цілу низку відмітних рис, що дозволяють йому конкурувати із західними системами на великих промислових проектах. По-перше, це потужні алгоритми планування використання обмежених ресурсів. Тестування відомих пакетів УП показало перевагу алгоритмів Spider Project за якістю планів, що брали участь у виконанні робіт за обмеженості наявних ресурсів. Для 32 із 100 проектів, що брали участь у тестуванні, Spider Project склав більш короткі розклади робіт, а для інших 68 його розклади не поступалися кращим із розкладів, складених західними пакетами. У пакеті реалізована можливість використання під час упорядкування розкладів робіт взаємозамінних ресурсів (пули ресурсів), що також дозволяють одержати більш короткі розклади. Використання ресурсних пулів позбуває менеджера необхідності жорстко призначати виконавців на роботи проекту. Йому досить зазначити загальну кількість необхідних для виробництва робіт ресурсів і з яких ресурсів цю кількість вибирати. Це дозволяє і скоротити непродуктивні простої ресурсів, і полегшити роботу проектного менеджера, позбавляючи його необхідності робити стомливі на великих проектах оцінки «що—якщо». Ще однією особливістю пакета є можливість використання нормативно-довідкової інформації — про продуктивність ресурсів на тих або інших видах робіт, витрати матеріалів, вартість робіт і ресурсів. Spider Project дозволяє безмежно нарощувати в проектах число показників, що враховуються, створювати і використовувати в розрахунках будь-які додаткові табличні документи і бази даних, вводити будь-які формули розрахунку. Можливість настроювання системи дозволяє користувачам одержувати від пакета не тільки розклад робіт, графіки завантаження ресурсів і вартісні характеристики проекту, а й технологічні характеристики складених розкладів. Наприклад, у гірничодобувній промис¬ловості користувачі Spider Project мають можливість планувати не тільки порядок виїмки об’ємів руди, а й враховувати об’єми окремих компонентів, що містяться в руді. Перевершуючи багато західних пакетів за потужністю і гнучкістю окремих функцій, Spider Project загалом поступається в галузі програмної реалізації (використання стандартів обміну даними, користувацький інтерфейс тощо). Не завершений ще повний переклад системи в середовище Windows. Пакет має Win¬dows — надбудову, введення і відображення даних у діаграмах Гантта і PERT, однак програми розрахунку, як і раніше, функціонують у DOS. Для створення користувацьких табличних звітів за проектом необхідно використовувати програму електронних таблиць AUTOPLAN (DOS версія), що входить у постачання Spider Project. 7) Open Plan (Welcom Software) Однією із основних відмінностей системи є потужні засоби ресурсного і вартісного планування, що дозволяють значно полегшити знаходження найбільш ефективного розподілу ресурсів і упорядкування їхнього робочого розкладу. Крім того, користувачами інтегрованої системи управління проектами організації є як професійні менеджери, що здійснюють узгодження й оптимізацію планів проектів, аналіз ризиків, прогнозування і т. ін., так і учасники проектів, що виконують збір, уточнення й актуалізацію даних, готують звіти. Якщо для професіоналів важливими є потужність і гнучкість наданих системою функцій планування й аналізу стану проектів, то для інших користувачів неабияке значення має простота і прозорість системи. Тільки Open Plan забезпечує сьогодні як повну інтеграцію між професійною і «настільною» версіями системи, так і відкритість для обміну даними із зовнішніми додатками. Система Open Plan поставляється в двох варіантах — Professional і Desktop, кожний із яких відповідає різним потребам виконавців, менеджерів та решти учасників проекту. Обидві версії працюють з однією базою даних — немає необхідності в обміні даними. Спільне використання професійної і «полегшеної» версій системи управління проектами дає змогу не тільки брати до уваги потреби всіх груп користувачів, а й значно знизити вартість вирішення завдання. До основних переваг пакету Open Plan належить те, що він може працювати з даними будь-якого профілю, що стосуються життєдіяльності підприємства. Програмне забезпечення Welcom можна настроїти на роботу з різноманітними базами даних завдяки об’єктно-орієнтованій і клієнт-серверній архітектурі. Open Plan має прямий доступ до SQL-баз даних. Користувач може вибрати, в якому форматі зберігати дані по проектах (у власному форматі Open Plan, у форматах Oracle, SQL Server, Sybase, xBase). Open Plan забезпечує обмеження доступу до даних проекту, дозволяючи давати різні права на доступ до певних даних, роблячи їх доступними обмеженому колу осіб і регулюючи їх спільне використання. Засіб «Директор управління проектами», вбудований в Open Plan, дозволяє упорядкувати застосування стандартних елементів проектів і процедур. В Open Plan пропонується 65 моделей, побудованих на базі керівництв PMI (Інституту Проектного Менеджменту, США), що їх можна наладнати для створення документів, які відповідають вимогам C/SCSC і ISO стандартів. 5.4. ПРОГРАМНИЙ ПРОДУКТ PRIMAVERA PROJECT PLANNER (P3) 5.4.1. Загальна характеристика Центральний програмний продукт сімейства Primavera Prima-vera Project Planner (P3) добре відомий професійним менеджерам проектів у всьому світі. Сьогодні P3 застосовується для управління середніми і великими проектами у найрізноманітніших галузях, хоча найбільше поширення цей продукт одержав у сфері керування будівельними та інженерними проектами. Pri¬mavera Project Planner дає досить стандартний для всіх подібних систем графічний інтерфейс, але в P3 є декілька додаткових можливостей. По-перше, це можливість групування й упорядкування робіт за різними ознаками на різних рівнях деталізації проекту, що дозволяє подати інформацію у більш зручному вигляді для конкретної управлінської ситуації. Наприклад, використовуючи дані засоби, всю інформацію з проекту можна згрупувати по фазі проекту на першому рівні ієрархії, по відповідальному ресурсу — на другому і відсортувати по даті початку робіт — на третьому. Для кожної групи можуть бути задані власні шрифт і колір (тексту і файла), посторінкова розбивка. Інша корисна особливість — це можливість розбивки екрана по горизонталі на дві частини, кожна з яких може бути переглянута незалежно. Це дає можливість одночасно переглядати різні частини проекту. Крім того, P3 має певні відмінності від інших пакетів у засобах ресурсного планування. Під час опису ресурсу можуть бути зазначені нормальна і максимальна кількість наявного ресурсу, а також його ціна в шести часових інтервалах. Ресурс може бути позначений як керуючий (об’єм призначення керуючого ресурсу на задачу впливатиме на тривалість її виконання). Наприклад, вказавши, що робітники — це керуючий ресурс, а бригадир — ні, можна домогтися скорочення термінів виконання задачі прокладки траншеї призначенням більшої кількості робітників. Збільшення ж кількості бригадирів не вплине на тривалість роботи. Під час планування завантаження ресурсів може виникнути необхідність в описі нелінійного профілю споживання ресурсу окремою задачею. P3 дає можливість описати різні криві розподілу ресурсу, пропонуючи дев’ять стандартних кривих і змогу визначити власний профіль споживання, розбивши часову фазу задачі на 10 періодів. Засоби автоматичного перепланування задач з обліком обмежень на ресурси набувають особливої ваги для великих проектів, коли менеджер не в змозі самостійно проаналізувати причини нестачі ресурсів і знайти рішення для кожної конкретної роботи. P3 дозволяє вибрати режим перерахунку розкладу і дібрати критерій перепланування робіт, що забезпечує одержання більш стислого розкладу. Серед режимів перерахунку можна виділити вирівнювання вперед (визначення можливої дати закінчення проекту за заданої початкової дати); вирівнювання назад (визначення найпіз¬нішої припустимої дати початку проекту); згладжування перевантажень ресурсів у межах часових резервів робіт або в межах заданого інтервалу. Крім того, є можливість перерозподіляти призначення робіт між згрупованими ресурсами. До недоліків засобів ресурсного планування можна віднести обмеження на кількість календарів. Крім головного календаря проекту, P3 дозволяє описати лише 30 додаткових календарів, тимчасом як можливість складання індивідуальних графіків роботи для кожного ресурсу вже стала нормою в сучасних пакетах управління проектами. Інше обмеження пов’язане з кількістю ресурсів (не більш як 120), що контролюються під час вирівнювання профілю завантаження обмежених ресурсів. Засоби підтримки багатопроектного середовища управління в P3 передбачають можливість визначення ієрархії і права доступу до майстер-проекту і підпроектів. Менеджер-координатор проекту має право редагувати майстер-проект і всі підпроекти. Менеджер підпроекту має право додавати ресурси в словник ресурсів, але не вилучати їх і не змінювати їхньої ціни. Якщо дозвіл ресурсних конфліктів у межах підпроекту вимагає даних іншого підпроекту, менеджер може це зробити тільки за умови надання йому додаткових повноважень з боку менеджера—координатора проекту. Однак ресурсне планування по всьому проектові в цілому може здійснюватися тільки менеджером-координатором. Тіль¬ки він може визначити зв’язок між підпроектами. Порівняно з багатьма іншими програмними продуктами, що також роблять можливим багатопроектне управління, відмітною рисою P3 є докладний опис принципів багатопроектного управління в доку¬ментації, де вони розглядаються з двох точок зору: менеджера—координатора проекту і менеджера підпроекту (хоча вважається, що тема мультипроектного управління вимагає додаткового підручника). 5.4.2. Специфіка використання програмного продукту Primavera Project Planner (P3) для управління проектом 1) Р3 будує логічну діаграму. Р3 дозволяє прискорити створення проекту, використовуючи PERT-діаграму, де кожній роботі відповідає прямокутник. Опція Лінійний графік, який є таблицею з графічною частиною, що подає роботи відповідно до шкали часу, дозволяє розглядати розклад. Після розробки списку робіт можна легко поєднати їх у певну сітьову логіку. 2) Типи Робіт. Р3 пропонує різні типи робіт, за допомогою яких можна моделювати різні взаємодії між роботами/ресурсами. При цьому слід використовувати типи робіт у поєднанні з календарями або робіт чи ресурсів для визначення робіт, тривалість яких визначається обсягом роботи чи інтенсивністю використання ресурсів (рис. 5.1). Рис. 5.1. Типи завдань, що можуть бути використані в РЗ 3) Організація даних проекту. Р3 організовує структуру даних проекту. Для отримання інформації, що цікавить, існує можливість організувати проект у численні групи за такими, наприклад, ознаками: важливість, місце розташування, фаза, ресурс або щотижневі календарні дати. Кожна група може бути показана різними кольорами і шрифтом для наочності уявлення. 4) Обмеження на роботи. Зовнішні умови, які не можна врахувати мережною логікою (терміни постачання, погодні умови тощо), можуть бути описані за допомогою обмежень. Р3 пропонує 10 типів обмежень, як-от: ранній старт або пізній фініш. Можна скористатися різними способами оптимізації розподілу ресурсів. Наприклад, розтягнути (зменшити) його використання протягом певного робочого періоду і стиснути (збільшити) використання його протягом інших періодів. Можна також припинити роботу за нестачі ресурсу і відновити її, коли його стане досить. Р3 надає плануванню необхідної гнучкості, не змінюючи кінцевої мети. 5) Коригування розкладу на основі даних, отриманих від віддалених учасників проекту. Додаток Primavera Post Office надає мож¬ливість дистанційного контролю над віддаленими учасниками проекту, що використовують систему пошти, завдяки чому існує можливість збирати дані, підвищувати продуктивність роботи, фіксувати відомості про використання ресурсу і вводити фактичні собівар¬тості. Р3 полегшує збір та поєднання інформації від різних джерел і змінює її згідно із запланованими користувачем потребами. 6) Звіти. Звіти можна створювати на основі макета в PERT-поданні або Лінійному графіку (рис. 5.2). Звіти в HTML-форматі можна підготувати, використовуючи Primavera Web Publishing Wizard. Ці документи можна розмістити в World Wide Web (використовуючи FTP) або в офісний Intranet і розглядати, використовуючи INTERNET-броузер. Документи містять пов’язаний гіпертекст або переходи на інші сторінки в структурі, дозволяючи переміщатися між проектами і повідомленнями від сторінки до сторінки в межах повідомлення. Для передачі проектної інформації можна використати табличні і графічні шаблони, передбачені в Р3. Можна також створювати свої власні звіти, щоб задовольнити особливі вимоги, використовуючи розроблені користувачем формати. 7) Контроль ресурсів і витрат. Всі дані проекту інтегровані, тому Р3 автоматично відображає зміну цін протягом усього часу виконання проекту. Під час запису поточних даних Р3 автоматич¬но перевіряє кінцевий кошторис. Досвідчені користувачі можуть визначити власні підходи до методів розрахунку кількостей і вартостей ресурсів. Рис. 5.2. Подання PERT-діаграми в РЗ Р3 призначає ресурси в проект через роботи. Можна визначити роботи, які управляються призначеними для них ресурсами; потім Р3 обчислює вплив обмеження ресурсу і час затримки розкладу. Перевантаження персоналу показують гістограми і криві на екрані. Якщо використання перевищує доступність, слід виконати швидкий аналіз «що—якщо» за допомогою коригування тривалості або затримки робіт, таким чином одразу стає очевидним ефект від перерозподілу ресурсу. ? Наступні кроки 1) Планування і реалізація розкладу. Створення розкладу доданням груп проектів і проектів у групи, визначення робіт і роз’яснення специфіки виконання кожного типу розкладу, установка структури вартісних звітів для регулювання кошторису проектних вартостей, визначення специфіки затримки, тривалості і нелінійного розподілу ресурсів. 2) Коригування і вдосконалення розкладу. Організація даних через використання WBS (структурна декомпозиція робіт), коди робіт, ID (ідентифікатор) проекту і пунктів, призначених для користувача даних, додання і зміни календарів. 3) Оновлення розкладу. Встановлення цільового плану і запис виконання робіт. Зміна проектів віддалених учасників і підготовка HTML-звітів. Використання звітів, графіків, лінійних діаграм і PERT-подання, а також інших інструментів для відображення процесу. 4) Підготовка презентацій. Настроювання макета і фільтрація даних, друк звітів та графіків. ? Визначення структури проекту Групи проектів Для управління декількома проектами використовують групу проектів. Ці проекти можуть бути не взаємопов’язаними. Деякі проекти можуть бути об’єднані, оскільки завершення їх пов’я-зане із використанням одних і тих самих ресурсів. Наприклад, компанії з дослідження і розвитку часто управляють однаковими проектами, які використовують однакові групи інженерів і наладчиків. Інші складні проекти можуть бути не пов’язані, але управління проектом потребує підсумкових даних розкладу в звітах або Лінійному графіку. При цьому можна використати групу проектів для контролю складних проектів, які управляються дистанційно (наприклад, якщо користувач відповідає за багатомільйонний проект, що включає в себе проекти субпідрядників, що управляються як один проект. Коли встановлюється структура для групи проектів і його учасників, можна повернути кожний проект і розіслати його електронною поштою відповідальним субпідрядникам. Кожний керівник проектом може відновити свою частину проекту на своєму комп’ютері (на якому встановлена ліцензована копія Р3) і працювати з ним як звичайно. Потім кожного тижня (або через інший намічений період часу) можна оновлювати групу проектів, відновлюючи кожний проект, отриманий від субпідрядника. У складних проектах навколишнє оточення і група проекту — це ключові питання управління. Всі проектні дані передаються в групу проекту, і всі зміни зберігаються. Зміни в групі проектів можуть бути автоматично передані у відповідний проект. В ідеалі контролювати проектну групу має одна людина. Головний менеджер проекту повинен визначити стандарт даних подання проектної інформації для всіх проектів компанії. Визначення прав доступу. Головний менеджер визначає права доступу, які вказують, хто може працювати в групі проектів. При цьому він повинен виконувати такі функції в групі проектів: а) встановлювати календарі, коди робіт, ресурсів, вартісні звіти, поля користувача даних, які задовольняють потреби проектів; б) базові календарі й словники можуть бути відредаговані з проектної групи. Ресурси, коди та інші пункти словника можуть бути додані (але не видалені) з проекту; в) визначати опції для розрахунку розкладу і вирівнювання. Для узгодження пересічних проектів їхні дані вводяться в групу проектів одночасно і є доступними для всіх проектів, однак важливо улагодити всі розбіжності перед запуском проекту, оскільки деяка інформація не може бути змінена на проектному рівні. Учасники мають встановити керівні принципи для координації коригування, перерахунку розкладу та інших необхідних змін. ? Проект у групі проектів Проект — це частина великої проектної групи. Зазвичай один менеджер управляє кожним проектом у групі. Проекти можуть бути завершеними і незалежними; можуть розглядатися як проек¬ти для спрощення аналізу ефекту розподілу ресурсів або створення звітів при перетині численних проектів. 1) Призначення ID проекту. За додання проекту до групи проектів Р3 автоматично призначає ID (ідентифікатор — унікальне ім’я) проекту для його ідентифікації. Цей ID-код займає перші дві позиції в ID-кодах робіт цього проекту. ID-код можна прийняти за умовчанням або ввести свій власний. 2) Призначення прав доступу. Кожний проект у групі проектів має свій список доступу. Головний менеджер проекту призначає права доступу на рівні групи, тимчасом як кожний менеджер проекту наділений правами доступу до свого проекту. ? Управління групою проектів Проекти можуть бути пов’язані залежністю в групі проектів. Залежність може бути простою, коли, наприклад, одні проекти починаються після завершення інших, або більш складною, коли проекти можуть бути пов’язані залежністю між роботами. 1) Складання розкладу групи проектів і проектів. Як і голов¬ний менеджер проекту, менеджер проекту повинен розрахувати загальний розклад проекту з групи проектів — як перед початком, так і під час реалізації проекту через певні проміжки часу. Після складання розкладу проектної групи Р3 розраховує розклад проектів. Для встановлення пізніх дат для кожного проекту можна взяти за основу їхні дати фінішу або кінцеву дату всієї групи проектів. Кожний менеджер проекту може розрахувати розклад для проектів (якщо у нього є доступ до групи проектів). Складаючи розклад проекту, можна або брати до уваги взаємозв’язок проектів між собою і з групою проектів, або ігнорувати всі зовнішні залежності. 2) Вирівнювання ресурсів. Коли різні проекти конкурують за одні й ті самі ресурси, вони не для всіх можуть бути доступними. Фактично основна причина затримки проекту — призначення одних і тих самих ресурсів на паралельні роботи. У P3 аналіз проводиться на екрані на гістограмах, які точно покажуть, коли і де використовуються ресурси для одного проекту або ж вони використовуються у всіх проектах групи проекту. Ресурс може бути доступний для одного проекту, проте коли оцінка проведена з групи проектів, одночасне використання ресурсу може в сумі перевищити його доступність. Щоб вирішити ресурсні конфлікти, слід скористатися вирівнюванням ресурсів. Якщо один проект має пріоритет над іншим, встановлюють пріоритети проектів. Якщо дві роботи з проектів конкурують за один і той самий ресурс, P3 призначає спочатку ресурс на проект з вищим пріоритетом. 3) Звіти проектів. У рамках РЗ можна легко виводити на екран Лінійний графік, PERT-діаграми, ресурсні гістограми, інші звіти та графіки як з групи проектів, так і з проектів. Аналіз проектів здійснюють на різних рівнях деталізування. Усі проекти спільно використовують макети, звіти і графіки, пов’язані групою проектів; однак менеджери проекту можуть додавати свої специфікації. Будь-які макети, додані з проектів, автоматично стають доступні іншим проектам і групі проектів, і навпаки. Макети і роздруковані звіти, зроблені з проекту, показують тільки роботи цих проектів. 4) Аналіз проектів. Під час перегляду даних проекту для спрощення аналізу існує можливість сфокусувати увагу на особливостях проекту. ? Визначення тривалості робіт На стадії планування збирають необхідні документи і обмірковують різні проблеми, в тому числі й тривалість робіт. ? Створення основного розкладу. Огляд процесу Передусім треба створити список робіт і показати залежність між ними. Потім необхідно розрахувати і переглянути розклад у часовій шкалі, визначити ресурси, потрібні для виконання роботи, після чого роздрукувати макет, що вийшов. Після створення базового розкладу при бажанні можна уточнити і розширити дані словника, як-от коди робіт, або удосконалити розклад, змінюючи параметри календарів. ? Використання Fragnet’ів для створення проектів «Fragnet» — фрагменти мереж — це ще один зручний варіант розробки проектів. По суті це набір робіт, які копіюють з уже існуючого проекту, зберігають і застосовують у тому самому або іншому проектах. Вони спрощують роботу над проектами за будь-якого типу циклічних процесів. Наприклад, без урахування номенклатури виробів, які треба придбати, процес закупівлі їх часто включає одну і ту саму низку робіт. У цьому разі можна ввести групу робіт і дані по одному з полів, вибрати цю групу і потім відправити в бібліотеку Frag-net’ів. Р3 копіює більшість параметрів роботи з Fragnet’ами, включаючи ID роботи, назву, тривалість, залежності, затримки, ресурси і ціни. Замість введення однакових параметрів для кожного поля можна знайти відповідний Fragnet і привести його до необхідного вигляду. Р3 забезпечує можливість переміщення текс¬ту, що дозволяє просто виготовляти заголовки робіт і коди, тобто без потреби їх друкувати. Техніка використання Fragnet’ів більш ефективна, ніж традиційна техніка використання буфера обміну, оскільки перша дозволяє копіювати, накопичувати і знаходити стільки Fragnet’ів, скільки треба. Р3 забезпечує установку Frag¬net’а для типових процесів. ? Розрахунок розкладу Після внесення робіт і логічних залежностей у проект Р3 розраховує розклад для визначення планових дат, виявляє критичний шлях, тобто роботи, терміни виконання яких визначають дату завершення всього проекту. Далі перевіряється і коригується розклад, наприклад, за фіксованої дати завершення проекту. При цьому можна розтягувати або стискати лінії робіт у Лінійному графіку, тобто змінити їхню тривалість і дати. Коли події повинні відбутися в певний час, можна переміщувати лінії робіт і точне місцезнаходження їх на шкалі часу. У PERT-поданні існує можливість відслідковувати один або декілька мережних шляхів для перевірки і приведення у відповідність логіки проекту. ? Перегляд розкладу за допомогою опції Лінійний графік Після складання розкладу проекту виводять на екран Лінійний графік для перевірки проекту відповідно до часової шкали. У таблиці вказані дані про роботи, а лінії вздовж шкали часу відображають хід самих робіт. Для внесення змін у проект, наприклад, стиснення розкладу, необхідно зменшити тривалість деяких робіт. Лінійний графік надає простий метод зміни тривалості робіт. Зміна тривалості або дат для однієї з робіт може привести до зміни планових дат для попередніх або подальших робіт. Для перегляду цих змін необхідно буде перерахувати розклад. Зміна дат старту і фінішу робіт. Роботи можна перемістити по часовій шкалі, зберігши їх тривалість. Якщо результат зміни стану робіт не відповідає обмеженню, Р3 відновить логіку при повторному перерахунку розкладу. Для прив’язки робіт до певних часових рамок необхідно виконати інші установки, як-от накладення обмежень або перегляд логіки. ? Розрахунок розкладу в Р3 Під час розрахунку розкладу наперед за мережною логікою Р3 розраховує дати раннього старту і раннього фінішу кожної роботи, починаючи з першої. Ці дати показують найбільш ранні терміни, в які може бути виконана робота, якщо передуючі їй також були виконані до ранніх дат їхнього фінішу. Відповідно дати пізнього старту і пізнього фінішу визначають найпізніші терміни виконання робіт, але без затримки планової дати завершення проекту. Певні роботи мають резерв часу, який дозволяє їм починатися пізніше дати їхнього раннього старту. Повний резерв часу — це кількість днів, протягом яких робота може не проводитися без збитку для своєчасного завершення проекту. При правильному управлінні цей резерв є ефективним засобом для регулювання затрат праці, матеріалів, грошових коштів та інших ресурсів, а також для планування робіт, які мають позитивний резерв часу. Робота з нульовим резервом не належить до гнучких робіт. Вона повинна розпочатися точно у визначений час і завершитися в означений термін або до планової дати її завершення. У іншому разі вона затримуватиме закінчення проекту в цілому. Негативний резерв часу попереджає про те, що одна або більше робіт виконуватимуться пізніше визначених пізніх дат і що виконання проекту буде затримано. (Чим більший негативний резерв, тим більшим є відставання у виконанні проекту. Р3 розраховує негативний резерв тільки за призначення фіксованої дати виконання проекту або за інших обмежень у розкладі. Критичні роботи безпосередньо впливають на виконання тривалості проекту. При цьому можна легко виявити критичний шлях, показавши на екрані критичні роботи. Р3 показує їх червоним кольором. У Лінійному графіку використовують різні зображення ліній та їхніх кін¬цевих точок, у PERT-поданні — прямокутників, що відображають роботи.) ? Визначення критичного шляху PERT-діаграма дає можливість відстежувати залежності між роботами за проектом, що дозволяє перевіряти послідовності робіт на екрані. Дослідження логіки використовують для детального вивчення критичного шляху і з’ясування того, чому окремі роботи мають негативний резерв часу. ? Призначення кодів Незалежно від того, скільки робіт включає в себе проект, доцільно організувати дані таким чином, щоб це було і корисно, і зручно для планування й управління проектом. Р3 розглядає кодування робіт як метод організації проекту. Система може класифікувати роботи, використовуючи до 20 словників кодів, як-от: відповідальний виконавець, галузь, міністерство, до яких відноситься робота, період, місце, розділ або тип роботи. Р3 забезпечує установку стандартних кодів робіт для кожного нового проекту. Ці коди дозволяють класифікувати роботи, використовуючи інформацію про відповідального виконавця, галузь, міністерство, ключову подію, продукт, місце і етап. Як слов¬ники, так і коди можуть бути перевизначеними. На самому початку звичайно потрібно визначити коди відповідальних виконавців, щоб була можливість знаходити і відбирати роботи персонально для співробітників. Далі слід визначати і призначати додаткові коди для розширення можливостей в організації робіт. ? Призначення ресурсів Під час розробки плану ресурсів, необхідних для виконання робіт, створюється список ресурсів. Р3 пропонує декілька способів призначення ресурсів роботам. Перед призначенням ресурсу треба уточнити: а) в яких величинах вводитимуться ресурси: в розмірних або безрозмірних, тобто у відсотках; б) загальні витрати (величину бюджету). Якщо величина бюджету не вказується, то Р3 автоматично її обчислює виходячи з норм витрат ресурсу і затрат часу, необхідного для виконання робіт. У проектах можна користуватися одиницями ресурсу типу трудовитрати (людино-годин у день, людино-днів у день), матеріали, що витрачаються протягом дня (на¬приклад, виражені в кілограмах, погонних метрах тощо) або будь-яким іншим типом одиниць. Період часу обчислюється у визначених у проекті одиницях. Р3 підраховує кількість ресурсу для виконання робіт множенням числа одиниць ресурсу, виділеного на одиницю часу, на кількість днів, необхідних для виконання роботи: Кількість для завершення = = Необхідна тривалість ? Число одиниць у день. ? Затримка і тривалість ресурсів Ресурси, призначені в Р3, починають витрачатися з початком відповідної їм роботи і закінчуються в момент її завершення. Однак можна використати затримку надходження ресурсів та тривалість їх використання для управління датами початку і закінчення використання ресурсу. Затримка — це час між початком роботи і початком витрачання ресурсу. Наприклад, ресурс може бути не затребуваний протягом декількох днів після початку робіт. Якщо ресурс не затребуваний протягом усього періоду роботи, можна уточнити тривалість відповідного ресурсу. ? Нелінійний розподіл ресурсів Незважаючи на те, що можна застосовувати затримку витрачання ресурсів для оцінки початку і кінця використання ресурсу, Р3 за умовчанням залишає без зміни рівні витрати ресурсу в будь-який із днів виконання роботи. Однак іноді ресурси витрачаються нерівномірно в часі, наприклад, матеріали звичайно опла¬чуються до дня постачання. Використовуючи криві ресурсів, можна описати розподіл ресурсів по роботі. Для витрати більшої частини ресурсу в початковий період часу треба використовувати криву, завантажену на початку роботи, а за великих витрат у кінці роботи — криву, завантажену в кінці. Найдоцільніше використовувати трикутну криву, яка показує, що ресурс витрачається повільно на початку і в кінці роботи, а в середині її витрата збільшується (рис. 5.3). Рис. 5.3. Використання кривих споживання ресурсів ? Організація і відбір макетів Після того, як проект підготовлений, його перегляд можна організувати з різних точок зору. Наприклад, згрупувати роботи за кодами Відповідальні для підготовки детального списку робіт кожного з менеджерів. Фільтри робіт використовують для показу на екрані і при друкуванні тільки вибраних робіт. Наприклад, під час аналізу розкладу може виникнути потреба перерахувати роботи з нульовим резервом. ? Контроль проекту Успішне управління проектом не закінчується в момент підготовки плану. Для досягнення поставленої мети необхідно щодня відстежувати виконання робіт і оновлювати розклад відповід¬но до фактичних даних. Контроль проекту означає ще й внесення інформації та звітність за фактом виконання робіт, відстеження змін у міру їх появи, порівняння поточного і цільового розкладу і вимірювання продуктивності (рис. 5.4). Рис. 5.4. Діалогове вікно для розрахунку завантаження кожного виконавця відповідно до його наявності і робочого тижня ? Огляд Коли проект виконується, важливо завжди мати «свіжі» дані. Одна з найважливіших причин оновлення розкладу — відстеження відхилень фактичної тривалості від запланованої спочатку. Крім того, може бути змінена послідовність робіт, додані нові, деякі можуть бути вилучені. Зазвичай організація обміну інформацією між учасниками про¬екту, процедура оновлення інформації обмірковуються до початку його реалізації. Обов’язково слід визначитися в тому, які дані необхідно оновлювати, як, коли і хто їх оновлюватиме. Створення процедури оновлення. Звичайно компанія одночасно виконує декілька проектів, що перебувають на різних стадіях реалізації. Становище може ускладнитися тим, що менеджери проектів, ключові ресурси або співробітники знаходяться у різних місцях і віддалені один від одного. При створенні процедур оновлення проекту слід враховувати ці обставини. ? Оновлення складного проекту Менеджери проектів повинні координувати збір даних про виконання проектів від кожного з керівників груп. Періодичність може варіюватися залежно від інтенсивності проекту. При добре налагодженому механізмі збору інформації керівники проектів можуть вводити її безпосередньо в свої проекти. Це важливо для багатопроектного управління, особливо тоді, коли один менеджер відповідає за кілька проектів. Якщо між керуючими проектами є зв’язок через комп’ютерну мережу, то це може істотно спростити обмін інформацією. Можна користуватися електронною поштою, передавати дискети або ж просто друкарські звіти. Головний менеджер проекту повинен максимально використати наявні можливості. Для кращого розуміння проблеми слід визначитися в таких питаннях: ? Які саме дані необхідно збирати і яким чином? ? Як часто потрібно оновлювати розклад проекту? ? Ресурси місцеві чи привізні? ? Хто саме в кожній команді збиратиме інформацію для коригування розкладу? ? Кому і коли необхідно надавати «свіжу» інформацію? ? Які звіти необхідно будувати після кожного оновлення і що треба аналізувати насамперед? Відповіді на ці запитання важливі для визначення методу використання P3 під час оновлення інформації з проекту. 1) Які дані потрібно збирати? Насамперед це залежить від того, які роботи є в проекті: типу Завдання або Керовані ресурсами. Якщо ця робота — Завдання, то можна просто записувати фактичні дати і тривалість, що залишилася. Для роботи, керованої ресурсами, потрібно відмічати використання ресурсів: фактич¬на кількість на дату і кількість до завершення. 2) Як буде відбуватися збір даних? На цьому етапі слід відповісти на такі запитання: Дані для оновлення проекту будуть надходити з віддалених майданчиків? Якщо так, то чи є з ними зв’язок через комп’ютерну мережу, модем або електронну пошту? 3) Аналіз і обмін даними. Введення інформації про виконання робіт в P3 є тільки початком процесу оновлення інформації. Після розрахунку розкладу необхідно проаналізувати результати. Найзагальніші результати можна побачити на екрані комп’ютера. Для детального аналізу даних будують необхідні звіти і графіки. Проаналізувати потенційні проблеми дозволить порівняння цільового плану і поточного розкладу. Аналіз «що—якщо» забезпечить вибір оптимального рішення. Ефективний обмін даними між учасниками проекту також є основою для успішної реалізації всього проекту. Наочні звіти і графіки спростять розуміння іншими учасниками того, що відбувається з проектом. У них можна показати критичні роботи, пере¬витрати ресурсів і грошей або простої, роботи наступного періоду. ? Створення цільового плану Перед тим, як у перший раз оновити розклад, Primavera пропонує користувачеві створити цільовий план. Найпростіший цільовий план — це повна копія початкового розкладу. У міру реалізації проекту цільовий план використовується для порівняння запланованих спочатку і фактичних термінів, ресурсів і вартості. Крім ознаки продуктивності, цільовий план можна використати для оцінки статусу проекту. В P3 можна створити необмежену кількість цільових планів, але порівнювати поточний розклад можна тільки з двома одночасно. Наприклад, можна визначити вихідний розклад як Ціль 1 і поточний розклад на момент останнього оновлення розкладу як Ціль 2. Порівняння поточного розкладу з кожним із цих цільових планів дасть можливість зрозуміти, як виконується проект з моменту його початку і за останній звітний період. У міру виконання проекту цільовий план можна оновлювати. При порівнянні це дозволить отримати точні дані. ? Автоматичне оновлення ресурсних і вартісних даних P3 надає можливість автоматично розраховувати ресурсні й вартісні показники під час виконання проекту. При оновленні статусу виконання робіт і введенні відсотка виконання або тривалості, що залишилася, P3 може автоматично оновити ресурсні й вартісні дані. Наприклад, якщо робота виконана на 70 відсотків, P3 розрахує факт на дату для кожного з ресурсів як 70% його бюджетної кількості. Отримане значення з кількості по завершенні для ресурсу береться як нове значення кількості до завершення. P3 оновлює подібним чином і вартості. Якщо існує необхідність оновлювати дані по ресурсах і вартостях вручну або змінити установки за умовчанням правил автоматичного розрахунку вартостей (Autocost), можна змінити набір правил, які використовує програма P3 під час оновлення даних. Наприклад, для введення фактичних значень на дату вручну вимикають правило 5. Правило 3 встановлено виходячи з того, що кількість ресурсу для завершення роботи обмежена (рис. 5.5). Рис. 5.5. Установлення правил при ручних коригуваннях ресурсів і вартостей Чим більше ресурсу або грошей витрачається у міру виконання проекту, тим менше їх залишається. Однак інша установка дозволить визначати фактичну кількість на дату і очікуване по завершенні при закінченні кожного звітного періоду. Отримана таким чином оцінка по завершенні дозволяє більш точно планувати вартість роботи. Настройку правил автоматичного розрахунку вартості можна застосувати як до окремо взятого проекту, так і до всіх проектів, що створюються наново. Їх настроюють на початку виконання проекту і підтримують постійними у міру його реалізації. ? Запис інформації про виконання для робіт з керуючими ресурсами Для проектів, тривалість виконання робіт за якими залежить від наявності ресурсів, використовують роботи типу «Незалежна» (Independent) або «Зустріч» (Meeting). У роботах типу «Незалежна» ресурси використовуються відповідно до їхніх власних календарів та їхніх власних тривалостей використання. P3 планує таку роботу відповідно до логіки передування і тривалості використання її керуючих ресурсів. Роботи типу «Зустріч» вимагають одночасної наявності всіх керуючих ресурсів для її виконання. Такі роботи корисні при плануванні «Зустрічей» та інших робіт, де для їх проведення потрібні всі ресурси відразу. У проекті, за яким мають використовуватися керуючі ресурси, роботи типу «Незалежна» або «Зустріч» оновлюють введенням фактичної кількості на дату (або фактичної за період) та очіку- ваної до завершення для визначених ресурсів. Наступний приклад (рис. 5.6) показує частину макета, налагодженого для збору інформації про виконання робіт. Це тільки один із методів, якими Рис. 5.6. Введення значень для робіт типу «Незалежна» можна користуватися під час оновлення проекту. У цьому прикладі макет організований за ресурсами і в таблиці робіт додані колонки, щоб кожний міг проставити туди інформацію про час, затрачений на виконання тих або інших робіт. (Для незалежних робіт з керуючими ресурсами вводять значення в полі Actual To Date або Actual This Period і To Complete. Колонки налагоджені таким чином, що можна вводити фактичну інформацію. Кожний співробітник вносить дані по своїх роботах.) Для оновлення інформації можна вивести Форму Роботи і деталізуюче вікно Resources, як показано на рис. 5.7. Рис. 5.7. Деталізуюче вікно Resources, що використовується для оновлення інформації P3 розраховує тривалість, що залишилася для кожного із ресурсів, діленням його кількості до завершення на інтенсивність споживання. ? Відстеження додаткових вартісних даних Незважаючи на те, що P3 надає декілька полів даних для аналізу розкладу, ресурсів і вартості, іноді виникає необхідність відстежувати додаткові дані. Для цього можна використати поля користувача даних, які дозволяють доповнити роботи або ресурси новими даними, що містять текст, числа (ціле або з десятковими знаками) або календарні дати. Призначені для користувача поля даних особливо корисні при відстеженні вартостей. Наприклад, поле для ресурсів «Початковий бюджет». У ньому зберігають усі бюджетні вартості на початку проекту. В іншому призначеному для користувача полі можна відстежувати кількість грошей, витрачених на роботу. Крім того, можна відстежувати переглянутий бюджет, грошові витрати, номери рахунків чи інших документів або інші дані. ? Підготовка презентації Інформацію учасникам проекту, менеджерам або замовникові необхідно подавати в простому і наочному вигляді. Система P3 надає багато можливостей для підготовки ефективної презентації. ? Налагодження таблиці робіт За умовчанням макет для екрана Лінійний графік містить колонки для даних розкладу проекту. Однак і зміст, і форму таблиці робіт можна налагоджувати, задаючи дані для кожної колонки та змінюючи тип шрифту, колір фону й інші візуальні елементи. ? Налагодження шкали часу У системі P3 шкала часу розташовується вище за область Лінійний графік, починаючись незадовго до стартової дати проекту і закінчуючись після дати його фінішу. Настроюючи шкалу часу, можна задавати мінімальну часову одиницю, часові рамки, визначати її щільність, показувати дати календарними числами, фінансовими роками, виробничими тижнями або порядковими датами. ? Форматування ліній Лінія представляє планові дати для кожної роботи. Кожну роботу можна визначити декількома лініями, показавши для неї, наприклад, лінію ранньої дати, лінію пізньої дати і цільову лінію. Відмінність ліній досягається зміною їхнього кольору, вигляду, розміру і позначень кінцевих точок (рис. 5.8). Рис. 5.8. Форматування ліній робіт ? Зображення даних на лініях робіт Деякі дані, як-от ID роботи, опис, вартісні дані, планові дати, тривалість, значення резерву і журнальні записи, для наочності можуть бути показані прямо на лініях (рис. 5.9). Рис. 5.9. Подання додаткових даних на лініях робіт (лінії на цьому макеті показують ID для кожної роботи, її опис і бюджетну вартість) ? Штрихування ліній по кодах робіт Для візуального виділення робіт треба використовувати кольори і шаблони штрихування. У наведеному прикладі штрихування застосовується для робіт, за які відповідає певний менеджер (рис. 5.10). Рис. 5.10. Виділення робіт за допомогою штрихування ? Укрупнення даних Часто виникає необхідність показати велику кількість інформації у стислому вигляді. Такий укрупнений вигляд проекту призначений тільки для керівництва і клієнтів, оскільки в ньому прихована детальна інформація по роботах. P3 дозволяє узагальню¬вати дані по роботах на основі загального коду, WBS-коду, ресурсів або статей витрат. У наведеному нижче прикладі проект організований по фазах і всередині кожної з них інформація укрупнена по відповідальних (рис. 5.11). Рис. 5.11. Укрупнене подання інформації щодо проекту (тонкою частиною лінії роботи позначений неробочий період) Поділ ліній робіт. Сумарна лінія може бути подана окремими елементами. Р3 розташовує в кожному ряду стільки індивідуальних ліній, скільки їх вміщується. Використовуючи дискретні лінії, можна укрупнити інформацію по групі робіт і водночас бачити початкові й кінцеві дати кожної роботи. ? Відображення підсумкових і детальних ліній Підсумкові лінії можна показувати разом із повним спис- ком робіт, групуючи їх і включивши відображення підсумків (рис. 5.12). (У даному прикладі P3 показує підсумкову лінію для кожного відділення — підсумкову лінію можна розташувати вго- рі або внизу у відповідній групі в діалоговому вікні Orga- nize.) Рис. 5.12. Відображення підсумкових і детальних ліній ? Багатопроектне управління й інтеграція За допомогою P3 контролювати групи проектів також просто, як і один проект. При цьому можна координувати незалежні проекти в багатопроектному оточенні, враховуючи залежність між роботами різних проектів. Багатокористувацький режим. P3 допускає одночасний доступ кількох користувачів до їхніх даних по проекту, для оновлення, аналізу цих даних і побудови звітів. P3 має засоби адміністрування для обмеження прав доступу користувачів відповідно до їхніх повноважень, місця роботи, наданих у їхнє розпорядження ресурсів та інших даних по проекту. Це дозволяє, наприк¬лад, бути в курсі справ усього проекту, але не змінювати дані, що безпосередньо не стосуються конкретного користувача. Використання електронної пошти. Для передачі інформації локальною мережею або по всьому світу P3 використовує Micro-soft Mail(r), cc:Mail(r) та багато інших VIM або MAPI-сумісних поштових систем. При цьому можна ввести адресу електронної пошти безпосередньо в проект і автоматично відстежувати стан запитів по кожному користувачеві, отримувати оновлені дані від локальних або віддалених груп користувачів. Додаток Primavera Post Office дасть можливість учасникам проекту обмінюватися проектною інформацією, навіть якщо у них немає своїх додатків P3. Інтеграція з іншими корпоративними системами. Якщо необхідно передати проектні дані в інші корпоративні системи, в розпорядженні користувача є декілька способів завдяки відкритій архітектурі P3. База даних P3 і правила введення інформації доступні через OLE 2.0 або такі мови високого рівня, як Visual Basic, С++ чи навіть Excel. ? Засоби аналізу для безперешкодної реалізації проекту За великої кількості проектної інформації, яка щодня і щогодини змінюється, засоби P3 дозволяють ретельно відстежувати всі дані по проекту і передбачувати можливі проблеми. Аналіз альтернатив. При виявленні можливої проблеми P3 дозволяє легко перепробувати десятки можливих варіантів найшвидшого і найкращого її вирішення і якнайефективнішого використання критичних ресурсів. За допомогою набору засобів P3 легко простежити (як детально, так і укрупнено на різних рівнях структури проекту) результат різних впливів на проект, які користувач може зробити в ситуації, що склалася. Звіти по проекту. Для наочного подання інформації по проекту P3 має більше ніж 150 табличних і графічних звітів, що настроюються. Для складних комплексних проектів можна використати зведені матричні і табличні звіти, що настроюються, а також спеціально розроблені за допомогою вбудованого редактора призначені для користувача звіти. Можна виділяти роботи за допомогою фільтрів, що настроюються, використовуючи різні набори кодів, призначених для користувача полів даних, часових, ресурсних і вартісних даних. Для кращого подання звітів можна використати будь-яку з 28 найпоширеніших мов, закладених в P3, включаючи й російську. Інформація на Web. Користувач може поширювати інформацію щодо проекту, використовуючи мережі INTERNET і/або свою власну корпоративну INTRANET. Майстер Web-звітів допоможе в інтерактивному режимі створити структури категорій проектів, проектів і типових звітів по проектах, так що можна подивитися укрупнену інформацію по проектах або, за необхідності, вивчити деталі. Для цього досить мати Netscape Navigator, або Microsoft Internet Explorer. Інтеграція даних. Технологія OLE дозволяє включати в звіти дані з інших додатків, наприклад креслення конструкторської документації, таблиці, малюнки, відскановані образи, текстові документи і навіть аудіо- і відеофрагменти. 5.4.3. Програмний додаток Primaplan Project Investigator Програма Primaplan Project Investigator дозволяє порівнювати дві версії проекту або групи проектів, переглядаючи при цьому всі поля даних, що існують у проекті P3. Крім того, при порівнянні виявляються видалені й додані роботи, ресурси, залежність і записи, зроблені в журналі роботи. Всі зміни виводяться на екран у наочній формі, кодовані кольором, так що можна легко переглядати результати порівняння. Після цього можна дати команду, і Primaplan Project Investigator перепише дані по одній роботі або по всіх тих, яким користувач «дав добро», з оновленого проекту в основний. Виконавши таку процедуру декілька разів, можна оновити основний проект (рис. 5.13). Рис. 5.13. Основне діалогове вікно Primaplan Project Investigator Серед найважливіших характеристик програми треба назвати такі: 1) Primaplan Project Investigator порівнює близько тисячі робіт, перевіряючи при цьому опис роботи, початкові та залишкові тривалості, дати фактичного старту і фінішу, поля користувача даних, коди, залежність та інші поля даних. При цьому Primaplan Project Investigator виявляє додані й вилучені роботи, залежності, зміни в ресурсних даних і рядках журналу роботи (рис. 5.14). Рис. 5.14. Вибір полів для порівняння 2) Можна перевіряти зміни не по всіх полях даних, а тільки по частині з них, починаючи з опису роботи і закінчуючи окремими кодами роботи і призначеними для користувача полями даних. 3) Після порівняння проектів Primaplan Project Investigator показує на екрані в табличній формі всі відмінності між проектами, кодуючи при цьому їх кольором. Приміром, вилучені дані показані червоним, додані — зеленим, а такі, що змінили свої значення, — синім кольором. 4) За підсумками порівняння проектів можна роздрукувати чотири звіти. Стислий звіт містить статистичну інформацію про підсумки порівняння. Матричний звіт показує зміни в наочній формі. Звіт по категоріях дає список змін для всіх робіт по кожному з полів даних (по опису роботи, потім по вихідній тривалості і т. ін.). Докладний звіт містить повну інформацію по всіх змінах для кожної з робіт. 5) Для кожної з робіт можна підтвердити або відхилити зроблені зміни. Пізніше, при передачі даних в основний проект, буде передана тільки підтверджена користувачем інформація. Програма Primaplan Project Investigator працює спільно з системою планування P3 (Primavera Project Planner for Windows). Primaplan Project Investigator є 32-бітовим додатком. 5.4.4. Аналіз ризику на основі програмного додатка Monte Carlo Monte Carlo — програмний продукт фірми Primavera, який дозволяє аналізувати ризики, пов’язані з вибраними аспектами проекту й оцінити їх значущість. Імітатор дає змогу отримати графіки, які показують один або більше з можливих результатів проек¬тування. Monte Carlo дає інформацію для прогнозування проблем, розвитку комплексних планів, управління критичною ситуацією, що базується на імовірностях подій. Monte Carlo дає також інформацію для прийняття вірного рішення, якщо оцінки розкладу проекту і його вартості ускладнюються подіями або умовами, що вийшли з-під контролю (приміром, погана погода, брак матеріалів або робочої сили). Monte Carlo надає засоби — звіти і графіки — для точного й ефективного сповіщення клієнтів, управлінців та керівників про труднощі й критичні ситуації. Після запуску програми оцінки ризику в Monte Carlo існує можливість порівнювати детерміновані й вірогідні оцінки ситуації, використовуючи Лінійний графік Р3, настроювання і можливості макета. Роботи в Р3 мають фіксовану тривалість, а загальна тривалість проекту визначається найдовшим шляхом його реалізації. У Monte Carlo встановлюють оцінки діапазону тривалості етапів проекту у вигляді мінімального, найбільш вірогідного і максимального його значень. Цей діапазон оцінок дозволяє знайти дату завершення проекту більш акуратно, ніж за фіксованої тривалості робіт. У Р3 робота є критичною, коли вона перебуває на критичному шля- ху. При оцінці критичного шляху в Monte Carlo кількість випадків, коли ця робота потрапляє на критичний шлях (наприклад, у 50 випадках із 100), вказує на ступінь її критичності. Завдяки опції Quick-Risk в Monte Carlo можна вводити процент відхилення від фіксованого значення для визначення діапазону, який використовується в Monte Carlo у розрахунках тривалості робіт. 5.4.5. Програмний додаток Webster Спеціальний програмний додаток Webster для Primavera забезпечує доступ до даних по проекту за допомогою Web-брау-зера. Webster для Primavera розширює доступ до даних проекту в межах інформаційної технології Concentric Project Management — від локальної мережі до корпоративної мережі Intrаnet. Програма Primavera надає можливість за допомогою Web-браузера звертатися до робіт проекту в режимі реального часу, переглядати й оновлювати дані по них. Завдяки цьому відповідальні особи володітимуть необхідною інформацією для прийняття рішень щодо управління проектом. Webster для Primavera використовує базу даних проекту спільно з Primavera Project Planner (P3) і SureTrak Project Manager. А це означає, що всі учасники проекту працюють з одними й тими самими даними. Володіючи найновішою інформацією, можна своєчасно ухвалювати відповідальні рішення. Програма дозволяє здійснювати: — доступ до даних проекту для будь-якого учасника, де б він не знаходився; — огляд завдань кожного виконавця по проектах; — управління проектом з урахуванням найновішої інформа-ції; — негайне оновлення даних по проекту; — додання в проект описів і посилань на документи; — можливість вносити інформацію про відпрацьований час поза проектом. Завдяки Webster для Primavera всі учасники проекту можуть отримувати списки робіт, впорядковані по проектах, по даті старту або фінішу, проценту завершення або по описах робіт. Виконавці працюють з одним списком робіт, що стосуються різних проектів, навіть якщо комусь із них у різних проектах приписані різні імена. Вони отримують простий список робіт, які повинні бути виконані в певний проміжок часу. Керівники проектів можуть отримати всю цю інформацію з бази даних P3 або SureTrak. Як альтернатива календарно-сітьовому графіку учасники про-екту можуть використати режим почасового перегляду, який містить інформацію про робітників, терміни і типи робіт: час виконання кожної з робіт, відпустки, лікарняні тощо. Webster для Primavera автоматично оновлює відповідні поля в базі даних проекту й обчислює приблизну кількість годин до завершення роботи. ? Збереження важливої інформації Докладні записи, вбудовані посилання на документи, Web-сторінки, внесені в журнали робіт Webster, автоматично стають частиною бази даних проекту, яку можна переглянути в P3 або SureTrak. Оскільки безпосередні виконавці краще за всіх знають стан своїх робіт, має сенс дозволити їм вводити фактичні дані по роботах. Для цього не треба ніякої спеціальної підготовки — тільки Web-браузер і Webster для Primavera. Виконавці зможуть самостійно записувати, скільки часу було витрачено на роботу, скільки потрібно для її завершення, яким є процент її виконання. Таким чином, керівник проекту краще уявлятиме загальний стан проекту. ? Єдина система видачі завдань Виконавці отримують завдання, звітують про затрачений час і про виконання роботи. Керівники проектів можуть отримати цю інформацію з бази даних P3 або SureTrak. Оскільки Webster працює безпосередньо з базою даних проекту, то існує упевненість, що всі мають справу з однією і тією самою інформацією, незалежно від додатку, яким користуються. Учасники проекту, що працюють з найновішими версіями Web-браузера і Webster для Primavera, мають доступ до останньої інформації про проект через загальну мережу intranet або через INTERNET. ? 5.4.6. Програмний додаток Ra Програма Ra поєднує в собі новий, об’єктно-орієнтований OLE 2.0 — сервер з блоком розрахунку розкладу P3. Це потужний інструмент, який може бути використаний при написанні інтерфейсів до даних проекту P3. Ra можна використати і під час створення інтерфейсів між розкладом проекту й іншими інформаційними системами підприємства, і як окремий «калькулятор» розкладу, робіт, ресурсів і вартостей, що може бути викликаний як фоновий процес будь-яким OLE — сумісним додатком. Ra надає доступ до ядра бази даних P3, дозволяючи добиратися з інших додатків до розкладу, робіт, ресурсів і вартостей проекту. Завдяки використанню Ra можна пов’язати з проектом P3 бух¬галтерську систему, кошторисну або конструкторську програму. Розробникам програмного забезпечення Ra дає можливість включати у власні корпоративні системи блок розрахунку розкладу. Користувач при цьому має тільки звичний йому інтерфейс, у який вміщуються дані про розклад. З використанням Ra написані такі додатки, як Primavera Enterprise Access Kit (PEAK), за допомогою якого можна пов’я-зати P3 із системами планування ресурсів ERP, як Oracle і SAP. Крім того, програмне забезпечення DataStore для Primavera доповнює аналіз проекту P3 передачею даних в Oracle (рис. 5.15 та 5.16). Рис. 5.15. Зв’язок програми Ra з іншими додатками Primavera Рис. 5.16. Зв’язок Ra з інформаційними системами управління підприємствами Консультанти і незалежні постачальники програмного забезпечення тепер використовують Ra для створення повноцінних, двоспрямованих потоків даних між власними додатками і P3. Завдяки простому інтерфейсу Ra зусилля, необхідні для створення таких додатків, виявляються мінімальними. Позитивною стороною Ra є те, що при зверненні до даних проекту P3 беруться до уваги всі бізнес-правила, а це означає, що оновлення даних відбувається коректно й автоматично оновлюються всі пов’язані поля. 5.4.7. Програмний додаток Expedition 6.0 Додаток Expedition 6.0 — це система для всебічного управління контрактами; вона може працювати в багатокористувацькому режимі й одночасно з кількома проектами, в тому числі й видаленими. Основу Expedition становить база даних, побудована в архітектурі «клієнт—сервер». Процедури управління контрактами можна настроювати, забезпечуючи своєчасне виконання робіт за проектом і запобігаючи можливим затримкам (рис. 5.17). Рис. 5.17. Вікно огляду проекту в Expedition 6.0 1) Expedition своєчасно надає необхідні документи. Завдяки останнім можливим є доступ до останніх редакцій усіх креслень у момент їх введення у систему. За допомогою Expedition можна ухвалювати більш обґрунтовані рішення на основі найновішої інформації про проектну документацію, специфікації, креслення і зміни в розкладі з Primavera Project Planner (P3 ) або SureTrak Project Manager. 2) Expedition дозволяє уникнути затримок під час виконання проекту. Короткий і наочний огляд стану проекту дає змогу спланувати роботи на майбутній період. За допомогою Expedi¬tion можна оцінити вплив термінів розгляду і затвердження проектної документації на розклад будівництва. 3) Уся інформація зібрана в одній таблиці. У Журналі обліку креслень за контрактом містяться точні дані про останні етапи розгляду креслень і про відповідальних виконавців. Інструмент «Комп¬лекти креслень» забезпечує складання добірок креслень, супровідного листа до них та їх розсилки. У результаті зацікавлені особи вчасно отримають всі останні редакції (рис. 5.18). 4) Expedition надає відповіді на питання користувачів. На всі питання щодо працівників, матеріалів проекту — календарно-мережних графіків, сертифікатів, зразків матеріалів, специфікацій обладнання тощо — (наприклад, «Чи були вони представлені?», «У кого вони знаходяться в даний момент?», «Чи затвердили їх?», «Кому направлені зауваження?») — в Expedition є відповідь. Дати проходження всіх етапів розгляду і затвердження робочих матеріалів обчислюються виходячи з часу, необхідного для виготовлення і доставки матеріалів і обладнання. Це дозволяє запобігти можливим затримкам. Рис. 5.18. Діалогове вікно «Комплекти креслень» 5) Точна і своєчасна передача повідомлень. Користувач може довести свою думку до всіх зацікавлених осіб. Система Expedi-tion автоматично створить супровідні листи, збере в одне поштове відправлення всі повідомлення, адресовані одній і тій самій особі, надрукує поштові наклейки або відішле їх факсом або електронною поштою (рис. 5.19). 6) Проект перебуває під контролем. Завдяки системі Expedi-tion жодна інформація не буде упущена, втрачена або забута. За допомогою системи Expedition можна організувати зберіган- ня, пошук і приєднання будь-якої необхідної документації: відсканованих документів, креслень, підготовлених системою автоматизованого проектування, фотографій, зроблених цифровими фотоапаратами, текстових файлів і електронних таблиць. Усе це являє собою зручний архів для запису і відновлення проектної інформації. 7) Прогнозування результатів змін. Інструмент «Управління змінами» дозволяє вмить оцінити наслідки змін, які відбиваються на вартості й розкладі усього проекту загалом. Відразу виявляються сторони за контрактами, яким буде потрібна закупівля нових матеріалів і обладнання, і ті, для кого ці зміни спричинять затримку в роботі. Рис. 5.19. Супроводжувальний лист, сформований за допомогою Expedition 6.0 8) Швидке вирішення питань і проблем. Ніякі проблеми не повинні гальмувати роботу проекту. У системі Expedition є інструмент «Створити добірку», що дозволяє за допомогою пошуку ключових слів у всіх документах, включаючи приєднані, вибрати всі матеріали, що стосуються даної проблеми. Система Expedition веде Журнал добірок, в якому фіксуються всі події. З нього завжди можна дізнатися, що сталося, коли і хто за це відповідає. 9) Контроль витрат. У системі Expedition є Таблиця витрат, в якій відображені всі прибуткові й витратні статті за контрактами. Ця таблиця дозволяє відстежувати фінансування проекту, аналізувати вартість субпідрядних договорів і договорів на постачання, а також вводити платіжні документи і рахунки-фактури у міру їхнього надходження. Таблиця витрат автоматич-но оновлюється під час створення у межах системи Expedition будь-якого документа, пов’язаного з витратами, забезпечуючи тим самим інформаційну підтримку при прийнятті фінансових управлінських рішень. 10) Швидке створення платіжних документів. Система Ex-pe¬dition автоматично формує платіжні документи з урахуванням даних про поставлені матеріали і затверджених розпоряджень про зміну за вказаний період часу. У платіжних документах може бути відображена інформація про первинну вартість контракту, сумарні зміни до контракту і фактичні платежі за контрактом на поточну дату. 11) Облік тенденцій зміни вартості. Управління фінансами не повинно будуватися на здогадках. Система Expedition допомагає зазирнути наперед і побачити, що станеться, якщо передбачувані зміни будуть затверджені. При цьому можна оцінити їхні наслідки для свого контракту і зробити необхідні кроки. Вихідна інформація системи Expedition може бути використана як початкові дані для системи бухгалтерського обліку. 12) Управління будівельними контрактами спрощується. В Expedition можна отримати наочне уявлення про стан проекту, переглядаючи його розклад у вигляді лінійного графіка. Система Expedition виявляє потенційні проблеми до того, як вони позначаться на терміні закінчення проекту. АВТОМАТИЗАЦІЯ ПРОЦЕСІВ БІЗНЕС-ПЛАНУВАННЯ ІНВЕСТИЦІЙНИХ ПРОЕКТІВ ТА СТРАТЕГІЧНОЇ ОЦІНКИ БІЗНЕСУ НА ПІДПРИЄМСТВАХ 6.1. ЗАГАЛЬНА ХАРАКТЕРИСТИКА ПРОГРАМНИХ ПРОДУКТІВ ДЛЯ БІЗНЕС-ПЛАНУВАННЯ ІНВЕСТИЦІЙНИХ ПРОЕКТІВ НА ПІДПРИЄМСТВАХ Планування на підприємстві завжди пов’язане з майбутнім, а модель є уявленням очікуваної реальності. Таким чином, уявлення можливих майбутніх стратегій може розглядатися як моделювання майбутнього. Розвиток моделювання в фінансах відбувається завдяки створенню моделей, здатних дедалі більш адекватно описувати реальність. Бурхливий розвиток інформаційних технологій та обчислювальної техніки надає фахівцям широкі можливості для створення все більш ефективних фінансових моделей. Необхідність обліку впливу безлічі динамічно змінних у часі чинників обмежує застосування статичних методів, які можуть бути рекомендовані тільки для проведення грубих, попередніх розрахунків, з метою орієнтовної оцінки ефективності проекту. Більш ефективними, і такими, що дозволяють розрахувати проект, у якому було б взято до уваги безліч вказаних чинників, є динамічні методи, засновані на імітаційному моделюванні. Імітаційні фінансові моделі підприємства, побудовані за допомогою відповідних ком¬п’ютерних систем, забезпечують генерацію стандартних бухгалтерських процедур і звітних фінансових документів, як наслідок бізнес-операцій, що реалізуються в часі. Під бізнес-операціями маються на увазі конкретні дії, здійснювані підприємством у процесі економічної діяльності, наслідком яких є зміни в обсягах і напрямках руху потоків грошових засобів. Ці моделі відображають реальну діяльність підприємства через опис грошових потоків (над-ходжень і виплат) як подій, що відбуваються в різні періоди часу. Зважаючи на те, що під час розрахунків використовуються такі важко прогнозовані чинники, як показники інфляції, плановані обсяги збуту та багато інших, для розробки стратегічного плану й аналізу ефективності проекту застосовується сценарний підхід. Сценарний підхід передбачає здійснення альтернативних розрахунків на основі даних, що відповідають різним варіантам розвитку проекту. Використання імітаційних фінансових моделей у процесі планування й аналізу ефективності діяльності підприємства або інвестиційного проекту, який реалізується, є досить сильним і дійовим засобом, що дозволяє «програти» різні варіанти стратегій і прийняти обґрунтоване управлінське рішення, спрямоване на досягнення цілей підприємства. Найчастіше для автоматизації бізнес-планування в нашій країні застосовують такі пакети прикладних програм: COMFAR (Computer model for feasibility analysis and reporting) і PROPSPIN (Project profile screening and preappraisal information system), створені при UNIDO — Організації Об’єднаних Націй з промислового розвитку, пакет «Альт-Инвест» фірми «Альт» (Санкт-Петер¬бург) та пакет «Project Expert» фірми «Pro-Invest Consulting». Порівняльні характеристики цих та інших продуктів наведені в табл. 6.1. Таблиця 6.1 ФУНКЦІОНАЛЬНІ ХАРАКТЕРИСТИКИ ПРОГРАМ ДЛЯ БІЗНЕС-ПЛАНУВАННЯ ТА ФІНАНСОВОГО АНАЛІЗУ ДІЯЛЬНОСТІ ПІДПРИЄМСТВ Програма для фундаментального аналізу COMFAR for windows Інве-стор Банківський аналітик «Альт-Фінан-си» «Альт-Ін-вест» EDIP FOCCAL Фінансовий аналіз підприємства «Project Expert for win-dows» Розроблювач UNIDO ІнЕк «Альт», С.-Петербург Центр-Інвест Софт Інфо-софт «ProInvest Consul- ting» Сегмент фінансового ринку, на якому використовується програмно-мате-матичний засіб (ПМС) Кредитний ринок + + + + + + + + + Ринок корпоративних папе-рів + + + + + Учасники фінансового ринку, на яких у першу чергу орієнтоване ПМС Державні органи влади і керування + + + + + + Інвестиційні інститути — інвестиційні консультанти + + + + + + Закінчення табл. 6.1 Програма для фундаментального аналізу COMFAR for windows Інве-стор Банківський аналітик «Альт-Фінан-си» «Альт-Ін-вест» EDIP FOCCAL Фінансовий аналіз підприємства «Project Expert for win-dows» Розроблювач UNIDO ІнЕк «Альт», С.-Петербург Центр-Інвест Софт Інфо-софт «ProInvest Consul- ting» — інвестиційні ком-па¬нії + + + + + + + — інвестиційні фонди + + + + + + + Банки — кредитні відділи + + + + + — відділи цінних паперів + + + Інші інвестори — корпоративні + + + + + — інституціональні + + + + + + Споживачі інвес-тицій — корпоративні + + + + + — інституціональні + + + + + Характер діяльності, що автоматизується: — інформаційна + + + — пошукова + + + — документоутворювальна + + + + + + + + Фаза життєвого циклу інвестицій, на якій використовується ПМС Вивчення об’єкта і кіль¬кісний аналіз інвестицій + + + + + + + + + Складання проекту пла¬ну фінансування інвес¬тицій + + + + + + Прийняття рішення про інвестиції і розробка плану їх здійснення + + + + + + + + + Пакет прикладних програм COMFAR існує в різних версіях, значною мірою адаптованих до економіки конкретних країн і перекладений на російську мову. Перша версія пакета була створена ще 1982 року, тому, незважаючи на значні удосконалення, деякі підходи до уявлення даних помітно застаріли. Пакет офіційно поширюється представництвом UNIDO, але через високу вартість цей програмний продукт не знайшов у країнах СНД покупців. Однак недосконалість законодавства і недостатній розвиток цивілізованого ринку програмних продуктів призвели до того, що він дістав неофіційне поширення і досить активно застосовується для оцінки інвестиційних проектів. Пакет «Альт-Инвест» реалізований як обчислювач на електронних таблицях і має всі переваги і недоліки такого підходу. Пакет Project Expert значно відрізняється від перелічених вище продуктів. Системність у рішенні багатьох проблем, урахування специфіки національних умов, потужна рекламна кампанія робить заявку цього програмного продукту на лідерство в даній галузі досить вагомою. Пакет рекламується як засіб підготовки бізнес-планів міжнародного зразка і до певної міри відповідає меті, що декларується. Вказані продукти містять досить докладний аналіз фінансового стану проекту з метою відстежити основні стадії реалізації як усього проекту, так і його основних етапів. 6.2. ПРОГРАМНІ ПРОДУКТИ COMFAR ТА PROPSPIN В основу пакетів COMFAR і PROPSPIN покладена методика UNIDO з підготування техніко-економічних досліджень. Структура даних пакета COMFAR подана такими основними блоками: — загальні капіталовкладення — будівництво; — загальні капіталовкладення — виробництво; — потреба в оборотному капіталі; — джерела фінансування; — таблиці руху коштів; — звіти про чистий прибуток; — проектно-балансові відомості. Розрахунки можна здійснювати в будь-якій валюті, обравши співвідношення її до рубля. Пакет дозволяє простежити окремо іноземні й вітчизняні інвестиції, дає можливість розрахувати диверсифіковане виробництво. Можливим є вирішення завдань як рівномірної амортизації, так і лінійної (до залишкової вартості) та прискореної. Розраховуючи виробничі витрати, користувач задає річний темп інфляції. Таким чином відстежуються всі зміни щорічних потоків готівки з обліком сплати податків, виплати дивідендів і відсотків за позиками. COMFAR здійснює розрахунок фінансових потоків таких фінансових показників, як чистий дисконтований прибуток, прибуток на акціонерний капітал, внутрішня норма прибутковості тощо. Пакет COMFAR реалізований у вигляді трьох програмних блоків (рис. 6.1 та 6.2): 1) введення даних; 2) розрахунків; 3) видача результатів. Рис. 6.1. Загальний вигляд діалогового вікна блоку введення даних у COMFAR Крім зазначених блоків, у пакеті подані два додаткових бло-ки: — графічного відображення інформації; — економічного аналізу «витрат-вигод». Рис. 6.2. Структура блоку проведення розрахунків у COMFAR Графічний блок дає можливість за допомогою засобів ділової графіки будувати діаграми, що дозволяють приймати організаційні та фінансові рішення з урахуванням аналізу чутливості таких важливих перемінних показників, як ціна продажів, обсяг виробництва і реалізації, розмір витрат і т. ін. (рис. 6.3). Метою проведення економічного аналізу є також бажання знайти дійсний результат реалізації проекту в умовах конкретної національної (регіональної) економіки і прийняти оптимальне інвестиційне рішення на весь період його виконання. До переваг пакету COMFAR з погляду виконання «контрольної» функції (тобто мінімізації можливості як помилок у методиці й розрахунку, так і свідомого підтасування результатів) належить закритість. У роботу пакета не можна втрутитися, що дає гарантію відповідності отриманих результатів уведеним даним і підвищує надійність результатів з точки зору їх достовірності. Хоча і в ранніх версіях пакета був відсутній автоматизований контроль відповідності між вхідною і вихідною інформацією, COMFAR є ліцензованим пакетом, що значно підвищує авторитет виконаних за його допомогою розрахунків. Рис. 6.3. Модуль аналізу чутливості в продукті COMFAR Основними недоліками пакета є неможливість існуючими в системі засобами адекватно описати умови реалізації проекту в країні з перехідною економікою. У даній системі також відсутній гнучкий механізм задання інфляційного впливу як на витрати, так і на співвідношення валют, не передбачені такі властиві українській економіці реалії, як затримки платежів. Є й інші вади: — неповна відповідність податкового блоку українському законодавству і необхідність застосування спеціальних прийомів для обходу наявних обмежень. COMFAR дозволяє прямо враховувати лише ті податки, що беруться й обчислюються виходячи з прибутку; — розрахунок системи тільки на фіксований (річний) період планування (у період будівництва — можливо півроку); — жорстка заданість переліку вихідних даних; — відсутність у системі досить розвинутих засобів для опису мережного графіка проекту, що зумовлює необхідність додатково використовувати програми Microsoft Project, Time Line та інші; — невисокий рівень сервісу для користувача. Пакет PROPSPIN (Project profile screening and preappraisal information system) являє собою інформаційну систему поперед-ньої оцінки проектів. Він був розроблений представництвом UNIDO для підготування, дослідження й аналізу промислових інвестиційних проектів. Як і COMFAR, PROPSPIN є ліцензованим і міжнародно визнаним програмним продуктом. PROPSPIN призначений для: — формулювання інвестиційного проекту; — дослідження наслідків змін обраних параметрів; — підготування можливих сценаріїв, заснованих на різних припущеннях щодо перспектив проекту. Відмітною рисою PROPSPIN є його інтегрованість. Користувач одночасно бачить на екрані і вхідні дані, і їхній фінансовий результат. Звіт, що отримується, являє собою варіант фінансового профілю проекту з урахуванням заданих обмежень. Водночас пакет не є засобом проведення повного фінансового аналізу, а служить для швидкого виявлення придатних для подальшого роз¬гляду варіантів. Таблиці, що генеруються системою, містять основні фізичні і фінансові показники, в них дається внутрішня оцінка прибутковості проектів з погляду таких показників, як норма прибутковості, період окупності, точка беззбитковості. Якщо аналіз виявляє слабкі місця у фінансовій структурі проекту, користувач має можливість змінювати значення вхідних даних доти, поки не знайдеться такий набір параметрів, який зробить проект прийнятним. PROPSPIN складається з двох частин: блока введення даних і генератора звітів. У першому задаються: початкові інвестиції, дані про вихідні матеріали, вартість робочої сили, вартість комплектуючих та інші дані. Деякі параметри можуть бути взяті за умовчанням. Генератор звітів створює таблиці, що відбивають: — початковий обсяг інвестицій та аналіз амортизації; — обсяг продажів і використання виробничих потужностей, потреби в ресурсах та електроенергії, витрати на заробітну плату і вартість основних фондів; — динаміку прибутків, а також містять: — аналіз передбачуваної фінансової структури й обслуговування боргу; — балансову відомість і таблицю грошових потоків; — аналіз доданої вартості й експортних ефектів; — виконавче зведення. Початкові дані проекту розбиті на групи: 1. Ідентифікація проекту. Тут користувач уводить найзагальніші дані про проект, як-от: назва проекту, місце розташування, імена розроблювачів і спонсорів проекту, обмінні курси валют, інформація про податки, інфляція і ставка дисконтування. 2. Інвестиції. Сюди вводяться такі дані, як вартість землі, машин, устаткування, транспорту й амортизаційні ставки. PRO-PSPIN надає користувачеві можливість розподілити інвестиційні вливання по перших п’яти роках, вказуючи відсоток, що доводиться на кожний рік. За умовчанням система вважатиме, що інвестування цілком доводиться на перший рік. 3. Фінансова структура. Ця таблиця містить зведення про всі необхідні фінансові виплати, їх терміни й умови. PRO¬PSPIN дозволяє вводити одну позику для кожного виду (довгострокову, середньострокову і короткострокову, зовнішню і внутрішню). 4. Поточні дані (виробництво/продаж; споживані ресурси; інші витрати). PROPSPIN являє собою стандартний пакет, що дає змогу здійснити попередній фінансовий аналіз інвестиційного проекту, система може бути використана під час складання бізнес-плану тільки як допоміжний засіб. Внаслідок своєї реалізації в середовищі електронних таблиць пакет має всі достоїнства та вади цього методу. 6.3. ПРОГРАМНІ ПРОДУКТИ ФІРМИ «АЛЬТ» Продукція фірми «Альт» виконана у форматі електронних таблиць і є повністю відкритою для користувача. Вона має «напівжорстку» структуру: побудова деяких модулів дозволяє користувачеві змінювати алгоритми розрахунків відповідно до специфіки свого підприємства. Інші модулі не допускають втручан¬ня користувача в алгоритми розрахунків. Програмні продукти фірми «Альт» утворюють необхідний пакет програм для фінансового менеджменту, куди входять: 1) програма для оцінки фінансового стану підприємства «Альт-фінанси»; 2) система для складання фінансового плану «Альт-план»; 3) програма для оцінки різних варіантів розвитку підприємства «Інвест». Програмним продуктом «Альт-фінанси» послуговуються під час вирішення двох задач: аналізу стану і визначення тенденцій розвитку підприємства. При аналізі фінансового стану підприємства враховуються обчислені програмою коефіцієнти ліквідності та фінансової стійкості. Система, дозволяючи простежити динаміку цих показників у часі, дає аналітикові картину розвитку підприємства, дозволяє скласти прогноз його діяльності на осяжний період. Вихідна інформація для аналізу формується на основі ряду бухгалтерських і фінансових документів. У результаті розрахунків програма створює звіт про прибутки і збитки, обчислює коефіцієнти загальної ліквідності (коефіцієнт загальної ліквідності виражає здатність підприємства виконувати короткострокові зобов’язання за рахунок усіх поточних активів), абсолютної ліквідності (коефіцієнт абсолютної ліквідності вказує на можливості підприємства виконувати короткострокові зобов’язання за рахунок вільних грошових коштів) і проміжної ліквідності (коефіцієнт проміжної ліквідності відображає здатність підприємства виконувати короткострокові зобов’язання за рахунок грошових коштів, короткострокових фінансових вкладень, дебіторської заборгованості та готової продукції на складі). Крім коефіцієнта загальної платоспроможності, що визначає частку власного капіталу в майні фірми, оцінюється фінансова стійкість або залеж¬ність підприємства від зовнішніх джерел фінансування, для чого використовується спеціальна серія коефіцієнтів, пов’язана з імовірністю банкрутства (Z-рахунок Альтмана — комплексна величина, що включає в себе групу показників, зокрема, структуру активів і пасивів, рентабельність, оборотність активів). Усіх перелічених показників директорові підприємства (але не фінансовому менеджеру) цілком достатньо: якщо значення коефіцієнта знизилося з 3.0 (що означає низьку імовірність банкрутства) до 1.8 (дуже висока імовірність) — це означає, що настав час займатися кадровою політикою і звільняти фінансового менеджера; якщо значення коефіцієнта зростає, — обрано правильний напрям діяльності підприємства. Для фінансового менеджера більш важливою є інша вихідна інформація, яка відбиває те, що виконується програмою аналізу прибутковості, та включає розрахунок таких показників: прибутковість змінних витрат (свідчить про зміну валового прибутку за зміни змін¬них витрат на одиницю в грошовому вираженні), а також прибутковість усіх витрат (відображає прибуток від основної діяльності, що доводиться на одиницю поточних витрат у грошовому вираженні). Важливим результатом обчислень є факторний аналіз рента-бельності, що відображає вплив таких чинників, як прибутковість продажу, оборотність активів, структура джерел, на рентабель-ність підприємства, що дозволяє виявити «вузькі місця» і гострі проблеми, які вимагають першочергової уваги фінансового ме-неджера. Після цього розпочинають формування фінансового плану за допомогою програмного продукту «Альт-план». Програмний продукт «Альт-план» складається з п’яти блоків: 1) опис запланованої номенклатури виробництва; 2) опис поточного фінансового стану підприємства, тобто ба-ланс; 3) дані про отриману оплату за відвантажену продукцію і пе-редоплату, що надійшла підприємству, за майбутнє постачання; 4) на підставі даних першого-третього блоків здійснюється оцінка поточного і перспективного виторгу від реалізації; 5) опис витрат із поділом їх на перемінні (ті, що залежать від обсягу виробництва) і постійні (незалежні від обсягу виробницт-ва). Результатом аналізу є оцінка витрат, необхідних для реалізації складеного плану. Таким чином, фінансовий менеджер отримує модель перспективного звіту про прибутки і збитки і на основі інформації про підсумкові та інші виплати з прибутку може оцінити чистий прибуток за період, що планується, і прийняти відповідні управлінські рішення (пов’язані в негативному випадку, наприклад, зі скороченням виробництва, зміною ціни продукції або обсягів випуску тощо), які допоможуть виправити становище. Якщо ж управлінські рішення передбачають інвестування капіталу, то може стати у пригоді програмний продукт «Альт-Інвест», призначений безпосередньо для оцінки інвестиційних проектів. Пакет «Альт-Інвест» реалізований із використанням елект-ронних таблиць Microsoft works або EXCEL і може працювати в середовищі інших поширених табличних процесорів (SuperCalc 4, Lotus 1-2-3, QUATTRO Pro). Це накладає відбиток на всю по-дальшу роботу з ним. Достоїнством пакета є те, що вся інформа-ція подана на одному екрані. Змінивши значення показників, ко-ристувач миттєво одержує відповідь на свої дії. «Альт-Інвест» випускається в російсько- та англомовному варіантах, передбачає можливість розрахунків у двох валютах. В «Альт-Інвесті» користувач має безпосередній доступ до формул, за якими здійснюються розрахунки. До недоліків такої організації можна віднести: незручність користування таблицями (у пошуках потрібних показників користувач повинен щоразу розглядати всю електронну таблицю або пам’ятати її координати); складності зміни формул, що потребує від користувача не тільки глибокого розуміння їхнього змісту, а й уміння правильно програмувати формули мовою даної електронної таблиці; від користувача вимагаються значні зусилля, щоб коректувати таблиці. Наявність вільного доступу до формул утруднює перевірку достовірності виконаних розрахунків. Крім того, у пакеті також бракує розвинутих засобів для побудови сітьового графіка, а процеси видачі результатів на друк або побудову графіків вимагають від користувача спеціального навчання. Пакет «Альт-Інвест» дозволяє робити розрахунки в постійних і в поточних цінах, при цьому розрахунок у постійних цінах здійснюється з використанням реальної на кожний заданий момент ставки банківського відсотка. Пакет дозволяє оцінити реакцію основних параметрів проекту на різні сценарії інфляційних процесів, що особливо важливо для сучасної ситуації. Податковий блок пакета «Альт-Інвест» більшою мірою адап-тований до російського законодавства, у ньому закладені можли-вості настроювати блоки вхідних даних на умови, що відповідають реальній ситуації (податки, інфляція тощо). Такий підхід надає користувачеві широкий вибір різних форм фінансування проекту через кредитування, емісію простих і привілейованих акцій, пошук надійних гарантів і можливих операцій з об’єктами незавершеного будівництва та інші форми фінансування і їх комбінації. Універсальні таблиці з розрахунку виплат по кредитах можуть бути використані для упорядкування оптимальних графіків погашення кредитів з урахуванням поточного фінансового стану проекту. Пакет дозволяє змінювати стосовно до даного проекту період планування (за умовчанням береться 90 днів) і кількість періодів планування. Досить зручною є видача вихідних форм, що дозволяє в межах роботи із системою створювати текстовий пояснювальний матеріал із введенням у нього табличної і графічної інформації. 6.4. ПРОГРАМНИЙ КОМПЛЕКС «ІНВЕСТОР» Програмний комплекс «Інвестор» займає за «закритістю» проміжне положення між Project Expert і «Альт-Інвест». Він є могутнім інструментом у техніко-економічному дослідженні інвестиційних проектів і формуванні на їхній основі інвестиційних програм. Методичною основою створення комплексу є рекомендації провідних міжнародних фінансових інститутів з підготовки тех-ніко-економічних досліджень інвестиційних проектів. Відмітною особливістю комплексу є його багатофункціональ-ність та універсальність застосування. Він може бути використа-ний для розрахунку інвестиційних проектів для діючих або спо-руджуваних промислових і торгових підприємств. Програмний комплекс «Інвестор» призначений також для тих, хто розробляє та розраховує інвестиційні проекти на своїх підприємствах, ре-ципієнтів (економістів, інженерно-технічних працівників і керів-ників підприємств) і тих, хто формує інвестиційні програми для фінансування, — інвесторів (керівників інвестиційних компаній, банків і інших кредитно-фінансових установ, підприємців, фахів-ців, а також органів державної влади і управління). Розгляньмо тільки ті аспекти, які відрізняють комплекс «Інве-стор» від усіх програмних продуктів, що використовуються на ринку СНД. Насамперед комплекс передбачає необхідність проведення аналізу фінансового стану реципієнта, який здійснюється за да-ними стандартних форм балансу і звіту про фінансові результати, причому ці дані автоматично можуть бути перенесені в «Інвестор» з будь-якої електронної бухгалтерії, що формує зовнішні форми бухгалтерської звітності. Покладена в основу аналізу і прогнозу економічної діяльності підприємства так звана «Багатофакторна модель вимірювання про¬дуктивності» у варіанті, розробленому «Вірджінським центром продуктивності» (США), дозволяє одночасно провести діагностику господарської діяльності об’єкта інвестування. Таким чином, «Інвестор» може бути ефективно використаний і для діагностики фінансово-господарського стану реципієнта на початковому етапі здійснення передінвестиційних досліджень. Однією з істотних особливостей комплексу є те, що форму-вання і розрахунок прогнозного балансу здійснюється в стан-дартній формі, прийнятій у бухгалтерському обліку на території України. Прогнозний баланс і звіт про фінансові результати складають-ся на основі початкової фінансової інформації діючого підприєм-ства з урахуванням спланованої виробничої діяльності. Алгоритм розрахунку прогнозного балансу дає змогу досить точно планувати фінансову діяльність на плановий період розви-тку підприємства або здійснення інвестиційного проекту з ураху-ванням специфіки формування фінансових результатів діяльності підприємств і податкової політики. Крім цього, на основі фінансового прогнозування будуються грошові потоки «прямим» і «непрямим» методами, перший з яких найчастіше використовується в Росії, другий — у країнах Західної Європи. Результати розрахунку прогнозного балансу і звіту про фінан-сові результати можуть бути експортовані у блок «Фінансовий аналіз», де на базі методики, розробленої фахівцями фірми «ІнЕк», можна розрахувати понад 90 абсолютних і відносних показників. Автоматично формується аналітичний баланс-нетто, баланс і звіт будь-якого підприємства перераховується в баланс і звіт по стандартах GAAP (Generally Accepted Accounting Principles, FASB, USA) і може бути поданий російською та англійською мовами. Одночасно розраховуються і узагальнюючі показники фінансової оцінки інвестиційного проекту відповідно до прийнятих методик. Таким чином, іноземні інвестори можуть отримати всю фінансову інформацію про проект у звичному вигляді, що відповідає міжнародним стандартам. Важливою відмітною особливістю комплексу є всебічний аналіз господарської діяльності підприємства або виробничого плану здійснення інвестиційного проекту. Використовуються в комплексі різні моделі аналізу (індексний, факторний, графічний та ін.), що дозволяє отримати детальну картину формування ви-трат виробництва і збуту продукції. Комплекс пропонує два режими аналізу залежно від міри гли-бини й подробиць опрацювання — автоматичний і ручний. Автоматичний аналіз — за заданим алгоритмом провадиться ретельне дослідження усіх фінансово-економічних аспектів інве-стиційного проекту, починаючи з умов його фінансування і за-кінчуючи загальною оцінкою спроможності проекту із зазначен-ням найбільш негативних моментів у його реалізації. Аналіз може бути проведений як по проекту загалом, так і по окремих його розділах. Автоматично аналіз проводиться в графічному вигляді і супроводжується текстовим коментарем, уся інформація якого може бути використана для первинного оформлення проекту. На підставі цього аналізу можна виявляти слабкі місця виробничого плану інвестиційного проекту, і отже, міру ризику вкладення коштів у цей проект. Внаслідок проведеного аналізу роз¬робники мають можливість сформувати декілька альтернативних варіантів проекту (наприклад, із різними джерелами фінансування, різною структурою інвестиційних або виробничих витрат тощо). Крім цього, в режимі автоматичного аналізу програма сама пропонує короткий висновок за оцінкою основних показників ефективності та у разі невідповідності прийнятим параметрам підказує стандартні способи їх коригування. Наявність в «Інвесторі» спеціального блоку дозволяє зробити порівняльну оцінку розрахованих варіантів інвестиційного проекту. Вибір оптимального варіанта інвестиційного проекту провадиться на базі оригінальної методики, розробленої фахівцями фір¬ми. Для здійснення порівняльної оцінки експерт може використати весь набір показників, розрахованих у різних блоках комплексу. За результатами порівняльної оцінки обирається оптимальний варіант інвестиційного проекту й автоматично формуються і ви-даються на друк інформаційний меморандум і звіт по бізнес-плану (фінансовий розділ) стандартного змісту, заданого програмою. Розробник проекту може доповнити стандартний варіант бізнес-плану додатковою інформацією, використовуючи весь спектр сервісних можливостей комплексу, і підготувати бізнес-план інвестиційного проекту, що повністю відповідає міжнародним вимогам. Водночас комплекс може бути успішно використаний і у фор-муванні інвестиційних програм для передбачуваного фінансу-вання їх різними фінансовими інститутами. Технологія роботи в цьому режимі передбачає отримання інвестором усієї інформації з інвестиційних проектів, включаючи інформаційний меморан-дум, фінансову та економічну інформацію. Комплекс має додатковий блок «Регіональні ризики», що дозволяє аналітикові оцінити ризик вкладення фінансових коштів у інвестиційний проект залежно від місця розташування об’єкта інвестування на території країни. Методика розрахунку, що її ви-користовують фахівці фірми, дозволяє оцінювати різні чинники ризику як в окремих регіонах, так і загалом по країні, причому експерт може задати свої оцінки різним показникам і порівняти отриманий результат з «думкою» комплексу. Показники ризиків, розраховані в цьому блоці комплексу, можуть бути також вико-ристані під час остаточного прийняття рішень. Особливо треба зазначити, що комплекс має потужний пакет графічної підтримки. Це дозволяє здійснити експрес-аналіз фінансового стану об’єкта інвестування і отримати рішення у графічному вигляді (наприклад, визначити вартість майна підприємства, структуру підприємства, вартість його складових, а також виявити джерела фінансування, юридичну чи фізичну особу, яка його придбала), оцінити власні позикові кошти підприємства. В аналізі виробничого плану може бути використаний спеціальний блок «Графічне планування». Він може бути застосований як для аналізу проекту, наприклад, програми продажу, так і для графічного планування виробничої діяльності. При цьому графічна зміна параметрів проекту приводить до автоматичного перерахунку всієї бази даних. Важливою особливістю комплексу є, як уже зазначалося, мо-жливість проведення за допомогою спеціального блоку порівня-льного аналізу проектів, що є у інвестора, і формування на їх ос-нові оптимальної інвестиційної програми. При цьому кожний інвестор може використати додатково свої індивідуальні показ-ники, їх значення і пріоритети, що відповідають його інвестицій-ній політиці. Проведення аналізу по заданих показниках дає змогу за допомогою програми здійснити комплексну оцінку всіх інвестиційних проектів і визначити інтегральну оцінку кожного з них. На основі отриманих даних у інвестора є достатня інформація для прийняття правильного рішення в формуванні оптимальної інвестиційної програми. Програми можуть бути сформовані з урахуванням індивідуальних вимог інвестора або регіональних особливостей інвестиційної програми. Треба відмітити наявність у комплексі довідково-правової ба-зи даних з усіх питань інвестиційної діяльності, використання яких дає можливість отримувати необхідну правову інформацію, працюючи з будь-яким блоком комплексу. 6.5. ПРОГРАМНІ ПРОДУКТИ «PROJECT EXPERT» Пакет Project Expert є автоматизованою системою плануван-ня й аналізу ефективності інвестиційних проектів на базі іміта-ційних моделей грошових потоків. Розроблювач пакета фірма «ПроИнвест Консалтинг» тривалий час є учасником ринку програмних продуктів у галузі економіки і фінансів. Вона розпочинала свою діяльність у 1989 р. як інноваційний центр при АН СРСР і сьогодні має більш як 1500 користувачів Project Еxpert у Росії і за кордоном. За результатами кон¬курсу, проведеного в 1995 р. щотижневиком «Економіка і життя», Project Еxpert названо кращим програмним продуктом для бізнес-планування. У вересні 1995 р. у Лондоні, на Конфедерації британської промисловості успішно пройшла презентація англійської версії Project Expert для Windows. Успіх російського програмного продукту пояснюється тим, що він цілком, і передусім з методичного боку, відповідає міжнародним стандартам. У середині 90-х років найбільшого поширення набули дві такі версії продукту: 1. Project Expert for windows 4.1 (Business plan guide) — програмний продукт, призначений для планування й аналізу ефе-к¬тивності інвестицій. 2. Project Expert for Windows (Biz planner 4.2) — спеціальна версія для малого і середнього бізнесу. У цих варіантах системи Project Expert реалізована нова кон-цепція, що поєднує в собі два типи систем: — системи керування проектами; — корпоративні системи. Об’єднуючим є модуль «Інвестиційний план», у якому складається сітьовий графік проекту з описом етапів роботи, що потім об’єднуються в активи відповідно до вимог бухгалтерського обліку. Нумерація етапів і визначення чітких часових рамок відкриває можливість автоматичного відстеження інформації про послідов-ність етапів і використання результатів попередніх етапів для на-ступних. Блок даних про збут продукції дозволяє побудувати індиві-дуальну стратегію збуту по кожному продукту. Тут на відміну від інших програм він містить інформацію не тільки про обсяг продажів, запаси продукції на складі та її ціни, але й про частку експортних продажів, тенденції зміни ціни на продукцію, можливості продажів у кредит і з авансовими платежами (у версії Business plan guide). Крім того, в програмі досить ретельно враховуються витрати на просування продукту на ринку (комісійна винагорода, частка безповоротних витрат під час збуту, преміальні адміністративному персоналу). Блок оцінки виробничих витрат дозволяє задати наймену-вання матеріалів і комплектуючих, зазначити їхні частки у варто-сті продукції, ціну і тенденцію її зміни за рік, визначити страте-гію формування запасів матеріалів і комплектуючих. Блок даних про капітал надає можливість визначити зовнішні і внутрішні джерела фінансування. Project Expert має засоби, що дозволяють провести детальний фінансовий аналіз проекту з урахуванням впливу на нього за-гальноекономічних чинників, що характеризують соціально-еко-номічне середовище, а саме: тенденції в інфляції, співвідношення курсів валют, динаміку масштабів і структури затрат на виробництво, включаючи сировину, матеріали і комплектуючі вироби, заробітну плату керуючого і виробничого персоналу, вартість основних фондів, особливості порядку і часу проходження платежів за реалізовану продукцію, загальний інвестиційний клімат і умови притягнення капіталу, можливі зміни в системі податків. Враховуються також чинники, що визначають ринкову і виробничу стратегію проекту і впливають на ефективність використання капіталу: експортні можливості проекту, умови збуту продукції (послуг), умови оплати постачань сировини, матеріалів і комплектуючих, що використовуються у виробництві, необхідних обсягів запасів готової продукції на складі залежно від коливання ринкового попиту, а також запасів сировини, матеріалів і комплектуючих виробів залежно від сталості й надійності постачань. Project Expert здійснює розрахунок фінансових показників ефективності інвестицій, що відповідають міжнародним стандартам. У версії Business plan guide обчислюються також показники фінансового стану (рентабельність, ліквідність, платоспроможність). Пакет забезпечує подання результатів фінансового аналізу у вигляді таблиць, діаграм і графіків, що можуть бути виведені на друк. Користувачеві надається можливість зробити інтегральну оцінку проекту за багатьма критеріями. Оцінюючи програмну ре-алізацію, можна зазначити, що пакет виконаний із використанням сучасного багатовіконного інтерфейсу. Розширена система підказок, зручне подання інформації на екрані, можливість «спіл-кування» з інформацією і зручність виводу на друк дозволяють стверджувати, що пакет значною мірою задовольняє всі вимоги до програмних продуктів такого класу. Водночас можливі полі-пшення в сервісному обслуговуванні споживача і графічній реа-лізації фінансових змінних. Основні функціональні можливості обох версій пакета пока-зані в таблиці 6.2, і залежно від своїх потреб користувач може зробити відповідний вибір (вартість версії Biz planner становить приблизно 10% вартості Business plan guide). Таблиця 6.2 ОСНОВНІ ФУНКЦІОНАЛЬНІ МОЖЛИВОСТІ PROJECT EXPERT BUSINESS PLAN GUIDE І PROJECT EXPERT — BIZ PLANNER Функціональні можливості системи Business plan guide Biz planner Тривалість проекту До 30 років До 5 років Номенклатура продуктів (послуг) в одному проекті До 400 До 5 Вибір валюти проекту для проведення розрахунків Дві валюти для операцій на внутрішньому і зовнішньому ринках Одна валюта Податковий блок Адаптивний модуль опису податкового режиму Закінчення табл. 6.2 Функціональні можливості системи Business plan guide Biz planner Опис прогнозованого рівня інфляції Корекція усіх вихідних даних у процесі розрахунків відповідно до прогнозованого рівня інфляції Опис прогнозованого рівня інфляції по окремих статтях (збут, витрати, нерухомість, зарплата, енер-гоносії) Інвестиційний план Сітьовий графік проекту. Діаграми Гантта і PERT Зв’язок MS Project і Time line — Прямі виробничі витрати на кож-ний продукт До 10000 витрат До 5 витрат Постійні витрати Адміністративні, виробничі й витрати на маркетинг План витрат на заробітну плату. Структура виробничого й адміністративного персоналу Планування мар-кетингової стра-тегії і збуту для кожного продукту Ціна, стратегія продажів (у кредит, із передоплатою, система знижок), життєвий цикл продукту, урахування впливу сезонних коливань попиту Ціна, обсяг продажів, життєвий цикл продукту, затримки платежів Фінансовий план Стратегія фінансування проекту, визначення щомісячного дефіциту бюджету, акціонерний капітал, кредити, лізинг. Розміщення вільних засобів на депозит, рефінансування прибутку, виплата дивідендів Проведення автоматичного аналізу чутливості інвестиційного проекту за допомогою варіювання різних параметрів (обсяг продажів, ціна реалізації продукції (послуг), прямі виробничі витрати, постійні витрати, ставка рефінансування) — Результуючі таблиці Звіт про прибутки і збитки, баланс, звіт про рух коштів (Cash-Flow) Розрахунок показ¬ників ефективності інвестицій Період окупності РВ, індекс прибутковості РІ, чистий зведений розмір прибутку NPV, внутрішня норма рентабельності IRR Розрахунок показників фінансового стану Рентабельність, ліквідність, платоспроможність — Мови формування зві-ту Російська, англійська, іспанська, німецька і т. ін. Вивід результатів на друк й у MS WinWord у вигляді таблиць і графіків, що можуть передаватися в MS Graph Для більш якісного підготування бізнес-плану проекту на до-даток до основного пакета користувач може придбати також роз-роблений фірмою «ПроИнвест Консалтинг» пакет, що містить модулі Project Risk & Project Questionnaire. Як самостійні про-грамні продукти, модулі доповнюють Project Expert до системи, що забезпечує повну організаційно-технологічну підтримку інве-стиційного процесу. У модулі Project Risk передбачені засоби, що дозволяють експертам у діалоговому режимі проаналізувати ризик проекту, виділити чинники найбільшого ризику і прокоментувати причини їх виникнення. За допомогою спеціальних засобів модуля ство-рюється необхідний перелік чинників ризику, що враховує спе-цифічні умови реалізації проекту. Project Risk містить три розділи, що охоплюють усі періоди реалізації проекту: підготовчий період, період виробництва, період збуту. Під час аналізу експерт визначає рівень ризику по всіх чинниках листа опитування. Програма дозволяє виводити результати аналізу й листи опитування на принтер або формувати файл для передачі в MS WinWord. Project Questionnaire дозволяє зробити якісну експертизу інвестиційного проекту, обчислити інтегральний показник рівня ефективності проекту. Програма пропонує користувачеві 2 експертних листи, умовно названі «Інноваційне фінансування», дозволяє зберегти в базах до 10 різних експертних листів, у кожному з яких може міститися близько 100 критеріїв. Результати експертизи також можуть виводитися на пресу або передаватися в MS WinWord. Фірма «ПроИнвест Консалтинг» розвиває систему Project Expert у двох напрямах: для малого і середнього бізнесу, досту-пна будь-якому підприємству, а також як спеціальна версія індивідуального постачання для великих корпорацій. Головною задачею другого варіанта системи, реалізованої на базі Project Expert версії 5.0. (Система планування і керування проектами), є моделювання й оцінка дій багатопрофільної з різноманітним асортиментом продукції підприємства, що діє на кількох різних ринках. За певних умов ця система може використовуватися і регіональними органами влади для вирішення багатофункціональних задач соціально-економічного розвитку регіону, міста. Програма Project Expert 5 має декілька рівнів. Перший рівень — Project Expert 5 — більш розширений варі-ант попередньої версії, що має те саме призначення — розробка стратегічного плану розвитку підприємства. З урахуванням порад і побажань користувачів у нову версію включені спеціальні процедури опису діючого підприємства (стартовий баланс), розв’я¬зані плани збуту і виробництва, могутній генератор звіту і цілу низку інших новацій. Другий рівень — Project Expert 5 Professional — якісно новий рівень програми, що дозволяє не тільки здійснювати фінансове планування підприємства або проекту, а й контролювати вико-нання планів. Це досягається за допомогою процедури введення актуальних даних і відповідного інструментарію для контролю неузгоджень. Істотною відмінністю нової версії є також можли-вість агрегації (об’єднання) в межах одного підприємства декіль-кох проектів в один на рівні єдиного звіту про рух грошових ко-штів і дисконтованих критеріїв ефективності. Третій рівень — Project Expert Holding — призначений для фінансового планування і контролю діяльності великих корпора-цій. Технологічно Project Expert 5 відрізняється від попередньої версії тим, що є мережною програмою, яка дозволяє кільком фа-хівцям одночасно працювати з одним проектом. Результати порівняльного аналізу двох версій програмного продукту Project Expert подані в табл. 6.3. Програма Project Expert 5 Professional, крім актуалізації да-них, надає додаткову можливість для фінансового планування і контролю за реалізацією групи проектів. Для цього в програмний комплекс включений додатковий модуль — Project Integrator, що дозволяє будувати об’єднаний потік готівкових коштів («кэш-фло») для групи проектів і обчислювати сумарні дисконтовані ефективності (термін окупності, індекс прибутковості, внутріш-ню норму рентабельності, чистий зведений прибуток). Таблиця 6.3 ПОРІВНЯЛЬНИЙ АНАЛІЗ МОДУЛІВ МОДЕЛЮВАННЯ ПРОЕКТУ Project Expert 4.2 Project Expert 5 Загальний опис проекту Тривалість проекту — до 30 років Тривалість проекту — до 50 років Тривалість проекту ре-гу¬люється тільки по ро-ках Тривалість проекту регулюється з точністю до місяця Масштаб валюти: фік-сований Масштаб валюти: вибирається користувачем Інфляція — редагування загальної інфляції по роках Інфляція — можливість редагування прогнозу інфляції по місяцях Продовження табл. 6.3 Project Expert 4.2 Project Expert 5 Введення переліку товарів (до 400 найменувань): тільки в інвестиційному плані, жорстка прив’язка до сітьового графіка прое-кту Введення переліку товарів (послуг): до 10 000 найменувань, незалежний Масштаб відображення інформації: до 4 років по місяцях, до 6 років по кварталах, далі по роках Масштаб відображення інформації: до 50 років — по місяцях (без обмежень) Податки: введення найменування податку; податкової бази; ставки (зміна по роках); періодичність виплат Податки: додатково — зміна ставки податку по місяцях; вибір податкової бази, що редагується і настроюється; введення формули розрахунку податкової бази, включно з рядками, що редагуються; вільний вибір статті, з якої виплачується податок; незалежне налагодження виплати ПДВ Дисконтна ставка ЦБ: карбованці Дисконтна ставка ЦБ (рефінансування): карбованці, долари. Моделювання початкового стану підприємства — стартовий баланс: активи (кошти на рахунку, рахунки до отримання, запаси готової про¬дукції, запаси комплектуючих, попередньо оплачені витрати, земля, будівлі, обладнання, нематеріальні активи, інвестиції, цінні папери); пасиви (відстрочені податки, рахунки до оплати, кредити, акціонерний капітал, нерозподілений прибуток) Захист проекту від не-санкціонованого досту-пу: відсутній Захист проекту (3 статуси з паролем): дозвіл редагування, дозвіл актуалізації даних, дозвіл тільки перегляду проекту Актуалізація даних: відсутня Актуалізація даних: введення актуальних даних по виплатах податків Розрахунок Кількість режимів роз-рахунку — 1 (повний пе-рерахунок) Кількість режимів розрахунку — 16. Вибір режиму здійснюється користувачем. Формування більш детального звіту за рахунок відкриття спеціальних файлів з додатковими звітними документами Інвестиційний план Етапи: створення етапу з поточним порядковим номером; вилучення ета¬пу; скріплення етапів через процедури формальної логіки (через меню) Етапи: ті самі можливості, що й у Project Expert 4.2 + перенесення етапу в будь-яку позицію. Групування етапів. Побудова вкладеної деревоподібної структури сітьового графіка. Зміна шрифтів (колір, розмір, тип). Скріплення етапів на діаграмі GANTT за допомогою миші. Вибір статусу етапу: % виконання робіт; фактичні витрати; рівень пріоритету етапу Продовження табл. 6.3 Project Expert 4.2 Project Expert 5 Ресурси: фіксовані види ресурсів (5 видів): введення сумарних витрат на ресурс Ресурси: необмежений список видів ресурсів, що редагується. Розрахунок витрат через питому вартість ресурсу Активи: вибір етапів до активу зі списку, що не редагується (1-й тип амор¬тизації активів) Активи: об’єднання згрупованих підетапів в актив, три способи амортизації активів Списання ПДВ: відсутнє Списання ПДВ: 3 типи (лінійне; за залишковою вартістю; за обсягом виробництва) Експорт / Імпорт даних з міжнародним форматом, mpx: обмежений (дати по-чатку / закінчення етапу; вартість) Експорт / Імпорт даних з міжнародним форматом, mpx: повний обмін Календар: 1 місяць 30 днів Календар: реальний календар, що редагується з урахуванням вихідних і святкових днів. Можливість використання кількох календарів (для кількох країн) План збуту Гнучка процедура визна-чення стратегії продажу для кожного з 400 продук-тів Значно розширені можливості введення гнучкої стратегії продажу для необмеженої кількості товарів / послуг Ціноутворення: задається ціна на внутрішньому і зовнішньому ринках; не¬стандартна інфляція по роках; нестандартні податки Ціноутворення: ті самі можливості, що й у Project Expert 4.2 + можливість введення нестандартної інфляції по місяцях; введення нестандартних податків з можливістю виплати з прибутку; можливість введення сезонних змін ціни; можливість введення стрибкоподібних змін ціни Актуалізація даних: відсутня Актуалізація даних: введення актуальних даних про обсяги продажу і ціни товарів План виробництва Формується автоматично залежно від плану збуту Незалежний план обсягу виробництва, що має три статуси: 1) необмежене виробництво 2) рівномірне виробництво 3) обмежений обсяг виробництва (квоти, лімі-ти) Прямі виробничі витра-ти: сумарні витрати обчислюються Прямі виробничі витрати: пряме введення сумарних витрат, прямих виробничих витрат Матеріали і комплек-туючі: введення статей витрат для кожного найменування продукту Матеріали і комплектуючі: вибір статей витрат (назва витрат) для кожного продукту з списку (загального складу); формування складу матеріалів і комплектуючих як страховий запас (%) від обсягу і на кількість робочих днів Закінчення табл. 6.3 Project Expert 4.2 Project Expert 5 Обсяг закупівлі: закупівля один раз у те число, що задається Обсяг закупівлі: закупівля у міру необхідності; закупівля по встановленій мінімальній партії; закупівля один раз у те число місяців, що задається та редагується; графік закупівлі по місяцях Актуалізація даних: відсутня Актуалізація даних: можливість введення фактичних даних по закупівлі матеріалів і комплектуючих і визначення тим самим реального стану складу Персонал Введення даних про ви-трати по статтях Ті самі можливості, що й у Project Expert 4.2 + сезонні зміни вартості персоналу Актуалізація даних: відсутня Актуалізація даних: можливість введення фактичних даних про вартість персоналу Загальні витрати Гнучкі процедури вве-дення даних про загальні витрати Ті самі можливості, що й у Project Expert 4.2 + за виплати нестандартних податків існують можливості виплати з прибутку і віднесення витрат на певний тип активу, сезонних змін вартості загальних витрат Актуалізація даних від-сутня Актуалізація даних: можливість введення фактичних даних по витратах Фінансовий план Гнучкі процедури фор-мування капіталу й об-слуговування кредитів Ті самі можливості, що й у Project Expert 4.2 + можливість вказівки номінальної вартості і кількості акцій, можливість введення даних про привілейовані акції Лізинг — новий модуль, здатний описати фінансування на основі лізингу Можливість віднесення виплат на конкретну статтю витрат у звіті про прибутки і збитки Актуалізація даних: відсутня Актуалізація даних: можливість внесення фактичних даних про виплати Результати У звітах про прибутки / збитки, про рух грошо-вих коштів, баланс, розширені (збільшені, деталізовані) таблиці Генератор звіту з можливістю деталізування результатів по окремих розділах бізнес-плану Актуалізація даних: відсутня Актуалізація даних: можна аналізувати фактичні дані про рух грошових коштів Структурно Project Expert 5 складається з блоків, перелік яких наведено на рис. 6.4: Рис. 6.4. Структура та функціональні можливості Project Expert 5 Кожний із зазначених блоків включає в себе набір функціо-нальних модулів, що містять діалогові засоби, які дозволяють розробникові проекту сформувати імітаційну модель проекту описом бізнес-операцій в інтерактивному режимі (рис. 6.5). Рис. 6.5. Перелік основних блоків Project Expert 5 І. Блок моделювання: 1. Модуль опису макроекономічного середовища: — вибір валюти для розрахунків на внутрішньому і зовніш-ньому ринках, прогноз обмінного курсу; — моделювання податкового режиму; — моделювання сценаріїв інфляції по різних статтях надхо-джень та виплат проекту. 2. Модуль опису компанії, що реалізує проект: — моделювання поточного стану компанії, формування акти-вів та пасивів; — формування переліку продукції або послуг; — моделювання методу бухгалтерського обліку (FIFO, LIFO) 3. Модель формування інвестиційного плану проекту: — сітьовий графік проекту, календарний план робіт, взає-мозв’язки між стадіями проекту; — перелік та обсяг необхідних ресурсів; — витрати та умови оплати ресурсів; — формування активів, що заново створюються. 4. Модуль моделювання операційного плану компанії: — формування плану збуту, опис умов реалізації продукції та послуг, моделювання процесу продаж; — формування плану виробництва, планування обсягу вироб-ництва, умов формування продукції; — моделювання прямих виробничих витрат, включаючи умо-ви придбання та збереження матеріалів, сировини комплектую-чих виробів, а також умов виплат відрядної заробітної плати; — моделювання плану по персоналу, умов оплати праці та використання трудових ресурсів; — формування статей витрат та умов оплати постійних витрат (накладних витрат); — моделювання процесу фінансування проекту, включаючи джерела грошових коштів та умов залучення капіталу; — моделювання процесу використання вільних грошових коштів. ІІ. Блок генерації фінансових документів Блок генерації фінансових документів забезпечує автоматичне формування стандартних фінансових форм, що відповідають між¬народним стандартам бухгалтерського обліку (International Accoun¬ting Standards — IAS). Це такі форми: — прогноз руху грошових коштів (Cash Flow); — звіт про прибутки та збитки; — балансова відомість; — звіт про використання прибутку. Усі перелічені документи формуються відповідно до міжна-родних стандартів бухгалтерського обліку (International Accoun-ting Standards — IAS) і є джерелом вхідних даних для розрахунку основних показників ефективності проекту. ІІІ. Блок аналізу Блок аналізу містить модуль аналізу чутливості проекту, який дозволяє оцінити вплив змін низки основних чинників на фінан-совий результат проекту: 1. Модуль розрахунку стандартних фінансових показників: — фінансових коефіцієнтів (показники ліквідності; платоспро-можності; ділової активності; рентабельності; структури капіта-лу); — показники ефективності інвестицій, дисконтовані критерії Cash Flow (РВ — період окупності; РІ — індекс прибутковості; NPV — чиста зведена величина доходу; IRR — внутрішня норма рентабельності). 2. Модуль аналізу чутливості, що забезпечує можливість ана-лізу чутливості проекту залежно від змін різних параметрів, що варіюються. 3. Модуль аналізу ефективності проекту стосовно до різних учасників (банків, інвесторів та ін.) 4. Модуль варіантного аналізу, що забезпечує можливості зі-ставлення показників ефективності різних варіантів реалізації проектів або групи різних проектів (доступ до даного модуля можливий лише у версії Professional). IV. Блок групування проектів Дозволяє сформувати сумарний фінансовий план групи про-ектів (сумарний звіт про рух грошових коштів) та розрахува- ти основні показники ефективності інвестицій для групи про- ектів. V. Блок контролю процесу реалізації проекту (рис. 6.6) Процедури актуалізації фактичних даних, отриманих у ре-зультаті реалізації проекту, доступні тільки у версії Professional. а) Актуалізація даних Однією з найважливіших систем є актуалізація фактичних да-них про процес реалізації проектів. Для цього в системі повинні бути передбачені спеціальні інструментальні засоби на робочому місці куратора проекту (особи, що контролює проект). б) Контроль неузгоджень За допомогою порівняння початкового плану з актуальними даними формується звіт про неузгодження плану з фактичним станом проекту. Серед параметрів, що контролюються, слід бра-ти до уваги такі. а) У передвиробничий (інвестиційний) період проекту: — відповідність запланованого та фактично виконаного ка-лендарного плану робіт (дотримання термінів робіт); — відповідність запланованого та фактично виконаного обся-гу робіт; — відповідність запланованих та фактичних витрат на вико-нання робіт. б) У період з моменту початку виробництва і збуту продукції та послуг: — відповідність запланованого та фактичного обсягу прода-жу; — відповідність запланованих та фактичних непрямих вироб-ничих витрат; — відповідність запланованих та фактичних постійних витрат; — відповідність запланованої та фактично отриманої суми при¬бутку; — відповідність графіка залучення акціонерного капіталу за-планованому раніше; — відповідність графіка отримання та погашення займів ра-ніше запланованому; — відповідність запланованих та фактично виплачених диві-дендів; — відповідність суми запланованих податкових надходжень фактичним. Процедура актуалізації даних має здійснюватися куратором проекту не рідше одного разу на місяць, відповідно крок плану-вання в системі повинен відповідати крокові контролю і не може тривати більше ніж 1 місяць. Рис. 6.6. Контроль та управління проектами VI. Блок-інтегратор Блок-інтегратор доступний тільки у версії «Holding». У блоці інтеграції передбачені такі модулі: 1. Модуль формування моделі холдінга (система загальних витрат, оподаткування, залучення капіталу). 2. Модуль підсумовування проектів холдінга. 3. Модуль розрахунку показників ефективності холдінга. 4. Модуль аналізу результатів діяльності холдінга. 5. Модуль багатокритеріальної експертизи проектів. 6. Модуль ранжування проектів для визначення пріоритетів фінансування. VII. Генератор звітів 1. Модуль редагування та генерації бізнес-плану дозволяє по-будувати бездоганно оформлений документ, що містить необхідні текстові блоки, таблиці та графіки. 2. Модуль формування звіту про неузгодженість планового та фактичного стану проекту дозволяє керуючому проектом регуляр¬но формувати звіт та здійснювати порівняльний аналіз, результати якого є основою для прийняття рішень у процесі управління проектом. 3. Модуль побудови графіків та діаграм дозволяє в інтеракти-вному режимі подавати дані та результати проекту в графічному вигляді, причому в процесі побудови графіків можуть здійснюва-тися необхідні розрахунки. 4. Модуль друку дозволяє вивести на принтер та передати в тек¬стовий редактор MS WinWord звітні документи, в яких наведено як вхідні дані проекту, так і результати моделювання та аналізу. При цьому звіт може бути сформований російською та кіль-кома європейськими мовами. ? Послідовність дій Робота з Project Expert 5 передбачає такі основні кроки: 1. Побудова моделі. 2. Визначення потреби у фінансуванні. 3. Розробка стратегії фінансування. 4. Аналіз фінансових результатів. 5. Формування та друкування звіту. 6. Введення та аналіз даних про поточний стан проекту в про-цесі його реалізації. 1) Побудова моделі Процес побудови моделі — найбільш трудомісткий і вимагає значної підготовчої роботи із збору та аналізу вхідних даних. Різні модулі Project Expert є незалежними та доступними користувачеві практично у будь-якій послідовності. Однак відсутність деяких необхідних вхідних даних може блокувати доступ до інших модулів програми. Незалежно від того, чи розробляється детальний фінансовий план, чи виконується попередній експрес-аналіз проекту, слід передусім ввести початкові дані: — дата початку та тривалість проекту; — перелік продуктів та/або послуг, виробництво та збут яких здійснюватиметься в межах проекту; — валюта розрахунку або дві валюти розрахунку для платіжних операцій на внутрішньому та зовнішньому ринках, а також їхній обмінний курс та прогноз його змін; — перелік, ставки та умови виплати основних податків; — для діючого підприємства також слід описати стан ба-лансу, включаючи структуру та склад активів, що є в наявності, зобов’язань та капіталу підприємства на дату початку проекту. Наступним етапом процесу побудови моделі є опис плану розвитку підприємства (проекту). Для цього необхідно ввести такі вхідні дані: — інвестиційний план, включаючи календарний план робіт з обов’язковим зазначенням витрат та ресурсів, що використо-вуються; — операційний план, включаючи стратегію збуту продук¬ції чи послуг, план виробництва, план персоналу, а також виробничі та накладні витрати. 2) Визначення потреб у фінансуванні Для визначення потреб у фінансуванні слід здійснити попере-д¬ній розрахунок проекту, в результаті якого визначається ефективність проекту без урахування вартості капіталу, а також обсяг грошових коштів, необхідних та достатніх для покриття дефіциту капіталу в кожний розрахунковий період часу з кроком в один місяць. 3) Розробка стратегії фінансування підприємства Після визначення потреби в фінансуванні розробляється план фінансування. Користувач має можливість описати два способи фінансування: — за допомогою залучення акціонерного капіталу; — шляхом залучення позичених грошових коштів. Під час розробки стратегії фінансування проекту користувач має змогу промоделювати обсяг та періодичність дивідендів, що виплачуються, а також стратегію використання вільних грошових коштів (наприклад, розміщення грошових коштів на депозит у комерційному банку чи придбання акцій сторонніх підприємств). 4) Аналіз ефективності проекту У процесі розрахунків Project Expert автоматично генерує стандартні звітні бухгалтерські документи: — звіт про прибутки та збитки; — бухгалтерський баланс; — звіти про рух грошових коштів; — звіт про використання прибутку. На основі даних звітних бухгалтерських документів розрахо-вуються основні показники ефективності та фінансові коефіцієн-ти. Користувач може розробити кілька варіантів проектів відпо-відно до різних сценаріїв їх реалізації. Після визначення найімо-вірнішого сценарію проекту його беруть за базовий. На основі базового варіанта проекту здійснюється аналіз чутливості й ви-значаються критичні значення найважливіших чинників, що впливають на фінансовий результат проекту. 5) Формування звіту Після завершення аналізу проекту формуються звіти. В Pro-ject Expert передбачений спеціальний генератор звіту, що забез-печує компонування та редагування звіту за бажанням користу-вача. У звіт можуть бути вбудовані не тільки стандартні графіки та таблиці, а й таблиці та графіки, побудовані користувачем за допомогою спеціального редактора. Крім цього, користувач має можливість вбудовувати у звіт коментарі у вигляді тексту. У кінці 1999 р. було випущено нову версію продукту — Project Expert 6.1. До числа основних новацій, характерних для цієї версії, слід віднести: — можливість використання як валюти для розрахунків euro; — можливість реалізації зв’язку через INTERNET (генерація звітів у НTML-форматі); — можливість задавати витрати не лише у формі конкретних сум, а й за допомогою формул; — можливість аналізу проектів за методом Monte Carlo; — можливість аналізу беззбитковості; — можливість тривимірного подання різноманітних графіків; — можливість проведення аналізу чутливості проектів (What-If-аналізу). 6.6. ПРОГРАМНІ ПРОДУКТИ ДЛЯ СТРАТЕГІЧНОЇ ОЦІНКИ БІЗНЕСУ НА ПІДПРИЄМСТВАХ 6.6.1. Продукт ФАРОС Навігація в бізнесі — це інформація про те, як уникнути нега-тивних тенденцій у розвитку підприємства і визначити економіч-ні можливості. Такого роду інформація повинна давати відповіді на запитан-ня: — чи заробляє підприємство досить грошей, щоб окупати свої витрати; — чи є позитивним рух готівки; — як розвивається виробництво; — яка продукція приносить найбільшу додану вартість; — які продажі формують найбільший прибуток; — якою є потенційна конкурентоспроможність фірми; — яким є рівень витрат на виробництво, прибуток за поточний період порівняно з тим самим періодом за минулий рік. Швидко отримати відповідь на ці запитання допоможе про-грамний продукт ФАРОС. ФАРОС — це програма для менеджерів, яка допомагає пере-творювати фінансові дані фірми в цілісний набір індикаторів для оцінки ефективності виробництва або бізнесу. Основним інстру-ментом програми є набір із шести основних індикаторів, що лег-ко інтерпретуються (рис. 6.7). Рис. 6.7. Перелік основних індикаторів продукту ФАРОС Це такі індикатори: витрати, ефективність, якість, конку-рентоспроможність, віддача від продукції, віддача від клієн-тів. Користувач може завжди оцінити картину діяльності вироб-ництва одним поглядом, побачивши маяки ФАРОСа, що горять зеленим вогнем («усе в порядку»), жовтим («можуть виникнути деякі проблеми») або червоним (один або декілька аспектів роботи підприємства проблематичні). Розгляньмо детальніше зазначені індикатори. 1) Витрати Під час аналізу витрат визначається та діяльність, що збіль-шує витрати на виробництво без збільшення прибутку. Типовим складовим зростання витрат є, наприклад, зміни й ускладнення в дизайні продукції, що не можуть бути скомпенсовані більш висо-кою продажною ціною. Достатньо стандартизоване виробництво великих обсягів продукції, звичайно, не має таких витрат. Однак за великих обсягів виробництва часто виникає потреба у випуску різних варіацій або модифікацій продукції одного типу, що за-безпечує більше замовлень і закупівель і веде до додаткових ви-трат. Інакше кажучи, чим більше додаткових операцій, тим вищі витрати. Сьогодні, коли в стратегіях економічного розвитку особливо-го значення набуває швидкість реакції на потреби і вимоги поку-пців, фірми повинні брати до уваги можливості значного зрос-тання складових витрат. Рис. 6.8. Введення даних по витратах у ФАРОСі Введення даних по витратах — це перший крок роботи з ФА-РОСом (рис. 6.8). Спочатку вводяться планові показники, по-тім — за результатами діяльності — фактичні. Важливо зауважи-ти, що весь процес контролю показників у програмі здійснюється через порівняння із загальним планом виробництва. 2) Ефективність є індикатором спроможності підприємства одержувати прибуток у виробничій діяльності і має пряме відно-шення до досягнення поставлених цілей, тобто до реалізації стратегій розвитку підприємства. Ефективність зазвичай характеризують такі показники, як використання робочого часу (запланованого й фактичного), визначення витрат на одиницю продукції (заплановані і фактичні), скарги покупців і повернення продукції, задоволення покупців тощо. Таким чином, основною функцією виміру ефективності виробництва є порівняння її запланованих і фактичних показників. Це означає, що планування ефективності виробництва має фундаментальне значення для економічного середовища. 3) Якість Продукція підприємства може бути не прийнята споживачем із багатьох причин. З погляду вимог до якості, усі дефекти повинні сприйматися однаково незалежно від того, чи незначним є цей дефект, чи це дефект, що призводить до заміни товару в цілому. Основною ме-тою будь-якого підприємства повинен бути нульовий рівень де-фектів, і менеджерам треба активно боротися за досягнення цієї мети. Якість виробництва, таким чином, є дійовою сферою для планування і програми заохочення виробничого персоналу до постійного поліпшення значення цього індикатора. Його розмір являє собою відношення числа забракованої продукції до загаль-ної кількості продукції, виготовленої протягом того ж часу. 4) Конкурентоспроможність Фірма може вважатися конкурентоспроможною, якщо вона в змозі продавати свою продукцію за ринковою ціною з прибут-ком. Конкурентоспроможність або конкурентна перевага означає, що фірма має перевагу в якості виробництва, у маркетингу і досягає такого рівня, за якого покупці готові платити за надану їм якість. Якщо відносини між фірмою і покупцями стабільні, то рівень прибутку відповідає оптимальній доданій вартості. Неконкурентоспроможність вказує на нестабільність у відносинах фірми і покупців, бо вони, покупці, не будуть впевнені у тому, що ціна продукції відповідає її доданій вартості. Бути конкурентоспроможним означає забезпечувати покупця продукцією або сервісом тієї якості, яка відповідає стандартам покупців, а не стандартам виробника. Однак це також означає, що прибуток виробника є настільки задовільним, що підприємст-во може собі дозволити виробництво на даному рівні якості. Як-що обидві ці умови виконані, то відношення між покупцем і ви-робником є досить стабільними, що і забезпечує належний рівень конкурентоспроможності. 5) Віддача від реалізації різних видів продукції Важливим для кожного менеджера є питання про те, яка про-дукція з виробленої найбільшою мірою сприяє розвиткові під-приємства. Внесок даного продукту в загальний прибуток під-приємства визначається тим, що всі складові витрат, взяті за перемінні, переважно витрати на матеріали і робочу силу, скла-даються по всіх стадіях виробничого процесу в загальну суму витрат на продукт. Ця сума відраховується від загальної ціни реалізації, з тим щоб одержати загальний внесок даного продукту в покриття виробничих витрат. Цей принцип оцінки фінансової ефективності завжди використовувався в аналізі виробництва. Він використовується й у ФАРОСі. У кожному модулі, що безпосередньо стосується виробництва різних видів продукції, завжди можна провести аналіз даних у графічному поданні і швидко визначити ті п’ять головних продуктів, що найбільшою мірою сприяють ефективності конкретної фірми. 6) Віддача покупців Віддача від клієнтів обчислюється на основі середнього при-бутку на кожного клієнта, який ФАРОС вміщує в спеціальній ді-аграмі. Програма вибирає п’ять найбільш «прибуткових» покуп-ців відповідно до принесеного ними прибутку, який обчислю-ється в середньому за останні дванадцять місяців або відповідно за останній період. Відповідні дані подаються в наочній діаграмі, з якої можна також одержати оцінку числа активних клієнтів що-до їхнього загального числа. 6.6.2. Програмний продукт BEST BEST, скорочено від «Business Environment Strategic Toolkit» (Стратегічний інструмент бізнесу), — це комп’ютерна програма для підтримки стратегічних рішень менеджерів, орієнтована на використання в умовах ринкової економіки і концепції прибутку. У програмі використовується набір оригінальних економічних індикаторів для виміру ефективності виробництва. Програма дозволяє перетворити стратегічні цілі конкретної фірми в набір послідовних заходів і кроків для забезпечення ефективності бізнесу (рис. 6.9). Рис. 6.9. Основне діалогове вікно програми BEST У програмі BEST певним чином зведені разом різні кількісні дані, як-от: додана вартість, виробничі витрати, продажна ціна і прибуток, із такими якісними параметрами, як ступінь задо- волення споживачів, витрати на забезпечення якості продукції і навколишнього середовища тощо. Особливо привабливими для менеджерів є такі показники, як, наприклад, конкурентоспро- можність, ступінь задоволення споживачів і віддача від продукції різних типів, що важко або неможливо одержати при викорис-танні традиційних методів. Під час застосування BEST вводяться в дію дані, які є до-ступними на будь-якому підприємстві, але яких часто не зби-рають і не аналізують. Використання програми дає користувачеві можливість зрозуміти, як розвивати високоефективне ви-робництво, як правильно ставити кінцеві цілі, вимірювати ви-робництво і управляти ним, вирішувати проблеми спадкоємності рішень. BEST автоматично розраховує розміри індикаторів і подає ре-зультати в реальному часі в різних графічних формах, що виби-раються користувачем залежно від його уподобань. ІНДИКАТОРИ BEST Основою BEST є набір із 25 індикаторів, згрупованих щодо таких форм діяльності підприємств: 1. Ефективність виробництва або бізнесу. 2. Маркетинг і збут. 3. Ефективність використання виробничого устаткування. 4. Контроль витрат. 5. Фінансова ефективність. 6. Якість продукції. 7. Конкурентоспроможність. 1) ЕФЕКТИВНІСТЬ БІЗНЕСУ Чотири індикатори сфокусовані на ефективності бізнесу. Пер-ший індикатор — «Уніфікований індикатор стану загальної дія-ль¬ності підприємства» — є зваженою комбінацією п’ятьох індексів, обумовлених арифметичними співвідношеннями. Рис. 6.10. Уніфікований індикатор стану загальної діяльності підприємства в BEST 1. Уніфікований індикатор стану загальної діяльності під-приємства (Business Performance Indicator) містить у собі п’ять основних індикаторів: динаміки поточних продажів щодо плану продажів на період (Year-to-date Index-YDX), якості обслугову-вання замовників (Customer Service Index — CSX), рівня поточ-них замовлень (Customer Order Index — COX), рівня якості про-дукції (Production Quality Index — PQX) і рівня динаміки складсь-ких запасів (Storage Level Index — SLX). Уніфікований індикатор стану загальної діяльності підприємства (ВРІ) — це головний ін-дикатор, що належить до короткострокової діяльності підприєм-ства (рис. 6.10). 1. Індикатор рівня виробничої діяльності (Total Enterprise Performance — TEP) є відношенням загального рівня надходжень від збуту до загальних витрат на виробництво плюс витрати на фінансування. Цей індикатор показує співвідношення між внес-ком у виробництво і віддачею від реалізації продукції. 2. Індикатор прибутковості підприємства (Profit Margin Indi¬cator — PFM) показує відношення прибутку до загального обсягу збуту, відображаючи відносний рівень прибутковості виробництва. 3. Індикатор рівня продажів за період (Sales Productivity Indicator — SLP) показує, наскільки рівень збуту відстає від рівня виробництва. Цей індикатор особливо цікавий для підприємств-виробників, що безпосередньо торгівлею не займаються. BPI і TEP є основними індикаторами, без яких скласти повне уявлення про виробництво в цілому неможливо. 2) ЕФЕКТИВНІСТЬ ВИКОРИСТАННЯ РЕСУРСІВ Два головних визначники динаміки зміни ефективності — зростання фонду заробітної плати і використання поточних акти-вів у виробництві. 1. Індикатор зростання фонду заробітної плати (Labor Pro-ductivity Indicator — LRP) показує, яка кількість додаткової вар-тості виробляється на одну одиницю робочої сили. Важливіше вимірювати випуск продукції щодо виробничої доданої вартості, ніж щодо кількості виробленої продукції, оскільки перший пока-зник відбиває ринкову значущість виробництва. 2. Індикатор ефективного використання поточних активів виробничого підприємства (Capital Productivity Indicator — CLP) показує відношення між вкладеним у виробництво капіта-лом (фінансовий капітал та інше майно) і виробництвом доданої вартості. 3. Індикатор ефективного використання фонду заробітної плати (Salary Productivity Indicator — SYP) показує співвідно-шення між доданою вартістю і загальними витратами на оклади. SYP, на відміну від LRP, містить у собі адміністративні витрати. Одна з корисних функцій цього індикатора — допомогти мене-джеру усвідомити внесок адміністративних функцій у генерацію прибутку. 4. Індикатор ефективного використання календарно-го/пла¬нового фонду часу (Production Time Utilization Indicator) використовується для порівняння фактичного продуктивного часу з оптимальним або запланованим часом. 5. Індикатор енергозалежності підприємства (Energy Pro-ductivity Indicator — EYP) показує співвідношення між доданою вартістю і витратами на енергію. 3) МАРКЕТИНГ І ЗБУТ 1. Індикатор динаміки поточних продажів щодо плану продажів на період (Year-to-date Index — YDX) порівнює екст-рапольовану фактичну кількість прибутку на визначений момент з очікуваним рівнем збуту за рік. 2. Індикатор планованого обсягу продажів на майбутні періоди (Year-End-Outlook Indicator — YEO) обчислюється ме-тодом аналізу регресії. Він прогнозує рівень збуту за рік на осно-ві загальної тенденції за останні дванадцять місяців. 3. Індикатор рівня поточних замовлень (Customer Order Index — COX). У BEST порівнюються два співвідношення: спів-відношення між новими замовленнями за останній місяць і сере-дньою кількістю місячних замовлень за останніх дванадцять мі-сяців і співвідношення збуту за останній місяць до середньої кількості збуту за останніх дванадцять місяців. Цей індикатор попереджує необхідність в особливих діях щодо збуту продукції. 4. Індикатор планування поточної реалізації продукції (Total Sales Performance Indicator — TSP) порівнює загальну кіль-кість збуту з очікуваною кількістю збуту за даний місяць. 4) КОНТРОЛЬ ВИТРАТ 1. Індикатор динаміки поточних продажів (Total Cost Pro-ductivity Indicator — TCP) надає менеджеру інформацію про те, наскільки фактичні витрати, віднесені на виробництво за фактом реалізації продукції, відповідають запланованим. 2. Індикатор динаміки складських запасів по періодах (Sto¬rage Level Index — SLX) попереджає менеджера про критичний стан накопичення складських запасів. 3. Індикатор поточної ліквідності валюти (Convertible Cur-rency Utilisation Indicator — CCU) показує, чи є невідповідність між заробленою конвертованою валютою і витратами в конвер-тованій валюті. 4. Індикатор рівня переробки сировини і матеріалів (Refi-nement Grade Indicator — RMG). Витрати на опрацювання — це витрати на переробку сирого матеріалу в кінцеву продукцію. Останні включають в себе фонд оплати праці виробничого пер-соналу, витрати на фінансування виробництва — усі витрати, крім витрат на покупні матеріали і комплектуючі. Цей індикатор також показує, наскільки врахування варіантів закупівлі частини матеріалів і вузлів поза власним виробництвом є цілком розум-ним економічним рішенням. 5) ФІНАНСОВА ЕФЕКТИВНІСТЬ 1. Прибуток на інвестиції (Return on Investment Indicator — ROI) — класичний індикатор, що зазвичай трактується як рента-бельність інвестицій. Індикатор показує ефективність викорис-тання вкладеного капіталу у виробництво. 2. Індикатор ефективності капіталу (Capital Utilisation Indi-cator — CPU) характеризує загальне управління оборотним капі-талом, метою якого є таке використання ліквідних активів, яке могло б принести максимально високий прибуток. 6) ЗАБЕЗПЕЧЕННЯ ЯКОСТІ Ці індикатори є фундаментальними показниками менеджмен-ту із забезпечення якості продукції. 1. Індикатор якості продукції (Production Quality Index — PQX) показує кількість браку стосовно до загального обсягу ви-робленої продукції за даний період. 2. Індикатор якості обслуговування замовників (Customer Service Index — CSX) показує кількість постачань із браком що-до загальної кількості постачань. 3. Індикатор ефективності поточних профілактик уста-ткування (Maintenance Productivity Indicator — MNP) показує відношення запланованого ремонту до непередбаченого ре- монту. 7) КОНКУРЕНТОСПРОМОЖНІСТЬ Для конкурентоспроможності важливими є два чинники: якість і рентабельність. Це означає: щоб бути конкурентоспроможною, продукція повинна відповідати очікуванню споживачів або перевершувати ці очікування за ціни, що дає прибуток. 1. Індикатор конкурентоспроможності продукції (Competi-tive Strength Indicator — CPS) показує відношення між прибутком і доданою вартістю. 2. Індикатор рівня доданої вартості (Added Value Grade Indicator — AVG). Додана вартість — це істотний параметр, оскільки використовується для визначення того, яка частина від ринкової ціни продукції була вироблена на підприємстві. 3. Індикатор поточного курсу конвертації (ліквідності) ва-люти підприємства (Convertible Currency Exchange Indicator — CCE) використовується для того, щоб оцінити баланс між надхо-дженнями в конвертованій валюті від експорту та її витрат у разі імпорту матеріалу, запасних частин і устаткування. ІНСТРУМЕНТИ МОДЕЛЮВАННЯ BEST містить у собі три інструменти моделювання: оцінку прибутковості продукції, моделювання ціноутворення на про¬дукцію й оцінку інвестицій. Користувач може вводити і моделювати різні рішення з метою визначення оптимальних стратегічних варіантів. Модуль оцінки інвестицій дає три можливі моделі капіталовкладень для використання: в короткострокових вкладеннях у нове обладнання або інші складові виробництва. Система дає рекомендації щодо найпридатнішої моделі залеж¬но від характеру інвестиційної ситуації (рис. 6.11). Ідея модуля Price Setting Simulation проста: «Спільний внесок у прибуток від різних типів продукції повинен перевищувати усі витрати і давати прибуток». Це один із модулів програми, де менеджер повинен варіювати різні показники виробництва по кожному типу продукції і аналізувати ціни, що утворюються, без ризику одержати реальні збитки. Програма надає можливість одержати ціну, «що рекомендується», залежно від ситуації на підприємстві. Отримані результати після додаткового підтвердження можуть бути введені в новий робочий план підприємства. За незадовільних результатів завжди є можливість відновити вихідні обсяги виробництва і ціни. Всі дані в програмі подаються за бажанням користувача в національній валюті або американських доларах. Рис. 6.11. Формування рекомендацій залежно від інвестиційної ситуації в програмі BEST Оцінка прибутковості продукції дозволяє оцінити пріорите-т¬ність виробництва різних типів продукції відповідно до п’ятьох різних ситуацій у виробництві. Моделювання може здійснюватися незалежно від фактичного плану і даних за результатами діяльності підприємства. Однак користувач має право ввести найбільш успішні результати моде-лювання як дані нового плану, послуговуючись кнопкою «Внести до плану». Інструменти моделювання, використовувані в BEST, постійно удосконалюються, заплановані нові модулі, що включа-тимуться в наступні версії програми. 6.6.3. Програмний продукт FIT FIT (Financial Improvement Toolkit) — це комп’ютерна про-грама, яка допомагає у прийнятті рішень і яка базується на суча-сних концепціях бізнесу. Ця програма пропонує для аналізу 23 індикатори діяльності, як-от: додана вартість, інвестиції, маркетинг, продажі на одного працюючого тощо. Розрахунок необхідних індикаторів провади-ться на основі даних про прибутки, збитки тощо. При цьому ви-користовуються наявні бухгалтерські дані за повний фінансовий рік, а також витрати на маркетинг, науково-дослідні та дослідно-конструкторські витрати відносно даних SBUs (стратегічних одиниць бізнесу) (рис. 6.12). Рис. 6.12. Стратегічні індикатори бізнесу в програмі FIT СТРАТЕГІЧНІ ІНДИКАТОРИ БІЗНЕСУ Нижче розглядаються 23 стратегічних індикатори, що викори-стовуються в FIT: 1. NET SALES INDEX — обсяг продажів продукції, де сума продажів першого року (без податків) береться за 100% і з нею порівнюються відповідні суми продажів наступних років (у %). Індекс відбиває тенденцію розвитку продажів. 2. NET SALES PER EMPLOYEE — обсяг продажів на спів-робітника — показує середню суму продажів, що припадає на одного працюючого за кожний рік у грошових одиницях (або ти-сячах одиниць). 3. ADDED VALUE — додаткова вартість — це чиста сума продажів мінус витрати на придбані товари або послуги, необ-хідні для отримання чистої суми продажів. 4. ADDED VALUE IN % OF SALES — додаткова вартість у % усієї суми витрат — показує, яка частина від суми чистих продажів зроблена «власними силами», а отже, є критерієм ви-значення ступеня вертикальної інтеграції. 5. ADDED VALUE PER EMPLOYEE — додаткова вартість на одного працівника — це індикатор продуктивності праці. Він може бути порівняний, наприклад, із середньою сумою виплачуваної платні, що припадає на одного працюючого, або із сумою інвестицій, що припадає на одного працюючого. 6. COST OF GOODS IN % OF SALES — вартість товарів у % від продажів — використовується для аналізу основних ком-понентів витрат, що утворять суму продажів, і тенденцій змін їх у часі. 7. INVESTMENT — інвестиції — це сукупний капітал (ос-новні засоби + оборотний капітал), що необхідний для одержання чистої суми продажів; розраховуються як сукупні основні засоби мінус сукупні зобов’язання. 8. NET FIXED CAPITAL IN % OF SALES — чистий капітал у % від продажів — показує, наскільки ефективно використо-вуються основні засоби для одержання всього обсягу продажів; ступінь віддачі капіталу стосовно суми продажів. 9. WORKING CAPITAL — робочий капітал — ефективність використання капіталу, це сукупні оборотні кошти мінус сукупні короткострокові зобов’язання. 10. WORKING CAPITAL IN % OF SALES — робочий капітал у % від продажів — інша міра рівня капіталовіддачі стосовно до суми продажів, крім основних засобів у % від суми продажів. 11. INVESTMENT INTENSITY IN % OF ADDED VALUE — віддача інвестицій у % від додаткової вартості — визначається як капіталовкладення, поділені на додану вартість. Це дуже важливий показник, що визначає відношення існуючої додаткової вартості за рік до необхідних капіталовкладень. 12. INVESTMENT PER EMPLOYEE — інвестиції на одиницю персоналу — відбиває ступінь автоматизації у компанії. Чим більше капіталовкладень припадає на одного працюючого, тим більшою має бути його віддача. 13. STOCKS IN % SALES — частка вартості продукції на складі до загального обсягу продажів — використовується для виявлення можливих проблем в оборотному капіталі (або інтен-сивність обороту капіталовкладень). Сутність індикатора — під-вищення потенціалу операцій постачання, виробництва під по-стачання чи замовлення або координації виробничих процесів і постачань клієнтам. 14. RAW MATERIALS IN % OF SALES — обсяг сировини стосовно до обсягу продажів — використовується для виявлен-ня можливих проблем в оборотному капіталі (або інтенсивності капіталовкладень). 15. WORK IN PROGRESS IN % OF SALES — співвідношення між виробничим капіталом і обсягом продажів. Використо-вується для виявлення можливих проблем у оборотному капіталі (або інтенсивності капіталовкладень). 16. FINISHED GOODS IN % OF SALES — завершене вироб-ництво щодо загального обсягу продажів — використовується для виявлення можливих проблем у оборотному капіталі (або ін-тенсивності капіталовкладень). 17. MARKETING IN % OF SALES — витрати на маркетинг до загального обсягу продажів — використовується для аналізу основних компонентів витрат, що утворять суму продажів, і тен-денцій їхніх змін у часі. 18. ADMINISTRATION IN % OF SALES — адміністративні витрати до загального обсягу продажів — використовується для аналізу основних компонентів витрат, що утворюють суму продажів, і тенденцій змін їх у часі. 19. TRADEDEBTORS IN % OF SALES — обсяг капіталу бо-ржників за платежами до загального обсягу продажів — ви-користовується для виявлення можливих проблем у оборотному капіталі (або інтенсивності капіталовкладень). 20. AVERAGE SALARY PER EMPLOYEE — середня заробі-тна плата на одного співробітника, тобто загальна сума випла-чуваної за рік зарплати, поділена на середню кількість працюю-чих за рік. 21. NUMBER OF EMPLOYEES — число співробітників — показує середню кількість за весь рік, а не тільки на кінець року. 22. ROI (RETURN ON INVESTMENT) — повернення інвес-тицій — розраховується як прибуток до відрахування податку плюс відсотки, потім ділиться на капіталовкладення. Цей показ-ник треба порівнювати з вартістю капіталу у валюті, що викорис-товується у розрахунках. 23. ROE (RETURN ON EQUITY) — повернення акціонерно-го капіталу — це прибуток до відрахування податку, віднесений до обсягу капіталу акціонерів. КОМП’ЮТЕРНІ СИСТЕМИ ПІДТРИМКИ ПРИЙНЯТТЯ РІШЕНЬ ТА ВИКОРИСТАННЯ ЇХ НА ПІДПРИЄМСТВАХ 7.1. ЕВОЛЮЦІЯ ІНФОРМАЦІЙНИХ СИСТЕМ Розвиток комп’ютерної інформаційної технології нерозривно пов’язаний з розвитком інформаційних систем, які в економіці використовуються для автоматизованого (людино-машинного) розв’язання економічних задач. Для розв’язання будь-якої задачі за допомогою комп’ютера необхідно створити інформаційне (забезпечити розрахунки необхідними даними) і математичне (створити математичну модель розв’язання задачі, за якою складається програма для ЕОМ) забезпечення. На рис. 7.1 показана спрощена схема автоматизованого розв’язання економічної задачі (наприклад, розрахунок оптимальної виробничої програми). Необхідна для розв’язання інформація може надходити безпосередньо (вхідна інформація) або через систему інформаційного забезпечення, яка може поповнюватися і за рахунок нової інформації. Рис. 7.1. Схема автоматизованого розв’язання економічної задачі Математичні моделі й алгоритми можуть бути подані у вигляді, який передбачає етап програмування, і в формі, придатній для прямого використання при розв’язанні задачі. Вихідна інформація може бути подана в різних варіантах. Визначальною особливістю інформаційної системи є те, що вона забезпечує користувачів інформацією із декількох організацій. Серед інших особливостей, які зумовлюють значні труднощі в розробці та побудові інформаційних систем організаційного типу, можна назвати такі: — середовище, в якому працюють ці системи, досить складне, не¬повністю визначене і важко моделюється; — системи мають складне сполучення із середовищем, що включає багато вхідних і вихідних ланцюгів; — функціональні взаємозв’язки вхідних і вихідних сигналів складні в структурному, а інколи і в алгоритмічному відношенні; — вони зазвичай містять у собі великі й складні БД (в перспе-к¬тиві — бази знань); — організації-замовники завжди нагально потребують постійної й тривалої роботоздатності цих систем, причому строки початкового введення їх в експлуатацію і наступних модифікацій установлюються досить стислими. У системах опрацювання даних (СОД) головними її компонентами є дані та обчислення. Більшість інформаційних систем управління інформаційними ресурсами в організаціях вміщують і багато інших компонент, як-от: вимоги, запити, тригери і звіти. І всі вони, зок¬рема, містять великі описи свого власного змісту в тій чи іншій формі. Ці описи необхідні для інтерпретації і корект¬ного використання наданої інформації (коли в системі відсутній повний опис, то мається на увазі, що користувачі отримують його із іншого джерела). Для головних компонентів інформації (даних і обчислень) ва-ж¬ливе значення має така характеристика, як їх надмірність. Визначення надмірності суттєво залежить від одиниці інформації. Коли одиниця вибрана, то надмірність — це просто дублювання однієї й тієї самої одиниці в системі. Суттєвим рішенням при виборі одиниці інформації є вибір її розміру. Вибір занадто малої одиниці приводить не тільки до високого рівня незалежності бло¬ків інформації, але й до збільшення накладних витрат та затрат на підтримку; при прийнятті крупної одиниці буде неможливо уникнути численного дублювання підблоків інформації. За час виникнення і розвитку інформаційних систем організаційного типу структура і надмірність даних і обчислень значно змінювалися, чим визначались покоління цих систем. На рис. 7.2 подана схема розвитку інформаційних систем, де показані особливості розв’язання функціональних задач залежно від характеру інформаційного і математичного забезпечення. Номер етапу Період, роки Назва етапу в Україні Назва етапу в зарубіжній літературі Схема розв’язування задачі Перший 1963—1972 Створення АСУ (позадачний підхід) Системи опрацювання даних (СОД) Дані Дані Задача 1 Задача N Моделі Моделі Другий 1972—1985 Створення і розвиток АСУ згідно з концепцією баз даних Управлінські інформаційні системи База даних Задача 1 Задачa N Моделі Моделі Третій Початок 1985 (триває досі) Системи підтримки прийняття рішень (СППР) База даних Задача 1 Задачa N База моделей Рис. 7.2. Схема еволюції інформаційних систем В інформаційних системах першого покоління, які в зарубіжній літературі відомі під назвою «Системи опрацювання даних» («Електронне опрацювання даних», «Система електронного опра¬цювання даних»), вітчизняній — «Автоматизовані системи управління (АСУ) — позадачний підхід»: — для кожної задачі окремо готувалися дані й створювалася математична модель. Такий підхід зумовлював інформаційну надмірність (одні й ті самі дані могли використовуватись для розв’язання різних задач) і математичну надмірність (моделі розв’язання різних задач мали загальні блоки). Типовими прикладами систем опрацювання даних є системи: керування запасами, виписування рахунків, нараху-вання зарплати. Системи опрацювання даних були вузько прикладними й орієнтованими на автоматизацію робіт з паперами за рахунок ком¬п’ютеризації великих масивів і потоків даних на операційному рівні. Розпізнавальною ознакою цих систем є ефективне опрацювання запитів, використання інтегрованих файлів для пов’язуван¬ня між собою задач і генерування зведених звітів для керівництва. Оскільки кожна система була націлена на конкретне застосування, то опис своїх функцій (зазвичай у формі надрукованих керівництв (інструкцій) до процедур або у вигляді стандартів) був поданий мінімальним і призначений для спеціаліста у цій предметній галузі. Крім того, передбачалося, що користувачі мають значний досвід як у прикладній галузі, так і в роботі із системами, які обслуговують це застосування. Інформаційні системи другого покоління відомі під назвою «управлінські (адміністративні) інформаційні системи» — Mana-gement Infоrmation System (у нашій літературі використовувався термін «АСУ — концепція баз даних»). Основною функцією таких систем є забезпечення керівництва інформацією. Типову управ¬лінську інформаційну систему характеризує структурований потік інформації, інтеграція задач опрацювання даних, генерування запитів і звітів. В управлінських інформаційних системах (УІС) вже були визнані переваги колективного користування даними, а також відзначено, що в одній організації багато прикладних програм використовують одні й ті самі робочі дані і має місце дублювання робіт у процесі збору, зберігання і пошуку цих даних. У міру збільшення кількості прикладних програм, що обслуговують усі рівні управління та опрацьовують одні й ті самі робочі дані, зростав обсяг дублювання, що ставало гальмом на шляху комп’ютеризації управління. Більше того, це дублювання часто було неефективним, оскільки спричинялося до несумісності прикладних програм. Виходом із цієї ситуації стала концепція створення єдиної централізовано керованої бази даних, яка обслуговує за допомогою спеціального програмного продукту — СУБД — усі прикладні програми організацій. Основною проблемою створення великих розподілених баз даних є складність описати дані об’єктивно, незалежно від окремих приклад¬них програм, з тим щоб спростити колективне використання даних різними прикладними програмами. Для опису даних широко застосо¬вуються моделі та словники даних. Семантика даних, тобто вивчення змісту даних незалежно від окремих прикладних програм, стала самостійною галуззю досліджень. Системи підтримки прийняття рішень (Decision Support System) — це інформаційні системи третього покоління. Вони мають не тільки загальне інформаційне забезпечення, а й загальне математичне забезпечення — бази моделей, тобто в них реалізована ідея розподілу обчислень подібно до того, як розподіл даних став вирішальним чинником у звичайних інформаційних системах. Усвідомлення важливості розподілу обчислень в автоматизованих розрахунках виникло тоді, коли було помічено, що в багатьох прикладних програмах використовуються аналогічні обчислення, а індивідуальні фактори, які впроваджуються в приладні програми для допомоги конкретному користувачеві, вносять незначні відмінності. Крім того, мало місце значне дублювання дій і процедур під час розробки, реалізації та тестування цих обчислювальних функцій. Із зростанням кількості прикладних програм для надання персоналізованої оперативної підтримки, а також із збільшенням кіль¬кості інформаційних систем зростав обсяг обчислювального дублювання, що стало значною мірою гальмівним чинником: для індивідуальної оперативної підтримки необхідно виконувати досить багато персоналізованих версій однієї й тієї самої прикладної програми, причому кожна версія підлягає багаторазовій модифікації упродовж періоду її експлуатації, з тим щоб вона відповідно реагувала на зміни в можливостях, знаннях, позиції і побажаннях користувача. Більше того, дубльована версія часто виявлялась менш ефективною, викликала взаємну несумісність програм і меншу продуктивність обчислень. Виходом із такої ситуації стала концепція утворення єдиної централізовано керованої бази моделей. У цьому напрямку було одержано ряд результатів: 1) більш високий рівень модульності, досягнутий завдяки стандартизації інтерфейсів, дозволив поліпшити можливості знаходження надмірностей; 2) системи управління базами даних були використані для контролю та управління інтерфейсами моделей; 3) за допомогою засобів системного аналізу і мов специфікацій були здійснені спроби описати обчислення таким способом, який був би прийнятним для широкого діапазону користувачів (від кінцевих користувачів до розроблювачів системи); 4) деякі системні описи були автоматизовані та включені в програмне забезпечення за допомогою діалогу користувач—система, параметризованих алгоритмів та інтерфейсів типу меню. 7.2. ОРГАНІЗАЦІЙНО-ТЕХНОЛОГІЧНІ ОСНОВИ ПРИЙНЯТТЯ РІШЕНЬ 7.2.1. Стислий опис процесу прийняття рішень Комп’ютерна інформаційна система СППР використовується для підтримки різних видів діяльності в процесі прийняття рішень: вибору загальної стратегії дії, визначення спеціальних зав¬дань, делегування відповідальності, оцінки результатів, ініціювання змін. Проблеми прийняття рішень і особа, яка приймає ці рішення, останнім часом все більше заслуговують на увагу. Це зумовлено зростанням динамізму навколишнього середовища, взаємопов’язаності багатьох рішень, стрімким темпом науково-тех¬нічного прогресу. Керівники, приймаючи рішення, стикаються із складним вибором, з необхідністю розгляду множини альтернативних варіантів. Для оцінки варіантів використовуються знання спеціалістів, складні аналітичні розрахунки, наукові дослідження, засоби сучасної інформаційної технології. Питання підтримки рішень на всіх стадіях цього процесу (цілевиявлення, розробка і прийняття рішень, організація виконання і контроль) стають де- далі більш актуальними (рис. 7.3). Фактично проблема полягає в Рис. 7.3. Схема підготовки і прийняття рішень автоматизації творчої частини праці відповідальної групи працівників організаційного управління — керівників усіх рангів та осіб, які приймають рішення, в реальних умо¬вах їхньої діяльності. Унікальні й нестандартні проблеми прийняття рішень в організаційному управлінні в своїй ситуаційній основі мають загальні риси: а) неповторність ситуації вибору; б) складний для оцінки характер альтернатив, що розглядаються; в) недостатня визначеність наслідків дій (невизначеність піс-лядій); г) наявність сукупності різнорідних чинників, які необхідно брати до уваги під час прийняття рішень; д) наявність особи або групи осіб, відповідальних за прийняття рішень. Існує декілька способів класифікації проблеми прийняття рішень. Найбільше визнання здобула класифікація, запропонована Саймоном у 1958 р. Відповідно до цієї класифікації всі проблеми прийняття рішень в організаційному управлінні поділяються на три класи (табл. 7.1). Таблиця 7.1 КЛАСИФІКАЦІЯ ЗАДАЧ ОРГАНІЗАЦІЙНОГО УПРАВЛІННЯ Клас Визначальна особливість Методи рішення Галузі використання Перший Цілком структуровані (формалізова¬ні) процедури вироблення рішень Основані на стандартизації і програмуванні Бухгалтерський облік; під¬готовка виробницт-ва; складський облік і т. ін. Другий Слабоструктуровані процедури ви¬роблення рі-шень Умови неповної інформації, теорії нечітких (розмитих) множин Поточне планування; оперативно-календарне плануван-ня; управління запасами Третій Неструктуровані процедури виро-б¬лення рішень Творчий підхід на основі поінформованості, кваліфікації, інтуїції і т. ін. Прогнозування; перспек¬тивне планування Перший клас становлять добре структуровані (цілком формалізовані, кількісно сформульовані) проблеми, в яких суттєві залежності визначені настільки повно, що вони можуть бути виражені в числах або символах і тому легко стандартизуються і програмуються. До цих задач належать: облік і контроль; оформлення документів, їх тиражування тощо. У традиційних інформаційних системах (АСУ) такого роду задачі автоматизовані, як правило, повністю (бухгалтерський облік, підготовка виробництва, кадрова система, складський облік тощо). Слова «добре струк¬туровані проблеми» зовсім не означають, що ці проблеми легкі. Застосування для їх розв’язання математичних методів, і зокрема методів дослідження операцій, пов’язані із значними труднощами. Другий клас становлять слабоструктуровані (змішані) проблеми, що мають як кількісні, так і якісні елементи, причому маловідомі й невизначені акценти проблеми виявляють тенденцію до переважання. Для таких задач характерною є відсутність методів розв’язання на основі безпосе¬редніх перетворень даних. Постановка задач вимагає прийняття рішень в умовах неповної інформації. Відомі випадки, коли на основі теорії нечітких множин і застосувань цієї теорії були побудовані формальні схеми рішень. До слабоструктурованих задач можна віднести задачі розподілу капіталовкладень, вибору проектів проведення наукових досліджень і розробок, складання плану виготовлення виробів широкого споживання тощо. Третій клас складають неструктуровані (неформалізовані, якісно виражені) проблеми (задачі), для яких описані лише важливі ресурси, ознаки і характеристики, а кількісні залежності між ними невідомі. Розв’язання таких задач передбачає неформалізовані процедури, які ґрунтуються на неструктурованій, з високим рівнем невизначеності інформації. До числа таких задач належить значна частина проблем прогнозування, перспективного планування, організаційного перетворення. Більшість неструктурованих проблем вирішується за допомогою евристичних методів, у яких відсутня будь-яка упорядкована логічна процедура пошуку розв’язання, а сам метод цілком залежить від особистісних характеристик людини (поінформованості, кваліфікації, таланту, інтуїції і т. ін.). До типових слабоструктурованих проблем належать проблеми, для яких характерними є такі особливості: — рішення, що приймаються, стосуються майбутнього; — має місце широкий діапазон альтернатив; — рішення залежить від неповноти поточних технологічних досягнень; — запропоновані рішення вимагають вкладання великих ресурсів і пов’язані з елементами ризику; — неповністю визначені вимоги стосовно вартості і часу рішення проблеми; — проблема складна через необхідність комбінувати різні ресурси для її розв’язання. Найважливіша особливість слабоструктурованих проблем полягає в тому, що концептуальна модель їх може бути створена тільки на основі додаткової інформації, що надходить від особи, яка бере участь у вирішенні проблеми. Тому такі моделі не можуть бути об’єктивними, неупередженими. Ця обставина — причина невдач у застосуванні «класичних» математичних моделей для дослідження слабоструктурованих проблем, а також стимул для розвитку адекватного інструментального забезпечення. Розглянута класифікація задач організаційного управління може бути поставлена у відповідність до певних груп працівників організацій і установ. Таких можна виділити три: керівники (головні адміністратори, директори, розпорядники), спеціалісти, технічні працівники (обслуговуючий персонал) (табл. 7.2). Таблиця 7.2 КЛАСИФІКАЦІЯ ПРАЦІВНИКІВ ОРГАНІЗАЦІЙНОГО УПРАВЛІННЯ Номер групи Назва групи Клас задач, що розв’язуються 1 Керівники (директори, головні адміністратори і т. ін.) Третій, меншою мірою — другий 2 Спеціалісти (керівники функціональних служб, головні спеціалісти) Другий 3 Технічні працівники (секретарі, касири, експерти, клерки і т. ін.) Перший Керівники зазвичай вирішують задачі другого класу (неструктуровані) і меншою мірою — третього (слабоструктуровані). Творчий елемент діяльності керівників є максимальним, а рутинна робота має бути зведена до розумного мінімуму. Ці працівники несуть найбільшу відповідальність за прийняття рішень і є одними із основних споживачів агрегованих (узагальнених) інформаційних ресурсів в організації. Другу групу працівників установ і організацій становлять спеціалісти (начальники функціональних служб, головні спеціалісти та ін.), які вирішують переважно задачі третього класу — слабоструктуровані. Ефективність функціонування установи визначається в багатьох випадках продуктивністю діяльності спеціалістів, особливо в питаннях створення нового інформаційного ресурсу. Робота спеціалістів вимагає багато в чому творчого підходу і залежить від конкретного змісту поточних задач. Спеціалісти забезпечують практично всю інформаційну підготовку для прий¬няття рішень. Враховуючи специфіку вирішуваних спеціалістами задач, підтримка їхньої діяльності за допомогою комп’ютерних інформаційних систем повинна бути досить серйозною. Технічні працівники, які утворюють третю групу працівників організаційного управління, виконують усю рутинну роботу, що належить до задач першого класу. До цієї групи входять молодші спеціалісти — касири, коректори, експедитори тощо, робота яких регламентована, але вимагає розуміння опрацьовуваної інформації. Водночас до групи належать і інші категорії працівників, кот¬рі володіють суто виробничими навичками (друкарки, телефоністки, секретарі і т. ін.), але специфіка їхньої роботи не потребує повного розуміння опрацьовуваної інформації. Комп’ютерна підтримка діяльності технічного персоналу не вимагає складної методологічної бази і реалізується в межах звичайних інформаційних систем. У результаті аналізу двох наведених вище таблиць, а також з урахуванням існуючого рівня розвитку ІС можна зробити такі висновки: 1) Комп’ютерною підтримкою охоплені повністю задачі пер-шого класу і частково другого (тобто ті задачі, які вирішують-ся на організаційному рівні спеціалістами та технічними праців-никами). 2) Практично повністю відсутня комп’ютерна підтримка ді-яльності керівників вищого рівня, які в своїй практичній діяльно-сті, як правило, вирішують задачі третього класу. Це означає, що комп’ютерні СППР насамперед покликані надавати допомо-гу в процесі прийняття рішень першим керівникам підприємств, організацій, тобто тим категоріям, які вирішують задачі слабо- або взагалі неструктуровані. Зазначимо, що в загальному випадку для підтримки прийняття рішення, окрім СППР, використовуються й інші типи сучасних інформаційних систем — експертні системи (ЕС) та виконавчі інформаційні системи (ВІС). Співвідношення між рівнями організаційного управління і типами інформаційних систем, що використовуються для підтримки прийняття відповідних рішень, наведено на рис. 7.4. Рис. 7.4. Співвідношення між рівнями організаційного управління і типами інформаційних систем 7.3. РОЗВИТОК ТА ВПРОВАДЖЕННЯ СИСТЕМ ПІДТРИМКИ ПРИЙНЯТТЯ РІШЕНЬ НА ПІДПРИЄМСТВАХ 7.3.1. Суть і компоненти СППР Системи підтримки прийняття рішень виникли на початку 70-х років як подальший розвиток управлінських інформаційних систем (УІС) і являють собою системи, розроблені для підтримки процесів прийняття рішень менеджерами в складних і слабострук¬турованих ситуаціях, пов’язаних з розробкою і прийняттям рішень. На розвиток СППР суттєвий вплив справили вражаючі досягнення в галузі інформаційних технологій, зокрема телекомунікаційні мережі, персональні комп’ютери, динамічні електронні таблиці, експертні системи. Термін СППР (DSS—Dесіsіоn Sup¬port System) ввели в 70-х роках Горрі і Мортон, хоча перше покоління СППР мало чим відрізнялося від традиційних управлінських інформаційних систем, і тому замість СППР часто використовувався термін «системи управлінських рішень». До цього часу немає загальновизнаного визначення СППР. Під СППР мають на увазі: «інтерактивну прикладну систему, що забезпечує кінцевим користувачам, які приймають рішення, лег-кий і зручний доступ до даних і моделей з метою прийняття рі-шень у напівструктурованих і неструктурованих ситуаціях в різ-них галузях людської діяльності»; «оснований на використаннях моделей ряд процедур з опрацювання даних і думок, що допома-гають керівникові у прийнятті рішень»; «інтерактивні автомати-зовані системи, які допомагають особам, що приймають рішення, використовувати дані і моделі під час вирішення неструктурованих і слабоструктурованих проблем»; «комп’ютерну інформаційну систему, використовувану для підтримки різних видів діяльності під час прийняття рішень у ситуаціях, де неможливо або небажано мати автоматичну систему, яка повністю виконує весь процес рішень». Нарешті, існує твердження, відповідно до якого СППР являє собою специфічний і добре описуваний клас систем на основі персональних комп’ютерів. Таке різноманіття визначень систем підтримки прийняття рі-шень відбиває широкий діапазон різних форм, розмірів, типів СППР. Але практично всі види цих комп’ютерних систем харак-теризуються чіткою родовою структурою, яка включає три голо-в¬ні компоненти: підсистему інтерфейса користувача; підсистему управління базою даних і підсистему управління базою моделей (рис. 7.5). Зазначимо, що компоненти забезпечують у СППР Рис. 7.5. Компоненти СППР реалізацію ряду важливих концепцій побудови інформаційних систем: інтерактивність, інтегрованість, потужність, доступ-ність, гнучкість, надійність, робастність, керованість. Інтерактивність СППР означає, що система відгукується на різного роду дії, якими людина хоче вплинути на обчислюваль-ний процес, зокрема за діалогового режиму. Людина і система обмінюються інформацією в темпі, що його можна порівняти з темпом опрацювання інформації людиною. Інтегрованість СППР забезпечує сумісність складових час-тин системи в управлінні даними і засобами спілкування з корис-тувачами в процесі підтримки прийняття рішень. Потужність СППР означає спроможність системи відповіда-ти на найсуттєвіші питання. Доступність СППР — це здатність забезпечувати видачу відповідей на запити користувача в потрібній формі і в потрібний час. Гнучкість СППР характеризує можливість системи адапту-ватися до змін потреб і перемін у ситуаціях. Надійність СППР полягає у здатності системи виконувати потрібні функції упродовж заданого періоду часу. Робастність СППР — це міра здатності системи відновлюва-тися у разі виникнення помилкових ситуацій як зовнішнього, так і внутрішнього походження. Керованість СППР означає спроможність користувача конт-ролювати дії системи і втручатися в хід рішення задачі. Аналіз еволюції систем підтримки прийняття рішень дозволяє виділити два покоління СППР: перше покоління розроблялось у період з 1970 до 1980 р., друге — з початку 1980 р. до цього ча-су. 1) Перше покоління СППР, як зазначалося, значною мірою дублювало функції звичайних управлінських систем у наданні комп’ютерної допомоги в прийнятті рішень. Основні компоненти СППР мали такі ознаки: управління даними — велика кількість інформації, внутрішні й зовнішні банки даних, опрацювання й оцінка даних; управління обчислюванням (моделювання) — моделі, роз- роблені спеціалістами в галузі інформатики для спеціальних про-блем; користувацький інтерфейс (мова спілкування) — мови про-грамування, створені для великих ЕОМ, які використовуються тільки програмістами. 2) СППР другого покоління вже мають принципово нові ознаки: управління даними — необхідний і достатній обсяг інформації про факти відповідно до сприйняття ОПР, що охоплює приховані припущення, інтереси та якісні оцінки; управління обчислюваннями і моделюванням — гнучкі моделі, що наслідують спосіб мислення ОПР у процесі прийняття рі-шень; користувацький інтерфейс — програмні засоби, «дружні» користувачеві, звичайна мова, безпосередня робота кінцевого користувача. Мету і призначення СППР другого покоління в загальному вигляді можна визначити таким чином: а) допомога в розумінні проблеми, що розв’язується. Вона пе-редбачає: структуризацію проблеми, генерування постановок за-дач, виявлення переваг, формування критеріїв; б) допомога в розв’язанні задачі: генерування і вибір моделей і методів, збір і підготовка даних, виконання обчислень, оформ-лення і видача результатів; в) допомога в аналізі розв’язань, тобто проведення аналізу ти-пу «що—якщо?» та інших, пояснення ходу розв’язання, пошук і видача аналогічних рішень у минулому та їхніх наслідків. Для сучасних комп’ютерних СППР характерна наявність ряду характеристик. 1. СППР надає керівникові допомогу в процесі прийняття рі-шень і забезпечує підтримку в усьому діапазоні контекстів структурованих, напівструктурованих і неструктурованих задач. 2. СППР підтримує і посилює (але не заміняє і не відміняє) міркування та оцінки керівника. Контроль залишається за лю-диною. 3. СППР підвищує ефективність прийняття рішень (а не лише продуктивність). На відміну від адміністративних систем, у яких увага загострюється на максимальній продуктивності аналітич-ного процесу, в СППР значно більше значення має ефективність процесу прийняття рішень. 4. СППР здійснює інтеграцію моделей і аналітичних методів із стандартним доступом до даних і вибіркою даних. Для подання допомоги під час прийняття рішення активізуються одна чи кіль-ка моделей (математичних, статистичних, імітаційних, кількіс-них, якісних і комбінованих). 5. СППР проста в роботі для осіб, які не мають значного до-свіду роботи з ЕОМ. 6. СППР побудована за принципом інтерактивного розв’я-зання задач. Користувач має можливість підтримувати діалог з СППР у безперервному режимі, а не обмежуватися видачею окремих команд з наступним очікуванням результатів. 7. СППР зорієнтована на гнучкість та адаптивність для при-стосування до змін середовища або підходів до розв’язання за-дач, які приймає користувач. 8. СППР не повинна нав’язувати певного процесу прийняття рішень користувачеві. 7.3.2. Галузі застосування та приклади використання СППР на підприємствах Системи підтримки прийняття рішень широко застосовуються в економіках передових країн світу, а кількість їх постійно зрос-тає. На рівні стратегічного управління використовується ряд СППР, зокрема для довгострокового, середньострокового і коро-т¬кострокового планування, а також для фінансового планування, включаючи систему для розподілу капіталовкладень. Орієнтовані на операційне управління СППР застосовуються в галузях маркетингу (прогнозування та аналіз збуту, дослідження ринку і цін), науково-дослідних та конструкторських робіт, в управлінні кадрами. Операційно-інформаційні застосування пов’язані з виробництвом, придбанням та обліком товарно-матеріальних запасів, фізичного розподілу їх та бухгалтерського обліку. Узагальнені СППР можуть інтегрувати дві або більше перелічених функцій. У США в 1984 р. був виконаний аналіз типів СППР, в результаті якого були виявлені пріоритетні галузі використання систем. До них належать: виробничий сектор; гірничорудна справа; транспорт; фінанси; урядова діяльність. Перелік найвідоміших «комерційних» СППР включає сотні назв. Ось найтиповіші із СППР, пов’язаних з про¬блемами мікро- і макроекономіки: «Сімплан» — призначена для корпоративного планування; «Прожектор» — для фінансового планування; «Джі-план» — для загального планування; «Експрес» — для маркетингу, фінансів; Marketing Expert — для стратегічного планування маркетингу; ІFPS — для інтерактивного фінансового планування; Dgrid — для підтримки прийняття багатокритеріальних рі-шень. Розгляньмо деякі СППР, що використовуються на підприєм- ствах. 7.3.2.1. Система «Сімплан» СППР «Сімплан» (SІМРLАN) створена в середині 70-х років для подання допомоги керівникам у подоланні невизначеності, властивої корпоративному плануванню. Її призначення полягає у вивченні складних взаємозалежностей між діяльністю корпорації в галузях фінансів, маркетингу і виробництва з використанням сукупності математичних і логічних співвідношень, занесених у комп’ютер. Ця система вміщує три центральні компоненти — фінансові моделі, моделі маркетингу і моделі виробництва. Призначення фінансових моделей — показати ефективність різних варіантів фінансового стану підприємства; моделі маркетингу використо-вуються для оцінки майбутнього обсягу ринку в тій частині, якою хоче заволодіти компанія; моделі виробництва застосовую-ться для вирішення питань, пов’язаних з витратами і плануван-ням, політикою в галузі товарно-матеріальних запасів, вимогами до робочої сили, вартості й наявності сировини, змінами в поту-жності обладнання і підприємства загалом. Система «Сімплан» включає такі підсистеми: 1) КЕРУВАННЯ ДАНИМИ — забезпечує ефективне зберіган-ня і виборку великих кількостей даних і має засоби управління даними; 2) МОДЕЛЮВАННЯ — надає можливість відбивати будь-які види зв’язків у галузі фінансів, маркетингу і виробництва в нале-ж¬ній формі; 3) ОДЕРЖАННЯ ЗВІТІВ — забезпечує генерацію звітів для користувачів; 4) КОНТРОЛЬ БЕЗПЕКИ — являє собою багаторівневу сис-тему контролю безпеки з метою обмеження доступу до даних і інформації; 5) ГРАФІЧНЕ ВІДОБРАЖЕННЯ — включає велику кількість форматів графічного відображення для візуального сприйняття діаграм і графіків; 6) ПРОГНОЗУВАННЯ — реалізує методи лінійного прогнозу-вання, експоненціального згладжування, адаптивного прогнозу-вання; 7) ЕКОНОМЕТРИЧНИЙ І СТАТИСТИЧНИЙ АНАЛІЗИ — дають змогу виділяти значущу інформацію про взаємозв’язки, які характеризують розглядувані планові періоди. Система «Сімплан» дає можливість користувачеві визначити нові функції і включати їх до СППР. Моделі (разом з переліче-ними і пов’язаними з ними функціями) є організаційними скла-довими частинами системи. Спочатку користувач вводить режим керування — точку, з якої можна увійти в будь-який інший режим. Режим даних об’єднує засоби системи з управління да-ними. Режим аналізу вміщує набір релевантних економетричних і статистичних методів аналізу, прогнозування і мову моделю-вання системи «Сімплан». Режим звіту служить основою гене-рації звітів, режим редагування призначений для цілей подаль-шого спрощення створення і використання моделей і звітів. Графічний режим дає можливість ідентифікувати закономірності даних, використовуваних як базис для прогнозування, розгля-дати розбіжності між практичними даними і прогнозами або бюджетами, а також служить для візуального порівняння ре-зультатів реалізації моделей, в основу яких покладені різні сис-темні припущення. 7.3.2.2. Система IFPS Система IFPS (Interactive Financial Planming System) підтримує процеси рішення проблем за допомогою побудови легко зрозумілих ділових ситуацій. Основні моделі IFPS, завдяки яким система є корисним інструментом для керівників, включають мову моделювання і структуру команд, які дозволяють описувати проб- леми звичайною для людини мовою і отримувати результатні рішення у вигляді таблиць. IFPS спроможна відбивати співвід-ношення між клітинами таблиці, інтерпретація значень яких ціл-ком залежить від користувачів. Робота з системою розпочинається з опису потрібної моделі мовою моделювання, яка супроводжується введенням послідов-ності положень, що визначають джерела даних для рядків і стов-п¬ців, а також співвідношень для обчислення рішення. При цьому користувач може викликати різні програми, вносити коментарі, визначати логічні умови, обмеження і використання даних, про-водити процедури, пов’язані з аналізом ризику, і виконувати ряд інших функцій. Система дозволяє розв’язувати досить широкий клас задач: 1) підбивання балансових підсумків; 2) розподіл при-бутку за статтями доходів; 3) передбачення змін валютних кур-сів; 4) прогнозування, аналіз ризику; 5) розроблення стратегії збуту продукції; 6) вибір науково-дослідних проектів; 7) стра-тегічне планування; 8) планування прибутку і бюджету; 9) вибір між стратегіями закупівлі або власного виготовлення продукції тощо. 7.3.2.3. Система підтримки прийняття рішень «Business Navigator 2.0» Система «Business Navigator 2.0» призначена для підвищення опе¬ративності та обгрунтованості рішень на етапах планування, організації та управління діяльності підприємств малого та середнього бізнесу, самонавчання спеціалістів у галузі маркетингу та планування. Необхідність підтримки прийняття рішень за допомогою спе-ціальної інформаційної системи пояснюється кількома чинника-ми: ? існуючою невизначеністю стану попиту, пропозиції та їх еволюції; ? складністю рішення фінансових і економічних задач; ? потребою забезпечити мінімально можливу вразливість від впливу негативних чинників зовнішнього середовища. До складу пакета програм «Business Navigator 2.0» входять три основних модулі: 1) модуль генерації рішень; 2) модуль планування; 3) модуль оперативного управління. Така структура зумовлена необхідністю етапів, що формулю-ють кінцеве рішення. Модуль генерації рішень допомагає вирішувати творчі зада-чі вибору цілі й формування оптимальної множини способів дій. У модулі сформульовані принципи ефективного управління, роз-криті основні управлінські функції; наведена узагальнена схема розвитку конфліктних ситуацій. Модуль «Планування» дозволяє освоїти методику стратегіч-ного й тактичного планування технологічних прийомів кількіс-них оцінок привабливості ринку та сили бізнесу, пов’язаних з оцінками прибутковості підприємства, надає можливість розра-ховувати всі основні розділи бізнез-плану, формулює звітні до-кументи бізнес-планування. Конструктивно модуль складається з трьох субмодулів: а) субмодуль «Моделі»; б) субмодуль «Попередній аналіз»; в) субмодуль «Детальне планування». Субмодуль «Моделі» дозволяє освоїти якісні та кількісні ме-тоди економічного аналізу та планування, а саме: ? дотримання принципів сегментації ринків; ? методику виділення стратегічних зон господарювання (СЗГ); ? методику оцінки привабливості стратегічних зон господа-рювання та силу бізнесу; ? методику прийняття економічних рішень і вибору стратегії та тактики бізнесу. Субмодуль «Попередній аналіз» реалізовано на моделі, що доз¬воляє кількісно оцінити конкурентний стан підприємства на ринкові. У субмодель вводять вхідні дані, що характеризують проект та умови діяльності. У результаті роботи цього субмодуля отримують такі дані: ? частка споживачів підприємства для певної кількості това-рів та послуг; ? частка споживачів конкурентів; ? частка реалізованої продукції; ? прибуток підприємства. Автоматично обчислюється залежність ринкової частки під-приємства від зміни ціни, зміни частки постійних споживачів та зміни популярності товарів, що пропонуються. Модуль дозволяє зробити одночасно аналіз поточного стану підприємства та перспективного, зумовленого розвитком ринку. Субмодуль «Детальне планування» дозволяє складати бізнес-план проекту, включаючи розрахунки виробничого та фінансово-го планів, а також: ? оцінити чутливість проекту; ? кількісно оцінити значення ризику проекту; ? скористатися для аналізу всіма функціями додатка Excel комплексу Microsoft Offiсe; ? розрахувати економічні й фінансові показники проекту; ? забезпечити видачу на друк усіх необхідних графічних та текстових результатів; ? заповнити основні розділи бізнес-плану для існуючого проекту, що передається в додаток Word. У формуванні виробничого плану можна скористатися авто-матизованим способом розвитку, при якому на основі введених характеристик плану збуту автоматично формуються необхідні значення обсягів виробництва та сировини, враховуючи вказані показники необхідних запасів сировини та готової продукції, можливих витрат під час виробництва та збуту. Звітні документи фінансового плану (звіт про прибутки та збитки, звіт про рух грошових коштів, консолідований бухгал-терський баланс) формуються автоматично на основі даних ви-робничого плану. Модуль «Оперативне управління» дозволяє організувати ефективне тактичне управління підприємством в умовах ринко-вої кон’юнктури, що швидко змінюється, та провадити аналіз за необмеженої кількості продуктів підприємства і необмеженої чи-сельності конкурентів. Основу модуля становить модель оцінки ефективності підприємства в заданих умовах ринкової кон’юнктури. Використання оригінальних рішень у галузі економічної кібернетики дозволяє кількісно оцінювати та враховувати вплив на кінцевий результат ефективності реклами, якості продукції, уподобання споживачів, доступність продукції для споживачів у поєднанні з ціною товарів та іншими чинниками. Залежно від купівельної спроможності споживачів, місткості ринку та існуючих можливостей конкурентів модуль дозволяє давати кількісні оцінки таким показникам: ? величина прибутку; ? частка продукції, що реалізується; ? рентабельність капіталу; ? положення точки беззбитковості. Автоматично розраховуються залежності ринкової величини прибутку від зміни частки постійних споживачів, зміни постій-них споживачів та популярності товарів, що пропонуються. Мо-дель надає можливість підібрати такі умови діяльності (такий ри-нок збуту), для яких фінансові показники підприємства будуть найліпшими за даних умов. 7.3.2.4. СППР Marketing Expert СППР Marketing Expert належить до класу MDSS — марке-тингових систем підтримки прийняття рішень — і призначається для допомоги менеджерам з маркетингу в розробці стратегічного і тактичного планів маркетингу. Розгляньмо основні елементи пер¬шої версії програми і те, як вони можуть бути використані у стратегічному плануванні маркетингу. Графічну основу програми становить Карта Ринку, на якій користувач за допомогою спеціального інструментарію може по-будувати інфраструктуру свого підприємства — так звані центри доходів і витрат (ЦДВ), у які входять сама компанія, її функціо-нальні відділи і канали збуту (комівояжери, агенти, оптова і роз-дрібна торгівля), що належать компанії. Карта Ринку відбиває й такі зовнішні стосовно компанії сегменти ринку (рис. 7.6): ? територія; ? ринок (сегмент товарного ринку); ? товар (товарна група); ? цільова група споживачів; Рис. 7.6. Загальний вид Карти Ринку ? конкурент; ? канали збуту, що не належать компанії. Інструментарій системи дозволяє легко будувати модель ком-панії, що оперує на декількох ринках з урахуванням її збутових структур; установлювати зв’язки між об’єктами різних типів; змінювати масштаб карти (від 1:1 до 1:8) і колір об’єктів різного типу сегментів; переміщати як окремі об’єкти на карті, так і всю побудовану структуру; вводити дані для кожного об’єкта і відоб-ражати за допомогою колірної диференціації кількісні характери-стики різних об’єктів. При цьому застосовується принцип візуалізації інформації, який використовується в геоінформаційних системах, що дозволяє зручно і швидко одержувати, а також опрацьовувати розподілену по сегментах інформацію. Це означає, що з кожним типом сегментів буде пов’язана відповідна база даних, в якій зберігатимуться не тільки внутрішні зв’язки сегментів (замовники купують конкретний товар), а й кількісні дані, що відображають виробничо-збутовий процес. З активізацією певного сегмента (за допомогою натискання ми¬ші) відображатиметься база даних, що відповідає цьому сегменту. Карта Ринку дозволяє ефективно вирішувати задачу аудиту маркетингу, оскільки дає можливість наочно зобразити інфраструк¬туру компанії та її зв’язок із усіма зовнішніми сегментами ринку. Рис. 7.7. Опитувальні листи для проведення SWOT-аналізу СППР надає можливість ефективно провадити процедуру SWOT-аналізу за допомогою спеціальних дворівневих багатокри-теріальних опитувальних листів, специфічних для кожного типу сегментів ринку (рис. 7.7 та 7.8). У результаті заповнення цих листів кожний об’єкт одержує сумарні оцінки по декількох критеріях. Потім за допомогою про-цедури багатокритеріального відбору, в якій можна гнучко змі-нювати систему критеріальних обмежень, менеджер може віді-брати об’єкти певного типу сегментів ринку (наприклад, канали збуту), що становлять найбільший інтерес для компанії. Після заповнення відповідних баз даних за допомогою пре-процесора блок сегментного аналізу дає змогу оцінювати ефек-тивність різних сегментів компаній, тобто моделювати реакцію різних сегментів (через показники їхньої ефективності) на варіа-цію вхідних даних. Це дозволяє якнайефективніше включати в модель урахування невизначеності, тобто What-if-аналіз. Рис. 7.8. Графічне подання SWOT-аналізу в СППР Маrketing Expert 7.3.2.5. Виконавчі інформаційні системи (ВІС) Традиційно основними користувачами СППР є професіонали та менеджери середнього рівня. Встановлені СППР (орієнтова- ні на підтримку прийняття рішень з конкретних специфічних га-лузей на підприємствах) здебільшого підтримують плановиків, аналітиків та дослідників. СППР для менеджерів вищого рангу (генеральних директорів, президентів) називаються виконавчими СППР або виконавчими ІС (ВСППР або ВІС). ВІС можна визначити як комп’ютерну систему, що надає до-помогу у вирішенні задач топ-менеджерами завдяки можливості швидкого доступу до оперативної інформації і прямого доступу до управлінських звітів. Окрім надання звітів та здатності зану-рення у зміст проблем (метод «drill-down»), ВІС відрізняється про¬стотою спілкування з користувачем та наявністю потужного графічного інтерфейсу. Доступ до електронної пошти та інформаційні послуги в режимі он-лайн є звичними засобами в системах цього класу. ВСППР фокусується на сучасному і надає користувачеві ін-формацію щодо бюджетування, його часових обмежень в орга-нізації тощо. ВІС побудована на демонстраційній техноло- гії, вона покликана подавати статистичні звіти та різноманітні графіки на вимогу. Система, як правило, пропонує багато ана-літичних операцій для пояснення, діагностування та розуміння інформації. У ВІС для виконання зазначених функцій використовуються сховища даних (Data Warehouse) — предметно-орієнтована, інтегрована, така, що не коригується, та залежна від часу ко-лекція даних, призначена для підтримки прийняття управлінсь-ких рішень. Сховище даних повинно пропонувати таке середо-вище накопичення даних, яке оптимізоване для виконання склад-них аналітичних запитів управлінського персоналу. Ці запити можуть бути досить специфічними для кожної організації, кож-ного підрозділу і навіть окремого керівника. Сховище даних повинно автоматично збирати операційні дані, погоджувати їх і об’єднувати в предметно орієнтований формат, який потрібен працівникам управління. Основними характеристиками ВСППР є : ? зручний дизайн, який задовольняє інформаційні потреби головних менеджерів, тобто легкість у використанні; ? адекватне відстежування та можливості контролю; ? орієнтація на індивідуальні потреби окремих посадових осіб, урахування корпоративної культури та управлінських орга-нізаційних стилів; ? широкі графічні можливості для подання інформації та можливості для створення звітів; ? своєчасне передбачення потреб в інформації для підтримки прийняття рішень; ? стандартний доступ до нестандартних альтернатив; ? виключне звітування з виявленням відхилення від планів; ? текстова та таблична інформація про можливості застосу-вання системи; ? можливості багатофакторного та глибокого осмислення даних; ? фільтри, архіватори та пошукачі даних; ? підтримка розв’язання відкрито-закритих задач; ? широке застосування зовнішніх БД, за допомогою яких до-сліджуються чинники впливу зовнішнього середовища; ? підтримка різних типів даних (зовнішніх, внутрішніх, структурованих та неструктурованих); ? підтримка певних класів користувачів (виконавців та конт-ролерів). Прикладом ВІС може бути система Executive Edge (EE) (роз-робник — корпорація Екзекюком Сістемс (США)). На рис. 7.9 наведено структуру системи: ЕЕ включає генератор СППР кор-порації Екзекюком, IFPS-PLUS (інтерактивну систему фінансо-вого планування) та Vantage Point — програмний засіб для діа-логу з ПЕОМ. IFPS-PLUS забезпечує виконання функцій СУБД для збереження специфічної інформації ВІС та деяких унікаль-них аналітичних програм, орієнтованих на виконавців. Vantage Point може користуватися будь-яким інтерактивним додатком на віддаленому АРМі. Це забезпечує простоту у використанні та можливість залучати будь-яку комп’ютерну інформацію або програму до ВІС-додатків (рис. 7.9). ЕЕ має у своєму розпоря-дженні засоби штучного інтелекту, може використовувати ме-ханізми «drill-down» для відповіді на проблемні питання в про-цесі розв’язання задач у великих організаціях, а її відкрито-закрита архітектура робить можливими зв’язок та інтеграцію з існуючими комп’ютерними інформаційними та операційними системами. Рис. 7.9. Виконавча інформаційна система Executive Edge ЕКСПЕРТНІ СИСТЕМИ ТА ВИКОРИСТАННЯ ЇХ НА ПІДПРИЄМСТВАХ 8.1. ОРГАНІЗАЦІЙНІ ОСНОВИ ЕКСПЕРТНИХ СИСТЕМ Управління підприємством або установою являє собою спосіб організації спільних дій колективу людей, які володіють деякими ресурсами для досягнення певних цілей. Цілі задаються під час створення підприємства, а в процесі його функціонування вони коригуються відповідно до зовнішніх змінюваних умов. Під ціллю мається на увазі характеристика підприємства з погляду результату свідомої діяльності людини. Виділяють два основних класи цілей: стратегічні й тактичні. Цілі відрізняються між собою рівнем узагальнення і періодом, на який вони сформовані. Управління призначене для зберігання основної якості підприємства, тобто сукупності таких його властивостей, втрата яких тягне за собою руйнацію підприємства в процесі взаємодії із зовнішнім середовищем. Управління прийнято поділяти на такі фази, або функції, як планування, облік, аналіз і регулювання (рис. 8.1). Рис. 8.1. Взаємозв’язок функцій управління Планування (П) необхідне для формулювання завдань підприємству в цілому й окремим його структурним підрозділам, облік (О) — для одержання об’єктивної інформації про стан справ, аналіз (А) — для виявлення причин відхилення від заданих планових характеристик і встановлення діагнозу стану підприємства, регулювання (Р) — для формування альтернативних варіантів поліпшення стану підприємства. Далі у викладі матеріалу використовуються поняття «управлінська економічна ситуація» і «рішення». Управлінська економічна ситуація — це характеристика сфор-мованого стану підприємства, що з погляду суб’єкта управління може бути задовільним або незадовільним. В останньому випадку ситуація відбиває розбіжність бажаного з дійсним станом підприємства і може бути охарактеризована як проблемна. Рішення — це знаходження зв’язку між існуючим і бажаним станом підприємства або організації, обумовленим ціллю. Оскільки управління — це безупинний процес цілеспрямованого впливу на об’єкт, а такий вплив можливий, якщо відомі правила ухвалення рішення й інформація, на підставі якої воно приймається, то, мабуть, від цих двох умов багато в чому залежить якість управління. У зв’язку з цим система, призначена для підтримки прийняття рішень, повинна володіти принаймні двома властивостями: а) якомога повніше акумулювати в собі знання і досвід у даній сфері прийняття рішень і б) уміти генерувати прос¬ті й ефективні прототипи рішень. Взаємозв’язок «ціль — рішення» не є однозначним через велике число шляхів досягнення однієї і тієї самої цілі. Це особливо стає очевидним, якщо в ієрархії управління виділити цілі, що відповідають кожному рівню. На найвищому рівні перебувають цілі, що мають директивний характер. Їх також називають траєкторними, оскільки вони відображають бажану траєкторію зміни об’єкта управління в часі (рис. 8.2). На практиці траєкторія руху підприємства задається за допомогою значень економічних показників. У процесі управління підприємством особа, що приймає рішення, прагнучи позбутися негативних явищ, домагається збігу фактичної траєкторії з бажаною. Якщо траєкторні цілі відбивають стратегію і перебувають на найвищому рівні ієрархії (рис. 8.3), то під ними знаходяться робочі цілі. Останні мають творчий характер, оскільки виробляються самою особою, що приймає рішення (ОПР). Ці цілі підпорядковані траєкторній цілі і змінюються відповідно до фактичної ситуації. Робоча ціль відповідає нижньому рівню ієрархії управління, і для нього вона стає траєкторією (директивною). Рис. 8.2. Графік зміни стану економічних показників Рис. 8.3. Ієрархія цілей і рівнів управління Формулювання робочих цілей вимагає знання цілей більш високого рівня, методики цілеутворення й інформації про фактичний стан підприємства. Якщо траєкторна ціль виражена не явно, тобто не структурована, вона може бути сформульована як робоча. При цьому обов’язковою є така умова: вся ієрархія траєкторних і робочих цілей повинна відповідати структурі управління підприємством. Це означає, що кожний структурний підрозділ повинен мати свій власний набір траєкторних цілей, що відображає службові обов’язки персоналу. Крім траєкторних та робочих цілей, існують ситуаційні цілі, що формулюються, виходячи з конкретної фінансово-господарської ситуації. Вся сукупність цілей, що стоять перед ОПР, подана на рис. 8.4. Рис. 8.4. Цілі особи, що приймає рішення Деякі фінансово-господарські ситуації можуть повторюватися досить часто, що дозволяє звести їх у ранг типових (базових). Описуючи типову ситуацію формальним способом, одержують так званий сценарій. Нагадаймо, що управління включає: планування, облік, аналіз та регулювання. З них досить автоматизованою є лише функція обліку. Щодо інших функцій єдиного підходу поки що не існує. Найпростішим варіантом автоматизації економічного аналізу порівняно з його ручним веденням (рис. 8.5 а) є формування аналітичних показників за допомогою комп’ютера (рис. 8.5 б). Ця задача практично вирішена, хоча комплексна методика цільового економічного аналізу ще удосконалюється. Така методика складається з технологічної й інформаційної частин. Технологічна частина описує спосіб перегляду, порівняння й оцінки обраних аналітичних показників відповідно до заданої шкали співвідношень. Інформаційна частина містить перелік аналітичних показників, спосіб розрахунку їх і нормативні значення. Під час розробки цієї частини об’єкти аналізу попередньо класифікуються за ознакою приналежності до задач управління. Згодом це дозволяє виділяти стандартні й нестандартні задачі: перші підлягають формалізації цілком, другі — частково. На рис. 8.5 б наведена схема використання експертної системи як інструмента автоматизації аналізу ситуації. Експертна система забезпечує: перегляд аналітичних показників та порівняння їх із заданими нормативами абсолютних значень; формування виводів виходячи з економічної ситуації; вироблення альтернатив. Цей процес може повторюватися циклічно, якщо ОПР що-не-будь не влаштовує. За повторного вироблення альтернатив ОПР може впливати на даний процес зміною ресурсів і резервів підприємства, а також ступеня актуальності тих або інших робочих цілей. Ще один варіант, поданий на рис. 8.5 в, забезпечує оцінку запропонованих рішень: для кожної альтернативи розраховується співвідношення «прибуток — витрати», що вимагає розвинутого програмного забезпечення. Рис. 8.5. Рівні автоматизації економічного аналізу 8.2. СКЛАД І ФУНКЦІЇ ЕКСПЕРТНИХ СИСТЕМ Зросла популярність експертних систем і їх значне поширення у різних галузях людської діяльності привели до того, що прог¬рамні продукти, створені для будь-яких потреб людини, їхні автори почали називати «експертними системами». Підставою для цього послужили недосить чіткі визначення таких систем. У даному випадку слід з’ясувати, які типові «розумові» процедури виконує людина-експерт, а які — спроможна виконати система, що претендує на назву експертної. Чим більше процедур вона може виконати, тим більше в неї підстав називатися експертною системою. Фахівці, що приймають рішення, звичайно здійснюють такі «розумові» процедури: • роблять висновок на підставі аналізу повних, неповних і ненадійних знань; • пояснюють і обґрунтовують, чому вони дійшли того або іншого висновку; • поповнюють свої знання, наново їх систематизують, на-вчаються на своєму і чужому досвіді; • роблять винятки з правил, використовують суперечливу і неправдоподібну інформацію; • визначають рівень своєї компетентності, тобто те, чи можуть вони приймати рішення в даному випадку чи ні. Перелічені процедури в повному обсязі не виконуються жодною програмною системою: зазвичай вони обмежуються першими двома. Тому побутує думка, що принциповою відмінністю експертних систем варто вважати їхню спроможність відтво- рювати уривчасті, неточні й суперечливі знання і маніпулювати ними. Вони повинні виконувати міркування не тільки і не стіль- ки на основі формальної (математичної) логіки, скільки на осно- ві комп’ютерної, тобто наближеної до людської логіки, причому система повинна вміти пояснювати, чому вона дійшла того або іншого висновку. Ці функції система зможе виконати, якщо міститиме компоненти, подані на рис. 8.6. Стисло охарактеризуємо функції основних блоків експертної системи. База знань за допомогою тих або інших моделей відображає знання експерта про предметну область, способи аналізу фактів, що надходять, і методику висновків, тобто породження нових знань на підставі наявних знань та знань, що надійшли. Факти і правила існують у різних видах знань людини-експерта. Найбільш визнаними і широко використовуваними в сучасних експертних системах є такі види знань: • глибинні й поверхові; • якісні та кількісні; • наближені (невизначені) і точні (визначені); • конкретні і загальні; • описові та наказові. Рис. 8.6. Склад типової експертної системи Ці види знань залежно від специфіки предметної галузі і кваліфікації проектувальника (інженера зі знань) з тією або іншою мірою адекватності можуть бути подані за допомогою однієї або декількох семантичних моделей. До найпоширеніших моделей належать: логічні, продукційні, фреймові та семантичні мережі. Логічні моделі базуються на поданні знань у системі логіки предикатів першого порядку. Наприклад, факт «ВО-Азовсталь є постачальником» відображається у вигляді предиката таким чином: є (во _азовсталь, постачальник). Вивід нових знань здійснюється на підставі силогізмів. Правила формальної логіки поступово розширюються, наближуючись до «людської» логіки. Остання характеризується нечіткістю, у зв’язку з чим доцільним є виокремлення модальної, багатозначної, немонотонної, псевдофізичної та інших видів логіки. Продукційні моделі подають знання у формі предиката першого порядку, а правила маніпулювання ними — за допомогою конструкцій «якщо—то». База правил складається з множини фраз типу: ЯКЩО РЕНТАБЕЛЬНІСТЬ знизилася І ПРИБУТОК збільшився ТО СОБІВАРТІСТЬ ПРОДУКЦІЇ збільшилася. Фреймове подання знань відбиває систематизовану у вигляді єдиної теорії психологічну модель пам’яті людини. Основний елемент моделі — фрейм — є відображенням структури даних для опису концептуальних (понятійних) об’єктів. Інформація, що стосується одного фрейма, міститься у слоті. Усі фрейми взаємозалежні й утворюють єдину систему, в якій поєднані факти (описові знання) і правила маніпулювання ними. Семантична мережа — найбільш зручна і зрозуміла для експертів модель подання знань. Під семантичною мережею, як правило, мають на увазі граф, вузли якого відповідають поняттям або об’єктам. Логічні виводи можуть ґрунтуватися на прямому або оберненому міркуваннях. Прямий ланцюжок пов’язаний із міркуваннями, що ведуться від даних до цілі міркування, а обернений — від цілі до даних — використовується для доведення міркування. Обернений вивід базується на графі ТА/АБО, що пов’язує в єдине ціле факти і висновки. Оцінка цього графа і є логічнии виводом. При цьому оцінюються лише ті частини графа, що стосуються висновку. Пряме міркування характеризується простотою вибору правил, однак часто призводить до некерованого режиму постановки питань у діалозі і, як правило, до зниження швидкодії системи. Блок логічних висновків має бути пристосований до роботи з ненадійними даними, що наближає експертну систему до реальної дійсності. Для цього розроблені нечітка логіка, коефіцієнти впевненості, байєсівська логіка, міра довіри тощо. Блок пояснень також відіграє важливу роль: система повинна уміти пояснити, як вона дійшла того чи іншого висновку. В експертних системах, заснованих на правилах, пояснення одержують звичайно простежуванням ще раз тих кроків міркування, що привели до даного висновку. 8.2.1. Економічні експертні системи Управлінська галузь істотно відрізняється від тих предметних галузей, у яких створені й успішно функціонують експертні системи (медицина, геологія, конструювання, хімія тощо). Економіч¬на сфера відстає від перелічених галузей як за кількістю, так і за якістю створених експертних систем, що можна пояснити складністю, динамічністю і великими обсягами знань, що підлягають відтворенню за допомогою комп’ютерів. Виявлення глибинних причин неефективності роботи того або іншого підприємства істотно залежить від уміння експерта проаналізувати стан виробництва й управління, сформулювати діагноз і виробити відповідний рецепт — перелік заходів. Очевидно, що перелічені процедури стосуються різних сфер діяльності підприємства — маркетингу, виробництва і т. ін. Все це досить важко відтворити в базі знань. Задані сфери діяльності вказують на перелік тих компонентів економічної експертної системи (ЕЕС), які повинні забезпечити управлінську діяльність. Перш ніж перейти до опису ЕЕС, треба спинитися на технології прийняття управлінських рішень в економічній сфері. Рис. 8.7. Послідовність виконання функцій управління Управління об’єктом економічного профілю (підприємством, організацією, банком тощо) припускає виконання ряду функцій управління, основними з яких, як уже згадувалося, є: планування, облік, аналіз і регулювання. Щоб співвіднести послідовність виконання функцій управління з послідовністю дій ЕЕС, розгляньмо повторюваний цикл управління. У поданому на рис. 8.7 циклі усі функції, за винятком формування цілі, можна автоматизувати. Причому функція обліку зазвичай автоматизується поза експертною системою і виконує роль допоміжного засобу. Функція цілеутворення також реалізується поза експертною системою, хоча і на основі інформації, що нею видається. Економічні об’єкти, що базуються на жорсткій структурі і мають одну головну ціль, досягнення якої залежить від підпорядкованих їй підцілей, породжують ієрархію цілей, що відображає ієрархію структурних підрозділів підприємства. Розгортання головної цілі в систему підпорядкованих цілей відбувається доти, поки останні не перетворяться в конкретні дії посадових осіб. Перетворення цілей у конкретні дії необхідне для вироблення плану дій на майбутнє. Виконання робіт обмежується ресурсами або резервами, що має важливе значення при прийнятті управлінських рішень. Жорстке визначення поняття «ресурс» відсутнє. Говорять про матеріальні, сировинні, трудові, грошові, енергетич¬ні та інші ресурси. У найпростішому випадку можна вважати, що усе, що лежить в основі графа цілей, є ресурсом. Ресурс можна розглядати як ієрархічно побудовану систему. Причому головний ресурс забезпечує досягнення головної цілі, ресурси другого рівня — досягнення цілей другого рівня і т. ін. Для жорстких організаційних систем (а саме до таких належать економічні об’єкти) ресурси, як і цілі, задані жорстко. Частина ресурсів перебуває в довгостроковому користуванні (будинки, устаткування, транспорт), а частина — швидко використо¬вується (енергія, напівфабрикати, грошові кошти). Кожному ресурсу в дереві ресурсів відведено цілком певне місце, що майже не змінюється. Крім поняття «ресурс», далі використовуватиметься поняття «резерв», під яким розуміється наднормативний розмір якогось ресурсу. У межах розміру резерву можна збільшувати обсяги робіт або розмір використовуваного ресурсу (акції, оренда, цінні папери). Щоб прийняти рішення, необхідно оцінити економічну ситуацію і виявити причини відхилення від заданої траєкторії. Якщо причини вдалося розкрити (установлені діагноз і рецепт дій), з’являється можливість відкоригувати раніше сплановані дії (план), після чого цикл управління повторюється. Звідси стає зрозумілим, які функції повинна виконувати ЕЕС: 1) розпізнавання сформованої економічної ситуації, її аналіз, формування діагнозу і найближчих цілей, досягнення яких забезпечить повернення до бажаної траєкторії розвитку підприємства; 2) вироблення шляхів досягнення сформульованих цілей без урахування і з урахуванням резервів підприємства; 3) поповнення бази знань, модифікація і ліквідація застарілих експертних знань із бази знань; 4) забезпечення «дружнього» інтерфейсу користувача із системою. Реалізація другої функції вимагає створення спеціального блоку оцінки можливих шляхів досягнення цілей, сформульованих за допомогою першої функції. У результаті склад типової ЕЕС дещо змінюється, відображаючи специфіку економічних задач. Порівняно з типовою експертною системою в економічну ЕС введені додаткові блоки (рис. 8.8): база даних, блок розрахунків, блок введення і коригування даних. Рис. 8.8. Склад економічної експертної системи Необхідність у блоці розрахунків диктується тим, що обґрунтування прийняття управлінських рішень вимагає не тільки логіч¬ного висновку, а й здійснення ряду розрахунків, досить часто складних та об’ємних. Без бази даних також не може обійтися жодна програмна система економічного профілю. У базі даних містяться планові, фактичні, розрахункові, звітні та інші постійні або оперативні показники. Наявність бази даних дозволяє використовувати стандартні процедури опрацювання файлів, що може різко скоротити витрати на їх підтримку. Блок введення і коригування даних має місце в ЕЕС, якщо вона функціонує локально, тобто поза мережею передачі даних. У противному разі потреба в цьому блоці відпадає, бо в системах опрацювання облікових і звітних даних підтримується (коригується) необхідна інформація (баланс підприємства, звіт про прибутки і збитки тощо). Блок логічних висновків і діагнозу є головним, оскільки за його допомогою користувач повинен установити шлях виходу з економічної ситуації, що виникла. Для цього виконується фактор¬ний аналіз показників, результати якого потім використовуються для логічного аналізу й оформлення діагнозу. Діагноз можна одержати на підставі формалізації знань експертів за допомогою конструкції «якщо—то». Встановлення діагнозу необхідне для отримання правильного рецепту «лікування» підприємства. Тому, якщо вдалося довести хоча б одне правило «якщо—то», то це означає, що відомий перелік заходів, дій або процедур, які слід виконати для виходу з економічної ситуації , що створилася. Рецепти, як і діагнози, мають ієрархічний характер: кожному рівню діагнозу відповідає свій рецепт більш або менш загального характеру. Блок набуття знань пов’язаний із проблемою навчання та самонавчання системи. 8.2.2. Експертні системи внутрішнього аудиту на підприємстві Аудиторські експертні системи, відображаючи специфіку даного виду діяльності, на додаток до вже розглянутих блоків повинні забезпечити три види аудиторських перевірок: 1) аудит бухгалтерських і фінансових звітів з метою перевірки слушності їх складання; 2) аудит на відповідність установленим вимогам з метою перевірки слушності дій адміністрації (нарахування коштів на оплату праці, списання витрат) на підставі норм, стандартів і правил; 3) аудит господарської діяльності, або аудит ефективності роботи адміністрації, що складається з аналізу економіки підприємства і вироблення ефективної фінансової стратегії. Рис. 8.9. Склад експертної системи внутрішнього аудиту на підприємстві Останній вид аудиторської діяльності є ні чим іншим, як функ¬ціями економічної експертної системи, розглянутої раніше. Нагадаємо їх: а) розпізнавання економічної ситуації, що склалася, її аналіз, визначення діагнозу та найближчих цілей, досягнення яких забезпечить повернення до бажаної траєкторії розвитку виробництва; б) вироблення шляхів досягнення сформульованих цілей без урахування та з урахуванням резервів виробництва. Специфіка аудиторської діяльності визначає додатковий набір блоків в ЕЕС, пов’язаних з контрольними функціями. Склад експертної системи внутрішнього аудиту подано на рис. 8.9. Блоки бази даних, бази знань, діагнозу і вироблення рекомендацій мають ті самі засоби, що й зазначені раніше. Перевірювальні блоки (фінансової і бухгалтерської звітності, відповідності нормам і стандартам) базуються на спеціальних таблицях, що містяться у базах даних. Наприклад, таблиця перевірки достовірності балансу може мати таку форму: Показник, що порівнюється Показник, з яким здійснюється порівняння Форма 1, рядок 470, графа 3 Форма 2, рядок 790, графа 3 та 4 і т. ін. Форма 2, рядок 90, графа 3 Форма 1, сума рядків 480, 530, 770 Завершуючи опис загальних характеристик ЕЕС, слід звернути увагу на те, що вони допомагають під час прийняття рішень уникнути типових помилок, якими нерідко супроводжується практика управління: 1) підміна загального частковим, головного — другорядним, визначального — випадковим. Це особливо яскраво виражається в гіпертрофованому перебільшенні ролі одиничного чинника і пояснень за його допомогою стану підприємства; 2) хибність висновків за випадковою аналогією. Розумові висновки за аналогією нерідко приводять до важливих висновків, однак при цьому необхідно дотримуватися ряду логічних правил; 3) перебільшення ролі математики. Обмеженість математичних моделей спричиняється ілюзіями, що створюють видимість благополуччя. Будь-які розрахунки не в змозі охопити всі умови функціонування підприємства, тому математичні моделі можуть лише збагатити знання про процеси, що відбуваються, але не замінити їх. 8.3. ПРИКЛАДИ ВИКОРИСТАННЯ ЕКСПЕРТНИХ СИСТЕМ НА ПІДПРИЄМСТВАХ Експертні системи можуть використовуватися на підприємстві для вирішення різних задач (а не тільки суто економічних). Експертна система ХСОМ використовується на виробничих підприємствах. Вона розроблена в науково-дослідному комп’ю-терному центрі Карнегі Мелоун на замовлення корпорації DЕС. Основне призначення такої експертної системи — надання консультативних послуг під час вибору конфігурації комп’ютера конкретним замовником. Принцип дії системи такий: покупець вимагає комп’ютер відповідної якості з певним набором технічних характеристик. Такі вимоги формалізуються системою і на їх основі автоматично визначається точний набір провідників та модулів, а також апаратні засоби. На вхід системи при цьому відповідно до стандартних форм подаються вимоги замовника, а на виході формується набір комп’ютерних діаграм, які відображають логічні зв’язки між окремими компонентами того комп’ю¬тера, що його бажає купити замовник. У подальшому ці діаграми використовуються технічним персоналом, який здійснює безпосереднє складання комп’ютера. Система ХСОМ дозволяє фірмі DЕС щорічно заощаджувати близько $2 млн. Прикладом експертної системи, розробленої в СНД, є система РSY (розробник — московська фірма «САЙНТЕКС»). Ця система використовується керівниками підприємств, менеджерами, працівниками кадрових організацій та агенцій для здійс¬нення професійного та психологічного добору під час прийому на роботу, для аналізу міжособових відносин та визначення психологічної сумісності співробітників, а також для ведення БД по кадрах з урахуванням особистісних характеристик людей. Система дозволяє: 1) використовувати готові тести для професійно-психологіч-ного обстеження (до складу системи входять різноманітні тести, необхідні для визначення загального рівня розвитку, особистісних, ділових та інтелектуальних якостей обстежуваних, а також для визначення відхилень від психічної норми); 2) отримувати готові тестові характеристики за результатами обстеження; 3) проводити опрацювання результатів тестування, здійснювати добір найбільш прийнятних кандидатур на конкретні посади з урахуванням професійних та особистісних якостей; 4) створювати та редагувати тести, анкети, листи опитування; 5) здійснювати коригування питань, відповідей, шкал та умов проведення тестування, а також сортування та статистичне опрацювання підсумків обстежень. Система РSY є по суті гібридною системою, до складу якої, окрім бази знань (БЗ), входять досить великі за обсягом БД для збереження тестів та відомостей про кадри, а також процедури статистичного опрацювання. Знання досвідчених експертів-психологів використовуються у системі у вигляді конкретних логічних правил, застосування цих знань дозволяє отримувати текстову характеристику обстежуваних, яка ґрунтується на аналізі результатів різних тестів. Система РSY налічує понад 6 тисяч правил. В останній версії системи (3.0) БЗ дозволяє здійснювати формування найбільш прийнятних тестів для добору з конкретної спеціальності на основі професійно-психологічних вимог, що заздалегідь визначаються користувачем. Завдяки накопиченим знанням система РSY дозволяє досить швидко та з високою точністю визначати рівень розвитку особистісних якостей кандидатів на ту чи іншу посаду відповідно до вимог, що пред’являються до даної посади на основі норматив¬них документів. Система є досить поширеною в комерційних фірмах, а також в організаціях із соціальної адаптації безробітних. ІНТЕГРОВАНІ ІНФОРМАЦІЙНІ СИСТЕМИ УПРАВЛІННЯ ПІДПРИЄМСТВАМИ 9.1. ЗАГАЛЬНА ХАРАКТЕРИСТИКА СУЧАСНОГО СТАНУ ІНФОРМАЦІЙНИХ СИСТЕМ УПРАВЛІННЯ ПІДПРИЄМСТВАМИ Перехід України на ринкові форми розвитку сприяв тому, що останні декілька років були ознаменовані значним підвищенням інтересу до комп’ютерних систем, за допомогою яких можна забезпечити ефективне управління підприємством. Причому зростає попит саме на інтегровані системи управління — автоматизація окремої функції, як-от бухгалтерський облік або збут готової продукції, вважається вже пройденим етапом для багатьох підприємств. І хоча ринок подібних інтегрованих систем формується посту¬пово, досить часто можна зустріти в списку учасників тендера на вибір системи, наприклад, для середнього промислового підприємства (яких в Україні, як і в усьому світі, — переважна більшість), SAP/R3, Platinum, ПАРУС і «1С – підприємство» одночасно. Для розроблювачів і розповсюджувачів інтегрованих систем у США і Західній Європі існування такого списку — нонсенс. На більшості підприємств добре знають основних діючих осіб саме в тому сегменті ринку, що максимально відповідає діяльності конк¬ретного підприємства. Вибір здійснюється з двох—чотирьох систем одного або близьких класів. Інші — просто не розглядаються. Такий підхід значно спрощує саму процедуру вибору і знижує часові й грошові витрати підприємства, що, зрештою, сприяє прийняттю більш ефективного рішення. У наших умовах дуже важко відповісти на запитання, хто саме виграє подібний тендер: скоріше за все — ніхто, бо за детального розгляду забажається взяти ціну системи «1С – підприємство» і функціональні можливості SAP/R3, що в принципі немож¬ливо. Нинішній стан ринку комп’ютерних систем в Україні зумовлений передусім історичним розвитком українських систем, приходом західних розроблювачів і партнерів на ринок і активну експансію російських систем. Більшість інформаційних систем почала з’являтися в нашій країні на рубежі 90-х років, коли з отриманням більшої свободи у веденні бізнесу підприємства і фірми почали замислюватися про комп’ютеризацію. З об’єктивних причин ринкової економіки першими змогли виділити необхідні фінансові кошти підприємства торгівлі і сфери послуг. Промисловість значно відставала через більш тривалий цикл оборотності капіталу і багато інших причин. Саме тому практично всі системи почали розвиватися як облікові бухгалтерські системи. Багато з них продовжують залишатися суто обліковими, дозволяючи автоматизувати одну або декілька функцій підприємства, але не даючи цілісної картини для управління підприємством. Тільки одиничні розробники (а їх усього більше сотні), передбачаючи розвиток подій, віддали перевагу еволюційному якісному зростанню перед простим збільшенням продажу «коробкових» рішень, вкладаючи кошти в розвиток систем і науково-дос¬лідні роботи. Західні системи зазнавали складностей іншого масштабу. Перші спроби прорватися на український ринок, що здавався «багатим і багатообіцяючим», були зроблені на початку 90-х років. Спочатку були створені невеличкі представництва або підписані партнерські угоди з місцевими компаніями. Потім експансія набула більш масованого характеру, і на вітчизняні фірми і підприємства обрушилася вся міць типової західної рекламної кампанії. Незнайома, але дратівлива з одночасною обіцянкою пов¬ного добробуту, за умови вкладення 1—2 млн. доларів, кампанія мала певний успіх. Проте перші спроби впровадження цих систем показали, що реклама рекламою, але й працювати також варто вміти. І добре було б одночасно із західним програмним продуктом мати навчений персонал, провести локалізацію і налаштування системи на «дуже динамічні» вимоги законодавства і бухгалтерського обліку. Тому перші два—чотири роки були витрачені західними постачальниками на набуття досвіду і приведення систем у відповідність із місцевими вимогами. Не претендуючи на винесення якогось остаточного рішення про готовність тієї або іншої системи до всіх перипетій місцевого ринку, можна сказати, що перший етап адаптації частково або цілком пройдений практично всіма серйозними постачальниками, які вирішили спробувати щастя на просторах колишнього СРСР. Одночасно відбувається процес зближення вітчизняних і захі-д¬них систем, що успішно конкурують за право працювати на підприємствах. У табл. 9.1 поданий один із варіантів класифікації інформаційних систем управління підприємствами. Таблиця 9.1 ЗАГАЛЬНА КЛАСИФІКАЦІЯ ІНФОРМАЦІЙНИХ СИСТЕМ УПРАВЛІННЯ ПІДПРИЄМСТВАМИ Локальні системи Малі інтегровані системи Середні інтегровані системи Великі інтегровані системи Представники груп • 1С • БЭСТ • Инотек • ИНФИН • Инфософт • Супер-Менеджер • Турбо-Бухгалтер • Інфо-Бухгалтер • + більш як 100 систем • Concorde XAL • Exact • NS-2000 • Platinum • PRO/MIS • Scala • SunSystems • БОСС-Корпорація • Галактика/ ПАРУС • Ресурс • Еталон • JD Edwards (Robertson & Blums) • MFG-Pro (QAD/BMS) • SyteLine (СОКАП/ SYMIX) • MIRACLE V • SAP/R3 (SAP AG) • Baan (Baan) • BPCS (ITS/SSA) • Oracle Applications (Oracle) Усі наведені в таблиці системи можна умовно поділити на два великих класи: а) фінансово-управлінські і б) виробничі системи. 9.1.1. Фінансово-управлінські системи Фінансово-управлінські системи включають підкласи локальних і частково малих інтегрованих систем. Такі системи призначені для ведення обліку по одному або декількох напрямах (бухгалтерія, збут, облік кадрів і т. ін.). Системами цієї групи може скористатися практично будь-яке підприємство, яке потребує управління фінансовими потоками й автоматизації облікових функцій. Такі системи по багатьох критеріях є універсальними, хоча найчастіше розроблювачі пропонують рішення галузевих проблем, наприклад, основні засоби, нарахування податків або управління персоналом з урахуванням специфіки регіонів. Універсальність призводить до того, що цикл упровадження таких систем невеличкий, іноді можна скористатися «коробковим» варіантом, достатньо для цього купити програму і самому закласти її в персональний комп’ютер. Фінансово-управлінські системи (особливо системи російських розроблювачів) значно більш гнучкі в адаптації до потреб конкретного підприємства. Часто пропонуються «конструктори», за допомогою яких можна практично цілком перекроїти вхідну систему, самостійно або за допомогою постачальника встановити зв’язок між таблицями баз даних або окремими модулями. Хоча загальна конфігурація систем може бути досить складною, практично всі фінансово-управлінські системи спроможні працювати на персональних комп’ютерах у звичайних мережах передачі даних Novell Netware або Windows NT. Вони спираються на технологію виділеного серверу бази даних (file server), що характеризується високою завантаженістю мережних каналів для передачі даних між сервером і робочими станціями. Тільки окремі із запропонованих систем такого класу були розроблені для промислових баз даних (Oracle, SYBASE, Progress, Informix, SQL Server). Використовувалися переважно більш прості засоби розробки Clipper, FoxPro, dBase, Paradox, що, як правило, дають збої на складних конфігураціях мережі і при збільшенні обсягів опрацьовуваних даних. 9.1.2. Виробничі системи Виробничі системи включають підкласи середніх і великих інтегрованих систем. Ці системи передусім призначені для управління і планування виробничого процесу. Облікові функції, хоч і глибоко опрацьовані, виконують допоміжну роль, та іноді неможливо виділити модуль бухгалтерського обліку, бо інформація в бухгалтерію надходить автоматично з інших модулів. Виробничі системи значно більш складні у впровадженні (цей цикл може займати від шести—дев’яти місяців до півтора і більше років (див. табл. 9.2). Це зумовлено тим, що система задовольняє потреби усього виробничого підприємства, що потребує значних спільних зусиль працівників підприємства і постачальника програмного забезпечення. Виробничі системи часто орієнтовані на одну або декілька галузей і/або типів виробництва: серійне складальне (електроніка, машинобудування), дрібносерійне і дослідне (авіація, важке машинобудування), безперервне (металургія, хімія, нафто- і газовидобуток). Мають місце також різноманітні типи організації самого виробничого процесу. Наприклад, для дискретного виробництва можливі: а) циклічне повторне виробництво (repetitive manufac-turing) — планування виконується на певний строк (квартал, місяць, тиждень); б) виробництво за замовленнями (make-to-order) — планування тільки при надходженні замовлення; в) роз-робка за замовленнями (engineering-to-order) — самостійна розробка кожного нового замовлення з таким виробництвом; г) ви¬робництво на склад (manufacture-to-stock); д) змішане виробництво (mixed mode manufacturing) — для виробництва кінцевого продукту використовується кілька типів організації виробничого процесу. Така спеціалізація відбивається як у наборі функцій системи, так і в існуванні бізнес-моделей даного типу виробництва. Наявність вмонтованих моделей для певних типів виробництва відрізняє виробничі системи одну від одної, у кожній із цих систем є глибоко розроблені напрями і функції. Таблиця 9.2 ВПРОВАДЖЕННЯ, СПІВВІДНОШЕННЯ ВИТРАТ І ВАРТІСНІ ОЦІНКИ Показник Локальні системи Малі інтегровані системи Середні інтегровані системи Великі інтегровані системи Впровад- ження Просте, коробковий варіант Поетапне або коробковий варіант Тільки поетапне Більш як 6—9 місяців Поетапне, складне Більш як 9—12 місяців Функціо- нальна повнота Облікові системи (за напрямом) Комплексний облік управління фінансами Комплексне управління: облік, управління виробництвом Співвідношення витрат ліцензія/ впровадження/ установка/ 1/0,5/2 1/1/1 1/2/1 1/ 1—-5/ 1 Орієнтовна вартість 5—50 тисяч USD 50—300 тисяч USD 200—500 тисяч USD 500 тисяч, > 1 мільйона USD Виробничі системи за багатьма параметрами значно більш жорсткі, ніж фінансово-управлінські. Виробниче підприємство повинне, насамперед, працювати як добре налагоджений годинник, де основними механізмами управління є планування й оптимальне управління виробничим процесом, а не врахування кількості рахунків-фактур за якийсь період. Ефект від упровадження виробничих систем стає суттєвим на верхніх рівнях управління підприємством, коли видно усю взаємозалежну картину роботи, що включає планування, закупівлі, виробництво, запаси, продаж, фінансові потоки та багато інших аспектів. При збільшенні склад¬ності й широти охоплення функцій підприємства системою зростають вимоги до технічної інфраструктури і комп’ютерної платформи. Всі, без винятку, виробничі системи розроблені за допомогою промислових баз даних. Здебільшого використовується технологія «клієнт—сервер», що припускає поділ опрацювання даних між виділеним сервером і робочою станцією. Технологія «клієнт—сервер» виправдовує себе під час опрацювання великих обсягів даних і запитів, оскільки дозволяє оптимізувати інтенсивність передачі даних комп’ютерною мережею. Основу кожної виробничої системи становлять рекомендації щодо управління виробництвом. На даний момент існує декілька груп таких рекомендацій (стандартів). Вони являють собою опис насамперед загальних правил, за якими мають здійснюватися планування і контроль різноманітних стадій виробничого процесу: потреб у сировині, закупівель, завантаження потужностей, розподіли ресурсів тощо. Вихідним стандартом середини 60-х ро¬ків був стандарт MRP (Material Requirements Planning), що включав тільки планування матеріалів для виробництва. Цей стандарт був розширений до MRP-II (Manufacturing Resource Planning). MRP-II дозволяв планувати усі виробничі ресурси підприємства (сировина, матеріали, устаткування тощо). Подальшим розвитком став стандарт ERP (Enterprise Resource Planning), що дозволив об’єднати всі ресурси підприємства, в такий спосіб збільшуючи керованість замовленнями, фінансами тощо. Зараз практич¬но усі виробничі системи відповідають рекомендаціям стандар- ту ERP. Нарешті, останній за часом стандарт CSRP (Customer Synchro¬nized Resource Planning) регламентує також взаємодію з клієнтами: оформлення наряду-замовлення, технічне завдання, підтримка замовника на місцях тощо. Таким чином, якщо MRP, MRP-II, ERP орієнтувалися на внутрішню організацію підприємства, то CSRP вийшов «за межі» підприємства і включив у себе повний цикл — від проектування майбутнього виробу з урахуванням вимог замовника до гарантійного і сервісного обслуговування після продажу. Рис. 9.1. Ефективність застосування систем. Співвідношення вартості / якості На підставі викладеного вище можна дати такі висновки (рис. 9.1): 1) Для малих підприємств, торгових фірм і компаній, що надають послуги, за співвідношенням ціна/якість найбільше підійдуть фінансово-управлінські системи, оскільки основні розв’я¬зувані ними задачі — це бухгалтерський облік, управління складами продукції, управління кадрами. Фінансово-управлінські системи також можуть бути використані на невеличких виробничих підприємствах, процес виробництва на яких не є складним. 2) Для малих і середніх виробничих підприємств, із невеликою кількістю юридичних осіб і взаємозв’язків найефективнішими будуть середні інтегровані системи або прості конфігурації інтегрованих систем. Для таких підприємств основним кри¬терієм є власне управління виробництвом, хоча облікові задачі залишаються важливими. 3) Для великих холдингових структур, фінансово-промис-лових груп, що управляють компаніями, для яких першоряд- не значення має управління складними фінансовими потоками, трансферними цінами, консолідація інформації, у багатьох випадках найприйнятнішими будуть великі інтегровані системи. Ці системи, маючи можливості для рішення проблем управління виробництвом, можуть задовольняти увесь комплекс вимог великого холдингу. Для автоматизації гігантських підприємств у світовій практиці також часто використовуються великі, середні і на¬віть дрібні інтегровані системи в комплексі, коли на рівні управління всією структурою працює, наприклад, SAP/R3, а виробничі компанії користуються пакетами середнього класу. Створення електронних інтерфейсів спрощує взаємодію між системами і дозволяє уникнути подвійного ведення даних. Відповідно до світової практики при необхідності більш тонкого аналізу декількох систем одного або близьких класів велике значення надається етапу вибору. Кожний проект у галузі автоматизації, який повинен розглядатися підприємством як стратегічна інвестиція засобів, має окупитися за рахунок удосконалення управлінських процесів, підвищення ефективності виробництва, скорочення витрат. У виборі правильного рішення повинно бути зацікавлене передусім керівництво підприємства. Такий проект треба ставити на один рівень із придбанням, наприклад, нової виробничої лінії або будівництвом цеху. Насамперед підприємству необхідно визначити, а що ж, власне, очікується від нової системи: яку функціональну галузь і які типи виробництва вона повинна охоплювати, яку технічну платформу використовувати, які звіти готувати. Під час вибору тієї або іншої системи для підприємства необхідно брати до уваги, що автоматизація заради автоматиза- ції не має сенсу. Основною метою повинна бути якість управління. Найкраща у світі комп’ютерна система не виконає ро- лі чарівної палички, що магічно вирішує всі накопичені проблеми. Будь-яка із систем — тільки механізм для підвищення ефективності управління, прийняття правильних стратегічних і тактичних рішень на підставі своєчасної і достовірної інформа- ції, що видається керівному персоналу за допомогою інформаційної системи. Розгляньмо детальніше деякі із систем, перелік яких наведено в табл. 9.1. 9.2. БАЗОВА КОНЦЕПЦІЯ І ОСНОВНІ ФУНКЦІОНАЛЬНІ КОМПОНЕНТИ ІНТЕГРОВАНОЇ ІНФОРМАЦІЙНОЇ СИСТЕМИ «ГАЛАКТИКА» В умовах ринкової економіки основною функцією будь-якого підприємства (організації) є випуск продукції (надання послуг) з метою отримання економічних результатів від реалізації цієї продукції. Центральне місце серед задач управління з цього погляду займає отримання прибутку від результатів господарської діяльності підприємства (організації). Придбання засобів і знарядь вироб¬ництва, виробничі процеси і організаційні заходи, як правило, передують прибуткам, що отримуються завдяки господарській діяльності. Тому важливо зуміти зіставити матеріальні, трудові і фінансові потреби з існуючими ресурсами. Процес управління підприємством (організацією), що має метою отримання прибутку, можна відобразити такою класичною схемою (рис. 9.2): Рис. 9.2. Схема управління підприємством Як бачимо з наведеної схеми, рух від поставлених цілей до результату є багатоступінчастим. Він вимагає оперативного коригування первинного плану дій залежно від досягнутих проміжних результатів. Загалом кінцевий успіх підприємства залежить від багатьох чинників, частина з яких не піддається суворій формалізації. Склад цих чинників подано на рис. 9.3. Рис. 9.3. Чинники комерційного успіху З наведеної схеми випливає, що система, яка автоматизує збір, підготовку та опрацювання інформації, є лише однією з необхідних складових, що визначають кінцевий успіх діяльності підприємства. Однак уже сьогодні очевидно, що найбільшого успіху в діловому світі досягають ті фірми і корпорації, які спроможні швидше за всіх зібрати інформацію, опрацювати, проаналізувати її і на основі цього ухвалити рішення, тобто ті, які використовують сучасні інформаційні технології. Дедалі більше керівників розуміють, що максимально ефективною автоматизованою системою є та, яка охоплює всі взаємопов’язані багатогранні бізнес-процеси, всі аспекти всередині господарської діяльності і поза нею, тобто інтегровані автоматизовані інформаційні системи. 9.2.1. Склад і характеристики ІС «Галактика» Результатом роботи корпорації «Галактика» став випуск у квітні 1995 р. на ринок програмних засобів комплексу «Галактика», яка до теперішнього часу встигла пройти випробування на більш ніж 400 підприємствах і продовжує інтенсивно розвиватися. Розв’язання всього комплексу задач, на який орієнтований комплекс «Галактика», забезпечується чотирма функціональними контурами: 1) контур адміністративного управління; 2) контур оперативного управління; 3) контур управління виробництвом; 4) контур бухгалтерського обліку. Модульний принцип побудови комплексу «Галактика» припускає як ізольоване використання окремих програмних модулів, так і довільні комбінації їх, залежно від виробничо-економічної необхідності. На рис. 9.4 подана структура функціональних складових ІС «Галактика». Пунктирними лініями означені програмні вироби, що перебувають у стадії розробки мережних інтегрованих версій. Модуль «Управління документообігом» винесений за межі контура адміністративного управління, оскільки забезпечує взаємодію всіх користувачів ІС «Галактика». В основі моделі побудови інформаційної системи «Галактика» лежать такі концептуальні положення: 1. Метою діяльності будь-якого підприємства (організації) є отримання прибутку від підсумків своєї діяльності. 2. Усі взаємодії між юридичними суб’єктами (підприємствами, організаціями) зводяться до укладання і реалізації угоди. При цьому одна із сторін є продавцем, інша — покупцем. Предметом угоди може бути товарно-матеріальна цінність (ТМЦ), робота, послуга або їх комбінація. 3. Під час здійснення будь-якої господарської операції формується документ, що підтверджує її здійснення (операційний документ). Сукупність операційних документів утворюють документообіг підприємства. 4. Операційні документи належать до одного з двох класів. Перший клас документів — документи-підстави, тобто документи, що регламентують операції між юридичними особами. До цього класу належать прості й багатоетапні договори, рахунки, рахунки-фактури, контракти, вимоги, гарантійні листи тощо. Документи-підстави додатково класифікуються за: Рис. 9.4. Функціональна структура ІС «Галактика» • життєвим циклом документа. Документ може мати один із трьох станів: такий, що оформляється, що виконується, закритий (виконаний); • видом розрахунків (з погляду багатовалютності): гривневий розрахунок, валютний, гривнево-валютний. Другий клас документів — супровідні документи, тобто опе-раційні документи, що відображають суть операцій, які фактично виконуються. Всі супровідні документи можна поділити на дві групи: а) документи, що підтверджують переміщення товарно-мате-ріальних цінностей або операції виконання робіт, послуг. До них належать накладні різних видів, складські ордери, акти на вико-нання робіт (послуг); б) фінансові супровідні документи, які підтверджують опера-ції переміщення готівкових і безготівкових фінансових коштів. До них належать банківські та касові документи. Супровідні документи зазвичай пов’язані з документами-підставами. 5. Робота користувачів контура оперативного управління ІС «Галактика» полягає в реєстрі документів, що входять, або формуванні вихідних документів-підстав і супровідних докумен-тів, які підтверджують виконання господарських операцій. За чітко налагодженої організаційної схеми функціональної експлуатації інформаційної системи «Галактика» кожний вико-навець виконує обумовлені для нього інструкцією дії, отримуючи інформацію в обсязі, необхідному і достатньому для здійснення своїх посадових обов’язків. Завдяки роботі всіх користувачів комплексу відбувається на-повнення бази даних підприємства (організації) оперативною інформацією про хід виконання конкретних господарських опе-рацій, що пов’язані з різними напрямами діяльності. Опрацю-вання оперативної інформації дозволяє, з одного боку, проаналі-зувати взаємовідносини з контрагентом на основі відомостей про рух матеріальних цінностей, послуг, робіт і фінансових коштів, а з іншого — оцінити ефективність роботи підприємства у різних напрямах господарської діяльності. При цьому забезпечуються: • принцип однократного введення в БД інформації і, як наслі-док, відсутність дублювання функцій користувачів, упорядку-вання документообігу; • легкість контролю на коректність та цілісність даних, персо-ніфікація дій користувача; • контроль за регламентом виконання господарських опера-цій; • швидка перебудова системи, зміна експлуатаційної схеми системи за зміни бізнес-процесу (технології управління). Адміністрація підприємства (організації), використовуючи для управління виробничими процесами ІС «Галактика», отримує можливість: • оперативного одержання достовірної інформації про поточ-ну діяльність підприємства; • оперативного управління фінансами; • контролю за ходом виконання договірних відносин; • контролю взаємних зобов’язань; • контролю та управління матеріальними, трудовими і техніч-ними ресурсами; • формування і контролю бізнес-плану; • планування та обліку виконання внутрішнього бюджету. 9.2.1.1. Налагодження інформаційної системи «Галактика» Налагодження системи «Галактика» передбачає такі дії (ета-пи): • налагодження прав доступу для конкретних користувачів до програмних модулів виконується системним адміністратором пі-сля установки «Галактики». У процесі настроювання системний адміністратор може ви-значити для кожного користувача ім’я в системі, пароль і права доступу до модулів і таблиць бази даних. При вході користувача в систему елементи меню модулів, закритих для даного користу-вача, не висвічуються на екрані. При обмеженні прав доступу до таблиць бази даних користувач може бути позбавлений можли-вості модифікації чи вилучення яких-небудь даних або навіть можливості перегляду їх; • настроювання класифікаторів, каталогів і довідників систем; • настроювання параметрів програми корпоративного між-офісного обміну (настроювання адресних даних кожного офісу, ознаки вибірки пошти, типу вирішення міжмережних конфліктів тощо); • настроювання структури корпорації з метою консолідації баз даних філій; • настроювання вхідних і вихідних банківських документів для організації електронного обміну з банком; • настроювання системних даних і параметрів користувача. Етап інформаційного настроювання системи «Галактика» є обов’язковим перед початком її практичного застосування. У процесі настроювання наповнюються інформаційні масиви, що використовуються далі всіма модулями, які входять до комплек-су, і визначаються параметри функціонування системи. 9.2.2. Контур адміністративного управління 9.2.2.1. Управління маркетингом Під терміном «маркетинг» звичайно розуміють одну із систем управління підприємством, що ґрунтується на комплексному об-ліку і прогнозуванні процесів, які відбуваються на ринку, і спря-мована на отримання максимального прибутку від виробництва і збуту товарів та послуг. Серед основних можливостей модуля «Управління марке-тингом» назвемо такі: • ведення розширеної інформації про товари, типові послуги; • реєстрація та опрацювання контактів з потенційними поста-чальниками; • управління каналами збуту; • аналіз ринку рекламних послуг, планування рекламних кампаній, розміщення реклами, аналіз ефективності рекламних вкладень; • збір і опрацювання незалежних відгуків; • ведення досьє на фірми-конкуренти і товари-аналоги; • аналіз ринку пропозицій, управління ціновою політикою; • контроль «життєвого» циклу товарів, аналіз сегментів рин-ку; • реєстрація «серійного» продажу, облік рекламацій, гарантій; • маркетинговий аналіз збуту в розрізах: по каналах збуту, товарах, групах товарів (послуг), напрямах реалізації. Технологію вирішення маркетингових задач в ІС «Галакти-ка» можна подати такою схемою (рис. 9.5): Рис. 9.5. Процес вирішення маркетингових задач 9.2.2.2. Фінансове планування Модуль «Фінансове планування» призначений для складан-ня плану інвестицій капіталу підприємства і пов’язаних з цим ви-трат, а також для проведення контролю та аналізу ходу виконан-ня складеного плану. Передбачається така схема використання модуля: 1. Розробка структури фінансового плану підприємства (іє-рархія статей надходжень і витрат). 2. Складання фінансового плану підприємства в розрізі на-прямів діяльності як плану руху коштів по періодах планування в розрізі ієрархії статей витрат і надходжень. 3. Детальний аналіз складеного плану в розрізі напрямів діяльності і по підрозділах за весь період планування або за певний відрізок часу на базі отримання безлічі текстових і графічних звітів. 4. Узагальнення фінансових планів для окремих напрямів дія-льності в єдиний фінансовий план підприємства. 5. Аналіз того, як впливає зміна курсу базової валюти і зміна прогнозованих витрат, а також надходжень по статтях фінансового плану на базі таблиці прогнозу курсу базової валюти і таблиці прогнозу змін витрат і надходжень по статтях фінансового плану. 6. Реєстрація ходу виконання фінансового плану і «рознесен-ня» надходжень і витрат по напрямах діяльності і по підрозділах. 7. Контроль ходу виконання фінансового плану за минулий період на базі отримання звітів типу «план/факт» з урахуванням впливу реальної зміни курсу базової валюти на раніше заплано-вані суми. 8. Аналіз ходу виконання складеного плану по напрямах дія-льності і по підрозділах на базі отримання великої кількості тек-стових і графічних звітів. 9.2.2.3. Господарське планування, управління проектами Програмний модуль «Господарське планування, управлін-ня проектами» призначений для вирішення завдань управління діяльністю підприємства з використанням комп’ютерної мережі через проведення планування робіт над проектами з подальшим контролем виконання затверджених планів. За допомогою модуля вирішуються такі завдання: 1. Складання планів підрозділів та визначення окремих вико-навців з огляду на напрями діяльності в режимі мережного вико-ристання системи, яка передбачає велике число користувачів. 2. Планування необхідних ресурсів для виконання накресле-них планів. 3. Узагальнення планів у єдиному господарському плані під-приємства, корпорації. 4. Ув’язка робіт в єдиний календарно-сітьовий графік. 5. Формування планів робіт по виконавцях на будь-який пері-од. 6. Реєстрація перебігу виконання планів, ведення журналу здійснюваних заходів. 7. Контроль виконання планів адміністрацією. 8. Ведення документообігу в аспекті структури господарсько-го плану. До найважливіших властивостей модуля слід віднести: • багатоплановість, поєднання декількох планів у єдиний ка-лендарно-сітьовий графік, підтримка ієрархії планів, ведення єди-ного плану корпорації і здійснення контролю його виконання за наявності віддалених філій, управління територіально-розподіле-ними проектами; • розмежування доступу на рівні окремих планів або їх частин, можливість «рознесення» по окремих робочих місцях мережі питань складання планів, реєстрації і контролю ходу їх виконання; • планування ресурсів для виконання плану загалом і його окремих пунктів, отримання графіка розподілу потреб у ресур-сах, необхідних для виконання плану по періодах планування. Приклад використання модулів фінансового і господарського планування в управлінні розподіленими проектами наведено на схемі (рис. 9.6). Фінансовий план і структура господарського плану формую-ться в головній фірмі. При цьому в плані закладаються схема фі-нансування і схема повернення коштів по періодах планування, календарно-сітьовий графік проектів. У фірмі-філії формуються плани виконання тих частин за-гального проекту, якими займається фірма-філія, провадиться ре-єстрація перебігу виконання робіт. Зв’язок баз даних здійснюється із застосуванням програми Соrро. Як засіб доставляння інформації використовується елект-ронна пошта, модем або магнітний носій інформації. Після онов-лення бази даних, періодичність якого визначається керівником проекту, в головній фірмі бачать загальний календарно-сітьовий графік виконання проекту. Отримуючи звіти про хід виконання господарського плану, керівник може контролювати реалізацію проекту й оперативно реагувати на відхилення в термінах вико-нання окремих робіт, відстежувати витрати і надходження. Рис. 9.6. Схема використання модулів планування Примітка: АРМ — автоматизоване робоче місце 9.2.2.4. Фінансовий аналіз Реалізація програмного модуля «Аналіз фінансової і госпо-дарської діяльності» в контурі адміністративного управління системи «Галактика» має на меті забезпечити керівника набо-ром наочних графічних і текстових звітів для швидкого огляду господарсько-фінансового стану підприємства (групи консолідо-ваних підприємств) і прийняття управлінських рішень. Дані для аналізу — це результати роботи оперативних підроз-ділів, що пройшли бухгалтерське опрацювання (синтетична й аналітична інформація по рахунках бухгалтерського обліку). На-копичена інформація розглядається в динаміці з можливістю урахування індексу цін. Аналіз господарсько-фінансової діяльно-сті підприємства провадиться на основі типових форм ( «Баланс підприємства», «Звіт про фінансові результати» та інші), показ-ників ефективності господарсько-фінансової діяльності підпри-ємства і внутрішніх звітів підприємства. Програмний модуль орієнтований передусім на фінансового директора, головного бухгалтера, фінансового менеджера / аналі¬тика, співробітників відділу планування підприємства. При бажанні можна створювати звіти для податкових органів, потенційних партнерів та інвесторів. Модуль реалізується здебільшого у таких процесах: • вертикальний аналіз (структура) типових форм звітності в будь-якому з накопичених моментів часу; • горизонтальний аналіз (динаміка) типових форм звітності в будь-якому з накопичених моментів часу; • вертикальний і горизонтальний аналіз типових форм звітно-сті відносно вибраного базового моменту часу; • аналіз динаміки і структури показників господарсько-фінан-сової діяльності підприємства (оцінка майнового стану, ліквідно-сті, фінансової стійкості, ділової активності, рентабельності, ста-новище підприємства на ринку цінних паперів); • аналіз динаміки перевищення або заниження показниками господарсько-фінансової діяльності значень, що рекомендують- ся, дозволяє зробити висновок про можливе погіршення або по- ліпшення господарсько-фінансового стану підприємства, показує небезпечне або нераціональне співвідношення господарсько-фі-нансових коштів підприємства; • розрахунок провадиться по вибраному консолідованому звіту, тобто по підгрупі підприємств, що входить до повної групи консолідованих підприємств; • набір розрахункових форм відповідає вибраному плану ра-хунків і, таким чином, може задовольнити різних споживачів аналітичної інформації, включаючи іноземних партнерів; • усі розраховані значення подаються і в текстових і в графіч-них звітах; • аналіз здійснюється з тією мірою деталізування, яку під-тримують інші контури «Галактики»; • розрахунки провадяться у всіх валютах, інформацію по кур-сах яких має в своєму розпорядженні «Галактика», причому су-ми всіх операцій перераховуються за курсом відповідної валюти на день операції; • створення і перегляд звітів, похідних від типових форм, до-зволяють групувати і співвідносити розраховані значення прак-тично за будь-якою методикою фінансового менеджменту; • розробка будь-яких внутрішніх звітів підприємства в термі-нах мови проектування бухгалтерських та економічних розра-хунків «Галактики» дозволяє скористатися всіма переліченими вище можливостями модуля з метою отримання управлінської інформації. 9.2.2.5. Облік і управління кадрами Програмний модуль «Облік і управління кадрами» призна-чений для: • автоматизації процесу ведення особових справ працівників; • планування і управління штатним розкладом і резервом на заміщення посад; • планування і обліку робочого часу працівників; • для отримання звітів по кадровій інформації стосовно пра-цівників підприємства. Дані, що зберігаються, повністю охоплюють особисту картку (форма NТ-2), затверджену постановою № 94 Держкомстату СРСР від 28.06.90, типову анкету, а також містить багато іншої інформації. На рис. 9.7 подана схема функціонування модуля, в якій пока-заний взаємозв’язок задач, що вирішуються системою, та інфор-мація в базі даних. Показано також взаємодію і з іншими моду-лями комплексу «Галактика». Особова справа працівника складається з дев’яти розділів, що містять близько 150 показників. Розділ «Анкетні дані» дозволяє сформувати анкету з необхідним набором запитань. Крім того, до особової справи можна «підшити» довільну кількість додатків, що містять текстову (автобіографія, характеристики тощо), графічну (фото) та іншу необхідну інформацію. Управління штатами забезпечує складання штатного розпису підприємства з описом основних характеристик робочих місць. За необхідності можна завести додаткові характеристики, зміст яких визначається користувачем (вимоги до кваліфікації, освіти, віку, посадові інструкції, оснащення робочого місця та ін.). Усі призначення і переміщення виконуються з огляду на штатний розпис. Один працівник може обіймати кілька ставок, у тому числі неповних. По кожному робочому місцю можна скласти перелік працівників, які становлять резерв для заміщення даної посади. Рис. 9.7. Схема функціонування модуля обліку та управління кадрами Облік робочого часу забезпечує ведення планового і фактич-ного табелів обліку робочого часу; інтегровано з відпустками, лікарняними, призначеннями і переміщеннями. На одного працівника можна вести кілька табелів одночасно по одному на кожну ставку, що обіймається. Засоби підготовки звітів надають можливість гнучкого наст-роювання вихідних документів на потреби конкретного підпри-ємства. Створення звіту включає в себе визначення правил від-бору працівників, дані про які відбиватимуться у звіті, порядок їх сортування і вибір форми вихідного документа. Користувач може створити свій власний звіт на доповнення до тих, що вже є, і включити його до списку стандартних звітів для подальшого використання. Модуль обліку та управління кадрами передбачає гнучкі за-соби для адаптації до різних вимог: • склад і структура каталогів повністю визначаються потре-бами підприємства, користувач може створювати власні каталоги для заповнення анкет і додаткових характеристик робочих місць; • анкета дозволяє вводити довільні, не передбачені програ-мою дані про працівника і використовувати їх при відборі й сор-туванні записів, що виводяться у звіт; • додатки дозволяють зберігати довільну додаткову інформа-цію про працівника — як текстову, так і графічну; • склад наявних звітів легко розширюється заданням правил відбору співробітників, дані про яких відображатимуться у звіті, і порядку їх сортування. Форми вихідних документів проектуються за допомогою текстового редактора. Модуль обліку та управління кадрами може бути встановлено як у локальному варіанті, коли вся робота виконується на одному комп’ютері, так і в мережному варіанті, коли робота над одними й тими самими даними може виконуватися на кількох комп’ютерах одночасно, що дозволяє гнучко розподіляти обов’язки між працівниками відділу кадрів та іншими споживачами кадрової інформації. Модуль обліку та управління кадрами працює спільно з моду-лями «Зарплата» і «Управління документообігом» 9.2.2.6. Управління документообігом Програмний модуль «Управління документообігом» при-значений для обліку, зберігання й опрацювання документів та облікових карток паперових документів (договорів, листів, нака-зів, протоколів нарад тощо) в електронній формі, а також для ор-ганізації спілкування користувачів під час вирішення виробничих задач (рис. 9.8). Документи, що входять у документообіг, можуть бути отримані скануванням паперових документів, електронною поштою, можуть бути підготовлені за допомогою різних текстових редакторів. Рис. 9.8. Схема документообігу Модуль «Управління документообігом» надає користувачеві такі можливості: • створення і ведення номенклатури справ фірми; • створення повнотекстних документів; • створення класифікації документів і використання її в про-цесі роботи; • ведення стадій опрацювання документів і контроль вико-нання документів; • пошук документів по формальних полях, привласнених да-ному документу; • просування документів маршрутом опрацювання; • масова розсилка документів у підрозділи; • реєстрація (постановка на облік) звітів системи «Галакти-ка» як документів; • виведення на екран списку всіх врахованих документів, пов’я¬заних з документами-підставами системи «Галактика» (наприклад, рахунками за продані товари або послуги) і напрямами робіт господарського плану; перегляд будь-якого з вказаних документів. Зв’я¬зок з документами-підставами вста-новлюється користувачем. 9.2.3. Контур оперативного управління До контуру оперативного управління віднесені задачі, безпо-середньо пов’язані з реалізацією виробничих планів підприємст-ва. Серед цих задач можна виділити як актуальні для всіх типів організацій (постачання, складський облік), так і характерні тіль-ки для торгових організацій (операції з консигнаційним товаром, роздрібна торгівля). Схема інформаційних потоків контуру оперативного управ-ління наведена на рис. 9.9. 9.2.3.1. Управління закупівлею (матеріально-технічне постачання) Стандартні функції підрозділу, що відповідає за закупівлю по-трібних підприємству товарів і матеріалів, звичайно передба- чають ведення картотеки пропозицій потенційних постачальни-ків, відстеження вимог (заявок) інших підрозділів на придбання, складання плану закупівлі відповідно до укладених договорів і довгострокових контрактів, вибір конкретного постачальника і формування замовлення на постачання, реєстрацію документів, на основі яких провадиться закупівля (рахунки, договори, конт-ракти, гарантійні листи), оформлення довіреності на отримання, розподіл матеріальних цінностей по складах, контроль стану до-говорів і платіжних документів на придбання (сплачено/не спла-чено/прострочено), отримання різних звітів щодо номенклатури, яка відстежується, партій, груп і систем класифікації, які викорис¬товуються. Рис. 9.9. Схема інформаційних потоків контуру оперативного управління У системі «Галактика» функції з відстеження пропозицій постачальників, планування закупівлі і вибору постачальника можуть бути виконані засобами програмного модуля «Управління маркетингом». Отримання і відстеження заявок на придбання забезпечується модулем «Управління документообігом». Крім того, заявки на постачання продукції можна вести в модулі «Управління закупівлею», використовуючи як заявки документи-під¬стави, що перебувають у стані таких, що «оформлюються». Для контролю взаєморозрахунків з постачальниками рекомендується використовувати модуль «Постачальники, отримувачі». Безпо-середньо в модулі «Управління закупівлею» зосереджені операції по роботі з конкретними документами на придбання. Внаслідок глибокої інтеграції модулів, що входять до системи «Галактика», та наявності єдиної бази даних усі відомості, не-обхідні для оформлення документів-підстав, накладні й довіреності можуть бути введені шляхом вибору з існуючих таблиць бази даних. Підключення потрібної таблиці (класифікатора, довідника) в момент заповнення тієї або іншої графи документа забезпечується автоматично. За відсутності в таблиці необхідних даних вони можуть бути введені без виходу з режиму оформлення поточного документа. Інтеграція модуля «Управління закупівлею» зі складським обліком і плануванням виробництва дозволяє в модулі «Складський облік» відстежувати встановлені рівні нор¬мативних запасів (матеріалів, комплектуючих), виявляти дефіцит і продукцію, що не користується попитом (неліквіди). До особливостей модуля слід віднести: • використання в документах на закупівлю як товарних, так і нематеріальних позицій (послуг); • облік партій товарів, що закупаються, відстеження термінів зберігання, термінів дії ліцензій і сертифікатів; • підтримка різних валют і міжнародної закупівлі; • облік митних зборів, транспортних та інших витрат при об-численні облікової вартості конкретних виробів, що закупають-ся; • облік повернення за рекламацією; • автоматизований розподіл товарів по складах; • автоматичне формування прибуткових складських ордерів по групі накладних; • формування платіжних документів на оплату за документа-ми-підставами; • формування довіреності на отримання матеріальних ціннос-тей; • отримання відомостей про документи-підстави по вибраних контрагентах за допомогою «картки постачальника»; • повна інтеграція з модулем «Постачальники, отримува-чі»; • відображення в бухгалтерському контурі всіх операцій із за-купівлі матеріальних цінностей і послуг за допомогою механіз¬му типових господарських операцій. Модуль формує такі стандартні звіти: • звіти про закуповувані товари і послуги (номенклатура, постачальники, групи, партії, зовнішня класифікація); • звіти про зареєстровані прибуткові та сформовані повернені накладні; • звіт про стан замовлень (документів-підстав, що виконують-ся) на закупівлю; • реєстри документів-підстав і накладних; • звіт про невідповідності в документах на закупівлю. 9.2.3.2. Управління продажем (збутом) Інтерфейс користувача програмного модуля «Управління продажем» реалізовано в «Галактиці» аналогічно інтерфейсу модуля «Управління закупівлею». Новим елементом модуля «Управління продажем» є функція формування відпускних цін. Програмний комплекс «Галактика» дозволяє створити і підтри-мувати довільну кількість різних прайс-листів. Так, можна мати окремі прайс-листи для великооптової та дрібнооптової торгівлі, для роздрібного продажу, для виділених груп товарів і послуг тощо. Прайс-лист можна формувати вручну або автоматично, розраховуючи передбачувану ціну реалізації додаванням до об-лікової ціни ТМЦ описаної користувачем гнучкої системи торго-вих націнок (знижок) і податків. До особливостей реалізації цього модуля належать такі: • довільна кількість позицій у документі на продаж; • облік типу оподаткування при оформленні документа; • можливість гнучкої зміни цін шляхом оперативного корек-тування прайс-листів; • використання в документах на продаж як товарних, так і не-матеріальних позицій (послуг); • автоматичне формування номерів документів на продаж з можливістю їх коригування користувачем; • можливість формувати документ у національній або будь-якій із зареєстрованих у системі валют з розрахунком гривневого або валютного еквівалента відповідно; • можливість коригування курсу валюти безпосередньо в про-цесі формування документа; • можливість продажу наборами (комплектами) товарів; • динамічний контроль наявності товарів на складі під час ви-писування рахунка; • можливість оформляти рахунки на відсутні у наявності то-вари (варіант передоплати); • автоматичне або ручне резервування товарно-матеріальних цінностей на складах і підприємствах під час виписування доку-мента і гнучке управління резервом; • можливість управляти вибором складу, з якого має бути здійснене відвантаження; • можливість автоматично оформляти накладну за виписаним документом-підставою; • контроль повторних спроб оформити накладну на відпустку за вже виконаним документом-підставою; • можливість автоматично провадити списання товару на складі під час оформлення накладної на його відпуск; • облік повернення ТМЦ; • автоматичне формування витратних складських ордерів по групі накладних; • формування платіжних вимог на оплату за документами-під¬ставами; • отримання відомостей про документи-підстави по вибраних контрагентах за допомогою «картки покупця»; • прогнозування обсягів закупівлі та формування заявок на дефіцити; • повна інтеграція з модулем «Постачальники, отриму- вачі»; • відображення в бухгалтерському контурі всіх операцій з ре-алізації матеріальних цінностей і послуг за допомогою механіз-му типових господарських операцій. До стандартних, що формуються модулем, належать такі звіти: • друк накладних; • звіти про стан документів-підстав на продаж (у виконанні, прострочені, оплачені тощо); • звіти про реалізовані товари і послуги (номенклатура, групи, партії, зовнішня класифікація, отримувачі; • звіт про невідповідності в документах на продаж; • реєстри документів-підстав і накладних; • аналіз реалізації по періодах у розрізі контрагентів (або гру-пи контрагентів по регіонах, форми власності тощо) і товарів (груп товарів). 9.2.3.3. Складський облік Програмний модуль «Складський облік» тісно пов’язаний із задачами управління закупівлею і продажем. Основні можливос-ті модуля «Складський облік» полягають у такому: • формування прибуткових і витратних складських ордерів, розподіл матеріальних цінностей між матеріально-відповідаль-ними особами; • облік операцій з ТМЦ за допомогою картки складського об-ліку; • операції внутрішнього переміщення; • динамічний переоблік складських залишків; • облік партій товарів, контроль термінів зберігання партій, термінів дії сертифікатів (ліцензій); • ведення облікових цін, підтримка методик списання за сере-дньозваженими цінами; • формування відомостей руху за період у розрізі: контр- агент, склад, МОЛ, група МЦ, партія МЦ; • формування відомостей наявності МЦ на будь-яку дату в розрізі: склад, МОЛ, партія МЦ, інфраструктура складу; • формування оборотних відомостей в розрізі складу або його матеріальних цінностей; • формування накопичувальних відомостей по надходженнях і по витратах; • контроль неліквідів, понаднормативів, дефіцитних позицій; • проведення інвентаризації, формування відомості фактичної наявності, порівнювальної відомості по підсумках інвентаризації; • проведення дооцінювання імпортних товарів з огляду на зміну курсу валют; • перерахунок собівартості реалізації відповідно до застосовуваної методики обліку і списання товарів; • контроль відповідності накладних і складських ордерів. 9.2.3.4. Управління консигнаційним товаром Під консигнаційними операціями мають на увазі приймання або передачу товару з регламентною відстрочкою платежу у міру реалізації. Придбавши модуль «Управління консигнаційним товаром», користувач «Галактики» отримує можливість виконувати такі операції: • оформлення документів на приймання або передачу консиг-наційного товару; • передача на консигнацію комплектів товарів; • отримання відомостей про документи-підстави по обраних контрагентах за допомогою картки консигнатора і консигнанта; • оформлення накладних на приймання або повернення кон-сигнаційного товару; • формування довіреності на отримання консигнаційного то-вару; • отримання відомостей на реалізацію і відомості на залишки консигнаційного товару (в гривнях і у валюті); • контроль відповідності накладних і складських ордерів; • врахування розрахунків між консигнаторами і консигнанта-ми; • отримання звітів по виконуваних документах-підставах на приймання або відпускання консигнаційного товару. Стандартними звітами модуля «Управління консигнацій-ним товаром» є такі: • звіти про залишки товарів, прийнятих на консигнацію (грив-неві, валютні, валютно-гривневий); • звіти (графічні й табличні) про реалізацію консигнаційних товарів (зведені відомості, обсяги продажу за кількістю, продаж у валюті у розрізі партій); • відомості прийому / відпуску консигнаційного товару в роз-різі контрагентів,ТМЦ; • відомості реалізації товарів, відпущених на консигнацію в розрізі контрагентів, товарів; • звіт про невідповідності в накладних на прийом / відпуск / повернення консигнаційних товарів і у відповідних складських ордерах. 9.2.3.5. Розрахунки з постачальниками та отримувачами Програмний модуль розрахунку з постачальниками й отриму-вачами призначений для повного контролю взаєморозрахунків з контрагентами з урахуванням фінансових і товарних супровідних документів. Основними можливостями модуля є: • формування реєстру виконуваних договорів з урахуванням товарних і фінансових документів за цими договорами; • спеціальний режим прив’язки платіжних документів до до-говорів (документів-підстав); • автоматичне формування платіжних документів за докумен-том-підставою; • розрахунок сальдо і складання платіжного балансу по конт-р¬агенту; • контроль взаєморозрахунків; • аналітика відносин з постачальниками по взаємній заборгованості в розрізі періодів, договорів, груп договорів, конкретних консигнатора та консигнанта МЦ, груп консигнатора та консигнанта МЦ; • аналітика відносин з отримувачами по взаємній заборгова-ності в розрізі періодів, договорів, груп договорів, конкретних МЦ, груп МЦ; • нарахування й облік штрафів (пені) за невиконаними зо-бов’язаннями контрагентів або фірми. 9.2.3.6. Роздрібна торгівля (управління продажем через торговий зал) Установка на робочих місцях касирів замість традиційних ка-сових апаратів, об’єднаних у мережу спеціалізованих касових терміналів на базі процесорів INTEL 386 з вбудованими принте-рами (наприклад IPC POS, ОКА-500.1 та ін., що пройшли держа-вну реєстрацію і включені до реєстру рекомендованого для вико-ристання обладнання) дозволяє оптимально організувати процес управління продажем. Касири за такої автоматизації мають такі зручності: • немає необхідності пам’ятати вартість кожного товару, оскіль¬ки ціна витягується з прайс-листа під час ідентифікації товару; • є можливість автоматичної ідентифікації товару за його штрихом-кодом за допомогою сканера; • завжди відома наявність / відсутність того або іншого виду товару в кожному відділі і кількість готівки в касі; • за наявності префіксів, що прочитують кредитні картки, можна обслуговувати відповідну категорію клієнтів; • спрощуються операції приймання / здачі зміни. • Завідувач торгового залу отримує можливість: • у будь-який момент часу мати необхідну інформацію про продаж по відділах і товарах, про готівку, що є в кожній касі, за-лишки товарів у відділах та на складі тощо; • гнучко управляти ціновою політикою: для зміни цін досить скоригувати прайс-лист і направити повідомлення у відділи про заміну цінників (каси отримають новий прайс-лист автоматично); • маючи дані про темпи продажу різних товарів та залишки їх, своєчасно подавати замовлення на поставку, не допускаючи перебоїв у торгівлі; Рис. 9.10. Інформаційні потоки в контурі управління підприємством • для розбору різних спірних ситуацій використати архів ви-даних і сторнованих чеків, архів виконаних прибуткових і ви-трат¬них операцій, реєстри і журнали по кожній касі. 9.2.4. Контур управління виробництвом Програмний комплекс «Галактика», що належить до класу фінансово-економічних систем, включає в себе не тільки компо-ненти, уніфіковані та призначені для експлуатації в організаціях (корпораціях) будь-якої професійної орієнтації, а й ряд спеціалі-зованих модулів, що автоматизують процеси управління вироб-ництвом промислової продукції. Серед них — такі, наприклад, класичні підсистеми традиційних автоматизованих систем упра-в¬ління (АСУ) виробництвом: техніко-економічне планування, об-лік витрат на виробництво, оперативне управління виробницт-вом, технічна підготовка виробництва. Однойменні модулі комплексу «Галактика» орієнтовані на великий спектр підприємств багатьох галузей промисловості, як-от: • видобування, транспортування і первинна переробка сиро-винних ресурсів: ? гірничорудна і гірничозбагачувальна промисловість; ? чорна і кольорова металургія; ? транспортування нафти і газу; • фізико-хімічне виробництво: ? хімічна і нафтохімічна промисловість; • легка промисловість; • харчова промисловість; • машинобудування; • приладобудування; • будіндустрія. Ці підприємства характеризуються такими параметрами: • безперервним, дискретним або змішаним характером виро-б¬ництва; • масовим, серійним, дрібносерійним, одиничним типом ви-робництва; • позамовним або попередільним плануванням; • наявністю нормативного методу обліку: специфікованими нормами витрат матеріалів; поопераційними технологічними про¬цесами. На рис. 9.10 наведена загальна схема циркуляції інформації в контурі управління промисловим виробництвом. 9.2.4.1. Техніко-економічне планування Програмний модуль «Техніко-економічне планування» (ТЕП) призначений для використання в планово-економічній службі підприємств. Будучи базовим у контурі управління виробництвом комплексу «Галактика», даний модуль разом із модулем «Облік фактичних витрат» інваріантний щодо галузі про- мисловості. Програмний модуль включає в себе три блоки задач: 1. Підтримка нормативно-довідкової інформації: • склад продукції, що випускається; • специфіковані (подетально специфіковані) норми витрати сировини, матеріалів у розрізі технологічних операцій і структу-р¬них підрозділів; • поопераційні технологічні процеси (норми часу, розцінки, технологічне обладнання, інструмент, оснащення). 2. Планування виробництва: • формування портфеля замовлень (при позамовному плану-ванні); • формування плану виробництва на кожний місяць за номен-клатурою та обсягом; • перерахунок виробничих показників за умови зміни плану; • формування виробничої програми; • оцінка виконуваності виробничої програми; • формування збалансованого за ресурсами плану; • облік або розрахунок фактичних обсягів випуску готової продукції; • оцінка зведених потреб у матеріалах і трудозатратах на ви-робниче замовлення, план виробництва, виробничу програму в розрізі структурних підрозділів і номенклатури продукції. 3. Розрахунок планової собівартості: • розрахунок нормативних витрат на виробництво (в розрізах центрів їх виникнення); • розрахунок зведення витрат на виробництво; • розрахунок зведених кошторисів витрат по цехах і кошториси витрат по підприємству; • розрахунок нормативних калькуляцій собівартості виро- бів і напівфабрикатів на місяць по підприємству і в розрізі цехів; • розрахунок планових цін виробів на основі собівартості. Мінімальним періодом планування в модулі є місяць. План також може бути розрахований на рік або на квартал. Модуль надає можливість формувати план виробництва декількома способами: за сумою договорів про постачання продукції; за сумою виробничих замовлень; за результатами попереднього року; ви¬ходячи з плану на рік або на квартал пропорціонально кількості робочих днів у місяці; інтерактивно. Допустимі на підприємстві варіанти формування задаються в настройці модуля. Модуль дозволяє формувати виробничі замовлення, оцінювати обсяги виробництва переділів / напівфабрикатів по структурних підрозділах і за потребою в сировині, матеріалах, комплектуючих ви¬робах, трудозатратах для їх виконання, включати замовлення у виробничу програму. Виробнича програма по структурних підрозділах (цехах, змі-нах, дільницях, бригадах, робочих місцях) на місяць може фор-муватися або на основі плану виробництва, або за сумою вироб-ничих замовлень з урахуванням запасів сировини на початок місяця, заділів, напівфабрикатів. Собівартість розраховується на основі норм витрати матеріа-лів і трудозатрат на виготовлення продукції (переділів, напівфаб-рикатів), планово-облікових або середніх за місяць відпускних цін матеріалів і купованих деталей, тарифних ставок оплати праці виробничого персоналу, кошторисів накладних витрат по струк¬турних підрозділах і загальнозаводських кошторисів, обсягів випуску продукції за виробничою програмою або фактичних обсягів випуску за місяць. Калькуляція собівартості може бути розрахована на будь-який напівфабрикат (переділ) у технологічному ланцюжку з урахуванням собівартості запасів. Витрати на обсяг випуску обчислюються в розрізі структур-них підрозділів, статей калькуляції і шифрів виробничих витрат. Калькуляції собівартості виробів розраховуються в розрізі підро-зділів і статей калькуляції. 9.2.4.2. Облік витрат на виробництво Програмний модуль «Облік фактичних витрат на виробни-цтво» (ОФВ) призначений для використання фахівцями вироб-ничого бюро (сектора) бухгалтерії підприємства. Він автоматизує функції розрахунку фактичних витрат за підсумками виробничої діяльності підприємства за певний період. Програмний модуль вирішує такі задачі: 1. Облік фактичних обсягів випуску: • розрахунок за даними складських надходжень фактичного випуску готових виробів і напівфабрикатів по цехах за кожний місяць; • облік фактичних обсягів незавершеного виробництва. 2. Розрахунок фактичних витрат: • розрахунок фактичних кошторисів витрат за комплексними статтями калькуляції; • розрахунок сум фактичних прямих витрат за статтями каль-куляції в розрізі підрозділів і по підприємству; • розрахунок сум фактичних витрат по економічних елемен-тах (шифри витрат); • розрахунок повних кошторисів фактичних витрат по підро-зділах; • розрахунок кошторису і зведення фактичних витрат по під-приємству; • розрахунок калькуляцій фактичної собівартості виробничих замовлень; • розрахунок калькуляцій фактичної собівартості виробів; • розрахунок собівартості незавершеного виробництва; • контроль та аналіз відхилень планових і фактичних витрат. Функціонування модуля можливе за наявності на підприємст-ві працюючого модуля «Техніко-економічне планування» і бу-х¬галтерського контуру системи «Галактика». 9.2.4.3. Технічна підготовка виробництва Програмний модуль «Технічна підготовка виробництва» (ТПВ) призначений для використання в конструкторських від-ділах, службах технічної документації, технологічних, планово-економічних і планово-диспетчерських службах підприєм- ства. ТПВ виконується під час освоєння виробів у серійному виро-б¬ництві і при підготовці до запуску кожного замовлення в оди- ничному виробництві. Якість і повнота технічної підготовки ви-робництва визначає в кінцевому підсумку якість планування і управління процесом виробництва. Модуль орієнтований в основному на підприємства машино-будівного профілю, але з успіхом може бути використаний для автоматизації служб забезпечення виробництва (насамперед служб головного механіка, головного енергетика) підприємств практично всіх галузей промисловості. Задачі вирішуються по таких напрямах: а) конструкторська підготовка виробництва • підтримка (формування і ведення бази даних) номенклатури виробів: • підтримка складу виробів (конструкторських специфікацій у стандарті ЕСКД); • підтримка повідомлень на конструкторські зміни. Опис ієрархічної структури виробів допускає 99 рівнів вхо-дження. На кожному рівні можна використати близько 99 альтер-нативних варіантів технологічного виконання; б) технологічна підготовка виробництва • підтримка подетально-специфікованих норм витрат матеріалів у розрізі технологічних операцій; • підтримка поопераційних технологічних процесів у стандартах ЕСТД ; • підтримка повідомлень на конструкторські зміни; в) розрахункові функції • розвузлуванння виробів; • розрахунок потреб у матеріальних ресурсах; • розрахунок потреби у трудових ресурсах; • розрахунок потреби в обладнанні, оснащенні, інструментах (у розрізі підприємства, підрозділу, виробу, групи продукції, виробничої програми, замовлення, плану виробництва). 9.2.4.4. Оперативне управління виробництвом Модуль призначений для використання в планово-диспетчер-ських службах підприємства. Основними його функціями є: • управління процесом запуску-випуску продукції відповідно до виробничої програми та технології виробництва; • внутрішньозаводська (міжцехова) диспетчеризація матері-альних потоків у виробництві; • оперативний облік виконання виробничої програми; • детальний контроль незавершеного виробництва. З огляду на значну специфіку організації процесу диспетчери-зації виробництва на підприємствах різного профілю і галузей промисловості даний програмний модуль планується клонувати, тобто здійснювати доробку модуля для конкретного підприємст-ва-замовника (галузі). 9.2.5. Контур бухгалтерського обліку 9.2.5.1. Зв’язок бухгалтерського та оперативного контурів Концепція інформаційної системи «Галактика» передбачає чіткий розподіл функцій між фахівцями оперативних підрозділів і бухгалтерією. Всі документи, сформовані в контурі оперативного управління під час виконання закупівлі, продажу, приймання і відпускання товарів і МЦ, вважаються первинними. Для обліку господарських операцій і відображення їх у Головній книзі і в звітних документах працівники бухгалтерії повинні сформувати проводки по рахунках бухгалтерського обліку. Для автоматизації формування проводок рекомендується ви-користати каталоги типових господарських операцій (ТГО). Кожна ТГО може виконати одну або відразу декілька проводок по документу. Опис типової господарської операції включає такі елементи. 1. Найменування господарської операції. 2. Кореспонденцію рахунків у проводках. За необхідності мо-жуть бути вказані субрахунки, коди аналітичного обліку і струк-турні підрозділи. 3. Відсоток суми кожної проводки відносно суми документа, а також алгоритми розрахунку сум проводок. 4. Набір ознак, що визначають вхід сум оборотів у суму пла-тежу по документу, необхідність конвертації валют тощо. Виконуючи рознесення (прив’язку) первинних документів по типових господарських операціях, бухгалтер тим самим визначає проводки, що мають бути виконані. Можливе формування групових проводок — згорнутих або розгорнутих. За необхідності сформовані проводки можуть бути відкориговані або відмінені. Схема опрацювання первинних господарських документів, сформованих під час вирішення задач оперативного управління, наведена на рис. 9.11. У контурі бухгалтерського обліку передбачене формування фінансових документів, що супроводжують рух грошових коштів — готівкових (касові ордери) і безготівкових (платіжні доручення тощо). Ці документи можуть бути пов’язані з доку-ментами-підста¬вами, створеними в контурі оперативного управління. Програмний комплекс забезпечує контроль відповідності платежів, оформлених фінансовими документами, і сум, вказаних у документах-підставах, а також отримання балансу взаєморозрахунків з контрагентами. Рис. 9.11 Схема опрацювання первинних господарських документів, які сформовані під час розв’язання задач оперативного управління Забезпечується можливість автоматизованого впровадження банківських виписок у вигляді текстових файлів, що пересила- ються модемним зв’язком або на дискетах, а також виконання електронних платежів (в електронних стандартах банків-корес-пондентів). Проводки по фінансових документах також можуть бути сформовані за допомогою типових господарських опе- рацій. Передбачена можливість ведення обліку не тільки в на-ціональній грошовій одиниці, а й у іноземних валютах. За до-помогою модуля «Валюта» провадиться реєстрація поточних курсів валют, перерахунок і рознесення по рахунках бух- галтерського обліку курсових різниць по валютних операціях і сальдо. 9.2.5.2. Розрахунок зарплати Модуль «Зарплата» повністю автоматизує ведення табелів і розрахунок нарахувань, утримань і податків на фонд оплати пра-ці (ФОП) за погодинної та відрядної форм оплати. При її розроб-ці реалізовані два основних принципи: • універсальність — можливість використання в будь-яких організаціях, починаючи від великих, з штатом у декілька тисяч чоловік, — до підприємств малого бізнесу, з будь-яким режимом роботи; • адаптованість — забезпечення можливості бухгалтерові са¬мостійно провести настроювання з урахуванням специфіки конк¬ретного підприємства і змін чинного законодавства. Враховані особливості розрахунків по оплаті праці в сучасних умовах, включаючи зміну мінімальної заробітної плати, видів і ставок податків, індексацію. Передбачена можливість використання районних коефіцієнтів, доплати за вислугу років, виплати матеріальної допомоги та цінних подарунків. Для нарахування заробітку можна використати близько 160 видів оплат. Для кожного виду оплати можна визначати алгоритм розрахунку, відбиття у розрахунку різних видів утримань, середніх заробітків і податків на ФОП, у стандартному варіанті — поставки налагод¬ження видів оплат. За необхідності, крім стандартного набору алгоритмів розрахунку, можна використати власні алгоритми. Формування їх забезпечується набором функцій, що відкривають доступ до бази даних, і не потребує спеціальної підготовки користувача. Передбачене використання близько 60 видів утримань, які також допускають самостійне настроювання. Розрахунок при¬буткового податку, а також відрахувань до пенсійного фонду, профсоюзних внесків повністю автоматизований, включаючи перерахунок при донарахуванні або сторнуванні зарплати за попередні місяці. Реалізовано два алгоритми розрахунку прибуткового податку: по місячному і по сукупному річному прибутку. Всі види оплат можуть бути віднесені до основного або додаткового заробітку і оподатковуватися прибутковим податком окремо, по одному із згаданих алгоритмів і окремих таблицях ставок податку. Автоматизовано розрахунок авансу, грошових допомог мате-рям, лікарняних, відпускних, допомог на дітей, разових витрат, індивідуальних і бригадних нарядів, договорів підряду. Забезпе-чується ведення особових рахунків працівників і зберігання да-них про всі нарахування та утримання за минулий і поточний рік. Ці дані можуть використовуватися для одержання різноманітних довідок. Модуль «Зарплата» дозволяє отримувати різноманітну доку-ментацію, починаючи від розрахункових листків і платіжних ві-домостей і кінчаючи різними зведеннями і контрольним журна-лом по оплаті праці. Основний документ по оплаті праці — розрахунково-платіжна відомість — допускає настроювання форми залежно від специфіки підприємства. При переході до нового розрахункового періоду автоматично формуються бухгалтерські довідки по нарахуваннях, утриманнях і податках на ФОП. Одночасно формуються платіжні доручення на перелік податків, а також утримань на користь інших юридичних і фізичних осіб. Подальша робота з цими документами виконується в модулі «Фінанси». Модуль «Зарплата» тісно пов’язаний з модулем «Облік і управління кадрами». Облікові дані працівників, введені в од-ному з цих модулів, стають доступними для іншого. Таким чи-ном, виключається необхідність повторного введення ідентичних даних про працівників підприємства. 9.2.5.3. Головна книга. Баланс Формування Головної книги в програмному комплексі «Га-лактика» полягає у виборці записів по вхідних сальдо і по всіх проводках, в розрахунку оборотів і вихідних залишків по рахун-ках бухгалтерського обліку. Провадиться перевірка на закриття рахунків і, якщо який-небудь тимчасовий рахунок не закритий, видається попереджуюче повідомлення. На відміну від Головної книги алгоритм розрахунку Балансу підприємства і численних додатків до нього не є строго визначеним. Він може мати масу особливостей на різних підприємствах залежно від їхньої специфіки і вимог вищестоящих організацій. Тому всі вихідні звітні бухгалтерські форми постачаються в складі комплексу «Галактика» у відкритому вигляді (тобто разом з вихідними формулами розрахунку), доступними для корекції користувачем. Набір включених до «Галактики» стандартних звітних бух-галтерських форм повністю відповідає поточним вимогам за- конодавства України. Водночас користувач має можливість са-мостійно модифікувати ту або іншу форму або розширити список цих форм. Для редагування або створення звітних форм досить ознайомитися з встроєною в систему мовою проектування бухгал¬терських і економічних звітів, а також із зразками оформлення форм, що надходять з «Галактикою». Стислі відомості про мову проектування бухгалтерських і економічних звітів наведені у наступному розділі. 9.2.5.4. Проектування бухгалтерської та економічної звітності довільної форми Усю бухгалтерську звітність можна поділити на три групи: бухгалтерська звітність для внутрішнього користування, ви-хідна бухгалтерська звітність, розрахунки економічних пока-з¬ників. 1. До бухгалтерської звітності для внутрішнього користу-вання належать такі види документів: • Відомості щоденного обліку будь-якого рахунку; • Групуючі відомості; • Оборотні відомості про будь-який рахунок (за звітний пері-од, за довільний інтервал часу) в розрізі структурних підрозділів; • Відомості аналітичного обліку; • Журнал (книга) господарських операцій; • Головна книга; • Відомості з розрахунку курсової різниці; • Відомості з обліку праці і зарплати; • Відомості з обліку основних засобів і нематеріальних ак-тивів; • Відомості з обліку МЦ і МШП. 2. Вихідна бухгалтерська звітність: • Баланс підприємства (організації). • Додатки до балансу. • Звіти про податки. 3. Розрахунки економічних показників. • Аналітичний баланс. • Розрахунок рентабельності. • Розрахунок стійкості. • Розрахунок оборотності. • Розрахунок ліквідності. Кількість і склад форм вихідної бухгалтерської звітності, їх оформлення і методики розрахунку можуть змінюватися залежно від таких чинників: • чинного законодавства; • вимог вищестоящих організацій і податкових органів у ме-жах діючого законодавства; • специфіки діяльності та структури підприємств, визначаль-них особливостей обліку. Усі перелічені чинники зумовлюють необхідність постійної доробки форм вихідної бухгалтерської звітності. У бухгалтерському контурі «Галактики» ця проблема ви- рішена наданням користувачеві можливості легко скоригувати будь-яку існуючу або створити власну звітну форму. Ця можли-вість ґрунтується на використанні вмонтованої в систему мови проектування звітів. Даною мовою виконані всі вихідні форми бухгалтерської звітності й документи з розрахунку економічних показників. (рис. 9.12). Технологія створення нової звітної форми є надто простою і складається з таких кроків: • формі, що створюється, треба привласнити найменування, яке надалі з’являтиметься в переліку обраних для друку звітних форм; • за допомогою вбудованого текстового редактора створюється шаблон звіту, що включає «шапку», «боковик», стовпчики, підписи; • на кожній сторінці шаблона в місцях, де повинні знаходити-ся розрахункові дані, проставляються найменування розрахунко-вих полів, а нижче окремими рядками записуються самі формули розрахунку. Як змінні в розрахункових формулах використовуються проводки по рахунках, обороти і сальдо по рахунку. Структу- ра найменувань змінних строго визначена і має такий вигляд (Рис. 9.12. Квадратними дужками виділені необов’язкові ком-поненти): Рис. 9.12. Мова проектування звітів Розрахункова формула може включати перевірку відносин значень змінних (рівно, нерівно, більше, менше тощо), а також ло¬гічні операції («так», «або», «ні»). Мова проектування звітів проста в освоєнні, наближена до звичної для бухгалтера термінології і дозволяє користувачеві оперативно адаптувати свої звіти до поточних змін зовнішніх вимог. 9.2.5.5. Багатоплановість рахунків бухгалтерського обліку За допомогою модуля «Консолідація» в «Галактиці» реалі-зується можливість паралельного обліку в декількох планах ра-хунків бухгалтерського обліку, тобто багатопланових рахунків. Один план рахунків може, наприклад, відповідно українським стандартам, інші — російським чи стандартам GААР. Кількість планів рахунків програмою не обмежується. Перемикання між ними провадиться натисненням певної комбінації клавіш. Користувач може самостійно визначати найменування планів рахунків, вводити будь-які номери рахунків (близько 19 алфавіт-но-цифрових символів) та назви їх. В усіх планах можна вводити субрахунки, коди аналітичного обліку, вести контроль допусти-мої кореспонденції. Типові господарські операції можуть бути настроєні таким чином, щоб одночасно формувати проводки по всіх існуючих планах рахунків, причому в кожному з них — у необхідній кореспонденції і з розрахунками сум оборотів. 9.2.5.6. Консолідована звітність корпорації За допомогою вже згаданого модуля «Консолідація» забезпе-чується можливість ведення консолідованої (спільної) бази даних корпорації і отримання консолідованої звітності. Під корпораці-єю в цьому разі треба розуміти об’єднання декількох юридичних осіб. Усі вони ведуть роздільний бухгалтерський облік по одно-му і тому самому набору планів рахунків. Один із учасників кор-порації вважається головною фірмою, інші — філіями. Ця від-мінність не відбивається на способі подання даних або роботі з ними. Для простоти можна вважати головну фірму також філією. Кожна філія, в свою чергу, може мати безліч офісів. Загальна (консолідована) база даних створюється різними способами: • Під час ведення обліку по філіях на одному комп’ютері або в єдиній обчислювальній мережі. Додаткові програмні засоби не потрібні. • Під час передачі даних через електронну пошту, модем або на дискетах. У цьому разі потрібне об’єднання їх за допомогою програми міжофісного обміну даними Соrро. У модулі «Консолідація» користувач має ряд можливостей: • встановлювати потрібний йому план рахунків, вид консолі-дованих звітів. Для кожного виду визначається набір філій, що включаються; • для обраного виду звіту визначати, які операції філій відби-рати для роботи: тільки зовнішні, тільки внутрішні, всі (і зовніш-ні, і внутрішні ). Внутрішніми вважаються операції між учасниками корпорації, зовнішніми — з контрагентами, що не входять у корпорацію. При роботі з іншими модулями контуру бухгалтерського обліку користувач має доступ до даних і може отримувати звіти по за-даній філії корпорації і у встановленому плані рахунків. Модуль «Консолідація» забезпечує отримання узагальнених звітів про рух коштів корпорації, що відображається на рахунках аналітичного обліку, і контроль сальдо на початок і кінець звіт-ного місяця. Мова проектування звітних форм забезпечує створення форм загального балансу корпорації та інших видів звітів. Для доступу до даних різних філій в іменах змінних передбачений спеціаль-ний елемент, що включає код філії. Він повинен передувати ін-шим елементам імені змінної, наприклад: &1 = F0_СД51+F1_СД51. Змінній &1 привласнюється значення суми сальдо по дебету рахунка 51 головної фірми (філія з кодом «0») і філія з кодом «1» на початок звітного періоду. Отримання загальних балансів та інших форм звітності може бути подане такою схемою (рис. 9.13). Рис. 9.13. Схема отримання звітності 9.3. ІНФОРМАЦІЙНА СИСТЕМА УПРАВЛІННЯ ПІДПРИЄМСТВОМ MIRACLE V 9.3.1. Базові принципи побудови ІС Miracle V являє собою інтегровану інформаційну систему уп¬равління бізнесом, засновану на найновітніших технологіях та сучасних методах. Ця інформаційна система здатна адаптуватися до вимог та потреб компаній-користувачів. Для досягнення цього головна увага фокусувалася на бізнес-процесах. Маючи в своєму розпо¬рядженні інформаційну систему, підприємство отримує інструментарій, який дозволяє йому постійно вдосконалювати процеси, що відбуваються всередині нього, та оптимізувати їх з метою якнайкращого використання можливостей середовища, що постійно змі-нюється. Дотримання цих вимог неможливо забезпечити звичайним адміністративним програмним рішенням, параметри якого можна настроювати лише до певної міри. Замість стандартного статичного програмного забезпечення підприємство може впровадити управлінську інформаційну систему, вільну від звичайних недоліків. Інформаційна система Miracle V була розроблена саме для задоволення таких вимог. Miracle V заснована на всеохопній управлінській моделі. Пропонується декілька таких моделей залежно від галузі, в якій працює компанія. Вони можуть бути легко і прозоро перебудовані відповідно до конкретних вимог даного підприємства. Безболісна модифікація моделей можлива завдяки інструментарію Miracle V, котрий включає: перемоделювання чи опис нових процесів; зміну структур даних; введення нових функціональних залежностей, перебудову форм та документів. Існує можливість спостереження за кожним процесом чи сферою діяльності, їх аналізу та симуляції на основі наявних фактичних даних. Процеси розробляються та модифікуються в графічному вигляді за допомогою компоненти Business Process Modeller. Компонента Business Executer відкриває та здійснює запуск процесів без додаткових проміжних кроків. Проілюструвати це допоможе приклад — опрацювання вхідного рахунка-фактури у компанії «Байк Інк». У «Байк Інк» усі рахунки-фактури проходять стадію початкового опрацювання (рис. 9.14). Залежно від зазначеного обсягу деякі рахунки-фактури мають бути підтверджені. Інформаційна система повинна вказати для кожного рахунка-фактури дату, до якої він має бути підтверджений, а також відповідальну особу. Після підтвердження рахунки-фактури повинні бути зареєстровані і направлені до оплати. Компоненти Business Рис. 9.14. Рахунки до оплати, вхідні рахунки-фактури Process Executer відповідає за виконання процесу, розробленого у Process Modeller. Коли певна особа виконала своє завдання в межах процесу, наприклад «Введення рахунка-фактури», система автома- тично генерує нове завдання для особи (або групи), відповідальної за підтвердження. Так Miracle V передає завдання від особи до особи. Ланкою комерційної діяльності (деякі зв’язки для спрощення опущені) може бути, наприклад, ця діаграма (подібну до неї мо-ж¬на розробити для будь-якого процесу). Вказівка «V» у назві «Miracle V» підкреслює віртуальність ці-єї інформаційної системи. Віртуальність означає, що кожне під-приємство (навіть таке, що, можливо, ще не існує) в усіх його ас-пектах (процеси, дані, організація тощо) може бути змодельоване. Такі змодельовані процеси можуть бути негайно виконані за допомогою виконавчої системи, вбудованої в Miracle V. Придбання розробленого за звичайною схемою стандартного програмного забезпечення подібне до придбання вже збудовано-го будинку. Зміни, хоча й обмежені, можуть бути внесені завдяки розширенню або реконструкції (окремі версії програмного забезпечення). План будинку все-таки залишається незмінним та статичним, що накладає певні обмеження. У Miracle V немає формального чи наперед заданого рішення. З бібліотеки довідкових (референтних) моделей підприємство обирає ту, що найкраще відповідає його вимогам. Довідкова модель у Miracle V — це повнофункціональна та внутрішньо узгоджена інформаційна система. Там, де процеси, функції та структури не повністю відповідають потребам підприємства, вони можуть бути змінені та модифіковані за допомогою інструментарію Mi¬racle V. Якщо продовжувати аналогію з будинками, підприємство може обрати будинок-модель (довідкова модель-приклад) і адаптувати його до своїх потреб. За допомогою Miracle V, або, точніше, її засобами для розробників, підприємство створює свою власну, таку, що повністю відповідає його потребам та вимогам, інформаційну систему. Всі процеси моделюються графічно, подібно до блок-схеми, і потім вводяться до системи. Структури даних та зв’язки їх можуть за необхідності змінюватися. За допомогою дизайнера форм їх можна змінювати та створювати наново. Інструмент запитів дозволяє впроваджувати запити на будь-якій стадії, протягом впровадження системи або пізніше. Усі визначення та описи (процеси, форми, документи, струк-тури даних тощо) інтерактивно взаємопов’язані. Вони функціо-нують як правила роботи для інформаційної системи і детально описуються у своїй власній базі даних, яка називається Repository (сховище). Вони також можуть змінюватися чи розширюватися в будь-який час. Структури Repository контролюють усю виконавчу систему Miracle V. Repository є «вихідним кодом» для системи. У наш час успіх підприємства великою мірою залежить від його здатності швидко реагувати на зміни. Звідси випливає, що бізнес-процеси також повинні адаптуватися, аби відповідати новим умовам. Перепроектування організацій та процесів вимагає наявності інформаційних інструментів для підтримки виконання відповідних завдань. Додатки Miracle V відповідають таким вимогам. Business Process Modeller забезпечує підтримку управлінської діяльності, дозволяючи створювати нові процеси та адаптувати наявні. За допомогою симуляції наслідків втілення нових ідей різні варіанти можна тестувати, перш ніж впроваджувати їх на підприємстві. Перепроектування бізнес-процесів одержує добру підтримку завдяки такій здатності їх симулювати. Все більш досконалі аналітичні засоби можуть генерувати надійні результати лише тоді, коли вони постійно використовуються в буденній діяльності підприємства. Саме то-му організація та інформаційна система мають працювати взаємопоєднано. Філософія Miracle V базується на цій ідеї, оскільки вико¬нуються лише процеси, необхідні в щоденній роботі підприємства. Інформація про бізнес-завдання всередині конкретних відділів чи в межах усього підприємства звичайно поширена серед невеликої групи людей. Відповідна документація або не існує, або є застарілою. Неефективна проробка завдань може бути виявлена лише за умови докладання величезних зусиль або не може бути виявлена взагалі. За допомогою компоненти Miracle V Business Process Modeler усі процеси відображаються графічно і одночасно здійснюється прямий вплив на інформаційну систему. Це означає, що відповідна документація, згенерована Process Modeler, у будь-який момент залишається актуальною. Оскільки процеси відомі інформаційній системі, а вся відповідна інформація (про виконані завдання) реєструється, ефективність процесів може аналізуватися на основі бази поточних даних. Динамічна система підтримки користу¬вача також користується інформацією від Process Modeler. Вона завжди показує користувачам, у якому процесі вони перебувають, попередні та наступні завдання і відповідальних за них. Коли впроваджується нова інформаційна система або модифі-кується наявне рішення, менеджери, інженери з програмного за-безпечення та користувачі можуть висловлювати різні думки та погляди на стадії аналізу інформаційного проекту. Це може призвести до непорозумінь та неузгоджень, які усвідомлюються на значно більш пізній стадії, звичайно у фазі виробництва, що призводить до конфліктів та зростання витрат. Інструмент графічного аналізу Miracle V — Process Modeler — допомагає «спорудити мости» між різними групами, дозволяючи їм краще розуміти одна одну. Стандартне програмне забезпечення набуває дедалі більшого поширення у сучасному бізнесі, а індивідуальне програмне за-безпечення використовується лише у виняткових випадках. При-кладні програми, які виробляються масово, коштують менше, во-ни дозволяють використовувати досвід інших, а постійне вдос-коналення програмного забезпечення гарантується. Все це добре, але при цьому користувач отримує лише обмежені функціональні можливості, процеси ж розроблені для загального використання, а не для задоволення індивідуальних потреб. Окрім того, має існувати еволюційний взаємозв’язок між наявними процесами та їх застосуванням. Miracle V розв’язує цю проблему, надаючи спеціально розроблені рішення для конкретних галузей, які можуть бути легко графічно адаптовані. Завдяки об’єктно-орієнтованому підходу в Miracle V будь-які модифікації автоматично поширюються на нові версії. Це означає, що не потрібно повторно проводити зміни для наступних версій Miracle V. Завдяки такій структурі Miracle V має переваги як у стандартному, так і в розроб¬леному на замовлення програмному забезпеченні. 9.3.2. Основні компоненти інформаційної системи Miracle V Опис компонентів Miracle V наведено нижче (рис. 9.15). Рис. 9.15. Miracle V – компоненти 9.3.2.1 Repository Repository — центральний компонент Miracle V. У ньому збе-рігаються усі визначення, правила та описи (включаючи зв’язки та відношення між ними самими). Repository являє собою різні аспекти інформаційної системи (рис. 9.16), які контролюють і ви-значають роботу виконавчої системи Miracle V. Інструменти Miracle V використовують інформацію з Repository та зберігають її у ньому. Його можна описати як «вихідний код» для всіх прикладних програм. Рис. 9.16. Різні аспекти інформаційної системи Різноманітні аспекти підприємства (наприклад, процеси, орга-нізація, структури даних тощо) описуються в єдиній, внутрішньо узгодженій, придатній до практичного застосування моделі – Repository. Головною перевагою даної архітектури є поєднання цих аспектів, а не розподіл їх по різних моделях і за допомогою різних інструментів. Вона гарантує цілісність та внутрішню узгодженість у системі усіх аспектів і кожного з них з іншими. Як і в усіх компонентах Miracle V, включаючи й виконавчу систему, в Repository суворо дотримані принципи об’єктно-орієн¬тованого програмування. В Repository визначаються базові класи. Від них походять усі інші класи, наприклад, від класу «Основні дані (Trunk data)» походить клас «Адреси». Таким чином, не тіль¬ки Miracle V, а й уся бізнес-модель є об’єктно-орієнтованою. На даний момент розроблені такі базові класи: основні дані, процеси, документи, журнали, форми, вибірки, запити, дозволи на доступ, організаційні структури (рис. 9.17). Усі окремі класи в моделі можуть поєднуватися один з одним — вільно асоціюватися або тісно пов’язуватися. Ці зв’язки полягають не просто в спеціалізації та ієрархії наслідування (наприклад, нова адреса приєднується до форми адреси, яка, в свою чергу, приєднується до запиту). Усі класи з їхніми відношеннями складають бізнес-модель. Вона є робочою моделлю Miracle V. Наводимо діаграму, яка описує конструкцію Repository. Рис. 9.17. Схема Repository Цей приклад роз’яснює викладені вище думки. Компанії «Байк Інк» потрібно вводити адреси, де вказується більш ніж од-на контактна особа. Існує клас «адреса», похідний від базового класу «основні дані». Атрибути — це поля для необхідних даних про адресата (назва компанії, прізвище, ім’я, відділ і т. ін.). Оби-раються методи «створити», «змінити» та «вилучити». За допомогою компоненти Miracle V Form Designer (дизайнер форм) генерується форма для адреси. Дизайнер форм «знає» про атрибути (поля) та методи (функції) з класу «Адреса». Форма адреси є породженням форм базового класу. Клас «Адреса» по-єднаний з відповідною формою, що дозволяє їй управляти адре-сами. Окрім того, клас «Адреса» пов’язаний з класом «населений пункт» (похідним від базового класу «Основні дані»), котрий містить усі населені пункти та відповідні індекси. Метод «внесення населеного пункту», який дозволяє обирати індекс, також доступний класу «адреса». Для вказання контактної особи створюється клас «контактна особа», похідний від класу «адреса». Далі визначається взаємозв’язок між двома класами, в даному випадку 1:n (це означає, що одній адресі можуть відповідати одна або декілька контактних осіб). Контактна особа, проте, відповідає лише одній адресі. «Байк Інк» не потрібно здійснювати операції з наведеного прикладу, оскільки все це вже введене в довідковій моделі. Проте, можливо, буде необхідним внесення певних уточнень. 9.3.2.2. Інструментарій для побудови бізнес-процесів Усі інструменти Miracle V, прямо пов’язані з процесами, на-зиваються інструментарієм бізнес-процесів. До нього належать: Business Process Modeler, Business Process Executer, Business Process Analyzer та Business Process Simulator. Modeler визначає процеси на різних рівнях абстракції. Під час моделювання проце-си відкриваються та виконуються додатком Executer. Уся інфор-мація, зібрана під час роботи, може бути вивчена за допомогою компонента Analyzer. Simulator створює сценарії типу «що—якщо для усіх процесів або їхніх частин. Опис перелічених інструментів для побудови бізнес-процесів наводиться нижче. ? Business Process Modeler У Business Process Modeler процеси визначаються графічно на різних рівнях абстракції. Програмне середовище «дружнє» щодо користувача і зрозуміле йому. Різні рівні дозволяють ко-ристувачеві ніколи не випускати з уваги процеси в цілому, навіть при роботі з дуже складними підприємницькими струк- турами. Найвищим рівнем є групи процесів. Вони поділяються на різноманітні категорії, які визначаються користувачем. Група процесів може містити інші групи процесів або власні процеси користувача. Процеси поділяються на один або більше частко-вих процесів. На ще нижчому рівні часткові процеси розгляда-ються як діяльність однієї або кількох осіб всередині процесу. На останньому рівні кожен вид діяльності поділяється на дії — кроки під час опрацювання інформації інформаційною системою (рис. 9.18). Рис. 9.18. Рівні абстракції у Process Modeler У бібліотеці довідкової моделі містяться декілька різних про-цесів однієї спрямованості. Це дозволяє підприємству обирати процес(и), який(і) підходить(ять) найбільше. Це зменшує потребу в модифікації процесів (рис. 9.19). Рис. 9.19. Загальний вигляд процесу «Замовлення» Вигляд компонента Process Modeler подібний до блок-схеми. Найголовніша його відмітна риса — те, що процеси, визначені в Modeler, можуть одразу вводитися в дію без необхідності вико-нання будь-яких додаткових кроків. Цілісність інформаційної си-стеми під час моделювання процесів гарантується, оскільки усі зміни автоматично перевіряються на відповідність визначенням та правилам, раніше описаним у Repository (рис. 9.20). Рис. 9.20. Етап роботи процесу У Modeler визначається і організаційна структура підприємства. Органіграма складається з функціональних робочих місць. Таким чином, організаційна структура визначається поза залежністю від конкретних найманих працівників. Коли останні змінюються, треба лише змінити імена. Органіграма призначена не лише для цілей опрацювання інформації та документації, а й для контролю за усією інформаційною системою при розподілі зав¬дань (рис. 9.21). Рис. 9.21. Етап роботи — операційні кроки (дії) Різні завдання прив’язуються до функціональних робочих місць (рис. 9.22): Рис. 9.22. Компонент Organigram Designer Відповідальність за кожне завдання чітко визначається — на рівні підприємства та на рівні інформаційної системи. Додаток виробляє перелік усіх майбутніх завдань. Отже, існує можливість у будь-який момент та для будь-якого завдання визначити, хто виконує його або хто відповідальний за нього (рис. 9.23). Рис. 9.23. Business Process Modeler Як показано вище, Process Modeler також виробляє повну до-кументацію. За допомогою системи підтримки користувачі завж-ди знають, де саме у процесі вони знаходяться. Допоміжна ін-формація видається автоматично, залежно від того, з якого зав-дання її викликали. ? Business Process Executer Додаток Business Process Executer виконує усі процеси та пра-вила, визначені у Business Process Modeler. Він відповідає за всі види завдань, їх цілісність, опрацювання у правильній послідов-ності та нагляд за їх виконанням. Business Process Executer коор-динує комплекс завдань системи та управління і розподіл окре-мих завдань (рис. 9.24). Рис. 9.24. Система завдань Далі описується робота Business Process Executer. Після його активації з робочого місця (WorkPlace) Executer відшукує бажа-ний процес і запускає перше його завдання. Системні дії вико-нання для цього завдання здійснюються у порядку, визначеному у Modeler. Коли дія виконана, викликається наступна (відповідно до правил, визначених у Modeler). Ця процедура триває доти, доки завдання не буде виконане повністю. Звичайно потім Exe-cuter передає наступне завдання до Task Manager, який надсилає відповідне повідомлення для наступного відповідального пра-цівника (або групи). Передана задача належить групі доти, доки один із членів групи не приймає її. Розподіл задач здійснюється під контролем системи управління задачами. Окрім того, задачі можуть бути вільно визначені та автоматично передані відпові-дно до органіграми. Продовжимо розгляд прикладу — опрацювання вхідного ра-хунка-фактури у компанії «Байк Інк». Усі вхідні рахунки-фак-тури спочатку вводяться, потім передаються відповідній особі для перевірки, підтвердження та сплати. За допомогою ярлика на робочому місці (Miracle V WorkPlace) активується завдання «введення рахунків-фактур». Перша дія завантажує форму для введення рахунка-фактури та інші необхідні компоненти. На-ступна дія, власне введення рахунка-фактури, являє собою вза-ємодію з користувачем. Коли користувач закінчує дію (введення рахунка-фактури), вона успішно завершується. Це є остання дія, отже, завдання «введення рахунків-фактур» також успішно за-вершується. Task manager потім генерує нове завдання для ро-бочого місця відповідальної особи. З викликом цією особою «підтвердження» виконуватимуться усі дії завдання «підтвер-дження». Коли і воно завершиться, буде створене нове завдання для відділу рахунків (на їхньому робочому місці). Якщо завдан-ня відміняється, усі дії автоматично і коректно будуть повернуті у вихідний стан системою. ? Business Process Analyzer Уся інформація, згенерована під час виконання завдань, запи-сується компонентом Business Process Analyzer, наприклад, ін-формація про те, які завдання, як і ким були виконані, скільки ча-су було витрачено і яким шляхом пішов процес. Ці та інші дані опрацьовуються додатком Analyzer, а результати надаються вла-с¬никові процесу та керівництву (в разі потреби). Головною метою є не аналіз діяльності окремих працівників, а надання інформації про якість усього процесу за певний промі-жок часу. Цей інструмент разом з іншими даними процесів до-зволяє власникам процесів концентруватися на своїй відпові-дальній роботі та вдосконаленні цих процесів. За допомогою Miracle V вперше стало можливим аналізувати процеси на основі бази фактичних даних без необхідності витрачати час та ресурси на збір цієї інформації. Ця нова ідея безпосередньо впливає на управління якістю, оскільки для ко-жного процесу можна побачити, які завдання насправді були виконані і ким. ? Business Process Simulator Немає потреби наголошувати, що у комплексному продук- ті, як-от Miracle V, обов’язковою є можливість здійснювати симулювання. Business Process Simulator дозволяє моделюва- ти та симулювати окремі процеси та їхні частини. Результуючий стан середовища генерується на основі статистичних методів. Таким чином, існує можливість експериментувати з нетради-ційними ідеями, перш ніж впроваджувати їх. 9.3.2.3 Робочі місця (WorkPlace) Робоче місце Miracle V — це інтегроване робоче середовище та головне вікно для прикладних програм Miracle V. Формат, поведінка та інтуїтивність WorkPlace стандартні для ОС Windows 95 та NT. По суті WorkPlace — це інтерфейс між Miracle V та кі-н¬цевим користувачем. На робочому місці користувачі знаходять усі об’єкти, необхідні для виконання своїх задач, — об’єкти біз-нес-процесів, об’єкти запитів, а також окремі адреси та докумен-ти (рис. 9.25). Рис. 9.25. Робоче місце Miracle V Користувач та ергономічність для користувача були в центрі уваги під час розробки Miracle V. Це чітко видно по WorkPlace, яке може бути повністю індивідуально настроєне кожним корис-тувачем згідно з мірою його відповідальності та правами досту-пу. WorkPlace поводить себе залежно від того, яке завдання ви-конується. Наприклад, на документи про зарплату у WorkPlace можуть бути створені ярлики для подальшого опрацювання. Ко-ристувачі, котрі не мають права на доступ до даних про зарплату, не можуть запустити на виконання ці запити або відкрити інші завдання, що пов’язані із зарплатою. WorkPlace містить такі елементи, як папки, посилання, яр-лики, меню, контекстні меню, лінійки інструментів та стану. Тут наявні певні суттєві відмінності від робочих середовищ Win-dows 95/NT, котрі певною мірою є статичними. Наприклад, пап-ка, де багато користувачів створюють та вилучають файли, не буде автоматично обновлюватися. Або ж ярлик прикладної про-грами може залишатися навіть після того, як сама програма була вилучена. Все це не стосується Miracle V. Багато об’єктів Mi-racle V мають короткий життєвий цикл, наприклад задачі у пе- реліку незробленого або ярлик до документа. Якщо завдання надсилається усій групі і приймається членом групи, його треба негайно вилучити з переліку задач решти. Наведемо інший при-клад: якщо згаданий вище документ вилучається, ярлик до нього також повинен бути вилучений. WorkPlace відповідає за автома-тичне створення та вилучення цих типів об’єктів. 9.3.2.4. OO Model Studio Більша частина інструментарію Miracle V, за винятком інст-рументарію бізнес-процесів, згрупована в об’єктно-орієнтованій студії моделей (Object Oriented (OO) Model Studio). Це дозволяє швидко і безпосередньо змінювати структури даних, форми, до-кументи тощо відповідно до потреб підприємства. Деякі з компо-нентів OO Model Studio описані нижче. ? Class Master Додаток Class Master — це центральний інструмент визначен-ня класів. За його допомогою із використанням модифікацій від базових класів усі класи розміщуються в Repository і пов’язують-ся між собою. Засадничі класи були описані в розділі 9.3.2.1 — Repository. У Class Master здійснюється створення та зміна атрибутів і методів класу. Для деяких специфічних завдань Class Master використовує інші інструменти, наприклад, для модифікування методу Class Master переключається прямо в систему розробки. Як уже зазначалося, класи пов’язуються і поєднуються між собою у різні способи. Ці зв’язки легко створюються і вилуча-ються у Class Master. Клас також можна утворити від іншого. Новий клас тоді успадкує усі атрибути, методи та зв’язки ма-теринського класу. Ці наслідувані методи можна ігнорувати за допомогою макромови Miracle V. Класи також можуть бути пов’язані за допомогою асоціювання та поєднання. Таким чином утворюється їх надійна мережа. ? Transaction Processor Додаток Transaction Processor відповідає за те, щоб реєстрація та інформаційні потоки відповідали певним правилам. Інформа-ційні потоки вводяться та зберігаються як «документи». Це не обов’язково повинні бути типи документів, які друкуються, але можуть бути й такі. Кожна операція має системний статус доку-мента. Так, введення елемента запасів є операцією і, отже, доку-ментом. Операції є важливою частиною кожної інформаційної системи. Критично важливою є можливість зміни поведінки та правил інформаційних потоків відповідно до нових умов і по-треб. Кожна операція генерує інформаційний потік. «Майстри» (wizards) Miracle V підтримують моделювання операцій. У Miracle V існує низка майстрів, які підтримують властивос-ті операцій та документів. Окрім того, правила, згідно з якими реєструються операції, також можуть бути модифіковані — через системні обмеження або на вищому рівні. Операції (або документи) фіксуються у журналах. Деякі доку-менти можуть бути зареєстровані в декількох журналах. Який документ має бути зареєстрований та якому журналі, — це визначається користувачем. Журнали є основою для вибірок. Журнали і вибірки є дублюючими інформаційними потоками. Отже, існує можливість складати та модифікувати їх після здійснення операцій. ? Concentrator Додаток Concentrator є інструментом, тісно пов’язаним з Tran-saction Processor. Він дозволяє здійснювати безпосередній доступ до таких даних, як баланси, звіти про рух запасів тощо. Дублю-вання у формі вибірок є необхідним. Воно і є завданням компо-нента Concentrator. Залежно від пріоритетності вибірок вони мо-жуть бути створені в режимі безпосереднього доступу, за гра-фіком або «на вимогу». ? Система запитів Здійснення запитів даних є центральною функцією будь-якої інформаційної системи. Система запитів формулює усі запити до бази даних. Вона тісно співпрацює з Mask Designer і здатна створювати багато типів запитів. Система запитів перетворює (заснований на об’єктах) запит на розширений вираз SQL і автоматично виконує його. Результати можуть бути передані до генератора звітів або до будь-якої іншої прикладної програми Miracle V. Система запитів Miracle V дозволяє створювати складні запи-ти і користувачам, які мають поверхові знання щодо баз даних та програмування або взагалі їх не мають (рис. 9.26). Рис. 9.26. Система запитів ? Mask Designer За допомогою Mask Designer можна створювати нові форми та модифікувати існуючі. За необхідності кожен користувач може мати свої індивідуальні форми. За своїм спектром можливостей інструмент розробки форм відповідає таким добре відомим і розповсюдженим продуктам, як Visual Basic, Delphi, Access і т. ін. Будь-яка особа, що вже використовувала ці засоби, одразу зможе ефективно працювати з Miracle V Mask Designer. Наявні усі стандартні елементи управління. Якщо їх виявиться недостатньо, можна легко створити нові. Mask Designer тісно інтегрований із системою запитів, що дозволяє без зайвих зусиль вбудовувати запити у форми. Оскільки ергономічність перебувала у центрі уваги під час розробки Miracle V, то Mask Designer відіграє ключову роль у наданні користувачам саме тих форм, яких вони потребують, незалежно від характеру їхньої роботи та конкретних завдань (рис. 9.27). Рис. 9.27. Mask Designer ? Система розробки Для забезпечення максимально можливої гнучкості Miracle V була розроблена його власна макромова. Вона являє собою 32-бітну мову програмування, що повністю підтримує багато-поточність та засоби автоматизації OLE-2. Можливості й син-таксис цієї мови порівнювані з Visual Basic. Наявний також ін-тегрований наладчик, який дозволяє здійснювати віддалене налагодження. ? Генератор списків Miracle V надає у розпорядження користувача потужний ге-нератор звітів. До системи включений добре відомий і популяр-ний продукт ReportSmith. 9.3.2.5. Інтерфейс бази даних ? Інтерфейс бази даних Нижче зображена взаємодія між виконавчою системою Mi-racle V та заснованою на SQL базою даних (рис. 9.28). Рис. 9.28. Інтерфейс бази даних Інтерфейс поділений на два рівні. Це дозволяє підтримувати різні SQL-бази даних. Компонент вищого рівня інтерфейсу пере-кладає специфічні об’єктно-орієнтовані вирази Miracle V у стан-дартні вирази SQL. ? Communication Manager Miracle V підтримує стандартні інтерфейси — MAPI та TAPI. Це дозволяє надсилати електронну пошту або передавати пові-домлення на пейджер. Здійснюється це за допомогою Communi-cation Manager. 9.3.3. Прикладні додатки Miracle V Miracle V — інтегрована система бухгалтерського обліку, фінансового аналізу та управління підприємством. Вона повні-стю автоматизує товарообіг та облік, позбавляє від зайвих на-кладних витрат і підвищує дійсність та точність інформації. Своєчасна інформація, яку можна отримати за допомогою сис-теми Miracle V, надає можливість регулярно інформувати ке-рівництво підприємства про поточну фінансову ситуацію, стан розрахунків з дебіторами та кредиторами, про виконання замо-влень і платіжніх зобов’язань клієнтами, обіг кожної одини-ці/групи товару. Структура прикладних додатків Miracle V на-ведена на рис. 9.29. Рис. 9.29. Прикладні додатки Miracle V ? Адреси Введення бази даних адрес партнерів, замовників, постачаль-ників і просто всіх корисних контактних осіб; встановлення зв’язку з рухом товарів на складі; отримання інформації про дебіторів та кредиторів. ? Товари та складський облік Введення бази даних товарів (робіт, послуг та усього того, що є предметом купівлі, виробництва, продажу), контроль стану складів, реєстрація приходу товарів на склад, облік товарів у різ-них валютах, облік поставок на склад та відпуск з нього. ? Облік договорів Діяльність підприємства як виконавця (продавця, постачаль-ника продукції), автоматична підготовка документів (договір, за-явка, товарна накладна, рахунок, рахунок-фактура, квитанція, кредитове авізо) для відповідних господарських операцій та їх проводка по книгах обліку, формування дебіторської заборгова-ності клієнтів як результат поставки товарів. ? Складання замовлень Діяльність підприємства як замовника: формування замовлень на закупівлю товарів, контроль виконання поставок, автоматична підготовка нагадування постачальникам. ? Облік дебіторів Виставлення рахунків до оплати та формування дебіторських заборгованостей, проведення платежів, генерування відповідних бухгалтерських проводок і передача їх у модуль «Фінансовий облік». ? Каса Ведення касових операцій і автоматична передача результатів до обліку дебіторів / кредиторів і фінансового обліку, друк жур-налу-ордера і касових ордерів, ведення касової книги відповідно до українського законодавства. ? Банк Облік банківських операцій та передача результатів до обліку дебіторів/кредиторів та фінансового обліку, друк і запис до жур-налу платіжних документів, ведення реєстру платіжних докумен-тів, друк журналу-ордера. ? Касовий апарат Номенклатурний облік продажу товарів у роздрібній торгівлі та передача інформації до складського і фінансового обліку, мо-ж¬ливість ідентифікації товару за допомогою як приладу зчитування штрихового коду (сканера), так і клавіатури. ? Інвентаризація Приведення у відповідність облікової кількості складських за-пасів підприємства з їхньою наявною кількістю, виявлення нестач та надлишків, підготовка інвентаризаційних відомостей та пере-дача результатів до фінансового обліку. ? Фінансовий облік Ведення головного та декількох додаткових журналів підпри-ємства, приймання проводок, згенерованих в інших компонентах системи, підготовка балансу та інших підсумкових фінансових документів, аналіз поточного фінансового стану підприємства. ІНФОРМАЦІЙНІ СИСТЕМИ ДЛЯ МУЛЬТИНАЦІОНАЛЬНИХ КОРПОРАЦІЙ (МНК) 10.1. ОСОБЛИВОСТІ ІНФОРМАЦІЙНИХ СИСТЕМ ДЛЯ МНК Останні два десятиріччя позначені бурхливим розвитком міжнародних економічних зв’язків. Почали з’являтися вільні економічні зони і посилилась роль мультинаціональних корпорацій (МНК). Слід зазначити, що МНК стають зараз дедалі більш реальною економічною силою. Так, на частку їхнього внутрішньокорпораційного обігу припадає близько 1/3 усього міжнародного капіталістичного експорту. Мультинаціональні корпорації визначаються як «корпорації, що є національними за капіталом, але інтернаціональними за сфе¬рою своєї діяльності, котра здійснюється за кордоном відповідно до місцевих законів і особливостей. Інформаційна система як складова частина системи управління містить дані, необхідні МНК для планування, контролю, оцінки і координації своєї виробничої діяльності, включаючи операції за кордоном. Головним завданням вищої управлінсь- кої ланки МНК є забезпечення її економічного процвітання на міжнародному рівні, яке відбивається у неухильному зростанні прибутку. Вирішити це завдання набагато важче, ніж його сформулювати. У різних країнах до його вирішення підходять по-різному. У Японії управлінський персонал розробляє стратегію забезпечення прибутковості на довгостроковій основі. Німці найчастіше будують свою стратегію, виходячи з фактичних витрат, швейцарці більшою мірою орієнтуються на кон’юнктуру ринку — можливі будь-які витрати, аби вони окупилися у майбутньому, а італьянці розробляють свої довгострокові плани шляхом тривалих переговорів із своїми закордонними контрагентами, погоджень та взаєм¬них поступок. Скандинавські країни досить жорстко контролюють розташовані на їхній території мультинаціональні корпорації; у Голландії, навпаки, цей контроль більш ліберальний. Таким чином, потреба в обліковій інформації суттєво відрізняється не тільки в різних країнах, а й навіть між штаб-квартирою МНК та її закордонними дочірніми компаніями. Інформація, яка призначена для зовнішніх щодо МНК споживачів (акціонери, кредитори, наймити, клієнти) значною мірою надається у вигляді річних звітів фірми. Тому у подальшому предметом нашої уваги будуть інформаційні потреби внутрішніх користувачів — управлінського персоналу МНК. Управляюча ланка використовує внутрішню інформацію для планування, контролю й аналізу як у короткострокових, так і в довгострокових цілях. Наприклад, короткострокові (поточні) кошториси складаються на наступний рік і в подальшому використовуються для контролю й оцінки ефективності управління вироб¬ничою одиницею (філією компанії, розташованою за кордоном). Довгострокове планування поширюється зазвичай на п’ятирічний період, при цьому процес складання наступного річного плану є складовою часткою стратегічного курсу МНК та її дочірніх компаній. Для пошуку і прийняття управлінського рішення керівництву усіх рівнів необхідна деталізована формалізована інформація. Незалежно від способу організації інформаційної системи в МНК повинні враховуватись і відображатись усі економічні та політичні зміни, законодавчі обмеження, культурні відмінності й соціологічні особливості країни, в якій корпорація здійснює свою діяльність. Ця інформація надходить від керівників закордонних філій і являє собою огляд можливих змін валютного курсу у найближчий час, політичної ситуації (наприклад падіння тоталітарного режиму) і навіть змін купівельних симпатій та можливостей різних молодіжних угруповань (від панків до прихильників металевого року). Такі зовнішні чинники можуть не братися до уваги під час проектування інформаційної системи для компанії, яка не здійснює операцій на зовнішньому ринку, але для МНК вони надзвичайно важливі при прийнятті управлінських рішень. Дані, які опрацьовуються в інформаційній системі МНК, надходять до неї з різних внутрішніх та зовнішніх джерел і використовуються керівниками усіх рівнів для прийняття рішень, які можуть вплинути на ефективність операцій як на внутрішньому, так і на зовнішньому ринках. Ця інформація корисна не тільки для управлінської ланки, яка знаходиться у штаб-квартирі МНК. Вона дозволяє МНК впливати на економічне середовище, в якому функціонує її закордонна філія, допомагаючи останній підвищити ефективність своєї діяльності. Аналітичні можливості інформаційної системи МНК дуже великі, оскільки до неї надходять дані із усіх дочірніх компаній і у різних виглядах. Крім того, система повинна постійно адаптуватися до запитів користувачів, своєчасно реагувати на можливі зміни економічної ситуації, у якій працює МНК. Обсяг і якість інформації, яка надається управлінській ланці, повинні максимальною мірою сприяти досягненню короткострокових і довгострокових цілей МНК та її дочірніх компаній. На рис. 10.1 відображені дані, які надходять і циркулюють в інформаційній системі МНК. Рис. 10.1. Циркулювання даних у інформаційній системі 10.2. ОРГАНІЗАЦІЙНА ПОБУДОВА КОРПОРАЦІЙ Кожна МНК має декілька рівнів управління, які розрізняються мірою владних повноважень і відповідальності. Розподіл цих повноважень закріплюється в організаційній структурі управління. Цим визначаються і обсяги інформації, яка необхідна кожному рівню для планування і контролю своєї діяльності. Виходячи із запитів, проектуються також способи збору, опрацювання та подання даних у інформаційній системі. Таким чином, склад накопичуваних даних, способи опрацювання і надання їх повинні відповідати вимогам організаційної структури управління МНК і максимальною мірою задовольняти їх (рис. 10.2). Система управління МНК може передбачати використання одного з таких п’яти способів організації своєї діяльності, включаючи закордонну: ? створення самостійного підрозділу (відділення) із закордонних операцій; ? поділ діяльності за функціональною ознакою; ? поділ діяльності за виробничо-технологічними напрям-ками; ? поділ діяльності за регіональною ознакою; ? використання матричної організаційної структури управління. 1. Виділення підрозділу з міжнародної діяльності 2. Поділ діяльності за виробничо- технологічними підсумками 3. Поділ діяльності за функціональною ознакою 4. Поділ діяльності за регіональною діяльністю 5. Матрична організаційна структура Рис. 10.2. Форми організації діяльності МНК Створення самостійного підрозділу (відділення) із закор-дон¬них операцій. До компетенції цього підрозділу входить управ¬ління операціями виключно на зовнішньому ринку. Зазвичай цей підрозділ проводить свою діяльність незалежно, а за підсумками може порівнюватися з іншими підрозділами МНК, які здійснюють операції тільки на внутрішньому ринку. Прикладом корпорацій, які використовують таку форму організації закордонної економічної діяльності, можуть бути «Геркулес-Інкорпорейтед», «Квокер Оутс», «ЗМ Компані», «Аллайд кезмикал Інтернешнл». Поділ діяльності за функціональною ознакою. У цьому разі в діяльності корпорації виокремлюються такі функціональні напрями: виробництво, збут, облік тощо. Саме по цих функціях здійснюється централізований контроль. Так, віце-президент кор-порації зі збуту, штаб-квартира якої розташована у США, відповідатиме за усі маркетингові операції, у тому числі й поза межами США, а віце-президент із виробництва нестиме відповідальність за його організацію у всіх без винятку філіях корпорації. Така форма організації виробництва не знайшла значного поширення, вона притаманна лише галузям з вузькою номенклатурою продукції. Це передусім видобувні галузі — нафтовидобувна, вуглевидобувна та інші. Способи видобування і збуту нафти або вугілля не дуже розрізняються у різних країнах, тому керівництво може здійснюватися централізовано із штаб-квартири. Поділ діяльності за виробничо-технологічними напрямами. Ця форма організації є підсумком інтеграції внутрішніх і зовнішніх операцій. У корпорації виділяють декілька основних виробничо-технологічних ліній, кожна з яких займається вироб¬ництвом і збутом певного виду продукції. Продукція може реалізовуватися на будь-якому ринку збуту. Ефективність роботи кожної технологічної лінії оцінюють за загальним результатом, незалежно від того, яка частина продукції була реалізована на зовнішньому ринку. Така форма організації виробництва властива корпораціям, які мають широку і різноманітну номенклатуру продукції. Як приклад можна навести корпорацію «Дюпон». Поділ діяльності за регіональною ознакою. Тут операції, які виконуються корпорацією, поділяються за регіонами (Північна Америка, Європа і т.ін.). До цієї форми організації компанія звертається у тому разі, якщо її операції на зовнішньому ринку не обмежені одним регіоном або країною, а досить рівномірно розосереджені по всьому світові. Американські МНК загалом обмежуються внутрішнім ринком і тому не використовують такої організації своєї діяльності. Навпаки, остання нерідко притаманна європейським і японським корпораціям. За приклад може правити швейцарська компанія «Нестле», яка займається виробництвом і збутом продукції з шоколаду і какао-бобів. Використання матричної організаційної структури управління. Ця форма організації виробництва являє собою своєрідне поєднання декількох названих вище форм (наприклад, генеральний управляючий французьким відділенням корпорації зві¬тує про свою діяльність як перед віце-президентом корпорації з виробництва, так і перед віце-президентом по європейському регіону). У корпорації «Юніон-Карбайд» операції на зовнішньому ринку організовані за регіональною ознакою, водночас ведення обліку і звітності здійснюється за функціональною озна¬кою. У цьому випадку діяльність регіональних відділень розглядається не як складова частина діяльності корпорації на внутрішньому ринку, а як діяльність відокремлених структурних оди¬ниць, що несуть повну відповідальність за кінцеві фінансові результати. На рис. 10.2 наведені описані вище форми організації виробничої діяльності МНК. Як же впливає форма організації виробництва на інформаційну систему, що використовується у корпорації? Очевидно, що дані про операції на зовнішньому ринку інваріантні, змінюються лише інформаційні потоки. При цьому врешті-решт інформація поширюється серед усіх зацікавлених у ній служб корпорації. Так, якщо управління МНК організоване за регіональною ознакою, облікові дані акумулюються в окремому регіональному відділенні і потім передаються до штаб-квартири. За матричної організаційної структури управління дані можуть надходити декількома інформаційними потоками: наприклад, регіональному управлінському персоналу і безпосередньо до штаб-квартири корпорації віце-президентові з виробництва. Організаційна структура, система контролю і принципи роботи функціональних служб корпорації значною мірою визначаються позицією її вищого керівництва відносно організації бізнесу за кордоном. Сьогодні підходи, які мають місце у закордонній практиці, можуть бути класифіковані таким чином: — етноцентричний — передбачає тиражування на усі дочірні компанії принципів організації і ведення бізнесу, прийнятих у своїй країні; — поліцентричний — надає закордонній дочірній компанії певну самостійність у виборі форм та організації бізнесу; — геоцентричний — зорієнтований на максимальну уніфікацію принципів організації і ведення бізнесу, прийнятих у кожній країні. У мультинаціональній корпорації, яка використовує етноцен-т¬ричний підхід, вважають, що стандарти і принципи організації бізнесу, ухвалені в штаб-квартирі, є найкращими і тому поширюються на усі дочірні компанії, які здійснюють свою діяльність за кордоном. Керівництво поліцентричної МНК не тільки визнає існування певних національних особливостей у організації бізнесу, а й шукає можливості використання їх для збільшення прибутку. Тому її закордонні дочірні компанії функціонують досить автономно, у тому числі й у плані організації системи управління і контролю. Геоцентричний підхід зорієнтований на досягнення глобальних цілей. У цьому разі МНК та її закордонні дочірні компанії розглядаються як єдине ціле. В організації системи управління і контролю керівництво МНК намагається застосувати стандарти і принципи, які є універсальними, тобто прийнятними для будь-якої країни. Організаційна структура управління такої корпорації повинна максимальною мірою сприяти координації ухвалюваних рішень у глобальному масштабі. Реалізація геоцентричного підходу постає як мета будь-якої МНК, але тільки декотрі з них її досягли. Типовими представниками етноцентричного підходу постають автомобілебудівні корпорації. Серед них — «Дженерал Моторз» і «Крайслер» (США), «Фіат» (Італія), «Сітроєн» і «Рено» (Франція), «Мерседес-Бенц» і «БМВ» (ФРН), «Тойота» і «Ніссан» (Японія), «Сааб» (Швеція). Фармацевтичні компанії сповідують поліцентричний підхід. Так, фірма «Байєр» (ФРН) організує виробництво лікарських препаратів у своїх закордонних філіях як у достатньо автономних формуваннях. Голландсько-англійські фірми, як-от «Н. В.Філіпс Електрик» і «Юнівілер» є великою мірою геоцентричними. Представники багатьох країн входять до рад директорів цих фірм, обіймають вищі керівні посади. Позиція керівництва штаб-квартири фірми впливає також на делегування повноважень із прийняття найважливіших управлінських рішень. Якщо керівництво МНК дозволяє своїм закордонним філіям самостійно приймати важливі управлінські рішення, то така корпорація може розглядатися як децентралізована. Цей підхід нині набув надзвичайно-великого поширення. Закордонним філіям надається значна автономія, і тому їх керівництву постійно необхідна інформація для планування, контролю та оцінки своєї діяльності. У кожній дочірній компанії така інформація генерується у межах приватної облікової інформаційної системи. Водночас керівництву штаб-квартири корпорації також необхідна інформація про її закордонні підрозділи для планування, контролю, оцінки і координації діяльності у глобальному масштабі. Таким чином, облікова інформаційна система має бути запроектована з урахуванням задоволення запитів управлінського персоналу першого і другого рівнів управління. У разі, якщо прийняття рішення здійснюється в штаб-квартирі МНК, мова йде про централізовану корпорацію. Як правило, мультинаціональні корпорації не приймають централізовано усі управлінські рішення, але намагаються знайти розумне поєднання прав прийняття рішень на рівні штаб-квар¬тири МНК та її дочірніх компаній. Так, рішення з найважливіших питань стратегії управління МНК можуть прийматися у централізованому порядку; навпаки, рішення, які не є життєво важливими, можуть прийматися на більш низьких рівнях управління, у тому числі й керівництвом дочірніх компаній. У випадках фірм «ІВМ» і «Нестле» централізовано здійснюються дослідні й пошукові роботи, оскільки, на думку керівництва корпорацій, ці роботи життєво важливі у стратегічному плані і тому повинні контролюватися безпосередньо у штаб-квартирі МНК. Разом з тим багато питань, які належать до виробничої і комерційної діяль¬ності дочірніх компаній, вирішуються децентралізовано, оскільки фінансові успіхи або невдачі будь-якої з них не можуть значно впливати на становище корпорації загалом. 10.3. ВИМОГИ ДО ПРОЕКТУВАННЯ І ВПРОВАДЖЕННЯ ІНФОРМАЦІЙНИХ СИСТЕМ МНК Протягом багатьох років у компаніях США дані, які стосуються операцій на внутрішньому і зовнішньому ринках, відображались у межах однієї облікової інформаційної системи. Причин тому було декілька. По-перше, експорт уже готової облікової інформаційної системи для її використання у закордонній філії корпорації набагато дешевший, ніж проектування нової системи. По-друге, виходячи з цілей контролю, бухгалтерії штаб-квартири МНК зручніше одержувати від внутрішніх і закордонних компаній звіти за однаковими формами. По-третє, вище керівництво МНК, як правило, обізнане у принципах побудови внутрішньої облікової системи, тому її використанню за кордоном віддається перевага. Водночас застосування однієї системи для контролю діяльності закордонних дочірніх компаній нерідко виявляється неефективним. Річ у тім, що облікова система повинна проектуватись і функціонувати під впливом цілої низки зовнішніх чинників (політичних, економічних, соціальних, культурних і правових), які мають національні особливості. Простий експорт облікової системи не дозволяє врахувати ці чинники в повному обсязі, що часто призводить до негативних наслідків. Чотири основні функції фінансового контролю — вимір, комунікація, оцінка і мотивація — повинні враховувати особливості соціально-економічного стану будь-якої країни. На рис. 10.3 показана взаємодія функцій фінансового контролю і чинників зовнішнього середовища. Ці ж функції властиві й іншим системам контролю, застосовуваним у МНК, у тому числі й системам конт¬ролю виробництва і маркетингу. Рис. 10.3. Концептуальна модель системи фінансового контролю в МНК Приклад: МНК з штаб-квартирою в США має декілька закордонних дочірніх компаній. Усі її підрозділи у США діють як автономні виробничі одиниці, метою функціонування яких є максимізація чистого прибутку у доларах США. Її закордонні компанії не мають повної автономії у прийнятті управлінських рішень. Їхнє основне завдання — постачання американським підрозділам напівфабрикатів. Для ефективного планування і контролю своїх закордонних операцій штаб-квартирі МНК по-стійно необхідна інформація про валютні курси, вимоги до екс-порту та імпорту виробів, податкову політику в різних країнах. Ця інформація не є обов’язковою для роботи на внутрішньо- му ринку, тобто у взаємодії з підрозділами, які функціонують у США. Для оцінки діяльності закордонних філій такої МНК потрібні інші критерії, оскільки максимізація чистого прибутку у доларах США не є їхньою метою. Закордонні підрозділи повинні оцінюватися передусім як надійні й ефективні постачальники. Щоб зробити таку оцінку, штаб-квартирі корпорації потрібна принципово інша інформація про свої закордонні компанії, аніж інформація про підрозділи, які функціонують у США. Ще раз нагадаємо, що головною метою облікової інформаційної системи є надання інформації, необхідної для планування, контролю й оцінки діяльності фірми. Мультинаціональні корпорації можуть мати різну організаційну структуру управління, склад і спосіб взаємодії виробничих підрозділів. Інформація, потрібна для такого виробничого підрозділу, визначається цільовою функцією. Тому розробник облікової інформаційної системи для конкретної МНК повинен чітко уявляти: характер її діяльності, особливості її організаційної структури, міру централізації (децентралізації), рівень повноважень керівників різного рангу, інформаційні потреби кожного з них для прийняття виважених управлінських рішень. Розмір фірми, масштаби її господарської діяльності — це ще один із чинників, що визначає потреби в інформації. Для керівництва великою компанією, яка має складну організаційну структуру, необхідна більш різноманітна інформація, ніж для невеликої за обсягом і сферою діяльності фірми. Масштаб діяльності компанії безпосередньо пов’язаний з числом рівнів, на яких приймаються управлінські рішення. Залежно від прийнятої в компанії організації і філософії управління кожному рівню властива своя міра відповідальності і компетентності у вирішенні управлінських питань. Тому інформаційна система повинна забезпечити усі рівні управління інформацією, які різняться мірою деталізації, періодичністю надання, зорієнтованістю на ті чи інші аспекти діяльності. Наприклад, великі МНК нерідко більш централізовані — у цьому разі вище керівництво в штаб-квартирі МНК віддає перевагу більш жорсткому контролю дій апарату управління підрозділів фірми. І навпаки, невеликі компанії можуть надавати більшу свободу дій своїм закордонним філіям; отже, інформація, не¬обхідна для прийняття управлінського рішення, акумулюється на більш низькому рівні. Розмір і організаційна структура компанії можуть також впливати на технологію проходження інформації від закордонної дочірньої компанії до штаб-квартири МНК. Наприклад, якщо у великій МНК створено самостійний підрозділ із закордонних опе¬рацій, то інформація від компаній, які функціонують у Європі, спочатку надається керівництву європейського відділення і тільки після цього — керівництву підрозділу. Таким чином, кожен із названих вище чинників повинен бути взятий до уваги під час розробки інформаційної системи, яка б гарантувала у майбутньому якісне інформаційне забезпечення стратегічного планування, контролю та аналізу діяль- ності МНК. Розвиток інформаційних систем пов’язаний з удосконаленням їх математичного і технічного забезпечення. Такі методи, як статистичний аналіз, лінійне програмування, регресивний аналіз, знач¬но підвищують ефективність використання інформації. Коли корпорація здійснює свою діяльність у різних регіонах світу, територіальна віддаленість джерел інформації зазвичай впливає на її своєчасність, якість і вірогідність. Тому застосування комп’ютерів і електронних комунікацій дозволяє мати більш якісну інформаційну систему, яка забезпечить функціонування систем прийняття рішень значно вищого рівня. 10.4. ІНТЕГРОВАНА ІНФОРМАЦІЙНА СИСТЕМА ДЛЯ УПРАВЛІННЯ МНК R/3 Інформаційна система R/3 розроблена німецькою фірмою SАР. Сфера застосування R/3 — від транснаціональних концернів до середніх підприємств. Вона локалізована (русифікована), адаптована до російського та українського законодавств. R/3 характеризується всебічною функціональністю, що охоплює весь економічний спектр діяльності підприємства. Перевага системи R/3 полягає у високому ступені інтеграції її додатків. R/3 виходить із того, що господарська операція не обмежується однією бізнес-функцією, тому зміна в одній із структур викликає відповідні трансформації в інших. Приміром, відпуск матеріалу зі складу у виробництво приводить не тільки до зменшення запасу на складі, але й викликає автоматичне виконання відповідних бухгалтерських проводок, а також операцій, пов’язаних з обліком витрат на виробництві і розрахунком собівартості виробленої продукції. Таким чином, єдина інформаційна база системи в будь-який момент відбиває актуальний стан підприємства і виключає дублювання даних, тобто система працює в режимі «реального економічного часу». Як робоче місце користувача найчастіше застосовується персональний комп’ютер із встановленою оболонкою Windows або бездискова робоча станція. Прикладні програми виконуються на серверах додатків. Вони здійснюють безпосередню взаємодію із серверами баз даних, що використовують такі СУБД, як Оrасlе, NFORMIX, ADABAS та MS SQL SERVER. Сервери можуть працювати під керуванням UNIХ і Windows NТ. Зв’язок між компонентами R/3 підтримує через локальні і глобальні мережі на базі поширених мережних протоколів: ТСР/IР, SNA та IРХ/SРХ. Ще однієї важливою особливістю R/3 є відкритість системи. Взаємозв’язок між додатками R/3, а також між R/3 та іншими системами здійснюється на рівні обміну повідомленнями, контролюється через концепцію АLЕ (Application Link Enabling). R/3 підтримує також стандарти OLЕ (Object Linking and Embedding), RFC (Remote Function Call) та ODBC (Open DataBase Connec¬tivity). 10.4.1. Функціональність системи На рис. 10.4 показана модульна структура системи R/3. Хоча всі модулі взаємозалежні, умовно їх можна поділити на фінансові модулі і модулі логістики (пов’язані з виробництвом). Система фінансового обліку і звітності найтісніше пов’язана з іншими модулями і стосується до всіх відділів і служб підприємства. Система логістики охоплює такі галузі діяльності підприємства, як управління матеріальними потоками, закупівля матеріалів, планування і управління виробництвом, збут готової продукції. Модулі логістики інтегровані з фінансовими модулями. Будь-який рух матеріалу може породжувати автоматичну бухгалтерську проводку, що відбивається на рахунках підприємства. Система логістики відповідає стандартній концепції MRP II (планування виробничих ресурсів) і вимогам СІМ (комплексне автоматизоване виробництво). Система класифікації дозволяє класифікувати матеріали (комплектуючі, заготовки і т. ін.), кредиторів, дебіторів, документи. Можливе паралельне ведення декількох класифікацій. Крім господарських функцій, R/3 пропонує набір офісних функцій, пов’язаних із підтримкою електронного документообігу на підприємстві, — від електронної пошти і управління проходженням документів до оптичного архівування документів. Оптичне архівування забезпечує можливість збереження оригінальних зображень первинних господарських документів і безпосередній зв’язок їх із даними в системі R/3. До цієї ж групи можна віднести і функції електронного обміну даними з банками та іншими партнерами підприємства. Рис. 10.4. Модульна структура системи R/3 10.4.2. Інформаційні підсистеми Як правило, сучасні підприємства відчувають дефіцит не в кількості даних, а в концентрованій інформації для управління і контролю. Тому важливою функцією системи R/3 є інформаційне обслуговування середньої і вищої управлінських ланок підприємств. Замість маси оперативних даних цим ланкам потрібна добірка інформації, що відбиває різні аспекти господарської діяльності підприємства, а також зведення про фактичний стан ринку. Необхідне й автоматичне відстежування особливих ситуацій, графічне подання їх. Ці вимоги приводять до концепції відкритості інформації (рис. 10.5), що передбачає накопичення даних як із додатків R/3, так і з зовнішніх систем та адаптації їх до вимог виробництва і персоналу управління. Рис. 10.5. Інформаційні підсистеми R/3 Завдяки реалізації цієї концепції з’являються нові можливості децентралізованого «самоконтролю» на рівні користувацьких відділів. Це раціональне логічне рішення реалізоване і в системі логістики (LIS), і у фінансовій системі (FIS), і в системі аналізу внутрішньогосподарської діяльності (СIS), і в системі управління персоналом (НIS). Виконавча система вищого рівня (ЕІS) дозволяє пов’язати факти з різних організаційних сфер діяльності підприємства. Доступ до інформації, необхідної для ухвалення рішення, досягається через графічне інтуїтивне операційне середовище користувача. Основа системи ЕІS — власна база даних та інструмент для наповнення її інформацією. У ній накопичуються дані з прикладних програм R/3 та інших систем і зовнішніх джерел, у тому числі й з віддалених. Структуру бази даних ЕIS можна конфігурувати відповідно до потреб менеджера. ЕIS має діалогові засоби візуалізації звітів і показників. За допомогою електронної пошти ЕIS підключається в комунікаційну структуру підприємства, що дозволяє надсилати опрацьовані й прокоментовані звіти будь-якій кількості адресатів. Підключивши ЕIS до системи «Управління документацією R/3», можна комбінувати інформацію, що пересилається, з іншими документами і графічними зображеннями. 10.4.3. Інструменти розробки Система R/3 містить вбудовану САSЕ-систему для власних внутрішніх розробок — АВАР/4 Development Workbench (рис. 10.6). У її основу покладена мова 4-го покоління АВАР/4 (Advanced Business Application Programming), спеціально орієнтована на ство¬рення бізнес-додатків у середовищі клієнт/сервер. Рис. 10.6. Інструментальні засоби R/3 Доступ до баз даних реалізується через інтегрований у середовище розробки словник даних, що містить загальні для всіх додатків опису метадані (таблиці, структури, елементи даних, домени, правила перетворення та інші об’єкти). Будь-які зміни в словнику негайно стають доступними для всіх додатків. Доступ до даних здійснюється за допомогою SQL-запитів. САSЕ-система орієнтована на колективну розробку програм і підтримку проектів і містить інтегрований редактор, відладчик, засоби аналізу ви¬конання програм та їхньої оптимізації (SQL-Тrасе та АВАР/4 Тrасе), керування версіями, засоби документування програм, бібліотеки готових модулів. Для діалогового проектування екранних інтерфейсів і упорядкування звітів використовуються генератор екранних форм (Screen Painter), редактор меню (Menu Painter), генератор звітів (Report Writer). АВАР/4 Repository є основним інструментом збереження і доступу до всіх об’єктів розробки, як-от АВАР/4 — модулі, екрани, об’єкти, словники, моделі даних, авторизації. Під¬тримка механізмів OLЕ і RFC (Remote Function Call) забезпечує зв’язок із зовнішніми додатками. З АВАР/4-модулів можливі виклики програм мовами С та Visual Basic. Мова АВАР/4 може використовуватися також для модифікації звітів і для організації інтерфейсів із зовнішніми системами і базами даних.

Вітаємо, ви успішно прочитали книгу!