Munca dintre sisteme, capitolul 2: cum automatizezi o trecere, fără riscuri

Partea 1 s-a încheiat cu o pagină: inventarul trecerilor, fiecare loc în care un om cară informație dintr-un sistem în altul, cu judecata din fiecare trecere scrisă pe numele ei. Capitolul de față arată ce se face cu pagina aceea. Se aplică oricărei implementări a buclei, inclusiv a noastră, și este scris așa încât o companie să îl poată urma cu echipa proprie.

Cu ce treceri se începe

Inventarul împinge privirea spre cifra cea mai mare. Merită să i se reziste o săptămână. Primele treceri predate învață compania cum merge lucrul acesta, iar o primă trecere aleasă prost predă lecția greșită. Alegerea se face după cinci criterii, în ordinea de mai jos.

Judecata se repetă. Se ia coloana judecății. O trecere în care decizia are aceeași formă de fiecare dată („de care comandă ține factura aceasta") este pregătită. O trecere în care fiecare caz este alt fel de excepție nu este pregătită; acolo se ajunge a treia, după ce stratul are deja în memorie regulile casei.

Intrarea este măcar pe jumătate structurată. E-facturi, extrase bancare exportate, confirmări de comandă, avize cu format fix. Pozele cu notițe scrise de mână se pot și ele, dar vin mai târziu.

O decizie greșită se poate întoarce. O factură potrivită greșit și prinsă la aprobare costă un minut. O declarație fiscală greșită costă un trimestru. Se începe acolo unde greșelile sunt ieftine, pentru că greșeli vor fi, iar rostul primei treceri este tocmai să le scoată la vedere.

Orele sunt reale. Dintre trecerile care trec de primele trei teste, se ia cea cu cele mai multe ore pe lună. Nimeni n-ar trebui să se uite cu lupa ca să vadă efectul.

Responsabilul vrea. Omul care face astăzi trecerea aceea va proiecta predarea împreună cu dumneavoastră și va deveni cel care aprobă. Dacă îl sperie gândul, se alege altă trecere și se revine mai târziu. Capitolul 1 l-a numit; aici judecata lui se pune pe hârtie.

Două treceri care trec de obicei toate cele cinci teste: facturile de la furnizori în contabilitate și întrebările clienților despre stadiul comenzii, cu răspunsul luat din sistemele operaționale. Două care pică de obicei testul al treilea și trebuie să mai aștepte: orice se depune la ANAF și orice pune bani în mișcare.

O trecere, descompusă

Se ia trecerea facturilor de furnizor de la distribuitorul din capitolul 1 și se așază pe buclă.

Citește. Factura în sine: structurată, dacă a venit prin e-Factura; scanată, dacă a venit pe email. Comenzile de achiziție deschise la furnizorul acela. Avizele din ultimele săptămâni. Regula pe care office managerul a spus-o o singură dată: „la furnizorul ăsta, linia de transport merge pe logistică, nu pe marfă."

Rezolvă. Ce fișă de furnizor, dat fiind că numele a venit scris altfel decât până acum. Ce comandă, dat fiind că suma se potrivește cu două dintre ele și doar una este pentru cantitatea livrată. Ce centre de cost, linie cu linie, după regula de mai sus.

Propune. Nota contabilă, linie cu linie, fiecare valoare cu sursa lângă ea: totalul acesta de pe prima pagină a facturii, cantitatea aceasta de pe aviz, centrul de cost acesta din regula spusă de office manager. Și o observație pe înțelesul oricui acolo unde ceva nu se leagă: „cantitatea de pe factură depășește avizul cu douăsprezece bucăți."

Confirmă. Office managerul vede propunerea și dovezile, corectează singura linie care are nevoie, aprobă. Treizeci de secunde în loc de unsprezece minute, iar greșeala pe care o prinde este a sistemului, nu a ei.

Înregistrează. Nota intră în programul de contabilitate, factura se arhivează și se leagă de ea, fișa furnizorului primește noua scriere a numelui ca alias, iar corectura făcută de office manager devine memorie: data viitoare, sistemul propune cum ar fi făcut ea.

Fiecare trecere din inventar se descompune la fel. Făcută pe hârtie pentru primele două treceri, împreună cu responsabilul, treaba durează o după-amiază, și rezultatul este chiar documentul de proiectare.

Ce pas cere ce model

Nu toți pașii buclei au nevoie de aceeași mașinărie, iar cea mai mare parte din costul unei implementări proaste vine din folosirea nivelului scump pentru muncă pe care unul ieftin o face mai bine. Fiecărui pas i se dă un nivel.

Nivelul zero, fără model. Citirea câmpurilor din e-factura structurată. Căutarea furnizorului după CUI. Potrivirea exactă a unui număr de factură. Regulile de validare pe care programul de contabilitate le are oricum. Programarea rulărilor. Nivelul acesta este exact, nu costă nimic și ar trebui să ducă tot ce poate duce.

Nivelul unu, mic și rapid. Clasificarea unui document („aceasta este o notă de credit, nu o factură"). Extragerea câmpurilor dintr-un PDF cu structură parțială. Lista scurtă a comenzilor care ar putea fi cea bună. Decizia despre care dintre trei acțiuni fixe cere un mesaj.

Nivelul doi, modelul cel mai puternic. Citirea unei scanări abia lizibile. Alegerea între doi candidați când suma se potrivește cu amândoi. Scrierea observației care explică nepotrivirea. Cazul pentru care n-a scris nimeni nicio regulă.

Disciplina se reduce la o singură regulă: fiecare pas se împinge în jos, la cel mai ieftin nivel care ține pragul de precizie, iar pragul se măsoară, ceea ce este subiectul capitolului 3. În trecerea facturilor de mai sus, cam totul este nivel zero și unu, cu excepția potrivirii ambigue și a explicației. Așa arată de obicei, și de aceea stratul este accesibil ca preț.

Unde se pune granița de confirmare

Regula implicită este simplă și se scrie înainte să ruleze orice: tot ce iese din companie sau schimbă o înregistrare care contează așteaptă un om. Un email către un furnizor, o notă contabilă înregistrată, un câmp de plată modificat, un document șters. Cititul, rezolvatul și redactatul merg liber; acțiunea așteaptă.

Regula implicită nu este și starea finală. Autonomia se câștigă pe clase de decizie și nu se acordă niciodată pe sisteme întregi.

O clasă de decizie înseamnă „potrivirea unei e-facturi cu o singură comandă deschisă, cu sumă identică", nu „facturile". Pentru fiecare clasă, comportamentul celui care aprobă spune singur când este sigur: după un șir de aprobări fără nicio corectură, destul de lung cât să fi prins toată varietatea unei luni, clasa aceea poate trece pe automat, cu un eșantion verificat. Una din zece la început; în eșantion se va vedea deriva. Clasele care nu trec de întrebarea din diagramă, cele ireversibile și cele care ies din companie, rămân definitiv la propune-și-confirmă. Valoarea lor stă în propunere, nu în autonomie.

Două reguli care rămân valabile la orice nivel de autonomie. O propunere fără dovezi nu este o propunere. Dacă sistemul nu poate arăta documentul și câmpul din care a luat o valoare, trebuie să spună asta și să se oprească, iar proiectarea trebuie să facă ghicitul pe tăcute imposibil; a-l descuraja nu este de ajuns. Și calea „n-am putut stabili" trebuie să existe și să se vadă: o coadă de cazuri nerezolvate, pe care un om o parcurge zilnic. Mărimea cozii este un semn de sănătate, iar fiecare caz rezolvat este un candidat la o memorie nouă sau la o regulă nouă.

Mecanismele care previn eșecurile clasice

Idempotența. Fiecare scriere are o cheie luată dintr-un identificator extern: numărul facturii plus furnizorul, id-ul mesajului din SPV, numărul comenzii. Dacă aceeași trecere rulează de două ori, pentru că un program s-a declanșat de două ori sau un om a dat clic de două ori, nu trebuie să apară nimic nou. Dublurile sunt cel mai rapid mod de a pierde încrederea, și se pot evita complet.

Drepturi minime, cu scurgerea luată ca sigură. Stratul primește citire pe larg și scriere pe puțin. Credențialele sunt limitate la treaba respectivă, au limită de rată și se păstrează ca și cum într-o zi vor ajunge la vedere, pentru că o credențială, undeva, ajunge întotdeauna. O cheie care poate citi facturi n-ar trebui să poată trimite email clienților.

Memorie cu responsabil. Regulile spuse de cel care aprobă („furnizorii aceștia doi se tratează ca unul singur") devin memorie pe care sistemul o aplică. Memoria are nevoie de un responsabil și de o listă; memoria fără responsabil este felul în care o regulă greșită din martie ajunge să modeleze pe tăcute fiecare decizie din iunie.

Urmă de audit din prima zi. Cine a aprobat ce, pe ce dovezi, când. Mai puțin pentru auditor, mai mult pentru marțea în care o cifră este greșită și omul care trebuie să afle de ce are zece minute la dispoziție.

Punerea în funcțiune

În umbră. Timp de două până la patru săptămâni, sistemul produce propuneri, iar omul face trecerea în continuare ca până acum. La sfârșitul fiecărei zile se compară. Aici ies la iveală variantele de scriere a numelor, regula pe care n-a spus-o nimeni, furnizorul acela unic ale cărui facturi arată mereu greșit. Nu s-a riscat nimic, iar documentul de proiectare își primește corecturile.

Asistat. Omul lucrează de acum pornind de la propuneri: verifică, corectează, aprobă. În starea aceasta stau cele mai multe treceri multă vreme, și tot aici este deja cea mai mare parte a valorii: orele scad, erorile se prind la aprobare, iar judecata se depune ca memorie la fiecare corectură.

Eșantionat. Pentru clasele care trec de decizia de mai sus și au câștigat-o prin istoricul aprobărilor: automat, cu un eșantion verificat. Este starea care aduce înapoi și ultimele ore, și se intră în ea câte o clasă pe rând, niciodată printr-un comutator tras peste toată trecerea.

Două până la șase săptămâni pe trecere este un ritm realist, cu un responsabil care vrea. Mai repede înseamnă de obicei că s-a sărit peste etapa în umbră, iar în etapa în umbră se găsesc greșelile ieftine.

Ce merge prost

Excepțiile automatizate primele. Sunt partea cea mai enervantă din ziua omului, așa că atrag atenția. Sunt și partea cu cel mai puțin tipar. Se lasă a treia.

Deriva tăcută. Un furnizor își schimbă formatul facturii; un portal redenumește un câmp. Parserul de la nivelul zero începe să scoată valori greșite cu toată încrederea. Eșantionul verificat și coada de nerezolvate există tocmai ca să prindă așa ceva; dacă nu se uită nimeni la ele, nu le prinde nimic.

Oboseala de propuneri. Dacă cel care aprobă vede patruzeci de confirmări mărunte pe zi, nu le mai citește, iar granița devine teatru. Clasele sigure se mută pe autonomie eșantionată, iar atenția omului se păstrează pentru deciziile care chiar au nevoie de ea.

Înmulțirea uneltelor. Fiecare sursă nouă conectată este o trecere nouă, de data aceasta cu stratul însuși. Se conectează ce a ordonat inventarul, în ordinea aceea, și se oprește când orele s-au întors.

Ce rămâne după predare

La capătul unei treceri predate există: un document de proiectare care numește judecata; o memorie a regulilor casei, în cuvintele responsabilului; un istoric al aprobărilor care arată, clasă cu clasă, ce nimerește sistemul; o coadă de nerezolvate care arată ce nu nimerește; și un om care aprobă și a cărui zi este mai scurtă. Există și materia primă pentru singura întrebare care contează mai departe: a mers, și de unde s-ar ști? Acesta este capitolul 3.