Mostrando entradas con la etiqueta Interface Analysis. Mostrar todas las entradas
Mostrando entradas con la etiqueta Interface Analysis. Mostrar todas las entradas

domingo, 13 de junio de 2021

Técnicas para generar, levantar y retener ideas, conocimiento y experiencia operativa en las empresas



Gran problema tiene una empresa  si no tiene un plan acerca de cómo generar, levantar y retener el conocimiento. Por suerte o por desgracia, el esfuerzo que tienen que hacer las organizaciones y las personas para construir y monetizar el know-how requiere mucho tiempo (lustros, decenios) y dinero, y sin embargo perderlo es cuestión de, como mucho tres años, en ocasiones meses. En otras palabras, no podemos permitirnos el lujo de tirar por la borda tanto esfuerzo.

Porque no es lo mismo talento (asociado a personas) que conocimiento (que debe ser compartido entre empresa y empleado), el presente post pretende dar a conocer una serie de herramientas para ideas, prototipos, pilotos, productos y sus procesos asociados en sus diferentes momentos de vida, para trabajadores y empresarios, y asegurar que todo queda en casa. 



Este enfoque bebe de tres pilares principales:
  • Los sistemas con los que interactúa el objeto alcance del estudio, que se declaran en el Diagrama de Límites (Boundary Diagram) y el Análisis de Interferencias con el resto de sistemas (Interface Analysis).
  • Una Ingeniería Robusta, que se define a través del Parameter Diagram y el Robustness Checklist.
  • Un Histórico de Calidad, que nos indica qué ha pasado en los últimos meses /años y qué hemos aprendido.

A todo este proceso se le llama FMA (Failure Mode Avoidance Process) - Proceso de Evitación de Modos de Fallos, y debe concluir, 
  • Primero, con un AMFE de Diseño (dirigido a atacar los modos de fallo del producto y su diseño) y un AMFE de Proceso (dirigido a atacar los modos de fallo que aparecerán durante la fabricación del producto en una línea de producción).
  • Más tarde y como conclusión del primer paso, en un Plan de Control con sus Instrucciones de Trabajo correspondientes.

Nota: si bien este enfoque ha surgido inicialmente y está orientado a la fabricación de componentes y piezas de producción, se puede reformular y adaptar, también, a cualquier tipo de servicio o incluso desarrollo de Software. 

¿Y todo esto por qué lo hacemos?





Pues por ahorrar tiempo y dinero, básicamente. Y por hacer las cosas bien a la primera, también. El gráfico muestra como, 
  1. En etapas muy tempranas del producto la generación de modos de fallos es fácil y sencilla: en muchas ocasiones es obvia y fácil de provocar, y el coste es mínimo.
  2. Conforme vamos evolucionándolo y lo testeamos frente a normativa y especificaciones correspondientes, aparecen nuevas oleadas de modos de fallos que deben ser eliminados en nuevas versiones del producto. Similarmente sucede conforme vamos desarrollando la línea de producción y la industrialización del producto.
  3. Si bien hasta ahora el coste de las actividades y medidas que se toman es relativamente pequeño, sobre todo cuando esperamos producir decenas de miles de piezas, al acercamos a los hitos de fabricación masiva de un producto, los costes por errores y por tanto cambios de ingeniería se van incrementando incesantemente y casi de manera casi exponencial
  4. Si, ya en fabricación masiva, no hemos llegado a un producto y un proceso de producción robusto, los costes asociados por garantías se nos pueden ir de las manos.

Es por ello que una identificación temprana de modos de fallo nos ayudará a tener un diseño robusto del producto y por ende lograr una mayor satisfacción del cliente. Pero el camino es largo y tedioso (hablamos de años), si bien la recompensa también es grande y gratificante. Empezaremos a explicarlo de lo "sencillo" a lo "complicado", de lo "entendible" a lo "complejo". 

Pilar I. Quality History - Histórico de Calidad


Tiene dos vertientes:
  • un Plan de FMA
  • Tener un registro de problemas de calidad

El Plan de FMA tiene el propósito de describir de manera pictográfica qué herramientas (por qué, cuando y cómo) vamos a emplear para levantar, capturar y retener conocimiento: más vale ser selectivo y no dispararle a todo.  A través de un Plan de FMA podremos: 
  • Priorizar los sistemas a trabajar, en base a su complejidad, impacto de una nueva tecnología, o criticidad del sistema.
  • Priorizar los problemas a solucionar, en base a su severidad e impacto.
  • Priorizar las herramientas a utilizar: como decíamos antes, no siempre es necesario hacer uso de todas ellas. La experiencia y el olfato nos ayudarán a elegir la mejor herramientas para acabar con nuestros problemas.
  • Identificar en qué momento hay que emplear cada una de las herramientas seleccionadas
Al final del día, el FMA Plan ayudará a la Dirección de la Empresa y también a cualquier recién llegado a conocer, mediante un mapa y a alto nivel, qué herramientas se han empleado. Es un documento vivo, que cobra especial relevancia sobre todo al inicio y al final del proceso.  

En cuanto al Histórico de Calidad, tiene el siguiente propósito
  • Entender y explicar los fallos, tanto durante el proceso de producción como las garantías que lleguen del mercado.
    • Se trata de reconocer la voz de las diferentes partes de interés
    • Esto incluye aprender las necesidades del cliente, tanto externo como interno, incluso aunque no las verbalice o no las sepa explicar. Para ello recurriremos al análisis y se usará la herramienta 8D.
  • Entender el tipo de retroalimentación (feedback) de estas partes de interés: 
    • ¿Se trata de una insatisfacción o un fallo?
    • ¿Cómo de grave es? (severidad)

Con la ayuda del Histórico de Calidad alcanzaremos los siguientes objetivos:
  • Validar asunciones mediante el diseño de experimentos y otras herramientas de análisis
  • Conocer la causa raíz y los puntos de escape de los problemas que hemos tenido:
    • ¿Cuál ha sido el mecanismo de fallo?
    • ¿Ha sido el fallo una gap en la Especificación, en los ensayos que se han realizado?
    • ¿Ha sido un fallo de producto, o de proceso?
    • ¿Dónde, en el proceso de ingeniería, se ha producido el fallo? ¿En qué fase?
  • Contra medidas: 
    • ¿Qué características de diseño / especificaciones han cambiado antes o después de que ocurriera el problema?
  • Mejoras en ensayos:
    • ¿Cuál ha sido el contenido de los ensayos?
    • ¿Algún ensayo ha cambiado su procedimiento?


Pilar II. System Definition - Definición del Sistema


Mediante la Definición del Sistema conseguiremos definir el alcance de lo que queremos analizar (sus límites), hacer zoom y poder visualizarlo con vista de halcón o a nivel de detalle (en función de las necesidades que tengamos) y entender su complejidad, así como de qué manera interactúa con sus elementos vecinos limítrofes importantes.

La definición del sistema se compone de dos documentos fundamentalmente:
  • El Diagrama de Bloques & Límites (Block & Boundary Diagram)
  • La Matriz o Tabla de Interferencias (Interface Matrix or Interface Table)

El proceso es el siguiente: Boundary Diagram > Interface Matrix > DFMEA

No olvidar:
  • Es importante identificar los elementos principales, comprender cómo interactúan entre sí y cómo pueden interactuar con los sistemas externos.
  • Dado que las interferencias pueden contener hasta el cincuenta por ciento o más del total de modos de fallo, es esencial que cualquier AMFE considere cuidadosamente las interferencias entre subsistemas y componentes, además del contenido de los subsistemas y componentes mismos.

Boundary Diagram

Un Diagrama de Límites es una ilustración gráfica de relaciones que existen entre los subsistemas, montajes, subconjuntos y componentes dentro del objeto en estudio, así como las interferencias con los sistemas y entornos vecinos.

Características principales de un Boundary Diagram (BD):
  • Al comenzar un nuevo diseño: un diagrama de límites podemos pintarlo con unos pocos bloques que representarán las funciones principales y sus relaciones a nivel del sistema.
  • A medida que madura el diseño: se pueden revisar los diagramas de límites o desarrollar otros adicionales para ilustrar un nivel de detalle más bajo, hasta el nivel de los componentes.
  • ¡Ojo! El Boundary Diagram es un documento obligatorio del DMFEA puesto que, a posteriori, el primero definirá el alcance del segundo. Además, el BD divide los DFMEA del Sistema en otros DFMEA más manejables.
  • Al fin y al cabo, lo que viene a hacer un BD es proporcionar fuentes de información al FMEA:
    • Salidas, previstas como funciones
    • Las interacciones del sistema pueden ayudar a identificar la (s) causa (s) de fallo




Pasos para construirlo:
  1. Identificar los elementos principales.
  2. Dibujar un diagrama de bloques que incluya todas las piezas, subconjuntos o sistemas que se conectan directamente.
  3. Considerar las relaciones entre todos los elementos del diagrama de bloques e ilustrar cómo interactúan entre sí. Resp: equipo de FMEA
  4. Ilustrar cómo interactúan los bloques entre sí - y aquí ya incorporamos la Matriz de Interferencias, que explicamos a continuación. Éstas pueden ser:
      • Conexión física (por ejemplo: soportes, pernos, abrazaderas y varios tipos de conectores).
      • Intercambio de material (por ejemplo: aire comprimido, fluidos hidráulicos o cualquier otro fluido o intercambio de material).
      • Transferencia de energía (por ejemplo, transferencia de calor, fricción o transferencia de movimiento mediante eslabones de cadena o engranajes).
      • Intercambio de datos (por ejemplo, entradas o salidas de computadora, bundles de cables, señales eléctricas o cualquier otro tipo de intercambio de información).
    • 5. Ilustrar cómo pueden interactuar con los sistemas externos:
      • El propósito es tener una imagen holística del sistema en estudio.
    Comentarios de interés y Q&A relacionados con el Diagrama de Bloques:
    • Si somos capaces de llegar al Paso 4, entonces podemos decir que hemos conseguido un pequeño éxito.
    • Relacionado con los elementos a mostrar:
      • Se han de mostrar todas las piezas necesarias para que el sistema funcione.
      • También se considerarán los componentes cercanos.
    • Jerarquía:
      • Se ha de visualizar siempre un subsistema superior y uno inferior.
      • Debemos incluir la interfaz con el cliente.
    • Interferencias: cada persona, lugar y cosa deben ser considerados
    Análisis de Interferencias

    Una Matriz de Interferencias de un sistema ilustra las relaciones entre los subsistemas, montajes, submontajes y componentes dentro del objeto en estudio, así como las interfaces con los sistemas y entornos vecinos.

    Respecto al Análisis de Interferencias, podemos decir lo siguiente:
    • Se han de mostrar todos los componentes del sistema y los componentes de interfaz.
    • De la misma manera, todos los flujos de energía / señales o transferencias de fuerza.
    • Se han de cuantificar las interfaces en términos medibles de ingeniería.
    • Como recomendación, programar valores específicos específicos de tecnologías / hardware.
    • Es preciso identificar a los propietarios de interfaces transfronterizas.
    • Las interfaces deben tener una magnitud y unidades de medida acordadas.
    • El alcance de cada bloque debe estar claramente identificado.


    Pilar III. Robust Engineering - Una Ingeniería Robusta


    Este tercer y último pilar se centra principalmente en:
    • La(s) función(es) y cómo conseguirla(s)
    • Identificar claramente todo lo que influye sobre esa función
    • Qué se puede controlar (factores de control)
    • Qué no se puede controlar razonablemente (factores de ruido)
    Este pilar es particularmente importante porque las funciones que se identifiquen serán entradas clave para un DFMEA robusto. Se divide en:
    • P-Diagram, o Parameter Diagram
    • Robustness Cheklist

    P-Diagram o Parameter Diagram


    La manera de encarar este documento es la siguiente: para cada función específica, podemos:
    • Analizar fallos de robustez
    • Conocer el impacto de las nuevas tecnologías
    • Estudiar las relaciones entre entradas y salidas
    • Contemplar los ruidos:
      • Podremos identificarlos, si bien su origen se estudia en el Análisis de Interferencias y Diagrama de Límites
      • En la medida de los posible, podemos describirlos en unidades físicas, medirlos y rastrearlos
    • Tener en cuenta cambios de salida específicos, tanto de magnitud como de rendimiento
    • Llegar a entender las transformaciones que deban de ocurrir
    No debemos olvidar que el Robust Engineering se centra en la ingeniería, y da respuesta a las decisiones de diseño necesarias para optimizar la producción.

    Buenas prácticas del documento
    • Ir función a función
    • Dibujar un diagrama por función
    • En principio, analizar sólo las funciones clave, para luego pasar a las secundarias.
    • Respecto a las pruebas y ensayos que se hagan, conviene:
      • Identificar contramedidas e influencias requeridas en las pruebas
      • Confirmar que las pruebas que se hagan representan situaciones "reales"
      • Asegurar que las pruebas incluyan las características adecuadas

    Ventajas del documento

    Con este documento ganamos las siguientes habilidades:
    • Permite identificar las entradas y salidas
    • Permite ver de qué manera se transforma el material, la energía o la información
    • Permite dividir y trocear los fallos y las pérdidas
    • Las fallos de funcionamiento se pueden medir en función de la salida elegida
    • El desvío o las pérdidas se pueden describir como salidas independientes
    • Permite conocer qué influencias impactan en el rendimiento

    Robustness Checklist (RCL)


    Este documento tiene un objetivo doble:
    • Por un lado, comprender las interacciones entre los factores de ruido y los modos de fallo
    • Por el otro, identificar y mejorar la definición de los ensayos a realizar y así garantizar la cobertura de las interacciones del modo de fallo
    ¿Con qué mentalidad debemos encarar este documento?
    • Para algunas funciones importantes, el RCL permite, de manera sistemática, evaluar la utilidad de los ensayos y métodos de evaluación.
    • Simplificando: esto es, para cada periodo de tiempo debemos centrarnos en aquellas funciones que van experimentando problemas de solidez o están en riesgo debido a cambios en la aplicación / el entorno operativo. Para ello debemos usar trend charts (dinámicos), no pie charts (estáticos).
    No debemos olvidar que el RCL se puede utilizar para justificar las calificaciones de los controles de detección en DFMEA

    Buenas prácticas
    • El RCL nos ayudará a centrarnos en algunas funciones y modos de fallo cuando lo justifique el historial de calidad o la evaluación de riesgos.
    • Los RCL simples son más fáciles de entender y permiten a los equipos concentrarse en el análisis y no en administrar la herramienta.
    • Los valores de Ruido aplicados en los ensayos se confirman aquí.
    • El RCL debe ser usado como una oportunidad para mejorar los tests.
    • Las mejoras que se encuentren para los ensayos deberán ser incluidos como Acción recomendada en DFMEA y confirmarse en Revisiones de diseño.

    Pilar IV. El DFMEA o AMFE de Diseño


    Un DFMEA o Análisis de Modos de Fallo y Errores del Diseño es una formalización, un "acuerdo legal" entre las partes, acerca del diseño y la revisiones que se han llevado a cabo. Es un documento muy útil para comunicar y justificar mejoras en ingeniería, pruebas y fabricación.

    ¿Por qué hace falta un DFMEA o un AMFE de Diseño? Por que nos ayuda a gestionar el riesgo desde el punto de vista del producto. Y es que el DFMEA permite:
    • Evaluar los controles implantados para un diseño robusto.
    • Identificar acciones para reducir el riesgo.
    • Establecer controles tanto de detección como de prevención, para toda la vida útil del producto.
    • Establecer la acciones pertinentes:
      • Priorizado en función del riesgo
      • Reduciendo la gravedad, ocurrencia o detección mediante planes de acción
      • Mejorando el diseño y mejorando los tests.
    • Documentar el análisis.

    ¿Con qué mentalidad debe afrontarse el documento?
    • Con la idea de hacer un análisis exhaustivo, en el que se deben considerar todas las funciones listadas en los documentos anteriores.
    • Con la idea de definir todos los elementos: componentes, aspectos de ingeniería, funciones, causas y controles.
    • Con el propósito de documentar el conocimiento existente & identificar lo desconocido.
    Al fin y al cabo, un DFMEA es como la columna vertebral del FMA Plan. Y esto es así porque un DFMEA reune todas las demás herramientas descritas anteriormente para evitar modos de fallo, y documenta los resultados clave en un solo análisis.

    Como podemos observar, de las herramienta analizadas hasta ahora:
    • El Histórico de Calidad, Parameter Diagram y Robustness Checklist harán aportaciones al DFMEA
    • El Diagrama de Bloques y la Matriz de Interferencias son herramientas de apoyo durante la ejecución de DFMEA.
    • El Parameter Diagram y Robustness Checklist serán también resultados del DFMEA.

    El DFMEA se puede dividir en dos partes: una primera parte en la que se han de describir de manera tácita y precisa las funciones esperadas, y por tanto:
    • Describir el desempeño esperado
    • Incluya requisitos "tácitos"
    • Describir los modos de fallo
    • Cuantificar la magnitud del incumplimiento a través de tablas pre establecidas, en cuanto a gravedad y ocurrencia
    • Identificar las causas detalladas
    • Explicar los mecanismos específicos del modo de fallo
    • Confirmar las contramedidas a adoptar
    Una segunda parte en la que se analizan los fallos y se tratan de evitar los errores:
    • Descripción de los fallos que pueden ocurrir y que ya han ocurrido 
    • Análisis de estos fallos, y cómo prevenirlos
    • Evaluar las consecuencias 
    • Explicar por qué el diseño o los tests previstos no permitirán que los fallos se escapen de los Quality Gates previstos


    Y llegados a este punto... ¿Cómo termina todo?

    Pilar V. El DVPV Plan


    Toda la historia para acabar, al fin, con una batería de ensayos analíticos y físicos que nos permitirán:
    • Verificar el desempeño
    • Verificar la ausencia de modos de fallo
    Los DVPVs no son más que ensayos que nos tienen que permitir asegurar:
    • Verificar el diseño (DV): Análisis o pruebas ejecutados para demostrar que los diseños nuevos o modificados, o las nuevas aplicaciones de diseños existentes, cumplirán con las expectativas del cliente, en el entorno previsto, durante la vida útil del producto.
    • Verificar el producto en el proceso de producción (PV): Análisis o pruebas ejecutados para validar que los productos elaborados en líneas y procesos de producción, a partir de herramientas, cumplirán con las expectativas del cliente, en el entorno previsto, durante la vida útil del producto.

    Así pues, el DVPV Plan deberá asegurarnos: 
    • que todos los modos y causas de fallo estén cubiertos
    • que los ruidos representen correctamente la realidad y están, en la medida de lo posible, controlados
    • que el diseño cumpla con los requisitos en presencia de todos los factores de ruido significativos.
    • Verificar que las piezas de producción cumplan con los requisitos en presencia de todos los factores de ruido significativos.
    El DVPV es un documento vivo que se alimenta de las herramientas FMA descritas en este post, y que por tanto también debe ser objeto de refinamiento y mejora, como el resto de documentos descritos.

    Buenas prácticas a tener en cuenta son:
    • Asegurar que se incluyen los factores de ruido, durante toda la vida útil del producto
    • Ojo con el tamaño de la muestra, pues debe ser estadísticamente significativo.
    • Los criterios de aceptación deben ser acordados entre todas las partes, y deben ser medibles (fundamental).
    • Merece la pena poner el foco en las pruebas de componentes críticos identificados

    Conclusiones


    Si has llegado hasta aquí, felicidades. Si además has implantado todas y cada una de estas herramientas, la enhorabuena es doble. Porque no es fácil, y porque requieren muchos recursos y mucho conocimiento.

    Dicho esto y volviendo al inicio del documento, ganar la habilidad de generar, levantar y retener talento (no entendido como personas, sino como ideas), es un factor de competitividad que no está resuelto a fecha de hoy, más estos documentos, convenientemente estructurados, ayudan sin duda a aterrizar el tremendo reto. 





      


    domingo, 28 de marzo de 2021

    Buenas prácticas para lanzar proyectos de I+D sin morir en el intento


    Lanzar un proyecto nunca es fácil: los actores y condicionantes a considerar son innumerables, el reto y el riesgo es alto, tanto que puede que se nos pase por la cabeza rendirnos antes incluso de empezar. A continuación se detalla una serie de consejos sencillos, junto con una sistemática de trabajo que, bien dirigida y trabajada, proporciona resultados óptimos en tiempo récord. 


    El enfoque que se propone en el siguiente post es el de hacer uso de los pasos para implantar una Gestión por Procesos, reformulando algunas de las entradas para incorporar a los actores relevantes en un proyecto de I+D (el Centro de Investigación, la start-up tecnológica) y acomodando a cada uno de los actores participantes con sus roles y responsabilidades claramente definidas.

    Las ventajas de la propuesta que se expone son las siguientes:
    • sólo hace falta un papel y un lápiz para darle forma, o en su defecto, una hoja excel con las pestañas correspondientes.
    • es independiente del número de departamentos o empresas que participan: esto es importante, pues en muchas ocasiones los proyectos de I+D se estructuran mediante un Consorcio.
    • sirve para huir del folio en blanco y, en tiempo récord, poner a trabajar a los equipos
    • empodera a las personas, definiendo claramente quién es responsable de qué
    • elimina zonas grises a base de iteraciones
    • son documentos vivos, siempre sujetos a revisión y mejora
    • las preguntas que nos hagamos en cada una las fases en las que nos encontremos las podemos acomodar al proyecto que queramos lanzar
    Este post no pretende explicar en detalle una sistemática, tampoco es un salvavidas: simplemente pretende generar curiosidad, retar al lector y eliminar barreras a través de herramientas que simplifican una actividad en ocasiones dura y compleja.  Se proponen a continuación los siguientes pasos:

    I. Hacer uso de la Gestión por Procesos

    Hacer uso del enfoque por procesos como filosofía implica darle una vuelta a la organización de una empresa, y este comentario también es válido para un proyecto. No se trata tan sólo de mirar a la empresa de izquierda a derecha en lugar de arriba abajo: esto va de profundizar en cada una de las etapas hasta el nivel de actividad, y para cada una de ellas, plasmar, de la manera más sucinta posible:

    • cuál es su entrada / entradas
    • cuál es su salida / salidas
    • las tareas a realizar
    • quién es el propietario de esa actividad, con nombre y apellidos
    • cómo medir esa actividad: plantear una serie de KPIs, que puedan ser medibles de manera cuantitativa
    • establecer una serie de objetivos

    Pero antes de todo esto, es importante hacer un mapa de procesos a alto nivel que permita pintar la empresa en un sólo folio, identificando los clientes a la izquierda y a la derecha, y luego en el cuerpo de la descripción, los procesos clave o core, los de apoyo, y los estratégicos. Y luego hacer lo mismo para cada uno de los procesos identificados en el folio. 

    Los pasos para aterrizar una Gestión por Procesos de manera constructiva y sistemática son los siguientes, para cada una de las cajas identificas en ese Mapa de Procesos de nivel I que se ha desarrollar:


    Hoy nos detendremos sólo en aquellas fases de la Gestión por Procesos que:

    • Uno, son reformuladas para asegurar que tenemos en cuenta las actividades de I+D, y 
    • Dos, fuerzan a todas las partes de interés a que salgan de su zona de confort y actúen de manera disruptiva.


    Son las siguientes:

    4. Mapa de actividades. Pestaña fundamental, puesto que incorporamos sin ningún genero de duda el barniz de I+D al proyecto. Ahora somos Research Centric. ¿Y esto cómo se hace? Colocando en el centro a los Institutos de I+D de turno, de manera que le demos el protagonismo que se merece.  Esta no es más que una manera gráfica de no sólo ponerlos en el foco, sino además de empoderarles y que todo pase por ellos y se les involucre en todas y cada una de las actividades.



    11. Pain Points. Se trata de listar todas aquellas desalineaciones encontradas, problemas que requieren ser escalados o la prestación de una atención especial: sobre todo las relacionadas con las actividades de I+D. Se puede hacer uso la sistemática 8D para su resolución:

    • Descripción del Pain
    • Causa Raiz
    • Plan de Acción
    • Responsable
    • Status

    12. Oportunidades. Uno sabe como empieza un proyecto de I+D, pero nunca cómo va a terminar. Esto es parte de lo divertido y al mismo tiempo lo duro: imagina vivir todo el día fuera de la zona de confort: pues eso. Como parte del proceso de captura de conocimiento, es importante listar todas estas oportunidades que van surgiendo, para más tarde priorizarlas e incorporarlas al pipeline de actividades a medio y largo plazo. El contenido mínimo de este punto debe ser, de manera sucinta:

    • Descripción de la Oportunidad
    • Origen de la Oportunidad
    • Qué pinta tiene el éxito
    • Responsable
    • Plan de Acción
    • Status

    II. Gannt de detalle

    Una vez tenemos todas los procesos a alto y bajo nivel identificados y un muy alto nivel de acuerdo entre los participantes, con la actividades relacionadas entre ellas a través de las entradas y salidas, podemos afrontar un Gannt de detalle con el que podremos:

    • Reflejar las etapas del proyecto, así como los hitos relevantes.
    • Determinar las tareas principales a desarrollar, así como su duración.
    • Entender las correlaciones entre cada una de las actividades.
    • Establecer la lista de prioridades.
    • Distribuir los recursos necesarios.
    • Asignar las tareas a cada persona o equipo de trabajo.
    • Conocer el camino crítico

    Las principales ventajas que encontramos con este Gannt son:
    • Visualizar de una sola vez el cronograma global del proyecto, lo que resulta muy práctico para saber las fases y tareas que se llevarán a cabo, los tiempos previstos y la evolución de los mismos.
    • Discutir los plazos de manera abierta, que se verán más tarde reflejados en el cronograma: el planteamiento de un diagrama de Gantt debe hacerse en base a fines totalmente alcanzables, porque si se hace sin haber reflexionado antes sobre la capacidad real que tenemos no servirá de nada. 
    • Facilita la monitorización de los objetivos y da respuesta a si se cumplirán o no. Esto es así porque habremos descompuesto el proceso en diversas actividades, con sus objetivos.
    • Es una eficaz herramienta de comunicación.

    III. Establecer una sistemática para el levantamiento y retención de conocimiento

    De poco habrá servido todo lo que hacemos si no tenemos un plan acerca de cómo levantar y retener el conocimiento. Por suerte o por desgracia, el esfuerzo que tienen que hacer las organizaciones y a las personas para levantar y retener el conocimiento requiere mucho tiempo (lustros, decenios) y dinero, y sin embargo perderlo es cuestión de, como mucho tres años, en ocasiones meses. Por eso no podemos permitirnos el lujo de tirar por la borda tanto esfuerzo



    Este enfoque bebe de tres columnas principales:
    • Una Ingeniería robusta, que se define a través del Parameter Diagram y el Robustness Checklist.
      • En concreto, el P-Diagram permite:
        • 1. Centrarse en el logro de la función, 
        • 2. Identificar claramente todas las influencias a esa función, 
        • 3. Qué se puede controlar (factores de control), 
        • 4. Qué no se puede controlar razonablemente (factores de ruido). 
      • Un buen P-Diagram es una entrada clave para un análisis DFMEA robusto.
    • El Histórico de Calidad, que nos indica qué ha pasado en los últimos meses /años y qué hemos aprendido.
    • Los sistemas con los que mi elemento bajo estudio interactúa, que se declaran en el Diagrama de Límites (Boundary Diagram) y el Análisis de Interferencias con el resto de sistemas:
      • Acerca del Boundary Diagram: 
        • 1. Permite definir el alcance del análisis, 
        • 2. Visualiza el diseño, 
        • 3. Nos ayuda a comprender la complejidad y las interacciones del sistema y 
        • 4. Permite conocer los sistemas vecinos importantes.
      • Acerca del Análisis de Interferencias: 
        • 1. Se muestran todos los componentes del sistema y los componentes de interfaz, 
        • 2. también los flujos de energía / señales o transferencias de fuerza identificadas.


    Recomendaciones y Conclusiones

    • Una vez tenemos muy bien definido el proyecto y los objetivos a conseguir, en tres simples pasos podemos organizar y empacarlo lo suficiente, de manera que podamos lanzarlo minimizando problemas y agilizando actividades.
    • Esto no va de certificaciones ISO o similar. Esto es una metodología para aterrizar proyectos complejos en los que normalmente participan muchas empresa, lo cual también eleva el riesgo de fracaso. Por supuesto, no es infalible.
    • En el enfoque por procesos, es importante poner una alfombra roja a las oportunidades que puedan surgir.
    • Esta metodología ha sido empleada en el lanzamiento de iniciativas tecnológicas en el sector hipotecario, en proyectos de I+D del sector del automóvil, y actualmente se está testeando para dar forma a iniciativas público - privadas.
    • Todo ello, de una manera independiente al tamaño del proyecto o el número de miembros de un Consorcio