Будь ласка, використовуйте цей ідентифікатор, щоб цитувати або посилатися на цей матеріал: https://er.chdtu.edu.ua/handle/ChSTU/6038
Назва: Система управління логістичним документообігом за технологією блокчейн
Автори: Підгорний, Микола Володимирович
Шевченко, Олексій Михайлович
Ключові слова: ЕЛЕКТРОННИЙ ДОКУМЕНТООБІГ,;ЦИФРОВІ ДОКУМЕНТИ,;БЛОКЧЕЙН,;ДОКУМЕНТОЦЕНТРИЧНА СИСТЕМА,;БЛОКЧЕЙН-ТЕХНОЛОГІЯ.
Дата публікації: 12-чер-2025
Короткий огляд (реферат): У сучасних умовах глобалізації та цифровізації логістика відіграє ключову роль у забезпеченні ефективного функціонування бізнесу. Водночас документообіг у логістичних процесах часто характеризується високим рівнем паперової роботи, дублюванням інформації та низьким рівнем прозорості. Використання технології блокчейн дозволяє забезпечити незмінність, цілісність і доступність документів, спрощуючи перевірку їх справжності та знижуючи ризики шахрайства. Тож робота обумовлена зростаючим попитом на системи логістичного електронного документообігу серед українських підприємств та відсутністю ефективних існуючих рішень. Метою цієї роботи є розробка та реалізація прототипу системи управління логістичним документообігом з використанням блокчейн-технології для підвищення прозорості, безпеки та автоматизації обміну даними між учасниками логістичних процесів. Важливим є вивчення проблем автоматизації документообігу шляхом впровадження системи, що ґрунтується на технології блокчейн. Для досягнення цієї мети були поставлені наступні завдання: аналіз існуючих систем електронного документообігу; проєктування нової системи; впровадження блокчейн-технології; розробка та тестування архітектури системи; створення користувацького інтерфейсу. Об'єкт дослідження – процеси документообігу в логістичних компаніях. Предмет дослідження – методи та засоби застосування блокчейн-технологій у системах документообігу. Методи дослідження: використання методів роботи з електронною документацією; пошук, обробка та збереження інформації; засоби автоматизації управлінських функцій. Практичне значення отриманих результатів полягає у впровадженні створеної системи документообігу на основі блокчейну, що дозволяє зменшити витрати підприємства та підвищити ефективність його діяльності.
URI (Уніфікований ідентифікатор ресурсу): https://er.chdtu.edu.ua/handle/ChSTU/6038
Розташовується у зібраннях:124 Системний аналіз (Штучний інтелект)

Файли цього матеріалу:
Файл Опис РозмірФормат 
Пояснювальна записка_Шевченко Олексій_СА-2102_2024-2025.pdf
  Restricted Access
2.69 MBAdobe PDFПереглянути/Відкрити    Запит копії


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

Extracted text
 
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
 
Факультет інформаційних технологій і систем 
 
Кафедра комп’ютерних наук та системного аналізу 
 
 
 
 
 
 
 
 
Пояснювальна записка 
до кваліфікаційної роботи 
бакалавра 
(освітньо-кваліфікаційний рівень) 
 
на тему: «Система управління логістичним документообігом за технологією 
блокчейн» 
 
 
 
Виконав: студент 4 курсу, групи СА-2102 
  
спеціальності 124 «Системний аналіз» 
                                                             (шифр і назва спеціальності) 
 
Освітня програма «Системний аналіз та  
                                                                (назва освітньої програми) 
прикладна логістика» 
 
Шевченко Олексій Михайлович 
 
Керівник                               Підгорний М.В. 
                                                                  (прізвище та ініціали) 
 
Рецензент                             Мельник В.П.  
                                                (прізвище та ініціали) 
 
 
 
 
 
 
 
 
Черкаси 2025 року 
2 
Бланк завдання на кваліфікаційну роботу бакалавра студенту 
 
Черкаський державний технологічний університет 
Факультет Інформаційних технологій і систем 
Кафедра Комп’ютерних наук та системного аналізу 
Освітньо-кваліфікаційний рівень Бакалавр 
Спеціальність 1
Освітня програма С2 истемний аналіз і прикладна логістика 
 – системний аналіз   
 
ЗАТВЕРДЖУЮ 
Завідувач кафедри КНСА  
_______________ Юрій ТРИУС 
«
 _
 _
ЗАВДАННЯ _
на кваліфікаційну роботу бакалавра ст_уденту 
Шевченко Олексію Михайловичу» 
(прізвище, ім‘я, по батькові)  
1. Тема роботи Система управління логістичним документоо_бігом за технологією блокчейн 
 _
Керівник роботи  Підгорний Микола Володимирович к.т.н., _професор 
(прізвище, ім’я, по батькові, науковий ступінь, вчене зв_ання)
 
 _
затверджені наказом університету від «25» лютого 2025 р. № 53/0_3-03. 
 _
2. Строк подання студентом роботи  «12» червня 2025 року  _
3. Вихідні дані до роботи:  _
Звіт з переддипломної практики. Робота з Веб-ресурсами.  _
_
Практичні навики роботи з інформаційними ресурсами. Робота з базами даних. 
_
 _
4. Зміст пояснювальної записки (перелік питань, що їх належить р озробити): 
Вступ 2
4.1. Основні поняття і визначення електронного документообігу 0
2
4.2. Огляд систем електронного документообігу  р. 
Аналіз можливостей технології блокчейн для побудови систем електронного  
дВоиксунмоевнктио. о бігу 
5 . Перелік додатків (з точним зазначенням назв додатків): 
 5.1. Додаток А. Специфікація 482.ЧДТУ. 52314-01. 
 1. Інструкція користувача 
5.2. Додаток Б. Інструкція користувача. 
5
 .
 Презентація у вигляді 19 слайдів. 
 
 
3 
6. Консультанти розділів роботи 
Прізвище, ініціали та Підпис, дата 
Розділ посада 
завдання видав завдання прийняв 
консультанта 
    
    
 
7. Дата видачі завдання 17.12.2024 
  
 
КАЛЕНДАРНИЙ ПЛАН 
Строк виконання 
№ з/п Назва етапів кваліфікаційної роботи бакалавра Примітка 
етапів роботи 
1 Видача завдання на кваліфікаційну роботу 
17.12.2024 Виконано 
бакалавра. 
2 Аналіз літературних джерел, об’єкту та предмету 
до 12.01.2025 Виконано 
дослідження. 
3 Написання теоретичного розділу кваліфікаційної 
до 18.03.2025 Виконано 
роботи бакалавра. 
4 Написання аналітичного розділу кваліфікаційної 
до 05.04.2025 Виконано 
роботи бакалавра. 
5 Написання практичних розділів й висновків до 
до 01.05.2025 Виконано 
кваліфікаційної роботи бакалавра. 
6 Передзахист кваліфікаційної роботи бакалавра 
26.05.2025 Виконано 
на засіданні кафедри КНСА. 
7 Подання роботи завідувачу кафедри КНСА. до 11.06.2025 Виконано 
8 Захист кваліфікаційної роботи бакалавра. 11.06.2025 Виконано 
    
    
    
 
 
Студент                                   _____________________________     Олексій ШЕВЧЕНКО                
(підпис)                                                                     
 
Керівник роботи                     ____________________________       Микола ПІДГОРНИЙ     
                                                                           (підпис)      
 
 
 
 
 
 
 
 
 
 
 
 
                                                               
4 
РЕФЕРАТ  
Кваліфікаційна робота бакалавра містить: 95 с., 32 рис., 42 табл., 3 
додатки, 14 використаних джерел. 
Актуальність дослідження У сучасних умовах глобалізації та 
цифровізації логістика відіграє ключову роль у забезпеченні ефективного 
функціонування бізнесу. Водночас документообіг у логістичних процесах часто 
характеризується високим рівнем паперової роботи, дублюванням інформації 
та низьким рівнем прозорості. Використання технології блокчейн дозволяє 
забезпечити незмінність, цілісність і доступність документів, спрощуючи 
перевірку їх справжності та знижуючи ризики шахрайства. Тож робота 
обумовлена зростаючим попитом на системи логістичного електронного 
документообігу серед українських підприємств та відсутністю ефективних 
існуючих рішень. 
Метою цієї роботи є розробка та реалізація прототипу системи 
управління логістичним документообігом з використанням блокчейн-
технології для підвищення прозорості, безпеки та автоматизації обміну даними 
між учасниками логістичних процесів. Важливим є вивчення проблем 
автоматизації документообігу шляхом впровадження системи, що ґрунтується 
на технології блокчейн. 
Для досягнення цієї мети були поставлені наступні завдання: аналіз 
існуючих систем електронного документообігу; проєктування нової системи; 
впровадження блокчейн-технології; розробка та тестування архітектури 
системи; створення користувацького інтерфейсу. 
Об'єкт дослідження – процеси  документообігу в логістичних компаніях. 
Предмет дослідження – методи та засоби застосування блокчейн-
технологій у системах документообігу.  
Методи дослідження: використання методів роботи з електронною 
документацією; пошук, обробка та збереження інформації; засоби автоматизації 
управлінських функцій. 
5 
Практичне значення отриманих результатів полягає у впровадженні 
створеної системи документообігу на основі блокчейну, що дозволяє зменшити 
витрати підприємства та підвищити ефективність його діяльності. 
Ключові слова: ЕЛЕКТРОННИЙ ДОКУМЕНТООБІГ, ЦИФРОВІ 
ДОКУМЕНТИ, БЛОКЧЕЙН, ДОКУМЕНТОЦЕНТРИЧНА СИСТЕМА, 
БЛОКЧЕЙН-ТЕХНОЛОГІЯ. 
ABSTRACT 
The bachelor's qualification work consists of 95 pages, 32 figures, 42 tables, 
3 appendices, and 14 references. 
Relevance of the research. 
In the current context of globalization and digitalization, logistics plays a key 
role in ensuring the efficient functioning of businesses. However, document 
management in logistics processes is often characterized by excessive paperwork, 
duplication of information, and low transparency. The use of blockchain technology 
ensures the immutability, integrity, and accessibility of documents, simplifying the 
verification of their authenticity and reducing the risks of fraud. This study is driven 
by the growing demand for electronic logistics document management systems among 
Ukrainian enterprises and the lack of effective existing solutions. 
The aim of this work is to develop and implement a prototype of a logistics 
document management system using blockchain technology to improve transparency, 
security, and automation of data exchange between participants in logistics processes. 
The study focuses on the problems of automating document workflows through the 
implementation of a system based on blockchain technology. 
To achieve this aim, the following tasks were set: 
– analysis of existing electronic document management systems; 
– design of a new system; 
– implementation of blockchain technology; 
– development and testing of the system architecture; 
– creation of a user interface. 
6 
Object of the research – document management processes in logistics 
companies. 
Subject of the research – methods and tools for applying blockchain 
technologies in document management systems. 
Research methods: 
Use of electronic documentation processing techniques; information search, 
processing, and storage; tools for automating management functions. 
Practical significance of the results lies in the implementation of the developed 
blockchain-based document management system, which enables companies to reduce 
costs and improve operational efficiency. 
Keywords: ELECTRONIC DOCUMENT MANAGEMENT, DIGITAL 
DOCUMENTS, BLOCKCHAIN, DOCUMENT-CENTRIC SYSTEM, 
BLOCKCHAIN TECHNOLOGY. 
  
7 
ЗМІСТ  
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СКОРОЧЕНЬ, ТЕРМІНІВ ....................... 10 
ВСТУП ...................................................................................................................... 11 
1 ОСНОВНІ ПОНЯТТЯ І ВИЗНАЧЕННЯ ЕЛЕКТРОННОГО 
ДОКУМЕНТООБІГУ……………………………...……………………………… 13 
1.1 Поняття документообігу ................................................................................ 13  
1.1.1 Види документообігу............................................................................ 14  
1.1.2 Способи організації документообігу  ................................................. 15  
1.1.3 Навіщо потрібен електронний документообіг ................................... 16  
1.1.4 Основні принципи електронного документообігу   ...........................17  
1.2 Проблеми традиційних та електронних технологій документообігу……. 21  
1.3 Переваги електронного документообігу над паперовим ............................ 23  
1.4 Реалізація електронного документообігу ..................................................... 25  
1.4.1 Що необхідно для побудови електронного документообігу…. ……. 25  
1.4.2 Забезпечення процесу підготовки документів……………………….27 
Висновки до розділу 1………………………………………………..…………..27 
2 ОГЛЯД СИСТЕМ ЕЛЕКТРОННОГО ДОКУМЕНТООБІГУ………………….28 
2.1 Типові вимоги до систем електронного документообігу…………………..29 
2.2 Огляд компонентів систем електронного документообігу………………...30 
2.3 Огляд провідних систем електронного документообігу…………………...32 
2.4 Основні характеристики ефективної системи електронного 
документообігу…………………………………………………………………...34 
Висновки до розділу 2…………………………………………………………….35 
3 АНАЛІЗ МОЖЛИВОСТЕЙ ТЕХНОЛОГІЇ БЛОКЧЕЙН................................... 36 
3.1 Використання блокчейн у побудові програмних продуктів……………….37 
3.2 Архітектура та принцип дії блокчейн-технології…………………………..38 
3.2 Ключові системи електронного документообігу ......................................... 30  
3.3 Властивості ефективної системи електронного документообігу ............... 32 
3.5 Використання блокчейн у побудові програмних продуктів ...................... 35 
3.6 Архітектура та принцип роботи технології блокчейн ................................ 36 
8 
Висновки до розділу 3……………………………………………………………40 
4 РОЗРОБКА СИСТЕМИ ЕЛЕКТРОННОГО ДОКУМЕНТООБІГУ ………... 41 
4.1 Постановка завдання ...................................................................................... 41 
4.2 Функціональний опис системи ..................................................................... 42 
4.3 Логічне проектування .................................................................................... 44 
4.4 Вибір та обґрунтування компонент.............................................................. .46 
4.5 Варіанти використання ................................................................................. .51 
4.6 Доменна модель ............................................................................................. .57 
4.7 Програмні компоненти системи ................................................................... .63 
4.8 Розгортання системи ..................................................................................... .65 
Висновки до розділу 4……………………………………………………………74 
ВИСНОВКИ ............................................................................................................. 75 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ…………………………………………..77 
ДОДАТОК А. СПЕЦИФІКАЦІЯ 482.ЧДТУ............................................................79 
ДОДАТОК Б. ІНСТРУКЦІЯ КОРИСТУВАЧА ……………………......................81 
ДОДАТОК В. ЛІСТИНГ КОДУ ПРОГРАМИ.........................................................83 
  
9 
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СКОРОЧЕНЬ, ТЕРМІНІВ 
 
ORM – об’єктно-реляційне відображення даних (Object-
Relational Mapping); 
POW – алгоритм досягнення консенсусу «доказ виконаної 
роботи» (proof-of-work); 
REST – архітектурний стиль передачі даних (Representational 
State Transfer); 
RPC – виклик віддаленої процедури (Remote Procedure Call); 
БД – база даних; 
ЕЦП – електронний цифровий підпис; 
ПЗ – програмне забезпечення; 
СЕД – система управління електронним документообігом; 
СУБД – система керування базами даних; 
Фреймворк – набір програмних компонентів, призначений для 
спрощення розробки комплексних програмних систем. 
   
10 
ВСТУП  
Використання систем електронного документообігу стає дедалі 
актуальнішою практикою для українських компаній, адже це дозволяє оцінити 
переваги сучасних цифрових технологій у сфері обробки документів. Навіть 
організації, що вже активно застосовують автоматизований документообіг, 
можуть стикнутися з необхідністю переосмислити свої поточні рішення з метою 
підвищення ефективності управління інформаційними потоками. Це 
обумовлено динамікою змін на ринку, зростанням кількості підприємств, які 
потребують оновлення структури та впровадження інформаційно-
комунікаційних технологій. З одного боку, це відкриває нові перспективи для 
розвитку бізнесу, з іншого — змушує тримати конкурентний темп. 
Кожне підприємство має власні мотивації для впровадження 
автоматизованого документообігу: для одних — це оптимізація управлінського 
документообігу, для інших — підвищення продуктивності працівників, які 
щоденно працюють з великою кількістю документів. Проте питання 
впровадження зазвичай розглядається однобічно, без врахування комплексного 
підходу. Таке розмежування пояснюється різними ролями документів у 
діяльності організації, що залежить від стилю управління, масштабів 
підприємства, сфери його діяльності та інших чинників. Наприклад, на одному 
підприємстві документ виступає ключовим управлінським інструментом, а на 
іншому — лише супровідним засобом або кінцевим продуктом. 
Першим етапом для будь-якої організації є вибір відповідної системи 
серед багатьох доступних рішень. Проте створення базової автоматизованої 
системи без подальшого її розширення не є ефективним кроком. Доцільно 
забезпечити її додатковими функціональними та технологічними 
можливостями, які можуть реалізовуватись через системи управління 
контентом та впровадження технології блокчейн. 
Сучасна організаційна діяльність супроводжується накопиченням 
значного обсягу інформації, а також потребою у формуванні договорів та обміні 
11 
повідомленнями між зацікавленими сторонами. Технологія блокчейн може 
забезпечити додаткову довіру в таких процесах: збереження записів про дії 
сторін усуває потребу в довіреній третій стороні, а унікальний цифровий 
відбиток договору дозволяє обом сторонам гарантувати збереження достовірної 
версії без потреби у паперових копіях чи посередниках. Важливою є також 
можливість фіксації факту підписання документа конкретним співробітником, 
що значно спрощує процес внутрішнього погодження. 
Метою цієї роботи є створення системи електронного документообігу з 
використанням блокчейн-технології, а також вивчення актуальних проблем 
автоматизації документообігу за допомогою таких систем. 
Відповідно до поставленої мети визначено наступні завдання: 
1) Провести аналіз існуючих аналогів систем електронного документообігу; 
2) описати архітектурні рішення для запропонованої системи; 
3) розкрити особливості реалізації системи електронного документообігу; 
4) описати процес інтеграції блокчейн-технології; 
5) подати результати тестування створеної системи. 
Об'єкт дослідження: процеси документообігу в логістичних компаніях. 
Предмет дослідження: методи та засоби застосування блокчейн-
технологій у системах документообігу. 
  
12 
1 ОСНОВНІ ПОНЯТТЯ І ВИЗНАЧЕННЯ ЕЛЕКТРОННОГО 
ДОКУМЕНТООБІГУ 
Щодня ми маємо справу з електронним обміном інформацією, який 
реалізується за допомогою різноманітних засобів — таких як інтернет, 
персональні комп’ютери, смартфони, смарт-годинники та інші цифрові пристрої. 
Останні роки ознаменувалися активним впровадженням новітніх 
інструментів, спрямованих на підвищення ефективності управлінських процесів 
у діяльності підприємств. Одним із таких засобів стало спеціалізоване програмне 
забезпечення, що забезпечує цифрову обробку документів. У практику увійшли 
поняття електронного документа, електронного цифрового підпису (ЕЦП) та 
систем електронного документообігу. 
1.1 Поняття документообігу  
Документообіг — це процес переміщення документів у межах установи, 
що розпочинається з моменту їх створення або отримання від зовнішніх джерел 
і триває до передачі на архівне зберігання. До складу цього процесу входять: 
прийом вхідної документації, її обробка, реєстрація, контроль виконання, 
підготовка вихідних документів та їх відправлення. 
Під електронним документообігом розуміють сукупність операцій, 
пов’язаних зі створенням, обробкою, редагуванням, передачею, отриманням, 
зберіганням, використанням і знищенням електронних документів із 
обов’язковим застосуванням засобів перевірки їх цілісності та, у разі 
необхідності, підтвердженням факту їхнього отримання [1]. 
Електронний документ — це файл певного формату, створений за 
допомогою програмних засобів обробки інформації, який має підпис у вигляді 
електронного цифрового підпису (ЕЦП). Такий документ може зберігатися на 
електронних носіях, дублюватися та поширюватися без втрати автентичності. 
Електронний цифровий підпис (ЕЦП) — це аналог власноручного підпису 
в цифровій формі, який формується в результаті криптографічної обробки даних. 
13 
ЕЦП використовується для забезпечення захисту інформації, підтвердження її 
цілісності та встановлення особи підписувача [2]. 
Документ є ключовою одиницею в системі електронного документообігу. 
Такі системи забезпечують рух документів у межах підприємства, дають змогу 
відстежувати їх переміщення, зберігають як самі документи, так і інформацію 
про зміни, які в них відбулися. В організаціях, де впроваджено документообіг, 
документ виступає основним інструментом управлінської діяльності. Жодне 
управлінське рішення, розпорядження чи доручення не може бути реалізоване 
без відповідного документального оформлення. 
Під документообігом у межах організації слід розуміти впорядкований 
процес пересування службових документів, що створюються посадовими 
особами в межах виконання їхніх функціональних обов’язків. 
1.1.1 Види документообігу. В залежності від характеру операцій 
організацій, в яких відбувається рух (переміщення і облік) документів, 
виділяють наступні види документообігу. 
Фінансовий – окреслює всі діловодні операції і дає можливість 
підприємству керувати нормативними документами такими як договори, звіти, 
кореспонденція, нормативно-законодавчі акти і т.д., які беруть участь у бізнес 
процесах.   
Управлінський – поєднує в собі збір, аналіз і узагальнення даних для 
створення чітких, достовірних і наглядних управлінських звітів, на основі яких 
відбувається прийняття рішень в організації і контроль їх вчасного виконання.   
Технічний – має на увазі організацію  координації інформаційних потоків 
для створення і забезпечення правильної роботи всіх ланок життєвого циклу 
документації проекту: створення, оформлення, узгодження, затвердження, 
внесення змін та архівація.  
Кадровий –  забезпечує збір і аналіз інформації, з ведення обліку кадрів 
на підприємстві: даних про прийом на роботу, звільнення працівників, прогули, 
зміни посад, графіки відпусток, розклади змін, посадові інструкції і т.д.  
14 
Архівний – забезпечує організовану та своєчасну передачу документів на 
зберігання в архів, номенклатурний облік справ в процесі діловодства. В 
комп'ютерних програмах виділяють три основні види документообігу, що 
потребує автоматизації.  
Офісний – обслуговування офісних завдань, що виконуються найчастіше 
та є рутинними для користувача, застосовується тільки в межах конкретного 
проекту, наприклад, підготовка завдань та інструкцій. Керівна особа приймає 
рішення, що і як необхідно виконати, а також призначає працівника – хто 
повинен виконувати роботу. Електронне сповіщення, з інструкціями та 
статусом у процесі документообігу, надходить до працівника від працівника 
відповідно до порядку, призначеного заздалегідь.  
Спільний – призначений для використання у випадках, коли нетипові 
процеси пов’язують декілька відділів чи підприємств. Створення нової 
продукції, розробка концепту, проектування – це приклади спільного 
документообігу.  
Адміністративний документообіг об’єднує процеси, які до цього 
використовували лише документи у паперовому вигляді. Його призначення – 
обробка звітів і форм про адміністративні витрати. Замість заповнення 
паперової версії форми працівник заповнює електронну й надсилає 
електронною поштою отримувачу.  
1.1.2 Способи організації документообігу. Залежно від особливостей 
операційної діяльності організацій, де здійснюється переміщення та облік 
документів, виділяють кілька типів документообігу. 
Фінансовий документообіг охоплює весь спектр діловодних операцій, що 
забезпечують керування фінансовою документацією підприємства: договорами, 
звітами, листуванням, нормативно-правовими актами тощо. Ці документи 
безпосередньо залучені до реалізації бізнес-процесів. 
Управлінський документообіг включає процеси збору, аналізу та 
систематизації інформації з метою формування достовірних, наочних 
15 
управлінських звітів, які слугують основою для прийняття рішень та здійснення 
контролю за їх виконанням. 
Технічний документообіг забезпечує впорядковану організацію 
інформаційних потоків, що супроводжують всі етапи життєвого циклу проєктної 
документації: створення, оформлення, погодження, затвердження, внесення змін 
та передача в архів. 
Кадровий документообіг відповідає за облік і аналіз персональних даних 
працівників підприємства. Сюди входить документація щодо прийняття на 
роботу, звільнення, відпусток, змін у посадових обов’язках, графіків змін, 
посадових інструкцій тощо. 
Архівний документообіг забезпечує своєчасну передачу документації на 
довгострокове зберігання, а також ведення номенклатурного обліку справ у 
процесі діловодства. 
У контексті автоматизації документообігу в програмному забезпеченні 
зазвичай виділяють три основні типи: 
Офісний документообіг охоплює рутинні офісні завдання в межах 
конкретного проєкту — наприклад, формування доручень та інструкцій. 
Керівник приймає рішення щодо змісту та порядку виконання завдань, визначає 
відповідального працівника. Працівник отримує сповіщення в електронному 
вигляді із супровідною інформацією про статус документа та подальші дії. 
Колективний (спільний) документообіг застосовується в ситуаціях, коли 
взаємодіють кілька відділів або підприємств. До прикладів такого типу належать: 
розробка нової продукції, створення концептуальних проєктів, інженерне 
проектування тощо. 
Адміністративний документообіг охоплює процеси, які раніше 
здійснювались виключно в паперовому вигляді. Його основне завдання — 
обробка звітності щодо адміністративних витрат. Замість заповнення паперової 
форми, працівник заповнює електронний аналог і надсилає його адресату 
електронною поштою. 
16 
1.1.3 Навіщо потрібен електронний документообіг. Ефективна праця 
персоналу завжди є основою якісного надання послуг населенню. У сучасних 
умовах традиційні методи обробки інформації втрачають свою актуальність, що 
зумовлює потребу в оптимізації витрат часу та ресурсів шляхом впровадження 
сучасних інформаційних технологій. 
Електронний документообіг виступає прогресивним і технологічно 
обґрунтованим способом підвищення ефективності та оперативності роботи як 
державних установ, так і комерційних організацій. 
Автоматизоване копіювання документів, відстеження їх переміщення у 
межах підприємства та контроль за збереженням конфіденційності суттєво 
знижують навантаження на працівників та втрати робочого часу. Завдяки 
можливості контролю кожного етапу роботи через автоматизовану систему 
підвищується якість виконання службових обов’язків, забезпечується більш 
точне планування термінів виконання доручень, що, у свою чергу, розширює 
управлінські можливості щодо персоналу. 
Системи електронного документообігу часто інтегруються з 
універсальними сховищами даних, що дозволяє ефективно структурувати, 
об’єднувати та обробляти інформацію. Це значно спрощує процес підготовки 
звітності, прискорює її аналіз та забезпечує виявлення закономірностей у 
великих обсягах даних, що є основою для прийняття обґрунтованих 
управлінських рішень. 
Усі ці переваги характерні саме для електронного документообігу, який 
значно перевершує традиційний паперовий формат з точки зору організації, 
надійності та оперативності роботи з документами. Такі системи не лише 
автоматизують та централізують процеси обміну інформацією, а й забезпечують 
збирання даних лише з релевантних джерел. Вони сприяють зміцненню 
організаційної культури, підвищуючи продуктивність, ефективність та 
значущість праці діловодів. Окрім цього, електронні системи сприяють 
спільному розв’язанню завдань та забезпечують швидший перехід організацій на 
якісно новий рівень обслуговування клієнтів. 
17 
1.1.4 Основні принципи електронного документообігу. Основні 
принципи організації електронного документообігу включають: 
1) єдину реєстрацію кожного документа з метою його однозначної 
ідентифікації в системі; 
2) можливість одночасного виконання кількох операцій із документом 
для зменшення часу його обробки та підвищення оперативності документообігу; 
3) забезпечення безперервного контролю за переміщенням документа, що 
дозволяє на будь-якому етапі життєвого циклу визначити відповідальну особу; 
4) усунення дублювання документів завдяки застосуванню 
централізованої або узгодженої розподіленої бази даних; 
5) ефективну реалізацію функції пошуку електронної документації з 
можливістю швидкого знаходження потрібного документа за мінімальним 
набором ключових слів; 
6) гнучку систему формування звітності за різними статусами документів 
та їхніми атрибутами, що сприяє покращенню контролю за обігом документації 
на всіх етапах та спрощує ухвалення управлінських рішень на основі аналітичних 
даних; 
7) розгляд документообігу як складової частини інформаційного 
забезпечення організації, що передбачає обробку, передачу, отримання та 
подальше використання інформаційних потоків всередині підприємства. 
До недавнього часу паперовий і електронний документообіг розглядалися 
окремо, однак сьогодні набуває поширення змішаний підхід, що поєднує 
переваги класичних методів діловодства із сучасними цифровими технологіями 
створення, опрацювання та пересилання документації. 
У практиці вітчизняного діловодства й досі застосовується поєднання обох 
форматів документообігу. При цьому в адміністративних центрах і великих 
містах спостерігається тенденція до переважного використання саме 
електронного формату. 
Паперовий документообіг переважає в окремих сферах, де обробляються 
документи з підвищеним рівнем конфіденційності. 
18 
Отже, сучасний документообіг підприємств переважно реалізується у 
вигляді гібридної моделі, у якій пріоритет надається цифровим технологіям. Це 
означає, що створення документації здебільшого відбувається за допомогою 
комп’ютерної техніки, тоді як її обробка, передача та зберігання можуть 
здійснюватися як у цифровому, так і в паперовому вигляді. 
Документообіг в організації формується на основі трьох основних 
інформаційних потоків: вхідного, вихідного та внутрішнього. 
Вхідний та вихідний потоки забезпечують рух зовнішньої кореспонденції, тоді 
як внутрішній потік охоплює переміщення документації між підрозділами 
підприємства. 
Внутрішні документи — це документація, що створюється у межах 
функціональних потреб організаційних підрозділів відповідно до внутрішніх 
нормативів, встановлених посадовими особами. Інакше кажучи, це документи, 
що виникають у процесі повсякденної діяльності підприємства [3]. 
Схематичну організацію роботи з внутрішніми документами організації 
представлено на рисунку 1.1. 
 
Рисунок 1.1 – Загальна організація роботи з внутрішніми документами 
заданого підприємства 
Вхідні документи — це інформаційні матеріали, що надходять до 
підприємства ззовні за допомогою різноманітних засобів зв’язку [3]. 
19 
Структура обробки вхідної документації на підприємстві представлена на 
рисунку 1.2. 
 
 
Рисунок 1.2 – Загальна організація роботи з вхідними документами 
підприємства 
Вихідна документація — це документи, що формуються всередині 
організації та передаються до підлеглих структур з метою виконання вказівок 
керівних органів. 
Візуальна схема обробки вихідних документів представлена на 
рисунку 1.3. 
20 
   
Рисунок 1.3 – Загальна організація роботи з вихідними документами 
підприємства 
1.2 Актуальні проблеми традиційного та електронного 
документообігу 
У реальній практиці як великі підприємства, так і представники малого та 
середнього бізнесу часто мають віддалені структурні підрозділи, де управління 
документаційними процесами є фрагментарним або взагалі нерозвиненим. 
Оскільки документообіг є фундаментальною частиною управлінської 
діяльності, належна його організація суттєво впливає на оперативність та 
ефективність прийняття рішень. 
У зв’язку з інтенсивним розвитком цифрових технологій стало 
очевидним, що класичні методи організації документообігу не відповідають 
вимогам сучасного бізнес-середовища. Застосування виключно паперових 
засобів діловодства зумовлює низку поширених проблем: 
21 
 затримки в доставці вихідних документів адресатам, що приймають 
рішення, а також імовірність виникнення інформаційних розбіжностей; 
 ризик витоку конфіденційної інформації третім особам чи конкурентам; 
 значні часові витрати на обробку вхідної та внутрішньої документації і 
ознайомлення з її змістом; 
 затримки у створенні та погодженні документів, що негативно впливають 
на оперативність реагування; 
 зберігання великої кількості документів незрозумілого походження; 
 можливість втрати важливої інформації; 
 недостатній контроль за виконавцями та повільне виконання 
розпоряджень; 
 відсутність фіксації історії роботи з конкретними документами; 
 зайві витрати часу на пошук необхідних матеріалів, організацію каталогів 
та тематичних добірок; 
 надмірне використання паперу та ресурсів на створення копій документів. 
Усе це ускладнює процес прийняття рішень, призводить до дублювання 
управлінських дій і втрати контролю за документообігом. Керівництво 
організації не може ефективно моніторити діяльність підрозділів, хід 
погодження документів та дотримання затверджених регламентів. 
Щоб оптимізувати ці процеси, багато компаній намагаються 
впроваджувати технологічні рішення. Втім, обрані інструменти не завжди 
відповідають специфіці діяльності підприємства. Наприклад, організація 
спільного доступу до документів через файловий сервер або використання 
електронної пошти може бути ефективною лише на початкових етапах 
становлення організації. У разі зростання структури підприємства ці підходи 
втрачають актуальність. 
У такій ситуації виникає потреба у впорядкуванні інформаційних і 
управлінських процесів. 
22 
Одним із варіантів вирішення є впровадження автоматизованої системи 
електронного документообігу. Однак разом із перевагами такі системи 
супроводжуються певними викликами, зокрема: 
 небезпека несанкціонованого доступу до конфіденційних матеріалів; 
 ймовірність втрати даних через технічні збої, людський фактор, віруси 
або хакерські атаки. 
До нормативних проблем можна віднести: 
 нечітке законодавче регулювання щодо юридичної сили електронних 
документів; 
 відсутність державного стандарту, що забезпечував би єдині вимоги до 
роботи з електронними документами; 
 брак методичних рекомендацій щодо оцінки якості цифрових документів 
та їх архівації. 
Як паперовий, так і електронний документообіг мають свої переваги і 
недоліки. Паперові носії зручні для візуального сприйняття, але поступаються 
електронним у швидкості передачі, копіюванні та зберіганні. 
У сучасних умовах найбільш ефективним вважається комбінований 
підхід, що забезпечує використання обох форматів відповідно до характеру 
конкретних управлінських завдань. Такий підхід дозволяє підвищити якість, 
надійність і швидкість документообігу в межах підприємства. 
1.3 Переваги електронного документообігу порівняно з традиційним 
паперовим 
Більшість організацій визнають обмеження та недоліки паперової форми 
документообігу (див. рисунок 1.4) і все частіше обирають електронні рішення 
(див. рисунок 1.5), що забезпечують ряд суттєвих переваг, зокрема: 
 можливість швидкого пошуку документів за різноманітними 
критеріями; 
 ефективний контроль за виконанням доручень і завдань, пов’язаних із 
документами; 
23 
 автоматична реєстрація документації у відповідних журналах і базах; 
 зручне внесення резолюцій безпосередньо у систему; 
 підтримка спільної обробки документів у мережевому середовищі; 
 гнучка система розмежування прав доступу до документів і 
функціоналу системи; 
 можливість ведення кількох незалежних каталогів або картотек; 
 підтримка роботи з чернетками та проєктами документів; 
 класифікація документів у віртуальні "папки" відповідно до етапів їх 
обробки: нові, у процесі виконання, на контролі тощо; 
 генерація типових та індивідуальних звітів за різними параметрами; 
 швидкий і зручний обмін документами через електронну пошту; 
 автоматичне списання документів у справу з фіксацією всіх змін; 
 можливість відстеження маршрутів переміщення як оригіналів, так і 
копій документів, ведення відповідних реєстрів внутрішнього обігу; 
 підтримка баз даних посадових осіб, організацій, тематичних категорій 
та класифікацій документів; 
 редагування шаблонів вихідних документів і форм з можливістю 
подальшого друку. 
Паперовий документообіг 
Доступ 
Сортування 
18%  12%  Розмноження 
11 % Перевірка 
Робота над вмістом 
5%  
21%  
Введення інформації 
13 % 
Зберігання 
12 % 8%  
Маршрутизація 
   
Рисунок 1.4 – Розподіл обов’язків при використанні традиційного паперового 
документообігу 
24 
Електронна форма документообігу суттєво підвищує продуктивність праці 
персоналу, демонструючи значну перевагу в порівнянні з класичним паперовим 
способом роботи з документами. 
Електронний документообіг 
Доступ 
5 % Сортування 
5 % 5 % 5 % 
5 % 2 % Розмноження 
8 % 
Перевірка 
Робота над вмістом 
Введення інформації 
Зберігання 
65 % Маршрутизація 
  
Рисунок 1.5 – Розподіл робіт з використанням електронного документообігу 
Запровадження системи електронного документообігу дозволяє істотно 
скоротити кількість працівників, задіяних у процесах обробки документації 
(наприклад, кур'єрів, працівників канцелярій тощо). Як показано на наведеній 
схемі, перехід від паперової форми до електронної суттєво зменшує тривалість 
окремих етапів документообігу. 
Завдяки цьому компанії можуть оперативніше реагувати на зовнішні зміни, 
зокрема, на нові вимоги щодо структури та формату звітної документації. 
1.4 Реалізація електронного документообігу 
1.4.1 Необхідні умови для впровадження електронного 
документообігу. Електронний документообіг – це технологічне рішення, що 
значно підвищує ефективність організаційної діяльності. Проте його 
25 
імплементація потребує ретельної підготовки, оскільки без належної оцінки 
рівня готовності компанії існує ризик порушення її операційної стабільності. 
Серед обов’язкових умов для впровадження такої системи: 
– кожен працівник повинен мати персональний комп’ютер із доступом до 
системи; 
– обчислювальна техніка має бути достатньо потужною для підтримки 
відповідного програмного забезпечення; 
– керівництво повинно бути готовим до впровадження електронного 
цифрового підпису; 
– наявність стабільного та безпечного інтернет-з’єднання; 
– функціонування служби технічної підтримки, яка забезпечує 
обслуговування апаратних засобів і програм, а також можливість друку й 
сканування документів. 
Якщо працівники не мають доступу до системи або потрібного 
обладнання, їх участь в електронному документообігу стає обмеженою — вони 
змушені працювати лише з друкованими копіями, без змоги повноцінно 
взаємодіяти з електронною системою. 
Для впровадження електронного документообігу підприємству також 
необхідно оновити інфраструктуру, змінити внутрішні процеси та провести 
навчання персоналу. Щоб полегшити запуск, систему можна впроваджувати 
поетапно — спочатку у межах окремих підрозділів, поступово об’єднуючи їх у 
загальну мережу. 
Електронний документообіг має бути інтегрований з іншими 
корпоративними системами для досягнення максимальної ефективності. 
Попереднє ознайомлення співробітників із основами роботи в системі 
(електронна пошта, обмін документами, система резолюцій тощо) значно 
полегшує перехід. 
Також важливо забезпечити використання електронного підпису та 
інструментів цифрової ідентифікації. Враховуючи проблему цифрової 
нерівності, система повинна мати механізми для оцифровування паперових 
26 
документів, щоб не обмежувати права користувачів, які не мають доступу до 
Інтернету. 
1.4.2 Забезпечення процесу підготовки документів. У більшості 
випадків підготовка документів здійснюється у цифровій формі. Такий підхід 
поступово стає звичним, оскільки не передбачає кардинальних змін у процесах і 
водночас сприяє їх оптимізації. 
Серед переваг електронного документообігу: 
– можливість автоматизації процесів візування, погодження та підписання 
документів за допомогою ЕЦП; 
– централізоване зберігання документів у спільному сховищі, що включає 
поточні, неформальні та архівні документи; 
– ефективне використання інформації, створеної іншими підрозділами 
(аналітика, звіти, дослідження), для підвищення якості управлінських рішень. 
Висновки до розділу 1 
Враховуючи проблему цифрової нерівності, система повинна мати 
механізми для оцифровування паперових документів, щоб не обмежувати права 
користувачів, які не мають доступу до Інтернету. 
 
  
27 
2 ОГЛЯД СИСТЕМ ЕЛЕКТРОННОГО ДОКУМЕНТООБІГУ 
Система електронного документообігу призначена для автоматизації та 
оптимізації всього життєвого циклу документів, що сприяє підвищенню 
ефективності управління бізнес-процесами та покращенню координації між 
працівниками організації. Центральним елементом таких систем є документ, 
який зазвичай представлений у вигляді неструктурованого текстового файлу.  
Системи електронного документообігу зазвичай включають модулі для 
автоматизації ділових процесів, що забезпечують колективну роботу над 
документами, інструменти для супроводу діловодних процедур, а також архів 
електронної документації. Водночас важливо розмежовувати поняття 
"діловодство" та "документообіг": діловодство описує сукупність правил і 
процедур, які можуть бути реалізовані у межах системи електронного 
документообігу [5]. 
Існують кілька основних типів систем, на які орієнтуються розробники 
електронного документообігу: 
Універсальні системи електронного документообігу: 
 містять базовий функціонал без додаткових можливостей; 
 не передбачають гнучкого налаштування під конкретні потреби 
підприємства; 
 мають невеликі витрати на впровадження; 
 характеризуються доступною ціною; 
 постачаються з відповідною ліцензією. 
Індивідуально розроблені системи електронного документообігу: 
 найточніше відповідають специфічним вимогам замовника; 
 потребують значних часових витрат для впровадження; 
 мають високу вартість розробки та інтеграції; 
 вимагають підготовки персоналу і закупівлі додаткових технічних 
ресурсів. 
Комплексні системи електронного документообігу: 
28 
 базуються на модульному підході; 
 повною мірою задовольняють потреби організації; 
 передбачають помірні витрати на введення в експлуатацію; 
 забезпечують повний набір прав на використання продукту; 
 прості у впровадженні та експлуатації. 
За функціональним призначенням системи поділяються на: 
Електронний архів — орієнтований на ефективне зберігання та пошук 
інформації. Такі системи зазвичай мають можливості повнотекстового та 
розширеного пошуку, використовують сучасні бази даних і можуть 
інтегруватися з іншими інформаційними системами. 
Системи підтримки робочих процесів — забезпечують автоматизацію 
руху документів згідно з визначеними маршрутами або правилами. Кожен етап 
процесу може включати можливість редагування документів. Ці системи 
доцільно застосовувати, коли структура обробки документів відома заздалегідь. 
Комплексні системи документообігу — поєднують можливості 
електронного архіву та підтримки робочих процесів. Вони особливо актуальні 
для державних установ або великих організацій, де потрібна гнучка система 
налаштувань і управління маршрутизацією документів. Такі системи мають 
модулі адміністрування, спільної роботи, розвинуті інтеграційні можливості, 
підтримують масштабування і можуть впроваджуватися поступово. Основна 
мета — забезпечення ефективної колективної роботи з документами за 
мінімальних витрат часу та ресурсів [5]. 
2.1 Типові вимоги до систем електронного документообігу 
Система електронного документообігу повинна відповідати таким 
ключовим критеріям: 
 гарантувати безпечне та надійне зберігання електронної документації; 
 забезпечувати повний цикл роботи з документом: створення, 
редагування, публікацію, контроль конфіденційності та архівування; 
29 
 підтримувати обробку різних форматів документів і пов’язаних із ними 
даних; 
 реалізовувати механізми категоризації для зручного пошуку; 
 забезпечувати як частковий, так і повнотекстовий пошук документів; 
 дозволяти налаштування прав доступу на основі ролей у межах 
організаційної структури; 
 зберігати історію дій з документами, підтримувати функції контролю й 
адміністрування; 
 надавати можливість віддаленого доступу до системи. 
Сучасна система також повинна відповідати додатковим технічним 
вимогам: 
 використовувати кластеризовані бази даних для забезпечення стабільної 
роботи; 
 підтримувати функціонування у розподілених територіальних 
структурах; 
 застосовувати сучасні алгоритми шифрування для захисту даних при 
збереженні та передаванні; 
 забезпечувати підтримку цифрового підпису. 
Архітектурні вимоги включають: 
 наявність сервера додатків; 
 можливість роботи через веббраузер; 
 масштабованість системи відповідно до потреб організації. 
Вимоги щодо інтеграції: 
 сумісність з хмарними або онлайн-сервісами для обробки документів; 
 інтеграція з поштовими службами; 
 підтримка API для розширення функціональності; 
 адаптивність інтерфейсу для різних сценаріїв використання; 
 можливість додавання спеціалізованих модулів до системи. 
 
 
30 
2.2 Огляд компонентів систем електронного документообігу 
На рисунку 2.1 подано загальну схему компонентної архітектури системи 
електронного документообігу. Основні складові включають: 
 Клієнтське робоче місце — застосунок, що забезпечує користувачеві 
інтерфейс для взаємодії з системою та управління нею; 
 Сервер додатків — обробляє бізнес-логіку, пов’язану з процесами 
роботи з документами; 
 Сервер бази даних — відповідає за зберігання інформації та надання 
доступу до даних. 
Система також передбачає інтеграцію через API, що підвищує її 
адаптивність і дозволяє поєднувати функціональність з іншими інформаційними 
платформами. API побудовано за принципами REST і базується на HTTP-
протоколі, що забезпечує сумісність і гнучкість у передачі даних. 
 
Рисунок 2.1 – Компоненти системи електронного документообігу та 
інфраструктури 
31 
Серед основних перешкод, з якими стикаються організації під час 
впровадження та обслуговування систем електронного документообігу, можна 
виділити такі: 
 небажання співробітників змінювати звичний підхід до роботи, низький 
рівень цифрової грамотності та страх перед контролем з боку керівництва; 
 відмова від використання комп’ютерної техніки й роботи з 
електронними файлами; 
 часті структурні зміни в організації та зміни бізнес-процесів; 
 необхідність взаємодії з контрагентами, які працюють виключно з 
паперовими документами. 
2.3 Огляд провідних систем електронного документообігу 
На сучасному українському ринку представлено широкий спектр систем 
електронного документообігу, що відповідають різним вимогам та масштабам 
діяльності підприємств. Нижче подано короткий огляд кількох популярних 
рішень: 
   Docs Fusion (розробник — Hummingbird). Ця система є однією з найбільш 
відомих і широко впроваджених у світі. В Україні вона використовується багатьма 
компаніями та організаціями. Docs Fusion підтримує спільну роботу з 
документами, масштабована для підприємств із великою кількістю 
співробітників, а також підходить для середнього бізнесу. Ідеально підходить для 
організацій з високою інтенсивністю документообігу. 
   Documentum Потужна система, орієнтована на потреби великих 
компаній. В Україні почала впроваджуватись порівняно недавно. Пропонує 
платформу для створення розподілених електронних архівів, управління 
командною роботою над проєктами, діловодством, та контентом вебпорталів 
підприємств. Відзначається високим рівнем відповідності корпоративним 
стандартам. 
32 
   FossDoc (платформа FossLook) Система орієнтована на створення 
внутрішніх електронних архівів, організацію документообігу всередині 
підприємств та автоматизацію бізнес-процесів. Гнучка модульна структура 
FossDoc дозволяє адаптувати систему під специфіку кожного підприємства. 
Архітектура побудована з розподілених компонентів: сервер додатків і база даних 
працюють на окремих пристроях, з’єднаних між собою. Схему архітектури 
представлено на рисунку 2.2. 
 
Рисунок 2.2 – Архітектура системи FossDoc. 
Система "Док Проф" автоматизує повний цикл обробки документів: від 
їх внесення в систему до реєстрації, розподілу, редагування, зберігання, 
пошуку, контролю виконання та інших етапів документообігу. 
Система електронного документообігу "Док Проф" реалізує такі ключові 
функції: 
 повна реєстрація, обробка, передача та контроль вхідних, вихідних, 
внутрішніх, службових документів, звернень громадян і розпорядчих 
документів; 
 нанесення штрих-кодів на документи; 
 налаштування маршрутів руху документів; 
 використання шаблонів документів і типових резолюцій; 
33 
 обробка запитів на отримання публічної інформації; 
 автоматизація діяльності центрів надання адміністративних послуг. 
Система працює з електронними документами, а також з паперовими, 
інформація про які вноситься в систему. Усі документи – згідно з визначеним 
регламентом – передаються між автоматизованими робочими місцями 
користувачів. Працівники, відповідно до своїх обов’язків, здійснюють дії щодо 
обробки документів. 
"Док Проф" також дозволяє створювати пакети публічної інформації (у 
вигляді даних або електронних копій документів) для розміщення на веб-сайтах 
організацій . 
2.4 Основні характеристики ефективної системи електронного 
документообігу 
Правильний вибір СЕДО є важливим завданням для більшості українських 
компаній, особливо новостворених. Для впорядкування документообігу 
необхідно забезпечити збереження даних, швидкий доступ до них і своєчасну 
доставку користувачам. 
Основна мета впровадження таких систем — оптимізація управління 
великими обсягами документів, організація контролю доступу, забезпечення 
ефективної передачі інформації та контроль за використанням документів. 
Сучасні СЕДО підтримують роботу з різними форматами файлів: текстовими 
документами, таблицями, мультимедіа, веб-документами тощо. 
Щоб система відповідала вимогам бізнесу, вона має включати такі 
властивості: 
 Масштабованість — здатність підтримувати необхідну кількість 
користувачів і розширювати ресурси при зростанні навантаження. 
 Розподіленість — можливість розміщення компонентів системи на різних 
географічних ділянках та підтримка взаємодії між ними. 
 Модульність — поділ системи на незалежні компоненти, що дозволяє 
впроваджувати її поетапно. 
34 
 Відкритість — підтримка інтеграції з іншими інформаційними системами 
через відкриті API. 
 Надійність — стабільна робота системи, включаючи обробку помилок і 
резервне копіювання. 
 Захищеність — контроль доступу до документів і захист інформації від 
несанкціонованого втручання. 
 Доступність — можливість доступу до системи через різні пристрої 
(браузер, десктоп, мобільні клієнти). 
Висновки до розділу 2 
Сьогодні більшість підприємств орієнтуються на впровадження 
програмних рішень, які забезпечують не лише управління документообігом, але 
й підтримку ключових бізнес-процесів, забезпечують ефективну комунікацію 
всередині організації та інтеграцію з іншими платформами. 
  
35 
3 АНАЛІЗ МОЖЛИВОСТЕЙ ТЕХНОЛОГІЇ БЛОКЧЕЙН 
Недоліки сучасних систем електронного документообігу зумовлюють 
підвищену зацікавленість у впровадженні блокчейн-технологій у цій сфері. Як 
зазначають експерти, блокчейн має потенціал для застосування у будь-яких 
процесах, пов’язаних із реєстрацією, обліком чи передачею різних видів активів 
— фінансових, матеріальних або нематеріальних. При цьому особливості 
блокчейн-сервісу, кількість учасників чи їхнє географічне розташування не є 
критичними факторами. 
Перші пілотні проєкти із використанням блокчейн-технологій у 
публічному адмініструванні з’явилися у 2018 році в таких країнах, як Швеція, 
Грузія, Гана, Естонія, а також в окремих адміністративних одиницях Японії та 
США (наприклад, у штаті Делавер і місті Чикаго) [8]. 
Варто підкреслити, що світова тенденція у впровадженні блокчейн-рішень 
базується на ретельному аналізі ризиків і можливих негативних наслідків від їх 
використання. Більшість великих компаній та організацій поки що перебувають 
на стадії дослідження, тестування або розробки таких систем. Наприклад, у 
Швеції ще у 2016 році було розпочато масштабне дослідження можливостей 
застосування блокчейна для переведення системи ведення земельного реєстру на 
нову технологічну платформу. Передбачалося, що кожен об’єкт нерухомості 
отримає так званий «блокчейн-паспорт» із вказаними технічними 
характеристиками об’єкта. Це значно спростить і пришвидшить оцінку об’єктів 
нерухомості, оскільки наразі для кожної угоди доводиться готувати документи з 
нуля. 
Впровадження блокчейн-технологій у документообіг дозволяє забезпечити 
високу надійність синхронізації даних, унеможливлює їх підміну внаслідок 
зовнішнього втручання, гарантує прозорість системи та створює умови для 
ефективного громадського контролю. 
 
 
36 
3.1 Використання блокчейн у побудові програмних продуктів 
Платформа блокчейн розглядається як децентралізована розподілена база 
даних, що функціонує без централізованого контролю або нагляду, надаючи 
можливість спільного доступу до інформації. Ця технологія дозволяє безпечно 
виконувати транзакції, здійснювати облік, зберігати дані й може бути 
застосована в різних галузях — від операцій з нерухомістю й страхування до 
логістики, державних реєстрів, судочинства тощо. 
Вперше блокчейн був використаний у 2009 році при створенні 
криптовалюти біткоїн. З того часу технологія активно інтегрується в інші сфери. 
Наприклад, у Китаї блокчейн вже використовується в роботі фонду 
національного страхування та впроваджується у створення «розумних міст». На 
основі блокчейну створюються медичні рішення, платформи захисту 
авторських прав і патентів, системи електронної ідентифікації, браузери, 
сервіси зберігання даних, месенджери й соціальні мережі. 
Особливої популярності набули смарт-контракти — програми, що 
працюють на блокчейн-платформах, автоматизуючи укладення та виконання 
угод без участі третіх сторін. Вперше смарт-контракти з’явилися у мережі 
Ethereum. Вони функціонують на основі заздалегідь визначених умов, 
закладених у код, та забезпечують конфіденційність, прозорість і гарантоване 
виконання угод. Кожен учасник має змогу перевірити стан виконання договору 
в будь-який момент. 
Один із яскравих прикладів використання цієї технології — угода між 
ірландською компанією та замовником із Сейшельських островів, укладена 
через платформу Wave у 2016 році. Вартість угоди становила 100 тисяч доларів, 
і її реалізація тривала всього чотири години замість звичних кількох днів. 
 
 
37 
3.2 Архітектура та принцип дії блокчейн-технології 
Блокчейн являє собою розподілену базу даних, у якій зберігається 
інформація про кожну здійснену транзакцію. Всі записи формуються у вигляді 
послідовного ланцюжка блоків (звідси й назва — «blockchain»), кожен з яких 
містить хеш попереднього, забезпечуючи незмінність структури. Будь-яке 
втручання в один блок потребує змін у всьому ланцюгу, що практично 
неможливо. 
Усі користувачі системи мають актуальну версію даних, яка автоматично 
оновлюється після кожної нової транзакції. Така архітектура забезпечує високу 
прозорість, надійність і децентралізованість обміну інформацією. 
Нові блоки формуються регулярно та містять певну кількість 
впорядкованих транзакцій, а також заголовок з технічною інформацією. 
Приклад структури блоку наведено на рисунку 3.1. 
 
  
Рисунок 3.1 – Схематичне представлення блоку у блокчейні 
38 
Транзакції у блокчейні — це будь-які дії, що здійснюються 
користувачами в межах мережі, зокрема: переказ коштів, реєстрація майнових 
прав, купівля товарів тощо. Після створення транзакції вона надходить до 
спеціального «мемпулу» — області пам’яті, де зберігається до моменту 
включення в блок. Лише після додавання до блоку транзакція вважається 
підтвердженою. 
Формування нового блоку супроводжується його перевіркою іншими 
вузлами мережі. Після досягнення консенсусу серед учасників, блок вважається 
дійсним і приєднується до кінця вже наявного ланцюга. З цього моменту будь-
які зміни в записаній інформації стають неможливими. 
Крім нових транзакцій, кожен блок містить зашифровану інформацію про 
попередній блок, утворюючи таким чином безперервний ланцюг (див. рис. 3.2). 
Оновлення даних відбувається автоматично на всіх пристроях, 
підключених до мережі. Після завершення цього процесу майнери (або 
валідатори) починають створення наступного блоку. 
 
Рисунок 3.2  –  Ключі до блоків 
Транзакції у блокчейні - це будь-які дії, що здійснюються користувачами 
в межах мережі, зокрема: переказ коштів, реєстрація майнових прав, купівля 
товарів тощо. Після створення транзакції вона надходить до спеціального 
39 
«мемпулу» — області пам’яті, де зберігається до моменту включення в блок. 
Лише після додавання до блоку транзакція вважається підтвердженою. 
Формування нового блоку супроводжується його перевіркою іншими 
вузлами мережі. Після досягнення консенсусу серед учасників, блок вважається 
дійсним і приєднується до кінця вже наявного ланцюга. З цього моменту будь-
які зміни в записаній інформації стають неможливими. 
Висновки до розділу 3 
Крім нових транзакцій, кожен блок містить зашифровану інформацію про 
попередній блок, утворюючи таким чином безперервний ланцюг (див. 
рисунок 3.2). 
Оновлення даних відбувається автоматично на всіх пристроях, 
підключених до мережі. Після завершення цього процесу майнери (або 
валідатори) починають створення наступного блоку. 
  
40 
4 РОЗРОБЛЕННЯ СИСТЕМИ ЕЛЕКТРОННОГО 
ДОКУМЕНТООБІГУ  
4.1 Постановка завдання 
Планується створення універсальної системи електронного 
документообігу, яка сприятиме оптимізації та прискоренню процесів роботи з 
документацією. Така система має відповідати низці ключових вимог: 
 має бути реалізована чітка модель розмежування доступу, з 
підтримкою щонайменше двох ролей: адміністратора та користувача; 
 доступ до системи повинні мати виключно користувачі, попередньо 
зареєстровані адміністратором; 
 додаток повинен підтримувати кросплатформенність і коректно 
функціонувати на різних операційних системах та пристроях; 
 система має бути галузевонезалежною, із можливістю налаштування 
під потреби конкретної організації з боку адміністратора; 
 адміністратор повинен мати доступ до таких функцій, як управління 
користувачами, групами, каталогами, а також можливість видаляти файли; 
 кожен документ має супроводжуватися збереженням відповідних 
метаданих; 
 користувачам має бути доступна функціональність щодо: 
завантаження та видалення файлів, встановлення терміну їх зберігання, 
додавання коментарів і надсилання сповіщень іншим користувачам електронною 
поштою; 
 інтерфейс системи повинен бути мінімалістичним, не 
перевантаженим візуальними елементами; 
 особлива увага повинна бути приділена зручності використання – 
інтерфейс має бути інтуїтивно зрозумілим навіть для нових користувачів. 
 
41 
4.2 Функціональний опис системи 
Користувацька модель системи електронного документообігу описує 
функціональні можливості програмного продукту з точки зору кінцевого 
користувача та передбачає характер взаємодії з інтерфейсом додатку. 
Згідно з підходом Microsoft Solution Framework, процес проектування 
починається з аналізу потреб і типів користувачів, для яких формується набір 
сценаріїв використання. Кожен сценарій деталізується через послідовність дій, 
що мають назву «випадки використання» (use cases). 
Веб-застосунок «BlockDoc» передбачає два основних типи користувачів: 
 Користувач — штатний співробітник організації; 
 Адміністратор — відповідальна особа з розширеними правами 
керування системою. 
Загальні функції, доступні всім авторизованим користувачам: 
 Авторизація в системі. Вхід до системи здійснюється за логіном 
(електронна пошта) та паролем. Успішна авторизація відкриває доступ до 
дозволених функцій залежно від ролі. 
 Перегляд метаданих файлу. Відображається інформація про назву 
файлу, дату створення, автора, розмір і термін зберігання. 
 Видалення файлу. Можливе лише для власника або адміністратора. 
Разом з файлом видаляються всі його версії. 
 Завантаження файлу або його версії. Можна зберегти доступний файл 
чи одну з його версій, обравши цільову папку. 
 Перегляд доступу до файлу. Користувач бачить, яким групам та іншим 
користувачам надано доступ до конкретного файлу. 
 Перегляд завдань, пов’язаних з файлом. Відображаються всі завдання, 
призначені до даного файлу із зазначенням автора, виконавця та статусу 
виконання. 
42 
 Перегляд користувачів і груп. Можна переглядати списки всіх 
користувачів, їхні ПІБ, посади, e-mail, а також інформацію про існуючі групи та 
їхній склад. 
Додаткові функції адміністратора: 
 Керування користувачами: 
 додавання нового користувача з повними даними; 
 редагування існуючої інформації (ПІБ, посада, логін, пароль); 
 тимчасове видалення або відновлення користувача. 
 Управління групами: 
 створення нових груп; 
 видалення існуючих; 
 додавання або виключення користувачів з груп. 
 Керування завданнями: 
 створення нового шаблону завдання; 
 видалення застарілих завдань; 
 перегляд усіх завдань, створених адміністратором. 
Функціональні можливості звичайного користувача: 
 Додавання нового файлу. Користувач вказує назву, додає коментар, 
вибирає файл та задає термін його зберігання. Інші поля (дата, розмір, власник) 
генеруються автоматично. Файл за замовчуванням доступний усім. 
 Перегляд власних файлів. Виводиться таблиця з інформацією про всі 
файли, які було додано користувачем. 
 Призначення завдань до файлу. Користувач може обрати тип 
завдання, виконавця та створити завдання. Система автоматично реєструє 
автора, статус і черговість виконання. 
 Редагування доступу до файлів. Можна обмежити або надати доступ 
до файлу окремим користувачам або групам. 
 Робота із завданнями. Перегляд власних завдань: відображаються всі 
активні завдання, призначені цьому користувачу. 
43 
 Перегляд наданих завдань: список завдань, які користувач створив 
для інших осіб. 
 Позначка про виконання завдання: автор завдання або виконавець 
може відмітити його як виконане. У разі завершення завдання — автор отримує 
повідомлення на електронну пошту. 
4.3 Логічне проектування 
Для моделювання предметної області та відображення специфіки 
структури даних, що обробляються системою, визначено основні сутності: 
 користувач; 
 група; 
 документ; 
 завдання, пов’язані з документами; 
 категорія документів. 
Після аналізу архітектури системи було виокремлено чотири ключові 
групи сервісів, необхідні для реалізації всіх функцій, передбачених 
користувацькою архітектурою: 
 сервіс взаємодії з базою даних; 
 сервіс управління користувачами та групами; 
 сервіс роботи з файлами та категоріями; 
 сервіс обробки завдань. 
Щоб забезпечити чітке розмежування функціональності, кожен з 
компонентів системи реалізовано у вигляді окремого сервісу. 
Сервіс роботи з базою даних. 
Основні функції: 
 встановлення стабільного з'єднання з БД; 
 ініціалізація структури бази даних (створення таблиць, адміністратора 
та кореневого каталогу). 
Сервіс управління користувачами та групами 
Цей модуль забезпечує: 
44 
 автентифікацію користувачів і адміністраторів на основі логіна та 
пароля; 
 отримання інформації про користувача; 
 перегляд списку всіх користувачів і груп; 
 перегляд груп, створених конкретним учасником; 
 перегляд членів окремої групи; 
 додавання, редагування, видалення або відновлення користувачів 
(лише адміністратором); 
 створення або видалення груп; 
 додавання або вилучення користувачів у/з груп (доступно лише 
адміністратору). 
Додаткові службові функції: 
 перевірка логіна на відповідність e-mail для надсилання сповіщень; 
 перевірка унікальності логіна; 
 перевірка унікальності імені групи; 
 отримання атрибутів об’єктів. 
Сервіс роботи з файлами та каталогами. 
Основні можливості: 
 створення або видалення каталогів (доступно лише адміністратору); 
 перегляд вмісту каталогів відповідно до рівня доступу користувача; 
 додавання файлів із заповненням метаданих (коментарі, термін 
зберігання, автор); 
 видалення файлів (доступно адміністратору або автору); 
 перегляд інформації про файл; 
 управління доступом до файлу (для всіх користувачів, груп чи 
окремих осіб); 
 робота з версіями файлів: додавання, видалення всіх або частини 
версій; 
 перегляд списку користувачів і груп з доступом до конкретного 
файлу. 
45 
Службові функції: 
 перевірка унікальності імені каталогу; 
 отримання фізичного шляху до файлу/версії; 
 підрахунок кількості версій файлу. 
Сервіс управління завданнями 
Можливості модуля: 
 створення/видалення шаблонів завдань для документів 
(адміністратором); 
 перегляд і вибір завдань; 
 призначення завдань з автоматичним e-mail сповіщенням; 
 перегляд завдань до конкретного файлу; 
 відображення завдань, призначених користувачу чи створених ним; 
 перевірка статусу виконання; 
 підтвердження або відхилення виконання завдань, з повторною 
відправкою. 
Сервіс інтеграції з блокчейном 
Для підвищення безпеки, достовірності та неможливості підробки 
документів реалізовано окремий сервіс із такими функціями: 
 додавання запису в блокчейн; 
 перегляд одного або кількох блоків; 
 створення цифрового підпису для документа; 
 перевірка автентичності документа або підпису. 
4.4 Вибір та обґрунтування компонент 
Під час визначення технологічної основи майбутньої системи були 
враховані ключові вимоги до функціональності та архітектури. 
Кросплатформеність. Зважаючи на необхідність забезпечити роботу 
системи на різних операційних системах, як мову програмування обрано C#, а 
платформу – .NET Core, яка дозволяє створювати кросплатформенні додатки з 
високою продуктивністю. 
46 
Веб-орієнтованість. Оскільки система повинна функціонувати як веб-
додаток, було прийнято рішення використовувати ASP.NET Core у поєднанні з 
шаблоном MVC (Model-View-Controller).  
Веб-додатки забезпечують такі переваги: 
 централізоване збереження та обробка даних за допомогою клієнт-
серверної моделі; 
 автоматична установка без потреби ручної інсталяції; 
 доступність з будь-якого пристрою через браузер і можливість 
дистанційної роботи. 
Реалізація логіки. Модельна частина системи базується на раніше 
визначених сутностях та сервісах. Логіка реалізована через SQL-запити до бази 
даних та взаємодію з файловою системою. Представлення інтерфейсу 
користувача здійснюється за допомогою технології Razor, яка дозволяє 
поєднувати HTML з елементами C#. 
Усі запити користувача обробляються контролерами, які викликають 
відповідні сервіси для виконання бізнес-логіки, а результати обробки 
повертаються у вигляді HTML-сторінок. 
Для кожної функціональної області було створено відповідні CSHTML-
сторінки. Враховуючи поділ користувачів на адміністраторів і звичайних 
користувачів, були розроблені окремі домашні сторінки для кожної ролі. 
Інтерактивність інтерфейсу. Інтерфейс реалізовано з використанням AJAX, 
що забезпечує оновлення контенту сторінки без повного перезавантаження. Це 
дозволяє зробити взаємодію більш швидкою та зручною. 
Для доступу до бази даних використовується технологія ODBC — 
універсальний інтерфейс для роботи з різними SQL-сумісними СУБД, а також з 
іншими табличними структурами, такими як електронні таблиці. 
Інженерні практики. Розробка системи супроводжувалась створенням 
UML-діаграм: 
 компонентів, 
 розгортання, 
47 
 ER-діаграм, 
 класів доменної моделі, 
 варіантів використання, 
 функціональної структури. 
Це дозволило забезпечити структурованість проєкту, модульність і 
масштабованість рішення. 
Інтеграція з блокчейном. Для забезпечення достовірності та незмінності 
даних у системі була реалізована інтеграція з блокчейном. Використано відкриту 
реалізацію Ethereum та бібліотеку Nethereum для C#. Смарт-контракти 
створювалися мовою Solidity. 
Особливості Ethereum:  
Ethereum — децентралізована віртуальна машина для запуску смарт-
контрактів. 
В системі існують два типи акаунтів: 
 зовнішній акаунт (керується приватним ключем); 
 контракт (має код і виконує його при виклику). 
Контракт активується під час отримання транзакції, виконує свій код, 
звертається до внутрішнього сховища, а також може викликати інші контракти. 
Після завершення виконання — «засинає» до наступної транзакції. 
Призначення смарт-контрактів: 
 збереження невеликих обсягів даних; 
 контроль доступу до облікових записів; 
 реалізація фінансових механізмів між користувачами; 
 функціонування як бібліотеки (надання функцій іншим контрактам). 
Контракти взаємодіють між собою через "виклики" — повідомлення, які 
передають ефір, дані та адреси. Контракт, отримавши повідомлення, може 
повернути відповідь, подібно до виклику функції. 
Структура даних Ethereum. Ethereum використовує спеціалізовану 
структуру збереження — дерево Patricia (тип Merkle-дерева), яке дозволяє 
перевіряти цілісність даних через кореневий хеш. Кожен акаунт містить: 
48 
 account_nonce — лічильник транзакцій; 
 ether_balance — баланс ефіру; 
 code_hash — хеш коду (для контрактів); 
 storage_root — корінь дерева даних контракту. 
Ця система дозволяє зберігати інформацію у незмінній, достовірній та 
перевірюваній формі. 
На рис. 4.1 подано приклад структури блокчейн-мережі Ethereum. 
 
 
Рисунок 4.1 – Структура блокчейну Ethereum 
Щохвилини в мережі Ethereum формується новий блок, що відповідає 
концепції майнінгу, подібній до тієї, яка застосовується в системі Bitcoin. Кожен 
блок містить перелік транзакцій, здійснених від моменту створення 
попереднього блоку, а також кореневий хеш дерева Patricia, яке відображає 
оновлений стан системи після застосування цих транзакцій. Додатково майнер 
отримує винагороду в ефірі за успішне створення блоку. 
Завдяки особливостям структури дерева Патриції, при внесенні змін у 
блокчейн більшість його частин залишаються незмінними. Це означає, що в 
новому дереві можуть повторно використовуватись ті ж самі вузли, що й у 
попередньому, оскільки вони не зазнали змін. Таким чином досягається 
49 
ефективне використання пам’яті без дублювання даних, оскільки повторювані 
елементи зберігаються за однією й тією ж адресою в пам’яті [12]. 
Для розробки смарт-контрактів було обрано мову Solidity — 
об’єктноорієнтовану мову високого рівня, створену спеціально для роботи у 
віртуальній машині Ethereum (EVM). Мова була розроблена під впливом C++, 
Python та JavaScript, і підтримує такі можливості, як статична типізація, 
успадкування, використання бібліотек та визначення складних типів 
користувача. 
Завдяки мові Solidity розробники можуть створювати смарт-контракти для 
широкого спектра задач, зокрема: 
 реалізація систем електронного голосування; 
 платформи краудфандингу; 
 реалізація сліпих аукціонів; 
 розробка блокчейн-гаманців. 
У зв’язку з активним розвитком мови, під час створення смарт-контрактів 
доцільно використовувати найновішу стабільну версію Solidity, що дозволяє 
уникнути помилок сумісності та скористатися останніми оновленнями й 
вдосконаленнями. 
Приклад контракту Solidity:  
contract 
SimpleStorage {     
uint storedData;     
function set(uint x) {         
storedData = x;  
    }  
    function get() constant returns 
(uint retVal) {         return storedData;  
    }}  
Оголошення uint storedData визначає змінну стану з ім’ям storedData, яка 
має тип uint — ціле число без знака розміром 256 бітів. Розміщення цієї змінної 
50 
у сховищі контракту визначається автоматично компілятором. Для зміни та 
отримання її значення використовуються функції set та get відповідно. 
Мова Solidity є статично типізованою, що означає: тип кожної змінної, 
незалежно від того, чи вона є глобальною чи локальною, має бути явно вказаним 
або виведеним компілятором під час компіляції. Solidity підтримує низку 
базових типів, які можуть бути об'єднані для створення складніших структур 
даних. 
4.5 Варіанти використання 
У системі реалізовано 21 варіант використання. У додатку А наведено 
діаграму активності, що ілюструє основні процеси, доступні для адміністратора 
системи. Для більш детального аналізу функціонування системи електронного 
документообігу, яка базується на технології блокчейн, у межах даної 
магістерської роботи описано вісім ключових варіантів використання, які 
мають пріоритетне значення. Інші варіанти подано у графічному вигляді у 
додатках Б і В. 
Основними учасниками взаємодії з системою виступають Адміністратор 
і Користувач. 
Нижче наведено детальний опис кожного з варіантів використання. 
Варіант використання 1: Авторизація (Sign in) 
 Учасник: Користувач 
 Мета: Отримання доступу до системи 
 Ініціація: Користувач бажає увійти в систему й відкриває відповідну 
сторінку входу 
 Передумови: Користувач попередньо зареєстрований у системі та 
вводить коректні облікові дані (логін і пароль) 
 Результат: Користувач успішно проходить авторизацію та отримує 
доступ до функціоналу системи 
Основну послідовність дій представлено в таблиці 4.1. 
51 
Таблиця 4.1 – Основна послідовність подій для варіанту використання 1 
№  Дійова особа  Крок  
1 Користувач/Адміністратор  Переходить на сторінку входу 
до системи  
2 Користувач/Адміністратор  Вводить логін та пароль  
3 Система  Перевіряє введені логін та 
пароль користувача  
4 Система  Підтверджує вхід  
5 Користувач/Адміністратор  Переходить на головну сторінку  
 У системі реалізовано 21 варіант використання. У додатку А наведено 
діаграму активності, що ілюструє основні процеси, доступні для адміністратора 
системи. Для більш детального аналізу функціонування системи електронного 
документообігу, яка базується на технології блокчейн, у межах даної 
магістерської роботи описано вісім ключових варіантів використання, які мають 
пріоритетне значення. Інші варіанти подано у графічному вигляді у додатках Б і 
В. Основними учасниками взаємодії з системою виступають Адміністратор і 
Користувач. Нижче наведено детальний опис кожного з варіантів використання. 
Варіант використання 1: Авторизація (Sign in) 
Учасник: користувач 
Мета: отримання доступу до системи 
Ініціація: користувач бажає увійти в систему й відкриває відповідну 
сторінку входу 
Передумови: користувач попередньо зареєстрований у системі та вводить 
коректні облікові дані (логін і пароль) 
Результат: користувач успішно проходить авторизацію та отримує доступ 
до функціоналу системи 
Основну послідовність дій представлено в таблиці 4.1. 
 
 
52 
Таблиця 4.1 – Основна послідовність подій для варіанту використання 1 
№  Дійова особа  Крок  
1  Користувач  Переходить до сторінки завантаження файлу  
2  Користувач  Натискає кнопку «Upload file»  
3  Користувач  Вибирає файл у файловій системі та натискає відправити  
4  Система  Завантажує файл та визначає його метадані  
5  Система  Записує файл на диск для подальшого зберігання  
6  Система  Додає запис про файл у блокчейн  
7  Система  Додає запис про файл до бази даних  
8  Система  Сповіщує користувача про успішне додання файлу  
Варіант використання 3. Verify Document.  
Дійові особи: User.   
Мета: перевірити достовірність документа.   
Тригер: користувач переходить до сторінки перевірки документа та 
натискає кнопку перевірити документ.   
Передумови: користувач зареєстрований в системі та файл вже був 
завантажений до системи раніше.   
Результат: інформація про достовірність файлу чи помилка в разі 
недостовірності.   
Основний потік подій зображено в таблиці 4.3.   
 
 
 
53 
Таблиця 4.3 – Основний потік подій для варіанту використання 3 
№ Дійова особа  Крок  
1 Користувач  Переходить до сторінки перевірки файлу  
2 Користувач  Натискає кнопку «Upload file»  
3 Користувач  Вибирає файл у файловій системі та натискає 
відправити  
4 Система  Завантажує файл та визначає його хеш  
5 Система  Робить запит у блокчейн за хешем файлу  
6 Система  Перевіряє чи співпадає наявний запис із 
збереженим у блокчейн  
7 Система  Сповіщує користувача про успішність перевірки  
 
Варіант використання 4. Sign Document.  
Дійові особи: User.   
Мета: підписати електронний документ.   
Тригер: користувач переходить до сторінки перегляду документів.   
Передумови: користувач зареєстрований в системі та файл для підпису вже 
є наявним у системі.   
Результат: підписаний електронний документ.   
Основний потік подій зображено в таблиці 4.4.   
Таблиця 4.4 – Основний потік подій для варіанту використання 4  
№  Дійова особа  Крок  
1  Користувач  Переходить до сторінки перегляду документів  
2  Користувач  Натискає кнопку «Sign file»  
3  Система  Генерує унікальний підпис на основі даних про 
користувача системи та документа  
4  Система  Записує інформацію про підпис до блокчейн  
6  Система  Сповіщує користувача про успішність/помилку 
підпису за допомогою вікна інформації  
  
54 
Варіант використання 5. Create Task.  
Дійові особи: User.   
Мета: створити завдання для користувача на основі документу.   
Тригер: користувач переходить до сторінки перегляду документів та 
натискає кнопку створити завдання.   
Передумови: користувачі зареєстровані в системі та обраний файл вже є 
завантаженим. 
Результат: створено нове завдання для користувача в системі.   
Основний потік подій зображено в таблиці 4.5.  
Таблиця 4.5 – Основний потік подій для варіанту використання 5  
№  Дійова особа  Крок  
1  Користувач  Переходить до сторінки перегляду документів  
2  Користувач  Обирає потрібний документ  
3  Користувач  Натискає створити завдання  
4  Користувач  Обирає виконавця та вводить текст завдання  
5  Система  Створює нове завдання, пов’язане з документом, з 
даними введеними користувачем   
6  Система  Сповіщує користувача про успішність/помилку 
створення завдання за допомогою вікна 
інформації  
 
Варіант використання 6. Change Document Permission.  
Дійові особи: Admin.   
Мета: надати/припинити доступ інших користувачів до документа.   
Тригер: користувач переходить до сторінки перегляду документів.   
Передумови: користувачі зареєстровані в системі та обраний файл вже є 
завантаженим.   
55 
Результат: зміна параметрів доступу до документа.   
Основний потік подій зображено в таблиці 4.6.  
Таблиця 4.6 – Основний потік подій для варіанту використання 6  
№  Дійова особа  Крок  
1  Користувач  Переходить до сторінки перегляду документів  
2  Користувач  Обирає потрібний документ  
3  Користувач  Натискає кнопку «Change permission»  
4  Користувач  Обирає користувачів яким доступний документ  
5  Система  Зберігає дані про доступ у БД  
  
Варіант використання 7. Create Document Category.  
Дійові особи: User.   
Мета: створити категорію для сортування документів.   
Тригер: користувач переходить до сторінки створення категорій.   
Передумови: користувач зареєстрований в системі.   
Результат: створено нову категорію.   
Основний потік подій зображено в таблиці 4.7.  
Таблиця 4.7 – Основний потік подій для варіанту використання 7  
№ Дійова особа  Крок  
1 Користувач  Переходить до сторінки створення категорії  
2 Користувач  Вводить назву категорії  
3 Користувач  Натискає кнопку «Add Category»  
4 Система  Зберігає дані про нову категорію  
5 Система  Сповіщує користувача про успішність операції  
  
1) Варіант використання 8. Create User.  
Дійові особи: Admin.   
Мета: створити нового користувача в системі.   
Тригер: адміністратор вирішує створити нового користувача.   
56 
Передумови: користувач не був зареєстрований в системі раніше.   
Результат: створено нового користувача.   
Основний потік подій зображено в таблиці 4.8.  
Таблиця 4.8 – Основний потік подій для варіанту використання 8  
№  Дійова особа  Крок  
1  Адміністратор  Переходить до сторінки створення користувача  
2  Адміністратор  Вводить основну інформацію про користувача  
3  Адміністратор  Натискає кнопку «Create»  
4  Система  Перевіряє чи не був користувач з заданими 
даними зареєстрований в системі раніше та 
додає нового користувача до БД  
5  Система  Сповіщує адміністратора про успішність 
створення користувача  
 4.6 Доменна модель 
Проєктування доменної моделі є критичним етапом у процесі створення 
додатку, оскільки воно забезпечує структуроване представлення логіки 
предметної області у вигляді об’єктної моделі. На цьому етапі здійснюється 
аналіз ключових характеристик предметної області та визначаються основні 
сутності, які ляжуть в основу моделі даних системи. 
У даному рішенні виділено дві базові сутності: User (Користувач) та 
Document (Документ). На основі функціональних вимог було розширено модель 
шляхом додавання допоміжних сутностей: Category, Task, DocumentTask, Group, 
UserGroup. 
 Category відповідає за класифікацію документів. Кожен користувач має 
можливість створювати власні категорії, що дозволяє персоналізувати структуру 
даних. 
 Task інкапсулює дані про завдання, пов’язані з певним документом, 
включаючи статус виконання та виконавця. 
 DocumentTask реалізує зв’язок "багато-до-багатьох" між документами та 
завданнями. 
57 
 Group описує логічні об’єднання користувачів, що дозволяє 
реалізовувати групову політику доступу. 
 UserGroup забезпечує асоціацію між користувачами та групами. 
Для підтримки інтеграції з блокчейн-технологією (Ethereum) реалізовано 
окрему сутність DocumentBase, яка зберігає хеш документа та унікальний 
ідентифікатор у мережі блокчейн. 
У якості інструменту для взаємодії з базою даних обрано ORM — Entity 
Framework. Для інкапсуляції доступу до даних застосовано шаблон 
проєктування Repository, що дозволяє створити рівень абстракції між бізнес-
логікою та шаром доступу до даних. Такий підхід спрощує модульне тестування 
та підвищує гнучкість у разі зміни джерела даних. 
Entity Framework працює з сутностями (entity) — класами, які 
відображають об’єкти предметної області. Кожна сутність містить властивості, 
які можуть бути як простими (типу string, int), так і комплексними (наприклад, 
вкладені об’єкти чи колекції). Визначальними властивостями є ключі, які 
ідентифікують об’єкти в межах таблиці. 
Зв’язки між сутностями реалізуються через відповідні типи асоціацій: 
"один-до-одного", "один-до-багатьох", "багато-до-багатьох", аналогічно 
зовнішнім ключам у реляційній БД. 
Для вибірки та маніпуляції даними використовується LINQ (Language 
Integrated Query) — декларативна мова запитів, що дозволяє писати запити до БД 
на C#-подібному синтаксисі. LINQ підтримує витяг пов’язаних об’єктів через 
навігаційні властивості, що суттєво спрощує роботу з асоційованими 
сутностями. 
Кожен клас-сутність має відповідний клас репозиторію та інтерфейс, що 
визначає контракт доступу до даних. Контролери взаємодіють лише з 
інтерфейсами, що дозволяє легко змінювати реалізацію (наприклад, замінити EF 
на інше джерело даних) без модифікації логіки контролера. 
На рисунку 4.2 представлено загальну взаємодію між SQL Server, Entity 
Framework, контекстом даних (DbContext) та основним застосунком. 
58 
 
Рисунок 4.2 – Відношення між компонентами шару доступу до даних 
Таблиця 4.1 – Користувач (User)  
Назва   Тип даних  Опис даних  
UserId  int  Ідентифікатор користувача  
PasswordHash  Varchar  Пароль користувача в системі  
Name  Varchar  Ім’я користувача  
Surname  Varchar  Прізвище користувача  
Email  Varchar  Адреса електронної пошти  
Active  int  Статус користувача  
  
Таблиця «Роль користувача» використовується для створення зв’язку між 
користувачем та його ролями в системі.  
Таблиця 4.2 – Роль користувача (Role)  
Назва   Тип даних  Опис даних  
RoleId  int  Ідентифікатор ролі  
Name  Varchar  Назва ролі  
Active  int  Статус ролі  
Таблиця «Дозвіл» використовується для означення дозволів що існують в сисемі.  
Таблиця 4.3 – Дозвіл (Permission)  
Назва   Тип даних  Опис даних  
PermissionId  int  Ідентифікатор дозволу  
59 
Name  Varchar  Назва дозволу  
Таблиця «Дозвіл-Роль» визначає які дозволи доступні певним ролям 
користувачів системи.  
Таблиця 4.4 – Дозвіл-Роль (RolePermission)  
Назва   Тип даних  Опис даних  
PermissionId  int  Ідентифікатор дозволу  
RoleId  int  Ідентифікатор ролі  
  
Таблиця «Група» використовується для зберігання інформації про групи до 
яких належать користувачі.  
Таблиця 4.5 – Група (Group)  
Назва   Тип даних  Опис даних  
GroupId  int  Ідентифікатор групи  
Name  Varchar  Назва групи  
Description  Varchar  Опис групи  
DateCreated  DateTime  Дата створення  
 
Таблиця Користувач-Група використовується для створення зв’язку між 
користувачами та групами документів у системі.   
Таблиця 4.6 – Користувач-Група (UserGroup)  
Назва   Тип даних  Опис даних  
UserId  int  Ідентифікатор користувача  
GroupId  int  Ідентифікатор групи  
Таблиця «Документ» використовується для зберігання основної інформації 
про документи завантажені користувачем до системи: час створення, коментар, 
категорія, назва файлу та шлях до файлу на жорсткому диску.  
 
 
60 
Таблиця 4.7 – Документ (Document)  
Назва   Тип даних  Опис даних  
DocumentId  int  Ідентифікатор документа  
UserId  int  Ідентифікатор користувача власника 
документа  
Comment  Varchar  Коментар до документа  
DateCreated  DateTime  Дата створення  
CategoryId  int  Категорія документа  
FilePath  Varchar  Шлях до файлу документа у файловій системі  
FileNane  Varchar  Ім’я документа  
Locked  Bit  Статус документа  
Hash  Varchar  Хэш документа  
Таблиця «Завдання» призначена для зберігання даних про задачі, що 
призначаються користувачам системи. Кожне завдання має два обов’язкові 
зв’язки з таблицею «Користувач»: 
 виконавець — користувач, відповідальний за виконання завдання; 
 власник — користувач, який створив або призначив це завдання. 
Ці зв’язки реалізовані через відповідні зовнішні ключі до таблиці 
«Користувач», що забезпечує логічну цілісність і дозволяє відслідковувати як 
авторство, так і поточний стан виконання завдання в системі. 
Таблиця 4.8 – Завдання (Task)  
Назва   Тип даних  Опис даних  
TaskId  int  Ідентифікатор завдання  
Description  Varchar  Опис завдання  
AssignedUserId  int  Користувач відповідальний за виконання 
завдання  
CreatedByUserId  int  Користувач який створив завдання  
DateCompleted  Datetime  Дата завершення завдання  
DateCreated  Datetime  Дата створення завдання  
61 
Таблиця 4.9 – Документ-Завдання (DocumentTask)  
Назва   Тип даних  Опис даних  
DocumentId  int  Ідентифікатор документа  
Taskd  int  Ідентифікатор завдання  
Таблиця «Тег» використовується для визначення переліку маркерів, що 
можуть бути прикріплені до документа. Вони відображають належність 
документа до певного логічного типу.  
Таблиця 4.10 – Тег (Tag)  
Назва   Тип даних  Опис даних  
TagId  int  Ідентифікатор тегу  
Name  Varchar  Назва тегу  
Description  Varchar  Опис тегу  
Таблиця 4.11 – Документ-Тег (DocumentTag)  
Назва   Тип даних  Опис даних  
DocumentId  int  Ідентифікатор документа  
Tagd  int  Ідентифікатор тегу  
Таблиця «Категорія» використовується для визначення категорії для 
документів користувача. Кожен користувач може мати безліч категорій для 
своїх документів.   
Таблиця 4.12 – Категорія (Category)  
Назва   Тип даних  Опис даних  
Categoryd  int  Ідентифікатор категорії  
Description  Varchar  Опис категорії  
Name  Varchar  Назва категорії  
DateCreated  Datetime  Дата створення категорії  
Таблиця «Архів» створена для зберігання документів, що були призначені 
до переміщення в архів.  
 
 
62 
Таблиця 4.13 – Архів (DocumentArchive)  
Назва   Тип даних  Опис даних  
DocumentId  int  Ідентифікатор документа  
UserId  int  Ідентифікатор користувача власника 
документа  
Comment  Varchar  Коментар до документа  
DateCreated  DateTime  Дата створення  
CategoryId  int  Категорія документа  
FilePath  Varchar  Шлях до файлу документа у файловій 
системі  
FileName  Varchar  Ім’я документа  
Hash  Varchar  Хэш документа  
  
4.7 Програмні компоненти системи 
У системі були реалізовані такі основні компоненти: 
 AuthService — забезпечує функціональність аутентифікації користувачів 
при вході до системи. Сервіс є спільним для адміністраторів та звичайних 
користувачів. 
 Основний метод: 
 List<User> CheckCredential(UserLogin userLogin) 
 UserService — відповідає за операції, пов’язані з користувачами та їх 
групами (перегляд, створення, видалення тощо). 
 Основні методи: 
 List<User> GetAll(), bool Create(User user), bool Delete(int id) 
 CategoryService — реалізує логіку управління категоріями документів і 
файлів. 
 Основні методи: 
 List<Category> GetAll(string email), bool CreateCategory(Category cat, string 
email), bool DeleteCategory(int id) 
63 
 DocumentService — виконує обробку документів та завдань, пов’язаних з 
ними: завантаження, редагування, видалення. 
 Основні методи: 
 IQueryable<DocumentViewModel> GetDocuments(string email, string str), 
 bool DocumentUpload(IFormFile file, string path, Document document, string 
email) 
Контролери. Для забезпечення взаємодії між інтерфейсом користувача та 
логікою обробки даних були реалізовані такі контролери: 
 AuthController — обробляє запити сторінки авторизації. 
Методи: IActionResult Login(UserLogin userLogin), Task<IActionResult> Logout() 
 CategoryController — керує запитами, пов’язаними з категоріями 
(перегляд, створення, видалення). 
Методи: IActionResult Index(), IActionResult Create(Category cat), IActionResult 
Delete(int id) 
 DocumentController — обробляє перегляд та взаємодію з документами. 
Методи:  
 Task<IActionResult> Index(string str, int page), 
Task<IActionResult> Create(IFormFile file, Document document), 
Task<FileResult> Download(int id) 
 HomeController — відповідає за логіку головної сторінки. 
 UserController — забезпечує перегляд, створення і редагування 
користувачів.  
Методи:IActionResult Create(User user), IActionResult Delete(int id) 
Опис і реалізація цих компонентів наведені в додатках Е і Ж. 
Окремо був розроблений сервіс для взаємодії з блокчейн-мережею — 
Blockchain Document Storage Manager (див. додаток З). Він забезпечує обмін 
даними з Ethereum: створення блоків, читання даних, перевірку цифрових 
підписів і версій документів. 
64 
Також було реалізовано смарт-контракт на мові Solidity для роботи з 
блокчейном Ethereum. 
contract DocumentStorage {     struct Document {         bytes documentHash;         
int32 documentId;  
    }  
     mapping(int32 => Document) documents;     int32[] documentsById;  
     function set(Document memory document) public {         
if(documents[document.documentId].documentHash.length != 0){             return;  
        }         if(document.documentHash.length != 0){             
documentsById.push(document.documentId);  
        }         documents[document.documentId].documentId = 
document.documentId;         documents[document.documentId].documentHash = 
document.documentHash;     }   
    function get(int32 id) public view returns (Document memory 
SavedDocument) {         SavedDocument = documents[id];         return SavedDocument;  
    }      function getAllIds() public view returns (int32[] memory) {         return 
documentsById;  
  }}  
 4.8 Розгортання системи 
Важливою складовою життєвого циклу програмного забезпечення є процес 
планування та реалізації стратегії розгортання. У межах даної магістерської 
роботи була підготовлена детальна стратегія низькорівневого розгортання 
системи на локальному серверному середовищі. 
Першим кроком у цьому процесі є інсталяція служби IIS (Internet 
Information Services) на сервер. Для зручності та спрощення налаштування 
рекомендовано використовувати Web Platform Installer (WPI) — інструмент, 
який автоматично встановлює всі необхідні серверні компоненти, зокрема IIS та 
65 
Web Deploy. У разі, якщо певні компоненти вже наявні на сервері, WPI 
проаналізує поточну конфігурацію і встановить лише відсутні модулі. 
На рисунках 4.3 та 4.4 наведено перелік компонентів, які необхідно 
інсталювати для повноцінного функціонування системи. 
  
Рисунок 4.3 – Встановлення IIS  
Щоб обрати потрібні елементи для встановлення, слід скористатися 
рядком пошуку, ввівши назву відповідного компонента. Це дозволить швидко 
знайти і додати необхідні модулі для розгортання системи.  
  
Рисунок 4.4 – Встановлення Web Deploy  
На подальшому етапі налаштування системи необхідно активувати 
компоненти WWW Services та IIS Management Console через стандартний засіб 
керування – Windows Features (Компоненти Windows). Це забезпечить належну 
роботу веб-сервера IIS. На рисунку 4.5 представлено приклад правильного 
вибору параметрів у вікні налаштувань. 
 
66 
 
Рисунок 4.5 – Налаштування Windows Features 
На цьому етапі потрібно створити пул додатків за допомогою 
встановленого IIS Manager. Для цього: 
1. Відкрийте IIS Manager (Диспетчер служб IIS). 
2. У лівій панелі перейдіть до розділу Application Pools (Пули програм). 
3. У правій панелі оберіть опцію "Add Application Pool" (Створити новий 
пул додатків). 
4. У вікні, що з’явиться, задайте ім’я пулу та оберіть потрібну версію .NET 
CLR, яка відповідає вашому проєкту (наприклад, .NET CLR Version v4.0). 
5. Натисніть OK для підтвердження. 
За замовчуванням у списку вже буде кілька системних пулів, які можуть 
різнитися залежно від встановленої версії .NET Framework. Приклад 
налаштувань за замовчуванням наведено на рисунку 4.6. 
67 
 
Рисунок 4.6 – Приклад налаштувань IIS  
Стандартний пул додатків необхідно налаштувати таким чином, щоб він 
підтримував платформу .NET Core. Для цього: 
1. У списку пулів в IIS Manager знайдіть створений раніше пул додатків. 
2. Клацніть правою кнопкою миші та оберіть "Advanced Settings" (Розширені 
параметри). 
3. У полі ".NET CLR version" встановіть значення "No Managed Code", оскільки 
.NET Core не потребує CLR, на відміну від .NET Framework. 
4. У полі "Managed pipeline mode" залиште значення "Integrated". 
5. За потреби змініть ідентифікатор користувача, від імені якого працює пул 
(наприклад, на ApplicationPoolIdentity або спеціально створеного користувача 
з відповідними правами доступу). 
Вікно налаштувань наведено на рисунку 4.7.  
68 
  
Рисунок 4.7 – Приклад налаштувань пулу додатків  
Наступним важливим етапом є встановлення SQL Server 2019 та SQL 
Management Studio.  Для створення нової бази даних потрібно використовуючи 
SQL Management Studio застосувати команду Create new SQL database, приклад 
наведено на рисунку 4.8.   
  
Рисунок 4.8 – Приклад створення нової бази даних  
За замовчуванням стандартний пул додатків не має доступу до бази 
даних.  
Для надання прав потрібно виконати наступну команду в створеній базі:  
IF NOT EXISTS (SELECT name FROM sys.server_principals WHERE name = 'IIS  
APPPOOL\DefaultAppPool')  
BEGIN  
    CREATE LOGIN [IIS APPPOOL\DefaultAppPool]   
      FROM WINDOWS WITH DEFAULT_DATABASE=[master],   
      DEFAULT_LANGUAGE=[us_english]  
END  
GO  
CREATE USER [SystemUser]   
69 
  FOR LOGIN [IIS APPPOOL\DefaultAppPool]  
GO  
EXEC sp_addrolemember 'db_owner', 'SystemUser'  
GO  
Третім ключовим етапом впровадження системи є налаштування та запуск 
блокчейн-мережі. Для підвищення надійності та стійкості системи 
рекомендується розгорнути кілька вузлів мережі. Нижче розглядається приклад 
створення одного з таких вузлів. 
Основним інструментом для керування Ethereum-мережею є Geth — 
багатофункціональна утиліта командного рядка, що запускає повноцінний 
Ethereum-вузол. Geth реалізований мовою програмування Go і забезпечує доступ 
до трьох основних інтерфейсів: 
 підкоманд та CLI-параметрів, 
 JSON-RPC сервера, 
 інтерактивної консолі [13]. 
Після запуску Geth автоматично ініціює процес виявлення інших вузлів у 
peer-to-peer мережі, використовуючи протокол discovery. Завдяки цьому 
протоколу вузли обмінюються відомостями про інших учасників мережі, 
поступово формуючи повний список підключень. 
Для запуску Geth з початковим набором вузлів використовують параметр 
--bootnodes. Приклад команди: 
bash 
КопіюватиРедагувати 
geth --bootnodes "enode://pubkey1@ip1:port1 enode://pubkey2@ip2:port2 
enode://pubkey3@ip3:port3" 
Щоб отримати інформацію про стан підключень у мережі, можна 
скористатися модулем net в інтерактивній консолі Geth. Він містить корисні 
атрибути, що дозволяють дізнатись: 
 кількість активних з’єднань, 
 статус мережевого інтерфейсу, 
 деталі про підключених вузлів. 
> net.listening true  
70 
> net.peerCount 4  
Geth також надає можливість налаштування статичних вузлів, що особливо 
корисно у випадках, коли необхідно забезпечити постійне з'єднання з 
конкретними учасниками мережі. Це дозволяє уникнути повторного виявлення 
вузлів при кожному перезапуску та забезпечити стабільну топологію мережі. 
Такі вузли визначаються в спеціальному конфігураційному файлі static-
nodes.json, який має бути розміщений у відповідній директорії data-dir (каталозі 
з даними вузла). У цьому файлі перелічуються адреси вузлів у форматі enode. 
[  
"enode://f4642fa65af50cfdea8fa7414a5def7bb7991478b768e296f5e4a54e8b995de102e0ceae2e8
26f293c 
[email protected]:30303",  
  
"enode://pubkey@ip:port" 
]  
Для розгортання кількох вузлів Ethereum у локальному середовищі 
слід дотримуватись таких умов: 
1. Кожному вузлу слід призначити окрему директорію зберігання даних — 
параметр --datadir, щоб уникнути конфліктів між екземплярами. 
2. Кожен вузол повинен мати унікальні порти для: 
 Ethereum P2P-з’єднання (--port) 
 доступу до JSON-RPC інтерфейсу (--http.port або --rpcport у 
старіших версіях). 
3. Вузли мають бути поінформовані один про одного, тобто містити 
відповідні bootnodes або бути визначеними у static-nodes.json, щоб 
утворити кластерну мережу. 
Приклад команди запуску першого вузла: 
bash 
КопіюватиРедагувати 
71 
geth --datadir node1 --networkid 12345 --port 30301 --http --http.port 
8545 --nodiscover --allow-insecure-unlock --http.api 
personal,eth,net,web3,miner,admin,txpool,debug console 
Пояснення параметрів: 
 --datadir node1 — директорія для зберігання даних вузла. 
 --networkid 12345 — унікальний ID приватної мережі. 
 --port 30301 — порт для P2P-з’єднань. 
 --http --http.port 8545 — увімкнення RPC API на вказаному порту. 
 --nodiscover — вимкнення автоматичного пошуку інших вузлів 
(опціонально). 
 --allow-insecure-unlock — дозволяє розблоковувати акаунти (для 
локального використання). 
 --http.api ... — список дозволених API. 
Для запуску наступного вузла слід змінити значення --datadir, --port, 
--http.port та вказати bootnodes, щоб з’єднатись з першим. 
geth --datadir="/tmp/eth/" -verbosity 6 --ipcdisable --port 30301 --rpcport 8101 
console 2>> /tmp/eth.log.txt  
Схожі команди можна застосовувати й для запуску інших вузлів, 
змінюючи лише унікальні параметри, такі як директорія даних та номери портів. 
Розгорнута Ethereum-мережа функціонує як приватна блокчейн-мережа, 
що означає — її вузли не мають з’єднання з глобальною мережею Ethereum. Така 
конфігурація створює ізольоване середовище, у якому обмін даними та взаємодія 
відбуваються лише між вузлами локальної мережі. 
У випадку дотримання всіх належних заходів безпеки при налаштуванні 
серверів, така мережа вважається захищеною від зовнішніх підключень. 
Архітектуру розгортання системи наведено у додатку Г.4.9 Тестування системи.  
Локальне тестування та інструкція користувача. 
72 
Система була протестована в локальному середовищі. Основна увага під час 
тестування була зосереджена на покритті ключових компонентів: клієнтського 
інтерфейсу, серверної логіки, а також взаємодії з блокчейн-мережею. 
Інтеграційні тести дозволили перевірити: 
 правильність реалізації контролерів; 
 коректність даних, що повертаються користувачу через шар доступу до 
БД; 
 відповідність функціонування сервісів заданій бізнес-логіці. 
Проведення тестування в локальному середовищі дозволило уникнути затримок 
мережі та значно скоротити час виконання тестів перед розгортанням у 
продуктивному середовищі. 
Проведено ручне тестування з використанням наступних тест-кейсів: 
Тест кейс 1 – Авторизація користувача 
Опис: Користувач вводить логін і пароль у форму авторизації. 
Вхідні дані: Email, пароль. 
Очікуваний результат: Перенаправлення користувача до особистого кабінету. 
Кроки: 
 Перейти на сторінку входу. 
 Ввести дані. 
 Натиснути кнопку входу. 
Тест кейс 2 – Створення користувача адміністратором 
Опис: Адміністратор створює обліковий запис користувача. 
Вхідні дані: Email, логін, пароль, ім’я, прізвище. 
Очікуваний результат: Користувача створено. 
Кроки: 
 Відкрити сторінку створення користувача. 
 Натиснути кнопку "Створити нового". 
 Заповнити форму. 
 Підтвердити створення. 
Тест кейс 3 – Завантаження документа 
73 
 Опис: Користувач завантажує файл до системи. 
 Вхідні дані: Документ, категорія. 
 Очікуваний результат: Документ доступний у списку. 
Кроки: 
 Перейти на сторінку завантаження. 
 Обрати файл. 
 Підтвердити завантаження. 
 Перевірити наявність у списку. 
Тест кейс 4 – Підписання документа через блокчейн 
Опис: Користувач створює блокчейн-підпис документа. 
Вхідні дані: Документ, користувач. 
Очікуваний результат: Підпис збережено у блокчейні. 
Кроки: 
 Відкрити сторінку підпису. 
 Обрати документ. 
 Натиснути «Підписати». 
 Перевірити наявність підпису в мережі. 
Висновки до розділу 4 
       У розділі описано реалізацію ключових сутностей, які побудовані на основі 
доменної моделі. У додатку Д представлено ER-діаграму системи. Розробка 
була виконана з дотриманням принципів Domain-Driven Design (DDD), що 
дозволило створити стійку архітектуру з чіткою логічною структурою. 
  
74 
ВИСНОВКИ  
У кваліфікаційній роботі було всебічно досліджено процеси аналізу, 
розробки та впровадження системи електронного документообігу з 
використанням технології блокчейн. 
Блокчейн виступає ефективною інфраструктурою для захисту, обміну та 
перевірки електронних документів. У контексті перевірки підпису документів ця 
технологія дозволяє зберігати інформацію про емітента, одержувача та 
цифровий підпис в розподіленій базі даних, копії якої синхронно підтримуються 
всіма учасниками приватної мережі. Це забезпечує незмінність збережених 
даних, що виключає можливість підробки як самого документа, так і його 
підпису. Перевірка справжності підпису можлива в будь-який час при наявності 
доступу до мережі. Також блокчейн дозволяє уникнути залучення посередників, 
підвищуючи рівень конфіденційності документообігу. 
У роботі проаналізовано сучасні рішення систем електронного 
документообігу, виявлено їхні основні недоліки та вимоги. Описано ключові 
принципи функціонування блокчейну та переваги його застосування у цьому 
контексті. Було сформульовано обґрунтування доцільності впровадження цієї 
технології в подібних системах. 
Окремий розділ присвячено бізнес-стратегії виходу розробленого рішення 
на ринок, створенню бізнес-плану та аналізу конкурентного середовища. 
Показано потенціал впровадження системи в умовах сучасного цифрового 
простору. 
Технологія блокчейн забезпечує високий рівень безпеки, надійності та 
незмінності даних, що є ключовими аспектами для систем електронного 
документообігу. Вона дозволяє зменшити часові та фінансові витрати на обробку 
документів, виконання завдань та архівацію, а також усунути загрозу 
фальсифікації інформації. 
Таким чином, у роботі доведено актуальність і перспективність 
впровадження блокчейн-орієнтованих рішень у сферу корпоративного 
75 
документообігу, зважаючи на стрімке зростання попиту на подібні системи в 
умовах цифрової трансформації бізнесу. 
  
76 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ  
1. Arvind Narayanan, Joseph Bonneau, Edward Felten, Andrew Miller, Steven 
Goldfeder. Bitcoin and Cryptocurrency Technologies: A Comprehensive 
Introduction. – Princeton University Press, 2016. 
2. Chris Dannen. Introducing Ethereum and Solidity: Foundations of Cryptocurrency 
and Blockchain Programming for Beginners. – APRESS: New York, USA, 2017. – 
DOI: 10.1007/978-1-4842-2535-6. 
3. Ølnes, S., Ubacht, J., & Janssen, M. Blockchain in government: Benefits and 
implications of distributed ledger technology for information sharing // Government 
Information Quarterly, 34(3), 2017. – p. 355–364. 
4. Xiuping Lin. Semi-centralized Blockchain Smart Contracts: Centralized 
Verification and Smart Computing under Chains in the Ethereum Blockchain // 
Department of Information Engineering, National Taiwan University, 2017. 
5. Steve Smith. Architecting Modern Web Applications with ASP.NET Core and 
Microsoft Azure. – 2018. 
6. Kendall K.E., Kendall J.E. Systems Analysis and Design. – 5th Edition. New Jersey: 
Prentice Hall, 2002. 
7. Леонов І.В. Введення в методологію розробки програмного забезпечення. – 
Ескейп, 2004. – 301 с. 
8. Матвієнко О.В., Цивін М.Н. Основи організації електронного документообігу. 
– 2008. – 112 с. 
9. Алексєєва Т., Потапенко М. Системи електронного документообігу: від 
усвідомлення потреби до оцінки та імплементації // ITСпец, 2008. № 12. – С. 
40–44. 
10. Брускіна Т., Дроздов Д. Спецобзор: програмні рішення в сфері електронного 
документообігу // ITСпец, 2008. № 12. – С. 28–35. 
11. Барановський В.П. Документаційне забезпечення діяльності організації. – 
Навчальний посібник. – М.: Асоціація авторів і видавців «Тандем», Вид-во 
ЕКМОС, 1999. 
77 
12. Печнікова Т.В. Практика роботи з документами в організації. – М.: «Тандем», 
ЕМОС, 1999. – 208 с. 
13. Система електронного документообігу FossDoc [Електронний ресурс]. – 
Режим доступу: https://fossdoc.com 
14. Система електронного документообігу ДокПроф [Електронний ресурс]. – 
Режим доступу: http://docprof.com.ua 
   
78 
ДОДАТОК А 
 
 
 
        Затверджую               
Зав. кафедри КНСА, 
______________ Юрій  ТРИУС     
«____»____________2025 р.                                                                                                                                                                              
 
 
 
 
 
 
 
СИСТЕМА УПРАВЛІННЯ ЛОГІСТИЧНИМ  ДОКУМЕНТООБІГОМ ЗА 
ТЕХНОЛОГІЄЮ БЛОКЧЕЙН 
 
Специфікація  
482.ЧДТУ. 52314-01 12 01 
Листів 2 
 
 
 
 
 
 
 
 
Розробник                          ____________________                Олексій ШЕВЧЕНКО 
 
Керівник                             ____________________                Микола ПІДГОРНИЙ 
 
 
 
 
 
 
 
 
Черкаси – 2025  
79 
482.ЧДТУ. 52314-01 
Позначення Найменування Примітка 
   
   
 Документація  
   
   
482.ЧДТУ. 52314-01    12 01 Текст програми  
482.ЧДТУ. 52314-01    34 01 Інструкція користувача  
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
80 
ДОДАТОК Б 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
СИСТЕМА УПРАВЛІННЯ ЛОГІСТИЧНИМ ДОКУМЕНТООБІГОМ ЗА 
ТЕХНОЛОГІЄЮ БЛОКЧЕЙН 
 
 
 
 
Текст програми 
482.ЧДТУ. 52314-01 12 01 
 
Листів 14 
 
 
 
 
 
 
 
 
Розробник                                                _____________             Олексій ШЕВЧЕНКО  
 
 
 
 
 
 
 
Черкаси – 2025  
81 
Код смарт-контракту для роботи з Ethereum блокчейном:  
contract 
DocumentStorage {     
struct Document {         
bytes documentHash;         
int32 documentId;  
    }  
  
     mapping(int32 => Document) 
documents;     int32[] documentsById;  
     function set(Document memory document) public {         
if(documents[document.documentId].documentHash.length != 0){             
return;  
        }         
if(document.documentHash.length != 0){             
documentsById.push(document.documentId);  
        }         documents[document.documentId].documentId = 
document.documentId;         documents[document.documentId].documentHash 
= document.documentHash;     }   
    function get(int32 id) public view returns (Document memory 
SavedDocument) {         SavedDocument = documents[id];         return 
SavedDocument;  
    }      function getAllIds() public view returns 
(int32[] memory) {         return documentsById;  
  }}  
  
 
 
  
82 
ДОДАТОК В 
 
 
 
 
 
 
 
 
 
 
 
 
СИСТЕМА УПРАВЛІННЯ ЛОГІСТИЧНИМ  ДОКУМЕНТООБІГОМ ЗА 
ТЕХНОЛОГІЄЮ БЛОКЧЕЙН 
 
 
 
ІНСТРУКЦІЯ КОРИСТУВАЧА 
482. ЧДТУ. 52314-01 34 01 
 
Листів 13 
 
 
 
 
 
 
 
 
 
Розробник                                         _____________                 Олексій ШЕВЧЕНКО 
 
 
 
 
 
 
 
 
 
Черкаси – 2025  
83 
В.1 Розгортання системи 
Важливим елементом життєвого циклу є планування та розробка стратегії 
розгортання системи. В рамках магістерської дисертації було розроблено 
низькорівневу стратегію розгортання системи на локальному сервері. 
Початковим этапом розгортання системи є встановлення IIS на сервері. 
Для встановлення IIS та Web Deploy рекомендується використовувати 
інсталятор веб-платформи (WPI). WPI встановлює рекомендовану конфігурацію 
серверного ПО, яке включає всі необхідні компоненти для IIS та Web Deploy. 
Якщо IIS, Web Deploy або будь-який з необхідних їх компонентів вже 
встановлено, WPI встановлює лише те, чого не вистачає. На рисунках В.3 та В.4 
зображено компоненти, що слід встановити.  
  
Рисунок В.1 – Встановлення IIS  
Для вибору відповідних елементів потрібно скористатися строкою 
пошуку та вести ім’я компонента.  
  
Рисунок В.2 – Встановлення Web Deploy  
84 
На наступному етапі потрібно увімкнути WWW Services та IIS 
Management Console використовуючи інструмент панелі управління – Windows 
Features.  
Приклад налаштувань наведено на рисунку В.5.  
 
Рисунок В.3 – Налаштування Windows Features 
На наступному кроці потрібно створити пул додатків використовуючи 
встановлений IIS Manager. Для цього потрібно відкрити менеджер веб серверу та 
перейти до меню Aplication Pools. Наступним кроком потрібно вибрати дію 
«Створити новий пул додатків». За замовчуванням в списку пулів вже буде 
додано 3 нових пули, що належать до системних та можуть відрізнятися в 
залежності від версії .Net framework встановленої на сервері. Приклад 
налаштувань за замовчуванням наведено на рисунку 4.6.  
85 
 
Рисунок В.6 – Приклад налаштувань IIS  
Стандартний пул додатків повинен бути налаштований для використання 
платформи .NET Core. Вікно налаштувань наведено на рисунку 4.7.  
  
Рисунок В.7 – Приклад налаштувань пулу додатків  
Наступним важливим етапом є встановлення SQL Server 2019 та SQL 
Management Studio.  Для створення нової бази даних потрібно використовуючи 
SQL Management Studio застосувати команду Create new SQL database, приклад 
наведено на рисунку 4.8.   
86 
  
Рисунок В.8 – Приклад створення нової бази даних  
За замовчуванням стандартний пул додатків не має доступу до бази 
даних.  
Для надання прав потрібно виконати наступну команду в створеній базі:  
IF NOT EXISTS (SELECT name FROM sys.server_principals WHERE name = 'IIS  
APPPOOL\DefaultAppPool')  
BEGIN  
    CREATE LOGIN [IIS APPPOOL\DefaultAppPool]   
      FROM WINDOWS WITH DEFAULT_DATABASE=[master],   
      DEFAULT_LANGUAGE=[us_english]  
END  
GO  
CREATE USER [SystemUser]   
  FOR LOGIN [IIS APPPOOL\DefaultAppPool]  
GO  
EXEC sp_addrolemember 'db_owner', 'SystemUser'  
GO  
Третім важливим етапом є розгортання мережі блокчейн. Для збільшення 
надійності системи необхідно розгорнути декілька вузлів мережі. Розглянемо 
приклад створення одного із вузлів. Основним інструментом керування мережею 
блокчейн Ethereum є Geth – це багатоцільовий інструмент командного рядка, 
який запускає повний вузол Ethereum, реалізований мовою Go. Він пропонує три 
інтерфейси: підкоманди та параметри командного рядка, сервер Json-rpc та 
інтерактивну консоль [13].  
Після запуску Geth в автоматичному режимі шукає інші вузли 
однорангової блокчейн мережі використовуючи прокотол виявлення. За цим 
протоколом вузли передають інформацію про учасників мережі один одному.  
 
87 
Для початку роботи з системою користувач має пройти процедуру 
авторизації. Необхідно заповнити логін та пароль у відповідну форму й 
натиснути кнопку входу. Зразок форми авторизації зображено на рисунку В.1.1. 
 
Рисунок В.1.1 – Форма авторизації в системі. 
Якщо на сторінці авторизації було введено невірні дані користувача буде 
сповіщено спеціальним повідомленням, приклад на рисунку В. 1.2. 
 
Рисунок В.2 – Повідомлення про неправильно введені дані 
У разі помилкової авторизації користувач отримує відповідне 
повідомлення про невірні облікові дані з можливістю повторити спробу входу. 
Система передбачає розмежування доступу відповідно до двох ролей: 
звичайний користувач та адміністратор. Після успішної автентифікації 
88 
користувач перенаправляється на головну сторінку (дашборд), де 
відображається зведена інформація про стан системи: кількість зареєстрованих 
користувачів, наявних документів та створених категорій. Приклад інтерфейсу 
наведено на рисунку В.3. 
   
Рисунок В.3 – Головна сторінка системи  
Для користувача передбачено два ключові функціональні блоки: модуль 
конфігурації та модуль керування документами. 
Модуль конфігурації, доступний лише для користувачів із роллю 
адміністратора, включає інструменти керування системними параметрами та 
доступом. Функціональні можливості цього модуля проілюстровано на рисунку 
В.4. 
  
Рисунок В.4 – Функції модуля конфігурації  
Функціональність створення нового користувача доступна виключно для 
адміністраторів системи. Для додавання користувача необхідно заповнити всі 
89 
обов’язкові поля форми (рис. В.5), включаючи: ім’я, електронну пошту, пароль, 
а також вказати роль користувача (адміністратор або звичайний користувач).
   
Рисунок В.5 – Форма створення нового користувача 
У разі успішної реєстрації нового користувача, у верхній частині сторінки 
з’являється відповідне повідомлення з підтвердженням, як показано на рисунку 
В.6. 
   
Рисунок В.6 – Форма створення користувача після успішної реєстрації  
Однією з ключових функцій модуля є управління користувачами. 
Відповідна сторінка інтерфейсу, що дозволяє переглядати, редагувати та 
90 
видаляти користувачів системи, представлена на рисунку В.7.
   
Рисунок В.7 – Сторінка управління користувачами  
Адміністратор має доступ до функцій перегляду, видалення та відновлення 
користувачів у системі. 
Окрім того, як адміністратори, так і звичайні користувачі мають 
можливість створювати категорії для документів за допомогою функції 
«Створити категорію». Інтерфейс цієї функції представлено на рисунку В.8.
   
Рисунок В.8 – Сторінка створення категорії  
Щоб створити нову категорію, необхідно ввести її назву у відповідне поле 
та натиснути кнопку «Створити». Після успішного створення категорії 
з’являється підтверджувальне повідомлення, приклад якого наведено на рис. В.9.  
91 
   
Рисунок В.9 – Приклад успішного створення категорії  
Користувач має можливість переглядати список наявних категорій 
документів, а також видаляти непотрібні за допомогою меню «Manage 
Categories». Інтерфейс цієї сторінки наведено на рисунку В.10.
   
Рисунок В.10 – Сторінка перегляду та управління категоріями  
  
Кожен користувач системи має доступ до модуля керування документами 
— «Document Module». Щоб додати новий документ, потрібно перейти до 
розділу «Upload Document», обрати файл зі свого пристрою та призначити його 
до однієї з існуючих категорій (яка має бути створена заздалегідь). Інтерфейс 
92 
сторінки завантаження документа показано на рисунку В.11.
   
Рисунок В.11 – Сторінка завантаження документа в системі  
  
Щоб переглянути наявні документи, користувач може скористатися 
розділом «Manage Documents» у модулі керування документами. У цьому розділі 
доступні такі функції, як завантаження документа з системи, підписування 
документа, а також перевірка його поточного статусу. Приклад інтерфейсу цієї 
сторінки наведено на рисунку В.12. 
   
Рисунок В.12 – Сторінка управління документами  
Користувач має можливість створювати завдання для інших користувачів, 
обираючи один із наявних документів як основу. Для цього необхідно перейти 
до відповідного розділу, заповнити форму із зазначенням виконавця, опису 
93 
завдання та пов’язаного документа. Приклад інтерфейсу створення нового 
завдання подано на рисунках В.13 та В.14. 
   
Рисунок В.13 – Сторінка створення нового завдання  
Після успішного створення завдання система автоматично відображає 
повідомлення, яке підтверджує, що завдання було збережено та призначено 
обраному користувачу. 
  
Рисунок В.14 – Сповіщення після створення завдання  
94 
Для перегляду завдань створених саме користувачем чи призначених йому 
існує сторінка списку завдань. Приклад на рисунку В.15.   
  
 
Рисунок В.15 – Сторінка списку завдань 
На сторінці кожного завдання відображаються такі дані, як унікальний 
ідентифікатор, опис завдання та статус його виконання. Для керування 
завданнями передбачені функції «Delete» (видалення) та «Complete» (позначення 
як виконане). Після виконання цих дій система повідомляє користувача про 
успішне завершення операції. 
Для зручної навігації в інтерфейсі доступні кнопки «DMS» та «Home», а 
для виходу з системи використовується іконка вимкнення у правому верхньому 
куті екрана (приклад показано на рисунку В.16). 
 
Рисунок В.15 – Приклад меню з кнопками навігації