Datos o documentos ¿Cuál es la piedra filosofal del e-gobierno?

Cuando uno empieza a comparar modelos de e-Administración empieza a ver algunas diferencias sustantivas. Una de las que me resulta más interesante es la ortientación utilitaria de los planes. Esto quiere decir, sobre qué elemento vamos a centrar la atención y las acciones en las etapas de diseño para que luego sea el elemento nuclear de la acción organizativa. En este caso hasta la fecha he encontrado dos enfoques diferenciados: los documentos y los datos. Puede parecer una disquisición filosófica, pero tanto el debate que generó este tema en el INAP social como las implicaciones reales de diseño hacen que sea, en realidad, uno de los aspectos más determintantes en el desarrollo del e-gobierno. Así que es la hora de preguntarse muy seriamente cuál es la esencia de la eAdministración, datos o documentos.

Cuadro del Alquimista de Rijckaert
Director general buscando si el plan de transformación digital va mejor con datos o con documentos. Fuente.

La piedra filosofal de la e-administración.

Hace años tuve la locura oportunidad de hacer un curso de diseño de arquitectura de datos. El profesor del curso insistía siempre en la primera instrucción siempre: mirar cuál es el grano. Es decir, cuál es la unidad mínima sobre la que construir esa base de datos. A decir verdad la comprensión de este aspecto hacía que un modelo fuera sencillo de hacer y sobre todo, que fuera sostenible y escalable.

El debate sobre documentos o datos es igual. Según comprendamos cuál es la materia prima indivisible, el átomo, la unidad mínima de operación, define lo versatil, sostenible y escalable del modelo de e-Administración. Es, en definitiva saber cuál es la esencia de la acción administrativa.

Sin embargo, al hablar de e-Administración pasa como con la alquimia: la tecnología es la magia, pero el elemento sobre el que operemos hará que el cambio sea para “un poco más de lo mismo” o para “hacer mucho más”.

El documento como base.

Empecemos por el elemento que ha servido como gasolina de la acción administrativa hasta ahora: el documento. Hasta la fecha la indisoluble unidad entre el documento y el dato era una realidad evidente. Un documento contiene datos y la validez del documento implica, por definición, la validez de los datos que contiene. En los casos en los que un dato tenía que ser rectificado, se precisaba un documento ulterior que lo indicara con igual o mayor validez.

Este modelo es, pese a lo que parezca, bastante seguro y eficiente. El documento tiene una firma, esa firma hace a una persona responsable de su veracidad, y es un elemento probatorio prácticamente indiscutible.

El dato como base

La disociación entre datos y soporte es un fenómeno relativamente nuevo y bastante transformador. Pensemos en lo que ha significado, por ejemplo, poder consumir películas o música sin un elemento físico que lo sustente. Por un lado, ha tenido un impacto muy severo en la industria creando todo el problema del intercambio de datos (e-mule, naposter, megapload o los torrents). Por el otro, ha permitido el afloramiento de industrias enormes, pujantes y transformadoras como Netflix o Spotify.

Este modelo aporta una enorme versatilidad, rapidez y ubicuidad. Puedes ver lo que quieras, desde donde quieras cuando quieras. Sin embargo, hay un papel importante de demandas de infraestructuras, soporte, seguridad e inversión base. Es decir, Netflix o Spotify son negocios enormes que son un éxito apuntalado en una deuda ingente (en modo de inversores), en gran medida por infraestructura y derechos. Y eso sin contar que una brecha de seguridad en Netflix no es ni la cuarta parte de grave que, por ejemplo, en el registro de la propiedad.

¿Qué hay que tener en cuenta?

En términos generales uno diría que un modelo es mejor que otro, pero realmente no es algo tan simple. Existen una serie de elementos que hacen más o menos viable una u otra opción. O, mejor dicho, hay unas condiciones que priman más una opción frente a otra

Aspectos organizativos

Lo primero a tener en cuenta es qué condiciones de la organización influyen en esta elección. Podríamos decir que una estructura basada en documentos es más viable en una organización con una estructura más descentralizada porque identifica y ordena responsabilidades. Es decir, si el ministerio A puede necesitar documentos del ministerio B para poder realizar un procedimiento, y tienen igual jerarquía y técnicas muy diferenciadas, un documento será más rápido y fiable que el modelo de los datos.

Sin embargo, si tenemos una organización con la suficiente centralización para garantizar que un modelo de datos y de seguridad se cumple en todas las condiciones y casos, el documento se convierte en un elemento más prescindible. Por ejemplo, si el ENS y el ENI tuvieran el predicamento (y la viabilidad) que el legislador esperaba, posiblemente el aspecto documental sea innecesario.

Aspectos técnicos

El segundo elemento que diría es el técnico. Un modelo basado en documentos tiene una dependencia tecnológica menos importante que un modelo orientado en datos. ¿Por qué? Porque un documento como norma general es autoexplicativo y relativamente autonomo. Es decir, es más fácil consultar una hoja excel o un texto en word (si tienen un formato más o menos estándar y tienes una herramienta ofimática) que hacer una llamada a los datos via API o webservice.

La orientación a datos requiere, como mínimo entornos para poder leerlos y procesarlos. Esto hace que, incluso con entornos estandar, utilizar productos (o crearlos) bastante menos estandar y masivos que las herramientas ofimáticas. Esto precisa que los datos tengan una cierta homogeneidad para que su acceso y manejo sea relativamente estándar e interoperable. En caso contrario nos encontramos con dos escenarios negativos no necesariamente exclutentes. En primer lugar, un entorno fragmentado, es decir, diferentes aplicaciones para hacer procesos similares. Por otro lado puede haber entornos masivos poco competitivos: una plataforma general, poco adaptada a especificidades de alta dependencia.

Si esa normalización y estandarización se garantiza y se permite una interacción a nivel de API, es evidentemente más rápido.

Aspectos normativos

Otro plano a tener en cuenta es el normativo. El modelo normativo-administrativo incide en las condiciones generales de funcionamiento. Es decir, un país con derecho administrativo precisa definir ex-ante las características del procedimiento con gran detalle. Esto significa una regulación, entre otras cosas, del mecanismo que certifica la validez de actos que se suponen auténticos. En este sentido, un documento como decía, es más “estable” y autoexplicativo. Defines los atributos del documento, que es indiferente a la tecnología (si es estandar) y listo. Una vez que tienes un mecanismo que acote autenticación y datado, no necesitas mucho más.

Sin embargo regular los atributos de elementos tan volátiles (y con unas definiciones más complejas) como los datos es más complicado. Lógicamente habría que validar cada uno de los registros y el conjunto de las bases de datos. A mi (y no soy ni mucho menos un experto, vaya por delante) me cuesta mucho imaginar la prescripción normativa de la validez de bases de datos y registros “en crudo”, por complejidad y por la propia manera de actuar del legislador aquí.

Evidentemente, puedes optar por un enfoque más mixto, aligerar el control de los datos y cargarlo en los documentos, pero eso supone, a fin de cuentas, centrarse en documentos.

Aspectos culturales

Por último tenemos los aspectos culturales. En mi experiencia sobre este debate hay un núcleo de personas muy aferradas al documento. Entienden que es este el que asegura y garantiza el cumplimiento de la legalidad de la acción pública. Es decir, cuesta mucho disociar el contenido (datos) del continente (documento), centrando el control en el último.

Es cierto que, en términos técnicos un documento (más aún si está estructurado) no deja de ser una colección de datos. Sin embargo, tenerlos en un solo bloque y que recojan toda la información que permita controlarse de manera sencilla por cualquiera que lo pueda leer, democratiza mucho el control.

El modelo de datos requiere una importante confianza en la validez de todos los datos y en los mecanismos de control que la asegura. Auditorías de seguridad, de control de datos, logs, confiar en que quede constancia y atribución de ataques…

Implicaciones a futuro.

Con todos estos condicionantes ya nos hacemos una idea de qué podemos elegir. Ahora la cuestión es plantearnos qué supone a futuro cada uno de estos enfoques.

Infografía de síntesis
Infografía que recoge los datos del artículo

Escalabilidad

El modelo basado en datos puede crecer y replicarse más fácilmente. Una vez que tenemos la arquitectura, hacerla crecer, almacenarla y trasladarla a otros sitios es más sencillo. Es más, si utilizamos estas arquitecturas para integrar diferentes fuentes y datos podemos generar más datos. Es más maleable.

El modelo orientado en documentos tiene limitaciones importantes. El crecimiento se basa en la capacidad de crear y validar documentos aislados, que son también la base de la validez y el intercambio. Es decir, podemos aprovechar la arquitectura hasta cierto punto para generar otros documentos, pero limitados al ritmo de generarlos.

Interoperabilidad

La interoperabilidad es el siguiente punto. En términos reales un modelo de datos para funcionar debe ser interoperable. Si no lo es, acaba siendo un modelo de documentos. Si no podemos intercambiar datos, tenemos que generar documentos para poder enviarlos y consultarlos. Esto es una condición. En caso de que no se dé, el modelo tendrá datos hasta cierto momento. Si una administración tiene un intercambio de datos de padrón en casi todo su territorio, pero en otros no, al final ahí acaba el modelo hacia datos. La interoparabilidad “automática” requiere una definición homogenea de modelos de datos, tipos, conservación, ubicación…

Sin embargo un modelo de documentos es “altamente interoperable” pero poco automático. Pocas cosas son más infalibles que leer un documento y entrar los datos a mano. Sin embargo, coincidiremos que es lento. Existe la posibilidad de extraer datos de un documento estructurado y sacar los datos. Sin embargo, aunque eso automatiza la captura genera una ralentización que tiene un impacto en términos de tiempo. No es lo mismo hacer una llamada de API que permita bajar 50000 registros que descargar via webservice 50000 documentos, extraer los datos y subirlos.

Reutilización y transparencia

La reutilización de los documentos es especialmente baja. Es decir, incluso en modelos restructurados, extraer datos y operarlos es algo complejo. Sin embargo, también es cierto que hay determinados niveles de información cuyo reflejo en simples datos es poco relevante. Por ejemplo, documentos relativos a un contrato público o a una certificación de unas instalaciones, el documento tiene un valor superior. Evidentemente, estos documentos pueden, en muchos casos, reconstruirse a partir de datos, pero normalmente no son aceptados de la misma manera. Podéis verlo si presentáis el CSV de vuestro título universitario en un proceso selectivo.

Sin embargo, la generación, actualización y mantenimiento de datos es especialmente complicado si no hay una arquitectura transaccional que lo haga. Es decir, si tienes un sistema que, por ejemplo, lleve toda la gestión de personal del ayuntamiento que genere todos los datos de remuneraciones, mantener los datos es fácil. Sin embargo, si esto no está automatizado, es un martirio hacer esta gestión y luego subir los datos. Un poco lo que pasa con los contratos. Lo malo es que, normalmente, estas estructuras son especialmente grandes, caras y lentas de instaurar.

Conclusión ¿Y tu de quién eres?

En términos digitales y técnicos un modelo de eAdministración basado en datos es superior. Más rápida, más ágil, más versatil, con más potencial. Eso no evita que genere importantes problemas a la hora de generar infraestructuras, acceso, fiabilidad y mantenimiento.

Por otro lado, la eAdministración más centrada a documentos tiene una menor explotabilidad tecnológica, pero un coste, inversión y visibilidad mayor.

La cuestión, como suelo decir, no es tanto optar por un modelo u otro, sino ser consecuente con ellos. En el caso de España, en mi opinión, la apuesta es clara por los documentos, pero ni la legislación ni el plan de transformación digital (ni parte del discurso político) están diciendo lo mismo. En ese caso nos encontramos una importante frustración e impotencia entre los que se creen lo que se dice y se encuentran lo que se hace.

Si tuviera que apostar, iría a por el modelo de datos, pero esto supone un tiempo de travesía en el desierto importante. No sólo por la lentitud de los resultados, sino por la necesidad de centralizar, normalizar y conceptualizar una estructura enorme. Si queremos llegar a ese auténtico cambio, no creo que podamos hacerlo de otra manera.


Comparte este artículo

Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on pinterest
Share on whatsapp

Acerca del autor

Regístrate y consigue los últimos artículos en tu mail.

icono mail suscribete
SUSCRIBIRME

4 Comentarios

  1. Muchas gracias por este artículo, Sergio. Lo que dices es importante y esclarecedor.

    Ahora bien, creo que va a ser difícil de entender para quien no esté en la intríngulis de los datos. Lo que tú -y la Ley 37/2007- llamas “documentos” es justo a lo que mucha gente llamaría “datos”. De forma paradigmática, una hoja de cálculo. Para la mayoría de las personas, “dato” es algo procesable, mientras que “documento” es un contenido no procesable -p.e., un PDF. Como parte de este lío conceptual, se ha acuñado “conjunto de datos” (dataset) para nombrar uno de estos “documentos” -un archivo procesable, incluso en varias “distribuciones”- y sus metadatos.Tu vocabulario es el correcto, no obstante.

    Desde mi punto de vista es muy útil ENTENDER esta distinción que tú haces. Ahora bien, no me parece incompatible. De manera general, las Administraciones están abriendo “documentos” en forma de datasets, que integran “catálogos de datos” a los que se accede vía portales de datos abiertos (open data). Al mismo tiempo, cuando cuentan con una fuente de datos fiable y bien construida pueden disponer servicios de acceso directo a los datos, tanto de manera interna como vía APIs o puntos SPARQL para acceso externo. No tenemos que optar y descartar.

    Volviendo a tu distinción, tendríamos 3 enfoques:

    – Enfoque a papel: los “documentos” de toda la vida, incluso cuando se han digitalizado y llevado al gestor documental.
    – Enfoque a documento: archivos reutilizables accesibles como datasets de una iniciativa de datos abiertos.
    – Enfoque a datos: átomos de información accesibles de manera independiente, semantizados.

    Retomando tu metáfora, los datos serían los átomos del conocimientos, mientras que los datasets serían moléculas.

    1. Pues gracias por comentar. Realmente yo un dataset no lo llamaría documento tal cual porque tiene una naturaleza dinámica que los documentos que tu llamas de manera analógica, y más esclarecedora, “en papel” no tienen, dado que son más una foto fija. Diría que los datasets son, efectivamente esas moléculas que dices y es a dónde nos lleva la planificación de los datos, pero claro, cuanto más nadas hacia la foto fija, menos interés (y esfuerzo) haces por esas moléculas.
      Eso sí, la cuestión que quería resaltar en el artículo, es que no todas las organizaciones tienen las características idóneas para optar por los datos, y creo que es el caso que tenemos en España en términos generales. Creo que los datos solo tienen aplicación, actualmente, en datos sólo son viable a nivel muy individual.

  2. Gracias Sergio por este interesante debate… sin embargo, y con todo respeto hacía ti, no creo que este debate realmente exista. Dicho de otro modo, ¿por qué una administración tiene que escoger una opción u otra?, ¿no puede ser, o mejor dicho, no debería ser, ambas a la vez?

    Además, hay algunas de tus afirmaciones que no comparto (o quizás simplemente no sé ver que sean ciertas, lo cual no implica que no lo sean, puede ser que no llegue a entender tus razonamientos). Este es el caso de la necesaria centralización de la organización en un modelo basado en datos, ¿por qué?¨, precisamente la tecnología de compartición (leáse Open Data) facilita enormemente la compartición de datos sin una centralización.

    Tampoco estoy de acuerdo con esta afirmación “Pocas cosas son más infalibles que leer un documento y entrar los datos a mano.”. Si entendemos por infalible aquello que no puede errar, te puedo asegurar – dada mi experiencia en este ámbito – que precisamente la introducción de los datos a mano es uno de los procesos que generan más errores (humanos, por supuesto). Dicho de otra forma, entrar los datos a mano es de todo menos infalible.

    Tampoco estoy de acuerdo (o no acabo de entender) otras de tus afirmaciones. Insisto, posiblemente por mi torpeza en entender tus razonamientos. En todo caso, sí que valoro muchísimo que generes un debate muy interesante.

    Gracias.

    1. Hola Marc
      Yo no era consciente del debate hasta que se suscitó en el foro del INAP (te animo a que lo veas). Lo cierto es que la TD, como cualquier proyecto complejo requiere priorizar recursos, arquitecturas y demás… Pues bien, tanto es una diferencia que, mientras por ejemplo en USA u otros países anglosajones se opta por poner los datos en el centro de la gestión, en España el esfuerzo está en el documento. Incluso en Francia, muy centrada también en el uso de los datos lo hace más en términos de definición de políticas y toma de decisiones que en la operativa de la gestión convencional porque toda la carga de transaccionalidad se deja en el documento como portador de la información validada y validable. No te digo que sea mi opción favorita, simplemente, hay gente que teniendo X dinero, medios, personas y capacidad legislativa para hacer un cambio así, tiene que decidir si los centra en modelos de datos e intercambio o en la creación y aseguración de los documentos como mecanismos seguros de transmisión.
      Es ir a setas o a rolex, y creo que en los países de derecho administrativo nos gustan las setas (documentos) porque son la foto fija de la gestión que compone el expediente que recoge el procedimiento y es un cambio mayor (enormemente mayor) que un expediente conceptualmente se componga por estructuras de datos llamadas de una API. Basta ver el enfoque de la factura electrónica y cómo se ha implementado.
      ¿Por qué es necesaria la centralización para compartir datos? Tres letras para responder: ENI. Cuándo se público, cuántos lo cumplen y quienes son? Estas seguro de que si el Ministerio de AP le dice al ayuntamiento de mi pueblo que cumpla el ENI (o a la Generalitat de Catalunya, como hemos visto en otros casos, como por ejemplo, el envío de datos a la PCSP), el exito va a ser el mismo que ha habido hasta la fecha: muy bajo.
      En cuanto a “lo infalible” quizá el preciso sea “controlable”. Puedes comprobar que puede haber menos errores en la transmisión automática de datos (aunque haberlos los hay, con menor frecuencia y mayor escala), pero que si al empleado público medio le dices si prefiere una entrada de datos automática de fondo no supervisable o la capacidad de validar y supervisar un documento, esta última opción es la preferente. Entre otras cosas porque como empleados son responsables del acto administrativo que firman y, bueno, prefieren controlar de manera visual y clara los datos de los que van a ser responsables.

      Puede gustar más o menos. Pero son dinámicas organizativas importantes, no sólo ligadas al tema digital (los trabajos de March y Olsen, así como los del primero en solitario) referentes a la asimilación de tecnología en las burocracias suelen encontrarse con estos problemas. En mi opinión, no asumir estos debates y rigideces genera no poca frustración (me vuelvo a remitir al ENI o a la PCSP por poner dos ejemplo) y resultados más bien exiguos.
      Un saludo

Deja un comentario

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