Права доступу співробітників: хто що бачить у CRM, магазині й обліковій системі

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

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

Чому «дати всім усе» — не економія часу

Найчастіший інцидент у малих компаніях — не зловмисний, а випадковий. Масова зміна цін замість однієї позиції, видалена категорія, розсилка не на ту базу, замовлення, скасовані «щоб не заважали». Відновлення таких дій коштує днів, а іноді неможливе взагалі, якщо резервної копії не було.

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

Третій — плутанина у відповідальності. Коли всі можуть усе, ніхто не відповідає за конкретне: неможливо сказати, хто змінив статус замовлення й чому.

Мінімальна схема ролей

Для більшості компаній достатньо чотирьох рівнів.

Власник або адміністратор — повний доступ, зокрема керування правами інших. Ця роль має бути в однієї-двох людей, не більше.

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

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

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

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

Що лишається тільки у власника

Незалежно від розміру компанії й ступеня довіри, пʼять речей не роздають:

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

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

Де обмеження починають заважати

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

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

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

Звільнення: список, який має бути готовим заздалегідь

Доступи закривають у день звільнення, і завжди виявляється, що систем більше, ніж памʼятали: основна система, пошта, робочі чати, спільні документи, панель сайту, рекламні кабінети, банк-клієнт, сервіси розсилок.

Тому список систем компанії з відповідальними варто вести постійно — це пʼять рядків у документі, які рятують від ситуації «через півроку зʼясувалося, що доступ лишався». Особисті облікові записи не передають наступнику, а закривають і створюють нові: спільний пароль на кількох людей знищує будь-яку відповідальність.

Заодно це привід перевірити резервні копії — вони страхують не тільки від зламу, а й від помилок своїх. Про це є окремий матеріал про резервне копіювання сайту.

Як це виглядає в системах

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

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

Коротко

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

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