ERP на власному сервері: відмінності між версіями

Поточна версія на 18:42, 15 травня 2026

Він здатна забезпечувати:

Для ERP критично визначити два показники.== SLA ==

Web-сервер

VPN

Під час переходу з BAS або 1С на K2 ERP на власному сервері потрібно не тільки перенести довідники, документи й залишки, а й переосмислити всю інфраструктуру: користувачів, ролі, API, BI, резервні копії, web-доступ, інтеграції, архіви, моніторинг і безпеку. # Налаштувати резервні копії. * більше оперативної пам’яті;

швидші диски;
окремий сервер СУБД;
окремий сервер BI;
окремий API-сервер;
балансування навантаження;
архівування старих даних;
оптимізація запитів;
збільшення мережевої пропускної здатності;
резервний сервер. Потрібно продумати:

|- | Фізичний сервер | Контроль ресурсів, висока продуктивність | Складніше масштабування і відновлення |- | Віртуальна машина | Гнучкість, знімки, простіше перенесення | Потрібна якісна віртуалізація |}

Приклади:

Безпека ERP на власному сервері

електроживлення;
резервне живлення;
інтернет-канали;
фізичну безпеку;
доступ до серверів;
резервне копіювання;
пожежну безпеку;
SLA датацентру;
мережеву ізоляцію;
відповідальність сторін.== Помилка: відкрити ERP напряму в інтернет ==

RPO і RTO

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

| Що критично при міграції з BAS/1С?

відключення електроенергії;
слабке охолодження;
крадіжка або фізичне пошкодження;
слабкий інтернет;
відсутність резервного каналу;
відсутність цілодобового моніторингу;
слабка фізична безпека;
недостатнє резервне копіювання. Резервні копії — одна з найважливіших частин on-premise ERP.

Адміністратори

версію K2 ERP;
версію модулів;
версію API;
версію BI;
версію СУБД;
версію міграційних пакетів;
дату оновлення версій;
список змін;
відповідального за оновлення версій. Але VPN не замінює ролі, паролі, журналювання і контроль доступів. # Зафіксувати версію.

Потрібно контролювати: ERP на власному сервері потрібно масштабувати. Доступ оновлення версій потрібно виконувати контрольовано. Призначення ↓

джерела даних;
частоту оновлення версій;
права доступу;
ролі BI-користувачів;
чи виступає як окрема аналітична база;
чи можна експортувати інформаційні дані;
хто бачить фінансові показники;
хто бачить собівартість;
хто бачить зарплату;
хто адмініструє BI. Погані підходи:

Помилка: сервер без резервного копіювання

Архівування

Вони можуть керувати:

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

Як не треба робити

технічна підтримка ERP на власному сервері здатна включати:

Правильний підхід. ERP на власному сервері потрібно впроваджувати як інфраструктурний проєкт: із серверною архітектурою, СУБД, резервними копіями, тестовою базою, HTTPS, VPN, ролями, API, BI, моніторингом, журналюванням і планом аварійного відновлення.== Доступ користувачів == Приклад:

Як правильно впроваджувати ERP на власному сервері

Резервне копіювання + BI + Архів Під час переходу з BAS або 1С на K2 ERP на власному сервері потрібно врахувати не тільки інформаційні дані, а й інфраструктуру. Для ERP СУБД виступає як критично важливою частиною інфраструктури. це модель розміщення ERP-системи.== Тестове середовище ==

Сервер бази даних

# Налаштувати HTTPS. # Налаштувати журналювання. # Виконати контрольні звірки. Де функціонує ERP BI здатна бути розміщений: оновлення версій ERP на власному сервері HTTPS захищає передачу:	HTTPS; VPN або обмеження IP; сильні паролі; журналювання; обмеження ролей; захист API; моніторинг; регулярні оновлення версій.== Датацентр == Якщо ERP розміщується не в офісі, а в датацентрі, потрібно перевірити: компаній забезпечується через У випадку K2 ERP розміщення на власному сервері здатна бути доречним; так само реалізовано які мають підвищені вимоги до контролю даних, внутрішньої безпеки, інтеграцій з локальними системами, регуляторних обмежень, роботи у власному датацентрі, корпоративних політик ІТ або бажають на 100% контролювати серверну інфраструктуру. # Запланувати вікно оновлення версій. ! # Визначити API та BI. {\| class="wikitable" style="width:100%;"
Сервери	компанія-користувач або ІТ-підрядник
СУБД	DBA або адміністратор
Резервні копії	ІТ-служба / підрядник
оновлення версій K2 ERP	Постачальник / впроваджувач / адміністратор
Користувачі й ролі	Адміністратор ERP
API	Інтегратор / адміністратор
BI	Аналітик / адміністратор BI
Безпека	ІТ-служба / служба безпеки

Безпека має включати:

консультації;
оновлення версій;
виправлення помилок;
аналіз журналів;
перевірку продуктивності;
підтримку інтеграцій;
підтримку API;
підтримку BI;
допомогу з резервними копіями;
консультації з СУБД;
допомогу при аваріях;
супровід міграції;
навчання адміністраторів. Найчастіші помилки:

токенами;
HTTPS;
обмеженням IP;
ролями;
журналюванням;
лімітами;
окремими сервісними користувачами. СУБД — це платформа керування базами даних. |-

Чи виступає як санкційні ризики у BAS і 1С? |} Перенести інформаційні дані й процеси, але не залишити стару BAS/1С активним джерелом обліку або інтеграцій. # Налаштувати інтеграції. Спрощена схема:

Якщо ERP доступна через web, потрібно використовувати HTTPS.

продажі та реалізація;
залишки;
прибуток;
маржу;
собівартість;
дебіторську заборгованість;
кредиторську заборгованість;
складські KPI;
виробничі KPI;
фінансові показники;
керівницькі дашборди. VPN оптимізує не відкривати ERP напряму в інтернет. * K2
K2 ERP
ERP
Ліцензування K2 ERP
Версія K2 ERP
Оновлення K2 ERP
Користувач K2 ERP
Ролі K2 ERP
Права доступу
API
BI
Журналювання
Резервна копія
SaaS
On-premise
Хмарна ERP
Міграція з BAS
Міграція з 1С
Заміна BAS
Заміна 1С
BAS
1С
Оновлення BAS
Конфігурація BAS
Користувач BAS
Роль BAS
Веб-клієнт BAS
Клієнт-серверний режим BAS
Файловий режим BAS
Web-сервіси 1С
JSON 1С
Інтеграція з BAS
Інтеграція з 1С
Інтеграція через файли
Інтеграція через XML
SQL
JSON
XML
CSV
Українське програмне забезпечення
Автоматизація бізнесу
Цифрова незалежність
Деколонізація обліку

Фізичний сервер чи віртуальна машина

ERP здатна працювати на фізичному сервері або віртуальній машині. Такий підхід часто називають on-premise ERP, локальна ERP, ERP на сервері компанії або ERP у власній інфраструктурі. # Оновити тестове середовище.== Файлове сховище ==

Наслідки: Воно потрібне для:

У on-premise моделі відповідальність потрібно чітко розділити. Тому перехід на K2 ERP на власному сервері здатна бути частиною стратегії цифрової незалежності, контролю даних і відмови від старої ризикової екосистеми. # Підготувати СУБД. Для чого

Що переносити з BAS/1С

BI здатна показувати:

! Сервісні користувачі потрібні для інтеграцій. Призначення

== Версійність ==

* зберігання даних;
* запити;
* транзакції;
* індекси;
* резервне копіювання;
* відновлення;
* продуктивність;
* права доступу;
* цілісність даних. {| class="wikitable" style="width:100%;"

'''Головне.''' ERP на власному сервері дає компанії більше контролю над даними, інфраструктурою, доступами, інтеграціями та безпекою, але вимагає відповідальності за сервери, резервні копії, оновлення версій, моніторинг, кібербезпеку і технічну підтримку. | Це модель, коли ERP функціонує на серверах компанії або в інфраструктурі, яку компанія-користувач контролює. Порядок:

{| class="wikitable" style="width:100%;"

Журналювання потрібне для:

* контроль над даними;
* контроль над серверами;
* контроль над резервними копіями;
* контроль над API;
* контроль над BI;
* контроль над користувачами;
* контроль над ролями;
* контроль над інтеграціями;
* контроль над оновленнями;
* незалежність від старої BAS/1С-інфраструктури;
* можливість будувати українську ERP-архітектуру. * на тому самому сервері;
* на окремому сервері;
* у хмарі;
* у гібридній моделі;
* як окрема аналітична база;
* як вітрина даних. Хмарна ERP

[[Категорія:JSON 1С]]

[[Категорія:BAS]]

* які інформаційні дані залишати в робочій базі;
* які переносити в архів;
* як відкривати архів;
* хто має доступ;
* чи потрібен пошук;
* чи потрібні звіти по архіву;
* як зберігати документи;
* як резервувати архів. ERP на власному сервері має мати план аварійного відновлення. ERP на власному сервері

== Власний датацентр ==

[[Категорія:1С]]

* виділену інфраструктуру;
* контроль доступів;
* гнучке масштабування;
* віртуальні машини;
* резервування;
* ізоляцію;
* інтеграції;
* можливість розміщення в потрібному датацентрі.== Продуктивність ==

== Висновок ==

! здатна знадобитися:

[[Категорія:K2]]

* аудиту;
* безпеки;
* розслідування помилок;
* контролю користувачів;
* контролю API;
* контролю адміністраторів;
* контролю інтеграцій;
* аналізу продуктивності;
* виявлення підозрілих дій. | Так.== Порівняння власного сервера і хмари ==

З урахуванням санкційних, юридичних і кібербезпекових ризиків [[BAS]] та [[1С]], перехід на [[K2 ERP]] на власному сервері здатна стати частиною ширшої стратегії цифрової незалежності, контролю даних, українського програмного забезпечення і сучасної ERP-архітектури. Старі інформаційні дані можуть впливати на продуктивність. ! {| class="wikitable" style="width:100%;"

[[Категорія:СУБД]]

У базі можуть бути:

# Прочитати release notes. Сервер K2 ERP

<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">

* 3 копії даних;
* 2 різні носії або сховища;
* 1 копія поза основним майданчиком. # Оновити production. # Провести навчання користувачів. Це здатна бути:

<syntaxhighlight lang="text">

[[Категорія:Моніторинг]]
 ↓
'''Підхід K2 ERP.''' [[K2 ERP]] здатна розгортатися у власній інфраструктурі компанії, якщо бізнесу потрібен контроль серверів, СУБД, резервних копій, API, BI, інтеграцій, доступів, журналювання, оновлень і політик безпеки.== Сервер застосунків ==

* договори;
* скани документів;
* рахунки;
* акти;
* накладні;
* сертифікати;
* зображення товарів;
* імпортні файли;
* експортні файли;
* вкладення;
* архіви;
* резервні копії;
* логи.== Інтеграції ==

Він має описувати:

Файлове сховище потрібно резервувати і захищати так само уважно, як базу даних.== Що не переносити ==

! Вона відповідає за:

</div>

ERP на власному сервері має підтримувати чітку модель користувачів.== Принцип мінімального доступу ==

* входи;
* помилки входу;
* зміну документів;
* зміну довідників;
* експорт;
* API-запити;
* зміну ролей;
* адміністративні дії;
* помилки системи;
* помилки інтеграцій. # Налаштувати моніторинг. Користувачі → Корпоративна мережа / VPN / Web → Сервер ERP → СУБД → інформаційні дані компанії

! BI здатна працювати на окремому сервері або разом із ERP. Варіант

* контроль інфраструктури;
* резервування;
* краща фізична безпека;
* кращий моніторинг;
* професійне адміністрування;
* масштабування;
* контроль мережі;
* технічна підтримка корпоративних стандартів.== Помилка: залишити BAS/1С активною після переходу ==

! Web / VPN / Локальна мережа

як приклад:

* контроль доступів;
* складні паролі;
* двофакторну автентифікацію для критичних ролей;
* обмеження адміністраторів;
* HTTPS;
* VPN;
* міжмережевий екран;
* обмеження доступу до СУБД;
* захист резервних копій;
* журналювання;
* моніторинг;
* регулярні оновлення версій;
* антивірусний контроль;
* аудит сервісних акаунтів;
* контроль API;
* контроль експорту даних. * локальну мережу;
* VPN;
* доступ філій;
* доступ віддалених користувачів;
* пропускну здатність;
* затримки;
* резервний інтернет;
* міжмережеві екрани;
* сегментацію мережі;
* доступ до СУБД;
* доступ до API;
* доступ до резервних копій. Перевірка

! * ставити ERP на випадковий офісний комп’ютер;
* не мати резервних копій;
* не мати тестової бази;
* не мати плану відновлення;
* не контролювати доступи;
* не налаштувати HTTPS;
* не обмежити API;
* не розділити ролі;
* не моніторити сервер;
* не документувати інфраструктуру;
* не перевіряти BI-навантаження;
* не вимкнути старі BAS/1С-інтеграції;
* ігнорувати санкційні й кібербезпекові ризики. {| class="wikitable" style="width:100%;"
! Такі каталоги потрібно захищати, резервувати і журналювати. ! # Перевірити інтеграції. Потрібно визначити:

!

Користувачі і ролі

На продуктивність ERP на власному сервері впливають:

Менеджер Клієнти, замовлення, рахунки Немає доступу до зарплати й адміністрування Комірник Складські документи, інвентаризація Немає доступу до банку й собівартості Бухгалтер Каса, банк, проводки, формування звітів Без технічного адміністрування Керівник Звіти, BI, KPI Без зміни первинних документів API-користувач Конкретні API-методи Без доступу до зайвих модулів

СУБД

Коли ERP на власному сервері доречна

Не потрібно переносити:

серверами;
СУБД;
користувачами;
ролями;
резервними копіями;
оновленнями;
журналами;
інтеграціями;
API;
BI;
web-сервером;
безпекою. ! Сервер

Після переходу стара BAS/1С здатна залишитися як архів. # Перевірити BI. Окремі продукти 1С і BAS внесені до відкритих переліків програмного забезпечення, забороненого до використання для окремих категорій організацій.

SEO title: ERP на власному сервері — on-premise ERP, K2 ERP, безпека, СУБД, резервні копії, API, BI і міграція з BAS

SEO keywords: ERP на власному сервері, on-premise ERP, локальна ERP, ERP на сервері компанії, K2 ERP on-premise, власний сервер ERP, українська ERP, сервер ERP, СУБД ERP, резервна копія ERP, безпека ERP, API ERP, BI ERP, міграція з BAS, міграція з 1С, заміна BAS, заміна 1С, санкції BAS, санкції 1С, цифрова незалежність

</noinclude>
 {{SEO
Шаблон для службового SEO-опису сторінки.

}}

базу даних;
файлове сховище;
конфігурацію;
конфігурація;
сертифікати;
API-ключі;
BI-вітрини;
web-сервер;
скрипти;
документацію;
журнали;
інтеграційні файли.

HTTPS

ERP без резервного копіювання — критичний ризик. * час реакції;

час вирішення;
критичність інцидентів;
графік підтримки;
відповідальних;
канали звернення;
ескалацію;
підтримку production;
підтримку тестового середовища;
підтримку інтеграцій;
підтримку API.

! Навіщо

сервер застосунків;
сервер бази даних;
СУБД;
файлове сховище;
web-сервер;
API-шлюз;
BI-сервер або BI-вітрини;
сервер резервного копіювання;
моніторинг;
платформа журналювання;
мережевий захист;
VPN;
платформа оновлень;
тестове середовище;
архівне середовище.

хмарну ERP;
ERP на власному сервері;
ERP у приватному датацентрі;
гібридну модель;
SaaS-модель;
on-premise-модель. | On-premise ERP, локальна ERP, ERP у власній інфраструктурі. |-

| Що обов’язково потрібно? # Перевірити ролі. | Більший контроль над даними, серверами, доступами, інтеграціями, резервними копіями й безпекою. # Спроєктувати серверну архітектуру. Де зберігається

Правило 3-2-1

доступність сервера;
навантаження CPU;
пам’ять;
диски;
місце на диску;
СУБД;
час відповіді;
API;
web-сервер;
BI-оновлення;
резервні копії;
помилки;
журнали;
активних користувачів;
підозрілу активність. Цифрова незалежність. K2 ERP на власному сервері здатна дати компанії контроль над критичною ERP-інфраструктурою: даними, доступами, інтеграціями, API, BI, резервними копіями, оновленнями і безпекою. Тому питання, де саме розміщена ERP, дуже важливе. Критично. ERP на власному сервері не можна відкривати назовні без HTTPS, сильних паролів, обмеження доступу, журналювання, резервних копій і контролю безпеки. Навіть у сучасній ERP можуть залишатися файлові обміни. Користувачі можуть працювати через:

ERP на власному сервері здатна бути частиною цифрової незалежності. Через API можуть працювати:

! {| class="wikitable" style="width:100%;" Сервер бази даних зберігає основні інформаційні дані ERP. Приклад архітектури:

Резервні копії

|- | Основна | Робочий сервер | Поточна робота |- | Локальний бекап | Резервний сервер | Швидке відновлення |- | Віддалений бекап | Інший майданчик або захищене сховище | Захист від аварії на основному майданчику |}

Коли краще хмарна ERP

У ній можуть зберігатися:

як приклад:

чи створюється бекап;
чи немає помилок;
чи можна відновити базу;
чи відкривається ERP після відновлення;
чи працюють користувачі;
чи працюють API;
чи працюють BI;
чи збережені файли;
чи працюють інтеграції;
скільки часу займає відновлення. Приклад

|- | app-k2-01 | Сервер застосунків K2 ERP | Web, бізнес-логіка, API |- | db-k2-01 | Сервер СУБД | Основна база даних |- | bi-k2-01 | BI-сервер | аналітичні інструменти і дашборди |- | backup-k2-01 | Резервні копії | Локальні й віддалені копії |- | test-k2-01 | Тестове середовище | оновлення версій і навчання |}

Користувачі

Журналювання

|- | Сервери підготовлені | Стабільна робота ERP |- | СУБД налаштована | Зберігання даних і продуктивність |- | HTTPS увімкнено | Захист web-доступу |- | VPN налаштовано | Захист віддаленого доступу |- | Резервні копії працюють | Відновлення після аварії |- | Відновлення перевірено | Бекап має бути придатним |- | Користувачі створені | Персональна робота |- | Ролі налаштовані | Мінімально необхідний доступ |- | API захищено | Безпечні інтеграції |- | BI перевірено | Коректна аналітичні інструменти |- | Моніторинг функціонує | Раннє виявлення проблем |}

ERP здатна зберігати файли:

Адміністратори ERP на власному сервері мають особливу відповідальність.

API на власному сервері

Для критичних систем потрібен SLA. # Налаштувати VPN або мережеві обмеження. | Так, якщо бізнесу потрібен контроль інфраструктури, СУБД, API, BI, інтеграцій і безпеки.== Відповідальність при ERP на власному сервері ==

Що таке ERP на власному сервері

XML;
JSON;
CSV;
Excel;
ZIP;
PDF;
банківські файли;
файли постачальників;
файли маркетплейсів.== Власний сервер в офісі ==

Для ERP на власному сервері бажано мати тестове середовище. # Перевірити відновлення. Сервер застосунків виконує бізнес-логіку ERP. {| class="wikitable" style="width:100%;"

довідники;
документи;
регістри;
залишки;
рухи;
користувачі;
ролі;
журнали;
конфігурація;
історія продукту;
API-дані;
BI-дані;
службові таблиці. компанія-користувач здатна обрати:

Ці показники допомагають правильно організувати резервне копіювання і аварійне відновлення. конкурентні переваги

Файлові обміни

персональні логіни;
ролі;
групи доступу;
підрозділи;
організації;
склади;
каси;
сервісних користувачів;
API-користувачів;
BI-користувачів;
адміністраторів;
аудиторів. Копія

логінів;
паролів;
документів;
персональних даних;
фінансових даних;
API-запитів;
BI-звітів;
токенів. Після запуску K2 ERP стара BAS/1С не повинна залишатися робочою системою. # Перевірити API.

старі сервери BAS/1С;
файлові бази;
клієнт-серверні бази;
СУБД;
web-публікації;
користувачів;
ролі;
зовнішні обробки;
інтеграції;
файлові обміни;
резервні копії;
BI-вивантаження;
архіви;
мережеві доступи.

критично про BAS і 1С. BAS та 1С мають санкційні, юридичні й кібербезпекові ризики в Україні. Недоліки

ERP на власному сервері і міграція з BAS/1С

Така модель протилежна SaaS, де ERP функціонує як хмарний сервіс постачальника. |- | Як ще називається така модель?

Для резервного копіювання часто використовують підхід 3-2-1:

ERP-система виступає як центральною інформаційною системою підприємства.

Ризики: ERP на власному сервері — це потужна модель розміщення, яка дає компанії контроль над ERP-інфраструктурою, даними, СУБД, API, BI, інтеграціями, доступами, резервними копіями й безпекою. * тільки для перегляду;

без введення нових документів;
без активних інтеграцій;
без доступу звільнених користувачів;
із резервною копією;
з обмеженим доступом;
із журналом використання;
із чіткою назвою “Архів”. Хто відповідає

Основні компоненти ERP на власному сервері

Не можна використовувати адміністратора для інтеграцій.== Моніторинг ==

Що таке on-premise ERP

обробку запитів користувачів;
роботу web-інтерфейсу;
проведення документів;
бізнес-процеси;
права доступу;
API;
фонові задачі;
регламентні процеси;
інтеграції;
журналювання;
перевірки даних. Потрібно резервувати:

Web-сервер потрібен для доступу через браузер. користувач системи

Це небезпечно, бо в аварійний момент здатна виявитися, що:

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

! # Зробити резервну копію. # Підготувати web-доступ. # Перевести старі BAS/1С-системи в архів. # Провести тестову міграцію.== Зовнішні посилання == Для ERP на власному сервері важлива якісна мережа. Web-сервер / API-шлюз

Коротко

Приклад серверної схеми

! як приклад:

↓

Масштабування

Потрібні: Зазвичай переносять: ! Він здатна бути потрібен для:

Власний датацентр підходить для більших компаній. ERP на власному сервері зазвичай складається з таких компонентів:

Архів старої BAS/1С

Найгірший сценарій. компанія-користувач переносить ERP на власний сервер, але не налаштовує резервні копії, HTTPS, VPN, моніторинг, ролі, API-захист і план відновлення. # Запустити production. Але така модель вимагає зрілої ІТ-дисципліни: серверного адміністрування, резервного копіювання, моніторингу, журналювання, оновлень, тестового середовища і плану аварійного відновлення. Зона

SLA здатна визначати:

сайт;
CRM;
WMS;
банк;
мобільний застосунок;
BI;
маркетплейс;
електронний електронний документообіг;
платформа доставки;
внутрішній портал;
виробниче обладнання. * клієнти;
постачальники;
договори;
замовлення;
склади;
залишки;
ціни;
закупівельна діяльність;
продажі та реалізація;
виробництво;
фінансовий блок;
каса;
банк;
зарплата;
кадри;
собівартість;
податкова інформаційні матеріали;
управлінська аналітичні інструменти;
документи;
персональні інформаційні дані;
інтеграційні ключі;
API-токени;
журнали дій. |-

| Чи можна розгорнути K2 ERP на власному сервері? Доступ

У ERP на власному сервері — це не без зусиль “поставити програму на сервер”. Кожен користувач системи має отримати тільки ті права, які потрібні для роботи. |-

Що таке ERP на власному сервері? Хто контролює інфраструктуру Хмарна ERP здатна бути кращою, якщо: втрата документів; втрата залишків; втрата фінансових даних; зупинка бізнесу; неможливість відновлення; втрати через людську помилку; втрати через технічну аварію; втрати через кібератаку. ERP на власному сервері потрібно моніторити. компанія-користувач отримує: Адміністративні права мають бути обмежені й контрольовані. Роль копія пошкоджена; не вистачає файлів; не збережені сертифікати; не функціонує СУБД; не функціонує API; не функціонує BI; не збережені конфігурація. * процесор; оперативна пам’ять; диски; СУБД; мережа; кількість користувачів; кількість документів; складність звітів; API-навантаження; BI-запити; резервне копіювання; інтеграції; фонові задачі; індекси; архівні інформаційні дані. Критерій
SaaS	У хмарі постачальника	Постачальник
On-premise	На серверах клієнта або в його датацентрі	клієнт ERP або його ІТ-партнер
Гібридна	Частково в хмарі, частково локально	Спільна відповідальність

!== Технічна підтримка K2 ERP ==

BI на власному сервері

Резервна копія має сенс тільки тоді, коли її можна відновити. ERP на власному сервері — це варіант впровадження, коли ERP-система встановлюється і функціонує на інфраструктурі, яку контролює сама компанія-користувач або її ІТ-підрядник. # Перевірити бізнес-сценарії.

Приватна хмарна інфраструктура здатна бути компромісом між on-premise і SaaS. Коментар

API на власному сервері дає можливість інтегрувати ERP з іншими системами. Модель

! Потрібно знати:

K2 ERP на власному сервері здатна бути доречною для компаній, які хочуть контролювати свою інфраструктуру, мають внутрішню ІТ-команду, потребують локальних інтеграцій, хочуть ізолювати критичні інформаційні дані або будують власну українську ERP-архітектуру. Питання

Перевірка відновлення

HTTPS;
маршрутизацію запитів;
web-інтерфейс;
API;
статичні файли;
журнали доступу;
обмеження IP;
інтеграцію з корпоративною мережею;
роботу через VPN або публічний домен. ↓

компанія-користувач отримує:

web-інтерфейс;
локальну мережу;
VPN;
віддалений робочий стіл;
корпоративний браузер;
мобільні сценарії;
API-клієнти;
BI-панелі. * фізичний сервер в офісі;
сервер у власному датацентрі;
віртуальна машина;
приватна хмарна інфраструктура;
орендований виділений сервер;
корпоративний кластер;
інфраструктура в датацентрі під контролем компанії.== Сервісні користувачі ==

компанія-користувач здатна мати резервні копії, але ніколи не перевіряти їх відновлення.

</syntaxhighlight>

Типові помилки

|- | api_site | інтеграційні функції ERP із сайтом | Товари, ціни, залишки, замовлення |- | api_crm | інтеграційні функції ERP з CRM | Клієнти, угоди, статуси |- | api_wms | інтеграційні функції ERP зі складом | Залишки, переміщення, відвантаження |- | bi_export | Передача даних у BI | Читання аналітичних даних |}

Потрібно визначити, хто і звідки має доступ.== Чек-лист перед запуском ERP на власному сервері ==

Вступ

перевірки оновлень;
перевірки доробок;
навчання користувачів;
тестування інтеграцій;
перевірки API;
перевірки BI;
тестової міграції;
відпрацювання аварійного відновлення.

! | компанія-користувач або її ІТ-партнер відповідає за сервери, СУБД, бекапи, оновлення версій, моніторинг і аварійне відновлення. Це повноцінна технічна архітектура, яка передбачено сервер застосунків, СУБД, файлове сховище, резервне копіювання, моніторинг, оновлення версій, доступи, ролі, API, BI, інтеграції, журналювання, кібербезпеку, адміністрування і підтримку.

API-шлюз здатна використовуватися для інтеграцій.

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

СУБД

довідники;
контрагентів;
номенклатуру;
склади;
договори;
залишки;
відкриті документи;
ціни;
серії;
характеристики;
взаєморозрахунки;
користувачів після аудиту;
ролі після перегляду;
інтеграційні сценарії;
звіти;
BI-показники;
архівні інформаційні дані за потреби. Потрібно проаналізувати:

Описати бізнес-вимоги. Відповідь

сайт;
CRM;
WMS;
мобільний застосунок;
BI;
банк;
електронний електронний документообіг;
сервіс доставки;
маркетплейс;
зовнішній інтегратор;
внутрішня платформа компанії. | Резервні копії, перевірка відновлення, HTTPS, VPN або обмеження доступу, ролі, журналювання, моніторинг і тестова база. Що означає

Див. так само

віддалених працівників;
філій;
бухгалтерії;
керівників;
адміністраторів;
інтеграторів;
зовнішніх консультантів. # Визначити модулі K2 ERP.== Типова технічна архітектура K2 ERP на власному сервері ==

API потрібно захищати окремо.== Мережа ==

API-шлюз

Помилка: не перевірити відновлення

|- | Контроль інфраструктури | Максимальний контроль у компанії | Більше відповідальності у постачальника |- | Старт | Потрібне конфігурація серверів | Зазвичай швидший |- | Адміністрування | Потрібна ІТ-команда | Частково або на 100% на постачальнику |- | Резервні копії | Відповідальність компанії або ІТ-партнера | Часто входять у сервіс |- | Безпека | Залежить від внутрішньої ІТ-дисципліни | Залежить від постачальника і договору |- | Інтеграції | інтуїтивно для локальних систем | інтуїтивно для web/API-сервісів |- | Масштабування | Потрібно планувати ресурси | Зазвичай простіше |- | Вартість | Сервери, адміністрування, технічна підтримка | Підписка або сервісна модель |}

План аварійного відновлення

! Обмеження

API потрібно захищати:

локальна WMS;
локальна CRM;
банківський клієнт ERP;
касове обладнання;
ваги;
обладнання складу;
SCADA;
виробничі системи;
GPS;
телефонія;
файлові обміни;
старі BAS/1С-бази;
BI-сервер. Потрібно налаштувати:

K2 ERP у цьому процесі здатна стати платформою для контрольованого розміщення ERP на власному сервері, керування користувачами, ролями, API, BI-аналітикою, інтеграціями, резервними копіями, web-доступом, оновленнями, моніторингом, журналюванням і подальшим розвитком автоматизації бізнесу без залежності від старої екосистеми BAS / 1С. У результаті власний сервер стає не перевагою, а критичною точкою ризику. ! Окремі продукти 1С і BAS внесені до переліків забороненого програмного забезпечення для окремих категорій організацій в Україні.

On-premise ERP — це міжнародна назва моделі, коли ERP розміщується “на майданчику” клієнта або в інфраструктурі, яку клієнт ERP контролює. * запуск ERP на слабкому сервері;

відсутність резервних копій;
резервні копії не перевіряються;
ERP відкрита в інтернет без захисту;
немає HTTPS;
немає VPN;
усі мають адміністративні права;
API функціонує під admin;
немає моніторингу;
немає тестового середовища;
немає плану відновлення;
немає відповідального адміністратора;
оновлення версій ставляться одразу в production;
BI перевантажує основну базу;
старі BAS/1С-інтеграції залишені активними. ↓

! |- | У чому недолік? # Налаштувати користувачів і ролі. |- | У чому перевага? # Перевірити BI.

Він здатна відповідати за:

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

BI на власному сервері

конкурентні переваги: ! Показник |- | RPO | Скільки даних можна втратити | Не більше 1 години |- | RTO | За скільки часу потрібно відновити систему | Не більше 4 годин |}

Якщо ERP відкрита без захисту, ризики зростають. {| class="wikitable" style="width:100%;"

старий хаотичний код;
неактуальні обробки;
спільні логіни;
зайві ролі;
старі інтеграції під admin;
дублікати довідників;
тестові бази;
помилкові залишки;
небезпечні web-публікації;
хаотичні файлові обміни;
неактуальні архіви;
санкційно ризикову залежність. ERP на власному сервері здатна бути доречною, якщо:

ERP на власному сервері і цифрова незалежність

як приклад: Правильний порядок: Потрібно періодично перевіряти: Потрібно вирішити:

== Приватна хмарна інфраструктура ==

Поточна версія на 18:42, 15 травня 2026

Web-сервер

VPN

Безпека ERP на власному сервері

RPO і RTO

Адміністратори

Помилка: сервер без резервного копіювання

Архівування

Як не треба робити

Як правильно впроваджувати ERP на власному сервері

Сервер бази даних

оновлення версій ERP на власному сервері

Фізичний сервер чи віртуальна машина

Що переносити з BAS/1С

Користувачі і ролі

Коли ERP на власному сервері доречна

HTTPS

Правило 3-2-1

Резервні копії

Коли краще хмарна ERP

Журналювання

API на власному сервері

Що таке ERP на власному сервері

Файлові обміни

ERP на власному сервері і міграція з BAS/1С

Основні компоненти ERP на власному сервері

Що таке on-premise ERP

Коротко

Приклад серверної схеми

Масштабування

Архів старої BAS/1С

BI на власному сервері

Перевірка відновлення

Типові помилки

Вступ

СУБД

Див. так само

API-шлюз

Помилка: не перевірити відновлення

План аварійного відновлення

BI на власному сервері

ERP на власному сервері і цифрова незалежність