El dilema del integrador de sistemas

Esta charla técnica trata del desarrollo tecnológico en general, pero quizá más concretamente del desarrollo tecnológico incremental. Evidentemente, está influida por mi propia experiencia en la industria óptica, donde el módulo óptico no es más que un componente de un sistema más amplio que combina diversas disciplinas de ingeniería, desde la mecánica a la óptica, pasando por las matemáticas y el software.

Expectativas: asegúrese de gestionarlas

No todas las cosas sencillas son sencillas. Si se hace que un número suficiente de cosas sencillas dependan unas de otras, el resultado a menudo deja de ser sencillo. Este suele ser el caso de los integradores de sistemas, que pueden subcontratar o adquirir componentes de gama alta, añadir su propia tecnología especializada y sus conocimientos del mercado para ensamblar productos complejos.

Al final, la pregunta es: ¿cumplimos las expectativas? ¿Qué expectativas? Si estamos en un mercado maduro, las expectativas son bastante conocidas. A veces, las expectativas están fijadas por los límites físicos fundamentales. Muchos productos maduros funcionan con algún pequeño factor por encima de los límites establecidos por la física fundamental. El teléfono es un ejemplo. Hace 25 años, los receptores telefónicos funcionaban no muchos dB por encima del límite de ruido establecido por la temperatura y la constante de Boltzman.

Sin embargo, algunos productos aún están a punto de alcanzar estos límites. En nombre de la diligencia debida, ¿no debería todo propietario de producto saber en qué punto se encuentra su producto en relación con los límites fundamentales? A medida que los productos (en los segmentos de gama alta) maduran, tienden a llegar allí.

La niebla de var

No, no lo he escrito mal. Lo has leído bien. ¿Qué quiero decir con eso? Esta charla técnica trata de los integradores de sistemas y, en este contexto, eso significaría alguien que ensambla un producto con muchas piezas móviles de las que depende el resultado final. Como ingenieros, conocemos la calibración. Esto nos permite compensar algunos fenómenos bastante complejos siempre que sean repetitivos, ya sea en el tiempo o en el espacio. Por esta razón, la calidad de muchos productos se mide en función de cuánto, o mejor dicho, cuánto nos acercamos al objetivo nominal por término medio. La medida para ello suele ser la varianza, pero como nos gusta hablar de variables primarias en lugar de cuadradas, preferimos sacar la raíz cuadrada y en su lugar hablamos de desviaciones típicas. No obstante, la medida subyacente de la calidad surge de una suma de cuadrados de fenómenos (a menudo) independientes.

El dilema del incrementador

Esto no es una indirecta a Clayton Christensen, sino que trata de los pros y los contras de la ingeniería incremental, especialmente en el contexto de los integradores de sistemas. Cuando se nos mide por un número de calidad basado en una varianza, el conocimiento de lo que aqueja a nuestro producto puede ser dramáticamente borroso debido a la naturaleza de una gran suma de errores al cuadrado, eventualmente representada como una desviación estándar. Digamos que nos lanzamos a un proyecto y aplastamos por completo uno de esos errores y, al final, todo ese esfuerzo se ve recompensado por una mejora de 3% de la desviación estándar con la que comparamos nuestro producto. Esa no es una reunión divertida con la dirección. Gastamos 3 o 6 meses de beneficios en una mejora marginal del rendimiento. No volverá a ocurrir.

¿Y ahora qué? ¿Dejamos de mejorar? ¿Hemos alcanzado los límites físicos? Aquí es donde tenemos que saber exactamente cómo y por qué funcionan los productos que construimos. Dentro de una desviación pueden esconderse errores bastante importantes y, si no nos ocupamos de los detalles, no sabremos cuál atacar primero hasta que hayamos conseguido aplastar montones de contribuciones menores que solían ocultarlo. Y existe el riesgo de que nunca tengamos la oportunidad de conseguirlo.

Una anécdota

Tengo aquí una historia de mi propio pasado, la calibración un modulador de luz espacial con espejo basculante (SLM). A pesar de lo sencillo que puede parecer hoy en día, en aquella época se consideraba difícil. Para resolverlo, construí un modelo que contenía lo que creía que serían las variables relevantes. Probé varias ideas y, al final, una de ellas dio resultado.

Sin embargo, mi planteamiento fue recibido con escepticismo. La máquina no respondió a las expectativas y recibí bastantes críticas. Sin embargo, como presté atención a los detalles, sabía que todos los resultados intermedios durante el proceso de calibración se ajustaban perfectamente a las expectativas del modelo. Y aquí radica la primera lección: no perder de vista nuestras expectativas. Por lo tanto, no necesitaba agachar demasiado la cabeza, los problemas no estaban en el algoritmo. Pasaron casi tres años hasta que se resolvieron los problemas de carga del SLM y de deriva mecánica, y he aquí que el algoritmo empezó a ofrecer los resultados previstos en el modelo.

Disponer de un modelo lo bastante detallado resultó crucial durante este desarrollo. Tardé menos de dos semanas en escribirlo, y eso que era mi primer intento. Valió la pena cada segundo. Estoy bastante seguro de que, sin él, me habría derrumbado bajo presión intentando resolver problemas que no me correspondía resolver.

Para llevar

¿Cuál es la conclusión de todo esto? Desde mis inicios, hace 25 años, hasta la semana pasada, recuerdo el valor de saber cuál debe ser el resultado. Cómo debe funcionar el producto. Sea lo que sea lo que he desarrollado, mi objetivo ha sido saber cómo funciona el producto antes de construirlo. No siempre es posible, pero la ambición produce ideas inestimables. A veces no hay hombros de gigante en los que apoyarse. Cuando te falten gigantes, construye modelos, modelos lo bastante detallados como para captar las complejidades de tu producto, de modo que sepas qué esperar cuando enciendas la luz.