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

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

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

Зовнішні посилання

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

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

Вона має містити:

Інтеграції на власному сервері

Для власного сервера важливі:

Файлове сховище

Якщо диск або сервер вийде з ладу, компанія-користувач втратить і базу, і резервну копію. | Backup, тест відновлення, firewall, HTTPS, VPN, моніторинг, тестовий контур, документація.

</syntaxhighlight>

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

конкуренція за диски;
snapshot замість нормального backup;
перевантаження хоста;
відсутність моніторингу. * потрібна ІТ-команда;
вищі стартові витрати;
відповідальність за backup;
відповідальність за безпеку;
відповідальність за оновлення версій;
ризики простою;
потрібно обладнання;
потрібен моніторинг;
складніше масштабування;
ризик застарівання серверів;
потрібно планувати аварійне відновлення;
потрібно контролювати фізичну безпеку. Вона особливо доречна для виробництва, логістики, агробізнесу, великих складів, підприємств із локальним обладнанням, закритими мережами або власною ІТ-командою.

Для ERP, доступної з інтернету, HTTPS виступає як обов’язковим. Копія

Приклад:

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

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

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

Компанії обирають on-premise ERP, коли потрібні:

схему серверів;
IP-адреси;
доменні імена;
порти;
ролі серверів;
версії ПЗ;
СУБД;
backup-політику;
процедуру відновлення;
список інтеграцій;
список сервісних облікових записів;
список адміністраторів;
графік оновлень;
правила доступу;

аварійні контакти. оновлення версій має виконуватися контрольовано.

== Типові питання ==
Відкрити API ERP напряму в інтернет без обмежень. Критерій

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

Файлове сховище має бути:

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

<syntaxhighlight lang="text">

__TOC__

! * тільки з локальної мережі;
* через VPN;
* через корпоративний портал;
* через reverse proxy;
* через захищений web-доступ;
* через окремий API-шлюз;
* через віддалений робочий стіл, якщо так вирішено;
* з філій через site-to-site VPN.[[Категорія:Цифрова незалежність України]]

== Правило 3-2-1 для backup ==

DEV → TEST → PROD

'''ERP на власному сервері''' — це модель розгортання, за якої ERP-система встановлюється на сервери, що контролюються компанією. |-
| Кому підходить? |-
| Альтернатива
| Хмарна або гібридна ERP. Призначення
== Модулі K2 ERP на власному сервері ==
[[Категорія:Реплікатор K2]]
Практичне правило:
|-
| Щоденний
| Щодня вночі
| 14–30 днів
|-
| Тижневий
| Раз на тиждень
| 2–3 місяці
|-
| Місячний
| Раз на місяць
| 1–3 роки
|-
| Перед оновленням
| Перед кожним оновленням
| До підтвердження стабільної роботи
|-
| Перед міграцією
| Перед кожним великим імпортом
| До завершення звірки
|}

ERP на власному сервері — це модель розгортання, коли ERP-система, база даних, файли, інтеграції й backup розміщуються на серверах, які контролює компанія-користувач. |-
| Сервер застосунку
| Виконання бізнес-логіки ERP
| Application server
|-
| Сервер бази даних
| Зберігання даних
| PostgreSQL, MS SQL, інша СУБД
|-
| Файлове сховище
| Документи, вкладення, архіви
| Файловий сервер або object storage
|-
| Web-сервер
| Доступ користувачів через браузер
| Nginx, IIS, Apache
|-
| Сервер інтеграцій
| API, обміни, фонові задачі
| Integration service
|-
| Backup-сервер
| Резервні копії
| NAS, backup storage
|-
| Моніторинг
| Контроль стану системи
| Zabbix, Grafana, інші системи
|-
| VPN / Firewall
| Захист доступу
| VPN-шлюз, міжмережевий екран
|}

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

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

Хмарна ERP здатна бути кращою, якщо:

Потрібен реєстр інтеграцій. # Перевірити інтеграції.

критично, щоб модулі не жили як окремі “острови”, а використовували єдині довідники, права, audit log і контрольні звіти. Де:

Аутентифікація користувачів

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

Він здатна виконувати:

куди вони підключаються;
які токени використовують;
хто відповідальний;
що буде, якщо інтеграційні функції ERP впаде;
де журнали;
як повторити помилковий обмін;
які IP відкриті у firewall. | Компаніям із власною ІТ-командою, локальними інтеграціями і високими вимогами до контролю. Доступ

Проста аналогія. Хмарна ERP — це орендований офіс із готовою охороною, електрикою і прибиранням. # Зафіксувати версію і результат. |-

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

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

Приклад критичних сповіщень:

Для ERP на власному сервері потрібно мати план аварійного відновлення. * кількості користувачів;

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

| Що обов’язково?== Права доступу ==

Реєстр інтеграцій

Чи дешевше власний сервер за хмару?

Тестовий сервер не повинен надсилати реальні листи, платежі, API-запити або обміни з сайтом без контролю.== Моніторинг ERP ==

маршрутизацію запитів;
HTTPS;
reverse proxy;
балансування;
обмеження доступу;
журналювання;
захист API;
інтеграцію з сертифікатами;
публікацію зовнішніх endpoint-ів.

Коли власний сервер доречний

Відновлення після аварії

Погано:

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

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

Сервер бази даних — один із найважливіших компонентів ERP. Потрібно рахувати повну вартість. Де зберігається

Реплікатор K2 здатна допомогти при міграції з 1С/BAS у K2 ERP. # Налаштувати моніторинг. Погано:

Банк	ERP ↔ Банк	API / файл	фінансовий блок + ІТ	Висока
Сайт	Сайт → ERP	REST API	продажі та реалізація + ІТ	Висока
Power BI	ERP → BI	Data export	Аналітик	Середня
WMS	ERP ↔ складський облік	API	Логістика + ІТ	Висока

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

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

Ризики: </syntaxhighlight>

Немає перевіреного backup

Копії створюються, але не тестуються

Неможливо відновити ERP

ERP відкрита в інтернет напряму

Хотіли оперативно дати доступ

Ризик атаки і витоку даних

Немає тестового контуру

Економія ресурсів

оновлення версій ламає робочу систему

Усе на одному сервері

Просте розгортання

Один збій зупиняє всю ERP

Немає моніторингу

Проблеми бачать тільки користувачі

Збої помічають запізно

Backup на тому самому диску

Неправильна економія

При аварії втрачається і база, і backup

Немає документації

Усе знає один адміністратор

Ризик при звільненні або аварії

Для критичних ERP потрібно думати про відмовостійкість. Навантаження можна розділяти між кількома серверами. Рівень відмовостійкості залежить від того, скільки часу бізнес-середовище здатна працювати без ERP.== Чек-лист запуску ERP на власному сервері ==

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

Електроживлення і фізична безпека

</syntaxhighlight>

Типова схема:

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

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

[[Категорія:Моніторинг]]

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

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

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

* сервер застосунку;
* сервер бази даних;
* файлове сховище;
* 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 дозволені;
* які API доступні зовні;
* які інтеграції можуть підключатися;
* які сервіси доступні тільки всередині мережі. * сервери;
* диски;
* мережеве обладнання;
* ліцензії ОС;
* ліцензії СУБД, якщо потрібні;
* backup-сховище;
* UPS;
* електрику;
* охолодження;
* адміністраторів;
* моніторинг;
* оновлення версій;
* антивірус і безпеку;
* аварійне відновлення;
* підтримку;
* простої;
* заміну обладнання.== Документація ERP-інфраструктури ==

! # Визначити модулі ERP. # Налаштувати VPN або захищений доступ. Без HTTPS інформаційні дані можуть бути перехоплені в мережі.== конкурентні переваги ERP на власному сервері ==

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

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

TCO або повна вартість володіння містить:

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

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

== Мережа і доступ ==

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

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

Описати цілі розгортання.<syntaxhighlight lang="text">

Через кілька років ERP здатна мати десятки інтеграцій, але ніхто не знає:

Що це? * диск бази даних;

диск журналів СУБД;
диск файлів;
диск backup;
тимчасові файли;
архіви. {| class="wikitable" style="width:100%;"

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

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

HTTPS захищає:

Правильний порядок:

Що найважливіше при ERP на власному сервері?

* логіни;

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

Локальний backup: окремий backup-сервер

Власний сервер не завжди дешевший за хмару. # Запустити користувачів. Приклад

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

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

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

ERP на власному сервері доречна, якщо:

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

це варіант розгортання ERP-системи. * API-ключі;

firewall;
IP-адреси;
журнали;
черги;
повтори;
external_id;
помилки;
таймаути;
безпеку.

3 копії даних;
2 різні типи носіїв або сховищ;
1 копія поза основним майданчиком.

Кому підходить ERP на власному сервері?

Він здатна використовуватися для:

Backup — критична частина on-premise ERP.== Для чого обирають ERP на власному сервері ==

Менеджер продажів Клієнти, угоди, замовлення, свої звіти Комірник Складські операції, залишки, інвентаризація Фінансист Платежі, бюджети, ДДС, платіжний календар Бухгалтер Первинні документи, податки, проводки HR Кадрові інформаційні дані, відпустки, табелі Зарплатний бухгалтер Нарахування, утримання, податки, виплати Адміністратор Технічне адміністрування

Потрібно контролювати:

Краще:

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

Правила:

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

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

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

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

довго відкриваються документи;
повільно формуються звіти;
зависає проведення;
падають фонові задачі;
API відповідає повільно;
користувачі скаржаться на затримки;
backup триває занадто довго. ! Він потрібен для:

RAID;
резервне живлення;
другий сервер;
репліка бази;
кластер;
резервний інтернет;
віддалений backup;
standby-сервер;
план ручного відновлення;
регулярні навчальні відновлення. # Створити тестову копію. !

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

Так, якщо така інфраструктурна модель відповідає вимогам компанії.

! Якщо ERP доступна через браузер або API, потрібно використовувати HTTPS.== Коли краще хмарна ERP ==

!

Firewall має обмежувати доступ до ERP. Компаніям із власною ІТ-командою, високими вимогами до контролю даних, локальними інтеграціями, виробництвом, складом, закритою мережею або вимогами до локального розміщення. # контролювати перші тижні роботи.

швидкі диски;
достатньо оперативної пам’яті;
стабільне резервне копіювання;
моніторинг;
обмеження доступу;
регулярне обслуговування;
контроль розміру бази;
план аварійного відновлення.== Що таке ERP на власному сервері ==

Висновок

HTTPS;
авторизацію;
токени;
обмеження IP;
журнал запитів;
rate limit;
ідемпотентність;
external_id;
контроль повторів;
обробку помилок;
моніторинг;
окремий API-шлюз, якщо потрібно. Audit log або журнал аудиту потрібен для контролю дій у ERP. Це повноцінна відповідальність компанії за сервери, базу даних, мережу, backup, безпеку, моніторинг, оновлення версій, доступи, продуктивність, аварійне відновлення та інтеграції. інтеграційні функції ERP

firewall;
VPN;
HTTPS;
регулярні оновлення версій ОС;
оновлення версій СУБД;
обмеження адміністративних доступів;
окремі сервісні облікові записи;
складні паролі;
2FA для критичних ролей;
audit log;
резервні копії;
антивірус або EDR;
моніторинг;
журнал доступу;
шифрування backup;
контроль USB/локального доступу, якщо потрібно;
навчання адміністраторів.

DEV — розробка програмного забезпечення;
TEST — перевірка бізнес-користувачами;
PROD — робоча платформа. # Оновити тестову систему. * філії;
віддалені працівники;
бухгалтери;
керівники;
складські підрозділи;
сервісні інженери;
інтеграційні сервери. Для чого потрібен

вивантаження довідників;
вивантаження документів;
вивантаження регістрів;
формування контрольних сум;
підготовки даних;
перевірки залишків;
порівняння старої і нової системи;
підготовки Power BI-аналітики;
паралельного запуску;
тестових імпортів у K2 ERP на власному сервері. Компонент

конкурентні переваги:

Firewall

Резервне копіювання ERP

Тестовий сервер ERP

Стару 1С/BAS як архів

Помилка: інтеграції не документовані

ERP, розгорнута на серверах компанії або її контрольованій інфраструктурі. Окремо варто відзначити коли програмне забезпечення (ПЗ), база даних, файли, інтеграції, резервні копії і серверна інфраструктура знаходяться на обладнанні компанії або в контрольованому дата-центрі компанії, а не на 100% в хмарі постачальника виступає ключовою рисою ERP на власному сервері або on-premise ERP. Недоліки: Гібридна ERP-архітектура поєднує власний сервер і хмарні сервіси. * логін і пароль; доменна авторизація; SSO; двофакторна автентифікація; VPN-доступ; окремі API-токени; службові облікові записи. ERP на власному сервері — це сильна модель для компаній, яким потрібен контроль над даними, інфраструктурою, доступами, інтеграціями і політиками безпеки. API → HTTPS → Reverse proxy → Firewall → Авторизація → Журнал → ERP На власному сервері можуть працювати різні Модулі K2 ERP: договори; рахунки; акти; накладні; скани; сертифікати; фото; креслення; технічну документацію; HR-документи; вкладення до заявок; архіви інтеграцій. Power BI здатна підключатися до ERP на власному сервері через: ERP здатна бути технічно добре налаштована, але вразлива через слабку серверну кімнату. Потрібно правильно спроєктувати сервери, СУБД, backup, доступи, інтеграції, тестовий контур і моніторинг. як приклад: Точні вимоги залежать від: фізичні сервери в офісі; сервери у власній серверній кімнаті; сервери в корпоративному дата-центрі; орендовані виділені сервери; приватна хмарна інфраструктура компанії; гібридна інфраструктура; локальна мережа підприємства; ізольований контур без публічного доступу з інтернету. Хмарна ERP Погана практика — зберігати базу, файли і backup на одному диску без резервування. ! # Перевірити ключові процеси. Не рекомендується відкривати ERP напряму в інтернет без захисту, firewall, HTTPS, журналювання і контролю доступу. До СУБД потрібні особливі вимоги:	Для ERP диски критично важливі. Типові симптоми проблем: Для ERP на власному сервері потрібна документація. Частота Не рекомендується давати Power BI прямий неконтрольований доступ до робочої бази ERP, якщо це створює навантаження або ризик витоку. \|-	Розміщення	Сервери компанії або її дата-центр	Інфраструктура постачальника або cloud-провайдера
Контроль	Максимальний контроль компанії	Частина контролю у провайдера
Адміністрування	компанія-користувач або її підрядник	Переважно провайдер
Backup	Налаштовує компанія-користувач	Часто входить у сервіс
оновлення версій	За планом компанії	За правилами сервісу або договору
Початкові витрати	Вищі	Нижчі
Операційні витрати	Сервери, ІТ, електрика, технічна підтримка	Підписка або оренда
Масштабування	Потрібне планування обладнання	Зазвичай простіше
Відповідальність за безпеку	Більше на компанії	Частково на провайдері

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

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

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

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

Моніторинг потрібен, щоб не дізнаватися про проблему від користувачів. Причина Snapshot не замінює повноцінний backup ERP. # Задокументувати інфраструктуру. |- | Головна перевага | Максимальний контроль над даними, інфраструктурою і доступами. # Налаштувати HTTPS. ! Роль

Розробницький контур

Це зменшує ризик зламати робочу ERP. * місце на диску менше 15%;

backup не виконано;
база недоступна;
API повертає помилки;
сертифікат HTTPS скоро закінчується;
фонові задачі не виконуються. Тип backup

Backup: D:\Backup

Можливі рішення для бізнесу:

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

Через VPN можуть працювати:

VPN застосовується для для безпечного доступу віддалених користувачів. # Налаштувати backup.== Недоліки ERP на власному сервері == SEO title: ERP на власному сервері — on-premise ERP, локальне розгортання, безпека, backup, адміністрування і K2 ERP

SEO keywords: ERP на власному сервері, on-premise ERP, локальна ERP, ERP on-premise, власний сервер ERP, K2 ERP на сервері, ERP без хмари, ERP інфраструктура, ERP backup, ERP безпека, українська ERP

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

}}

Для складних ERP-проєктів здатна бути окреме середовище розробки. * RPO — скільки даних допустимо втратити;

RTO — за який час потрібно відновити систему.== Типові помилки при ERP на власному сервері ==

Погана практика — видавати всім адміністративні права. Технологія

Сервер застосунку

У плані має бути:

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

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

VPN для ERP

Приклад: Приклад графіка:

ERP база: D:\ERP

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

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

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

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

Чим on-premise ERP відрізняється від хмарної ERP?

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

шлюз даних;
API;
проміжну аналітичну базу;
регламентне вивантаження;
data warehouse;
CSV/Excel-експорт, якщо немає кращого варіанту. # Провести навантажувальну перевірку.== API на власному сервері ==

Помилка: backup лежить на тому самому сервері

Зробити backup.

Краще будувати окремий BI-шар. Орієнтовно потрібно оцінити:

ERP на власному сервері дає контроль, але не прощає хаосу. Без backup, моніторингу, тестового контуру і плану відновлення власний сервер здатна стати не перевагою, а ризиком. Наслідок