Complejidad de la gestión pública: aprendiendo de casos no exitosos

Escrito por Alejandro Pareja Glass*

Este es el segundo post de una serie que pretende poner de manifiesto la complejidad extrema de la gestión pública analizando situaciones que se dan en todos los países, desarrollados o no.

En el post anterior vimos un caso de falla regulatoria, el caso de informes solicitados por el Congreso de Estados Unidos al poder Ejecutivo y que en muchos casos se preparan sabiendo que nadie los va a leer. Veremos en este post otro caso, seguramente el más sonado del último bienio.

Caso 2: HealthCare.gov
HealthCare.gov es el sistema de información a través del cual se gestiona el nuevo sistema de salud americano. Se trata de un sitio donde, básicamente, los usuarios se registran, entran a un mercado de seguros de salud donde se informa de los diferentes precios, coberturas, deducibles, condiciones de elegibilidad, etc., y se elige el más conveniente.

La reforma se conoce como Obamacare o el Affordable Care Act. Se trata de la mayor transformación del servicio de salud norteamericano en los últimos 50 años. Fue muy resistida por algunos porque torna obligatorio el seguro de salud y extiende mediante subsidios la cobertura a los estratos más pobres. La ley marcaba que el nuevo sistema debía comenzar a operar el 01-Oct-2013 y lo hizo en fecha. Pero el sistema informático falló estrepitosamente. Fue un duro golpe para el gobierno que veía cómo su arriesgada reforma, que venía resistiendo 4 años de acoso público, se estrenaba haciendo agua en la implementación de su sistema de información.

El presupuesto inicial era de US$ 100 millones pero al momento de la puesta en producción ya se había gastado el triple. El gobierno tuvo que salir de apuro a contratar con nuevos proveedores la reparación a marchas forzadas de la herramienta. El costo final habría superado los US$ 840 millones y la factura aún no está cerrada. Cuesta imaginar que un sistema de información conlleve esos montos pero así es.

El fallo de la implementación y el tremendo sobrecosto hicieron que rodara la cabeza de la Secretaria de Estado del Department of Health and Human Services. Y, sin embargo, el sistema funciona ya muy bien, el producto esté siendo utilizado tal como se preveía.

El gobierno de Obama comprendió que detrás de este doloroso caso había una cuestión de fondo. Para corregirla creó una nueva oficina en la Casa Blanca, el US Digital Service, a cuyo frente puso al ingeniero que lideró la recuperación del desastre, Michael Dickerson. El US Digital Service sigue el ejemplo británico del Government Digital Service y su misión, en conjunto con la agencia 18F, de la General Services Administration, es apoyar a los distintos departamentos de gobierno en la mejora de los servicios online.

Una lección a aprender de HealthCare.gov es que asignar a un único contratista un proyecto de sistemas de información gigante constituye un riesgo crítico. Para mitigar este riesgo hay que buscar la forma de distribuirlo entre varios proveedores. Sin embargo, uno de los problemas básicos identificados por Dickerson y su equipo es el mecanismo de compras públicas de software, el cual anima a licitar todo el alcance en una sola compra. Así que parte del trabajo del US Digital Service es mejorar la regulación de compras públicas de sistemas de información.

Otra lección no desligada de la anterior es que las metodologías de desarrollo en cascada tienden a hacer que los errores no se detecten a tiempo. Esto se mitigaría mediante desarrollos ágiles. Así, los mastodontes se podrían comer de a bocaditos y, de paso, dar entrada al mercado de software público a las PYME, que hasta ahora lo tienen de facto vedado.

La metodología ágil permite comenzar los proyectos con pocas definiciones, obtener productos en plazos muy cortos y detectar problemas tempranamente. Pero, por el otro lado, implica: una dificultad mayor para estimar plazos y presupuestos finales; que los proyectos sean más intensos, requiriendo ritmos que en muchos casos los funcionarios contraparte tendrán dificultad en asumir; y de parte de las empresas, se requiere desarrolladores con gran experiencia. Y todo esto supone proyectos (al menos inicialmente) más caros, una relación de mucha confianza entre cliente y proveedor (para nada obvia en las compras públicas) y la necesidad de una mayor capacidad articuladora por parte del cliente. El desafío para el ámbito público, donde las indefiniciones en las compras pueden dar lugar a problemas de transparencia y de cumplimiento de contratos, no es menor.

Como conclusión final, podemos decir que HealthCare.gov, tras sufrir severos problemas, logró obtener un producto que está siendo utilizado tal como se esperaba. Los aspectos más salientes de este proyecto y cuyo análisis nos será útil para nuestros proyectos son: una diferencia sustancial entre el presupuesto inicial y el final; el presupuesto colosal que los países desarrollados están dispuestos a asignar a la implementación de sistemas de información; la asignación de un proyecto de este tipo y de esa dimensión a un solo contratista; y la aplicación de metodologías de desarrollo rígidas (no ágiles).

Continuaremos con el análisis de más casos en el próximo post.