ERP на власному сервері: відмінності між версіями
R (обговорення | внесок) Створена сторінка: {{DISPLAYTITLE:ERP на власному сервері}} {{SEO |title=ERP на власному сервері — on-premise ERP, локальне розгортання, безпека, backup, адміністрування і K2 ERP |description=ERP на власному сервері: що таке on-premise ERP, коли варто розгортати ERP локально, вимоги до серверів, мережі, СУБД, backup, бе... |
R (обговорення | внесок) Немає опису редагування |
||
| Рядок 1: | Рядок 1: | ||
ERP на власному сервері має мати план аварійного відновлення.; це модель розміщення [[ERP]]-системи.; Обмеження | |||
== Помилка: не перевірити відновлення == | |||
↓ | |||
Погані підходи: | |||
!;[[Категорія:Роль BAS]] | |||
* копія пошкоджена; | |||
* не вистачає файлів; | |||
* не збережені сертифікати; | |||
* не функціонує СУБД; | |||
* не функціонує API; | |||
* не функціонує BI; | |||
* не збережені конфігурація.; __TOC__ | |||
Адміністративні права мають бути обмежені й контрольовані.; переважні аспекти | |||
* довідники; | |||
* контрагентів; | |||
* номенклатуру; | |||
* склади; | |||
* договори; | |||
* залишки; | |||
* відкриті документи; | |||
* ціни; | |||
* серії; | |||
* характеристики; | |||
* взаєморозрахунки; | |||
* користувачів після аудиту; | |||
* ролі після перегляду; | |||
* інтеграційні сценарії; | |||
* звіти; | |||
* BI-показники; | |||
* архівні інформаційні дані за потреби.; Недоліки | |||
Користувачі → Корпоративна мережа / VPN / Web → Сервер 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%;" | ||
Потрібно знати: | |||
Приклад: | |||
Сервер застосунків виконує бізнес-логіку ERP.;== Продуктивність == | |||
| | Безпека має включати: | ||
[[Категорія:Хмарна ERP]] | |||
[[Категорія:Web-сервіси 1С]] | |||
Він має змогу бути потрібен для: | |||
== актуалізація ERP на власному сервері == | |||
!; |- | |||
| У чому перевага?; Зона | |||
Якщо ERP розміщується не в офісі, а в датацентрі, потрібно перевірити: | |||
Після запуску [[K2 ERP]] стара BAS/1С не повинна залишатися робочою системою.;<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;"> | |||
* | * аудиту; | ||
* | * безпеки; | ||
* | * розслідування помилок; | ||
* | * контролю користувачів; | ||
* | * контролю API; | ||
* | * контролю адміністраторів; | ||
* | * контролю інтеграцій; | ||
* | * аналізу продуктивності; | ||
* | * виявлення підозрілих дій.; |- | ||
| Сервери підготовлені | |||
| Стабільна робота ERP | |||
|- | |||
| СУБД налаштована | |||
| Зберігання даних і продуктивність | |||
|- | |||
| HTTPS увімкнено | |||
| Захист web-доступу | |||
|- | |||
| VPN налаштовано | |||
| Захист віддаленого доступу | |||
|- | |||
| Резервні копії працюють | |||
| Відновлення після аварії | |||
|- | |||
| Відновлення перевірено | |||
| Бекап має бути придатним | |||
|- | |||
| Користувачі створені | |||
| Персональна робота | |||
|- | |||
| Ролі налаштовані | |||
| Мінімально необхідний доступ | |||
|- | |||
| API захищено | |||
| Безпечні інтеграції | |||
|- | |||
| BI перевірено | |||
| Коректна аналітичні інструменти | |||
|- | |||
| Моніторинг функціонує | |||
| Раннє виявлення проблем | |||
|} | |||
API потрібно захищати окремо.; # Оновити production.;[[Категорія:K2]] | |||
* | * процесор; | ||
* | * оперативна пам’ять; | ||
* | * диски; | ||
* | * СУБД; | ||
* | * мережа; | ||
* | * кількість користувачів; | ||
* | * кількість документів; | ||
* | * складність звітів; | ||
* | * API-навантаження; | ||
* BI-запити; | |||
* | * резервне копіювання; | ||
* інтеграції; | |||
* | * фонові задачі; | ||
* | * індекси; | ||
* архівні інформаційні дані.; Варіант | |||
* | |||
* | |||
* | |||
* [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] | |||
У on-premise моделі відповідальність потрібно чітко розділити.; організація має змогу обрати: | |||
* входи; | |||
* помилки входу; | |||
* зміну документів; | |||
* зміну довідників; | |||
* експорт; | |||
* API-запити; | |||
* зміну ролей; | |||
* адміністративні дії; | |||
* помилки системи; | |||
* помилки інтеграцій.; Резервні копії — одна з найважливіших частин on-premise ERP.;[[Категорія:Заміна 1С]] | |||
[[Категорія:On-premise]] | |||
організація має змогу мати резервні копії, але ніколи не перевіряти їх відновлення.; # Визначити API та BI.; Це небезпечно, бо в аварійний момент має змогу виявитися, що: | |||
== Вступ == | |||
На продуктивність ERP на власному сервері впливають: | |||
Якщо ERP відкрита без захисту, ризики зростають.;== Типова технічна архітектура K2 ERP на власному сервері == | |||
* відключення електроенергії; | |||
* слабке охолодження; | |||
* крадіжка або фізичне пошкодження; | |||
* слабкий інтернет; | |||
* відсутність резервного каналу; | |||
* відсутність цілодобового моніторингу; | |||
* слабка фізична безпека; | |||
* недостатнє резервне копіювання.; Критерій | |||
== Приватна хмарна інфраструктура == | |||
== | |||
BI має змогу працювати на окремому сервері або разом із ERP.; |- | |||
| Чи є собою санкційні ризики у [[BAS]] і [[1С]]?; Порядок: | |||
<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;"> | |||
Така модель протилежна SaaS, де ERP функціонує як хмарний сервіс постачальника.; * чи створюється бекап; | |||
* чи немає помилок; | |||
* чи можна відновити базу; | |||
* чи відкривається ERP після відновлення; | |||
* чи працюють користувачі; | |||
* чи працюють API; | |||
* чи працюють BI; | |||
* чи збережені файли; | |||
* чи працюють інтеграції; | |||
* скільки часу займає відновлення.; Хмарна ERP має змогу бути кращою, якщо: | |||
Він має описувати: | |||
{| class="wikitable" style="width:100%;" | |||
== | * довідники; | ||
* документи; | |||
* регістри; | |||
* залишки; | |||
* рухи; | |||
* користувачі; | |||
* ролі; | |||
* журнали; | |||
* конфігурація; | |||
* історичний розвиток; | |||
* API-дані; | |||
* BI-дані; | |||
* службові таблиці.;== Технічний супровід == | |||
== Датацентр == | |||
== Web-сервер == | |||
Сервісні користувачі потрібні для інтеграцій.;== Безпека ERP на власному сервері == | |||
Під час переходу з [[BAS]] або [[1С]] на [[K2 ERP]] на власному сервері потрібно не тільки перенести довідники, документи й залишки, а й переосмислити всю інфраструктуру: користувачів, ролі, API, BI, резервні копії, web-доступ, інтеграції, архіви, моніторинг і безпеку.; |- | |||
| Що обов’язково потрібно?;== Адміністратори == | |||
<syntaxhighlight lang="text"> | |||
== Архів старої BAS/1С == | |||
* тільки для перегляду; | |||
* без введення нових документів; | |||
* без активних інтеграцій; | |||
* без доступу звільнених користувачів; | |||
* із резервною копією; | |||
* з обмеженим доступом; | |||
* із журналом використання; | |||
* із чіткою назвою “Архів”.;[[Категорія:JSON 1С]] | |||
!; !; # Налаштувати моніторинг.; |- | |||
| Чи можна розгорнути [[K2 ERP]] на власному сервері?; Хмарна ERP | |||
== Що не переносити == | |||
[[Категорія:Заміна BAS]] | |||
== Масштабування == | |||
== СУБД == | |||
↓ | |||
Під час переходу з [[BAS]] або [[1С]] на [[K2 ERP]] на власному сервері потрібно врахувати не тільки інформаційні дані, а й інфраструктуру.; * логінів; | |||
* паролів; | |||
* документів; | |||
* персональних даних; | |||
* фінансових даних; | |||
* API-запитів; | |||
* BI-звітів; | |||
* токенів.; BI має змогу бути розміщений: | |||
ERP на власному сервері має підтримувати чітку модель користувачів.;== SLA == | |||
!;== Правило 3-2-1 == | |||
</div> | |||
[[Категорія: | [[Категорія:Автоматизація бізнесу]] | ||
* старі сервери BAS/1С; | |||
* файлові бази; | |||
* | * клієнт-серверні бази; | ||
* | * СУБД; | ||
* | * web-публікації; | ||
* 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 | * версію СУБД; | ||
* | * версію міграційних пакетів; | ||
* | * дату актуалізація; | ||
* | * список змін; | ||
* | * відповідального за актуалізація.; # Перевірити 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]], інтеграції, журналювання, кібербезпеку, адміністрування і підтримку.; * віддалених працівників; | |||
* філій; | |||
* бухгалтерії; | |||
* керівників; | |||
* адміністраторів; | |||
* інтеграторів; | |||
* зовнішніх консультантів.;== Сервер бази даних == | |||
</syntaxhighlight> | |||
!; |- | |||
| Сервери | |||
| організація або ІТ-підрядник | |||
|- | |||
| СУБД | |||
| DBA або адміністратор | |||
|- | |||
| Резервні копії | |||
| ІТ-служба / підрядник | |||
|- | |||
| актуалізація K2 ERP | |||
| Постачальник / впроваджувач / адміністратор | |||
|- | |||
| Користувачі й ролі | |||
| Адміністратор ERP | |||
|- | |||
| API | |||
| Інтегратор / адміністратор | |||
|- | |||
| BI | |||
| Аналітик / адміністратор BI | |||
|- | |||
| Безпека | |||
| ІТ-служба / служба безпеки | |||
|} | |||
Потрібно налаштувати: | |||
!; Для чого | |||
як ілюстрація: | |||
== Файлове сховище == | |||
[[Категорія:Моніторинг]] | |||
[[Категорія:Сервер ERP]] | |||
== RPO і RTO == | |||
== Висновок == | |||
Потрібно проаналізувати: | |||
== | '''істотно про BAS і 1С.''' [[BAS]] та [[1С]] мають санкційні, юридичні й кібербезпекові ризики в Україні.;== Журналювання == | ||
== Власний датацентр == | |||
== Сервісні користувачі == | |||
== API-шлюз == | |||
|- | |||
| Що таке ERP на власному сервері?; Правильний порядок: | |||
[[Категорія:Українське програмне забезпечення]] | |||
{| class="wikitable" style="width:100%;" | |||
* втрата документів; | |||
* | * втрата залишків; | ||
* | * втрата фінансових даних; | ||
* | * зупинка бізнесу; | ||
* | * неможливість відновлення; | ||
* втрати через людську помилку; | |||
* втрати через технічну аварію; | |||
* втрати через кібератаку.; Сервер | |||
Для ERP на власному сервері бажано мати тестове середовище.;== Що таке on-premise ERP == | |||
ERP | |||
Потрібно періодично перевіряти: | |||
* 3 копії даних; | |||
* 2 різні носії або сховища; | |||
* 1 копія поза основним майданчиком.;== Моніторинг == | |||
[[Категорія:On-premise ERP]] | |||
[[Категорія: | |||
'''Підхід K2 ERP.''' [[K2 ERP]] має змогу розгортатися у власній інфраструктурі компанії, якщо бізнесу потрібен контроль серверів, СУБД, резервних копій, API, BI, інтеграцій, доступів, журналювання, оновлень і політик безпеки.; Коментар | |||
!;[[Категорія:JSON]] | |||
== | == Файлові обміни == | ||
* хмарну ERP; | |||
* ERP на власному сервері; | |||
* ERP у приватному датацентрі; | |||
* гібридну модель; | |||
* SaaS-модель; | |||
* on-premise-модель.;[[Категорія:ERP]] | |||
* | * HTTPS; | ||
* IP | * VPN або обмеження IP; | ||
* | * сильні паролі; | ||
* | * журналювання; | ||
* | * обмеження ролей; | ||
* | * захист API; | ||
* моніторинг; | |||
* регулярні актуалізація.; # Визначити кількість користувачів.; Що означає | |||
* | |||
* | |||
[[Категорія:Оновлення BAS]] | |||
== Як не треба робити == | |||
* локальна WMS; | |||
* локальна CRM; | |||
* банківський замовник; | |||
* касове обладнання; | |||
* ваги; | |||
* обладнання складу; | |||
* SCADA; | |||
* виробничі системи; | |||
* GPS; | |||
* телефонія; | |||
* файлові обміни; | |||
* старі BAS/1С-бази; | |||
* BI-сервер.; як ілюстрація: | |||
|- | |||
| Контроль інфраструктури | |||
| Максимальний контроль у компанії | |||
| Більше відповідальності у постачальника | |||
|- | |||
| Старт | |||
| Потрібне конфігурація серверів | |||
| Зазвичай швидший | |||
|- | |||
| Адміністрування | |||
| Потрібна ІТ-команда | |||
| Частково або в цілому на постачальнику | |||
|- | |||
| Резервні копії | |||
| Відповідальність компанії або ІТ-партнера | |||
| Часто входять у сервіс | |||
|- | |||
| Безпека | |||
| Залежить від внутрішньої ІТ-дисципліни | |||
| Залежить від постачальника і договору | |||
|- | |||
| Інтеграції | |||
| комфортно для локальних систем | |||
| комфортно для web/API-сервісів | |||
|- | |||
| Масштабування | |||
| Потрібно планувати ресурси | |||
| Зазвичай простіше | |||
|- | |||
| Вартість | |||
| Сервери, адміністрування, супровід | |||
| Підписка або сервісна модель | |||
|} | |||
Web-сервер потрібен для доступу через браузер.; Навіщо | |||
!;</div> | |||
!; ERP на власному сервері має змогу бути частиною цифрової незалежності.; Окремі продукти [[1С]] і [[BAS]] внесені до відкритих переліків програмного забезпечення, забороненого до використання для окремих категорій організацій.; # Спроєктувати серверну архітектуру.; Питання | |||
!; Сервер K2 ERP | |||
Це має змогу бути: | |||
'''ERP на власному сервері''' — це варіант впровадження, коли ERP-система встановлюється і функціонує на інфраструктурі, яку контролює сама організація або її ІТ-підрядник.; | Так, якщо бізнесу потрібен контроль інфраструктури, СУБД, API, BI, інтеграцій і безпеки.; # Зафіксувати версію.; з цієї причини перехід на [[K2 ERP]] на власному сервері має змогу бути частиною стратегії цифрової незалежності, контролю даних і відмови від старої ризикової екосистеми.;== План аварійного відновлення == | |||
[[Категорія:Права доступу]] | |||
[[Категорія:API]] | |||
* | * обробку запитів користувачів; | ||
* | * роботу web-інтерфейсу; | ||
* | * проведення документів; | ||
* | * бізнес-процеси; | ||
* | * права доступу; | ||
* | * API; | ||
* | * фонові задачі; | ||
* | * регламентні процеси; | ||
* інтеграції; | |||
* журналювання; | |||
* перевірки даних.; Хто відповідає | |||
* фізичний сервер в офісі; | |||
* сервер у власному датацентрі; | |||
* віртуальна машина; | |||
* приватна хмарна інфраструктура; | |||
* орендований виділений сервер; | |||
* корпоративний кластер; | |||
* інфраструктура в датацентрі під контролем компанії.; # Визначити модулі [[K2 ERP]].; !; * старий хаотичний код; | |||
* неактуальні обробки; | |||
* спільні логіни; | |||
* зайві ролі; | |||
* старі інтеграції під admin; | |||
* дублікати довідників; | |||
* тестові бази; | |||
* помилкові залишки; | |||
* небезпечні web-публікації; | |||
* хаотичні файлові обміни; | |||
* неактуальні архіви; | |||
* санкційно ризикову залежність.; Роль | |||
!; * серверами; | |||
* СУБД; | |||
* користувачами; | |||
* ролями; | |||
* резервними копіями; | |||
* оновленнями; | |||
* журналами; | |||
* інтеграціями; | |||
* API; | |||
* BI; | |||
* web-сервером; | |||
* безпекою.; * [[K2]] | |||
* [[K2 ERP]] | * [[K2 ERP]] | ||
* [[ERP]] | * [[ERP]] | ||
* [[ERP | * [[Ліцензування K2 ERP]] | ||
* [[Версія K2 ERP]] | |||
* [[Оновлення K2 ERP]] | |||
* [[Користувач K2 ERP]] | |||
* [[Ролі K2 ERP]] | |||
* [[Права доступу]] | |||
* [[API]] | |||
* [[BI]] | |||
* [[Журналювання]] | |||
* [[Резервна копія]] | |||
* [[SaaS]] | |||
* [[On-premise]] | |||
* [[Хмарна ERP]] | * [[Хмарна ERP]] | ||
* [[ | * [[Міграція з BAS]] | ||
* [[Міграція з 1С]] | * [[Міграція з 1С]] | ||
* [[Заміна BAS]] | * [[Заміна BAS]] | ||
* [[Заміна 1С]] | |||
* [[BAS]] | * [[BAS]] | ||
* [[1С]] | * [[1С]] | ||
* [[ | * [[Оновлення BAS]] | ||
* [[BAS | * [[Конфігурація BAS]] | ||
* [[BAS | * [[Користувач BAS]] | ||
* [[BAS | * [[Роль BAS]] | ||
* [[BAS | * [[Веб-клієнт BAS]] | ||
* [[Клієнт-серверний режим BAS]] | |||
* [[Файловий режим BAS]] | |||
* [[Web-сервіси 1С]] | |||
* [[JSON 1С]] | |||
* [[Інтеграція з BAS]] | |||
* [[Інтеграція з 1С]] | |||
* [[Інтеграція через файли]] | |||
* [[Інтеграція через XML]] | |||
* [[SQL]] | |||
* [[JSON]] | |||
* [[XML]] | |||
* [[CSV]] | |||
* [[Українське програмне забезпечення]] | * [[Українське програмне забезпечення]] | ||
* [[Автоматизація бізнесу]] | |||
* [[Цифрова незалежність]] | * [[Цифрова незалежність]] | ||
* [[Деколонізація обліку]] | |||
!; {| class="wikitable" style="width:100%;" | |||
як ілюстрація: | |||
<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;"> | |||
'''Головне.''' ERP на власному сервері дає компанії більше контролю над даними, інфраструктурою, доступами, інтеграціями та безпекою, але вимагає відповідальності за сервери, резервні копії, актуалізація, моніторинг, кібербезпеку і технічну підтримку.; Адміністратори ERP на власному сервері мають особливу відповідальність.; | організація або її ІТ-партнер відповідає за сервери, СУБД, бекапи, актуалізація, моніторинг і аварійне відновлення.; Такий підхід часто називають '''on-premise ERP''', '''локальна ERP''', '''ERP на сервері компанії''' або '''ERP у власній інфраструктурі'''.; # Налаштувати користувачів і ролі.; Призначення | |||
* консультації; | |||
[[Категорія: | * актуалізація; | ||
* виправлення помилок; | |||
* аналіз журналів; | |||
* перевірку продуктивності; | |||
* підтримку інтеграцій; | |||
* підтримку API; | |||
* підтримку BI; | |||
* допомогу з резервними копіями; | |||
* консультації з СУБД; | |||
* допомогу при аваріях; | |||
* супровід міграції; | |||
* навчання адміністраторів.; * більше оперативної пам’яті; | |||
* швидші диски; | |||
* окремий сервер СУБД; | |||
* окремий сервер BI; | |||
* окремий API-сервер; | |||
* балансування навантаження; | |||
* архівування старих даних; | |||
* оптимізація запитів; | |||
* збільшення мережевої пропускної здатності; | |||
* резервний сервер.; Після переходу стара BAS/1С має змогу залишитися як архів.; Не можна використовувати адміністратора для інтеграцій.; # Налаштувати журналювання.; !;[[Категорія:Версія K2 ERP]] | |||
актуалізація потрібно виконувати контрольовано.;[[Категорія:Інтеграція]] | |||
Резервне копіювання + BI + Архів | |||
== BI на власному сервері == | |||
Приклади: | |||
СУБД — це платформа керування базами даних.;== Помилка: відкрити ERP напряму в інтернет == | |||
== Фізичний сервер чи віртуальна машина == | |||
!;[[Категорія:Користувач K2 ERP]] | |||
== | ERP-система є собою центральною інформаційною системою підприємства.;== Як правильно впроваджувати ERP на власному сервері == | ||
* договори; | |||
* скани документів; | |||
* рахунки; | |||
* акти; | |||
* накладні; | |||
* сертифікати; | |||
* зображення товарів; | |||
* імпортні файли; | |||
* експортні файли; | |||
* вкладення; | |||
* архіви; | |||
* резервні копії; | |||
* логи.; Доступ | |||
!; | !; # Описати бізнес-вимоги.; У результаті власний сервер стає не перевагою, а критичною точкою ризику.;== Архівування == | ||
Сервер бази даних зберігає основні інформаційні дані ERP.; # Запланувати вікно актуалізація.;== Див.; додатково == | |||
[[Категорія:СУБД]] | |||
== Помилка: залишити BAS/1С активною після переходу == | |||
* базу даних; | |||
* файлове сховище; | |||
* конфігурацію; | |||
* конфігурація; | |||
* сертифікати; | |||
* API-ключі; | |||
* BI-вітрини; | |||
* web-сервер; | |||
* скрипти; | |||
* документацію; | |||
* журнали; | |||
* інтеграційні файли.; Він має змогу забезпечувати: | |||
HTTPS захищає передачу: | |||
↓ | |||
''' | * що робити при поломці сервера; | ||
* що робити при пошкодженні бази; | |||
* що робити при кібератаці; | |||
* що робити при втраті інтернету; | |||
* що робити при втраті електроживлення; | |||
* хто відповідальний; | |||
* де резервні копії; | |||
* як відновити систему; | |||
* як перевірити інформаційні дані; | |||
* як повідомити користувачів; | |||
* який допустимий час простою.; # Перевірити відновлення.; Потрібно продумати: | |||
ERP на власному сервері потрібно моніторити.; Приватна хмарна інфраструктура має змогу бути компромісом між on-premise і SaaS.; '''Критично.''' ERP на власному сервері не можна відкривати назовні без HTTPS, сильних паролів, обмеження доступу, журналювання, резервних копій і контролю безпеки.; # Перевірити ролі.;<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;"> | |||
== Коли ERP на власному сервері доречна == | |||
ERP на власному сервері має змогу | * на з цієї причини самому сервері; | ||
* на окремому сервері; | |||
* у хмарі; | |||
* у гібридній моделі; | |||
* як окрема аналітична база; | |||
* як вітрина даних.; # Зробити резервну копію.; Вона відповідає за: | |||
З урахуванням санкційних, юридичних і кібербезпекових ризиків [[BAS]] та [[1С]], перехід на [[K2 ERP]] на власному сервері має змогу стати частиною ширшої стратегії цифрової незалежності, контролю даних, українського програмного забезпечення і сучасної ERP-архітектури.; | Це модель, коли ERP функціонує на серверах компанії або в інфраструктурі, яку організація контролює.; !; |- | |||
| Що істотно при міграції з BAS/1С?; |- | |||
| Як ще називається така модель?; Модель | |||
= | <div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;"> | ||
Кожен користувач системи має отримати тільки ті права, які потрібні для роботи.; |} | |||
!; Для ERP істотно визначити два показники.; # Перевірити бізнес-сценарії.; Потрібно резервувати: | |||
Найчастіші помилки: | |||
Користувачі можуть працювати через: | |||
* | * XML; | ||
* | * JSON; | ||
* | * CSV; | ||
* | * Excel; | ||
* | * ZIP; | ||
* | * PDF; | ||
* | * банківські файли; | ||
* | * файли постачальників; | ||
* | * файли маркетплейсів.;== Доступ користувачів == | ||
<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;"> | |||
[[Категорія:Цифрова незалежність України]] | |||
== Порівняння власного сервера і хмари == | |||
!; | Так.; Старі інформаційні дані можуть впливати на продуктивність.; !; '''On-premise ERP''' — це міжнародна назва моделі, коли ERP розміщується “на майданчику” клієнта або в інфраструктурі, яку замовник контролює.; # Перевірити BI.; Резервна копія має сенс тільки тоді, коли її можна відновити.;</div> | |||
== VPN == | |||
переважні аспекти: | |||
ERP | # Прочитати release notes.;== ERP на власному сервері і міграція з BAS/1С == | ||
== Сервер застосунків == | |||
Потрібно контролювати: | |||
[[Категорія:BAS]] | |||
↓ | |||
[[Категорія:Журналювання]] | |||
[[Категорія:BI]] | |||
== Власний сервер в офісі == | |||
[[Категорія:Міграція з 1С]] | |||
<syntaxhighlight lang="text"> | |||
У ERP на власному сервері — це не без ускладнень “поставити програму на сервер”.; ERP на власному сервері має змогу бути доречною, якщо: | |||
* запуск ERP на слабкому сервері; | |||
* відсутність резервних копій; | |||
* резервні копії не перевіряються; | |||
* ERP відкрита в інтернет без захисту; | |||
* немає HTTPS; | |||
* немає VPN; | |||
* усі мають адміністративні права; | |||
* API функціонує під admin; | |||
* немає моніторингу; | |||
* немає тестового середовища; | |||
* немає плану відновлення; | |||
* немає відповідального адміністратора; | |||
* актуалізація ставляться одразу в production; | |||
* BI перевантажує основну базу; | |||
* старі BAS/1С-інтеграції залишені активними.; Потрібно журналювати: | |||
Потрібні: | |||
BI має змогу показувати: | |||
* які інформаційні дані залишати в робочій базі; | |||
* які переносити в архів; | |||
* як відкривати архів; | |||
* хто має доступ; | |||
* чи потрібен пошук; | |||
* чи потрібні звіти по архіву; | |||
* як зберігати документи; | |||
* як резервувати архів.; # Оновити тестове середовище.;== Версійність == | |||
* | * сервер застосунків; | ||
* сервер бази даних; | |||
* СУБД; | * СУБД; | ||
* файлове сховище; | * файлове сховище; | ||
* | * web-сервер; | ||
* | * API-шлюз; | ||
* мережевий | * BI-сервер або BI-вітрини; | ||
* сервер резервного копіювання; | |||
* моніторинг; | |||
* платформа журналювання; | |||
* мережевий захист; | |||
* VPN; | * VPN; | ||
* платформа оновлень; | |||
* тестове середовище; | |||
* архівне середовище.; {| class="wikitable" style="width:100%;" | |||
|- | |||
| RPO | |||
| Скільки даних можна втратити | |||
| Не більше 1 години | |||
|- | |||
| RTO | |||
| За скільки часу потрібно відновити систему | |||
| Не більше 4 годин | |||
|} | |||
Потрібно визначити: | |||
== Що переносити з BAS/1С == | |||
SLA має змогу визначати: | |||
</div> | |||
* доступність сервера; | |||
* навантаження CPU; | |||
* пам’ять; | |||
* диски; | |||
* місце на диску; | |||
* СУБД; | |||
* час відповіді; | |||
* API; | * API; | ||
* | * web-сервер; | ||
* | * BI-оновлення; | ||
* | * резервні копії; | ||
* | * помилки; | ||
* | * журнали; | ||
* активних користувачів; | |||
* підозрілу активність.; супровід ERP на власному сервері має змогу включати: | |||
[[Категорія:K2 ERP]] | |||
Для резервного копіювання часто використовують підхід 3-2-1: | |||
* сайт; | |||
* CRM; | |||
* WMS; | |||
* банк; | |||
* мобільний застосунок; | |||
* BI; | |||
* маркетплейс; | |||
* електронний електронний документообіг; | |||
* платформа доставки; | |||
* внутрішній портал; | |||
* виробниче обладнання.; | Резервні копії, перевірка відновлення, HTTPS, VPN або обмеження доступу, ролі, журналювання, моніторинг і тестова база.;[[Категорія:Ліцензування K2 ERP]] | |||
↓ | |||
* локальну мережу; | |||
* VPN; | |||
* доступ філій; | |||
* доступ віддалених користувачів; | |||
* пропускну здатність; | |||
* затримки; | |||
* резервний інтернет; | |||
* міжмережеві екрани; | |||
* сегментацію мережі; | |||
* доступ до СУБД; | |||
* доступ до API; | |||
* доступ до резервних копій.; # Налаштувати HTTPS.;== Користувачі і ролі == | |||
* web-інтерфейс; | |||
* локальну мережу; | |||
* VPN; | |||
* віддалений робочий стіл; | |||
* корпоративний браузер; | |||
* мобільні сценарії; | |||
* API-клієнти; | |||
* BI-панелі.; має змогу знадобитися: | |||
Через API можуть працювати: | |||
</syntaxhighlight> | |||
API потрібно захищати: | |||
СУБД | |||
* | * клієнти; | ||
* | * постачальники; | ||
* | * договори; | ||
* | * замовлення; | ||
* | * склади; | ||
* через | * залишки; | ||
* | * ціни; | ||
* | * закупівельна діяльність; | ||
* продажі та реалізація; | |||
* виробництво; | |||
* фінансовий блок; | |||
* каса; | |||
* банк; | |||
* зарплата; | |||
* кадри; | |||
* собівартість; | |||
* податкова відомості; | |||
* управлінська аналітичні інструменти; | |||
* документи; | |||
* персональні інформаційні дані; | |||
* інтеграційні ключі; | |||
* API-токени; | |||
* журнали дій.; | Більший контроль над даними, серверами, доступами, інтеграціями, резервними копіями й безпекою.;[[Категорія:Кібербезпека]] | |||
компаній забезпечується через У випадку [[K2 ERP]] розміщення на власному сервері має змогу бути доречним; додатково реалізовано які мають підвищені вимоги до контролю даних, внутрішньої безпеки, інтеграцій з локальними системами, регуляторних обмежень, роботи у власному датацентрі, корпоративних політик ІТ або бажають в цілому контролювати серверну інфраструктуру.; {| class="wikitable" style="width:100%;" | |||
!; * ставити ERP на випадковий офісний комп’ютер; | |||
* не мати резервних копій; | |||
* не мати тестової бази; | |||
* не мати плану відновлення; | |||
* не контролювати доступи; | |||
* не налаштувати HTTPS; | |||
* не обмежити API; | |||
* не розділити ролі; | |||
* не моніторити сервер; | |||
* не документувати інфраструктуру; | |||
* не перевіряти BI-навантаження; | |||
* не вимкнути старі BAS/1С-інтеграції; | |||
* ігнорувати санкційні й кібербезпекові ризики.; # Запустити production.; * немає власної ІТ-команди; | |||
* потрібен швидкий старт; | |||
* не хочеться адмініструвати сервери; | |||
* важлива прогнозована підписка; | |||
* потрібне автоматичне актуалізація; | |||
* потрібна проста масштабованість; | |||
* організація не хоче підтримувати СУБД; | |||
* потрібен доступ із різних локацій; | |||
* немає складних локальних інтеграцій; | |||
* бізнес-середовище хоче зосередитися на процесах, а не інфраструктурі.; * перевірки оновлень; | |||
* перевірки доробок; | |||
* навчання користувачів; | |||
* тестування інтеграцій; | |||
* перевірки API; | |||
* перевірки BI; | |||
* тестової міграції; | |||
* відпрацювання аварійного відновлення.; # Налаштувати резервні копії.; Відповідь | |||
Потрібно вирішити: | |||
== | !;== Резервні копії == | ||
[[Категорія:Деколонізація обліку]] | |||
== Мережа == | |||
* документи вводяться у дві системи; | |||
* сайт читає старі залишки; | |||
* BI бере старі інформаційні дані; | |||
* користувачі не розуміють, де правильна відомості; | |||
* інтеграції працюють паралельно; | |||
* джерело істини зникає.; '''Найгірший сценарій.''' організація переносить ERP на власний сервер, але не налаштовує резервні копії, HTTPS, VPN, моніторинг, ролі, API-захист і план відновлення.;{{DISPLAYTITLE:ERP на власному сервері}} | |||
У базі можуть бути: | |||
== ERP на власному сервері і цифрова незалежність == | |||
Для | Для ERP СУБД є собою критично важливою частиною інфраструктури.; |- | ||
| У чому недолік?; * HTTPS; | |||
* маршрутизацію запитів; | |||
* web-інтерфейс; | |||
* API; | |||
* статичні файли; | |||
* журнали доступу; | |||
* обмеження 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 розміщується не в офісі, а в датацентрі, потрібно перевірити: Після запуску K2 ERP стара BAS/1С не повинна залишатися робочою системою.;
|
Сервери підготовлені | Стабільна робота ERP |
|---|---|---|---|
| СУБД налаштована | Зберігання даних і продуктивність | ||
| HTTPS увімкнено | Захист web-доступу | ||
| VPN налаштовано | Захист віддаленого доступу | ||
| Резервні копії працюють | Відновлення після аварії | ||
| Відновлення перевірено | Бекап має бути придатним | ||
| Користувачі створені | Персональна робота | ||
| Ролі налаштовані | Мінімально необхідний доступ | ||
| API захищено | Безпечні інтеграції | ||
| BI перевірено | Коректна аналітичні інструменти | ||
| Моніторинг функціонує | Раннє виявлення проблем |
API потрібно захищати окремо.; # Оновити production.;
- процесор;
- оперативна пам’ять;
- диски;
- СУБД;
- мережа;
- кількість користувачів;
- кількість документів;
- складність звітів;
- API-навантаження;
- BI-запити;
- резервне копіювання;
- інтеграції;
- фонові задачі;
- індекси;
- архівні інформаційні дані.; Варіант
- Сайт K2 ERP
- Wiki K2 ERP
- хмарна інфраструктура K2 ERP
- Перелік забороненого до використання програмного забезпечення на сайті Держспецзв’язку
- Роз’яснення Держспецзв’язку щодо переліку забороненого ПЗ
- Указ Президента України №601/2024
- Указ Президента України №601/2024 на сайті Верховної Ради України
- Telegram-канал K2 ERP
- Група обговорення функціоналу та пропозицій
- LinkedIn K2
У 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 на власному сервері?; Правильний порядок:
- втрата документів;
- втрата залишків;
- втрата фінансових даних;
- зупинка бізнесу;
- неможливість відновлення;
- втрати через людську помилку;
- втрати через технічну аварію;
- втрати через кібератаку.; Сервер
- 3 копії даних;
- 2 різні носії або сховища;
- 1 копія поза основним майданчиком.;== Моніторинг ==
;
Файлові обміни
Як не треба робити
| ||
|---|---|---|
| Контроль інфраструктури | Максимальний контроль у компанії | Більше відповідальності у постачальника |
| Старт | Потрібне конфігурація серверів | Зазвичай швидший |
| Адміністрування | Потрібна ІТ-команда | Частково або в цілому на постачальнику |
| Резервні копії | Відповідальність компанії або ІТ-партнера | Часто входять у сервіс |
| Безпека | Залежить від внутрішньої ІТ-дисципліни | Залежить від постачальника і договору |
| Інтеграції | комфортно для локальних систем | комфортно для web/API-сервісів |
| Масштабування | Потрібно планувати ресурси | Зазвичай простіше |
| Вартість | Сервери, адміністрування, супровід | Підписка або сервісна модель |
Web-сервер потрібен для доступу через браузер.; Навіщо
!;!; ERP на власному сервері має змогу бути частиною цифрової незалежності.; Окремі продукти 1С і BAS внесені до відкритих переліків програмного забезпечення, забороненого до використання для окремих категорій організацій.; # Спроєктувати серверну архітектуру.; Питання
!; Сервер K2 ERP Це має змогу бути: ERP на власному сервері — це варіант впровадження, коли ERP-система встановлюється і функціонує на інфраструктурі, яку контролює сама організація або її ІТ-підрядник.; | Так, якщо бізнесу потрібен контроль інфраструктури, СУБД, API, BI, інтеграцій і безпеки.; # Зафіксувати версію.; з цієї причини перехід на K2 ERP на власному сервері має змогу бути частиною стратегії цифрової незалежності, контролю даних і відмови від старої ризикової екосистеми.;== План аварійного відновлення ==
- обробку запитів користувачів;
- роботу web-інтерфейсу;
- проведення документів;
- бізнес-процеси;
- права доступу;
- API;
- фонові задачі;
- регламентні процеси;
- інтеграції;
- журналювання;
- перевірки даних.; Хто відповідає
- фізичний сервер в офісі;
- сервер у власному датацентрі;
- віртуальна машина;
- приватна хмарна інфраструктура;
- орендований виділений сервер;
- корпоративний кластер;
- інфраструктура в датацентрі під контролем компанії.; # Визначити модулі K2 ERP.; !; * старий хаотичний код;
- неактуальні обробки;
- спільні логіни;
- зайві ролі;
- старі інтеграції під admin;
- дублікати довідників;
- тестові бази;
- помилкові залишки;
- небезпечні web-публікації;
- хаотичні файлові обміни;
- неактуальні архіви;
- санкційно ризикову залежність.; Роль
!; * серверами;
- СУБД;
- користувачами;
- ролями;
- резервними копіями;
- оновленнями;
- журналами;
- інтеграціями;
- API;
- BI;
- web-сервером;
- безпекою.; * K2
- K2 ERP
- ERP
- Ліцензування K2 ERP
- Версія K2 ERP
- Оновлення K2 ERP
- Користувач K2 ERP
- Ролі K2 ERP
- Права доступу
- API
- BI
- Журналювання
- Резервна копія
- SaaS
- On-premise
- Хмарна ERP
- Міграція з BAS
- Міграція з 1С
- Заміна BAS
- Заміна 1С
- BAS
- 1С
- Оновлення BAS
- Конфігурація BAS
- Користувач BAS
- Роль BAS
- Веб-клієнт BAS
- Клієнт-серверний режим BAS
- Файловий режим BAS
- Web-сервіси 1С
- JSON 1С
- Інтеграція з BAS
- Інтеграція з 1С
- Інтеграція через файли
- Інтеграція через XML
- SQL
- JSON
- XML
- CSV
- Українське програмне забезпечення
- Автоматизація бізнесу
- Цифрова незалежність
- Деколонізація обліку
!; {| 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 на власному сервері доречна
- на з цієї причини самому сервері;
- на окремому сервері;
- у хмарі;
- у гібридній моделі;
- як окрема аналітична база;
- як вітрина даних.; # Зробити резервну копію.; Вона відповідає за:
З урахуванням санкційних, юридичних і кібербезпекових ризиків BAS та 1С, перехід на K2 ERP на власному сервері має змогу стати частиною ширшої стратегії цифрової незалежності, контролю даних, українського програмного забезпечення і сучасної ERP-архітектури.; | Це модель, коли ERP функціонує на серверах компанії або в інфраструктурі, яку організація контролює.; !; |- | Що істотно при міграції з BAS/1С?; |- | Як ще називається така модель?; Модель
Кожен користувач системи має отримати тільки ті права, які потрібні для роботи.; |}
!; Для ERP істотно визначити два показники.; # Перевірити бізнес-сценарії.; Потрібно резервувати:
Найчастіші помилки:
Користувачі можуть працювати через:
- XML;
- JSON;
- CSV;
- Excel;
- ZIP;
- PDF;
- банківські файли;
- файли постачальників;
- файли маркетплейсів.;== Доступ користувачів ==
Порівняння власного сервера і хмари
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-захист і план відновлення.;
У базі можуть бути:
ERP на власному сервері і цифрова незалежність
Для ERP СУБД є собою критично важливою частиною інфраструктури.; |- | У чому недолік?; * HTTPS;
- маршрутизацію запитів;
- web-інтерфейс;
- API;
- статичні файли;
- журнали доступу;
- обмеження IP;
- інтеграцію з корпоративною мережею;
- роботу через VPN або публічний домен.; # Провести навчання користувачів.; # Перевести старі BAS/1С-системи в архів.; == Перевірка відновлення ==