Estoy de acuerdo Utilizamos cookies para mejorar la experiencia de navegación del usuario y para estudiar cómo se utiliza nuestro sitio web. Si navega por nuestro sitio web, estará aceptando el uso de las cookies en las condiciones establecidas en la presente política de cookies. Esta política puede ser actualizada, por lo que le invitamos a revisarla de forma regular.
¡HOLA! Si quieres proponernos un proyecto contacta con nosotros, escribe un mail a la siguiente dirección: info@albatian.com
Por Francisco González, experto en Transformación de datos
Hoy en día, una condición absolutamente necesaria para el crecimiento sostenido de una empresa comercial es su facilidad para el intercambio electrónico de información con clientes y proveedores. Es impensable al día de hoy, que una empresa que reciba 100 pedidos y genere 100 facturas al día, tome los pedidos por teléfono o envíe 100 sobres por correo ordinario a sus clientes. A medida que el negocio crece, aumenta proporcionalmente la cantidad de recursos de personal necesarios para afrontar tal cantidad de trabajo manual.
Aunque los datos de los pedidos lleguen en el texto de un e-mail o las facturas se envíen en formato PDF, esto no supone una mejora considerable, puesto que el receptor siempre tiene que introducir los datos a mano en su sistema. Aquí los primeros en poner la señal de stop son las grandes cadenas comerciales (Makro, Alcampo, El Corte Inglés, etc…), que no pueden acometer el trabajo de teclear las 1.000 facturas de proveedores que reciben a diario.
Una alternativa para estas grandes empresas sería escanearlas en masa mediante un sistema de OCR automatizado, pero no es tan sencillo encontrar de forma inequívoca los datos necesarios para realizar, por lo menos, el asiento contable. Además de eso, cada proveedor tiene su propio diseño de documento, con lo que incorporar a un nuevo proveedor requiere el trabajo adicional de crear una plantilla de escaneo nueva. En resumen: se ahorra trabajo, pero el negocio no es escalable.
Por estos motivos se puede observar un crecimiento constante, promovido principalmente por estas cadenas comerciales, del intercambio de documentos electrónicos, también llamado EDI. A diferencia de archivos PDF o correos electrónicos, los documentos intercambiados por EDI (pedidos, albaranes, facturas, niveles de stock, listas de precios, etc…) contienen los datos estructurados de tal manera que pueden ser leídos perfectamente por un sistema informático e importados a su base de datos automáticamente. La reducción de personal, de errores producidos por la introducción de datos manual y de tiempo transcurrido entre envío y recepción es enorme, lo que conlleva un abaratamiento extremadamente grande de la gestión de compras.
Este ahorro es tan significativo, que estas grandes superficies llegan a obligar a sus proveedores al envío de datos mediante EDI. Para ello definen uno o dos formatos de documento (EDIFACT, XML, CSV, etc…) y otras tantas vías de comunicación (e-mail, FTP, AS2, VANs, etc…) a las que tienen que ajustarse sus proveedores. Las grandes hacen valer su condición de cliente para presionar a las pequeñas en su propio beneficio.
Una vez que el problema interno de las grandes cadenas parece solucionado, ¿qué ocurre con sus proveedores? Éstos suelen ser PYMEs y no suelen contar con la capacidad técnica suficiente para generar cualquier tipo de documento EDI que les pidan sus clientes. Esto les supone, como poco, perder ventaja competitiva respecto a la competencia (el cliente escogerá siempre al proveedor que le origine el menor costo) y en otros casos significa perder al cliente completamente. Un proveedor que se desligue de su cadena de distribución está condenado al fracaso.
En ocasiones se afronta el problema de crear un nuevo formato EDI de manera muy poco razonable: se realiza un mapeo de datos directo desde la base de datos del sistema ERP al formato de salida (p.ej. una factura EDIFACT) mediante programación. Esta solución suele ser difícil de mantener y no es en absoluto escalable, puesto que para el nuevo formato del siguiente cliente hay que repetir casi todo el código, sin contar con el tiempo de implementación y test, que suele sobrepasar con mucho los planes iniciales. Debido al alto coste total de este enfoque, no parece ser una solución razonable.
El mismo fabricante de ERP puede proporcionar algunos formatos EDI específicos, pero no puede abarcar todos los del mercado. Además, este tipo de funciones de interfaces de datos no son una tarea central de ninguna aplicación de este tipo y siempre suponen un trabajo molesto pero necesario para satisfacer las peticiones de sus clientes.
La solución óptima para ellos es adquirir un software (p.ej. TransdatiX) que se integre fácilmente con su ERP y que proporcione módulos preconfigurados para la transformación de los documentos a los formatos de las grandes cadenas y facilite el envío y la recepción de éstos. Otra característica de un software así es el tipo de uso, que puede ser mediante instalación local, en la nube o pago por servicio.
Así como los motores de tracción mecánica necesitan un acoplamiento perfecto entre los engranajes para funcionar de forma óptima, la cadena de producción del proveedor tiene que estar ligada de manera síncrona a la cadena de distribución del cliente. A veces, la diferencia entre el éxito y el fracaso de una relación comercial es muy pequeña y depende de la fluidez de los datos entre ellas para que sus cadenas estén acopladas entre sí. Para ello se necesita algo relativamente pequeño: un eslabón.
RELACIONADO
by Albatian Ene. 9, 2017
by Albatian Abr. 19, 2013
by 4 Mayo 9, 2017
by 4 Sept. 18, 2017