MANUAL DE REGLAS DE NEGOCIO ASOCIADAS AL PROCESO DE ESTRATEGIA DEL SERVICIO DE TI PERTENECIENTES AL MACRO PROCESO GESTIÓN DE TECNOLOGÍA DE INFORMACIÓN

Transcripción

1 Página 1 de 20 MANUAL DE REGLAS DE NEGOCIO ASOCIADAS AL PROCESO DE ESTRATEGIA DEL SERVICIO DE TI PERTENECIENTES AL MACRO PROCESO GESTIÓN DE TECNOLOGÍA DE INFORMACIÓN VERSIÓN 001 Junio 2012 Página 1

2 Página 2 de 20 Tabla de Contenido INTRODUCCIÓN OBJETIVO GLOSARIO DE TÉRMINOS Reglas relacionadas con definición de la estrategia y arquitectura de TI Reglas relacionadas con gestión de la demanda y portafolio de TI Reglas relacionadas con planeación del servicio de TI REGLAS DE NEGOCIO PARA DIRECCIÓN DE PROYECTOS DE TI Página 2

3 Página 3 de 20 INTRODUCCIÓN Acorde con el Modelo Normativo Interno propuesto para las Empresas, mediante el cual se busca optimizar el manejo de la información, la efectividad en la toma de decisiones y facilitar la operación, corresponde al Subdirector de Tecnología de Información (STI-EPM) dictar las reglas de negocio para la Gestión de Tecnología de Información contando con una normativa interna que indique como se deben operar, sin desconocer las normas externas que impactan los mismos, es decir, tomando como referente las disposiciones legales y estatutarias de los sistemas y modelos de gestión. El Modelo Normativo Interno para su aplicación tiene en cuenta dos manuales, el primero contiene la política aprobada por la Junta Directiva de EPM y los lineamientos dictados por el Gerente General; el segundo manual relaciona las reglas de negocio definidas por el responsable del proceso que detallan o establecen la operación del proceso. Como parte del primer manual, la Junta Directiva en su sesión de febrero 01 de 2011, según Acta 1528 definió la política para la Gestión de Tecnología de Información en los siguientes términos: En EPM, la Gestión de Tecnología de Información habilita a la empresa para que disponga de la información requerida por los grupos de interés y se adapte oportunamente a los cambios generados por el entorno, sus procesos y la visión de negocio, usando como referencia la arquitectura empresarial y operando bajo un modelo de prestación de servicios con las mejores prácticas de mercado como una forma de apalancar la sostenibilidad y el crecimiento del negocio. Paso siguiente, el Gerente General el 31 de enero de 2012, según Decreto 1866 definió el Manual de lineamientos asociados al macroproceso gestión de tecnología de información, y como objetivo fundamental Establecer los Lineamientos Asociados al Macro proceso Gestión de Tecnología de Información, con el propósito de guiar la toma de decisiones en el marco de tecnología de información (TI en este documento) y la optimización y aprovechamiento de sus recursos. Y como parte del segundo manual, Bajo el entendido de que los lineamientos están en continua evolución, la Subdirección Tecnología de Información (STI-EPM) tiene, de acuerdo Página 3

4 Página 4 de 20 con el marco de gobierno definido para el Grupo Empresarial EPM (GE-EPM), la responsabilidad de crear los mecanismos de actualización y divulgación apropiados que permitan publicar y desarrollar estos lineamientos a través de reglas de negocio, procedimientos e instructivos., así como se contempló en el decreto 1866 de enero 31 de Este documento contiene el Manual de Reglas de Negocio asociadas a los lineamientos del proceso Estrategia del servicio de TI y brinda elementos de referencia que facilitan la orientación y actuación de todos los servidores de EPM. OBJETIVO Establecer las Reglas de Negocio asociadas a los lineamientos del proceso Estrategia del servicio de TI, con el propósito de establecer parámetros que califican y cuantifican criterios específicos para la actuación del personal en la operación de dichos procesos. GLOSARIO DE TÉRMINOS A continuación, se presenta la definición de los términos de TI que facilitan la comprensión del presente documento. CICLO DE VIDA DE SOFTWARE: Es un período de tiempo que se inicia cuando se concibe el producto software y finaliza cuando el producto software se retira de uso. Típicamente incluye: fase de requisitos, fase de diseño, fase de implementación, fase de pruebas, fase de instalación y liberación, fase de operación y mantención, y algunas veces, fase de retiro. Estas fases se pueden superponer o se puede ejecutar iterativamente. ARQUITECTURA DE UN SISTEMA SOFTWARE: La arquitectura de un sistema es el conjunto de decisiones significativas sobre la organización del sistema software; la selección de elementos estructurales y sus interfaces a través de los cuales se constituye el sistema; el comportamiento del sistema, como se especifica en las colaboraciones de esos elementos; la composición de esos elementos estructurales y de comportamiento en subsistemas Página 4

5 Página 5 de 20 progresivamente más grandes; el estilo arquitectónico que guía esta organización: los elementos estáticos y dinámicos y sus interfaces, su colaboración y su composición. SISTEMA SOFTWARE: Un sistema software es una colección de subsistemas organizados para lograr un propósito descrito por un conjunto de modelos que representan diferentes puntos de vista del sistema. Desde un enfoque de ciclo de vida, un sistema representa el elemento que se está desarrollando, visto desde diferentes dimensiones mediante diferentes modelos presentados en forma de diagramas. SUBSISTEMA: Un subsistema es un grupo de elementos, algunos de los cuales constituyen una especificación del comportamiento ofrecido por los otros subsistemas. MODELO: Un modelo es una abstracción semánticamente cerrada de un sistema, es decir, representa una simplificación completa y autoconsciente de la realidad, creado para comprender mejor el sistema, es decir, representa una simplificación completa y autoconsciente de la realidad, creado para comprender el sistema. VISTA: Una vista es una proyección de la organización y estructura de un modelo de un sistema en el contexto de su arquitectura. DIAGRAMA: Es la representación gráfica de un conjunto de elementos, el cual normalmente se muestra como un grafo de nodos (elementos) y arcos (relaciones). DIAGRAMAS ESTRUCTURALES DE UN SISTEMA SOFTWARE: Existen para especificar, construir y documentar los aspectos estáticos de un sistema software. Los aspectos estáticos de un sistema representan su esqueleto y su andamiaje, es decir, incluyen la existencia y ubicación de clases, interfaces, colaboraciones, componentes y nodos. Los aspectos estáticos de un sistema se representan mediante los diagramas siguientes: diagrama de clases, diagrama de objetos, diagrama de componentes, diagramas de despliegue. DIAGRAMA DE CLASES: Un diagrama de de clases presenta un conjunto de clases, interfaces y colaboraciones, y las relaciones entre ellas. Se utilizan para describir la vista de diseño estática o la vista de procesos estática de un sistema. Los diagramas de clase que Página 5

6 Página 6 de 20 incluyen clases activas se utilizan para cubrir la vista de procesos estática de un sistema. Los diagramas de clases son los diagramas más comunes en el modelado de sistemas orientados por objetos. Por último, un sistema se puede estructurar como un conjunto de subsistemas, donde un diagrama de subsistemas como un conjunto de clases del sistema. DIAGRAMAS DE OBJETOS: Un diagrama de objetos representa un conjunto de objetos y sus relaciones. Se utiliza para describir estructuras de datos, instantáneas de las instancias de los elementos que se encuentran en los diagramas de clases. Los diagramas de objetos cubren la vista de diseño estática o la vista de procesos estática de un sistema al igual que los diagramas de clase, pero desde la perspectiva de casos reales o prototípicos. DIAGRAMAS DE COMPONENTES: Un diagrama de componentes muestra un conjunto de componentes y sus relaciones. Los diagramas de componentes se utilizan para describir la vista de implementación estática de un sistema. Los diagramas de componentes se relacionan con los diagramas de clases en que un componente normalmente se corresponde con una o más clases, interfaces o colaboraciones. DIAGRAMAS DE DESPLIEGUE: Un diagrama de despliegue muestra un conjunto de nodos y sus relaciones. Los diagramas de despliegue se utilizan para describir la vista de despliegue estática de una arquitectura. Los diagramas de despliegue se relacionan con los diagramas de componentes en que un nodo normalmente incluye uno o más componentes. DIAGRAMAS DE COMPORTAMIENTO DE UN SISTEMA SOFTWARE: Se emplean para visualizar, especificar, construir y documentar los aspectos dinámicos de un sistema software. Los aspectos dinámicos de un sistema software se pueden ver como aquellos que representan sus partes mutables. Los aspectos dinámicos de un sistema software involucran cosas tales como el flujo de mensajes entre los componentes del sistema a lo largo del tiempo y el movimiento físico de los componentes en una red de telecomunicaciones. Los componentes dinámicos de un sistema software se representan mediante los diagramas siguientes: diagramas de casos de uso, diagramas de secuencia, diagramas de colaboración, diagramas de estados, diagramas de actividades. Página 6

7 Página 7 de 20 DIAGRAMAS DE CASOS DE USO: Un diagrama de casos de uso representa un conjunto de casos de uso y actores (un tipo especial de clase) y sus relaciones. Los diagramas de casos de uso se utilizan para describir la vista de casos de uso estática de un sistema. Los diagramas de casos de uso son especialmente importantes para organizar y modelar los comportamientos de un sistema. DIAGRAMAS DE INTERACCIÓN: Es el nombre que recibe el conjunto conformado por los diagramas de secuencia y diagramas de colaboración. DIAGRAMAS DE SECUENCIA: Un diagrama de secuencia es un diagrama de interacción que resalta la ordenación temporal de los mensajes. El diagrama de secuencia presenta el conjunto de objetos y los mensajes enviados y recibidos por ellos. Los objetos suelen ser instancias con nombre o anónimas de clases, pero también pueden representar instancias de otros elementos, tales como colaboraciones, componentes y nodos. Los diagramas de secuencia se utilizan para describir la vista dinámica de un sistema. Los diagramas de secuencia y colaboración son isomorfos, es decir, se puede convertir el uno en el otro sin pérdida de información. DIAGRAMAS DE COLABORACIÓN: Un diagrama de colaboración es un diagrama de interacción que resalta la organización estructural de los objetos que envían y reciben mensajes. Un diagrama de colaboración muestra un conjunto de objetos, enlaces entre esos objetos y mensajes enviados y recibidos por esos objetos. Los objetos normalmente son instancias con nombre o anónimas de clase, pero también pueden representar instancias de otros elementos, como colaboraciones, componentes y nodos. Los diagramas de colaboración se utilizan para describir la vista dinámica de un sistema. Los diagramas de secuencia se utilizan para describir la vista dinámica de un sistema. Los diagramas de secuencia y colaboración son isomorfos, es decir, se puede convertir el uno en el otro sin pérdida de información. DIAGRAMAS DE ESTADOS: Un diagrama de estados representa una máquina de estados, constituida por estados, transiciones, eventos, actividades. Los diagramas de estados se utilizan para describir la vista dinámica del un sistema. Son especialmente importantes para modelar el comportamiento de una interfaz, una clase o una colaboración. Los diagramas de Página 7

8 Página 8 de 20 estado resaltan el comportamiento dirigido por eventos de un objeto, lo que es especialmente útil al modelar sistemas reactivos. Los diagramas de secuencia se utilizan para describir la vista dinámica de un sistema. Los diagramas de estado y actividades son isomorfos, es decir, se puede convertir el uno en el otro sin pérdida de información. DIAGRAMA DE ACTIVIDADES: Un diagrama de actividades muestra el flujo de actividades en un sistema. Una actividad muestra un conjunto de actividades, el flujo secuencial o ramificado de actividades y los objetos que actúan y sobre los que se actúa. Los diagramas de actividades se utilizan para ilustrar la vista dinámica de un sistema. Además, estos diagramas son especialmente importantes para modelar la función de un sistema, así como para resaltar el flujo de control entre objetos. Los diagramas de estado y actividades son isomorfos, es decir, se puede convertir el uno en el otro sin pérdida de información. Página 8

9 Página 9 de 20 1 REGLAS DE NEGOCIO PROCESO ESTRATEGIA DEL SERVICIO DE TI. 1.1 Reglas relacionadas con definición de la estrategia y arquitectura de TI Alineación del Proceso: El Procesos debe estar alineado y sincronizados con el proceso de Planeacion estratégico del Grupo EPM. Alineación del Ciclo de Planeación: El ciclo de planeación de la OTI debe estar alineado al ciclo de planeación de Grupo EPM. Formulación de Estrategias de TI: La formulación de la estrategia de TI estará alineada con la estrategia empresarial, de negocio y sus respectivas herramientas y métodos. Insumos de las estrategias de TI: Para la formulación de estrategias de TI se usarán como insumos el análisis del entorno, las directrices estratégicas, los objetivos estratégicos y el mapa de riesgos estratégicos de EPM. Contenido de una estrategia de TI: Toda estrategia de TI debe tener un objetivo claro y tener asociados planes de acción que permitan materializarla. Herramientas y Métodos de Planeacion Estratégica de TI: Las herramientas y los métodos de Planeación Estratégica de TI deben estar alineados y sincronizados con las herramientas y los métodos de Planeacion Empresarial Plan Estratégico de TI: Basados en la Arquitectura de TI formulada y en la demanda de TI, se debe definir el respectivo plan estratégico de TI para EPM. Cada una de las dependencias involucradas en el proceso Gestión TI en EPM, deberán elaborar y actualizar anualmente su plan de TI, presupuestarlo, llevarlo a aprobación a las instancias definidas. Página 9

10 Página 10 de 20 Consolidación del PETI del Grupo: EPM debe integrar y consolidar para el Grupo EPM los respectivos planes estratégicos de TI la atención de sus necesidades para asegurar que se cuenten con los recursos necesarios de ambas partes y poder hacer la gestión y seguimiento del mismo para garantizar un crecimiento armónico de la TI en el Grupo. Formulación del Modelo de trabajo TI: La Formulación del modelo de trabajo de TI estará alineada con el modelo de trabajo del grupo Empresarial y sus respectivas herramientas y métodos. Alcance del modelo de trabajo de TI: El modelo de trabajo de TI debe considerar la política,, los lineamientos, las reglas de negocio, el modelo de atención,la Estrategia de Recursos Humanos (Tercerización)., la Estrategia de Entrega de Servicios, las Métricas de Desempeño de la TI Tercerización de actividades de TI: La organización informática de EPM (OTI) no tercerizará las actividades de los procesos de TI que requieren competencias específicas claves del talento humano de TI de EPM; por lo tanto deberá desarrollarlas y garantizar que se efectúe la vinculación a EPM del personal que las posea. Formulación y desarrollo de la Arquitectura de TI: La formulación de la Arquitectura de TI estará alineada con el Modelo de Trabajo, la estrategia empresarial de EPM y sus respectivas herramientas y métodos. Insumos de la Arquitectura de TI: Para la formulación de Arquitectura de TI se usarán como insumos el modelo de trabajo, la arquitectura de negocios, el análisis del entorno, las directrices estratégicas, los objetivos estratégicos y el mapa de riesgos estratégicos Cubrimiento de la Arquitectura de TI: La Arquitectura de TI debe tener un cubrimiento de EPM como casa matriz del Grupo Empresarial asegurando la alineación de TI con el modelo de trabajo y cumpliendo con lo definido en dicho modelo Página 10

11 Página 11 de 20 Gobierno de Arquitectura: Las alternativas de solución propuestas al negocio, así como las arquitecturas de referencia, estarán gobernadas por los principios de arquitectura (negocio, aplicaciones, datos y tecnología) definidos por EPM. Cobertura de las Arquitecturas de Referencia de TI: Las arquitecturas de referencia, en el entorno de TI, deben considerar los tres dominios técnicos (datos, aplicaciones, tecnología). Oportunidad de las Arquitecturas de Referencia de TI: La Elección de arquitecturas de Referencia de TI deben facilitar el análisis e identificación de las alternativas de solución. Herramientas y Métodos de Arquitectura: Las herramientas y los métodos de arquitectura de TI deben estar alineados y sincronizados con las herramientas y los métodos de arquitectura de negocio en un marco común de arquitectura empresarial. Excepciones de la Arquitectura de TI: Todas las excepciones a la Arquitectura de TI deben ser sustentadas y presentadas de acuerdo a lo definido en el marco de trabajo. Las excepciones a la Arquitectura de TI deben ser aprobadas, consolidadas y publicadas por EPM. Herramientas de desarrollo de software: La Organización de Tecnología de Información de EPM es la encargada de definir al interior de EPM, cuáles son las herramientas software que se utilizarán durante el ciclo de vida de desarrollo de los diferentes servicios de TI, tales como lenguajes de programación, generadores de lenguaje, herramientas para la administración de datos en bases de datos, herramientas de acceso a las bases de datos, herramientas para configurar soluciones, herramientas para consultar y desplegar información, y todas aquellas otras que cumplan con las arquitecturas tecnológica, de aplicaciones y de datos de EPM, y que sean avaladas por la Organización de Tecnología de Información (OTI) de EPM. Igualmente, la Organización de Tecnología de Información es la encargada de autorizar el uso de estas herramientas software al personal vinculado a EPM, al personal de los proveedores de servicios de fábrica de software, de fábrica de Página 11

12 Página 12 de 20 pruebas, o de proveedores que suministran productos y servicios que incorporan servicios de TI. Alineación de las ideas de TI: Las ideas de TI estarán alineadas con la visión de la TI y aportaran valor al negocio. Gestion de ideas de TI: Las ideas de TI deben ser documentadas y administradas cumpliendo los lineamientos y reglas del negocio del proceso Gestión de la Demanda y Portafolio de TI y serán sometidas a evaluación y priorización como cualquier necesidad de negocio.. Evaluar desempeño de la TI: Obtener y consolidar la información de desempeño de la TI a partir de sus procesos de gestión de TI. Cuadro de Mandos de TI: Se debe actualizar mensualmente del BSC (Balanced Score Card Cuadro Integral de Mandos) de TI Reglas relacionadas con gestión de la demanda y portafolio de TI. Planeación de Necesidades: La Subdirección Tecnología de Información y las Unidades Informáticas de los negocios, solo recibirá necesidades de información, que provengan del proceso formal de planeación empresarial (Planes de negocio, Planes de soporte, Planes de mercadeo, Plan de Tecnología de Información y equivalentes) o aquellas que al no ser previsibles, sean solicitadas directamente por los clientes de tecnología de información o sus representantes. Se consideran necesidades de información no previsibles, las que se originan de la dinámica propia de la empresa y su entorno, tales como obligaciones de cumplimiento a nueva normatividad, cambios en productos y servicios ofrecidos por EPM a sus clientes, actividades de crecimiento del mercado, atención de recomendaciones de entes de control, asunto críticos operativos, requerimientos de información de terceros, cambios organizacionales o necesidades equivalentes debidamente justificadas. Página 12

13 Página 13 de 20 Inventario de Necesidades: Las necesidades de información deben ser recogidas y gestionadas a través del proceso Gestión de Demanda y Portafolio de TI y se clasificarán en primera instancia como una Idea, hasta que sean debidamente definidas, justificadas y documentadas por la dependencia que la origina, momento a partir del cual adquieren el carácter de un Requerimiento de Negocio a ser atendido por la Organización de Tecnología de Información. Una Idea se considera bien documentada cuando tenga completamente descrito el Problema u Oportunidad de negocio, Identificación del patrocinador, dependencias y actores involucrados; diagnóstico de la situación actual y una justificación de negocio en términos de los beneficios obtenidos al resolver el problema o aprovechar la oportunidad, así como la definición detallada de los procesos involucrados con sus respectivos flujos de información. Documentación de Ideas: La documentación de las ideas es responsabilidad de los clientes de la OTI, para lo cual contarán con el apoyo de los ejecutivos de cuenta asignados por la Organización de tecnología de Información. Las ideas que no sean documentadas en un plazo máximo de 3 meses serán archivadas y eliminadas del proceso de Gestión de Demanda y Portafolio de TI. Clasificación de las Ideas: Una vez se tenga una definición clara en términos de negocio de las ideas que requieren una solución de tecnología de información estás se clasificarán para su gestión en iniciativas o requerimientos de servicio según con base en el siguiente criterio: o Requerimiento de servicio: Está orientado a modificar o adicionar funcionalidad o los niveles de servicio de una solución existente (Servicio, sistema de información o plataforma tecnológica) y su costo estimado es inferior a 200 salarios mínimos legales mensuales. o Iniciativa: Cuando se trate de la implementación nuevos servicios, tecnologías y soluciones informáticas o cuando se trate de modificar o escalar soluciones existentes que implican esfuerzos significativos con costo estimado superior a 200 SMMLV. Página 13

14 Página 14 de 20 Registro de Iniciativas: Las iniciativas deberán ser incorporadas en los planes de negocio o soporte para su atención y serán definidas, evaluadas y priorizadas a través de casos de negocio. La elaboración de los casos de negocio es responsabilidad principal de las UEN y las dependencias del nivel institucional dueñas de procesos en EPM, quienes deberán, describir el alcance en términos de negocio y describir los beneficios cuantitativos y cualitativos de la iniciativa y sustentarlos ante el comité Negocio TI, hasta lograr su aprobación, para poder continuar con la definiciones de alternativas de solución, el costeo y la asignación de recursos. Alternativas de Solución a las Iniciativas: Las OTI elaborará alternativas de solución para las iniciativas aprobadas y estimará los costos, esfuerzos y riesgos para su ejecución. Con la información de beneficio (valor) entregado por el dueño de la necesidad, el costo y el análisis de riesgo se hará una evaluación comparativa de las iniciativas en el portafolio de TI con el fin de determinar un orden de prioridad para la asignación de recursos y autorización de su ejecución como proyecto. Priorización de Proyectos: La responsabilidad de aprobar los proyectos, definir su prioridad y asignar recursos (financieros y humanos), recaerá en el Comité Negocios Tecnología de Información, quienes además harán seguimiento a los proyectos en ejecución. Presupuestación de proyectos: Las UEN, dependencias o filiales dueñas de la necesidad que da origen a un proyecto que contiene componentes de tecnología de información, son las responsables de obtener el presupuesto requerido por éstos, en las distintas vigencias en que su programe su ejecución. Vigencia de las Iniciativas/Proyectos: Aquellas iniciativas con alternativas de solución definidas, o aquellos proyectos aprobados que permanezcan en el portafolio de TI por un lapso superior a un año, sin haber iniciado su ejecución, deberán ser reevaluados para verificar su pertinencia o cancelados en caso de haber perdido prioridad o interés para el negocio. Página 14

15 Página 15 de 20 Definición y Priorización de Requerimientos de Servicio: Los requerimientos de servicio serán definidos y priorizados en función de su discrecionalidad, impacto, riesgo, beneficio y costo serán clasificados y programados para ser atendidos con versiones de producto que serán liberadas periódicamente según la frecuencia que establezca el proceso de planeación de servicios. Predecir e Influenciar la Demanda de TI: La Organización de Tecnología de Información, implementará procedimientos proactivos encaminados a predecir e influenciar la demanda de servicios de tecnología de información, a partir de análisis de crecimiento vegetativo de variables de negocio y análisis de la información disponible en los planes de negocio y establecerá mecanismos para satisfacer dicha demanda o negociar su distribución en el tiempo con el fin de reducir picos y mejorar la oportunidad de atención, en función de las capacidades organizacionales y los recursos disponibles. Gestión integral de la demanda: Con el fin de asegurar una análisis completo de la demanda que afecte a procesos y servicios comunes y propender por la obtención de soluciones integrales que simplifiquen la arquitectura de aplicaciones, se crearán grupos o equipos de demanda y se establecerán procedimientos que ayuden a analizar y consolidar necesidades comunes en una misma iniciativa. Herramienta para la gestión de la demanda: Se implementará una herramienta de gestión de demanda y portafolio de proyectos, la cual debe estar alineada con las herramientas que se apliquen el los procesos de Planeación Empresarial, con el fin de facilitar la ejecución controlada del proceso Gestión de demanda, la priorización de los proyectos y la generación de métricas del proceso. 1.3 Reglas relacionadas con planeación del servicio de TI Conceptualización de servicios: Cada nuevo servicio del portafolio de servicios de tecnología de información, serán previamente modelado con el fin de asegurar que contemple todos los elementos y componentes requeridos para generar valor y satisfacer las necesidades del negocio para las cuales ha sido desarrollado. El modelo Página 15

16 Página 16 de 20 conceptual del servicio es la especificación de lo que será su alcance, sus objetivos, los recursos necesarios para prestar el servicio, las necesidades y clientes a los que se orienta el servicio, las condiciones o restricciones que originan el servicio para que su diseño posterior satisfaga los requerimientos de negocio. El modelo conceptual debe incluir tanto los aspectos externos que generan influencia sobre el servicio (procesos de negocio, información, usuarios, ambiente operativo, etc), como los componentes internos del mismo (plataforma, aplicaciones, funcionalidad, capacidades organizacionales requeridas para su operación, evolución y soporte, procedimientos administrativos y operativos, niveles de servicio esperados, etc) Versionamiento de Servicios de TI: La Organización Tecnología de información desarrollará y evolucionará los servicios de tecnología de información mediante planes de entrega por versiones, cada una de las cuales empaquetará un conjunto limitados de requerimientos funcionales y no funcionales, que serán definidos, especificados, diseñados, construidos, probados y liberados como una sola unidad, según programación previamente establecida en un calendario de versiones, con el fin de asegurar la disponibilidad de recursos y mantener un mejor control sobre los procesos de desarrollo del servicio. Inicialmente se implementará la planeación de versiones para los servicios considerados críticos para el negocio, y a medida que el proceso madure, se irán incorporando nuevos servicios a la planeación por versiones. Tamaño y Frecuencia de las Versiones del Servicio de TI: El tamaño y la frecuencia de entrega de las distintas versiones será establecido por el proceso de planeación de versiones teniendo en cuenta los requerimientos del negocio, el esfuerzo y complejidad de los requerimientos y la disponibilidad de recursos humanos y técnicos para llevar a cabo las actividades de especificación, análisis, diseño, construcción, adquisición, integración, pruebas y aseguramiento de la calidad de las nuevas versiones. Contenidos de los Planes de Versiones: Los planes de versiones deberán incluir tanto los requerimientos de negocio, como los requerimientos técnicos que se originan en los programas de mantenimiento, optimización, renovación, reposición y Página 16

17 Página 17 de 20 migraciones tecnológicas con el fin de asegurar la vigencia continuidad de las soluciones informáticas. Clasificación de las Versiones de los Servicios de TI: Se tendrán dos tipos de versiones. Las versiones estándar y las versiones de emergencia. Las versiones estándar corresponden a paquetes de requerimientos funcionales y no funcionales (técnicos) que se planean para ser definidos, implementados y liberados a producción siguiendo unos calendarios previamente establecidos, con dos puntos de control claramente establecidos: La fecha de corte, que corresponde a la fecha máxima en que se reciben requerimientos para ser incluidos en la versión y fecha de liberación, que corresponde a la fecha en que se estima que una versión será liberada a producción. Las versiones de emergencia son programaciones por excepción que se hacen para resolver requerimientos de negocio de obligatorio cumplimiento o resolver asuntos críticos operativos que no pueden esperar hasta la próxima versión estándar del producto. Para evitar un uso inadecuado de las versiones de emergencia, se mantendrá un indicador que permita llevar un control de éstas. Tiempos de estabilización de los Servicios de TI: Para los nuevos servicios que se liberen a producción, se deberá acordar con el cliente, un periodo de estabilización técnica y funcional para resolver problemas y fallas que se presenten. Los cambios que se deben efectuar para lograr la estabilización de un nuevo servicio durante la fase de estabilización no pasarán por el proceso de versiones, pero cualquier requerimiento de mejora o nueva funcionalidad que surja, y que no sea tendiente a resolver problemas de operación, deberán planearse para ser incorporadas en versiones posteriores, siguiendo el proceso de planeación de versiones. Responsable de los Servicios de TI: Cada servicio de tecnología de información tendrá un arquitecto de servicio (también denominado líder de servicio), quien será el responsable de garantizar la integridad, calidad y disponibilidad del servicio a través de todo su ciclo de vida, de determinar la factibilidad técnica de implementar nuevas funcionalidades o capacidades al servicio, de conceptualizar el servicio y de establecer y coordinar la planeación de versiones del servicio, entre otras actividades. Página 17

18 Página 18 de 20 Evaluación de servicios: Los servicios de tecnología de información serán periódicamente evaluados por el el equipo de trabajo responsable del servicio bajo el liderazgo del arquitecto de servicio, con el fin de identificar brechas funcionales y riesgos potenciales para la prestación del servicio y proponer planes de evolución, mejora e innovación del servicio que serán posteriormente priorizados y programados para ser atendidos como parte de los planes de versiones. Página 18

19 Página 19 de 20 2 REGLAS DE NEGOCIO PARA DIRECCIÓN DE PROYECTOS DE TI Inicio de un proyecto o programa: No se debe iniciar ningún proyecto o programa que implique el desarrollo de un producto o servicios de TI sin que se hayan cumplido todas las instancias de aprobación y firmas del Representante del Cliente, el Ejecutivo de Cuenta y la Unidad de soluciones responsable de su desarrollo, lo que se constituye un mandato de ejecución Programa o Proyecto: Una iniciativa aprobada por el cliente de TI puede resultar en un programa (varios proyectos cubiertos por una sola iniciativa) o un proyecto único. Condiciones general para programas o proyectos. El programa o proyecto debe contar con un Director de Programa y/o Proyecto y un equipo para la ejecución del mismo. Para el programa no se define arquitectura, solo se entregan un conjunto de lineamientos generales. Registro de los programas ó Proyecto: Los programas o proyectos se deben matricular en la herramienta de gestión definida por EPM) de acuerdo con parámetros y estándares que facilitan la gestión integral Planeación de los proyectos. Cada proyecto debe planearse de manera detallada en una fase de definición de alcance y plan de trabajo, la cual debe entregar como mínimo el documento de visión, alcance del proyecto y el plan de dirección del proyecto. Una vez aprobada la fase anterior, el proyecto puede dividirse en una planeación gradual, iterativa e incremental la cual debe cubrir en forma detallada los procesos de ingeniería de requisitos, análisis de solución, Diseño-Construcción de la solución y Pruebas, seguridad y operación de la solución resultante. Dirección de Proyectos: Los proyectos aprobados para proveer o mejorar Soluciones y Servicios de TI deberán llevarse a cabo mediante la utilización de la disciplina de Gerencia de Proyectos establecida en EPM y deberá incluir dentro de su plan de trabajo todas las actividades propias para implantación del proyecto y además debe tener definido el alcance del proyecto, la respectiva Verificación de alcance y Control Página 19

20 Página 20 de 20 de cambios del alcance, manejo de Cronograma y tiempos del proyecto, los costos del proyecto, planeación, aseguramiento y control de la calidad, tener el recurso humano asignado al proyecto con los roles, responsabilidades y compromiso de los jefes, el planeamiento de las comunicaciones, reporte de avance, gestión de riesgo del proyecto y lo relacionado con el plan de contrataciones con proveedores y la administración de contratos y cierre de contratos. Información de Programa o Proyecto: Los proyectos deben contar con información permanente relacionada con su gestión. Avance de los programas ó Proyecto: Los programas o proyectos deben Generar como mínimo una vez al mes su estado de avance respecto a: su alcance tiempo, costos y riesgos. Seguimiento a los programas ó Proyecto: Los Comités patrocinadores de los programas o proyectos deben hacer seguimiento y control como mínimo una vez al mes para controlar el avance planeado vs la ejecución respecto a: su alcance tiempo, costos y riesgos, para hacer los ajustes pertinentes. Cambio a Programa ó Proyectos: Los Cambios a los Programas ó Proyectos se deben realizar y aprobar formalmente por las instancias competentes. Cierre a Programa ó Proyectos: Los programas y proyectos una vez hayan cumplido con su objetivo o sean suspendidos o cancelados por las instancias competentes se deben ser cerrar formalmente Página 20