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
ESTRUCTURA NORMATIVA DE EMPRESAS PÚBLICAS DE MEDELLÍN E.S.P.
REGLAS DE NEGOCIO PROCESO ESTRATEGIA DEL SERVICIO DE TI
Página 2 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 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
ESTRUCTURA NORMATIVA DE EMPRESAS PÚBLICAS DE MEDELLÍN E.S.P.
REGLAS DE NEGOCIO PROCESO ESTRATEGIA DEL SERVICIO DE TI
Página 3 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 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
ESTRUCTURA NORMATIVA DE EMPRESAS PÚBLICAS DE MEDELLÍN E.S.P.
REGLAS DE NEGOCIO PROCESO ESTRATEGIA DEL SERVICIO DE TI
Página 4 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 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
ESTRUCTURA NORMATIVA DE EMPRESAS PÚBLICAS DE MEDELLÍN E.S.P.
REGLAS DE NEGOCIO PROCESO ESTRATEGIA DEL SERVICIO DE TI
Página 5 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 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
ESTRUCTURA NORMATIVA DE EMPRESAS PÚBLICAS DE MEDELLÍN E.S.P.
REGLAS DE NEGOCIO PROCESO ESTRATEGIA DEL SERVICIO DE TI
Página 6 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 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.
ESTRUCTURA NORMATIVA DE EMPRESAS PÚBLICAS DE MEDELLÍN E.S.P.
REGLAS DE NEGOCIO PROCESO ESTRATEGIA DEL SERVICIO DE TI
Página 7 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 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
ESTRUCTURA NORMATIVA DE EMPRESAS PÚBLICAS DE MEDELLÍN E.S.P.
REGLAS DE NEGOCIO PROCESO ESTRATEGIA DEL SERVICIO DE TI
Página 8 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 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.
ESTRUCTURA NORMATIVA DE EMPRESAS PÚBLICAS DE MEDELLÍN E.S.P.
REGLAS DE NEGOCIO PROCESO ESTRATEGIA DEL SERVICIO DE TI
Página 9 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 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.
ESTRUCTURA NORMATIVA DE EMPRESAS PÚBLICAS DE MEDELLÍN E.S.P.
REGLAS DE NEGOCIO PROCESO ESTRATEGIA DEL SERVICIO DE TI
Página 10 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 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
ESTRUCTURA NORMATIVA DE EMPRESAS PÚBLICAS DE MEDELLÍN E.S.P.
REGLAS DE NEGOCIO PROCESO ESTRATEGIA DEL SERVICIO DE TI
Página 11 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 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
ESTRUCTURA NORMATIVA DE EMPRESAS PÚBLICAS DE MEDELLÍN E.S.P.
REGLAS DE NEGOCIO PROCESO ESTRATEGIA DEL SERVICIO DE TI
Página 12 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 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.
ESTRUCTURA NORMATIVA DE EMPRESAS PÚBLICAS DE MEDELLÍN E.S.P.
REGLAS DE NEGOCIO PROCESO ESTRATEGIA DEL SERVICIO DE TI
Página 13 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 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.
ESTRUCTURA NORMATIVA DE EMPRESAS PÚBLICAS DE MEDELLÍN E.S.P.
REGLAS DE NEGOCIO PROCESO ESTRATEGIA DEL SERVICIO DE TI
Página 14 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 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.
ESTRUCTURA NORMATIVA DE EMPRESAS PÚBLICAS DE MEDELLÍN E.S.P.
REGLAS DE NEGOCIO PROCESO ESTRATEGIA DEL SERVICIO DE TI
Página 15 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 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
ESTRUCTURA NORMATIVA DE EMPRESAS PÚBLICAS DE MEDELLÍN E.S.P.
REGLAS DE NEGOCIO PROCESO ESTRATEGIA DEL SERVICIO DE TI
Página 16 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 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
ESTRUCTURA NORMATIVA DE EMPRESAS PÚBLICAS DE MEDELLÍN E.S.P.
REGLAS DE NEGOCIO PROCESO ESTRATEGIA DEL SERVICIO DE TI
Página 17 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 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.
ESTRUCTURA NORMATIVA DE EMPRESAS PÚBLICAS DE MEDELLÍN E.S.P.
REGLAS DE NEGOCIO PROCESO ESTRATEGIA DEL SERVICIO DE TI
Página 18 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 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.
ESTRUCTURA NORMATIVA DE EMPRESAS PÚBLICAS DE MEDELLÍN E.S.P.
REGLAS DE NEGOCIO PROCESO ESTRATEGIA DEL SERVICIO DE TI
Página 19 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 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
ESTRUCTURA NORMATIVA DE EMPRESAS PÚBLICAS DE MEDELLÍN E.S.P.
REGLAS DE NEGOCIO PROCESO ESTRATEGIA DEL SERVICIO DE TI
Página 20 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 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