Com Triar Proveïdor Tecnològic sense Arruïnar-te (i sense Caure en una Càrnica)

El 68% dels projectes de programari externalitzats a Espanya acaben costant més del doble del pressupostat. No perquè la tecnologia falle, sinó perquè l'empresa va triar proveïdor mirant una sola variable: el preu per hora. És com triar cirurgià pel que cobra menys per minut en quiròfan. Tècnicament lògic. Pràcticament suïcida.

Portem anys veient el mateix patró. Una empresa necessita digitalitzar un procés, demana tres pressupostos, tria el més barat i díhuit mesos després té un sistema a mig funcionar, un proveïdor que ha rotat l'equip dues vegades i una factura que supera amb escreix la del pressupost "car" que van descartar al principi.

El problema no és que no hi haja bons proveïdors a Espanya. N'hi ha. El problema és que el procés de selecció que fan servir la majoria d'empreses està dissenyat per a triar malament.

El mercat espanyol del programari: tres categories que ningú t'explica

Quan una empresa busca un proveïdor tecnològic a Espanya, es troba amb un ecosistema que sembla homogeni des de fora però que funciona de maneres radicalment distintes per dins. Hi ha tres models operatius, i entendre'ls canvia completament la conversa.

Les càrniques. El nom ve del sector i no és afectuós. Són empreses que bàsicament lloguen cossos. Tenen una base de dades de CVs, un departament comercial agressiu i un marge que ix de la diferència entre el que et cobren per hora i el que li paguen al desenvolupador. El desenvolupador no tria estar en el teu projecte. L'hi han assignat perquè estava lliure. Si demà ix un altre projecte que paga millor, el mouen i et posen un altre. El teu projecte és una línia en un Excel d'ocupació. Aquestes empreses no venen resultats. Venen hores. I com més hores necessites, millor els va. Pensa en això un moment.

Les factories de programari. Un pas per damunt. Ací sí que hi ha equips més o menys estables, metodologia de projecte i un delivery manager que fa seguiment. Et pressuposten un projecte tancat amb abast definit. El problema és el model de propietat: construeixen el programari segons les especificacions que els dones, te'l lliuren i se'n van. Si les especificacions estaven malament, el programari està malament. Si el negoci canvia als sis mesos, el programari no canvia amb ell. És un model transaccional. Funciona per a projectes amb requisits estables i ben definits. No funciona per a quasi res que tinga a veure amb la realitat d'una empresa en moviment.

Els partners de producte. Aquest és el model menys freqüent i el més difícil de trobar. Són empreses que s'impliquen en el resultat de negoci, no només en el lliurament tècnic. Entenen la teua operació, participen a definir què cal construir i es responsabilitzen que el programari genere l'impacte esperat. No et venen hores ni projectes tancats. Et venen capacitat d'execució tecnològica integrada en la teua empresa. Construeixen actius que queden com a propietat del client. A SAUCO ho anomenem l'enfocament FDE, i és la raó per la qual existeix l'empresa.

La majoria de processos de compra no distingeixen entre aquests tres models. Posen els tres en la mateixa comparativa, demanen preu per hora i trien. És com comparar un taxi, un autobús i un copilot de ral·li fent servir només el cost per quilòmetre.

La trampa del preu/hora i per què el teu CFO hauria d'odiar-la

Anem a fer números. És l'únic que funciona per a desmuntar aquesta trampa.

Suposa que necessites construir un sistema de gestió de comandes integrat amb el teu ERP. Demanes pressupost a dos proveïdors.

Proveïdor A: t'ofereix un equip de tres perfils amb poca experiència a 32 €/hora cadascun. Estimació: 6 mesos. Cost estimat: 3 persones × 32 €/h × 160 h/mes × 6 mesos = 92.160 €.

Proveïdor B: t'ofereix un equip senior amb perfils full-stack a una mitjana de 72 €/hora. Estimació: 3,5 mesos. Cost estimat: 72.800 €.

El CFO mira el preu per hora i veu 32 contra 72 de mitjana. Tria A. Evidentment.

Excepte que no. Perquè els perfils del Proveïdor A necessiten supervisió que no tenen. Als dos mesos cal refer l'arquitectura de dades perquè no van contemplar concurrència. Als quatre mesos roten a un dels tres perquè "el necessiten en un altre projecte". El substitut tarda tres setmanes a posar-se al dia. El projecte s'allarga a nou mesos. S'afig un quart recurs per a "accelerar". El cost real acaba en 148.000 € i el sistema ix amb defectes que requereixen altres 20.000 € en correccions durant el primer any.

El Proveïdor B va lliurar en quatre mesos, lleugerament per damunt de l'estimació. Cost final: 83.200 €. Sistema estable. Sense refer.

Diferència real: 84.800 €. A favor del proveïdor "car".

El que més em sorprén quan veig això és que no és un cas extrem. És el cas mitjà. Les dades de Standish Group porten dècades mostrant que els projectes amb major seniority a l'equip tenen taxes d'èxit significativament majors. Però el procés de compra continua optimitzant per a la variable equivocada.

El preu per hora mesura el cost de l'input. No mesura el valor de l'output. La teua empresa no necessita comprar hores de programació. Necessita comprar capacitat de resoldre problemes de negoci amb tecnologia.

Set preguntes que el teu proveïdor actual no vol que faces

Si estàs avaluant proveïdors ara mateix, o si vols auditar el que ja tens, aquestes set preguntes separen els que construeixen actius dels que facturen temps. Hem desenvolupat una guia completa de criteris de selecció amb més detall, però aquestes són les que més incomoden.

1. Puc parlar amb l'equip tècnic que treballarà en el meu projecte abans de firmar? Si la resposta és "encara no hem assignat l'equip", fuig. Significa que el teu projecte és un slot en un calendari de recursos, no una decisió tècnica.

2. Qui és el propietari del codi font des del dia u? No al final del projecte. No quan es pague l'última factura. Des del primer commit. Si el contracte diu una altra cosa, estàs finançant un actiu que no et pertany.

3. Quin és el nivell d'experiència real de l'equip proposat? No el que posa al CV. El verificable. Demana perfils concrets amb anys d'experiència en projectes comparables al teu. Un equip on només hi ha un perfil experimentat envoltat de gent que està aprenent no és un equip senior — és formació subvencionada per la teua factura.

4. Què passa quan el projecte es lliura? Aquesta pregunta revela més que qualsevol altra. Si la resposta és "firmem un contracte de manteniment a part", el proveïdor no es fa responsable del que construeix més enllà del lliurament. El programari no acaba quan es desplega. Comença.

5. Poden donar-me tres referències de projectes similars al meu on puga parlar amb el client directament? No testimonis a la web. Telefonades reals amb persones reals que confirmen abast, termini i resultat. Si no poden o no volen, ja tens la teua resposta.

6. Com gestionen el coneixement quan algú de l'equip se'n va? La rotació en el sector tech espanyol és alta. Un bon proveïdor té documentació, pair programming, code reviews i processos que minimitzen l'impacte. Un de roín et diu "no es preocupe, això no passarà".

7. Heu dit que no a un projecte en els últims sis mesos? Un proveïdor que accepta tot no té criteri. Els bons diuen que no quan el projecte no encaixa amb la seua capacitat o el seu model. Els que diuen sí a tot estan venent cossos, no solucions.

El portfolio inflat: com detectar projectes fantasma

Obris la web d'un proveïdor i veus logos d'empreses conegudes. Telefónica. Repsol. Inditex. Impressiona. Fins que t'assabentes que la seua contribució a aqueix projecte va ser posar un desenvolupador durant dos mesos dins d'un equip de 40 persones gestionat per una altra empresa.

Això és més freqüent del que sembla. Les càrniques, per definició, col·loquen persones en projectes aliens. Cada projecte on col·loquen algú es converteix en un "cas d'èxit" al seu portfolio. Tècnicament no menteixen. Van participar. Però la diferència entre "vam participar en el projecte de transformació digital de [gran empresa]" i "vam liderar i lliurar el sistema complet" és la diferència entre ser extra en una pel·lícula i ser-ne el director.

Hi ha senyals que delaten els portfolios inflats.

Absència de detall tècnic. Si la descripció del projecte parla de "transformació digital" i "solucions innovadores" però no menciona ni una tecnologia, ni una mètrica de resultat, ni un repte concret que van resoldre, probablement no van resoldre res concret.

Logos sense context. Mostrar el logo d'una multinacional sense explicar què van fer exactament, amb quantes persones i durant quant de temps és màrqueting, no és portfolio.

Projectes que no pots verificar. Demana parlar amb algú del client. Si el proveïdor posa excuses, el projecte o no va existir com el conten o el client no va quedar content.

El mateix projecte descrit de tres maneres distintes. Ho he vist: un mateix engagement apareix a la web com "desenvolupament de plataforma", a la proposta comercial com "consultoria estratègica" i a LinkedIn com "transformació end-to-end". Tres línies al portfolio que en realitat són una sola, i modesta.

Un portfolio real té projectes amb noms, números i conseqüències. "Vam construir el sistema de picking del magatzem X. Vam reduir el temps de preparació de comanda de 12 minuts a 4. Projecte de 5 mesos amb equip especialitzat." Això és verificable. La resta és fum.

Com documentem a Low-Code és Deute Tècnic amb Interfície Bonica, en el programari el que importa és què queda quan el proveïdor se'n va. Si el que queda és un actiu teu que funciona, van triar bé. Si el que queda és una dependència que no pots tallar, van triar malament.

Per què "Forward Deployed" canvia l'equació

Tot l'anterior descriu un mercat trencat. El model FDE existeix precisament perquè aqueix mercat no resolia el problema real.

La idea darrere del El Naixement del FDE és senzilla: en comptes que el client especifique el que necessita i el proveïdor ho construïsca en remot, l'enginyer s'integra en l'operació del client. Veu el problema de primera mà. Entén les restriccions reals, no les que algú va escriure en un document de requisits fa tres mesos.

Això canvia tres coses fonamentals.

L'enginyer és responsable del resultat, no del lliurament. En una càrnica, l'èxit es mesura en hores facturades. En una factoria, en funcionalitats lliurades. En el model FDE, l'èxit es mesura en impacte operatiu. El magatzem processa més comandes? L'equip comercial tanca més ràpid? El procés que abans tardava dos dies ara tarda vint minuts? Si no, el treball no està fet, tant se val quantes línies de codi s'hagen escrit.

No hi ha "presa de requisits" separada de la construcció. El FDE observa, prototipa, valida amb usuaris reals i ajusta. El cicle entre "entendre el problema" i "lliurar la solució" es comprimeix de mesos a dies. Els requisits no es recullen en una reunió; es descobreixen a la trinxera.

El codi és teu des del minut u. Tot es construeix als repositoris del client, amb tecnologies estàndard, documentat perquè qualsevol equip puga continuar-ho. Si l'endemà el client vol prescindir del proveïdor i muntar equip intern, pot fer-ho sense reescriure res. Això no és un detall contractual. És una decisió arquitectònica que reflecteix per a qui treballa realment el proveïdor.

A SAUCO apliquem aquest model perquè hem vist des de dins el que passa amb els altres. Hem arreplegat projectes abandonats per càrniques a mig fer. Hem migrat sistemes lliurats per factories que el client no podia mantindre. I en tots els casos, el cost d'arreglar era major que el d'haver-ho fet bé des del principi.

No és el model més fàcil de vendre. Requereix enginyers que sàpien parlar amb un director d'operacions i també escriure codi en producció. Requereix dir que no a projectes on només necessiten un cos assegut. Però és el model que genera actius reals per al client i relacions que duren anys, no mesos.

Estàs avaluant proveïdors o vols entendre millor com funciona el model FDE? Consulta la nostra guia completa de criteris de selecció per a una comparativa estructurada, o llig el nostre manifest per a entendre per què vam construir SAUCO d'aquesta manera.