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.

Método AHP para la selección de una solución software (y II)

Entrada relacionada: Método AHP para la selección de una solución software (I)

Para la aplicación de la técnica AHP a un problema específico, se deben realizar las siguientes etapas:

1. Definición de la estructura de decisión jerarquizada.
Esta estructura está formada por diferentes niveles. El primer nivel es el objetivo final de la decisión, el segundo nivel lo forman los criterios y subcriterios que se utilizan para valorar las posibles alternativas de decisión, que forman el tercer nivel.
d
2. Establecer la interpretación de los valores de la matriz de pares comparados.

Una vez que se han establecido los criterios y las alternativas para la decisión, se procede a asignar pesos a los juicios de valor expresados por los individuos y/o grupos de interés involucrados en la toma de decisión. Estos juicios de valor pueden estar guiados por la información científica, técnica, experiencia y conocimientos del grupo decisor.

Para asignar estos pesos, se utiliza el método propuesto por Saaty en términos de pares comparados. AHP dispone de una escala creada por el propio autor que mide los juicios emitidos por el grupo decisor. En la siguiente tabla se presenta dicha escala de interpretación de valores de pares comparados.

3. Obtención del vector de prioridad de la matriz de pares comparados de criterios.
El vector de prioridad es el autovector normalizado de la matriz de pares comparados de criterios. Es decir, el resultado final de este paso, es conocer la importancia relativa de cada criterio con respecto los demás, expresada en porcentaje.

La matriz de pares comparados de criterios se calcula asignando un valor a cada par comparado (criterio por criterio). El valor asignado siempre es de 1 a 9 , se normalizan las columnas de la matriz dividiendo cada valor de la columna entre el sumatorio de todos los valores asociados a una misma columna y se promedian las filas de la matriz sumando los valores de cada fila entre el número de criterios.

Así la matriz de criterios se transforma en un vector de prioridad de pares comparadas de criterios.

4. Análisis de la consistencia del vector de prioridad obtenido.
Una consideración importante acerca de la calidad de la decisión final se relaciona con la consistencia en los juicios, demostrada por el decisor durante la serie de comparación por pares. Es difícil conseguir consistencia perfecta, por lo que pueden surgir inconsistencias en prácticamente cualquier juego de comparaciones por pares.

AHP proporciona un método para medir el grado de consistencia, si el grado de consistencia es aceptable, el proceso de decisión puede continuar, de lo contrario, el decisor debe reconsiderar y posiblemente revisar los juicios de comparación por pares, antes de seguir adelante en el análisis.

Para comprobar que los juicios de valor enunciados son consistentes, Saaty propone un ratio de consistencia (CR) cuya expresión es:


Siendo RI el índice de ruido aleatorio definido como índice medio de consistencia de estimaciones hechas al azar y que se presentan en la tabla y CI el índice de consistencia, siendo (lambda_max) el valor máximo del autovector de la matriz de pares comparados no normalizada y (n) el orden de la matriz.


Si el valor de CR es menor que 0,1 (para matrices de más de 5 x 5) entonces el grado de consistencia es satisfactorio. Si por el contrario es mayor, existen inconsistencias y el proceso de decisión debe depurarse ya que la asignación de pesos está sesgada.

5. Obtención del vector de prioridad para la matriz de comparación entre alternativas y criterios.
Para ello se realiza el mismo proceso que se ha llevado a cabo para obtener el vector de prioridad de la matriz de criterios. En este caso, se desarrollan tantas matrices como criterios existan.

En cada matriz se realizan pares comparados de las distintas alternativas existentes, emitiendo juicios de valor en los que se valora cómo una alternativa se adecúa más o menos a cada uno de los criterios seleccionados.

Una vez que se obtienen las matrices no normalizadas, se procede a normalizarlas y promediarlas como se hizo en la matriz de criterios. Tras estas operaciones cada matriz de comparación de alternativas por criterio es una matriz de una sola columna que corresponde al vector de prioridad de dicha matriz.

Al igual que se hace con la matriz no normalizada de criterios, se analiza la consistencia de cada matriz de alternativas por criterio.

El último paso es crear una matriz general en la que se consolidan todos los vectores de prioridad de cada matriz. El resultado final es una matriz de tantas filas como alternativas haya y tantas columnas como criterios se hayan tomado en consideración.

6. Obtención del ranking de alternativas y selección.
El último paso consiste en multiplicar el vector de prioridad de matrices y criterios (el obtenido en el anterior paso) por el vector de prioridad de criterios.

El resultado es una matriz en la que se ponderan las distintas alternativas existentes. Esta matriz genera un ranking de alternativas. Aquella que tenga una ponderación mayor es la más adecuada y la que obtenga menor puntuación la menos apropiada. De esta manera los juicios de valor enunciados, se transforman en datos numéricos objetivos que facilitan el proceso de decisión.
nn

Memorias RDRAM y XDR: Rambus

La tecnología RDRAM para memoria principal consigue un rendimiento bastante alto en lo que se refiere al ancho de banda (comparando con las memorias DDR que todos estamos acostumbrados a utilizar en nuestros PCs y servidores), pero su elevado coste y consumo de potencia, sus elevadas latencias, así como la falta de apoyo de los fabricantes de chipsets y placas base impidió inicialmente que se extendiera en las arquitecturas de consumo.

Todas las tecnologías de memoria DDR utilizan canales de memoria del mismo ancho que el bus de memoria y el bus del sistema (64 bits). Pero esta tecnología propone aproximarse más a la comunicación serie, con un canal de memoria más estrecho pero más rápido, siguiendo la misma filosofía que los actuales buses de E/S, por ejemplo. Esta es la principal dierencia entre una memoria de tipo DDR y una de tipo RDRAM o XDR, la conexión paralela o serie de los chips de memoria.

El canal utilizado se denomina Rambus, tiene una anchura de 16 bits y funciona a frecuencias de hasta 533 MHz, permitiendo dos transferencias por ciclo de reloj. Este canal utiliza un protocolo de transferencia basado en paquetes y permite la multiplexación en el tiempo para la transferencia de direcciones y de datos. Al Rambus pueden conectarse hasta 32 chips de RDRAM en serie, pero todas las transferencias se realizan entre el controlador de memoria y un chip, no entre los chips.

La tecnología sucesora de la RDRAM ha sido XDR DRAM (eXtreme Data Rate DRAM), mucho más extendida ya que está siendo la tecnología más utilizada en las videoconsolas. Por ejemplo la Playtstation3 incorpora este tipo de memoria, que ha incrementado la frecuencia del bus hasta 800 MHz con una anchura de 32 bits y además realiza ocho transferencias de datos por ciclo de reloj, mejorando también notablamente las latencias de acceso de los chips.

Según muchos especialistas este tipo de tecnología de memoria es el futuro de la memoria principal de los PCs y los servidores, no sólo de las consolas, pero veremos cómo evolucionan las cosas en el futuro.

Más sobre Kanban

Teníamos pendiente resumir la información más habitual que se puede encontrar en una tarjeta Kanban así somo las normas básicas asociadas a su funcionamiento.

En cuanto a la información, depende mucho del tipo de dispositivo que se utilice como señalización. Lo más habitual es escoger las típicas tarjetas Kanban con códigos de barras, aunque se pueden sustituir por un corcho o panel con tarjetas o post-its rellenados manualmente que sean visibles desde todos los puestos de trabajo si se quiere reducir la inversión inicial. Si por el contrario se dispone de suficiente presupuesto, se puede incluir un sistema de pantallas Kanban en los interfaces utilizados por los operarios en la planta y prescindir así de las tarjetas físicas. En cualquiera de estos casos, se suele manejar este tipo de información:

• Fecha y hora.
• Puesto origen y puesto destino del kanban. Datos de autorización.
• Número de parte del componente y su descripción. Información del lote.
• Nombre / Número del producto.
• Cantidad requerida.
• Tipo de manipulación de material requerido.
• Secuencia de ensamblaje / producción.
• Dónde debe ser almacenado el resultado cuando sea terminado.

Además de este tipo de información, se debe tener siempre muy presente que el funcionamiento óptimo del sistema dependerá de que se cumplan las siguientes normas básicas:

• Regla 1: No se debe mandar producto defectuoso a los procesos posteriores.
• Regla 2: Los procesos posteriores requerirán sólo lo necesario a los que les preceden.
• Regla 3: Se debe producir solamente la cantidad exacta requerida por el proceso posterior.
• Regla 4: Es imprescindible balancear la producción (equilibrado de la cadena).
• Regla 5: Kanban es un medio para evitar especulaciones. No supongas nada.
• Regla 6: El objetivo es estabilizar y racionalizar el proceso.

Zona desmilitarizada

Con este término nos referimos a un área de una red de computadores que está entre la red de computadores interior de una organización (Intranet) y la red de computadores exterior, generalmente una WAN en la que no se confía que suele ser Internet. También se puede llamar red perimetral.

La zona desmilitarizada o DMZ permite que servidores interiores provean a la red exterior de servicios, mientras protege a la red interior de intromisiones. Para ello se coloca detrás de un servidor de seguridad de Internet (que se suele denominar el Front-End) y delante de un servidor de seguridad de segundo nivel (el Back-End) que protege los sistemas y datos de la red interna.

En la DMZ encontraremos típicamente los servidores web, de correo ó DNS de la organización. Estos servidores pueden ser accedidos tanto desde la red externa como desde la interna, pero desde ellos sólo se podrá salir al exterior, de manera que no puedan hacer de "pasarela" para un intruso hacia la intranet.

La utilidad del CRM

Ya hemos tratado en alguna entrada el tema de los sistemas CRM (Customer Relationship Management).

Recordemos que se trata de una aplicación que permite centralizar las actividades que se llevan a cabo para dar un correcto servicio al cliente y para gestionar óptimamente la cartera de clientes vinculada a una empresa.

Estas soluciones software se basan en una base de datos, que se nutre de la información introducida por los departamentos comercial, de producto, financiero y de marketing de una empresa. Permiten conocer la información detallada de cada cliente y de su historial, las ventas por comercial, las campañas de marketing abiertas, las oportunidades creadas, las acciones pendientes de llevar a cabo con determinados clientes, etc.

Sea cual sea el modelo de implantación escogido (solución a medida, software factory, software abierto, Software as a Service), nos encontramos muchas veces con que los proyectos se centran en esta implantación pero olvidan la explotación y el mantenimiento del sistema.

El ROI que se obtiene con una solución de este tipo depende directamente de su utilización óptima por parte de la fuerza comercial de la empresa, y para ello el CRM debe estar correctamente configurado y parametrizado. Además deben existir procedimientos y políticas claros acerca de la introducción, actualización y utilización de los datos manejados por la aplicación. Ésta es la única manera que existe para convertirlos en información útil y en última instancia, en conocimiento.

Se debe intentar que el CRM ayude a realizar estas tareas:

• Retener a los clientes más valiosos para la empresa.
• Incrementar la lealtad de los clientes que pueden ser más valiosos en el futuro.
• Aumentar el consumo de los clientes que tienen capacidad para ello.
• Dispersar el portafolios de productos que consumen los clientes que se detecta que tienen predisposición para ello.
• Evitar la adquisición de clientes de poco valor y alto costo para la empresa.
• Optimizar el gasto de operación en los clientes de poco valor.
• Buscar y adquirir clientes similares a los más valiosos para el negocio.

¿En qué consiste Kanban?

Ya hemos hablado en otras entradas de herramientas típicas de Lean, vamos a centrarnos hoy en Kanban.

Se trata de un sistema de señalización que permite reducir los stocks. Suele estar basado en tarjetas que señalan la necesidad de un artículo aunque se pueden utilizar otros dispositivos como marcadores plásticos, pelotas, o incluso carros vacíos. Cuando el dispositivo kanban no puede ser colocado cerca del material o artículo (p.ej. si el material está siendo tratado con calor), debe ser colgado lo más cerca posible del puesto donde este material es procesado.

El flujo de Kanban va siempre desde el cliente hacia el proveedor y el objetivo es producir sólo bajo demanda ( y conseguir un sistema de producción "pull").

Se suelen distinguir tres tipos de Kanban diferentes:

• Kanban de señal: Sirve como una autorización al último puesto de procesamiento (generalmente el de ensamblado) para que ordene a los puestos anteriores que comiencen la producción. Suele ir asociada al pedido que realiza el cliente.
• Kanban de producción: Indica la cantidad que debe producir el proceso anterior. Suele ir asociada al material o al puesto que lo procesa.
• Kanban de transporte: Indica la cantidad que debe recoger el proceso posterior y se utiliza cuando se traslada un material ya procesado de un puesto a otro posterior a éste. Suele ir adherida al contenedor.

En entradas futuras pondremos algún ejemplo y comentaremos la información típica que debe ir asociada a las tarjetas Kanban así como sus normas básicas de funcionamiento.

Método AHP para la selección de una solución software (I)

El AHP (Analytic Hierarchy Process) es un método que permite al decisor realizar el proceso de decisión de forma visual a través de la construcción de un modelo jerárquico que básicamente contiene tres niveles: meta u objetivo, criterios y alternativas.

El proceso de decisión se realiza básicamente de la siguiente manera: el decisor debe alcanzar un objetivo y para ello dispone de varias alternativas, cada alternativa es valorada teniendo en cuenta una serie de criterios.

Se llevan a cabo dos tipos de valoraciones:

• La primera entre la mayor o menor preferencia o importancia de los criterios entre sí.
• La segunda valoración entre los criterios seleccionados y cada una de las alternativas.

Ambas valoraciones se llevan a cabo realizando comparaciones de pares de elementos (criterio por criterio o criterio por alternativa) proporcionándoles valores numéricos que van desde el valor 1 al 9. Dicha ponderación es la que propone Saaty (el investigador que propueso esta metodología) para valorar los pares comparados y se comprenderá mejor con un ejemplo que pondremos en una entrada futura.

El resultado final del método permite entonces seleccionar como la mejor alternativa, a aquella que tiene el valor de prioridad más elevado, o realizar un ordenamiento de alternativas que facilite, por ejemplo, la asignación de recursos.

Es fundamental señalar que una de las características principales de AHP es que sólo es aplicable si las alternativas que se incluyen en el proceso de decisión son excluyentes entre sí. Es decir, no existen relaciones de dependencia entre las alternativas ni por tanto una alternativa incluye parcialmente a otra. El grupo decisor debe elegir de forma integral una u otra. Estas mismas condiciones se aplican a los criterios y subcriterios de decisión.

v

Gestión corporativa en Tiempo Real: El valor de la información (y IV)

4. CONCLUSIONES

Como conclusión, sugerimos que los directivos que se estén planteando gestionar sus organizaciones en tiempo real se planteen las siguientes preguntas:

• ¿Cuál es el objetivo de esta gestión corporativa en tiempo real?. Es decir, ¿cuáles son los impulsores de esta iniciativa?.
• ¿Está preparada la organización para ser gestionada con una estrategia de estas características?. ¿Presenta la suficiente madurez tecnológica y organizativa para generar valor a partir de la información en tiempo real?.
• ¿Cuál sería éste valor?. ¿De dónde provendría la ventaja competitiva que supondría la transformación en una Zero Latency Enterprise?.

Si las respuestas a estas preguntas llevan a la organización a afrontar el reto de una gestión en tiempo real, la transformación de la organización deberá realizarse con un enfoque holístico y multidisciplinar, teniendo en cuenta en todo momento los tres factores clave discutidos en este artículo asociados a las personas (concienciación), a los procesos (minimización de latencias) y a los sistemas (integración).

Gestión corporativa en Tiempo Real: El valor de la información (III)

3. FACTORES CLAVE PARA LA GESTIÓN CORPORATIVA EN TIEMPO REAL

El principal problema que debe resolverse para conseguir la gestión corporativa en tiempo real de una organización es conseguir que multitud de procesos y sistemas, en la mayor parte de los casos completamente heterogéneos y distribuidos, incluso geográficamente, operen de manera conjunta en tiempo real. Y que las personas que componen la organización comprendan este tipo de gestión para aprovechar adecuadamente la ventaja competitiva que éste supone.

Teniendo esto en cuenta, y para superar las barreras ya discutidas, la implantación de una estrategia de gestión corporativa en tiempo real, sea cual sea la opción escogida, debe tener presente los factores clave que se describen a continuación (ver figura), relacionados con las personas, los procesos y los sistemas.



1. Concienciación de la importancia de la información en tiempo real
El hecho de concienciar a las personas que componen la organización de la importancia de la información en tiempo real, implica que éstas conocen y comparten las siguientes ideas:

Dados unos datos o una información válida, su valor y utilidad para la organización decrece si no se obtienen en el momento que se necesitan, es decir, si no se cumple la latencia establecida para el manejo de información estratégica.

• Es necesario disponer de sistemas de información que permitan gestionar paquetes de información con latencias en distintos órdenes de magnitud y ser consciente de la heterogeneidad de estas latencias. Por ejemplo, una empresa que disponga de un sistema MES y un sistema ERP puede gestionar información de planta en tiempo real (latencias entre microsegundos y minutos) e información de procesos de negocio y operaciones (latencias cercanas al día). Pero si no es consciente de la diferencia entre las latencias de ambos sistemas, cuando se necesite integrar su información, no se hará correctamente. Y además, la información cuya latencia oscila entre el minuto y el día, quedará sin procesar por norma general.
• Es deseable que los sistemas de información incorporen funcionalidades que proporcionen información basándose en eventos. Para recoger y procesar información en tiempo real los sistemas de información deben ser de tipo push, es decir, debe ser el propio sistema el que entregue la información al individuo adecuado sin que éste la haya solicitado. Además este tipo de sistemas debe contextualizar la información recogida para aportarle el valor que genere la ventaja competitiva.

Este proceso de concienciación e información debe llegar a todo el personal operativo y directivo de la organización. Es imprescindible una correcta política de comunicación empresarial y de gestión del cambio durante el proceso de adaptación de la empresa a la gestión en tiempo real, de manera que se garantice una exitosa implantación de la estrategia ZLE y un retorno de inversión adecuado. Sin la colaboración e implicación de todas las personas que componen la organización, esto sería imposible.

2. Minimización de la latencia de procesos de negocio
La latencia de un proceso es su tiempo de transacción o tiempo total que tarda en ejecutarse correctamente una vez. Partiendo de esta definición, el tiempo de transacción es la suma de los tiempos de ejecución (tiempos que transcurren mientras las actividades que componen los procesos se ejecutan) y de los tiempos de espera (tiempos que transcurren desde que una actividad es finalizada y se inicia la siguiente). La existencia de tiempos de espera se produce fundamentalmente por dos motivos. El primero es la falta de continuidad en la ejecución de las actividades de los procesos, producida por ineficiencias asociadas a los sistemas que los ejecutan o por los retrasos y errores generados por la intervención de personas en la realización de actividades manuales. El segundo motivo, es la aparición de cuellos de botella durante la ejecución de las actividades realizadas tanto automáticamente como manualmente.

Para minimizar la latencia de los procesos, por tanto, pueden llevarse a cabo dos tipos de acciones, unas orientadas a disminuir los tiempos de espera existentes entre las actividades que forman un proceso y otras dirigidas a disminuir su tiempo de ejecución, es decir, a realizar las actividades que componen el proceso de manera más eficiente o a reducir el número de actividades.

Existen diferentes técnicas que permiten conseguir estos objetivos: el enfoque incremental o Kaizen, el rediseño de procesos, la reingeniería de procesos, la utilización de técnicas BPM, etc. Además de todas éstas, más o menos generales, cada sector de actividad suele contar con metodologías y técnicas específicas para la minimización de la latencia de sus procesos específicos.

3. Integración de sistemas de información
Como tercer factor clave, es necesario contar con una red o infraestructura tecnológica que permita que los sistemas de información interoperen en tiempo real. Esta integración de los sistemas de información garantiza que se cumplen las latencias de entrega de información dentro de la organización, que ésta se comparte de manera efectiva para detectar eventos de manera global, y además contribuye a la minimización de la latencia de los procesos (por ejemplo, una correcta integración de los sistemas ERP y CRM puede reducir considerablemente la latencia de los procesos de venta).

La arquitectura ZLE puede implementarse llevando a cabo un desarrollo a medida que reutilice las aplicaciones que ya existían en la organización, utilizando la infraestructura desarrollada por la multinacional norteamericana Hewlett-Packard (HP) que dispone de la única solución comercial específica para ZLE o utilizando los diferentes estilos y estándares de integración de datos y funcionalidades que existen en la actualidad, entre los que cabe destacar la utilización de SOA y ESB por los buenos resultados que están consiguiendo en entornos ZLE.

Gestión corporativa en Tiempo Real: El valor de la información (II)

2. GESTIÓN CORPORATIVA EN TIEMPO REAL

Para comprender mejor la ventaja competitiva que puede obtenerse mediante la gestión corporativa en tiempo real, resulta conveniente comenzar por analizar las principales circunstancias o impulsores que pueden motivar a una organización a implantar una solución de este tipo, más allá de los beneficios directos que este tipo de gestión ofrece en relación a las personas, los procesos y los sistemas. En general se observa que ZLE se percibe como una herramienta muy potente para la gestión de crisis y para la innovación. Aunque resulta complejo realizar una enumeración completa de todos los impulsores identificados en nuestro estudio, a continuación se clasifican los más importantes en tres grandes grupos.

1. Impulsores asociados a la organización:

• Necesidad de mejorar resultados empresariales. La puesta en marcha de una estrategia ZLE permite detectar los procesos corporativos y operaciones que no se están llevando a cabo de forma satisfactoria y corregirlos, ayudando así a mejorar los resultados de la organización. Además, este tipo de solución contribuye a optimizar la utilización de los sistemas de información disponibles y su retorno de inversión, consiguiendo que el conocimiento fluya de manera adecuada dentro de la organización, eliminando las islas y aumentando el valor de la información que se maneja.
• Crecimiento. La información en tiempo real puede ayudar enormemente a gestionar la posición crítica por la que pasa una organización en periodos de expansión y a aliviar la situación coyuntural de inestabilidad, convirtiendo las amenazas y debilidades en oportunidades y fortalezas. También puede ayudar a identificar nuevos mercados en una fase previa a este crecimiento.
• Fusiones, adquisiciones y absorciones. La estrategia ZLE permite optimizar los nuevos procesos, minimizando sus latencias, e integrar los sistemas de información de las organizaciones que se fusionan. Además ayuda a no destruir valor el proceso sino a generarlo.
• Adopción de un nuevo modelo de negocio. De nuevo en una situación de innovación la información en tiempo real puede ayudar a reducir costes y a incrementar la tasa de éxito.
• Existencia de centros de operaciones o delegaciones repartidas geográficamente. Una iniciativa ZLE ayuda a reducir los problemas que tradicionalmente introducen dichas distancias geográficas, asegurando la mínima latencia de los procesos (a pesar de que sus actores estén geográficamente distribuidos) y la correcta integración de los sistemas de información distribuidos. También puede ayudar, por ejemplo, a minimizar desplazamientos y mejorar la comunicación interna.

2. Impulsores asociados a clientes y proveedores:

• Necesidad de mejorar la calidad de servicio proporcionada a los clientes. Este impulsor está muy relacionado con la minimización de la latencia de los procesos de negocio, de manera que los tiempos de distribución y entrega de productos y servicios, por ejemplo, se puedan reducir.
• Necesidad de mejorar en la captación y fidelización de los clientes.
• Elevada segmentación de mercados y clientes. Las organizaciones que trabajan en distintos mercados verticales y con clientes heterogéneos (en cuanto al tamaño del cliente, sus exigencias particulares, los modelos de asociación cliente-proveedor, etc), suelen realizar una gestión descentralizada de este entorno, con las desventajas que esto conlleva por la convivencia de diferentes procesos y sistemas de información. ZLE ayuda a implantar un modelo centralizado de gestión que permita reducir los costes de gestión inherentes a un modelo segmentado.
• Voluntad de los clientes y/o proveedores de llevar a cabo una integración de sistemas de información transaccionales (ERP y SCM, principalmente) para agilizar los procesos de compra/venta. Una infraestructura tecnológica que de soporte a ZLE, está preparada para que los sistemas de información estratégicos puedan integrarse entre ellos y/o con otros sistemas externos. Esto redundará positivamente en los niveles de satisfacción de clientes y/o proveedores.

3. Impulsores asociados a productos y servicios:

• Existencia de productos y servicios complejos de gestionar. ZLE ayuda a gestionar de manera óptima un elevado número de productos y servicios que lleven asociados procesos y sistemas de información heterogéneos.
• Necesidad de desarrollar nuevos productos y servicios. Por ejemplo, una estrategia ZLE puede ayudar a escoger el mejor momento de lanzamiento del nuevo producto o servicio al mercado, o a identificar las necesidades de los clientes antes de la fase de diseño. Esto puede reducir el coste y/o la tasa de fracaso de la innovación en producto.

Una vez comprendidos los factores que deben hacer que una empresa se plantee la gestión corporativa en tiempo real como una necesidad, pasemos a analizar las opciones que tiene para conseguir implantar este tipo de estrategia en su organización. La mejor prueba de que la gestión corporativa en tiempo real se consolida como una herramienta indispensable para conseguir el éxito en los mercados actuales es la proliferación de conceptos, metodologías y herramientas asociadas a este tipo de gestión (aunque nosotros nos referimos en este artículo sólo a las estrategias ZLE para unificar terminología). Trabajos y casos prácticos acerca de Real Time Enterprise, Actionable Enterprise Architecture, Instant Virtual Enterprise, de la combinación de arquitecturas SOA con Business Process Management o de Event-Driven Architecture, son sólo una muestra del gran avance que en los últimos años se está produciendo en este campo y del interés que despierta en todos los sectores.

Como mencionábamos en la introducción de este artículo, ya existen empresas, tanto dentro como fuera de nuestras fronteras, que han adoptado este tipo de gestión para convertir los datos que manejan habitualmente en información de valor. Desgraciadamente en casi todos estos casos se trata de empresas que han confiado en gurús para implantar una estrategia ZLE a medida en su organización. Todavía no están extendidas metodologías estándar y generales o mejores prácticas comúnmente aceptadas que permitan que una empresa acometa este tipo de iniciativa sin depender de este tipo de visionarios o expertos para ello.

Sin embargo se pueden extraer conclusiones comunes de todos los trabajos y casos prácticos antes mencionados que pueden ayudar a los directivos a implantar este tipo de gestión en sus empresas.

Gestión corporativa en Tiempo Real: El valor de la información (I)

El concepto clave en el marco competitivo actual es el tiempo real, las organizaciones con un ciclo de decisión más corto y un tiempo adaptación más rápido son las que adquieren una ventaja competitiva y sobreviven en los exigentes mercados actuales. En este artículo escrito por Fernando Sevillano y Marta Beltrán hace unos meses se discuten los aspectos críticos de la gestión corporativa en tiempo real y se presentan los conceptos necesarios para comprender la relación que tienen con este tipo de gestión la minimización de la latencia de los procesos de negocio y la integración de los sistemas de información.

1. INTRODUCCIÓN

Las Tecnologías de la Información y Comunicaciones (TIC), y su utilización para la mejora de la eficiencia y productividad empresarial, constituyen en la actualidad una de las líneas de investigación más interesantes para la administración y dirección de empresas. Investigaciones previas han concluido que las empresas pueden realizar hasta tres usos o aplicaciones estratégicas de las TIC: mejorar la eficiencia interna de la empresa, mejorar la atención a los clientes actuales y definir nuevos mercados y nuevas oportunidades de negocio.

Sin embargo, la exigencia de los mercados globalizados actuales, hace que sea necesario dar un paso más en la utilización de las TIC para conseguir realmente una ventaja competitiva: el concepto clave es su utilización para la gestión en tiempo real.

Zero Latency Enterprise (ZLE) es un concepto definido por Gartner que considera la aplicación de soluciones de tiempo real a la gestión global de las organizaciones. La entidad que adopta esta estrategia, hace que el acceso a la información y los procesos de intercambio de la misma se produzcan en tiempo real, lo que se traduce en una ventaja competitiva para las empresas, que pueden acortar sus tiempos de decisión, reacción y adaptación. Dicha ventaja competitiva se materializa en una organización cuando ésta es capaz de proporcionar información correcta a las personas que la necesitan, en el momento adecuado, utilizando el proceso idóneo y con un coste mínimo. Para ello, la organización debe minimizar la latencia de sus operaciones y procesos de negocio e integrar sus sistemas de información estratégicos.

Los beneficios de la implantación de una estrategia ZLE son claros en un entorno como el actual dinámico y competitivo, en el que todo parece estar cambiando constantemente: las personas, los procesos, los productos y los sistemas. En esta vorágine, es necesario dar servicio a un gran número de clientes a pesar de las variaciones en la demanda y en sus preferencias, hay que adaptarse a las nuevas tecnologías, cumplir las nuevas regulaciones nacionales e internacionales e incluso asumir nuevas fronteras geográficas y políticas. Todo ello gestionando los riesgos corporativos de una forma integrada y en una situación de recesión económica global como la actual en la que los ingresos disminuyen y existe una gran presión sobre los márgenes de beneficios. Por ello las organizaciones deben plantearse que sólo aquéllas con los ciclos de decisión y adaptación más cortos sobrevivirán en el mercado. La mayor disponibilidad de información que las organizaciones manejan en la actualidad no tiene efectos positivos sobre sus resultados si ésta no se gestiona de la manera adecuada y en los plazos en los que su valor es estratégico.

En este contexto los beneficios de la gestión corporativa en tiempo real se pueden resumir en los siguientes puntos:

• Proporciona una visión en tiempo real de la organización a diferentes niveles de detalle y abstracción.
• Aumenta la agilidad y la flexibilidad de la organización, permitiendo que tome decisiones y/o se adapte más rápidamente a los cambios que se producen en el entorno en el que realiza su actividad.
• Permite detectar y eliminar potenciales peligros antes de que supongan un problema real (amenazas externas e internas).
• Incrementa la productividad y reduce los costes de los procesos de negocio que se ejecutan en la organización.
  

A pesar de todos estos beneficios las estrategias de gestión corporativa en tiempo real no están todavía muy extendidas debido a ciertas barreras en los entornos organizativos actuales.

Las primeras de estas barreras tienen que ver con las personas, ya que suele existir una actitud negativa por parte de los integrantes de una organización a cualquier cambio en los procesos de negocio o en los sistemas de información. Esto incluye a la dirección de las organizaciones, que todavía suele percibir que la adopción de modelos de gestión en tiempo real es un proceso complejo y costoso, que no siempre termina compensando la inversión realizada y que incluso puede obligar a modificar el modelo de negocio.

El segundo tipo de barreras suelen ser más bien de carácter tecnológico. El aislamiento de ciertos sistemas dentro de las organizaciones y la existencia de cajas negras de información a las que no se puede acceder, dificulta mucho la consecución del nivel de integración entre sistemas necesario para obtener ZLE.

Un ejemplo claro de empresa que se está beneficiando de la ventaja competitiva que supone superar todas estas barreras antes que la competencia lo podemos encontrar en el grupo Inditex, el minorista español del sector de la moda, que gestiona marcas globales como Zara, Massimo Dutti o Stradivarius. Este grupo ha hecho de la gestión corporativa en tiempo real una prioridad, adaptando su modelo de negocio para aprovechar al máximo el valor de la información en tiempo real. Según la Memoria Anual de Inditex en el año 2008, su modelo de negocio "no entiende de temporadas sino que es continuo y comienza con la información que han procesado las tiendas sobre los deseos e impresiones de los clientes. La rapidez del proceso se mantiene en la fase de producción gracias a que una parte importante de la fabricación se lleva a cabo en factorías pertenecientes al grupo y en centros próximos a las sedes corporativas de cada una de las cadenas. Inditex da prioridad al tiempo frente a los costes de producción, reduciendo así el riesgo que entraña la fabricación alejada de los centros de decisión".

Fuera de nuestras fronteras, los casos más exitosos de gestión corporativa en tiempo real se pueden encontrar en las empresas Cisco, AT&T, General Electric, Mercedes Benz ó DaimlerChrysler.

FTA ó Fault Tree Analysis (y II)

Este sería el aspecto de un árbol muy sencillo de tres niveles sin asignar todavía las probabilidades de cada rama, en el que el rectángulo que está en la parte superior es el top event o fallo al que no se desea llegar, los rectángulos del nivel intermedio son sus causas principales y los círculos del nivel inferior son las consideradas causas básicas (que limitan la resolución del análisis porque ya no se descomponen más). Hay que recordar que para que se active la salida de una puerta OR basta con que se active alguna de sus entradas, mientras que en una puerta AND todas tienen que estar activas.

Cuando se utiliza FTA se deben cumplir la siguientes etapas:

• Etapa 1: Definición de los objetivos del estudio.
• Etapa 2: Creación del grupo de trabajo.
• Etapa 3: Definición del área de estudio y de su resolución. ¿En qué nivel están las causas que se consideran básicas? Puede ser organizativo o funcional o en el otro extremo, mecánico. Depende mucho de los objetivos que se hayan fijado en la primera etapa.
  
• Etapa 4: Definición de los top events del árbol. Los fallos de partida deben ser muy probables o muy graves para que merezca la pena analizarlos. Hay que evitar "matar moscas a cañonazos".
  
• Etapa 5: Construcción de los árboles. Es decir, analizar las relaciones entre las causas y los efectos y decidir si las puertas de cada rama son OR o AND.
  
• Etapa 6: Asignación de probabilidades. Pero, ¿de dónde sacamos estas probabilidades para completar el árbol? Se puede recurrir a estándares industriales (estándar IEEE 500, estándares NUREG), al GIDEP (Government-Industry Data Exchange Program), a los estándares MIL, a los datos proporcionados por otros fabricantes y proveedores, a simulaciones y pruebas, a datos históricos, a foros sectoriales, etc. Depende mucho del sector de actividad y de los objetivos del análisis. Esta última etapa suele ser crítica para el éxito del análisis, por lo que conviene invertir esfuerzo en realizarla correctamente.
  

Y estas etapas deben realizarse siempre cumpliendo una normas básicas:

• Dividir la planta en subsistemas y líneas para atacar problemas sencillos y manejables.
• Nunca alimentar una puerta desde otra puerta.
• Utilizar nomenclatura clara y consistente para las causas y los top events.
• Ser realista y no esperar milagros cuando se asignan las probabilidades.
• Las causas básicas deben ser completamente independientes unas de otras.

Tenéis un tutorial muy completo pero sencillo de entender en:

http://www.fault-tree.net/papers/clemens-fta-tutorial.pdf

FTA ó Fault Tree Analysis (I)

Ya hemos hablado en entradas anteriores de las técnicas de Ingeniería Forense o de diagnosis de fallos aplicadas a la mejora de la productividad industrial. En el lenguaje técnico se entiende por fallo la alteración sufrida por un componente del sistema que origina un cese prematuro, total o parcial de su función. La realización de diagnosis de fallos permite encontrar las causas de los fallos para:

• Mapear estas causas adecuadamente en las matrices y/o escalas de tiempos que se utilizan para la medida de la productividad industrial (cálculo del OEE, por ejemplo).
• Minimizar las consecuencias de estos fallos.
• Evitarlos en el futuro.

Es decir, nos interesa disponer de metodologías y herramientas que permitan la investigación sistemática para encontrar las causas de un mal comportamiento de nuestro sistema de producción. Existen técnicas muy potentes como las cadenas de Markov o los distintos tipos de simulación. Pero hay otras herramientas más sencillas que pueden aplicarse en grupos de mejora y que permiten obtener resultados razonablemente buenos. Una de ellas es el FTA o Fault Tree Analysis.

Esta técnica se suele denominar probabilística, ya que más que identificar los fallos permite determinar cuantitativamente la probabilidad de que se produzcan. Se basa en escoger una situación no deseada para el sistema (fallo, anomalía, error), comprender el comportamiento del sistema y las posibles causas de esta situación no deseada, así como la probabilidad de que ocurran, y construir un árbol de probabilidad mediante lógica booleana (puertas AND y OR).

Este árbol permite determinar la probabilidad de cada situación no deseada, analizar las posibles mejoras que se podrían hacer en el sistema para reducir esta probabilidad y comprender cómo de robusto es el sistema ante ciertos eventos que pueden provocar las situaciones no deseadas.

Cambio de fecha para el curso de Cloud Computing

Por problemas ajenos a redindustria se ha retrasado hasta el día 27 de Octubre, y además se ha cambiado el horario (será de 17.00 a 21.00 en lugar de en horario de mañana) para que os sea más sencillo asistir.

Disculpad las molestias, os dejo de nuevo el enlace. No dejéis la inscripción para el último momento, porque las plazas están limitadas:

http://www.cel-logistica.org/index.php?seccion=47&accion=detalleNoticia&id=264

ACTUALIZACIÓN del 11 de Octubre: Por causas ajenas a nosotros se ha retrasado el curso indefinidamente, os avisaremos si se celebra en el futuro. Lo sentimos.

No cON Name

Os dejo el enlace a este congreso de seguridad informática en su séptima edición:

http://www.noconname.org/

Se celebra los días 20 y 21 de Octubre en en Barcelona (siempre os quejáis de que sólo anunciamos eventos en Madrid), las ponencias y formaciones son muy interesantes y mañana publican el horario completo de actividades.

RUCT

En los últimos tiempos, dada la proliferación de másters y post-grados públicos y privados, títulos propios y cursos de experto; y la confusión general con Bolonia y los cambios en los planes de estudios, muchos de vosotros os habéis puesto en contacto conmigo para preguntarme acerca de titulaciones concretas y de su validez para opositar, continuar con vuestros estudios, realizar un doctorado, etc.

Por supuesto estaré encantada de seguir ayudando a cualquiera que me pregunte, pero ahora tenéis disponible en la página web del Ministerio de Educación la base de datos del Registro de Universidades, Centros y Títulos (RUCT). Aquí podéis consultar si una titulación es oficial (si está acreditada y ha pasado todos los trámites) y podéis saber en qué BOE se ha publicado su plan de estudios y así comprobar si os vale para vuestros objetivos o no.

Os dejo el enlace:

https://www.educacion.es/ruct/home.do

Curso de Cloud Computing

El próximo jueves 7 de Octubre estaremos en las oficinas del CEL (Centro Español de Logística) en Madrid para dar un curso de 4 horas acerca de Cloud Computing. Comenzaremos a las 9:30 para terminar alrededor de las 14.00.

Os dejo el enlace con toda la información para inscribiros o conocer en profunidad el alcance del seminario que hemos preparado. Esperamos veros por allí:

http://www.cel-logistica.org/index.php?seccion=47&accion=detalleNoticia&id=264

Takt time y Heijunka

Ya hemos hablado en multitud de entradas de las iniciativas de mejora de la productividad basadas en Lean Manufacturing (uno de los enfoques incrementales de mejora más utilizados hoy en día). Hoy nos vamos en centrar en un tipo de iniciativa de mejora de los flujos de producción: evaluación de tiempos Takt y equilibrado de la cadena de producción.

El tiempo Takt (palabra que significa "ritmo" en alemán) es el tiempo máximo que puede tardarse en producir una unidad del producto para conseguir cubrir la demanda. Por lo tanto se calcula como el cociente entre el Production Time y el número de unidades demandadas. En realidad, si queremos ser realistas, para obtener el tiempo Takt real, habría que ponderar este valor con la calidad (Q del OEE) de la producción ya que no todas las unidades producidas llegan al mercado.

Por tanto, de la información o previsiones que se tengan de la demanda del cliente, se puede deducir el ritmo al cual la compañía tiene que producir para satisfacerla. Producir con el Takt time significa que los ritmos de producción y de ventas están sincronizados. Para ello si se modifica la demanda, hay que replanificar la producción y es necesario que nuestra cadena de producción sea flexible.

Aquí aparece el concepto de Heijunka (palabra japonesa como otras tantas asociadas a Lean) o suavizado de la producción. Este concepto implica diseñar cadenas de producción "adaptativas", equilibrando el trabajo que se debe realizar en cada una de las etapas, buscando un tiempo óptimo para cada una de ellas, etc. Para ello se suelen evitar las líneas dedicadas a un solo producto (seríamos muy sensibles a las variaciones en la demanda) y se prefieren líneas capaces de fabricar varios tipos de productos de manera que se amortiguen los efectos de estas variaciones en la demanda. De igual forma se opta por la producción en lotes pequeños en lugar de en lotes grandes. Y también se suelen utilizar otras herramientas Lean como Kanban, One-piece-flow o la producción en celdas de las que hablaremos en entradas futuras.

¿Cuándo recurrir al modelo de Cloud Computing?

Ya hemos definido en entradas anteriores un sistema Cloud como un conjunto de recursos virtualizados que se ofrecen como servicio a través de Internet (los cloud públicos, ya hablaremos en el futuro de las diferencias entre éstos y los privados). Y hemos analizado cómo estos recursos pueden ir desde una infraestructura o plataforma hasta una aplicación completa.

Esto implica que detrás del término Cloud encontramos todos estos conceptos:

• Infraestructura virtualizada.
• Recursos masivos que se emplean bajo demanda.
• Localización dinámica y transparente al usuario.
• Pago por utilización.
• Sin compromisos a largo plazo.
• No hay necesidad de instalar nada.
• Incorporación instantánea de nuevas tecnologías.
• Se utiliza justo lo que se necesita, no es necesario predecir para dimensionar.

Entonces, respondiendo a la pregunta planteada como título de la entrada ¿cuándo se debe escoger este tipo de arquitectura?, podemos proporcionar una serie de guías o recomendaciones básicas:

• Cuando los procesos, aplicaciones y datos están débilmente acoplados.
• Cuando los puntos de integración están bien definidos.
• Cuando no se necesitan altos niveles de control y seguridad.
• Cuando la Web es una plataforma adecuada para nuestro negocio.
• Cuando las aplicaciones son nuevas.
• Cuando nos preocupa el coste de nuestra infraestructura TIC.

Definiciones de Marketing (y II)

La AMA (American Market Association) es una instutición que vela por la promoción y difusión de las técnicas, estrategias, casos y tendencias del marketing.

La AMA define el marketing de esta manera: "Marketing is the activity, set of institutions, and processes for creating, communicating, delivering, and exchanging offerings that have value for customers, clients, partners, and society at large. (Approved October 2007)".

http://www.marketingpower.com/AboutAMA/Pages/DefinitionofMarketing.aspx


Para terminar esta serie de definiciones, acabamos con lo que Philip Kotler define como el Marketing Mantra. En la figura se recoge la esencia de la charla que Kotler dá y que os recomendamos visualicéis en este vídeo.

Definiciones de Marketing (I)

Comenzamos esta serie de entradas de marketing para ingenieros compartiendo con vosotros diferentes definiciones de marketing:

• El marketing son las actividades que lleva a cabo una empresa que tienen como objetivo conocer cuáles son las necesidades de los clientes y satisfacerlas.
• Es un sistema total de actividades empresariales en íntima interacción, destinadas a planificar, fijar precios, promover y distribuir productos y servicios que satisfagan las necesidades de los clientes actuales y potenciales (William J. Stanton. “Fundamentos de Marketing.” Mcgraw-hill 2007).
• Es la actividad humana dirigida a satisfacer necesidades y deseos por medio de un proceso de intercambio. (Philip Kotler. “Marketing: An introduction”. Prentice Hall 1996).
• Es la realización de aquellas actividades que tienen por objeto cumplir la metas de una organización, al anticiparse a los requerimientos del consumidor o cliente y al encauzar un flujo de mercancías aptas a las necesidades y los servicios que el productor presta al consumidor o cliente. (E. Jerome McCarthy. ”Basic Marketing: A Managerial Approach," Richard D. Irwin, Inc. 1975).

Por último esta definición resume las ideas principales recogidas en las anteriores: El marketing promueve procesos de intercambio, con el fin de lograr la satisfacción de todas las partes que intervienen en él. Es decir, el marketing orientado al consumidor/mercado tiene como misión principal satisfacer necesidades, mientras que el marketing como función de la empresa pretende ayudar a alcanzar los objetivos corporativos.

Todavía quedan plazas en nuestro máster

Hola a todos.

Mañana 8 de Septiembre abrimos un plazo extraordinario de preinscripción en el Máster en Investigación en Sistemas Hardware y Software Avanzados para cubrir las plazas que nos quedan.

Ya sabéis que tiene un horario compatible con el trabajo, que es posible seguir las asignaturas a distancia y que es oficial y con precios públicos (se imparte en la Universidad Rey Juan Carlos), por lo que la matrícula son alrededor de 1800 euros. Admitimos tanto ingenieros superiores/licenciados como ingenieros técnicos/diplomados, y si os interesa la I+D+i, os puede abrir las puertas a trabajos de este tipo en el sector privado y al doctorado.

Os dejo el link con toda la información:

http://www.gaapsoluciones.es/MISHSA/

Marketing para ingenieros

¿Por qué entradas relacionadas con Marketing en un Blog orientado específicamente a ingenieros?

Durante los últimos tres años hemos tratado en nuestras entradas temas enmarcados en el ámbito de la informática industrial, de la mejora de la productividad y de la problemática asociada a las áreas productivas de las organizaciones.
m
Si consideramos una organización como un conjunto de procesos corporativos que son ejecutados por personas y sistemas con el fin de obtener un resultado específico, los procesos de producción se enmarcan dentro de la cadena de suministro como un eslabón que es precedido por los procesos de aprovisionamiento y continuado por los procesos de distribución.
n
Por otro lado si consideramos la organización como un sistema compuesto por órganos funcionales, la función de producción está estrechamente ligada con la función de marketing:

• Antes de producir un producto, la función de marketing permite conocer las necesidades y requerimientos de los clientes y establece métodos para desarrollar nuevos productos eficientemente (productos que luego son fabricados masivamente por la función de producción).
• Durante o posteriormente a que el producto sea fabricado, la correcta ejecución de la estrategia de marketing elegida, el desarrollo del producto considerando los aspectos tangibles e intangibles que lo caracterizan, la definición de su política de precio así como la forma de promocionarse y distribuirse, son algunas de las decisiones que deben ser tomadas por los responsables de la función de marketing.

Es normal que en las organizaciones exista desconocimiento mutuo entre las actividades que realizan los responsables del entorno fabril y los responsables de que el producto fabricado sea vendido al segmento de mercado elegido de forma satisfactoria. Por este motivo, creemos interesante desarrollar una nueva etiqueta que denominamos "Marketing para ingenieros" que tiene como fin principal aclarar y/o tratar los aspectos y actividades más importantes que realiza el departamento de marketing de una organización.

Utilizando argot de marketing, analizaremos las variables más importantes que forman el "Marketing-Mix" de una organización (y que tradicionalmente se han clasificado en las 4P´s: Producto, Precio, Distribución/Place y Promoción).
n
Esperamos que esta serie de entradas os resulten interesantes y que os permitan conocer mejor las funciones generales de vuestro departamento de marketing. Obviamente os invitamos a que recomendéis nuestro blog a vuestros responsables de marketing para que también conozcan algo más de los términos y problemáticas que vosotros tratáis normalmente.

Vacaciones

Como todos los años, nos cogemos un descanso para volver después del verano con energías renovadas.

En unas semanas volvemos con nuevas entradas y propuestas.

Buen verano a todos.

¿Qué es un SLA?

Un SLA (Service Level Agreement) no es más que un documento que define la relación entre dos partes: el proveedor de un servicio y su cliente. Si se elabora correctamente, debería identificar y definir las necesidades del cliente, proporcionar un marco para la comprensión mutua, simplificar los aspectos complejos, reducir las zonas de conflicto, fomentar el diálogo en el caso de que estos conflictos surjan y eliminar las expectativas poco realistas.

Con la proliferación de las arquitecturas orientadas a servicios y de los sistemas Cloud, los SLAs son elementos imprescindibles para una correcta prestación de servicios por parte de los proveedores que cumpla con los requisitos de calidad de los clientes. Por desgracia en la mayoría de las áreas no existen formatos estándar para su definición.

Por ello puede ser muy útil tener en cuenta ITIL, que es una guía de buenas prácticas orientada a la gestión de servicios de TI, aunque su campo de aplicación se extiende también a otro tipo de servicios. Puede ser utilizada por y desde los directores de los departamentos de TI y CIOs (Chief Information Officers) hasta los técnicos de apoyo y administradores. Y se puede aplicar a todo tipo de proveedores de servicios que proporcionen estos servicios TI a clientes externos.

La última versión de ITIL es la 3, que se encuentra orientada principalmente al ciclo de vida de los servicios. Esta versión 3 aún no se encuentra implantada con una gran extensión, pero uno de los conceptos más importantes que maneja es el de SLA (Service Level Agreement), documento que aunque no haya tenido su origen en ITIL, sí que ha difundido esta metodología proporcionando una serie de mejores prácticas y recomendaciones que son lo más parecido que podemos encontrar hoy en día a un estándar para su definición (lo es de facto).

II Curso de programación de GPU para procesado de imágenes

Después de la primera edición que tuvo llugar el año pasado, este año el Instituo de Óptica Daza de Valdés del CSIC vuelve a contar con nosotros para impartir este curso.

Pero hay algunas novedades: se separan los cursos de FPGA y GPU, y esta última parte, que es la que impartimos nosotros, será este año de 20 horas, por lo que tendremos tiempo de ver los contenidos con más profundidad y de practicar más la programación con CUDA en diferentes entornos.

Será los días 22, 23 y 24 de Septiembre, os dejo el link con el tríptico del curso por si os interesa:

http://www.iv.optica.csic.es/page19/page5/assets/triptico_GPU_2010.pdf

Material conferencia CIIP

Este año nos han invitado a dar una conferencia acerca de CIIP (Protección de Infraestructuras de Información Críticas, ya hemos hablado de este tema en alguna entrada anterior) en el III Curso de Verano de Seguridad Informática de la Universidad Europea de Madrid celebrado estos días en Valencia.

La impartió Antonio Guzmán, y me ha pasado el material para que os lo deje disponible a todos. Espero que os resulte interesante:

Seguridad en Infraestructuras Críticas.pdf

ISA95

El estándar ISA95 especifica cómo integrar aplicaciones de negocio (oficinas) con aplicaciones industriales (planta). Este estándar responde básicamente a la necesidad de integración del sistema ERP con el sistema MES.

La integración de estos dos tipos de sistemas puede tener unos beneficios enormes desde el punto de vista de la productividad industrial. Pero es tremendamente complicada debido a las diferencias de terminología, temporización, modelos, cultura, etc.

El estándar está constituido por cinco partes:

• ISA-95.01 Enterprise-Control System Integration: Models & Terminology.
• ISA-95.02 Enterprise-Control System Integration: Object Models & Attributes.
• ISA-95.03 Activity Models of Manufacturing Operations Management.
• Draft ISA-95.04 Object Models & Attributes of Manufacturing Operations Management.
• ISA-95.05 Business To Manufacturing Transactions.

En la parte 1 se definen la terminología y el modelo de objetos que permiten integrar las aplicaciones en el dominio de negocio y en del dominio industrial: información que deben intercambiarse. los sistemas ERP y MES. La parte 2 especifica los atributos de los objetos definidos en la parte 1, por lo que es la que permite diseñar los esquemas XML, las bases de datos compartidas, etc.

Las partes 3 y 4 definen el modelo de planta que se debe utilizar para describir el nivel 3, en concreto se dedica a la descripción de funciones y responsabilidades.

Y en la parte 5, utilizando este modelo, se definen las transacciones que se pueden realizar entre las aplicaciones de negocio y las de planta.

Además ISA95 proporciona una serie de mejores prácticas para diseñar esquemas XML a partir de el estándar. De aquí proviene B2MML, que permite la utilización de ISA95 mediante transferencia de ficheros estándar. En este enlace os podéis descargar documentación y de manera libre, directamente los esquemas XML, que además no son muy complicados de entender:

http://www.wbf.org/catalog/b2mml.php

En futuras entradas explicaremos las diferentes partes de este estándar con algo más de profundidad.

Recomendaciones para el proceso de medida de la productividad industrial

En anteriores entradas hemos visto alguna de las métricas que pueden ser utilizadas para llevar a cabo la medida de la productividad industrial. Una vez seleccionadas, debe realizarse el proceso de medida y para ello os proponemos las siguientes recomendaciones:

1.- Medir lo menos posible, comenzando por alguna línea piloto, zona de proceso, etc.

2.- Medir para para mejorar. Siempre debe existir un objetivo que alcanzar.

3.- Medir donde se intuye/sabe que están los problemas. En este sentido, la involucración de las personas que conocen la planta es fundamental (operarios, ingenieros de mantenimiento, procesistas...).
Es decir, el proceso de medida debe hacerse en "cantidad" y "calidad" suficiente como para permitir su posterior análisis e interpretación.

4.- Es importante tener en cuenta otras dos variables: coste y tiempo. Los procesos de medida incurren en costes adicionales y suponen un carga extra de trabajo para las personas que lo llevan a cabo.

5.- Los medios disponibles para recoger la información son dos: la recolección manual y la automática. Es posible llevar a cabo un proceso de mejora basándose en una recolección manual de datos, de hecho la mayoría de empresas lo realizan actualment de esta manera, pero no cabe duda que la recolección automática de datos permite que la información recogida sea más exácta y descarga a las personas que tienen que llevar a cabo la captura de información.

En cualquiera de los dos modos de recolección hay que evitar manejar información incompleta, imprecisa u obsoleta. En caso contrario las interpretaciones podrían llevarnos a extraer conclusiones erróneas. Dentro de un proceso de mejora continua, la medida no se hace una sola vez. Se trata de un proceso iterativo (de ahí el nombre de mejora continua).

6.- Por último os proponemos la utilización de estas matrices de variables de medida de productividad, que os pueden ayudar a realizar vuestros procesos de medida. Puede observarse que en la primera matriz se definen:

• Dimensiones de la productividad: cantidad, calidad, tiempo y coste.
• Los aspectos que debo tener en cuenta durante el proceso de medida: insumos, procesos y resultados.
• Se plantean una serie de preguntas que permiten medir la productividad.

En la segunda matriz, se asocian "métricas no estándares" que permiten dar respuesta a las preguntas planteadas, es decir permiten cuantificar el estado de los aspectos medidos.

Diseño y evaluación de arquitecturas de computadoras

Por fin está en las librerías la primera edición de nuestro libro de Arquitectura de Computadores editado por Prentice Hall (Pearson).

Este libro de texto se centra en el diseño y evaluación de arquitecturas de computadores que incorporen las técnicas de aumento de prestaciones actuales en el diseño del procesador o procesadores, la jerarquía de memoria y el sistema de E/S.

Se trata de un libro de texto, que no ha sido concebido como libro de consulta o de referencia, sino como una herramienta muy potente para el estudio autónomo y/o dirigido de los alumnos de las titulaciones relacionadas con la informática, las tecnologías de la información y las comunicaciones. Y para que cualquier persona interesada en estos temas pueda acercarse a la materia con un libro manejable de unas 350 páginas.

Este libro está adaptado a los nuevos planes de estudios universitarios, es accesible, ameno y está escrito con un enfoque completamente pedagógico (basado en la utilización de figuras ilustrativas, ejemplos resueltos, casos prácticos, pruebas de autoevaluación, resúmenes de conceptos importantes) que surge de la experiencia de años impartiendo materias en el área de Arquitectura de Computadores de los dos autores del libro. Además este libro lleva asociado un sitio web con recursos adicionales para estudiantes y profesores.

Desde esta perspectiva didáctica, el libro se estructura en seis capítulos cuyo objetivo es el aprendizaje basado en competencias. Estos capítulos se centran en el estudio del diseño del procesador, la jerarquía de memoria y el sistema de E/S, el aumento de prestaciones del procesador, la mejora de la jerarquía de memoria y del sistema de E/S, el diseño de sistemas multiprocesador y multicomputador y la evaluación del rendimiento de las arquitecturas.

Os dejo a continuación toda la información necesaria para que lo podáis localizar:

Diseño y evaluación de arquitecturas de computadoras
Marta Beltrán Pardo y Antonio Guzmán Sacristán
Prentice Hall (Pearson Educación)
ISBN: 978-84-8322-650-6

SPEC

Hace mucho tiempo que os debía una entrada hablando de los benchmarks de SPEC. Standard Performance Evaluation Corporation (SPEC) es una organización que se encarga de proponer y mantener conjuntos de aplicaciones benchmark para diferentes campos de aplicación, y de estandarizar las métricas y metodologías de medida asociadas a estos conjuntos.

Quizás el más conocido sea SPEC CPU, que es el conjunto de benchmarks más utilizado para caracterizar el rendimiento de CPUs en sistemas de propósito general. (casi siempre PCs y servidores). Por ejemplo, el conjunto SPEC CPU 2006 está compuesto por 29 aplicaciones que evalúan el rendimiento del sistema tanto en operaciones con enteros (12 de las aplicaciones) como en operaciones en coma flotante (las otras 17). Dentro de este conjunto de benchmarks hay aplicaciones de compilación y programación en diferentes lenguajes, compresión de diferentes tipos de datos, algoritmos genéticos, inteligencia artificial y juegos, simulación, cómputo científico, etc.

Resumiendo, se trata de un conjunto de aplicaciones que representa de la manera más completa posible la carga de trabajo habitual de los computadores de propósito general actuales. Para todos los benchmarks existe una documentación que describe exhaustivamente el tipo de trabajo que realizan, las entradas que necesitan, las salidas que producen, el lenguaje de programación en el que están escritos y los aspectos relacionados con su portabilidad (ya que se evalúan con estos benchmarks una gran variedad de plataformas).

SPEC no sólo proporciona este conjunto de aplicaciones sino también una métrica de rendimiento asociada y una metodología para su medida. Además SPEC publica en su página web (www.spec.org) evaluaciones de rendimiento de multitud de sistemas y plataformas por lo que se utiliza muy a menudo para hacer comparaciones de rendimiento y para encontrar configuraciones óptimas.

Podéis ver en la web de SPEC que además de este conjunto de aplicaciones para medir el rendimiento de computaroes de propósito general, existen otros para cuantificar las prestaciones de tarjetas gráficas, servidores web, etc; y que además se están desarrollando otros para arquitecturas SOA o virtualizaciones. Algunos de estos conjuntos se pueden descargar libremente, pero la mayoría, aunque con un precio asequible, son de pago.