Imagine una operadora de call center en Caracas. Son las 9 de la mañana y tiene la pantalla de SAP Business One abierta en un monitor, y en el otro, WhatsApp Web con 47 mensajes sin leer. Uno de esos mensajes es un audio de dos minutos de un vendedor de campo que dice, en voz entrecortada desde una farmacia en Valencia: “mandame lo mismo de la semana pasada pero cambia el paracetamol por el ibuprofeno de 400, y agrega dos cajas del antiinflamatorio ese, el grande, el que viene en blíster”.
Eso tiene que llegar a SAP. Alguien tiene que traducirlo.
Es 2026. El ERP existe desde hace 15 años. El problema tampoco es nuevo.
El ERP como sistema de registro, no de captura
Hay una distinción técnica que pocas empresas hacen con precisión: un ERP es un sistema de registro de transacciones estructuradas, no un sistema de captura de intenciones comerciales no estructuradas.
SAP Business One, Profit Plus, Oracle NetSuite — todos fueron diseñados para almacenar y procesar datos que ya vienen en el formato correcto. Un pedido en el ERP tiene campos fijos: código de cliente, código de producto (SKU exacto), cantidad, unidad de medida, lista de precios, bodega de despacho. El ERP es extraordinariamente bueno en procesar esos datos una vez que están correctamente formados.
Lo que el ERP no hace — ni fue diseñado para hacer — es interpretar “el ibuprofeno de 400” y convertirlo en SKU-IBUP-400MG-TAB-20 según el maestro de productos del cliente. Esa traducción siempre estuvo en manos de una persona.
Los canales reales de un distribuidor en LatAm
Un laboratorio farmacéutico o una distribuidora de consumo masivo en Venezuela, Colombia o Bolivia recibe pedidos por una variedad de canales que ningún departamento de TI diseñó oficialmente:
- WhatsApp Business: el canal dominante. Audios, fotos de listas manuscritas, textos con abreviaturas propias del comprador.
- Email con PDF adjunto: el comprador tiene su propio formato de orden de compra. Cada cliente tiene el suyo, con sus propias columnas, sus propios encabezados, a veces en español, a veces mezclado con inglés.
- Email con tabla en el cuerpo del mensaje: ni siquiera hay archivo adjunto. Los datos están pegados directamente en el cuerpo, con formato que depende del cliente de correo que usó el comprador.
- Llamada telefónica: el vendedor de campo llama desde el punto de venta. La operadora toma nota en papel o en un Excel propio antes de ingresar al sistema.
- Portal web propio: si el distribuidor tiene uno, lo usan los clientes que pudieron registrarse. Normalmente una fracción del total.
Cada uno de estos canales llega con un formato diferente, con diferentes errores posibles, con diferente completitud de información. Un cliente manda el código de producto correcto; otro manda el nombre del producto como lo conoce en su farmacia, que puede diferir del nombre en el catálogo del distribuidor.
La trampa de la digitación manual
El costo visible de este proceso es el salario del operador que digita. Pero ese no es el costo real.
El costo real está en tres lugares:
Errores de transcripción. Un código de producto con un dígito equivocado. Una cantidad de 20 leída como 200. Un SKU de presentación de 20 unidades confundido con la presentación de 100. Estos errores generan despachos incorrectos, devoluciones, notas de crédito, llamadas de reclamo, deterioro de la relación comercial. No se contabilizan como “errores del operador” en los sistemas de gestión — aparecen como “ajustes de inventario” o “devoluciones de clientes”, invisibles en sus causas reales.
Excel paralelos. Los equipos de operaciones desarrollan hojas de cálculo propias para validar pedidos antes de ingresarlos al ERP: listas de precios extraídas del sistema, codificación propia de productos, historial de pedidos del cliente. Estos archivos son frágiles, no están sincronizados con el ERP, y representan un riesgo operacional que ninguna auditoría suele detectar a tiempo.
Techo de crecimiento implícito. Si procesar 200 pedidos por día requiere 4 operadores, procesar 400 pedidos por día requiere 8 operadores. El crecimiento del negocio tiene un costo de escala lineal en personal de captura — un techo que no está en el roadmap de ningún comité de dirección, pero que aparece inevitablemente cuando el negocio crece.
Por qué los conectores EDI estándar no resuelven esto
La respuesta estándar de TI a este problema es “implementemos EDI”. Y tienen razón — en el contexto correcto.
EDI clásico (ANSI X12, EDIFACT) es una solución extraordinariamente eficaz cuando ambas partes tienen sistemas capaces de generar y consumir documentos estructurados en un formato acordado. Una cadena de retail grande puede exigir a sus proveedores certificación EDI porque tiene el poder de negociación para hacerlo. Los proveedores se adaptan o pierden el contrato.
En la distribución farmacéutica y de consumo masivo en LatAm, esa asimetría de poder no existe en la misma dirección. El laboratorio no puede exigirle a una farmacia de 3 empleados en Maracaibo que implemente SAP y certifique un canal EDI. Esa farmacia va a seguir mandando su pedido por WhatsApp porque es lo que tiene y lo que sabe usar.
El resultado es que el 80% de los pedidos de un laboratorio venezolano promedio no vienen por EDI — vienen por los canales no estructurados descritos arriba. El conector EDI resuelve el 20% que ya tenía sistema. El otro 80% sigue siendo trabajo manual.
El problema tiene nombre
Lo que acabamos de describir se llama captura no estructurada de pedidos en el extremo B del B2B. Es el problema más común, más costoso y más ignorado de la cadena de suministro comercial en América Latina.
La solución no es obligar al cliente a cambiar su canal. La farmacia de barrio no va a adoptar EDI. El vendedor de campo no va a dejar de usar WhatsApp.
La solución es absorber el canal del cliente — cualquiera que sea — y entregar estructura al ERP. Recibir el caos y producir orden. Eso es lo que hacemos en Greicodex, y lo que llamamos EDI Asimétrico.
En el siguiente artículo explicamos cómo funciona esa arquitectura en detalle.