Versiones comparadas

Clave

  • Se ha añadido esta línea.
  • Se ha eliminado esta línea.
  • El formato se ha cambiado.

...

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.

Matriz RASCI

PerfilResponsabilidad
Equipo de implantación
Jefe de equipo de implantaciónS
Perfil de sistemasC
Centro
Responsable TIC del centroC  I
Proveedores soporte N3
Soporte N3 del producto existente a sustituirC
Soporte N3 de sistemas terceros o departamentales afectadosC

Dependencias

Actividad
[ACT-APS-SIST-2.2] Gestionar apertura de comunicaciones para entornos de RP
[ACT-PRE-SIST-5.1] Entregar entornos para PRE
[ACT-APS-GEST-2] Reunión de preparación y definición calendario de sesiones de RP

Catálogo de entregables

EntradaSalida
  • [SIST04] Catálogo de Apertura de comunicaciones
  • [GEST02] Calendario de sesiones de RP
  • [SIST02] Datos de conectividad de los entornos
  • [SIST10] Entornos de PRE
  • [SIST04] Catálogo de Apertura de comunicaciones
[ACT-PRE-SIST-5.3] Verificar entrega de los entornos para PRE

...

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

Matriz RASCI

PerfilResponsabilidad
Equipo de implantación
Jefe de equipo de implantaciónR
Perfil de migraciónS
STIC
Jefe de proyecto de la STICI
Área de sistemas de la STICA  C

Dependencias

Actividad
[ACT-APS-SIST-2.2] Gestionar apertura de comunicaciones para entornos de RP
[ACT-PRE-SIST-5.1] Entregar entornos para PRE
[ACT-APS-GEST-2] Reunión de preparación y definición calendario de sesiones de RP

Catálogo de entregables

EntradaSalida
  • [SIST04] Catálogo de Apertura de comunicaciones
  • [GEST02] Calendario de sesiones de RP
  • [SIST02] Datos de conectividad de los entornos
  • [SIST10] Entornos de PRE
  • [SIST10] Entornos de PRE
[ACT-PRE-SIST-5.4] Precarga con juego de datos del entorno de PRE

...

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

Matriz RASCI

PerfilResponsabilidad
STIC
Jefe de proyecto de la STICI
Proveedores de soporte N3
Soporte N3 del producto a implantarR  A

Dependencias

Actividad
[ACT-APS-GEST-2] Reunión de preparación y definición calendario de sesiones de RP

Catálogo de entregables

EntradaSalida
  • [GEST02] Calendario de sesiones de RP
--

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

...

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

Matriz RASCI

PerfilResponsabilidad
Equipo de implantación
Jefe de equipo de implantaciónI
Perfil de sistemasS
STIC
Jefe de proyecto de la STICI
Proveedores soporte N3
Soporte N3 del producto existente a sustituirS

Dependencias

Actividad
[ACT-APS-GEST-2] Reunión de preparación y definición calendario de sesiones de RP

Catálogo de entregables

EntradaSalida
  • [GEST02] Calendario de sesiones de RP

--

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

...

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

Matriz RASCI

PerfilResponsabilidad
Equipo de implantación
Jefe de equipo de implantaciónI
Perfil de sistemasC
Centro
Responsable TIC del centroR  A
STIC
Jefe de proyecto de la STICI

Dependencias

Actividad
[ACT-APS-SIST-2.4] Solicitar despliegue de entornos
[ACT-APS-GEST-4] HITO. Entrega producto versión visualizable
[ACT-APS-GEST-2] Reunión de preparación y definición calendario de sesiones de RP

Catálogo de entregables

EntradaSalida
  • [GEST02] Calendario de sesiones de RP
  • [EXT.GEST01] Cronograma estratégico de implantaciones
  • [SIST02] Datos de conectividad de los entornos
  • [SIST11] Entornos de PRO
[ACT-PRE-SIST-7.2] Gestionar apertura de comunicaciones para entornos PRO

...

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.

Matriz RASCI

PerfilResponsabilidad
Equipo de implantación
Perfil de integraciónC
Centro
Responsable TIC del centroR  A

Dependencias

Actividad
[ACT-PRE-SIST-7.1] Entregar entornos para PRO
[ACT-APS-GEST-2] Reunión de preparación y definición calendario de sesiones de RP

Catálogo de entregables

EntradaSalida
  • [SIST02] Datos de conectividad de los entornos
  • [GEST02] Calendario de sesiones de RP
  • [SIST11] Entornos de PRO
  • [SIST04] Catálogo de Apertura de comunicaciones
[ACT-PRE-SIST-7.5] Nivelar versión a la última disponible

Matriz RASCI

PerfilResponsabilidad
Equipo de implantación
Jefe de equipo de implantaciónI
STIC
Jefe de proyecto de la STICI
Proveedores soporte N3
Soporte N3 del producto existente a sustituirS

Dependencias

Actividad
[ACT-PRE-GEST-4] Hito. Verificación disponibilidad versión de producto requerida
[ACT-APS-GEST-2] Reunión de preparación y definición calendario de sesiones de RP

Catálogo de entregables

EntradaSalida
  • [GEST02] Calendario de sesiones de RP

--

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

...

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

Matriz RASCI

PerfilResponsabilidad
Equipo de implantación
Jefe de equipo de implantaciónA
Perfil de sistemasR
STIC
Jefe de proyecto de la STICI

Dependencias

Actividad
[ACT-PRE-SIST-7.1] Entregar entornos para PRO
[ACT-PRE-SIST-7.2] Gestionar apertura de comunicaciones para entornos PRO
[ACT-PRE-SIST-7.5] Nivelar versión a la última disponible
[ACT-APS-GEST-2] Reunión de preparación y definición calendario de sesiones de RP

Catálogo de entregables

EntradaSalida
  • [SIST02] Datos de conectividad de los entornos
  • [GEST02] Calendario de sesiones de RP
  • [SIST04] Catálogo de Apertura de comunicaciones
  • [SIST11] Entornos de PRO
  • [SIST11] Entornos de PRO
[ACT-PRE-SIST-7.4] Activar modo transición en el entorno de producció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 el acceso al mismo mediante gestión de comunicaciones, etc.

Matriz RASCI

PerfilResponsabilidad
Equipo de implantación
Jefe de equipo de implantaciónS
STIC
Área de sistemas de la STICR  A

Dependencias

Actividad
 [ACT-PRE-SIST-7.3] Verificar entrega de los entornos para PRO
[ACT-APS-GEST-2] Reunión de preparación y definición calendario de sesiones de RP

Catálogo de entregables

EntradaSalida
  • [SIST04] Catálogo de Apertura de comunicaciones
  • [SIST11] Entornos de PRO

--

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

...

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.

Matriz RASCI

PerfilResponsabilidad
Equipo de implantación
Jefe de equipo de implantaciónI
Perfil de integraciónS
Centro
Responsable TIC del centroI

Dependencias

Actividad
--

Catálogo de entregables

EntradaSalida

--

--


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

Matriz RASCI

PerfilResponsabilidad
Equipo de implantación
Jefe de equipo de implantación
Perfil funcionalC
Perfil de formación C
Perfil de migraciónC
Perfil de integraciónC
Centro
Responsable TIC del centroC  I
Responsable de cartera y servicios en el centroC
Referentes funcionales del centroI
STIC
Jefe de proyecto de la STICA  S
Responsables funcionalesC
Proveedores de soporte N3
Soporte N3 del producto a implantarC
Soporte N3 del producto a sustituirC
Soporte N3 de sistemas terceros o departamentales afectadosC

Dependencias

Actividad
--

Catálogo de entregables

EntradaSalida

--

  • [GEST08.x] Informes de seguimiento y control
  • [GEST10.x] Catálogo de Solicitudes de Cambio

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

Matriz RASCI

PerfilResponsabilidad
--

Dependencias

Actividad
--

Catálogo de entregables

EntradaSalida

--

--

[ACT-CON-GEST-3[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.

Matriz RASCI

PerfilResponsabilidad
--

Dependencias

Actividad
--

Catálogo de entregables

EntradaSalida

--

--

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

Matriz RASCI

PerfilResponsabilidad
--

Dependencias

Actividad
--

Catálogo de entregables

EntradaSalida

--

--

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

Matriz RASCI

PerfilResponsabilidad
--

Dependencias

Actividad
--

Catálogo de entregables

EntradaSalida

--

--


Ancla
FaseEXT
FaseEXT
Extensión

...

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

Matriz RASCI

PerfilResponsabilidad
--

Dependencias

Actividad
--

Catálogo de entregables

EntradaSalida

--

--

 Área Formación

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

...

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 conocimiento del uso de las nuevas aplicaciones o funcionalidades.

...

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

Matriz RASCI

PerfilResponsabilidad
--

Dependencias

Actividad
--

Catálogo de entregables

EntradaSalida

--

--

Área de Migración

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

...

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

Matriz RASCI

PerfilResponsabilidad
--

Dependencias

Actividad
--

Catálogo de entregables

EntradaSalida

--

--

Área de Integración

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

...

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

Image Removed Área de Sistemas e Infraestructuras

Matriz RASCI

PerfilResponsabilidad
--

Dependencias

Actividad
--

Catálogo de entregables

EntradaSalida

--

--

Image Added Área de Sistemas e Infraestructuras

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

...

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

Matriz RASCI

PerfilResponsabilidad
--

Dependencias

Actividad
--

Catálogo de entregables

EntradaSalida

--

--

 Área de Análisis y 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.

Matriz RASCI

PerfilResponsabilidad
--

Dependencias

Actividad
--

Catálogo de entregables

EntradaSalida

--

--


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

Matriz RASCI

PerfilResponsabilidad
--

Dependencias

Actividad
--

Catálogo de entregables

EntradaSalida

--

--


Ancla
FasePN3
FasePN3
Paso a N3

Á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

Matriz RASCI

PerfilResponsabilidad
Equipo de implantación
Jefe de equipo de implantaciónR  A
Perfil funcionalS
Perfil de formación S
Perfil de migraciónS
Perfil de integraciónS
Perfil de sistemasS
Centro
Responsable TIC del centroI
Referentes funcionales del centroI
STIC
Jefe de proyecto de la STICI
Área de Sistemas de la STICI
OTII
Responsables funcionalesI
CGESI
Proveedores de soporte N3
Soporte N3 del producto a implantarI

Dependencias

Actividad
--

Catálogo de entregables

EntradaSalida

--

  • [GEST24] Catálogo de problemas
  • GEST25] Informe de Alcance Final de la Implantación
  • [GEST26] Catálogo de FAQs y Problemas frecuentes
  • [GEST27] Catálogo de mejoras transmitidas o solicitadas por el centro durante la implantació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.

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.

Matriz RASCI

PerfilResponsabilidad
Equipo de implantación
Jefe de equipo de implantaciónR  A
Perfil funcionalS
Perfil de formación S
Perfil de migraciónS
Perfil de integraciónS
Perfil de sistemasS
Centro
Responsable TIC del centroS
Responsable de cartera y servicios en el centroS
Referentes funcionales del centroS
STIC
Jefe de proyecto de la STICS
Área de Sistemas de la STICS
OTIS
Jefe de proyectos Módulos centralizadosS
Responsables funcionalesS
CGESS
Proveedores de soporte N3
Soporte N3 del producto a implantarS
Soporte N3 del producto existente a sustituirS
Soporte N3 de sistemas terceros o departamentales afectadosS

Dependencias

Actividad
[ACT-PN3-GEST-1] Generación de documentación de estado de situación

Catálogo de entregables

EntradaSalida
  • [GEST24] Catálogo de problemas
  • GEST25] Informe de Alcance Final de la Implantación
  • [GEST26] Catálogo de FAQs y Problemas frecuentes
  • [GEST27] Catálogo de mejoras transmitidas o solicitadas por el centro durante la implantación
  • [GEST23] Informe de Lecciones Aprendidas
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 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.

    Matriz RASCI

    PerfilResponsabilidad
    Equipo de implantación
    Jefe de equipo de implantaciónR  A
    STIC
    Jefe de proyecto de la STICI
    Área de Sistemas de la STICI
    OTII
    Responsables funcionalesI
    CGESI
    Proveedores de soporte N3
    Soporte N3 del producto a implantarI

    Dependencias

    Actividad
    [ACT-PN3-GEST-1] Generación de documentación de estado de situación

    Catálogo de entregables

    EntradaSalida
    • [GEST24] Catálogo de problemas
    • GEST25] Informe de Alcance Final de la Implantación
    • [GEST26] Catálogo de FAQs y Problemas frecuentes
    • [GEST27] Catálogo de mejoras transmitidas o solicitadas por el centro durante la implantación
    --

    Matriz RASCI

    PerfilResponsabilidad
    Equipo de implantación
    Jefe de equipo de implantación
    Perfil funcional
    Perfil de formación 
    Perfil de migración
    Perfil de integración
    Perfil de sistemas
    Centro
    Responsable TIC del centro
    Responsable de cartera y servicios en el centro
    Referentes funcionales del centro
    STIC
    Jefe de proyecto de la STIC
    Área de Sistemas de la STIC
    OTI
    Jefe de proyectos Módulos centralizados
    Responsables funcionales
    CGES
    Proveedores de soporte N3
    Soporte N3 del producto a implantar
    Soporte N3 del producto existente a sustituir
    Soporte N3 de sistemas terceros o departamentales afectados