Când recomandăm împotriva construirii de software personalizat: un tipar documentat

Notă editorială: Acest articol descrie un tipar de decizie întâlnit în mod repetat în angajamente de consultanță. Nu este un caz singular. Scenariul este construit din elemente observate în mai multe situații reale. Cifrele de costuri specifice sunt excluse deoarece ar necesita fabricare; analiza descrie relații de structură a costurilor, nu cifre inventate.

Există o categorie de solicitare de client pe care o întâlnim în mod regulat. Un proprietar de business sau un responsabil de operațiuni vine cu o problemă specifică de software pe care dorește să o rezolve. A evaluat instrumentele SaaS și a concluzionat că niciunul nu face ceea ce are nevoie. Vrea să construiască ceva personalizat.

Rolul nostru, în viziunea lor, este să confirmăm cerința și să începem să definim domeniul de aplicare. De obicei, asta facem exact. Dar uneori — mai des decât ar trebui să admită o agenție de software — răspunsul corect este să nu construim deloc.

Contextul tipic

Situațiile care produc această recomandare au o formă consistentă. Clientul gestionează o operațiune — logistică, servicii profesionale, meserii, agenții de diverse tipuri. Au un proces care funcționează, dar este manual și fragmentat: foi de calcul, email, WhatsApp, poate un instrument SaaS care nu se conectează cu restul.

Au avut experiențe proaste cu SaaS. Un instrument care promitea să le rezolve fluxul de lucru s-a dovedit a fi construit pentru un alt tip de business. Au pierdut date într-o migrare, au plătit pentru funcționalități pe care nu le-au folosit niciodată, sau au descoperit că foaia de parcurs a produsului a încetat să includă ceea ce aveau nevoie. Concluzia: trebuie să dețină propriul software.

Ce găsim în faza de descoperire

În cazurile care duc la recomandarea de a nu construi, există de obicei un instrument SaaS pe care clientul l-a privit pe scurt, a găsit ceva care nu i-a plăcut și a trecut mai departe. Când îl examinăm mai atent, descoperim că face marea majoritate din ce au nevoie. Restul se împarte în două categorii: lucruri care necesită cu adevărat funcționalitate personalizată și lucruri care sunt neobișnuite în procesul lor actual mai degrabă decât cerințe ale business-ului lor de bază.

A doua categorie este cea importantă. Fiecare business are fluxuri de lucru care au evoluat în jurul limitărilor instrumentelor actuale. Unele reprezintă diferențiere competitivă autentică. Altele sunt adaptări la limitări care nu ar exista într-un instrument SaaS mai bine implementat. Când parcurgem această distincție cu clientul, cerințele personalizate se reduc — adesea suficient pentru a schimba cazul economic.

Analiza pe care o efectuăm

Comparația standard build vs buy este: costul proiectului față de abonamentul anual SaaS. Această comparație ratează costurile care determină economia reală pe termen lung.

Pentru opțiunea SaaS adăugăm: costul de onboarding (timpul personalului pentru migrare, configurare și formare), costul de integrare (orice conexiuni cu alte sisteme) și costul anual de administrare (cine gestionează instrumentul, rezolvă cazurile de suport, formează angajații noi). Acestea sunt costuri reale, adesea semnificative, invizibile în prețul per utilizator.

Pentru opțiunea personalizată adăugăm: costul de mentenanță (cine menține software-ul funcțional, actualizat și sigur după livrare), costul de suport (cine gestionează bug-uri și întrebări ale utilizatorilor după ce echipa originală a trecut la alte proiecte) și costul de dezvoltare viitoare (orice software care se potrivește operațiunii azi nu se va potrivi perfect în 18 luni). Pentru un business fără dezvoltator intern, fiecare dintre acestea este o dependență față de un furnizor extern.

Când adăugăm aceste categorii la ambele opțiuni, economia se schimbă. Opțiunea SaaS, care părea scumpă pentru că abonamentul anual este vizibil, include de fapt multe dintre costurile operaționale continue. Opțiunea personalizată, care părea o investiție unică, poartă costuri operaționale continue care erau invizibile în oferta de proiect.

Ce îi spunem clientului

Recomandarea de a nu construi nu este în primul rând un argument de cost. Este un argument organizațional.

Orice software personalizat creează o dependență. Pentru un business cu capacitate tehnică internă, aceasta este gestionabilă. Pentru un business fără capacitate internă, dependența este externă — trăiește într-o relație cu o agenție sau un freelancer care trebuie menținută, finanțată și gestionată. Când acea relație se rupe, software-ul devine un pasiv. Funcționează, probabil continuă să funcționeze o vreme, și apoi într-o zi nu mai funcționează și nu există nimeni care să știe cum să îl repare.

Asta explicăm când recomandăm să nu se construiască. Nu că software-ul personalizat este rău, ci că software-ul personalizat fără capacitate internă este un angajament pe termen lung pe care oferta de proiect nu îl reflectă. Oferta acoperă construirea. Nu acoperă dependența de 36 de luni care urmează.

Ce se întâmplă mai departe

Unii clienți acceptă această analiză și migrează la instrumentul SaaS. Alții nu — de obicei pentru că au un motiv pe care nu îl știm din faza de descoperire: o experiență anterioară cu dependența față de furnizor, o cerință de suveranitate a datelor, un plan viitor care face cazul proprietății real. Nu ne opunem clienților care aleg altfel. Documentăm raționamentul, notăm ce am recomandat și construim cea mai bună versiune posibilă din ce au cerut.

În cazurile unde am recomandat să nu se construiască și clientul a procedat oricum, tiparul a ceea ce a urmat este instructiv. Software-ul este construit. Funcționează. Relația cu agenția se reduce. Software-ul rulează fără mentenanță mai mult decât s-ar fi așteptat. Apoi nu mai funcționează.

În cazurile unde am recomandat SaaS și clientul a acceptat, tiparul de follow-up este diferit. Există plângeri despre instrument — mereu există. Dar plângerile sunt despre funcționalități specifice, nu despre eșec existențial al software-ului. Business-ul încă folosește software-ul doi ani mai târziu.

Ce ne spune asta despre cum se ia decizia

Decizia build vs buy nu este în primul rând o decizie tehnică. Nu este nici în primul rând o decizie financiară, deși finanțele fac parte din ea. Este o decizie despre ce tip de dependență operațională este acceptabilă.

Software-ul personalizat este o dependență de propria ta capacitate de a-l menține. SaaS este o dependență de foaia de parcurs și deciziile de prețuri ale furnizorului. Niciuna dintre dependențe nu dispare alegând cealaltă opțiune. Întrebarea este pe care dependență o poți gestiona mai bine, date fiind echipa reală și resursele reale pe care le ai.

Majoritatea analizelor build vs buy compară costurile vizibile și ignoră dependențele operaționale. Recomandarea de a nu construi apare când putem vedea că dependența implicată de proprietatea personalizată este una pe care organizația nu este echipată să o gestioneze — și când alternativa SaaS este suficient de aproape de ceea ce au nevoie, astfel încât dependența față de furnizor este mai gestionabilă decât dependența față de cod personalizat.