SALA - Analisis Comparativo Entre COBIT 5 y TOGAF 9.1 para Su Aplicacion de Forma Integrada

Escuela Técnica Superior de Ingeniería Informática
Universitat Politècnica de València
Análisis comparativo entre COBIT 5 y TOGAF 9.1

para su aplicación de forma integrada
Trabajo Final de Grado

Grado en Ingeniería Informática
Autor: Sala Pérez, Rubén

Tutora: Cuenca González, Llanos
Curso 2016-2017
Análisis comparativo entre COBIT 5 y TOGAF 9.1 para su aplicación de forma integrada
2
Agradecimientos
A las dos únicas personas que tienen más mérito que yo en este trabajo, mi padre y mi madre.
Por todo el apoyo que me han dado en todos los sentidos y por hacer siempre lo mejor para mí.
Gracias Mamá. Gràcies Papa.
A mi novia por aguantar la carga de este trabajo conmigo y creer siempre en mí.
A María y a Dani por soportar mi compañía y sudar junto a mí este TFG.
A Pedro Martínez por enseñarme que nunca hay que rendirse.
A Llanos por orientarme en este trabajo cuando más perdido estaba.
3
4
Resumen
Este Trabajo de Fin de Grado (TFG) pretende comparar los estándares COBIT 5 (ISACA) y TOGAF
9.1 (Open Group), describiendo, a su vez, cómo pueden trabajar de manera conjunta.
Además, se mostrarán las formas de actuar que nos ofrecen los dos estándares a analizar. A
partir de ello, se estudiarán semejanzas, discrepancias y actuaciones que pueden ser
complementarias entre ellas.
El trabajo se desarrollará siguiendo las etapas por las que pasa una empresa que implanta un
marco para el Gobierno de las TI y la definición de la Arquitectura Empresarial. Para ello, se
presentará un caso de estudio con el que se seguirá la evolución de una corporación.
Con el caso de estudio veremos cómo estas herramientas nos proveen de pasos, procesos y
buenas prácticas para dirigir la corporación mediante la buena gestión de las TI.
Palabras clave: COBIT 5, TOGAF 9.1, Gobierno de las TI, Arquitectura Empresarial.
Resum
Aquest Treball Fi de Grau pretén comparar els estàndards COBIT5 (ISACA) i TOGAF 9.1 (Open
Group), descrivint, a la vegada, com poden treballar de manera conjunta.
A més, es mostrarà les maneres d'actuar que ens ofereixen ambdós estàndards. A partir d'açò,
s'estudiaran semblances, discrepàncies i actuacions que poden ser complementàries.
El treball es desenvoluparà seguint les etapes per les quals passa una empresa que implanta un
marc per al Govern de les TI i la definició de l'Arquitectura Empresarial. Per açò, es presentarà
un cas d'estudi amb el qual es seguirà l'evolució d'una corporació.
Amb el cas d'estudi vorem com aquestes ferramentes ens proveeixen de passos, processos i
bones pràctiques per a dirigir la corporació mitjançant la bona gestió de les TI.
Paraules clau: COBIT 5, TOGAF 9.1, Govern de les TI, Arquitectura Empresarial.
5
Abstract
This Final Project aims to compare the standards of COBIT 5 (ISACA) and TOGAF 9.1 (Open
Group), describing, at the same time, how can they work together.
Besides, will be shown ways of acting that both standards to analyze offer. From it, will be
studied similarities, discrepancies and acts that can be complementary between them.
The project will be developed following the stages by which a company that implants a
framework of IT Governance and define the Enterprise Architecture. For that, will be presented
a study case with which the evolution of the corporation will be followed.
With the study case, we will observe how these tools provide us of steps, processes and good
practices to lead the corporation by means of good manage of the IT.
Keywords: COBIT 5, TOGAF 9.1, IT Governance, Enterprise Architecture
6
Tabla de contenidos
1. Introducción ........................................................................................................................ 13
1.1. Motivación .................................................................................................................. 13
1.2. Objetivo ....................................................................................................................... 13
1.3. Estructura de la memoria ............................................................................................ 13
2. COBIT 5 ................................................................................................................................ 16
2.1. Introducción ................................................................................................................ 16
2.2. Principio 1: Satisfacer las Necesidades de las Partes Interesadas .............................. 17
2.3. Principio 2: Cubrir la Organización de Forma Integral (extremo-a-extremo) ............. 17
2.4. Principio 3: Aplicar un Marco de referencia único Integrado ..................................... 18
2.5. Principio 4: Hacer Posible un Enfoque Holístico ......................................................... 19
2.5.1. Catalizadores COBIT 5 ......................................................................................... 19
2.5.2. Gobierno y Gestión Sistémicos Mediante Catalizadores Interconectados ......... 20
2.5.3. Dimensiones de los Catalizadores de COBIT 5 .................................................... 20
2.6. Principio 5: Separar el Gobierno de la Gestión ........................................................... 22
3. TOGAF 9.1 ............................................................................................................................ 28
3.1. Introducción ................................................................................................................ 28
3.2. FASE PRELIMINAR........................................................................................................ 29
3.3. FASE A: Visión Arquitectónica ..................................................................................... 31
3.4. FASE B .......................................................................................................................... 33
3.5. FASE C: Arquitectura del Sistema de Información ...................................................... 35
3.6. Fase D: Arquitectura Tecnológica................................................................................ 36
3.7. Fase E: Oportunidades y Soluciones ........................................................................... 37
3.8. Fase F: Planear Migración ........................................................................................... 39
3.9. Fase G: Implementación del Gobierno........................................................................ 39
3.10. Fase H: Gestión del cambio de la arquitectura ........................................................... 41
4. Análisis comparativo............................................................................................................ 44
5. La empresa seleccionada ..................................................................................................... 47
6. Sector del mantenimiento y la restauración ....................................................................... 49
7. Caso de estudio ................................................................................................................... 51
7.1. Situación ...................................................................................................................... 51
7.2. Necesidad .................................................................................................................... 52
7
7.3. Expectativas................................................................................................................. 53
8. Aplicación de COBIT 5 y TOGAF 9.1 al caso de estudio ....................................................... 55
8.1. Selección y justificación............................................................................................... 55
8.2. Metodología COBIT 5 .................................................................................................. 55
8.2.1. Principio 1: Satisfacer las necesidades de las partes interesadas ....................... 55
8.2.2. Principio 2: Cubrir la organización de forma integral.......................................... 59
8.2.3. Principio 3: Aplicar un marco de referencia único integrado ............................. 60
8.2.4. Principio 4: Hacer posible un enfoque holístico.................................................. 60
8.2.4.1. Principios, políticas y marcos de referencia .................................................... 60
8.2.4.2. Procesos .......................................................................................................... 61
8.2.4.3. Estructuras Organizativas ................................................................................ 61
8.2.4.4. Cultura, ética y comportamiento .................................................................... 62
8.2.4.5. Información ..................................................................................................... 63
8.2.4.6. Servicios, Infraestructuras y Aplicaciones ....................................................... 64
8.2.4.7. Persona, Habilidades y Competencias ............................................................ 64
8.2.5. Principio 5: Separar El Gobierno de la Gestión ................................................... 65
8.2.5.1. EDM ................................................................................................................. 66
8.2.5.2. APO .................................................................................................................. 66
8.2.5.3. BAI ................................................................................................................... 70
8.2.5.4. DSS................................................................................................................... 71
8.2.5.5. MEA ................................................................................................................. 72
8.3. Aplicación de TOGAF 9.1 ............................................................................................. 73
8.3.1. Fase Preliminar .................................................................................................... 73
8.3.2. Fase A: Visión Arquitectónica .............................................................................. 73
8.3.3. Fase B: Arquitectura de Negocio ......................................................................... 74
8.3.4. Fase C: Arquitectura del Sistema de Información ............................................... 75
8.3.5. Fase D: Arquitectura Tecnológica........................................................................ 76
8.3.6. Fase E: Oportunidades y soluciones .................................................................... 77
8.3.7. Fase F: Planear la Migración................................................................................ 78
8.3.8. Fase H: Gestión del cambio de la arquitectura ................................................... 78
9. Valoración económica ......................................................................................................... 80
9.1. DIAGRAMA DE GANTT ................................................................................................. 80
9.2. PRESUPUESTO ............................................................................................................. 81
10. Conclusiones .................................................................................................................... 84
8
10.1. Consideraciones finales ............................................................................................... 84
10.2. Posibles mejoras.......................................................................................................... 84
11. Bibliografía ....................................................................................................................... 87
11. Anexo ............................................................................................................................... 92
9
10
Tabla de ilustraciones
Ilustración 1. Principios de COBIT5 ............................................................................................. 16
Ilustración 2. Cascada de Metas de COBIT 5 ............................................................................... 17
Ilustración 3. Gobierno y Gestión en COBIT 5 ............................................................................. 18
Ilustración 4. Roles, actividades y relaciones .............................................................................. 18
Ilustración 5. Catalizadores Corporativos COBIT 5 ...................................................................... 19
Ilustración 6. Catalizadores genéricos COBIT 5 ........................................................................... 20
Ilustración 7. Áreas clave de Gobierno y Gestión de COBIT 5 ..................................................... 22
Ilustración 8. ADM de TOGAF 9.1 ................................................................................................ 28
Ilustración 9. Marco de gestión para coordinar TOGAF .............................................................. 30
Ilustración 10. Escenario de Negocio .......................................................................................... 32
Ilustración 11. Esquema del repositorio de arquitectura ........................................................... 34
Ilustración 12. Línea base del rendimiento inmediato................................................................ 53
Ilustración 13. Línea base del tiempo de respuesta.................................................................... 53
Ilustración 14. Actores de TapBeverage...................................................................................... 74
Ilustración 15. Funciones de los actores ..................................................................................... 75
Ilustración 16. Aplicaciones TapBeverage ................................................................................... 76
Ilustración 17. Tecnologías de la información............................................................................. 77
Ilustración 18. Transacciones de la migración ............................................................................ 78
Ilustración 19. Diagrama de Gantt .............................................................................................. 80
Ilustración 20. Informe costos de las tareas ............................................................................... 82
11
12
1. Introducción
1.1. Motivación
Resulta evidente que las tecnologías han irrumpido con mucha fuerza en nuestra vida cotidiana
hasta tal punto que nos resultan imprescindible para muchas tareas de nuestro día a día. El
mismo efecto han tenido en el desempeño de las tareas de las empresas de todos los sectores.
Las Tecnologías de la Información (TI) tienen una importancia vital en el éxito de cualquier
organización con o sin ánimo de lucro y de cualquier sector. Han alcanzado tal magnitud en su
papel dentro de las empresas que resulta difícil gestionarlas sin tener un marco de referencia.
Cada día más, las empresas se dan cuenta de la importancia de alinear las TI con el negocio y de
que ambos factores trabajen juntos para conseguir los objetivos de la organización. Los marcos
de referencia cobran sentido cuando las empresas se conciencian de que sin una buena gestión
de los recursos tecnológicos su éxito en el ámbito del negocio es casi imposible. Gracias a la
toma de conciencia del mundo empresarial en este sentido, las organizaciones optan por
implementar marcos de referencia para la gestión de las TI, pero también para la Arquitectura
Empresarial, la seguridad de las TI, la calidad de sus procesos, y para muchos más aspectos de
los negocios.
Todo esto da sentido al desarrollo de un trabajo en el que se muestra cómo una empresa
implementa dos marcos de referencia con el fin de asegurar su éxito empresarial.
1.2. Objetivo
El objetivo del proyecto es analizar los marcos de referencia COBIT 5 y TOGAF 9.1 y su aplicación
conjunta. Para ello se mostrará la forma de proceder de cada marco, se compararán y se aplicará
de manera conjunta mediante un caso de estudio. Este caso de estudio tratará de una empresa
que desea aplicar un gran cambio en su Sistema de la Información. Para asegurar el éxito del
proyecto y de su gestión una vez terminado, la empresa decide implantar estos dos marcos.
1.3. Estructura de la memoria
El trabajo está compuesto fundamentalmente por dos partes, la parte teórica y la práctica. En la
primera se explica cada uno de los marcos y en la segunda se aplican los marcos de forma
integrada en un caso de estudio.
1. Introducción
Es el capítulo en el que nos encontramos, en él se definen motivación, objetivo y estructura de
la memoria.
2. COBIT 5
Se explicará la teoría relativa a COBIT 5 con la que se va a respaldar el trabajo práctico.
13
3. TOGAF 9.1
Se verá cómo funciona el ciclo ADM de TOGAF y se explicará este marco de trabajo.
4. Análisis comparativo
Se compararán ambos marcos de trabajo, mencionando las semejanzas, discrepancias y sobre
todo el punto en el que se encuentran y a partir del cual pueden ser aplicados de forma conjunta.
5. La empresa seleccionada
Se mencionan las raíces y las características de la empresa protagonista del caso de estudio en
el cual se aplican los marcos de referencia a estudiar.
6. Sector del mantenimiento y la restauración
Se analiza el panorama de los dos sectores a los que está ligada la empresa del caso de estudio.
7. Caso de estudio
Se declara el caso de estudio que ocupa este trabajo, analizando la situación de la empresa y sus
necesidades.
8. Aplicación de COBIT 5 y TOGAF 9.1 al caso de estudio
Esta es la parte práctica, donde veremos cómo se aplica TOGAF 9.1 y COBIT 5 en un caso como
el presentado en el capítulo anterior.
9. Valoración económica
Se calcula y explica el costo económico y en esfuerzo necesario para llevar a cabo el proyecto
del caso de estudio.
10. Conclusiones
Se valora de forma global el resultado final del trabajo, mostrando las posibles mejoras que
pueden aplicarse en él y dando pie a que el trabajo sea usado en otros proyectos.
14
15
2. COBIT 5
2.1. Introducción
El objetivo de COBIT 5 es proporcionar un marco integral para ayudar a las organizaciones a

generar valor y lograr sus metas mediante la gestión y gobierno efectivos de las TI de la
organización.
Los beneficios2 de usar COBIT 5 son:

 Mantener información de calidad para apoyar las decisiones del negocio.
 Generar un valor comercial de las inversiones habilitadas por la Tecnología de la
Información (TI), o sea: lograr metas estratégicas y mejoras al negocio mediante el uso
eficaz e innovador de la TI.
 Lograr una excelencia operativa mediante la aplicación eficiente y fiable de la
tecnología.
 Mantener el riesgo relacionado con TI a niveles aceptables.
 Optimizar el costo de la tecnología y los servicios de TI.
COBIT 5 está estructurado en cinco principios:
Ilustración 1. Principios de COBIT5
16
2.2. Principio 1: Satisfacer las Necesidades de las Partes Interesadas
Las organizaciones tienen una gran cantidad de

partes interesadas y COBIT debe asegurar la
creación de valor para todas ellas. Al haber
tantas partes interesadas el hecho de generar
valor puede significar cosas muy diferentes entre
unas partes y otras, incluso podríamos encontrar
organizaciones en las que esto pueda significar
cosas opuestas.
El Gobierno es el encargado de negociar y decidir
los intereses que deben ser potenciados para el
beneficio de las partes interesadas. Para que esto
sea posible el Gobierno debe de tener en cuenta
todas las partes interesadas en todas sus
decisiones referentes a la evaluación de riesgos,
beneficios y manejo de recursos.
Las necesidades de las partes interesadas deben
transformarse en metas específicas, accionables
y personalizadas para cada organización. Las
metas pueden ser de la organización,
relacionadas con la TI o metas habilitantes o
catalizadoras Estas metas serán definidas
mediante la Cascada de Metas de COBIT 5.
Además, COBIT 5 proporciona una lista de las
metas corporativas mapeadas con su Ilustración
Cascada
2. Cascada
de metas
de Metas
de COBIT
de 5COBIT 5
importancia para los objetivos de Gobierno
[Anexo 1].
Gracias a las metas en Cascada podemos definir las prioridades para implementar, mejorar y
asegurar el gobierno corporativo de la TI, basándonos en los objetivos de la organización.
2.3. Principio 2: Cubrir la Organización de Forma Integral (extremo-a-

extremo)
COBIT 5 tiene una perspectiva global de la Organización, y se centra en la gestión y el gobierno

de la misma, separando estas dos responsabilidades.
Que COBIT 5 tenga una visión global de la Organización se traduce en el alineamiento de la TI
con el gobierno corporativo, es decir, el gobierno de la TI se encuentra integrado en el gobierno
corporativo. Para conseguir esta visión global COBIT 5 no solo se encarga de tratar con el
funcionamiento de la TI, sino que ve a la TI como un activo más de la organización, algo que
debe trabajar en la misma dirección y con los mismos objetivos que el resto de la Organización.
Por eso los catalizadores son para toda la empresa.
17
Ilustración 3. Gobierno y Gestión en COBIT 5
En la figura se observan los componentes del sistema de Gobierno extremo-a-extremo que

propone COBIT 5:
Los catalizadores de Gobierno son recursos organizativos mediante los cuales se dirigen las
acciones y se alcanzan los objetivos. Estos recursos pueden ser marcos de referencias, procesos,
prácticas, etc. Los catalizadores serán vistos con más detalles más adelante dada su importancia.
Pese a que el alcance de Gobierno “natural” de COBIT 5 es toda la Organización, este puede ser
aplicado a un departamento o a un activo en concreto.
Los roles, actividades y relaciones de gobierno. Definen quién está involucrado en el gobierno,
como se involucran, lo que hacen y cómo interactúan, dentro del alcance de cualquier sistema
de gobierno.
Ilustración 4. Roles, actividades y relaciones
2.4. Principio 3: Aplicar un Marco de referencia único Integrado
ISACA proporciona un marco que gestione la TI y el gobierno además de ser integrador, por eso
COBIT 5 está alineado con otros marcos relacionados con el Gobierno corporativo (COSO, ISO
31000, etc.) y del gobierno de la TI (TOGAF, PRINCE2, etc.).
Además, ISACA respalda COBIT 5 con otras publicaciones y guías, así consigue que a la
organización le sea mucho más sencillo gestionar e implantar COBIT 5.
18
2.5. Principio 4: Hacer Posible un Enfoque Holístico
2.5.1. Catalizadores COBIT 5
Lo catalizadores o habilitadores son las herramientas que usan las organizaciones para gobernar
y gestionar sus procesos. Los catalizadores aceleran, mejoran, regulan y controlan los procesos
para conseguir las metas y los resultados esperados de una manera eficaz.
Los catalizadores se dividen en siete categorías, según la descripción literal de COBIT 5 las siete
categorías son las siguientes:
1. “Principios, políticas y marcos de referencia son el vehículo para traducir el comportamiento
deseado en guías prácticas para la gestión del día a día.”2
2. “Los procesos describen un conjunto organizado de prácticas y actividades para alcanzar
ciertos objetivos y producir un conjunto de resultados que soporten las metas generales
relacionadas con TI.” 2
3. “Las estructuras organizativas son las entidades de toma de decisiones clave en una
organización.” 2
4. “La Cultura, ética y comportamiento de los individuos y de la empresa son muy a menudo
subestimados como factor de éxito en las actividades de gobierno y gestión.” 2
5. “La información impregna toda la organización e incluye toda la información producida y
utilizada por la empresa. La información es necesaria para mantener la organización
funcionando y bien gobernada, pero a nivel operativo, la información es muy a menudo el
producto clave de la empresa en sí misma.” 2
6. “Los servicios, infraestructuras y aplicaciones incluyen la infraestructura, tecnología y
aplicaciones que proporcionan a la empresa, servicios y tecnologías de procesamiento de la
información.” 2
7. “Las personas, habilidades y competencias están relacionadas con las personas y son
necesarias para poder completar de manera satisfactoria todas las actividades y para la correcta
toma de decisiones y de acciones correctivas.” 2
Ilustración 5. Catalizadores Corporativos COBIT 5
19
2.5.2. Gobierno y Gestión Sistémicos Mediante Catalizadores Interconectados
Las empresas deberían tener estructurado un conjunto de catalizadores interconectados. Cada

catalizador necesita los outputs de otros catalizadores como inputs, es decir, un proceso
catalizador necesitará información y una estructura organizativa necesita las competencias y
habilidades de las personas y estas necesitan una cultura a seguir. En definitiva, cada catalizador
necesita del resultado de otros catalizadores y estos generarán las entradas para uno o varios
catalizadores diferentes.
La empresa deberá asegurar que los catalizadores definidos son relevantes y necesarios para el
fin para el que se han definido. Si la elección de los catalizadores es correcta estarán todos
interconectados, por ejemplo, si queremos tener una alta disponibilidad de un servicio
necesitaremos, evidentemente, unas aplicaciones e infraestructuras, pero de nada servirá si nos
falla la competencia de las personas del equipo de trabajo o si la información no está disponible.
2.5.3. Dimensiones de los Catalizadores de COBIT 5
COBIT 5 proporciona un conjunto de dimensiones que son comunes para las siete categorías de
catalizadores, esto permite facilitar el manejo de interacciones complejas en las organizaciones,
que los catalizadores sean utilizados de manera exitosa y, además, nos ayuda a gestionar de una
manera más sencilla y estructurada los catalizadores.
Ilustración 6. Catalizadores genéricos COBIT 5
Los grupos de interés de un catalizador son todo aquello que forma parte o tiene algún interés
en el catalizador en cuestión. Por ejemplo, en un proceso forma parte de los grupos de interés
internos un trabajador que tiene un rol en dicho proceso, o puede formar parte de los grupos
de interés externos una empresa subcontratada para conseguir alcanzar las metas de dicho
proceso.
20
Las metas son el objetivo de todo catalizador, un habilitador puede tener varias metas y el éxito
y valor generado por dicho habilitador se mide mediante las metas conseguidas. Los
catalizadores pueden ser medidos en diferentes aspectos:
- Calidad intrínseca: Medida en que los catalizadores trabajan de manera precisa,
objetiva y proporcionan resultados precisos, objetivos y de confianza.
- Calidad contextual: La calidad del resultado que genera el catalizador, valorando si
han servido con éxito para el propósito que han sido creados.
- Accesibilidad y seguridad: Los catalizadores están disponibles en el momento que
se les requiere y además se asegura que esto solo pueden hacerlo aquellas personas
que estén autorizadas.
El ciclo de vida son las fases que debe pasar todo catalizador. Estas fases pueden ser diferentes
según el catalizador, es posible que un catalizador esté diseñado para alcanzar una meta o
generar un resultado y entonces su final será la eliminación del mismo catalizador, por ejemplo,
un proceso cuya meta sea recopilar información de un servidor; o puede ser que un catalizador
perdure tanto tiempo como la organización y su fase final en el ciclo de vida sea su actualización,
por ejemplo, un empleado de la empresa.
Las fases del ciclo de vida de los catalizadores son:
– Planificar (incluye el desarrollo y selección de conceptos)
– Diseñar
– Construir / adquirir / crear / implementar
– Utilizar / operar
– Evaluar / monitorizar
– Actualizar / eliminar
Las buenas prácticas son las lecciones aprendidas durante todo el ciclo de vida de cada
catalizador. Esto nos proporcionará ejemplos y sugerencias para aplicar en un futuro en otros
catalizadores, esto nos ahorrará errores, tiempo y esfuerzo.
Para mantener una buena gestión de los catalizadores y asegurar que el rendimiento de estos
es el correcto y esperado, es necesario evaluar el rendimiento de los mismos, para ello COBIT 5
nos proporciona cuatro preguntas que debemos hacernos sobre cada catalizador de manera
periódica. Estas preguntas contemplan el resultado que está ofreciendo el catalizador y su
funcionamiento actual. Las cuatro preguntas son las siguientes:
1- ¿Se consideran las necesidades de las partes interesadas?
2- ¿Se alcanzan los objetivos de los catalizadores?
3- ¿Se gestiona el ciclo de vida?
4- ¿Se aplican las buenas prácticas?
21
2.6. Principio 5: Separar el Gobierno de la Gestión
COBIT 5 define Gobierno y gestión de maneras totalmente diferentes e independientes. Cada

una desempeña actividades diferentes, tienen fines distintos y requieren estructuras
organizativas diferentes.
El Gobierno suele estar bajo la responsabilidad del consejo de administración dirigido por el
presidente del mismo. El objetivo y la labor del Gobierno es asegurar que las condiciones,
necesidades y opciones que se han acordado con las partes interesadas están siendo evaluadas
con el objetivo de conseguir las metas corporativas determinadas. La junta debe desarrollar las
tareas de dirección tomando decisiones y estableciendo prioridades. Además, debe medir el
cumplimiento de las metas acordadas y de la dirección, así como el rendimiento de las mismas.
La Gestión suele estar bajo la responsabilidad de la dirección ejecutiva, cuyo máximo
mandatario es el CEO. COBIT 5 define la función de la gestión de la siguiente manera: “La gestión
planifica, construye, ejecuta y controla actividades alineadas con la dirección establecida por el
cuerpo de gobierno para alcanzar las metas empresariales.”2 Es decir, la Gestión es quien se
encarga de la ejecución de los planes que el Gobierno ha determinado y esto incluye desde el
nacimiento del plan (planificando y construyendo), pasando por la ejecución del mismo y
controlando que las actividades sigan el camino que el Gobierno ha descrito.
COBIT 5 presenta un modelo para implementar los procesos de gobierno y de gestión. COBIT 5
no obliga a usar el modelo de implementación de procesos, pero si propone que las
organizaciones tengan cubiertas las áreas fundamentales de gobierno y gestión. En la figura se
muestra el modelo de implementación de procesos que propone COBIT 5.
Ilustración 7. Áreas clave de Gobierno y Gestión de COBIT 5

COBIT 5, aparte de permitir una libre configuración en la manera de organizar los procesos, deja
a la elección de la organización la cantidad de procesos que quiere implementar. Habrá
empresas más pequeñas que no tengan suficientes recursos para implementar un gran número
de procesos, otras simplemente no lo consideren necesario y otras tendrán otros marcos de
referencia que gestionen ciertos procesos que propone COBIT 5. El número de procesos no
importa, lo importante y obligatorio es lograr cubrir las metas de gobierno y gestión.
Además de aportar una propuesta de organización de los procesos, COBIT 5 otorga a las
organizaciones varios procesos de gobierno y de gestión descritos al detalle. Los procesos que
presenta son los que se deben encontrar en empresas relacionada con actividades de TI. Este
22
modelo de procesos es integral, es decir, cubre todas las necesidades de las empresas más
complejas, pero cada empresa debe valorar su caso en particular y configurar su propio modelo.
El modelo de referencia de procesos de COBIT 5 se divide en procesos de gobierno y procesos
de gestión:
Gobierno: Como se ha descrito en la Ilustración 7, el gobierno debe evaluar, orientar y
supervisar, para ello COBIT 5 define cinco procesos:1 3
EDM01. Asegurar el establecimiento y mantenimiento del marco de referencia de gobierno:
Analiza los requisitos para el gobierno de las TI, activa y mantiene efectivos los catalizadores y
clarifica las responsabilidades y autoridades para conseguir los objetivos que ha propuesto la
organización.
EDM02. Asegurar la entrega de beneficios: Optimiza el valor generado por las TI y minimiza los
costes de la inversión en TI.
EDM03. Asegurar la optimización del riesgo: Asegura que los riesgos y la tolerancia a ellos de la
organización es gestionada.
EDM04. Asegurar la optimización de recursos: Asegura que la organización dispone de
suficientes recursos de TI y con suficiente capacidad para lograr las metas y objetivos propuestos
por la organización.
EDM05. Asegurar la transparencia hacia las partes interesadas: Asegura la elaboración de
informes para las partes interesadas y se asegura de acordar las medidas a tomar con todas las
partes interesadas.
Gestión: COBIT 5 define cuatro dominios para la gestión de las TI: Planificar (APO), Construir
(BAI), Ejecutar (DSS) y Supervisar (MEA). El nombre lo adquieren por las principales actividades
que cubren, pero están compuestos por más actividades. Los cuatro dominios son:
- APO: Alinear, Planificar y Organizar
- BAI: Construir, Adquirir e Implementar
- DSS: Entregar, dar Servicio y Soporte
- MEA: Supervisar, Evaluar y Valorar
23
Cada uno de estos dominios tiene los siguientes procesos:1 4 5 6 7

APO: Alinear, Planificar y Organizar
El objetivo principal del primer dominio de la Gestión es cubrir las necesidades estratégicas de
la TI en la organización de tal manera que la TI ayude a conseguir los objetivos estratégicos de
la organización. Para ello se han definido los siguientes procesos.
APO01. Gestionar el marco de gestión de las TI: Mantener el gobierno de la misión y la visión
de la organización, así como mantener los mecanismos necesarios para gestionar las TI de
acuerdo con la política y principios de la organización.
APO02. Gestionar la estrategia: Proporcionar una fotografía del momento actual del negocio y
futuro que se espera respecto a las TI.
APO03. Gestionar la arquitectura empresarial: Establecer una arquitectura común para los
procesos de negocio y todo lo relacionado con la información y las TI, con el objetivo de
conseguir las metas marcadas para las TI y para la empresa, mediante la descripción de la línea
de partida y la final. Mejorar el flujo de información potenciando la mejora de las herramientas
utilizadas, la agilidad del manejo de la información y mejorando la calidad de la misma.
APO04. Gestionar la innovación: Mantener la organización informada de las nuevas tecnologías
y servicios de TI, aprovechando la oportunidad de incluir en la organización nuevas soluciones
que permitan mejorar el rendimiento de las TI.
APO05. Gestionar el portafolio: Ejecutar el conjunto de direcciones estratégicas para la
inversión.
APO06 Gestionar el presupuesto y los costes: Gestionar el apartado económico relativo a las TI
como presupuestos y costes. Consultar con las partes interesadas los movimientos de las
actividades económicas, acordando, en caso de ser necesario, correcciones en las decisiones.
APO07 Gestionar los Recursos Humanos: Estructurar los recursos humanos de la organización.
Hay que tener en cuenta la gestión de las responsabilidades de los trabajadores, su formación
necesaria para el desempeño de su trabajo y conseguir que cada trabajador mantenga al nivel
más alto su competencia y su motivación.
AP008 Gestionar las relaciones: Mantener una estrecha relación y una buena comunicación
entre el negocio y las TI de una manera formal para conseguir que ambos se apoyen
mutuamente para lograr las metas de la organización basándose en una mejor toma de
decisiones.
AP009 Gestionar los acuerdos de servicio: Alinear los servicios que presta la TI con las
necesidades y expectativas de la empresa, acordando cual será el nivel de servicio prestado y
asegurar que esto se cumple.
APO10 Gestionar los Proveedores: Gestionar los servicios que prestan proveedores externos a
la organización con el objetivo de satisfacer las necesidades que no se cubren desde dentro de
la empresa.
APO11 Gestionar la calidad: Definir los requisitos mínimos de la calidad de los procesos.
APO12 Gestionar el riesgo: Identificar, evaluar y reducir los riesgos relacionados con la TI y
asegurar que estos se encuentran dentro de los niveles de tolerancia aceptables para la
organización.
APO13 Gestionar la seguridad: Definir, operar y supervisar un sistema para la gestión de la
seguridad de la información.
24
BAI: Construir, Adquirir e Implementar
Este dominio se encarga de llevar a cabo la estrategia definida por el dominio APO. Se definen
procesos para llevar a cabo las principales tareas de este dominio: construir, planificar i
organizar.
BAI01 Gestión de programas y proyectos: Gestionar los programas y proyectos del portafolio
con el objetivo de alinearlos con la estrategia corporativa.
BAI02 Gestionar la definición de requisitos: Valorar las posibles soluciones y requerimientos
para una posible adquisición de las mismas. Asegurar que las soluciones se alineen con la
estrategia de la organización y cubren las necesidades del negocio. Acordar con las partes
interesadas la configuración y las decisiones de las soluciones y requerimientos a adquirir.
BAI03 Gestionar la identificación y construcción de soluciones: Asegurar que las soluciones
adoptadas se mantienen alineadas con los requisitos de la organización.
BAI04 Gestionar la disponibilidad y la capacidad: Mantener el equilibrio entre disponibilidad,
costes y capacidades de las TI y el coste que estas requieren. Para ello hay que evaluar las
capacidades actuales y prever las necesidades futuras.
BAI05 Gestionar la facilitación del cambio organizativo: Reducir al máximo la probabilidad de
cosechar fracasos durante el cambio organizativo y durante todo el ciclo de vida.
BAI06 Gestionar los cambios: Conseguir implantar los cambios de una manera controlada. Esto
se conseguirá mediante generación y seguimiento de documentación, implantación de normas,
análisis de impacto, automatización del cambio y la utilización de cualquier herramienta capaz
de ayudar a la organización a conseguir un control sobre el cambio.
BAI07 Gestionar la aceptación del cambio y la transición: Aceptar formalmente y construir
nuevas soluciones operativas, incluyendo la planificación de la implementación, la conversión
de sistemas y datos, las pruebas de aceptación, la comunicación, la preparación de la liberación,
la promoción a la producción de procesos de negocio nuevos o cambiados y los servicios de TI.
BAI08 Gestionar el conocimiento: Asegurar que el conocimiento relevante para las actividades
de la organización se encuentra disponible, actualizado, validado y fiable.
BAI09 Gestionar los activos: Asegurar que los activos aportan valor con un coste óptimo a la
empresa mediante el ciclo de vida. Mantener los activos seguros y actualizados.
BAI10 Gestionar la configuración: Definir relaciones entre los recursos de la empresa y las
capacidades necesarias para desempeñar correctamente las actividades relacionadas con las TI.
DSS: Entregar, dar Servicio y Soporte

Este dominio define procedimientos para poner a disposición de los usuarios las nuevas
soluciones.
DSS01 Gestionar operaciones: Gestionar la entrega de servicios de TI, externos e internos,
mediante las actividades y procedimientos necesarios.
DSS02 Gestionar peticiones e incidentes de servicio: Dar respuesta y soporte a las incidencias y
peticiones que reporten los usuarios.
DSS03 Gestionar problemas: Clasificar e identificar problemas pasados y posibles problemas
futuros, así como identificar las causas y proporcionar soluciones para atajarlo y evitar que se
vuelvan a producir.
25
DSS04 Gestionar la continuidad: Mantener la disponibilidad de la información y los servicios y

diseñar un plan de contingencia para responder a interrupciones de los servicios.
DSS05 Gestionar servicios de seguridad: Diseñar un sistema que permita proteger la
información de la empresa para alcanzar un nivel de riesgo aceptable según la política y
requerimiento de la empresa.
DSS06 Gestionar controles de procesos de negocio: Implementar y mantener controles para
asegurar que la información relativa a la organización se procesa de forma adecuada y satisface
todas las necesidades de la empresa.
MEA: Supervisar, Evaluar y Valorar

Este dominio se encarga de que todos los procesos de TI estén disponibles en el momento
oportuno para garantizar la calidad de las soluciones y del plan estratégico de TI en la
organización. Para ello este dominio provee de procesos para supervisar, evaluar y valorar y así
asegurar el objetivo del mismo.
MEA01. Supervisar, evaluar y valorar el rendimiento y la conformidad: Recolectar, de forma
sistemática y continuada, estadísticas y métricas de los procesos de negocio y de las TI para
evaluar el rendimiento de los procesos respecto al rendimiento esperado y su conformidad con
los objetivos diseñados por la organización.
MEA02. Supervisar, evaluar y valorar el sistema de control interno: Crear mecanismos para
supervisar y evaluar el sistema de control interno. Crear actividades y normas para agilizar un
control sistemático. Identificar y comunicar acciones de mejora y problemas potenciales.
MEA03. Supervisar, evaluar y valorar la conformidad con los requerimientos externos:
Asegurar que se cumplen los requerimientos regulatorios y contractuales mediante la
evaluación continua de los procesos de negocio y de TI.
26
27
3. TOGAF 9.1
3.1. Introducción
TOGAF 9.1 es un marco de trabajo de arquitectura empresarial. TOGAF tiene dos definiciones
de arquitectura:
“Una descripción formal de un sistema, o un plan detallado del sistema a nivel de sus
componentes que guía su implementación.”13
“La estructura de componentes, sus interrelaciones, y los principios y guías que gobiernan su
diseño y evolución a lo largo del tiempo.” 13
TOGAF se basa en el método ADM (Architecture Development Method) para desarrollar una
arquitectura empresarial que responda a las necesidades del negocio.
El método ADM apoya el concepto de iteración en tres niveles diferentes:
1. ADM con estructura circular: El ADM tiene forma circular para representar que cada fase
de trabajo alimenta directamente a fases posteriores.
2. Iteración entre fases: El seguimiento del ADM permite iterar a través de las fases,
volviendo a fases que no son vecinas.
3. Bucle en una fase: TOGAF permite ejecutar repetidas veces las actividades de una misma
fase para elaborar contenido arquitectónico.
Ilustración 8. ADM de TOGAF 9.1
28
Beneficios TOGAF 9:
• Alineamiento del negocio con la TI
• Reducción de costes
• Agilidad
• Innovación
• Cumplimiento de las leyes reguladoras
• Documentación y normalización de los procesos de negocio
• Consolidación de la infraestructura de TI
• Flexibilidad y adaptación
3.2. FASE PRELIMINAR
En esta fase se describe la preparación y el inicio de las actividades necesarias para satisfacer las
necesidades de la directiva con una nueva arquitectura empresarial. Se definen los apartados
de la organización que se verán afectados, se construirá el equipo para la arquitectura
empresarial y se describirán los principios de la arquitectura. Además, la organización deberá
adaptar una arquitectura específica para su caso en concreto.
Los objetivos de esta fase serán:
- Determinar la capacidad de la arquitectura a lo deseado por la organización, para ello
se deberá estudiar el contexto de la organización, determinar los elementos de la
organización que se verán afectados, identificar los marcos, métodos y procesos
relativos a la capacidad de la arquitectura y determinar el objetivo para la madurez de
la capacidad.
- Definir la capacidad de la arquitectura. Deberemos definir el modelo organizacional,
detallar los procesos y recursos para la arquitectura del gobierno, elegir las
herramientas que darán soporte a la capacidad de la arquitectura y definir los principios
de la arquitectura.
El enfoque de esta fase se debe centrar en dónde, qué, por qué, quién y cómo vamos a crear la
arquitectura. Para ello deberemos tener en cuenta los siguientes siete puntos:
• Definir la empresa. Identificar los stakeholders que van a proporcionar mayor beneficio
a la arquitectura empresarial, se debe designar un sponsor (responsable) para asegurar
que los stakeholders están incluidos en la arquitectura de trabajo.
• Identificación de factores claves y elementos en el contexto organizacional. Los
factores claves son aquellos elementos que generan valor a la organización
(stakeholders, habilidades de los trabajadores, cultura de la organización, etc.).
• Definir los requisitos para la arquitectura de trabajo.
• Definir los principios de la arquitectura. Los principios de la arquitectura son
herramientas que ayudan a seguir el camino para conseguir los objetivos marcados,
deberán ser basados en los principios de la organización. Los principios de la
organización proporcionan una base para la toma de decisiones y los principios de la
arquitectura reflejan los principios de la empresa y el nivel de consenso con ella.
• Definir el marco de trabajo usado.
29
• Definir la relación entre la gestión de marcos.

• Evaluar la madurez de la arquitectura empresarial.
TOGAF debe coexistir con otros marcos de gestión que la organización tiene implementados y
mejorar sus capacidades. Los marcos de trabajo que se propone coordinar con TOGAF son:
Gestores de capacidad de negocio (Dirección y planificación de negocio) determinan que
capacidades de negocios son necesarias para que el negocio incremente su valor, además,
incluyen la definición del retorno de la inversión y de las medidas de control.
Portfolio/Gestores de proyectos que ayudan a gestionar las iniciativas de cambio mediante
proyectos.
Los gestores de operaciones describen el trabajo en el día a día de una organización, a nivel de
negocio y de TI.
Los métodos para el desarrollo de soluciones formalizan la manera en la que los sistemas de
negocio son entregados de acuerdo con las estructuras creadas en la arquitectura de las TI.
Ilustración 9. Marco de gestión para coordinar TOGAF
Los inputs para la fase preliminar serán los marcos de trabajo de arquitectura si son requeridos,
el propio TOGAF y modelos de capacidad de arquitectura empresarial con los que la organización
operaba previamente, con ellos se construirá una línea base desde la que empezar a trabajar.
Además, se usarán otros inputs no relacionados con la arquitectura, como, por ejemplo:
estrategias y planes de negocio definidos por la junta, marcos de gobernanza o contratos
acordados con los partners.
Pasos:
• Determinar las partes de organización que van a ser afectadas
• Confirmar los marcos de gobierno y de soporte que se van a utilizar
• Configurar el equipo de trabajo
• Establecer los principios de la arquitectura.
• Adaptar TOGAF al contexto y necesidades de la empresa
• Implementar las herramientas de la arquitectura
30
La fase preliminar debería tener, como mínimo, los siguientes outputs:
• Modelo organizacional de la arquitectura empresarial.
• Marco de trabajo de la arquitectura adaptado a las necesidades y contexto de la
organización.
• Repositorio de la arquitectura inicial, esto permite gestionar los entregables de los
proyectos, identificar los activos reutilizables e informar a los stakeholders de los
resultados.
• Reafirmación de los principios, objetivos y motivaciones del negocio.
• Marco de referencia de gobierno.
Además, deberá incluir un catálogo de principios.
3.3. FASE A: Visión Arquitectónica
En la fase inicial del ADM se define el alcance del proyecto, las limitaciones, se identifican los
stakeholders, se crea la visión arquitectónica y se obtiene la aprobación de todo ello.
La fase inicial del ADM de TOGAF tiene dos objetivos:
1. Desarrollar una visión de alto nivel de las capacidades y el valor de negocio que se
desean obtener.
2. Obtener la aprobación, por parte de la alta dirección, de la definición de la arquitectura
de trabajo que define el programa de trabajo.
Enfoque:
La visión arquitectónica provee al sponsor una herramienta clave para promocionar los
beneficios de la capacidad propuesta a los stakeholders y a los responsables de la toma de
decisiones dentro de la organización. La VA describe como la nueva capacidad cumplirá los
objetivos estratégicos y los objetivos marcados para el negocio y trata los asuntos y
preocupaciones de los stakeholders a la hora de su implementación. Se proporciona una
descripción de alto nivel describiendo la línea base y los objetivos de la arquitectura, así como
la cobertura del negocio, la información y las TI.
31
El Escenario de Negocio una técnica útil y apropiada para descubrir los requerimientos del
negocio y documentarlos, con ello conseguiremos una buena herramienta para responder a las
necesidades de la VA.
Ilustración 10. Escenario de Negocio

1. Problema: Identificar, documentar y clasificar el problema de manejar el escenario.
2. Entorno: Identificar el entorno de la empresa y el técnico del escenario y documentarlo.
3. Objetivos: Identificar y documentar los objetivos deseados.
4. Actores Humanos: Identificar los actores (participantes) humanos y ubicarlos en el
modelo de negocio.
5. Actores Informáticos: Identificar los elementos informáticos y ubicarlos en el modelo
tecnológico.
6. Roles y responsabilidades: Identificar y documentar los roles y las responsabilidades.
7. Ajustar: Revisar si encaja para nuestro propósito y ajustarlo si es necesario.
Inputs:
Petición de Trabajo de Arquitectura: se trata de un documento que es enviado desde el sponsor
a la organización de la arquitectura para iniciar el ciclo de desarrollo de la arquitectura. Este
documento también puede ser creado como un output de la Fase A.
Principios, objetivos y motivaciones del negocio: proporcionan el contexto para la arquitectura
de trabajo describiendo las necesidades y la forma de desplegar el trabajo de la empresa.
Modelo Organizacional de la AE: es la definición de la organización, los roles y las
responsabilidades dentro de la organización. Sus contenidos son: Alcance de los organismos
afectados, evaluación de la madurez, responsabilidades de los equipos, limitaciones del trabajo
de la arquitectura, presupuesto necesario, gobernanza y estrategia de apoyo.
Adaptación del marco de referencia de arquitectura: incluye la adaptación del método de
arquitectura, contenido de arquitectura, principios de la arquitectura y herramientas
implementadas.
Repositorio de arquitectura: el global de la documentación que existe de la arquitectura.
32
Pasos:
• Establecer el proyecto de arquitectura
• Identificar los stakeholders, sus preocupaciones y los requerimientos de negocio
• Confirmar y elaborar objetivos, motivaciones de negocio y limitaciones
• Evaluar las capacidades del negocio
• Evaluar la preparación para la transformación del negocio
• Definir el alcance
• Confirmar y elaborar Principios de Arquitectura, incluyendo Principios de Negocio
• Desarrollar la Visión Arquitectónica
• Definir las propuestas de valor de la arquitectura que se quiere conseguir y el KPI
• Identificar los riesgos de la transformación de negocio y las actividades que ayuden a
mitigarlas
• Desarrollar la declaración de trabajo de la arquitectura y asegurar que se aprueba
3.4. FASE B
Esta fase se centra en describir una arquitectura base y una arquitectura objetivo que será la
que la empresa pretenda alcanzar. La arquitectura objetivo estará en consonancia con la visión
de la arquitectura, satisfaciendo las necesidades de la arquitectura y las preocupaciones de los
stakeholders.
Objetivos:
- Desarrollar la arquitectura objetivo, describiendo el modo en el que la empresa necesita
trabajar para alcanzar los objetivos de negocio y se encuentre en consonancia con la
visión arquitectónica.
- Identificar los posibles pasos a seguir (Hoja de Ruta Candidata) para alcanzar la
arquitectura objetivo. La Hoja de Ruta será creada a partir de la brecha que hay entre la
arquitectura base y la objetivo.
Para el desarrollo de la descripción de la línea base la empresa deberá incluir la descripción de

la arquitectura existente, en caso de que la haya. Lo importante es reutilizar al máximo el
material del que ya dispone la empresa, y recoger y analizar solo aquella información que nos
permita tomar decisiones fundamentadas para crear la arquitectura objetivo. Es importante no
entrar en detalles innecesarios.
El modelado de negocio debe ser extensiones lógicas de los escenarios de la VA, así que
debemos mapear la arquitectura desde el nivel más alto al más bajo, es decir, cada vez
denotando más detalles. Hay varias técnicas de modelado que podemos usar, podemos usar los
Modelos de Actividad para describir las funciones de cada actividad, Modelo de casos de uso
para describir cualquier proceso de negocio o las funciones del sistema y también podemos usar
los Modelos de clase para describir la información estática y las relaciones entre la información.
El soporte al Enterprise Continuum es el concepto de un repositorio de arquitectura, esto sirve
para almacenar lo que se ha generado como salida en el ADM. Los principales componentes del
repositorio son:
- El metamodelo de la arquitectura describe las aplicaciones organizacionales ajustadas
al marco de referencia de la arquitectura.
33
- La capacidad de la arquitectura define los parámetros, estructuras y procesos que

apoyan a la gobernanza del repositorio de la arquitectura.
- El Mapa Arquitectónico (Architecture Landscape) muestra cuales son los elementos de
construcción de la arquitectura que están activos en el momento actual.
- Base de estándares de información (SIB): recopila las necesidades de los estándares
que se deben cumplir.
- Bibliografía de referencias: guías, plantillas, patrones y cualquier tipo de material que
puede ayudar a agilizar la creación de la nueva arquitectura.
- Registro de gobierno: registra la actividad del gobierno para con la empresa.
Ilustración 11. Esquema del repositorio de arquitectura
Pasos:
• Seleccionar modelos de referencia, puntos de vista y herramientas: escoger los recursos
más importantes de la arquitectura de negocio, cómo, por ejemplo: plantillas modelos
de referencia, patrones, etc.
• Desarrollar una línea base que describa la arquitectura empresarial.
• Describir la arquitectura de negocio objetivo.
• Analizar la brecha entre la línea base y la arquitectura objetivo.
• Definir posibles elementos para la Hoja de Ruta para alcanzar la arquitectura objetivo
desde la línea base.
• Resolver los impactos a través del Mapa Arquitectónico: encontrar elementos afectados
y resolverlo. Por ejemplo, impacto sobre otros proyectos.
• Revisión formal de los stakeholders: Revisar si la arquitectura propuesta se ajusta a las
motivaciones que iniciaron el proyecto.
• Finalizar la arquitectura de negocio: seleccionar estándares, cumplimentar la
documentación de cada bloque, finalizar los productos de trabajo.
• Crear el documento que defina la arquitectura.
34
3.5. FASE C: Arquitectura del Sistema de Información
Describe el desarrollo de arquitecturas de sistemas de información para un proyecto de

arquitectura, incluyendo arquitecturas de datos y de aplicaciones.
Objetivo:
- Desarrollar una arquitectura de SI objetivo, describir como la arquitectura del SI de
negocio habilita a la arquitectura de negocio, de modo que dirige las peticiones de la
arquitectura de trabajo y las preocupaciones de los stakeholders.
arquitectura de SI objetivo. La Hoja de Ruta será creada a partir de la brecha que hay
entre la arquitectura base y la objetivo.
La Fase C es una combinación entre el desarrollo de la Arquitectura de Datos y la Arquitectura

de Aplicaciones, por lo que tiene estos dos mismos objetivos para cada una de las Arquitecturas
(Arquitecutra de SI, Arquitectura de Datos y Arquitectura de Aplicaciones)
Enfoque de la arquitectura de datos

Consideraciones clave para la Arquitectura de Datos:
Gestión de datos:
• Se debe definir claramente que aplicaciones servirán para el sistema de registro o
de referencia para los datos de la empresa.
• Concretar que estándares serán incluidos.
• Reconocer como son utilizadas las entidades de datos en procesos, servicios y
funciones de negocio.
• Entender cómo y dónde se crean, almacenan, transportan e informan las entidades
de datos empresariales.
• Saber cómo va a ser de complejo la adaptación de las entidades de datos para
soportar el cambio entre aplicaciones.
• Saber los requisitos para integrar los nuevos datos en el software de los clientes y
proveedores.
Migración de datos:
Cuando reemplazamos una aplicación por otra, se crea la necesidad crítica de migrar los datos
a la nueva aplicación. Mediante la arquitectura de datos se debe identificar los cambios
necesarios que hay que realizar en los datos para que cumpla los requisitos para poder introducir
en la nueva aplicación datos compatibles y de calidad.
La gobernanza de datos tiene como objetivo asegurar que se tiene el espacio suficiente para
llevar a cabo la transformación, para conseguirlo se deben tener en cuenta las tres dimensiones
siguientes:
• Estructura: asegura que la estructura de la organización tiene la capacidad necesaria y
los estándares para gestionar la transformación son correctos.
35
• Gestión del sistema: son necesarios sistemas de gestión y programas para la gestión de
datos de gobierno adecuados para gestionar las entidades de datos a lo largo de su ciclo
de vida.
• Personas: las empresas deben tener personal capacitado para manejar los datos
durante la transformación. Si la empresa no dispone de estas aptitudes en su plantilla
deberá contratar nuevo personal que se pueda hacer cargo, formar a su plantilla o
buscar alguien externo que esté capacitado.
Objetivos:
- Elegir los marcos de referencia, los puntos de vista y las herramientas
- Desarrollar la descripción de la Arquitectura base de Datos y Aplicaciones
- Desarrollar la descripción de la Arquitectura objetivo de Datos y Aplicaciones
- Analizar la brecha entre ambas Arquitecturas (base y objetivo)
- Definir posibles componentes de la Hoja de Ruta
- Resolver los impactos a través del Mapa Arquitectónico
- Llevar a cabo una revisión de los stakeholders
- Finalizar la Arquitectura de Datos y de Aplicaciones
- Crear el Documento de Definición de la Arquitectura
Tanto la Arquitectura de Datos como la Arquitectura de Aplicaciones se basan en la Arquitectura

Repositorio.
3.6. Fase D: Arquitectura Tecnológica
En esta fase se describe como desarrollar la Arquitectura Tecnológica para un proyecto de

arquitectura.
Objetivos:
- Desarrollar una Arquitectura Tecnológica Objetivo que habilite las aplicaciones y datos
lógicos y físico y, también habilite, la VA, atendiendo las peticiones de la Arquitectura
de Trabajo y las preocupaciones de los stakeholders.
Arquitectura Tecnológica de información objetivo. La Hoja de Ruta será creada a partir
de la brecha que hay entre la arquitectura base y la objetivo.
36
Pasos:
• Elegir los marcos de referencia, los puntos de vista y las herramientas
• Desarrollar la descripción de la Arquitectura Tecnológica base
• Desarrollar la descripción de la Arquitectura Tecnológica objetivo
• Analizar la brecha entre ambas Arquitecturas (base y objetivo)
• Definir una Hoja de Ruta
• Resolver los impactos a través del Mapa Arquitectónico
• Llevar a cabo una revisión de los stakeholders
• Finalizar la Arquitectura Tecnológica
• Crear el Documento de Definición de la Arquitectura
3.7. Fase E: Oportunidades y Soluciones
Esta fase se centra en cómo se va a entregar la arquitectura, creando una Hoja de Ruta. La fase
E tiene en cuenta las Hojas de Ruta de las fases B, C y D y todos los análisis efectuados de la
brecha que hay entre las arquitecturas base y las objetivo. Agrupa los cambios que se deben
realizar en paquetes de trabajo dentro del portfolio de la empresa. Esta labor tiene como
objetivo elaborar una Hoja de Ruta que se ajuste más a las necesidades de los stakeholders, la
capacidad que tiene la empresa para transformar su negocio, las oportunidades y las soluciones
identificadas, así como a las restricciones de implementación. La clave es concentrar los
esfuerzos en el objetivo final mientras se incrementa el valor del negocio.
Objetivos:
- Generar una versión inicial y completa de la Hoja de Ruta, basada en los análisis de la
brecha entre las Arquitecturas base y objetivo y en las Hojas de Ruta Candidatas
elaboradas en las fases B, C y D.
- Determinar si la organización necesita un enfoque incremental, si fuese así, identificar
la Arquitectura de Transición que proporcionarán un valor continuo al negocio.
37
Pasos:
• Determinar y confirmar los atributos clave para el cambio corporativo
• Determinar las limitaciones del negocio para la implementación
• Revisar y consolidar los análisis elaborados en las fases B, C y D sobre la brecha entre las
arquitecturas base y las objetivo
• Revisar los requisitos consolidados a través de las funciones de negocio consolidadas:
en este paso se evaluarán los requisitos, brechas, soluciones y factores para identificar
el conjunto de requisitos que se implementarán de forma más eficiente como paquete
de trabajo.
• Consolidar los requerimientos de interoperabilidad identificados en las fases previas.
• Ajustar las dependencias iniciales, de manera que quede asegurado que se identifica
cualquier limitación en los planes de implementación o de migración.
• Confirmar la preparación y los riesgos que se necesitan para la transformación del
negocio.
• Crear una estrategia global para la implementación y la migración.
• Identificar y agrupar los paquetes de trabajo de mayor envergadura.
• Identificar las Arquitecturas de Transición
• Crear la Arquitectura de la Hoja de Ruta y el Plan de Implementación y de Migración.
38
3.8. Fase F: Planear Migración
La fase F se centra en la creación de un plan de Implementación y de Migración con la

cooperación del portfolio y de los gestores de proyectos.
En esta fase se aprovecha el la Arquitectura de la Hoja de ruta y el Plan de Migración e
Implementación que proporciona la fase E. Estos outputs de la fase previa se integran con la
actividad de la empresa y otras actividades para el cambio. Además, los outputs de la fase E se
usarán para construir el plan final de Implementación y Migración.
Las actividades para el cambio incluyen la evaluación de dependencias, costes y beneficios de
diferentes proyectos de migración. También, se debería completar las lecciones aprendidas y
documentarlas.
Objetivos:
- Terminar la Arquitectura de la Hoja de Ruta y apoyar al Plan de Implementación y
Migración.
- Asegurar que el Plan de Implementación y Migración está coordinado con el enfoque de
gestión e implementación del cambio en el portfolio global de cambio.
- Asegurar que los stakeholders claves entienden el coste y el valor que otorga el paquete
de trabajo y la Arquitectura de Transición.
Pasos:
• Coordinar la Implementación y la Migración con el marco de gestión que existe en
la organización.
• Asignar valor de negocio a cada paquete de trabajo.
• Estimar los requerimientos de los recursos y el timing del proyecto.
• Priorizar los proyectos de Migración mediante la relación costes/beneficios y la
evaluación de riesgos.
• Confirmar la Arquitectura de la Hoja de Ruta y actualizar el documento que la define.
• Generar el Plan de Implementación y Migración.
• Completar el ciclo de desarrollo de la Arquitectura y documentar las lecciones
aprendidas.
3.9. Fase G: Implementación del Gobierno
En la fase G se reúne toda la información de varios proyectos para una gestión exitosa.
Objetivos:
- Asegurar la conformidad con la Arquitectura Objetivo por proyectos de
implementación.
- Realizar funciones apropiadas para la Arquitectura de Gobierno y para cualquier
arquitectura basada en Peticiones de Cambio.
39
Para activar la obtención temprana del valor de negocio y de los beneficios, así como para
minimizar el riesgo en el programa de transformación y migración, el enfoque favorable es
desplegar la Arquitectura Objetivo como una serie de transiciones. Cada transición representa
un paso más hacia el objetivo, y cada paso otorga beneficio al negocio. Por lo tanto, a la fase G
debemos darle el siguiente enfoque:
• Establecer un programa de implementación que active la entrega de las Arquitecturas
de Transición de acordado para la implementación durante la fase de Planeamiento de
la Migración.
• Adoptar un programa de implementación por fases que refleje las prioridades del
negocio incorporados en la Arquitectura de la Hoja de Ruta.
• Seguir el estándar de la organización para las TI y el gobierno de la arquitectura.
• Utilizar el enfoque de gestión de portfolio establecido por la organización, si es que
existe.
• Definir un marco de operaciones para asegurar una larga vida de las soluciones
desplegadas.
El gobierno de la arquitectura se define como “la práctica y orientación mediante la cual las
arquitecturas empresariales y otras arquitecturas son gestionadas y controladas a nivel de toda
la empresa”.
El gobierno de la arquitectura no opera solo, se apoya en una jerarquía de estructuras de
gobierno, se pueden llegar a incluir las siguientes estructuras o dominios:
• Gobierno corporativo
• Gobierno de la tecnología
• Gobierno de las TI
• Gobierno de la arquitectura
Estas estructuras pueden existir a diferentes niveles geográficos (nacional, comarcal, local, etc.)
El gobierno de la Arquitectura tiene las siguientes características:
• Implementación de un sistema de controles sobre la creación y el seguimiento de todos
los componentes y actividades de la arquitectura, para asegurar una presentación,
implementación y evolución efectiva de la arquitectura en la organización.
• Implementación de un sistema que asegure el cumplimiento de las normas internas,
externas y las obligaciones legales.
• Establece procesos que apoyan la gestión eficaz de los procesos anteriores dentro de
los parámetros acordados.
• El desarrollo de prácticas que garanticen la responsabilidad de los stakeholders
identificados.
40
Pasos:
• Confirmar el alcance y las prioridades para el despliegue con la gestión de despliegue.
• Identificar recursos y habilidades para el despliegue.
• Usar la guía y las soluciones de despliegue.
• Realizar una revisión del cumplimiento de la Arquitectura Empresarial.
• Implementar operaciones de negocio y de las TI.
• Realizar la revisión de post implementación y cerrar la implementación.
3.10. Fase H: Gestión del cambio de la arquitectura
En la fase H, TOGAF 9, se centra en establecer los procedimientos necesarios para gestionar el

cambio hacia la nueva arquitectura.
Objetivos:
- Asegurar que el ciclo de vida se mantiene
- Asegurar que el marco de referencia del Gobierno de la Arquitectura se ejecuta
- Asegurar que la Capacidad de la Arquitectura empresarial cubre los requerimientos
actuales
Enfoque:
La meta de esta fase es garantizar que la arquitectura alcanza el valor de negocio que se había
planteado como objetivo originalmente. Para ello se debe gestionar los cambios en la
arquitectura de una manera coherente y estructurada.
Esta fase dispondrá el monitoreo continuo de las solicitudes de gobierno, nuevos desarrollos
tecnológicos y cambios en el entorno del negocio. Cuando los cambios estén identificados, la
gestión del cambio determinará si se debe iniciar formalmente un nuevo ciclo de evolución para
la arquitectura.
Existen tres maneras de cambiar la infraestructura que debe ser integrada:
• Estratégica, de arriba abajo, el cambio es dirigido a mejorar o crear nueva capacidad
(capital).
• Cambios de abajo a arriba para corregir o mejorar la capacidad para la infraestructura
bajo la gestión de las operaciones (operación y mantenimiento).
• Las experiencias con los incrementos de proyectos entregados previamente en el
cuidado de la gestión de operaciones. Todavía se están entregando por los proyectos
que están en marcha.
Procesos de gestión del cambio de la Arquitectura Empresarial:

Podemos identificar tres categorías de cambios en la arquitectura:
• Cambio de simplificación: si queremos hacer un cambio para simplificar las tareas
normalmente lo podemos gestionar mediante las técnicas de gestión del cambio.
• Cambio incremental: puede ser gestionado mediante las técnicas de gestión del cambio
o puede necesitar una reestructuración parcial de la arquitectura.
41
• Cambio de reestructuración de la arquitectura (Re-architecting change): este tipo de

cambio requiere poner, de nuevo, la arquitectura entera en el ciclo de desarrollo de
arquitectura.
Existen ciertas directrices (reglas de oro) para el mantenimiento frente al rediseño de la

arquitectura.
Reglas de oro:
• Si un cambio afecta a dos stakeholders o más, seguramente requiera volver a activar el
ciclo ADM.
• Si el cambio solo afecta a un stakeholder la mejor opción es administrarlo mediante la
gestión del cambio.
• Si el cambio es permitido bajo una dispensación, será un escenario candidato para la
gestión del cambio.
Pasos:
• Establecer el proceso de realización del valor
• Desplegar las herramientas de monitorización
• Gestionar los riesgos
• Realizar el análisis para la gestión del cambio de la Arquitectura
• Desarrollar los requerimientos del cambio para cumplir con los objetivos
• Gestionar el proceso de Gobierno
• Activar el proceso para implementar el cambio
42
43
4. Análisis comparativo
Podemos encontrar relaciones directas entre COBIT 5 y TOGAF 9.1. Para los dos marcos las TI
tienen un papel vital en las organizaciones a la hora de conseguir sus objetivos y metas.
Entienden que se deben alinear de manera correcta y que no pueden trabajar de manera aislada.
Pretenden unir los esfuerzos del ámbito del negocio y de las TI en favor de unos logros comunes.
Ambos marcos de referencia tienen un objetivo global en común, para los dos es fundamental
conseguir que las organizaciones que los implementan consigan reducir los costes generales que
conllevan las actividades intrínsecas a las empresas y por tanto optimizar los costes. COBIT 5
hace especial hincapié en la reducción de costes que provienen de los servicios de TI y de las
tecnologías.
La relación más fuerte y relevante entre TOGAF 9.1 y COBIT 5 es que el marco de referencia de
ISACA define un conjunto de procesos para gestionar la Arquitectura Empresarial. Al ser COBIT
5 un marco que se alinea con los principales marcos del mercado, haciendo clara referencia a
ello en sus publicaciones, se puede denotar que ve en TOGAF 9.1 una buena ayuda para delegar
en él las tareas relacionadas con la Arquitectura Empresarial. Además, COBIT 5 no solo ve en
TOGAF 9.1 un buen candidato para delegar estas tareas, también se intuye que ha analizado el
marco de Open Group para la definición de sus propios procesos encargados de las tareas de
gestionar la Arquitectura empresarial.
Como podemos observar en la Tabla 1 se muestran prácticas y procesos de COBIT 5 que se
corresponden con fases y actividades de TOGAF 9.1. La mayoría de estas correspondencias las
encontramos en las prácticas del proceso APO03 de COBIT 5 (Gestionar la Arquitectura
Empresarial). Las fases de TOGAF 9.1 Arquitectura del Negocio, Arquitectura del SI y
Arquitectura de la Tecnología están definidas en la misma práctica del proceso APO03
(APO03.02) de COBIT 5. El marco de ISACA junta estas tres fases pese a que se usan para
diferentes tipos de arquitecturas. La práctica APO03.05 también combina las actividades de
Gobierno de la Implementación, Arquitectura de la Gestión del Cambio y Gestión de los
Requerimientos. Estás tres fases son de una naturaleza similar y tiene más lógica, desde el punto
de vista de TOGAF 9.1, la unión de ellas en COBIT 5 que la unión que se hace en la práctica
APO03.02. No podemos encontrar una correspondencia directa en ninguna de las prácticas del
proceso APO03 de COBIT con la fase preliminar del ADM de TOGAF 9.1. De todas formas, es
claramente relacionable con el proceso APO03 y APO01 ya que es donde COBIT 5 define las
estructuras organizativas, las funciones y responsabilidades y las políticas. La correspondencia
de la fase Gobierno de la Arquitectura la encontramos fuera del dominio APO, COBIT considera
esta fase en el proceso EDM04, perteneciente al Gobierno.
Pese a que analizando de esta manera las relaciones entre ambos marcos podríamos decir que
COBIT 5 incluye todas las fases definidas en TOGAF 9.1 no debemos olvidar que la Arquitectura
Empresarial abarca mucho más que las TI, que es en el área en la que está especializado COBIT
5. TOGAF 9.1, como marco de Arquitectura Empresarial, también nos ofrece información y
orientación sobre cómo se organiza el negocio en sí, al margen de las TI. Además, TOGAF 9.1
presenta algún producto que no se puede encontrar en COBIT 5, como por ejemplo la Hoja de
Ruta que define en la fase de Oportunidades y Soluciones no se encuentra en COBIT 5. Aunque
no deja de ser cierto que COBIT 5 no se limita al Gobierno y la Gestión de las TI. Procesos del
dominio APO, como por ejemplo Gestionar la Innovación, Gestionar los RRHH o Gestionar los
44
proveedores. Estos procesos tienen sentido y utilidad para una empresa más que no se hiciese
referencia en ellos a las TI. En realidad, COBIT 5 dispone de un amplio catálogo de procesos que
bien podrían ser utilizados como apoyo para definir la arquitectura de una organización.
A los procesos que reflejan el trabajo de TOGAF 9.1, COBIT 5 añade metas generales y
relacionados con las TI y responsabilidades a las partes interesadas a partir de la Arquitectura
Empresarial. Al tratarse de un marco con las TI como protagonista, usa los procesos descritos
para la Arquitectura Empresarial para mostrar como esta contribuye a los objetivos de alinear
las TI con el negocio, la agilidad de las TI y la optimización de los activos, recursos y capacidades
de las TI. Además, en la publicación “Enabling Procesess” de COBIT 5 se definen métricas que
ayudan a comprender el valor que la Arquitectura Empresarial y las TI otorgan conjuntamente a
la organización. Otra información adicional que COBIT 5 ofrece y de la que TOGAF 9.1 carece son
las matrices RACI que muestran los responsables de cada proceso para cada una de sus prácticas,
como ejemplo podemos ver la tabla del anexo 8.
Gracias a que COBIT 5 muestra de forma integrada la Arquitectura Empresarial con el resto de
procesos, podemos observar la relación de la arquitectura con otros procesos.
Fases y actividades de TOGAF 9 Procesos y prácticas de COBIT 5

Gestionar el Marco de Gestión de TI (APO01)
Fase Preliminar
Gestionar la Arquitectura Empresarial (APO03)
(A) Visión Arquitectónica Desarrollar una Visión Arquitectónica (APO03.01)
(B) Arquitectura del Negocio Definir una Arquitectura de Referencia (APO03.02)
(C) Arquitectura del SI Definir una Arquitectura de Referencia (APO03.02)
(D) Arquitectura de la Tecnología Definir una Arquitectura de Referencia (APO03.02)
(E) Oportunidades y Soluciones Seleccionar Oportunidades y Soluciones (APO03.03)
(F) Planificación de la Migración Definir la Implementación de la Arquitectura (APO03.04)
(G) Gobierno de la Implementación Proporcionar Servicios de la Arquitectura Empresarial (APO03.05)
(H) Arquitectura de la Gestión del
Proporcionar Servicios de la Arquitectura Empresarial (APO03.05)
Cambio
Gestión de los Requerimientos Proporcionar Servicios de la Arquitectura Empresarial (APO03.05)
Gobierno de la Arquitectura Asegurar la Optimización de Recursos (EDM04)
Tabla 1. Relación entre COBIT 5 y TOGAF 9.1
45
46
5. La empresa seleccionada
La empresa protagonista del caso de estudio de este trabajo es TapBeverage. Esta empresa
aparece a finales 2014 por una fusión de dos empresas dedicadas a la instalación y
mantenimiento de surtidores de bebidas.
Las empresas de las que proviene TapBeverage empezaron sus servicios en Granada y en Bilbao,
cada una empezó a expandirse por el sur y por el norte respectivamente. Este panorama hizo su
fusión supusiese el funcionamiento de la empresa en toda la península Ibérica y Baleares.
La empresa tiene en plantilla 127 trabajadores en los que están incluidos altos cargos, técnicos,
trabajadores del ámbito legal, mozos de almacén, etc. La empresa dispone de varios almacenes
en propiedad y alquilados repartidos por la península y Baleares.
47
48
6. Sector del mantenimiento y la
restauración
La empresa del caso de estudio que se presenta en este trabajo pertenece al sector del
mantenimiento, dentro de este sector se encuentra en el de la conservación correctiva.
Desde 1990 existe una tendencia en la que se ve como en España el porcentaje de gastos
dedicados al mantenimiento correctivo descienden y ascienden los gastos en el mantenimiento
preventivo. En 1990 los gastos correctivos eran del 70% frente a los preventivos que suponían
el 30%, en 2010 se calculó que los correctivos eran del 52% mientras que los preventivos habían
crecido hasta el 48%. La razón de esta evolución es que previniendo se evita un paro en la
actividad y se reducen gastos.23
Pese a dedicarse al mantenimiento, TapBeverage está fuertemente ligada al sector de la
restauración, su crecimiento está directamente relacionado al de este sector.
Las empresas dedicadas a la restauración en España crecieron un 3% en 2015 y un 6% en 2016.
Se calcula que en 2017 se abrirán 400 nuevos locales dedicados a la restauración. Las cadenas
de restauración suponen un importante aporte a este sector, facturando 9.276 millones en 2015
y 10.000 en 2016. Estas cadenas suponen buenas oportunidades para las empresas
dependientes de este sector a la hora conseguir contratos importantes.24 25
49
50
7. Caso de estudio
7.1. Situación
TapBeverage es una empresa dedicada a la instalación y mantenimiento de surtidores de

bebidas y cafeteras en bares, discotecas, restaurantes, clubes y particulares. La empresa opera
en toda España exceptuando el archipiélago canario. Debido a una fusión anterior TapBeverage
tiene su sistema de información (SI) partido en dos, las comunidades autónomas de
Extremadura, Murcia y Andalucía funcionan al margen del resto, al conjunto de estas tres
comunidades se le denomina como zona Sur y al resto zona Norte.
La zona Norte tiene una oficina localizada en Madrid donde se reciben las incidencias de los
clientes, las incidencias pueden ser reportadas telefónicamente o mediante un sistema de
gestión de incidencias (SGI) al que tienen acceso los clientes. Cuando una incidencia entra vía
telefónica el operador inserta los datos del cliente y de la incidencia en el SGI y la deriva al grupo
de técnicos correspondiente. Si la incidencia está reportada por el cliente mediante el SGI el
operador recibe una alerta y deriva la incidencia. Hay tres casos que dependiendo de los
síntomas del producto averiado y del modelo del mismo en el que el operador pide al cliente
que haga ciertas comprobaciones con el objetivo de solucionar el problema sin enviar un
técnico, si la incidencia no ha sido realizada telefónicamente el operador llamará al cliente para
realizar el test. [Anexo 9]
Además del centro de atención al cliente, en el mismo centro de oficinas TapBeverage tiene
ubicado los servicios de SI, a este departamento se le denomina Departamento de Tecnologías
(DT). Tienen un servidor propio que da soporte al SGI y a las PDAs de los técnicos. El DT se
encarga de gestionar la base de datos de los clientes, mantener todos los servicios activos,
mantenimiento de la aplicación usada en las PDAs, mantenimiento del SGI y del gestor de stock.
En la zona Sur usan un SGI diferente pero el funcionamiento es idéntico al que usan en la zona
Norte y las incidencias se atienden desde una oficina ubicada en Granada la cual también
funciona como almacén. El resto de servicios que se desempeña en el centro de oficinas de
Madrid están subcontratados a una consultora para la zona Sur.
Para la atención de las incidencias los técnicos reciben los avisos de las incidencias mediante la
PDA corporativa, el trabajo se divide en grupos de técnicos y se asigna a cada grupo según la
proximidad geográfica, cada grupo de técnicos tiene un coordinador que asigna cada incidencia
del grupo al técnico que crea más conveniente. Acuden al lugar de la incidencia y la resuelven,
si precisan una pieza de la cual no disponen en su vehículo de trabajo van al almacén de la zona
para cogerla y lo refleja mediante la PDA en el sistema de control de stock.
Este SI tiene carencias al estar partido en dos. El mismo cliente puede estar en la base de datos
de la zona Sur y de la zona Norte ya que TapBeverage tiene contrato con cadenas de restauración
con presencia en ambas zonas, esto puede resultar un problema ya que algunos clientes hacen
las incidencias de forma centralizada y se ven obligados a usar dos SGIs diferentes, además al
final de cada ejercicio se realizan estudios para ver la eficacia con la que se ha tratado a cada
cliente y otras operaciones para las que es necesario tener el mismo cliente en una sola base de
datos. La manutención de los dos sistemas resulta más costosa en términos económicos que
tener todo subcontratado o gestionarlo todo de manera autónoma. Puede darse el caso de que
51
un técnico de la zona Norte esté más cerca de una incidencia de la zona Sur que cualquier técnico
de dicha zona. La gestión de los almacenes es muy deficiente, se quedan piezas sin usar en
almacenes de una zona para la que están obsoletas pero que no lo están para la otra zona, en
ciertos lugares geográficos es necesario consultar ambos sistemas de gestión de stock para
asegurarse de cuál es el más cercano, etc. Las mejores prácticas que guardan en el SGI los
técnicos para averías menos habituales no están compartidas para ambas zonas.
7.2. Necesidad
Desde la fusión que dio lugar a este SI dividido se está proyectando la integración de los servicios,
la unión de las zonas y mejorar la usabilidad del sistema, pero con el acuerdo alcanzado con una
empresa de restauración a nivel estatal (Restaurantes Attic) TapBeverage se ha visto obligada a
acelerar la implantación del nuevo SI.
La empresa con la que ha alcanzado el acuerdo ha determinado el nivel de servicio que necesita.
Para que TapBeverage pueda cubrir las necesidades del nuevo cliente debe de actualizar y
mejorar todo su SI y la estructura de su empresa. Para ello ha identificado las carencias que tiene
su sistema, anteriormente nombradas, y va a llevar a cabo una reestructuración de la
organización en base a dichas carencias.
TapBeverage se ha propuesto varias metas a nivel tecnológico y de funcionamiento. Quiere
tener una base de datos que incluya todos los clientes, almacenes, técnicos, etc. El SGI será único
y se hallarán en él todas las mejores prácticas de los anteriores SGIs.
Cada técnico dispondrá de una nueva PDA con geolocalización que permitirá encontrar al
técnico más cercano para asignar una incidencia, además cuando un técnico acuda a una
incidencia que no pueda resolver por falta de material, el nuevo sistema le permitirá saber si es
más eficiente ir a buscar dicha pieza a un almacén o si un compañero cercano dispone de la
pieza, pudiendo así pasar la incidencia al compañero y quedar él libre para ir a atender otra.
Dado que para esta aplicación resulta necesario hacer inventario de lo que hay en cada almacén
y de lo que tiene cada técnico muy a menudo, se va a implementar un sistema de gestión de
stock mediante etiquetas RFID, con las etiquetas RFID conseguiremos que cada vez que un
técnico extraiga o introduzca material del almacén quede reflejado y la aplicación esté
actualizada constantemente, una vez usada la pieza el técnico lo reflejará en su PDA.
Todo el mantenimiento de los servidores, SGI, aplicación de las PDAs y base de datos lo llevará
TapBeverage. La atención al cliente y la gestión de incidencias se llevará desde la oficina ubicada
en Granada, se aprovechará que también funciona como almacén para dejar obsoleta la oficina
de Madrid y ahorrar costes. Gracias al nuevo funcionamiento del sistema que permite tener la
base de datos, el stock y el seguimiento de los técnicos a tiempo real, se desarrollará una
aplicación con un cuadro de mando [anexo 10] que muestre el rendimiento de la empresa y la
eficiencia del servicio que presta a los clientes, esta aplicación también permitirá de manera más
sencilla encontrar debilidades, tener informes detallados y saber las necesidades de cada
cliente.
La empresa espera que esta nueva forma de funcionar le permita: reducir el tiempo medio de
resolución de incidencias, controlar que no haya clientes con un tiempo de espera que salga del
margen aceptable, detectar cuellos de botella, aumentar la satisfacción del trabajador
disminuyendo la cantidad de kilómetros que realizan, aumentar la satisfacción del cliente,
52
disminuir la cantidad total de incidencias en espera y aumentar el ratio de incidencias resueltas
por día y por técnico. Además, pretenden ahorrar costes en el alquiler de almacenes,
desplazamiento de los técnicos, sobredimensionamiento de la plantilla, mantenimiento del SI y
en la gestión de stock.
La dirección de TapBeverage ha bautizado a este proyecto como Proyecto Trenza.
7.3. Expectativas
TapBeverage quiere que los clientes noten la diferencia entre el SGI actual y el nuevo. Para ello
se ha marcado dos objetivos: aumentar el porcentaje de incidencias resueltas el mismo día de
su creación (las siguientes 24 horas a su creación) y disminuir el tiempo de respuesta medio de
cada incidencia.
El porcentaje de incidencias resueltas el mismo día es del 61% y gracias a la geolocalización de
la aplicación de las PDAs se quiere mejorar mucho en este aspecto, el objetivo es llegar al 80%
medio año después de estrenar el nuevo SGI. Se ha calculado una línea base que describe la
evolución las primeras 10 semanas para medir la consecución del objetivo. TapBeverage tiene
en cuenta que la evolución en las primeras semanas es mucho mayor.
RENDIMIENTO INMEDIATO
% INC. RESUELTAS MISMO
90
80
DIA CREACIÓN
70
60
50
1 2 3 4 5 6 7 8 9 10
SEMANAS DESDE EL NUEVO SGI
Ilustración 12. Línea base del rendimiento inmediato
Para el tiempo de respuesta se ha marcado el objetivo de bajar de las 13 horas en un año,

actualmente se encuentra en 17,5 horas. También se ha creado una línea base.
TIEMPO DE RESPUESTA
HORAS EN RESPONDER
18
17
16
15
1 2 3 4 5 6 7 8 9 10
SEMANAS DESDE EL NUEVO SI
Ilustración 13. Línea base del tiempo de respuesta
53
54
8. Aplicación de COBIT 5 y TOGAF 9.1 al
caso de estudio
8.1. Selección y justificación
TapBeverage tiene por delante una reestructuración de gran envergadura. Para lograr gestionar
con éxito el enorme cambio en la organización se debe implementar mediante una metodología
probada y contrastada, que tenga en cuenta las necesidades de la organización y del propio
cambio.
En este caso, la protagonista principal del cambio es la Tecnología de la Información, desde ella
se quiere conseguir que la inversión en la empresa genere valor. La prioridad es lograr las metas
y cubrir las necesidades que la organización se ha propuesto y el cliente ha impuesto. Para
rentabilizar el capital que va a necesitar el proyecto se necesita optimizar los costes que suponen
la TI y que el nuevo sistema tenga un funcionamiento eficiente y que realmente proporcione
valor a la empresa. Además, al tener tanta importancia las TI, la mayor parte de los riesgos
estarán relacionados con ellas, por lo tanto, se pretende minimizar los riesgos provenientes de
las TI. Teniendo en cuenta estas necesidades, la directiva ha decidido que el marco más
adecuado es COBIT 5.
Además, COBIT 5 se integra con TOGAF 9 y TapBeverage cree necesario aplicar un marco de
referencia que esté exclusivamente dedicado a la Arquitectura Empresarial. La elección de este
marco para la arquitectura ha sido causada por la búsqueda de un marco que ayude a alinear
las TI con el negocio, potencie la innovación, y proporcione capacidad de adaptación.
8.2. Metodología COBIT 5
8.2.1. Principio 1: Satisfacer las necesidades de las partes interesadas
Según se describe en el Principio 1 de COBIT 5, el Gobierno de TapBeverage debe asegurar que

el cambio que pretende llevar a cabo va a generar valor a todas las partes interesadas. Para ello
se deben identificar todas las partes interesadas en el proyecto de TapBeverage.
La principal parte interesada, o stakeholder, es la empresa con la que TapBeverage ha firmado
el nuevo contrato (Restaurantes Attic), el cual ha acelerado el comienzo del Proyecto Trenza.
Todos los clientes que ya estaban anteriormente en la cartera de TapBeverage constituyen un
stakeholder que se gestionará aparte de Restaurantes Attic, ya que las necesidades y exigencias
de los clientes más antiguos están satisfechas con el sistema actual de la empresa, pero para
satisfacer los de Restaurantes Attic son necesarios los cambios que conlleva el Proyecto Trenza.
Los trabajadores de TapBeverage, representados por el sindicato, tienen un alto interés en el
proyecto porque van a ser necesarios cambios en la manera de trabajar, reciclaje de
trabajadores, nuevas contrataciones y posiblemente despidos. Caja Austral será una parte
interesada por proporcionar parte del capital necesario en forma de crédito financiero.
55
Por tanto, el análisis de los stakeholders queda de la siguiente manera:

Stakeholder: Restaurantes Attic
Tipo: Externo
Nivel Acciones Posibles
Objetivo o Nivel de
de De impacto negativo Estrategias
Resultados Influencia De impacto positivo
Interés
Ejecución de
Consultar
Conseguir Aporte de ideas y cláusulas
decisiones clave.
tener sus soluciones para contractuales por el
Aportar
necesidades Alto Alto problemas surgidos incumplimiento de
información del
y exigencias durante el Proyecto plazos u otros
progreso del
cubiertas Trenza puntos por parte de
proyecto.
TapBeverage
Intereses: o Cubrir todas las necesidades.
o Cumplimiento de los plazos del proyecto.
o Influir en el proyecto.
o Que sus problemas y peticiones sean atendidas.
Tabla 2. Stakeholder Restaurantes Attic
Stakeholder: Caja Austral

Tipo: Externo
Objetivo o Nivel de
de De impacto De impacto Estrategias
Resultados Influencia
Interés positivo negativo
Penalización o Cumplir con los
Mejora de las
toma de medidas plazos de pago
Cumplir las condiciones del
legales por el establecidos o
condiciones Bajo Bajo crédito por
incumplimiento de justificar y negociar
del crédito. pronto pago del
las condiciones de con anticipación
crédito.
pago del crédito. posibles retrasos.
Intereses: o Cumplimiento de los términos y condiciones del pago del crédito.
Tabla 3. Stakeholder Caja Austral
56
Stakeholder: Trabajadores (Sindicato)
Tipo: Interno
Objetivo o de Nivel de De impacto De impacto Estrategias
Resultados Interé Influencia positivo negativo
s
Reducir al mínimo el
Paro del trabajo
número de despidos.
Conseguir que los Implicación y (huelga) a causa
Compensar el
empleados estén motivación a la de despidos
esfuerzo extra de los
implicados en el hora de excesivos o
trabajadores. Atender
proyecto, formarse y empeoramiento
el impacto personal
mantener la reciclarse. de las
Alto Alto por el reciclado de
motivación alta y Detección de condiciones de
trabajadores.
que aporten valor fortalezas y trabajo.
Maximizar la
con el nuevo debilidades del Desentendimient
información y la
sistema de antiguo sistema o y dejadez
formación sobre el
trabajo. de trabajo. sobre el
nuevo sistema de
proyecto.
trabajo.
Intereses: o Conservar el puesto de trabajo.
o Compensación del esfuerzo extra que supone el proyecto.
o Atención personalizada en todos los casos que un trabajador deba
cambiar de puesto o de funciones.
o Mejorar y hacer más cómoda la forma de trabajo.
o Formación sobre el nuevo SI y las nuevas tareas a desempeñar.
Tabla 4. Stakeholder trabajadores
Stakeholder: Cartera de clientes de TapBeverage

Tipo: Externo
Objetivo o Nivel de
de De impacto De impacto Estrategias
Resultados Influencia
Interés positivo negativo
Al ser Rescisión o no
Mantener
Mantener el conocedores del prorrogación del
informados del
mismo nivel, método de trabajo contrato vigente
progreso y cambios
como mínimo, de TapBeverage por verse
Alto Bajo del proyecto y estar
de servicios pueden detectar afectado
dispuestos a
prestados puntos débiles y negativamente
escuchar propuestas
anteriormente. aconsejar sobre por la marcha del
e ideas.
ellos. proyecto.
Intereses: o Recibir, como mínimo, el mismo nivel de servicio que ahora reciben
durante y después del Proyecto Trenza.
o Recibir información sobre los cambios en la forma de trabajar de
TapBeverage.
o Ser tomados en cuenta a la hora de decidir cambios que puedan afectar al
servicio que reciben antes del proyecto.
Tabla 5. Stakeholder clientes
57
Todo el cambio que se va a experimentar en la estructura organizativa, la manera de trabajar y

en las TI de TapBeverage es, principalmente, a causa del nuevo contrato que ha conseguido con
Restaurantes Attic. Ya que el contrato supone una gran cantidad de ingresos para la empresa. El
principal objetivo de TapBeverage es la satisfacción del cliente mediante el ofrecimiento de un
servicio excelente. El proyecto también tiene como objetivo reducir costes, pero eso se puede
dejar en un segundo plano para conseguir el objetivo principal.
Teniendo clara la prioridad de la empresa, se han definido unas metas tanto a nivel corporativo
como relacionadas con las TI. La empresa se ha apoyado en la relación de las metas corporativas
y los objetivos de Gobierno [anexo 1] y el mapeo entre las metas corporativas y las preguntas
del Gobierno y la Gestión [anexo 5] para elección de las metas corporativas. Además, para la
definición de las metas relacionadas con las TI se ha usado la tabla de mapeo entre metas
corporativas y metas relacionadas con las TI de COBIT 5 [anexo 3], priorizando y eligiendo
aquellas metas relacionadas con las TI que desempeñan un papel principal o secundario para la
consecución de las metas corporativas.
Metas corporativas:
Financiera:
• Valor para las partes interesadas de las Inversiones de Negocio
Cliente:
• Cultura de servicio orientada al cliente
• Optimización de costes de entrega del servicio
Interna:
• Optimización de la funcionalidad de los procesos de negocio
• Optimización de los costes de los procesos de negocio
• Productividad operacional y de los empleados
Metas relacionadas con las TI:

Financiera:
• Alineamiento de TI y estrategia de negocio
Cliente:
• Entrega de servicios de TI de acuerdo a los requisitos del negocio
• Uso adecuado de aplicaciones, información y soluciones tecnológicas
Interna:
• Agilidad de las TI
• Optimización de activos, recursos y capacidades de las TI
• Disponibilidad de información útil y fiable para la toma de decisiones
58
8.2.2. Principio 2: Cubrir la organización de forma integral
El Proyecto Trenza tiene como misión principal el cambio del SI, pero este objetivo requiere un
transformación profunda y completa de la organización. Por eso el Gobierno va adoptar el
alcance natural de COBIT 5: cubrir la empresa de extremo a extremo. Todos los activos y niveles
de la empresa van a verse afectados por los cambios de este proyecto.
También se definen los catalizadores Gobierno que lo van a apoyar en sus actividades. Marcos
de referencia, procesos, principios, prácticas y recursos corporativos van a formar el conjunto
de catalizadores de Gobierno.
- Marcos de referencia: Como se ha descrito anteriormente, para llevar a cabo el proyecto
van a usarse COBIT 5 y TOGAF 9.1, pero, además, TapBeverage tiene aplicado desde
hace un tiempo la serie ISO 27000 para encargarse del sistema de gestión de la
seguridad de la información y SFIA-Skills Framework for the Information Age para las
buenas prácticas de personas, habilidades y competencias.
- Procesos: Serán definidos con detalle más adelante.
- Principios: Los principios se recogen en la misión, visión y valores de la empresa.
o Misión: Ofrecer la refrescante sensación de una bebida servida con tirador a
todos los clientes de establecimientos de restauración.
o Visión: Ofrecer la más amplia variedad de soluciones para bebidas de tirador.
Desarrollar los recursos y las formas de trabajo que más satisfagan a nuestros
clientes y empleados.
o Valores: Calidad, garantía, rápida actuación y transparencia.
- Prácticas: Tener a disposición de la empresa las mejores prácticas que aportan los
marcos de referencia implementados en la organización y el portfolio de mejores
prácticas acumuladas durante los años de trabajo y experiencia de TapBeverage.
- Recursos corporativos: Se usarán como catalizadores la infraestructura de TI vigente en
la organización, así como las nuevas soluciones de TI que se vayan incorporando a
medida que avance el proyecto. Además, las competencias y habilidades de los
trabajadores en plantilla y toda la experiencia a nivel personal y a nivel de la empresa.
Aparte de estos catalizadores, el Gobierno podrá apoyarse en cualquier otro catalizador que
será definido más adelante, como, por ejemplo, los procesos, políticas de la empresa o la
información.
La configuración de los roles, actividades y relaciones es la siguiente:
En primer lugar, están los propietarios y los grupos de interés, serán los máximos responsables
del proyecto y del gobierno, ellos delegarán en el Órgano de Gobierno las decisiones, la
evaluación, supervisión y orientación.
El órgano de Gobierno es responsabilidad del consejo de administración y está dirigido por su
presidente. Este órgano estará formado por la unidad de auditorías interna que se encargará de
evaluar las necesidades de la empresa para cumplir satisfacer a las partes interesadas. Por otro
lado, estará la unidad de análisis, serán los encargados de evaluar las condiciones y opciones
que existen para cubrir las necesidades detectadas por la unidad de auditoría interna. Por
último, la unidad de toma de decisiones que, junto al presidente, serán los que tomarán las
decisiones. El Órgano de Gobierno supervisará a la Gestión y le comunicará las necesidades para
que ésta aplique las actividades necesarias con tal de satisfacerlas.
59
8.2.3. Principio 3: Aplicar un marco de referencia único integrado
Pero la revolución que va a tener lugar en TapBeverage no se limita a las TI, va a tener
repercusión a muchos niveles en la organización, va a cambiar la manera de trabajar y en la
estructura global de la empresa. Así que se ha decidido delegar en una norma especializada las
actividades y procesos relativos a la Arquitectura Empresarial. Gracias a que TOGAF 9.1 ofrece
ciertos aspectos que TapBeverage estima cruciales (alineamiento del negoció con la TI,
reducción de costes, voluntad de innovación y capacidad de adaptación a las necesidades de un
proyecto concreto) ha hecho que este marco sea el elegido para gestionar los aspectos
relacionados con la arquitectura empresarial.
8.2.4. Principio 4: Hacer posible un enfoque holístico
COBIT 5 recomienda a la organización estructurar los catalizadores en las siete categorías

existentes. Junto a cada categoría se definen los dominios de cada uno de ellas.
8.2.4.1. Principios, políticas y marcos de referencia
En la categoría de principios, políticas y marcos de referencia encontraremos los principios

definidos anteriormente mediante la misión, la visión y los valores. Los marcos de referencia
también han sido anteriormente nombrados, siendo COBIT 5 para la gobernanza y gestión de
las TI, TOGAF 9.1 para la arquitectura empresarial, SFIA-Skills Framework for the Information
Age como marco buenas prácticas para Personas, Habilidades y Competencias y los estándares
de la serie 27000 para la seguridad de los recursos informáticos. También se usarán los
estándares de modelación Archimate y BPMN. Falta por definir las políticas de la empresa.
TapBeverage define claramente y comunica a todos los interesados sus políticas. Las políticas se
revisarán al inicio de cada ejercicio para asegurar que están alineadas con los objetivos de la
empresa. Las políticas de la organización son:
• Sobre el uso de recursos informáticos: Los empleados podrán usar los portátiles de la
organización que la empresa les proporciona para su uso personal fuera de horario
laboral y puntualmente mientras permanecen en su puesto de trabajo.
• Sobre la seguridad informática: No se permite el uso de otros recursos informáticos en
el puesto de trabajo que no sean los proporcionados por la empresa. Además, no se
podrá conectar en ningún momento un dispositivo personal (móvil, pendrive, etc.) a un
recurso de la empresa.
• Sobre cambios que afectan al cliente: Cuando surja la necesidad de hacer un cambio que
afecte al servicio prestado al cliente, este será informado con suficiente anterioridad
para buscar una solución acordada.
Las partes interesadas para estas políticas son los trabajadores como grupo de interés interno y
los clientes como externo.
Las metas que se esperan conseguir con estas políticas es aumentar la seguridad en los recursos
informáticos, aportar una facilidad a los empleados ofreciéndoles la posibilidad de usar los
equipos corporativos y aumentar la satisfacción del cliente.
60
El ciclo de vida de estas políticas y principios se reiniciará al finalizar el ejercicio fiscal, cuando se
evalúa el existo de las mismas, se revisa su efectividad y se considera la posibilidad de cambiarlas
o continuar con su uso.
El alcance de estos catalizadores es a toda la empresa e incluso afectando a partes externas
como son los clientes. Si las políticas no se cumplen se depurarán responsabilidades aplicando
sanciones en caso de que procedan y en caso de que el no cumplimiento afecte directamente a
uno o más clientes TapBeverage deberá compensar al cliente de forma proporcional a los
perjuicios que se le hayan causado. Para detectar que se cumplen las políticas del uso de
recursos informáticos y de la seguridad de lo mismo, se incorporarán aplicaciones que detecten
las infracciones monitoreando los equipos.
Esta categoría catalizadores afectan directamente a todos los catalizadores ya que se
encuentran dentro de los marcos de referencia. Además, las políticas están vinculadas a la
cultura de la empresa y son una herramienta más para conseguir que se instauren y cumplan.
8.2.4.2. Procesos
La categoría de procesos será definida detalladamente más adelante cuando se decidan los
procesos de COBIT 5 que se van a activar, estos procesos serán elegidos de acuerdo con las
metas y objetivos de la organización. Cada proceso activado tiene sus partes interesadas metas
y buenas prácticas. Cada proceso tendrá su propio ciclo de vida en el que será definido, creado,
será utilizado, supervisado y actualizado o en caso de que no se requiera más su uso se retirará.
8.2.4.3. Estructuras Organizativas
De las estructuras organizativas que COBIT 5 presenta TapBeverage ha estimado oportuna

presentar en la organización las siguientes:
- Consejo de Administración
- Dentro de la Gerencia se encontrarán: El CEO como máximo responsable de la Gerencia,
el Jefe de Desarrollo, el Jefe de Operaciones de TI y el Jefe de Administración de TI.
- Director General Financiero (CFO)
- Director de Informática/Sistemas (CIO)
- El Consejo de Arquitectura cuyo máximo responsable será el Jefe de Arquitectura
- El Jefe de RRHH
- La función de Auditorías internas
La parte interesada de esta categoría de catalizador son todos los miembros de TapBeverage.
La meta es conseguir un buen mandato, si se consigue aplicar correctamente las Estructuras
Organizativas estarán bien definidos los responsables de cada área de trabajo.
El ciclo de vida de las estructuras consiste en su creación, existencia y ajuste, cuando llega el
periodo de ajuste se considera que no cumple con las expectativas o que a partir de ese
momento no va a ser de utilidad se deberá disolver.
61
Las buenas prácticas que se implementarán en las Estructuras Organizativas serán el ámbito de
control de cada una y que nivel de derecho de decisión tiene cada una de ellas para conseguir
un funcionamiento óptimo de las estructuras sin que ninguna invada el espacio de otras.
Esta categoría de catalizadores está relacionada con la cultura, ética y comportamiento,
personas, habilidades y competencias y los principios, políticas y marcos de referencia, ya que
esta categoría será la responsable de gestionarlas correctamente e implantarlas mediante su
correcto mandato.
8.2.4.4. Cultura, ética y comportamiento
Con la experiencia se ha detectado que hay proyectos en los que se encuentran cuellos de
botella al haber una tarea asignada a un trabajador en concreto que no se ha cumplido, por ello
se quiere instaurar la cultura del "problema compartido". Consiste en que todos los miembros
de un equipo de trabajo deben de saber en que punto se encuentran las tareas que tiene
asignadas cada compañero. La finalidad es que no se produzcan estos cuellos de botella y evitar
que un problema suponga el estancamiento en una tarea. Esto también aumentará el
compañerismo y la comunicación entre los miembros del equipo.
Esto se pretende conseguir mediante reuniones diarias (daily), en la que cada miembro explica
en que punto se encuentran sus tareas y puede pedir ayuda a otros compañeros o redistribuir
la carga.
Además, con el tiempo se ha instaurado una "obligación" de hacer una jornada laboral más larga
de lo estipulado. Hay trabajadores que consideran que está bien visto retrasar la hora de salida
del puesto de trabajo. En algunos casos se ha percibido que muchos de los empleados que han
adoptado esta práctica dedican un tiempo relativamente largo los primeros momentos de la
jornada a asuntos personales y comienzan el trabajo más tarde o compensan ese el tiempo extra
que permanecen en su puesto con parones no programados o más largos de lo establecido.
Se pretende cambiar esa cultura e implantar la “cultura del rendimiento”. La directiva maneja
estudios que afirman que si se cumplen los horarios y las paradas estipuladas los trabajadores
tienen un rendimiento más alto. Para ello se pretende programar las reuniones diarias un poco
antes del ecuador de la jornada para hacer un balance de lo hecho ese mismo día. Los superiores
deberán animar a sus subordinados a hacer las paradas de 5 minutos acordadas cada 90 minutos
y a abandonar su puesto de trabajo llegado el final de la jornada. Con ello se pretende no dejar
espacio a usar el tiempo de la organización para asuntos personales de manera reiterada y
sistemática, evitar que haya empleados que pidan compensación por horas trabajadas de más
que no eran necesarias y que los empleados puedan compaginar mejor la vida laboral con la
privada sabiendo cuál es exactamente su horario. Todo ello aumentará el rendimiento y la
satisfacción del trabajador que verá como en menos tiempo es capaz de conseguir los resultados
(que deben ser realistas) previstos en las reuniones diarias y no sentirá la necesidad de aportar
valor a la empresa con su tiempo libre y si con su rendimiento.
Las partes interesadas para de estas medidas son los empleados y sus responsables más
directos.
Las metas son las ya citadas: aumentar el rendimiento y la satisfacción de los empleados,
además de ahorrar posibles sobrecostes con las compensaciones.
62
El ciclo de vida consiste en crear e implantar estas culturas, al fin de cada ejercicio fiscal se
evalúan la consecución de las metas, y con ello se ajustan o disuelven.
Las buenas prácticas que se aplicarán en esta categoría de catalizadores consistirán en
comunicar claramente y de forma reiterada las intenciones de la organización de implantar estas
culturas, incentivar a los empleados más participativos en las reuniones diarias y consiga ajustar
sus metas de forma más realista.
La cultura está relacionada con las habilidades y competencias de los trabajadores y principios
y políticas, que se deben complementar entre sí. Además, las estructuras organizativas deberán
configurar sus límites de forma que puedan controlas y promover estas culturas.
8.2.4.5. Información
Los catalizadores de la categoría de información estarán compuestos por toda la información

que tiene almacenada la organización:
• Todos los manuales desarrollados durante el tiempo que TapBeverage lleva
desarrollando su actividad empresarial. Esto incluye las mejores prácticas aprendidas
por los técnicos y que han sido incluidas en el SGI, los manuales para realizar actividades
como la instalación base de datos o sistemas operativos por parte del DT y todos los
manuales existentes en cualquier departamento o nivel de la organización.
• Los documentos de formación usados para el aprendizaje de las nuevas incorporaciones
o en cursos destinados para la plantilla en general.
• La base de datos con toda la información de los clientes: averías, número de
intervenciones, equipos que tienen en funcionamiento o han tenido, número de
sucursales, programas de fidelización aplicados en cada cliente, etc.
• Los SLA y contratos firmados con actores externos a TapBeverage.
• Informes de auditorías (internas y externas)
Las partes interesadas de la información son todos los componentes de la empresa a todos los
niveles, todos los clientes que tienen interés principalmente en la información referente a ellos
y las autoridades que deben asegurar que se cumple la normativa de tratamiento de datos
estipulada en la LOPD.
TapBeverage tiene que conseguir tres metas generales:
Conseguir que la información sea de calidad intrínseca, es decir, que se pueda confiar en que la
información tenga credibilidad, precisión, objetividad y que provenga de un origen con
credibilidad.
El ciclo de vida de la información consiste en planificarla, diseñarla, construirla y usarla.
TapBeverage debe de guardar el máximo de información relevante y que la ley permita
almacenarla.
TapBeverage delegará en la ISO 27001 las buenas prácticas sobre la seguridad de la información.
La información está relacionada con todas las categorías de catalizadores, todas ellas reciben o
crean información.
63
8.2.4.6. Servicios, Infraestructuras y Aplicaciones
En la categoría de servicios, infraestructuras y aplicaciones la organización dispone de:

• PDAs que utilizan los técnicos.
• La infraestructura de las TI: servidores, ordenadores, redes, etc.
• Sistemas operativos y todo tipo de aplicaciones y programas instalados o adquiridos.
• El SGI (antiguo y el nuevo cuando se despliegue)
Los clientes forman parte de las partes interesadas ya que son usuarios del SGI y todos los
empleados de la empresa, desde los técnicos que usan las PDAs hasta la alta dirección que usa
los equipos informáticos con sus aplicaciones y sistemas operativos. También forma parte de las
partes interesadas las empresas que proveen servicios a TapBeverege.
Las metas de los servicios son definidas por el SLA que TapBeverage ha firmado tanto con sus
clientes como con sus proveedores de servicios.
TapBeverage adoptará como buenas prácticas una arquitectura para las infraestructuras simple
y la reutilización de sus recursos, en esta categoría de catalizadores, para otros servicios
prestados para los que originalmente habían sido dirigidos, por ejemplo, ofrecer un servicio a
un cliente que se ha implementado por petición de una necesidad o requerimiento de otro
cliente.
Esta categoría mantiene relación con la política de la empresa, ya que parte de esas políticas van
expresamente dirigidas al uso de las infraestructuras corporativas. La información también está
relacionada, ya que los servicios se desempeñan con la información que se tiene y mediante las
infraestructuras que dispone.
8.2.4.7. Persona, Habilidades y Competencias
La empresa da una especial importancia a la categoría de personas, habilidades y competencias.

La organización se ha asegurado de que todos los empleados (directivos, coordinadores y
técnicos) constituyan un catalizador que genere gran valor ofreciendo y desempeñando sus
habilidades y competencias. TapBeverage ha realizado un importante esfuerzo en la formación
de su plantilla, en aquellas habilidades y aptitudes que considera clave para sus empleados. En
el departamento de RRHH se ha prestado especial atención en incorporar aquellos candidatos
que presentaban un perfil personal con mayor capacidad para adaptarse a la ética y cultura de
la empresa y luego se les ha formado técnicamente. En los equipos de Gobierno y Gestión se
han asegurado de contratar a gente certificada y experimentada en COBIT 5 y en TOGAF 9.1,
además han ofrecido cursos y exámenes para los miembros que ya estaban en los equipos de
trabajo.
Las partes interesadas son los componentes de la organización y los clientes que contratan las
competencias de la plantilla de TapBeverage.
La meta es conseguir que esta categoría de catalizadores ofrezca un apoyo importante a todos
los niveles de la empresa y en todos los departamentos.
El ciclo de vida que TapBeverage tiene implementado es la recopilación de los conocimientos y
plantilla que actualmente posee y al finalizar el ejercicio fiscal evalúa su rendimiento y la
64
consecución de sus metas con el fin de continuar con la misma filosofía o incorporar algún
cambio.
Las buenas prácticas en esta categoría se delegarán en el marco de referencia SFIA-Skills
Framework for the Information Age.
Los procesos tendrán una fuerte relación con esta categoría, ya que con las habilidades y
competencias de los empleados se desempeñarán las tareas que los componen. La cultura, ética
y comportamiento también están relacionadas, ya que son las personas quien deben adoptarlas.
8.2.5. Principio 5: Separar El Gobierno de la Gestión
Mientras se han ido ejecutando los principios de COBIT 5 se ha visto que hay una clara
diferenciación entre el Gobierno y la Gestión. Ahora TapBeverage decidirá los procesos que va
a activar para los dos organismos.
Los procesos que se van a activar han sido escogidos mediante la matriz que mapea las metas
relacionadas con las TI y los procesos de COBIT 5. [anexo 4] Estos procesos elegidos son en
conjunto los que más aportan a las metas definidas, para asegurar que así sea se han elegido los
procesos que tienen una relación más importante con las metas, o al menos que mantengan un
fuerte vínculo con ellas, según la matriz proporcionada por COBIT 5.
TapBeverage ha ajustado el número de procesos activados a sus recursos, necesidades y
posibilidades, activando los imprescindibles para aportar el valor que la organización necesita.
Los procesos activados son los siguientes:
Dominio EDM (Evaluar, orientar y supervisar):
• EDM04: Asegurar la Optimización de los Recursos
Dominio APO (Alinear, Planificar y Organizar):

• APO03: Gestionar la arquitectura empresarial
• APO04: Gestionar la Innovación
• APO07: Gestionar los RRHH
• APO08: Gestionar las relaciones
• APO09: Gestionar los acuerdos de servicio
Dominio BAI (Construir, Adquirir e Implementar):

• BAI04: Gestionar la disponibilidad y la capacidad
• BAI08: Gestionar el conocimiento
Dominio DSS (Entregar, dar Servicio y Soporte):

• DSS03: Gestionar los problemas
Dominio MEA (Supervisar, Evaluar y Valorar):

• MEA01: Supervisar, evaluar y valorar rendimiento y conformidad
65
8.2.5.1. EDM
Para el dominio que es responsabilidad del Gobierno (EDM), se ha activado el proceso EDM04
“Asegurar la Optimización de los Recursos”. Este proceso se ha activado ya que cubre la
necesidad de sacar el máximo rendimiento a aquellos productos que se han adquirido para
mejorar el rendimiento del SI. TapBeverage ha decidido que será el único proceso activo para
este dominio durante el cambio que va a sufrir la corporación porqué considera que es el que
más va a ayudar a la empresa a conseguir el conjunto de metas definidas y ve imprescindible
potenciar al máximo el rendimiento del SI. Para ello el Gobierno asegurará que la corporación
dispone de suficientes capacidades (personas, procesos y tecnología) para alcanzar los objetivos
de la empresa con un coste óptimo.
Las metas del proceso EDM04 son:
• Asegurar que las necesidades de los recursos se satisfacen.
• Conseguir la mejor asignación de los recursos dentro de las limitaciones
presupuestarias.
• Asegurar que los recursos se aprovechan al máximo dentro de su coste económico.
El Gobierno de TapBeverage describirá cuales deben ser las políticas a la hora de asignar los
recursos de la empresa en las diferentes necesidades de la empresa a la hora de llevar a cabo el
Proyecto Trenza. La política será ofrecer prioritariamente los recursos a aquellas actividades que
vayan a tener unos resultados más inmediatos y que ofrezcan un mayor valor.
Para conseguir medir la relación “valor generado/tiempo necesario” se establecerá un
procedimiento que consistirá en listar todas las tareas a desempeñar, comunicárselas al
responsable de su desarrollo y pedirles un informe con la previsión del tiempo necesario para
conseguir terminarlas. Además, el Gobierno y el mismo responsable de la tarea deben informar
de que efectos inmediatos tendrá en el funcionamiento de la empresa, tanto por si misma como
en conjunto con otras tareas relacionadas. Cuando estén todos los informes de las tareas listadas
acabados y comunicados al Gobierno se ordenará las tareas por orden decreciente de su relación
“valor generado/tiempo necesario”. Este procedimiento se deberá repetir varias veces porque
no se listarán en una sola vez todas las tareas necesarias para el Proyecto Trenza, las listas se
crearán según se terminen las tareas de la lista anterior.
Las métricas que se usarán para medir el rendimiento de este proceso serán:
• Porcentaje de tiempo en el que los recursos están en uso.
• Número de tareas terminadas por semana.
8.2.5.2. APO
APO03: Gestionar la arquitectura empresarial:

TapBeverage ha decido que el proceso APO03 de COBIT 5 debería aplicarse, pero, la organización
cree conveniente delegar estas tareas relacionadas con la Arquitectura Empresarial a TOGAF 9.1.
66
APO04: Gestionar la Innovación:
TapBeverage ve a la innovación como un punto clave para conseguir cubrir las necesidades de
los clientes de una manera más rentable económicamente y en términos de esfuerzo. La
organización ve tan importante el uso de las nuevas soluciones como una buena gestión de ellas,
por eso ha considerado necesario activar este proceso.
Las metas que TapBeverage pretende conseguir con este proceso son:
• Crear valor mediante el despliegue de las innovaciones más apropiadas
• Aumentar los beneficios o reducir los costes mediante la implementación de soluciones
innovadoras
• Promover la innovación como parte de la cultura empresarial
TapBeverage va a formar un equipo que pertenece al Departamento de Tecnologías cuya

función será escanear el panorama tecnológico para identificar tecnologías que puedan aportar
valor a la empresa. Este escaneo incluye la investigación del mercado, la competencia y las
tendencias del sector industrial.
El procedimiento que seguirá el equipo configurado para este propósito consistirá en hacer un
análisis de las tecnologías inicialmente propuestas para el nuevo SI de la empresa (etiquetas
RFID, sistemas de geolocalización, PDAs, etc.) en busca de carencias y obsolescencias que
puedan tener, tanto si se encuentran como si no se hará una investigación por los panoramas
externos que concluirá con un informe de lo encontrado con las posibles soluciones tecnológicas
a implementar, en que mejorarían lo inicialmente propuesto, su coste y su potencial de mejora.
Una vez concluido el informe se convocará un comité con los usuarios finales de la empresa y
clientes externos, el jefe de finanzas, el Consejo de Administración y el CEO para acordar cuáles
serán las nuevas soluciones incluidas en el Proyecto Trenza, cuáles excluidas definitivamente y
cuáles se dejan en espera para una futura reconsideración.
TapBeverage ve en este proceso mucho potencial y quiere aprovechar el proyecto en el que está
inmersa la empresa para dejar este equipo funcionando al terminarlo. Para ello se ha diseñado
otro procedimiento. De manera periódica se hará un escaneo de la empresa extremo a extremo,
este escaneó consistirá en hacer un listado de las tecnologías usadas, actualizarlo y guardarlo
para el próximo escaneo. Mantener reuniones con los encargados de técnicos, operadoras,
RRHH, finanzas, etc. De estas reuniones se pretende extraer qué tecnologías son mejorables o
que necesidades están descubiertas, estas reuniones concluirán con un informe de apartados a
mejorar con soluciones tecnológicas. A partir de aquí se seguirá el mismo proceso que en el
procedimiento ideado para el Proyecto Trenza: informe de las soluciones encontradas en el
exterior de la empresa, convocar un comité y clasificar las soluciones tecnológicas propuestas
en las tres posibles categorías.
La métrica que se usará para medir el rendimiento de este proceso será:
• Porcentaje de medidas propuestas que han sido implementadas.
APO07: Gestionar los RRHH:

TapBeverage tiene en especial consideración su activo humano. La importancia que la empresa
le da a los RRHH cobra una nueva dimensión con el Proyecto Trenza dado que va a haber una
restructuración importante de sus empleados y van a sufrir directamente las consecuencias de
67
esta reestructuración. Para mantener un alto rendimiento de los empleados y su satisfacción se

requiere una buena gestión de los RRHH, esta es la razón por la que la organización ha decidido
activar este proceso.
Las metas que se van a conseguir con una buena gestión de los RRHH son:
• Flexibilizar las relaciones y la estructura organizativa de las TI
• Conseguir una gestión eficaz y eficiente de los RRHH
Los puntos en los que TapBeverage quiere incidir en este proceso son mantener el personal
adecuado e identificar el personal clave para las TI.
Para mantener el personal adecuado al terminar el Proyecto Trenza, se va a analizar los
requisitos en cuestión de personal en el caso de que la organización alcance el estado previsto
al final del proyecto. TapBeverage es consciente de que en un proyecto de tal envergadura
surges imprevistos y cambios, por eso se va a crear un procedimiento que se lanzará
bisemanalmente durante el proyecto y quedará activo después del Proyecto Trenza, entonces
se lanzará al final de cada ejercicio fiscal.
En el caso del procedimiento que se lanzará durante la ejecución del proyecto, el departamento
de RRHH analizará la brecha entre el estado actual y el estado esperado y cado dos semanas
analizará los cambios confirmados en el proyecto y ajustará el estado de la plantilla final. Se
realizará un informe con los despidos y las contrataciones recomendadas. En este caso no se
ejecutará ningún despido hasta finalizar el proyecto y previo acuerdo con la alta dirección de la
empresa y el sindicato, en el caso de las contrataciones se hará una evaluación de su urgencia y
decidirá si se efectúan de manera inmediata o se permanece a la espera de terminar el proyecto.
Cuando el proyecto termine, se analizará la brecha entre el estado actual y el del anterior
ejercicio y se realizará un informe en el que debe constar la previsión de la evolución de las
necesidades que va a tener la empresa en cuanto a los recursos humanos. Entonces se
convocará una comisión para analizar las recomendaciones que el departamento de RRHH ha
señalado en el informe y se decidirá sobre ellas. TapBerage quiere evitar al máximo cualquier
tipo de despido, por lo tanto, si se decide que algún trabajador está en un puesto que es
prescindible se buscará otro puesto en el que puede ser reciclado el empleado, el despido
siempre será la última opción.
• Porcentaje de empleados reubicados/reciclados.
• Media de tiempo que permanecen las plazas en estado vacante
• Porcentaje de plazas vacante.
68
APO08: Gestionar las relaciones:
El proyecto en el que está inmersa la organización conlleva un alto coste en TI, que este coste
sea rentabilizado pasa por conseguir que TI y negocio tenga una buena relación y que luchen
por las mismas metas. Esta es la motivación de la activación de este recurso.
Las metas a alcanzar por este proceso son:
• Conseguir una buena relación entre empresa y TI.
• Concienciar a las partes interesadas en el negocio de las oportunidades que ofrecen las
TI.
Se designará una persona del ámbito del negocio encargada de comunicar las tareas y proyectos
en los que el negocio está inmerso a los miembros del ámbito de las TI, se aplicará también en
sentido contrario. La tarea de cada uno de estos encargados o enlaces, aparte de la
comunicación entre sí, será comunicar a los de su propio ámbito lo que le ha comunicado su
homólogo. A parte de para mantenerse informados, se usarán estos enlaces para intercambiar
impresiones y proponer ideas en los proyectos del otro, así se conseguirá una mejor alineación
entre negocio y TI. Para una posterior medición del éxito del progreso se realizarán encuestas
de satisfacción a todos los implicados.
Además, todas las decisiones clave de negocio o TI serán consultadas y consensuadas con
miembros de los dos ámbitos. Así se conseguirá que ambos estén interesados en las actividades
del otro y mantener el interés entre ellos.
• Resultados de las encuestas realizadas.
APO09: Gestionar los acuerdos de servicio:

TapBeverage quiere asegurar que los niveles del servicio de las TI cumplen las expectativas de
lo esperado y de los requisitos definidos por los SLA.
Las metas a cumplir por este proceso son:
• La empresa puede usar los servicios de TI tal y como ha sido acordado.
• Los acuerdos de servicio son acordes con las necesidades de la empresa y las
capacidades de las TI.
• Los servicios de TI cumplen con lo estipulado en los SLA
El procedimiento que se ha creado para este proceso será ejecutado de manera continua
durante el Proyecto Trenza y después se ejecutará trimestralmente.
Se creará un catálogo con los recursos de TI y los servicios que están cubriendo y prestando.
Cada vez que se active este proceso se actualizará este catálogo. Se analizará el nivel de servicio
que se está prestando realmente y se creará un informe. El informe, aparte del nivel de servicio
que se está prestando, incluirá las brechas que existen entre ese nivel de servicio y el acordado
en los acuerdos y SLA. Si se encuentra alguna brecha se comunicará al CEO y decidirá junto a las
partes interesadas las medidas correctivas a tomar.
69

• Porcentaje de servicios analizados que cumplen los niveles de servicio acordados.
8.2.5.3. BAI
BAI04: Gestionar la disponibilidad y la capacidad:

TapBeverage quiere mantener una alta disponibilidad de sus servicios el máximo tiempo posible,
pero una de sus prioridades es la reducción de costes durante el Proyecto Trenza, la empresa ha
activado este proceso para conseguir este propósito.
Las metas para este proceso son:
• Anticipar los requerimientos de capacidad crítica
• Cumplir los requisitos de capacidad, rendimiento y disponibilidad
• Identificar los problemas de disponibilidad, rendimiento y capacidad de manera
sistemática
Este proceso estará continuamente activo durante y después del Proyecto Trenza, ya que
requiere de una monitorización continua.
El Departamento de Tecnologías hará un análisis del rendimiento de los servicios y el tiempo
que se mantienen disponibles, como resultado creará una línea base. Se mantendrá una
monitorización continua de estas características de los servicios y la línea base se usará para
visualizar las desviaciones. Cuando se detecte una desviación anómala se debe investigar las
razones que han provocado este problema e implementar soluciones para el problema raíz.
Además, con una buena monitorización se podrán interpretar la evolución para encontrar
tendencias que hagan anticiparse a problemas, como por ejemplo el llenado de una base de
datos o el crecimiento anómalo de los cursores en el servicio de las PDAs.
• Número de incidentes sobre la disponibilidad de los servicios.
• Porcentaje de tiempo que se encuentran disponibles los servicios.
BAI07: Gestionar la aceptación del cambio y la transición:

Este proceso se ha activado para pasar el las nuevas aplicaciones y servicios de los entornos de
desarrollo y test a producción de manera exitosa. TapBeverage no puede permitirse liberar un
producto que no sea estable o que tenga errores, el paso debe ser lo menos traumático posible.
Las metas para este proceso son:
• Contar con la aceptación de las partes interesadas.
• Puesta a punto de las implementaciones para pasarlas a producción.
• Promover las implementaciones a producción de manera exitosa.
• Catalogar las lecciones aprendidas.
70
La implantación de las nuevas TI pasarán tres fases: desarrollo, test y producción. En el entorno
de desarrollo se implementará e instalará todo lo necesario para que la herramienta esté lista.
El entorno de test servirá para hacer pruebas técnicas y funcionales, de aceptación, de
comunicación entre las aplicaciones y en este entorno se solucionarán los problemas surgidos.
El próximo paso será promocionar a producción los productos conforme vayan estando listos
para su uso. El entorno productivo será una copia exacta del entorno de test, por eso el entorno
de test debe de ser completamente funcional. Al ser un cambio tan radical a todos los niveles
de la organización, el paso de test a producción debe darse con la máxima cantidad de pruebas
realizadas, se acepta el riesgo de que este paso conlleve problemas, pero se debe hacer lo
posible para evitarlos al máximo y no se vayan uniendo unos a otros por pasos a producción
prematuros.
• Número y porcentaje de servicios no promocionados a producción en la fecha
estipulada.
• Porcentaje de fallos en producción dentro del periodo de aceptación.
8.2.5.4. DSS
DSS03: Gestionar los problemas:

TapBeverage pretende atacar los problemas surgidos durante el Proyecto Trenza desde su causa
raíz y aprender de la experiencia para que no vuelvan a repetirse. El valor que quiere generar
con este proceso viene dado por el aumento de la disponibilidad, la reducción de costes al evitar
la recurrencia del mismo problema y la satisfacción del cliente al no verse incordiado por
problemas repetidos.
La meta que se quiere conseguir es:
• Resolver los problemas relacionados con las TI y que no vuelvan a repetirse.
Para implementar este proceso

Cuando se detecte un problema se clasificará según sus características (tecnología a la que
pertenece, gravedad, alcance) y se guardará esta información en la base de datos donde se
guardarán todos los problemas detectados. Según se vaya conociendo tratando el problema se
irá añadiendo información a la base de datos. Cuando esté clasificado, se investigará la causa
del problema y cuando este se identifique se buscarán posibles soluciones. Cuando se solucione
el problema se añadirá a la base de datos la solución aplicada y todo aquello que haya sido
aprendido durante la solución del problema.
• Decrecimiento de problemas recurrentes
• Número de problemas solucionados mediante la subsanación del problema raíz
71
8.2.5.5. MEA
MEA01: Supervisar, evaluar y valorar rendimiento y conformidad:

La organización quiere asegurarse de que los procesos trabajen en todo momento para
conseguir las metas. Además, precisa de un informe que indique en que punto se encuentran
todos los procesos activados. Pretende conseguir transparencia en la ejecución de las tareas e
impulsar el logro de los objetivos.
Las metas fijadas para este proceso son:
• Supervisar correctamente los procesos.
• Mantener un enfoque eficaz sobre la evaluación y supervisión de la empresa.
• Presentar un proceso útil para conseguir informes sobre el rendimiento de las tareas.
Habrá un equipo encargado de ejecutar y analizar todas las métricas del resto de procesos y de
él mismo de manera continua. Los resultados de este análisis deberán usarse para analizar si los
procesos están cumpliendo su propósito y avanzan hacia la consecución de sus metas. Se deberá
valorar si es recomendable continuar con cada uno de los procesos activados, si hay que cambiar
el procedimiento según se están analizando o si hay que eliminarlo. También deberán de decidir
si hay algún proceso que no cumple las expectativas por falta del apoyo de otros procesos que
ofrece COBIT 5 y no están activados. Si se ve necesario se redefinirán las métricas existentes
para los procesos y se crearán nuevas.
• Porcentaje de métricas que cumplen con los requisitos marcados por las partes
interesadas.
• Porcentaje de procesos con las métricas alineadas con las metas.
72
8.3. Aplicación de TOGAF 9.1
8.3.1. Fase Preliminar
El alcance de la organización afectada ya ha sido definido por COBIT 5. Este proyecto, y por tanto
la implementación de la Arquitectura Empresarial y de TOGAF 9.1, va a llegar a todos los niveles
de la empresa, ya que es un cambio general. También se han definido los marcos de referencia
en los que se va a apoyar la organización (TOGAF 9.1, COBIT 5, marcos de la serie ISO 27000 y
SFIA-Skills Framework for the Information Age).
El equipo encargado para la gestión de las actividades de la Arquitectura Empresarial del que
dispondrá TOGAF 9.1 estará formado por las siguientes estructuras organizativas clasificadas por
sus responsabilidades [anexo 8]:
• Encargados: Consejo de Arquitectura (será la organización responsable durante las fases
B, C y D), jefe de Arquitectura y Director de Sistemas Informáticos (CIO)
• Responsables: CEO (tendrá el rol de consultado en las fases B, C y D)
• Consultados: Director General Financiero (CFO), jefe de RRHH, la función de Auditoría,
el jefe de Desarrollo, el jefe de Operaciones de TI y el jefe de Administración de TI.
Aparte de las herramientas generales de las que dispone TapBeverage (equipos informáticos,
información, redes, etc.), la el equipo para la Arquitectura Empresarial también contará con
herramientas específicas para la arquitectura como son:
• Archimate: Herramienta para el modelado de procesos.
• Alfabet Enterprise Architecture Management: Facilitará la toma de decisión sobre la
inversión en TI y reduce los riesgos de transformación en procesos de cambio.
8.3.2. Fase A: Visión Arquitectónica
El análisis de los stakeholders que debe hacerse en esta fase ya lo ha elaborado la organización
en el Principio 1 de COBIT 5, al igual que las metas de negocio. Así que la primera tarea de la que
se encargará esta fase será de la declaración de restricciones. Estas restricciones son el tiempo
para ejecutar el Proyecto Trenza, el nuevo SI debe estar en producción antes de que entre en
vigor la prestación de servicios de TapBeverage a Restaurantes Attic. Otro importante factor que
limita las posibles actuaciones de la organización es el presupuesto del que dispone la empresa
para realizar las actividades necesarias y recursos para el proyecto. La disponibilidad del
personal técnico también es una restricción, ya que los servicios prestados al resto de clientes
no pueden verse mermados y los técnicos deben recibir cursos de formación sobre el nuevo SI.
Las capacidades de la empresa para desarrollar la arquitectura están formadas por las
competencias, habilidades y experiencia del personal que configuran las estructuras
organizativas, aparte las herramientas generales y específicas que apoyan el desarrollo de la
arquitectura. Para la consecución de las metas de la empresa forman parte de las capacidades
la experiencia, habilidades y competencias de toda la plantilla de TapBeverage, la información
disponible, los sistemas y aplicaciones, marcos de referencias y procesos que se han habilitado.
73
La arquitectura que se describirá mediante la aplicación de TOGAF 9 afectará los stakeholders

internos. Esta arquitectura afectará a la información, sistema de la información y a todas sus
infraestructuras.
TapBeverage ha decido que la implementación de la arquitectura no usará la fase G. No cree
necesario incluir en el proyecto la fase G ya que ven el proyecto desde una perspectiva más
cercana a COBIT 5 y consideran que con la fase H ya se cubren todas las prácticas necesarias
desde el punto de vista de COBIT 5.
8.3.3. Fase B: Arquitectura de Negocio
Para identificar los actores que van a tomar parte de los procesos se clasificarán según su puesto
físico de trabajo.
Exterior: Los actores que trabajan fuera de los edificios de TapBeverage son los técnicos, ellos
se mueven entre los almacenes y los lugares donde los clientes han puesto una incidencia. La
actualización de los almacenes se hará de manera automática con la tecnología RFID, pero los
técnicos deberán actualizar el stock que tienen en su furgoneta. Además, hay coordinadores se
encargarán de gestionar las incidencias a nivel de repartir la carga de trabajo entre los
compañeros, estos coordinadores también desempeñan las funciones de los técnicos.
Oficina: El personal que atiende las llamadas de atención al cliente y gestionan las incidencias
que entran mediante el SGI. Esta parte del personal de la oficina también se encargará de la
resolución de las incidencias que puedan resolver los propios clientes por teléfono.
También se encuentran los encargados de administración de sistemas, los trabajadores que
llevan el mantenimiento de los servidores, base de datos, etc.
Almacén: La plantilla encargada de gestionar y llevar el mantenimiento de los almacenes de la
empresa. Ayudarán a descargar material a los técnicos y a mantener los almacenes ordenados
y preparar partidas de material. Solo en el almacén central habrá personal de manera continua.
Ilustración 14. Actores de TapBeverage

Los procesos que siguen los técnicos a la hora de resolver incidencias y los empleados de la
gestión de incidencia están descritos en el caso de estudio.
74
Ilustración 15. Funciones de los actores
En la modelación cabe destacar que no aparecen los trabajadores de los almacenes ni
administradores de sistemas ya que no interactúan en proceso de atención de incidencias.
También cabe destacar que con el nuevo SI la actualización del stock de los almacenes es
automática y no representa una actividad como si lo hace la actualización del stock de la
furgoneta.
La línea base que tomará la organización será la existente. La Arquitectura de Negocio no varía
mucho con la objetivo. Las principales diferencias se encuentran en la atención de las incidencias
por parte de los técnicos, después del proyecto tendrán la posibilidad de encontrar un
compañero cercano mediante la aplicación de la PDA y no deberá de preocuparse por la
actualización del stock en el almacén. El resto de las operaciones de negocio no varían de
manera notable.
La Hoja de Ruta que va a seguir TapBeverage para llegar a la arquitectura objetivo será:
• Informar de la nueva manera de trabajar a los afectados, principalmente a los técnicos.
• Formar a los técnicos sobre la nueva metodología en la atención de incidencias.
• Hacer posible el funcionamiento de los recursos tecnológicos mediante la instalación y
puesta a punto de SGI, RFID, BBDD, etc. (Este paso se atenderá con más detalle en las
Arquitecturas de Sistema de la Información y Tecnológica).
• Mientras los servicios de PDAs y del nuevo SGI están en fase de test se crearán manuales
para los clientes y a la vez se usarán para formar a los técnicos en el uso del nuevo
sistema de PDAs, SGI y almacenes.
8.3.4. Fase C: Arquitectura del Sistema de Información
El SI va a diferenciar entre los componentes del SI que usan los clientes (portal del SGI para
clientes) y los que usan los empleados de TapBeverage. Dentro de los componentes que usan
los propios empleados de la organización se diferenciará entre las aplicaciones funcionales
75
(portal del SGI para los empleados y PDAs) y las que dan soporte técnico (base de datos y
servidores de aplicaciones).
Ilustración 16. Aplicaciones TapBeverage

En la modelación se observa como el gestor de la BBDD es usada por las aplicaciones funcionales
y que la PDA está usa aplicaciones instaladas en los servidores de TapBeverage.
La diferencia entre la arquitectura base y la objetivo es el cambio de las herramientas usadas: el
SGI será diferente, la BBDD estará unificada y la aplicación de las PDA será totalmente nueva.
La Hoja de Ruta para pasar del SI antiguo al nuevo será:
• Configurar los servidores necesarios para albergar las aplicaciones y herramientas
necesarias (instalación de SO, SOA, balanceadores de carga, etc.).
• Instalar las aplicaciones que se usarán en las PDAs (la versión del SGI para las PDAs, la
aplicación de geolocalización etc.).
• Crear y unificar la base de datos.
• Instalar los gestores de BBBDD.
• Pasar todos los servicios de aplicaciones a los servidores propios de TapBeverage,
pasando los servicios que están subcontratados a lo propios.
• Diseñar e implementar el nuevo SGI, se vinculará con la base de datos unificada para
poder acceder a todos los clientes, mejores prácticas para los técnicos, material de los
almacenes, etc.
8.3.5. Fase D: Arquitectura Tecnológica
En TapBeverage hay configurada redes LAN en las oficinas y en los almacenes para comunicar
los equipos que hay dentro entre ellos. Además, hay una WAN que comunica PDAs, oficina y
almacenes entre sí. Las comunicaciones que hay antes de la conclusión del Proyecto Trenza y las
que habrá al terminarlo no difieren mucho, la diferencia erradica en la cantidad de redes LAN
que hay.
76
Ilustración 17. Tecnologías de la información
La diferencia entre la Arquitectura Tecnológica base y objetivo erradica en que todos los
componentes de ella son propiedad de Tapbeverage, la existencia de una LAN en los almacenes
para poder comunicar los equipos de los empleados con los componentes de la RFID y una WAN
única en la que no intervienen elementos externos a los de Tapbeverage como eran los
subcontratados.
La Hoja de Ruta a seguir en este caso será simple, se creará una nueva configuración para todas
las redes LAN y para la red WAN. En este proceso se eliminarán de estas redes almacenes y
oficinas obsoletas como la de Madrid y se incluirán en ellas las comunicaciones necesarias para
la tecnología de las etiquetas RFID.
8.3.6. Fase E: Oportunidades y soluciones
Llegada esta fase la organización dispone de las Hojas de ruta de las Arquitecturas de Negocio,
Sistema de Información y Tecnológica. Ahora TapBeverage pretende crear una Hoja de Ruta
general que englobe el trabajo hecho en las fases B, C y D.
Los pasos a seguir que marca la Hoja de Ruta son:
• Preparar los servidores necesarios para albergar las aplicaciones y herramientas
necesarias. Esto implica tareas como la instalación de sistemas operativos o
herramientas para balancear la carga de los servidores.
• Configurar las redes LAN que comunicarán los equipos de cada edificio entre ellos, estas
redes no ofrecerán la intercomunicación entre edificios diferentes.
• Unificar las dos bases de datos existentes en una.
• Implementar en la cadena de trabajo las herramientas tecnológicas para los servicios
del nuevo SI. Cómo por ejemplo los sensores para las etiquetas RFID en los almacenes y
las PDAs de los técnicos.
• Implementar todos los servicios de aplicaciones a los nuevos servidores de
TapBeverage. Instalando en ellos las aplicaciones que darán servicio a las PDAs, a la
tecnología RFID, etc.
• Implementar el nuevo SGI para la gestión de las incidencias.
• Preparar el nuevo SGI, se vinculará con la base de datos unificada para poder acceder a
todos los clientes, mejores prácticas para los técnicos, material de los almacenes, etc.
• Mientras los servicios de PDAs y del nuevo SGI están en fase de test se crearán manuales
para los clientes y a la vez se usarán para formar a los técnicos en el uso del nuevo
77
sistema de PDAs, SGI y almacenes, al igual que los de atención de incidencias se les
formará para saber usar correctamente el SGI.
• Preparar el nuevo SGI, se vinculará con la base de datos unificada para poder acceder a
todos los clientes, mejores prácticas para los técnicos, material de los almacenes, etc.
• Configurar la red WAN para que todos los servicios estén comunicados entre sí (PDAs,
equipos de almacenes, tecnología RFID, etc.)
Por razones técnicas se ha decidido cambiar el orden de algunos de los pasos a tomar según se
habían definido en las fases anteriores.
8.3.7. Fase F: Planear la Migración
Se tomará como Hoja de Ruta la descrita en la Fase E. En esta fase se definirá el plan que
TapBeverage tiene para no dejar de dar servicio a los clientes durante la ejecución de Proyecto
Trenza.
Mientras se ejecute el proyecto todas las funciones del antiguo SI seguirán funcionando. Eso
elevará el coste ya que se necesitarán más recursos tecnológicos, pero TapBeverage considera
que es una forma de potenciar la satisfacción de los clientes.
Ilustración 18. Transacciones de la migración

Se recomienda instalar antes el hardware necesario, pero puede empezarse con la preparación
de los servidores y la unión de la BBDD.
8.3.8. Fase H: Gestión del cambio de la arquitectura
Durante la fase en la que el proyecto tenga los servicios en test se trabajará en este entorno con
datos reales de los clientes. Una vez el SI esté en producción, las dos arquitecturas seguirán
conviviendo y TapBeverage irá incluyendo progresivamente los clientes en el nuevo, de esta
manera el impacto en el negocio en caso de errores inesperados será menor.
78
79
9. Valoración económica
9.1. DIAGRAMA DE GANTT
Según los recursos y plazos existentes se ha diseñado el siguiente diagrama de Gantt para el
seguimiento del Proyecto Trenza.
Ilustración 19. Diagrama de Gantt

Se han incluido las tareas que tienen incidencia directa en la implantación del nuevo SI. Existen
otros procesos que se ejecutan durante y después del proyecto como las monitorizaciones, pero
no están incluidos ya que no forman parte de las tareas concretas de instalación.
La formación de los técnicos y operadores van a cargo de un empleado que se encarga de la
parte funcional de las aplicaciones. La formación de los técnicos es de media jornada, la tarea
se representa como una jornada completa ya que participa media plantilla en dos turnos
diferentes para no desatender las incidencias completamente, el curso se imparte de manera
presencial pero los empleados que no se encuentran cerca de las oficinas pueden hacerlo a
80
distancia. La formación de los operadores sigue la misma dinámica, pero dura una jornada
completa, la mitad de la plantilla lo hace un día y la otra a la siguiente jornada.
9.2. PRESUPUESTO
A continuación, se muestra la tabla de trabajadores que participan en el proyecto para la

instalación del nuevo SI. Existen más trabajadores, como los mozos de almacén, pero estos no
toman parte en las tareas del proyecto, aunque se vean afectados por los cambios.
Cargo €/hora Empleados

CEO 21 1
Consultor arquitectura 19 1
Jefe desarrollo 19 1
Jefe de operaciones TI y de administración TI 19 1
Jefe arquitectura 19 1
CFO 19 1
CIO 18 1
Empleados depto. Legal 13 2
Desarrollador 11,25 4
Administrador de sistemas 11 3
Funcionales 11 3
Empleados RRHH 10 3
Operadores 8 4
Técnicos 7 60
Empresa instalación RFID 20 -
Tabla 6. Honorarios de los trabajadores
El coste total de la mano de obra del proyecto es de 34.070€. Se ha incluido el coste del tiempo
de los empleados que desempeñan tareas, el coste de la empresa que instala el hardware de la
tecnología RFID y el tiempo de los operadores y técnicos usado para su formación.
El coste en tiempo de cada paquete de tareas y su costo económico viene determinado por el
siguiente informe.
81
Ilustración 20. Informe costos de las tareas

Aparte del coste de mano de obra de los trabajadores de la empresa y del equipo de instalación
del hardware de RFID hay que tener en cuenta los productos adquiridos. La aplicación para las
PDAs tiene un coste de 8.750€ y el coste total de la adquisición las PDAs para cada técnico de
20.000€. El hardware instalado en los almacenes para la tecnología RFID, las etiquetas
necesarias y el software suma 7.850€, la mano de obra para instalarlo va aparte y se tiene en
cuenta en el apartado de coste de mano de obra, TapBeverage es el encargado de instalar el
software.
TapBeverage necesita que varios de sus empleados se certifiquen en COBIT 5 y comprar las guías
para implantarlo. El coste de los cursos y exámenes es de 4.500€ y la documentación 800€, un
total de 5.300€.
TapBeverage ha optado por herramientas gratuitas para modelar la Arquitectura Empresarial y
BPMN.
Sumando todos los costes el Proyecto Trenza tiene un coste de 75.970 €.
Mano de obra 34.070 €

Aplicación PDA 8.750 €
PDAs 20.000 €
RFID 7.850 €
COBIT 5 5.300 €
TOTAL 75.970 €
Tabla 7. Coste del Proyecto Trenza
82
83
10. Conclusiones
10.1. Consideraciones finales
Durante el desarrollo del trabajo se ha analizado de forma general los marcos de COBIT 5 y
TOGAF 9.1. Para ello se han analizado los aspectos más importantes de cada uno de ellos y luego
ha sido necesario profundizar en los detalles de cada uno
Para su análisis ha sido necesario identificar que aportaba el uno al otro. COBIT 5 considera
dentro de su marco la Arquitectura Empresarial en un proceso en concreto, por ello se ha
identificado ese punto como el que une a ambos marcos, centrando en él el análisis de ambos
estándares.
La empresa protagonista del caso de estudio es una empresa ficticia, se ha escogido un caso que
no fuese real por la dificultad de encontrar una empresa con un proyecto adecuado para realizar
el trabajo y permitiese publicar sus datos. La empresa está basada en casos conocidos en mi
ámbito laboral y el caso de estudio ha sido construido a partir de otros casos analizados durante
el desarrollo del trabajo y el grado.
Para la aplicación de los marcos se ha procurado atender el mayor número de aspectos
explicados en la parte teórica del trabajo. Ha sido imposible abarcar toda la envergadura de los
marcos, tanto en la fase de teoría como en la de aplicación, porque el trabajo sería de una
complejidad y extensión demasiado elevada.
La valoración económica se ha realizado de modo que todos los gastos estuviesen justificados.
Para ello se ha utilizado una aplicación para la gestión de proyectos, obteniendo de ella el
diagrama de Gantt que se presenta y facilitando el cálculo de los gastos de mano de obra.
Por último, se ha respaldado el trabajo realizado con un diagrama BPMN y el cuadro de mando
que la empresa pretende implementar con el objetivo de mostrar de una manera más visual
como trabaja la organización.
10.2. Posibles mejoras
Las posibles mejoras son muchas, como ya se ha mencionado este trabajo podría tener una
extensión mucho mayor, por ello se han dejado para futuros trabajos.
La parte teórica puede ser tan extensa como cada uno de los marcos. Cabe, por ejemplo, definir
más y mejor las prácticas de cada proceso de COBIT 5 y las estructuras organizativas que se
activan en cada uno de ellos. En TOGAF se puede describir todo aquello que queda fuera del
ciclo ADM y describir la gestión de requerimientos. Para que esto tuviese sentido sería necesario
disponer de un caso práctico más detallado y profundizar mucho más en su aplicación práctica.
Varios puntos de mejora en el apartado de teoría han sido eliminados ya que no se han
implementado en la práctica al aumentar demasiado la extensión y complejidad del trabajo.
En el apartado de la aplicación se podría definir de una manera más extensa y concreta las
dimensiones de los catalizadores, principalmente las buenas prácticas. También cabe describir
84
los SLA de la empresa con sus stakeholders, implementar y explicar el ciclo de vida de COBIT 5,
entrar en más detalle en cada una de las fases del ciclo ADM de TOGAF 9.1. Así como concretar
cada práctica de cada proceso activado descrito la publicación “Enabling Processes” de COBIT 5.
En definitiva, podría aumentarse la complejidad y el detalle de cada uno de los apartados del
trabajo, esto pude darse en trabajos con un mayor alcance o en organizaciones que necesiten
aplicar estos dos marcos en un caso real.
85
86
11. Bibliografía
COBIT 5
1. ISACA. Enabling Processes. Rolling Meadows, Illinois USA. 2012.
2. ISACA. Un Marco de Negocio para el Gobierno y la Gestión de las TI de la Empresa. Rolling

Meadows, Illinois USA. 2012.
3. Carlos Alberto Martínez Ramírez. COBIT 5 – Proceso de Gobierno de TI Empresarial –

Evaluar, Orientar y Supervisar. 15 agosto de 2014. Consultado en agosto de 2017.
Disponible en: http://cam2149.blogspot.com.es/2014/08/cobit-5-proceso-de-gobierno-de-
ti.html
4. Carlos Alberto Martínez Ramírez. COBIT 5 – Alinear, Planificar y Organizar (APO). 15 agosto
de 2014. Consultado en agosto de 2017. Disponible en:
http://cam2149.blogspot.com.es/2014/08/alinear-planificar-y-organizar-apo-01.html
5. Carlos Alberto Martínez Ramírez. COBIT 5 – Construir, adquirir e implementar (BAI). 15

agosto de 2014. Consultado en agosto de 2017. Disponible en:
http://cam2149.blogspot.com.es/2014/08/cobit-5-construir-adquirir-e.html
6. Carlos Alberto Martínez Ramírez. COBIT 5 – Entrega, Servicio y Soporte (DSS). 15 agosto de
2014. Consultado en agosto de 2017. Disponible en:
http://cam2149.blogspot.com.es/2014/08/cobit-5-entrega-servicio-y-soporte-dss.html
7. Carlos Alberto Martínez Ramírez. COBIT 5 – Supervisar, Evaluar y Valorar (MEA). 15 agosto
de 2014. Consultado en agosto de 2017. Disponible en:
http://cam2149.blogspot.com.es/2014/08/cobit-5-supervisar-evaluar-y-valorar-mea.html
8. ISACA®. ISACA® Glossary of Terms. Consultado en mayo 2017. Disponible en:

https://www.isaca.org/Knowledge-Center/Documents/Glossary/glossary.pdf
9. Gonçalo Rodrigues Cadete. Using Enterprise Architecture for COBIT 5 Process Assessment
and Process Improvement. Noviembre 2015. Consultado en agosto de 2017. Disponible en:
https://fenix.tecnico.ulisboa.pt/downloadFile/563345090413909/Master-Thesis-33851-
%20Goncalo%20Rodrigues%20Cadete.pdf
87
10. Alfonso Mateluna. Auditoría al gobierno de TI usando COBIT 5. 23 de septiembre de 2014.

Consultado en agosto de 2017. Disponible en
http://www.isaca.org/chapters10/Santiago/Educacion/Documents/AUDITANDO%20EL%20
GOBIERNO%20DE%20TI_ISACA_SANTIAGO%202014.pdf
11. ISACA. Mapping to COBIT 5. Consultado en agosto de 2017. Disponible en:
http://www.isaca.org/certification/cgeit-certified-in-the-governance-of-enterprise-
it/prepare-for-the-exam/mappin-to-cobit/pages/default.aspx
TOGAF
12. Josey Andrew et al. TOGAF Versión 9.1: guía de bolsillo. Primera edición. Zaltbommel: Van
Haren Publising. Abril 2013.
13. The Open Group. TOGAF® 9.1. Octubre de 2008. Consultado en abril 2017 Disponible en:
http://pubs.opengroup.org/architecture/togaf9-doc/arch/
14. Diego Fernando Ruíz Sánchez. Diseño de arquitectura empresarial en el sector educativo
colombiano: caso colegio privado en Bogotá. 2014. Consultado en agosto de 2017.
Disponible en:
http://repository.ucatolica.edu.co/bitstream/10983/1691/1/Trabajo%20de%20Grado%20
Arquitectura%20Empresarial.pdf
15. The Open Group. TOGAF® 9.1 Translation Glossary: English – Castilian Spanish. Octubre
2014. Consultado en abril de 2014. Disponible en:
https://publications.opengroup.org/c149
COBIT & TOGAF
16. Önder Aykurt. Analyse in Relation between ITIL, COBIT, CMMI and TOGAF. 27 de marzo de
2015. Consultado en julio 2017. Disponible en:
https://onderaykurt.wordpress.com/2015/03/27/analyse-in-relation-between-
itilcobitcmmi-and-togaf/
17. Danny Greefhorst. TOGAF & Major IT Frameworks, Architecting the Family. Consultado en
mayo 2017 febrero 2013. Disponible en:
http://mailing.itpreneurs.com/Newsflash/TOGAF/Whitepaper-Architecture-with-
TOGAF.pdf
88
18. BPMUtils Marketing. Connecting the dots between Cobit, Togaf & Agile. Enero de 2017.
Consultado en agosto de 2017. Disponible en:
https://bpmutils.atlassian.net/wiki/spaces/BPMUT/pages/53084163/Connecting+the+dots
+between+Cobit+Togaf+Agile
19. Stuart Macgregor. COBIT 5 and TOGAF® 9. EA Governance Made Practical. 2011.
Consultado en agosto de 2017. Disponible en:
http://opengroup.co.za/sites/default/files/presentations/SM%20-%20presentation_0.pdf
Modelación
20. Rafael Almeida, Pedro Linares Pinto, Renato Lourinho, Miguel Mira da Silva, Ph.D. Using
Visual Models for Adopting IT Governance Practices. 20 de marzo de 2017. Consultado en
mayo de 2017. Disponible en :http://www.isaca.org/Groups/Professional-English/cobit-5-
use-it-effectively/Pages/ViewDiscussion.aspx?PostID=817
21. Rafael Almeida, Pedro Linares Pinto, Miguel da Silva. Using ArchiMate to Assess COBIT 5
and ITIL Implementations. 2016. Consultado en mayo de 2017. Disponible en:
http://aisel.aisnet.org/cgi/viewcontent.cgi?article=1120&context=isd2014
22. Denis Gangné y Simon Ringuette. BPMN Quick Guide. Consultado en agosto de 2017.
Disponible en: http://www.bpmnquickguide.com/view-bpmn-quick-guide/
Sectores
23. Francisco Javier Cárcel Carrasco. Análisis del sector del mantenimiento en relación a
estudios sectoriales. Diciembre 2015. Consultado en agosto de 2017. Disponible en:
https://www.3ciencias.com/wp-content/uploads/2015/12/An%C3%A1lisis-del-sector-del-
mantenimiento-en-relaci%C3%B3n-a-estudios-sectoriales.pdf
24. Mapal. Estadísticas sobre el sector de la restauración en España. Consultado en agosto de

2017. Disponible en: http://mapalsoftware.com/estadisticas-sobre-sector-de-la-
restauracion-espana/
89
25. Javier Salvatierra. Las cadenas de restauración crecen un 7,8% mientras el resto del sector
frena. 8 de febrero de 2017. Consultado en agosto de 2017. Disponible en:
https://economia.elpais.com/economia/2017/02/08/actualidad/1486545881_497929.htm
l
90
91
11. Anexo
1. Metas Corporativas de COBIT 5 2
2. Metas relacionadas con las TI 2
92
3. Mapeo entre las Metas Corporativas de COBIT 5 y las metas Relacionadas con las TI 2
93
4. Mapeo entre las Metas Relacionadas con las TI de COBIT 5 y los Procesos 2
94
Mapeo entre las Metas Relacionadas con las TI de COBIT 5 y los Procesos (Continuación)
95
5. Mapeo entre las Metas Corporativas de COBIT 5 y las Preguntas del Gobierno y la Gestión 2
96
Mapeo entre las Metas Corporativas de COBIT 5 y las Preguntas del Gobierno y la Gestión
(Continuación)
97
6. Ciclo de la Información 2
98
7. Roles y estructuras organizativas de COBIT 5 2
Roles y estructuras organizativas de COBIT 5 (Continuación)
99
8. Matriz RACI APO03 1
R: Encargado
A: Responsable
C: Consultado
I: Informado
100
9. Gestión recepción incidencias (BPMN)
101
10. Cuadro de mando propuesto para el nuevo SGI
Este es el cuadro de mando propuesto. A la izquierda queda la monitorización de las incidencias.

1. Número de incidencias resueltas, creadas y las que han sido resueltas en el mismo día de su
creación.
2. Número de incidencias pendientes.
3. Porcentaje de incidencias creadas y resueltas el mismo día en la última semana.
4. Lista de las incidencias más antiguas sin resolver.
5. Fecha y hora de la última actualización de los datos que se muestran.
6. La cantidad de técnicos ocupados sobre el total, se ha usado este formato para mostrarlos ya
que no todos los días se dispone del mismo número de técnicos.
7. Las tres piezas más escasas en los almacenes.
8. Botón que dirige a información más detallada.
102

SALA - Analisis Comparativo Entre COBIT 5 y TOGAF 9.1 para Su Aplicacion de Forma Integrada

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

SALA - Analisis Comparativo Entre COBIT 5 y TOGAF 9.1 para Su Aplicacion de Forma Integrada

Cargado por

Copyright:

Formatos disponibles

Escuela Técnica Superior de Ingeniería Informática

Universitat Politècnica de València

Análisis comparativo entre COBIT 5 y TOGAF 9.1

Trabajo Final de Grado

Autor: Sala Pérez, Rubén

A María y a Dani por soportar mi compañía y sudar junto a mí este TFG.

A Pedro Martínez por enseñarme que nunca hay que rendirse.

A Llanos por orientarme en este trabajo cuando más perdido estaba.

Keywords: COBIT 5, TOGAF 9.1, IT Governance, Enterprise Architecture

1.3. Estructura de la memoria

El objetivo de COBIT 5 es proporcionar un marco integral para ayudar a las organizaciones a

Los beneficios2 de usar COBIT 5 son:

COBIT 5 está estructurado en cinco principios:

Ilustración 1. Principios de COBIT5

Las organizaciones tienen una gran cantidad de

2.3. Principio 2: Cubrir la Organización de Forma Integral (extremo-a-

COBIT 5 tiene una perspectiva global de la Organización, y se centra en la gestión y el gobierno

Ilustración 3. Gobierno y Gestión en COBIT 5

En la figura se observan los componentes del sistema de Gobierno extremo-a-extremo que

Ilustración 4. Roles, actividades y relaciones

2.4. Principio 3: Aplicar un Marco de referencia único Integrado

2.5.1. Catalizadores COBIT 5

Ilustración 5. Catalizadores Corporativos COBIT 5

2.5.2. Gobierno y Gestión Sistémicos Mediante Catalizadores Interconectados

Las empresas deberían tener estructurado un conjunto de catalizadores interconectados. Cada

2.5.3. Dimensiones de los Catalizadores de COBIT 5

Ilustración 6. Catalizadores genéricos COBIT 5

2.6. Principio 5: Separar el Gobierno de la Gestión

COBIT 5 define Gobierno y gestión de maneras totalmente diferentes e independientes. Cada

Ilustración 7. Áreas clave de Gobierno y Gestión de COBIT 5

Cada uno de estos dominios tiene los siguientes procesos:1 4 5 6 7

DSS: Entregar, dar Servicio y Soporte

DSS04 Gestionar la continuidad: Mantener la disponibilidad de la información y los servicios y

MEA: Supervisar, Evaluar y Valorar

Ilustración 8. ADM de TOGAF 9.1

3.2. FASE PRELIMINAR

• Definir la relación entre la gestión de marcos.

Ilustración 9. Marco de gestión para coordinar TOGAF

Además, deberá incluir un catálogo de principios.

3.3. FASE A: Visión Arquitectónica

Ilustración 10. Escenario de Negocio

Para el desarrollo de la descripción de la línea base la empresa deberá incluir la descripción de

- La capacidad de la arquitectura define los parámetros, estructuras y procesos que

Ilustración 11. Esquema del repositorio de arquitectura

Describe el desarrollo de arquitecturas de sistemas de información para un proyecto de

La Fase C es una combinación entre el desarrollo de la Arquitectura de Datos y la Arquitectura

Enfoque de la arquitectura de datos

Tanto la Arquitectura de Datos como la Arquitectura de Aplicaciones se basan en la Arquitectura

3.6. Fase D: Arquitectura Tecnológica

En esta fase se describe como desarrollar la Arquitectura Tecnológica para un proyecto de

3.7. Fase E: Oportunidades y Soluciones

La fase F se centra en la creación de un plan de Implementación y de Migración con la

3.9. Fase G: Implementación del Gobierno

3.10. Fase H: Gestión del cambio de la arquitectura

En la fase H, TOGAF 9, se centra en establecer los procedimientos necesarios para gestionar el

Procesos de gestión del cambio de la Arquitectura Empresarial:

• Cambio de reestructuración de la arquitectura (Re-architecting change): este tipo de

Existen ciertas directrices (reglas de oro) para el mantenimiento frente al rediseño de la

Fases y actividades de TOGAF 9 Procesos y prácticas de COBIT 5

TapBeverage es una empresa dedicada a la instalación y mantenimiento de surtidores de

Ilustración 12. Línea base del rendimiento inmediato

Para el tiempo de respuesta se ha marcado el objetivo de bajar de las 13 horas en un año,

Ilustración 13. Línea base del tiempo de respuesta