(Què fem)
02 Aplicacions, integracions i sistemes sobre models, escrits per a la teva operativa.
Aquesta part reuneix tres classes de programari: les aplicacions amb què treballa cada lloc de treball, les integracions que mouen les dades entre els teus programes i els sistemes que posen un model de llenguatge a treballar dins d’un procés, amb límits fixats en codi. Totes tres comparteixen l’entorn, els comptes i el registre d’activitat de la resta del sistema.
Aplicacions per a cada lloc de treball
Cada aplicació parteix d’un model de dades explícit i dels permisos que ja existeixen a la teva empresa, i deixa constància de qui crea, modifica o aprova cada registre.
-
01 Aplicacions web internes
Panells, portals, CRM propis i eines d’equip al navegador, amb un compte per persona i permisos per rol. Llegeixen i escriuen a través de les mateixes integracions que la resta del sistema.
-
02 Apps per a iPhone i Android
Per a la feina fora de l’oficina: fotos i notes de veu a l’obra, al magatzem o en una visita, i consulta de l’estat d’una comanda o d’un projecte. Fan servir la càmera, el micròfon i les notificacions del telèfon, i envien el que capturen al mateix sistema que fa servir l’oficina.
-
03 Programes d’escriptori per a Mac i Windows
Per a fitxers locals pesants, carpetes de xarxa o diàleg amb programes instal·lats al lloc de treball, com els de modelatge, càlcul o pressupostos. S’executen a l’ordinador i se sincronitzen amb els serveis de l’empresa.
-
04 Pantalles davant de programes antics
El programa antic continua sent el sistema de registre. La pantalla nova valida cada dada abans d’escriure-la, per la mateixa via que fan servir les seves integracions, i cada operació es registra completa o no es registra. L’alta d’un projecte, un client o una comanda s’introdueix una sola vegada i la pantalla la distribueix entre els programes que la fan servir.
Integracions entre programes
Triem la via de connexió per estabilitat: primer la interfície documentada del fabricant, després l’intercanvi de fitxers i, en últim terme, la lectura directa de la seva base de dades, que exigeix més manteniment. Tot el que entra es desa en brut abans de processar-se, de manera que qualsevol dada es pot tornar a processar i auditar.
Per API i webhooks
Connectors sobre API REST, amb webhooks quan el programa notifica els seus esdeveniments i consulta periòdica quan no ho fa. Cada crida respecta els límits de taxa del proveïdor, es reintenta amb una espera creixent i és idempotent: un reintent mai no duplica una comanda ni una factura.
Per fitxers
Quan no hi ha API, l’intercanvi fa servir els formats que el programa ja sap llegir i escriure: IFC des del model BIM, BC3 per al programa de pressupostos, DWG per als plànols, i CSV, Excel o PDF per a la resta. Cada fitxer es valida contra la seva estructura abans d’importar-lo.
Servidors MCP
Un servidor MCP embolcalla un sistema antic i exposa a un model un conjunt tancat d’operacions amb paràmetres tipats, majoritàriament de lectura. Així un model consulta un ERP o un programa tècnic sense accés a la seva base de dades.
Proves de cada connector
Un connector es dona per bo quan es pot tallar el programa d’origen a mitja operació sense perdre ni duplicar cap registre. Cada missatge es valida contra l’esquema esperat: si un proveïdor canvia un camp, el missatge s’atura amb el seu error en lloc d’escriure’s a mitges. Les equivalències entre programes, com ara els codis de client i d’article, les unitats o els tipus d’IVA, viuen en una taula revisable.
Sistemes construïts sobre un model concret
Cada model difereix en la finestra de context, la fiabilitat a l’hora d’invocar eines, la quantitat de tokens que genera per a una mateixa tasca i el rendiment en cada idioma. Per això cada sistema té el seu propi W.A.T. (Workflows, Agents, Tools) i les seves pròpies cadenes de procés, ajustats al model i a la versió fixada sobre la qual funciona.
-
01 El flux, dissenyat per al model
El flux de treball és la seqüència fixa del procés. La dividim en passos de la mida que aquell model resol amb fiabilitat, cadascun amb les seves instruccions i el seu esquema, i desem l’estat de cada etapa: si alguna cosa falla, el procés es reprèn on s’havia aturat. El que resol el codi determinista no passa pel model.
-
02 El criteri, només on cal
Els agents són rols amb un objectiu, unes eines i uns límits definits, i només intervenen en els passos del flux que exigeixen criteri: un redacta, un altre comprova el resultat contra unes regles i un altre prepara l’acció perquè una persona l’aprovi.
-
03 Eines precises
Cada eina fa una sola cosa, amb paràmetres tipats, una descripció inequívoca i errors que el model sap interpretar. El model només proposa la crida; l’execució, els permisos i el registre corresponen a la nostra capa. Les operacions irreversibles queden fora de la caixa d’eines: les executa una persona, o codi determinista després d’una aprovació registrada.
-
04 Al núvol o al teu servidor
Amb un model al núvol, avui de les famílies Mistral o Claude, un pas pot gestionar més context i més eines. Un model obert instal·lat al teu servidor, com Granite, ALIA/Salamandra o EuroLLM, rep passos més curts, menys eines i esquemes més estrictes, i cap dada no surt de l’empresa. El servim amb vLLM o SGLang en producció, que reaprofiten la memòria cau entre peticions, i amb Ollama als prototips. El model de cada tasca es revisa cada mes.
Eficiència i control de la despesa
Cada sistema es dissenya per gastar el mínim per resultat útil, amb els seus límits escrits en codi, on no depenen que el model obeeixi una instrucció.
- Cost per tasca acabada: mesurem el cost de cada comanda registrada o de cada resposta enviada, no el preu per token: un model barat que genera més tokens de sortida pot acabar sortint més car.
- Prefix estable: les instruccions, els esquemes i les definicions d’eines van sempre al davant i sense canvis, per aprofitar la memòria cau de prefix del proveïdor o del servidor propi; el que és variable va al final.
- Retall determinista: abans de resumir amb un model, el context es retalla amb regles i se’n descarten els duplicats, els torns antics i els camps que la tasca no fa servir.
- Topalls durs: un màxim de passos i de despesa per tasca i per clau, aplicat per codi i registrat.
- Escalat per pas: cada pas fa servir el model més econòmic que el resol amb fiabilitat, comprovat amb casos reals, i només els casos que ho exigeixen passen a un model més gran.
- Sortides estructurades: cada resposta és un objecte validat contra JSON Schema, amb el seu nivell de confiança i la indicació de si ha de passar a una persona. El que no valida es registra com a error, sense reintents silenciosos.
Resultats i com es mesuren
- Menys reintroduccions: les vegades que es tecleja la mateixa dada en dos programes, comptades amb el mètode de la línia base del diagnòstic.
- Temps per tasca: abans i després, en cada tasca sobre la qual actua el programari, amb el mateix mètode.
- Cost i passos per tasca acabada: en els sistemes sobre models, comparats després de cada ajust del flux o canvi de versió.
- Entrades aturades per validació: quantes dades frena cada comprovació abans d’arribar a un programa, i per quin motiu.
Posem la teva empresa al dia?
Comencem amb una trucada de 30 minuts per entendre el teu cas i explicar-te en què consisteix el diagnòstic i quin preu té.
Demana el diagnòstic