Custom sau de pe raft
Nu există un răspuns general între soluția cumpărată și cea construită. Există o comparație verificabilă, pe același flux, cu costul întregului ciclu de viață.
„Custom sau de pe raft” nu e o alegere de tabără care se câștigă o dată, la nivelul întregii companii. E o comparație pe fiecare flux în parte: ce nevoie trebuie acoperită, cât acoperă configurarea unui produs deja existent, ce transfer manual rămâne după, cine operează soluția mai departe și cât costă să ieși din ea dacă nu mai merge. Un verdict general, construiești mereu sau cumperi mereu, sare peste exact întrebarea care contează.
De ce fiecare tool a fost alegerea corectă, la momentul ei
Poți ajunge aici chiar dacă fiecare unealtă cumpărată separat a rezolvat o problemă reală și punctuală, ca facturarea sau suportul pentru clienți, și fiecare decizie, izolat, a părut rezonabilă. Ce rămâne nedecis explicit e cine deține adevărul comun între ele: cine spune, când doi clienți diferă, care e cifra corectă. Nu e neapărat vina unei persoane. Poate fi pur și simplu o decizie de arhitectură care nu s-a luat la momentul cumpărării.
Costul care nu apare în factură
Lipitura dintre unelte separate costă, dar costul nu stă în abonamentul lunar. Stă în timpul cuiva care mută date dintr-un sistem în altul, în decizia amânată pentru că nimeni nu e sigur care variantă e cea bună și în riscul tăcut ca cele două valori să ajungă să difere, fără ca cineva să observe imediat. Bugetarea mentenanței se face indiferent de decizia de a construi sau de a cumpăra[2], recomandă un ghid guvernamental american de achiziții digitale, exact pentru că întreținerea, nu achiziția inițială, e partea care costă pe termen lung. Cumpărarea unei unelte în plus nu elimină costul ăsta. Poate muta o parte din el din factură în operare, unde e mai greu de văzut și, de-asta, mai greu de bugetat.
Grila care chiar decide
Testul rapid, câte unelte ating fluxul și câte transferuri manuale există între ele, arată dacă problema e reală. Nu decide singur ce faci cu ea. Un ghid britanic de achiziții publice enumeră drept motive pentru build nevoia e unică sau rară, piața nu poate acoperi, scala sau integra ce ai deja, iar tu chiar ai capacitatea să operezi ce construiești[1], și drept motive pentru buy există deja o soluție comercială care acoperă majoritatea nevoii prin configurare, fără personalizare amplă[1]. Sunt motive dintr-o grilă, nu o regulă obligatorie.
Diferența dintre configurare și modificare contează aici. Configurarea înseamnă să folosești setările native ale unui produs; modificarea înseamnă să-i schimbi codul de bază[2]. Modificarea codului de bază adaugă mentenanță proprie: chiar și modificări mici pot pierde beneficiile produsului standard și pot îngreuna mentenanța[1]. Și cumpărarea nu elimină singură riscul de integrare: aducerea unei componente de la un furnizor terț într-un sistem mai mare ridică propriile probleme de calitate, origine și securitate[3].
Grila reală compară cinci lucruri, nu unul: nevoia acoperită, integrarea cu ce ai deja, cât costă o schimbare ulterioară, cine operează soluția zi de zi și cât costă să ieși din ea dacă alegerea nu mai ține. Reducerea transferului manual e un singur criteriu din cinci, nu răspunsul complet: poate reduce lipitura și, în același timp, poate crește costul de operare sau de ieșire.
La nivelul UE, 53% dintre întreprinderile cu cel puțin 10 persoane ocupate, din sectoarele măsurate, foloseau deja un produs de ERP, CRM sau BI în 2025[4]; doar pentru ERP, adopția variază de la 41% la firmele mici la 89% la firmele mari, în aceeași populație[4]. Cifrele arată cât de răspândite sunt produsele standard în această populație, nu câte transferuri manuale ai tu între ele acum. Asta rămâne o întrebare la care doar fluxul tău concret poate răspunde.
Ce verifici înainte de următorul tool
Ordinea contează. Listezi uneltele care ating fluxul respectiv. Numeri transferurile manuale și excepțiile care ies din regulă. Verifici dacă există deja o legătură legitimă între sisteme, scrisă independent de cineva care nu s-a gândit s-o documenteze ca atare.
Am găsit exact asta într-un sistem propriu[5]. Un identificator de sesiune era scris separat, la momente diferite, în două sisteme care nu se citeau unul pe altul: colectorul de evenimente și baza de cereri. Nimeni nu-l declarase drept „cheia comună”, dar exista deja, scris corect în ambele locuri. Verificarea a confirmat-o: aceeași sesiune, aceeași secundă, în ambele sisteme. N-a fost nevoie de un identificator nou sau de o migrare ca să legăm cele două înregistrări. A fost nevoie doar ca cineva să caute în codul care scrie datele, nu într-o presupunere.
Abia după ce faci lista, numeri transferurile și verifici legătura separi configurarea de modificare, și abia apoi compari custom, de pe raft sau hibrid pe operare și pe ieșire, nu doar pe cât de repede pornești.
Fiecare pas de mai sus se face pe fluxul real, nu într-un tabel general de argumente pro și contra. Dacă vrei să treci un flux al tău prin grila asta, scrie-ne la [email protected]. Construim arhitecturi modulare, cu limite și responsabilități explicite.