Користувач K2 ERP

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

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

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

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

Підхід K2 ERP. У K2 ERP користувач має бути прив’язаний до реальної ролі в бізнесі: бухгалтер, менеджер, комірник, керівник, касир, логіст, адміністратор, інтегратор, сервісний користувач або інша роль. Права мають видаватися за принципом мінімально необхідного доступу.

Вступ

У будь-якій ERP-системі користувач — це точка входу в бізнес-процеси.

Через користувачів система розуміє:

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

Без правильної моделі користувачів ERP швидко перетворюється на хаос: усі бачать усе, адміністраторські права роздані зайвим людям, документи змінюються без контролю, а відповідальність за помилки неможливо встановити.

Що таке користувач K2 ERP

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

Користувач може мати:

логін;
пароль або інший спосіб автентифікації;
ПІБ;
email;
телефон;
роль;
групу доступу;
підрозділ;
організацію;
посаду;
статус активності;
мову інтерфейсу;
налаштування інтерфейсу;
права на довідники;
права на документи;
права на звіти;
права на інтеграції;
журнал дій.

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

Користувач	Роль	Підрозділ	Доступ
ivanenko	Менеджер продажів	Відділ продажів	Клієнти, замовлення, рахунки
petrenko	Бухгалтер	Бухгалтерія	Банк, каса, проводки, звітність
sklad01	Комірник	Склад	Надходження, переміщення, інвентаризація
api_site	Сервісний користувач	Інтеграції	API для сайту

Обліковий запис

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

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

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

Обліковий запис має бути унікальним.

Погано:

user
admin
manager
buh
123

Краще:

ivanenko
petrenko.buh
sklad.kyiv.01
api_site

Людина і користувач

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

Погано:

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

Добре:

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

Типи користувачів K2 ERP

У K2 ERP можна виділити кілька типів користувачів.

Тип	Хто це	Приклад
Бізнес-користувач	Працівник, який виконує операції	Менеджер, бухгалтер, комірник
Керівник	Користувач для контролю й аналітики	Директор, фінансовий директор, керівник складу
Адміністратор	Користувач для налаштувань системи	ERP-адміністратор
Сервісний користувач	Технічний акаунт для інтеграцій	api_site, api_wms, bi_export
Аудитор	Користувач для перегляду й перевірки	Внутрішній або зовнішній аудитор

Роль користувача

Роль визначає, що користувач може робити в системі.

Наприклад:

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

Роль має відповідати реальній роботі людини.

Приклади ролей

Роль	Основні можливості
Менеджер продажів	Створення клієнтів, замовлень, рахунків, перегляд статусів
Комірник	Приймання, переміщення, списання, інвентаризація
Бухгалтер	Каса, банк, проводки, податкові документи, звітність
Касир	Касові операції, оплати, повернення
Закупівельник	Постачальники, замовлення постачальникам, надходження
Логіст	Доставка, маршрути, рейси, статуси відвантажень
Керівник	Звіти, BI, контроль KPI
Адміністратор	Налаштування, користувачі, ролі, довідники, інтеграції

Права доступу

Права доступу визначають, які дії дозволені користувачу.

Права можуть бути:

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

Приклад:

Об’єкт	Менеджер	Комірник	Бухгалтер
Замовлення покупця	Створення і зміна	Перегляд	Перегляд
Реалізація	Створення	Перегляд	Проведення
Складські залишки	Перегляд	Зміна через документи	Перегляд
Собівартість	Немає доступу	Немає доступу	Перегляд
Каса	Немає доступу	Немає доступу	Повний доступ

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

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

Це зменшує ризики:

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

Приклад:

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

Групи користувачів

Групи користувачів допомагають керувати доступами.

Наприклад:

Бухгалтерія;
Продажі;
Закупівлі;
Склад;
Каса;
Логістика;
Виробництво;
Керівництво;
Адміністратори;
Інтеграції;
Аудитори.

Приклад:

Група	Типові ролі	Приклад доступу
Продажі	Менеджер, керівник продажів	Клієнти, замовлення, рахунки
Склад	Комірник, керівник складу	Надходження, переміщення, залишки
Бухгалтерія	Бухгалтер, головний бухгалтер	Каса, банк, податки, проводки
Інтеграції	Сервісні користувачі	API, обміни, технічні операції

Профіль користувача

Профіль користувача може містити:

ПІБ;
посаду;
підрозділ;
email;
телефон;
мову;
часовий пояс;
організацію;
склад за замовчуванням;
касу за замовчуванням;
роль;
налаштування інтерфейсу;
підпис;
відповідального керівника.

Приклад:

Поле	Значення
Логін	ivanenko
ПІБ	Іваненко Іван Іванович
Посада	Менеджер продажів
Підрозділ	Відділ продажів
Склад за замовчуванням	Основний склад
Роль	Менеджер продажів
Статус	Активний

Підрозділ користувача

Підрозділ допомагає обмежувати або структурувати доступ.

Наприклад:

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

Організація користувача

Якщо в системі кілька юридичних осіб, користувач може мати доступ:

до однієї організації;
до кількох організацій;
до всіх організацій;
тільки до консолідованої аналітики.

Приклад:

Користувач	Організація	Доступ
buh_kyiv	ТОВ Київ	Бухгалтерські документи ТОВ Київ
buh_lviv	ТОВ Львів	Бухгалтерські документи ТОВ Львів
fin_dir	Усі організації	Консолідована фінансова аналітика

Склад за замовчуванням

Для складських і торгових ролей важливо мати склад за замовчуванням.

Наприклад:

менеджер Києва створює замовлення з Основного складу;
комірник філії бачить тільки склад Львів;
інтернет-магазин резервує товар на складі E-commerce;
виробництво списує матеріали зі складу Виробництво.

Це зменшує кількість помилок при введенні документів.

Каса за замовчуванням

Для касира або бухгалтера може бути налаштована каса за замовчуванням.

Наприклад:

каса магазину;
каса офісу;
валютна каса;
каса філії;
каса кур’єра;
каса ресторану.

Користувач не повинен випадково створювати касові документи в чужій касі.

Мова і локальні налаштування

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

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

Це підвищує зручність роботи, але не повинно порушувати єдині правила обліку.

Автентифікація

Автентифікація — це перевірка, що користувач є тим, за кого себе видає.

Можливі способи:

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

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

Паролі

Пароль має бути достатньо складним і персональним.

Погані практики:

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

Добрі практики:

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

Двофакторна автентифікація

Двофакторна автентифікація додає другий рівень захисту.

Вона особливо важлива для:

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

Адміністратор K2 ERP

Адміністратор має розширені права.

Він може:

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

Адміністраторські права мають бути обмежені й контрольовані.

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

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

Приклади:

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

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

Чому не можна використовувати адміністратора для інтеграцій

Погана практика — підключати сайт, CRM або WMS під адміністратором.

Ризики:

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

Краще створювати окремого сервісного користувача для кожної інтеграції.

Користувач і журналювання

Кожна важлива дія користувача має журналюватися.

Журнал може фіксувати:

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

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

Приклад журналу дій

Дата	Користувач	Дія	Об’єкт
15.05.2026 10:15	ivanenko	Створено документ	Замовлення покупця №123
15.05.2026 10:20	petrenko.buh	Проведено документ	Банківська виписка №45
15.05.2026 11:05	admin	Змінено роль	Користувач sklad01
15.05.2026 12:30	api_site	API-запит	Створення замовлення WEB-100245

Користувач і відповідальність

Правильна модель користувачів допомагає встановити відповідальність.

Наприклад:

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

Якщо всі працюють під одним логіном, відповідальність зникає.

Користувач і бізнес-процеси

Користувачі можуть брати участь у бізнес-процесах.

Наприклад:

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

Приклад:

Етап	Роль	Дія
Створення замовлення	Менеджер	Вводить клієнта і товари
Перевірка боргу	Бухгалтер	Перевіряє оплату або ліміт
Резерв	Склад	Резервує товар
Відвантаження	Комірник	Підтверджує відвантаження
Контроль	Керівник	Переглядає звіт

Користувач і BI

У BI користувачі також мають різні права.

Наприклад:

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

BI-доступ не повинен відкривати більше даних, ніж потрібно користувачу.

Користувач і API

API-доступ має бути пов’язаний із конкретним сервісним користувачем.

Наприклад:

api_site  → сайт
api_wms   → складська система
api_crm   → CRM
bi_export → BI

Для кожного API-користувача потрібно визначити:

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

Активний і заблокований користувач

Користувач може мати статус:

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

При звільненні працівника користувача не обов’язково видаляти. Часто краще заблокувати, щоб зберегти історію дій.

Видалення користувача

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

Краще:

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

Користувач після звільнення працівника

Після звільнення потрібно:

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

Тимчасові користувачі

Тимчасові користувачі можуть створюватися для:

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

Для них потрібно вказувати:

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

Аудиторський доступ

Аудиторський доступ зазвичай має бути тільки для перегляду.

Аудитор може бачити:

документи;
звіти;
журнали;
довідники;
проводки;
історію змін.

Але не повинен:

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

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

Експорт даних — окрема зона ризику.

Користувач може експортувати:

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

Права на експорт потрібно обмежувати й журналювати.

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

Користувачі можуть мати доступ до персональних даних.

Наприклад:

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

Доступ до персональних даних має бути обмежений реальними потребами роботи.

Користувач і фінансові дані

Фінансові дані мають бути захищені.

До них можуть належати:

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

Не кожен користувач ERP має бачити фінансову інформацію.

Користувач і складські дані

Для складу важливо розділяти доступ.

Наприклад:

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

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

Собівартість — чутлива інформація.

Її не завжди мають бачити:

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

Права на собівартість потрібно виділяти окремо.

Користувач і закриті періоди

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

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

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

Користувач і друковані форми

Деякі користувачі можуть мати права на друк документів.

Наприклад:

рахунків;
накладних;
актів;
касових ордерів;
податкових документів;
договорів;
етикеток;
ТТН.

Права на друк теж можуть бути частиною контролю.

Користувач і повідомлення

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

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

Повідомлення допомагають не втрачати важливі події.

Користувач і робочий стіл

Робочий стіл користувача може відображати:

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

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

Користувачі при міграції з BAS або 1С

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

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

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

Чому не можна просто скопіювати користувачів із BAS

У старій BAS/1С часто буває хаос:

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

У K2 ERP потрібно створювати нову модель доступу, а не переносити старий хаос.

Таблиця міграції користувачів

Користувач у BAS	Статус	Роль у K2 ERP	Рішення
admin	Активний	Адміністратор	Створити окремий контрольований admin-доступ
manager	Спільний логін	Не переносити	Створити персональні логіни менеджерам
ivanenko	Активний	Менеджер продажів	Перенести як персонального користувача
old_buh	Звільнений	Немає	Не переносити, залишити в архіві історії
api_site	Сервісний	API сайту	Створити новий API-доступ з обмеженими правами

Етапи налаштування користувачів у K2 ERP

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

Описати організаційну структуру.
Описати ролі.
Описати групи користувачів.
Описати права доступу.
Визначити критичні дані.
Визначити сервісних користувачів.
Створити користувачів.
Призначити ролі.
Налаштувати підрозділи.
Налаштувати організації.
Налаштувати склади й каси за замовчуванням.
Перевірити доступи.
Провести тестування.
Навчити користувачів.
Заблокувати старі доступи в BAS після запуску.
Періодично переглядати права.

Матриця доступу

Матриця доступу — це таблиця, яка показує, хто що може робити.

Приклад:

Об’єкт / Роль	Менеджер	Комірник	Бухгалтер	Керівник	Адміністратор
Контрагенти	Створення	Перегляд	Зміна	Перегляд	Повний доступ
Замовлення	Створення і зміна	Перегляд	Перегляд	Перегляд	Повний доступ
Складські документи	Перегляд	Створення	Перегляд	Перегляд	Повний доступ
Каса	Немає	Немає	Повний доступ	Перегляд	Повний доступ
Зарплата	Немає	Немає	Обмежений доступ	Перегляд за дозволом	Повний доступ
Адміністрування	Немає	Немає	Немає	Немає	Повний доступ

Контроль після запуску

Після запуску K2 ERP потрібно перевірити:

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

Типові помилки в налаштуванні користувачів

Найчастіші проблеми:

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

Помилка: один логін на відділ

Погано:

manager / пароль для всіх менеджерів
sklad / пароль для всіх комірників
buh / пароль для всієї бухгалтерії

Наслідки:

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

Помилка: усі адміністратори

Якщо всім видати повні права, система стає неконтрольованою.

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

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

Помилка: не заблокували користувача після звільнення

Якщо працівник звільнився, але доступ залишився, виникають ризики:

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

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

Наприклад, сайт має доступ до:

усіх документів;
зарплати;
фінансів;
адміністрування;
зміни ролей.

Це небезпечно. API-користувач має бачити тільки ті дані, які потрібні для інтеграції.

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

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

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

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

Як правильно налаштовувати користувачів K2 ERP

Правильний підхід:

Створити персональні облікові записи.
Описати ролі.
Описати групи доступу.
Налаштувати мінімально необхідні права.
Розділити бізнес-користувачів і сервісні акаунти.
Обмежити доступ до зарплати, собівартості й фінансів.
Налаштувати підрозділи, склади, каси й організації.
Увімкнути журналювання важливих дій.
Перевірити права на тестових сценаріях.
Заблокувати старі BAS-доступи після запуску.
Регулярно переглядати права.
Документувати зміни в доступах.

Користувач K2 ERP і цифрова незалежність

Користувачі — це частина цифрової безпеки підприємства.

Під час переходу з BAS/1С у K2 ERP компанія повинна:

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

Цифрова незалежність. Перехід у K2 ERP — це можливість не тільки замінити BAS або 1С, а й навести порядок у користувачах, ролях, доступах, сервісних акаунтах, журналах і відповідальності.

Коротко

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

Висновок

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

Правильно налаштовані користувачі дозволяють:

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

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

Правильний підхід. Користувачі K2 ERP мають налаштовуватися через ролі, групи, підрозділи, організації, склади, каси, права доступу й журналювання. Мета — не просто дати людям доступ, а створити контрольовану, безпечну й зрозумілу модель роботи.

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

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

Див. також

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