Представьте: отдел из 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 недель. Свяжитесь с нами для обсуждения пилотного проекта.