Entusiasmado con 'La meta' y con 'No es cuestión de suerte' me lancé a leer 'El síndrome del pajar'. El libro en cuestión no es una «novela empresarial» como las anteriores. Se trata de un ensayo, circunscrito en un contexto tecnológico determinado, sobre cuál sería la mejor forma de diseñar un programa de ordenador destinado a la programación de las operaciones de fabricación. Dado que el libro tiene dos décadas, el contexto tecnológico era, siguiendo la Ley de Moore adaptada y a la inversa, el de ordenadores veintiséis veces menos potentes de los que tenemos ahora. O, dicho de otra forma, en igual tiempo empleado, un ordenador de la época en que se escribió el libro solo podía hacer un 3% de las cosas -cálculos- que puede hacer un ordenador de nuestros días. Así no es de extrañar que invierta tantas páginas del libro a explicar cómo optimizar las estructuras de datos para evitar lecturas innecesarias a disco y acelerar al máximo el tiempo para obtener un resultado en la programación de las operaciones. Los amantes de las formas normales de datos no se encontrarán cómodos con este libro.
Sin embargo, pese a tratarse de un texto obsoleto, en tanto al aspecto tecnológico de los ordenadores, el libro contiene muchos párrafos que merecen la pena ser recordados y, en general, supone un agradable estímulo intelectual de cara a entender cómo se optimiza la programación de operaciones teniendo la Teoría de las limitaciones, o TOC, en mente. En este sentido, parte de la primera parte -valga la redundancia- del libro, que está dividido en tres, explica por qué TOC ha de considerarse una filosofía empresarial, competidora en ese momento con Calidad Total y Just In Time.
Dime cómo me mides y te diré cómo me comporto. Si me mides de forma ilógica no te quejes si me comporto de forma ilógica.
Soy de la creencia que todo libro siempre puede aportar algo, son raros los casos en que no ha sido así, independiente de la ruindad literaria del mismo, y, como decía en el párrafo anterior, éste, pese a su considerable edad, tiene algunos párrafos que han resultado inspiradores. La mayoría de la gente, ingenieros en tecnologías de la información incluidos, te respondería que la diferencia entre datos e información la determina su uso. Este ha sido un precepto que siempre, al menos yo, he tenido presente como válido. Goldratt ofrece una definición que, para mi gusto, está mucho más cercana a lo que la intuición parece dictar. Así, también durante la primera parte del libro, se dedica a elucubrar sobre el significado de información y a diferenciar o categorizar entre qué datos son válidos para la toma de decisiones. Sostiene que lo que nosotros solemos llamar Sistema de Información no deja de ser un Sistema de Datos. ¿Y qué quieren que les diga? A mí me parece lógico su enfoque. Y eso que estamos hablando de algo escrito hace dos décadas. Si es que ya está todo inventado.
Hay una palabra clave escondida en lo que acabamos de decir que no nos debe pasar inadvertida. Hemos llegado a la conclusión de que la información se dispone de forma jerárquica, que en cada nivel la información se deduce de los datos. La palabra deducir es un término clave. Nos revela que, para poder derivar la información, necesitamos algo más que los datos, necesitamos el proceso de decisión.
¿Cómo no? Siendo Goldratt el libro aprovecha para atacar directamente a la contabilidad de costes y a las decisiones tan estúpidas que se toman teniendo en cuenta la misma. Ataca a la inercia con que nos movemos por el mundo. El «mundo del coste», lo denomina, en contraposición al «mundo del valor» el que postula como una alternativa más realista. Se encontrará un ejemplo interesante que demuestra cómo la intuición, a veces, nos juega malas pasadas.
La segunda parte ya se enfoca en conceptos que se deben manejar antes de proceder a la programación de las operaciones. «La arquitectura de un sistema de información» llama a esta segunda parte. Se exponen los distintos tipos de buffer que se deben contemplar de cara a evitar que una limitación se quede sin trabajar a causa de Murphy (Murphy es algo que menciona constantemente en sus libros). Esta parte me resultó un poquitín más pesada. Como la tercera, que se dedica enteramente a describir el procedimiento con el cual se deben programar las actividades productivas. Durante unas 90 páginas se dedica a elaborar, y argumentar en favor de su algoritmo, el mejor programa para conseguir la mejor programación, interacción hombre máquina incluida. Esta parte me resultó aún más pesada.
En resumen, un libro distinto a los dos anteriores y que, en general, resulta aburrido u obsoleto, pero que, aún así, esconde algunas perlas de sabiduría que bien merecen una lectura, aunque sea superficial o, como recomendaría, de forma parcial. La primera parte merece la pena, la segunda más o menos y la tercera no es necesaria leerse salvo que se tenga unas ganas infinitas de llevar a cabo el programa que se describe. Por cierto, hay algunas erratas muy graves. Más allá de errores de traducción, faltan varias gráficas a las que hace mención en el texto y que, obvio porque faltan, no aparecen por ninguna parte. Erro grave. Sobretodo porque en un texto donde escasean los recursos gráficos, que falten los pocos que se deberían usar es jodido de asimilar. Además, hay otro que está mal. Se repite dos veces el mismo. En fin, que esto complica enormemente que sea un libro a recomendar. Al menos en la edición que a mí me tocó en la librería.
Para aquellos que vean en mis palabras un «sabio consejo», pueden descargar una copia del mismo desde aquí. No esperen encontrar todo el texto ni que lo esté en perfectas condiciones, pero bien vale la pena intentarlo. Aunque no tengo ni idea cuánto tiempo estará disponible. Si es que aún lo está.
2 comentarios:
Ok, gracias
A ver si la próxima vez que coincidamos te lo presto también. Aunque, como intento reflejar en el artículo, no creo que puedas esperar gran cosa de él.
Publicar un comentario