Новий співробітник приступає до роботи, але на початку робочого дня він ще не має доступу до необхідних систем. При переведенні в інший відділ старі права зберігаються довше, ніж потрібно, а після звільнення керівник вручну згадує, які облікові записи та обладнання потрібно закрити.
Онбординг та звільнення часто сприймають як завдання відділу кадрів або системного адміністратора. На практиці це єдиний наскрізний процес, у якому беруть участь керівник, кадрова служба, ІТ-відділ, служба безпеки та співробітник, відповідальний за майно.
Розберемо, як автоматизувати цей маршрут, не надаючи зайвих прав і не передаючи критичні рішення системі.
Чому звичайного контрольного списку недостатньо
Таблиця із завданнями допомагає побачити загальний план, але вона не знає, що дата виходу змінилася, співробітника перевели в інший підрозділ або керівник не підтвердив роль. Одні пункти відмічають вручну, інші обговорюють у листуванні, а частина дій виконується без фіксації результату.
Через це доступ може з’явитися занадто пізно або залишитися після того, як він уже не потрібен. Обладнання замовляють двічі, пропускають обов’язкове навчання, а під час перевірки важко зрозуміти, хто дозволив конкретну дію.
З якої події починається процес
Надійний маршрут починається з підтвердженої кадрової події: прийняття на роботу, зміна посади, переведення, тривала відпустка або припинення роботи. Джерелом може бути кадрова система або узгоджена заявка з обов’язковими полями.
Для запуску потрібні щонайменше співробітник, підрозділ, керівник, роль, дата події та місце роботи. Якщо даних недостатньо, система не намагається вгадати права, а повертає запит відповідальній особі.
Як формується набір завдань
Після підтвердження події система створює завдання за заздалегідь затвердженим шаблоном ролі. Для одного співробітника це підготовка робочого місця та базових корпоративних сервісів, для іншого — доступ до CRM, ERP, складу або проектної документації.
- керівник підтверджує посаду та посадові обов’язки;
- Відділ кадрів перевіряє дату та кадрові дані;
- ІТ-відділ готує облікові записи та обладнання;
- особи, відповідальні за системи, призначають дозволені права;
- співробітник отримує інструкції та обов’язкові матеріали.
Завдання створюються не у вигляді одного довгого списку для всіх, а залежно від ролі та умов. Це зменшує кількість зайвих дій і дозволяє чітко визначити відповідального за кожен крок.
Як безпечно керувати доступом
Система автоматизації може підготувати запит на доступ, додати співробітника до дозволеної базової групи та повідомити власника системи. Однак розширені права, фінансові функції, публікація даних та доступ до конфіденційних розділів вимагають окремого підтвердження.
Права слід пов’язувати з посадою, а не копіювати у колеги. У двох менеджерів із схожими посадами можуть бути різні регіони, юридичні особи або ліміти. Копіювання чужого профілю переносить і ті дозволи, які новому співробітнику не потрібні.
Основний принцип: система виконує лише заздалегідь дозволені дії, а власник даних підтверджує доступ, який стосується грошей, персональних даних або критично важливих операцій.
Що змінюється під час переведення співробітника
Зміна посади — це не лише надання нових прав. У ході цього процесу слід порівняти попередню та нову роль, підготувати перелік змін та окремо вказати права доступу, які більше не відповідають обов’язкам.
Керівники колишнього та нового підрозділів підтверджують перехід у межах своїх повноважень. Після виконання зберігається історія: що додано, що відкликано, хто погодив виключення та до якої дати діє тимчасовий доступ.
Як відбувається звільнення
Завершення роботи запускає зворотний маршрут. Система створює завдання щодо повернення обладнання, передачі активних клієнтів та документів, відключення облікових записів, видалення з робочих груп та відкликання ліцензій. Термін кожної дії залежить від підтвердженої дати та політики компанії.
Критичне блокування доступу не повинно залежати від того, чи згадав керівник надіслати листа. При цьому кадрове рішення та момент блокування підтверджуються уповноваженими співробітниками: система автоматизації виконує правило, але не приймає рішення про звільнення.
Що робити з помилками та затримками
Не кожне завдання вдасться виконати з першого разу. Обліковий запис може вже існувати, обладнання — бути відсутнім на складі, а власник системи — не відповісти вчасно. Для таких ситуацій потрібен окремий статус, новий відповідальний та зрозуміле повідомлення керівнику.
Якщо один крок не виконано, процес не повинен автоматично позначати весь маршрут як завершений. Керівник бачить, що готово до першого дня, які права потребують підтвердження та що вимагає ручного втручання.
Як перевіряти та реєструвати дії
У журналі зберігаються джерело події, створені завдання, рішення осіб, що надають згоду, внесені зміни та помилки. Такий журнал потрібен не заради формальності: він допомагає швидко відновити стан співробітника та перевірити, чому доступ було надано або залишався активним.
Корисно регулярно порівнювати фактичні права з поточною роллю. Автоматизація життєвого циклу не замінює періодичний перегляд прав доступу, особливо для тимчасових проєктів та розширених повноважень.
Як запустити процес без зайвого ризику
- Обрати одну роль із широким колом обов’язків.
- Визначити достовірне джерело кадрової події.
- Розділити базові, розширені та тимчасові права.
- Призначити відповідального та термін для кожної дії.
- Перевірити прийняття на роботу, переведення та звільнення, включаючи помилки та зміну дати.
Який результат отримує бізнес
Співробітник отримує необхідні умови до узгодженої дати, керівник бачить готовність процесу, а власники систем зберігають контроль над конфіденційними правами. У разі зміни ролі або звільнення зайві права доступу не губляться у листуванні.
Цінність такої автоматизації полягає не в кількості надісланих повідомлень. Вона створює єдиний керований маршрут, де подія підтверджена, відповідальність розподілена, винятки помітні, а кожну зміну можна перевірити.
