Historial de página

[ACT-PRE-FUNC-3.3] Preparar otros procesos de Autentificación

De igual forma que para aplicaciones que gestionen sus usuarios y perfiles a través de MACO es necesario preparar los procesos de autentificación y la carga de usuarios en sistemas en lo que la autentifican se lleva a cabo a través de otros mecanismos de autentificación, como pueden ser certificados digitales, dni electrónico, etc.

Es necesario verificar de forma previa al arranque durante la fase de preimplantación que todos los usuarios que vayan a utilizar estos sistemas de autentificación dispongan de los elementos necesarios y tengan asociado el rol/perfil correspondiente.

[ACT-PRE-FUNC-4] Preparar dependencias en módulos centralizados

Matriz RASCI

Dependencias

Catálogo de entregables

[ACT-PRE-FUNC-4] Preparar dependencias en módulos centralizados

Otro de los procesos que mayor dedicación Otro de los procesos que mayor dedicación necesitan por parte del centro para La preparación del comienzo de la implantación es la configuración y adecuación de todos los módulos corporativos centralizaos relacionados directa o indirectamente con el proyecto.

Son Módulos Centralizados por ejemplo: Citaweb, MPA, APD, PDI, BDU, AGD, ETC

El conjunto de sistemas, la forma y el grado en la que estos serán afectados dependerá específicamente de cada proceso de implantación y debe ser especializado en cada Modelo Corporativo de Implantaciones MCI que se defina sobre el marco del MCMI. A pesar de ello, el objetivo final sobre todos ellos son los mismos:

• Configurar cada uno de los módulos con la información necesaria para su interacción con el nuevo sistema a implantar. Ejemplos:
  • AGD > inclusión de códigos de procedimientos que falten.
  • AGD > inclusión de todas las intervenciones a futuro que estén registradas en otros sistemas de gestión.
  • Citaweb > inclusión de todas las citas a futuro que estén registradas en otros sistemas de gestión.
  • Citaweb > marcado de las agendas para petición o no de historia clínica.
  • MPA > definir catálogo de la cartera de servicios para el centro
• Parametrización de cada uno de los sistemas corporativos centralizados para que funcionen conforme a la definición de los circuitos.
  • OJO: en fase de preimplantación solo modificaremos la parametrización de los entornos preproductivos para no afectar a producción.
  • El entorno de producción solo será configurado si existen garantías de que no afectarán al funcionamiento normal de los usuarios.
  • En caso contrario se analizarán los cambios necesarios en este momento y se recogerán las actuaciones a realizar en el “GEST15. Plan de arranque” que definiremos para la ejecución de la “Fase 5. ARR”.
  • Ejemplos:
    • Citaweb > configuración de parámetros para trabajar en nuevos circuitos, como por ejemplo los circuitos de especializada.
    • CAE > configuración de puertas de urgencia para su integración con DAH y que se emita mensajería.
• En preproducción, introducción de un pool de datos de muestra suficientemente amplio como para que permita la ejecución de todas las actividades de la fase 4 de implantación enfocadas a preparar el cambio. Ejemplos:
  • Citaweb > creación de agendas de prueba con citas suficientes de cada tipología.
  • AGD > creación de entradas de prueba.
  • MPA > creación y parametrización de circuitos de prueba, peticiones, etc.
  • PDI > creación de agendas de prueba, citas y resultados.
  • Etc.

Es importante reseñar que esta configuración deberá llevarse a cabo en:

• Los entornos preproductivos (FOR, VAL, PRE) > para poder llevar a cabo correctamente:
  • Las sesiones de formación y transferencia del conocimiento a usuarios finales.
  • Las pruebas de integración con sistemas terceros en el nuevo escenario.
  • La validación de los procesos de migración de datos.
• El entorno de producción > para permitir el funcionamiento correcto del nuevo sistema tras el arranque.

Matriz RASCI

Catálogo de entregables

[ACT-PRE-FUNC-5] Parametrización

En el conjunto de actividades englobadas dentro de este apartado llevaremos a cabo una serie de acciones encaminadas a completar la definición de la parametrización del sistema a implantar.

[ACT-PRE-FUNC-5.1] Definir

[ACT-PRE-FUNC-5] Parametrización

En el conjunto de actividades englobadas dentro de este apartado llevaremos a cabo una serie de acciones encaminadas a completar la definición de la parametrización del sistema a implantar.

[ACT-PRE-FUNC-5.1] Definir parametrización del sistema a implantar

En la fase de Reingeniería de procesos, durante las sesiones de reingeniería se habrá comenzado a reflejar los valores de los parámetros y tablas maestras que se hayan acordado durante dichas sesiones.

En previsión de que existan parámetros o valores de tablas maestras que, bien por falta de tiempo o bien por necesidad de escalar la decisión sobre sus valores a otro ámbito, no hayan podido ser acordados durante la sesión (y recogido en las plantillas de parametrización), antes de finalizar dicha fase, estas plantillas han de ser facilitadas al centro para que sean finalizadas (proceso “[P-RP-FUNC-9] Entregar plantillas de parametrización”).

La finalización de la recogida de información en estas plantillas para la definición de la parametrización debe ser llevada a cabo como decimos por el centro con el apoyo consultivo  de SSCC y equipo de implantación.

Esta parametrización dará como resultado una serie de documentos que definirán los valores de los parámetros cuya potestad de decisión están en el centro, y la definición de los valores de una serie de tablas maestras parametrizables.

Dependencias

[ACT-PRE-FUNC-5.2] Verificar que los valores definidos corporativamente son respetados

Una vez hemos definido la parametrización del sistema en el proceso “[ACT-PRE-FUNC-5.1] Definir parametrización del sistema a implantar”, y hemos recogido el resultado en el entregable “FUNC11. Parametrización del.

Matriz RASCI

Dependencias

Catálogo de entregables

[ACT-PRE-FUNC-5.3] Definir mapeos de tablas maestras

En relación a los valores de tablas maestras, son de aplicación los valores incluidos en el nuevo sistema, que a su vez hace uso de tablas de valores y aplicaciones centralizadas, utilizando un conjunto de datos maestros tipo.

Para los procesos de migración de datos de un sistema origen diferente hacia un sistema del SAS, es necesario un mapeo de determinados valores maestros.

Ídem ocurre para la implementación de procesos de integración entre sistemas del SAS y sistemas terceros. En este caso, los valores a utilizar en la integración son igualmente los definidos en el sistema del SAS.

Es necesario por tanto en muchos casos un proceso de mapeo entre los valores de los parámetros y las tablas maestras del sistema origen y los del nuevo sistema a implantar. De este proceso obtendremos como salida el entregable “FUNC12. Mapeos de tablas maestras”.

Con respecto a la definición de los mapeos es importante tener en

En relación a los valores de tablas maestras, son de aplicación los valores incluidos en el nuevo sistema, que a su vez hace uso de tablas de valores y aplicaciones centralizadas, utilizando un conjunto de datos maestros tipo.

Para los procesos de migración de datos de un sistema origen diferente hacia un sistema del SAS, es necesario un mapeo de determinados valores maestros.

Ídem ocurre para la implementación de procesos de integración entre sistemas del SAS y sistemas terceros. En este caso, los valores a utilizar en la integración son igualmente los definidos en el sistema del SAS.

Es necesario por tanto en muchos casos un proceso de mapeo entre los valores de los parámetros y las tablas maestras del sistema origen y los del nuevo sistema a implantar. De este proceso obtendremos como salida el entregable “FUNC12. Mapeos de tablas maestras”.

Con respecto a la definición de los mapeos es importante tener en cuenta la casuística relacionada con los mapeos con cardinalidad N..1, 1..N y N..N

En todo caso un mapeo ha de ser unívoco, por lo que cada valor de origen ha de ser mapeado a uno y solo un valor de destino. Esto nos permitirá automatizar los procesos de migración e integración de datos.

OJO: es diferente el mapeo que se utilizará para las migraciones y las integraciones en sentido SISTEMA_ORIGINAL > NUEVO_SISTEMA, que el mapeo que se utilizará las integraciones en sentido NUEVO_SISTEMA > SISTEMA_ORIGINAL.

Tendremos así dos mapeos:

• Flujo de información A. Mapeo para el flujo de información con dirección SISTEMA_ORIGINAL > NUEVO_SISTEMA.
  • Este flujo de información es típico para:
    • Procesos de migración de datos
    • Procesos de integración posibles pero no muy extendidos. Son aquellos procesos de integración con emisor SISTEMA_ORIGINAL y receptor NUEVO_SISTEMA.
  • Dará como resultado la necesidad de definir un mapeo de datos específico: Mapeo A.
• Flujo de información B. Mapeo para el flujo de información con dirección NUEVO_SISTEMA > SISTEMA_ORIGINAL
  • Este flujo de información es típico para:
    • Procesos de integración más comunes. Son aquellos procesos de integración con emisor NUEVO_SISTEMA y receptor SISTEMA_ORIGINAL.
  • Dará como resultado la necesidad de definir un mapeo de datos específico: Mapeo B.

Para el flujo de información A donde el mapeo es desde el sistema origen hacia el nuevo sistema, deberemos tener cuidado con los mapeos de datos con cardinalidad 1..N y N..N, correspondiendo el primer literal a la cardinalidad en el sistema original y el segundo a la cardinalidad en el nuevo sistema.

Para los flujos de información de tipo B, y donde el mapeo es desde el nuevo sistema hacia el sistema origen, deberemos tener cuidado con los mapeos de datos con cardinalidad N..1 y N..N, correspondiendo el primer literal a la cardinalidad en el sistema original y el segundo a la cardinalidad en el nuevo sistema.

En función de la correspondencia de datos nos podemos encontrar los siguientes escenarios:

Estrategia para definir el mapeo de datos A para Flujos de información (SISTEMA_ORIGINAL  > NUEVO_SISTEMA).

[ACT-PRE-FUNC-6] Adecuar Sistemas origen

Sobre diferentes sistemas origen, la ejecución del proceso de implantación puede suponer una modificación de su alcance, y de sus circuitos de interoperabilidad.

Ante esta situación, es común que surja la necesidad de modificar el sistema origen para adecuarlo a este nuevo escenario. Modificaciones comunes pueden ser las siguientes:

• Adecuación para el modelo de migración de datos histórico / activo. Ver apartado “9 Modelo de migración”.
• Eliminación de funcionalidades en código que queden obsoletas.
• Modificación de la parametrización del sistema origen > para eliminar funcionalidades, cambiar circuitos.
• Modificación o reducción de funcionalidades que si bien quedan activas, no en todo su alcance.
• Preparación de escenario de mantenimiento del sistema en modo solo lectura. Suele necesitar de la gestión de usuarios / roles / perfiles que no siempre dan cobertura a un escenario de solo lectura.
• Modificación en los elementos de autentificación para el sistema origen > permisos, perfiles, eliminación de usuarios, etc.
• Etc.

[ACT-PRE-FUNC-6.1] Definir modificaciones necesarias sobre sistema origen

Sobre diferentes sistemas origen, la ejecución del proceso de implantación puede suponer una modificación de su alcance, y de sus circuitos de interoperabilidad.

Ante esta situación, es común que surja la necesidad de modificar el sistema origen para adecuarlo a este nuevo escenario. Modificaciones comunes pueden ser las siguientes:

• Adecuación para el modelo de migración de datos histórico / activo. Ver apartado “9 Modelo de migración”.
• Eliminación de funcionalidades en código que queden obsoletas.
• Modificación de la parametrización del sistema origen > para eliminar funcionalidades, cambiar circuitos.
• Modificación o reducción de funcionalidades que si bien quedan activas, no en todo su alcance.
• Preparación de escenario de mantenimiento del sistema en modo solo lectura. Suele necesitar de la gestión de usuarios / roles / perfiles que no siempre dan cobertura a un escenario de solo lectura.
• Modificación en los elementos de autentificación para el sistema origen > permisos, perfiles, eliminación de usuarios, etc.
• Etc.

Todas las modificaciones que se acuerden sean necesarias llevar a cabo, serán incluidas en un registro para su control.

El alcance concreto deberá haberse debatido durante el proceso “[P-RP-FUNC-4] Sesiones de análisis de procesos”, y basarse en los acuerdos plasmados en el entregable “GEST05. Informe final Reingeniería de Procesos”.

Por último, del acuerdo de las modificaciones a llevar a cabo deberá surgir la actualización del “FUNC06. Plan de Pruebas de los sistemas origen”.

Matriz RASCI

Dependencias

Catálogo de entregables

[ACT-PRE-FUNC-6.2] Definir Plan de pruebas sobre sistemas origen

En el proceso anterior “

[ACT-PRE-FUNC-6] Adecuar Sistemas origen

Sobre diferentes sistemas origen, la ejecución del proceso de implantación puede suponer una modificación de su alcance, y de sus circuitos de interoperabilidad.

Ante esta situación, es común que surja la necesidad de modificar el sistema origen para adecuarlo a este nuevo escenario. Modificaciones comunes pueden ser las siguientes:

• Adecuación para el modelo de migración de datos histórico / activo. Ver apartado “9 Modelo de migración”.
• Eliminación de funcionalidades en código que queden obsoletas.
• Modificación de la parametrización del sistema origen > para eliminar funcionalidades, cambiar circuitos.
• Modificación o reducción de funcionalidades que si bien quedan activas, no en todo su alcance.
• Preparación de escenario de mantenimiento del sistema en modo solo lectura. Suele necesitar de la gestión de usuarios / roles / perfiles que no siempre dan cobertura a un escenario de solo lectura.
• Modificación en los elementos de autentificación para el sistema origen > permisos, perfiles, eliminación de usuarios, etc
• Etc.

[ACT-PRE-FUNC-6.1] Definir modificaciones necesarias sobre sistema

Sobre diferentes sistemas origen, la ejecución del proceso de implantación puede suponer una modificación de su alcance, y de sus circuitos de interoperabilidad.

Ante esta situación, es común que surja la necesidad de modificar el sistema origen para adecuarlo a este nuevo escenario. Modificaciones comunes pueden ser las siguientes:

• Adecuación para el modelo de migración de datos histórico / activo. Ver apartado “9 Modelo de migración”.
• Eliminación de funcionalidades en código que queden obsoletas.
• Modificación de la parametrización del sistema origen > para eliminar funcionalidades, cambiar circuitos.
• Modificación o reducción de funcionalidades que si bien quedan activas, no en todo su alcance.
• Preparación de escenario de mantenimiento del sistema en modo solo lectura. Suele necesitar de la gestión de usuarios / roles / perfiles que no siempre dan cobertura a un escenario de solo lectura.
• Modificación en los elementos de autentificación para el sistema origen > permisos, perfiles, eliminación de usuarios, etc
• Etc.

Todas las modificaciones que se acuerden sean necesarias llevar a cabo, serán incluidas en un registro para su control.

origen” se definen las modificaciones sobre los sistemas origen necesarias para su convivencia con los nuevos sistemas tras la finalización de la implantación. Las  modificaciones a realizar deben tener asociado un plan de pruebas que ejecutar sobre el sistema origen y que validen las modificaciones realizadas.

Matriz RASCI

Dependencias

Por último, del acuerdo de las modificaciones a llevar a cabo deberá surgir la actualización del “FUNC06. Plan de Pruebas de los sistemas origen”.

[ACT-PRE-FUNC-6.2] Definir Plan de pruebas sobre sistemas origen

Catálogo de entregables

[ACT-PRE-FUNC-7] Implementar optimizaciones como resultado de los planes de sistema

Es caso normal que una vez un producto es impmlantado implantado o desplegado en determinados entornos con características similares al entorno definitivo de producción, se proceda a ejecutar sobre dicha instancia determinados planes de prueba no relacionados en si con el proceso de implantación sino con el de construcción.

El ejemplo típico es la ejecución de planes de pruebas de sistemas o de estrés. Debido a que necesitan de un entorno similar a producción no es concluyente los resultados que pudieran desprenderse de su ejecución en un entorno de desarrollo, por lo que, si bien son actividades correspondientes a la fase de Construcción, se postpone pospone su ejecución hasta el despliegue del mismo, por lo que la actividad se enmarca temporalmente dentro de una orden de implantación.

De esta ejecución de pruebas surgirá un resultado y una serie de conclusiones que pueden mostrar la necesidad de implementar una serie de optimizaciones sobre los productos evaluados. Es en el marco de esta tarea donde los responsables del desarrollo incorporarían estas mejoras, que administrativamente hablando formarían parte del alcance de la orden de trabjo trabajo de construcción (aunque temporalmente coincidan en fase de implantación).

Matriz RASCI

Dependencias

Catálogo de entregables