Guía Para El Procedimiento De Gestión De … · Web viewCadena de valor Catálogo de servicios de...

PROCESO PROVISIÓN DE SOLUCIONES TECNOLÓGICAS CÓDIGO RSGU04

GUÍA GUÍA PARA EL PROCEDIMIENTO DE GESTIÓN DE ARQUITECTURA DE TI VERSIÓN 1

GUÍA

Guía de apoyo al procedimiento de gestión de arquitectura de TI

BOGOTÁ D.C.2017

ELABELABORÓ: Profesional de Tecnologías de la InformaciónProfesional Oficina Asesora de Planeación

REVISÓ: Jefe Oficina Tecnologías de la InformaciónJefe Oficina Asesora de Planeación

APROBÓ: Jefe Oficina Tecnologías de la Información

FECHA:10/2/2017

FECHA: 06/07/2017

FECHA: 06/07/2017



Tabla de Contenido

1. Objetivo del Documento.....................................................................................................................................................................22. Alcance...............................................................................................................................................................................................2

3. Ámbito de Aplicación..........................................................................................................................................................................34. Desarrollo de los ejercicios de arquitectura de TI..............................................................................................................................3

4.1 Generalidades de los ejercicios de arquitectura de TI...................................................................................................................34.2 Tipos de proyectos para los ejercicios de arquitectura de TI.........................................................................................................5

4.3 Roles para realizar los ejercicios de arquitectura de TI..................................................................................................................74.4 Actividades en los ejercicios de arquitectura de TI........................................................................................................................8

5. Gestión de Proyectos de Arquitectura de TI....................................................................................................................................255.1 Generalidades Gestión de Proyectos de Arquitectura Empresarial de TI....................................................................................25

5.2 Ciclo de Vida de Proyectos de Arquitectura Empresarial de TI...................................................................................................265.3 Fases de Proyectos de Arquitectura de TI en la SuperSalud......................................................................................................27

5.4 Roles para realizar los ejercicios de arquitectura de TI................................................................................................................295.5 Actividades...................................................................................................................................................................................31

6. Documentos a elaborar según tipo de proyecto..............................................................................................................................336.1 Para Ejercicios de Arquitectura....................................................................................................................................................33

6.2 Para Gestión de proyectos:..........................................................................................................................................................437. Estructura de Repositorios documentales.......................................................................................................................................44

7.1 Repositorio documental para ejercicios de arquitectura de TI.....................................................................................................447.2 Repositorio documental para gestión de proyectos de arquitectura TI........................................................................................45

1



7.3 Nomenclatura de documentos......................................................................................................................................................47

1. Objetivo del Documento

Describir las consideraciones y actividades correspondientes al desarrollo de los ejercicios de arquitectura de TI, así como en la práctica de la gestión de proyectos para dichos ejercicios, en apoyo al cumplimiento del procedimiento de Provisión de las Soluciones Tecnológicas. Esta guía adopta las actividades fundamentales de la práctica de arquitectura en marcos como TOGAF, la práctica de gestión de proyectos en marcos como PMI, así como elementos que contribuyen a dar cumplimiento del marco de referencia de Arquitectura de TI planteado por la estrategia de Gobierno el Línea, y los lineamientos normativos que debe aplicar la SUPERSALUD.

2. Alcance

Esta guía en su primera parte cubre el paso a paso para la estructuración de proyectos de nuevas soluciones tecnológicas, a través del desarrollo de ejercicios de arquitectura empresarial, que contempla la identificación de situación actual de arquitectura de TI para las soluciones a abordar, el análisis de referentes, el análisis de brecha entre línea base y referentes, la definición de arquitectura objetivo, el análisis de brecha entre línea base y arquitectura objetivo, y la estructuración de hoja de ruta. También comprende la fase precontractual en torno a estudios previos y la fase contractual.

En la segunda parte, el documento da guía sobre la gestión de proyectos que se debe adelantar como una práctica transversal desde que son recibidos como requerimientos, cuando pasan a ser iniciativas hasta cuando se consolidan como proyectos, en paralelo a los ejercicios de arquitectura de TI, así como también una guía durante el acompañamiento que brinda el grupo de arquitectura al grupo de aplicaciones para las implementaciones de las soluciones.

3. Ámbito de Aplicación

2



La presente guía aplica para todos los ejercicios de arquitectura de T.I. referente al procedimiento de Provisión de las Soluciones Tecnológicas de nueva TI con que cuenta la entidad.

4. Desarrollo de los ejercicios de arquitectura de TI

4.1 Generalidades de los ejercicios de arquitectura de TI

El enfoque metodológico para los ejercicios de arquitectura de TI que se ha definido desde la Oficina de Tecnologías de la Información a través del Grupo De Gestión de Arquitectura de TI, para la SUPERSALUD, se enmarca en el un ciclo de desarrollo como se ilustra a continuación:

3



Dicho ciclo que se explica en detalle más adelante en esta guía.

Para cada fase del ciclo de vida, se trabajan los siguientes dominios:

4



Bajo este ámbito se recorren los ejercicios de arquitectura, los cuales se establecen de acuerdo a la tipología de proyectos definida a continuación.

4.2 Tipos de proyectos para los ejercicios de arquitectura de TI

De acuerdo con la naturaleza de cada proyecto se han clasificado los siguientes tipos de proyecto:

1. Desarrollo de arquitectura de TI para nuevos sistemas de información de complejidad baja (pequeños): Son aquellos a desarrollar desde cero, en donde la solución a implementar cubre entre 20 y 50 requerimientos funcionales y esta será

5



utilizada por una sola dependencia de la entidad, es decir, no es transversal a varias áreas, demanda hasta tres (3) servicios de interoperabilidad con otras aplicaciones ya existentes, y se puede desarrollar con recursos internos, como desarrolladores de planta o contrataciones de prestación de servicios en la OTI.

2. Desarrollo de arquitectura TI para nuevos sistemas de información de complejidad media (medianos): Son aquellos a desarrollar desde cero, en donde la solución a implementar cubre entre 51 y 99 requerimientos funcionales. Suele ser un sistema de información de uso transversal a varias dependencias de la entidad con más de tres (3) servicios de interoperabilidad con otras aplicaciones ya existentes, y se puede desarrollar con recursos internos, es decir, por desarrolladores de planta o contratados por prestación de servicios en la OTI.

3. Desarrollo de arquitectura TI para nuevos sistemas de información de complejidad alta (grandes): Son aquellos a desarrollar desde cero, en donde la solución a implementar cubre más de cien (100) requerimientos funcionales y que suele ser un sistema de información de uso transversal a varias dependencias de la entidad con más de tres (3) servicios de interoperabilidad con otras aplicaciones ya existentes, y que su desarrollo se hará vía contratación de un desarrollo a la medida con un proveedor especializado o fábrica de software.

4. Desarrollo de arquitectura TI para evolución de sistemas de información ya existente en la entidad: Es una redefinición de la arquitectura de componentes del software, la cual se va a implementar con recursos internos de la OTI, es decir, por desarrolladores de planta o contratados por prestación de servicios en la OTI. Asumiendo que los cambios no superarán el 50% de las funcionalidades y que se reutilizará el 50% restante de funcionalidades ya existentes. Si la redefinición de arquitectura debe cambiar más del 50% de la aplicación deberá considerarse similar a un trabajo de desarrollo de una arquitectura tipo 1 o 2.

5. Desarrollo de la arquitectura TI para sistemas de información que se recibirán vía convenio interinstitucional: Son aquellos desarrollos o personalizaciones de más de diecinueve (19) funcionalidades. Entendiendo que la aplicación ya está madura y probada y que va a ser utilizada por una sola dependencia de la entidad, es decir no es transversal a varias áreas, no demanda más de tres (3) servicios de interoperabilidad con otras aplicaciones ya existentes, y su personalización se hará con recursos internos, es decir, por desarrolladores de planta o contratados por prestación de servicios en la OTI.

6



4.3 Roles para realizar los ejercicios de arquitectura de TI

Para realizar los ejercicios de arquitectura de TI se cuenta con los siguientes roles:

Gestor de Proyecto Asesor AE (Arquitectura Empresarial) Asesor PMO (Gestión de Proyectos) Coordinador Grupo de Arquitectura de TI

El siguiente cuadro establece las responsabilidades generales de cada rol en el ámbito de los ejercicios de arquitectura de TI:

Rol ResponsabilidadCoordinador Grupo de Arquitectura de TI

Aprobación del enfoque de cada ejercicio de Arquitectura de TI.

Apoyar la aprobación institucional de entregables. Definir estrategias para el logro de metas. Relacionamiento con alta dirección y áreas funcionales de

la entidad.

Gestor de Proyecto Establecer con el Asesor AE el enfoque de cada ejercicio de Arquitectura de TI.

Confirmar y obtener del Coordinador Grupo de Arquitectura de TI la aprobación el enfoque de cada ejercicio de Arquitectura de TI

Elaborar todos los entregables del ejercicio de Arquitectura de TI asignado.

Mantener actualizados todos los entregables del ejercicio de Arquitectura de TI en el repositorio establecido para tal fin.

7



Socializar y obtener aprobaciones de los actores patrocinadores e interesados en el ejercicio de Arquitectura de TI.

Asesor AE Apoyar Metodológicamente el enfoque de los ejercicios de Arquitectura de TI.

Orientar el desarrollo del ciclo de definición de los ejercicios de Arquitectura de TI para implementación de solución.

Brindar entrenamiento al Gestor de Proyecto en la práctica de arquitectura empresarial (orientándolo para que desarrolle los ejercicios de Arquitectura de TI, elabore y sustente los entregables del mismo).

Validar y retroalimentar la calidad de los entregables que elabore el Gestor de Proyecto en los ejercicios de Arquitectura de TI.

Asesor PMO Apoyar Metodológicamente al Gestor de proyecto lo concerniente a la práctica de gerencia de proyectos en los ejercicios de Arquitectura de TI

En la siguiente sección se determinan las responsabilidades de cada rol asociado a las actividades que se desarrollan en los ejercicios de arquitectura de TI.

4.4 Actividades en los ejercicios de arquitectura de TI

La siguiente tabla es el detalle operativo de las actividades a realizar en el desarrollo de cada ejercicio de Arquitectura Empresarial.

8



No. Actividad Descripción Responsable Registro1 Clasificación y

asignación de solicitudes para arquitectura de TI

El coordinador del grupo de Gestión de Arquitectura de TI revisa la solicitud hecha en la aplicación CA –Service Desk, verificando si la solicitud es viable, es completa, y cuenta con los soportes adecuados.Cumplido lo anterior se establece el tipo de proyecto para el ejercicio de arquitectura a aplicar, según la tipificación de requerimientos descrita en el numeral 4.2 de esta guía. Hecha la tipificación el coordinador del grupo de Gestión de Arquitectura de TI asigna la solicitud a un profesional del grupo con el rol de Gestor de proyecto que se considere adecuado para atender el requerimiento.

Coordinador Grupo de Arquitectura de TI

Solicitud en la aplicación CA Service Desk

Y

Solicitud de requerimientos de para sistemas de información RSFT02

2 Análisis arquitectónico del requerimiento

El Gestor de Proyecto a cargo de la solicitud asignada, brinda acompañamiento al área solicitante para delimitar y detallar el alcance del ejercicio de arquitectura a emprender, propiciando sesiones de entendimiento, y elabora la presentación de interpretación de la necesidad, que debe ser socializada y aprobada por parte del área solicitante.

Esta actividad en el ejercicio de arquitectura de TI dispara la actividad “Formalización de la Solicitud” de gestión del proyecto, la cual se describe en el capítulo 5 "Gestión de Proyectos de Arquitectura de TI".

Gestor de Proyecto Presentación de interpretación de la necesidad

3 Formalización Esta actividad en el ejercicio de arquitectura de TI dispara la actividad “Inicio” de gestión del proyecto,

Gestor de Proyecto Acta de Constitución.

9



No. Actividad Descripción Responsable Registrodel proyecto la cual se describe en el capítulo 5 "Gestión de

Proyectos de Arquitectura de TI".4 Formular la

estrategia del ejercicio de arquitectura de T.I.

El Gestor de Proyecto, con apoyo del Asesor en Arquitectura Empresarial consolida en un documento y en los artefactos complementarios que se requieran el detalle de la problemática a resolver, los motivadores (beneficios esperados), la identificación de interesados, el alcance detallado, la metodología con la cual se abordará el ejercicio de arquitectura para el tipo de proyecto, los entregables para el ejercicio. Esta actividad incluye las iteraciones necesarias para la socialización, ajustes y aprobación del documento consolidado.

Gestor de Proyecto Documento de Estrategia del ejercicio de arquitectura de T.I. aprobado y cargado en el Repositorio de Arquitectura

5 Definición del Ejercicio de Arquitectura de TI

El Gestor de Proyecto con apoyo del Asesor de Arquitectura Empresarial consolida el documento de definición del ejercicio de arquitectura de T.I. que contiene la recopilación de necesidades de los grupos de interés, la organización impactada, el equipo humano requerido, la línea de tiempo del ejercicio de arquitectura (incluye resumen de hitos), la identificación de fortalecimiento de competencias del equipo de trabajo, las restricciones al trabajo de arquitectura, los principios de arquitectura (tomados del catálogo de principios de arquitectura de TI) y la Visión del trabajo de arquitectura

Gestor de Proyecto Documento de definición del ejercicio de arquitectura de T.I.

6 Obtención y El Gestor de Proyecto con la orientación del Asesor de Arquitectura Empresarial realiza la obtención de

Inventario de información para el Documento de

10



No. Actividad Descripción Responsable Registroconsolidación de la situación actual para el dominio de Estrategia y Normativa

la información de situación actual, para el dominio de Estrategia y Normativa y consolida la información obtenida en el documento de Línea Base de la arquitectura de solución de TI. Dependiendo del tipo y características del proyecto se establecerá el alcance de los elementos a describir en este dominio. Para el dominio de Estrategia y Normativa se deben desarrollar siguientes temas: Descripción del Marco Normativo y regulatorio

relacionado. Relación de Objetivos institucionales y del

sector. Identificación del DOFA.

Esta actividad en el ejercicio de arquitectura de TI dispara la actividad “Análisis y estructuración” de gestión del proyecto, la cual se describe en el capítulo 5 "Gestión de Proyectos de Arquitectura de TI".

Línea basey

Documento de Línea Base de la arquitectura de solución de TI.

7 Obtención y consolidación de la situación actual para el dominio de Negocio

El Gestor de Proyecto con la orientación del Asesor de Arquitectura Empresarial realiza la obtención de la información de situación actual, para el dominio de negocio y consolida la información obtenida en el documento de Línea Base de la arquitectura de solución de TI. Dependiendo del tipo y características del proyecto se establecerá el alcance de los elementos a describir en este

Gestor de Proyecto Documento de Línea Base de la arquitectura de solución de TI.

11



No. Actividad Descripción Responsable Registrodominio. Para el dominio de Negocio se deben desarrollar siguientes temas: Cadena de valor Catálogo de servicios de Negocio Catálogo de procesos Catálogo de la organización y Matriz RACI del

proceso Diagrama organizacional Diagrama de procesos


8 Obtención y consolidación de la situación actual para el dominio de Información

El Gestor de Proyecto con la orientación del Asesor de Arquitectura Empresarial realiza la obtención de la situación actual, para el dominio de Información y consolida lo obtenido en el documento de Línea Base de la arquitectura de solución de TI. Dependiendo del tipo y características del proyecto se establecerá el alcance de los elementos a describir en este dominio. Para el dominio de Información se deben desarrollar los siguientes temas: Diagrama conceptual de datos de entidades

principales (en este componente tener en cuenta artefactos cuya fuente es el proyecto DASI)


12



No. Actividad Descripción Responsable Registro Modelo de entidad relación de información ((en

este componente tener en cuenta artefactos cuya fuente es el proyecto DASI)

Flujo de la información Catálogo de activos de información. (entidades,

datos, archivos, bases de datos, etc.) Vista de organización física de la información

(Esquema) Matriz procesos - datos Catálogo de servicios de información Políticas y estándares de información Indicadores claves


9 Obtención y consolidación de la situación actual para el dominio de Aplicaciones

El Gestor de Proyecto con la orientación del Asesor de Arquitectura Empresarial realiza la obtención de la información de situación actual, para el dominio de Aplicaciones y consolida la información obtenida en el documento de Línea Base de la arquitectura de solución de TI. Dependiendo del tipo y características del proyecto se establecerá el alcance de los elementos a describir en este dominio. Para el dominio de Aplicaciones se deben desarrollar siguientes temas: Vista lógica de aplicaciones (en este


13



No. Actividad Descripción Responsable Registrocomponente tener en cuenta artefactos cuya fuente es el proyecto DASI)

Diagramas de despliegue (en este componente tener en cuenta artefactos cuya fuente es el proyecto DASI)

Matriz aplicaciones - datos (en este componente tener en cuenta artefactos cuya fuente es el proyecto DASI)

Matriz aplicaciones - procesos (en este componente tener en cuenta artefactos cuya fuente es el proyecto DASI)

Matriz roles - aplicaciones (en este componente tener en cuenta artefactos cuya fuente es el proyecto DASI)

Catálogo de interfaces y matriz de interoperabilidad

Catálogo de servicios de aplicación Políticas y estándares Inventario de Requerimientos funcionales


10 Obtención y consolidación de la situación

El Gestor de Proyecto con la orientación del Asesor de Arquitectura Empresarial realiza la obtención de la información de situación actual, para el dominio de Servicios Tecnológicos y consolida la


14



No. Actividad Descripción Responsable Registroactual para el dominio de Servicios Tecnológicos

información obtenida en el documento de Línea Base de la arquitectura de solución de TI. Dependiendo del tipo y características del proyecto se establecerá el alcance de los elementos a describir en este dominio. Para el dominio de Servicios Tecnológicos se deben desarrollar siguientes temas: Diagramas de redes y comunicaciones Middleware (servidores de aplicaciones, bus de

servicios, etc.) Software base de las aplicaciones existentes

(Fuente DASI) Infraestructura de servidores (Fuente DASI) Diagramas de ambientes (Desarrollo, pruebas,

producción) Matriz de tecnología - aplicaciones (Fuente

DASI) Políticas y estándares de servicios tecnológicos Inventario de Requerimientos No funcionales


11 Obtención y consolidación de la situación

El Gestor de Proyecto con la orientación del Asesor de Arquitectura Empresarial realiza la obtención de la información de situación actual, para el dominio de Uso y apropiación, y consolida la información


15



No. Actividad Descripción Responsable Registroactual para el dominio de Uso y Apropiación

obtenida en el documento de Línea Base de la arquitectura de solución de TI. Dependiendo del tipo y características del proyecto se establecerá el alcance de los elementos a describir en este dominio. Para el dominio de Uso y apropiación se deben desarrollar siguientes temas: Línea base de Uso y apropiación de soluciones

TI del ámbito del ejercicio de arquitectura Estrategia actual de gestión de asimilación de

cambio


12 Aprobación de Línea Base de la arquitectura de solución de TI

El Gestor de Proyecto tramita la aprobación del Documento de Línea Base de la arquitectura de solución de TI, por parte del equipo de proyecto mediante la presentación del documento y/o socialización con el área solicitante. Esto se formaliza mediante Acta de aceptación registrada en el sistema integrado de Gestión de la entidad.

Esta actividad en el ejercicio de arquitectura de TI dispara la actividad “Análisis y estructuración” de gestión del proyecto, la cual se describe en el capítulo 5 "Gestión de Proyectos de Arquitectura de

Gestor de Proyecto

16



No. Actividad Descripción Responsable RegistroTI".

13 Análisis de referentes

El Gestor de Proyecto con la orientación del Asesor de Arquitectura Empresarial, hacen la investigación para identificar los referentes más relacionados con la solución. El resultado del análisis de estos referentes se incorpora al Documento de Arquitectura Objetivo para solución de TI, cubriendo estos capítulos: Marcos y estándares, y Otros (productos, servicios, entidades de gobierno).


Gestor de Proyecto Documento Análisis de Referentes

14 Definición y aplicación de los modelos de valoración

El Gestor de Proyecto con la orientación del Asesor de Arquitectura Empresarial, revisan los capacidades o funcionalidades de solución de TI para los cuales se enfocará la valoración. Allí pueden combinarse modelos de madurez y análisis de cubrimiento. Elegidos lo modelos, se establece el método y se construyen los instrumentos de valoración a aplicar. Luego se aplican los modelos y se registra el resultado de esto en el Documento de Arquitectura Objetivo para solución de TI, en los capítulos: Definición del Modelo de valoración Aplicación del modelo de Valoración

Gestor de Proyecto Documento de Arquitectura Objetivo para solución de TI

17



No. Actividad Descripción Responsable Registro


15 Análisis de brecha entre línea base y referentes

El Gestor de Proyecto con la orientación del Asesor de Arquitectura Empresarial, revisan los resultados de la aplicación del modelo de valoración, y basado en ello realizan el análisis de brecha entre línea base y referentes. Esto se registra en el Documento de Arquitectura Objetivo para solución de TI, en el capítulo: Análisis de brecha entre línea base y referentes



16 Definición de Arquitectura Objetivo de Negocio

El Gestor de Proyecto con la orientación del Asesor de Arquitectura Empresarial, definen la línea objetivo para el dominio de negocio. Esto se registra en el Documento de Arquitectura Objetivo para solución de TI. Dependiendo del tipo y características del proyecto se establecerá el alcance de los elementos a definir en este dominio. Para el dominio de Negocio se deben desarrollar los siguientes temas:


18



No. Actividad Descripción Responsable Registro Cadena de valor Catálogo de servicios de Negocio Catálogo de la organización (RACI) Diagrama organizacional Diagrama de procesos (aplica si hay cambios vs

la línea base)


17 Definición de Arquitectura Objetivo de Información

El Gestor de Proyecto con la orientación del Asesor de Arquitectura Empresarial, definen la línea objetivo para el dominio de Información. Esto se registra en el Documento de Arquitectura Objetivo para solución de TI. Dependiendo del tipo y características del proyecto se establecerá el alcance de los elementos a definir en este dominio. Para el dominio de Negocio se deben desarrollar los siguientes temas: Diagrama conceptual de datos de entidades Diagrama entidad relación de información Flujo de la información Catálogo de activos de información. (Aplica si

hay cambios vs la línea base) Vista de organización física de la información Matriz procesos - datos Catálogo de servicios de información


19



No. Actividad Descripción Responsable Registro Políticas y estándares de información Indicadores


18 Definición de Arquitectura Objetivo de Aplicaciones

El Gestor de Proyecto con la orientación del Asesor de Arquitectura Empresarial, definen la línea objetivo para el dominio de Aplicaciones. Esto se registra en el Documento de Arquitectura Objetivo para solución de TI. Dependiendo del tipo y características del proyecto se establecerá el alcance de los elementos a definir en este dominio. Para el dominio de Aplicaciones se deben desarrollar los siguientes temas: Vista lógica de aplicaciones Diagramas de despliegue Matriz aplicaciones - datos Matriz aplicaciones - procesos Matriz roles - aplicaciones Catálogo de interfaces Catálogo de servicios Políticas y estándares Requerimientos funcionales

Esta actividad en el ejercicio de arquitectura de TI


20



No. Actividad Descripción Responsable Registrodispara la actividad “Análisis y estructuración” de gestión del proyecto, la cual se describe en el capítulo 5 "Gestión de Proyectos de Arquitectura de TI".

19 Definición de Arquitectura Objetivo de Servicios Tecnológicos

El Gestor de Proyecto con la orientación del Asesor de Arquitectura Empresarial, definen la línea objetivo para el dominio de Servicios Tecnológicos. Esto se registra en el Documento de Arquitectura Objetivo para solución de TI. Dependiendo del tipo y características del proyecto se establecerá el alcance de los elementos a definir en este dominio. Para el dominio de Servicios Tecnológicos se deben desarrollar los siguientes temas: Diagramas de redes y comunicaciones. Middleware Software base Infraestructura de servidores. Diagramas de ambientes. Matriz de tecnología - aplicaciones Políticas y estándares de servicios tecnológicos Requerimientos No funcionales



21



No. Actividad Descripción Responsable Registro20 Definición de

Estrategias para el Uso y Apropiación

El Gestor de Proyecto con la orientación del Asesor de Arquitectura Empresarial, definen la línea objetivo para el dominio de Uso y Apropiación. Esto se registra en el Documento de Arquitectura Objetivo para solución de TI. Dependiendo del tipo y características del proyecto se establecerá el alcance de los elementos a definir en este dominio. Para el dominio de Uso y Apropiación se deben desarrollar los siguientes temas: Estrategia de gestión de cambio Estrategia de uso y apropiación



21 Análisis de brecha entre Línea Base y Arquitectura Objetivo

El Gestor de Proyecto con la orientación del Asesor de Arquitectura Empresarial, realizan el análisis de brecha entre línea base y arquitectura objetivo. Esto se registra en el Documento de Arquitectura Objetivo para solución de TI, en el capítulo: Análisis de brecha entre línea base y

arquitectura compuesta por el artefacto Matriz de análisis por dominio (Arq. Actual vs Arq. Objetivo)

Esta actividad en el ejercicio de arquitectura de TI dispara la actividad “Análisis y estructuración” de


22



No. Actividad Descripción Responsable Registrogestión del proyecto, la cual se describe en el capítulo 5 "Gestión de Proyectos de Arquitectura de TI".

22 Elaboración del mapa de ruta

El Gestor de Proyecto con la orientación del Asesor de Arquitectura Empresarial, definen la mapa de ruta para la implementación de la arquitectura objetivo de la solución. Esto se registra en el Documento de Arquitectura Objetivo. Para este fin se desarrollan los siguientes temas: Estrategia mapa de ruta Identificación de iniciativas o Proyectos Priorización de proyectos



23 Aprobación de Arquitectura Objetivo para solución de TI

El Gestor de Proyecto tramita la aprobación del Documento de Arquitectura Objetivo para solución de TI, por parte del equipo de proyecto mediante la presentación del documento y/o socialización con el área solicitante. Esto se formaliza mediante Acta de aceptación registrada en el sistema integrado de Gestión de la entidad.



23



No. Actividad Descripción Responsable Registrodispara la actividad “Análisis y estructuración” de gestión del proyecto, la cual se describe en el capítulo 5 "Gestión de Proyectos de Arquitectura de TI".

24 Elaboración de Anexo Técnico

Cuando la arquitectura objetivo definida se dimensiona como una solución para implementar mediante la contratación de un tercero, el Gestor de Proyecto realiza la definición arquitectónica de los requerimientos funcionales de la solución, y tomando como insumo los documentos de la arquitectura objetivo definida elabora el documento de Anexo técnico.

Esta actividad en el ejercicio de arquitectura de TI dispara la actividad “Precontractual” de gestión del proyecto, la cual se describe en el capítulo 5 "Gestión de Proyectos de Arquitectura de TI".

Gestor de Proyecto Anexo técnico

25 Elaboración de Estudio de Mercado

Cuando la arquitectura objetivo definida se dimensiona como una solución para implementar mediante la contratación de un tercero, y ya se ha elaborado y revisado con los actores intersados los requerimientos funcionales y los demás elementos del Anexo técnico, el Gestor del Proyecto realiza el Estudio de mercado y hace el consolidado del mismo acorde a las respuestas enviadas por los oferentes.

Gestor de Proyecto Estudio de mercado

24



No. Actividad Descripción Responsable RegistroEsta actividad en el ejercicio de arquitectura de TI dispara la actividad “Precontractual” de gestión del proyecto, la cual se describe en el capítulo 5 "Gestión de Proyectos de Arquitectura de TI".

26 Elaboración de Estudios Previos

Cuando la arquitectura objetivo definida se dimensiona como una solución para implementar mediante la contratación de un tercero, y el estudio de mercado ha sido consolidado el Gestor de Proyecto elabora el documento de Estudio previo y tramita la Solicitud de CDP, y la solicitud de vigencias futuras (en caso de requerirlo).

Esta actividad en el ejercicio de arquitectura de TI dispara la actividad “Precontractual” de gestión del proyecto, la cual se describe en el capítulo 5 "Gestión de Proyectos de Arquitectura de TI".

Gestor de Proyecto Estudio previo

27 Radicación documentos Precontractuales

Cuando la arquitectura objetivo definida se dimensiona como una solución para implementar mediante la contratación de un tercero, y el documento de Estudio previo está finalizado el Gestor de Proyecto solicita revisión y aprobación de la coordinación del grupo de Arquitectura y área solicitante, para radicar mediante memorando en el grupo de contratación dichos documentos.


Gestor de Proyecto Memorando Radicación

25



No. Actividad Descripción Responsable Registrodispara la actividad “Precontractual” de gestión del proyecto, la cual se describe en el capítulo 5 "Gestión de Proyectos de Arquitectura de TI".

28 Apoyo etapa pre-contractual

Cuando la arquitectura objetivo definida se dimensiona como una solución para implementar mediante la contratación de un tercero, y los documentos resultantes del estudio previo fueron radicados, el Gestor de Proyecto realiza el acompañamiento al grupo de contratación para la publicación y adjudicación del proceso. Este acompañamiento involucra: Revisión y ajustes a documentos elaborados. Revisión de cronograma del proceso. Respuestas a observaciones de carácter técnico

de posibles proponentes. Evaluación técnica de propuestas Respuestas a observaciones de la evaluación

realizada.

Esta actividad en el ejercicio de arquitectura de TI dispara la actividad “Contractual” de gestión del proyecto, la cual se describe en el capítulo 5 "Gestión de Proyectos de Arquitectura de TI".

Gestor de Proyecto Pliego definitivo

29 Apoyo adjudicación de

Una vez ha sido adjudicado el contrato, el Gestor de Proyecto y la coordinación del grupo de Arquitectura, realizan mediante acta, la entrega de

Gestor de Proyecto

26



No. Actividad Descripción Responsable Registrocontrato la documentación del proyecto, a la coordinación de

Gestión de Aplicaciones quien que asumirá la implementación del sistema y por ende la ejecución del contrato, acordando la reunión de inicio en los términos contractuales establecidos.

Esta actividad en el ejercicio de arquitectura de TI dispara la actividad “contractual” de gestión del proyecto, la cual se describe en el capítulo 5 "Gestión de Proyectos de Arquitectura de TI".

30 Apoyar la definición del modelo de gestión del proyecto de implementación de solución de TI

Esta actividad en el ejercicio de arquitectura de TI dispara la actividad “Implementación” de gestión del proyecto, la cual se describe en el capítulo 5 "Gestión de Proyectos de Arquitectura de TI".

Gestor de Proyecto Propuesta de Plantilla para Acta de constitución.

Propuesta de Plantilla para Kickoff.

Propuesta de Plantilla para Informe mensual de avance.

Propuesta de Plantilla para reporte semanal gerencial

31 Entrega de Definiciones de Arquitectura a Aplicaciones OTI

Cuando la arquitectura objetivo definida se dimensiona como una solución para implementar con el equipo de Aplicaciones de la OTI, (desarrollo interno) el Gestor de Proyecto entrega y socializa con el grupo de Aplicaciones la documentación del ejercicio de arquitectura, y establecen en conjunto

Gestor de Proyecto Acta de entregaOInforme de cierre de proyecto

27



No. Actividad Descripción Responsable Registroel cronograma de implementación como proyecto interno.

Esta actividad en el ejercicio de arquitectura de TI dispara la actividad “Implementación” de gestión del proyecto, la cual se describe en el capítulo 5 "Gestión de Proyectos de Arquitectura de TI".

32 Apoyar en el gobierno arquitectónico de la implementación

Durante la ejecución y monitoreo de la implementación de la solución, ya sea con desarrollos internos o servicios tercerizados, el Gestor de proyecto con la orientación del Asesor de Arquitectura Empresarial, de acuerdo con los requerimientos de la solución y los acuerdos establecidos con el área funcional, acompaña en las siguientes actividades: Seguimiento y verificación al cumplimiento de lo

contratado y/o acordado, en relación con los productos, servicios y avance del proyecto hasta el cierre del mismo.

Formula recomendaciones para el proyecto de implementación.

Asegurar que haya conformidad con la arquitectura definida.

Emitir conceptos técnicos y lecciones aprendidas.

Documentar el cierre de proyecto una vez finalizado el contrato.

Gestor de Proyecto Concepto de cumplimiento de la arquitectura Objetivo

Documento de evaluación de Uso y apropiación

28



No. Actividad Descripción Responsable RegistroEsta actividad en el ejercicio de arquitectura de TI dispara la actividad “Implementación” de gestión del proyecto, la cual se describe en el capítulo 5 "Gestión de Proyectos de Arquitectura de TI".

33 Actualización del repositorio de Arquitectura

Los documentos que se generen por el ejercicio de arquitectura deberán ser creados, almacenados y actualizados en el Repositorio de “Ejercicios de Arquitectura de Solución de T.I.” definido para tal fin, esto será responsabilidad del Gestor de proyecto.

Gestor de Proyecto Actualización de entregables de arquitectura en Repositorio

5. Gestión de Proyectos de Arquitectura de TI

5.1 Generalidades Gestión de Proyectos de Arquitectura Empresarial de TI

Este documento tiene como objetivo brindar algunos lineamientos generales para gestionar proyectos en el grupo de Arquitectura de TI de la OTI, mediante la descripción de las diferentes etapas de un proyecto y los entregables asociados cada una de ellas, de manera que se configure como un instrumento de apoyo para que los profesionales especializados, administren los proyectos de manera que se guíe hacia su culminación exitosa.

Se considera un proyecto un emprendimiento de carácter temporal, realizado para crear un producto o servicio único. Es un plan de trabajo, con acciones sistemáticas, es decir, coordinadas entre sí, valiéndose de los medios necesarios y posibles, en busca de objetivos específicos a alcanzar en un tiempo previsto. Es importante diferenciar un proyecto de una operación, ya que este último corresponde a un trabajo continuo, repetitivo, cuyo propósito es mantener el negocio.

29



El Grupo de Arquitectura de T.I., es el encargado de formular la arquitectura de las soluciones de TI, con el propósito de proveer soluciones tecnológicas adecuadas que atiendan las necesidades y/o problemáticas de la entidad, y por este motivo la formulación y ejecución de proyectos se convierte en uno de los principales habilitadores de nuevos escenarios organizacionales.

5.2 Ciclo de Vida de Proyectos de Arquitectura Empresarial de TI

Los proyectos son entes vivos que deben ser manejados de manera secuencial y organizada, es decir, contempla un ciclo de vida con fases, según se describe en la siguiente gráfica:

Reconocer las fases, ayuda al gestor a establecer metas y objetivos concretos, también permite controlar la duración y costos del proyecto.

FASE DE INICIO: Implica las tareas de definición del proyecto, que consisten en acotar su alcance y realizar los procedimientos necesarios a nivel administrativo para abrir el proyecto de forma oficial dentro de la compañía.

30



FASE DE PLANIFICACIÓN: Consiste en establecer las acciones que se llevarán a cabo durante el proyecto y su calendarización en el tiempo, así como los objetivos que se pretenden conseguir y los recursos de los que se dispone, tanto humanos como materiales. Lo más común es realizar una matriz en la que para cada acción que hay que realizar se establece un responsable y una fecha en la que dicha acción debe estar finalizada. De esta manera, durante la siguiente etapa de ejecución se puede realizar el seguimiento del proyecto de forma sencilla.

FASE DE EJECUCIÓN: una vez el proyecto está planificado, la ejecución consiste en que cada miembro del equipo tomará la matriz definida y realizará las tareas que le han sido asignadas. La misión del gestor aquí es doble; por un lado, vigilar que la planificación se cumple con la mayor precisión posible, tanto en tiempo como en esfuerzo (para que no aumenten los costes), por otro, coordinar al equipo y facilitar la solución a los problemas que vayan surgiendo al equipo para desatascar posibles cuellos de botella. Como gestor, irás realizando modificaciones en tu planificación para reajustarla, adelantándote a los riesgos y comunicando el estado del proyecto a tus interlocutores (jefes y clientes).

FASE DE SEGUIMIENTO Y CONTROL: Monitorización del trabajo realizado analizando cómo el progreso difiere de lo planificado e iniciando las acciones correctivas que sean necesarias. Incluye también el liderazgo, proporcionando directrices a los recursos humanos, subordinados (incluso subcontratados) para que hagan su trabajo de forma efectiva y a tiempo.

CIERRE: esta fase es meramente administrativa pero muy importante. Implica concluir oficialmente el proyecto, de manera que todos los implicados entienden que las tareas planificadas se han ejecutado y se puede realizar una valoración final del éxito del proyecto.

Para cada una de las fases de proyecto, se establecen entregables o documentos que permite llevar un registro de los avances en cada una de las etapas del mismo, hasta la finalización o cierre.

5.3 Fases de Proyectos de Arquitectura de TI en la SuperSalud

En el ciclo de vida de proyectos de tecnología en la OTI, se identifican las siguientes etapas:

31



FORMALIZACIÓN DE LA SOLICITUD: El área funcional realiza una solicitud del requerimiento para un sistema de información, a través de la Mesa de servicios. El gestor asignado por la coordinación del grupo de arquitectura, debe hacer el acompañamiento al área solicitante en la definición del alcance y aclarar los roles clave del proyecto, como el sponsor y líderes funcionales, para garantizar una adecuada interpretación de la solicitud hecha por el área funcional.

INICIO: Esta etapa comienza con la firma del acta de constitución de acuerdo con la plantilla, por parte del sponsor, formalizando de esta manera el inicio del proyecto, que debe contar con el patrocinio ejecutivo y un presupuesto asignado.

ANÁLISIS Y ESTRUCTURACIÓN: El gestor debe generar los entregables correspondientes a la planeación detallada del proyecto, se realiza la categorización del proyecto y se define la estrategia del ejercicio de arquitectura, que permitirá generar los documentos de línea base de arquitectura, arquitectura objetivo, que suministra el anexo técnico para hacer el estudio de mercado, necesario para dar inicio a la etapa precontractual.

PRECONTRACTUAL: Esta fase se contempla para los casos en los que se decide contratar con un tercero la solución que requiere el área funcional, e implica la definición de la modalidad de contratación por parte del grupo de contratación para elaborar y radicar los estudios previos en el grupo de contratación, dando así inicio al proceso hasta la selección del contratista.

32



CONTRACTUAL: Una vez se adjudica el contrato a un proveedor, el grupo de contratación se encarga de hacer el perfeccionamiento del contrato y firma del acta de inicio.

IMPLEMENTACIÓN: La implementación se puede llevar a cabo bien sea por el grupo de aplicaciones de la OTI, es decir como un desarrollo interno o por parte de un contratista, en todo caso se requiere una nueva planeación detallada de esta etapa, para poder hacer un seguimiento detallado de las actividades del ciclo de vida de Software, que permita dar cumplimiento al alcance definido, en el tiempo establecido y con el presupuesto aprobado.

CIERRE: El cierre del proyecto se formaliza con el informe final, y el acta de cierre.

5.4 Roles para realizar los ejercicios de arquitectura de TI

Para realizar la gestión de proyectos de arquitectura de TI se cuenta con los siguientes roles:

Gestor de Proyecto Asesor AE (Arquitectura Empresarial) Asesor PM (Gestión de Proyectos) Coordinador Grupo de Arquitectura de TI Asesor de Gestión de Asimilación del Cambio

El siguiente cuadro establece las responsabilidades generales de cada rol en el ámbito de la gestión de proyectos de arquitectura de TI:

Rol ResponsabilidadCoordinador Grupo de Arquitectura de TI

Dirección general de proyectos de Arquitectura de TI. Conseguir recursos para la ejecución de proyectos de Arquitectura de TI. Autorizar y aprobar controles de cambios sobre los de proyectos de Arquitectura de TI. Definir estrategias para el logro de metas para los proyectos de Arquitectura de TI. Aprobación Institucional de entregables de la gestión de proyectos de Arquitectura de TI. Relacionamiento con alta dirección para informar avances de proyectos de Arquitectura de TI

33



Coordinar las actividades administrativas con los gestores de proyecto en la gestión de proyectos de Arquitectura de TI.

Gestor de Proyecto Planificar el trabajo (Alcance, Cronograma, riesgos, etc.) de proyectos de Arquitectura de TI. Coordinar el equipo de trabajo (Reservar recursos, agendar sesiones de trabajo, asegurar la

ejecución de las actividades planeadas, participar activamente en el seguimiento de los planes) de proyectos de Arquitectura de TI.

Preparar y entregar reportes de avance de proyectos de Arquitectura de TI. Elaborar todos los entregables de gestión de proyectos de Arquitectura de TI.

Asesor AE Apoyar la estructuración del proyecto junto con el Gestor de Proyecto. Validar y retroalimentar la calidad de los entregables de gestión de proyectos que elabore el Gestor

de Proyecto.

Asesora PMO Apoyar Metodológicamente al Gestor de proyecto lo concerniente a la gerencia de proyectos. Validar y aceptar la calidad de los entregables de la gestión de proyectos. Hacer Seguimiento y Monitoreo de los cronogramas y los riesgos.

Asesor de Gestión de Asimilación del Cambio

Garantizar la aplicación del modelo de Gestión de Asimilación del Cambio definido en la OTI, para los proyectos de Tecnología, apoyando al gestor de proyecto de la Supersalud, en la validación de entregables asociados a la actividad, además de hacer seguimiento al plan de trabajo y retroalimentar las actividades ejecutadas por el contratista en la etapa de implementación.

En la siguiente sección se determinan las responsabilidades de cada rol asociado a las actividades que se desarrollan en los ejercicios de arquitectura de TI.

34



5.5 Actividades

La siguiente tabla es el detalle operativo de las actividades a realizar para la gestión de proyectos de cada ejercicio de Arquitectura. En el capítulo anterior en las actividades de cada ejercicio se referencia las actividades propias de gestión de proyectos de esta tabla.

No. Actividad Descripción Responsable Registro1 Formalización

de la solicitudCuando el análisis del requerimiento en el ejercicio de arquitectura determina la viabilidad el mismo, el Asesor PMO inicializa el proyecto en Portafolio de Proyectos de Arquitectura de TI, actualiza el estatus de la solicitud en la herramienta CA y en acuerdo el Coordinador del Grupo asigna el Gestor de Proyecto oficial a cargo del mismo.

Coordinador Grupo de Gestión de Arquitectura TI

Solicitud en la aplicación CA Service Desk

Inicio Se elabora el acta de constitución del proyecto.

Gestor de Proyecto

Acta de Constitución.

Definición EDT

Análisis de interesados de Proyecto

Plan de Proyecto

Cronograma de trabajo

Plan de comunicaciones

35



No. Actividad Descripción Responsable RegistroAnálisis de riesgos

Actualización de la Solicitud en la aplicación CA Service Desk

Análisis y Estructuración

De acuerdo con el plan de proyecto, el profesional designado en paralelo a las actividades siguientes presentará informes de avance y gestionará el cumplimiento del mencionado plan.

Gestor de Proyecto

Presentación de avance semanal

Cronograma con avance


Precontractual De acuerdo con el plan de proyecto, el profesional designado en paralelo a las actividades siguientes presentará informes de avance y gestionará el cumplimiento del mencionado plan.

Gestor de Proyecto




Contractual De acuerdo con el plan de proyecto, el profesional designado en paralelo a las actividades siguientes presentará informes de avance y gestionará el cumplimiento del mencionado plan.

Gestor de Proyecto




Implementación El Gestor de proyecto, el Asesor PMO, y al Asesor en Arquitectura Empresarial establecen el esquema de gestión de proyecto y gestión de asimilación del cambio para la

Gestor de Proyecto

Propuesta de Plantilla para Acta de constitución.

Propuesta de Plantilla para Kickoff.

Propuesta de Plantilla para Informe mensual de

36



No. Actividad Descripción Responsable Registroimplementación, y propone las plantillas a ser usadas.

avance.

Propuesta de Plantilla para reporte semanal gerencial


Cierre El Asesor PMO establece el cierre de proyecto

Asesor PMO Acta de Cierre

Lecciones Aprendidas

Cierre de la Solicitud en la aplicación CA Service Desk

6. Documentos a elaborar según tipo de proyecto

Alineado a lo anterior a continuación se describen los documentos referentes a elaborar en el desarrollo de los proyectos, no es de carácter obligatorio elaborar todos los entregables, pues de acuerdo con la tipología de proyecto y las características de cada uno se analizará en conjunto con el arquitecto líder y la coordinación de Gestión de Arquitectura los documentos a elaborar en cada proyecto, a saber:

6.1 Para Ejercicios de Arquitectura

37



Entregable Contenido / Artefactos

Complejidad alta

(Aprox. cubre más de cien

requerimientos)

Complejidad media

(Aprox. entre 51 y 99

requerimientos)

Complejidad baja:

(Aprox. 20 y 50

requerimientos funcionales)

S.I. ya existente en la entidad (cambios no superarán el

50% del producto )

Caso de asignación - CA

formato diligenciado y firmado en C:A x x x x

Presentación de interpretación de la

necesidadPresentación de interpretación de la necesidad x x x x

Documento de Estrategia del ejercicio de arquitectura de T.I.

Problemática a resolver x x x xMotivadores (beneficios esperados) x x x xIdentificación de Interesados x x x xAlcance x x x xMetodología x x x x

Entregables x x x x

Documento de definición del ejercicio de arquitectura de T.I.

Necesidades de los grupos de interés y organización impactada x x x xRecursos (Elementos de infraestructura) x x x x

Equipo humano requerido x x x x

Financiero (presupuesto) x x x x

38




Complejidad alta


requerimientos)

Complejidad media


requerimientos)

Complejidad baja:

(Aprox. 20 y 50



50% del producto )

Línea de tiempo del ejercicio de arquitectura (incluye resumen de hitos) x x x x

Identificación de fortalecimiento de competencias del equipo de trabajo x Restricciones al trabajo de arquitectura x x x x

Principios de arquitectura x x x x

Visión del trabajo de arquitectura x x x x

Documento de linea base de arquitectura

Línea base de arquitectura estratégica y normativa x x

Marco Normativo y regulatorio relacionados. x x

Objetivos institucionales y del sector x Institucionales Institucionales Institucionales

DOFA x x x Línea base de Arquitectura de negocio

Cadena de valor x x x

39




Complejidad alta


requerimientos)

Complejidad media


requerimientos)

Complejidad baja:

(Aprox. 20 y 50



50% del producto )

Catálogo de servicios de Negocio x x x

Catálogo de procesos x x Catálogo de la organización

(RACI del proceso) x x

Diagrama organizacional x x x x

Diagrama y flujo de procesos x x x xLínea base de Arquitectura de información

Políticas y estándares de información x x

Matriz procesos - información x x x xCatálogo de servicios de

información (incluye fuente y flujo) x x x xModelo de entidades de

información (incluye fuentes y flujos de información)

Indicadores de proceso x x x x

Línea base de Arquitectura de

40




Complejidad alta


requerimientos)

Complejidad media


requerimientos)

Complejidad baja:

(Aprox. 20 y 50



50% del producto )

aplicación

Vista lógica de aplicaciones x x xActualizar la

existente

Políticas y estándares x x Actualizar la

existente

Diagramas de despliegue x x xActualizar la

existenteMatriz aplicaciones - entidades

de información x x xActualizar la

existente

Matriz aplicaciones - procesos x x xActualizar la

existente

Caracterización de usuarios x x xActualizar la

existenteModelo y matriz de

interoperabilidad x x xActualizar la

existenteCatálogo de servicios de

aplicación x x xActualizar la

existenteLínea base de Arquitectura de los servicios tecnológicos x x

Actualizar la existente

Políticas y estándares de servicios tecnológicos x

Middelware (servidores de x x x

41




Complejidad alta


requerimientos)

Complejidad media


requerimientos)

Complejidad baja:

(Aprox. 20 y 50



50% del producto )

aplicaciones, bus de servicios, apis, balanceadores)

Software base (licenciamiento) Fuente DASI x x x

Infraestructura de servidores (Fuente DASI) x x x

Diagramas de ambientes (Desarrollo, pruebas, producción, ect..) x

Matriz de tecnología - aplicaciones x

ANALISIS DE REFERENTES

Marcos y estándares x x x Otros (productos, servicios, entidades de gobierno) x x x

Definición del Modelo de valoración x x Aplicación del modelo de Valoración de brechas (Arq. Actual vs Referente) x x

Identificación de brechas a cerrar x x Documento de

Arquitectura Objetivo Arquitectura Objetivo de información

42




Complejidad alta


requerimientos)

Complejidad media


requerimientos)

Complejidad baja:

(Aprox. 20 y 50



50% del producto )

para solución de TI

Modelo de entidades de información

Aplica si hay cambios vs la

línea base


línea base


línea base


línea base

Flujo de la información x

Matriz procesos - datos x x

Catálogo de servicios de información


línea base


línea base


línea base


línea base

Políticas y estándares de información


línea base


línea base


línea base


línea base

Indicadores


línea base


línea base


línea base


línea baseArquitectura Objetivo de aplicación

Vista lógica de aplicaciones x x xActualizar la

existente

Diagramas de despliegue x x xActualizar la

existente

Matriz aplicaciones - entidades x x x Actualizar la

43




Complejidad alta


requerimientos)

Complejidad media


requerimientos)

Complejidad baja:

(Aprox. 20 y 50



50% del producto )

de información existente

Matriz aplicaciones - procesos x x xActualizar la

existente

Caracterización de usuarios x x xActualizar la

existenteModelo y matriz de

interoperabilidad x x xActualizar la

existenteCatálogo de servicios de

aplicación x x xActualizar la

existente

Políticas y estándares x x Actualizar la

existente

Requerimientos funcionales x x xActualizar la

existenteArquitectura Objetivo de los servicios tecnológicos

Middelware x x x x

Software base x x x

Diagramas de ambientes. x x Matriz de tecnología -

aplicacionesx x

44




Complejidad alta


requerimientos)

Complejidad media


requerimientos)

Complejidad baja:

(Aprox. 20 y 50



50% del producto )

Políticas y estándares de servicios tecnológicos x

Requerimientos No funcionales x x x x

Análisis de brecha Matriz de análisis por dominio

(Arq. Actual vs Arq. Objetivo) x x

Mapa de ruta

Estrategia mapa de ruta x x x Identificación de iniciativas o

Proyectos x x x

Priorización de proyectos x Anexo técnico y/o

especificación de requerimientos Anexo técnico Anexo técnico

Especificación de

requerimientos

Especificación de

requerimientos

Documentos pre-contractuales Estudio de mercado

x x x

45




Complejidad alta


requerimientos)

Complejidad media


requerimientos)

Complejidad baja:

(Aprox. 20 y 50



50% del producto )

Estudio previox x x

Para el periodo de acompañamiento al gobierno arquitectónico de la implementación.

Uso y apropiación

Estrategia actual de gestión de asimilación de cambio x x

Matriz de gestión de interesados x x

Actualizar la existente

Estrategia de involucramiento x x xActualizar la

existentePlan de formación y

transferencia de conocimiento x x x x

Matriz de Gestión de impactos x x Actualizar la

existenteEvaluación del nivel de Uso y

apropiación x x x x

46




Complejidad alta


requerimientos)

Complejidad media


requerimientos)

Complejidad baja:

(Aprox. 20 y 50



50% del producto )

Bitácora de proyecto

Información General del Proyecto x x x x

Estado general del proyecto x x x x

Avance de cronograma x x x xEntregables de este periodo y criterios de aceptación x x x x

Ejecución de Presupuesto x x x xRiesgos visibilizados o materializados x x x x

Lecciones Aprendidas x x x x

Documentos anexos x x x x

6.2 Para Gestión de proyectos:

47



FASE DE PROYECTO EntregableComplejidad alta

(cubre más de cien requerimientos)

Complejidad media(entre 51 y 99

requerimientos)

Complejidad baja: (20 y 50


S.I. ya existente en la entidad (cambios no superarán el 50%

del producto )

convenio interinstitucional

Solicitud en la aplicación CA Service Desk x x x x x

x x x x x

P03_Analisis_Interesados_Plantilla_v03_20160513_CG x x x x xEDT x x x x xCronograma de trabajo x x x x xP04_Plan de Comunicaciones_Plantilla_v02_20160513_CG x xP05_Analisis_Riesgos_Plantilla_v02_20160513_CG x x x x xPlan de Proyecto x xPresentación de avance semanal x x x x xCronograma con avance x x x x xActualización de la Solicitud en la aplicación CA Service Desk mensual x x x x xInforme mensual de avance(DOC), reporte semanal gerencial(PPT) x x x x xSolicitud de cambios por demanda por demanda por demanda por demanda por demandaLecciones aprendidas x x x x xRecomendaciones x x x x x

Cierre

Inicio y planeación

Ejecución y Cierre

Acta de constitución firmada ( para proyectos internos será un documento que se elabora en estapa de estructuración) y para proyectos con terceros se debe contar con dos actas 1, etapa de estrcturación y 2. una acta al incio de la implementación proveida por el implementador)

48



7. Estructura de Repositorios documentales

7.1 Repositorio documental para ejercicios de arquitectura de TI

El repositorio de gestión de arquitectura de TI, para los ejercicios de arquitectura de TI, tiene una estructura como se ilustra y explica a continuación:

Gestión de Arquitectura de TI: Carpeta principal o de primer nivel en la estructura jerárquica para este repositorio. Documentos Marco y Políticas AE: Carpeta de segundo nivel donde reposan los documentos de referencia como marcos y

políticas alrededor de la práctica de Arquitectura Empresarial que se está adoptando en la OTI de la SUPERSALUD. Plantillas de AE: Carpeta de segundo nivel donde se ubican las plantillas para los entregables del ejercicio de Arquitectura

Empresarial.

49



Procesos y Procedimientos: Carpeta de segundo nivel donde se registran los documentos fuente de procedimientos y guías desde el enfoque del sistema de gestión de calidad de la SUPERSALUD.

Ejercicios de Arquitectura: Carpeta de segundo nivel donde se ubica la información de cada uno de los ejercicios de arquitectura.

o Nombre del proyecto: Carpeta de tercer nivel en donde se establece el nombre clave o silga del ejercicio de arquitectura que está en curso.

Inicio y Planeación: Carpeta de cuarto nivel que resguarda para cada ejercicio de arquitectura los entregables de gestión de proyectos de las fases de inicio y planeación.

Ejecución: Carpeta de cuarto nivel que almacena los entregables resultantes en el desarrollo del ciclo para cada ejercicio de arquitectura de TI.

Monitoreo y Control: Carpeta de cuarto nivel que resguarda para cada ejercicio de arquitectura las presentaciones e informes de avance en la gestión de proyectos de las fases de inicio y planeación.

7.2 Repositorio documental para gestión de proyectos de arquitectura TI

Bajo la misma capeta de primer nivel explicada en el aparte anterior se detalla a continuación la estructura relacionada con la gestión de proyectos, como se ilustra y explica a continuación:

Continúa en la siguiente página…

50



Gestión de Arquitectura de TI: Carpeta principal o de primer nivel en la estructura jerárquica para este repositorio. Documentos Marco y Políticas GP: Carpeta de segundo nivel donde reposan los documentos de referencia como marcos y

políticas alrededor de la práctica de Gestión de Proyectos que se ha adoptado en la OTI de la SUPERSALUD. Plantillas de GP: Carpeta de segundo nivel donde se ubican las plantillas para los entregables de la gestión de proyectos de

Arquitectura de TI. Reporte de Información: Carpeta de segundo nivel donde se registran los presentaciones y cronograma consolidados de la

gestión del portafolio de proyectos de Arquitectura de TI. Ejercicios de Arquitectura: Carpeta de segundo nivel donde se ubica la información de cada uno de los ejercicios de

arquitectura.o Nombre del proyecto: Carpeta de tercer nivel en donde se establece el nombre clave o silga del ejercicio de

arquitectura que está en curso. Inicio y Planeación: Carpeta de cuarto nivel que resguarda para cada ejercicio de arquitectura los

entregables de gestión de proyectos de las fases de inicio y planeación.

51



Ejecución: Carpeta de cuarto nivel que almacena los entregables resultantes en el desarrollo del ciclo para cada ejercicio de arquitectura de TI.

Monitoreo y Control: Carpeta de cuarto nivel que resguarda para cada ejercicio de arquitectura las presentaciones e informes de avance en la gestión de proyectos de las fases de inicio y planeación.

7.3 Nomenclatura de documentos

Con el fin de garantizar homogeneidad en la nomenclatura de documentos, éstos se regirán de acuerdo con las siguientes consideraciones:

Continúa en la siguiente página…

52



53



CONTROL DE CAMBIOSASPECTOS QUE CAMBIARON EL

DOCUMENTO

DETALLES DE LOS CAMBIOS EFECTUADOS

RESPONSABLE DE LA SOLICITUD DEL

CAMBIO

FECHA DEL CAMBIO

VERSIÓN

Adopción del documento

Mediante Memorando NURC: 3-2017-013780 se solicita la creación de la

guía

Mediante NURC se aprobó el presente documentos con número 3-

2015-015540.

Jefe Oficina de Tecnologías de la

Información02/10/2017 1

54

Guía Para El Procedimiento De Gestión De … · Web viewCadena de valor Catálogo de servicios de...

Documents

Transcript of Guía Para El Procedimiento De Gestión De … · Web viewCadena de valor Catálogo de servicios de...