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.

Matriz RASCI

Catálogo de entregables

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

Matriz RASCI

Dependencias

Catálogo de entregables

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

Matriz RASCI

Dependencias

Catálogo de entregables

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

Matriz RASCI

Catálogo de entregables

[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 se podrán 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 se puede encontrar 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.

Matriz RASCI

Catálogo de entregables

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

Matriz RASCI

Dependencias

Catálogo de entregables

[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, se agruparán 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 se encuentran 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.

Matriz RASCI

Dependencias

Catálogo de entregables

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

Matriz RASCI

Dependencias

Catálogo de entregables

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

Matriz RASCI

Dependencias

Catálogo de entregables

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

Matriz RASCI

Dependencias

Catálogo de entregables

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

Esta actividad se divide en tantas actividades como ámbitos se presentan:

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

• [ACT-RP-FUNC-3.3] Facultativos

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

• [ACT-RP-FUNC-3.1] Urgencia

Matriz RASCI

Dependencias

Catálogo de entregables

[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 “.

Matriz RASCI

Dependencias

Catálogo de entregables

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

Matriz RASCI

Dependencias

Catálogo de entregables

[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 (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.

Matriz RASCI

Dependencias

Catálogo de entregables

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

Una vez se disponga de un entorno en el que se ha parametrizado tanto la conectividad como las decisiones funcionales, y una vez se hayan implementado sobre el mismo las modificaciones acordadas al alcance del equipo de implantación, se podrá verificar que el resultado final casa con el esperado y acordado durante la fase de Reingeniería de Procesos. Para verificar todo esto, se ejecutarán las pruebas funcionales definidas en esta actividad. En esta actividad se trata de definir el plan de pruebas funcionales completo que se chequeará durante la fase de implantación.

Matriz RASCI

Dependencias

Catálogo de entregables

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

Matriz RASCI

Dependencias

Catálogo de entregables

 Á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, hay que asegurarse que las tareas incluidas en esta fase son entendidas e interiorizadas por cada uno de sus responsable, en general, del centro.

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

Matriz RASCI

Dependencias

Catálogo de entregables

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

Matriz RASCI

Dependencias

Catálogo de entregables

[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.).

Matriz RASCI

Dependencias

Catálogo de entregables

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

Matriz RASCI

Dependencias

Catálogo de entregables

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

Matriz RASCI

Dependencias

Catálogo de entregables

[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”.

Matriz RASCI

Dependencias

Catálogo de entregables

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

Matriz RASCI

Dependencias

Catálogo de entregables

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

Matriz RASCI

Catálogo de entregables

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

Matriz RASCI

Dependencias

Catálogo de entregables

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

Matriz RASCI

Dependencias

Catálogo de entregables

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

Matriz RASCI

Dependencias

Catálogo de entregables

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

Matriz RASCI

Dependencias

Catálogo de entregables

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

Matriz RASCI

Dependencias

Catálogo de entregables

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

Matriz RASCI

Dependencias

Catálogo de entregables

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

Matriz RASCI

Dependencias

Catálogo de entregables

Área de Gestión

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

Matriz RASCI

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

Matriz RASCI

Dependencias

Catálogo de entregables

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

Matriz RASCI

Dependencias

Catálogo de entregables

[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).

Matriz RASCI

Dependencias

Catálogo de entregables

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

Matriz RASCI

Dependencias

Catálogo de entregables

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

Matriz RASCI

Dependencias

Catálogo de entregables

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

Matriz RASCI

Dependencias

Catálogo de entregables

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

Matriz RASCI

Dependencias

Catálogo de entregables

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.

Matriz RASCI

Dependencias

Catálogo de entregables

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

Matriz RASCI

Dependencias

Catálogo de entregables

Dependencias

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

Matriz RASCI

Dependencias

Catálogo de entregables

 Á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

En esta fase se llevarán a cabo las sesiones de formación marcadas en el Plan de formación y en el calendario de formación.

Es fundamental que los responsables de cada unidad tanto Médicas, de Enfermería, como Administrativas organicen los grupos de usuarios de forma nominal, que deben asistir a la formación para que llegue al mayor porcentaje posible de estos. De este modo es como se ha conseguido un mayor alcance en cuanto a asistentes a las formaciones.

Por el contrario, si los responsables comunican que hay programadas una serie de grupos para el personal al cargo, y se les insta a organizarse sin asignarlos nominalmente, la asistencia será mucho menor de la deseada.

Por último, destacar que es muy recomendable que previo al comienzo de cada sesión de formación, se haga llegar a los formadores aquellas directrices, o mensajes clave que considere la dirección del  centro, que deban transmitirse a los asistentes en cada grupo de formación, para un mejor funcionamiento con los nuevos módulos tras la implantación. Se podrá incidir así exhaustivamente en este tipo de directrices corporativas.

Durante esta fase además se seguirá profundizando en Transferir el Conocimiento a los usuarios expertos de referencia, 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 hospital 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 hospital 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.

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

En esta fase se llevarán a cabo las sesiones de formación marcadas en el Plan de formación y en el calendario de formación.

Es fundamental que los responsables de cada unidad tanto Médicas, de Enfermería, como Administrativas organicen los grupos de usuarios de forma nominal, que deben asistir a la formación para que llegue al mayor porcentaje posible de estos. De este modo es como se ha conseguido un mayor alcance en cuanto a asistentes a las formaciones.

Por el contrario, si los responsables comunican que hay programadas una serie de grupos para el personal al cargo, y se les insta a organizarse sin asignarlos nominalmente, la asistencia será mucho menor de la deseada.

Por último, destacar que es muy recomendable que previo al comienzo de cada sesión de formación, se haga llegar a los formadores aquellas directrices, o mensajes clave que considere la dirección del  centro, que deban transmitirse a los asistentes en cada grupo de formación, para un mejor funcionamiento con los nuevos módulos tras la implantación. Se podrá incidir así exhaustivamente en este tipo de directrices corporativas.

Durante esta fase además se seguirá profundizando en Transferir el Conocimiento a los usuarios expertos de referencia, 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 hospital 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 hospital 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.

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

En esta fase se llevarán a cabo las sesiones de formación marcadas en el Plan de formación y en el calendario de formación.

Es fundamental que los responsables de cada unidad tanto Médicas, de Enfermería, como Administrativas organicen los grupos de usuarios de forma nominal, que deben asistir a la formación para que llegue al mayor porcentaje posible de estos. De este modo es como se ha conseguido un mayor alcance en cuanto a asistentes a las formaciones.

Por el contrario, si los responsables comunican que hay programadas una serie de grupos para el personal al cargo, y se les insta a organizarse sin asignarlos nominalmente, la asistencia será mucho menor de la deseada.

Por último, destacar que es muy recomendable que previo al comienzo de cada sesión de formación, se haga llegar a los formadores aquellas directrices, o mensajes clave que considere la dirección del  centro, que deban transmitirse a los asistentes en cada grupo de formación, para un mejor funcionamiento con los nuevos módulos tras la implantación. Se podrá incidir así exhaustivamente en este tipo de directrices corporativas.

Durante esta fase además se seguirá profundizando en Transferir el Conocimiento a los usuarios expertos de referencia, 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 hospital 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 hospital 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.

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

Es importante dejar planificada una reserva de tiempo de entre 1 y 2 semanas antes del arranque sin planificación prevista de formación debido a que en los últimos días antes del arranque suele ser habitual que deba dirigirse el esfuerzo en otro tipo de actividades.

También suele ser habitual que sea necesario planificar alguna sesión adicional de formación no prevista inicialmente. Utilizaremos esta semana, si no hay otra opción, para este tipo de imprevistos.

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

Una vez finalizadas las sesiones de formación, el equipo de implantación deberá generar un Informe final con el resumen y la información de interés relativa al impacto y efectividad de dichas sesiones para que el centro pueda valorar la ejecución de la misma, así como la potenciar si lo estima oportuno aquellas áreas o aspectos que hayan tenido un peor resultado con la formación planificada.

Este informe contendrá al menos y entre otras, la siguiente información:

• Número de sesiones de formación impartidas
• Número de usuarios convocados por perfil
• Número de usuarios por perfil que asisten y son formados
• % de usuarios formados
• Total de horas de formación impartidas
• Puntuación media en las encuestas de satisfacción en cada una de las unidades didácticas.
• Puntuación media en las encuestas de satisfacción para cada uno de los formadores.

Área de Migración

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

Dentro del elevado número de actividades que componen al área de conocimiento de migraciones durante la fase de implantación (más de cien) es importante tener en cuenta una serie de apreciaciones.

La primera hace referencia a la problemática asociada al movimiento de un elevado número de registros (del orden de millones) y el coste en tiempo de estas operaciones de gran envergadura. A este respecto, el primer objetivo de esta área es la verificación de que los procesos de extracción de datos del HIS origen son adecuados y funcionan correctamente. Esto suele necesitar de un proceso iterativo de verificación hasta conseguir que el resultado obtenido sea el esperado.

Llevar a cabo este tipo de procesos iterativos con la totalidad de los datos a migrar, es un proceso tan pesado que puede suponer un riesgo en el cumplimiento de la planificación marcada y consecuentemente para el cumplimiento de la fecha de arranque.

A esto se une que en un proceso de validación cualitativo de datos es inviable validar el Plan de Pruebas de Migración sobre el conjunto completo de datos a migrar. La media de datos verificados en procesos de implantación no superó en ningún caso los datos asociados a 200 pacientes, siendo la media inferior a 100.

Por ello, para llevar a cabo el proceso de validación es suficiente con disponer de los datos migrados referente a un número de pacientes en dicho orden. A este proceso lo denominamos “catas”. Utilizar el conjunto completo de datos para la carga en el entorno de validación y validar así los procesos de extracción y migración de datos es una decisión que no aportaría beneficio frente a las catas y si añade elementos de riesgo para el cumplimiento de los compromisos.

Para ello, utilizaremos el subconjunto de datos seleccionado durante la fase de preimplantación en el proceso “[P-PRE-MIGR-4] Establecer subconjunto de datos para las pruebas de migración unitarias”.

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

Una vez implementados y verificados los procesos de extracción de datos del sistema origen durante la fase de preimplantación, llevaremos a cabo la validación completa del proceso de migración en los entornos preproductivos antes de proceder a la migración del histórico de datos sobre producción.

Para ello es necesario como decimos disponer de los procesos de extracción de datos así como de la selección de la cata de datos que utilizaremos para dichas pruebas.

La utilización de una cata de datos en lugar del juego completo de datos permite eliminar un riesgo elevado sobre todo en entornos con mucha información. Este riesgo está relacionado con el volumen de datos y las reiteraciones necesarias para afinar o validar los procesos de extracción de datos.

Suele ser normal que el proceso de validación de las migraciones no se lleve a cabo en la vuelta inicial, sino que por el contrario, se detecten anomalías o detalles a corregir que deban volver a ser implementados sobre los procesos de extracción de datos, dando lugar a la necesidad de una nueva extracción posterior de datos del sistema origen.

Si para estas reiteradas extracciones utilizamos un juego de datos completo muy grande, dado que este tipo de extracciones consumen una gran cantidad de horas de máquina, corremos el riesgo de saturar la planificación consumiendo fácilmente la holgura de las tareas relacionadas con el área de migraciones.

Para evitar este riesgo es por lo que en lugar de utilizar el juego completo de datos se utiliza una cata especialmente seleccionada. Esto permite que la extracción de datos del sistema origen no se demore en exceso, y que sea viable repetir el proceso de extracción de datos cuantas veces sea posible hasta afinar y validar el proceso completo de migración de datos.

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

Una vez extraída la información, el responsable de su extracción debe verificar que los ficheros o soportes de datos obtenidos cumplen con las restricciones acordadas y no existe anomalía ni en su formato ni en su contenido.

Para ello, contrastará la información contenida en dichos soportes con la información original existente en el sistema origen.

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

Una vez los ficheros han sido extraídos y validados por el proveedor, el equipo de implantación procederá a su carga en el entorno preproductivo del nuevo sistema de información, haciendo uso para ello de las herramientas de migración proporcionadas por el fabricante, así como de las guías y manuales de migración correspondientes.

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

En el entorno de preproducción ejecutaremos el proceso de migración de catas y validación cuantas veces sea necesario hasta que el “MIGR04. Plan de pruebas de migración Cualitativas.” sea pasado satisfactoriamente.

Igualmente haremos con el “MIGR05. Plan de pruebas de migración Cuantitativas”.

Pasaremos por tanto ambos planes de pruebas en este entorno.

Este plan de prueba, debe ser ejecutado por personal de referencia funcional en el centro para verificar la validez de los procesos de migración.

Una vez el proceso es validado cualitativa y cuantitativamente mediante la validación de catas, se procederá a la migración de datos históricos en su totalidad, y no antes.

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

En el entorno de preproducción ejecutaremos el proceso de migración de catas y validación cuantas veces sea necesario hasta que el “MIGR05. Plan de pruebas de migración Cuantitativas” sea pasado satisfactoriamente, de igual forma que hicimos con el “MIGR04. Plan de pruebas de migración Cualitativas.”

Pasaremos por tanto ambos planes de pruebas en este entorno.

Este plan de prueba, será ejecutado por el equipo de implantación con la ayuda y soporte para su validación de los responsables TIC y los referentes funcionales del centro.

Una vez el proceso es validado cualitativa y cuantitativamente mediante la validación de catas, se procederá a la migración de datos históricos en su totalidad, y no antes.

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

En determinados escenarios de implantación, debido al volumen de datos involucrados y la incertidumbre sobre el tiempo necesario para la ejecución de determinadas tareas de la planificación de la fase de implantación y sobre todo de la fase de arranque, es necesario llevar a cabo de forma previa una simulación de los procesos de migración sobre el entorno real en el que posteriormente se cargarán los datos definitivos.

Esta simulación nos dará información valiosa para poder planificar de la forma más efectiva la fase de arranque y en concreto la subfase de Transición, ayudando así a cumplir el objetivo de minimizar el tiempo de ejecución de dicha fase, en la que los usuarios finales no dispondrán de sistemas de información.

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

Para la ejecución de la simulación del proceso de migración en PRO, suele ser necesario llevar a cabo una serie de parametrizaciones y configuraciones que nos permitan aislar el sistema de inferencias externas, nos ayuden a discriminar los datos que forman parte del proceso de simulación y los que no, etc.

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

En este paso, procederemos ya sí a la ejecución de la simulación de dicha migración en PRO y sobre todo a la medición de los tiempos de ejecución de cada uno de los pasos involucrados.

Esta simulación nos dará información valiosa para poder planificar de la forma más efectiva la fase de arranque y en concreto la subfase de Transición, ayudando así a cumpir el objetivo de minimizar el tiempo de ejecución de dicha fase, en la que los usuarios finales no dispondrán de sistemas de información.

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

En este momento, se marca una separación temporal que limita la ejecución de determinadas actividades en el centro, desde dicho momento, hasta el arranque del nuevo sistema, dado que ya dispondremos del snapshot de datos del sistema origen para comenzar la migración de datos históricos.

Estos datos, declarados “históricos” deben permanecer en todo momento invariables, lo que supone que es primordial garantizar que no se puede hacer ninguna acción sobre el sistema origen que permita modificar un dato incluido en este conjunto estático, ni directa ni indirectamente (fusiones de pacientes, etc.).

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

Los datos para la migración del histórico deben extraerse no del sistema en producción sino del snapshot de datos obtenido al comienzo de esta fase durante la ejecución de la actividad “[ACT-IMP-SIST-5] Crear snapshot.

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

Una vez extraída la información, el responsable de su extracción debe verificar que los ficheros o soportes de datos obtenidos cumplen con las restricciones acordadas y no existe anomalía ni en su formato ni en su contenido.

Para ello, contrastará la información contenida en dichos soportes con la información original existente en el sistema origen.

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

Una vez los ficheros han sido extraídos y validados por el proveedor, el equipo de implantación procederá a su carga en el entorno de producción del nuevo sistema de información, haciendo uso para ello de las herramientas de migración proporcionadas por el fabricante, así como de las guías y manuales de migración correspondientes.

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

En el entorno de producción no verificaremos cualitativamente los datos, dado que ya se hizo en preproducción y se pasó el “MIGR04. Plan de pruebas de migración Cualitativas.” satisfactoriamente.

La variación entre las pruebas de migración en entornos preproductivos con catas especialmente seleccionadas y las pruebas de migración en entornos productivos es el volumen de información.

Por ello, en producción, solo se ejecutará el “MIGR05. Plan de pruebas de migración Cuantitativas”, cuyo objetivo es verificar que cuantitativamente el número de registros que fluye por cada uno de los pasos del proceso de migración es idéntico, y que por tanto, no se están quedando registros atrás.

Este plan de prueba, será ejecutado por el equipo de implantación con la ayuda y soporte para su validación de los responsables TIC y los referentes funcionales del centro.

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

Una vez hemos migrado los datos pasivos al nuevo sistema de información, y hemos llevado a cabo las correspondientes validaciones sobre dicho proceso, podemos proceder a la ejecución de los procesos de extracción de datos del sistema para la generación de los ficheros con la información que necesitemos facilitar a sistemas terceros para que estos puedan sincronizar su posición y su información con la que tiene el nuevo sistema con el que deberan convivir.

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

Una vez recibidos los ficheros con el pasivo por parte del soporte de los sistemas de información terceros que los necesiten, estos deberán proceder a actualizar la información de sus sistemas con la incluida en dichos ficheros.

Área de Integración

[ACT-IMP-INTE-1] PRE

En esta fase, las actividades principales en el entorno de PRE van encaminadas a verificar que los procesos de integración con todos los agentes involucrados se ejecutan correctamente (módulos del nuevo sistema, módulos centralizados, departamentales, sistema origen, sistemas de terceros, etc.).

Para ello, se llevará a cabo la ejecución del Plan de Pruebas de Integración, de cuyo resultado dependerán las acciones correctoras a ejecutar sobre cada elemento involucrado hasta  que se certifique la correcta comunicación según los Contratos de Integración definidos.

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

Una vez dispongamos de un entorno preproductivo con los desarrollos de integración desplegados, deberemos ejecutar en primera instancia el “INTE04. Plan de Pruebas de Conectividad de las integraciones” definido en el proceso “[P-RP-INTE-3] Definir Plan de Pruebas de conectividad de integraciones”.

El objetivo de este plan es definir todas las pruebas de conectividad origen-destino necesarias para verificar que no existen problemas de conexión, cortafuegos, accesibilidad entre la dirección ip origen, y la dirección ip destino, puerto y protocolo destino.

De este plan, en esta actividad solo verificaremos los aspectos relacionados con las integraciones corporativas a través de ESB, pues dependen de la relación y disponibilidad de recursos terceros de la OTI, etc.

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

En esta actividad, completaremos la ejecución del “INTE04. Plan de Pruebas de Conectividad de las integraciones” comenzado en la actividad anterior, centrándonos en este caso en todas aquellas pruebas de integración que no involucren a la mensajería corporativa ESB (web services, acceso a vistas, dblinks, etc).

Los recursos requeridos en este caso para llevar a cabo las pruebas estarán más relacionados con sistemas en todo caso que con la OTI.

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

Una vez dispongamos de un entorno preproductivo con los desarrollos de integración desplegados, y en el que hemos verificado que no existen problemas de conectividad que impidan llevar a cabo correctamente las integraciones, deberemos ejecutar el “INTE05. Plan de Pruebas funcionales de las integraciones” definido en el proceso “[P-RP-INTE-4] Definir Plan de Pruebas funcionales de las integraciones”.

Una vez garantizada la base de conectividad necesaria por tanto, procederemos a verificar que funcionalmente los sistemas integrados se comportan como debieran.

De este plan, en esta actividad solo verificaremos los aspectos relacionados con las integraciones corporativas a través de ESB, pues dependen de la relación y disponibilidad de recursos terceros de la OTI, etc.

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

En esta actividad, completaremos la ejecución del “INTE05. Plan de Pruebas funcionales de las integraciones” comenzado en la actividad anterior, centrándonos en este caso en todas aquellas pruebas de integración que no involucren a la mensajería corporativa ESB (web services, acceso a vistas, dblinks, etc).

Los recursos requeridos en este caso para llevar a cabo las pruebas estarán más relacionados con sistemas en todo caso que con la OTI.

Finalizado con éxito este plan de pruebas, podremos afirmar que los desarrollos de integración se han implementado correctamente y pueden ser pasados al entorno de producción.

[ACT-IMP-INTE-2] PRO

Se incluyen en las actividades incluidas en este apartado todas las actividades de esta fase relacionadas con los entornos de PRO.

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

Tras finalizar la verificación de los procesos de integración en PRO, se deberá proceder a su despliegue en producción.

OJO, deben ser desplegados pero no ejecutados, siendo de vital importancia mantener en todo momento la integridad del sistema en producción a pesar de la nueva incorporación de funcionalidades.

Es por ello, que en producción como veremos en las dos próximas actividades, antes del arranque (fase de implantación) solo llevaremos a cabo pruebas de conectividad entre los sistemas con los nuevos circuitos de integración, dado que la funcionalidad de las mismas ha sido verificada en PRE.

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

Es de vital importancia mantener en todo momento la integridad del sistema en producción a pesar de la nueva incorporación de funcionalidades llevada a cabo en la actividad anterior.

Es por ello, que en producción, antes del arranque (fase de implantación) solo llevaremos a cabo pruebas de conectividad entre los sistemas con los nuevos circuitos de integración, dado que la funcionalidad de las mismas ha sido verificada en PRE.

El objetivo de este plan es definir todas las pruebas de conectividad origen-destino necesarias sobre los entornos de producción ara verificar que no existen problemas de conexión, cortafuegos, accesibilidad entre la dirección ip origen, y la dirección ip destino, puerto y protocolo destino.

De este plan, en esta actividad solo verificaremos los aspectos relacionados con las integraciones corporativas a través de ESB, pues dependen de la relación y disponibilidad de recursos terceros de la OTI, etc.

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

En esta actividad, completaremos la ejecución del “INTE04. Plan de Pruebas de Conectividad de las integraciones” comenzado en la actividad anterior, centrándonos en este caso en todas aquellas pruebas de integración que no involucren a la mensajería corporativa ESB (web services, acceso a vistas, dblinks, etc).

Los recursos requeridos en este caso para llevar a cabo las pruebas estarán más relacionados con sistemas en todo caso que con la OTI.

Finalizado con éxito este plan de pruebas, podremos afirmar que los desarrollos de integración se han desplegado correctamente en producción y están listos para comenzar a funcionar en la fase de arranque.

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

Una vez dispongamos de un entorno preproductivo con los desarrollos de integración desplegados, y en el que hemos verificado que no existen problemas de conectividad que impidan llevar a cabo correctamente las integraciones, deberemos ejecutar el “INTE05. Plan de Pruebas funcionales de las integraciones” definido en el proceso “[P-RP-INTE-4] Definir Plan de Pruebas funcionales de las integraciones”.

Una vez garantizada la base de conectividad necesaria por tanto, procederemos a verificar que funcionalmente los sistemas integrados se comportan como debieran.

De este plan, en esta actividad solo verificaremos los aspectos relacionados con las integraciones corporativas a través de ESB, pues dependen de la relación y disponibilidad de recursos terceros de la OTI, etc.

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

En esta actividad, completaremos la ejecución del “INTE05. Plan de Pruebas funcionales de las integraciones” comenzado en la actividad anterior, centrándonos en este caso en todas aquellas pruebas de integración que no involucren a la mensajería corporativa ESB (web services, acceso a vistas, dblinks, etc).

Los recursos requeridos en este caso para llevar a cabo las pruebas estarán más relacionados con sistemas en todo caso que con la OTI.

Finalizado con éxito este plan de pruebas, podremos afirmar que los desarrollos de integración se han implementado correctamente y pueden ser pasados al entorno de producción.

Á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)

De forma previa al comienzo de las actividades de migración de los datos históricos es necesario disponer de una fotografía fija de los datos  a migrar. Es por ello que en esta actividad se deberá crear una copia del sistema origen en producción.

En este momento, se marca una separación temporal que limita la ejecución de determinadas actividades en el centro, desde dicho momento, hasta el arranque del nuevo sistema, dado que ya dispondremos del snapshot de datos del sistema origen para comenzar la migración de datos históricos.

Estos datos, declarados “históricos” deben permanecer en todo momento invariables, lo que supone que es primordial garantizar que no se puede hacer ninguna acción sobre el sistema origen que permita modificar un dato incluido en este conjunto estático, ni directa ni indirectamente (fusiones de pacientes, etc.).

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

En los últimos días de la fase de implantación, existiendo ya entregado  el entorno de producción, deberá llevarse a cabo la publicación de los accesos a estos sistemas por los usuarios finales de forma que quede preparado para la puesta en producción durante la fase de Arranque.

Es muy importante que se garantice que los usuarios finales no pueden entrar en el sistema en producción antes del momento de arranque para lo que se habrá llevado a cabo la actividad “[P-PRE-SIST-7.4] Activar modo transición en el entorno de producción”.

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

Suele ser habitual en procesos de implantación de larga duración que durante la ejecución de la misma se produzca la entrega de nuevas versiones del producto por parte de los n3.

De cara a la preparación del arranque de la implantación, será conveniente analizar si es conveniente llevar a cabo el proceso de arranque con estas nuevas versiones porque supongan un beneficio (corrección de incidencias, implementación de funcionalidad esperada, etc) o si por el contrario el cambio no es conveniente porque desvirtua la preparación de los trabajos para el arranque sobre la versión anterior, siendo el riesgo mayor que el beneficio y por tanto es conveniente usar la versión estable anterior.

Una vez llevado a cabo este análisis y tomada la decisión correspondiente, si se opta por la nivelación del sistema, será conveniente gestionar su nivelación con Sistemas STIC con la suficiente antelación. Es clave que exista tiempo suficiente tras la nivelación para verificar que los trabajos de preparación llevados a cabo hasta la fecha no pierden integridad, evolucionando los mismos en caso necesario.

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

Cada vez que se despliegue una nueva versión a un entorno es necesario informar a cges de la existencia de esta versión, así como de los cambios incluidos en la misma y los grupos de entornos en los que se va a desplegar (PRE, PRO, etc)

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

De cara al arranque suele ser común que no solo se desplieguen las aplicaciones previstas en el plan de arranque, sino que junto a estas, y como parte de la adecuación de los sistemas existentes en el centro, se programe la activación de nuevos circuitos o nuevos sistemas de información que sustituyan a otros obsoletos en el nuevo escenario.

Estos sistemas deben ser desplegados en fase de implantación de cara a la preparación del momento de arranque.

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

En la actividad “[ACT-IMP-FUNC-3.1] Implementar modificaciones necesarias sobre sistema origen” se implementaron las modificaciones que eran necesarias sobre el sistema origen, siendo validadas las mismas en la actividad “[ACT-IMP-FUN

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

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

El centro tendrá en esta fase la oportunidad de certificar que los desarrollos que implementó en la fase de Preimplantación, para la adecuación al nuevo sistema de los procesos propios de extracción de datos y cálculo de indicadores, arrojan los resultados esperados, y estos, coinciden con los obtenidos anteriormente a partir del sistema original.

Para ello, esta actividad deberá ejecutarse con posterioridad a la migración de los datos correspondientes al proceso de Validación de la migración, disponiendo así de un de juego de datos reales con los que llevar a cabo las comprobaciones.

Tras la misma deberán disponerse en producción de los nuevos procesos de explotación de datos.

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

Por último, una vez validados los procesos de explotación de datos en el proceso “[ACT-IMP-GEST-1] Dar Seguimiento y Control a los Trabajos del Proyecto”, podremos proceder a la publicación a los usuarios finales de la.

Arranque

Actividades Previas al Arranque

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

En esta actividad de la subfase de pre-arranque se incluyen todas aquellas actividades encaminadas a realizar las verificaciones previas necesarias sobre el  entorno origen necesarias para garantizar que se encuentre, en el último momento, en la situación correcta para que la siguiente subfase de transición pueda comenzar. 

Estas actividades se realizarán las veces que se estimen oportuno durante las horas y minutos previos al comienzo de la subfase de transición con el objetivo de que si a última hora existen datos o configuraciones o registros que no cumplen con las condiciones necesarias para comenzar la transición, sean detectados y subsanados antes de dicho momento.

Por supuesto, además de ejecutarse horas antes del comienzo de la subfase de transición, estas verificaciones han de hacerse como última acción de esta subfase de actividades previas al arranque, y siempre justo en el último instante antes del comienzo de la sufbase de transición. Detectamos así situaciones incorrectas de último momento.

Las verificaciones a realizar están estrechamente ligadas con el negocio involucrado en  la implantación. A modo de ejemplo, verificaciones típicas que nos encontramos en el ámbito asistencial por ejemplo son las siguientes:

• Verificación de que todos los usuarios a migrar dispongan de NUHSA, dado que este hecho es un elemento básico en este ámbito y no se puede tratar a un usuario o paciente en ningún sistema de información si no dispone de este identificador.

Área de Sistemas e Infraestructuras

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

Antes del comienzo de la fase de transición y que comiencen las actividades que modificarán los sistemas destino hasta su puesta en producción, podemos comenzar a realizar la copia de seguridad de dichos entornos.

El objetivo de esta copia es que dispongamos de una copia del entorno de partida como elemento básico para la ejecución de una hipotética marcha atrás en el proceso de implantación.

En aquellos escenarios en los que el sistema a implantar no esté a disposición de los usuarios finales antes del proceso de implantación porque se trate de despliegue de nuevos sistemas(y no de despliegue de nuevos evolutivos), si tenemos la certeza y garantía de que los sistemas no son accesibles por los usuarios finales, podemos adelantar la realización de estas copias de seguridad a periodos anteriores (por ejemplo la noche anterior como parte de las copias de seguridad planificadas que pueda ejecutar sistemas y siempre verificando con estos).

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

En el ámbito de esta actividad, llevaremos a cabo todas las acciones necesarias para verificar que, antes de comenzar las actividades efectivas de esta subfase, estamos en condiciones de poder comenzar. Se trata pues de chequeos, verificaciones y comprobaciones de última hora para garantizar que el proceso se puede comenzar sin problemas.

Ejemplos típicos suelen ser la verificación de que todos los involucrados están preparados y a la escucha, de que los sistemas de información y entornos involucrados se encuentran levantados y con buena conectividad, que se dispone de todas las credenciales necesarias para la ejecución del proceso, etc.

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

Entre las lecciones aprendidas durante la ejecución de muchas implantaciones se encuentra una que tiene relación directa con esta actividad.

Normalmente en los procesos de implantación, en la fase de implantación se facilita a los usuarios finales acceso a entornos de PRE que se utilizan para dar formación, posibilitar las pruebas y realización de ejercicios por parte de los usuarios finales, etc.

Suele se más común de lo deseable que tras la puesta en producción de los nuevos sistemas, y una vez que se informa a los usuarios de que ya pueden comenzar a utilizar el nuevo sistema, estos, dado que conocen la dirección y las credenciales del entorno de formación, confundan a este con el verdadero entorno en producción, bien por confusión o bien por no diferenciar que puedan existir dos entornos homólogos con diferente utilidad.

Por ello, como elemento preventivo ante este tipo de situaciones, dado que la introducción de información real en entornos de formación suele dar muchos problemas en la atención al usuario y mucha inseguridad del operador en relación al nuevo sistema, que evidentemente no funciona como el de producción, se establece como conveniente llevar a cabo esta actividad.

Dicha actividad consiste básicamente en deshabilitar el acceso a los entornos de PRE (formación, validación, etc.) al comienzo de la fase de transición y siempre antes de la puesta en producción del nuevo sistema y su comunicación a los usuarios finales.

De esta forma, ante una posible equivocación de los usuarios finales en los momentos iniciales tras el arranque, si intenta acceder a los entornos erróneos no le va a ser posible por lo que detectará que no es el correcto si el resto de compañeros pueden entrar y él no.

De esta forma podrá o solventar el problema y dirigirse al entorno correcto, o al menos solicitar incidencia al respecto para que los técnicos de implantación le puedan explicar la situación y que se estaba intentando acceder a entornos incorrectos.

Días después de la puesta en producción (se propone al menso 7 días después) se puede volver a habilitar los accesos a los entornos de formación si estos son necesarios para nuevas acciones formativas, etc.

Actividades de Transición

  Área de Migración

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

En esta actividad procederemos a realizar todas aquellas actividades que sean necesario ejecutar sobre el sistema origen para que se pueda comenzar a extraer datos de este. Este tipo de actividades pueden ser la creación de elementos de esquema temporales que apoyen la extracción, apertura de comunicaciones temporales, cambios en la configuración para mejorar el rendimiento, etc.

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

De forma parecida a lo que ocurre en la actividad anterior con los sistemas origen, suele ser necesario en ocasiones preparar los entornos destino antes de poder comenzar a migrar datos sobre el mismo. Esto suele pasar cuando se comparten por ejemplo entornos de migración e instancias de los productos migradores, etc.

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

Los datos para la migración del activo deben extraerse del sistema en producción, a diferencia de los datos pasivos o históricos, que debían extraerse del snapshot de datos obtenido al comienzo de la fase de implantación durante la ejecución de la actividad “[ACT-IMP-SIST-5] Crear snapshot.

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

Una vez extraída la información, el responsable de su extracción debe verificar que los ficheros o soportes de datos obtenidos cumplen con las restricciones acordadas y no existe anomalía ni en su formato ni en su contenido.

Para ello, contrastará la información contenida en dichos soportes con la información original existente en el sistema origen.

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

Una vez los ficheros han sido extraídos y validados por el proveedor, el equipo de implantación procederá a su carga en el entorno de producción del nuevo sistema de información, haciendo uso para ello de las herramientas de migración proporcionadas por el fabricante, así como de las guías y manuales de migración correspondientes.

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

En el entorno de producción no verificaremos cualitativamente los datos (OJO, no confundir con el Plan de Pruebas de Aceptación del sistema (funcionales), que sí se lleva a cabo), dado que ya se hizo en preproducción y se pasó el “MIGR04. Plan de pruebas de migración Cualitativas.” satisfactoriamente.

La variación entre las pruebas de migración en entornos preproductivos con catas especialmente seleccionadas y las pruebas de migración en entornos productivos es el volumen de información.

Por ello, en producción, solo se ejecutará el “MIGR05. Plan de pruebas de migración Cuantitativas”, cuyo objetivo es verificar que cuantitativamente el número de registros que fluye por cada uno de los pasos del proceso de migración es idéntico, y que por tanto, no se están quedando registros atrás.

Este plan de prueba, será ejecutado por el equipo de implantación con la ayuda y soporte para su validación de los responsables TIC y los referentes funcionales del centro.

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

Una vez hemos migrado los datos activos al nuevo sistema de información, y hemos llevado a cabo las correspondientes validaciones sobre dicho proceso, podemos proceder a la ejecución de los procesos de extracción de datos del sistema para la generación de los ficheros con la información que necesitemos facilitar a sistemas terceros para que estos puedan sincronizar su posición y su información con la que tiene el nuevo sistema con el que deberan convivir.

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

Una vez recibidos los ficheros con el activo por parte del soporte de los sistemas de información terceros que los necesiten, estos deberán proceder a actualizar la información de sus sistemas con la incluida en dichos ficheros.

Área de Integración

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

En este momento, una vez que ya nos encontramos dentro de la fase de transición, y se ha procedido a activar el modo de transición en los entornos originales y en los nuevos a implantar, podemos proceder a parar todos aquellos circuitos de integración que vayan a quedar obsoletos y deban dejar de funcionar tras la implantación.

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

Para aquellos circuitos de integración que si vayan a seguir funcionando tras el proceso de implantación, se procede en este momento a encolar la mensajería (tanto en origen como en el ESB de integración, ws, ficheros, etc) de forma que esta pueda ser liberada y tratada una vez finalice la fase de transición. Evitamos así que se pierda esta mensajería y que se gestione correctamente (con cierto delay), manteniendo coherente la situación de sincronía entre los entornos involucrados.

  Área de Sistemas e Infraestructuras

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

El modo transición consiste en configurar los sistemas de información de forma que su información no sea modificable por ninguna vía no controlada, de manera que pasemos a tener un sistema de información estanco, y con garantías de mantener una foto estable con la que trabajar.

Si un proceso de actualización o implantación no necesita de un entorno estanco y puede hacer por tanto las modificaciones en vivo, no sería necesario esta actividad, ejecutándose sin las garantías que ofrece la misma.

Para ello, suele ser necesario tomar medidas con respecto a:

• Evitar que pueda entrarse en el sistema y modificar datos a través de la interfaz de usuario.
• Evitar que puedan procesarse modificaciones a través de circuitos de integración.
• Evitar que pueda alterarse el sistema debido a la ejecución de demonios que ejecuten tareas de forma periódica.
• En general evitar cualquier vía de modificación de datos sobre el sistema que no sea estrictamente los controlados relacionados con el proceso de implantación (migración de datos, parametrización de la BD, etc.).

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

De forma análoga a lo que ocurre con los sistemas origen, es necesario normalmente garantizar un entorno controlado para los sistemas afectados a implantar o actualizar.

El modo transición consiste en configurar los sistemas de información de forma que su información no sea modificable por ninguna vía no controlada, de manera que pasemos a tener un sistema de información estanco, y con garantías de mantener una foto estable con la que trabajar.

Si un proceso de actualización o implantación no necesita de un entorno estanco y puede hacer por tanto las modificaciones en vivo, no sería necesario esta actividad, ejecutándose sin las garantías que ofrece la misma.

Para ello, suele ser necesario tomar medidas con respecto a:

• Evitar que pueda entrarse en el sistema y modificar datos a través de la interfaz de usuario.
• Evitar que puedan procesarse modificaciones a través de circuitos de integración.
• Evitar que pueda alterarse el sistema debido a la ejecución de demonios que ejecuten tareas de forma periódica.
• En general evitar cualquier vía de modificación de datos sobre el sistema que no sea estrictamente los controlados relacionados con el proceso de implantación (migración de datos, parametrización de la BD, etc.).

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

Una vez los sistemas de información origen se encuentran en modo transición, pueden desplegarse sobre el mismo cualquier modificación, actualización o adaptación que sea necesario en el proceso de implantación para que se adapte a su nueva situación tras el arranque, que puede ser desde pasar a modo solo lectura, a pasar a ser un departamental con otro rol, dejar activa solo determinada funcionalidad del mismo restringiendo la ejecución del resto, etc.

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

Una vez que hemos comenzado la fase de transición, y que tenemos garantía de que la información contenidas en los sistemas de información no puede ser modificada por ninguna vía, podemos comenzar a realizar la copia de seguridad de dichos entornos.

El objetivo de esta copia es que dispongamos de una copia del entorno de partida como elemento básico para la ejecución de una hipotética marcha atrás en el proceso de implantación.

En aquellos escenarios en los que el sistema a implantar no esté a disposición de los usuarios finales antes del proceso de implantación porque se trate de despliegue de nuevos sistemas(y no de despliegue de nuevos evolutivos), si tenemos la certeza y garantía de que los sistemas no son accesibles por los usuarios finales, podemos adelantar la realización de estas copias de seguridad a periodos anteriores (por ejemplo la noche anterior como parte de las copias de seguridad planificadas que pueda ejecutar sistemas y siempre verificando con estos).

Área de Gestión

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

El Plan de comunicación define las actividades de comunicación que hay que llevar a cabo en cada fase para coordinar e informar correctamente a todos los involucrados en el proceso de arranque por el método preciso y a través del canal acordado.

En esta actividad ejecutaremos aquellas actividades definidas en el Plan de Comunicación planificadas para ser ejecutadas durante Subfase 5.2 Actividades de 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

En la subfase de arranque, una vez que hemos realizado las verificaciones pertinentes, y con el objeto de poder verificar que los circuitos de integración con los sistemas terceros son correctos antes de dar acceso a los usuarios finales, se procede a arrancar los procesos de integración de aquellos sistemas terceros que arranquen durante esta subfase. Recordemos que pueden arrancar sistemas terceros en la subfase de arranque o bien en la subfase de post-arranque en función de su disponibilidad e impacto que suponga que esta tenga hasta dicha fase los datos estáticos y no actualizados.

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

Por otro lado, una vez activados los procesos de integración con sistemas terceros, procederemos a desencolar la mensajería de integraciones de estos sistemas para los que arranquen en esta fase.

Esto hará que toda la mensajería encolada durante la fase de transición y la fase de arranque comience a ser transmitida por los sistemas de integración y gestionadas por los destinos.

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

Procederemos igualmente en esta fase una vez tenemos preparado los sistemas implantados o actualizados, a configurar los sistemas corporativos centralizados que deban variar su funcionamiento con respecto a las nuevas aplicaciones porque entren en funcionamiento nuevos circuitos que los impacten etc.

Hacemos de esta forma que dichos entornos viren hacia el nuevo escenario y estén perfectamente preparados y alineados con estos antes de dar paso al uso de los sistemas por los usuarios finales.

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

Igualmente suele ser necesario configurar sistemas terceros para variar su funcionamiento con respecto a las nuevas aplicaciones porque entren en funcionamiento nuevos circuitos que los impacten, varien los circuitos existentes, los sistemas involucrados, etc.

Hacemos de esta forma que los entornos terceros que arranquen en esta subfase viren hacia el nuevo escenario y estén perfectamente preparados y alineados con estos antes de dar paso al uso de los sistemas por los usuarios finales.

Los que arranquen en la subfase de actividades de post-arranque serán configurados en dicho momento.

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

Deberemos ejecutar el “INTE05. Plan de Pruebas funcionales de las integraciones” definido en el proceso “[P-RP-INTE-4] Definir Plan de Pruebas funcionales de las integraciones”.

Una vez garantizada la base de conectividad necesaria durante la fase de implantación, procederemos ahora en la fase de arranque a verificar que funcionalmente los sistemas integrados que arrancan en el transcurso de esta subfase se comportan como debieran.

Esto es así porque la realización de pruebas de integración funcionales suelen suponer la modificación, creación y eliminación de registros en los entornos, y su ejecución en el entorno de producción antes de la fase de arranque podría suponer una situación no controlada en el entorno de pro a la hora de ejecutar los procesos de migración de datos.

De este plan, en esta actividad solo verificaremos los aspectos relacionados con las integraciones corporativas a través de ESB, pues dependen de la relación y disponibilidad de recursos terceros de la OTI, etc.

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

En esta actividad, completaremos la ejecución del “INTE05. Plan de Pruebas funcionales de las integraciones” sobre el entorno de PRO  comenzado en la actividad anterior, centrándonos en este caso en todas aquellas pruebas de integración que no involucren a la mensajería corporativa ESB (web services, acceso a vistas, dblinks, etc) para los sistemas integrados que arrancan en el transcurso de esta subfase.

Los recursos requeridos en este caso para llevar a cabo las pruebas estarán más relacionados con sistemas en todo caso que con la OTI.

Finalizado con éxito este plan de pruebas, podremos afirmar que los desarrollos de integración se han implementado correctamente y pueden ser puestos en producción para los sistemas integrados que arrancan en el transcurso de esta subfase.

  Área de Sistemas e Infraestructuras

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

Ya en este momento, antes de dar paso a los usuarios finales, se solicita a sistemas que comience la monitorización de los sistemas y se prepare para la entrada de todos los usuarios de manera que todos los sistemas de vigilancia y control estén arriba y alerta para la detección de posibles problemas de rendimiento, calidad en las comunicaciones o procesado de información, etc.

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

Durante la fase de transición pasabamos los sistemas de información a modo transición, en el que conseguíamos sistemas estancos en un contexto controlado que garantizaba que las actividades de las fase de transición se podían llevar a cabo sin inferencias externas.

Una vez en este punto, finalizada esta necesidad, se procede a restaurar las posibilidades de acceso sobre los sistemas origen, pasándolos en este caso no a la situación que tenían antes del paso a modo transición sino al modo definitivo que tendrán tras el mismo (acceso en modo solo lectura, subconjunto restringido de funcionalidades, etc.).

Para ello, suele ser necesario verificar la situación en la que han de quedar los mismos elementos que modificamos en el paso a modo transición. Estos suelen ser:

• Acceso al sistema y modificación datos a través de la interfaz de usuario.
• Procesado de modificaciones y actualizaciones a través de circuitos de integración.
• Activación de ejecución de demonios que ejecuten tareas de forma periódica.
• En general cualquier vía de modificación de datos sobre el sistema que no fueran los utilizados durante la fase de transición y que deban activarse de cara a la puesta en producción y uso por parte de los usuarios finales.

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

Durante la fase de transición pasábamos los sistemas de información a modo transición, en el que conseguíamos sistemas estancos en un contexto controlado que garantizaba que las actividades de las fase de transición se podían llevar a cabo sin inferencias externas.

Una vez en este punto, finalizada esta necesidad, se procede a restaurar las posibilidades de acceso sobre los sistemas destino, pasándolos a su situación final de acceso.

Para ello, suele ser necesario verificar la situación en la que han de quedar los mismos elementos que modificamos en el paso a modo transición. Estos suelen ser:

• Acceso al sistema y modificación datos a través de la interfaz de usuario.
• Procesado de modificaciones y actualizaciones a través de circuitos de integración.
• Activación de ejecución de demonios que ejecuten tareas de forma periódica.
• En general cualquier vía de modificación de datos sobre el sistema que no fueran los utilizados durante la fase de transición y que deban activarse de cara a la puesta en producción y uso por parte de los usuarios finales.

Área de Gestión

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

El Plan de comunicación define las actividades de comunicación que hay que llevar a cabo en cada fase para coordinar e informar correctamente a todos los involucrados en el proceso de arranque por el método preciso y a través del canal acordado.

En esta actividad ejecutaremos aquellas actividades definidas en el Plan de Comunicación planificadas para ser ejecutadas durante Subfase 5.3 Actividades de Arranque.

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

Para la ejecucion de esta actividad es necesario que previo a la mecanización, se proceda a la recolección y recopilación de los soportes que contienen dicha información por los sitios físicos en los que se haya repartido antes del comienzo de la fase de transición.

Es importante que los usuarios correspondientes hayan registrado en estas plantillas los datos acordados para facilitar posteriormente su mecanización en el nuevo sistema en tiempo, garantizando así el cumplimiento de las estimaciones de momento de arranque. Una insuficiente cumplimentación puede suponer un retraso en este hito

De igual forma es muy importante que se retiren y eliminen el resto de formularios, impresos, etc. de este plan de transición para que no se mecanice más información en este formato temporal.

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

Si bien esta actividad forma parte del Plan de Comunicación, hemos querido reseñarla de forma explícita dada su importancia a la hora de marcar el momento en el que se considera finalizado el proceso de arranque y la consecuencia que ello tiene en que los usuarios finales puedan comenzar a hacer uso de los sistemas de información implantados.

Actividades de Post-arranque

Área de Migración

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

En esta actividad procederemos a realizar todas aquellas actividades que sean necesario ejecutar sobre el sistema origen para que se pueda comenzar a extraer datos de este. Este tipo de actividades pueden ser la creación de elementos de esquema temporales que apoyen la extracción, apertura de comunicaciones temporales, cambios en la configuración para mejorar el rendimiento, etc.

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

De forma parecida a lo que ocurre en la actividad anterior con los sistemas origen, suele ser necesario en ocasiones preparar los entornos destino antes de poder comenzar a migrar datos sobre el mismo. Esto suele pasar cuando se comparten por ejemplo entornos de migración e instancias de los productos migradores, etc.

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

Los datos para la migración del activo deben extraerse del sistema en producción, a diferencia de los datos pasivos o históricos, que debían extraerse del snapshot de datos obtenido al comienzo de la fase de implantación durante la ejecución de la actividad “[ACT-IMP-SIST-5] Crear snapshot.

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

Una vez extraída la información, el responsable de su extracción debe verificar que los ficheros o soportes de datos obtenidos cumplen con las restricciones acordadas y no existe anomalía ni en su formato ni en su contenido.

Para ello, contrastará la información contenida en dichos soportes con la información original existente en el sistema origen.

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

Una vez los ficheros han sido extraídos y validados por el proveedor, el equipo de implantación procederá a su carga en el entorno de producción del nuevo sistema de información, haciendo uso para ello de las herramientas de migración proporcionadas por el fabricante, así como de las guías y manuales de migración correspondientes.

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

En el entorno de producción no verificaremos cualitativamente los datos (OJO, no confundir con el Plan de Pruebas de Aceptación del sistema (funcionales), que sí se lleva a cabo), dado que ya se hizo en preproducción y se pasó el “MIGR04. Plan de pruebas de migración Cualitativas.” satisfactoriamente.

La variación entre las pruebas de migración en entornos preproductivos con catas especialmente seleccionadas y las pruebas de migración en entornos productivos es el volumen de información.

Por ello, en producción, solo se ejecutará el “MIGR05. Plan de pruebas de migración Cuantitativas”, cuyo objetivo es verificar que cuantitativamente el número de registros que fluye por cada uno de los pasos del proceso de migración es idéntico, y que por tanto, no se están quedando registros atrás.

Este plan de prueba, será ejecutado por el equipo de implantación con la ayuda y soporte para su validación de los responsables TIC y los referentes funcionales del centro.

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

Una vez hemos migrado los datos activos al nuevo sistema de información, y hemos llevado a cabo las correspondientes validaciones sobre dicho proceso, podemos proceder a la ejecución de los procesos de extracción de datos del sistema para la generación de los ficheros con la información que necesitemos facilitar a sistemas terceros para que estos puedan sincronizar su posición y su información con la que tiene el nuevo sistema con el que deberan convivir.

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

Una vez recibidos los ficheros con el activo por parte del soporte de los sistemas de información terceros que los necesiten, estos deberán proceder a actualizar la información de sus sistemas con la incluida en dichos ficheros.

Área de Integración

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

En la subfase de arranque, una vez que hemos realizado las verificaciones pertinentes, y con el objeto de poder verificar que los circuitos de integración con los sistemas terceros son correctos antes de dar acceso a los usuarios finales, se procede a arrancar los procesos de integración de aquellos sistemas terceros que arranquen durante esta subfase. Recordemos que pueden arrancar sistemas terceros en la subfase de arranque o bien en la subfase de post-arranque en función de su disponibilidad e impacto que suponga que esta tenga hasta dicha fase los datos estáticos y no actualizados.

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

Por otro lado, una vez activdaos los procesos de integración con sistemas tereros, procederemos a desencolar la mensajería de integraciones de estos sistemas para los que arranquen en esta fase.

Esto hará que toda la mensajería encolada durante la fase de transición y la fase de arranque comience a ser transmitida por los sistemas de integración y gestionadas por los destinos.

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

Procederemos igualmente en esta fase una vez tenemos preparado los sistemas implantados o actualizados, a configurar los sistemas corporativos centrailzados que deban variar su funcionamiento con respecto a las nuevas aplicaciones porque entren en funcionamiento nuevos circuitos que los impacten etc.

Hacemos de esta forma que dichos entornos viren hacia el nuevo escenario y estén perfectamente preparados y alineados con estos antes de dar paso al uso de los sistemas por los usuarios finales.

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

Igualmente suele ser necesario configurar sistemas terceros para variar su funcionamiento con respecto a las nuevas aplicaciones porque entren en funcionamiento nuevos circuitos que los impacten, varien los circuitos existentes, los sistemas involucrados, etc.

Hacemos de esta forma que los entornos terceros que arranquen en esta subfase viren hacia el nuevo escenario y esten perfetamente preparados y alineados con estos antes de dar paso al uso de los sistemas por los usuarios finales.

Los que arranquen en la subfase de actividades de post-arranque serán configurados en dicho momento.

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

Deberemos ejecutar el “INTE05. Plan de Pruebas funcionales de las integraciones” definido en el proceso “[P-RP-INTE-4] Definir Plan de Pruebas funcionales de las integraciones”.

Una vez garantizada la base de conectividad necesaria durante la fase de implantación, procederemos ahora en la fase de arranque a verificar que funcionalmente los sistemas integrados que arrancan en el transcurso de esta subfase se comportan como debieran.

Esto es así porque la realización de pruebas de integración funcionales suelen suponer la modificación, creación y eliminación de registros en los entornos, y su ejecución en el entorno de producción antes de la fase de arranque podría suponer una situación no controlada en el entorno de pro a la hora de ejecutar los procesos de migración de datos.

De este plan, en esta actividad solo verificaremos los aspectos relacionados con las integraciones corporativas a través de ESB, pues dependen de la relación y disponibilidad de recursos terceros de la OTI, etc.

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

En esta actividad, completaremos la ejecución del “INTE05. Plan de Pruebas funcionales de las integraciones” sobre el entorno de PRO  comenzado en la actividad anterior, centrándonos en este caso en todas aquellas pruebas de integración que no involucren a la mensajería corporativa ESB (web services, acceso a vistas, dblinks, etc) para los sistemas integrados que arrancan en el transcurso de esta subfase.

Los recursos requeridos en este caso para llevar a cabo las pruebas estarán más relacionados con sistemas en todo caso que con la OTI.

Finalizado con éxito este plan de pruebas, podremos afirmar que los desarrollos de integración se han implementado correctamente y pueden ser puestos en producción para los sistemas integrados que arrancan en el transcurso de esta subfase.

Área de Gestión

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

El Plan de comunicación define las actividades de comunicación que hay que llevar a cabo en cada fase para coordinar e informar correctamente a todos los involucrados en el proceso de arranque por el método preciso y a través del canal acordado.

En esta actividad ejecutaremos aquellas actividades definidas en el Plan de Comunicación planificadas para ser ejecutadas durante Subfase 5.4 Actividades de Post-Arranque.

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

En esta actividad, completaremos la ejecución del “INTE05. Plan de Pruebas funcionales de las integraciones” sobre el entorno de PRO  comenzado en la actividad anterior, centrándonos en este caso en todas aquellas pruebas de integración que no involucren a la mensajería corporativa ESB (web services, acceso a vistas, dblinks, etc) para los sistemas integrados que arrancan en el transcurso de esta subfase.

Los recursos requeridos en este caso para llevar a cabo las pruebas estarán más relacionados con sistemas en todo caso que con la OTI.

Finalizado con éxito este plan de pruebas, podremos afirmar que los desarrollos de integración se han implementado correctamente y pueden ser puestos en producción para los sistemas integrados que arrancan en el transcurso de esta subfase.

Consolidación

Área de Sistemas e Infraestructuras

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

Sistemas sigue durante toda la fase de consolidación monitorizando de los sistemas de manera que todos los sistemas de vigilancia y control estén arriba y alerta para la detección de posibles problemas de rendimiento, calidad en las comunicaciones o procesado de información, etc.

Extensión

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

Durante la fase de Extensión s e continuará con los trabajos de ampliación de la implantación acordados en la fase de Implantación que serían postergados hasta este momento, de modo que en este periodo se alcance la implantación total del sistema en el centro

Por tanto, en el ámbito de esta actividad incluiremos todo el desglose de actividades relativas al área de conocimiento funcional que bien porque inicialmente así estaba planificado o bien porque por la ejecución del plan de implantación, para evitar riesgos se postergaron hasta este momento.

Suelen ser actividades típicas:

• Configuración de elementos de listados adicionales
• Configuración de elementos de explotación de datos.
• Parametrización y puesta en marcha de circuitos funcionales secundarios.
• Etc.

 Área Formación

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

Durante la fase de Extensión se continuará con los trabajos de ampliación de la implantación acordados en la fase de Implantación que serían postergados hasta este momento, de modo que en este periodo se alcance la implantación total del sistema en el centro

Por tanto, en el ámbito de esta actividad incluiremos todo el desglose de actividades relativas al área de conocimiento de formación que bien porque inicialmente así estaba planificado o bien porque por la ejecución del plan de implantación, para evitar riesgos se postergaron hasta este momento.

También suele planificarse actividades formativas en esta fase fruto del análisis de los resultados del soporte durante la fase de consolidación en cada uno de los servicios, puntos calientes, colectivos, etc, lo que suele ayudar a detectar posibles problemas de falta de conocimietno del uso de las nuevas aplicaciones o funcionalidades.

Suelen ser actividades típicas:

• Refuerzo de la formación impartida.
• Sesiones específicas de resolución de dudas, etc
• Etc.

Área de Migración

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

Durante la fase de Extensión se continuará con los trabajos de ampliación de la implantación acordados en la fase de Implantación que serían postergados hasta este momento, de modo que en este periodo se alcance la implantación total del sistema en el centro

Por tanto, en el ámbito de esta actividad incluiremos todo el desglose de actividades relativas al área de conocimiento de migración que bien porque inicialmente así estaba planificado o bien porque por la ejecución del plan de implantación, para evitar riesgos se postergaron hasta este momento.

Suelen ser actividades típicas:

• Revisión de migraciones en las que se haya detectado errores menores que se deseen mejorar
• Migración de información histórica o no crítica que no era necesario que estuviera disponible para el momento de arranque
• Etc.

Área de Integración

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

Durante la fase de Extensión se continuará con los trabajos de ampliación de la implantación acordados en la fase de Implantación que serían postergados hasta este momento, de modo que en este periodo se alcance la implantación total del sistema en el centro

Por tanto, en el ámbito de esta actividad incluiremos todo el desglose de actividades relativas al área de conocimiento de integración que bien porque inicialmente así estaba planificado o bien porque por la ejecucion del plan de implantación, para evitar riesgos se postergaron hasta este momento.

Entrarán también dentro de las actividades a realizar dentro de esta fase, la puesta en producción de los procesos de integraciones que no hubiesen sido implementados en tiempo de cara al arranque del nuevo sistema, y que se hubieran planificado para su puesta en producción en esta fase.

Suelen ser actividades típicas:

• Activación de circuitos adicionales de integración.
• Integración de sistemas de proveedores terceros que no llegaran a tiempo al momento de arranque.
• Etc.

Área de Sistemas e Infraestructuras

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

Durante la fase de Extensión se continuará con los trabajos de ampliación de la implantación acordados en la fase de Implantación que serían postergados hasta este momento, de modo que en este periodo se alcance la implantación total del sistema en el centro

Por tanto, en el ámbito de esta actividad incluiremos todo el desglose de actividades relativas al área de conocimiento de sistemas que bien porque inicialmente así estaba planificado o bien porque por la ejecucion del plan de implantación, para evitar riesgos se postergaron hasta este momento.

Suelen ser actividades típicas:

• Sustitución de elementos de electrónica de red
• Modificación de enrutados o segmentación de redes
• Etc.

 Á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

En el ámbito de esta actividad incluiremos todo el desglose de actividades relativas al área de análisis y explotación de datos que bien porque inicialmente así estaba planificado o bien porque por la ejecución del plan de implantación, para evitar riesgos se postergaron hasta este momento.

Paso a N3