1

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

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

Факультет інформаційних технологій і систем

Кафедра комп’ютерних наук та системного аналізу

Пояснювальна записка
до кваліфікаційної роботи
магістра
(освітньо-кваліфікаційний рівень)

на тему: «ІТ-проєкт створення інформаційної системи управління залишками

товарів, розміщених на сторонніх платформах»

Виконала: студентка 2 курсу, групи МСТП-2202

спеціальності 122  «Комп’ютерні науки»

(шифр і назва спеціальності)

освітня програма «Управління стартапами

(назва освітньої програми)
і проєктами в галузі інформаційних технологій»

Немцова Олена Геннадіївна .

Керівник Триус Ю.В.

(прізвище та ініціали)

Консультант___________ Сіньковський А.П.

(прізвище та ініціали)

Рецензент Веретельник В.В.

(прізвище та ініціали)

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

 2

Черкаський державний технологічний університет

Факультет Інформаційних технологій і систем
Кафедра Комп’ютерних наук та системного аналізу
Освітній рівень Магістр
Спеціальність 122 – комп’ютерні науки
Освітня програма Управління стартапами і проєктами в галузі інформаційних технологій

«ЗАТВЕРДЖУЮ»
Завідувач кафедри КНСА
_______________ Юрій ТРИУС
«06» жовтня 2023 року

ЗАВДАННЯ
на кваліфікаційну роботу магістра студенту
Немцовій Олені Геннадіївній
(прізвище, ім‘я, по батькові)

1. Тема роботи: ІТ-проєкт створення інформаційної системи управління залишками

товарів, розміщених на сторонніх платформах
Керівник роботи д.п.н., к.ф.-м.н., професор Триус Юрій Васильович
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)

затверджені наказом університету від «06» жовтня 2023 р. № 267/04

2. Строк подання студентом роботи 19.12.2023
3. Вихідні дані до роботи:
Система, що розроблюється, повинна здійснювати: аналіз та синхронізацію великих обсягів
структурованих даних; враховувати контекст; використовувати алгоритми оптимізації
управління залишками.
4. Зміст пояснювальної записки (перелік питань, що їх належить розробити):
Вступ
Розділ 1. Аналіз предметної області та постановка задачі дослідження
Розділ 2. Розробка концепції інформаційної системи управління залишками на сторонніх
платформах
Розділ 3. Планування проєкту розробки інформаційної системи управління залишками на
сторонніх платформах
Розділ 4. Практична реалізація продукту проєкту
Висновки
Список використаних джерел
5. Перелік додатків (з точним зазначенням назв додатків):
5.1. Додаток А. Специфікація 482.ЧДТУ. 32244-01.
5.2. Додаток В. Текст програми управління залишками товарів в межах інформаційної системи
та на сторонній платформі eBay.
5.3. Додаток В. Інструкція користувача щодо пошуку та перегляду інформації про товари.
5.4. Додаток Г. Публікація по темі кваліфікаційної роботи магістра.
 3

6. Консультанти розділів роботи

Підпис, дата
Прізвище, ініціали та
Розділ посада завдання видав завдання прийняв
консультанта
Розділ 4. Практична Сіньковський А.П.
реалізація продукту
проєкту

7. Дата видачі завдання 06 жовтня 2023 року

КАЛЕНДАРНИЙ ПЛАН
Строк виконання
№ з/п Назва етапів кваліфікаційної роботи магістра Примітка
етапів роботи
1 Видача завдання на кваліфікаційну роботу 1.09.2023 - виконано
магістра. 2.10.2023
2 Аналіз літературних джерел, об’єкту та предмету 3.10.2023 - виконано
дослідження. 20.10.2023
3 Написання теоретичного розділу кваліфікаційної 21.10.2023 - виконано
роботи магістра. 5.11.2023
4 Написання аналітичного розділу (аналіз об’єкту й 6.11.2023 - виконано
предмету дослідження). 20.11.2023
5 Написання практичних розділів й висновків 21.11.2023 - виконано
кваліфікаційної роботи магістра. 5.12.2023
6 Передзахист кваліфікаційної роботи магістра на виконано
13.12.2023
засіданні випускової кафедри.
7 Подання роботи завідувачу кафедри КНСА. 19.12.2023 виконано
8 Захист кваліфікаційної роботи магістра. 21.12.2023 виконано

Студент-магістрант ____________________________ Немцова О.Г.

(підпис)

Керівник роботи _____________________________ Триус Ю.В.

(підпис)
 4

РЕФЕРАТ

Обсяг кваліфікаційної роботи магістра складає 109 сторінок, у тому числі вступ,
чотири розділи, висновки, список використаних джерел і додатки. Робота містить 36
рисунків та 19 таблиць. Для виконання роботи використано 11 джерел.
Актуальність кваліфікаційної роботи магістра обумовлюється тим, що в
умовах посилення жорстких методів конкуренції на ринку, сучасні умови бізнес-
середовища, насичені стрімким розвитком технологій та активним ростом
електронної комерції, що змушує компанії шукати ефективні та інноваційні підходи
до управління своїми ресурсами. Виникла об’єктивна потреба у розробці та втіленні
нових підходів до управління конкурентоспроможністю продукції компаній.
Сучасний бізнес потребує постійної адаптації до швидко змінюючогося електронного
середовища, де онлайн-платформи відіграють важливу роль у торгівлі та комунікації
з клієнтами. У цьому контексті однією з ключових сфер управління є ефективне
ведення обліку залишків товарів на різних онлайн-платформах, що стає важливим
етапом стратегії успіху компанії в умовах глобального електронного ринку.
Мета роботи і задачі дослідження. Метою кваліфікаційної роботи є розробка
ІТ-проєкту створення інформаційної системи управління залишками товарів,
розміщених на сторонніх платформах, що оптимізує процес управління запасами та
підвищує рівень обслуговування клієнтів. Об'єктом дослідження є процес управління
проєктом створення інформаційної системи управління залишками товарів,
розміщених на сторонніх платформах. Для досягнення поставленої мети в
дослідженні необхідно вирішити такі задачі:
 виконати огляд методів та засобів для розробки інформаційної системи
управління залишками;
 дослідити аналоги та провести системний аналіз проблеми, визначити
оточення проєкту;
 визначити оточення проєкту та основні вимоги до системи, спроєктувати
систему відповідно до визначених вимог;
 5

 розробити концепцію інформаційної системи та провести її практичну

реалізацію, спрямовану на автоматизацію управління залишками товарів
на різних платформах;
 апробація системи на практиці з метою оцінки її ефективності та
придатності у реальному бізнесі.
Об’єкт дослідження: процес управління проєктом розробки інформаційної
системи управління залишками товарів компанії на різних онлайн-платформах в
умовах конкурентного суперництва між суб’єктами ринку на основі впровадження
ефективного управління запасами, здійснюваного компанією.
Предмет дослідження: проєкт розробки інформаційної системи управління
залишками товарів компанії на різних онлайн-платформах.
Методи дослідження. Сукупність прийомів і принципів наукового
дослідження, а саме: методи наукових узагальнень, порівняльного аналізу, сітьове
планування, метод декомпозиції, методи управління ризиками, моделювання бізнес-
процесів і прийоми програмування для розробки та тестування інформаційної
системи.
Апробація результатів роботи. Основні положення і результати
кваліфікаційної роботи магістра були представлені та отримали позитивну оцінку на
ІІІ Міжнародній науково-практичній Інтернет-конференції «ІПШРІТ-2023», м.
Черкаси, 6 грудня 2023 р.
Перелік ключових слів: ІНФОРМАЦІЙНА СИСТЕМА, УПРАВЛІННЯ
ЗАЛИШКАМИ, ЕЛЕКТРОННА КОМЕРЦІЯ, ІТ-ПРОЄКТ, ОПТИМІЗАЦІЯ
ПРОЦЕСІВ, СТОРОННІ ПЛАТФОРМИ.
 6

ABSTRACT
The volume of the master's thesis is 109 pages, including an introduction, four
chapters, conclusions and a list of sources used. The work contains 36 drawings and 19
tables. 11 sources were used to perform the work.
The relevance of the master's qualification work is due to the fact that in the
conditions of strengthening of tough methods of competition in the market, modern
conditions of the business environment, saturated with the rapid development of
technologies and the active growth of electronic commerce, which forces companies to look
for effective and innovative approaches to managing their resources. There was an objective
need to develop and implement new approaches to managing the competitiveness of
companies' products. Modern business needs constant adaptation to a rapidly changing
electronic environment, where online platforms play an important role in commerce and
communication with customers. In this context, one of the key areas of management is
effective accounting of product balances on various online platforms, which becomes an
important stage of the company's success strategy in the global electronic market.
Purpose and tasks of research. The purpose of the qualification work is the
development of an IT project to create an information system for managing product balances
placed on third-party platforms, which optimizes the inventory management process and
improves the level of customer service. The object of the research is the process of managing
the project of creating an information system for managing the balance of goods placed on
third-party platforms. To achieve the goal of the research, it is necessary to solve the
following problems:
 carry out a review of methods and means for the development of an information
system for the management of residues;
 research analogues and conduct a systemic analysis of the problem, determine
the environment of the project;
 determine the project environment and basic requirements for the system,
design the system in accordance with the specified requirements;
 to develop the concept of an information system and carry out its practical
implementation, aimed at automating the management of product balances on
 7

various platforms;
 approbation of the system in practice in order to assess its effectiveness and
suitability in real business.
Object of research: the project management process of the development of an
information system for managing the balance of the company's goods on various online
platforms in the conditions of competitive rivalry between market entities based on the
implementation of effective inventory management carried out by the company.
Subject of research: the project of developing an information system for managing
the balance of the company's goods on various online platforms.
Research methods. System analysis, network planning, decomposition method, risk
management methods, bottom-up budgeting method, SWOT analysis, PEST
analysis,programming techniques in programming languages: Python, JavaScript.
Approval of the results of work. The results of the master's qualification work are
published in the collection of abstracts of the student scientific-practical conference of
ChSTU «ITEST-2022», Cherkasy, 6 december, 2023.
The key words: INFORMATION SYSTEM, REMAINDER MANAGEMENT,
ELECTRONIC COMMERCE, IT PROJECT, PROCESS OPTIMIZATION, THIRD-
PARTY PLATFORMS
 8

ЗМІСТ
ВСТУП .................................................................................................................................. 9
РОЗДІЛ 1 АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ ТА ПОСТАНОВКА ЗАДАЧІ
ДОСЛІДЖЕННЯ................................................................................................................ 12
1.1 Системний аналіз об’єкта дослідження та предметної області .......................... 12
1.2 Постановка та обґрунтування проблеми .............................................................. 18
1.3 Методи та засоби вирішення проблеми ............................................................... 21
Висновки до розділу 1 .................................................................................................. 29
РОЗДІЛ 2 РОЗРОБКА КОНЦЕПЦІЇ ІНФОРМАЦІЙНОЇ СИСТЕМИ УПРАВЛІННЯ
ЗАЛИШКАМИ НА СТОРОННІХ ПЛАТФОРМАХ ...................................................... 30
2.1 Аналіз первинних та вторинних зацікавлених сторін та їх впливу на проєкт . 30
2.2 Формування цілей та місії проєкту розробки інформаціної системи ............... 33
2.3 Аналіз життєвого циклу проєкту .......................................................................... 38
Висновки до розділу 2 .................................................................................................. 41
РОЗДІЛ 3 ПЛАНУВАННЯ ПРОЄКТУ РОЗРОБКИ ІНФОРМАЦНОЇ СИСТЕМИ
УПРАВЛІННЯ ЗАЛИШКАМИ НА СТОРОННІХ ПЛАТФОРМАХ ........................... 42
3.1 Планування змісту проєкту ................................................................................... 42
3.2 Планування ресурсів та бюджету проєкту .......................................................... 46
3.3 Ідентифікація та аналіз ризиків проєкту ............................................................... 49
3.4 Планування якості проєкту ................................................................................... 55
Висновки до розділу 3 .................................................................................................. 63
РОЗДІЛ 4 ПРАКТИЧНА РЕАЛІЗАЦІЯ ПРОДУКТУ ПРОЄКТУ ................................ 65
4.1 Структурно-функціональне моделювання процесу розробки інформаційної
системи управління залишками на сторонніх платформах ...................................... 65
4.2 Опис реалізації інформаційної системи управління залишками на сторонніх
платформах .................................................................................................................... 72
4.3 Аналіз отриманих результатів .............................................................................. 82
Висновки до розділу 4 .................................................................................................. 88
ВИСНОВКИ ....................................................................................................................... 89
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ......................................................................... 91
ДОДАТОК А Специфікація 482.ЧДТУ. 32244-01 ......................................................... 92
ДОДАТОК Б Текст програми управління залишками товарів в межах інформаційної
системи та на сторонній платформі eBay ....................................................................... 94
ДОДАТОК В Інструкція користувача щодо пошуку та перегляду інформації про
товари ............................................................................................................................... 102
ДОДАТОК Г Публікація по темі кваліфікаційної роботи магістра .......................... 105
 9

ВСТУП

Актуальність кваліфікаційної роботи магістра обумовлюється тим, що в умовах

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

 проаналізувати ринок та сучасні тенденції у сфері електронній комерції

та управлінні ланцюгом постачання;
 дослідити аналоги та провести системний аналіз проблеми, стратегічний
аналіз організації, визначити оточення проєкту;
 розробити концепцію інформаційної системи управління залишками
товарів компанії на різних онлайн-платформах та провести її практичну
реалізацію, спрямовану на автоматизацію управління залишками товарів
на різних платформах;
 апробація інформаційної системи на практиці з метою оцінки її
ефективності та придатності у реальному бізнесі.
Методами дослідження роботи є сукупність методів, прийомів і принципів
наукового дослідження, а саме: методи наукових узагальнень, порівняльного аналізу,
синтезу застосовано при дослідженні теоретичних основ, моделювання бізнес-
процесів, програмування для розробки інформаційної системи, тестування та
апробація на практиці.
Теоретичною і методологічною основою дослідження виступають публікації в
засобах масової інформації, наукові праці вітчизняних та іноземних дослідників,
основні положення яких є базисом управління ІТ-стартапами та ІТ-проєктами.
Результати дослідження та розроблена інформаційна система будуть
використані для покращення ефективності управління залишками товарів компанії на
різних електронних платформах. Це дозволить оптимізувати процеси управління
запасами, зменшити ризики людських помилок та підвищити
конкурентоспроможність компанії.
Розроблена інформаційна система буде апробована на практиці в реальних
умовах функціонування компанії для ефективного управління запасами, що
означатиме прискорений розвиток електронної комерції компанії та гарантуватиме їй
підвищення конкурентоспроможності на ринку та відповідності високим стандартам
обслуговування клієнтів. Результати апробації будуть використані для коригування
та удосконалення системи перед її повним впровадженням.
 11

У цій роботі буде надано детальний огляд розробленої інформаційної системи,

її можливостей та практичного внеску у сферу управління запасами на онлайн-
платформах.
Апробація результатів роботи. Основні положення і результати кваліфікаційної
роботи магістра були представлені та отримали позитивну оцінку на ІІІ Міжнародній
науково-практичній Інтернет-конференції «ІПШРІТ-2023», м. Черкаси, 6 грудня
2023 р.
Немцова О.Г., Сіньковський А.П. Інформаційна система управління
залишками, розміщених на сторонніх платформах.
 12

1 АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ ТА ПОСТАНОВКА ЗАДАЧІ

ДОСЛІДЖЕННЯ

1.1 Системний аналіз об’єкта дослідження та предметної області

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

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

Системний аналіз об'єкта дослідження та предметної області надає глибоке

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

Критерії якості

Точність обліку Оперативність Адаптивність

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

Рисунок 1.1 – Критерії якості інформаційної системи

Наявні ресурси компанії включають в себе наступні:

 ІТ-інфраструктура: аналіз доступності та потужності інформаційних систем
та технічних ресурсів;
 Людські ресурси: експертиза та кваліфікація персоналу для впровадження
та підтримки системи;
 Фінансові ресурси: фінансові можливості для розробки та впровадження
інформаційної системи.
 14

Система «as is» в проєктуванні інформаційних систем вказує на поточний стан

або існуючий стан системи. Це опис системи такою, якою вона є на даний момент,
без будь-яких змін чи вдосконалень. У контексті бізнес-аналізу та проєктного
управління вираз «as is» використовується для документування, аналізу та розуміння
існуючих бізнес-процесів, систем та процедур перед початком будь-яких змін чи
покращень.
Процес аналізу «as is» включає в себе визначення системи та її взаємодії з
зовнішнім середовищем:
 Система: об'єктом є комплекс торгівельних платформ, баз даних,
інформаційних систем та процесів інвентаризації, що використовуються для
управління залишками товарів на різних електронних платформах;
 Зовнішнє середовище: включає електронні торговельні платформи,
конкурентів та технологічні тенденції;
 Декомпозиція елементів: товари, платформи, інформаційні системи,
процеси інвентаризації;
 Бізнес-процеси: додавання товарів, оновлення залишків, ведення
інвентаризації.
 Потоки даних: обмін інформацією між платформами та системами;
 Елементи системи: товари на платформах, інформаційні системи для
управління запасами, процеси інвентаризації та оновлення залишків.
Наступним кроком проаналізуємо основні альтернативи побудови системи.
Аналіз основних альтернатив побудови системи є важливим етапом у процесі
проєктного менеджменту. Він дозволяє визначити найбільш оптимальний шлях для
реалізації системи, враховуючи відповідні фактори. Також аналіз допомагає
ідентифікувати можливі ризики та труднощі, пов'язані з кожним варіантом, сприяючи
мінімізації можливих проблем.
Завдяки аналізу альтернатив, можна отримати обґрунтовану основу для
прийняття рішення щодо найефективнішого шляху досягнення цілей проєкту.
До переліку основних альтернатив побудови системи можна віднести наступні:
 15

1. Інтеграція платформ, тобто забезпечення єдиного інтегрованого простору

для управління запасами на всіх платформах – A1;
2. Оптимізація інформаційних систем, тобто модернізація існуючих систем
для узгодження даних та покращення продуктивності – A2;
3. Впровадження аналітичних інструментів, тобто використання аналітики
для прогнозування попиту, підтримки стратегічних рішень та оптимізації
запасів – A3.
Виділення станів середовища в контексті аналізу ризиків та прийняття рішень
дозволяє враховувати різні сценарії розвитку подій або умови, які можуть впливати
на проєкт чи бізнес-процес [1]. Врахування різних станів дозволяє краще розуміти та
управляти невизначеністю та ризиками. Тому наступним кроком виділимо стани
середовища:
1. Попит на єдиному інтегрованому просторі – S1;
2. Взаємодія між модернізованими системами – S2;
3. Використання аналітичних інструментів для прогнозування попиту– S3.
Розглянемо матрицю втрат (таблиця 1.1), значення якої вказані в межах від 0 до
1, де 0 – відсутність втрат, а 1 – максимальні втрати.

Таблиця 1.1 – Матриця втрат

Аі \𝑆𝑗 S1 S2 S3
A1 0,3 0,3 0,2
A2 0,3 0,2 0,5
A3 0,2 0,7 0,1

Знаходження оптимальних рішень для кожного критерію може допомогти

визначити, яка альтернатива є найбільш прийнятною в умовах невизначеності.
За принципом Лапласа [2] стани середовища 𝑆1 , 𝑆2 , 𝑆3 – рівноймовірні.
Обчислимо для кожної альтернативи середнє значення втрат і виберемо альтернативу
з максимальним середнім. Отже, за формулою ймовірності станів дорівнюють:
 16

1
pi = = 0,33, i ∈ {1,2,3}.
3
Очікувані витрати для різних альтернатив побудови системи А1 , А2 , А3
становлять:
E(A1 ) = 0,33 ⋅ (0,3 + 0,3 + 0,2) = 0,26 → min
E(A2 ) = 0,33 ⋅ (0,3 + 0,2 + 0,5) = 0,33
E(A3 ) = 0,33 ⋅ (0,2 + 0,7 + 0,1) = 0,33

За критерієм Лапласа можна рекомендувати для вибору альтернативу 𝐴1 .

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

Таблиця 1.2 – Обчислення за критерієм Вальда

Витрати eij m𝑎𝑥 eij E ∗= minmaxeij
j
Аі \Sj S1 S2 S3 j

𝐀𝟏 0,3 0,3 0,2 0,3 0,3

A2 0,3 0,2 0,5 0,5 -

A3 0,2 0,7 0,1 0,7 -

Таким чином, найкращою відповідно до критерію Вальда є альтернатива 𝐴1 .

Відповідно до критерію Седвіджа для вихідної матриці ефективності будуємо
матрицю ризиків 𝑅𝐴 (таблиця 1.3), елементи якої 𝑟𝑖𝑗 визначаємо за формулою:

𝑟11 = 0,3 − 0,2 = 0,1 𝑟12 = 0,3 − 0,2 = 0,1 𝑟13 = 0,2 − 0,1 = 0,1
𝑅𝐴 = (𝑟21 = 0,3 − 0,2 = 0,1 𝑟22 = 0,2 − 0,2 = 0 𝑟23 = 0,5 − 0,1 = 0,4).
𝑟31 = 0,2 − 0,2 = 0 𝑟32 = 0,7 − 0,2 = 0,5 𝑟33 = 0,1 − 0,1 = 0
 17

Таблиця 1.3 – Обчисення за критерієм Седвіджа

Аі \𝑆𝑗 𝐸 ∗= 𝑚𝑖𝑛𝑚𝑎𝑥 𝑟𝑖𝑗 E ∗= minmaxeij
𝑖 𝑗 m𝑎𝑥 eij j
j
S1 S2 S3
𝐀𝟏 0,1 0,1 0,1 0,1 0,1

A2 0,1 0 0,4 0,4 -

A3 0 0,5 0 0,5 -

Запровадження величини ризику 𝑟𝑖𝑗 призвело до вибору альтернативи 𝐴1 , яка

забезпечує найменші втрати у найсприятливішій ситуації (коли ризик мінімальний).
У методі Гурвіца, параметр α представляє ваговий коефіцієнт між максимумом
та мінімумом. Значення α може змінюватися від 0 до 1 і відображати ступінь
консервативності чи ризикованості прийняття рішення. Коли α = 0.5, обидві сторони
(максимум та мінімум) рівнозначні, що вказує на баланс між уникненням ризику та
отриманням максимальної вигоди.
Таким чином, в даному випадку, вибір α = 0.5 вказує на те, що обидва кінці
(максимум і мінімум) мають однаковий вплив на прийняття рішення для досягнення
балансу між оптимізмом і песимізмом при визначенні найкращого варіанту в умовах
невизначеності.
Для реалізації критерію побудуємо відповідну таблицю, коли 𝛼 = 0,5
(таблиця 1.4).

Таблиця 1.4 – Обчисення за критерієм Гурвіца

Аі 𝑚𝑖𝑛𝑒𝑖𝑗 𝑚𝑎𝑥 𝑒𝑖𝑗 𝐸(𝐴𝑖 ) = 𝛼𝑚𝑖𝑛𝑒𝑖𝑗 + (1 − 𝛼 )𝑚𝑎𝑥 𝑒𝑖𝑗 𝐸 ∗= 𝑚𝑖𝑛𝐸𝑖

𝑗 𝑗 𝑗 𝑗 𝑖

𝑨𝟏 0,2 0,3 0,35 0,35

𝐴2 0,2 0,5 0,45 -

𝐴3 0,1 0,7 0,45 -

 18

Оптимальне рішення полягає у виборі значення 𝐸1 , яке відповідає альтернативі

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

1.2 Постановка та обґрунтування проблеми

У сучасному електронному бізнесі, де конкуренція надто висока, а споживачі

стають все більше вимогливими, управління залишками товарів на різних онлайн-
платформах стає надзвичайно важливим завданням для компаній [3]. Проблема
неефективного управління залишками товарів виникає через ряд чинників, що
вимагають докладного вивчення та вирішення. До їх переліку можна віднести
наступні:
1. Комплексність електронної комерції: зростання популярності електронної
комерції призвело до збільшення кількості платформ, на яких компанії можуть
представляти свої товари. Це може призводити до фрагментації даних та
ускладнення процесів інвентаризації. Управління залишками на кожній з
платформ стає викликом через неоднакові формати, протоколи та вимоги
кожної платформи.
2. Неоднорідність інформаційних систем: багато компаній використовують різні
інформаційні системи для ведення обліку залишків. Це може призводити до
неузгодженості та розбіжностей у даних між системами, а також ускладнювати
процес прийняття рішень. Неоднорідність інформаційних систем стає
перешкодою для швидкого та точного управління залишками.
 19

3. Потреба у високій точності та оперативності: споживачі у сфері електронної

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

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

зростанням конкуренції на ринку. Забезпечення точності та оперативності управління
залишками товарів є ключовим фактором для успішної конкурентоспроможності.
Очікувані ефекти від впровадження системи:
1. Мінімізація помилок: зменшення людських помилок у процесі інвентаризації
та управління залишками;
2. Оптимізація процесів: автоматизація і оптимізація управління асортиментом
для ефективнішої роботи компанії;
3. Збільшення точності інформації: забезпечення єдиної та точної інформації про
товари на різних платформах.
Концептуальна модель системи включає опис вхідних та вихідних даних, опис
функцій та структури системи, а також додаткові формальні або узагальнені моделі
системи (рисунок 1.2).

Вхідні дані Вихідні дані

 Дані про товари на різних  Актуальні дані про

електронних платформах. залишки товарів на
 Інформація про платформах.
інвентаризацію та залишки  Звіти і аналітика щодо
товарів. управління запасами.

Функції та структури системи Додаткові формальні або

узагальнені моделі системи
 Автоматизована інвентаризація
товарів.  Модель зв'язків між
 Синхронізація інформації про таблицями бази даних.
залишки на різних платформах.  Модель оптимізації
 Генерація звітів та аналітика управління асортиментом.
залишків та попиту.

Рисунок 1.2 – Концептуальна модель інформаційної системи

 21

Згідно рисунку 1.2 можна зробити висновки, що вхідні дані включають

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

1.3 Методи та засоби вирішення проблеми

Розроблювана інформаційна система спеціалізується на управлінні залишками

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

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

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

Таблиця 1.5 – Аналіз основних СУБД

СУБД Переваги Недоліки
 Легко встановлюється та
використовується.
 Використовується в
 Обмежені можливості
широкому спектрі
для розподілених систем.
проєктів.
 Менше розширених
MySQL  Широка підтримка
функцій порівняно з
спільноти та активний
деякими іншими СУБД.
розвиток.
 Висока продуктивність
при роботі з великими
обсягами даних.
 Легко вбудовується в
додатки.  Неефективна для великих
 Проста в управлінні та об'ємів даних.
SQLite
обслуговуванні.  Обмежені можливості
 Не потребує окремого масштабування.
серверу для роботи.
 Потужна та розширювана.  Вимагає більше ресурсів
 Висока надійність та у порівнянні з SQLite та
PostgreSQL масштабованість. MySQL.
 Розширена підтримка
стандарту SQL.

Для більш детального аналізу СУБД, виділимо основні критерії їх порівняння

та надамо оцінку від 1 до 10 по кожному з них:
 23

1. MySQL:
 Стандарт SQL: 7 – Хоча MySQL використовує стандарт SQL, існують
відмінності в підтримці деяких опцій, що може вплинути на
переносимість коду;
 Розширюваність: 8 – Забезпечує прийнятну розширюваність для середніх
проєктів, але може виникнути обмеження на великих обсягах даних або
високому навантаженні;
 Використання ресурсів: 7 – Має низькі вимоги до ресурсів, що робить
його ефективним для проєктів з обмеженими ресурсами;
 Підтримка масштабування: 9 – Є гнучким у масштабуванні, але високий
рівень масштабування може вимагати додаткових зусиль;
 Вільна ліцензія: 9 - Використовує дві ліцензії: GPLv2 та комерційну.
Безкоштовний використання, але комерційні додатки можуть вимагати
платної ліцензії.
2. PostgreSQL
 Стандарт SQL: 9 – Широко визнаний своєю дотриманістю стандартів
SQL, PostgreSQL надає повну підтримку SQL та навіть розширює його
деякими додатковими функціями;
 Розширюваність: 9 – Висока гнучкість та можливості розширення.
 Використання ресурсів: 7 – Має високе споживання ресурсів, особливо
для великих проєктів;
 Підтримка масштабування: 8 – Забезпечує високий рівень
масштабованості, включаючи реплікацію та кластеризацію;
 Вільна ліцензія: 9 – PostgreSQL має вільну ліцензію.
3. SQLite:
 Стандарт SQL: 6 – Обмежений функціонал, особливо у порівнянні з
серверними СУБД;
 Розширюваність: 6 – Підходить для простих проєктів, але не ефективний
для великих систем;
 24

 Використання ресурсів: 8 – Легкий, споживає низьку кількість ресурсів4

 Підтримка масштабування: 5 – Обмежена підтримка масштабування, в
основному для невеликих проєктів4
 Вільна ліцензія: 10 – SQLite має вільну ліцензію, яка дозволяє
використання в комерційних та некомерційних проєктах без обмежень.
На рисунку 1.3 графічно представлено результати оцінювання основних
критеріїв порівняння СУБД. Завдяки цьому підходу можна краще зрозуміти переваги
тої чи іншої СУБД.

PosgreSQL SQLite MySQL

Стандарт SQL
10

4
Вільна ліцензія Розширюваність
2

Підримка
Використання ресурсів
масштабування

Рисунок 1.3 – Оцінка основних критеріїв порівяння СУБД

На підставі порівняльного аналізу СУБД, PostgreSQL видається найбільш

підходящим варіантом для веб-орієнтованої інформаційної системи управління
залишками товарів. Він поєднує високу підтримку стандартів SQL, потужність,
розширюваність та здатність ефективно опрацьовувати великі обсяги даних, що є
важливими факторами для успішного розвитку системи.
Обираючи мову програмування для розробки інформаційної системи
«Управління залишками товарів компанії, розміщених на сторонніх платформах»,
було прийнято рішення вибрати Java. Обґрунтуємо цей вибір, розглянувши та
порівнявши її з 2 іншими найвідомішими мовами програмування, які
 25

використовуються у веб-розробці: C# і Python. Проаналізуємо їхні переваги та

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

Таблиця 1.6 – Аналіз мов програмування

Мова
Переваги Недоліки
програмування
 Широка спільнота
користувачів та розробників;
 Порівняно більший обсяг коду;
 Широке використання в
 Підвищені вимоги до обсягу
корпоративному середовищі;
Java оперативної пам'яті;
 Масштабованість та
 Складніше вивчення;
ефективність;
 Не такий зручний синтаксис,
 Кроссплатформенність;
як у Python.
 Безпека та надійність;
 Об'єктно-орієнтована.
 Залежність від інфраструктури
Microsoft;
 Підтримка Microsoft та .NET;
 Обмежені можливості веб-
 Висока інтеграція з
розробки;
C# продуктами Microsoft;
 Не така широка спільнота, як у
 Ефективність;
Java;
 Сучасний синтаксис та
 Помірна швидкодія;
розширені можливості;
 Обмежена підтримка для
деяких типів додатків
 Простота та легкість  Спрощений синтаксис може
вивчення; призвести до меншої
 Мультипарадигмальність; читабельності коду;
 Простий синтаксис;  Відсутність компіляції;
Python  Розширюваність;  Відсутність вбудованих
 Широка спільнота механізмів безпеки;
розробників;  Брак інфраструктурної
 Багатофункціональність та підтримки у деяких областях,
велика кількість бібліотек порівняно з Java

Аналізуючи переваги і недоліки можна зробити висновки, що:

 C#: мова програмування, розроблена Microsoft, орієнтована на платформу
.NET. C# з потужним інструментарієм, особливо ефективним для розробки програм
для Windows та веб-застосунків.
 Python: високорівнева мова програмування, яка знайшла широке
застосування у веб-розробці, наукових дослідженнях та штучному інтелекті. Python
 26

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

розробників.
 Java: це об'єктно-орієнтована мова програмування, розроблена компанією
Sun Microsystems, є платформонезалежною, що дозволяє виконувати код на різних
пристроях без перекомпіляції.
Після аналізу всіх переваг і недоліків, вибір був зроблений на користь мови
програмування Java. Java – це найкраща мова для створення динамічних веб-сайтів та
веб-додатків, з великою кількістю фреймворків і бібліотек, які щорічно оновлюються,
що робить її зручною для роботи.
У розробці веб-орієнтованої інформаційної системи для управління залишками
товарів на різних онлайн-платформах обрано використання фреймворків для
підвищення швидкості та надійності розробки. Один з ключових фреймворків, який
буде задіяний у проєкті – Spring Boot.
Фреймворк Spring Boot обрано для розробки серверної частини веб-
орієнтованої інформаційної системи управління залишками товарів. Spring Boot – це
високопродуктивний фреймворк для створення мікросервісів та веб-додатків [6].
Розглянемо ключові фактори та переваги використання Spring Boot у нашому проєкті:
 Легкість розгортання та конфігурації: Spring Boot надає конфігурацію за
замовчуванням, що робить розгортання додатків простим та швидким. Він дозволяє
швидко налаштовувати додаток без великої кількості шаблонного коду.
 Вбудований веб-сервер: Spring Boot має вбудовані сервери, такі як Tomcat,
Jetty або Undertow, що спрощує розгортання додатків без необхідності налаштування
зовнішніх серверів.
 Модульність та Компонентна Архітектура: Spring Boot використовує
компонентний підхід та інверсію управління, що полегшує розробку, тестування та
підтримку коду.
 Активна спільнота та регулярні оновлення: Spring Boot користується
великою спільнотою розробників та має вичерпну документацію. Це забезпечує
доступність ресурсів для вирішення можливих проблем, а регулярні оновлення
гарантують сучасні можливості.
 27

 Підтримка хмарних технологій: Spring Boot легко інтегрується з різними

облачними платформами, такими як AWS, Azure, а також забезпечує підтримку
мікросервісної архітектури.
 Підтримка сучасних технологій: Spring Boot вбудовує засоби для створення
RESTful API, а також має велику кількість бібліотек для інтеграції з іншими
технологіями.
 Підтримка Мікросервісної Архітектури: Засоби Spring Boot ідеально
підходять для реалізації мікросервісної архітектури, що є важливим аспектом для
масштабованості та гнучкості системи.
 Безпека та автентифікація: Spring Boot надає широкі можливості для
реалізації заходів безпеки, включаючи аутентифікацію, авторизацію та захист від
атак, за допомогою Spring Security.
Обрання Spring Boot для розробки серверної частини системи управління
залишками товарів є обґрунтованим рішенням, адже він надає необхідні інструменти
та можливості для швидкого та ефективного розгортання, керування та розширення
проєкту, забезпечуючи високу продуктивність та безпеку.
Для розробки клієнтської частини був обраний фреймворк Angular. Angular –
це популярний фреймворк для розробки веб-додатків, розроблений компанією
Google. У таблиці 1.7 виокремлені ключові фактори та переваги Angular у контексті
нашого проєкту.
 28

Таблиця 1.7 – Ключові фактори Angular

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

Аналізуючи таблицю 1.7, можна зробити висновки, що Angular є потужним

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

Висновки до розділу 1

В результаті аналізу предметної області та системного аналізу об’єкта

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

2 РОЗРОБКА КОНЦЕПЦІЇ ІНФОРМАЦІЙНОЇ СИСТЕМИ УПРАВЛІННЯ

ЗАЛИШКАМИ НА СТОРОННІХ ПЛАТФОРМАХ

2.1 Аналіз первинних та вторинних зацікавлених сторін та їх впливу на

проєкт

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

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

інтерфейсу. Для них важливо, щоб система була легкою у використанні та

забезпечувала необхідні функції.
 Партнери компанії: Партнери, що співпрацюють із компанією, можуть бути
зацікавлені в покращенні фінансової стійкості компанії через ефективне управління
залишками та обігом товарів.
 Галузеві експерти: Фахівці в галузі можуть допомагати визначити та
реалізувати специфічні вимоги системи. Їхні рекомендації можуть впливати на
функціональність системи.
Вторинні зацікавлені сторони можуть впливати на нього або піддаватися його
впливу. До вторинних зацікавлених сторін нашого проєкту можна віднести наступні:
 Конкуренти: Конкуренція стимулює компанію до інновацій. Щоб займати
лідируючі позиції, необхідно пропонувати унікальні та покращені рішення, які
відрізнятимуть продукт від інших.
 Клієнти компанії: Клієнти, які купують товари через сторонні платформи,
мають інтерес в доступності товарів, точності та узгодженності інформації про
залишки, а також оперативності обробки замовлень.
 Регулюючі органи: Регулюючі органи можуть бути зацікавлені в тому, як
система дотримується встановлених стандартів та вимог.
Проаналізуємо та визначимо рівень впливу на проєкт кожної із зацікавлених
сторін (таблиця 2.1).
Аналізуючи таблицю 2.1, можна зробити висновки, що замовник та менеджер
проєкту є ключовими фігурами, оскільки вони визначають стратегічні та оперативні
аспекти проєкту відповідно. Розглянемо більш детально, чому саме ці ролі найбільше
впливають на проєкт.
Визначення вимог:
 Замовник визначає основні вимоги до продукту. Його бачення та очікування
визначають функціональні та якісні характеристики системи.
 32

 Менеджер проєкту: Менеджер проєкту взаємодіє із замовником для

розуміння його потреб, допомагає визначити реалістичні та досяжні цілі
проєкту.
Таблиця 2.1 – Матриця зацікавлених сторін
Зацікавлені сторони Вплив на проєкт (1 - незначний, 4 - критичний)
проєкту Ресурси Запити проєкту Процеси проєкту Оцінка виконання

Вирішення проблем

Гарантія зайнятості
Премія персоналу
Командна робота
Процеси проєкту

Прогрес проєкту

Робота команди
Інфраструктура
Розклад роботи

Успіх проєкту
Організаційні
Специфікації

Компетенції
Обладнання

Пріоритети
Інформація

Технологія
Матеріали

Бюджет
Знання

Якість
Гроші
Люди

Первинні Цілі

Компанія-власник 1 4 1 1 3 3 3 4 4 2 2 3 1 2 1 2 2 3 2 3 1 2 2 1
Замовник 1 4 1 2 3 3 4 4 4 2 3 3 1 2 3 2 3 3 3 3 2 2 3 2
Менеджер 4 3 3 3 3 4 3 2 2 2 2 3 4 4 4 2 3 4 4 4 4 4 3 4
Команда розробки 2 1 1 1 1 3 1 3 2 2 2 3 4 4 3 2 4 3 3 3 3 2 2 2
Постачальники 1 1 1 4 1 1 1 2 1 1 1 1 1 2 2 2 1 1 2 2 1 1 1 1
Користувачі системи 1 1 1 1 2 2 3 4 4 1 1 2 1 2 1 1 2 1 1 2 1 2 1 1
Партнери компанії 1 1 1 1 1 1 1 2 2 1 1 2 1 1 1 2 1 1 1 1 1 1 1 1
Галузеві експерти 1 1 1 1 3 3 2 2 3 1 1 2 1 1 1 2 1 2 2 1 1 1 1 1
Вторинні
Конкуренти 1 1 1 1 3 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
Клієнти компанії 1 2 1 1 2 1 2 3 2 1 1 2 1 1 1 1 1 1 1 3 1 1 1 1
Регулюючі органи 1 1 1 1 2 1 2 1 2 1 1 1 1 1 1 2 1 2 1 2 1 1 1 1

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

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

2.2 Формування цілей та місії проєкту розробки інформаційної системи

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

відповідає потребам компанії у керуванні залишками товарів на онлайн-платформах,
забезпечуючи ефективність, безпеку та розширюваність. До переліку цілей проєкту
віднесемо наступні:
1. Реалізація системи для ефективного моніторингу та управління залишками
товарів, розміщених на різних сторонніх платформах забезпечить компанії
автоматизовані інструменти для ефективного контролю залишків товарів у
режимі реального часу.
2. Розробка системи, яка може взаємодіяти з різними онлайн-торговельними
платформами, такими як eBay, Amazon тощо, забезпечить можливість
підключення та взаємодії з різними платформами для швидкого та ефективного
обміну даними.
3. Розробка функціоналу для оптимізації процесів управління та обробки
замовлень на різних торговельних платформах зменшить час та ресурси,
необхідні для обробки та виконання замовлень, покращить швидкість та якість
обслуговування клієнтів.
4. Створення зручного та інтуїтивно зрозумілого інтерфейсу для користувачів
системи забезпечить простий та зрозумілий доступ до функціоналу системи для
ефективного використання користувачами.
 34

5. Впровадження заходів безпеки для захисту даних про товари, замовлення та

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

Таблиця 2.2 – Критерії досягнення цілей проєкту

№ Ціль Критерії

Автоматизація  Зниження помилок при обліку залишків;

1  Скорочення часу на проведення інвентаризації;
управління залишками
 Підвищення точності прогнозування потреб в товарах.
 Забезпечення безперервного обміну інформацією між
Інтеграція з онлайн- системою та сторонніми платформами;
2
платформами  Інтеграція з новими платформами;
 Зменшення часу реагування на зміни стану залишків.
 Зменшення часу обробки та аналізу даних;
Оптимізація процесів  Введення інтерфейсу для зручного управління
3 залишками;
обробки інформації
 Підвищення ефективності роботи персоналу;
 Зменшення кількості помилок при обробці даних.
Забезпечення безпеки та  Впровадження механізмів шифрування для
4 конфіденційнихданих;
конфіденційності
 Запобігання несанкціонованому доступу до системи.
 Готовність системи до інтеграції нових
Забезпечення сумісності функціональностей;
5
та розширюваності  Збереження стабільності та продуктивності системи
підчасрозширень.
 Зменшення часу на оформлення замовлення;
Покращення  Підвищення доступності та оперативності в оновленні
6
клієнтського досвіду інформації для клієнтів;
 Збільшення задоволеності клієнтів.
 35

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

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

 збільшення прибутку через підвищення рівня продажів.

Користувачі системи:
 покращення ефективності роботи через автоматизовані процеси
управління товарами;
 забезпечення точної та актуальної інформації для швидких та
обґрунтованих рішень;
 можливість легко взаємодіяти з іншими системами та отримувати
інформацію в режимі реального часу.
Партнери компанії:
 забезпечення доступу до актуальних даних про товари та замовлення для
оптимізації спільної діяльності;
 розширення можливостей для спільних маркетингових та продажових
ініціатив.
Галузеві експерти:
 отримання доступу до інноваційних методів та технологій управління
залишками;
 посилення експертного статусу через використання передових рішень у
галузі.
Конкуренти:
 можливість оптимізації власних процесів та покращення обслуговування
клієнтів;
 підвищення власної прибутковості через посилення позицій на ринку;
 можливість швидше реагувати на зміни у попиті та забезпечити
ефективніші стратегії управління запасами.
Клієнти компанії:
 покращення якості обслуговування через швидку та точну інформацію
про наявність товарів;
 забезпечення надійності та якості обробки замовлень.
Регулюючі органи:
 37

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

Таблиця 2.3 – Обмеження проєкту

Назва Значення Опис
Обмеження фінансових ресурсів для проєкту, що
Бюджетні <= 500
визначає доступність коштів для розробки та
обмеження тис.грн
впровадження системи.
Часові обмеження <= 9 міс. Конкретний термін для виконання проєкту.
Технічні обмеження eBay API Система має враховувати технічні обмеження
платформ (версія 2.0) платформ щодо інтеграції та функціональності.
Обмеження доступу Залежно від API сторонніх платформ, може
<= 5 тис./день
до API існувати обмеження на частоту запитів.
Потреба у Розробка та підтримка системи може вимагати
спеціалізованому Java, JS наявності кваліфікованого персоналу з певними
персоналі навичками.
Розробка повинна враховувати вимоги Закону про
захист персональних даних та угоди про конфіденційність
Правові обмеження
з партнерами для забезпечення відповідності
законодавству та уникнення правових проблем.
 38

2.3 Аналіз життєвого циклу проєкту

Життєвий цикл проєкту – це сукупність етапів, які проєкт пройде від початку
до завершення. Кожен етап має свої особливості та завдання, спрямовані на
досягнення конкретних цілей.
Чітке розуміння цих фаз дозволить менеджеру максимально ефективно
контролювати проєкти. Метою життєвого циклу є створення простої в користуванні
структури для керівництва та управління проєктами.
Життєвий цикл проєкту допомагає:
 ефективно розподіляти завдання та ресурси серед членів команди,
забезпечуючи оптимальне використання їх потенціалу;
 забезпечувати зручний механізм відстеження прогресу проєкту та вчасні
корективи у випадку виникнення змін або непередбачених ситуацій;
 створювати базу для подальшого вдосконалення процесів та методів
роботи команди на майбутніх проєктах;
 забезпечувати прозорість управління проєктом, що сприяє довірі між
усіма учасниками та стейкхолдерами.
Загалом життєвий цикл проєкту відіграє ключову роль у забезпеченні
успішного виконання завдань, сприяє вдосконаленню комунікації та зменшенню
ризиків на різних етапах розробки та реалізації проєкту.
Згідно зі стандартом Project Management Body of Knowledge, або PMBOK [7],
життєвий цикл складається з п'яти фаз (рисунок 2.1).
 39

Ініціалізація

Завершення Планування

Контроль Реалізація

Рисунок 2.1 – Етапи життєвого циклу проєкту

Розглянемо етапи життєвого циклу для нашого проєкту:

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

 Визначення ризиків: Аналіз можливих ризиків та розробка стратегій їх

управління;
 Оцінка бюджету: Визначення фінансових ресурсів, необхідних для
кожного етапу проєкту.
3. Реалізація – на етапі реалізації відбувається сам процес розробки та
впровадження інформаційної системи. Цей етап включає:
 Розробка інформаційної системи: Створення програмного забезпечення,
включаючи всі необхідні функціональності та інтеграцію з існуючими
системами;
 Тестування та валідація: Проведення тестів для перевірки
функціональності, надійності та безпеки системи;
 Навчання персоналу: Проведення навчань для користувачів та
адміністраторів системи.
4. Контроль – на етапі контролю відбувається моніторинг ходу проєкту та
вживання заходів для виправлення виявлених невідповідностей. Цей етап
включає:
 Моніторинг прогресу проєкту: Систематичне відстеження реалізації
плану, виявлення можливих затримок чи проблем;
 Звітність та комунікації: Підготовка звітів для зацікавлених сторін та
підтримка відкритого спілкування в команді проєкту;
 Вирішення проблем: Швидке реагування на проблеми, що виникають, та
прийняття заходів для їх вирішення.
5. Завершення – на етапі завершення відбувається завершення всіх робіт та
підготовка проєкту до етапу експлуатації. Цей етап включає:
 Оцінка результатів: Аналіз того, наскільки були досягнуті цілі та задачі
проєкту;
 Підготовка до експлуатації: Передача розробленої системи до
використання та забезпечення підтримки на етапі експлуатації.
 41

 Документування результатів: Створення офіційних звітів та документації

про завершення проєкту;
 Закриття проєкту: Офіційне завершення всіх аспектів проєкту,
архівування документів.
Кожен з цих етапів важливий для успішної реалізації проєкту та досягнення
поставлених цілей. Життєвий цикл проєкту забезпечує системний та логічний підхід
до його розробки та впровадження інформаційної системи управління залишками
товарів на сторонніх платформах.

Висновки до розділу 2

У другому розділі було проведено глибокий аналіз первинних та вторинних

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

3 ПЛАНУВАННЯ ПРОЄКТУ РОЗРОБКИ ІНФОРМАЦНОЇ СИСТЕМИ

УПРАВЛІННЯ ЗАЛИШКАМИ НА СТОРОННІХ ПЛАТФОРМАХ

3.1 Планування змісту проєкту

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

залишками на сторонніх платформах використаємо Microsoft Project. Microsoft
Project – це інструмент, який забезпечує повноцінне управління проєктом розробки
інформаційної системи управління залишками на сторонніх платформах.
Зокрема, інтеграція діаграми Ганта та сітьового графіку, допоможе визначити
послідовність та залежність завдань, а також візуалізувати терміни їх реалізації.
Завдяки організаційній структурі проєкту (OBS) та матриці відповідальності можна
чітко та систематизовано спланувати трудові ресурси.
Microsoft Project також допоможе враховувати ризики та розробляти стратегії
для їх управління. Ідентифікація потенційних проблем сприяє попередженню
негативних наслідків [8].
Загалом, Microsoft Project забезпечить повний спектр інструментів для
впорядкування та керування всіма аспектами проєкту розробки інформаційної
системи управління залишками на сторонніх платформах, що робить його
ефективним вибором для цієї задачі.
У Microsoft Project створення підсумкових задач є важливою частиною
організації та контролю проєкту. Вони представляють собою вищий рівень
абстракції, об'єднуючи групу взаємозалежних завдань або етапів. Використання
підсумкових задач дозволяє створювати ієрархію завдань, полегшуючи сприйняття та
аналіз проєкту.
Підсумкові задачі групують схожі частини проєкту, роблячи його більш
структурованим та зрозумілим. Вони також полегшують контроль за прогресом,
дозволяючи вам визначити стан різних секцій або етапів, не заглиблюючись в деталі
кожного окремого завдання.
 43

Створення підсумкових задач також допомагає визначити критичні шляхи в

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

Рисунок 3.1 – Утворення підсумкових задач в рамках проєкту

Наступним кроком визначимо порядок організації задач в межах проєкту.

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

шляху дозволяє ідентифікувати послідовність завдань, що визначає тривалість всього

проєкту.
Створений ланцюг робіт та типи зв’язків для кожної задачі представленні на
рисунку 3.2.

Рисунок 3.2 – Ланцюг робіт та задач проєкту

Згідно рисунку 3.2, розробка інформаційної системи управління залишками на

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

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

ключовим кроком перед переходом до фази реалізації.
Реалізація включає в себе встановлення необхідного програмного забезпечення,
проєктування інфраструктури системи, розробку UI/UX дизайну, а також розробку
самої системи (бекенду та фронтенду). Ділянка розробки системи займає значну
частину часу проєкту та має декілька підзадач, таких як розробка CI/CD системи,
перевірка перед релізом та сам реліз системи.
Контрольна фаза охоплює період моніторингу прогресу проєкту, формування
звітності та вирішення можливих проблем, що виникають під час реалізації.
Завершальний етап включає оцінку результатів, підготовку до експлуатації,
документацію результатів та закриття проєкту.
Загалом, створення ланцюга робіт визначає порядок виконання завдань,
полегшуючи управління проєктом. Кожна з підзадач є важливою ланкою у виконанні
інтегральної мети – розробки та успішного впровадження інформаційної системи
управління залишками на сторонніх платформах.

3.2 Планування ресурсів та бюджету проєкту

Планування ресурсів в Microsoft Project є ключовим етапом управління

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

підкреслюють важливість планування ресурсів у контексті успішного виконання

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

Рисунок 3.3 – Перелік ресурсів проєкту

Згідно рисунку 3.3 до складу нашого проєкту належать трудові та матеріальні

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

Рисунок 3.4 – Призначення ресурсів

Згідно рисунку 3.4 можемо зробити висновки, що призначення ресурсів

дозволило визначити хто та коли буде виконувати завдання, контролювати та
аналізувати завантаженість ресурсів, а також ефективно бюджетувати витрати. Це
необхідно для вчасного виявлення можливих ризиків та вирішення проблем на різних
етапах проєкту.
Формування звіту про бюджет проєкту в MS Project є важливим етапом у
керуванні проєктом. Цей звіт дозволяє ретельно вивчати фінансові аспекти та
контролювати використання ресурсів. Він є ефективним інструментом для
моніторингу витрат, визначення ефективності ресурсів та прийняття рішень на основі
аналізу фактичних та планованих даних. Крім того, звіт допомагає прогнозувати
витрати, виявляти можливі ризики та можливості, а також оцінювати продуктивність
команди. Сформований звіт на основі призначених ресурсів проєкту представлений
на рисунку 3.5
 49

Рисунок 3.5 – Звіт про бюджет проєкту

Згідно рисунку 3.5 загальні вирати на реалізацію проєкту складають близько

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

3.3 Ідентифікація та аналіз ризиків проєкту

У процесі розробки інформаційної системи для управління залишками на

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

можливі труднощі та небезпеки, що можуть виникнути у ході розробки.

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

Таблиця 3.1 – Ризики проєкту

Ймовірність Вплив на
№ Найменування ризику виникнення проєкт
(0-1) (0-1)
1 Проблеми інтеграції з іншими платформами 0.2 0.8

2 Технічні збої та помилки в ПЗ 0.6 0.8

3 Затримки у формуванні команди 0.5 0.7

4 Зміни в організаційній стратегії 0.1 0.6

5 Проблеми з доступністю сторонніх платформ 0.2 0.8

6 Втрата ключових членів команди 0.1 0.6

7 Управлінський ризик 0,2 0,8

8 Нестабільне фінансування 0,2 0,6

9 Форс мажор 0,2 0,2

10 Технічний ризик 0,3 0,2

11 Хвороби членів команди 0,3 0,1

12 Зростання інфляції 0,4 0,5

Аналізуючи таблицю, можна дійти висновку, що проєкт розробки

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

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

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

Таблиця 3.2 – Аналіз ризиків проєкту

Імовірність

0.8 – 1.0

0.6 – 0.8 2

0.4 – 0.6 12 3

0.2 – 0.4 11 9, 10 8 1, 5, 7

0.0 – 0.2 6, 4

0.05 0.1 0.2 0.4 0.8

Вплив

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

проєкт. Номери ризиків, що вказані відповідно до відповідних клітин, відносяться
до номерів ризиків з таблиці 3.2. Найбільш критичні ризики знаходяться в області
високої імовірності та великого впливу (правий верхній кут). Ризики в області
низької імовірності та невеликого впливу (лівий нижній кут) можуть бути менш
критичними та потребувати менше уваги.
Таким чином, до найбільш критичні ризиків проєкту відносятся: 1 – Проблеми
інтеграції з іншими платформами, 2 – Технічні збої та помилки в ПЗ, 3 – Затримки у
 52

формуванні команди, 5 – Проблеми з доступністю сторонніх платформ, 7 –

Управлінський ризик, 8 – Нестабільне фінансування та 12 – Зростання інфляції.
Загалом, ця таблиця допомагає визначити пріоритетність управління ризиками
та визначити стратегії їх запобігання в рамках проєкту.
Заходи щодо запобігання ризиків проєкту подано в таблиці 3.3.

Таблиця 3.3 – Заходи щодо запобігання ризиків проєкту

Усунення наслідків від
Найменування Попередження ризику
ризику
№ ризику
Відпові- Відпові-
Дії Дата Дії
дальний дальний
- Ретельний Команда На фазі - Швидке Команда
аналіз розробки планування виявлення розробки
технічних проблем;
вимог - Негайна Команда
Проблеми
платформ; корекція або розробки
інтеграції з
1 - Попереднє Команда На фазі заміна
іншими
тестування розробки реалізації інтеграційних
платформами
інтеграції; рішень;
- Взаємодія з Менеджер - Взаємодія з Менеджер
постачальни- технічною
ками API для підтримкою
уточнення платформ.
деталей.
- Ретельне - Швидке
тестування виявлення та
програмного виправлення
забезпечення; помилок;
Технічні збої - Використання - Вивчення
та помилки в методів Команда На фазі причин і Команда
2
ПЗ розробки з розробки реалізації попередження розробки
високою аналогічних
якістю коду, помилок у
аудит коду; майбутньому;
-Автоматизація - Забезпечення
тестування резервних копій
Затримки у - Планування - Підтримка з
формуванні заздалегідь; На фазі команди
3 Менеджер Менеджер
команди - Вчасна інціалізації керівництва,
рекрутація; можливість
 53

- Чітке заміни членів

визначення команди;
ролей та меж - Планування
відповідальнос резервного часу
тей для адаптації
нових членів.
- Швидке
переключення
на
- Вибір
альтернативні
надійних та
рішення;
Проблеми з добре
- Вивчення
доступністю підтримуваних На фазі Команда
5 Замовник причин
сторонніх платформ; реалізації розробки
недоступності
платформ - Резервування
та складання
альтернатив-
планів
них варіантів
уникнення у
майбутньому.

- Чітке
- Проактивне
визначення Менеджер Менеджер
вирішення
цілей та
конфліктів,
завдань
виявлення та
проєкту,
вирішення
Управлінсь- - Виявлення та Менеджер На фазі
7 непорозумінь;
кий ризик управління інціалізації
- Ревізія
конфліктами в Менеджер
стратегій та
команді;
планів проєкту;
- Проведення Замовник
-Наймання
сертифікації Замовник
консультанта
менеджера
- Пошук Замовник
- Резервування
додаткових
коштів у
джерел
бюджеті
фінансування;
проєкту;
- Перегляд Менеджер
- Періодична
бюджетних
оцінка
Нестабільне На фазі планів,
8 фінансового Менеджер
фінансування планування оптимізація
стану проєкту;
витрат;
- Ретельне
- Використання
фінансове
резерву
планування,
бюджету;
розробка
- Призупинення
альтернативни
проєкту Замовник
 54

х фінансових
стратегій
- Перегляд Менеджер
бюджету та
-Постійний
внесення змін в
моніторинг Кожен
управлінські
рівня інфляції; день
Зростання рішення
12 -Резервування Менеджер
інфляції відповідно до
коштів у На фазі
нових умов;
бюджеті планування
- Призупинення Замовник
проєкту
проєкту

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

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

3.4 Планування якості проєкту

Планування якості проєкту є важливим етапом управління, спрямованим на

забезпечення високої якості виготовленого продукту чи послуги. Цей процес включає
визначення вимог до якості, розробку плану якості, визначення метрик та критеріїв
якості, планування контролю якості, управління змінами та взаємодію з
зацікавленими сторонами.
Визначення вимог до якості включає розуміння очікувань зацікавлених сторін
та встановлення конкретних вимог до продукту чи послуги. На основі цього
визначається план якості, що включає в себе методи вимірювання якості, процеси
контролю та відповідальних за них учасників, а також план тестування.
Визначення метрик якості включає конкретні критерії вимірювання успішності
проєкту, а планування контролю якості визначає етапи контролю під час виконання
проєкту. Крім того, важливим етапом є залучення зацікавлених сторін та планування
управління змінами для забезпечення високої якості під час всього процесу
виконання.
Планування якості сприяє виконанню проєкту відповідно до вимог та
досягненню визначених цілей якості. Це допомагає уникнути непередбачених
проблем та забезпечує задоволення клієнтів чи користувачів від кінцевого результату.
Agile методологія, така як Scrum, є ідеальним вибором для проєкту. Це
пов'язано з тим, що Scrum надає можливість гнучко реагувати на зміни та визначати
пріоритети в процесі розробки. Очікується, що потреби користувачів та вимоги до
інформаційної системи будуть еволюціонувати, тому Agile дозволить швидко
адаптуватися до нових обставин. Для відстеження та керування проєктом можна буде
використовувати такі інструменти, як Jira для управління задачами та Trello для
візуалізації процесу.
Scrum включає ряд практик та ролей, які впливають на якість виробленого
продукту. У Scrum якість визначається не тільки технічними аспектами, але і
вимогами користувачів. Кожен спринт в Scrum завершується готовим до
використання прирістом продукту, що дозволяє забезпечити постійний контроль та
 56

оцінку якості. Крім того, в Scrum передбачені регулярні ретроспективи, на яких

команда може аналізувати свою роботу та визначати можливості для поліпшення,
включаючи аспекти якості.
Багато Scrum-команд також використовують техніки тестування,
автоматизоване тестування, практики постійної інтеграції та інші методи для
забезпечення високої якості продукту. Scrum надає каркас, в межах якого команди
можуть організовувати свою роботу для досягнення високого рівня якості
виробленого продукту [9].
Складемо план реалізації проєкту відповідно до обраної Agile методології
Scrum:
 Спринти: Розпочати ітеративну розробку в спринтах тривалістю 2 тижні, де
кожен спринт визначає пріоритетні задачі та завдання;
 Backlog: Створити Product Backlog і Sprint Backlog для ефективного
планування та відстеження задач;
 Спринт-планування: Проводити щотижневі спринт-планування для
визначення завдань на наступний спринт;
 Щотиженві мітинги: Проводити щотижневі онлайн-конференції для
відстеження прогресу та вирішення проблем;
 Спринт-ретроспективи: Проводити спринт-ретроспективи для аналізу та
покращення процесу розробки;
 Демонстрація та оцінка: Проводити демонстрації виконаних робіт
користувачам та отримувати їх відгуки для подальших вдосконалень;
 Завершення проєкту: По завершенні всіх спринтів випустити продукт у
відкритий доступ і продовжити його підтримку та розвиток.
Цей план дозволить ефективно розробляти та впроваджувати продукт,
забезпечуючи високу якість та відповідність потребам користувачів.
У ході планування якості проєкту, наступним кроком, визначимо історії
користувачів системи. Історії користувачів (user stories) важливі для визначення
функціональності системи та вимог до неї з точки зору різних ролей користувачів.
 57

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

залишками на сторонніх платформах (таблиця 3.4).

Таблиця 3.4 – Історії користувачів

Користувач User stories
 Як адміністратор, я хочу мати можливість створення та
управління акаунтами користувачів для забезпечення безпеки
Адміністратор доступу до системи;
 Як адміністратор, я хочу мати повний доступ до усього
функціоналу керування асортиметом та пошуку продукції.
 Як менеджер, я хочу мати можливість додавати, видаляти та
оновлювати існуючі товари системи, щоб керувати
асортиментом;
 Як менеджер, я хочу мати можливість встановлювати правила
здешевлювання товарів в залежності від платформи;
 Як менеджер, я хочу бачити зведену статистику залишків, щоб
моніторити обсяги товарів на складі;
Менеджер
 Як менеджер, я хочу мати можливість швидкого та зручного
пошуку товарів;
 Як менеджер, я хочу створювати CSV/EXCEL файли з
інформацією про товари для подальшого завантаження їх на
платформах;
 Як менеджер, я хочу отримувати актуальну інформацію про
виконання замовлень для вчасного реагування на зміни.

Таким чином, планування якості включає виділення основного функціоналу,

який має забезпечувати система. Враховуючи історії користувачів, зазнечені у
таблиці 3.5, складемо перелік завдань для реалізації інформаційної системи
управління залишками товарів на сторонніх платформах:
1. Створення товару на eBay з використанням інформаційної системи:
 Реалізація функції створення товару на eBay на основі даних із
інформаційної системи. Під час створення товару на eBay необхідно
зберігати інформацію про товар до інформаційної системи, включаючи
такі поля, як залишки, опис, назва товару та ціна;
 Функція порівняння товарів в інформаційній системі та на сторонніх
платформах, аналіз невідповідності даних.
 58

2. Видалення товару зі сторонніх платформ з використанням інформаційної

системи:
 Реалізація функції видалення товару з eBay на основі даних із
інформаційної системи. При видаленні товару зі сторонніх платформ
також необхідно видаляти інформацію про товар із інформаційної
системи (Змінити інформацію про товар у інформаційній системі);
 Зміна полів товару на eBay з використанням інформаційної системи:
Реалізація функції зміни полів товару на eBay на основі даних із
інформаційної системи. Змінювані поля товару на eBay включають:
залишки, опис, назва товару та ціна (+ поля шаблону CSV);
3. Зміна полів товару в інформаційній системі з використанням eBay:
 Реалізація функції зміни полів товару в інформаційній системі на основі
даних зі сторонніх платформ. Змінювані поля товару в інформаційній
системі включають: залишки, опис і назва товару (+ поля шаблону CSV,
з можливістю налаштування відображення чи приховування полів при
роботі з інформаційною системою).
4. Отримання інформації про замовлення та замовників в інформаційній
системі, які замовили товар на сторонніх платформах:
 Реалізація функції отримання інформації про замовників в інформаційній
системі, які здійснили замовлення на eBay. Отримані дані повинні
містити інформацію про замовників, таку як ім'я, адреса, контактні дані
тощо.
5. Управління зображеннями:
 Проміжний сервіс повинен надавати функціонал для збереження,
видалення та отримання зображень для подальшого завантаження на
сторонні платформи. Якщо існує можливість зробити з мережевого
сховища зображень сховище з доступом до зображень через URL,
призначений кожному зображенню);
 59

 Зображення повинні зберігатися в певній структурі папок, де кожне

зображення матиме своє ім'я. Можливо використання наступного
формату для зберігання зображень: {ім'я_папки}/{ім'я_зображення}.
6. CSV/EXCEL парсер/білдер:
 Проміжний сервіс повинен підтримувати функціонал парсингу та
створення CSV/EXCEL файлів;
 Функціонал парсингу повинен дозволяти завантажувати існуючі товари з
eBay в інформаційній системі;
 Функціонал створення CSV/EXCEL файлів повинен дозволяти
формувати файли для експорту даних з інформаційної системи.
7. Зниження ціни товару в залежності від платформи:
 Проміжний сервіс повинен надавати можливість встановлення різних цін
для товарів в залежності від платформи. Зниження з вибором інтервалів
цін, категорій, комбіноване. Можливість гнучкої налаштування
параметрів зниження. Для кожної платформи повинні бути визначені
відповідні ціни та правила зниження товарів.
8. Реалізація пошуку по інформаційній системі:
 Проміжний сервіс повинен забезпечувати функціонал пошуку товарів в
інформаційній системі за різними параметрами: категоріями, артикулом,
назвою товару, описом товару.
9. Забезпечення безпеки, масштабованості та продуктивності:
 Проміжний сервіс повинен забезпечувати захист передачі даних між eBay
та інформаційною системою;
 Забезпечення безпеки доступу до сервісу, включаючи аутентифікацію та
авторизацію;
 База даних PostgreSQL повинна бути належно масштабованою для
ефективної роботи з обробкою великого обсягу даних;
 Проміжний сервіс повинен бути готовий до горизонтального та
вертикального масштабування;
 60

 База данних повинна забезпечувати високу продуктивність при операціях

зчитування та запису даних;
 Код сервісу повинен бути оптимізований для швидкості виконання та
ефективного використання ресурсів.
10. Забезпечення обробки помилок та логування:
 Реалізація обробки та логування помилок для забезпечення відновлення
після неполадок;
 Забезпечення зручного моніторингу сервісу через системи логування.
На основі вищеперелічених завдань до реалізації інформаційної системи
управління залишками на строронніх платформах розробимо основні функції, що
вона має забезбечувати (таблиця 3.5).

Таблиця 3.5 – Основна функціональність системи

№ Функція Критерії

PRODUCTS

1 save products (*) save as butch (one product should save as

collection singleton)

2 get all products with pagination (*) main page

get all products by category with pagination (*) category page

3 get product by id (*)

4 update product by id (*) update exist product

5 delete product by ids delete exist products

6 delete product by categories delete exist products

7 get all products by dataTime update history activities page

(ASC/DESC) with pagination.

PRODUCT HISTORY (LOG INFO)

1 get product log info by product id changing product details (with data time):
 price (discount)
 title
 count etc.

CATEGORIES
 61

1 add providers categories

2 update categories

3 delete outdated categories (with or without products)

IMAGES

1 get images by product ids

2 get images by ids

3 delete images by ids

4 load images using butch save

CSV PARSER (BUILDER)

1 load CSV (from providers)

2 preview CSV product details

3 build CSV for providers

SEARCH

1 Search products by: elastic search can be used

 AND/OR title
 AND/OR description
 AND/OR category name
 AND/OR articul

FILTER

1 Filter products by:

 title
 articul
 price
 count

ADDITIONAL INFO

1 get actual eBay endpoints with the last call time

CHEAPENING GOODS

1 global cheapening action/update (providers

resources/shop resources)

Отже, функціональність проміжного сервісу включає:

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

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

системи, зміна полів товарів (залишки, опис, назва товару, ціна) на сторонніх
платформах за допомогою інформаційної системи, зміна полів товарів
(залишки, опис, назва товару) в інформаційній системі за допомогою
сторонніх платформ, отримання інформації про замовників в інформаційній
системі, які замовили товар на сторонніх платформах.
2. Управління зображеннями включає збереження, видалення та отримання
зображень для подальшого завантаження на eBay в форматі
{ім'я_папки}/{ім'я_зображення}.
3. CSV/EXCEL парсер/білдер забезпечує парсинг існуючих товарів із
сторонніх платформ в інформаційній системі, створення CSV/EXCEL файлів
для експорту даних з інформаційної системи.
4. Здешевлення товару в залежності від площадки забезпечує можливість
встановлення різних цін для товарів відповідно до платформи (з
урахуванням інтервалів цін, категорій та гнучкої настройки параметрів).
5. Пошук в інформаційній системі забезпечує пошук товарів за різними
параметрами, такими як категорія, артикул, назва товару та опис.
Визначення ролей користувачів системи у контексті планування якості
проєкту є важливою складовою процесу забезпечення якості в розробці і
впровадженні інформаційної системи (таблиця 3.6). До переліку ключових
аспектів, які розкривають важливість визначення ролей користувачів у цьому
контексті можна віднести наступні:
 Спрямованість на потреби користувачів: Визначення ролей користувачів
допомагає розуміти різноманітні потреби та очікування різних груп
користувачів. Забезпечення якості означає відповідність системи
потребам користувачів, і визначення ролей допомагає зосередитися на
конкретних аспектах їхнього взаємодії з системою;
 Тестування відповідності функціональності: Ролі користувачів
визначають, які функції системи будуть використовуватися різними
 63

користувачами. Під час тестування можна перевірити, чи задовольняє

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

Таблиця 3.6 – Ролі користувачів системи

Роль Права доступу Опис

PRODUCTS | * full access

CSV PARSER | BUILDER | * full access
IMAGES | * full access
SEARCH | * full access Повний доступ до усього
ADMIN
ADDITIONAL INFO| * full access фунціоналу системи
CHEAPENING GOODS | * full access
PROVIDERS | * full access
USERS | * full access

PRODUCTS | * full access

CSV PARSER | BUILDER | * full access
Повний доступ до усього
IMAGES | * full access
фунціоналу системи, пов’язаного
SEARCH | * full access
MANAGER з управлінням залишками на
ADDITIONAL INFO| * full access
сторонніх платформах, тільки
CHEAPENING GOODS | * full access
читання користувачів
PROVIDERS | * read only
USERS | * read only

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

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

Висновки до розділу 3

У третьому розділі було проведено детальний аналіз і розробку стратегічних

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

розробки інформаційної системи та послідовність їх виконання, що забезпечить

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

4 ПРАКТИЧНА РЕАЛІЗАЦІЯ ПРОДУКТУ ПРОЄКТУ

4.1 Структурно-функціональне моделювання процесу розробки

інформаційної системи управління залишками на сторонніх
платформах

Моделювання процесу роботи представляє собою відтворення особистого

сприйняття послідовності операцій у формі формальної моделі, яка включає в себе
взаємопов'язані операції [10]. Проведемо моделювання процесу роботи
інформаційної системи управління залишками на сторонніх платформах. Спочатку
розробимо модель функціонування системи, використовуючи структурний підхід
заснований на стандарті IDEF0.
На рівні A0 весь процес розглядається як функціональний блок, де
інформаційна система взаємодіє з зовнішнім середовищем та виконує основну
функцію – управління залишками компанії на сторонніх платформах. Контекстна
модель системи зображена на рисунку 4.1.

Інформація Інтеграція зі
Правила та
у базі сторонніми
процедури
даних платформами
Дані користувача Синхронізовані дані про
Управління залишками на сторонніх залишки
Дані платформи платформах

Інформаційна Користувач Платформа

система

Рисунок 4.1 – Контекстна модель системи

Наведена контекстна модель дозволяє узагальнено розглядати інформаційну

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

Модель декомпозиції для інформаційної системи управління залишками на

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

Інформація у базі данних

Авторизація Правила та процедури

Пошук Інтеграція з платформами

товару
Перегляд
товару
Оновлення
Дані користувача інформації
про товар
Дані платформи
Синхронізація
даних про товар
Інформаційна система на платформах

Рисунок 4.2 – Модель декомпозиції системи

Кожен компонент в системі має визначені функціональні властивості та

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

Цільові аспекти дослідження випадків використання можуть включати

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

Таблиця 4.1 – Опис акторів системи

Назва Опис
Користувач, що має можливості управління залишками
на сторонніх платформах, завантаження та формування
Менеджер
CSV/EXCEL-файлів, перегляд інформації про
замовлення та клієнтів
Користувач з найбільшими можливостями у системі,
Адміністратор окрім основного фунціоналу, має змогу управління
користувачами та налаштування параметрів платформ

Ця таблиця надає огляд ключових акторів у системі, їхніх ролей та основних

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

Таблиця 4.2 – Опис варінтів використання системи

Назва Опис
Авторизація Функція входу в систему
Редагування персональних данних Можливість редагування особистої інформації
Адмінстратор має можливість управління
CRUD-операції з користувачем
користувачами
Адміністратор має можливість налаштування
Редагування параметрів платформи правил здешевлення товарів для кожної
платформи
Функція пошуку, фільтрації та сортування
Пошук товару
товарів
Можливість перегляду, редагування, додавання
CRUD-операції з товаром
та видалення товарів
Адміністратор має можливість редагувати
Редагування загального шаблону опису товару глобальний шаблон, відповідно до якого
формується опис товару
Функція пошуку, фільтрації та сортування
Пошук замовлення
замовлень
Можливість перегляду інформації про
Перегляд замовлення
замовлення
Можливість додавання нових товарів шляхом
Завантаження CSV/EXCEL-файлів завантаження CSV/EXCEL-файлів з
відповідними данними
Можливість формування CSV/EXCEL-файлів
Вивантаження CSV/EXCEL-файлів
на основі данних про існуючі або нові товари
Функція оновлення та синхронізації данних зі
Міграція даних
стороніми платформами та системою
Функція пошуку, фільтрації та сортування
Пошук категорій
категорій
Можливість переглядати історію ціни певного
Перегляд цінової історії
товару

У наведеній таблиці описані різноманітні варіанти використання системи, що

включають різні функціональні можливості та операції. Кожен варіант використання
 69

спрямований на забезпечення ефективної та зручної роботи з системою управління

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

Рисунок 4.3 – Модель прецедентів системи

Моделювання діаграм діяльності в інформаційній системі управління

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

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

що розробляється.

Рисунок 4.4 – Діаграма діяльності авторизації

Рисунок 4.5 – Діаграма діяльності оновлення інформації про залишки

 71

Рисунок 4.6 – Діаграма діяльності пошуку інформації

Рисунок 4.7 – Діаграма діяльності завантаження CSV/EXCEL-файлу

 72

4.2 Опис реалізації інформаційної системи управління залишками на

сторонніх платформах

Структура бази даних інформаційної системи управління залишками має

важливе значення у процесі розробки проєкту. Вона служить основою для організації
та зберігання інформації про запаси, замовлення, клієнтів та інші аспекти системи. Ця
структура не лише допомагає забезпечити легкий доступ до даних, але й сприяє їхній
інтеграції з іншими системами.
Правильно спроєктована база даних визначає формат та спосіб зберігання
даних, забезпечуючи їхню безпеку та оптимізацію продуктивності. Розробка цієї
структури є важливим етапом, який сприяє ефективній реалізації функціоналу
системи та готовності до майбутніх змін та розширень. Визначимо сутності та їх
атрибути для нашої системи (рисунок 4.8).
Наступним кроком інтегруємо комунікацію з платформою eBay у нашу
систему. eBay API – це набір інтерфейсів програмування застосунків, які надають
доступ до різноманітних сервісів та функцій платформи eBay. Цей API дозволяє
розробникам інтегрувати функціональність eBay в свої додатки, щоб отримати доступ
до даних про товари, управляти замовленнями, отримувати інформацію про
користувачів та багато іншого.
Для нових розробок eBay наполегливо заохочує використання RESTful API.
Ключовою перевагою REST є те, що він використовує меншу пропускну здатність і
підтримує кілька форматів, включаючи простий текст, XML, HTML і JSON, тоді як
SOAP підтримує лише XML [11]. Розглянемо основні можливості, які надає RESTful
API (рисунок 4.9).
Тепер розглянемо Sell APIs, оскільки вони дозволять інтегрувати функціонал з
продажу на eBay безпосередньо до нашої системи. eBay Sell API – це RESTful API,
які використовують автентифікацію OAuth, корисні дані JSON і HTTP-заголовки
eBay.
 73

Рисунок 4.8 – Структура бази данних системи

RESTful API

Buy APIs — Sell APIs — Commerce APIs —

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

Рисунок 4.9 – Можливості RESTful API

 74

Проаналізуємо схему, зображену на рисунку 4.10, де описано, основні етапи

інтеграції Sell APIs до інформаційної системи управдіння залишками на платформі
eBay.

Додаток для продажу на eBay

Конфігурація акаунту продавця на eBay Конфігурація акаунту продавця на eBay

Account API Metadata API

 Отримання статус облікового запису
та лімітів продажу;
 Створення та налаштування політики
продажу (оплати, виконання,
повернення);
 Налаштування способів доставки.
 Отримання категорій для товарних
пропозицій;
 Отримання правил лістингу для
окремої категорії;
 Отримання ідентифікаторів стану
товарів та їх назви.

Управління запасами та пропозиціями Обробка замовлень

Inventory API та Media API Fulfillment API та Feed API

 Керування товарними запасами та
пропозиціями;
 Зіставлення асортименту з
продуктами в каталозі;
 Створення груп товарів та керування
ними;
 Керування медіа (створення та
завантаження) для просування
асортименту продавця;
 Перевірка запасів у реальному часі.
 Перевірка замовлень;
 Упраління доставкою та виконанням
замовлень;
 Робота з каналами замовлень;
 Виявлення та обробка невиконаних
замовлень.

Аналіз роботи продавця

API Analytics
 Отримання звітів про трафік покупців;
 Отримання звітів про показники обслуговування клієнтів;
 Взаємодія зі службами репутації eBay.

Рисунок 4.10 – Схема додатку для продажу на платформі eBay

Усі REST-запити eBay містять стандартний набір компонентів виклику.

Частини запиту REST включають наступне:
 75

 HTTP заголовки (необхідно надати набір заголовків HTTP, під час надсилання
запиту, спеціальні заголовки eBay починаються з « X-EBAY-C-»);
 Операція REST (або кінцева точка);
 Корисне навантаження запиту (або тіло запиту, як того вимагає операція);
Деякі спеціальні заголовки eBay можуть містити кілька пар ім’я/значення.
Формат пари ім’я/значення – <name>=<value>, кілька значень в одному заголовку
необхідно розділяти комами. У наступному прикладі показано загальний формат:
X-EBAY-C-PACKED-EXAMPLE: fig=7,bar=«quux»,value=42
У таблиці 4.3 представлено стандартні заголовки запитів, які приймає eBay, а
також спеціальні заголовки eBay, які використовуються за потребою.
Таблиця 4.3 – Стандартні заголовки запитів до eBay
Заголовок HTTP Необхідність Опис
Accept вказує формати, які клієнт
приймає для відповіді.
Accept Умовно необхідний JSON є стандартним і єдиним форматом,
який повертається в тілах відповіді.
приклад:
Accept: application/json
Authorization визначає маркер OAuth і тип
маркера, які використовуються для
Authorization Необхідний авторизації запиту.
приклад:
Authorization: Bearer <accessToken>
Content-Type вказує формат тіла запиту,
Content-Type Умовно необхідний наданий клієнтом.
приклад:
Content-Type: application/json
Content-Language визначає мову, яка
використовуватиметься в полях корисного
Content-Language Умовно необхідний навантаження запиту.
приклад:
Content-Language: en-US

На основі вище зазначеної інформації побудуємо WebClient для виконання

запитів до eBay API (рисунок 4.11).
 76

this.webClient = webClientBuilder
.baseUrl(url)
.defaultHeader("Authorization", "Bearer " + Token.getEbayToken())
.defaultHeader("Accept", "application/json")
.defaultHeader("Content-Type", "application/json")
.defaultHeader("Content-Language", "de-DE")
.filter(getFilter())
.build();
Рисунок 4.11 – WebClient для виконання запитів до eBay API

Цей фрагмент коду використовує бібліотеку Spring WebClient для здійснення

HTTP-запитів до веб-сервісу eBay. Проаналізуємо код більш детально:
 this.webClient = webClientBuilder: Вказує на те, що webClient буде
ініціалізовано за допомогою webClientBuilder.
 .baseUrl(url): Встановлює базовий URL для всіх HTTP-запитів, які будуть
виконані за допомогою webClient. url тут є змінною і в данному випадку
відповідає значенню https://api.ebay.com.
 .defaultHeader("Authorization", "Bearer " + Token.getEbayToken()): Додає
HTTP-заголовок Authorization з токеном доступу, отриманим від eBay.
Використання токену у заголовку Authorization дозволяє автентифікувати
запити до eBay API.
 .defaultHeader("Accept", "application/json"): Вказує, що клієнт очікує
отримати відповідь у форматі JSON.
 .defaultHeader("Content-Type", "application/json"): Встановлює тип вмісту
запиту як JSON, що вказує на те, що дані, надіслані в тілі запиту, будуть у
форматі JSON.
 .defaultHeader("Content-Language", "de-DE"): Встановлює мову вмісту на
німецьку (de-DE). Цей заголовок вказує на те, що передані дані або очікувані
відповіді можуть бути вказані німецькою мовою.
 .filter(getFilter()): Додає фільтр до клієнта. Фільтри можна використовувати
для зміни або доповнення поведінки WebClient. У данному випадку
створений фільтр займається обробкою відповідей від сервера. Якщо
отримана відповідь має статус UNAUTHORIZED (401), фільтр викликає
 77

обробник, який генерує помилку TokenExpiredException, що у свою чергу

викличе оновлення застрарілого токену доступу та повторення виклику
запиту.
 .build(): Завершує конфігурацію webClient і повертає готовий до
використання клієнт.
Весь цей код призначений для налаштування і створення webClient, який
використовуватиметься для взаємодії з веб-сервісом eBay.
Процес отримання інформації про товари зі сторонніх API є необхідною
функцією для міграції вже існуючих данних до розроблюваної інформаційної системи
управління запасами, а також для оновлення існуючих товарів, що були зміненні
безпосередньо на сторонніх платформах для забезпечення актуальності та
узгодженості даних.
Щоб отримати інформацію про товари, розміщені на сторонніх платформах,
використовується веб-клієнт для взаємодії з API цих платформ. Проаналізуємо код,
що відповідає за отримання товарів з eBay (рисунок 4.12).

InventoryItemsResp inventoryItemsResp = webClient.get().uri(uriBuilder -> uriBuilder

.path(INVENTORY_PATH)
.queryParam("limit", limit)
.queryParam("offset", offset)
.build())
.retrieve()
.bodyToMono(InventoryItemsResp.class)
.block();

if (inventoryItemsResp == null || inventoryItemsResp.getInventoryItems() == null) {

return;
}
List<InventoryItem> inventoryItems = inventoryItemsResp.getInventoryItems();

inventoryItems.forEach(
inventoryItem -> {
Part part = partMapper.toEntity(inventoryItem,
getOfferBySku(inventoryItem.getSku()));
parts.add(part);
}
);
Рисунок 4.12 – Отримання інформації про розміщенні товари
 78

Здійснення HTTP GET-запит відбувається за вказаним шляхом

(INVENTORY_PATH) і параметрами (limit, offset) до API сторонньої платформи,
використовуючи веб-клієнт.
Отримана відповідь в форматі JSON конвертується в об'єкт класу
InventoryItemsResp, який містить інформацію про товари інвентарю. Далі
перевіряється, чи отримано коректну відповідь, і чи наявні товари в об’єкті відповіді.
Якщо інформація про товари присутня, для кожного товару викликається
функція partMapper.toEntity(..), яка перетворює об'єкт InventoryItem в об'єкт класу
Part, використовуючи дані пропозиції цього товару, отримані, за допомогою функції
getOfferBySku за SKU товару, для зведення інформації про товари з різних платформ
до спільного об’єкту.
Цей процес дозволяє отримати та обробляти інформацію про товари зі
сторонніх платформ для подальшого використання в інформаційній системі.
Щоб отримати інформацію про категорії товарів на сторонніх платформах,
використовується веб-клієнт для взаємодії з API цих платформ. Розглянемо код для
отримання списку категорій на eBay зображеного на рисунку 4.13.

String requestBodyXml =
requestBodyXmlBuilder.buildCategoriesRequestBody(Token.getEbayToken());

String xmlCategories = webClient.post()

.uri(CATEGORIES_PATH)
.body(BodyInserters.fromValue(requestBodyXml))
.accept(MediaType.TEXT_XML)
.retrieve()
.bodyToMono(String.class)
.block();

categories.addAll(categoryMapper.toEntities(
categoryXmlParser.parse(xmlCategories)
));
Рисунок 4.13 – Отримання інформації про категорії

На рисунку 4.13 описаний процес створення XML-запиту, який буде

відправлений до API сторонньої платформи для отримання інформації про категорії
товарів. Для цього використовується клас requestBodyXmlBuilder, який будує тіло
запиту, включаючи необхідний токен для автентифікації. Далі здійснюється POST-
 79

запит за вказаним шляхом (CATEGORIES_PATH) і тілом запиту в форматі XML,

використовуючи веб-клієнт. Заголовок accept вказує, що очікується відповідь у
форматі XML.
Отримана відповідь зберігається в змінну xmlCategories та застосовується
парсер, який аналізує XML-відповідь та перетворює її у зведені об'єкти категорій, що
дозволяє отримувати та обробляти зведену інформацію про категорії товарів зі
сторонніх платформ для подальшої роботи з ними.
Щоб оновити інформацію про існуючий товар на сторонніх платформах або
створити новий використовується транзакція, що зберігає товар у базі даних та на
сторонніх платформах. Код, представлений на рисунку 4.14, реалізує процес
збереження товару на сторонній платформі.

InventoryItem inventoryItem = partMapper.toInventoryItem(part);

saveInventoryItem(inventoryItem);

Offer offer = partMapper.toOffer(part);

Offer existsOffer = getOfferBySku(offer.getSku());
if (existsOffer == null) {
String newOfferId = saveOffer(offer);
publishOffer(newOfferId);
return;
}
updateOffer(offer, existsOffer.getOfferId());
publishOffer(existsOffer.getOfferId());

Рисунок 4.14 – Збереження та оновлення інформації про товар

Спочатку створюється об'єкт InventoryItem та Offer за допомогою спеціальних

маперів. Далі відбувається збереження InventoryItem за допомогою методу
saveInventoryItem. Перевіряється чи існує вже такий Offer за допомогою
getOfferBySku: якщо Offer не існує, викликається метод saveOffer, який створює
новий Offer та викликає метод publishOffer для його публікації. Якщо Offer існує,
викликається метод update для оновлення існуючого Offer та метод publishOffer для
його публікації.
 80

Цей процес дозволяє зберігати та оновлювати інформацію про товари на

сторонніх платформах, забезпечуючи актуальність даних та їх відображення в
інформаційній системі.
Збереження нових товарів також можливе шляхом завантаження CSV/EXCEL-
файлу з данними про товар. Ця операція включає зчитування данних з файлу в
залежності від типу та транзакції збереження товару в системі та на платформах.
Щоб видалити товар на сторонніх платформах, використовується HTTP-запит
DELETE до відповідного ресурсу за допомогою веб-клієнта. Ось як це відбувається
на прикладі коду зображеного на рисунку 4.15.

webClient.delete().uri(uriBuilder -> uriBuilder

.path(INVENTORY_PATH + "/{SKU}")
.build(sku)
).retrieve()
.onStatus(HttpStatus.NOT_FOUND::equals,
response ->
response.bodyToMono(String.class).map(NotFoundException::new))
.toBodilessEntity()
.block()
Рисунок 4.15 – Видалення товару

У представленому коді здійснюється HTTP DELETE-запит до ресурсу,

вказаного у шляху (INVENTORY_PATH + "/{SKU}"), де {SKU} підставляється
конкретним значенням SKU товару. Далі використовується метод retrieve(), який
ініціює відправку запиту та отримання відповіді. Обробляється статус відповіді за
допомогою методу onStatus. У випадку, якщо отримано статус NOT_FOUND,
викликається обробник response.bodyToMono(..).map(NotFoundException::new), який
перетворює тіло відповіді на об'єкт класу NotFoundException та генерує виключення.
Використання toBodilessEntity() обумовлене тим, що видалення товару не
повертає тіло відповіді, а метод block() – для очікування завершення виконання
запиту та отримання результату. Таким чином процес забезпечує видалення товарів
на сторонніх платформах.
 81

Пошук товарів в інформаційній системі реалізований з можливістю гнучкої

фільтрації та сортування данних. Розглянемо функцію, що відповідальна за пошук
товарів відповідно до введених параметрів (рисунок 4.16).
Цей код є методом у сервісному класі продукту, який відповідає за отримання
списку частин (parts) з бази даних з урахуванням різних параметрів, таких як номер
сторінки, обмеження кількості елементів на сторінці, фільтри, та сортування.
Основні етапи методу:
 Створення об'єкту Pageable, який використовується для задання параметрів
сторінкування та сортування при отриманні даних з бази даних.
 За допомогою об'єктів generatorQueryParams генеруються параметри
сортування (sort) та фільтрації (criteria) на основі вхідних списків sorts та
filters.
 Якщо переданий параметр carUuid не є null, то отримується ідентифікатор
автомобіля (carId) за допомогою репозиторію. Далі, до існуючих критеріїв
(criteria) додається умова для фільтрації за ідентифікатором автомобіля.
 Застосовуючи параметри сортування, сторінкування та фільтрації,
виконується запит до бази даних за допомогою jdbcAggregateTemplate.
Результат отримується у вигляді списку об'єктів продукції.
 Застосовуючи ті ж параметри, обчислюється загальна кількість записів, що
задовольняють умовам фільтрації.
 Використовуючи pageMapper та partMapper, результат перетворюється в
об'єкт сторніки, який містить список частин для поточної сторінки та
загальну кількість записів.
 82

public PageDto<PartRespDto> getAll(String carUuid, int page, int limit,

List<PartFilterDto> filters, List<PartSortDto> sorts) {
Pageable pageable = PageRequest.of(page, limit);

Sort sort = generatorQueryParams.generatePartSort(sorts);

Criteria criteria = generatorQueryParams.generatePartCriteria(filters);

if (carUuid != null) {
long carId = carRepository.findFirstByUuid(carUuid)
.map(Car::getId)
.orElseThrow(
() -> new NotFoundException("Not found Car by uuid:
%s ".formatted(carUuid))
);

criteria = criteria.and(Criteria.where("car_id").is(carId));
}

List<Part> parts = IterableUtils.toList(

jdbcAggregateTemplate.findAll(Query.query(criteria).sort(sort).limit(limit).
offset(pageable.getOffset()), Part.class)
);
long count = jdbcAggregateTemplate.count(Query.query(criteria),
Part.class);

return pageMapper.toDto(
new PageImpl<>(partMapper.toDtos(parts), pageable, count)
);
}
Рисунок 4.16 – Функція параметризованого пошуку товарів

Отже, даний метод дозволяє ефективно отримувати товари, враховуючи

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

4.3 Аналіз отриманих результатів

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

можливість авторизуватися. Доступ до усього функціоналу сайту мають лише
авторизовані користувачі. Після авторизації відкривається сторінка зі списком
продукції компанії (рисунок 4.17).
 83

Рисунок 4.17 – Сторінка зі списком продукції

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

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

Рисунок 4.18 – Сторінка редагування інформації

 84

Обрати автомобіль також можна використовуючи список, де вони групуються

спочатку за іменем, потім за моделлю та додатковою інформацією (рисунок 4.19).
Представлення автомобіля у цьому випадку здіснюється шляхом формування
специфічного імені, що включає наступні компоненти:
 Абревіатура назви автомобіля та моделі автомобіля, встановлюється вручну
під час створення автомобіля (в даному прикладі TL – Toyota Auris);
 Останні цифри року «erstzulassung» або «modelljahr» (у цьому прикладі рік
erstzulassung – 2023), встановлюються автоматично під час створення запису
про автомобіль. Цей двозначний номер використовується також в
зовнішньому id продукта (деталі), який належить автомобілю (наприклад,
23.001.002);
 Внутрішній номер автомобіля.

Рисунок 4.19 – Вибір машини за списком

Після вибору автомобіля, користувач потрапляє на сторінку редагування

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

Рисунок 4.20 – Редагування інформації про автомобіль

При натисканні на кнопку «Part», корисувач переходить на сторінку додавання

нового продукту на сторонні платформи (рисунок 4.21). Тут реалізована можливість
вибру автомобіля, якому належить продукт (деталь) та автоматичного формування
заголовку продукту згідно з певним шаблоном зазначеним на рисунку 4.22. Також,
справа від поля введення даних про продукт автоматично формується повний його
опис у вигляді html на основі зазначеної товарної інформації та данних про машину.
Користувач має можливість, також, завантажити зображення продукту та
налаштувати специфічні параметри для кожної платфоми, на яку буде додаватися
продукт: політики доставки, місця знаходження оплати та повернення, а також
специфічний заголовок і знижка.
 86

Рисунок 4.21 – Редагування інформації про автомобіль

Рисунок 4.22 – Схема формування заголовку продукту

При натисканні на кнопку «Додавання кастомних слів до категорій» до

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

Рисунок 4.23 – Вікно додаткових налаштувань категорій

Тепер під час пошуку цієї категорії буде доступний за вказаним переліком
ключових слів (рисунок 4.24).

Рисунок 4.24 – Пошук категорій за ключовими словами

Користувачу доступна також можливість одночасного пошуку товарів за

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

Висновки до розділу 4

У четвертому розділі було виконано розробку інформаційної системи

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

зрозуміти загальну архітектуру проєкту. Опис реалізації інформаційної системи

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

ВИСНОВКИ

У даній кваліфікаційній роботі було розглянуто та розроблено інформаційну

систему управління залишками компанії на сторонніх платформах. Проєкт включав в
себе ретельний аналіз вимог та очікувань від різних зацікавлених сторін, визначення
місії та цілей проєкту, а також визначення стратегічних та технічних аспектів
реалізації системи.
Другий розділ кваліфікаційній роботи присвячений розробці концепції проєкту.
Визначені первинні та вторинні зацікавлені сторони, здійснений аналіз їх впливу на
проєкт, розроблено дерево цілей організації, визначено місію та конкретні цілі
проєкту. Такий підхід дозволяє враховувати широкий спектр вимог та гарантує
вироблення стратегії, яка відповідає потребам усіх учасників.
Структура продукту проєкту була ретельно пророблена, а очікувані результати
проєкту визначені з урахуванням не тільки технічних аспектів, але й стратегічних
переваг для компанії. Велика увага була приділена визначенню життєвого циклу
проєкту, з виділенням ключових віх та етапів від початкової ініціалізації до
завершення проєкту.
У подальшому був розроблений робочий розподіл для кожного етапу проєкту,
де чітко визначені завдання та відповідальність різних команд та співробітників.
Використовуючи різні методи прийняття рішень в умовах невизначеності, було
визначено оптимальний шлях управління проєктом з урахуванням ризиків та
можливих виграшів.
Основні кроки розробки системи включають моделювання процесу роботи та
його функціональних вимог за допомогою IDEF0 діаграм, використання
структурного підходу та стандарту UML для побудови моделі взаємодії користувачів
із системою. Також було вивчено та описано взаємодію з eBay API для отримання
інформації про товари та їх категорії, а також реалізовано процеси збереження,
оновлення та видалення товарів на сторонніх платформах.
 90

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

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

СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ

1. Решетило В.П., Федотова Ю.В. Невизначеність та ризик: співвідношення

понять та специфіка прийняття рішень. 2020. Випуск №3 С. 140-154.
2. Коряшкіна Л.С. Моделі й методи прийняття рішень : посібник для студентів
вищих навчальних закладів напряму підготовки «Системний аналіз».
Дніпропетровськ : НГУ, 2014. 248 с.
3. Ковтун Т. Д., Матвієнко А. П. Сучасний стан і перспективи розвитку
світового та вітчизняного ринків електронної комерції. Бізнес Інформ. 2020.
№4. C. 295-303.
4. Аніловська Г. Я., Марушко Н. С., Стоколоса Т. М. Інформаційні системи і
технології у фінансах : навч. посіб. Львів : Магнолія, 2015. 312 с.
5. The Most Popular Databases in 2023. URL:
https://learnsql.com/blog/most-popular-databases-2023/
6. Spring Boot Documentation. URL:
https://spring.io/projects/spring-boot
7. A Guide to the Project Management Body of Knowledge (PMBOK® Guide).
Sixth Edition. USA. PMI, 2017. 756 с.
8. Добровська Л.М., Аверьянова О.В. Управління ІТ-проєктами в Microsoft
Project: Комп’ютерний практикум. Київ: КПІ ім. Ігоря Сікорського, 2020.
152 с.
9. Альтман Г. Scrum: The First Agile Methodology For Managing Product
Development Step-By-Step – Каліфорнія: CreateSpace Independent Publishing
Platform, 2017.
10. Дубовий В.М., Москвіна С.М., Никитенко О.Д. Моделювання процесів і
систем керування. Вінниця : ВНТУ, 2009. 103 с.
11. Ebay develepers program. RESTful API. URL:
https://developer.ebay.com/develop/apis/restful-apis
 92

ДОДАТОК А

Затверджую
Зав. кафедри КНСА,
______________ Юрій ТРИУС
«____»____________2023 р.

ІТ-ПРОЄКТ СТВОРЕННЯ ІНФОРМАЦІЙНОЇ СИСТЕМИ УПРАВЛІННЯ

ЗАЛИШКАМИ ТОВАРІВ, РОЗМІЩЕНИХ НА СТОРОННІХ ПЛАТФОРМАХ

Специфікація
482. ЧДТУ. 32244-01 90 01

Листів 2

Розробник ____________________ Немцова О.Г.

Керівник ____________________ Триус Ю.В.

Черкаси – 2023
 93

482. ЧДТУ. 32244-01

Позначення Найменування Примітка

Документація

482. ЧДТУ. 32244-01 12 01 Текст програми

управління залишками
товарів в межах
інформаційної системи
та на сторонній
платформі eBay

482. ЧДТУ. 32244-01 34 01 Інструкція користувача

щодо пошуку та
перегляду інформації про
товари

482. ЧДТУ. 32244-01 90 01 Публікація по темі

кваліфікаційної роботи
магістра
 94

ДОДАТОК Б

Затверджую
Зав. кафедри КНСА,
______________ Юрій ТРИУС
«____»____________2023 р.

ІТ-ПРОЄКТ СТВОРЕННЯ ІНФОРМАЦІЙНОЇ СИСТЕМИ УПРАВЛІННЯ

ЗАЛИШКАМИ ТОВАРІВ, РОЗМІЩЕНИХ НА СТОРОННІХ ПЛАТФОРМАХ

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

сторонній платформі eBay
482. ЧДТУ. 32244-01 12 01

Листів 8

Розробник ____________________ Немцова О.Г.

Черкаси – 2023
 95

Абстрактний клас комунікації зі сторонньою платформою eBay:

@RequiredArgsConstructor
public abstract class EbayAdapter {
private final EbayTokenAdapter tokenAdapter;
protected final WebClient.Builder webClientBuilder;
protected final String url;

protected abstract void buildWebClient();

protected ExchangeFilterFunction getFilter() {

return ExchangeFilterFunction.ofResponseProcessor(response -> {

HttpStatusCode httpStatusCode = response.statusCode();

if (httpStatusCode.equals(HttpStatus.UNAUTHORIZED)) {
return response.bodyToMono(String.class)
.flatMap(
body -> Mono.error(new TokenExpiredException(body))
);
}
if (!httpStatusCode.equals(HttpStatus.NOT_FOUND) &&
httpStatusCode.isError()) {
return response.bodyToMono(String.class)
.flatMap(
body -> Mono.error(new
IllegalArgumentException(body))
);
}
return Mono.just(response);
});
}

protected void handleTokenExpiration(Runnable action) {

try {
buildWebClient();
action.run();
} catch (TokenExpiredException e) {
String newToken = tokenAdapter.refresh(Token.getREFRESH_TOKEN());
Token.setEbayToken(newToken);
handleTokenExpiration(action);
}
}
}

Клас-адаптер, відповідальний за управління залишками товарів на eBay:

@Component
public class EbayPartAdapter extends EbayAdapter {
private WebClient webClient;
private static final String INVENTORY_PATH = "sell/inventory/v1/inventory_item";
private static final String OFFER_PATH = "sell/inventory/v1/offer";
private final PartMapper partMapper;
 96

public EbayPartAdapter(@Value("${ebay.url}") String url,

WebClient.Builder webClientBuilder,
PartMapper partMapper,
EbayTokenAdapter tokenAdapter) {

super(tokenAdapter, webClientBuilder, url);

this.partMapper = partMapper;
}

@Override
protected void buildWebClient() {
this.webClient = webClientBuilder
.baseUrl(url)
.defaultHeader("Authorization", "Bearer " + Token.getEbayToken())
.defaultHeader("Accept", "application/json")
.defaultHeader("Content-Type", "application/json")
.defaultHeader("Content-Language", "de-DE")
.filter(getFilter())
.build();
}

List<Part> getParts(int limit, int offset) {

List<Part> parts = new ArrayList<>();

handleTokenExpiration(() -> {
InventoryItemsResp inventoryItemsResp = webClient.get().uri(uriBuilder ->
uriBuilder
.path(INVENTORY_PATH)
.queryParam("limit", limit)
.queryParam("offset", offset)
.build())
.retrieve()
.bodyToMono(InventoryItemsResp.class)
.block();

if (inventoryItemsResp == null || inventoryItemsResp.getInventoryItems()

== null) {
return;
}
List<InventoryItem> inventoryItems =
inventoryItemsResp.getInventoryItems();

inventoryItems.forEach(
inventoryItem -> {
Part part = partMapper.toEntity(inventoryItem,
getOfferBySku(inventoryItem.getSku()));
parts.add(part);
}
);
});
return parts;
}

void save(Part part) {

String sku = getPartSku(part);
 97

handleTokenExpiration(() -> {

InventoryItem inventoryItem = partMapper.toInventoryItem(part);

inventoryItem.setSku(sku);

saveInventoryItem(inventoryItem);

Offer offer = partMapper.toOffer(part);

Offer exists = getOfferBySku(offer.getSku());
if (exists.equals(new Offer())) {
String newOfferId = saveOffer(offer);
publishOffer(newOfferId);
return;
}
update(offer, exists.getOfferId());
publishOffer(exists.getOfferId());
});
}

private void update(Offer offer, String offerId) {

webClient.put().uri(uriBuilder -> uriBuilder
.path(OFFER_PATH + "/{offerId}")
.build(offerId))
.bodyValue(offer)
.retrieve()
.toBodilessEntity()
.block();
}

private void saveInventoryItem(InventoryItem inventoryItem) {

webClient.put().uri(uriBuilder -> uriBuilder
.path(INVENTORY_PATH + "/{SKU}")
.build(inventoryItem.getSku())
)
.bodyValue(inventoryItem)
.retrieve()
.onStatus(HttpStatus.NOT_FOUND::equals,
response ->
response.bodyToMono(String.class).map(NotFoundException::new))
.toBodilessEntity()
.block();
}

private String saveOffer(Offer offer) {

Offer newOffer = webClient.post().uri(OFFER_PATH)
.bodyValue(offer)
.retrieve()
.bodyToMono(Offer.class)
.block();
if (newOffer == null) {
return null;
}
return newOffer.getOfferId();
}
 98

private void publishOffer(String newOfferId) {

webClient.post().uri(uriBuilder -> uriBuilder
.path(OFFER_PATH + "/{offerId}/publish")
.build(newOfferId))
.retrieve()
.toBodilessEntity()
.block();
}

void remove(String sku) {

handleTokenExpiration(() ->
webClient.delete().uri(uriBuilder -> uriBuilder
.path(INVENTORY_PATH + "/{SKU}")
.build(sku)
).retrieve()
.onStatus(HttpStatus.NOT_FOUND::equals,
response ->
response.bodyToMono(String.class).map(NotFoundException::new))
.toBodilessEntity()
.block()
);
}

private Offer getOfferBySku(String sku) {

OffersResp offersResp = webClient.get()
.uri(uriBuilder -> uriBuilder
.path(OFFER_PATH)
.queryParam("sku", sku)
.build())
.retrieve()
.onStatus(HttpStatus.NOT_FOUND::equals,
response -> Mono.empty())
.bodyToMono(OffersResp.class)
.block();

if (offersResp == null || offersResp.getOffers().isEmpty()) {

return new Offer();
}
return offersResp.getOffers().get(0);
}

private String getPartSku(Part part) {

return part.getPartProviders().stream()
.filter(partProvider -> {
long providerId =
partProvider.getCategoryProvider().getProviderId();
return providerId == ProviderType.EBAY.getId();
}
)
.map(PartProvider::getExternalId)
.findFirst()
.orElseThrow(
() -> new NoSuchElementException("External ebay id not found
for part: %s".formatted(part))
);
 99

}
}

Сервіс, відповідальний за управління залишками товарів в межах

інформаційної системи та передачу данних до адаптерів сторонніх платформ:
@Service
@RequiredArgsConstructor
public class PartService {
private final PartRepository partRepository;
private final PartAdapter partAdapter;
private final PartMapper partMapper;
private final PageMapper<PartRespDto> pageMapper;
private final JdbcAggregateTemplate jdbcAggregateTemplate;
private final CarRepository carRepository;
private final GeneratorQueryParamsService generatorQueryParams;
private final PartMigration partMigration;
private final GeneratorUuidService uuidService;
private final HtmlParseService htmlParseService;
private static final String NOT_FOUND_MESSAGE = "Not found Part by uuid: %s ";

public PageDto<PartRespDto> getAll(String carUuid, int page, int limit,

List<PartFilterDto> filters, List<PartSortDto> sorts) {
Pageable pageable = PageRequest.of(page, limit);

Sort sort = generatorQueryParams.generatePartSort(sorts);

Criteria criteria = generatorQueryParams.generatePartCriteria(filters);

if (carUuid != null) {
long carId = carRepository.findFirstByUuid(carUuid)
.map(Car::getId)
.orElseThrow(
() -> new NotFoundException("Not found Car by uuid: %s
".formatted(carUuid))
);

criteria = criteria.and(Criteria.where("car_id").is(carId));
}

List<Part> parts = IterableUtils.toList(

jdbcAggregateTemplate.findAll(Query.query(criteria).sort(sort).limit(limit).
offset(pageable.getOffset()), Part.class)
);
long count = jdbcAggregateTemplate.count(Query.query(criteria), Part.class);

return pageMapper.toDto(
new PageImpl<>(partMapper.toDtos(parts), pageable, count)
);
}

public PartRespDto getByUuid(String uuid) {

return partRepository.findFirstByUuid(uuid)
.map(partMapper::toDto)
 100

.orElseThrow(
() -> new
NotFoundException(NOT_FOUND_MESSAGE.formatted(uuid))
);
}

public PartRespDto getById(long id) {

return partRepository.findById(id)
.map(partMapper::toDto)
.orElse(null);
}

@Transactional
public PartRespDto add(PartRespDto partRespDto) {
Part part = partMapper.toEntity(partRespDto);
part.setUuid(uuidService.getUUid());
setExternalId(part);
part.setDescription(null);
Part saved = partRepository.save(part);

saveAtProviders(part);
saved.getMedias().forEach(media -> media.setFile(null));
return partMapper.toDto(
saved
);
}

@Transactional
public PartRespDto update(String uuid, PartRespDto partRespDto) {
Part exists = partRepository.findFirstByUuid(uuid).orElseThrow(
() -> new NotFoundException(NOT_FOUND_MESSAGE.formatted(uuid))
);

Part updateTo = partMapper.toEntity(partRespDto);

setExternalId(updateTo);
removePartsForDeletedProviders(
partMapper.toEntity(partMapper.toDto(exists)).getPartProviders(),
updateTo.getPartProviders()
);
partMigration.updatePartProps(exists, updateTo);
exists.setDescription(null);

Part saved = partRepository.save(exists);

saveAtProviders(exists);
saved.getMedias().forEach(media -> media.setFile(null));
return partMapper.toDto(
saved
);
}

private void saveAtProviders(Part part) {

Set<PartProvider> partProviders = part.getPartProviders();
partProviders.forEach(partProvider -> {
CategoryProvider categoryProvider = partProvider.getCategoryProvider();
 101

partAdapter.save(
ProviderType.valueOf(categoryProvider.getProviderId()),
part
);
});
}

public void removePartsForDeletedProviders(Set<PartProvider> existingProviders,

Set<PartProvider> updatedProviders) {
existingProviders.forEach(partProvider -> {
long providerId = partProvider.getCategoryProvider().getProviderId();

if (updatedProviders.stream()
.noneMatch(updatedPartProvider ->
updatedPartProvider.getCategoryProvider().getProviderId()
== providerId)) {

partAdapter.remove(ProviderType.valueOf(providerId),
partProvider.getExternalId());
}
});
}

@Transactional
public void delete(String uuid) {
Part part = partRepository.findFirstByUuid(uuid)
.orElseThrow(
() -> new
NotFoundException(NOT_FOUND_MESSAGE.formatted(uuid))
);
deleteAtProviders(partMapper.toEntity(partMapper.toDto(part)));

partRepository.deleteById(part.getId());
}

void deleteAtProviders(Part part) {

Set<PartProvider> partProviders = part.getPartProviders();

partProviders.forEach(partProvider -> {
CategoryProvider categoryProvider = partProvider.getCategoryProvider();

partAdapter.remove(
ProviderType.valueOf(categoryProvider.getProviderId()),
partProvider.getExternalId()
);
});
}
}
 102

ДОДАТОК В

Затверджую
Зав. кафедри КНСА,
______________ Юрій ТРИУС
«____»____________2023 р.

ІТ-ПРОЄКТ СТВОРЕННЯ ІНФОРМАЦІЙНОЇ СИСТЕМИ УПРАВЛІННЯ

ЗАЛИШКАМИ ТОВАРІВ, РОЗМІЩЕНИХ НА СТОРОННІХ ПЛАТФОРМАХ

Інструкція користувача щодо пошуку та перегляду інформації про товари

482. ЧДТУ. 32244-01 34 01

Листів 3

Розробник ____________________ Немцова О.Г.

Черкаси – 2023
 103

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

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

Рисунок В.1 – Сторінка зі списком продукції

На цій сторінці реалізована можливість пошуку продукції за датою, описом,

заголовками, внутрішнім та зовнішнім (id на сторонніх платформах) номерами
продукту, додатковою інформацією та ціною. Для пошуку товарів за датою
розміщення необхідно задати часовий інтервал в поле «Time Interval» (початкову та
кінцеву шукані дати). Щоб шукати товари за описом, заголовками, внутрішнім та
зовнішнім номерами продукту та додатковою інформацією необхідно ввести включні
в них слова в поле «Search», а пошук за ціною відбувається відповідно до введених
чисел у поля: «Min cost» – мінімальна шукана ціна та «Max cost» – максимальна
шукана ціна. Результатом введення необхідних данних та після натиснення клавіші
«Search» буде список відфільтрованних відповідно товарів.
Також доступне сортування товарів за заголовками, внутрішнім номером,
ціною та датою. Для здійснення сортування, необхідно натиснути на відповідний
заголовок списку продукції.
 104

Продивитись інформацію про товар (рисунок В.2) можна натиснувши на іконку

«ⓘ», редагувати інформацію про товар (рисунок В.3) – іконка «•••» та видалити товар

– іконка «🗑».

Рисунок В.2 – Загальна інформація про товар

 105

Рисунок В.3 – Редагування та перегляд інформації про товар

 106

ДОДАТОК Г

Затверджую
Зав. кафедри КНСА,
______________ Юрій ТРИУС
«____»____________2023 р.

ІТ-ПРОЄКТ СТВОРЕННЯ ІНФОРМАЦІЙНОЇ СИСТЕМИ УПРАВЛІННЯ

ЗАЛИШКАМИ ТОВАРІВ, РОЗМІЩЕНИХ НА СТОРОННІХ ПЛАТФОРМАХ

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

482. ЧДТУ. 32244-01 90 01

Листів 4

Розробник ____________________ Немцова О.Г.

Черкаси – 2023
107
 108

Секція №5. Веб-орієнтовані інформаційні системи

Немцова Олена Геннадіївна
магістрантка
Сіньковський Артем Петрович
асистент кафедри КНСА
Черкаський державний технологічний університет, м.Черкаси, Україна
ІНФОРМАЦІНА СИСТЕМА УПРАВЛІННЯ ЗАЛИШКАМИ ТОВАРІВ
КОМПАНІЇ, РОЗМІЩЕННИХ НА СТОРОННІХ ПЛАТФОРМАХ
Сучасна компанія, діяльність якої зосереджена на продажі товарів через онлайн-
платформи, такі як eBay, Amazon тощо, потребує ефективного управління запасами
та продажами. Зростання популярності цих платформ роблять їх важливими каналами
для продажу, адже вони надають можливість компаніям працювати з великою
аудиторією клієнтів, підвищуючи попит на продукцію та розширюючи власні бізнес-
можливості. В цьому контексті виникає потреба у створенні та впроваджені
інформаційної системи для управління залишками товарів компанії на різних онлайн-
платформах [1].
Однією з проблем управління залишками на різних онлайн-платформах є
фрагментація управління запасами. Необхідність окремого оновлення інформації про
товари на кожній платформі призводить до дублювання робочих процесів. Зміна
будь-якої інформації про товар на одній платформі, вимагає ручного оновлення цієї
інформації і на інших платформах, що, у свою чергу, призводить до затримок у
відображенні актуальних даних.
До проблем, що має вирішити впровадження інформаційної системи управління
залишками товарів компанії, розміщених на різних онлайн-платформах, варто
віднести такі:
1. Неузгодженість інформації про товари – вплив людського фактору може стати
причиною появи розбіжностей даних про товари на різних платформах, що
вимагатиме зайвих витрат часу на пошук, перевірку та редагування цієї інформації, а
також до можливих помилок у веденні обліку запасів;
2. Ризик втрати продажів та репутації – неактуальна інформація про товари є
потенційною причиною зменшення рівня продажів та негативно позначається на
репутації компанії;
3. Складність управління декількома платформами – управління товарами на
різних платформах може бути ускладненим процесом через відмінності у їх вимогах
та інтерфейсі.
Створення інформаційної системи для управління залишками на сторонніх
платформах допоможе оптимізувати бізнес-процеси та покращити ефективність
діяльності компанії, підвищити її конкурентоспроможність на ринку.
Інформаційна система має забезпечити вирішення таких задач:
1. Автоматизація процесів інвентаризації – створення системи надасть
можливість автоматизувати процес інвентаризації, мінімізуючи людські помилки та
збільшуючи точність обліку товарів. Ключовим аспектом автоматизованої системи є
те, що інформація про товари буде єдиною та однаковою на всіх платформах. Сервіс
 109

допоможе систематизувати та спростити процес створення товарів, узгоджуючи

особливості кожної платформи для ефективного управління асортиментом;
2. Автоматичне оновлення залишків – система зможе автоматично
синхронізувати інформацію про залишки товарів на різних платформах, що допоможе
уникнути розбіжностей та забезпечити актуальну інформацію для якісного
обслуговування клієнтів;
3. Розширення діяльності на інші платформи – інформаційна система може
включати можливість розширити діяльність компанії на інші платформи, спростивши
процес інтеграції та управління асортиментом товарів;
4. Покращення обслуговування клієнтів – постійна актуалізація інформації на
всіх платформах сприятиме підвищенню якості обслуговування, оскільки компанія
матиме можливість оперативно реагувати на запити клієнтів, виявляти попит, а також
допоможе компанії бути більш гнучкою в управлінні запасами та замовленнями;
5. Підвищення конкурентоспроможності компанії – інформаційна система
створює умови для ефективної роботи на різних платформах, що додасть
конкурентних переваг компанії, розширить географію продажів та надасть
можливість залучити нових клієнтів;
6. Покращення аналітичної діяльності – система може надати аналітичні засоби
для вивчення попиту, здійснення прогнозів продажів та виявлення ключових трендів,
що допоможе компанії приймати обґрунтовані рішення щодо стратегії її розвитку [2].
Отже, створення та впровадження інформаційної системи для управління
залишками товарів на різних онлайн-платформах є актуальною науково-технічною
проблемою, вирішення якої надасть керівництву компанії можливість оптимізувати
процеси управління запасами, збільшити її прибутковість та підвищити
конкурентоспроможність на міжнародному ринку, при цьому має відбутися
зменшення адміністративного навантаження та підвищення загальної ефективності
діяльності компанії.
Авторами дослідження розробляється веб-орієнтована інформаційна система
управління залишками товарів компанії, розміщених на різних онлайн-платформах.
Основними засобами розробки системи є сучасні веб-технології, бази даних для
зберігання інформації про товари та замовлення, а також механізми автоматизації, які
гарантують ефективну інтеграцію з різними торговельними платформами для
забезпечення швидкої, надійної та безпечної обробки інформації. Система буде
враховувати потреби користувачів і здатна інтегруватися з існуючими інформаційними
системами компанії. Крім того, враховуються сучасні стандарти безпеки для захисту
конфіденційності та цілісності даних, забезпечуючи високий рівень безпеки обробки та
зберігання інформації.
Список літератури
1. Коваленко О. C., Л. М. Добровська. Проектування інформаційних систем: Загальні питання
теорії проектування ІС (конспект лекцій). Навч. посіб. для студ. спеціальності 122 «Комп’ютерні
науки». Київ : КПІ ім. Ігоря Сікорського, 2020. 192с.
2. Ebay develepers program. Sell APIs. URL: https://developer.ebay.com/develop/apis/restful-
apis/sell-apis