Користувач BAS

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

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

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

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

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

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

Вступ

У BAS користувач є точкою входу в інформаційну базу.

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

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

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

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

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

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

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

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

Користувач	Призначення	Типовий доступ
ivanenko	Менеджер продажів	Контрагенти, замовлення, рахунки
petrenko_buh	Бухгалтер	Банк, каса, проводки, звітність
sklad_kyiv	Комірник	Складські документи, залишки, інвентаризація
api_site	Сервісний користувач	Обмін із сайтом

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

У BAS потрібно розрізняти користувача і фізичну особу.

Поняття	Що означає	Приклад
Користувач	Обліковий запис для входу в систему	ivanenko
Фізична особа	Людина як об’єкт кадрового або довідкового обліку	Іваненко Іван Іванович
Працівник	Фізична особа, пов’язана з трудовими відносинами	Менеджер відділу продажів

Одна фізична особа може бути пов’язана з користувачем, але це не завжди налаштовано правильно.

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

Обліковий запис потрібен для:

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

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

Погано:

user
admin
manager
buh
123
test

Краще:

ivanenko
petrenko.buh
sklad.kyiv.01
api_site
bi_export

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

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

Тип	Хто це	Приклад
Звичайний користувач	Працівник, який виконує щоденні операції	Менеджер, бухгалтер, комірник
Керівник	Користувач для перегляду звітів і контролю	Директор, фінансовий директор
Адміністратор	Користувач із розширеними правами	admin
Сервісний користувач	Технічний акаунт для інтеграцій	api_site, api_crm, api_wms
Тимчасовий користувач	Доступ для консультанта, аудитора або тестування	consultant, auditor
Архівний користувач	Старий заблокований користувач для збереження історії	old_ivanenko

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

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

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

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

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

Заблокований користувач

Заблокований користувач не повинен мати можливості входити в систему.

Блокування потрібне, якщо:

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

Зазвичай краще блокувати користувача, а не видаляти, щоб зберегти історію дій.

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

Видалення користувача може створити проблеми.

На користувача можуть посилатися:

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

Тому часто краще:

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

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

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

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

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

Ролі можуть бути типовими або доробленими під конкретну конфігурацію.

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

Роль	Що зазвичай дозволено	Що бажано обмежити
Менеджер продажів	Клієнти, замовлення, рахунки	Собівартість, зарплата, адміністрування
Комірник	Надходження, переміщення, інвентаризація	Фінанси, ціни закупівлі, зарплата
Бухгалтер	Банк, каса, проводки, податкові документи	Адміністрування без потреби
Касир	Касові документи, оплати	Складські й кадрові документи
Керівник	Звіти, контроль, аналітика	Зміна первинних документів без потреби
Адміністратор	Налаштування, користувачі, права	Щоденна робота під admin-логіном

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

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

Вони можуть включати:

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

Приклад матриці доступу

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

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

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

Приклади груп:

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

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

Адміністратор BAS

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

Він може:

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

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

Важливо. Не варто використовувати адміністратора BAS для щоденної роботи, інтеграцій, обміну із сайтом або звичайного введення документів.

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

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

Приклади:

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

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

Чому інтеграції не повинні працювати під адміністратором

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

Сайт → BAS → користувач admin

Ризики:

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

Краще:

Сайт → BAS → api_site з обмеженими правами
CRM → BAS → api_crm з обмеженими правами
WMS → BAS → api_wms з обмеженими правами

Спільні логіни

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

Приклади:

manager
sklad
buh
operator
user

Це погана практика.

Наслідки:

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

Персональні логіни

Краще використовувати персональні логіни.

Наприклад:

ivanenko
petrenko
kovalenko.sklad
melnyk.buh
shevchenko.sales

Переваги:

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

Автентифікація користувача

Автентифікація — це перевірка користувача під час входу.

У BAS можуть використовуватися різні способи входу залежно від налаштувань:

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

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

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

Паролі мають бути захищені.

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

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

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

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

Користувач і журнал реєстрації BAS

Журнал реєстрації показує події в інформаційній базі.

Він може фіксувати:

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

Приклад:

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

Навіщо потрібен журнал реєстрації

Журнал реєстрації потрібен для:

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

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

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

Звіти можуть містити чутливі дані.

Наприклад:

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

Не кожен користувач має бачити всі звіти.

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

Обробки можуть виконувати масові або критичні дії.

Наприклад:

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

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

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

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

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

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

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

У BAS можуть бути персональні дані:

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

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

Користувач і зарплата

Зарплатні дані є особливо чутливими.

До них не повинні мати доступ:

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

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

Собівартість також є чутливою інформацією.

Її варто обмежити для:

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

Інакше може бути витік комерційної інформації.

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

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

Наприклад:

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

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

Каса потребує окремого контролю.

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

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

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

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

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

Права можуть включати:

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

Користувач і інтеграції

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

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

Приклад:

Сценарій	Користувач	Ризик
Обмін із сайтом	api_site	Має зайві права
Обмін із CRM	api_crm	Передає зайві дані
Завантаження Excel	manager	Помилка в даних
Імпорт банку	buh	Неправильні платежі
BI-вивантаження	bi_export	Витік фінансової аналітики

Користувач і веб-клієнт BAS

Якщо використовується Веб-клієнт BAS, користувач може входити через браузер.

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

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

Користувач і клієнт-серверний режим BAS

У клієнт-серверному режимі BAS користувач підключається до бази через сервер.

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

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

Користувач і файловий режим BAS

У файловому режимі BAS важливо контролювати не тільки користувачів у BAS, а й доступ до папки бази.

Ризик:

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

Користувач і конфігурація BAS

Права користувачів залежать від конфігурації BAS.

У конфігурації визначаються:

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

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

Користувачі при міграції з BAS у K2 ERP

Під час переходу в K2 ERP потрібно виконати інвентаризацію користувачів.

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

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

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

У старих базах BAS часто є проблеми:

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

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

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

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

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

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

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

Матриця доступу для міграції

Приклад:

Роль у бізнесі	BAS-користувачі	Роль у K2 ERP	Коментар
Менеджер продажів	ivanenko, shevchenko	Менеджер продажів	Персональні логіни
Комірник	sklad, sklad2	Комірник	Замість спільних логінів створити персональні
Бухгалтер	buh1, buh2	Бухгалтер	Обмежити організації й періоди
Керівник	director	Керівник	Звіти й BI без зайвого редагування
Інтеграція сайту	admin або api_site	api_site	Тільки API з обмеженими правами

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

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

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

Типові помилки з користувачами BAS

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

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

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

Погано:

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

Наслідки:

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

Помилка: усі мають адміністративні права

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

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

Помилка: не заблокувати звільненого працівника

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

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

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

Наприклад, користувач `api_site` має повні права.

Це небезпечно, бо сайт або зовнішній сервіс не повинен бачити:

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

Помилка: не перевірити журнал реєстрації

Журнал може показати:

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

Якщо його не перевірити, можна пропустити важливі процеси перед міграцією.

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

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

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

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

Як правильно працювати з користувачами BAS перед міграцією

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

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

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

Аналіз користувачів BAS — це частина виходу зі старої ризикової системи.

Компанія повинна:

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

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

Коротко

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

Висновок

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

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

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

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

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

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

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

Див. також

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