La reunió on tot funciona
Imagina una demostració interna.
Entra una petició comercial ben escrita. La persona explica a què es dedica l’empresa, quin procés voldria millorar i quan necessita una primera resposta. El sistema llegeix el missatge, en prepara un resum, el classifica com una possible oportunitat, crea el registre corresponent i avisa l’equip amb el context necessari.
Tot passa en menys d’un minut.
La classificació és correcta. El registre queda ben creat. L’avís arriba a la persona adequada. La demo funciona i és fàcil veure-hi valor.
El problema no és la demo. El problema és confondre el que acaba de demostrar.
Durant aquella prova, l’entrada estava completa. No hi havia cap duplicat. L’eina de destí responia. Les credencials eren vàlides. La petició encaixava amb una categoria clara i ningú havia canviat els criteris des que es va preparar el flux.
L’endemà poden arribar casos diferents.
Un missatge que només diu “truqueu-me”. Una entrada repetida perquè la persona ha premut dues vegades el botó. Una consulta que barreja una oportunitat comercial i una incidència. Un adjunt que el sistema no pot llegir. Una eina externa que deixa de respondre durant uns minuts. O una petició que sembla prioritària, però no conté prou informació per decidir-ho.
Aquests casos no són una anomalia del procés. Són el procés quan entra en contacte amb el dia a dia.
Una demo pot demostrar que una idea és possible. Un sistema real ha de saber què fer quan la realitat deixa de seguir el guió.
Si el procés encara no té criteris, dades mínimes o responsables clars, primer convé revisar quan no automatitzar encara. Aquí partim d’un punt posterior: ja existeix una demo o un pilot, hi ha valor potencial i toca decidir què falta abans de posar-lo en operació o escalar-lo.
Una demo prova una possibilitat, no una operació
Una demostració té una funció important. Permet validar que dues eines es poden connectar, que una IA pot preparar una primera lectura o que una acció es pot executar sense construir tot el sistema.
És una manera ràpida d’aprendre.
Però una operació real fa preguntes diferents. No pregunta només si el flux pot avançar quan tot va bé. Pregunta si pot aturar-se quan falta informació, evitar una acció duplicada, recuperar-se d’un error, deixar constància del que ha passat i avisar algú quan necessita ajuda.
| Una demo pot demostrar | Encara no demostra |
|---|---|
| Que dues eines es poden connectar | Que el flux aguantarà canvis, errors i més volum |
| Que el cas clar funciona | Que sabrà aturar-se davant de dades absents, duplicades o ambigües |
| Que la sortida és convincent | Que el criteri serà coherent, revisable i adequat al negoci |
| Que una acció es pot executar | Que no es duplicarà i que es podrà corregir o recuperar |
| Que hi ha valor potencial | Que l’equip l’adoptarà i que algú se’n farà responsable |
Això no treu valor a la demo. Simplement la situa al lloc correcte.
La demo respon “ho podem fer?”. Abans d’escalar, encara falta respondre “com funcionarà quan no surti com esperàvem?”.
Cinc preguntes abans de posar-la en el dia a dia
No hi ha una frontera exacta que converteixi una prova en un sistema. Però sí que hi ha cinc preguntes que ajuden a veure si la base és prou sòlida.
No són preguntes només tècniques. Parlen d’ús, responsabilitat, excepcions, control i manteniment. És aquí on moltes automatitzacions que impressionen durant una presentació comencen a mostrar les seves mancances.
1. Aporta valor i l’equip la fa servir?
La primera pregunta no és si el flux s’executa. És si canvia alguna cosa útil en la feina.
Potser redueix el temps fins a la primera resposta. Potser evita copiar dades. Potser ajuda a detectar informació que falta o deixa cada cas amb un estat més clar. També pot passar que el resultat sigui correcte, però l’equip continuï treballant pel correu, el xat o un full paral·lel perquè el nou sistema no encaixa amb la rutina real.
Escalar una automatització que ningú incorpora només multiplica una capa que l’equip esquivarà.
No cal exigir deu indicadors ni un quadre de comandament enorme. Però sí que convé tenir dues o tres evidències: la fricció que volíem reduir ha baixat, el resultat s’utilitza i les persones que hi treballen confien prou en el registre.
Aquesta part es desenvolupa amb més detall a com saber si una automatització realment funciona. Aquí és la condició d’entrada: abans de reforçar l’operació, cal comprovar que hi ha una operació que val la pena reforçar.
2. Qui n’és responsable quan alguna cosa falla?
Un flux pot executar-se sense supervisió directa. Un procés no pot quedar sense propietari.
Algú ha de saber que existeix, entendre quin problema resol i tenir autoritat per decidir què passa quan apareix una excepció. Aquesta persona no ha de reparar necessàriament una integració, però sí que ha de poder respondre preguntes bàsiques:
- Qui rep una alerta si una entrada no s’ha pogut processar?
- Qui decideix si cal tornar-ho a provar, corregir una dada o contactar amb la persona?
- Qui pot aturar el flux si comença a actuar malament?
- Qui revisa si els criteris encara tenen sentit al cap d’un temps?
El manteniment tècnic pot estar en mans d’un equip intern o extern. Però el criteri de negoci necessita un responsable dins de l’organització.
Sense aquesta figura, el sistema pot continuar funcionant tècnicament mentre el procés canvia al seu voltant. Pot assignar estats que ja no s’utilitzen, avisar una persona que ha canviat de funció o aplicar una prioritat que l’equip ja no considera correcta.
Una automatització sense propietari no queda quieta. Es va separant, a poc a poc, de la manera real de treballar.
3. Què fa amb dades dolentes, duplicats i excepcions?
La fiabilitat no consisteix a no fallar mai. Consisteix a fallar sense perdre el control.
Si falta un correu electrònic, el sistema no hauria d’inventar-lo ni crear un registre que sembli complet. Si una entrada està duplicada, no hauria de generar dos seguiments. Si una classificació és ambigua, no hauria d’escollir una opció només perquè necessita continuar. Si l’eina de destí no respon, no hauria de marcar el cas com a resolt.
En aquests punts, un sistema pot demanar la dada que falta, deixar el cas pendent, enviar-lo a revisió, tornar-ho a provar més endavant, avisar que l’acció no s’ha completat o aturar-se abans de provocar un efecte extern.
Aturar-se també és una resposta.
De fet, sovint és la resposta que diferencia una automatització controlada d’un flux que només sap avançar. Quan cada error obliga una persona a investigar què ha passat, reconstruir el cas i corregir registres, el sistema encara no està assumint l’operació. Només n’està executant la part fàcil.
El cas més perillós no sempre és un error visible. Pot ser una execució aparentment correcta que ha fet una acció equivocada: ha duplicat un contacte, ha actualitzat el registre incorrecte o ha enviat una resposta quan faltava context.
Un error que es veu i es pot recuperar acostuma a ser menys costós que un èxit fals que ningú detecta.
4. Podem veure, entendre i corregir què ha passat?
Quan una persona pren una decisió en un procés, normalment podem preguntar-li què ha vist i per què ha actuat d’aquella manera. Amb una automatització, aquesta traça s’ha de dissenyar.
No n’hi ha prou que el sistema guardi informació tècnica que només entén qui el va construir. L’equip hauria de poder veure quina entrada va rebre, quina classificació o proposta va generar, quina acció va intentar executar, si es va completar, quin error va aparèixer i si una persona va modificar el resultat.
Això és especialment important quan hi ha IA. Si una petició queda descartada, prioritzada o derivada, convé poder revisar quina informació hi havia disponible i quin criteri s’havia definit. No perquè el sistema hagi de justificar cada paraula, sinó perquè una decisió operativa ha de ser revisable.
La traçabilitat també accelera les correccions. Si una acció s’ha repetit, cal poder veure si l’entrada va arribar dues vegades o si el sistema va reintentar malament. Si un registre no s’ha creat, cal saber si faltava una dada o si l’eina externa no estava disponible.
Sense aquesta visibilitat, cada incidència comença des de zero. I quan cada error necessita una investigació artesanal, escalar significa escalar també el temps dedicat a entendre què ha passat.
5. Es pot mantenir sense convertir-se en una dependència fràgil?
Un sistema no queda acabat el dia que es publica.
Canvien els formularis, els estats del CRM, les persones responsables, els permisos, les fonts d’informació i els criteris comercials. També pot canviar el volum: un flux pensat per a poques entrades pot començar a rebre’n moltes més quan s’obre a un altre canal o equip.
Per això, abans d’escalar, miraria quatre coses molt concretes.
La primera és el cost. No només el cost inicial de construir, sinó el cost de cada execució, de les eines connectades i de la revisió humana que continua sent necessària. Una automatització pot aportar valor i, alhora, necessitar límits de consum o alertes perquè el creixement no converteixi una factura petita en una sorpresa.
La segona són els permisos. Cada connexió hauria de tenir només l’accés que necessita. Si un flux només crea tasques, no cal que pugui esborrar registres. Si treballa amb informació sensible, cal definir qui la pot consultar i què queda registrat.
La tercera és la manera de fer canvis. Abans de modificar un criteri o una acció, convé provar-lo amb casos coneguts, veure què faria i poder tornar a la versió anterior si el resultat no és l’esperat. Simular abans d’executar és especialment útil quan el flux envia, publica, modifica o elimina informació.
La quarta és la documentació mínima. No cal un manual enorme, però sí deixar clar què activa el flux, quines dades utilitza, quines accions pot fer, qui n’és responsable, com s’atura i què cal revisar quan hi ha una alerta.
Si només una persona sap com funciona tot el conjunt, encara no tens una capacitat operativa. Tens una dependència.
Un mateix cas, de demo a sistema
Entre la demo i la versió operativa hi ha un pas que no convé saltar: el pilot supervisat. El mateix flux pot començar a treballar amb entrades reals, però sense executar encara totes les accions pel seu compte. Resumeix la petició, proposa una classificació, detecta dades absents i prepara el registre; una persona revisa la proposta, corregeix el criteri quan cal i aprova el pas següent.
Aquesta fase permet descobrir quines excepcions es repeteixen, en quins casos la classificació és massa ambigua i quins controls falten abans de donar més autonomia al sistema.
Si encara estàs comparant diverses oportunitats i no has decidit quin cas ha de passar a prova, abans convé revisar Com triar el primer pilot d’IA sense perdre mesos. Això evita confondre una demo que ha sortit bé amb un primer pilot ben acotat.
Si el cas comença en una entrada web, també convé recordar que un formulari no és un procés: abans d’escalar-lo, cal definir què passa amb les dades incompletes, els duplicats, els estats i la responsabilitat de cada cas.
En aquest pilot, el missatge “truqueu-me” no avançaria com si fos una oportunitat completa. El flux el marcaria com una entrada amb context insuficient, prepararia la informació que cal demanar i deixaria el pas següent pendent perquè una persona el revisés. Si la mateixa entrada arribés dues vegades, també mostraria el possible duplicat abans de crear un segon registre.
El pilot no intenta demostrar que el sistema ja pot actuar sol. Serveix per observar, amb casos reals, on el criteri encara necessita una decisió humana i quins controls cal incorporar abans de donar-li més autonomia.
Tornem a la petició comercial del principi. En la demo, el recorregut és simple: entra un missatge clar, la IA el resumeix, el classifica com una oportunitat, crea un registre i avisa l’equip. Aquesta seqüència pot ser suficient per validar la idea. Però per posar-la en el dia a dia cal ampliar la pregunta: què ha de passar amb totes les entrades que no són tan clares?
Una primera versió operativa podria començar validant les dades mínimes. Si no hi ha una manera de contactar amb la persona o el missatge no conté prou context, el cas no avança com si fos complet. Queda marcat com a pendent d’informació o passa a revisió.
Després pot comprovar si ja existeix una entrada semblant. Potser la persona ha enviat el formulari dues vegades o ha escrit també per correu. En lloc de crear dos casos, el sistema pot relacionar-los o avisar que hi ha un possible duplicat.
Només llavors té sentit resumir i classificar. Els casos clars poden continuar. Els que barregen necessitats, contenen informació contradictòria o queden fora de les categories previstes poden arribar a una persona amb el motiu de la derivació.
I encara falta executar l’acció. Si el CRM està disponible, es crea o actualitza el registre. Si no ho està, la petició queda en una cua pendent, es torna a intentar i s’avisa si el problema continua. El sistema no pot dir que ha acabat si la part important no s’ha completat.
El recorregut ja no és només una línia:
- Entrada
- Validar dades mínimesSi falten, demanar informació o derivar.
- Detectar duplicatsRelacionar-los o avisar abans de crear un registre nou.
- Resumir i proposar classificació
- Decidir
- actuar
- demanar informació
- revisar
- aturar
- Crear o actualitzar el registreO deixar-lo pendent de reintent.
- Avisar la persona responsableAmb el context necessari.
- Registrar el resultatDeixar traça de l’acció, l’excepció i la revisió.
Aquesta versió sembla menys espectacular perquè dedica una part important del flux a no actuar malament. Però és molt més útil.
També genera informació que la demo no podia donar. Permet veure quantes entrades arriben incompletes, quins duplicats són habituals, quins casos la classificació no separa bé i quines incidències depenen d’una eina externa.
Això converteix el sistema en una font d’aprenentatge sobre el procés.
La primera versió real no ha de resoldre-ho tot. Pot automatitzar només els casos clars i preparar millor els altres. El criteri no és quanta autonomia aparent té, sinó si cada resultat queda en un estat comprensible i amb un següent pas.
Quatre estats i què ha de ser cert per avançar
Passar d’una demo a un sistema no és un salt únic. És més útil veure-ho com quatre estats, cadascun amb una evidència diferent.
| Estat | Què passa | Què ha de ser cert per avançar |
|---|---|---|
| Demo | El cas controlat funciona i la connexió és possible. | El resultat resol una fricció concreta i val la pena provar-lo amb dades reals. |
| Pilot supervisat | Treballa amb casos reals, però una persona revisa les accions rellevants. | Es veuen patrons d’ús, excepcions repetides, criteris útils i una millora mesurable. |
| Operació amb límits | Resol els casos clars, deriva els dubtosos, recupera errors i deixa traça. | Hi ha propietari, alertes, criteris estables i una manera clara de mantenir-lo. |
| Escala controlada | Augmenta volum, usuaris o abast sense perdre visibilitat ni control. | Els costos són coneguts, els canvis es proven, els permisos estan acotats i hi ha revisió periòdica. |
Cap d’aquests estats és una etiqueta de prestigi. Un pilot supervisat pot ser exactament el que necessita un procés amb impacte extern o criteris que encara s’estan afinant.
El problema no és quedar-se temporalment en una fase. El problema és actuar com si ja fossis a la següent sense haver construït les condicions que la sostenen.
Escalar una dimensió cada vegada
Quan un pilot funciona, és temptador ampliar-lo en diverses direccions al mateix temps: més volum, més canals, més equips, més tipus de cas i més autonomia.
Això fa difícil saber què ha provocat una millora o un problema.
Es pot escalar una sola dimensió. Per exemple, mantenir el mateix tipus de cas i augmentar-ne el volum. O mantenir el volum i obrir el sistema a un segon equip. O conservar l’aprovació humana, però incorporar una font nova. També es pot automatitzar una acció interna abans de permetre una resposta externa.
Fer-ho així permet observar millor el canvi.
Si el sistema comença a fallar després d’afegir un altre canal, sabràs on mirar. Si els costos pugen quan augmenta el volum, podràs ajustar-los abans d’ampliar l’abast. Si un segon equip interpreta les categories d’una altra manera, podràs revisar el criteri abans de donar més autonomia.
Escalar gradualment no és falta d’ambició. És una manera de conservar la capacitat d’aprendre.
Un dels errors habituals en automatització de processos és convertir una primera prova satisfactòria en una solució massa gran abans d’haver entès les excepcions. La millor defensa és canviar una cosa cada vegada i deixar prou traça per veure què passa.
Una matriu per decidir el següent pas
No tots els pilots que funcionen necessiten la mateixa decisió.
| Situació actual | Següent pas recomanat |
|---|---|
| El resultat no redueix una fricció clara o l’equip no l’utilitza. | Parar o reformular el cas abans d’afegir més automatització. |
| Hi ha valor, però les excepcions i els criteris encara canvien sovint. | Continuar amb un pilot supervisat i registrar els motius de revisió. |
| Els casos clars estan ben definits, però l’acció té impacte extern. | Operar amb aprovació humana abans d’enviar, modificar o publicar. |
| El flux tracta errors, evita duplicats, deriva dubtes i deixa traça. | Automatitzar els casos clars amb límits i alertes. |
| Hi ha valor sostingut, propietari, costos coneguts i manteniment definit. | Escalar gradualment volum, usuaris o abast. |
Aquesta matriu no és un certificat. Serveix per tenir una conversa més concreta que “la demo ens ha agradat”.
La decisió correcta pot ser avançar, mantenir el pilot una mica més, reduir l’abast o parar. El que importa és que la següent fase respongui al que ja has après, no només a les ganes de desplegar.
Una bona automatització sap què fer quan alguna cosa no surt bé
Una demo és necessària perquè permet provar una idea sense construir-ho tot. Però el seu èxit és modest: demostra que el cas preparat pot funcionar.
El sistema comença després.
Comença quan l’equip utilitza el resultat, algú n’assumeix la responsabilitat, les excepcions tenen una sortida, les accions deixen traça i els errors es poden recuperar. També comença quan els costos, els permisos i els canvis deixen de dependre de la memòria d’una sola persona.
Abans d’escalar, jo tornaria a les cinc preguntes: aporta valor i l’equip la fa servir? Qui n’és responsable? Què fa amb les dades dolentes i els casos imprevistos? Podem entendre i corregir què ha passat? Es pot mantenir sense convertir-se en una dependència fràgil?
Una bona automatització no és la que no falla mai. És la que sap aturar-se, demanar ajuda, deixar constància i tornar a un estat controlat quan alguna cosa no surt com estava previst.
La demo funciona. Ara cal saber si pot aguantar el dia a dia.
Si tens un pilot o una automatització que ja aporta valor, podem començar amb una diagnosi curta per veure si el fre és al procés, a les dades, a les excepcions, a la responsabilitat o als controls. A partir d’aquí, podem decidir si convé ajustar el pilot, preparar una implementació amb límits o no escalar encara. Pots veure com treballem, explorar les solucions disponibles o anar directament a contacte.