AI-прогнозування кадрових потреб: workforce planning

Уявіть: ваша компанія виграла великий контракт, але через місяць з'ясовується, що не вистачає інженерів-розробників, а найм senior-спеціаліста займає 100 днів. Або навпаки — після запуску продукту залишається 20% зайвого персоналу, і ФОП «з'їдає» прибуток. За досвідом наших проєктів, компанії без прогнозування кадрів втрачають до 30% виручки від не закритих вчасно вакансій і переплачують 15–20% фонду оплати праці на надлишковий штат. Ми будуємо AI-системи workforce planning, які за рахунок ML-моделей передбачають потребу в співробітниках на горизонті 1–3 роки з точністю ±10%. Наприклад, для мережі з 200 магазинів ми знизили надлишок персоналу з 18% до 4% за 6 місяців. Нижче — архітектура такого рішення та конкретні метрики.

Як AI-прогнозування знижує розрив між попитом і пропозицією?

Система будує Supply Model та Demand Model, потім виконує Gap Analysis. Згідно з Wikipedia, Workforce planning — це процес балансування попиту та пропозиції праці.

Supply Model (наявність персоналу):

• Поточна чисельність за посадами та рівнями.
• Прогноз убутку: звільнення (churn prediction), вихід на пенсію, декрет.
• Планові зміни: промоція, переведення, реструктуризація.
• Прогноз доступності за поточної HR-політики.

Demand Model (потреба в персоналі):

• Прогноз бізнес-метрик: виручка, обсяг виробництва, кількість клієнтів.
• Нормативи продуктивності: виручка на співробітника, звернень на оператора.
• Demand = Business Volume / Productivity Norm.

Gap Analysis:

def workforce_gap(demand_forecast, supply_forecast):
    gap = demand_forecast - supply_forecast
    return {
        'surplus': gap[gap > 0],
        'deficit': gap[gap < 0],
        'by_role': gap.groupby('job_family').sum(),
        'by_location': gap.groupby('location').sum()
    }

Чому AI прогнози точніші за традиційні методи?

Традиційні підходи (експертні оцінки, трендові моделі) дають похибку ±30% вже на рік вперед. ML-моделі враховують нелінійні залежності: churn, внутрішню мобільність, вплив автоматизації. Після калібрування точність досягає ±10% на горизонті 12 місяців. Додатково Monte Carlo симуляція supply дає ймовірнісні оцінки (P50, P90) — це критично важливо для risk-based планування.

Проблеми, які вирішуємо

Дефіцит співробітників. Якщо вакансія не закрита вчасно, бізнес втрачає контракти, падає NPS. Особливо критично для IT-компаній, де time-to-hire senior-інженера — 90-120 днів. Використання workforce planning з ML дозволяє скоротити цей термін на 30%. Економія ФОП при цьому досягає 1,5–2 млн грн на рік на кожні 100 співробітників.

Надлишок персоналу. Зайві люди — це перевитрата ФОП. Наші клієнти скорочували надлишок з 20% до 5% після впровадження прогнозу. Економія ФОП досягає 20% на рік, що в грошовому вираженні становить до 2 млн грн на кожні 100 співробітників.

Невідповідність компетенцій. Skill gap вимагає перенавчання, яке дешевше зовнішнього найму. Ми включаємо L&D-рекомендації в план.

Supply і Demand моделі

Як побудувати модель пропозиції

Retention модель. На основі churn prediction (окреме ML-завдання) з розбивкою за посадами та рівнями.

Retirement модель. Для країн з раннім виходом на пенсію — важлива компонента. Вхідні дані: вікова піраміда, пенсійний вік, історія виходу на пенсію за посадою.

Internal mobility. Історичні дані про частоту промоцій, переведень, ротації між відділами. Markov chain model:

# Transition matrix між рівнями (Junior → Mid → Senior → Lead)
transition_matrix = calculate_historical_transitions(hr_data)
# P(перейти на наступний рівень за рік) по кожній посаді

Модель попиту

Productivity drivers. Продуктивність не константа — змінюється при автоматизації, навчанні, зміні mix задач.

def demand_forecast(business_volume_forecast, productivity_model):
    """
    Business volume (виручка, обсяг) × прогнозована продуктивність
    → потреба в FTE (Full-Time Equivalents)
    """
    base_fte_need = business_volume_forecast / productivity_model.baseline
    # Коригування на автоматизацію
    automation_saving = productivity_model.automation_impact_3y
    adjusted_fte = base_fte_need * (1 - automation_saving)
    return adjusted_fte

Аналіз розривів

Результат gap-аналізу — конкретні цифри: скільки і яких співробітників не вистачає (або надлишок) за посадами, локаціями та часовими періодами.

Що дає сценарне планування кадрів?

Workforce Planning повинен включати сценарний аналіз:

• Базовий: зростання виручки 12% YoY, продуктивність +3%
• Оптимістичний: зростання 20%, продуктивність +5%
• Консервативний: зростання 5%, стагнація продуктивності
• M&A: поглинання конкурента (+300 FTE)

Для кожного сценарію — FTE потреба, gap, план найму. Monte Carlo симуляція supply дає ймовірнісні оцінки (P50, P90) для кожного сценарію.

Plan → Action

Recruitment Plan. Gap × час на закриття вакансії = терміни початку найму. Senior Engineer: time-to-hire 90-120 днів → почати найм за 4-5 місяців. Junior Analyst: 30-45 днів → 2 місяці.

L&D (Learning & Development) Plan. Якщо gap у навичках (skill gap) — програми перенавчання всередині компанії дешевші за зовнішній найм.

Succession Planning. High-risk посади (ключові, без заміни) → рання ідентифікація наступників.

Integrations. SAP SuccessFactors Workforce Planning, Workday Adaptive Planning, 1С:ЗУП 3.1 (українські компанії), Oracle HCM Cloud.

Які метрики підтверджують ефективність?

Що входить в проект

• Аудит HR-даних: оцінка повноти, якості та історичної глибини.
• Побудова Supply та Demand моделей з калібруванням під бізнес.
• Gap-аналіз з деталізацією за посадами, локаціями та часовими періодами.
• Сценарне планування (базовий, оптимістичний, консервативний, M&A).
• Інтеграція з HRIS (SAP SuccessFactors, Workday, 1С:ЗУП, Oracle HCM).
• Документація архітектури, моделі та інструкції для HR-аналітиків.
• Навчання команди роботі з дашбордами та інтерпретації прогнозів.
• Постпроектна підтримка: перенавчання моделі раз на квартал.

Впровадження: від аудиту до деплою

Терміни: базова модель з gap-аналізом — 6-8 тижнів. Повноцінна система зі сценарним аналізом, succession planning та HRIS-інтеграцією — 4-5 місяців. Вартість розраховується індивідуально — зв'яжіться для оцінки вашого проекту.

Чому обирають нас?

Більше 8 років досвіду, 30+ реалізованих проектів з AI-планування. Сертифіковані інженери з ML та HR-аналітики гарантують точність прогнозів не нижче ±15% на горизонті року. Пропонуємо рішення під ключ: від аудиту до навчання команди.

Зв'яжіться з нами для оцінки вашого проекту — ми запропонуємо оптимальне рішення. Замовте аудит HR-даних вже сьогодні і скорочіть незакриті вакансії на 30%.

Які проблеми прогнозування часових рядів зустрічаються найчастіше?

Фінансовий директор запитує прогнозування часових рядів продажів на квартал. Аналітик будує SARIMA, досягає MAPE 8.3% на тестовій вибірці — і з гордістю деплоїть. Через два місяці в production метрика падає до 23%. Причина класична: модель навчалася на даних до COVID, тестувалася на стабільному періоді, а production потрапив на промо-акцію та збій поставок. Data leakage + distribution shift = гарні цифри в ноутбуці та непрацюючий прогноз в реальності. Ми стикалися з цим десятки разів. Наш досвід — 5+ років у прогнозуванні часових рядів для рітейлу, фінтеху та IoT, більше 50 завершених проєктів.

Неправильна крос-валідація. Стандартний train_test_split для часових рядів — помилка. Випадкове розбиття створює data leakage: модель бачить «майбутні» значення в навчанні. Правильно — TimeSeriesSplit або walk-forward validation з expanding window.

Множинна сезонність. Погодинні дані споживання електроенергії мають три сезонності: добову (24 год), тижневу (168 год), річну (8760 год). SARIMA справляється лише з однією. Prophet обробляє кілька, але повільно масштабується на тисячі рядів.

Пропуски та аномалії в даних. Пропуск у сенсорних даних — це інформація (датчик відключився), а не просто NaN. Лінійна інтерполяція вбиває цей сигнал. Правильна обробка залежить від природи пропуску.

Cold start при ієрархічному прогнозуванні. Новий SKU в асортименті з 50 000 позицій: історичних даних немає, потрібен прогноз. Стандартні підходи тут не працюють — потрібні cross-learning підходи або feature-based методи.

Які інструменти і коли застосовувати?

Prophet (Meta) — чудовий старт для бізнес-даних із зрозумілою сезонністю та святами. Швидко налаштовується, інтерпретований, вбудована обробка викидів і пропусків. Падає в точності при нерегулярних патернах і не масштабується на десятки тисяч рядів без паралелізації. Prophet (Facebook) — офіційна документація.

Gradient boosting на фічах (LightGBM, XGBoost) — часто недооцінений підхід. Створюєте фічі вручну: лаги (t-1, t-7, t-28), ковзні середні, категоріальні ознаки (день тижня, місяць), екзогенні змінні. Модель навчається на всіх рядах одночасно — вирішує cold start через схожі ряди. MAPE на рітейл-прогнозуванні часто кращий за нейронні мережі при правильній feature engineering.

TFT (Temporal Fusion Transformer) — трансформер, спеціально розроблений для інтерпретованого прогнозування з коваріатами. Вбудовані механізми: variable selection (які ознаки важливі), temporal self-attention (які часові точки впливають на прогноз), квантильні передбачення. Доступний у pytorch-forecasting. Вимагає ~10 000+ записів на ряд для стабільного навчання. Temporal Fusion Transformer — академічна публікація.

PatchTST — трансформер, який ділить часовий ряд на патчі (аналогічно ViT для зображень). Краще захоплює локальні патерни, ніж класичні трансформери. Добре працює для long-horizon forecasting (прогноз на 96–720 кроків). Реалізація в neuralforecast від Nixtla.

N-HiTS, N-BEATS — нейронні архітектури без attention, швидші за TFT, конкурентна точність. N-BEATS виграє на M4/M5 benchmark для задач без коваріат.

Як ми розгортаємо TFT в production?

TFT потребує ретельної підготовки даних. Типовий пайплайн через pytorch-forecasting:

training = TimeSeriesDataSet(
    data,
    time_idx="time_idx",
    target="sales",
    group_ids=["store", "sku"],
    min_encoder_length=max_encoder_length // 2,
    max_encoder_length=max_encoder_length,  # 120 днів
    min_prediction_length=1,
    max_prediction_length=max_prediction_length,  # 28 днів
    static_categoricals=["store_type", "category"],
    time_varying_known_reals=["price", "promo_flag"],
    time_varying_unknown_reals=["sales"],
    target_normalizer=GroupNormalizer(groups=["store", "sku"], transformation="softplus"),
)

Часта помилка: target_normalizer за замовчуванням (StandardScaler) ламає передбачення для рядів з нульовими значеннями (немає продажів у вихідні). GroupNormalizer з transformation="softplus" — правильний вибір для count-даних.

Покрокова інструкція з налаштування TFT

1. Збір та підготовка даних. Обробити пропуски (маркувати NaN, інтерполювати лише якщо це технічний збій), агрегувати до потрібної частоти, сформувати коваріати (свята, промо, ціни).
2. Створення TimeSeriesDataSet. Вказати group_ids (наприклад, магазин+SKU), часовий індекс, горизонт прогнозу. Налаштувати target_normalizer з урахуванням розподілу таргета.
3. Навчання baseline. Спочатку Prophet або LightGBM — щоб зрозуміти, наскільки складніше завдання.
4. Тренування TFT. Запустити TemporalFusionTransformer з loss=QuantileLoss(), підібрати learning rate та розміри hidden шарів. Використовувати pytorch_forecasting або neuralforecast.
5. Валідація та інтерпретація. Перевірити walk-forward, проаналізувати variable selection, побудувати attention heatmap.

Кейс: прогноз попиту в рітейлі. Мережа з 120 магазинів, 8000 SKU, горизонт прогнозу 28 днів. Вихідна система: SARIMA окремо для кожного ряду, MAPE 18.4%, повний цикл перенавчання — 6 годин. TFT на PyTorch + pytorch-forecasting: одна модель на всі ряди, MAPE 11.2%, перенавчання — 40 хв на A10G. Додатковий бонус: feature importance через variable selection — з'ясувалося, що day_before_holiday впливає сильніше, ніж сама дата свята. Середня економія бюджету на інференсі для клієнта склала значну суму.

Як правильно оцінювати якість прогнозів?

Не використовуйте RMSE як єдину метрику — вона сильно штрафує за великі помилки на великих значеннях. Наш набір метрик для рітейл-прогнозування:

• MAPE — інтерпретована, але нестабільна при значеннях близьких до нуля
• sMAPE — симетрична версія, уникає ділення на маленькі числа
• MASE (Mean Absolute Scaled Error) — нормалізована відносно наївного сезонного прогнозу, чудово підходить для порівняння між рядами з різними масштабами
• Quantile loss / Pinball loss — для ймовірнісного прогнозування, оцінка покриття інтервалів

Гарантуємо: ми надаємо model card з цими метриками на валідаційній вибірці та результати walk-forward тесту на історії не менше 6 місяців.

Що входить в роботу

• Документація щодо обраної архітектури, обґрунтування вибору гіперпараметрів.
• Відтворюваний пайплайн навчання та інференсу (Docker + CI/CD + Airflow/Prefect).
• Код з коментарями та модульними тестами на ключові компоненти.
• Навчання вашої команди: як перенавчати модель, як інтерпретувати виходи, як деплоїти нові версії.
• Підтримка протягом 3 місяців після здачі: консультації, виправлення багів, доналаштування.

Процес роботи

Починаємо з EDA: візуалізація, тест ADF на стаціонарність, STL-декомпозиція, аналіз пропусків та викидів. Це 2–3 дні, але часто виявляє системні проблеми даних, які блокують прогнозування.

Потім: baseline (наївний seasonal, Prophet), feature engineering для LGBM, вибір архітектури нейронної мережі якщо потрібно. Walk-forward validation з реалістичним горизонтом. Деплой через API з автоматичним перенавчанням за розкладом через Airflow або Prefect.

Строки орієнтовно: MVP-прогноз на одному типі даних — 3–6 тижнів. Ієрархічна система прогнозування з автоматизацією — 2–5 місяців. Вартість розраховується індивідуально.

Наша команда — сертифіковані ML-інженери (AWS ML Specialty, GCP Professional ML Engineer). За 5 років на ринку реалізували понад 50 проєктів з прогнозування. Зв'яжіться з нами для безкоштовного аналізу ваших даних — ми оцінимо завдання та дамо перші рекомендації за 1–2 дні. Замовте консультацію і переконайтеся, що ваші прогнози працюють в production, а не тільки в ноутбуці.