ШІ у плануванні змін: як насправді працюють покриття, відпочинок і справедливість

Серйозна система планування зі ШІ складається з двох різних частин. Перша — розмовний асистент: він читає інструкції, розбирає наявні таблиці й PDF і перетворює розмиті побажання на кшталт «у пʼятницю ввечері потрібно більше людей» на структуровані налаштування. Друга — розвʼязувач: детермінований рушій, який бере ці налаштування й обчислює, хто коли працює, перевіряючи кожне правило для кожного можливого призначення.

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

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

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

Візьмімо кавʼярню як розібраний приклад. У понеділок можуть бути потрібні два бариста й один старший зміни з 08:00 до 12:00, три бариста в обідній пік з 12:00 до 15:00 і знову два з 15:00 до 18:00. Ці три інтервали описують реальну роботу значно точніше, ніж «пʼять людей у понеділок».

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

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

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

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

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

Класична помилка, якій це запобігає, — закриття з наступним відкриттям. Припустімо, Дана закриває локацію у вівторок о 23:00, а зміна відкриття в середу починається о 07:00. Проміжок — вісім годин. Якщо налаштований мінімум відпочинку вищий — скажімо, одинадцять чи дванадцять годин, — рушій просто ніколи не побачить Дану кандидаткою на це відкриття; їй, можливо, дістанеться денна зміна. Без послуг, втоми й переговорів: призначення неможливе за правилом.

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

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

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

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

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

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

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

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

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

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

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

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

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