Chatbots interns amb dades de l'ERP: IA conversacional

La demostració sempre convenç. Algú escriu «quant vam facturar al Client A el trimestre passat» i apareix una resposta fluida i ben formatada. Tots els presents pensen immediatament en cinc preguntes que farien. El projecte s'aprova.

Després afloren dos problemes, i són el mateix problema amb roba diferent. El primer és que la resposta ha de ser correcta: no plausible, no aproximadament correcta, sinó correcta tal com ho ha de ser una xifra d'un informe de direcció, perquè algú hi actuarà. El segon és que la resposta ha de ser correcta per a qui pregunta: un comercial que pregunta pel marge, un responsable de magatzem que pregunta per la situació creditícia d'un client i un analista financer que fa les mateixes preguntes no tenen tots dret a la mateixa resposta.

Un chatbot sobre dades de l'ERP no és, per tant, un projecte d'interfície conversacional. És un projecte de recuperació de dades, permisos i verificació amb una interfície conversacional a sobre, i l'ordre d'aquestes paraules marca tota la diferència entre una cosa útil i una cosa que desinforma la seva empresa en silenci.

Per què això importa

El benefici és genuí i no té gaire a veure amb la comoditat. La majoria dels ERP del mid-market contenen respostes que ningú no recupera, perquè recuperar-les exigeix saber quina cerca desada cal executar, i aquest coneixement està concentrat en tres o quatre persones. Aquestes persones esdevenen un coll d'ampolla per a preguntes rutinàries, i la resta o endevina o treballa amb un full de càlcul exportat que estava actualitzat el mes passat. Fer que les dades siguin realment accessibles canvia de debò com opera una empresa.

El risc és proporcionat. Un sistema que respon amb fluïdesa i de tant en tant s'equivoca és més perillós que un que és difícil d'utilitzar, perquè els errors arriben amb la mateixa seguretat que les respostes correctes i no hi ha cap moment natural de dubte. Un comercial que dona una xifra de marge a un client, o un responsable que pren una decisió d'aprovisionament amb un número mal llegit, no sabrà que aquesta resposta concreta era una de les equivocades.

I hi ha un risc d'exposició que és fàcil de crear accidentalment. Un chatbot connectat amb permisos amplis de compte de servei explicarà de gust a qui pregunti els salaris, els marges per client o els preus dels proveïdors. La interfície fa trivialment accessibles dades abans fosques, que és precisament l'objectiu, i això vol dir que un control d'accés que era adequat quan les consultes requerien perícia ja no ho és.

Cop d'ull: tipus de pregunta i si convé permetre'ls

La distinció que importa és entre recuperar i raonar. Les preguntes que es responen obtenint un número i aplicant una definició acordada són segures. Les que exigeixen interpretar per què ha passat una cosa conviden a un relat fluid que pot estar completament construït, i els usuaris no en noten la diferència. Mantingui el sistema al costat de la recuperació d'aquesta línia i digui-ho obertament als usuaris.

Què funciona i sobre què cal ser honest

Què funciona:

Consultes contra fonts definides i deterministes, no interpretació lliure. El chatbot assigna la pregunta a una de les consultes parametritzades d'un catàleg curat: cerques desades, informes, mètriques definides. Si cap consulta no encaixa, ho diu. Això és menys vistós en una demostració i espectacularment més fiable en producció.

Permisos heretats de l'usuari que pregunta, sempre. Cada consulta s'executa amb els permisos que aquella persona té a l'ERP, no amb els d'un compte de servei. És la decisió de disseny més important de tot el projecte i és la que més sovint s'ajorna perquè resulta incòmoda.

Cada resposta mostra el seu desenvolupament. La xifra, la font, els filtres aplicats, el període i un enllaç al registre o informe subjacent. Els usuaris han de poder verificar, i la presència d'una citació canvia com tracten el número, i per bé.

Negativa explícita abans que inferència. Quan la pregunta és ambigua o no està suportada, el comportament correcte és dir-ho i oferir allò que sí que pot respondre. Un sistema que endevina per semblar útil s'equivocarà de tant en tant i serà cregut sempre, que és la pitjor combinació.

Definicions acordades abans del desplegament. Si «ingressos», «marge» o «client actiu» signifiquen coses diferents en tres departaments, el chatbot n'escollirà una i la presentarà com un fet. Fixi primer les definicions; l'exercici ja val la pena per si mateix.

Registrar cada pregunta i cada resposta. Això li dona una traça d'auditoria, una visió de què vol saber realment la gent i l'evidència per detectar una resposta sistemàticament errònia abans que es propagui.

Sobre què cal ser honest:

L'agregació és on s'amaguen els errors. Una consulta d'un sol registre mal resolta es veu de seguida. Una agregació subtilment errònia —un filtre que exclou l'intercompanyia, un límit de període desplaçat un dia, una divisa sense convertir— produeix un número plausible que ningú no qüestiona. Les consultes d'agregació s'han de provar contra informes de correcció coneguda, i tornar-se a provar quan aquests informes canviïn.

Els usuaris confiaran en excés en una sortida fluida. És una propietat del mitjà, no de la seva configuració. Mitigui-ho amb citacions, declaracions explícites d'abast i explicant a la gent sense embuts per a què no serveix el sistema. Compti amb repetir aquest missatge.

Traurà a la llum els seus problemes de qualitat de les dades com a errors visibles per a l'usuari. Registres de client duplicats fan que una consulta de client retorni resultats parcials. Dades d'article inconsistents produeixen respostes incompletes. El chatbot no crea aquests problemes; els fa públics.

Consolidar no és sumar, i el sistema no ho sabrà. Les xifres de grup requereixen lògica d'eliminació i de conversió. Tret que aquesta lògica sigui explícita i s'utilitzi, les preguntes entre entitats s'haurien de bloquejar en lloc de respondre-les de manera aproximada.

L'ampliació incontrolada de l'abast és el principal mode de fallada. Comença amb l'estat de les comandes i preguntes definitòries, funciona bé, i després algú demana previsions. Els tipus de pregunta prospectiva i explicativa són on es perd la confiança, i el límit s'ha de sostenir deliberadament.

Marc de decisió: dissenyar-ho amb seguretat

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

1. Pot executar-se cada consulta amb els permisos propis de l'usuari que pregunta?
Si no, resolgui això abans que res. Un chatbot sobre un compte de servei compartit és una exposició de dades amb una interfície amable, i l'utilitzaran persones l'accés de les quals abans estava limitat per la seva incapacitat d'escriure consultes, no per política.

2. Tenen les seves mètriques clau una única definició acordada cadascuna?
Si no, fixi-les. Ingressos, marge, client actiu, lliurament a temps. Altrament, el chatbot presentarà la definició d'un departament com la resposta de l'empresa.

3. Ha definit el domini de preguntes suportat i què passa fora d'ell?
Escrigui el límit, implementi una negativa explícita fora d'ell i comuniqui-ho als usuaris. Comenci estret: consultes d'estat, agregacions definides i preguntes de política i procés.

4. Porta cada resposta la seva font, els seus filtres i el seu període?
Si no, afegeixi-ho abans del llançament i no després. És el que fa possible la verificació i el que canvia el comportament de l'usuari per bé.

5. Ha provat les respostes d'agregació contra informes de correcció coneguda?
Construeixi un conjunt de proves de preguntes amb respostes verificades i torni a executar-lo sempre que canviïn els informes subjacents o la configuració. És una bateria de regressió, i és el que evita la desviació silenciosa.

6. Es registra cada interacció amb l'usuari, la pregunta, la consulta executada i la resposta?
Implementi-ho des del primer dia. És la seva traça d'auditoria i la seva millor font d'informació sobre què construir a continuació.

7. Tot l'anterior i els usuaris encara no l'adopten?
Normalment el domini suportat és massa estret per ser útil, o les respostes són correctes però més lentes que preguntar a un company. Miri les preguntes registrades que va rebutjar: aquí té el seu full de ruta.

Cost i esforç indicatius

Assumeix una única instància d'ERP i un domini inicial de preguntes definit. La consolidació multientitat, o l'extensió a fonts documentals no estructurades, amplia això de manera substancial. Sol·liciti un pressupost per a una estimació delimitada.

Preguntes freqüents

Pot generar consultes dinàmicament en lloc d'utilitzar un catàleg curat?
Tècnicament sí, i no ho recomanaríem per a dades financeres i operatives a escala mid-market. Una consulta generada que és subtilment incorrecta produeix un número plausible sense cap senyal d'error. Un catàleg curat és menys flexible i les seves fallades són visibles, cosa que per a xifres sobre les quals la gent actua és l'intercanvi adequat.

Com evitem que respongui preguntes que no hauria de respondre?
Dues capes: permisos, perquè no pugui recuperar el que l'usuari no pot veure; i delimitació del domini, perquè categories senceres —dades personals, preguntes prospectives, anàlisi explicativa— quedin excloses per disseny en lloc de filtrar-se cas per cas.

I les al·lucinacions?
Ancorar cada resposta en un resultat recuperat i exigir una citació cobreix la major part del risc en les preguntes de recuperació. El risc residual és en com es resumeixen els resultats i en les preguntes explicatives, on es convida el sistema a construir un relat, i per això s'haurien d'excloure en lloc de mitigar-les.

Hauria d'escriure a l'ERP a més de llegir?
Al principi no, i el només lectura és una posició permanent defensable per a una interfície conversacional. Les accions d'escriptura corresponen a agents amb límits d'autoritat definits, traces d'auditoria i vies d'escalat —el disseny que tractem en altres articles d'aquesta sèrie— i no a una finestra de chat on la intenció s'infereix del llenguatge natural.

Com mesurem si funciona?
Preguntes formulades, preguntes rebutjades, precisió verificada contra el seu conjunt de proves i el canvi en la demanda sobre les dues o tres persones que abans responien aquestes preguntes. L'últim és el veritable cas de negoci.

Amb quina rapidesa pot el chatbot connectar-se realment a les dades de l'ERP en directe?
La connexió sol ser ràpida — un partner certificat com Stacksync pot tenir la sincronització en temps real i governada entre l'ERP i la capa de dades del chatbot funcionant en setmanes. Aconseguir que el chatbot respongui només amb allò que realment té permís de veure, com s'explica d'amunt, és la part que necessita temps real de disseny.

Tancament — Passos següents

Un chatbot intern sobre dades de l'ERP és l'element més demostrable i més mal entès d'aquesta sèrie. El que fa que funcioni gairebé no té res a veure amb la conversa: són els permisos per usuari, les definicions de mètriques acordades, les consultes deterministes curades, les fonts visibles i un límit que el sistema es nega a creuar.

Un punt de partida útil que costa una setmana: reculli les vint preguntes que els seus equips de finances i operacions reben realment amb més freqüència. Separi-les en preguntes de recuperació i preguntes de raonament. La primera pila és el seu abast inicial, i normalment és prou gran per justificar el projecte per si sola.

Sobre l'autor

Bruno Galo és el fundador d'Atypical Tech, una consultora de NetSuite que presta servei a clients mid-market de tota la península Ibèrica. Està especialitzat a connectar sistemes CRM i ERP per a fluxos order-to-cash sense friccions, construint pipelines automatitzats de gestió de comandes que eliminen la introducció 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 i amb automonitoratge.

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

Fonts

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

• Oracle NetSuite, documentació de rols, permisos i cerques desades — https://docs.oracle.com/en/cloud/saas/netsuite/
• NIST, AI Risk Management Framework — validesa, fiabilitat i transparència — https://www.nist.gov/itl/ai-risk-management-framework
• Comissió Europea, EU AI Act — obligacions de transparència — https://digital-strategy.ec.europa.eu
• Comitè Europeu de Protecció de Dades, orientacions sobre minimització de dades i control d'accés — https://www.edpb.europa.eu
• Experiència d'Atypical Tech en projectes d'ERP mid-market i desplegaments conversacionals a la península Ibèrica
• Stacksync, blog de la plataforma d'integració i sincronització en temps real — https://www.stacksync.com/blog