Software a mida o estàndard: comprar o construir?
Software a mida o estàndard? Marc pràctic per a pimes: la regla del 80%, el cost total real a tres anys, senyals que l'estàndard es queda curt i 5 preguntes.
En aquesta pàgina
Una confessió poc habitual en un estudi de programari a mida: la majoria de les vegades, el que et convé és comprar l’eina estàndard. Comptabilitat, correu, nòmines, videotrucades: són problemes resolts, i tornar-los a construir és la millor manera de fer volar el pressupost.
La pregunta interessant és on s’acaba aquesta “majoria de les vegades”. Perquè moltes empreses arriben a un punt en què l’eina estàndard deixa d’encaixar, i adonar-se’n a temps estalvia molts diners, tant en un sentit com en l’altre.
La regla del 80%
La nostra regla pràctica: si un producte existent cobreix el 80% o més del teu flux de treball real tal com ve de fàbrica, compra’l i adapta el 20% restant a l’eina. L’economia del SaaS — el cost de desenvolupament repartit entre milers de clients — és imbatible per als problemes comuns.
La regla també funciona al revés. Quan la cobertura s’acosta més al 60%, el teu equip es passa els dies cobrint el buit: exportant, tornant a importar, mantenint “el full de càlcul que arregla el sistema”. Aquest buit té un cost en nòmina, en errors i en moral, però no apareix mai com a partida, i per això ningú no el pressuposta.
La comparació real: cost total de propietat
Compara un horitzó de tres anys, no un preu de compra:
Comprar vol dir subscripció × usuaris × 36 mesos, més les hores dedicades a cobrir el buit, més les pujades de preu que no controles, més el dia que el proveïdor retira la funció de la qual depens. Per a un equip de 15 persones amb una eina de 40 €/usuari, són més de 21.000 €, abans de comptar ni una hora de feina per cobrir el buit.
Construir vol dir un projecte d’un sol cop (mira el nostre desglossament honest de costos — una eina interna ben acotada se sol quedar a la part baixa de les cinc xifres, o per sota), més un manteniment que sol voltar el 10–20% anual. No es paga per usuari: l’usuari 5 i l’usuari 50 costen el mateix. I encaixa amb el 100% del flux de treball, perquè el flux de treball és l’especificació.
Cap de les dues opcions no guanya sempre. El que cal és fer de debò els números de totes dues; la majoria d’empreses només en calculen una.
Senyals que l’estàndard és suficient
Sigues-hi honest, perquè t’estalvien un projecte de vanitat ben car:
- El teu procés és estàndard al teu sector (si tots els competidors el fan igual, ja hi ha un producte que ho resol bé).
- El volum és baix i t’hi jugues poc.
- El necessites la setmana que ve, no el trimestre que ve.
- Ningú a l’empresa no es faria càrrec de l’evolució d’una eina pròpia.
Senyals que l’eina se t’ha quedat petita
Aquests patrons solen indicar que un projecte de programari a mida hauria d’haver començat abans:
- Contorsions del flux de treball. El teu equip ha canviat la manera de treballar per adaptar-se a l’eina, no al client.
- Fulls de càlcul de pegat. El procés real viu en fulls de càlcul que fan de pont entre dos sistemes, mantinguts per una persona heroica.
- El preu per usuari fa mal. T’ho penses dues vegades abans de donar accés a algú pel que costa una llicència més.
- Dades aïllades. Les xifres existeixen, però reunir-les per a una sola decisió costa un dia d’exportacions.
- El purgatori de les peticions. La millora que la teva operativa necessita porta dos anys “al full de ruta del proveïdor”.
Si en reconeixes tres o més, la regla del 80% ja s’ha girat: pagues en hores de pedaços el que costaria un programari a mida, i encara amb les limitacions d’una eina estàndard.
El camí híbrid
La fórmula més sòlida poques vegades és construir-ho tot o comprar-ho tot: compra el que és genèric i construeix el que et diferencia. Queda’t el programa de comptabilitat estàndard i el CRM, i construeix la capa a mida que és realment teva: la lògica de pressupostos que només té el teu negoci, la planificació de producció que encaixa amb la teva planta, les integracions que fan parlar les teves eines. Aprofites l’economia del SaaS allà on fas el mateix que tothom i tens un avantatge a mida allà on no.
La llista de les 5 preguntes
Abans de qualsevol decisió de comprar o construir, respon això per escrit:
- Hi ha un producte que cobreixi el 80% del nostre flux de treball real? Prova’l amb el teu procés real, no amb el guió de la demo del venedor.
- Quant costa el buit cada mes? Hores × persones × taxa d’errors. Posa-hi una xifra, ni que sigui aproximada.
- Aquest procés et diferencia o és genèric? Construeix només el que et fa diferent.
- Quin és el cost a 3 anys de cada camí? Les subscripcions s’acumulen; el desenvolupament s’amortitza.
- Qui decideix el dia 400? En un cas, el full de ruta d’un proveïdor; en l’altre, tu — sempre que el que s’entrega, i amb quina llicència, hagi quedat acordat per escrit.
Si les respostes apunten a construir, defineix bé l’abast amb algú amb experiència abans de creure’t cap pressupost: aquesta conversa és exactament el que ofereix la nostra primera trucada de 30 minuts, i acaba amb una proposta escrita amb preu tancat.
Preguntes freqüents
El programari a mida no és arriscat per a una pime? El risc es concentra en com es construeix, no en la decisió en si: pressupost tancat, pagaments per fites, demos setmanals i condicions per escrit sobre què s’entrega en redueixen bona part. Els projectes oberts i amb un abast difús sí que es mereixen la fama que tenen.
Podem començar amb programari estàndard i migrar més endavant? Sovint és la seqüència ideal: l’eina t’ensenya els requisits reals a baix cost. Només cal que les dades siguin exportables: el lligam que s’ha de témer és el de les dades, no el dels contractes.
I les plataformes low-code com a terme mitjà? Són realment útils per a eines internes, fins que el volum, la complexitat o les condicions de llicència toquen sostre. Tracta-les com un “comprar” amb flexibilitat extra, i aplica-hi la mateixa regla del 80%.
Quant triga de debò un desenvolupament a mida? Depèn de l’abast, així que no hi ha una xifra honesta en abstracte: el termini de cada projecte es fixa per escrit a la proposta, i pel camí hauries de veure programari funcionant cada setmana. El que allarga els projectes no és el codi, sinó l’abast per decidir.