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.

Anuncios

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.