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.

RootedCON 2011

Esta vez se me ha hecho un poco tarde para avisaros, lo siento, pero para los que estáis interesados en temas de seguridad y nos pedís que os anunciemos los eventos más interesantes, aquí tenéis uno de ellos:

http://www.rootedcon.es/

Se celebra los próximos 3, 4 y 5 de Marzo en Madrid, y podéis ver en la página web qué ponencias se van a celebrar.

Cloud brokers

Dentro del modelo de negocio que hay detrás de los sistemas cloud se suelen contemplar tres tipos de agente: el cliente de los servicios, el proveedor de los servicios y el desarrollador de los servicios (que puede coincidir o no con el proveedor).

Pero últimamente ha surgido una nueva figura, el Cloud Broker, que suele situarse entre el consumidor y el proveedor.

En un entorno tan complejo como el de la nube, este tipo de agente suele cumplir con tres funciones esenciales:

• Consultoría y arbitraje: El broker se encarga de asesorar al consumidor acerca del mejor proveedor para sus necesidades concretas y realiza funciones de intermediación en la definición de las SLA. También se encarga de velar por su cumplimiento y de realizar labores de arbitraje ante cualquier problema que surja entre ambas partes.
• Agregación: El broker se encarga de ofrecer los servicios de diferentes proveedores cloud a un cliente como si se tratara de un único proveedor, añadiendo un nivel de abstracción que permite a los usuarios finales acceder a diferentes clouds de manera transparente.
• Valor añadido: El broker se encarga de completar los servicios ofrecidos por un proveedor con otros propios relacionados con las pruebas y auditoría, con la seguridad, con el diseño de interfaces, etc.

En algunos casos el broker se ofrece desde el propio proveedor de servicios y en otros casos, se trata de un agente independiente. Pero como parece que cada vez serán más necesarios los brokers como intermediarios, parece lógico pensar que las organizaciones que apuesten por el modelo cloud los incluyan dentro de su propio personal. De esta manera, las habilidades en gestión de proyectos y gobernanza de TIC serán más importantes para los departamentos técnicos de muchas organizaciones que las de desarrollo y programación. Y además este tipo de figura intermediaria puede adaptarse con facilidad a otros entornos tecnológicos y de negocio que no sean exclusivamente el de Cloud Computing.

¿Qué es la lógica difusa?

El término fuzzy logic (lógica difusa) aparece mucho en sistemas de control industrial. La palabra fuzzy se refiere a "términos, frases o sentencias que no son suficientemente claras, no son bien conocidas, o su especificación está sujeta a la estimación, subjetividad o intuición". Por ejemplo, mucho, poco, varios, más o menos, alrededor de, etc.

Este tipo de expresiones se formalizaron matemáticamante hace ya bastantes años con la teoría de conjuntos difusos que ahora sirve de base para estos sistemas de control industrial tan de moda.

Simplificando mucho, en la teoría de conjuntos clásicos hay una relación directa entre la pertenencia/no pertenencia de un elemento al conjunto y la lógica binaria o booleana: el 1 equivale a la pertenencia y el 0 a la no pertenencia.

Por el contrario, en el caso de los conjuntos difusos, el grado de pertenencia de un elemento a un conjunto tiene un rango entre 0 y 1, de manera que vale 0 para los elementos que no pertenecen al conjunto, vale 1 para los elementos que sí pertenecen a él, y toma valores intermedios para los elementos de frontera.

Esto permite formalizar de manera relativamente sencilla situaciones de incertidumbre, ambigüedades, aproximaciones, percepciones y sensaciones, que son muy habituales en el mundo real y en la vida cotidiana, y que se suelen expresar mediante el lenguaje.

Por ello los sistemas de control basados en lógica difusa se construyen alrededor de un conjunto de reglas de conocimiento. Una regla es una frase o sentencia que consta de dos partes: una premisa o antecedente y una conclusión o consecuente. El antecedente define las variables de entrada al sistema de control y el consecuente, define el resultado. Es decir, son reglas del tipo IF (antecedente) THEN (consecuente): por ejemplo, IF (caudal es alto) THEN (disminuir la temperatura).

En futuras entradas hablaremos de las aplicaciones de este tipo de sistemas de control.

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.