Перейти до вмісту

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

Матеріал з K2 ERP Wiki
R (обговорення | внесок)
Бюрократи, Адміністратори інтерфейсу, Адміністратори
2367 редагувань
ВізуальнийВікірозмітка
Створена сторінка: {{DISPLAYTITLE:ERP на власному сервері}} {{SEO |title=ERP на власному сервері — on-premise ERP, локальне розгортання, безпека, backup, адміністрування і K2 ERP |description=ERP на власному сервері: що таке on-premise ERP, коли варто розгортати ERP локально, вимоги до серверів, мережі, СУБД, backup, бе...
 
Немає опису редагування
 
Рядок 1: Рядок 1:
=== Чи можна розгорнути K2 ERP на власному сервері? ===
Він здатна забезпечувати:


=== Що таке ERP на власному сервері? ===
Для ERP критично визначити два показники.== SLA ==


== Зовнішні посилання ==
== Web-сервер ==


== Помилка: немає тестового оновлення версій ==
== VPN ==


== оновлення версій ERP на власному сервері ==
Під час переходу з [[BAS]] або [[1С]] на [[K2 ERP]] на власному сервері потрібно не тільки перенести довідники, документи й залишки, а й переосмислити всю інфраструктуру: користувачів, ролі, API, BI, резервні копії, web-доступ, інтеграції, архіви, моніторинг і безпеку. # Налаштувати резервні копії. * більше оперативної пам’яті;
</div>
* швидші диски;
Вона має містити:
* окремий сервер СУБД;
* окремий сервер BI;
* окремий API-сервер;
* балансування навантаження;
* архівування старих даних;
* оптимізація запитів;
* збільшення мережевої пропускної здатності;
* резервний сервер. Потрібно продумати:
|-
| Фізичний сервер
| Контроль ресурсів, висока продуктивність
| Складніше масштабування і відновлення
|-
| Віртуальна машина
| Гнучкість, знімки, простіше перенесення
| Потрібна якісна віртуалізація
|}
 
Приклади:
 
== Безпека ERP на власному сервері ==
 
* електроживлення;
* резервне живлення;
* інтернет-канали;
* фізичну безпеку;
* доступ до серверів;
* резервне копіювання;
* пожежну безпеку;
* SLA датацентру;
* мережеву ізоляцію;
* відповідальність сторін.== Помилка: відкрити ERP напряму в інтернет ==


== Інтеграції на власному сервері ==
== RPO і RTO ==
Для власного сервера важливі:
== Файлове сховище ==


Якщо диск або сервер вийде з ладу, компанія-користувач втратить і базу, і резервну копію. | Backup, тест відновлення, firewall, HTTPS, VPN, моніторинг, тестовий контур, документація.[[Категорія:Power BI]]
* немає власної ІТ-команди;
* потрібен швидкий старт;
* не хочеться адмініструвати сервери;
* важлива прогнозована підписка;
* потрібне автоматичне оновлення версій;
* потрібна проста масштабованість;
* компанія-користувач не хоче підтримувати СУБД;
* потрібен доступ із різних локацій;
* немає складних локальних інтеграцій;
* бізнес-середовище хоче зосередитися на процесах, а не інфраструктурі. |-
| Що критично при міграції з BAS/1С?[[Категорія:Роль BAS]]


</syntaxhighlight>
* відключення електроенергії;
* слабке охолодження;
* крадіжка або фізичне пошкодження;
* слабкий інтернет;
* відсутність резервного каналу;
* відсутність цілодобового моніторингу;
* слабка фізична безпека;
* недостатнє резервне копіювання. Резервні копії — одна з найважливіших частин on-premise ERP.[[Категорія:Міграція з BAS]]


ERP на власному сервері часто функціонує у віртуальному середовищі. У хмарній ERP значну частину цієї відповідальності бере на себе провайдер. * неправильний розподіл ресурсів;
== Адміністратори ==
* конкуренція за диски;
* snapshot замість нормального backup;
* перевантаження хоста;
* відсутність моніторингу. * потрібна ІТ-команда;
* вищі стартові витрати;
* відповідальність за backup;
* відповідальність за безпеку;
* відповідальність за оновлення версій;
* ризики простою;
* потрібно обладнання;
* потрібен моніторинг;
* складніше масштабування;
* ризик застарівання серверів;
* потрібно планувати аварійне відновлення;
* потрібно контролювати фізичну безпеку. Вона особливо доречна для виробництва, логістики, агробізнесу, великих складів, підприємств із локальним обладнанням, закритими мережами або власною ІТ-командою.[[Категорія:Модулі K2 ERP]]
Для ERP, доступної з інтернету, HTTPS виступає як обов’язковим. Копія


Приклад:
* версію [[K2 ERP]];
* версію модулів;
* версію API;
* версію BI;
* версію СУБД;
* версію міграційних пакетів;
* дату оновлення версій;
* список змін;
* відповідального за оновлення версій. Але VPN не замінює ролі, паролі, журналювання і контроль доступів. # Зафіксувати версію.<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">
{| class="wikitable" style="width:100%;"


* UPS;
Потрібно контролювати:
* стабільне живлення;
ERP на власному сервері потрібно масштабувати. Доступ
* охолодження;
* фізичний доступ;
* пожежна безпека;
* контроль вологості;
* замки;
* відеоспостереження;
* обліковий облік доступу;
* резервний майданчик. # Перевірити звіти. Потрібно копіювати:


[[Категорія:API]]
оновлення версій потрібно виконувати контрольовано. Призначення


Не можна оновлювати робочу ERP без тесту й backup. Не завжди. ! Потрібно спочатку перевіряти оновлення версій на тестовому контурі. # Налаштувати мережу. Відповідальний
↓


* CPU;
* джерела даних;
* RAM;
* частоту оновлення версій;
* SSD/NVMe;
* права доступу;
* місце для бази;
* ролі BI-користувачів;
* місце для файлів;
* чи виступає як окрема аналітична база;
* місце для backup;
* чи можна експортувати інформаційні дані;
* мережеву пропускну здатність;
* хто бачить фінансові показники;
* резервне живлення;
* хто бачить собівартість;
* масштабування;
* хто бачить зарплату;
* моніторинг. Безпека має включати:
* хто адмініструє BI. Погані підходи:


Компанії обирають on-premise ERP, коли потрібні:
== Помилка: сервер без резервного копіювання ==


* схему серверів;
== Архівування ==
* IP-адреси;
Вони можуть керувати:
* доменні імена;
{| class="wikitable" style="width:100%;"
* порти;
* ролі серверів;
* версії ПЗ;
* СУБД;
* backup-політику;
* процедуру відновлення;
* список інтеграцій;
* список сервісних облікових записів;
* список адміністраторів;
* графік оновлень;
* правила доступу;
* аварійні контакти. оновлення версій має виконуватися контрольовано.<syntaxhighlight lang="text">
== Типові питання ==
Відкрити API ERP напряму в інтернет без обмежень. Критерій


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


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


* роботу користувачів;
== Як не треба робити ==
* обробку документів;
* бізнес-процеси;
* workflow;
* API;
* фонові задачі;
* друковані форми;
* інтеграції;
* обробку файлів;
* авторизацію;
* логування.<syntaxhighlight lang="text">


<syntaxhighlight lang="text">
технічна підтримка ERP на власному сервері здатна включати:


__TOC__
[[Категорія:Автоматизація бізнесу]]


! * тільки з локальної мережі;
'''Правильний підхід.''' ERP на власному сервері потрібно впроваджувати як інфраструктурний проєкт: із серверною архітектурою, СУБД, резервними копіями, тестовою базою, HTTPS, VPN, ролями, API, BI, моніторингом, журналюванням і планом аварійного відновлення.== Доступ користувачів ==
* через VPN;
Приклад:
* через корпоративний портал;
[[Категорія:Цифрова незалежність України]]
* через reverse proxy;
[[Категорія:Резервна копія]]
* через захищений web-доступ;
== Як правильно впроваджувати ERP на власному сервері ==
* через окремий API-шлюз;
[[Категорія:SaaS]]
* через віддалений робочий стіл, якщо так вирішено;
Резервне копіювання + BI + Архів
* з філій через site-to-site VPN.[[Категорія:Цифрова незалежність України]]
Під час переходу з [[BAS]] або [[1С]] на [[K2 ERP]] на власному сервері потрібно врахувати не тільки інформаційні дані, а й інфраструктуру. Для ERP СУБД виступає як критично важливою частиною інфраструктури. це модель розміщення [[ERP]]-системи.== Тестове середовище ==


== Правило 3-2-1 для backup ==
== Сервер бази даних ==


DEV → TEST → PROD
! # Налаштувати HTTPS. # Налаштувати журналювання. # Виконати контрольні звірки. Де функціонує ERP
[[Категорія:Деколонізація обліку]]
BI здатна бути розміщений:
== оновлення версій ERP на власному сервері ==
HTTPS захищає передачу:
</div>
!<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">


'''ERP на власному сервері''' — це модель розгортання, за якої ERP-система встановлюється на сервери, що контролюються компанією. |-
* HTTPS;
| Кому підходить? |-
* VPN або обмеження IP;
| Альтернатива
* сильні паролі;
| Хмарна або гібридна ERP. Призначення
* журналювання;
== Модулі K2 ERP на власному сервері ==
* обмеження ролей;
[[Категорія:Реплікатор K2]]
* захист API;
Практичне правило:
* моніторинг;
* регулярні оновлення версій.== Датацентр ==
Якщо ERP розміщується не в офісі, а в датацентрі, потрібно перевірити:
компаній забезпечується через У випадку [[K2 ERP]] розміщення на власному сервері здатна бути доречним; так само реалізовано які мають підвищені вимоги до контролю даних, внутрішньої безпеки, інтеграцій з локальними системами, регуляторних обмежень, роботи у власному датацентрі, корпоративних політик ІТ або бажають на 100% контролювати серверну інфраструктуру. # Запланувати вікно оновлення версій. ! # Визначити API та BI. {| class="wikitable" style="width:100%;"
|-
|-
| Щоденний
| Сервери
| Щодня вночі
| компанія-користувач або ІТ-підрядник
| 14–30 днів
|-
|-
| Тижневий
| СУБД
| Раз на тиждень
| DBA або адміністратор
| 2–3 місяці
|-
|-
| Місячний
| Резервні копії
| Раз на місяць
| ІТ-служба / підрядник
| 1–3 роки
|-
| Перед оновленням
| Перед кожним оновленням
| До підтвердження стабільної роботи
|-
| Перед міграцією
| Перед кожним великим імпортом
| До завершення звірки
|}
 
ERP на власному сервері — це модель розгортання, коли ERP-система, база даних, файли, інтеграції й backup розміщуються на серверах, які контролює компанія-користувач. |-
| Сервер застосунку
| Виконання бізнес-логіки ERP
| Application server
|-
|-
| Сервер бази даних
| оновлення версій K2 ERP
| Зберігання даних
| Постачальник / впроваджувач / адміністратор
| PostgreSQL, MS SQL, інша СУБД
|-
|-
| Файлове сховище
| Користувачі й ролі
| Документи, вкладення, архіви
| Адміністратор ERP
| Файловий сервер або object storage
|-
|-
| Web-сервер
| API
| Доступ користувачів через браузер
| Інтегратор / адміністратор
| Nginx, IIS, Apache
|-
|-
| Сервер інтеграцій
| BI
| API, обміни, фонові задачі
| Аналітик / адміністратор BI
| Integration service
|-
|-
| Backup-сервер
| Безпека
| Резервні копії
| ІТ-служба / служба безпеки
| NAS, backup storage
|-
| Моніторинг
| Контроль стану системи
| Zabbix, Grafana, інші системи
|-
| VPN / Firewall
| Захист доступу
| VPN-шлюз, міжмережевий екран
|}
|}


виробництва забезпечується через Такий підхід застосовується для, коли бізнес-середовище хоче мати максимальний контроль над даними, інфраструктурою, доступами, інтеграціями, політиками безпеки, резервними копіями, мережевими правилами і внутрішнім ІТ-контуром. |-
Безпека має включати:
| провідний недолік
| компанія-користувач сама відповідає за сервери, backup, безпеку, оновлення версій й відновлення. ![[Категорія:Backup]]
Він відповідає за:
Потрібно розділяти:


[[Категорія:Заміна BAS]]
[[Категорія:Web-сервіси 1С]]


Хмарна ERP здатна бути кращою, якщо:
* консультації;
</syntaxhighlight>
* оновлення версій;
</div>
* виправлення помилок;
Потрібен реєстр інтеграцій. # Перевірити інтеграції.[[Категорія:K2 Cloud ERP]]
* аналіз журналів;
* перевірку продуктивності;
* підтримку інтеграцій;
* підтримку API;
* підтримку BI;
* допомогу з резервними копіями;
* консультації з СУБД;
* допомогу при аваріях;
* супровід міграції;
* навчання адміністраторів. Найчастіші помилки:
 
* токенами;
* HTTPS;
* обмеженням IP;
* ролями;
* журналюванням;
* лімітами;
* окремими сервісними користувачами. СУБД — це платформа керування базами даних. |-
| Чи виступає як санкційні ризики у [[BAS]] і [[1С]]? |}


критично, щоб модулі не жили як окремі “острови”, а використовували єдині довідники, права, audit log і контрольні звіти. Де:
! # Визначити кількість користувачів. ! | Перенести інформаційні дані й процеси, але не залишити стару BAS/1С активним джерелом обліку або інтеграцій. # Налаштувати інтеграції. Спрощена схема:


== Аутентифікація користувачів ==
Якщо ERP доступна через web, потрібно використовувати HTTPS.[[Категорія:ERP на власному сервері]]


{| class="wikitable" style="width:100%;"
* продажі та реалізація;
* залишки;
* прибуток;
* маржу;
* собівартість;
* дебіторську заборгованість;
* кредиторську заборгованість;
* складські 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]]
* [[Українське програмне забезпечення]]
* [[Автоматизація бізнесу]]
* [[Цифрова незалежність]]
* [[Деколонізація обліку]]


* банками;
[[Категорія:XML]]
* сайтом;
* CRM;
* WMS;
* MES;
* Power BI;
* електронним документообігом;
* IP-телефонією;
* маркетплейсами;
* службами доставки;
* вагами;
* сканерами;
* ТСД;
* GPS;
* паливними картками;
* виробничим обладнанням;
* локальними базами;
* державними сервісами.[[Категорія:ERP на власному сервері]]


[[Категорія:СУБД]]
* [https://erp.kyiv.ua Сайт K2 ERP]
* [https://wiki.erp.kyiv.ua Wiki K2 ERP]
* [https://cloud.corp2.eu хмарна інфраструктура K2 ERP]
* [https://cip.gov.ua/ua/statics/perelik-zaboronenogo-do-vikoristannya-programnogo-zabezpechennya-ta-komunikaciinogo-merezhevogo-obladnannya Перелік забороненого до використання програмного забезпечення на сайті Держспецзв’язку]
* [https://cip.gov.ua/ua/news/vidpovidi-na-poshireni-zapitannya-shodo-pereliku-zaboronenogo-programnogo-zabezpechennya-ta-obladnannya Роз’яснення Держспецзв’язку щодо переліку забороненого ПЗ]
* [https://www.president.gov.ua/documents/6012024-52009 Указ Президента України №601/2024]
* [https://zakon.rada.gov.ua/go/601/2024 Указ Президента України №601/2024 на сайті Верховної Ради України]
* [https://t.me/+uIdWI1W6vndkMTAy Telegram-канал K2 ERP]
* [https://t.me/+6jFwAZM6TQliNTdi Група обговорення функціоналу та пропозицій]
* [https://www.linkedin.com/company/k2erp/ LinkedIn K2]


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


* куди вони підключаються;
<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">
* які токени використовують;
* хто відповідальний;
* що буде, якщо інтеграційні функції ERP впаде;
* де журнали;
* як повторити помилковий обмін;
* які IP відкриті у firewall. | Компаніям із власною ІТ-командою, локальними інтеграціями і високими вимогами до контролю. Доступ


'''Проста аналогія.''' Хмарна ERP — це орендований офіс із готовою охороною, електрикою і прибиранням. # Зафіксувати версію і результат. |-
Наслідки:
| Основна
Воно потрібне для:
| Робочий сервер
! У on-premise моделі відповідальність потрібно чітко розділити. Тому перехід на [[K2 ERP]] на власному сервері здатна бути частиною стратегії цифрової незалежності, контролю даних і відмови від старої ризикової екосистеми. # Підготувати СУБД. Для чого
| Поточна робота
== Що переносити з BAS/1С ==
|-
BI здатна показувати:
| Локальний backup
[[Категорія:K2 ERP]]
| NAS або backup-сервер
<syntaxhighlight lang="text">
| Швидке відновлення
! Сервісні користувачі потрібні для інтеграцій. Призначення
|-
| Віддалений backup
| Інший майданчик або захищене сховище
| Відновлення після аварії
|}


!== Реплікатор K2 і власний сервер ==
== Версійність ==


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


Для ERP на власному сервері потрібно мати план аварійного відновлення. * кількості користувачів;
'''Головне.''' ERP на власному сервері дає компанії більше контролю над даними, інфраструктурою, доступами, інтеграціями та безпекою, але вимагає відповідальності за сервери, резервні копії, оновлення версій, моніторинг, кібербезпеку і технічну підтримку. | Це модель, коли ERP функціонує на серверах компанії або в інфраструктурі, яку компанія-користувач контролює. Порядок:
* модулів;
* обсягу даних;
* інтенсивності інтеграцій;
* BI-навантаження;
* кількості документів;
* файлів;
* звітів;
* потрібної відмовостійкості. # Перевірити відновлення. # Оновити робочу систему. |-
| Що обов’язково?== Права доступу ==
== Реєстр інтеграцій ==
=== Чи дешевше власний сервер за хмару? ===
[[Категорія:Міграція даних]]
Тестовий сервер не повинен надсилати реальні листи, платежі, API-запити або обміни з сайтом без контролю.== Моніторинг ERP ==


* маршрутизацію запитів;
* HTTPS;
* reverse proxy;
* балансування;
* обмеження доступу;
* журналювання;
* захист API;
* інтеграцію з сертифікатами;
* публікацію зовнішніх endpoint-ів.[[Категорія:Міграція з BAS]]
== Коли власний сервер доречний ==
== Відновлення після аварії ==
{| class="wikitable" style="width:100%;"
{| class="wikitable" style="width:100%;"
{| class="wikitable" style="width:100%;"
! Погано:


[[Категорія:Міграція з 1С]]
Журналювання потрібне для:
 
* контроль над даними;
* контроль над серверами;
* контроль над резервними копіями;
* контроль над API;
* контроль над BI;
* контроль над користувачами;
* контроль над ролями;
* контроль над інтеграціями;
* контроль над оновленнями;
* незалежність від старої BAS/1С-інфраструктури;
* можливість будувати українську ERP-архітектуру. * на тому самому сервері;
* на окремому сервері;
* у хмарі;
* у гібридній моделі;
* як окрема аналітична база;
* як вітрина даних. Хмарна ERP
 
[[Категорія:JSON 1С]]
 
[[Категорія:BAS]]
 
* які інформаційні дані залишати в робочій базі;
* які переносити в архів;
* як відкривати архів;
* хто має доступ;
* чи потрібен пошук;
* чи потрібні звіти по архіву;
* як зберігати документи;
* як резервувати архів. ERP на власному сервері має мати план аварійного відновлення. ERP на власному сервері
 
== Власний датацентр ==
 
[[Категорія:1С]]
 
* виділену інфраструктуру;
* контроль доступів;
* гнучке масштабування;
* віртуальні машини;
* резервування;
* ізоляцію;
* інтеграції;
* можливість розміщення в потрібному датацентрі.== Продуктивність ==


* фінансовий блок;
== Висновок ==
* бухгалтерський обліковий облік;
* управлінський обліковий облік;
* продажі та реалізація;
* закупівельна діяльність;
* складський облік;
* WMS;
* CRM;
* виробництво;
* MRP;
* MES;
* HRM;
* зарплата;
* електронний документообіг;
* автотранспорт;
* агро;
* елеватор;
* акцизне пальне;
* BI;
* API;
* інтеграції.== Гібридний варіант ==


* повний контроль над даними;
! здатна знадобитися:
* розміщення даних у власній інфраструктурі;
* робота в закритій мережі;
* внутрішні вимоги безпеки;
* інтеграції з локальним обладнанням;
* підключення до виробничих систем;
* інтеграції з вагами, ТСД, сканерами, станками, GPS, WMS, MES;
* контроль доступу через корпоративну мережу;
* власна політика backup;
* власна політика оновлень;
* відповідність внутрішнім ІТ-стандартам;
* незалежність від зовнішньої хмари;
* контроль продуктивності;
* робота в умовах нестабільного інтернету. Краще:
Сервер бази даних — один із найважливіших компонентів ERP. Потрібно рахувати повну вартість. Де зберігається


'''[[Реплікатор K2]]''' здатна допомогти при міграції з 1С/BAS у K2 ERP. # Налаштувати моніторинг. Погано:
[[Категорія:K2]]
<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
{| class="wikitable" style="width:100%;"
|-
| Банк
| ERP ↔ Банк
| API / файл
| фінансовий блок + ІТ
| Висока
|-
| Сайт
| Сайт → ERP
| REST API
| продажі та реалізація + ІТ
| Висока
|-
| Power BI
| ERP → BI
| Data export
| Аналітик
| Середня
|-
| WMS
| ERP ↔ складський облік
| API
| Логістика + ІТ
| Висока
|}


'''Практичний сенс.''' Якщо компанія-користувач має виробництво, складський облік із ТСД, локальні ваги, внутрішню мережу, власний домен, закриті інтеграції й ІТ-команду, ERP на власному сервері здатна бути логічним вибором. ERP база: базовий сервер
* аудиту;
[[Категорія:Кібербезпека]]
* безпеки;
Права доступу мають бути налаштовані за принципом мінімально необхідного доступу. Відповідь
* розслідування помилок;
== Сервер бази даних ==
* контролю користувачів;
Ризики:
* контролю API;
</syntaxhighlight>
* контролю адміністраторів;
|-
* контролю інтеграцій;
| Немає перевіреного backup
* аналізу продуктивності;
| Копії створюються, але не тестуються
* виявлення підозрілих дій. | Так.== Порівняння власного сервера і хмари ==
| Неможливо відновити ERP
|-
| ERP відкрита в інтернет напряму
| Хотіли оперативно дати доступ
| Ризик атаки і витоку даних
|-
| Немає тестового контуру
| Економія ресурсів
| оновлення версій ламає робочу систему
|-
| Усе на одному сервері
| Просте розгортання
| Один збій зупиняє всю ERP
|-
| Немає моніторингу
| Проблеми бачать тільки користувачі
| Збої помічають запізно
|-
| Backup на тому самому диску
| Неправильна економія
| При аварії втрачається і база, і backup
|-
| Немає документації
| Усе знає один адміністратор
| Ризик при звільненні або аварії
|}


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


Але власний сервер означає і власну відповідальність: backup, безпека, оновлення версій, моніторинг, відновлення після аварії, продуктивність, права доступу, інтеграції, документація і фізичний захист інфраструктури мають бути організовані професійно. Критичність
[[Категорія:СУБД]]


== Електроживлення і фізична безпека ==
У базі можуть бути:


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


Типова схема:
<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">


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


<syntaxhighlight lang="text">
<syntaxhighlight lang="text">
Для критичних ролей бажано використовувати посилений захист, особливо для адміністраторів, фінансів, зарплати й API. Сервер застосунку виконує бізнес-логіку ERP.== Відмовостійкість ==


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


Якщо ERP відкриває API, потрібно передбачити:
</div>


* доступність ERP;
ERP на власному сервері має підтримувати чітку модель користувачів.== Принцип мінімального доступу ==
* CPU;
 
* RAM;
* входи;
* диски;
* помилки входу;
* місце на диску;
* зміну документів;
* навантаження СУБД;
* зміну довідників;
* час відповіді;
* експорт;
* помилки web-сервера;
* API-запити;
* фонові задачі;
* зміну ролей;
* інтеграції;
* адміністративні дії;
* backup;
* помилки системи;
* сертифікати;
* помилки інтеграцій. # Налаштувати моніторинг. Користувачі → Корпоративна мережа / VPN / Web → Сервер ERP → СУБД → інформаційні дані компанії
* черги;
 
* журнали помилок. * ERP функціонує на власному сервері;
! BI здатна працювати на окремому сервері або разом із ERP. Варіант
* Power BI функціонує в хмарі;
* backup дублюється в захищене хмарне сховище;
* сайт функціонує в хмарі;
* API-шлюз розміщений у DMZ;
* частина користувачів функціонує через VPN;
* мобільний застосунок підключається через захищений reverse proxy;
* архівні копії зберігаються поза основним майданчиком.[[Категорія:ERP інфраструктура]]


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


* сервер застосунку;
! Web / VPN / Локальна мережа
* сервер бази даних;
* файлове сховище;
* web-доступ;
* API;
* інтеграції;
* backup;
* тестовий контур;
* моніторинг;
* права доступу;
* audit log;
* Power BI-шар;
* аварійне відновлення. Приклади:
{| class="wikitable" style="width:100%;"
Це дуже часта помилка.== Web-сервер ==


== Audit log ==
як приклад:
== Віртуалізація ==
== On-premise ERP і хмарна ERP ==


Правильний on-premise підхід дає можливість компанії отримати сучасну українську ERP-систему з повним контролем над даними, безпечною інфраструктурою, прозорими інтеграціями й готовністю до масштабування. * які порти відкриті;
* контроль доступів;
* хто має доступ до web-сервера;
* складні паролі;
* хто має доступ до СУБД;
* двофакторну автентифікацію для критичних ролей;
* хто має доступ до SSH/RDP;
* обмеження адміністраторів;
* які IP дозволені;
* HTTPS;
* які API доступні зовні;
* VPN;
* які інтеграції можуть підключатися;
* міжмережевий екран;
* які сервіси доступні тільки всередині мережі. * сервери;
* обмеження доступу до СУБД;
* диски;
* захист резервних копій;
* мережеве обладнання;
* журналювання;
* ліцензії ОС;
* ліцензії СУБД, якщо потрібні;
* backup-сховище;
* UPS;
* електрику;
* охолодження;
* адміністраторів;
* моніторинг;
* моніторинг;
* оновлення версій;
* регулярні оновлення версій;
* антивірус і безпеку;
* антивірусний контроль;
* аварійне відновлення;
* аудит сервісних акаунтів;
* підтримку;
* контроль API;
* простої;
* контроль експорту даних. * локальну мережу;
* заміну обладнання.== Документація ERP-інфраструктури ==
* VPN;
* доступ філій;
* доступ віддалених користувачів;
* пропускну здатність;
* затримки;
* резервний інтернет;
* міжмережеві екрани;
* сегментацію мережі;
* доступ до СУБД;
* доступ до API;
* доступ до резервних копій. Перевірка


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


== Power BI і ERP на власному сервері ==
!</syntaxhighlight>
== Користувачі і ролі ==
На продуктивність ERP на власному сервері впливають:
|-
| Менеджер
| Клієнти, замовлення, рахунки
| Немає доступу до зарплати й адміністрування
|-
| Комірник
| Складські документи, інвентаризація
| Немає доступу до банку й собівартості
|-
| Бухгалтер
| Каса, банк, проводки, формування звітів
| Без технічного адміністрування
|-
| Керівник
| Звіти, BI, KPI
| Без зміни первинних документів
|-
| API-користувач
| Конкретні API-методи
| Без доступу до зайвих модулів
|}


В on-premise ERP компанія-користувач сама відповідає за сервери, backup, безпеку, оновлення версій і моніторинг. Для ERP на власному сервері audit log особливо важливий, бо компанія-користувач сама контролює інфраструктуру і має мати докази подій. Зберігання
СУБД


TCO або повна вартість володіння містить:
== Коли ERP на власному сервері доречна ==


Для K2 ERP на власному сервері критично спроєктувати:
Не потрібно переносити:


! * сервери;
* серверами;
* СУБД;
* СУБД;
* файлове сховище;
* користувачами;
* backup;
* ролями;
* тестовий контур;
* резервними копіями;
* мережевий доступ;
* оновленнями;
* VPN;
* журналами;
* інтеграціями;
* API;
* API;
* інтеграції;
* BI;
* Power BI;
* web-сервером;
* права доступу;
* безпекою. ! Сервер
* архів старої BAS/1С;
Після переходу стара BAS/1С здатна залишитися як архів. # Перевірити BI. Окремі продукти [[1С]] і [[BAS]] внесені до відкритих переліків програмного забезпечення, забороненого до використання для окремих категорій організацій.[[Категорія:Заміна 1С]]
* план аварійного відновлення. # Узгодити час оновлення версій. Напрям
[[Категорія:Відновлення після аварії]]
Сервер бази даних не повинен бути доступний напряму з інтернету. # Налаштувати тестовий контур.</div>


== Мережа і доступ ==
{{SEO
|title=ERP на власному сервері — on-premise ERP, K2 ERP, безпека, СУБД, резервні копії, API, BI і міграція з BAS
|description=ERP на власному сервері: що таке on-premise ERP, як працює локальне розміщення K2 ERP, сервери, СУБД, безпека, резервні копії, оновлення, API, BI, інтеграції, підтримка, SLA, порівняння з хмарою і перехід з BAS та 1С.
|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С, цифрова незалежність
|image=https://erp.kyiv.ua
}}


</syntaxhighlight>
* базу даних;
 
* файлове сховище;
== ERP на власному сервері і міграція з 1С/BAS ==
* конфігурацію;
 
* довідники;
* документи;
* проводки;
* регістри;
* залишки;
* історію змін;
* користувачів;
* права;
* конфігурація;
* конфігурація;
* сертифікати;
* API-ключі;
* BI-вітрини;
* web-сервер;
* скрипти;
* документацію;
* журнали;
* журнали;
* інформаційні дані інтеграцій;
* інтеграційні файли.[[Категорія:On-premise]]
* аналітичні таблиці. # Визначити кількість користувачів. ! # Налаштувати інтеграції. ERP на власному сервері


# Описати цілі розгортання.<syntaxhighlight lang="text">
== HTTPS ==
[[Категорія:VPN]]
Через кілька років ERP здатна мати десятки інтеграцій, але ніхто не знає:
|-
| Що це? * диск бази даних;
* диск журналів СУБД;
* диск файлів;
* диск backup;
* тимчасові файли;
* архіви. {| class="wikitable" style="width:100%;"


== Продуктивність ERP на власному сервері ==
ERP без резервного копіювання — критичний ризик. * час реакції;
* час вирішення;
* критичність інцидентів;
* графік підтримки;
* відповідальних;
* канали звернення;
* ескалацію;
* підтримку production;
* підтримку тестового середовища;
* підтримку інтеграцій;
* підтримку API.[[Категорія:Оновлення K2 ERP]]


'''Головне.''' ERP на власному сервері — це не без зусиль “поставити програму на комп’ютер”. |}
! Навіщо


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


Правильний порядок:
[[Категорія:Ліцензування K2 ERP]]


=== Що найважливіше при ERP на власному сервері? ===
* хмарну ERP;
* ERP на власному сервері;
* ERP у приватному датацентрі;
* гібридну модель;
* SaaS-модель;
* on-premise-модель. | On-premise ERP, локальна ERP, ERP у власній інфраструктурі. |-
| Що обов’язково потрібно? # Перевірити ролі. | Більший контроль над даними, серверами, доступами, інтеграціями, резервними копіями й безпекою. # Спроєктувати серверну архітектуру. Де зберігається


! * логіни;
== Правило 3-2-1 ==
* паролі;
* сесії;
* документи;
* фінансові інформаційні дані;
* зарплату;
* персональні інформаційні дані;
* API-токени;
* файли;
* інтеграційні запити. Без документації ERP залежить від пам’яті одного адміністратора. # Виконати контрольні перевірки. Потрібно рахувати повну вартість володіння: обладнання, ліцензії, адміністрування, електрику, backup, безпеку, моніторинг, простої й оновлення версій. # Налаштувати права.== Вимоги до серверів ==


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


Власний сервер не завжди дешевший за хмару. # Запустити користувачів. Приклад
ERP на власному сервері здатна бути частиною цифрової незалежності. Через API можуть працювати:


</div>
! {| class="wikitable" style="width:100%;"
Сервер бази даних зберігає основні інформаційні дані ERP. Приклад архітектури:
== Резервні копії ==
|-
| Основна
| Робочий сервер
| Поточна робота
|-
| Локальний бекап
| Резервний сервер
| Швидке відновлення
|-
| Віддалений бекап
| Інший майданчик або захищене сховище
| Захист від аварії на основному майданчику
|}


== K2 ERP на власному сервері ==
== Коли краще хмарна ERP ==


Для on-premise ERP бажано мати окремий тестовий контур. Потрібно підготувати:
У ній можуть зберігатися:


* немає власної ІТ-команди;
як приклад:
* потрібно оперативно стартувати;
* компанія-користувач не хоче купувати сервери;
* користувачі працюють віддалено;
* потрібне просте масштабування;
* немає складних локальних інтеграцій;
* критично зменшити стартові витрати;
* backup і адміністрування краще передати провайдеру;
* бізнес-середовище не хоче утримувати серверну інфраструктуру. 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
| Тестове середовище
| оновлення версій і навчання
|}


[[Категорія:K2 ERP]]
[[Категорія:Оновлення BAS]]


* тільки для читання;
Користувачі
* інтеграції вимкнені;
== Журналювання ==
* регламентні задача вимкнені;
[[Категорія:Безпека]]
* доступ обмежений;
|-
* backup збережений;
| Сервери підготовлені
* дата переходу зафіксована;
| Стабільна робота ERP
* контрольні звіти сформовані;
|-
* архів не застосовується для для нових операцій.== Безпека ERP на власному сервері ==
| СУБД налаштована
це варіант розгортання ERP-системи. * API-ключі;
| Зберігання даних і продуктивність
* firewall;
|-
* IP-адреси;
| HTTPS увімкнено
* журнали;
| Захист web-доступу
* черги;
|-
* повтори;
| VPN налаштовано
* external_id;
| Захист віддаленого доступу
* помилки;
* таймаути;
* безпеку.{{DISPLAYTITLE:ERP на власному сервері}}
 
* 3 копії даних;
* 2 різні типи носіїв або сховищ;
* 1 копія поза основним майданчиком.[[Категорія:Права доступу]]
=== Кому підходить ERP на власному сервері? ===
Він здатна використовуватися для:
 
Backup — критична частина on-premise ERP.== Для чого обирають ERP на власному сервері ==
|-
|-
| Менеджер продажів
| Резервні копії працюють
| Клієнти, угоди, замовлення, свої звіти
| Відновлення після аварії
|-
|-
| Комірник
| Відновлення перевірено
| Складські операції, залишки, інвентаризація
| Бекап має бути придатним
|-
|-
| Фінансист
| Користувачі створені
| Платежі, бюджети, ДДС, платіжний календар
| Персональна робота
|-
|-
| Бухгалтер
| Ролі налаштовані
| Первинні документи, податки, проводки
| Мінімально необхідний доступ
|-
|-
| HR
| API захищено
| Кадрові інформаційні дані, відпустки, табелі
| Безпечні інтеграції
|-
|-
| Зарплатний бухгалтер
| BI перевірено
| Нарахування, утримання, податки, виплати
| Коректна аналітичні інструменти
|-
|-
| Адміністратор
| Моніторинг функціонує
| Технічне адміністрування
| Раннє виявлення проблем
|}
|}


Потрібно контролювати:
ERP здатна зберігати файли:
 
Адміністратори ERP на власному сервері мають особливу відповідальність.[[Категорія:API]]
 
== API на власному сервері ==


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


оновлення версій без тесту здатна зламати:
== Що таке ERP на власному сервері ==


Правила:
* XML;
* JSON;
* CSV;
* Excel;
* ZIP;
* PDF;
* банківські файли;
* файли постачальників;
* файли маркетплейсів.== Власний сервер в офісі ==
Для ERP на власному сервері бажано мати тестове середовище. # Перевірити відновлення. Сервер застосунків виконує бізнес-логіку ERP. {| class="wikitable" style="width:100%;"


* входи користувачів;
* довідники;
* створення документів;
* документи;
* зміну документів;
* регістри;
* видалення;
* залишки;
* погодження;
* рухи;
* зміну прав;
* користувачі;
* зміну фінансових реквізитів;
* ролі;
* експорт даних;
* журнали;
* зміну зарплати;
* конфігурація;
* API-запити;
* історія продукту;
* помилки;
* API-дані;
* запуск інтеграцій;
* BI-дані;
* зміну налаштувань. Ключові показники:
* службові таблиці. компанія-користувач здатна обрати:
 
Ці показники допомагають правильно організувати резервне копіювання і аварійне відновлення. конкурентні переваги
 
== Файлові обміни ==
 
* персональні логіни;
* ролі;
* групи доступу;
* підрозділи;
* організації;
* склади;
* каси;
* сервісних користувачів;
* API-користувачів;
* BI-користувачів;
* адміністраторів;
* аудиторів. Копія


* повний контроль над даними;
* логінів;
* контроль інфраструктури;
* паролів;
* можливість закритої мережі;
* документів;
* гнучкі політики доступу;
* персональних даних;
* локальні інтеграції;
* фінансових даних;
* незалежність від cloud-провайдера;
* API-запитів;
* власний графік оновлень;
* BI-звітів;
* можливість глибокого адміністрування;
* токенів. Після запуску [[K2 ERP]] стара BAS/1С не повинна залишатися робочою системою. # Перевірити API.[[Категорія:ERP]]
* локальне зберігання великих файлів;
* потенційно нижча вартість при великому масштабі й сильній ІТ-команді. Після переходу стару 1С/BAS-базу можна залишити як архів.== Вартість володіння ERP на власному сервері ==


* процесор;
* старі сервери BAS/1С;
* оперативна пам’ять;
* файлові бази;
* диски;
* клієнт-серверні бази;
* мережа;
* СУБД;
* СУБД;
* кількість користувачів;
* web-публікації;
* обсяг даних;
* користувачів;
* звіти;
* ролі;
* зовнішні обробки;
* інтеграції;
* інтеграції;
* фонові задачі;
* файлові обміни;
* індекси;
* резервні копії;
* backup у робочий час;
* BI-вивантаження;
* антивірус;
* архіви;
* віртуалізація;
* мережеві доступи.[[Категорія:Заміна BAS]]
* якість коду;
* конфігурація web-сервера. Такий підхід часто дає баланс між контролем і гнучкістю. # Оцінити обсяг даних. Це можуть бути:


[[Категорія:BI]]
'''критично про BAS і 1С.''' [[BAS]] та [[1С]] мають санкційні, юридичні й кібербезпекові ризики в Україні. Недоліки
== ERP на власному сервері і міграція з BAS/1С ==
Така модель протилежна SaaS, де ERP функціонує як хмарний сервіс постачальника. |-
| Як ще називається така модель?[[Категорія:Конфігурація BAS]]
{{DISPLAYTITLE:ERP на власному сервері}}
Для резервного копіювання часто використовують підхід 3-2-1:


* хто відповідальний;
ERP-система виступає як центральною інформаційною системою підприємства. __TOC__
* де backup;
* як відновити базу;
* як відновити файли;
* як підняти web-сервер;
* як перевірити ERP після відновлення;
* які інтеграції ввімкнути;
* які користувачі тестують;
* скільки даних можна втратити;
* скільки часу бізнес-середовище здатна бути без ERP. У такій моделі компанія-користувач сама або через підрядника відповідає за інфраструктуру. '''Критично.''' Backup ERP, який не перевірявся на відновлення, не можна вважати робочим backup.[[Категорія:Сервери]]


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


* RAID;
== Основні компоненти ERP на власному сервері ==
* резервне живлення;
* другий сервер;
* репліка бази;
* кластер;
* резервний інтернет;
* віддалений backup;
* standby-сервер;
* план ручного відновлення;
* регулярні навчальні відновлення. # Створити тестову копію. !<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">


При впровадженні [[K2 ERP]] на власному сервері потрібно проєктувати не тільки модулі ERP, а всю інфраструктуру: сервер застосунку, СУБД, файлове сховище, API, Power BI, інтеграції, права доступу, audit log, backup, тестовий контур і аварійне відновлення. # Спроєктувати сервери. Перевага VPN — ERP не потрібно відкривати напряму в публічний інтернет. Він має фіксувати:
Не можна використовувати адміністратора для інтеграцій.== Моніторинг ==


[[Категорія:Інтеграція]]
<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">


Так, якщо така інфраструктурна модель відповідає вимогам компанії.[[Категорія:Firewall]]
== Що таке on-premise ERP ==


! Якщо ERP доступна через браузер або API, потрібно використовувати HTTPS.== Коли краще хмарна ERP ==
* обробку запитів користувачів;
* роботу web-інтерфейсу;
* проведення документів;
* бізнес-процеси;
* права доступу;
* API;
* фонові задачі;
* регламентні процеси;
* інтеграції;
* журналювання;
* перевірки даних. Потрібно резервувати:
Web-сервер потрібен для доступу через браузер. користувач системи


![[Категорія:ERP]]
Це небезпечно, бо в аварійний момент здатна виявитися, що:


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


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


== Висновок ==
[[Категорія:JSON]]


* HTTPS;
↓
* авторизацію;
== Масштабування ==
* токени;
</div>
* обмеження IP;
Потрібні:
* журнал запитів;
[[Категорія:Журналювання]]
* rate limit;
Зазвичай переносять:
* ідемпотентність;
! Він здатна бути потрібен для:
* external_id;
* контроль повторів;
* обробку помилок;
* моніторинг;
* окремий API-шлюз, якщо потрібно. '''Audit log''' або журнал аудиту потрібен для контролю дій у ERP. Це повноцінна відповідальність компанії за сервери, базу даних, мережу, backup, безпеку, моніторинг, оновлення версій, доступи, продуктивність, аварійне відновлення та інтеграції. інтеграційні функції ERP


* firewall;
Власний датацентр підходить для більших компаній. ERP на власному сервері зазвичай складається з таких компонентів:
* VPN;
== Архів старої BAS/1С ==
* HTTPS;
'''Найгірший сценарій.''' компанія-користувач переносить ERP на власний сервер, але не налаштовує резервні копії, HTTPS, VPN, моніторинг, ролі, API-захист і план відновлення. # Запустити production. Але така модель вимагає зрілої ІТ-дисципліни: серверного адміністрування, резервного копіювання, моніторингу, журналювання, оновлень, тестового середовища і плану аварійного відновлення. Зона
* регулярні оновлення версій ОС;
* оновлення версій СУБД;
* обмеження адміністративних доступів;
* окремі сервісні облікові записи;
* складні паролі;
* 2FA для критичних ролей;
* audit log;
* резервні копії;
* антивірус або EDR;
* моніторинг;
* журнал доступу;
* шифрування backup;
* контроль USB/локального доступу, якщо потрібно;
* навчання адміністраторів.[[Категорія:HTTPS]]


* DEV — розробка програмного забезпечення;
SLA здатна визначати:
* TEST — перевірка бізнес-користувачами;
* PROD — робоча платформа. # Оновити тестову систему. * філії;
* віддалені працівники;
* бухгалтери;
* керівники;
* складські підрозділи;
* сервісні інженери;
* інтеграційні сервери. Для чого потрібен
 
* вивантаження довідників;
* вивантаження документів;
* вивантаження регістрів;
* формування контрольних сум;
* підготовки даних;
* перевірки залишків;
* порівняння старої і нової системи;
* підготовки Power BI-аналітики;
* паралельного запуску;
* тестових імпортів у K2 ERP на власному сервері. Компонент
конкурентні переваги:
== Firewall ==


* сайт;
* CRM;
* WMS;
* банк;
* мобільний застосунок;
* BI;
* маркетплейс;
* електронний електронний документообіг;
* платформа доставки;
* внутрішній портал;
* виробниче обладнання. * клієнти;
* постачальники;
* договори;
* замовлення;
* склади;
* залишки;
* ціни;
* закупівельна діяльність;
* продажі та реалізація;
* виробництво;
* фінансовий блок;
* каса;
* банк;
* зарплата;
* кадри;
* собівартість;
* податкова інформаційні матеріали;
* управлінська аналітичні інструменти;
* документи;
* персональні інформаційні дані;
* інтеграційні ключі;
* API-токени;
* журнали дій. |-
| Чи можна розгорнути [[K2 ERP]] на власному сервері? Доступ
{| class="wikitable" style="width:100%;"
{| class="wikitable" style="width:100%;"
<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">
У ERP на власному сервері — це не без зусиль “поставити програму на сервер”. Кожен користувач системи має отримати тільки ті права, які потрібні для роботи. |-
| Що таке ERP на власному сервері? Хто контролює інфраструктуру


== Резервне копіювання ERP ==
Хмарна ERP здатна бути кращою, якщо:


== Тестовий сервер ERP ==
* втрата документів;
* втрата залишків;
* втрата фінансових даних;
* зупинка бізнесу;
* неможливість відновлення;
* втрати через людську помилку;
* втрати через технічну аварію;
* втрати через кібератаку. ERP на власному сервері потрібно моніторити. компанія-користувач отримує:


* [[K2 ERP]]
Адміністративні права мають бути обмежені й контрольовані. Роль
* [[K2 Cloud ERP]]
* [[Модулі K2 ERP]]
* [[ERP]]
* [[ERP система]]
* [[Хмарна ERP]]
* [[Гібридна ERP]]
* [[API]]
* [[Інтеграція через JSON]]
* [[Power BI]]
* [[BI система]]
* [[Права доступу в ERP]]
* [[Аудит дій]]
* [[Реплікатор K2]]
* [[Міграція з 1С]]
* [[Міграція з BAS]]
* [[Заміна BAS]]
* [[BAS]]
* [[BAF]]
* [[1С]]
* [[Інформаційна база BAS]]
* [[BAS ERP]]
* [[BAS Бухгалтерія]]
* [[BAS Управління торгівлею]]
* [[BAS Зарплата та Управління Персоналом]]
* [[Українське програмне забезпечення]]
* [[Цифрова незалежність]]


<div style="border:3px solid #ef6c00; background:#fff3e0; padding:14px; margin:16px 0;">
* копія пошкоджена;
* не вистачає файлів;
* не збережені сертифікати;
* не функціонує СУБД;
* не функціонує API;
* не функціонує BI;
* не збережені конфігурація. * процесор;
* оперативна пам’ять;
* диски;
* СУБД;
* мережа;
* кількість користувачів;
* кількість документів;
* складність звітів;
* API-навантаження;
* BI-запити;
* резервне копіювання;
* інтеграції;
* фонові задачі;
* індекси;
* архівні інформаційні дані. Критерій
|-
| SaaS
| У хмарі постачальника
| Постачальник
|-
| On-premise
| На серверах клієнта або в його датацентрі
| клієнт ERP або його ІТ-партнер
|-
| Гібридна
| Частково в хмарі, частково локально
| Спільна відповідальність
|}


* [https://erp.kyiv.ua Сайт K2 ERP]
!== Технічна підтримка K2 ERP ==
* [https://wiki.erp.kyiv.ua Wiki K2 ERP]
* [https://cloud.corp2.eu хмарна інфраструктура K2 ERP]


[[Категорія:On-premise ERP]]
== BI на власному сервері ==
== Стару 1С/BAS як архів ==
== Помилка: інтеграції не документовані ==
! ! | ERP, розгорнута на серверах компанії або її контрольованій інфраструктурі. Окремо варто відзначити коли програмне забезпечення (ПЗ), база даних, файли, інтеграції, резервні копії і серверна інфраструктура знаходяться на обладнанні компанії або в контрольованому дата-центрі компанії, а не на 100% в хмарі постачальника виступає ключовою рисою '''ERP на власному сервері''' або '''on-premise ERP'''. Недоліки:
Гібридна ERP-архітектура поєднує власний сервер і хмарні сервіси. * логін і пароль;
* доменна авторизація;
* SSO;
* двофакторна автентифікація;
* VPN-доступ;
* окремі API-токени;
* службові облікові записи.[[Категорія:Audit log]]


'''ERP на власному сервері''' — це сильна модель для компаній, яким потрібен контроль над даними, інфраструктурою, доступами, інтеграціями і політиками безпеки. API → HTTPS → Reverse proxy → Firewall → Авторизація → Журнал → ERP
Резервна копія має сенс тільки тоді, коли її можна відновити. '''ERP на власному сервері''' — це варіант впровадження, коли ERP-система встановлюється і функціонує на інфраструктурі, яку контролює сама компанія-користувач або її ІТ-підрядник. # Перевірити бізнес-сценарії.[[Категорія:Інтеграція]]


На власному сервері можуть працювати різні [[Модулі K2 ERP]]:
Приватна хмарна інфраструктура здатна бути компромісом між on-premise і SaaS. Коментар


* договори;
API на власному сервері дає можливість інтегрувати ERP з іншими системами. Модель
* рахунки;
* акти;
* накладні;
* скани;
* сертифікати;
* фото;
* креслення;
* технічну документацію;
* HR-документи;
* вкладення до заявок;
* архіви інтеграцій. Power BI здатна підключатися до ERP на власному сервері через:


ERP здатна бути технічно добре налаштована, але вразлива через слабку серверну кімнату. Потрібно правильно спроєктувати сервери, СУБД, backup, доступи, інтеграції, тестовий контур і моніторинг. як приклад:
! Потрібно знати:


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


[[Категорія:Українське програмне забезпечення]]
[[Категорія:CSV]]


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


Погана практика — зберігати базу, файли і backup на одному диску без резервування. ! # Перевірити ключові процеси. Не рекомендується відкривати ERP напряму в інтернет без захисту, firewall, HTTPS, журналювання і контролю доступу.<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">
* HTTPS;
* маршрутизацію запитів;
* web-інтерфейс;
* API;
* статичні файли;
* журнали доступу;
* обмеження IP;
* інтеграцію з корпоративною мережею;
* роботу через VPN або публічний домен. ↓


До СУБД потрібні особливі вимоги:
компанія-користувач отримує:
! Для ERP диски критично важливі. Типові симптоми проблем:


Для ERP на власному сервері потрібна документація. Частота
* web-інтерфейс;
Не рекомендується давати Power BI прямий неконтрольований доступ до робочої бази ERP, якщо це створює навантаження або ризик витоку. |-
* локальну мережу;
| Розміщення
* VPN;
| Сервери компанії або її дата-центр
* віддалений робочий стіл;
| Інфраструктура постачальника або cloud-провайдера
* корпоративний браузер;
|-
* мобільні сценарії;
| Контроль
* API-клієнти;
| Максимальний контроль компанії
* BI-панелі. * фізичний сервер в офісі;
| Частина контролю у провайдера
* сервер у власному датацентрі;
|-
* віртуальна машина;
| Адміністрування
* приватна хмарна інфраструктура;
| компанія-користувач або її підрядник
* орендований виділений сервер;
| Переважно провайдер
* корпоративний кластер;
|-
* інфраструктура в датацентрі під контролем компанії.== Сервісні користувачі ==
| Backup
компанія-користувач здатна мати резервні копії, але ніколи не перевіряти їх відновлення.</div>
| Налаштовує компанія-користувач
</syntaxhighlight>
| Часто входить у сервіс
== Типові помилки ==
|-
| оновлення версій
| За планом компанії
| За правилами сервісу або договору
|-
|-
| Початкові витрати
| api_site
| Вищі
| інтеграційні функції ERP із сайтом
| Нижчі
| Товари, ціни, залишки, замовлення
|-
|-
| Операційні витрати
| api_crm
| Сервери, ІТ, електрика, технічна підтримка
| інтеграційні функції ERP з CRM
| Підписка або оренда
| Клієнти, угоди, статуси
|-
|-
| Масштабування
| api_wms
| Потрібне планування обладнання
| інтеграційні функції ERP зі складом
| Зазвичай простіше
| Залишки, переміщення, відвантаження
|-
|-
| Відповідальність за безпеку
| bi_export
| Більше на компанії
| Передача даних у BI
| Частково на провайдері
| Читання аналітичних даних
|}
|}


! ERP на власному сервері здатна бути доречною; так само реалізовано агробізнесу, логістики, фінансово чутливих компаній, державного сектору, холдингів, підприємств із закритою мережею або організацій, які мають власну ІТ-команду. Питання
Потрібно визначити, хто і звідки має доступ.== Чек-лист перед запуском ERP на власному сервері ==


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


* компанія-користувач має власну ІТ-команду;
* перевірки оновлень;
* потрібен повний контроль над інфраструктурою;
* перевірки доробок;
* виступає як вимоги до локального зберігання даних;
* навчання користувачів;
* виступає як закрита корпоративна мережа;
* тестування інтеграцій;
* виступає як виробниче обладнання в локальній мережі;
* перевірки API;
* потрібна низька затримка між ERP і локальними системами;
* перевірки BI;
* виступає як інтеграції з локальними базами;
* тестової міграції;
* виступає як вимоги служби безпеки;
* відпрацювання аварійного відновлення.<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
* виступає як власний дата-центр;
* виступає як багато користувачів у локальній мережі;
* інтернет нестабільний або обмежений;
* компанія-користувач хоче сама контролювати оновлення версій. ERP на власному сервері — це власна будівля: більше контролю, але й більше відповідальності за все. конкурентні переваги:


На продуктивність впливають:
[[Категорія:Користувач BAS]]


Моніторинг потрібен, щоб не дізнаватися про проблему від користувачів. Причина
! | компанія-користувач або її ІТ-партнер відповідає за сервери, СУБД, бекапи, оновлення версій, моніторинг і аварійне відновлення. Це повноцінна технічна архітектура, яка передбачено сервер застосунків, СУБД, файлове сховище, резервне копіювання, моніторинг, оновлення версій, доступи, ролі, [[API]], [[BI]], інтеграції, журналювання, кібербезпеку, адміністрування і підтримку.</div>
Snapshot не замінює повноцінний backup ERP. # Задокументувати інфраструктуру. |-
| Головна перевага
| Максимальний контроль над даними, інфраструктурою і доступами. # Налаштувати HTTPS. ! Роль
== Розробницький контур ==
Це зменшує ризик зламати робочу ERP. * місце на диску менше 15%;
* backup не виконано;
* база недоступна;
* API повертає помилки;
* сертифікат HTTPS скоро закінчується;
* фонові задачі не виконуються. Тип backup


Backup: D:\Backup
API-шлюз здатна використовуватися для інтеграцій.[[Категорія:BI]]


Можливі рішення для бізнесу:
[[Категорія:Права доступу]]


ERP на власному сервері здатна бути доступною:
</div>


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


VPN застосовується для для безпечного доступу віддалених користувачів. # Налаштувати backup.== Недоліки ERP на власному сервері ==
== СУБД ==
{{SEO
|title=ERP на власному сервері — on-premise ERP, локальне розгортання, безпека, backup, адміністрування і K2 ERP
|description=ERP на власному сервері: що таке on-premise ERP, коли варто розгортати ERP локально, вимоги до серверів, мережі, СУБД, backup, безпека, права доступу, інтеграції, моніторинг, порівняння з хмарною ERP і впровадження K2 ERP на власній інфраструктурі.
|keywords=ERP на власному сервері, on-premise ERP, локальна ERP, ERP on-premise, власний сервер ERP, K2 ERP на сервері, ERP без хмари, ERP інфраструктура, ERP backup, ERP безпека, українська ERP
}}
Для складних ERP-проєктів здатна бути окреме середовище розробки. * '''RPO''' — скільки даних допустимо втратити;
* '''RTO''' — за який час потрібно відновити систему.== Типові помилки при ERP на власному сервері ==
Погана практика — видавати всім адміністративні права. Технологія


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


У плані має бути:
# Описати бізнес-вимоги. Відповідь


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


Для інтеграцій потрібно контролювати:
== Див. так само ==
Віддалений backup: інший майданчик або захищене сховище
== VPN для ERP ==
Приклад:
Приклад графіка:


ERP база: D:\ERP
[[Категорія:Локальна ERP]]


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


* документи;
API потрібно захищати окремо.== Мережа ==
* звіти;
== API-шлюз ==
* інтеграції;
== Помилка: не перевірити відновлення ==
* друковані форми;
|-
* права;
| Контроль інфраструктури
* API;
| Максимальний контроль у компанії
* фонові задачі;
| Більше відповідальності у постачальника
* Power BI-вивантаження. При переході з [[1С]] або [[BAS]] у K2 ERP на власному сервері потрібно планувати не тільки перенесення даних, а й нову інфраструктуру.== Див. так само ==
|-
| Старт
| Потрібне конфігурація серверів
| Зазвичай швидший
|-
| Адміністрування
| Потрібна ІТ-команда
| Частково або на 100% на постачальнику
|-
| Резервні копії
| Відповідальність компанії або ІТ-партнера
| Часто входять у сервіс
|-
| Безпека
| Залежить від внутрішньої ІТ-дисципліни
| Залежить від постачальника і договору
|-
| Інтеграції
| інтуїтивно для локальних систем
| інтуїтивно для web/API-сервісів
|-
| Масштабування
| Потрібно планувати ресурси
| Зазвичай простіше
|-
| Вартість
| Сервери, адміністрування, технічна підтримка
| Підписка або сервісна модель
|}


Backup, перевірене відновлення, безпека, права доступу, firewall, HTTPS, моніторинг, тестовий контур, документація і план аварійного відновлення. ! ERP здатна підтримувати різні способи входу:
== План аварійного відновлення ==
!== Диски і сховище ==


[[Категорія:Локальна ERP]]
! Обмеження


Для великих компаній сервер застосунку здатна бути не один. # Перевірити права.== SSL / HTTPS ==
API потрібно захищати:


=== Чим on-premise ERP відрізняється від хмарної ERP? ===
* локальна WMS;
* локальна CRM;
* банківський клієнт ERP;
* касове обладнання;
* ваги;
* обладнання складу;
* SCADA;
* виробничі системи;
* GPS;
* телефонія;
* файлові обміни;
* старі BAS/1С-бази;
* BI-сервер. Потрібно налаштувати:
'''[[K2 ERP]]''' у цьому процесі здатна стати платформою для контрольованого розміщення ERP на власному сервері, керування користувачами, ролями, [[API]], [[BI]]-аналітикою, інтеграціями, резервними копіями, web-доступом, оновленнями, моніторингом, журналюванням і подальшим розвитком автоматизації бізнесу без залежності від старої екосистеми [[BAS]] / [[1С]]. У результаті власний сервер стає не перевагою, а критичною точкою ризику. ! Окремі продукти [[1С]] і [[BAS]] внесені до переліків забороненого програмного забезпечення для окремих категорій організацій в Україні.[[Категорія:Версія K2 ERP]]
[[Категорія:SQL]]


'''[[K2 ERP]]''' здатна розгортатися як сучасна ERP-система з різними варіантами інфраструктури, зокрема на власних серверах компанії, якщо така модель відповідає вимогам бізнесу. ! доступ до ERP через браузер або API реалізується засобами Web-сервер. Потрібно контролювати:
</div>


[[Категорія:Резервне копіювання]]
[[Категорія:Міграція з 1С]]


* шлюз даних;
'''On-premise ERP''' — це міжнародна назва моделі, коли ERP розміщується “на майданчику” клієнта або в інфраструктурі, яку клієнт ERP контролює. * запуск ERP на слабкому сервері;
* API;
* відсутність резервних копій;
* проміжну аналітичну базу;
* резервні копії не перевіряються;
* регламентне вивантаження;
* ERP відкрита в інтернет без захисту;
* data warehouse;
* немає HTTPS;
* CSV/Excel-експорт, якщо немає кращого варіанту. # Провести навантажувальну перевірку.== API на власному сервері ==
* немає VPN;
* усі мають адміністративні права;
* API функціонує під admin;
* немає моніторингу;
* немає тестового середовища;
* немає плану відновлення;
* немає відповідального адміністратора;
* оновлення версій ставляться одразу в production;
* BI перевантажує основну базу;
* старі BAS/1С-інтеграції залишені активними. ↓
 
! |-
| У чому недолік? # Налаштувати користувачів і ролі. |-
| У чому перевага? # Перевірити BI.[[Категорія:On-premise ERP]]


== Помилка: backup лежить на тому самому сервері ==
Він здатна відповідати за:


# Зробити backup.<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">
* що робити при поломці сервера;
* що робити при пошкодженні бази;
* що робити при кібератаці;
* що робити при втраті інтернету;
* що робити при втраті електроживлення;
* хто відповідальний;
* де резервні копії;
* як відновити систему;
* як перевірити інформаційні дані;
* як повідомити користувачів;
* який допустимий час простою. ERP на власному сервері часто інтегрується з локальними системами.[[Категорія:Користувач K2 ERP]]
== BI на власному сервері ==
конкурентні переваги:
! Показник
[[Категорія:Кібербезпека]]
|-
| RPO
| Скільки даних можна втратити
| Не більше 1 години
|-
| RTO
| За скільки часу потрібно відновити систему
| Не більше 4 годин
|}


Краще будувати окремий BI-шар. Орієнтовно потрібно оцінити:
Якщо ERP відкрита без захисту, ризики зростають. {| class="wikitable" style="width:100%;"


{| class="wikitable" style="width:100%;"
[[Категорія:Українське програмне забезпечення]]


'''ERP на власному сервері дає контроль, але не прощає хаосу.''' Без backup, моніторингу, тестового контуру і плану відновлення власний сервер здатна стати не перевагою, а ризиком. Наслідок
* старий хаотичний код;
* неактуальні обробки;
* спільні логіни;
* зайві ролі;
* старі інтеграції під admin;
* дублікати довідників;
* тестові бази;
* помилкові залишки;
* небезпечні web-публікації;
* хаотичні файлові обміни;
* неактуальні архіви;
* санкційно ризикову залежність. ERP на власному сервері здатна бути доречною, якщо:
== 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.

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

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-показники;
  • архівні інформаційні дані за потреби. Потрібно проаналізувати:
  1. Описати бізнес-вимоги. Відповідь
  • сайт;
  • 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 на власному сервері і цифрова незалежність

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

== Приватна хмарна інфраструктура ==
Отримано з https://wiki.kyiv.ua/index.php?title=ERP_на_власному_сервері&oldid=2029