Automatització

Automatitzar aprovacions: errors freqüents i com evitar-los

Una sol·licitud queda pendent perquè ningú no sap qui l'ha de revisar. Una altra s'aprova per defecte tot i que li falta informació. I, quan apareix una excepció, l'equip torna al correu o al xat per resoldre-la manualment. Si aquesta situació et resulta familiar, probablement no necessites només una eina: necessites definir bé el procés abans d'automatitzar-lo.

Aquest article respon a una pregunta pràctica: quins errors convé evitar en automatitzar aprovacions? En acabar, podràs decidir quines parts del teu flux estan preparades per automatitzar, quins controls has de mantenir i quina informació cal preparar abans d'implantar-lo.

Què es vol aconseguir en automatitzar aprovacions

L'objectiu no hauria de ser aprovar més coses sense revisió. Hauria de ser que cada sol·licitud arribi a la persona adequada, amb la informació necessària i en el moment oportú.

Un flux d'aprovació es pot aplicar, per exemple, a despeses, compres, pressupostos, documents interns, canvis de dades o sol·licituds de clients. El patró acostuma a ser semblant: algú envia una petició, el sistema comprova unes regles, avisa la persona responsable corresponent, registra la decisió i comunica el pas següent.

Abans d'escollir una solució, separa tres nivells:

Objectiu: quin problema vols corregir, com ara evitar que les sol·licituds es perdin o reduir esperes innecessàries.
Abast: quins tipus de sol·licitud, persones, dades, estats i excepcions entren en el flux.
Solució: quina eina o integració executarà les regles i enviarà les notificacions.

Començar per la solució acostuma a portar a automatitzar un procés confús. Aquests són els errors més habituals que convé detectar abans.

Errors freqüents en automatitzar aprovacions

1. Automatitzar un procés que ningú no ha descrit

Símptoma: cada persona explica el procés d'una manera diferent. No queda clar què es considera una sol·licitud completa, quan comença la revisió ni què passa després d'aprovar-la.

Causa: s'intenta traslladar a una eina una manera de treballar que depèn de missatges, memòria o acords informals.

Conseqüència: el flux pot moure sol·licituds entre estats, però no resol els dubtes reals. Apareixen bloquejos, decisions duplicades i passos manuals fora del sistema.

Correcció: primer dibuixa el recorregut actual amb prou detall. Per a cada sol·licitud, defineix qui la crea, quines dades aporta, qui decideix, quines decisions són possibles i què passa en cada cas. Després, identifica els passos repetitius que sí que es poden executar mitjançant regles.

2. Fer servir criteris ambigus per decidir qui aprova

Símptoma: apareixen regles com ara «si és important», «si té un import alt» o «si ho revisa direcció», però ningú no concreta què volen dir.

Causa: les decisions es basen en un context que algunes persones coneixen, però que no s'ha convertit en una condició verificable.

Conseqüència: l'automatització no pot assignar correctament la sol·licitud o aplica una ruta que l'equip considera incorrecta. També es fa difícil explicar per què una petició ha arribat a una persona i no a una altra.

Correcció: converteix cada criteri en una regla concreta. Per exemple, defineix quin camp determina la ruta, quins valors admet, qui el pot modificar i què passa si falta. Si una decisió requereix valoració professional, negociació o informació externa, no la forcis dins d'una regla automàtica: deixa una revisió humana identificada.

3. Dissenyar només el camí ideal

Símptoma: el flux preveu enviar, aprovar i finalitzar, però no contempla sol·licituds incompletes, rebutjos, canvis de responsable o manca de resposta.

Causa: el disseny se centra en la seqüència més senzilla i deixa les excepcions per més endavant.

Conseqüència: davant del primer cas no previst, l'equip ha d'intervenir fora del flux. Això pot trencar el registre de decisions i crear incertesa sobre l'estat real de la sol·licitud.

Correcció: per a cada estat, planteja què passa si alguna cosa falla o canvia. Defineix, com a mínim, com demanar informació addicional, com rebutjar amb un motiu, com reassignar una aprovació i què fer quan la persona responsable no pot actuar. No cal automatitzar totes les excepcions des de l'inici, però sí decidir com es gestionaran.

4. Confondre un avís amb una aprovació

Símptoma: una persona rep una notificació, respon per un canal diferent o no respon, i l'equip interpreta aquesta situació com una decisió.

Causa: no s'ha definit quina acció confirma una aprovació ni on queda registrada.

Conseqüència: és difícil saber si la sol·licitud està aprovada, pendent o simplement vista. A més, es poden executar passos posteriors sense una confirmació clara.

Correcció: estableix una acció explícita per aprovar, rebutjar o sol·licitar canvis. Cada decisió ha de deixar associats la persona responsable, la data i el resultat. Les notificacions serveixen per cridar l'atenció; el registre de la decisió és l'element que permet continuar el flux amb seguretat.

5. Permetre que una automatització aprovi decisions sensibles sense límits

Símptoma: es planteja que el sistema aprovi automàticament qualsevol sol·licitud que compleixi unes condicions inicials, encara que el context pugui haver canviat.

Causa: es tracta tota aprovació com una tasca repetitiva, sense distingir entre comprovacions objectives i decisions que impliquen criteri.

Conseqüència: una regla pot validar una condició formal, però no detectar circumstàncies que requereixen revisió. El problema no és l'automatització en si, sinó assignar-li una responsabilitat que no pot valorar segons el context.

Correcció: reserva l'aprovació automàtica per a condicions clares, acotades i revisables. Mantén la intervenció humana quan hi hagi imports, riscos, excepcions, compromisos o dades insuficients que s'hagin d'avaluar. També convé definir qui pot modificar les regles i quan es revisen.

6. No definir permisos ni substitucions

Símptoma: diverses persones poden aprovar sense saber-ho, una persona conserva permisos que ja no necessita o el flux s'atura quan algú és absent.

Causa: les persones responsables s'han configurat com a noms fixos, sense preveure rols, canvis d'equip ni substitucions.

Conseqüència: el procés perd traçabilitat i pot quedar bloquejat. Alhora, els permisos poden no reflectir qui hi hauria d'intervenir realment.

Correcció: defineix quins rols hi participen i què pot fer cadascun: crear, consultar, aprovar, rebutjar, modificar o reassignar. Afegeix una regla de substitució per a les absències i decideix qui revisa periòdicament els accessos. Els permisos no són un detall tècnic; determinen qui pot prendre cada decisió.

7. Connectar eines sense revisar les dades que circulen

Símptoma: una sol·licitud passa d'un formulari a un full de càlcul, un correu o un sistema de gestió, però alguns camps arriben buits, duplicats o amb formats diferents.

Causa: es dona per fet que les eines comparteixen la mateixa informació i significat per a cada dada.

Conseqüència: una aprovació es pot dirigir per una ruta equivocada, crear registres duplicats o deixar dades rellevants fora de la decisió.

Correcció: documenta el recorregut de cada dada rellevant: d'on surt, on es desa, qui la pot canviar i què passa si no arriba correctament. Prova casos amb dades completes, incompletes i modificades. Si hi ha informació personal o confidencial, decideix també quines persones i sistemes hi han d'accedir.

8. Posar en marxa el flux sense criteris de revisió

Símptoma: el sistema sembla que funciona perquè envia avisos, però ningú no comprova si les sol·licituds es resolen per la ruta esperada ni si s'acumulen pendents.

Causa: no s'ha definit com reconèixer que el flux funciona ni qui revisarà les incidències i els canvis posteriors.

Conseqüència: els errors petits es normalitzen. Amb el temps, l'equip pot crear dreceres manuals i perdre confiança en el procés.

Correcció: acordeu criteris senzills de revisió abans d'activar el flux. Per exemple: una sol·licitud completa arriba a la persona responsable definida, una decisió queda registrada, els rebutjos informen de què cal corregir i les excepcions tenen una via de resolució. Prova el procés amb situacions representatives abans d'utilitzar-lo de manera general.

Com prevenir aquests errors sense complicar el primer flux

Comença per un cas concret i repetitiu. No intentis reunir totes les aprovacions de l'empresa en una única automatització des del principi.

Un punt de partida raonable és escollir un tipus de sol·licitud amb responsables identificats i regles relativament estables. Després, redacta una fitxa breu amb aquests elements:

Què activa la sol·licitud.
Quines dades són obligatòries per revisar-la.
Quins estats pot tenir.
Qui aprova o rebutja cada estat.
Quines regles determinen l'assignació.
Quines excepcions requereixen intervenció humana.
Quins avisos s'envien i per quin canal.
On queda registrada cada decisió.
Qui manté les regles, els permisos i els canvis.

Aquesta fitxa permet detectar una qüestió important: potser no cal automatitzar la decisió completa. En alguns casos n'hi ha prou amb automatitzar la recollida de dades, la classificació, l'assignació i els recordatoris, mentre que la validació final continua sent humana.

Llista de comprovació abans d'automatitzar aprovacions

Revisa aquestes preguntes abans de configurar el flux:

Si diverses respostes queden obertes, convé resoldre-les abans d'escollir l'eina o ampliar l'abast. L'automatització funciona millor quan elimina passos repetitius d'un procés que ja s'entén, no quan intenta amagar-ne les indefinicions.

Pas següent

Si tens clar el procés, però dubtes sobre quines regles automatitzar, quins controls humans mantenir o com connectar les eines que ja utilitzes, pots explicar el teu projecte d'automatització a AVSISTEC. Així podràs valorar l'abast a partir de les teves sol·licituds, persones responsables, excepcions i necessitats reals de control.