Автоматизація понаднормових: від ручного обліку до годин, готових до нарахування зарплати

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

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

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

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

Чому звичайного обліку робочого часу недостатньо

Більшість інструментів обліку часу вміють зафіксувати, що людина працювала з 18:00 до 23:30. Це проста частина. Складніша — перетворити цей «сирий» проміжок на години, з якими справді може працювати нарахування зарплати. А це означає класифікацію, а не просто вимірювання.

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

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

Що саме потрібно автоматизувати

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

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

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

Коли одна зміна — це одразу два типи понаднормових

Візьмімо запит 18:00–23:30. На папері це п’ять із половиною годин понаднормових. На практиці, якщо компанія вважає все після 22:00 нічними годинами, це насправді дві речі: звичайні вечірні години з 18:00 до 22:00 і нічні — з 22:00 до 23:30 за вищою ставкою.

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

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

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

Які правила можна налаштувати

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

Усередині політики ви задаєте стільки типів понаднормових, скільки потрібно компанії, кожен зі своєю логікою:

• Назва типу, щоб усі читали однаковий підпис.
• Ставка — множник, що застосовується до звичайної оплати. Це варто сказати прямо: 1,5×означає повну ставку «півтори» — одна година зараховується як година й тридцять хвилин, — а не додаткові+150%поверх базової оплати. Базова оплата — це 1, 1,5 — це півтори ставки (типово для нічних годин), 2 подвоює її (типово для свят). Коли ви вводите значення, налаштування саме розшифровує математику — «1 год × 1,5 = 1 год 30 хв» — тож місця для плутанини +50%/+150% не лишається.
• Спосіб компенсації — виплата через нарахування зарплати чи відгул, задається окремо для кожного типу, тож одна політика може містити обидва.
• Умова автокласифікації — тип матчиться або за конкретними днями тижня,абоза типом дня (робочий день, неробочий день, державне свято чи оплачувана відпустка) — не обома одночасно, — а звузити його можна необов’язковим часовим проміжком, наприклад 22:00–06:00 для нічних годин. Якщо задано і правило дня, і часове вікно, для застосування типу мають виконатися обидва.
• Інструкції для погоджувача — текст, що з’являється тому, хто погоджує запит цього типу.

Один тип завжди лишається типом за замовчуванням — зі ставкою1×(базова оплата), без умов. Це запасний варіант для всього, що не збіглося з жодним правилом, тож жоден запит ніколи не лишається некласифікованим, і видалити цей тип не можна.

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

Погодження — частина автоматизації, а не додаток до неї

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

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

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

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

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

Що компанія перестає робити вручну

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

• Ділити зміну на частини калькулятором. Для зміни 18:00–23:30 ви більше не вираховуєте самі, що чотири години — звичайні, а півтори — нічні за іншою ставкою. Запит показує це двома рядками.
• Тримати ставки в голові чи в окремому файлі. «Неділя — 2×, після десятої вечора — 1,5×» перестає бути знанням однієї людини й стає налаштуванням, яке бачить кожен, хто працює із запитами.
• Перевіряти, чи правильний множник. Кожен запит показує тип і ставкудопогодження — співробітник і менеджер бачать однакову картину, перш ніж цифри підуть далі, а не після.
• Пояснювати менеджерам правила погодження руками. Інструкції спливають у момент рішення, а не в документі політики, який доводиться щоразу пересилати.
• Звіряти дані про понаднормові наприкінці місяця. Тип і правильна ставка вже прив’язані до кожного запиту, тож нічого збирати докупи заново.
• Переносити дані з обліку часу в нарахування зарплати через Excel. Класифіковані, погоджені години вже в експорті й готові рухатися далі.

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

Від точного обліку часу до даних, готових до нарахування зарплати

Результат усього цього — не просто охайна картка запиту на понаднормові. Це структуровані дані щодо кожного погодженого запиту:

• кількість годин,
• тип,
• ставка,
• спосіб компенсації,
• статус погодження.

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

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

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

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

Як автоматизувати облік понаднормових у PeopleForce — за п’ять кроків

Для команд, які вже в PeopleForce, налаштування коротке:

1. Перейдіть у Налаштування → Політики присутності й відкрийте потрібну політику (або створіть нову).
2. На кроці «Понаднормово» увімкніть перемикач обліку понаднормових.
3. Натисніть «Додати» і створіть тип: назва, ставка (множник звичайної оплати — напр., 1,5 для півтори ставки) і спосіб компенсації (нарахування зарплати чи відгул).
4. Якщо потрібно, задайте умову автокласифікації — конкретні дні тижня або тип дня (робочий день, неробочий день, державне свято, оплачувана відпустка) плюс часовий проміжок для нічних годин, якщо це важливо.
5. Збережіть. Тип одразу з’явиться в списку, і система почне автоматично застосовувати його до нових запитів.

З чого насправді починається автоматизація понаднормових

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