|
Iridium fue un megaproyecto ideado por Motorola a fines de la década de los 80 con el objetivo de ofrecer una solución para comunicarse desde y hacia cualquier lugar del mundo a través de una constelación de 77 satélites. En 1991, Motorola fundó Iridium LLC, empresa independiente que llegó a costar US$15 mil millones.
Todos aplaudieron lo que parecía ser un gran éxito. La primera llamada fue realizada el 1 de noviembre de 1998 por Al Gore, en medio de vítores y aplausos. Sin embargo, nueve meses más tarde la firma se declaró en quiebra y aunque sus activos se calculaban en US$ 6 mil millones, fue adquirida en apenas US$ 25 millones.
Gran fracaso. ¿Quién fue el responsable: quienes lo diseñaron, los que lo implementaron, quienes salieron a vender o los que operaron el proyecto?
Todos tienen su cuota de culpa. Sin embargo, el diseño, que parecía óptimo en su momento, fue uno de los principales causantes.
Esta semana el ex presidente Ricardo Lagos dijo -en una entrevista a la radio ADN- que respecto al Transantiago "una responsabilidad es el diseño, que todas las autoridades internacionales aplauden y dicen que está muy bien, pero la forma en que se implementó o si se implementó antes de tiempo, a mí excúsenme, no me corresponde".
¿Qué tanta razón tiene Lagos? ¿Cuánto de la responsabilidad es atribuible al diseño de un sistema como éste, cuánto podemos asignar a su implementación y cuánto a su operación?
El proyecto Iridium posee varias cosas en común con nuestro Transantiago. La comparación ayuda a poner en perspectiva el dilema y a responder la pregunta que hoy divide a Lagos y a Bachelet: ¿diseño o implementación?
4 razones para entender un fracaso
1) Tanto el diseño de Iridium como el del Transantiago fueron elogiados en su momento. Sin embargo, cuando se aplaude el diseño de una iniciativa que está en el papel -que sabemos que aguanta mucho- no se alaba la excelencia de la solución sino más bien la ambición del proyecto.
Como lo dijo el World Resources Institute, el Transantiago era "la reforma al sistema de transporte más ambiciosa llevada a cabo por un país en desarrollo". Que sea ambiciosa, no quiere decir que su diseño sea óptimo
¿Por qué no se puede aplaudir la excelencia del diseño de un sistema como éste antes de su operación? Porque, como
veremos a lo largo de este artículo, en esa instancia aún no existe la información necesaria para asegurar sus méritos. O sea, el Transantiago pudo ser una idea muy valorada en foros y seminarios, pero de ahí a que funcionara, había un gran trecho. Basta ver las reacciones a posteriori. Conversé esto con Joseph Sussman, mi antiguo profesor del MIT y uno de los padres de la teoría de sistemas inteligentes de transporte. Concluimos que el Transantiago es un ejemplo de cómo no llevar a cabo sistemas de ingeniería desde su diseño hasta su operación.
2)Tanto Iridium como Transantiago son ejemplos de "sistemas de ingeniería". Utilizando la definición de la División de Sistemas de Ingeniería del MIT, son sistemas de gran escala habilitados por tecnología; que poseen, afectan y son afectados por los aspectos sociales, económicos y políticos propios de donde y cómo operan; presentan aspectos dinámicos y están sujetos a incertidumbre, ambigüedad y riesgo; y además, al ser altamente complejos, poseen propiedades emergentes.
¿Qué significa que posean propiedades emergentes? Que algunos problemas y comportamientos sólo aparecen con la operación de parte o de la totalidad de sus componentes. Son sistemas que no sólo afectan a la sociedad, sino también son afectados por ella, por lo que su comportamiento no es 100% predecible.
Por ende, no son pocas las iniciativas que contando con los "mejores datos, mejores profesionales, mejores consultoras y mejores intenciones", generan los peores resultados al ser llevadas a la práctica sin haber realizado experimentos o prototipos con al menos parte de sus componentes.
3) Iridium y el Transantiago son ejemplos de "gran diseño": iniciativas de envergadura y complejidad; donde existen muchas variables por controlar y conocer; con alto grado de incertidumbre y riesgo; y que comienzan a operar de una vez, al mismo tiempo.
¿Qué problemas poseen este tipo de iniciativas? Que, dadas sus propiedades emergentes, no se puede aprender lo necesario para disminuir su probabilidad de fracaso, sin someter a prueba los supuestos y teorías utilizados en el diseño de los sistemas.
Eso pasó con el Transantiago. Está más que claro que las cosas funcionaron contrario a lo presupuestado. Además fuimos testigos de lo que se llama en la academia la "resistencia de las políticas": son las características de algunos proyectos que en vez de resolver los problemas, los terminan agravando.
4) Otro aspecto común a este tipo de proyectos es que lo que no funciona se conoce demasiado tarde: durante su operación. De este modo, un diseño que no incorpora previamente experimentación parcial o total no permite detectar qué puede no funcionar.
Como resultado, la atención de quienes desarrollan el proyecto se pone entonces en tratar de validar un diseño que, en muchos casos, puede ser trágico. Se da una perversa alineación de incentivos que tiende a desoír, desechar o no considerar a las personas o la información que contradicen lo planeado y esperado por el establishment. Nadie es capaz de poner freno de mano.
Los cambios se hacen al principio, no al final
Como me decía un antiguo profesor del MIT: "No existe un límite claro entre etapas. Separar el diseño, implementación y operación en sistemas complejos sólo está en la mente de los ineptos".
En sistemas como el Transantiago, dichas etapas deben ir de la mano para minimizar la probabilidad de megafracasos. Algo que los académicos de Harvard Carliss Baldwin y Kim Clark -en su libro "Las Reglas del Diseño"- y que Daniel Whitney, profesor de MIT, dejan bastante claro: "Pensar que diseño, implementación y operación son etapas aisladas es, por decir lo menos, no entender la naturaleza del problema que se tiene entre manos".
Los sistemas de ingeniería permiten, a la luz de la evidencia, explicar en parte por qué una iniciativa que "se cree" bien diseñada puede terminar siendo un fracaso máximo. La teoría de la innovación permite, a su vez, complementar el análisis de responsabilidades en el diseño, implementación y operación del Transantiago.
Los procesos de innovación buscan resolver un problema de la mejor manera posible y generar algo nuevo, o un cambio no trivial, que cree valor para un mercado o grupo social y retornos para la organización que innova.
Al innovar queremos generar lo que llamo el efecto Wow! (positivo). El Transantiago, sin embargo, ha creado un efecto Auch! (negativo) y lo ha hecho con bombos y platillos.
¿Qué nos dice la teoría de innovación acerca de cómo evitar los efectos Auch!? Nos dice que los problemas de una iniciativa se pueden identificar a lo largo de todo su ciclo de vida, pero el costo de solucionarlos aumenta exponencialmente a medida que se avanza en etapas posteriores al diseño básico.
En otras palabras, cuanto más se demore uno en identificar y resolver un problema, más caro resultará hacerlo. ¿Por qué? Debido a que las inversiones organizacionales, políticas y de capital hacen más rígida la arquitectura del sistema (la manera en que un concepto le da forma a la función que el sistema debe cumplir).
Por el trabajo de los académicos Steven Wheelwright y Kim Clark, sabemos que al menos 70% de las posibilidades de influenciar resultados o afectar cambios en un proyecto se juegan en las etapas de adquisición de información, creación de conceptos y diseño básico. Es decir, antes de seguir avanzando en el diseño detallado y comenzar la implementación y la operación. Paradójicamente, son muchas las investigaciones que demuestran que la mayor parte del tiempo dedicado en resolver problemas que "aparecen" se gasta durante la implementación y operación. O sea, al final.
Es decir, las personas se ponen de cabeza a tratar de resolver los "imprevistos" cuando las posibilidades de hacer cambios son mínimas, y el costo de solucionarlos se ha elevado varias veces por sobre lo que habría costado "hacerlo bien".
Qué significa "hacerlo bien"
¿Qué significa "hacerlo bien"? Para esto podemos aprender de Toyota o la NASA.
Toyota llama front loading a un método que consiste en aumentar la carga de trabajo en las etapas tempranas de un proyecto -anteriores a la implementación y ejecución- con el objetivo de identificar y eliminar lo antes posible problemas potenciales.
Antes de que surgiera el front loading, el 80% de los problemas se resolvía entre las etapas de implementación y operación. Después del front loading el 80% se identifica y resuelve antes o durante el diseño.
¿Qué implicancia tiene esto? Que los "imprevistos" pueden ser identificados si se trabaja adecuadamente.
Ahora ¿cómo se cargan de trabajo las etapas tempranas de un proyecto? Invirtiendo en aprender lo más que se pueda en áreas de alta ambigüedad e incertidumbre. Esto mediante estudios, análisis etnográfico y prototipeo.
Veamos un ejemplo concreto y reciente: el cambio del sistema de pago del transporte público en Boston. En dicha ciudad pasaron del tradicional token -una moneda de bronce- al Charlie Ticket, una tarjeta inteligente algo más simple que la Bip!
¿Cómo lo hicieron? Implementando paulatinamente: cada semana una estación se incorporaba al nuevo sistema. Además decidieron partir por las estaciones con menor tránsito. Sí, tal cual. Y eso que sólo trataban de modificar el hábito de pagar de los usuarios.
¿Qué hacían en cada estación? Identificar los problemas más comunes que sufrían las personas al operar con el nuevo sistema de recarga de las tarjetas y pago. Gracias a esa información, semana a semana modificaban el sistema y la manera de vender las tarjetas, y así podían capacitar a su personal para que estuviesen preparados para enfrentar las dudas de los usuarios.
De esta manera, detectaron muchos de los errores de manera localizada y controlada, y fueron capaces de mejorar el diseño.
¿Por qué demoraron en Boston más de un año en cambiar sólo el sistema de pago? Porque sabían que el simple hecho de pagar con un medio distinto y habilitado por tecnología requería un cambio de comportamiento de las personas. Tenían claro que, más allá de los resultados siempre limitados de encuestas y focus groups, no podían anticipar todos los problemas asociados a la experiencia de consumo del nuevo sistema. Además, para garantizar la implementación a gran escala, necesitaban aprender-haciendo y para evitar un megafracaso era indispensable fallar de manera controlada, focalizada, lo más pronto y barato posible.
Así evitaron el efecto Auch! masivo, y encontraron el efecto Wow!
¿Cuánto costaba adelantarse a los problemas?
El Transantiago "pareciera" haber sido implementado por etapas, sin embargo la evidencia apunta más a la tesis del Big Bang: todo de una vez.
La ilusión de las etapas es fruto de la cantidad y el calibre de los problemas que surgieron, de la subestimación del impacto de no partir con todos los componentes en perfecto funcionamiento, y de la falta de conciencia de su complejidad operacional.
Por ejemplo, antes del Transantiago las autoridades trataron de implementar al menos tres sistemas de pago automático en las micros (para una población 10 veces mayor a la de Boston). Ninguno de ellos funcionó. Pese a ese dato crucial, no se hizo nada parecido -experimentación y gradualidad- a lo de Boston. Y eso que en el Transantiago, la tarjeta Bip! era sólo uno de los cambios (y no el más relevante).
Algunos esgrimen que no se pueden comparar los recursos de un país desarrollado con los de uno en desarrollo. Es cierto, pero hasta cierto punto. Es aquí donde la teoría de innovación nos ayuda de nuevo, porque los sistemas complejos son contra-intuitivos en muchos aspectos.
Si somos más pobres, debemos cuidar mejor nuestros recursos. Sin embargo, esto no significa no gastar, sino invertir bien. Lo ejemplificaremos con un ejercicio basado en algunos datos del Transantiago.
El sitio web del Transantiago enuncia que, previo a febrero del 2007, la inversión para el proyecto contemplaba, entre aportes del Estado y de los privados, montos que van de los US$ 300 millones a los US$ 400 millones. Sus pérdidas entre febrero de 2007 y agosto del 2008 ascienden a US$ 635.5 millones, con un déficit mensual para julio del 2008 de US$ 54.2 millones.
Supongamos que identificar lo antes posible los problemas del Transantiago hubiese costado US$ 35.5 millones. De haber sido así, nos habríamos ahorrado unos US$ 600 millones.
Supongamos además que, en promedio, cada experimento de alguna dimensión del Transantiago -entre las etapas de diseño e implementación y antes de comenzar a operar- hubiese costado US$ 500 mil. Los estudios académicos -como el de Stefan Thomke, de Harvard- permiten deducir que el número óptimo de experimentos o pilotos a realizar en el Transantiago deberían haber sido 24. O sea, US$ 12 millones adicionales para experimentar previamente con los buses, las interconexiones, los sistemas de pago automático, la interacción con usuarios, etc.
Son casi US$ 48 millones que se suman a los US$ 400 millones originales. Cierto, es un valor alto y que a la luz de nuestra mentalidad a la hora de diseñar políticas públicas, difícilmente se habría aprobado. Hay atenuantes: el Transantiago era un desafío nuevo y tal como dicen los académicos John Sterman y Nelson Reppenning -de MIT-, nadie obtiene el crédito por evitar problemas que nunca pasaron.
El punto es que aunque se trate de valores nada despreciables, son varias veces inferiores a las pérdidas potenciales.
Errores del Transantiago
Miremos el Transantiago y enumeremos algunos de sus problemas.
Primer error: una manera de gestionar el proyecto que separó el diseño de la implementación y operación. Este es quizás el peor de los problemas, porque se basa en un paradigma antiguo de gestión de proyectos que no está alineado con las necesidades y requerimientos de sistemas de ingeniería de alta complejidad, como el Transantiago.
Sin embargo, aún bajo el antiguo paradigma, los problemas no fueron menores: subestimación de la demanda debido a la utilización de encuestas de origen y destino de viajes con más de cinco años de antigüedad. Esta es una de las causas más comunes en los fracasos de este tipo de iniciativas: si los contextos cambian con el tiempo, éstos deben incorporarse al diseño de las soluciones. No fue el caso aquí.
También hubo problemas en el alineamiento de incentivos entre las partes operadoras, cambios al diseño original y eliminación de algunas funciones que inicialmente eran parte del diseño. La evidencia derribó los supuestos acerca de cómo las personas utilizarían el Metro y la tarjeta Bip! Entre todo esto, no se pueden minimizar los efectos de los cambios en el liderazgo del Transantiago. Uno de los problemas más graves en desarrollo de sistemas de ingeniería son atribuidos a cambios en el liderazgo.
¿Implementación?
¿Problemas de implementación? Sin duda que los hubo, pero dichos problemas se incubaron por un diseño deficiente, y por no ser capaces de disminuir la ambigüedad, incertidumbre, el riesgo y la ignorancia asociada a este proyecto.
En este tipo de iniciativas no se puede separar el diseño de la implementación y la operación, tan fácilmente como si se tratase de la construcción de una casa. Es más: en la construcción de una casa, uno percibe problemas de diseño durante la construcción. ¿Hay "tareas" que son puramente de diseño, implementación y operación? Sin duda… pero sólo tareas. Cuando hablamos de "etapas" la división es difusa.
¿Qué lecciones podemos sacar? Cualquier megaproyecto debe considerar presupuestos para el aprendizaje mediante experimentación. Este debe orientarse a probar más que a verificar. Esto es un desafío mayor porque no está internalizado aquí el concepto de gastar en fallar. Lo conversábamos hace poco más de un año en Silicon Valley con un grupo de expertos de IDEO, una de las empresas de innovación más relevantes del mundo: estos presupuestos, si bien parecen excesivos, por lo general son menores que los costos del "peor escenario" y han mostrado disminuir la probabilidad de megafracasos en hasta 90%.
Jeffrey Pressman y Aaron Wildavsky escribieron, en su libro Implementación (1984) que "una política pública no sólo se debe evaluar en términos de lo atractiva que sea, sino también en términos de si se puede implementar".
Es por esto que no podemos separar diseño de implementación y operación. El diseño es concurrente, la evaluación es continua y la implementación y operación sirven para mejorar un diseño básico que, se sabe, va a tener problemas.
Entonces. ¿Le corresponde parte de la responsabilidad al ex presidente Lagos? Basado en lo anterior, claramente que le corresponde. De acuerdo a una encuesta realizada entre la Escuela de Sociología de la UC y el programa Tolerancia Cero, el 67.7% de los consultados así lo cree. Siguiendo a James Surowiecki, aquí la sabiduría parece estar en la masa. Lo peor de todo es que aún no hemos absorbido el costo total de solucionar este problema.
Algunas voces han llamado al "rediseño" del Transantiago. Por favor, saquemos lecciones de lo que hemos vivido. A esta altura, un rediseño puede ser mucho peor: existen varias razones de peso, las que serían material para otra columna. Además ¿ayudaría en algo una acusación constitucional a estas alturas? Quizás a la Alianza la ayude políticamente, pero la evidencia nos dice que sólo serviría para empeorar las cosas en el Transantiago.
Ojalá que todos -gobierno y oposición- estén a la altura de las circunstancias. Lo necesitamos de manera urgente.
|
