Agencia de Gobierno Electrónico y Sociedad de la Información y del Conocimiento

Aspectos del negocio a tener en cuenta para el diseño y la definición de la Arquitectura de Procesos

En esta sección se analizarán los aspectos fundamentales a tener en cuenta de ese conjunto de trámites y servicios que componen el Servicio Hiperconectado y de las posibles formas que existen de que se vinculen entre sí.

En las secciones anteriores se realizó un análisis sobre el supuesto de que el Servicio Hiperconectado es un conjunto de trámites que tienen secuencialidad obligatoria desde el inicio hasta el final, es decir a lo largo de todos los trámites requeridos en cada uno de los organismos intervinientes.

Sin embargo, esto puede no ser exactamente así en todos los casos, y es por ello que analizaremos en esta sección los aspectos del negocio que influyen en la definición de la arquitectura de procesos y en el diseño de los mismos.

Los aspectos de negocio que influyen en el diseño son:

1. Duplicidad de trámites y datos

2. Tipo de conectividad entre trámites (Secuencialidad VS Dependencia Existencial)

3. Determinación y alcance

4. Perfiles de la persona

5. Órbita de cada organismo

6. Gobernanza de los Datos

7. Sostenibilidad y Sustentabilidad

8. Soporte y Mantenimiento

Duplicidad de trámites y datos

El primer aspecto a analizar del conjunto de trámites que componen el Servicio Hiperconectado es la duplicidad que exista entre ellos. Es común encontrar trámites definidos en distintos organismos que solicitan la misma información a la persona en distintos momentos. Esto tiene que ver directamente con uno de los principales objetivos de la implantación de un Servicio Hiperconectado: los datos suministrados por la persona durante la ejecución del servicio deben solicitarse una única vez.

Por lo general lo que se encuentra duplicado entre organismos no es un trámite “tal cual” sino trámites “similares” que con nombre y apariencia distinta (o similar) terminan solicitando exactamente la misma información a la persona para guardar en Entidades de Negocio muy similares entre sí, cada organismo en sus propios repositorios de datos.

Esto no solo constituye un servicio de baja calidad hacia la persona que debe reingresar la misma información en distintos lados, sino que genera datos duplicados y desincronizados en los distintos organismos del Estado.

Si dos o más procesos (trámites) de un mismo Servicio Hiperconectado solicitan la misma información (el mismo dato) entonces se debe mantener la solicitud de dicha información en el primer proceso que la solicite y eliminar la solicitud del dato duplicado de los posteriores procesos (trámites) que también la soliciten. Entendiéndose por “primer” proceso y “posteriores procesos” el orden lógico en que se suceden en el Servicio Hiperconectado.

Cuando se identifiquen trámites y datos duplicados dentro de un Servicio Hiperconectado se deben hacer las siguientes acciones a nivel de diseño:

1. Eliminar toda solicitud de un dato posterior a la primera solicitud. Esto puede significar eliminar partes parciales de un trámite (subprocesos) o la totalidad de un trámite. Ello dependerá de cada caso de negocio y cada Servicio Hiperconectado.

2. Asegurar a nivel del diseño del proceso del primer trámite (en el que se mantiene la solicitud del dato) que el dato (ahora solicitado una sola vez) se “comparta” con los organismos de los procesos posteriores que ya no lo solicitan

El mecanismo por el cual se “comparta” el dato dependerá de factores técnicos, económicos o normativos pudiendo ser algunas de las opciones:

• Mantener un único repositorio del dato dando acceso remoto al resto de los organismos
• Duplicar el dato (redundancia) entre los organismos que lo requieren, ya sea por replicación a nivel de bases de datos, ya sea por envío operativo del dato a nivel del primer proceso que lo solicita.

Tipo de conectividad entre trámites

El segundo aspecto del negocio fundamental para tener en cuenta al momento de evaluar la definición de una arquitectura de procesos y la elaboración del Modelo BPMN, es que tipo de conectividad existe entre los trámites (ya no duplicados).

Existen dos tipos de conectividad entre trámites de un Servicio Hiperconectado:

1. Conectividad fuerte: que llamaremos Secuencialidad

2. Conectividad débil: que llamaremos Dependencia Existencial

Conectividad fuerte: Procesos secuenciales

Por definición, dos procesos (o trámites), que llamaremos A y B, son secuenciales (tienen conectividad fuerte) cuando sucede una de las siguientes posibilidades:

1. El proceso A invoca al proceso B (B es subproceso de A)

2. El proceso A dispara (trigger) el proceso B

Como se ve en los dos casos anteriores, la secuencialidad entre dos procesos implica la “continuidad obligatoria” desde el proceso A hacia el proceso B, ya sea en la misma instancia de proceso (si B es invocado) o con una nueva instancia de proceso (si B es disparado).

Expresado en lenguaje no técnico, significa que el proceso B si o si debe proseguir inmediatamente después del A para que el objetivo del negocio se complete.

Ello significa que el proceso A no tiene un objetivo por sí mismo y nunca se ejecuta de forma independiente del proceso B. Exactamente lo mismo sucede con el proceso B respecto del proceso A.

Conectividad débil: Procesos con Dependencia Existencial

Un proceso (o trámite) B tiene dependencia existencial respecto de un proceso (o trámite) A cuándo se cumple lo siguiente:

1. El proceso B para poder ejecutarse necesita datos previamente generados por el proceso A

La dependencia existencial implica que el proceso B depende de que haya existido previamente al menos una instancia del proceso A que se haya ejecutado y haya generado datos que son insumos del proceso B.

Ambos procesos son independientes y cada uno tiene objetivos propios y no existe secuencialidad obligatoria entre los mismos, ya que el proceso B puede ejecutarse mucho tiempo después de haber terminado el proceso A, o inclusive no ejecutarse nunca. Los datos generados por el proceso A pueden ser un producto en sí mismo y/o ser insumos de otros procesos distintos del B.

Los trámites que integran un Servicio Hiperconectado pueden tener conectividad fuerte o débil entre sí y ello condiciona la arquitectura de procesos a seleccionar.

Los trámites con conectividad fuerte entre ellos son candidatos a ser modelados como procesos del nivel 1 de la arquitectura centralizada, mientras que trámites que no tienen conectividad fuerte con otros trámites del Servicio Hiperconectado, pueden ser modelados en el nivel 2.

Diferencia entre conectividad débil e interoperabilidad.

Es importante aclarar que la conectividad débil (o dependencia existencial) entre procesos NO es lo mismo que la interoperabilidad entre procesos.

La interoperabilidad es un concepto “más débil aún” que la conectividad débil. Cuando un sistema interopera con otro para enviarle o solicitarle determinados datos no significa necesariamente que la continuidad del primero está condicionada a los datos que recibe del segundo.

Por ejemplo, si un proceso interactúa con la DGI para consultar si un número de CI tiene RUT asociado, la respuesta podrá ser el RUT o vacío, y en cualquiera de los dos casos el proceso solicitante de los datos continuará. Es decir, no es condición necesaria que la CI tenga asociado un RUT, simplemente se consulta para ver si lo tiene y guardar el dato.

Si en el mismo ejemplo anterior, el proceso solamente pudiera continuar cuando efectivamente existe un RUT, entonces solo en ese caso existe dependencia existencial (conectividad débil) del proceso de registro de RUT en DGI al proceso consultante.

Puede decirse que la conectividad débil (dependencia existencial) es equivalente a la interoperabilidad bloqueante, pero no a la interoperabilidad a secas.

Determinación y alcance de un Servicio Hiperconectado

La conectividad fuerte entre dos procesos (de un mismo o diferentes organismos) es condición SUFICIENTE para que formen parte de un mismo Servicio Hiperconectado.

La conectividad débil entre dos procesos (de un mismo o diferentes organismos) NO es condición SUFICIENTE para que formen parte de un mismo Servicio Hiperconectado.

Un SSHH estará compuesto por los procesos con conectividad fuerte que se identifiquen más lo procesos de conectividad débil que se identifiquen y que por definición de alcance del negocio se decidan incluir.

Perfiles de la persona que ejecutan el Servicio Hiperconectado

En las secciones anteriores se realizó un análisis sobre el supuesto de que el Servicio Hiperconectado es utilizado por un único perfil de la persona que es la interesada en obtener el producto o servicio final de ese trámite global que es el Servicio Hiperconectado. Es decir, una persona (que podrá ser persona física o jurídica) que ejecuta de punta a punta el Servicio Hiperconectado.

Sin embargo, esto puede no ser exactamente así en todos los casos. Existirán casos en los cuales el Servicio Hiperconectado es ejecutado por varios perfiles distintos que ejecutan el o los subprocesos que necesitan según sus necesidades y de acuerdo a las siguientes premisas:

- Todos los procesos que tengan conectividad fuerte (secuencialidad obligatoria) dentro de un Servicio Hiperconectado serán ejecutados por un único perfil de persona

- Los procesos que tengan conectividad débil dentro de un Servicio Hiperconectado podrán ser ejecutados por perfiles distintos de persona.

Para ejemplificar lo anterior, presentamos el siguiente caso:

El organismo O1 registra a Técnicos Autorizados mediante el proceso (trámite) P1. Esto genera una lista de Técnicos Autorizados que queda disponible a la persona por si alguien lo necesita para cualquier otro trámite.

Luego el organismo O2 tiene un proceso (trámite) de registro de equipos importados a través del proceso P2. En el proceso P2 es necesario declarar un Técnico Autorizado que se haga cargo técnicamente del equipo importado.

En este ejemplo tenemos 2 procesos con conectividad débil que forman parte del Servicio Hiperconectado “Equipos Importados”. La persona que ejecuta el proceso P1 es un perfil Técnico y la persona que ejecuta el proceso P2 es un perfil Comercial y puede que ni siquiera se conozcan previamente.

El SSHH integra la necesidad de un Técnico Autorizado y un Equipo Importado, pero ambos subprocesos son ejecutados por personas distintas. Si bien el proceso P1 tiene su propio objetivo independiente que es “figurar en lista de Técnicos Autorizados” el objetivo final del mismo se cumple recién cuando lo contratan para hacerse cargo de un equipo en P2 de Equipos Importados.

Órbita de los trámites

Cuando un trámite T puede ser ejecutado completamente por personas de un solo organismo O y dicho trámite no tiene conectividad fuerte con trámites de otros organismos, entonces el trámite T es de la órbita del organismo O.

Por el contrario, si un trámite T1 del organismo O1 tiene conectividad fuerte con un trámite T2 del organismo O2, entonces existe (y debe modelarse) un nuevo trámite T1-2 que integra a T1 y T2 y es de la órbita COMPARTIDA de O1 y O2.

Cuando un trámite es de la órbita compartida de dos (o más) organismos, significa que en cada instancia del proceso de ese trámite actúan personas de distintos organismos.

La órbita de un trámite refiere a cuál o cuáles son los organismos responsables de la ejecución del proceso, pero no refiere a la gobernanza y los permisos de acceso a los datos generados por dicho proceso.

Gobernanza de datos

La gobernanza del Servicio Hiperconectado tiene un cometido fundamental y debe ser definida antes de la implementación, ya que definirá quien es el dueño de la cadena de servicios. Además de definir donde comienza el servicio, debe definir las fronteras del negocio entre los diferentes actores y los puntos de contacto entre estos, así como también la información que tienen en común y su origen (tomar en cuenta que los datos deben ser ingresados una sola vez en todo el ecosistema del Servicio Hiperconectado).

También es importante definir los procedimientos de administración y mantenimiento de los servicios a exponer en el Servicio Hiperconectado, de forma que no afecte a todas las personas implicadas ante mantenimientos o cambios en las reglas del negocio de una o más partes del proceso.

La gobernanza de los datos generados por los trámites de un Servicio Hiperconectado refiere a los aspectos del negocio que definen:

1. Qué organismo/s es/son dueño/s de los datos

2. Qué organismo/s tiene/n acceso a los datos

3. Cómo es el repositorio de los datos (replicación)

4. Cómo es el Hosting de los datos

Sostenibilidad y Sustentabilidad

Los Servicios Hiperconectados, como todo producto de software, no son productos estáticos, ya que deben acompañar en el tiempo la evolución de los sistemas que lo sustentan (software de base), así como también la propia evolución y dinámica del negocio al que soportan.

Es muy importante a partir de la gobernanza definida, la sostenibilidad en el tiempo de los servicios, para que estos se adecúen a la evolución tecnológica y a los cambios del negocio, por lo que se debe tener en consideración el impacto que pueda haber al actualizar/modificar/eliminar cualquiera de los servicios afectados a un Servicio Hiperconectado y quienes son los responsables.

La evolución de un proceso debería ser transparente a la conexión en un Servicio Hiperconectado. En caso de no serlo, es necesario evaluar si el Servicio Hiperconectado tiene que ser reformulado para mantener su sostenibilidad.

La sustentabilidad de los Servicio Hiperconectado va muy de la mano de la definición de la gobernanza en cuanto a quien es responsable de su ejecución y a como se implementa el servicio, bien sea en una implementación centralizada o distribuida. Pero en el concepto, las consideraciones a tener en cuenta para la sustentabilidad se basan en los procedimientos de soporte y mantenimiento.

Soporte y Mantenimiento

Al ser un Servicio Hiperconectado un producto que puede involucrar a diferentes organismos, Unidades Ejecutoras con diversidad de ecosistemas vinculados, se deben definir las fronteras que separan las responsabilidades y capacidades para el soporte.

Se sugiere centrarse en:

FrontOffice: Es todo lo concerniente a la interface de usuario del Servicio Hiperconectado con la persona

BackOffice: Es todo lo concerniente a la interface de usuario del Servicio Hiperconectado con el funcionario

MiddleOffice: Es todo lo concerniente a las integraciones existentes dentro del Servicio Hiperconectado y que además se pueden separar entre:

- Integración interna al organismo, conectividad entre servicios internos

- Integración externa entre servicios de diferentes organismos.

El modelo de soporte estará muy ligado al tipo de implementación del Servicio Hiperconectado en cuanto a si es distribuido o centralizado. Debe analizarse si el soporte debe ser centralizado y luego derivado al organismo responsable, o si debería existir un sistema de ticket para derivar las peticiones según corresponda. 

En cuanto al mantenimiento del Servicio Hiperconectado, se deberán definir reglas y procedimientos referidas a la actualización, manutención de infra, administración de los servicios y su grado de afectación en el Servicio Hiperconectado, así como también los planes de contingencia contra fallos (workaround, procedimientos de rollback, respaldos, ventanas de actualización), ambientes de Testing, Pre Producción y Producción, etc.

Organismos dueños y con acceso a los Datos (nivel lógico)

Para explicar el significado y la forma de analizar y diseñar según los 2 primeros puntos anteriores, comenzaremos por describir las Características de la Información (datos) de un Servicio Hiperconectado.

Toda la información (datos) recabada y gestionada en un Servicio Hiperconectado tiene las siguientes características:

1. El proceso a través del cual se obtiene (alta) el dato

2. El proceso a través del cuál se mantiene (modifica o baja) el dato

3. El organismo dueño del dato

4. Los organismos con acceso (consulta) al dato

Se ilustra lo anterior con la siguiente tabla de ejemplo:

Proceso de Alta de un dato

Es el proceso (trámite) mediante el cuál se solicita el dato por primera y única vez a la persona, de acuerdo con el objetivo del Servicio Hiperconectado. Este proceso puede ser de la órbita de cualquiera de los organismos del Servicio Hiperconectado independientemente de quién es el dueño del dato y quienes tienen acceso al mismo.

Proceso de MyB del dato (mantenimiento)

Es el proceso mediante el cuál se gestiona el mantenimiento del dato, tanto sus modificaciones posteriores al alta como su baja. El proceso de MyB del dato podrá, en algún caso particular, ser el mismo que el ¨Proceso de Alta, si las características del negocio así lo requirieran, pero por regla general se analiza como proceso aparte.

Organismo Dueño del Dato

El organismo dueño del dato es aquél a partir de la competencia del cual el dato es solicitado a la persona. Es decir, si un dato es requerido por un organismo por ser necesario para el trámite según la normativa y/o competencia del organismo, entonces ese organismo es dueño del dato. Cuando un organismo es dueño de un dato es responsable por su mantenimiento, por lo tanto, el Proceso de MyB de ese dato debe estar en la órbita de dicho organismo. Sin embargo, cuando un organismo es dueño de un dato, el Proceso de Alta del dato puede estar en la órbita de otro organismo y ser transferido del segundo al primero ni bien es obtenido de parte de la persona.

Organismo con acceso al Dato

Existen datos que, si bien son requeridos por la competencia o normativa de un organismo para un trámite, es sabido y reconocido por el organismo que dicho dato ya lo tiene otro organismo y, por lo tanto, para obtenerlo se lo solicita al organismo que ya lo tiene. Es decir, normativamente el organismo A tiene derecho al acceso a ese dato que tiene el organismo B, que a su vez lo solicitó en algún momento a la persona o lo obtuvo como resultado de sus propios procesos y/o aprobaciones internas.

Repositorio y Hosting de los Datos (nivel físico)

Una vez identificados (y definidos) los procesos que lo generan, los procesos que lo modifican, el dueño y quienes tienen acceso al Dato, se debe definir el repositorio del mismo. Específicamente lo que interesa a nivel del diseño de los procesos es si el Dato va a estar centralizado o distribuido (replicado). Por ejemplo, si la dirección del proveedor va a estar en:

Opción 1: solamente en una Base de Datos del Ministerio A (dueño del dato) con acceso remoto otorgado al Ministerio B (con acceso) en esa base.

Opción 2: en la Base de Datos del Ministerio A y replicada a una Base de Datos del Ministerio B

Si bien a priori la definición más óptima desde el punto de vista técnico pudiera ser la opción 1,  también es cierto que pueden existir diversas variables del negocio, incluyendo políticas y normativas de los organismos, que hagan imposible esta opción y se deba optar por la opción 2 con los datos distribuidos y replicados.

La definición de un repositorio centralizado o distribuido para un Dato puede tener implicancias en los modelos de los procesos. Esto se explica sobre la base de que, si un Dato está distribuido entre distintos organismos, es muy probable que no existan (y sean muy difíciles de implementar) mecanismos automáticos de replicación entre las bases heterogéneas de los organismos, y por ello pueda llegar a ser necesario el envío y recepción de dichos datos como actividades específicas de los procesos.

Finalmente debe definirse el hosting de los datos, es decir, el lugar físico de almacenamiento de las bases de datos definidas siendo ya ese tema parte de la arquitectura física a la que se hace referencia en secciones anteriores.

Mapa de Procesos

El nivel más alto de especificación del Servicio Hiperconectado es el Mapa de Procesos dónde debe especificarse y visualizarse con claridad estos 3 aspectos fundamentales del diseño del Servicio Hiperconectado:

1. Tipo de conectividad de trámites (Secuencialidad VS Dependencia Existencial)

2. Órbita de cada Organismo

3. Gobernanza de los Datos

Que determinan y condicionan el resto del diseño Top-Down de los Modelos BPMN de cada proceso y subproceso componente del Servicio Hiperconectado global. Para un mismo Servicio Hiperconectado se pueden tener distintas combinaciones de las opciones que presenta cada uno de los puntos Conectividad, Órbita y Gobernanza de Datos, coexistiendo en una misma arquitectura lógica.

Este Diseño de alto nivel especificado en el Mapa de Procesos es el primer entendimiento y nivel de acuerdo que se debe lograr con (y entre) los Organismos que intervienen en el Servicio Hiperconectado.

Ejemplo de Mapa de Procesos:

• El SSHH da un servicio global integrado a 3 perfiles interesados: Per1, Per2 y Per3
• El proceso P1 es ejecutado por Per1 o Per2
• El proceso P2 es ejecutado por Per3
• El proceso P3 es ejecutado por Per1
• El proceso P4 es ejecutado por Per2
• El proceso P1 “dispara” (por secuencialidad) el proceso P2 teniendo, por lo tanto, conectividad fuerte y ambos están en la órbita del organismo O1.
• Los datos generados en el proceso P1 son impactados en el repositorio R1 del organismo O1 y por gobernanza de datos, son replicados al repositorio R2 del organismo O2
• Los datos generados por P2 son impactados en el repositorio R3 en la órbita del organismo O1
• El proceso P3 tiene conectividad débil con el proceso P2 ya que utiliza como insumos requeridos los datos del repositorio R3
• El proceso P3 impacta sus datos en el repositorio R4
• El proceso P4 tiene conectividad débil con el proceso P3 y con el proceso P2 ya que utiliza como insumos requeridos los datos del repositorio R4 y R3
• Los datos generados en el proceso P4 son impactados en el repositorio R5 de la órbita compartida de los organismos O1 y O2 y por gobernanza de datos, son replicados al repositorio R6 del organismo O2 y R7 del organismo O1

Si bien el Mapa de Procesos más importante para el diseño de alto nivel del Servicio Hiperconectado es el TO-BE, es recomendable también especificar el AS-IS, de manera tal que se pueda ver claramente los procesos depurados e integrados.

Modelo AS-IS: Modelo del proceso que especifica el comportamiento actual del proceso y/o del sistema que lo implementa.

Modelo TO-BE: Modelo del proceso que especifica el comportamiento deseado del proceso tal y como se entiende que contempla las necesidades actuales del negocio