Área FuncionalPrevio a cualquier trabajo de implantación en un centro, es conveniente obtener determinados indicadores que nos permitan tener una percepción sobre el volumen y la complejidad de dicho centro, dado que esta puede incidir positiva o negativamente en la complejidad de ejecución del proceso de implantación.
Es necesario recabar al menos la siguiente información referente al dimensionamiento del centro:
Este proceso, decide, del total de elementos catalogados en el proceso “[ACT-APS-FUNC-1] Dimensionar el ámbito de implantación” cuáles de ellos se ven afectados por el proceso de implantación.
En esta actividad el objetivo principal es verificar el estado inicial de parametrización del hospital.
Se suele utilizar en aquellas implantaciones en las que se actualiza una versión del producto ya existente a una nueva, o en la que se parte de un producto común que se sustituye por otro, y en la que es necesario una situación controlada de partida en cuanto a parametrización.
Área de Sistemas e InfraestructurasPrevio a cualquier trabajo de implantación en un centro, es conveniente obtener determinados indicadores que nos permitan tener una percepción sobre el volumen y la complejidad de dicho centro, dado que esta puede incidir positiva o negativamente en la complejidad de ejecución del proceso de implantación.
Para ello, en el área de sistemas es necesario recabar información referente al catálogo de sistemas de información: proveedores, productos, tecnologías, alcance de integraciones, modelos de integración, etc.
Para la realización de la fase de Reingeniería de Procesos se debe disponer de un entorno con la versión más actualizada del aplicativo a implantar sobre el que se puedan llevar a cabo las sesiones de reingeniería, mostrar los procesos a los que se dará cobertura, etc.
Estos entornos deben estar con la suficiente antelación para que el equipo de implantación pueda verificar que funciona correctamente y que dispone de un juego de datos suficientemente amplio como para llevar a cabo las sesiones.
El Modelo Corporativo Marco de Implantaciones (MCMI) define una serie de entornos necesarios para implementar con garantías y seguridad todas las actividades involucradas en un proceso de implantación.
El número y características de los entornos viene marcada por las actividades que deben poder ejecutarse paralelamente en el tiempo y la interdependencia entre estas.
Los entornos comúnmente utilizados son:
El jefe de equipo de implantación en común acuerdo con el jefe de proyecto por parte de la STIC deberá definir un cronograma estratégico que marque las líneas maestras de los periodos de implantación en caso de que el proceso vaya a ser ejecutado repetitivamente.
En base a este cronograma, y con la máxima antelación posible, deberá solicitarse a Sistemas de la STIC la entrega de los entornos necesarios para llevar a cabo los procesos de implantación: RP, FOR, VAL, PRO.
Deberá consensuarse con sistemas las fechas comprometidas para la entrega de cada uno de los entornos de forma que se garantice el cronograma estratégico de implantaciones y se minimice el impacto en la actividad planificada de Sistemas.
Para la realización de la fase de Reingeniería de Procesos se debe disponer de un entorno con la versión más actualizada del aplicativo a implantar sobre el que se puedan llevar a cabo las sesiones de reingeniería, mostrar los procesos a los que se dará cobertura, etc.
Estos entornos deben estar con la suficiente antelación para que el equipo de implantación pueda verificar que funciona correctamente y que dispone de un juego de datos suficientemente amplio como para llevar a cabo las sesiones.
La entrega de estos entornos será entregada igualmente conforme al cronograma estratégico de las implantaciones y de acuerdo a las fechas solicitadas en el proceso [P-APS-SIST-2.4] Solicitar despliegue de entornos.
La entrega de un entorno específico conlleva la gestión correspondiente de los canales de comunicación hacia y desde el mismo.
De esta forma, toda entrega de un entorno, aunque existiera previamente, debe ir acompañada con la gestión de las reglas de comunicación, apertura de firewalls, etc. necesarios para que los sistemas incluidos en el entorno puedan comunicarse entre sí según ha especificado el fabricante del aplicativo, y a su vez, estos puedan comunicarse con el resto de sistemas que vayan a conformar el ecosistema de aplicaciones involucradas (sistemas corporativos centralizados, departamentales, sistemas de terceros, aplicaciones distribuidas, etc.).
De cada comunicación es necesario recoger y registrar la siguiente información:
En relación específica a este proceso, deberá gestionarse la apertura de comunicaciones necesarias para el entorno de Reingeniería de Procesos solicitado y que será utilizado durante la fase de RP.
Una vez recepcionado el entorno para las Reingeniería de Procesos, el equipo de implantación deberá verificar que el entorno funciona conforme a sus expectativas y cumple con las funcionalidades necesarias para llevar a cabo las sesiones de Reingeniería de Procesos.
Si bien la verificación será llevada a cabo por el equipo de implantación, la responsabilidad de que este proceso se pase con éxito recae en Sistemas STIC, quien entrega el entorno y deberá ejecutar las acciones necesarias para garantizar que el entorno facilitado sea totalmente operativo.
Área de GestiónUna de las primeras actividades que deberán llevarse a cabo en un proceso de implantación es realizar el listado de todos los Interesados o Stakeholders.
Stakeholders son todas las personas u organizaciones (externas o internas) que de alguna manera se van a ver afectadas por el proceso de implantación o afectarán con su acción al mismo.
Los stakeholders tienen:
Los cambios solicitados por los stakeholders en las fases finales del proyecto tienen un impacto muy elevado. Para evitarlo, desde un principio hay que gestionar muy bien a los stakeholders y hacerlos muy partícipes de todo el proceso.
El comienzo de la siguiente fase, que será la de Reingeniería de Procesos, comenzará con la celebración de un conjunto de reuniones en las que dará cobertura a los objetivos de la reingeniería.
Para facilitar la asistencia de los perfiles involucrados en la misma es necesario generar con la suficiente antelación un calendario de sesiones consensuado con los perfiles que deben asistir.
Para maximizar la antelación con la que se dispondrá de este calendario, deberemos definirlo ya en esta fase.
De cada una de estas sesiones de reingeniería de procesos, deberemos acordar al menos las siguientes características:
Área FuncionalUna vez se haya presentado oficialmente el MCI a los involucrados, podremos comenzar con las sesiones de reingeniería de procesos con la visita al ámbito.
Se realizarán visitas conjuntamente con el responsable correspondiente para conocer de primera mano el funcionamiento de cada ámbito, registrando información relevante sobre cada uno como personal de cada perfil, ubicaciones, circuito habitual, excepciones,…
De este tipo de visitas, se extraen conclusiones e información adicional que normalmente no es transmitida por el usuario final en reuniones de reingeniería en una sala de trabajo (disposición física, disponibilidad de espacio e infraestructuras, flujo físico, etc.).
El centro presenta los circuitos funcionales que actualmente se encuentran implementados en el mismo.
Se obtienen y anotan conclusiones para modelar posteriormente dichos circuitos con los implementados con el nuevo sistema.
De esta forma, los perfiles expertos en el nuevo sistema a implantar conocen de primera mano el funcionamiento del centro y aquellas características que lo hagan específico.
Los miembros del equipo de implantación presentan al centro los circuitos implementados en el aplicativo o sistema a implantar.
Los referentes del centro obtienen y anotan conclusiones para modelar posteriormente dichos circuitos con los implementados actualmente en el centro.
De esta forma, los perfiles referentes del centro conocen de primera mano el funcionamiento del nuevo sistema y aquellas características que sean clave para poder encajar sobre el mismo los procesos actuales.
Los miembros del equipo de implantación presentan al centro los circuitos implementados en el aplicativo o sistema a implantar.
Los referentes del centro obtienen y anotan conclusiones para modelar posteriormente dichos circuitos con los implementados actualmente en el centro.
De esta forma, los perfiles referentes del centro conocen de primera mano el funcionamiento del nuevo sistema y aquellas características que sean clave para poder encajar sobre el mismo los procesos actuales.
Los miembros del equipo de implantación presentan al centro los circuitos implementados en el aplicativo o sistema a implantar.
Los referentes del centro obtienen y anotan conclusiones para modelar posteriormente dichos circuitos con los implementados actualmente en el centro.
De esta forma, los perfiles referentes del centro conocen de primera mano el funcionamiento del nuevo sistema y aquellas características que sean clave para poder encajar sobre el mismo los procesos actuales.
Los miembros del equipo de implantación presentan al centro los circuitos implementados en el aplicativo o sistema a implantar.
Los referentes del centro obtienen y anotan conclusiones para modelar posteriormente dichos circuitos con los implementados actualmente en el centro.
De esta forma, los perfiles referentes del centro conocen de primera mano el funcionamiento del nuevo sistema y aquellas características que sean clave para poder encajar sobre el mismo los procesos actuales.
Los miembros del equipo de implantación presentan al centro los circuitos implementados en el aplicativo o sistema a implantar.
Los referentes del centro obtienen y anotan conclusiones para modelar posteriormente dichos circuitos con los implementados actualmente en el centro.
De esta forma, los perfiles referentes del centro conocen de primera mano el funcionamiento del nuevo sistema y aquellas características que sean clave para poder encajar sobre el mismo los procesos actuales.
Tras un periodo de reflexión, una vez visitado los ámbitos funcionales del centro, y presentado los circuitos a los que da cobertura el sistema a implantar, se realizarán sesiones para presentar la propuesta de engranaje entre los circuitos del hospital y los ofertados por el sistema, a los responsables correspondientes para analizar la idoneidad de este engranaje.
En estas sesiones se podrán sacar conclusiones sobre el grado de adaptación del nuevo sistema en el centro para elevar los riesgos y beneficios de la implantación de estos.
En estas reuniones deberán participar los responsables funcionales correspondientes del centro, responsables de TIC, el responsable de implantación además del consultor funcional correspondiente del equipo de implantación.
Es fundamental que estén especialmente los responsables funcionales para que todas aquellas excepciones que existan en los circuitos del hospital, puedan salir a la luz y tenerse en cuenta para las siguientes fases y queden reflejados en el documento ”GEST05. Informe final Reingeniería de Procesos GEST05. Informe final Reingeniería de Procesos” y en el documento “GEST06. Catálogo de peticiones de cambio funcionales “.
En la Verificación del estado inicial el objetivo es concienciar a la Gerencia, Dirección y responsables del centro en la criticidad de que una serie de actividades deben ser ejecutadas por el centro en tiempo y forma para realizar una implantación con éxito. Entre estas se encuentran las actividades que más adelante veremos en la fase de preimplantación, como la parametrización de Estructura Física y Funcional si aplica, la preparación y gestión de los operadores, profesionales, perfiles y permisos, y la adecuación de los módulos corporativos involucrados para su preparación de cara al proceso de implantación
La experiencia confirma que la no adecuada ejecución de estas actividades de la fase de preimplantación supone un incremento en ocasiones traumático de las incidencias en los primeros días después del arranque. De aquí la importancia de que los altos cargos del centro conozcan y asuman la relevancia de estas actividades.
El equipo de implantación debe apoyar en todo momento al hospital en la consecución de estas metas, aportando la experiencia y las herramientas que hayan generado valor añadido en anteriores implantaciones para la ejecución de estas actividades.
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.
Una vez se hayan parametrizado los entornos durante el proceso “[ACT-IMP-FUNC-1.2] Parametrizar funcionalmente los entornos en PRE” y se hayan implementado sobre este las modificaciones acordadas e implementadas en el proceso “[ACT-IM
Los elementos que son susceptibles de ser parametrizados deben ser conocidos de antemano y facilitados por el N3 del nuevo sistema a implantar.
Son elementos parametrizables:
Es conveniente tener en cuenta que no todos los parámetros del sistema y los valores de tablas maestras pueden ser modificados a conveniencia, dado que en ocasiones, los valores de estos elementos son fijados de forma corporativa por decisión de los grupos funcionales.
Las plantillas de parametrización y las guías de parametrización deben referir la información suficiente para poder conocer de forma inequívoca:
En este proceso, haremos entrega de las plantillas o material de recogida de los valores de parametrización a los usuarios involucrados, procediéndose a un análisis conjunto con estos de dicho material.
Se debe garantizar que los usuarios responsables de recopilar los valores de parametrización entienden y comprenden sin lugar a duda la información que se les está requiriendo y las consecuencias de la toma de decisión sobre cada uno de los valores de dichos elementos de parametrización.
Para ello, entre otras medidas, se debe facilitar igualmente a los responsables las correspondientes guías de parametrización del sistema.
Área FormaciónUna vez llevadas a cabo las sesiones de reingeniería de procesos, y antes de comentar la fase de Preimplantación, debemos asegurarnos que las tareas incluidas en esta fase son entendidas e interiorizadas por cada uno de sus responsable, en general, del centro.
Para ello, llevaremos a cabo este proceso de transferencia del conocimiento con los recursos implicados.
La formación se establece con el siguiente alcance de forma general salvo norma o pacto en contra:
El objetivo principal de esta actividad será recabar la información necesaria para poder estimar las necesidades de formación del centro, amén de conocer con nombres y apellidos los usuarios expertos y los tutores del hospital, como más adelante explicamos.
Esta sesión se llevará a cabo de las últimas, una vez realizadas todas las sesiones funcionales, de modo que nos hayan ayudado a averiguar los distintos perfiles (por las tareas que desempeñan en los distintos circuitos funcionales) que hay en el hospital y que utilizarán cualquiera de los módulos del sistema para realizarla.
Definiremos así una serie de perfiles sobre los que se organizará y planificará la formación.
A modo de ejemplo, en un entorno de atención especializada, los siguientes suelen ser perfiles tipos: Administrativo de Admisión, Responsable de Admisión, Técnico de Archivo, Responsable de Archivo, Visador Quirúrgico, Programador Quirúrgico, Administrador de la Estación de Cuidados, Supervisor de la Estación de Cuidados, etc. Pero puede que como resultado de las visitas in-situ se detecte la necesidad de ampliar la formación a algún perfil no contemplado entre los perfiles tipo utilizados en implantaciones anteriores.
Obtendremos el número de usuarios por perfil, para organizar la formación de manera que pueda impartirse al menos a un porcentaje entre el 80% y el 100% de los usuarios de cada perfil para, de este modo, ayudar a que el soporte dedicado a estos usuarios en las fechas posteriores al arranque sea menor que si se impartiesen en modo formación a formadores.
Un aspecto muy importante son los recursos de los que dispone el hospital para impartir la formación. Nos referimos a las aulas de formación, proyectores, disponibilidad de red para acceso a los entornos, capacidad de las mismas, si dispone de Aula Magna, o Salón de Actos para sesiones multitudinarias, etc. Obtendremos estos datos también para prever con antelación las necesidades que hubiese para cubrir el alcance a los porcentajes indicados de usuarios por perfil.
Otro aspecto clave será identificar los usuarios expertos, es decir, aquellos a los que habrá que dedicar especial atención en la formación ya que serán los referentes por áreas, del soporte N0, una vez puesto en producción el sistema en el hospital, siendo estos los primeros a los que podrán acudir sus propios compañeros para realizar las consultas, o dudas que tengan. Serán referencia funcional para los usuarios del centro, una vez el equipo de implantación haya finalizado el periodo de Consolidación y Extensión. Aparte de realizar con ellos la transferencia del conocimiento necesario a nivel funcional, también se formará a determinados perfiles en cuanto a las áreas de integraciones, infraestructura de servidores, réplicas…
Aparte de la celebración de estas sesiones de formación específicas para los usuarios expertos, el conocimiento que estos adquirirán a través de las mismas se complementará de forma diaria con la participación activa en la ejecución de las actividades de implantación de la mano del equipo de implantación, y con el acceso a entornos de formación en los que profundizar y experimentar procesos con las nuevas herramientas.
En esta actividad, se procederá a la entrega al centro de los requisitos mínimos necesarios que han de cumplir los equipos cliente puestos a disposición de la formación de manera que se garantice que esta pueda llevarse a cabo sin problemas.
Incluye todos los requisitos que deberá cumplir un puesto cliente normal más aquellos adicionales que se estimen convenientes para poder ser utilizados en sesiones de formación (cañones de proyección, orientación de las mesas, pizarras, etc).
Área de MigraciónDurante la ejecución de este proceso, se entregará y expondrá el catálogo de requisitos que han de cumplir los datos para poder ser migrados al sistema a implantar, haciendo especial hincapié en aquellos que en otros centros hayan supuesto un mayor escollo.
Entre estos requisitos, y a título de ejemplo, se encuentra la obligatoriedad de que los pacientes cuyos datos se desean migrar, dispongan de NUHSA, un único NHC activo, etc.
Estos requisitos y reglas deberán ser tenidos en cuenta en todo momento en la implementación de los procesos de extracción y transformación de datos del sistema origen, pues se deberá verificar que los datos contenidos en los ficheros de salida de dichas extracciones cumplan con todas y cada una de dichas reglas.
El objetivo de esta actividad es definir al máximo detalle:
Además de las reglas entregadas y analizadas en el proceso “[P-RP-MIGR-1] Entregar catálogo de reglas de negocio implicadas”, se deben exponer aquellas recomendaciones basadas en las experiencias vividas en otros centros que resulten importantes para garantizar que los procesos de extracción y transformación de datos serán los más adecuados para la consecución del objetivo final de migración de información.
Estas apreciaciones junto con el conocimiento interno de la calidad de los datos albergados en el sistema origen por parte del centro formarán la base de decisión sobre la que se sustentará el acuerdo de alcance de la migración.
Igualmente se pondrán de manifiesto un conjunto de actividades sobre las que el centro, acompañado en todo momento por el equipo de implantación, deberá incidir con mayor fuerza durante la fase de Preimplantación con el objetivo de maximizar el número de registros migrados.
Como ejemplo en un ámbito de atención especializada, una de las principales actividades en este sentido es la conciliación sistemática de usuarios con BDU hasta alcanzar un ratio de al menos el 90% de los usuarios que tienen episodio en el hospital en los últimos 3-5 años. A mayor % de conciliación obtenido, mayor número de registros se verán incluidos en el proceso de migración, y menor será el impacto de cara al acceso a la historia clínica del paciente en el nuevo sistema.
Una vez definido el alcance de las migraciones en la actividad anterior, será necesario definir y consensuar cuál será el catálogo de pruebas que se llevarán a cabo para verificar que los procesos de migración (extracción, transformación y carga de datos) se han llevado a cabo correctamente.
A este respecto, definiremos dos Planes de prueba diferentes relacionados con el área de migración de datos.
El “MIGR04. Plan de pruebas de migración Cualitativas.”, que es el que atañe a esta actividad, contendrá todas las pruebas funcionales que deberán llevarse a cabo sobre una cata de información para verificar que el proceso de migración, hasta el más mínimo, detalle es correcto.
Se verificarán que todos los datos se carguen correctamente en su correspondiente campo, que los mapeos entre tablas maestros funcione bien en el 100% de los casos, que los valores dummy acordados son visualizados convenientemente cuando deben, etc.
Dado que estas pruebas son tan tediosas, no es posible llevar a cabo toda la batería sobre el 100% de los datos a migrar, dado que se trata de una inspección manual.
Esta idiosincrasia hace demasiado costoso revisar un número de registros superior a 100, por lo que este es considerado un número correcto de datos a verificar.
Dado que trabajaremos con un subconjunto, es importante que la elección del mismo sea cuidadosamente elegida en el proceso “[P-PRE-MIGR-4] Establecer subconjunto de datos para las pruebas de migración unitarias”.
El “MIGR05. Plan de pruebas de migración Cuantitativas”, a diferencia del “MIGR04. Plan de pruebas de migración Cualitativas.”, lleva a cabo una batería de pruebas a un nivel más amplio pero a la vez más general.
Este plan de pruebas, a diferencia del anterior, se centra sobre el aspecto cuantitativo en lugar de sobre el cualitativo, verificando conteos de registros y correspondencia con los números en el sistema origen.
Es por ello que es necesario ejecutarlo sobre una migración completa.
Área de IntegraciónAl comienzo de la fase de reingeniería de procesos, deberá trasladarse al centro los contratos de integración corporativos para que sean tenidos en cuenta por este y por los proveedores que de él dependan.
En esta actividad deberá llevarse a cabo la transferencia del conocimiento necesaria hacia dichos actores, a través de la Oficina Técnica de Interoperabilidad.
Si bien debe garantizarse la correcta ejecución de todas las integraciones incluidas en el alcance de la implantación, el objetivo principal en este apartado radica en detectar cual es el subconjunto de integraciones crítico de cara al correcto funcionamiento del centro en el momento del arranque. Si bien todas las integraciones tienen su importancia y su razón de ser, no todas comparten el mismo nivel de impacto en caso de mal funcionamiento en dicho momento. A este respecto, integraciones como las existentes hacia los servicios peticionarios, los departamentales de dietas o de farmacia suelen tener un nivel de impacto mayor al existente por ejemplo en la integración con un sistema de impresión de sobres o un cuadro de mandos.
Detectar y categorizar como críticas este tipo de integraciones nos ayudará a hacer sobre las mismas un especial seguimiento y una labor más exhaustiva si cabe, sin menoscabo alguno de la correcta gestión y cumplimiento de objetivos con el resto.
Garantizando el control y la monitorización de los procesos en los que se ven involucradas estas integraciones conseguiremos en gran medida el escenario de arranque esperado.
Es importante en este aspecto analizar todos los elementos integrados existentes que se ven afectados con el proceso de implantación, así como los nuevos elementos que entran en funcionamiento. Se ha de tener en cuenta igualmente no solo las integraciones corporativas a través de ESB, sino también cualquier otro tipo de integración a través de acceso a bases de datos, dblinks, acceso a descarga de ficheros vía ftp, permisos sobre vistas, web services, etc.
Una vez analizado el espectro de integraciones que intervienen y son afectadas por el proceso de implantación durante la sesión “[ACT-RP-INTE-2] Sesión RP de integración”, tendremos acotado y acordado el alcance.
Una vez analizado el espectro de integraciones que intervienen y son afectadas por el proceso de implantación durante la sesión “[ACT-RP-INTE-2] Sesión RP de integración”, tendremos acotado y acordado el alcance.
Área de Sistemas e InfraestructurasEn esta actividad, se procederá a la entrega al centro de los requisitos mínimos necesarios que han de cumplir los equipos cliente puestos a disposición de la formación de manera que se garantice que esta pueda llevarse a cabo sin problemas.
De forma previa a que se lleve a cabo la fase de Arranque, deberá verificarse según se haya determinado específicamente para el proyecto, que las infraestructuras de comunicaciones del centro son aptas para dar cobertura al nuevo sistema.
En función de la tipología del nuevo sistema, requisitos de conectividad y arquitectura, nos encontraremos en un escenario más exigente o más laxo en relación a la criticidad de las infraestructuras de comunicaciones.
Por ello, deberá ser en cada proyecto concreto donde se acuerde cual es la situación que hay que garantizar en relación a la infraestructura de comunicaciones y las acciones correctivas necesarias para dicha garantía.
Área de Análisis y Explotación de DatosSabemos de la importancia organizativa que tiene para los centros la disponibilidad de información de seguimiento y control, tanto para el funcionamiento diario, la toma de decisiones en el ámbito hospitalario cómo para la comunicación a terceros en el cumplimiento de compromisos adquiridos.
De las actividades del área de AyED, corresponden a la fase de Reingeniería de Procesos las relacionadas con la detección y catalogación de todas las fuentes de información externas relativas a explotación de información que se nutran del sistema origen a sustituir, y que tengan el riesgo de no disponer de información actualizada, una vez finalizado el proceso de implantación del nuevo sistema. Entre estas suelen encontrarse, aplicaciones de cuadro de mandos propias del centro, procesos de generación de informes en entornos web, procesos nocturnos de cálculo de datos, scripts de extracción de información para alimentar estructuras de datos en Excel o ficheros planos, etc.
Una vez catalogados todos los procesos de explotación de datos, es necesario contrastar los procesos en este ámbito existentes en el centro y catalogados con los ofrecidos por el nuevo sistema a implantar, poniendo el foco y el énfasis en aquellos procesos actuales que pasen a estar obsoletos tras la implantación bien porque se apague el origen de datos, bien porque se modifique el modelo de datos, etc.
Es labor en este proceso ese análisis y la categorización de los procesos de explotación de datos antes inventariados para conocer:
Deberá en este proceso igualmente planificarse las necesidades de desarrollo que supongan estas adecuaciones.
Área de GestiónEn relación al área de gestión durante la fase de Reingeniería de Procesos, una de las principales actividades que se llevará a cabo es la presentación del MCI al centro.
Supone la introducción a los implicados en el proceso de implantación que será ejecutado, y proporcionará a estos una visión general sobre los hitos y horizonte que deberán ser marcados para la consecución con éxito de la implantación.
En esta presentación es clave la participación de los órganos directivos del centro (Gerencia, Dirección Médica, Dirección de Enfermería, Dirección de Atención al Ciudadano, Coordinadores Provinciales de TIC, Administración, etc.). La asimilación por parte de estos cargos del horizonte marcado propiciará la comprensión de las metas y objetivos a conseguir y la eliminación de falsas expectativas.
La gestión de las expectativas debe convertirse en un aspecto positivo de la implantación.
Huyendo siempre de la asimilación de falsas expectativas, el momento de implantación debe ser aprovechado como un momento de oportunidad para la mejora de la gestión en el centro, propiciando la modificación de pautas y procesos que se ejecutan erróneamente y que se encuentran arraigados, o mejorando determinados aspectos que el análisis de la actividad arroja como mejorables.
Esta actividad marcará el comienzo de las actividades de la fase de Reingeniería de Procesos
En todo proyecto es necesario identificar los riesgos y disparadores asociados al proyecto, clasificándolos según sus principales componentes, y según los tipos y categorías de riesgos más importantes.
Se identificará de manera clara la causa específica de cada riesgo y el objetivo u objetivos del proyecto sobre los que estos inciden.
Los disparadores (triggers) son síntomas o señales de advertencia de que un riesgo ha ocurrido o está a punto de ocurrir.
La identificación de riesgos es un proceso iterativo, que comienza en la fase de planificación del proyecto y finaliza en su cierre. Dentro de cada una de estas fases, el análisis de la situación en busca de riesgos ha de ejecutarse periódicamente.
El formato del enunciado de cada riesgo ha de asegurar que este se entiende claramente y sin ambigüedades.
Como resultado obtendremos un “GEST04. Registro de riesgos” riesgos que analizaremos en los siguientes procesos. Este registro, debe contener al menos:
En las fases de planificación es cuando es conveniente identificar los riesgos, si bien estos pueden aparecer en cualquier fase del ciclo de vida del proyecto y deben ser gestionados. Por ello la idoneidad de identificar los riesgos en la fase de Reingeniería de Procesos.
El análisis cualitativo de riesgo evalúa la prioridad de los riesgos identificados usando:
El análisis cualitativo es una forma de priorizar de forma rápida y rentable las prioridades de la planificación de la respuesta a los riesgos. En embargo, en ocasiones no es suficiente y es necesario acompañarlo de un análisis cuantitativo para algún riesgo en concreto más crítico.
El análisis cualitativo de riesgos debe ser revisado continuamente pues la situación puede cambiar.
Como salida, dotaremos al entregable “GEST04. Registro de riesgos” de información adicional a la obtenida en el proceso anterior, y que facilitarán su priorización a través del cálculo de su severidad (probabilidad * impacto).
Una vez hemos identificado los riesgos, y estos han sido analizados al menos cualitativamente, podemos planificar la respuesta a los mismos.
El resultado final de esta fase será plasmado en la definición del entregable “GEST05. Informe final Reingeniería de Procesos” que contendrá toda la información relevante recopilada durante las sesiones de reingeniería de procesos y todos aquellos aspectos críticos a tener en cuenta en sucesivas fases.
Este informe ha de contener al menos la siguiente información:
Durante la ejecución de los sesiones de Reingeniería de Procesos se habrán recopilado diferentes peticiones de cambio o solicitudes de mejora sobre la funcionalidad implementada sobre el nuevo sistema a implantar.
Estas peticiones de cambio o mejora deberán ser trasladadas a los referentes del ámbito funcional de la STIC para su análisis y toma en consideración.
La última parte de esta fase se centrará en la definición conjunta de un cronograma para la ejecución de las actividades de las siguientes fases (Preimplantación e implantación).
Haremos hincapié en el concepto “conjunto” pues ha de constituir un compromiso por todas las partes involucradas (equipo de implantación, centro, STI, proveedores, N3, etc.). Este compromiso, en relación a la fase de preimplantación debe garantizar que el centro se encuentre preparado y adecuado para el aterrizaje del equipo de implantación al completo al final de dicha fase, y que, una vez comience la fase de implantación, ninguna de las partes involucradas se va a encontrar en un estado bloqueado que le impida completar con éxito su responsabilidad de cara a la fecha propuesta de arranque.
Área FuncionalDe las primeras actividades que los responsables del centro deberán llevar a cabo en cuento comienza la fase de Preimplantación están todas aquellas relacionadas con la parametrización y configuración de los Módulos Corporativos relacionados. De estos hacemos especial hincapié en Estructura y los procesos de autentificación.
En relación a la estructura física es importante reflejar, tal cual, la realidad física y palpable de las localizaciones y divisiones del centro: edificios, plantas, controles de enfermería, habituaciones, etc.
Dado que Estructura incluye algunas limitaciones con respecto a las opciones de modificación de elementos ya incluidos y de análisis de la información contenida, para la definición de la estructura se recomienda la utilización de una plantilla que nos permitirá plasmar de forma jerárquica dicha estructura antes de su mecanización en el Módulo Corporativo.
Esta plantilla permite analizar la coherencia y estandarización de los datos incluidos de forma fluida para detectar correcciones necesarias sobre la misma.
Una vez garantizado que el contenido de la misma es correcto, se puede proceder a su mecanizado sobre el sistema.
Independientemente de la utilización de una plantilla para la definición de estructura o la mecanización directa en el sistema, existen una serie de aspectos que es recomendable sean tenidos en cuenta:
Finalmente, bien directamente a través de la plantilla utilizada para la definición, o bien mediante una exportación de la aplicación ESTRUCTURA, deberemos devolver el catálogo de elementos del árbol de estructura física, que servirá como entrada a posteriores procesos.
Para la definición de la estructura funcional o de las modificaciones necesarias sobre esta, se atenderá en todo caso a las directrices y recomendaciones marcadas por el Servicio de Cartera de Servicios.
Además de dichas recomendaciones, es recomendable tener en cuenta que las decisiones que sean tomadas a la hora de definir o modificar la estructura funcional de un centro, afectan o tienen incidencia directa en los siguientes aspectos:
En relación a las Líneas asistenciales en estructura, para cada UF final, se debe definir, para cada uno de los centros del hospital, dichas líneas.
Los valores posibles son:
Ejemplos:
Se incluyen en este bloque las actividades relacionadas con la preparación de todos los procesos de autentificación, gestión de usuarios y contraseñas, perfiles, permisos, etc.
La correcta ejecución de las actividades relacionadas con los procesos de autentificación es clave para el arranque, dado que es imprescindible que todos los usuarios puedan acceder al sistema y puedan hacerlos con los permisos y roles concretos que necesitan para la ejecución de su actividad. La experiencia nos indica que la realización de esta actividad de forma manual, supone un alto grado de posibilidad de error que no saldrá a la luz hasta el mismo día del arranque, tanto referidos a usuarios que falten, como a asignación incorrecta de roles o permisos en las diferentes estaciones. En este caso su única opción de mitigación pasa por formar un equipo de contingencia que subsanen estos errores.
Por el contrario, experiencias en otros centros, que basaron la ejecución de estas tareas en la utilización de herramientas automatizadas para la carga de operadores y profesionales, obtuvieron resultados mucho más satisfactorio dado que, si bien la eliminación total de errores no fue posible, el números de estos disminuyó drásticamente.
El equipo de implantación debe colaborar con el centro para garantizar el éxito de estas actividades, facilitando un primer cruce de los usuarios del sistema a sustituir, con los ya existentes en MACO. Esto permitirá detectar cuales coinciden unívocamente, cuales pueden coincidir con uno o más usuarios, y cuáles de forma certera no están en este módulo central.
Para ello, deben utilizarse procedimientos de análisis de información basados en reglas acordadas con el hospital que permitirán categorizar a los usuarios en estos grupos.
[ACT-PRE-FUNC-3.2] Preparar procesos de Autentificación a través de DMSAS
De igual forma que para aplicaciones que gestionen sus usuarios y perfiles a través de MACO es necesario preparar los procesos de autentificación y la carga de usuarios en sistemas en lo que la autentifican se lleva a cabo a través DMSAS.
Es necesario verificar de forma previa al arranque durante la fase de preimplantación que todos los usuarios que vayan a utilizar estos sistemas que se autentifican a través de DMSAS, dispongan de usuario en el dominio y tengan asociado el rol/perfil correspondiente.
De igual forma que para aplicaciones que gestionen sus usuarios y perfiles a través de MACO es necesario preparar los procesos de autentificación y la carga de usuarios en sistemas en lo que la autentifican se lleva a cabo a través de otros mecanismos de autentificación, como pueden ser certificados digitales, dni electrónico, etc.
Es necesario verificar de forma previa al arranque durante la fase de preimplantación que todos los usuarios que vayan a utilizar estos sistemas de autentificación dispongan de los elementos necesarios y tengan asociado el rol/perfil correspondiente.
Otro de los procesos que mayor dedicación necesitan por parte del centro para La preparación del comienzo de la implantación es la configuración y adecuación de todos los módulos corporativos centralizaos relacionados directa o indirectamente con el proyecto.
Son Módulos Centralizados por ejemplo: Citaweb, MPA, APD, PDI, BDU, AGD, ETC
El conjunto de sistemas, la forma y el grado en la que estos serán afectados dependerá específicamente de cada proceso de implantación y debe ser especializado en cada Modelo Corporativo de Implantaciones MCI que se defina sobre el marco del MCMI. A pesar de ello, el objetivo final sobre todos ellos son los mismos:
Es importante reseñar que esta configuración deberá llevarse a cabo en:
En el conjunto de actividades englobadas dentro de este apartado llevaremos a cabo una serie de acciones encaminadas a completar la definición de la parametrización del sistema a implantar.
En la fase de Reingeniería de procesos, durante las sesiones de reingeniería se habrá comenzado a reflejar los valores de los parámetros y tablas maestras que se hayan acordado durante dichas sesiones.
En previsión de que existan parámetros o valores de tablas maestras que, bien por falta de tiempo o bien por necesidad de escalar la decisión sobre sus valores a otro ámbito, no hayan podido ser acordados durante la sesión (y recogido en las plantillas de parametrización), antes de finalizar dicha fase, estas plantillas han de ser facilitadas al centro para que sean finalizadas (proceso “[P-RP-FUNC-9] Entregar plantillas de parametrización”).
La finalización de la recogida de información en estas plantillas para la definición de la parametrización debe ser llevada a cabo como decimos por el centro con el apoyo consultivo de SSCC y equipo de implantación.
Esta parametrización dará como resultado una serie de documentos que definirán los valores de los parámetros cuya potestad de decisión están en el centro, y la definición de los valores de una serie de tablas maestras parametrizables.
Una vez hemos definido la parametrización del sistema en el proceso “[ACT-PRE-FUNC-5.1] Definir parametrización del sistema a implantar”, y hemos recogido el resultado en el entregable “FUNC11. Parametrización del.
En relación a los valores de tablas maestras, son de aplicación los valores incluidos en el nuevo sistema, que a su vez hace uso de tablas de valores y aplicaciones centralizadas, utilizando un conjunto de datos maestros tipo.
Para los procesos de migración de datos de un sistema origen diferente hacia un sistema del SAS, es necesario un mapeo de determinados valores maestros.
Ídem ocurre para la implementación de procesos de integración entre sistemas del SAS y sistemas terceros. En este caso, los valores a utilizar en la integración son igualmente los definidos en el sistema del SAS.
Es necesario por tanto en muchos casos un proceso de mapeo entre los valores de los parámetros y las tablas maestras del sistema origen y los del nuevo sistema a implantar. De este proceso obtendremos como salida el entregable “FUNC12. Mapeos de tablas maestras”.
Con respecto a la definición de los mapeos es importante tener en cuenta la casuística relacionada con los mapeos con cardinalidad N..1, 1..N y N..N
En todo caso un mapeo ha de ser unívoco, por lo que cada valor de origen ha de ser mapeado a uno y solo un valor de destino. Esto nos permitirá automatizar los procesos de migración e integración de datos.
OJO: es diferente el mapeo que se utilizará para las migraciones y las integraciones en sentido SISTEMA_ORIGINAL > NUEVO_SISTEMA, que el mapeo que se utilizará las integraciones en sentido NUEVO_SISTEMA > SISTEMA_ORIGINAL.
Tendremos así dos mapeos:
Para el flujo de información A donde el mapeo es desde el sistema origen hacia el nuevo sistema, deberemos tener cuidado con los mapeos de datos con cardinalidad 1..N y N..N, correspondiendo el primer literal a la cardinalidad en el sistema original y el segundo a la cardinalidad en el nuevo sistema.
Para los flujos de información de tipo B, y donde el mapeo es desde el nuevo sistema hacia el sistema origen, deberemos tener cuidado con los mapeos de datos con cardinalidad N..1 y N..N, correspondiendo el primer literal a la cardinalidad en el sistema original y el segundo a la cardinalidad en el nuevo sistema.
En función de la correspondencia de datos nos podemos encontrar los siguientes escenarios:
Estrategia para definir el mapeo de datos A para Flujos de información (SISTEMA_ORIGINAL > NUEVO_SISTEMA).
CARD. SISTEMA ORIGINAL | CARD. NUEVO SISTEMA | OBSERVACIONES |
|---|---|---|
1 | 1 | En este caso, no existe mayor problema, pues es posible mapear un valor del sistema origen a un valor del sistema destino de forma unívoca. |
N | 1 | En Este caso, aunque varios valores del sistema original sean mapeados al mismo valor destino, seguimos teniendo una asignación de cada valor origen a uno de destino de forma unívoca, por lo que no habría problemas más allá de la pérdida de la diferenciación entre los n valores de origen, que son sintetizados en un único valor |
1 | N | En este caso, no existe una relación unívoca entre el valor del sistema original y los del nuevo sistema, por lo que no es posible sistematizar el proceso de migración o integración. Es por ello necesario convertir la relación 1..N en una relación 1..1 seleccionando uno de los N valores del nuevo sistema correspondientes como el valor por defecto en la migración o integración de estos datos. |
N | N | En este caso, no existe una relación unívoca entre el valor del sistema original y los del nuevo sistema, por lo que no es posible sistematizar el proceso de migración o integración. Es por ello necesario convertir la relación N..N en una relación N..1 seleccionando uno de los N valores del nuevo sistema correspondientes como el valor por defecto en la migración o integración de estos datos. |
Estrategia para definir el mapeo de datos A para Flujos de información (NUEVO_SISTEMA > SISTEMA_ORIGINAL).
CARD. SISTEMA ORIGINAL | CARD. NUEVO SISTEMA | OBSERVACIONES |
|---|---|---|
1 | 1 | En este caso, no existe mayor problema, pues es posible mapear un valor del sistema origen a un valor del sistema destino de forma unívoca. |
N | 1 | En este caso, no existe una relación unívoca entre el valor del nuevo sistema y los del sistema original, por lo que no es posible sistematizar el proceso de integración. Es por ello necesario convertir la relación N..1 en una relación 1..1 seleccionando uno de los N valores del sistema original correspondientes como el valor por defecto en la integración de estos datos. |
1 | N | En Este caso, aunque varios valores del sistema destino sean mapeados al mismo valor del sistema original, seguimos teniendo una asignación de cada valor origen a uno de destino de forma unívoca, por lo que no habría problemas más allá de la pérdida de la diferenciación entre los n valores de origen, que son sintetizados en un único valor |
N | N | En este caso, tampoco existe una relación unívoca entre el valor del nuevo sistema y los del sistema original, por lo que no es posible sistematizar el proceso de integración. Es por ello necesario convertir la relación N..N en una relación 1..N seleccionando uno de los N valores del sistema original correspondientes como el valor por defecto en la integración de estos datos. |
En resumen, es necesario tener en cuenta que los mapeos de datos son bidireccionales, y así han de ser definidos para dar cobertura correctamente a los procesos de migración y de integración (para los sentidos de flujo de integración utilizado).
Sobre diferentes sistemas origen, la ejecución del proceso de implantación puede suponer una modificación de su alcance, y de sus circuitos de interoperabilidad.
Ante esta situación, es común que surja la necesidad de modificar el sistema origen para adecuarlo a este nuevo escenario. Modificaciones comunes pueden ser las siguientes:
Sobre diferentes sistemas origen, la ejecución del proceso de implantación puede suponer una modificación de su alcance, y de sus circuitos de interoperabilidad.
Ante esta situación, es común que surja la necesidad de modificar el sistema origen para adecuarlo a este nuevo escenario. Modificaciones comunes pueden ser las siguientes:
Todas las modificaciones que se acuerden sean necesarias llevar a cabo, serán incluidas en un registro para su control.
El alcance concreto deberá haberse debatido durante el proceso “[P-RP-FUNC-4] Sesiones de análisis de procesos”, y basarse en los acuerdos plasmados en el entregable “GEST05. Informe final Reingeniería de Procesos”.
Por último, del acuerdo de las modificaciones a llevar a cabo deberá surgir la actualización del “FUNC06. Plan de Pruebas de los sistemas origen”.
En el proceso anterior “[ACT-PRE-FUNC-6.1] Definir modificaciones necesarias sobre sistema origen” se definen las modificaciones sobre los sistemas origen necesarias para su convivencia con los nuevos sistemas tras la finalización d.
Es caso normal que una vez un producto es impmlantado o desplegado en determinados entornos con características similares al entorno definitivo de producción, se proceda a ejecutar sobre dicha instancia determinados planes de prueba no relacionados en si con el proceso de implantación sino con el de construcción.
El ejemplo típico es la ejecución de planes de pruebas de sistemas o de estrés. Debido a que necesitan de un entorno similar a producción no es concluyente los resultados que pudieran desprenderse de su ejecución en un entorno de desarrollo, por lo que, si bien son actividades correspondientes a la fase de Construcción, se postpone su ejecución hasta el despliegue del mismo, por lo que la actividad se enmarca temporalmente dentro de una orden de implantación.
De esta ejecución de pruebas surgirá un resultado y una serie de conclusiones que pueden mostrar la necesidad de implementar una serie de optimizaciones sobre los productos evaluados. Es en el marco de esta tarea donde los responsables del desarrollo incorporarían estas mejoras, que administrativamente hablando formarían parte del alcance de la orden de trabjo de construcción (aunque temporalmente coincidan en fase de implantación).
Área FormaciónEn esta actividad seguiremos completando el Plan de Formación.
Durante la fase de Preimplantación, se adecuarán los planes formativos al centro, se personalizarán los contenidos de manuales y guías a las funcionalidades que necesitan cada perfil según la información obtenida en la Reingeniería de Procesos, se propondrá un Calendario de Formación para los tres módulos de DAH, teniendo en cuenta los distintos perfiles existentes, además de realizar la transferencia del conocimiento a los usuarios expertos.
El Plan de formación debe incluir al menos la siguiente información:
En caso de ser necesario la preparación de material previo para llevar a cabo la formación, deberá ser confeccionado en el transcurso de esta actividad.
Se incluye dentro de esta actividad la preparación de todos los juegos de datos necesarios para disponer de casuísticas suficientes para impartir la formación para todos los asistentes.
Se incluye igualmente la adecuación de guías, esquemas, y demás material de apoyo si así es necesario.
Por último, se procederá a validar con el centro el Plan de formación confeccionado.
Este proceso será ejecutado hasta conseguir la validación de dicho plan.
El objetivo de este proceso es facilitar a los responsables TIC del centro cuanta formación y conocimiento necesiten sobre la nueva herramienta a implantar.
Se llevarán a cabo sesiones específicas de formación sobre aspectos tanto funcionales como técnicos.
Se implementarán igualmente cualquier otra vía de transferencia del conocimiento que se estime oportuno para asegurar la misma: trabajo conjunto, tutorización, etc.
Durante esta fase se seguirá profundizando en Transferir el Conocimiento a los usuarios expertos de referencia, en este caso usuarios TIC, propiciando así que se familiaricen cuantos antes con los módulos y puedan maximizar el aporte de valor añadido y las mejores soluciones durante el soporte N0 al resto de usuarios del centro durante la fase de consolidación.
Disponer de un periodo de tiempo mayor para practicar con los módulos, resolver dudas, etc., antes del arranque redundará positivamente en una mayor destreza con los nuevos sistemas, permitiendo ofrecer el soporte deseado, y facilitando la necesaria autonomía de los usuarios y del centro en general a la salida del equipo de implantación.
Por esto, insistiremos en la implicación al 100% de estos usuarios en la Transferencia del Conocimiento, garantizándose así que la salida del equipo de implantación sea un proceso natural y exitoso.
Área de MigraciónEs en esta fase donde se decidirá en función del número de registros finalmente incluidos en el proceso de migración, el mecanismo que se utilizará para marcar la frontera entre los datos considerados históricos y los datos considerados activos. Se definen así los dos bloques de migración estipulados en el MCI (bloque de migración de histórico y bloque de migración de activo).
Este mecanismo puede ser una fecha de corte, un proceso de verificación de datos migrados, o cualquier sistema que se considere fiable para garantizar que el 100% de los datos previstos son migrados y que ninguno es migrado dos o más veces.
La decisión al respecto se recogerá en la Definición del Alcance de las Migraciones.
El N3 del sistema origen, en colaboración con el hospital debe preparar los procesos de extracción y transformación de información de acuerdo a la Definición del Alcance de migración acordada, y conforme a las estructuras de datos que marque el migrador de datos específico del sistema a implantar.
Una vez ha finalizado la implementación de los procesos de extracción de datos del sistema origen, se ha de verificar que la información generada a partir de dichos procesos de extracción cumple con las restricciones, normativas, acuerdos y peculiaridades recogidas para cada entidad en el entregable “MIGR02. Definición Alcance de las Migraciones”, subsanándose aquellos aspectos que no cumplan con dichos criterios.
Para la elección de los registros incluidos en las pruebas de migración unitarias (catas), es recomendable hacer una selección de datos especialmente complejos (pacientes con historia clínica especialmente compleja, tratamientos complejos, agendas con múltiples variantes, etc.) que cubran la mayor parte de las casuísticas posibles.
La experiencia nos indica que 100 es un número suficiente de pacientes a ser incluidos en esta selección con toda su información asociada, si bien será el centro el que decida este número en la medida en la que estime oportuno para garantizar la cobertura de todas las casuísticas.
Los datos elegidos en esta actividad son sobre los que posteriormente se ejecutará el “MIGR04. Plan de pruebas de migración Cualitativas.”.
Esta información será incluida en el entregable “MIGR02. Definición Alcance de las Migraciones” completando su contenido.
Área de IntegraciónEl Modelo Corporativo de Implantaciones marca unos escenarios de integración concretos basados en los Contratos de Integración facilitados por la OTI. Estos Contratos de Integración son de obligado cumplimiento por todos los sistemas a integrar.
Si bien la mayoría de sistemas existentes en Andalucía ya tienen experiencia en procesos de integración con los sistemas del SAS, es probable que entren en juego sistemas que aún no hayan pasado por este proceso.
Para estos, la fase de Preimplantación será clave para la adecuación de sus sistemas a los Contratos de Integración, y dado que estos procesos suelen ser costosos en tiempo y esfuerzo para el proveedor, es importante el comienzo de los mismos con suficiente antelación para garantizar su finalización en tiempo y forma de cara al inicio de la fase de Implantación.
Para dicha fase, todos los sistemas departamentales y terceros que se integren con el sistema a implantar deberán estar desplegados en el entorno de pruebas para la certificación de los procesos de integración, por lo que al inicio de esta fase se solicita formalmente a cada uno de los proveedores involucrados la implementación de dichos procesos de integración.
Una vez conocido el alcance de las integraciones en el ámbito de la implantación, y definido en la fase de reingeniería de procesos el entregable “GEST07. Cronograma conjunto implantación”, podremos analizar las fechas límite para disponer de los desarrollos que sea necesario llevar a cabo sobre procesos de integración.
Estas fechas límites en todo caso deberán ser acordes a los hitos y compromisos marcados de forma conjunta entre el centro y el equipo de implantación, cumpliendo el cronograma conjunto de implantación.
Sin embargo, dependencias específicas en el centro con otros proyectos, con necesidad de equipamiento, con convivencia con otros procesos de mejora e implantación, pueden hacer necesario restringir aún más los hitos máximos definidos en el cronograma de implantación para garantizar por un lado los compromisos adquiridos en este, y por otro, la convivencia del proyecto de implantación con otros procesos relacionados en el hospital y el día a día.
Esta actividad será implementada por los proveedores relacionados con los sistemas de información a integrar, con el apoyo de la OTI y del equipo de implantación.
En la misma, deberán implementarse los cambios y desarrollos necesarios para cumplir con el alcance acordado en la fase de reingeniería de procesos, y en las fechas límites acordadas.
Una vez los desarrollos relativos a las integraciones son finalizados, estos deberán ser desplegados en los entornos preproductivos para poder ser verificados antes de su puesta en producción.
En los entornos preproductivos debe disponerse de una instancia de cada uno de los sistemas a integrar, de manera que las pruebas de integración puedan ser realistas y completas.
Los despliegues de estos desarrollos deberán hacerse igualmente cumpliendo con los compromisos del “GEST07. Cronograma conjunto implantación” y con las fechas límite acordadas en la actividad “[P-PRE-INTE-2] Establecer fecha límite disponibilidad desarrollos integraciones”.
Área de Sistemas e InfraestructurasAl comienzo de la fase de preimplantación, y una vez se haya hecho entrega de los entornos preproducitvos, deberá llevarse a cabo la publicación de los accesos a estos sistemas por los usuarios finales de forma que quede preparado para la realización de las pruebas de integración, de migración, sesiones de formación, etc.
El centro deberá verificar que todos los puestos de usuario cumplen con los requisitos mínimos establecidos para cada uno de los sistemas de información que entran en juego en el proceso de implantación.
Suelen especificarse requisitos relativos a:
Sobre los equipamientos que no cumplan con dichos requisitos, el centro deberá establecer un Plan de sustitución y mejora de equipamiento que deberá ejecutarse antes del comienzo de la fase de Arranque, de manera que se garantice que tras el mismo, los usuarios que comiencen a utilizar el nuevo sistema, no se encuentran con incidencias relativas a estos requisitos.
Dado que esta tarea es tediosa, se recomienda comenzar con ella lo antes posible. Para llevarla a cabo suele ser necesario:
En esta actividad, se procederá a la verificación en el centro de los requisitos mínimos necesarios que han de cumplir los equipos cliente puestos a disposición de la formación de manera que se garantice que esta pueda llevarse a cabo sin problemas.
Incluye todos los requisitos que deberá cumplir un puesto cliente normal más aquellos adicionales que se estimen convenientes para poder ser utilizados en sesiones de formación (cañones de proyección, orientación de las mesas, pizarras, etc).
Una de las actividades en las que suele colaborar el n3 y los equipos de implantación en las primeras instalaciones de un nuevo producto de envergadura es en la creación de una maqueta master para los entornos de los sistemas a desplegar.
Esta maqueta consiste en una serie de imágenes de SO que construye Sistemas con el objetivo de tener preparada la base operacional donde poder desplegar a posteriori los productos involucrados. En dicha maqueta se seleccionan e intervienen elementos como el sistema operativo, la versión de java, el contenedor de aplicaciones a utilizar, los elementos de balanceado, la versión de la base de datos, etc.
Sistemas procede a la creación de la maqueta de la estructura de las bases de datos que se utilizarán con los sistemas involucrados. Para dicha creación, contará con el apoyo del n3 que colaborará en la resolución de dudas sobre dicho proceso y que posteriormente procede a la validación del resultado final obtenido.
Sistemas procede a la creación de la maqueta del software base de los servidores a utilizar con los sistemas involucrados. Para dicha creación, contará con el apoyo del n3 que colaborará en la resolución de dudas sobre dicho proceso y que posteriormente procede a la validación del resultado final obtenido.
En dicha maqueta se seleccionan e intervienen elementos como el sistema operativo, la versión de java, el contenedor de aplicaciones a utilizar, los elementos de balanceado, etc.
Sistemas procede a la creación de la maqueta de la estructura de las bases de datos que se utilizarán con los sistemas involucrados. Para dicha creación, contará con el apoyo del n3 que colaborará en la resolución de dudas sobre dicho proceso y que posteriormente procede a la validación del resultado final obtenido.
Sistemas procede a la creación de la maqueta del software base de los servidores a utilizar con los sistemas involucrados. Para dicha creación, contará con el apoyo del n3 que colaborará en la resolución de dudas sobre dicho proceso y que posteriormente procede a la validación del resultado final obtenido.
En dicha maqueta se seleccionan e intervienen elementos como el sistema operativo, la versión de java, el contenedor de aplicaciones a utilizar, los elementos de balanceado, etc.
Por último el n3 participará y apoyará en la validación básica funcional de la creación de dichas maquetas master. Para ello, estas serán desplegadas en algún entorno de verificación, y sobre las mismas se ejecutarán una serie de pruebas encaminadas a detectar posibles fallos iniciales en la concepción y elaboración de la misma.
El Modelo Corporativo Marco de Implantaciones (MCMI) define una serie de entornos necesarios para implementar con garantías y seguridad todas las actividades involucradas en un proceso de implantación.
El número y características de los entornos viene marcada por las actividades que deben poder ejecutarse paralelamente en el tiempo y la interdependencia entre estas.
Los entornos comúnmente utilizados son:
Para la realización de la fase de Preimplantación se debe disponer de los correspondientes entornos preproductivos con la versión más actualizada del aplicativo a implantar sobre el que se puedan llevar a cabo las sesiones de formación, la preparación de los procesos de migración e integración, etc.
Estos entornos deben estar con la suficiente antelación para que el equipo de implantación pueda verificar que funciona correctamente de cara a la ejecución de las actividades que de estos entornos dependen.
La entrega de estos entornos será entregada igualmente conforme al cronograma estratégico de las implantaciones y de acuerdo a las fechas solicitadas en el proceso [P-APS-SIST-2.4] Solicitar despliegue de entornos.
La entrega de un entorno específico conlleva la gestión correspondiente de los canales de comunicación hacia y desde el mismo.
De esta forma, toda entrega de un entorno, aunque existiera previamente, debe ir acompañada con la gestión de las reglas de comunicación, apertura de firewalls, etc. necesarios para que los sistemas incluidos en el entorno puedan comunicarse entre sí según ha especificado el fabricante del aplicativo, y a su vez, estos puedan comunicarse con el resto de sistemas que vayan a conformar el ecosistema de aplicaciones involucradas (sistemas corporativos centralizados, departamentales, sistemas de terceros, aplicaciones distribuidas, etc.).
En el apartado “7.1.2.3 [P-APS-SIST-2.2] Gestionar apertura de comunicaciones para entornos de RP” más atrás puede obtener más información con respecto a este tema.
En relación específica a este proceso, deberá gestionarse la apertura de comunicaciones necesarias para los entornos Preproductivos solicitados y que serán utilizado durante la fase de Preimplantación e Implantación.
Una vez recepcionado los entornos preproductivos, el equipo de implantación deberá verificar que el entorno funciona conforme a sus expectativas y cumple con las funcionalidades necesarias para llevar a cabo las actividades de la fase de Preimplantación e Implantación.
Si bien la verificación será llevada a cabo por el equipo de implantación, la responsabilidad de que este proceso se pase con éxito recae en Sistemas STIC, quien entrega el entorno y deberá ejecutar las acciones necesarias para garantizar que el entorno facilitado sea totalmente operativo.
Para poder llevar a cabo las actividades de implantación que utilizan como base los entornos de preproducción, en ocasiones es necesario precargar estos con un juego de datos más escueto o mas completo que permita la simulación de determinados escenarios o casos de prueba o que permita la asimilación a un entorno real (en cuanto a nº de registros) para ejecutar determinados planes de pruebas de estrés, de sistemas, etc.
Las acciones necesarias para precargar este juego de datos quedarán enmarcadas en esta actividad.
Una vez dispongamos de un entorno preproductivo con el juego de datos que necesitemos cargado, si dentro del alcance de la implantación se incluye la ejecución de un plan de pruebas de sistemas, deberemos proceder a ello en el marco de esta actividad.
El objetivo de este plan es definir todas las pruebas de sistemas o de estrés necesarias para verificar que no existen problemas de rendimiento, cuellos de botella, eficiencia, tiempos de respuesta, etc.
De este plan, obtendremos un entregable con el resultado de dichas pruebas.
El Modelo Corporativo Marco de Implantaciones (MCMI) define una serie de entornos necesarios para implementar con garantías y seguridad todas las actividades involucradas en un proceso de implantación.
El número y características de los entornos viene marcada por las actividades que deben poder ejecutarse paralelamente en el tiempo y la interdependencia entre estas.
Los entornos comúnmente utilizados son:
Para la realización de la fase de Implantación y para la preparación de la fase de Arranque se debe disponer del correspondiente entorno de producción con la versión más actualizada del aplicativo a implantar. Sobre él se llevará a cabo la migración de datos históricos en la fase de implantación, el despliegue de configuraciones y parametrizaciones, o el despliegue de los desarrollos de integración entre otros.
Estos entornos deben estar con la suficiente antelación para que el equipo de implantación pueda comenzar sin bloqueo la configuración y preparación de los mismos de cara a la ejecución de las actividades que de este entorno dependen.
La entrega de estos entornos será entregada igualmente conforme al cronograma estratégico de las implantaciones y de acuerdo a las fechas solicitadas en el proceso [P-APS-SIST-2.4] Solicitar despliegue de entornos.
La entrega de un entorno específico conlleva la gestión correspondiente de los canales de comunicación hacia y desde el mismo.
De esta forma, toda entrega de un entorno, aunque existiera previamente, debe ir acompañada con la gestión de las reglas de comunicación, apertura de firewalls, etc. necesarios para que los sistemas incluidos en el entorno puedan comunicarse entre sí según ha especificado el fabricante del aplicativo, y a su vez, estos puedan comunicarse con el resto de sistemas que vayan a conformar el ecosistema de aplicaciones involucradas (sistemas corporativos centralizados, departamentales, sistemas de terceros, aplicaciones distribuidas, etc.).
En el apartado “7.1.2.3 [P-APS-SIST-2.2] Gestionar apertura de comunicaciones para entornos de RP” más atrás puede obtener más información con respecto a este tema.
En relación específica a este proceso, deberá gestionarse la apertura de comunicaciones necesarias para el entorno de Producción solicitado y que serán utilizado durante la fase de Implantación y posteriores.
Una vez recepcionado el entorno de producción, el equipo de implantación deberá verificar que el entorno funciona conforme a sus expectativas y cumple con las funcionalidades necesarias para llevar a cabo las actividades de la fase de Preimplantación e Implantación.
Si bien la verificación será llevada a cabo por el equipo de implantación, la responsabilidad de que este proceso se pase con éxito recae en Sistemas STIC, quien entrega el entorno y deberá ejecutar las acciones necesarias para garantizar que el entorno facilitado sea totalmente operativo.
Es necesario tener en cuenta que especialmente durante la fase de implantación, se lleva a cabo una de las labores más tediosas y costosas que es la relacionada con la asignación de permisos y perfiles a todos los usuarios sobre el entorno en producción.
Eso quiere decir, que en el momento que se publiquen dichos accesos, si no se aplican medidas adicionales, los usuarios podrían entrar en el sistema en producción, pudiendo tergiversar la información migrada en histórico y pudiendo suponer un problema de cara a la migración de los datos activos.
Esta precaución es de aplicación en aquellos procesos de implantación en las que sea necesario llevar a cabo las actividades de migración.
Para ello, si el sistema origen no es el mismo que el nuevo sistema (caso de nivelaciones por ejemplo), llegado este momento deberemos haber activado el modo transición en los sistemas en producción para evitar, mediante gestión de comunicaciones, etc, el acceso al sistema
Área de Análisis y Explotación de DatosEl centro deberá comenzar las actividades de desarrollo planificadas. Para esta labor, contará con el apoyo de miembros del equipo de implantación especializados en el área funcional y en el conocimiento del modelo de datos de las estaciones, quienes asesorarán a los desarrolladores del centro, dentro del alcance del Plan de Transferencia del Conocimiento, sobre la forma más idónea de obtener la información que en cada caso sea demandada.
Al finalizar esta fase, es conveniente que el centro haya finalizado las actividades de desarrollo, para que estas puedan ser verificadas durante la siguiente fase con datos reales.
Área de GestiónEl principal objetivo de las actividades de esta área de conocimiento va enfocado hacia el seguimiento y control de los avances en los procesos de adecuación de cada uno de los involucrados.
Del correcto cumplimiento de todos ellos en tiempo y forma dependerá al 100% el inicio de la Fase de Implantación y por transitividad, el cumplimiento del compromiso de fecha de arranque.
Será en esta fase por tanto donde se inicie el establecimiento de forma periódica de 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.
Este proceso supone un bloque de acciones relativas a la tramitación de todas las solicitudes necesarias para la ejecución de actividades dependientes de terceros.
Si bien suponen poca carga de esfuerzo, si suelen suponer un tiempo de ejecución considerable al estar envueltas en diferentes procesos de tramitación y aprobación. La experiencia nos demuestra que en determinados centros, la gestión de estas solicitudes ha sido el foco inicial del retraso en la ejecución de tareas críticas, por lo que debe ejecutarse la gestión de estas al momento inicial de la fase, minimizando así el riesgo de bloqueo. Englobaríamos aquí actividades como la solicitud de los administradores delegados de MACO, gestiones sobre BDU, ESTRUCTURA, CITAWEB, MPA, etc.
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:
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)
Área Funcional Área Formación Área de Migración Área de Integración Área de Sistemas e Infraestructuras Área de Análisis y Explotación de Datos Área de Gestión Área Funcional Área de Sistemas e Infraestructuras Área de Gestión Área Funcional Área de Migración Área de Integración Área de Sistemas e Infraestructuras Área de Gestión Área Funcional Área de Integración Área de Sistemas e Infraestructuras Área de Gestión Área Funcional Área de Migración Área de Integración Área de Gestión Área de Sistemas e Infraestructuras Área de Gestión Área Funcional Área Formación Área de Migración Área de Integración Área de Sistemas e Infraestructuras Área de Análisis y Explotación de Datos Área de Gestión Área de Gestión