Fracaso del proyecto informático ICAM/IBM: la errónea aplicación de la «filosofía Ikea» al software

He querido sorprender a los lectores de este artículo -una breve reflexión jurídico informática-, con un título provocador; la afirmación categórica de que, en esta debacle del proyecto tecnológico concertado entre el reputado colegio profesional de abogados y la afamada International Business Machine -IBM-, la culpa podría atribuírsele a la aplicación a este contrato informático de la filosofía “IKEA”. Una afirmación que es totalmente figurada, ya que es notorio que esta popular empresa sueca no ha participado en modo alguno en el proyecto de informatización del ICAM, ni ha estado sujeta a ningún contrato con las partes, ni, mucho menos, es extraneus de este injusto. Sin embargo, no doy un paso atrás al atribuir a la filosofía IKEA, comprometida con el concepto de la funcionalidad y bajo precio, el ser la responsable de haber introducido en nuestro contexto vivencial diario y del disfrute de bienes el concepto de la sencillez y la adecuación al mínimo costo. Una filosofía ésta, que si bien es válida para pequeños compromisos de cualquier naturaleza -necesidades medias y pequeñas-, extrapolada a otros campos de la productividad y a otra envergadura de las creaciones -industriales, tecnológicas, arquitectónicas, etc…-, como es el caso de los complejos proyectos de implementación de software, supone el más rotundo y clamoroso fracaso.

Es injustificable que IBM no haya sido capaz de conducir y reconducir este proyecto

La meritoria sentencia 257/2022, del Juzgado de 1ª Instancia 13 de Madrid, sistematiza muy bien lo acontecido; aporta esta resolución judicial una explicación minuciosa y extensa -una visión casi auditora- que permite hacer un diagnóstico muy preciso de los hechos y justifica diáfanamente el catastrófico resultado obtenido para ambas partes en este proyecto. Haciendo un esfuerzo para resumir las causas que han desembocado en este clamoroso incumplimiento de IBM con el ICAM, podemos afirmar que el infructuoso resultado propiciado era, ni más ni menos, que el que merecía la concertación del mediocre diseño del proyecto que pactaron ambas partes y el precario sistema de seguimiento del cumplimiento del contrato de desarrollo e implementación; a la vista de lo ocurrido, un proyecto onerosísimo ayuno de profesionalidad, ya que no se han dado cuenta de su fracaso, sino hasta muy avanzado el proyecto y verificados todos los pagos. En otras palabras, repartiendo responsabilidades: por parte de IBM, esta señera multinacional configuró un proyecto de informatización en el que, para la recogida de especificaciones del cliente -el ICAM- se iba a utilizar herramientas y metodologías inadecuadas -casi, me permito decir, infantiles-, como son los métodos “agile” que, como recoge la sentencia, posteriormente IBM se dio cuenta de que eran inadecuadas para poder servir de base para las siguientes fases de programación y las cambiaron por una metodología en “cascada”; esto es, una metodología como “las que toda la vida” hemos utilizado los ingenieros de aplicaciones de software  para acometer los proyectos de informatización complejos [diseños prefuncionales, funcionales, de sistema, cuadernos de cargas, codificación, pruebas e implementación, adaptaciones y correcciones]. Por parte del ICAM, todos los esfuerzos que hizo de control, inclusive, por contratación de caros consultores externos, fueron inadecuados; asimismo, el seguimiento realizado del avance y cumplimiento del contrato, por parte de la inteligencia y know how interno, es obvio que sus usuarios no tenían la experiencia para poder auditar el citado avance del proyecto, ni de poder anticipar el fracaso a que conducía su diseño.

«IBM es una gran compañía, en la que yo que me formé en ingeniería de sistemas, durante más de 5 años». (Foto: E&J)

Hace mucho tiempo -casi décadas-, que vengo afirmando, cuando participo en encuentros con empresas tecnológicas en reuniones profesionales de desarrollo de aplicaciones y metodologías de implementación -a las que también acuden las empresas usuarias, inclusive grandes bancos y aseguradoras-, que la calidad del software que hoy día y desde hace años se está implementando, es de un nivel muy bajo; en algunos casos, inaceptable. A esta falta de calidad se suma el hecho de que, bajo el supuesto paradigma de que las nuevas metodologías abaratan los costos de producción de aplicaciones informáticas, la realidad es todo lo contrario; esto es, encarecen los presupuestos hasta límites inadmisibles, en base a productos inacabados, en continuas modificaciones y con un alto coste reputacional por los fallos en la explotación de la aplicación que hacen los usuarios y clientes. A esta situación se ha llegado por la avidez de las empresas multinacionales tecnológicas para abaratar costes y facturar rápido; y, también, de forma cada vez más profusa, por la aparición de otras compañías “oportunistas” internacionales -principalmente anglosajonas-, que van convenciendo a muchos clientes grandes -con instalaciones informáticas muy complejas-, que pueden resolver a y reducir sus costes y onerosos presupuestos del capítulo de desarrollo y mantenimiento, en base a sistemas más prácticos, rápidos y funcionales; así, aparecen los tópicos “low code-no code” y los proyectos “Agile” “Scrum”, “Kanban”,  “XP”, “Lean”, etc… En definitiva, todas estas metodologías son un pasaporte asegurado al fracaso del proyecto informático, siempre y cuando estemos hablando de implementaciones o migraciones de una cierta complejidad. Así, una metodología “rápida” en informática se basa en prototipos basados en importantes interacciones regulares del técnico -muchas veces, un psudoinformático con otra formación académica y técnica dispar- con el cliente y usuario de la aplicación que, uno con otro, van haciendo ajustes al prototipo y ajustándolo al funcionamiento real que ha de tener en el futuro; algo más parecido al automontaje. No se parte pues, de un modelo exacto de base, esto es, fijado en las primeras fases de diseño y análisis que anteceden a la programación, como se hace con las metodologías tradicionales.

Para que se entienda bien, voy a poner un ejemplo relativo al ámbito de la arquitectura; así, si bien, el arquitecto -en el método tradicional-, una vez contratada la obra haría unos planos detallados -con las mediciones, el cálculo de la estructura, el trazado de las instalaciones, etc…-, para el caso figurado de utilizar una metodología “agile” aplicada a este campo de la construcción, el arquitecto haría unos bocetos a “mano alzada” o con un poco más de detalle, que servirían para iniciar la obra física constructiva. En esta dinámica de intercambio de pareceres e información cliente-arquitecto, regularmente, se harían cambios de planificación, derribo por replanteos continuos y nueva construcción sobre la marcha; y todo ello, en base a dichas reiteradas conversaciones que tuviera con el cliente, considerando sus gustos cambiantes, etc…. Un despropósito que augura el bodrio de obra resultante y su desproporcionado costo final; un clamoroso error siempre y cuando la obra concertada sea medianamente compleja.

A esta situación se ha llegado por la avidez de las empresas multinacionales tecnológicas para abaratar costes y facturar rápido

Pues lo mismo ocurre en el desarrollo de software de aplicación. Trabajar sobre prototipos “agile” es un continuo camino de ida y vuelta en el que nada de lo que tienes programado está garantizado para que quede de la forma en que debe de ser entregado finalmente al cliente; todo es pura provisionalidad. Así, el concepto de funcionalidad y rapidez prometido por el desarrollador, se muta en fracaso cuando se pretende que el prototipo funcione en un entorno real de explotación, en el que las funcionalidades de los usuarios han sido soportadas de forma “simplificada”, temporal y descontrolada. Al igual que la mesa de IKEA tiene su perfecto encaje en viviendas sencillas y de una personalización general, en las que no se pretende una duración y un uso especializado -y, evidentemente, por su industrialización y elaboración por máquinas, su coste es muy asequible-, el  software tiene las mismas exigencias de sofisticación y proporcionalidad en su elaboración; esto es, en un entorno complejo, como es el ICAM, con más de cien aplicaciones en explotación [como dice la sentencia], no le puedes plantear un proyecto “agile” para soportar la evolución y perfeccionamiento de su informática, porque el resultado que le corresponde a esta aventura no puede ser otro distinto que el insoslayable incumplimiento y el escandaloso fracaso que se ha producido.

IBM es una gran compañía, en la que yo que me formé en ingeniería de sistemas, durante más de 5 años; allá, por los años 70-80; ahora, después de esta sentencia, no la reconozco. Es injustificable que IBM no haya sido capaz de conducir y reconducir este proyecto, todas las veces que hubiera hecho falta, para que no recalara en el incumplimiento; aún sabiendo la importante trascendencia y escaparate que suponía el ICAM. Esperemos que este fracaso conciencie a esta multinacional, a otras del sector -e ilustre a las empresas usuarias de tecnologías- para que profesionalicen sus proyectos; y ello, a través de contratos rigurosos, redactados por abogados que conozcan el fondo técnico de las cuestiones que se transigen –ciberabogados de verdad, con experiencia contrastada en el desarrollo de software, no con un cursillo ofimático-; así como, en la ejecución de los proyectos, que participen interlocutores especializados -usuarios y técnicos- que dominen el campo en el que trabajan.