Procesarea cererilor de concediu nu este o singură sarcină, ci o serie de pași, iar acești pași nu evoluează toți în același ritm. Verificarea soldului și înregistrarea unei cereri în sistem este între timp adesea complet automatizată. Evaluarea unei cereri care intră în conflict cu ocuparea posturilor — doi angajați din aceeași echipă care doresc liber în aceeași săptămână — rămâne o decizie care revine unui responsabil, eventual cu un sistem care semnalează conflictul, dar nu îl rezolvă. Iar excepțiile, cum ar fi concediul în jurul unei reorganizări sau un angajat cu un traseu de absenteism în curs, rămân muncă umană fără discuție. Această pagină explică de ce sarcina se încadrează în acest moment predominant în blocul din mijloc: rpa care gestionează majoritatea cererilor, cu un om care evaluează restul.
O cerere de concediu are o formă fixă: un angajat, o perioadă, un sold, o normă de ocupare. Acest lucru face ca sarcina să obțină un scor ridicat pe axa gradului de structurare. Un sistem poate verifica cererea în raport cu soldul și cu regulile de ocupare stabilite în prealabil, și pe această bază poate aproba o cerere sau o poate transmite mai departe unui om. Acesta este exact motivul pentru care rpa efectuează deja acest tip de muncă astăzi: regulile pot fi surprinse în logică, iar volumul de cereri este de obicei suficient de mare pentru ca automatizarea să merite efortul. La o companie cu ture fixe și o politică de concediu simplă, această pondere este mai mare decât la o companie cu multe acorduri personalizate per angajat, unde regulile sunt stabilite mai puțin clar.
Motivul pentru care această sarcină nu trece complet la AI ține de marja de apreciere. De îndată ce o cerere intră în conflict cu ocuparea unei echipe, nu mai există un răspuns fix. Cine are prioritate: angajatul care a cerut primul, cel cu cea mai mare vechime în muncă sau cel cu un motiv medical? Aceasta este o decizie pe care un sistem o poate semnala, dar nu o poate lua fără ca cineva să poată explica motivul din spatele unei alegeri. Aceasta este și esența aprobării cu supraveghere: sistemul propune cererea, un responsabil aprobă sau respinge și poate motiva această decizie. La o companie cu ocupare redusă și mult concediu sezonier — gândiți-vă la sănătate sau la horeca — această pondere este mai mare decât la un mediu de birou cu marje de personal ample.
Volumul cererilor de concediu este adesea ridicat: fiecare angajat face acest lucru de mai multe ori pe an, iar la echipe mai mari acest lucru se ridică la un flux considerabil de cereri pe lună. Această repetiție face automatizarea atractivă, chiar dacă cererea individuală nu este complexă. Același tipar îl observăm la alte sarcini cu multă repetiție și reguli fixe, cum ar fi calcularea orelor suplimentare pe baza timpului lucrat sau procesarea modificărilor de program după concedii medicale sau cereri de schimb. În toate aceste cazuri, nu complexitatea unui singur caz este motivul automatizării, ci suma multor cazuri similare.
O aprobare eronată de concediu este de obicei reversibilă și nu duce la o pierdere financiară directă, ceea ce menține costul erorilor moderat. Totuși, sarcina atinge domeniul conformității: soldul de concediu este legat de condițiile de muncă, iar în cazul respingerii sistematice a cererilor, angajații pot contesta acest lucru. De aceea, un pas uman rămâne necesar în cazul abaterilor, nu pentru că sistemul nu poate gestiona latura de calcul, ci pentru că urmările unei decizii greșite necesită o justificare care poate fi explicată. Pentru deciziile care depășesc o simplă cerere de concediu — de exemplu, atunci când tiparele de concediu sunt luate în considerare în deciziile privind personalul — se aplică cerințe legale proprii asupra cărora această pagină nu se pronunță.
Repartizarea schițată aici nu se aplică uniform peste tot. O organizație cu reguli de aprobare clare și uniforme pe echipă și cu un sistem de concediu cu sold actualizat și conectat poate lăsa o parte mai mare a cererilor să se desfășoare fără intervenție. O organizație cu multe excepții, înregistrare manuală a soldului sau acorduri diferite între echipe va păstra o parte mai mare la nivel uman, pur și simplu pentru că nu sunt îndeplinite condițiile de bază pentru automatizare — reguli fixe și date actuale. Aceasta este aceeași dependență pe care o regăsiți la pregătirea procesării salariale pe baza posturilor fixe și la întocmirea programelor de lucru în limitele normelor de ocupare: cu cât regulile sunt stabilite mai strict în prealabil, cu atât mai mare este partea care se poate desfășura automat.
AI nu poate procesa cererile de concediu în mod independent și complet. Cea mai mare parte a cererilor de rutină — sold în regulă, fără conflict de ocupare — poate fi gestionată de un sistem. Cererile care intră în conflict cu ocuparea sau se abat de la normă necesită un responsabil care aprobă sau respinge cu motiv. Aceasta nu este o fază intermediară pe drumul spre automatizarea completă, ci o repartizare care ține de natura excepțiilor: atât timp cât acestea necesită o decizie care trebuie să poată fi explicată, acea parte rămâne muncă umană.
Pentru a vedea cum se aplică această repartizare propriei dumneavoastră organizații, este util să analizați regulile și sistemele care stau la bază: dacă regulile de aprobare sunt stabilite pe echipă și dacă soldul de concediu este disponibil actualizat în sistem. Scanarea rapidă și gratuită de la FTE TO AI constă din douăsprezece întrebări, poate fi parcursă fără cont și oferă o indicație privind ce parte din orele din acest tip de profiluri poate fi preluată astăzi de AI. Scanarea completă a activității, care descompune munca unei companii sarcină cu sarcină și o traduce în capacitate exprimată în fte, este încă în construcție.
Vraag maar. Ik ken de kennisbank van deze site; wat ik niet weet, zeg ik erbij.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.