Preparación para IA · ERP · Integridad de datos
Siete señales de que los datos de tu ERP no están listos para la IA
Antes de poner un agente de IA a leer el ERP, conviene revisar siete señales de datos que no cuadran. Cada una tiene causa conocida y corrección posible, y el orden importa.
La pregunta más común que escuchamos de empresas que intentaron usar IA sobre su propio ERP es alguna variación de “el modelo responde bonito, pero el número está mal”. El modelo no está mal: leyó lo que había. El problema es que nadie había revisado lo que había.
Un modelo de lenguaje no corrige datos; los amplifica. Si el maestro está duplicado, la respuesta sale duplicada con un texto convincente alrededor. Por eso el primer trabajo de cualquier proyecto de IA sobre los datos de la empresa es el más aburrido: mirar los datos.
Estas son las siete señales que más aparecen en nuestros mapeos. Si reconoces tres o más, tu empresa todavía está en la etapa de mapeo de datos, no en la de implementación.
1. Campo libre haciendo el papel de campo estructurado
La obra, el proyecto, el vendedor o el motivo del ajuste van en el campo “observaciones”, “historial” o “complemento”. Un humano con experiencia lo lee y entiende. Un informe no agrupa. Un agente de IA agrupa mal y con confianza.
Corrección: promover la información a campo propio, con lista cerrada de valores, y migrar el histórico con reglas explícitas.
2. La misma cosa con nombres distintos
“Cliente”, “deudor” y “tomador” son la misma entidad en tres módulos. “Obra” en finanzas es “proyecto” en compras y “centro de costo” en contabilidad. Sin un vocabulario único, cada pregunta a la IA necesita tres traducciones.
Corrección: un diccionario de datos con el nombre canónico, los sinónimos y en qué sistema aparece cada uno.
3. Registros duplicados
El mismo proveedor con dos identificaciones fiscales tipeadas de forma distinta, el mismo producto en tres códigos, el mismo empleado en dos centros. Ya tratamos el costo de esto en Por qué el maestro de tu ERP no cuadra con el inventario.
Corrección: regla de unicidad (identificación fiscal, código de barras, legajo), rutina de deduplicación y separación entre quien registra y quien aprueba.
4. Fechas que no representan el hecho
La fecha del asiento es la fecha en que alguien tipeó, no la fecha en que la cosa ocurrió. Devengo, emisión, vencimiento, pago y asiento se mezclan. Cualquier análisis de tendencia, previsión de caja o estacionalidad sale desplazado.
Corrección: definir, por documento, qué fecha responde a qué pregunta, y exigir la fecha del hecho como campo obligatorio.
5. Ajustes recurrentes
Todos los meses hay un “ajuste de stock”, una “corrección de saldo” o una “reversión” del mismo tamaño. El ajuste recurrente es síntoma de regla ausente: el sistema no sabe hacer algo que la operación hace cada mes, y alguien lo corrige a mano.
Corrección: mapear el proceso detrás del ajuste y llevarlo dentro del sistema, o al menos registrarlo como regla escrita.
6. Nadie sabe explicar una columna
Hay un campo llamado flag_tp2 que todos los informes usan y nadie sabe qué significa. O un estado “7” que el equipo aprendió a ignorar. Los datos sin dueño y sin definición son lo que más confunde a un modelo, porque va a inventar una explicación plausible.
Corrección: inventario de campos con dueño, definición y ejemplos, empezando por los usados en los informes de gestión.
7. El informe que depende de una persona
El cierre mensual solo sale porque una analista sabe qué líneas excluir, qué planilla cruzar y qué cuenta ignorar. Ese conocimiento no está en ningún sistema. Cuando la IA intenta reproducir el informe, no puede, y cuando la analista sale de vacaciones, la empresa tampoco.
Corrección: documentar el proceso paso a paso, con las excepciones, y transformarlo en regla ejecutable. Es exactamente el tipo de contexto que el agente necesita para operar.
El orden importa
Las siete señales tienen corrección, y ninguna exige cambiar de ERP. Lo que exigen es orden: mapear (saber qué está mal y cuánto cuesta), diseñar la arquitectura (decidir qué corregir en el sistema, qué resolver con una regla y qué entregar a un agente) y recién entonces implementar la IA en producción. Saltarse etapas es lo que produce el “responde bonito, pero está mal”.
Si quieres una lectura externa de tus datos antes de invertir en IA, la conversación de diagnóstico con Koltren es el primer paso, sin compromiso.