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

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

Матеріал з K2 ERP Wiki
Створена сторінка: {{DISPLAYTITLE:ERP на власному сервері}} {{SEO |title=ERP на власному сервері — on-premise ERP, локальне розгортання, безпека, backup, адміністрування і K2 ERP |description=ERP на власному сервері: що таке on-premise ERP, коли варто розгортати ERP локально, вимоги до серверів, мережі, СУБД, backup, бе...
 
Немає опису редагування
 
Рядок 1: Рядок 1:
{| class="wikitable" style="width:100%;"
ERP на власному сервері має мати план аварійного відновлення.; це модель розміщення [[ERP]]-системи.; Обмеження
== Помилка: не перевірити відновлення ==
Погані підходи:
!;[[Категорія:Роль BAS]]


[[Категорія:On-premise ERP]]
* копія пошкоджена;
* не вистачає файлів;
* не збережені сертифікати;
* не функціонує СУБД;
* не функціонує API;
* не функціонує BI;
* не збережені конфігурація.; __TOC__


[[Категорія:Цифрова незалежність України]]
Адміністративні права мають бути обмежені й контрольовані.; переважні аспекти


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


== Коли власний сервер доречний ==
Користувачі → Корпоративна мережа / VPN / Web → Сервер ERP → СУБД → інформаційні дані компанії
== Основні компоненти ERP на власному сервері ==
== Мережа і доступ ==


Для складних ERP-проєктів має змогу бути окреме середовище розробки.; '''Практичний сенс.''' Якщо організація має виробництво, складський облік із ТСД, локальні ваги, внутрішню мережу, власний домен, закриті інтеграції й ІТ-команду, ERP на власному сервері має змогу бути логічним вибором.; ERP на власному сервері має змогу інтегруватися з:
{| class="wikitable" style="width:100%;"
== Типові питання ==


Приклад:
API на власному сервері дає можливість інтегрувати ERP з іншими системами.; Спрощена схема:
Воно потрібне для:
Якщо ERP доступна через web, потрібно використовувати HTTPS.;== Відповідальність при ERP на власному сервері ==
Web-сервер / API-шлюз
Приклад архітектури:
|-
| app-k2-01
| Сервер застосунків K2 ERP
| Web, бізнес-логіка, API
|-
| db-k2-01
| Сервер СУБД
| Основна база даних
|-
| bi-k2-01
| BI-сервер
| аналітичні інструменти і дашборди
|-
| backup-k2-01
| Резервні копії
| Локальні й віддалені копії
|-
| test-k2-01
| Тестове середовище
| актуалізація і навчання
|}


== Гібридний варіант ==
{| class="wikitable" style="width:100%;"


* 3 копії даних;
Потрібно знати:
* 2 різні типи носіїв або сховищ;
Приклад:
* 1 копія поза основним майданчиком.; # Запустити користувачів.; | Компаніям із власною ІТ-командою, локальними інтеграціями і високими вимогами до контролю.; # Налаштувати backup.; |-
Сервер застосунків виконує бізнес-логіку ERP.;== Продуктивність ==
| Що обов’язково?; # Налаштувати права.;[[Категорія:ERP на власному сервері]]
Безпека має включати:
[[Категорія:Хмарна ERP]]
[[Категорія:Web-сервіси 1С]]
Він має змогу бути потрібен для:
== актуалізація ERP на власному сервері ==
!; |-
| У чому перевага?; Зона
Якщо ERP розміщується не в офісі, а в датацентрі, потрібно перевірити:
Після запуску [[K2 ERP]] стара BAS/1С не повинна залишатися робочою системою.;<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">


* CPU;
* аудиту;
* RAM;
* безпеки;
* SSD/NVMe;
* розслідування помилок;
* місце для бази;
* контролю користувачів;
* місце для файлів;
* контролю API;
* місце для backup;
* контролю адміністраторів;
* мережеву пропускну здатність;
* контролю інтеграцій;
* резервне живлення;
* аналізу продуктивності;
* масштабування;
* виявлення підозрілих дій.; |-
* моніторинг.; # Зафіксувати версію і результат.; # Оновити робочу систему.; # Перевірити звіти.;== Моніторинг ERP ==
| Сервери підготовлені
| Стабільна робота ERP
|-
| СУБД налаштована
| Зберігання даних і продуктивність
|-
| HTTPS увімкнено
| Захист web-доступу
|-
| VPN налаштовано
| Захист віддаленого доступу
|-
| Резервні копії працюють
| Відновлення після аварії
|-
| Відновлення перевірено
| Бекап має бути придатним
|-
| Користувачі створені
| Персональна робота
|-
| Ролі налаштовані
| Мінімально необхідний доступ
|-
| API захищено
| Безпечні інтеграції
|-
| BI перевірено
| Коректна аналітичні інструменти
|-
| Моніторинг функціонує
| Раннє виявлення проблем
|}


Не можна оновлювати робочу ERP без тесту й backup.;== Коли краще хмарна ERP ==
API потрібно захищати окремо.; # Оновити production.;[[Категорія:K2]]


* договори;
* процесор;
* рахунки;
* оперативна пам’ять;
* акти;
* диски;
* накладні;
* СУБД;
* скани;
* мережа;
* сертифікати;
* кількість користувачів;
* фото;
* кількість документів;
* креслення;
* складність звітів;
* технічну документацію;
* API-навантаження;
* HR-документи;
* BI-запити;
* вкладення до заявок;
* резервне копіювання;
* архіви інтеграцій.; * немає власної ІТ-команди;
* інтеграції;
* потрібно оперативно стартувати;
* фонові задачі;
* організація не хоче купувати сервери;
* індекси;
* користувачі працюють віддалено;
* архівні інформаційні дані.; Варіант
* потрібне просте масштабування;
* немає складних локальних інтеграцій;
* істотно зменшити стартові витрати;
* backup і адміністрування краще передати провайдеру;
* бізнес-середовище не хоче утримувати серверну інфраструктуру.; актуалізація має виконуватися контрольовано.; Моніторинг потрібен, щоб не дізнаватися про проблему від користувачів.; |-
| Кому підходить?; !; ERP база: ключовий сервер
При впровадженні [[K2 ERP]] на власному сервері потрібно проєктувати не тільки модулі ERP, а всю інфраструктуру: сервер застосунку, СУБД, файлове сховище, API, Power BI, інтеграції, права доступу, audit log, backup, тестовий контур і аварійне відновлення.; !; Навантаження можна розділяти між кількома серверами.; Не завжди.; Зберігання


</div>
* [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]


Для K2 ERP на власному сервері істотно спроєктувати:
У on-premise моделі відповідальність потрібно чітко розділити.; організація має змогу обрати:


== Розробницький контур ==
* входи;
* помилки входу;
* зміну документів;
* зміну довідників;
* експорт;
* API-запити;
* зміну ролей;
* адміністративні дії;
* помилки системи;
* помилки інтеграцій.; Резервні копії — одна з найважливіших частин on-premise ERP.;[[Категорія:Заміна 1С]]
[[Категорія:On-premise]]
організація має змогу мати резервні копії, але ніколи не перевіряти їх відновлення.; # Визначити API та BI.; Це небезпечно, бо в аварійний момент має змогу виявитися, що:


Погано:
== Вступ ==


Рівень відмовостійкості залежить від того, скільки часу бізнес-середовище має змогу працювати без ERP.; Ключові показники:
На продуктивність ERP на власному сервері впливають:


Це можуть бути:
Якщо ERP відкрита без захисту, ризики зростають.;== Типова технічна архітектура K2 ERP на власному сервері ==


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


!; # Спроєктувати СУБД.; Технологія
== Приватна хмарна інфраструктура ==
[[Категорія:Міграція даних]]
== Інтеграції на власному сервері ==
!; Частота


При переході з [[]] або [[BAS]] у K2 ERP на власному сервері потрібно планувати не тільки перенесення даних, а й нову інфраструктуру.; Для ERP на власному сервері потрібна документація.; Тип backup
BI має змогу працювати на окремому сервері або разом із ERP.; |-
| Чи є собою санкційні ризики у [[BAS]] і [[]]?; Порядок:


[[Категорія:K2 ERP]]
<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">


Вона має містити:
Така модель протилежна SaaS, де ERP функціонує як хмарний сервіс постачальника.; * чи створюється бекап;
* чи немає помилок;
* чи можна відновити базу;
* чи відкривається ERP після відновлення;
* чи працюють користувачі;
* чи працюють API;
* чи працюють BI;
* чи збережені файли;
* чи працюють інтеграції;
* скільки часу займає відновлення.; Хмарна ERP має змогу бути кращою, якщо:


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


Якщо ERP доступна через браузер або API, потрібно використовувати HTTPS.; це варіант розгортання ERP-системи.; Він потрібен для:
{| class="wikitable" style="width:100%;"


== Зовнішні посилання ==
* довідники;
* документи;
* регістри;
* залишки;
* рухи;
* користувачі;
* ролі;
* журнали;
* конфігурація;
* історичний розвиток;
* API-дані;
* BI-дані;
* службові таблиці.;== Технічний супровід ==
== Датацентр ==
== Web-сервер ==
Сервісні користувачі потрібні для інтеграцій.;== Безпека ERP на власному сервері ==


Якщо диск або сервер вийде з ладу, організація втратить і базу, і резервну копію.;[[Категорія:Права доступу]]
Під час переходу з [[BAS]] або [[1С]] на [[K2 ERP]] на власному сервері потрібно не тільки перенести довідники, документи й залишки, а й переосмислити всю інфраструктуру: користувачів, ролі, API, BI, резервні копії, web-доступ, інтеграції, архіви, моніторинг і безпеку.; |-
!; Firewall має обмежувати доступ до ERP.;<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
| Що обов’язково потрібно?;== Адміністратори ==


* ERP функціонує на власному сервері;
<syntaxhighlight lang="text">
* Power BI функціонує в хмарі;
* backup дублюється в захищене хмарне сховище;
* сайт функціонує в хмарі;
* API-шлюз розміщений у DMZ;
* частина користувачів функціонує через VPN;
* мобільний застосунок підключається через захищений reverse proxy;
* архівні копії зберігаються поза основним майданчиком.;== Audit log ==
 
Тестовий сервер не повинен надсилати реальні листи, платежі, API-запити або обміни з сайтом без контролю.;== Сервер бази даних ==
Він зберігає:
== Коротко ==
|-
| Розміщення
| Сервери компанії або її дата-центр
| Інфраструктура постачальника або cloud-провайдера
|-
| Контроль
| Максимальний контроль компанії
| Частина контролю у провайдера
|-
| Адміністрування
| організація або її підрядник
| Переважно провайдер
|-
| Backup
| Налаштовує організація
| Часто входить у сервіс
|-
| актуалізація
| За планом компанії
| За правилами сервісу або договору
|-
| Початкові витрати
| Вищі
| Нижчі
|-
| Операційні витрати
| Сервери, ІТ, електрика, супровід
| Підписка або оренда
|-
| Масштабування
| Потрібне планування обладнання
| Зазвичай простіше
|-
| Відповідальність за безпеку
| Більше на компанії
| Частково на провайдері
|}


<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">
== Архів старої BAS/1С ==


!;== Помилка: backup лежить на з цієї причини самому сервері ==
* тільки для перегляду;
* без введення нових документів;
* без активних інтеграцій;
* без доступу звільнених користувачів;
* із резервною копією;
* з обмеженим доступом;
* із журналом використання;
* із чіткою назвою “Архів”.;[[Категорія:JSON 1С]]


== Чек-лист запуску ERP на власному сервері ==
!; !; # Налаштувати моніторинг.; |-
| Чи можна розгорнути [[K2 ERP]] на власному сервері?; Хмарна ERP
== Що не переносити ==
[[Категорія:Заміна BAS]]
== Масштабування ==
== СУБД ==
Під час переходу з [[BAS]] або [[1С]] на [[K2 ERP]] на власному сервері потрібно врахувати не тільки інформаційні дані, а й інфраструктуру.; * логінів;
* паролів;
* документів;
* персональних даних;
* фінансових даних;
* API-запитів;
* BI-звітів;
* токенів.; BI має змогу бути розміщений:


== Power BI і ERP на власному сервері ==
ERP на власному сервері має підтримувати чітку модель користувачів.;== SLA ==


Для ERP на власному сервері audit log особливо важливий, бо організація сама контролює інфраструктуру і має мати докази подій.; {| class="wikitable" style="width:100%;"
!;== Правило 3-2-1 ==


== переважні аспекти ERP на власному сервері ==
</div>


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


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


* API-ключі;
[[Категорія:CSV]]
* firewall;
* IP-адреси;
* журнали;
* черги;
* повтори;
* external_id;
* помилки;
* таймаути;
* безпеку.; TCO або повна вартість володіння охоплює:
== API на власному сервері ==


</syntaxhighlight>
Файлове сховище потрібно резервувати і захищати так само уважно, як базу даних.; організація отримує:
{| class="wikitable" style="width:100%;"
{| class="wikitable" style="width:100%;"
Журналювання потрібне для:
ERP має змогу працювати на фізичному сервері або віртуальній машині.; {| class="wikitable" style="width:100%;"


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


Погана практика — видавати всім адміністративні права.; * куди вони підключаються;
'''[[K2 ERP]]''' у цьому процесі має змогу стати платформою для контрольованого розміщення ERP на власному сервері, керування користувачами, ролями, [[API]], [[BI]]-аналітикою, інтеграціями, резервними копіями, web-доступом, оновленнями, моніторингом, журналюванням і подальшим розвитком автоматизації бізнесу без залежності від старої екосистеми [[BAS]] / [[]].;== BI на власному сервері ==
* які токени використовують;
* хто відповідальний;
* що буде, якщо інтеграційні функціональні можливості впаде;
* де журнали;
* як повторити помилковий обмін;
* які IP відкриті у firewall.; # Спроєктувати сервери.; # Оновити тестову систему.; !;[[Категорія:Відновлення після аварії]]


* кількості користувачів;
* версію [[K2 ERP]];
* модулів;
* версію модулів;
* обсягу даних;
* версію API;
* інтенсивності інтеграцій;
* версію BI;
* BI-навантаження;
* версію СУБД;
* кількості документів;
* версію міграційних пакетів;
* файлів;
* дату актуалізація;
* звітів;
* список змін;
* потрібної відмовостійкості.; Критерій
* відповідального за актуалізація.; # Перевірити BI.; # Провести тестову міграцію.; # Налаштувати VPN або мережеві обмеження.;[[Категорія:Безпека]]
Сервер бази даних не повинен бути доступний напряму з інтернету.;[[Категорія:VPN]]
Для критичних систем потрібен SLA.; Призначення
!; * сайт;
* CRM;
* WMS;
* мобільний застосунок;
* BI;
* банк;
* електронний електронний документообіг;
* сервіс доставки;
* маркетплейс;
* зовнішній партнерська сторона;
* внутрішня платформа компанії.; !;[[Категорія:Оновлення K2 ERP]]
|-
| Фізичний сервер
| Контроль ресурсів, висока продуктивність
| Складніше масштабування і відновлення
|-
| Віртуальна машина
| Гнучкість, знімки, простіше перенесення
| Потрібна якісна віртуалізація
|}


!; ERP на власному сервері доречна, якщо:
</div>


== Файлове сховище ==
ERP на власному сервері зазвичай складається з таких компонентів:
Правила:
Точні вимоги залежать від:
!; # Описати цілі розгортання.; Роль


__TOC__
* електроживлення;
* резервне живлення;
* інтернет-канали;
* фізичну безпеку;
* доступ до серверів;
* резервне копіювання;
* пожежну безпеку;
* SLA датацентру;
* мережеву ізоляцію;
* відповідальність сторін.; | On-premise ERP, локальна ERP, ERP у власній інфраструктурі.;</div>


Компанії обирають on-premise ERP, коли потрібні:
'''Цифрова незалежність.''' [[K2 ERP]] на власному сервері має змогу дати компанії контроль над критичною ERP-інфраструктурою: даними, доступами, інтеграціями, API, BI, резервними копіями, оновленнями і безпекою.; Він має змогу відповідати за:


* повний контроль над даними;
VPN сприяє не відкривати ERP напряму в інтернет.; Хто контролює інфраструктуру
* розміщення даних у власній інфраструктурі;
</div>
* робота в закритій мережі;
У ній можуть зберігатися:
* внутрішні вимоги безпеки;
* інтеграції з локальним обладнанням;
* підключення до виробничих систем;
* інтеграції з вагами, ТСД, сканерами, станками, GPS, WMS, MES;
* контроль доступу через корпоративну мережу;
* власна політика backup;
* власна політика оновлень;
* відповідність внутрішнім ІТ-стандартам;
* незалежність від зовнішньої хмари;
* контроль продуктивності;
* робота в умовах нестабільного інтернету.; * [https://erp.kyiv.ua Сайт K2 ERP]
* [https://wiki.erp.kyiv.ua Wiki K2 ERP]
* [https://cloud.corp2.eu хмарна інфраструктура K2 ERP]
 
'''ERP на власному сервері''' — це модель розгортання, за якої ERP-система встановлюється на сервери, що контролюються компанією.; ERP на власному сервері — це власна будівля: більше контролю, але й більше відповідальності за все.; |-
| Альтернатива
| Хмарна або гібридна ERP.; # Контролювати перші тижні роботи.; Для ERP, доступної з інтернету, HTTPS є собою обов’язковим.; # Налаштувати HTTPS.; Питання
 
* роботу користувачів;
* обробку документів;
* бізнес-процеси;
* workflow;
* API;
* фонові задачі;
* друковані форми;
* інтеграції;
* обробку файлів;
* авторизацію;
* логування.; Потрібно правильно спроєктувати сервери, СУБД, backup, доступи, інтеграції, тестовий контур і моніторинг.; |-
| Сервер застосунку
| Виконання бізнес-логіки ERP
| Application server
|-
|-
| Сервер бази даних
| Основна
| Зберігання даних
| Робочий сервер
| PostgreSQL, MS SQL, інша СУБД
| Поточна робота
|-
|-
| Файлове сховище
| Локальний бекап
| Документи, вкладення, архіви
| Резервний сервер
| Файловий сервер або object storage
| Швидке відновлення
|-
|-
| Web-сервер
| Віддалений бекап
| Доступ користувачів через браузер
| Інший майданчик або захищене сховище
| Nginx, IIS, Apache
| Захист від аварії на основному майданчику
|}
 
'''Правильний підхід.''' ERP на власному сервері потрібно впроваджувати як інфраструктурний проєкт: із серверною архітектурою, СУБД, резервними копіями, тестовою базою, HTTPS, VPN, ролями, API, BI, моніторингом, журналюванням і планом аварійного відновлення.;== Принцип мінімального доступу ==
 
ERP на власному сервері — це потужна модель розміщення, яка дає компанії контроль над ERP-інфраструктурою, даними, СУБД, API, BI, інтеграціями, доступами, резервними копіями й безпекою.; # Підготувати web-доступ.; Доступ
|-
|-
| Сервер інтеграцій
| api_site
| API, обміни, фонові задачі
| інтеграційні функціональні можливості із сайтом
| Integration service
| Товари, ціни, залишки, замовлення
|-
|-
| Backup-сервер
| api_crm
| Резервні копії
| інтеграційні функціональні можливості з CRM
| NAS, backup storage
| Клієнти, угоди, статуси
|-
|-
| Моніторинг
| api_wms
| Контроль стану системи
| інтеграційні функціональні можливості зі складом
| Zabbix, Grafana, інші системи
| Залишки, переміщення, відвантаження
|-
|-
| VPN / Firewall
| bi_export
| Захист доступу
| Передача даних у BI
| VPN-шлюз, міжмережевий екран
| Читання аналітичних даних
|}
|}


Практичне правило:
Сервер в офісі має змогу бути простішим, але має ризики:


Ризики:
[[Категорія:ERP на власному сервері]]


!; |-
Для ERP на власному сервері важлива якісна мережа.; Де зберігається
| Головна перевага
|-
| Максимальний контроль над даними, інфраструктурою і доступами.;</div>
| Менеджер
Потрібно спочатку перевіряти актуалізація на тестовому контурі.;</syntaxhighlight>
| Клієнти, замовлення, рахунки
 
| Немає доступу до зарплати й адміністрування
* UPS;
* стабільне живлення;
* охолодження;
* фізичний доступ;
* пожежна безпека;
* контроль вологості;
* замки;
* відеоспостереження;
* обліковий облік доступу;
* резервний майданчик.; Де зберігається
!; |-
| Менеджер продажів
| Клієнти, угоди, замовлення, свої звіти
|-
|-
| Комірник
| Комірник
| Складські операції, залишки, інвентаризація
| Складські документи, інвентаризація
|-
| Немає доступу до банку й собівартості
| Фінансист
| Платежі, бюджети, ДДС, платіжний календар
|-
|-
| Бухгалтер
| Бухгалтер
| Первинні документи, податки, проводки
| Каса, банк, проводки, формування звітів
| Без технічного адміністрування
|-
|-
| HR
| Керівник
| Кадрові інформаційні дані, відпустки, табелі
| Звіти, BI, KPI
| Без зміни первинних документів
|-
|-
| Зарплатний бухгалтер
| API-користувач
| Нарахування, утримання, податки, виплати
| Конкретні API-методи
|-
| Без доступу до зайвих модулів
| Адміністратор
| Технічне адміністрування
|}
|}


Погано:
ERP без резервного копіювання — критичний ризик.; Окремо варто відзначити за якої програмне забезпечення, база даних, файли, інтеграції, резервні копії і технічна інфраструктура працюють на серверах компанії або в контрольованому датацентрі, а не в цілому в хмарному сервісі постачальника виступає ключовою рисою '''ERP на власному сервері'''.;== Помилка: сервер без резервного копіювання ==


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


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


{{DISPLAYTITLE:ERP на власному сервері}}
* час реакції;
* час вирішення;
* критичність інцидентів;
* графік підтримки;
* відповідальних;
* канали звернення;
* ескалацію;
* підтримку production;
* підтримку тестового середовища;
* підтримку інтеграцій;
* підтримку API.;[[K2 ERP]] на власному сервері має змогу бути доречною для компаній, які хочуть контролювати свою інфраструктуру, мають внутрішню ІТ-команду, потребують локальних інтеграцій, хочуть ізолювати критичні інформаційні дані або будують власну українську ERP-архітектуру.; !; * токенами;
* HTTPS;
* обмеженням IP;
* ролями;
* журналюванням;
* лімітами;
* окремими сервісними користувачами.; # Підготувати СУБД.; Зазвичай переносять:


* входи користувачів;
API-шлюз має змогу використовуватися для інтеграцій.; Вони можуть керувати:
* створення документів;
 
* зміну документів;
!; # Налаштувати інтеграції.; організація отримує:
* видалення;
* погодження;
* зміну прав;
* зміну фінансових реквізитів;
* експорт даних;
* зміну зарплати;
* API-запити;
* помилки;
* запуск інтеграцій;
* зміну налаштувань.; Власний сервер не завжди дешевший за хмару.; Хмарна ERP
</div>
Для on-premise ERP бажано мати окремий тестовий контур.; | ERP, розгорнута на серверах компанії або її контрольованій інфраструктурі.; У такій моделі організація сама або через підрядника відповідає за інфраструктуру.; | Backup, тест відновлення, firewall, HTTPS, VPN, моніторинг, тестовий контур, документація.; * тільки для читання;
* інтеграції вимкнені;
* регламентні задача вимкнені;
* доступ обмежений;
* backup збережений;
* дата переходу зафіксована;
* контрольні звіти сформовані;
* архів не застосовують, коли потрібно для нових операцій.; Без HTTPS інформаційні дані можуть бути перехоплені в мережі.;== Резервне копіювання ERP ==


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


У плані має бути:
* контроль інфраструктури;
* резервування;
* краща фізична безпека;
* кращий моніторинг;
* професійне адміністрування;
* масштабування;
* контроль мережі;
* супровід корпоративних стандартів.; Web / VPN / Локальна мережа


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


</div>
[[Категорія:Конфігурація BAS]]
!; Перевірка
{| class="wikitable" style="width:100%;"


'''Головне.''' ERP на власному сервері — це не без ускладнень “поставити програму на комп’ютер”.; * філії;
як ілюстрація:
* віддалені працівники;
* бухгалтери;
* керівники;
* складські підрозділи;
* сервісні інженери;
* інтеграційні сервери.;[[Категорія:ERP інфраструктура]]


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


=== Що таке ERP на власному сервері? ===
{{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
}}


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


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


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


Потрібно контролювати:
Користувачі


Це дуже часта помилка.; |-
* виділену інфраструктуру;
| центральний недолік
* контроль доступів;
| організація сама відповідає за сервери, backup, безпеку, актуалізація й відновлення.;{{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
* ізоляцію;
}}
* інтеграції;
* можливість розміщення в потрібному датацентрі.; !; * контроль доступів;
* складні паролі;
* двофакторну автентифікацію для критичних ролей;
* обмеження адміністраторів;
* HTTPS;
* VPN;
* міжмережевий екран;
* обмеження доступу до СУБД;
* захист резервних копій;
* журналювання;
* моніторинг;
* регулярні актуалізація;
* антивірусний контроль;
* аудит сервісних акаунтів;
* контроль API;
* контроль експорту даних.; # Перевірити API.; Приклад


== Сервер застосунку ==
ERP має змогу зберігати файли:


HTTPS захищає:
ERP на власному сервері часто інтегрується з локальними системами.; Навіть у сучасній ERP можуть залишатися файлові обміни.; Ризики:


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


* маршрутизацію запитів;
* зберігання даних;
* HTTPS;
* запити;
* reverse proxy;
* транзакції;
* балансування;
* індекси;
* обмеження доступу;
* резервне копіювання;
* журналювання;
* відновлення;
* захист API;
* продуктивність;
* інтеграцію з сертифікатами;
* права доступу;
* публікацію зовнішніх endpoint-ів.;== ERP на власному сервері і міграція з 1С/BAS ==
* цілісність даних.;== Тестове середовище ==


!;== Реплікатор K2 і власний сервер ==
[[Категорія:1С]]
Потрібен реєстр інтеграцій.; # Налаштувати мережу.; * місце на диску менше 15%;
* backup не виконано;
* база недоступна;
* API повертає помилки;
* сертифікат HTTPS скоро закінчується;
* фонові задачі не виконуються.; Безпека має включати:


* логіни;
[[Категорія:Користувач BAS]]
* паролі;
Потрібно визначити, хто і звідки має доступ.;[[Категорія:XML]]
* сесії;
* документи;
* фінансові інформаційні дані;
* зарплату;
* персональні інформаційні дані;
* API-токени;
* файли;
* інтеграційні запити.; інтеграційні функціональні можливості
{| class="wikitable" style="width:100%;"
!; Вона особливо доречна для виробництва, логістики, агробізнесу, великих складів, підприємств із локальним обладнанням, закритими мережами або власною ІТ-командою.; '''[[Реплікатор K2]]''' має змогу допомогти при міграції з 1С/BAS у K2 ERP.; Наслідок


== актуалізація ERP на власному сервері ==
[[Категорія:Міграція з BAS]]
!; Такі каталоги потрібно захищати, резервувати і журналювати.;== Що таке ERP на власному сервері ==


Через кілька років ERP має змогу мати десятки інтеграцій, але ніхто не знає:
Власний датацентр підходить для більших компаній.;[[Категорія:SQL]]


* доступність ERP;
* продажі та реалізація;
* CPU;
* залишки;
* RAM;
* прибуток;
* диски;
* маржу;
* місце на диску;
* собівартість;
* навантаження СУБД;
* дебіторську заборгованість;
* час відповіді;
* кредиторську заборгованість;
* помилки web-сервера;
* складські KPI;
* фонові задачі;
* виробничі KPI;
* інтеграції;
* фінансові показники;
* backup;
* керівницькі дашборди.; Копія
* сертифікати;
== HTTPS ==
* черги;
* журнали помилок.; # Налаштувати інтеграції.; # Створити тестову копію.; # Перевірити ключові процеси.; Не рекомендується давати Power BI прямий неконтрольований доступ до робочої бази ERP, якщо це створює навантаження або ризик витоку.;=== Кому підходить ERP на власному сервері? ===
Через VPN можуть працювати:
|-
|-
| Основна
| SaaS
| Робочий сервер
| У хмарі постачальника
| Поточна робота
| Постачальник
|-
|-
| Локальний backup
| On-premise
| NAS або backup-сервер
| На серверах клієнта або в його датацентрі
| Швидке відновлення
| замовник або його ІТ-партнер
|-
|-
| Віддалений backup
| Гібридна
| Інший майданчик або захищене сховище
| Частково в хмарі, частково локально
| Відновлення після аварії
| Спільна відповідальність
|}
|}


доступ до ERP через браузер або API реалізується засобами Web-сервер.; Критичність
== Зовнішні посилання ==


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


На власному сервері можуть працювати різні [[Модулі K2 ERP]]:
* організація має власну ІТ-службу;
* є собою вимоги до локального зберігання даних;
* є собою корпоративний датацентр;
* є собою політики безпеки, які не дозволяють повну хмару;
* потрібні локальні інтеграції;
* є собою багато внутрішніх систем;
* потрібен контроль СУБД;
* потрібен контроль резервних копій;
* потрібен контроль мережі;
* потрібен доступ без публічного інтернету;
* є собою вимоги до ізоляції;
* організація має критичні процеси;
* потрібне розміщення в конкретній юрисдикції.; Де функціонує ERP
<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
== Основні компоненти ERP на власному сервері ==
[[Категорія:SaaS]]


Краще будувати окремий BI-шар.; істотно, щоб модулі не жили як окремі “острови”, а використовували єдині довідники, права, audit log і контрольні звіти.; Для критичних ролей бажано використовувати посилений захист, особливо для адміністраторів, фінансів, зарплати й API.; # Перевірити відновлення.;== Що таке ERP на власному сервері ==
[[Категорія:Локальна ERP]]


Правильний on-premise підхід надає можливість компанії отримати сучасну українську ERP-систему з повним контролем над даними, безпечною інфраструктурою, прозорими інтеграціями й готовністю до масштабування.; ERP на власному сервері часто функціонує у віртуальному середовищі.; |}
Але VPN не замінює ролі, паролі, журналювання і контроль доступів.; Це повноцінна технічна архітектура, яка передбачено сервер застосунків, СУБД, файлове сховище, резервне копіювання, моніторинг, актуалізація, доступи, ролі, [[API]], [[BI]], інтеграції, журналювання, кібербезпеку, адміністрування і підтримку.; * віддалених працівників;
* філій;
* бухгалтерії;
* керівників;
* адміністраторів;
* інтеграторів;
* зовнішніх консультантів.;== Сервер бази даних ==
</syntaxhighlight>
!; |-
| Сервери
| організація або ІТ-підрядник
|-
| СУБД
| DBA або адміністратор
|-
| Резервні копії
| ІТ-служба / підрядник
|-
| актуалізація K2 ERP
| Постачальник / впроваджувач / адміністратор
|-
| Користувачі й ролі
| Адміністратор ERP
|-
| API
| Інтегратор / адміністратор
|-
| BI
| Аналітик / адміністратор BI
|-
| Безпека
| ІТ-служба / служба безпеки
|}


Він відповідає за:
Потрібно налаштувати:


Приклади:
!; Для чого


!;[[Категорія:Audit log]]
як ілюстрація:


<syntaxhighlight lang="text">
== Файлове сховище ==
[[Категорія:Моніторинг]]
[[Категорія:Сервер ERP]]


<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
== RPO і RTO ==
== Висновок ==
Потрібно проаналізувати:


== Безпека ERP на власному сервері ==
'''істотно про BAS і 1С.''' [[BAS]] та [[1С]] мають санкційні, юридичні й кібербезпекові ризики в Україні.;== Журналювання ==


* довідники;
== Власний датацентр ==
* документи;
== Сервісні користувачі ==
* проводки;
== API-шлюз ==
* регістри;
|-
* залишки;
| Що таке ERP на власному сервері?; Правильний порядок:
* історію змін;
* користувачів;
* права;
* конфігурація;
* журнали;
* інформаційні дані інтеграцій;
* аналітичні таблиці.; !; * RAID;
* резервне живлення;
* другий сервер;
* репліка бази;
* кластер;
* резервний інтернет;
* віддалений backup;
* standby-сервер;
* план ручного відновлення;
* регулярні навчальні відновлення.; Backup, перевірене відновлення, безпека, права доступу, firewall, HTTPS, моніторинг, тестовий контур, документація і план аварійного відновлення.;[[Категорія:BI]]


'''Критично.''' Backup ERP, який не перевірявся на відновлення, не можна вважати робочим backup.;== Тестовий сервер ERP ==
[[Категорія:Українське програмне забезпечення]]


Для критичних ERP потрібно думати про відмовостійкість.;<syntaxhighlight lang="text">
{| class="wikitable" style="width:100%;"


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


[[Категорія:Firewall]]
Для ERP на власному сервері бажано мати тестове середовище.;== Що таке on-premise ERP ==
ERP має змогу підтримувати різні способи входу:
<div style="border:3px solid #ef6c00; background:#fff3e0; padding:14px; margin:16px 0;">


'''[[K2 ERP]]''' має змогу розгортатися як сучасна ERP-система з різними варіантами інфраструктури, зокрема на власних серверах компанії, якщо така модель відповідає вимогам бізнесу.; !; # Узгодити час актуалізація.; У хмарній ERP значну частину цієї відповідальності бере на себе провайдер.; Це зменшує ризик зламати робочу ERP.;[[Категорія:Інтеграція]]
Потрібно періодично перевіряти:


[[Категорія:ERP]]
* 3 копії даних;
* 2 різні носії або сховища;
* 1 копія поза основним майданчиком.;== Моніторинг ==


DEV → TEST → PROD
[[Категорія:On-premise ERP]]
 
{| class="wikitable" style="width:100%;"
Правильний порядок:
== Помилка: інтеграції не документовані ==
[[Категорія:Резервне копіювання]]
переважні аспекти:
=== Чим on-premise ERP відрізняється від хмарної ERP? ===
|-
| Банк
| ERP ↔ Банк
| API / файл
| фінансовий блок + ІТ
| Висока
|-
| Сайт
| Сайт → ERP
| REST API
| продажі та реалізація + ІТ
| Висока
|-
| Power BI
| ERP → BI
| Data export
| Аналітик
| Середня
|-
| WMS
| ERP ↔ складський облік
| API
| Логістика + ІТ
| Висока
|}


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


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


Недоліки:
* хмарну ERP;
* ERP на власному сервері;
* ERP у приватному датацентрі;
* гібридну модель;
* SaaS-модель;
* on-premise-модель.;[[Категорія:ERP]]


* схему серверів;
* HTTPS;
* IP-адреси;
* VPN або обмеження IP;
* доменні імена;
* сильні паролі;
* порти;
* журналювання;
* ролі серверів;
* обмеження ролей;
* версії ПЗ;
* захист API;
* СУБД;
* моніторинг;
* backup-політику;
* регулярні актуалізація.; # Визначити кількість користувачів.; Що означає
* процедуру відновлення;
* список інтеграцій;
* список сервісних облікових записів;
* список адміністраторів;
* графік оновлень;
* правила доступу;
* аварійні контакти.; Відкрити API ERP напряму в інтернет без обмежень.; Напрям


Компаніям із власною ІТ-командою, високими вимогами до контролю даних, локальними інтеграціями, виробництвом, складом, закритою мережею або вимогами до локального розміщення.; !; * хто відповідальний;
[[Категорія:Оновлення BAS]]
* де backup;
* як відновити базу;
* як відновити файли;
* як підняти web-сервер;
* як перевірити ERP після відновлення;
* які інтеграції ввімкнути;
* які користувачі тестують;
* скільки даних можна втратити;
* скільки часу бізнес-середовище має змогу бути без ERP.;</syntaxhighlight>


* '''RPO''' — скільки даних допустимо втратити;
== Як не треба робити ==
* '''RTO''' — за який час потрібно відновити систему.; # Оцінити обсяг даних.; виробництва забезпечується через Такий підхід застосовується, коли бізнес-середовище хоче мати максимальний контроль над даними, інфраструктурою, доступами, інтеграціями, політиками безпеки, резервними копіями, мережевими правилами і внутрішнім ІТ-контуром.;[[Категорія:HTTPS]]


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


== Правило 3-2-1 для backup ==
Web-сервер потрібен для доступу через браузер.; Навіщо
!;</div>


* сервери;
!; ERP на власному сервері має змогу бути частиною цифрової незалежності.; Окремі продукти [[1С]] і [[BAS]] внесені до відкритих переліків програмного забезпечення, забороненого до використання для окремих категорій організацій.; # Спроєктувати серверну архітектуру.; Питання
* диски;
* мережеве обладнання;
* ліцензії ОС;
* ліцензії СУБД, якщо потрібні;
* backup-сховище;
* UPS;
* електрику;
* охолодження;
* адміністраторів;
* моніторинг;
* актуалізація;
* антивірус і безпеку;
* аварійне відновлення;
* підтримку;
* простої;
* заміну обладнання.; # Налаштувати VPN або захищений доступ.; # Визначити кількість користувачів.; # Налаштувати моніторинг.; '''ERP на власному сервері дає контроль, але не прощає хаосу.''' Без backup, моніторингу, тестового контуру і плану відновлення власний сервер має змогу стати не перевагою, а ризиком.; * швидкі диски;
* достатньо оперативної пам’яті;
* стабільне резервне копіювання;
* моніторинг;
* обмеження доступу;
* регулярне обслуговування;
* контроль розміру бази;
* план аварійного відновлення.;<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">


як ілюстрація:
!; Сервер K2 ERP
Це має змогу бути:
'''ERP на власному сервері''' — це варіант впровадження, коли ERP-система встановлюється і функціонує на інфраструктурі, яку контролює сама організація або її ІТ-підрядник.; | Так, якщо бізнесу потрібен контроль інфраструктури, СУБД, API, BI, інтеграцій і безпеки.; # Зафіксувати версію.; з цієї причини перехід на [[K2 ERP]] на власному сервері має змогу бути частиною стратегії цифрової незалежності, контролю даних і відмови від старої ризикової екосистеми.;== План аварійного відновлення ==


== Віртуалізація ==
[[Категорія:Права доступу]]


# Зробити backup.; Для великих компаній сервер застосунку має змогу бути не один.; Потрібно рахувати повну вартість володіння: обладнання, ліцензії, адміністрування, електрику, backup, безпеку, моніторинг, простої й актуалізація.; Приклад графіка:
[[Категорія:API]]
Права доступу мають бути налаштовані за принципом мінімально необхідного доступу.; Це повноцінна відповідальність компанії за сервери, базу даних, мережу, backup, безпеку, моніторинг, актуалізація, доступи, продуктивність, аварійне відновлення та інтеграції.; Так, якщо така інфраструктурна модель відповідає вимогам компанії.; Він має фіксувати:


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


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


Для ERP диски критично важливі.; Відповідь
!; {| class="wikitable" style="width:100%;"


* які порти відкриті;
як ілюстрація:
* хто має доступ до web-сервера;
<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
* хто має доступ до СУБД;
'''Головне.''' ERP на власному сервері дає компанії більше контролю над даними, інфраструктурою, доступами, інтеграціями та безпекою, але вимагає відповідальності за сервери, резервні копії, актуалізація, моніторинг, кібербезпеку і технічну підтримку.; Адміністратори ERP на власному сервері мають особливу відповідальність.; | організація або її ІТ-партнер відповідає за сервери, СУБД, бекапи, актуалізація, моніторинг і аварійне відновлення.; Такий підхід часто називають '''on-premise ERP''', '''локальна ERP''', '''ERP на сервері компанії''' або '''ERP у власній інфраструктурі'''.; # Налаштувати користувачів і ролі.; Призначення
* хто має доступ до SSH/RDP;
* які IP дозволені;
* які API доступні зовні;
* які інтеграції можуть підключатися;
* які сервіси доступні тільки всередині мережі.; Погана практика — зберігати базу, файли і backup на одному диску без резервування.; ERP на власному сервері має змогу бути доречною; додатково реалізовано агробізнесу, логістики, фінансово чутливих компаній, державного сектору, холдингів, підприємств із закритою мережею або організацій, які мають власну ІТ-команду.; VPN застосовується для безпечного доступу віддалених користувачів.; * DEV — розробка програмного забезпечення;
* TEST — перевірка бізнес-користувачами;
* PROD — робоча платформа.; # Задокументувати інфраструктуру.; Файлове сховище має бути:


Для ERP на власному сервері потрібно мати план аварійного відновлення.; Backup — критична частина on-premise ERP.; Відповідальний
* консультації;
[[Категорія:Українське програмне забезпечення]]
* актуалізація;
В on-premise ERP організація сама відповідає за сервери, backup, безпеку, актуалізація і моніторинг.; Причина
* виправлення помилок;
переважні аспекти:
* аналіз журналів;
* перевірку продуктивності;
* підтримку інтеграцій;
* підтримку API;
* підтримку BI;
* допомогу з резервними копіями;
* консультації з СУБД;
* допомогу при аваріях;
* супровід міграції;
* навчання адміністраторів.; * більше оперативної пам’яті;
* швидші диски;
* окремий сервер СУБД;
* окремий сервер BI;
* окремий API-сервер;
* балансування навантаження;
* архівування старих даних;
* оптимізація запитів;
* збільшення мережевої пропускної здатності;
* резервний сервер.; Після переходу стара BAS/1С має змогу залишитися як архів.; Не можна використовувати адміністратора для інтеграцій.; # Налаштувати журналювання.; !;[[Категорія:Версія K2 ERP]]


Потрібно розділяти:
актуалізація потрібно виконувати контрольовано.;[[Категорія:Інтеграція]]
Резервне копіювання + BI + Архів
== BI на власному сервері ==


Після переходу стару 1С/BAS-базу можна залишити як архів.; * фінансовий блок;
Приклади:
* бухгалтерський обліковий облік;
* управлінський обліковий облік;
* продажі та реалізація;
* закупівельна діяльність;
* складський облік;
* WMS;
* CRM;
* виробництво;
* MRP;
* MES;
* HRM;
* зарплата;
* електронний документообіг;
* автотранспорт;
* агро;
* елеватор;
* акцизне пальне;
* BI;
* API;
* інтеграції.; # Виконати контрольні перевірки.; # Перевірити права.;== K2 ERP на власному сервері ==


</syntaxhighlight>
СУБД — це платформа керування базами даних.;== Помилка: відкрити ERP напряму в інтернет ==


* процесор;
== Фізичний сервер чи віртуальна машина ==
* оперативна пам’ять;
* диски;
* мережа;
* СУБД;
* кількість користувачів;
* обсяг даних;
* звіти;
* інтеграції;
* фонові задачі;
* індекси;
* backup у робочий час;
* антивірус;
* віртуалізація;
* якість коду;
* конфігурація web-сервера.; {| class="wikitable" style="width:100%;"


Гібридна ERP-архітектура поєднує власний сервер і хмарні сервіси.; # Провести навантажувальну перевірку.; Для власного сервера важливі:
!;[[Категорія:Користувач K2 ERP]]


== Модулі K2 ERP на власному сервері ==
ERP-система є собою центральною інформаційною системою підприємства.;== Як правильно впроваджувати ERP на власному сервері ==


API → HTTPS → Reverse proxy → Firewall → Авторизація → Журнал → ERP
* договори;
* скани документів;
* рахунки;
* акти;
* накладні;
* сертифікати;
* зображення товарів;
* імпортні файли;
* експортні файли;
* вкладення;
* архіви;
* резервні копії;
* логи.; Доступ


!; Доступ
!; # Описати бізнес-вимоги.; У результаті власний сервер стає не перевагою, а критичною точкою ризику.;== Архівування ==
Сервер бази даних зберігає основні інформаційні дані ERP.; # Запланувати вікно актуалізація.;== Див.; додатково ==


Типові симптоми проблем:
[[Категорія:СУБД]]


{| class="wikitable" style="width:100%;"
== Помилка: залишити BAS/1С активною після переходу ==


{| class="wikitable" style="width:100%;"
* базу даних;
!; Компонент
* файлове сховище;
|-
* конфігурацію;
| Що це?; Копія
* конфігурація;
|-
* сертифікати;
| Щоденний
* API-ключі;
| Щодня вночі
* BI-вітрини;
| 14–30 днів
* web-сервер;
|-
* скрипти;
| Тижневий
* документацію;
| Раз на тиждень
* журнали;
| 2–3 місяці
* інтеграційні файли.; Він має змогу забезпечувати:
|-
| Місячний
| Раз на місяць
| 1–3 роки
|-
| Перед оновленням
| Перед кожним оновленням
| До підтвердження стабільної роботи
|-
| Перед міграцією
| Перед кожним великим імпортом
| До завершення звірки
|}


Краще:
HTTPS захищає передачу:


== SSL / HTTPS ==


'''Проста аналогія.''' Хмарна ERP — це орендований офіс із готовою охороною, електрикою і прибиранням.; Power BI має змогу підключатися до ERP на власному сервері через:
* що робити при поломці сервера;
* що робити при пошкодженні бази;
* що робити при кібератаці;
* що робити при втраті інтернету;
* що робити при втраті електроживлення;
* хто відповідальний;
* де резервні копії;
* як відновити систему;
* як перевірити інформаційні дані;
* як повідомити користувачів;
* який допустимий час простою.; # Перевірити відновлення.; Потрібно продумати:
ERP на власному сервері потрібно моніторити.; Приватна хмарна інфраструктура має змогу бути компромісом між on-premise і SaaS.; '''Критично.''' ERP на власному сервері не можна відкривати назовні без HTTPS, сильних паролів, обмеження доступу, журналювання, резервних копій і контролю безпеки.; # Перевірити ролі.;<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">


'''ERP на власному сервері''' — це сильна модель для компаній, яким потрібен контроль над даними, інфраструктурою, доступами, інтеграціями і політиками безпеки.; Потрібно рахувати повну вартість.; # Визначити модулі ERP.; Сервер застосунку виконує бізнес-логіку ERP.; Окремо варто відзначити коли програмне забезпечення, база даних, файли, інтеграції, резервні копії і серверна інфраструктура знаходяться на обладнанні компанії або в контрольованому дата-центрі компанії, а не в цілому в хмарі постачальника виступає ключовою рисою '''ERP на власному сервері''' або '''on-premise ERP'''.; Якщо ERP відкриває API, потрібно передбачити:
== Коли ERP на власному сервері доречна ==


ERP на власному сервері має змогу бути доступною:
* на з цієї причини самому сервері;
* на окремому сервері;
* у хмарі;
* у гібридній моделі;
* як окрема аналітична база;
* як вітрина даних.; # Зробити резервну копію.; Вона відповідає за:
З урахуванням санкційних, юридичних і кібербезпекових ризиків [[BAS]] та [[1С]], перехід на [[K2 ERP]] на власному сервері має змогу стати частиною ширшої стратегії цифрової незалежності, контролю даних, українського програмного забезпечення і сучасної ERP-архітектури.; | Це модель, коли ERP функціонує на серверах компанії або в інфраструктурі, яку організація контролює.; !; |-
| Що істотно при міграції з BAS/1С?; |-
| Як ще називається така модель?; Модель


== Firewall ==
<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">


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


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


== Відмовостійкість ==
Найчастіші помилки:


!; Приклад критичних сповіщень:
Користувачі можуть працювати через:


* потрібна ІТ-команда;
* XML;
* вищі стартові витрати;
* JSON;
* відповідальність за backup;
* CSV;
* відповідальність за безпеку;
* Excel;
* відповідальність за актуалізація;
* ZIP;
* ризики простою;
* PDF;
* потрібно обладнання;
* банківські файли;
* потрібен моніторинг;
* файли постачальників;
* складніше масштабування;
* файли маркетплейсів.;== Доступ користувачів ==
* ризик застарівання серверів;
* потрібно планувати аварійне відновлення;
* потрібно контролювати фізичну безпеку.; Для чого потрібен
[[Категорія:Power BI]]
!; актуалізація без тесту має змогу зламати:


[[Категорія:Кібербезпека]]
<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">


<syntaxhighlight lang="text">
[[Категорія:Цифрова незалежність України]]
Snapshot не замінює повноцінний backup ERP.;== On-premise ERP і хмарна ERP ==


[[Категорія:Модулі K2 ERP]]
== Порівняння власного сервера і хмари ==
!; | Так.; Старі інформаційні дані можуть впливати на продуктивність.; !; '''On-premise ERP''' — це міжнародна назва моделі, коли ERP розміщується “на майданчику” клієнта або в інфраструктурі, яку замовник контролює.; # Перевірити BI.; Резервна копія має сенс тільки тоді, коли її можна відновити.;</div>


Без документації ERP залежить від пам’яті одного адміністратора.; Потрібно контролювати:
== VPN ==


* диск бази даних;
переважні аспекти:
* диск журналів СУБД;
* диск файлів;
* диск backup;
* тимчасові файли;
* архіви.; ERP на власному сервері — це модель розгортання, коли ERP-система, база даних, файли, інтеграції й backup розміщуються на серверах, які контролює організація.; # Налаштувати тестовий контур.;=== Чи дешевше власний сервер за хмару? ===


ERP база: D:\ERP
# Прочитати release notes.;== ERP на власному сервері і міграція з BAS/1С ==
== Сервер застосунків ==
Потрібно контролювати:
[[Категорія:BAS]]
[[Категорія:Журналювання]]
[[Категорія:BI]]
== Власний сервер в офісі ==
[[Категорія:Міграція з 1С]]
<syntaxhighlight lang="text">
У ERP на власному сервері — це не без ускладнень “поставити програму на сервер”.; ERP на власному сервері має змогу бути доречною, якщо:


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


* документи;
Потрібні:
* звіти;
* інтеграції;
* друковані форми;
* права;
* API;
* фонові задачі;
* Power BI-вивантаження.;== Права доступу ==
== Документація ERP-інфраструктури ==
== Див.; додатково ==
Хмарна ERP має змогу бути кращою, якщо:
<syntaxhighlight lang="text">
[[Категорія:СУБД]]
!;== Графік резервного копіювання ==


{| class="wikitable" style="width:100%;"
BI має змогу показувати:


[[Категорія:Заміна BAS]]
* які інформаційні дані залишати в робочій базі;
* які переносити в архів;
* як відкривати архів;
* хто має доступ;
* чи потрібен пошук;
* чи потрібні звіти по архіву;
* як зберігати документи;
* як резервувати архів.; # Оновити тестове середовище.;== Версійність ==


* сервери;
* сервер застосунків;
* сервер бази даних;
* СУБД;
* СУБД;
* файлове сховище;
* файлове сховище;
* backup;
* web-сервер;
* тестовий контур;
* API-шлюз;
* мережевий доступ;
* BI-сервер або BI-вітрини;
* сервер резервного копіювання;
* моніторинг;
* платформа журналювання;
* мережевий захист;
* VPN;
* VPN;
* платформа оновлень;
* тестове середовище;
* архівне середовище.; {| class="wikitable" style="width:100%;"
|-
| RPO
| Скільки даних можна втратити
| Не більше 1 години
|-
| RTO
| За скільки часу потрібно відновити систему
| Не більше 4 годин
|}
Потрібно визначити:
== Що переносити з BAS/1С ==
SLA має змогу визначати:
</div>
* доступність сервера;
* навантаження CPU;
* пам’ять;
* диски;
* місце на диску;
* СУБД;
* час відповіді;
* API;
* API;
* інтеграції;
* web-сервер;
* Power BI;
* BI-оновлення;
* права доступу;
* резервні копії;
* архів старої BAS/1С;
* помилки;
* план аварійного відновлення.; Де:
* журнали;
* активних користувачів;
* підозрілу активність.; супровід ERP на власному сервері має змогу включати:
 
[[Категорія:K2 ERP]]
 
Для резервного копіювання часто використовують підхід 3-2-1:
 
* сайт;
* CRM;
* WMS;
* банк;
* мобільний застосунок;
* BI;
* маркетплейс;
* електронний електронний документообіг;
* платформа доставки;
* внутрішній портал;
* виробниче обладнання.; | Резервні копії, перевірка відновлення, HTTPS, VPN або обмеження доступу, ролі, журналювання, моніторинг і тестова база.;[[Категорія:Ліцензування K2 ERP]]
 
 
* локальну мережу;
* VPN;
* доступ філій;
* доступ віддалених користувачів;
* пропускну здатність;
* затримки;
* резервний інтернет;
* міжмережеві екрани;
* сегментацію мережі;
* доступ до СУБД;
* доступ до API;
* доступ до резервних копій.; # Налаштувати HTTPS.;== Користувачі і ролі ==


Краще:
* web-інтерфейс;
* локальну мережу;
* VPN;
* віддалений робочий стіл;
* корпоративний браузер;
* мобільні сценарії;
* API-клієнти;
* BI-панелі.; має змогу знадобитися:


== Web-сервер ==
Через API можуть працювати:


* логін і пароль;
</syntaxhighlight>
* доменна авторизація;
* SSO;
* двофакторна автентифікація;
* VPN-доступ;
* окремі API-токени;
* службові облікові записи.; Сервер бази даних — один із найважливіших компонентів ERP.; '''Audit log''' або журнал аудиту потрібен для контролю дій у ERP.;== Реєстр інтеграцій ==


На продуктивність впливають:
API потрібно захищати:
!;=== Чи можна розгорнути K2 ERP на власному сервері? ===


* довго відкриваються документи;
СУБД
* повільно формуються звіти;
* зависає проведення;
* падають фонові задачі;
* API відповідає повільно;
* користувачі скаржаться на затримки;
* backup триває занадто довго.; ERP має змогу бути технічно добре налаштована, але вразлива через слабку серверну кімнату.;=== Що найважливіше при ERP на власному сервері? ===


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


[[Категорія:Моніторинг]]
Потрібно вирішити:


== Відновлення після аварії ==
!;== Резервні копії ==


Він має змогу виконувати:
[[Категорія:Деколонізація обліку]]
Не рекомендується відкривати ERP напряму в інтернет без захисту, firewall, HTTPS, журналювання і контролю доступу.; !;[[Категорія:Реплікатор K2]]


<syntaxhighlight lang="text">
== Мережа ==


Backup: D:\Backup
* документи вводяться у дві системи;
* сайт читає старі залишки;
* BI бере старі інформаційні дані;
* користувачі не розуміють, де правильна відомості;
* інтеграції працюють паралельно;
* джерело істини зникає.; '''Найгірший сценарій.''' організація переносить ERP на власний сервер, але не налаштовує резервні копії, HTTPS, VPN, моніторинг, ролі, API-захист і план відновлення.;{{DISPLAYTITLE:ERP на власному сервері}}


* вивантаження довідників;
У базі можуть бути:
* вивантаження документів;
* вивантаження регістрів;
* формування контрольних сум;
* підготовки даних;
* перевірки залишків;
* порівняння старої і нової системи;
* підготовки Power BI-аналітики;
* паралельного запуску;
* тестових імпортів у K2 ERP на власному сервері.; # Перевірити інтеграції.;[[Категорія:K2 Cloud ERP]]


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


Для інтеграцій потрібно контролювати:
Для ERP СУБД є собою критично важливою частиною інфраструктури.; |-
[[Категорія:Сервери]]
| У чому недолік?; * HTTPS;
Але власний сервер означає і власну відповідальність: backup, безпека, актуалізація, моніторинг, відновлення після аварії, продуктивність, права доступу, інтеграції, документація і фізичний захист інфраструктури мають бути організовані професійно.;== Вартість володіння ERP на власному сервері ==
* маршрутизацію запитів;
До СУБД потрібні особливі вимоги:
* web-інтерфейс;
[[Категорія:Backup]]
* API;
Він має змогу використовуватися для:
* статичні файли;
</div>
* журнали доступу;
== Для чого обирають ERP на власному сервері ==
* обмеження IP;
== Помилка: немає тестового актуалізація ==
* інтеграцію з корпоративною мережею;
== Аутентифікація користувачів ==
* роботу через VPN або публічний домен.; # Провести навчання користувачів.; # Перевести старі BAS/1С-системи в архів.; == Перевірка відновлення ==

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

ERP на власному сервері має мати план аварійного відновлення.; це модель розміщення ERP-системи.; Обмеження

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

Погані підходи: !;

  • копія пошкоджена;
  • не вистачає файлів;
  • не збережені сертифікати;
  • не функціонує СУБД;
  • не функціонує API;
  • не функціонує BI;
  • не збережені конфігурація.;

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

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

Користувачі → Корпоративна мережа / VPN / Web → Сервер ERP → СУБД → інформаційні дані компанії

API на власному сервері дає можливість інтегрувати ERP з іншими системами.; Спрощена схема: Воно потрібне для: Якщо ERP доступна через web, потрібно використовувати HTTPS.;== Відповідальність при ERP на власному сервері == Web-сервер / API-шлюз Приклад архітектури:
app-k2-01 Сервер застосунків K2 ERP Web, бізнес-логіка, API
db-k2-01 Сервер СУБД Основна база даних
bi-k2-01 BI-сервер аналітичні інструменти і дашборди
backup-k2-01 Резервні копії Локальні й віддалені копії
test-k2-01 Тестове середовище актуалізація і навчання
Потрібно знати: Приклад: Сервер застосунків виконує бізнес-логіку ERP.;== Продуктивність == Безпека має включати: Він має змогу бути потрібен для:

актуалізація ERP на власному сервері

- У чому перевага?; Зона

Якщо ERP розміщується не в офісі, а в датацентрі, потрібно перевірити:

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

API потрібно захищати окремо.; # Оновити production.;

  • процесор;
  • оперативна пам’ять;
  • диски;
  • СУБД;
  • мережа;
  • кількість користувачів;
  • кількість документів;
  • складність звітів;
  • API-навантаження;
  • BI-запити;
  • резервне копіювання;
  • інтеграції;
  • фонові задачі;
  • індекси;
  • архівні інформаційні дані.; Варіант

У on-premise моделі відповідальність потрібно чітко розділити.; організація має змогу обрати:

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

організація має змогу мати резервні копії, але ніколи не перевіряти їх відновлення.; # Визначити API та BI.; Це небезпечно, бо в аварійний момент має змогу виявитися, що:

Вступ

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

Якщо ERP відкрита без захисту, ризики зростають.;== Типова технічна архітектура K2 ERP на власному сервері ==

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

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

BI має змогу працювати на окремому сервері або разом із ERP.; |- | Чи є собою санкційні ризики у BAS і ?; Порядок:

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

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

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

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

Датацентр

Web-сервер

Сервісні користувачі потрібні для інтеграцій.;== Безпека ERP на власному сервері ==

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

Що обов’язково потрібно?;== Адміністратори ==
== Архів старої BAS/1С ==

* тільки для перегляду;
* без введення нових документів;
* без активних інтеграцій;
* без доступу звільнених користувачів;
* із резервною копією;
* з обмеженим доступом;
* із журналом використання;
* із чіткою назвою “Архів”.;[[Категорія:JSON 1С]]

!; !; # Налаштувати моніторинг.; |-
| Чи можна розгорнути [[K2 ERP]] на власному сервері?; Хмарна ERP
== Що не переносити ==
[[Категорія:Заміна BAS]]
== Масштабування ==
== СУБД ==
 ↓
Під час переходу з [[BAS]] або [[1С]] на [[K2 ERP]] на власному сервері потрібно врахувати не тільки інформаційні дані, а й інфраструктуру.; * логінів;
* паролів;
* документів;
* персональних даних;
* фінансових даних;
* API-запитів;
* BI-звітів;
* токенів.; BI має змогу бути розміщений:

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

!;== Правило 3-2-1 ==

</div>

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

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

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

Файлове сховище потрібно резервувати і захищати так само уважно, як базу даних.; організація отримує:
{| class="wikitable" style="width:100%;"
{| class="wikitable" style="width:100%;"
Журналювання потрібне для:
ERP має змогу працювати на фізичному сервері або віртуальній машині.; {| class="wikitable" style="width:100%;"

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

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

* версію [[K2 ERP]];
* версію модулів;
* версію API;
* версію BI;
* версію СУБД;
* версію міграційних пакетів;
* дату актуалізація;
* список змін;
* відповідального за актуалізація.; # Перевірити BI.; # Провести тестову міграцію.; # Налаштувати VPN або мережеві обмеження.;[[Категорія:Безпека]]
Для критичних систем потрібен SLA.; Призначення
!; * сайт;
* CRM;
* WMS;
* мобільний застосунок;
* BI;
* банк;
* електронний електронний документообіг;
* сервіс доставки;
* маркетплейс;
* зовнішній партнерська сторона;
* внутрішня платформа компанії.; !;[[Категорія:Оновлення K2 ERP]]
|-
| Фізичний сервер
| Контроль ресурсів, висока продуктивність
| Складніше масштабування і відновлення
|-
| Віртуальна машина
| Гнучкість, знімки, простіше перенесення
| Потрібна якісна віртуалізація
|}

</div>

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

* електроживлення;
* резервне живлення;
* інтернет-канали;
* фізичну безпеку;
* доступ до серверів;
* резервне копіювання;
* пожежну безпеку;
* SLA датацентру;
* мережеву ізоляцію;
* відповідальність сторін.; | On-premise ERP, локальна ERP, ERP у власній інфраструктурі.;</div>

'''Цифрова незалежність.''' [[K2 ERP]] на власному сервері має змогу дати компанії контроль над критичною ERP-інфраструктурою: даними, доступами, інтеграціями, API, BI, резервними копіями, оновленнями і безпекою.; Він має змогу відповідати за:

VPN сприяє не відкривати ERP напряму в інтернет.; Хто контролює інфраструктуру
</div>
У ній можуть зберігатися:
|-
| Основна
| Робочий сервер
| Поточна робота
|-
| Локальний бекап
| Резервний сервер
| Швидке відновлення
|-
| Віддалений бекап
| Інший майданчик або захищене сховище
| Захист від аварії на основному майданчику
|}

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

ERP на власному сервері — це потужна модель розміщення, яка дає компанії контроль над ERP-інфраструктурою, даними, СУБД, API, BI, інтеграціями, доступами, резервними копіями й безпекою.; # Підготувати web-доступ.; Доступ
|-
| api_site
| інтеграційні функціональні можливості із сайтом
| Товари, ціни, залишки, замовлення
|-
| api_crm
| інтеграційні функціональні можливості з CRM
| Клієнти, угоди, статуси
|-
| api_wms
| інтеграційні функціональні можливості зі складом
| Залишки, переміщення, відвантаження
|-
| bi_export
| Передача даних у BI
| Читання аналітичних даних
|}

Сервер в офісі має змогу бути простішим, але має ризики:

[[Категорія:ERP на власному сервері]]

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

ERP без резервного копіювання — критичний ризик.; Окремо варто відзначити за якої програмне забезпечення, база даних, файли, інтеграції, резервні копії і технічна інфраструктура працюють на серверах компанії або в контрольованому датацентрі, а не в цілому в хмарному сервісі постачальника виступає ключовою рисою '''ERP на власному сервері'''.;== Помилка: сервер без резервного копіювання ==

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

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

* час реакції;
* час вирішення;
* критичність інцидентів;
* графік підтримки;
* відповідальних;
* канали звернення;
* ескалацію;
* підтримку production;
* підтримку тестового середовища;
* підтримку інтеграцій;
* підтримку API.;[[K2 ERP]] на власному сервері має змогу бути доречною для компаній, які хочуть контролювати свою інфраструктуру, мають внутрішню ІТ-команду, потребують локальних інтеграцій, хочуть ізолювати критичні інформаційні дані або будують власну українську ERP-архітектуру.; !; * токенами;
* HTTPS;
* обмеженням IP;
* ролями;
* журналюванням;
* лімітами;
* окремими сервісними користувачами.; # Підготувати СУБД.; Зазвичай переносять:

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

!; # Налаштувати інтеграції.; організація отримує:

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

* контроль інфраструктури;
* резервування;
* краща фізична безпека;
* кращий моніторинг;
* професійне адміністрування;
* масштабування;
* контроль мережі;
* супровід корпоративних стандартів.; Web / VPN / Локальна мережа

ERP на власному сервері потрібно масштабувати.; # Перевірити інтеграції.; Показник

[[Категорія:Конфігурація BAS]]
!; Перевірка
{| class="wikitable" style="width:100%;"

як ілюстрація:

Наслідки:

{{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
}}

* персональні логіни;
* ролі;
* групи доступу;
* підрозділи;
* організації;
* склади;
* каси;
* сервісних користувачів;
* API-користувачів;
* BI-користувачів;
* адміністраторів;
* аудиторів.; ERP на власному сервері
== Інтеграції ==
Ці показники допомагають правильно організувати резервне копіювання і аварійне відновлення.; | Перенести інформаційні дані й процеси, але не залишити стару BAS/1С активним джерелом обліку або інтеграцій.;== Чек-лист перед запуском ERP на власному сервері ==

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

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

Користувачі

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

ERP має змогу зберігати файли:

ERP на власному сервері часто інтегрується з локальними системами.; Навіть у сучасній ERP можуть залишатися файлові обміни.; Ризики:

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

* зберігання даних;
* запити;
* транзакції;
* індекси;
* резервне копіювання;
* відновлення;
* продуктивність;
* права доступу;
* цілісність даних.;== Тестове середовище ==

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

[[Категорія:Користувач BAS]]
Потрібно визначити, хто і звідки має доступ.;[[Категорія:XML]]

[[Категорія:Міграція з BAS]]
!; Такі каталоги потрібно захищати, резервувати і журналювати.;== Що таке ERP на власному сервері ==

Власний датацентр підходить для більших компаній.;[[Категорія:SQL]]

* продажі та реалізація;
* залишки;
* прибуток;
* маржу;
* собівартість;
* дебіторську заборгованість;
* кредиторську заборгованість;
* складські KPI;
* виробничі KPI;
* фінансові показники;
* керівницькі дашборди.; Копія
== HTTPS ==
|-
| SaaS
| У хмарі постачальника
| Постачальник
|-
| On-premise
| На серверах клієнта або в його датацентрі
| замовник або його ІТ-партнер
|-
| Гібридна
| Частково в хмарі, частково локально
| Спільна відповідальність
|}

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

Архів має бути:

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

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

Але VPN не замінює ролі, паролі, журналювання і контроль доступів.; Це повноцінна технічна архітектура, яка передбачено сервер застосунків, СУБД, файлове сховище, резервне копіювання, моніторинг, актуалізація, доступи, ролі, [[API]], [[BI]], інтеграції, журналювання, кібербезпеку, адміністрування і підтримку.; * віддалених працівників;
* філій;
* бухгалтерії;
* керівників;
* адміністраторів;
* інтеграторів;
* зовнішніх консультантів.;== Сервер бази даних ==
- Сервери організація або ІТ-підрядник
СУБД DBA або адміністратор
Резервні копії ІТ-служба / підрядник
актуалізація K2 ERP Постачальник / впроваджувач / адміністратор
Користувачі й ролі Адміністратор ERP
API Інтегратор / адміністратор
BI Аналітик / адміністратор BI
Безпека ІТ-служба / служба безпеки

Потрібно налаштувати:

!; Для чого

як ілюстрація:

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

RPO і RTO

Висновок

Потрібно проаналізувати:

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

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

Сервісні користувачі

API-шлюз

|- | Що таке ERP на власному сервері?; Правильний порядок:

  • втрата документів;
  • втрата залишків;
  • втрата фінансових даних;
  • зупинка бізнесу;
  • неможливість відновлення;
  • втрати через людську помилку;
  • втрати через технічну аварію;
  • втрати через кібератаку.; Сервер
Для ERP на власному сервері бажано мати тестове середовище.;== Що таке on-premise ERP == Потрібно періодично перевіряти:
  • 3 копії даних;
  • 2 різні носії або сховища;
  • 1 копія поза основним майданчиком.;== Моніторинг ==
Підхід K2 ERP.K2 ERP має змогу розгортатися у власній інфраструктурі компанії, якщо бізнесу потрібен контроль серверів, СУБД, резервних копій, API, BI, інтеграцій, доступів, журналювання, оновлень і політик безпеки.; Коментар
;

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

  • хмарну ERP;
  • ERP на власному сервері;
  • ERP у приватному датацентрі;
  • гібридну модель;
  • SaaS-модель;
  • on-premise-модель.;
  • HTTPS;
  • VPN або обмеження IP;
  • сильні паролі;
  • журналювання;
  • обмеження ролей;
  • захист API;
  • моніторинг;
  • регулярні актуалізація.; # Визначити кількість користувачів.; Що означає

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

  • локальна WMS;
  • локальна CRM;
  • банківський замовник;
  • касове обладнання;
  • ваги;
  • обладнання складу;
  • SCADA;
  • виробничі системи;
  • GPS;
  • телефонія;
  • файлові обміни;
  • старі BAS/1С-бази;
  • BI-сервер.; як ілюстрація:
Контроль інфраструктури Максимальний контроль у компанії Більше відповідальності у постачальника
Старт Потрібне конфігурація серверів Зазвичай швидший
Адміністрування Потрібна ІТ-команда Частково або в цілому на постачальнику
Резервні копії Відповідальність компанії або ІТ-партнера Часто входять у сервіс
Безпека Залежить від внутрішньої ІТ-дисципліни Залежить від постачальника і договору
Інтеграції комфортно для локальних систем комфортно для web/API-сервісів
Масштабування Потрібно планувати ресурси Зазвичай простіше
Вартість Сервери, адміністрування, супровід Підписка або сервісна модель

Web-сервер потрібен для доступу через браузер.; Навіщо

!;

!; ERP на власному сервері має змогу бути частиною цифрової незалежності.; Окремі продукти і BAS внесені до відкритих переліків програмного забезпечення, забороненого до використання для окремих категорій організацій.; # Спроєктувати серверну архітектуру.; Питання

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

  • обробку запитів користувачів;
  • роботу web-інтерфейсу;
  • проведення документів;
  • бізнес-процеси;
  • права доступу;
  • API;
  • фонові задачі;
  • регламентні процеси;
  • інтеграції;
  • журналювання;
  • перевірки даних.; Хто відповідає
  • фізичний сервер в офісі;
  • сервер у власному датацентрі;
  • віртуальна машина;
  • приватна хмарна інфраструктура;
  • орендований виділений сервер;
  • корпоративний кластер;
  • інфраструктура в датацентрі під контролем компанії.; # Визначити модулі K2 ERP.; !; * старий хаотичний код;
  • неактуальні обробки;
  • спільні логіни;
  • зайві ролі;
  • старі інтеграції під admin;
  • дублікати довідників;
  • тестові бази;
  • помилкові залишки;
  • небезпечні web-публікації;
  • хаотичні файлові обміни;
  • неактуальні архіви;
  • санкційно ризикову залежність.; Роль

!; * серверами;

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

як ілюстрація:

Головне. ERP на власному сервері дає компанії більше контролю над даними, інфраструктурою, доступами, інтеграціями та безпекою, але вимагає відповідальності за сервери, резервні копії, актуалізація, моніторинг, кібербезпеку і технічну підтримку.; Адміністратори ERP на власному сервері мають особливу відповідальність.; | організація або її ІТ-партнер відповідає за сервери, СУБД, бекапи, актуалізація, моніторинг і аварійне відновлення.; Такий підхід часто називають on-premise ERP, локальна ERP, ERP на сервері компанії або ERP у власній інфраструктурі.; # Налаштувати користувачів і ролі.; Призначення

  • консультації;
  • актуалізація;
  • виправлення помилок;
  • аналіз журналів;
  • перевірку продуктивності;
  • підтримку інтеграцій;
  • підтримку API;
  • підтримку BI;
  • допомогу з резервними копіями;
  • консультації з СУБД;
  • допомогу при аваріях;
  • супровід міграції;
  • навчання адміністраторів.; * більше оперативної пам’яті;
  • швидші диски;
  • окремий сервер СУБД;
  • окремий сервер BI;
  • окремий API-сервер;
  • балансування навантаження;
  • архівування старих даних;
  • оптимізація запитів;
  • збільшення мережевої пропускної здатності;
  • резервний сервер.; Після переходу стара BAS/1С має змогу залишитися як архів.; Не можна використовувати адміністратора для інтеграцій.; # Налаштувати журналювання.; !;

актуалізація потрібно виконувати контрольовано.; Резервне копіювання + BI + Архів

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

Приклади:

СУБД — це платформа керування базами даних.;== Помилка: відкрити ERP напряму в інтернет ==

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

!;

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

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

!; # Описати бізнес-вимоги.; У результаті власний сервер стає не перевагою, а критичною точкою ризику.;== Архівування == Сервер бази даних зберігає основні інформаційні дані ERP.; # Запланувати вікно актуалізація.;== Див.; додатково ==

Помилка: залишити BAS/1С активною після переходу

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

HTTPS захищає передачу:

  • що робити при поломці сервера;
  • що робити при пошкодженні бази;
  • що робити при кібератаці;
  • що робити при втраті інтернету;
  • що робити при втраті електроживлення;
  • хто відповідальний;
  • де резервні копії;
  • як відновити систему;
  • як перевірити інформаційні дані;
  • як повідомити користувачів;
  • який допустимий час простою.; # Перевірити відновлення.; Потрібно продумати:
ERP на власному сервері потрібно моніторити.; Приватна хмарна інфраструктура має змогу бути компромісом між on-premise і SaaS.; Критично. ERP на власному сервері не можна відкривати назовні без HTTPS, сильних паролів, обмеження доступу, журналювання, резервних копій і контролю безпеки.; # Перевірити ролі.;

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

  • на з цієї причини самому сервері;
  • на окремому сервері;
  • у хмарі;
  • у гібридній моделі;
  • як окрема аналітична база;
  • як вітрина даних.; # Зробити резервну копію.; Вона відповідає за:

З урахуванням санкційних, юридичних і кібербезпекових ризиків BAS та , перехід на K2 ERP на власному сервері має змогу стати частиною ширшої стратегії цифрової незалежності, контролю даних, українського програмного забезпечення і сучасної ERP-архітектури.; | Це модель, коли ERP функціонує на серверах компанії або в інфраструктурі, яку організація контролює.; !; |- | Що істотно при міграції з BAS/1С?; |- | Як ще називається така модель?; Модель

Кожен користувач системи має отримати тільки ті права, які потрібні для роботи.; |}

!; Для ERP істотно визначити два показники.; # Перевірити бізнес-сценарії.; Потрібно резервувати:

Найчастіші помилки:

Користувачі можуть працювати через:

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

Порівняння власного сервера і хмари

!; | Так.; Старі інформаційні дані можуть впливати на продуктивність.; !; On-premise ERP — це міжнародна назва моделі, коли ERP розміщується “на майданчику” клієнта або в інфраструктурі, яку замовник контролює.; # Перевірити BI.; Резервна копія має сенс тільки тоді, коли її можна відновити.;

VPN

переважні аспекти:

  1. Прочитати release notes.;== ERP на власному сервері і міграція з BAS/1С ==

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

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

Власний сервер в офісі

У ERP на власному сервері — це не без ускладнень “поставити програму на сервер”.; ERP на власному сервері має змогу бути доречною, якщо:

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

Потрібні:

BI має змогу показувати:

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

* сервер застосунків;
* сервер бази даних;
* СУБД;
* файлове сховище;
* web-сервер;
* API-шлюз;
* BI-сервер або BI-вітрини;
* сервер резервного копіювання;
* моніторинг;
* платформа журналювання;
* мережевий захист;
* VPN;
* платформа оновлень;
* тестове середовище;
* архівне середовище.; {| class="wikitable" style="width:100%;"
|-
| RPO
| Скільки даних можна втратити
| Не більше 1 години
|-
| RTO
| За скільки часу потрібно відновити систему
| Не більше 4 годин
|}

Потрібно визначити:

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

SLA має змогу визначати:

</div>

* доступність сервера;
* навантаження CPU;
* пам’ять;
* диски;
* місце на диску;
* СУБД;
* час відповіді;
* API;
* web-сервер;
* BI-оновлення;
* резервні копії;
* помилки;
* журнали;
* активних користувачів;
* підозрілу активність.; супровід ERP на власному сервері має змогу включати:

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

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

* сайт;
* CRM;
* WMS;
* банк;
* мобільний застосунок;
* BI;
* маркетплейс;
* електронний електронний документообіг;
* платформа доставки;
* внутрішній портал;
* виробниче обладнання.; | Резервні копії, перевірка відновлення, HTTPS, VPN або обмеження доступу, ролі, журналювання, моніторинг і тестова база.;[[Категорія:Ліцензування K2 ERP]]

 ↓

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

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

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

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

СУБД

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

компаній забезпечується через У випадку K2 ERP розміщення на власному сервері має змогу бути доречним; додатково реалізовано які мають підвищені вимоги до контролю даних, внутрішньої безпеки, інтеграцій з локальними системами, регуляторних обмежень, роботи у власному датацентрі, корпоративних політик ІТ або бажають в цілому контролювати серверну інфраструктуру.; {| class="wikitable" style="width:100%;"

!; * ставити ERP на випадковий офісний комп’ютер;

  • не мати резервних копій;
  • не мати тестової бази;
  • не мати плану відновлення;
  • не контролювати доступи;
  • не налаштувати HTTPS;
  • не обмежити API;
  • не розділити ролі;
  • не моніторити сервер;
  • не документувати інфраструктуру;
  • не перевіряти BI-навантаження;
  • не вимкнути старі BAS/1С-інтеграції;
  • ігнорувати санкційні й кібербезпекові ризики.; # Запустити production.; * немає власної ІТ-команди;
  • потрібен швидкий старт;
  • не хочеться адмініструвати сервери;
  • важлива прогнозована підписка;
  • потрібне автоматичне актуалізація;
  • потрібна проста масштабованість;
  • організація не хоче підтримувати СУБД;
  • потрібен доступ із різних локацій;
  • немає складних локальних інтеграцій;
  • бізнес-середовище хоче зосередитися на процесах, а не інфраструктурі.; * перевірки оновлень;
  • перевірки доробок;
  • навчання користувачів;
  • тестування інтеграцій;
  • перевірки API;
  • перевірки BI;
  • тестової міграції;
  • відпрацювання аварійного відновлення.; # Налаштувати резервні копії.; Відповідь

Потрібно вирішити:

!;== Резервні копії ==

Мережа

  • документи вводяться у дві системи;
  • сайт читає старі залишки;
  • BI бере старі інформаційні дані;
  • користувачі не розуміють, де правильна відомості;
  • інтеграції працюють паралельно;
  • джерело істини зникає.; Найгірший сценарій. організація переносить ERP на власний сервер, але не налаштовує резервні копії, HTTPS, VPN, моніторинг, ролі, API-захист і план відновлення.;

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

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

Для ERP СУБД є собою критично важливою частиною інфраструктури.; |- | У чому недолік?; * HTTPS;

  • маршрутизацію запитів;
  • web-інтерфейс;
  • API;
  • статичні файли;
  • журнали доступу;
  • обмеження IP;
  • інтеграцію з корпоративною мережею;
  • роботу через VPN або публічний домен.; # Провести навчання користувачів.; # Перевести старі BAS/1С-системи в архів.; == Перевірка відновлення ==