Al navegar por este sitio web acepta el uso de cookies propias y de terceros para una mejor experiencia y servicio. Para más información, visite nuestra Política de Cookies. Aceptar

Un idioma común

01/08/2006

Una de las mayores revoluciones que han producido las tecnologías informáticas y más concretamente aquéllas destinadas a la comunicación ha sido el cambio en la forma de trabajar en la gestión empresarial. La llegada de sistemas de planificación de los recursos de la empresa (ERP), que permiten integrar las operaciones y la documentación de las distintas partes de la compañía; desde los recursos humanos al área financiera, han proporcionado el escenario perfecto para el gestor: establecer una relación directa entre lo que se hace, el cómo se hace, quién lo hace y qué resultados–operativos y financieros– tiene todo ello.

En la logística también ha habido revoluciones y cambios de paradigma, de maneras de trabajar y de pensar, a partir de la integración de servicios y sistemas informáticos. Así, el almacén automático se convierte en un arma poderosa cuando la tecnología es capaz de gestionarlo de la manera más optimizada, más inteligente; gracias al cálculo que permiten los ordenadores y a su prodigiosa memoria, capaz de guardar la información el tiempo que haga falta y de accedera ella con la mayor rapidez.

 

Gestión integrada

Otra revolución –esta vez no tecnológica, sino de la manera de entender la empresa: la que considera la logística y el almacén como integrantes del sistema muscular de la compañía– ha provocado que la gestión integrada estuviera felizmente condenada a integrar las estanterías, las paletas y las expediciones en su universo.

Puede que se dé por hecho que en los tiempos de Internet comunicar dos sistemas informáticos es sencillo. Pero la realidad es otra. Se trata de establecer un diálogo fluido e inteligente entre dos estructuras que en ocasiones ni siquiera hablan el mismo idioma. Todo un retopara el que se cuenta con buenas soluciones.

 

Sistemas asíncronos

El sistema de gestión de almacén que se ha escogido como ejemplo para este reportaje es el proporcionado por Mecalux en sus almacenes,el denominado SGA. Consiste en un paquete de software que puede ejecutarse en distintas plataformas y que es el encargado de gestionar, optimizar y controlar los movimientos de mercancías en el almacén o centro de distribución y su stock, así como la operativa necesaria en cada caso, como puede ser la administración del picking.

Para acometer sus operaciones, el SGA dispone de una base de datos, que actúa como si fuera la parte de su cerebro que se encarga de memorizar informaciones: dónde está determinada paleta, cuándo se puso allí y qué contiene, entre otra mucha información de todo tipo. La base también se ocupa de establecer relaciones precisas entre unos datos y otros, así como de enviarlos o recibirlos.

En el lado del cliente, por su parte, se puede encontrar otro cerebro informático que se ocupa de unificar las distintas ramas de la gestión de una empresa. Es lo que se denomina un ERP y también necesita una herramienta para recibir, enviar, albergar y relacionar entre sí los datos que maneja, es decir, otra base de datos. La primera cuestión que los informáticos han tenido que resolver en el enlace de las bases de datos entre cliente y proveedor ha sido cómo evitar que una vez integradas, y hablándose los dos sistemas, cuando uno se pare –por un error técnico, por ejemplo–, el otro quede bloqueado.

 

Comunicar sin éxito

"Si se utiliza un procedimiento síncrono –explica José Luis Vázquez, analista funcional y uno de los desarrolladores del software de Mecalux–uno de los sistemas se bloquea si el otro falla, porque se queda enviando información sin que haya respuesta"; es decir, se puede quedar eternamente intentando comunicarse sin éxito y sin poder continuar con su tarea porque no obtiene respuesta.

Para evitarlo, según comenta este experto,"utilizamos una comunicación asíncrona. Consiste en usar unos buzones virtuales en los que los dos sistemas dejan sus datos, ya sea para dar órdenes o para proporcionar información. Además de hacer eso, también miran en el buzón del otro y si hay datos disponibles, los leen. De esta forma, si uno de los dos no se comunica, porque haya un problema en las redes o esté caído (no funcione), no lo bloquea y se puede seguir trabajando de manerai ndependiente".

Otra forma de creae la comunicación asíncrona es dejar las órdenes que se han de pasar de una a otra base en una cola de espera; si la red funciona, los datos fluyen de una base a otra, pero si pasa algo con la comunicación o con el otro sistema, las órdenes se quedan almacenadas en la cola y se envían cuando se restablece la conexión.

 

La torre de Babel

La forma de comunicación (asíncrona) es el principio que rige la manera de comunicarse o,por utilizar un símil, el medio de comunicación que dos bases de datos eligen para entenderse.Pero eso es sólo el principio. Aún queda un segundo escollo que superar: "Lo más importante para nosotros es conocer con qué sistema de ERP y de base de datos trabaja el cliente. En nuestra herramienta trabajamos siempre con Oracle, pero el usuario puede usar otras".

Si la base de datos del cliente es también Oracle se puede recurrir a un método de comunicación propio de esta herramienta que se denomina dblink. Establecer una comunicación entre las bases de este modo es relativamente rápido y sencillo. Además, esta característica permite especificar si el paso de datos se podrá llevar a cabo de manera síncrona o asíncrona (en este caso, como ya se ha comentado anteriormente, se escoge la primera opción).

Por desgracia esta posibilidad no siempre se da, ya sea porque se utiliza un tipo de base de datos distinto o porque el ERP no facilita el uso de dblink en su certificaciòn. Ésta es como un sello que asegura que la empresa integradora o bien el fabricante del software de gestión se hará cargo de los problemas que puedan surgir con su sistema siempre y cuando no existan elementos externos o terceras manos que lo estén modificando.

 

Otras opciones

En el primer caso, si el cliente no usa Oracle (enla mayoría de los casos la alternativa más empleada es Microsoft SQL Server, aunque puede tratarse de otras herramientas como Postgre SQL, por ejemplo), se recurre a un mecanismo estándar que se ha desarrollado para poder hablar entre bases distintas. Consiste en enviar y recoger –siguiendo la metáfora de los buzones–ficheros de texto plano; es decir, sin especificaciones especiales sobre la fuente de letra, el formato de palabras en negrita o en cursiva, marcas de párrafo, etc.

La base de datos que envía una orden o devuelve un resultado (una información), elabora un fichero de texto y lo deja en un directorio de un servidor. O dicho de otra forma: depositan una carta con instrucciones en el buzón de una central de correos. La otra base, cuando mira en el buzón, y encuentra que tiene correspondencia, pasa a copiar el fichero, lo abre, lo lee y lo borra del servidor. De este modo, se consigue establecer una comunicación asíncrona y, a la vez, estándar para ambas bases. La siguiente cuestión,entonces, consiste en establecer el idioma en el que estarán escritas estas cartas: los ficheros.

 

Estandarizar el idioma

Trabajar con ficheros de texto plano es un paso en la estandarización del continente, pero hay que unificar también el contenido. Es necesario preparar las bases de datos para que sean capaces de hablar una lengua común y para ello primero se establecen las reglas y el vocabulario de esa lengua. En concreto, se trata de definir cómo se estructura la información en cada frase contenida en el fichero, a fin de que sea posible determinar qué parte de la sentencia dice qué.

Así, por ejemplo, se puede establecer que en cada línea de texto los primeros 20 caracteres sean de tipo numérico e indiquen el código de referencia del producto, los siguientes 18 corresponden al nombre del mismo y son alfanuméricos (cifras y letras), los próximos ocho indican el lugar de origen, etc.Para una orden de extracción de una paleta del almacén automático se pueden establecer otras reglas; por ejemplo, es posible determinar que los primeros 18 caracteres numéricos sean la referencia de producto, los siguientes seis de tipo alfanumérico la de la paleta, etc.

La generación de este código, de estas frases, sólo es una parte del proceso. Hay otra que consiste en indicar qué tipo de información es la que contiene el fichero para que el sistema que lo lee sepa qué reglas específicas tiene que aplicar; es decir, si, como en el ejemplo, debe leerlo como un maestro de artículos o como una orden de extracción de una paleta.

Para codificar esta información se utiliza el propio nombre del fichero de texto plano, así como su extensión, por lo que –para explicarlo visualmente–el sistema informático debe tener en cuenta cuál es tema de conversación entre las bases de datos y después leer, en consecuencia, los argumentos.que se genera con algunos clientes del ERP deSAP. Se trata de un escenario que se da con cierta frecuencia, por lo que merece ser comentado.

"SAP puede correr tanto bajo Oracle como SQL Server, por lo que se podría utilizar dblink o ficheros de texto plano. Pero a veces el usuario quiere que todo lo que hace esté certificado por SAP. Si tiene que hacerlo por su cuenta, contratando a consultores de la firma, le resulta costoso; pero si lo hacen por cualquiera de los dos sistemas nuestros, pierden la certificación SAP", explica José Luis Vázquez.

La soluciónes que los informáticos del proveedor se adapten al cliente y utilicen los llamados IDoc.Un IDoc es un tipo de fichero de texto plano pero que, a diferencia de los que se usan en otras ocasiones, tiene una estructura específica que ha sido definida por SAP. Se trata, sin duda, de la mejor solución a un escenario como éste, ya que aunque, como comenta José Luis Vázquez, "requierede un esfuerzo extra por nuestra parte y también de un desembolso del cliente; sin embargo, éste siempre opta por esta solución porque el coste es mucho menor que si hace la integración por su cuenta".

 

El esfuerzo del cliente

Ahora bien, el usuario no sólo debe hacer un esfuerzo económico. Sus informáticos o técnicos tienen que trabajar y participar en el proceso de integración para que ésta sea posible.El proceso requiere una fase previa. Una vez que se tiene el lay-out del centro de distribución (un plano en el que se especifican las zonas de almacenaje, su composición, etc.), los informáticos efectúan un análisis funcional –cuáles y cómo hay que mover las mercancías–;fase en la que resulta esencial aportar todos los datos posibles.

"Por ejemplo –explica JoséLuis Vázquez–, hay que saber si en un mismo almacén automático se quieren guardar alimentos y otros productos que puedan afectarles, como por ejemplo lejía, ya que no se podría colocar ésta en una posición superior en la estantería puesto que en caso de rotura del envase se perdería todo el alimento que estuviera por debajo".

También se define qué datos son necesarios que pasen del centro de distribución a la gestión de la empresa y viceversa, algo que se resuelve definiendo aspectos como por ejemplo:qué datos hay que trasmitir desde el departamento de administración para generar un albarán y qué información se debe pasar a ésta para contabilizar una salida de un pedido.

Una vez emprendido este estudio funcional, se provee al cliente de un documento en el que se especifica el tipo de comunicación que se utilizará entre las bases de datos, las tablas que se usarán, así como la estructura y las clases de ficheros –en caso de que se empleen– necesarios para la conexión de los sistemas. La buena noticia es que si se cuenta con un proveedor serio y profesional, éste podrá ayudar a la empresa cliente en todo el proceso, de tal forma que,al final, la operación del almacén encaje perfectamente, como una pieza en el puzzle de la gestión de la empresa.

______________________________________________________________________________________

DICCIONARIO PARA NO PERDERSE

 

Oracle: es un sistema de gestión de bases dedatos muy completo y difundido. Resulta establey puede trabajar en distintas plataformas.Ahora bien, tiene un precio alto.

Microsoft SQL Server: el igual que Oracle es unsistema de gestión de bases de datos. Es estable y compite con el líder, pero sólo está disponible para la plataforma Windows, por lo que de optar por el uso de Unix o Linux, por ejemplo, hay que inclinarse por otra alternativa.

ERP: siglas en inglés de Planificación de los Recursos Empresariales. Es un sistema que integra diversos módulos de herramientas informáticas con el objetivo de unificar toda la gestión de la empresa, centralizando la informaciónen una misma base de datos. Algunos ERP muy conocidos son SAP y PeopleSoft.

SAP: se suele denominar así al ERP desarrollado por la compañía del mismo nombre, aunque su denominación oficial como producto en su versión más actual es mySAP ERP. Aúna cuatro módulos:financiero, recursos humanos, operacionesy servicios corporativos.

Dblink: es una característica de las bases de datos de Oracle que permite establecer rápidamente un canal de comunicación para que puedan hablar entre ellas e intercambiarse datos rápida y fácilmente sin tener que traducirlos a otros formatos.

Fichero de texto plano: es un documento que sólo contiene texto sin formatear; es decir, sin códigos de tipo de letra, negritas, cursivas, párrafos,etc. Eliminando toda la información superflua se consigue que el fichero pueda ser leído por cualquier sistema.

IDoc: es un tipo de fichero de texto plano que tiene una estructura particular que ha sido desarrollada por SAP. Se utiliza para intercambiar información con otras bases de datos fuera del ERP conservando la certificación otorgada por SAP.

FTP: siglas en inglés de Protocolo de Transferencia de Ficheros. Es un estándar que permite dar órdenes para operar con ficheros a travésInternet (dejarlos en un servidor, copiarlos, moverlos, eliminarlos, modificarlos...).

____________________________________________________________________________

CASO ERP CON ORACLE

ESCENARIO: tanto el SGA del proveedor, como la base de datos del cliente son Oracle y no se han de utilizar sistemas específicos del ERP como los Idocs de SAP.

SOLUCIÓN: Se establece una comunicación entre ambas bases a través de bdlink, un proceso

sencillo que facilita bastante el trabajo, pero aún habrá mucho que hacer, como definir qué datos se han de pasar de un sistema a otro y todos los procesos implicados.

_____________________________________________________________________________

CASO ERP CON SQL SERVER U OTRA BASE DE DATOS

ESCENARIO: El proveedor tiene que enlazar su base de datos con la del cliente, no siendo

esta Oracle, ni teniendo que mantener la certificación SAP.

SOLUCIÓN: Para la comunicación entre la base de datos del usuario y la del proveedor se utiliza un sistema de ficheros de texto plano en el que se especifica toda la información necesaria de cara al entendimiento entre los dos sistemas.

_______________________________________________________________________________________

CINCO PREGUNTAS INELUDIBLES

El escenario ideal, a la hora de integrar la gestión del almacén con la del resto de la empresa, es que el proveedor de la solución automatizada sepa de antemano qué tipo de plataforma tiene el cliente para adecuar mejor sus soluciones. Cuando se reúna con su proveedor, es una buena idea proporcionarle algunos datos para que tanto el presupuesto como las estimaciones en los tiempos de puesta en marcha sean lo más precisos posible.

Las preguntas principales a las que debería responderse son:

- ¿Con qué tipo de base de datos trabaja la gestión de su empresa (Oracle,
SQL Server, etc).
- ¿Utiliza ERP?
- ¿Se trata de un ERP comercial y, si es así, cuál es? Por ejemplo, SAP.
- ¿Cuáles son las características de los productos que maneja? ¿Existen
artículos que no se deban mezclar o situar debajo de otros?
- ¿Cómo es su operativa de trabajo?