archivo

Archivos Mensuales: mayo 2012

Pocas estrategias de desarrollo de sistemas de información han hecho más daño que orientarlos hacia sistemas tramitadores.

Esta estrategia ha añadido complejidad a procesos que durante años y años se han gestionado de manera casera o con recursos informáticos de manera más simple y que ha permitido a usuarios y gestores trabajar.

No se trata de no evolucionar hacia soluciones más productivas sino de entender que el empleo de tramitadores, salvo en circunstancias muy concretas, no proporciona valor al proceso (lo explico un poco más adelante).

En primer lugar porque el diseño de los procedimientos o flujogramas en los tramitadores se ha realizado, por regla general, de manera nefasta. ¿Por qué? Se ha considerado, en unos casos de manera más extrema y en otros de menos, que cada acción o tarea que realiza un usuario es una fase, lo que nos lleva a diagramas de decenas de fases (cuando no del orden de tres cifras).

No está mal tener esa secuencia de pasos, pero después debe adaptarse a un flujograma tramitable y eso no se consigue con tantas fases y transiciones, en las que los usuarios en lugar de realizar su trabajo lo que hacen es llevarse todo el día haciendo clicks con el ratón.

En segundo lugar los tramitadores tratan de darle uniformidad a procesos que en la realidad no la tienen ni la van a tener (lo de siempre: la informática no resuelve problemas organizativos), por lo que en el momento en haces más rígido lo que de manera natural necesita más flexibilidad provoca rechazo por parte del conjunto de usuarios, los cuales abandonarán el sistema y si no pueden hacerlo, tratarán por todos los medios de que su forma de trabajar habitual encaje en lo posible en el sistema, lo que impactará probablemente en la calidad del dato.

¿Por qué digo que salvo en casos concretos los tramitadores no proporcionan valor? Pues porque en la mayoría de los casos se ha metido con calzador, sistemas de información dentro de este paradigma por el simple hecho en muchos casos de querer controlar el estado o fase de un determinado procedimiento. Eso por sí solo no justifica el empleo de un tramitador.

Lo que sucede es que un sistema tramitador tiene por debajo un motor de tramitación y por encima una plataforma de tramitación (sea genérica o no) que proporcionan servicios de valor añadido al usuario, sin embargo esos servicios no son inherentes a un sistema tramitador sino que se han añadido a estas plataformas porque son recursos que necesita el usuario (envió de documentos a portafirmas electrónicos, almacenamiento de documentos en gestores documentales, registro y archivo de documentos, etc…) y perfectamente se podían haber definido fuera de las mismas de manera genérica en otro tipo de plataformas no orientadas a caminar dentro de un flujograma.

Los usuarios deben ser conscientes del esfuerzo y el coste que tiene el desarrollo de un sistema de información. Cuando no tienen esa referencia se piensan que están disparando con pólvora del rey y que pueden estar haciendo y deshaciendo el sistema a la ligera, sin unos criterios sólidos.

Soy un defensor a ultranza del feedback porque es a través de él como se consigue que la aplicación paulatinamente se vaya aproximando a las expectativas de los usuario, pero el feedback debe perseguir una intención, de lo contrario se convierte en prueba y error.

Los usuarios muchas veces tienen la percepción de que una aplicación es un bloque de plastilina que se moldea con facilidad a sus requerimientos y si además no tienen la impresión de que eso cuesta mucho dinero y esfuerzo tienden a no centrarse en lo realmente prioritario en los feedbacks queriendo en muchos casos encontrar la cuadratura del círculo (y cuando la encuentran quieren otra cosa).

Por ese motivo soy partidario de los feedbacks sobre el producto en producción, lo que debe llevarnos a intentar poner en marcha la mínima versión del producto que pueda ser utilizada de manera real por los usuarios. Esa mínima versión utilizable dependerá del sistema que se desarrolle y de su contexto (existencia de otros sistemas previos, necesidades de la organización, etc…) por lo que en muchos casos el tiempo hasta tenerla disponible será mayor del que nos gustaría, obligando a hacer feedbacks sobre versiones usables pero en un entorno de pruebas o preproducción.

Si una organización tiene decenas (o centenas) de aplicaciones o sistemas de información es un mal síntoma. Como es lógico se trata de solo un indicio, hay organizaciones y organizaciones y necesidades y necesidades, sin embargo incluso en situaciones donde podría justificarse algo así habría que pensarse muy seriamente en reducir el censo de sistemas de información, ya sea haciendo un esfuerzo por erradicar ciudades fantasma o por unificarlos.

Cuando nos encontramos en esta situación nos encontramos con un parque de aplicaciones fragmentado tecnológicamente y que requerirán distintas versiones de muchas cosas para funcionar y cuyo mantenimiento requerirá en muchos casos una cierta especialización (a esto se llega después de muchos años y en los sistemas, como si de un corte en el terreno se tratara, se ve reflejada la evolución “geológica” que ha tenido la organización).

A esta situación se llega porque lo fácil es asociar, salvo que sea algo evidente, necesidades a nuevos sistemas, en lugar de hacer un estudio previo que determine si tal vez lo mejor es evolucionar uno ya existente para recoger estas necesidades.

Como ese estudio no se hace, nos encontramos con un segundo problema, un parque de aplicaciones fragmentado a nivel de dato, gestionándose dominios comunes de datos como si fueran independientes y existiendo, en consecuencia, una falta total de coherencia entre los mismos como consecuencia de eso y en muchos casos (la mayoría) con serias dificultades de poder relacionar una misma entidad con otra en caso de que se vaya a abordar en un futuro la integración de los sistemas a nivel de datos.

Hace muy poco un amigo me comentó que en su organización tenían un sistema de información que se encontraba lejos de satisfacer las necesidades y expectativas de los usuarios y que eso implicaba que tras la puesta en marcha del mismo se hubiera convertido en una ciudad fantasma.

Los usuarios no querían parches sino un cambio radical en el sistema.

Es cierto que el proyecto que originó la aplicación tenía un pasado y que iba respaldado por una inversión importante, pero, ¿se consigue la solución mirando hacia atrás o hacia adelante? Hay que mirar atrás para saber qué se ha hecho mal y por qué se ha llegado a esa situación, sin embargo la solución solo tiene un sentido y es actuar desde el presente para intentar obtener resultados en el futuro.

Si los usuarios no quieren parches y existe una justificación objetiva para ello no debemos invertir esfuerzo en hacer esos parches (sí que se debe invertir en convencernos de que los parches no suponen la solución). Mi amigo me puso un ejemplo rotundo: “imagina que la aplicación es como un traje y que actualmente es un traje de luces (de torero) y que el usuario quiere una chaqueta y una corbata, por mucho que vayas haciendo costuras sobre el traje de luces no tendrás un traje decente con chaqueta y corbata”.

Si el área usuaria para en la definición del sistema lo mejor es parar el proyecto hasta que la situación se reconduzca. Esto tiene muchos inconvenientes, entre otras cosas porque puede deshacer al equipo de desarrollo y dar al traste con planificaciones generales de parte del Departamento de Informática y con las expectativas de los responsables funcionales cuyas necesidades dieron lugar a este trabajo.

Pero por mucho inconveniente que nos encontremos ninguno será superior a desarrollar un sistema de espaldas al usuario por mucho que hayan sido los propios usuarios designados para definirlo los que se hayan puesto de espaldas al mismo.

La tentación de liarnos la manta a la cabeza y continuar es muy grande porque probablemente encontremos presiones que nos empujen a ello (si somos un proveedor de servicios de desarrollo de software tendremos a los responsables de turno protestando porque el taxímetro se ha parado, si eres el responsable técnico del cliente tendrás al proveedor protestando por el motivo anterior, etc…), sin embargo la solución no debe pasar por ahí, sino por intentar reconducir la situación y si no se consigue, negociar una salida digna para todas las partes.

¿Cuánto dinero ha costado que prácticamente cada Administración Estatal, Autonómica, Provincial o Municipal tenga una solución de Oficina Virtual y servicios de autenticación y firma electrónica?.

¿Tiene sentido ese gasto?, ¿qué beneficios proporciona esa fragmentación?.

Ese gasto (muchos millones de euros) está muy lejos de ser justificados con los más que mediocres resultados que se están obteniendo con la Administración electrónica.

Y lo peor es que no se trata de un gasto realizado de una sola vez, después hay que mantener toda esa infraestructura, por lo que se están “pagando intereses” por ese motivo.

Esa fragmentación es además tecnológica, por lo que lo que funciona en mi relación administrativa con una determinada Administración no tiene por qué funcionar con otra (aunque esté en el otro lado de la calle).

Esta fragmentación es el resultado de esa velocidad desbocada que cogió la implantación de la Administración Electrónica donde sin la existencia de un plan, cada uno hizo la guerra por su cuenta.

¿La solución? No es fácil, teniendo en cuenta todo lo que hay ya implantado. Desde mi punto de vista se debería tender a servicios de Oficina Virtual y de autenticación y firma electrónica en nubes que engloben a conjuntos de órganos administrativos, por ejemplo, en el caso de una Comunidad Autónoma una sola Oficina Virtual y un solo servicio de autenticación y firma electrónica para todas sus Consejerías (yo incluso iría más allá e intentaría arbitrar las medidas oportunas para que todas sus Diputaciones y Municipios la utilizasen).

Hablo de nube, no de una solución técnica que sea común y después se implante en cada sitio (para mi eso no soluciona nada y el único ahorro que tiene es no desarrollar de cero ese producto, pero que después termina siendo una utopía porque después vienen las personalizaciones, actualizaciones, etc… que al cabo de un par de años da lugar a una infraestructura fragmentada).

¿Y la integración de esas Oficinas Virtuales con los backends que probablemente estén implantados en las infraestructuras de cada entidad administrativa? Respondo con otra pregunta, ¿acaso es eso un millonésima parte más caro o complejo que mantener las infraestructuras actuales?.

Lo he dicho muchas veces y no me cansaré de repetiros el mantra de que la informática no resuelve problemas de carácter organizativo. Primero se tienen que resolver estos problemas y después la informática ayudará a hacer más eficientes los procesos (si se ha trabajado bien) y a obtener información y conocimiento de los mismos que permitan tomar decisiones que lleven a una mejora continua de la organización.

La implantación de la Administración Electrónica debería haber sido precedida por un plan general de racionalización de los procesos administrativos y eso se hacía mediante cambios de Leyes y normas. Este proceso se ha ido realizando de forma coetánea a la implantación de la Administración Electrónica de manera muy lenta, lo que no ha beneficiado en nada a la expansión de la misma.

Simplificando procesos no solo se reduce la carga de backend, sino que también tiene un impacto directo con el ciudadano ya que se simplifican los trámites y los tiempos medios de tramitación de los procedimientos.

Que tenga que haber una conjunción planetaria para poder presentar un trámite (que lo mismo me he llevado decenas de minutos u horas rellenarlo) es uno de los mayores males para la expansión de la firma electrónica.

Si un ciudadano de a pie tiene que empezar a instalar otro navegador, bajar de versión el que ya tiene, instalar un fichero por aquí y otro por allá, que le pregunten por versiones de máquina virtual Java, etc… lo tenemos claro si realmente queremos que se utilicen los servicios de administración electrónica.

La complejidad tenemos que solucionársela al ciudadano y no que sea él quien resuelva lo que no se ha sabido hacer bien. Apple ha enseñado el camino en ese aspecto: hacer esfuerzos importantes de ingeniería para que el usuario disfrute de sus dispositivos y servicios y no para perder el tiempo en aprender a utilizarlos.

Es necesario que la solución de autenticación y firma electrónica elegida tenga una matriz de compatibilidad con los principales navegadores del mercado y con el mayor número de versiones de los mismos y lo más importante que el tiempo existente entre una nueva versión de esa solución que cubra una nueva versión de esos navegadores sea cuestión de horas o de días (como sucede con los principales antivirus cuando surge uno nuevo) y no solo eso, que esa nueva versión llegue al entorno de producción poco después y con el menor coste de instalación (o desatendido con autorización previa de instalación o no).

Un error muy típico lo tenemos en el diseño de los formularios de presentación telemática en los cuales, en lugar de buscar soluciones simples y sencillas para el ciudadano o para personas jurídicas se ha optado por el diseño de angostos formularios para los cuales se necesita tener quince doctorados para rellenarlos con una información medianamente decente (en el caso de que el ciudadano tenga la paciencia necesaria para rellenarlo, la calidad del dato no será muy buena, lo que después dará probablemente a uno o varios trámites de subsanación).

Con estos formularios se pretende que el ciudadano descargue de parte de trabajo a la Administración, cuando en realidad el objetivo de la Administración Electrónica es distinto: facilitar y simplificar las relaciones que tiene el ciudadano con la Administración. Y no me vale el criterio del ahorro económico para dar un mayor “trabajo” al solicitante, ya que salvo excepciones ese ahorro económico es ínfimo.

Por otro lado hay que tener en cuenta que el desarrollo de formularios complejos requiere unos mayores costes de desarrollo y unas plataformas de Oficinas Virtuales a la vez más complejas. Lo mismo lo que te consigues ahorrar por un sitio (a costa del ciudadano) te lo terminas gastando por otro.

Los formularios deben ser simples siempre que sea posible (y es posible incluso en aquellos casos donde parece que no es viable realizar esa simplificación) y no pedir al ciudadano que realice tareas redundantes o que podría realizar la Administración, por ejemplo, si un determinado trámite telemático requiere una memoria que se adjunta en la solicitud, no se le debe hacer al ciudadano grabar en el formulario información contenida en el mismo (salvo que sea absolutamente necesarios).

¿Por qué no termina de arrancar la administración electrónica? La respuesta es compleja y en los siguientes artículos voy a comentar algunos factores que, desde mi punto de vista, tienen gran influencia.

No obstante antes de entrar a analizar esos factores es importante poner sobre la mesa una realidad (al menos para mi) y no es otra de que las expectativas puestas en la administración electrónica eran demasiadas, se disparó la inversión y se empezaron a hacer leyes sin tener en cuenta el contexto real en el que nos encontramos.

Las Administraciones Públicas se lanzaron a montar oficinas virtuales, aplicaciones que en tenían en sí una oficina virtual embebida, a contratar sistemas de autenticación y firma electrónica y todo con poco orden y concierto. El fin evidentemente era positivo pero las acciones para llegar a ese fin no.

¿Por qué digo demasiadas expectativas? Pues porque se pensaba que a base de dinero se conseguiría una implantación eficaz de la misma y no ha sido así. Se han conseguido resultados, es evidente, pero ¿están acordes a la inversión realizada?.

No quiero que entendáis que estoy en contra de la Administración Electrónica, antes al contrario, soy un defensor a ultranza de la misma y lo que critico es cómo se han hecho las cosas, se ha ido a un ritmo de 1000 km/h cuando en realidad se hubiera requerido un ritmo inferior y que hubiera conseguido unos resultados como mínimo similares y con una inversión mucho menor.