15 iulie 2026

De ce mor sistemele după livrare

Un sistem software nu se termină la livrare. Ce înseamnă asta pentru decizia de a cumpăra un sistem și ce întrebi înainte să semnezi.

Livrarea nu e finalul

Livrarea închide proiectul, nu viața sistemului. Din ziua în care intră în producție, un sistem începe să coste, iar o livrare impecabilă nu garantează că peste doi ani mai face ce trebuie, mai poate fi schimbat sau mai e sigur. Dacă nimeni nu are responsabilitatea, ritmul și capacitatea de a-l observa și adapta, sistemul pierde treptat legătura cu munca pentru care a fost construit.

Standardul internațional de mentenanță software e explicit: activitățile de mentenanță se desfășoară și înainte de livrare^[1], iar exemplul pe care îl dă pentru ele este chiar planificarea operării de după livrare. Manualul de servicii al guvernului britanic o pune mai simplu: un serviciu live nu e terminat^[4], iar îmbunătățirea continuă e ce îi permite să răspundă la nevoi, tehnologii și reguli noi.

Pentru cine semnează, consecința e directă. Dacă în ofertă nu există planul de după livrare, nu e o omisiune de documentație. E o etapă lipsă.

Costul se mută după semnătură

Standardul nu dă un procent. Spune doar că mentenanța consumă o parte majoră din resursele financiare ale ciclului de viață^[1], și e onest că se oprește acolo.

O cifră există totuși, cu domeniul ei declarat. Guvernul federal american cheltuie peste 100 de miliarde de dolari pe an pe IT și securitate, iar agențiile raportează în mod tipic circa 80% din sumă pe operarea și întreținerea sistemelor existente^[2], nu pe construcția lor. Sunt agenții federale americane, nu piața românească și nu proiectul tău. Cifra nu se transferă. Întrebarea pe care o ridică, da: cât din costul total al sistemului vine după semnătură și cine îl plătește?

De ce moare, de fapt

Lehman a studiat cum se schimbă programele în timp și a formulat câteva regularități care s-au dovedit greu de ocolit. Sunt mecanismul din spatele senzației că sistemul „merge mai prost ca la început”, deși nimeni n-a stricat nimic.

Mediul se mișcă, sistemul nu. Un sistem care mecanizează o activitate reală trebuie adaptat continuu, altfel devine progresiv mai puțin satisfăcător^[3]. Nu s-a defectat. Lumea din jurul lui s-a schimbat, iar el a rămas pe loc.

Complexitatea crește singură. Pe măsură ce sistemul evoluează, complexitatea lui crește, dacă nu se lucrează explicit ca ea să fie menținută sau redusă^[3]. „Explicit” e cuvântul care contează. Nimeni nu simplifică un sistem din greșeală și nimeni nu o face gratis.

Calitatea pare că scade, fără vinovat. Va părea că scade dacă sistemul nu e riguros întreținut și adaptat la schimbările din mediul în care rulează^[3].

Sub același cuvânt se ascund trei lucruri diferite, și merită separate o dată. Operarea ține sistemul în funcțiune. Mentenanța îl repară și îl ajustează când ceva nu mai e în regulă. Evoluția îl schimbă odată cu businessul, pentru că businessul nu stă. În practică se suprapun, dar o ofertă care acoperă una dintre ele nu le acoperă pe celelalte două.

Momentul în care nu se mai poate schimba

Sistemul nu doar costă mai mult. La un punct, refuză să se schimbe.

Din 11 sisteme critice analizate de auditorul guvernamental american, 8 rulează pe limbaje învechite, 7 operează cu vulnerabilități de securitate cunoscute, iar doar 3 au un plan de modernizare complet documentat^[2]. Au între 23 și 60 de ani și costă circa 754 de milioane de dolari pe an doar ca să fie ținute în viață. Două, de la Trezorerie, rulează COBOL și cod de asamblare, limbaje pentru care numărul de oameni cu competențele necesare e în scădere^[2].

Traducerea pentru ziua în care contează: când ai cel mai mult nevoie ca sistemul să se schimbe, fiindcă a apărut un client mare, o lege nouă sau un concurent care mișcă mai repede, atunci descoperi că nu se mai poate. Nu pentru că nu vrea nimeni. Pentru că nimeni nu mai poate garanta ce strică.

Sistemul care arată verde și e mort

Sistemul nostru de preluare a cererilor era live din 6 iulie. Verificarea automată săptămânală trecea, verificarea de sănătate răspundea „ok”, tabloul de bord nu semnala nimic. Pe 14 iulie, un control de rutină făcut de om a găsit în coadă o cerere reală de la un client, trimisă pe 7 iulie. Stătea acolo de șapte zile, fără confirmare, fără notificare internă, și nimic din sistem nu urma s-o ia vreodată.

Nimic nu era stricat, în sens strict. Doar că treaba nu se făcea. Monitorizarea trebuie să răspundă la ce e stricat și de ce^[7]. A noastră nu ajungea la niciuna dintre întrebări: verifica un drum pe care nu intra niciun client, așa că răspunsul ei rămânea verde orice s-ar fi întâmplat pe drumul real.

Ce întrebi înainte să semnezi

Cine operează sistemul după livrare și cu ce ritm? Standardul numește explicit momentul predării de la organizația care dezvoltă către cea care întreține, tranziția software^[1]. Dacă în ofertă nu apare acel moment, el se va întâmpla oricum, doar că neplanificat și în ziua în care ceva arde.

Cum aflu că sistemul nu-și mai face treaba, dacă nimic nu e căzut? Uptime-ul și erorile interne sunt semnale despre sistem, nu despre treaba lui. Întreabă ce anume verifică traseul pe care îl parcurge un client real, cap-coadă.

Cine urmărește vulnerabilitățile și dependențele după release? Identificarea vulnerabilităților rămase, răspunsul la ele și prevenirea recurenței^[6] sunt o practică declarată într-un cadru oficial, nu un favor. „Codul a funcționat la recepție” nu acoperă obligația asta.

Schimbările vin în bucăți mici și dese, sau într-un big-bang la doi ani? Cercetarea DORA arată an după an că modificările mari sunt mai lente și mai predispuse să creeze instabilitate^[5]. Noi lucrăm în ritm săptămânal fiindcă așa schimbarea rămâne ieftină, dar ăsta e modul nostru de lucru, nu o cadență prescrisă de cercetare.

Ce cumperi, de fapt

Proiectul se termină, sistemul rămâne. Când cumperi un sistem, plătești pentru capacitatea de a-l schimba în anii în care încă îți trebuie. Predarea la o dată fixă e doar începutul acelei perioade.

Așa lucrăm: ownership de la discovery până la operare, ritm săptămânal, raportare transparentă, KPI-uri comune. Fără promisiuni despre rezultatul tău, fiindcă nu e al nostru de promis.

Întrebările de dinainte de semnătură funcționează și retroactiv, pe un sistem pe care îl ai deja. Răspunsurile îți arată unde stai. Dacă vrei să le răspundem împreună, scrie-ne la [email protected].