Pagrindinių duomenų valdymas – tai bazinių duomenų įvedimas, keitimas ir nuoseklumo palaikymas: kliento duomenys, produktų kodai, tiekėjų informacija. Šis darbas vyksta tarp sistemų, tokių kaip ERP aplinka ir pagrindinių duomenų valdymo (MDM) įrankis, ir dabar jį dažnai atlieka duomenų administratorius ar administracinis darbuotojas, kuris tikrina ir taiso įrašus.
Siekdami nustatyti, ką DI čia gali perimti, žiūrime ne į pareigų pavadinimą, o į pačią užduotį, aštuoniomis ašimis. Trys iš jų yra lemiamos: struktūrizuotumas, apimtis ir klaidų kaina.
Pagrindiniai duomenys turi pastovią formą. Kliento įrašas turi pavadinimą, adresą, PVM kodą, produkto kodas turi fiksuotą skaičių laukų. Šis nuspėjamumas gauna aukštą struktūrizuotumo įvertinimą, ir tai yra tiksliai toks darbo tipas, kurį automatizavimas jau dešimtmečius gerai valdo. Prie to prisidėkime apimtį: įmonės su tūkstančiais kliento ar produkto įrašų turi užduotį, kuri nuolat kartojasi, su tais pačiais žingsniais kiekvienam įrašui. Didelė apimtis kartu su aukštu struktūrizuotumu yra kombinacija, kurioje taisyklėmis pagrįstas automatizavimas, šiuo atveju RPA, veikia geriausiai.
Pavyzdys: tiekėjas pakeičia adresą. Naują adresą reikia perkelti į ERP sistemą, sąskaitų išrašymo sistemą ir kliento portalą. Tai reiškia tris kartus užpildyti tą pačią lauką pagal fiksuotą taisyklę. Tam nereikia įžvalgos, bet reikia nuoseklumo.
Čia kyla kliūtis. Klaida pagrindiniuose duomenyse plinta toliau: neteisingas PVM kodas sukelia neteisingą sąskaitą, neteisingas produkto kodo laukas sukelia neteisingus atsargų skaičiavimus ar neteisingas kainas klientui. Todėl klaidų kainos ašis nėra žema, taip pat ir atitiktis: daug pagrindinių duomenų patenka į taisykles apie asmens duomenis ar mokestinę registraciją. Tai nereiškia, kad DI čia neturi vaidmens, bet reiškia, kad visiškai autonomiškas apdorojimas be kontrolės yra rizika, kuri nėra taip lengvai priimama.
Be to, vertinimo laisvė yra maža: yra mažai vietos savarankiškai interpretuoti, kas yra teisinga vertė, taisyklės yra fiksuotos. Tai yra gera žinia automatizavimui, kadangi vertinimo laisvė paprastai yra ta ašis, kuri reikalauja žmogaus darbo. Su pagrindiniais duomenimis sunkumas nėra sprendime, o nustatant nukrypimus: adresas, kuris neegzistuoja, pavadinimas, kuris neatitinka ankstesnio įrašo. Čia žmogiškoji priežiūra su pagrįstu patvirtinimu ar atmetimu išlaiko savo vertę.
Didžioji dalis reguliaraus įvedimo ir sinchronizavimo tarp sistemų yra užduotis, kurią DI šiandien gali perimti, jei įvykdytos dvi sąlygos: aiškūs duomenų apibrėžimai, kad nebūtų abejonių, kas yra galiojanti vertė, ir validavimo taisyklės įvedimo metu, kad nukrypę atvejai būtų atpažinti prieš tai, kai jie patenka toliau. Be šių dviejų sąlygų užduotis automatiškai persikelia atgal į trečią bloką: žmogiškąjį darbą, nes niekas negali pasitikėti tuo, kas automatiškai užrašoma.
Vykstantis pokytis nėra tai, kad duomenų administratorius išnyksta, o tai, kad užduoties turinys pasikeičia: nuo pačio rašymo prie savarankiško vertinimo, ką sistema pažymėjo kaip nukrypimą. Tai kitokio tipo darbas, su kitokio tipo dėmesiu, ir jis reikalauja žmogaus, kuris supranta, kodėl įrašas buvo atmestas, o ne tik kaip jį įvesti.
Įmonėje su maža, aiškia klientų baze ir mažai produktų variantų automatizavimo nauda yra ribota: apimtis yra per maža, kad atsipirktų investicijos į validavimo taisykles ir jungtis. Įmonėje su labai skirtingais pirminiais duomenimis – pavyzdžiui, po susijungimo, su dviem skirtingomis CRM sistemomis, kurios nenaudoja tų pačių laukų – sunkumas yra ne įvedime, o pirmiausia nustatant aiškius apibrėžimus. Tai yra vienkartinis, turinio darbas, prieš tai, kai automatizavimas tampa prasmingas.
Šis pasirinkimas tarp struktūros, apimties ir klaidų rizikos veikia ne tik pagrindiniuose duomenyse. Ta pati logika kartojasi klausimuose apie kokį darbą pirkimų skyriuje tinka automatizuoti, kur tiekėjų duomenys ir užsakymo eilutės turi tą pačią kartojimosi ir klaidų jautrumo kombinaciją. Panašus pasirinkimas tarp fiksuotų šablonų ir eskalavimo veikia ir atsakant į naudotojų klausimus apie programinę įrangą: žr. kaip DI elgiasi su naudotojų klausimais apie programinės įrangos problemas. Ir kai sistemos pačios stebimos dėl nukrypimų, signalizavimo ir persiuntimo logika yra panaši į tai, kas aprašyta apie sistemos veikimo stebėjimą DI.
Tai nėra personalo patarimas ir nėra pagrindas sprendimui dėl pareigybės ar personalo struktūros. Jei šios analizės rezultatas kur nors naudojamas su personalu susijusiame procese, tam taikomi savi teisiniai reikalavimai, kuriems šis straipsnis nei prideda, nei atima nieko. Tai, kas čia parašyta, yra pareiškimas apie užduotį, o ne apie asmenį, kuris ją šiuo metu atlieka.
Kad pamatytumėte, kaip šis skirstymas pasireiškia jūsų įmonei, yra nemokamas greitasis patikrinimas: dvylika klausimų, paskyros nereikia, o rezultatas – rodmuo, kurią dalį valandų tame profilyje šiandien galima perduoti DI. Visas darbo patikrinimas, kuris peržiūri visos įmonės darbą užduotis po užduoties šiomis aštuoniomis ašimis, dar kuriamas ir bus pasiūlytas čia vėliau.
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.