Modernización del Estado: ¿y qué hay del back office?

Días atrás hablando con algunos amigos vinculados a los temas de Modernización del Estado y sobretodo aquellos que dicen relación con la digitalización de los procesos de este (gobierno electrónico), les compartía mis reflexiones en este ámbito, las cuales se ven influenciadas por temas recientes asociados a grandes proyectos TI, cuyo resultado no ha sido especialmente bueno.

En los últimos años, hemos visto una preocupación creciente en muchos de los estados de la región por dotar a los servicios públicos de portales en la web con toda clase de servicios, transacciones e información.  Este tema, no sólo ha sido preocupación de los practitioners, sino también de la academia produciendo mucha investigación y documentación en torno al tema, me incluyo.

Hoy en día, es cool hablar de open data y servicios centrados en el ciudadano.  Pero, por lo que me toca ver, en la región hemos olvidado, lo que algunos denominan back office, la trastienda o cocina, como se llama en forma menos docta.

Se nos olvida, que para dar servicios en la web, sean estos, de transacciones y/o de información, las instituciones públicas deben resolver algo, que es de perogrullo, pero que con frecuencia se olvida, contar con un adecuado soporte TI a sus procesos de negocios y operacionales.

Al observar a los servicios públicos que cuentan con el mayor nivel de exigencia en términos de prestación de servicios transaccionales, llegamos a un listado de instituciones públicas que generalmente se repite en todos los países, por mencionar sólo algunos:

• Servicio de registros de personas (registro civil)
• Servicios de registro de propiedades (conservadores de bienes raíces, registros de propiedad,…)
• Sistemas y Administraciones Tributarias
• Seguros públicos de salud
• Sistemas de beneficios en áreas masivas (educación, pensiones, …)

Todos estos servicios requieren para sus operaciones, sofisticados sistemas informáticos que den cuenta de la  complejidad que tiene su entorno y exigencias operacionales, las cuales se expresan en:

• Ato volumen de transacciones, hablamos habitualmente de muchos millones mensualmente;
• Gran cantidad de datos, son terabytes de información;
• Importantes cantidades de intercambio de datos entre sistemas muy diversos y en muchos casos poco estándares;
• Gran variedad de tecnologías, muchas veces con altos niveles de obsolescencia.

Todo ello, plantea escenarios muy complejos, que en pocas ocasiones son visualizados adecuadamente, manejar millones de transacciones, terabytes de datos y altos niveles de disponibilidad es un escenario que debe ser diseñado e implementado tomando en cuenta estos aspectos a la hora de definir la arquitectura TI.

Algunos ejemplos recientes de modernizaciones, en las cuales el front office (la ventanilla) estaba lista pero el back office (sistemas operacionales) no, como fue el caso de Healthcare.gov.  Un portal web con buenos niveles de usabilidad, lanzado con bombos y platillos por la administración Obama en septiembre 2013, pero que todo su modelo de integración con sistemas legados (legacy) de múltiples instituciones públicas y privadas falló, recuerden que inicialmente y durante un buen rato (más de un mes) sólo el 1% de las transacciones terminaba en un proceso exitoso.  Este es, probablemente un ejemplo emblemático de este tipo de problemas, las cascara lista pero los sistemas de información de soporte a los procesos no.

El estado ha demostrado no ser muy bueno en los procesos de modernización de su backoffice, salvo honrosas excepciones, este tipo de proyectos son de gran tamaño y con múltiples factores de riesgo no solo de carácter tecnológico, algunos de estos riesgos (tomados desde mi libro polisDigital) que creo influyen son:

• Proyectos muy ambiciosos tanto desde el punto de vista funcional como de alcance
• Uso de tecnologías no probadas y con poco conocimiento local
• Contratos largos y de compleja administración, asumiendo que el contrato resolverá todo si el proyecto tiene problemas, en lugar de contratos más pequeños y manejables, separando componentes de diferente naturaleza.
• Creer sólo en lo que dicen los proveedores, sin contar con adecuada contraparte.
• Proyectos con una duración muy larga en su desarrollo y que tiene riesgos importantes en términos de cambios funcionales y/o de obsolescencia tecnológica
• Creer en todo lo que le dicen del grado de avance del proyecto, no basta sólo con la carta Gantt, deben existir otros KPI
• Esperar que los problemas se van a resolver más adelante y no asumir los costos de la decisión temprana
• Premisa de que al incorporar más recursos (técnicos, humanos o financieros) va a resolver el problema.
• Desconexión de la autoridad que toma decisiones políticas acerca del impacto de la implantación del SW.

En mi experiencia, he podido observar en muchas personas la simplificación con que se miran algunos de estos proyectos, un comentario que se escucha, es que sólo basta con contar con un bonito portal web para que las cosas caminen mejor, la evidencia empírica muestra todo lo contrario sino pregunten a la Secretario de Salud del gobierno de Obama!