PLANIFICACIÓN Y SEGUIMIENTO DE PROYECTOS
Introducción
El diseño de un producto nuevo y de su proceso es, básicamente, un flujo de creación de conocimiento, pero ese conocimiento debe ser “conocimiento útil” para ser considerado valor agregado en el desarrollo. A ese flujo de conocimiento útil, o proceso de aprendizaje, se lo denomina “flujo de valor de desarrollo” y sus salidas son el diseño del producto, con sus características, y el diseño del proceso. Este último conforma el “flujo de valor operativo”, cuyo valor agregado es el material transformado. El flujo de valor operativo o proceso debe ser rentable y consistente.
Así, tenemos un sistema de desarrollo cuyo cliente principal es el proceso operativo, y un sistema de producción, cuyo cliente principal es el cliente propiamente dicho; el cliente compra productos, no compra ni desarrollo ni proceso.
Como todo flujo, el flujo de desarrollo debe ser continuo y su “lead time” debe ser corto. La reducción del lead time de desarrollo se basa en la eliminación de los desperdicios de desarrollo, que permite obtener el conocimiento correcto, en el lugar y el momento correctos.
Conocimiento
El conocimiento se crea de tres modos básicos:
- Enterándose del estado de cosas ahora, para integrarlas al diseño. Incluye aprender acerca de los clientes, los proveedores, el ambiente donde se usará el producto, etc. Ayuda a integrar el diseño con las necesidades de otros.
- Inventando, para crear soluciones nuevas posibles.
- Evaluando la factibilidad de las soluciones, para tomar mejores decisiones a partir de distintas opciones.
El conocimiento puede clasificarse en dos tipos:
- Un primer tipo es el conocimiento a priori o necesario, aquel que, por ejemplo, disponen las funciones de apoyo especializadas como ingeniería, administración, recursos humanos, calidad o mantenimiento, y que, en general, conforman el núcleo duro de todas las organizaciones y es independiente del “corebusiness”. También es conocimiento a priori el documentado en políticas, planes y procedimientos, así como los resultados reales de éstos que permiten tomar las decisiones tácticas. Se denomina conocimiento a priori porque debe estar disponible de antemano para cuando sea necesario sin necesidad de recurrir a alguien más.
- Un segundo tipo es el conocimiento a posteriori o contingente, aquella información relevante para el producto o el proceso en foco, y que surge en el momento como fruto de la interacción con los componentes del entorno inmediato, pero que no puede ser anticipada. Este tipo de conocimiento fluye por el canal de comando promoviendo instrucciones hacia abajo, demandas hacia arriba y negociaciones entre ambos niveles.
El ciclo de creación de conocimiento:
El ciclo de creación (ciclo de agregado de valor) se despliega en seis fases, todas igualmente importantes.
- Observar:
Comportamiento del cliente, productos competitivos, procesos, proveedores, nuevas tecnologías, naturaleza, etc.
- Inventar:
Innovar a partir de lo aprendido de la observación.
- Probar:
Simular, testear lo inventado.
- Abstraer:
Explicitar el conocimiento adquirido en formas útiles, compactas y comprensibles.
- Conectar con la teoría:
Asociar con la teoría ya existente.
- Enseñar:
Transferir lo aprendido a otros.
Desperdicios en el sistema de desarrollo
En su libro “Lean Product and Process Development”, Allen Ward distingue tres categorías de desperdicios:
- Las interrupciones del flujo de conocimiento útil
- La gestión del conocimiento inútil
- El pensamiento voluntarioso en la toma de decisiones
- Las interrupciones del flujo de conocimiento útil:
Son acciones que hacen inefectivo el conocimiento interrumpiendo su flujo; básicamente interrumpiendo las interacciones sutiles del equipo de trabajo.
Dos categorías asociadas a esta categoría de desperdicio son la existencia de barreras en la comunicación y la utilización de herramientas pobres tales como procedimientos excesivamente detallados, útiles quizás en su momento.
Las barreras en las comunicaciones son típicas de las organizaciones donde la gestión por procesos es débil, prevaleciendo la gestión por departamentos con la consecuencia negativa de priorizar los resultados divisionales por encima de los del conjunto. El proceso de desarrollo no se percibe como un proceso integrador, capaz de lograr los objetivos estratégicos de la organización.
Los procedimientos se empobrecen con el correr del tiempo y de los proyectos de desarrollo. Cuando los proyectos se atrasan, la reacción natural de los responsables últimos, impulsados por una falsa ilusión de control, es solicitar más informes, poner más controles, más controles cruzados, etc., siendo la consecuencia inevitable desarrolladores más ocupados y, sin dudas, un proyecto que se atrasa aún más. Entonces se piden más informes y controles. Los desarrolladores, a su vez, toman atajos para poder cumplir con los plazos degradando la calidad del proyecto, con lo que se dispara una espiral de la muerte. Todo esto se traslada a los procedimientos que no reflejarán adecuadamente la realidad de los proyectos futuros.
Lo que realmente sucede es que estos procedimientos ignoran la diferencia entre conocimiento a priori y conocimiento a posteriori. El conocimiento a posteriori sobre el desarrollo del proyecto se crea en el momento, es inmediato, por lo que solo pueden alcanzarlo los desarrolladores. El conocimiento a posteriori no puede anticiparse, por lo que no cabe que un procedimiento pretenda contemplar cosas que es imposible que se conozcan de antemano. El resultado es el colapso del sistema de desarrollo, de los responsables del proyecto con los desarrolladores.
- La gestión de conocimiento inútil:
El conocimiento inútil se genera por la separación artificial de conocimiento, responsabilidad, feedback y ejecución en el desarrollo de un proyecto, producida por su asignación a diferentes personas. Ese conocimiento inútil se incorpora al flujo de desarrollo haciendo su gestión inevitable, con el consecuente desperdicio de tiempo y esfuerzo.
La separación de conocimiento, responsabilidad, feedback y ejecución, en el desarrollo de un proyecto, se debe a la ausencia de un líder de proyecto con autoridad y responsabilidad para lograr un sistema de desarrollo integrador, y a quién los responsables departamentales deben dar apoyo.
El secuenciado de las actividades de desarrollo también genera conocimiento inútil, dado que cada actividad no se inicia hasta que la anterior se haya finalizado, no se solapan pese a que el trabajo en los proyectos de desarrollo lo permite; es más, lo exige a fin de evitar los desvíos y sus consecuentes revisiones por desconocer las necesidades de la actividad siguiente, con las demoras que esto implica. A diferencia de los productos físicos que solo pueden estar en un solo lugar a la vez, el conocimiento puede ser compartido por muchas personas permitiendo que las actividades se solapen.
- El pensamiento voluntarioso en la toma de decisiones:
Es una consecuencia de la necesidad de tomar decisiones bajo la presión de los vencimientos de plazos, sin la suficiente información útil y en medio del ruido que genera el exceso de información inútil.
Mucho conocimiento se ha perdido por no saber cómo convertir datos en conocimiento útil. No se dispone de una estrategia de “lecciones aprendidas”.
Otro aspecto del pensamiento voluntarioso es que las pruebas de las especificaciones las realizan los mismos ingenieros del proyecto. Al no ser independientes aparece un sesgo natural hacia lo que conviene.
Principios guía para el diseño de un sistema de desarrollo
En su libro “Lean Product and Process Development”, Allen Ward enuncia los siguientes principios que guían el diseño de un sistema de desarrollo:
- Poner el foco en la creación de conocimiento y hardware nuevos para flujos de valor operativo rentables y consistentes.
Producción es el cliente principal de desarrollo, siendo el valor primordial del desarrollo el conocimiento útil.
Diseño de un sistema de producción:
- La innovación en producción es tan importante como la innovación en los productos y es más fácil de mantener en secreto, sosteniendo por más tiempo la ventaja competitiva.
- Asignar los ingenieros de proceso al proyecto desde el inicio ya que, en general, los productos se diseñan para un sistema de producción existente.
- Cerrar el bucle entre diseñar y hacer. Los operadores, los líderes de equipos y el personal de mantenimiento son la autoridad última en relación a como se usan y mantienen los equipos, por lo que deben ser asignados al proyecto desde el inicio.
- Intentar diseñar y construir el herramental íntimamente ligado con las partes y conjuntos que se producirán.
- Diseñar el sistema de producción teniendo en cuenta los desperdicios de Ohno Taiichi (muda).
- Integrar la construcción y prueba del equipamiento al proceso de desarrollo, si es posible.
- Designar como líder de proyecto a un diseñador de sistema emprendedor
El líder del proyecto debe diseñar un sistema, es decir, un flujo de valor operativo que corra desde los proveedores a través de manufactura hasta llegar al cliente, pasando por las características del producto. Son responsables de ensamblar en un conjunto todas las partes del flujo de valor operativo, ya que optimizar cada una de éstas independientemente, sin tener en cuenta todo el flujo, resulta siempre en un mal sistema.
Pero además, deben ser emprendedores, es decir, deben reunir habilidades tanto técnicas y de gestión como de negocios, y tener un contagioso entusiasmo. No son burócratas sino básicamente emprendedores.
Responden directamente a los número uno, y deben tener el apoyo de los responsables funcionales o departamentales. La tensión que esta forma de organización indefectiblemente genera es la fuente de la creatividad; a decir de un ingeniero jefe de Toyota, “montones de conflictos hacen un gran auto” (Allen Ward en su libro “Lean Product and Process Development”).
Los diseñadores de sistema emprendedores son responsables de:
- La rentabilidad y el riesgo del proyecto
- Representar al cliente
- Proveer la visión
- Negociar recursos
- Diseñar el flujo de valor evitando desperdicios
- Proveer liderazgo técnico
- Activar el proceso de desarrollo del proyecto
- Hacer el seguimiento del proyecto
- Implementar una ingeniería concurrente basada en múltiples alternativas (SBCE – Set – Based Concurrent Engineering)
Se trabaja, en el inicio del proyecto, en múltiples alternativas, simultáneamente y en todos los niveles de la organización. Se trata de gastar al principio en más alternativas de las que se van a usar, pero descartando las más débiles agresiva y rápidamente.
Una red de comunicaciones, la gestión a la vista y las interacciones cara a cara son también ingredientes esenciales.
Esta estrategia disminuye sensiblemente la gestión de conocimiento inútil en gran parte del proyecto, reduciendo su lead time.
- Implementar un flujo cadencioso y la gestión por arrastre del proyecto.
Los nuevos proyectos se liberan a un ritmo regular de manera de nivelar la carga de trabajo de los desarrolladores (cadencia).
Se planifican eventos integradores (3 a 10 por proyecto) que funcionan como mojones para los desarrolladores, quienes planifican su propio trabajo basándose en ellos y esforzándose por alcanzarlos (sistema de arrastre).
Los eventos indican plazos estratégicos que no pueden modificarse, no hay excusas.
- Equipo de expertos con autonomía.
- Los expertos son los desarrolladores, que pueden pertenecer a diferentes departamentos.
- Responden al líder del proyecto, en relación con ese proyecto en particular, es su cliente.
- Reciben apoyo de los líderes de sus propios departamentos.
- Planifican su propio trabajo para alcanzar cada evento integrador (sistema de arrastre).
- Aprenden del conflicto que surge de la natural y útil tensión producto de la interacción con el líder del proyecto.
Ingeniería concurrente (punto 3)
- Desplegar el sistema en subsistemas y sub-subsistemas
Estructura de producto: las jerarquías reducen variedad permitiendo hacer un uso infinito de recursos finitos.
- Identificar objetivos de límites amplios para cada ítem del punto 1
- Crear múltiples conceptos para cada artículo y su respectivo proceso
- Evaluar agresivamente identificando sus modos y puntos de falla
Producir trade-off curves para cada modo de falla de cada artículo. Describen los límites de performance o posibilidades del artículo.
Muy útiles para diseños futuros.
Considerar:
- Integración de la parte con el todo
- Necesidades de los clientes
- Productos competitivos
- Crear una base de conocimientos con las hojas de las trade-off curve
Armar libros por especialidad con las hojas trade-off curve. Recordar: hacer un uso infinito de recursos finitos.
- Filtrar los múltiples conceptos
El filtrado permite incrementar la precisión, el detalle y los costos de cada modelo conceptual y de sus pruebas.
- Ciclos cortos y rápidos
Reuniones que proveen un orden dinámico – una por semana, a veces una diaria.
Los ciclos deben se cortos para evitar que cada situación sea significativamente nueva.
Trade-off curve
Es una hoja A3 (o dos enfrentadas) que muestra esquemáticamente los límites de performance o de posibilidades de un sistema, un subsistema o un sub-subsistema:
- Es el registro primario de los modos de falla
- El más común de los modos de falla sea probablemente el ensamblado de conjuntos
- Los puntos de falla deben caer cómodamente dentro de las condiciones operativas. Prevención de fallas de campo.
