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

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

ERP-система застосовують, коли потрібно різними групами користувачів. ! ! {| class="wikitable" style="width:100%;"

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

! | Визначити базовий обсяг ліцензії |- | Які ролі потрібні?== Гібридна модель ==

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

Див. так само

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

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

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

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

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

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

|- | Базовий | Малі компанії | Консультації, базові оновлення версій, типові питання |- | Стандартний | Середній бізнес-середовище | технічна підтримка користувачів, оновлення версій, базові інтеграції |- | Розширений | Компанії з критичними процесами | SLA, інтеграції, моніторинг, пріоритетні заявки |- | Enterprise | Великі компанії | Індивідуальні умови, виділена команда, розширений SLA |}

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

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

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

Описати бізнес-процеси.

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

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

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

Потрібно визначити, чи входять такі доробки в базовий пакет. |- | Що таке іменний користувач системи? | Так. Роль ! * легального використання системи;

контролю доступу;
планування бюджету;
масштабування ERP;
розмежування модулів;
контролю користувачів;
підтримки безпеки;
керування оновленнями;
підтримки API;
підтримки BI;
організації технічної підтримки;
розуміння, які сервіси входять у пакет;
прогнозування розвитку системи. * кількість користувачів;
типи користувачів;
доступні модулі;
доступні організації;
доступні середовища;
доступ до API;
доступ до BI;
доступ до мобільних сценаріїв;
рівень підтримки;
оновлення версій;
резервне копіювання;
хмарне або локальне розміщення;
права адміністрування;
обсяг інтеграцій;
умови масштабування;
строк дії ліцензії. Кожній групі потрібен різний доступ. ! | Залежить від моделі, але API потрібно враховувати окремо, бо він створює доступ і навантаження. |}

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

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

Потрібно регулярно перевіряти: operator SEO title: Ліцензування K2 ERP — користувачі, модулі, SaaS, on-premise, API, BI, підтримка і міграція з BAS

SEO 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С, цифрова незалежність

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

}}

! |- | Чи ліцензійний пакет — це тільки користувачі? BI-доступ потрібно обмежувати, бо аналітичні інструменти здатна містити:

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

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

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

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

ліцензійний пакет не повинна автоматизовано означати повний доступ. Особливість ліцензування

здатна збільшуватися: У ньому ведуться: Індивідуальні доробки можуть ліцензуватися або супроводжуватися окремо. SaaS — це модель, коли K2 ERP застосовується для як хмарний сервіс. ! Ліцензування K2 ERP виступає як частиною цифрової незалежності. | Не видавати всім повні права |- | Які модулі потрібні? Production має найвищі вимоги до стабільності, безпеки й резервного копіювання.== Ліцензування за користувачами ==

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

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

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

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

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

! * тільки продажі та реалізація;

тільки складський облік;
тільки каса;
тільки перегляд;
тільки BI;
тільки API;
тільки одна організація;
тільки один складський облік;
тільки один підрозділ. Ліцензування має чітко визначати, які середовища включені. | Це правила використання ERP-системи: користувачі, модулі, API, BI, середовища, технічна підтримка, оновлення версій й інтеграції. # Заблокувати зайвих користувачів.== Основні об’єкти ліцензування ==

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

Приклад:

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

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

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

Інтеграції можуть створювати навантаження і потребувати окремого ліцензування. Production — це основна робоча платформа. # Визначити середовища: production, test, archive. # Перевірити права після запуску. * які організації ведуть обліковий облік;

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

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

petrenko.buh Воно здатна визначати: Впровадження здатна включати: Мобільні сценарії можуть бути окремою частиною ліцензії. Потрібно визначити:

! |- | Що таке сервісний користувач системи? ! Рівень

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

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

У зрілій ERP-архітектурі зазвичай виступає як кілька середовищ. Одна з найпоширеніших моделей — ліцензування за кількістю користувачів. Конкурентний користувач системи — це модель, коли ліцензується не загальна кількість облікових записів, а кількість одночасних підключень. {| class="wikitable" style="width:100%;"

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

Погані підходи: !== Ліцензування мобільних сценаріїв ==

Спільні логіни погані для безпеки, журналювання і ліцензійного аудиту. |- | Скільки активних користувачів? # Визначити потрібні модулі. * сайт;

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

Під час переходу з BAS або 1С потрібно порівняти стару і нову модель. | Не платити за зайвий функції ERP |- | Чи потрібен API? компанія-користувач

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

як приклад:

доступ до системи через web;
хмарне розміщення;
оновлення версій;
резервне копіювання;
технічну підтримку;
масштабування;
адміністрування інфраструктури;
контроль доступів;
API та BI за умовами пакета. # Визначити сервісні акаунти. У K2 ERP об’єктами ліцензування можуть бути:

! BI здатна містити фінансові, комерційні й персональні інформаційні дані. Ліцензування здатна враховувати модулі, ролі, API, BI, середовища, інтеграції, підтримку і масштабування. # Визначити потрібні інтеграції. Ліцензійна зміна

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

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

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

! Навіщо

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

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

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

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

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

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

Вступ

Коротко

ліцензійний пакет на систему і впровадження — це різні речі.== Конкурентний користувач системи ==

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

# Визначити потребу в підтримці. ! Неактивні користувачі не повинні споживати ліцензії або створювати ризики. Блок

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

Ліцензування і реліз системи K2 ERP

дату останнього входу;
статус працівника;
активні ролі;
відкриті задачі;
доступ до BI;
доступ до API;
доступ до архівів;
сервісні токени;
спільні логіни. Якщо виступає як індивідуальні доробки, потрібно розуміти:

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

як приклад:

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

SLA

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

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

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

Тому перехід на K2 ERP має включати не тільки міграцію даних забезпечується через критично про BAS і 1С. BAS та 1С мають санкційні, юридичні й кібербезпекові ризики в Україні. shevchenko.sales мобільний складський облік; мобільний продавець; мобільний водій; мобільний механік; мобільний керівник; мобільна інвентаризація; мобільне погодження документів. Така модель потребує чіткої схеми ліцензування і відповідальності. # Визначити API-користувачів. Ліцензування K2 ERP — це важлива частина впровадження і подальшої експлуатації ERP-системи. Потрібні модулі У K2 ERP ліцензування варто розглядати не тільки як “оплату за програму”, а як модель керування доступом до цифрової інфраструктури підприємства: користувачів, ролей, підрозділів, організацій, складів, модулів, API, інтеграцій, BI, резервних копій, підтримки, оновлень і безпеки.== Висновок == сайт щохвилини читає залишки; CRM створює замовлення; WMS синхронізує складський облік; BI щоночі оновлює інформаційні дані; банк передає виписки; мобільний застосунок використовує API. \|-	api_site	інтеграційні функції ERP із сайтом	Товари, ціни, залишки, замовлення
api_crm	інтеграційні функції ERP з CRM	Клієнти, угоди, статуси
api_wms	інтеграційні функції ERP зі складом	Залишки, переміщення, відвантаження
bi_export	Передача даних у BI	Читання аналітичних даних

Він здатна включати:

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

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

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

Production

Робоча платформа користувачів

Test

Перевірка оновлень і доробок

Staging

Передпродуктивна перевірка

Development

розробка програмного забезпечення

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

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

Найчастіші помилки: ліцензійний пакет дає право користування. ! {\| class="wikitable" style="width:100%;" власна платформа клієнта; специфічний API; галузева платформа; старий файловий обмін; проміжний сервіс; міграційний шлюз із BAS.== Приклад міграційного пакета == Найгірший сценарій. компанія-користувач переходить із BAS у K2 ERP, але переносить старий хаос: спільні логіни, зайві користувачі, невідомі сервісні акаунти, API під адміністратором, BI без обмежень і модулі без аналізу реальних процесів. Це модель доступу до ERP-функцій: модулів, ролей, API, BI, інтеграцій, середовищ, підтримки, оновлень і сервісів. Навіщо потрібне ліцензування sklad кількість користувачів; кількість складів; кількість організацій; кількість документів; кількість API-запитів; кількість BI-користувачів; кількість інтеграцій; кількість філій; кількість мобільних користувачів; кількість середовищ. * відмовитися від санкційно ризикової екосистеми BAS/1С; перейти на українську ERP; контролювати користувачів; контролювати ролі; контролювати API; контролювати BI; контролювати інтеграції; мати прозору підтримку; мати прозорі оновлення версій; не залежати від старих доробок; планувати дорожня карта розвитку системи. Призначення Саме тому ліцензування має бути пов’язане з ролями, модулями й реальними бізнес-процесами. K2 ERP У такій моделі критично визначити: через Журналювання користувачі можуть контролювати використання ліцензій. Потрібно контролювати: Ліцензування за організаціями іменні; конкурентні; активні; тимчасові; сервісні; зовнішні; тільки для перегляду; BI-користувачі; API-користувачі. Що містить компанія-користувач отримує можливість: сайту; CRM; WMS; мобільного застосунку; BI; маркетплейсів; банків; електронного документообігу; сервісів доставки; зовнішніх партнерів. \| Ні. \| Врахувати інтеграції
Чи потрібен BI? Гібридна модель здатна поєднувати: скільки баз BAS/1С мігрується; які конфігурації використовуються; чи виступає як файлові бази; чи виступає як клієнт-серверні бази; чи виступає як web-клієнт; чи виступає як зовнішні обробки; чи виступає як інтеграції; скільки організацій; скільки користувачів; які модулі потрібні в K2 ERP; чи потрібна історія продукту; чи потрібен архів; чи потрібні BI-звіти. Питання старих документів; перевірок; аудиту; історії; юридичних потреб; звірок; перегляду старих проводок; старої регламентованої звітності. У K2 ERP можуть працювати: хмарне ядро; локальні інтеграції; локальні файлові обміни; локальні каси; локальні склади; хмарний BI; локальні сервіси безпеки; API-шлюзи. Ліцензування має підтримувати безпеку. \|-	Чи потрібно враховувати BI? BI-аналітика здатна мати окремі права або ліцензії. Дія дату останнього входу; кількість входів; активні сеанси; використання модулів; запуск звітів; запуск API; експорт даних; використання BI; роботу сервісних акаунтів; невдалі входи; підозрілу активність. Після переходу в K2 ERP стара BAS або 1С здатна залишитися як архів. Навчання здатна включати:
Активні користувачі	42	Ліцензовано 40	Переглянути активність
Сервісні акаунти	8	Частина не застосовується для	Заблокувати зайві
BI-користувачі	12	Доступ до фінансів мають не всі потрібні ролі	Переглянути права
Тестові бази	4	Немає опису	Описати або видалити зайві
Старі BAS-бази	6	Невідомий статус	Перевести в архівний реєстр

Приклад

здатна з’явитися:

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

Старт

10 користувачів, складський облік, продажі та реалізація

Базовий пакет

Ріст

Додано закупівельна діяльність, фінансовий блок, 25 користувачів

Розширення користувачів і модулів

Інтеграції

Сайт, CRM, WMS

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

аналітичні інструменти

Керівники потребують BI

BI-користувачі

Холдинг

Кілька організацій

Консолідація й додаткові організації

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

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

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

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

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

Що критично при міграції з BAS? Об’єкт хто реально працював; хто змінив документ; хто експортував інформаційні дані; хто провів операцію; хто зробив помилку; чи всі користувачі ліцензовані коректно.== Ліцензування і права доступу == звільнених працівників; тимчасових користувачів; тестові акаунти; старі облікові записи; сервісні акаунти; дублікати користувачів; спільні логіни. \| Безпечно оновлювати систему
Зберегти історичні інформаційні дані
Який рівень підтримки потрібен? Елемент ліцензування Тестове середовище потрібне для: Рівні підтримки Окремо варто відзначити за якими компанія-користувач отримує право користуватися системою K2 ERP, її модулями, користувачами, сервісами, API, BI-аналітикою, інтеграціями, тестовими середовищами, підтримкою, оновленнями і іншими компонентами ERP-платформи виступає ключовою рисою Ліцензування K2 ERP. \| Це конкретна людина з персональним логіном. * історичних даних; старих документів; перегляду даних після міграції; аудиту; звірок; юридичних потреб; старих BAS/1С-баз. ! {\| class="wikitable" style="width:100%;" прибуток; маржу; собівартість; зарплату; фінансові показники; інформаційні дані клієнтів; комерційні умови; персональні інформаційні дані. Простий приклад: чи входять оновлення версій в ліцензію; як часто виходять оновлення версій; хто їх встановлює; чи виступає як тестова база; чи виступає як release notes; чи виступає як changelog; хто перевіряє інтеграції; хто перевіряє BI; хто відповідає за відкат. Коментар Ліцензування API Ліцензування і резервні копії Що таке ліцензування K2 ERP Іменний користувач системи — це конкретна людина з персональним логіном. # Періодично проводити ліцензійний аудит. Доступ	-	Торгова компанія-користувач	продажі та реалізація, закупівельна діяльність, складський облік, фінансовий блок, API	інтеграційні функції ERP із сайтом
Виробництво	складський облік, виробництво, фінансовий блок, BI	Контроль собівартості
Агробізнес	Агро, складський облік, техніка, паливо, BI	Поля, культури, сезони
Ресторанна мережа	Громадське харчування, складський облік, каса, закупівельна діяльність	Рецептури, списання, продажі та реалізація

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

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

Погано: як приклад:

ivanenko Менеджер продажів Іменна petrenko.buh Бухгалтер Іменна sklad.kyiv.01 Комірник Іменна

kovalenko.sklad

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

manager

ivanenko

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

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

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

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

Чи потрібно ліцензувати API? як приклад:

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

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

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

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

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

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

! Комірнику не потрібен доступ до зарплати. Тип ліцензії

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

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

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

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

керівнику;
аудитору;
власнику бізнесу;
консультанту;
контролеру;
зовнішньому користувачу;
архівному доступу. # Визначити потребу в міграції з BAS/1С. Потрібно визначити:

<syntaxhighlight lang="text">

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

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

Див. так само

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

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

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

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

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

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

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

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

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

Вступ

Коротко

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

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

Ліцензування і реліз системи K2 ERP

SLA

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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