Actividades por fases

APS

[ACT-APS-FUNC-1] Dimensionar el ámbito de implantación

Previo a cualquier trabajo de implantación en un centro, es conveniente obtener determinados indicadores que nos permitan tener una percepción sobre el volumen y la complejidad de dicho centro, dado que esta puede incidir positiva o negativamente en la complejidad de ejecución del proceso de implantación.

Es necesario recabar al menos la siguiente información referente al dimensionamiento del centro:

• Dimensionamiento general:
  • Infraestructura > número de camas, número de consultas, quirófanos, puestos de uci, etc.
  • Personal > número de directivos, facultativos, enfermería, administrativos de gestión, etc.
• Cartera de servicios
• Actividad > número de ingresos, estancias, urgencias, consultas, partos, éxitus, etc.
• Cartera de pruebas diagnósticas
• Infraestructura de asistencia: número de equipos cliente, salas de formación, salas de trabajo, etc.

[ACT-APS-FUNC-2] Definir impacto de la implantación

Este proceso, decide, del total de elementos catalogados en el proceso  “[ACT-APS-FUNC-1] Dimensionar el ámbito de implantación” cuáles de ellos se ven afectados por el proceso de implantación.

[ACT-APS-FUNC-3] Analizar estado situación inicial del hospital para la implantación (datos, parametrización, jaspers compatibles,…)

En esta actividad el objetivo principal es verificar el estado inicial de parametrización del hospital.

Se suele utilizar en aquellas implantaciones en las que se actualiza una versión del producto ya existente a una nueva, o en la que se parte de un producto común que se sustituye por otro, y en la que es necesario una situación controlada de partida en cuanto a parametrización.

Área de Sistemas e Infraestructuras

[ACT-APS-SIST-1] Catalogar los sistemas de información

Previo a cualquier trabajo de implantación en un centro, es conveniente obtener determinados indicadores que nos permitan tener una percepción sobre el volumen y la complejidad de dicho centro, dado que esta puede incidir positiva o negativamente en la complejidad de ejecución del proceso de implantación.

Para ello, en el área de sistemas es necesario recabar información referente al catálogo de sistemas de información: proveedores, productos, tecnologías, alcance de integraciones, modelos de integración, etc.

[ACT-APS-SIST-2] Entrega de entornos RP

Para la realización de la fase de Reingeniería de Procesos se debe disponer de un entorno con la versión más actualizada del aplicativo a implantar sobre el que se puedan llevar a cabo las sesiones de reingeniería, mostrar los procesos a los que se dará cobertura, etc.

Estos entornos deben estar con la suficiente antelación para que el equipo de implantación pueda verificar que funciona correctamente y que dispone de un juego de datos suficientemente amplio como para llevar a cabo las sesiones.

El Modelo Corporativo Marco de Implantaciones (MCMI) define una serie de entornos necesarios para implementar con garantías y seguridad todas las actividades involucradas en un proceso de implantación.

El número y características de los entornos viene marcada por las actividades que deben poder ejecutarse paralelamente en el tiempo y la interdependencia entre estas.

Los entornos comúnmente utilizados son:

• Entornos en Preproducción.
  • Los entornos en preproducción suelen  tres entornos diferenciados.
  • Entorno de RP
    • Generalmente cualquier entorno disponible que se facilita de forma provisional al equipo de implantación para que pueda llevar a cabo las sesiones de reingeniería de procesos.
    • Puede ser cualquier entorno que disponga de la versión del aplicativo a implantar, con independencia de que pertenezca o esté parametrizado para otro centro.
    • Una vez finalizados los procesos de reingeniería de procesos, este entorno puede ser liberado.
  • Entorno de FOR
    • Entorno que será utilizado por el equipo de implantación para la preparación del proceso de implantación.
    • En él se llevarán a cabo actividades relacionadas con la certificación de los procesos de integración, sesiones de formación, certificación de circuitos, etc.
  • Entorno de VAL
    • Este entorno es exclusivamente necesario para llevar a cabo la validación de los procesos de migración.
    • Dadas las características de los procesos de migración y la necesidad existente de contar con un entorno con la garantía de que los datos contenidos no sean modificados ni corrompidos durante el proceso de validación, es necesario contar con un entorno estanco que ofrezca estas facilidades.
    • De esta forma podremos validar los procesos de migración de datos garantizando que los resultados obtenidos son correctos y no han sido corrompidos.
    • Utilizar un entorno diferenciado permite paralelizar en el tiempo la ejecución de los procesos de migración de datos con los procesos de integración y formación.
    • En caso de no poder disponer de un entorno de validación de los procesos de migración (VAL), será obligatorio secuenciar este bloque de actividades para que sean ejecutadas antes o después de las actividades de integración, formación o cualquier otro bloque que pueda modificar datos, pero nunca en paralelo, pues no existiría el concepto de garantía de integridad de datos necesario para llevar a cabo la validación de los procesos de migración.
    • Una vez finalizada la validación de los procesos de migración, este entorno puede ser liberado.
• Entorno de PRO.
  • Entorno en producción con datos reales utilizado o que será utilizado por los usuarios finales una vez finalizado el proceso de implantación.
  • Para el entorno de producción podemos encontrarnos en el escenario de que dicho escenario ya esté disponible y puesto en producción (entornos centralizados, etc.). En este caso, el proceso de entrega del entorno no implicará despliegue físico y bastará con facilitar los datos de conexión, gestionar la apertura de comunicaciones, etc.

[ACT-APS-SIST-2.4] Solicitar despliegue de entornos

El jefe de equipo de implantación en común acuerdo con el jefe de proyecto por parte de la STIC deberá definir un cronograma estratégico que marque las líneas maestras de los periodos de implantación en caso de que el proceso vaya a ser ejecutado repetitivamente.

En base a este cronograma, y con la máxima antelación posible, deberá solicitarse a Sistemas de la STIC la entrega de los entornos necesarios para llevar a cabo los procesos de implantación: RP, FOR, VAL, PRO.

Deberá consensuarse con sistemas las fechas comprometidas para la entrega de cada uno de los entornos de forma que se garantice el cronograma estratégico de implantaciones y se minimice el impacto en la actividad planificada de Sistemas.

[ACT-APS-SIST-2.1] Entregar entornos para RP

Para la realización de la fase de Reingeniería de Procesos se debe disponer de un entorno con la versión más actualizada del aplicativo a implantar sobre el que se puedan llevar a cabo las sesiones de reingeniería, mostrar los procesos a los que se dará cobertura, etc.

Estos entornos deben estar con la suficiente antelación para que el equipo de implantación pueda verificar que funciona correctamente y que dispone de un juego de datos suficientemente amplio como para llevar a cabo las sesiones.

La entrega de estos entornos será entregada igualmente conforme al cronograma estratégico de las implantaciones y de acuerdo a las fechas solicitadas en el proceso [P-APS-SIST-2.4] Solicitar despliegue de entornos.

[ACT-APS-SIST-2.2] Gestionar apertura de comunicaciones para entornos de RP

La entrega de un entorno específico conlleva la gestión correspondiente de los canales de comunicación hacia y desde el mismo.

De esta forma, toda entrega de un entorno, aunque existiera previamente, debe ir acompañada con la gestión de las reglas de comunicación, apertura de firewalls, etc. necesarios para que los sistemas incluidos en el entorno puedan comunicarse entre sí según ha especificado el fabricante del aplicativo, y a su vez, estos puedan comunicarse con el resto de sistemas que vayan a conformar el ecosistema de aplicaciones involucradas (sistemas corporativos centralizados, departamentales, sistemas de terceros, aplicaciones distribuidas, etc.).

De cada comunicación es necesario recoger y registrar la siguiente información:

• Grupo de reglas
  • Para poder localizar las reglas fácilmente, agruparemos estas en diferentes grupos en función del entorno, la finalidad, etc.
• Código de regla
  • Todas las reglas deben ir acompañadas de un código único que las identifique para poder hacer referencia inequívocamente a la misma.
• Responsable de la apertura
  • En función de la regla de comunicación, existen diferentes responsables con la capacidad de gestionar e implementar la apertura.
  • Son responsables tipo:
    • Sistemas STIC
    • Sistemas del centro
• Definitiva / provisional
  • Determinadas reglas de comunicación deben tener un carácter definitivo sobre todo aquellas relacionadas con los entornos en producción.
  • Sin embargo, otras reglas tienen un carácter provisional y deben ser desactivadas después de que su finalidad haya expirado. En este tipo de reglas encontramos las relacionadas con los procesos de preparación de la implantación, la apertura hacia/desde VPNs de técnicos de implantación, etc.
  • Es por tanto necesario reflejar el carácter temporal de cada una de las reglas.
• Fecha de expiración
  • Para aquellas reglas de comunicación que sean provisionales, debe reflejarse la fecha límite en la que deben dejar de estar activas.
• Estado
  • Este valor nos permitirá hacer un seguimiento del estado de la regla de comunicación facilitando su gestión.
  • Se proponen al menos los siguientes valores:
    • Pendiente de definir
      • Para aquellas reglas incluidas en el catálogo completo cuya apertura aún no se ha solicitado.
      • Recordemos que el objetivo es trabajar con un catálogo completo de reglas pre-establecido de antemano.
    • Revisión solicitada
      • Para aquellas reglas que se ha solicitado se gestione su apertura y están en dicho proceso.
      • Una vez tengamos confirmación de su gestión debe pasarse su estado a “Implementada”.
    • Implementada
      • Para aquellas reglas de comunicación que ya hayan sido implementadas.
• Origen
  • Entorno origen
    • Diferencia entre orígenes centralizados y orígenes centralizados, pues implica diferencias en su gestión y en los actores involucrados.
    • Valores: distribuido / centralizado
  • Descripción
    • Referencia corta que defina de forma descriptiva al origen que estamos conectando
    • Ej.: ESB centralizado, Estación de Gestión en PRO, etc.
  • IP origen
    • IP concreta del sistema origen.
• Destino
  • Entorno destino
    • Diferencia entre orígenes centralizados y orígenes centralizados, pues implica diferencias en su gestión y en los actores involucrados.
    • Valores: distribuido / centralizado
  • Descripción
    • Referencia corta que defina de forma descriptiva al destino que estamos conectando
    • Ej.: ESB centralizado, Estación de Gestión en PRO, etc.
  • IP origen
    • IP concreta del sistema destino.
  • Puertos TCP
    • Debemos especificar los puertos TCP concretos a los que es necesario conectar:
    • Ej.: 80, 8080, 423, 1521, etc.
  • Puertos UDP
    • Ídem con los puertos UDP.

En relación específica a este proceso, deberá gestionarse la apertura de comunicaciones necesarias para el entorno de Reingeniería de Procesos solicitado y que será utilizado durante la fase de RP.

[ACT-APS-SIST-2.3] Verificar entrega de los entornos para RP

Una vez recepcionado el entorno para las Reingeniería de Procesos, el equipo de implantación deberá verificar que el entorno funciona conforme a sus expectativas y cumple con las funcionalidades necesarias para llevar a cabo las sesiones de Reingeniería de Procesos.

Si bien la verificación será llevada a cabo por el equipo de implantación, la responsabilidad de que este proceso se pase con éxito recae en Sistemas STIC, quien entrega el entorno y deberá ejecutar las acciones necesarias para garantizar que el entorno facilitado sea totalmente operativo.

Reingeniería de Procesos

 Área Funcional

[ACT-RP-FUNC-1] Sesiones de RP de Visitas al ámbito

Una vez se haya presentado oficialmente el MCI a los involucrados, podremos comenzar con las sesiones de reingeniería de procesos con la visita al ámbito.

Se realizarán visitas conjuntamente con el responsable correspondiente para conocer de primera mano el funcionamiento de cada ámbito, registrando información relevante sobre cada uno como personal de cada perfil, ubicaciones, circuito habitual, excepciones,…

De este tipo de visitas, se extraen conclusiones e información adicional que normalmente no es transmitida por el usuario final en reuniones de reingeniería en una sala de trabajo (disposición física, disponibilidad de espacio e infraestructuras, flujo físico, etc.).

[ACT-RP-FUNC-2] Sesiones de RP circuitos actuales

El centro presenta los circuitos funcionales que actualmente se encuentran implementados en el mismo.

Se obtienen y anotan conclusiones para modelar posteriormente dichos circuitos con los implementados con el nuevo sistema.

De esta forma, los perfiles expertos en el nuevo sistema a implantar conocen de primera mano el funcionamiento del centro y aquellas características que lo hagan específico.

[ACT-RP-FUNC-3] Sesiones de RP circuitos nuevo sistema

Los miembros del equipo de implantación presentan al centro los circuitos implementados en el aplicativo o sistema a implantar.

Los referentes del centro obtienen y anotan conclusiones para modelar posteriormente dichos circuitos con los implementados actualmente en el centro.

De esta forma, los perfiles referentes del centro conocen de primera mano el funcionamiento del nuevo sistema y aquellas características que sean clave para poder encajar sobre el mismo los procesos actuales.

[ACT-RP-FUNC-3.4] Enfermería

Los miembros del equipo de implantación presentan al centro los circuitos implementados en el aplicativo o sistema a implantar.

Los referentes del centro obtienen y anotan conclusiones para modelar posteriormente dichos circuitos con los implementados actualmente en el centro.

De esta forma, los perfiles referentes del centro conocen de primera mano el funcionamiento del nuevo sistema y aquellas características que sean clave para poder encajar sobre el mismo los procesos actuales.

[ACT-RP-FUNC-3.3] Facultativos

Los miembros del equipo de implantación presentan al centro los circuitos implementados en el aplicativo o sistema a implantar.

Los referentes del centro obtienen y anotan conclusiones para modelar posteriormente dichos circuitos con los implementados actualmente en el centro.

De esta forma, los perfiles referentes del centro conocen de primera mano el funcionamiento del nuevo sistema y aquellas características que sean clave para poder encajar sobre el mismo los procesos actuales.

[ACT-RP-FUNC-3.2] Admisión

Los miembros del equipo de implantación presentan al centro los circuitos implementados en el aplicativo o sistema a implantar.

Los referentes del centro obtienen y anotan conclusiones para modelar posteriormente dichos circuitos con los implementados actualmente en el centro.

De esta forma, los perfiles referentes del centro conocen de primera mano el funcionamiento del nuevo sistema y aquellas características que sean clave para poder encajar sobre el mismo los procesos actuales.

[ACT-RP-FUNC-3.1] Urgencia

Los miembros del equipo de implantación presentan al centro los circuitos implementados en el aplicativo o sistema a implantar.

Los referentes del centro obtienen y anotan conclusiones para modelar posteriormente dichos circuitos con los implementados actualmente en el centro.

De esta forma, los perfiles referentes del centro conocen de primera mano el funcionamiento del nuevo sistema y aquellas características que sean clave para poder encajar sobre el mismo los procesos actuales.

[ACT-RP-FUNC-4] Sesiones de análisis de procesos

Tras un periodo de reflexión, una vez visitado los ámbitos funcionales del centro, y presentado los circuitos a los que da cobertura el sistema a implantar, se realizarán sesiones para presentar la propuesta de engranaje entre los circuitos del hospital y los ofertados por el sistema, a los responsables correspondientes para analizar la idoneidad de este engranaje.

En estas sesiones se podrán sacar conclusiones sobre el grado de adaptación del nuevo sistema en el centro para elevar los riesgos y beneficios de la implantación de estos.

En estas reuniones deberán participar los responsables funcionales correspondientes del centro, responsables de TIC, el responsable de implantación además del consultor funcional correspondiente del equipo de implantación.

Es fundamental que estén especialmente los responsables funcionales para que todas aquellas excepciones que existan en los circuitos del hospital, puedan salir a la luz y tenerse en cuenta para las siguientes fases y queden reflejados en el documento ”GEST05. Informe final Reingeniería de Procesos GEST05. Informe final Reingeniería de Procesos” y en el documento “GEST06. Catálogo de peticiones de cambio funcionales “.

[ACT-RP-FUNC-5] Verificar estado inicial

En la Verificación del estado inicial el objetivo es concienciar a la Gerencia, Dirección y responsables del centro en la criticidad de que una serie de actividades deben ser ejecutadas por el centro en tiempo y forma para realizar una implantación con éxito. Entre estas se encuentran las actividades que más adelante veremos en la fase de preimplantación, como la parametrización de Estructura Física y Funcional si aplica, la preparación y gestión de los operadores, profesionales, perfiles y permisos, y la adecuación de los módulos corporativos involucrados para su preparación de cara al proceso de implantación

La experiencia confirma que la no adecuada ejecución de estas actividades de la fase de preimplantación supone un incremento en ocasiones traumático de las incidencias en los primeros días después del arranque. De aquí la importancia de que los altos cargos del centro conozcan y asuman la relevancia de estas actividades.

El equipo de implantación debe apoyar en todo momento al hospital en la consecución de estas metas, aportando la experiencia y las herramientas que hayan generado valor añadido en anteriores implantaciones para la ejecución de estas actividades.

[ACT-RP-FUNC-6] Definir Plan de Pruebas de Aceptación del Sistema

El plan de pruebas de aceptación del sistema debe contener las pruebas generales que se llevarán a cabo la noche del arranque por parte del equipo de implantación y de responsables o referentes del centro en el que esta se lleva a cabo durante la ejecución del proceso .Este Plan de pruebas NO es por tanto el plan de pruebas funcionales completo que chequearemos durante la fase de implantación. Dicho Plan es el FUNC07. Plan de Pruebas Funcionales de los Circuitos.El objetivo de este plan es definir aquellas pruebas que se van a llevar a cabo en un periodo de tiempo corto (máximo 1 hora) para verificar que, un sistema que ya ha sido previamente verificado durante la fase de implantación, y tras la migración de todos los datos activos y la activación de los elementos de integración, sigue comportándose correctamente y de igual forma a la que lo hizo durante la ejecución del “FUNC07. Plan de Pruebas Funcionales de los Circuitos” en la fase de implantación.

[ACT-RP-FUNC-8] Definir Plan de Pruebas Funcionales de los circuitos

Una vez se hayan parametrizado los entornos durante el proceso “[ACT-IMP-FUNC-1.2] Parametrizar funcionalmente los entornos en PRE” y se hayan implementado sobre este las modificaciones acordadas e implementadas en el proceso “[ACT-IM

[ACT-RP-FUNC-9] Entregar plantillas de parametrización

Los elementos que son susceptibles de ser parametrizados deben ser conocidos de antemano y facilitados por el N3 del nuevo sistema a implantar.

Son elementos parametrizables:

• Parámetros del sistema
• Valores de tablas maestras

Es conveniente tener en cuenta que no todos los parámetros del sistema y los valores de tablas maestras pueden ser modificados a conveniencia, dado que en ocasiones, los valores de estos elementos son fijados de forma corporativa por decisión de los grupos funcionales.

Las plantillas de parametrización y las guías de parametrización deben referir la información suficiente para poder conocer de forma inequívoca:

• Qué valores no pueden ser modificados y tienen un valor fijo por decisión corporativa.
• Qué valores deben ser parametrizados pero de acuerdo con la directriz marcada en una decisión corporativa.
  • Ej.: parámetros que hagan referencia a códigos de unidades funcionales.
• Qué valores pueden ser parametrizados a conveniencia.

En este proceso, haremos entrega de las plantillas o material de recogida de los valores de parametrización a los usuarios involucrados, procediéndose a un análisis conjunto con estos de dicho material.

Se debe garantizar que los usuarios  responsables de recopilar los valores de parametrización entienden y comprenden sin lugar a duda la información que se les está requiriendo y las consecuencias de la toma de decisión sobre cada uno de los valores de dichos elementos de parametrización.

Para ello, entre otras medidas, se debe facilitar igualmente a los responsables las correspondientes guías de parametrización del sistema.

 Área Formación

[ACT-RP-FORM-1] Transferencia del conocimiento > Actividades fase PRE

Una vez llevadas a cabo las sesiones de reingeniería de procesos, y antes de comentar la fase de Preimplantación, debemos asegurarnos que las tareas incluidas en esta fase son entendidas e interiorizadas por cada uno de sus responsable, en general, del centro.

Para ello, llevaremos a cabo este proceso de transferencia del conocimiento con los recursos implicados.

[ACT-RP-FORM-2] Estimar esfuerzo necesario formación usuarios finales

La formación se establece con el siguiente alcance de forma general salvo norma o pacto en contra:

• Para perfiles con menos de 50 usuarios.
  • Formación al 100% de los usuarios.
  • Dado que se trata de un número reducido de usuarios, es posible formar al 100% de sus integrantes.
  • Suelen ser además perfiles muy específicos para los que se hace conveniente la extensión de la formación directa a todos sus miembros.
  • Ej.: administrativos de admisión o programadores quirúrgicos.
• Para perfiles con más de 50 usuarios
  • Se establecen dos alternativas no excluyentes para colectivos numerosos.
  • Modalidad de formación a formadores.
    • Seleccionando un subconjunto de usuarios de referencia del centro, generalmente también detectados como candidatos a soporte n0.
    • Este subconjunto de profesionales, tras asistir a formación intensa y específica deberá definir un calendario de formación al resto de compañeros, por lo que es importante que gocen de la suficiente disponibilidad para que este modelo sea realmente efectivo.
  • Formación en sesiones plenarias
    • Sustituyendo las sesiones de formación en aulas de trabajo en las que se pueda practicar por presentaciones en aulas magnas o localizaciones que permitan la asistencia masiva de usuarios (de 100 en 100 por ejemplo).

El objetivo principal de esta actividad será recabar la información necesaria para poder estimar las necesidades de formación del centro, amén de conocer con nombres y apellidos los usuarios expertos y los tutores del hospital, como más adelante explicamos.

Esta sesión se llevará a cabo de las últimas, una vez realizadas todas las sesiones funcionales, de modo que nos hayan ayudado a averiguar los distintos perfiles (por las tareas que desempeñan en los distintos circuitos funcionales) que hay en el hospital y que utilizarán cualquiera de los módulos del sistema para realizarla.

Definiremos así una serie de perfiles sobre los que se organizará y planificará la formación.

A modo de ejemplo, en un entorno de atención especializada, los siguientes suelen ser perfiles tipos: Administrativo de Admisión, Responsable de Admisión, Técnico de Archivo, Responsable de Archivo, Visador Quirúrgico, Programador Quirúrgico, Administrador de la Estación de Cuidados, Supervisor de la Estación de Cuidados, etc. Pero puede que como resultado de las visitas in-situ se detecte la necesidad de ampliar la formación a algún perfil no contemplado entre los perfiles tipo utilizados en implantaciones anteriores.

Obtendremos el número de usuarios por perfil, para organizar la formación de manera que pueda impartirse al menos a un porcentaje entre el 80% y el 100% de los usuarios de cada perfil para, de este modo, ayudar a que el soporte dedicado a estos usuarios en las fechas posteriores al arranque sea menor que si se impartiesen en modo formación a formadores.

Un aspecto muy importante son los recursos de los que dispone el hospital para impartir la formación. Nos referimos a las aulas de formación, proyectores, disponibilidad de red para acceso a los entornos, capacidad de las mismas, si dispone de Aula Magna, o Salón de Actos para sesiones multitudinarias, etc. Obtendremos estos datos también para prever con antelación las necesidades que hubiese para cubrir el alcance a los porcentajes indicados de usuarios por perfil.

Otro aspecto clave será identificar los usuarios expertos, es decir, aquellos a los que habrá que dedicar especial atención en la formación ya que serán los referentes por áreas, del soporte N0, una vez puesto en producción el sistema en el hospital, siendo estos los primeros a los que podrán acudir sus propios compañeros para realizar las consultas, o dudas que tengan. Serán referencia funcional  para los usuarios del centro, una vez el equipo de implantación haya finalizado el periodo de Consolidación y Extensión. Aparte de realizar con ellos la transferencia del conocimiento necesario a nivel funcional, también se formará a determinados perfiles en cuanto a las áreas de integraciones, infraestructura de servidores, réplicas…

Aparte de la celebración de estas sesiones de formación específicas para los usuarios expertos, el conocimiento que estos adquirirán a través de las mismas se complementará de forma diaria con la participación activa en la ejecución de las actividades de implantación de la mano del equipo de implantación, y con el acceso a entornos de formación en los que profundizar y experimentar procesos con las nuevas herramientas.

[ACT-RP-FORM-3] Entregar requisitos equipamiento formación

En esta actividad, se procederá a la entrega al centro de los requisitos mínimos necesarios que han de cumplir los equipos cliente puestos a disposición de la formación de manera que se garantice que esta pueda llevarse a cabo sin problemas.

Incluye todos los requisitos que deberá cumplir un puesto cliente normal más aquellos adicionales que se estimen convenientes para poder ser utilizados en sesiones de formación (cañones de proyección, orientación de las mesas, pizarras, etc).

Área de Migración

[ACT-RP-MIGR-1] Entregar catálogo de reglas de negocio implicadas

Durante la ejecución de este proceso, se entregará y expondrá el catálogo de requisitos que han de cumplir los datos para poder ser migrados al sistema a implantar, haciendo especial hincapié en aquellos que en otros centros hayan supuesto un mayor escollo.

Entre estos requisitos, y a título de ejemplo, se encuentra la obligatoriedad de que los pacientes cuyos datos se desean migrar, dispongan de NUHSA, un único NHC activo, etc.

Estos requisitos y reglas deberán ser tenidos en cuenta en todo momento en la implementación de los procesos de extracción y transformación de datos del sistema origen, pues se deberá verificar que los datos contenidos en los ficheros de salida de dichas extracciones cumplan con todas y cada una de dichas reglas.

[ACT-RP-MIGR-2] Definir Alcance de las migraciones

El objetivo de esta actividad es definir al máximo detalle:

• Qué datos van a ser migrados y cuales no por falta de calidad en los datos, etc.
• Qué restricciones han de cumplir cada uno de los registros y cada uno de los campos de estos para poder ser migrados al nuevo sistema.
• Para aquellos valores obligatorios en el nuevo sistema para los que no exista información a migrar en el sistema origen, se deberá acordar qué valor/valores dummy van a ser utilizados.
• Requisitos previos que deberán tenerse en cuenta antes de la implementación de los procesos de extracción de datos.
• Decisiones generales a tener en cuenta: formatos de ficheros, de líneas de ficheros, de fechas, caracteres especiales, etc
• Para cada campo de cada entidad a migrar, cuál es el origen de datos del que se va a nutrir de información (entidad y campo concreto).
• Qué campos son obligatorio especificar en el fichero de migración y cuales serán opcionales. Siempre de acuerdo con las restricciones de la guía de migración y el Manual de Alcance de las migraciones del sistema a implantar correspondiente.

Además de las reglas entregadas y analizadas en el proceso “[P-RP-MIGR-1] Entregar catálogo de reglas de negocio implicadas”, se deben exponer aquellas recomendaciones basadas en las experiencias vividas en otros centros que resulten importantes para garantizar que los procesos de extracción y transformación de datos serán los más adecuados para la consecución del objetivo final de migración de información.

Estas apreciaciones junto con el conocimiento interno de la calidad de los datos albergados en el sistema origen por parte del centro formarán la base de decisión sobre la que se sustentará el acuerdo de alcance de la migración.

Igualmente se pondrán de manifiesto un conjunto de actividades sobre las que el centro, acompañado en todo momento por el equipo de implantación, deberá incidir con mayor fuerza durante la fase de Preimplantación con el objetivo de maximizar el número de registros migrados.

Como ejemplo en un ámbito de atención especializada, una de las principales actividades en este sentido es la conciliación sistemática de usuarios con BDU hasta alcanzar un ratio de al menos el 90% de los usuarios que tienen episodio en el hospital en los últimos 3-5 años. A mayor % de conciliación obtenido, mayor número de registros se verán incluidos en el proceso de migración, y menor será el impacto de cara al acceso a la historia clínica del paciente en el nuevo sistema.

[ACT-RP-MIGR-3] Definir Plan de Pruebas de migración Cualitativas (catas)

Una vez definido el alcance de las migraciones en la actividad anterior, será necesario definir y consensuar cuál será el catálogo de pruebas que se llevarán a cabo para verificar que los procesos de migración (extracción, transformación y carga de datos)  se han llevado a cabo correctamente.

A este respecto, definiremos dos Planes de prueba diferentes relacionados con el área de migración de datos.

• MIGR04. Plan de pruebas de migración Cualitativas. > Verifica aspectos cualitativos de la migración.
• MIGR05. Plan de pruebas de migración Cuantitativas > Verifica aspectos cuantitativos de la migración.

El “MIGR04. Plan de pruebas de migración Cualitativas.”, que es el que atañe a esta actividad, contendrá todas las pruebas funcionales que deberán llevarse a cabo sobre una cata de información para verificar que el proceso de migración, hasta el más mínimo, detalle es correcto.

Se verificarán que todos los datos se carguen correctamente en su correspondiente campo, que los mapeos entre tablas maestros funcione bien en el 100% de los casos, que los  valores dummy acordados son visualizados convenientemente cuando deben, etc.

Dado que estas pruebas son tan tediosas, no es posible llevar a cabo toda la batería sobre el 100% de los datos a migrar, dado que se trata de una inspección manual.

Esta idiosincrasia hace demasiado costoso revisar un número de registros superior a 100, por lo que este es considerado un número correcto de datos a verificar.

Dado que trabajaremos con un subconjunto, es importante que la elección del mismo sea cuidadosamente elegida en el proceso “[P-PRE-MIGR-4] Establecer subconjunto de datos para las pruebas de migración unitarias”.

[ACT-RP-MIGR-4] Definir Plan de Pruebas de migración Cuantitativas

El “MIGR05. Plan de pruebas de migración Cuantitativas”, a diferencia del “MIGR04. Plan de pruebas de migración Cualitativas.”, lleva a cabo una batería de pruebas a un nivel más amplio pero a la vez más general.

Este plan de pruebas, a diferencia del anterior, se centra sobre el aspecto cuantitativo en lugar de sobre el cualitativo, verificando conteos de registros y correspondencia con los números en el sistema origen.

Es por ello que es necesario ejecutarlo sobre una migración completa.

Área de Integración

[ACT-RP-INTE-1] Entregar contratos integración y tablas maestras involucradas

Al comienzo de la fase de reingeniería de procesos, deberá trasladarse al centro los contratos de integración corporativos para que sean tenidos en cuenta por este y por los proveedores que de él dependan.

En esta actividad deberá llevarse a cabo la transferencia del conocimiento necesaria hacia dichos actores, a través de la Oficina Técnica de Interoperabilidad.

[ACT-RP-INTE-2] Sesión RP de integración

Si bien debe garantizarse la correcta ejecución de todas las integraciones incluidas en el alcance de la implantación, el objetivo principal en este apartado radica en detectar cual es el subconjunto de integraciones crítico de cara al correcto funcionamiento del centro en el momento del arranque. Si bien todas las integraciones tienen su importancia y su razón de ser, no todas comparten el mismo nivel de impacto en caso de mal funcionamiento en dicho momento. A este respecto, integraciones como las existentes hacia los servicios peticionarios, los departamentales de dietas o de farmacia suelen tener un nivel de impacto mayor al existente por ejemplo en la integración con un sistema de impresión de sobres o un cuadro de mandos.

Detectar y categorizar como críticas este tipo de integraciones nos ayudará a hacer sobre las mismas un especial seguimiento y una labor más exhaustiva si cabe, sin menoscabo alguno de la correcta gestión y cumplimiento de objetivos con el resto.

Garantizando el control y la monitorización de los procesos en los que se ven involucradas estas integraciones conseguiremos en gran medida el escenario de arranque esperado.

Es importante en este aspecto analizar todos los elementos integrados existentes que se ven afectados con el proceso de implantación, así como los nuevos elementos que entran en funcionamiento. Se ha de tener en cuenta igualmente no solo las integraciones corporativas a través de ESB, sino también cualquier otro tipo de integración a través de acceso a bases de datos, dblinks, acceso a descarga de ficheros vía ftp, permisos sobre vistas, web services, etc.

[ACT-RP-INTE-3] Definir Plan de Pruebas de conectividad de integraciones

Una vez analizado el espectro de integraciones que intervienen y son afectadas por el proceso de implantación durante la sesión “[ACT-RP-INTE-2] Sesión RP de integración”, tendremos acotado y acordado el alcance.

[ACT-RP-INTE-4] Definir Plan de Pruebas funcionales de las integraciones

Una vez analizado el espectro de integraciones que intervienen y son afectadas por el proceso de implantación durante la sesión “[ACT-RP-INTE-2] Sesión RP de integración”, tendremos acotado y acordado el alcance.

Área de Sistemas e Infraestructuras

[ACT-RP-SIST-1] Entregar requisitos mínimos

En esta actividad, se procederá a la entrega al centro de los requisitos mínimos necesarios que han de cumplir los equipos cliente puestos a disposición de la formación de manera que se garantice que esta pueda llevarse a cabo sin problemas.

[ACT-RP-SIST-2] Verificar situación infraestructura de comunicaciones

De forma previa a que se lleve a cabo la fase de Arranque, deberá verificarse según se haya determinado específicamente para el proyecto, que las infraestructuras de comunicaciones del centro son aptas para dar cobertura al nuevo sistema.

En función de la tipología del nuevo sistema, requisitos de conectividad y arquitectura, nos encontraremos en un escenario más exigente o más laxo en relación a la criticidad de las infraestructuras de comunicaciones.

Por ello, deberá ser en cada proyecto concreto donde se acuerde cual es la situación que hay que garantizar en relación a la infraestructura de comunicaciones y las acciones correctivas necesarias para dicha garantía.

 Área de Análisis y Explotación de Datos

[ACT-RP-AYED-1] Inventariar sistemas de explotación afectados

Sabemos de la importancia organizativa que tiene para los centros la disponibilidad de información de seguimiento y control, tanto para el funcionamiento diario, la toma de decisiones en el ámbito hospitalario cómo para la comunicación a terceros en el cumplimiento de compromisos adquiridos.

De las actividades del área de AyED, corresponden a la fase de Reingeniería de Procesos las relacionadas con la detección y catalogación de todas las fuentes de información externas relativas a explotación de información que se nutran del sistema origen a sustituir, y que tengan el riesgo de no disponer de información actualizada, una vez finalizado el proceso de implantación del nuevo sistema. Entre estas suelen encontrarse, aplicaciones de cuadro de mandos propias del centro, procesos de generación de informes en entornos web, procesos nocturnos de cálculo de datos, scripts de extracción de información para alimentar estructuras de datos en Excel o ficheros planos, etc.

[ACT-RP-AYED-2] Analizar cobertura de los procesos de explotación de datos

Una vez catalogados todos los procesos de explotación de datos, es necesario contrastar los procesos en este ámbito existentes en el centro y catalogados con los ofrecidos por el nuevo sistema a implantar, poniendo el foco y el énfasis en aquellos procesos actuales que pasen a estar obsoletos tras la implantación bien porque se apague el origen de datos, bien porque se modifique el modelo de datos, etc.

Es labor en este proceso ese análisis y la categorización de los procesos de explotación de datos antes inventariados para conocer:

• Cuales permanecen invariables.
• Cuales son válidos pero deben ser actualizados.
• Cuales pasan a ser obsoletos y deben implementarse de nuevo tomando de origen de datos el nuevo sistema de información.

Deberá en este proceso igualmente planificarse las necesidades de desarrollo que supongan estas adecuaciones.

Área de Gestión

[ACT-RP-GEST-8] HITO. Comienzo trabajo equipo implantación

[ACT-RP-GEST-1] Presentar MCI. Visión y Alcance

En relación al área de gestión durante la fase de Reingeniería de Procesos, una de las principales actividades que se llevará a cabo es la presentación del MCI al centro.

Supone la introducción a los implicados en el proceso de implantación que será ejecutado, y proporcionará a estos una visión general sobre los hitos y horizonte que deberán ser marcados para la consecución con éxito de la implantación.

En esta presentación es clave la participación de los órganos directivos del centro (Gerencia, Dirección Médica, Dirección de Enfermería, Dirección de Atención al Ciudadano, Coordinadores Provinciales de TIC, Administración, etc.). La asimilación por parte de estos cargos del horizonte marcado propiciará la comprensión de las metas y objetivos a conseguir y la eliminación de falsas expectativas.

La gestión de las expectativas debe convertirse en un aspecto positivo de la implantación.

Huyendo siempre de la asimilación de falsas expectativas, el momento de implantación debe ser aprovechado como un momento de oportunidad para la mejora de la gestión en el centro, propiciando la modificación de pautas y procesos que se ejecutan erróneamente y que se encuentran arraigados, o mejorando determinados aspectos que el análisis de la actividad arroja como mejorables.

Esta actividad marcará el comienzo de las actividades de la fase de Reingeniería de Procesos

[ACT-RP-GEST-2] Identificar riesgos

En todo proyecto es necesario identificar los riesgos y disparadores asociados al proyecto, clasificándolos según sus principales componentes, y según los tipos y categorías de riesgos más importantes.

Se identificará de manera clara la causa específica de cada riesgo y el objetivo u objetivos del proyecto sobre los que estos inciden.

Los disparadores (triggers) son síntomas o señales de advertencia de que un riesgo ha ocurrido o está a punto de ocurrir.

La identificación de riesgos es un proceso iterativo, que comienza en la fase de planificación del proyecto y finaliza en su cierre. Dentro de cada una de estas fases, el análisis de la situación en busca de riesgos ha de ejecutarse periódicamente.

El formato del enunciado de cada riesgo ha de asegurar que este se entiende claramente y sin ambigüedades.

Como resultado obtendremos un “GEST04. Registro de riesgos” riesgos que analizaremos en los siguientes procesos. Este registro, debe contener al menos:

• Lista de riesgos identificados, incluyendo causas y asunciones inciertas.
• Efecto que puede provocar la materialización del riesgo.
• Se identifican los disparadores (triggers) asociados a cada riesgo que indican que el riesgo a ocurrido o está a punto de ocurrir
• Causas que provocan la existencia del riesgo.
• Lista de posibles respuestas al riesgo.
• El indicio que identifica que el riesgo se ha materializado
• Categorización del riesgo. Es conveniente basarse en una matriz EDR (Estructura de Desglose de Riesgo).

En las fases de planificación es cuando es conveniente identificar los riesgos, si bien estos pueden aparecer en cualquier fase del ciclo de vida del proyecto y deben ser gestionados. Por ello la idoneidad de identificar los riesgos en la fase de Reingeniería de Procesos.

[ACT-RP-GEST-3] Realizar el Análisis Cualitativo de riesgos

El análisis cualitativo de riesgo evalúa la prioridad de los riesgos identificados usando:

• La probabilidad de ocurrencia,
• El impacto correspondiente sobre los objetivos del proyecto. En una unidad de medida (tiempo, monetario, etc).
• El tiempo de respuesta, etc.
• Severidad del riesgo.

El análisis cualitativo es una forma de priorizar de forma rápida y rentable las prioridades de la planificación de la respuesta a los riesgos. En embargo, en ocasiones no es suficiente y es necesario acompañarlo de un análisis cuantitativo para algún riesgo en concreto más crítico.

El análisis cualitativo de riesgos debe ser revisado continuamente pues la situación puede cambiar.

 Como salida, dotaremos al entregable “GEST04. Registro de riesgos” de información adicional a la obtenida en el proceso anterior, y que facilitarán su priorización a través del cálculo de su severidad (probabilidad * impacto).

[ACT-RP-GEST-4] Planificar la respuesta a Riesgos

Una vez hemos identificado los riesgos, y estos han sido analizados al menos cualitativamente, podemos planificar la respuesta a los mismos.

[ACT-RP-GEST-5] Elaborar Informe Reingeniería de Procesos

El resultado final de esta fase será plasmado en la definición del entregable “GEST05. Informe final Reingeniería de Procesos” que contendrá toda la información relevante recopilada durante las sesiones de reingeniería de procesos y todos aquellos aspectos críticos a tener en cuenta en sucesivas fases.

Este informe ha de contener al menos la siguiente información:

• Resumen de los acuerdos alcanzados durante las sesiones de RP.
• Valores de los elementos parametrizables ya acordados
• Modificaciones sobre los sistemas origen necesarias de cara al arranque.
• Modificaciones acordadas sobre el nuevo sistema que están a la mano del equipo de implantación.
• Detalle de las decisiones importantes tomadas respecto a los procesos y flujos de información en el hospital.

[ACT-RP-GEST-6] Enviar de Peticiones Cambios / Mejoras al Comité de Cambios

Durante la ejecución de los sesiones de Reingeniería de Procesos se habrán recopilado diferentes peticiones de cambio o solicitudes de mejora sobre la funcionalidad implementada sobre el nuevo sistema a implantar.

Estas peticiones de cambio o mejora deberán ser trasladadas a los referentes del ámbito funcional de la STIC para su análisis y toma en consideración.

[ACT-RP-GEST-7] Elaborar cronograma implantación

La última parte de esta fase se centrará en la definición conjunta de un cronograma para la ejecución de las actividades de las siguientes fases (Preimplantación e implantación).

Haremos hincapié en el concepto “conjunto” pues ha de constituir un compromiso por todas las partes involucradas (equipo de implantación, centro, STI, proveedores, N3, etc.). Este compromiso, en relación a la fase de preimplantación debe garantizar que el centro se encuentre preparado y adecuado para el aterrizaje del equipo de implantación al completo al final de dicha fase, y que, una vez comience la fase de implantación, ninguna de las partes involucradas se va a encontrar en un estado bloqueado que le impida completar con éxito su responsabilidad de cara a la fecha propuesta de arranque.

Preimplantación

El equipo de implantación debe colaborar con el centro para garantizar el éxito de estas actividades, facilitando un primer cruce de los usuarios del sistema a sustituir, con los ya existentes en MACO. Esto  permitirá detectar cuales coinciden unívocamente, cuales pueden coincidir con uno o más usuarios, y cuáles de forma certera no están en este módulo central.

Para ello, deben utilizarse procedimientos de análisis de información basados en reglas acordadas con el hospital que permitirán categorizar a los usuarios en estos grupos.

[ACT-PRE-FUNC-3.2] Preparar procesos de Autentificación a través de DMSAS

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 DMSAS.

Es necesario verificar de forma previa al arranque durante la fase de preimplantación que todos los usuarios que vayan a utilizar estos sistemas que se autentifican a través de DMSAS, dispongan de usuario en el dominio y tengan asociado el rol/perfil correspondiente.

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

En resumen, es necesario tener en cuenta que los mapeos de datos son bidireccionales, y así han de ser definidos para dar cobertura correctamente a los procesos de migración y de integración (para los sentidos de flujo de integración utilizado).

 Área Formación

[ACT-PRE-FORM-1] Definir Plan de formación

En esta actividad seguiremos completando el Plan de Formación.

Durante la fase de Preimplantación, se adecuarán los planes formativos al centro, se personalizarán los contenidos de manuales y guías a las funcionalidades que necesitan cada perfil según la información obtenida en la Reingeniería de Procesos, se propondrá un Calendario de Formación para los tres módulos de DAH, teniendo en cuenta los distintos perfiles existentes, además de realizar la transferencia del conocimiento a los usuarios expertos.

El Plan de formación debe incluir al menos la siguiente información:

• Catálogo de Unidades Didácticas diferenciadas a impartir
• Índice del contenido de cada una de las Unidades Didácticas
• Mapeo de los perfiles o roles a los que aplica cada unidad didáctica.
• Número de sesiones de formación por cada Unidad Didáctica y Perfil/Rol.
• Calendario de sesiones de formación con fecha, hora, unidad didáctica y colectivo al que se va a impartir la formación.

[ACT-PRE-FORM-2] Preparar material de formación

En caso de ser necesario la preparación de material previo para llevar a cabo la formación, deberá ser confeccionado en el transcurso de esta actividad.

Se incluye dentro de esta actividad la preparación de todos los juegos de datos necesarios para disponer de casuísticas suficientes para impartir la formación para todos los asistentes.

Se incluye igualmente la adecuación de guías, esquemas, y demás material de apoyo si así es necesario.

[ACT-PRE-FORM-3] Validar Plan de formación

Por último, se procederá a validar con el centro el Plan de formación confeccionado.

Este proceso será ejecutado hasta conseguir la validación de dicho plan.

[ACT-PRE-FORM-4] TC > formación a responsables TIC del centro / CGES

El objetivo de este proceso es facilitar a los responsables TIC del centro cuanta formación y conocimiento necesiten sobre la nueva herramienta a implantar.

Se llevarán a cabo sesiones específicas de formación sobre aspectos tanto funcionales como técnicos.

Se implementarán igualmente cualquier otra vía de transferencia del conocimiento que se estime oportuno para asegurar la misma: trabajo conjunto, tutorización, etc.

Durante esta fase se seguirá profundizando en Transferir el Conocimiento a los usuarios expertos de referencia, en este caso usuarios TIC, propiciando así que se familiaricen cuantos antes con los módulos y puedan maximizar el aporte de valor añadido y las mejores soluciones durante el soporte N0 al resto de usuarios del centro durante la fase de consolidación.

Disponer de un periodo de tiempo mayor para practicar con los módulos, resolver dudas, etc., antes del arranque redundará positivamente en una mayor destreza con los nuevos sistemas, permitiendo ofrecer el soporte deseado, y facilitando la necesaria autonomía de los usuarios y del centro en general a la salida del equipo de implantación.

Por esto, insistiremos en la implicación al 100% de estos usuarios en la Transferencia del Conocimiento, garantizándose  así que la salida del equipo de implantación sea un proceso natural y exitoso.

Área de Migración

[ACT-PRE-MIGR-1] Establecer mecanismo diferenciación activo vs pasivo

Es en esta fase donde se decidirá en función del número de registros finalmente incluidos en el proceso de migración, el mecanismo que se utilizará para marcar la frontera entre los datos considerados históricos y los datos considerados activos.  Se definen así los dos bloques de migración estipulados en el MCI (bloque de migración de histórico y bloque de migración de activo).

Este mecanismo puede ser una fecha de corte, un proceso de verificación de datos migrados, o cualquier sistema que se considere fiable para garantizar que el 100% de los datos previstos son migrados y que ninguno es migrado dos o más veces.

La decisión al respecto se recogerá en la Definición del Alcance de las Migraciones.

[ACT-PRE-MIGR-2] Implementar extracción y transformación de datos

El N3 del sistema origen, en colaboración con el hospital debe preparar los procesos de extracción y transformación de información de acuerdo a la Definición del Alcance de migración acordada, y conforme a las estructuras de datos que marque el migrador de datos específico del sistema a implantar.

[ACT-PRE-MIGR-3] Verificar procesos de extracción y transformación de datos

Una vez ha finalizado la implementación de los procesos de extracción de datos del sistema origen, se ha de verificar que la información generada a partir de dichos procesos de extracción cumple con las restricciones, normativas, acuerdos y peculiaridades recogidas para cada entidad en el entregable “MIGR02. Definición Alcance de las Migraciones”, subsanándose aquellos aspectos que no cumplan con dichos criterios.

[ACT-PRE-MIGR-4] Establecer subconjunto de datos para las pruebas de migración unitarias

Para la elección de los registros incluidos en las pruebas de migración unitarias (catas), es recomendable hacer una selección de datos especialmente complejos (pacientes con historia clínica especialmente compleja, tratamientos complejos, agendas con múltiples variantes, etc.) que cubran la mayor parte de las casuísticas posibles.

La experiencia nos indica que 100 es un número suficiente de pacientes a ser incluidos en esta selección con toda su información asociada, si bien será el centro el que decida este número en la medida en la que estime oportuno para garantizar la cobertura de todas las casuísticas.

Los datos elegidos en esta actividad son sobre los que posteriormente se ejecutará el “MIGR04. Plan de pruebas de migración Cualitativas.”.

Esta información será incluida en el entregable “MIGR02. Definición Alcance de las Migraciones” completando su contenido.

Área de Integración

[ACT-PRE-INTE-1] Solicitar implementación de procesos de integración a terceros

El Modelo Corporativo de Implantaciones marca unos escenarios de integración concretos basados en los Contratos de Integración facilitados por la OTI. Estos Contratos de Integración son de obligado cumplimiento por todos los sistemas a integrar.

Si bien la mayoría de sistemas existentes en Andalucía ya tienen experiencia en procesos de integración con los sistemas del SAS, es probable que entren en juego sistemas que aún no hayan pasado por este proceso.

Para estos, la fase de Preimplantación será clave para la adecuación de sus sistemas a los Contratos de Integración, y dado que estos procesos suelen ser costosos en tiempo y esfuerzo para el proveedor, es importante el comienzo de los mismos con suficiente antelación para garantizar su finalización en tiempo y forma de cara al inicio de la fase de Implantación.

Para dicha fase, todos los sistemas departamentales y terceros que se integren con el sistema a implantar deberán estar desplegados en el entorno de pruebas para la certificación de los procesos de integración, por lo que al inicio de esta fase se solicita formalmente a cada uno de los proveedores involucrados la implementación de dichos procesos de integración.

[ACT-PRE-INTE-2] Establecer fecha límite disponibilidad desarrollos integraciones

Una vez conocido el alcance de las integraciones en el ámbito de la implantación, y definido en la fase de reingeniería de procesos el entregable “GEST07. Cronograma conjunto implantación”, podremos analizar las fechas límite para disponer de los desarrollos que sea necesario llevar a cabo sobre procesos de integración.

Estas fechas límites en todo caso deberán ser acordes a los hitos y compromisos marcados de forma conjunta entre el centro y el equipo de implantación, cumpliendo el cronograma conjunto de implantación.

Sin embargo, dependencias específicas en el centro con otros proyectos, con necesidad de equipamiento, con convivencia con otros procesos de mejora e implantación, pueden hacer necesario restringir aún más los hitos máximos definidos en el cronograma de implantación para garantizar por un lado los compromisos adquiridos en este, y por otro, la convivencia del proyecto de implantación con otros procesos relacionados en el hospital y el día a día.

[ACT-PRE-INTE-3] Desarrollar integración de terceros

Esta actividad será implementada por los proveedores relacionados con los sistemas de información a integrar, con el apoyo de la OTI y del equipo de implantación.

En la misma, deberán implementarse los cambios y desarrollos necesarios para cumplir con el alcance acordado en la fase de reingeniería de procesos, y en las fechas límites acordadas.

[ACT-PRE-INTE-4] Desplegar en PRE integraciones de terceros

Una vez los desarrollos relativos a las integraciones son finalizados, estos deberán ser desplegados en los entornos preproductivos para poder ser verificados antes de su puesta en producción.

En los entornos preproductivos debe disponerse de una instancia de cada uno de los sistemas a integrar, de manera que las pruebas de integración puedan ser realistas  y completas.

Los despliegues de estos desarrollos deberán hacerse igualmente cumpliendo con los compromisos del “GEST07. Cronograma conjunto implantación” y con las fechas límite acordadas en la actividad “[P-PRE-INTE-2] Establecer fecha límite disponibilidad desarrollos integraciones”.

Área de Sistemas e Infraestructuras

[ACT-PRE-SIST-1] Publicar accesos al Sistema para formación

Al comienzo de la fase de preimplantación, y una vez se haya hecho entrega de los entornos preproducitvos, deberá llevarse a cabo la publicación de los accesos a estos sistemas por los usuarios finales de forma que quede preparado para la realización de las pruebas de integración, de migración, sesiones de formación, etc.

[ACT-PRE-SIST-2] Certificar requisitos hardware mínimos puestos de usuario

El centro deberá verificar que todos los puestos de usuario cumplen con los requisitos mínimos establecidos para cada uno de los sistemas de información que entran en juego en el proceso de implantación.

Suelen especificarse requisitos relativos a:

• Sistema operativo
• Memoria RAM
• Espacio en disco duro
• Capacidad del procesador
• Resolución mínima de pantalla.
• Versión de java o .NET
• Navegadores
• Versión de cada uno de los navegadores
• Visores de pdf
• etc

Sobre los equipamientos que no cumplan con dichos requisitos, el centro deberá establecer un Plan de sustitución y mejora de equipamiento que deberá ejecutarse antes del comienzo de la fase de Arranque, de manera que se garantice que tras el mismo, los usuarios que comiencen a utilizar el nuevo sistema, no se encuentran con incidencias relativas a estos requisitos.

Dado que esta tarea es tediosa, se recomienda comenzar con ella lo antes posible.  Para llevarla a cabo suele ser necesario:

• Hacer o actualizar un inventario de equipamiento.
• Analizar las características de cada uno de los elementos del inventario con respecto a las características mínimas requeridas.
• Analizar el % de equipamiento que no cumplen con los mismos, categorizando las diferentes necesidades y categorizando las mismas según criticidad.
• Gestionar la adquisición del equipamiento necesario para dar cobertura a las carencias detectadas.
• En caso de imposibilidad de dar cobertura al 100% de las carencias, establecer un plan de priorización de la cobertura de las mismas, garantizando en primera instancia el funcionamiento de los ámbitos más críticos del hospital y las siguientes áreas a continuación.

[ACT-PRE-SIST-3] Certificar infraestructura necesaria para formación

En esta actividad, se procederá a la verificación en el centro de los requisitos mínimos necesarios que han de cumplir los equipos cliente puestos a disposición de la formación de manera que se garantice que esta pueda llevarse a cabo sin problemas.

Incluye todos los requisitos que deberá cumplir un puesto cliente normal más aquellos adicionales que se estimen convenientes para poder ser utilizados en sesiones de formación (cañones de proyección, orientación de las mesas, pizarras, etc).

[ACT-PRE-SIST-4] Creación maqueta Master de entornos

Una de las actividades en las que suele colaborar el n3 y los equipos de implantación en las primeras instalaciones de un nuevo producto de envergadura es en la creación de una maqueta master para los entornos de los sistemas a desplegar.

Esta maqueta consiste en una serie de imágenes de SO que construye Sistemas con el objetivo de tener preparada la base operacional donde poder desplegar a posteriori los productos involucrados. En dicha maqueta se seleccionan e intervienen elementos como el sistema operativo, la versión de java, el contenedor de aplicaciones a utilizar, los elementos de balanceado, la versión de la base de datos, etc.

[ACT-PRE-SIST-4.1] Soporte creación bbdd

Sistemas procede a la creación de la maqueta de la estructura de las bases de datos que se utilizarán con los sistemas involucrados. Para dicha creación, contará con el apoyo del n3 que colaborará en la resolución de dudas sobre dicho proceso y que posteriormente procede a la validación del resultado final obtenido.

[ACT-PRE-SIST-4.2] Soporte creación master software base servidor

Sistemas procede a la creación de la maqueta del software base de los servidores a utilizar con los sistemas involucrados. Para dicha creación, contará con el apoyo del n3 que colaborará en la resolución de dudas sobre dicho proceso y que posteriormente procede a la validación del resultado final obtenido.

En dicha maqueta se seleccionan e intervienen elementos como el sistema operativo, la versión de java, el contenedor de aplicaciones a utilizar, los elementos de balanceado, etc.

[ACT-PRE-SIST-4.3] Validación creación bbdd

Sistemas procede a la creación de la maqueta de la estructura de las bases de datos que se utilizarán con los sistemas involucrados. Para dicha creación, contará con el apoyo del n3 que colaborará en la resolución de dudas sobre dicho proceso y que posteriormente procede a la validación del resultado final obtenido.

[ACT-PRE-SIST-4.4] Validación creación master software base servidor

Sistemas procede a la creación de la maqueta del software base de los servidores a utilizar con los sistemas involucrados. Para dicha creación, contará con el apoyo del n3 que colaborará en la resolución de dudas sobre dicho proceso y que posteriormente procede a la validación del resultado final obtenido.

En dicha maqueta se seleccionan e intervienen elementos como el sistema operativo, la versión de java, el contenedor de aplicaciones a utilizar, los elementos de balanceado, etc.

[ACT-PRE-SIST-4.5] Validación básica funcional creación entorno

Por último el n3 participará y apoyará en la validación básica funcional de la creación de dichas maquetas master. Para ello, estas serán desplegadas en algún entorno de verificación, y sobre las mismas se ejecutarán una serie de pruebas encaminadas a detectar posibles fallos iniciales en la concepción y elaboración de la misma.

[ACT-PRE-SIST-5] Entrega de entornos PRE

El Modelo Corporativo Marco de Implantaciones (MCMI) define una serie de entornos necesarios para implementar con garantías y seguridad todas las actividades involucradas en un proceso de implantación.

El número y características de los entornos viene marcada por las actividades que deben poder ejecutarse paralelamente en el tiempo y la interdependencia entre estas.

Los entornos comúnmente utilizados son:

• Entornos en Preproducción.
  • Los entornos en preproducción suelen  tres entornos diferenciados.
  • Entorno de RP
    • Generalmente cualquier entorno disponible que se facilita de forma provisional al equipo de implantación para que pueda llevar a cabo las sesiones de reingeniería de procesos.
    • Puede ser cualquier entorno que disponga de la versión del aplicativo a implantar, con independencia de que pertenezca o esté parametrizado para otro centro.
    • Una vez finalizados los procesos de reingeniería de procesos, este entorno puede ser liberado.
  • Entorno de FOR
    • Entorno que será utilizado por el equipo de implantación para la preparación del proceso de implantación.
    • En él se llevarán a cabo actividades relacionadas con la certificación de los procesos de integración, sesiones de formación, certificación de circuitos, etc.
  • Entorno de VAL
    • Este entorno es exclusivamente necesario para llevar a cabo la validación de los procesos de migración.
    • Dadas las características de los procesos de migración y la necesidad existente de contar con un entorno con la garantía de que los datos contenidos no sean modificados ni corrompidos durante el proceso de validación, es necesario contar con un entorno estanco que ofrezca estas facilidades.
    • De esta forma podremos validar los procesos de migración de datos garantizando que los resultados obtenidos son correctos y no han sido corrompidos.
    • Utilizar un entorno diferenciado permite paralelizar en el tiempo la ejecución de los procesos de migración de datos con los procesos de integración y formación.
    • En caso de no poder disponer de un entorno de validación de los procesos de migración (VAL), será obligatorio secuenciar este bloque de actividades para que sean ejecutadas antes o después de las actividades de integración, formación o cualquier otro bloque que pueda modificar datos, pero nunca en paralelo, pues no existiría el concepto de garantía de integridad de datos necesario para llevar a cabo la validación de los procesos de migración.
    • Una vez finalizada la validación de los procesos de migración, este entorno puede ser liberado.
• Entorno de PRO.
  • Entorno en producción con datos reales utilizado o que será utilizado por los usuarios finales una vez finalizado el proceso de implantación.
  • Para el entorno de producción podemos encontrarnos en el escenario de que dicho escenario ya esté disponible y puesto en producción (entornos centralizados, etc.). En este caso, el proceso de entrega del entorno no implicará despliegue físico y bastará con facilitar los datos de conexión, gestionar la apertura de comunicaciones, etc.

[ACT-PRE-SIST-5.1] Entregar entornos para PRE

Para la realización de la fase de Preimplantación se debe disponer de los correspondientes entornos preproductivos con la versión más actualizada del aplicativo a implantar sobre el que se puedan llevar a cabo las sesiones de formación, la preparación de los procesos de migración e integración, etc.

Estos entornos deben estar con la suficiente antelación para que el equipo de implantación pueda verificar que funciona correctamente de cara a la ejecución de las actividades que de estos entornos dependen.

La entrega de estos entornos será entregada igualmente conforme al cronograma estratégico de las implantaciones y de acuerdo a las fechas solicitadas en el proceso [P-APS-SIST-2.4] Solicitar despliegue de entornos.

[ACT-PRE-SIST-5.2] Gestionar apertura de comunicaciones para entornos PRE

La entrega de un entorno específico conlleva la gestión correspondiente de los canales de comunicación hacia y desde el mismo.

De esta forma, toda entrega de un entorno, aunque existiera previamente, debe ir acompañada con la gestión de las reglas de comunicación, apertura de firewalls, etc. necesarios para que los sistemas incluidos en el entorno puedan comunicarse entre sí según ha especificado el fabricante del aplicativo, y a su vez, estos puedan comunicarse con el resto de sistemas que vayan a conformar el ecosistema de aplicaciones involucradas (sistemas corporativos centralizados, departamentales, sistemas de terceros, aplicaciones distribuidas, etc.).

En el apartado “7.1.2.3 [P-APS-SIST-2.2] Gestionar apertura de comunicaciones para entornos de RP” más atrás puede obtener más información con respecto a este tema.

En relación específica a este proceso, deberá gestionarse la apertura de comunicaciones necesarias para los entornos Preproductivos solicitados y que serán utilizado durante la fase de Preimplantación e Implantación.

[ACT-PRE-SIST-5.3] Verificar entrega de los entornos para PRE

Una vez recepcionado los entornos preproductivos, el equipo de implantación deberá verificar que el entorno funciona conforme a sus expectativas y cumple con las funcionalidades necesarias para llevar a cabo las actividades de la fase de Preimplantación e Implantación.

Si bien la verificación será llevada a cabo por el equipo de implantación, la responsabilidad de que este proceso se pase con éxito recae en Sistemas STIC, quien entrega el entorno y deberá ejecutar las acciones necesarias para garantizar que el entorno facilitado sea totalmente operativo.

[ACT-PRE-SIST-5.4] Precarga con juego de datos del entorno de PRE

Para poder llevar a cabo las actividades de implantación que utilizan como base los entornos de preproducción, en ocasiones es necesario precargar estos con un juego de datos más escueto o mas completo que permita la simulación de determinados escenarios o casos de prueba o que permita la asimilación a un entorno real (en cuanto a nº de registros) para ejecutar determinados planes de pruebas de estrés, de sistemas, etc.

Las acciones necesarias para precargar este juego de datos quedarán enmarcadas en esta actividad.

[ACT-PRE-SIST-6] Ejecutar Plan de Pruebas de Sistemas (pruebas estrés del producto)

Una vez dispongamos de un entorno preproductivo con el juego de datos que necesitemos cargado, si dentro del alcance de la implantación se incluye la ejecución de un plan de pruebas de sistemas, deberemos proceder a ello en el marco de esta actividad.

El objetivo de este plan es definir todas las pruebas de sistemas o de estrés necesarias para verificar que no existen problemas de rendimiento, cuellos de botella, eficiencia, tiempos de respuesta, etc.

De este plan, obtendremos un entregable con el resultado de dichas pruebas.

[ACT-PRE-SIST-7] Entrega de entornos PRO

El Modelo Corporativo Marco de Implantaciones (MCMI) define una serie de entornos necesarios para implementar con garantías y seguridad todas las actividades involucradas en un proceso de implantación.

El número y características de los entornos viene marcada por las actividades que deben poder ejecutarse paralelamente en el tiempo y la interdependencia entre estas.

Los entornos comúnmente utilizados son:

• Entornos en Preproducción.
  • Los entornos en preproducción suelen  tres entornos diferenciados.
  • Entorno de RP
    • Generalmente cualquier entorno disponible que se facilita de forma provisional al equipo de implantación para que pueda llevar a cabo las sesiones de reingeniería de procesos.
    • Puede ser cualquier entorno que disponga de la versión del aplicativo a implantar, con independencia de que pertenezca o esté parametrizado para otro centro.
    • Una vez finalizados los procesos de reingeniería de procesos, este entorno puede ser liberado.
  • Entorno de FOR
    • Entorno que será utilizado por el equipo de implantación para la preparación del proceso de implantación.
    • En él se llevarán a cabo actividades relacionadas con la certificación de los procesos de integración, sesiones de formación, certificación de circuitos, etc.
  • Entorno de VAL
    • Este entorno es exclusivamente necesario para llevar a cabo la validación de los procesos de migración.
    • Dadas las características de los procesos de migración y la necesidad existente de contar con un entorno con la garantía de que los datos contenidos no sean modificados ni corrompidos durante el proceso de validación, es necesario contar con un entorno estanco que ofrezca estas facilidades.
    • De esta forma podremos validar los procesos de migración de datos garantizando que los resultados obtenidos son correctos y no han sido corrompidos.
    • Utilizar un entorno diferenciado permite paralelizar en el tiempo la ejecución de los procesos de migración de datos con los procesos de integración y formación.
    • En caso de no poder disponer de un entorno de validación de los procesos de migración (VAL), será obligatorio secuenciar este bloque de actividades para que sean ejecutadas antes o después de las actividades de integración, formación o cualquier otro bloque que pueda modificar datos, pero nunca en paralelo, pues no existiría el concepto de garantía de integridad de datos necesario para llevar a cabo la validación de los procesos de migración.
    • Una vez finalizada la validación de los procesos de migración, este entorno puede ser liberado.
• Entorno de PRO.
  • Entorno en producción con datos reales utilizado o que será utilizado por los usuarios finales una vez finalizado el proceso de implantación.
  • Para el entorno de producción podemos encontrarnos en el escenario de que dicho escenario ya esté disponible y puesto en producción (entornos centralizados, etc.). En este caso, el proceso de entrega del entorno no implicará despliegue físico y bastará con facilitar los datos de conexión, gestionar la apertura de comunicaciones, etc.

[ACT-PRE-SIST-7.1] Entregar entornos para PRO

Para la realización de la fase de Implantación y para la preparación de la fase de Arranque se debe disponer del correspondiente entorno de producción con la versión más actualizada del aplicativo a implantar. Sobre él se llevará a cabo la migración de datos históricos en la fase de implantación, el despliegue de configuraciones y parametrizaciones, o el despliegue de los desarrollos de integración entre otros.

Estos entornos deben estar con la suficiente antelación para que el equipo de implantación pueda comenzar sin bloqueo la configuración y preparación de los mismos de cara a la ejecución de las actividades que de este entorno dependen.

La entrega de estos entornos será entregada igualmente conforme al cronograma estratégico de las implantaciones y de acuerdo a las fechas solicitadas en el proceso [P-APS-SIST-2.4] Solicitar despliegue de entornos.

[ACT-PRE-SIST-7.2] Gestionar apertura de comunicaciones para entornos PRO

La entrega de un entorno específico conlleva la gestión correspondiente de los canales de comunicación hacia y desde el mismo.

De esta forma, toda entrega de un entorno, aunque existiera previamente, debe ir acompañada con la gestión de las reglas de comunicación, apertura de firewalls, etc. necesarios para que los sistemas incluidos en el entorno puedan comunicarse entre sí según ha especificado el fabricante del aplicativo, y a su vez, estos puedan comunicarse con el resto de sistemas que vayan a conformar el ecosistema de aplicaciones involucradas (sistemas corporativos centralizados, departamentales, sistemas de terceros, aplicaciones distribuidas, etc.).

En el apartado “7.1.2.3 [P-APS-SIST-2.2] Gestionar apertura de comunicaciones para entornos de RP” más atrás puede obtener más información con respecto a este tema.

En relación específica a este proceso, deberá gestionarse la apertura de comunicaciones necesarias para el entorno de Producción solicitado y que serán utilizado durante la fase de Implantación y posteriores.

[ACT-PRE-SIST-7.5] Nivelar versión a la última disponible

[ACT-PRE-SIST-7.3] Verificar entrega de los entornos para PRO

Una vez recepcionado el entorno de producción, el equipo de implantación deberá verificar que el entorno funciona conforme a sus expectativas y cumple con las funcionalidades necesarias para llevar a cabo las actividades de la fase de Preimplantación e Implantación.

Si bien la verificación será llevada a cabo por el equipo de implantación, la responsabilidad de que este proceso se pase con éxito recae en Sistemas STIC, quien entrega el entorno y deberá ejecutar las acciones necesarias para garantizar que el entorno facilitado sea totalmente operativo.

[ACT-PRE-SIST-7.4] Activar modo transición en el entorno de producción

Es necesario tener en cuenta que especialmente durante la fase de implantación, se lleva a cabo una de las labores más tediosas y costosas que es la relacionada con la asignación de permisos y perfiles a todos los usuarios sobre el entorno en producción.

Eso quiere decir, que en el momento que se publiquen dichos accesos, si no se aplican medidas adicionales, los usuarios podrían entrar en el sistema en producción, pudiendo tergiversar la información migrada en histórico y pudiendo suponer un problema de cara a la migración de los datos activos.

Esta precaución es de aplicación en aquellos procesos de implantación en las que sea necesario llevar a cabo las actividades de migración.

Para ello, si el sistema origen no es el mismo que el nuevo sistema (caso de nivelaciones por ejemplo), llegado este momento deberemos haber activado el modo transición en los sistemas en producción para evitar, mediante gestión de comunicaciones, etc, el acceso al sistema

 Área de Análisis y Explotación de Datos

 [ACT-PRE-AYED-1] Adecuar los procesos de explotación de datos afectados

El centro deberá comenzar las actividades de desarrollo planificadas. Para esta labor, contará con el apoyo de miembros del equipo de implantación especializados en el área funcional y en el conocimiento del modelo de datos de las estaciones, quienes asesorarán a los desarrolladores del centro, dentro del alcance del Plan de Transferencia del Conocimiento, sobre la forma más idónea de obtener la información que en cada caso sea demandada.

Al finalizar esta fase, es conveniente que el centro haya finalizado las actividades de desarrollo, para que estas puedan ser verificadas durante la siguiente fase con datos reales.

Implantación

 Área Formación

[ACT-IMP-FORM-1] Impartir sesiones de formación

[ACT-IMP-FORM-1.1] Impartir sesiones de formación a Formadores

[ACT-IMP-FORM-1.2] Impartir sesiones de formación a usuarios finales

[ACT-IMP-FORM-1.3] Semana de contingencia

[ACT-IMP-FORM-2] Generar Informe final actividades de formación

Área de Migración

[ACT-IMP-MIGR-1] Validar el proceso de migración (catas) en PRE

[ACT-IMP-MIGR-1.1] Extraer y transformar los datos para las catas

[ACT-IMP-MIGR-1.2] Validar los ficheros o soportes de datos obtenidos

[ACT-IMP-MIGR-1.3] Cargar los datos activos en PRE

[ACT-IMP-MIGR-1.4] Ejecutar el Plan de Pruebas de migración Cualitativas

[ACT-IMP-MIGR-1.5] Ejecutar el Plan de Pruebas de migración cuantitativas

[ACT-IMP-MIGR-3] Simulación migración en PRO

[ACT-IMP-MIGR-3.3] Configuración entorno de PRO prueba simulación de migración

[ACT-IMP-MIGR-3.4] Simulación de migración en PRO y medición de tiempos

[ACT-IMP-MIGR-2] Migrar datos pasivos en PRO

[ACT-IMP-MIGR-2.1] Extraer y transformar los datos históricos

[ACT-IMP-MIGR-2.2] Validar los ficheros o soportes de datos obtenidos

[ACT-IMP-MIGR-2.3] Cargar los datos históricos en PRO

[ACT-IMP-MIGR-2.4] Ejecutar el Plan de Pruebas de migración cuantitativas

[ACT-IMP-MIGR-2.5] Generar ficheros pasivo para sistemas terceros integrados

[ACT-IMP-MIGR-2.6] Actualizar información en sistemas terceros integrados

Área de Integración

[ACT-IMP-INTE-1] PRE

[ACT-IMP-INTE-1.1] Ejecutar Plan de Pruebas de conectividad de integraciones (ESB)

[ACT-IMP-INTE-1.2] Ejecutar Plan de Pruebas de conectividad de integraciones (no ESB)

[ACT-IMP-INTE-1.3] Ejecutar Plan de Pruebas funcionales de las integraciones (ESB)

[ACT-IMP-INTE-1.4] Ejecutar Plan de Pruebas funcionales de las integraciones (no ESB)

[ACT-IMP-INTE-2] PRO

[ACT-IMP-INTE-2.1] Desplegar en PRO integraciones de terceros

[ACT-IMP-INTE-2.2] Ejecutar Plan de Pruebas de conectividad de integraciones (ESB)

[ACT-IMP-INTE-2.3] Ejecutar Plan de Pruebas de conectividad de integraciones (no ESB)

[ACT-IMP-INTE-2.4] Ejecutar Plan de Pruebas funcionales de las integraciones (ESB)

[ACT-IMP-INTE-2.5] Ejecutar Plan de Pruebas funcionales de las integraciones (no ESB)

Área de Sistemas e Infraestructuras

[ACT-IMP-SIST-5] Crear snapshot de los sistemas en producción previos (creación bbdd y carga de datos)

[ACT-IMP-SIST-1] Publicar accesos al Sistema en producción

[ACT-IMP-SIST-2] Nivelar sistema a la versión acordada para la implantación

[ACT-IMP-SIST-6] Informar cambios incluidos en la versión

[ACT-IMP-SIST-3] Desplegar sistemas terceros relacionados

[ACT-IMP-SIST-4] Desplegar modificaciones necesarias sobre sistema origen

 Área de Análisis y Explotación de Datos

[ACT-IMP-AYED-1] Validar los procesos de explotación de datos afectados

[ACT-IMP-AYED-2] Publicar los nuevos procesos de explotación de datos

Arranque

Actividades Previas al Arranque

[ACT-ARR-PREV-1.1] Ejecutar verificaciones previas al arranque en entorno origen

Área de Sistemas e Infraestructuras

[ACT-ARR-PREV-2.1] Realizar copias de seguridad de los sistemas destino

[ACT-ARR-PREV-2.2] Verificar que los sistemas están listos para el arranque

[ACT-ARR-PREV-2.3] Deshabilitar acceso a entornos formativos

Actividades de Transición

  Área de Migración

[ACT-ARR-TRAN-2.1] Preparar los sistemas origen para la extracción de datos

[ACT-ARR-TRAN-2.2] Preparar los sistemas destino para la carga de datos

[ACT-ARR-TRAN-2.3] Extraer y transformar los datos activos

[ACT-ARR-TRAN-2.4] Validar los ficheros o soportes de datos obtenidos

[ACT-ARR-TRAN-2.5] Cargar los datos activos en PRO

[ACT-ARR-TRAN-2.6] Ejecutar el Plan de Pruebas de migración cuantitativas

[ACT-ARR-TRAN-2.7] Generar ficheros activo para sistemas terceros integrados

[ACT-ARR-TRAN-2.8] Actualizar información en sistemas terceros integrados

Área de Integración

 [ACT-ARR-TRAN-3.1] Detener mensajería de integraciones obsoletas tras el arranque

 [ACT-ARR-TRAN-3.2] Encolar mensajería de integraciones afectadas durante la fase de transición

  Área de Sistemas e Infraestructuras

[ACT-ARR-TRAN-4.1] Activar modo transición en los sistemas origen

[ACT-ARR-TRAN-4.2] Activar modo transición en los sistemas afectados y en las comunicaciones

[ACT-ARR-TRAN-4.4] Desplegar modificaciones necesarias sobre sistema origen

[ACT-ARR-TRAN-4.3] Realizar copias de seguridad de los sistemas origen

Área de Gestión

[ACT-ARR-TRAN-5.1] Ejecutar Plan de comunicación subfase 5.2 Transición

Actividades de Arranque

Área de Integración

 [ACT-ARR-ARR-2.1] Arrancar procesos de integración de sistemas terceros que arranquen en esta fase

[ACT-ARR-ARR-2.2] Desencolar mensajería de integraciones de sistemas terceros que arranquen en esta fase

[ACT-ARR-ARR-2.6] Configurar módulos corporativos para su integración con el sistema

[ACT-ARR-ARR-2.7] Configurar sistemas terceros para su integración con el sistema

[ACT-ARR-ARR-2.3] Ejecutar Plan de Pruebas funcionales de las integraciones (ESB)

[ACT-ARR-ARR-2.4] Ejecutar Plan de Pruebas funcionales de las integraciones (no ESB)

  Área de Sistemas e Infraestructuras

[ACT-ARR-ARR-3.1] Monitorizar la capacidad y disponibilidad del sistema

[ACT-ARR-ARR-3.2] Activar modo definitivo en los sistemas origen

[ACT-ARR-ARR-3.3] Activar modo Abierto en los sistemas afectados y en las comunicaciones

Área de Gestión

[ACT-ARR-ARR-4.1] Ejecutar Plan de comunicación subfase 5.3 Arranque

[ACT-ARR-ARR-4.4] Recoger elementos desplegados del plan de Transición

[ACT-ARR-ARR-4.5] Comunicar finalización proceso de arranque

Actividades de Post-arranque

Área de Migración

[ACT-ARR-POST-6.17] Preparar los sistemas origen para la extracción de datos

[ACT-ARR-POST-6.18] Preparar los sistemas destino para la carga de datos

[ACT-ARR-POST-6.19] Extraer y transformar los datos activos de los sistemas origen

[ACT-ARR-POST-6.20] Validar los ficheros o soportes de datos obtenidos

[ACT-ARR-POST-6.21] Cargar los datos activos en PRO

[ACT-ARR-POST-6.22] Ejecutar el Plan de Pruebas de migración cuantitativas

[ACT-ARR-POST-6.23] Generar ficheros activo para sistemas terceros integrados

[ACT-ARR-POST-6.24] Actualizar información en sistemas terceros integrados

Área de Integración

[ACT-ARR-POST-5.14] Arrancar procesos de integración de sistemas terceros dependientes que arranquen en esta fase

[ACT-ARR-POST-5.15] Desencolar mensajería de integraciones de sistemas terceros dependientes que arranquen en esta fase

[ACT-ARR-POST-5.16] Configurar módulos corporativos para su integración con el sistema

[ACT-ARR-POST-5.17] Configurar sistemas terceros para su integración con el sistema

[ACT-ARR-POST-5.18] Ejecutar Plan de Pruebas funcionales de las integraciones (ESB)

[ACT-ARR-POST-5.19] Ejecutar Plan de Pruebas funcionales de las integraciones (no ESB)

Área de Gestión

[ACT-ARR-POST-3.1] Ejecutar Plan de comunicación subfase 5.4 Post-Arranque

[ACT-ARR-POST-3.2] Comunicar finalización proceso de post-arranque

Consolidación

Área de Sistemas e Infraestructuras

[ACT-CON-SIST-1] Monitorizar la capacidad y disponibilidad del sistema

Extensión

 [ACT-EXT-FUNC-1] Tareas acordadas para esta fase relativas al área funcional

 Área Formación

 [ACT-EXT-FORM-1] Tareas acordadas para esta fase relativas al área de formación

Área de Migración

[ACT-EXT-MIGR-1] Tareas acordadas para esta fase relativas al área de migraciones

Área de Integración

 [ACT-EXT-INTE-1] Tareas acordadas para esta fase relativas al área de integraciones

Área de Sistemas e Infraestructuras

 [ACT-EXT-SIST-1] Tareas acordadas para esta fase relativas al área de sistemas

 Área de Análisis y Explotación de Datos

 [ACT-EXT-AYED-1] Tareas acordadas para esta fase relativas al área de explotación de datos

Paso a N3