La mina burocrática

“Complejidad de la gestión pública: Aprendiendo de casos no exitosos” – Parte 3

Este es el tercer 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 previo vimos el caso HealthCare.gov, un proyecto costoso, con una implementación muy dificultosa y demorada pero que finalmente logró su objetivo. Veremos en este post otro caso, el de un proceso complejo que se ejecuta con tecnologías anacrónicas.

Caso 3: La mina burocrática

En el socavón de lo que fuera una mina, 60 metros bajo tierra, en un pueblo perdido de Pennsylvania, la Office of Personnel Management (OPM), responsable del reclutamiento y gestión de la fuerza de trabajo del gobierno federal, instaló una oficina dedicada a procesar la jubilación de todos los empleados federales. En esta peculiar implementación de data mining, el trabajo se hace casi completamente con papeles, los cuales se guardan en 28.000 archiveros, luego de haber sido trasegados de escritorio en escritorio y de caverna en caverna.

Cada empleado federal al jubilarse llena en papel la solicitud de retiro, la que luego es enviada por correo normal a la caverna, a efectos de que se procese la elegibilidad. Al recibir la solicitud lo primero que se hace es juntarla con la foja de servicios del empleado. En el 17% de los casos, la misma está en papel y hay que buscarla físicamente. Para el 83% que está en formato electrónico, se la imprime de modo de poder determinar la completitud y consistencia del legajo. Una vez logrado este objetivo, los datos se digitan a un sistema que calcula el monto jubilatorio que corresponde. Un empleado revisa entonces el resultado que dio ese sistema y finalmente se aprueba la jubilación. El proceso, en promedio, dura 60 días.

Este modo anacrónico de funcionamiento provoca que diariamente los empleados reciban decenas de e-mails solicitando ayuda para encontrar legajos perdidos dentro del recinto. Como tecnológicamente el proceso no ha evolucionado, la velocidad de procesamiento es exactamente la misma que en 1977 (a comienzos del gobierno de Obama el plazo de resolución era de 160 días; para llevarlo nuevamente a 60 días se aplicó un rediseño del proceso sin incorporación de tecnología pero sí de mucha fuerza de trabajo).

El primer intento de digitalización del proceso comenzó en 1987. Tras 9 años y 25 millones invertidos, el proyecto fue cancelado sin que ningún sistema llegara a implementarse. Aparentemente, la causa principal del desastre fue que quien dirigía el proyecto por parte del gobierno era un PhD en literatura inglesa que no se percató de la necesidad de asesorarse por expertos en gestión de proyectos y en implementación de sistemas de información. Y los proveedores no colaboraron para cubrir ese vacío.

El segundo intento comenzó en 1997. Seguramente como reacción al fracaso recién sufrido, esta vez la estrategia fue un desarrollo in-house. Pero el nuevo proyecto tampoco anduvo y se volvió a buscar el apoyo de proveedores. Este tercer intento debía entrar en producción en 2008. Sin embargo, las pruebas realizadas durante 2007 arrojaron resultados desesperantes tales como tasa de cálculos correctos de jubilaciones por parte del sistema de apenas 18%. A pesar de estas evidencias negativas, igualmente se decidió poner el sistema en producción. Seguramente, los responsables del proceso no tenían cómo explicar que se habían gastado la friolera de USD 106 millones en algo que no iba a funcionar. Prefirieron hacer que los hechos hablaran, entraron en producción, nada funcionaba, apagaron el sistema y continuaron trabajando en papel. El proceso, que requiere la consolidación de un número muy grande de fuentes de datos y la aplicación de un sistema de reglas también excesivamente complejo, continuó resistiendo su digitalización. La lección a aprender fue que las pruebas de los productos si se hacen demasiado tarde ya no tienen sentido. Hay que buscar la forma de testear mucho antes de que el monstruo alcance la pubertad.

En un estudio de The Standish Group, una firma de Boston que se dedica a analizar proyectos de software, se señala que sólo 6% de los proyectos de software de gran envergadura cerrados entre 2003 y 2012 fueron completamente exitosos (los productos obtenidos se usaron y se cumplió con lo planificado); 52% tuvieron problemas (hubo exceso de costos, de plazos o el producto no fue completamente usado); y 42% fueron fracasos completos (los productos fueron completamente inútiles o el proyecto fue cancelado anticipadamente).

Así que los 3 fracasos de la OPM, si bien sorprendentes, no son eventos aislados. Sin embargo, es increíble que con estos guarismos seamos tan sobreoptimistas cuando ideamos y planificamos nuestros proyectos, asumiendo que con toda seguridad caerán dentro del 6% ideal. Poco ayudan a evitar este equívoco los metodologistas que poco o ningún acento ponen en analizar y hacer conocer los casos de fracaso. Tal vez una divulgación mayor de estas cifras contribuiría a hacer menos traumáticos los casos en que las cosas no salen del todo bien o nada bien.

Como dato anecdótico y que refleja una cultura más asociada con el tercer mundo que con Estados Unidos, el periodista David A. Fahrenthold, autor del artículo del Washington Post de donde tomé este caso, cuenta que el procesamiento de las jubilaciones del personal propio de la OPM, casualmente, se procesa en plazos menores al promedio.

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