Feliz año 2011

Aunque este año hemos tenido menos tiempo para publicar entradas en el blog, cerramos el 2010 muy contentos con un record de más de 40.000 visitas. Gracias a todos.

El año próximo seguiremos al pie del cañón y ya os iremos avisando de nuestros planes en cursos de invierno y verano, colaboraciones con el IMADE y el CEL, por mencionar algunas entidades que ya nos han propuesto cosas, y esperamos que podamos celebrar la segunda edición del WIIND.

Un abrazo y que el año nuevo os traiga lo que le hayáis pedido.

Marta&Fernando

Eficiencia, efectividad y eficacia

Últimamente estamos todos involucrados en proyectos de mejora de la eficiencia energética o de mejora de la efectividad de líneas de producción, por poner sólo algunos ejemplos. La actual coyuntura de crisis económica está incrementando enormemente la necesidad de las empresas de utilizar de manera óptima los recursos que ya posee y de minimizar gastos en materia prima, suministros, personal, etc.

Pero en muchos casos, debido a malas traducciones del inglés, utilizamos de manera equivocada los términos eficiencia, efectividad y eficacia. Vamos a intentar aclarar estos tres conceptos:

• Eficiencia: Relación entre los recursos programados y los utilizados realmente.
• Efectividad: Grado de consecución de los objetivos de producción/servicio fijados.
• Eficacia: Grado de adecuación del producto/servicio a requerimientos de producción y necesidades del mercado.

Por lo tanto, en las tres variables que manejamos habitualmente en términos de productividad, la eficiencia tiene que ver sobre todo con el coste, la efectividad con la cantidad y la eficacia con la calidad.

¿Qué es XML?

Hemos mencionado bastante esta tecnología en entradas anteriores (cuando hablamos de SOA o de integración de datos, por ejemplo), y algunos de vosotros nos habéis pedido una "introducción" al tema.

La tecnología XML busca dar solución al problema de expresar información estructurada de la manera más abstracta y reutilizable posible. Que la información sea estructurada quiere decir que se compone de partes bien definidas, y que esas partes se componen a su vez de otras partes.

La estructura de un fichero XML se asemeja a un árbol de información. Cada rama o parte del fichero se llama elemento y se distingue por la utilización de una etiqueta. Una etiqueta consiste en una marca hecha en el documento, que señala una porción de éste como un elemento.

Este es el típico primer ejemplo de fichero XML: el elemento raíz se llama libro y tiene tres hijos (título, autores y editorial) y un atributo (precio).

Failure Mode and Effect Analysis (y II)

Para utilizar esta técnica de ingeniería forense se recomienda completar las siguientes etapas o pasos:

• Etapa 1: Definición de los objetivos del estudio.
• Etapa 2: Creación del grupo de trabajo formado por expertos en las diferentes áreas objeto del estudio.
• Etapa 3: Definición del área de estudio y de su resolución, es decir, ¿en qué nivel están los componentes de partida cuyos fallos se evalúan: elétrico, mecánico, funcional? Definición de las escalas de puntuación.
  
• Etapa 4: Recorrido por todos los posibles fallos de los componentes de partida analizando causas, efectos y posibles soluciones.
• Etapa 5: Recorrido por todos los posibles fallos de los componentes de partida cuantificando los Risk Priority Numbers.

Para completar la etapa 5 es necesario cuantificar la probabilidad de ocurrencia (O), gravedad (S) y probabilidad de no detectar el fallo antes de que se produzca (D) para cada fallo analizado.

Para hacerlo de una manera sistemática suelen utilizarse unas hojas de trabajo basadas en tablas y se utilizan las escalas establecidas en la etapa 3 antes de comenzar con el análisis. Por ejemplo, para la probabilidad de ocurrencia un 1 puede significar un 0.0000001% de probabilidad de ocurrencia y en el otro extremo un 10 un 100% de probabilidad de ocurrencia.

En cuanto a la gravedad, un 1 sería un fallo muy leve mientras que un 10 sería peligro de muerte o de parada total de la planta. Para la probabilidad de detectar el fallo, un 1 sería para un fallo que se detecta siempre o casi siempre mientras que un 10 sería para un fallo que es imposible de detectar antes de que se produzca.

Cómo se establezcan las gradaciones intermedias entre las puntuaciones 1 y 10 afectará mucho al resultado del análisis, por eso la discusión de las escalas antes de comenzar a evaluar todos los fallos detectados es crítica para este tipo de estudios.

En este link tenéis mucha información acerca de esta técnica y de su aplicación en diferentes sectores:

http://www.fmeainfocentre.com/

Failure Mode and Effect Analysis (I)

Continuando con las técnicas de ingeniería forense aplicadas a la mejora de la productividad industrial (ya hemos hablado de Hazop o FTA en entradas anteriores), hoy vamos a introducir la metodología FMEA.

Esta técnica es en muchos casos complementaria de FTA, ya que al contrario que ella, es inductiva y va de lo concreto a lo abstracto. Se basa en analizar lo que ocurre cuando se produce un fallo, anomalía o error en cada uno de los componentes del sistema.

Es un método muy efectivo para localizar todas las posibles fuentes de riesgo en un sistema siempre y cuando no sea excesivamente complejo. El principal inconveniente es que no es capaz de identificar los riesgos asociados a la interacción entre componentes, sólo se trabaja con fallos en componentes individuales del sistema de producción.

Normalmente un grupo de trabajo compuesto por expertos puntúa:

• La probabilidad de ocurrencia de un fallo (de 1 a 10).
• La gravedad de ese fallo (de 1 a 10).
• Y la probabilidad de no detectar el fallo antes de que se produzca (de 1 a 10).

Con estos tres factores se pueden calcular los Risk Priority Numbers (R = Occurrence x Severity x Detection), que permiten comparar riesgos, priorizar su gestión, etc.

Existe una variante de esta técnica, FMECA (Failure Mode, Effect and Criticality Analysis), que en lugar de utilizar este R, calcula un factor de criticidad, más complejo y que permite diferenciar mejor entre los riesgos críticos que provocarán situaciones no deseadas con casi toda seguridad, y el resto.

Diferencias entre un cloud público y un cloud privado

Normalmente hablamos de sistemas Cloud sin diferenciar si se trata de sistemas públicos o provados, normlamente nos referimos a uno público pero conviene tener claras las diferencias.

En el caso de un cloud público, se contrata a un proveedor a través de Internet que nos permite el acceso a sus recursos (HW, SW, etc) mediante un interfaz estándar. Hoy en día existen proveedores de prácticamente todo tipo de servicios (ya hemos hablado en entradas anteriores de los sistemas SaaS, PaaS, IaaS) con un modelo "self-service". La idea fundamental es pagar sólo por lo que se usa, y es imprescindible definir correctamente una SLA (Service Level Agreement) que defina al detalle la relación entre el cliente y el proveedor.

Por el contrario, en el caso de un cloud privado se contrata a un proveedor para que lo monte dentro de nuestra empresa con nuestros propios recursos, a medida para nuestras necesidades. cumple nuestras políticas internas y mantenemos el control sobre todos los recursos. Se paga por la instalación y mantenimiento del sistema como en otros modelos tradicionales pero los recursos TIC de la organización se ofrecen como servicios a los propios empleados (esto suele ser una ventaja en el caso de empresas geográficamente distribuidas).

Existen modelos híbridos en los que un cloud privado puede demandar de un cloud público recursos sólo cuando los necesita. En estos casos es crítico decidir qué es lo que se puede externalizar, y qué se debe quedar siempre en el entorno privado.

Las empresas que optan por la opción de un cloud privado, si son del sector tecnológico o son grandes empresas dentro de un sector con necesidades muy específicas, acaban en muchos casos ofreciéndolos a otras empresas. De esta forma se evita tener recursos infrautilizados, se aumenta el ROI y se opta por un nuevo modelo de negocio que puede aportar ingresos sustanciales.