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.