Контекст Celonis прискорив найм в Uniper
Uniper підключила Context Model від Celonis до HR-агента в Microsoft Copilot Studio. Без процесного контексту агент називав загальні проблеми найму. З ним він знайшов 27 кандидатів, які залишалися у шортлисті понад 14 днів. Після запуску в продакшн середній час до підписання договору скоротився на 27 днів, а скринінг — на 13.
Uniper не купувала окремий ШІ-сервіс для рекрутингу: використала наявні дані Celonis і Copilot, доступний усім працівникам, провела два хакатони та описала реальні процеси. Кейс показує, що точний бізнес-контекст перетворює загальні відповіді агента на вимірювані підказки.
Як перейти від даних до корисної відповіді агента
Uniper почала не з генеративного ШІ, а з опису фактичних процесів. Центр експертизи використовував Celonis для виявлення процесів, їх документування та пошуку можливостей для автоматизації. До роботи залучали бізнес-аналітиків і консультантів, щоб модель відображала реальний стан операцій, а не змушувала агента самостійно шукати закономірності в масиві даних.
Для рекрутингу цей підхід складався з послідовних кроків:
- зібрати дані із системи обліку кандидатів;
- перебудувати й описати наскрізний процес найму в різних підрозділах і країнах;
- очистити дані та отримати прозору картину етапів процесу;
- створити контекстну модель із правилами та фактичним станом процесу;
- порівняти відповіді Copilot без бізнес-контексту і з ним;
- перевірити, чи можна кількісно підтвердити висновки агента;
- лише після цього перенести рішення в повноцінну експлуатацію.
Практичний тест має бути сформульований як запит про конкретний процес: Які вузькі місця є в процесі рекрутингу та найму? Загальні слова на кшталт фрагментації даних або перевантаження менеджерів ще не дають підстав для дії. Корисна відповідь повинна називати конкретний етап, відповідальних працівників або заявки та показувати, де саме виникла затримка.
Ще два сценарії для HR-команди
Перший сценарій — персональний брифінг для менеджера з найму в Microsoft Teams. Агент повідомляє про нових кандидатів, додає посилання на відповідну заявку та нагадує про людей, з якими співбесіда вже відбулася, але рішення ще не зафіксоване. Робочі формулювання: Покажи нових кандидатів за моїми заявками та додай посилання і За якими кандидатами після співбесіди я ще не ухвалив рішення? Це зменшує ризик, що кандидат загубиться через незавершену адміністративну дію.
Другий сценарій — огляд великої кількості вакансій для рекрутера. Замість ручного перегляду системи агент формує персональну картину завдань і нагадує, де потрібне втручання. Запит може виглядати так: Покажи мої відкриті заявки, прострочені дії та кандидатів, які очікують наступного кроку. Цінність тут не в автоматичному рішенні, а в прозорості процесу та своєчасній реакції працівника.
Третій сценарій — пошук іншої відкритої позиції для кандидата, який добре пройшов співбесіду, але не підійшов на конкретну роль. Рекрутер може запитати: Чи є відкриті схожі вакансії, куди можна рекомендувати цього кандидата? Так інформація, яка раніше залишалася в головах окремих досвідчених працівників, стає доступною команді навіть після зміни її складу.
Де проходить межа автоматизації
Uniper використовує агента для адміністративних нагадувань, моніторингу процесу та пошуку інформації. Він не спілкується з кандидатами й не відбирає людей. Така межа принципова: застосування ШІ до HR-даних у ЄС може належати до категорії високого ризику, а автоматизація відбору створює небезпеку помилок і упередженого виключення окремих людей або груп.
Підхід також не спрацює як проста надбудова над неочищеними даними. До проєкту HR-команда періодично переносила Excel-файли в Power BI, а система обліку кандидатів не давала зручного огляду. Лише після перегляду процесу, очищення даних і створення контекстної моделі відповіді стали точнішими та придатними для кількісної перевірки.
Ще одна межа — спосіб упровадження. Окремий новий інструмент створив би додатковий бар’єр для працівників. Uniper розмістила агента в Microsoft Teams, де команда вже працювала, тому користувачам не довелося опановувати новий інтерфейс.
Що перевіряти перед довірою до результату
Типова помилка — оцінювати відповідь за переконливим формулюванням. Uniper перевіряла однаковий запит у двох режимах: без контекстної моделі агент називав універсальні проблеми, а з нею — конкретні відхилення у фактичному процесі. Інша помилка — одразу масштабувати рішення. Компанія почала з малих сценаріїв і двох хакатонів, де центральна команда разом із бізнесом визначала цінність для внутрішніх користувачів.
Перед дією працівник має перевірити:
- чи стосується відповідь його заявок, кандидатів і поточного етапу процесу;
- чи підтверджуються названі затримки даними системи обліку кандидатів;
- чи не підміняє агент рішення рекрутера або менеджера щодо людини;
- чи зрозуміло, яку адміністративну дію потрібно виконати;
- чи можна виміряти результат через тривалість етапів і незавершені завдання;
- чи пройшов проєкт погодження функцій корпоративного управління.
Використання вже перевірених технологічних партнерів полегшувало погодження, але сам процес контролю залишався ґрунтовним. Uniper також створювала цифровий реєстр ШІ-проєктів, щоб команди бачили чинні ініціативи й не дублювали однакову роботу.