Автоматизація управління персоналом: мій досвід як аналітика

💡 Усі статті, обговорення, новини для аналітиків — в одному місці. Приєднуйтесь до Analysts спільноти!

Мене звати Дмитро Михайленко, я аналітик в UBM SOFT. Нещодавно ми запустили масштабний проєкт з автоматизації WFM-системи для великого ритейлера — і він став для мене особистим еталоном того, як має виглядати справжня синергія бізнесу та IT. Але за красивим результатом стоять місяці роботи, кілька серйозних концептуальних помилок і один момент, коли я всерйоз думав, що ми зайшли у глухий кут. Цей матеріал — для аналітиків, які працюють із нетривіальною бізнес-логікою і хочуть не наступати на ті самі граблі.

Коли замовник приходить не з проблемою, а з алгоритмом

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

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

Мій головний виклик звучав не як «полагодити щось», а як «перекласти їхню унікальну логіку мовою Odoo, не втративши жодного нюансу». Це зовсім інша задача. І, як з’ясувалося, значно складніша, ніж здається на перший погляд.

Коли в системі 10 000+ співробітників і понад 200 000 змін щомісяця — помилка в алгоритмі обходиться надто дорого.

Перша помилка: я недооцінив контекст «живих» процесів

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

Проблема виявилася в деталях. Частина логіки існувала лише в головах менеджерів, які щодня «дотискали» Telegram-боти вручну. Вони вносили дрібні корекції, про які навіть не думали як про правила — це просто «так робимо завжди».

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

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

Як ми будували «Картку магазину»: від таблиць до живого організму

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

Тому замість стаціонарних таблиць ми одразу будували «Картку магазину» — єдиний цифровий профіль, де FTE, норми КЗПП та розподіл змін є частиною одного зв’язаного об’єкта. Зміна в одному місці автоматично поширюється на всі залежні розрахунки.

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

Норма штату як доміно: чому одна цифра змінює весь графік

Другий великий блок — управління нормою штату. Логіка тут проста: банк годин магазину на місяць залежить від норми штату та норми КЗпП. Фіксована сума, але всередині місяця вона розподіляється нерівномірно — залежно від навантажувальних характеристик конкретного дня.

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

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

Найскладнішим було визначити пріоритети цих конфліктів. Що важливіше: витримати норму КЗПП чи закрити пікове навантаження в конкретний день? Відповідь не завжди однозначна, і ми витратили чимало часу на узгодження пріоритетів з бізнесом — щоб закласти їх у логіку системи, а не залишати на розсуд кожного менеджера окремо.

Є один момент, про який не дуже приємно писати, але він важливий.

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

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

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

Підхід до контролю: прозорість без мікроменеджменту

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

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

Ми також мінімізували людський фактор там, де це можливо. Система автоматично фіксує порушення — наприклад, якщо зміна перевищує допустиму тривалість або між змінами недостатній відпочинок. Управлінець бачить лише результат: «є порушення, ось де». Йому не треба самому перевіряти сотні рядків табеля.

Це принципово важливо при масштабі в 10 000+ співробітників. Жодна людина фізично не здатна переглянути всі записи — система повинна робити це сама і виносити на поверхню лише ті випадки, які потребують уваги.

Що дав цей проєкт мені особисто

Після цього проєкту я інакше думаю про роль аналітика.

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

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

Є речі, які розумієш тільки в процесі. Одна з них — де проходить межа між «підлаштуватися під платформу» і «зробити по-своєму».

Odoo — опінійна система. У неї є своє бачення того, як має виглядати бізнес-процес. І більшість часу це бачення розумне. Але іноді воно не збігається з реальністю конкретного бізнесу — і тоді доводиться вибирати.

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