Com automatitzar proveïdors sense perdre el control del procés

Un proveïdor confirma un lliurament per correu electrònic, un altre envia una tarifa en PDF i un tercer avisa d’un retard per telèfon. Després cal actualitzar un full de càlcul, informar compres o producció i comprovar si falta cap dada. Si aquesta situació et resulta familiar, probablement no necessitis automatitzar tota la relació amb els proveïdors: necessites decidir quins passos repetitius poden seguir una regla clara i quins requereixen el teu criteri.

Aquest cas és expressament hipotètic. Serveix per respondre una pregunta pràctica: per on començar a automatitzar proveïdors sense crear un sistema difícil de mantenir? En acabar podràs delimitar un primer flux, identificar les dades que necessita i establir controls per comprovar que funciona.

Situació inicial hipotètica

Imagina una petita empresa que compra materials a diversos proveïdors. La persona responsable rep sol·licituds internes de compra, consulta preus o disponibilitat, envia comandes i fa seguiment de les confirmacions. La informació queda repartida entre correus electrònics, trucades i un full compartit.

La direcció no busca substituir qui negocia ni delegar decisions de compra rellevants en un sistema. Vol evitar que es perdin avisos, que una confirmació trigui a arribar a qui la necessita o que l’estat d’una comanda depengui de revisar diverses safates d’entrada.

La primera decisió no seria «instal·lar una eina», sinó concretar el canvi desitjat:

Cada comanda enviada ha de quedar registrada, tenir una persona responsable i mostrar si està pendent de confirmació, confirmada, amb incidència o tancada.

Aquest objectiu és observable. També permet distingir una millora operativa concreta d’una automatització massa àmplia.

Problema observable: el seguiment depèn de recordar

En aquest escenari, el problema no és que hi hagi correus electrònics. El problema apareix quan el correu electrònic es converteix en l’únic lloc on viu l’estat de la comanda.

Per exemple, la persona responsable pot enviar una sol·licitud a un proveïdor i anotar la comanda en un full. Si arriba una resposta, ha de localitzar el registre correcte, actualitzar-lo i avisar una altra persona. Si no arriba cap resposta, algú ha de recordar revisar-ho. Cada pas aïllat sembla petit, però el procés perd traçabilitat quan depèn d’una atenció manual constant.

Abans d’automatitzar proveïdors, convé descriure el recorregut real d’una comanda:

1. Algú sol·licita una compra.
2. Es revisa què es necessita i si cal fer la comanda.
3. Es prepara i s’envia la sol·licitud al proveïdor.
4. Arriba —o no arriba— una confirmació.
5. Es registra la data prevista, una incidència o un canvi.
6. La persona adequada consulta l’estat i actua si cal.

No tots aquests passos s’han d’automatitzar. L’aprovació d’una compra, l’elecció entre ofertes o l’acceptació d’un canvi de condicions poden requerir valoració humana. En canvi, registrar una sol·licitud aprovada, crear un avís de seguiment o actualitzar un estat a partir d’una confirmació estructurada són candidats més clars.

Anàlisi de l’objectiu: separar decisions de moviments d’informació

Per triar bé el primer cas, pots dividir el procés en tres capes:

Aquesta separació evita demanar una automatització a partir d’una etiqueta imprecisa. Si l’objectiu és saber quines comandes necessiten atenció, potser no cal interpretar qualsevol document rebut ni connectar totes les eines de l’empresa des del principi.

També obliga a respondre preguntes que canvien el resultat:

• Quina dada identifica cada comanda?
• Qui en pot canviar l’estat?
• Què es considera una confirmació vàlida?
• Quan s’ha de generar un avís i qui el rep?
• Què passa si falta la data de lliurament o el proveïdor respon amb informació ambigua?

Una automatització només pot aplicar regles que estiguin definides. Si una resposta exigeix comparar condicions, negociar o interpretar una excepció, s’ha de deixar preparada per a revisió humana en lloc de forçar una decisió automàtica.

Abast proposat per a una primera aplicació

En el cas hipotètic, l’empresa decideix començar pel seguiment posterior a l’enviament de la comanda. Deixa fora de la primera versió la negociació de preus, la selecció de proveïdors i la comptabilització de factures.

L’abast podria quedar així:

• Crear un registre quan s’aprova i s’envia una comanda.
• Desar proveïdor, referència, articles o concepte, responsable i data prevista quan estiguin disponibles.
• Marcar la comanda com a pendent de confirmació.
• Avisar la persona responsable si transcorre el termini definit sense resposta.
• Permetre que una persona validi i actualitzi confirmacions o incidències abans de tancar la comanda.

La diferència és important: el sistema no decideix si una resposta del proveïdor és acceptable. Fa visible allò que necessita atenció i redueix les tasques de còpia, cerca i recordatori.

Convé establir des de l’inici què en queda fora. Per exemple, una resposta rebuda en un format no previst pot necessitar classificació manual. De la mateixa manera, una incidència de qualitat o una modificació de preu hauria de seguir una ruta de revisió acordada. Definir aquests límits protegeix el procés i evita donar per fet que l’automatització entén qualsevol situació.

Solució i comprovació: aplicar regles visibles

L’aplicació hipotètica comença amb un registre únic de comandes. Cada comanda té un identificador, un estat i les dades mínimes per fer-ne el seguiment. A partir d’aquí, el flux executa accions senzilles segons condicions conegudes.

Un exemple de funcionament seria aquest:

• Quan es crea una comanda aprovada, el sistema la registra com a «pendent de confirmació».
• Si arriba una confirmació identificable i conté les dades necessàries, es prepara l’actualització de l’estat perquè una persona la revisi o s’actualitza segons la regla acordada.
• Si no hi ha confirmació dins del termini definit per l’empresa, s’envia un avís al responsable.
• Si es registra una incidència, la comanda passa a un estat que impedeix donar-la per tancada fins que no es revisi.

La comprovació no s’hauria de limitar a verificar que surt un avís. Cal provar situacions habituals i excepcions: una comanda amb totes les dades, una confirmació tardana, una referència incorrecta, un missatge duplicat i una resposta que no permeti identificar la comanda. Així es detecta on una regla funciona i on el flux ha de demanar intervenció humana.

També convé decidir qui manté els estats, els destinataris dels avisos i les regles de termini. Una automatització que ningú no pot ajustar quan canvia el procés acaba traslladant el problema a un altre lloc.

Aprenentatges transferibles

El cas mostra que automatitzar proveïdors no consisteix a eliminar totes les intervencions manuals. Consisteix a triar un punt concret en què la informació es mou de manera repetitiva, definir una regla comprensible i mantenir el control sobre les excepcions.

Abans d’ampliar el sistema a comandes, factures, inventari o avaluació de proveïdors, convé comprovar que el primer flux respon tres preguntes: què ha passat, què falta i qui ha d’actuar. Si les respostes són visibles i els casos ambigus arriben a la persona adequada, tindràs una base més sòlida per decidir la següent automatització.

Si necessites dissenyar un flux connectat amb les teves eines i els teus criteris de revisió, pots explicar el teu projecte d’automatització. El punt de partida útil és indicar quina informació reps, quina acció repeteixes i en quin moment necessites mantenir una validació humana.