Actualidad | Artículos | 18 FEB 2018

La Transformación Digital en las Administraciones Públicas (parte III)

Mi experiencia
transformacion-digital-logo
Victoriano Fernández

En las dos anteriores publicaciones, había expuesto cómo abordar el complejo camino de la Transformación Digital en la Administración Pública, y cual podía ser la hoja de ruta a seguir. Para terminar, presento:

 

Mi experiencia

En la Administración Pública en la que yo desarrollo mi actividad profesional, comenzamos el camino de la Administración Electrónica hace ya bastantes años, aunque no dispongamos de Sede Electrónica aún. Esperamos tenerla en breve.

Cuando nos planteamos cómo abordarla, observamos que la legislación que se estaba generando estaba toda interrelacionada, que cada vez se demandaba más a las AAPP y que, en parte, aunque siempre hablábamos de los “administrados”, no los estábamos teniendo en cuenta tanto como parecía. Así, en el proceso de diseño de nuestra Administración Electrónica entendimos que debíamos ir un paso más allá que sólo construir un conjunto de aplicaciones sobre una determinada arquitectura tecnológica. Observamos que éramos, y somos, un gestor de servicios de información y nuestro modelo de negocio giraba alrededor del concepto de servicio.

En paralelo, habíamos iniciado un camino para adaptar las TIC de la institución con el firme propósito de conseguir que fuesen eficientes, eficaces y capaces de evolucionar con las necesidades de la misma. Definimos un conjunto de principios:

1.Uso de frameworks y estándares en los tres ámbitos.

2. Alinear el Negocio y las TIC.

3. Tecnologías basadas en plataformas, en lugar de aplicaciones.

4. Licenciar las plataformas de Negocio internas (sin necesidad de acceso público) por usuario, y las plataformas de Negocio públicas por servidor.

5. Perseguir la flexibilidad en todos los aspectos.

6. Alcanzar el mayor grado de integración entre las tecnologías y con el Negocio.

7. Buscar la sencillez.

8. Disponer de diseños escalables.

9. Arquitecturas SOA.

10. No externalizar el “core” funcional y tecnológico del OAPGT.

11. Incluir la seguridad como elemento integrado.

12. Hacer que Informática se convierta en un generador de valor para el OAPGT

13. Informática ha de soportar directamente las tareas que añaden valor.

 

Qué aplicaríamos sobre los ámbitos en los que dividimos las TIC:

 

 

De manera que, por una parte, entendimos que debíamos apoyarnos en frameworks y estándares:

 

Siendo los elegidos:

 

Y respecto a las tecnologías, fuimos creando una Arquitectura Empresarial IT, cuyo esquema conceptual es:

 

 

De manera que:

  • Las infraestructuras son “utilities” convertidas en un conjunto de servicios Cloud Computing, incluyendo las licencias.
  • Las plataformas son proporcionadas por grandes multinacionales:
    • Microsoft: SharePoint, Dynamics CRM, Dynamics NAV, Biztalk, .NET, Team Foundation Server, Visual Studio, Exchange, Skype Business
    • Cisco: Toda la parte de seguridad.
    • Manage Engine: las plataformas de atención a usuarios, monitorización, …

Queríamos conseguir que la tecnología dejase de ser un puro coste, con un ciclo diabólico de compra de aplicaciones que tras varios años había que dejar de utilizar y que era muy complicado o imposible de integrar.

Sobre esta AEIT, entendimos que había que crear una capa intermedia que sería la que, aprovechando todas las capacidades funcionales/tecnológicas de los entornos nos permitiese gestionar el ciclo de vida de un servicio. Así, diseñamos nuestro proyecto de Administración Electrónica o Transformación Digital, como la suma de dos proyectos:

 

 

Donde el proyecto de consultoría y organización debía dar a luz un modelo de negocio para la institución basado en la gestión de servicios, junto con el diseño de un catálogo inicial de servicios, mientras que el proyecto de tecnología se ocuparía de crear la capa intermedia que nos permitiese gestionar el ciclo de vida de un servicio:

 

Ambos proyectos fueron liderados por el ámbito TIC, lo que permitió que el modelo de gestión de servicios y las tecnologías nacieran completamente alineadas. Gracias a la capa intermedia, creamos dos entornos:

  • La Sede Electrónica, como un canal de presentación y consumo de los servicios.
  • El entorno de Tramitación Electrónica PROXY, eTramitación PROXY, como el entorno que gestionar el ciclo de vida de los servicios.

La parte más interesante se encuentra en el entorno eTramitación PROXY sobre el que se diseñó y construyó una herramienta de gestión del portfolio de servicios. Dicha herramienta gestiona el ciclo de vida de los servicios. Para cada servicio se articula sobre un conjunto de conceptos:

Las características básicas permiten que el servicio quede correctamente ubicado, definiendo:

  • El nombre del servicio.
  • El ámbito del servicio. Los servicios pueden estar soportados por sistemas de información externos, internos o mixtos. El ámbito del servicio influye tanto en la gestión del ciclo de vida del servicio, como la modelización del servicio y, por supuesto, el aspecto tecnológico.
  • Tipo de servicio. El tipo de servicio define las características específicas. Está condicionado en parte por el ámbito del servicio, ya que lo servicios de ámbito externo, en principio no requieren desarrollo/soporte alguno, sólo la inclusión en el catálogo de servicios. El momento del consumo de dicho servicio, nos llevaría al entorno de la entidad que realmente soporta dicho servicio, como por ejemplo la consulta de cartografía de la Oficina Virtual de Catastro. Inicialmente tenemos los siguientes tipos de servicio:
    • De presentación: son servicios que se utilizan para agrupar su presentación y facilitar su consumo, como, por ejemplo, Cita Previa que sería un servicio de presentación que agruparía servicios de consulta y que generan trámite:
      • Solicitud de Cita
      • Consulta de Cita
      • Modificación de Cita
      • Eliminación de Cita
    • Externos: son aquellos servicios que están soportados por sistemas de información externos, de los que sólo necesitamos tener la información visible y el enlace al mismo.
    • Consulta: son servicios que desde la perspectiva de los “clientes” permiten exclusivamente la consulta de información. Por ejemplo, el calendario tributario o las competencias delegadas son servicios de consulta.
    • Gestionan Expediente: son aquellos servicios cuyo consumo genera expediente electrónico. Por ejemplo, una solicitud de fraccionamiento.
    • Gestionan Trámite: son aquellos servicios cuyo consumo genera un trámite. Por ejemplo, las consultas realizadas por los ciudadanos a través de los diferentes entornos web: Sede Electrónica, Web Corporativa, Portal de Transparencia,
    • Gestionan Actuaciones: son aquellos servicios cuyo consumo provocan una acción atómica, como, por ejemplo, el adjuntado de documentación.
    • Ad-Hoc: son servicios que necesitan de un desarrollo funcional a medida. Por ejemplo, el servicio de cita previa o el pago con tarjeta.
  • Canal de consumo. Determina el entorno tecnológico que será utilizado para publicar el servicio y su posterior consumo. Un servicio podrá estar asociado a uno o varios canales. El canal de consumo se encuentra condicionado por el ámbito del servicio y el tipo del servicio:
    • Si el ámbito del servicio es externo, el canal de consumo será telemático. Sin embargo, los servicios cuyo ámbito sea interno o mixto, estarán asociados a cualquiera de los canales definidos.
    • El tipo de servicio delimita en cierta medida los canales de consumo. Por ejemplo, el calendario tributario es un servicio de consulta que no estaría disponible por el canal Presencial.
  • Las opciones actualmente disponibles son:
    • eAdmin
    • Web
    • Presencial
    • Teléfono
    • APP
  • · Métodos de consumo. Nos indica qué modelo de autenticación/identificación es necesario para consumir el servicio. Los métodos de consumo están condicionados por
    • El ámbito del servicio. Un servicio externo, por ejemplo, no requerirá autenticación/identificación.
    • El tipo del servicio. Los servicios externos o servicios de consulta generalmente serán servicios cuyo modelo de autenticación/identificación será público o anónimo. Sin embargo, los servicios que generan expediente requerirán métodos de consumo más fuertes o seguros, como por ejemplo Certificado Electrónico, DNIe o PIN24.
    • El canal de consumo. Hay servicios que pueden ser consumidos por diferentes canales. Cada canal puede tener unas características técnicas y/o restricciones que obliguen a utilizar diferentes métodos de consumo.
    • Los métodos de consumo identificados inicialmente son:
    • Público: se aplica cuando el servicio puede ser consumido por cualquier usuario, sin necesidad de autenticación/identificación.
    • DNIe-Certificado Electrónico: se aplicará a aquellos servicios que requieren de una interactividad que debe seguir las características jurídicas marcadas por la legislación de administración electrónica. Por ejemplo, los servicios que generan expediente.
    • Usuario/Contraseña: es un método alternativo, compatible, para aquellos servicios cuyo método de consumo sea DNIe-Certificado Electrónico, de manera que se facilite el acceso a los mismos. Requerirá el alta del ciudadano, ayuntamiento, …
    • PIN24: es otro método alternativo que facilitará el consumo de los servicios. Este método permitirá que se genere un código que el ciudadano, ayuntamiento, … podrá utilizar durante un período limitado y estará vinculado al consumo de un servicio en una única ocasión. Es decir, la siguiente ocasión que desee consumir el consumo se generará un nuevo código.
  • Perfiles de usuario: Los perfiles nos permiten definir roles de seguridad en la gestión de los servicios de manera que se hace mucho más sencilla la gestión de la seguridad. Los perfiles de usuario definen agrupan conjuntos de funciones y/o servicios que pueden ser consumidos. Están fuertemente relacionados con los grupos de usuario.
  • Servicio del OAPGT Responsable: Cada uno de los servicios del catálogo de servicios del OAPGT está vinculado con una de las áreas o servicios de la institución, que es el responsable último de los diferentes aspectos (diseño, calidad, ...) del servicio y la gestión del ciclo de vida asociado al mismo.

Los perfiles de usuario aplican sobre los usuarios denominados externos: ciudadanos, Ayuntamientos, ... y los usuarios internos.

Siendo posible la gestión de varios tipos de servicio, pero bajo un mismo marco o framework, con una estandarización y una gestión digital. Todo pivotando alrededor del portfolio de servicios.

Diseñamos cómo debían ser los diversos tipos de servicio en detalle, por ejemplo, los servicios que generan eExpedientes:

 

El consumo del servicio por parte de cualquier usuario perteneciente a los diferentes grupos de interés identificados es “instanciado” generando un expediente electrónico. Cada servicio que genera expediente es un tipo de servicio que tiene un elevado grado de interactividad, gestionado a través del expediente creado y los conceptos relacionados dan completitud a todo el proceso.

La interactividad del servicio está representada/gestionada por:

  • Las fases por las que pasa el proceso de consumo del servicio. Cada fase representa cada una de las etapas que debemos cubrir para completar el consumo del servicio.
  • Las interacciones que se pueden ejecutar. Una interacción representa una acción o conjunto de acciones, existiendo dos tipos de interacciones:
  • Interacciones oficiales: denominadas actuaciones. Son las acciones que están marcadas por la legislación y deben cumplir todos los requisitos jurídico/tecnológicos definidos en la legislación aplicable en la Administración Electrónica. 

Las actuaciones pueden ser sencillas o complejas, en función del flujo de trabajo que requieran.

  • Interacciones oficiosas: existen un conjunto de acciones que pueden ejecutarse en la gestión de un servicio que no están contempladas por la legislación existente, pero que deben quedar registradas en la vida del servicio. Estas interacciones son:
    • Agregar Notas.
    • Enviar Correo Electrónico.
    • Realizar/Recibir llamadas de teléfono.
    • Enviar Fax.
    • Enviar Cartas.
    • Crear Citas.
    • Agregar Tareas.
  • Los formularios utilizados para ejecutar cada una de las interacciones. Aquellas interacciones complejas que requieran de un flujo de trabajo con varios pasos, utilizarán un formulario para cada paso.
  • Las notificaciones electrónicas generadas como consecuencia de la ejecución de las interacciones oficiales. Cada interacción oficial, por ejemplo una resolución de cierre de un expediente, generará una notificación electrónica.
  • Los documentos electrónicos que se crean como consecuencia de cada interacción o de la gestión de las notificaciones electrónicas.
  • Las comunicaciones que se generan como consecuencia de las notificaciones electrónicas. Las comunicaciones son una forma de aviso a los usuarios de la necesidad de revisar algún aspecto del servicio.

Por otra parte, los expedientes pueden ser clasificados con una estructura en dos niveles:

  • Tipo de expediente
  • Subtipo de expediente

Esta estructura, además, facilita la coherencia e integración con la modelización del Sistema de Información Tributario.

La clasificación está estrechamente relacionada y condicionada por el servicio que se consume. Por ejemplo, un servicio del área de Recursos Humanos no tendrá como tipo de expediente “Fraccionamiento”.

Haciendo que, los servicios del portfolio pudiesen ser consumidos tanto desde entorno web, como por interfaz SOA (Web Service). Estábamos intentando diseñar una arquitectura SOA, aplicando conceptos de reutilización y buscando la mayor flexibilidad posible, apoyándonos en tecnologías que entendemos no será necesario tirar en unos años y que se podrán seguir

utilizando. Es más, evolucionarán con la institución, creando un entorno estable sobre el que diseñar y construir los servicios de negocio de la organización.

Algunas características que creo son destacables del ecosistema de Administración Electrónica diseñado:

  • Su proactividad. El sistema “persigue” a los tramitadores/gestores de los servicios.
  • Su capacidad de adaptación. Hemos testado el modelo conceptual con servicios de diferentes instituciones o empresas.
  • Su capacidad tecnológica.
  • Su arquitectura SOA.
  • No sólo ayuda a normalizar/estandarizar la gestión de los servicios, sino que también es capaz de canalizar la gestión del trabajo.
  • Su capacidad para gestionar SLAs por servicio.
  • La capacidad de gestionar una relación personalizada, per-to-per, del entorno, teniendo en cuenta aspectos como la gestión de la relación con el administrado (mails, llamadas, …) de forma integrada en el servicio.
  • Su flexibilidad. Podemos añadir nuevos canales de consumo de servicio con facilidad, añadir nuevos grupos de interés con sencillez, etc.

De esta forma, entorno al concepto de servicio y el modelo de gestión de servicios, hemos construido todo un ecosistema al que se le pueden ir añadiendo cualquiera de los sistemas de información que hemos visto al principio, con relativa facilidad.

 

___________________________

Para aquellos que deseen conocer más sobre lo que estamos haciendo las Administraciones Públicas, les invito a acceder al Portal de Administración Electrónica (PA):

https://administracionelectronica.gob.es/

 

Victoriano Fernández

Castellano-manchego formado en el sistema público, que ha desarrollado su vida profesional en compañías de sector muy diferente y de tamaño muy diverso. Ha trabajado en el sector privado y el sector público. Persona joven y con experiencia, apasionado de su profesión, con mucha ilusión por continuar aprendiendo y mejorando. Toledo, España

 



Comentar
Para comentar, es necesario iniciar sesión
Se muestran 0 comentarios