Tesis Gobernabilidad

MAESTRÍA EN GESTIÓN
ESTRATÉGICA DE SISTEMAS Y
TECNOLOGÍAS DE LA INFORMACIÓN
(M44)
Trabajo Final de la
Carrera de Maestría:
Normas y Marcos relacionados con la

implementación de esquemas de Gobierno de la
Tecnología de la Información.
Director de la Maestría: Dr. Raúl Saroka

Sub-Director: Mg. Claudio Freijedo
Coord. Académica: Mg. Virginia Chaina
Director del Trabajo: Mg. Gustavo Díaz
Autor: Esp. Lic. Daniel Piorun

Primer Cohorte 2014 GESTI
Buenos Aires – 2016

UBA – FCE Escuela de Posgrado – Maestría GESTI M44
1 Declaración
“Por medio de la presente, el autor manifiesta conocer y aceptar el Reglamento de

Trabajos Finales vigente en la Escuela de Estudios de Posgrado y se hace responsable
que la totalidad de los contenidos del presente documento son originales y de su
creación exclusiva, o bien pertenecen a terceros u otras fuentes, que han sido
adecuadamente referenciados y cuya inclusión no infringe la legislación Nacional e
Internacional de Propiedad Intelectual”.
Juan Daniel Piorun
DNI 14.462.322
 Autor de este trabajo final de la Maestría
 Especialista en Gestión estratégica de sistemas y Tecnologías de la Información

FCE-UBA (2015)
 Profesor adjunto regular y asociado interino en la carrera de sistemas FCE-UBA
 Director de proyectos de tecnología de la información en organismos públicos y

empresas privadas
Trabajo Final de Maestría GESTI Página 2 Autor: Lic. Daniel Piorun

2 Director del Trabajo Final de Maestría
Prof. Mg. Gustavo Díaz
 Magister MBA en la Facultad de Ciencias Económicas – UBA
 Profesor de la Maestría en Gestión Estratégica de Sistemas y Tecnologías de la

Información – GESTI – FCE- UBA
 Profesor de la Maestría en Seguridad informática – FCE - UBA
 Gerente Titular de Sistemas de Información en Banco de la Provincia de Buenos Aires
 Profesor Adjunto Regular en grado en la materia “Metodología de Análisis y Diseño

de Sistemas de Información” FCE – UBA
 Licenciado en Informática – UADE
Mg. Gustavo Díaz

3 Contenido Global
1 Declaración .......................................................................................................... 2
2 Director del Trabajo Final de Maestría ................................................................. 3
3 Contenido Global ................................................................................................. 4
4 Tabla de ilustraciones .......................................................................................... 6
5 Título del Trabajo y Resumen .............................................................................. 8
6 Dedicatoria y Agradecimientos ............................................................................ 8
7 Glosario ............................................................................................................... 9
8 Resumen Ejecutivo ............................................................................................ 11
9 Introducción ....................................................................................................... 12
10 Planteo del Problema ........................................................................................ 13
11 Objetivos ............................................................................................................ 14
12 Justificación y Relevancia de este Trabajo ........................................................ 15
13 Metodología de elaboración del Trabajo y Alcance ........................................... 16
14 Marco Teórico .................................................................................................... 17
15 Planeamiento estratégico organizacional .......................................................... 18
16 El Gobierno de la tecnología de la información ................................................. 21
17 Desarrollo de Sistemas de Información ............................................................. 34
18 Gestión de Proyectos de TI ............................................................................... 40
19 Gestión de Procesos ......................................................................................... 44
20 Infraestructura y Arquitectura Tecnológica ........................................................ 47
21 Integración de los marcos existentes con las normas ISO ................................ 50
22 La norma ISO 38500 – Gobierno de TI.............................................................. 51
23 La norma ISO 20000 – Gestión de Servicios ..................................................... 53
24 La norma ISO 9001- Gestión de la Calidad ....................................................... 57
25 La norma ISO 90003 – Aplicación al Software .................................................. 60

26 La norma ISO 27001- Gestión de Seguridad de la Información ........................ 65
27 La norma ISO 31000 - Gestión del Riesgo ........................................................ 68
28 La Norma ISO 21500 – Guidance on Project Management ............................... 69
29 La norma ISO 15504 - Madurez del Proceso de Software ................................ 70
30 Marcos existentes para el gobierno y gestión de TI........................................... 75
31 COBIT ................................................................................................................ 76
32 ITIL .................................................................................................................... 96
33 TOGAF ............................................................................................................ 110
34 ZACHMAN ....................................................................................................... 134
35 PMI .................................................................................................................. 140
36 CMMI ............................................................................................................... 153
37 Otros marcos complementarios ....................................................................... 162
38 COSO .............................................................................................................. 163
39 Ley Sarbanes Oaxley ...................................................................................... 166
40 Basilea III ......................................................................................................... 168
41 BCRA – Comunicación 4609 ........................................................................... 169
42 PRINCE2 ......................................................................................................... 171
43 Conclusiones y Recomendaciones .................................................................. 172
44 Bibliografía ....................................................................................................... 184

4 Tabla de ilustraciones
Ilustración 1 - Plan estratégico y táctico .............................................................................. 19

Ilustración 2 - Estrategia de TI ............................................................................................. 21
Ilustración 3 - Evaluación gobierno TI .................................................................................. 28
Ilustración 4 - Mapa de Frameworks ................................................................................... 29
Ilustración 5 - Ciclo de vida BPM ......................................................................................... 45
Ilustración 6 - Mapa PRISM ................................................................................................. 46
Ilustración 7 - Mapa ISO y Frameworks ............................................................................... 50
Ilustración 8 - Mapa ISO 38500............................................................................................ 52
Ilustración 11 – Elementos de un proceso (ISO 9001:2015) ................................................. 59
Ilustración 12 – Circuito Planificar-Hacer-Verificar-Actuar (ISO 9001:2015) ......................... 59
Ilustración 13 - Documentación Sistema Gestión Calidad .................................................... 62
Ilustración 14 - Brecha del SGC ............................................................................................ 63
Ilustración 15 - Directrices ISO 90003 .................................................................................. 64
Ilustración 16 - Mapa ISO 27001.......................................................................................... 67
Ilustración 17 - Modelo de capacidad de procesos .............................................................. 73
Ilustración 18 - Procesos COBIT5 ......................................................................................... 77
Ilustración 19 - Evolución hacia COBIT5 ............................................................................... 79
Ilustración 20 - Principios COBIT5 ........................................................................................ 80
Ilustración 21 - Habilitadores de COBIT5 ............................................................................. 81
Ilustración 22 - Dimensiones de los Habilitadores COBIT5 ................................................... 83
Ilustración 23 - Interacción gobierno y gestión TI ................................................................ 84
Ilustración 24 - Marco ITIL .................................................................................................. 98
Ilustración 25 - Ciclo de vida ITIL ......................................................................................... 99
Ilustración 26 - Procesos ITIL ............................................................................................. 102
Ilustración 27 - Mejora Continua ITIL ................................................................................. 105
Ilustración 28 - Introducción a TOGAF ............................................................................... 110
Ilustración 29 - ADM TOGAF .............................................................................................. 112
Ilustración 30 - Mapa ZACHMAN ....................................................................................... 135
Ilustración 31 - Matriz ZACHMAN ...................................................................................... 139
Ilustración 32 - PMI restricciones ...................................................................................... 141
Ilustración 33 - PMI Nuevas restricciones .......................................................................... 142
Ilustración 34 - PMI Procesos ............................................................................................ 142
Ilustración 35 - PMI ciclo de vida ....................................................................................... 144
Ilustración 36 - PMI áreas temáticas .................................................................................. 145
Ilustración 37 - Proyectos WBS .......................................................................................... 147
Ilustración 38 - PMI matriz ................................................................................................ 148

Ilustración 39 - Actividades de la matriz ............................................................................ 149

Ilustración 40 - CMMI niveles de madurez ......................................................................... 154
Ilustración 41 - Estructura CMMI ....................................................................................... 157
Ilustración 42 - Areas de proceso CMMI ............................................................................ 158
Ilustración 43 - Ejemplo GAP CMMI ................................................................................... 160
Ilustración 44 - Acreditación CMMI ................................................................................... 160
Ilustración 45 - Mapa COSO............................................................................................... 163
Ilustración 46 - Principios COSO ........................................................................................ 165
Ilustración 47 - Cuadro de Mando Integral de TI ................................................................ 178
Ilustración 48 - Priorización de procesos ........................................................................... 180

5 Título del Trabajo y Resumen
Normas y Marcos relacionados con la implementación de esquemas

de Gobierno de la Tecnología de la Información.
Resumen: Este trabajo tendrá como objetivo integrar los conocimientos de las
materias de la Maestría y aplicarlos para analizar y entender, cual es el estado del arte
en relación a los principales marcos de trabajo existentes a nivel internacional para la
implementación del Gobierno de la Tecnología de la Información y su importancia en
el plan estratégico de la organización.
Palabras Clave: CIO, CEO, Gobierno, Tecnología de la Información, Estrategia, Marcos
6 Dedicatoria y Agradecimientos
Dedicado a mis hijas, Sofía, Julia y Carolina
A todos los que quieren ser un poco mejor cada día
Un especial agradecimiento a Raúl Saroka y Claudio Freijedo que me convencieron de

cursar esta Maestría.
A mí Tutor, colega y amigo Gustavo Díaz.

7 Glosario
A los fines de este trabajo y dado el uso de diversa terminología existente en la industria
de la tecnología de la información (en muchos casos usando el mismo término para
diferentes conceptos), a continuación, se establece el significado con el cual ha sido
utilizado cada uno.
TI: Tecnología de la información.
ESTANDARDES: Hace referencia en forma global a todas las leyes, normativas y marcos
de trabajo relacionados con la TI.
GOBIERNO DE TI: Refiere a los procesos de gobierno de TI que implementa cada

organización, con el fin de establecer la priorización, decisión y las líneas de acción,
monitoreando el desempeño, el cumplimiento y los resultados obtenidos por la gestión.
GESTION DE TI: Refiere a los procesos que tienen a cargo el planeamiento para construir,
implementar y ejecutar los planes de TI definidos y alineados al negocio.
GESTION ORGANIZACIONAL: Hace referencia a la función de gestión en cualquier

temática de la organización. Es sinónimo del término inglés, “management”.
LEY: Reglas establecidas por una autoridad superior y obligatorias, para regular aspectos
de diversa índole en la sociedad y las organizaciones. Pueden ser leyes Nacionales o de
otros países que por diversos motivos deban cumplirse en Argentina.
NORMA: Reglas establecidas por una autoridad superior y obligatorias, para regular
aspectos específicos de una industria o temática. En este trabajo se utiliza para las
regulaciones del Banco Central de la República Argentina, como sinónimo de
“Comunicación”, que es de cumplimiento obligatorio para dicha industria.
NORMAS ISO: Familia de normas de alcance internacional y utilización optativa por parte
de las organizaciones, para diversas temáticas. En este trabajo se mencionan las
relacionadas con la TI. La International Organization for Standardization –ISO/IEC- es
quien las define.
MARCOS DE TRABAJO: Se utiliza como la traducción de “Frameworks”. Definen según la

temática a la cual se refieran, diversos principios, conceptos y prácticas que deben ser
implementadas para un eficiente logro las metas establecidas. Utilizaremos el término
“marco” como sinónimo.

MARCO TEÓRICO: Es un capítulo de este documento en el cual se sintetizan los diversos

temas conceptuales que se vieron en la Maestría y han sido utilizados.
PRÁCTICAS: Conjunto de actividades que se utilizan de una forma continuada y conforme

a determinadas reglas. Normalmente los frameworks, sugieren un conjunto de prácticas,
que han demostrado ser útiles en una temática para la gestión.
HERRAMIENTAS: Instrumento que sirve para realizar una actividad o un trabajo. Por
ejemplo, en este documento, se definen como herramientas, a planillas para priorizar
procesos, calcular indicadores de desempeño y otras actividades.
CASOS ESTUDIADOS: En este trabajo se hace referencia al estudio de diversos casos

empresariales analizados por el autor en relación a la temática, hayan sido ejecutados
por terceros o experimentados directamente por el autor.
CEO: Refiere al gerente general de una organización, en inglés chief executive officer.
CIO: Refiere al ejecutivo principal de tecnología de la información de una organización,

en inglés chief information officer.

8 Resumen Ejecutivo
Este trabajo final, contiene un análisis de los beneficios de disponer de un eficiente

gobierno y gestión de la tecnología de la información. Se describen las principales normas
y marcos de trabajo existentes a nivel internacional, para llevarlo a la práctica.
En los fundamentos teóricos se analiza como eje central, el planeamiento estratégico

organizacional y el gobierno de la tecnología de la información, como una herramienta
que colabora con la visión de la organización, dado que la TI es un canal conducente que
facilita el cumplimiento de los objetivos de negocio.
Como cuerpo central del trabajo, se analizan con un enfoque resumido y didáctico, 19
estándares utilizados, relacionados con la temática de este estudio. Los mismos están
compuestos por 1 ley, 1 norma Nacional, 1 norma internacional, 8 normas ISO y 8 marcos
de trabajo específicos para diversos tópicos del gobierno y gestión de la TI.
En las conclusiones y recomendaciones se detallan temáticas y ejemplos de

instrumentos concretos, referidos a:
 El beneficio cuantitativo y cualitativo de implementar procesos de gobierno de TI en las

organizaciones.
 Un análisis sobre los enfoques de “certificar normas” o gobernar la TI.
 Tomar como base el modelo COBIT5 y la ISO 38500, y a partir de allí complementar el
resto de los marcos necesarios para la organización.
 Transitar las fases del ciclo de vida de la implementación de mejoras.
 El diseño y uso de un “Cuadro de mando integral de TI” para gestionar.
 La utilización del modelo de madurez de procesos de la ISO 15504, y un método de

ejemplo para priorizar procesos en relación a las metas del negocio.
 Sugerencias para el uso de marcos de trabajo, tomando lo mejor de cada uno para las
necesidades de cada organización, e implementarlo en forma simple pero efectiva que
pueda ser monitoreado con el cuadro de mando integral de TI.
Como cierre, se establece que cada organización, no puede escapar a la tarea de realizar
un minucioso análisis de sus necesidades y los estándares descriptos, que, en forma total
o parcial, deben ser utilizados para una gestión integrada del gobierno de TI, con el fin de
consolidar los objetivos del negocio.

9 Introducción
La Maestría en Gestión Estratégica de Sistemas y Tecnologías de la Información, tiene un

foco particular en la formación del profesional, para poder desempeñarse en una
organización de cualquier tipo, en actividades de gestión de TI, mucho más involucrado
en el núcleo del negocio, o sea en el alineamiento con la consecución de los objetivos
estratégicos organizacionales. Esta es la función del CIO (chief information officer).
Este trabajo, se enfoca en particular, en un eje que debe garantizar la función de gestión,
tanto del CEO como del CIO, que es la “Gobernabilidad de la TI”, lo cual debe asegurar
que toda inversión y esfuerzo que realice la organización en este campo, tiene que
contribuir fuertemente con la consecución de resultados, en línea con los objetivos
definidos por el directorio.
Las tecnologías de la información, brindan hoy una gran posibilidad de hacer fuertes
cambios en la forma en la cual se desarrolla el “negocio” de la organización. Sin embargo
esto tiene asociado, un conjunto de riesgos que deben gestionarse.
Por lo expuesto anteriormente, es de fundamental importancia que se incorpore el

concepto de “Gobernabilidad de la TI” y esta incorporación finalice con procesos
implementados y gestionados, con el fin de que todas las decisiones de TI estén alineadas
con el plan estratégico del negocio y, tanto el CEO como el CIO, cuenten con instrumentos
de gestión para la toma de decisiones.
Para ello, en este trabajo se profundizará en la función de la “Gobernabilidad” (e incluyo

la gestión de TI como base necesaria para disponer de procesos para un gobierno) y en el
análisis de diversos estándares y marcos para su implementación.
Es importante destacar que para todos los marcos analizados, no se tratará de reproducir
en detalle todo el material existente disponible, sino el objetivo es hacer un compendio
de lo importante y hacer foco en la “usabilidad práctica” de dichas herramientas.
Por último, se realiza una conclusión y recomendación, con el fin de colaborar en que,
todo lo expuesto en este trabajo, pueda llevarse a la realidad, con las restricciones que
ésta presenta. La bibliografía, las citas realizadas y las fuentes utilizadas, surgen de
diversos casos estudiados, y una nutrida cantidad de material académico y profesional
de nivel internacional analizado, como así también de esta Maestría.

10 Planteo del Problema
La globalización de los mercados, el acelerado desarrollo tecnológico y la dinámica en la

competitividad en todos los productos y servicios, son factores que están enfrentando
los directivos de empresas, ante el dilema de incorporar nuevos procesos y soluciones a
la organización, haciendo uso de las tecnologías de la información de manera eficaz y
eficiente.
Hace ya muchos años, se ha instituido y formalizado la función del CIO (Chief Information
Officer) como un rol innovador y transformador, gracias a la inteligente aplicación de las
nuevas tecnologías disponibles, integradas al negocio. Importantes analistas del
mercado como Gartner y revistas como CIO Magazine plantean que los CIOs deben ser
más estratégicos y no sólo proveedores de servicios de tecnología: deben ser socios de
negocio.
Dicho rol, implica que el CIO en “sociedad” con el CEO de la organización, deben
implementar y llevar a cabo el concepto de “Gobernabilidad de las Tecnologías de la
Información”.
La problemática actual, reside en que aún no está totalmente alineado el rol de las
Tecnologías de la información, a los procesos de negocio y objetivos estratégicos de la
organización, y se mantiene en el área de tecnología algún tipo de exclusividad en la toma
de decisiones sobre inversiones, tendencias, niveles de servicio, calidad y otras variables,
que no deberían ser definidas y administradas en forma exclusiva por dicho sector o
solamente por el CIO, dado que tienen un impacto fundamental en el cumplimiento del
plan estratégico organizacional.
Para resolver este problema, es necesario que se implementen marcos de trabajo

compartidos por el CEO y el resto de los directivos. Si la TI se van a gestionar como un
negocio dentro del negocio, el concepto de gobierno (o sea los procesos en que se
soporta la dirección para asegurar el logro de objetivos, y mantener bajo control las
variables de inversión y riesgo) es también aplicable a la gestión de TI.
La dirección necesita entender la importancia estratégica de la TI, y debería tener en su

agenda el gobierno de la misma, siendo entonces la responsable del comportamiento de
un conjunto de variables, tal como la dirección lo hace con otras áreas, como ser finanzas
y recursos humanos, por mencionar algunos ejemplos.
El desafío es entonces organizativo, de procesos y fundamentalmente cultural, siendo los

principales actores en producir este cambio el propio CEO, el comité directivo,
conjuntamente con el CIO, y trabajar para que existan marcos y procesos de
Gobernabilidad de la TI.

11 Objetivos
11.1 Objetivo General
Analizar el estado del arte en relación a los principales estándares existentes a nivel
internacional, para la implementación de esquemas de Gobierno y Gestión de la
Tecnología de la Información en las organizaciones.
11.2 Objetivos Específicos
 Integrar los conocimientos adquiridos en esta Maestría y aplicarlos

específicamente al análisis de la problemática planteada.
 Describir y analizar el estado actual del arte de los principales estándares

existentes a nivel internacional, para la implementación del Gobierno y la Gestión
de la Tecnología de la Información.
 Desarrollar un conjunto de recomendaciones para la temática planteada, con el

fin de maximizar el impacto estratégico organizacional, de la implementación de
esquemas de Gobierno de la Tecnología de la Información.

12 Justificación y Relevancia de este Trabajo
En el “planteo del problema”, queda explícito que el desafío de implementar un buen

gobierno de TI tiene un fuerte componente organizacional y cultural.
En este trabajo se avanzará en analizar diversas herramientas, proponer métodos de

control de gestión y brindar una argumentación con lenguaje organizacional y no técnico,
para que los directivos y profesionales puedan encarar la gestión del cambio, con una
base previa.
La definición de gobierno de TI para el “IT Governance Institute” dice: “Es una estructura
de relaciones y procesos para dirigir la organización, con el objeto de alcanzar los
objetivos estratégicos y añadir valor a los mismos, mientras se equilibran los riesgos y el
retorno de la inversión en tecnología y sus procesos asociados”1.
Por lo tanto, lograr diseñar e implementar estos procesos que impactan en el

funcionamiento de la organización, es una tarea compleja y debe tener la total convicción
y apoyo del máximo nivel directivo.
En los diversos capítulos de este trabajo, se podrán analizar los diversos estándares
existentes en la actualidad, la interrelación colaborativa entre ellos y las superposiciones,
con el fin de que cada profesional pueda adoptar lo que considere más apropiado para
su organización.
Sin dudas que el mejor modelo a implementar para la gobernabilidad (e incluyo la gestión
de TI como base necesaria para disponer de procesos para un gobierno), no es la suma de
todos los estándares que se analizan, sino seleccionar aquellos que apuntalen el
cumplimiento de los objetivos y las características de cada organización.
En este contexto, este estudio proporcionará en forma integrada y sintética, una visión
del universo analizado y brindará lineamientos para poder ejercer un control de gestión
por indicadores del modelo final, que cada uno seleccione para la implementación del
gobierno de TI.
1
‘About Governance of Enterprise IT’. Consultado: Noviembre 2015, de http://www.isaca.org/about-isaca/it-
governance-institute/pages/default.aspx

13 Metodología de elaboración del Trabajo y Alcance
La metodología que se utilizó para el desarrollo del trabajo, involucró aspectos empíricos
de los casos analizados, como así también, aspectos teóricos del marco conceptual
descripto.
En relación a los primeros, se relevarán los diferentes marcos de trabajo, enfoques y

prácticas que actualmente las organizaciones están utilizando para el gobierno de las
tecnologías de la Información. Para ello, se buscó información en diferentes fuentes tales
como: universidades, consultoras especializadas, Gartner Group, otros y se ahondó en
encuestas y artículos sobre la temática, en fuentes relevantes. Esta etapa es una
investigación exploratoria – descriptiva.2
Respecto a la perspectiva temporal, el análisis tuvo un enfoque actual y de corto /

mediano plazo. Haciendo foco en la información y casos recientes.
Se utilizaron medios de recolección de datos primarios:
Entrevistas de tipo exploratoria
 A los CEOs y CIOs de empresas
 A especialistas en estrategias organizacionales y tecnología
Se utilizaron medios de recolección de datos secundarios:
 Datos estadísticos de fuentes validadas
 Investigaciones relacionadas con la temática
 Artículos relacionados y sitios en Internet
En relación al sustento conceptual, está descripto en detalle en el capítulo “Marco

Teórico”.
En base al material recolectado, se estructuró el contenido de este trabajo, arribando a

un diagnóstico y a lineamientos propios, para abordar la problemática planteada, con un
alcance enfocado particularmente para Argentina.
2
Mayoral, Luisa (2001). Metodología del trabajo de Tesis. Tandil: Editorial CEAE.

14 Marco Teórico
Se desarrollará una selección de conocimientos de materias que componen la

Maestría y tienen relación con este trabajo. El objetivo del marco teórico es el de
disponer de un digesto de conocimientos que sustenten la realización de los diversos
capítulos.
Este desarrollo, permite para mi caso particular, profundizar aquellos conceptos o

metodologías vistas, que me han resultado de alto valor para mi formación, y
explorarlas y aplicarlas en una temática específica, como lo es este Trabajo Final.
Las materias que se analizaron y que componen este marco teórico integrado, con sus
principales temas, son:
 Infraestructura y Arquitectura Tecnológica.

 Desarrollo de Sistemas de Información.
 Gestión de Proyectos.
 Gestión de Procesos.
 Análisis Organizacional.
 Gestión Estratégica de las Tecnologías de la Información.
 Gestión del Conocimiento.
 Gestión de la Seguridad de la Información.
En los siguientes “seis capítulos”, se desarrollará un compendio del marco teórico,

tomando diversos elementos de las materias mencionadas.
Finalizados estos capítulos, se comenzará con el análisis objetivo de las normas ISO y
los marcos de trabajo de gobierno y gestión de TI” (incluyo la gestión de TI como base
necesaria para disponer de procesos para un gobierno), que son el eje de estudio de
este documento.

15 Planeamiento estratégico organizacional
En la medida que la Organización tenga clara su “visión“, podrá entonces desarrollar su

estrategia para alcanzarla. En ese sentido, antes de involucrar específicamente a las
Tecnologías de la Información, definiremos algunos conceptos.
ESTRATEGIA: “Es el patrón de una serie de acciones que ocurren en el tiempo”3.
Este modelo enfatiza la acción en donde la organización “tendría una estrategia”, aún
cuando no tuviera planes definidos, incluso aunque nadie en la empresa dedique tiempo
a establecer objetivos formales.
Todo desarrollo de la estrategia, avanza sobre dos instancias, una deliberada y la otra
emergente.
PENSAMIENTO ESTRATEGICO: Mintzberg, plantea claramente las relaciones de

complementariedad y ambigüedad entre el pensamiento intuitivo que origina iniciativas
originales provocadas por la creatividad y la innovación, y su transformación;
intermediando el razonamiento analítico en una estrategia o curso de acción que va
tomando forma en sus etapas de elaboración, formulación e implementación como
proceso interno del planeamiento estratégico. Queda claro de esta definición, que
“pensar estratégicamente” no implica siempre, que exista un “plan estratégico”.
Otras definiciones difundidas de estrategia a lo largo de la historia, son:
Peter Drucker – Estrategia de la organización es la respuesta a dos preguntas: ¿Qué es

nuestro negocio?, ¿Qué debería ser? 4.
Alfred Chandler - Define a la estrategia como la determinación de metas y objetivos

básicos de largo plazo de la empresa, la adición de los cursos de acción y la asignación de
recursos necesarios para lograr dichas metas5.
Michael Porter - La estrategia es la creación de un posicionamiento de valor único,

escogiendo actividades diferentes de la competencia6.
3 Mintzberg, Henry (1993). El proceso estratégico. México: Prentis Hall Hispanoamericana.

4 Drucker, Peter (1954). The practice of management. USA: Harper & Row.
5 Dupont Chandler, Alfred (2003). Strategy and Structure. USA: Beard Books.
6
Porter, Michael (2009). Estrategia competitiva. Argentina: Ediciones Pirámide.

PLANEAMIENTO ESTRATEGICO: Es una herramienta que permite a las organizaciones

prepararse para enfrentar las situaciones que se presentan en el futuro, y está
entrelazado con el proceso completo de la dirección de modo inseparable.
Por lo tanto, queda explícito que el proceso adecuado para que una organización innove
y crezca en forma sostenida, parte de la “visión” unida a un “pensamiento estratégico”,
lo cual finaliza en un “planeamiento estratégico” para el logro de los objetivos y las
metas en el mediano y largo plazo.
GESTION ESTRATEGICA: “La gestión estratégica es un camino que se recorre en conjunto

por los actores de la organización en forma continua, identificados en forma permanente
con la visión y el compromiso con las técnicas analíticas, para dar cumplimiento al plan
estratégico”. 7 A continuación se grafican los niveles: 8
Ilustración 1 - Plan estratégico y táctico
7
Mintzberg, Henry (1993). El proceso estratégico. México: Prentis Hall Hispanoamericana.
8
Material preparado para clases en el MBA-UBA, por Díaz G. y Piorun D. 2010, Buenos Aires.

De lo expresado anteriormente y la ilustración, puede entonces enmarcarse cómo se

transita desde la visión al plan estratégico.
En la ilustración se observa, además, diferentes capas con mayor nivel de detalle y los
principales responsables, en términos generales según la organización. Cada una de las
capas inferiores del gráfico, está incluida en la capa superior a la cual reporta.
Desde la visión y el pensamiento estratégico, puede derivarse en un plan estratégico

organizacional a mediano y largo plazo. A partir de dicho insumo, el CEO define el modelo
del negocio y el plan de ejecución del mismo. Esto es un insumo para llegar al plan
estratégico de TI, que principalmente estará en manos del CIO, el cual debe estar en
consonancia con el negocio (desde ya que en algunos casos la propia TI es parte del
negocio), y desde ya el CEO debe estar también involucrado en su elaboración y
aprobación.
Luego se define el plan táctico que el CIO elaborará en conjunto con el Gerente de
sistemas de la organización (o el rol que tenga a cargo la operación de la TI). En el mismo
se definen objetivos, metas, presupuestos, prioridades y lineamientos de ejecución.
Luego se define el plan operativo de TI, el cual será ejecutado bajo la responsabilidad del
área de sistemas, con los proyectos particulares a implementar y el nivel esperado para
la operación.
Si estos planes estratégico y táctico están elaborados a partir de una sustancia creativa y
sólida, sobre la visión de la organización y el futuro a donde se desea encaminar a la
misma, serán entonces herramientas de mucha utilidad para dirigir la acción cotidiana
enfocada en las metas y objetivos definidos. De no ser así, sólo serán instrumentos
formales que no colaboran con el crecimiento, sino solamente con el cumplimiento de
requisitos formales. Existen ambas situaciones en las organizaciones actuales.
Lo expresado en este capítulo, son las bases del planeamiento estratégico de TI, que
desde ya pueden presentarse con diversos ajustes y enfoques según cada cultura
organizacional, y con diferente profundidad y formalismo, según se trate de grandes,
medianas o pequeñas organizaciones.
Disponer de este tipo de enfoques y herramientas de planeamiento estratégico, es uno

de los pilares que el CEO y el CIO deben tener para poder asegurar la permanente
alineación de la TI al negocio y esto dará paso al concepto y prácticas de Gobernabilidad
TI que se desarrollan en este trabajo.

16 El Gobierno de la tecnología de la información
La Estrategia de TI como parte del Plan Estratégico Global
Ilustración 2 - Estrategia de TI
Como puede apreciarse en este esquema y según lo explicitado en el capítulo anterior, la

estrategia de TI es de suma importancia en la media que esté embebida en la estrategia
global de la organización.
Estas responsabilidades exceden al propio CIO, y tienen que participar el CEO y el comité
de directores que representan a los accionistas (en el caso de una empresa privada).

Sin dudas, lograr que todos los componentes de un plan estratégico se desarrollen de
una forma ordenada y tal cual fue pensado, es muy difícil, pues una organización por
definición es un entorno complejo. Vale analizar la siguiente definición:
“La organización es un sistema complejo pues operan múltiples lógicas y diversidad de

fuerzas que no se conjugan en un todo armónico o estable y multiplicidad de objetivos
inconsistentes, donde se mezclan factores de índole política, cultural, económica y
social”.9
Por lo tanto, la capacidad de gestión del CEO y del CIO, serán fundamentales e impactarán
en forma directa en los resultados de la organización y el cumplimiento del plan
estratégico global, y el de la TI.
GOBIERNO DE LA TECNOLOGÍA DE LA INFORMACIÓN
Como ya se mencionó y se citó, en el capítulo 12, el “IT Governance Institute” define al

gobierno de la TI de la siguiente manera: “Es una estructura de relaciones y procesos para
dirigir la organización, con el objeto de alcanzar los objetivos estratégicos y añadir valor
a los mismos, mientras se equilibran los riesgos y el retorno de la inversión en tecnología
y sus procesos asociados”
Implementar el gobierno de la tecnología de la información, es claramente oportuno y

beneficioso para cualquier tipo de organización moderna, que tenga como objetivo
disponer de un management eficiente de la organización.
Un estudio publicado en Harvard 10, concluyó que sobre 250 empresas relevadas a nivel
mundial, aquellas empresas que tienen un gobierno de la Tecnología de la Información
de gran calidad, muestran al menos, un 20% más de rentabilidad que aquellas con un
gobierno pobre, dados los mismos objetivos.
9
Etkin, Jorge R. (2005). Gestión de la Complejidad en las organizaciones. Buenos Aires: Editorial Granica.
10
Ross, J. W.; Weill, P. (2004). Gobierno de TI: Cómo los mejores gestionan los derechos de decisión de TI para
obtener resultados superiores. EEUU: Harvard Business School Press.

Una buena implementación del Gobierno de la Tecnología de la Información (TI), debe

llevar a la organización a tener claramente las respuestas a estas preguntas básicas:
 ¿Cómo conseguir valor mediante el uso de TI?
 ¿Están contemplados los riesgos de TI para el negocio?
 ¿Cómo se relaciona el costo de TI con los resultados que aporta al negocio?
 ¿Cuánto depende mi negocio de los proveedores externos?
 ¿Mi personal de TI es adecuado en cantidad y calidad?
 ¿Mi entorno de TI es seguro?
 ¿Cuánto colabora TI en soportar los servicios críticos del negocio?
 ¿Cómo se desarrollan los proyectos de TI en mi organización?
En este trabajo se incluye el análisis de la “gestión de TI” como base necesaria para
disponer de procesos sólidos en un “Gobierno de TI”.
Otras definiciones de “GOBIERNO DE TI”:
Para el IT Governance Institute:
“Es el proceso de administración que asegura la obtención de los beneficios esperados

de la tecnología de información (TI) de manera controlada para acrecentar el éxito
sostenido de una empresa a largo plazo”.
Para ISACA:
“Es el uso eficiente de los recursos de TI para apoyar el cumplimiento de los objetivos del
negocio”.
Para el Australian Standard for Corporate Governance:
“Sistema por el cual el uso presente y futuro de la TI es controlado. Involucra evaluar y

dirigir planes del uso de la TI que soporten a la organización, así como monitorear el uso
de estos planes. Incluye además políticas y estrategias de uso de TI en la organización”.

Alcance de la Gobernabilidad
Las definiciones anteriores, muestran claramente el objetivo del gobierno de TI. El

alcance de las funciones de dicho gobierno, podemos resumirlas en:
 Definir de las iniciativas de gobierno: alineación al negocio, entrega de valor,

recursos, riesgos, desempeño.
 Establecer las políticas, procesos y procedimientos de TI.
 Disponer de un mapa estratégico en cascada de objetivos propios del negocio,

objetivos de TI para el negocio, objetivos de desempeño de TI, estructura de TI
(procesos, aplicaciones, infraestructura y personal), tal como lo define el
planeamiento estratégico.
 Evaluar continuamente la madurez de los procesos de planificación y

organización: alineación con la estrategia de la organización, eficiencia en la
utilización de recursos, comunicación de objetivos de TI, gestión de riesgos,
calidad de servicio, estándares, metodologías y prácticas empleadas.
 Evaluar continuamente la madurez de los procesos de adquisición e

implementación: alineación de proyectos con objetivos de la organización,
oportunidad y costo de los proyectos, implementación ordenada y controlada de
aplicaciones a producción, gestión de los cambios.
 Evaluar continuamente la madurez de los procesos de entrega y soporte: relación

costo-beneficio de los servicios provistos por TI, productividad del negocio,
gestión de seguridad de la información.
 Evaluar continuamente la madurez de los procesos de supervisión y evaluación:

indicadores de desempeño, efectividad y eficacia del control interno, mecanismos
de control sobre la información.
 Evaluar continuamente los controles de las aplicaciones en los procesos de

desarrollo, gestión de cambios, seguridad y operación.
 Definir la estructura, contenido y utilización de un método e instrumento de

cuadro de mando 11 de TI para la toma de decisiones directivas.
11
El concepto de Cuadro de Mando Integral – CMI, fue presentado en la revista Harvard Business Review, en el
número de Enero/Febrero de 1992.

Beneficios de la gobernabilidad
Los beneficios que obtendrá la organización y, por ende, su equipo directivo, al

implementar procesos de Gobierno, se pueden resumir en:
 Mantener la alineación de la gestión de TI con los objetivos estratégicos y del

negocio de la organización.
 Aprovechar y utilizar las mejores prácticas del mercado y controles estándar,

independientes de tecnologías específicas utilizadas.
 Establecer un lenguaje común que sea comprensible entre todos los interesados
e involucrados en la gestión de TI y el negocio.
 Contribuir al cumplimiento de requisitos normativos y regulatorios específicos de

cada organización y su contexto.
 Implementar una metodología estándar de evaluación de madurez de procesos y

los mecanismos y prácticas de mejora continua.
 Estar preparados para afrontar los cambios y poder justificar cada decisión de TI
en forma metodológica y su impacto en el negocio.
 Disponer de una visión integrada para el responsable de TI y del negocio.
De acuerdo a lo desarrollado en este trabajo, existen diferentes normas y frameworks 12

para implementar la gobernabilidad TI. Será fundamental, contar con un claro
planeamiento estratégico, tal lo expresado en el capítulo de referencia de este trabajo.
Con estos insumos y definiciones que la propia organización, debe establecer al más alto
nivel, se puede entonces comenzar con la implementación de procesos de Gobierno de
TI, teniendo claro que esto no significa solo una implementación de nuevos
“procedimientos”, sino que involucra un cambio cultural en el comportamiento y la toma
de decisiones de la dirección, en relación a las tecnologías de la información.
12
‘The Framework defines enterprise risk management and describes principles and concepts, providing
direction for all levels of management in businesses and other organizations to use in evaluating and enhancing
the effectiveness of enterprise risk management’.
Enterprise Risk Management — Integrated Framework Executive Summary. (2004). Coso.org. Consultado: Enero
2016, de http://www.coso.org/documents/coso_erm_executivesummary.pdf

Temas claves para decisiones de TI
Las decisiones que se toman para las áreas de tecnología de la información, son críticas y
claves para el desarrollo del negocio y el plan estratégico de la organización. Por este
motivo, las mismas (a nivel estratégico) deben sobrepasar a las propias áreas de
tecnología, y enmarcarse como decisiones del Gobierno de TI que deben darse en los más
altos niveles de dirección de la organización.
A continuación, definimos un conjunto de preguntas ampliadas (varias preguntas fueron

tomadas de un documento del MIT 13), para que un buen gobierno de TI y sus procesos,
puedan contestar:
1. ¿Cómo se trasladan los principios del negocio a principios de TI, de manera tal de guiar
las decisiones de TI?
2. ¿Cuál es el rol de TI en el negocio?
3. ¿Cuáles son los comportamientos deseables de TI?
4. ¿Cuál es el core del negocio de la organización y cómo es visto por TI?
5. ¿Qué información de ese core se procesa y cómo se integran los datos?
6. ¿Qué capacidades técnicas deben estandarizarse y ser soportadas en forma eficiente

por TI?
7. ¿Cuál tecnología debe elegirse y cómo se enfocan las iniciativas de TI?
8. ¿Qué infraestructura de servicio es crítica para los objetivos de la organización?
9. ¿Cuál es el nivel de servicios que debe asegurarse para resolver los requerimientos?
10. ¿Cuál es el plan para las actualizaciones tecnológicas?
11. ¿Qué infraestructura de servicios puede ser tercerizada?
12. ¿Están contemplados los riesgos de TI para el negocio?
13. ¿Cuánto depende mi negocio de los proveedores externos?
14. ¿Mi personal de TI es adecuado en cantidad y calidad?
15. ¿Mi entorno de TI es seguro?
13
Ross, J., Weill, P. (2005). A Matrixed Approach to Designing IT Governance. MIT Sloan Management Review,
Nro 46.

16. ¿Cómo debe definirse la inversión en TI?
17. ¿Qué procesos o nuevas tecnologías pueden aportar oportunidades para nuevos
negocios o mercados?
18. ¿Cuándo debe utilizarse tecnología estándar de mercado y cuándo se aceptaría una
excepción?
19. ¿Quién es el responsable de obtener los resultados organizacionales que se buscan a

partir de cada proyecto de cambio que utiliza TI para agregar valor?
20. ¿Cuál es la distribución actual del portafolio de proyectos de TI?. ¿El portafolio actual
de proyectos de TI es consistente con los objetivos estratégicos de la organización?
21. ¿Cuál es el plan actual de investigación?. ¿El mismo refleja la importancia del
crecimiento del negocio esperado y los objetivos futuros?
En este trabajo se abordan diversos marcos que componen el gobierno de TI,

particularmente la ISO 38500, la 31000 y COBIT5.

Evaluación del Gobierno de TI
Es importante para una organización, saber cuál es el estado evolutivo actual del gobierno
de las tecnologías de la información y cómo las mismas están colaborando con los
objetivos estratégicos de la organización.
A continuación se presenta un tablero de control, con un testeo simple pero que permite
tener un indicador cuantitativo para evaluar dicho estado. El siguiente cuadro ha sido
diseñado para este trabajo, en base a documento publicado por el MIT sobre la temática.14
Ilustración 3 - Evaluación gobierno TI
Este tablero puede servir para un primer acercamiento cuantitativo sobre el estado del
gobierno de TI. A lo largo de este trabajo y en las conclusiones, se propondrá una
herramienta detallada específica de cuadro de mando integral de TI.
14Ross, J., Weill, P. (2005). A Matrixed Approach to Designing IT Governance. MIT Sloan Management Review,
Nro 46.

Marco Conceptual
A continuación se explicita un mapa conceptual, en el cual claramente se pueden

observar los alcances de algunos de los distintos estándares que actualmente están
vigentes en el mercado, para gobernar y gestionar la TI, desde las distintas necesidades
de la organización. Este mapa forma parte de la documentación oficial de COBIT 15, creado
por la organización ISACA 16.
Ilustración 4 - Mapa de Frameworks
Puede observarse que la norma ISO 3850017, especialmente creada para la

gobernabilidad de TI, es la que mayormente abarca dicha capa en la cual están las
funciones de evaluación, dirección y monitoreo. El framework COBIT5 está totalmente
alineado con dicha norma. La otra norma que se superpone en una parte con la
mencionada, es la ISO 3100018, especialmente creada para colaborar con las funciones
de dirección en la gestión de riesgos. Cada una de las siglas de los estándares
mencionados en este cuadro, se ampliarán a continuación.
15
Control Objectives for Information and related Technology
16
Information Systems Audit and Control Association
17
Corporate governance of information technology
18
ISO 31000. Risk management – Principles and guidelines, framework and a process for managing risk.

Como puede observarse en el mapa, existen otras 3 franjas horizontales de alcance de

funciones, como ser: alineamiento, planeamiento y organización, la segunda es
construcción, adquisición e implementación; y la tercera entrega, servicio y soporte.
Estas tres franjas pertenecen a la gestión de TI.
A continuación haremos referencia (en forma resumida en este capítulo) a cada uno de
los estándares mencionados (se han sumado algunos otros complementarios que serán
desarrolladas en este trabajo) con el fin de conocer su ámbito particular de aplicación:
 (COBIT) Control Objectives for Information and related Technology: Es un modelo

de referencia que describe 37 procesos relacionados con TI (32 de gestión y 5 de
gobierno corporativo) y que pueden ser comunes a todas las organizaciones. Cada
proceso está descripto en detalle, incluyendo entradas y salidas, actividades,
objetivos, indicadores de desempeño y un modelo básico de madurez. Fue creado
por la organización ISACA pero en la actualidad es mantenido por ITGI (Instituto de
Gobernanza de TI). Está alineado con la norma de gobernabilidad de TI - ISO 38500.
 ISO/IEC 38500:2008 Corporate governance of information technology, (basado en

AS8015-2005), define un marco de trabajo para el gobierno de TI que permite apoyar
a la alta dirección en cuanto a los aspectos legales, éticos y normativos relacionados
con el uso de TI, así como en el uso efectivo y eficiente de la tecnología de la
información dentro de la organización. ISO/IEC 38500 es aplicable a organizaciones
de cualquier tamaño, públicas o privadas, con o sin ánimo de lucro. La componen 6
principios y 3 grandes actividades (evaluar, dirigir, monitorear) que son la base
conceptual de la norma.
 (ITIL) Information Technology Infrastructure Library: Es un conjunto de conceptos y

prácticas para la gestión de servicios de las tecnologías de la información y las
operaciones relacionadas con los mismos. ITIL brinda descripciones detalladas de un
extenso conjunto de procedimientos de gestión creados para ayudar a las
organizaciones a lograr calidad y eficiencia en las operaciones de TI. Está alineado con
la norma ISO 20000. Se compone de un ciclo de vida con 5 etapas, las cuales son
descriptas por 30 procesos y funciones.

 ISO/IEC 20000 - Service Management: Publicada por ISO (International Organization

for Standardization) e IEC (International Electrotechnical Commission) el 14 de
diciembre de 2005, es el estándar reconocido internacionalmente en gestión de
servicios de TI (Tecnologías de la Información).
La serie 20000 proviene de la adopción de la serie BS 15000 desarrollada por la entidad

de normalización británica, la British Standards Institution. La misma está soportada
por 7 grandes procesos / componentes, que se desagregan en un conjunto de
actividades que la organización debe cumplir.
 ISO 31000 - Es una familia de normas sobre Gestión del riesgo publicadas por la
International Organization for Standardization. El propósito de la norma ISO
31000:2009 es proporcionar principios y directrices para la gestión de riesgos y el
proceso implementado en el nivel estratégico y operativo. Esta norma proporciona
lineamientos y 11 principios a aplicar para gestionar los riesgos organizacionales. Esta
norma no es certificable, sino que se integra para mejorar esta temática, en otras
normas certificables, con la ISO 9001 del sistema de gestión de la calidad.
 PRINCE2 - Proviene del acrónimo en inglés PRojects IN Controlled Environments es

decir, gestionar proyectos, que manejan una carga importante de variabilidad y de
incertidumbre, en entornos controlados. Más que un conjunto de buenas prácticas,
PRINCE2 propone una metodología de gestión de proyectos que cubre, mediante lo
que se conoce como “Temáticas”, la Calidad, el Cambio, la estructura de roles del
proyecto, los planes, el riesgo y el progreso del proyecto, justificado por un Business
Case que debe ser revisado durante el ciclo de vida del proyecto y justificar en todo
momento el proyecto como consecución de los beneficios esperados. Establece un
modelo de procesos soportado en 4 niveles de gestión y define 5 roles en el
gerenciamiento del proyecto.
 PMBOK - Fue Desarrollado por el Project Management Institute (PMI), es una guía
con un conjunto de conocimientos en Dirección, Gestión y Administración de
Proyectos generalmente reconocidos como “buenas prácticas” y que se constituye
como estándar de administración de proyectos. La Guía del PMBOK comprende dos
grandes secciones, la primera sobre los procesos y contextos de un proyecto, la
segunda sobre las áreas de conocimientos específicos para la gestión de un proyecto.
Define 9 áreas temáticas y 5 procesos (con los cruces entre ambas que generan
actividades específicas), para el gerenciamiento de proyectos.

 ISO/IEC 27000 - Es una familia de normas, con estándares de seguridad, publicados

por la Organización Internacional para la Estandarización (ISO) y la Comisión
Electrotécnica Internacional (IEC). La serie contiene las mejores
prácticas recomendadas en seguridad de la información para desarrollar,
implementar y mantener especificaciones para los Sistemas de Gestión de la
Seguridad de la Información (SGSI). La norma certificable ISO 27001 actualizada 2013,
establece 14 dominios de incumbencia de la seguridad y 114 controles.
 CMMI: Integración de modelos de madurez de capacidades o Capability maturity

model integration, es un modelo para la evaluación de procesos de desarrollo,
mantenimiento y operación de sistemas (software), conjuntamente con la gestión del
proyecto. Las mejores prácticas CMMI se publican en los documentos llamados
modelos. En la actualidad hay tres áreas de interés cubiertas por los modelos de
CMMI: Desarrollo, Adquisición y Servicios. Explicita cinco niveles de madurez. En cada
nivel se establecen áreas de procesos y prácticas que deben ser cumplidas.
 TOGAF: The Open Group Architecture Framework o Esquema de Arquitectura del

Open Group, es un marco de trabajo de Arquitectura Empresarial que proporciona un
enfoque para el diseño, planificación, implementación y gobierno de una arquitectura
empresarial de información. Esta arquitectura está modelada, en cuatro
dimensiones: Negocios, Tecnología (TI), Datos y Aplicaciones. El Architecture
Development Method (ADM) cuenta con 9 fases.
 El ISO/IEC 15504, también conocida como Software Process Improvement Capability

Determination, abreviado SPICE, en español, “Determinación de la Capacidad de
Mejora del Proceso de Software”, es un modelo para la mejora, evaluación de los
procesos de desarrollo, mantenimiento de sistemas de información y productos de
software. Esta norma no está explícitamente en el mapa conceptual pues es utilizada
por la última versión de COBIT5, como marco de referencia para la evaluación de sus
procesos, motivo por el cual la menciono. Tiene definido niveles de madurez del 0 al
5 para los procesos, se utiliza como estándar, más allá de los procesos de software.

Además se analizarán en forma general, los siguientes estándares complementarios:
 La norma ISO 9001- Gestión de la Calidad

 La norma ISO 90003 – Aplicación al Software
 La norma ISO 21500 - Guidance on Project Management
 Arquitectura empresarial ZACHMAN
 Framework COSO
 Ley Sarbanes Oaxley
 Basilea III
 BCRA – Comunicación 4609 y complementarias
Como puede apreciarse, no hay falta de estándares, sino lo contrario.
También podemos afirmar que muchos conceptos y prácticas son comunes en los
diferentes marcos.
Lo realmente importante, es que cada organización pueda formar este “mapa de

herramientas para la gestión y el gobierno de TI”, con el fin de tomar aquellas que
permitan gestionar, medir, evaluar y mejorar, aquellos procesos que son críticos para la
organización y el negocio.
En simultáneo a lo expresado, hay que conseguir que se utilice el marco adecuado para
disponer de la “Gobernabilidad de la TI”, tal lo expresando en páginas anteriores, con el
fin de no perder el rumbo del aporte de la tecnología, para el negocio y los objetivos
organizacionales, lo cual en definitiva es consolidar la estrategia.

17 Desarrollo de Sistemas de Información
El desarrollo de software genera un componente de alto nivel de abstracción que finaliza

en un bien intangible, de difícil estimación y concreción pues también participa la mente
de quien lo recibe y modela.
Construir software no es lo mismo que construir una casa, dado que las diferencias con
los productos físicos son importantes. Un aspecto fundamental es que en la construcción
del software, no hay una tan clara separación entre las etapas de diseño y construcción.
Por ejemplo en la obra civil, los planos, o sea el diseño es una etapa muy clara en sí misma
donde se define todo lo necesario a nivel de detalle, en varios tipos de planos. Además,
puede simularse antes su visualización con una computadora y las estimaciones son
bastantes certeras en tiempos y costos para la próxima etapa de construcción
propiamente dicha. En la etapa de construcción, hay poco trabajo intelectual y mucho
especializado en la ejecución de la obra para que la misma refleje lo que dicen los planos.
Dado que esta es una actividad que tiene miles de años de madurez, existen métricas y
estándares para cada temática.
En el software, dicha diferenciación entre el diseño y la programación es más difusa y en

muchos casos se diseña en parte “mientras” se programa. Las metodologías
estructuradas o de cascadas, han intentado simular el comportamiento del resto de las
ingenierías y lo han llevado al desarrollo de software, con algún éxito en ordenar el
trabajo, pero no han llegado al éxito de convertir estos proyectos en una ingeniería
estandarizada y exacta.
Otras metodologías de desarrollo han venido a colaborar con esta problemática, y es así
que nacieron los métodos por iteraciones y los actuales denominados métodos ágiles,
que de alguna forma incorporan algún grado de informalidad a la pretendida ingeniería.
Otro aspecto, tiene que ver con la “intangibilidad” del producto de software. El
relevamiento de los requerimientos será muy diverso, ya que dependerá de dos grandes
cuestiones: por un lado, los intereses comunes del equipo asignado a realizar esta tarea,
respecto al producto de software (alcance, objetivos, necesidades, mejoras evolutivas,
etc.). Por el otro, el compendio personal-profesional de variables que cada uno de los
integrantes pone de manifiesto ante una determinada situación a resolver (experiencia,
educación, cultura, personalidad, etc.). Por lo tanto, los resultados de esta tarea serán
únicos e irreproducibles, por características inherentes del factor humano. Dicha
diversidad, se ha intentado capturar y formalizar desde minutas y gráficos hasta diversos
métodos hasta llegar a UML19, que se supone puede explicitar el comportamiento en un
“caso de uso”. Este aspecto genera una brecha (gap) cuando se prueba el software
19
The Unified Modeling Language™ - UML

terminado por el propio usuario, versus lo que él mismo “quiso decir” cuando lo definió.
Muchos métodos incorporan el concepto de prototipo u otras formas para reducir la
brecha, pero no deja de ser un aspecto diferenciador en relación a cuando se describe
“cómo” quiero una casa y la que puedo ver reflejada en maquetas u otros elementos
tangibles antes de su concreción.
El tercer punto, es que el software permite cosas que otras ingenierías no permiten (o
cuesta mucho). Por ejemplo en una casa terminada, agregar una habitación más en
planta alta puede ser imposible o tener un costo tan alto como el resto ya construido si
no fue prevista en el diseño original. En cambio el software tiene el inconveniente que
parece simple y sin consecuencias de gran impacto ajustar las líneas de código, agregar
una pantalla o un campo a la base de datos. Esto atenta en el tiempo que se aplica al
diseño, dado que a simple vista el impacto de modificar los construido “on line”,
pareciera menor.
Si consideramos que la programación de un software puede tener una variabilidad en la

productividad de un programador de 1 a 10, según la forma en la cual encare el tema, su
experiencia, la aleatoriedad de un error desconocido, etc., es lógico que las estimaciones
tengan grandes desvíos. Por lo tanto, nuestros métodos de estimación y control, deben
considerar estas alternativas y trabajar sobre la base que las mismas existen. Con el
tiempo, la acumulación de experiencias y la estandarización de muchas actividades,
permitirá parecernos un poco más a una ingeniería.
Es natural que estemos en este estado del arte, en una disciplina que tiene unos 50 años
de existencia, en comparación con otras que suman miles.
Como marco para el análisis de esta disciplina es interesante considerar las siguientes
conclusiones de un Foro de especialistas, las cuales presento 20:
“[…] Automatización de la Ingeniería de Software
La sofisticación de herramientas de análisis y transformación de artefactos del proceso

de desarrollo de software está comenzando a tener un impacto, largamente
prometido, en el tipo de herramientas (de software) que soportan las actividades de
verificación, validación y construcción. Combinaciones novedosas de técnicas de
análisis de código, model checking, demostración de teoremas, data mining, y síntesis
están siendo utilizadas cada vez más para potenciar las relativamente simples técnicas
utilizadas actualmente por la industria. El impacto de algunas de estas técnicas ya
puede verse en técnicas de Verificación y Validación como testing, en temas de diseño
y programación como refactorización automática y detección de clones. El potencial
20
Braberman, V., Boria, J., & Yankelevich, D. (2009). Foro en Ingeniería de Software.

que tienen estas técnicas en la automatización de actividades de IS tendrá un fuerte

impacto en lidiar con la creciente complejidad de la disciplina.
Por ejemplo, las problemáticas de líneas de productos y productización ciertamente

ofrecen oportunidades para la aplicación de técnicas automatizadas y semi-
automatizadas para el procesamiento de artefactos del proceso de desarrollo que
permitan extraer, abstraer y refactorizar los artefactos disponibles y ayudar en la
construcción (primero de la visión y después concretamente) de una familia de
productos.
Desarrollo basado en Modelos
Este es un problema clásico de la ingeniería de software: cómo usar modelos de mayor

nivel de abstracción para poder generar de manera automática o semiautomática
distintas aplicaciones, además de lograr un análisis más oportuno sobre propiedades
de lo que se está construyendo y facilitar las tareas de verificación. A lo largo de la
historia de la ingeniería de software se fueron logrando avances en estos puntos, pero
en muchos casos los nuevos paradigmas que fueron apareciendo (de división de un
sistema en módulos, de centralización o descentralización) provocaron retrocesos
importantes que provocaron que los avances en productividad a partir de la
automatización nunca se lograran. Creemos que a medida que se va logrando cierta
madurez en la disciplina y cierta estabilidad en estos paradigmas, esta tendencia
inevitablemente irá ganando lugar y cambiando los procesos de desarrollo. A esta
tendencia se deberá agregar la complejidad de la necesidad de nuevos modelos para
los nuevos desafíos presentados en puntos anteriores, sobre todo los relacionados a
atributos de calidad. Sin más y mejores modelos, esos avances no se podrán lograr.
Desarrollo distribuido y métodos ágiles
Los modelos de desarrollo global seguirán evolucionando e impactando en el proceso

de desarrollo. Por ejemplo, la aparición hace varios años de las llamadas
“metodologías ágiles”, que ponen mucho foco en la interacción entre los integrantes
de un equipo, tienen un impacto sobre la posibilidad de aplicarlas en lugares con poca
compatibilidad horaria. Esto implica una oportunidad para la Argentina, teniendo en
cuenta la zona compatible con Europa y Estados Unidos. Por lo tanto, se deberá invertir
en especializar procesos de desarrollo que exploten estos beneficios que no pueden ser
provistos por zonas más alejadas.[Fin de cita]”

La adquisición de aplicativos, criterios y metodología de selección
Las empresas necesitan estar seguras del éxito de procesos de negocio nuevos y más
eficientes. Hemos asistido muchas veces a malas experiencias sobre la adquisición e
implementación de un software de gestión (ERP, CRM, BI, otros), con el desconcierto de
quien tuvo a cargo todo el proyecto, dado que él mismo no entendía el porqué de tan
mal resultado, puesto que se amparaba en la tranquilidad de “haber elegido un buen
software”.
Este tipo de situaciones se presenta más a menudo en pequeñas y medianas

organizaciones. Incluso, las grandes corporaciones no están libres de esta realidad. El
motivo es simple: se requiere un grado mínimo de madurez organizacional de parte de la
empresa, y un grado mínimo de experiencia y conocimiento sobre lo que implica un
proceso de cambio, de parte de la persona a cargo del proyecto.
Consideraciones para el éxito final de este proyecto
Un proyecto exitoso de cambio y automatización de procesos de gestión, tiene varias

aristas para poder calificarlo de exitoso. Deben darse al menos:
 un nuevo proceso de negocios, donde las actividades a realizar hayan sido

diseñadas en base a los objetivos que fueron definidos en la organización y que
dan origen al proyecto, puesto que se busca una mejora “significativa” en alguna
variable de gestión o en varias a la vez; ejemplo: bajar los días entre la toma de
pedido y la emisión de factura, automatizar el control de créditos, automatizar la
toma de pedidos en forma remota y descentralizada on line, disponer de
información crítica antes inexistente, aumentar la capacidad del departamento
de administración disminuyendo costos, entre otras.
 un producto de software adquirido que cubra ampliamente las funcionalidades

requeridas y sea flexible para parametrizar nuevas necesidades mínimas de
cambios en la gestión cotidiana.
 una plataforma de hardware y comunicaciones / redes adecuadas, segura y con

buenos niveles de performance
 el producto de software adecuadamente instalado y configurado, funcionando

óptimamente, de acuerdo a los niveles de performance con el volumen de datos
acordados por el fabricante.
 personal capacitado en el “nuevo proceso” y en el “uso del software”.
 manuales de procedimientos y manuales de usuarios por funciones.

 un plan de proyecto para realizar “todos” estos cambios con tiempos, esfuerzos y
presupuesto asociado, y gestión de riesgos.
Podríamos mencionar otras variables, pero como ejemplo es suficiente. Entonces, si

todo esto debe darse adecuadamente para que el proyecto sea exitoso, el desafío es
llevarlo a la práctica.
Generalmente, las organizaciones sólo evalúan software para implementar un proyecto

de Sistemas. Disciplinas como gestión de proyectos, gestión del conocimiento para
reutilizar experiencias, gestión de procesos de negocio y gestión de infraestructura
tecnológica están involucradas en esta temática a la hora de elegir. Con lo cual, primero
hay que definir “qué se hace en casa con personal propio y qué se compra a uno o más
proveedores”.
Dado esto, existen metodologías de adquisición de software, proyectos y evaluación de

proveedores que nos podrán acercar más a una óptima elección, para el mejor plan que
se adapte a la organización en cuestión. Según la complejidad e inversión en el proyecto,
estos mecanismos de evaluación ponderados (se usan mucho en evaluación de
licitaciones donde pueden evaluarse más de 100 variables del software y del proveedor),
tienen como núcleo básico algunas variables mínimas a considerar.

Como ejemplo podemos mencionar:
Software
 Cumplimiento de funcionalidades críticas.
 Cumplimiento de funcionalidades opcionales.
 Tecnología de desarrollo / Construcción.
 Facilidad de uso.
 Capacidad de configuración y parametrización.
 Capacidad para desarrollar adaptaciones, sin depender del fabricante.
 Capacidad para explotar la base de datos desde otros aplicativos.
 Requerimientos de hardware.
 Calidad de la documentación técnica y de usuario final.
 Cantidad de instalaciones productivas en el país, verificables.
El proveedor
 Nivel de representatividad y respaldo, si no es el fabricante directo.
 Cantidad de implementaciones verificables, realizadas en el país.
 Cantidad de años y trayectoria como proveedor de esta herramienta.
 Solvencia empresarial, que garantice razonablemente la continuidad.
 Oferta y modalidad del mantenimiento, correctivo y evolutivo.
 Política de lanzamientos, nuevos y versiones.
 SLAs acordados (tiempos de respuestas comprometidos ante incidencias).
 Capacidad en la ejecución de proyectos.
 Conocimiento del negocio y los procesos de la industria específica.
 Capacidad de proveer kits preconfigurados, generados con la experiencia.
 Expertise de los recursos humanos concretos, que se asignarán al proyecto

18 Gestión de Proyectos de TI
Los proyectos de Tecnología de la Información, tienen algunas características

particulares en comparación con otros proyectos de ingeniería.
Son proyectos socio-técnicos, o sea que tienen una gran participación social de las
personas que conforman la organización. Poner en marcha un nuevo sistema de
información implica que mucha gente debe adoptar una nueva forma de trabajar y
comportarse. Esta tarea puede llegar a ser más compleja y ardua que, por ejemplo,
interactuar con maquinarias o manipular materiales en la fabricación o ensamble de un
bien físico.
Dado que en las organizaciones hay personas, además de sus comportamientos

individuales, están los comportamientos grupales o sociales. Estas características están
inmersas en la cultura propia de la organización. Para que un cambio propuesto a la
organización y sus integrantes sea viable, tiene que conseguirse la aceptación y
participación en dicho proceso de cambio, por parte de sus integrantes e incorporar ésos
cambios o mejoras a la cultura organizacional.
Cuando hablamos de proyectos de TI, los mismos intentan modificar procesos de trabajo,
incorporando tecnología (hardware, software, base de datos, redes, etc.). Dichos
procesos son los que las personas ejecutan en su día a día. Por eso, incorporar un sistema
de información que cambie la forma de ejecutar dichos procesos, impacta fuertemente
en la forma de hacer las cosas y lo que la cultura grupal acepta o rechaza en relación a
los valores, costumbres y creencias existentes.
Lograr la aceptación y el cambio para que la incorporación de tecnologías y nuevos

procesos de trabajo sean parte de una nueva cultura de hacer las cosas, es una ardua
tarea que tiene que ver con las personas, los grupos, la organización y las motivaciones,

más allá de los aspectos tecnológicos puros. Por eso, este tipo de proyectos, son
complejos de diseñar y ejecutar.
Un proyecto es un emprendimiento organizado, planificado, con recursos finitos,

con un objetivo final especificado y medible y que se ejecuta por única vez en un
tiempo predeterminado.21
Por lo tanto, el diseño, estimación, ejecución, control y cierre de este tipo de proyectos,
es muy complejo y en algunos casos muy diferente a los tradicionales proyectos de
ingeniería.
Sin embargo, en los últimos años se han aplicado muchos conceptos y herramientas de
PM (Project Management) a este tipo de proyectos, una formalización de las mismas
están reflejadas en el PMBok del PMI22, el cual será analizado en este trabajo
conjuntamente con otros marcos.
Para diseñar y ejecutar proyectos, existen “metodologías” que permiten transitar en

forma previsible el camino. Esta es la visión “dura” de la temática. El segundo eje
fundamental del tema proyectos, es la función del “Líder” de proyectos 23, pues los
mismos se desarrollan en un contexto de organizaciones y personas, con todas las
problemáticas previsibles del comportamiento, conformando así la visión “blanda” del
tema. Los proyectos se identifican y se priorizan en cada organización, como parte de
los logros esperados para sustentar la estrategia organizacional definida.
Estimación de esfuerzos y tiempos para actividades de proyectos
Con el fin de poder realizar una adecuada estimación del proyecto, es necesario armar el
WBS (work break down structure, en español ‘Estructura de Descomposición del
Trabajo’), de manera tal de descomponer el “trabajo” a realizar y llegar a nivel de
actividades. Luego las mismas se deben estimar en esfuerzo y tiempo (desde ahora ‘E y
T’), con el fin de construir la planificación detallada expresada, por ejemplo, en un Gantt.
Es fundamental poder estimar esfuerzos (horas hombre de trabajo necesario para

resolver una actividad) y tiempos (cantidad de días / semanas cronológicas para cumplir
la actividad). Desde ya que existen diversas combinaciones de E y T. Por ejemplo, una
persona puede hacer un trabajo de 40 hs de esfuerzo en 5 días hábiles de 8 hs, o bien 2
21
Piorun, Daniel (2001). Liderando Proyectos. Buenos Aires: Editorial Macchi.
22 Project Management Institute (P.M.I.). Guía de Fundamentos de la Dirección de Proyectos (PMBOK Quinta
Edición) , 2014
23
Piorun, D. (2002). III Congreso Iberoamericano de Gerencia de Proyectos - PMI (Project Management
Institute). Lecture, Caracas, Venezuela.

personas pueden hacer el mismo trabajo en 2 días hábiles de 10 hs cada uno. Ambas
suman 40 horas hombre de esfuerzo. Es obvio que hay muchas combinaciones pero no
son infinitas pues la realidad nos da restricciones de cuales aplican y cuáles no.
De acuerdo a la asignación definida, se puede entonces establecer fechas de cronograma

para su comienzo y fin. Consideremos un proyecto tipo donde puede haber 10
entregables, 70 actividades y 280 tareas, con 5 personas asignadas full time al proyecto
en forma directa, y otras 10 en forma indirecta pero con parte de tareas asignadas.
Gestionar esto en tiempo, forma, calidad, recursos y costos, es el desafío de un gerente
de proyectos. El primer paso para el éxito es el correcto diseño del WBS y la asignación
de tareas.
Esta es una tarea de base técnica, que fundamentalmente se apoya en la experiencia.

Toda nueva actividad, o bien ya fue realizada en el pasado en forma similar, o contiene
distintas partes que en forma individual ya han sido experimentadas.
La base de un método para poder presupuestar esfuerzos con el menor margen de riesgo
posible (evitando la subjetividad total) es tener acumulación de experiencias sobre
‘cómo’ se desarrolló un trabajo similar en el pasado y ‘cuántos’ recursos insumió, en un
contexto definido. Es un tema en donde hay mucho para decir y metodologías de cálculo
específicas, pero lo fundamental a considerar es conocer cuánto E y T me han demandado
actividades de diverso tipo en el pasado, de manera de poder extrapolar cuánto podría
insumir una nueva tarea a realizar en un nuevo contexto.

Indicadores Básicos de Proyecto 24
En resumen, lo que se necesita monitorear como base sería:
Esfuerzo
 Total de esfuerzo recurso planificado.

 Total de esfuerzo real insumido a la fecha, versus el total de esfuerzo planeado
insumir.
 Desvío previsto al final del proyecto (positivo / negativo porcentual).
Tiempos
 Total de Semanas laborales planificadas de duración.

 Total de semanas insumidas a la fecha, versus el total de semanas planeadas a
insumir.
Costos
 Total de costo previsto al planificar el proyecto.

 Total de costo real actual y proyectado, al finalizar el proyecto.
Satisfacción del cliente / Patrocinador del proyecto
 Encuesta periódica de satisfacción del “usuario” sobre el avance del proyecto.

 Evaluación del resultado, versus la expectativa esperada.
 Evaluación del cumplimiento de la CALIDAD de lo producido.
24
Material MBA, UBA, Unidad de Proyectos, por Piorun, D. 2009, Buenos Aires.

19 Gestión de Procesos
Las organizaciones necesitan disponer de procesos eficientes para concretar sus

objetivos de negocio. Dichos procesos son claramente potenciados cuando están
implementados en adecuadas plataformas de tecnología de la información.
Los Sistemas de información, son un conjunto de componentes integrados, que gestionan

datos e información, para que los procesos organizacionales fluyan eficientemente y
cumplan con sus objetivos estipulados.
Se denomina Gestión o administración por procesos de negocio (Business Process

Management o BPM en inglés) a la metodología corporativa cuyo objetivo es mejorar el
desempeño de la Organización a través de la gestión de los procesos de negocio, que se
deben diseñar, modelar, organizar, documentar y optimizar de forma continua.
El Modelo de Administración por Procesos, se refiere al cambio operacional de la

empresa al migrar de una operación funcional a una operación de administrar por
procesos. Las ventajas del modelado BPM son el entendimiento, visibilidad y control de
los procesos de negocio de una organización.25
Un proceso de negocio representa una serie discreta de actividades o pasos de tareas

que pueden incluir, personas, aplicativos, eventos de negocio y organizaciones.
25
Dumas, M. (2013). Fundamentals of BPM. Berlin: Springer-Verlag

Este conjunto de herramientas son llamadas Business Process Management System

(BPMS), y con ellas se construyen aplicaciones BPM. Normalmente siguen una notación
común, denominada BPMN.26
Ilustración 5 - Ciclo de vida BPM
En el modelo coexisten seis fases diferentes, que están unidas en un proceso continuo.
Esto implica que luego de la última fase se vuelve a la primera, para corregir errores o
identificar nuevas necesidades del negocio, e introducir lo aprendido en el ciclo
anterior.
A continuación se presenta una visión conceptual27 PRISM sobre el rol de los procesos,
sus reglas y su medición de desempeño, en el marco de una estructura de la
organización en particular pero siempre apuntalando el modelo de negocios de la
organización como prioridad.
26
Business Process Model and Notation (2011). Object Management Group.
27
‘Mapa conceptual PRISM: Processes, Rules, Indicators, Structure Modeling’, por Ing. L. Stabile (ITBA).Buenos
Aireas. Reg. de Propiedad Intelectual 918285.

Ilustración 6 - Mapa PRISM
Todo esfuerzo en una organización por implementar gestión de procesos y gestión de

la calidad, tiene sentido en la medida que colabore fuertemente con la consecución
de los objetivos estratégicos definidos. La estrategia se despliega en un modelo de
negocio que está sustentado en procesos automatizados que ejecutan reglas y se mide
su desempeño con indicadores. Esto funciona sobre una estructura organizacional
diseñada para hacer “eficientes” a dichos procesos.

20 Infraestructura y Arquitectura Tecnológica
Actualmente las organizaciones son más complejas y necesitan de procesos de negocios

más flexibles y eficientes, que estén alineados e integrados a la consecución de los
objetivos estratégicos de la organización. Ya sea una organización pública o una entidad
sin fines de lucro, en las cuales sus objetivos están orientados a brindar un servicio o
cubrir una necesidad de la sociedad, como así también en las empresas privadas, en las
cuales sus objetivos están orientados al crecimiento y a la renta.
Para ello, las decisiones de inversión y selección de la TI, deben ser acordes a dichos
objetivos, y no funcionar como un compartimiento estanco. A su vez, los cambios
permanentes en las tecnologías disponibles, como así también en su implementación
para soportar los procesos de negocio, hacen muy difícil sostener dicha alineación e
integración.
Para colaborar con dicha problemática, existe una disciplina denominada Arquitectura
Empresarial (AE), que modela la Arquitectura Tecnológica con el fin ya explicitado.
Tal como lo expone Lankhorst, la Arquitectura Empresarial (AE) es un “conjunto

coherente de principios, métodos y modelos que se utilizan en el diseño y la realización
de la estructura de una empresa, organización, procesos de negocio, sistemas de
información e infraestructura.”28
Es este capítulo se realiza una introducción a esta temática y luego en el desarrollo del
trabajo en detalle, se analizan dos frameworks específicos de AE, como lo son TOGAF y
Zachman.
Dado el mapa conceptual definido por COBIT en el capítulo 16 (El Gobierno de la

tecnología de la información), la AE viene a resolver una parte esencial de todas las
temáticas que conforman la gestión integrada de TI.
28
Minoli, Dan (2008). Enterprise Architecture A to Z: Frameworks, Business Process Modeling, SOA, and
Infrastructure Technology. USA: Taylor & Francis Group.

Los Fundamentos por los cuales existe la AE
 Para informar a la dirección de la organización, en un lenguaje accesible, cuál es

la infraestructura actual, y el modelo de infraestructura deseado.
 Para brindar una visión integrada y única para los tomadores de decisiones
 Para disponer de instrumentos metodológicos que unifiquen criterios,

vocabularios y formas de describir una situación presente y/o futura
 Para medir la relación de la inversión en TI con respecto a los resultados

esperados del negocio, impactados por dicha inversión
 Para que la organización pueda realizar un planeamiento a largo plazo y saber que
la infraestructura amparará los futuros lineamientos del negocio
Dimensiones de una Arquitectura Empresarial

Existen cuatro dimensiones 29:
 Arquitectura de Negocios (o de Procesos de Negocio) que define la estrategia de

negocios, la gobernabilidad, la estructura y los procesos clave de la organización.
 Arquitectura de Aplicaciones, que provee un plano (blueprint en inglés) para cada

uno de los sistemas de aplicación que se requieren implementar, las interacciones
entre estos sistemas y sus relaciones con los procesos de negocio centrales de la
organización.
 Arquitectura de Datos, que describe la estructura de los datos físicos y lógicos de

la organización, y los recursos de gestión de estos datos.
 Arquitectura Tecnológica, que describe la estructura de hardware, software y

redes requerida para dar soporte a la implantación de las aplicaciones principales,
de misión crítica, de la organización.
29
Minoli, Dan (2008). Enterprise Architecture A to Z: Frameworks, Business Process Modeling, SOA, and
Infrastructure Technology. USA: Taylor & Francis Group.

A continuación se enumeran los beneficios organizacionales, que se

esperan obtener al implementar Arquitectura Empresarial:
 Asegurar la interoperabilidad entre las plataformas y los sistemas
 Estar mejor preparados para afrontar los cambios
 Poder medir el impacto de los cambios en los diversos componentes
 Poder justificar cada decisión de TI en forma orgánica
 Poder gestionar la configuración de todos los componentes
 Disponer de una visión integrada para el responsable de TI y la Dirección
 Disponer de un repositorio de conocimiento de la infraestructura
 Tener trazabilidad de los estados, desde la línea base en adelante
 Poder medir desempeño con diversos indicadores de gestión
 La necesidad de un marco de referencia para la AE.

21 Integración de los marcos existentes con las normas ISO
Mapa de relación de influencias entre las normas ISO y los marcos de gobierno y gestión de
Tecnologías de la Información.
Luego de analizar todos los marcos y normas que componen este trabajo y en consulta con
diversas organizaciones que las implementan, he podido conceptualizar este mapa que indica,
en términos globales, las relaciones de influencia entre los mismos.
Ilustración 7 - Mapa ISO y Frameworks
Los Normas ISO mencionadas, son agrupaciones conceptuales que representan a las familias
de normas de ésa temática. A su vez, las flechas representan el grado de influencia de dichas
familias de normas en el resto de los marcos de trabajo. A continuación se analizarán
conceptualmente las diversas normas ISO.

22 La norma ISO 38500 – Gobierno de TI
La ISO/IEC 38500:2008 30 es la primer norma internacional que desarrolla la temática de

“Gobierno de TI” para las organizaciones (Corporate governance of information technology),
fija estándares para el gobierno de los procesos y decisiones relativas a las tecnologías de la
información. Fue publicada en junio de 2008 basándose en la norma australiana
AS8015:2005.
ISO/IEC 38500:2008 define seis principios para el gobierno corporativo de TI:
1. Responsabilidad: Todos los integrantes de la organización deben comprender y

aceptar sus responsabilidades relacionadas con los servicios de TI.
2. Estrategia: La estrategia empresarial de organización, considera las capacidades

actuales y futuras de la TI, y los planes estratégicos de TI satisfacen las necesidades
previstas en la estrategia de negocio.
3. Adquisición: Las adquisiciones de TI se realizan analizando el negocio y buscando un

adecuado equilibrio entre beneficios, oportunidades, costos y riesgos tanto a corto
como a largo plazo.
4. Desempeño: La TI estará dimensionada para dar soporte a la organización y debe

proporcionar los servicios con la calidad adecuada, para cumplir con las necesidades
del negocio.
5. Conformidad: La TI debe cumplir las legislaciones y normas vigentes, como así

también las políticas y prácticas establecidas.
6. Comportamiento humano: Las políticas y prácticas de TI demostrarán respeto al

factor humano.
Estos principios deben regir el Gobierno de TI en las organizaciones, la norma ISO 38500
define un modelo global, para que la dirección haga efectivo el gobierno. La norma
propone conseguirlo mediante la ejecución de tres actividades.
30
ISO/IEC 38500:2008 - Corporate governance of information technology. (2008). ISO. Consultado: Noviembre
2015, de http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=51639

ISO/IEC 38500:2008 define tres actividades para el gobierno corporativo de TI:
 Evaluar: Examinar y analizar el uso actual y la previsión de uso futuro de la TI,

incluyendo estrategias, objetivos, planes y adquisiciones.
 Dirigir: Conducir la preparación y ejecución de las políticas y planes de TI, asignando

las responsabilidades que correspondan y asegurar la adecuada implementación de
los proyectos en producción, considerando los impactos en el negocio y la
infraestructura.
 Monitorear: Controlar en forma permanente y con sistemas de medición, que el

rendimiento de la TI coincide con lo planificado, asegurando su aporte de valor.
Esquema de las actividades del Gobierno de TI 31
Ilustración 8 - Mapa ISO 38500
Bajo este marco de principios y actividades, la norma desarrolla un conjunto de lineamientos

para el Gobierno de TI. El marco de trabajo COBIT5, toma estos lineamientos y los desarrolla.
31
JOnline: Gobierno de la TIC ISO/IEC 38500. (2010). Isaca.org. Consultado: Febrero 2016, de
http://www.isaca.org/Journal/archives/2010/Volume-1/Pages/Gobierno-de-las-TIC-ISO-IEC-385001.aspx

23 La norma ISO 20000 – Gestión de Servicios
ISO/IEC 20000 - Service Management: Publicada por ISO (International Organization for
Standardization) e IEC (International Electrotechnical Commission) en 2005 y actualizada en
2011, es el modelo de normalización internacional en gestión de servicios de TI. La serie
20000 proviene de la adopción de la serie BS 15000 desarrollada por la entidad de
normalización británica, la British Standards Institution.
La norma ISO/IEC 20000 32, es el primer modelo de normalización a nivel mundial, para la
gestión de servicios de TI y es totalmente compatible con ITIL, dado que este último en sus
prácticas soporta dicha norma. La misma contiene dos documentos, uno que describe un
modelo de gestión de servicios basado en procesos y otro con una guía para la gestión y
auditoría de servicios de TI.
La ISO/IEC 20000 es un estándar “certificable” de Procesos para gestionar Servicios de IT,

basado en Mejores Prácticas, su objetivo es “entregar” y “soportar” servicios eficientes para
el negocio. Además invita a adoptar un enfoque integrado para la gestión de los procesos
que prestan servicios. En 2011 tuvo la última actualización.
32
ISO/IEC 20000 - Service Management, publicada por ISO (International Organization for Standardization) e
IEC (International Electrotechnical Commission) el 14 de diciembre de 2005, actualizada en 2011.

Estructura de la ISO 20000 33
Esquema de traducción del Autor, del gráfico original
33
ISO/IEC 20000 - Service Management, publicada por ISO (International Organization for Standardization) e
IEC (International Electrotechnical Commission) el 14 de diciembre de 2005, actualizada en 2011.

En su primer documento, la ISO/IEC 20000-1, establece especificaciones a cumplir y dicha

norma es certificable por las organizaciones. En su segundo documento, la ISO/IEC
20000-2, contiene un conjunto de recomendaciones.
Descripción de los componentes de la ISO 20000 34:
Sistema de Gestión del Servicio
Debe facilitar el mecanismo de gestión, que incluye las políticas, las responsabilidades y
los métodos de trabajo, para implementar y gestionar los servicios de IT.
Planificación e Implementación del Servicio
Debe facilitar los instrumentos para planificar y ejecutar la implementación de los

servicios de IT. Establece utilizar el círculo de mejora continua: Planificar, Hacer, Verificar
y Actuar.
Diseño y Transición de Servicios nuevos o modificados
Debe facilitar los métodos para asegurar que los nuevos servicios que se implementen o
sus modificaciones, sean gestionables con la calidad preestablecida.
Proceso de entrega del Servicio
Debe facilitar los métodos para que “el servicio” se brinde en tiempo y forma, de acuerdo
a los niveles de SLA establecidos, presupuestos, capacidad, información de reporte y
disponibilidad de los mismos.
Procesos de relaciones
Debe facilitar y establecer adecuadas relaciones entre proveedores y clientes, del

servicio, basado en las necesidades del negocio del cliente.
Procesos de Resolución
Debe facilitar los métodos para entregar, distribuir y realizar el seguimiento de los
cambios en el entorno de producción del servicio.
Procesos de Control
Debe facilitar los métodos para asegurar que los cambios son evaluados y aprobados,
antes de su implementación, y luego implementados y monitoreados en forma
controlada y sistemática.
34
Search - ISO. ISO. Consultado: Noviembre 2015, de
http://www.iso.org/iso/home/search.htm?qt=20000&sort=rel&type=simple&published=on

Principales novedades de la versión ISO 20000-2011 sobre la 2005
 Se enfoca en forma general a la gestión de servicios, en los cuales incluye los de IT,
pero ya no es específica solo para ellos sino que amplía el panorama de uso.
 Establece que el circulo PDCA (Plan-Do-Check-Act) es un proceso que debe cumplirse

por quien brinda el servicio y hace mucho foco en el gobierno de los servicios, incluso
para terceros.
 Establece más relaciones con otras normas ISO
 Establece revisión por la Dirección y requisitos para llevarlo a cabo.
 Establece nuevos requisitos para operar el proceso de transición.
 Establece nuevos requisitos detallados para cada uno de los procesos componentes
de la norma.

24 La norma ISO 9001- Gestión de la Calidad
Las organizaciones tratan con clientes que aumentan continuamente sus demandas y se
enfrentan a una competencia sin precedentes. Entender y satisfacer a los clientes dejó de ser
una ventaja competitiva, transformándose en una necesidad. La respuesta adecuada a la
situación actual es contar con un Sistema de Gestión de la Calidad actualizado.
La norma ISO 900135 es una herramienta utilizada en todo el mundo y permite diseñar,
implementar y mejorar continuamente un Sistema de Gestión de la Calidad y en
consecuencia, generar una mejora en los resultados que aprecian los clientes de la
organización.
La certificación aumenta la confianza de los clientes, y constituye un instrumento eficaz para

comunicar y demostrar el compromiso de la organización con la calidad y la satisfacción del
cliente.
Los Sistemas de Gestión de la Calidad, la norma ISO 9001 y el proceso de certificación son
aplicables a cualquier tipo de organización: industrias y servicios de cualquier rubro;
empresas, organismos del estado, organizaciones no gubernamentales; independientemente
de su complejidad y tamaño. A continuación, se presenta el gráfico definido por ISO:36
35
ISO 9000 quality management - ISO. ISO. Consultado: Noviembre 2015, de
http://www.iso.org/iso/home/standards/management-standards/iso_9000.htm
36
IRAM Argentina (Instituto Argentino de Normalización y Certificación de Calidad). Mapa ISO 9001. Buenos
Aires: IRAM Argentina.

La norma ISO 9001 corresponde a Sistemas de Calidad, la cual incluye aspectos tales como el
diseño, la fabricación, la instalación y el mantenimiento; con el fin de demostrar la capacidad
de la organización de satisfacer las necesidades de los clientes.
La Norma IRAM-ISO 9001:2008 establece los requisitos mínimos para un Sistema de Gestión
de la Calidad, de manera de asegurar:
 La conformidad de los productos o servicios (según los requisitos del cliente y las
reglamentaciones aplicables)
 La mejora continua de la eficacia.
 El aumento de la satisfacción del cliente.
La versión 2015
A diferencia de sus predecesoras, la nueva Norma ISO 9001:2015, 37 se enfoca más en el
rendimiento que en la gestión, basándose en los riesgos y los procesos, aplicando el circuito
Planificar-Hacer-Verificar-Actuar (PHVA), e integrándose fácilmente a los diferentes sistemas
de gestión. A continuación, se presentará el nuevo esquema de los elementos de un proceso:
37
ISO 9000 quality management - Consultado: Enero 2016, de

Ilustración 11 – Elementos de un proceso (ISO 9001:2015)
Como se puede observar en el esquema anterior, la 9001:2015 contemplan las distintas

instancias intermedias que se realizan para el seguimiento y control del desempeño de los
procesos del Sistema de Gestión de la Calidad (SGC), permitiendo así evitar niveles elevados
de errores y sobre trabajo. De esta forma, el circuito PHVA logra aplicarse e integrarse a cada
proceso y al SGC en su conjunto, asegurando los resultados definidos por la Organización.
Ilustración 12 – Circuito Planificar-Hacer-Verificar-Actuar (ISO 9001:2015)

25 La norma ISO 90003 – Aplicación al Software
Esta norma proporciona las directrices para la aplicación de la ISO 9001 en las
organizaciones, para la compra, abastecimiento, desarrollo, operación y mantenimiento del
software38. Esta norma identifica los puntos que se recomienda considerar y es
independiente de la tecnología, modelos de ciclo de vida, procesos de desarrollo, secuencia
de actividades y estructura utilizados por una organización.
La aplicación de esta norma es apropiada para el software, que puede ser:
 Parte de un contrato comercial con otra organización
 Un producto disponible para un sector del mercado
 Utilizado para apoyar los procesos de una organización
 Un nuevo desarrollo de software
 Incluido en un producto de hardware
 Relacionados con servicios de software
Documentación Obligatoria de la Norma
ISO 9001:2008 con las directrices de la ISO 90003 para software
La Norma ISO39 9001 requiere “un sistema de Gestión de la Calidad Documentado” y “no”
un sistema de documentos.
La documentación del sistema de gestión de Calidad debe incluir:
 Políticas y objetivos de calidad
 Manual de calidad
 Procedimientos documentados, requeridos en esta Norma
 Documentos necesarios para la Organización, para asegurarse de la eficaz

planificación, operación y control de sus procesos.
38
ISO/IEC 90003:2014 - Software engineering -- Guidelines for the application of ISO 9001:2008 to computer
software. (2014). ISO. Consultado: Diciembre 2015, de
http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=66240
39
La Organización Internacional de Estandarización (ISO, según la abreviación aceptada internacionalmente)
tiene su oficina central en Ginebra, Suiza, y está formada por una red de institutos nacionales de
estandarización en 156 países, con un miembro en cada país.

Algunos de estos procedimientos y documentos son:
 Procedimiento de control de los documentos, que define los estándares a

controlar y su grado de control.
 Procedimiento para la realización de auditorías internas.
 Procedimiento para control de los productos no conformes.
 Procedimiento para la realización de acciones correctivas.
 Procedimiento para la realización de acciones preventivas.
 Procedimiento de control de los registros, el que define los registros a

controlar y su grado de control.
Algunos registros posibles, requeridos por esta Norma son:
 Actas de revisiones de la Dirección.
 Elementos de entrada para el diseño y desarrollo.
 Resultados de auditorías internas.
 Planes de formación.
 Planes de mejora.
El alcance, nivel y detalle de la documentación lo define la Organización. De la

conceptualización de la Norma, se realiza el siguiente esquema, que representa la
granularidad de la documentación del Sistema de Gestión de la Calidad

Ilustración 13 - Documentación Sistema Gestión Calidad
Mejora Continua
El esfuerzo de mejora es conducido por la "Política de Calidad" y los "Objetivos de

Calidad". Las oportunidades de mejora son identificadas a partir del análisis de la
información, proveniente de los indicadores de gestión establecidos.
El desempeño de la calidad es evaluado en las reuniones de Dirección. Las decisiones

de realización de mejoras son tomadas por la Dirección.
El Sistema de Gestión de la Calidad (SGC), explica los requisitos generales del sistema
de Calidad, ya que cada organización construye su propio sistema. Esto contempla
definir los requerimientos para el control de la documentación y el control de los
registros, los cuales serán más o menos complejos, en función del tipo de Negocio y
tamaño de la Organización. Del análisis que se ha realizado, se genera el siguiente
esquema:

Ilustración 14 - Brecha del SGC
La brecha mide la falta de eficiencia del SGC. Entre más estrecha sea la brecha, más
eficaz es dicho Sistema.
Por lo tanto, se espera que el SGC sea un instrumento que la Dirección utiliza, para
asegurarse que los procesos de producción y soporte que realiza la organización estén
alineados con los objetivos organizacionales y funcionen bajo un esquema medible de
mejora continua.
El esquema que se presenta a continuación, surge del análisis que se realizó en

paralelo de la Norma ISO 9001 y la aplicación de las directrices de la ISO/IEC 90003,
respecto al software.

Ilustración 15 - Directrices ISO 90003
Las ideas principales que propone el estándar ISO 90003 son las siguientes:
 La gestión de calidad debe ser aplicada a todas las fases de la producción de

software, incluido el mantenimiento.
 Debe existir colaboración entre la organización que adquiere el software y el

proveedor del mismo.
 El productor del software debe establecer su sistema de calidad y asegurarse

que toda la organización utilice el mismo.
La aplicación de la norma ISO 9001, en combinación con las directrices propias para
software de la norma ISO 90003, está siendo una opción muy difundida pues permite
mayor flexibilidad en su implementación que el modelo CMMI, y al ser “Certificable”
internacionalmente le brinda a las organizaciones un sello de calidad reconocido.

26 La norma ISO 27001- Gestión de Seguridad de la

Información
La familia de normas ISO 2700040, son un estándar que colabora con las organizaciones
en gestionar la seguridad de la información.
La norma ISO/IEC 27001 es la más conocida y provee un sistema de gestión de seguridad

de la información denominado “Sistemas de Gestión de la Seguridad de la Información”
(SGSI) (ISMS, por sus siglas en inglés).
La revisión más reciente de esta norma fue publicada en 2013. La primera versión se
publicó en 2005 y fue desarrollada en base a la norma británica BS 7799-2.
La ISO 27001 puede ser implementada en cualquier tipo de organización. Recopila las
mejores prácticas internacionales sobre la temática. Esta norma es posible de ser
certificada por la organización.
La ISO 27001 se ha convertido en la principal norma a nivel mundial para la seguridad de

la información y muchas empresas han certificado su cumplimiento.
Forman parte de esta familia de normativas la 27002 (Código de prácticas para los
controles de seguridad de la información), la 27003 (Guía para la implementación de un
Sistema de Gestión de Seguridad de la Información), la 27004 (gestión de la seguridad de
la información - Métricas), la 27005 (Gestión de riesgos de la Seguridad la Información),
27006 (Técnicas de seguridad Requisitos para los organismos que realizan la auditoría y
certificación de sistemas de información de gestión de la seguridad), y la 27007 (Guía
para Auditar el Sistema de Gestión de Seguridad de la Información)
40
ISO/IEC 27001 - Information security management. (2013). ISO. Consultado: Enero 2016, de
http://www.iso.org/iso/home/standards/management-standards/iso27001.htm

La Seguridad de la Información consiste en garantizar:
 Confidencialidad: Información disponible exclusivamente a las personas autorizadas.
 Integridad: Mantenimiento de la validez y exactitud de la información, protegiéndola

de las modificaciones o alteraciones no autorizadas.
 Disponibilidad: Acceso y utilización de los servicios, única y exclusivamente en el

momento de ser solicitado por una persona autorizada.

La ISO 27001 en su versión 2013 establece 14 dominios y 114 controles
A continuación se describen los dominios, de acuerdo a lo establecido por ISACA: 41
En su Anexo A la norma enumera los objetivos de control y los controles que desarrolla
en detalle la norma ISO 27002, para que sean seleccionados y utilizados por las
organizaciones en su SGSI. A pesar de no ser obligatoria la implementación de todos los
controles que define, cada organización deberá argumentar los motivos de la “no
aplicabilidad” de los controles que decide no implementar.
41
Principales Novedades de la ISO 27001/ISO 27002. (2013). isaca.org. Consultado: Diciembre 2015, de
http://www.isaca.org/chapters7/Madrid/Events/Documents/Principales%20Novedades%20de%20la%20ISO27
001ISO%2027002%20-%20Paloma%20Garcia.pdf

27 La norma ISO 31000 - Gestión del Riesgo
La norma ISO 31000 42 es un conjunto de normas sobre Gestión del riesgo, publicadas por
la Organización Internacional de Normalización (ISO, por sus siglas en inglés). El propósito
de la norma ISO 31000:2009 es proporcionar principios y directrices para la gestión de
riesgos y el proceso implementado en el nivel estratégico y operativo.
Esta norma proporciona lineamientos y 11 principios a aplicar para gestionar los riesgos
organizacionales. Esta norma no es certificable, sino que se integra para mejorar esta
temática, en otras normas certificables como ser la ISO 9001 de sistemas de gestión de la
calidad.
Los principios para la gestión del Riesgo son:
1. Crear valor a la organización
2. Integrarse en los procesos organizacionales existentes
3. Integrarse en las decisiones
4. Abordar explícitamente la incertidumbre
5. Ser sistemática, estructurada, oportuna y eficaz
6. Disponer de la mejor información posible
7. Ser conveniente y adaptarse a los recursos disponibles
8. Integrar factores humanos, culturales y organizacionales
9. Ser transparente y participativa
10. Ser dinámica, iterativa, flexible y sensible al cambio
11. Facilitar la mejora continua de la organización
Esta norma, inserta en los marcos de gobierno de TI descriptos, permite disponer de

procesos de gobierno y gestión mucho más efectivos y predictivos en sus acciones.
42
ISO 31000 - Risk management - ISO. (2009). ISO. Consultado: Enero 2016, de
http://www.iso.org/iso/home/standards/iso31000.htm

28 La Norma ISO 21500 – Guidance on Project Management
La Norma ISO 21500 43 publicada en su última revisión en 2013, define las “Directrices
para la Dirección y Gestión de Proyectos”. Puede ser utilizada por cualquier tipo de
organización y para cualquier tipo de proyecto, independientemente del tamaño o
complejidad.
La misma nace como una recopilación de mejores prácticas en gestión de proyectos,

reutilizando los marcos más difundidos a nivel internacional y está altamente alineada al
PMBOK del PMI. En este caso el PMI certifica “personas” como especialistas en gestión de
proyectos.
La ISO 21500 va camino a ser una norma “certificable por las organizaciones”, con lo cual
cubrirá una necesidad diferente al PMI. En relación al contenido, tiene alta correlación
con los principios y estructura del PMBOK. Algunas diferencias genéricas son:
 La ISO 21500 se focaliza en la Organización y el PMBOK se focaliza en el Project

Manager
 La ISO 21500 no incluye Técnicas y Herramientas
 La ISO 21500 sólo hace mención del ciclo de vida del proyecto, el PMBOK hace
mención del ciclo de vida del proyecto y del producto
El mismo PMI impulsa la adopción de la ISO 21500 por parte de las organizaciones al
considerarla un aporte para el negocio, con definiciones como esta: “Esto facilita la
expansión de los negocios por proyectos al ámbito internacional. Luego, la Gestión de
Proyectos con la ISO 21500 PM es una competencia estratégica para las empresas”.44
Por lo tanto, es una norma que complementa los otros marcos descriptos para la gestión
de proyectos, en miras de sumar un mejor Gobierno de TI a nivel organizacional.
43
ISO 21500:2012 - Guidance on project management. (2012). ISO. Consultado: Octubre 2015, de
44
Núñez Araque, José María (PMP®) - Vocal Junta Directiva PMI Madrid - Spain Chapter

29 La norma ISO 15504 - Madurez del Proceso de Software
El ISO/IEC 15504,45 también conocida como Software Process Improvement Capability

Determination, abreviado SPICE, en español, “Determinación de la Capacidad de Mejora
del Proceso de Software”, es un modelo para la mejora, evaluación de los procesos de
desarrollo, mantenimiento de sistemas de información y productos de software.
Esta norma es utilizada por la última versión de COBIT5,46 como marco de referencia para
la evaluación de sus procesos. Tiene definido niveles de madurez del 0 al 5 para los
procesos y se la utiliza como modelo para los procesos de software.
Con la norma ISO 15504 se pueden evaluar diferentes modelos de procesos. Proporciona
los principios para realizar una evaluación de la implementación del modelo de procesos
en una organización. Dado que establece 5 niveles de madurez para el modelo de
procesos, tiene alta relación con el enfoque de CMMI 47 para desarrollo.
La ISO 15504 tiene la última revisión en 2011. Es un marco de trabajo para evaluar de
manera general cualquier modelo de procesos (aunque se lo utiliza fundamentalmente
en la industria del software).
Con relación a la madurez de las implementaciones de los procesos, ambos modelos,

CMMI e ISO 15504, son de la década del 90. En el caso de CMMI hay un mayor número
de certificaciones. La ISO 15504, no tiene la popularidad de otros marcos de trabajo, pero
aplicándola en conjunto con la ISO 12207 48 “Ciclo de vida del proceso de desarrollo del
software”, tiene un fuerte grado de solidez, motivo por el cual COBIT5 la incorpora a su
marco de trabajo. Una ventaja organizacional para la ISO 15504, es que es una norma
“Certificable”. En Europa tiene mayor vigencia que en EEUU, donde predomina el CMMI.
45
ISO/IEC TS 15504-10:2011 - Information technology -- Process assessment -- Part 10: Safety extension.
(2011). ISO. Consultado: Octubre 2015, de
46
COBIT5: A Business Framework for the Governance and Management of Enterprise IT (2012). Isaca.org.
Consultado: Noviembre 2015, de http://www.isaca.org/cobit/pages/default.aspx
47
CMMI Institute. Cmmiinstitute.com. Consultado: Diciembre 2015, de http://cmmiinstitute.com/#home
48
ISO/IEC 12207:2008 - Systems and software engineering -- Software life cycle processes. (2008). ISO.
Consultado: Octubre 2015, de

29.1 El Modelo de Capacidad de los Procesos de COBIT5
COBIT5 explicita un modelo de capacidad y madurez de los procesos de una

organización, en particular para el Gobierno y Gestión de TI 49
Este modelo se utiliza para evaluar la “madurez actual” de los procesos relacionados con
la TI de una empresa y para definir un estado de madurez requerido a obtener, con la
consiguiente definición de la brecha existente.
COBIT5 incluye este modelo de capacidad de los procesos, basado en la norma ya

mencionada ISO/IEC 15504 de Procesos para software. Los detalles del enfoque de
evaluación de la capacidad de procesos en COBIT5 están incluidos en la publicación de
ISACA, pero explicitaremos los pilares conceptuales del modelo.
La evaluación distingue entre evaluar el nivel inicial de madurez y los niveles superiores.
El nivel 1 de capacidad de procesos describe si un proceso “alcanza su objetivo
establecido” y es por tanto un nivel muy importante (así como la base para hacer
alcanzables los niveles de capacidad superiores).
La evaluación de madurez puede hacerse por:
1. Revisión de los resultados del proceso tal y como se describen para cada proceso en
sus definiciones detalladas, y usando las escalas y ratios de la ISO/IEC 15504 para asignar
un ratio para el grado en el que cada objetivo es alcanzado.
Esta escala consiste en los siguientes ratios:
No alcanzado: Hay muy poca o ninguna evidencia de que se alcanza el atributo

definido en el proceso de evaluación (0 al 15 por ciento de logro).
Parcialmente alcanzado: Hay alguna evidencia de aproximación y algún logro del

atributo definido en el proceso evaluado (16 a 50 por ciento de logro).
49
COBIT5: A Business Framework for the Governance and Management of Enterprise IT (2012). Isaca.org.
Consultado: Noviembre 2015, de http://www.isaca.org/cobit/pages/default.aspx

Ampliamente alcanzado: Hay evidencias de un enfoque sistemático y de un logro

significativo del atributo definido en el proceso. Pueden encontrarse algunas
debilidades relacionadas con el atributo en el proceso evaluado (51 a 85 por ciento de
logro).
Completamente alcanzado: Existe evidencia de un completo y sistemático enfoque y

un logro completo del atributo definido en el proceso evaluado. No existen
debilidades significativas relacionadas con el atributo en el proceso evaluado. (86 a
100 por ciento de logro).
2. Revisión de las prácticas del proceso (de gobierno o de gestión) pueden ser evaluadas
usando la misma escala de puntuación, expresando el grado de la “aplicación real” de las
prácticas de base.
Para niveles de capacidad de los procesos superiores se utilizan las prácticas genéricas
tomadas del estándar ISO/IEC 15504:2. Estas proporcionan descripciones genéricas para
cada uno de los niveles de capacidad.
Existen seis niveles de capacidad que se pueden alcanzar por un proceso, incluida la
designación de “proceso incompleto”.

Proceso
0 El proceso no está implementado o no alcanza su propósito
incompleto
Proceso
1 El proceso implementado alcanza su propósito
ejecutado
Proceso El proceso ejecutado descripto anteriormente está implementado de
2
gestionado forma gestionada (planificado, supervisado y ajustado)
El proceso gestionado descripto anteriormente está ahora
Proceso
3 implementado usando un proceso definido que es capaz de alcanzar
establecido
sus resultados de proceso
Proceso El proceso establecido descripto anteriormente ahora se ejecuta

4
predecible dentro de límites definidos para alcanzar sus resultados de proceso
Proceso El proceso predecible descripto anteriormente es mejorado de forma

5
optimizado continua para cumplir con las metas empresariales actuales y futuras
Tal como se muestra en el siguiente gráfico, existen 5 niveles de madurez de los procesos,
los cuales están alineados con la Norma ISO/IEC 15504 respecto a la madurez del proceso
de Software.
Ilustración 17 - Modelo de capacidad de procesos

Cada nivel de capacidad puede ser alcanzado sólo cuando el nivel inmediato anterior se
ha alcanzado por completo. Existe una diferencia significativa entre el nivel inicial de
capacidad de procesos y los niveles superiores. Cada organización de forma individual
deberá elegir su objetivo o nivel deseado.
29.2 Conclusión de aplicabilidad del modelo:
Este modelo de madurez de procesos explicitado, es una herramienta muy útil para
toda organización, para llevar a la práctica con mayor éxito un buen Gobierno y Gestión
de TI. Puede usarse para cualquier tipo de proceso y cualquier marco de trabajo, más
allá de COBIT propiamente dicho.

30 Marcos existentes para el gobierno y gestión de TI
Como puede apreciarse, la ISO ha generado un amplio conjunto de normativas

relacionadas a la temática que recorre este trabajo. En las últimas décadas, en
simultáneo, se han generado diversos estándares de marcos específicos de trabajo, que
tal como se ha graficado al comienzo del capítulo de normas ISO, tienen relaciones de
influencia en las normas propiamente dichas.
Dado que se ha finalizado con el marco teórico del presente trabajo, en los capítulos
siguientes se analizarán diversos marcos para el gobierno y la gestión de TI, y algunas
leyes o acuerdos internacionales aceptados por los países, cuyo cumplimiento tiene
influencia en el entorno de TI.
El objetivo de los siguientes capítulos no es reproducir todo el material específico de cada

marco o framework, sino transmitir el espíritu central y su lógica de comportamiento
conjuntamente con los objetivos que persigue.
Muchos conceptos y prácticas son comunes en los diferentes marcos. Lo realmente

importante, es que cada organización pueda formar un “mapa de herramientas para la
gestión y el gobierno de TI”, con el fin de tomar aquellas prácticas que permitan
gestionar, medir, evaluar y mejorar, aquellos procesos que son críticos para la
organización y el negocio.

31 COBIT
En este capítulo, describiremos las principales características de este marco de trabajo

empresarial. Es importante destacar que “no es el objetivo presentar en detalle todo el
material existente” para COBIT que está disponible en el mercado y en su propia
documentación pública generada por ISACA50, dado que es un framework muy difundido,
sino el objetivo es hacer un compendio de lo importante y hacer foco en la usabilidad de
dichas herramientas para aplicar a cualquier tipo de organización, con el fin de colaborar
en los procesos de Gobernabilidad.
COBIT (Control Objectives for Information and related Technology), es un modelo de

referencia que describe 37 procesos relacionados con TI y que pueden ser comunes a
todas las organizaciones. Cada proceso está descripto en detalle, incluyendo entradas y
salidas, actividades, objetivos, indicadores de desempeño y un modelo básico de
madurez. Fue creado por la organización ISACA pero en la actualidad es mantenido por
ITGI (Instituto de Gobernanza de TI). Está alineado con la norma ISO 38500.
COBIT, brinda un conjunto de buenas prácticas a través de un marco de trabajo basado

en procesos y presenta las actividades en forma estructurada. Dichas prácticas están
enfocadas especialmente al control y mucho menos a la ejecución, es decir, indican más
“qué se debe obtener” sin focalizarse en el cómo.
La principal característica de COBIT es que está orientado al negocio, vinculando los

objetivos del negocio con las metas de TI, proporcionando métricas y modelos de
madurez para medir resultados, e identificando las responsabilidades asociadas de los
dueños de los procesos de negocio y de TI.
50
http://www.isaca.org - Information Systems Audit and Control Association [NO tengo la suficiente
información para generar esta cita]

Sus 37 procesos están distribuidos en 1 área global de procesos de gobierno corporativo

de TI y 4 áreas de responsabilidad de gestión:
Gobierno corporativo: 5 procesos
Áreas de responsabilidad:
1. Planear: 13 procesos
2. Construir: 10 procesos
3. Ejecutar: 6 procesos
4. Monitorear: 3 procesos
Dichas áreas coinciden con el ciclo de calidad de Deming51 (Plan-Do-Check-Act).
En el siguiente cuadro se observa dicha distribución, la cual se explicitará, cada proceso,

más adelante detalladamente, este cuadro de acuerdo a lo establecido con ISACA:52
Ilustración 18 - Procesos COBIT5

Como puede observarse, existen 32 procesos pertenecientes a la categoría de la

“Administración de TI corporativa”; a su vez, existen 5 procesos, autónomos y superiores
que representan al “Gobierno corporativo de TI”. Esto obedece a un lineamiento de
COBIT5 (la última versión53), en la cual se separa claramente la “Gestión de IT” del
“Gobierno de TI”.
A continuación se explicita dicha separación conceptual.
Gobierno de IT
Busca asegurar que los objetivos de la empresa, a nivel corporativo, se logren mediante
la evaluación de las necesidades de las partes interesadas, las condiciones y alternativas
existentes, estableciendo la dirección a través de la priorización y decisión, las líneas de
acción, monitoreando el desempeño, el cumplimiento y los resultados obtenidos por la
gestión.
Administración o Gestión de IT
Tiene a cargo el planeamiento para construir, implementar y ejecutar los planes de IT

definidos y alineados al negocio. Monitorea los proyectos y actividades, asegurando que
permanezcan alineadas con la dirección establecida por el órgano de gobierno, para
alcanzar los objetivos de la empresa.
En este sentido, COBIT, mediante la división y la asignación de responsabilidades a

diferentes actores de la organización, según los procesos mencionados en el mapa,
asegura que “ambos” intereses (gobierno y gestión), se lleven adelante
satisfactoriamente y que realmente el área de IT contribuya al negocio.
51
Deming, W. Edwards (1989). Calidad, Productividad y Competitividad. Madrid: Ediciones Díaz de Santos.
52
COBIT5© (2012). ISACA®
53

Evolución temporal y alcances de COBIT: 54
En el siguiente esquema se observa cómo COBIT ha evolucionado de marco teórico para

realizar auditorías, para transformarse en un marco de Gobierno de TI, tal como se
analizará más adelante la versión COBIT5.
Ilustración 19 - Evolución hacia COBIT5
Los 5 principios de COBIT5:
Los 37 procesos mencionados, divididos en el área de Gobierno corporativo y las 4 áreas

de responsabilidad, COBIT establece que dichos procesos deben permitir el logro de los
siguientes “cinco principios”, para beneficio de la organización:
54

La aplicación de COBIT debe:
Ilustración 20 - Principios COBIT5
Principio 1: poder satisfacer a los intereses de las distintas partes, ya sean accionistas,
directores, CEO, CIO y el equipo gerencial de ejecución.
Principio 2: poder cubrir mediante sus procesos todas las áreas que componen la
organización para brindar el resultado esperado.
Principio 3: poder brindar una única herramienta metodológica e integradora, que

permita mediciones homogéneas.
Principio 4: poder generar un enfoque holístico (o sea integrado), con el fin de que todos
los esfuerzos se generen en pos de una única visión.
Principio 5: permitir, separar los procesos y controles que se necesitan para el Gobierno
de IT y para la Gestión de IT.

Los 7 habilitadores (o catalizadores) de COBIT5:
Tal lo mencionado, COBIT dispone de 37 procesos, divididos en las 4 áreas de

responsabilidad, más la quinta que es el Gobierno corporativo, buscando que se cumplan
los cinco principios ya establecidos. Para lograr esto, define que se deben utilizar lo que
denomina, los “7 Habilitadores”55, que permiten su implementación:
Ilustración 21 - Habilitadores de COBIT5
COBIT establece que existen factores que pueden influir en forma individual o colectiva,
sobre si algo realmente se concretará exitosamente. En nuestro caso, el Gobierno y la
Gestión de TI.
Estos factores los denomina CATALIZADORES, pero en diversos materiales traducidos,

también se encontrará este término como HABILITADORES o FACILITADORES. Más allá
del nombre, como puede apreciarse en el gráfico, son elementos, esquemas, principios y
recursos que conforman a la “organización” y que COBIT los considera indispensables en
cuanto a su alineación a este framework, para que el “modelo de gobernabilidad” se
implemente y funcione adecuadamente.
55

A partir de los 7 catalizadores (que su propio nombre representan su contenido, sin

necesidad de explicitarlos más), COBIT establece que los mismos actúan en forma
“interconectada” permitiendo así que unos sean entradas/proveedores de otros para
que la gestión sea efectiva.
De todas las interconexiones posibles que la propia realidad de una organización puede
establecer para estos siete catalizadores, COBIT representa la principal de ellas, que son
las flechas que delinean que los “principios, las políticas y los marcos de trabajo” que
adopta la organización, deben ser quienes influyan en el desarrollo de los otros
catalizadores restantes.

Las “Dimensiones” de los Habilitadores o Catalizadores de COBIT5:
Todos los habilitadores tienen una serie de dimensiones56 comunes. Dichas dimensiones
permiten:
 tener una forma común, sencilla y estructurada para tratar los habilitadores
 manejar sus interacciones complejas
 facilitar resultados exitosos de los habilitadores
Ilustración 22 - Dimensiones de los Habilitadores COBIT5
Si tomamos cada uno de los 7 habilitadores y realizamos un análisis con las 4 dimensiones
establecidas para cada uno (partes interesadas, metas, ciclo de vida, buenas prácticas) e
intentamos pensar cómo serían las respuestas a las preguntas sobre el desempeño de los
habilitadores, podemos concluir que COBIT no nos presenta conceptos desconocidos
sobre lo que significa gobernar y gestionar una organización (en este caso focalizada en
la TI), sino que lo que presenta es un marco integrador y lógico para diseñar un esquema
de gobierno efectivo, a partir de que la máxima dirección pueda integrar e interrelacionar
todos los componentes definidos y establecer un “cómo” deben ejecutarse en la Gestión.
56

Interacciones entre gobierno y gestión de TI
Retomando la lógica de este capítulo y volviendo al comienzo, en el cual describimos qué

es COBIT, sus áreas de responsabilidad, sus procesos, los principios, los habilitadores y
sus dimensiones, destacaremos con mayor profundidad ahora, la clara división que la
versión 5 de COBIT, incorpora sobre gobierno y gestión.
Ilustración 23 - Interacción gobierno y gestión TI
En la ilustración precedente, puede observarse la visión global sobre esta separación, la

cual presentamos al principio de este capítulo, desde la perspectiva de los procesos que
la componen. Para el área de responsabilidad de Gobierno, vemos que las funciones de
dirigir, evaluar y monitorear, se ejecutan en 5 procesos de gobierno, estas funciones
están alineadas con la norma ISO 38500 de gobierno.
En el gráfico precedente, también puede observarse que en forma separada están las
otras 4 áreas, que componen la Administración o gestión de TI, que como ya se mencionó
en este capítulo, suman los 32 procesos restantes que las componen.

Descripción de los Procesos de COBIT5 por área de responsabilidad:
Habiendo descripto en forma general y conceptual los principales componentes de este

marco de trabajo, describiremos con mayor detalle los 37 procesos.
Gobierno corporativo para TI
Esta área la componen 5 procesos, que se espera sean llevados a cabo y monitoreados
por los responsables de la dirección de la organización, para que permitan cumplir con la
función de gobierno y tomar las decisiones correspondientes en base a información
objetiva que brindan los indicadores de desempeño de estos procesos. Los mismos son:
1. Asegurar el establecimiento y mantenimiento del marco de gobierno
2. Asegurar la entrega de beneficios
3. Asegurar la optimización del riesgo
4. Asegurar la optimización de los recursos
5. Asegurar la transparencia hacia las partes interesadas
El concepto de “asegurar” debe ser trasladado a cada organización, en metas concretas

e indicadores de cumplimiento, para que el órgano de gobierno pueda controlar y ajustar
lineamientos, con el fin de cumplir las metas corporativas.
Gestión: Alinear, planificar y organizar
Esta área la componen 13 procesos, que se espera sean ejecutados y monitoreados por
los responsables “ejecutivos” de la organización (CEO, CIO y gerentes, en el caso de una
empresa privada), para que permitan cumplir con la función ejecutiva y “disponer de
planes” de acción en cada una de las temáticas que estos procesos representan, para que
luego pueda disponerse de información objetiva que brindan los indicadores de
desempeño de procesos. Los mismos son:

1. Gestionar el marco de gestión de TI
2. Gestionar la estrategia
3. Gestionar la arquitectura empresarial
4. Gestionar la innovación
5. Gestionar el portafolio
6. Gestionar el presupuesto y los costos
7. Gestionar los recursos humanos
8. Gestionar las relaciones
9. Gestionar los acuerdos de servicio
10. Gestionar los proveedores
11. Gestionar la calidad
12. Gestionar el riesgo
13. Gestionar la seguridad
El concepto de “gestionar” en particular en esta área de planificación, debe ser

trasladado a cada organización, en metas concretas e indicadores de cumplimiento por
proceso, para que el responsable ejecutivo, pueda controlar su ejecución y ajustar
acciones, con el fin de cumplir las metas organizacionales definidas.
Gestión: Construir, adquirir e implementar
los responsables “ejecutivos” (CEO, CIO y gerentes) de la organización, en el caso de una
empresa privada, para que permitan cumplir con la función ejecutiva de “poner en
marcha” los planes de cada una de las temáticas que estos procesos representan, para
que luego, pueda disponerse de información objetiva que brindan los indicadores de
desempeño de procesos. Los mismos son:

1. Gestionar los programas y proyectos
2. Gestionar la definición de requisitos
3. Gestionar la identificación y la construcción de soluciones
4. Gestionar la disponibilidad y la capacidad
5. Gestionar la introducción de cambios organizativos
6. Gestionar los cambios
7. Gestionar la aceptación del cambio y de la transición
8. Gestionar el conocimiento
9. Gestionar los activos
10. Gestionar la configuración
El concepto de “gestionar” en particular en esta área de implementación, debe ser

trasladado a cada organización, en metas concretas e indicadores de cumplimiento por
proceso, para que el responsable ejecutivo, pueda concretar su ejecución y ajustar
acciones, con el fin de cumplir las metas organizacionales definidas.
Gestión: Entregar, dar servicio y soporte
los responsables “ejecutivos” para que permitan cumplir con la función ejecutiva de
“brindar el servicio” de lo implementado, para lo cual debe gestionarse cada una de las
temáticas que estos procesos representan, para que luego, pueda disponerse de
información objetiva que brindan los indicadores de desempeño de procesos. Los mismos
son:

1. Gestionar las operaciones
2. Gestionar las peticiones y los incidentes del servicio
3. Gestionar los problemas
4. Gestionar la continuidad
5. Gestionar los servicios de seguridad
6. Gestionar los controles de los procesos de negocio
El concepto de “gestionar” en particular en esta área de soporte, debe ser trasladado a

cada organización, en metas concretas e indicadores de cumplimiento por proceso, para
que el responsable ejecutivo, pueda concretar su ejecución y ajustar acciones, con el fin
de cumplir las metas organizacionales definidas.
Área de Gestión: Supervisar, evaluar y verificar
los responsables “ejecutivos” (CEO, CIO y gerentes) de la organización, en el caso de una
empresa privada, para que permitan cumplir con la función ejecutiva de “supervisar” la
operación, para lo cual debe gestionarse cada una de las temáticas que estos procesos
representan, para que luego, pueda disponerse de información objetiva que brindan los
indicadores de desempeño de procesos. Los mismos son:
1. Supervisar, evaluar y valorar el rendimiento y conformidad
2. Supervisar, evaluar y valorar el sistema de control interno
3. Supervisar, evaluar y valorar la conformidad con los requerimientos externos
El concepto de “supervisar” en particular en esta área de monitoreo, debe ser trasladado

a cada organización, en metas concretas e indicadores de cumplimiento por proceso,
para que el responsable ejecutivo, pueda valorar su ejecución y ajustar acciones, con el
fin de cumplir las metas organizacionales definidas.

Modelo de capacidad de los procesos de COBIT557:
COBIT5 dispone de un “modelo de madurez” de procesos. Dicho modelo está basado en

la norma ISO / IEC 15504 (mencionada en el marco conceptual de este trabajo y en las
normas ISO), referida a ingeniería de software y evaluación de procesos.
Este modelo se utiliza para medir y calificar el estado actual de los procesos de la
organización relacionados con TI y establecer el nivel de madurez que deberían tener
para cumplir con las metas organizacionales, o sea establecer el “deber ser”. Conocida
entonces esta brecha, se genera un plan de mejora de los procesos el cual incluye un
monitoreo permanente de su evolución. Establece grados de madurez de al 0 al 5.
COBIT5 pone mucha atención a la gestión por procesos y con el basamento de la ISO
15504, propone llevar a la práctica lo que actualmente en el mercado se conoce como
“Gestión por procesos de negocio” (Business Process Management o BPM en inglés), a
la metodología corporativa cuyo objetivo es mejorar el desempeño (Eficiencia y Eficacia)
de la Organización a través de la gestión de los procesos de negocio, que se deben
diseñar, modelar, organizar, documentar y optimizar de forma continua.
El Modelo de Gestión por Procesos, se refiere al cambio operacional de la empresa al

migrar de una operación funcional a una operación administrada por procesos. Un
proceso de negocio representa una serie discreta de actividades o pasos de tareas que
pueden incluir, personas, aplicativos, eventos de negocio y organizaciones.
Hemos descripto en particular el mapa de procesos de COBIT5, lo cual es el componente

realmente “visible” de este marco de trabajo, o sea los 37 procesos operando en la
realidad de la organización.
En las conclusiones de este trabajo, abordaremos un análisis sobre la factibilidad y

enfoques posibles para llevar a la práctica de este marco, sin que ello se convierta en una
mera formalidad ni burocracia. En relación a la temática de madurez de los procesos
mencionada anteriormente, es de mucha importancia para cualquier tipo de
organización. En los cuerpos de documentación formal de COBIT5 y la ISO 15504, se
encontrará mayor información al respecto.
57

Metas en cascada de COBIT5:
El objetivo del Gobierno de IT es “crear valor”58. Con esta premisa, es que la dirección a
cargo del Gobierno de toda la organización, genera un plan estratégico de mediano y
largo plazo, que focaliza la visión y la traduce en planes y actividades para alcanzarla.
En el capítulo 15 de este documento, se presentó la temática de Planeamiento

Estratégico, tanto los conceptos como una macro metodología para desagregar el mismo
hasta los niveles de ejecución. Este es un abordaje actual de un plan estratégico, en el
cual, en forma de “cascada”, cada objetivo se va desagregando en metas, proyectos,
actividades, recursos asociados, tiempos y resultados esperados.
COBIT5 toma este mismo concepto y genera lo que denomina “Metas en Cascada”. Las
partes interesadas (accionistas, directores, gerentes, influentes externos, otros), son los
que participan en distinto grado, en el diseño del planeamiento estratégico, en el cual
están incluidos los análisis de beneficios esperados, riesgos asumidos y recursos
necesarios.
La cascada de metas de COBIT5, es el mecanismo por el cual se traducen las necesidades

de las partes interesadas en “metas corporativas”. De estas metas se desprenden las
“metas relacionadas con TI” y desde allí se desprenden las “metas de los catalizadores”
específicos.
Este método permite establecer en toda la organización, en todos los niveles y en todas
las áreas, metas que van en apoyo al logro de los objetivos generales y dar soporte a la
alineación del negocio con los servicios de TI. Con lo cual COBIT5 hace uso del método de
planeamiento estratégico y lo utiliza específicamente para el diseño de “Metas en
cascada”.
58

Metas Corporativas de COBIT5:
COBIT5 define un conjunto de 17 metas corporativas, o sea metas empresariales

genéricas y para ello utiliza las 4 dimensiones del cuadro de mando integral (en inglés
balanced scorecard) 59. Con esta temática también hace uso de una técnica muy difundida
y la incorpora como una buena práctica a su marco de referencia.
Estas 17 metas corporativas (esta lista no es exhaustiva según COBIT5), apuntalan en

forma genérica a los objetivos más comúnmente definidos por las organizaciones.
59
Kaplan, R.; Norton, D. (1996). The balanced scorecard. USA: Harvard University

A continuación detallamos las metas corporativas en sus cuatro dimensiones60.
DIMENSION DEL
METAS CORPORATIVAS DE COBIT5
CUADRO DE MANDO
1-Valor para las partes interesadas de las inversiones de negocio
2-Cartera de productos y servicios competitivos

ECONÓMICA-
FINANCIERA 3-Riesgos de negocio gestionados (cuidado del activo)
4-Cumplimiento de leyes y regulaciones externas
5-Transparencia financiera
6-Cultura de servicio orientada al cliente
7-Continuidad y disponibilidad del servicio al negocio
CLIENTE 8-Respuestas ágiles a un entorno de negocios cambiante
9-Toma de decisiones estratégicas basadas en información
10-Optimización de costos de entrega del servicio
11-Optimización de la funcionalidad de los procesos de negocio
12-Optimización de los costos de los procesos de negocio

INTERNA 13-Programas gestionados de cambio en el negocio
14-Productividad operacional y de los empleados
15-Cumplimiento con las políticas internas
APRENDIZAJE Y 16-Personas preparadas y motivadas

CRECIMIENTO
17-Cultura de innovación del producto y del negocio
De esta forma COBIT5 propone estas 17 metas corporativas que cada empresa deberá
ponderarlas y cuantificarlas para apuntalar su propio plan estratégico y priorizar los
recursos, según el riesgo que se defina asumir, para el logro de los resultados planteados
en su estrategia.
60
Elaboración propia en base a las fuentes ya citadas en este capítulo.

Metas Relacionadas con la TI de COBIT5:
COBIT5 también define un conjunto de 17 metas relacionadas con la TI, o sea metas que
permiten en cascada de las metas corporativas (solo desde el punto de vista de TI, dado
que habrá otras metas de otras áreas) apuntalar el cumplimiento de las metas
empresariales.
También las clasifica en las 4 dimensiones del cuadro de mando integral (en inglés
balanced scorecard). A continuación detallaremos las metas de TI en sus 4 dimensiones.

DIMENSION DEL
CUADRO DE MANDO METAS RELACIONADAS CON LA TI DE COBIT5
1-Alineamiento de TI y la estrategia de negocio

2-Cumplimiento y soporte de la TI al cumplimiento del negocio de
las leyes y regulaciones externas
3-Compromiso de la dirección ejecutiva para tomar decisiones
FINANCIERA relacionadas con TI
4-Riesgos de negocio, relacionados con la TI gestionadas
5-Realización de beneficios del portafolio de inversiones y servicios
relacionados con la TI
6-Transparencia de los costos, beneficios y riesgos de la TI
7-Entrega de servicios de TI de acuerdo a los requisitos del negocio
CLIENTE 8-Uso adecuado de aplicaciones, información y soluciones
tecnológicas
9-Agilidad de la TI
10-Seguridad de la información, infraestructura de procesamiento
y aplicaciones
11-Optimización de activos, recursos y capacidades de la TI
12-Capacitación y soporte de procesos de negocio integrando
aplicaciones y tecnología en procesos de negocio
INTERNA
13-Entrega de programas que proporcionan beneficios a tiempo,
dentro del presupuesto y satisfaciendo los requisitos y normas de
calidad
14-Disponibilidad de información útil y relevante para la toma de
decisiones
15-Cumplimiento de las políticas internas por parte de la TI
16-Personal del negocio y de la TI competente y motivado
APRENDIZAJE Y
CRECIMIENTO 17-Conocimiento, experiencias e iniciativas para la innovación de
negocio
De esta forma COBIT5 propone estas 17 metas relacionadas con la TI, que cada empresa
deberá ponderarlas y cuantificarlas para apuntalar su propio plan estratégico y priorizar
los recursos, según el riesgo que se defina asumir, para el logro de los resultados
planteados en su estrategia.

Metas de los Catalizadores de COBIT5:
A partir de esta cascada de metas, se llega entonces a los catalizadores, que como ya se
ha mencionado, son “facilitadores o habilitadores” para ejecutar la gestión, e incluyen
procesos, estructuras e información, entre otros.
Para cumplir con las metas específicas cuantificadas, que se definan para la TI, se
requerirá la aplicación satisfactoria de varios catalizadores y siguiendo el concepto de la
cascada. Para cada catalizador pueden definirse una o más metas que sean relevantes,
en apoyo de las metas relacionadas con la TI.
Para ello, se deberá utilizar lo expuesto en este capítulo, sobre las “dimensiones de los
catalizadores” y las preguntas que se deben contestar sobre si los mismos están o no bien
gestionados.
Apreciaciones del autor sobre el capítulo de COBIT5:
Por lo tanto, cada organización debe generar su propia cascada, priorizando metas,
asumiendo riesgos, definiendo beneficios y logros esperados, estableciendo los recursos
a utilizar y el tiempo. Con este esquema, entonces, podrá poner en marcha los procesos
de gobierno y gestión de la TI, monitorearlos y tomar las decisiones ejecutivas para no
desviarse del rumbo estratégico definido, pero logrando que toda la organización en su
conjunto y en particular la TI, trabajen alineadas a una visión y plan del negocio y sean
gobernadas por la dirección de la organización.
De esta forma, completamos una visión conceptual de COBIT5, habiendo hecho una
selección del material oficial de ISACA y complementando cada sección de este capítulo,
con apreciaciones personales. Para mayor detalle, en los documentos oficiales, se anexan
varias matrices, en las cuales se cruzan metas corporativas, metas de TI, procesos,
dimensiones y otros instrumentos de análisis que ISACA pone a disposición de los
usuarios de COBIT5.

32 ITIL
Es importante destacar que no se trata de reproducir en detalle todo el material
existente, dado que es un framework que tiene mucha documentación disponible. El
objetivo, es hacer un compendio de los conceptos más importantes y hacer foco en la
“usabilidad práctica” de dichas herramientas. En este capítulo, describiremos las
principales características de este marco de trabajo destinado a la gestión de servicios de
TI.
ITIL - Information Technology Infrastructure Library61: Es un conjunto de conceptos y

prácticas para la gestión de servicios de las tecnologías de la información y las
operaciones relacionadas con los mismos. ITIL brinda descripciones detalladas de un
extenso conjunto de procedimientos de gestión creados para ayudar a las organizaciones
a lograr calidad y eficiencia en las operaciones de TI. Está alineado con la norma ISO
20000. Su última versión es la V3 de 2007, actualizada en 2011.
Si observamos en el capítulo del marco conceptual (ver Ilustración 4) veremos que el

mapa general de marcos de referencia, COBIT5 tiene una cobertura total, garantizando
las funciones del gobierno de TI y la gestión de TI, haciendo uso -si la organización así lo
desea- de otros marcos más específicos a una temática.
Como puede observarse en el mapa, existen 3 franjas horizontales de alcance de

funciones de Gestión de TI, como ser: alineamiento planeamiento y organización, la
segunda es construcción adquisición e implementación y la tercera entrega servicio y
soporte. Del mismo puede observarse que el triángulo de cobertura que cruza dichas tres
capas es ITIL.
Por lo tanto, para garantizar la gestión de los servicios de TI, en el marco de

Gobernabilidad que propone COBIT, puede perfectamente y es útil hacerlo, usar ITIL
como framework específico para esta temática (ver Ilustración 24).
61
What is ITIL Best Practice? | ITIL | AXELOS. AXELOS. Consultado: Diciembre 2015, de
https://www.axelos.com/best-practice-solutions/itil/what-is-itil

Estructura de ITIL
ITIL (Information Technology Infraestructure Library) es un conjunto de buenas prácticas

dedicadas a la gestión de servicios de tecnologías de la información. La última versión de
ITIL es la v3, que se publicó en junio de 2007 y en 2011 se publicó una revisión.
ITIL fue publicada por primera vez entre 1989 y 1995 por la Stationery Office (HMSO) en
el Reino Unido, en nombre de la central de Comunicaciones y Agencia Nacional de
Telecomunicaciones (CCTA). Su uso temprano se limitaba principalmente al Reino Unido
y los Países Bajos. La versión inicial de ITIL consistía en una biblioteca de 31 libros que
cubren todos los aspectos de la prestación de servicios de TI. Entre los años 2000 y 2004
esta versión inicial fue revisada y sustituida por ITIL V2. El organismo propietario de esta
referencia de estándares es la OGC (Office of Government Commerce), una entidad
independiente de del gobierno británico.
Después de una importante actualización, ITIL V3 fue publicada en 2007, que consta de
cinco publicaciones centrales que cubren el ciclo de vida del servicio. En 2011, ITIL
publicó actualizaciones de mejora62. Cada uno de las cinco publicaciones principales
cubre una etapa del servicio en el “ciclo de vida”, a partir de la definición y el análisis
inicial de los requerimientos del negocio63, totalizando 30 procesos y funciones.
ITIL contiene 5 libros principales que se condicen con el ciclo de vida:
1. Estrategia de Servicio
2. Diseño del Servicio
3. Transición del Servicio
4. Funcionamiento del Servicio
5. Mejora continua del Servicio
62
63
ITSMF UK. Itsmf.co.uk. Consultado: Enero 2016, de http://www.itsmf.co.uk/

Marco conceptual ITIL v3
Ilustración 24 - Marco ITIL 64
Como puede observarse, el marco que propone ITIL tiene una fuerte influencia de parte
del negocio, que es el objetivo final a satisfacer. Por dicha razón el diseño del servicio,
tiene especial contacto con los responsables del negocio. Por la otra parte, la puesta en
marcha desde lo instrumental, está del lado de tecnología.
64

Tanto la estrategia, la operación y el mantenimiento, son actividades transversales que

deben realizarse en conjunto. En el centro de la escena, está el “ciclo de vida del servicio”
definido por ITIL65.
Ciclo de vida de ITIL v3
Tal lo expuesto por la OGC66, (Office of Government Commerce), el sitio y documentación

oficial de ITIL, se encuentra publicado en Axelos67, existiendo también diversas
organizaciones de usuarios, que publican en forma complementaria, material sobre la
aplicación de ITIL a las organizaciones.
El ciclo de vida de ITIL para la gestión de servicios de IT, se basa en:
• Rol de la función de IT como socio estratégico del negocio
• Foco en la alineación e Integración de IT con el Negocio
Ilustración 25 - Ciclo de vida ITIL
65
Best Management Practice Portfolio - Publications - GOV.UK. (2011). Gov.uk. Consultado: Diciembre 2015,
de https://www.gov.uk/government/publications/best-management-practice-portfolio
66
Best Management Practice Portfolio - GOV.UK. (2011). Gov.uk. Consultado: Diciembre 2015, de
https://www.gov.uk/government/publications/best-management-practice-portfolio/about-the-office-of-
government-commerce
67
ITIL | AXELOS. AXELOS. Consultado: Noviembre 2015, de https://www.axelos.com/itil

A continuación describiremos estos cinco grandes macro procesos o etapas, del ciclo de
vida ITIL, que se encuentran detallados en cada uno de sus cinco libros:
1. Estrategia de Servicio
ITIL define la “Estrategia de los servicios” y propone diseñar un plan de acción que
conduzca la estrategia de la organización en relación a la TI. Para ello no solo define los
marcos internos de la organización, la estrategia de los servicios como apoyo del negocio,
responsabilidades y otros factores complementarios, sino que también abarca los
proveedores externos y la competitividad que los servicios deben tener para estar a tono
con el mercado.
2. Diseño del Servicio
ITIL define el “Diseño de los servicios” y propone que se desarrollen la arquitectura, los
procesos, las políticas y el nivel de capacidad y disponibilidad del servicio. Además
establece que se definan todos los parámetros que formen parte de nuevo servicio para
que el mismo pueda ser ejecutado eficientemente y disponga de indicadores de control,
con el fin de mantenerlo siempre sumando valor al negocio.
3. Transición del Servicio
ITIL define la “Transición de los servicios” y propone que se establezcan, tanto para
nuevos servicios como para los cambios que se realicen en los existentes, todas las
especificaciones relativas a la gestión de la configuración, la planificación de la puesta en
marcha y el soporte, los mecanismos de gestión del cambio, instrumentos para medir el
impacto de un cambio, una metodología de gestión del Conocimiento para reutilizar lo
aprendido en la ejecución y las responsabilidades de quienes participen.
4. Funcionamiento del Servicio
ITIL define el “Funcionamiento de los servicios” y propone que se establezcan las mejores
prácticas para lograr un nivel del servicio acorde a las necesidades de la Organización. Se
deben establecer claramente la gestión de incidentes, problemas, respuestas, tiempos
para cada categoría, escalamientos, mecanismos de continuidad en la operación crítica,
funcionamiento de la mesa de ayuda, funciones del personal que participa en todas las
instancias y mecanismos de reportes de evaluación.
5. Mejora continua del Servicio
ITIL define la “Mejora Continua de los servicios” y propone que se establezcan los
mecanismos pues este tópico es la garantía de aporte de valor continuo del servicio.
Establece utilizar el mecanismo Plan-Do-Check-Act en 7 pasos, para evaluar en forma

permanente, donde estamos y donde queremos llegar en relación al nivel de prestación
y eficiencia del servicio. Para ello establece la utilización de información de gestión de los
servicios, de manera útil para la toma de decisiones y la ejecución de este ciclo de mejora
continua de calidad.
Procesos y funciones asociadas al ciclo de vida de ITIL:
El ciclo de vida descripto tiene, para cada “etapa o macro proceso” que conforman el
mismo, un conjunto de procesos específicos que deben cumplirse, que suman 26
procesos y en una de las etapas existen 4 funciones que deben ser realizadas,
completando un total de 30 procesos y funciones, para la versión 3 ITIL, revisión 2011: 68
Ilustración 26 - Procesos ITIL
68
El cuadro es una elaboración propia, en base a las diversas fuentes ya citadas en este capítulo.
Dado que el “Servicio” tiene el principal objetivo de “Entregar valor a los clientes del
mismo”, cada una de las etapas descriptas en el ciclo de vida tiene que asegurar que se
cumplan los objetivos específicos para cada una de ellas. Para ello, los procesos y
funciones definidas, deben ser diseñados y ejecutados en la organización, con un
monitoreo permanente en base a indicadores de desempeño.
Funciones, procesos y roles
ITIL establece una diferenciación entre funciones y procesos. Una función es una “unidad
especializada” en la ejecución de una actividad y es la responsable de su eficacia. Las
funciones tienen que brindar a la organización la estructura de ejecución de dicha
especialidad.
Los procesos, en cambio, son un “conjunto de actividades” que se interrelacionan entre

sí, con el fin de cumplir un objetivo específico y medible. El resultado final de un proceso
es una “salida” que el cliente o receptor del mismo recibe y utiliza para su fin en el
negocio.
ITIL también define con claridad el concepto de Rol. Un rol es el grupo de actividades que
se le asigna a una persona y se le atribuye la responsabilidad por los resultados.
Por ejemplo, en este entorno, donde los servicios y procesos son los protagonistas del
mismo, para satisfacer los resultados esperados del negocio, ITIL estable como
indispensable que cada servicio y cada proceso “tenga formalmente un propietario y un
gestor”.
Estos dos tipos de roles bien podrían darse en la misma persona, o una persona podría
ser gestor de varios procesos o servicios. Lo importante es que frente a la dirección de la
organización “cada servicio y cada proceso tendrá un responsable por su desempeño”,
que será el propietario y también habrá un responsable más operativo que será el gestor
del mismo.
Al igual que hemos hecho con el capítulo de COBIT, no desarrollaremos cada uno de los
procesos en detalle para ITIL, pues dicho material está disponible y referenciado en
diversos puntos de este documento.
En particular para la última etapa de mejora continua, que propone un método de los “7
pasos”, considero útil describirla, pues su concepto intrínseco, puede ser aplicado a
diversas temáticas de gobernabilidad.
Mejora continua del Servicio - Los 7 pasos de la mejora continua -
Es fundamental que cada servicio, tenga un proceso de mejora continua, a partir de su

desempeño en la realidad, el cual debe ser medido y analizado. Tanto los niveles de
disponibilidad, los costos insumidos, la rigidez para sumar cambios en el negocio, los
reportes de monitoreo, incapacidades de responder a eventos o crisis, las percepciones
de calidad de parte de los clientes usuarios, los tiempos de respuesta y otras variables,
siempre son susceptibles de mejora permanente en el servicio y por lo tanto en los
procesos que lo componen.
El siguiente cuadro69 muestra el esquema de los 7 pasos que ITIL propone para dicha
etapa del ciclo de vida:
Ilustración 27 - Mejora Continua ITIL
69
ITSMF UK. Itsmf.co.uk. Consultado: Enero 2016, de http://www.itsmf.co.uk/
Como puede observarse, el esquema está basado en las 4 etapas del ciclo de mejora de
calidad ya mencionado en este documento (Plan-Do-Check-Act). El mismo está
enmarcado en 4 cuadrantes con diversas actividades, que refieren, en cada uno, a cuatro
conceptos que “se generarían” a partir de la ejecución correcta de dichas actividades. Los
mismos son: Datos, Información, Conocimiento, Sabiduría.
Por supuesto, las actividades del ciclo de mejora y el paso por sus cuadrantes, son
continuos y retroalimentados en forma permanente.
Hecha la descripción y fundamento de este esquema, describiremos en forma sintética,

cada uno de los 7 pasos:
1- IDENTIFICACION DE ESTRATEGIA PARA LA MEJORA
Es la definición de la visión de “hacia dónde” se quiere ir con el servicio en cuestión y

el nivel de valor que el mismo debería contribuir a las metas del negocio y la
satisfacción del cliente que lo recibe, conjuntamente con los objetivos tácticos y
operacionales esperados.
2- DEFINICION DE QUE SE QUIERE MEDIR
A partir de la definición anterior, debe establecerse “cuál” debe ser el indicador a

medir para saber si se alcanzó dichos logros y “cuanto” deben ser las métricas reales
obtenidas para satisfacer dicho criterio de éxito.
3- ACCESO A LOS DATOS
En esta actividad debe definirse “cómo” se obtendrán los datos para construir las
métricas que luego serán indicadores. Es fundamental que los datos sean
consistentes y que se defina de “donde” se obtendrán, con que instrumento, quien
lo hará, cuando y el formato de origen de los mismos.
4- PROCESO DE LOS DATOS
Con los datos disponibles, en esta actividad se establece “como se procesarán”, con
qué herramienta, cual es el algoritmo a utilizar, cómo serán los formatos de salida, el
nivel de precisión esperado de la información de salida, quien debe recibirla, cuándo
y cómo.
5- ANALISIS DE LA INFORMACION
Cuando la información esté disponible hay que analizarla. El responsable definido

para esta actividad, deberá contrastarla con los indicadores esperados y establecer la
brecha faltante, cuál es la tendencia observada, cuáles son los destinatarios que
deben saber de esta situación y delinear “cuál” es la mejora que “debería”
implementarse.
6- UTILIZACION DE LA INFORMACION
Con la definición de la mejora esperada, en esta actividad debe conjugarse y

compendiarse un resumen de la evaluación realizada sobre el servicio o los servicios
en cuestión, conjuntamente con los procesos involucrados y convertir esta intención,
en planes concretos y detallados de “como” debe implementarse la mejora definida.
7- IMPLEMENTACION DE LA MEJORA
En esta última actividad, con todo definido, hay que implementar la mejora en la
práctica y apuntalar el cambio organizacional que la misma genere. La
implementación de la misma, finaliza cuando los procesos y el servicio ya están
funcionando en régimen con la nueva modalidad y las mediciones de su
funcionamiento así lo avalan. A partir de allí se debe seguir monitoreando su
funcionamiento y cuando se generen las necesidades organizacionales, se volverá a
comenzar con la actividad 1.
El uso de este esquema para la etapa de mejora continua propuesta por ITIL, con todos
sus conceptos y componentes, está totalmente alineado con lo propuesto por la norma
ISO 9001:200870 , “Sistemas de gestión de calidad”, en el apartado de mejora continua
de los procesos. También con lo propuesto en el “Modelo de capacidad y madurez” de
procesos de COBIT5, que a su vez está alineado con la norma ISO/IEC 15504 71,
“Tecnología de la Información – Evaluación de Procesos”.
70
ISO 9000 quality management – ISO (2015). ISO. Consultado: Noviembre 2015, de
71
ISO/IEC TS 15504-10:2011 - Information technology -- Process assessment -- Part 10: Safety extension.
(2011). ISO. Consultado: Octubre 2015, de
Apreciaciones del Autor sobre el capítulo de ITIL V3 - 2011:
De esta forma, completamos una visión conceptual de ITIL, habiendo hecho una selección
del material oficial y complementando cada sección de este capítulo, con apreciaciones
personales y otros marcos de trabajo complementarios. Para mayor detalle, en los
documentos oficiales, se amplían cada uno de los procesos con recomendaciones.
Como se ha mencionado, ITIL y COBIT son totalmente complementarios. De las 5 áreas

de gestión que propone gestionar COBIT, la denominada “Entregar, dar servicio y
soporte”, perfectamente puede ser cumplida utilizando ITIL con todos sus procesos.
También ITIL, podría abarcar una parte de otras áreas, complementándose con otros
frameworks, tal como se presenta en la ilustración del marco conceptual.
33 TOGAF
TOGAF 72 es un marco unificado internacional de Arquitectura Empresarial.
Ilustración 28 - Introducción a TOGAF
72 The Open Group Architecture Framework (TOGAF)
33.1 Dimensiones de una Arquitectura Empresarial
 Arquitectura de Negocios (o de Procesos de Negocio), la cual define la estrategia de

negocios, la gobernabilidad, la estructura y los procesos clave de la organización.
 Arquitectura de Aplicaciones, la cual provee un plano (blueprint, en inglés) para cada

uno de los sistemas de aplicación que se requiere implantar, las interacciones entre
estos sistemas y sus relaciones con los procesos de negocio centrales de la
organización.
 Arquitectura de Datos, la cual describe la estructura de los datos físicos y lógicos de

la organización, y los recursos de gestión de estos datos.
 Arquitectura Tecnológica, la cual describe la estructura de hardware, software y redes

requerida para dar soporte a la implantación de las aplicaciones principales, de misión
crítica, de la organización.
33.2 Framework de arquitectura empresarial TOGAF
TOGAF (significa “The Open Group Architecture Framework” 73), es un marco de trabajo
que establece un enfoque para el diseño, planificación, implementación y gobierno de
una arquitectura empresarial de la información. Esta arquitectura se sustenta en las
cuatro dimensiones ya definidas. El Open Group es un consorcio global que permite el
logro de los objetivos de negocio a través de estándares de Tecnología de la Información
y cuenta con más de 450 organizaciones miembros.
33.3 Aplicación de TOGAF – ADM
Más conocido como ADM, sigla en inglés de "Architecture Development Method", es el

método definido por TOGAF para el desarrollo de una arquitectura empresarial que
cumpla con las necesidades empresariales y de tecnología de la información de una
organización. Puede ser ajustado y personalizado según las necesidades propias de la
organización y una vez definido se utiliza para gestionar la ejecución de las actividades
de desarrollo de la arquitectura.
73
TOGAF® Publications | The Open Group. Opengroup.org. Consultado: Noviembre 2015, de
http://www.opengroup.org/publications/togaf
Se realizará en este documento una apertura de las 9 fases del ADM.
Ilustración 29 - ADM TOGAF
33.4 Fase Preliminar de TOGAF
Esta fase preliminar es sobre la definición de "cómo hacer arquitectura" de la

organización en cuestión. Hay dos aspectos principales: la definición del marco que se
utilizará, y la definición de los principios de arquitectura que va a informar a cualquier
obra de arquitectura.
El enfoque de la organización para la reutilización de los activos de la arquitectura es una

parte fundamental tanto de la definición del marco y los principios de la arquitectura.
OBJETIVOS
Examinar el contexto de la organización para llevar a cabo AE
Identificar el alcance y las áreas afectadas por la AE
Identificar los marcos de referencia y métodos existentes
Establecer el modelo de AE que soporte a la organización
ENTRADAS
TOGAF como marco de referencia
Estrategia organizacional definida
Estado actual de la AE en el organismo
Marcos de referencia existentes
Repositorio de requerimientos
SALIDAS
Modelo organizacional de la AE
Principios de arquitectura
Repositorio de AE
Reafirmación de los principios y motivaciones organizacionales
33.5 Fase “A” Visión de Arquitectura
En esta fase, se establece el proyecto de arquitectura junto con el alcance de la iniciativa

de EA. Se deben identificar las partes interesadas, sus inquietudes y requerimientos de
negocio. En esta fase, es el momento en el que también se deben confirmar los principios
de arquitectura y desarrollar la visión de arquitectura para poder proporcionar una visión
general de los cambios que se llevarán a cabo en la organización como resultado de la
iniciativa de EA.
OBJETIVOS
Desarrollar una visión de alto nivel del valor que la AE dará a los objetivos de la institución
Obtener una declaración de aprobación del trabajo de AE
ENTRADAS
Modelo organizacional de la AE
Principios de arquitectura
Reafirmación de los principios y motivaciones organizacionales
Repositorio de AE actualizado y validación con la gestión de requerimientos
SALIDAS
Aprobación sobre el trabajo de AE para soportar los objetivos de la organización y su

aporte de valor
Visión de arquitectura, objetivo Destino
Repositorio AE actualizado
33.6 Fase “B” Arquitectura del Negocio
En esta fase, se establece en particular el modelo de negocio definido por la organización,

con el fin de establecer las necesidades para soportarlo adecuadamente y definir la
brecha actual que tiene la organización para alcanzar la arquitectura necesaria, con un
plan de avance incremental en este tópico.
OBJETIVOS
Desarrollar la arquitectura del negocio definido en el plan estratégico, estableciendo

cómo la organización tiene que operar para lograrlo
Establecer un plan incremental para abordar la brecha actual identificada de arquitectura

del negocio y las metas intermedias a lograr
ENTRADAS
Aprobación sobre el trabajo de AE para soportar los objetivos de la organización y su

aporte de valor
Visión de arquitectura, objetivo Destino
SALIDAS
Definiciones validadas del modelo de negocio y sus necesidades
Línea base de arquitectura del negocio actual
Plan incremental para alcanzar la arquitectura final
33.7 Fase “C” Arquitectura de los sistemas de Información
En esta fase se abordan las necesidades para el negocio de utilización de los sistemas de
información. En relación a los mismos se debe establecer la arquitectura necesaria y un
plan para resolver la brecha que se identifica con la situación actual, tanto a nivel de
arquitectura de datos y de aplicación.
OBJETIVOS
Desarrollar la arquitectura del negocio definido en el plan estratégico, estableciendo

cómo la organización tiene que operar para lograrlo

del negocio y las metas intermedias a lograr
ENTRADAS
Definiciones validadas del modelo de negocio y sus necesidades
Línea base de arquitectura del negocio actual
Plan incremental para alcanzar la arquitectura final
SALIDAS
Definiciones sobre la arquitectura de datos necesaria para soportar el modelo final del
negocio
Definiciones sobre la arquitectura de la aplicación necesaria para soportar el modelo final

del negocio
Establecimiento de niveles de operabilidad y comportamiento de los sistemas aplicativos
Plan de evolución con metas específicas para resolver la brecha con la situación actual y
la buscada
33.8 Fase “D” Arquitectura de la Tecnología
Establecer en detalle la arquitectura tecnológica final que la organización necesita para

su negocio y la concreción de su plan estratégico. Esta arquitectura debe contener tanto
los elementos físicos como lógicos para su concreción. Además se debe establecer un
plan de evolución para resolver la brecha con la tecnología actual.
OBJETIVOS
Desarrollar la arquitectura tecnológica necesaria para soportar el plan estratégico del

negocio, estableciendo los componentes físicos y lógicos

tecnológica y las metas intermedias a lograr
ENTRADAS
Definiciones sobre la arquitectura de datos necesaria para soportar el modelo final del
negocio
Definiciones sobre la arquitectura de la aplicación necesaria para soportar el modelo final

del negocio
Establecimiento de niveles de operabilidad y comportamiento de los sistemas aplicativos
Plan de evolución con metas específicas para resolver la brecha con la situación actual y
la buscada
SALIDAS
Establecer la línea base de la arquitectura tecnológica actual, tanto en sus componentes

físicos como lógicos
Definir las necesidades de una arquitectura destino, considerando las necesidades

actuales del negocio y su visión de evolución en el tiempo
Establecer necesidades críticas tales como interoperabilidad on line, seguridad,

ambientes web, servicios tecnológicos para aplicativos de movilidad, etc.
Preparar un plan evolutivo para resolver la brecha detectada entre la situación actual y
la esperada final
33.9 Fase “E” Oportunidades y Soluciones
En esta fase se comienza el trabajo analítico sobre la implementación que se deberá

realizar en la organización para lograr la arquitectura final completa necesaria y
establecida.
Se define un documento de visión de “como” se realizarán estos programas y proyectos,

considerando las ventajas que se detecten como aportantes para este desafío y las
soluciones previstas para los problemas que puedan identificarse como riesgos para el
plan.
OBJETIVOS
Visión inicial global del plan de implementación para cubrir las brechas definidas de
arquitectura en todas las fases anteriores
Identificación de metas intermedias para ejecutar este plan global de forma incremental
ENTRADAS
Línea base de la arquitectura tecnológica actual, tanto en sus componentes físicos como
lógicos
Necesidades de una arquitectura destino, considerando las necesidades actuales del

negocio y su visión de evolución en el tiempo
Necesidades críticas tales como interoperabilidad on line, seguridad, ambientes web,

servicios tecnológicos para aplicativos de movilidad, etc.
Plan evolutivo para resolver la brecha detectada entre la situación actual y la esperada
final
SALIDAS
Documento actualizado de la visión de la arquitectura global necesaria final para todas

las dimensiones
Definición de las brechas de arquitectura a cubrir en todas las fases anteriores
Documento de visión del plan global de implementación
Identificación de oportunidades en la organización para el éxito del plan y soluciones

propuestas a los riesgos del mismo
Definición de estrategias de migración tecnológica para los diferentes componentes que

deban evolucionar
33.10 Fase “F” Plan de Migración
En esta fase se define con nivel de detalle, el plan a ejecutar para la migración de la
arquitectura actual, definida en las líneas base, hacia el modelo esperado de la
arquitectura empresarial.
OBJETIVOS
Disponer de un plan detallado de migración de la arquitectura empresarial actual, hacia

la definida
Asegurar los diferentes aspectos que hacen al éxito del plan, tales como costos, calidad,
consenso de los interesados, valor para el negocio
ENTRADAS
Documento actualizado de la visión de la arquitectura global necesaria final para todas

las dimensiones
Definición de las brechas de arquitectura a cubrir en todas las fases anteriores
Documento de visión del plan global de implementación
Identificación de oportunidades en la organización para el éxito del plan y soluciones

propuestas a los riesgos del mismo
Definición de estrategias de migración tecnológica para los diferentes componentes que

deban evolucionar
SALIDAS
Plan detallado de migración de la arquitectura empresarial actual, hacia la definida
Identificación de aspectos críticos para su éxito y planificación de acciones al respecto en

el plan
Identificación y plan de gestión de riesgos
Modelo de gestión del proyecto de implementación
Generación de instancias intermedias en el plan de migración para validar

organizacionalmente los avances, las lecciones aprendidas y ajustar el resto del plan en
curso
33.11 Fase “G” Gobierno de la Implementación
En esta fase se espera conseguir los mecanismos que aseguren que la implementación
en curso de la nueva arquitectura empresarial -con las brechas ya definidas y el plan
específico en marcha para cubrirlas- tenga un avance óptimo de acuerdo a lo previsto y
en el caso de desvíos o cambios en las definiciones de la arquitectura, se disponga de
procesos de gestión y gobernabilidad de dicha implementación para que la misma no se
aparte de los objetivos organizacionales establecidos.
OBJETIVOS
Asegurar que los proyectos en curso cubran de manera eficiente, el nuevo modelo de
arquitectura empresarial definida y se gestionen en forma gobernada los cambios de
arquitectura que surjan durante el proyecto
Disponer de mecanismos de gobierno del proyecto con el fin de garantizar que los
mismos se ejecuten en calidad y tiempo definidos, como así también que cualquier
cambio en el plan esté gestionado
ENTRADAS
Plan detallado de migración de la arquitectura empresarial actual, hacia la definida
Identificación de aspectos críticos para su éxito y planificación de acciones al respecto en

el plan
Identificación y plan de gestión de riesgos
Modelo de gestión del proyecto de implementación
Generación de instancias intermedias en el plan de migración para validar

organizacionalmente los avances, las lecciones aprendidas y ajustar el resto del plan en
curso
SALIDAS
Indicadores sobre la evolución del proyecto
Métricas de desempeño de las implementaciones parciales de componentes de la nueva

arquitectura
Modelo de operación del negocio con la arquitectura implementada
Solicitudes de cambios identificadas
Acuerdos de tiempos de respuestas
Evaluaciones de conformidad
33.12 Fase “H” Gestión de cambios en la Arquitectura
Esta fase debe asegurar que los cambios identificados sean gestionados con un proceso
específico y los mismos estén controlados y validados en los diferentes aspectos que
tienen impacto en la implementación.
OBJETIVOS
Asegurar que se cumple el ciclo de vida de un requerimiento de cambio
Asegurar que se cumplen los procesos de gobierno para los cambios
Asegurar que los cambios están alineados con la Arquitectura empresarial esperada por
el negocio
ENTRADAS
Indicadores sobre la evolución del proyecto
Métricas de desempeño de las implementaciones parciales de componentes de la nueva

arquitectura
Modelo de operación del negocio con la arquitectura implementada
Solicitudes de cambios identificadas
Acuerdos de tiempos de respuestas
SALIDAS
Plan de implementación de los cambios aprobados
Actualización del modelo de arquitectura empresarial
Análisis de riesgos realizado
33.13 Proceso de Gestión de Requerimientos
Este proceso interactúa con todas las fases del ADM. Es un proceso dinámico que se
retroalimenta con la fase que se ejecuta. Se genera un repositorio permanentemente
actualizado sobre los requerimientos que el negocio necesita para la organización y las
necesidades asociadas de soporte de la tecnología de la información. Debe gestionar los
cambios permanentes de requerimientos y dejar establecida la solución posible a los
mismos.
OBJETIVOS
Asegurar que el proceso de gestión de requerimientos interactúe y se actualice en todas

las fases del ADM
Asegurar que la arquitectura empresarial que se defina considere los requerimientos

actualizados y brinde una cobertura a los mismos en la ejecución de los proyectos
ENTRADAS
Los requerimientos iniciales estratégicos para el negocio
Todas las salidas que se produzcan en cada fase del ciclo del ADM
SALIDAS
Repositorio de requerimientos actualizado
Evaluación del impacto de cada requerimiento
Plan de ejecución para su cobertura
33.14 Contínuum Empresarial
Este concepto que aplica TOGAF, tiene como objetivo proporcionar un modelo de trabajo
dinámico para el arquitecto. El mismo, define “cómo” una solución genérica puede ser
utilizada y ajustada de tal forma que soporte los requerimientos de una organización en
particular.
El continuum empresarial puede ser una “vista del Repositorio de la Arquitectura” el cual
provee métodos y patrones para clasificar “arquitecturas y soluciones”, mientras las
mismas están en pleno desarrollo y evolución.
33.15 Repositorio de la Arquitectura
Es un soporte concreto para llevar a la realidad el concepto de “continuum empresarial”.

Puede tener diferentes funciones y estar montado en diferentes tecnologías, pero debe
cumplir con las premisas mencionadas en todo este capítulo de TOGAF. El repositorio y
todas sus salidas, deben satisfacer las necesidades de diferentes púbicos que están
directa o indirectamente involucrados con la creación de la arquitectura empresarial, por
ejemplo: socios, directivos, gerentes, arquitectos, técnicos, desarrolladores y otros
actores de este proyecto organizacional.
33.16 Definición final de la arquitectura empresarial
Para llegar a esta instancia final, es posible que deban realizarse varios ciclos del ADM,
en los cuales se profundiza cada fase, con el fin de disponer de un plan real y factible.
Una vez comenzado el plan de ejecución, se debe seguir monitoreando el avance de los
proyectos y analizar si surgen impactos para el diseño de la arquitectura empresarial,
teniendo en muchos casos que revisar y actualizar algunas de las fases.
La dirección de la organización debe definir el nivel de profundidad que se dará a este

proceso de diseño del ADM y los resultados deben estar en línea con los objetivos
estratégicos organizacionales, los tiempos necesarios y el presupuesto disponible para
invertir. De esta manera TOGAF colabora fuertemente con la alineación de la tecnología
y el negocio.
34 ZACHMAN
El Framework o Marco de Trabajo de Zachman74, se utiliza para el desarrollo de

arquitecturas empresariales. Fue creado su autor en 1984 y se difundió por IBM en 1987.
Es uno de los Frameworks de mayor difusión en la temática, junto con Togaf.
El modelo, establece que la arquitectura empresarial (u otro proyecto), puede diseñarse

y visualizarse, como la intersección de dos grandes clasificaciones. La primera, es una serie
de preguntas básicas:
1. ¿Qué?
2. ¿Cómo?
3. ¿Dónde?
4. ¿Quién?
5. ¿Cuándo?
6. ¿Por qué?
Estas respuestas, dan una taxonomía que puede explicar en forma simple, ideas y
entornos complejos. La segunda clasificación, es el producto de seis visiones diferentes,
que conforman, en cada caso, una transformación de una abstracción en una salida
tangible:
1. Identificación del alcance, según la perspectiva de los Ejecutivos

2. Requerimientos, según la perspectiva del Negocio
3. Diseño lógico, según la perspectiva del Arquitecto
4. Diseño físico, según la perspectiva del Ingeniero
5. Configuración, según la perspectiva del Desarrollador
6. Implementación, según la perspectiva del Producto/Negocio
Por lo dicho, Zachman es más un modelo para “Explicar y Definir” un proyecto complejo,
que una metodología de implementación, propiamente dicha.
Para ello, de define una matriz entre las dos grandes clasificaciones de 6 componentes
cada una. En las columnas va la primer clasificación y en las filas las segunda clasificación.
Cada restricción de una fila, debe sumarse a las otras, teniendo así un conjunto de
restricciones del entorno para este proyecto. En cada columna se representa una
abstracción con el objetivo de simplificarla para representar en forma simple la realidad
que contesta cada pregunta, sobre el proyecto. Por lo tanto cada “Intercepción” (fila-
columna), es UNICA y totalizan 36 descripciones.
74
Zachman, J. (2008). About the Zachman Framework. Zachman.com. Consultado: Febrero 2016, de
https://www.zachman.com/about-the-zachman-framework
A continuación vemos en forma gráfica el Framework Zachman75 descripto

anteriormente:
Ilustración 30 - Mapa ZACHMAN
75
Zachman, J. (2008). About the Zachman Framework. Zachman.com. Consultado: Febrero 2016, de
https://www.zachman.com/about-the-zachman-framework
El marco Zachman muestra la visión estática de las 36 descripciones que se dan en las
intercepciones de la matriz. No tiene como fin definir los procesos para lograr una nueva
situación evolutiva a la existente. Este marco es aplicable tanto para una visión de una
arquitectura empresarial, como así también para un sistema de información en particular.
34.1 Descripción en detalle de las columnas o enfoques
1 - Qué: Enfoque a los datos. Describe las entidades involucradas en cada proceso de la
organización y las relaciones entre ellas.
2 - Cómo: Enfoque a la función. Describe las funciones que deben disponerse dentro de
cada vista. Incluye los diferentes tipos de procesos.
3 - Dónde: Enfoque a la red. Describe las localizaciones de diferentes componentes de la

red y las interconexiones entre ellos en la organización.
4 - Quién: Enfoque a personas. Describe las relaciones entre las personas dentro de la
organización. Se establecen roles, responsabilidades y la interacción horizontal.
5 – Cuándo: Enfoque temporal. Describe la representación de los eventos en el tiempo y

los factores críticos de rendimiento esperado de cada evento.
6 - Por qué: Enfoque Motivacional. Describe las motivaciones estratégicas de la

organización. Los objetivos definidos a nivel global y del plan de negocios en particular.
Establece para qué se espera contar con una arquitectura empresarial que soporte al
negocio.
34.2 Descripción en detalle de las filas o vistas
1 – Vista de Planificación y Alcance: Es una visión a nivel global y estratégico que

proporciona una perspectiva sobre el sistema de la arquitectura a lograr para poder
soportar e impulsar los objetivos de negocio. Se define en términos generales, costos,
tiempos, complejidad y su interacción con el contexto interno y externo de la
organización. Es una vista de nivel ejecutivo.
2- Vista del Modelo de Negocio: Es una visión del modelo del negocio y los procesos que
lo sustentan. Tiene su fortaleza en los intereses de los dueños del negocio y se espera
identificar las entidades y las relaciones con los procesos. Se espera expresar claramente
los requerimientos del negocio que deben ser satisfechos por arquitectura empresarial.
Es una vista del propietario del negocio.
3 – Vista Lógica del Diseñador: Es una visión de diseño que espera conseguir los planos
conceptuales de la solución a nivel lógico. Debe determinar elementos de datos, el flujo
de la lógica de los procesos y las funciones que representan los procesos de negocios. Es
una vista de arquitectura.
4 – Vista del diseño físico y tecnológico: En esta visión se espera un nivel de detalle de
los componentes de la solución. Se tienen en cuenta las restricciones existentes en el
plano tecnológico y se diseña una solución factible que responda al diseño lógico. Se
definen tecnologías, lenguajes, sistemas y cualquier otro componente tecnológico de
base. Es una visión ingenieril.
5 – Vista detallada de configuración: Es una visión de los componentes detallados que

deben construirse, la integración entre ellos, las especificaciones de interactividad y
todas las definiciones que diferentes desarrolladores y técnicos deben concretar para
satisfacer la arquitectura tecnológica esperada. En este mapa de componentes de una
solución global, puede haber partes que se desarrollen y otras que se adquieran y se
integren como parte de la solución. Es una visión a nivel de desarrolladores.
6 – Vista del Sistema Actual / Empresa en Funcionamiento: Se visualiza la

implementación final del sistema / arquitectura en funciones. Es una visión empresarial
del negocio en funcionamiento.
34.3 Un ejemplo interpretado de la matriz:
A continuación se muestra un ejemplo del contenido posible 76, de las intercepciones de

la matriz, de acuerdo a los criterios ya explicitados para este Framework, adaptado a un
caso y necesidad en particular.
76
Apunte ITBA de Conceptos de arquitectura empresarial, por Ing. L. Stabile, 2014, Buenos Aires.
Ilustración 31 - Matriz ZACHMAN
Como puede apreciarse, el Framework permite una gran taxonomía para explicar
entornos y sistemas complejos, desde todas las perspectivas. No es un método de
implementación y cada caso en particular puede adaptarlo a sus necesidades.
35 PMI
Para diseñar y ejecutar proyectos, existen metodologías que permiten transitar en forma
previsible el camino. El uso de las mismas es responsabilidad del Líder de proyectos, pues
los proyectos se desarrollan en un contexto de organizaciones y personas. Los proyectos
se identifican y se priorizan en cada organización, como parte de los logros esperados
para sustentar la estrategia organizacional definida.
Como se observa, a diferencia de un trabajo continuo y permanente, un proyecto tiene

“restricciones” que le dan forma y deben cumplirse para que el mismo sea exitoso, en un
marco de calidad predeterminada.
35.1 La metodología de proyectos
En relación a la metodología, existen diversos marcos de trabajo a nivel internacional.

Desarrollaremos a continuación, la visión del PMI, que se ha consolidado como un
estándar mundial.
Project Management Institute77 (PMI) es una asociación internacional fundada en 1969,

dedicada a mejorar el estado del arte de la ciencia y aplicación de la Administración de
Proyectos. Difunde estándares internacionales en un cuerpo de conocimientos de la
Administración de Proyectos, el PMBOK GUIDE (Project Management Body of
Knowledge).
En su versión del PMBOK 5 del 2013, el PMI establece 5 grupos de procesos, 10 áreas de
conocimiento y 47 procesos que se definen de la intercepción de ambas categorías.
La Guía de los Fundamentos para la Dirección de Proyectos (Guía del PMBOK®), quinta
edición, proporciona pautas para la dirección de proyectos. Describe asimismo el ciclo de
vida de la dirección de proyectos y los procesos relacionados.
La Guía del PMBOK® contiene el estándar, reconocido a nivel global y la guía para la
profesión de la dirección de proyectos. Por estándar se entiende un documento formal
que describe normas, métodos, procesos y prácticas establecidos. Al igual que en otras
profesiones, el conocimiento contenido en este estándar evolucionó a partir de las
buenas prácticas reconocidas de los profesionales dedicados a la dirección de proyectos
que han contribuido a su desarrollo.
77
Project Management Institute, Inc. Pmi.org. Consultado: Marzo 2016, de http://www.pmi.org
Definición del PMI78:
La dirección de proyectos es aplicación de conocimientos, habilidades, herramientas y

técnicas para cumplir con los requisitos del proyecto.
Las restricciones que tiene un proyecto, el PMI históricamente las ha definido como estas
tres:
Ilustración 32 - PMI restricciones
Las características específicas del proyecto y las circunstancias pueden influir sobre las
restricciones, en las que el equipo de dirección del proyecto necesita concentrarse. La
relación entre estos factores es tal que si alguno de ellos cambia, es probable que al
menos otro de ellos se vea afectado.
78
PMBOK Guide. (2016). Pmi.org. Consultado: Enero 2016, de http://www.pmi.org/PMBOK-Guide-and-
Standards/pmbok-guide.aspx
A partir de las versiones 4 y 5 (la última) del PMBOK, las restricciones se han ampliado
explícitamente y han quedado establecidas de la siguiente manera:
Ilustración 33 - PMI Nuevas restricciones
O sea que se han agregado el “Riesgo”, “Calidad” y “Satisfacción del cliente”.
Como parte de su concepción global, establece que el “ciclo de dirección de un

proyecto” se compone de 5 procesos bien definidos que se van cristalizando en el
tiempo.
Ilustración 34 - PMI Procesos
Analizando el gráfico, el primer camino secuencial podría indicarnos que los procesos
se dan como: Inicio – Planeamiento – Ejecución – Control – Cierre. Esto sin dudas es
un camino “ideal”, pero como existe la realidad y existen imprevistos, el proceso de
control “impacta” en reajustar el plan y nuevamente volver a controlar la nueva
ejecución, logrando así un feedback (retroalimentación) de los procesos con el fin de
“cumplir” con el objetivo del proyecto. Estos procesos son de DIRECCION del proyecto,
e independientes a las fases o etapas propias del proyecto en relación al contenido
que produce.
Ilustración 35 - PMI ciclo de vida
Traducción del gráfico, por parte del Autor:
 Activity level: Nivel de Actividad

 Time: Tiempo
 Iniciation Processes: Procesos de inicio
 Planning Processes: Procesos de Planificación
 Execution Processes: Procesos de Ejecución
 Controlling Processes: Procesos de Control
 Closing Processes: Procesos de Cierre
Otro eje de análisis en esta metodología, son las áreas de conocimiento que debe
tener el PM (Project management), quien debe gerenciar el proyecto para cumplir con
los 5 procesos descriptos. Estas 10 áreas de conocimiento, son las diversas temáticas
que deben ser conocidas por el PM y que se ejecutan -según el proyecto- en forma
combinada durante la ejecución de los 5 procesos.
Ilustración 36 - PMI áreas temáticas
Hasta la versión del Pmbok 4, las áreas de conocimiento eran 9. En la última versión
se agregó la décima que se denomina, “Gestión de los stakeholders” o sea de los
interesados en el proyecto, que se la debe tomar como un objetivo clave del mismo.
Los interesados son personas u organizaciones a los que el proyecto puede afectar o
que pueden influir en el éxito del mismo. Es necesario identificar a todos los
interesados del proyecto aunque su relación con el mismo no sea evidente, y
esclarecer su rol en el proyecto y su postura frente al mismo.
Con la combinación de estos dos ejes de análisis (procesos y áreas de conocimiento)

el PMI establece una metodología detallada, que fundamentalmente apuntalan el
“que” debe hacerse, sin establecer específicamente los instrumentos.
Dado que el proceso de “planeamiento” es el más laborioso y detallado, pues en él se

define, el trabajo a realizar, la asignación en forma particionada a diversos recursos,
los costos, los tiempos, los riesgos y demás componentes de un buen plan, es
importante conocer una técnica que se usa internacionalmente denominada WBS.
35.2 Que es la WBS?
WBS significa Work Breakdown Structure, o sea una técnica para desagregar el trabajo
en partes más pequeñas de una manera jerárquica – de mayor a menor - y en forma
estructurada, partiendo de un tronco y llegando al final, a las hojas de un árbol, que serían
las tareas necesarias a ejecutar. La suma y el cumplimiento de todas ellas en tiempo y
forma, darán como resultado el cumplimiento del objetivo del proyecto con el alcance,
tiempos y recursos definidos.
Se muestra a través de un diagrama de varios niveles. En este esquema no se tienen en

cuenta tiempos, ni secuencias de las tareas del proyecto – esa es otra instancia – el
objetivo del WBS es entender el trabajo que hay que hacer y particionarlo hasta llegar a
unidades manejables.
En el gráfico siguiente se observa cómo a partir del objetivo general de un proyecto se va

subdividiendo hasta llegar a la asignación de una unidad de trabajo llamada tarea, a un
responsable particular.
Ilustración 37 - Proyectos WBS
Este trabajo es arduo pues es una “conceptualización” de lo que hay que hacer para lograr
un objetivo. El objetivo general con el alcance definido, se particiona en objetivos
específicos buscando que los mismos sean un subproyecto en sí mismo, con la menor
(nunca es nulo) dependencia posible de otros. A partir de ahí para cada objetivo
específico se definen resultados concretos o como se lo denomina en la jerga, “productos
entregables”, o sea un resultado tangible, medible y auditable, ya sea una pieza física o
un servicio o una pieza intangible.
Con esta definición de los “entregables del proyecto” (pueden ser 3, 5, o 30 según la
complejidad del proyecto), se deben asegurar que la suma de ellos significa el “todo” del
proyecto. A partir de ahí, hay que definir el “trabajo que hay que hacer” para conseguir
cada entregable. Se establece en base al conocimiento del proyecto y experiencias
anteriores, las “actividades” a realizar que sumadas darán el entregable en cuestión.
Dichas actividades, si tienen un tamaño o complejidad mayor, se dividen en tareas o

subtareas.
En el siguiente cuadro79 se muestra en términos globales, cuales son las “intercepciones”

entre los procesos y las áreas temáticas o de conocimiento, en las que existe mayor
actividades críticas a ejecutar.
Ilustración 38 - PMI matriz
79
Tomado de material didáctico, producido para GESTI, por Díaz, Carrarbal, y Sens.
En el cuadro siguiente, hay un nivel de apertura de dichas actividades, siendo las que
están en rojo, las nuevas que aportó la versión 5 del PMBOK80.
Ilustración 39 - Actividades de la matriz
80
Compilación del cuadro, Ing. PMP Felipe Meléndez de la Cruz, 2013.
A continuación se explicita en términos generales, las principales metas que se espera

lograr, desde la vista de cada proceso en particular, de los 5 grupos mencionados.
Proceso de Inicio
Las metas del Proceso de Inicio son.
 Compromiso de las máximas autoridades de la organización, para comenzar el

proyecto y afectar los recursos necesarios.
 Puesta en situación de los actores del proyecto y comunicación formal a los que
serán la parte afectada, directa o indirectamente, de los resultados de l proyecto.
 Es el punto en el cual el proyecto comienza a EXISTIR.
Proceso de Planeamiento
Se realizan las siguientes acciones, las cuales deben iterar hasta tener el aval de los
actores críticos del proyecto:
 Verificación del alcance

 Definición de entregables
 Definición de actividades
 Estimación de esfuerzo y cronograma
 Definición de riesgos
 Definición del plan de calidad
 Definición de recursos humanos
 Plan de adquisiciones
 Plan de comunicación
 Estimación de presupuesto
 Construcción del WorkBreakDown Structure
Proceso de Ejecución
Se realizan las siguientes acciones, con el fin de asegurar el cumplimiento del objetivo
del proyecto:
 Administración del alcance

 Ejecución de actividades
 Desarrollo del equipo de trabajo
 Aseguramiento del plan de calidad
 Compras y contrataciones
 Distribución de información
 Implementaciones
Proceso de Control
Se realizan las siguientes acciones, con el fin de asegurar que no existan desvíos del
plan del proyecto, y disparar las acciones correctivas necesarias:
 Control de tiempos
 Control de costos
 Control de calidad
 Control de métodos y procedimientos
 Control de riesgos
 Control de alcance
 Control de cambios en el proyecto
Proceso de Cierre
Se realizan las siguientes acciones, con el fin de dejar establecido formalmente la

terminación del proyecto y los resultados obtenidos, como así también las
recomendaciones para la continuidad en el marco de la organización:
 Evaluación de productos entregables

 Cierre de contratos
 Análisis de recursos y tiempos reales insumidos
 Distribución de información del cierre
 Documento de finalización y recomendaciones
De esta manera el PMI establece la aceptación de la dirección de proyectos como una

profesión, e indica que la aplicación de conocimientos, procesos, habilidades,
herramientas y técnicas puede tener un impacto considerable en el éxito de un
proyecto.
La Guía del PMBOK®81 identifica ese subconjunto de fundamentos para la dirección de

proyectos generalmente reconocido como buenas prácticas. “Generalmente
reconocido” significa que los conocimientos y prácticas descritos son aplicables a la
mayoría de los proyectos, la mayoría de las veces, y que existe consenso sobre su valor
y utilidad. “Buenas prácticas” significa que se está de acuerdo, en general, en que la
aplicación de conocimientos, habilidades, herramientas y técnicas puede aumentar las
posibilidades de éxito de una amplia variedad de proyectos.
Buenas prácticas, no significa que el conocimiento descrito deba aplicarse siempre de

la misma manera en todos los proyectos; la organización y/o el equipo de dirección
del proyecto son los responsables de establecer lo que es apropiado para cada
proyecto concreto.
81
PMBOK Guide. Pmi.org. Consultado: Marzo 2016, de http://www.pmi.org/PMBOK-Guide-and-
Standards/pmbok-guide.aspx
36 CMMI
CMMI ® (Capability Maturity Model Integration) es un modelo de evaluación de la

madurez de los procesos de una organización para el desarrollo de productos y servicios.
El mismo fue desarrollado inicialmente para los procesos relativos al software para el SEI
(Software Engineering Institute). 82
El SEI es un centro de investigación y desarrollo patrocinado por el Departamento de

Defensa de los Estados Unidos de América y gestionado por la Universidad Carnegie
Mellon.
En la visión escalonada y centrada en la madurez de la organización, el modelo definirá

en su conjunto, un nivel de madurez del 1 al 5, en función de qué áreas de procesos
consiguen sus objetivos y se gestionan con principios de ingeniería.
Las mejores prácticas propuestas por CMMI son publicadas en documentos denominados
“modelos”. Actualmente hay tres áreas cubiertas por los modelos de CMMI: 1-Desarrollo,
2-Adquisición, 3-Servicios. Define cinco niveles de madurez. En cada nivel se establecen
un conjunto de áreas de procesos y prácticas que deben ser cumplidas. Las tres áreas
son:
 CMMI-DEV para desarrollo. Se enfoca en la gestión de los procesos de desarrollo de

productos
 CMMI-ACQ para adquisiciones. Se enfoca en la gestión de la cadena de suministro,

adquisiciones y contrataciones.
 CMMI-SVC para servicios. Se enfoca en la gestión de servicios.
Actualmente está vigente la versión 1.3 del 2010 de CMMI.
82
CMMI Institute. Cmmiinstitute.com. Consultado: Diciembre 2015, de http://cmmiinstitute.com/#home
Las organizaciones no son “certificadas” por CMMI. Las mismas son “evaluadas” con un
método denominado SCAMPI (Standard CMMi Appraisal Method for Process
Improvement), por lo cual la organización recibe el resultado de dicha evaluación,
dándole un nivel de madurez del 1 a 5. El primer nivel evaluado es el 2.
Eventualmente, la organización podrá evaluar solamente “áreas de proceso” particulares

por lo cual recibirá lo que se denomina "Perfil de Capacidad" de la Organización.
La madurez de una organización es la medida en la cual la misma ejecuta sus procesos con
mayor rigor y con un amplio conocimiento de parte de todos los actores partícipes de la
organización. El modelo escalonado de CMMi define que se va subiendo en los “niveles
de madurez” desde el 2 al 5, según se vayan cumpliendo nuevas prácticas por nivel.
36.1 Niveles de Madurez de CMMI
Ilustración 40 - CMMI niveles de madurez
Nivel 1: Inicial básico
Los resultados de la organización son consecuencia de la impronta de las personas y

no de procesos. Es una organización inmadura.
Nivel 2: Repetible o gestionado
Se ejecutan prácticas básicas de gestión de proyectos mediante el uso de procesos.

Los equipos de los proyectos reutilizan las mejores prácticas realizadas, para aplicarlas
en nuevos proyectos.
Nivel 3: Definido
Los procesos para el desarrollo del software se documentan y están disponibles en un

repositorio. Las personas los utilizan y están formadas para proponer mejoras en
forma proactiva.
Nivel 4: Gestionado por indicadores
La organización dispone de métricas e indicadores de los procesos que generan los

productos y los servicios. Existe previsibilidad y los indicadores permiten tomar
decisiones para adoptar medidas correctivas.
Nivel 5: Optimizado
La mejora continua es una actividad permanente en la organización. Se identifican

riesgos y oportunidades y se ejecutan acciones en base a ello. Se analizan causas de
los defectos y las mejoras se analizan en base a su eficiencia y su aporte a los objetivos
de la organización.
36.2 Estructura escalonada
CMMI presenta una estructura escalonada, partiendo del nivel de madurez pretendido,
las áreas de proceso que deben cumplirse para dicho nivel, los objetivos definidos para
dicha área de proceso y las prácticas que deben realizarse para cumplir dichos objetivos.
O sea, se evalúa desde abajo hacia arriba el cumplimiento (con evidencias concretas) de
las prácticas, que si todas se cumplen, entonces se alcanza el nivel de madurez.
Ilustración 41 - Estructura CMMI
CMMI para Desarrollo contiene 22 áreas de proceso. Cada área es un conjunto de

prácticas que se implementan y consiguen lograr los objetivos de calidad definidos por la
organización, como importantes, para dicha área. 83
83
CMMI® para Desarrollo, Versión 1.3. (2010). sei.cmu.edu. Consultado: Diciembre 2015, de
http://www.sei.cmu.edu/library/assets/whitepapers/Spanish%20Technical%20Report%20CMMI%20V%201%2
03.pdf
36.3 Areas de proceso
A continuación se muestra una tabla propia, en la cual se agrupan las áreas de proceso
por el nivel de madurez que CMMi establece84. Cada nivel de madurez es “Acumulativo”
del cumplimiento de las áreas de proceso del nivel anterior.
Ilustración 42 - Areas de proceso CMMI
Cumplir en la evaluación con un nivel de madurez, implica que se cumplen los

objetivos y prácticas (con evidencias concretas) para “todas” las áreas de proceso de
ese nivel y los anteriores.
Objetivos Genéricos
Los objetivos genéricos se denominan así porque la misma declaración del mismo se
aplica a múltiples áreas de proceso. Describe las características que deben estar
presentes para institucionalizar los procesos que implementan un área de proceso.
Objetivos Específicos
Los objetivos específicos describen las características propias que deben estar
presentes para satisfacer el área de proceso. Es un componente requerido del modelo
y se utiliza en las evaluaciones para determinar si se satisface un área de proceso.
Práctica
Una práctica (tanto genérica como específica), es la descripción de una actividad que
se considera fundamental para lograr un objetivo. El hecho de estar establecida, ya
forma parte del modelo. Las prácticas se plasman en procesos.
36.4 GAP Análisis
Ejemplo para el Nivel 3
Cuando se realiza un análisis de Gap (brecha) entre la situación real de la organización

y lo que el Modelo en cada nivel de madurez requiere, surge entonces una brecha a
resolver para dar cumplimiento al mismo. En este gráfico se muestra –por ejemplo-
un análisis para el nivel 3 de una organización donde están las 11 áreas de proceso. La
parte azul es que la organización hoy cumple y el resto faltante en cada eje para llegar
el 100%, es la brecha.
84
CMMI® para Desarrollo, Versión 1.3. (2010). sei.cmu.edu. Consultado: Diciembre 2015, de
http://www.sei.cmu.edu/library/assets/whitepapers/Spanish%20Technical%20Report%20CMMI%20V%201%2
03.pdf
Ilustración 43 - Ejemplo GAP CMMI
Ilustración 44 - Acreditación CMMI
En el grafico anterior se muestran las etapas para llevar adelante una acreditación de
la evaluación de CMMI para cumplir con un nivel de madurez.
El modelo de CMMI, es un modelo muy estricto y rígido, que claramente se focaliza en

el cumplimiento de “Prácticas” que se plasman en procesos medibles.
El grado de complejidad de cada proceso implementado, está en la órbita de decisión

de cada organización.
37 Otros marcos complementarios
Los marcos y normas definidas en capítulos anteriores, son a nivel internacional en la

actualidad, las principales herramientas y principios para la concepción, el diseño, la
implementación y el monitoreo del gobierno de TI, conjuntamente con la gestión de
TI.
Desde ya, cada organización tomará de cada uno de ellos lo que considere útil, e
implementará las prácticas que colaboran concretamente con los objetivos de dicha
organización, considerando su contexto e historia.
Aquellas que además, decidan “certificar” internacionalmente una norma ISO o

“acreditar” un nivel de madurez de CMMi, deberán cumplir con dicho marco en forma
completa.
Sin embargo, no todas las decisiones son totalmente de la organización. Por ejemplo
existen en determinados rubros, algunas normas o leyes internacionales que deben
ser cumplidas para poder prestar servicios en el mercado.
Un ejemplo claro de estas circunstancias, son el mercado financiero, bancario, la

presentación de balances de todas las empresas, etc.
En estos casos, las mismas deben cumplir con estas normativas que aunque no sean
directamente de TI, tienen un impacto importante en “como” se diseñan los sistemas,
la infraestructura y los controles para poder sostener el cumplimiento de requisitos
de estas normas.
Por dicho motivo, en forma resumida, a continuación mencionamos algunas de ellas

para que sean consideradas como componentes necesarios en el gobierno de TI para
las organizaciones que estén alcanzadas por las mismas.
38 COSO
COSO - Committee of Sponsoring Organizations, of the Treadway Commission
Es una iniciativa conjunta de cinco organizaciones del sector privado internacional y se

enfoca a la elaboración de marcos para el control interno y el riesgo empresarial,
conjuntamente con la disuasión del fraude.
El control interno es un proceso impulsado por la dirección de una organización con el

objeto de proporcionar un grado de seguridad para el logro de objetivos en:
 Eficacia y eficiencia de las operaciones

 Confiabilidad de la información financiera
 Cumplimiento de las leyes, reglamentos y normas aplicables
De acuerdo a lo definido en el marco COSO, el control interno se estructura en cinco

componentes relacionados entre sí. Estos componentes serán los mismos para todas las
organizaciones y todos los niveles dentro de una organización.
Ilustración 45 - Mapa COSO
Los componentes definidos en el CUBO son:
 Ambiente de Control
 Evaluación de Riesgos
 Actividades de Control
 Información y Comunicación
 Supervisión y Monitoreo
La premisa del marco COSO, es que una buena gestión de riesgos y control interno es
necesaria para el logro de los objetivos de la organización a largo plazo y contribuye a
mejorar la gobernabilidad. COSO establece principios de trabajo.
Los 17 principios de COSO: 85
85
Gráfico The COSO Framework on Internal Control, por Deloitte Development LLC, 2013.
Ilustración 46 - Principios COSO
Este marco colabora con las necesidades de la dirección, estableciendo controles

integrados a las operaciones, lo cual genera una sinergia que contribuye a disminuir los
riesgos y acrecentar la efectividad y gobernabilidad organizacional.
39 Ley Sarbanes Oaxley
La Ley Sarbanes-Oxley 86 conocida también

como SOX, es la ley que regula las funciones
financieras contables y de auditoria y
FRENTE A LOS FRAUDES CONTABLES
penaliza en una forma severa, el crimen LEY SARBANES-OXLEY - Julio 2002

corporativo. La misma fue generada debido a
los múltiples fraudes, la corrupción
administrativa, los conflictos de interés, la
negligencia y la mala práctica de algunos
profesionales y ejecutivos en diversas
organizaciones.
La Ley establece una agencia privada, “The Public Company Accounting Oversight
Board" (PCAOB), que tiene la función reguladora de revisar, inspeccionar y sancionar
a las empresas de auditoría. La Ley se refiere también a la independencia necesaria de
las auditoras, el gobierno corporativo y la transparencia financiera.
Requerimientos que establece la PCAOB
 Eficacia del funcionamiento de los controles internos relacionados con la

generación de los balances financieros
 Comprensión de la criticidad de las transacciones autorizadas, procesadas y
contabilizadas
 Documentar suficientemente la información sobre el flujo de transacciones
para identificar posibles errores o fraudes
86
Inter American Community Affairs. (2002). U.S. Sarbanes-Oxley.
 Evaluar la credibilidad de los controles de la organización, de acuerdo con el

marco COSO 87 (Committee of Sponsoring Organizations of the Treadway
Commission), para identificar fraudes
 Evaluar los controles de la dirección para prevención de fraudes
 Evaluar el control del proceso de generación del informe financiero al final del
ejercicio y los asientos contables que lo sustentan
Dado que la implicancia de los sistemas informáticos es fundamental para poder

implementar estos controles, la PCAOB 88 ha publicado una directiva que trata sobre
los controles generales de TI que se relacionen con la ley SOX.
En términos generales, se establece cuales controles deben verificarse en al ámbito

de la tecnología de la información, dado que sobre el buen funcionamiento de esta
plataforma, se apoyan otros controles de contenido de la información y las
transacciones.
El cumplimiento de esta ley está íntimamente unido a un buen gobierno de la TI, por
lo cual hemos incluido este apartado en este trabajo.
Todos los marcos descriptos (fundamentalmente COBIT y COSO), son la base de

poder garantizar un buen gobierno de TI y el cumplimiento de esta norma
internacional.
87
Home. Coso.org. Consultado: Octubre 2015, de http://www.coso.org/
88
PCAOB: Protecting Investors through Audit Oversight. Pcaobus.org. Consultado: Diciembre 2015, de
http://www.pcaobus.org/
40 Basilea III
Los denominados “Acuerdos de Basilea” (I, II y III), se refieren a un conjunto de
reformas de la regulación bancaria. La última actualización se publicó en 2013.
Basilea III, forma parte de un conjunto de iniciativas, promovidas por el Foro de

Estabilidad Financiera 89 (FSB, Financial Stability Board) y el G-20, para fortalecer el
sistema financiero internacional tras diversas crisis.
Basilea III se centra principalmente en el riesgo de “pánico bancario”, exigiendo

diferentes niveles de capital para las distintas modalidades de depósitos bancarios y
otros préstamos. Basilea III se suma a las premisas de Basilea I y II.
Basilea III, contiene un conjunto de medidas para fortalecer la regulación, supervisión

y gestión de riesgos del sector bancario. Estas medidas buscan:
 Mejorar la capacidad del sector bancario para afrontar perturbaciones

ocasionadas por tensiones financieras o económicas
 Mejorar la gestión de riesgos y el buen gobierno en los bancos
 Reforzar la transparencia y la divulgación de información de los bancos
Dichas medidas se enfocan en la regulación de los bancos en particular (dimensión

micro-prudencial), para aumentar la capacidad de reacción de cada institución en
periodos de tensión y en los riesgos sistémicos (dimensión macro-prudencial) que
puedan acumularse en el sector bancario en su conjunto.
El Banco Central de la República Argentina, dispone de un conjunto de

recomendaciones y normativas para implementar Basilea III en las instituciones
bancarias del país. 90
Como se aprecia, la implementación de estos criterios y procesos, tienen un impacto

directo en los Sistemas de Información y por lo tanto en el Gobierno de TI.
89
Financial Stability Board. Financialstabilityboard.org. Consultado: Diciembre 2015, de
http://www.financialstabilityboard.org/
90
La hoja de ruta hacia Basilea III. (2015). BCRA. Consultado: Diciembre 2015, de
http://www.bcra.gov.ar/Pdfs/Politicas/Hoja_ruta_Basilea_III.pdf
41 BCRA – Comunicación 4609
La “Comunicación del Banco Central de la República Argentina 4609” 91, denominada:

“Requisitos mínimos de gestión, implementación y control de los riesgos relacionados
con tecnología informática y sistemas de información”, tiene vigencia desde 2006.
Esta norma es la base mínima que todos los bancos deben cumplir en relación al gobierno
interno de TI.
Define una larga lista de requisitos y recomendaciones para gestionar los riesgos relativos
a la plataforma, sistemas, operaciones y comunicaciones electrónicas.
Estable responsabilidades del área de sistemas:
El área será responsable de observar la existencia y correcta aplicación de los controles

considerados como práctica recomendada y de uso frecuente en la implementación de
la protección de los activos de información:
 La existencia de una política de protección de los activos de información,

redactada, formalizada, actualizada y comunicada a toda la entidad
 La asignación de responsabilidades operativas en materia de administración de la
protección de los activos de información
 La comunicación oportuna de incidentes relativos a la seguridad, a los
responsables propietarios de los datos
 La existencia de procedimientos de control y monitoreo, y su aplicación sobre el
empleo continuo de los estándares fijados de seguridad
 La instrucción y el entrenamiento en materia de seguridad de la información
Esta norma ha tenido influencias de tendencias internacionales en seguridad de la

información. Lineamientos que provienen del “Information Security Government” 92, la
ISO 27002, la ley SOX y las buenas prácticas difundidas por las certificaciones
internacionales de seguridad CISM y CISSP, se perciben en la 4609, que sin dudas es un
pilar para implementar en la institución bancaria, el Gobierno de TI.
La misma se ha enriquecido con la aplicación complementaria de otras normas que el

BCRA ha publicado, tales como:
BCRA 5388 y 5460 - Protección de los usuarios de servicios financieros.
BCRA 5374 - Requisitos mínimos de gestión, implementación y control de los riesgos

relacionados con tecnología informática, sistemas de información y recursos asociados
para las entidades financieras.
92
Information security — Government Service Design Manual. Gov.uk. Consultado: Febrero 2016, de
https://www.gov.uk/service-manual/making-software/information-security.html
42 PRINCE2
PRINCE2 - Proviene del acrónimo en inglés PRojects IN Controlled Environments es

decir, gestionar proyectos, que manejan una carga importante de variabilidad y de
incertidumbre, en entornos controlados. Más que un conjunto de buenas prácticas,
PRINCE2 93 propone una metodología de gestión de proyectos, que cubre mediante lo
que se conoce como “Temáticas”.
La metodología propone la justificación del proyecto por un Business Case que debe ser
revisado durante el ciclo de vida del proyecto y validar en todo momento el proyecto, en
relación a los beneficios esperados. Establece un modelo de procesos soportado en 4
niveles de gestión y define 5 roles en el gerenciamiento del proyecto.
Las 7 temáticas de PRINCE2:
1. Business case: Justifica el proyecto desde el inicio y en forma continua
2. Organization: Define cómo se organizan los equipos para hacer el proyecto
3. Quality: Define la calidad esperada de los productos resultantes
4. Plans: Establece un plan detallado y mecanismos de control del proyecto
5. Risk: Define esquemas de gestión del riesgo e incertidumbre
6. Change: Explicita mecanismos de gestión del cambio durante el proyecto
7. Progress: Establece una evaluación continua desde todos los puntos de vista
PRINCE2 es una metodología de gestión de proyectos tal como lo es el PMBOK, pero está
más orientada a la práctica de ejecución del proyecto y al aseguramiento de conseguir
los resultados esperados. En cambio el PMBOK tiene una orientación mayor a la
enseñanza y a explicitar el cuerpo de conocimientos que un Project Management debe
tener. Ambas forman parte de metodologías que componen un buen Gobierno y Gestión
de TI.
93
PRINCE2 Information & PRINCE2 Courses for Project Managers | USA. Prince2.com. Consultado: Enero 2016,
de http://www.prince2.com
43 Conclusiones y Recomendaciones
Según un estudio publicado en Harvard 94, que además se referencia en la documentación

oficial de ISACA-COBIT, el mismo demostró que sobre 250 empresas relevadas a nivel
mundial, se concluyó que aquellas empresas que tienen un gobierno de TI de gran calidad,
tenían, al menos, un 20% más de rentabilidad que aquellas con un gobierno pobre, dados
los mismos objetivos. Esta cifra implica que el valor para el negocio (de TI), aporta
directamente con un gobierno de TI eficaz.
Esta afirmación se ha seguido sosteniendo por diversos estudios hasta la actualidad, esto
significa que gobernar y gestionar la TI, es tan eficiente y conveniente para la
organización, tanto como gobernar y gestionar las finanzas, los recursos humanos y otras
áreas claves para el negocio, que son prioridad para sus máximos directivos.
El gobierno de la TI es un componente importante para el logro de la excelencia y

competitividad requerida por la organización. Dicho gobierno, no es responsabilidad
exclusiva de la unidad de tecnología, sino que involucra a toda la capa de dirección.
Tener un sistema de gobierno de TI, implica disponer de herramientas para la toma de

decisiones, con información objetiva y estar mejor preparado para afrontar los cambios
del negocio, del ecosistema, del mercado y poder entonces alinear rápidamente y
eficientemente las inversiones y los servicios para las nueva metas empresariales en este
entorno tan dinámico.
Las actividades propuestas por la norma ISO/IEC 38500 para el gobierno corporativo de
TI, que son: Evaluar – Dirigir – Monitorear, están reflejadas en la implementación de
COBIT5.
Esto nos lleva a concluir que las herramientas conceptuales y marcos metodológicos con
mejores prácticas, descriptos en este trabajo, hoy en día, “están disponibles y maduros”
para ser usados en todas las organizaciones.
Por lo tanto, podríamos preguntarnos la razón por la cual muchas organizaciones, o bien:
no utilizan marcos de gobierno de TI o si lo utilizan, es para cumplir con algunos requisitos
formales, ya sean internos o externos de la organización, pero no como una herramienta
para que los directivos conduzcan mejor el negocio.
94
Ross, Jeanne W.; Peter, Weill (2004). Gobierno de TI: Cómo los mejores gestionan los derechos de decisión
de TI para obtener resultados superiores. EEUU: Harvard Business School Press.
Dado lo estudiado y relevado para el desarrollo de este documento, como así también mi
experiencia personal y de colegas, entiendo y concluyo que los principales motivos,
tienen que ver con algunos de los siguientes aspectos:
Certificar una o diversas normas ISO
Esta es una situación a tener clara por parte de la dirección, muchas veces algunos
directivos priorizan disponer de una certificación de validez internacional, a disponer de
los procesos e indicadores, que serían necesarios para la gestión real. Esto implica que
no hay total “convicción” sobre la necesidad de un gobierno de TI por parte de los
directivos máximos, pero sí, existe la convicción sobre la necesidad de la certificación.
Cuando esta combinación se da, entonces el trabajo de implementación, está orientado
a cumplir con la norma, haciéndolo muchas veces muy complejo, pero no está puesto en
la necesidad de gobierno y gestión real, pues se considera que si no fuera por la
certificación, con lo que hoy dispone la organización, es suficiente.
Cumplimiento de normas internas de la organización
Esta situación es totalmente similar a la anterior. Se da fundamentalmente en grandes

empresas y holding Nacionales y Multinacionales. Existen tantos procesos y tantas
normativas, locales, regionales y de las casas matrices, que todo el esfuerzo está puesto
en cumplir con ellas, sacando el foco de la gobernabilidad y la gestión en sí mismas. Luego
con el tiempo, algunos sectores llegan a la errónea conclusión, que los procesos de
gobierno de TI, no aportan, pues con “todo lo que se hace”, igual sigue habiendo malas
decisiones y resultados de TI. Esta conclusión está obviando que, lo que se hace, es para
cumplir normas y no para tener un buen gobierno.
Implementar el gobierno de TI y su rendimiento, delegado a la gente de TI
En línea con los dos ítems anteriormente descriptos, al no existir dicha convicción por
parte de los directivos que no son de TI, se deja “exclusivamente” en manos de TI -y en
el mejor de los casos solo del CIO- la construcción y monitoreo del gobierno de TI, sin
llegar al núcleo que se busca, que es que los máximos responsables del negocio y la
organización, sean los actores involucrados en esta temática.
Alta burocracia en la implementación
Como complemento de lo expresado, muchas organizaciones pretenden pasar de “la

nada al todo” en un solo paso. De esta forma se generan pretensiosos servicios y procesos
que son engorrosos de utilizar en la operación diaria y generan una burocracia que
desanima su uso. En cualquiera de los casos, se pierde el objetivo de disponer de
herramientas agiles y eficientes para conducir y gobernar la TI y el negocio.
RECOMENDACIONES PROPUESTAS
Sería recomendable en primer lugar que los máximos directivos de la organización, luego
de un proceso interno de concientización, tomen la decisión sobre lo que se quiere
obtener:
1- Implementar procesos de Gobierno y Servicios de IT

2- Certificar algunas o varias de las normas ISO
3- Ambos objetivos conjuntos
Por lo tanto, la estrategia a llevar adelante, será distinta según cuál de las 3 opciones
se elija, dado que modifica el alcance del proyecto, el impacto de cambio organizacional
y el grado de cumplimiento de requisitos a cubrir.
Sin embargo un factor común y “muy importante a considerar para el éxito”, es tener en
cuenta la siguiente definición que hace COBIT5:
“ ISACA proporciona amplias prácticas y guías de implementación en

su publicación COBIT5, que está basada en un ciclo de vida de mejora
continua. No está pensada con un enfoque prescriptivo ni como una
solución completa, sino más bien como una guía para evitar los
obstáculos más comunes, aprovechar las mejores prácticas y ayudar
en la creación de resultados satisfactorios. El gobierno y la gestión de
la TI empresarial no suceden de manera aislada. Cada empresa
necesita diseñar su propio plan de implantación, atendiendo a los
factores específicos del entorno interno y externo de la empresa” 95
De esta forma, la recomendación es que no se intente implementar todo el framework

de una forma absoluta e indiscutible, sino que siguiendo las premisas de COBIT5, cada
organización debe poder priorizar y armar un plan para poner en marcha los
componentes prioritarios de los marcos descriptos en este documento, que sean “útiles
a los fines de la organización”, de manera tal de tener un plan incremental y darle el
tiempo necesario, para que la organización y las personas, vayan alcanzando los niveles
de madurez adecuados y dicha nueva forma de trabajo, sea parte de la cultura aceptada.
Otra recomendación complementaria, es que ningún marco de trabajo, ni cualquiera de

las normas ISO, dispone ni obliga, “cuan complejos o rígidos deben ser los procesos ni los
indicadores de monitoreo de los mismos”. Solo establecen, “qué” debe realizarse y
controlarse en determinados dominios de la organización.
95
Este último párrafo parece obvio, pero es uno de los mayores problemas y riesgos al
momento de implementar estos marcos o normas. Quienes tienen a cargo la definición
e implementación de los “nuevos procesos” (siempre terminan siendo el fin tangible de
un marco de trabajo), en muchos casos, cuando definen el gap del “estado actual” al
“estado deseado”, se proponen metas y niveles de complejidad demasiados ambiciosos
y rígidos, para dar en un solo salto y muchas de dichas complejidades no contribuyen a
los fines del negocio.
Tanto los marcos de trabajo como las normas ISO pueden implementarse, usando pocos
procesos (los que la organización defina) y de poca complejidad (que cumplan con las
salidas e indicadores básicos que la organización necesite para decidir y monitorear el
negocio).
Lo que se desea expresar es que en muchos casos, la complejidad y el fracaso de las

implementaciones, no son atribuibles a los marcos ni a los requisitos de las normas, sino
a una interpretación rígida, falta de practicidad y visión muy sectorial de quienes definen
la implementación, o sea, se pierde el “para que” se está haciendo, desde la visión del
negocio y el management.
COBIT5 propone para la implementación de las mejoras, un ciclo de vida de 7 fases.
En forma resumida, se describen las preguntas que deben ser respondidas en cada fase,
con el objetivo de clarificar las definiciones de la dirección.
Las mismas son:
Fase 1: ¿Cuáles son los motivos del cambio?
Fase 2: ¿Dónde estamos ahora?
Fase 3: ¿Dónde queremos ir?
Fase 4: ¿Qué es preciso hacer?
Fase 5: ¿Cómo conseguimos llegar?
Fase 6: ¿Hemos conseguido llegar?
Fase 7: ¿Cómo mantenemos vivo el impulso?
EL USO DEL CUADRO DE MANDO INTEGRAL COMO HERRAMIENTA DE EVALUACIÓN
COBIT5 define un conjunto de 17 metas corporativas relacionadas con la TI, o sea metas
empresariales genéricas y para ello utiliza las 4 dimensiones del cuadro de mando integral
(en inglés balanced scorecard) 96. Con esta temática también hace uso de una técnica
muy difundida y la incorpora como una buena práctica a su marco de referencia.
Estas 17 metas corporativas (esta lista no es exhaustiva según COBIT5), apuntalan en

forma genérica, los objetivos más comúnmente definidos por las organizaciones.
A continuación y a modo de recomendación, proponemos un formato de ejemplo para

implementar en la práctica esta herramienta de gestión para el Gobierno de TI.
GOBIERNO TI-TABLERO DE CUMPLIMIENTO DE METAS SEGÚN COBIT5
INDICADOR GLOBAL ORGANIZACIONAL DEL GOBIERNO DE TI
PERSTECTIVA MEDIDA RESULTADO PONDERACION EN EL TOTAL

PERSPECTIVA 1 69% 25%
PERFORMANCE DE LA ORGANIZACIÓN: 71%
En este cuadro resumen, se puede observar el porcentaje de cumplimiento de cada una

de las cuatro perspectivas del Cuadro de Mando Integral y dada la ponderación de cada
una en el total, el resultado final de “La organización” en esta temática.
Los valores específicos de cortes de dichos valores que cualitativamente pueden leerse
como Malo, Regular, Bueno o Muy bueno, deben ser definidos por cada organización y
se sugiere que estén inmersos en un proceso de “Mejora Continua” tal como lo define
para diversas temáticas la norma ISO 9001.
96
Kaplan, R.; Norton, D. (1996). The balanced scorecard. USA: Harvard University
A continuación desagregamos dicho cuadro de mando, por cada una de las perspectivas,
las cuales se componen de la cuantificación ponderada de Metas Parciales.97
PERSPECTIVA METAS EVALUADAS

Número Resultado Ponderación Resultado parcial Nombre de la Meta
30% 70% 1-Alineamiento de TI y la estrategia de negocio

2-Cumplimiento y soporte de la TI al cumplimiento
10% 60%
1- Financiera
del negocio de las leyes y regulaciones externas

3-Compromiso de la dirección ejecutiva para tomar
69%
20% 65%
decisiones relacionadas con TI
4-Riesgos de negocio, relacionados con las TI
20% 70%
gestionadas
5-Realización de beneficios del portafolio de
10% 70%
inversiones y servicios relacionados con las TI
6-Transparencia de los costos, beneficios y riesgos
10% 80%
de las TI
2- Cliente
7-Entrega de servicios de TI de acuerdo a los

60% 70%
70%
requisitos del negocio
8-Uso adecuado de aplicaciones, información y

40% 70%
soluciones tecnológicas
15% 80% 9-Agilidad de las TI

10-Seguridad de la información, infraestructura de
3- Interna-Procesos
20% 75%
procesamiento y aplicaciones
11-Optimización de activos, recursos y
10% 70%
capacidades de las TI
71%
12-Capacitación de procesos de negocio

15% 80%
integrando aplicaciones y tecnología
13-Entrega de programas que proporcionan
10% 75%
beneficios a tiempo, a costo y calidad
14-Disponibilidad de información útil y relevante
20% 55%
para la toma de decisiones
15-Cumplimiento de las políticas internas por parte
10% 60%
de las TI
Aprendizaje
16-Personal del negocio y de las TI competente y

55% 80%
78%
motivado
4-
17-Conocimiento, experiencias e iniciativas para la

45% 75%
innovación de negocio
Ilustración 47 - Cuadro de Mando Integral de TI
97
Este cuadro es de elaboración propia y está basado en lo definido en COBIT5 para metas empresariales y con
el formato de las 4 dimensiones del cuadro de mando integral ya citado de Kaplan-Norton
METRICAS MEDIDAS SOBRE EVIDENCIAS

Para obtener el resultado parcial porcentual de cumplimiento de cada una de las 17 Metas definidas, cada
organización debe establecer las métricas con las cuales llegará a dicho resultado. Una meta puede
responder al resultado de una sola métrica o bien, ser el resultado de "varias" métricas que se ponderan
entre sí para llegar a un solo resultado, tal como luego se hace entre las 17 metas y el resultado final de
cada Perspectiva. Es fundamental que cada métrica se mida en forma objetiva con "Evidencias" que las
respalden, para lo cual debe haber procesos estandarizados y medibles en su comportamiento en la
organización.
Es importante considerar la obtención de métricas tal como se ha definido, con el fin de

obtener indicadores reales que reflejen el comportamiento de la organización en cada
proceso.
PRIORIZAR LOS PROCESOS A REDISEÑAR E IMPLEMENTAR
COBIT5, en su documentación oficial, ofrece un conjunto de anexos entre los cuales

(producto de experiencias acumuladas), hay matrices que cruzan las metas del negocio
con las metas de TI y establecen el grado de relación y aporte entre ellas. Luego existen
otras en la cual se cruzan las metas de TI con todos los procesos establecidos por COBIT5
y se define también el grado de relación y aporte entre cada cruce.
Por lo tanto, si se lleva adelante una metodología de priorización para armar un plan
factible e incremental, aquí hay método posible para ello. Una gran ventaja es que si se
realiza un taller de trabajo con los máximos directivos, las preguntas “No son sobre los
procesos”, puesto que no tendrían tanto detalle operativo para poder contestar
adecuadamente, sino que las preguntas son sobre “cuales metas de negocio y de TI”
necesitan estratégicamente priorizar (ver detalles de las metas en el capítulo COBIT en
este documento).
Con esas respuestas, e implementando un algoritmo de ponderación manual o con

alguna herramienta, puesto que ya se tienen las matrices y cruces antes mencionados
con su importancia, el resultado serán el “nombre de los procesos” que se deben priorizar
en la implementación del marco de trabajo, estando seguros que son los que soportan
las metas definidas por los ejecutivos.
Priorización de los 32 procesos de Gestión corporativa de TI
Este sería un simple ejemplo del resultado del método mencionado. Partiendo de la
priorización de metas por parte de los responsables del negocio, se llega a la priorización
de procesos de TI a implementar en el marco definido.
Ilustración 48 - Priorización de procesos
Una vez que se dispone de un subconjunto de procesos que han sido catalogados como
prioritarios para las “metas del negocio”, se debe entonces trabajar en la evolución de la
madurez de comportamiento de los mismos. En este aspecto es donde debe aplicarse
con el criterio que la organización defina, el modelo de madurez de procesos ya definido
en este documento tanto para la norma ISO 15504 como su utilización por COBIT5.
Este gráfico que fue analizado en el capítulo mencionado, es la base de la estrategia de

evolución en la madurez de los procesos, comenzando desde ya por los ya establecidos
como críticos para el negocio pues su mejora tendrá un impacto más rápidamente visible
y cuantificable para la organización.
De las conclusiones explicitadas en este capítulo y las recomendaciones realizadas

sobre la base de priorizar y madurar los procesos con la metodología que propone
COBIT5, son totalmente exportables y reutilizables para “cualquiera de todos los
marcos definidos” en este trabajo y desde ya la combinación adecuada de ellos, que
cada organización establezca como útil para implementar su Gobierno y Gestión de TI.
LA ELECCIÓN ADECUADA DE LOS MARCOS A IMPLEMENTAR
En este trabajo se han definido diversos marcos que en forma complementaria pueden
formar el “Set de herramientas” para la óptima gestión de TI y el Gobierno corporativo
de TI en una organización en particular.
En este capítulo de recomendaciones, se ha explicitado lo sugerido particularmente por

ISACA en cuanto a que la guía de COBIT5 “No está pensada con un enfoque prescriptivo ni
como una solución completa, sino más bien como una guía para evitar los obstáculos más
comunes, aprovechar las mejores prácticas”. Por lo tanto, cada organización “No puede
escapar” a la tarea de realizar un minucioso análisis de sus necesidades y las herramientas
que en forma total o parcial, deben ser utilizadas para la gestión.
La sugerencia de este trabajo es tomar como base la ISO 38500 y COBIT5 (en forma
parcial o total) y desde ahí construir el mapa global de los marcos, normas o prácticas
que utilizará la organización para disponer de un sistema integrado de gestión de
Gobierno de TI.
Con este mapa conceptual de ISACA ya descripto en detalle, hemos analizado los diversos
marcos y normas que en forma complementaria pueden brindar una solución. Pero
además hemos agregado otros que se consideran de utilidad para que la organización
tenga mayor amplitud a la hora de elegir. También hemos analizado las diferentes
normas ISO y en un análisis propio, las relaciones que se consideran influyentes entre las
normas y los marcos internacionales.
Este esquema que fue analizado en al capítulo de ISO, nos da una visión global de las
relaciones mencionadas, lo cual debe servir como base para implementar las
recomendaciones realizadas en este capítulo.
POSTULADO DE ESTE TRABAJO
Muchas organizaciones deben abordar las decisiones sobre el Gobierno y Gestión de TI,
como una prioridad estratégica a nivel del máximo órgano de decisión. Si dicha premisa
no se da, será entonces una labor indelegable, que los profesionales que estamos
consustanciados con este modelo de funcionamiento, hagamos la docencia necesaria
hasta que logremos el nivel de “madurez dirigencial”, para que se incorpore esta visión.
Este trabajo se basó en materiales oficiales de los marcos y normas descriptas,

relevamiento de experiencias del mercado con especialistas en implementarlas, diversas
fuentes académicas y de organismos internacionales consultadas y en la experiencia
profesional personal y materiales propios elaborados a lo largo de la maestría. El objetivo
de este trabajo fue describir conceptualmente los diferentes marcos, conjuntamente con
las normas ISO asociadas, pero fundamentalmente, concluir y recomendar, desde mi
visión, algunos lineamientos prácticos para decidir las elecciones y que sean exitosas. Las
conclusiones y opiniones vertidas son de mi exclusiva responsabilidad y tienen carácter de
material original.
Esp. Lic. Daniel Piorun
44 Bibliografía
 CMMI – Capability maturity model integration, for Development, Versión 1.3,

Noviembre 2010.
 COBIT5 – ISACA – Control Objectives for Information and related Technology.
 Collazo Javier, Saroka Raul (2010). Informática en las organizaciones. Buenos Aires:
Fondo Editorial Consejo Profesional de Ciencias Económicas de la CABA.
 Cordella, Antonio (2007). E-government. Toward the e-bureaucratic form. Journal of
Intormation Techonology.
 COSO – The Committee of Sponsoring Organizations of the Treadway Commission.
 Deming Edwards (1989). Calidad, Productividad y Competitividad. Madrid: Ediciones

Díaz de Santos.
 El Open Group Architecture Framework (TOGAF)

 ISO – International Organization for Standardization.
 IT Governance Institute.
 ITIL – Information Technology Infrastructure Library.
 Kaplan, Robert; Norton David (2000). Mapas Estratégicos. USA: Harvard Business
School.
 Mayoral, Luisa (2001). Metodología del Trabajo de Tesis. Tandil: Editorial CEAE.
 Minoli, Dan (2008). Enterprise Architecture A to Z: Frameworks, Business Process

Modeling, SOA, and Infrastructure Technology. USA: Taylor & Francis Group.
 Mintzberg, Henry (1999). Safari a la estrategia. Argentina: Editorial Granica.
 Norma ISO 21500 – Guidance on Project Management.
 Norma ISO 31000 – Gestión del riesgo.
 Norma ISO 9001 – Sistema de Gestión de la Calidad.
 Norma ISO/IEC 15504 – Capacidad de Mejora del Proceso de Software.
 Norma ISO/IEC 20000 – Gestión de servicios de IT.
 Norma ISO/IEC 27000 – Gestión de la seguridad.
 Norma ISO/IEC 38500 – Gobierno de IT.
 Office of Government Commerce (OGC-UK).
 Ministerio de Industria, Presidencia de la Nación Argentina. Cadena de valor del

Software y servicios informáticos. Plan estratégico 2020.
 PRINCE2 - PRojects IN Controlled Environments.
 Guía de Fundamentos de la Dirección de Proyectos (PMBOK Quinta Edición). Project

Management Institute (P.M.I.).
 Ross, Jeanne W.; Weill, Peter (2004). Gobierno de TI: Cómo los mejores gestionan los
derechos de decisión de TI para obtener resultados superiores. USA: Harvard Business
School Press.
 The IT Service Management Forum (ITSMF UK).

Tesis Gobernabilidad

Cargado por

Copyright:

Formatos disponibles

Tesis Gobernabilidad

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tesis Gobernabilidad

Cargado por

Copyright:

Formatos disponibles

MAESTRÍA EN GESTIÓN

Normas y Marcos relacionados con la

Director de la Maestría: Dr. Raúl Saroka

Director del Trabajo: Mg. Gustavo Díaz

Autor: Esp. Lic. Daniel Piorun

Buenos Aires – 2016

“Por medio de la presente, el autor manifiesta conocer y aceptar el Reglamento de

Juan Daniel Piorun

 Autor de este trabajo final de la Maestría

 Especialista en Gestión estratégica de sistemas y Tecnologías de la Información

 Profesor adjunto regular y asociado interino en la carrera de sistemas FCE-UBA

 Director de proyectos de tecnología de la información en organismos públicos y

Trabajo Final de Maestría GESTI Página 2 Autor: Lic. Daniel Piorun

2 Director del Trabajo Final de Maestría

Prof. Mg. Gustavo Díaz

 Magister MBA en la Facultad de Ciencias Económicas – UBA

 Profesor de la Maestría en Gestión Estratégica de Sistemas y Tecnologías de la

 Profesor de la Maestría en Seguridad informática – FCE - UBA

 Gerente Titular de Sistemas de Información en Banco de la Provincia de Buenos Aires

 Profesor Adjunto Regular en grado en la materia “Metodología de Análisis y Diseño

 Licenciado en Informática – UADE

Mg. Gustavo Díaz

Trabajo Final de Maestría GESTI Página 3 Autor: Lic. Daniel Piorun

2 Director del Trabajo Final de Maestría ................................................................. 3

3 Contenido Global ................................................................................................. 4

4 Tabla de ilustraciones .......................................................................................... 6

5 Título del Trabajo y Resumen .............................................................................. 8

6 Dedicatoria y Agradecimientos ............................................................................ 8

8 Resumen Ejecutivo ............................................................................................ 11

10 Planteo del Problema ........................................................................................ 13

12 Justificación y Relevancia de este Trabajo ........................................................ 15

13 Metodología de elaboración del Trabajo y Alcance ........................................... 16

14 Marco Teórico .................................................................................................... 17

15 Planeamiento estratégico organizacional .......................................................... 18

16 El Gobierno de la tecnología de la información ................................................. 21

17 Desarrollo de Sistemas de Información ............................................................. 34

18 Gestión de Proyectos de TI ............................................................................... 40

19 Gestión de Procesos ......................................................................................... 44

20 Infraestructura y Arquitectura Tecnológica ........................................................ 47

21 Integración de los marcos existentes con las normas ISO ................................ 50

22 La norma ISO 38500 – Gobierno de TI.............................................................. 51

23 La norma ISO 20000 – Gestión de Servicios ..................................................... 53

24 La norma ISO 9001- Gestión de la Calidad ....................................................... 57

25 La norma ISO 90003 – Aplicación al Software .................................................. 60

Trabajo Final de Maestría GESTI Página 4 Autor: Lic. Daniel Piorun

26 La norma ISO 27001- Gestión de Seguridad de la Información ........................ 65

27 La norma ISO 31000 - Gestión del Riesgo ........................................................ 68

28 La Norma ISO 21500 – Guidance on Project Management ............................... 69

29 La norma ISO 15504 - Madurez del Proceso de Software ................................ 70

30 Marcos existentes para el gobierno y gestión de TI........................................... 75

33 TOGAF ............................................................................................................ 110

34 ZACHMAN ....................................................................................................... 134

35 PMI .................................................................................................................. 140

36 CMMI ............................................................................................................... 153

37 Otros marcos complementarios ....................................................................... 162

38 COSO .............................................................................................................. 163

39 Ley Sarbanes Oaxley ...................................................................................... 166

40 Basilea III ......................................................................................................... 168

41 BCRA – Comunicación 4609 ........................................................................... 169