Разработка AI-системы мониторинга выгорания сотрудников

Представьте: отдел из 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 недель раньше, что позволяет предотвратить затраты на замену сотрудника.

Адаптация к индивидуальной норме

Мы обучаем 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.

Интерпретация результата

При score >0.6 дополнительно выдаётся список топ-3 факторов риска (например, "meeting overload" и "after-hours ratio") — это помогает HR понять, что именно нужно менять.

Процесс внедрения

1. Аудит. Собираем информацию о доступных источниках (Slack, Jira, Git, календари).
2. Интеграция. Настраиваем API-подключения, разворачиваем сервис сбора данных.
3. Пайплайн. Данные агрегируются за 4 недели, raw-события удаляются через 24 часа.
4. Модель. Обучаем baseline на истории команды или используем универсальный шаблон.
5. Мониторинг дрейфа. Еженедельная проверка распределения признаков, переобучение при отклонениях.
6. Дашборд. Создаём интерфейс для HR с групповой и индивидуальной аналитикой.
7. Пилот. Запускаем на одной команде на 2-4 недели, затем тиражируем.

Что входит в результат

• Документация архитектуры и метрик (Data Flow Diagram).
• API-доступ к микросервису прогнозирования.
• Дашборд для HR с разграничением прав.
• Инструкция для администратора и пользователей.
• Поддержка в течение 3 месяцев после запуска.

Наши инженеры имеют сертификаты по машинному обучению и опыт работы с корпоративными данными более 5 лет. Гарантируем конфиденциальность всех обрабатываемых метрик. Мы реализовали более 10 проектов в области HR-аналитики для компаний от 100 до 5000 сотрудников.

Получите консультацию по внедрению системы — мы подготовим пилот на ваших данных за 1 день. Просто пришлите список доступных источников данных. Реализация под ключ от 8 недель. Свяжитесь с нами для обсуждения пилотного проекта.