Historial de página
...
Área Funcional
[ACT-IMP-FUNC-1] PRE
Se incluyen en las actividades incluidas en este apartado todas las actividades de esta fase relacionadas con los entornos de PRE.
[ACT-IMP-FUNC-1.1] Parametrización de PRE
Procedemos en este bloque de actividades a parametrizar el entorno de preproducción al completo
[ACT-IMP-FUNC-1.1.1] Generación de script y herramientas de parametrización por lotes
[ACT-IMP-FUNC-1.1.2] Testing scripts y herramientas de parametrización por lotes. Cálculo de tamaño de ventana de tiempo necesario
[ACT-IMP-FUNC-1.1.3] Parametrizar conectividad de los entornos en PRE
En determinadas ocasiones, la parametrización de sistemas de información supone una modificación o carga de datos de mucho volumen.
Por poner algunos ejemplos, la parametrización de toda la extensión local de la estructura física en sistemas como la Estación de gestión, la creación de todas las agendas y tramos básicos para los profesionales de un nuevo hospital, etc suelen suponer la parametrización de cientos de elementos.
Para ello, no es viable la parametrización manual de cada uno de ellos por el esfuerzo necesario que ello supondría.
En su lugar, es habitual el apoyo en herramientas de parametrización específicas que ayuden a automatizar dicho proceso de parametrización (ojo, no de migración).
En el ámbito de esta actividad será en el que procederemos a la concepción, diseño y construcción de dichas herramientas (scripts, código java, procesos ETL, etc).
[
[ACT-IMP-FUNC-1.1.
4] Parametrizar funcionalmente los entornos en PRE2] Testing scripts y herramientas de parametrización por lotes. Cálculo de tamaño de ventana de tiempo necesario
Una vez creadas en el paso anterior las herramientas que nos ayudarán a la automatización del proceso de parametrización, estas han de ser previamente probadas y validadas antes de poder dar por bueno el resultado de su ejecución con datos reales.
Testearemos por tanto en esta actividad dichas herramientas.
Como resultado además de dichas pruebas, otro punto importante en esta actividad consiste en obtener y calcular el tamaño de ventana de tiempo necesario para su ejecución. Este dato nos servirá para poder planificar y ajustar correctamente el proceso de parametrización y el proceso de arranque.
[ACT-IMP-FUNC-1.1.
5] Implementar modificaciones sobre el aplicativo en PRE3] Parametrizar conectividad de los entornos en PRE
En esta área habrán de realizarse las parametrizaciones del nuevo sistema, en todos los entornos de preproducción que se utilicen: formación, validación, preproducción, producción, etc.
Basados en anteriores experiencias, se propone llevar a cabo esta parametrización en dos fases. Una primera en la que se realizará la parametrización de conectividad, y una segunda fase en la que esta parametrización será completada con todos aquellos aspectos relacionados con las decisiones funcionales acordadas durante la fase de Reingeniería de Procesos.
Esta escisión, reportará como beneficio directo la optimización de los tiempos de ejecución del resto de actividades dependientes de estas, al facilitarles un sistema en el que es posible realizar los circuitos básicos.
Basado en esta estrategia surgen las dos actividades [ACT-IMP-FUNC-1.1.
6] Verificar modificaciones sobre el aplicativo3] Parametrizar conectividad de los entornos en PRE
y [ACT-IMP-FUNC-1.1.
24]
CertificarParametrizar funcionalmente los
circuitos parametrizadosentornos en PRE
[ACT-IMP-FUNC-1.2.1] Validación del alcance
[ACT-IMP-FUNC-1.2.2] Verificación del alcance. Soporte a las pruebas funcionales
.
En el caso de la presente, el objetivo como decimos es que el entorno sea operativo con las configuraciones por defecto.
Por ello, para llevar a cabo esta actividad no es necesario disponer de la definición de la parametrización específica para el hospital. Bastará disponer del entorno y de la documentación externa relativa a la parametrización del mismos.
Finalizada esta actividad, podremos hacer uso del sistema con la configuración básica por defecto.
[ACT-IMP-FUNC-
2] PRO[ACT-IMP-FUNC-2.1
] Parametrización de PRO[ACT-IMP-FUNC-2.1.
1] Parametrización conectividad de los entornos en PRO[ACT-IMP-FUNC-2.1.2] Trasladar parametrización funcional a PRO
[ACT-IMP-FUNC-2.1.3] Trasladar modificaciones sobre el aplicativo en PRO
4] Parametrizar funcionalmente los entornos en PRE
Una vez disponemos de un entorno ejecutable tras la parametrización de la conectividad llevada a cabo en la anterior actividad, deberemos pasar de un sistema que funciona a un sistema que se comporta con la idiosincrasia y características específicas que el centro demanda.
Es hora por tanto de llevar a cabo la parametrización funcional del mismo. Para ello, si será necesario disponer previamente de la parametrización y los valores acordados para cada elemento en función de los acuerdos funcionales aprobados para el centro.
Una vez realizadas la parametrización de conectividad y funcional, podrá verificarse con el centro que los circuitos funcionales acordados en la Reingeniería de Procesos, efectivamente cumplen los requisitos necesarios para poder utilizar el nuevo sistema. Esto se llevará a cabo en el proceso “[P-IMP-FUNC-1.4] Certificar los circuitos parametrizados en PRE”.
[ACT-IMP-FUNC-3] Sistemas origen[ACT-IMP-FUNC-
31.1.5] Implementar modificaciones
necesarias sobre sistema origen[ACT-IMP-FUNC-3.2] Validar modificaciones necesarias sobre sistema origen
Área Formación
...
sobre el aplicativo en PRE
Aquellos otros acuerdos que se alcanzaron en la Reingeniería de Procesos que estén al alcance y bajo la potestad de ser construidos o implementados por el equipo de implantación (realización o modificación de informes en el caso, decisiones específicas tomadas sobre circuitos funcionales,…) se implementarán en esta fase y serán validados por los responsables correspondientes.
Estas modificaciones fueron acordadas durante la fase de RP, y deben estar recogidas en el entregable “GEST05. Informe final Reingeniería de Procesos” generado durante la ejecución del proceso “[P-RP-GEST-5] Elaborar Informe Reingeniería de Procesos”.
Es importante que todos estos cambios queden recogidos en un Registro de modificaciones, y sean tenidos en cuenta en el contenido de los Planes de Prueba funcionales correspondientes.
Este Registro facilitará igualmente a posteriori la labor de los equipos de n3 del proveedor encargado del mantenimiento de la solución a quien deberá trasladársele dicho registro.
[ACT-IMP-
...
FUNC-1.1
...
.6] Verificar modificaciones sobre el aplicativo en PRE
[ACT-IMP-
...
FUNC-1.2]
...
Certificar los circuitos parametrizados en PRE
Una vez disponemos de un entorno en el que hemos parametrizado tanto la conectividad como las decisiones funcionales, y una vez hemos implementado sobre el mismo las modificaciones acordadas al alcance del equipo de implantación, podremos verificar que el resultado final casa con el esperado y acordado durante la fase de Reingeniería de Procesos.
Para ello, ejecutaremos el “FUNC07. Plan de Pruebas Funcionales de los Circuitos” previamente definido y recogeremos el resultado de dichas pruebas en el entregable “FUNC14. Plan de Pruebas Funcionales de los Circuitos. Registro de ejecución”.
[ACT-IMP-FORM-1.3] Semana de contingencia
[ACT-IMP-FORM-2] Generar Informe final actividades de formación
Área de Migración
[ACT-IMP-MIGR-1] Validar el proceso de migración (catas) en PRE
...
[ACT-IMP-
...
FUNC-1.2
...
.1] Validación del alcance
El objetivo de esta tarea es que el equipo de implantación, una vez parametrizados los entornos, valide que sobre dicho entorno funcionan perfectamente todos los circuitos funcionales y que estos son conformes con todos los acuerdos establecidos durante la fase de reingeniería de procesos.
Es una tarea previa de los equipos de implantación antes de que dichos circuitos sean posteriormente verificados por los responsables funcionales durante la ejecución de la tarea "
[ACT-IMP-MIGR-1.3] Cargar los datos activos en PRE
[ACT-IMP-MIGR-1.4] Ejecutar el Plan de Pruebas de migración Cualitativas
[ACT-IMP-
...
FUNC-1.2.
...
2] Verificación del alcance. Soporte a las pruebas funcionales".
En ningún caso debe procederse a ejecutarse la verificación del alcance por parte de los responsables funcionales sin que previamente exista recogida formalmente el resultado satisfactorio del equipo de implantación al proceso de "Validación de alcance" realizado en esta tarea.
...
[ACT-IMP-
...
FUNC-
...
1.2.
...
2] Verificación del alcance. Soporte a las pruebas funcionales
Durante esta tarea, los respnosanbles funcionales verifican que el funcionamiento y los procesos implementados y parametrizados en las herramientas a implantar son conforme a los acuerdos establecidos y las funcionalidades esperadas del producto.
En esta actividad, el objetivo es que, las mismas pruebas que previamente ya ha debido validar el equipo de implantación en la actividad "[ACT-IMP-
...
FUNC-
...
1.2.
...
1] Validación del alcance" sean ejecutadas en presencia de los responsables funcionales, "verificando" estos que efectivamente el funcionamiento es correcto.
En ningún caso esta actividad ha de suponer el primer encuentro contra una situación anómala que ha todas luces refleje una situación previamente no verificada.
[ACT-IMP-
...
FUNC-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-
...
FUNC-2.1]
...
Parametrización de PRO
Procedemos en este bloque de actividades a parametrizar el entorno de producción al completo.
[ACT-IMP-
...
FUNC-2.1.
...
1]
...
Parametrización conectividad de los entornos en PRO
En esta área habrán de realizarse las parametrizaciones del nuevo sistema, en el entorno de producción.
Basados en anteriores experiencias, como ya hemos comentado anteriormente para los entornos preproductivos, se propone llevar a cabo esta parametrización en dos fases.
- Una primera en la que se realizará la parametrización de conectividad.
- Una segunda fase en la que esta parametrización será completada con todos aquellos aspectos relacionados con las decisiones funcionales acordadas durante la fase de Reingeniería de Procesos.
Esta escisión, reportará como beneficio directo la optimización de los tiempos de ejecución del resto de actividades dependientes de estas, al facilitarles un sistema en el que es posible realizar los circuitos básicos.
Basado en esta estrategia surgen las dos actividades “[P-IMP-FUNC-2.1] Parametrización conectividad de los entornos en PRO” y “[P-IMP-FUNC-2.2] Trasladar parametrización funcional a PRO”.
En el caso de la presente, el objetivo como decimos es que el entorno sea operativo con las configuraciones y flujos acordados para el centro.
Por ello, para llevar a cabo esta actividad si es necesario disponer de la definición de la parametrización específica para el centro, debiendo disponer del entorno y de la documentación externa relativa a la parametrización de mismo.
[ACT-IMP-FUNC-2.1.2] Trasladar parametrización funcional a PRO
Una vez disponemos de un entorno ejecutable tras la parametrización de la conectividad llevada a cabo en la anterior actividad, deberemos pasar de un sistema que funciona a un sistema que se comporta con la idiosincrasia y características específicas que el centro demanda.
Es hora por tanto de llevar a cabo la parametrización funcional del mismo. Para ello, si será necesario disponer previamente de la parametrización y los valores acordados para cada elemento en función de los acuerdos funcionales aprobados para el centro.
Lo que haremos en este caso será trasladar sobre este entorno la parametrización ya llevada a cabo sobre los entornos preproductivos, y ya verificaos sobre estos.
Una vez realizadas la parametrización de conectividad y funcional, que previamente se ha probado ya en PRE en la ejecución de la actividad “[P-IMP-FUNC-1.4] Certificar los circuitos parametrizados en PRE”, tendremos un entorno parametrizado para producción al que solo faltará incorporar las modificaciones realizadas en PRE y recogidas en el entregable “FUNC17. Registro de modificaciones implementadas sobre Sistema Origen”.
[ACT-IMP-FUNC-2.1.3] Trasladar modificaciones sobre el aplicativo en PRO
Una vez implementadas las modificaciones acordadas y al alcance del equipo de implantación sobre los entornos preproducitvos (actividad [ACT-IMP-FUNC-1.3] Implementar modificaciones sobre el aplicativo en PRE”) y una vez certificada la va.
[ACT-IMP-FUNC-3] Sistemas origen
Se incluyen en las actividades incluidas en este apartado todas las actividades de esta fase relacionadas con los entornos de los sistemas origen a sustituir durante el proces de implantación.
[ACT-IMP-FUNC-3.1] Implementar modificaciones necesarias sobre sistema origen
Durante los procesos de sustitución de sistemas de información, en infinidad de situaciones es necesario mantener la convivencia entre el anterior sistema y el nuevo. Esta convivencia puede ir desde un escenario de total funcionamiento de los dos sistemas a un escenario en el que el anterior sistema queda activo para consultas solo en modo lectura.
La adecuación del antiguo sistema al nuevo escenario en el que tendrá que funcionar, supone en multitud de casos la necesidad de llevar a cabo adecuaciones y modificaciones sobre el mismo para permitir el funcionamiento del mismo en esta nueva etapa. Estas adecuaciones son recogidas durante el proceso “[P-PRE-FUNC-6.1] Definir modificaciones necesarias sobre sistema origen”.
De igual forma, normalmente la implementación de mecanismos de extracción de datos que diferencien entre los bloques de información histórico y activa, supone la necesidad de implementar sobre el sistema origen en el que extraeremos los datos determinados cambios que permitan implementar la diferenciación de datos que marca esta política. Estos criterios se definen en el proceso “[P-PRE-MIGR-1] Establecer mecanismo diferenciación histórico vs activo”.
Por último, de la ejecución del proceso”[P-IMP-GEST-5] Definir e implementar el Plan de Transición“ puede surgir la necesidad de implementar determinados cambios en el sistema origen que faciliten el momento de transición del antiguo sistema al nuevo, generalmente durante la noche de arranque. Estos cambios a implementar, recogidos en el entregable “GEST12. Plan de Transición durante el Arranque” deberán ser tenidos en cuenta en este proceso para su implementación.
Es por ello, necesario, durante la fase de implantación, implementar una serie de cambios sobre el sistema origen, según se haya acordado durante el proceso “[P-PRE-FUNC-6.1] Definir modificaciones necesarias sobre sistema origen”, el proceso “[P-PRE-MIGR-1] Establecer mecanismo diferenciación histórico vs activo” y el proceso “GEST12. Plan de Transición durante el Arranque”.
[ACT-IMP-FUNC-3.2] Validar modificaciones necesarias sobre sistema origen
Todas las modificaciones llevadas a cabo sobre el sistema origen deberán ser validadas mediante la ejecución del Plan de pruebas correspondiente, dando como resultado un registro de la ejecución de dicho plan.
Este Plan de pruebas se nutre de los tres procesos anteriormente citados que son susceptibles de definir modificaciones sobre el sistema origen.
Á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.
Área de Gestión
[ACT-IMP-GEST-1] Dar Seguimiento y Control a los Trabajos del Proyecto
Al igual que en la fase de preimplantación, en esta fase continuaremos de forma periódica con las reuniones de seguimiento en el ámbito del centro, cuyo objetivo serán reportar a los responsables del mismo y de la STIC el grado de avance en estas tareas y alertar sobre aquellos puntos que supongan un riesgo global para la finalización de la fase.
[ACT-IMP-GEST-2] Controlar los riesgos
El seguimiento y control de los riesgos es el proceso de identificar, analizar y planificar nuevos riesgos, realizar el seguimiento de los riesgos identificados y los que se encuentran en la lista de supervisión, volver a analizar los riesgos existentes, realizar el seguimiento de las condiciones que disparan los planes para contingencias, realizar el seguimiento de los riesgos residuales, y revisar la ejecución de las respuestas a los riesgos mientras se evalúa su efectividad.
Este es un proceso continuo que se realiza durante el ciclo de vida del proyecto.
Otros elementos que hay que configurar son:
- Verificar que el riesgo, según fue evaluado, no ha cambiado de su estado anterior.
- Las asunciones del proyecto siguen siendo válidas.
[ACT-IMP-GEST-3] Definir el Plan de arranque
Tienen gran importancia todas las actividades relacionadas con la preparación del momento de arranque. La gestión del cambio supone en muchas ocasiones un horizonte difícil de afrontar para muchos usuarios, y si bien, esta gestión comienza desde el mismo inicio de la fase de Reingeniería de Procesos, es ahora el momento de su culminación y de la concienciación profunda de todos los involucrados de lo que a título individual va a suponer el momento de arranque.
Se elaborará para ello una serie de documentos que definirán de forma detallada todo el acontecer en el momento de arranque.
- Cronograma de arranque.
- Se trata de una planificación definida con redistribución de tareas y especificación de fechas al minuto que incluirá todas las tareas a llevar a cabo en la fase de arranque.
- Es muy importante tener en cuenta que este cronograma no solo debe incluir las actividades del equipo de implantación, sino que debe incluir cualquier tarea, sea del perfil responsable que sea (centro, proveedor tercero, usuario experto, etc), que tenga el más mínimo impacto o dependencia en el proceso de arranque.
- Ej.: se para mecanizar un plan de transición es necesario que un celador recoja formularios en papel de controles de enfermería, es necesario que el cronograma refleje una tarea que indique esa necesidad, y las dependencias existentes con ella, pues no se puede mecanizar la información hasta que este recurso haga dicha tarea.
- Las actividades se miden en minutos.
- Dado que la fase de arranque tiene una duración inferior a días, es necesario que todas las estimaciones de duración y esfuerzo necesario para las actividades se especifiquen en minutos, pues un retraso por ej de 30 minutos en una tarea puede impactar en el cronograma de arranque.
- Por ende, el cronograma debe definir las fechas previstas de inicio y finalización de las tareas al minuto.
- Actividades nominales.
- Todas las actividades del cronograma de arranque deben ser asignadas de forma nominal a un RH responsable.
- Debe quedar claro para el momento de arranque, exactamente qué persona es la responsable de llevar a cabo una tarea que ha de ser realizada por un determinado perfil.
- Si indicamos un perfil genérico en su lugar, corremos un alto riesgo de que llegado el momento ninguno de los RH de dicho perfil se responsabilice de su ejecución.
- Esta planificación debe ser distribuida y ser entendible por todos los afectados.
- Se recomienda generar una exportación de la planificación completa y adicionalmente a esta, una planificación filtrada para cada RH involucrado, de forma que este pueda:
- Disponer de la planificación global para poder asimilar los tiempos.
- Tener claramente a mano las tareas que son de su competencia y poder consultar fechas previstas de forma rápida.
- Se recomienda generar una exportación de la planificación completa y adicionalmente a esta, una planificación filtrada para cada RH involucrado, de forma que este pueda:
- Plan de soporte.
- Para su elaboración, se hará un análisis de los puntos calientes para el arranque. Es decir, aquellos puntos en los que es crítico minimizar el impacto y reforzar el soporte para que el proceso de adaptación al nuevo sistema sea rápido y eficaz, y el resto de áreas funcionales del hospital no sufran efectos colaterales adversos relacionados con estos.
- El soporte se organizará en torno a la elección de estos puntos, en los que se hará especial seguimiento al soporte.
- Estos puntos calientes estarán definidos y descritos en el Plan de Arranque.
- El plan de soporte consta de dos matrices relativas a la estructuración del soporte una vez se finalice la fase de arranque.
- Una primera matriz con el nivel de soporte que se acuerde para cada punto caliente en cada día y en cada turno. Define igualmente los turnos de soporte que se van a gestionar.
- Incluye por tanto la siguiente tupla:
- Centro
- Punto caliente
- Día
- Turno
- Nivel de soporte
- Incluye por tanto la siguiente tupla:
- Una segunda matriz, definirá para los valores definidos en la primera, quién será el recurso del equipo de implantación (soporte n0) y quien será el recurso del centro (tutor n0) que darán cobertura a dicho punto caliente en dicho turno.
- De cada uno de los recursos aquí incluidos este documento debe reflejar:
- Nombre y apellidos
- Rol
- Teléfono de contacto
- Correo
- DNI (para la gestión del acceso a las zonas restringidas del centro).
- Empresa
- Por último, el documento denominado Plan de Arranque.
- Jugará un papel clave de cara a la preparación de ese hito. Este documento definirá, de cara a todos los involucrados, toda la información de relevancia para la comprensión de los pasos que serán ejecutados y la respuesta que se espera de cada perfil/rol concreto en la ejecución de los mismos.
- Describirá por tanto de forma comprensible toda la información contenida en los dos anteriores entregables: descripción de las tareas del cronograma, de los puntos calientes, modelo de soporte, etc.
[ACT-IMP-GEST-4] Definir el Plan de comunicació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 la parte final de la fase de Implantación.
[ACT-IMP-GEST-8] Ejecutar Plan de comunicación fase implantación
En esta actividad ejecutaremos aquellas actividades definidas en el Plan de Comunicación planificadas para ser ejecutadas durante la parte final de la fase de Implantación.
[ACT-IMP-GEST-5] Definir e implementar el Plan de Transición
Dentro de la fase de Arranque, se define una subfase denominada “de transición”.
La característica más importante de la misma es que durante su ejecución, los usuarios finales no disponen de sistema de información, dado que será restringido el acceso al sistema original para llevar a cabo la transición, y el nuevo sistema aún no estará disponible para su utilización por los usuarios finales hasta que no finalice la fase de arranque.
Es por ello necesario planificar con antelación cómo se ejecutarán los procesos del hospital en este periodo con el hándicap de no contar con sistema de información.
Existen diferentes alternativas para ello teniendo todas como factor común la necesidad de buscar una alternativa para la consulta y registro de información.
Para la consulta de información, suelen ser una técnica extendida la planificación de la obtención del sistema original de la información a consultar vía descarga o impresión de informes.
Con esta información en la mano, que deberá ser obtenida lo más tarde posible en la subfase de activiades previas al arranque, y justo antes del comienzo de la usbfase de transición, tendremos, aunque sea de forma estática, la foto de información que existía en el sistema origen antes de restringirse el acceso al mismo.
Por otro lado, para la recolección de la información, se deberá planificar el mecanismo alternativo que vaya a ser utilizado. Este puede ser o bien una serie de formularios en papel que deberán ser convenientemente aprobados y distribuidos, o bien sistemas informáticos alternativos como hojas Excel o similar.
El objetivo principal de este plan es definir cómo se va a trabajar durante dicha fase en todos los ámbitos afectados, utilizando para ello las vías alternativas acordadas y así debe quedar reflejado de forma clara, concisa y completa.
Debe tenerse en cuenta que no solo son afectados aquellos sistemas de información a los que se vaya a restringir el acceso a los usuarios finales. También se verán afectados todos los sistemas de información que se integren con estos por cualquier vía para obtener o dar información.
Dado que el sistema original tendrá acceso restringido y no se podrá actualizar en el mismo los cambios que se produzcan durante la fase de transición, los sistemas de información que consulten datos a estos (por ejemplo nuevos episodios, traslados de pacientes de localización, etc) no estarán actualizados con los datos del plan de transición, sino que en su lugar seguirán obteniendo los datos de la foto estática del momento de parada.
Es por ello que es necesario igualmente planificar cómo se va a trabajar durante esta subfase en dichos ámbitos.
Ej.: como se hacen peticiones a laboratorio para un nuevo paciente ingresado en un hospital si estoy actualizando el his que le suministra los ingresos. Como se gestionan las dietas del mismo, etc.
IMPORTANTE: para minimizar el impacto de la subfase de transición se recomienda que se minimice la actividad en el centro que pueda dar lugar a la necesidad de registrar información en los mecanismos del plan de transición . Ej.:
- Si es posible no trasladar de cama a un paciente hasta que se haya arrancado, espérese, evitando así la regularización posterior de esta información sobre el sistema ya actualizado.
- Si no es posible demorarlo, hágase y regístrese sin problemas en el plan de transición.
[ACT-IMP-GEST-6] Precertificación de Entornos
Antes de la ejecución de la fase de Arranque para un proceso de implantación, el entorno de producción sobre el que se ejecutará el mismo debe ser verificado de forma que se garantice que, tras finalizar la fase de implantación, este se encuentra perfectamente parametrizado, configurado y disponibles para ser utilizado por los usuarios finales tras el proceso de arranque.
Esta verificación ha de ejecutarse en las últimas semanas de la fase de implantación.
Esta verificación se llevará a cabo en dos pasos.
En el primero de ellos, será el equipo de implantación que haya ejecutado la fase de implantación los que chequearán la preparación que han hecho del entorno en producción. Para ello completarán el Checklist de verificaciones que en cada caso haya definido el n3 del producto afectado. Este paso es el que se define en este apartado.
En el segundo de ellos, será el n3 correspondiente el que, una vez recibido el Checklist proceda a verificar con las revisiones y comprobaciones que estime oportuno, que el entorno se encuentra perfectamente preparado. En caso de encontrar anomalías al respecto, remitirá Informe de anomalías al equipo de implantación para que sea este el que proceda a su subsanación de forma previa al arranque.
[ACT-IMP-GEST-7] Certificar los entornos
Como comentábamos en la descripción de la actividad anterior, antes de la ejecución de la fase de Arranque para un proceso de implantación, el entorno de producción sobre el que se ejecutará el mismo debe ser verificado de forma que se garantice que, tras finalizar la fase de implantación, este se encuentra perfectamente parametrizado, configurado y disponibles para ser utilizado por los usuarios finales tras el proceso de arranque.
Esta verificación ha de ejecutarse en las últimas semanas de la fase de implantación.
Esta verificación se llevará a cabo en dos pasos.
En el primero de ellos, será el equipo de implantación que haya ejecutado la fase de implantación los que chequearán la preparación que han hecho del entorno en producción. Para ello completarán el Checklist de verificaciones que en cada caso haya definido el n3 del producto afectado.
En el segundo de ellos, será el n3 correspondiente el que, una vez recibido el Checklist proceda a verificar con las revisiones y comprobaciones que estime oportuno, que el entorno se encuentra perfectamente preparado. En caso de encontrar anomalías al respecto, remitirá Informe de anomalías al equipo de implantación para que sea este el que proceda a su subsanación de forma previa al arranque. Este paso es el que se define en este apartado.
[ACT-IMP-GEST-10] Enviar de Peticiones Cambios / Mejoras al Comité de Cambios
[ACT-IMP-GEST-9] HITO. Entrega producto versión definitiva
Arranque
Ancla FasePARR FasePARR
Actividades Previas al Arranque
| FasePARR | |
| FasePARR |
Área Funcional
[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.
Área de Gestión
[ACT-ARR-PREV-3.1] Ejecutar Plan de comunicación subfase 5.1
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.1 Actividades Previas al Arranque.
[ACT-ARR-PREV-3.2] Desplegar elementos del plan de Transición
Como parte del Plan de Transición, y con el objetivo de suplir la no disponibilidad de sistemas de información suele ser necesario poner a disposición de los usuarios finales mecanismos alternativos para el registro de información, que pueden ir desde el reparto por los puntos afectados de plantillas o formularios en papel en el que poder recopilar a mano dicha información, a la publicación de formularios en sistemas alternativos (sharepoint, oracle forms, etc), o incluso a la puesta a disposición de los usuarios de plantillas excel, word, etc.
Durante esta actividad repartiremos dichos elementos, asegurándonos de que todos los usuarios involucrados disponen de los mismos siempre antes del comienzo de la fase de Transición, dado que en dicho momento ya no dispondrán de acceso a los sistemas de información.
| Ancla | ||||
|---|---|---|---|---|
|
Área Funcional
[ACT-ARR-TRAN-1.1] Ejecutar procesos de obtención de datos del sistema origen datos para el Plan de Transición
En relación al Plan de Transición, suele ser habitual que como parte del mismo se planifique la ejecución de determinadas acciones para este momento inicial en la subfase de actividades previas al arranque.
Estas actividades suelen estar encaminadas a recabar información de los sistemas de información que se van a desconectar o evolucionar durante la fase de transición de manera que se pueda trabajar con esa información descargada como herramienta del Plan de transición.
Esta información suele Actividades típicas que suelen hacerse en esta actividad en relación a la ejecución del Plan de Transición son:
- Descarga de información, exportación de datos o impresión de listados con la situación de los elementos críticos justo antes del momento de parada y siempre una vez garantizada la imposibilidad de que los datos sean modificados por terceros mediante la ejecución de la actividad [ACT-ARR-TRAN-4.1] Activar modo transición en los sistemas origen.
- Nos ayuda a poder visualizar dichos datos durante la fase de transición donde no tendremos acceso ni al sistema de información antiguo ni al nuevo.
- Nos ayuda igualmente a verificar cuando se ponga en producción el nuevo sistema, que la foto de partida de los registros incluidos coincide exactamente con el snapshot obtenido del sistema sustituido justo antes de apagarlo.
- Descarga de censos de pacientes, nóminas generadas con su estado, etc.
- Impresión de partes de trabajo: quirófanos, citas agendadas para los próximos días, historias pendientes de servir los próximos días, nóminas pendientes de generar, fármacos a servir en los próximos días, etc.
Se recomienda que como parte del Plan de transición siempre se incluya la descarga de este tipo de información sensible y necesaria para el trabajo para un periodo de tiempo de al menos 7 días contando desde la fecha de arranque. Dispondremos así de un plan B de contingencia con datos con los que trabajar en el caso del fatídico escenario en el que no se disponga de los nuevos sistemas de información hasta x días después de lo previsto.
Á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.
| Ancla | ||||
|---|---|---|---|---|
|
Área Funcional
[ACT-ARR-ARR-1.2] Ejecutar Plan de pruebas de aceptación del sistema
El plan de pruebas de aceptación del sistema debe contener las pruebas generales que se llevarán a cabo la noche del arranque por parte del equipo de implantación y de responsables o referentes del centro en el que esta se lleva a cabo durante la ejecución del proceso.
Este Plan de pruebas NO es por tanto el plan de pruebas funcionales completo que chequearemos durante la fase de implantación. Dicho Plan es el FUNC07. Plan de Pruebas Funcionales de los Circuitos.
El objetivo de este plan es definir aquellas pruebas que se van a llevar a cabo en un periodo de tiempo corto (máximo 1 hora) para verificar que, un sistema que ya ha sido previamente verificado durante la fase de implantación, y tras la migración de todos los datos activos y la activación de los elementos de integración, sigue comportándose correctamente y de igual forma a la que lo hizo durante la ejecución del “FUNC07. Plan de Pruebas Funcionales de los Circuitos” en la fase de implantación.
Durante esta actividad procederemos a la ejecución de dicho plan de pruebas de Aceptación del sistema.
Para ello:
- Determinados perfiles deben ser identificados en la planificación del arranque como responsables de la validación del proceso de arranque.
- Estas figuras, serán las responsables de validar de forma conjunta con el equipo de implantación la correcta ejecución del Plan de Pruebas de Aceptación, que incluye, entre otras actividades, la validación de censos, verificación del correcto funcionamiento de las integraciones en producción, etc.
- Certificarán así la finalización del proceso de arranque, dándose comienzo a la fase de Consolidación en la que el centro comenzará su andadura en el nuevo sistema en entorno real, quedando el sistema original en el estado que en cada caso se acuerde (no disponible, solo disponible en modo lectura para consulta de información, etc.).
[ACT-ARR-ARR-1.3] Ejecutar Plan de pruebas de apagado sobre sistemas origen
De forma análoga al plan de pruebas de aceptación del sistema sobre los sistemas destino, cuando el sistema origen queda disponible tras el arranque y se modifica su comportamiento o alcance, es necesario llevara cabo sobre el mismo una serie de verificaciones rápidas durante la subfase de arranque para garantizar que quedan parametrizados y funcionando de forma correcta antes de dar paso a su utilización por parte de los usuarios finales.
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 origen 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 que queden activos, sigue comportándose correctamente.
[ACT-ARR-ARR-1.5] Actualizar en el sistema la información recogida en los elementos del Plan de Transición
Una de las últimas actividades incluidas en la fase de arranque, y justo antes de dar paso a la utilización del sistema por parte de todos los usuarios finales es la mecanización de la información recogida en sistemas alternativos (papel, excel, formularios electrónicos externos, etc.) en el nuevo sistema ya desplegado y validado.
Antes de la ejecución de esta actividad debemos tener un sistema destino cuya foto de datos coincida al 100% con los datos que tenía el sistema origen en el momento de paso a modo transición (ese snapshot final).
Tras la ejecución de esta actividad, el sistema destino implantado o actualizado debe haber evolucionado su foto de datos reflejando exactamente no la realidad que existía en el momento de parada del sistema origen sino la que existe en tiempo real en el centro, tras trascribir la información recogida temporalmente en estos medios alternativos.
Procederemos por tanto durante esta actividad a mecanizar en el sistema de información destino la información recopilada en los formularios del Plan de Transición.
Á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.
| Ancla | ||||
|---|---|---|---|---|
|
Área Funcional
[ACT-ARR-POST-1.1] Configurar el sistema con posterioridad al arranque
En esta actividad se llevan a cabo todas las parametrizaciones que sea necesario llevar a cabo con el sistema ya en producción y en uso por parte de los usuarios finales.
Á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.
| Ancla | ||||
|---|---|---|---|---|
|
Á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.
Área de Gestión
[ACT-CON-GEST-1] Dar seguimiento y Control a los trabajos del Proyecto
Al igual que en la fase de preimplantación, O implantación, en esta fase continuaremos de forma periódica con las reuniones de seguimiento en el ámbito del centro, cuyo objetivo serán reportar a los responsables del mismo y de la STIC el grado de avance en estas tareas y alertar sobre aquellos puntos que supongan un riesgo global para la finalización de la fase.
Sin embargo, durante esta fase, dada la importancia de contar con información de estado de situación de forma rápida y continua, estas acciones de seguimiento y control se deberán intensificar, de forma que sobre todo los primeros días, estas reuniones deberán convertirse en sesiones de kick-off diarios donde podamos reportar al centro la situación a comienzo del día y las acciones que es necesario llevar a cabo por todos os involucrados para reorientar aquellos elementos que durante la jornada anterior se hubiera llegado a la conclusión que era necesario mejorar o corregir.
[ACT-CON-GEST-2] Informes cuantitativos de actividad
En los primeros días tras el arranque, el objetivo principal del equipo de implantación estará centrado en conseguir que los usuarios comiencen a utilizar los nuevos sistemas de información. Problemas frecuentes en este momento son todos los relacionados con falta de credenciales para los usuarios, reticencia al cambio, etc.
Para cuantificar el nivel de consolidación a este respecto, deberá analizarse diariamente un catálogo de indicadores encaminados a cuantificar el nivel de uso. Los siguientes son ejemplo de indicadores posibles, si bien estos dependen directamente del negocio involucrado:
- Nº de usuarios logados. Como comentamos, los primeros problemas suelen estar relacionados con las credenciales de acceso de los usuarios (olvido de contraseñas, usuario bloqueado por reintentos, etc.). Medir el nº de usuarios logados a diario y contrastarlo con los datos obtenidos durante el funcionamiento normal del hospital nos dará un conocimiento amplio sobre el nivel de utilización de la herramienta por los usuarios de los diferentes servicios. Se deberá ofrecer igualmente un estudio pormenorizado por servicio o colectivo para facilitar la detección de posibles focos de reticencia al cambio. Dirección podrá de esta forma acordar medidas de refuerzo específicas que se unirán al refuerzo de las actividades de soporte por parte de los tutores (del equipo de implantación y del centro).
- Nº acciones de las tipologías principales (ingresos, actualización de expedientes, creación de nóminas, registro de bajas, etc). En general todos aquellos elementos que puedan ser cuantificables y que nos puedan dar el orden de utilización de las nuevas herramientas en los puntos considerados críticos para el funcionamiento de los centros involucrados en la implantación. Ejemplos de algunos ámbitos funcionales son:
- Nº de movimientos historia. Archivo es uno de los puntos clave de cuyo buen funcionamiento depende en cascada el funcionamiento de otras áreas de los centros hospitalarioa.. Es por ello importante detectar posibles focos de riesgo lo antes posible. Un buen indicador sobre el funcionamiento básico de un archivo es el número de movimientos de historia que se llevan a cabo durante la jornada, comparando este dato con los obtenidos previamente durante el funcionamiento normal del hospital y los obtenidos durante los anteriores días de consolidación.
- Nº de ingresos. Al igual que archivo, admisión es otro de los puntos clave a monitorizar. En este caso, un buen indicador sobre el nivel de uso de las aplicaciones asistenciales en este servicio es el relacionado con el conteo de ingresos o de altas. Consideramos el primero en este caso, dado que marca igualmente el inicio del proceso sobre el paciente en el resto del servicio. Si los datos obtenidos no se ajustan a los esperados se procedería a reforzar el tutelado insitu en este servicio.
- Nº de intervenciones programadas. Mide el grado de utilización de los sistemas de información en los servicios de Planificación y programación quirúrgica, por lo que un número bajo de intervenciones programadas respecto a la media normal diaria del hospital puede ser un síntoma de problema a la hora de comenzar a utilizar el nuevo sistema.
- Nº de hojas de anamnesis y Nº de informes de alta creados. Estos dos indicadores por su parte verifican cuantitativamente el nivel de uso por parte de determinados colectivos, por lo que su análisis nos ofrecerá un conocimiento amplio sobre el nivel de utilización de la herramienta por los estos en las diferentes área del centro.
- Nº de informe radiológicos generados. Con respecto a la medida por centro o servicio.
- Nº de vacunas suministradas o registradas.
- Nº de incidencias registradas y gestionadas en los sistemas de gestión de profesionales,
- Etc
A partir de todos los indicadores elegidos y acordados se puede obtener una visualización detallada del nivel de uso de los sistemas de información en los diferentes puntos involucrados de los centros, permitiendo la redistribución de tutores de soporte N0 en los puntos más conflictivos, y facilitando la aplicación de medidas paliativas por parte de la dirección del centro.
[ACT-CON-GEST-3] Informes Cualitativos de actividad
A medida que el nivel cuantitativo de utilización de los sistemas de información en los puntos calientes del centro se vaya acercando a la normalidad, iremos centrando el análisis y los esfuerzos de soporte en conseguir que la utilización que de esta herramienta sea de calidad y conforme a los procesos acordados durante la fase de Reingeniería de Procesos.
Para ello, comenzarán a analizarse, junto a los anteriores, una serie de indicadores encaminados a detectar malas praxis y errores frecuentes en el uso de los sistemas de información.
Nos centramos ya por tanto no solo en el uso de la aplicación mediante un control numérico sino en un uso correcto de la misma mediante un control de calidad del uso.
Estos indicadores dependen fuertemente del negocio involucrado en el proceso de implantación. A modo de ejemplo, planteamos una serie de indicadores del ámbito asistencial hospitalario:
- Nº de ingresos anulados.
- Un número elevado de ingresos anulados suele ser consecuencia de problemas en la gestión del ingreso de los usuarios en Admisión.
- Por otro lado, la ausencia total de ingresos anulados indica igualmente que no se ha puesto en práctica este mecanismo para la resolución de los errores que se hayan podido producir, y que en su lugar, se puede estar procediendo a mantener el episodio dándole el alta al usuario, incluyendo así un episodio ficticio con información errónea a este.
- Nº de preingresos ni anulados ni ingresados.
- Preingresos a pasado que no hayan sido ni finalmente ingresados ni anulados carecen de sentido.
- Es información obsoleta que debe ser revisada de forma diaria.
- Por otro lado, la existencia de un gran número de preingresos ni anulados ni ingresados suele indicar un uso incorrecto del circuito de ingreso desde preingreso.
- Este circuito es típico para los ingresos para actividad quirúrgica programada, y los ingresos a hospitalización provenientes de urgencias.
- En ambos casos, se generan preingresos para el usuario que deben ser localizados e ingresados, manteniendo así la trazabilidad entre las listas de espera y los episodios de hospitalización en el primer caso, y entre los episodios de urgencias y hospitalización en el segundo.
- Un análisis de este indicador por tanto, nos permitirá la corrección de estos aspectos.
- Nº Informes de alta.
- En relación a los informes de alta suelen ocurrir dos tipos de errores frecuentes.
- El primero está relacionado con la administración del Alta administrativa al paciente sin acompañarse por el informe de alta médico y el informe de alta de enfermería.
- El segundo tiene relación con el concepto alta y el concepto traslado.
- Tradicionalmente, el cambio de servicio para un paciente se ha modelado con un Alta del servicio con destino a otro servicio.
- En los nuevos sistemas este aspecto se denomina traslado.
- Suele ser frecuente la confusión entre ambos términos y la generación de un informe de alta sobre un paciente para definir un cambio de servicio cuando en su lugar habría de haber definido un Informe de Traslado.
- Este hecho más allá del error conceptual, supone una fuente de problemas debido a que sobre un episodio de hospitalización en los sistemas de información es posible definir más de un informe de Traslado, pero solo es posible definir un único informe de alta, que corresponderá al momento en el que el paciente abandona el hospital.
- Si en un cambio de servicio, el facultativo definió un informe de alta, en el momento real de alta hospitalaria, no será posible generar un nuevo informe de alta.
- A este respecto, existen medios para facilitar el desbloqueo de esta situación y serán aplicadas en todos los casos que se produzcan. Sin embargo, su prevención evitará bloqueos en el circuito de alta de un paciente.
- Nº de hojas de traslado.
- Este indicador tiene relación con el anterior, y nos dará información relativa a qué determinados servicios no han asimilado convenientemente este concepto en detrimento del concepto de alta entre servicios.
- Para ello, contrastaremos la información obtenida respecto al número de hojas de traslado por servicio respecto a los datos obtenidos con anterioridad durante el funcionamiento normal del hospital.
- Nº de hojas quirúrgicas provisionales (no firmadas como definitivas).
- La hoja de registro de actividad quirúrgica permite el registro de la actividad manteniendo la misma en estado provisional para facilitar la coordinación en la cumplimentación de la misma por los facultativos y el personal de enfermería.
- Parte de esta coordinación ha de implicar la firma de la hoja quirúrgica como definitiva, siendo este hito muy importante de cara al circuito de gestión de esta intervención en los sistemas de gestión de listas de espera.
- Cuando una hoja quirúrgica es firmada como definitiva, lanza un proceso automático de baja en la lista de espera, facilitando esta tarea de forma que se gestionen correctamente los tiempos medios de espera en el hospital.
- Sin embargo, si la hoja quirúrgica se queda en estado provisional, como tal, no causa baja en la lista de espera al no estar finalizada.
- Este hecho puede suponer un repunte no real del tiempo de demora en las intervenciones, incurriendo en un incumplimiento de la Ley de Garantía que en realidad no se produjo.
- Nº de ingresos por tipo de financiación.
- Otro error que suele ser recurrente es el relacionado con el tipo de financiación en los episodios de hospitalización.
- En este aspecto, en bastantes ocasiones ocurre que los usuarios suelen especificar de forma generalizada el tipo de financiación “Sistema Andaluz de Salud”, independientemente de que el paciente provenga de una aseguradora privada, o se trate de un paciente que proviene de urgencias donde fue hospitalizado por un accidente de tráfico.
- Este tipo de error no está vinculado al cambio de herramienta y suele darse con antelación al proceso de implantación.
- En el alcance de este proyecto analizaremos el % de ingresos asignados a este tipo de financiación y lo compararemos con los datos previamente obtenidos durante el funcionamiento normal del centro con el antiguo sistema de información.
- Incidiremos en todo caso en la importancia de recoger bien esta información en los ingresos aunque se trate de un error previo, para intentar mejorar este dato con la entrada del nuevo sistema de información.
- Nº de altas administrativas vs altas médicas.
- Comprobaremos que todas las altas administrativas tengan su correspondiente informe de alta médico.
- Ratio de cumplimentación de Informes de Alta médico.
- Contrastaremos el % obtenido frente a la media normal del hospital.
- Recién nacidos ingresados cuya madre ha sido dada de alta.
- En función de la parametrización elegida por el centro, al recién nacido no patológico se le dará el alta automáticamente cuando se dé el alta a la madre, o habrá que dársela de forma manual.
- En esta segunda opción, suelen darse casos en los que la madre obtiene su alta médica y administrativa, se va a casa con el recién nacido, y sin embargo, este no tiene alta ni médica ni administrativa.
- Este hecho se deriva de la asimilación conceptual de que un recién nacido en el momento en el que nace, es ingresado en el centro con origen “recién nacido”, tanto si se trata de un niño patológico, como si es no patológico.
- Nº de partes abiertos con posterioridad a la fecha de inicio del parte.
- Como parte del circuito de programación quirúrgica, es necesario que los partes de quirófano sean “cerrados” con anterioridad a la fecha de intervención (existe un proceso automático que los cierra, pero el usuario puede revertir esta acción dejándolos abiertos).
- El evento de cierre del parte lanza el proceso de generación de hoja quirúrgica previamente cumplimentada con los datos de AGD y asociadas al episodio del paciente.
- Si el parte no es cerrado, la hoja no es creada automáticamente como una hoja de intervención programada, y solo nos quedará como opción generar una nueva hoja quirúrgica, que al no estar vinculada a una programación quirúrgica, será entendida a todos los efectos como una intervención urgente, con la distorsión correspondiente en el análisis de actividad del hospital.
- Por ello, monitorizaremos que el circuito quirúrgico es implementado correctamente y es entendida la importancia de los procesos involucrados.
- Pacientes con hoja quirúrgica proveniente de programación en estado provisional que nunca se ha utilizado.
- Otra casuística que puede llegar a darse y que es necesario monitorizar para corregirla de forma temprana es la creación masiva de hojas quirúrgicas urgentes para registrar la actividad quirúrgica en lugar de utilizar la correspondiente hoja quirúrgica programada que ya debe existir en el episodio del paciente en el momento de su entrada a quirófano.
- Como en el caso anterior, este error distorsiona las estadísticas del centro en relación a la tasa de intervenciones urgentes frente a las programadas.
- Duplicidad de hojas de quirófano para una misma intervención.
- Relacionado con los dos casos anteriores, puede ocurrir que determinados usuarios procedan a generar una nueva hoja quirúrgica (urgente) en lugar de la existente (programada) en el episodio del paciente, distorsionando en doble medida las estadísticas del centro y la historia clínica del paciente, ya que no solo se registra la intervención como urgente en lugar de como programada, sino que se duplica el número de hojas quirúrgicas, y si esta es la base para cálculos de indicadores, podremos obtener resultados más elevados de lo previsto debido a esta duplicidad.
- Ingresos en hospital de día médico sin fecha de alta o con duración mayor a 24 horas.
- Por definición un ingreso en la modalidad hospital de día tiene que tener ingreso y alta en el mismo día.
- Por tanto todos aquellos episodios de esta tipología de duración mayor a 24 horas incluyen un error que se trasladará a las estadísticas del centro, CMBD, etc.
- Suele darse este tipo de error cuando las altas se registran al siguiente día a primera hora de la mañana. Se monitorizará este caso como todos los anteriores para mitigar su aparición e incidir en los flujos correctos.
La revisión de todos estos indicadores nos permitirá consolidar la calidad de los procesos ejecutados sobre el nuevo sistema de información conforme a los criterios acordados en la fase de Reingeniería de Procesos, monitorizando aquellas casuísticas que se detecten erróneas y facilitando a Dirección herramientas para su detección y mitigación
[ACT-CON-GEST-4] Soporte a usuarios finales
Durante esta fase posterior al arranque el objetivo fundamental es conseguir, en el menor tiempo posible, que el centro trabaje de la forma más fluida posible con los nuevos sistemas.
Para ello es clave en esta actividad de soporte a usuarios finales el papel de los tutores del equipo de implantación ( tutor n0) y de los usuarios expertos del centro que participarán en el tutelado insitu ( referentes n0). Esta figura perteneciente al centro asentará durante estas fases el conocimiento adquirido durante todo el proceso de Transferencia del Conocimiento iniciado en la fase de Reingeniería de Procesos.
Los equipos de soporte n0 serán equipos mixtos compuestos por:
- Un tutor n0 del equipo de implantación y
- El usuario referente n0 vinculado al punto de soporte correspondiente.
Ante una consulta de un profesional o una incidencia a resolver, esta será resuelta por el tutor del equipo de implantación, quien estará en contacto en todo momento por el usuario referente del hospital correspondiente (presencialmente, telefónicamente o según el modelo recogido en la relación con el proveedor). Conseguimos así que este usuario referente del hospital conozca la información relacionada con la resolución de la duda o de la incidencia y vaya centralizando actuación tras actuación todo el conocimiento necesario para tutelar al resto de compañeros a la salida del equipo de implantación del centro.
El soporte durante esta fase debe ser 24x7, siendo recomendada la presencia in-situ en el puesto del usuario para reforzar en todo lo posible el aprendizaje de las funcionalidades que le afecten.
Existirán durante esta fase determinadas ubicaciones clave en el hospital, acordadas en el Plan de Arranque, donde se prestará especial atención a las actividades de soporte. Será en estos puntos, donde los equipos mixtos de soporte n0 deben prestar un servicio más relevante.
En este periodo igualmente, se debe disponer de soporte n3 prioritario de los proveedores de los diferentes sistemas afectados, de manera que la resolución del volumen inicial de incidencias que suelen registrarse en los momentos iniciales sea estabilizado lo más rápidamente posible.
La organización del soporte vendrá definido en el entregable Plan de soporte definido en la fase de implantación durante la definición del Plan de Arranque, que como ya comentabamos en dicha actividad, Tiene las siguientes características:
- Plan de soporte.
- Para su elaboración, se hará un análisis de los puntos calientes para el arranque. Es decir, aquellos puntos en los que es crítico minimizar el impacto y reforzar el soporte para que el proceso de adaptación al nuevo sistema sea rápido y eficaz, y el resto de áreas funcionales del hospital no sufran efectos colaterales adversos relacionados con estos.
- El soporte se organizará en torno a la elección de estos puntos, en los que se hará especial seguimiento al soporte.
- Estos puntos calientes estarán definidos y descritos en el Plan de Arranque.
- El plan de soporte consta de dos matrices relativas a la estructuración del soporte una vez se finalice la fase de arranque.
- Una primera matriz con el nivel de soporte que se acuerde para cada punto caliente en cada día y en cada turno. Define igualmente los turnos de soporte que se van a gestionar.
- Incluye por tanto la siguiente tupla:
- Centro
- Punto caliente
- Día
- Turno
- Nivel de soporte
- Incluye por tanto la siguiente tupla:
- Una segunda matriz, definirá para los valores definidos en la primera, quién será el recurso del equipo de implantación (soporte n0) y quien será el recurso del centro (tutor n0) que darán cobertura a dicho punto caliente en dicho turno.
- De cada uno de los recursos aquí incluidos este documento debe reflejar:
- Nombre y apellidos
- Rol
- Teléfono de contacto
- Correo
- DNI (para la gestión del acceso a las zonas restringidas del centro).
- Empresa
[ACT-CON-GEST-5] Corrección de incidencias in stiu
Fruto de estas actividades de soporte y del comienzo de la utilización de nuevas herramientas, se incrementará durante los primeros días el número de incidencias y consultas por dudas funcionales que trasladen los usuarios finales hacia el servicio de soporte. Es por ello que durante la fase de consolidación, la parte del equipo de implantación que se dedique a soporte n2 deberá atender de forma ágil y cercana estas incidencias y consultas para aportar en aras de la normalización del hospital en el menor tiempo posible.
De igual forma, en este periodo igualmente, se debe disponer de soporte n3 prioritario de los proveedores de los diferentes sistemas afectados, de manera que la resolución del volumen inicial de incidencias que suelen registrarse en los momentos iniciales sea estabilizado como decimos lo más rápidamente posible.
| Ancla | ||||
|---|---|---|---|---|
|
Área Funcional
[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.
Área de Gestión
[ACT-EXT-GEST-1] Dar seguimiento y Control a los trabajos del Proyecto
Al igual que en la fase de preimplantación o en la fase de implantación, en esta fase continuaremos de forma periódica con las reuniones de seguimiento en el ámbito del centro, cuyo objetivo serán reportar a los responsables del mismo y de la STIC el grado de avance en estas tareas y alertar sobre aquellos puntos que supongan un riesgo global para la finalización de la fase.
| Ancla | ||||
|---|---|---|---|---|
|
Área de Gestión
[ACT-PN3-GEST-1] Generación de documentación de estado de situación
Durante esta fase se protocolarizará el paso del servicio de implantación al soporte n3. Para este proceso la primera acción consiste en recopilar y generar toda aquella documentación, informes de estado, y demás información previamente acordada con los n3 para la oficialización del traspaso al n3, y que vaya a servir a este para poder continuar con el soporte n3 garantizando la continuidad del servicio con el mismo o mejor nivel de calidad..
Entre otras, es necesario recopilar la siguiente información:
- Registrar todos los problemas que vayan a quedar sin resolución total a la salida del equipo de implantación (finalización de la OTIMPL).
- Que ocurre
- Impacto del problema (grupos de usuario, etc.)
- Workaround que este aplicado o se pueda aplicar
- Situación del estudio del problema hasta la fecha
- Preparar un listado de los mismos para presentar en la reunión de PN3.
- Registrar todas las incidencias que tengan abiertas en listados fuera de CGES(papel, excel, etc.), y que no se consigan resolver en el momento de salida.
- Este listado debe ser taxativamente cero incidencias, y solo en caso muy justificado cabría esta opción.
- Preparar un listado de los mismos para presentar en la reunión de PN3.
- Estado de extensión a la salida: que está arrancado y que no.
- Ámbitos funcionales arrancados y pendientes, grado de arranque, funcionalidades pendientes de arrancar, etc.
- Transferencia del conocimiento > Documento de preguntas más frecuentes y errores más comunes que realiza el personal y que el equipo de implantación haya detectado durante los días que ha estado allí. Se deberán especificar las respuestas y correcciones que deban darse y aplicarse en cada caso.
- Transferencia del conocimiento > Peticiones de mejora realizadas por el centro durante el proceso de implantación. Se deberán registrar en CGES por parte del equipo de implantación todas estas mejoras para que puedan ser convenientemente gestionadas. Del catálogo de mejoras registradas, se generará listado en esta actividad, que será presentado en la sesión de transferencia del conocimiento (siguiente actividad).
En esta actividad por tanto procederemos a la elaboración y empaquetado de dicha documentación.
[ACT-PN3-GEST-3] Informe de Lecciones Aprendidas
- Con ánimo de por un lado, no cometer los mismos errores o en la medida de lo posible mejorar o evitar riesgos, y por otro, asegurarnos que se replica lo que sí se ha hecho bien, me gustaría que cada uno me pasaseis para este vienes un informe de las lecciones aprendidas que vosotros hayáis detectado -que pueden ser de otras áreas- u os haya afectado directamente a vuestra área o producto durante el desarrollo, implantación, arranque y piloto de AU.
- Se trata de identificar:
- 1. El hecho objetivo de lo que ha pasado
- 2. La causa(s) o lo que uno crea puede ser la causa que ha provocado que eso ocurra
- 3. Analizando el hecho objetivo, que se extrae como lección para futuras implantaciones
- 4. Propuesta de mecanismo para implementar esa lección.
[ACT-PN3-GEST-2] Sesión de transferencia a N3 y CGES
Durante esta fase se protocolarizará el paso del servicio de implantación al soporte n3. Para este proceso se debe hacer entrega de toda aquella documentación, informes de estado, y demás información previamente acordada con los n3.
Soporte n3, recepcionará dicha información, que deberá analizar y verificar.
Por último, en el ámbito de esta actividad, se lleva a cabo un comité específico de paso a n3 donde el soporte n3 puede solicitar aclaración sobre la documentación facilitada y la subsanación de posibles deficiencias, dando como resultado final la aprobación formal del paso a n3 del centro implantado.
[ACT-IMP-MIGR-2.4] Ejecutar el Plan de Pruebas de migración cuantitativas
[ACT-IMP-MIGR-2.5] Generar ficheros pasivo para sistemas terceros integrados
[ACT-IMP-MIGR-2.6] Actualizar información en sistemas terceros integrados
Área de Integración
[ACT-IMP-INTE-1] PRE
[ACT-IMP-INTE-1.1] Ejecutar Plan de Pruebas de conectividad de integraciones (ESB)
[ACT-IMP-INTE-1.2] Ejecutar Plan de Pruebas de conectividad de integraciones (no ESB)
[ACT-IMP-INTE-1.3] Ejecutar Plan de Pruebas funcionales de las integraciones (ESB)
[ACT-IMP-INTE-1.4] Ejecutar Plan de Pruebas funcionales de las integraciones (no ESB)
[ACT-IMP-INTE-2] PRO
[ACT-IMP-INTE-2.1] Desplegar en PRO integraciones de terceros
[ACT-IMP-INTE-2.2] Ejecutar Plan de Pruebas de conectividad de integraciones (ESB)
[ACT-IMP-INTE-2.3] Ejecutar Plan de Pruebas de conectividad de integraciones (no ESB)
[ACT-IMP-INTE-2.4] Ejecutar Plan de Pruebas funcionales de las integraciones (ESB)
[ACT-IMP-INTE-2.5] Ejecutar Plan de Pruebas funcionales de las integraciones (no ESB)
Área de Sistemas e Infraestructuras
[ACT-IMP-SIST-5] Crear snapshot de los sistemas en producción previos (creación bbdd y carga de datos)
[ACT-IMP-SIST-1] Publicar accesos al Sistema en producción
[ACT-IMP-SIST-2] Nivelar sistema a la versión acordada para la implantación
[ACT-IMP-SIST-6] Informar cambios incluidos en la versión
[ACT-IMP-SIST-3] Desplegar sistemas terceros relacionados
[ACT-IMP-SIST-4] Desplegar modificaciones necesarias sobre sistema origen
Área de Análisis y Explotación de Datos
[ACT-IMP-AYED-1] Validar los procesos de explotación de datos afectados
[ACT-IMP-AYED-2] Publicar los nuevos procesos de explotación de datos
Área de Gestión
[ACT-IMP-GEST-1] Dar Seguimiento y Control a los Trabajos del Proyecto
[ACT-IMP-GEST-2] Controlar los riesgos
[ACT-IMP-GEST-3] Definir el Plan de arranque
[ACT-IMP-GEST-4] Definir el Plan de comunicación
[ACT-IMP-GEST-8] Ejecutar Plan de comunicación fase implantación
[ACT-IMP-GEST-5] Definir e implementar el Plan de Transición
[ACT-IMP-GEST-6] Precertificación de Entornos
[ACT-IMP-GEST-7] Certificar los entornos
[ACT-IMP-GEST-10] Enviar de Peticiones Cambios / Mejoras al Comité de Cambios
[ACT-IMP-GEST-9] HITO. Entrega producto versión definitiva
Arranque
...
Área Funcional
[ACT-ARR-PREV-1.1] Ejecutar verificaciones previas al arranque en entorno origen
Área de Sistemas e Infraestructuras
[ACT-ARR-PREV-2.1] Realizar copias de seguridad de los sistemas destino
[ACT-ARR-PREV-2.2] Verificar que los sistemas están listos para el arranque
[ACT-ARR-PREV-2.3] Deshabilitar acceso a entornos formativos
Área de Gestión
[ACT-ARR-PREV-3.1] Ejecutar Plan de comunicación subfase 5.1
[ACT-ARR-PREV-3.2] Desplegar elementos del plan de Transición
...
Área Funcional
[ACT-ARR-TRAN-1.1] Ejecutar procesos de obtención de datos del sistema origen datos para el Plan de Transición
Área de Migración
[ACT-ARR-TRAN-2.1] Preparar los sistemas origen para la extracción de datos
[ACT-ARR-TRAN-2.2] Preparar los sistemas destino para la carga de datos
[ACT-ARR-TRAN-2.3] Extraer y transformar los datos activos
[ACT-ARR-TRAN-2.4] Validar los ficheros o soportes de datos obtenidos
[ACT-ARR-TRAN-2.5] Cargar los datos activos en PRO
[ACT-ARR-TRAN-2.6] Ejecutar el Plan de Pruebas de migración cuantitativas
[ACT-ARR-TRAN-2.7] Generar ficheros activo para sistemas terceros integrados
[ACT-ARR-TRAN-2.8] Actualizar información en sistemas terceros integrados
Área de Integración
[ACT-ARR-TRAN-3.1] Detener mensajería de integraciones obsoletas tras el arranque
[ACT-ARR-TRAN-3.2] Encolar mensajería de integraciones afectadas durante la fase de transición
Área de Sistemas e Infraestructuras
[ACT-ARR-TRAN-4.1] Activar modo transición en los sistemas origen
[ACT-ARR-TRAN-4.2] Activar modo transición en los sistemas afectados y en las comunicaciones
[ACT-ARR-TRAN-4.4] Desplegar modificaciones necesarias sobre sistema origen
[ACT-ARR-TRAN-4.3] Realizar copias de seguridad de los sistemas origen
Área de Gestión
[ACT-ARR-TRAN-5.1] Ejecutar Plan de comunicación subfase 5.2 Transición
...
Área Funcional
[ACT-ARR-ARR-1.2] Ejecutar Plan de pruebas de aceptación del sistema
[ACT-ARR-ARR-1.3] Ejecutar Plan de pruebas de apagado sobre sistemas origen
[ACT-ARR-ARR-1.5] Actualizar en el sistema la información recogida en los elementos del Plan de Transición
Área de Integración
[ACT-ARR-ARR-2.1] Arrancar procesos de integración de sistemas terceros que arranquen en esta fase
[ACT-ARR-ARR-2.2] Desencolar mensajería de integraciones de sistemas terceros que arranquen en esta fase
[ACT-ARR-ARR-2.6] Configurar módulos corporativos para su integración con el sistema
[ACT-ARR-ARR-2.7] Configurar sistemas terceros para su integración con el sistema
[ACT-ARR-ARR-2.3] Ejecutar Plan de Pruebas funcionales de las integraciones (ESB)
[ACT-ARR-ARR-2.4] Ejecutar Plan de Pruebas funcionales de las integraciones (no ESB)
Área de Sistemas e Infraestructuras
[ACT-ARR-ARR-3.1] Monitorizar la capacidad y disponibilidad del sistema
[ACT-ARR-ARR-3.2] Activar modo definitivo en los sistemas origen
[ACT-ARR-ARR-3.3] Activar modo Abierto en los sistemas afectados y en las comunicaciones
Área de Gestión
[ACT-ARR-ARR-4.1] Ejecutar Plan de comunicación subfase 5.3 Arranque
[ACT-ARR-ARR-4.4] Recoger elementos desplegados del plan de Transición
[ACT-ARR-ARR-4.5] Comunicar finalización proceso de arranque
...
Área Funcional
[ACT-ARR-POST-1.1] Configurar el sistema con posterioridad al arranque
Área de Migración
[ACT-ARR-POST-6.17] Preparar los sistemas origen para la extracción de datos
[ACT-ARR-POST-6.18] Preparar los sistemas destino para la carga de datos
[ACT-ARR-POST-6.19] Extraer y transformar los datos activos de los sistemas origen
[ACT-ARR-POST-6.20] Validar los ficheros o soportes de datos obtenidos
[ACT-ARR-POST-6.21] Cargar los datos activos en PRO
[ACT-ARR-POST-6.22] Ejecutar el Plan de Pruebas de migración cuantitativas
[ACT-ARR-POST-6.23] Generar ficheros activo para sistemas terceros integrados
[ACT-ARR-POST-6.24] Actualizar información en sistemas terceros integrados
Área de Integración
[ACT-ARR-POST-5.14] Arrancar procesos de integración de sistemas terceros dependientes que arranquen en esta fase
[ACT-ARR-POST-5.15] Desencolar mensajería de integraciones de sistemas terceros dependientes que arranquen en esta fase
[ACT-ARR-POST-5.16] Configurar módulos corporativos para su integración con el sistema
[ACT-ARR-POST-5.17] Configurar sistemas terceros para su integración con el sistema
[ACT-ARR-POST-5.18] Ejecutar Plan de Pruebas funcionales de las integraciones (ESB)
[ACT-ARR-POST-5.19] Ejecutar Plan de Pruebas funcionales de las integraciones (no ESB)
Área de Gestión
[ACT-ARR-POST-3.1] Ejecutar Plan de comunicación subfase 5.4 Post-Arranque
[ACT-ARR-POST-3.2] Comunicar finalización proceso de post-arranque
...
Área de Sistemas e Infraestructuras
[ACT-CON-SIST-1] Monitorizar la capacidad y disponibilidad del sistema
Área de Gestión
[ACT-CON-GEST-1] Dar seguimiento y Control a los trabajos del Proyecto
[ACT-CON-GEST-2] Informes cuantitativos de actividad
[ACT-CON-GEST-3] Informes Cualitativos de actividad
[ACT-CON-GEST-4] Soporte a usuarios finales
[ACT-CON-GEST-5] Corrección de incidencias instiu
...
Área Funcional
[ACT-EXT-FUNC-1] Tareas acordadas para esta fase relativas al área funcional
Área Formación
[ACT-EXT-FORM-1] Tareas acordadas para esta fase relativas al área de formación
Área de Migración
[ACT-EXT-MIGR-1] Tareas acordadas para esta fase relativas al área de migraciones
Área de Integración
[ACT-EXT-INTE-1] Tareas acordadas para esta fase relativas al área de integraciones
Área de Sistemas e Infraestructuras
[ACT-EXT-SIST-1] Tareas acordadas para esta fase relativas al área de sistemas
Área de Análisis y Explotación de Datos
[ACT-EXT-AYED-1] Tareas acordadas para esta fase relativas al área de explotación de datos
Área de Gestión
[ACT-EXT-GEST-1] Dar seguimiento y Control a los trabajos del Proyecto
...
Área de Gestión
[ACT-PN3-GEST-1] Generación de documentación de estado de situación
[ACT-PN3-GEST-3] Informe de Lecciones Aprendidas
[ACT-PN3-GEST-2] Sesión de transferencia a N3 y CGESVista general
Herramientas de contenido
- Impreso por Atlassian Confluence 8.7.2