Управління проєктом розробки інформаційної системи  автоматизованої видачі мастильних матеріалів на СТО

Рябчук, Сергій Григорович

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

Title:	Управління проєктом розробки інформаційної системи автоматизованої видачі мастильних матеріалів на СТО
Authors:	Андрієнко, Володимир Олександрович Рябчук, Сергій Григорович
Keywords:	ІНФОРМАЦІЙНА СИСТЕМА;РОЗРОБКА ПРОЄКТУ;ПЛАНУВАННЯ ПРОЄКТУ;МАСТИЛЬНІ МАТЕРІАЛИ.
Issue Date:	29-Jan-2024
Abstract:	Сьогодні кожен живе в світі, в якому інформаційні технології і комп’ютеризація займає велике місце в життєдіяльності людей. Люди хочуть отримувати максимальний прибуток, затративши мінімальність ресурсів. З цим пов’язано і бажання витрачати менше часу на ту чи іншу справу. Автоматизація процесу мінімізує участь звичайного працівника підприємства у його виконанні, що значно зекономить час самому працівнику і пришвидшить виконання наступних процесів. Також автоматизація процесу дає можливість провести точну видачу мастила з подальшим його обліком, що суттєво вплине на фінансову складову для організації. Мета дослідження полягає в розробці інформаційної системи автоматизованої видачі мастильних матеріалів на СТО. Об’єкт дослідження: проєкт автоматизації видачі мастильних матеріалів на станції технічного обслуговування на різних фазах його реалізації. Предмет дослідження: проєкт інформаційної системи автоматизації процесу видачі мастильних матеріалів на СТО. Апробація результатів роботи. Основні положення і результати кваліфікаційної роботи магістра доповідалися і були обговорені на пятій міжнародній науково-практичній конференції «CURRENT CHALLENGES OF SCIENCE AND EDUCATION», 2024. Публікації. Рябчук С. Г. Управління проєктом розробки інформаційної системи автоматизованої видачі мастильних матеріалів на СТО. [Текст] : // V Міжнародна науково-практична конференція “CURRENT CHALLENGES OF SCIENCE AND EDUCATION”, 15-17.01.2024. Берлін, Німеччина.
URI:	https://er.chdtu.edu.ua/handle/ChSTU/6744
Appears in Collections:	122 Комп’ютерні науки (Управління стартапами і проектами в галузі інформаційних технологій)

Files in This Item:

File	Description	Size	Format
Пояснювальна записка_ Рябчук Сергій_МСТП-2202_2023-2024.pdf Restricted Access		3.24 MB	Adobe PDF	View/Open Request a copy

Show full item record

Extracted text

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра комп’ютерних наук та системного аналізу
Пояснювальна записка
до кваліфікаційної роботи
магістра
(освітньо-кваліфікаційний рівень)
на тему: «Управління проєктом розробки інформаційної системи
автоматизованої видачі мастильних матеріалів на СТО»
Виконав: студент 2 курсу, групи МСТП-2202
спеціальності 122  «Комп’ютерні науки»
(шифр і назва спеціальності)
освітня програма «Управління стартапами
(назва освітньої програми)
і проектами в галузі інформаційних технологій»
Рябчук Сергій Григорович
Керівник Андрієнко В.О.
(прізвище та ініціали)
Рецензент Антонюк В.С.
(прізвище та ініціали)
Черкаси 2024 року
2
Бланк завдання на кваліфікаційну роботу магістра студенту
Черкаський державний технологічний університет
Факультет Інформаційних технологій і систем
Кафедра Комп’ютерних наук та системного аналізу
Освітньо-
кваліфікаційний рівень М Магістр
Спеціальність 122 – комп’ютерні науки
Освітня програма Управління стартапами і проєктами в галузі
інформаційних технологій
ЗАТВЕРДЖУЮ
Завідувач кафедри КНСА
___________ Юрій ТРИУС
«____» _____________ 20__ р.
ЗАВДАННЯ
на кваліфікаційну роботу магістра студенту
Рябчуку Сергію Григоровичу
(прізвище, ім‘я, по батькові)
1. Тема роботи «Управління проєктом розробки інформаційної системи
автоматизованої видачі мастильних матеріалів на СТО»
Керівник роботи Андрієнко Володимир Олександрович, к.т.н., доцент
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)
затверджені наказом університету від «06» жовтня 2023 р. № 267/04.
2. Строк подання студентом роботи «22» січня 2024 року
3. Вихідні дані до роботи:
Звіт з переддипломної практики
4. Зміст пояснювальної записки (перелік питань, що їх належить розробити):
Вступ
4.1. Аналіз передумов створення проєкту розробки інформаційної системи
автоматизованої видачі мастильних матеріалів на СТО.
4.2. Розробка концепції проєкту.
4.3. Планування та управління проєкту.
4.4 Моделювання виконання проєкту.
3
Висновки.
5. Додатки
5.1. Додаток А. Специфікація 482. ЧДТУ. 42248-01
5.2. Додаток Б. Аналіз наукових підходів до управління проєктними та
операційними ризиками
5.3. Додаток В. Публікація по темі кваліфікаційної роботи магістра.
Презентація у вигляді 25 слайдів.
6. Консультанти розділів роботи
Прізвище, ініціали Підпис, дата
Розділ та посада
завдання видав завдання прийняв
консультанта
7. Дата видачі завдання: 6.11.2023 р.
КАЛЕНДАРНИЙ ПЛАН
Строк
№ Назва етапів кваліфікаційної роботи
виконання Примітка
з/п магістра
етапів роботи
1 Видача завдання на кваліфікаційну Виконано
до 02.10.2023
роботу магістра.
2 Аналіз літературних джерел, об’єкту та Виконано
до 20.10.2023
предмету дослідження.
3 Написання теоретичного розділу Виконано
до 05.11.2023
кваліфікаційної роботи магістра.
4 Написання аналітичного розділу (аналіз Виконано
до 20.11.2023
об’єкту й предмету дослідження).
5 Написання практичних розділів й Виконано
до 05.12.2023
висновків по роботі.
6 Передзахист кваліфікаційної роботи Виконано
15.01.2024
магістра на засіданні випускової кафедри.
7 Подання роботи завідувачу кафедри. до 22.01.2024 Виконано
8 Захист кваліфікаційної роботи магістра. 29.01.2024 Виконано
Студент _____________________________ Сергій РЯБЧУК
(підпис)
Керівник роботи ____________________________ Володимир АНДРІЄНКО
(підпис)
4
РЕФЕРАТ
Кваліфікаційна робота магістра містить: 88 с., 39 рис., 10 табл., 51
використаних джерел.
Актуальність теми. Сьогодні кожен живе в світі, в якому інформаційні
технології і комп’ютеризація займає велике місце в життєдіяльності людей. Люди
хочуть отримувати максимальний прибуток, затративши мінімальність ресурсів. З
цим пов’язано і бажання витрачати менше часу на ту чи іншу справу. Автоматизація
процесу мінімізує участь звичайного працівника підприємства у його виконанні, що
значно зекономить час самому працівнику і пришвидшить виконання наступних
процесів. Також автоматизація процесу дає можливість провести точну видачу
мастила з подальшим його обліком, що суттєво вплине на фінансову складову для
організації.
Мета роботи і задачі дослідження. Мета дослідження полягає в розробці
інформаційної системи автоматизованої видачі мастильних матеріалів на СТО. Дана
робота розглядає проєкт автоматизації видачі мастила, що допоможе економити час
працівників і вести коректний облік мастильних матеріалів на підприємстві, який в
свою чергу буде економити кошти власників.
Завдання, що вирішуються в даному проєкті:
– проведення дослідження подібних систем на ринку;
– дослідження особливостей методології управління проєктами в галузі IT;
– аналіз оточення проєкту та формування стратегії;
– обґрунтування доцільності проєкту;
– проведення структурного планування;
– розробка компонентів управління проєктом;
– виявлення та оцінки можливостей подальшого удосконалення продукту з
метою розширення його функціональності.
Об’єкт дослідження: проєкт автоматизації видачі мастильних матеріалів на
станції технічного обслуговування на різних фазах його реалізації.
Предмет дослідження: проєкт інформаційної системи автоматизації процесу
видачі мастильних матеріалів на СТО.
5
Методи дослідження.
У процесі дослідження використовувалися наступні методи:
– аналіз ринку систем автоматизації видачі мастильних матеріалів та
дослідження конкурентів;
– PEST - аналіз;
– SWOT - аналіз;
– канва бізнес-моделі;
– метод декомпозиції;
– календарне планування;
– метод освоєного обсягу.
Готовий продукт проєкту буде складатись з програмного забезпечення та
контролера видачі мастила. Програмне забезпечення матиме можливість
підключення декількох контролерів видачі, що в свою чергу дасть можливість
одночасно отримувати різні типи оливи. Дана автоматизація процесу допоможе
економити кошти підприємства – буде вестись точний облік та видача, час механіка,
який перестає бути залежним від комірника, котрий раніше мав піти і набрати за
допомогою ручного насосу оливу. За рахунок автоматизації процесу клієнту
доведеться менше очікувати на власний автомобіль.
Апробація результатів роботи.
Основні положення і результати кваліфікаційної роботи магістра доповідалися
і були обговорені на пятій міжнародній науково-практичній конференції «CURRENT
CHALLENGES OF SCIENCE AND EDUCATION», 2024.
Публікації. Рябчук С. Г. Управління проєктом розробки інформаційної
системи автоматизованої видачі мастильних матеріалів на СТО. [Текст] : // V
Міжнародна науково-практична конференція “CURRENT CHALLENGES OF
SCIENCE AND EDUCATION”, 15-17.01.2024. Берлін, Німеччина.
Перелік ключових слів: ІНФОРМАЦІЙНА СИСТЕМА, РОЗРОБКА
ПРОЄКТУ, ПЛАНУВАННЯ ПРОЄКТУ, МАСТИЛЬНІ МАТЕРІАЛИ.
6
ABSTRACT
The master's thesis contains: 88 pages, 39 figures, 10 tables, 51 used
Asocutrucaelsi.t y of theme. Today, everyone lives in a world in which information
technology and computerization occupy a large place in people's daily life. People want to
get the maximum profit by spending the minimum amount of resources. This is connected
with the desire to spend less time on this or that matter. Automation of the process minimizes
the participation of an ordinary employee of the enterprise in its execution, which will
significantly save time for the employee himself and speed up the execution of subsequent
processes. Also, the automation of the process makes it possible to carry out accurate
dispensing of lubricant with its subsequent accounting, which will significantly affect the
financial component for the organization.
The purpose and objectives of the research. The purpose of the study is to develop
an information system for automated dispensing of lubricants at service stations. This work
considers the project of automating the dispensing of lubricant, which will help save the
time of employees and keep correct records of lubricants at the enterprise, which in turn will
save the owners' money.
Tasks solved in this project:
– conducting a study of similar systems on the market;
– study of the peculiarities of project management methodology in the field of IT;
– analysis of the project environment and strategy formation;
– substantiation of the feasibility of the project;
– carrying out structural planning;
– development of project management components;
– identification and evaluation of the possibilities of further improvement of the
product in order to expand its functionality.
The object of the research: the project of automating the dispensing of lubricants at
the technical service station in various phases of its implementation.
The subject of the research: project of an information system for automating the
process of issuing lubricants at service stations.
Research methods.
7

The following methods were used in the research process:
– analysis of the market of systems for automating the dispensing of lubricants and
research of competitors;
– PEST - analysis;
– SWOT - analysis;
– business model canvas;
– decomposition method;
– calendar planning;
– the method of mastered volume.
The finished product of the project will consist of software and a lubricant dispensing
controller. The software will have the ability to connect several dispensing controllers,
which in turn will make it possible to receive different types of oil at the same time. This
automation of the process will help save the company's money - accurate accounting and
issuance will be carried out, the mechanic's time will no longer be dependent on the
storekeeper, who previously had to go and collect oil using a manual pump. Due to the
automation of the process, the client will have to wait less for his own car.
Approbation of work results.
The main provisions and results of the master's qualification work were reported and
discussed at the fifth international scientific and practical conference "CURRENT
CHALLENGES OF SCIENCE AND EDUCATION", 2024.
Publications.
Ryabchuk S. G. Management of the project for the development of an information
system for the automated dispensing of lubricants at service stations. [Text] : // V
International scientific and practical conference "CURRENT CHALLENGES OF
SCIENCE AND EDUCATION", 15-17.01.2024. Berlin, Germany.
List of keywords: INFORMATION SYSTEM, PROJECT DEVELOPMENT,
PROJECT PLANNING, LUBRICANTS.
8

ЗМІСТ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, СКОРОЧЕНЬ І ТЕРМІНІВ ...... 10
ВСТУП ................................................................................................................................ 10
1 АНАЛІЗ ПЕРЕДУМОВ СТВОРЕННЯ ПРОЄКТУ РОЗРОБКИ ІНФОРМАЦІЙНОЇ
СИСТЕМИ АВТОМАТИЗОВАНОЇ ВИДАЧІ МАСТИЛЬНИХ МАТЕРІАЛІВ НА СТО
............................................................................................................................................. 14
1.1 Встановлення задачі та обґрунтування проблеми ................................................ 14
1.2 Опис ідеї проєкту ................................................................................................... 177
1.3 Маркетингові дослідження та аналіз оточення проєкту ...................................... 19
1.4 Альтернативні ідеї реалізації проєкту та аналіз аналогів .................................... 22
Висновки до розділу 1 ................................................................................................... 24
2 РОЗРОБКА КОНЦЕПЦІЇ ПРОЄКТУ ........................................................................... 25
2.1 Зацікавлені сторони та їх вплив на проєкт ............................................................ 25
2.2 Розробка концепції проєкту .................................................................................... 27
2.3 Життєвий цикл проєкту ........................................................................................... 29
Висновки до розділу 2 ................................................................................................. 322
3 ПЛАНУВАННЯ ТА УПРАВЛІННЯ ПРОЄКТОМ ................................................... 333
3.1 Планування змісту проєкту ................................................................................... 333
3.2 Організаційна структура проєкту ........................................................................... 38
3.3 Розробка календарного плану проєкту ................................................................ 411
3.4 Планування трудових та матеріальних ресурсів проєкту .................................... 46
3.5 Планування якості проєкту ..................................................................................... 56
3.6 Управління ризиками ............................................................................................... 58
3.7 Управління комунікаціями .................................................................................... 622
3.8 Моделювання виконання проєкту ........................................................................ 644
3.9 Проведення розрахунку бюджетної вартості ........................................................ 68
Висновки до розділу 3 ................................................................................................... 71
4 МОДЕЛЮВАННЯ ВИКОНАННЯ ПРОЄКТУ ТА ЙОГО РЕЗУЛЬТАТИ ............. 733
4.1 Моделювання продукту проєкту .......................................................................... 733
9

4.2 Опис процесу практичної реалізації проєкту ...................................................... 755
4.3 Механізм контролю робіт проєкту ........................................................................ 82
Висновки до розділу 4 ................................................................................................... 85
ВИСНОВКИ ....................................................................................................................... 87
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ......................................................................... 89
ДОДАТОК А Специфікація 482. ЧДТУ. 42248-01 ……………………………………94
ДОДАТОК Б Аналіз наукових підходів до управління проєктними та операційними
ризиками ………………………………………………………………………………....96
ДОДАТОК В Публікація по темі кваліфікаційної роботи магістра ………………….97

10

ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, СКОРОЧЕНЬ І ТЕРМІНІВ
САР – система автоматичного регулювання;
САК – система автоматичного керування;
СТО – станція технічного обслуговування;
ІТ – інформаційні технології;
ТО – технічний огляд;
ПК – персональний комп’ютер;
ТЗ – технічне завдання.

11

ВСТУП
Сьогодні кожен живе в світі, в якому інформаційні технології і комп’ютеризація
займає велике місце в життєдіяльності людей. На даний момент важко уявити своє
життя без різних гаджетів і комп’ютерної техніки. На кожному підприємстві
використовуються комп’ютери. Виробники комп’ютерів з кожним роком нас
дивують новими можливостями своїх винаходів. Великі організації і підприємства
все частіше і частіше використовують комп’ютерні технології і автоматизацію
процесу для виконання як складних і точних так і простих і легких завдань.
Автоматизація процесів в наш час використовується майже у всіх галузях і
сферах побуту людини. Від простого натиску кнопки для відкриття дверей чи
приготування кави до натиску кнопки для створення готової і складної деталі на
підприємстві. Автоматизація технологічних процесів – використання енергії неживої
природи в технологічному процесі або його складових частинах для їх виконання і
керування ними без безпосередньої участі людей, що здійснюється з метою
зменшення трудових затрат, покращення умов виробництва, підвищення обсягів
випуску й якості продукції. За рівнем автоматизації розрізняють часткову, повну і
комплексну автоматизацію технологічних процесів. Здійснюється за допомогою
систем автоматичного регулювання (САР) та систем автоматичного керування (САК)
[49]. Одним із процесів автоматизації також являється система автоматизованої
видачі мастильних матеріалів на СТО.
Актуальність теми. Сьогодні кожен живе в світі, в якому інформаційні
технології і комп’ютеризація займає велике місце в життєдіяльності людей. Люди
хочуть отримувати максимальний прибуток, затративши мінімальність ресурсів. З
цим пов’язано і бажання витрачати менше часу на ту чи іншу справу. Автоматизація
процесу мінімізує участь звичайного працівника підприємства у його виконанні, що
значно зекономить час самому працівнику і пришвидшить виконання наступних
процесів. Також автоматизація процесу дає можливість провести точну видачу
мастила з подальшим його обліком, що суттєво вплине на фінансову складову для
організації.
12

Даний проєкт мінімізує участь комірника в процесі отримання мастила
механіком, що в свою чергу дає можливість клієнту швидше отримати свій
автомобіль після ремонту.
Мета та задачі дослідження. Мета кваліфікаційної роботи магістра є
розробка інформаційної системи автоматизованої видачі мастильних матеріалів на
СТО. Дана робота розглядає проєкт автоматизації видачі мастила, що допоможе
економити час працівників і вести коректний облік мастильних матеріалів на
підприємстві, який в свою чергу буде економити кошти власників.
Для досягнення поставленої мети в роботі розв’язуються наступні завдання:
– проведення дослідження подібних систем на ринку;
– дослідження особливостей методології управління проєктами в галузі IT;
– аналіз оточення проєкту та формування стратегії;
– обґрунтування доцільності проєкту;
– проведення структурного планування;
– розробка компонентів управління проєктом;
– виявлення та оцінки можливостей подальшого удосконалення продукту з
метою розширення його функціональності.
Об’єктом дослідження є проєкт автоматизації видачі мастильних матеріалів на
станції технічного обслуговування на різних фазах його реалізації.
Предметом дослідження виступає проєкт інформаційної системи
автоматизації процесу видачі мастильних матеріалів на СТО.
У процесі дослідження використовувалися наступні методи:
– аналіз ринку систем автоматизації видачі мастильних матеріалів та
дослідження конкурентів;
– PEST - аналіз;
– SWOT - аналіз;
– канва бізнес-моделі;
– метод декомпозиції;
– календарне планування;
– метод освоєного обсягу.
13

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

14

1 АНАЛІЗ ПЕРЕДУМОВ СТВОРЕННЯ ПРОЄКТУ РОЗРОБКИ
ІНФОРМАЦІЙНОЇ СИСТЕМИ АВТОМАТИЗОВАНОЇ ВИДАЧІ
МАСТИЛЬНИХ МАТЕРІАЛІВ НА СТО
1.1 Встановлення задачі та обґрунтування проблеми
Автоматизація процесів посідає важливе місце в життєдіяльності людини. Вона
дає нам можливість більш якісно і швидше виконувати різні завдання. Є різні типи
автоматизації процесів на підприємстві, які мінімізують час витрачений працівником,
підвищують якість і продуктивність праці, а також дають можливість підприємству
економити кошти. Одним з таких типів автоматизації може стати система
автоматичної видачі мастильних матеріалів на СТО.
Станція технічного обслуговування (акредитоване СТО або «автосервіс») –
підприємство, що надає послуги з технічного обслуговування і ремонту
автомобільного транспорту, а також встановленню додаткового обладнання [50].
Сучасні СТО мають наступні ознаки:
– спеціалізовані СТО, які надають обмежений набір послуг. Це як правило
невеликі станції зі спеціалізованим обладнанням;
– загальні СТО, які надають більш широкий спектр послуг і потребують не
тільки більші площі, а і ширший перелік обслуговуючого;
– серед СТО можна виділити авторизовані сервісні центри офіційних дилерів.
Ремонт і обслуговування автомобілів у таких центрах зберігає гарантію дилера на
авто;
– також не потрібно забувати за так звані «гаражні СТО». Під цим терміном
мається на увазі автомайстри, які працюють самі і, не маючи змоги орендувати
відповідне приміщення, надають послуги з ремонту та обслуговуванню у своїх
власних чи орендованих гаражах у гаражно-будівельних кооперативах [50].
Сучасні СТО, можуть надавати послуги якісно і швидко тільки у випадку, якщо
у них є свій склад запчастин і комплектуючих. Як правило, на сучасних СТО є окрема
кімната для відпочинку клієнтів, обладнана телевізорами, а також іноді і дисплеями,
15

де видно процес ремонту автомобіля, орієнтовний час закінчення робіт, сповіщення
про закінчення роботи та інше.
Розподіл СТО за спеціалізацією:
– загальні СТО;
– СТО із ремонту вантажних, комерційних авто і автобусів;
– СТО із кузовного ремонту;
– СТО із ремонту АКПП;
– СТО із ремонту авто електрики;
– Студії автотюнінгу.
Внаслідок великої кількості автомобілів, послуги СТО є доволі затребувані, але
і конкуренція між ними присутня. За даними одного із інтернет-довідників у Києві,
наприклад, ведуть діяльність більше 1,5 тис. автосервісів різних типів.
Одним із факторів, за якими споживачі обирають, де проводити ремонт
власного авто, є розташування СТО (станції технічного обслуговування), що
дозволить заощадити час на поїздку та ціна, яку їм потрібно буде заплатити за
проведену роботу. Також не потрібно забувати про людський ресурс, бо якою не була
близькою в розташуванні СТО і яка не була низькою ціна, але якщо нема спеціалістів,
які здатні якісно виконати свою роботу, то на таку станцію мало хто заїде.
У зв’язку з поточною фінансово-економічною та соціальною кризою компанії,
які займаються сервісним обслуговуванням автомобілів, змушені розробляти
ефективні механізми управління, які забезпечуватимуть збереження позицій компанії
на ринку та підтримку досягнутих результатів діяльності. Однією з важливих
складових цього механізму є управління ціновою політикою [13]. Зниження
середнього рівня життя населення внаслідок воєнних дій і падіння реальних доходів,
з одного боку, призводить до загального зниження попиту, що супроводжується
зміною критеріїв, за якими споживачі оцінюють і вибирають товари та послуги, а з
іншого боку – впливає на обсяги та частоту їх купівлі. Водночас зростання
собівартості продукції призводить до підвищення закупівельних цін на товари,
збільшуються й витрати підприємств роздрібної торгівлі, що змушує їх підвищувати
рівень цін.
16

Аналізуючи цінову політику підприємств в сфері послуг, встановлено, що
найчастіше використовуються акційні пропозиції, дисконтні програми, що
накопичують бали та бонуси, рідше – дисконтні картки, що пропонують знижки [13].
Зараз українським споживачам вкрай необхідно економити, тому їм важливо
виконувати ремонт авто швидко, дешево і надійно.
Отже, головна проблема, яку потрібно вирішити – економія часу власника
автомобіля під час його ремонту або проведення планового технічного огляду (ТО),
економія часу комірника і економія коштів підприємства.
Метою створення проєкту є спроба вирішити оговорену проблему, тому
основне завдання – розробка автоматизованої системи видачі оливи, що допоможе
працівникам і клієнтам економити свій час і кошти. Продуктом проекту є
автоматизована система видачі мастила, яка дає можливість підприємству економити
кошти, мінімізувати участь комірника при видачі оливи цим самим пришвидшити
роботу механіка, що прямо пропорційно пришвидшенню отримання
відремонтованого автомобіля клієнтом.
Цільовою аудиторією майбутнього проєкту є станції технічного
обслуговування, які в робочих процесах мають заміну чи продаж оливи. Також варто
зазначити, що клієнтами, які будуть користуватися даною програмою є декілька –
комірник, механік та організація. Проблеми клієнтів, які необхідно вирішити,
відображені у канві ціннісної пропозиції, що зображена на рисунку 1.1.

Рисунок 1.1 – Канва ціннісної пропозиції
17

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

нової бочки в разі потреби. Також він може бачити всі видачі, які були до цього і на
підставі якого документу (наряд-замовлення чи видаткова накладна).
Також є доступ для адміністрування. В даному доступі є все перераховане вище,
а також можливість керування кранами. Під керування розуміємо, що є можливість
змінити ІР-адресу, а також назву оливи.
Клієнтська частина для механіків відрізняється. В них біля місця видачі стоїть
планшет на базі ОС Windows 10. Там в автозапуску стоїть окрема програма, яка
тримає зв'язок з базою даних і контролером видачі мастильних матеріалів. Також біля
планшету встановлено сканер штрих-коду за допомогою якого механік проходить
авторизацію. Для заощадження його часу програма містить мінімальну кількість
послідовних дій. Він сканує свій код після чого бачить кількість і назву оливи, що
йому потрібно отримати. Далі він натискає кнопку на планшеті «Отримати», після
цього висвічується вікно підтвердження чи дійсно він хоче отримати оливу (дане
вікно попередження створене з метою звернути його увагу і перевірити чи він
поставив ємність для отримання оливи під потрібний йому кран). Натиснувши кнопку
він отримує оливу.
Отже, готовим продуктом проекту є програмно-апаратний комплекс, який
забезпечує автоматичну видачу мастильних матеріалів на станції технічного
обслуговування автомобілів.
Підіб’ємо підсумок основних функцій програми:
– для комірника
1. зрозумілий інтерфейс користувача, який є зручним в користуванні;
2. мінімальна участь в процесі видачі оливи, що економить йому час для
виконання інших завдань;
3. можливість відслідковувати залишок оливи в бочці, що дає можливість
своєчасно підготувати іншу і потім оприбуткувати її;
– для механіка
1. зручний і зрозумілий інтерфейс;
2. мінімальна кількість операцій для отримання оливи;
3. економія часу;
19

– для підприємства
1. коректний облік видачі оливи;
2. економія коштів.
1.3 Маркетингові дослідження та аналіз оточення проєкту
Враховуючи проєктну ситуацію було проведено аналіз оточення проєкту.
Абревіатура PEST розшифровується як P (policy) – політичні фактори, E (economic) –
економічні фактори, S (Social) – соціальні та суспільні фактори, T (Technical) –
технологічні фактори [34]. Аналіз визначає поточні або очікувані тенденції в
технологічній, економічній, політичній та соціальній сферах, які можуть вплинути на
даний проєкт.
Виявлені фактори та їх вплив на проєкт було оцінено за наступною шкалою
впливу:
– 1 бал – даний фактор мало впливає і будь-яка його зміна не вплине на
проєкт;
– 2 - 3 бали – тільки значні зміни факторів матимуть вплив на майбутній
проєкт;
– 4 - 5 балів – вплив даного фактору високий, будь-які коливання можуть
викликати значні зміни в реалізації проєкту.
Позитивний чи негативний вплив кожен фактор має на проект показує знак «+»
або «-» перед оцінкою.
У таблиці 1.1 наведені дані PEST – аналізу проєкту, які буде використано при
подальших маркетингових дослідженнях.

20

Таблиця 1.1 – PEST - аналіз
Політичні фактори Економічні фактори
– Політична стабільність +2 – Рівень оподаткування -3
– Ступінь державного +2 – Темп інфляції -2
регулювання економіки – Загальна економічна -2
– Законодавча база -4 ситуація
– Вибори на усіх рівнях влади 2 – Динаміка курсу гривні -3
– Антимонопольне – Рівень безробіття -2
регулювання -3 – Інвестиційна +3
– Державне регулювання привабливість
конкуренції 1

Соціальні фактори Технологічні фактори
– Якість життя 1 – Нові патенти -2
– Вплив ЗМІ +2 – Поява нових -5
– Активність споживача 1 конкурентних технологій
– Демографічні зміни 2 – Нові інформаційні -4
– Рівень доходів населення 2 системи
– Потреба у постійному 1
навчанні, що обумовлена
швидкими
технологічними змінами

Для визначення сильних та слабких сторін продукту проєкту, можливостей та
загроз було проведено SWOT - аналіз. SWOT інтерпретується таким чином: S – сильні
сторони, переваги продукту, W – слабкі сторони, O – можливості, T – загрози.
Результати аналізу представлені на рисунку 1.2.
21

Рисунок 1.2 – SWOT - аналіз проєкту
Після аналізу проєкту та визначення сильних і слабких сторін, загроз та
можливостей було сформовано варіанти регулювання проектної ситуації для
подальшої розробки.
Як використати можливості?
– створення продукту;
– виведення продукту на ринок;
– проведення рекламної кампанії;
– займатися підтримкою продукту.
Що може завадити скористатися можливостями?
– недостатній рівень кваліфікації команди проєкту;
– неякісне виконання своїх обов’язків працівниками;
– вихід на ринок нових конкурентів.
За рахунок чого можна знизити загрози?
– провести якісний аналіз ринку;
– планування та управління можливими ризиками;
– підбір кваліфікованих працівників в команду проєкту.
Отже, дослідивши маркетингове середовище проєкту, можна стверджувати, що
він є перспективним, але потрібен більш детальний розрахунок його реалізації для
оцінки прибутковості та окупності проєкту.
22

Провівши дослідження, створили на їх основі канву бізнес-моделі (рис. 1.3), що
відображає основні складові бізнес-моделі проєкту:

Рисунок 1.3 – Канва бізнес-моделі
1.4 Альтернативні ідеї реалізації проєкту та аналіз аналогів
Взявши до огляду результат SWOT - аналізу (див. рис. 1.2), було проведено
аналіз альтернативних варіантів реалізації ідеї проєкту:
– Купівля сертифікованих електронних лічильників для ручної видачі оливи.
Переваги: точність при видачі мастильних матеріалів; економія часу механіка
для отримання оливи.
Недоліки: видача оливи повністю залежить від комірника; мала
функціональність; не вирішує поставлену проблему в повному обсязі.
– Купівля готової системи видачі мастильних матеріалів.
Переваги: можливість проводити точну видачу та контроль залишку оливи;
мінімізація участі комірника в процесі видачі оливи; економія часу механіка на
отримання оливи.
23

Недоліки: комірнику доводиться працювати в двох програмах одночасно, що
може спричинити помилки в роботі; більша витрата коштів за встановлення і запуск
програми; замалий функціонал; дана програма не повністю вирішує поставлену перед
нами проблему.
– Купівля сертифікованих електронних лічильників для ручної видачі оливи і
разом з цим найм додаткових працівників.
Переваги: комірник взагалі не приймає участь в процесі видачі оливи; точність
при видачі мастильних матеріалів; економія часу механіка для отримання оливи;
ведення точного обліку виданої оливи і залишку в бочці.
Недоліки: фінансово недоцільно наймати додаткових працівників для процесу
автоматизації; не вирішує поставлену проблему в повній мірі.
Приведені вище варіанти вирішують поставлену проблему лише частково (або
економія коштів підприємства, або економія часу працівника), тому для реалізації
проєкту було прийнято рішення створення програмно апаратного комплексу
описаного в роботі.
В даний момент, на ринку мало подібних розробок і вони мають різні недоліки
і преваги. Продукти конкурентів знаходяться у вищому ціновому сегменті та
пропонують менший функціонал.
Після дослідження ринку було виявлено наступні аналоги та конкуренти, що
подано в табл. 1.2:
Таблиця 1.2 – Аналіз конкурентів
Назва Переваги Недоліки
«Комплексні рішення міні – готове рішення – велика вартість
АЗС» – детальна інформація – відсутність адаптації з
про облік робочою програмою
– дороге після продажне
обслуговування і
витратні матеріали
«Автоматизація видачі та – готове рішення – велика вартість
приймання палива»
24

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

Отже, як видно з таблиці 1.2, основним конкурентом продукту даного проєкту
є програма «АВТОМАТИЗАЦІЯ ВИДАЧІ ТА ПРИЙМАННЯ ПАЛИВА». Проте, вона має
багато недоліків, а переваги над розроблюваним в продуктом незначні. Всі інші
аналоги мають обмежений функціонал в порівнянні з продуктом даного проєкту.
Висновки до розділу 1
У даному розділі проаналізовано мету створення проєкту, визначено проблему,
яку необхідно вирішити. На основі проведених досліджень, було сформульовано
декілька варіантів ідеї реалізації продукту проєкту, що повинні допомогти виконати
поставлену проблему та обрано серед них найкращу. Для ідеї, яку обрали, був
описаний детально потрібний функціонал для майбутнього проєкту.
Проведено маркетингові дослідження, SWOT - аналіз, PEST - аналіз та
розроблено канву бізнес-моделі проєкту. Аналіз ринку подібних програмно-
апаратних рішень показав, що дуже мало подібних розробок і вони мають більше
недоліків ніж переваг. Продукти конкурентів знаходяться у вищому ціновому
сегменті та пропонують менший функціонал. Це свідчить про те, що обрана ідея
продукту проєкту має право на існування і є конкурентоспроможною та
перспективною.

25

2 РОЗРОБКА КОНЦЕПЦІЇ ПРОЄКТУ
2.1 Зацікавлені сторони та їх вплив на проєкт
Для проведення аналізу зацікавлених сторін особливо важливо провести
комплексний аналіз усіх його учасників, зацікавлених у реалізації проєкту. Тому для
початку необхідно виділити всі зацікавлені сторони проєкту (рис. 2.1).

Рисунок 2.1 – Зацікавлені сторони проєкту

Розглянемо детальніше тепер всіх осіб, які беруть участь у проєкті:
– Замовник/Власник/Інвестор проекту – Компанія «СТО».
Відповідальність за: Фінансування, контроль виконання проєкту, надання
матеріально технічної бази.
Ціль: Отримати продукт проєкту, отримання прибутку.
– Ініціатор/Менеджер проєкту
Відповідальність за: Створення ідеї проєкту, пошук команди для її реалізації,
планування, контроль виконання проєкту, прийняття рішень на всіх етапах реалізації
проєкту.
26

Ціль: отримати продукт проєкту, досвід в управлінні проєктами, прибуток.
Головна ціль – успіх проєкту.
– Команда проєкту – програміст, адміністратор системи, схемотехнік.
Відповідальність за: розробка та реалізація автоматизованого робочого місця
видачі оливи, тестування продукту.
Ціль: отримати досвід роботи в команді, підвищити кваліфікацію, отримати
прибуток.
– Постачальник – магазин електродеталей.
Відповідальний за: своєчасну доставку потрібних для реалізації проєкту
деталей.
Ціль: отримання прибутку.
– Конкуренти – Автоматизація видачі та приймання палива.
Механізм участі: конкуренція, пошук переваг та недоліків.
– Споживачі кінцевої продукції – співробітники компанії «СТО».
Відповідальні за: користування продуктом проєкту, тестування та надання
відгуків і рекомендацій.
Ціль: отримати продукт, який заощадить їх час і задовольнить вимоги.
Клієнти – кінцеві користувачі продукту проєкту, отже продукт має відповідати
вимогам та очікуванням користувачів. Мати зручний інтерфейс і бути простим в
користуванні.
У таблиці 2.1 визначений вплив на проєкт зацікавлених сторін по різних
факторах (ресурси, вимоги до проєкту, процеси проєкту, оцінка виконання):
Проаналізувавши усі фактори які впливають на проєкт, можна зробити
висновок, що зацікавлені сторони позитивно вплинуть на проєкт завдяки власній
вигоді кожного.

27

Таблиця 2.1 – Вплив зацікавлених сторін на проєкт

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

зможе дати їм більш раціонально використовувати свій робочий час, проводити точні
видачі оливи, що в свою чергу зекономить кошти фірми.
Цілі проекту:
– отримати прибуток;
– мінімізувати участь комірника в процесі отримання оливи механіком.
Критерії досягнення цілей проєкту відображені в таблиці 2.2.
Таблиця 2.2 – Критерії досягнення цілей
№ Ціль Критерії
1. Отримати прибуток 30 000 грн через 6 міс після проєкту
2. Мінімізувати участь комірника в Механік отримує оливу в зручний для
процесі отримання оливи себе час без участі комірника
механіком

Продукт проекту: інформаційна система автоматизованої видачі паливо
мастильних матеріалів на СТО.
Основний функціонал продукту проекту:
– зручний та зрозумілий інтерфейс для взаємодії з основними елементами та
функціями програми;
– можливість точного обліку виданих мастильних матеріалів;
– можливість додати нових користувачів в систему для отримання оливи;
– при потребі змінити вид мастила, який видається;
– можливість додати новий вид мастила в існуючу систему чи видалити зайве.
Критерії успішності проекту:
– наявність продукту проєкту (готова та повністю функціонуюча програма,
яка відповідатиме вимогам);
– мінімізація участі комірника в процесі видачі оливи;
– відхилення від плану по проєктам ≤ 10%;
– кількість позитивних оцінок членів команди проекту ≥ 70%.
Обмеження проєкту:
– проєкт має бути реалізовано не більше ніж за 3 місяці;
29

– бюджет не повинен перевищувати 100 000 грн.
Допущення проекту:
– часове відхилення від плану реалізації проєкту не більше ніж 1 тиждень;
– бюджет може бути перевищено максимум на 10 000 грн.
2.3 Життєвий цикл проєкту
Життєвий цикл проєкту розробки інформаційної системи автоматизованої
видачі мастильних матеріалів на СТО складається з наступних фаз:
– Ініціалізація;
– Планування;
– Реалізація;
– Завершення.
Ключові фази проєкту, перелік їх характеристика основних робіт виглядають
наступним чином:
Ініціалізація:
– розробка та опрацювання загальної концепції та стратегії проєкту (розробка
стратегії, визначення чітких цілей, завдань, вимог, можливостей, обмежень,
очікуваних результатів проекту);
– розробка попереднього пакету основної документації по проєкту
(підготовка статуту проєкту; попереднє бачення організаційної структури команди;
погодження плану дій на початковий період);
– формування команди;
– розробка бізнес-плану;
– прийняття рішення про реалізацію проєкту.
Планування:
– коригування та затвердження попереднього пакету базової проєктної
документації;
– розробка та затвердження плану управління проектом (розробка
календарного плану; розробка плану виконання робіт (WBS); планування ресурсів);
30

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

– створені та узгоджені ТЗ та концептуальна схема продукту;
– виконані пакети робіт;
– розроблена, протестована програма.
Завершення:
– наказ про закриття проєкту;
– архівація проєкту;
– розпуск команди;
– закриті контракти.
Будемо тепер визначати детальний зміст фаз життєвого циклу проєкту, як
подано в табл. 2.3 – з тривалістю та ключовими віхами.
Таблиця 2.3 – Зміст фаз життєвого циклу проєкту
Фаза Ініціалізація Планування Реалізація Завершення
Тривалість 10 10 30 4
фази (дні)
Перелік – Формування – Планування – Розробка – Розміщення
основних команди змісту концепту програми на ПК
робіт – Формалізація – Планування – Розробка ТЗ користувачів
ідеї трудових ресурсів – Вибір технології – Розпуск
– Аналіз ринку – Планування – Проектування команди
– Розробка бюджету архітектури – Архівація
бізнес-плану – Планування програми проєкту
ризиків – Створення – Аналіз
– Планування структури програми проєкту
якості – Розробка дизайну
– Планування часу – Створення
– Планування прототипу
комунікацій – Тестування
– Планування – Реалізація
закупівель програми
Ключові Прийняте рішення Всі плани проєкту Готова система Проект закритий
віхи замовником затверджені автоматизованої
замовником видачі оливи
Можливі Ідея може Планування може Наявних ресурсів Продукт може
проблеми виявитися бути не дуже може не вистачити виявитися
недоцільною і якісним і точним для успішної недостатньо
неактуальною для через недостатню реалізації продукту якісним,
реалізації кваліфікацію проєкту функціональним
проєктного або
менеджера конкурентоспро
можним, чи
неактуальним

32

Отже, тривалість життєвого циклу всього проєкту становить 54 робочих дні або
2,5 місяці. Обмеження, яке встановили за часом виконання проекту – 3 місяці, тому
запланована тривалість проєкту відповідає встановленому обмеженню. Фаза
ініціалізації триває 10 робочих дні, як і фаза планування. Найдовша фаза – реалізація,
вона триває 30 робочих днів, найкоротша – завершення, тривалість якої становить 4
робочі дні.
Як було зазначено на початку розділу, ефективність проєкту оцінюватиметься
рівнем прибутку та залежністю механіка від комірника в процесі отримання паливо
мастильних матеріалів після реалізації продукту.
Висновки до розділу 2
В даному розділі було розроблено концепцію програми, а саме визначені цілі та
завдання проєкту, критерії успішності, обмеження та допущення. Провели аналіз
зацікавлених сторін, в результаті якого визначено механізм участі та цілі кожного з
учасників проєкту. Провівши аналіз усіх факторів, можна зробити висновок, що
зацікавлені сторони позитивно впливають на проєкт завдяки вигоді кожного. Тому
логічним завершенням розділу є обґрунтований стратегічний план, на основі якого
сформовано фази життєвого циклу та зроблений прогноз очікуваних результатів
кожної фази проєкту.

33

3 ПЛАНУВАННЯ ТА УПРАВЛІННЯ ПРОЄКТОМ
3.1 Планування змісту проєкту
Щоб почати планувати зміст проєкту, потрібно зробити визначення кінцевого
результату – продукту проєкту. В даному проєкті його продуктом є інформаційна
система автоматизованої видачі паливо мастильних матеріалів на станції технічного
обслуговування автомобілів.
Тепер можемо визначити високорівневі вимоги до кінцевого результату
майбутнього проєкту і представимо це в таблиці 3.1.
Таблиця 3.1 – Високорівневі вимоги до кінцевого результату проєкту
№ Назва вимоги
1 Можливість коригувати точність видачі мастильних матеріалів
2 Мінімізувати участь комірника в процесі отримання мастильних матеріалів
співробітниками підприємства
3 Встановлення обмеження кількості отриманих мастильних матеріалів за один
раз
4 Підвищити автономність контролерів видачі мастильних матеріалів
5 Можливість отримання мастильних матеріалів механіком по його робочій
авторизаційній картці

Для деталізації кінцевого результату проєкту була створена схема декомпозиції
(рис. 3.1).
Керуючи змістом проєкту, потрібно слідкувати за тим, щоб в його входили
лише ті роботи, які необхідні для успішної реалізації програми. Процес управління
змістом проєкту складається з наступного: планування змісту, визначення змісту,
побудова WBS, підтвердження змісту та управління змістом [29].
34

Рисунок 3.1 – Декомпозиція кінцевого результату проєкту
Основними роботами по проєкту що розробляється, є:
– розробка проєктної документації та узгодження проєкту;
– формування проєктної стратегії;
– написання ТЗ;
– створення концептуальної схеми продукту;
– розробка дизайну продукту;
– розробка основного функціоналу продукту;
– розробка контролерів видачі мастильних матеріалів;
– тестування інформаційної системи;
– підписання документації про передачу продукту замовнику;
– запуск та встановлення продукту на робочих комп’ютерах користувачів
підприємства.
Беручи до уваги наведений перелік, створено структуру декомпозиції робіт
(WBS) проєкту.
WBS визначає роботи, які необхідні для досягнення цілей проєкту. Також це
дає змогу з’ясувати терміни виконання ієрархічно взаємопов’язаних, орієнтованих на
35

результат елементів (пакетів робіт – комплексів робіт, згрупованих за заданими
критеріями).
Кожен наступний рівень декомпозиції забезпечує послідовну деталізацію
змісту проєкту, дозволяючи оцінити об’єм виконаних робіт, засвоєний бюджет і
виконання у відповідності до встановлених термінів.
Пакетам робіт нижчого рівня повинні відповідати менші за об’ємами роботи.
Це набагато спрощує оцінку виконання та дозволяє більш чітко визначити відсоток
дії для досягнення поставлених цілей проєкту.
Структура декомпозиції робіт має такі характеристики:
– описує зміст робіт в проєкті;
– визначає весь об’єм робіт проєкту;
– сформована у вигляді ієрархічної структури;
– має об’єктивний або вимірювальний результат, який розглядається як
результат роботи по пакету та сукупність результатів робіт.
При розробці WBS проєкту необхідно враховувати такі правила [21]:
– кожен елемент WBS повинен забезпечувати досягнення помітного
результату;
– кожен елемент WBS має бути набором усіх підпорядкованих елементів,
перерахованих безпосередньо під ним;
– декомпозиція результатів, від верхнього рівня до нижнього, повинна мати
логічний зв'язок;
– результати пакетів робіт мають бути унікальними і відрізнятися від
результатів пакетів робіт того самого рівня. Вони мають бути розбиті до рівня
деталізації, який забезпечує успішне планування, координацію та контроль робіт,
пов’язаних з досягненням поставлених цілей;
– процес розробки WBS повинен бути гнучким механізмом, який дозволяє
коригувати WBS, особливо враховуючи, що обсяг робіт проєкту може змінюватися.
Проте для успішного управління проєктом потрібен процес контролю змін, щоб
документувати зміни у змісті проєкту та керувати ними. Коли зміст проєкту
змінюється, WBS необхідно переглянути;
36

– кожен елемент WBS, який представляє обсяг робіт підрядника або інших
зовнішніх організацій, повинен бути узгоджений безпосередньо з відповідними
елементами WBS підрядника;
– усі пакети робіт повинні відповідати організаційній структурі та структурі
витрат;
– з WBS має бути виключене дублювання робіт.
WBS розробляється шляхом ітераційного розгляду цілей і результатів проєкту,
критеріїв планування, досягнення функціональності, обсягу робіт і реалізації
технічних вимог. Верхні рівні WBS можуть бути розроблені на початкових
концептуальних стадіях проєкту. Однак, після підготовки специфікацій та визначення
проєкту WBS може бути деталізована додатково, якщо це потрібно.
Розподіл робіт та їх структуру (WBS) можна розробляти «з нуля» або
використати компоненти вже створеної WBS з проєкту, в якому раніше приймали
участь. При розробці WBS проєкту початковим кроком є визначення кінцевого
результату проєкту – створення та впровадження інформаційної системи
автоматизованої видачі мастильних матеріалів на станції технічного обслуговування.
Наступним кроком має бути визначення основних робочих пакетів і
підпорядкованих їм завдань, які необхідні для отримання кінцевого результату
(продукту) проєкту.
Наступним кроком потрібно визначити тривалість робіт і зв’язки між ними. Не
потрібно забувати, що деякі роботи можуть виконуватися одночасно, а деякі тільки
після завершення попередніх. Кінцева WBS проєкту відображена в таблиці 3.2.
Таблиця 3.2 – WBS проєкту
№ 1-го № 2-го № 3-го Назва роботи Оцінка тривалості
рівня рівня рівня
1 Створення інформаційної системі 54 днів
автоматизації видачі мастильних
матеріалів на СТО
1.1 Ініціація 10 днів
1.1.1 Формування команди 1 день
37

1.1.2 Формалізація ідеї 3 дні
1.1.3 Аналіз ринку 2 дні
1.1.4 Розробка бізнес-плану 3 дні
1.1.5 Прийняте рішення замовником 0 днів
1.2 Планування 10 днів
1.2.1 Планування якості 2 дні
1.2.2 Планування змісту 2 дні
1.2.3 Планування трудових ресурсів 1 день
1.2.4 Планування бюджету 1 день
1.2.5 Планування часу 1 день
1.2.6 Планування ризиків 1 день
1.2.7 Планування комунікацій 1 день
1.2.8 Планування закупівель 1 день
1.2.9 Всі плани проекту затверджені 0 днів
замовником
1.3 Реалізація 30 днів
1.3.1 Розобка концепту 3 днів
1.3.2 Розробка ТЗ 2 днів
1.3.3 Вибір технології 1 день
1.3.4 Проектування архітектури 4 дні
програми
1.3.5 Створення структури програми 2 дні
1.3.6 Розробка дизайну 1 день
1.3.7 Створення прототипу 10 днів
1.3.8 Тестування 5 днів
1.3.9 Реалізація програми 2 дні
1.3.10 Готова інформаційна система 0 днів
автоматизації процесу
1.4 Завершення 4 дні
1.4.1 Розміщення програми на ПК 1 день
користувачів
1.4.2 Розпуск команди 1 день
1.4.3 Архівація проєкту 1 день
1.4.4 Аналіз проєкту 1 день
1.4.5 Проєкт закритий 0 днів
38

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

Рисунок 3.2 – Сітьовий графік
3.2 Організаційна структура проєкту
Команда проєкту – це певна група людей, які разом працюють над досягненням
спільної мети, реалізацією проєкту та підпорядковані його керівнику (менеджеру)
[29].
Для побудови проєктної команди потрібно виконати основні організаційні
завдання: створити професійно-стимулююче оточення; забезпечити кваліфікованим
технічним персоналом; здійснювати грамотне керівництво; забезпечити підтримку
керівництва і стабільно сприятливого навколишнього середовища.
Учасники команди мають бачити себе частиною команди проєкту та виробити
спільні цінності та норми, перш ніж вони зможуть працювати разом як команда. Для
створення та розвитку команди можуть бути використані наступні шляхи:
39

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

Рисунок 3.3 – Організаційна структура проєкту
Команда проєкту складається з 4 осіб:
− менеджера проєкту,
− програміста,
− адміністратора системи
− схемотехніка.
Керівником даного проєкту є проєктний менеджер, якому підпорядковуються
всі інші учасники команди даного проєкту.
Розподіл відповідальності учасників проєкту по основним проектним роботам
представлено на основі організаційної структури виконавців проєкту та структури
декомпозиції робіт. Далі можемо сформувати матрицю відповідальності (табл. 3.2), в
якій визначаються ролі виконавців у різних фазах та ролях проєкту.
40

Таблиця 3.2 – Матриця відповідальності
Ресурси
1.1.1 Формування команди RP
1.1.2 Формалізація ідеї RP
1.1.3 Аналіз ринку RP
1.1.4 Розробка бізнес-плану RP
1.2.1 Планування якості RP
1.2.2 Планування змісту RP Р Р P
1.2.3 Планування трудових ресурсів RP
1.2.4 Планування бюджету RP
1.2.5 Планування часу RP
1.2.6 Планування ризиків RP
1.2.7 Планування комунікацій RP
1.2.8 Планування закупівель RP
1.3.1 Розробка концепту RP Р P P
1.3.2 Розробка ТЗ P Р RP
1.3.3 Вибір технології Р RP
1.3.4 Проектування архітектури Р RP
програми
1.3.5 Створення структури Р RP
програми
1.3.6 Розробка дизайну Р RP
Задачі
Менеджер
проєкту
Адміністратор
системи
Схемотехнік
Програміст
41

1.3.7 Створення прототипу P RP
1.3.8 Тестування RP Р
1.3.9 Реалізація програми P RP
1.4.1 Розміщення програми на ПК RP
користувачів
1.4.2 Розпуск команди RP
1.4.3 Архівація проєкту RP
1.4.4 Аналіз проєкту RP
R – Відповідальний P – Виконавець

3.3 Розробка календарного плану проєкту
З метою координації діяльності виконавців, які залучені до проєкту, та для
забезпечення його успішного завершення, користуємось загальною функцією
календарного планування, а саме – визначення та фіксування дат виконання всіх
робіт.
До основних цілей календарного планування входить:
– фінансування та забезпечення його своєчасного надходження;
– забезпечення контролю над ходом виконання проєкту;
– ступінь коригування, завантаженості ресурсів та їх своєчасне забезпечення;
– забезпечення своєчасного виконання проєкту.
Розробка календарного плану проєкту завжди носить ітеративний характер,
оскільки в ході роботи необхідно неодноразово повертатися до попередніх етапів,
щоб уточнити і наблизити їх до реальності, або поступово наблизити попередні
варіанти до найкращих досяжних значень [16].
Створений на даному етапі календарний план проєкту є першим наближенням
прогнозу до його реалізації. Під час реалізації проєкту та в його процесі цей прогноз
уточнюється з урахуванням планових і фактичних показників ефективності проєкту
42

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

43

Рисунок 3.4 – Вікно проєкту з введеним переліком робіт
44

Рисунок 3.5 – Вікно проєкту з визначеною тривалістю робіт
Одним з останніх кроків у плануванні робіт проєкту потрібно встановити
взаємозв’язки між роботами. Це пояснюється тим, що лише врахувавши
послідовність робіт, система може розрахувати часовий графік проєкту та
представити його на діаграмі.
Для зв'язування між роботами використовують два основні інструменти:
вказування попередника (роботу зв'язують з попередником, проставляючи у стовпці
45

Predecessor номер рядку роботи попередника), або встановлення такого зв'язку
безпосередньо на часовій діаграмі з використанням піктограми зв'язування.
При заповненні календарного плану проєкту в роботі використали інструмент
вказування попередника роботи.
Існує чотири типи зв’язків між роботами: старт до старту, фініш до фінішу,
фініш до старту та старт до фінішу (Start to Start (SS), Finish to Finish (FF), Finish to
Start (FS), Start to Finish (SF)) [32]. По замовчуванню зв’язок між роботами проєкту є
зв'язком фініш до старту, тобто, послідовним.
При встановленні зв'язку між роботами необхідно враховувати часові межі
роботи, які можуть бути наступних типів [19]:
– As Late As Possible (ALAP) – так пізно, як це можливо;
– As Soon As Possible (ASAP) – так швидко, як це можливо;
– Finish No Earlier Than (FNET) – фініш не раніше, ніж;
– Finish No Later Than (FNLT) – фініш не пізніше, ніж;
– Must Finish On (MFO) – фініш на визначену дату;
– Must Start On (MSO) – старт визначеної дати;
– Start No Earlier Than (SNET) – старт не раніше, ніж;
– Start No Later Than (SNLT) – старт не пізніше, ніж.
Також потрібно врахувати конкретні дати для часових обмежень. Для кожного
типу обмеження, суть і призначення якого стає зрозумілим після введення
послідовності виконання робіт, логічно ввести лише кілька часових параметрів. Так,
наприклад, для використання обмежень типу MFO логічно визначити дату
завершення та тривалість. У цьому випадку дата початку розраховується
автоматично.
Перед початком визначення зв'язків між роботами проєкту було використано
обмеження типу ASAP для всіх робіт, які пізніше були скориговані для окремих робіт.
Після встановлення зв’язків робіт календарний план проєкту набув наступний
вигляд (рис. 3.6):
46

Рисунок 3.6 – Вікно проєкту з вказаними зв’язками між роботами
3.4 Планування трудових та матеріальних ресурсів проєкту
Для продовження планування проєкту, потрібно вказати ресурси, які плануємо
використати для виконання кожної з робіт, тобто – призначити ресурс до роботи
проєкту.
47

Під словом ресурси в проєкті розуміють обладнання, матеріали, робочу силу та
гроші, які необхідні для виконання сформованих робіт, і є головними передумовами
під час реалізації будь-якого проєкту.
Одним з важливих питань завжди є правильне складання та оцінка потреб у
ресурсах, умовах їх надходження та забезпечення повного та ефективного
подальшого використання.
Для початку планування ресурсів потрібно визначитись, що є ресурсами в
даному проєкті, тобто скласти перелік учасників і обладнання, які знадобляться для
виконання проєктних робіт.
Це можна зробити двома способами:
– призначивши ресурси для кожної роботи, таким чином формуючи їх
перелік;
– скласти перелік ресурсів, а потім за допомогою нього призначати ресурси
до робіт.
Оскільки відомі всі ресурси проєкту, простіше використати другий спосіб з
наведених вище.
Використовуючи меню View, Resource Sheet, на екрані з'явиться таблиця
ресурсів усіма доступними характеристиками, а саме:
– Resource Name – назва ресурсу;
– Type – тип (працівник, матеріал);
– Material Label – позначення матеріалу;
– Initials – абревіатура працівника;
– Group – група;
– Max. Units – максимальна "задіяність";
– Std. Rate – звичайний тариф оплати (протягом робочого часу);
– Ovt. Rate – тариф оплати за роботу в неробочий час;
– Cost/Use – одноразові витрати;
– Accrue At – форма оплати (аванс, погодинно, по факту);
– Base Calendar – базовий календар ресурсу;
– Code – код ресурсу.
48

Якщо ресурс повністю використовується для виконання робіт у проєкті, у
комірці Units необхідно поставити значення (100%), якщо ресурс використовується
частково – вказується відсоток його використання в проєкті.
Результати заповнення таблиці ресурсів даними наведено на рисунку 3.7:

Рисунок 3.7 – Заповнена таблиця ресурсів проєкту
Виконаємо призначення ресурсів до робіт проєкту
Після того, як визначили ресурси проєкту, можна розпочати призначення
ресурсів до робіт. Для цього потрібно навести курсор на клітинку з назвою роботи і
двічі клікнути лівою кнопкою мишки. На екрані з’явиться діалогове вікно Task
Information. В ньому потрібно зайти у вкладку Resource.
В цьому вікні є таблиця, яка дозволяє вибрати з переліку кілька доступних
ресурсів, які необхідні для виконання цієї роботи (рис. 3.8).

Рисунок 3.8 – Перелік доступних ресурсів проєкту для призначення

Також можна призначати ресурси, клікнувши лівою кнопкою мишки на
клітинку поруч із датою закінчення роботи – стовбець Resource names (рис. 3.9).
49

Рисунок 3.9 – Присвоєння ресурсу до роботи
Після встановлення ресурсів біля робіт, їх назви відображаються на діаграмі
поруч з лініями робіт (рис. 3.10):

Рисунок 3.10 – Відображення призначених роботам ресурсів на часовій
діаграмі

50

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

Рисунок 3.11 – Маркування перевантажених ресурсів
Після цього потрібно скористатися меню View, Resource Graph. У вікні, що
відкриється, відображається графік перевантаження ресурсів (рис. 3.12, 3.13). В лівій
частині вікна знаходиться назва ресурсу і шкала, а в правій – часова діаграма
завантаження.

Рисунок 3.12 – Графік перевантаження ресурсу «Менеджер проєкту»
51

Рисунок 3.13 – Графік перевантаження ресурсу «Програміст»
Тепер визначено, що у проєкті перевантаженими виявились програміст та
менеджер проєкту (рис. 3.11). Перевантаження означає, що ресурсу потрібно буде
більше часу, ніж він має для виконання робіт, які були йому призначені.
Причин такого перевантаження може бути кілька:
– одна з найбільш розповсюджених причин є призначення ресурсу до робіт,
виконання яких частково або повністю виконуються в один і той же час;
– іншим варіантом може бути збільшення обсягу робочих завдань, що
призводить до перевищення допустимого часу на їх виконання та перевантаження
ресурсу.
В разі присутності конфліктів ресурсів необхідно застосувати методи
«згладжування» або «калібрування».
Застосувавши метод «калібрування» явне навантаження ресурсу розподілиться
рівномірно протягом усього терміну виконання, що призведе до зниження пікового
навантаження та дотримання термінів виконання робіт, проте при використанні
даного методу ресурси змушені працювати понаднормово, як наслідок будемо мати
перевитрати бюджету проєкту.
При застосуванні іншого методу – «згладжування» рівень задіяних ресурсів
зводиться до номінальних 100%, але при цьому змінюються терміни виконання робіт.
Для того щоб збалансувати перевантаження ресурсів, можна використовувати
один або кілька методів:
52

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

Рисунок 3.14 – Тривалість виконання проєкту до згладжування ресурсів
У проєкті застосували один з методів - «згладжування» (рис. 3.15, 3.16):

Рисунок 3.15 – Графік завантаженості ресурсу «Менеджер проєкту» до
застосування «згладжування»
53

Рисунок 3.16 – Графік завантаженості ресурсу «Менеджер проєкту» після
застосування «згладжування»
Виконавши даний етап слід зазначити, що після згладжування завантаженості
менеджера проєкту, строк виконання проєкту збільшився (рис. 3.17).

Рисунок 3.17 – Строк виконання проєкту після згладжування ресурсів
Оскільки у проєкті перевантаженим виявився також ресурс «Програміст»,
виконаємо вирівнювання і для цього ресурсу (рис 3.18, 3.19):

Рисунок 3.18 – Ресурс «Програміст» до застосування «згладжування» ресурсів
54

Рисунок 3.19 – Ресурс «Програміст» після застосування «згладжування»
ресурсів
Як бачимо, перевантаження ресурсів програміста усунуте, а час виконання
проекту збільшився до 53 днів.
Після застосування згладжування конфліктів ресурсів лист ресурсів виглядає
наступним чином (рис. 3.20):

Рисунок 3.20 – Лист ресурсів із вирішеними конфліктами ресурсів
Після отримання остаточної діаграми Ганта, слід зазначити, що тривалість
проєкту збільшилась на 3 дні, в порівнянні з тривалістю до згладжування ресурсів.
Остаточний план проєкту зображено на рисунку 3.21.

55

Рисунок 3.21 – Остаточний план проєкту
Тепер можна переглянути критичний шлях проєкту (рис. 3.22) та побачити, які
роботи є критичними, і їх затримка призведе до затримки виконання всього проєкту.

Рисунок 3.22 – Критичний шлях проєкту
56

3.5 Планування якості проєкту
У проєкті використовуємо таку концепцію формування якості:
– формування корпоративних рекомендацій з якості (на основі стандартів
серії ISO 9001), що визначають основні методи забезпечення якості та структуру
документів системи забезпечення якості;
– як складову частину в системі управління якістю використали технології
управління проектами;
– виконання усіх робіт в проєкті з урахуванням попередньо узгоджених і
затверджених рекомендацій з якості;
– забезпечення підвищення кваліфікації членів команди;
– використання обладнання з сертифікатами, ліцензійне програмне
забезпечення;
– контроль якості на всіх етапах проєкту;
– всі виконавці в проєкті несуть відповідальність за якість виконаних їми
процесів.
Визначимо заходи, які забезпечать досягнення якості в кожній з фаз проєкту:
– Фаза ініціалізації.
Виконати комплексний аналіз ринку та визначити об’єктивні потреби та
очікування потенційних клієнтів, техніко-економічного обґрунтування та повноту
статуту проєкта.
– Фаза планування.
Повнота та якість створених основних нормативних інструкцій та документів,
проєктних структур, оцінки ризиків тощо. Створення процедур та рекомендацій
відносно налагодження ефективних комунікацій проєкту та командоутворення.
– Фаза реалізації.
Вимога щодо відповідності результатів робіт вимогам корпоративної настанови
з якості (ISO 9001), та загальновизнаним стандартам якості. Забезпечити проведення
високоякісного технічного тестування продукту проєкту для максимального
57

виявлення недоліків і помилок до завершення етапу впровадження. Також провести
користувацьке тестування.
– Фаза завершення.
Скласти звіти про результати проєкту. Якість та повнота архіву проєкту.
Виконати оцінку фактичного бюджету, фактичних термінів виконання проєкту та
якості продукту проєкту.
Ключові показники якості наведені у таблиці 3.3.
Таблиця 3.3 – Показники якості
Показники Цільове Допустиме Опис Відповіда- Контро- Робота або
значення значення показників льні за люючий фаза проєкту
якості якість
Підтримка Мульти- Версії Програміст Менеджер Фаза
операційних платфор- Windows 7 операційних проєкту планування,
систем менність та вище систем на Фаза
яких має реалізації
працювати
додаток
Час До 1-ої До 5-ти Час за який Програміст Менеджер Фаза
встановленн хвилини хвилин має бути проєкту планування,
я програми встановлена Фаза
та реалізації
налаштована
програма
Час Виконан- Допустиме Виконання Менеджер Замовник На всіх
виконання ня в відхилення робіт в термін проєкту фазах
поставлених термін не більше впливає на
задач 1го тижня бюджет
зазначено- проєкту
го терміну
Точність Похибка Похибка не Точність Схемотех- Менеджер Фаза
видачі відсутня більше 10 отримання нік проєкту реалізації
мастильних мл мастильних адміністра-
матеріалів матеріалів тор
системи
Надійність 100% 100% Відповідність Програміст Менеджер На фазі
виконаних кінцевих та проєкту реалізації
робіт результатів адміністра-
поставленим тор
58

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

3.6 Управління ризиками
Метою управління ризиками є зниження ймовірності настання ризикових подій,
що негативно впливають на процес реалізації проекту, та підвищення ймовірності
настання подій, що позитивно впливають на процес реалізації проекту [24]. Процес
загального управління ризиками наведено на рисунку 3.23.

Планування
Ідентифікація Якісний Кількісний Планування Моніторинг та
управління
ризиків аналіз ризиків аналіз ризиків реагування контроль
ризикам

Рисунок 3.23 – Схема процесу управління ризиками
У проєкті, що розробляється, застосовуються наступні процеси управління
ризиками:
– процес визначення підходів та планування операцій по управлінню
ризиками проєкту – планування управління ризиками;
– ітеративний процес, який передбачає визначення та документування
характеристик ризиків, які можуть вплинути на проєкт – ідентифікація ризиків;
– якісний аналіз ризиків включає встановлення пріоритетів ризиків,
результати якого використовуються пізніше (у процесі кількісного аналізу ризиків
або при плануванні реагування на ризики);
– кількісний аналіз ризиків проводиться щодо тих ризиків, які визначені в
процесі якісного аналізу як ті, що потенційно або суттєво впливають на
59

конкурентоспроможну якість продукту. У процесі кількісного аналізу ризиків
оцінюється вплив ризикових подій і присвоюється числова оцінка;
– реагування планування на ризики – процес розробки шляхів та визначення
дій для збільшення можливостей і зменшення загроз для цілей проєкту;
– моніторинг та управління ризиками – процес виявлення, аналізу та
планування повторних ризиків, відстеження виявлених і перерахованих ризиків для
постійного моніторингу, перегляду та впровадження заходів реагування на ризики та
оцінки їх ефективності.
Для оцінювання впливу ризикових подій на процес реалізації проєкту, було
використано наступну шкалу:
– «0» – ризик не має ніякого впливу;
– «0.05» – ризик має мінімальний вплив;
– «0.1» – ризик має невеликий вплив;
– «0.2» – ризик має помірний вплив;
– «0.4» – ризик має великий вплив;
– «0.8» – ризик має надмірно великий вплив.
Тепер розподілимо ймовірність настання ризикової події на такі діапазони (від
0 до 1, де 0 – подія неможлива, 1 – подія що точно відбудеться):
– 0.0 - 0.2 – дуже низька;
– 0.2 - 0.4 – низька;
– 0.4 - 0.6 – середня;
– 0.6 - 0.8 – велика;
– 0.8 - 1.0 – дуже велика.
Сформуємо таблицю ризиків проєкту (табл. 3.4), яка містить наступні дані:
Таблиця 3.4 – Ризики проєкту
Вид Ризикова подія Умова виникнення Наслідки
Управлінський Помилки у людський фактор зрив календарного плану, додаткові
плануванні витрати на позапланові ресурси
60

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

Визначимо ймовірність настання того чи іншого ризику та його вплив на проєкт
(табл. 3.5):

61

Таблиця 3.5 – Ймовірність настання ризиків
№ Назва ризику Ймовірність Вплив на
виникнення проект
1 Технічні ризики 0,2 0,8
2 Фінансові ризики 0,2 0,8
3 Ризики персоналу 0,4 0,4
4 Маркетингові ризики 0,1 0,2
5 Управлінські ризики 0,3 0,6
6 Форс-мажорні ризики 0,5 0,8
7 Ринкові ризики 0,1 0,4

Для комплексної оцінки можливих наслідків впливу ризикової події на проєкт
сформуємо матрицю аналізу ризиків (табл. 3.6).
Таблиця 3.6 – Аналіз ризиків
Ймовірність
0.8 – 1.0
0.6 – 0.8
0.4 – 0.6 3 6
0.2 – 0.4 2, 5
0.0 – 0.2 4 7 1
0.05 0.1 0.2 0.4 0.8
Вплив

Згідно таблиці 3.6 було виявлені найбільш впливові ризикові події (2, 3, 5, 6).
Визначивши, які ризики матимуть найбільший вплив на проєкт, було
розроблено план по попередженню або усуненню ризиків проєкту (табл. 3.7).
62

Таблиця 3.7 – Управління ризиками
№ Назва ризику Попередження ризику Усунення ризику
Дії Відповідаль Дії Відповідаль
ний ний
2 Фінансовий ризик – резервування Менеджер – перепланування Менеджер
бюджету проєкту бюджету проєкту
– дослідити – кредитування
можливості проекту
кредитування – пошук
додаткових джерел
фінансування
3 Ризик персоналу – стимулювання Менеджер – навчання Менеджер
та заохочення проєкту персоналу проєкту
учасників проєкту – пошук нових
– проведення учасників
досконалого та – підвищення
детального відбору кваліфікації
команди проєкту

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

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

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

Зазвичай, комунікація учасників проєкту і потреба в їй виходить за рамки
чотирьох описаних і перерахованих пунктів. Проте слід розглядати лише «необхідні
та достатні» для успіху проєкту, в рамках управління комунікаціями. Надлишок або
недостатньо інформації може мати негативний вплив на процес виконання проєкту.
При плануванні комунікацій, які необхідні учасникам проєкту, визначається їх
взаємодії та інформація. Для прикладу, яка кому інформація потрібна, хто і коли
повинен її надати і як. Методи розповсюдження інформації та інформаційні потреби
можуть відрізнятись, проте всі проєкти потребують передачі інформації. Одним з
важливих факторів успіху проєкту є визначення інформаційних потреб та методів їх
задоволення для учасників проєкту.
Для проєкту було створено такий комунікаційний план (табл. 3.8):
Таблиця 3.8 – Комунікаційний план
№ Вид комунікації Регулярність Хто відправляє Хто отримує
комунікації інформацію інформацію
1 Звіт по завданнях 1 раз на тиждень (кожен Виконавець Той, хто контролює
тижневий понеділок)
2 Звіт по завданнях 1 раз на місяць Виконавець Той, хто контролює
місячний (останній день місяця)
3 Місячний звіт по 1 раз на місяць Менеджер проєкту Замовник
проєкту (останній день місяця)
4 Нарада щотижня 1 раз на тиждень (кожна Виконавець Менеджер проєкту
середа)
5 Усна комунікація Кожні 3 дні Будь-хто з команди Будь-хто з команди
6 Підсумковий звіт з При завершенні проєкту Менеджер проєкту Замовник
всього проєкту

3.8 Моделювання виконання проєкту
Виконання робіт над проєктом розпочали із використання програмного
забезпечення MS Project. Змогли отримати можливість відстежувати прогрес проєкту
та його освоєний об’єм. Маючи змогу порівнювати поточний прогрес з початковим
планом, можемо визначати відхилення за часом та вартістю у проєкті.
65

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

Рисунок 3.24 – Відхилення по проєкту
Як бачимо з рисунку (рис. 3.24), що відбулась затримка у проєкті на етапах
планування і реалізації. Затримка на етапі планування вийшла відносно не великою
(5 днів), а пов’язано це через велике навантаження на менеджера проєкту. Адже вся
фаза планування залежить саме від його. Затримка в етапі реалізації вийшла меншою
і склала три дні. Затримки відбулися в процесах розробки концепту та вибір
технології. Можливою причиною даної ситуації став невисокий рівень кваліфікації
менеджера проєкту, котрий не зміг точно розрахувати час, який знадобиться для
реалізації цих завдань на етапі планування проєкту. Практика показала, що потрібно
трохи більше часу на реалізацію, ніж запланували. Найбільше проблем виявилося з
реєстрацією ФОП (12 днів замість 6) та проєктуванням архітектури мобільного
додатку (14 днів замість 8). При реєстрації ФОП на затримку вплинули зовнішні
фактори, а затримка з проєктуванням архітектури додатку повністю залежала від
66

програмістів – додаток виявився складнішим у реалізації, ніж було розраховано.
Загальна затримка по задачам склала 19 днів. Бюджет проєкту через затримку
збільшився на 23 040 грн.
Оцінити часову складову відхилення можна за допомогою звіту робочого часу,
що наведено на рисунку 3.25.

Рисунок 3.25 – Часова складова відхилення проєкту
Оцінити вартісну складову відхилення можна за допомогою звіту засвоєного
об’єму, що наведено на рисунку 3.26.
67

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

Але це накладало багато додаткових ризиків, а також не раціонально витрачати
зайві 20 000 грн. заради незначного збереження часу. Тому, було вирішено збільшити
строк виконання проєкту, але уникнути ризиків та зайвих витрат.
Відстеження стану виконання проєкту шляхом порівняння планових показників
і фактичних (термінів і витрат) зручно проводити з використанням методу освоєного
об’єму. Для побудови графіку звіту освоєного об’єму в MS Project використовуємо
стандартній шаблон. Звіт, створений на основі шаблону, показано на рисунку 3.27.

Рисунок 3.27 – Звіт освоєного об’єму проєкту
З графіку видно, що лінія запланованого об’єму знаходиться нижче фактичної
кількості роботи, що свідчить про затримку у виконанні задач на дату формування
звіту та перевищенні грошових затрат по задачах проєкту в порівнянні з
запланованими.
3.9 Проведення розрахунку бюджетної вартості
Бюджетна вартість робіт розраховується виходячи з вартості використання
ресурсу за одиницю часу (у нашому випадку – годину) та тривалості роботи в
годинах. Вартість робіт формується автоматично, після того, як роботам присвоєні
ресурси та для ресурсів вказано вартість використання. Для перегляду бюджетної
69

вартості робіт на таблиці до діаграми Ганта необхідно додати стовпчик «Expences»
(рис. 3.28):

Рисунок 3.28 – Бюджетна вартість робіт проєкту
Крім того, MS Project має велику кількість шаблонів і вбудованих звітів про хід
виконання проєкту (рис. 3.29), які також дуже корисні для менеджера проєкту на етапі
моніторингу:
70

Рисунок 3.29 – Види наглядних звітів
Графік бюджетної вартості може бути побудований за допомогою вбудованих
звітів (див. рис. 3.29). Таким чином, одразу отримуємо місячну бюджетну вартість
проєкту зі зростаючим підсумком (рис. 3.30):

Рисунок 3.30 – Бюджетна вартість проєкту щомісячно та зростаючим
підсумком
Після того, як починається виконання робіт проєкту, маємо можливість
відслідковувати засвоєний об’єм бюджету.
Щоб переглянути загальні освоєні об’єми на рівні проєкту та завдань, що
містяться у таблицях, в меню «Вид» необхідно обрати пункт «Інші представлення».
У списку «Представлення» обираємо «Лист завдань» і натискаємо «Застосувати». В
меню «Вид» обираємо пункт «Таблиця», потім натискаємо «Інші таблиці». У списку
71

«Таблиці» обираємо «Освоєний об’єм», «Показники витрат» або «Показники
календарного плану, а потім натискаємо «Застосувати».
Приклад такого звіту на момент виконання проєкту на рівні 71% зображено на
рис. 3.31.

Рисунок 3.31 – Звіт по виконанню 71% проєкту (засвоєний об’єм бюджету)
Висновки до розділу 3
Даний розділ складається з розробки компонентів управління проєктом та
структурного планування. Він є суттю роботи проєкту, оскільки складається з таких
елементів як ієрархічна структура робіт в проєкті, організаційна структура проєкту,
72

календарний план проєкту, матриця відповідальності і тому подібне. З метою
запобігання ризиків витрат фінансів та перевантаженню персоналу, увага була
приділена плануванню ресурсів та управлінню комунікаціями, якістю, ризиками. Як
результат проведених робіт став реалізований календарний план проектних робіт, з
призначеними ресурсами для кожної задачі. Провели визначення бюджетної вартості
робіт та їх тривалість. Для реалізації проекту за планом потрібно 155 робочих днів,
або 7 місяців, та 246 760 грн.
За допомогою комп’ютерної програми провели моделювання управлінням
проєкту з відхиленням строку проєкту. Виконання проєкту сягає 71% і перебуває на
етапі реалізації прототипу інформаційної системи. ІС містить в собі запланований
нами функціонал та попередній варіант дизайну. По завданням загалом затримка
склала 9 днів і загальний час виконання проєкту також збільшився. Бюджет проекту
через затримку збільшився на 23 040 грн і тепер складає 269 800 грн. Відхилення по
часу та бюджету не є критичними, тому що не перевищують заплановані допущення
проекту.

73

4 МОДЕЛЮВАННЯ ВИКОНАННЯ ПРОЄКТУ ТА ЙОГО РЕЗУЛЬТАТИ
4.1 Моделювання продукту проєкту
Важливим кроком на початку розробки будь-якої інформаційної системи, який
допоможе створити якісний продукт, є її моделювання. Процес моделювання
допомагає з визначенням платформ, з якими буде працювати майбутній продукт,
вимогами до інтерфейсу та дізнатись, які інструменти знадобляться для його
розробки, щоб в подальшому досягти запланованих результатів.
Розроблювана інформаційна система розділена на такі модулі: узгодження
вимог та аналіз предметної області, розробка інтерфейсу користувача (комірник) та
розробка інтерфейсу користувача (механік), розробка контролера видачі мастильних
матеріалів.
Для кращого розуміння функціональності цієї системи, потрібно визначити, як
користувачі будуть використовувати кінцевий продукт проєкту. Варіанти
використання додатку допомагають представити наступне:
– взаємодія користувача з програмою;
– важливість кожного окремого процесу в проєкті і його роль;
– загальний обсяг створення проєкту.
Для розуміння потреб майбутніх користувачів потрібно для початку виділити
основні функціональні розділи, мова йде про:
– авторизація в програмі;
– створення запитів на отримання оливи;
– створення та редагування кранів видачі.
Наступним кроком маємо визначити основні дії, які користувач буде
виконувати в кожному з розділів. Після цього можемо визначитись, які функції
необхідно розробити для задоволення очікувань користувачів. Сформулювавши
основні функції, можемо визначитись з додатковими. Хоч вони і не є критично
важливими в роботі програми для виконання основних дій користувачами, але ці
74

функції покращать комфорт використання та її привабливість для них. Основні та
додаткові функції по розділах зображено на рисунках 4.1 і 4.2.

Рисунок 4.1 – Функції розділів «Авторизація в програмі» та «Створення
запитів на отримання оливи»

Рисунок 4.2 – Функції розділу «Створення та редагування кранів видачі»

75

4.2 Опис процесу практичної реалізації проєкту
Готовність проєкту досягла 71% і перебуває на етапі створення прототипу
інформаційної системи. Попередній варіант дизайну і весь запланований функціонал
вже має наш прототип. Розгляньмо результат проєкту і його виконання більш
детально.
Реалізація проєкту складалась з кількох етапів. Створення контролера видачі
оливи виконувалась поступово.
Першим кроком було визначення методу отримання оливи. Було взято
імпульсний лічильник і насос, який працював завдяки повітрю в системі та качав
оливу лише тоді, коли йшло повітря. Для рахування імпульсів з лічильника
використали плату Arduino. Arduino (Ардуіно) – апаратна обчислювальна платформа
для аматорського конструювання, основними компонентами якої є плата
мікроконтролера з елементами вводу/виводу та середовище розробки
Processing/Wiring на мові програмування, що є спрощеною підмножиною C/C++.
Arduino може використовуватися як для створення автономних інтерактивних
об'єктів, так і підключатися до програмного забезпечення, яке виконується на
комп'ютері (наприклад: Processing, Adobe Flash, Max/MSP, Pure Data, SuperCollider).
Інформація про плату (малюнок друкованої плати, специфікації елементів, програмне
забезпечення) знаходяться у відкритому доступі і можуть бути використані тими, хто
воліє створювати плати власноруч [51].
Після того, як змогли рахувати імпульси з лічильника, наступним кроком
потрібно вирахувати кількість грам оливи за імпульс. Також потрібно встановити
електро-магнітні клапани, які з одного боку (біля насоса) відкриватиме повітря, а з
іншого боку (місце отримання оливи) буде відкривати кран з якого тектиме олива. На
перший погляд може здатись, що достатньо буде і одного клапану, який буде
відкривати повітря, проте це не так. Два клапани забезпечують герметичність
системи, а саме – насос\кран. Для керування клапанами встановлено реле, яке ними
керує. На даному етапі наш контролер складається з:

76

– плата Arduino;
– імпульсний лічильник;
– два електромагнітних клапани;
– реле керування
– блок живлення.
На рисунку 4.3 представлено прототип контролера видачі оливи.

Рисунок 4.3 – Прототип контролера видачі оливи.
Послідовність його роботи така – на плату подається інформація з потрібною
кількістю імпульсів. Плата подає сигнал на реле для відкривання електромагнітних
клапанів. Після того, як насос почав качати масло, наш лічильник розпочав рахувати
імпульси до вказаної кількості, коли є потрібна кількість подається повторний сигнал,
який закриває клапани. Для доступу до контролера ззовні налаштували йому статичну
ІР-адресу по якій йому можна було б подавати команди.
Наступним кроком потрібно було розробити інтерфейс користувача комірника
та механіка. Програма, якою користуються на підприємстві, написана на базі
платформи «1С:Роздріб». Тому для створення інтерфейсу також було обрану дану
систему. Інтерфейсів два тільки тому, що для досягнення однієї з цілей проєкту, а
саме пришвидшити отримання оливи механіком, потрібно мінімізувати дії, які він має
виконати.
77

Перше вікно запуску програми – це поле вікна авторизації, пройшовши яку
перед користувачем відкривалось головне вікно програми. Вікно авторизації
інтерфейсу користувачів представлено на рисунках 4.3 та 4.4.

Рисунок 4.3 – Вікно авторизації інтерфейсу механіка

Рисунок 4.4 – Вікно авторизації інтерфейсу комірника

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

Рисунок 4.5 – Головне меню програми комірника
В даному меню він має доступ для створення запиту на отримання оливи. Також
може натиснувши на видачу мастила, переглянути створені раніше запити, а також
побачити запити, які ще не видані. Додавати чи редагувати співробітників,
натиснувши на «Співробітники». Переглянути налаштування кранів можна
перейшовши до «Крани». В пункті «Приход мастила» він може оприбуткувати нову
бочку чи просто вказати кількість мастила, яке він додає.
Розглянемо більш детально можливості деяких меню. Головне меню, з яким він
працює, це звичайно «Запити на видачу» та «Створення запиту». На рисунку 4.6
відображено вікно запитів на видачу та на рисунку 4.7 – Форма створення запиту на
видачу.

Рисунок 4.6 – Вікно запиту на видачу
79

Рисунок 4.7 – Форма створення запиту на видачу
Розберемо поля та їх можливості. Номер і дата документа встановлюються
автоматично. В полі «співробітник» комірнику є можливість вибрати зі списку що
випадає механіка для якого буде створено даний запит. Для зручності в списку одразу
видно шість останніх отримувачів мастила. Якщо його немає в даному списку,
комірник тисне кнопку показати всіх і вже в загальному списку вибирає потрібного.
Поле «Товар» – це поле, в якому вказуємо тип мастила, яке будемо видавати. Це поле
реалізоване також списком, що випадає. Поле «Кількість» – потрібне для вказування
кількості отримуваного мастила в літрах. Поле «Документ на підставі» – це поле
необхідне для вказування документу на підставі якого видається мастило. Може бути
наряд замовлення якщо в ремзону або видаткова, якщо відбувся продаж працівником
відділу продажів запчастин. Кінцевим етапом створення запиту є натискання кнопки
«Провести і закрити». Після чого в програмі механіка з’являється можливість
отримання мастила. Також важливим меню для налаштування програми і контролю
кранів є «Крани». На рисунку 4.8 зображено вікно меню кранів.

Рисунок 4.8 – Вікно меню крани
В даному вікні видно доступні крани, тип мастила за який вони відповідають,
залишок та стан. Більш інформативним є вікно редагування та налаштування крану,
що зображене на рисунку 4.9.
80

Рисунок 4.9 – Вікно налаштування крану
В даному вікні можна виконати основні налаштування крану. Вказати назві та
тим мастила, яке буде видавати даний кран. Вказати ІР-адресу для зв’язку з
контролером видачі мастила. Вказати кількість імпульсів за літр і вказати за скільки
зупиняти видачу. Також важливим є можливість обмежувати максимальну кількість
отриманого мастила за одну видачу та пункт корегування, який відповідає за точність
кількості виданого мастила.
Головне меню механіка відрізняється від меню комірника. Головне меню
механіка, після проходження авторизації, зображено на рисунку 4.10.

Рисунок 4.10 – Головне меню програми механіка
Одразу варто зазначити, що програма авторизації механіка розміщена на
планшеті під управлінням ОС Windows 10 та має додатковий повноцінний порт USB
81

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

Рисунок 4.11 – Вікно детальної інформації та коригування кількості мастила
Розберемо більш детально поля і інформацію, яку ми бачимо. Самий перший
напис «5w30 Renault» – назва типу мастила, яке будемо отримувати. Кнопки, які
дають можливість редагувати кількість отримуваного мастила. Дана функція більш
актуальна, коли для отримання механіку мастила кількість перевищує п’ять літрів. В
середньому при тестуванні отримання оливи було визначено, що в ємності для
отримання оливи влазить біля 5.5 літрів. Отож, коли до отримання стоїть сім чи вісім
літрів, у механіка є можливість розбити видачу на зручну для себе кількість. Кнопка
«Видати» переводить на наступне вікно «Підтвердження видачі» рисунок 4.12. Дане
вікно несе виключно попереджувальний характер і створене для запобігання
випадкових натисків на екран, а також зайвий раз звернути увагу механіка чи він
поставив ємність для отримування під потрібний йому кран.
82

Рисунок 4.12 – Вікно підтвердження видачі
Натиснувши кнопку «Видати», механік розпочинає процес наливання оливи в
ємність. Після чого програма повертається на вікно авторизації та готова да наступної
видачі мастила.
4.3 Механізм контролю робіт проєкту
Базовим планом контролю проєкту є моніторинг та постійне спостереження за
ходом виконання робіт в йому, порівнювати поточний стан з базовим планом. Збір
інформації про стан та хід реалізації проєкту потрібно проводити систематично для
своєчасного виявлення несподіваних відхилень від очікуваного плану.
Моніторинг є невід’ємною частиною проєктної діяльності, ключовим
компонентом управління якістю та невід’ємною частиною повсякденної практики
управління. Для контролю ефективності проєкту використовуються коригувальні та
запобіжні дії [3].
Для моніторингу проєкту була розроблена система, яка містить в собі наступні
пункти:
– заходи попередження:
1) моніторинг запитів на внесення змін (щодня);
2) проведення нарад команди проєкту (щотижня);
3) проведення аудитів (по закінченні кожної фази проекту);
4) позачергове проведення зборів команди проєкту (за вимогою);
5) проведення презентації з представленням результатів фази зацікавленим
сторонам (по закінченні кожної фази проєкту).
83

– звітність постачань та витрат в проєкті:
1) витрати в проєкті на місяць (щомісяця);
2) звіт про використання коштів (щомісяця);
3) звіти та протоколи тестування (згідно календарного плану проєкту);
4) специфікації на постачання (відповідність до стандартів якості ISO
9001).
– система узгодження запитів на зміни у проєкті.
Запити на узгодження про внесення змін у проєкті відбувається в такому
порядку:
1) Надсилання пропозиції ініціатором щодо змін в проєкті в електронному
вигляді на електронну адресу керівника.
2) Керівник звіряється та перевіряє чи відповідають запропоновані зміни
кінцевим цілям проєкту.
3) Після чого керівник проєкту виносить зміни, запропоновані ініціатором, на
щотижневій нараді для їх обговорення або відмовляє в запропонованих змінах
пояснюючи причину відмови.
В запиті на зміну повинно бути детально описано необхідні зміни, вказати
підрозділи які приймуть участь, терміни виконання, необхідні додатки та список
узгодження. Після погодження із проєктним керівником, проте не пізніше ніж за два
дні до наради, учасники проєкту отримають електронний лист з описом ініціативи.
Члени команди, які відповідальні (залежно від напрямку зміни) визначають терміни
реалізації запропонованого. Вся команда, яка має отримати інформацію про запит
змін, додається до списку що переглядає його. Коли запит виконано, то на електронну
адресу кожного члена команди має автоматично надіслатись повідомлення. На
рисунку 4.13 наведено алгоритм внесення змін.
84

Замовник/Ініціатор
Заявка на внесення змін
Реєстрація заявки на внесення
змін
Аналіз запропонованих змін
Змістом змін є зміни проектної
Змістом пропонованих змін є зміни документації, змісту, об'єму та
умов Угоди строків виконання робіт, матеріалів
що використовуються та інше
Узгодження змін зі сторонами Узгодження змін зі сторонами
Угоди Угоди
Документальне оформлення змін
умов Угоди (оформлення та Оцінка змін
підписання)
Документальне оформлення змін
(оформлення технічного завдання,
додатків до Угоди, коригування
строків виконання та ін.)
Контроль над процесом
виконанням змін та оцінка
результатів

Рисунок 4.13 – Алгоритм внесення змін
На основі вимірюваних якісних і кількісних параметрів у форматі
План/Факт/Відхилення формуються всі показники в проєкті.
Система звітів по реалізації робіт проєкту:
– звіт про ключові проблеми проекту (щотижневий);
– звіт про виконання робіт (місячний);
– звіт про виконання робіт (щотижневий).
85

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

Рисунок 4.14 – Шаблон щотижневого звіту
Звіти є невід’ємною частиною контролю за ходом реалізації робіт, аналізу їх
виконання та встановлення завдань на наступний. Всі проєктні показники
створюються на основі вимірювання якісних і кількісних параметрів у форматі
План/Факт/Відхилення.
Висновки до розділу 4
Підбиваючи підсумки по даному розділу, можемо сказати, що моделювання
кінцевого продукту проєкту є одним з важливих кроків на початкових етапах при
створені інформаційної системи.
86

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

87

ВИСНОВКИ
Отже, у період коли існує фінансова, економічна та соціальна криза, викликана
воєнним станом, для більшості підприємств і їх працівників важливими є кожна
хвилина і гривня. Кожен хоче економити, а не витрачати. Саме для цього реалізовано
проєкт – створення інформаційної системи автоматизованої видачі мастильних
матеріалів на СТО. Він полегшує роботу працівникам підприємства, забезпечуючи
мінімальну участь комірника в процесі отримання механіком оливи. Також точна
видача мастильних матеріалів дає змогу підприємству економити кошти і вести
точний облік. Зекономлений час, який отримали завдяки автоматизації процесу,
позитивно вплинув на кількість часу, який проводить автомобіль на території ремзони
і тим самим економимо час клієнтів.
У кваліфікаційній роботі магістра розглянуті наступні питання:
1. Проаналізовано мету створення стартапу, визначено проблему, яку
необхідно вирішити. На основі проведених досліджень було сформовано декілька
ідей реалізації продукту проекту, що повинні розв’язати поставлену проблему та
обрано серед них найкращу. Для обраної ідеї додатку був детально описаний
необхідний функціонал. Проведено маркетингові дослідження, SWOT - аналіз, PEST
- аналіз та розроблено канву бізнес-моделі стартапу. Аналіз ринку мобільних додатків
показав, що ринку дуже мало подібних розробок і вони мають більше недоліків ніж
переваг – продукти конкурентів знаходяться у вищому ціновому сегменті та
пропонують менший функціонал. Це свідчить про те, що обрана ідея продукту
проєкту є конкурентоспроможною та перспективною.
2. Розроблено концепцію стартапу, а саме визначені цілі та завдання проєкту,
критерії успішності, обмеження та допущення. Проведено аналіз зацікавлених сторін,
в результаті якого визначено механізм участі та цілі кожного учасника проєкту.
Проаналізувавши усі фактори, можна зробити висновок, що зацікавлені сторони
позитивно впливають на проєкт, тому що кожен має свою вигоду. Логічним
завершенням розділу є обґрунтований стратегічний план, на основі якого сформовано
88

фази життєвого циклу та зроблений прогноз очікуваних результатів кожної фази
проекту.
3. Базується на таких елементах як організаційна структура проєкту,
ієрархічна структура робіт проєкту, матриця відповідальності, календарний план
проєкту та ін. Для уникнення ризиків фінансових втрат та перевантаження персоналу,
було приділено увагу плануванню ресурсів, управлінню якістю, ризиками,
комунікаціями. Результатом є готовий календарний план робіт проекту, з
назначеними ресурсами до кожної задачі, визначеною тривалістю та бюджетною
вартістю робіт. Для реалізації проєкту за планом потрібно 155 робочих днів, або 7
місяців, та 246 760 грн. Проведено комп’ютерне моделювання управління проєктом з
відхиленням по строкам проєкту. Реалізація проєкту досягла 71% і знаходиться на
етапі створення прототипу мобільного додатку. Прототип має весь запланований
функціонал та попередній варіант дизайну.
4. Моделювання продукту проєкту є важливим кроком на початкових етапах
розробки мобільних додатків. Визначено основні функції додатку, розробка яких має
відбуватися першочергово, та додаткові, що роблять продукт зручнішим та
привабливішим для користувачів. Створено дизайн основних розділів додатку –
головної сторінки, реєстрації користувача, особистого кабінету, карти супермаркетів
та замовлення доставки. Також було визначено механізм моніторингу та контролю
виконання робіт проєкту. Створено систему заходів контролю робіт, що забезпечить
успішну реалізацію проєкту.
Продукт проєкту має весь описаний в роботі функціонал: дозволяє
користувачам порівнювати ціни на одні й ті самі продукти в різних супермаркетах;
відображує найближчі супермаркети на карті; дає можливість замовити доставку
необхідних продуктів з певної торгової мережі. Розроблений додаток допоможе
користувачам легко економити свій час та гроші, що є дуже важливим в наш час.
Таким чином, у кваліфікаційній роботі магістра всі вимоги технічного завдання
виконані в повному обсязі. Мета роботи досягнута.
89

СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. Афанасьєв М. В. Управління проектами: навч.-метод. посіб. [Текст]
Харків : ІНЖЕК, 2007. 271 с.
2. Балабанова Л. В., Сардак О.В. Цінова політика торговельного
підприємства в умовах маркетингової орієнтації : навч. посібник. [Текст] Київ :
Професіонал, 2004. 156 с.
3. Буріменко Ю. І., Галан Л. В., Лебедєва І. Ю., Щуровська А. Ю.
Управління проектами : навч. посібник. [Текст] Одеса : ОНАЗ ім. О. С. Попова, 2017.
208 с.
4. Вассерман Н. Дилеми засновника бізнесу. Як попередити помилки й
уникнути їх під час створення стартапу. [Текст] Київ : Vivat, 2017. 480 c.
5. Ворона Т.В. Стартап на мільйон. Як українці заробляють статки на
технологіях. [Текст] Харків : Віват, 2017. 224 с.
6. Гавриш О. А., Бояринова К. О., Кравченко М. О. Управління стартапами
: підручник для для здобувачів вищої освіти за економічними спеціальностями. за заг.
ред. О. А. Гавриша. [Текст] Київ : КПІ ім. Ігоря Сікорського, Видавництво
«Політехніка», 2020. 716 с.
7. Гільбо К. Стартап на 100$. Як перетворити хобі на бізнес. [Текст] Київ :
Наш формат, 2017.
8. Гонтарева І. В. Управління проектами: підручник. Харків : ХНЕУ, 2011.
443 с.
9. Грицюк Ю.І. Управління ризиками реалізації програмних проєктів / за
ред. Ю. І. Грицюк, М. Р. Жабич. Київ : Науковий вісник НЛТУ України. Т. 28. № 1.
2018. С. 150–162.
10. Демиденко М.А. Д30 Управління проектами інформатизації за
методологією SCRUM : навч. посіб. [Текст] : Нац. гірн. ун-т. Д. : 2016. 80 с.
11. Длігач А.О. Маркетингова цінова політика: світовий досвід, вітчизняна
практика : навчальний посібник. Київ : ВД „Професіонал”, 2006. 304 с.
90

12. Довгань Л.Є., Мохонько Г.А., Малик І.П. Управління проєктами : навч.
посібник. [Текст] Київ : КПІ ім. Ігоря Сікорського, 2017. 420 с.
13. Дугіна С.І. Маркетингова цінова політика [Текст] : навч. посібник. К. :
КНЕУ, 2005. 393 с.
14. Ілляшенко С.М. Економічний ризик [Текст] : навч. посіб. Київ : Центр
навчальної літератури, 2004. 220 с.
15. Колянко О.В. Використання жорсткої "Waterfall" та гнучкої "Agile"
моделей управління проєктами / за ред. О.В. Колянко, Г.В. Озимок. Львів : Вісник
Львівського торговельно-економічного університету. Економічні науки. 2017. С.
177—182.
16. Крижановський Є.М. Моделювання бізнес-процесів та управління ІТ-
проєктами / Є.М. Крижановський, А.Р. Ящолт, С.О. Жуков, О.М. Козачко. Вінниця :
ВНТУ, 2018. 91 с.
17. Кучеров Д. П., Артамонов Є. Б. Інженерія програмного забезпечення:
навч. посібник. Київ : НАУ, 2017. 388 с.
18. О.М. Азарян, О.А. Виноградов, В.Руделіус. Маркетинг : підручник / за
ред. О.І. Сидоренко, П.С. Редько. [Текст] Київ : Навчально-методичний центр
«Консорціум із удосконалення менеджмент-освіти в Україні», 2005. 422 с.
19. Морозов В. В. Інформаційні системи і технології в управлінні проектами.
Ч.1 Планування проектів у MS Project [Текст] : навчальний посібник / Морозов В.В.,
Данченко О.Б., Шаров О.І. К. : Університет економіки та права "КРОК", 2011. 167 с.
20. Ноздріна Л., Ящук В., Полотай О. Управління проєктами. [Текст] Київ :
Центр навчальної літератури, 2020. 432 с.
21. Основи управління IT проектами [Текст]: навч. посіб. для студ.
спеціальності 122 «Комп’ютерні науки»/ КПІ ім. Ігоря Сікорського ; уклад.: В. О.
Кузьміних, Р. А. Тараненко. Київ : КПІ ім. Ігоря Сікорського, 2019. 75 с.
22. Остервальдер A., Піньє І. Побудова бізнес-моделей. Настільна книга
стратега і новатораю [Текст] Київ : Наш формат, 2018. 288 с.
23. Приймак В. М. Управління проектами [Текст]: навч. посібник. Київ : КНУ
ім.Тараса Шевченка, 2017. 459 с.
91

24. Проектний менеджмент: управління ризиками та змінами в процесах
прийняття управлінських рішень [Текст]: монографія / О. Б. Данченко, В. О. Занора.
Черкаси : ПП Чабаненко Ю.А., 2019. 278 с.
25. Райс Е. Стартап без помилок. Посібник зі створення успішного бізнесу з
нуля. Харків : Віват, 2018. 368 с.
26. Рішняк І.В. Моделювання процесу управління ризиками у
мультипроектному середовищі. [Текст] Львів : Вісник Національного університету
"Львівська політехніка" № 783: Інформаційні системи та мережі, 2014. С. 466-473.
27. Синґер С. Країна стартапів. Історія ізраїльського економічного дива.
[Текст] Kиїв : Yakaboo Publishing, 2016.
28. Сметанюк О. А., Бондарчук А. В. Особливості системи управління
проєктами в it-компаніях. [Текст] Київ : Агросвіт, 2020. С. 105–111.
29. Стандарт з управління проєктами та Настанова до зводу знань з
управління проєктами (Настанова PMBOK). Сьоме видання : Project Management
Institute, Inc, 2021. 274 c.
30. Тарасюк Г.М. Управління проектами [Текст]: навч. посібник. Київ :
Каравела, 2019. 320 с.
31. Управління IT-проектами. Книга 1. Стандарти, моделі та методи
управління проектами : підручник. Львів : «Новий Світ-2000», 2013. 550 с.
32. Управління ІТ-проектами в Microsoft Project: Комп’ютерний практикум
[Текст]: навчальний посібник для студентів спеціальності 122 “Комп’ютерні науки”
для всіх спеціалізацій / за ред.: Л.М. Добровська, О.В. Аверьянова. Київ : КПІ ім. Ігоря
Сікорського, 2020. 152 с.
33. Управління конкурентоспроможністю підприємства : навч. посібник / за
ред. С.М. Клименко, Т.В. Омельяненко, Д.О. Барабась, О.С. Дуброва, А.В. Вакуленко.
Київ : КНЕУ, 2011. 267 с.
34. Управління проектами: процеси планування проектних дій : підручник /
за ред. І.В. Чумаченко, В.В. Морозов, Н.В. Доценко, А.М. Чередниченко. Київ : КРОК,
2014. 673 с.
92

35. Управління проєктами : навч. посібник / за ред. О.В Ульянченка, П.Ф.
Цигікала. Xарків : ХНАУ ім. В.В. Докучаєва, 2010. 522 с.
36. Управління проектами : підручник / за заг. ред. Л. В. Ноздріної. Київ :
Центр учбової літератури, 2010. 432 с.
37. Хацер М.В., Хацер Г.О. Регламентація процесів утворення стартапів в
умовах трансформації національної економіки. Глобальні та національні проблеми
економіки. Випуск 9. Харків : 2016. С. 433-436.
38. Хігні Д. Основи управління проєктами. [Текст] Харків : Фабула, 2020. 272
с.
39. Чухліб В.Є, Ведута Л.Л. Сучасні методи управління проектами. Сучасні
підходи до управління підприємством. Київ : 2018. С. 234–243.
40. Шостак Р.С. Оцінка сучасного стану та розвитку торгівельних мереж в
Україні. Київ : Економічний простір, 2011. С.115-123.
41. Яковенко О.І. Управління проектами та ризиками [Текст] : навч.
посібник. Ніжин : Видавець ПП Лисенко М.М., 2019. 196 с.
42. Cicala G. The Project Managers Guide to Microsoft Project 2019. Apress,
2020. 681 p.
43. Dionisio C.S. Microsoft Project 2019 For Dummies John Willey & Sons, Inc.,
2019. 352 p.
44. Kerzner H. Project Management: A Systems Approach to Planning,
Scheduling, and Controlling, 12th Edition. John Willey & Sons, Inc., 2017. 848 p.
45. Projects IN Controlled Environments (PRINCE2) the Office of Government
Commerce (OGC), United Kingdom. URL:
https://discovery.nationalarchives.gov.uk/details/r/C11669509 (дата звернення:
10.12.2023).
46. Алюшина Н. О. Тайм-менеджмент посадовця: мистецтво управляти своїм
часом. URL: http://alyushina.com/content/presentation/TM.pdf (дата звернення:
17.12.2023).
93

47. Буняк Н. М. Самоменеджмент як мистецтво саморозвитку особистості.
2017. Вип.18. URL: http://global-national.in.ua/archive/18-2017/36.pdf (дата звернення:
18.12.2023).
48. Гаврилюк А. М. Тайм-менеджмент як складова успішної комунікативної
взаємодії в індустрії туризму України. 2016. No.1. URL:
http://www.economy.nayka.com.ua/pdf/1_2016/14.pdf (дата звернення: 21.12.2023).
49. Матеріал з Вікіпедії – вільної енциклопедії. Автоматизація
технологічних процесів URL:
https://uk.wikipedia.org/wiki/Автоматизація_технологічних_процесів (дата звернення:
22.12.2023).
50. Матеріал з Вікіпедії – вільної енциклопедії. Станція технічного
обслуговування URL:
https://uk.wikipedia.org/wiki/Станція_технічного_обслуговування (дата звернення:
25.12.2023).
51. Матеріал з Вікіпедії – вільної енциклопедії. Станція технічного
обслуговування URL: https://uk.wikipedia.org/wiki/Arduino (дата звернення
25.12.2023).

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