Crawl, Walk, Run: nu sări etapele

Înainte de orice tehnică sau software, ai nevoie de o hartă. Una simplă, împrumutată din felul în care un copil învață să se miște: mai întâi se târăie, apoi merge, abia la final aleargă. CLM-ul se maturizează exact la fel — fazat. Iar dacă sari etapele, nu câștigi timp; doar te împiedici mai spectaculos.

Crawl — recunoști haosul

Contracte împrăștiate prin foldere și e-mailuri, cereri ad-hoc «pe hol», copy-paste dintr-un document vechi în altul. Primul pas nu e să cumperi ceva — ci să faci haosul vizibil și să începi să-l reduci.

Walk — pui disciplină

Standarde și proceduri simple, șabloane curate, un mod comun de lucru și igiena minimă a documentului: Track Changes, numerotare automată, structură unitară. Tot ce ține contractul «sănătos».

Run — abia acum, tehnologia

Un software CLM serios capătă sens doar aici: depozit unic cu metadate vii — alerte de termene, raportare, integrări. Adică exact când știi deja ce îi ceri.

Tehnologia pusă peste dezordine doar accelerează dezordinea.

Cea mai importantă lecție: nu trebuie, din prima zi, să schimbi întreaga organizație. Stabilește ce ai cu adevărat sub control și ce resurse ai deja la îndemână — și începe de acolo. Dacă procesele ușurează viața tuturor, se răspândesc ca cercurile pe apă și se implementează singure, fără politici scrise și sigilate.

Datoria tehnică, dar în contracte

Dacă ești din IT, cunoști deja conceptul de technical debt. Este obligația pe care un inginer și-o asumă implicit în clipa în care a terminat de scris o bucată de cod: trebuie s-o întrețină, s-o adapteze, uneori s-o explice altora. Regula e simplă — cu cât codul e mai neclar, cu atât «dobânda» la această datorie crește.

Aceeași logică se transpune unu-la-unu în contracte. Un contract scris în grabă, cu termeni inconsecvenți și o structură haotică, creează o datorie rea. Iar dobânda ei nu se plătește azi — se plătește peste un an, doi, când nu-ți mai amintești exact ce ai convenit cu acel partener.

Un exemplu din port

Mă sună colegii: clientul n-a dat destule camioane, n-a asigurat ritmul la descărcare — și din cauza asta stau terminalul, dana și nava. Pierderi pe minut. Munca mea, contra-cronometru: să scot din contract cum sunt împărțite obligațiile, zonele de răspundere, riscul; să prognozez cine, cui și cât compensează.

Și aici se duce resursa. Dacă în contract e dezordine — dacă acea condiție despre camioane rătăcește din capitol în capitol — sunt nevoit să citesc tot. Îmi ard atenția pe căutare. Iar când ajung la momentul care contează, concluzia juridică, resursa s-a dus deja — și acolo greșesc. Exact unde nu trebuie.

Într-un contract sănătos, orice element-cheie are un singur loc — și știi exact unde să-l cauți.

DRY: contract-cadru + condiții speciale

Un contract poate avea peste douăzeci de pagini. Din ele, vreo cincisprezece sunt identice în fiecare contract — definiții, răspundere, notificări, soluționarea litigiilor. Doar o pagină-două conțin ce interesează cu adevărat: ce prestăm, când, pentru cine, la ce tarif.

Dacă ai douăzeci de astfel de șabloane, asta înseamnă peste trei sute de pagini de text duplicat. Și în ziua în care vrei să schimbi o singură prevedere standard — fie și o cifră, penalitatea de la 0,1% la 0,05% — trebuie să deschizi douăzeci de fișiere, să cauți, să înlocuiești, să salvezi. Douăzeci de ocazii de a greși.

Răspunsul: DRY — Don't Repeat Yourself

Scoate cele cincisprezece pagini comune într-un document separat — contractul-cadru. Acolo stă tot ce nu se schimbă de la o tranzacție la alta. Iar într-un al doilea document, mult mai scurt, scrii doar ce e specific: serviciul, tarifele, termenul — condițiile speciale. Un contract gata de semnat se asamblează din două piese. Ca un Lego.

Beneficiile se simt imediat. Cifra pe care voiai s-o modifici o schimbi acum într-un singur loc. Un contract pentru un serviciu nou se pregătește în vreo oră, nu într-o zi. Iar echipa — contabili, manageri de cont — nu mai sapă prin douăzeci de pagini: citește două, cu cifre în format cunoscut.

Un ultim lucru: sistemul nu e bătut în cuie, e un document viu. O dată pe an strângi tot ce s-a acumulat — observațiile echipei, propriile descoperiri — compilezi o versiune nouă și de acolo lucrezi după ea. Cu disciplină de versiuni chiar în numele fișierului: data și numărul.

Ce este, de fapt, un contract?

De obicei spunem «contract» și înțelegem, tacit, un document — pe hârtie sau electronic. Dar dacă deschidem articolul 992 din Codul civil, citim altceva.

«Contract este acordul de voinţă realizat între două sau mai multe persoane prin care se stabilesc, se modifică sau se sting raporturi juridice.»art. 992 Cod civil — niciun cuvânt despre «document»

Cazul emoji-ului de 82.000 $

Canada, 2021. Un cumpărător de cereale trimite unui fermier poza unui contract pentru 86 de tone de in și scrie: «please confirm». Fermierul răspunde cu un singur emoji — 👍 — și apoi nu livrează nimic. În instanță s-a apărat: «un degețel nu e semnătură». N-a ținut. Instanța s-a uitat la cum lucraseră cei doi până atunci și a decis că, în acel context, 👍 înseamnă contract încheiat. Fermierul a plătit peste 82.000 $.

Asta nu înseamnă că orice emoji e o semnătură. E doar o probă. Și nicio probă nu are o putere dinainte stabilită — nici emoji-ul, nici semnătura olografă, nici ștampila. Contextul decide. De-aceea munca noastră nu e să «semnăm», ci să adunăm un dosar care, în ansamblu, dovedește.

Trei moduri de a proba acordul

Hârtie + semnătură olografă. Funcționează și azi, dar cere prezență fizică, logistică, timp — și e vulnerabilă: autenticitatea paginilor, identitatea semnatarului.

Scan + e-mail. Singur dovedește puțin. Dar împreună cu corespondența și cu ce face partenerul după — comandă, plătește, trimite camioanele — dovedește în ansamblu. Regula: salvează e-mailul în aceeași mapă cu PDF-ul.

Semnătura electronică calificată (QES). Standardul de aur: fără prezență fizică, exemplare originale nelimitate, iar dovada e în interiorul fișierului. Nu e ștampila de pe pagină — e un cod criptografic care identifică semnatarul și «îngheață» documentul.

AI ≠ automatizare: scriptul de 50 de cenți

Când cineva îți vinde o «automatizare pe bază de inteligență artificială», merită o întrebare pusă înainte de a semna ceva: chiar e nevoie de un model care «gândește» de fiecare dată — sau e o muncă mecanică, mereu aceeași?

Un model generativ pus pe muncă repetitivă plătește token cu token — adică bani — pentru ceva ce un script banal (Python, ba chiar VBA în Excel) face o dată, gratis, și apoi de fiecare dată identic. Și, apropo, scriptul ăla ți-l scrie tot AI-ul.

Exemplul arhivei

Aveam o arhivă de contracte vechi, scanate, de citit, sortat, redenumit și introdus într-un registru. Prima idee: un agent AI autonom. Dar am întrebat chiar modelul dacă e cel mai rațional mod — și m-a sfătuit să nu-l folosesc așa. Mi-a scris un program clasic în Python. Rezultatul: vreo sută de contracte procesate în câteva minute, cu cam o jumătate de dolar — în loc de un agent care ar fi «mestecat» tokeni ore în șir.

Unde bagi AI-ul în lucru e o evaluare a riscului, nu o alegere tehnică.

Și mai e un risc de luat în calcul: AI-ul procesează datele clienților — date cu caracter personal — pe servere aflate, posibil, peste ocean. Are loc un transfer transfrontalier, pentru care legea cere «garanții adecvate». Lipsa lor se poate plăti scump. Deci: cu ochii deschiși, nu fiindcă «așa e moda».