Управління проєктом створення інформаційної системи турагенства

Липний, Василь Віталійович

Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/7298

Title:	Управління проєктом створення інформаційної системи турагенства
Authors:	Прокопенко , Тетяна Олександрівна Липний, Василь Віталійович
Keywords:	управління проєктом;WBS;інформаційна система;турагенство;операційна діяльність
Issue Date:	4-Dec-2021
Abstract:	Інвестиційна діяльність в сучасних умовах тісно пов'язана з умінням розробити ефективний інвестиційний план або проєкт, а потім забезпечити визначені ними об-меження по ресурсах і реалізувати заданий рівень якості продукції проєкту. Тому гостро постає питання про необхідність забезпечення ефективного управління проєктом. Успіх кожної організації залежить від її здатності адаптуватися на зміни зовнішнього оточення. Саме поняття «зміни» є сутністю будь-якого проєкту, а уп-равління проєктами розглядається як універсальна методологія управління такими змінами. Управління проєктами не є чимось незвичайним – це найбільш ефективний засіб досягнення результату. Краще або гірше, у залежності від умінь, інтуїції й уда-чі менеджерів, проєкти завжди повинні бути керовані. Практично завжди під час реалізації проєктів в галузі інформаційних техноло-гій виникає визначений набір невирішених проблем, таких як збільшення обсягу операцій і зменшення швидкості роботи системи, використання могутньої системи не на повну потужність, перетворення впровадження в нескінченний процес, постій-ну зміну вимог і т.д. Управління ризиками в проєкті, може повністю або частково запобігти цим ситуаціям. Знаючи методи і аналізи боротьби з ризиками і використо-вуючи їх в управлінні проєктами в галузі створення інформаційної системи, можна уникнути зриву проєкту, оскільки сама галузь створення інформаційних систем є до-сить не прогнозованою. Управління проєктами [15] у широкому розумінні – це професійна діяльність, заснована на використанні сучасних наукових знань, навичок, методів, засобів і тех-нологій і орієнтована на одержання ефективних результатів. Застосування методології управління проєктами дає можливість чітко визна-чити мету і результати проєкту, дати їм кількісні характеристики, тимчасові, вартісні і якісні параметри проєкту, створити чіткий план проєкту, виділити, оцінити ризики і запобігти можливі негативні наслідки під час реалізації проєкту.
URI:	https://er.chdtu.edu.ua/handle/ChSTU/7298
Appears in Collections:	126 Інформаційні системи та технології (IT Project Management)

Files in This Item:

File	Description	Size	Format
МА_Липний_Василь_МІТ-2010.pdf Restricted Access		1.26 MB	Adobe PDF	View/Open Request a copy

Show full item record

Extracted text

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ

ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ

Кафедра інформаційних технологій проектування

Пояснювальна записка
до кваліфікаційної роботи

магістра
(освітньо-кваліфікаційний рівень)

на тему: «Управління проєктом створення інформаційної системи турагенства»

Виконав: студент 2 курсу, групи МІТ-2010
Спеціальності
122 «Комп’ютерні науки» »
(шифр і назва спеціальності)
Освітньої програми
Управління ІТ-проектами я

Липний В.В.
(прізвище та ініціали)
Керівник Прокопенко Т.О.
(прізвище та ініціали)
Рецензент Катаєв Д.С.
(прізвище та ініціали)

Черкаси 2021 року

Зміст стр.

Управління проектом створення інформаційної системи управління
турагенством
Вступ ...............................................................................................................
Розділ 1 Концепція проекту створення інформаційної системи управ-
ління турагенством ……..
1.1 Опис предметної області розробки інформаційних систем для
туристичних компаній .........................................
1.2 SWOТ та PEST аналізи проекту………………………………….
1.3 Резюме проекту...........................................................................
Розділ 2 Управління проектом створення інформаційної системи. уп-
равління турагенством……………………………………………...........
2.1 Управління інтеграцією та інформаційними зв’язками проекту
2.2 Управління змістом проекту (WBS - структура)..........................
2.2.1 Ієрархічна структура робіт................................................
2.2.2 WBS – структура проекту по створенню ІС....................
2.3 Управління часом проекту.............................................................
2.4 Управління трудовими ресурсами проекту..................................
2.5 Управління вартістю проекту........................................................
2.6 Управління якістю проекту...........................................................
2.7 Управління закупками проекту.....................................................
2.8 Управління ризиками проекту……………………………………
2.9 Управління змінами проекту..........................................................
2.10 Контроль проекту
Розділ 3 Оцінка ефективності проекту. створення інформаційної систе-
ми. управління турагенством…………........................................................
3.1. Планування фінансових ресурсів інвестиційної фази проекту
3.2. Розробка зведеного кошторису витрат інвестиційної фази
5

проекту
3.3. Планування амортизаційних витрат операційної діяльності
3.4. Прогноз доходів та витрат операційної діяльності
3.5. Прогноз грошових потоків проекту
3.6. Оцінка показників ефективності проекту
3.7. Оцінка соціальної ефективності проекту
Висновки..........................................................................................................
Список використаної літератури..................................................................
Додатки……………………………………………………………………..
6

Вступ

Інвестиційна діяльність в сучасних умовах тісно пов'язана з умінням розроби-
ти ефективний інвестиційний план або проєкт, а потім забезпечити визначені ними
обмеження по ресурсах і реалізувати заданий рівень якості продукції проєкту. Тому
гостро постає питання про необхідність забезпечення ефективного управління
проєктом. Успіх кожної організації залежить від її здатності адаптуватися на зміни
зовнішнього оточення. Саме поняття «зміни» є сутністю будь-якого проєкту, а управ-
ління проєктами розглядається як універсальна методологія управління такими змі-
нами. Управління проєктами не є чимось незвичайним – це найбільш ефективний за-
сіб досягнення результату. Краще або гірше, у залежності від умінь, інтуїції й удачі
менеджерів, проєкти завжди повинні бути керовані.
Практично завжди під час реалізації проєктів в галузі інформаційних техноло-
гій виникає визначений набір невирішених проблем, таких як збільшення обсягу опе-
рацій і зменшення швидкості роботи системи, використання могутньої системи не на
повну потужність, перетворення впровадження в нескінченний процес, постійну змі-
ну вимог і т.д. Управління ризиками в проєкті, може повністю або частково запобігти
цим ситуаціям. Знаючи методи і аналізи боротьби з ризиками і використовуючи їх в
управлінні проєктами в галузі створення інформаційної системи, можна уникнути
зриву проєкту, оскільки сама галузь створення інформаційних систем є досить не
прогнозованою.
Управління проєктами [15] у широкому розумінні – це професійна діяльність,
заснована на використанні сучасних наукових знань, навичок, методів, засобів і тех-
нологій і орієнтована на одержання ефективних результатів.
Застосування методології управління проєктами дає можливість чітко визначи-
ти мету і результати проєкту, дати їм кількісні характеристики, тимчасові, вартісні і
якісні параметри проєкту, створити чіткий план проєкту, виділити, оцінити ризики і
запобігти можливі негативні наслідки під час реалізації проєкту.
Актуальність теми. Застосування проєктного підходу в процесі впровадження
програмного продукту для туристичних компаній на базі СК «Глобус», м. Черкаси є
7

актуальним науковим завданням, що дасть можливість підвищення ефективності
використання необхідних ресурсів та дотриматись заданих часових рамок.
Мета дослідження. Метою даної дипломної роботи є розкрити методологію
управління проєктом впровадження програмного продукту для туристичних компа-
ній на базі СК «Глобус», м. Черкаси за допомогою теоретичних знань та практичних
навичок, що були здобуті за час навчання.
Для досягнення поставленої мети були сформульовані та вирішені такі за-
вдання дослідження.:
- визначити цілі проєкту;
- підготовити обґрунтування та концепцію проєкту;
- структурувати проєкт (підцілі, підпроєкти, фази і т.д.);
- визначити фінансові потреби і джерела фінансування;
- підбор постачальників, підрядчиків і інших виконавців (на основі процедур то-
ргів і конкурсів);
- підготовка і висновок контрактів;
- розрахувати кошторису і бюджету проєкту;
- визначити терміни виконання проєкту і розробити графік реалізації;
- забезпечити контроль за ходом виконання проєкту і внесення коректив у план
реалізації;
- управління ризиками в проєкті.
Об’єктом дослідження є проєкт впровадження програмного продукту для ту-
ристичних компаній на базі СК «Глобус», м. Черкаси.
Предмет дослідження – методи та засоби управління проєктом впровадження
програмного продукту для туристичних компаній на базі СК «Глобус», м. Черкаси.
Галузь дослідження - галузь інформаційних технологій.
Методи дослідження. В роботі застосовані методи проєктного менеджменту
згідно PMBok.
Наукова новизна одержаних результатів. Вперше застосовано метод дерева
цілей при формулюванні цілей проєкту впровадження програмного продукту для
туристичних компаній на базі СК «Глобус», м. Черкаси.
8

Практичне значення одержаних результатів. Практична значимість даної ро-
боти полягає в тому, що теоретичні положення та висновки знайшли своє безпосе-
реднє застосування в ході управління проєктом впровадження програмного продук-
ту для туристичних компаній на базі СК «Глобус», м. Черкаси.
Апробація результатів роботи і публікації. Результати дипломної роботи
представлені в журналі «Вісник ЧДТУ», стаття «Застосування методів ситуаційного
аналізу в управлінні ІТ проєктами» номер 1, 2017 р., ст. 94 -98.

9

РОЗДІЛ 1. КОНЦЕПЦІЯ ПРОЄКТУ РОЗРОБКИ ІНОРМАЦІЙНОЇ СИСТЕМИ
УПРАВЛІННЯ ТУРАГЕНСТВОМ

1.1 Опис предметної області розробки інформаційних систем для туристичних
компаній

Проєкт – це тимчасова діяльність, призначена для створення унікальних про-
грамних продуктів для IT сфери або послуг.
Найчастіше проєкти є засобом організації роботи по створенню нових про-
дуктів, до того ж ступені новизни продукту можуть мінятися від світового рівня до
локальної новизни(новизни для даної організації). Прибуток проєкту суттево зале-
жить від рівня новизни, до того ж: чим вищий рівень новизни, тим вищий рівень
прибутку.
Характеристики проєкту:
● тимчасовість;
● унікальність(від світового рівня до локального);
● наукова ємність проєктних рішень;
● терміни виконання;
● затрати на проєкт;
● рентабельність проєкту(прибуток);
● рентабельність створеного продукту
Управління проєктами — це система організації робіт по створенню нового IT
продукту, яка забезпечує задоволення вимог, що пред'являються до проєкту. Управ-
ління проєкту передбачає застосування нових наукових знань, навичок, інструментів
і методів операцій по проєкту.
Проєктний менеджмент — процес управління командою, ресурсами проєкту за
допомогою спеціальних методів та прийомів з метою успішного досягнення постав-
леної мети. Класично найважливішими параметрами у процесі управління проєктом
вважають виконання роботи у заданих обсягах, вчасно і в межах виділених коштів.
10

Американський Інститут управління проєктами розробив сертифікаційну про-
граму, в якій, окрім етичного кодексу і професійного досвіду, було визначено про-
фесійні знання, відомі як Project Management Body of Knowledge (PMBOK). PMBOK
[10] складається з дев’яти функцій: менеджменту обсягів, затрат, часу, якості, люд-
ських ресурсів, комунікацій, контрактів/постачання, ризиків, проєктної інтеграції.
Перші чотири функції (спрямовані на управління цілями) заведено називати ос-
новними. Це такі функції:
Управління обсягом проєкту — контролює проєкт за допомогою встановлення
його мети, завдань і цілей.
Управління затратами — передбачає фінансовий контроль проєкту завдяки
накопиченню, аналізу та складанню звітів по затратах.
Управління часом — передбачає планування, складання календарних графіків
та їх контроль для забезпечення вчасного виконання проєкту.
Управління якістю — забезпечує виконання стандартів якості, встановлених
для проєкту.
П’ять функцій, перелічених нижче (спрямовані на управління певними
об’єктами), називають додатковими:
Управління людськими ресурсами — включає спрямування і координацію
діяльності людей, залучених до проєкту.
Управління комунікаціями — накопичує інформацію, якою обмінюються члени
проєктної команди, керівництво, і сприяє успішному завершенню проєкту.
Управління контрактами/постачанням — передбачає відбір, переговори і підпи-
сання замовлень, контроль за постачанням матеріалів, устаткування і послуг (обслу-
говування).
Управління ризиком — залежить від ступеня невизначеності проєкту і базуєть-
ся на знаннях та досвіді із зазначенням умов реалізації конкретного проєкту.
Управління проєктною інтеграцією — має забезпечити належну координацію
всіх функцій проєкту.
Як бачимо, основні функції PMBOK визначено за цілями, за досягнення яких
відповідає проєктний менеджер, а додаткові — за об’єктами, на які спрямовується
11

діяльність керівника. Проте в назві всіх цих функцій наявне спільне слово управлін-
ня, що, в свою чергу, передбачає виконання в їх межах таких функцій управління, як
організація, планування, контроль, мотивація. Інакше кажучи, проєктний менеджер
повинен здійснювати основні функції управління щодо специфічних цілей та
об’єктів очолюваних ним проєктів.
IT сфера є одним з найбільш прогресивних напрямків бізнесу, що розвивається
дуже швидкими темпами як в Україні, так і в цілому світі. Основним видом діяль-
ності є розробка продуктів та сервісів Інтернет Технологій. Як свідчать дані НБУ за
2014-2015 рік, IT індустрія має дуже великий внесок у ВВП країни. Дохід на 2014
рік складає 18.1 млрд. гривень (за даними Horizon Capital), при цьому є стабільна
сплата податків. На 2014-2015 рік налічується 74 000 - 100 000 IT спеціалістів, що
працюють у даній сфері.
Прогнози говорять про те, що до 2020 року очікується зростання обсягу галузі
до 182 млрд грн. в рік, також збільшиться кількість робочих місць до 180 000, тобто
20 000 нових місць щорічно (Рис.1). Варто також відмітити, що на сьогодні середня
заробітна плата ІТ спеціаліста становить 2 000 $.
Існує щонайменше 3000 ІТ компаній в Україні. В Черкасах їх налічується бли-
зько 40ка.

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

відпочинку. Щорічно туристичні компанії відправляють за кордон понад 12000 ту-
ристів. Значна увага в роботі компанії приділяється інновація та новітнім техно-
логіям. В даний момент існує потреба в розробці інформаційних систем, що забез-
печувала б можливості онлайн роботи з клієнтом, де можна було б здійснити пошук
турів по всіх туроператорах України. Також необхідна зручна система пошуку, де
кожен мав би змогу підібрати собі потрібну пропозицію за найвигіднішою ціною.
Основними принципами роботи компанії є відповідальність, професіоналізм та
індивідуальний підхід до кожного клієнта, збереження репутації. Туристичні ком-
панії тісно співпрацюють з туроператорами, для яких основним критерієм є
надійність.
Головною метою туристичних компаній є розвиток внутрішнього туризму в
Україні, розробка нових оригінальних маршрутів. Більшість туристичних компаній
є туроператорами по Україні і працюють за двома напрямками - внутрішній та виїз-
ний туризм.
Кожний туристичний маршрут розробляється безпосередньо менеджерами
компанії. Працівники компанії плідно відшукують цікаві факти з української
історії та культури, особисто виїжджають в місця, з ними пов’язані, готують марш-
рути і доповнюємо їх якісним сервісом. В Україні є досить багато історичних ма-
ловідомих місць, які варто відвідати. Туристична компанія повинна забезпечувати
виконання наступних послуг:
 Виїзд менеджера в офіс або додому з каталогами
 Бронювання готелів по всьому світу
 Допомога в підготовці документів в консульство і їх переклад на іно-
земні мови
 Доставка документів додому або в офіс
 Готівковий і безготівковий способи оплати турів
 Медичне страхування
 Продаж і поповнення карток Тревел СІМ.
Тому для туристичної компанії необхідна така інформаційна система управлін-
ня, що надавала б такі можливості:
13

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

1.2 SWOТ та PEST аналізи проєкту

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

Методологія проєктного менеджменту є одним з тих небагатьох засобів управ-
ління, за допомогою яких досягається більш високий рівень якості управління, оп-
тимізації та інновації.
Реалізація проєкту вимагає виконання певної кількості різноманітних заходів і
робіт, які для зручності розгляду можна поділити на дві групи: основна діяльність і
діяльність із забезпечення проєкту. Такий поділ є поділом процесу реалізації проєк-
ту на фази і стадії, оскільки ці види діяльності часто не співпадають у часі.
При формулюванні стратегії впровадження програмного продукту (інфор-
маційної системи) необхідно чітко уявляти, можливості та загрози ринку. Процес
всебічного пристосування підприємства до зовнішніх і внутрішніх умов характер-
ний для ринкових умов господарювання обумовлюється загальною макроекономіч-
ною ситуацією, зміною кон’юнктури ринку чи впливом внутрішніх факторів підпри-
ємства. Для ефективного розвитку в конкурентному середовищі підприємство по-
винне мати певний рівень прибутку, постійно збільшувати свою ринкову вартість,
зберігати та збільшувати частку ринку. А це, в свою чергу, передбачає постійні змі-
ни на підприємстві в організаційній структурі, технології, управлінні.
SWOТ-аналіз - це аналіз зовнішнього та внутрішнього середовища організації.
Аналізу підлягають сильні сторони (Strength), слабкі сторони (Weakness) внутріш-
нього середовища, а також можливості (Opportunities) і загрози (Threats) зо-
внішнього середовища організації [14].
Згідно методології SWOT-аналізу необхідно виявити сильні та слабкі сторони,
можливості і загрози проєкту впровадження програмного продукту (ІС для туристи-
чних компаній). Після цього встановлюються зв'язки між ними, які в подальшому
можуть бути використані для формулювання подальшої стратегії проєкту впро-
вадження програмного продукту (ІС для туристичних компаній). SWOT-аналіз
проєкту впровадження програмного продукту (ІС для туристичних компаній) наве-
дений в таблиці 1.1

15

Таблиця 1.1.
Результати SWOТ-аналізу проєкту впровадження програмного продукту (ІС для ту-
ристичних компаній).
Strengths Opportunities
(конкурентні переваги) (сприятливі обставини, використання
яких створює переваги)
1. Високий рівень контролю якості; 1. Необхідність в розробці ІС;
2. Зростання оборотних коштів; 2. Ритмічна робота проєктної коман-
3. Досвід роботи з клієнтами; ди;
4. Концентрація на певних продуктах 3. Погіршення позицій конкурентів;
та послугах; 4. Співпраця з зарубіжними партне-
5. Передові інформаційні технології рами;
та висока якість обслуговування; 5. Удосконалення менеджменту;
6. Висококваліфікований персонал та 6. Надання послуг он-лайн;
досконала система управління; 7. Участь в міжнародних проєктах
7. Ефективна взаємодія з місцевими
органами влади.
Weaknesses Threats
(слабкі сторони) (фактори, які потенційно можуть погір-
шити становище на ринку)
1. Некомпетентність персоналу у пи- 1. Нестабільність політичного сере-
таннях прийняття управлінських довища;
рішень; 2. Економічна депресія;
2. Погане управління активами; 3. Можливі великі коливання курсу
3. Не виділяються та не вдосконлю- обміну валюти;
ються основні бізнес-процеси; 4. Вихід на ринок нових конкурентів;
4. Надмірний ріст персоналу. 5. Збільшення податків.

16

PEST - аналіз дає можливість виявлення політичних (P - political), еко-
номічних (E - economic), соціальних (S - social) і технологічних (T - technological)
аспектів зовнішнього середовища, які впливають на реалізацію інвестиційної фази
проєкту будівництва торгівельного центру.
Таблиця 1.2.
PEST аналіз проєкту впровадження програмного продукту (ІС для туристичних ком-
паній).
Група фак-
торів Фактор Опис

В 2021 році керівництвом планується
Політичне Законодавство стабілізувати ситуацію. Планується ряд реформ, нових
середовище
законів, які можуть суттєво вплинути на розвиток ІТ
галузі
Регулювання
міжнародної Ризиком є зростання валютного курсу
торгівлі
Економічні Економічне За оцінками експертів в 2021 році очікується по-
фактори зростання вільне стабілізування ринку нерухомості
Радикальні зміни, які відбулися в політиці опо-
даткування на 2020 рік, дозволяє вважати, що протягом
Оподаткування 2020 року податкове законодавство буде піддане ряду
доопрацювань та змін у рамках моделі, запропонованої
в Податковому Кодексі.
Соціальні Перерозподіл В зв’язку з виходом країни з економічної кризи,
фактори сімейних бюд- підвищеням соціальних стандартів планується збіль-
жетів шення попиту на придбання товарів та послуг.
Розвиток зеле- Зростає відсоток компаній в Україні які плану-
Технологічні ної енергетики ють модернізацію, запровадження нових технологій,
використання сучасної техніки та обладнання.

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

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

1.3. Концепція проєкту

Проєкт розробки ІС управління турагенством, що представляється нам, як
принципово нова система, що автоматизує повний спектр обліку інформації, що увіб-
рала в себе багаторічний досвід групи програмістів і аналітиків СК «Глобус».
Метою проєкту розробки ІС управління турагенством є підвищення ступеню
автоматизації роботи фірми в рамках єдиної архітектури на рівні, що не уступає веду-
чим вітчизняним розробкам. Дерево цілей представлене на рисунку (Рис. 1.4). Дру-
горядною метою проєкту є створити ІС управління туристичним агенством, щоб ма-
ти можливість продати її іншим фірмам чи організаціям даної галузі, при чому, щоб
дана ціль не зашкоджувала головній меті проєкту для даної організації.
Впроваджена інформаційна система забезпечить такі можливості:
- підтримка організаційних процесів управління туристичним агентством шля-
хом обміну, обробки інформації та прийняття рішень,створення інфраструк-
тури, що сприяє підняттю ефективності інформаційного обміну;
- редагування лінії, аналізу інформації про туристичні тури, редагування клієн-
тів, створення таблиць для автоматичного розрахунку вартості турів;
- введення результатів, статистики, розрахунку вартості турів, отримання дета-
льної інформації по кожній касі (адреса, валюта, поштова скринька, телефон),
18

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

Рисунок 1.2 Дерево цілей

Дерево цілей має чотири рівні завдань. Опис та шляхи досягнення цілей пред-
ставлені в таблиці (Табл. 1.3)

Таблиця 1.3
Опис та шляхи досягнення цілей
Код Вага
Ціль Шляхи досягнення цілі
С Створення конкурентно зда-
тного програмного продукту Розробити програмний продукт для 1

19

Продовження табл.1.3

С Автоматизація роботи тура- Розробити інформаційну систему для робо-
1 генства ти персоналу турагенства 0,65

С Створення рентабельного Розробити програмний продукт для клієнтів
2 програмного продукту турагенства 0,35

С11 Розробка АРМів працівників Розробити технічний комплекс разом з ор-
ганізаційно-технічними регламентами 0,15

С12 Створення WEB сайту Розробити WEB сайт 0,20
С21 Розробка якісного продукту Розробка продукту у відповідності до стан-
дартів 0,05

С Мінімізація витрат на підт- Просування через пошукові системи та со-
22 римку ціальні мережі 0,45

С Розробка програмного за- Розробка фунціоналу із застосуванням су-
111 безпечення часних мов програмування 0,15

С Впровадження програмного
112 продукту Підтримки та навчання персоналу 0,08

С Розробка Розробтити інтерфейс для взаємодії між ко-
121 Front end ристувачем і 0,15
back end
С122 Розробка back end Розробити бази даних та функціонал 0,07
Забезпечення належного рі-
С вня якості за допомогою те- Проведення тестування, розробка тестової
211 стування та тестової доку- документації 0,12

ментації
С Забезпечення коректності та
212 надійності розробки Перевірка функціоналу, пошук багів 0,08

С Забезпечення стабільного
221 функціонування продукту Розробка точних проєктних рішень 0,35

С Розвиток продукту Впровадження покращень та необхідних
222 змін 0,10

20

За класом проєкту (складом і структурою самого проєкту та його предметної
галузі) проєкт розробки ІС управління турагенством є:
1) за класом – монопроєкт;
2) за типом – економічний;
3) за видом – інвестиційний;
4) за тривалістю – короткостроковим;
5) за масштабом – середній;
6) за ступенем складності – простий.
Вимоги до результату проєкту:
 Результатом проєкту повинна бути веб-орієнтована інформаційна система,
що базується на рішенні для персональних комп’ютерів;
 Продукт повинен надавати можливість простого і швидкого керування
проєктом, його документацією та власним часом проєктного менеджера;
 Система повинна мати інтуїтивно зрозумілий інтерфейс;
 Система має бути готовою до змін та покращень;
 Продукт має містити мінімальну кількість багів та помилок.
Учасники проекту:
В даному проекті до команди проекту відносимо: головний розробник, 3 розро-
бника,QA- інженер, QS –інженер, системний адміністратор, дизайнер сайту (OBS
проекту в Додатку А) .
Особливості проєкту:
 Продукт проєкту є простим у використанні;
 Проєкт є досить короткочасним для проєктів подібного типу.
Альтернативні реалізації проєкту:
 Головною альтернативою такого проєкту є розробка продукту як десктоп-
ну версію, що могло би надати користувачам більше надійності та безпеки системи,
але робить систему менш гнучкою та дорожчою в розробці.
21

Окрім вище названих характеристик проєкту можна також виділити характе-
ристику споживачів результату проєкту.
Як свідчать дослідження в галузі комунікацій, проведені зарубіжними та вітчи-
зняними науковцями, на різні групи споживачів реклама впливає по-різному. Тому в
економічно розвинутих країнах більше не орієнтуються на якогось середньостати-
стичного індивіда. Зараз увесь рекламний процес спрямовано на конкретну людину,
яка входить до певної групи людей, подібних до неї.
Реклама більше не обіцяє людині задоволення якихось глобальних бажань, не
породжує в неї солодких мрій про суспільство «білих кадилаків». Сучасна реклама
пропонує саме той спосіб (стиль) життя, який цінує в даний момент конкретна група
споживачів або навіть країна в цілому. Реклама послідовно домагається свідомого
сприйняття покупцем рекламного звернення і свідомого здійснення покупки.
Споживач — основна особа в маркетингу. Уся політика маркетингу полягає,
врешті-решт, у спрямуванні дій безпосередньо на кінцевого споживача. Широкий
спектр засобів рекламування створюється з однією метою — найефективнішим спо-
собом залучити кінцевого споживача та максимально задовольнити його запити. Усі
інші об’єкти рекламного впливу (наприклад, торгівля) є лише допоміжними, і вплив
на них здійснюється тільки для посилення тиску на споживача.
Радники — це особи, які завдяки своєму авторитетові, соціальному стану,
професії можуть справляти вирішальний вплив на придбання товару (послуг) інши-
ми особами. За характером споживання покупці підрозділяються на дві
категорії: покупці товарів широкого вжитку та покупці (споживачі) товарів проми-
слового призначення. Оскільки попит на товари промислового призначення майже
на 90 % визначається попитом на товари широкого вжитку, головним об’єктом ре-
кламного бізнесу є покупець товарів широкого вжитку. В економічно розвинутих
країнах процес наукового обґрунтування споживчого попиту пройшов три етапи. На
першому етапі бралися до уваги в основному соціально-демографічні, географічні
критерії та критерії матеріального забезпечення й рівня споживання. Споживачів
групували за такими ознаками: стать, вік, соціально-професійна належність, місце
проживання, район, кількість членів сім’ї, кількість дітей, забезпеченість окремими
22

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

Висновки до розділу 1
В першому розділі досліджено предметна сфера, ідея та можливості реаліза-
ції проекту створення інформаційної системи управління турагенством, розроблено
концепцію проекту, здійснено PEST та SWOT аналізи проекту. Сформовано ре-
зюме проекту створення інформаційної системи управління турагенством, де описа-
но мету проекту, оточення та учасники проекту, інвестиційні можливості та продукт
проекту. Розроблено цільове дерево проекту, сценарій його реалізації на основі сце-
нарно-цільового методу.

23

РОЗДІЛ 2. ГАЛУЗІ ЗНАНЬ З УПРАВЛІННЯ ПРОЄКТАМИ

2.1. Управління інтеграцією та інформаційним зв’язком в проєкті

Управління інтеграцією проєкту (Project Іntegratіon Management) – розділ
проєктного менеджменту, що включає процеси, необхідні для забезпечення коорди-
нації різних процесів управління проєктами. Інтеграція включає в себе такі процеси
як визначення, уточнення, комбінування, об’єднання та координацію різних дій що-
до управляння проєктом.
Управління інтеграцією проєкту складається з таких компонентів:
 розробка плану проєкту – створення підсумкового структурованого доку-
менту на підставі даних, отриманих на попередніх етапах планування;
 визначення критеріїв успіху – розробка критеріїв оцінки виконання проєк-
ту;
 виконання плану проєкту – реалізація плану проєкту шляхом виконання
робіт, які ввійшли до нього;
 загальне управління змінами – координація змін за всіма параметрами
проєкту.
Для визначення процесу інтеграції проєкту необхідно також виділити групи
усіх процесів управління проєктом. Їх можна поділити на 5 груп:
1) група процесів ініціації (initiating process group) – процеси, які виконують-
ся визначення нового проєкту або нової фази існуючого проєкту шляхом отримання
дозволу щодо початку проєкту або фази;
2) група процесів планування (planning process group) – процеси, необхідні
для визначення загального змісту проєкту, уточнення цілей та визначен-
ня послідовності дій задля досягнення цілей проєкту;
3) група процесів виконання (executing process group) – процеси, які застосо-
вуються для виконання робіт, визначених в плані управління проєктом задля задо-
волення специфікації проєкту;
24

4) група процесів моніторингу та контролю (monitoring and controlling process
group) – процеси, необхідні для відстеження, аналізу та регулювання ходу та ефек-
тивності виконання проєкту, виявлення тих областей, щодо яких необхідно внести
зміни в план, а також ініціація відповідних змін;
5) група процесів завершення (closing process group) – процеси, які викону-
ються для завершення всіх дій в межах всіх груп процесів
та формального завершення проєкту або фази.
Управління інтеграцією проєкту Project Management Assistant можна зобразити
за допомогою таблиці 2.1.
Таблиця 2.1
Управління інтеграцією
Група процесів Заходи
Процеси ініціації Визначення залученого до проєкту
персоналу, попередній опис проєк-
ту
Процеси планування Проведення вартісної оцінки,
визначення обсягу проєкту, пла-
нування бюджету проєкту
Процеси виконання Набір команди для реалізації проєк-
ту згідно визначеного плану та
бюджету
Процеси моніторингу Моніторинг ринку та процесу ро-
зробки
Процеси завершення Закриття проєкту чи віхи

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

чення досягнення цілей проєкту. Кожен учасник проєкту має бути підготовлений до
взаємодії в рамках проєкту відповідно до його функціональних обов'язків.
Функція управління інформаційними зв'язками включає наступні процеси:
 планування системи комунікацій – визначення інформаційних потреб уча-
сників проєкту (склад інформації, терміни і способи доставки);
 збір і розподіл інформації – процеси регулярного збору і своєчасної доста-
вки необхідній інформації учасникам проєкту;
 оцінка і відображення прогресу – обробка фактичних результатів стану ро-
біт проєкту, співвідношення з плановими і аналіз тенденцій, прогнозування;
 документування ходу робіт – збір, обробка і організація зберігання форма-
льної документації по проєкту.
Технології або методи розподілу інформації між учасниками проєкту можуть
значно розрізнятися залежно від параметрів проєкту і вимог системи контролю.
Вибір технологій взаємодій визначається: мірою залежності успіху проєкту від акту-
альності даних або детальності опису; доступністю технологій; кваліфікацією і
підготовленістю кадрів.
План управління комунікаціями включає:
 план збору інформації, в якому визначаються джерела інформації і методи
її здобуття. План розподілу інформації, в якому визначаються споживачі інформації
і методи доставки;
 детальний опис кожного документа, який має бути отриманий або переда-
ний, включаючи формат, вміст, рівень детальності визначення, які використовува-
лися;
 розклад і частота взаємодій;
 метод внесення змін в план комунікацій.
Залежно від потреб проєкту, план комунікацій може бути більш менш фор-
малізований, деталізований або описаний лише в загальному вигляді. План ко-
мунікацій є складовою частиною плану проєкту. Процеси збору і обробки даних про
досягнуті результати, фактичні витрати та відображення інформації про стан робіт у
26

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

2.2. Управління змістом проєкту (WBS - структура)

Структура робіт проєкту – ієрархічна структура, що розділяє роботи проєкту на
групи, підгрупи, фази і т.д.(називається WBS – структура проєкту).
По своїй природі структура робіт є ієрархічної, і призначена для повноти опису
проєкту і відстеження змін складу і змісту робіт, що відбуваються в ньому.
WBS– структура – це перелік робіт, які необхідно виконати по проєкті. Для її
побудови необхідно провести декомпозицію робіт. Її можна здійснювати різними
способами: або по життєвому циклі проєкту, або по змісту продукту (те, що ми хоче-
мо в результаті одержати). У будь-якому випадку, спочатку виділяються блоки робіт,
що у міру розробки WBS – структури необхідно деталізувати.
Переміщення від верхніх рівнів до нижнього означає перехід до більш деталь-
ного опису робіт проєкту. Деталізація робіт проводиться доти, поки по кожній роботі
стане можливим здійснення безпосереднього контролю, тобто призначення відпові-
дального за її виконання.
Часто використовують ітераційний похід для створення WBS – структури, що
полягає в тім, що на початковому етапі не завжди можна детально описати всі роботи
з проєкту. Однак вартість проєкту визначається через вартість його робіт. Тому при
визначенні вартості проєкту на первісному етапі відбувається груба оцінка блоків ро-
біт з обов'язковим обліком погрішності (за згодою Замовника).
Після того, як декомпозиція робіт проведена, можна говорити про наявність іє-
рархічної структури робіт. Після цього приступають до календарного планування
проєкту, тобто встановлюють зв'язку між роботами, оцінюють тривалість кожної ро-
боти, а також визначають обмеження на терміни початку і закінчення проєкту, фаз,
окремих робіт при необхідності. У результаті можна одержати графік Ганта – горизо-
нтальну лінійну діаграму, на якій роботи проєкту представлені протяжними в часі
відрізками з датами початку і закінчення.
27

Для виконання цих дій існують спеціальні програмні продукти, наприклад
Microsoft Project.
В даному проєкті створення WBS-структури використовувалася програма Mi-
crosoft Project 2010 (див. додаток Б). Також WBS – структуру можна представити в
вигляді таблиці 2.1
Таблиця 2.1.
WBS – структура проєкту
Роботи проєкту
1. Старт проєкту
2. Підготовчі роботи
2.1 Закупівля комп'ютерів та меблів
2.2 Розміщення меблів і комп'ютерів
2.3 Закупівля сервера та WEB-сервера
2.4 Купівля ліцензійного ПЗ
2.5 Установка ПЗ
3. Аналіз
3.1 Визначення цілей ІС
3.2 Визначення основних вимог
3.3 Визначення основних ризиків
3.4 Складання початкового плану робіт
3.5 Документація
Роботи проєкту
4. Проєктування
4.1 Формування плану розробки ІС
4.2 Розробка структури бази даних
4.3 Розробка архітектури ІС
4.4 Розробка методів боротьби з ризиками
5. Реалізація
5.1 Створення бази даних
5.2 Створення програми «офісу для туристичних компаній»
5.2.1 Реалізація редактора турів
5.2.2 Реалізація аналізу турів
28

5.3 Створення сайту
5.3.1 Створення дизайну сайту
5.3.2 Реєстрація на сайті
5.3.3 Реалізація поповнення рахунку
5.3.4 Реалізація грошових операцій
5.3.5 Реалізація перегляду турів
5.4 Створення контрольного центру
5.4.1 Реалізація введення результатів
5.4.2 Реалізація розрахунку вартості туру
5.4.3 Реалізація управління і реєстрацію клієнтів
5.4.4 Реалізація перегляду фінансової статистики
5.5 Створення програми прийому коштів
5.6 Створення програми регіонального офісу
5.7 Створення програм для інтернет-диспетчера
5.7.1 Реалізація отримання інформації про клієнтів
5.7.2 Реалізація прийому коштів
6. Тестування
6.1 Альфа - тестування
6.1.1 Визначення основних недоліків
6.1.2 Усунення помилок
6.1.3 Внесення змін
6.2 Бета - тестування
6.2.1 Визначення основних недоліків
6.2.2 Усунення помилок
Роботи проєкту
6.3 Підготовка документації для користувачів
7. Впровадження
7.1 Установлення нової інформаційної системи
7.2 Навчання користувачів

2.3. Управління часом в проєкті

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

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

В даному проєкті для планування часу використовувалась програма Microsoft
Project 2010. Діаграма Ганта показував план робіт проєкту (див. додаток Г).
Як ми бачимо з WBS-структури проєкт складається з таких фаз:
1) Підготовчі роботи – час виконання 18 днів;
2) Аналіз – час виконання 14 днів;
3) Проєктування – час виконання 14 днів;
4) Реалізація – час виконання 59,98 день;
5) Тестування – час виконання 12 днів;
6) Документація - час виконання 22 днів;
7) Впровадження – час виконання 10,67 днів.
Отже час виконання проєкту впровадження ІС для туристичних компаній –
150,64 днів.

2.4. Управління трудовими ресурсами в проєкті

При управлінні ресурсами в проєкті ІС повинне бути зроблено дві перевірки
зв'язані з дослідженням його забезпечення ресурсами. У найпростішому виді це озна-
чає, що планування персоналу в проєкті враховує деякі основні реалії [6].
Перша реалія в тім, що розподіл людей по задачах враховує той факт, що люди
можуть працювати тільки п'ять днів у тиждень, і що є визначені періоди (вихідні, свя-
та, відпустки), коли вони не працюють. Таким чином, ви повинні перевірити, що вра-
ховано вплив:
- щорічних відпусток (особливо для проєктів, що йдуть улітку);
- свят;
- довгих вихідних;
- сезонних відпусток.
Також варто дивитися з деякою підозрою на проєкти або етапи проєктів, що за-
кінчуються в суботи і неділі. Вони можуть мати на увазі, що деякі основні речі не бу-
ли продумані.
31

Отже в проєкті планується розподіл людей на задачі, так щоб людина викону-
вала поставлену задачу, тоді коли в неї немає відпустки чи вихідного. Тому при пла-
нуванні часу виконання задач проєкту необхідно враховувати розподіл ресурсів.
Друга перевірка складається в контролі, що проти кожної задачі в плані проєкту
коштує ресурс. Якщо справа обстоїть не так, це не обов'язково проблема за умови, що
десь у плані закладені такі роботи, як, наприклад, найму персоналу, внутрішні пере-
ходи, узгодження субпідрядних договорів, і так далі – імена цих людей, що надає.
Отже в проєкті план розподілу ресурсів складається так, що напроти кожної за-
дачі стояв відповідний ресурс (по можливості не повинно стояти містерів Х чи ресурс
У в плані). Якщо на початку планування не вдається розподілити всі ресурси, то не-
обхідно розподілити по можливості точніше ресурси на початкові задачі проєкту, а
потім розподіляти ресурси протягом проєкту, коли є більш точна інформація на задачі
проєкту.
Дуже ефективний шлях з'ясування того, що проєкт був запланований і проду-
маний належним образом, складається в перевірці розподілу працезатрат і робітника
графіка за часом життя проєкту. Порівнюючи цей розподіл з аналогічними парамет-
рами попередніх закінчених проєктів, ви можете відчути точність, або її відсутність, в
оцінках у розглянутому плані.
Очевидно, проєкти сильно розрізняються в різних організаціях і навіть у межах
однієї організації. У силу цього розподіл працезатрат і робітника графіка по життю
проєкту також будуть розрізнятися.
На жаль, в області інформаційних систем усе ще вкрай рідко можна знайти такі
дані, не говорячи вже про їхню точність.
Третя перевірка заключається в тому, що коли ми маємо графік робіт, ми по-
винні зробити розподіл людей по задачам, де деякі зразково підходять до даної задачі,
а інші в меншому ступені. Тепер треба розподілити задачі по людям так, щоб проєкт
був виконаний.
Який найкращий шлях для цього? Для будь-якої задачі із списку і для будь-
якого члена проєктної команди в команді є варіанти [4]:
32

1) дана людина може виконати дану роботу и хоче її робити (дана категорія
людей ідеал для проєкту, чим більше таких людей в проєкті, тим більша
ймовірність, що проєкт буде виконано вчасно);
2) може виконувати дану роботу и підготовлений, щоб робити її (від даної ка-
тегорії людей рідко коли з’являються проблеми в виконанні задач проєкту);
3) може виконати дану роботу, але не підготовлений, щоб робити її (для даної
категорії людей необхідно в плануванні часу відвести час на підготовку до
виконання поставленої задачі);
4) може виконати дану роботу, але не хоче виконувати її (в даній категорії лю-
дина, або виконувала багато разів дану роботу і їй зовсім не цікаво викону-
вати, ще один раз дану роботу, або їй мало платять за виконання поставленої
задачі);
5) може бути навчений проінструктований, як виконувати дану роботу (Напри-
клад, коли людина знає мову програмування, але даній область вона не ство-
рювала програм і вона може легко бути проінструктована по даній задачі і в
результаті буде виконана поставлена задача перед даною людиною);
6) не може виконувати дану роботу (Наприклад в проєкті є декілька програміс-
тів, один із них добре орієнтується в галузі інтернет, а інший в офісній час-
тині. Тому слід назначати на задачу по створенню сайту ту людину, яка доб-
ре в цьому розуміється, якщо назначити другу людину, то вона може або не
виконати цю задачу, або не вкластися в час виконання цієї задачі).
Отже в результаті розподілу ресурсів, необхідно розподілити по можливості їх
так, щоб люди, які виконували поставлену задачу відносилися до категорії 1 або 2.
Також в проєкті для виконання поставленої задачі необхідно ресурси такі, як
WEB-сервер, інтернет (відноситься до задач пов’язаних с написанням інтернет-
сайту).
Отже в проєкті даний розподіл ресурсів зображено на сітьовому графіку, листі
ресурсів і працезатрат (див. додатки).
Кількість людей, які необхідно для проєкту вибираються за такими ознаками:
1) від рівня знання програмістів і експертів;
33

2) від оцінки об’єму в проєкті;
3) від рішення прийнятих по головним ризикам;
Отже в проєкті ми маємо такі фази в проєкті, по яким необхідно розділити ре-
сурси:
1) Підготовчі роботи – в даній фазі створюється закупка всього необхідного
для проєкту, установка ПЗ, розміщення меблів та комп’ютерів, всім цим
займається системний адміністратор СК «Глобус».
2) Аналіз – для даної фази два експерти в галузі створення ІС, головний аналі-
тик СК «Глобус» і головний програміст, 4 комп’ютери, меблі (4 комплекти)
та інтернет необхідний для роботи проєктної команди;
3) Проєктування – в даній галузі необхідно головний програміст, програміст та
2 комп’ютери, меблі (2 комплекти) та інтернет.
4) Реалізація – для даної галузі необхідно такі ресурси: головний програміст, 3
програмісти, дизайнер сайту, інтернет і ще 5 комп’ютерів, меблі (5 компле-
ктів), сервер та WEB-сервер ліцензійне програмне забезпечення.
5) Тестування – для даної галузі такі необхідні ресурси 3 програмісти, голов-
ний програміст, 4 комп’ютери, меблі (4 комплекти) та інтернет.
6) Впровадження – для даної галузі необхідно ресурсів: системний адміністра-
тор та головний програміст, 2 комп’ютери, меблі (2 комплекти) та інтернет.
В кожній фазі також необхідно комплект меблів і комп’ютерної техніки керів-
нику проєкту.
2.5. Управління вартістю проєкту

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

Затверджений бюджет проєкту 580 тис. грн.
Керівник проєкту в першу чергу заклопотаний управлінням прямими витратами
проєкту, але сучасна тенденція в керуванні проєктами веде до того, що його роль у
керуванні вартістю проєкту буде зростати за рахунок усе більшого включення нетра-
диційних областей управління вартістю. Можна припустити, що в майбутньому усе
більше керівників проєктів будуть мати справа з управлінням непрямими витратами і
витратами по проєктах.
При цьому незалежно від того, за що конкретно відповідає керівник проєкту,
критично важливо, щоб його робота оцінювалася по тим і тільки тим показникам, за
які він несе відповідальність. Наприклад, якщо керівник проєкту не відповідає за вар-
тість матеріалів у проєкті, то немає ніякого сенсу оцінювати його роботу з цього по-
казника.
Для обліку витрат також досить важливо установити відповідний часовий по-
рядок збору фактичних даних по витратах. Бюджет проєкту повинний бути синхроні-
зований із процедурою їхнього збору. Наприклад, якщо керівник проєкту відповідає
за вартість матеріалів, то необхідно визначити, коли в бюджеті повинний бути пока-
зана витрата. Чи повинно це відбуватися при прийнятті керівником проєкту рішення
про покупку, або при постачанні купленого? А може бути, варто фіксувати витрата
після завершення приймання купленого, або в момент, коли покупка оплачується?
Подібні проблеми можуть перетворити управління вартістю проєкту в кошмар.
Таким чином, якщо в проєкті не здійснюється відповідне керування вартістю,
то він обов'язково вийде з-під контролю, і для його завершення буде витрачено біль-
ше грошей, чим передбачалося. Управління вартістю проєкту націлене саме на запо-
бігання такої ситуації.
Отже для визначення вартості проєкту потрібно знати вартість складових ре-
сурсів проєкту, час виконання робіт і вартість цих робіт. Таким чином, оцінка вартос-
ті проєкту починається після визначення робіт проєкту і структури необхідних ресур-
сів. Контроль вартості проєкту здійснюється в процесі реалізації проєкту такими ме-
тодами як аналіз освоєного обсягу, прогнозування витрат і іншими. Отже, що обраху-
вати вартість проєкту необхідно просумувати:
35

1) Зарплата проєктної команди і керівника проєкту – 384 тис. грн.;
2) Вартість матеріальних ресурсів (WEB-сервер, сервера, офісні меблі,
комп’ютери) – 166 тис. грн.
3) Вартість за оренду та інтернет-послуги – 10 тис. грн..
Більш детальний розподіл коштів зображено в звіті бюджету проєкту (див. до-
даток Е).

2.6. Управління якістю проєкту

Проєкт по створенню інформаційної системи (ІС) підприємства завжди включає
безліч задач, зв'язаних із загальним управлінням проєктом, розробкою ПО, проєкту-
ванням ІС, упровадженням ERP-системи, кожна з яких сама по собі є проєктом із вла-
стивими йому особливостями.
Як правило, вести такі проєкти без реально діючої системи управління якістю
практично неможливо. Навіть якщо на початковому етапі компанії, що взялися за ре-
алізацію проєктів, не задумуються про це, усвідомлення необхідності системи управ-
ління якістю проєкту приходить досить швидко. Особливо, коли проблеми управлін-
ня починають рости з кожним днем у геометричній прогресії [24].
Загальні методичні вказівки по управління якістю проєктів дані в ISO
10006:1996 "Адміністративне управління якістю. Провідні вказівки по забезпеченню
якості при управлінні проєктом" [20], ISO 10007:1995 "Адміністративне управління
якістю. Провідні вказівки по управлінню конфігурацією" [21]. По управління якістю
проєктів в області інформаційних технологій (ІТ-проєкти) існують спеціалізовані ста-
ндарти, наприклад, стандарти COBIT або корпоративний стандарт Microsoft MSF.
Але великі проєкти мають три основні особливості.
Перша – зміна задач у ході проєкту [25]. Цим "страждають" ІТ-проєкти, але ве-
ликі наслідки бувають особливо важкими. Часто первісна постановка задачі істотно
міняється в ході проєкту. Крім того, при впровадженні проєктних рішень необхідна
реорганізація діяльності замовника, при цьому постійно повинні уточнюватися і ко-
36

ректуватися функціональність розроблювальної системи і відслідковуватися потреби
замовника при зміні його бізнесів-процесів. Як правило, будь-яка некерована зміна у
функціональності створюваної ІС або роботах, здійснюваних у рамках проєкту, істот-
но позначається на якості проєктних рішень і може взагалі привести до краху проєк-
ту. І це необхідно враховувати при керуванні проєктом.
У проєкті для того, щоб не виникали різкі зміни у головній цілі, було проведено
детально збір інформації від кожного замовника проєкту і опис необхідних вимог до
ІС, оскільки в даному проєкті по створенню ІС для туристичних компаній, замовни-
ками виступають працівники фірми СК «Глобус».
Друга – рівнобіжне ведення робіт різними проєктними групами [25]. Напри-
клад, одночасно можуть виконуватися роботи з ескізного проєктування всієї ІС, роз-
роблятися ПО, що забезпечує інтеграцію існуючих ІС підприємства з розроблюваль-
ною системою, вестися впровадження окремих модулів ERP-системи. У сполученні з
першою особливістю це може викликати лавиноподібний ріст працезатрат в проєкті.
Тим самим паралельність і багатоплановість робіт, виконуваних у проєкті по
розробці і впровадженню ІС, багаторазово збільшує імовірність виникнення ризиків
невдалого завершення проєкту. Одна з важливих задач управління якістю проєкту –
домогтися, щоб до моменту його завершення "зрослися" усі компоненти системи і
були виконані вимоги замовника по функціональності, термінам і вартості системи.
Як видно с WBS – структури проєкту ми маємо декілька робіт, які ведуться па-
ралельно, щоб в результаті не було того, що один модуль не працює разом з іншим,
була проведене детальне планування архітектури системи експертами і програміста-
ми проєкту.
Оскільки в новостворюваній ІС для туристичних компаній до десятка програм і
кожна повинна відповідати вимогам замовника, необхідно було ведення уточнень
вимог замовника до початку проєкту.
Третя – дуже великі ризики як для замовника, так і для виконавця проєкту [25].
У даній роботі ризик – це добуток величини збитку (зміна термінів проєкту, працеза-
трат і т.д.) на імовірність його виникнення. Ризики замовника зв'язані з неповним до-
сягненням цілей проєкту і не ефективно витраченими засобами, а ризики виконавця –
37

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

2.7. Управління закупівлями в проєкті

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

– закриття контракту – завершення і врегулювання виконання завдань кон-
тракту, включаючи вирішення відкритих питань.
Планування закупівель – це процес визначення проєктних потреб, які можуть
задовольнятися найкращим чином з допомогою закупівлі товарів і послуг за межами
виконавчої організації. Він включає обговорення того, чи варто закуповувати, як,
що, скільки і коли [17].
Описання змісту проєкту включає описання поточних проєктних меж, надає
важливу інформацію про потреби та стратегії проєкту, які мають бути розглянуті в
процесі планування закупівель.
Описання продукту містить важливу інформацію про будь-які технічні рішен-
ня або проблеми ,які необхідно розглянути в процесі планування закупівель.
Ресурси закупівлі. Якщо виконавча організація не має офіційної групи по ро-
боті з контрактами, то члени команди проєкту повинні набути знань і досвіду для
підтримки конкретних робіт по закупівлі.
Умови ринку. При плануванні закупівель повинні бути враховані асортимент
товарів та послуг на ринку товаровиробника.
Обмеження. Обмеження – це чинники, що обмежують права покупця. В на-
шому випадку обмеженням являються наявність грошових коштів.
Управління закупівлями в проєкті обговорюється з позиції покупця у відно-
шенні “покупець – продавець“. Таке відношення існує майже на всіх рівнях проєкту
[9, 53]. Продавець в даному проєкті називається постачальником.
Основним методом планування закупівель є вибір типу контракту. В проєкті
використовується контракт з твердою ціною або з фіксованою вартістю. Така кате-
горія контракту включає загальну тверду ціну для конкретного товару.
Планування клопотань включає підготовку документів, необхідних для
підтримки клопотань при управлінні закупівлями в проєкту. Основним методом для
планування клопотань є стандартні форми, які включають стандартні контракти,
стандартні описання елементів закупівлі, стандартизовані версії всіх або частини
необхідних документів по торгах. Документи по закупівлі використовують для про-
39

позиції – клопотань від передбачуваних продавців. Вони структуровані, для того
щоб сприяти точним і повним відповідям від продавців (постачальників).
Для отримання повної оцінки при закупках визначаємо наступні критерії:
– розуміння потреби;
– загальна вартість, або вартість життєвого циклу, - чи буде вибраний прода-
вець надавати найнижчу вартість;
– технічні можливості;
– підхід до управління;
– фінансові можливості.
Процес клопотання включає отримання комерційних пропозицій від потенцій-
них продавців про те, як можуть бути задоволені проєктні потреби.
Закупівлі, які необхідно зробити в проєкті для створення ІС для туристичних
компаній (які виконуються в фазі „Підготовчі роботи”, крім інтернет-послуг):
- закупки матеріалів (меблі, ліцензійне програмне забезпечення);
- закупки обладнання (комп’ютери, сервер та Web-сервер);
- закупки послуг (інтернет-послуги).
Ресурсами нашого проєкту є:
- покупка CMS;
- покупка доменного імені;
- покупка хостингу;
- витрати на SEO просування;
- витрати на контекстну рекламу.
Всі клопотання щодо закупівель лежать на виконавцеві, який за свою практи-
ку добре знайомий з цим ринком і може робити покупки по зниженим цінам, як для
постійного клієнта. А це, в свою чергу дозволяє знизити загальні витрати для
підприємства-замовника веб-послуг. І бере на себе всю відповідальність за якість та
доцільність куплених продуктів.
Для створення ІС дизайн-студія обрала Систему управління вмістом (Content
Management System – CMS). CMS - ефективна і надійна система управління сайтами,
40

що дозволяє створювати, підтримувати і управляти інтернетом-сайтами практично
будь-якої міри складності.
Придбання доменного імені http://brandmania.com.ua та хостингу дизайн-студія
здійснює на першому в Україні, повністю автоматизованому сервісі за наданням хо-
стингу і реєстрації доменних імен. Особливістю хостингу
(http://www.ukraine.com.ua) є повна автоматизації всіх процесів, пов'язаних не лише
з реєстрацією доменів і хостингу, але і повною автоматизацією роботи серверів і
персоналу хостингу. За рахунок закладеної в програмне забезпечення логіки ми до-
сягається найбільша швидкість і якість в наданні послуг. Напрям хостингу був
відкритий в 2004 році, в більшості для власних проєктів компанії і своїх клієнтів. З
часом, кількість сайтів розміщених на серверах виросло на стільки, що для управ-
ління хостингом потрібно було створити програмне забезпечення, що автоматизує
роботу.
У основу хостингу "Україна" закладено унікальне програмне забезпечення,
якого немає ні в однієї української хостинг - компанії. Користувачі можуть вико-
навати тонке налаштування хостингу, налаштувати кожен сайт. Користувачі не об-
межені єдиними налаштуваннями PHP, для кожного сайту є можливість налаштува-
ти ті параметри PHP, які потрібні для більшості систем управління.
SEO просування забезпечує виведення сайту на перших позиціях результатів
пошуку в Google.
Контекстна реклама направлена на швидке (в порівнянні з пошуковим просу-
ванням сайту) збільшення цільової відвідуваності сайту або залучення уваги кори-
стувачів.
Методи та засоби вибору джерела:
– переговори по контракту передбачають пояснення положень контракту і
взаємну угоду відносно структури та вимог контракту перед його підписанням.
Текст контракту має відображати всі досягнуті домовленості;
– система ранжування – спосіб кількісного подання якості даних, спрямований
на те, щоб мінімізувати вплив персональних переваг при виборі джерела;
41

– система необхідних умов передбачає складання мінімальних вимог до по-
казників виконання за одним або більше критеріями оцінки.
Результатами вибору джерел є підписання контракту – угода, яка зв’язує по-
купця сплачувати по ньому [8].
Адміністрування контракту – це процес забезпечення того, що постачальник
задовольняє показники контрактних вимог [17]. Юридична сторона контрактних
відносин вимагає, щоб всі учасники проєкту усвідомлювали всі юридичні наслідки
рішень, що приймаються при адмініструванні контракту. Адміністрування контрак-
ту містить компонент фінансового менеджменту. Строки оплати визначені в кон-
тракті і відображають певний зв’язок між виконанням його та виплатами по ньому.
Основні методи адміністрування:
– система контролю за змінами в контракті;
– звіти про виконання;
– система оплати.
Закриття контракту включає перевірку того, чи вся робота виконана правиль-
но та задовільно та коригування записів для відображення підсумкових результатів і
архівація цієї інформації з метою подальшого використання.
Основним методом закриття контракту є аудит закупівлі – структурований пе-
регляд процесу закупівлі від стадії планування закупівлі до адміністрування по кон-
тракту.
Для отримання інтернет-послуг вкладено контракт на поставку інтернету про-
тягом всього проєкту.

2.8. Управління ризиками проєкту

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

інтеграція планування. Виробляється підписання контрактів з консультантами-
експертами по основних питаннях, одержання інформації з баз даних.
У ряді публікацій рекомендується модель управління ризиками,в якій структура
містить шість етапів, зміст яких охоплює ті ж процеси, докладно відбиті на малюнку
моделі. В описі виділені дві основні проблеми управління ризиками складних про-
грамних проєктів: проблема менеджменту проєктів і проблема теорії управління
проєктом. У цій моделі виділені десять компонентів — найбільш важливих причин
при керуванні ризиками проєктів складних комплексів програм, для яких рекоменду-
ються процедури їхнього скорочення:
 недостатня кількість і кваліфікація колективу фахівців;
 нереальна оцінка необхідного часу реалізації проєкту і виділюваного бюджету;
 дефекти і невизначеності при розробці вимог і основних функцій комплексу
програм;
 дефекти і помилки при розробці інтерфейсу для користувача і зв'язків компоне-
нтів ІС;
 порушення базових (золотих) основ процесів розробки і твердих вимог, відсут-
ність прототипів, аналізу і проєктування витрат;
 безперервна зміна вимог, інформаційних зв'язків, розширення функцій проєкту
ІС;
 недоліки компонентів зовнішнього обслуговування і контролю, аналізу суміс-
ності компонентів, рекомендацій і застосування зв'язків;
 недоліки засобів зовнішніх перетворень і взаємодії компонентів, компетентного
проєктування або прототипування;
 дефекти при забезпеченні процесів реального часу, моделюванні прототипів,
настроювання інструментів розробки і контролю;
 дефекти контролю обчислювальної техніки і відмовлення функціонування ком-
п'ютерів і системи.
Також існує модель управління ризиками з використанням 12 категорій потен-
ційного ризику для визначеного проєкту. Для кожної категорії детально представлені
фактори, що впливають на ризики, і рекомендується проводити їхньої оцінки по
43

трьох рівнях можливого прояву (низька, середня, висока очевидність погрози ризику),
опису змісту й атрибутів яких представлено у великій таблиці. План управління проє-
ктними ризиками для конкретного ІС рекомендується моделювати категоріями:
1) Задачі і цілі. Кожен схвалений проєкт ІС повинний займати відповідне місце
серед цілей і задач підприємства. Ті проєкти, що не відповідають реальної цілям ор-
ганізації, створюють напруга, що впливає на всі проєкти. Наприклад, зажадаємо, щоб
існувала організація, у задачі якої входила би розробка ІС для внутрішнього корпора-
тивного виробництва, а ціль складається в створенні найбільш ефективного, замовле-
ного програмного забезпечення для підприємств організації. Якщо підприємство при-
ступить до виконання проєкту по створенню пакета ІС загальної спрямованості і на
комерційній основі, то це може бути ризикованим заходом, що суперечать поточним
задачам, кваліфікації і цілям організації.
2) Організаційний менеджмент. Кожний з обраних проєктів повинний вписувати-
ся в поточну або плановану організаційну структуру. Якщо організація не має подіб-
ну структуру або ж вона ще не створена, важко розраховувати на успішну реалізацію
програмного проєкту. Прикладом подібних ризикованих формувань є торговельні ор-
ганізації, що припиняють розробку проєктів без дотацій з боку виконуючих організа-
цій. Проєкт перекидається на інше підприємство по розробці, оскільки немає підхо-
дящої команди і відсутній процес формування необхідного типу системи.
3) Замовник. Усі проєкти повинні мати постійний зворотний зв'язок із замовни-
ком. Проєкт розробки ІС вимагає великих вихідних даних, що можуть представити
замовники і кінцеві користувачі. Без подібних даних самий удалий процес розробки
приведе до формування тільки відмінно функціонуючої системи, що не відповідає ре-
альним запитам кінцевих користувачів. Схований тут ризик складається в залученні в
команду недосвідчених співробітників, що не володіють адекватним досвідом з до-
зволу проблем, зв'язаних з конкретною предметною областю. Такі співробітники не
зможуть задовольняти необхідні технічні запити замовника і розроблювачів ІС.
4) Бюджет/вартість. Саме дана категорія звичайно залучає найбільш пильну увагу
і впливає на всі інші категорії ризиків. Менеджери проєктів зосереджують увагу на
бюджеті й обсягах витрат, оскільки саме ці важелі дозволяють задіяти широкий
44

спектр можливостей, що приводять проєкт до успішного завершення. Для зменшення
ризику, що відноситься до цієї категорії, варто чітко представляти розміри проєкту,
мати у своєму розпорядженні достовірну передісторію про роботу над подібними
проєктами, а також мати досить повне представлення про зовнішні впливи, напри-
клад, про технології.
5) Графік. Великий ризик полягає в тому, що команді розроблювачів нав'язуються
занадто тісні тимчасові рамки графіка робіт. Якщо розроблювачі не можуть робити
впливу на формування графіка і дати ключових етапів проєкту, велика імовірність то-
го, що графік виконуватися не буде. Команди розроблювачів ІС повинні брати участь
у розробці проєктних графіків і мати можливість вносити туди зміни.
6) Зміст проєкту. Усі проєкти генерують ті або інші особливості, що доповнюють
проєкт і утворять проміжні продукти. Одним з основних компонентів є документація,
що містить вимоги, відомості про проєктування, про цільову систему і зовнішнє сере-
довище. Якщо ця інформація відсутня, можуть з'явитися помилки, або різко і непе-
редбачено зросте ризик утрати зведень, що утримуються в проєкті. Також може по-
рушитися графік або істотно постраждає вміст продукту.
7) Виконання. Ці фактори ризику відносяться до особливого періоду, коли настає
момент практичних іспитів розробленої системи і ІС. Однак саме ці фактори ризику є
ключовими для критерію по розробці програмного продукту. Деякі з основних облас-
тей ризику відносяться до функціонування системи під час тестування. Критичне зна-
чення має доступна можливість повного тестування всіх модулів і їхніх інтерфейсів.
Неадекватне тестування веде до відмовлень при виконанні проєкту і відповідних ри-
зиків.
8) Управління проєктом. Ця категорія відноситься як до процесу управління проє-
ктом, так і до компетенції менеджера проєкту. Ризик існує не тільки через недоліки,
неадекватного трактування, процесів менеджменту, але може бути також наслідком
попереднього досвіду роботи менеджера проєкту. Менеджери проєктів повинні мати
досвід роботи з визначеною предметною областю і мати представлення про процеси
проєктного менеджменту в життєвому циклі ІС.
45

9) Процеси розробки. Ця категорія фокусується на тих процесах, що зменшують
загальний ризик і поліпшують якість виробленого продукту. До процесів розробки не
відносяться специфічні інструменти, такі як мови програмування, генератори коду.
Розглянуті процеси фокусуються на процесах конфігураційного менеджменту, прак-
тиках і методах забезпечення якості і на аналізі альтернатив.
10) Середовище розробки. Дана категорія зосереджена на фізичному середовищі
можливостей, апаратних платформах і інструментах по розробці програмного проду-
кту. Ризик виникає не тільки через недолік адекватних інструментів, але і унаслідок
відсутності адекватних можливостей їхнього використання. Якщо команда не підіб-
рана спеціально для рішення конкретної задачі, відсутнє адекватний простір для ви-
роблення угод, простір для підтримки інтерв'ю з замовником і робітники кімнати, ри-
зик істотно зростає.
11) Персонал. Ця категорія є єдиної, де істотне зменшення ризику досягається за
рахунок набору досвідченої і високопродуктивної команди розроблювачів ІС. Розро-
блювачі, що володіють високою робочою ефективністю, можуть у 10 і навіть у 25 ра-
зів продуктивніше працювати, чим звичайна команда. Непевність у можливостях ко-
манди або в досвідченості її членів у сполученні з деякими особливостями предмет-
них областей, сприяє фіксації консервативного підходу до факторів ризику з цієї ка-
тегорії.
12) Підтримка. Ця заключна категорія дозволяє кількісно оцінювати ризик, зв'яза-
ний із ІС, після постачання програмного продукту. Команда розроблювачів проєкту
часто несе відповідальність за підтримку програмного продукту протягом визначено-
го періоду після його постачання. Якщо ж це не так, а недосвідчені користувачі нама-
гаються фіксувати і виправляти помилки в ІС, проєктний ризик істотно зростає. Ін-
струменти, застосовувані для розробки, повинні бути доступні і на етапі підтримки.
Підтримка постачальника після випуску продукту характеризується наявністю ризику
випуску, якщо відсутній план або бюджет для реалізації інструментарію безперервної
підтримки.
Рекомендується розробка плану управління ризиками, що складається з п'яти
етапів. Використовуючи попередній розподіл на 12 категорій ризиків, пропонується
46

виконати ранжирування і відсортувати ризики таким чином, щоб ними можна було
керувати в конкретному проєкті. Потім розглянутий план скомпонувати в процесі
ідентифікації потенційних погроз і ризиків, уведення їхніх категорій і встановлення
пріоритетів.
Етап 1. Використовуючи описані категорії ризиків, рекомендується створити
таблицю категорій. Команда розроблювачів може скористатися цією таблицею для
огляду категорій ризиків даного проєкту. Також команда повинна сформувати інфор-
мацію про набір факторів і погроз для вивчення. Таблиця категорій ризиків повинна
містити зведення про те, які фактори ризиків більш реальні і наскільки вони очевидні.
Якщо підприємство має у своєму розпорядженні методи роботи з цими факторами,
можна порівняти їхні рейтинги в даному проєкті з рейтингами в проєктах, що розроб-
лялися раніше. Можна використовувати підхід, заснований на всеосяжному рейтингу,
або фіксувати увага на визначеній кількості найбільших ризиків або ж комбінувати
кількість ризиків і ступінь їхнього впливу, прогнозуючи успіх або невдачу проєкту.
Дана таблиця є відправною крапкою при ідентифікації визначених ризиків у кожнім
проєкті.
Етап 2. Ранжуються ризики, зв'язані з виконанням проєкту, по категоріях:
 фактори ризику й області — для кожної категорії в стовпці перелічуються фак-
тори і погрози категорії ризику;
 виділяється низька очевидність ризиків — цей стовпець характеризує фактори
щодо невисокої імовірності і малих наслідків ризику для проєкту;
 середня очевидність ризиків — стовпець характеризує фактори, що мають се-
редню імовірність, і наслідку ризиків для проєкту;
 висока очевидність ризиків — виділяються фактори, коли імовірність і негати-
вні наслідки ризику для проєкту досить великі;
 визначення рейтингу — виділення рівня інтегрального ризику, припустимого
для даного проєкту;
 коментарі — підтримується інформація про особливості проєкту, що дозволяє
дотримувати обраний рейтинг.
47

У деяких випадках очевидний прояв ризику однієї категорії може характеризу-
ватися як високе, а іншої — як низьке. У приведена таблиця факторів ризику і кате-
горій, для яких очевидність ризику характеризується відповідно як низька, середня
або висока. Дана таблиця може служити шаблоном, використовуваним як відправну
крапку для розробки проєкту програмного продукту. Категорії, фактори й очевид-
ність ризиків можна обновляти для будь-якого проєкту в межах розглянутої схеми.
Етап 3. Виконується сортування таблиці ризиків, розташовуючи них у порядку
убування очевидності і погрози. Спочатку перелічуються ризики з найвищою очевид-
ністю. Обчислюється інтегральний ризик для найбільших десяти ризиків, а також для
всіх ризиків, відзначених як високі, якщо їх більше десяти. Саме вони і будуть клю-
човими. Ідентифікуються засоби для контролю кожного ключового ризику, установ-
люється відповідальність за його скорочення і дата виконання. Інтегруються ключові
ризики в план проєкту, і уточнюється їхній вплив на графік і розмір витрат.
Етап 4. Установлюється формат звіту для кожного регулярного ризику. Цей звіт
рекомендується заслуховувати на щотижневих зустрічах колективу фахівців, де розг-
лядається стан проєкту. Показується стан найбільших десяти ризиків, зміни в ранжи-
руванні для кожного ризику за останній тиждень. Відображається звіт відгуків-
контрзаходів про ризики і про їхні зміни.
Етап 5. На заключному етапі варто упевнитися, що управління і скорочення ри-
зиків є безперервним процесом у рамках життєвого циклу проєкту ІС. Відстеження і
контроль ризиків, включених у список, повинні виконуватися на регулярній основі.
Менеджер проєкту і всі члени команди повинні звертати увагу на поводження іден-
тифікованих ризиків, а також контролювати процеси їхнього визначення. Нові ризики
повинні ідентифікуватися, насамперед, для них визначаються пріоритети, що потім
додаються в план управління ризиками. Ризики з високим пріоритетом варто оброб-
ляти відповідно до загального плану проєкту ІС.
Технічні ризики визначаються вимогами й особливостями об'єкта — програмного за-
собу і включають:
 функціональні характеристики;
 характеристики якості;
48

 надійність;
 застосовність;
 тимчасову продуктивність;
 повторне використання компонентів.
Вартісні ризики складають:
 обмеження сумарного бюджету;
 недоступна, фіксована вартість проєкту ІС;
 ступінь реалізму при оцінюванні витрат на проєкт ІС.
Планові ризики включають:
 властивості і можливості гнучкості зміни планів;
 можливості порушення установлених віх — термінів етапів;
 реалізм планів і етапів життєвого циклу.
Крім того, виділені ризики процесів і процедур управління проєктом, які можна
віднести до основних перерахованих елементів ризиків:
 ризики ідентифікації;
 ризики стратегії і планування проєкту;
 ризики оцінок;
 припустимі результуючі ризики при скороченні або усуненні погроз;
 ризики документування;
 ризики прогнозування розвитку й удосконалювання проєкту.
Загальні методи аналізу ризиків у складних системах регламентовані стандар-
том ДСТ Р 51901 — Управління надійністю. Аналіз ризику технологічних систем
[17]. Основною задачею стандарту є обґрунтування рішень, що стосуються аналізу
ризику реалізації проєктів і технологій складних систем. Викладені в стандарті реко-
мендації можуть бути, зокрема, застосовані при техніко-економічному обґрунтуванні
і розробці проєктів комплексів програм. Нижче представлені основні концепції і ско-
рочений зміст цього стандарту, адаптовані для можливості застосування його поло-
жень при аналізі ризиків проєктів програмних засобів. Для підвищення ефективності
управління проєктами рекомендується проводити аналіз ризику, що включає:
 ідентифікацію ризику і визначення методів рішення зв'язаних з ним проблем;
49

 використання об'єктивної інформації при прийнятті рішень для скорочення ри-
зиків;
 задоволення регламентованих вимог замовника до припустимого ризику.
 Застосовуваний метод аналізу ризику повинний бути:
 науково обґрунтованим і відповідати функціям, характеристикам і складності
досліджуваної системи;
 давати результати у формі, що забезпечує розуміння природи погроз, властиво-
стей ризику і способів його контролю;
 типовим і мати властивості, що забезпечують прослідковуваність, повторюва-
ність і контрольованість результатів аналізу.
Елементи процесу оцінки величини ризику є загальними для усіх видів небез-
пеки. Насамперед, аналізуються можливі причини небезпеки з метою визначення час-
тоти її виникнення, тривалості, а також характеру. У процесі аналізу може виникнути
необхідність визначення оцінки імовірності небезпеки, що викликає негативні наслід-
ки, і проведення аналізів послідовності подій, що обумовлюють.
Аналіз частот використовується для оцінки імовірності кожної негативної події, що
проявились на стадії ідентифікації небезпек, погроз. Для оцінки частот подій, що від-
буваються, звичайно застосовуються наступні три методи:
 використання наявних статистичних даних (передісторії);
 одержання частот негативних подій на основі аналітичних або імітаційних ме-
тодів;
 використання думок експертів.
Дані експлуатації використовуються з метою визначення частоти, з яким нега-
тивні події відбувалися в минулому, і, виходячи з цього, прогнозування частоти, з
яким вони можуть відбутися в майбутньому. У тому випадку, коли статистичні дані
недоступні або не відповідають вимогам до системи, можна одержувати частоти по-
дій за допомогою аналізу структури і змісту системи і її аварійних станів. При прове-
денні аналізу частот можуть використовуватися методи імітаційного моделювання
відмовлень. Існує ряд методів для зіставлення експертної думки, що виключають дво-
значність оцінок, допомагають при постановці відповідних питань.
50

Існує безліч невизначеностей, зв'язаних з оцінкою ризику. Розуміння невизна-
ченостей і зухвалих їхніх причин необхідно для ефективної інтерпретації значень ри-
зику. Аналіз невизначеностей повинний передбачати визначення змін і неточностей у
результатах моделювання, що є наслідком відхилення параметрів і припущень, засто-
совуваних при побудові моделі. Областю, тісно зв'язаної з аналізом невизначеностей,
є аналіз чутливості. Аналіз має на увазі визначення змін у реакції моделі на відхилен-
ня окремих параметрів моделі. Оцінка невизначеності складається з перетворення не-
визначеності критичних параметрів моделі в невизначеність результатів відповідно до
моделі ризику. Це відноситься як до невизначеностей даних, так і до невизначеностей
моделі. Повинні бути визначені ті параметри, до яких чуттєвий аналіз.
Вибрана розробка плану управління ризиками, що складається з п'яти етапів,
використовуючи 12 категорій ризиків. Потім необхідно виконати ранжирування і від-
сортувати ризики таким чином, щоб ними можна було керувати в проєкті. Потім роз-
глянутий план скомпонувати в процесі ідентифікації потенційних погроз і ризиків,
уведення їхніх категорій і встановлення пріоритетів.
Етап 1. Використовуючи описані категорії ризиків, створюємо таблицю 3.1
Таблиця 3.1.
Визначення ризиків проєкту
Категорія ризику Ризик Опис ризиків
1. Задачі і цілі проєкту - створенню ІС загальної Існує ризик, що дані заходи суперечать поточним
спрямованості задачам, кваліфікації і цілям фірми.
- зміна цілей Ризик зміни цілей під час виконання проєкту

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

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

51

4. Бюджет (вартість) - вартість проєкту Важко представити розмір проєкту.
- зміна кількості робіт Зміна кількості робіт під час виконання проєкту.

5. Графік робіт - тісний графік робіт Проєктній команді нав’язують тісний графік робіт,
який не в змозі виконати дана команда.

6. Зміст проєкту - відсутність документації Відсутня документація по проміжним модулям ІС,
яка містить вимоги, відомості по проєктуванню.
Категорія ризику Ризик Опис ризиків

7. Виконання - випробування новоство- Існує ризик, що новостворена система не коректно
реної системи виконує свої функції під час тестування.
- неадекватне тестування Не вірно вибране тестування інформаційної сис-
теми проєктною командою.
- надійність ІС Ризик пов’язаний з надійністю нової ІС

8. Управління проєктом - компетентність керівника Немає досвіду роботи керівника проєкту в даній
проєкту предметній області, що може повести до неправи-
льного трактування процесів управління.

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

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

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

12. Підтримка - підтримка після впрова- Ризик, що підтримку буде проводити недосвідче-
дження продукту ний користувач із-за відсутності плану або бю-
джету неперервної підтримки ІС.

52

Етап 2. Оцінюємо ризики, зв'язаних з виконанням проєкту, по категоріях:
Таблиця 3.2.
Оцінка ризиків по категоріям
Оцінка
Категорія ризику Ризик Малий Середній Високий
ризику
1. Задачі і цілі проєк- - створенню ІС загальної спрямова- + 5
ту ності
2. Організаційний - зміна цілей + 7
менеджмент - немає підходящої проєктної коман- + 3
ди
3. Замовник - постійний зв’язок з замовником + 4
- функціонування системи + 6
- підбір не підходящої проєктної ко- + 4
манди
- застосовність + 7
4. Бюджет (вартість) - вартість проєкту + 8
- зміна кількості робіт + 7
5. Графік робіт - тісний графік робіт + 5
6. Зміст проєкту - відсутність документації + 2
7. Виконання - випробування новоствореної сис- + 8
теми
- неадекватне тестування + 4
- надійність + 7
8. Управління проєк- - компетентність керівника проєкту + 5
том
9. Процеси розробки - якість управління + 4
10. Середовище роз- - вибір інструмента розробки + 8
робки - відсутність адекватного простору + 7
для вироблення угод між учасниками
проєкту
- захищення даних ІС в даному сере- + 9
довищі
- піратське ПЗ + 5
11. Персонал - вибір персоналу + 3
- погана домовленість з проєктною + 5
командою
12. Підтримка - підтримка після впровадження про- + 6
дукту

53

Етап 3. Виконуємо сортування таблиці ризиків, розташовуючи них у порядку
убування очевидності і погрози, та розписуємо методи боротьби з ними.
Таблиця 3.3
Оцінка ризиків і методи боротьби з ними
Оцінка
Ризик Методи боротьби
ризику
1) захищення даних ІС в даному се- 10 Необхідний вибір достатнього рівня захищеності (можливо
редовищі необхідно найняти спеціаліста (експерта) для цього)
2) вибір інструмента розробки 9 Детальне вивчення існуючих інструментів розробки
3) вартість проєкту 8 Постійне детальне планування протягом ЖЦ проєкту
4) випробування новоствореної сис- 8 Розробка детального тестування проєкту і постійний зв’язок з
теми замовником
5) зміна кількості робіт 7 Постійне детальне планування протягом ЖЦ проєкту
6) зміна цілей 7 Отримання повної інформації від замовника в фазі аналізу
7) надійність ІС 7 Детальне тестування
8) застосовність ІС 7 Постійний зв’язок з замовником
9) відсутність адекватного простору 7 Створення сайту для постійного зв’язку з замовником
для вироблення угод між учасниками
проєкту
10) функціонування системи 6 Постійна перевірка на відповідність функціонування ІС
11) підтримка після впровадження 6 Розробка плану і бюджету для підтримки ІС
продукту
12) піратське ПЗ 5 Купівля ліцензійне програмне забезпечення
13) компетентність керівника проєкту 5 Вибір керівника з досвідом роботи в даній ПО
14) створенню ІС загальної спрямо- 5 Перш за все розробка ІС, яка відповідає головним цілям, а
ваності якщо буде вистачати часу, то і для комерційних цілей
15) тісний графік робіт 5 Розробка графіку з проєктною командою
16) погана домовленість з проєктною 5 Назначати працівників на роботи, які працівник може і хоче
командою виконувати, чітка початкова домовленість по заробітній платі
на весь проєкт
17) постійний зв’язок з замовником 4 Створення сайту
18) підбір не підходящої проєктної 4 Ретельний підбір команди
команди (вибір персоналу)
19) неадекватне тестування 4 Розробка плану тестування
20) якість управління 4 Вибір керівника з досвідом роботи в даній ПО
21) немає підходящої проєктної ко- 3 Відведення часу для навчання проєктної команди
манди
22) відсутність документації 2 Постійне ведення проєктувальної документації
23) економічна криза в країні 1 Страхування від таких ситуацій

54

Етап 4. Установлюється формат звіту для кожного ризику. Цей звіт заслухову-
ється на щотижневих зустрічах проєктної команди, де розглядається стан проєкту.
Показується стан найбільших десяти ризиків, зміни в ранжируванні для кожного ри-
зику за останній тиждень. Відображається звіт відгуків-контрзаходів про ризики і про
їхні зміни.
Етап 5. На заключному етапі необхідно постійно перевіряти управління і ско-
рочення ризиків є безперервним процесом у рамках життєвого циклу проєкту ІС. Від-
стеження і контроль ризиків, включених у список, виконуються на регулярній основі.
Менеджер проєкту і всі члени команди повинні звертають увагу на поводження іден-
тифікованих ризиків, а також постійно контролюють процеси їхнього визначення.
Нові ризики, які виникають під час проєкту ідентифікуються, насамперед, для них ви-
значаються пріоритети, що потім додаються в план управління ризиками. Ризики з
високим пріоритетом варто обробляються відповідно до загального плану проєкту ІС.

2.9. Управління змінами проєкту

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

 тривалість і терміни завершення проєкту;
 вартість і бюджет проєкту;
 якість виконання робіт і специфікації вимог до результатів;
Внесення змін у проєкт припускає:
 виникнення додаткових витрат;
 порушення планових термінів здійснення проєкту;
 неможливість досягнення необхідної якості або результату проєкту.
У міру просування проєкту вартість внесених змін зростає, а практична цінність
часто убуває. У практиці використовуються наступні документи, що регламентують
і протоколюють проходження змін:
1) Звіт про проблему (Problem report) - опис проблеми, що виникає в ході реаліза-
ції проєкту. Формується на початковій стадії.
2) Запит на здійснення зміни (Change request) - формується на початковій стадії.
3) Опис передбачуваної зміни (Change proposal form) - інформація про зміну, його
поточному статусі, ініціаторах і відповідальних за виконання і контроль. Фор-
мується на початковій і коректується на наступних стадіях.
4) Заявка на зміну (Change order) - оформляється у виді письмового наказу і під-
писується посадовою особою підрядчика; дозволяє і вказує, які робити зміни по
проєкті. Формується на стадії ухвалення рішення.
Отже потенційними змінами в даному проєкті пов’язаного зі створенням інфо-
рмаційної системи можуть бути:
- можливі зовнішні зміни пов’язані з політичними, економічними соціальними,
законодавчими, технологічними, екологічними, міжнародними, географічними
аспектами;
- зміна структури інформаційної системи;
- зміна структури бази даних інформаційної системи;
- зміна кількості програм (модулів) інформаційної системи;
- зміна вартості і бюджету проєкту;
- зміна якості виконання робіт і специфікації вимог до результатів.

56

2.10 Контроль проєкту

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

57

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

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

Висновок до розділу 2.
В другому розділі здійснено управління проектом згідно методології PMBOK
на основі застосування програмного засобу “Microsoft Project”. Досліджені ризики
та їх ймовірність, визначені основні методи боротьби з ймовірними ризиками. Роз-
роблено план проекту, бюджет проекту, здійснено управління ресурсами, закупів-
лями та якістю.

59

РОЗДІЛ 3. ОЦІНКА ЕФЕКТИВНОСТІ ПРОЄКТУ

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

Таблиця 3.1
Календарний графік фінансування інвестиційної фази
Дисконтовані виттра-
Потреба в капіта- Коефіцієнт дис- Дисконтовані ти з наростаючим під-
Місяць ловкладенні, грн. контування витрати, грн сумком, грн
1 73470 0,952380952 69971,43 69971,43
2 75487 0,907029478 68468,93 138440,4
3 89289 0,863837599 77131,2 215571,6
4 99963 0,822702475 82239,81 297811,4
5 101157 0,783526166 79259,16 377070,5
6 94499 0,746215397 70516,61 447587,1
7 89379 0,71068133 63519,99 511107,1
8 73079 0,676839362 49462,74 560569,9
Всього 696323 560569,9

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

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

Назва Показники
1. Середньорічний обсяг реалізації продукції (ОР), 2-3
2.Середня ціна реалізації замовлення (Ц), т. грн./одиницю 25,5
3. Прямі витрати для 1 замовлення (П), т.грн./одиницю 8,8
4. Прямі витрати на оплату праці (ОП), т.грн./одиницю, (з нарахуваннями) 7,5
5. Постійні витрати операційної діяльності (ПВ), тис.грн./рік 46,04

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

1. Коефіцієнт щорічного зростання (зниження) ціни продукції (Ц )
1,02
2. Коефіцієнт щорічного зростання (зниження) ціни на продукти(сировину)
(Ц П )
1,02
3. Коефіцієнт щорічного зростання (зниження) рівня оплати праці (ОП ) 1,02
4. Коефіцієнт щорічного зростання рівня постійних витрат (ПВ ) 1,02

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

61

Рисунок 3.1 - Графік поточних потреб у капіталовкладеннях

3.2. Розробка зведеного кошторису витрат інвестиційної фази проекту

Основою для розробки планового зведеного кошторису (бюджету) витрат ін-
вестиційної фази проекту служать дані прогнозу витрат окремих робіт. Для проце-
сів, витрати на які визначені як щоквартальні, розраховуються загальні суми витрат,
що враховують кількість кварталів. У кошторисі фігурують роботи, що потребують
фінансових затрат (крім фіктивних робіт).
Зведений кошторис, що наведено у табл. 3.5 є одним з найважливіших плано-
во-координуючих документів, що забезпечує процеси управління ходом реалізації
проекту.
Таблиця 3.5
Зведений кошторис
планових витрат інвестиційної фази проекту
№ п/п Процеси, роботи Витрати, грн.
1 Старт проекту 43470
2 Підготовчі роботи 65487
3 Аналіз 109289

62

Продовження таблиці 3.5
№ п/п Процеси, роботи Витрати, грн.
4 Проектування 109963
5 Реалізація 154157
6 Тестування 124499
7 Впровадження 89367
8 Всього витрат 696323

Прогнозування значення показників за роками операційної діяльності (для t-го
року) складуть:
- прогноз середньої ціни одного замовлення:
Ц t = Ц t-1 * ∆Ц, грн./одиницю;
- прогноз прямих продуктових витрат:
П t = П t-1 * ∆Ц п, грн./одиницю;
- прогноз прямих витрат на оплату праці:
ОП t = ОП t-1 * ∆ОП, грн./одиницю;
- прогноз рівня постійних витрат операційної діяльності:
ПВ t = ПВ t-1 * ∆ПВ, грн./рік,
де Ц t-1,П t-1, ОП t-1, ПВ t-1 - відповідні показники попереднього року опера-
ційної діяльності (табл. 3.2);
∆Ц, ∆Цп, ∆ОП, ∆ПВ – коефіцієнти темпу зміни(зростання чи зниження)
значення показників для кожного наступного року операційної діяльності(табл.
3.3).
Таблиця 3.6
Прогноз динаміки вартісних показників операційної діяльності
Роки операційної діяльності
Показники 1 2 3 4 5 6 7 8 9 10
1. Середня ціна
одного замов-
лення (Цt),т.
грн./од. 25,5 26,01 26,53 27,06 27,60 28,15 28,71 29,29 29,87 30,47
2. Прямі про-
дуктові витра-
ти (Пt), грн./од. 8,8 8,976 9,155 9,338 9,525 9,715 9,910 10,10 10,31 10,51
63

Продовження табл.3.6
3. Прямі ви-
трати на оп-
лату праці
(ОПt),
т.грн./од. 7,5 7,65 7,803 7,959 8,118 8,280 8,446 8,615 8,787 8,963
4. Постійні
витрати
(ПВt),
тис.грн. 46,04 46,96 47,90 48,85 49,83 50,83 51,84 52,88 53,94 55,02

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

3.3. Планування амортизаційних витрат операційної діяльності

Метою розробки цього комплексу розрахунків є обґрунтування амортизацій-
них витрат за роками операційної діяльності, що наведено у таблиці 3.7. Стандарти
бухгалтерського обліку передбачають право суб`єкта самостійно вирішувати питан-
ня про строк і метод погашення амортизаційних витрат.
Самостійно обираємо найбільш доцільний метод амортизації та розраховуємо
величини амортизаційних відрахувань за роками операційної діяльності. В рамках
даних методів обираємо один, який передбачає застосування до амортизації, як
процесу погашення витрат, правил і норм, що застосовуються податковим законо-
давством для амортизації, як процесу накопичення коштів.
Діюче податкове законодавство відокремлює у складі основних фондів
суб‘єктів господарської діяльності 16 груп фондів, для кожної з яких встановлені
відповідні граничні норми амортизації від балансової вартості груп на початок року.
Виходячи з цих граничних норм визначаємо суму прибутку, яку підприємство може
вивести з оподаткування і направити на цілі оновлення основних фондів.
Розмір річної амортизації групи основних фондів для t-го року операційної ді-
яльності складає:

Аt БtВНам* , грн.,
100
64

де БВt – балансова вартість групи на початок року, грн.;
Н ам – встановлена підприємством норма річної амортизації (не більше грани-
чних норм), %.
Таблиця 3.7
Розрахунок амортизаційних витрат за роками операційної діяльності
Пер-
Мініма- Роки
вісна льно до-
вар- пустимі
тість, строки
корисного 1 2 3 4 5 6 7 8 9 10
Група тис.гр викорис-
ОФ н. тання
3 26,32 15 2,106 1,937 1,782 1,639 1,58 1,38 1,76 1,14 1,08 0,94
6 4,265 4 1,76 1,23 0,614 0,368 0,221 0,132 0,079 0,047 0,028 0,01
4 13,04 5 0312 2,37 1,80 1,37 1,04 0,793 0,603 0,458 0,348 0,26
4 0,690 2 0,414 0,165 0,066 0,026 0,010 0,004 0,001 0,006 0,002 0,01
Разом 443,2 7,45 5,70 4,5 3,887 3,245 2,984 2,613 2,416 2,358 2,27

3.4. Прогноз доходів та витрат операційної діяльності

Операційні доходи за роками операційної діяльності визначаються запланова-
ними обсягами виробництва, реалізації продукції і рівнем цін на продукцію. Ро-
зрахунок річних сум доходів за 10 років операційної фази проекту представлений у
формі наступної таблиці:
Річні суми операційних витрат для t-го року операційної фази проекту скла-
дають:
ОВВПЗАВП,(тисК. грн.)
t t t t t
де ВЗ – витрати змінного характеру (тис. грн.)
t
ПВ - витрати постійного характеру (тис. грн.)
t
А – амортизаційні погашення(тис. грн.)
t
Таблиця 3.8
Прогноз доходів операційної діяльності
Роки операційної діяльності
Показники
1 2 3 4 5 6 7 8 9 10
65

1.Середньорічні 2 3 3 3 3 2 2 2 2
обсяги реалізації
продукції (ОР),
одиниць 2
2. Середня ціна
реалізації замов-
лення (Ц), т.
грн./одиницю 25,5 26,01 26,53 27,06 27,60 28,15 28,71 29,29 29,87 30,47
3. Річний дохід
(Д) тис.грн 51 52,02 79,59 81,18 82,8 84,45 57,42 58,58 59,74 60,94

Річні суми витрат змінного характеру для t-го року операційної фази проекту
складуть:
ОР П  
ВЗ  t t ОПt , тис.грн.
t 1000

де ОР – обсяг реалізації продукції, одиниць;
t
П – витрати на продукти (сировину) для одного замовлення, грн./од;
t
ОП – витрати на пряму оплату праці (з нарахуваннями) на одиницю продук-
t
ції, грн./од.
Розробляємо і оформлюємо прогноз операційних витрат. Розрахунок
представлений у табл. 3.9.
Таблиця 3.9
Прогноз витрат операційної діяльності, тис. грн.

Роки операційної діяльності
Показник 1 2 3 4 5 6 7 8 9 10
1. Змінні 2,0195 2,0599 2,1011 2,1431 2,1860 2,2297 2,2743 2,3198 2,3662 2,4135
витрати 7
(ВЗ)
2. Постійні
витрати
(ВП) 46,04 46,96 47,9 48,85 49,835 50,831 51,848 52,885 53,943 55,022
3.Амортиза 7,45 5,70 4,5 3,887 3,245 2,984 2,613 2,416 2,358 2,276
ція (А)
Разом опе-
раційні ви-
трати (ОВ) 55,509 54,719 54,501 54,880 55,266 56,044 56,735 57,620 58,667 59,711

66

Прогноз грошових потоків операційної діяльності
Прогнозний аналіз грошових потоків операційної діяльності на основі
співставлень доходів і витрат за роками цієї фази дає картину формування прибутку
(табл.. 3.10).
Розрахунок грошових потоків базується на використанні попередніх таблиць.
Розмір балансового прибутку t-го року проекту складе:
ПБДО, Втис. грн.
t t t
Оподаткований прибуток t-го року операційної фази проекту складе:
ОПБА, тис. грн.
t t t
Податок на прибуток t-го року складе:
ПОПНп* , тис. грн.
t t
100
де Н п - діюча на момент розрахунків ставка (норма) податку на прибуток,
дор. 25%.
Чистий прибуток t-го року:
ПЧОП, тис. грн.
t t t

Таблиця 3.10
Прогноз грошових потоків операційної діяльності

Показни- Роки операційної діяльності
ки 1 2 3 4 5 6 7 8 9 10
1. Дохід
від реалі-
зації (Д),
тис грн 51 52,02 79,59 81,18 82,8 84,45 57,42 58,58 59,74 60,94
2. Опера-
ційні ви-
трати,
грн (ОВ) 55,50 54,71 54,501 54,880 55,266 56,044 56,735 57,620 58,667 59,711
3. Прибу-
ток (ПБ) -4,5 -2,69 -1,441 -0,76 -0,066 0,256 0,685 0,96 1,073 1,229
4. Амор- 7,45 5,70 4,5 3,887 3,245 2,984 2,613 2,416 2,358 2,276
тизація
67

(А)
5 Опода-
ткований
прибуток
(ОП) -11,95 -8,39 20,589 22,413 24,289 25,422 -1,928 -1,456 -1,285 -1,047
6. Пода-
ток на
прибуток
(П) -2,39 -1,67 4,1178 4,4826 4,8578 5,0844 -0,385 -0,291 -0,257 -0,209
7. Чистий
прибуток
(ПЧ) -9,56 -6,71 16,471 17,930 19,431 20,337 -1,542 -1,164 -1,028 -0,837

3.5 Прогноз грошових потоків проекту
Метою виконання даних прогнозних розрахунків є співставлення грошових
потоків інвестиційної, операційної, і фінансової діяльності в межах даного проекту з
тим, щоб переконатися в його ефективності. При виконанні даної роботи розрахунки
виконуються за перші 2 роки інвестиційної фази (з розбивкою за кварталами) та
послідуючі 10 років операційної фази проекту. Саме такий підхід застосовується у
практиці проектного аналізу.
В цілому картина грошових потоків проекту, в ситуації що моделюється в
роботі, має вигляд за формою таблиці 3.11. При виконанні розрахунків коефіцієнти
дисконтування для квартальних періодів інвестиційної фази визначаються за
квартальною нормою доходу, а для річних періодів операційної фази – за річними
нормами доходу на капітал. Для t-го періоду значення коефіцієнта дисконтування
складає:
КД  1 ,
t t
 Н д 1 
 100
де Н – норма доходу на капітал.
д
Величину Н виходячи із ситуації у банківських та інвестиційних сферах на
д
момент виконання роботи дорівнює 25%.
68

Таблиця 3.11
Прогноз грошових потоків проекту

Фази, роки, квартали проекту
Інвестиційна фаза, тис грн Роки операційної фази, тис грн
Показники Місяці
1 2 3 4 5 6 7 8 9 10
1 2 3 4 5 6 7 8
1. Грошові потоки ін-
вестиційної діяльності 73,47 75,48 89,289 99,96 101,15 94,499 89,37 73,08
2. Чистий прибуток
операційної діяльності -9,56 -6,71 16,47 17,93 19,43 20,33 -1,54 -1,16 -1,02 -0,87
3. Амортизація 7,45 5,70 4,5 3,887 3,245 2,984 2,613 2,416 2,358 2,276
4. Сальдо реальних - - - - - - -
грошей 73,47 75,48 89,289 -99,96 101,15 94,499 89,37 73,08 -9,56 -6,71 16,47 17,93 19,43 20,33 -1,54 -1,16 -1,02 -0,87
5. Коефіцієнт дискон-
тування 0,95 0,90 0,863 0,822 0,783 0,746 0,71 0,67 0,51 0,40 0,32 0,26 0,20 0,16 0,13 0,10 0,08 0,06
6. Дисконтований по-
тік грошей за періода-
- - - - - - - - - -
ми 69,79 67,93 77,056 -82,16 79,200 70,496 63,45 48,96 4,875 2,684 5,270 4,661 3,886 3,252 -0,20 0,116 -0,38 -0,16
7. Дисконтований по-
тік грошей наростаю-
чим підсумком -69,7 -137, -214,7 -296,9 -376,1 -446,6 -510 -559, -4,9 -7,58 -2,31 2,348 6,234 9,487 9,286 9,170 8,781 8,620

69

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

Рисунок 3.2 - Схема номінальних грошових потоків проекту

3.6 Оцінка показників ефективності проекту

Розрахунок показників ефективності проекту робиться на підставі прогнозу і
по реалізації за 12 років. За формалізованим підходом показник абсолютного ефекту
проекту визначається як різниця між накопиченими грошовими притоками і
відтоками проекту. Якщо мова йде про дисконтовані грошові потоки, то цей
показник має назву чистого дисконтованого прибутку (доходу) проекту – ЧДП
(ЧДД).
ЧДП П *КД 
t В *КД  8,620
t t t тис.грн,
де П t - поточні грошові притоки, тис. грн.;
Вt - поточні грошові відтоки, тис. грн.
Таке значення ЧДП свідчить про ефективність проекту.
Показник відносної ефективності використання капіталу – індекс прибутково-
сті (дохідності) капіталу проекту:
2

ІД П *КД
 t
t 1,1
В *КД
t t
Індекс дохідності більше 1, що також свідчить про ефективність проекту.
Для розрахунку строку окупності капіталу, що передбачається вкласти у про-
ект, визначається величина середньорічних грошових притоків:
П *КД
П  t t тис. грн.,
Т оп
де Т оп - тривалість операційного періоду генерування грошових притоків, ро-
ків.
Очікуваний строк окупності капіталу, що буде вкладений у проект:
В *КД
Т  t t 10років

ок П
Показник внутрішньої норми доходності проекту (ВНД) визначається на
підставі рішення рівняння:
П *КД В *КД  0
t t t t
Якщо підставити вираз:
КД 1
t t

Н  ,
д
1 
 100
отримуємо наступне вирішення цього рівняння:

Пt  Вt 
0
t t
 Н  Н
 д1  1 д
 100 100
Вирішення цього рівняння відносно X Нд , дає значення Н д , яке являє
собою показник ВНД.
Цей показник повинен бути більшим ніж норми доходу на капітал, яка покла-
дена в основу розрахунків показників ефективності проекту
3

В даній задачі ВНД = 25%, що є відповідає значенню від норми доходу на ка-
пітал (25%). Отже, за всіма розрахованими показниками ефективності, даний проект
є ефективним для впровадження для власних потреб турагенства.

3.2. Оцінка соціальної ефективності проєкту

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

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

Рис. 3.2. Соціальний аналіз проєкту
Окремо в аналізі варто розглянути технічні аспекти місця людини у проєкті:
заплановані умови праці, режим роботи, дотримання правил техніки безпеки. Робота
працівника буде відповідати всім нормам і стандартам безпечної роботи. Буде про-
ведено вступний, а через певний час і повторний інструктаж по техніці безпеки.
Здійснюючи соціальний аналіз проєкту, необхідно враховувати, що для біль-
шості проєктів основним є аналіз впливу проєкту на рівень життя залученого персо-
налу і оцінка його екологічної безпеки. Аналізуючи даний проєкт, можна зазначити,
що рівень життя залученого персоналу зростатиме, адже планується надбавки за
ефективну і активну роботу. Індексація заробітної плати відповідно до динаміки
роздрібних цін на товари і регулювання продажних цін на певні види товарів для
населення. Що до оцінки екологічної безпеки, то проєкт є повністю безпечним.
Висновок до розділу 3.
5

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

6

ВИСНОВОК

В даній магістерській дипломній роботі розглянуто управління проєктом впро-
вадження програмного продукту (ІС) для туристичних компаній. Питання пов’язані з
успішним управлінням проєктів на сьогодні є досить актуальні, оскільки в галузі ін-
формаційних технологій, оскільки часто виникає визначений набір невирішених про-
блем, таких як збільшення обсягу операцій і зменшення швидкості роботи системи,
використання могутньої системи не на повну потужність, перетворення впроваджен-
ня в нескінченний процес, постійну зміну вимог. Саме цими питаннями і займається
управління ризиків та управління змінами в проєкті. Знаючи методи і аналізи бороть-
би з ризиками та змінами і використовуючи їх в управлінні проєктами в галузі ство-
рення інформаційної системи, можна уникнути зриву проєкту.
При цьому були вирішені наступні задачі:
- проведено управління проєктом впровадження програмного продукту (ІС) для
туристичних компаній;
- розглянуто моделі, методи і аналізи боротьби з ризиками при управлінні проєк-
тами в галузі створення інформаційних систем;
- розглянуто міжнародні стандарти якості з управління ризиками проєкту ство-
рення інформаційних систем;
- проведено досить детальне управління ризиками вибраним методом, що скла-
дається з п'яти етапів, використовуючи 12 категорій ризиків;
- проаналізовано особливості управління змінами в проєктах створення інформа-
ційних систем;
- розраховано економічну ефективність проєкту впровадження програмного про-
дукту (ІС) для туристичних компаній.
В результаті проведення аналізу управління ризиками та змінами в проєктах в
галузі створення інформаційних систем, було зроблено такі висновки:
- для вирішення задачі управління ризиками існує багато, методів, кожний із них
має свої особливості, обумовлені властивостями і характеристиками об'єктів
розробки — комплексів програм, а також систем і зовнішнього середовища, у
7

яких вони застосовуються. Моделі відрізняються специфікою інтересів і квалі-
фікації їхніх авторів і охоплюють широкий спектр реальних ситуацій проєкту-
вання інформаційних систем, у яких необхідне скорочення або виключення ри-
зиків проєктів;
- в моделях, що приводяться, увага акцентується на процесах аналізу і зменшен-
ня ризиків, однак практично відсутні оцінки реальних значень ризиків, що мо-
жуть бути досягнуті при пропонованих методах і стратегіях. Рішення цієї задачі
сильно залежить від параметрів і характеристик реальних проєктів ІС і навряд
чи може конструктивно вирішуватися в загальному виді. Приведений набір мо-
делей і стандартів і їхні фрагменти доцільно узагальнювати і використовувати
розроблювачам і замовникам складних ІС високої якості для формування влас-
них керівних документів підприємства при необхідності забезпечення мініма-
льних ризиків у життєвому циклі конкретних програмних продуктів;
- при управлінні ризиками в магістерській роботі, зроблено висновок, що в проє-
ктах в галузі створення інформаційних систем, досить часто виникають ризики,
які охоплюють широкий спектр різноманітних ситуацій, для яких необхідно
знайти метод боротьби з ними. Є ризики, з якими досить легко боротися, а є ри-
зики, які відомі розробникам, але невідомо їх реальні перспективи для того чи
іншого проєкту, з якими досить важко боротися і які можуть принести досить
великі втрати для проєкту. Тому необхідно досить ретельно аналізувати мож-
ливі ризики, які виникають в проєктах в галузі створення інформаційних сис-
тем;
- при управлінні змінами в проєкті зроблено висновок, що у міру просування
проєкту вартість внесених змін зростає, а практична цінність часто убуває.
В результаті управління проєктом впровадження програмного продукту (ІС)
для туристичних компаній отримали такі результати.
Проєкт розбитий на 6 фаз: підготовчі роботи, аналіз, проєктування, реалізація,
тестування та впровадження.
Час виконання проєкту рівний: Т = 150, 64 днів
Бюджет проєкт: С = 580 тис. грн.
8

При визначенні оцінки економічного ефекту проєкту створення інформаційної
системи для туристичних компаній, отримали результати, що даний проєкт є досить
перспективним.
ЧДП = 53200 грн. - свідчить про високу комерційну ефективність проєкту.
ІД = 1,66 – індекс прибутковості капіталу, досить високий.
Ток = 0,6 років
Проєкт дуже швидко може окупитися 7-8 місяців. Якщо б даний проєкт окуп-
лювався в межах 2-3 років, даний проєкт був зовсім не перспективний, оскільки га-
лузь інформаційних технологій швидко змінюється і через 2-3 роки, створену інфор-
маційну систему необхідно було б міняти, а це означає, що фірма не отримала ніяких
прибутків, а могла і понести збитків.
При виконанні магістерської дипломної роботи було проведено управління
проєктом за допомогою сучасних програмних засобів проєктного менеджменту.
9

СПИСОК ВИКОРИСТАНОЇ ЛІТЕРАТУРИ

1. Sutherland, Jeff; Sutherland, J.J. Scrum: The Art of Doing Twice the Work in Half
the Time (1st ed.). Currency, 2014. – p. 256. ISBN 9780385346450.
2. Bichler, Shimshon; Nitzan, Jonathan Systemic Fear, Modern Finance and the Fu-
ture of Capitalism, Jerusalem and Montreal, 2010, pp. 8–11.
3. Pekoz, Erol The Manager's Guide to Statistics. ProbabilityBookstore.com, 2009. –
26 р. ISBN 9780979570438.
4. Belov, Mikhail V., Novikov, Dmitry A. Methodology of Complex Activity: Foun-
dations of Understanding and Modelling. Heidelberg: Springer, 2020. – 290 с.
5. Antonio Nesticò, Gianluigi De Mare A Multi-Criteria Analysis Model for Invest-
ment Projects in Smart Cities. Environments, 2018, 5(4), 50.
6. Novikov D. Control Methodology. – New York: Nova Science Publishers, 2013. –
76 p. ISBN 978-1624179624.
7. Charles G. Cobb The Project Manager's Guide to Mastering Agile: Principles and
Practices for an Adaptive Approach. John Wiley & Sons. 2015, p. 378. ISBN 978-
1-118-99104-6.
8. Collyer, S., & Warren, C. M. (2009). Project management approaches for dynamic
environments. International Journal of Project Management, 27(4), 355–364.
9. Ярошенко Ф.А., Бушуев С.Д., Танака Х. Управление инновационными проек-
тами и программами на основе системы знаний Р2М - К.: 2011. – 268 с.
10. Serrador, P. & Turner, R. (2015). The relationship between project success and pro-
ject efficiency. Project Management Journal, 46(1), 30–39.
11. Prokopenko, T.A., Zyelyk, Ya.L. Complex method of strategic decision-making in
management of technological complexes of continuous type. - Journal of Automa-
tion and Information Sciences. - 2017.- Volume 49. - P.71 -79
12. Prokopenko, T.A., Ladanyuk A.P. Information model of control of the continuous
type technological complexes in the class of organizational and technological sys-
tems // Journal of Automation and Information Sciences, 2014, Volume 46, Issue 9,
Pages 78-85
10

13. Большаков А. А. Интеллектуальные системы управления организационно-
техническими системами [Текст] / под. ред. А. А. Большакова. - М.: Горячая
линия-Телеком, 2006. – 160 с.
14. Большаков А.А. Синтез интеллектуальных организационно-технических си-
стем управления. // Вестник Тамбов. Гос. Техн.. ун-та. 2004. – Т. 10 №4а. - С.
954 – 959.
15. Юдицкий, С.А. Моделирование динамики многоагентных триадных сетей –
М.: СИНТЕГ, 2012. – 112 с.
16. Архангельский В.И., Богаенко И.В., Грабовский Г.Г., Рюмшин Н.А. Интегри-
рованное управление производством: организационные и технологические ас-
пекты менеджмента предприятиями – К.: «Техніка», 2005. – 328 с.
17. Борисов В.В., Сысков В.В. Мультиагентное моделирование сложных органи-
зационно-технических систем в условиях противоборства // Информационные
технологии. - 2012. - № 4. - С.7 -14.
18. Саати Т. Принятие решений. Метод анализа иерархий / Т. Саати. – М.: Радио и
связь, 1993. – 150 с.
19. Прокопенко Т. О., Ободовский Б. П. Дослідження впливу компетентностей
членів проєктної команди на ефективність проєкту в галузі інформаційних
технологій// Вісник Національного технічного університету «ХПІ». Серія:
Стратегічне управління, управління портфелями, програмами та проектами.
2020. No 2, ст. 50-55
20. Tetiana Prokopenko, Yaroslav Povolotskyi CONCEPTUAL PROCEDURE FOR
ESTIMATING THE PERFORMANCE PROJECT BASED ON FLEXIBLE
SCRUM METHODOLOGIES IN THE FIELD OF INFORMATION
TECHNOLOGIES. Bulletin of NTU "KhPI". Series: Strategic Management, Portfo-
lio, Program and Project Management No. 2(4) (2021). – Р.60-66
21. Прокопенко Т.О., Лавданська О.В. Інформаційна модель керування проектами
галузі інформаційних технологій в умовах гнучкої методології Scrum.
Міжнародний науково-технічний журнал Проблеми управління та інформати-
ки. 2021 №2. С. 129 – 138.
11

22. ISO 12207 — Процеси життєвого циклу програмних засобів
23. ISO 15504 — Оцінка й атестація зрілості процесів створення і супроводи про-
грамних засобів і інформаційних систем, що доцільно використовувати при ро-
зробці комплексів програм.
24. ISO 10006:1996 "Адміністративне управління якістю. Провідні вказівки по за-
безпеченню якості при управлінні проєктом"/
25. ISO 10007:1995 "Адміністративне управління якістю. Провідні вказівки по уп-
равлінню конфігурацією"
26. «Жизненный цикл информационных систем». Григорий Ефимов
27. Баутов А. Н. Новый менеджмент качества. “CIO – Директор информационной
службы”, № 3, 2001 г.
28. Баутов А. Н. Оценка факторов, влияющих на качество программных продук-
тов. “CIO – Директор информационной службы”, № 5 – 6, 2001 г.
29. М.Г. Круглов, П.М. Козлов Управление качеством проєктов корпоративных
информационных систем
30. Бакаєв Л. О. Кількісні методи в управлінні інвестиціями. – К., 2000.
31. Бланк И. А. Инвестиционный менеджмент. – К., 2001.
32. Власова А.М., Краснокутська Н.В. Інноваційний менеджмент: Навч. посібник.
– К.: КНЕУ, 2002. – 92с.
33. Гончарова Н., Перерва П. Маркетинг інноваційного процесса – К., 2002. – с. 8-
256;
34. Губський Б.В. Інвестиційні процеси в глобальному середовищі. – К., 2002.
35. Економіка виробничого підприємства / Під ред. Петровича. - К., 2001;
36. Загородній А. В., Стадницький Ю. С. Менеджмент реальних інвестицій. – К.,
2000.
37. Золотогоров В.С. Инвестиционное проєктирование. – Мн., 2002.
38. Інформаційні системи і технології в економіці: Посібник для студентів вищих
навчальних закладів / За ред. В.С. Пономаренка. – К. : Видавничий центр
„Академія”, 2002. – 544с.
39. Инвестиции в Украине / Под ред. С.И. Вакарина. – К., 1996. – с. 87-93;
12

40. Инновационный менеджмент / Под ред. С.Д. Ильенковой. – М., 1997. – с. 6-
323;
41. Керівництво з питань проєктного менеджменту / Під ред. С.Д. Бушуєва, 2-е
вид., перероб. – К.: Видавничій дім “Деловая Украина”, 2000. – 198 с.
42. Кобиляцький Л.С. Управління проєктами: Навч. посіб. – К.: МАУП, 2002. –
2005 с.: іл. – Бібліогр.: с. 193 – 196.
43. Котлер Ф. Основы маркетинга. – М.: Прогресс, 2003.-736с.
44. Куденко Н.В. Стратегічний маркетинг: Навч. Посібник.- К.: КНЕУ, 2001.-
152с.
45. Курс предпринимательства / Под ред. В.Я. Горфинкеля. – М., 2003. – с. 350-
375;
46. Медынский В., Шаршукова Л. Инновационное предпринимательство. – М.,
2000. – с. 5-233;
47. Орлов О.О. Планування діяльності промислового підприємства. Підручник. –
К.: Скарби, 2002. – 336 с.
48. Оценка бизнеса / Под ред. А. Г. Грязновой, М. А. Федотовой. – М., 1998. – с.
263 – 283.
49. Плоткін Я.Д., Янушкевия О.К. Організація і планування виробництва: Навч.
видання. Львів: Світ, 2001 – с. 28-36;
50. Покровний С.Ф. Підприємництво: стратегія, організація, ефективність: Навч.
посібник . - К.: КНЕУ, 2002 – 350с.;
51. Проєктний аналіз. – Київ: ТОВ “Видавництво Лібра”, 1999. – 368 с.
52. Примак Т.О. Економіка підприємства. – К., 2001. – с. 112-122.
53. Сизоненко В. Підприємництво. – К., 2002р.
54. Ситник В. Ф., Писаревська Т.А., Єрьоміна Н.В., Краєва О. Основи інформа-
ційних систем : Навч. посібник . – К. : КНЕУ, 1997. – 252 с.
55. Титаренко Н. О. , Поручик А. М. Теорії інвестицій. – К., 2000.
56. Тян Р.Б., Холод Б.І., Ткаченко В.А.Управління проєктами.//Київ. 2003. с.221;
57. Управление исследованиями, разработками и инновационными проєктами /
Под. ред. С.В. Валдайцева. – СПб., 2003. – с. 6-205;
13

58. Управление проєктами: зарубежный опыт / А.Й. Кочетков и др. – С. – Пб.:
Два-Три, 1996.
59. Устинова Г. М. Информационные системы менеджмента : Осн. аналитические
технологии в поддержке принятия решений / Учебное пособие. – СПб : Изда-
тельство «ДиаСофтЮП», 2000. – 368 с.
60. Швиданенко Г.О. Обґрунтування інвестиційних проєктів у процесі трансфор-
мації форм власності. – К., 2002.
61. Куденко Н.В. Стратегічний маркетинг: Навч. Посібник.- К.: КНЕУ, 2001.-152с.
62. Покровний С.Ф. Підприємництво: стратегія, організація, ефективність: Навч.
посібник . - К.: КНЕУ, 2002 – 350с.;
63. Инвестиции в Украине / Под ред. С.И. Вакарина. – К., 1996. – с. 87-93;
64. Інформаційні системи і технології в економіці: Посібник для студентів вищих
навчальних закладів / За ред. В.С. Пономаренка. – К. : Видавничий центр
„Академія”, 2002. – 544с.
65. Титаренко Н. О. , Поручик А. М. Теорії інвестицій. – К., 2000.
66. Управління ризиками // http://wiki.tntu.edu.ua/Управління_ризиками
67. Шеремет В.В. и др. Управление инвестициями. В 2 т. – М.: Высшая школа,
1998., 243с.
68. Управление проєктами: Толковый англо-русский словарь-справочник/Под
ред. В.Д. Шапиро. – М.:Высшая школа, 2000.
69. Методические рекомендации по оценке проєктов и их отбору для финансиро-
вания. – М.: Информелектро, 1994.
70. Эрик Верзух., Управление проєктами. Второе издание. Ускоренный курс по
программе МВА: Перевод с англ. – М.: ООО «Диалектика» - М., 2007., - 480с.
71. Г.Л. Ципес, А.С. Товб. Менеджмент проєктов. В практике современной ком-
пании. – М., ЗАО «Олимп-Бизнес» 2006.. – 304с.
72. И.И. Мазур, В.Д. Шапиро, Н.Г. Ольдерогге. Управление проєктами. 3-е изда-
ние. – М. «Омега-Л»., 2007., - 610с.
73. Государственный университет управления., Учебник. Основы проєктного
управления. – М. «КНОРУС»., 2006., - 768с.
14

74. Р.Б. Тян, Б.І. Холод, В.А. Ткаченко. Управління проєктами. Підручник. – К.
2004., - 224 с.
75. Методичні рекомендації і завдання до контрольної роботи з курсу: "Інвести-
ційні інструменти проєктного менеджменту " для слухачів всіх форм
навчання спеціальності 8.000003 "Управління проєктами"
76. Мізюк Б.М. Особливості стратегічного управління підприємствами / Б.М. Мі-
зюк // Фінанси України. – 2002. – №12. – С. 31 – 36.
77. Морозов О.В., Такчук Л.М. Організаційно-економічні фактори управління які-
стю на підприємствах: Монографія / О.В. Морозов, Л.М. Ткачук. – Вінниця:
УНІВЕРСУМ-Вінниця, 2005. – 138 с.
78. Немчин М.С., Хобта В.М. Методика управління ризиками інвестиційних
проєктів / М.С. Немнич, В.М. Хобта // Матеріали всеукраїнської міжвузівської
наукової студентської конференції. – Київ, Київський національний економіч-
ний університет імені Вадима Гетьмана. – 2009, С. 85 – 86.
79. Никитин В.А. , Филончева В.В. . Управление качеством на базе стандартов
ISO-9000 / В.А. Никитин, В.В. Филончева. – С.-П.: Питер, 2004. – 127 с.
80. Овчаренко Л. Інноваційне підприємство: світовий досвід реалії України //
Економіка. Фінанси. Право. – 2001. - №2. – с. 3-5;
81. Одрехівський М.В. Методологічні аспекти організаційного проєктування ін-
новаційних підприємств. // Регіональна економіка. – 2000. - №3. – с. 88-94;
82. Пересада А.А., Майорова Т.В. Інвестиційне кредитування: Навч. посібник /
А.А. Пересада, Т.В. Майборода. – К.: КНЕУ, 2002. – 271 с.
83. Пересада А.А. Управління інвестиційним процесом / А.А. Пересада. – К.:
Лібра, 2002. – 472 с.
84. Про інвестиційну діяльність: Закон України // Відомості Верховної Ради
України. - 1992. - № 10. - Ст. 138; 1998. - №33. - Ст. 226; 1999. - №31. - Ст. 248.
85. Сайт компании ООО АКАНТ Управление проєктами Строительство и
реконсрукция, управление инвестиционньїми проєктами (реальньіе проєкти)
15

86. Ситніченко В. та ін. Удосконалення системи менеджменту підприємства на
принципах якості / В. Ситніченко та ін. // Стандартизація, Сертифікація,
якість. – 2004. – №5. – С. 55 – 58.
87. Словник-довідник з питань управління проєктами./ Бушуєв С.Д. Українська
асоціація управління проєктами. – К.: Видавничий дім „Деловая Украина”,
2001. – 640 с.
88. Словник-довідник з питань управління проєктами. – К:ВІПОЛ,2001.
89. Стратегічне управління: Метод. вказ. для студентів спеціальності «Економіка
підприємством», «Фінанси» / Упоряд. В.І. Хомяков та ін. – Черкаси: ЧДТУ,
2003. – 20 с.
90. Тарасюк Г.М. Управління проєктами: Навч. посібн. для вузів / Г.М. Тарасюк. –
2-е вид. – К.: Каравела, 2006. – 320 с.
91. Тесля Ю.М. Системна організація управлінських взаємодій як інструмент
підвищення ефективності реалізації складних проєктів / Ю.М. Тесля,
І.І. Оберемок, О.Г. Тімінський // Вісник ЧДТУ. – 2008. – №2. – С. 100 – 105.
92. Тупчієнко О. Управління затратами / О. Тупчієнко. – Кіровоград: Центральне
українське видавництво, 2004. – 220 с.
93. Тян Р.Б. та ін. Управління проєктами: Підручник для вузів / Р.Б. Тян та ін. –
К.: ЦНЛ, 2004. – 224 с.
94. Управление проєктом. Основы проєктного управлення: учебник/ кол. авто-
ров;под ред. проф. М.Л.Разу. -М.: КНОРУС, 2007, - 768 с.
95. Управление программами и проєктами / М.Л.Разу и др. – М: ИНФРА, 2001.
96. Управління проєктами: навч.-метод. посібн. для вузів / Л.О. Збаразька,
В.С. Рижиков, І.Ю. Ерфорт та ін. – К.: Центр учб. л-ри, 2008. – 167 с.
97. Управління ресурсами підприємства: Навч. посібн. для вузів / В. Крамаренко,
Б. Холод, Ю. Воробйов та ін. – К.: ЦНЛ, 2004. – 288 с.
98. Устинова Г.М. Информационные системы Менеджмента: Основные аналити-
ческие технологии в поддержке принятия решений / Учеб. Пособие. – СПб:
Издательство «ДиаСофтЮП», 2003. – 368с.
16

99. Фінансова діяльність підприємства: Підручник / О.М. Бандурка та ін. – К.:
Либідь, 2002. – 383 с.
100. Чирков В. Эффектометрия / В. Чирков. - К.: Феникс, 2005. – 240 с.
101. Чумаченько М. Амортизаційні відрахування - суттєве джерело фінансу-
вання інвестицій підприємства / М. Чумаченько // Бухгалтерський облік і
аудит. – 2004. – №8. – с. 6 – 8.
102. Хохлов Н.В. Управление риском: [учебное пособие для вузов] / Хох-
лов Н.В. – М.: ЮНИТИ-ДАНА, 2003. – 239 с.
103. Шаповал М.І. Основи стандартизації, управління якістю і сертифікації:
Навч. посібник / М.І. Шаповал. – К.: Вид-во ЄУ, 2001. – 173 с.
104. Шелудько В.М. Фінансовий менеджмент: Підручник для вузів / В.М.
Шелудько. – К.: Знання, 2006. – 440 с.
105. Шеремет А.Д., Ненашев Е.В. Методика финансового анализа: Учеб. По-
собие / А.Д. Шеремет, Е.В. Ненашев. – М.: Инфра-М, 2000. – 210 с.
106. Щукін Б.М. Аналіз інвестиційних проєктів: Конспект лекцій / Б.М.
Щукін. – К.: МАУП, 2002. – 128 с.
107. Экономика предприятия: Учебник / Под общ. ред. С.Ф. Покропивного. –
Пер. с укр. 2-го перераб. и доп. изд. – К.: КНЭУ, 2002.
108. Вдовічен А.А., Черешньовська Г.М. Методи оцінки ефективності інве-
стиційних проєктів // http://intkonf.org/kenvdovichen-aa-chereshnovska-gm-
metodi-otsinki-efektivnosti-investitsiynih-proektiv/
109. Верба В.А. «Проєктний аналіз (2000)» / В.А. Верба //
http://library.if.ua/books/134.html
110. Грещак М. Г., Коцюба О. С. Управління витратами: Навч.-метод. посіб-
ник для самост. вивч. дисц. / М.Г. Грещак, О.С. Коцюба. – К.: КНЕУ, 2002. –
131 с. // http://fingal.com.ua/content/view/204/39/
111. Дворнікова О.О. Управління якістю на підприємствах торгівельного
бізнесу / О.О. Дворнікова // http://intkonf.org/dvornikova-oo-upravlinnya-
yakistyu-na-pidpriemstvah-torgivelnogo-biznesu/

17

ДОДАТКИ

18

ДОДАТОК А
OBS проекту створення ІС управління турагенством
Проектний менеджер
Головний розробник QA-інженер QS-інженер Дизайнер Системний
адміністра-
тор
Розробник 1 Розробник 2 Розробник 3

19

ДОДАТОК Б
WBS проекту створення ІС управління турагенством
Проект створення ІС
управління турагенст-
вом

Доінвестиційна фаза Інвестиційна фаза Операційна фаза

Визначення цілей Проектування Впровадження
проекту

Встановлення за- Супровід
вдань проекту Реалізація

Аналіз Тестування

Підготовчі роботи Документування

20

ДОДАТОК В

21

22

ДОДАТОК Г

23

24

ДОДАТОК В

25

ChSTU repository

ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets