Munca dintre sisteme: teza

Acesta este textul lung al unui argument pe care l-am spus pe scurt. Nu este un tur de produs. Este o încercare de a spune exact ce s-a schimbat, de ce cincizeci de ani de tehnologii de integrare nu au reușit să schimbe acest lucru, ce poate merge prost și ce disciplină face ca totul să funcționeze. Dacă cineva conduce o firmă cu mai mult de două sisteme, sau construiește software pentru astfel de firme, textul este scris pentru el. Argumentul este scurt dinadins; partea practică, capitol cu capitol, începe aici.

1. Munca pe care n-a proiectat-o nimeni

În orice firmă care are un ERP, o căsuță de email, un Excel, un portal bancar și sistemul de e-facturare al statului se găsește o muncă al cărei singur rost este să mute informația dintr-unul în altul. Să-i spunem munca dintre sisteme. Apare mereu în aceleași cinci forme:

• Transcriere. Se citește o valoare într-un loc și se tastează în altul: totalul facturii din PDF în contabilitate, liniile comenzii în portalul furnizorului.
• Reconciliere. Se hotărăște că două înregistrări sunt același lucru: furnizorul scris în trei feluri, plata care se potrivește cu factura aceasta, livrarea care închide comanda aceea.
• Traducere. Se transpune sensul între sisteme care văd lumea diferit: „clientul" lor este „contul" nostru, „termen de plată 30 de zile" la ei este la noi codul 4 de termen de plată.
• Rutare. Se hotărăște unde merge ceva și cine trebuie să-l vadă: ce centru de cost, ce aprobator, ce dosar.
• Excepții. Tot ce nu se potrivește nicăieri: nota de credit fără factură, scanarea pe jumătate lizibilă, duplicatul care nu este chiar duplicat.

Trei lucruri fac munca asta scumpă. O fac oameni care cunosc afacerea, pentru că deciziile de acolo cer exact cunoașterea aceea. Este invizibilă: nicio organigramă nu are o căsuță numită „munca dintre sisteme", așa că nimeni nu-i adună vreodată costul. Și crește mai repede decât firma: cu n sisteme există până la n(n-1)/2 treceri, iar la fiecare trecere cineva citește dintr-o parte și scrie în cealaltă.

2. Cincizeci de ani de încercări

Fiecare generație de tehnologie pentru companii a atacat stratul acesta. Ce a reușit fiecare și unde s-a oprit fiecare: în tiparul acesta stă tot argumentul.

Schimbul electronic de date (EDI) le-a dat marilor parteneri comerciali mesaje structurate pentru comenzi și facturi. A mers acolo unde ambele părți au investit în formate rigide și în relații stabile. N-a făcut nimic pentru coada lungă: partenerii mici, documentele neobișnuite, tot ce nu prevăzuse standardul.

Middleware-ul și magistralele de servicii au atacat problema pătratică cu un nod central: fiecare sistem vorbește cu magistrala, magistrala vorbește cu fiecare sistem. Mapările au ajuns treaba unui specialist, scumpe de construit și fragile de câte ori se schimba ceva de o parte sau de alta. Nodul a mutat trecerile; judecata dinăuntrul lor a rămas unde era.

API-urile și platformele de integrare au ieftinit țevăria și au înmulțit conectorii. Mapările deterministe au ajuns ieftine. Dar o mapare este tot o regulă, iar o regulă acoperă doar cazurile la care s-a gândit cine a scris-o. Excepțiile au curs mai departe spre un om.

Automatizarea robotizată a proceselor (RPA) a luat calea cea mai cinstită: reproduce clicurile omului exact așa cum le face el. Tot ea a arătat problema cel mai limpede. Un robot care repetă o improvizație bate improvizația în cuie. Când se schimbă ecranul, se strică; când cazul este neobișnuit, se oprește și deschide un tichet, care ajunge la același om.

Ce au în comun aceste valuri? Fiecare a automatizat jumătatea deterministă a muncii, partea care se poate scrie ca regulă, și s-a oprit exact la același zid: punctul în care pasul următor depinde de citirea a ceva ambiguu, de amintirea unei decizii de dinainte sau de o apreciere a plauzibilității. O jumătate de secol de unelte, un singur zid.

3. De ce zidul a fost judecata

Patru lucruri au ținut jumătatea de judecată departe de cod.

Intrări fără capăt. Ce intră în munca dintre sisteme sunt documente, emailuri, scanări și ecrane, făcute de alte organizații pentru oameni. Varietatea lor nu are limită. O regulă care descifrează formatul facturii din luna aceasta cade pe cel din luna viitoare.

Deriva. Se schimbă și sursele structurate: un câmp primește alt nume, un partener trece pe alt format, apare un cod de taxă nou. Regulile se strică pe tăcute, iar stricăciunea iese la suprafață sub formă de excepții.

Contextul. La „este același furnizor?" nu se poate răspunde doar din înregistrare. Trebuie știut că firma și-a schimbat numele anul trecut, că aceasta este punctul de lucru, că cei de la financiar au hotărât în martie să le socotească pe amândouă ca una singură. Cunoașterea aceea stătea în capul unui om.

Coada lungă. Cazurile excepționale sunt rare luate unul câte unul și majoritare luate împreună. Când se automatizează drumul obișnuit, dispare partea plăcută a meseriei și ziua omului se strânge pe partea grea. Numărul de angajați nu se mișcă; meseria devine mai grea.

4. Ce s-a schimbat, exact

Patru capacități au apărut deodată în modelele mari de limbaj, iar ceea ce contează este combinația lor.

Citire la nivel de om. Un model poate citi o factură scanată, un fir de emailuri sau o pagină de portal și poate scoate din ele ce ar scoate un om, fără o regulă scrisă pentru formatul respectiv. Asta acoperă transcrierea și traducerea, cele două forme care făceau cel mai mult volum.

Rezolvare în context. Primind un candidat și înregistrările cu care s-ar putea potrivi, un model poate cântări grafia, adresa, codul fiscal și istoricul, apoi poate decide, sau poate spune că nu poate decide. Aceasta este reconcilierea, forma care cerea cea mai multă judecată.

Acțiune. Modelele pot apela unelte: interoghează un sistem, scriu o înregistrare, trimit un mesaj, fac un calcul. Citirea fără acțiune ar fi dat doar rapoarte mai bune. Acțiunea închide bucla.

Memorie. O decizie spusă o singură dată („cele două entități se tratează ca una", „facturile de la furnizorul acesta merg pe centrul de cost acela") poate fi păstrată și aplicată la fel de fiecare dată după aceea. Asta transformă un cititor isteț într-un coleg care învață regulile casei.

Acum limitele, spuse cu aceeași precizie. Sistemele acestea sunt probabiliste: pot greși cu toată siguranța din lume și nu știu când greșesc. Nu au nicio autoritate a lor: un model care poate scrie înregistrări este un model care poate scrie înregistrări greșite cu viteză de mașină. Costă bani la fiecare pas, așa că buclele risipitoare sunt un risc real. Și sunt exact atât de bune cât le lasă ce pot vedea: un asistent care nu poate citi documentele firmei este o fereastră de chat.

Niciuna dintre limitele acestea nu este fatală. Toate dictează arhitectura.

5. Bucla care face totul sigur

Munca dintre sisteme, făcută cum trebuie, este o buclă cu o formă anume.

Fiecare etapă vine cu o disciplină a ei, iar disciplinele acestea despart un sistem care merge de o demonstrație.

Proveniență pe fiecare fapt. Tot ce se extrage își poartă sursa după el: din ce document, de pe ce pagină, din ce câmp. Verificarea unei afirmații nu mai costă „caută originalul", costă un clic. Nu este un răsfăț: de aici vine viteza care face ca aprobarea de către om să fie reală, nu o ștampilă.

O graniță fermă de confirmare. Citirea, rezolvarea și redactarea pot rula libere. Tot ce iese din spațiul de lucru sau schimbă o înregistrare care contează așteaptă un om: trimiterea, ștergerea, modificarea câmpurilor cu bani. Granița trebuie să stea în cod, nu într-un prompt, pentru că prompturile sunt sugestii, iar granițele trebuie să fie garanții.

Idempotență. Fiecare sincronizare este legată de identificatori externi, așa că rulată de două ori nu produce nimic nou. Sistemele care trag date din alte sisteme vor fi rulate din nou, de programări și de oameni nerăbdători, iar duplicatele sunt felul clasic în care o automatizare pierde încrederea.

Privilegii minime, cu compromiterea luată în calcul. Credențialele se dau strict pentru ce cere sarcina, cu limită de rată, și se păstrează ca și cum într-o zi ar ajunge unde nu trebuie, pentru că unele chiar vor ajunge. O cheie care poate doar citi facturi nu poate trimite emailuri clienților.

Când cade, cade spre om. Când dovezile nu ajung, răspunsul corect este „n-am putut stabili, iată ce am găsit", niciodată o ghicire plauzibilă. Un sistem care improvizează pe cazurile grele este mai rău decât unul care n-ar exista deloc, pentru că greșelile lui vin cu siguranța unui sistem.

O urmă de audit. Fiecare acțiune este înregistrată cu cine, ce, când și pe ce dovezi. Mai puțin pentru conformitate, mai mult pentru marțea în care ceva este greșit și cineva trebuie să afle de ce în zece minute.

6. Economia, spusă cinstit

Unde se duce de fapt timpul în munca dintre sisteme? Rareori pe drumul fără probleme. Se duce pe excepții, pe căutări și pe costul de a ține trei sisteme în același cap și de a sări dintr-unul în altul. Valoarea automatizării acestui strat este deci fracțiunea de decizii pe care sistemul le ia corect, înmulțită cu costul minutului de om pe care îl economisește, minus costul celor pe care le greșește. „Robotul tastează în locul omului" este doar o parte marginală.

Formula aceasta are o urmare în felul în care se evaluează orice furnizor, inclusiv noi. Cifrele care contează se pot măsura:

• Precizia rezolvării. Când sistemul spune că două înregistrări se potrivesc, cât de des are dreptate, judecat după cum s-a încheiat cazul?
• Rata de aprobare. Cât de des acceptă omul propunerea fără s-o schimbe? O rată mare înseamnă că judecata este preluată; o rată mică înseamnă că omul face tot el munca, cu pași în plus.
• Rata de scăpare. Câte erori ajung în contabilitate, la client sau la Fisc?
• Timpul până la închidere. Pe fiecare element, de la sosire până la înregistrare, cu omul în buclă.

Un furnizor care nu poate raporta cifrele acestea pe datele firmei vinde o senzație. Măsurătoarea este produsul.

Obiecția costului

Prima obiecție la toate acestea este costul: modelele se plătesc pe token, iar munca dintre sisteme merge toată ziua. Trei lucruri fac obiecția mai slabă decât sună.

Comparația se face cu minutul de om, iar distanța este uriașă. O decizie de rezolvare care citește o factură și câteva înregistrări candidate costă o fracțiune de cent; minutul unui om care cunoaște afacerea costă cu ordine de mărime mai mult. Prețul tokenilor a scăzut abrupt de la un an la altul și nu dă semne că s-ar opri, în timp ce prețul minutului de om crește.

Cea mai mare parte a buclei nu are nevoie de cel mai puternic model. Un document de clasificat, un declanșator de rutat, câmpuri de scos dintr-un XML curat, o regulă de plauzibilitate de verificat: sunt treburi de model mic, rapide și ieftine, și ele fac grosul volumului. Modelele cele mai puternice sunt pentru coada grea: o reconciliere ambiguă, un raționament pe mai multe documente, o scanare pe jumătate lizibilă. Un design pe niveluri, model mic întâi și model puternic pe excepții, cheltuiește tokenii scumpi exact acolo unde se duceau înainte minutele de om.

O parte nu are nevoie de niciun model. O e-factură structurată este un XML cu schemă: codul fiscal al furnizorului, totalul, scadența, liniile de TVA le citește un parser, exact și pe gratis, iar un model care le recitește este bani aruncați. Căutarea pe cuvinte-cheie este tokenizare plus punctaj și găsește un număr de factură sau un cod fiscal mai bine decât orice embedding. Un set fix de comenzi („trage facturile acum", „ce este scadent săptămâna aceasta") este un clasificator mic și un tabel de dispecerizare. Declanșatoarele programate sunt un ceas. Disciplina este împingerea în jos: fiecare sarcină coboară la cel mai ieftin nivel care ține pragul de precizie. Parser și reguli unde intrarea este structurată, model mic unde este semi-structurată sau unde se alege dintr-un set închis, model puternic doar unde citirea este deschisă, potrivirea este ambiguă sau pasul următor trebuie planificat. Grosul volumului stă în cele două niveluri de jos. Grosul valorii, și aproape tot riscul, stă în cel de sus.

Riscul real la cost este risipa, nu prețul. Un agent care se învârte în cerc, recitește documente întregi din care putea să scoată doar bucata de care avea nevoie sau retrimite aceleași instrucțiuni la fiecare apel arde bani fără să producă decizii. Disciplinele se cunosc: fragmente extrase în loc de documente întregi, cache pentru părțile de prompt care se repetă, un buget pe fiecare rulare, pauze între declanșări, muncă programată prelucrată în loturi. Economia de tokeni este o practică de inginerie, și acolo stă cea mai mare parte a diferenței de cost dintre implementări.

Despre modelele rulate pe hardware propriu: un model deschis de mărime medie, pe un server decent, poate duce bine nivelul modelului mic, iar pentru organizațiile cu cerințe stricte de rezidență a datelor este un design legitim. Două rezerve cinstite. Coada grea este exact locul unde modelele mai mici sunt cele mai slabe și unde greșelile costă cel mai mult, așa că un design ținut doar local are nevoie de granița de confirmare mai mult, nu mai puțin. Iar un server de modele este un angajament de operare: actualizări, evaluare, capacitate. Pentru cele mai multe firme, un design pe niveluri găzduit în Uniunea Europeană dă aceeași economie fără un dulap plin de plăci grafice. Măsura corectă pentru oricare dintre alegerile acestea este costul pe decizie corectă, niciodată costul pe token.

7. Ce înseamnă asta pentru ERP-uri

ERP-ul este sistemul de evidență: registrul, stocul, contractele, adevărul. Rolul acesta nu dispare, iar cine spune că inteligența artificială înlocuiește ERP-ul nu a înțeles la ce folosește un ERP. Ce se schimbă este sistemul de lucru: suprafața pe care o ating oamenii de-a lungul zilei. Suprafața aceasta iese din formularele ERP-ului și se mută într-un strat care citește ce sosește, îl potrivește cu înregistrările, propune intrarea și o scrie înapoi după ce a fost aprobată.

De aici, trei predicții.

Conectorii devin marfă. Pe măsură ce tot mai multe sisteme expun API-uri și apar protocoale standard prin care uneltele vorbesc cu modelele, întrebarea „aveți conector pentru X?" cântărește tot mai puțin. Țevăria n-a fost niciodată partea grea; au dovedit-o cele patru valuri de dinainte.

Judecata devine produsul. Diferența o fac deciziile pe care stratul le poate lua și pe care se poate conta, cu ce dovezi și sub ce graniță. Aici disciplinele din secțiunea 5 încetează să fie igienă de inginerie și devin substanța concurenței.

Un chat lipit pe ERP nu preia munca dintre sisteme. Este de așteptat ca fiecare ERP să-și crească o fereastră de chat. O fereastră de chat fără proveniență, fără memorie, fără unelte și fără graniță de confirmare este o casetă de căutare cu gramatică mai bună. Testul este simplu: i se cere să facă reconcilierea, apoi i se cere să spună de unde știe.

8. Ce rămâne omului

Trei lucruri, și niciunul nu este premiu de consolare.

Alegerea. Între doi furnizori, două oferte, două feluri de a structura o afacere. Sistemul poate așeza comparația pe masă, cu fiecare cifră; alegerea poartă răspundere, iar răspunderea nu se transferă la software.

Angajamentul. O promisiune făcută unui client, o semnătură, o plată eliberată. Sunt acte ale firmei, făcute de oameni pe care firma i-a împuternicit.

Asumarea greșelii. Când automatizarea greșește ceva, un om hotărăște ce este de făcut, iar omul acela are nevoie de urma de audit din secțiunea 5 ca s-o facă în zece minute, nu într-o zi.

Nimeni nu este înlocuit. Omul care făcea munca aceasta își vede ziua schimbată: nu mai face transferurile, le aprobă, iar aprobarea este exact partea care a avut întotdeauna nevoie de un om. Orele economisite sunt orele care n-au avut niciodată nevoie de unul.

9. Unde suntem

Construim o implementare a acestei teze și am prefera să fim judecați după detalii, nu după argument. Astăzi stratul citește documente, scanări și e-facturi românești trase din SPV odată ce firma își conectează contul; completează și actualizează tabele de date din ce citește; citește și scrie în Google Sheets și Drive; apelează din fluxuri programate sistemele care expun un API; deschide spațiul de lucru oricărei unelte care vorbește Model Context Protocol; iar fiecare acțiune cu consecințe se oprește la granița de confirmare. Ce nu avem încă: conectori cu nume, activabili dintr-un clic, pentru anumite ERP-uri, și scrierea înapoi mai largă care vine odată cu ei. Din pilot învățăm ce decizii sunt sigure de preluat în continuare și în ce ordine.

Dacă argumentul de mai sus descrie o muncă din firma dumneavoastră, am vrea să vedem munca aceea.