Hace tiempo que no escribo por temas familiares (cosas buenas), y la verdad es que va siendo hora de volver a escribir por aquí.
Quiero hablar de un libro que creo que ya he comentado alguna vez, pero que estos días he estado releyendo y que me tiene un aspecto bastante actual en política y que seguro hemos visto todos en nuestras empresas. El libro se llama «Goog Strategy/Bad Strategy» de Richard Rumelt.
En un momento, Richard habla de una de las maneras de tener lo que él llama estrategia mala:
Una mala estrategia tiende a pasar por alto detalles molestos, como los problemas. Ignora el poder de la elección y la concentración, y en su lugar intenta dar cabida a una multitud de demandas e intereses contradictorios.
y un poco más adelante matiza:
Tienen múltiples objetivos e iniciativas que simbolizan el progreso, pero no cuentan con un enfoque coherente para lograrlo, aparte de «gastar más y esforzarse más.
Seguramente el lector ya ha visualizado alguna situación semejante.
Cuantas veces hemos visto al partido en el poder, para conseguir unos votos para aprobar alguna propuesta, prometer una cosa a un partido aliado y lo contrario (o casi) a otro partido. Así parece que hay avance. Pueden salir diciendo que se han conseguido dar pasos en la buena dirección porque han convencido a los otros partidos para que voten a favor de una propuesta. Pero luego vienen las acciones coherentes. Es cuando se intenta dar lo prometido a uno y a otro. En la mayor parte de las ocasiones no es posible y se genera una ley o una propuesta que no convence ni a uno ni a otro, o es tan enrevesado que complica el sistema.
Un ejemplo podría ser el caza Lockheed Martin F-35 de los Estados Unidos. Este caza multifunción buscaba satisfacer las necesidades de la Fuerza Aérea, la Marina, el Cuerpo de Marines e incluso aliados internacionales, incorporando requerimientos de todos para un diseño unificado. El resultado fue un «cuchillo suizo» de avión con enormes sobrecostes (estimados en 1.65 billones de dólares a lo largo de su vida útil), retrasos de décadas, problemas técnicos como inestabilidad en software y hardware, y un rendimiento puesto en entredicho al intentar ser todo para todos. Se generó complejidad innecesaria para no contentar a nadie.
Otro podría ser National Programme for IT del NHS del Servicio Nacional de Salud del Reino Unido. Este proyecto pretendía modernizar los sistemas IT, registros electrónicos y digitalizaciones para todos los hospitales y comunidades. Para contentar a políticos, proveedores y partes locales, se aceptaron especificaciones cambiantes y contradictorias, resultando en un enfoque politizado que no se adaptaba a necesidades locales reales. El resultado: retrasos, problemas técnicos, falta de responsabilidad y un desperdicio de unos 10 mil millones de libras. Es considerado como el mayor fracaso IT de la historia del Reino Unido. Se abandonó sin completar.
Más en el mundo de la tecnología, fue muy sonado el caso de Windows Vista. Cuando se estaban estableciendo los requisitos de «Longhorn» (nombre de desarrollo de Windows Vista), se fueron asimilando propuestas de todos equipos internos sin un enfoque claro. Además se propusieron todas para para la misma versión, sería revolucionario. Esto causó lo que se llama un «feature creep», un sistema sobrecargado con funciones innecesarias. La consecuencia de esto fue inestabilidad, retrasos (se empezó el desarrollo en mayo de 2001, con la idea de liberarlo en Octubre de 2003, finalmente vio la luz a finales del 2006) y bajo rendimiento. El resultado fue un OS criticado que dañó la reputación de Microsoft.
Yo recuerdo en una empresa que vendía varias aplicaciones que hacían prácticamente lo mismo. Se decidió reducir el portafolio para abaratar costes operativos y mejorar el mantenimiento. La idea era simple:
- Si había una aplicación que tenía una función que iba bien, se usaría la función de esa aplicación por el resto de las aplicaciones.
- Si había una función que no existía, se crearía nueva y todos usarían esa función.
- Se irían eliminando las aplicaciones que menos se usaran, reduciendo así la complejidad y el número de sistemas a mantener.
- Se haría una capa de presentación por encima de todas las aplicaciones, para que el usuario no notara que estaba usando servicios de distintas aplicaciones.
Durante la presentación de la idea se mostró un diagrama con todas las aplicaciones bajo esa capa de presentación. Todos estaban contentos, sus aplicaciones estaban en el diagrama final, todos se veían ahí, así que todos aceptaron esa idea, sin detenerse a pensar en cómo llevar a cabo este plan.
El resultado no fue el esperado. Cada grupo responsable de las aplicaciones, lógicamente, decía que la suya era la mejor en cada funcionalidad, que el resto debían usar la suya. Y se negaban a implementar las funcionalidades de otros. En caso de necesitar un servicio nuevo, no había consenso en los detalles de cómo debía ser implementado ni qué unidad lo pagaría, con lo que cada uno se implementaba su funcionalidad. Nadie estaba contento, pero ahora había que mantener todo el portafolio anterior, y una capa de presentación adicional que cuando podían se la saltaban, pero que nadie quería eliminar por completo, porque había costado mucho dinero.
Así que como dice Richard Rumelt,
«La estrategia debe significar una respuesta cohesionada a un reto importante»… «es un conjunto coherente de análisis, conceptos, políticas, argumentos y acciones».
y parte de esta respuesta, de estas acciones coherentes, es tomar decisiones que en ocasiones pueden resultar incómodas a alguna de las partes.