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

Чому прогнозування звільнень ламається на історичних даних

Прогнозування звільнень майже завжди починається однаково: беремо вивантаження з кадрової системи за кілька років, позначаємо працівників, які пішли, і навчаємо модель.

На демо метрики виглядають переконливо, а в проді половина «тих, хто йде» залишається, натомість ідуть ті, кого модель вважала лояльними. Причина не в алгоритмі — в історичних даних, які описують минулий стан компанії, а не поточний.

Перше джерело помилок — зміщення вибірки. У вивантаженні є лише ті, кого найняли і хто дійшов до звільнення; кандидати, яким відмовили, і працівники, які пішли до потрапляння в систему, до неї не потрапили.

Модель навчається на усіченій популяції і переносить її закономірності на всіх — звідси хибні спрацювання в підрозділах, яких в історії майже не було.

Друге — дисбаланс класів. Звільнення — рідкісна подія: на сотні працівників припадають одиниці випадків за період. За такого співвідношення моделі вигідніше передбачати «залишиться» і отримувати високу точність, нікого не знаходячи.

Лікується не підкручуванням порогу, а перезбиранням цільової змінної: горизонт прогнозу, визначення події, вага спостережень.

Третє — дрейф даних. Ознаки, значущі в минулому, втрачають силу: змінюється ринок, структура команд, політика оплати, сам процес найму.

Модель, навчена на старих зрізах, продовжує опиратися на застарілі залежності, і якість падає непомітно — метрики на відкладеній вибірці цього не показують.

Окремо варто якість історичних даних: заднім числом змінювалися грейди і керівники, частина звільнень оформлена як «переведення», причини закриті текстом у вільній формі.

Без розбору цих артефактів прогнозування звільнень перетворюється на вгадування, а не на управління плинністю персоналу. Розбираємо, як це закривається на етапі підготовки даних і валідації.

Що дає система прогнозування звільнень бізнесу

Система прогнозування звільнень працює не як «передбачення долі», а як інструмент пріоритизації уваги керівників.

Модель оцінює кожного співробітника за сукупністю сигналів — динаміка залученості, зміни в характері завдань, активність у внутрішніх сервісах, історія підвищень і ротації, поведінкові патерни в комунікації.

На виході — ймовірність виходу в заданому горизонті попередження, зазвичай від одного до трьох місяців. Цього достатньо, щоб у керівника залишився час на розмову, перегляд умов або планову заміну, а не на гасіння пожежі в момент заяви.

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

Тому пороги налаштовуються асиметрично: для критичних ролей чутливість вища, для лінійних позицій — баланс між навантаженням на керівників і реальними ризиками.

Точність моделі калібрується на історичних даних компанії, а не на галузевих середніх — патерни виходу в конкретній культурі та на конкретному ринку сильно різняться.

Практичний ефект складається з трьох вимірюваних величин. Горизонт попередження дає час на утримання співробітників: розмова відбувається до того, як людина почала активно шукати, а не після оффера на руках.

Частка утриманих співробітників із числа тих, хто потрапив у зону ризику, показує, скільки спрацьовувань конвертувалося в реальне рішення залишитися.

Зниження раптових втрат критичних ролей — найчутливіша метрика для бізнесу: вона напряму пов'язана з простоєм напрямів, зривом термінів і вартістю термінового найму.

Окремо варто враховувати, що система не замінює управлінське рішення, а змінює його контекст. Керівник бачить не «співробітник піде», а «ймовірність зросла, ось фактори, ось динаміка».

Це переводить розмову про утримання з площини особистих здогадів у площину роботи з конкретними причинами — перевантаженням, відсутністю зростання, розмитими зонами відповідальності.

Підходи до побудови моделі: порівняння варіантів

Вибір моделі для прогнозування звільнень — це компроміс між точністю, інтерпретованістю та вимогами до даних.

Прості правила на кшталт «немає підвищення понад рік — ризик» працюють як baseline: їх легко пояснити, але вони вловлюють лише очевидні випадки й дають багато хибних спрацювань.

Логістична регресія додає ваги ознакам і залишається прозорою: для кожного співробітника видно, який чинник підняв або знизив оцінку ризику.

Градієнтний бустинг на табличних даних зазвичай дає кращу роздільну здатність, але потребує пояснення через SHAP-значення або surrogate-модель, щоб результат залишався зрозумілим HR-команді.

На практиці ми частіше будуємо дворівневу схему: бустинг дає ранжування ризику, а логістична регресія або дерево на тих самих ознаках пояснює, чому співробітник потрапив до групи уваги.

Такий тандем закриває і точність, і інтерпретованість — а отже, і регуляторні вимоги до обґрунтування рішень, що впливають на людей.

Етапи впровадження системи прогнозування звільнень

Впровадження починається не з моделі, а з даних: без чесної картини кадрових подій будь-який прогноз залишиться гарною демонстрацією. Тому процес іде етапами, і на кожному фіксуємо критерій приймання — інакше незрозуміло, що саме передається в експлуатацію.

1. Аудит даних. Збираємо джерела: кадрові системи, табелі, оцінки, історію найму та зміни грейдів. Перевіряємо повноту, дублі, пропуски та розбіжності між системами. На виході — карта даних із переліком полів, які реально доступні на момент прогнозу, без витоків із майбутнього.
2. Розмітка цільової події. Домовляємося, що вважаємо звільненням: добровільний вихід, закінчення строку, вихід з ініціативи компанії — це різні класи. Фіксуємо горизонт прогнозу та вікно спостереження, щоб модель передбачала подію заздалегідь, а не констатувала її постфактум.
3. Побудова та валідація моделі. Навчаємо на історичних періодах і перевіряємо на пізніших — так виключаємо підгонку під минуле. Дивимося не лише на точність, а й на повноту за групами: модель не повинна «позначати» цілий відділ через зміщення в даних.
4. Пілот на обмеженій вибірці. Запускаємо прогноз за частиною підрозділів і звіряємо з реальними наслідками. Уточнюємо пороги спрацювання, щоб сигналів було достатньо для дій, але без потоку хибних тривог.
5. Впровадження в робочий контур. Вбудовуємо розрахунок у регулярний процес: оновлення даних, видача списку ризиків відповідальним, регламент роботи із сигналом. Визначаємо, хто і в який строк реагує.
6. Моніторинг і перенавчання. Відстежуємо частку спрацювань, якість на нових періодах і дрейф даних. У разі зміни структури чи ринку модель перенавчається на свіжому зрізі.
7. Передача та супровід. Віддаємо документацію, регламенти й доступи, навчаємо команду замовника. Далі — планові перевірки якості та оновлення моделі за узгодженим циклом.

Такий порядок дає передбачуваність: на кожному кроці видно, що вже працює і де ще є ризик. Опишіть вашу задачу — повернемося з оцінкою строків і планом за цими етапами.

Артефакти та документація, які залишаються у замовника

Проєкт закінчується не демонстрацією моделі, а передачею комплекту, за яким ваша команда зможе систему експлуатувати, перевіряти та розвивати без нас.

Для прогнозування звільнень це критично: ознаки змінюються разом з оргструктурою, а рішення має бути зрозумілим для HR і юридично захищеним. Нижче — що саме залишається у замовника.

• Документація моделі — призначення, цільова змінна (хто вважається таким, що звільнився, і в якому горизонті), межі застосовності та відомі обмеження. Окремим блоком — які рішення модель ухвалювати не повинна: вона ранжує ризик, а не виносить кадрові вердикти.
• Схема ознак — джерело кожної ознаки, формула розрахунку, вікно агрегації, обробка пропусків. Сюди ж входить перелік ознак, виключених з етичних і правових причин, з обґрунтуванням.
• Конфігурації — параметри навчання, розбиття на навчальну та контрольну вибірки, пороги спрацювання, налаштування регулярного перерахунку.
• Регламент перенавчання — тригери (зсув розподілу ознак, падіння якості, зміна оргструктури), періодичність, порядок валідації перед викаткою нової версії.
• Звіт про якість — метрики з розподілом за групами співробітників, а не лише загальна цифра: повнота та точність на рідкісному класі, калібрування ймовірностей, частка хибних спрацювань.
• Відтворюваність — зафіксовані версії даних і коду, інструкція з локального запуску, журнал змін моделі. Будь-який минулий прогноз можна перерахувати й отримати той самий результат.
• Регламент моніторингу — що дивитися в проді, які відхилення вважати деградацією, кому надходить сигнал.
• Протокол передачі — навчання вашої команди, розбір інцидентів, точки розширення.

Комплект розрахований на інженера, який не брав участі в розробці: за ним можна підняти систему з нуля, пояснити рішення перевіряючому та обґрунтувати кожну рекомендацію перед співробітником. Опишіть задачу — повернемося з оцінкою та планом.

Кейс: як знизили раптові втрати в роздрібній мережі

Що було до впровадження

Роздрібна мережа з плинністю персоналу в магазинах: керівники точок дізнавалися про звільнення продавця або адміністратора в момент заяви, а HR — постфактум, коли вакансія вже відкрита.

Заміна співробітника в роздрібі — це зміна графіка, навчання новачка та просідання виручки точки на період адаптації. Керуючі тонули в ручному аналізі: дивилися табелі, графіки відпусток і скарги, але закономірності вислизали — сигнали були розмазані по різних системах.

Що зробили

Наші інженери зібрали модель прогнозування звільнень, яка працює на даних, що вже є в контурі компанії: графік змін, стаж, історія переведень між точками, динаміка виробітку, лікарняні, затримки та плинність у конкретному магазині.

Окремо врахували сезонність і «ефект керуючого» — у точках з високою ротацією керівників ризик відходу вищий. Модель видає не абстрактний бал, а ймовірність відходу в найближчі тижні з розбивкою за факторами, щоб HR розумів, за що зачепитися в розмові.

Метрики до і після

Термін попередження виріс до кількох тижнів — цього достатньо, щоб підготувати заміну, передати справи та не втратити виручку точки.

Навантаження на HR змістилося з ручного перегляду даних на роботу з пріоритетним списком: система сама підсвічує, де ризик критичний, а де можна не втручатися.

Що це дало бізнесу

Мережа перестала втрачати людей «раптово»: відходи, які можна було запобігти, тепер видно заздалегідь, а ті, що неминучі, закриваються за планом. Керівники точок отримали зрозумілий сигнал, HR — інструмент пріоритизації, а бізнес — передбачуваність у графіку та виручці. Модель донавчається на нових даних, тому точність попереджень з часом зростає, а не деградує.

Чим відрізняється прогнозування звільнень від аналізу плинності?

Аналіз плинності відповідає на питання «що вже сталося»: рахує частку тих, хто пішов за період, розбиває її за підрозділами, ґрейдами, стажем, порівнює з минулим кварталом. Це ретроспектива — звіт за фактом, де подія звільнення вже відбулася і вплинути на неї неможливо.

Цінність такого аналізу в діагностиці: він показує, де проблема хронічна, але не дає часу на реакцію.

Прогнозна аналітика відповідає на інше питання — «хто піде найближчими тижнями і чому».

Модель оцінює кожного співробітника за сукупністю сигналів: динаміка залученості, зміна характеру комунікацій, перепрацювання, паузи в активності, зміна поведінки в робочих системах, історія підвищень і зворотного зв'язку.

На виході — ймовірність відходу з горизонтом прогнозу, зазвичай від кількох тижнів до кварталу. Чим коротший горизонт, тим вища точність, але тим менше часу на попереджувальні заходи.

Ключова відмінність — у вимогах до даних. Ретроспективі достатньо кадрової звітності: дати прийому та звільнення, причини, підрозділ.

Прогнозу потрібні різнорідні та регулярно оновлювані джерела, зведені до одного співробітника в часі: кадрові події, оцінки, результати опитувань, знеособлена активність у робочих інструментах.

Без історичної глибини в кілька циклів оцінки модель не навчиться — їй нема на чому побачити провісники відходу.

Друга відмінність — у тому, що робити з результатом. Аналіз плинності закінчується звітом для керівництва. Прогноз вбудовується в процес: сигнал надходить керівнику заздалегідь, разом із факторами ризику, і запускає конкретну дію — розмову, перегляд умов, зміну проєкту.

Саме тому прогнозування звільнень має сенс лише там, де є кому і чим відреагувати: без готових попереджувальних заходів навіть точна модель залишається красивою цифрою.

Часті технічні сумніви перед стартом

Сумніви зазвичай одні й ті самі: чи вистачить історичних даних, чи не доведеться перебудовувати облік, хто побачить персональні висновки і що буде з моделлю через пів року. Нижче — як ми закриваємо кожен із них на рівні архітектури, а не обіцянок.

Чи доведеться змінювати HR-систему або заводити другу базу?

Ні. Ми підключаємося до наявного контуру через штатні вивантаження та програмні інтерфейси, які вже підтримує ваша система обліку.

Дані забираються за розкладом, приводяться до єдиної схеми і складаються в окреме сховище — робоча база залишається недоторканою, навантаження на неї не зростає. Якщо облік рознесено по кількох джерелах, зводимо їх за стійким ідентифікатором співробітника.

Хто отримає доступ до персональних висновків?

Прогноз видно лише тим ролям, яким він потрібен за посадою, — як правило, це HR-партнер і прямий керівник. Рядові співробітники та суміжні відділи даних не бачать.

В інтерфейсі показуємо фактори ризику в знеособленому вигляді: «зміна керівника», «відсутність зростання», а не сирі персональні записи. Усі звернення до прогнозів пишуться в журнал — видно, хто і коли дивився картку.

Що буде з моделлю, коли зміняться процеси та ринок?

Модель застаріває разом із даними, тому ми закладаємо контроль перенавчання: раз на квартал рахуємо якість на свіжому зрізі й порівнюємо з минулим періодом. Якщо точність просідáє, модель перенавчається на актуальній історії, а стара версія залишається для відкату.

Ручні коригування HR-фахівців повертаються в навчання як розмітка — система з часом точніше відображає вашу специфіку.

Опишіть, які дані та системи у вас уже є, — повернемося з оцінкою реалістичності прогнозу та планом робіт.

Обговорімо ваше завдання прогнозування звільнень

Щоб розмова була предметною, а не «розкажіть про ваші завдання», корисно заздалегідь зібрати мінімум вхідних даних. Вони не потребують вивантаження персональних даних — достатньо структури та обсягів.

• Які категорії співробітників і підрозділи потрапляють у периметр: одна команда, філія, вся компанія.
• Які події фіксуються в облікових системах: прийом, переведення, зміни грейду, оцінювання, навчання, дисциплінарні відмітки.
• Який горизонт цікавий: попередити за місяць, за квартал, за півроку — від цього залежить і модель, і набір ознак.
• Що вже робили: рахували плинність вручну, будували звіти, пробували готові сервіси.
• Хто з боку замовника ухвалює рішення щодо кожного співробітника і як результат вбудується в цей процес.
• Які обмеження щодо даних діють усередині компанії: де можна зберігати, хто має доступ, що заборонено використовувати.

Далі робота йде за зрозумілим планом. Спочатку розбираємо завдання і домовляємося, що вважаємо відтоком і який горизонт прогнозу потрібен бізнесу.

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

На цьому етапі ви отримуєте оцінку термінів і розуміння, які кроки залежать від нас, а які — від готовності ваших систем.

Обговорення займає одну зустріч: розбираємо вхідні дані, ставимо уточнювальні запитання і повертаємося з оцінкою та планом. Якщо даних поки недостатньо, чесно скажемо, що потрібно підготувати в першу чергу, — це теж частина відповіді.