HREvio
Журнал змін HR
Що таке Журнал змін HR?
Журнал змін HR - це захищений від підробки запис того, хто, що і коли змінив у системі - правки карток, зарплат і погодження відпусток - для підзвітності та комплаєнсу.
Журнал змін перетворює суперечки на факти: хто погодив ту відпустку, хто змінив ту зарплату і коли. Хороші журнали маскують чутливі поля, щоб сам журнал не зливав дані, які відстежує.
Що фіксує запис у журналі
Корисний запис сам відповідає на кожне питання про зміну, без перевірок в іншій системі й розпитувань колег.
| Поле | Приклад | Навіщо це |
|---|---|---|
| Хто діяв | Anna Weber, HR-адміністраторка | За кожною зміною стоїть конкретна людина або "System" для запланованих задач. |
| Кого стосується | Marek Nowak | Один фільтр показує всю історію працівника - це розв'язує суперечки й допомагає відповідати на запити доступу за GDPR. |
| Що сталося | змінено, погоджено, невдалий вхід | Фіксований перелік назв подій робить журнал придатним для пошуку. |
| Який запис | Заява на відпустку, 13-17 квіт | Пов'язує запис саме з тим об'єктом, що змінився, наприклад з конкретною заявою на відпустку. |
| До і після | Статус: очікує -> погоджено | Старе й нове значення перетворюють питання "хто це змінив?" на факт. |
| Коли | 2026-03-03 11:02:14 UTC | Зберігається в UTC і показується в часовому поясі читача, тож записи з різних офісів сортуються правильно. |
| Звідки | IP 203.0.113.42, Firefox на Linux | Зберігається для входів та інших подій безпеки, щоб помітити зловживання обліковим записом. |
Як виглядає журнал змін
Ось місяць одного працівника в журналі, від найстарішого запису. Зверніть увагу, чого там немає: нової зарплати й нової домашньої адреси.
| Час (UTC) | Хто | Дія | Запис | Зміна |
|---|---|---|---|---|
| 2026-03-02 09:14 | Anna Weber | змінено | Профіль працівника: Marek Nowak | Посада: Developer -> Senior developer |
| 2026-03-02 09:15 | Anna Weber | змінено | Компенсація: Marek Nowak | Сума: [encrypted] -> [encrypted], діє з 2026-04-01 |
| 2026-03-03 11:02 | Tom Fischer | погоджено | Заява на відпустку: 13-17 квіт, 5 днів | Статус: очікує -> погоджено |
| 2026-03-04 08:40 | Marek Nowak | змінено | Власний профіль | Адреса: [redacted] -> [redacted] |
| 2026-03-05 22:17 | невідомо | невдалий вхід | Обліковий запис: Marek Nowak | IP 203.0.113.42, Firefox на Linux, хибний пароль |
| 2026-04-01 00:05 | System | нараховано | Баланс відпустки: Marek Nowak | Баланс: 12,5 -> 14,5 дня |
Маскування навмисне: журнал доводить, що зарплата й адреса змінилися і хто їх змінив, але не стає другою копією цих даних.
Один запис зсередини
Зміна зарплати з прикладу в тому вигляді, у якому вона зберігається. Суму маскують ще до того, як запис потрапить у журнал, тож навіть сирий експорт журналу не розкриває зарплат.
{
"id": "0192f1c4-7b3e-7a10-9c1d-3f5e8a2b6d41",
"log": "compensation",
"event": "updated",
"actor": { "id": "u-118", "name": "Anna Weber" },
"subject": { "type": "compensation", "id": "c-2291" },
"employee": { "id": "u-342", "name": "Marek Nowak" },
"changes": {
"old": { "amount": "[encrypted]", "effective_from": "2025-04-01" },
"new": { "amount": "[encrypted]", "effective_from": "2026-04-01" }
},
"created_at": "2026-03-02T09:15:42Z"
}Що записувати в HR-системі
Записуйте кожну зміну, яку хтось може згодом оскаржити, і кожну подію, що стосується доступу. Звичайні перегляди записів зазвичай лишаються поза журналом: запис кожного перегляду сторінки ховає зміни, які справді важать.
| Сфера | Події |
|---|---|
| Картки працівників | Створено, змінено, звільнено, відновлено; змінено керівника або відділ |
| Оплата | Зміни зарплати, типу оплати й графіка виплат із датою набуття чинності |
| Відпустки | Подано, погоджено, відхилено, скасовано; ручні коригування балансу |
| Доступ і безпека | Входи й невдалі входи, скидання паролів, зміни ролей і прав, вхід підтримки від імені користувача |
| Автоматичні задачі | Нарахування відпусток, перенесення залишку на новий рік, масові імпорти - записуються з "System" як виконавцем |
Чого не має бути в журналі
Журнал змін часто зберігають довше й читає його більше людей, ніж дані, які він відстежує, тож він не повинен ставати чорним ходом до них. Фіксуйте, що чутливе поле змінилося і хто його змінив, а саме значення маскуйте: зарплати, банківські реквізити, домашні адреси, дати народження.
Дечому там узагалі не місце: паролям, посиланням для скидання й API-ключам, а також даним про здоров'я, як-от діагнозу за лікарняним, - це особлива категорія даних за статтею 9 GDPR.
Захистіть і сам журнал. Записи лише додаються, їх ніколи не редагують і не видаляють у застосунку; читати журнал можуть лише власники та адміністратори; зберігається він визначений строк, достатній, щоб розв'язати суперечки й пройти аудити, після чого видаляється за розкладом.
Пов'язані терміни
Дивіться також
Застосуйте ці терміни на практиці
HR за фіксованою ціною для малого та середнього бізнесу. 30 днів безкоштовно, без картки, скасування будь-коли.
Спробуйте 30 днів безкоштовно