Si algo es de envidiar a los británicos, es la capacidad para definir todos y cada unos de los aspectos de los modelos de Administración Pública que tratan de poner en marcha los sucesivos gobiernos, apoyándose en una miriada de think-tanks de la más diversa índole. El modelo PBA (Post-Burocratic Age) incluido en la visión de "Big Society" del gobierno de coalición actual no es una excepción, y recientemente encontré un interesante documento denominado "Better for less. How to make Government IT deliver savings". El documento pretende resumir cuál es el marco en que debe abordarse el uso de las TIC dentro de una Administración Pública PBA.
El documento es una lectura imprescindible, más teniendo en cuenta la futura y previsible extensión de la ola conservadora a nuestro páis. Si bien parte de premisas erroneas se pueden obtener interesantes conclusiones para la innovación de cómo hacemos frente al uso de las TIC en las AAPP. Aclaro lo de las premisas erroneas. En primer lugar, dudo que sea viable un modelo extremo de PBA de Administración Pública, siempre es necesario la existencia de una jerarquía y el establecimiento de unos objetivos en una organización politizada (y eso es lo que somos). En segundo lugar, no creo cómo afirma el texto que el problema de la falta de mejoras de productividad en las AAPP tras una decada de inversiones TIC se resuelva exclusivamente replanteando como realizamos la adopción de las TIC en las AAPP. Son necesarios cambios organizativos que no se abordan (e.g. reducción de horarios de ventanillas o prohibición paulatina del uso de papel).
Si es cierto, sin embargo, que un mayor partido al empleo de las TIC podría obtenerse, y que el eje de dichas mejoras radica en cómo compramos y las normas qué para ello establecemos. En general en toda AAPP, no sólo la Británica y la Española, tal y como dice el documento "There is no effective centralisation, nor is localisation accepted - we have, instead, the worst of both worlds." O lo que es lo mismo, no aceptamos que otros nos impongan sus soluciones y además tratamos siempre de partir de cero. Ello sólo se evita con estructuras de gobernanza más fuertes (crítica la debilidad del CIO Council de UK), con lo cual coincido, aunque me resulta contradictorio con la filosofía PBA. La revisión de los procedimientos de compras TIC, tendiendo a la adquisición modular para ir construyendo a partir de éxitos en medio plazo, es quizás otra reforma necesaria.
Si es cierto, sin embargo, que un mayor partido al empleo de las TIC podría obtenerse, y que el eje de dichas mejoras radica en cómo compramos y las normas qué para ello establecemos. En general en toda AAPP, no sólo la Británica y la Española, tal y como dice el documento "There is no effective centralisation, nor is localisation accepted - we have, instead, the worst of both worlds." O lo que es lo mismo, no aceptamos que otros nos impongan sus soluciones y además tratamos siempre de partir de cero. Ello sólo se evita con estructuras de gobernanza más fuertes (crítica la debilidad del CIO Council de UK), con lo cual coincido, aunque me resulta contradictorio con la filosofía PBA. La revisión de los procedimientos de compras TIC, tendiendo a la adquisición modular para ir construyendo a partir de éxitos en medio plazo, es quizás otra reforma necesaria.
Otro problema que acertadamente plantea es la falta de aceptación por las AAPP (no de modo abstracto, sino por todas y cada unas de sus unidades) de su falta de especificidad en lo relativo a las TIC. Embarcarse en costosos procesos de customización (algunos repetidas veces por distintos actores) antes de hacer uso de cualquier producto, no aceptar mecanismos de identificación de terceros (e.g. bancos) o establecer normas de seguridad propias, son algunos de los ejemplos que se mencionan. Una mayor comoditización de las TIC es precisa, pero no entendida esta como un mero outsourcing, sino como una reutilización generalizada de éxitos internos de las AAPP en otros departamentos. Ello requeriría una aproximación más modular a las soluciones, y la construcción de lo complicado a partir de lo simple ya validado.
Open data, open source, open standards, open markets. O como la apuesta por lo abierto lleva a un menor coste de las TIC para las AAPP, a una menor dependencia de un conjunto reducido de suministradores.
El modelo para la solución de los problemas enunciados y otros es denominado ILC (Innovation, Leverage, Commoditation). Desarrollar la innovación en pequeñas dosis sin pedir permiso, para apalancarse sobre ella mediante la agregación de soluciones y construir mediante la comoditización de lo probado las soluciones a los grandes problemas.
La descentralización radical de la resolución de los problemas, bajo unos estándares desarrollados desde el centro, permitiría realizar la agregación de componentes dentro de una nube de servicios apoyado en arquitecturas orientadas a servicios. Nada nuevo, ya figura una teorización similar en la Declaración de Malmö, pero la que da un marco práctico de gobernanza de cuatro niveles: Dirección, Financiación, Monitorización, Implementación.
Andrés, estoy de acuerdo con gran parte de tus comentarios, y haré caso de tu sugerencia de lectura del documento al que haces referencia.
ResponderEliminarSolo hay un punto sobre el que tengo una opinión distinta, y es sobre la preferencia por lo open en tecnología. En mi opinión, la base de un buen sistema informático es la robustez y cálidad de sus elementos base, lo que llamamos los técnicos la plataforma. Aquí es donde veo que se están cometiendo errores de bulto en la administración, por un cierto desconocimiento según mi parecer.
Open source en sistemas no es firefox ni openoffice. Por supuesto que son herramientas a mi entender clave, y que yo estoy poniendo en marcha en mi organización, seguramente de una forma mas atrevida que muchas otras que se declaran opensource.
Pero hay otros elementos que son la base de los sistemas, en los que intentando digamos ahorrar nos estamos metiendo en una complicación que no se valora en su sentido amplio.
Para mi, en la parte de sistemas centrales, opensource hay que limitarlo a apache y como mucho a linux en algunas partes, y siempre con distribuciones soportadas.
El opensource tiende a requerir una gran cantidad de esfuerzo en su implantación, y como permite una gran parametrizacion (esto es así, es una de las cosas buenas), acaba no pareciendose a lo que uno se baja de internet. Con lo que hacemos cada vez mas diferentes nuestros sistemas, haciendo imposible la comparticion de los desarrollos.
Para mi, lo que falta es que desde la administración central se haga una apuesta por negociar con alguno de los grandes la adquisición masiva de una plataforma para que todas las administraciones medianas y pequeñas puedan acceder a tecnología punta, de fácil implantación, a un coste reducido. Hablo de las tecnólogias des portal, bus, bpm, gestor documental, base de datos. El middleware no ha de ser el problema, ha de ser estable para poder realizar las integraciones con el nivel de robustez que se precisa.
A partir de aquí, seremos capaces de desarrollar servicios en cloud, o reutilizar desarrollos como programas que ejecutemos cada uno en una misma tecnología de plataforma.
Si a esto le añadiéramos una unificación de los modelos de datos de la información, estaríamos en ese mundo buscado de la reutilizacion del software y de la interoperabilidad.
Un saludo,
Antoni, estoy de acuerdo contigo en que lo opensource no tiene porque ser la mejor solución, y que a veces se adopta sin pensar en todas las implicaciones. En lo ecónomico, claro, a veces exige unas capacidades internas que no están al alcance de todas las organizaciones o contratar unos servicios que suponen un coste similar al propietario. Pero no todo es la pela. Las implicaciones de transparencia y competencia son innegables.
ResponderEliminarSi creo que en la Administración un problema de compras es que no se hace fuerza de la escala. Por ejemplo, en la AGE el presupuesto TIC es de mil y pico millones, pero al no agregar demanda tenemos el efecto de presupuestos de 100 y pico, q no es lo mismo.
Y al respecto de la adopción de opensource en las AAPP en España, ya quisieran los amantes del opensource q estuviéramos cometiendo errores de bulto con ello.
Hola Antoni,
ResponderEliminarperdona que discrepo con tus comentarios en materia de soluciones libres, ya que estamos permanentemente evaluando y utilizando frameworks para AAPP, incluso con desarrollos en el paradigma BPMS. Nuestro desafío es lograr un ambiente completo para construir aplicaciones que evolucionen desde ERPs tradicionales(GRPs en este contexto), hacia ambientes modernos en materia de una suite BPM. Lo estamos logrando rápidamente desde que en noviembre pasado, comenzamos a emplear OpenERP, le conoces?
Vamos muy bien encaminados en materia de "desarrollar servicios en cloud, o reutilizar desarrollos como programas que ejecutemos cada uno en una misma tecnología de plataforma...
una unificación de los modelos de datos de la información, reutilizacion del software y de la interoperabilidad."
Nuestro horizonte es "lograr modelos de gestión(PRIMERO) para AAPP que se sustenten en Ecosistemas nTICs LIBRES, para poder REPENSAR las organizaciones públicas centradas en sus CIUDADANOS", por lo tanto también priorizamos la PARTICIPACIÓN en todas sus variantes y complejidad.
Reciban un saludo, desde Misiones, Argentina