Kontrolinė suma: kodėl automatizacija turi tikrinti pati save

Automatizacijoje kontrolinė suma yra skaičius, kurį programa apskaičiuoja kitu būdu nei pagrindinį rezultatą ir su juo palygina. Jei abu būdai duoda tą patį skaičių, rezultatu galima pasitikėti gerokai labiau, nors ir ši patikra visų klaidų neparodo. Jei ne – vadinasi, kažkas nuskaityta klaidingai, praleista arba įrašyta ne ten.

IT srityje kontroline suma vadinama reikšmė, kuri apskaičiuojama iš duomenų ir saugoma ar siunčiama kartu su jais: pagal ją tikrinama, ar duomenys nebuvo pakeisti ar sugadinti. Čia kalbame apie kitą, buhalterijai artimesnę prasmę – ar suvesti skaičiai sudaro dokumente nurodytą sumą.

Bendresnis terminas – invariantas: sąlyga, kuri turi galioti visada, kad ir kokie būtų duomenys. Pavyzdžiui, sąskaitos suma lygi jos eilučių sumai; gautų eilučių yra tiek pat, kiek jų įrašyta ir atidėta; ta pati sąskaita į sąrašą patenka tik vieną kartą. Kai tokia sąlyga pažeidžiama, programa skaičiaus „nepataiso“ – ji parodo, kuri sąlyga pažeista ir kokie skaičiai nesutampa, o sprendžia žmogus.

Dar prieš pradedant sprendimą naudoti, kontrolinė suma parodė, kad iš PDF sąskaitos į lentelę suvesti skaičiai nesudaro jos bendros sumos, nors programa veikė be jokių įspėjimų. Automatizaciją kūrėme logistikos įmonei: programa jos užsakovo išrašytą PDF sąskaitą suveda į mokesčių stulpelius pačios įmonės Excel lentelėje, o visų tų stulpelių suma turi sutapti su bendra sąskaitos suma. Klaida buvo mūsų pačių PDF nuskaitymo kode, o ne sąskaitoje ar kliento duomenyse.

Tai buvo tylioji klaida, kurią išdavė nesutampanti suma. Jei tokios patikros nebūtų, po paleidimo panašią klaidą galėtų pastebėti nebent žmogus, ranka tikrinantis sumas, nors automatizacija diegiama būtent tam, kad to daryti nebereikėtų. Kodėl tokias klaidas sunku pastebėti, rašome straipsnyje apie tylias automatizavimo klaidas.

Išvada paprasta: patikra, kuri aptiko klaidą prieš paleidimą, turi veikti ir kasdieniame darbe. Todėl suma iki cento tikrinama ne tik bandymo metu, bet ir kaskart suvedant sąskaitą. Visą projektą aprašėme logistikos įmonės atvejyje apie kilometrus, kelių mokesčius ir sąskaitas.

Biuro procesuose verta tikrinti sumas, eilučių skaičių, dublikatus, datas ir matavimo vienetus. Mūsų taisyklė: kiekvienam automatiniam skaičiavimui – savas invariantas, t. y. bent viena sąlyga, kuri išduotų neteisingą rezultatą. Jei programa ką nors skaičiuoja, perkelia ar surenka, tokia sąlyga turi būti.

Lentelėje – keli pavyzdžiai iš procesų, kuriuose duomenys perrašomi iš el. laiškų, PDF ir Excel failų. Kokius administracinius procesus automatizuojame ir kaip atrodo automatizuotas sąskaitos suvedimas, aprašėme puslapyje apie verslo procesų automatizavimą.

Geras invariantas remiasi kitu šaltiniu nei tikrinamas rezultatas. Pavyzdžiui, bendra suma imama iš sąskaitos eilutės „Iš viso“, o eilučių suma skaičiuojama iš atskirai nuskaitytų eilučių. Jei abu skaičiai gaunami tuo pačiu būdu, klaida pateks į abu ir patikra nieko neparodys.

Apvalinimą reikia aprašyti, o ne paslėpti. Jei sąskaitos išrašytojas apvalina kiekvieną eilutę, o programa – tik galutinę sumą, gali atsirasti kelių centų skirtumas. Todėl apvalinimo taisyklę verta įrašyti į programą tiksliai, užuot nustačius didelę leistiną paklaidą: kitaip kartu su apvalinimo skirtumais pro patikrą praslys ir tikra klaida.

Kontrolinė suma pastebi tik tas klaidas, kurios pakeičia bendrą sumą. Jei suma priskirta ne tam užsakymui ar ne tam stulpeliui, bendra suma vis tiek sutaps ir patikra klaidos neparodys. Tas pats nutinka, kai dvi klaidos viena kitą atsveria: vienos eilutės suma nuskaityta per didelė, kitos – lygiai tiek pat per maža.

Ji netikrina ir pačios sąskaitos teisingumo. Kontrolinė suma parodo, ar programa perkėlė visą dokumente nurodytą sumą, bet ne tai, ar sąskaitos išrašytojas ją apskaičiavo teisingai. Todėl ji – tik viena iš kelių patikrų. Prieš patvirtindamas žmogus mato, ką ir kur programa įrašys, o suvedusi sąskaitą programa parodo, ką verta patikrinti prieš apmokant.

Programos (pvz., apskaitos sistemos) sugeneruotą PDF sąskaitą skaitome tiesiogiai iš dokumento teksto – be teksto atpažinimo iš vaizdo (OCR) ir be kalbos modelio spėjimų. Tokiame PDF tekstas jau yra, todėl skaičiai paimami tokie, kokie įrašyti dokumente. Tai nereiškia, kad klaidų nebūna – mūsų pačių klaida įvyko būtent nuskaitant PDF. Todėl visos sumos papildomai tikrinamos matematiškai.

Skaičių neturi spėti ir DI (AI) kalbos modelis. Jis gali padėti suprasti laisvą tekstą ar paaiškinti rezultatą, bet sumas, kiekius ir tarifus skaičiuoja deterministinė programa: tie patys duomenys visada duoda tą patį atsakymą. Jei laisvą tekstą skaito debesyje veikiantis kalbos modelis, dokumento turinys perduodamas to modelio teikėjui – tai verta įvertinti prieš siunčiant jam sąskaitas.

Ko programa nesupranta, to ji nepildo spėliodama. Neatpažinta sąskaitos eilutė nepraleidžiama tyliai – ji lieka matoma atskirame sąraše. Jei eilutės negalima patikimai suskaičiuoti (pvz., faile nelogiškos datos), programa jos nepildo ir paaiškina kodėl. Šiai taisyklei patikrinti turime atskirą automatinį testą „jokia eilutė nedingsta tyliai“.

Kontrolinės sumos reikia, kad ir kas nuskaitytų sąskaitą – OCR programa, DI modelis ar pagal taisykles veikianti programa: bet kuris iš jų gali praleisti eilutę ar nuskaityti ją du kartus. Nuskaitymo įrankio skelbiamas tikslumo procentas rodo vidutinį rezultatą, bet nepasako, kuri konkreti sąskaita suvesta klaidingai – tam reikia patikrinti kiekvieną sąskaitą. Jei sąskaitoms jau naudojate nuskaitymo programą, verta pasidomėti, ar ji palygina suvestų eilučių sumą su eilute „Iš viso“ ir kas nutinka, kai sumos nesutampa.

Nesvarbu ir tai, kur rezultatas įrašomas: ar sąskaita suvedama į Excel lentelę, ar per API – į apskaitos ar ERP sistemą, įrašytų eilučių suma turi sutapti su dokumento eilute „Iš viso“. Mūsų iki šiol sukurtas sąskaitų suvedimas rezultatą įrašo į įmonės Excel lentelę. Integracija su sistema, turinčia API, galima, bet ją vertiname tik pamatę tos sistemos licenciją ir dokumentaciją.

Šis būdas turi ribų. Nuskenuotame ar nufotografuotame dokumente teksto sluoksnio arba nėra, arba jį sukūrė OCR – bet kuriuo atveju skaičiai atpažįstami iš vaizdo, todėl patikros tampa dar svarbesnės. Jei sąskaitų nedaug ir kiekviena ateina vis kitokios formos, gali būti paprasčiau jas ir toliau suvesti ranka: ne kiekvieną rankinį darbą verta automatizuoti. Kaip tai įvertinti, rašome straipsnyje apie tai, nuo ko pradėti automatizavimą.

Automatizaciją tikriname trimis būdais: bandymu su įmonės darbinės lentelės kopija, kontroline suma ir automatiniais testais. Bandymas atliekamas tik prieš paleidimą, o kontrolinė suma ir testai veikia ir po jo. Kaip bandymo metu skirstome rastus skirtumus ir kaip saugoma pati lentelė, aprašėme straipsnyje apie Excel automatizavimą be naujos programos.

Bandymui reikia žmogaus įvestų reikšmių, su kuriomis galima palyginti programos rezultatą. Pradėjus sprendimą naudoti, darbuotojai šių reikšmių paprastai nebeįveda – juk dėl to ir automatizuojama. Kontrolinei sumai žmogaus duomenų nereikia: ji rezultatą lygina su pačiu dokumentu, todėl tikrina kiekvieną sąskaitą ir pasibaigus bandymui. Pirmą kartą sprendimas paleidžiamas tik su lentelės kopija, o pačioje darbinėje lentelėje programa rašo tik į tuščius langelius ir tik žmogui patvirtinus.

Šiais būdais tikrinome ir logistikos įmonės sprendimą: bandyme programos rezultatai sutapo su ranka įvestais duomenimis, o sąskaitos suma – iki cento. Tikslių projekto skaičių be kliento sutikimo neskelbiame.

Kai nesutampa kontrolinė suma arba programos ir žmogaus skaičiai, pirmiausia ieškome konkrečios priežasties: kuri eilutė, kuris stulpelis, kokia taisyklė. Sąskaita, kurios kontrolinė suma nesutapo, nelaikoma teisingai suvesta – ją peržiūri žmogus. Didelis skirtumas – ne triukšmas, o signalas, todėl jo nenurašome paklaidai. Iš anksto nustatyta procentinė riba tik rodo, kuriuos skirtumus tikrinti pirmiausia, bet nėra pagrindas jų nepaisyti.

Tas pats principas taikomas ir suvedus sąskaitą. Programa parodo, ką verta patikrinti prieš apmokant:

• užsakymus, kuriuose lentelėje pažymėta prastova, bet į sąskaitą ji neįtraukta;
• priedus (pvz., stovėjimo aikštelės mokestį), kurių toje sąskaitoje nėra.

Šie sąrašai rodo, ką verta patikrinti, bet tai nebūtinai prarasti pinigai: kai kurie priedai gali būti apmokami vėliau kitu sąrašu, o dalis skirtumų – tiesiog suvedimo klaidos. Todėl sprendžia žmogus. Darbuotojai netampa nereikalingi – jie tampa tikrintojais: dirba toje pačioje lentelėje, tik jiems nebereikia perrašinėti duomenų.

Logistikoje skirtumą gali lemti ir tarifo galiojimo data: kelių mokesčių tarifai keičiasi ir metų viduryje, todėl mokesčius skaičiuojame pagal reiso datą, o ne pagal šiandien galiojantį tarifą. Daugiau apie tokius skaičiavimus – puslapyje apie logistikos automatizavimą.