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

Ліцензування K2 ERP — це правила, за якими компанія отримує право користуватися системою K2 ERP, її модулями, користувачами, сервісами, API, BI-аналітикою, інтеграціями, тестовими середовищами, підтримкою, оновленнями та іншими компонентами ERP-платформи. Ліцензування визначає, хто може працювати в системі, які функції доступні, які модулі підключені, які середовища використовуються, які обмеження діють і як компанія масштабує ERP у міру розвитку бізнесу.

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

Під час переходу з BAS або 1С на K2 ERP ліцензування має особливе значення. Компанія повинна не механічно переносити стару кількість користувачів або стару модель доступу, а переосмислити, кому і який доступ реально потрібен: бухгалтерам, менеджерам, комірникам, керівникам, касирам, логістам, виробництву, інтеграціям, API-користувачам, BI-користувачам і адміністраторам.

Головне. Ліцензування K2 ERP — це не тільки кількість користувачів. Це модель доступу до ERP-функцій: модулів, ролей, API, BI, інтеграцій, середовищ, підтримки, оновлень і сервісів.

Важливо про BAS і 1С. BAS та 1С мають санкційні, юридичні й кібербезпекові ризики в Україні. Окремі продукти 1С і BAS внесені до відкритих переліків програмного забезпечення, забороненого до використання для окремих категорій організацій. Тому перехід на K2 ERP має включати не тільки міграцію даних, а й перегляд ліцензійної моделі, користувачів, ролей, сервісних акаунтів, інтеграцій і підтримки.

Підхід K2 ERP. Ліцензування K2 ERP має бути прозорим: скільки є активних користувачів, які модулі підключені, які API використовуються, які BI-панелі доступні, які середовища працюють, хто має адміністративні права і які сервіси входять у підтримку.

Вступ

ERP-система використовується різними групами користувачів.

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

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

Кожній групі потрібен різний доступ. Менеджеру продажів не потрібен повний бухгалтерський модуль. Комірнику не потрібен доступ до зарплати. API сайту не повинен бачити банк і касу. Керівнику часто потрібна аналітика, але не обов’язково право змінювати документи.

Саме тому ліцензування має бути пов’язане з ролями, модулями й реальними бізнес-процесами.

Що таке ліцензування K2 ERP

Ліцензування K2 ERP — це набір правил і умов використання ERP-системи.

Воно може визначати:

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

Простий приклад:

Елемент ліцензування	Приклад	Що означає
Користувачі	25 активних користувачів	У системі працює до 25 людей
Модулі	Продажі, склад, фінанси	Підключені тільки потрібні блоки
API	API для сайту	Дозволено інтеграцію із зовнішнім сайтом
BI	5 BI-користувачів	Доступ до аналітичних панелей для керівників
Середовище	Production + Test	Є робоча і тестова база

Навіщо потрібне ліцензування

Ліцензування потрібне для:

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

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

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

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

Ліцензування за користувачами

Одна з найпоширеніших моделей — ліцензування за кількістю користувачів.

Користувачі можуть бути:

іменні;
конкурентні;
активні;
тимчасові;
сервісні;
зовнішні;
тільки для перегляду;
BI-користувачі;
API-користувачі.

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

Іменний користувач — це конкретна людина з персональним логіном.

Наприклад:

Користувач	Роль	Тип ліцензії
ivanenko	Менеджер продажів	Іменна
petrenko.buh	Бухгалтер	Іменна
sklad.kyiv.01	Комірник	Іменна

Перевага іменних користувачів — прозоре журналювання і персональна відповідальність.

Конкурентний користувач

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

Наприклад:

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

Така модель може бути зручною, якщо користувачі працюють позмінно.

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

Активний користувач — це користувач, який має право входити в систему.

Активними мають бути тільки ті, хто реально працює.

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

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

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

Користувач тільки для перегляду може бути потрібен:

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

Він може бачити дані, але не змінювати їх.

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

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

Наприклад:

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

Сервісні користувачі мають ліцензуватися і контролюватися окремо, якщо вони створюють навантаження або отримують доступ до даних.

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

Ліцензування може враховувати різні ролі.

Наприклад:

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

Приклад:

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

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

Модульна модель дозволяє підключати тільки потрібний функціонал.

Модулі можуть бути такими:

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

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

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

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

Якщо в системі кілька юридичних осіб, ліцензія може враховувати кількість організацій.

Наприклад:

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

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

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

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

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

Середовище	Для чого
Production	Робоча система користувачів
Test	Перевірка оновлень і доробок
Staging	Передпродуктивна перевірка
Development	Розробка
Archive	Архівні дані

Ліцензування має чітко визначати, які середовища включені.

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

Production — це основна робоча система.

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

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

Production має найвищі вимоги до стабільності, безпеки й резервного копіювання.

Тестове середовище

Тестове середовище потрібне для:

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

Тестове середовище не повинно використовуватися для реальних операцій.

Архівне середовище

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

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

Архівний доступ бажано робити тільки для читання.

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

SaaS — це модель, коли K2 ERP використовується як хмарний сервіс.

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

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

Переваги SaaS:

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

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

On-premise — це модель, коли K2 ERP встановлюється на інфраструктурі клієнта.

Це може бути потрібно, якщо:

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

У такій моделі важливо визначити:

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

Гібридна модель

Гібридна модель може поєднувати:

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

Така модель потребує чіткої схеми ліцензування і відповідальності.

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

API може ліцензуватися окремо або входити в пакет.

API потрібен для:

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

Ліцензія API може враховувати:

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

Ліцензування BI

BI-аналітика може мати окремі права або ліцензії.

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

директор;
фінансовий директор;
керівник продажів;
керівник складу;
керівник виробництва;
власник бізнесу;
аналітик;
аудитор.

BI-доступ потрібно обмежувати, бо аналітика може містити:

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

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

Мобільні сценарії можуть бути окремою частиною ліцензії.

Наприклад:

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

Для таких сценаріїв важливо визначити:

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

Ліцензування інтеграцій

Інтеграції можуть бути стандартними або індивідуальними.

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

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

Індивідуальні інтеграції:

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

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

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

Підтримка може включати:

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

Рівні підтримки

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

Рівень	Для кого	Що включає
Базовий	Малі компанії	Консультації, базові оновлення, типові питання
Стандартний	Середній бізнес	Підтримка користувачів, оновлення, базові інтеграції
Розширений	Компанії з критичними процесами	SLA, інтеграції, моніторинг, пріоритетні заявки
Enterprise	Великі компанії	Індивідуальні умови, виділена команда, розширений SLA

SLA

SLA — це домовленість про рівень сервісу.

Вона може визначати:

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

Ліцензування оновлень

Оновлення можуть входити в підписку або надаватися окремо.

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

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

Ліцензування міграції з BAS або 1С

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

Він може включати:

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

Що врахувати при міграційному ліцензуванні

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

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

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

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

Ліцензування архіву BAS/1С

Після переходу в K2 ERP стара BAS або 1С може залишитися як архів.

Архівний доступ може бути потрібен для:

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

Але архів не повинен бути робочою системою.

Ліцензійний аудит

Ліцензійний аудит — це перевірка фактичного використання системи.

Потрібно перевірити:

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

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

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

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

Неактивні користувачі не повинні споживати ліцензії або створювати ризики.

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

дату останнього входу;
статус працівника;
активні ролі;
відкриті задачі;
доступ до BI;
доступ до API;
доступ до архівів;
сервісні токени;
спільні логіни.

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

Спільні логіни погані і з точки зору безпеки, і з точки зору ліцензування.

Погано:

manager
buh
sklad
operator

Краще:

ivanenko
petrenko.buh
kovalenko.sklad
shevchenko.sales

Персональні логіни дають:

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

Ліцензування і права доступу

Ліцензія не повинна автоматично означати повний доступ.

Користувач може мати ліцензію, але обмежені права:

тільки продажі;
тільки склад;
тільки каса;
тільки перегляд;
тільки BI;
тільки API;
тільки одна організація;
тільки один склад;
тільки один підрозділ.

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

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

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

хто має доступ;
які користувачі активні;
які ролі призначені;
хто має admin-права;
які API-ключі активні;
хто має доступ до BI;
хто бачить зарплату;
хто бачить собівартість;
хто може експортувати дані;
хто має доступ до архіву;
хто може створювати користувачів.

Ліцензування і журналювання

Журналювання допомагає контролювати використання ліцензій.

Можна аналізувати:

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

Ліцензування і резервні копії

У SaaS або підтримуваній інфраструктурі потрібно визначити, чи входять резервні копії в ліцензію або пакет підтримки.

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

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

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

Навчання може бути частиною ліцензійного або впроваджувального пакета.

Навчання може включати:

адміністраторів;
бухгалтерів;
менеджерів;
комірників;
керівників;
API-інтеграторів;
BI-користувачів;
службу підтримки клієнта;
нових працівників.

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

Ліцензія на систему і впровадження — це різні речі.

Ліцензія дає право користування.

Впровадження може включати:

аналіз процесів;
налаштування;
міграцію;
інтеграції;
навчання;
доробки;
тестування;
запуск;
підтримку після старту.

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

Індивідуальні доробки можуть ліцензуватися або супроводжуватися окремо.

Наприклад:

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

Потрібно визначити, чи входять такі доробки в основний пакет.

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

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

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

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

Ліцензування пов’язане з версією K2 ERP.

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

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

Ліцензування і масштабування

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

Може збільшуватися:

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

Ліцензійна модель має дозволяти поступове розширення.

Приклад масштабування

Етап	Потреба	Ліцензійна зміна
Старт	10 користувачів, склад, продажі	Базовий пакет
Ріст	Додано закупівлі, фінанси, 25 користувачів	Розширення користувачів і модулів
Інтеграції	Сайт, CRM, WMS	API та сервісні користувачі
Аналітика	Керівники потребують BI	BI-користувачі
Холдинг	Кілька організацій	Консолідація й додаткові організації

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

Під час переходу з BAS або 1С потрібно порівняти стару і нову модель.

Питання	BAS/1С	K2 ERP
Користувачі	Часто накопичені старі акаунти	Потрібна чиста модель персональних користувачів
Ролі	Можуть бути хаотичні або дороблені	Варто будувати нову матрицю доступу
Інтеграції	Часто через обробки, файли, web-сервіси	Бажано через контрольований API
BI	Часто зовнішні вивантаження або Excel	Контрольований BI-доступ
Оновлення	Можуть бути складні через доробки	Потрібна прозора версійність і changelog
Санкційні ризики	Є для окремих продуктів BAS/1С	Українська ERP-архітектура

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

Ліцензування K2 ERP є частиною цифрової незалежності.

Компанія отримує можливість:

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

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

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

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

Помилка: рахувати тільки людей

Компанія може порахувати тільки людей, які входять у систему, але забути:

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

Помилка: не врахувати інтеграції

Інтеграції можуть створювати навантаження і потребувати окремого ліцензування.

Наприклад:

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

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

Спільні логіни погані для безпеки, журналювання і ліцензійного аудиту.

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

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

Помилка: не переглядати ліцензії після змін у бізнесі

Бізнес змінюється.

Може з’явитися:

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

Після таких змін потрібно переглядати ліцензійну модель.

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

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

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

Найгірший сценарій. Компанія переходить із BAS у K2 ERP, але переносить старий хаос: спільні логіни, зайві користувачі, невідомі сервісні акаунти, API під адміністратором, BI без обмежень і модулі без аналізу реальних процесів.

Як правильно підходити до ліцензування K2 ERP

Правильний порядок:

Описати бізнес-процеси.
Визначити потрібні модулі.
Порахувати реальних користувачів.
Розділити користувачів за ролями.
Визначити BI-користувачів.
Визначити API-користувачів.
Визначити сервісні акаунти.
Визначити потрібні інтеграції.
Визначити середовища: production, test, archive.
Визначити потребу в підтримці.
Визначити потребу в оновленнях.
Визначити потребу в міграції з BAS/1С.
Побудувати матрицю доступу.
Заблокувати зайвих користувачів.
Перевірити права після запуску.
Періодично проводити ліцензійний аудит.

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

Питання	Навіщо
Скільки активних користувачів?	Визначити базовий обсяг ліцензії
Які ролі потрібні?	Не видавати всім повні права
Які модулі потрібні?	Не платити за зайвий функціонал
Чи потрібен API?	Врахувати інтеграції
Чи потрібен BI?	Врахувати аналітику
Чи потрібна тестова база?	Безпечно оновлювати систему
Чи потрібен архів BAS?	Зберегти історичні дані
Який рівень підтримки потрібен?	Планувати SLA і супровід

Коротко

Питання	Відповідь
Що таке ліцензування K2 ERP?	Це правила використання ERP-системи: користувачі, модулі, API, BI, середовища, підтримка, оновлення й інтеграції.
Чи ліцензія — це тільки користувачі?	Ні. Ліцензування може враховувати модулі, ролі, API, BI, середовища, інтеграції, підтримку і масштабування.
Що таке іменний користувач?	Це конкретна людина з персональним логіном.
Що таке сервісний користувач?	Це технічний акаунт для API, інтеграцій, BI або автоматичного обміну.
Чи потрібно ліцензувати API?	Залежить від моделі, але API потрібно враховувати окремо, бо він створює доступ і навантаження.
Чи потрібно враховувати BI?	Так. BI може містити фінансові, комерційні й персональні дані.
Що важливо при міграції з BAS?	Не переносити стару модель користувачів як є, а побудувати нову модель ліцензій, ролей, модулів, API й BI.
Чи є санкційні ризики у BAS і 1С?	Так. Окремі продукти 1С і BAS внесені до переліків забороненого програмного забезпечення для окремих категорій організацій в Україні.

Висновок

Ліцензування K2 ERP — це важлива частина впровадження і подальшої експлуатації ERP-системи. Воно має відповідати реальним бізнес-процесам, кількості користувачів, ролям, модулям, API, BI, інтеграціям, середовищам, підтримці, оновленням і вимогам безпеки.

Правильне ліцензування дозволяє:

не платити за зайве;
не обмежувати розвиток бізнесу;
контролювати користувачів;
контролювати ролі;
контролювати API;
контролювати BI;
розділяти production і test;
планувати підтримку;
безпечно масштабувати ERP;
якісно перейти з BAS і 1С.

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

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

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

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

Див. також

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