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

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 і 1С?; Порядок:

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

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

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

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

Датацентр

Web-сервер

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

Під час переходу з BAS або 1С на 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 та 1С мають санкційні, юридичні й кібербезпекові ризики в Україні.;== Журналювання ==

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

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

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

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

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

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

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

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

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

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

VPN

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

Прочитати 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-захист і план відновлення.;

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