Autonomic Computing

El número de nodos de los sistemas distribuidos en muchos de sus campos de aplicación está creciendo de manera espectacular en los últimos años. Este crecimiento añade una gran complejidad a la gestión de los sistemas, y en muchos casos, es esta complejidad la que limita el crecimiento de las infraestructuras tecnológicos y no, como se podría pensar sus costes o sus consumos energéticos.

Cuando se habla de Autonomic Computing, concepto introducido en el año 2001 por IBM, se trata de diseñar sistemas que se autogestionen de manera que se reduzca la complejidad de su integración, gestión y operación. Los sistemas autónomos deben cumplir, como mínimo tres propiedades: la automatización, la capacidad de adaptación y la conciencia del entorno.

Aunque existen diferentes aproximaciones al problema, este tipo de sistemas suele basar su diseño en el sistema nervioso humano y en la implementación de bucles de control que permitan realizar ciclos de monitorización, análisis, planificación, ejecución y predicción cuyos objetivos sean la auto-protección, la auto-configuración, el auto-mantenimiento, la auto-optimización, etc. 

Aunque parece que este es el futuro de las grandes infraestructuras desplegadas, por ejemplo, por los proveedores Cloud más importantes, en el campo de la autonomía todavía queda mucho por avanzar, y en los centros de datos actuales no se puede hablar de Autonomic Computing más que a niveles muy básicos, siendo todavía necesaria mucha intervención humana en la mayor parte de los procesos. Poco a poco.

3PL y 4PL

Estas siglas se corresponden con Third Party Logistics y Fourth Party Logistics respectivamente, y el concepto que hay detrás es el de la externalización de los procesos logísticos de una compañía.

Si comenzamos por el término 3PL, este modelo se puede asociar directamente al de contratación de un operador logístico (un único operador, es decir, estrategia de Sole Sourcing) para el almacenaje, transporte y distribución de mercancías por poner sólo algunos ejemplos de los procesos típicos que se externalizan con este tipo de compañías. Normalmente se crea una nueva figura dentro de la organización, el Chief Resources Officer (CRO) cuyo trabajo consiste en gestionar el outsourcing en lugar de gestionar procesos logísticos propios.

Las ventajas de este tipo de modelo se pueden resumir en competitividad en costes, menor inversión que con logística propia (en muchos casos), posibilidad de presencia global y sin barreras geográficas e idiomáticas, propuesta de valor añadido para los clientes y obtención del respaldo de un especialista en logística. Por otro lado, las desventajas son las mismas que en casi todos los procesos de externalización: pérdida de control y riesgo de cautividad.

En la mayor parte del mundo este tipo de modelo ha sido ampliamente adoptado por las organizaciones que realizan actividades de comercio electrónico. Sin embargo, en el informe especial publicado recientemente por la consultora DBK, un estudio realizado a partir de 150 entrevistas con empresas españolas que hacen comercio electrónico se muestra que sólo el 4% tienen externalizada la gestión a operadores logísticos de este tipo.

Si el modelo 3PL es la asignatura pendiente, más lo es de momento el 4PL. El objetivo de 4PL es externalizar la cadena de suministro desde un punto de vista operativo, táctico y estratégico. Es decir, desde el transporte hasta la administración de indicadores, pasando por el almacenaje y la gestión de inventarios, pero también por el diseño de los procesos y la estrategia tecnológica. El 4PL es un integrador de la cadena de suministro: aconseja, diseña, construye y ejecuta soluciones globales.

El 4PL combina las capacidades de los 3PLs, de los proveedores de servicios tecnológicos y de los gestores de procesos de negocio. Tradicionalmente, los 3PLs se han centrado sólo en la parte operativa, y las consultoras en la parta estratégica. Y aquí ha surgido la polémica en los últimos tiempos, ¿quién debe asumir el papel de 4PL? ¿Un operador logístico que añada la parte de consultoría estratégica? ¿O una consultora que adopte también el papel de operador? 

Procesadores Itanium

Ya hemos comentado en entradas anteriores que los procesadores que podemos encontrar hoy en día en los PCs, portátiles y servidores, están diseñados para ejecutar instrucciones del repertorio x86 (que es CISC, aunque luego el front-end de los procesadores traduzca las instrucciones a microoperaciones de tipo RISC). Este es el estándar de facto en el que los dos grandes fabricantes de este segmento de mercado, Intel y AMD, basan todos sus diseños. O casi todos, porque Intel lanzó hace ya unos años un procesador que se basa en otro tipo de repertorio: el procesador Itanium diseñado para ejecutar instrucciones del repertorio IA-64.

Algunos habéis preguntado en ocasiones por este tipo de procesador ya que es relativamente habitual en  servidores críticos tanto en industria como en infraestructuras (en concreto del fabricante HP), así que intentaré explicar en qué se diferencia del resto de procesadores en pocas palabras. El Itanium es un procesador de tipo EPIC (Explicitly Parallel Instruction Computing) y en este tipo de diseños la relación entre el compilador y el hardware es mucho más estrecha de los habitual. Simplificando un poco, la idea es descargar al procesador de ciertas "responsabilidades" de manera que se encargue de ellas el compilador. De esta manera se puede simplificar el hardware que normalmente se dedica a funciones como la planificación dinámica de instrucciones y ejecución fuera de orden, la emisión superescalar, etc; y dedicar el área que se ahorra a añadir más unidades funcionales a la ruta de datos del procesador (capacidad de realizar operaciones). ¿Para qué? Para agrupar varias instrucciones en una más larga (con técnicas del tipo VLIW que ya hemos explicado) y que se puedan ejecutar en paralelo.

El compilador, además de encargarse de buscar las instrucciones que pueden empaquetarse juntas, y por lo tanto, ejecutarse en paralelo, también se encarga de proporcionar "pistas" (hints) al procesador para que pueda mejorar sus resultados en las predicciones de los saltos, para que las técnicas de prefetching sean más eficientes, etc.

A pesar de los continuos rumores acerca de este procesador y de su desaparición, parece que Intel y HP siguen apostando por él para servidores de HPC, por lo que los sistemas operativos orientados a servidores, tanto Windows como Linux, le siguen dando soporte. Próximamente se espera el lanzamiento de una nueva versión del procesador Itanium2, el Poulson, que ha generado bastantes expectativas en cuanto a su rendimiento.

Tolerancia a fallos y disponibilidad

En un sistema compuesto por  nodos de cómputo distribuidos la probabilidad de que se produzca un fallo aumenta, pero se debe garantizar que el sistema siga funcionando a pesar de ellos. Y minimizando las pérdidas de información y/o rendimiento, es decir, garantizando una calidad de servicio mínima a los usuarios.

Desde el punto de vista de la arquitectura, la principal herramienta que se puede utilizar para resolver este problema es la redundancia, es decir, incluir recursos adicionales a los estrictamente necesarios para la operación normal del sistema. La redundancia siempre incrementa el coste de la arquitectura, por lo que es importante elegir adecuadamente el tipo de recurso adicional que se va a utilizar.

Existen distintos tipos de redundancia, principalmente hardware, software y  de información. Y se puede aplicar a diferentes niveles (físico, sistema operativo, aplicación). Por ejemplo, en lo que se refiere al hardware, dos de los elementos críticos para conseguir la tolerancia a fallos que se suelen incluir en todos los diseños actuales son las SAI (Sistemas de Alimentación Ininterrumpida) para la alimentación y los RAID para el almacenamiento.

A veces el concepto de la tolerancia a fallos se confunde con el de disponibilidad, pero, aunque estén relacionados, no se refieren exactamente a lo mismo. La disponibilidad es la capacidad de un sistema de garantizar la continuidad en su operación ante cualquier situación. Los usuarios deben tener, la mayor parte del tiempo, la capacidad de acceder a la arquitectura para lanzar trabajos, realizar tareas de configuración y mantenimiento, recoger resultados, etc. Esta capacidad del sistema se suele cuantificar con el porcentaje de tiempo que ha estado disponible para los usuarios (se habla de alta disponibilidad cuando este porcentaje está en un valor a partir de los tres nueves, es decir, por encima de un 99.9%).

Obviamante debemos tener resuelta la tolerancia a fallos para conseguir sistemas de alta disponibilidad. Pero la continuidad en el servicio no sólo se ve amenazada por fallos o desastres, también existen discontinuidades en el servicio por paradas programadas, por ataques de denegación de servicio o por picos de demanda del servicio, sólo por poner algunos ejemplos.

SOA en entornos industriales (y II)

Volviendo a los entornos industriales, la pregunta que surge es la siguiente: ¿Tiene sentido incluir una capa de integración SOA que de forma estándar permitiera integrar y comunicar todos los dispositivos y sistemas para facilitar la gestión de entornos industriales?

La respuesta es afirmativa. De hecho ya existen varias iniciativas que corroboran la idoneidad de este planteamiento (SIRENA, SODA, SOCRADES, VINNOVA...) de las que hablaremos en futuras entradas.

En esta, resumimos y relacionamos los principales beneficios que se han obtenido al orientar el desarrollo de aplicaciones a servicios o a integrar diferentes sistemas a través de una arquitectura orientada a servicios.

1. Se facilita la integración de todos los dispositivos y sistemas ya que han sido desarrollados bajo una arquitectura SOA. En este sentido se puede hablar de una integración horizontal (entre dispositivos y sistemas existentes al mismo nivel, como entre dos PLC o dos SCADA) y una integración vertical (entre dispositivos y sistemas existentes a diferente nivel, como entre un SCADA y un ERP). En caso de que las aplicaciones no hayan sido desarrollados bajo SOA, la práctica común consiste en desarrollar un "envoltorio" basado en Web Services para estas aplicaciones monolíticas que puedan ofrecer sus datos como servicios y ser accesibles por otras aplicaciones.
2. Se proporciona una nueva generación de dispositivos y sistemas industriales “Plug&Play” en los que la integración sea una funcionalidad natural asociada a estos y en los que los cambios de configuración, parametrización y mantenimiento se realicen en tiempo real con alta disponibilidad de los sistemas.
3. Se reducen los costes de integración entre sistemas transaccionales y sistemas tiempo real.

Por último, en esta imagen (extraida del artículo "Towards an Architecture for Service-Oriented Process Monitoring and Control") se puede observar cómo la incorporación de un capa de servicios sobre todos los dispositivos y aplicaciones asociados al entorno industrial permite que todos ellos puedan integrarse fácilmente.

SOA en entornos industriales (I)

Los entornos industriales se caracterizan por la complejidad de los procesos de fabricación, por la heterogeneidad de dispositivos de campo instalados (PCL, RTU, Controladores), por la diversidad de sistemas de información implantados (SCADA, MES, LIMS) y por la escasa integración existente entre los diferentes sistemas.

La existencia de islas de información y del desaprovechamiento de los datos generados por todos estos sistemas para la toma de decisiones es una realidad asociada a la gestión industrial.

En el ámbito de los sistemas transaccionales (ERP, CRM, SCM...), también existía este problema, pero la inclusión de arquitecturas SOA ha permitido resolver buena parte de las barreras que se encontraban para realizar proyectos de integración de aplicaciones.

El concepto de SOA ha sido tratado previamente en anteriores entradas.

http://redindustria.blogspot.com/2008/09/qu-es-soa-i.html

http://redindustria.blogspot.com/2008/09/qu-es-soa-ii.html

http://redindustria.blogspot.com/2008/09/qu-es-soa-y-iii.html

De todas ellas podemos extraer las siguientes ideas principales:

• Service Oriented Architecture (SOA), es una nueva filosofía de diseño de aplicaciones que propone una alternativa a las tradicionales aplicaciones de negocio monolíticas basadas en objetos.

• SOA propone que los procesos de negocio no se traduzcan en aplicaciones clásicas (desarrolladas con códigos difícilmente integrables y reutilizables), sino que éstos llamen a los servicios que necesitan para obtener resultados.

• Los servicios deben estar débilmente acoplados y ser altamente interoperables, por lo que son muy importantes los protocolos que definen formalmente estos servicios y que permiten la comunicación con ellos y entre ellos.

• Los estándares que han estado relacionados con SOA desde los comienzos han sido XML, SOAP y WSDL. Es decir, los que proporcionan la base para los Web Services. La definición más extendida de un Web Service es "función pública, encapsulada y débilmente acoplada ofrecida a través de protocolos estándar".

• Por tanto, los Web Services son componentes accesibles desde diferentes aplicaciones, y que al estar basados en protocolos estándares, facilitan mucho la reutilización.

Lean Six Sigma

Como hemos discutido en entradas anteriores, las técnicas Lean Manufacturing tienen como objetivo último la reducción de lo que no aporta valor en los procesos de producción (muda). Estas técnicas suelen involucrar a todo el personal en su implementación, se basan en muchos casos en la utilización de grupos de mejora y se nutren en gran medida de la creatividad y del sentido común. Por el contrario, las técnicas basadas en Six Sigma (en concreto, en DMAIC, que es el enfoque incremental para la mejora continua) persiguen reducir la variabilidad de los procesos de producción, suelen involucrar sólo a un grupo de personas, y estas personas tienen que recibir formación muy específica en Six Sigma y en todas las herramientas estadísticas asociadas.

En principio, combinar en un proceso de mejora herramientas y metodologías de estos "dos mundos" que parecen tan dispares, no parece tarea sencilla. Pero, si lo pensamos bien, es más fácil reducir la variabilidad de lotes pequeños (muy asociados a las técnicas Lean), y es más fácil eliminar lo que no aporta valor en procesos de poca variabilidad (controlados). Por eso es tan interesante combinar las dos metodologías. 

Además, hay que tener en cuenta que las técnicas Six Sigma ayudan a reducir costes al productor mediante el control de sus procesos y la reducción de producción defectuosa. Pero no se preocupa de aportar valor al cliente. Por el contrario, Lean aporta valor al cliente minimizando todo aquello que es innecesario, pero no se preocupa por la variabilidad de los procesos ya que se estima que los defectos de producción son sólo 1/8 de las fuentes de muda en la producción.

Lean Six Sigma intenta aportar valor al cliente ayudando al productor a controlar sus procesos y a reducir sus costes, por lo que podría ser la solución perfecta en muchas plantas. Sin embargo esta metodología todavía está muy poco extendida, especialmente en España. En los proyectos que se están llevando a cabo, se utiliza la metodología DMAIC típica de Six Sigma pero contando en todo momento con los objetivos y las herramientas propios de Lean.


Muchos de estos proyectos no están teniendo todo el éxito esperado por falta de formación para el personal, falta de comunicación, liderazgo y una correcta gestión del cambio y sobre todo, por una mala definición del alcance del proyecto de mejora. Pero esperemos que estas barreras se vayan superando con el tiempo para poder obtener los beneficios esperados con esta herramienta tan potente.

¿Cómo es por dentro mi smartphone? (y II)

Los retos actuales en el diseño de SoC para smartphones son superar la barrera de 1GHz en la frecuencia de funcionamiento de los procesadores y pasar a arquitecturas multinúcleo (comenzando por las dual core igual que ha ocurrido en los PCs). En esta dirección hay que destacar el diseño del NVidia Tegra 2 que incorporan los "superphones" de Motorola, LG y Samsung. Está basado también en un diseño ARM, pero en lugar del ARM11 habitual, incorpora dos ARM Cortex A9. Intel está trabajando también en un diseño basado en su procesador Atom que consuma menos potencia y se pueda incorporar en teléfonos móviles, aunque todavía no hay ninguna explotación comercial de este nuevo procesador.

Otros retos abiertos en la actualidad son la incorporación de displays 3D a los teléfonos y la mejora del tratamiento de imágenes y vídeo, pero estos tienen más que ver con el diseño de la GPU.

La evolución de los procesadores gráficos para móviles en los últimos años ha sido incluso más rápida que la de las GPUs para tarjeta gráfica de PC. Esto es debido a la importancia que ha adquirido la calidad de los gráficos en este tipo de dispositivos al ser la interfaz con el usuario del sistema operativo renderizada por la GPU (siendo en muchos casos 3D, excepto en Windows Mobile). La arquitectura de las GPUs móviles es muy variada, y bastante diferente de la de las GPUs para tarjeta gráfica: están alimentadas por baterías, sirven a una CPU con repertorio de instrucciones limitado, su frecuencia de funcionamiento es baja, tienen poca capacidad de memoria y escaso ancho de banda en la conexión, etc.

Por este motivo suelen trabajar en tiles de 16x16 píxeles de manera que no hacen el renderizado de la imagen completa de una pasada, sino que lo van haciendo por partes. Además utilizan técnicas de compresión de datos para minimizar las necesidades de ancho de banda con memoria.

¿Cómo es por dentro mi smartphone? (I)

Cada vez encontramos más plataformas móviles en los entornos industriales y de infraestructuras, tanto para realizar tareas de visualización como de control. Pero en la mayor parte de los casos no nos paramos a pensar en las diferencias que existen entre las arquitecturas de nuestros PCs de sobremesa o portátiles, y las de nuestros teléfonos móviles, a los que empezamos a exigir rendimientos similares.

Entendemos por smartphone (aunque no hay una definición estándar) el teléfono móvil que separa claramente el hardware de acceso a la red de telecomunicaciones del hardware empleado para la interfaz con el usuario y la ejecución de aplicaciones. Normalmente esta separación implica que el smartphone incorpora dos procesadores, siendo el más complejo el destinado a la ejecución de aplicaciones, que cada día son más variadas y más similares a las que se ejecutan en un PC.

Pero este hardware para la interfaz con el usuario y la ejecución de aplicaciones no sólo incluye una CPU para la ejecución de aplicaciones, normalmente también incorpora una memoria Flash (SLC o NAND), una memoria RAM (Mobile SDRAM o mobile DDR), una GPU, una unidad para la gestión eficiente de la energía, un codec de audio y el hardware para la conectividad del dispositivo (wifi, bluetooth, etc).

En la memoria Flash se suelen cargar el sector de inicio, el núcleo del SO, los drivers, el sistema de archivos y las aplicaciones. Esta memoria es más lenta que una RAM, pero al ser memoria no volátil no hace falta una batería extra como ocurre con las pocket PC y otros dispositivos móviles. Sin embargo la memoria RAM se utiliza como memoria de ejecución, por lo tanto almacena la pila y el montón.

Las soluciones que incorporan todos los teléfonos actuales se basan en diseños de tipo SoC (System on Chip) específicos para teléfonos móviles, que incorporan todo este hardware con el menor consumo de potencia posible. Existen distintos fabricantes, pero todos ellos han optado por utilizar como CPU el procesador ARM, de tipo RISC y similar al MIPS o al PowerPC, pero con un consumo de potencia mucho menor. Este es el procesador que incorporan los iPhone, los Nokia, los Toshiba, los HTC, etc.

Tecnologías verdes en informática industrial

Los términos Green IT o huella de carbono son cada vez más habituales en nuestro vocabulario debido a la preocupación actual por el cambio climático.

El primero se refiere a todas aquellas tecnologías que permiten reducir el consumo de energía y/o mejorar la eficiencia en su consumo. De esta manera se consigue minimizar el impacto ambiental de los equipos de trabajo, grandes servidores y datacenters de una compañía, además de mejorar su viabilidad económica reduciendo los gastos en suministros (electricidad, iluminación, aire acondicionado). Es decir, el objetivo de estas tecnologías es reducir la huella de carbono y al mismo tiempo, permitir ahorros en costes a las compañías, haciendo que sean más eficientes en la utilización de los recursos energéticos.

La huella de carbono se define como la cantidad de Gases de Efecto Invernadero (GEI) emitidos a la atmósfera como resultado de las actividades humanas (producción, comercio de bienes y servicios, etc). Normalmente se mide como emisiones directas de toneladas de dióxido de carbono.

La eficiencia energética de los equipos informáticos actuales suele cuantificarse con métricas del tipo número de operaciones/watio, y esta información puede obtenerse directamente de los fabricantes o utilizando para ello algún tipo de benchmark específico (como el SPECpower para servidores).

La preocupación por la eficiencia energética ha hecho que se cree una lista Green500 que ordene los supercomputadores en función de su eficiencia energética igual que la lista Top500 los ordena en función de su potencia de cómputo. En este caso concreto la métrica de eficiencia escogida son los MFLOPS/watio (siendo los MFLOPS millones de operaciones en coma flotante).

Por desgracia, en el campo de la informática industrial las tecnologías verdes todavía no están muy extendidas, por lo menos no como lo están en la informática generalista o en las áreas de logística y transporte. Su introducción está siendo muy lenta, así como la del manejo de métricas de eficiencia energética. Y sin embargo es un aspecto esencial para la consecución de los objetivos corporativos tanto a corto como largo plazo, por no hablar de la responsabilidad que todos tenemos sobre un ya dañado medio ambiente, por lo que es obligado tomar conciencia de la importancia de este tema y comenzar a proponer iniciativas específicas del sector, aunque sea poco a poco.

Paquetes de simulación: software COTS

Los paquetes y lenguajes de simulación presentan una serie de ventajas obvias frente a los lenguajes de programación de propósito general por tratarse de un software específico para simulación.

Los paquetes de simulación, también llamados en ocasiones paquetes COTS (Commercial Of The Shelf packages) proporcionan de manera automática la mayor parte de las funcionalidades necesarias para el modelado y simulación del sistema, así como para la interpretación de los resultados obtenidos. Esto reduce mucho el tiempo de desarrollo del proyecto y sus costes.

Normalmente, los modelos que se manejan con estos paquetes suelen ser más fáciles de crear, modificar y mantener. Además, la detección y corrección de errores suele ser muy sencilla, en algunos casos incluso automática. Sin embargo, nada es perfecto, y este tipo de software presenta otras desventajas:

• Hay que aprender explícitamente a utilizarlos.
• La ejecución de los modelos que producen suele ser más lenta que cuando se programan con lenguajes de propósito general, casi no permiten optimizaciones.
• Suele ser más difícil la integración con otras aplicaciones o rutinas, por lo que se pierde en flexibilidad dentro de los proyectos.
• Las limitaciones vienen impuestas por el propio producto independientemente de la habilidad de los modeladores y desarrolladores implicados.

Aún así, en el sector de la industria y de la logística, estos paquetes suelen ser la opción más utilizada. Quizás los más extendidos sean Arena, ProModel, ModSim y Extend, aunque hay otros mucho más específicos por sector.

Ciberseguridad: lecturas sobre la situación actual

Como sabéis algunos de vosotros, hace un par de años que colaboro con la organización del congreso ICCC (International Conference on CyberConflict) que se celebra en Tallín y que tiene su origen en el estupendo trabajo que realizan en el CCDCOE (Cooperative Cyber Defence Centre Of Excellence) allí ubicado.

Aquí os dejo un enlace muy interesante en el que podéis empezar a leer acerca de estos temas para conocer la situación actual desde el punto de vista de la seguridad nacional, ya que a veces me preguntáis acerca de ciberseguridad, ciberguerra, ciberterrorimo, etc; y me parece una muy buena manera de introduciros en el tema:

http://www.ieee.es/publicaciones/cuadernos-estrategia/cuadernos/Cuaderno_149.html

Si lo que os interesa es saber cómo está la situación en lo que se refiere a protección de infraestructuras de información críticas (más bien desde el punto de vista de la industria, aunque en el caso de infraestructuras críticas, sabéis que tiene mucho que ver con la seguridad nacional), ya os he dejado en otras ocasiones enlaces al CNPIC en España y sobre todo, a la página web del DHS en EEUU (donde podéis encontrar hoy por hoy los recursos más prácticos).

Hoy os quiero mencionar un informe reciente de la Comisión Europea en el que se resumen los logros conseguidos hasta el momento en este campo y los retos que todavía están por resolver:

http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:52011DC0163:ES:HTML

Como podréis ver, todavía queda mucho por hacer...

Novedades en seguridad RFID

Este tipo de tecnología se ha ido incorporando en los últimos tiempos a pasaportes, tarjetas de crédito, identificaciones de empleados, etc. Esto implica que las etiquetas RFID contienen información como el nombre completo de una persona, su fecha de nacimiento, sus huellas dactilares o fotografías.

Ya hemos explicado en entradas anteriores cómo funciona la tecnología RFID básica, y como podéis imaginar, este tipo de funcionamiento pone en peligro cualquier información sensible que se incluya en las etiquetas.

La mayor parte de los proyectos encaminados a mejorar la seguridad de estos dispositivos estudian dos aspectos: que los usuarios sepan cuándo un lector está accediendo a la información almacenada en su etiqueta y que los usuarios puedan controlar cuándo esta información está accesible.

En cuanto al primer aspecto, se están explorando diferentes alternativas. Las más habituales, que la etiqueta se encienda, vibre o emita un sonido cuando está cerca de un lector RFID (interrogador) o cuando es accedida por uno. Es decir, existe la posibilidad de utilizar métodos preventivos o reactivos.

En el caso del segundo aspecto, quizás mucho más útil, existen diferentes soluciones. Por ejemplo, se puede diseñar la etiqueta para que sea abierta o cerrada (haciendo así la información accesible o inaccesible) por su propietario, por ejemplo con un botón o con una zona de la etiqueta que sea deslizante. También se ha propuesto que las etiquetas sean sensibles a la luz, de manera que no puedan ser leídas si se encuentran dentro de un bolso o bolsillo. O que la etiqueta sólo se active cuando se ponga en contacto físico con un lector autorizado.

Como ocurre casi siempre que hablamos de seguridad, todas estas soluciones son válidas y no aumentan excesivamente el tamaño de las etiquetas, pero encarecen la tecnología. Por este motivo se plantea que las etiquetas se dividan en dos: aquellas que no necesitan protección porque no contienen información sensible, y las que sí la necesitan.

Aún así, el desconocimiento de los riesgos que se corren, especialmente en ciertos entornos, hace que todavía no se hayan extendido las soluciones propuestas hasta el momento.

Cómo calcular el ROI de la implantación de una solución MES (y II)

Por nuestra experiencia en este tipo de proyectos, se utilizan varios enfoques para estimar y/o calcular la relación coste/beneficios obtenidos en la implantación de soluciones MES (cuando se decide que compensa hacerlo):

1. Utilizar una estimación cualitativa de los beneficios obtenidos y el TCO como indicador del coste.
2. Utilizar una estimación cualitativa de los beneficios obtenidos, pero sistemática. Para ello se suele elaborar un checklist que permita determinar en qué grado se han cumplido los objetivos iniciales del proyecto MES. Por ejemplo: reducir la variabilidad del proceso de esterilización, aumentar el productividad de la línea de empaquetado, etc. Y esto se contrasta con el TCO del proyecto.
3. Utilizar una estimación cuantitativa de los beneficios obtenidos con el proyecto. Para ello es necesario definir unos KPIs relacionados con el rendimiento del área involucrada y medirlos antes y después del proyecto para calcular la mejora obtenida. Por ejemplo: la desviación típica se puede utilizar como métrica de la variabilidad del proceso de esterilización, el OEE como métrica de la productividad de la línea de empaquetado, etc. Y se puede estimar si gracias a la implantación de la solución MES estas magnitudes han mejorado y cuánto han mejorado. De nuevo se suele utilizar el TCO como métrica para los costes.
   

Normalmente estos son los enfoques utilizados, pero ninguno de ellos permite realizar un cálculo del ROI. Para llegar a dar una cifra concreta del ROI sería necesario pasar, en cualquiera de los dos últimos enfoques, de la estimación de los beneficios obtenidos (sea cualitativa o cuantitativa) a cifras económicas. Es decir, traducir las mejoras realizadas a euros.

Para ello es necesario recurrir a grupos de expertos, a datos históricos o de otras empresas del sector, a simulaciones, etc. En este artículo tenéis algunas sugerencias:

http://media.roiinstitute.net/articles/pdf/2007/09/08/Converting_Data_to_Monetary_Value.pdf

Aunque ésta parte es la más complicada del cálculo del ROI y es la que realmente aportará valor a vuestros clientes, que deben estar siempre involucrados en esta parte del proyecto ya que suelen ser los que mejor conocen sus procesos.

Cómo calcular el ROI de la implantación de una solución MES (I)

Esta es la eterna pregunta en este tipo de proyectos, pero también en la implantación de otro tipo de soluciones tecnológicas.

El ROI o Return On Investment se puede calcular de varias formas, aunque la más habitual es dividir las ganancias que se obtienen con la implantación de la solución (beneficios-costes) entre los costes de esta implantación, y multiplicar este cociente por 100 darlo como un porcentaje. Se suele realizar una previsión del ROI al inicio de los proyectos para tomar decisiones en las fases de planificación, y luego una medida del ROI (como mínimo, lo recomendable en realidad es realizar varias en diferentes momentos temporales, por ejemplo, a los tres meses, a los seis y al año) cuando el proyecto ya ha finalizado para comprobar si se han cumplido los objetivos de la implantación.

Hay que ser muy cuidadoso con estas previsiones y medidas porque algunos casos prácticos han demostrado que los cálculos de ROI pueden suponer en proyectos importantes entre un 5 y un 10% de los costes totales del proyecto. Por lo tanto, se tiene que estar seguro de que esta información es necesaria y que reporta algún tipo de beneficio directo a la organización. De hecho, en algunos casos se cuestiona "el ROI de calcular el ROI".

En el caso de una solución MES, la determinación de los costes del proyecto de implantación no debería ser muy complicada (ya hemos hablado en entradas anteriores del TCO o Total Cost of Ownership), lo complicado suele ser medir los beneficios que se han obtenido con la solución escogida.

Estos beneficios suelen provenir de dos tipos de factores: aumentos en la producción, ventas, márgenes, etc o ahorros en costes. La organización MESA Internacional creó el año pasado un grupo de trabajo para intentar crear un libro guía que permita calcular el ROI de la implantación de soluciones MES, aunque todavía no hay resultados disponibles.

Tenéis información sobre este grupo de trabajo en este enlace:

http://www.mesa.org/en/modelstrategicinitiatives/returnoninvestment.asp

Y los sitios web con mejor información acerca de los cálculos de ROI son:

http://www.roiinstitute.net/
(aquí téneis el artículo ROI Basics en el que se explica la metodología completa para su cálculo)

http://www.gartner.com/technology/home.jsp
(sobre todo para que podáis ver casos prácticos)

ISA95.01: Conceptos básicos

Ya hemos hablado en entradas anteriores del estándar ISA95 para la integración de sistemas ERP con sistemas MES. Si recordáis, la parte 1 de este estándar define la terminología y el modelo de objetos que permite integrar estos dos tipos de aplicaciones, definiendo la información que deben intercambiarse.

Para ello, el estándar ISA en su primera parte, distingue entre el dominio transaccional y el de tiempo real, definiendo claramente las funciones que recaen sobre el ERP como sistema de información de negocio y las que recaen sobre el sistema MES como sistema de información en planta.

A continuación, se seleccionan aquellas funcionalidades que son críticas para la integración entre ambos tipos de sistemas y se definen los flujos de información necesarios entre ellas para que se produzca esta integración. En el modelo propuesto por ISA, estas funciones principales que deben integrarse unas con otras son:

• Order processing.
• Production scheduling.
• Production control.
• Material and energy control.
• Procurement.
• Quality assurance.
• Product inventory control.
• Product cost accounting.
• Product shipping administration.
• Maintenance management.

Los flujos de información identificados entre estos módulos se clasifican en diferentes categorías. En principio son tres:

• Production capability (qué recursos tenemos disponibles para la producción).
• Product definition information (cómo se hacen los productos).
• Production information (qué resultados estamos obteniendo y cómo de bien lo estamos haciendo).

Esta última categoría resulta ser demasiado extensa, por lo que al traducir estos tres tipos de información a un modelo de objetos, se acaba desdoblando en dos: scheduling y performance.

Lo último que podemos encontrar en esta primera parte del estándar son los modelos UML para estas cuatro clases de información (no se detallan más los modelos de objetos, el nivel más bajo se deja para la segunda parte del estándar).

Los cuatro modelos propuestos tienen estructuras similares, definiendo los datos que deben ser intercambiados en la integración siempre como una colección de información acerca de personal, equipos, material y segmentos de proceso.

Mejores prácticas para grupos de mejora (y II)

4. El jefe de grupo debe decidir cuándo convocar las sesiones de trabajo y es muy importante que antes de cada una de ellas se defina con una agenda su objetivo, las personas convocadas, el material que debe revisarse antes o durante la sesión, etc. La duración de cualquier sesión no debería superar las dos horas.

5. La participación en el grupo debe primarse/recompensarse de alguna manera. El reconocimiento a las aportaciones realizadas por los miembros del grupo debe ser, como mínimo, personal, pero a ser posible, económico. De esta manera la motivación será mucho mayor.

6. El resultado más importante de los grupos de mejora suele ser un plan de acción que recoja las acciones de mejora que deben llevarse a cabo con sus responsables asociados, así como las fechas límite para su realización. Para realizar el seguimiento de este plan de acción y evaluar los resultados obtenidos, suele ser recomendable la figura del Gestor del Proyecto en Planta como representante del grupo en el día a día de la fábrica. Su misión principal es el seguimiento y verificación en planta del grado de avance de las acciones de mejora establecidas, de manera que se hace reponsable de un programa de observación/evaluación del que se pueden extraer conclusiones muy valiosas para el proyecto de mejora.

Mejores prácticas para grupos de mejora (I)

Un grupo de mejora continua es el conjunto de personas responsables de la elección, definición, priorización y supervisión/evaluación de las acciones de mejora que se deben llevar a cabo en procesos de mejora continua. Puede que se encarguen de su aplicación directa o no, pero lo que está claro es que un proyecto de mejora continua nunca será responsabilidad de una única persona.

En un curso que realizamos la semana pasada llegamos a una serie de conclusiones acerca del trabajo con estos grupos.

1. Los grupos de mejora pueden tener diferentes composiciones atendiendo a:

• Las áreas que están involucradas en la mejora (homogéneo o multidisciplinar).
• Su temporalidad (permanente o no).
• El tipo de agentes que intervienen (externos o internos).
• La naturaleza de las técnicas de mejora que se van a utilizar (Lean, ingeniería forense, etc).

Pero sea cual sea el tipo de grupo, cuando se trabaja con ellos hay que tener en cuenta que van a pasar por estas fases (Tuckman´s Group Development Model, 1965):

• Forming (fase inicial de formación del grupo y conocimiento de sus miembros entre sí).
• Storming (fase de dinámica de trabajo poco ordenada, el grupo debe encontrar la manera de trabajar eficientemente, de momento no se ha estblecido una manera estándar de trabajar conjuntamente).
• Norming (fase en la que se establecen las normas, formales o informales, que permiten que el grupo desarrolle su labor).
• Performing (fase de dinámica de trabajo normalizada, el grupo trabaja al 100% de su potencial).
• Renewing (fase de renovación de los miembros del grupo).

2. Además de tener en cuenta estas fases o etapas, también se debe observar si el jefe del grupo tiene las capacidades adecuadas de comunicación, liderazgo, gestión del cambio y toma de decisiones; ya que será imprescindible que así sea para fomentar un correcto trabajo en equipo.

3. El jefe de grupo debe tener siempre presente la misión del grupo de mejora y su composición para formentar la participación adecuada de todos los miembros del grupo. Para que las sesiones sean productivas, los grupos no deberían superar las 9 ó 10 personas y debería distinguirse entre grupos orientados a instalaciones/equipos y grupos orientados a proceso.

Managed Security Service Provider

Muchas organizaciones y pequeñas y medianas empresas no pueden permitirse la creación y mantenimiento de departamentos de seguridad de la información. Por este motivo desde el año 2000 se maneja el concepto de MSSP (Managed Security Service Provider), un proveedor de servicios que en este caso no se encarga de proporcionar el acceso a la red (como el ISP ó Internet Service Provider) sino de proporcionar servicios de seguridad gestionados.

De esta forma, mediante out-sourcing, muchas empresas que de otra manera no podrían permitírselo, pueden acceder a servicios de control de seguridad para sus redes, servidores y bases de datos, de análisis y mantenimiento de la seguridad y de consultoría de seguridad. Las empresas que se han convertido en MSSPs en estos años suelen ofrecer servicios de firewall gestionado, VPN gestionada, IDS (sistema de detección de intrusos) gestionado, antivirus gestionado, filtrado gestionado, análisis de vulnerabilidades gestionada, etc.

La utilización cada vez más frecuente de sistemas de tipo Cloud Computing, especialmente en su modalidad de Software as a Service (SaaS), está haciendo que las organizaciones y empresas sean más receptivas a la subcontratación de ciertos servicios críticos para su correcto funcionamiento. El concepto de Security as a Service ya ha comenzado a extenderese aunque todavía plantea ciertos problemas prácticos que hay que resolver, como por ejemplo, la dificultad de obtener ciertas certificaciones de seguridad (como puedan ser las ISO/IEC 27001) cuando los servicios de seguridad están externalizados.

PYMES y nuevas tecnologías

Las TIC son una de las herramientas más valiosas con las que cuentan las empresas a la hora de adaptarse los actuales mercados, cambiantes y competitivos. En la mayoría de los casos las empresas intuyen los desafíos y ventajas que las TIC representan, pero cada empresa, en función de la situación geográfica, la actividad y el tamaño que tenga, presentará necesidades y/o carencias diferentes, que requerirán, por tanto, soluciones también diferentes. Y modelos de implantación e integración diferentes. Del mismo modo, cada empresa, presenta una realidad de partida, que deberá tomarse en cuenta a la hora de tomar decisiones.

En los últimos tiempos se nos están demandando desde diferentes foros, conferencias y cursos relacionados con la innovación tecnológica, sobre todo, orientados a la PYME. Desde nuestro punto de vista, esta innovación trae consigo una serie de ventajas como:

• Mejora de la competitividad.
• Mejora de la productividad.
• Reducción de costes.
• Apertura de nuevos mercados.
• Mejora la relación con clientes y proveedores.

Y así intentamos transmitirlo en todas nuestras intervenciones. Sin embargo nos encontramos con un panorama bastante descorazonador en el que hablar de sistemas de información, metodologías de integración, seguridad, gestión de proyectos, etc; es hablar casi de ciencia ficción para muchas de nuestras empresas. Especialmente en algunos sectores entre los que tenemos que incluir al industrial.

Investigando un poco, nos encontramos con la encuesta del INE acerca del uso de TIC y comercio electrónico en las empresas españolas. Y nos damos cuenta de que todavía estamos en la fase en la que consideramos que tener un ordenador y una conexión a Internet ya se considera innovación tecnológica. Este es el enlace de la nota de prensa con los últimos datos recogidos, por si queréis echar un vistazo:

http://www.ine.es/prensa/np618.pdf

Reflexionando acerca del tema y hablando con muchos de nuestros seguidores, nos parece que la falta de innovación es en muchos casos fruto de una combinación de varios factores. Primero, de factores internos como el desconocimiento de los posibles beneficios que pueden reportar ciertas tecnologías o la falta de formación del personal. Y después de factores externos como el coste de las soluciones que ofrece el mercado, la limitada transferencia tecnológica desde el sector de I+D y la falta de comunicación entre los proveedores y los posibles clientes.

¿Qué os parece a vosotros? ¿Por dónde deberíamos empezar a solucionar este grave problema?