Com mesurar un agent d'IA: les mètriques que importen

Pregunti quina és la taxa d'automatització d'un agent i normalment obtindrà una xifra contundent. Pregunti què ha passat amb el cost total del procés, la taxa d'error o el temps de cicle i la resposta serà molt menys contundent i, sovint, no estarà disponible, perquè ningú no va mesurar el procés abans que arribés l'agent.

Aquest és el problema central de mesura en els desplegaments d'agents. Les mètriques fàcils de produir són les que l'agent genera sobre si mateix: quants elements ha processat, quina proporció ha gestionat sense intervenció humana, la seva confiança mitjana. Són entrades, no resultats. Un agent pot reportar una taxa d'automatització alta mentre el cost total del procés es manté igual, perquè la feina s'ha desplaçat a una cua d'escalat que ningú no compta.

Les mètriques que compten són les que parlen del procés, no de l'agent. Són més difícils de recollir, requereixen una línia base capturada abans del desplegament i són l'única base sobre la qual algú pot dir honestament si la cosa va funcionar.

Per què això importa

La mesura determina tres resultats que arriben tots més tard que el desplegament.

Si l'agent sobreviu al seu primer mes dolent. Tots els agents en tenen un. Si l'única evidència disponible és una taxa d'automatització, una única fallada visible domina la conversa. Si pot demostrar una reducció del temps de cicle, de la taxa d'error i del cost per transacció al llarg de dos trimestres, un incident queda contextualitzat en lloc de ser decisiu.

Si millora. La millora exigeix saber quins casos fallen i per què. Un desplegament que només mesura la taxa d'automatització agregada no té cap mecanisme de millora, perquè la xifra no es descompon en res sobre el qual es pugui actuar.

Si es finança el següent. Els programes d'agents solen ser seqüencials: un procés, després un altre. El segon es finança amb l'evidència del primer, i «hem automatitzat el 85% del quadrament» és un argument més feble davant d'un comitè financer que un canvi demostrat en el cost per transacció i el temps de cicle.

Hi ha un risc invers que val la pena anomenar. Una mala mesura també pot fer que un desplegament genuïnament pobre sembli reeixit durant prou temps per prorrogar-lo, cosa que és més cara que una fallada honesta i primerenca.

D'un cop d'ull: les capes de mètriques

La capa que més sovint falta del tot és la salut del traspàs, que és precisament on s'amaga un desplegament que falla. Un agent amb una taxa d'automatització alta i una cua d'escalat creixent i envellida no ha reduït feina: ha concentrat la feina difícil en un sol lloc i ha deixat de comptar-la.

Què funciona i sobre què cal ser honest

Què funciona:

Una línia base capturada abans de construir res. Temps de cicle, cost per transacció, taxa d'error i volum durant com a mínim un període complet, idealment dos. És l'activitat més econòmica i més sovint omesa de tot el desplegament i, sense ella, cada afirmació posterior és una asserció.

El cost total del procés, incloent-hi els escalats. El denominador honest és tot el temps humà dedicat al procés: supervisió de l'agent, resolució d'escalats, monitoratge i l'ajust periòdic. Els desplegaments que només compten la part automatitzada reporten estalvis que no apareixen en el pressupost de ningú.

Revisió per mostreig de les accions automatitzades, de manera permanent. Els escalats es revisen perquè exigeixen atenció. Les accions automatitzades no, i és exactament per això que els errors allà es detecten tard. Una mostra petita i permanent és l'única manera de detectar una degradació silenciosa.

Taxa d'error desglossada per conseqüència, no només per recompte. Deu elements de poc valor mal classificats i un pagament a proveïdor mal redirigit no són comparables. Ponderi per impacte o la mètrica l'enganyarà.

La precisió de l'escalat com a mètrica de primer ordre. La proporció d'escalats que van resultar ser problemes genuïns. Una precisió baixa vol dir que les persones estan revisant no-problemes, cosa que destrueix l'atenció sobre la cua i és invisible en qualsevol altra mètrica.

Sobre què cal ser honest:

Sense línia base no pot provar el valor, i probablement no l'obtindrà retrospectivament. Reconstruir de memòria el temps de cicle previ al desplegament produeix una xifra modelada per qui vol que el desplegament hagi tingut èxit. Accepti que alguns beneficis seran indemostrables i sigui franc sobre quins.

Els resultats de negoci són multicausals. Els dies fins al cobrament han millorat, però també va canviar les condicions, va afegir un segment de clients i va perdre un pagador lent. Reclamar tota la millora per a l'agent és la manera més ràpida de perdre credibilitat davant d'un CFO. Atribueixi de manera conservadora i digui què més va canviar.

Part del benefici és real i no mesurable. Consistència, auditabilitat, resistència a l'absència de personal i l'eliminació de feina que la gent trobava desmoralitzadora. Aquestes coses compten i no apareixen en una mètrica de cost. Enunciï-les com a qualitatives en lloc de convertir-les en xifres inventades.

La taxa d'automatització es pot manipular sense que ningú ho pretengui. Afluixar els llindars la puja. Estrènyer l'abast als casos fàcils la puja. Cap de les dues coses millora el procés. Si es reporta, reporti-la al costat de la taxa d'error i de la precisió de l'escalat, perquè no es pugui moure sola.

La mesura té un cost. Instrumentar tot el que hi ha en aquesta llista és desproporcionat per a un desplegament petit. Triï les capes que es corresponguin amb el que hi ha en joc: qualitat de l'agent, salut del traspàs i un resultat de procés és un mínim defensable.

Marc de decisió: construir la mesura

Recorri'l en ordre. Aturi's en la primera coincidència.

1. Té una línia base prèvia al desplegament?
Si l'agent encara no està en producció, capturi'n una ara: un o dos períodes complets de temps de cicle, cost, volum i taxa d'error. Si ja està en producció, reconstrueixi el que pugui, etiqueti-ho com a estimació i comenci a mesurar correctament a partir d'avui en lloc de discutir sobre el passat.

2. Mesura alguna cosa més enllà de l'activitat de l'agent?
Si la taxa d'automatització i el volum és tot el que té, afegeixi la taxa d'error en accions automatitzades i la profunditat de la cua d'escalat. Aquestes dues converteixen un dashboard que no pot fallar en un que sí que pot.

3. Està instrumentada la salut del traspàs?
Si no, aquesta és la prioritat: profunditat de la cua, antiguitat, temps fins a la resolució, proporció dins de l'objectiu. Aquí és on un desplegament que falla es fa visible primer.

4. Està mostrejant les accions automatitzades per comprovar-ne la correcció?
Si no, comenci una mostra petita i permanent. Revisar només els escalats vol dir que està comprovant els casos sobre els quals l'agent ja sabia que no estava segur.

5. Pot indicar el cost total del procés incloent-hi tot el temps humà?
Si no, construeixi aquesta xifra. És la que demanarà un comitè financer i la que determina si es finança el següent desplegament.

6. Té una revisió mensual que categoritzi les resolucions dels escalats?
Si no, programi-la amb un responsable amb nom i cognoms. Sense ella, el rendiment de l'agent queda estàtic des de l'arrencada.

7. Tot l'anterior, les xifres semblen bones, però ningú no se les creu?
El problema és de transparència, no de mesura. Publiqui el mètode, les reserves i el que no pot atribuir. La confiança en una xifra ve més de les limitacions declarades que de la seva mida.

Cost i esforç indicatius

Pressuposa un agent en un procés amb dades disponibles a l'ERP o a la plataforma d'integració. Sol·liciti un pressupost per a una estimació delimitada.

Preguntes freqüents

Quina única mètrica hauríem de reportar al consell?
Cost per transacció i temps de cicle, amb la taxa d'error al costat perquè no es pugui mostrar eficiència sense qualitat. Si només una, el temps de cicle: és més difícil de manipular i correlaciona amb la major part dels beneficis que de debò preocupen la gent.

Quant temps passa fins que les xifres signifiquen alguna cosa?
La qualitat de l'agent i la salut del traspàs esdevenen significatives en quatre a sis setmanes. Els resultats de procés necessiten un o dos trimestres. Els resultats de negoci (dies fins al cobrament, dies fins al tancament) normalment dos o tres trimestres, perquè són lents i necessiten un període net després que el desplegament s'assenti.

Hauríem de mesurar contra un objectiu o contra la línia base?
Contra la línia base, principalment. Els objectius fixats abans del desplegament són conjectures, i no assolir un objectiu arbitrari en un desplegament que va millorar materialment el procés genera la conversa equivocada.

I si l'agent funciona però les xifres no s'han mogut?
Les causes habituals són que la part automatitzada no era la restricció, que la feina s'ha desplaçat a una cua d'escalat que no es compta, o que domina un problema aigües amunt. Els tres són troballes que val la pena tenir, i els tres són invisibles si només es mesura la taxa d'automatització.

Necessitem una eina d'analítica a part?
Normalment no a escala mid-market. La major part d'aquestes mètriques es poden derivar de l'ERP i dels registres de la mateixa plataforma d'integració. La mancança sol ser el model de cost del procés i la revisió per mostreig, i cap de les dues és un problema d'eines.

Amb quina rapidesa podem connectar les dades subjacents prou bé per mesurar això?
Més ràpid del que la majoria d'equips suposa per a la part de connexió — un partner certificat com Stacksync pot tenir en setmanes la sincronització en temps real que alimenta les mètriques d'un agent. La part més lenta és acordar quines de les mètriques d'amunt importen realment per al teu agent abans de començar a mesurar, per no acabar produint números nets sobre les coses equivocades.

Tancament — Passos següents

La mètrica d'agent que es reporta és gairebé sempre la que l'agent produeix sobre si mateix, i és la que menys relació té amb si el desplegament valia la pena. Les mesures útils es troben a nivell de procés, necessiten una línia base i inclouen la feina que l'agent va tornar.

Si ja té un agent en marxa i vol saber en quin punt està: extregui la profunditat de la cua d'escalat i el seu perfil d'antiguitat, i després extregui el total d'hores humanes dedicades al procés aquest mes. Aquestes dues xifres, contrastades amb el que sàpiga de l'estat previ al desplegament, li diran més que qualsevol taxa d'automatització.

Sobre l'autor

Bruno Galo és el fundador d'Atypical Tech, una consultora de NetSuite que atén clients mid-market a tota la península Ibèrica. Està especialitzat a connectar sistemes CRM i ERP per aconseguir fluxos d'order-to-cash sense friccions, construint pipelines automatitzats de gestió de comandes que eliminen l'entrada manual de dades entre els equips comercials i financers. Com a partner oficial d'implementació de Stacksync, Bruno dissenya i desplega agents d'IA sobre plataformes d'integració per gestionar l'encaminament d'excepcions, el processament de documents i la conciliació, convertint fluxos de comandes fragmentats en sistemes fiables que es monitoren a si mateixos.

LinkedIn: https://www.linkedin.com/in/brunogd

Fonts

Els URL són a nivell d'editor i s'han de verificar abans de la publicació.

• APQC, Open Standards Benchmarking — mesures de cost i temps de cicle de processos — https://www.apqc.org
• NIST, AI Risk Management Framework — mesura i monitoratge de sistemes d'IA — https://www.nist.gov/itl/ai-risk-management-framework
• Oracle NetSuite, documentació de reporting i saved searches — https://docs.oracle.com/en/cloud/saas/netsuite/
• COSO, Internal Control — Integrated Framework — activitats de monitoratge — https://www.coso.org
• Experiència de projectes d'Atypical Tech, desplegaments d'agents al mid-market de la península Ibèrica
• Stacksync, blog de la plataforma d'integració i sincronització en temps real — https://www.stacksync.com/blog