Tres errors que frenen el ROI en projectes d'IA (i com evitar-los)

Un projecte d'IA pot semblar rendible i encara no haver demostrat retorn econòmic. Passa quan convertim hores teòricament estalviades en euros que l'empresa mai no arriba a capturar, deixem fora costos necessaris per operar la solució o atribuïm a la IA una millora que també depèn d'altres canvis en procés, persones o demanda.

El problema no és menor. Una automatització pot reduir de manera evident el temps dedicat a una tasca i, tot i així, oferir un retorn força inferior a l'esperat quan afegim integració, supervisió, consum, manteniment i el treball necessari perquè la nova capacitat segueixi funcionant.

Per això, per adreça, la pregunta útil no és simplement “quant estalvi produeix la IA?”. És una altra: “quin valor addicional podem atribuir realment al projecte després de comptabilitzar tot allò que costa crear-lo, operar-lo i controlar-lo?”.

A R&R trucarem ROI defensable a un càlcul que es pot explicar davant de direcció sense dependre de supòsits ocults: part d'una situació anterior coneguda, diferència benefici potencial de benefici realment capturable, incorpora el cost total del projecte i fa explícites les hipòtesis que encara no s'han pogut observar.

No vol dir que el ROI s'hagi de conèixer amb precisió absoluta abans de començar. En un pilot sempre hi haurà incertesa. Significa que hem de saber quina part estem mesurant, quina part estem estimant i quina hauria de complir-se perquè la inversió compensi.

1. Què vol dir realment ROI en un projecte d'IA

Bona part de la confusió sobre el retorn de la intel·ligència artificial apareix perquè fem servir la paraula ROI per descriure coses diferents. Una eina es pot utilitzar molt, produir més ràpid, millorar una tasca o fins i tot reduir un cost operatiu sense que totes aquestes millores constitueixin per elles mateixes un retorn financer atribuïble al projecte.

El ROI és una relació econòmica: compara el benefici net generat per una inversió amb el cost necessari per obtenir-lo. Per tant, abans de calcular-ho necessitem saber quin resultat ha canviat, quin valor econòmic té aquest canvi i quina part es pot atribuir raonablement a la nova capacitat.

1.1. Activitat, output, resultat i impacte econòmic no són el mateix

Un projecte pot mostrar senyals positius molt abans d'haver demostrat retorn. De fet, convé que les mostri: adopció, velocitat o qualitat són indicadors útils per saber si la solució funciona. L'error comença quan fem servir aquests senyals com a substitut de la conseqüència econòmica final.

Un projecte pot tenir molta adopció i poc de ROI. També pot tenir poc volum i generar un retorn excel·lent si actua sobre una tasca petita però econòmicament important.

1.2. El problema de mesurar massa aviat

Durant un pilot és normal treballar amb indicadors intermedis. No tindria sentit esperar dotze mesos per saber si una automatització està reduint el temps d'una tasca o si un assistent comercial millora la preparació de determinades interaccions. Aquestes mètriques serveixen per decidir si val la pena continuar.

El que hem d'evitar és convertir un senyal primerenc en una conclusió econòmica definitiva. Una reducció de temps observada durant dues setmanes es pot degradar quan augmenta el volum, apareixen excepcions, canvien els usuaris o incorporem tots els controls necessaris per operar en producció.

L'IBM Institute for Business Value va trobar un senyal semblant al seu estudi del 2025 amb 2.000 CEO de 33 països: els enquestats van indicar que només el 25 % de les iniciatives d'IA havia lliurat el ROI esperat i només el 16 % s'havia escalat a tota l'empresa. De nou, la xifra no s'ha de traslladar mecànicament a una pime concreta, però sí que reforça una conclusió útil: experimentar, escalar i obtenir el retorn previst són etapes diferents.

Font: IBM Institute for Business Value · 2025 CEO Study

1.3. Què significa que un ROI sigui “defendible”

A R&R utilitzem l'expressió ROI defensable per distingir una estimació comercial o exploratòria duna avaluació que pot sostenir una decisió dinversió.

Un ROI defensable no exigeix conèixer el futur. Exigeix quina direcció pugui reconstruir el raonament: d'on surt la baseline, quina millora s'ha observat, com es converteix aquesta millora en valor, quina part podem atribuir al projecte, quins costos estem incorporant i quina hipòtesi segueix obert.

1.4. El ROI no s'ha d'utilitzar per justificar una decisió ja presa

Hi ha una altra distorsió freqüent: construir el business case després d'haver decidit quina eina volem implantar. En aquest moment el càlcul deixa de funcionar com a criteri i es comença a convertir en una justificació.

L'ordre hauria de ser el contrari. Primer identifiquem quin resultat empresarial mereix millorar, després estimem quin valor ho hauria de fer, calculem quin cost podem assumir i finalment comprovem si la IA ofereix una manera suficientment bona d'intervenir.

Amb aquesta base ja podem entrar als tres errors que més deformen la lectura econòmica. El primer és especialment comú perquè sembla intuïtiu: convertir tota millora operativa, i especialment tot temps aparentment estalviat, en benefici econòmic.

2. Error 1: convertir activitat o estalvi aparent en benefici econòmic

El primer error apareix fins i tot abans d'introduir costos a l'equació: donar per fet que tota millora operativa té el mateix valor econòmic que la millora que som capaços de mesurar.

És especialment freqüent amb el temps. Si una tasca que abans requeria deu hores passa a necessitar-ne sis, sembla raonable afirmar que hem “estalviat quatre hores”. Com a mesura operativa pot ser correcte. Com a benefici financer, encara no en sabem prou.

Aquestes quatre hores es poden convertir en cost evitat, en capacitat per absorbir més feina, en temps dedicat a una activitat de més valor o simplement en una comoditat que l'organització no utilitza de manera diferent. El mateix estalvi de temps pot produir conseqüències econòmiques completament diferents.

2.1. Temps alliberat no és el mateix que el cost eliminat

Suposem que cinc persones alliberen dues hores setmanals gràcies a una nova automatització. Podem valorar aquest temps utilitzant el cost laboral i obtenir ràpidament una xifra anual. Aquest càlcul pot ser útil com valor de capacitat alliberada, però seria incorrecte presentar-lo automàticament com a reducció de costos.

La nòmina continuarà sent la mateixa tret que l'empresa pugui capturar aquesta millora mitjançant algun mecanisme concret. Per exemple:

2.2. D'estalvi potencial a estalvi capturable

Aquesta distinció permet introduir una variable que sol faltar als business cases d'IA: la capturabilitat.

En aquest article utilitzarem aquest terme per descriure quina part d'una millora operativa es pot convertir realment en una conseqüència econòmica útil per a l'empresa. No és una taxa universal ni un percentatge estàndard. S'ha d'estimar per a cada cas.

Si una automatització allibera 1.000 hores cada any, no hauríem de valorar automàticament les 1.000 hores al cost laboral corresponent. Primer necessitem entendre'n la distribució.

Alliberar 20 minuts diaris repartits entre 80 persones pot tenir un valor molt diferent d'alliberar 1.000 hores concentrades en un coll d'ampolla operatiu que obliga regularment a contractar suport extern.

2.3. La millora de productivitat tampoc garanteix per si sola ROI

Productivitat i tornada estan relacionats, però tampoc són equivalents. Una persona pot produir el mateix treball en menys temps o produir més a la mateixa jornada. Totes dues coses són valuoses. Tot i això, per incorporar-les al ROI hem d'identificar quina conseqüència econòmica produeix aquesta nova capacitat.

Les dades de l'OCDE sobre ús d'IA generativa a pimes mostren bé per què convé mantenir aquesta separació. A la seva enquesta del 2024 a 5.232 pimes de fins a 249 empleats de set països —Àustria, Canadà, Alemanya, Irlanda, Japó, Corea i Regne Unit; Espanya no estava inclosa—, entre les empreses usuàries d'IA generativa un 32,7 % va declarar una reducció de la càrrega de treball, un 11,8 % un augment i un 54,8 % cap canvi. La mateixa OCDE adverteix que aquests resultats no permeten convertir la variació de càrrega directament en estalvi financer ni establir per si mateixos causalitat.

Font: OECD · Generative AI and the SME Workforce

És una distinció especialment rellevant per a una pime. Reduir càrrega pot permetre treballar millor, reduir saturació o recuperar capacitat de direcció sense que hi hagi una partida pressupostària que desaparegui l'endemà. Aquest valor pot ser real; simplement no l'hem de dir estalvi de costos si no estem eliminant o evitant un cost.

A On la IA sí que estalvia temps (i on no) desenvolupem específicament com mesurar el temps fins a sortida vàlida i quan una reducció de temps sobreviu a preparació, revisió, correcció i retreball. Aquí fem el pas següent: convertir aquesta millora operativa en una variable econòmica defensable.

2.4. Ingressos addicionals: el problema de l'atribució

La mateixa cura és necessària quan el benefici esperat no procedeix de costos sinó d'ingressos. És fàcil construir un business case on una nova capacitat d'IA “genera” més oportunitats, millora conversió o incrementa vendes. El que és difícil és demostrar quina part d'aquesta variació procedeix realment del projecte.

Imaginem que un equip comercial incorpora IA per preparar reunions, prioritzar comptes i personalitzar seguiments. Tres mesos després, la taxa de conversió millora. Aquesta variació pot estar relacionada amb el projecte, però també amb:

• canvis en preus o proposta de valor;
• una cartera d‟oportunitats diferent;
• millores simultànies en procés comercial;
• més experiència de l'equip;
• estacionalitat o condicions de mercat;
• altres accions de màrqueting o vendes.

No necessitem un assaig científic per prendre una decisió empresarial. Sí que necessitem evitar l'extrem contrari: atribuir a la IA tot el bo que passa després d'implantar-la.

2.5. Una forma pràctica de treballar amb atribució

En una pime, no sempre serà possible aïllar perfectament l'efecte causal d'una iniciativa. Podem, però, augmentar molt la qualitat de l'avaluació si establim abans del pilot:

• una baseline temporal suficientment representativa;
• la variable concreta que esperem moure;
• quines altres iniciatives poden modificar-la durant el mateix període;
• un grup, procés o període de comparació quan sigui viable;
• i un rang d‟atribució prudent si no podem aïllar completament l‟efecte.

Per exemple, si una millora de marge representa 40.000 € però hi ha diversos canvis simultanis, pot ser més defensable treballar amb escenaris en què atribuïm al projecte d'IA una part del resultat que adjudicar-li els 40.000 € complets.

2.6. Reducció d'errors i retreball també pot crear valor

No tot el benefici ha de fer hores o ingressos. Un projecte també pot generar retorn reduint errors, repeticions, devolucions, incidències o errors de procés.

En aquests casos la valoració ha de tornar a partir d'una baseline. Si sabem quants errors es produeixen, quant costa resoldre'ls i quina reducció s'observa després del canvi, podem estimar-ne el cost evitat.

També convé incloure l'efecte contrari. Si la nova solució introdueix errors diferents o exigeix més revisió humana per detectar-los, aquesta càrrega s'ha de descomptar. Un projecte no crea cap valor perquè elimineu una hora de treball manual si afegiu una altra hora de validació o correcció.

2.7. Les tres preguntes que tanquen el primer error

Quan aquestes tres respostes són explícites, el numerador del ROI comença a ser defensable. Però encara falta l?altra meitat de l?equació.

I és aquí on apareix el segon error: comparar tot aquest benefici amb el preu de l'eina en lloc de amb el cost real de construir i mantenir la capacitat.

3. Error 2: calcular el retorn sense incorporar el cost total del projecte

El segon error sol fer que el denominador sigui massa petit. Comparem el benefici esperat amb la llicència, el cost d'una API o la factura inicial del proveïdor i cridem aquesta relació ROI.

Però una eina no és el mateix que una capacitat operativa. Perquè una solució d'IA funcioni dins d'una empresa, pot ser necessari preparar dades, integrar-la amb altres sistemes, dissenyar controls, formar usuaris, revisar resultats, mantenir fluxos i actualitzar-la quan canvien processos, models o proveïdors.

Alguns projectes seran molt simples i tindran pocs costos addicionals. Altres no. El criteri no consisteix a inflar artificialment el pressupost, sinó a fer visible quins recursos realment necessita la solució durant l'horitzó que estem avaluant.

3.1. Preu d'eina i cost del projecte són diferents magnituds

Una subscripció de 30 € al mes pot habilitar un cas molt rendible. També pot passar que una llicència aparentment barata requereixi desenes d'hores de configuració, revisió periòdica, accés a dades i manteniment.

Per això, per avaluar el retorn, necessitem treballar amb una visió de cost total de propietat o TCO durant un període definit.

3.2. Set capes de cost que cal revisar

3.3. Els costos inicials i els recurrents s'han de separar

No tots aquests costos es comporten igual. Alguns apareixen principalment al principi: diagnòstic, configuració, integració inicial o formació. Altres continuen durant la vida del sistema: llicències, consum, supervisió, manteniment o actualització.

Aquesta distinció és important perquè el resultat del ROI depèn de l'horitzó temporal. Un projecte amb una inversió inicial important pot oferir un ROI mediocre durant tres mesos i molt bo durant dos anys si els beneficis són recurrents i el cost operatiu continua controlat.

També pot passar el contrari: un pilot barat sembla extraordinàriament rendible, però el cost creix en portar-lo a producció perquè apareixen integracions, controls i manteniment que l'experiment inicial no necessitava.

3.4. La supervisió humana no és un detall gratuït

En determinats casos, revisar la sortida forma part del disseny correcte del sistema. No és necessàriament una ineficiència: pot ser el control que permet fer servir IA en un procés on el cost d'un error és significatiu.

Però econòmicament aquesta supervisió existeix. Si una persona ha de revisar deu minuts cada resultat generat, aquest temps forma part del cost d'operació i s'ha de comparar amb el temps que hauria requerit fer la tasca d'una altra manera.

El marc AI RMF de NIST insisteix precisament a tractar avaluació, monitorització, rols de responsabilitat i revisió com a elements del cicle de vida del sistema, no com una activitat que acaba quan es desplega la tecnologia. En el seu perfil específic per a IA generativa, NIST contempla a més monitorització en producció i intervenció humana davant de determinades desviacions.

Font: NIST · AI Risk Management Framework: Generative Artificial Intelligence Profile

Això no vol dir que totes les pimes necessitin construir una estructura complexa de govern. Significa que el nivell de control ha de ser proporcional al cas dús i que el cost daquest control forma part de la seva economia.

3.5. Dades i integració poden canviar completament el business case

Alguns casos funcionen amb informació que l'usuari ja té disponible i amb prou feines necessiten integració. Altres requereixen accedir a CRM, ERP, documentació, expedients, catàlegs, històrics o sistemes interns.

En aquests projectes, el cost no està únicament a “connectar una API”. Hi pot haver informació duplicada, camps sense mantenir, permisos inconsistents, documents incompatibles o regles de negoci que mai no s'havien formalitzat perquè fins aleshores residien en l'experiència de determinades persones.

La IA no crea aquest problema, però ho pot fer visible. I si necessitem resoldre'l perquè el projecte funcioni, hem de decidir amb criteri quina part del cost realment pertany al cas d'IA i quina part correspon a un deute operatiu o tecnològic que l'empresa necessitava resoldre de totes maneres.

3.6. El cost pot canviar quan augmenta el volum

Un dels motius pels quals el ROI d'un pilot no sobreviu sempre a l'escalat és que diverses variables canvien simultàniament.

Pot créixer:

• el consum de models o infraestructura;
• el nombre dintegracions;
• la quantitat d'excepcions;
• la necessitat de suport;
• el volum de revisió;
• les exigències de seguretat i traçabilitat;
• i el cost de mantenir coneixement, instruccions o dades actualitzades.

Alhora, també poden aparèixer economies d'escala: una integració inicial es pot utilitzar per a milers d'operacions, una base de coneixement pot servir diversos equips i un cost d'implantació es pot diluir a mesura que augmenta el volum.

Per això no és suficient afirmar que “si funciona per a 100 casos funcionarà deu vegades millor per a 1.000”. El model econòmic ha d'identificar quins costos són fixos, quins creixen amb l'ús i quins apareixen només quan elevem el nivell d'exigència del sistema.

3.7. Què no hauria d'entrar automàticament al TCO

L'objectiu tampoc no és convertir cada projecte en un exercici comptable impossible. Hi ha costos que poden existir al voltant duna iniciativa però no ser materials o incrementals.

Per exemple, si una persona dedica quinze minuts a una reunió mensual ja existent a revisar un indicador del projecte, potser quantificar aquesta fracció de salari afegeixi una precisió fictícia.

En canvi, si dues persones han de dedicar sis hores setmanals a validar resultats, aquest cost difícilment es pot ignorar.

3.8. La prova del denominador

Després dels dos primers errors, ja tenim les dues peces bàsiques del càlcul: un benefici que intentem fer atribuïble i capturable i un cost que intenta representar el TCO real.

Encara hi ha una distorsió important: convertir aquestes estimacions inicials en una certesa i escalar abans d'haver comprovat si el model econòmic sobreviu al funcionament real.

4. Error 3: escalar un ROI que encara no està demostrat

El tercer error apareix quan un pilot ofereix bons senyals i convertim aquests senyals en una conclusió massa aviat. L?automatització funciona, els usuaris responen bé, el temps d?una tasca disminueix i el business case comença a semblar evident.

Aquest és precisament el moment en què més convé separar potencial, evidència i decisió. Un pilot pot demostrar que una hipòtesi mereix continuar sense haver demostrat encara quin serà el ROI quan el sistema funcioni amb més usuaris, més volum, més excepcions i controls de producció propis.

L'evidència empresarial recent mostra precisament aquesta distància entre prova i escala. A l'enquesta global de McKinsey publicada el 2025, gairebé dos terços de les organitzacions consultades encara no havien començat a escalar IA a tota l'empresa, i només un 39 % declarava impacte d'IA sobre EBIT a nivell empresarial. Són organitzacions de mides i sectors diversos, no una estimació específica per a pimes, però el senyal és útil: experimentar, escalar i capturar impacte econòmic són etapes diferents.

Font: McKinsey · The state of AI in 2025: Agents, innovation, and transformation

4.1. ROI estimat, observat i demostrat no són el mateix

Una de les millores més senzilles que pot introduir adreça és deixar de presentar totes les xifres de retorn amb el mateix grau de certesa.

No té el mateix significat afirmar que “esperem estalviar 400 hores a l'any” que dir “durant vuit setmanes hem observat una reducció mitjana de 35 minuts per cas sobre 180 operacions reals”.

Totes dues xifres poden ser útils. El que canvia és el tipus d‟evidència que contenen.

Aquesta classificació evita una pràctica habitual: presentar el ROI estimat del business case com si ja fos una conseqüència econòmica obtinguda.

El problema no és fer servir estimacions. Tota decisió d‟inversió conté supòsits sobre el futur. El problema apareix quan deixem de distingir què sabem i què necessitem que passi.

4.2. El pilot té una economia diferent de l'operació real

Un pilot està dissenyat precisament per reduir complexitat. Podeu treballar amb pocs usuaris, una part del procés, un conjunt limitat de documents o un nombre reduït d'excepcions.

Aquesta reducció és útil perquè permet aprendre més de pressa. Però també vol dir que els costos i beneficis observats durant el pilot no s'han d'extrapolar automàticament.

En passar a producció poden aparèixer costos que l'experiment no necessitava:

• nous perfils dusuari amb comportaments menys homogenis;
• més casos excepcionals;
• majors requisits de seguretat, accés i traçabilitat;
• integracions addicionals;
• suport i gestió dincidències;
• necessitat de documentar i mantenir procediments;
• més supervisió o controls de qualitat;
• costos variables lligats al volum dús.

També pot passar el contrari. Una inversió inicial elevada es pot diluir quan el mateix sistema processa més operacions o serveix diversos equips.

Per això la pregunta correcta abans d'escalar no és:

“Va funcionar el pilot?”

sinó:

“"Quina part de l'economia observada durant el pilot continuarà sent certa quan canviem volum, usuaris i condicions d'operació?"”

4.3. L'error d'extrapolar linealment

Suposem que una prova amb 100 operacions permet estalviar 20 hores. Multiplicar automàticament aquest resultat per deu per estimar 200 hores en 1.000 operacions pot ser raonable com a primera hipòtesi, però no com a conclusió.

La relació pot deixar de ser lineal perquè:

• les operacions addicionals són més complexes;
• augmenta la proporció d'excepcions;
• la revisió humana no escala al mateix ritme que la generació;
• la qualitat canvia amb nous tipus dentrada;
• el cost tecnològic depèn del consum;
• o lorganització no aconsegueix capturar tota la capacitat addicional.

També hi podem trobar economies favorables: processos més estandarditzats, reutilització d'infraestructura, aprenentatge d'usuaris o reducció del cost unitari.

L'important és que l'escalat no es basa en una regla de tres invisible.

4.4. El ROI pot empitjorar fins i tot quan la tecnologia millora

Sembla contradictori, però una solució tècnicament millor no garanteix un retorn més gran.

Una versió posterior pot produir respostes més completes i, alhora, utilitzar més recursos, augmentar latència, requerir més infraestructura o provocar que els usuaris deleguin tasques que abans resolien de forma molt ràpida.

També pot passar que, en comprovar que una tecnologia funciona, l'empresa ampliï l'abast: més departaments, més integracions, més dades, més processos.

El projecte genera més capacitat, però l?objecte econòmic ja no és el mateix que el del pilot inicial.

4.5. Què hauria de demostrar un pilot abans d'escalar

No tots els casos necessiten el mateix nivell d‟evidència. Una automatització reversible, barata i de risc baix pot escalar amb menys comprovacions que un sistema integrat en un procés crític.

Com a criteri general, abans d'incrementar materialment la inversió convé haver reduït incertesa sobre cinc qüestions:

4.6. Escalar no hauria de ser l'única sortida possible

Un altre senyal d'un mal business case és que sembla que el pilot té una única conclusió acceptable: escalar.

Una prova ben governada hauria de poder acabar almenys en quatre decisions:

Escalar, ajustar, mantenir limitat o parar són quatre resultats legítims. Hi tornarem al final de l'article, quan puguem combinar evidència, economia, operabilitat i risc sense duplicar aquí aquesta decisió.

Aquesta lògica connecta directament amb la implantació: a Implantar IA a empreses: per què falla i què revisar desenvolupem els problemes de procés, governança, dades i operació que poden impedir que una solució arribi de pilot a producció.

En aquesta pàgina ens quedem deliberadament a la frontera econòmica: quan l'evidència disponible permet comprometre més inversió.

4.7. La regla que tanca el tercer error

5. Com calcular un ROI defensable en un projecte de IA

Després de corregir tots tres errors, podem construir el càlcul. La fórmula matemàtica és senzilla. El més difícil és decidir quines xifres mereixen entrar-hi.

Per a aquest article utilitzarem:

La fórmula no és diferent de la lògica bàsica de qualsevol ROI. El que canvia és el rigor amb què construïm numerador i denominador.

5.1. Pas 1 · Fixar la baseline

No podem demostrar millora si no sabem raonablement què passava abans.

La baseline no ha de ser perfecta. Ha de ser prou representativa per comparar el resultat posterior.

Segons el cas, pot incloure:

• temps mitjà per operació;
• volum processat;
• cost unitari;
• errors o incidències;
• treball;
• taxa de conversió;
• necessitat de suport extern;
• backlog;
• capacitat màxima abans d ampliar estructura.

Si el procés és molt variable, una setmana aïllada pot ser una mala referència. Convé utilitzar un període que capturi variació normal, estacionalitat i excepcions rellevants.

5.2. Pas 2 · Triar la unitat econòmica que volem moure

El projecte necessita una connexió explícita entre la millora operativa i el negoci.

No tots els casos s'haurien de mesurar exclusivament en hores. Depenent del procés, la unitat rellevant pot ser:

• cost per operació;
• cost per expedient;
• marge per transacció;
• cost duna incidència;
• hores de capacitat crítica;
• volum addicional absorbible;
• contractació evitada;
• ingressos incrementals;
• o una combinació de diverses fonts.

Com més directament connectada estigui la mètrica amb una decisió econòmica, menys transformacions necessitarem per arribar al ROI.

5.3. Pas 3 · Mesurar el delta operatiu

Un cop definida la baseline, mesurem la diferència entre el procés anterior i el nou procés complet.

La paraula complet és important. Si una IA genera una sortida en trenta segons, però després requereix vuit minuts de revisió i correcció, no hauríem de comparar trenta segons contra el temps anterior.

Hem de comparar:

Aquesta lògica és la mateixa que desenvolupem amb més profunditat en On la IA sí que estalvia temps (i on no) .

5.4. Pas 4 · Aplicar capturabilitat

El delta operatiu ens indica què ha millorat. Encara cal determinar quina part d'aquesta millora genera valor econòmic.

Aquí convé evitar un únic “percentatge estàndard”. La capturabilitat depèn de com es fa servir la capacitat alliberada.

5.5. Pas 5 · Ajustar l'atribució

Un cop sabem quin valor es podria capturar, hem d'evitar atribuir al projecte una millora que té múltiples causes.

En alguns processos, la connexió serà molt directa. Per exemple, una automatització elimina una operació externa que costava una quantitat coneguda.

En altres, com ara vendes, productivitat directiva o millora de decisions, l'atribució serà necessàriament menys precisa.

Podem treballar llavors amb:

• comparació abans/després;
• períodes equivalents;
• grups comparables;
• cohorts d'usuaris;
• anàlisi de canvis simultanis;
• o rangs prudents d'atribució.

La precisió absoluta no sempre serà possible. La transparència sobre el supòsit sí.

5.6. Pas 6 · Construir el TCO

Ara incorporem el denominador treballat al segon error.

Per a l'horitzó seleccionat, sumem els costos materials:

No totes les partides existiran a tots els projectes. L?objectiu és representar l?economia real del cas, no completar una plantilla per obligació.

5.7. Pas 7 · Triar horitzó i escenaris

Un ROI sense període de referència pot ser enganyós.

Una inversió inicial de 20.000€ pot semblar molt diferent si l'avaluem sobre tres mesos, dotze mesos o tres anys.

L'horitzó hauria de correspondre amb una durada raonable de la decisió: prou llarg per capturar beneficis recurrents, però no tant per fingir que coneixem variables que poden canviar materialment.

A IA aquesta precaució és especialment important perquè models, preus, proveïdors i capacitats tecnològiques poden evolucionar amb rapidesa.

Quan hi ha incertesa rellevant, és preferible construir diversos escenaris que amagar-la dins una única xifra. Més endavant veurem com utilitzar un escenari conservador, un de base i un de favorable, i com localitzar el punt de ruptura que pot canviar la decisió.

5.8. La fórmula final

Quan ja disposem de les variables anteriors, podem fer el càlcul:

Suposem, per exemple, que durant un any estimem 30.000€ de valor econòmic atribuïble i capturable i un TCO de 12.000€.

El benefici net seria:

I el ROI:

Aquesta xifra només és tan bona com les variables que la sostenen. Si els 30.000 € procedeixen d'una estimació excessivament optimista, el càlcul matemàtic continuarà sent correcte i la decisió empresarial serà dolenta.

La fórmula poques vegades és el problema. El problema són els supòsits que hi amaguem.

5.9. Un full de ROI hauria de mostrar alguna cosa més que el percentatge final

Per adreça, un full que només retorna “ROI = 150 %” conté poca informació.

Com a mínim hauria de permetre reconstruir:

• baseline utilitzada;
• millora operativa observada o estimada;
• valor econòmic brut;
• percentatge o criteri de capturabilitat;
• criteri d'atribució;
• costos inicials;
• costos recurrents;
• horitzó;
• volum esperat;
• escenari;
• ROI resultant;
• i les principals hipòtesis pendents.

Així, el business case deixa de ser una xifra aïllada i es converteix en un model que podem revisar conforme obtenim nova evidència.

5.10. La calculadora és útil si entenem què estem introduint

R&R disposa d'una calculadora bàsica de ROI que permet fer una primera estimació de retorn i punt d'equilibri.

És útil com a aproximació inicial, especialment en casos senzills. Però cap calculadora no pot decidir si una hora alliberada és realment capturable, quina part d'una millora hem d'atribuir a la IA o quins costos incrementals són materials.

Aquestes decisions pertanyen a l'anàlisi del cas, no pas a l'aritmètica.

5.11. La prova final del ROI defensable

Fins aquí hem construït el mètode. El següent pas és aplicar-lo a un cas concret per comprovar quant pot canviar el resultat quan passem del ROI aparent al ROI defensable.

6. Del ROI aparent al ROI defensable: un exemple complet

Fins aquí hem separat les peces del càlcul. Vegem ara què passa quan les apliquem al mateix projecte.

L'exemple és completament il·lustratiu. No representa un benchmark de mercat, un cas de client ni una expectativa de tornada. La seva funció és mostrar com pot canviar una decisió quan deixem de fer servir únicament hores teòricament estalviades i preu d'eina.

6.1. El cas de partida

Imaginem-nos una pime que automatitza part d'un procés recurrent de reporting. Abans del projecte, preparar, revisar i tancar aquests informes consumeix unes 90 hores mensuals distribuïdes entre diverses persones.

Després d'implantar la nova solució, el procés complet —incloent-hi preparació, ús d'IA, revisió, excepcions i correcció— requereix 38 hores mensuals.

La millora operativa observada seria:

Per fer visible la lògica econòmica, suposem a més un cost intern de 32 €/hora.

6.2. El càlcul ràpid: un ROI del 824 %

El càlcul més temptador seria:

Suposem que la llicència i el consum tecnològic costen 180 € al mes:

Si utilitzéssim exclusivament aquestes dues xifres:

L'aritmètica és correcta. El model econòmic no.

Hem suposat simultàniament que totes les hores alliberades tenen valor econòmic íntegre per a l'empresa i que l'únic cost necessari per produir aquest benefici és la tecnologia.

Cap d'aquestes dues premisses encara ha estat demostrada.

6.3. Primer ajustament: no totes les hores són capturables

Analitzant com es distribueixen les 52 hores mensuals, l'empresa conclou —per a aquest exemple— que pot aprofitar econòmicament al voltant del 65 %.

La resta correspon a petites fraccions disperses, folgatges difícils de reassignar o temps que millora la comoditat operativa però no modifica de manera material la capacitat o el cost.

Observeu que no estem afirmant que el 65 % sigui una regla recomanable. És un supòsit específic de l'exemple. En un altre projecte podria ser 20 %, 90 % o no tenir sentit expressar-ho com a percentatge.

6.4. Segon ajust: tampoc no atribuïm el 100 % de la millora a la IA

Durant el mateix període, lequip també ha simplificat alguns passos del procés. Per tant, seria difícil defensar que tota la millora procedeix exclusivament de la nova solució.

Per a l'escenari base de l'exemple, assignem un 90 % d'atribució al projecte.

Ja hem passat de 19.968€ d'estalvi aparent a 11.681,28€ de valor que estem disposats a incorporar al business case.

6.5. Tercer ajustament: construir el TCO

Ara incorporem els costos materials del primer any.

La revisió ordinària de cada informe ja està inclosa a les 38 hores mensuals del nou procés. La partida de 2.400 € representa únicament manteniment, seguiment i control addicionals que queden fora del cicle operatiu, per evitar comptabilitzar dues vegades el mateix esforç.

6.6. El ROI defensable canvia radicalment

Ara sí que podem aplicar el model construït al bloc anterior:

Hem passat d'un supòsit 824 % de ROI a un 5,6 % durant el primer any.

La tecnologia no ha empitjorat. L'estalvi operatiu tampoc no ha desaparegut. L'únic que hem fet és canviar la qualitat del model econòmic.

6.7. Això vol dir que el projecte ja no val la pena?

No necessàriament. Aquest seria un altre error.

El 5,6 % correspon al primer any, que suporta diversos costos inicials que no han de repetir-se amb la mateixa intensitat.

En el nostre exemple, disseny, integració inicial i formació representen:

Mentre que els costos recurrents que hem suposat són:

Si el benefici observat es mantingués un segon any i no apareguessin nous costos materials, l'economia seria diferent.

Això no vol dir que hàgim de projectar indefinidament el mateix benefici. Significa que ROI del primer any, economia recurrent i retorn acumulat són perspectives diferents.

6.8. L'exemple també mostra perquè una xifra aïllada diu poc

Imaginem dues presentacions davant d'un comitè de direcció.

La segona xifra és molt menys espectacular. També és molt més útil per decidir.

6.9. Què aprendríem del pilot

L'exemple tampoc no s'hauria de tancar amb un simple “sí” o “no”. Ara sabem exactament quines variables governen el resultat.

• La solució allibera 52 hores mensuals.
• La decisió depèn molt de quant temps aconsegueix capturar realment l'organització.
• Els costos inicials pesen de manera important durant el primer any.
• Si el benefici persisteix, l'economia recurrent pot millorar materialment.
• Abans d'escalar, val la pena validar si es mantenen capturabilitat, volum i cost de supervisió.

Hem convertit així el càlcul de ROI en una cosa més útil: un mapa de les variables que podrien canviar la decisió.

7. ROI no n'hi ha prou: payback, escenaris i sensibilitat

El ROI respon a una pregunta important: quant valor obtenim en relació amb allò que invertim.

Però direcció sol necessitar almenys dues respostes més:

• quant trigarem a recuperar la inversió inicial?
• quines variables poden fer que el projecte deixi de compensar?

Aquí entren el payback i el anàlisi de sensibilitat.

7.1. ROI i payback mesuren coses diferents

Dos projectes poden tenir un ROI semblant i exigir temps de recuperació completament diferents.

Per a una pime, aquesta diferència pot ser decisiva. Un projecte molt rendible a tres anys pot no ser prioritari si immobilitza recursos durant massa temps o si hi ha molta incertesa tecnològica.

El payback simple respon a:

En el nostre exemple, hem de separar primer inversió inicial i cost recurrent.

Per tant:

Aquesta informació complementa el ROI del 5,6 % del primer any.

El projecte amb prou feines genera benefici net acumulat durant aquests primers dotze mesos, però recupera aproximadament la inversió inicial a prop del final del període.

7.2. El payback tampoc no hauria d'utilitzar-se sol

Recuperar ràpid una inversió no vol dir necessàriament que sigui la millor inversió disponible.

Un projecte pot tenir un payback molt curt i després generar poc benefici. Un altre pot necessitar més temps per recuperar el desemborsament inicial i produir molt més valor acumulat.

A més, el payback simple té limitacions:

• no descriu què passa després de recuperar la inversió;
• no incorpora per si mateix el valor temporal dels diners;
• pot amagar diferències importants de risc;
• i depèn que el benefici periòdic sigui prou estable.

Per a inversions grans, horitzons llargs o fluxos de caixa complexos, poden ser necessàries mètriques financeres addicionals. Per a molts projectes operatius d'IA en una pime, però, ROI + payback + sensibilitat proporciona una lectura directiva força més útil que un únic percentatge.

7.3. La sensibilitat mostra on és realment el risc

Tornem a l'exemple. Una de les variables que condiciona més el resultat és la capturabilitat.

Mantenim constants:

• les 624 hores anuals alliberades;
• el cost de 32 €/hora;
• una atribució del 90 %;
• i el TCO anual de 11.060€.

Canviem únicament quin percentatge del valor pot capturar lempresa.

El projecte tecnològic és exactament el mateix. El que canvia és la capacitat de lorganització per convertir la millora en valor útil.

A l'escenari conservador, el projecte perd diners durant el primer any. Al favorable, el ROI arriba aproximadament al 30 % i la inversió inicial es recupera en uns vuit mesos.

Aquesta diferència és molt més informativa que no pas afegir un decimal al càlcul de l'escenari base.

7.4. No totes les variables mereixen tres escenaris

Podem construir fulles amb desenes de supòsits i acabar fent el model menys útil.

El criteri hauria de ser concentrar-nos en variables que siguin:

• prou incertes;
• econòmicament materials;
• i capaços de canviar la decisió dinversió.

Depenent del projecte, podrien ser:

7.5. El punt dequilibri és una altra pregunta útil

A més de calcular un escenari conservador i favorable, podem invertir-ne la lògica:

Què hauria de passar perquè el projecte deixés de perdre diners?

Aquesta pregunta converteix el business case en una condició operativa.

Podem cercar, per exemple:

• quantes operacions mensuals necessitem processar;
• quantes hores s'han d'alliberar;
• quina capturabilitat mínima necessitem assolir;
• quant pot créixer el cost recurrent;
• o quina reducció derrors fa rendible el projecte.

D'aquesta manera, en comptes de dir “esperem un ROI del 20 %”, podem formular una condició molt més governable:

Aquesta formulació ens diu què cal observar després del desplegament.

7.6. El millor escenari no hauria de ser lúnic que justifica el projecte

Un business case és fràgil quan només és atractiu si pràcticament totes les hipòtesis surten bé.

Si necessitem simultàniament:

• adopció gairebé total;
• estalvi màxim;
• costos sense desviacions;
• alta atribució;
• i cap degradació en escalar,

probablement no estem davant d'una inversió robusta, encara que l'escenari favorable faci un ROI espectacular.

Per contra, un projecte l'escenari conservador del qual continua sent raonable pot merèixer prioritat encara que el seu màxim retorn potencial sigui menor.

7.7. ROI, payback i sensibilitat responen a tres preguntes diferents

8. Què hem observat a R&R en mesurar valor amb IA

Els marcs anteriors serveixen per ordenar el càlcul. Però treballar amb IA en processos reals deixa a més a més una sèrie d'aprenentatges que no apareixen quan analitzem únicament eines, llicències o demostracions controlades.

Les observacions d'aquest bloc provenen de experiència interna de R&R treballant amb automatització, reporting, anàlisi, desenvolupament de ferramentes i sistemes recolzats per IA. No són un estudi estadístic, no representen una mitjana de mercat i no s'haurien d'interpretar com una promesa de resultats per a altres empreses.

8.1. Estalviar temps i estalviar diners són dos resultats diferents

En determinades rutines de reporting hem observat internament reduccions de temps de fins al 45 %. És una millora operativa material, però no equival per si sola a una reducció de costos: l'efecte econòmic depèn de si aquesta capacitat permet absorbir més feina, evitar suport extern, reduir acumulació o tornar temps útil a direcció.

8.2. Els casos petits poden tenir una economia excel·lent

Hi ha una tendència natural a associar retorn important amb projectes grans. A IA no ha de ser així.

Un procés molt fitat pot oferir una combinació especialment favorable:

• freqüència elevada;
• entrades ben definides;
• resultat fàcil de verificar;
• integració senzilla;
• baix cost derror;
• i poc manteniment.

Encara que el benefici absolut no sigui extraordinari, pot presentar un TCO baix, un payback curt i una elevada probabilitat de mantenir el resultat.

Al contrari, un projecte ambiciós que promet transformar un procés complet pot acumular prou dependències, excepcions i costos de coordinació per oferir pitjor economia.

La mida estratègica d'una idea i la qualitat econòmica del primer cas d'ús no són la mateixa cosa.

8.3. El ROI d'una tasca no és el ROI d'un sistema

Aquest aprenentatge és especialment visible quan passem de fer servir IA com a assistència individual a integrar-la dins una eina o procés empresarial.

Una funció determinada pot ser extraordinàriament ràpida: classificar informació, resumir documents, proposar una resposta o generar una primera versió.

Però el sistema complet pot necessitar a més:

• resoldre identitat i permisos;
• conservar traçabilitat;
• gestionar estats;
• controlar versions;
• validar resultats;
• integrar dades;
• resoldre errors;
• i mantenir compatibilitat quan canvien proveïdors o processos.

En desenvolupament d'eines pròpies ho hem comprovat de manera recurrent: la IA pot accelerar molt una peça sense reduir en la mateixa proporció el temps necessari per aconseguir un sistema complet, estable i governable.

No contradiu el valor de la IA. Explica perquè mesurar només la velocitat d'una microtasca pot sobreestimar el ROI del producte o procés complet.

8.4. La validació pot decidir la rendibilitat

Dues tasques aparentment similars poden tenir economies molt diferents segons quant costi comprovar-ne la sortida. Si un professional valida ràpidament, l'estalvi pot sobreviure; si heu de tornar a fonts, reconstruir raonament o refer bona part de la feina, l'avantatge pot desaparèixer.

Això connecta directament amb el concepte de temps fins a sortida vàlida desenvolupat a On la IA sí que estalvia temps (i on no) .

Des del punt de vista econòmic, la conseqüència és senzilla: el cost de validació forma part de la unitat de producció.

8.5. La capacitat alliberada pot tenir valor encara que no redueixi plantilla

En una pime bona part del valor no apareix en forma d'una persona menys en nòmina.

Pot aparèixer com:

L'error seria triar una xifra monetària arbitrària per a qualsevol d'aquests beneficis només perquè ens cal completar un full de ROI.

Quan la monetització no és prou defensable, és millor mantenir part del resultat com mètrica operativa complementària d'inventar una precisió financera. Aquesta distinció entre eina i capacitat empresarial la desenvolupem també a Com guanyar capacitat empresarial amb IA sense augmentar estructura, cost ni dependència .

8.6. Una bona arquitectura pot millorar leconomia amb el temps

No tots els costos inicials s'haurien d'interpretar com a penalització.

Una integració, una estructura de dades, un sistema de permisos o una capacitat de monitorització es poden utilitzar després en altres casos.

Quan això passa, l'empresa deixa de finançar únicament una automatització i comença a construir capacitat reutilitzable.

Però cal mantenir el mateix rigor que hem utilitzat durant tot l'article: no hem d'atribuir al primer cas tots els beneficis hipotètics que potser generi aquesta infraestructura en el futur.

Podem reconèixer-ne el valor estratègic i, alhora, calcular separadament el ROI del projecte concret.

8.7. El ROI pot canviar després que el projecte sigui rendible

Un projecte no queda econòmicament “certificat per sempre” perquè hagi funcionat durant el primer any.

Poden canviar:

• preus de models i proveïdors;
• volum dús;
• qualitat de la sortida;
• requisits regulatoris;
• costos de supervisió;
• estructura del procés;
• o fins i tot l'alternativa contra la qual estem comparant.

Una solució que abans evitava molta feina pot perdre part del seu avantatge si el procés convencional també millora.

I una solució inicialment marginal es pot tornar molt atractiva si disminueixen costos, millora el model o augmenta prou el volum.

8.8. La conclusió principal no és tecnològica

Tots aquests aprenentatges apunten cap a la mateixa direcció: la tecnologia influeix al ROI, però l'organització determina quant d'aquest potencial aconsegueix convertir-se en valor.

Definició de tasca, qualitat de dades, capacitat dintegració, criteris de validació, disciplina per mesurar, adopció i capacitat per reassignar recursos poden ser tan importants com lelecció del model.

9. Quan escalar, ajustar o parar

L'objectiu final de mesurar la ROI no és produir un percentatge. És millorar una decisió.

Un cop coneixem benefici, TCO, payback, sensibilitat i grau d'evidència, la pregunta deixa de ser si “la IA funciona” i passa a ser molt més concreta:

Mereix aquest projecte el següent euro, la següent hora i el següent nivell de complexitat?

9.1. Quatre dimensions abans de decidir

No utilitzaria un llindar universal del tipus “tot projecte amb ROI superior al 20 % s'ha d'escalar”.

La decisió hauria de combinar almenys quatre dimensions.

9.2. Escalar

Escalar té sentit quan el projecte ha reduït les incerteses materials i l'economia es manté raonablement atractiva fins i tot sense fer servir l'escenari més optimista.

Escalar tampoc significa desplegar immediatament a tota l'empresa. Podeu consistir a ampliar un departament, un conjunt de processos o un volum controlat.

9.3. Ajustar

Alguns pilots confirmen que hi ha valor, però mostren que la solució actual no és encara la millor manera de capturar-lo.

Pot ser necessari modificar:

• abast;
• model o proveïdor;
• instruccions;
• procés previ;
• integració;
• controls;
• experiència d'usuari;
• o fins i tot la mètrica utilitzada per avaluar el cas.

Ajustar és una bona decisió quan la hipòtesi econòmica continua sent atractiva, però hem localitzat una restricció concreta que impedeix capturar-la.

9.4. Mantenir limitat

No tot cas rendible s'ha de convertir en una plataforma empresarial.

Algunes solucions funcionen precisament perquè:

• tenen pocs usuaris;
• treballen amb inputs homogenis;
• el procés està ben delimitat;
• les excepcions són escasses;
• i la validació roman barata.

Estendre-les a altres contextos pot destruir una part d'aquesta economia.

9.5. Aturar

Aturar un projecte no vol dir necessàriament que la tecnologia hagi fallat.

Podeu funcionar perfectament i seguir sense merèixer més recursos.

Això darrer és important. El ROI no s'hauria d'avaluar només contra zero.

Una empresa té recursos limitats. Un projecte amb retorn positiu pot continuar sent una mala prioritat si hi ha una altra manera d'utilitzar capital, atenció directiva o capacitat tècnica amb millor resultat esperat.

9.6. La comparació correcta inclou el cost d'oportunitat

Dos projectes poden presentar ROI positiu i no merèixer la mateixa prioritat.

Adreça hauria de considerar:

9.7. Una matriu simple per prendre la decisió

Sense convertir lanàlisi en un scoring mecànic, podem resumir la lectura en quatre situacions.

9.8. L'objectiu no és aprovar projectes d'IA: assignar millor els recursos

Aquest canvi de perspectiva és probablement el més important de tot larticle.

Si una empresa comença preguntant “Com aconseguim que aquest projecte de IA tingui ROI?”, hi ha el risc que el càlcul acabi convertit en una justificació.

La pregunta més útil és:

Algunes vegades la resposta serà IA. Altres vegades serà simplificar un procés, millorar dades, integrar dos sistemes, canviar una responsabilitat o eliminar feina que mai no s'hauria d'haver realitzat.

A IA pràctica amb ROI: quan té sentit i quan no desenvolupem precisament com passar del problema al cas dús, pilotar-lo i decidir si mereix escalar.

El paper daquesta pàgina és més concret: evitar que una xifra de ROI mal construïda converteixi una bona tecnologia en una mala decisió empresarial.

10. Preguntes freqüents sobre ROI en projectes de IA