Aun recuerdo la sensación que me produjo, hace dos años, ver la primera valla publicitaria en la que únicamente se anunciaba una dirección web de un periódico exclusivamente on-line; por fin, Internet había cobrado la suficiente importancia como para que algún responsable de marketing creyera que no se estaba dirigiendo a un segmento excesivamente específico si anunciaba Internet en una valla exterior en plena calle.
Posiblemente el hecho de que la publicidad sobre portales (y webs en general) aparezca en todas partes y en cualquier momento, está llevando a mucha gente a una confusión importante y es pensar que Internet es solo WWW y que todo lo que se tiene que hacer en Internet pasa por un navegador.
Afortunadamente eso no es así y el éxito de Internet va más allá de las simples (y complejas) aplicaciones gráficas. Ni siquiera el comercio electrónico o el B2B (Business to Business) es un invento de Internet…
Hace casi 2 décadas que se están utilizando sistemas transaccionales de comercio electrónico entre empresas (B2B) basados en EDI (Electronic Data Interchange) y desde hace 5, con la aparición de Internet, esos mismos sistemas están cobrando más protagonismo que nunca al comenzarse a abrir camino en la pequeña y mediana empresa.
El modelo de negocio basado en Intercambio Electrónico Documental
Muchos son los sectores de la empresa española que llevan utilizando EDI desde hace ya bastantes años:
- Distribución comercial.
- Logística y transporte.
- Banca y Servicios Financieros.
- Industria.
- Administración Pública.
En todos ellos existe una necesidad básica y es la de automatizar algún tipo de transacción entre dos empresas. Dicha automatización debe realizarse entre dos sistemas o máquinas que en cada una de las dos (o más) empresas realizan funciones concretas de facturación, control de stocks, etc… El problema principal residía en que si el ordenador de la empresa 1 quería solicitar un pedido concreto de material (por ejemplo) al ordenador de la empresa 2 sin intervención humana, era necesario definir un formato de fichero o mensaje específico que definiera las características de dicho pedido. Los estándares EDI se encargaron de definir dichos formatos y de asegurar la interoperabilidad de sistemas de gestión propietarios a través de un único interfaz.
Imaginemos, por ejemplo, un gran centro comercial (con un stock presencial de productos muy importante) al que cada día acuden miles de consumidores y donde existen aspectos críticos como:
- La gestión de stock tiene que ser perfecta para mantener solamente el número mínimo imprescindible de producto y reducir costes de almacenaje.
- El tiempo de reposición de producto presencial tiene que ser mínimo.
- El control de facturación tiene que ligarse directamente al paso por caja del cliente de tal forma que coincida la necesidad de reposición con la facturación directa producida.
- Deben coordinarse adecuadamente los pedidos y facturación de la multitud (miles) de proveedores del centro comercial.
La única solución para controlar eficientemente todos estos factores pasa por la introducción de un software de gestión integrada que permita la interconexión, entre otros, del stock de almacén, del stock en tienda, de la lista de reposiciones almacén-tienda, del control de caja en tienda, del control de caja en almacén, de la contabilidad y del control y gestión de pedidos a los diferentes proveedores (posiblemente la tarea más crítica).
Si se requiere la automatización total para alcanzar la ECR (Efficient Consumer Response) en todo el proceso, será necesario que toda la comunicación con los proveedores (en otros casos, clientes) se encuentre libre de actuación humana. Para ello, EDI define toda una serie de formatos de mensajes, cada uno de los cuales es utilizado para «comunicar» algo de una empresa 1 a una empresa 2, permitiendo a los diferentes proveedores y al centro comercial adaptar sus sistemas de gestión (por ejemplo, SAP) a un único interfaz de comunicación definido de manera internacional. Algunos ejemplos de mensajes EDI estándar son:
Orden de transporte. Utilizado para la expedición y transporte de mercancías desde un origen a un destino. Por ejemplo, este mensaje es utilizado por empresas exportadoras / importadoras, para comunicar a las empresas de transporte la descripción del envío.
Estado del envío. Puede utilizarse como confirmación de recepción, albarán de entrega, etc.
Coste del flete. Para notificar los costos del flete o de la carga.
Uno de los grupos de estandarización EDI más utilizados es EDIFACT (Electronic Data Interchange For Administration, Commerce and Trade), pensado para su uso en logística y administración pública. Para el caso de los mensajes anteriores, por ejemplo, se han definido los formatos IFTMIN, IFTSTA y IFTFCC (http://www.unece.org/trade/untdid/welcome.htm).
Las empresas (por ejemplo, el gran centro comercial) receptoras de mensajes EDI, tienen que poder asegurar que todos los mensajes cumplen un formato predefinido para que no se produzcan errores de ningún tipo en los sistemas de gestión propios. Para asegurar este hecho, se recurre a los Centros de Compensación EDI (VANs – Value Added Networks o Redes de Valor Añadido), donde además de esta tarea son utilizados para guardar (típicamente por 5 años) copia de todos los mensajes que son enviados y recibidos.
Quizás ahora resulte más fácil entender que el B2B no es un invento de nuestros días sino que se lleva utilizando desde hace casi 2 décadas para gestionar pedidos y pagarlos, entre otros.
Las barreras del EDI
Sin embargo, el uso de EDI (antes de la aparición de Internet) presenta fuertes barreras económicas que hace su uso prohibitivo para las PYMEs, restándoles competitividad frente a los grandes gigantes. Algunas de estas barreras son:
Los costes de comunicación son elevados ya que generalmente es necesario la contratación de una línea punto a punto entre la empresa y la VAN.
El desarrollo de la interfaz es muy costosa dada la complejidad de las estructuras EDI. El hecho es especialmente crítico cuando se tiene que modificar alguna variable o característica del formato (en ese caso será necesario reprogramar la interfaz).
Muchas empresas grandes optan por utilizar formatos propietarios con lo que los proveedores están obligados a adoptar dichos formatos si quieren entrar en la cadena de negocio (por ejemplo, en las comunidades portuarias europeas, en 1999, el 60 % utilizaban formatos propietarios EDI) . El coste de implementación de varios formatos propietarios simultáneamente (si deciden trabajar con más de un cliente) es totalmente inalcanzable para la mayoría de PYMEs.
Con estos datos en la mano es sencillo entender el porqué solo utilizan EDI las grandes empresas.
Las aportaciones de Internet
La llegada de Internet ha revolucionado el mercado EDI en tres aspectos clave:
- Comunicaciones. Ya no es necesaria la utilización de líneas dedicadas para la transmisión de los mensajes (una con cada VAN o cliente final). Simplemente es necesario que las dos empresas tengan conexión a Internet y que puedan enviar y recibir por email, FTP, etc.
- Interfaz gráfico. En el caso de pequeñas empresas en las que no se enlazan directamente sistemas de gestión propios con interfaz EDI, se recurre a aplicaciones «independientes» que a partir de formularios construyen el mensaje EDI y lo envían y que son capaces de recibir los mensajes entrantes, procesarlos y mostrarlos de forma inteligible para el usuario. El principal problema de este tipo de aplicaciones EDI reside en que requieren de un mantenimiento constante para adaptar los formatos a los diferentes clientes y hacer frente a las evoluciones en las guías EDI (por ejemplo, EDIFACT genera dos versiones por año). Con Internet, es posible mantener la aplicación a través de web o si se requiere mayor velocidad, utilizar una aplicación local con actualización automática (smart update).
- XML. Pero la verdadera revolución ha aparecido con XML. No solo se ha introducido el concepto de EDIXML (con separación de campos por tags), sino que el simple envío del DTD y del XSL de un mensaje puede ser suficiente para que la aplicación cliente adopte un nuevo mensaje.
El interfaz gráfico de la aplicación EDI
Abandonemos, de momento, la gran empresa (por ejemplo un gran centro comercial) y centrémonos en una PYME que debe recibir 4 pedidos semanales, procesarlos y servirlos.
Está claro que si dicha empresa solo debe atender 4 pedidos semanales (obligatoriamente a través de EDI) no será rentable implementar un interfaz EDI para el sistema de gestión de la empresa porqué será más económico que la respuesta a los pedidos se haga manualmente a través de un formulario que alguien deberá rellenar para responder al mensaje recibido por parte del cliente.
Ilustrará lo dicho anteriormente un ejemplo real: en las comunidades portuarias (Port Community Systems – PCS) los transitarios son los responsables de la organización del transporte de la mercancía a nivel internacional entre un importador y un exportador. La mayoría de la información que se maneja es enviada y recibida a través de EDI y para ello disponen de interfaces EDI conectados directamente a sus sistemas propietarios de gestión y control. Sin embargo, en alguna ocasión (imaginemos una vez al mes), puede ser necesario realizar algún enlace de mercancía a través de avión. Para ello, será necesario solicitar disponibilidad de vuelo, de espacio, reservar plaza de mercancía, contratarla, etc., obviamente a a través de EDI (exclusivamente). Para el caso de Europa, lidera el mercado el sistema alemán Traxon que agrupa a más de 30 aerolíneas (Lufthansa, British Airways, Air France,…) y desde el cual es posible realizar cualquier transacción de reserva, petición de estatus, etc. utilizando el estándar CARGOIMP encapsulado en EDIFACT.
Volviendo al transitario que nos ocupaba, posiblemente este no tendrá implementado el interfaz EDI para transporte aéreo en su sistema de gestión a no ser que haga un uso intensivo de el. Sin embargo, sino se envía su solicitud de reserva de espacio por EDI, no va a poder transportar su carga. Con la llegada de Internet, se ha abierto un campo de posibilidades que permite a este tipo de empresas que hacen un uso «marginal» de EDI poder utilizar servicios de alto valor añadido a un coste bajo.
Comienzan a proliferar las empresas que ofrecen servicios EDIWEB en comunidades logísticas concretas. Esto significa que cualquier empresa con un mero navegador puede acceder a servicios EDI complejos a través de web.
Sin embargo, cabe no sobrevalorar el EDIWEB, porque solo ofrece una solución para casos muy concretos: PYMEs con bajo uso de EDI y automatización de mensajes sencilla.
El principal problema de EDIWEB reside en la dificultad de implementar formularios potentes y rápidos por la simple limitación de velocidad que tiene la red Internet hoy en día. Si se aspira a disponer de formularios para la introducción de complejos mensajes (por ejemplo un manifiesto de carga con cientos de campos) con validaciones muy pesadas deberá descartarse el uso de una aplicación remota basada en web. La solución, cada vez más utilizada, consiste en desarrollar una aplicación (cada vez más en JAVA nativo) que se comunique con el servidor de la VAN a través de Internet y que permite realizar acciones de interfaz gráfico de forma rápida.
La revolución XML
El XML, lenguaje extensible de etiquetas (extensible por que no es un formato prefijado como HTML), describe una clase de objetos de datos llamados documentos XML y describe parcialmente el comportamiento de los programas que los procesan.
Antes de proseguir conviene definir algunos conceptos básicos:
Fichero XML. Conteniendo la información que se quiere transmitir.
Fichero DTD. Conteniendo la forma en que se tiene que estructurar dicha información (estructura del mensaje XML).
Fichero XSL. Conteniendo las reglas de transformación de un mensaje XML a otro formato de fichero o de presentación (XML, HTML, PDF,…).
La revolución XML en el intercambio documental se fundamenta en lo siguiente:
- Nueva estructura de mensajes EDI. Ha aparecido una variante del EDI que es el EDIXML donde la identificación de campos se realiza a través de tags, permitiendo a las aplicaciones su procesamiento sencillo.
- Interpretación automatizada de formato. Trabajando con EDI clásico la descripción del formato para un tipo determinado de mensaje se realiza a través de la llamada «guía del mensaje». Dicha guía no es más que un documento de texto en el que se describe cada uno de los campos que componen el mensaje y sus características y que tiene que ser leído, entendido y codificado (programado) manualmente por alguien para disponer del interfaz con el sistema de gestión o de un formulario para «rellenar» los campos.
La novedad reside en que para definir un mensaje EDIXML solo es necesario disponer del DTD (indicando la estructura del mensaje), un XSL (indicando la forma en que deberá codificarse en pantalla o traducirse a un sistema de gestión determinado) y un XML de validaciones (indicando que validaciones deberán aplicarse para cada campo) que pueden ser interpretados automáticamente por una aplicación capaz de construir un formulario, realizar las validaciones, etc…
- Interoperabilidad. La construcción de una aplicación de procesamiento y gestión de EDIXML, desarrollada en XML permite un alto grado de interoperabilidad con plataformas y aplicaciones preparadas para soportar este estándar.
En definitiva, la ventaja del EDIXML frente al EDI convencional radica en su flexibilidad a la hora de realizar los frecuentes cambios de formato que sufren los mensajes de intercambio documental.
Conclusiones
Durante más de dos décadas muchas empresas disponen y utilizan sistemas transaccionales de comercio electrónico basados en el B2B a través de EDI. Los grandes centros comerciales, por ejemplo, solo admiten entre sus proveedores a aquellos que disponen de sistemas EDI capaces de atender sus pedidos electrónicamente a través de VANs (Redes de Valor Añadido). Nadie puede pensar que un gran establecimiento (con más de 100.000 millones de facturación anual) va a utilizar sistemas de solicitud de pedidos basados en páginas web ya que sería económicamente muy costoso (piénsese en un departamento de personas rellenando formularios).
Con Internet, la forma de trabajar de estas grandes empresas del comercio no va a variar porque incluso sus líneas de comunicación EDI no salen a Internet. La auténtica revolución reside en que la pequeña y mediana empresa ahora si que puede comerciar con los grandes establecimientos (B2B) a través de los servicios que pueda prestarle una VAN que disponga de aplicaciones EDIWEB.
Dichos servicios se basan en la posibilidad de enviar y recibir mensajes EDI, tanto a través de email y FTP (los dos sistemas más eficientes y rápidos) como de formularios en web (EDIWEB). Si una empresa necesita procesar y servir pedidos con una cierta asiduidad, lo más normal es que utilice, por ejemplo, sistemas basados en email para enviar los mensajes EDI y que acuda al web para conocer el «status» de los pedidos, envíos o simplemente de los pagos. Si por otro lado, la empresa es pequeña, no necesitará ni tener generadores EDI propios ya que podrá servir pedidos atendiendo directamente la solicitud a través de web (podrá enviar el mensaje de confirmación -APERAK- desde un formulario).
Con la llegada de XML, el panorama mejora aun más. El costoso problema de los cambios de estándar EDI que obliga a la realización de cambios en los generadores de documentos con una periodicidad más que elevada se soluciona con la introducción del EDIXML ya que con el procesamiento automático de los ficheros DTD (esquema del documento) y XSL (presentación/traducción), se puede actualizar la generación y recepción del mensaje que ha variado sin tener que reprogramar la aplicación.
El EDI está mucho más presente en nuestras vidas de lo que creemos y gracias a Internet y a XML, cada vez serán más las empresas, PYMEs, que se podrán apuntar a el y participar del comercio B2B.