Portales One-stop shop 

Desde hace algunos años que estamos viendo un proceso de implementación de portales de trámites para personas y empresas, con la lógica del modelo One-stop shop o ventanillas únicas.  Esta corriente que la iniciaron fundamentalmente países anglosajones, con los ingleses a la cabeza y su portal Gov.uk, marcaron una ruta que muchos países han adoptado en la región.  Algunos ejemplos de ello son: Chileatiende y EscritorioEmpresa en Chile, Tramites.gub en Uruguay, SIVirtual en Colombia y Gob.MX.

Si bien estas iniciativas resultan una buena idea, se aprecian una serie de dificultades que han tenido que resolver, algunas con mayor éxito que otras. Ya hay aprendizajes sobre la mesa que es bueno tomar.

 

 

¿Por qué es complejo abordar estos procesos?

 

Revisemos algunos de esos desafíos, que resultan fundamentales tener presentes a la hora de diseñar y/o implementar uno de estos portales.

 

  • Complejidad en el diseño y gestión del proyecto, este tipo de proyectos plantean algunos desafíos importantes desde el punto de vista de su diseño y gestión, ya que habitualmente la institución que aborda el tema, tiene bien poco poder o poco reconocimiento del resto de la institucionalidad pública para al asumir el rol de intermediario, al menos en los modelos que me ha tocado ver en la región. Otro elemento, es que estos proyectos habitualmente no están adecuadamente priorizados en las puntas, esto es, que las instituciones que resuelven el trámite finalmente, deben hacer algunas modificaciones y desarrollos para interactuar con el portal, procesos de desarrollo que habitualmente no han sido priorizados. Por otra parte, no hay incentivos claros para realizar dicho desarrollo, ya que es muy frecuente que estas iniciativas no cuenten con KPI’s que impacten directamente a las instituciones. Finalmente, un tema de la mayor importancia es establecer estos modelos en forma escalonada, con la lógica de proyectos delfines más que ballenas, en lugar de proyectos muy ambiciosos y con lógicas maximalistas, lo cual choca muchas veces con los tiempos políticos.

 

  • Encadenamiento, es frecuente escuchar el cuestionamiento, ¿por qué poner una ventanilla a trámites que ya están en la web? Si solo se trata de una ventanilla más, es poco el valor público que agregan, pero si logran moverse de la lógica de trámites a meta-trámites, o bien encadenamiento como lo conocen algunos, si se agrega valor.  Las personas no necesitan muchos de los trámites que tienen que hacer, es sólo porque son parte de una cadena, por ejemplo: los certificados de nacimiento NO tienen valor en sí mismos, sólo son prerrequisito para algo más.

 

  • Front End o ventanilla de otros, los servicios públicos son bastante celosos de que un tercero aunque sea parte del mismo Estado los intermedie.  Prefieren tener contacto directo con el ciudadano, por lo cual, si esta intermediación no se hace en forma cuidadosa, por ejemplo destacando que instituciones participan de un proceso (por ejemplo poniendo el logo) se produce un efecto de rechazo inmediato.

 

  • Complejidad de los trámites, el modelo one size fits all que adoptó Gov.uk, puede ser todo un problema, ya que la varianza de interacciones que el Estado tiene es muy grande, desde simples solicitudes de certificados, hasta complejos procesos que requieren de múltiples interacciones, incluyendo en algunos casos etapas presenciales (por ejemplo: inspecciones de instalaciones), por lo que la arquitectura de diseño debe contemplar esa variabilidad de trámites. Hasta el Gov.uk se topó con este problema, producto de un análisis simplista de este tipo de situaciones.

 

  • Interoperabilidad y Semántica, este es un tema recurrente, el cual se expresa muchas veces en bajos niveles de interoperabilidad semántica entre servicios públicos, lo que genera importantes desafíos de estandarización y acuerdos multinstitucionales, para producir ese encadenamiento esperado.  Muchas veces el problema de la interoperabilidad se centra en la técnico, lo cual dista mucho de los problemas más recurrentes en este ámbito.

 

  • Arquitectura, tipo de arquitectura a diseñar, ya que existen desde modelos bastante light, esto es, la lógica de broker de trámites hasta ventanilla con altos niveles de inteligencia, la pregunta es: ¿qué modelo me conviene? mientras mayor es la profundidad del proceso, más complejidad incorporo. Otro de los elementos, que influyen en estos diseños es el alcance (todo el estado o sólo parte de el). Estamos hablando de decenas y centenares de millones de transacciones de trámites, dependiendo del tamaño del país, lo cual pone una exigencia en términos de escalabilidad a este tipo de plataformas muy significativo. Son pocos los países que conocen el universo total de trámites que realizan las personas y empresas, y menos aún conocen la cantidad de total transacciones. Otro gran desafío, desde el punto de vista arquitectónico es que mecanismo de autenticación y firmado (para aquellos trámites que requieran de un proceso de firmado por parte del usuario final) voy a utilizar, ya que es muy frecuente que no existan mecanismos centralizados, y por lo tanto hay que establecer complejos sistemas de dominios de confianza para no obligar a los usuarios a autenticarse varias veces.

 

  • Operación, a la hora de operar estas plataformas deben enfrentar un problema serio desde el punto de vista de los niveles de servicio ofrecidos al usuario final.  Este tema se acentúa, cuando tengo trámites encadenados, porque la plataforma depende de los niveles de servicio que puede ofrecer el backend del(los) servicio(s) publico(s) involucrado(s) en la cadena.

 

 

 

Si estos elementos no están sobre la mesa a la hora de diseñar e implementar estas iniciativas es muy probable que el proyecto fracase, o al menos no cumpla la promesa original. 

Comparte este artículo en

4 comentarios

  1. Hola Alejandro,
    ChileAtiende cae en esta categoría? Entiendo que no realiza transacciones sino que te enlaza con los sistemas de cada servicio público.
    Saludos!

  2. Hola Guillermo,

    Gracias por tu comentario, efectivamente ChileAtiende también cae en esa categoría, el Gov.uk partió como un concentrador de información de trámites, para luego evolucionar a un modelo más profundo. En general estos portales parten en la modalidad informacional para luego avanzar hacia un modelo más transaccional.

  3. Hola Alejandro, gracias por tu columna.
    Creo que de la innovación atomizada que a veces vemos y que agrega gran complejidad es la que no permite, más por mito que realidad el no funcionamiento del “one size fits all” que mencionas.

    Hace años me toco participar de la discusión de la línea única de procesos para el INDAP, la cual se logró a nivel de meta procesos, dejando la casuística para ser desarrollada por cada uno de los servicios. Lo que quiero decir es que si logramos identificar las lineas de procesos base, dejando de lado los egos de los servicios y ministerios nos daremos cuenta que no son tantos tipos de trámite.

    Por otro lado hoy tenemos a la mano soluciones de robotización que en caso de dificultar la integración de sistemas, por tiempo , presupuesto o incluso miopía, pueden ser una buena solución para eliminar procesos repetitivos que muchas veces son los que dificultan la aplicación de este tipo de sistemas.

    Finalmente, y una vez más, tiene que ver como todos los procesos de modernización, principalmente en el Estado, con : Voluntad Política, Capacidad Técnica, y sobre todo un Gran Liderazgo de quienes tienen la tarea, de forma que logren traccionar a sus pares, y sobre todo a los superiores.

    Un abrazo!

Deja un comentario:

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

Blog eL ABC de Alejandro Barros

Suscríbete a newsletter

En este espacio reflexiono sobre Modernización del Estado, Innovación Pública, Desarrollo Digital, tecnologías de información y otras yerbas.