DE SCADA A BI, EJEMPLOS

  • Actualizado: 31 agosto 2023
  • Publicado por primera vez: 4 junio 2013

de scada a bi

Cada uno de los sistemas de información enumerados en el post anterior disponen de su propio interfaz de usuario, capaz de proporcionar la información suficiente, en el ámbito en que se esté moviendo, para sacar conclusiones y tomar las acciones necesarias a nivel operativo en el día a día de la fábrica y del almacén.

Los sistemas SCADA, PLC y MES servirán a los responsables del seguimiento de cada sección productiva e incluso en los sistemas de almacenaje automatizado, para revisar los parámetros de funcionamiento de cada instalación, e interactuar con ella de forma amigable para variar esos parámetros. Permitirán detectar anomalías de funcionamiento y solucionarlas. Pero aquí ya nos vamos encontrando a los primeros demandantes de información: por ejemplo, el sistema de mantenimiento industrial necesita recoger los datos de funcionamiento de las máquinas, sean de la naturaleza que sea (tiempos de funcionamiento, piezas producidas, caudales de fluidos soportados) para llevar a cabo un tratamiento predictivo, programado, de las tareas de mantenimiento para evitar averías. Pero también el sistema de control de producción (ya sea el propio ERP el que lleve el control y seguimiento de las órdenes de fabricación o bien forme parte del propio sistema MES) está esperando información para conocer las cantidades de productos fabricadas, el tiempo empleado, los consumos de materiales y toda la información necesaria para la trazabilidad del producto.

 

Al mismo tiempo, en esa fabricación, así como en las tareas de almacén, están participando operarios que han realizado sus correspondientes ticadas en el sistema de control de presencia. Estas ticadas proporcionan información vital a varios sistemas: al control de producción para saber los tiempos de mano de obra empleados y por tanto parte del coste de producción, y análisis de productividades. Pero también el sistema de recursos humanos y nóminas puede necesitar esa información para poder preparar la nómina de los empleados, ya que debe tener en cuenta los tiempos de presencia, absentismo y horas extra.

Los sistemas automáticos de almacén están continuamente moviendo mercancía, ya sea para ubicarla, ya sea para extraerla para servir pedidos de clientes finales, pedidos para otras plantas de la empresa, o aprovisionamiento de materiales para las secciones productivas. Aunque estos sistemas también disponen de un completo interfaz de usuario para interactuar con ellos, lo normal es que actúen siguiendo “las órdenes” de un sistema global que suele ser el ERP, quien se encarga de indicarle la necesidad de ubicar mercancía y sobre todo la necesidad de extraer mercancía para dar servicio a la demanda producida.

 

Si te está resultando de interés este post, te gustará el Caso de Éxito de SGA, ebook gratis donde verás cómo se consiguieron ahorros de hasta 40% en costes  de expedición.

 

Al mismo tiempo, el ERP necesita conocer al detalle las existencias de mercancía en esos sistemas, pues de ello depende la toma de decisiones en muchos ámbitos. El stock es un dato muy demandado. Lo necesita el módulo de planificación de la producción y necesidades de materiales (MRP), también lo necesita la gestión comercial para poder establecer los niveles de servicio  a los pedidos de cliente que van entrando, y simultáneamente lo pueden estar requiriendo el sistema de movilidad para la preventa y el portal corporativo (en la entrada de pedidos web).

Como último eslabón de la cadena tenemos a los directivos de la empresa, a mayor o menor nivel de responsabilidad. Todos los detalles técnicos de la comunicación entre sistemas de información son irrelevantes para ellos. Lo que va a ver un responsable de costes versus ventas a la hora de analizar los márgenes obtenidos es que la rentabilidad del producto A no es la esperada. Verá que el coste de producción del mismo se ha disparado, ¿por qué? Profundizando en la información que, no lo olvidemos, debe estar perfectamente integrada, se tiene que poder llegar al más mínimo detalle para averiguar las causas, incluso a los propios datos del SCADA que nos están denunciando que en la máquina X los valores de ciertos parámetros indican que no está funcionando adecuadamente: un ajuste incorrecto de alguna de sus piezas nos provoca unas mermas de material excesivas, o un porcentaje de producto defectuoso fuera de lo normal, o un tiempo de producción muy mejorable.

Como este podríamos poner multitud de ejemplos, ya que cada perfil de directivo va a solicitar un modelo distinto de Cuadros de Mando, para la parte financiera, para el director comercial, para el director de fábrica, para el director de logística. Estamos hablando de la herramienta de Business Intelligence (BI), capaz de integrar y consolidar toda la información requerida, pero también de “desintegrarla” para profundizar en ella. Pero este sistema es un voraz demandante de información. Se nutre de una capa de “metadatos” que han sido diseñados y preparados previamente, bien consolidando diferentes fuentes de información con distintos orígenes y formatos (opción menos recomendable), o bien a partir de un único repositorio de información (opción deseable), normalmente mantenido por el ERP, el cual ya se ha “peleado” con los demás sistemas para poder alimentar ese repositorio.

Según todo lo anterior, conviene buscar una comunicación entre los distintos sistemas. Conceptualmente, se suele definir un esquema de trabajo tipo “cebolla” por las múltiples capas que lo componen, en forma de círculos concéntricos, en el cual colocamos cada sistema de los que disponemos en el círculo que le corresponde en función de a quién proporciona información y de quién la recibe. Ese intercambio de información puede ser mono direccional o bien bidireccional. Por ejemplo, las comunicaciones entre un sistema gestor de almacén automatizado y un ERP suele ser bidireccional, ya que ambos deben llevar a cabo acciones al recibir información del otro sistema. Pero una relación ente el control de presencia y el programa de nóminas, mayoritariamente, será mono direccional desde el primero de los sistemas al segundo.

SCADA

Obviamente, cuanto más semejantes sean entre sí a nivel tecnológico los sistemas, más sencillo es el intercambio de información. Si cada sistema funciona en una plataforma distinta y con formatos de base de datos diferentes, el protocolo se complica. Esto nos lleva a pensar que cuantos más sistemas nos proporcione el mismo proveedor de servicios informáticos, más integrados van a estar entre sí de forma natural aunque, por ejemplo, el ERP y el BPM no utilicen la misma tecnología. Y aunque no lo estuvieran, al menos minimizamos el número de interlocutores a la hora de definir los interfaces entre sistemas.

Los protocolos de comunicación entre sistemas más utilizados son:

  • Web services: constituyen actualmente el sistema más genérico e independiente de la plataforma tecnológica utilizada por los sistemas participantes, ya que respetando todos los formatos convenidos de los mensajes o solicitudes de información a enviar, el servidor se encarga del diálogo con el sistema que debe proporcionar el dato. Un ejemplo concreto sería cuando el portal web de pedidos o bien la aplicación de movilidad solicitan al ERP la actualización inmediata del stock disponible en almacén de ciertos artículos. Se realizaría la solicitud y respuesta a través de un web service.

Business Intelligence SCADA

  • Bases de datos: consiste en el intercambio de información a través de tablas de base de datos que hacen las veces de buzones de intercambio de mensajes, con unos formatos y contenidos consensuados entre ambos sistemas. La bases de datos pueden ser de igual o diferente tecnología en los dos sistemas, y la mensajería puede residir en una de ellas, en ambas o incluso en una tercera en “terreno neutral” habilitada para ello.
  • Ficheros: parte del mismo principio que el anterior, pero en lugar de tablas la información se intercambia sobre ficheros, en zonas compartidas de disco y visibles por ambos sistemas, o bien mediante la transferencia de dichos ficheros a través de ftp. Los formatos de fichero más usuales son txt, csv y xml.

Lo que tendremos que identificar en nuestro esquema “cebolla” es el conjunto de pares de sistemas que van a comunicarse entre sí, y qué interface o protocolo de comunicaciones van a emplear. Además, deberemos analizar:

  • Eventos que provocarán el envío de información de un sistema a otro, y con qué propósito: qué información debe ser enviada y en qué formato.

  •  Acciones que deberá llevar a cabo el sistema receptor al recibir la información.

  • Respuestas que deben ser enviada para la confirmación del tratamiento OK de la información recibida, o en su caso reporte de incidencias y protocolos para solucionarlas.

 

El esquema de la siguiente figura nos ilustra un ejemplo de comunicaciones entre un sistema SGA que gobierna un almacén automático, y un ERP. Está basado en un protocolo de mensajes que se envían el uno al otro, haciendo uso de unos “buzones” de envío y recepción implementados sobre tablas de base de datos, a la cual ambos sistemas pueden acceder, bien de forma nativa o bien a través de conectores tipo ODBC o Dblinks.

SCADA BI

Ejemplos de mensajes enviados por el SGA al ERP:

Emisor

Mensaje

SGA Gestión maestro de Artículos
SGA Palet en PIE
SGA Palet mercancía disponible
SGA Inserción cabecera pedido SGA
SGA Inserción línea de pedido SGA
SGA Modificación en línea de pedido
SGA Borrado línea de pedido
SGA Cierre de línea de pedido.
SGA Cierre de pedido.
SGA Anulación parcial de línea
SGA Cierre de Picking.
SGA Corrección stock
SGA Palet Extraído
SGA Palet servido por liberación total

 

Ejemplos de mensajes enviados por el ERP al SGA:

Emisor

Mensaje

ERP                                           Gestión maestro de Artículos
ERP                                           Inserción Cabecera Pedido
ERP                                           Inserción Línea pedido
ERP                                          Modificación línea de pedido
ERP                                          Borrado línea de pedido
ERP                                          Liberación de pedido

 

De todo lo expuesto en los párrafos anteriores, podemos concluir que las comunicaciones entre los distintos sistemas de información de nuestra empresa son un medio necesario para la buena marcha del negocio. La información es vital, por tanto disponer de ella con tiempos de respuesta rápidos, y con una buena calidad y presentación de la misma lo es aún más. Debemos tender para ello a la unificación de plataformas tecnológicas y capas lógicas de metadatos que sean fácilmente explotables. Descartemos los montones de listados con información variopinta y el punteo de los mismos para poder analizar nuestros indicadores.

 

EBOOK GRATIS: El Libro Blanco del SGA. todo lo que necesitas saber sobre el sistema de gestión de almacén