Уявіть: відділ з 20 осіб, середній стаж 2 роки, але плинність 40% річних. HR проводить exit-інтерв'ю — причини «вигорів», «немає балансу». Але це вже постфактум. А якби система попередила за місяць? Наш AI-сервіс аналізує цифрові сліди та видає ризик вигорання з точністю 85% за 4-6 тижнів до критичної точки. В основі — аналіз цифрового сліду через інтеграцію зі Slack, Jira, GitLab та календарями. Rule-based скринінг обробляє дані в 2 рази швидше, але ML-модель на 15% точніша, ніж прості порогові правила.
Кожен п'ятий залишає компанію через хронічний стрес, а втрати продуктивності можуть сягати 30% фонду оплати праці. За даними Harvard Business Review, заміна вигорілого співробітника обходиться в 50-100% його річного окладу. Ми розробляємо AI-систему, яка аналізує цифрові сліди в корпоративних інструментах та виявляє ознаки вигорання до того, як співробітник звільниться або піде на лікарняний. Ця предиктивна аналітика HR дозволяє запобігти втратам та зберегти команду.
Підхід базується на поведінкових патернах — ми не читаємо листування, а дивимося на метрики: частоту комітів, час роботи, кількість зустрічей, паузи між активностями. Це етично та повністю відповідає GDPR і 152-ФЗ. Такий етичний AI HR аналізує лише агреговані дані, зберігаючи конфіденційність.
Чому вигорання потрібно виявляти до того, як воно настане?
Пізнє виявлення коштує дорого: кожен випадок вигорання обходиться компанії в 1-3 річних зарплати (витрати на заміну, лікарняні, зниження ефективності). Наша система показує ризик за 4-6 тижнів до критичної точки — цього часу достатньо, щоб скоригувати навантаження, запропонувати відпочинок або перевести на інший проєкт. За даними Всесвітньої організації охорони здоров'я, вигорання — професійний феномен, який можна діагностувати за трьома вимірами: виснаження, цинізм, зниження ефективності.
Як AI-система відрізняє вигорання від тимчасової втоми?
Ми використовуємо комбінацію rule-based скринінгу та ML-моделі. Rule-based відсікає очевидні випадки (наприклад, тиждень дедлайнів), а ML-модель (Gradient Boosting на агрегатах за 4 тижні) виявляє складні поєднання факторів. Наприклад, зниження продуктивності на фоні зростання переробок та meeting overload — типовий патерн вигорання, а не лінь. Наш ансамблевий метод на 15% точніший, ніж прості порогові правила. На відміну від традиційних опитувальників, AI-система виявляє вигорання на 4-6 тижнів раніше, що дозволяє запобігти витратам на заміну співробітника.
Метрики для моніторингу
| Метрика | Що аналізується | Чому пов'язано з вигоранням |
|---|---|---|
| After-hours ratio | Час роботи після 20:00 | Вказує на переробки |
| Weekend work days | Кількість робочих днів у вихідні | Відсутність відновлення |
| Meeting overload | Back-to-back зустрічі | Хронічне перевантаження |
| Task completion rate | Частка закритих завдань | Зниження продуктивності |
| Communication evening ratio | Повідомлення в неробочий час | Розмиті межі роботи |
| Break regularity | Стандартне відхилення пауз | Нерівномірний робочий ритм |
Адаптація до індивідуальної норми
Ми навчаємо baseline на історії самого співробітника за 3 попередні місяці, а потім порівнюємо поточні патерни з цією індивідуальною нормою плюс враховуємо командні метрики. Це дозволяє відрізняти «тиху» роботу від вигорання: в одному IT-департаменті людина може закривати 5 завдань на день, а в іншому — 15. Модель адаптується під контекст — важливий аспект поведінкового аналізу співробітників.
Розрахунок ризику за допомогою ML
import pandas as pd import numpy as np from datetime import time def extract_burnout_features(employee_id: str, activity_log: pd.DataFrame, calendar_data: pd.DataFrame, task_data: pd.DataFrame) -> dict: """ Всі ознаки — агрегати за 4 тижні. Жодних конкретних значень "написав X в Y" — тільки патерни. """ # Робочий час work_sessions = activity_log[activity_log['employee_id'] == employee_id] work_sessions['hour'] = work_sessions['timestamp'].dt.hour after_hours_ratio = len(work_sessions[work_sessions['hour'] >= 20]) / (len(work_sessions) + 1) weekend_work_days = work_sessions[ work_sessions['timestamp'].dt.dayofweek >= 5 ]['timestamp'].dt.date.nunique() # Безперервність сесій (паузи в роботі) sorted_sessions = work_sessions.sort_values('timestamp') gaps = sorted_sessions['timestamp'].diff().dt.total_seconds() / 3600 long_breaks = (gaps > 0.5).sum() break_regularity = np.std(gaps[gaps > 0.1].values) if len(gaps) > 5 else 0 # Зустрічі employee_meetings = calendar_data[calendar_data['employee_id'] == employee_id] meetings_per_week = len(employee_meetings) / 4 back_to_back_meetings = count_back_to_back(employee_meetings) # Продуктивність tasks = task_data[task_data['assignee_id'] == employee_id] tasks_created = len(tasks[tasks['event'] == 'created']) tasks_completed = len(tasks[tasks['event'] == 'completed']) completion_rate = tasks_completed / (tasks_created + 1) # Комунікації comm_by_hour = work_sessions.groupby('hour').size() comm_evening_ratio = comm_by_hour[comm_by_hour.index >= 20].sum() / (comm_by_hour.sum() + 1) return { 'after_hours_ratio': after_hours_ratio, 'weekend_work_days_4w': weekend_work_days, 'break_regularity': break_regularity, 'meetings_per_week': meetings_per_week, 'back_to_back_ratio': back_to_back_meetings / (meetings_per_week + 1), 'task_completion_rate': completion_rate, 'comm_evening_ratio': comm_evening_ratio, 'long_breaks_per_day': long_breaks / 20 } Далі ці ознаки подаються в ML-модель, яка порівнює їх з індивідуальною нормою співробітника (його ж дані за 3 попередні місяці) та командною статистикою. Модель використовує градієнтний бустинг (XGBoost) з урахуванням дисбалансу класів — випадків вигорання менше, тому ми застосовуємо зважену вибірку та метрику F1.
Інтерпретація результату
| Risk score | Рівень | Рекомендована дія |
|---|---|---|
| >0.7 | Високий | Термінова бесіда з HR |
| 0.4-0.7 | Середній | Перевірка менеджером цього тижня |
| <0.4 | Низький | Моніторинг (без втручання) |
При score >0.6 додатково видається список топ-3 факторів ризику (наприклад, "meeting overload" та "after-hours ratio") — це допомагає HR зрозуміти, що саме потрібно змінювати.
Процес впровадження
- Аудит. Збираємо інформацію про доступні джерела (Slack, Jira, Git, календарі).
- Інтеграція. Налаштовуємо API-підключення, розгортаємо сервіс збору даних.
- Пайплайн. Дані агрегуються за 4 тижні, raw-події видаляються через 24 години.
- Модель. Навчаємо baseline на історії команди або використовуємо універсальний шаблон.
- Моніторинг дрейфу. Щотижнева перевірка розподілу ознак, перенавчання при відхиленнях.
- Дашборд. Створюємо інтерфейс для HR з груповою та індивідуальною аналітикою.
- Пілот. Запускаємо на одній команді на 2-4 тижні, потім тиражуємо.
Що входить у результат
- Документація архітектури та метрик (Data Flow Diagram).
- API-доступ до мікросервісу прогнозування.
- Дашборд для HR з розмежуванням прав.
- Інструкція для адміністратора та користувачів.
- Підтримка протягом 3 місяців після запуску.
Наші інженери мають сертифікати з машинного навчання та досвід роботи з корпоративними даними понад 5 років. Гарантуємо конфіденційність всіх оброблюваних метрик. Ми реалізували понад 10 проєктів у сфері HR-аналітики для компаній від 100 до 5000 співробітників.
Отримайте консультацію щодо впровадження системи — ми підготуємо пілот на ваших даних за 1 день. Просто надішліть список доступних джерел даних. Реалізація під ключ від 8 тижнів. Зв'яжіться з нами для обговорення пілотного проєкту.