Entre la conjetura inicial para obtener un sistema, equipo, objeto o proceso y su materialización median una cantidad ingente de criterios, decisiones, acciones y factores. Tomando como ejemplos producir una nueva plataforma administrativa o un nuevo intercambiador de calor, el origen de cualquiera de esas dos iniciativas se remonta a la noción de alguien, probablemente un empresario, con conciencia de querer tener algo para que surta determinada utilidad.
Toda una secuencia de razonamiento dará lugar a la concepción clara de que lo que se quiere es, efectivamente, un sistema informático o un equipo industrial, o lo que sea. También habrán sido esclarecidas en extenso cuáles son las utilidades que se pide al ingenio que se está queriendo crear. Seguidamente, habrá que decidir qué componentes utilizar, cuál será la estructura de la solución, los plazos, los precios,…
…y el sinfín de asuntos que están involucrados en la producción de un prototipo mediante el cual comprobar que el resultado es satisfactorio.
El diseño de la plataforma administrativa, o del intercambiador de calor, habrá de llevarlo a cabo un ingeniero o un equipo de ellos. Finalmente, la realización de los prototipos y su comprobación correrán a cargo de los equipos técnicos especializados.
En el caso general, corresponde asumir que el demandante de soluciones, tal vez ese empresario que hemos mencionado, ya directamente o mediante su equipo de colaboradores, sea experto en el campo donde será explotado el nuevo ingenio. En cambio, a la ingeniería corresponde imputarle la pericia en el campo tecnológico propio del ingenio (informática o ingeniería industrial, respectivamente, para producir la plataforma administrativa o el intercambiador de calor).
Que el cliente y el ingeniero asuman cada uno el rol que estrictamente le corresponde, constituye un ejercicio de inteligencia indispensable para garantizar el éxito de la iniciativa. Sin embargo, la experiencia está plagada de ejemplos en contra: los informáticos ejercen frecuentemente como si fueran expertos contables, sanitarios, pedagogos, transportistas, etc. para especificar las prestaciones que determinado encargo de sistema informático habrá de satisfacer. Complementariamente, los expertos del sector donde las soluciones han de proporcionar utilidad, a menudo, se limitan a descripciones fenomenológicas de qué es lo que quieren y, a partir de ahí, dejan que el experto del ramo tecnológico, el informático, sea el que imponga la que para él es la mejor aproximación a lo que se demanda. Ello conlleva que el problema se subordina a determinada capacidad de resolver. Conceptualmente, dado que el campo tecnológico de la solución proporciona método al campo del problema, el primero constituye cuerpo de conocimiento del segundo. Operando así, el riesgo está servido ya que toman decisiones de un ámbito expertos que lo son de otro campo.
Es obvio que los resultados podrán garantizarse únicamente si cada experto resuelve solamente dentro del ámbito de sus competencias, esto es, el demandante que se limite a lo concerniente al ámbito de su negocio, y el ingeniero que especifique y tome decisiones de diseño exclusivamente concernientes al ingenio que va a crear. El ámbito de las competencias de cada experto viene establecido, precisamente, por los dos instrumentos que median entre la conjetura y el resultado, esto es, el problema y la solución.
Así las cosas, corresponde caracterizar el problema bajo el enfoque de su propia naturaleza, sobre todo, con absoluta independencia de los aspectos de la solución para garantizar la ausencia de condicionantes previos y evitar la toma de decisiones prematuras que opten por determinada tecnología o estructura antes de haber analizado otras posibilidades. En los ejemplos que venimos considerando, es como encargar una plataforma administrativa basada en MySQL o que el intercambiador de calor tenga carcasa metálica. La base de datos habrá de ser la que satisfaga las necesidades de compatibilidad, capacidad, etc., de la misma manera que el material de la carcasa del intercambiador deberá ser el que corresponda a las necesidades de aislamiento térmico, protección mecánica, encapsulamiento eléctrico, etc.
En consecuencia, el enunciado que cabe esperar del empresario interesado en la plataforma administrativa o en el intercambiador de calor habrá de evitar lo estructural y lo constitutivo. Es decir, la especificación del problema ha de ser funcional, estrictamente inscrita en el campo al que pertenece el problema, totalmente al margen del sector al que pertenecerá la solución. La especificación funcional del problema podrá, pues, contener solamente términos que identifiquen al problema y términos que delimiten su extensión.
Los términos identificativos son los que ubican el problema en el seno de una colectividad de otros problemas con los que comparte aspectos, esto es, se trata de nombrar el problema refiriéndolo a un modelo (por extensión, encajarlo dentro de una teoría). En la práctica, cualquier respuesta a la cuestión “qué es el problema” constituye una identificación de ese problema:
– “La plataforma administrativa es un sistema informático.”
– “La plataforma administrativa es una herramienta software.”
– “La plataforma administrativa es una comisión gerencial.”
– “El intercambiador de calor es un ingenio.”
– “El intercambiador de calor es un equipo hidromecánico.”
Para delimitar el problema a fin de diferenciarlo de los demás problemas del modelo identificador, lo que corresponde es contestar a la pregunta “para qué es el problema”. Con ello, se establece la finalidad a satisfacer, es decir, los objetivos que se persigue alcanzar:
– “La plataforma administrativa es un sistema informático para custodiar los datos de gestión, sistematizar la operatoria y agilizar los trámites.”
– “El intercambiador de calor es un ingenio para trasvasar energía térmica entre dos medios que están a diferente temperatura.”
Nada se dice sobre el uso de bases de datos o si el intercambio de calor ha de ser convectivo, ya que esos asuntos son del mundo de las soluciones y, por lo tanto, corresponde que los resuelva, no el cliente sino el ingeniero.
La competencia ingenieril abarca desde la especificación funcional que recibe del cliente hasta la obtención de un prototipo validado mediante la comprobación de que satisface la especificación funcional. Consta de una primera fase de diseño propiamente dicho en la cual el ingeniero toma decisiones conducentes tanto a especificar la solución como a establecer el método para realizarla, y propone el proyecto de ejecución; y de una segunda fase de prototipado en la que el ingeniero dirige la realización del prototipo y su validación.
En la fase de diseño para obtener la solución, el ingeniero contesta sucesivamente a las cuestiones “cómo es la solución” y “con qué hacer la solución”:
– “La plataforma administrativa es un sistema informático para custodiar los datos de gestión, sistematizar la operatoria y agilizar los trámites; con un gestor documental, un motor inteligente de monitorización y una interfaz de usuario intuitiva, soportado en MySQL sobre Apache.”
– “El intercambiador de calor es un ingenio para trasvasar energía térmica entre dos medios que están a diferente temperatura que consiste en un equipo con dos conducciones de material conductor, que transportan fluidos a diferentes temperaturas, inmersas en una caldera de líquido de alta conductividad térmica.”
Mediante la respuesta al resto de cuestiones (dónde, cuándo, cuánto, quién, etc.), el ingeniero elabora el proyecto de ejecución.
Descompuesta la resolución de problemas (ya sean del tipo de creación de ingenios o sobre concepción de procesos) en una secuencia de tres pasos, corresponde a los expertos del sector del problema contestar a las preguntas “qué” y “para qué”, y exclusivamente a esas preguntas. Por su parte, los especialistas del área tecnológica diseñarán decidiendo sobre “cómo” y “con qué”, e idearán la realización y comprobación mediante todas las demás cuestiones. Esta secuencia de tres bloques (ámbito del problema, dominio de la solución y mundo de la realización) incorpora sendas interfaces:
– la especificación funcional que media entre el ámbito del problema y el diseño de la solución, y
– la especificación estructural que separa la fase de diseño de la de prototipado.
Dichas interfaces proporcionan fabulosos instrumentos metodológicos para garantizar por adelantado el éxito (antes de hacer las inversiones cuantiosas).
La receta es bien sencilla:
– que el cliente se limite a la especificación funcional y que el ingeniero vigile que así sea,
– que el ingeniero diseñador intervenga exclusivamente en la especificación estructural de la solución, y
– que el ingeniero responsable del prototipado sea distinto del diseñador para facilitar la detección de potenciales errores sistemáticos se diseño.
A fin de cuentas, solo es cuestión de poner un poco de inteligencia natural.