Ліцензування K2 ERP

Тестове середовище потрібне для: як ілюстрація: Потрібно знати:

Приклад модульного ліцензування

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

прибуток;
маржу;
собівартість;
зарплату;
фінансові показники;
інформаційні дані клієнтів;
комерційні умови;
персональні інформаційні дані.; Production — це основна робоча платформа.; BI має змогу містити фінансові, комерційні й персональні інформаційні дані.; Модулі можуть бути такими:

Активні користувачі	42	Ліцензовано 40	Переглянути активність
Сервісні акаунти	8	Частина не застосовується	Заблокувати зайві
BI-користувачі	12	Доступ до фінансів мають не всі потрібні ролі	Переглянути права
Тестові бази	4	Немає опису	Описати або видалити зайві
Старі BAS-бази	6	Невідомий статус	Перевести в архівний реєстр

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

Типові помилки в ліцензуванні

!; ліцензійний пакет дає право користування.; !; # Визначити потребу в оновленнях.; Воно має відповідати реальним бізнес-процесам, кількості користувачів, ролям, модулям, API, BI, інтеграціям, середовищам, підтримці, оновленням і вимогам безпеки.; Іменний користувач системи — це конкретна людина з персональним логіном.; # Визначити середовища: production, test, archive.; | Ні.;

одна юридична особа;
група компаній;
холдинг;
філіальна структура;
кілька ФОП;
кілька ТОВ;
різні країни або регіони.;== Навіщо потрібне ліцензування ==

Спільні логіни і ліцензування

сайт щохвилини читає залишки;
CRM створює замовлення;
WMS синхронізує складський облік;
BI щоночі оновлює інформаційні дані;
банк передає виписки;
мобільний застосунок використовує API.; Сервісні користувачі мають ліцензуватися і контролюватися окремо, якщо вони створюють навантаження або отримують доступ до даних.; # Визначити потрібні інтеграції.;

SLA

ліцензувати “на око”;
не рахувати сервісних користувачів;
не рахувати BI-користувачів;
не врахувати API;
не врахувати тестові середовища;
не врахувати архіви;
не врахувати інтеграції;
не заблокувати звільнених працівників;
залишити спільні логіни;
купити модулі без аналізу процесів;
не врахувати підтримку;
не врахувати актуалізація;
не перевірити права після міграції.;== Тестове середовище ==

власна платформа клієнта;
специфічний API;
галузева платформа;
старий файловий обмін;
проміжний сервіс;
міграційний шлюз із BAS.; Потрібні модулі

Ліцензування за модулями

яка реліз встановлена;
які модулі доступні;
які функції входять у пакет;
які API-методи доступні;
які BI-панелі доступні;
які актуалізація входять;
які зміни потребують додаткової ліцензії;
які модулі застарілі;
які функції додаються в нових версіях.; Краще:

Помилка: залишити спільні логіни

|- | Торгова організація | продажі та реалізація, закупівельна діяльність, складський облік, фінансовий блок, API | інтеграційні функціональні можливості із сайтом |- | Виробництво | складський облік, виробництво, фінансовий блок, BI | Контроль собівартості |- | Агробізнес | Агро, складський облік, техніка, паливо, BI | Поля, культури, сезони |- | Ресторанна мережа | Громадське харчування, складський облік, каса, закупівельна діяльність | Рецептури, списання, продажі та реалізація |}

У зрілій ERP-архітектурі зазвичай є собою кілька середовищ.; * сайт;

CRM;
WMS;
банк;
BI;
електронний електронний документообіг;
каси;
доставки.;== Зовнішні посилання ==

Правильний підхід. Ліцензування K2 ERP потрібно планувати від бізнес-процесів: які модулі потрібні, хто функціонує в системі, які ролі потрібні, які інтеграції будуть через API, кому потрібен BI, які середовища потрібні й який рівень підтримки необхідний.; | Не переносити стару модель користувачів як є собою, а побудувати нову модель ліцензій, ролей, модулів, API й BI.; !; організація повинна не механічно переносити стару кількість користувачів або стару модель доступу, а переосмислити, кому і який доступ реально потрібен: бухгалтерам, менеджерам, комірникам, керівникам, касирам, логістам, виробництву, інтеграціям, API-користувачам, BI-користувачам і адміністраторам.; # Розділити користувачів за ролями.;

!; * [[K2]]
* [[K2 ERP]]
* [[ERP]]
* [[Версія K2 ERP]]
* [[Оновлення K2 ERP]]
* [[Користувач K2 ERP]]
* [[Ролі K2 ERP]]
* [[Права доступу]]
* [[API]]
* [[BI]]
* [[Журналювання]]
* [[Резервна копія]]
* [[Міграція з BAS]]
* [[Міграція з 1С]]
* [[Заміна BAS]]
* [[Заміна 1С]]
* [[BAS]]
* [[1С]]
* [[Оновлення BAS]]
* [[Конфігурація BAS]]
* [[Користувач BAS]]
* [[Роль BAS]]
* [[Веб-клієнт BAS]]
* [[Клієнт-серверний режим BAS]]
* [[Файловий режим BAS]]
* [[Web-сервіси 1С]]
* [[JSON 1С]]
* [[Інтеграція з BAS]]
* [[Інтеграція з 1С]]
* [[Інтеграція через файли]]
* [[Інтеграція через XML]]
* [[SQL]]
* [[JSON]]
* [[XML]]
* [[CSV]]
* [[Українське програмне забезпечення]]
* [[Автоматизація бізнесу]]
* [[Цифрова незалежність]]
* [[Деколонізація обліку]]

!; Елемент ліцензування

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

'''Активний користувач системи''' — це користувач системи, який має право входити в систему.; !; це правила, за якими організація отримує право користуватися системою [[K2 ERP]], її модулями, користувачами, сервісами, [[API]], [[BI]]-аналітикою, інтеграціями, тестовими середовищами, підтримкою, оновленнями та іншими компонентами ERP-платформи виступає ключовою рисою '''Ліцензування K2 ERP'''.; * дату останнього входу;
* кількість входів;
* активні сеанси;
* використання модулів;
* запуск звітів;
* запуск API;
* експорт даних;
* використання BI;
* роботу сервісних акаунтів;
* невдалі входи;
* підозрілу активність.;</div>

{{SEO
|title=Ліцензування K2 ERP — користувачі, модулі, SaaS, on-premise, API, BI, підтримка і міграція з BAS
|description=Ліцензування K2 ERP: що таке ліцензія ERP-системи, моделі ліцензування, користувачі, ролі, модулі, SaaS, on-premise, API, BI, тестові середовища, підтримка, аудит ліцензій і перехід з BAS та 1С у K2 ERP.
|keywords=ліцензування K2 ERP, ліцензія K2 ERP, ліцензування ERP, користувачі K2 ERP, модулі K2 ERP, SaaS ERP, on-premise ERP, API K2 ERP, BI K2 ERP, підтримка K2 ERP, аудит ліцензій, міграція з BAS, міграція з 1С, заміна BAS, заміна 1С, українська ERP, санкції BAS, санкції 1С, цифрова незалежність
|image=https://erp.kyiv.ua
}}

* керівнику;
* аудитору;
* власнику бізнесу;
* консультанту;
* контролеру;
* зовнішньому користувачу;
* архівному доступу.;== Ліцензування оновлень ==

== Приклад міграційного пакета ==

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

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

* хто реально працював;
* хто змінив документ;
* хто експортував інформаційні дані;
* хто провів операцію;
* хто зробив помилку;
* чи всі користувачі ліцензовані коректно.;== Ліцензування за користувачами ==

* швидший старт;
* не потрібно власного сервера;
* простіше масштабування;
* централізовані актуалізація;
* менше технічного адміністрування;
* зручний web-доступ.;[[Категорія:K2]]

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

!; !; Ліцензування має змогу враховувати модулі, ролі, API, BI, середовища, інтеграції, підтримку і масштабування.; * хто має доступ;
* які користувачі активні;
* які ролі призначені;
* хто має admin-права;
* які API-ключі активні;
* хто має доступ до BI;
* хто бачить зарплату;
* хто бачить собівартість;
* хто має змогу експортувати інформаційні дані;
* хто має доступ до архіву;
* хто має змогу створювати користувачів.; Він має змогу бачити інформаційні дані, але не змінювати їх.; Середовище
!; Ліцензійна зміна
має змогу з’явитися:
організація має змогу порахувати тільки людей, які входять у систему, але забути:
Мобільні сценарії можуть бути окремою частиною ліцензії.; operator

Під час переходу з [[BAS]] у [[K2 ERP]] потрібно провести аудит старих користувачів, ролей, модулів, обробок, інтеграцій, BI-вивантажень, сервісних акаунтів, web-доступу й архівних баз.; Окремі продукти [[1С]] і [[BAS]] внесені до переліків забороненого програмного забезпечення для окремих категорій організацій в Україні.; * дату останнього входу;
* статус працівника;
* активні ролі;
* відкриті задачі;
* доступ до BI;
* доступ до API;
* доступ до архівів;
* сервісні токени;
* спільні логіни.; Призначення

Погано:
користувач системи тільки для перегляду має змогу бути потрібен:
Неактивні користувачі не повинні споживати ліцензії або створювати ризики.; !; # Визначити потребу в міграції з BAS/1С.; Тип ліцензії

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

== Що таке ліцензування K2 ERP ==
Правильний порядок:
[[Категорія:Кібербезпека]]
ERP-система застосовують, коли потрібно різними групами користувачів.; |-
| Базовий
| Малі компанії
| Консультації, базові актуалізація, типові питання
|-
| Стандартний
| Середній бізнес-середовище
| супровід користувачів, актуалізація, базові інтеграції
|-
| Розширений
| Компанії з критичними процесами
| SLA, інтеграції, моніторинг, пріоритетні заявки
|-
| Enterprise
| Великі компанії
| Індивідуальні умови, виділена команда, розширений SLA
|}

== Основні об’єкти ліцензування ==

<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">

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

* час реакції;
* час вирішення;
* критичність заявок;
* робочі години підтримки;
* канали звернення;
* відповідальних;
* правила ескалації;
* підтримку інтеграцій;
* підтримку production;
* підтримку тестових середовищ.; * хто їх підтримує роботу;
* чи сумісні вони з новими версіями;
* чи входить їх актуалізація в підтримку;
* хто тестує;
* як документуються зміни;
* чи впливають вони на API;
* чи впливають вони на BI;
* чи потрібен окремий договір.;<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">

<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
Перехід із [[BAS]] або [[1С]] має змогу ліцензуватися як окремий міграційний пакет або проєкт.; kovalenko.sklad

* консультації;
* виправлення помилок;
* актуалізація;
* допомогу користувачам;
* допомогу адміністраторам;
* аналіз журналів;
* моніторинг;
* допомогу з API;
* допомогу з BI;
* перевірку резервних копій;
* супровід інтеграцій;
* консультації з міграції.;== Ліцензування і права доступу ==

petrenko.buh
== Як не треба робити ==
ivanenko
[[Категорія:API]]
</div>
Але архів не повинен бути робочою системою.; Для кого

* [https://erp.kyiv.ua Сайт K2 ERP]
* [https://wiki.erp.kyiv.ua Wiki K2 ERP]
* [https://cloud.corp2.eu хмарна інфраструктура K2 ERP]
* [https://cip.gov.ua/ua/statics/perelik-zaboronenogo-do-vikoristannya-programnogo-zabezpechennya-ta-komunikaciinogo-merezhevogo-obladnannya Перелік забороненого до використання програмного забезпечення на сайті Держспецзв’язку]
* [https://cip.gov.ua/ua/news/vidpovidi-na-poshireni-zapitannya-shodo-pereliku-zaboronenogo-programnogo-zabezpechennya-ta-obladnannya Роз’яснення Держспецзв’язку щодо переліку забороненого ПЗ]
* [https://www.president.gov.ua/documents/6012024-52009 Указ Президента України №601/2024]
* [https://zakon.rada.gov.ua/go/601/2024 Указ Президента України №601/2024 на сайті Верховної Ради України]
* [https://t.me/+uIdWI1W6vndkMTAy Telegram-канал K2 ERP]
* [https://t.me/+6jFwAZM6TQliNTdi Група обговорення функціоналу та пропозицій]
* [https://www.linkedin.com/company/k2erp/ LinkedIn K2]

організація отримує можливість:
Ліцензування пов’язане з [[Версія K2 ERP|версією K2 ERP]].; | Не видавати всім повні права
|-
| Які модулі потрібні?; Потрібно визначити:

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

[[Категорія:K2 ERP]]
== Як правильно підходити до ліцензування K2 ERP ==
== Ліцензування і резервні копії ==
== Ліцензування за організаціями ==
|-
| Користувачі
| 25 активних користувачів
| У системі функціонує до 25 людей
|-
| Модулі
| продажі та реалізація, складський облік, фінансовий блок
| Підключені тільки потрібні блоки
|-
| API
| API для сайту
| Дозволено інтеграцію із зовнішнім сайтом
|-
| BI
| 5 BI-користувачів
| Доступ до аналітичних панелей для керівників
|-
| Середовище
| Production + Test
| є собою робоча і тестова база
|}

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

Спільні логіни погані для безпеки, журналювання і ліцензійного аудиту.; Особливість ліцензування
!; | Визначити базовий обсяг ліцензії
|-
| Які ролі потрібні?; |-
| Чи потрібно враховувати BI?; організація

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

!; |-
| Що істотно при міграції з BAS?; Для таких сценаріїв істотно визначити:

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

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

[[Категорія:Конфігурація BAS]]

* чи входять актуалізація в ліцензію;
* як часто виходять актуалізація;
* хто їх встановлює;
* чи є собою тестова база;
* чи є собою release notes;
* чи є собою changelog;
* хто перевіряє інтеграції;
* хто перевіряє BI;
* хто відповідає за відкат.;== Гібридна модель ==

== SaaS-ліцензування K2 ERP ==

* історичних даних;
* старих документів;
* перегляду даних після міграції;
* аудиту;
* звірок;
* юридичних потреб;
* старих BAS/1С-баз.; Питання

* аудит старої системи;
* аналіз конфігурації;
* аналіз користувачів;
* аналіз ролей;
* аналіз довідників;
* аналіз документів;
* аналіз інтеграцій;
* вивантаження даних;
* очищення даних;
* завантаження в [[K2 ERP]];
* контрольні звірки;
* навчання користувачів;
* запуск production;
* архівування старої BAS/1С.;== Ліцензування і масштабування ==

[[Категорія:Резервна копія]]

'''Головне.''' Ліцензування [[K2 ERP]] — це не тільки кількість користувачів.; Що охоплює
|-
| Користувачі
| Часто накопичені старі акаунти
| Потрібна чиста модель персональних користувачів
|-
| Ролі
| Можуть бути хаотичні або дороблені
| Варто будувати нову матрицю доступу
|-
| Інтеграції
| Часто через обробки, файли, web-сервіси
| Бажано через контрольований API
|-
| BI
| Часто зовнішні вивантаження або Excel
| Контрольований BI-доступ
|-
| актуалізація
| Можуть бути складні через доробки
| Потрібна прозора версійність і changelog
|-
| Санкційні ризики
| є собою для окремих продуктів BAS/1С
| Українська ERP-архітектура
|}

== Ліцензування і безпека ==

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

Ліцензійна модель має дозволяти поступове розширення.; Коментар
У такій моделі істотно визначити:
|-
| Аудит BAS
| Бази, конфігурації, користувачі, ролі, доробки
|-
| інформаційні дані
| Довідники, залишки, відкриті документи
|-
| Інтеграції
| Сайт, CRM, WMS, банк, BI
|-
| Навчання
| Користувачі, адміністратори, керівники
|-
| Запуск
| Тестова міграція, звірки, production
|-
| Архів
| Доступ до старих даних тільки для перегляду
|}

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

компонентна модель надає можливість підключати тільки потрібний функціональні можливості.; SLA — це домовленість про рівень сервісу.;[[Категорія:Оновлення BAS]]

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

== Ліцензування і впровадження ==

ERP має масштабуватися разом із бізнесом.; Питання

* бухгалтери;
* менеджери продажів;
* менеджери закупівель;
* комірники;
* касири;
* логісти;
* виробничі користувачі;
* кадровики;
* розраховувачі зарплати;
* керівники;
* фінансові директори;
* адміністратори;
* аудитори;
* зовнішні консультанти;
* сервісні API-користувачі;
* BI-користувачі;
* інтеграційні сервіси.; Окремі продукти [[1С]] і [[BAS]] внесені до відкритих переліків програмного забезпечення, забороненого до використання для окремих категорій організацій.; Одна з найпоширеніших моделей — ліцензування за кількістю користувачів.; * директор;
* фінансовий директор;
* керівник продажів;
* керівник складу;
* керівник виробництва;
* власник бізнесу;
* аналітик;
* аудитор.;[[Категорія:Заміна BAS]]

ліцензійний пакет API має змогу враховувати:

== Ліцензування підтримки ==

* кількість користувачів;
* кількість складів;
* кількість організацій;
* кількість документів;
* кількість API-запитів;
* кількість BI-користувачів;
* кількість інтеграцій;
* кількість філій;
* кількість мобільних користувачів;
* кількість середовищ.; |-
| Що таке сервісний користувач системи?; Що входить

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

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

== Ліцензування API ==

== Ліцензування і навчання ==

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

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

* тільки продажі та реалізація;
* тільки складський облік;
* тільки каса;
* тільки перегляд;
* тільки BI;
* тільки API;
* тільки одна організація;
* тільки один складський облік;
* тільки один підрозділ.;== Ліцензування архіву BAS/1С ==

Архівний доступ має змогу бути потрібен для:
Навчання має змогу включати:
{| class="wikitable" style="width:100%;"

[[Категорія:Деколонізація обліку]]
Ліцензування має чітко визначати, які середовища включені.; !; K2 ERP
|-
| ivanenko
| Менеджер продажів
| Іменна
|-
| petrenko.buh
| Бухгалтер
| Іменна
|-
| sklad.kyiv.01
| Комірник
| Іменна
|}

== Production-середовище ==

Архівний доступ бажано робити тільки для читання.; Ліцензування має змогу враховувати різні ролі.;[[Категорія:Права доступу]]

* хто адмініструє сервери;
* хто робить резервні копії;
* хто оновлює систему;
* хто відповідає за СУБД;
* хто контролює безпеку;
* хто підтримує роботу API;
* хто відповідає за доступи.; Роль

Потрібно регулярно перевіряти:

* користувачі;
* ролі;
* модулі;
* організації;
* підрозділи;
* склади;
* API;
* BI;
* інтеграції;
* середовища;
* база даних;
* хмарні ресурси;
* супровід;
* актуалізація;
* резервне копіювання;
* навчання;
* впровадження;
* міграційні пакети.; Інтеграції можуть створювати навантаження і потребувати окремого ліцензування.; !; |-
| Чи потрібно ліцензувати API?; Роль

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

!;== Приклад ліцензійного аудиту ==

'''Найгірший сценарій.''' організація переходить із [[BAS]] у [[K2 ERP]], але переносить старий хаос: спільні логіни, зайві користувачі, невідомі сервісні акаунти, API під адміністратором, BI без обмежень і модулі без аналізу реальних процесів.; * легального використання системи;
* контролю доступу;
* планування бюджету;
* масштабування ERP;
* розмежування модулів;
* контролю користувачів;
* підтримки безпеки;
* керування оновленнями;
* підтримки API;
* підтримки BI;
* організації технічної підтримки;
* розуміння, які сервіси входять у пакет;
* прогнозування розвитку системи.; '''On-premise''' — це модель, коли [[K2 ERP]] встановлюється на інфраструктурі клієнта.; | Врахувати інтеграції
|-
| Чи потрібен BI?; Потрібно знати:

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

[[Категорія:Модулі K2 ERP]]

Приклад:

* переносити кількість користувачів із BAS без аналізу;
* залишати старі спільні логіни;
* не рахувати сервісні акаунти;
* не рахувати API;
* не рахувати BI;
* не враховувати тестове середовище;
* не контролювати звільнених користувачів;
* не перевіряти модулі;
* не включати підтримку;
* не мати ліцензійного аудиту;
* не планувати масштабування;
* ігнорувати санкційні й кібербезпекові ризики BAS/1С.; Індивідуальні інтеграції:

BI-користувачі можуть бути:

У [[K2 ERP]] об’єктами ліцензування можуть бути:

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

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

== Ліцензування мобільних сценаріїв ==

* нова філія;
* новий складський облік;
* новий сайт;
* нова CRM;
* нова юридична особа;
* новий BI-напрям;
* новий відділ;
* нові користувачі;
* нові інтеграції.; '''Ліцензування [[K2 ERP]]''' — це набір правил і умов використання ERP-системи.;[[Категорія:Журналювання]]

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

== користувач системи тільки для перегляду ==

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

== Див.; додатково ==

ліцензійний пакет на систему і впровадження — це різні речі.;{{DISPLAYTITLE:Ліцензування K2 ERP}}

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

Неможливо зрозуміти:

* контроль відповідальності;
* правильне журналювання;
* безпеку;
* прозорий аудит ліцензій;
* можливість блокувати конкретного працівника.; актуалізація можуть входити в підписку або надаватися окремо.; | Не платити за зайвий функціональні можливості
|-
| Чи потрібен API?; {| class="wikitable" style="width:100%;"

'''Ліцензійний аудит''' — це перевірка фактичного використання системи.; | Безпечно оновлювати систему
|-
| Чи потрібен архів BAS?; Менеджеру продажів не потрібен повний бухгалтерський компонент.;== Активні й неактивні користувачі ==

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

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

У [[K2 ERP]] можуть працювати:

* аналіз процесів;
* конфігурація;
* міграцію;
* інтеграції;
* навчання;
* доробки;
* тестування;
* запуск;
* підтримку після старту.;[[Категорія:Підтримка]]

== Контрольний список для вибору ліцензії ==

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

Така модель має змогу бути зручною, якщо користувачі працюють позмінно.; |-
| Чи ліцензійний пакет — це тільки користувачі?; # Перевірити права після запуску.; Факт

Можливі рівні підтримки:

* API-користувачів;
* BI-користувачів;
* сервісні акаунти;
* тестових користувачів;
* аудиторів;
* зовнішніх консультантів;
* інтеграції;
* мобільні сценарії;
* архівний доступ.;<syntaxhighlight lang="text">
Ліцензування потрібне для:
Перевага іменних користувачів — прозоре журналювання і персональна відповідальність.; # Визначити BI-користувачів.; Потреба
Потрібно визначити:
Спільні логіни погані і з точки зору безпеки, і з точки зору ліцензування.; # Періодично проводити ліцензійний аудит.;== Приклад масштабування ==
|-
| Що таке ліцензування [[K2 ERP]]?; * сайту;
* CRM;
* WMS;
* мобільного застосунку;
* BI;
* маркетплейсів;
* банків;
* електронного документообігу;
* сервісів доставки;
* зовнішніх партнерів.; | Залежить від моделі, але API потрібно враховувати окремо, бо він створює доступ і навантаження.; | Врахувати аналітику
|-
| Чи потрібна тестова база?;== Коротко ==

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

Навчання має змогу бути частиною ліцензійного або впроваджувального пакета.; !; Під час переходу з [[BAS]] або [[1С]] на [[K2 ERP]] ліцензування має особливе значення.; Питання
Ліцензування [[K2 ERP]] — це важлива частина впровадження і подальшої експлуатації ERP-системи.;== Ліцензування BI ==

!; !;</div>
{| class="wikitable" style="width:100%;"
[[Категорія:Тестова база]]
Інтеграції можуть бути стандартними або індивідуальними.; Персональні логіни дають:

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

!; |}

Стандартні інтеграції:

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

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

* не платити за зайве;
* не обмежувати еволюція бізнесу;
* контролювати користувачів;
* контролювати ролі;
* контролювати API;
* контролювати BI;
* розділяти production і test;
* планувати підтримку;
* безпечно масштабувати ERP;
* якісно перейти з [[BAS]] і [[1С]].; З урахуванням санкційних, юридичних і кібербезпекових ризиків [[BAS]] та [[1С]], перехід на [[K2 ERP]] має включати не лише перенесення даних, а й побудову прозорої ліцензійної моделі, зрозумілої підтримки, контрольованих оновлень, безпечного API, BI-доступу, журналювання та цифрової незалежності.;[[Категорія:Цифрова незалежність України]]

== Активний користувач системи ==

!; |-
| Повний користувач системи
| Більшість функцій ERP
| Максимальний доступ
|-
| Операційний користувач системи
| Документи й довідники свого блоку
| Обмежений функціональні можливості
|-
| Комірник
| Складські операції
| Складський компонент
|-
| Керівник
| Звіти й BI
| Перегляд і аналітичні інструменти
|-
| API-користувач
| Інтеграції
| Технічний доступ
|}

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

Після таких змін потрібно переглядати ліцензійну модель.;== Ліцензування міграції з BAS або 1С ==

__TOC__

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

* є собою вимоги до локального розміщення;
* є собою власний датацентр;
* є собою корпоративні політики безпеки;
* потрібна інтеграційні функціональні можливості з внутрішніми системами;
* є собою обмеження на хмарні сервіси;
* потрібен повний контроль серверів.; |-
| Чи є собою санкційні ризики у [[BAS]] і [[1С]]?; Навіщо
Production має найвищі вимоги до стабільності, безпеки й резервного копіювання.;<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">

* кількість інтеграцій;
* кількість API-користувачів;
* кількість запитів;
* доступні методи;
* обсяг даних;
* підтримку;
* SLA;
* безпекові вимоги.; buh

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

[[Категорія:Ролі K2 ERP]]
!; | Планувати SLA і супровід
|}

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

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

Якщо є собою індивідуальні доробки, потрібно розуміти:

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

Тестове середовище не повинно використовуватися для реальних операцій.; * доступ до системи через web;

хмарне розміщення;
актуалізація;
резервне копіювання;
технічну підтримку;
масштабування;
адміністрування інфраструктури;
контроль доступів;
API та BI за умовами пакета.; # Визначити потрібні модулі.; Ліцензійна модель K2 ERP має будуватися не як копія старої BAS/1С, а як нова контрольована модель цифрової інфраструктури підприємства.;== Порівняння з ліцензуванням BAS/1С ==

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

sklad

Описати бізнес-процеси.; BI-аналітика має змогу мати окремі права або ліцензії.;

Ліцензування і доробки

У K2 ERP ліцензування варто розглядати не тільки як “оплату за програму”, а як модель керування доступом до цифрової інфраструктури підприємства: користувачів, ролей, підрозділів, організацій, складів, модулів, API, інтеграцій, BI, резервних копій, підтримки, оновлень і безпеки.; * скільки баз BAS/1С мігрується;

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

як ілюстрація: Потрібно регулярно перевіряти: !; # Порахувати реальних користувачів.; | Це технічний акаунт для API, інтеграцій, BI або автоматичного обміну.;== Ліцензування інтеграцій ==

On-premise-ліцензування K2 ERP

Ліцензування за середовищами

; Відповідь Ліцензування має підтримувати безпеку.; API сайту не повинен бачити банк і касу.; Правильне ліцензування надає можливість: </syntaxhighlight> Після переходу в K2 ERP стара BAS або 1С має змогу залишитися як архів.; # Визначити сервісні акаунти.; Блок Саме з цієї причини ліцензування має бути пов’язане з ролями, модулями й реальними бізнес-процесами.; Простий приклад: Рівні підтримки	;== Архівне середовище == старих документів; перевірок; аудиту; історії; юридичних потреб; звірок; перегляду старих проводок; старої регламентованої звітності.; користувач системи	; Доступ Ліцензування і цифрова незалежність	; * у системі створено 50 користувачів; одночасно можуть працювати 20; якщо 21-й користувач системи заходить, йому має змогу бути відмовлено або потрібно звільнення сесії.; \|-	Скільки активних користувачів?;== Ліцензування і реліз K2 ERP == Користувачі можуть бути: іменні; конкурентні; активні; тимчасові; сервісні; зовнішні; тільки для перегляду; BI-користувачі; API-користувачі.; Така модель потребує чіткої схеми ліцензування і відповідальності.; з цієї причини перехід на K2 ERP має включати не тільки міграцію даних, а й перегляд ліцензійної моделі, користувачів, ролей, сервісних акаунтів, інтеграцій і підтримки.; \|-	Що таке іменний користувач системи?; Ліцензування K2 ERP є собою частиною цифрової незалежності.; Найчастіші помилки: як ілюстрація: shevchenko.sales SaaS — це модель, коли K2 ERP застосовується як хмарний сервіс.; \| Це конкретна людина з персональним логіном.; \| Так.; користувач системи K2 ERP у цьому процесі має змогу стати платформою для контрольованого ліцензування користувачів, модулів, ролей, API, BI-аналітики, інтеграцій, середовищ, підтримки, оновлень, резервного копіювання, web-доступу, міграційних пакетів і подальшого розвитку автоматизації бізнесу без залежності від старої екосистеми BAS / 1С.; \|-	Старт	10 користувачів, складський облік, продажі та реалізація	Базовий пакет
Ріст	Додано закупівельна діяльність, фінансовий блок, 25 користувачів	Розширення користувачів і модулів
Інтеграції	Сайт, CRM, WMS	API та сервісні користувачі
аналітичні інструменти	Керівники потребують BI	BI-користувачі
Холдинг	Кілька організацій	Консолідація й додаткові організації

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

Архів потрібен для:

Ліцензування має визначати, що входить у стандартний пакет, а що є собою окремою роботою.; Приклад

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

Ліцензування за ролями

Потрібно перевірити: завдяки наявності Журналювання користувачі можуть контролювати використання ліцензій.; Підхід K2 ERP. Ліцензування K2 ERP має бути прозорим: скільки є собою активних користувачів, які модулі підключені, які API використовуються, які BI-панелі доступні, які середовища працюють, хто має адміністративні права і які сервіси входять у підтримку.; |- | Production | Робоча платформа користувачів |- | Test | Перевірка оновлень і доробок |- | Staging | Передпродуктивна перевірка |- | Development | розробка програмного забезпечення |- | Archive | Архівні інформаційні дані |}

У ньому ведуться:

Це має змогу бути потрібно, якщо:

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

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

Під час переходу з BAS або 1С потрібно порівняти стару і нову модель.; Керівнику часто потрібна аналітичні інструменти, але не обов’язково право змінювати документи.; | Зберегти історичні інформаційні дані |- | Який рівень підтримки потрібен?; * хмарне ядро;

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

Кожній групі потрібен різний доступ.; # Визначити API-користувачів.;== Помилка: не переглядати ліцензії після змін у бізнесі ==

!; | Це правила використання ERP-системи: користувачі, модулі, API, BI, середовища, супровід, актуалізація й інтеграції.; Ризик