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

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

Матеріал з K2 ERP Wiki

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

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

Web-сервер

VPN

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

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

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

Приклади:

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

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

RPO і RTO

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

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

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

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

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

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

Архівування

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

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

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

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

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

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

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

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

# Налаштувати HTTPS. # Налаштувати журналювання. # Виконати контрольні звірки. Де функціонує ERP

BI здатна бути розміщений:

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

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

  • HTTPS;
  • VPN або обмеження IP;
  • сильні паролі;
  • журналювання;
  • обмеження ролей;
  • захист API;
  • моніторинг;
  • регулярні оновлення версій.== Датацентр ==

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

Сервери компанія-користувач або ІТ-підрядник
СУБД DBA або адміністратор
Резервні копії ІТ-служба / підрядник
оновлення версій K2 ERP Постачальник / впроваджувач / адміністратор
Користувачі й ролі Адміністратор ERP
API Інтегратор / адміністратор
BI Аналітик / адміністратор BI
Безпека ІТ-служба / служба безпеки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<syntaxhighlight lang="text">

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

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

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

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

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

</div>

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

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

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

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

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

як приклад:

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

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

!

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

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

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

СУБД

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

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

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

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

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

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

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

}}


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

HTTPS

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

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

! Навіщо

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

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

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

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

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

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

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

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

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

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

як приклад:

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

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

Користувачі

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Що таке on-premise ERP

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

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

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

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

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

Коротко

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

! як приклад: 

↓

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

</syntaxhighlight>

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

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

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

Вступ

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

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

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

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

СУБД

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

Див. так само

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

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

API-шлюз

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

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

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

! Обмеження

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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