Projectes que mai s’aprovaven i que ara tenen ROI en setmanes

Tota organització té una llista. Projectes que tothom sap que aportarien valor, però que mai passen del PowerPoint al pressupost. La IA ha canviat el denominador d’aquesta equació i aquests projectes ja no tenen excusa.

No és un problema d’idees. En gairebé qualsevol organització amb més de cinquanta persones, existeix una llista no escrita de projectes que porten anys en espera. Automatitzacions que estalviarien hores cada setmana. Eines internes que l’equip demana i mai arriben. Processos manuals que ningú ha tingut el coratge de calcular en euros reals.

La raó per la qual no s’executen mai és la mateixa: el cost de fer-los no justificava el retorn. Un desenvolupament a mida requeria mesos de feina i un pressupost que el consell no estava disposat a aprovar sense certesa de retorn a 18 o 24 mesos.

Aquest càlcul ja no és vàlid. La intel·ligència artificial ha comprimit dràsticament tant el cost com el temps de validació. I això canvia quins projectes mereixen estar al backlog — i quins mereixen executar-se ja.

Per què els projectes «bons» no s’aprovaven

La paràlisi no era irracionalitat. Era una resposta lògica a una estructura de costos concreta. Durant anys, desenvolupar programari a mida tenia tres característiques que el feien difícil de justificar per a projectes d’impacte moderat:

• Cost fix, valor variable. El cost de desenvolupament era alt i fix, independent del valor del projecte. Un procés que estalviava 10 hores setmanals costava gairebé el mateix que un que n’estalviava 100.
• Payback a llarg termini. El període de recuperació es calculava entre 18 i 24 mesos. Massa risc per a projectes que no eren estratègics de primer nivell, i massa per a la majoria dels consells d’administració.
• El cicle que es perpetua. Any rere any, els mateixos projectes apareixien a la llista de «prioritats per al proper exercici». I any rere any, tornaven al calaix. El cost d’oportunitat acumulat mai no es comptabilitzava.

El problema real no era el cost dels projectes no executats. Era el cost acumulat de mantenir processos ineficients durant anys, multiplicat pel nombre de persones involucrades. Aquest número rarament apareixia a l’anàlisi de pressupost.

Què ha canviat exactament?

L’irrupció de models de llenguatge avançats i eines de desenvolupament assistit per IA no és un canvi incremental. És una ruptura en la corba cost-retorn que afecta directament l’equació d’aprovació de projectes.

Però la xifra més important no és l’estalvi en desenvolupament. És el canvi en el risc percebut. Abans, aprovar un projecte significava comprometre tot el pressupost abans de saber si funcionaria. Ara, es pot construir un pilot funcional en dues setmanes, mesurar l’impacte real, i decidir si escalar — amb dades, no amb suposicions.

El cost d’equivocar-se s’ha reduït tant que la pregunta ja no és si té ROI, sinó per què no s’està executant.

Això no significa que tots els projectes tinguin sentit ara. Significa que el llindar de rendibilitat necessari per aprovar un projecte ha baixat de forma estructural, i que molts projectes que abans no superaven aquest llindar, ara sí que ho fan.

Tres tipus de projectes a reconsiderar ara

No tots els projectes del calaix són igualment recuperables. Hi ha tres categories que concentren la major part del potencial de retorn ràpid:

1. Automatitzacions internes d’alt consum humà. Tasques repetitives que consumien hores de persones valuoses però que no justificaven un projecte formal. Consolidació d’informes, classificació de sol·licituds, generació de respostes estàndard, extracció de dades de documents. Individualment, cada tasca sembla menor. Sumades, representen desenes d’hores setmanals de treball d’alta qualificació destinades a treball de baixa qualificació.
2. Eines pròpies que IT mai tenia temps de construir. Aplicacions internes que l’equip porta anys demanant: cercadors sobre documentació interna, assistents d’onboarding, panells d’estat en temps real. Projectes que sempre perdien davant les prioritats urgents de manteniment. Amb la IA assistint en el desenvolupament, el temps necessari per construir-les s’ha reduït a una fracció del que requeria abans.
3. Processos «que sempre s’han fet a mà». Workflows que ningú ha qüestionat perquè sempre han funcionat així. Revisió manual de contractes, categorització de tickets de suport, preparació de briefings per a reunions. El cost mai no s’ha calculat en termes reals perquè mai no hi ha hagut una alternativa econòmicament viable. Ara n’hi ha.

Com avaluar si un projecte paralitzat ara té ROI

No cal un business case de quaranta pàgines. L’anàlisi inicial es pot fer en menys d’una hora amb tres preguntes concretes.

Senyals d’alerta: quan executar sense més anàlisi

→ El teu equip dedica més d’un dia a la setmana a una tasca repetitiva? Probablement té ROI positiu amb IA.

→ El procés implica extreure, classificar o resumir informació de documents o sistemes? Segur que el potencial d’automatització és molt alt.

→ La resposta a «per què es fa així?» és «sempre s’ha fet així»? Calcula el cost real abans d’assumir que no hi ha alternativa.

→ Si el projecte porta més de dos anys al backlog, el cost acumulat de no haver-lo executat ja supera gairebé amb certesa el cost de desenvolupament actual.

La recomanació no és aprovar tots els projectes del calaix de cop. És revisar la llista amb la nova estructura de costos en ment, identificar els dos o tres projectes amb major ràtio impacte/esforç, i llançar un pilot de dues setmanes. El pilot dóna la resposta real — no una estimació, sinó dades d’ús, velocitat d’adopció i estalvi mesurable.

El risc d’equivocar-se és ara prou baix com perquè el cost d’anàlisi prolongada superi el cost de simplement provar.

Preguntes freqüents

Quina diferència hi ha entre automatització tradicional i automatització amb IA? L’automatització tradicional (RPA, scripts) requereix que el procés sigui perfectament estructurat i predictible: si el format canvia, l’automatització falla. L’automatització amb IA pot gestionar variabilitat, llenguatge natural, documents no estructurats i fins i tot prendre decisions contextuals. Això amplia enormement el tipus de tasques automatitzables — i elimina la fricció de manteniment que feia que moltes automatitzacions RPA resultessin més costoses de mantenir que el propi procés manual.

Quant costa realment un pilot de dues setmanes? Depèn de l’abast, però els rangs han canviat de forma substancial. Projectes que fa dos anys requerien entre 80.000 i 150.000 euros de desenvolupament inicial avui es poden validar amb pilots funcionals entre 8.000 i 25.000 euros. Aquest és el punt d’inflexió: el pilot ja no requereix comprometre el pressupost complet. Si el pilot no demostra ROI suficient, el cost d’haver-ho provat és un ordre de magnitud inferior al cost d’haver-ho desenvolupat completament sense validar abans.

Què passa si el projecte requereix integració amb sistemes legacy? La integració amb sistemes legacy continua sent el factor que més dilata els projectes — això no ha canviat. Tot i això, hi ha una distinció important: molts projectes del calaix no requereixen integració profunda en els sistemes de registre. Poden funcionar sobre outputs d’aquests sistemes (arxius, exportacions, correus) sense necessitat d’accés API. Per als que sí requereixen integració, l’enfocament de pilot primer amb dades de mostra continua sent vàlid per validar l’impacte abans d’acometer la integració completa.

Com convenc el consell d’aprovar un projecte quan el ROI no està garantit? El canvi de marc és clau: no s’està demanant aprovar el projecte, s’està demanant aprovar el pilot. La diferència no és semàntica — és pressupostària. Un pilot de dues setmanes requereix una aprovació de despesa petita, amb un criteri d’èxit mesurable i una decisió de continuïtat explícita en finalitzar. Aquest format redueix la fricció d’aprovació dràsticament. Si el pilot demostra el ROI esperat, l’aprovació del projecte complet ja arriba amb dades reals, no amb projeccions en PowerPoint.

Com es prioritza quins projectes del backlog revisar primer? La matriu més simple és creuar dues variables: freqüència de la tasca (quantes vegades ocorre per setmana) i grau d’estructuració (com de predictible i estandarditzat és el procés). D’una banda, els projectes amb alta freqüència i procés raonablement estructurat tenen el major potencial de ROI ràpid i menor complexitat d’implementació. De l’altra, els d’alta freqüència però molt poc estructurats requereixen més inversió en disseny. Els de baixa freqüència rarament justifiquen l’esforç, llevat que l’impacte per ocurrència sigui excepcionalment alt.

L’equip d’IT necessita capacitats noves per executar aquests projectes? Depèn del punt de partida. Els projectes de menor complexitat — automatitzacions sobre fluxos de documents o integracions via API amb models de llenguatge — es poden executar amb un equip de desenvolupament intermedi que tingui accés als models adequats. Els projectes més complexos, especialment els que requereixen fine-tuning, RAG sobre bases de coneixement pròpies o integració amb infraestructura de dades, sí que requereixen perfils especialitzats. La recomanació pràctica és començar amb projectes que l’equip actual pugui executar, i utilitzar aquests primers resultats per justificar la inversió en capacitats addicionals.

Tens projectes al calaix que podrien tenir ROI amb IA? Explica’ns el cas. En una trucada de 30 minuts t’ajudem a identificar quins tenen més potencial i com validar-los.

T’ho expliquem amb detall al nostre webinar ‘Desarrolla software hasta 10x más rápido con IA’. Accedeix aquí.