evolución del marco para evaluar la conveniencia de
TRANSCRIPT
1
Evolución del marco para evaluar la conveniencia de adoptar servicios en la
nube en entidades públicas
Jose Robinson Pacheco Gómez y Mateo Saravia Salamanca
Proyecto de Grado de Ingeniería de Sistemas y Computación
Director
Oscar Javier Ávila Cifuentes, PhD
Facultad de Ingeniería
Departamento de Ingeniería de Sistemas y Computación
Universidad de los Andes
Junio de 2020
Bogotá D.C
2
TABLA DE CONTENIDO 1. Introducción ..................................................................................................................................... 6
1.1 Organización del proyecto ....................................................................................................... 7
2. Objetivos .......................................................................................................................................... 7
2.1 Objetivo general ...................................................................................................................... 7
2.2 Objetivos específicos: .............................................................................................................. 7
3. Marco teórico .................................................................................................................................. 8
3.1 Computación en la nube .......................................................................................................... 8
3.1.1 ¿Qué es la computación en la nube?............................................................................... 8
3.1.2 ¿Cuáles son las características de tiene la computación en la nube? ............................. 9
3.1.3 ¿Qué modelos de servicios en la nube existen? ............................................................10
3.1.4 ¿Qué modelos de despliegue existen en la computación en la nube? .........................11
3.1.5 Inhibidores de la informática en la nube .......................................................................11
3.2 Gobierno en línea ..................................................................................................................12
3.3 Marco para evaluar la conveniencia de adoptar servicios en la nube en entidades públicas
14
4. Evaluación y diagnóstico del marco para adoptar servicios en la nube en entidades públicas....20
4.1 Entrevista para el análisis del marco metodológico ..............................................................20
4.1.1 Modelo de preguntas: ...................................................................................................21
4.1.2 Dinámica de la entrevista: .............................................................................................21
4.1.3 Análisis y evaluación de las respuestas: ........................................................................21
4.2 Aplicación del marco metodológico a una entidad del sector público .................................25
4.2.1 Descripción general de las Centrales Eléctricas de Nariño (CEDENAR) .........................25
4.2.2 Descripción general del servicio de TI ...........................................................................26
4.2.3 Aplicación del marco sobre CEDENAR ...........................................................................27
4.3 Diagnóstico y conclusiones del marco de metodología actual .............................................29
5. Evolución del marco de evaluación ...............................................................................................30
5.1. Estructura del nuevo marco metodológico para adoptar servicios en la nube en entidades
públicas ..............................................................................................................................................31
5.2. Diseño del marco de evaluación ............................................................................................37
5.3. Ejemplo de aplicación del marco metodológico de adopción de servicios en la nube .........59
6. Aplicación del nuevo marco metodológico de adopción de servicios en la nube en empresas del
sector público ........................................................................................................................................60
6.1 Resultados de la aplicación del nuevo marco de evaluación para la adopción de servicios en
la nube ...............................................................................................................................................60
6.2 Conclusiones de la aplicación del nuevo marco de evaluación para la adopción de servicios
en la nube ..........................................................................................................................................63
3
7. Conclusiones ..................................................................................................................................64
Referencias ............................................................................................................................................66
Anexos....................................................................................................................................................68
Anexo A. Aplicación de la primera versión del marco de evaluación para evaluar la conveniencia de
adoptar servicios en la nube de entidades públicas..........................................................................68
Anexo B. Mapeo de mejores prácticas de ITIL 4 a procesos de ITIL v3. ............................................89
Anexo C. Aplicación de la segunda versión del marco para la viabilidad de adoptar servicios en la
nube en entidades públicas ...............................................................................................................89
4
ÍNDICE DE TABLAS Tabla 1. Marco de referencia de computación en la nube según la NIST (Mell & Grance, 2011). ......... 9
Tabla 2. Elementos de evaluación (Ruiz Aguilar, 2016). ........................................................................15
Tabla 3. Valores posibles del subcriterio nivel de cubrimiento (Ruiz Aguilar, 2016). ...........................18
Tabla 4. Valores posibles para el subcriterio de nivel de madurez del proceso (Ruiz Aguilar, 2016). ..18
Tabla 5. Valores posibles para el subcriterio de nivel de factibilidad financiera (Ruiz Aguilar, 2016). .18
Tabla 6. Actividades pertenecientes al lineamiento: LI.ST.01. Directorio de servicios tecnológicos
(Ruiz Aguilar, 2016). ...............................................................................................................................19
Tabla 7. Ejemplo de aplicación de los criterios pertenecientes a la categoría Cat_1. Arquitectura de
Servicios tecnológicos (Ruiz Aguilar, 2016) ...........................................................................................20
Tabla 8. Modelo de preguntas usadas en la entrevista. ........................................................................21
Tabla 9. Evaluación de la importancia de dificultades para la mejora del marco de evaluación (Ruiz
Aguilar, Entrevista del marco de evaluación para la adopción de servicios en la nube en entidades
públicas, 2020). ......................................................................................................................................22
Tabla 10. Mapa de procesos fraccionado – Enfocado en la sección de Apoyo (CEDENAR, 2020). .......26
Tabla 11. Valores posibles del subcriterio nivel de cubrimiento (Ruiz Aguilar, 2016). .........................34
Tabla 12. Valores posibles para el subcriterio de nivel de madurez del proceso (ITIL, 2013). .............35
Tabla 13. Nuevos valores posibles para el subcriterio de nivel de factibilidad financiera....................36
Tabla 14. Ejemplo de evaluación del subcriterio de nivel de factibilidad financiera. ...........................36
Tabla 15. Valores posibles para el subcriterio de nivel de nivel de liquidez. ........................................37
Tabla 16. Criterios, actividades y procesos definidos para la ejemplificación de la aplicación del
marco metodológico de adopción de servicios en la nube. ..................................................................59
Tabla 17. Ejemplificación de la aplicación del marco metodológico de adopción de servicios en la
nube para dos criterios. .........................................................................................................................60
5
ÍNDICE DE FIGURAS Figura 1. Metamodelo del Marco de Referencia de Arquitectura Empresarial del MinTIC (MinTIC,
2019). .....................................................................................................................................................14
Figura 2. Meta modelo del Marco de evaluación para adoptar servicios en la nube (Ruiz Aguilar,
2016) ......................................................................................................................................................19
Figura 3. Tiempos en la migración de un servicio a la nube (Ruiz Aguilar, Entrevista del marco de
evaluación para la adopción de servicios en la nube en entidades públicas, 2020) .............................23
Figura 4. Dominios fundamentales para la implementación del nuevo marco (Ruiz Aguilar, Entrevista
del marco de evaluación para la adopción de servicios en la nube en entidades públicas, 2020). ......24
Figura 5. Estructura Organizacional de las Centrales Eléctricas de Nariño (CEDENAR, 2020). .............26
Figura 6. Metamodelo del nuevo marco metodológico para la adopción de servicios en la nube en
entidades públicas. ................................................................................................................................31
Figura 7. Modelo de la estructura del nuevo marco metodológico. .....................................................32
6
1. INTRODUCCIÓN El contexto contemporáneo de las Tecnologías de Información (TI) está cambiando velozmente, y es
que el surgimiento de nuevas herramientas tecnológicas capaces de satisfacer los múltiples
requerimientos empresariales. Entre estos requerimientos está ofrecer soluciones de TI para
posicionarse en el mercado, optimizar los procesos internos, reducir gastos tanto operativos como no
operativos y agilizar la operación general. Una de estas herramientas de tecnología es la computación
en la nube que, a pesar de ya llevar varios años en el mercado, sus servicios se siguen transformando
con el paso del tiempo para así ofrecer soluciones innovadoras y ajustadas a las necesidades de todos
los sectores de la industria. Estas soluciones consisten en ofrecer recursos, a través de Internet, de
hardware, software y de datos bajo un modelo de autoservicio por demanda, que además cuenta con
una rápida elasticidad y una medición de servicio.
Sin embargo, la migración de servicios a la nube no debe hacerse solamente considerando los
beneficios que esta tecnología trae, sino que también es necesario realizar un análisis de los factores
internos y externos a la organización que puedan alterar el correcto aprovisionamiento de la
computación en la nube. Por un lado, dentro de los factores internos están, por ejemplo, los riesgos
relacionados a la resistencia al cambio. Por otro lado, dentro de los factores externos se encuentran
problemas asociados al incumplimiento de acuerdos de nivel de servicio estipulados por parte del
proveedor de nube. Lo anterior, puede generar situaciones como inconvenientes legales o
incumplimiento de los objetivos de negocio de la organización.
Ahora bien, dentro del contexto del sector público colombiano, también se ha buscado adoptar la
computación en la nube como una solución tecnológica que apoye la operación de las empresas del
estado. De este modo, la situación en este sector es de particular interés porque, además de sus
políticas internas, estas empresas deben alinearse a la estrategia de gobierno en línea del Ministerio
de Tecnologías de Información y Comunicaciones (MinTIC). Esta estrategia, sugiere a las empresas
públicas considerar la opción de adoptar servicios en la nube antes de comprar infraestructura propia
(MinTIC, 2018), y cumplir con los lineamientos del marco de Arquitectura Empresarial (AE) que
contiene los lineamientos que un servicio de TI debe cumplir para asegurar la calidad del mismo
(MinTIC, 2019).
En este orden de ideas, es necesario disponer de una solución analítica que mida la factibilidad de
migrar un servicio de TI a la nube con el fin de aprovechar los beneficios, minimizar los riesgos y
garantizar el cumplimiento de los lineamientos tecnológicos definidos por el gobierno colombiano.
Ante esta situación, en el año 2016 el ingeniero John Jairo Ruiz Aguilar elaboró el “Marco para evaluar
la conveniencia de adoptar servicios en la nube en entidades públicas” (Ruiz Aguilar, 2016), cuyo
objetivo, como se define en el título del trabajo, consiste en diseñar un marco que evalúe la viabilidad
de adoptar servicios en la nube para entidades del sector público colombiano y que se articule con la
normativa propuesta por el Ministerio de las TICs.
No obstante, al ser una solución del año 2016, apoya su base conceptual sobre el contexto tecnológico
y empresarial de ese periodo. Adicionalmente, su contenido no logra abarcar la totalidad de las
normativas propuestas por el Gobierno en Línea (GEL), sino que se enfoca en trabajar en un único
dominio que se relaciona con la implementación de servicios tecnológicos. Estas dos situaciones,
hacen que el marco de Ruiz Aguilar (2016) requiera mejoras y complementos para que, de esta forma,
se logre estructurar una solución más completa y alineada con las normativas y estándares actuales.
De acuerdo con lo anterior, este proyecto busca responder la siguiente pregunta: ¿Qué elementos del
marco de evaluación para la adopción de servicios en la nube (Ruiz Aguilar, 2016) deben ser
7
modificados para mejorar los resultados que se obtienen al aplicarlo a las entidades del sector
público?
Para resolver este interrogante en esta tesis, en principio, se realiza un análisis de los lineamientos
actuales del marco de AE (MinTIC, 2019) y un estudio detallado de la estructura del “Marco para
evaluar la conveniencia de adoptar servicios en la nube en entidades públicas” (Ruiz Aguilar, 2016) con
el fin de entender los cimientos conceptuales de ambos trabajos. Después, se efectúa un análisis sobre
el contenido del marco de Ruiz (2016) que hace uso de dos metodologías: por un lado, la realización
de una entrevista a un experto para evaluar el nivel de utilidad de la solución en un escenario real; y
por otro lado, la aplicación del marco sobre una entidad del estado colombiano para que, a través de
la práctica, sea posible identificar los puntos de mejora potenciales. Enseguida, con las observaciones
adquiridas en el proceso de análisis, se plantea un rediseño del marco metodológico que incorpora las
correcciones definidas a partir del diagnóstico establecido. Por último, se realiza una segunda
aplicación con el nuevo marco para determinar los avances logrados con las modificaciones realizadas.
1.1 ORGANIZACIÓN DEL PROYECTO La presentación de la estructura de este proyecto de grado se define de la siguiente forma:
• Capítulo 2: en esta sección se describen los objetivos a cumplir dentro de este trabajo de
investigación.
• Capítulo 3: este capítulo contiene el marco teórico del proyecto, con el fin de conceptualizar
la temática abordada a lo largo del trabajo: computación en la nube, gobierno en línea y el
“Marco para evaluar la conveniencia de adoptar servicios en la nube en entidades públicas”
(Ruiz Aguilar, 2016).
• Capítulo 4: dentro de este apartado, se encuentra la evaluación del marco metodológico y el
diagnóstico del estado del mismo; esto, tras haber hecho el ejercicio de aplicarlo a una
empresa de carácter público y efectuado la entrevista a un experto en temas de computación
en la nube.
• Capítulo 5: en esta sección, se presenta el rediseño del marco de evaluación con respecto al
análisis efectuado del estado del marco metodológico.
• Capítulo 6: este capítulo hace referencia a la aplicación de la nueva versión del marco para
evaluar la viabilidad de adoptar servicio de nube.
• Capítulo 7: este último apartado presenta las conclusiones obtenidas de la realización del
proyecto de grado.
2. OBJETIVOS
2.1 OBJETIVO GENERAL Evaluar y mejorar la propuesta del “Marco para evaluar la conveniencia de adoptar servicios en la
nube en entidades públicas” (Ruiz Aguilar, 2016) para así poder diseñar una solución que resuelva las
falencias que éste presenta en la práctica real.
2.2 OBJETIVOS ESPECÍFICOS: • Profundizar el conocimiento sobre marco de evaluación para adoptar servicios en la nube en
entidades públicas (Ruiz Aguilar, 2016) por medio de una entrevista a un experto en el tema
en cuestión.
8
• Evaluar el marco metodológico para determinar la conveniencia de adoptar servicios en la
nube (2016) aplicándolo sobre un servicio de una entidad del sector público.
• Realizar un diagnóstico del estado actual del marco de evaluación para la adopción de
servicios en la nube (Ruiz Aguilar, 2016) con base en la entrevista y la aplicación realizada.
• Rediseñar la estructura del marco metodológico, corrigiendo los fallos identificados en el
diagnóstico.
• Modificar los criterios de evaluación con base en: (i) los lineamientos del “Marco de
Arquitectura Empresarial” (2019) propuesto por el MinTIC y (ii) los criterios del estado del arte
del “Marco para evaluar la conveniencia de adoptar servicios en la nube en entidades
públicas” (Ruiz Aguilar, 2016).
• Aplicar la nueva versión del marco para evaluar la viabilidad de adoptar servicios en la nube
sobre el mismo servicio de la empresa del sector público seleccionada previamente.
• Evaluar las diferencias (de estructura, contenido, usabilidad y resultados) del nuevo marco
para evaluar la conveniencia de adoptar servicios en la nube en entidades públicas, por medio
de un ejercicio comparativo, con respecto a su primera versión.
3. MARCO TEÓRICO
3.1 COMPUTACIÓN EN LA NUBE
3.1.1 ¿Qué es la computación en la nube?
La definición de computación en la nube ha sido descrita desde diferentes contextos temporales y
espaciales por parte de diversos autores. Por un lado, la empresa estadounidense Amazon define la
computación en la nube como el conjunto de recursos de TI por demanda, suministrados vía internet,
cuyo modelo de pagos se genera por consumo (Amazon, 2020). Por otro lado, IBM enuncia la nube
como la “oferta de servicios de computación bajo demanda” (IBM, 2019). Sin embargo, The National
Institute of Standards and Technology 1 (NIST), a través de sus integrantes Peter Mell y Timothy
Grance, ha logrado concretar una definición altamente integral, afirmando que:
La computación en la nube es un modelo para permitir el acceso de red ubicuo, conveniente y bajo
demanda a una red compartida de recursos informáticos (e.j redes, servidores, almacenamiento,
aplicaciones y servicios) que pueden ser rápidamente aprovisionados y liberados con el mínimo
esfuerzo de gestión o interacción del proveedor de servicios (Mell & Grance, 2011).
Como se observa, esta definición logra englobar las descripciones hechas por las dos entidades de
tecnología en cuanto al modelo de operación (bajo demanda). Además, es precisa al detallar algunos
de los recursos informáticos que son asequibles implementando este tipo de computación. Por último,
la definición de la NIST enuncia una premisa fundamental para la nube: una relación intensa con el
proveedor del servicio no es necesaria para que los servicios ofrecidos sean aprovisionados y
desplegados con rapidez.
1 La National Institute of Standards and Technology es una entidad encargada en la administración de tecnología del sector comercial de Estados Unidos. Entre sus objetivos primordiales destaca el intento por impulsar la innovación y la industria en Estados Unidos a través de normas y tecnología para que se logre una mayor estabilidad económica y se mejore la calidad de vida (Rouse, 2006).
9
Una vez definida la computación en la nube, en la tabla 1, se enuncian los principales modelos y
características de esta, según el marco de definición de la NIST (Mell & Grance, 2011). Estos
componentes serán explicados más adelante en el documento de la siguiente manera: la subsección
3.1.2 detalla las características esenciales de la computación en la nube, la subsección 3.1.3 presenta
los modelos de servicio de la computación en la nube y la subsección 3.1.4 define modelos de
despliegue de nube.
Marco de referencia de la computación en la nube de la NIST
Modelos de despliegue
Nube privada
Nube comunitaria Nube pública
Nube híbrida
Modelos de servicio Software as a Service (SaaS) Platform as a Service (PaaS)
Infrastructure as a Service (IaaS).
Características esenciales
Autoservicio por demanda
Amplio acceso a la red Multiusuario
Rápida elasticidad
Servicio medido Tabla 1. Marco de referencia de computación en la nube según la NIST (Mell & Grance, 2011).
3.1.2 ¿Cuáles son las características de tiene la computación en la nube?
Ahora bien, es necesario detallar las características con las que cuenta la computación en la nube para
que su entendimiento sea más preciso. Para ello, se abordarán las principales características con las
que cuenta la nube propuestos por el marco de referencia de la NIST, estos son (Mell & Grance, 2011):
a) Autoservicio por demanda: un consumidor puede hacer uso unilateral de las capacidades
informáticas, por ejemplo, el tiempo de uso de un servidor o el almacenamiento en red. Todo
esto, según sea necesario y de forma automática, es decir, sin necesidad de interacción humana
con el proveedor de servicios.
b) Amplio acceso a la red: una de las grandes ventajas que presenta este modelo, corresponde a la
facilidad de acceder a los servicios o aplicaciones que la nube provee; ya que para un interesado
será posible acceder a estos recursos a cualquier hora del día y desde cualquier lugar del mundo.
c) Multiusuario: esta característica se refiere al uso de recursos informáticos que el proveedor de
nube ofrece, los cuales pueden ser agrupados para servir múltiples consumidores. Estos recursos
pueden ser físicos o virtuales y son asignados de forma dinámica de acuerdo con la demanda del
consumidor. En palabras más concisas, los recursos que no son utilizados por un usuario pueden
ser usados por otros (esto se logra a través de una infraestructura abstracta).
d) Rápida elasticidad: al aplicar tecnologías de ‘Cloud Computing’, cambia la necesidad de adquirir
recursos excesivos de infraestructura tecnológica con antelación con el fin de gestionar niveles
pico de actividad comercial a futuro. En lugar de ello, se provee recursos más precisos según la
necesidad de la empresa. En otras palabras, se puede ajustar la escala de uso de estos recursos
de forma que se aumente o disminuya la capacidad en el momento que cambien las necesidades
de negocio.
e) Servicio medido: al adoptar servicios de informática en la nube, el uso del servicio puede ser
medido según diferentes tipos de métricas, tales como: almacenamiento, procesamiento, ancho
de banda y número de usuarios activos.
10
3.1.3 ¿Qué modelos de servicios en la nube existen?
Hasta el día de hoy, se han creado tres principales modelos que son implementados por los clientes
dependiendo a las necesidades que estos presentan. En seguida se presentan los modelos de
computación en la nube existentes (Mell & Grance, 2011):
• ‘Infrastructure as a Service’ (IaaS): en este modelo, al cliente se le proveen servicios de
almacenamiento, procesamiento y red donde el consumidor puede correr y desplegar
productos de software como sistemas operativos o aplicaciones. Un punto importante para
aclarar en este modelo es que el consumidor no tiene control sobre la infraestructura como
tal, pero sí tiene control sobre el sistema operativo, el almacenamiento y el despliegue de las
aplicaciones. Asimismo, el usuario final tiene cierto control sobre algunos componentes de
red (como escoger el firewall que desea usar). Ahora, se describirán las funciones de un IaaS
por Salinas Montemayor (2015):
o Al contratar este modelo de servicio, se crea la capacidad de escalar las necesidades
de infraestructura, tales como recursos de procesamiento, almacenamiento y
memoria principal según lo requiera el usuario.
o Este modelo trae consigo la ventaja de adquirir capacidades computacionales en un
punto temporal específico.
• ‘Platform as a Service’ (PaaS): al elegir este modelo de servicio, se provee una plataforma de
desarrollo y bases de datos para que los clientes puedan implementar soluciones de software,
ejecutar pruebas y gestionar información. A continuación, se mencionarán los elementos
mínimos que debe asegurar una PaaS como servicio de computación en la nube según Salinas
Montemayor (2015):
o Una solución de PaaS debe de poderse integrar con otros servicios de web externos y
con bases de datos.
o Una solución de PaaS debe suministrar una vigilancia global de la aplicación y la
actividad de los usuarios, de modo que sirva de apoyo a los desarrolladores para
entender mejor sus aplicaciones y las mejoras que deban hacerle.
o El proveedor de PaaS debe garantizar al cliente apoyo formal y colaboración bajo
demanda en todo el ciclo de vida del desarrollo de la solución (desarrollo,
documentación, pruebas y puesta en producción) manteniendo seguro el código
fuente y la propiedad intelectual de los asociados.
• ‘Software as a Service’ (SaaS): En este último modelo se le provee una aplicación al cliente
que ya está corriendo sobre la infraestructura subyacente de nube. El cliente puede acceder
a esta aplicación desde una interfaz como el navegador web o un programa de despliegue.
Este modelo trae la ventaja de que el consumidor ya no se preocupa por cómo mantener el
servicio o cómo gestionar la infraestructura subyacente, sino que solo debe entender cómo
manipular la aplicación de SaaS. Seguido de esto, se presentarán los beneficios que describe
Salinas Montemayor (2015) del uso de este modelo:
o Los servicios y aplicaciones que se contratan con el modelo SaaS son gestionados por
un tercero (proveedor de servicios o software). De esta forma, se puede reducir costos
de licencias de software, servidores u otro tipo de infraestructuras requeridas para el
funcionamiento del sistema. Adicional a esto, también logra reducir otros costos de
personal; destinados al alojamiento de las aplicaciones.
11
o Con el uso de SaaS, el uso del software contratado puede ser controlado por los
proveedores de nube. También, estos proveedores, impiden la copia y distribución
del producto y facilitan el control de las versiones que se deriven de su software.
o Las aplicaciones SaaS son accedidas desde un navegador web (pues estas no
requieren un hardware específico para emplearse). Teniendo en cuenta esto, el
software de una SaaS proporciona una interfaz estandarizada con el fin de facilitarle
a sus usuarios el manejo de sus aplicaciones.
o El proveedor de una aplicación de SaaS puede brindar soporte con respecto a los
problemas que presente el usuario final. Además, una aplicación SaaS puede ser
parametrizada de modo que satisfaga las necesidades del negocio al que le brindan
servicios. Si bien, esta no permite una totalidad de su personalización.
3.1.4 ¿Qué modelos de despliegue existen en la computación en la nube?
La computación en la nube puede operar bajo despliegues diferentes, cada uno con características y
beneficios específicos. Para la definición de estos, se hará alusión nuevamente al marco de referencia
propuesto por la NIST (Mell & Grance, 2011).
• Nube privada: este modelo hace referencia a la utilización virtualizada de los recursos en la
nube por parte de organizaciones de forma exclusiva. Además, para este tipo de despliegue
se resalta una alta garantía en seguridad (al no compartir datos ni aplicaciones con usuarios
externos) y una relevante integración con la infraestructura actual de la empresa ya que, al
ser exclusivo, se implementa con base en el estado actual de la entidad. Sin embargo, el
modelo también se caracteriza por sus costos altos ya que requiere la realización de
inversiones para adquirir los servicios (CAPEX) y, durante la operación, costos para poder
gestionar este modelo de despliegue (OPEX).
• Nube de comunidad: en este modelo, el servicio de nube se provee de forma exclusiva para
una “comunidad de consumidores”; es decir, un grupo en el que se encuentran varias
organizaciones que comparten algunos intereses como la visión de la empresa, la misión de
la empresa, entre otras. En este caso, la nube pude ser posesionada gestionada y operada por
una o más organizaciones pertenecientes a la “comunidad de consumidores”, un tercero o
ambos. Este servicio se encuentra ‘OnPremise’ u ‘OffPremise’.
• Nube pública: este modelo de despliegue, la infraestructura de nube se dispone para el libre
uso del público en general. Este tipo de nube es gestionado, generalmente, por entidades
gubernamentales o instituciones académicas.
• Nube híbrida: el último modelo, es la composición de dos o más modelos de despliegue (nube
privada, nube de comunidad o nube pública). Esto se debe a que, en este modelo de
despliegue, cada nube se presenta como una entidad única que conserva sus propiedades,
pero está vinculada con las demás entidades que componen la nube híbrida por tecnologías
estandarizadas, para así garantizar la portabilidad de los datos y aplicaciones.
3.1.5 Inhibidores de la informática en la nube
Hasta el momento, en este documento se ha mencionado a las características positivas de la
computación en la nube. No obstante, la informática en la nube (al igual que otros sistemas de
información empresariales) trae consigo diversos riesgos, tales como (Rountree & Castrillo, 2013):
• Ambigüedad: no se cuenta la información clara acerca de todos los servicios que la nube
ofrece. Pues, se suele presentar dudas constantes con respecto al incremento de costos, falta
de control de los datos o problemas de integración y seguridad del servicio.
12
• Dudas con respecto a la madurez de la computación en la nube: los servicios ofrecidos no
cuentan con un alto nivel de robustez, ya que no cuentan con las necesidades específicas de
algunos clientes. Además, no todos los proveedores de nube pueden cumplir los acuerdos de
nivel de servicio establecidos al cliente.
• Integración: al migrar servicios a la nube, es necesario buscar mecanismos para la integración
de datos en el ambiente local y los datos en la nube.
• Seguridad: al adoptar servicios de computación en la nube, se pierde el control total de los
datos y el sistema.
3.2 GOBIERNO EN LÍNEA Este ítem, se aborda en el contexto colombiano. Ahora bien, en este ámbito, se mencionará el objetivo
propuesto por el Ministerio de Tecnología y las Comunicaciones (MinTIC), donde señala la importancia
de “Contribuir con la construcción de un Estado más eficiente, más transparente y participativo, y que
preste mejores servicios a los ciudadanos y a las empresas, a través del aprovechamiento de las
Tecnologías de la Información y la Comunicación” (MinTIC, 2018). Por consiguiente, el mismo MinTIC
propuso un marco de referencia de Arquitectura Empresarial (AE) para asegurar el cumplimiento del
objetivo ya mencionado. Este marco de referencia actualizado está estructurado en los siguientes
componentes (MinTIC, 2019):
• Principio: se define como una regla de alto nivel, la cual direcciona los lineamientos del marco
actual de AE y se deben de tener en cuenta en la toma de decisiones durante la ejecución de
los ejercicios definidos en el respectivo ‘Framework’. Entre estos principios están: Excelencia
del servicio ciudadano, Costo/Beneficio, Racionalización, Estandarización, Interoperabilidad,
Co-Creación, Calidad, Seguridad Digital, Sostenibilidad, Neutralidad tecnológica, Foco en las
necesidades y Vigilancia tecnológica.
• Dominio: son las dimensiones con las que se abordan las actividades propuestas de
arquitectura empresarial y se constituyen en los principales componentes del marco de
referencia de AE. Ahora, se describen los dominios que agrupan los lineamientos del marco
de AE:
o Planeación de la arquitectura: este dominio, contiene los elementos cuyo fin es
orientar las entidades estatales en la planeación, estructuración y priorización de los
ejercicios de AE, partiendo de las necesidades de negocio.
o Arquitectura misional: los componentes de este dominio se encargan de orientar a
las entidades en la definición de la arquitectura misional o del negocio, con base en la
documentación del modelo de intención y el modelo operativo de la entidad e
identificación.
o Arquitectura de información: los elementos que contiene este dominio buscan
orientar a las entidades públicas en la definición de la arquitectura de información
que precisa la estructura con la cual se representan y almacenan los datos y la
información de una organización; del mismo modo, establece los servicios y los flujos
de información que soportan los procesos de la empresa de la arquitectura misional.
o Arquitectura de sistemas de información: este dominio contiene elementos cuya
finalidad es orientar a las entidades en la definición de la arquitectura de aplicaciones
que especifica los componentes de los sistemas, sus interacciones, la relación con la
arquitectura misional, de información e infraestructura de TI.
o Arquitectura de infraestructura tecnológica: en este dominio, se agrupan elementos
que orienten a las entidades en la descripción de la arquitectura de infraestructura de
13
TI, la cual define todos los elementos de la infraestructura de TI que soporta la
operación de la institución.
o Arquitectura de seguridad: dentro de este dominio se encuentran los criterios que
orientan a las empresas con la orientación y diseño de las regulaciones necesarias que
garanticen la protección de la información en la arquitectura misional tanto de
información, de sistemas de información como de infraestructura tecnológica.
o Uso y apropiación de la arquitectura: este dominio contiene los componentes que
orientan a las entidades en la gestión de cambio y de grupos de interés. De este modo,
se busca desarrollar ciertos comportamientos culturales que faciliten la adopción y
utilización de las arquitecturas objetivo ya definidas. Asimismo, dentro de este
dominio, se construye la capacidad de la arquitectura empresarial de la organización;
puesto que esta capacidad es fundamental en la implementación del modelo de AE.
• Lineamiento: hace referencia a orientaciones de carácter general, correspondiente a una
disposición o directriz que debe ser ejecutada por la entidad estatal de modo que se pueda
emplear correctamente el ‘Framework’ de AE.
• Guías: estas son herramientas metodológicas que determinan, mediante actividades, los
pasos que se deben seguir para cumplir ciertos lineamientos del marco de referencia de AE.
• Evidencias: muestran los resultados obtenidos de las actividades realizadas con respecto a
uno o varios lineamientos del ‘Framework’ de AE.
• Proceso de arquitectura: estos procesos puntualizan las actividades necesarias para definir la
arquitectura empresarial objetivo de una organización estatal.
• Ejercicio de AE: dentro de este contexto, los ejercicios buscan definir la situación objetivo de
una entidad especificando el alcance y las necesidades claras que se han de solucionar. Estos
ejercicios operan de forma iterativa.
• Repositorio de AE: este repositorio, tiene como principal funcionalidad gestionar la
arquitectura y generar vistas de los componentes de la AE.
Adicionalmente, en el documento del marco de referencia se identifican aspectos para tener en
cuenta para una correcta aplicación de este ‘Framework’. Estos son (MinTIC, 2019):
• Estándares: las guías de los lineamientos definen ciertos estándares de la industria que
manejan temas específicos de AE.
• Mejores prácticas: en la industria se definen mejores prácticas que precisan asuntos
metodológicos y técnicos que facilitan la implementación del ‘Framework’ de Arquitectura
Empresarial.
• Herramientas: son instrumentos tecnológicos que permiten, a las empresas del sector
público, realizar acciones especificadas. Estas, se asocian a las definiciones dadas por el
modelo de Arquitectura Empresarial; más específicamente, se vinculan a un lineamiento o
una guía. Estas herramientas son escogidas de modo que se acoplen a las mejores prácticas
de la industria en temas que se traten en Arquitectura Empresarial.
Una vez mencionados los componentes de la estructura del modelo del marco de referencia de
Arquitectura Empresarial del MinTIC, se hará una representación gráfica de un metamodelo de esta
estructura para tener una mejor visualización del modelo. Esta representación, se muestra en la figura
1 en seguida:
14
Figura 1. Metamodelo del Marco de Referencia de Arquitectura Empresarial del MinTIC (MinTIC, 2019).
No obstante, este marco de referencia resulta muy complejo de implementar en las organizaciones.
Esto se debe, a que las guías de cómo aplicar los lineamientos no son claras; falta especificar una
metodología que asesore a estas entidades en los procesos definidos para cumplir debidamente con
los lineamientos propuestos en este marco de referencia.
3.3 MARCO PARA EVALUAR LA CONVENIENCIA DE ADOPTAR SERVICIOS EN LA NUBE EN
ENTIDADES PÚBLICAS Dentro del contexto del sector público colombiano, el Ministerio de Tecnología y Comunicaciones
planteó una estrategia de gobierno en línea; parte de esta, consiste en que las entidades estatales del
país deben evaluar la opción de adquirir servicios de TI en la nube, antes que implementar estos
mismos servicios ‘On-Premise’. No obstante, las organizaciones del Estado colombiano, aun
tercerizando la operación de sus servicios de TI, no están eximidas de cumplir con los lineamientos del
marco de referencia de Arquitectura Empresarial (descrito en la sección anterior de Gobierno en línea)
propuesto por el mismo MinTIC. De este modo, resulta bastante complejo para las entidades del
sector evaluar la posibilidad de adoptar servicios en la nube cumpliendo con el marco de referencia
de AE propuesto por el MinTIC; pues estos lineamientos presentan un bajo nivel de detalle. Por ende,
se diseñó un marco de referencia de adopción de servicios de nube, llamado “Marco para evaluar la
conveniencia de adoptar servicios en la nube en entidades públicas” elaborado por Ruiz Aguilar (2016)
en su proyecto de grado de maestría.
Ahora, entrando más a fondo al marco de evaluación para adquirir servicios en la nube, se revisa la
forma en la cual fue elaborado este marco metodológico. Por un lado, el autor elaboró un estado del
arte acorde a la literatura existente; este estado del arte le permitió extraer los principales elementos
15
de evaluación de factibilidad de adquisición de servicios en la nube planteados en las publicaciones de
investigación relacionadas con el tema (Ruiz Aguilar, 2016). El análisis contempló tres grandes
categorías (Contexto, Aspectos de evaluación y Método de Evaluación) cada una de ellas con sus
respectivos criterios. Con esto, el trabajo de investigación pudo realizar una mejor selección de
fuentes que abarquen la temática de computación en la nube en entidades públicas. En este orden de
ideas, se construyó un modelo de evaluación de las investigaciones. A continuación, se presenta la
tabla 2 donde se muestra el modelo de trabajo del estado del arte (Ruiz Aguilar, 2016):
Elementos de evaluación Categoría Criterio Pregunta
Contexto Dominio ¿A qué sector se aplica el trabajo de investigación analizado?
Meta ¿Qué busca el trabajo de investigación?
Alcance ¿Qué aplicación actual y/o potencial tiene dentro del sector identificado anteriormente y en otros sectores?
Aspectos de evaluación
Financiero ¿Se evalúa la factibilidad económica de adoptar servicios en la nube?
Otros ¿Qué otros aspectos tienen en cuenta en el trabajo de investigación?
Método de evaluación
Método de evaluación ¿Cómo se evalúan los aspectos previamente identificados?
Unidades de medición ¿Cuál es la unidad de medida utilizada para cada aspecto? Tabla 2. Elementos de evaluación (Ruiz Aguilar, 2016).
Con este modelo de criterios, el autor prosiguió a la recolección y evaluación del material a investigar.
Este decidió utilizar la base de datos Scopus, con el fin de encontrar trabajos que concordaran con las
preguntas previamente enunciadas (tabla 2). Para la realización de la búsqueda, se especificaron los
siguientes parámetros:
• Términos de búsqueda: Assessment or Evaluation or Evaluating) and (Methodology or
Framework or Model) and Adoption and (Saas or Paas or Iaas or Cloud) and (Public sector or
Government or Public institution or E-government).
• Área de búsqueda: ‘Computer Science’
• Tipo de documento: ‘Conference paper or Journal paper’
• Tipo de campo de búsqueda: ‘Abstract, title and keywords’
• Idioma: inglés
Habiendo especificado los criterios de evaluación de los informes, el motor de búsqueda retornó un
total de 48 artículos candidatos que, después de aplicar otros filtros de selección, se limitó a 10
artículos con los cuales se trabajó para elaborar el marco de evaluación. Seguido de esto, Ruiz Aguilar
(2016) prosiguió a realizar un compendio de cada artículo obtenido del motor de búsqueda.
Finalmente, para concretar el estado del arte, se elaboró el informe. En este, Ruiz Aguilar (2016)
sintetizó los resultados de la búsqueda de artículos en un formato de doble entrada; en la primera
tabla se presentaba el contexto de la fuente, en la segunda tabla los aspectos de evaluación y en la
tercera tabla los métodos de evaluación, sacando una conclusión de cada criterio. Además de
presentar en tablas el contenido sintetizado de las fuentes de información, también se respondían las
preguntas propuestas de cada criterio de evaluación.
Después de haber realizado el estado del arte, las conclusiones que obtuvo el autor fueron las
siguientes (Ruiz Aguilar, 2016):
16
• Según el análisis del contexto, para el sector público la evaluación e identificación de los
servicios de ‘Cloud’ están enfocados en el modelo SaaS, mientras que para el sector privado
se enfocan en los modelos IaaS y PaaS.
• De acuerdo con los “aspectos de evaluación”, la factibilidad económica para la
implementación de servicios en la nube se hace a través de la disminución de costos de
infraestructura y mantenimiento. Además de esto, con la elaboración del estado del arte del
proyecto, se identificaron otros cuatro grupos de aspectos de evaluación: aspectos
socioculturales, aspectos tecnológicos y de seguridad, aspectos de percepción del usuario
hacia el entorno, y aspectos políticos y legales.
• Acorde con los “métodos de evaluación”, en los informes de investigación se pudo identificar
la presencia de ciertos marcos metodológicos para la adopción de tecnologías en la nube. No
obstante, el número de trabajos que tenían definidas las unidades de medición, para los
aspectos de evaluación identificados, era limitada.
• No se determinaron aspectos de evaluación claros para el contexto del sector público
colombiano, que además deben estar relacionados con la estrategia de gobierno en línea.
Por otro lado, en el trabajo de investigación se realizó un ejercicio de análisis de los lineamientos
propuestos por el MinTIC en el marco de evaluación de AE. Si bien, antes de explicar cómo Ruiz Aguilar
(2016) utilizó este marco de base, cabe aclarar que este hizo uso de una versión anterior de este
documento; la versión del 2016 donde hizo el marco de evaluación de servicios en la nube. Pasando a
la elaboración del marco de evaluación, el autor decidió enfocarse en uno de los dominios propuestos:
el dominio de “Servicios tecnológicos” propuesto en esa versión del marco de referencia del MinTIC.
Sobre este dominio, el autor definió ciertos grupos que reúnen los lineamientos respectivos (Ruiz
Aguilar, 2016). Estos grupos, con sus respectivos lineamientos, son:
• Arquitectura de los servicios tecnológicos
- (LI.ST.01) Directorio de servicios tecnológicos.
- (LI.ST.02) Elementos para el intercambio de información.
- (LI.ST.03) Gestión de los servicios tecnológicos.
- (LI.ST.04) Acceso a servicios en la nube.
- (LI.ST.16) Tecnología verde.
• Operación de servicios tecnológicos
- (LI.ST.05) Continuidad y disponibilidad de los servicios tecnológicos.
- (LI.ST.06) Alta disponibilidad de los servicios tecnológicos.
- (LI.ST.07) Capacidad de los servicios tecnológicos.
• Soporte de los servicios tecnológicos
- (LI.ST.08) Acuerdos de Nivel de Servicios.
- (LI.ST.09) Mesa de servicio.
- (LI.ST.10) Planes de mantenimiento.
• Gestión de la calidad y seguridad de los servicios tecnológicos
- (LI.ST.11) Control de consumo de los recursos compartidos por Servicios tecnológicos.
- (LI.ST.12) Gestión preventiva de los servicios tecnológicos.
- (LI.ST.13) Respaldo y recuperación de los servicios tecnológicos.
- (LI.ST.14) Análisis de vulnerabilidades.
- (LI.ST.15) Monitoreo de la seguridad de infraestructura tecnológica.
Seguido de haber identificado los grupos, Ruiz Aguilar (2016) siguió una metodología de análisis e
interpretación de los lineamientos de la estrategia de gobierno en línea (Ruiz Aguilar, 2016). Esta
metodología se muestra a continuación:
17
1) Presentación del lineamiento de GEL: La presentación se hace a partir de la definición del
lineamiento hecha por MinTIC en el marco de arquitectura TI de Gobierno en Línea.
2) Interpretación del lineamiento de GEL: Se explica el lineamiento en el contexto de
contratación de servicios en la nube. Para ello, se utilizan como base del análisis los elementos
conceptuales provistos en las mejores prácticas de ITIL.
3) Definición de los criterios de evaluación para el seguimiento del lineamiento: Conforme a la
interpretación del lineamiento se identifican y se definen los criterios de evaluación para
asegurar el cumplimiento del lineamiento a la hora de contratar un servicio en la nube con un
proveedor externo. Estos criterios se clasifican en: (i) Criterios que aplican a la dirección o área
de TI de la entidad pública como cliente; (ii) criterios para el proveedor del servicio de TI que
quiere ser contratado.
4) Relacionamiento con trabajos de investigación del estado del arte: De acuerdo con los
criterios de evaluación establecidos en el punto anterior, se examina si existe algún trabajo de
investigación (del estado del arte, ver capítulo 2) que tenga aspectos de evaluación similares
o relacionados a los criterios de evaluación del lineamiento. Lo anterior, con la finalidad de
identificar qué aspectos de evaluación del estado del arte -que son importantes para evaluar
la conveniencia de adoptar un servicio en la nube- no son cubiertos por los criterios descritos
a partir de la interpretación de los 20 lineamientos. Los trabajos de investigación del estado
del arte son enumerados y referenciados con el nombre de los autores.
5) Análisis del nivel de cubrimiento de los criterios de evaluación: Para los lineamientos para
los cuales existen trabajos de investigación con aspectos de evaluación similares, se procede
a analizar el nivel de cubrimiento por parte de los trabajos de investigación. Este análisis se
realiza de acuerdo con una matriz de nivel de cubrimiento de los criterios de evaluación.
Teniendo definida la metodología de implementación, aplicó una medición del nivel de cubrimiento
para cada lineamiento. En resultado de esto, el autor hizo una integración del análisis del estado del
arte y la estrategia de gobierno en línea para obtener de ellos los aspectos de evaluación y los criterios
de evaluación respectivamente.
Una vez concluyendo el estado del arte y analizado el marco de referencia de AE, Ruiz Aguilar (2016)
planteó la estructura de su marco de evaluación de la adopción de servicios con tecnologías ‘Cloud’.
En seguida se mencionará la estructura del marco de referencia hecho por John Jairo Ruiz (Ruiz Aguilar,
2016):
• Categoría de evaluación: este es el primer aspecto de la estructura, en el cual se determinan
las diferentes categorías donde se encuentran catalogados los lineamientos con respecto al
‘Framework’ de Arquitectura Empresarial. Estas categorías y sus respectos IDs son: (Cat_1)
Arquitectura de servicios de negocio, (Cat_2) Operación de servicios tecnológicos, (Cat_3)
Soporte de los servicios tecnológicos, (Cat_4) Gestión de la calidad y seguridad de los servicios
tecnológicos, (Cat_5) Entorno legal, (Cat_6) Entorno financiero.
• Actor: el siguiente factor, dentro de la estructura del ‘Framework’, corresponde al actor
envuelto en la evaluación de adopción de servicios en ‘Cloud’. En el estudio realizado se
identificaron dos actores principales: directivos de TI de la entidad estatal (cliente) y el
proveedor de TI.
• Criterios de evaluación: estos criterios son pertenecientes a las categorías de evaluación
previamente propuestas. Estos criterios son descritos en los lineamientos de gobierno en línea
y el análisis de aspectos de evaluación del estado del arte (del proyecto de John Jairo Ruiz).
• Subcriterio de evaluación: por cada criterio se pueden definir hasta dos subcriterios que estos
son: (i) el nivel de cubrimiento de las actividades clave de los procesos descritos en el
18
lineamiento del GEL (ver tabla 3), (ii) la madurez de los procesos descritos en el respectivo
lineamiento del GEL según el modelo de capacidad y madurez (ver tabla 4) y (iii) la viabilidad
financiera que conlleva el proyecto (ver tabla 5).
• Valores posibles: por cada subcriterio de evaluación, se le debe asignar un valor. En ambos
casos se le otorga al subcriterio un valor de 0 a 100 para determinar el nivel de madurez y
cubrimiento del subcriterio. En seguida, se presentan las tablas de valores, que puede tomar
cada subcriterio (Ruiz Aguilar, 2016):
Valores posibles para el subcriterio: nivel de cubrimiento de las actividades
Nivel de cubrimiento de actividades
Fórmula Puntuación
Sin cubrimiento (#ActividadesCubiertas/#TotalActividades) = 0% 0
Bajo cubrimiento 0% < (#ActividadesCubiertas/#TotalActividades) <= 50%
25
Parcialmente cubierto
50% < (#ActividadesCubiertas/#TotalActividades) < 80%
50
Altamente cubierto 80% <= (#ActividadesCubiertas/#TotalActividades) < 100%
75
Cubierto (#ActividadesCubiertas/#TotalActividades) = 100% 100 Tabla 3. Valores posibles del subcriterio nivel de cubrimiento (Ruiz Aguilar, 2016).
Valores posibles para el subcriterio: nivel de madurez del proceso Nivel de madurez del proceso
Descripción Puntuación
Nivel 0: proceso incompleto
El proceso no se ha implementado o no cumple con alcanzar su propósito
0
Nivel 1: proceso ejecutado
El proceso es implementado y alcanza su propósito 20
Nivel 2: proceso gestionado
El proceso es gestionado y los productos de trabajo son establecidos, controlados y mantenidos.
40
Nivel 3: proceso establecido
Se utiliza un proceso definido, basado en un estándar del proceso
60
Nivel 4: proceso predecible
El proceso es establecido consistentemente con los limites definidos
80
Nivel 5: proceso optimizado
El proceso se mejora continuamente para satisfacer las metas de negocio actuales, relevantes y proyectadas
100
Tabla 4. Valores posibles para el subcriterio de nivel de madurez del proceso (Ruiz Aguilar, 2016).
Valores posibles para el subcriterio: nivel de factibilidad financiera
Nivel de factibilidad financiera Fórmula Puntuación No factible (((CSN * 100)/PACI) – 100) < 0% 0
Factibilidad baja (((CSN * 100)/PACI) – 100) <= 10% 33
Factibilidad alta (((CSN * 100)/PACI) – 100) <= 20% 66 Factible (((CSN * 100)/PACI) – 100) > 20% 100 Tabla 5. Valores posibles para el subcriterio de nivel de factibilidad financiera (Ruiz Aguilar, 2016).
Donde:
• CSN: Costo de contratación de servicio en la nube
• PACI: Presupuesto asignado para compra de infraestructura
19
Ahora, teniendo descrita la estructura, se hará una representación gráfica del metamodelo del marco
de evaluación para adoptar servicios en la nube hecho por John Jairo Ruiz (2016), que se muestra en
seguida en la figura 2:
Figura 2. Metamodelo del Marco de evaluación para adoptar servicios en la nube (Ruiz Aguilar, 2016)
Para finalizar, se proporcionará un ejemplo de la aplicación del marco de evaluación para adoptar
servicios en la nube diseñado por Ruiz Aguilar (2016). Para ello, se hará con base al caso de aplicación
que realizó el autor en el Banco de la República de Colombia; el servicio de Portal Web, en el que se
presenta la información cultural y de interés tanto para personas naturales como jurídicas, es el que se
evaluó en ese caso de aplicación (Ruiz Aguilar, 2016):
• Ejemplo aplicación categoría 1: Cat_1. Arquitectura de servicios tecnológicos:
o Se ejemplificará las actividades identificadas que se relacionan con el lineamiento
LI.ST.01 “Directorio de servicios tecnológicos del primer grupo de las categorías de
evaluación”.
Proceso Actividades identificadas
Proceso de Gestión del Catálogo
➢ Ofrecer información del servicio de cloud a otros procesos (tales como gestión de proveedores).
➢ Mantener actualizada la información del servicio (e.j el vínculo y dependencia entre otros procesos de negocio y el servicio de TI).
➢ Exponer el servicio a los clientes internos para que estos puedan solicitarlo y consumirlo.
Proceso de gestión de portafolio
➢ Gestionar el ciclo de vida de los servicios que presta el cliente.
Tabla 6. Actividades pertenecientes al lineamiento: LI.ST.01. Directorio de servicios tecnológicos (Ruiz Aguilar, 2016).
Como se pudo observar en la tabla 6, para el lineamiento de “Directorio de servicios
tecnológicos” se identificaron tres actividades totales para el primer proceso y una
actividad para el segundo proceso. Ahora bien, a partir de los procesos descritos en la
tabla 6, evaluar cuantas de las actividades están cubiertas y darle el puntaje
correspondiente según la tabla 3 y el nivel de madurez del proceso y darle el puntaje
20
respectivo según la tabla 4 (cabe aclarar que el nivel de cubrimiento y madurez del
proceso lo determina la empresa a la que se aplica el marco de referencia). Por último,
en el proceso de evaluación del criterio, se promedian los dos puntajes de cada
subcriterio y se obtiene el puntaje global del criterio. A continuación, se ejemplificará la
obtención del puntaje posible en la tabla 7:
Actor Criterio de
evaluación Subcriterio 1: % de cubrimiento de actividades Subcriterio 2: Nivel de madurez del
proceso
Total de actividades
Actividades cubiertas
% de cubrimiento de actividades
Puntos obtenidos
Nivel de madurez del proceso
Puntos obtenidos
Puntaje total del criterio de evaluación
Dirección de TI
Cri_1.1 La Dirección de TI cuenta con un proceso de gestión del catálogo
3 3 100 100 Nivel 4: proceso predecible
80 90
Proveedor de TI
Cri_1.2 El proveedor de TI cuenta con proceso de gestión del portafolio de servicios tecnológicos
1 1 100 100 Nivel 4: Proceso predecible
80 90
Tabla 7. Ejemplo de aplicación de los criterios pertenecientes a la categoría Cat_1. Arquitectura de Servicios tecnológicos (Ruiz Aguilar, 2016)
Este proceso se debe realizar con todos los criterios descritos del marco de evaluación
de adopción de servicios en la nube para las empresas de carácter público. Para ver a
mayor detalle este ejemplo, revisar el proyecto de grado de Ruiz (2016) “Marco para
evaluar la conveniencia de adoptar servicios en la nube en entidades públicas” capítulo
“5.3. Aplicación del marco de evaluación sobre el servicio de TI” (Ruiz Aguilar, 2016, págs.
47 - 55). Finalmente, se promedian los puntajes globales de todos los criterios y así se
obtiene el puntaje total del análisis de viabilidad de adquirir servicios en la nube. En este
caso de aplicación, el puntaje global del análisis fue de 79 puntos a lo que el autor logró
concluir que: con respecto al nivel de madurez general de los procesos evaluados, que
fue medio-alto, en los que se tiene la gestión y el soporte del servicio como actividades
clave. Por tanto, junto con el nivel de factibilidad financiera que fue positivo, se aprueba
la evaluación de adquisición de servicios de ‘Cloud’ para el servicio de Portal Web del
Banco de la República de Colombia (Ruiz Aguilar, 2016).
4. EVALUACIÓN Y DIAGNÓSTICO DEL MARCO PARA ADOPTAR SERVICIOS EN LA
NUBE EN ENTIDADES PÚBLICAS El objetivo de esta sección es analizar el estado actual del marco de evaluación para evaluar la
conveniencia de adoptar servicios en la nube en entidades públicas e identificar los diferentes
aspectos que requieran de una modificación.
4.1 ENTREVISTA PARA EL ANÁLISIS DEL MARCO METODOLÓGICO La primera actividad que se realizó fue una entrevista a John Jairo Ruiz, el diseñador de la primera
versión del marco de evaluación para evaluar la conveniencia de adoptar servicios en la nube en
21
entidades públicas. Esto con el fin de conocer a través de su experiencia cómo fue la aplicación del
marco y que aspectos relevantes considera el entrevistado acerca de ese trabajo.
4.1.1 Modelo de preguntas:
En la tabla 8 se muestra el modelo de preguntas utilizado para la entrevista:
Modelo de preguntas sobre el marco de referencia
Sección Preguntas Objetivo de la sección
Conceptos generales sobre migración de servicios a la
nube
¿Cuáles son las complicaciones más comunes a la hora de migrar un servicio a la nube?
La intención de estas preguntas consistió en que, a partir de la experiencia propia laboral o académica propia del entrevistado, se lograra comprender cuales son los retos de la migración de servicios y de qué manera se puede implementar.
¿Cuánto tiempo puede tomar una decisión de migrar un servicio a la nube?, de ese tiempo ¿Cuánto se tarda en el análisis de viabilidad?
Indagación sobre el marco de referencia
¿Considera que las 6 categorías presentadas son suficientes para una adecuada
implementación del marco? A partir del conocimiento del marco de referencia existente, se plantea una evaluación sobre sus componentes y la viabilidad que tienen los mismos dentro del contexto actual
¿Considera usted que se debe evaluar algún factor más, diferente del cubrimiento, la
madurez y la factibilidad financiera?
Reflexiones y recomendaciones para el
trabajo futuro
¿Qué nos recomendaría para lograr optimizar correctamente el marco de referencia?
Una vez se trataron los elementos del marco actual que cuentan con fallas, en esta sección se le pide al entrevistado sugerir recomendaciones en términos de metodologías o estudios particulares que permitan optimizar correctamente el marco.
Tabla 8. Modelo de preguntas usadas en la entrevista.
4.1.2 Dinámica de la entrevista:
La entrevista tuvo lugar el día 24 de febrero de 2020 a través de una llamada telefónica. El entrevistado
fue John Jairo Ruiz, el creador del marco de referencia para la migración de servicios a la nube en el
sector público. El contenido completo de esta charla se plantea como un anexo de este documento.
4.1.3 Análisis y evaluación de las respuestas:
Para un entendimiento ideal de lo dicho por John Ruiz, se trabajará sobre cada pregunta y los puntos
relevantes de la respuesta correspondiente dada por el entrevistado. Adicionalmente, se planteará un
análisis sobre dichas respuestas para que sean estos estudios los que empiecen a esbozar las bases
del nuevo marco de evaluación.
❖ ¿Cuáles son las dificultades más comunes a la hora de migrar un servicio a la nube?
a) Puntos relevantes:
• Uno de los principales inconvenientes encontrados en la migración de un servicio
en la nube corresponde al manejo de datos. Dentro de esta práctica se resalta
particularmente la seguridad y almacenamiento de la información; además del
gobierno de datos
• Otro factor determinante que obstaculiza la migración corresponde a la
resistencia al cambio por parte de las entidades.
22
• Un último ítem hace referencia al tema de presupuestos, ¿Cuándo la nube pasa a
ser una inversión y de qué manera puede recibir esta financiación por parte del
estado?
b) Análisis respectivo:
Por un lado, con respecto a las anotaciones sobre el manejo de la información, John
Ruiz destaca que el gobierno de datos de las empresas públicas se encuentra mal
estructurado en su mayoría, de tal forma que la información puede llegar a
encontrarse en servidores fuera del país (Ruiz Aguilar, Entrevista del marco de
evaluación para la adopción de servicios en la nube en entidades públicas, 2020).
Ahora, si se tiene en cuenta nuevamente la característica de Cloud que facilita la
obtención de los servicios desde cualquier parte del mundo, este inconveniente no
estaría presente. Sin embargo, dada esta situación, el problema pasa a centrarse en
la gran cantidad de clústeres que se manejan, hecho que genera un desconocimiento
sobre la información puntual que maneja cada grupo de servidores. Este problema
puede atrasar considerablemente la migración del servicio, pues un punto vital para
el inicio del proyecto corresponde al conocimiento de la estructura de los datos.
Por otro lado, la resistencia al cambio se configura como una consecuencia de la falta
de agilidad en los procesos de migración, lo que a su vez se deriva de la complejidad
en la transición aun si es altamente controlada (Ruiz Aguilar, Entrevista del marco de
evaluación para la adopción de servicios en la nube en entidades públicas, 2020). Lo
último se debe a que para el traslado de un servicio a la nube y, posteriormente, de
grandes procesos; requerirá de una transformación sustancial en la infraestructura,
los conocimientos, las capacidades, las metodologías, entre otros componentes que
se involucran en esta práctica desplazada a la nube.
Por último, el tema presupuestal define que la migración de servicios a la nube
requiere de un mayor capital, pero es vital que este proceso no se configure dentro
de los rubros de costos sino de inversión; y para que esto se logre (teniendo en cuenta
que los costos de mantenimiento de la infraestructura actual siguen vigentes) es
necesario hacer una justificación muy detallada. Este requerimiento se hace más
evidente al observar que dentro del presupuesto del MinTIC sólo se destinan
$3.634.000.000 para proyectos afines a la computación en la nube (Ruiz Aguilar,
Entrevista del marco de evaluación para la adopción de servicios en la nube en
entidades públicas, 2020).
A partir del análisis hecho, se define un modelo (ver tabla 9) del nivel de importancia
de las dificultades a la hora de tomar la decisión de adoptar servicios de nube. Esta
tabla es tenida en cuenta para mejorar el marco de evaluación. A continuación, se
presenta el modelo:
Modelo de evaluación de impacto por complicación
Dificultad Nivel de importancia
Manejo de datos Crítico
Resistencia al cambio Alto
Presupuesto Crítico Tabla 9. Evaluación de la importancia de dificultades para la mejora del marco de evaluación.
❖ ¿Cuánto tiempo puede tomar una decisión de migrar un servicio a la nube? De ese tiempo
¿Cuánto se tarda en el análisis de viabilidad?
a) Puntos relevantes:
23
• Los tiempos en el análisis, la presentación y la implementación es altamente
dependiente del proyecto de migración.
b) Análisis respectivo
En la figura 3, se muestra el análisis del tiempo promedio que toma un proyecto de
migrar servicios a la nube:
Figura 3. Tiempos en la migración de un servicio a la nube (Ruiz Aguilar, Entrevista del marco de evaluación para la adopción de servicios en la nube en entidades públicas, 2020)
Es importante resaltar que dentro del proceso de análisis del proyecto es fundamental
tener en cuenta el nivel de madurez del servicio a migrar y de la empresa que recibe
el proyecto. Por un lado, la entidad debe ser madura pues será necesario entrar a
estudiar sus procesos, lineamientos y políticas para verificar si es viable la migración,
por consiguiente, estos deben estar correctamente definidos. Y por el otro lado, si un
servicio ya es muy maduro y se estima que presentaría más inconvenientes al pasar a
la nube que estando en su estado local; es preferible no migrarlo. Sin embargo, un
servicio puede ser implementado directamente, y desde cero, en Cloud.
❖ ¿Considera que las 6 categorías presentadas son suficientes para una adecuada
implementación del marco?
a) Puntos relevantes
• El trabajo de John Ruiz tiene como base al marco de Arquitectura Empresarial del
MinTIC; sin embargo, sólo abarca el dominio de Servicios Tecnológicos de la
versión del 2016 (actual Arquitectura de sistemas de información). Además, este
carece de detalles específicos.
• Hay dominios que faltan dentro del marco y que serían útiles para el entorno
actual.
b) Análisis respectivo:
24
Dentro de la conversación con John Jairo se definió que las seis categorías presentadas
en el marco son correctas pero pueden ser complementadas por nuevas; sin embargo,
es necesario adecuarlas al nuevo marco de referencia de Arquitectura Empresarial.
Además, se concretaron dos dominios fundamentales para tener en cuenta en la
mejora del marco de evaluación, que se muestran en la figura 4 en seguida:
❖ ¿Considera usted que se debe evaluar algún factor más, diferente del cubrimiento, la madurez
y la factibilidad financiera?
a) Puntos relevantes:
• Hay que revisar bien los lineamientos definidos, pues depende del lineamiento si
se requieran más factores de evaluación. Por tanto, se debe hacer la correcta
interpretación del lineamiento.
• Hay que observar el cambio que han tenido los factores a través del tiempo. Es
decir, si existen actividades con las que no contaba la organización y ahora sí.
• Partir del punto relevante anterior, y definir si hay nuevos factores a evaluar.
• Si los criterios presentados en el marco de AE del MinTIC se presentan de forma
más detallada, es decir, que dentro del marco de arquitectura se describa una
forma de como implementar cada criterio; puede haber otro nivel de
cubrimiento.
• Cambiar los criterios respecto a la presentación del lineamiento.
b) Análisis respectivo:
De acuerdo con el criterio de John Ruiz, hay que evaluar de forma más detallada los
lineamientos del marco de arquitectura empresarial del MinTIC actualizado (MinTIC,
2019). Dentro del marco de servicios de computación en la nube, se debe observar la
evolución de los criterios que se observan en ese marco; analizar si un criterio ha
avanzado en su nivel de cubrimiento. Ahora bien, un importante aporte, que afirmaba
Ruiz en la entrevista, es el cambio que ha tenido el marco de referencia de AE hecho
por el MinTIC. Pues hay lineamientos que fueron modificados en función de aportar
un mejor asesoramiento a las entidades que aplican este marco a su portafolio de
servicios. Por consiguiente, se debe realizar un mapeo de los lineamientos con los que
está compuesto el marco de referencia de Ruiz Aguilar con los lineamientos
especificados en la última versión del marco del ‘Framework’ de AE.
•El manejo de los datos para los servicios migrados a la nube esfundamental y es necesario regularlos.
•Es importante velar por la unión de la información.
Gobierno de datos
•En Colombia, muchos sistemas son creados y no son usadosdebido a la complejidad del mismo sistema.
•La inversión en activos de TI que no se usan representan ungasto grande para el estado.
Usabilidad
Figura 4. Dominios fundamentales para la implementación del nuevo marco (Ruiz Aguilar, Entrevista del marco de evaluación para la adopción de servicios en la nube en entidades públicas, 2020).
25
❖ ¿Qué nos recomendaría para lograr optimizar correctamente el marco de referencia?
a) Puntos relevantes:
• A pesar de que se han creado guías de implementación de los lineamientos, son
muy limitadas con el hecho de asesoramiento de implementación de los
lineamientos del marco de referencia de AE. Sin embargo, pueden servir de ayuda
en la definición de criterios del nuevo ‘framework’ de ‘Cloud computing’.
• Es vital estudiar las actualizaciones del marco de referencia de AE para lograr
hacer la relación entre los dominios propuestos en el 2016 (año en el que se
trabajó la primera versión del ‘framework’ para la migración de servicios a la
nube) y los tratados en el documento correspondiente al 2019.
b) Análisis respectivo:
Para el diseño del nuevo marco de referencia es de suma importancia tener en cuenta
el contexto actual del documento maestro de arquitectura empresarial del MinTIC
(2019). Dentro de este entorno se destaca, particularmente, la definición de guías de
implementación y la actualización de dominios. Para el primer caso, es importante
valorar que estos manuales no se enfocan en definir a detalle el ¿cómo? Implementar
o llevar a cabo el proceso sugerido. Sin embargo, estas limitadas metodologías son de
utilidad y pueden servir de base en la creación de nuevos criterios dentro del nuevo
marco. Por otra parte, para el segundo caso, se resalta que es vital estudiar la
actualización del marco de AE para lograr alinear los lineamientos del 2016 con los
actuales y, además, poder incluir aquellos que aún no estaban definidos.
4.2 APLICACIÓN DEL MARCO METODOLÓGICO A UNA ENTIDAD DEL SECTOR PÚBLICO En esta sección del capítulo se plantea una aplicación del marco de referencia creado por John Ruiz
(Ruiz Aguilar, Marco para evaluar la conveniencia de adoptar servicios en la nube en entidades
públicas, 2016) con el fin de obtener más datos y evidencias que permitan realizar un mejor
diagnóstico y posterior ajuste al marco. Esta aplicación se realizó sobre las Centrales Eléctricas de
Nariño (CEDENAR), una entidad pública con sede principal en San Juan de Pasto.
Con el fin de proveer un contexto más amplio, se trabajarán con subsecciones de la siguiente forma:
1. Descripción general de la entidad. (4.2.1)
2. Descripción general del servicio de TI seleccionado para la evaluación. (4.2.2)
3. Aplicación del marco de referencia sobre el servicio mencionado. (4.2.3)
4.2.1 Descripción general de las Centrales Eléctricas de Nariño (CEDENAR)
El 9 de agosto de 1955 la electrificadora de Nariño fue creada bajo la escritura pública 2059 de la
Notaria Cinco del Circuito de Bogotá y contando con la aprobación de la Superintendencia de
Sociedades mediante la Resolución 1055 del 24 de octubre de 1955. En un primer momento, la entidad
se crea como una Sociedad Anónima con la ayuda de diferentes accionistas y desde ese punto se
empezaron a gestionar proyectos de alta relevancia que han culminado en la posibilidad de, hoy por
hoy, brindar el suministro de energía a la ciudad capital de Pasto y a los demás municipios de Nariño.
26
Figura 5. Estructura Organizacional de las Centrales Eléctricas de Nariño (CEDENAR, 2020).
Dentro de su estructura organizacional (ver figura 5) se destaca que el área encargada del manejo de
tecnologías de la información corresponde a la Sub gerencia administrativa y financiera. Actualmente,
y de acuerdo con los testimonios dentro de esta unidad, este departamento cuenta con un alto interés
en implantar un proyecto de análisis sobre qué servicios deberían migrar a la nube, todo esto en el
marco de implementación de nuevas tecnologías. De hecho, en el mapa de procesos (ver tabla 10) se
declara que la gestión en TI corresponde a un elemento fundamental en el apoyo de la empresa y,
particularmente, en el manejo administrativo de la entidad.
Listado de Procesos (Sección de Apoyo)
Gestión Administrativa
Número del proceso Nombre del proceso 16 Gestión Humana 17 Gestión Almacén
15 Gestión de Compra de Bienes
19 Servicios Administrativos
20 Gestión Financiera
21 Gestión Seguridad y Salud en el Trabajo - SST
22 Gestión Centro de Administración Documental
23 Gestión Tecnologías de la Información y la Comunicación – TIC
Tabla 10. Mapa de procesos fraccionado – Enfocado en la sección de Apoyo (CEDENAR, 2020).
Así pues, y debido a este interés, la información para completar el estudio sobre las categorías del
marco de referencia propias a los servicios tecnológicos fue de fácil acceso y no se presentaron
inconvenientes mayores en su obtención.
4.2.2 Descripción general del servicio de TI
Se seleccionó evaluar la posibilidad de migrar los servicios del Portal Web de la organización. Este
servicio opera actualmente en la entidad de manera ‘On-Premise’ y la empresa desea migrarlo a la
nube. Esta migración de servicios se debe a que Cedenar presenta altos costos en el soporte y
mantenimiento de los servidores que manejan para operar este servicio. Adicionalmente, la empresa
desea obtener los beneficios tributarios propuestos por el MinTIC al adoptar servicios en la nube.
27
4.2.3 Aplicación del marco sobre CEDENAR
Para observar a más detalle el resultado de aplicación del marco de evaluación se debe abrir el ‘anexo
A’, llamado “Primera aplicación del marco de evaluación para evaluar la conveniencia de adoptar
servicios en la nube de entidades públicas”. Partiendo de cada categoría de evaluación, se obtuvo el
siguiente análisis (para mayor orientación revisar las tablas 3 y 4 con la información de los subcriterios
de nivel de cubrimiento y madurez respectivamente):
4.2.3.1 Categoría de Arquitectura de Servicios Tecnológicos
o Con respecto al subcriterio de cubrimiento de actividades en esta categoría, solo el 20% del
total de criterios presentaron un nivel de cubrimiento menor al 100% de las actividades
señaladas. Lo que demuestra la capacidad de operar los servicios de TI de la empresa.
o En cuanto al subcriterio de nivel de madurez del proceso, en la mayoría de los procesos
presentaron un nivel 4 de madurez. Asimismo, hubo cinco criterios (de los veinte totales)
que presentaron un nivel inferior, que de este sólo uno estuvo en nivel 0 (que no se ha
implementado).
o El puntaje global de la categoría fue de 82. Esta puntuación, permite observar a nivel general
que la empresa mantiene una buena gestión de los procesos pertenecientes a esta
categoría. Con respecto a este puntaje, cabe aclara que se halló promediando los puntajes
de todos los criterios.
o Observando el resultado de la mediana de los criterios, se puede denotar una puntuación
más alta. Lo que elimina el sesgo de promediar los resultados globales de los criterios de
esta categoría. Puesto que no hay ponderación sobre los criterios, es decir, que todos tienen
el mismo valor.
4.2.3.2 Categoría de Operación de Servicios Tecnológicos
o El subcriterio de cubrimiento de actividades presenta puntajes altos y bosqueja un escenario
que muestra que Cedenar, en materia de operación de sus servicios tecnológicos, logra
desempeñar la mayoría de las actividades planeadas.
o La actividad de Gestión de Disponibilidad sólo se cubre en un 50%, lo que indica que el
modelo actual de operación no está asegurado para operar con una alta disponibilidad y es
necesario implementar mecanismos locales para asegurar este atributo de calidad.
o La actividad de Gestión de Demanda para establecer requerimientos actuales y futuros en
activos TI presenta un porcentaje considerablemente bajo (33%) y muestra que la Dirección
de TI no gestiona correctamente un estudio sobre las necesidades en TI que la empresa
actualmente presenta y tampoco hace un análisis sobre el panorama futuro en materia de
tecnología.
o En nivel de madurez, se muestra que la actividad de Gestión de Demanda tiene un puntaje
de 0, el cual fue asignado debido a que actualmente este proceso no alcanza los objetivos
de negocio ni de TI.
4.2.3.3 Categoría de soporte de servicios tecnológicos
o A visión general, el subcriterio de nivel de cubrimiento de actividades tiene se mantiene un
nivel de cobertura total para el 70% de los criterios. Sin embargo, hubo dos criterios que no
presencian nivel de cubrimiento, en los cuales corresponde al proveedor de TI.
o Con respecto al subcriterio de nivel de madurez del criterio, todos los procesos
correspondientes a la dirección de TI presentan entre procesos predecibles u optimizados. Si
bien, hubo criterios pertenecientes al proveedor de TI que tienen procesos hasta ahora
implementados (nivel uno); estos dos criterios, corresponden a los mismos que no
presentaban cubrimiento en el punto anterior.
28
o El puntaje global de esta categoría fue de 82, lo que indica la calidad en los procesos de
soporte de servicios tecnológicos por parte de esta categoría. Puesto que este puntaje se
obtuvo principalmente por los criterios que le conciernen a la directiva de TI. Por lo que se
requiere realizar un proceso más cuidadoso de selección del proveedor de TI.
o Al hallar la mediana, el puntaje fue aún más alto, obteniendo 90 puntos. Este cambio se debe
principalmente a que mantiene valores altos en general, los valores de bajo puntaje
coinciden con los criterios que le corresponden al proveedor de TI. Lo que hace más evidente
la necesidad de reevaluar el proveedor para esta categoría o reevaluar los términos pactados
en el servicio ofrecido de ‘Cloud’.
4.2.3.4 Categoría de gestión de la calidad y seguridad de TI
o Esta categoría posee un puntaje global de 89 y altos valores en los subcriterios de cubrimiento
y nivel de madurez. Estos resultados indican que las implementaciones de servicios TI son
realizadas bajo un estándar de calidad altamente definido y, además, se garantiza una buena
seguridad para los mismos.
o Las actividades que cuentan con un puntaje menor a 100% son las de Gestión de Eventos para
asegurar los SLA en materia de acciones preventivas y las Gestión de Eventos en el esquema
de acciones preventivas; ambos relacionados al Proveedor de TI. No obstante, la mitad de las
actividades no se cubren para ambos casos, lo que puede indicar que la identificación de
eventos y alertas para la gestión de seguridad no están completamente garantizadas.
4.2.3.5 Categoría de entorno legal
o De acuerdo con el subcriterio de nivel de cubrimiento de actividades de la empresa, en esta
categoría solo hay un criterio que no tiene cubrimiento (correspondiente a la directiva de TI),
los otros dos están totalmente cubiertos. Según este criterio, la directiva de TI no tiene
procesos de gestión de relaciones con el negocio, que le permite regular el alcance normativo
que debe ser implementado par el servicio de TI.
o Según el subcriterio de nivel de madurez en esta categoría se presentaron dos criterios con
procesos predecibles y uno como proceso establecido (perteneciente a la directiva de TI). Por
ende, no se muestran deficiencias en el nivel de madurez de los procesos relacionados a esta
categoría.
o El puntaje global de esta categoría fue de 70. Esta fue de las categorías con un puntaje más
bajo. Puesto que el puntaje se redujo debido a un criterio perteneciente a la directiva de TI,
se puede denotar que la empresa no articula bien la operación de este servicio con el entorno
legal.
o Para esta categoría no tiene sentido analizar la mediana debido a que solo hay tres criterios
hasta el momento, por tanto, la mediana presentaría un sesgo porque se comportaría como
una moda.
4.2.3.6 Categoría de entorno financiero
o Es la categoría con menor puntaje global con 54 puntos. Esto se debe principalmente a dos
criterios estudiados correspondientes al análisis de factibilidad financiera de la nube con otros
servicios y la gestión de relaciones. Estos dos criterios cuentan con un puntaje total de 33 y 35
respectivamente, que en un escenario de evaluación de 4 elementos, reduce
considerablemente el promedio.
o Con respecto al análisis de factibilidad financiera se enuncia que actualmente Cedenar se
encuentra en un proceso de migración entre sistemas de información, razón por la cual no es
tan factible que gran parte de los recursos en tecnología se destinen para el despliegue en la
nube. Adicionalmente, este tuvo un resultado de 0, bajando el promedio de la categoría; este
29
se debe, principalmente a que se presentan falencias en la fórmula de los valores posibles de
este criterio de evaluación.
o El segundo criterio de bajo puntaje corresponde al de gestión de relaciones con el cliente para
garantizar acuerdos comerciales y requerimientos en la prestación del servicio de TI. Acá se
destaca que el proveedor de TI no logra cubrir esta actividad en su totalidad y, por ende, las
garantías mencionadas no están totalmente aseguradas. Por otra parte, el nivel de madurez
del servicio indica que el proceso no alcanza su objetivo, por ende, el puntaje asignado es de
0.
4.3 DIAGNÓSTICO Y CONCLUSIONES DEL MARCO DE METODOLOGÍA ACTUAL Para realizar el diagnóstico de la situación actual del “marco de evaluación para adoptar servicios en
la nube”, se tomaron dos puntos de partida. El primero, fue la entrevista a John Jairo Ruiz de la cual
se dedujeron los siguientes criterios:
• El marco de referencia de AE diseñado por el MinTIC actualizó a su nueva versión del año
2019. Por tanto, es necesario actualizar los criterios del marco de evaluación de adquisición
de servicios en ‘Cloud Computing’ elaborado por Ruiz (2016).
• Es necesario incluir criterios relacionados con la estructura de los datos que maneja el servicio.
• La resistencia al cambio es un factor vital a la hora de adquirir nuevos servicios de TI (en este
caso se habla de servicios de nube), ya que las empresas presentan falta de agilidad en los
procesos de migración de servicios. Pues se presentarán transformaciones de infraestructura,
en las capacidades requeridas para operar los servicios de negocio, las metodologías
implementadas en los proyectos de trabajo, entre otros.
• Hay que evaluar la viabilidad de migración de servicios con respecto a la complejidad del
proyecto. Puesto que la complejidad del proyecto es un factor determinante con la estimación
de tiempo de este. Por lo tanto, es un factor que se debe tener en cuenta a la hora de evaluar
la factibilidad de migrar servicios a la nube, ya que los retrasos son más costosos en proyectos
complejos.
• Evaluar el estado de madurez actual del servicio que se quiere migrar, ya que el entrevistado
resalta que un servicio muy maduro no es recomendable migrarlo a la nube.
• En cuanto a los criterios que se tienen del marco actual, basados en los lineamientos del marco
de referencia de AE del MinTIC, se les debe hacer su respectivo mapeo a los lineamientos del
marco de referencia actual (2019).
• Además de los lineamientos actuales (2019) del marco de referencia de Arquitectura
Empresarial, también se presenció un cambio en los dominios que maneja (ver dominios en
la sección 3.2 “Gobierno en línea”). El marco elaborado por Ruiz Aguiar (2016) se basó en un
dominio llamado “Servicios tecnológicos” que ahora se representa en os dominios de:
Arquitectura misional, Arquitectura de información, Arquitectura de sistemas de información,
Arquitectura de infraestructura tecnológica y Arquitectura de seguridad.
El segundo punto de partida es la aplicación del marco de evaluación a la empresa Centrales Eléctricas
de Nariño (Cedenar), donde se obtuvieron las siguientes reflexiones:
• Los actores definidos para el marco de Dirección de TI y Proveedor de TI son insuficientes para
realizar la evaluación de viabilidad de la adopción de tecnologías en la nube debido a que
pueden a ver otras áreas dentro de la organización que incidan en la toma de decisiones. Por
consiguiente, se debe evaluar más actores que puedan incidir en el proceso de evaluación.
Puesto que hay empresas que tienen un esquema más complejo en su área de TI, que puede
30
estar más fragmentada en equipos de gestión, dirección, soporte, infraestructura, desarrollo,
innovación, pruebas, entre otros.
• Algunos criterios presentados en el marco de evaluación para adoptar servicios en la nube
(Ruiz Aguilar, 2016) carecen de claridad en la redacción, lo que genera complicaciones a la
hora de aplicarlo. En otras palabras, se presentan dificultades a la hora de entender ciertos
criterios, mostrando que requieren una reformulación.
• La categoría de entorno financiero presenta insuficiencias. Dentro de esta, hace falta incluir
criterios que integren los beneficios financieros que tiene la computación en la nube en
cuanto a factores como soporte y mantenimiento y el análisis de los gastos asociados.
• El análisis de viabilidad para la adquisición se servicios en la nube no debe depender
únicamente de la información interna de la empresa a la cual se le aplica. En ese orden de
ideas, se pueden crear nuevas categorías que correspondan a datos tales como el sector de la
industria a la que pertenece la entidad (como se aplica Cloud en ese sector). De este modo,
se pueden crear un preanálisis que soporte las categorías que ya están y así crear un marco
de evaluación más robusto y que se agilice la aplicación de este.
• Con respecto al criterio de factibilidad financiera, se identificó una falencia en la fórmula de
los valores posibles asociados al nivel de factibilidad. Este problema reside en que, según la
fórmula, mientras más alto sea el costo de contratar servicios en la nube el resultado es más
factible. De este modo, se observa que hay una incoherencia en la forma de evaluar este
criterio, pues la proporción de factibilidad debería ser inversa a al costo de contratar servicios
en la nube. Por ende, resulta necesario modificar esta fórmula.
• En cuanto a la usabilidad del marco actual, debe ser más automatizado. Esto se debe a que
tener hojas de Excel para llenar resulta muy tedioso para el que realiza la actividad. Por ende,
es preferible tener un servicio de TI que con tenga la información, se le asignen los valores, y
este genere el puntaje final y un informe con los resultados y conclusiones acerca de la
decisión que debe tomar la dirección de la organización.
5. EVOLUCIÓN DEL MARCO DE EVALUACIÓN Del análisis realizado para el entendimiento y diagnóstico del marco de metodología de Ruiz Aguilar
(2016) se lograron extraer varias conclusiones acerca del funcionamiento y estado del marco de
referencia en cuestión. Ahora, el verdadero valor agregado de estos resultados consiste en que estos
se configuran como la base en el desarrollo de la evolución del marco. Por consiguiente, a lo largo de
esta sección se detallará el Marco para evaluar la conveniencia de adoptar servicios en la nube en
entidades públicas versión 2.
31
5.1. ESTRUCTURA DEL NUEVO MARCO METODOLÓGICO PARA ADOPTAR SERVICIOS EN LA
NUBE EN ENTIDADES PÚBLICAS
Figura 6. Metamodelo del nuevo marco metodológico para la adopción de servicios en la nube en entidades públicas.
En la figura 6 se encuentra la estructura del nuevo marco de metodología propuesto para la
migración de servicios a la nube en entidades del sector público. Como se observa, el
metamodelo de este marco no cambia a gran escala con respecto al “Marco para evaluar la
conveniencia de adoptar servicios en la nube en entidades públicas” (revisar figura 2) diseñado
por Ruiz (2016) ya que ambos manejan tres niveles de agrupación: categoría, criterios,
subcriterios. A cada criterio le corresponden entre uno y dos subcriterios de nivel de madurez
del proceso, nivel de cubrimiento del proceso y factibilidad financiera. Adicionalmente, en la
figura se evidencia que cada subcriterio tiene valores posibles, los cuales serán especificados más
adelante. También se resalta que a cada criterio se le atribuirá un actor que puede ser el
proveedor de TI o la dirección de TI. En resumen, se mantuvo un modelo similar a la primera
versión del marco de evaluación; sin embargo, hubo un cambio sustancial en el contenido.
De igual manera, se presenta la figura 7 a modo de complemento de la estructura del nuevo
marco.
32
Figura 7. Modelo de la estructura del nuevo marco metodológico.
Como se mencionó previamente, el marco de referencia de John Ruiz (Ruiz Aguilar, 2016) fue
modificado después de un análisis sobre los instrumentos de diagnóstico (entrevista y aplicación).
Específicamente los cambios tuvieron lugar en la estructura y el contenido, esto con el fin de que el
nuevo marco de evaluación resultante esté actualizado según el nuevo diseño del documento de AE
del MinTIC y ofrezca un enfoque de evaluación más completo al integrar diferentes componentes de
la arquitectura empresarial. En primer lugar, en esta subsección se listarán, de forma superficial, los
cambios y consideraciones sobre la estructura del marco. Posteriormente, en el apartado 5.2 se
describirá el nuevo contenido. Por lo tanto, a continuación, se encuentran los cambios aludidos:
1. Cambio en el enfoque de los dominios: teniendo en cuenta el cambio conceptual sobre los
dominios en el marco de arquitectura empresarial se optó por no incluir este término y, a su
vez, establecer las categorías como la raíz del nuevo marco de metodología para la evaluación
de la migración de servicios a la nube en entidades públicas. Además, la primera versión del
“Marco para evaluar la viabilidad de adoptar servicios en la nube en entidades públicas” se
enfocaba en un dominio de marco de AE propuesto por el MinTIC llamado “dominio de
servicios tecnológicos”; mientras que la nueva versión de este marco se enfoca en cinco
dominios del marco AE propuesto por el MinTIC (ya que este fue actualizado) en los cuales se
excluyeron los dominios de “Planeación de la arquitectura” y “Uso y apropiación de la
arquitectura” (MinTIC, 2019) porque el primero estaba centrado en la arquitectura
empresarial de la organización y no en servicios tecnológicos; el segundo, estaba enfocado en
actividades posteriores a la implementación de servicios de TI.
2. Cambio en el enfoque de las categorías: tal y como se mencionó previamente, el punto de
origen del marco de metodología corresponde al concepto de categoría. Para definir este
grupo se optó por realizar un cambio de terminología entre “dominio” y “categoría”. Lo
anterior se realizó con el fin de agrupar los criterios del marco de evaluación.
Adicionalmente, se adoptaron categorías del “Marco para evaluar la conveniencia de adoptar
servicios en la nube en entidades públicas” (Ruiz Aguilar, 2016). Por un lado, están las
categorías de entorno legal y entorno financiero, esta decisión se debe a su relevancia en los
proyectos de migración de tecnología; cabe resaltar que al primero se le cambió el nombre de
la categoría debido a que hay poco aspecto jurídico y legal, y el segundo fue modificado de
Cateogría de evaluación
Actor
Criterio de evaluación
Sub-criterio de evaluación
Valor posible
Mejor
práctica de
ITIL 4
Actividades
asociadas
33
acuerdo con el diagnóstico del marco. Por otro lado, se diseñó una categoría que contiene los
criterios correspondientes a la evaluación de niveles de servicio; para esta se integran criterios
del estado del arte del trabajo de Ruiz Aguilar (2016) y ciertos lineamientos del marco de AE
del MinTIC. A continuación, se listan las categorías manejadas en el nuevo marco de
referencia:
o (CAT.1) Arquitectura Misional o (CAT.2) Arquitectura de Información o (CAT.3) Arquitectura de Sistemas de Información o (CAT.4) Arquitectura de Infraestructura o (CAT.5) Arquitectura de Seguridad o (CAT.6) Arquitectura de servicios tecnológicos o (CAT.7) Entorno de las partes interesadas o (CAT.8) Entorno Financiero
3. Se mantiene el concepto de actor: el motivo por el cual se decidió mantener este concepto
es debido a que se está tercerizando un servicio de tecnología. En otras palabras, parte de las
responsabilidades del servicio pasa a ser del proveedor de servicios de nube. Por ende, es
necesario que tanto la dirección del área de TI de la organización como el proveedor elegido
cuentan con los elementos necesarios, asegurando un buen funcionamiento del servicio. Para
ello, se deben incluir criterios de evaluación que apliquen a la (i) dirección de TI y al (ii)
proveedor de TI.
4. Se mantiene el concepto de criterio de evaluación: este concepto corresponde a los
elementos necesarios para analizar la viabilidad en una empresa de la adopción de servicios
de computación en la nube. Por tanto, se decidió conservar este concepto, porque es el
elemento central del marco de evaluación; ya que este es el que determina la finalidad del
proyecto.
Adicionalmente, como se muestra en la figura 7, cada criterio tendrá asignada una práctica
proveniente de ITIL 4 y, a su vez, de cada práctica se derivarán una o más actividades que se
usarán para medir el nivel de cubrimiento (explicado en el componente de “Subcriterio de
evaluación”).
Ahora, es importante resaltar que la forma de los criterios provenientes de los lineamientos
del marco de AE, los del estado del arte y los propios del marco de Ruiz (2016); son diferentes.
En seguida se ejemplificará el formato de presentación de los lineamientos del marco de
evaluación:
• Categoría: (COD-Categoría) NOM-Categoría
➢ (COD-Categoria.CRI.X) NOM-Criterio: DESC-Criterio.
▪ (i) Subcriterio: DESC-Subcriterio.
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL
4: NOM-Práctica):
✓ DESC – Actividad.
✓ (…)
✓ DESC – Actividad.
▪ (ii) Subcriterio: DESC-Subcriterio.
o Proceso para evaluar ITIL v3: NOM-Proceso
Donde:
1. (COD-Categoría): corresponde al código de la categoría según como se describió
en el componente “Categoría de evaluación”.
2. (NOM-Categoría): corresponde al nombre de la categoría.
34
3. (CRI.X): hace referencia al código del criterio en la estructura del marco de
evaluación.
4. (i) Subcriterio: la “i” hace referencia al número del subcriterio tomado del
criterio correspondiente.
5. (XX): “XX” corresponde al número del criterio.
6. NOM-Criterio: hace referencia al nombre del criterio.
7. (DES-Criterio): corresponde a la descripción del criterio.
8. (NOM-Práctica): corresponde al nombre de la práctica, el cual ya está definido
en el documento “ITIL Foundation 4 edition” (ITIL, 2019).
9. (DESC-Actividad): corresponde a la descripción de la actividad seleccionada.
10. (NOM-Proceso): hace referencia al proceso para evaluar el nivel de madurez de
ITIL v3.
5. Se mantiene el concepto de subcriterio de evaluación: este concepto tiene como fin
determinar el cumplimiento del respectivo criterio. Puesto que para entender si una empresa
satisface un criterio, se debe analizar los procesos que se derivan del mismo. Para esta versión
del marco de referencia también se cuentan con los siguientes dos subcriterios generales:
a. Nivel de cubrimiento: número de actividades tomadas de ITIL 4 con las que cuenta
actualmente la empresa, con respecto al número de actividades propuestas para cada
criterio.
b. Madurez del proceso: nivel de madurez de los procesos asociados según el estándar
propuesto por “ITIL Maturity Model” (ITIL, 2013).
Adicionalmente, se destaca que se seguirá usando el subcriterio especial de “nivel de
factibilidad financiera” propuesto en el marco de evaluación de adopción de servicios en la
nube elaborado por Ruiz (2016) y aplicado sólo en criterio perteneciente a la categoría de
“Entorno financiero”. De la misma forma, se consideró necesario crear otro subcriterio
especial para determinar el “beneficio de liquidez”; este subcriterio hace referencia a los
costos ahorrados por la adquisición de servicios en la nube, con respecto a la contratación de
infraestructura propia (Ruiz Aguilar, 2016).
6. Se mantiene el concepto de valor posible: la razón de mantener este concepto es por el hecho
de que se necesita de una puntuación para concluir si el servicio al cual se le aplica el marco
de evaluación le resulta viable adoptar servicios en la nube. Para ello, se debe analizar el
resultado de la aplicación del marco, que es el que refleja si cumple o no con los criterios
estipulados. Adicionalmente, para el subcriterio de beneficio en liquidez se determinaron
nuevos valores posibles en los que se definen cuatro intervalos iguales (ver tabla 15). A
continuación, se presentarán las tablas con los valores posibles de los subcriterios:
Valores posibles para el subcriterio: nivel de cubrimiento de las actividades
Nivel de cubrimiento de actividades
Fórmula Puntuación
Sin cubrimiento (#ActividadesCubiertas/#TotalActividades) = 0% 0
Bajo cubrimiento 0% < (#ActividadesCubiertas/#TotalActividades) <= 50% 25
Parcialmente cubierto 50% < (#ActividadesCubiertas/#TotalActividades) < 80% 50
Altamente cubierto 80% <= (#ActividadesCubiertas/#TotalActividades) < 100% 75
Cubierto (#ActividadesCubiertas/#TotalActividades) = 100% 100
Tabla 11. Valores posibles del subcriterio nivel de cubrimiento (Ruiz Aguilar, 2016).
Para la evaluación del subcriterio de madurez se decidió utilizar el modelo de evaluación de
ITIL, el cual consiste en medir la madurez de los procesos a través de seis valores posibles.
35
Ahora, esta versión del marco para evaluar la migración de servicios a la nube está planteada
sobre ITIL 4; no obstante, con la información que se cuenta, para ITIL 4 aún no existe un
modelo para evaluar la madurez del proceso. Por ende, es necesario realizar la evaluación de
nivel de madurez haciendo uso de ITIL v3. Para esto, se realiza un mapeo (ver ‘anexo B’
“Mapeo de mejores prácticas de ITIL 4 a procesos de ITIL v3”) entre ITIL v3 e ITIL 4, para así
relacionar cada práctica con su proceso correspondiente. En consecuencia, se procede a
evaluar según los valores posibles mencionados a continuación en la tabla 12:
Valores posibles para el subcriterio: nivel de madurez del proceso Nivel de madurez del
proceso Descripción Puntuación
Nivel 0: ausencia (caos) El proceso está parcialmente presentado, pues no están definidas las responsabilidades y no hay consistencia en su operación.
0
Nivel 1: inicial (reactiva)
El proceso está destinado a cumplir con una solución concreta, sin embargo, su operación y gestión es desordenada y anárquica.
20
Nivel 2: repetitiva (activa)
El proceso está descoordinado, es irregular y enfocado directamente hacia la eficiencia del mismo.
40
Nivel 3: definida (proactiva)
El proceso es parcialmente reconocido, estandarizado, documentado, comunicado y enfocado a la eficiencia y la eficacia.
60
Nivel 4: gestionado (preventivo)
El proceso está totalmente definido, gestionado, monitoreado, direccionado a la prevención, con interfaces establecidas y documentadas, y con dependencia a otros procesos de TI.
80
Nivel 5: optimizado El proceso cuenta con objetivos y metas estratégicas alineadas con la estrategia general de negocio y los objetivos de TI.
100
Tabla 12. Valores posibles para el subcriterio de nivel de madurez del proceso (ITIL, 2013).
Ahora bien, para la factibilidad financiera es importante mencionar que el marco de Ruiz
Aguilar (2016) ya presenta una metodología para obtener los valores de este subcriterio. Sin
embargo, analizando las fórmulas matemáticas utilizadas para el cálculo se determinó que era
necesario adecuar las ecuaciones. Lo anterior debido a que el costo de contratar servicios en
la nube (CSN) debe ser inverso al nivel de factibilidad financiera; ya que mientras menos
costoso sea adoptar servicios de nube, en comparación con la compra de infraestructura
propia, debe ser más factible contratar servicios de nube. En ese orden de ideas, se hace una
comparación a modo de razón entre el costo de adoptar servicios en la nube y el costo de la
compra de infraestructura (PACI). Ahora, si el costo de contratar servicios de nube es menor
se obtiene un nivel factible. Con respecto a la definición de los demás elementos del
subcriterio, se destaca que se realizó con base a la siguiente metodología: (i) Se adoptaron los
mismos puntajes y niveles del subcriterio de factibilidad financiera del marco de evaluación
de Ruiz Aguilar (2016). (ii) Para determinar los nuevos intervalos se plantea que si la razón
PACI/CSN es mayor o igual a uno (1), se obtiene el puntaje máximo (100) y el nivel es factible.
(iii) Para los otros niveles (factibilidad media, factibilidad baja y no factible), en donde la razón
PACI/CSN está entre 0 y 0. 99̅̅̅̅ , se realizó una partición de tres intervalos iguales. Por tanto, los
valores posibles de este criterio se muestran en seguida en la tabla 13:
Valores posibles para el subcriterio: nivel de factibilidad financiera
Nivel de factibilidad financiera Fórmula Puntuación
No factible PACI/CSN < 0,33 0
36
Factibilidad baja 0,33 <= PACI/CSN < 0,66 33
Factibilidad media 0,66 <= PACI/CSN < 1 66
Factible PACI/CSN >= 1 100 Tabla 13. Nuevos valores posibles para el subcriterio de nivel de factibilidad financiera.
Donde:
• CSN: Costo de contratación de servicio en la nube. Este se obtiene al hallar el valor
presente neto (VPN) del costo de suscripción de un proveedor de nube por el
tiempo que dura el proyecto de migrar el servicio a la nube y hacer uso del mismo.
• PACI: Presupuesto asignado para comprar la infraestructura. Este es aportado por
la empresa.
Para un mayor entendimiento de la evaluación del nivel de factibilidad financiera se propone
un ejemplo en donde se abordan los cuatro niveles de factibilidad posibles (no factible,
factibilidad baja, factibilidad media y factible) y se brinda una interpretación del resultado.
Para la realización de esta demostración, por un lado, se fijó el presupuesto asignado para
compra de infraestructura (PACI) en quinientos millones de pesos ($500.000.000,00 COP). Por
otro lado, para costo de contratación en la nube (CSN) se tuvieron en cuenta cuatro escenarios
con cuatro valores diferentes. El ejemplo se presenta en la tabla 14 a continuación:
Por último, para el subcriterio de beneficio en liquidez se adoptaron los mismos intervalos del
subcriterio de factibilidad financiera de la primera versión del marco de evaluación para
adoptar servicios en la nube en entidades públicas (ver tabla 5).
Valores posibles para el subcriterio: nivel de liquidez
Nivel de beneficio en liquidez Fórmula Puntuación
CSN (COP) PACI/CSN Intervalo Nivel de
factibilidad Puntuación del criterio
Explicación
$2.000.000.000,00 0,25 PACI/CSN< 0,33 No factible 0
Teniendo en cuenta que el costo de contratación en la nube es cuatro veces mayor en comparación de comprar infraestructura, se define que adoptar servicios en la nube no es viable financieramente.
$1.000.000.000,00 0,50 0,33 <=
PACI/CSN < 0,66
Factibilidad baja
33
Teniendo en cuenta que el costo de contratación en la nube es dos veces mayor en comparación de comprar infraestructura, y la razón entre los dos es mayor a 0,33 se obtiene un puntaje adicional.
$575.000.000,00 0,87 0,66 <=
PACI/CSN < 1 Factibilidad
media 66
Teniendo en cuenta que el costo de contratar servicios en la nube corresponde a cuatro terceras partes en comparación de comprar infraestructura propia se le otorga al criterio 66 puntos. Pues la razón es mayor a 0,66. No obstante, no hay factibilidad total.
$250.000.000,00 2,00 PACI/CSN >= 1 Factible 100
En este caso, el costo de contratar servicios en la nube es menor en comparación de contratar infraestructura propia, por lo que resulta completamente factible, en términos financieros, adoptar servicios de nube.
Tabla 14. Ejemplo de evaluación del subcriterio de nivel de factibilidad financiera.
37
Sin beneficio ((PARP – CSN)/PARP) * 100% <= 0% 0
Beneficio bajo 0 < ((PARP – CSN)/PARP) * 100% <= 10% 33 Beneficio medio 10% < ((PARP – CSN)/PARP) * 100% <= 20% 66
Beneficio alto ((PARP – CSN)/PARP) * 100% > 20% 100
Tabla 15. Valores posibles para el subcriterio de nivel de nivel de liquidez.
Donde:
• CSN: Costo de contratación de los servicios en la nube el primer mes.
• PARP: Presupuesto destinado para la realización del proyecto.
Ahora bien, una vez explicados los valores posibles, se resalta que estos son promediados para todos
los subcriterios (de su respectivo criterio) y así se obtiene el puntaje del criterio. Seguidamente, se
computan todos los valores de los criterios para así obtener el puntaje de la categoría. Finalmente, se
halla el promedio de los valores de las ocho categorías para así tener el resultado global del marco de
evaluación para la adopción de servicios en la nube. El mínimo de esta cifra debe ser de setenta y cinco
(75) puntos para así considerar que el servicio evaluado sea factible de migrar el servicio a la nube.
Este valor, que aumenta con respecto a la versión anterior del marco de evaluación (Ruiz Aguilar,
2016), que era de sesenta (60) puntos, surge de la necesidad de reducir el sesgo asociado con el cálculo
del promedio. En otras palabras, dado el caso de que una categoría presente un puntaje muy alto y
las demás un puntaje muy bajo, se pueda evitar que el promedio permita la aceptación de la migración
del servicio. Lo anterior se ejemplifica al considerar un escenario en el cual, haya una categoría con
noventa y cinco (95) puntos, otra categoría con setenta (70) puntos y las seis restantes con cincuenta
y cinco (55) puntos, se obtendría un puntaje global de 61,87 puntos. De este modo, en la primera
versión del marco de evaluación la migración del servicio a la nube sería aprobada, a pesar de que en
este escenario existen seis categorías que no sobrepasan los sesenta (60) puntos.
5.2. DISEÑO DEL MARCO DE EVALUACIÓN Ahora bien, se presenta la instanciación la estructura de la nueva versión del marco de evaluación
para la adopción de servicios en la nube en entidades del sector público. Para la elaboración de este,
se extrajeron las mejores prácticas y actividades de ITIL 4 del libro “ITIL Foundation ITIL 4 Edition” (ITIL,
2019), para así hacer la evaluación de cada criterio. A continuación, se muestra el marco de evaluación:
• Categoría: (CAT.1) Arquitectura Misional
➢ (CAT.1.CRI.1) Gestión misional del modelo estratégico: la dirección de TI cuenta con un
proceso de seguimiento continuo del modelo estratégico de la empresa. Lineamiento:
MAE.LI.AM.01 - Modelo de intención de la entidad.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Strategy
Management):
✓ Análisis del entorno organizacional para identificar las oportunidades que pueden
ser beneficiosas.
✓ Identificación de los inconvenientes que pueden afectar de forma negativa los
objetivos de la organización y como minimizarlos.
38
✓ Definir la dirección y perspectiva de la entidad, definiendo correctamente los
interesados, la misión, la visión y los principios.
✓ Asignar planes operacionales y tácticos para cada unidad de la organización
reflejando la estrategia de la empresa.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Strategy Management for IT Services.
➢ (CAT.1.CRIT.2) Gestión misional del modelo financiero: la dirección de TI cuenta con un
proceso de seguimiento continuo del modelo financiero. Lineamiento: MAE.LI.AM.01 -
Modelo de intención de la entidad.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Service
Financial Management):
✓ Presupuesto/Costos: predecir y controlar los ingresos y los gastos dentro de la
organización.
✓ Contabilidad: realizar una contabilidad completa sobre la forma en cómo se gasta
el dinero disponible, permitiendo realizar análisis de pronóstico vs actual y de
gastos. Se resalta la posibilidad de identificar y diferenciar utilidades y costos por
clientes, servicios y actividades.
✓ Carga: proveer un servicio de facturación a los consumidores por los servicios que
se les está entregando.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Financial Management for IT Services.
➢ (CAT.1.CRIT.3) Gestión misional del portafolio de servicios: la dirección de TI cuenta con un
proceso de seguimiento continuo del portafolio de servicios. Lineamiento: MAE.LI.AM.01 -
Modelo de intención de la entidad.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Portfolio
Management):
✓ Desarrollo y aplicación de marcos de referencia sistemáticos para definir y
entregar portafolio de productos, servicios, programas y proyectos para apoyar
determinadas estrategias y objetivos.
✓ Definir productos y servicios articulándolos con el cumplimiento de los costos
presupuestados y asegurar que todas las actividades del servicio se alinean con la
cadena de valor en la definición de valor y los factores críticos de éxito.
✓ Evaluar y priorizar los ingresos de los proyectos, productos o servicios propuestos
basándose en las restricciones de recursos, compromisos actuales y la estrategia
de la organización.
✓ Implementar asesoramientos estratégicos de inversión y procesos de toma de
decisiones basados en el entendimiento del valor creado, los costos, los riesgos,
39
las restricciones en términos de recursos, las interdependencias y el impacto
sobre las actividades existentes de negocio.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Service Portfolio Management.
➢ (CAT.1.CRI.4) Gestión del portafolio de servicios del proveedor: el proveedor de TI cuenta
con un proceso de seguimiento continuo del portafolio de servicios. Lineamiento:
MAE.LI.AM.01 - Modelo de intención de la entidad.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Portfolio
Management):
✓ Desarrollo y aplicación de marcos de referencia sistemáticos para definir y
entregar portafolio de productos, servicios, programas y proyectos para apoyar
determinadas estrategias y objetivos.
✓ Implementar asesoramientos estratégicos de inversión y procesos de toma de
decisiones basados en el entendimiento del valor creado, los costos, los riesgos,
las restricciones en términos de recursos, las interdependencias y el impacto
sobre las actividades existentes de negocio.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Service Portfolio Management.
➢ (CAT.1.CRI.5) Gestión del modelo de capacidades: la dirección de TI cuenta con un proceso
de gestión del modelo de capacidades de la entidad. Lineamiento: MAE.LI.AM.02 - Modelo de
capacidades institucionales.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Architecture
Management):
✓ Definir el modelo de capacidades de la empresa de la arquitectura de negocio.
✓ Las capacidades de la empresa se deben articular con las actividades relacionadas
con la creación de valor.
✓ Priorizar las capacidades, según las necesidades del negocio.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Strategy Management for IT Services.
➢ (CAT.1.CRI.6) Gestión del modelo operativo: la dirección de TI cuenta con un proceso de
gestión del modelo operativo de la entidad. Lineamiento: MAE.LI.AM.03 - Modelo operativo
de la entidad.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
40
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Architecture
Management):
✓ Definir el nivel de estandarización en toda la organización.
✓ Definir el nivel de integridad en toda la organización.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Strategy Management for IT Services.
➢ (CAT.1.CRI.7) Apoyo de TI a los procesos: la dirección de TI cuenta con proceso de
identificación de necesidades de sistematización y apoyo tecnológico para los procesos de la
empresa. Lineamiento: MAE.LI.AM.04 - Apoyo de TI a los procesos.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Architecture
Management):
✓ Diseño de la arquitectura de negocio como está definida en ITIL 4, identificando
las necesidades del negocio.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Strategy Management for IT Services.
• Categoría: (CAT.2) Arquitectura de Información:
➢ (CAT.2.CRI.1) Catálogo de componentes de información: la dirección de TI cuenta con un
catálogo de los componentes de información y un proceso de gestión del mismo.
Lineamiento: MAE.LI.AI.01 - Catálogo de los componentes de información.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Architecture
Management):
✓ La dirección de TI cuenta con un catálogo de los componentes de información
presentados en la capa lógica y física.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Strategy Management for IT Services.
➢ (CAT.2.CRI.2) Gestión de la arquitectura de información: la dirección de TI cuenta con un
proceso de gestión de la arquitectura de información. Lineamiento: MAE.LI.AI.02 -
Arquitectura de Información.
41
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Architecture
Management):
✓ La arquitectura de información se debe diseñar y gestionar con base a los
siguientes conceptos: completitud, precisión y accesibilidad.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Strategy Management for IT Services.
➢ (CAT.2.CRI.3) Marco de interoperabilidad: la dirección de TI cuenta con un proceso de
intercambio de la información con respecto al marco de interoperabilidad. Lineamiento:
MAE.LI.AI.03 - Marco de Interoperabilidad del Estado.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla
11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Architecture
Management):
✓ Definición de los procesos de gestión y distribución de la información que maneja
la empresa.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Strategy Management for IT Services.
➢ (CAT.2.CRI.4) Estructura de los datos maestro: la dirección de TI cuenta con una estructura
definida de los datos maestros. Lineamiento: MAE.LI.AI.04 – Datos Maestros.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes al subcriterio (Mejor práctica de ITIL 4: Architecture
Management):
✓ Definir estructuras de información para el almacenamiento de datos maestros
que cuenten con los siguientes conceptos: completitud, precisión y accesibilidad.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Strategy Management for IT Services.
➢ (CAT.2.CRI.5) Mapa de información: la dirección de TI cuenta con un modelo que refleje el
flujo de la información desde sus fuentes de datos hacia el resto de los sistemas de
información. Lineamiento: MAE.LI.AI.05 - Mapa de Información.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes al subcriterio (Mejor práctica de ITIL 4: Architecture
Management):
✓ Establecer un proceso para modelar un diagrama de componentes; especificando
a detalle el flujo de la información.
42
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Strategy Management for IT Services.
➢ (CAT.2.CRI.6) Manejo del lenguaje: la dirección de TI cuenta con un proceso para garantizar
el manejo del lenguaje común para el intercambio de información con otras entidades.
Lineamiento: MAE.LI.AI.06 -Lenguaje común de intercambio de información.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes al subcriterio (Mejor práctica de ITIL 4: Knowledge
Management):
✓ Definir una estructura de información adecuada, de forma tal de modo que los
interesados puedan entenderla, analizarla en un nivel ideal, de forma oportuna y
en su debido formato.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Knowledge Management.
➢ (CAT.2.CRI.7) Definición de lenguaje común: la dirección de TI cuenta con un proceso para
solicitar la inclusión de una definición al portal de Lenguaje común de intercambio de
información del Estado Colombiano. Lineamiento: MAE.LI.AI.06 -Lenguaje común de
intercambio de información.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Knowledge
Management):
✓ Adquisición de la información, incluyendo el desarrollo, captura, agrupación y
categorización de los datos no estructurados.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Knowledge Management.
➢ (CAT.2.CRI.8) Mecanismos de acceso a los componentes de información: la dirección de TI
cuenta con un proceso para diseñar los mecanismos que permitan el acceso a los
componentes de información. Lineamiento: MAE.LI.AI.07 - Canales de acceso a los
Componentes de información.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Architecture
Management):
✓ Al definir distribución de los sistemas de información, se especifica cuáles de estos
sistemas tienen acceso a las fuentes de datos.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Knowledge Management.
43
➢ (CAT.2.CRI.9) Uso de los mecanismos de acceso a la información: el proveedor de TI garantiza
que los mecanismos diseñados permitan el entendimiento, análisis y aprovechamiento de la
información. Lineamiento: MAE.LI.AI.07 - Canales de acceso a los Componentes de
información.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Architcture
Management):
✓ Garantizar que los recursos disponibles para la gestión de la información cuenten
con un alto nivel de usabilidad y además permitan generar vistas que sean útiles
para la toma de decisiones.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Strategy Management for IT Services.
➢ (CAT.2.CRI.10) Fuentes únicas de información: la dirección de TI garantiza la existencia de
fuentes únicas de información para que el acceso a los datos sea completo, confiable y
comparable. Lineamiento: MAE.LI.AI.08 - Fuentes unificadas de información.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Architecture
Management):
✓ Al diseñar la distribución de los sistemas de información, se estructura la
configuración de la información; de modo que pueda ser almacenada y publicada
en una base de datos para la organización completa, o una base de datos
distribuida en varios componentes de la empresa.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Strategy Management for IT Services.
➢ (CAT.2.CRI.11) Documentación de hallazgos: la dirección de TI cuenta con un proceso para
documentar los hallazgos asociados a los componentes de información. Lineamiento:
MAE.LI.AI.09 – Hallazgos en el acceso a los Componentes de información.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Monitoring
and Event Management):
✓ Identificar qué servicios, sistemas, CIs u otros componentes del servicio deben ser
monitoreados; y establecer la estrategia de monitoreo.
✓ Implementar y mantener el monitoreo, aprovechando tanto las características de
monitoreo nativas como el uso de herramientas creadas específicamente para la
actividad de monitoreo.
44
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Event Management.
➢ (CAT.2.CRI.12) Impacto de los hallazgos: la dirección de TI identifica el impacto de cada
hallazgo sobre los componentes de información. Lineamiento: MAE.LI.AI.09 – Hallazgos en el
acceso a los Componentes de información.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Monitoring
and Event Management):
✓ Establecer y mantener umbrales y otros criterios para determinar qué cambios se
tratarán como eventos; y elegir criterios para definir cada tipo de evento
(informativo, advertencia o excepción).
✓ Establecer y mantener políticas sobre cómo se debe manejar cada tipo de evento
detectado, esto con el fin de garantizar una gestión adecuada.
✓ Implementar procesos y automatizaciones requeridos para gestionar los
umbrales, criterios y políticas definidos.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Event Management.
➢ (CAT.2.CRI.13) Apertura de datos: el proveedor de TI cuenta con un proceso automático para
garantizar la creación y publicación de datos abiertos a partir de sistemas de información.
Lineamiento: MAE.LI.AI.10 – Apertura de datos.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Knowledge
Management):
✓ Proveer una estructura aproximada para definir, construir, reusar y compartir
información.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Knowledge Management.
• Categoría: (CAT.3) Arquitectura de Sistemas de Información
➢ (CAT.3.CRI.1) Arquitecturas de referencia: el proveedor de TI cuenta con un proceso para
garantizar que la definición y evolución de arquitecturas de referencia permitan diseñar
arquitecturas de solución bajo parámetros, patrones y atributos de calidad y, además, con
base a los principios de servicios digitales, definidos en el Manual de Gobierno digital.
Lineamiento: MAE.LI.ASI.01 – Arquitecturas de referencia de la entidad.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
45
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Architecture
Management):
✓ Diseñar la arquitectura de sistemas de información cómo están definidas en ITIL
4, integrando la arquitectura de información y de aplicaciones.
✓ Interpretar la arquitectura de negocio, para obtener los atributos de calidad.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Strategy Management for IT Services.
➢ (CAT.3.CRI.2) Arquitecturas de solución: la dirección de TI cuenta con un proceso para
garantizar la definición, documentación y actualización de las arquitecturas de solución según
dictámenes de las arquitecturas de referencia. Lineamiento: MAE.LI.ASI.02 – Arquitecturas de
solución de la entidad.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Software
Development and Management):
✓ Diseño, documentación y actualización de la arquitectura de solución.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Application Management.
➢ (CAT.3.CRI.3) Arquitecturas de solución: el proveedor de TI cuenta con un proceso para
garantizar la definición y actualización de las arquitecturas de solución según dictámenes de
las arquitecturas de referencia. Lineamiento: MAE.LI.ASI.02 – Arquitecturas de solución de la
entidad.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Software
Development and Management):
✓ Seguimiento de la arquitectura de solución.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Application Management.
➢ (CAT.3.CRI.4) Definición de la arquitectura de software: la dirección de TI es capaz de definir
y documentar la arquitectura de software de los sistemas de información y aplicaciones
identificando los componentes propios de las arquitecturas de referencia definidas.
Lineamiento: MAE.LI.ASI.03 – Arquitectura de software.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Software
Development and Management)
✓ Diseño, documentación y actualización de la arquitectura de solución.
✓ Diseño del prototipo de la solución (UI, CX, diseño del servicio, etc).
46
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Application Management.
➢ (CAT.3.CRI.5) Definición de la arquitectura de software: el proveedor de TI es capaz de
definir, documentar y suministrar la arquitectura de software de los sistemas de información
y aplicaciones identificando los componentes propios de las arquitecturas de referencia
definidas. Lineamiento: MAE.LI.ASI.03 – Arquitectura de software.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Software
Development and Management):
✓ Diseño, documentación y actualización de la arquitectura de solución.
✓ Diseño del prototipo de la solución (UI, CX, diseño del servicio, etc).
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Application Management.
➢ (CAT.3.CRI.6) Actualización del catálogo de sistemas de información: la dirección de TI
cuenta con un proceso para actualizar el catálogo de sistemas de información. Lineamiento:
MAE.LI.ASI.04 – Catálogo de sistemas de información.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Service
Catalogue Management):
✓ Publicación, edición y mantenimiento de las descripciones del servicio y el
producto y sus determinadas ofertas.
✓ Proveer diferentes vistas y niveles de detalle de las descripciones del catálogo de
servicios según el grupo de interés. Por ejemplo:
► Vista de Usuario: información en las ofertas de servicio que pueden ser
solicitadas, y/o provisión de detalles.
► Vista del Cliente: proveer información sobre el nivel de servicio, datos
financieros y desempeño del servicio.
► TI – Consumidor de TI: proveer información técnica, de seguridad y de
proceso para su uso en la prestación de servicios.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Service Catalogue Management.
➢ (CAT.3.CRI.7) Actualización del catálogo de sistemas de información: (si aplica) la dirección
de TI, dentro de una entidad cabeza de sector, cuenta con un proceso para actualizar el
catálogo de sistemas de información sectorial. Lineamiento: MAE.LI.ASI.04 – Catálogo de
sistemas de información.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
47
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Service
Catalogue Management):
✓ Publicación, edición y mantenimiento de las descripciones del servicio y el
producto y sus determinadas ofertas.
✓ Proveer diferentes vistas y niveles de detalle de las descripciones del catálogo de
servicios según el grupo de interés. Por ejemplo:
► Vista de Usuario: información en las ofertas de servicio que pueden ser
solicitadas, y/o provisión de detalles.
► Vista del Cliente: proveer información sobre el nivel de servicio, datos
financieros y desempeño del servicio.
► TI – Consumidor de TI: proveer información técnica, de seguridad y de
proceso para su uso en la prestación de servicios.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Service Catalogue Management.
• Categoría: (CAT.4) Arquitectura de Infraestructura Tecnológica:
➢ (CAT.4.CRI.1) Catálogo de los elementos de infraestructura: el proveedor de TI cuenta con
un catálogo de los elementos de infraestructura tecnológica y un proceso de gestión de este.
Lineamiento: MAE.LI.AIT.01 – Catálogo de elementos de infraestructura tecnológica.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: IT Assets
Management):
✓ Todo hardware dentro del catálogo de infraestructura debe tener un formato de
identificación.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Service Asset and Configuration Management.
➢ (CAT.4.CRI.2) Plataforma de interoperabilidad: el proveedor de TI cuenta con los elementos
necesarios que garanticen el intercambio de información con respecto al marco de
interoperabilidad. Lineamiento: MAE.LI.AIT.02 Plataforma de interoperabilidad.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4:
Infrastructure and Platform Management):
✓ La gestión de infraestructura y plataforma debe incluir la provisión de tecnología
necesaria para apoyar a las actividades que generan valor a la organización y sus
interesados.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Strategy Management for IT Services.
48
➢ (CAT.4.CRI.3) Establecimiento del tipo de nube: la dirección de TI cuenta con un portafolio
de clientes que le permite establecer el tipo de nube que se requiere adoptar. Lineamiento:
MAE.LI.AIT.03 – Acceso a servicios en la Nube.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio Mejor práctica de ITIL 4: IT Assets
Management):
✓ Los activos basados en computación en la nube deben ser asignados a diferentes
grupos o productos tal que se puedan gestionar los costos.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Service Asset and Configuration Management.
➢ (CAT.4.CRI.4) Gestión de requerimientos: el proveedor de TI cuenta con un proceso de
gestión de requerimientos para analizar e implementar el tipo de nube requerida por la
dirección de TI. Lineamiento: MAE.LI.AIT.03 – Acceso a servicios en la Nube.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Capacity and
Performance Management):
✓ Desempeño del servicio y planeación de capacidad
► Proceso de análisis de requerimientos de capacidad.
► Procesos de planeación de recursos y pronósticos de demanda.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Capacity Management.
➢ (CAT.4.CRI.5) Gestión de incidentes: el proveedor de TI tiene un proceso de gestión de
incidentes que garantice la correcta operación del servicio. Lineamiento: MAE.LI.AIT.04 –
Continuidad y disponibilidad de los Elementos de infraestructura.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Incident
Management):
✓ Deben incluir procesos formales para la gestión de incidentes, tales como:
► Técnicas de para realizar investigación y diagnósticos precisos de incidentes.
► Creación de scripts de recolección de información de los usuarios durante el
contacto inicial; con estos, se puede obtener directamente el diagnóstico y la
resolución de incidentes simples.
► Los procesos de investigaciones de incidentes más complejos requieren el
apoyo de expertos en el tema.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Incident Management.
49
• Categoría: (CAT.5) Arquitectura de Seguridad:
➢ (CAT.5.CRI.1) Trazabilidad y auditoría de los datos: la dirección de TI cuenta con criterios
necesarios para asegurar la trazabilidad y auditoria de creación, modificación o eliminación
de datos. Lineamiento: MAE.LI.AS.01 – Auditoria y trazabilidad de componentes de
información.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Information
Security Management):
✓ Revisión de control y proceso de auditoría.
✓ Procedimientos para el manejo de la seguridad de la información relacionada con
modificaciones.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Information Security Management.
➢ (CAT.5.CRI.2) Garantía de la correcta auditoría y trazabilidad: el proveedor de TI garantiza la
buena trazabilidad para la auditoria de creación, modificación o eliminación de datos.
Lineamiento: MAE.LI.AS.01 – Auditoria y trazabilidad de componentes de información.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Information
Security Management):
✓ Revisión de control y proceso de auditoría.
✓ Procedimientos para el manejo de la seguridad de la información relacionada con
modificaciones.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Information Security Management.
➢ (CAT.5.CRI.3) Protección y privacidad de los componentes de información: la dirección de TI
cuenta con un catálogo de información asociada con los responsables y políticas de protección
y privacidad de la información. Lineamiento: MAE.LI.AS.02 – Protección y privacidad de
Componentes de información.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Information
Security Management):
✓ Proceso de gestión de incidentes relacionados con la seguridad de la información.
✓ Proceso de gestión de identidad y acceso.
✓ Procedimientos para pruebas de penetración, escáner de vulnerabilidad, etc.
50
✓ Procedimientos para el manejo de la seguridad de la información relacionada con
modificaciones.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Information Security Management.
➢ (CAT.5.CRI.4) Protección y privacidad de los componentes de información: el proveedor de
TI cuenta con un catálogo de información asociado con los responsables y políticas de
protección y privacidad de la información. Lineamiento: MAE.LI.AS.02 – Protección y
privacidad de Componentes de información.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Information
Security Management):
✓ Proceso de gestión de incidentes relacionados con la seguridad de la información.
✓ Proceso de gestión de identidad y acceso.
✓ Procedimientos para pruebas de penetración, escáner de vulnerabilidad, etc.
✓ Procedimientos para el manejo de la seguridad de la información relacionada con
modificaciones.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Information Security Management.
➢ (CAT.5.CRI.5) Auditoria y trazabilidad de los sistemas de información: la dirección de TI
cuenta con un proceso para garantizar la trazabilidad de las acciones sobre los sistemas de
información. Lineamiento: MAE.LI.AS.04 – Auditoria y trazabilidad de los sistemas de
información.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Information
Security Management):
✓ Revisión de control y proceso de auditoría.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Information Security Management.
➢ (CAT.5.CRI.6) Auditoria y trazabilidad de los sistemas de información: el proveedor de TI
garantiza la buena trazabilidad de las acciones sobre los sistemas de información requerida
por la Dirección de TI. Lineamiento: MAE.LI.AS.04 – Auditoria y trazabilidad de los sistemas de
información.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Information
Security Management):
✓ Revisión de control y proceso de auditoría.
51
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Information Security Management.
➢ (CAT.5.CRI.7) Identificación y análisis de riesgos: el proveedor de TI cuenta con un proceso
para la identificación de componentes de tecnología altamente expuestos a riesgos que
afecten la seguridad de la información y/o la prestación de servicios de la entidad.
Lineamiento: MAE.LI.AS.05 – Análisis de Riesgos.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Information
Security Management):
✓ Proceso de gestión de riesgo.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Information Security Management.
➢ (CAT.5.CRI.8) Seguridad informática: el proveedor de TI cuenta con un proceso para diseñar
controles de seguridad informática para gestionar riesgos de disponibilidad, integridad y
confidencialidad de la información. Lineamiento: MAE.LI.AS.05 – Seguridad informática.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Information
Security Management):
✓ Proceso de gestión de incidentes relacionados con la seguridad de la información.
✓ Proceso de gestión de riesgo.
✓ Proceso de gestión de identidad y acceso.
✓ Procedimientos para pruebas de penetración, escáner de vulnerabilidad, etc.
✓ Procedimientos para el manejo de la seguridad de la información relacionada con
modificaciones.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Information Security Management.
• Categoría: (CAT.6) Arquitectura de servicios tecnológicos:
Dentro de esta categoría se integran fuentes del estado del arte del trabajo de Ruiz Aguilar (2016) y
lineamientos del marco de AE propuesto por el MinTIC (2019). Para ello, se especifican las fuentes
literarias del estado del arte (Ruiz Aguilar, 2016) y el lineamiento del marco de AE del cual se deriva el
criterio.
➢ (CAT.6.CRI.1) Definición de nivel de servicio de disponibilidad: la dirección de TI cuenta con
un proceso de gestión de niveles de servicio para definir, negociar y hacer seguimiento del
nivel de disponibilidad. Lineamiento: MAE.LI.AIT.04 – Continuidad y disponibilidad de los
52
Elementos de infraestructura. Fuentes literarias adicionales: “Business and Government
Organizations’ Adoption of Cloud Computing” (Charif & Awad, 2014) y
“CHALLENGES_FOR_ADOPTING_CLOUD-BASED SOFTWARE AS a SERVICE (SAAS) IN THE
PUBLIC SECTOR” (Janssen & Joha, 2011).
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Service Level
Management):
✓ Se debe construir un acuerdo de nivel de servicio de disponibilidad que evidencie
compromiso y discusión con el proveedor de nube. Asimismo, se debe crear un
acuerdo de nivel de servicio de disponibilidad con el cliente que contrata el
servicio, esto teniendo en cuenta lo pactado con el proveedor. Es importante que
dentro de estos acuerdos se atiendan las necesidades particulares de cada parte
involucrada.
✓ Se debe realizar un proceso de seguimiento continuo sobre el nivel de servicio de
disponibilidad acordada.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Service Level Management.
➢ (CAT.6.CRI.2) Gestión del nivel de servicio de disponibilidad: el proveedor de TI cuenta con
un proceso de gestión de la disponibilidad, para garantizar los objetivos de nivel de servicio
de disponibilidad acordados. Lineamiento: MAE.LI.AIT.04 – Continuidad y disponibilidad de
los Elementos de infraestructura. Fuentes literarias adicionales: “Business and Government
Organizations’ Adoption of Cloud Computing” (Charif & Awad, 2014) y
“CHALLENGES_FOR_ADOPTING_CLOUD-BASED SOFTWARE AS a SERVICE (SAAS) IN THE
PUBLIC SECTOR” (Janssen & Joha, 2011).
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Availability
Management):
✓ Negociación y acuerdo de objetivos alcanzables para la disponibilidad.
✓ Designar aplicaciones e infraestructura que pueden ofrecer los niveles de
disponibilidad requeridos.
✓ Proceso de monitoreo, análisis y reporte de disponibilidad.
✓ Planeación de mejoras de la disponibilidad.
✓ Se garantiza que los servicios y componentes sean capaces de recolectar la
información requerida para medir la disponibilidad.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Availability Management.
➢ (CAT.6.CRI.3) Definición del nivel de servicio de seguridad: la dirección de TI cuenta con un
proceso de gestión de niveles de servicio para definir, negociar y hacer seguimiento del nivel
de servicio de seguridad. Fuentes literarias adicionales: “Adoption and Use of Cloud
Computing in Small and Medium Enterprises in Kenya” (Kihara & Gichoya, 2013), “Business
53
and Government Organizations’ Adoption of Cloud Computing” (Charif & Awad, 2014),
“Factors affecting the adoption of integrated cloud-based e-health record in healthcare
organizations: a case study of Jordan” (Sulaiman & Magaireah, 2015) y “CHALLENGES FOR
ADOPTING CLOUD-BASED SOFTWARE AS A SERVICE (SAAS) IN THE PUBLIC SECTOR” (Janssen
& Joha, 2011).
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Service Level
Management):
✓ Se debe construir un acuerdo de nivel de servicio de seguridad que evidencie
compromiso y discusión con el proveedor de nube. Asimismo, se debe crear un
acuerdo de nivel de servicio de seguridad con el cliente que contrata el servicio,
esto teniendo en cuenta lo pactado con el proveedor. Es importante que dentro
de estos acuerdos se atiendan las necesidades particulares de cada parte
involucrada.
✓ Se debe realizar un proceso de seguimiento continuo sobre el nivel de servicio de
seguridad acordada.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Service Level Management.
➢ (CAT.6.CRI.4) Gestión del nivel de servicio de seguridad: el proveedor de TI cuenta con un
proceso de gestión de la seguridad para garantizar los objetivos de nivel de servicio relativos
a la seguridad. Lineamiento: MAE.LI.AS.03 – Seguridad y privacidad de los sistemas de
información. Fuentes literarias adicionales: “Adoption and Use of Cloud Computing in Small
and Medium Enterprises in Kenya” (Kihara & Gichoya, 2013), “Business and Government
Organizations’ Adoption of Cloud Computing” (Charif & Awad, 2014) y “Factors affecting the
adoption of integrated cloud-based e-health record in healthcare organizations: a case study
of Jordan” (Sulaiman & Magaireah, 2015).
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Information
Security Management):
✓ Gestión de eventos.
✓ Proceso de gestión de incidentes relacionados con la seguridad de la información.
✓ Proceso de gestión de identidad y acceso.
✓ Procedimientos para pruebas de penetración, escáner de vulnerabilidad, etc.
✓ Procedimientos para el manejo de la seguridad de la información relacionada con
modificaciones.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Information Security Management.
➢ (CAT.6.CRI.5) Definición de nivel de servicio de continuidad: la dirección de TI cuenta con un
proceso de gestión de niveles de servicio para definir, negociar y hacer seguimiento del nivel
de continuidad para el buen funcionamiento del servicio. Fuentes literarias adicionales:
54
“Privacy and Legal Issues in Cloud Computing – The SMME Position in South Africa” (Mujinga,
2013) y “CHALLENGES_FOR_ADOPTING_CLOUD-BASED SOFTWARE AS a SERVICE (SAAS) IN
THE PUBLIC SECTOR” (Janssen & Joha, 2011).
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Service Level
Management):
✓ Se debe construir un acuerdo de nivel de servicio de continuidad que evidencie
compromiso y discusión con el proveedor de nube. Asimismo, se debe crear un
acuerdo de nivel de servicio de continuidad con el cliente que contrata el servicio,
esto teniendo en cuenta lo pactado con el proveedor. Es importante que dentro
de estos acuerdos se atiendan las necesidades particulares de cada parte
involucrada.
✓ El acuerdo de nivel de servicio con el cliente debe definir los resultados y no
simplemente métricas operacionales. Esto puede lograrse balanceando
diferentes grupos de métricas, en especial el RPO, BIA y RTO.
✓ Se debe realizar un proceso de seguimiento continuo sobre el nivel de servicio de
continuidad acordada.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Service Level Management.
➢ (CAT.6.CRI.6) Gestión del nivel de servicio de continuidad: el proveedor de TI cuenta con un
proceso de gestión de la continuidad para garantizar los objetivos de nivel de servicio relativos
a la continuidad. Lineamiento: MAE.LI.AIT.04 – Continuidad y disponibilidad de los Elementos
de infraestructura. Fuente literaria adicional: “Privacy and Legal Issues in Cloud Computing -
The SMME Position in South Africa” (Mujinga, 2013).
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Service
Continuity Management):
✓ Proveer técnicas para la investigación de desastres y así tener diagnósticos más
precisos de estos.
✓ Los procesos de investigaciones de desastres más complejos requieren el apoyo
de expertos.
✓ Definir un plan de recuperación en el que se especifique cómo la organización se
puede recuperar de un desastre y cómo puede regresar a un estado de “pre-
desastre”, considerando las cuatro dimensiones de la gestión del servicio: (1)
Organizaciones y personas; (2) Información y tecnología; (3) Socios y proveedores;
(4) Procesos y cadena de valor.
✓ Establecer un plan de continuidad que abarque y garantice todas las definiciones
enunciadas y descritas en ITIL 4 (RTO, RPO y BIA).
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: IT Service Continuity Management.
55
➢ (CAT.6.CRI.7) Gestión de pruebas: el proveedor de TI debe contar con un proceso de gestión
de pruebas para asegurar la implementación de un plan de pruebas de continuidad para el
servicio de TI. Fuente literaria adicional: “Privacy and Legal Issues in Cloud Computing - The
SMME Position in South Africa” (Mujinga, 2013).
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes al subcriterio (Mejor práctica de ITIL 4: Service
Continuity Management):
✓ Definir un plan de pruebas que se ajuste al plan de recuperación ante desastres,
el cual cumpla con los objetivos de nivel de servicio.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: IT Service Continuity Management.
➢ (CAT.6.CRI.8) Definición de nivel de servicio de resiliencia: la dirección de TI cuenta con un
proceso de gestión de niveles de servicio para definir, negociar y hacer seguimiento los
objetivos de nivel de servicio de resiliencia.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Service Level
Management):
✓ Se debe construir un acuerdo de nivel de servicio de resiliencia que evidencie
compromiso y discusión con el proveedor de nube. Asimismo, se debe crear un
acuerdo de nivel de servicio de resiliencia con el cliente que contrata el servicio,
esto teniendo en cuenta lo pactado con el proveedor. Es importante que dentro
de estos acuerdos se atiendan las necesidades particulares de cada parte
involucrada.
✓ Se debe realizar un proceso de seguimiento continuo sobre el nivel de servicio de
resiliencia acordada.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Service Level Management.
➢ (CAT.6.CRI.9) Gestión de incidentes: el proveedor de TI cuenta con un proceso de gestión de
incidentes, para así garantizar la resiliencia propuesta en los objetivos del atributo de calidad.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Incident
Management):
✓ Se debe registrar y gestionar cada incidente para asegurar la resolución de este,
en un tiempo prudente y relacionado con las expectativas del cliente y usuario.
✓ Acordar, documentar y comunicar los tiempos de recuperación objetivos para que las expectativas del cliente y usuario sean realistas.
56
✓ Se debe contar con un mecanismo de priorización de incidentes que opere según el nivel de impacto sobre el negocio. En este orden de ideas, los de mayor impacto se deben resolver primero.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Incident Management.
➢ (CAT.6.CRI.10) Gestión de problemas: el proveedor de TI cuenta con un proceso de gestión
de problemas, para así garantizar la resiliencia propuesta en los objetivos del atributo de
calidad.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Problem
Management):
✓ Se debe contar con un proceso de detección y análisis de incidentes duplicados y
problemas recurrentes presentados por los usuarios, la mesa de ayuda y el equipo
técnico.
✓ Se cuenta con un proceso de análisis de tendencia sobre los incidentes históricos.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Problem Management.
• Categoría: (CAT.7) Entorno de las partes interesadas
➢ (CAT.7.CRI.1) Gestión de proveedores: la dirección de TI cuenta con un proceso de gestión de
proveedores que le permite negociar y acordar las responsabilidades contractuales para el
cumplimiento de la normatividad vigente en la prestación del servicio de TI.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Supplier
Management):
✓ Desarrollar, negociar, revisar, actualizar, finalizar y adjudicar los contratos con los
proveedores.
✓ Dado el caso que fallen las negociaciones, se debe diseñar un nuevo contrato,
actualizarlo o terminar el mismo.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Supplier Management.
➢ (CAT.7.CRI.2) Gestión de relaciones con el negocio: la dirección de TI cuenta con un proceso
de gestión de relaciones con el negocio que le permite recolectar y analizar los requerimientos
normativos que deben ser implementados para el servicio de TI.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
57
o Actividades correspondientes al subcriterio (Mejor práctica de ITIL 4: Architecture
Management):
✓ Elaborar la arquitectura del entorno, definiendo los aspectos políticos con
respecto al manual de GEL, para así recolectar y analizar los requerimientos
normativos.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Strategy Management for IT Services.
➢ (CAT.7.CRI.3) Gestión de requerimientos normativos: el proveedor de TI cuenta con un
proceso de gestión de requerimientos que le permite garantizar la implementación de los
requerimientos normativos de la dirección de TI.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Supplier
Management):
✓ Gestionar la entrega del desempeño en función del contrato establecido con la
dirección de TI.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Supplier Management.
• Categoría: (CAT.8) Entorno financiero
➢ (CAT.8.CRI.1) Gestión de los recursos financieros: la dirección de TI cuenta con un proceso de
gestión financiera de servicios de TI que le permite asegurar los recursos financieros para la
contratación del servicio de TI.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Service
Financial Management):
✓ Gestionar y proyectar los presupuestos de la organización para que estos puedan
ser utilizados para la contratación de servicios tecnológicos.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Financial Management for IT Services.
➢ (CAT.8.CRI.2) Gestión de acuerdos con el proveedor: la dirección de TI debe contar con un
proceso de gestión de proveedores que le permita negociar y acordar con el proveedor de TI
los costos de la prestación, soporte y mantenimiento del servicio de TI.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Service
Financial Management):
58
✓ Estimar los costos de la operación y los proyectos de forma anticipada para poder
realizar un debido seguimiento del presupuesto.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Financial Management for IT Services.
➢ (CAT.8.CRI.3) Análisis de factibilidad financiera: la dirección de TI debe realizar un análisis de
factibilidad financiera comparando la contratación del servicio en la nube con otras
posibilidades.
▪ (1) Subcriterio: nivel de factibilidad financiera (ver valore explicados en la tabla 13).
➢ (CAT.8.CRI.4) Gestión de relacionamiento del proveedor: el proveedor de TI cuenta con un
proceso de gestión de relaciones con el cliente para asegurare el cumplimiento de los
acuerdos comerciales y requerimientos para la prestación del servicio de TI.
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Supplier
Management):
✓ Alinear el contrato del servicio de TI con los acuerdos comerciales de la
organización.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Supplier Management.
➢ (CAT.8.CRI.5) Análisis del modelo de nube: la dirección de TI cuenta con un proceso de
análisis financiero para la decisión del modelo de nube que se requiera (en caso de que el
servicio sea nuevo).
▪ (1) Subcriterio: nivel de cubrimiento de actividades (ver valores explicados en la tabla 11).
o Actividades correspondientes del subcriterio (Mejor práctica de ITIL 4: Service
Financial Management):
✓ Realizar un análisis financiero y comparativo sobre los costos de cada proveedor;
estos deben estar ajustados al presupuesto acordado para el proyecto.
▪ (2) Subcriterio: nivel de madurez del proceso (ver valores en la tabla 12).
o Proceso a evaluar ITIL v3: Financial Management for IT Services.
➢ (CAT.8.CRI.6) Beneficio en liquidez: la dirección de TI cuenta con un proceso para analizar el
beneficio en términos de liquidez con la inclusión de computación en la nube.
▪ (1) Subcriterio: beneficio en liquidez (ver valores explicados en la tabla 15).
59
5.3. EJEMPLO DE APLICACIÓN DEL MARCO METODOLÓGICO DE ADOPCIÓN DE SERVICIOS EN
LA NUBE A continuación, a modo de ejemplo, se presenta una evaluación de los criterios (CAT.6.CRI.1) y
(CAT.6.CRI.2). Estos pertenecen a la categoría (CAT.6) Arquitectura de servicios tecnológicos, y
derivados del lineamiento “MAE.LI.AIT.04 – Continuidad y disponibilidad de los elementos de
Infraestructura” y de otras fuentes del estado del arte de la primera versión del marco de evaluación.
Criterio Actividades identificadas de ITIL 4 Proceso de ITIL v3 para medir el nivel de madurez
La dirección de TI cuenta con un proceso de gestión de niveles de servicio para definir, negociar y hacer seguimiento del nivel de disponibilidad.
➢ Se debe construir un acuerdo de nivel de servicio de disponibilidad que evidencie compromiso y discusión con el proveedor de nube. Asimismo, se debe crear un acuerdo de nivel de servicio de disponibilidad con el cliente que contrata el servicio, esto teniendo en cuenta lo pactado con el proveedor. Es importante que dentro de estos acuerdos se atiendan las necesidades particulares de cada parte involucrada.
➢ Se debe realizar un proceso de seguimiento continuo sobre el nivel de servicio de disponibilidad acordada.
Service Level Management
El proveedor de TI cuenta con un proceso de gestión de la disponibilidad, para garantizar los objetivos de nivel de servicio de disponibilidad acordados.
➢ Negociación y acuerdo de objetivos alcanzables para la disponibilidad.
➢ Designar aplicaciones e infraestructura que pueden ofrecer los niveles de disponibilidad requeridos.
➢ Proceso de monitoreo, análisis y reporte de disponibilidad. ➢ Planeación de mejoras de la disponibilidad. ➢ Se garantiza que los servicios y componentes sean capaces de
recolectar la información requerida para medir la disponibilidad.
Availability Management
Tabla 16. Criterios, actividades y procesos definidos para la ejemplificación de la aplicación del marco metodológico de adopción de servicios en la nube.
En la tabla 16 se definen las actividades que le corresponden a cada criterio definido para esta
ejemplificación y los procesos los que se requiere medir el nivel de madurez según el modelo de ITIL
(ver tabla 12). Las actividades definidas son de gran utilidad en la evaluación del subcriterio de nivel
de cubrimiento ya que estas les otorgan el valor correspondiente a las variables “Total de actividades”.
Con esta información, y teniendo en cuenta que las entradas restantes para cada subcriterio dependen
exclusivamente de la entidad evaluada, se presenta el ejemplo del marco de metodología aplicado
sobre estos dos criterios en seguida en la Tabla 17:
Actor Criterio de evaluación
Subcriterio 1: % de cubrimiento de actividades Subcriterio 2: Nivel de madurez del proceso
Total de actividade
s
Actividades
cubiertas
% de cubrimie
nto de actividad
es
Puntos obtenid
os
Nivel de madurez
del proceso
Puntos obtenid
os
Puntaje total del criterio
de evaluació
n
(CAT.6) Dirección
de TI
(CAT.6.CRI.1) La dirección de TI cuenta con un proceso de gestión de niveles de servicio para definir, negociar y hacer seguimiento
2 2 100 100
Nivel 4: gestiona
do (preventi
vo)
80 90
60
del nivel de disponibilidad.
Proveedor de TI
(CAT.6.CRI.1) El proveedor de TI cuenta con un proceso de gestión de la disponibilidad, para garantizar los objetivos de nivel de servicio de disponibilidad acordados.
5 5 100% 100
Nivel 4: gestiona
do (preventi
vo)
80 90
Tabla 17. Ejemplificación de la aplicación del marco metodológico de adopción de servicios en la nube para dos criterios.
6. APLICACIÓN DEL NUEVO MARCO METODOLÓGICO DE ADOPCIÓN DE SERVICIOS
EN LA NUBE EN EMPRESAS DEL SECTOR PÚBLICO En la sección 4.2.1 fue descrita la estructura organizacional de la entidad evaluada. Del mismo modo
en la sección 4.2.3 se encuentra la aplicación de la primera versión del marco de evaluación para la
adopción de servicios en la nube propuesto por Ruiz (2016). Ahora, con la versión actualizada de este
mismo marco, se hizo nuevamente la aplicación sobre la misma empresa para evaluar la viabilidad de
adopción de servicios en la nube (para observar a mayor detalle la aplicación de este marco ver el
'anexo C’ llamado “Aplicación de la segunda versión del marco para la viabilidad de adoptar servicios
en la nube en entidades públicas”).
6.1 RESULTADOS DE LA APLICACIÓN DEL NUEVO MARCO DE EVALUACIÓN PARA LA
ADOPCIÓN DE SERVICIOS EN LA NUBE
6.1.1. Categoría de Arquitectura Misional
o Por un lado, el resultado general de esta categoría es de, aproximadamente, 71 puntos. Esta
cifra se debe principalmente a la influencia del nivel de cubrimiento asociado a los criterios
CAT.1.CRI.4 y CAT.1.CRI.6 ya que sólo cuentan con una actividad, entonces, de no cumplirse
el puntaje pasa a 0 puntos; lo que a su vez afecta el promedio general.
o Por otro lado, se observa que el nivel de madurez en todos los criterios no es inferior a cuatro
(proceso gestionado); lo que indica que los procesos relacionados con la estrategia de la
empresa están totalmente definidos, son monitoreados y están mayormente alineados con el
plan estratégico general del negocio.
o Ahora, con respecto a las actividades no cubiertas es posible identificar que: no existe una
distribución de los planes operacionales y tácticos a cada unidad de negocio (UN) en la
empresa, el portafolio de productos no se basa en marcos de referencia ya establecidos y la
arquitectura de negocio no sigue, todavía, ligada a la propuesta de ITIL 4. Considerando este
escenario, se sugiere destinar esfuerzos en elevar el nivel de estandarización de la entidad
para que, de esta forma, las decisiones estratégicas (como la migración de servicios a la nube)
puedan ser tomadas con base a la realidad más general de la empresa.
61
6.1.2. Categoría de Arquitectura de Información
o El puntaje global de la categoría fue alrededor de 76. Por un lado, se mantuvo el uso del
promedio de los criterios para la obtención del total de la categoría. Por otro lado, a nivel
general de los criterios, pues la empresa no contaba con dos criterios con puntajes de 0 y 40.
Estos, corresponden a los criterios relacionados con los canales de acceso a la información y
la documentación de hallazgos asociados a los componentes de información. En
consecuencia, el puntaje se vio afectado por esto.
o Ahora, el subcriterio de nivel de cubrimiento fue totalmente cubierto en el 84,62% de los
criterios evaluados. Por tanto, tanto la empresa como el proveedor cuentan con los procesos
y actividades necesarios para migrar el servicio a la nube, en cuanto a la capa de información.
o Por último, está el subcriterio de madurez del proceso, en este el promedio de madurez de
los procesos en esta categoría fue de 3,30. Puesto que la gran mayoría de los procesos
presentaban un nivel 3 del proceso (definido), algunos otros presentaban un nivel 4
(gestionado), uno era un proceso optimizado y se observó un proceso en ausencia (nivel 0).
Por consiguiente, se evidencia el motivo por el cual la categoría no obtuvo un puntaje global
mayor a 90; pues a pesar de que cuentan con la gran mayoría de procesos, les hace falta
mejorar la madurez de los mismos (en especial en los criterios relacionados con el acceso a
los datos y la documentación de hallazgos asociados a los componentes de información).
6.1.3. Categoría de Arquitectura de Sistemas de Información
o Para esta categoría se identifica un puntaje global, aproximado, de 85 puntos. Esta cifra se
debe, principalmente, al excelente nivel de cubrimiento que maneja la entidad: cinco de los
seis criterios reflejan una completitud del 100%. Además, este también indica que existe una
gran coordinación entre el proveedor de TI y la dirección de TI en la definición,
implementación y gestión de las arquitecturas de solución y software y de los sistemas de
información.
o Ahora, la única actividad no cubierta corresponde a la definición de sistemas de información
bajo los estándares definidos en ITIL 4, lo cual es lógico al considerar el poco tiempo que lleva
esta edición del marco en el mercado.
o Por último, con respecto al nivel de madurez se identifica que el promedio es cuatro, lo que
indica que la mayoría de los procesos están definidos, gestionados, monitoreados y
direccionados a la prevención.
6.1.4. Categoría de Arquitectura de Infraestructura Tecnológica
o En esta categoría, el puntaje obtenido fue de 64; un resultado no muy favorable para la
evaluación de adopción de servicios en la nube. No obstante, este puntaje se debe
(únicamente) a un criterio relacionado con el proveedor de nube. Puesto que el proveedor
evaluado no cuenta con un proceso de gestión de incidentes.
o Por un lado, se encuentra el nivel de cubrimiento de actividades para los criterios de esta
categoría. Observando de forma general, todos los criterios tuvieron un nivel total de
cubrimiento a excepción de uno, el criterio relacionado con la gestión de incidentes. De este
modo, se muestra la completitud de procesos con los que cuenta la empresa.
o Por otro lado, está el nivel de madurez de los procesos relacionados con el criterio. Pues en
este subcriterio, el promedio de nivel que se muestra es de un proceso repetitivo. Puesto que
la gran mayoría de los criterios muestran entre un nivel dos y tres de madurez, un criterio
mostró un nivel de ausencia (nivel 0) y sólo se evidenció uno con un nivel gestionado. Además,
cabe aclarar que el único proceso con un nivel de madurez de cuatro corresponde a la
62
dirección de TI. No obstante, el criterio que tuvo mayor incidencia sobre el puntaje de esta
categoría (el criterio relacionado con el control de incidentes) que tuvo un nivel de cero.
6.1.5. Categoría de Arquitectura de Seguridad
o El puntaje general de la categoría es de 87 puntos, el cual se deriva del buen nivel de
cubrimiento en las actividades asociadas a cada criterio ya que se evidencia un promedio, en
este subcriterio, de 94%. La anterior cifra indica que la entidad cuenta con un buen proceso
de gestión de la seguridad en términos de protección de la información y mantenimiento de
procesos de trazabilidad y auditoría. Adicionalmente, con esta cifra se evidencia el alto interés
que tiene CEDENAR por contar con los mejores estándares de seguridad posibles y, por ende,
de migrar sus servicios a la nube, será necesario mantener los niveles actuales o, de ser
posible, mejorarlos.
o Sin embargo, también se identifica a través del nivel de cubrimiento que no se realizan
procesos para desarrollar pruebas de penetración o análisis de vulnerabilidad, es decir, sólo
se garantiza la implementación de métodos de prevención ante ataques más no se realiza una
prueba de los mismos. Esta situación, de acuerdo con la información suministrada durante la
evaluación, se debe a que las metodologías de seguridad utilizadas ya han sido probadas en
numerosos esquemas de información similares.
o Por último, se visualiza que el nivel de madurez promedio de la categoría es de cuatro, lo que
indica un buen manejo de los procesos.
6.1.6. Categoría de arquitectura de servicios tecnológicos
o Esta categoría tuvo un puntaje de 72 demostrando cómo la empresa gestiona los niveles de
servicio tecnológicos. Este puntaje se debe a que la gran mayoría de criterios tuvieron un
puntaje alto, salvo por dos que están relacionados con la gestión de la continuidad y la
resiliencia del proveedor de TI.
o Si bien, el subcriterio de nivel de cubrimiento fue de cobertura total para el 70% de los criterios
evaluados. Sin embargo, solo los criterios relacionados con la gestión de la continuidad y uno
asociado a la resiliencia de incidentes (CAT.6.CRI.10) tuvieron un nivel de cubrimiento menor
al 80%. Por ende, se cuenta con el suficiente número de actividades de esta categoría.
o Ahora bien, con respecto al subcriterio de nivel de madurez del proceso, el nivel promedio de
los procesos evaluado fue de tres (proceso definido). Pues, se presentan procesos con un nivel
optimizado (CAT.6.CRI.2 y CAT.6.CRI.5), y otros como procesos definidos. No obstante, hubo
dos criterios relacionados con la resiliencia del servicio presentaron niveles de madurez de
madurez en caos (CAT.6.CRI.9) y en inicial (CAT.6.CRI.10), lo que muestra que necesitan
plantear procesos relacionados con la capacidad de recuperarse ante incidentes y reforzar los
que se relacionan con la gestión de problemas.
6.1.7. Entorno de las partes interesadas
o Para esta categoría se evidencia un puntaje global de 90 puntos, el cual se debe a que ambos
subcriterios evaluados presentan un promedio ideal: 100% (nivel de cubrimiento) y nivel 4
(nivel de madurez). Sobre este escenario se afirma que la gestión de proveedores y relaciones
y la gestión de requerimientos normativos se cumple correctamente en la entidad.
6.1.8. Entorno financiero
o El puntaje global obtenido en esta categoría fue de 98 puntos, siendo esta la categoría de
mayor puntaje. De este modo, se evidencia que el aspecto financiero para la realización del
proyecto de migrar el servicio a la nube no presenta grandes inconvenientes.
63
o En primer lugar, está el subcriterio de nivel de cubrimiento de actividades. Pues en esta
categoría todos los criterios estaban totalmente cubiertos. Por tanto, la empresa cuenta con
las debidas actividades financieras para la realización del proyecto.
o En segundo lugar, está el subcriterio de nivel de madurez del proceso, en cual todos los
procesos eran optimizados salvo uno que era gestionado (CAT.8.CRI.4). Por ende, tanto las
actividades como el nivel de madurez eran óptimos para la implementación del proyecto.
o En tercer lugar, está el subcriterio de factibilidad financiera, que tuvo como resultado un nivel
factible. Pues al hacer el análisis financiero de contratar servicios en la nube de
almacenamiento y procesamiento, el costo de adoptar estos servicios de nube resultó
comparativamente menor que el costo de comprar infraestructura propia. Por ende, la razón
entre estos (PACI/CSN) fue de 44 evidenciando que es menos costoso adoptar servicios de
nube.
o En cuarto y último lugar, está el beneficio de liquidez que (al igual que la factibilidad financiera)
tuvo un resultado de 100 puntos. Esto se debe, a que la compra de contratar servicios en la
nube (procesamiento y almacenamiento) el primer mes representa el 0,58% del presupuesto
asignado para el proyecto. Por tanto, al contratar servicios de computación en la nube se
obtiene una liquidez del 99,42% del presupuesto para uso de la empresa.
6.1.9. Resultados globales de la aplicación
Después de haber aplicado la segunda versión del marco metodológico para evaluar la viabilidad de
adoptar servicios en la nube, se obtuvo un resultado global de ochenta y un (81) puntos. Por
consiguiente, de acuerdo con el puntaje mínimo de aceptación (75 puntos), se considera que es viable
adoptar servicios de computación en la nube para hacer la migración del servicio de Portal Web de la
entidad.
6.2 CONCLUSIONES DE LA APLICACIÓN DEL NUEVO MARCO DE EVALUACIÓN PARA LA
ADOPCIÓN DE SERVICIOS EN LA NUBE Ahora bien, después de haber aplicado la nueva versión del marco metodológico para evaluar la
viabilidad de adoptar servicios en la nube, y de acuerdo con las sugerencias planteadas desde el área
financiera y de tecnología (involucradas en la evaluación), se destacan las siguientes conclusiones:
• A partir del análisis de cubrimiento de actividades de cada criterio evaluado se identificó que
implementar elementos de ITIL 4 es adecuado para evaluar el nivel de actualización en
términos tecnológicos y organizacionales de las entidades públicas. Por consiguiente, se
evidencia que las empresas de carácter público no están actualizadas ni regidas a estándares
y marcos de referencia de gestión tecnológica (como lo es ITIL).
• El proceso de realizar la aplicación fue más rápido. Por un lado, se tenían las actividades del
subcriterio de nivel de cubrimiento dentro de la misma plantilla de Excel; puesto que en la
primera aplicación no se tenían explícitos y por ende durante la aplicación se presentaban
confusiones. Por otro lado, se modificó el formato de las plantillas de Excel para agilizar el
proceso, pues ahora se dispuso de celdas para marcar las actividades cubiertas y los resultados
se calculaban con fórmulas de Excel ya predefinidas.
• El cambio en la fórmula de la factibilidad financiera y la incorporación del subcriterio de
beneficio en liquidez aportaron valor a la categoría de entorno financiero, pues el puntaje
global fue considerablemente mayor. De este modo, se logra comprender de mejor forma el
valor generado (hablando en términos financieros) de adoptar servicios de computación en la
nube
64
• El marco se queda corto en la evaluación específica del manejo de estructuras de datos, es
decir, sólo se apega a los lineamientos del MinTIC de la categoría de Arquitectura de
Información. Sin embargo, un punto clave en la migración de servicios a la nube es investigar
cómo se manejan los datos de forma específica: qué tipo de bases de datos, cuantas
relaciones, cuantas dependencias, cuantos registros anuales se ingresan, cuantos registros
hay, entre otros. Lo anterior pensando en servicios más complejos: gestión administrativa,
gestión de personal, recaudos, etc.
• Al aplicar la segunda versión del marco para evaluar la conveniencia de adoptar servicios en
la nube, se obtuvo un mayor puntaje global con respecto a la aplicación de la primera versión.
El resultado de la aplicación de la segunda versión fue de ochenta y un (81) puntos, mientras
que el de la primera versión fue de setenta y siete (77). No obstante, a pesar de que en ambas
aplicaciones resultó viable la adopción de servicios de computación en la nube (con base al
puntaje mínimo de aceptación), fue más evidente con la segunda aplicación sobre esta
empresa. En otras palabras, si se presentan cambios en el resultado de la aplicación.
7. CONCLUSIONES El trabajo realizado sobre el nuevo marco metodológico refleja la constante necesidad de realizar una
actualización y ampliación de las herramientas disponibles para evaluar el uso de TI en el sector
público. Con lo anterior como premisa, a largo del desarrollo del presente marco, se definió como
principio el hecho de que la primera versión del marco de evaluación, propuesto por John Ruiz (2016),
no es contemporánea con las normativas y prácticas presentes en el contexto actual. Por consiguiente,
fue necesario realizar un diagnóstico para determinar con exactitud el estado del marco de Ruiz para,
después, poder llevar a cabo una reestructuración que se adapte con la realidad presente. Para este
procedimiento de valoración se acudió a dos metodologías: (i) entrevista a experto y (ii) aplicación del
marco metodológico. Por un lado, el primer método tuvo lugar con la ayuda de John Jairo Ruiz, el
creador de la primera versión del marco de evaluación, a quien se le cuestionó acerca de sus
consideraciones sobre el trabajo que llevó a cabo y sobre qué mejoras potenciales se podrían incluir
de acuerdo con la experiencia académica y laboral que adquirió tiempo después. A partir de estos
cuestionamientos se logró identificar que, en principio, el marco de metodología no abarcó el total de
los dominios manejados por el documento de Arquitectura Empresarial del MinTIC; sino que sólo se
realizó con base al ámbito de Servicios Tecnológicos. Además, se observó que los lineamientos
actuales propuestos por el Ministerio de las TICs, realizados en el documento mencionado
previamente, no son coetáneos con los criterios de la primera versión del marco de evaluación.
Por otro lado, también se realizó una aplicación del marco de metodología a una entidad del sector
público (CEDENAR), sobre el servicio de Portal Web, con el fin de lograr un entendimiento más
profundo del mismo. Con respecto a esta metodología, se encontró que: en primer lugar, la primera
versión del marco de evaluación presenta una alta complejidad al estar definida en un formato tabular
de Excel, razón por la cual el ejercicio resultó un poco tedioso (ya que los cálculos de los puntajes se
hacían de forma manual). En segundo lugar, la primera versión del marco de evaluación carecía de un
análisis robusto en el ámbito financiero, lo que inhibía la incorporación de un estudio sobre otros
beneficios que conlleva la adopción de servicios en la nube. Adicionalmente, se identificó un error en
la fórmula de los valores posibles del criterio de “factibilidad financiera” ya que, con base en la forma
como estaba definida, la migración era más factible si el costo de contratar servicios en la nube era
más alto que el de comprar infraestructura propia. En tercer y último lugar, se observó que la primera
versión del marco de evaluación presenta varios criterios con errores de redacción, lo que hizo más
difícil la aplicación del marco metodológico.
65
Después de haber realizado el diagnóstico sobre el marco de metodología e identificado sus fallas, se
llevó a cabo un rediseño del mismo. Para este cambio se tuvieron en cuenta dos perspectivas:
alteraciones sobre la estructura y sobre el contenido. Para el primer escenario, se consideró que el
esqueleto del marco no presenta inconvenientes en su primera versión, por consiguiente, se conservó
igual: (i) categoría, (ii) criterio, (iii) subcriterio y (iv) valores posibles. Ahora, para el contenido del
marco de metodología si se realizó un proceso de redefinición sustancial, en el cual un primer cambio
consistió en la derivación de los criterios a partir de los lineamientos de la última versión de los
lineamientos del marco de referencia del MinTIC (2019). Además, se integró los criterios asociados a
la arquitectura de información, arquitectura de sistemas de información y arquitectura misional, lo
que hace del nuevo marco de metodología propuesto una solución más completa al valorar los
conceptos de aquellos dóminos que fueron excluidos en la primera versión del marco de evaluación.
Un tercer cambio radicó en la inclusión de actividades y mejores prácticas provenientes marco de
referencia de ITIL 4 para evaluar el subcriterio de cubrimiento de actividades. Asimismo, para la
evaluación del nivel de madurez, se realizó un mapeo entre los procesos de ITIL v3 y las mejores
prácticas de ITIL 4, para que así sea viable utilizar el modelo de madurez de ITIL (ITIL, 2013).
Adicionalmente, en la categoría de entorno financiero de la primera versión del marco de evaluación,
se adaptó la fórmula de los valores posibles del criterio de “factibilidad financiera”, haciendo el criterio
más factible mientras más bajo sea el costo de adquirir servicios de computación en la nube. De igual
modo, se añadió otro criterio (con nuevos valores posibles) para determinar el beneficio en liquidez
al adoptar servicios de nube. Por último, se replanteó el valor mínimo de aceptación de la migración
para evitar los problemas asociados al sesgo que se presenta al calcular el promedio global del marco.
En resumidas cuentas, se mantuvo la estructura de la primera versión del marco de evaluación, sin
embargo, sí se modificó el contenido de los criterios, las actividades y los procesos para que el marco
metodológico se adecué al contexto empresarial actual y abarque más normativas del marco de AE
del MinTIC.
Una vez rediseñado el marco metodológico para evaluar la viabilidad de contratar servicios en la nube
en entidades públicas, se realizó una nueva aplicación, para mismo servicio (Portal Web), en la misma
empresa en la que se hizo la primera evaluación. Para esta nueva versión, se elaboró una nueva
plantilla para simplificar la complejidad de la aplicación. Dentro de esta, se incluyeron las actividades
que serían evaluadas para medir el subcriterio de nivel de cubrimiento para cada criterio y, además,
los puntajes ya eran calculados automáticamente por medio de fórmulas condicionales de Excel. De
este modo, se ejecutó exitosamente la segunda evaluación de adopción de servicios en la nube; en la
que el resultado final concluyó como factible que la entidad migre a la computación en la nube para
el servicio seleccionado.
Ahora bien, al realizar una comparación entre las aplicaciones realizadas con cada versión del marco
de evaluación, es posible identificar ciertos factores. En principio, la plantilla utilizada para la
evaluación del nuevo marco se caracteriza por una mayor usabilidad en comparación con la primera
versión, puesto que la aplicación para esta nueva adaptación del marco fue más rápida y sencilla. Un
segundo aspecto diferenciador corresponde a la adopción de las mejores prácticas de ITIL 4 en el
nuevo marco de evaluación. No obstante, esta inclusión generó un leve retraso en la aplicación del
marco debido a que esta versión del estándar es muy reciente en el mercado y la organización aún no
está capacitada en los cambios estructurales y de terminología en el estándar. Por ejemplo, la
transición de procesos a mejores prácticas fue un aspecto del que no se tenía mucho conocimiento.
Lo anterior llevó a que se realizara una breve sesión de explicación de los principales hallazgos de la
nueva versión de ITIL. El tercer aspecto se relaciona con la evaluación financiera del marco ya que con
la fórmula de la factibilidad financiera corregida y la inclusión del beneficio en liquidez. Sin embargo,
en la aplicación del marco con la entidad del cliente, se identificó que el último factor radica en que
66
fuera de la actualización del contenido, no se aportó más valor con respecto a la primera versión del
marco de evaluación. Lo anterior se debe a que a pesar de que en el planteamiento del diagnóstico se
identificaron más puntos críticos, que podrían hacer del marco una solución más completa, no se
implementaron por cuestiones de tiempo del proyecto.
Para finalizar, con respecto al marco de evaluación, se recomienda que en proyectos futuros se
efectúen los siguientes cambios: (i) desarrollar una herramienta de software que automatice el
proceso de evaluación, como por ejemplo un servicio Web, y que además sea capaz de generar un
informe de resultados; este punto se propone debido a que el uso de plantillas de Excel no es lo
suficientemente eficiente en términos de tiempo; (ii) buscar una forma de ponderar los criterios y/o
categorías para así obtener resultados más precisos con respecto a la decisión de contratar servicios
de nube, esto debido a que hay criterios que tienen mayor impacto sobre la decisión de contratar
servicios en la nube; (iii) diseñar una estructura que incluya un preanálisis en el cual se evalúen
aspectos como la complejidad del proyecto o la madurez del servicio, ya que con estos instrumentos
se pueden estructurar prerrequisitos, que de no cumplirse, ya no harían factible la migración a la nube;
y (iv) introducir criterios que se relacionen con la gestión de las estructuras de datos de la entidad y la
forma detallada en cómo se lleva a cabo el flujo de información.
REFERENCIAS Amazon. (2020). AWS. Recuperado el 07 de Febrero de 2020, de ¿Qué es la informática en la nube?:
https://aws.amazon.com/es/what-is-cloud-computing/?nc1=h_ls
CEDENAR. (2020). CEDENAR. Recuperado el 08 de Mayo de 2020, de Mapa de Procesos:
https://www.cedenar.com.co/webcedenar/mapa-de-procesos/
Charif, B., & Awad, A. I. (2014). Business and Government Organizations’ Adoption of Cloud
Computing. Qena. Recuperado el 28 de Abril de 2020
Escudero Macluf, J., Delfín Beltrán, L. A., & Arano Chávez, R. M. (2014). EL DESARROLLO
ORGANIZACIONAL Y LA RESISTENCIA AL CAMBIO EN LAS. IIESCA. Recuperado el 11 de Mayo
de 2020, de https://www.uv.mx/iiesca/files/2014/09/01CA201401.pdf
Fisher, C. (2018). Cloud versus On-Premise Computing. Cambridge: American Journal of Industrial
and Business Management.
IBM. (2019). IBM. Recuperado el 12 de Febrero de 2020, de Computación en la nube: Una guía
completa: https://www.ibm.com/privacy/co/es/?lnk=flg-priv-ares
ITIL. (2013). ITIL Maturity Model and Self-assessment Service User Guide. Axelos. Recuperado el 07
de Mayo de 2020, de
https://www.axelos.com/Corporate/media/Files/Misc%20Qualification%20Docs/ITIL-
maturity-model-self-assessment-service-user-guide.pdf
ITIL. (2019). ITIL Foundation ITIL 4 Edition. Norwich: The Stationary Office. Recuperado el 29 de Abril
de 2020
Jain, M. (29 de 05 de 2019). How Perficient are Cloud Deployment Models for N/W Storage Needs?
Obtenido de https://www.konstantinfo.com/blog/cloud-deployment-models/
67
Janssen, M., & Joha, A. (2011). CHALLENGES FOR ADOPTING CLOUD-BASED SOFTWARE AS A SERVICE
(SAAS) IN THE PUBLIC SECTOR. ECIS. Recuperado el 28 de Abril de 2020, de
https://pdfs.semanticscholar.org/1487/a77ac26c155e93af30664a85bc0cc7072fcf.pdf
Kihara, T., & Gichoya, D. (2013). Adoption and Use of Cloud Computing in Small and Medium
Enterprises in Kenya. Narobi: IEEE. Recuperado el 28 de Abril de 2020
Mell, P., & Grance, T. (2011). The NIST Definition of Cloud Computing. NIST, Gaithersburg.
Recuperado el 17 de Febrero de 2020, de
https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf
MinTIC. (2018). Manual de gobierno digital. Recuperado el 20 de Febrero de 2020, de
https://estrategia.gobiernoenlinea.gov.co/623/articles-81473_recurso_1.pdf
MinTIC. (2019). Documento Maestro del Modelo de Arquitectura Empresarial. Recuperado el 24 de
Febrero de 2020, de https://www.mintic.gov.co/arquitecturati/630/articles-
9401_pdf_00.pdf
Mujinga, M. (2013). Privacy and Legal Issues in Cloud Computing - The SMME Position in South
Africa. Perth: Australian Information Security Management Conference.
doi:10.4225/75/57b5658ecd8e4
Rashid, A., & Chaturvedi, A. (Febebrero de 2019). Cloud Computing Characteristics and Services: A
Brief Review. doi:10.26438/ijcse/v7i2.421426
Red Hat. (2020). Red Hat. Recuperado el 07 de Febrero de 2020, de ¿Qué es un lago de datos?:
https://www.redhat.com/es/topics/data-storage/what-is-a-data-lake
Rountree, D., & Castrillo, I. (2013). The Basics of Cloud Computing Understanding the Fundamentals
of Cloud Computing in Theory and Practice. Syngress. Recuperado el 02 de Junio de 2020
Rouse, M. (Enero de 2006). NIST (National Institute of Standards and Technology). Recuperado el 15
de Febrero de 2020, de TechTarget:
https://searchsoftwarequality.techtarget.com/definition/NIST
Ruiz Aguilar, J. J. (2016). Marco para evaluar la conveniencia de adoptar servicios en la nube en
entidades públicas. Universidad de los Andes, Bogotá D.C. Recuperado el 20 de Febrero de
2020
Ruiz Aguilar, J. J. (24 de Febrero de 2020). Entrevista del marco de evaluación para la adopción de
servicios en la nube en entidades públicas. (J. R. Pacheco Gómez, & M. Saravia Salamanca,
Entrevistadores) Bogotá, Bogotá D.C, Colombia.
Salinas Montemayor, A. D. (2015). Factores Críticos que explican el grado de utilización de la Nube.
Universidad Autónoma de Nuevo León, Nuevo León. Recuperado el 12 de Febrero de 2020,
de http://eprints.uanl.mx/9244/1/1080215094.pdf
Sulaiman, H., & Magaireah, A. (2015). Factors affecting the adoption of integrated cloud-based e-
health record in healthcare organizations: a case study of Jordan. Putrajaya: IEEE.
doi:10.1109/ICIMU.2014.7066612
68
ANEXOS
ANEXO A. APLICACIÓN DE LA PRIMERA VERSIÓN DEL MARCO DE EVALUACIÓN PARA EVALUAR
LA CONVENIENCIA DE ADOPTAR SERVICIOS EN LA NUBE DE ENTIDADES PÚBLICAS.
69
Para la presentación de la aplicación de la primera versión del marco de evaluación se realiza con la nomenclatura respectiva de este marco, mostrada a continuación:
Subcriterio 1: % de cubrimiento de actividades Subcriterio 2: nivel de madurez del proceso
Subcriterio 3: nivel de factibilidad financiera
Categoría de evaluación
Actor Criterio de evaluación
Total de actividades
Actividades cubiertas
% de cubrimiento de actividades
Puntos obtenidos (1)
Nivel de madurez del proceso
Puntos obtenidos (2)
Nivel de factibilidad financiera
Puntos obtenidos (3)
Puntaje total del criterio
Cat_X. Nombre de la categoría de evaluación.
Nombre del actor.
Cri_X.Y. Descripción del criterio de evaluación.
Número total de actividades identificadas para el criterio.
Número de actividades con las que cuenta la empresa del criterio actual.
Porcentaje de actividades cubiertas con respecto al total de actividades.
Puntos obtenidos del subcriterio según los valores posibles de la tabla 3 (cubrimiento de actividades).
Nivel de madurez del proceso identificado de COBIT.
Puntos obtenidos del subcriterio según los valores posibles de la tabla 4 (nivel de madurez del proceso).
Resultado de la evaluación de factibilidad financiera según la fórmula de la tabla 5.
Puntos obtenidos de la evaluación de factibilidad financiera según los valores posibles de la tabla 5.
Resultado del promedio de los campos de puntos obtenidos (1), (2) y (3).
Subcriterio 1: % de cubrimiento de actividades
Subcriterio 2: nivel de madurez del
proceso
Subcriterio 3: nivel de factibilidad financiera
Categoria de evaluación
Actor Criterio de evaliación Total de
actividades Actividades
cubiertas
% de cubrimiento
de actividades
Puntos obtenidos
(1)
Nivel de madurez
del proceso
Puntos obtenidos
(2)
Nivel de factibilidad financiera
Puntos obtenidos
(3)
Puntaje total
(CRITERIO)
Puntaje total
Cat_1. Arquitectura de servicios tecnológicos
Dirección de TI
Cri_1.1. La Dirección de TI cuenta con un catálogo de servicios de TI y un proceso de gestión del catálogo
2 2 100% 100 4 80 N/A N/A 90.0
82
Cat_1. Arquitectura de servicios tecnológicos
Proveedor de TI
Cri_1.2. El proveedor de TI cuenta con un portafolio de servicios tecnológicos
2 2 100% 100 4 80 N/A N/A 90.0
Cat_1. Arquitectura de servicios tecnológicos
Dirección de TI
Cri_1.3. La dirección de TI cuenta con los procesos de gestión de requerimientos para la recolección, análisis y entrega de los requerimientos de intercambio de información del cliente al proveedor de TI para la adaptación del servicio de TI
2 2 100% 100 4 80 N/A N/A 90.0
Cat_1. Arquitectura de servicios tecnológicos
Dirección de TI
Cri_1.4. La dirección de TI cuenta con proceso de gestión del portafolio de clientes en el cual puede clasificar y vincular el catálogo de servicios con cada cliente (interno y externo)
2 2 100% 100 4 80 N/A N/A 90.0
Cat_1. Arquitectura de servicios tecnológicos
Dirección de TI
Cri_1.5. La dirección de TI cuenta dentro del proceso de gestión de proveedores con el manejo y seguimiento de los contratos y las condiciones técnicas y legales con las que deben cumplir junto con el proveedor de TI
2 2 100% 100 5 100 N/A N/A 100.0
Cat_1. Arquitectura de servicios tecnológicos
Proveedor de TI
Cri_1.6. El proveedor de TI cuenta con un proceso de gestión de requerimientos que le permite recibir, diseñar e implementar los requerimientos de la dirección de TI para el intercambio de información
3 3 100% 100 3 60 N/A N/A 80.0
Cat_1. Arquitectura de servicios tecnológicos
Dirección de TI
Cri_1.7. La dirección de TI cuenta con un proceso de gestión de la demanda que le permite establecer los requerimientos de capacidad para implementarel servicio de TI
3 3 100% 100 3 60 N/A N/A 80.0
Cat_1. Arquitectura de servicios tecnológicos
Dirección de TI
Cri_1.8. La dirección de TI cuenta con un proceso de gestión de niveles de servicio para hacer seguimiento durante la operación
2 1 50% 50 2 40 N/A N/A 45.0
al alcance de los objetivos de nivel de servicio acordados para la seguridad
Cat_1. Arquitectura de servicios tecnológicos
Dirección de TI
Cri_1.9. La dirección de TI cuenta con un proceso de gestión de niveles de servicio para hacer seguimiento durante la operación al alcance de los objetivos de nivel de servicio acordados para la disponibilidad
2 2 100% 100 5 100 N/A N/A 100.0
Cat_1. Arquitectura de servicios tecnológicos
Dirección de TI
Cri_1.10. La dirección de TI cuenta con un proceso de gestión de niveles de servicio para hacer seguimiento durante la operación al alcance de los objetivos de nivel de servicio acordados para la continuidad
2 2 100% 100 5 100 N/A N/A 100.0
Cat_1. Arquitectura de servicios tecnológicos
Proveedor de TI
Cri_1.11. El proveedor de TI cuenta con un proceso de gestión de la capacidad para garantizar el cumplimiento de los requerimientos de capacidad para implementar el servicio de TI
2 2 100% 100 4 80 N/A N/A 90.0
Cat_1. Arquitectura
Proveedor de TI
Cri_1.12. El proveedor de TI cuenta con el proceso
3 1 33% 33 4 80 N/A N/A 56.7
de servicios tecnológicos
de gestión de la seguridad para garantizar el cumplimiento de los objetivos de nivel de servicio de seguridad durante de la operación
Cat_1. Arquitectura de servicios tecnológicos
Proveedor de TI
Cri_1.13. El proveedor de TI cuenta con el proceso de gestión de la disponibilidad para garantizar el cumplimiento de los objetivos de nivel de servicio de disponibilidad durante de la operación
3 2 67% 67 4 80 N/A N/A 73.3
Cat_1. Arquitectura de servicios tecnológicos
Proveedor de TI
Cri_1.15. El proveedor de TI cuenta con el proceso de gestión de la continuidad para garantizar el cumplimiento de los objetivos de nivel de servicio de continuidad durante de la operación
3 3 100% 100 5 100 N/A N/A 100.0
Cat_1. Arquitectura de servicios tecnológicos
Dirección de TI
Cri_1.16. La dirección de TI cuenta con un portafolio de clientes que le permite identificar los clientes del servicio de TI y establecer el tipo de nube a
2 2 100% 100 5 100 N/A N/A 100.0
implementar para este servicio
Cat_1. Arquitectura de servicios tecnológicos
Proveedor de TI
Cri_1.17. El proveedor de TI cuenta con un proceso de gestión de requerimientos para analizar e implementar el tipo de nube requerida por la dirección de TI para el servicio de TI
1 1 100% 100 5 100 N/A N/A 100.0
Cat_1. Arquitectura de servicios tecnológicos
Dirección de TI
Cri_1.18. La dirección de TI cuenta con un proceso de gestión de proveedores que le permite negociar y acordar las responsabilidades y el cumplimiento de acuerdos con el proveedor para la implementación del plan de tecnología verde
2 2 100% 100 4 80 N/A N/A 90.0
Cat_1. Arquitectura de servicios tecnológicos
Dirección de TI
Cri_1.19. La dirección de TI cuenta con un proceso de gestión de requerimientos que le permite recolectar y analizar los requerimientos de tecnología verde para el servicio de TI
2 2 100% 100 3 60 N/A N/A 80.0
Cat_1.
Arquitectura de servicios tecnológicos
Proveedor de TI
Cri_1.18. El proveedor de TI cuenta con un proceso de gestión de
3 3 100% 100 3 60 N/A N/A 80.0
tecnología verde que le permite cumplir con los acuerdos y responsabilidades en la implementación de requerimientos de tecnología verde
Cat_1. Arquitectura de servicios tecnológicos
Proveedor de TI
Cri_1.19. El proveedor de TI cuenta con un proceso de gestión de tecnología verde que le permite garantizar la implementación de los requerimientos de tecnología verde de la dirección de TI
2 0 0% 0 0 0 N/A N/A 0.0
Sub-criterio 1: % de cubrimiento de actividades Sub-criterio 2: nivel
de madurez del proceso
Sub-criterio 3: nivel de factibilidad financiera
Categoría de
evaluación Actor Criterio de evaluación
Total de actividades
Actividades cubiertas
% de cubrimiento
de actividades
Puntos obtenidos
(1)
Nivel de madurez
del proceso
Puntos obtenidos
(2)
Nivel de factibilidad financiera
Puntos obtenidos
(3)
Puntaje total
(CRITERIO)
Puntaje total
Cat_2. Operación
de servicios tecnológicos
Dirección de TI
Cri_2.1. La dirección de TI cuenta con un proceso de gestión de proveedores que le permite negociar y acordar con el proveedor la prestación del servicio de TI con los sistemas de respaldo a la infraestructura.
2 2 100% 100 5 100 N/A N/A 100.0 83
Cat_2. Operación
de servicios tecnológicos
Proveedor de TI
Cri_2.2. El proveedor de TI cuenta con un proceso de gestión de requerimientos que le permite analizar e implementar los requerimientos de sistemas de respaldo a la infraestructura del servicio de TI
2 2 100% 100 5 100 N/A N/A 100.0
Cat_2. Operación
de servicios tecnológicos
Dirección de TI
Cri_2.3. La dirección de TI cuenta con un proceso de gestión de niveles de servicio que le permite negociar, definir y hacer seguimiento con el proveedor de TI a los objetivos de nivel de servicio para la disponibilidad las responsabilidades de las partes para el cumplimiento de estos objetivos
3 3 100% 100 5 100 N/A N/A 100.0
Cat_2. Operación
de servicios tecnológicos
Dirección de TI
Cri_2.4. La dirección de TI cuenta con un proceso de gestión de pruebas que le permite negociar y establecer con el proveedor de TI los criterios de aceptación de pruebas, el plan de pruebas y las responsabilidades del ciclo de vida de pruebas para la disponibilidad
2 2 100% 100 5 100 N/A N/A 100.0
Cat_2. Operación
de servicios tecnológicos
Proveedor de TI
Cri_2.5. El proveedor de TI cuenta con un proceso de gestión de pruebas que le permite asegurar el cumplimiento de los criterios de aceptación de pruebas para el modelo de alta disponibilidad y las responsabilidades acordadas en el plan de pruebas
3 3 100% 100 5 100 N/A N/A 100.0
Cat_2. Operación
de servicios tecnológicos
Proveedor de TI
Cri_2.6. El proveedor de TI cuenta con un proceso de gestión disponibilidad con mecanismos reactivos y proactivos que le permita atender, analizar y garantizar la alta disponibilidad de sus infraestructuras
2 1 50% 50 3 60 N/A N/A 55.0
Cat_2. Operación
de servicios tecnológicos
Dirección de TI
Cri_2.7. La dirección de TI cuenta con un proceso de gestión de la demanda que le permite establecer los requerimientos de capacidad actual y futura para el servicio de TI
3 1 33% 33 0 0 N/A N/A 16.7
Cat_2. Operación
de servicios tecnológicos
Proveedor de TI
Cri_2.8. El proveedor de TI cuenta con un proceso de gestión de la capacidad para garantizar el cumplimiento de los requerimientos de capacidad de recursos
2 2 100% 100 4 80 N/A N/A 90.0
compartidos para el servicio de TI
Sub-criterio 1: % de cubrimiento de actividades Sub-criterio 2: nivel
de madurez del proceso
Sub-criterio 3: nivel de factibilidad financiera
Categoría de
evaluación Actor Criterio de evaluación
Total de actividade
s
Actividades cubiertas
% de cubrimient
o de actividades
Puntos obtenido
s (1)
Nivel de madure
z del proceso
Puntos obtenido
s (2)
Nivel de factibilida
d financiera
Puntos obtenido
s (3)
Puntaje total
(CRITERIO)
Puntaje total
Cat_3. Soporte de los servicios tecnológico
s
Dirección de TI
Cri_3.1. La dirección de TI cuenta con un proceso de gestión de proveedores que le permite negociar y establecer las responsabilidades contractuales para el proceso de gestión de niveles de servicio
2 2 100% 100 5 100 N/A N/A 100.0
82
Cat_3. Soporte de los servicios tecnológico
s
Dirección de TI
Cri_3.2. La dirección de TI cuenta con un proceso de gestión de niveles de servicio que le permite negociar y establecer con los clientes (internos y externos) los objetivos de nivel de servicio
3 3 100% 100 4 80 N/A N/A 90.0
Cat_3. Soporte de los servicios tecnológico
s
Dirección de TI
Cri_3.2. La dirección de TI cuenta con un proceso de gestión de niveles de servicio que le permite negociar y establecer con el proveedor de TI los objetivos de nivel de servicio
2 1 50% 50 3 60 N/A N/A 55.0
Cat_3. Soporte de los servicios tecnológico
s
Proveedor de TI
Cri_3.2. El proveedor de TI cuenta con los procesos de gestión de los criterios de calidad establecidos con la dirección de TI para cumplir con los objetivos de nivel de servicio
3 3 100% 100 4 80 N/A N/A 90.0
Cat_3. Soporte de los servicios tecnológico
s
Dirección de TI
Cri_3.2. La dirección de TI cuenta con una mesa de servicios que le permite recibir y gestionar los incidentes, problemas y requerimientos de primer, segundo y tercer nivel del cliente (interno y externo)
2 2 100% 100 5 100 N/A N/A 100.0
Cat_3. Soporte de los servicios tecnológico
s
Dirección de TI
Cri_3.2. La dirección de TI cuenta con un proceso de gestión de niveles de servicio que le permite negociar y establecer objetivos de nivel de servicio de la mesa de servicios con el cliente (interno y externo)
2 2 100% 100 5 100 N/A N/A 100.0
Cat_3. Soporte de los servicios tecnológico
s
Dirección de TI
Cri_3.2. La dirección de TI cuenta con un proceso de gestión de niveles de servicio que le permite negociar y establecer objetivos de nivel de servicio de la mesa de servicios con el proveedor de TI
3 3 100% 100 4 80 N/A N/A 90.0
Cat_3. Soporte de los servicios tecnológico
s
Proveedor de TI
Cri_3.2. El proveedor de TI cuenta con una mesa de ayuda para gestionar los incidentes, problemas y requerimientos de la dirección de Tecnología
2 0 0% 0 1 20 N/A N/A 10.0
Cat_3. Soporte de los servicios tecnológico
s
Dirección de TI
Cri_3.2. La dirección de TI cuenta con un proceso de gestión de proveedores que permite negociar y establecer en los acuerdos de nivel de servicio la inclusión de planes de mantenimiento de la infraestructura y el servicio de TI
2 2 100% 100 5 100 N/A N/A 100.0
Cat_3. Soporte de los servicios tecnológico
s
Proveedor de TI
Cri_3.2. El proveedor de TI cuenta con los procesos de gestión de la confiabilidad y la continuidad para implementar los planes de mantenimiento de la infraestructura y el servicio de TI
1 0 0% 0 1 20 N/A N/A 10.0
Subcriterio 1: % de cubrimiento de actividades Subcriterio 2: nivel de madurez del proceso
Subcriterio 3: nivel de factibilidad financiera
Categoría de
evaluación Actor
Criterio de evaluación
Total de actividades
Actividades cubiertas
% de cubrimiento
de actividades
Puntos obtenidos
(1)
Nivel de madurez
del proceso
Puntos obtenidos
(2)
Nivel de factibilidad financiera
Puntos obtenidos
(3)
Puntaje total
(CRITERIO)
Puntaje total
Cat_4. Gestión de la calidad y seguridad
de los servicios
tecnológicos
Dirección de TI
Cri_4.1. La dirección de TI cuenta con un proceso de gestión de la demanda que le permite establecer los requerimientos de capacidad de recursos compartidos para el servicio de TI
2 2 100% 100 5 100 N/A N/A 100.0
89
Cat_4. Gestión de la calidad y seguridad
de los servicios
tecnológicos
Proveedor de TI
Cri_4.2. El proveedor de TI cuenta con un proceso de gestión de la capacidad para garantizar el cumplimiento de los requerimientos de recursos compartidos para el servicio de TI
2 2 100% 100 5 100 N/A N/A 100.0
Cat_4. Gestión de la calidad y seguridad
de los servicios
tecnológicos
Dirección de TI
Cri_4.3. La dirección de TI cuenta con un proceso de gestión de niveles de servicio que le permite negociar, establecer y hacer seguimiento a los objetivos de nivel
2 2 100% 100 4 80 N/A N/A 90.0
de servicio para el criterio de acciones preventivas (eventos, alertas)
Cat_4. Gestión de la calidad y seguridad
de los servicios
tecnológicos
Proveedor de TI
Cri_4.4. El proveedor de TI cuenta con un proceso de gestión de eventos para asegurar el cumplimiento de los objetivos de nivel de servicio para el criterio de acciones preventivas(eventos y alertas)
2 1 50% 50 3 60 N/A N/A 55.0
Cat_4. Gestión de la calidad y seguridad
de los servicios
tecnológicos
Proveedor de TI
Cri_4.5. El proveedor de TI incluye en el proceso de gestión de eventos el esquema de eventos y alertas tempranos alineados a los objetivos de nivel de servicio
2 1 50% 50 4 80 N/A N/A 65.0
Cat_4. Gestión de la calidad y seguridad
de los servicios
tecnológicos
Dirección de TI
Cri_4.6. La dirección de TI cuenta con un proceso de gestión de niveles de servicio que le permite negociar y establecer con el cliente (interno y externo) el RPO y el
2 2 100% 100 4 80 N/A N/A 90.0
RTO para el servicio de TI
Cat_4. Gestión de la calidad y seguridad
de los servicios
tecnológicos
Dirección de TI
Cri_4.7. La dirección de TI cuenta con un proceso de gestión de niveles de servicio que le permite negociar, establecer y hacer seguimiento con el proveedor TI al RPO y el RTO para el servicio de TI
3 3 100% 100 4 80 N/A N/A 90.0
Cat_4. Gestión de la calidad y seguridad
de los servicios
tecnológicos
Proveedor de TI
Cri_4.8. El proveedor de TI debe contar con un proceso de gestión de la continuidad para asegurar el cumplimiento del RPO y el RTO acordados para el servicio de TI
3 3 100% 100 4 80 N/A N/A 90.0
Cat_4. Gestión de la calidad y seguridad
de los servicios
tecnológicos
Proveedor de TI
Cri_4.9. El proveedor de TI debe contar con un proceso de gestión de pruebas para asegurar la implementación de un plan de pruebas de continuidad para el servicio de TI
1 1 100% 100 4 80 N/A N/A 90.0
Cat_4.
Gestión de la calidad y seguridad
de los
Dirección de TI
Cri_4.10. La dirección de TI cuenta con un proceso de gestión de requerimientos
2 2 100% 100 5 100 N/A N/A 100.0
servicios tecnológicos
que le permite recolectar y analizar las políticas y requerimientos de seguridad del cliente (interno y externo) para su implementación en el servicio de TI
Cat_4. Gestión de la calidad y seguridad
de los servicios
tecnológicos
Proveedor de TI
Cri_4.11. El proveedor de TI cuenta con un proceso de gestión de la seguridad que le permite implementar las políticas y requerimientos de seguridad de la dirección de TI bajo los principios de confidencialidad, integridad y disponibilidad de la información
2 2 100% 100 4 80 N/A N/A 90.0
Cat_4. Gestión de la calidad y seguridad
de los servicios
tecnológicos
Proveedor de TI
Cri_4.12. El proveedor de TI cuenta con un proceso de gestión de pruebas que le permite implementar un plan de pruebas de seguridad para la identificación, análisis y corrección de vulnerabilidades del servicio de TI
3 3 100% 100 5 100 N/A N/A 100.0
Cat_4. Gestión de la calidad y seguridad
de los servicios
tecnológicos
Dirección de TI
Cri_4.13. La dirección de TI cuenta con un proceso de gestión de niveles de servicio que le permite negociar, establecer y hacer seguimiento a los objetivos de nivel de servicio para el criterio de seguridad de la información
3 3 100% 100 5 100 N/A N/A 100.0
Cat_4. Gestión de la calidad y seguridad
de los servicios
tecnológicos
Dirección de TI
Cri_4.14. La dirección de TI cuenta con un proceso de gestión de requerimientos que le permite recolectar y analizar los requerimientos de controles de seguridad del cliente
4 4 100% 100 5 100 N/A N/A 100.0
Cat_4. Gestión de la calidad y seguridad
de los servicios
tecnológicos
Proveedor de TI
Cri_4.15. El proveedor de TI cuenta con un proceso de gestión de la seguridad que le permite asegurar el cumplimiento de los objetivos de nivel de servicio para el criterio de seguridad de la información
3 3 100% 100 3 60 N/A N/A 80.0
Cat_4. Gestión de la calidad y
Proveedor de TI
Cri_4.16. El proveedor de TI cuenta con un
2 2 100% 100 4 80 N/A N/A 90.0
seguridad de los
servicios tecnológicos
proceso de gestión de la seguridad que le permite asegurar la implementación de los controles de seguridad requeridos por la dirección de TI
Subcriterio 1: % de cubrimiento de actividades Sub-criterio 2: nivel
de madurez del proceso
Sub-criterio 3: nivel de factibilidad financiera
Categoría de
evaluación Actor Criterio de evaluación
Total de actividades
Actividades cubiertas
% de cubrimiento
de actividades
Puntos obtenidos
(1)
Nivel de madurez
del proceso
Puntos obtenidos
(2)
Nivel de factibilidad financiera
Puntos obtenidos
(3)
Puntaje total
(CRITERIO)
Puntaje total
Cat_5. Entorno
legal
Dirección de TI
Cri_5.1. La dirección de TI cuenta con un proceso de gestión de proveedores que le permite negociar y acordar las responsabilidades contractuales para el cumplimiento de la normatividad vigente en la prestación del servicio de TI
5 5 100% 100 4 80 N/A N/A 90
70
Cat _5. Entorno
legal
Dirección de TI
Cri_5.2. La dirección de TI cuenta con un proceso de gestión de relaciones con el negocio que le permite analizar el alcance normativo que deben ser implementados para el servicio de TI
3 0 0% 0 3 60 N/A N/A 30
Cat _5. Entorno
legal
Proveedor de TI
Cri_5.3. El proveedor de TI cuenta con un proceso de gestión de requerimientos que le
2 2 100% 100 4 80 N/A N/A 90
permite garantizar la implementación de los requerimientos normativos de la dirección de TI
Sub-criterio 1: % de cubrimiento de actividades Sub-criterio 2: nivel
de madurez del proceso
Sub-criterio 3: nivel de factibilidad financiera
Categoría de
evaluación Actor Criterio de evaluación
Total de actividades
Actividades cubiertas
% de cubrimiento
de actividades
Puntos obtenidos
(1)
Nivel de madurez
del proceso
Puntos obtenidos
(2)
Nivel de factibilidad financiera
Puntos obtenidos
(3)
Puntaje total
(CRITERIO)
Puntaje total
Cat_6. Entorno
financiero
Dirección de TI
Cri_6.1. La dirección de TI cuenta con un proceso de gestión financiera de servicios de TI que le permite asegurar los recursos financieros para la contratación del servicio de TI.
3 3 100% 100 4 80 N/A N/A 90
54 Cat_6. Entorno
financiero
Dirección de TI
Cri_6.2. La dirección de TI debe contar con un proceso de gestión de proveedores que le permita negociar y acordar con el proveedor de TI los costos de la prestación, soporte y mantenimiento del servicio de TI
2 2 100% 100 5 100 N/A N/A 100
Cat_6. Entorno
financiero
Dirección de TI
Cri_6.3. La dirección de TI debe realizar un análisis de factibilidad financiera comparando la contratación del servicio en
N/A N/A N/A N/A N/A N/A Sin
factibilidad 0 0
la nube con otras posibilidades
Cat_6. Entorno
financiero
Proveedor de TI
Cri_6.4. El proveedor de TI cuenta con un proceso de gestión de relaciones con el cliente para asegurar el cumplimiento de los acuerdos comerciales y requerimientos para la prestación del servicio de TI
2 1 50% 50 0 0 N/A N/A 35
ANEXO B. MAPEO DE MEJORES PRÁCTICAS DE ITIL 4 A PROCESOS DE ITIL V3.
Mejor práctica de ITIL 4 Proceso de ITIL v3
Architecture Management En ITIL v3 no existe un mapeo concreto de esta práctica, pero está fuertemente relacionada con el proceso de Strategy Management for IT Services.
Strategy Management Strategy Management for IT Services
Service Financial Management Financial Management for IT Services
Portfolio Management Service Portfolio Management Knowledge Management Knowledge Management
Monitoring and Event Management Event Management
Software Development and Management
En ITIL v3 no existe un mapeo concreto de esta práctica, pero está fuertemente relacionada con el proceso de Application Management.
Service Catalogue Management Service Catalogue Management
IT Assets Management En ITIL v3 no existe un mapeo concreto de esta práctica, pero está fuertemente relacionada con el proceso de Service Asset and Configuration Management.
Infrastructure and Platform Management
En ITIL v3 no existe un mapeo concreto de esta práctica, pero está fuertemente relacionada con el proceso de Service Strategy Management.
Capacity and Performance Management
Capacity Management
Availability Management Availability Management
Service Continuity Management IT Service Continuity Management (ITSCM)
Incident Management Incident Management
Information Security Management Information Security Management
Service Level Management Service Level Management
Supplier Management Supplier Management
Problem Management Problem Management
ANEXO C. APLICACIÓN DE LA SEGUNDA VERSIÓN DEL MARCO PARA LA VIABILIDAD DE ADOPTAR
SERVICIOS EN LA NUBE EN ENTIDADES PÚBLICAS
Para la aplicación de la nueva versión del marco de evaluación se proporciona la nomenclatura propuesta a continuación:
Subcriterio 1: % de cubrimiento de actividades. Subcriterio 2: nivel de madurez del proceso
Categoría de evaluación
Actor Criterio de evaluación
Actividades ¿La(s) actividades se cumplen?
Total de actividades
Actividades cubiertas
% de cubrimiento de actividades
Puntos obtenidos (1)
Nivel de madurez del proceso
Puntos obtenidos (2)
Puntaje total (CRITERIO)
(CAT.X) Nombre de la categoría de evaluación.
Nombre del actor.
(CAT.X.CRI.Y) Descripción del criterio de evaluación.
Descripción de la actividad de ITIL 4.
Se marca con una “x” si la empresa cumple con la actividad.
Número total de actividades identificadas para el criterio.
Número de actividades con las que cuenta la empresa del criterio actual.
Porcentaje de actividades cubiertas con respecto al total de actividades.
Puntos obtenidos del subcriterio según los valores posibles de la tabla 11 (cubrimiento de actividades).
Nivel de madurez del proceso identificado de COBIT.
Puntos obtenidos del subcriterio según los valores posibles de la tabla 12 (nivel de madurez del proceso).
Resultado del promedio de los campos de puntos obtenidos (1) y (2).
Adicionalmente, para la categoría (CAT.8) Entorno financiero se tienen los siguientes campos:
Subcriterio 3: nivel de factibilidad financiera Subcriterio 4: beneficio en liquidez
CSN PACI Total de actividades
Nivel de factibilidad financiera
Puntos obtenidos (3)
PARP Nivel de beneficio en liquidez
Puntos obtenidos (4)
Puntaje total (CRITERIO)
Valor del Costo de Contratar Servicios en la Nube (Valor presente de todos los meses de la suscripción por el tiempo de duración del promedio.
Valor del Presupuesto Asignado para Compra de Infraestructura (proporcionado por la empresa).
Número total de actividades identificadas para el criterio.
Cálculo de la factibilidad financiera según la fórmula presentada en la tabla 13.
Puntos obtenidos del subcriterio según los valores posibles de la tabla 13 (nivel de factibilidad financiera).
Valor del presupuesto asignado para la realización del proyecto (proporcionado por la empresa).
Cálculo del beneficio en liquidez según la fórmula presentada en la tabla 15.
Puntos obtenidos del subcriterio según los valores posibles de la tabla 15 (beneficio en liquidez).
Resultado del promedio de los campos de puntos obtenidos (1), (2), (3) y (4).
Subcriterio 1: % de cubrimiento de actividades Subcriterio 2: nivel
de madurez del proceso
Categoría Actor Criterio Práctica
ITIL 4 Actividades
¿La(s) actividad(
es) se cumple(n)
?
Total de actividad
es
Actividades
cubiertas
% de cubrimien
to de actividade
s
Puntos obtenid
os (1)
Nivel de
madurez del proces
o
Puntos obtenid
os (2)
Puntaje total
(CRITERIO)
Puntaje Categor
ía
(CAT.1) Arquitectu
ra Misional
Dirección de TI
(CAT.1.CRI.1) La dirección de TI cuenta
con un proceso de
seguimiento continuo del
modelo estratégico
de la empresa.
Strategy Manageme
nt
Análisis del entorno organizacional para identificar las oportunidades que pueden ser beneficiosas.
x
4 3 75% 50 4 80 65
71.43
Identificación de los inconvenientes que pueden afectar de forma negativa los objetivos de la organización y como minimizarlos.
x
Definir la dirección y perspectiva de la entidad, definiendo correctamente los stakeholders, la misión, la visión y los principios.
x
Asignar planes operacionales y tácticos para cada unidad de la organización reflejando la estrategia de la empresa.
(CAT.1). Arquitectu
ra Misional
Dirección de TI
(CAT.1.CRI.2) La dirección de TI cuenta
con un proceso de
seguimiento continuo del
modelo financiero.
Service Financial
Management
Presupuesto/Costos: predecir y controlar los ingresos y los gastos dentro de la organización.
x
3 3 100% 100 5 100 100
Contabilidad: realizar una contabilidad completa sobre la forma en cómo se gasta el dinero disponible, permitiendo realizar análisis de pronóstico vs actual y de gastos. Se resalta la posibilidad de identificar y diferenciar utilidades y costos por clientes, servicios y actividades.
x
Carga: proveer un servicio de facturación a los consumidores por los servicios que se les está entregando.
x
(CAT.1). Arquitectu
ra Misional
Dirección de TI
(CAT.1.CRI.3) La dirección de TI cuenta
con un proceso de
seguimiento continuo del portafolio de
servicios. Portfolio
Management
Desarrollo y aplicación de marcos de referencia sistemáticos para definir y entregar portafolio de productos, servicios, programas y proyectos para apoyar determinadas
4 3 75% 50 4 80 65
estrategias y objetivos.
Definir productos y servicios articulándolos con el cumplimiento de los costos presupuestados y asegurar que todas las actividades del servicio se alinean con la cadena de valor en la definición de valor y los factores críticos de éxito.
x
Evaluar y priorizar los ingresos de los proyectos, productos o servicios propuestos basándose en las restricciones de recursos, compromisos actuales y la estrategia de la organización.
x
Implementar asesoramientos estratégicos de inversión y procesos de toma de decisiones basados en el entendimiento del valor creado, los costos, los riesgos, las restricciones en
x
términos de recursos, las interdependencias y el impacto sobre las actividades existentes de negocio.
(CAT.1) Arquitectu
ra Misional
Proveedor de TI
(CAT.1.CRI.4) El proveedor de TI cuenta con un proceso de seguimiento continuo del portafolio de servicios.
Portfolio Manageme
nt
Desarrollo y aplicación de marcos de referencia sistemáticos para definir y entregar portafolio de productos, servicios, programas y proyectos para apoyar determinadas estrategias y objetivos.
1 0 0% 0 4 80 40
(CAT.1). Arquitectu
ra Misional
Dirección de TI
(CAT.1.CRI.5) La dirección de TI cuenta
con un proceso de gestión del modelo de
capacidades de la
entidad. Architectur
e Manageme
nt
Definir el modelo de capacidades de la empresa de la arquitectura de negocio.
x
3 3 100% 100 5 100 100
Las capacidades de la empresa se deben articular con las actividades relacionadas con la creación de valor.
x
Priorizar las capacidades, según las necesidades del negocio.
x
(CAT.1)
Arquitectura
Misional
Dirección de TI
(CAT.1.CRI.6) La dirección de TI cuenta
con un
Architecture
Management
Definir el nivel de estandarización en toda la organización.
x 2 2 100% 100 4 80 90
proceso de gestión del
modelo operativo de la entidad.
Definir el nivel de integridad en toda la organización.
x
(CAT.1) Arquitectu
ra Misional
Dirección de TI
(CAT.1.CRI.7) La dirección de TI cuenta con proceso de identificación de necesidades de sistematización y apoyo tecnológico para los procesos de la empresa.
Architecture
Management
Diseño de la arquitectura de negocio como está definida en ITIL 4, identificando las necesidades del negocio.
1 0 0% 0 4 80 40
Subcriterio 1: % de cubrimiento de actividades
Subcriterio 2: nivel de madurez del
proceso
Categoría
Actor Criterio Práctica ITIL 4 Actividades
¿La(s) actividad
(es) se cumple(n
)?
Total de activida
des
Actividades
cubiertas
% de cubrimie
nto de actividad
es
Puntos obtenidos (1)
Nivel de
madurez del proces
o
Puntos obtenido
s (2)
Puntaje total
(CRITERIO)
Puntaje
Categoría
(CAT.2) Arquitect
ura de informaci
ón
Dirección de
TI
(CAT.2.CRI.1) La dirección de TI cuenta con un catálogo de los componentes de información y
Architecture management
La dirección de TI cuenta con un catálogo de los componentes de información presentados en la capa lógica y física.
x 1 1 100% 100 4 80 90 76.35
un proceso de gestión del mismo.
(CAT.2) Arquitect
ura de informaci
ón
Dirección de
TI
(CAT.2.CRI.2) La dirección de TI cuenta con un proceso de gestión de la arquitectura de información.
Architecture management
La arquitectura de información se debe diseñar y gestionar con base a los siguientes conceptos: completitud, precisión y accesibilidad.
x 1 1 100% 100 3 60 80
(CAT.2) Arquitect
ura de informaci
ón
Dirección de
TI
(CAT.2.CRI.3) La dirección de TI cuenta con un proceso de intercambio de la información con respecto al marco de interoperabilidad.
Architecture management
Definición de los procesos de gestión y distribución de la información que maneja la empresa.
x 1 1 100% 100 4 80 90
(CAT.2) Arquitect
ura de informaci
ón
Dirección de
TI
(CAT.2.CRI.4) La dirección de TI cuenta con una estructura definida de los datos maestros.
Architecture Management
Definir estructuras de información para el almacenamiento de datos maestros que cuenten con los siguientes conceptos: completitud, precisión y accesibilidad.
x 1 1 100% 100 3 60 80
(CAT.2) Arquitect
ura de informaci
ón
Dirección de
TI
(CAT.2.CRI.5) La dirección de TI cuenta con un modelo que refleje el flujo de la información desde sus fuentes de datos hacia el resto de los sistemas de información.
Architecture management
Establecer un proceso para modelar un diagrama de componentes; especificando a detalle el flujo de la información.
x 1 1 100% 100 4 80 90
(CAT.2) Arquitect
ura de informaci
ón
Dirección de
TI
(CAT.2.CRI.6) La dirección de TI cuenta con un proceso para garantizar el manejo del lenguaje común para el intercambio de información con otras entidades.
Knowledge Management
Definir una estructura de información adecuada, de forma tal de modo que los interesados puedan entenderla, analizarla en un nivel ideal, de forma oportuna y en su debido formato.
x 1 1 100% 100 3 60 80
(CAT.2) Arquitect
ura de informaci
ón
Dirección de
TI
(CAT.2.CRI.7) La dirección de TI cuenta con un proceso para solicitar la inclusión de una definición al portal de Lenguaje común de
Knowledge Management
Adquisición de la información, incluyendo el desarrollo, captura, agrupación y categorización de los datos no estructurados.
x 1 1 100% 100 2 40 70
intercambio de información del Estado Colombiano.
(CAT.2) Arquitect
ura de informaci
ón
Dirección de
TI
(CAT.2.CRI.8) La dirección de TI cuenta con un proceso para diseñar los mecanismos que permitan el acceso a los componentes de información.
Architecture management
Al definir distribución de los sistemas de información, se especifica cuáles de estos sistemas tienen acceso a las fuentes de datos.
1 0 0% 0 0 0 0
(CAT.2) Arquitect
ura de informaci
ón
Proveedor de
TI
(CAT.2.CRI.9) El proveedor de TI garantiza que los mecanismos diseñados permitan el entendimiento, análisis y aprovechamiento de la información.
Architecture management
Garantizar que los recursos disponibles para la gestión de la información cuenten con un alto nivel de usabilidad y además permitan generar vistas que sean útiles para la toma de decisiones.
x 1 1 100% 100 4 80 90
(CAT.2) Arquitect
ura de informaci
ón
Dirección de
TI
(CAT.2.CRI.10) La dirección de TI garantiza la existencia de fuentes únicas de información para que el acceso a los
Architecture management
Al diseñar la distribución de los sistemas de información, se estructura la configuración de la información; de modo que pueda ser almacenada y
x 1 1 100% 100 5 100 100
datos sea completo, confiable y comparable.
publicada en una base de datos para la organización completa, o una base de datos distribuida en varios componentes de la empresa.
(CAT.2) Arquitect
ura de informaci
ón
Dirección de
TI (CAT.2.CRI.11) La dirección de TI cuenta con un proceso para documentar los hallazgos asociados a los componentes de información.
Monitoring and Event Management
Identificar qué servicios, sistemas, CIs u otros componentes del servicio deben ser monitoreados; y establecer la estrategia de monitoreo.
2 1 50% 25 3 60 42.5
Implementar y mantener el monitoreo, aprovechando tanto las características de monitoreo nativas como el uso de herramientas creadas específicamente para la actividad de monitoreo.
x
(CAT.2) Arquitect
ura de informaci
ón
Dirección de
TI
(CAT.2.CRI.12) La dirección de TI identifica el impacto de cada hallazgo sobre los componentes
Monitoring and Event Management
Establecer y mantener umbrales y otros criterios para determinar qué cambios se tratarán como eventos; y elegir criterios para
x 3 3 100% 100 4 80 90
de información.
definir cada tipo de evento (informativo, advertencia o excepción).
Establecer y mantener políticas sobre cómo se debe manejar cada tipo de evento detectado, esto con el fin de garantizar una gestión adecuada.
x
Implementar procesos y automatizaciones requeridos para gestionar los umbrales, criterios y políticas definidos.
x
(CAT.2) Arquitect
ura de informaci
ón
Proveedor de
TI
(CAT.2.CRI.13) El Proveedor de TI cuenta con un proceso automático para garantizar la creación y publicación de datos abiertos a partir de sistemas de información.
Knowledge Management
Proveer una estructura aproximada para definir, construir, re-usar y compartir información.
x 1 1 100% 100 4 80 90
Subcriterio 1: % de cubrimiento de actividades Subcriterio 2: nivel
de madurez del proceso
Categoría Actor Criterio Práctica ITIL 4 Actividades ¿La(s) actividad(es) se cumple(n)?
Total de actividades
Actividades cubiertas
% de cubrimiento de actividades
Puntos obtenidos (1)
Nivel de madurez del proceso
Puntos obtenidos (2)
Puntaje total (CRITERIO)
Puntaje Categoría
(CAT.3) Arquitectura de sistemas de información
Proveedor de TI
(CAT.3.CRI.1) El Proveedor de TI cuenta con un proceso para garantizar que la definición y evolución de arquitecturas de referencia permitan diseñar arquitecturas de solución bajo parámetros, patrones y atributos de calidad y, además, con base a los principios de servicios digitales, definidos en el Manual de Gobierno digital.
Architecture Management
Diseñar la arquitectura de sistemas de información cómo están definidas en ITIL 4, integrando la arquitectura de información y de aplicaciones.
2 1 50% 25 3 60 42.5 85.42
Interpretar la arquitectura de negocio, para obtener los atributos de calidad.
x
(CAT.3) Arquitectura de sistemas de información
Dirección de TI
(CAT.3.CRI.2) La Dirección de TI cuenta con un proceso para garantizar la definición, documentación y actualización de las arquitecturas de solución según dictámenes de las arquitecturas de referencia.
Software Development and Management
Se debe tener un proceso de diseño de la arquitectura de solución.
x 1 1 100% 100 4 80 90
(CAT.3) Arquitectura de sistemas de información
Dirección de TI
(CAT.3.CRI.3) La Dirección de TI es capaz de definir y documentar la arquitectura de software de los sistemas de información y aplicaciones identificando los componentes propios de las arquitecturas
Software Development and Management
Se debe tener un proceso de diseño de la arquitectura de solución.
x 2 2 100% 100 4 80 90
Diseño del prototipo de la solución (UI, CX, diseño del servicio, etc).
X
de referencia definidas.
(CAT.3) Arquitectura de sistemas de información
Proveedor de TI
(CAT.3.CRI.4) El Proveedor de TI es capaz de definir, documentar y suministrar la arquitectura de software de los sistemas de información y aplicaciones identificando los componentes propios de las arquitecturas de referencia definidas.
Software Development and Management
Se debe tener un proceso de diseño de la arquitectura de solución.
x 2 2 100% 100 4 80 90
Diseño del prototipo de la solución (UI, CX, diseño del servicio, etc).
X
(CAT.3) Arquitectura de sistemas de información
Dirección de TI
(CAT.3.CRI.5) La Dirección de TI cuenta con un proceso para actualizar el catálogo de sistemas de información.
Service Catalogue Management.
Publicación, edición y mantenimiento de las descripciones del servicio y el producto y sus determinadas ofertas.
X 2 2 100% 100 5 100 100
Proveer diferentes vistas y niveles de detalle de las descripciones del catálogo de servicios según el grupo de interés.
X
(CAT.3) Arquitectura de sistemas de información
Dirección de TI
(CAT.3.CRI.6) (Si aplica) La Dirección de TI, dentro de una entidad cabeza de sector, cuenta con un proceso para actualizar el catálogo de sistemas de información sectorial.
Service Catalogue Management
Publicación, edición y mantenimiento de las descripciones del servicio y el producto y sus determinadas ofertas.
X 2 2 100% 100 5 100 100
Proveer diferentes vistas y niveles de detalle de las descripciones del catálogo de servicios según el grupo de interés.
X
Subcriterio 1: % de cubrimiento de actividades Subcriterio 2: nivel de madurez del proceso
Categoría Actor Criterio Práctica ITIL 4
Actividades ¿La(s) actividad(es) se cumple(n)?
Total de actividades
Actividades cubiertas
% de cubrimiento de actividades
Puntos obtenidos (1)
Nivel de madurez del
Puntos obtenidos (2)
Puntaje total (CRITERIO)
Puntaje Categoría
proceso
(CAT.4) Arquitectura de Infraestrucutra Tecnológica
Proveedor de TI
(CAT.4.CRI.1) El proveedor de TI cuenta con un catálogo de los elementos de infraestructura tecnológica y un proceso de gestión de este.
Assets Management
Todo hardware dentro del catálogo de infraestructura debe tener un formato de identificación.
x 1 1 100% 100 3 60 80 64.00
(CAT.4) Arquitectura de Infraestrucutra Tecnológica
Proveedor de TI
(CAT.4.CRI.2) El proveedor de TI cuenta con los elementos necesarios que garanticen el intercambio de información con respecto al marco de interoperabilidad.
Infrastructure and Platform Management
La gestión de infraestructura y plataforma debe incluir la provisión de tecnología necesaria para apoyar a las actividades que generan valor a la organización y sus interesados.
x 1 1 100% 100 4 80 90
(CAT.4) Arquitectura de Infraestrucutra Tecnológica
Dirección de TI
(CAT.4.CRI.3) La Dirección de TI cuenta con un portafolio de clientes que le permite establecer el tipo de nube
IT Assets Management
Los activos basados en computación en la nube deben ser asignados a diferentes grupos o
x 1 1 100% 100 2 40 70
que se requiere adoptar.
productos tal que se puedan gestionar los costos.
(CAT.4) Arquitectura de Infraestrucutra Tecnológica
Proveedor de TI
(CAT.4.CRI.4) El proveedor de TI cuenta con un proceso de gestión de requerimientos para analizar e implementar el tipo de nube requerida por la dirección de TI.
Capacity and performance Management.
Desempeño del servicio y planeación de capacidad: (1) Proceso de análisis de requerimientos de capacidad. (2) Procesos de planeación de recursos y pronósticos de demanda.
x 1 1 100% 100 3 60 80
(CAT.4) Arquitectura de Infraestrucutra Tecnológica
Proveedor de TI
(CAT.4.CRI.5) El proveedor de TI tiene un proceso de gestión de incidentes que garantice lo correcta operación del servicio.
Incident Management.
Deben incluir procesos formales para la gestión de incidentes, tales como: (1) Técnicas de para realizar investigación y diagnósticos precisos de incidentes. (2) Creación de scripts de recolección
1 0 0% 0 0 0 0
de información de los usuarios durante el contacto inicial; con estos, se puede obtener directamente el diagnóstico y la resolución de incidentes simples. (3) Los procesos de investigaciones de incidentes más complejos requieren el apoyo de expertos en el tema.
Subcriterio 1: % de cubrimiento de actividades Subcriterio 2: nivel de madurez del proceso
Categoría Actor Criterio Práctica ITIL 4 Actividades ¿La(s) actividad(es) se cumple(n)?
Total de actividades
Actividades cubiertas
% de cubrimiento de actividades
Puntos obtenidos (1)
Nivel de madurez del proceso
Puntos obtenidos (2)
Puntaje total (CRITERIO)
Puntaje Categoría
(CAT.5) Arquitectu
Dirección de TI
(CAT.5.CRI.1) La dirección
Revisión de control y
X 2 2 100% 100 4 80 90 87
ra de seguridad
de TI cuenta con criterios necesarios para asegurar la trazabilidad y auditoria de creación, modificación o eliminación de datos.
Information Security Management
proceso de auditoría.
Procedimientos para el manejo de la seguridad de la información relacionada con modificaciones.
X
(CAT.5) Arquitectura de seguridad
Proveedor de TI
(CAT.5.CRI.2) El proveedor de TI garantiza la buena trazabilidad para la auditoria de creación, modificación o eliminación de datos.
Information Security Management
Revisión de control y proceso de auditoría.
X 2 2 100% 100 4 80 90
Procedimientos para el manejo de la seguridad de la información relacionada con modificaciones.
X
(CAT.5) Arquitectura de seguridad
Dirección de TI
(CAT.5.CRI.3) La dirección de TI cuenta con un catálogo de información asociada con los responsables y políticas de protección y privacidad de
Information Security Management
Proceso de gestión de incidentes relacionados con la seguridad de la información.
X 4 4 100% 100 3 60 80
Proceso de gestión de identidad y acceso.
X
la información.
Procedimientos para pruebas de penetración, escáner de vulnerabilidad, etc.
x
Procedimientos para el manejo de la seguridad de la información relacionada con modificaciones.
X
(CAT.5) Arquitectura de seguridad
Proveedor de TI
(CAT.5.CRI.4) El proveedor de TI cuenta con un catálogo de información asociada con los responsables y políticas de protección y privacidad de la información.
Information Security Management
Proceso de gestión de incidentes relacionados con la seguridad de la información.
x 4 3 75% 50 4 80 65
Proceso de gestión de identidad y acceso.
x
Procedimientos para pruebas de penetración, escáner de vulnerabilidad, etc.
Procedimientos para el manejo de la seguridad de
x
la información relacionada con modificaciones.
(CAT.5) Arquitectura de seguridad
Dirección de TI
(CAT.5.CRI.5) La Dirección de TI cuenta con un proceso para garantizar la trazabilidad de las acciones sobre los sistemas de información.
Information Security Management
Revisión de control y proceso de auditoría.
x 1 1 100% 100 5 100 100
(CAT.5) Arquitectura de seguridad
Proveedor de TI
(CAT.5.CRI.6) El Proveedor de TI garantiza la buena trazabilidad de las acciones sobre los sistemas de información requerida por la Dirección de TI.
Information Security Management
Revisión de control y proceso de auditoría.
x 1 1 100% 100 4 80 90
(CAT.5) Arquitectura de seguridad
Proveedor de TI
(CAT.5.CRI.7) El proveedor de TI cuenta con un proceso para la identificación de componentes de tecnología altamente expuestos a riesgos que afecten la seguridad de la información y/o la prestación de servicios de la entidad.
Information Security Management
Proceso de gestión de riesgo.
x 1 1 100% 100 5 100 100
(CAT.5) Arquitectura de seguridad
Proveedor de TI
(CAT.5.CRI.8) El Proveedor de TI cuenta con un proceso para diseñar controles de seguridad informática para gestionar riesgos de disponibilidad, integridad y confidencialidad de la información.
Information Security Management
Proceso de gestión de incidentes relacionados con la seguridad de la información.
x 5 4 80% 75 4 80 77.5
Proceso de gestión de riesgo.
x
Proceso de gestión de identidad y acceso.
x
Procedimientos para pruebas de penetración,
escáner de vulnerabilidad, etc.
Procedimientos para el manejo de la seguridad de la información relacionada con modificaciones.
x
Subcriterio 1: % de cubrimiento de actividades
Subcriterio 2: nivel de madurez del proceso
Categoría Actor Criterio Práctica ITIL 4 Actividades ¿La(s) actividad(es) se cumple(n)?
Total de actividades
Actividades cubiertas
% de cubrimiento de actividades
Puntos obtenidos (1)
Nivel de madurez del proceso
Puntos obtenidos (2)
Puntaje total (CRITERIO)
Puntaje Categoría
(CAT.6) Arquitectura de servicios tecnológicos
Dirección de TI
(CAT.6.CRI.1) La dirección de TI cuenta con un proceso de gestión de niveles de servicio para definir, negociar y hacer seguimiento del nivel de disponibilidad.
Service level management
Se debe construir un acuerdo de nivel de servicio de disponibilidad que evidencie compromiso y discusión con el proveedor de nube. Asimismo, se debe crear un acuerdo de nivel de servicio
x 2 2 100% 100 3 60 80 72
de disponibilidad con el cliente que contrata el servicio, esto teniendo en cuenta lo pactado con el proveedor. Es importante que dentro de estos acuerdos se atiendan las necesidades particulares de cada parte involucrada.
Se debe realizar un proceso de seguimiento continuo sobre el nivel de servicio de disponibilidad acordada.
x
(CAT.6) Arquitectura de servicios tecnológicos
Proveedor de TI
(CAT.6.CRI.2) El proveedor de TI cuenta con un proceso de gestión de la disponibilidad, para garantizar los objetivos de nivel de servicio de disponibilidad acordados.
Availability Management
Designar aplicaciones e infraestructura que pueden ofrecer los niveles de disponibilidad requeridos.
x 3 3 100% 100 5 100 100
Proceso de monitoreo, análisis y reporte de disponibilidad.
x
Planeación de mejoras de la
x
disponibilidad.
(CAT.6) Arquitectura de servicios tecnológicos
Dirección de TI
(CAT.6.CRI.3) La dirección de TI cuenta con un proceso de gestión de niveles de servicio para definir, negociar y hacer seguimiento del nivel de servicio de seguridad
Service Level Management
Se debe construir un acuerdo de nivel de servicio de seguridad que evidencie compromiso y discusión con el proveedor de nube. Asimismo, se debe crear un acuerdo de nivel de servicio de seguridad con el cliente que contrata el servicio, esto teniendo en cuenta lo pactado con el proveedor. Es importante que dentro de estos acuerdos se atiendan las necesidades particulares de cada parte involucrada.
x 2 2 100% 100 4 80 90
Se debe realizar un proceso de seguimiento continuo sobre el nivel de servicio de seguridad acordada.
x
(CAT.6) Arquitect
Proveedor de TI
(CAT.6.CRI.4) El proveedor
Information Security Management
Gestión de eventos.
x 5 4 80% 75 4 80 77.5
ura de servicios tecnológicos
de TI cuenta con un proceso de gestión de la seguridad para garantizar los objetivos de nivel de servicio relativos a la seguridad.
Proceso de gestión de incidentes relacionados con la seguridad de la información.
x
Proceso de gestión de identidad y acceso.
x
Procedimientos para pruebas de penetración, escáner de vulnerabilidad, etc.
Procedimientos para el manejo de la seguridad de la información relacionada con modificaciones.
x
(CAT.6) Arquitectura de servicios tecnológicos
Dirección de TI
(CAT.6.CRI.5) La dirección de TI cuenta con un proceso de gestión de niveles de servicio para definir, negociar y hacer seguimiento
Service level management
Se debe construir un acuerdo de nivel de servicio de continuidad que evidencie compromiso y discusión con el proveedor de nube. Asimismo, se debe crear un acuerdo de
x 3 3 100% 100 5 100 100
del nivel de continuidad para el buen funcionamiento del servicio.
nivel de servicio de continuidad con el cliente que contrata el servicio, esto teniendo en cuenta lo pactado con el proveedor. Es importante que dentro de estos acuerdos se atiendan las necesidades particulares de cada parte involucrada.
El acuerdo de nivel de servicio con el cliente debe definir los resultados y no simplemente métricas operacionales. Esto puede lograrse balanceando diferentes grupos de métricas, en especial el RPO, BIA y RTO.
x
Se debe realizar un proceso de seguimiento continuo sobre el nivel
x
de servicio de continuidad acordada.
(CAT.6) Arquitectura de servicios tecnológicos
Proveedor de TI
(CAT.6.CRI.6) El proveedor de TI cuenta con un proceso de gestión de la continuidad para garantizar los objetivos de nivel de servicio relativos a la continuidad.
Service Continuity Management
Proveer técnicas para la investigación de desastres y así tener diagnósticos más precisos de estos.
x 4 2 50% 25 4 80 52.5
Los procesos de investigaciones de desastres más complejos requieren el apoyo de expertos.
x
Definir un plan de recuperación en el que se especifique cómo la organización se puede recuperar de un desastre y cómo puede regresar a un estado de “pre-desastre”, considerando las cuatro dimensiones de la gestión del servicio: (1) Organizaciones y personas; (2)
Información y tecnología; (3) Socios y proveedores; (4) Procesos y cadena de valor.
Establecer un plan de continuidad que abarque y garantice todos las definiciones enunciadas y descritas en ITIL 4 (RTO, RPO y BIA)
(CAT.6) Arquitectura de servicios tecnológicos
Proveedor de TI
(CAT.6.CRI.7) El proveedor de TI debe contar con un proceso de gestión de pruebas para asegurar la implementación de un plan de pruebas de continuidad para el servicio de TI.
Service Continuity Management
Definir un plan de pruebas que se ajuste al plan de recuperación ante desastres, el cual cumpla con los objetivos de nivel de servicio.
x 1 1 100% 100 3 60 80
(CAT.6) Arquitectura de servicios
Dirección de TI
(CAT.6.CRI.8) La dirección de TI cuenta con un proceso de
Service Level Management
Se debe construir un acuerdo de nivel de servicio de resiliencia
x 2 2 100% 100 3 60 80
tecnológicos
gestión de niveles de servicio para definir, negociar y hacer seguimiento los objetivos de nivel de servicio de resiliencia.
que evidencie compromiso y discusión con el proveedor de nube. Asimismo, se debe crear un acuerdo de nivel de servicio de resiliencia con el cliente que contrata el servicio, esto teniendo en cuenta lo pactado con el proveedor. Es importante que dentro de estos acuerdos se atiendan las necesidades particulares de cada parte involucrada.
Se debe realizar un proceso de seguimiento continuo sobre el nivel de servicio de resiliencia acordada.
x
(CAT.6) Arquitectura de servicios tecnológicos
Proveedor de TI
(CAT.6.CRI.9) El proveedor de TI cuenta con un proceso de gestión de incidentes, para así garantizar la
Incident Management
Se debe registrar y gestionar cada incidente para asegurar la resolución del mismo en un tiempo
3 0 0.00% 0 0 0 0
resiliencia propuesta en los objetivos del atributo de calidad.
prudente y relacionado con las expectativas del cliente y usuario.
Acordar, documentar y comunicar los tiempos de recuperación objetivos para que las expectativas del cliente y usuario sean realistas.
Se debe contar con un mecanismo de priorización de incidentes que opere según el nivel de impacto sobre el negocio. En este orden de ideas, los de mayor impacto se deben resolver primero.
(CAT.6) Arquitectura de servicios
Proveedor de TI
(CAT.6.CRI.10) El proveedor de TI cuenta con un proceso de
Problem Management
Se debe contar con un proceso de detección y análisis de
x 2 2 100.00% 100 1 20 60
tecnológicos
gestión de problemas, para así garantizar la resiliencia propuesta en los objetivos del atributo de calidad.
incidentes duplicados y problemas recurrentes presentados por los usuarios, la mesa de ayuda y el equipo técnico.
Se cuenta con un proceso de análisis de tendencia sobre los incidentes históricos.
x
Subcriterio 1: % de cubrimiento de actividades
Subcriterio 2: nivel de madurez del proceso
Categoría
Actor Criterio Práctica ITIL 4 Actividades ¿La(s) actividad(es) se cumple(n)?
Total de actividades
Actividades cubiertas
% de cubrimiento de actividades
Puntos obtenidos (1)
Nivel de madurez del proceso
Puntos obtenidos (2)
Puntaje total (CRITERIO)
Puntaje Categoría
(CAT.7) Entorno de las partes
Dirección de TI
(CAT.7.CRI.1) La dirección de TI cuenta con un proceso de gestión de proveedores que le permite negociar y
Supplier management
Desarrollar, negociar, revisar, actualizar, finalizar y adjudicar los contratos con los proveedores.
x 2 2 100% 100 4 80 90 90
interesadas
acordar las responsabilidades contractuales para el cumplimiento de la normatividad vigente en la prestación del servicio de TI.
Dado el caso que fallen las negociaciones, se debe diseñar un nuevo contrato, actualizarlo o terminar el mismo.
x
(CAT.7) Entorno de las partes interesadas
Dirección de TI
(CAT.7.CRI.2) La dirección de TI cuenta con un proceso de gestión de relaciones con el negocio que le permite recolectar y analizar los requerimientos normativos que deben ser implementados para el servicio de TI.
Architecture management
Elaborar la arquitectura del entorno, definiendo los aspectos políticos con respecto al manual de GEL, para así recolectar y analizar los requerimientos normativos.
x 1 1 100% 100 4 80 90
(CAT.7) Entorno de las partes interesadas
Proveedor de TI
(CAT.7.CRI.3) El proveedor de TI cuenta con un proceso de gestión de requerimientos que le permite garantizar la implementación de los requerimientos normativos de la dirección de TI.
Supplier management
Gestionar la entrega del desempeño en función del contrato establecido con la dirección de TI.
x 1 1 100% 100 4 80 90
Subcriterio 1: % de cubrimiento de actividades
Subcriterio 2: nivel de
madurez del proceso
Subcriterio 3: nivel de factibilidad financiera
Subcriterio 4: Beneficio en liquidez
Categoría
Actor Criterio Práctica ITIL 4
Actividades
¿La(s) actividad(es)
se cumple
(n)?
Total de
actividades
Actividades cubier
tas
% de cubrimiento
de actividades
Puntos
obtenidos
(1)
Nivel de madurez del
proceso
Puntos
obtenidos
(2)
CSN (descrip
ción abajo)
PACI (descripción abajo)
Nivel de
factibilidad
financiera
Puntos
obtenidos
(3)
PARP (descrip
ción abajo)
Nivel de
beneficio en
liquidez
Puntos
obtenidos
(4)
Puntaje
total (CRITERIO)
Puntaje
Categoría
(CAT.8)
Entorno
financiero
Dirección de TI
(CAT.8.CRI.1) La dirección de TI cuenta con un proceso de gestión financiera de servicios de TI que le permite asegurar los recursos financieros para la contratación del servicio de TI.
Service financi
al management
Gestionar y proyectar los presupuestos de la organización para que estos puedan ser utilizados para la contratación de servicios tecnológicos.
x 1 1 100% 100 5 100 N/A N/A N/A N/A N/A N/A N/A 100 98.3
(CAT.8)
Entorno
financiero
Dirección de TI
(CAT.8.CRI.2) La dirección de TI debe contar con un proceso de gestión de proveedores que le permita Negocia y acordar
Service financi
al management
Estimar los costos de la operación y los proyectos de forma anticipada para poder realizar un debido seguimiento del
x 1 1 100% 100 5 100 N/A N/A N/A N/A N/A N/A N/A 100
con el proveedor de TI los costos de la prestación, soporte y mantenimiento del servicio de TI.
presupuesto.
(CAT.8)
Entorno
financiero
Dirección de TI
(CAT.8.CRI.3) La dirección de TI debe realizar un análisis de factibilidad financiera comparando la contratación del servicio en la nube con otras posibilidades. N/A N/A
N/A N/A N/A N/A N/A N/A N/A $
55,924,320.19
$ 2,500,000
,000.00
44.7032703
100 N/A N/A N/A 100
(CAT.8)
Entorno
Proveedor de TI
(CAT.8.CRI.4) El proveedor de TI
Supplier
management
Alinear el contrato del servicio
x 1 1 100% 100 4 80 N/A N/A N/A N/A N/A N/A N/A 90
financiero
cuenta con un proceso de gestión de relaciones con el cliente para asegurare el cumplimiento de los acuerdos comerciales y requerimientos para la prestación del servicio de TI.
de TI con los acuerdos comerciales de la organización.
(CAT.8)
Entorno
financiero
Dirección de TI
(CAT.8.CRI.5) La dirección de TI cuenta con un proceso de análisis financiero para la decisión del modelo de nube que se requiera (en caso
Service financi
al management
Realizar un análisis financiero y comparativo sobre los costos de cada proveedor; estos deben estar ajustados al presupuesto
x 1 1 100% 100 5 100 N/A N/A N/A N/A N/A N/A N/A 100
de que el servicio sea nuevo).
acordado para el proyecto.
(CAT.8)
Entorno
financiero
Dirección de TI
(CAT.8.CRI.6) La dirección de TI cuenta con un proceso para analizar el beneficio en términos de liquidez con la inclusión de computación en la nube. N/A N/A
N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A $
750,000,000.00
99.42%
100 100