MANUAL DE REGLAS DE NEGOCIO ASOCIADAS AL … · REGLAS DE NEGOCIO PROCESO ESTRATEGIA DEL SERVICIO...

ESTRUCTURA NORMATIVA DE EMPRESAS PÚBLICAS DE MEDELLÍN E.S.P.

REGLAS DE NEGOCIO PROCESO ESTRATEGIA DEL SERVICIO DE TI

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 Junio 2012

Página 1

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 2 de 20



Página 2

Tabla de Contenido

INTRODUCCIÓN

OBJETIVO

GLOSARIO DE TÉRMINOS

1 REGLAS DE NEGOCIO PROCESO ESTRATEGIA DEL SERVICIO DE TI. ..................... 9

1.1 Reglas relacionadas con definición de la estrategia y arquitectura de TI ........................... 9

1.2 Reglas relacionadas con gestión de la demanda y portafolio de TI. ................................ 12

1.3 Reglas relacionadas con planeación del servicio de TI ................................................... 15

2 REGLAS DE NEGOCIO PARA DIRECCIÓN DE PROYECTOS DE TI ........................... 19



Página 3 de 20



Página 3

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 4 de 20



Página 4

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

2012.

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 5 de 20



Página 5

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 6 de 20



Página 6

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 7 de 20



Página 7

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 8 de 20



Página 8

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 9 de 20



Página 9

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 10 de 20



Página 10

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 11 de 20



Página 11

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 12 de 20



Página 12

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

1.2 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 13 de 20



Página 13

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 14 de 20



Página 14

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 15 de 20



Página 15

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 16 de 20



Página 16

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 17 de 20



Página 17

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 18 de 20



Página 18

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 19 de 20



Página 19

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 20 de 20



Página 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

MANUAL DE REGLAS DE NEGOCIO ASOCIADAS AL … · REGLAS DE NEGOCIO PROCESO ESTRATEGIA DEL SERVICIO...

Documents

Transcript of MANUAL DE REGLAS DE NEGOCIO ASOCIADAS AL … · REGLAS DE NEGOCIO PROCESO ESTRATEGIA DEL SERVICIO...