ATS diegimas ir duomenų migracija Lietuvoje

Pradėkite nuo duomenų inventorizacijos

Surašykite visus šaltinius: kandidatų bazes, Excel lenteles, CV aplankus, el. pašto dėžutes, LinkedIn užrašus, ankstesnės ATS eksportus ir klientų failus. Prie kiekvieno šaltinio pažymėkite savininką, formatą, apytikslę apimtį, prieigos ribas ir tai, ar jame yra jautresnės informacijos.

Klausimas turi būti ne tik “ką importuosime?”, bet ir “ką turime teisę toliau saugoti?”. Kandidatas, tinkamas vienai pozicijai prieš kelerius metus, nėra automatiškai tinkamas visiems būsimiems mandatams. Saugojimo terminai, duomenų mažinimas ir sutikimų tikrinimas turi būti sutarti prieš perkėlimą.

Yena gali tapti bendra DI paieškos, ATS ir atrankų CRM darbo aplinka, tačiau ji negali nuspręsti, kurie seni įrašai teisėtai reikalingi jūsų organizacijai. Tą sprendimą turi priimti jūsų komanda, prireikus pasitelkdama duomenų apsaugos specialistą.

Inventorizacijos rezultate turėtų matytis ne tik failų pavadinimai. Pažymėkite, kada duomenys paskutinį kartą naudoti, ar juose yra kelių klientų informacija, ar yra dubliuojamų kontaktų ir ar žinomas jų gavimo šaltinis. Tokia lentelė vėliau tampa sprendimo pagrindu, kai reikia pagrįsti, kodėl vieni įrašai keliami, o kiti ne.

Jei komanda dirba keliomis kalbomis, iš anksto susitarkite dėl laukų pavadinimų ir reikšmių. Vienodas terminas “neaktyvus” turi reikšti tą patį Vilniuje, Kaune ir nuotolinėje komandoje. Duomenų migracija yra gera proga išspręsti šiuos nesusipratimus, kol jie dar netapo sistemos taisyklėmis.

Skirkite laiko ir darbuotojų klausimams. Žmonės dažniausiai priešinasi ne pačiai sistemai, o neaiškumui, kas nutiks jų užrašams ir klientų santykiams. Trumpas paaiškinimas bei aiški pagalba pirmomis savaitėmis sumažina pagundą grįžti prie senų įpročių.

Pirmą savaitę suplanuokite trumpą kasdienę pagalbos peržiūrą, kad klaidos būtų sugautos, kol jos dar mažos.

Skirstykite darbus į etapus

Pirmajame etape sukurkite duomenų žodyną. Sutarkite, ką reiškia “aktyvus”, “archyvuotas”, “nebesusisiekti” ir “sutikimą reikia patikrinti”. Apibrėžkite privalomus laukus, leistinas tuščias reikšmes ir tai, kas gali redaguoti svarbius duomenis.

Antrajame etape sukurkite testinį rinkinį. Į jį įtraukite dublikatus, nepilnus įrašus, skirtingus datų formatus, kandidatus su keliais klientais ir įrašus, kurių nereikia perkelti. Gražus testinis failas neparodo tikrų migracijos problemų.

Trečiajame etape atlikite pilotą su viena komanda arba dviem mandatais. Išbandykite paiešką, būsenas, laiškų registravimą, trynimo užklausą, eksportą ir shortlist klientui. Visą bazę kelkite tik po tokio testo.

• Inventorizacija ir teisėtas tikslas
• Duomenų žodynas ir valymo taisyklės
• Testinis importas su sudėtingais atvejais
• Pilotas su ribota tikra darbo eiga
• Pilnas perkėlimas ir kontrolė po paleidimo

Patikros po importo

Palyginkite šaltinio ir naujos sistemos įrašų skaičių, bet nesustokite ties skaičiumi. Atidarykite atsitiktinę imtį iš kiekvienos kategorijos. Tikrinkite vardą, kontaktus, įmonę, sutikimo būseną, paskutinį veiksmą, priedus ir ryšį su mandatu.

Patikrinkite, ar konsultantas gali rasti kandidatą pagal el. paštą, telefoną ir buvusią įmonę. Ar mato, kas jau bendravo? Ar vadovas mato tik savo klientų informaciją? Jei darbuotojai vėl kuria privačias lenteles, migracija nepasiekė darbo tikslo.

Paleidimo metu naudokite skirtingus vartotojų vaidmenis. Išbandykite administratoriaus, vadovo ir įprasto konsultanto prieigą, taip pat kampanijos stabdymą, trynimą, eksportą ir veiksmų žurnalą. Rezultatus užrašykite.

Grįžimo ir eksporto planas

Grįžimo planas nėra stebuklingas mygtukas. Tai iš anksto paruošta tvarka su išsaugotu šaltinio eksportu, jo versija, migracijos žurnalu, klaidų sąrašu, sprendimo savininku ir data, iki kurios galima grįžti prie ankstesnio proceso.

Prieš importą sukurkite saugomą šaltinio kopiją pagal jūsų saugos taisykles. Po kiekvieno etapo eksportuokite ir naują sistemą. Taip matysite, kas pridėta, pakeista ar ištrinta, o ne bandysite rekonstruoti įvykius iš atminties.

Sutarkite, kiek laiko sena sistema bus tik skaitoma ir kada ji bus išjungta. Dvi lygiagrečios aktyvios bazės greitai sukuria naujus dublikatus. Pilote turi būti aišku, kada tęsiate, ką taisote ir kada grįžtate.

Yena diegimo logika

Yena diegimą verta pradėti nuo to, kaip agentūra ieško kandidatų. Apibrėžkite, kaip paieškos rezultatas tampa kandidato įrašu, kaip saugomas tinkamumo paaiškinimas, kada papildomi duomenys ir kada pradedama kampanija.

LinkedIn plėtinį, ATS ir atrankų CRM testuokite kaip vieną kelią. Kandidato informacija neturėtų likti atskira kopija naršyklėje, kurią vėliau reikia ranka perkelti į sistemą. Tačiau integracija nepanaikina pareigos tikrinti šaltinį, teisėtą pagrindą ir klaidas.

Po paleidimo numatykite 30 dienų peržiūros ritmą. Kartą per savaitę peržiūrėkite dublikatus, neužpildytus laukus, nenaudojamas būsenas, eksportą ir komandos pastabas. Diegimas baigiasi tada, kai procesas tampa pakartojamas.

Į biudžetą įrašykite ir sprendimus, kurie atsiranda po paleidimo. Pirmą mėnesį paaiškės, kad vienas statusas nereikalingas, kitam reikia papildomo leidimo, o kliento ataskaitoje trūksta vieno lauko. Tai nėra nesėkmė. Svarbu, kad pakeitimai būtų valdomi, dokumentuoti ir negrąžintų komandos prie senų asmeninių lentelių.

Lietuvos rinkoje verta iš anksto susitarti, kas prižiūri terminologiją, jei agentūra dirba keliomis kalbomis. Kandidato būsena, kliento pastaba ir laiško šablonas turi reikšti tą patį visiems konsultantams. Priešingu atveju ataskaitos taps sunkiai palyginamos, o naujų darbuotojų apmokymas užtruks.

Kur lieka žmogaus atsakomybė

Žmogaus patikra nėra pasirenkama

Yena padeda susieti darbo eigą ir kandidatų kontekstą, tačiau nepatvirtina jūsų teisinio pagrindo ir nenusprendžia, kuriuos senus įrašus galima toliau naudoti. Už migracijos apimtį, saugojimą, trynimą ir grįžimo sprendimą atsako jūsų organizacija.