7 Dias Con ITIL Spa

Conviértase en
ITIL®
4
Fundación
certificada en 7
días
Comprender y
prepararse para el
examen básico de ITIL
con ejemplos de la vida
real
Segunda edicion
Abhinav Krishna Káiser

Obtenga la certificación ITIL® 4 Foundation en 7 días: comprenda y prepárese
para el examen ITIL Foundation con ejemplos de la vida real
Abhinav Krishna Káiser
Staines, Reino Unido
ISBN-13 (pbk): 978-1-4842-6360-0 ISBN-13 (electrónico): 978-1-4842-6361-7

https://doi.org/10.1007/978-1-4842-6361- 7
Copyright © 2021 por Abhinav Krishna Kaiser

Esta obra está sujeta a derechos de autor. Todos los derechos están reservados por el Editor, ya sea total
o parcialmente el material, específicamente los derechos de traducción, reimpresión, reutilización de
ilustraciones, recitación, radiodifusión, reproducción en microfilmes o de cualquier otra forma física, y
transmisión o almacenamiento de información. y recuperación, adaptación electrónica, software de
computadora, o por metodología similar o diferente ahora conocida o desarrollada en el futuro.
En este libro pueden aparecer nombres, logotipos e imágenes de marcas registradas. En lugar de
utilizar un símbolo de marca comercial con cada aparición de un nombre, logotipo o imagen de marca
registrada, utilizamos los nombres, logotipos e imágenes solo de manera editorial y en beneficio del
propietario de la marca comercial, sin intención de infringir la marca comercial.
El uso en esta publicación de nombres comerciales, marcas registradas, marcas de servicio y términos
similares, incluso si no están identificados como tales, no debe tomarse como una expresión de
opinión sobre si están o no sujetos a derechos de propiedad.
Si bien se cree que los consejos y la información de este libro son verdaderos y precisos en la fecha de
publicación, ni los autores ni los editores ni el editor pueden aceptar ninguna responsabilidad legal por
los errores u omisiones que puedan cometerse. El editor no ofrece ninguna garantía, expresa o
implícita, con respecto al material contenido en este documento.
Director general, Apress Media LLC: Welmoed Spahr
Editor de adquisiciones: Celestin Suresh John
Editora de desarrollo: Laura Berendson
Editora coordinadora: Aditee Mirashi
Portada diseñada por eStudioCalamar
Imagen de portada diseñada por Freepik (www.freepik.com)
ITIL® es una marca comercial (registrada) de AXELOS Limited. Reservados todos los derechos.
Distribuido al comercio de libros en todo el mundo por Springer Science+Business Media New York,
1 New York Plaza, Suite 4600, Nueva York, NY 10004-1562, EE. UU. Teléfono 1-800-SPRINGER,
fax (201)
348-4505, envíe un correo electrónico a orders-ny@springer-sbm.com o visite
www.springeronline.com. Apress Media, LLC es una LLC de California y el único miembro
(propietario) es Springer Science + Business Media Finance Inc (SSBM Finance Inc). SSBM Finance
Inc es una corporación de Delaware .
Para obtener información sobre las traducciones, envíe un correo electrónico a
booktranslations@springernature.com; para reimpresión, edición en rústica o derechos de audio, envíe
un correo electrónico a bookpermissions@springernature.com.
Los títulos de Apress se pueden comprar al por mayor para uso académico, corporativo o promocional.
Las versiones y licencias de libros electrónicos también están disponibles para la mayoría de los
títulos. Para obtener más información, consulte nuestra página web de ventas masivas de libros
electrónicos e impresos en www.apress.com/bulk-sales.
Cualquier código fuente u otro material complementario al que haga referencia el autor en este libro
está disponible para los lectores en GitHub a través de la página del producto del libro, ubicada en
www.apress.com/978-1-4842-6360-0. Para obtener información más detallada, visite
www.apress.com/source-code.
Impreso en papel libre de ácido
Dedicado a mi esposa Radhika y mis hijos Anagha

y Aadwik, quienes soportaron varias horas lejos de
mí durante el “tiempo en familia”.
Tabla de contenido
Acerca del autor xvii Acerca del revisor técnico xix Prefacio
xxi Introducción xxv
Día 1 1
Capítulo 1: Introducción al Nuevo ITIL 3
¿Por qué ITIL 4?4
ITIL V3 no era para la era digital 4 Aparición de DevOps 5 Ciclo de
vida del servicio incompatible 7
ITIL reinventado 9
Breve historia de ITIL 10
ITIL V3 e ITIL 4: las diferencias 11 El ciclo de vida del servicio
está muerto 12 Introducción a las prácticas 12 El servicio
tiene una nueva definición 13 La gobernanza es un niño
nuevo en el bloque 14
La automatización está en 14
Jerarquía de certificación de ITIL 4 15 Profesional de gestión de
ITIL 16 Líder estratégico de ITIL 16
Maestro ITIL 17
Certificación básica de ITIL 17
Criterios de elegibilidad 18
Examen de Certificación 19
Capitulo 2: Breve descripción general de DevOps 21

Qué es exactamente DevOps22 DevOps explicado con un
ejemplo 23 Por qué DevOps 25 Una nota sobre el alcance de
DevOps 27
v
Tabla de contenido
Beneficios de transformarse en DevOps 28

Principios de DevOps 29 Cultura 30 Automatización 31 Lean 32
Medición 33
Compartir 34
Elementos de DevOps 34 Personas 37
Proceso 39
Tecnología41
Prácticas de DevOps 41 Integración continua 41 Entrega
continua 44 Implementación continua 46
Entrega continua frente a implementación continua 47
¿DevOps es el fin de las operaciones? 48
Día 2 51
Capítulo 3: ITIL 101: Conceptos y fundamentos básicos 53
Gestión de servicios 54
Productos y Servicios 55
Organización 59
Roles de personas 61
Definición de valor 63 Resultados 66 Costos 67
Riesgos 69
Utilidad y Garantía 73
Ofertas de servicios 80
Relaciones de servicio 83 Prestación de servicios 84 Consumo
de servicios 86
Modelo de Relación de Servicio 87
Prueba de conocimientos 88
Capítulo 4: Enfoque holístico de la gestión de servicios:
vi
Tabla de contenido
cuatro dimensiones 91
Las cuatro dimensiones 92
Organizaciones y personas 94 Estructuras organizativas a vista
de pájaro 95 ¡No solo estructuras, también cultura! 96 Roles
de las personas y sus responsabilidades 97 El liderazgo
importa 100
Todos los caminos conducen al valor 100 Información y
tecnología 101 TI para servicios reales 101 TI para gestión de
servicios 102
Consideraciones para la Información 103
Consideraciones para la tecnología 105
Socios y Proveedores 108
Diferenciando Socios y Proveedores 108 Organización
Estrategia para la Apuesta por Socios y Proveedores 110
Introducción a la integración y gestión de servicios 111
Procesos y flujos de valor 112
Descifrando flujos de valor 112
Simplificando Procesos 114
MAJA 116
Factores políticos 116 Factores económicos 117 Factores
sociales 118 Factores tecnológicos 118 Factores legales 118
Factores ambientales 119
Verificación de conocimientos 119 Día 3 121
Capítulo 5: Creación de valor con el sistema de valor del

servicio 123
Introducción al sistema de valor del servicio 124 Oportunidad y
demanda 127
Gobernanza 129
vii
Tabla de contenido
Cadena de valor del servicio 130 Planificar 134 Participar 136

Mejorar 139
Diseño y transición 141 Obtener/construir 144
Entregar y apoyar 147
Prueba de conocimientos 151
Capítulo 6: Influir a través de principios rectores 153

Centrarse en el valor 157 Comprender al consumidor del servicio
158 Comprender las perspectivas del consumidor del servicio
159 Obtener retroalimentación del cliente 160
Aplicación de los principios/aprendizajes 161
Comience donde se encuentra 162 Evalúe el estado actual 163
Mida todo 164
Progreso iterativo con retroalimentación 167 Importancia de la
retroalimentación 168 Iteraciones de alimentación de
retroalimentación 169
Colaborar y promover la visibilidad 172 Socios de colaboración
173 Medios de comunicación 175 Expandir la visibilidad 176
Piense y trabaje holísticamente 178
Manténgalo simple y práctico 180 Qué dejar de lado, qué
conservar 180 Facilitadores de la simplicidad y el
pragmatismo 182
Optimizar y Automatizar 184
viii
Tabla de contenido
Prácticas de optimización 185 Prácticas de automatización

186
Verificación de conocimientos 188
Capítulo 7: Gestión de Prácticas de ITIL 191

Categoría de Prácticas 192 Prácticas Generales de Gestión 192
Prácticas de gestión de servicios 194
Prácticas de Gestión Técnica 195
Capítulo 8: Prácticas para Gestionar a los Stakeholders 199

Gestión de relaciones 200 Actividades de gestión de relaciones
201
Participación en la cadena de valor del servicio 204
Gestión de proveedores 205 Actividades de gestión de
proveedores 206 Estrategias de abastecimiento 208
Participación en la cadena de valor del servicio 210 Gestión
del nivel de servicio 211 Actividades principales de la gestión
del nivel de servicio 212 Acuerdos de nivel de servicio 213
Capítulo 9: Prácticas para habilitar el soporte de servicio 221

Gestión de la Seguridad de la Información 222 Áreas de
Seguridad de la Información 224
Gestión de activos de TI 229 Tipos de gestión de activos 232
ix
Tabla de contenido
Gestión de la configuración del servicio 235 CMDB, CMS y

modelo de servicio 238 Actividades principales de la gestión
de la configuración del servicio 243
Capítulo 10: Mejora continua 249

Mejora Continua en SVS250
Modelo de siete pasos 251 ¿Qué es la visión? 253 ¿Dónde
estamos ahora? 254 ¿Dónde queremos estar? 256 ¿Cómo
llegamos allí? 258 Actúe 258 ¿Llegamos allí? 259
¿Cómo mantenemos el impulso? 259 Práctica de mejora
continua 260
Actividades clave de la práctica de mejora continua 261
Herramientas de mejora continua 263
Compromiso con la cadena de valor del servicio 267
Capítulo 11: Prácticas para gestionar operaciones 273

Supervisión y gestión de eventos 275
Tipos de eventos 277 Actividades clave 280 Habilitación de
automatización 282
Práctica de gestión de incidentes 284 Buenas prácticas de
gestión de incidentes 287 Ciclo de vida de la gestión de
incidentes 290 Gestión de incidentes mayores 301
Práctica de gestión de problemas 304 Incidentes frente a
problemas 306 Otras terminologías clave en la gestión de
problemas 308 Fases de gestión de problemas 311
x
Tabla de contenido

Día 6 323
Capítulo 12: Prácticas para gestionar cambios 325
Gestión de solicitudes de servicio 326 Catálogo de servicios y
confusión con incidentes 329 Cumplimiento de solicitudes de
servicio 330 Directrices para la implementación 332
Práctica de control de cambios 335 Alcance del control de
cambios 338 Tipos de cambios 339 Aviso de cambios 348
Calendario de cambios 349
Capítulo 13: Prácticas para administrar versiones 355

Gestión de versiones 357 Control de cambios frente a gestión de
versiones 358 Fundamentos de las versiones 361
Waterfall vs Agile/DevOps 364 Técnicas de gestión de
versiones 367
Gestión de implementación 373 Enfoques de implementación
374 Proceso de implementación 380
Biblioteca de medios definitiva 383 Herramientas de
implementación 384
Día 7 389
xi
Tabla de contenido
Capítulo 14: La mesa de servicio 391

Práctica de mesa de servicio 392 ¿Por qué una mesa de
servicio? 394 Negocios y tecnología 395 Canales para llegar a
la mesa de servicio 396
Estructuras de la mesa de servicio 402
Cualidades que se esperan del personal de la mesa de servicio
410 Comunicación para comenzar 411 Orientación técnica 411
Sondeo hacia el éxito 412
Empatizar con los usuarios 412
¿Mesa de servicio bajo la nube de automatización? 413
Capítulo 15: Consejos y trucos para realizar el examen ITIL

419
Examen básico de ITIL 4: consejos y trucos 420 Preparación 420
Exámenes simulados 423
El día del examen 424
Preguntas frecuentes sobre carreras basadas en ITIL 427 ¿Cuán
diferente es ITIL de la gestión de proyectos? 427 ¿Necesito
experiencia en TI para obtener la certificación ITIL? 427
Estoy en desarrollo de software Quiero cambiar mi
Carrera basada en ITIL ¿Qué puedo elegir? 428 ¿Cuáles son los
roles de nivel de entrada en ITIL? 429
¿Cuál es la progresión normal del rol en las operaciones de
servicio? 429
¿Cuáles son los roles técnicos en ITIL? 430 Soy excelente en
el servicio al cliente ¿A qué rol debo aspirar? 430
¿Cuál es el rol de ITIL que más ha disfrutado? 430
xii
Tabla de contenido
Apéndice: Respuestas a las pruebas de conocimiento 433

Capítulo 3 433
Capítulo 4 434
Capítulo 5 434
Capítulo 6 435
Capítulo 7 435
Capítulo 8 436
Capítulo 9 437
Capítulo 10 437
Capítulo 11 438
Capítulo 12 439
Capítulo 13 440
Capítulo 14 441 Índice 443
xiii
Sobre el Autor
Abhinava Krishna Kaiser es una autoridad
reconocida en los marcos DevOps, Agile e ITIL.
Ha desarrollado arquitecturas DevOps y ha
transformado organizaciones de clientes en formas
ágiles de trabajar al desempeñar los roles de un
arquitecto ágil y un entrenador ágil. Continúa
innovando con formas novedosas de trabajo y
oportunidades de automatización. Su nombre está
ampliamente asociado con el marco ITIL.
Sus diseños ITIL más notables han
ha estado en la práctica de administración de configuración, donde ha diseñado
arquitecturas en entornos complejos que involucran múltiples interfaces y
herramientas como ServiceNow y BMC Atrium.
Abhinav ha impartido numerosas capacitaciones en ITIL, DevOps y Agile en
todo el mundo. Sus capacitaciones son particularmente poderosas con el uso de
ejemplos cotidianos para explicar conceptos difíciles.
Trabaja como gerente sénior en una importante firma de consultoría. Consulta
con organizaciones clientes en sus áreas de especialización. Al ser un consultor,
siempre está en movimiento. Es de Bangalore pero actualmente vive en Staines-
upon-Thames, Reino Unido. Abhinav está felizmente casado con Radhika y tienen
una hija (Anagha) y un hijo (Aadwik).
Abhinav comenzó como bloguero en 2004 cuando el mundo estaba
empezando a conocer los blogs y pasó a escribir en sitios web famosos como
Tech Republic y Plural Sight. Su primer libro fue sobre habilidades blandas:
Workshop in a Box: Habilidades de comunicación para profesionales de TI .
Luego escribió Conviértete
xvii
Sobre el Autor
ITIL Foundation Certified in 7 Days , que es una de las principales guías para el
marco ITIL V3. Su libro anterior fue Reinventing ITIL in the Age of DevOps , en
el que ajusta y personaliza el marco ITIL V3 para adaptarse a los contornos de
los proyectos DevOps. Este marco modificado se ha implementado en todas las
industrias con gran éxito.
Abhinav bloguea y escribe guías y artículos sobre DevOps, Agile e ITIL en
http://abhinavpmp.com . Si bien la mayoría de sus trabajos están asociados con TI,
también siente pasión por la ficción. Ha escrito algunas historias cortas en
http://indiancritic.com y espera escribir una novela completa algún día, con suerte
no muy lejos en el futuro.
xviii
Acerca del revisor
técnico
Jaya Tiwari es un líder de pruebas certificado por ISTQB®, PRINCE2®,
ITIL®, PSM™ I, Lean Six Sigma Green Belt que ha estado trabajando en la
industria del software de telecomunicaciones durante los últimos diez años, con un
enfoque en el aseguramiento de la calidad del software y las mejores prácticas. .
Ha dirigido departamentos que abarcan todos los aspectos del ciclo de vida del
software, incluidos el diseño y análisis de requisitos, el desarrollo de software, el
diseño de bases de datos, la garantía de calidad del software, las pruebas de
software, la documentación técnica y las revisiones. Además de trabajar como
"profesional de pruebas", Jaya es entrenadora de calidad y ágil y brinda
capacitación para certificaciones de prueba ISTQB y marcos ágiles. Ella cree
firmemente que el aprendizaje y la adaptación continuos conducen a una
transformación fenomenal en cada individuo.
xix
Prefacio
En 2017, dos años antes de que ITIL 4 apareciera en escena, escribí Conviértase
en ITIL Foundation Certified en 7 días . Cuando se anunció ITIL 4 en 2018, sentí
que me había tocado un cráter. Había esquivado varias solicitudes de editores a lo
largo de los años, y cuando finalmente decidí escribir un libro sobre ITIL, la
versión estaba llegando a un final prematuro. Sin embargo, mi libro básico de ITIL
se convirtió en un éxito instantáneo en el año de publicación y mi editor pronto
volvió a llamar a mi puerta para escribir la segunda edición. Estoy agradecido con
todos los lectores de la primera edición por extender su apoyo para hacer de mi
libro la principal guía para tomar el examen de Fundamentos de ITIL. Es posible
que ITIL V3 se haya actualizado oficialmente a ITIL 4, pero el marco sigue vivo.
La secuencia lógica de desarrollar un servicio desde la nada hasta una bestia de
pura sangre es un viaje que perdura en la mayoría de las organizaciones, y su
mayor fortaleza es que su aplicación sigue siendo relevante para las
organizaciones que no son de TI. ITIL V3 es un hermoso marco que es perenne y
proporciona una base sólida para ITIL 4 y DevOps para
florecer.
Cuando mi editor se acercó a mí para la segunda edición, les dije que la
primera y la segunda edición son mundos diferentes. Un cambio de edición
generalmente tendría actualizaciones que quedan eclipsadas por el contenido
restante del libro. Por el contrario, el libro que me pidieron que escribiera como
segunda edición iba a ser el polo opuesto. Iba a reescribir al menos el 80 por ciento
del libro; tal fue el cambio entre las dos versiones de ITIL.
Entre mi primera y segunda edición, escribí un libro en 2018 sobre un
marco ITIL que funcionaría en proyectos DevOps. La reinvención de ITIL en la
era de DevOps se basó en ITIL V3 y consideró ajustes y
xxx
Prefacio
personalizaciones a las estructuras de la organización, y la mayoría de los procesos

de ITIL pasaron por el escáner para el reacondicionamiento de DevOps. Además,
se identificó un énfasis especial y oportunidades donde la tecnología y la
automatización podrían emplearse para aumentar la eficiencia y reducir los
defectos. El ajuste del marco que propuse en el libro es relevante con ITIL 4, ya
que algunos de los ajustes que había adelantado en mi marco se han considerado
en ITIL 4 y se combinan a la perfección.
Uno de los principios básicos de ITIL es dar libertad a los arquitectos de
servicios para que presenten un diseño de marco que se adapte a la organización.
La reinvención de ITIL en la era de DevOps adapta el marco de ITIL para que
funcione para DevOps, prescribiendo en el proceso ITIL para proyectos que
funcionan en un modo DevOps. Si está buscando ingresar a ITIL o hacer la
transición a ITIL 4 desde ITIL V3, Conviértase en ITIL 4 Foundation Certified en
7 días es su libro de referencia. Si está buscando implementar ITIL en una
configuración de DevOps, Reinventar ITIL en la era de DevOps debería ser su
mejor opción.
Empecé mi camino hacia ITIL en 2005-2006 con la segunda versión de ITIL.
Pasé rápidamente de ser un practicante de ITIL a un consultor de ITIL y emprendí
varias implementaciones de ITIL a lo largo de los años. Mi perspectiva del mundo
de los servicios cambió cuando comencé a desempeñar el papel de arquitecto de
servicios y luego, finalmente, la vía de Experto en ITIL en la que me embarqué.
Cuando comencé a explorar ITIL y manipular los servicios para obtener los
resultados deseados, el funcionamiento del marco de trabajo de ITIL me pareció
una segunda naturaleza. Dirigí la práctica de capacitación y consultoría en una
organización y realicé cientos de capacitaciones de nivel básico y experto. Gané
fama y posiciones de autoridad, y luego algo sucedió.
Un cambio en la organización hizo que me agruparan con los consultores de
DevOps y la práctica de DevOps. Aproximadamente al mismo tiempo, mi gerente,
que estaba familiarizado con mi experiencia (que en ese momento era ITIL y no
DevOps), renunció a la organización. Un nuevo gerente asumió el cargo y un día,
mientras estaba empacando, se me acercó y me dijo: "Abhinav, te estoy buscando
para que seas uno de los entrenadores de DevOps". Podría haberle dicho que no
soy DevOps, sino ITIL. Permanecí en silencio y acepté el encargo.
XXII
Prefacio
Durante el siguiente mes y medio, comí, dormí y soñé con DevOps y DevOps
solo. Estudié todo sobre DevOps que pude tener en mis manos. En aquellos días,
los recursos de DevOps eran pocos y distantes entre sí, a diferencia de hoy.
La asignación comenzó y comencé con una explosión. Combinado con mi
destreza de entrenamiento, el conocimiento de DevOps que había adquirido me
convirtió en un éxito instantáneo. Comencé a capacitar a desarrolladores y
evaluadores de TI en varios continentes durante los siguientes 12 meses en varios
conceptos y procesos de DevOps. Mi vida había cambiado en el momento en que
permanecí en silencio, y nunca miré hacia atrás en mi decisión de saltar de un
segmento de TI a otro. A medida que profundizaba en DevOps, era evidente que
DevOps e ITIL no eran mundos separados, y que había un puente que se creía que
estaba demasiado lejos. A través de este y mi libro Reinventar , espero haber unido
los dos paquetes de TI.
A medida que el mundo se vuelve más plano, también lo hacen las diferentes
ramas de TI. Todos parecen estar convergiendo bajo el paraguas de DevOps. Antes
de mi carrera en DevOps, habría jurado que usted está en la gestión de servicios o
en la gestión de proyectos (desarrollo) y que su carrera se centrará en cualquiera
de estas áreas. En estos días, veo la convergencia. He diseñado arquitecturas
DevOps en las que tanto el desarrollo como la gestión de servicios se llevan a cabo
en la misma cabaña, y el mismo grupo de personas es responsable de ambos.
Cuando lea Conviértase en ITIL 4 Foundation Certified en 7 días , tenga la mente
abierta. No seas de la opinión de que esto es algo que no haces, por lo que no es
importante. Puede que no lo estés haciendo hoy, pero las responsabilidades de
mañana son una incógnita.
Este libro no solo lo prepara para el examen, sino también para un mundo que
se está unificando abrumadoramente con DevOps. El libro lo ayudará a convertirse
en un profesional de TI completo que está preparado para lo que el futuro tiene
para ofrecer.
XXIII
Introducción
La previsibilidad es una cualidad crítica de la planificación en TI. Prepararse para
una certificación de TI no es diferente. He tratado de imbuir esta cualidad en
Conviértase en ITIL 4 Foundation Certified en 7 días . Los profesionales que
trabajan necesitan saber el tipo de compromisos de tiempo que deben reservarse
para tomar nuevas capacitaciones para los exámenes de certificación. Todo el
libro está dividido en 7 partes desiguales, y he sugerido cómo podrías leer el libro
y completarlo en 7 días. He ido un paso adelante y también he estimado el tiempo
que puede necesitar para leer y comprender cada capítulo. Esto le dará un manejo
decente en la planificación de sus actividades de aprendizaje.
También debo recordarles que ITIL no es prescriptivo; en el mismo espíritu,
los 7 días que he propuesto son una sugerencia y no una receta. He considerado un
profesional de TI de trabajo común que tiene alrededor de una hora al día después
del horario de oficina. Si tienes más tiempo libre, entonces puedes terminarlo más
rápido. Si solo tiene fines de semana, entonces dos fines de semana pueden ser lo
que necesita. Planifica tu estudio de acuerdo a tus necesidades. Al final del día, no
tiene sentido estresarse por establecer objetivos que no son alcanzables. Como
dicen, debemos planificar para lograr el éxito y no hacer que el objetivo sea tan
empinado que el fracaso parezca inminente.
Si es nuevo en ITIL, es posible que le resulte un poco difícil acostumbrarse a
los conceptos de gestión de servicios. Para ayudarlo a atravesar estas aguas, los
Capítulos 1 , 2 y 3 son especialmente para usted. He explicado los conceptos
básicos de ITIL y DevOps con ejemplos del día a día para ayudarlo a comprender
los conceptos.
ITIL 4 se pone en marcha desde el Capítulo 4 . Si viene de ITIL V3,
encontrará que los conceptos como el sistema de valor del servicio, la cadena de
valor del servicio y las cuatro dimensiones son completamente nuevos. si, lo han
sido
xiv
Introducción
introducidos en ITIL 4. Sin embargo, no son completamente novedosos; se derivan
del ciclo de vida del servicio con el que está familiarizado. Cuando lea los
Capítulos 4 y 5 , se dará cuenta de que ITIL V3 e ITIL 4 no son muy diferentes
después de todo.
Lo que solíamos llamar procesos en ITIL V3 se conoce como prácticas en
ITIL 4. Sin embargo, no es lo mismo. No hay funciones. ITIL 4 tiene una visión
diferente del proceso de clubbing y funciona en conjunto para generar prácticas.
Cada capítulo (3-14) termina con ejercicios. Su objetivo es ayudarlo a
recordar el contenido del capítulo y prepararlo para el próximo examen.
Recuerde que las definiciones son especialmente importantes en los exámenes de
Fundamentos de ITIL; Este no es diferente. Comprender los conceptos es
necesario y, además de memorizar las definiciones, lo ayuda a recordarlos
fácilmente. Axelos también proporciona un documento de muestra, que debe
intentar antes del examen de certificación. He proporcionado estos detalles en el
Capítulo 14 . Para aquellos que tienen preguntas sobre carreras basadas en ITIL,
he respondido algunas preguntas frecuentes seleccionadas en el Capítulo 14 .
Hay 34 prácticas en ITIL y no las estudiará todas para el examen. Se
consideran quince prácticas en el plan de estudios para el examen de
Fundamentos de ITIL 4. Si está interesado en las prácticas que están fuera del
alcance del examen, diríjase a mi blog ( http://abhinavpmp.com ) donde se
presentan las prácticas restantes .
xxi
DÍA 1
Tiempo aproximado de estudio: 1 hora y 12 minutos
Capítulo 1 - 25 minutos
En el primer día de su viaje de ITIL 4 Foundation, conocerá la descripción general,

la historia y las diferencias entre ITIL 4 e ITIL V3, y aprenderá los conceptos y
procesos de DevOps. Se cubren los detalles del examen de certificación de la
Fundación ITIL y se analizan las otras certificaciones ITIL que se ofrecen.
CAPÍTULO 1
Introducción
al Nuevo ITIL
ITIL está en su cuarta encarnación y la nueva tiene algo interesante que ofrecer.
No solo ofrece una nueva variante de un marco para administrar servicios, sino
que también brinda una nueva perspectiva en el mundo de los servicios. Esto es
especialmente interesante porque el límite entre la etapa de desarrollo y la etapa de
operaciones no es muy delgado, sino que se ha desvanecido en el aire. Con la
ausencia de una barrera para distinguir las actividades que rodean las etapas de
desarrollo y las actividades operativas, se ha analizado la relevancia de ITIL como
marco para gestionar las operaciones. La respuesta es una nueva versión de ITIL
que se adapta a la era digital.
ITIL se emplea ampliamente en las organizaciones de TI en varios niveles de
madurez e implementación. Es el estándar hoy en día para ejecutar operaciones de
TI. Con el advenimiento de la era digital y DevOps, los principios y la
comprensión central de la gestión de servicios se vieron algo sacudidos. Se
concibió una nueva versión de ITIL para adaptarse al mundo de TI que cambia
rápidamente y para mantener relevante el principal marco de gestión de servicios.
De hecho, se escribieron varios elogios para ensalzar el marco de gestión de
servicios que estuvo de guardia durante al menos dos décadas y media. Se
consideró que en esta era de todo digital , el ITIL V3 centrado en el servicio era
obsoleto.
© Abhinav Krishna Kaiser 2021 3

AK Kaiser, obtenga la certificación ITIL® 4 Foundation en 7 días , https://doi.org/10.1007/978-1-4842-
6361-7_1
Capítulo 1
¿Por qué ITIL 4?

ITIL ha recorrido un largo camino. Comenzó siendo la Biblioteca de
Infraestructura de Tecnología de la Información (ITIL) y luego pasó al ámbito de
todo lo relacionado con la gestión de servicios. Ahora en su cuarto avatar como
ITIL digital, el marco está regresando con fuerza.
Cuando se anunció ITIL 4 en 2017, más personas temieron que se regocijaron.
La principal preocupación eran las certificaciones que poseía la gente.
Tradicionalmente, las certificaciones de ITIL se vuelven redundantes con la
llegada de nuevas versiones, y el curso puente es generalmente un puente
demasiado lejano. "También podrías estudiar todo el asunto en su lugar", era la
comidilla de la ciudad.
Aparte de los dolores de cabeza de la certificación, otros que conocían la
industria y hacia dónde se dirigía se sintieron un poco felices de ver una
actualización. Sintieron que la actualización se retrasó al menos 4 a 5 años; sin
embargo, más vale tarde que nunca.
Había una pregunta que todos tenían. ITIL V3 fue mucho más exitoso que
todo lo que existía. Todas las organizaciones que practican la gestión de servicios
optaron por ella sin pestañear. El marco era resistente; no prescriptivo; tecnología
neutral; y libres de ser adoptados, adaptados e implementados. ¿Por qué se
necesitaba un nuevo marco? La respuesta es simple: estaba fuera de contacto con
los tiempos.
ITIL V3 no era para la era digital

ITIL V3 me recordó a Nokia. Cuando comenzó la era de los teléfonos celulares, la
palabra teléfono celular era sinónimo de Nokia y viceversa. Y cuando los teléfonos
con pantalla táctil se hicieron realidad, Nokia simplemente pasó a un segundo
plano. La razón puede ser tan sencilla como que la empresa no se mantuvo al día
con los tiempos cambiantes y siguió invirtiendo en teléfonos tradicionales con
teclas en lugar de pantallas sensibles al tacto. El resultado fue desastroso. Se
4
Capítulo 1
dieron cuenta de que era demasiado tarde para regresar con un rugido atronador, y
se quedaron al margen.
INTRODUCCIÓN AL NUEVO ITIL
Con ITIL también, la historia habría sido similar si se hubiera mantenido con
ITIL V3. Al igual que Nokia, ITIL V3 y la gestión de servicios significan lo
mismo. No hay alternativa, absolutamente ninguna oposición o competidor. Sin
embargo, se puso en duda su mera existencia cuando nos embarcamos en la era
digital. Muchos críticos y campeones digitales escribieron elogios para ITIL y
básicamente dijeron que en la era en la que el cambio ocurre a la velocidad de la
luz, un marco tradicional y basado en procesos no tiene ningún lugar para jugar.
La era digital necesitaba mucha agilidad, dinamismo y una rápida toma de
decisiones. ITIL V3 con sus fases, procesos y funciones nunca iba a ser
suficiente, dijeron.
Fue entonces cuando la empresa detrás de ITIL, AXELOS, inició una
actualización al llegar a cerca de 2000 profesionales de varias organizaciones para
unirse con el único objetivo de crear un marco que fuera ágil e innovador. El
resultado es ITIL 4.
Aparición de DevOps
Hubo una explosión que hizo que la tradición quedara encerrada en una caja, y dos
partes distintas de TI tuvieron que unirse bajo el mismo paraguas. El desarrollo y
las operaciones siempre habían estado en desacuerdo y habían sido el juego de
culpas favorito de la industria de TI. Si se reportaban demasiados incidentes, se
culpaba al lado del desarrollo. Si la resolución tomaba demasiado tiempo, los
desarrolladores la relacionaban con las ineficiencias operativas. Si bien la industria
había aceptado vivir con este arreglo, Patrick Debois tenía otros planes. Propuso
que todas las ineficiencias podrían eliminarse y la sinergia amplificarse al pedir
que el desarrollo y las operaciones funcionen como una sola unidad. No más
juegos de culpas y no más pasar la pelota; sólo colaboración, supuso.
5
Capítulo 1
No es que la industria se cayera por completo en la metodología DevOps
cuando se socializó por primera vez. Pero cuando entró en los grandes como
Accenture e IBM, todas las demás empresas querían entrar en este modelo. De
hecho, ejecutar proyectos en un modelo DevOps se convirtió en un argumento de
venta. Los clientes también querían lo nuevo y brillante y se dirigieron hacia
DevOps
metodología.
Debajo del juego de desarrollo y operaciones, hubo un cambio importante
que presenció la industria de TI. Ya no era la gestión de proyectos y la gestión de
servicios lo que impulsaba las partes combinadas que se juntaron. Más bien fue
reemplazada por la gestión de productos. Entonces, todo lo que sabíamos sobre la
gestión de proyectos y servicios se volvió obsoleto y hubo hambre por las formas
digitales de pensar. Llegó en sabores ágiles en el lugar de la gestión de proyectos;
luego estaba Lean que prometía recortes y minimalismo; y finalmente, en el
frente de las operaciones, había rumores de que las operaciones ya no eran
necesarias si la gestión del producto se hacía de manera brillante. Dijeron que si
proporciona un producto perfecto sin defectos, ¿qué incidentes resolverían las
operaciones y cuál era la necesidad de pasar por los nueve metros de gestión del
servicio? La industria realmente no aceptó el concepto de no operaciones, sino
que comenzó a buscar opciones para tomar el relevo del poderoso ITIL que había
dominado el espacio de gestión de servicios. Fue entonces cuando se anunció el
nuevo ITIL y fue el momento en que comenzó mi trabajo para reinventar ITIL.
En un proyecto DevOps, esencialmente el desarrollo de un producto ocurre
junto con las operaciones. La mayoría de las veces, habrá un solo producto
atrasado para alimentarse, y el mismo grupo de personas tiene la tarea de trabajar
en ambos conjuntos de actividades. Esto cambia la ecuación para que ITIL V3
funcione de la forma en que se implementa más comúnmente; tomemos, por
ejemplo, el proceso de gestión de cambios. Está destinado a ser un gobierno
proceso que se basa en un cierto nivel de burocracia. Y la burocracia tarda en

procesarse debido a varias aprobaciones y controles y equilibrios. DevOps es
6
Capítulo 1
como una empresa nueva. No le gusta la burocracia. No cree en esperar a menos
que exista una dependencia real. En esta situación, ¿cómo implementa la gestión
de cambios para un proyecto DevOps? ¿Cómo puedes mantener felices a ambas
partes? ¿Tal vez estandarizar todas las formas de cambios? ¡Piensa otra vez! ¿Se
anula el propósito del proceso de gestión de cambios si todos los cambios se van a
estandarizar? Tal vez. Más probable. Asimismo, existen varios conflictos y
contradicciones que surgieron al diseñar ITIL para un proyecto DevOps. El más
importante fue el ciclo de vida del servicio de ITIL.
Ciclo de vida del servicio incompatible

La mayor USP (Propuesta Única de Venta) de ITIL V3 de su versión anterior fue el
comienzo lógico para identificar los servicios y su ciclo de vida. La definición del
ciclo de vida completo de un servicio trajo un nuevo significado a cómo se
valoraban y definían los servicios. Esto literalmente fue el cambio de juego. Hay
cinco fases en el ciclo de vida del servicio ITIL V3:
1. estrategia de servicio
2. Diseño de servicio
3. Transición de servicio
4. Operaciones de servicio
5. Servicio de Mejoramiento contínuo
Las cinco fases están representadas en la Figura 1-1 .
7
Capítulo 1
Continual
service
improcement
Service
transition
Service
strategy
Service Service
design operation
Figura 1-1. Ciclo de vida del servicio ITIL V3
Muestra la estrategia de servicio en el núcleo para indicar la importancia y la

participación de una estrategia sólida en el inicio de los servicios de TI. La
estrategia de servicio proporciona orientación sobre los servicios de TI existentes y
nuevos. La estrategia de servicio circundante es el diseño del servicio, la transición
del servicio y las operaciones del servicio. El diseño del servicio proporciona la
dirección relativa a la realización de un servicio. Se definen y diseñan los servicios
de TI que se identifican en la estrategia de servicio y se crean blueprints para su
desarrollo. Estos diseños se construyen, prueban e implementan en el
8
Capítulo 1 Introducción al nuevo ITIL
fase de transición del servicio. Después de la implementación, los servicios pasan

a un modo de mantenimiento. El mantenimiento de los servicios está a cargo de
la fase de operaciones del servicio. Las operaciones de servicio continuo
envuelven las otras cuatro fases. La representación muestra que las cuatro fases
presentan oportunidades de mejora, y la mejora continua del servicio
proporcionará los medios para identificar e implementar mejoras en todo el
servicio.
ciclo vital.
La vida de un servicio, comenzando con su intercepción y viéndolo crecer y
mejorar, es una historia maravillosa. es atemporal Pero hoy, el servicio por sí
mismo no tiene identidad. Está golpeado con la historia del desarrollo. Entonces,
cuando el desarrollo y los servicios se ven como gemelos siameses, el servicio y su
ciclo de vida se vuelven irrelevantes. Esta es una de las principales razones por las
que ITIL V3 no se adaptó de forma natural al esquema general de DevOps.
El ciclo de vida del servicio ITIL V3 es de naturaleza secuencial. Comienza
muy bien con la ideación en la estrategia de servicio y se mueve lógicamente y con
un propósito de una fase a otra. DevOps, por otro lado, no es secuencial. No es
paralelo también. Funciona en pequeñas iteraciones. El valor se realiza a través de
fragmentos de entrega en lugar de todo el pez gigante. No podemos ver un servicio
tomando forma en las iteraciones. Simplemente no es posible.
ITIL reinventado
Comencé mi carrera como arquitecto de gestión de servicios que abrazó ITIL con
ambas manos. Después de una década de diseños e implementaciones de ITIL,
pasé al área de DevOps. Como arquitecto DevOps, a menudo tenía la oportunidad
de diseñar las operaciones, y el ITIL textualmente no podía encajar en el esquema
de las cosas. Entonces, diseñé mi propio marco que se construyó sobre los pilares
del núcleo ITIL V3 mientras se adaptaba a la naturaleza de la metodología
DevOps.
9
El marco se convirtió en un libro llamado Reinventar ITIL en la era de

DevOps (Apress, 2018). Varias implementaciones de ITIL V3 han optado por mi
marco reinventado para adaptarse a sus necesidades digitales y de DevOps.
La demanda proveniente de los proyectos DevOps era construir un marco de
operaciones que fuera ágil y se combinara bien con el trabajo de desarrollo.
Como ya no teníamos el lujo de contratar profesionales de operaciones, la nueva
demanda de las operaciones de servicio era construir un sistema ponderado que
midiera el trabajo de desarrollo contra las operaciones de una manera ágil. El
marco tendría que considerar incidentes y problemas junto con las historias de
usuario de desarrollo.
En Reinventar ITIL en la era de DevOps , ofrecí sugerencias sobre cómo se
pueden estructurar los equipos para adaptarse a DevOps e ITIL en conjunto,
decodifiqué cada uno de los 26 procesos y brindé consejos y trucos de procesos
implementables para los procesos que se emplean más durante las operaciones.
(procesos de gestión de incidentes, problemas, configuración, cambios y
versiones).
Si su interés es poner en funcionamiento ITIL en proyectos DevOps, aún así le
recomendaría que utilice el proceso que expongo en mi libro.
Breve historia de ITIL

La historia de ITIL es nebulosa e inconsistente. Comenzó en algún momento a
fines de la década de 1980 como una colección de mejores prácticas en la gestión
de TI. Un departamento del gobierno del Reino Unido, conocido como OGC
(Office of Government Commerce), sancionó a la coalición. Básicamente, se
estudiaron y documentaron las mejores prácticas de varios departamentos de TI y
empresas en el Reino Unido. Se cree que la mayoría de las prácticas iniciales que
constituyeron ITIL provinieron de IBM.
La primera versión de ITIL era voluminosa y carecía de dirección, con una
compilación de más de 30 libros. La segunda versión de ITIL se redujo a nueve
libros en 2000, pero giraba principalmente en torno a dos libros: prestación de
10
servicios y soporte de servicios. Las certificaciones ITIL también se basaron en

estos dos libros. ITIL v2 introdujo diez procesos, cinco de cada uno de la entrega
de servicios y soporte de servicios. Empecé mi viaje ITIL con ITIL v2.
ITIL v2 estaba centrado en el proceso. Se esperaba que las organizaciones de
TI operaran en torno a los procesos de ITIL. Los procesos estaban interconectados
pero carecían de una visión más amplia y un flujo para avanzar.
Las deficiencias e insuficiencias en v2 dieron lugar a ITIL V3 en 2007. Tenía
un exceso de 20 procesos, que abarcaban todo el ciclo de vida de un servicio,
desde la concepción hasta el punto en que el servicio se ejecuta en ciclos regulares
de mejora.
ITIL V3 salió con cinco libros, cada libro abarca una fase del ciclo de vida de
un servicio de TI. ITIL V3 ha penetrado en la mayoría de las organizaciones de
TI. Incluso las organizaciones de TI conservadoras han adoptado el marco de
gestión de servicios de ITIL V3 con los brazos abiertos. El marco todavía está
muy extendido en la industria hoy en día y disfruta de una naturaleza monopólica,
a excepción de Microsoft, que se adhiere a una versión derivada de ITIL,
Microsoft Operations Framework.
En 2011, ITIL V3 recibió una actualización menor en la que se agregaron un
par de procesos nuevos junto con algunos cambios mínimos en definiciones y
conceptos. El marco de 2011 tiene 26 procesos y cuatro funciones. Se denomina
ITIL 2011 y algunas personas se refieren a él como ITIL V3 2011, indicando la
versión y el año de revisión.
En 2017, se anunció una nueva versión (V4). La fecha se fijó 2 años después
y, en febrero de 2019, comenzó un lanzamiento por fases de ITIL 4. Comenzó con
la publicación de la Fundación ITIL y el anuncio del examen de la Fundación ITIL
y, durante los meses siguientes, se anunciaron los módulos individuales. Se espera
que el conjunto completo se lance a fines de 2020.
ITIL V3 e ITIL 4: Las diferencias
11
ITIL 4 no es un vino nuevo en una botella vieja. Aunque los principios de ITIL
siguen siendo sólidos, los matices del marco contrastan. Mientras el primero
intenta construir una historia como Jeffrey Archer, el nuevo es dinámico
12
y explosivo como la brillantez de Tim Ferriss. En otras palabras, la semejanza se

limita a los procesos individuales más que a la historia y el contexto construido
alrededor de ellos.
Hay varios cambios, pero no voy a discutirlos todos aquí. Tal vez necesito un
libro completo para comenzar a exponerlo. Aquí están los artículos caros.
El ciclo de vida del servicio está muerto

En las líneas esperadas, el ciclo de vida del servicio se ha eliminado. Fue la falta
de un ciclo de vida tradicional lo que condujo a la convocatoria de un nuevo ITIL
y al eventual desarrollo de ITIL 4.
El vacío dejado por el ciclo de vida del servicio ha sido ocupado no por un
concepto sino por dos. El sistema de valor del servicio y la cadena de valor del
servicio son los nuevos conceptos que impulsan la prestación de servicios. La
cadena de valor del servicio trata de cubrir aproximadamente el ciclo de vida del
servicio, pero toma un PDCA (Plan-Do-
Check-Act) con sabor a planificación, actuación, investigación y acciones
correctivas.
Más detalles al respecto se encuentran en el Capítulo 5 .
Introducción a las prácticas

En ITIL, los procesos mandan. Todas las actividades suceden a través de procesos.
De hecho, el ciclo de vida del servicio también se compone de varios procesos
para cumplir los objetivos de la fase de servicio. Sin embargo, en ITIL 4 son las
prácticas las que ocupan un lugar central, pero no tan prominentemente como lo
hicieron los procesos.
Las prácticas son más que procesos. Uno no reemplaza al otro, ni uno es un
mero reflejo del otro. Un proceso estaba destinado a tomar ciertas entradas y
cuando el desencadenante se activa, se diseñó un conjunto de actividades para que
se lleven a cabo. Y finalmente, habría una salida. Una práctica es una extensión de
13
un proceso. No solo define las actividades, sino que también reúne varias
entidades, capacidades y herramientas para lograr los objetivos establecidos.
Teníamos un concepto llamado funciones en ITIL V3, que eran los equipos
que ejecutaban varios procesos. En la versión anterior, tenía una sección dedicada
a fusionar procesos y funciones. Imaginé las funciones ejecutándose como
horizontales, mientras que los procesos eran verticales y se cruzaban como una
malla, porque se necesitaban personas y equipos para ejecutar los procesos. No
tengo esa sección en este libro. ¿Adivina qué? No hay funciones en ITIL 4. Las
funciones se fusionan dentro del proceso y el resultado se puede denominar
aproximadamente como una práctica.
Imagine tener un equipo de gestión de problemas en su organización. es una
función ¿Qué hacen? Trabajan en el proceso de gestión de problemas para cumplir
sus objetivos. Además del equipo de gestión de problemas, necesitaba otros
equipos técnicos para cumplir los objetivos. Eran parte de las diferentes funciones
distintas.
Para colaborar mejor y entregar valor de manera eficiente, ITIL 4 ha
introducido el concepto de prácticas. La práctica de gestión de problemas en este
caso es un sistema en su conjunto cuyos objetivos son entregar todos los
resultados de la gestión de problemas.
El servicio tiene una nueva definición

La definición de servicio de ITIL V3 dice: un medio para entregar valor a los
clientes facilitando los resultados que los clientes desean lograr sin asumir costos
y riesgos específicos . El proveedor de servicios tenía la responsabilidad de crear
valor para el cliente, y el cliente no tiene que hacerse cargo de los riesgos o costos
individuales de los artículos unitarios. El cliente paga una cierta cantidad acordada
por el servicio y obtiene el servicio sin preocuparse por los riesgos inherentes al
servicio o el costo subyacente de los elementos individuales que componen un
servicio.
ITIL 4 ha cambiado la definición de un servicio. Es un medio para permitir la
creación conjunta de valor al facilitar los resultados que los clientes desean
14
lograr, sin que el cliente tenga que administrar costos y riesgos específicos. La
diferencia puede parecer trivial, pero el significado y la implicación son enormes.
Hoy en día, un proveedor de servicios no puede ocultar los servicios y

entregárselos al cliente de forma aislada. Cualquier servicio puede volverse
valioso solo si hay una amplia dirección y retroalimentación del cliente, la persona
principal que usa el servicio. Por lo tanto, la definición ha incluido correctamente
la co-creación .
La gobernanza es un chico nuevo en el

bloque
En mi opinión, la gobernanza en ITIL V3 no se recibió con los brazos abiertos.
Sí, teníamos los procesos de gobierno para garantizar que el trabajo de gestión
de servicios se gobernara al máximo y que las cosas no tomaran direcciones no
deseadas. Pero mi problema era que no había una mención explícita ni un
proceso o una función para definirlo. Siempre era el forastero el que miraba
hacia adentro.
Las cosas han cambiado para mejor en ITIL 4. La gobernanza tiene un lugar
adecuado en la mesa. La única forma en que un marco de gestión de servicios o
cualquier otro marco de gestión puede definir e implementar correctamente la
gobernanza es enfocándolo y definiendo sus objetivos. Encontrará más sobre esto
en el Capítulo 5 .
La automatización está de moda

En teoría, las máquinas pueden ejecutar actividades que no requieren
conocimiento, inteligencia o células cerebrales para la toma de decisiones. Esto
tiene aún más sentido si estas actividades son ejercicios repetibles. La
automatización es la clave para lanzar y ejecutar cualquier servicio porque ya no
son simplistas. Hay múltiples integraciones, y el manejo de cada controlador solo
15
se puede lograr si se confía a las máquinas. Por lo tanto, la automatización debe
adoptarse y no verse como un oponente a la creación de empleo.
ITIL V3 jugó con la idea de las herramientas de gestión de eventos. No fue
en toda regla, pero las intenciones eran claras. ITIL 4 lo ha llevado al siguiente
nivel al definir un principio rector que combina la optimización y la
automatización para permitir que ITIL atraviese las puertas de DevOps.
16
Capítulo 1
Jerarquía de Certificación ITIL 4

ITIL ha madurado con cada lanzamiento de su jerarquía de exámenes, y esto tiene
como objetivo ayudar a los profesionales de gestión de servicios a elegir la
certificación adecuada en función de su perfil de trabajo. En ITIL V3 también,
comenzó con el examen básico de fundamentos y pasó a cada una de las
áreas/fases específicas, y se definió un nivel experto para la persona que pudo
aprobar todos los niveles. Por encima del nivel experto estaba el pináculo de las
certificaciones ITIL: el nivel maestro. Era como un doctorado en ITIL, donde se
esperaba que el solicitante de la certificación escribiera una tesis en lugar de
responder un montón de preguntas.
ITIL 4 es similar y ha cambiado significativamente, adaptándose a los tiempos
que vivimos. Los niveles de certificación se ilustran en la Figura 1-2 .
ITIL Master
ITIL Managing ITIL Strategic

Professional (MP) Leader (SL)
ITIL ITIL ITIL ITIL ITIL ITIL

Specialist Specialist Specialist Strategist Strategist Leader
Create, Drive High Direct, Direct, Digital

Deliver & Stakeholder Velocity Plan & Plan & & IT
Support Value IT Improve Improve Strategy
ITIL Foundation
Figura 1-2. Ruta de certificación ITIL 4
17
Capítulo 1
Similar a ITIL V3, el nuevo ITIL 4 también comienza a reconocer a los
profesionales de ITIL a través de la certificación ITIL Foundation. Más
información sobre la certificación se incluye en la siguiente subsección.
Después de completar la certificación básica, los profesionales de ITIL
pueden elegir su certificación en función de la elección de carrera. Hay dos
opciones:
1. Profesional de gestión de ITIL (MP)
2. Líder Estratégico ITIL (SL)
Profesional de gestión de ITIL

El profesional de administración de ITIL (MP) es para aquellos que trabajan en el
diseño, la implementación y las operaciones de ITIL. Está destinado a
profesionales puros de gestión de servicios que trabajan en tecnología y flujos
digitales. Los exámenes de certificación evalúan el conocimiento profundo de la
gestión de servicios y brindan conocimientos sobre la ejecución de proyectos,
prácticas, equipos y flujos de trabajo.
Para convertirse en MP, el profesional debe completar cuatro módulos
individuales:
1. Especialista en ITIL: crear, entregar y brindar soporte
2. Especialista en ITIL: impulsar el valor de las partes interesadas
3. Especialista en ITIL: TI de alta velocidad
4. Estratega de ITIL: dirigir, planificar y mejorar
ITIL MP es equivalente a ITIL Expert en el esquema de certificación V3.
18
Capítulo 1
Líder Estratégico ITIL

Mientras que ITIL MP mira principalmente hacia adentro, hacia los engranajes
del motor ITIL, la certificación ITIL SL está destinada a mirar hacia afuera, hacia
las necesidades comerciales, las expectativas y todo lo relacionado con ellas.
La certificación prueba el conocimiento de ITIL desde la perspectiva de la

comprensión de la influencia que tiene ITIL en la estrategia empresarial.
Para convertirse en SL, el practicante debe completar dos módulos:
1. Estratega de ITIL: dirigir, planificar y mejorar (común con MP)

2. Líder ITIL: Estrategia Digital y TI
Maestro ITIL
No se sabe mucho sobre la certificación ITIL 4 Master. Actualmente, la
certificación maestra disponible es solo para la certificación ITIL V3.
Creemos que la certificación ITIL 4 Master será elegible para los profesionales
de ITIL que hayan completado las certificaciones MP y SL y deben presentarse a
una entrevista o probar un diseño/teoría basado en hechos empíricos y datos
supuestos.
La certificación Master existente tiene una elegibilidad de certificación ITIL
Expert y un mínimo de 5 años de experiencia en gestión de servicios.
Certificación de la Fundación ITIL

La certificación ITIL Foundation es una prueba de comprensión de los diversos
conceptos, filosofía, marco e ideas subyacentes de ITIL. La certificación roza la
superficie en todo el marco. El candidato obtiene una descripción general
completa del marco, el principio de los servicios de TI, los mecanismos de
entrega y las mejoras continuas que soporta. La certificación ITIL 4 Foundation
se abrió el 28 de febrero de 2019.
19
Capítulo 1
Criterio de elegibilidad
Cualquiera puede obtener la certificación ITIL 4. No hay criterios para la
experiencia mínima, la educación u otras certificaciones de requisitos previos. Si
bien existen organizaciones de capacitación acreditadas que brindan capacitación
sobre los fundamentos de ITIL, puede estudiar por su cuenta utilizando una guía
de estudio como esta y presentarse para el examen.
Su certificación ITIL V3 Foundation existente no cuenta para el examen
de certificación ITIL 4, ya que no hay un programa puente disponible. Por lo
tanto, todos deben realizar el examen de certificación de ITIL 4 Foundation,
ya sea que tengan o no una certificación equivalente en ITIL V3.
Este es un programa de certificación de nivel de entrada al mundo de ITIL.
Animo a todos en TI a que obtengan la certificación, ya que DevOps e ITIL no se
excluyen mutuamente. Qué mejor manera de obtener un control más firme de
DevOps que obtener una comprensión sólida del lado de las operaciones.
La mayoría de los trabajos basados en ITIL se encuentran en operaciones de
servicios, y para un rol de operaciones de servicios, la certificación de
Fundamentos de ITIL se considera adecuada. Incluso en las organizaciones
tradicionales que brindan servicios de TI, la mayoría de los empleadores esperan
que los empleados se pongan manos a la obra cuando comienzan. Para que esto
suceda, debe haber una alineación de los procesos, la terminología y las formas de
trabajar. Esta es principalmente la razón por la que los empleadores insisten en la
certificación de la Fundación ITIL.
Las personas a menudo cambian de trayectoria profesional dentro de la
misma organización. Para cambiar a una función de gestión de servicios, las
organizaciones insisten en que los empleados reciban capacitación en ITIL y
probablemente obtengan la certificación antes de la
transición.
También he tenido estudiantes que son principalmente del lado de los
proyectos de la industria. Estaban ansiosos por comprender cómo funcionan los
20
Capítulo 1
servicios y, para obtener una conciencia general sobre la gestión de servicios de
TI, tomaron el curso de certificación de Fundamentos de ITIL.
Examen de Certificación
La certificación de la Fundación ITIL se puede realizar a través de un examen en
línea o un examen en papel.
Estos son algunos aspectos destacados del examen básico de ITIL:
• Libro cerrado: no puede hacer referencia a ningún libro, notas u

hojas de trucos.
• Hay 40 preguntas de opción múltiple; cada pregunta viene con una
selección de cuatro respuestas posibles.
• Duración del examen: 60 minutos
• Cada pregunta vale un punto; las respuestas incorrectas no lo

atascan con una puntuación negativa.
• Debe dar 26 respuestas correctas para aprobar el examen: 65 por
ciento.
• El certificado de la Fundación solo muestra que ha aprobado el
examen y no muestra el puntaje que obtuvo en el examen.
• Obtiene resultados instantáneos cuando opta por los exámenes en
línea.
Encontrará consejos, trucos y preguntas frecuentes para el examen de

Fundamentos de ITIL sobre ITIL y carreras basadas en ITIL en el Capítulo 15 .
21
CAPITULO 2
Breve
descripción
general de
DevOps
Nuevas formas de trabajar, o nuevas metodologías, comienzan a descubrirse
debido a un problema, sí, todo comienza con un problema. DevOps también
tenía sus propias razones. Las empresas anhelaban tiempos de respuesta
rápidos para sus soluciones. Y, a menudo, las empresas descubrieron en
medio del desarrollo que no tenían toda la información que necesitaban para
tomar las decisiones correctas. Querían recomendar algunos cambios más a
los requisitos y aún esperaban que la entrega se realizara a tiempo. DevOps
nació para resolver este problema.
Bueno, DevOps no solo apareció como el DevOps que tenemos hoy. Ha
evolucionado con el tiempo. Para aquellos que comenzaron a resolver el
problema relacionado con la agilidad, quedó claro que DevOps tiene un gran
potencial no solo para resolver el problema de la agilidad, sino también para
aumentar la productividad a pasos agigantados. Además, la calidad del
software desarrollado tenía el potencial de ser históricamente mejor.
Por lo tanto, hasta el día de hoy, DevOps sigue cambiando y cambiando para
mejor.
Capitulo 2
DevOps no es solo una metodología para desarrolladores. Operaciones
también obtiene su parte del pastel de beneficios. Con una mayor
automatización, las operaciones pasaron de ser un trabajo mundano a uno
innovador. La gente de operaciones acaba de obtener una nueva oportunidad
de vida a través de varias herramientas que pueden mejorar mucho su vida
laboral, y podrían comenzar a integrar y configurar herramientas para hacer
cosas avanzadas, en lugar de la carga de trabajo repetitiva que generalmente se
asocia con operaciones. Aquí también, la productividad se disparó y los
errores humanos se convirtieron en una rareza.

AK Kaiser, obtenga la certificación ITIL® 4 Foundation en 7 días , https://doi.org/10.1007/978-1-
4842-6361-7_2
El desarrollo de software se llevó a cabo en la parte posterior del ciclo de
vida de entrega de software (SDLC) y se administró a través de la gestión de
proyectos en cascada. En el frente de las operaciones, ITIL gobernó el
gallinero. A través de DevOps, el desarrollo y las operaciones esencialmente
se unieron para formar una unión. En la combinación, la metodología en
cascada dio paso a las metodologías ágiles y, aún así, las personas que
diseñan procesos DevOps no tenían una buena comprensión de cómo ITIL
entraría en DevOps. Entonces, comenzó a circular mucho ruido de que el
amanecer de DevOps es el final de ITIL. Esto es simplemente ruido sin
ninguna sustancia.
¿Qué es exactamente DevOps?

Hay múltiples percepciones sobre DevOps. De hecho, si busca en la Web, se
sorprenderá al encontrar múltiples definiciones para DevOps y que no hay dos
definiciones originales que converjan en aspectos y elementos comunes.
He capacitado a miles en el área de DevOps, y la mejor respuesta que
tengo es que reúne a los equipos de desarrollo y operaciones, y eso es todo.
¿Reunir a dos equipos crea un revuelo tan fuerte en todo el mundo? De
hecho, si fuera solo la culminación de dos equipos, entonces probablemente
se habría hablado de DevOps en la ecosfera de recursos humanos, y habría
seguido siendo un proceso de gestión de recursos humanos semicomplejo.
22
Capitulo 2
Durante el comienzo de la era DevOps, para divertir mi curiosidad, hablé
con varias personas para entender qué es DevOps. La mayoría se inclinó hacia
la automatización; algunos hablaron de eso que hacen en las startups; y fueron
muy pocos los que hablaron de ello como un cambio cultural. ¡Interesante!
¿Quién habla de cultura en estos días, cuando el borde de nuestros asientos
quema un agujero si no cumplimos con nuestros compromisos? Un ejemplo en
particular me hizo sentarme y comenzar a unir los puntos de DevOps, y
finalmente todo tuvo sentido.
Breve descripción general de DevOps
DevOps explicado con un ejemplo

Digamos que usted es gerente de proyecto de un producto de banca por
Internet. El fin de semana pasado implementó un cambio para actualizar un
componente crítico del sistema después de semanas de desarrollo y pruebas. El
cambio se implementó con éxito; sin embargo, durante la revisión posterior a
la implementación, arrojó un error que lo obligó a revertir el cambio.
La reversión fue exitosa y todos los artefactos relacionados con el
lanzamiento se pusieron sobre la mesa para examinar e identificar la causa
raíz el lunes siguiente. Ahora que pasa? Se identifica la causa raíz, se
presiona a un desarrollador para que corrija el error y el código pasa por el
escrutinio de varias pruebas, incluidas las pruebas que no se realizaron
originalmente y que podrían haber detectado el error en la etapa de prueba
funcional en lugar de en producción. Todas las pruebas funcionan bien; se
planea un nuevo cambio; es aprobado por la junta asesora de cambios; y el
cambio se implementa, se prueba y se le da luz verde.
Estas son las actividades de proceso típicas que se llevan a cabo cuando
falla una implementación y se debe volver a planificar. Sin embargo, en el
momento en que las cosas van mal, ¿qué es lo primero que le viene a la mente
como gerente de proyecto? ¿Es qué acción objetiva debe tomar a continuación,
o comienza a pensar en el desarrollador que trabajó en esta área, la persona
responsable del error en primer lugar? ¿O piensa en el probador que identificó
los escenarios, escribió los guiones y realizó pruebas exploratorias? Sí, es
cierto que empiezas a pensar en los responsables del lío. ¿Por qué? Es por
nuestra cultura. Vivimos en una cultura que culpa a la gente y trata de pasar la
pelota.
23
Capitulo 2
Anteriormente mencioné que algunos encuestados me dijeron que DevOps
tiene que ver con la cultura. Entonces, ¿de qué cultura estoy hablando en el
contexto de este ejemplo? El ejemplo representa una cultura de culpa en la que
el director del proyecto intenta culpar a las personas de su equipo que son
directamente responsables del fracaso. Él podría tener razón en los hechos al
culpar a las personas directamente responsables, pero me estoy enfocando en
la práctica de culpar a los individuos.
¿En qué se diferencia esta práctica de una cultura DevOps? En DevOps,
la responsabilidad de completar una tarea no se considera una
responsabilidad individual sino una responsabilidad compartida. Aunque un
individuo trabaja en una tarea, si la persona falla o tiene éxito, todo el equipo
obtiene el palo o la zanahoria. Las personas no son responsables cuando
observamos el esquema general de DevOps, y no culpamos a las personas.
Seguimos una cultura intachable. Esta cultura de la inocencia surge del hecho
de que todos cometemos errores porque somos humanos después de todo y
estamos lejos de ser perfectos. Hacemos errores. Entonces, ¿cuál es el punto
de culpar a la gente? De hecho, esperamos que las personas cometan errores,
no por negligencia sino por la mentalidad de experimentación.
Esta aceptación (de los desarrolladores que cometen errores) nos ha
llevado a desarrollar un sistema en el que los errores que se cometen se
identifican y rectifican en las etapas de desarrollo, mucho antes de que lleguen
a la producción.
¿Cómo se construye este sistema (para detectar errores)? Para que esto
suceda, reunimos a los equipos de desarrollo y operaciones (para evitar la
desconexión); desarrollamos procesos que son mucho más efectivos y
eficientes que los existentes; y, finalmente, nos ofendimos con la
automatización para proporcionarnos de manera eficiente información sobre
cómo lo estamos haciendo (ya que la velocidad es uno de los principales
objetivos que pretendemos lograr).
DevOps es una frase común, y con su difusión a lo largo y ancho, existen
múltiples definiciones provenientes de varios sectores. No habrá dos
definiciones iguales, pero tendrán un tema común: la cultura. Entonces, para
mí, DevOps es una transformación cultural que reúne a personas de todas las
disciplinas para trabajar bajo un mismo paraguas para colaborar y trabajar
como una unidad con una mente abierta y eliminar las ineficiencias.
24
Capitulo 2
Nota La cultura sin culpa no significa que las

personas que cometen errores repetidos queden
impunes. las personas serán evaluadas de manera justa
y apropiada, pero de manera constructiva.
¿Por qué DevOps?

Podría preguntarse qué dio lugar a una nueva cultura llamada DevOps. La
respuesta es la evolución. Si observa una línea de tiempo del software, desde
la década de 1960 hasta la llegada de Internet en la década de 1990, el
desarrollo de software era equivalente a un proyecto de construcción o al
lanzamiento de un transbordador espacial. Requirió una planificación
meticulosa y actividades que fueron planificadas para ser ejecutadas
secuencialmente. La metodología de gestión de proyectos en cascada nació así
con cinco pasos secuenciales, como se indica en la Figura 2-1 .
Figura 2-1. Metodología de gestión de proyectos en cascada
25
Capitulo 2
Cuando Internet floreció, el software era mucho más accesible que en la
era anterior, y esto generó una demanda que no se había visto antes. Cuando
la industria del software comenzó a expandirse, quedaron expuestas las
limitaciones del modelo en cascada. La necesidad de completar un ejercicio
de planificación detallado y la práctica secuencial del flujo parecían un
impedimento para el avance de la industria del software.
Luego, en 2001, en una estación de esquí en Utah, nació el Manifiesto
Ágil. Varias metodologías ágiles predominantes se unieron para formar un
objetivo común que eliminaría las actividades secuenciales en cascada.
Agile fue más fluido porque no concibió todos los requisitos al principio y
trató de resolver todo de la noche a la mañana. Era un enfoque que se basaba
en iteraciones, donde todas las actividades de gestión de proyectos
simplemente se ciclaban repetidamente.
En el medio, si se cambiara un requisito, está bien porque había
disposiciones para realizar cambios que no eran de naturaleza burocrática ni
tediosa. De hecho, la metodología Agile pone el énfasis en la respuesta a
cambios en los requisitos más que en un mapa a seguir.
La flexibilidad y el dinamismo que surgieron a través de Agile
extendieron sus alas a través de la industria del software. Varios proyectos de
software migraron a la forma ágil de trabajar y, hasta el día de hoy, hay
proyectos que están pasando por un entrenamiento serio durante esta fase de
transformación.
La metodología Agile es simple, donde mantiene las cosas lo
suficientemente pequeñas para administrarlas y lo suficientemente grandes
para que sean significativas. Los marcos de tiempo que definían las iteraciones
en Agile no tenían demasiado margen de maniobra. Desde una perspectiva de
eficiencia, Agile fue mucho mejor que el modelo en cascada. Sin embargo, las
demandas del mercado no estaban sincronizadas con lo que podía ofrecer
Agile. Mientras el mercado pedía a gritos entregas más rápidas, la necesidad
de aumentar la calidad (reduciendo la tasa de defectos) se perseguía de forma
perenne. La metodología de gestión de proyectos Agile necesitaba algo, como
un elixir para ejecutar las cosas más rápido. Necesitaba automatización.
¡Ingrese a DevOps!
La automatización en sí misma es como darle un dron a un niño sin
enseñarle realmente el proceso para hacerlo volar. En términos generales, la
26
Capitulo 2
tecnología por sí misma no tiene sentido si no hay una arquitectura funcional,
un proceso y principios integrados subyacentes. DevOps, por lo tanto, no es
solo automatización, sino mucho más. Encontrará los detalles esenciales en las
próximas secciones.
Una nota sobre el alcance de DevOps

La palabra DevOps revela el alcance a través de la conjunción de dos partes
del ciclo de vida del software. Si bien Agile existió principalmente para
poner fin a la rigidez provocada por el modelo en cascada, se dijo que la
metodología también se puede usar para operaciones. Pero, sin un proceso
general o un marco, usar Agile para operaciones con el mismo rigor no iba
a funcionar. DevOps cerró esta brecha al reunir las fases operativas junto
con las actividades de desarrollo bajo un solo paraguas y aplicar procesos y
principios comunes para ser empleados en todos los ámbitos.
DevOps entra en juego cuando comienza con el proceso de desarrollo de
software, que es la fase de recopilación de requisitos. Finaliza cuando el
software se retira del servicio. DevOps abarca toda la longitud de onda del
ciclo de vida de un software, y si lee entre líneas, no puede simplemente
implementar y ejecutar DevOps hasta la implementación y terminar. Seguirá
funcionando hasta que los usuarios designados utilicen el software. En otras
palabras, DevOps llegó para quedarse y permanecerá mientras se brinden
los servicios. Entonces, en la práctica, la fase operativa se ejecuta
perpetuamente y DevOps brindará la optimización y automatización
requeridas. Los procesos para ejecutar operaciones se tomarán prestados del
marco de gestión de servicios de ITIL.
Nota la palabra DevOps nació gracias a Twitter. La

primera conferencia Devopsdays se llevó a cabo en
Gante, Bélgica, en 2009. Mientras la gente tuiteaba al
respecto, la etiqueta #devopsdays consumía 11
caracteres de los 140 posibles. En una forma de
acortarla, uno de los tuiteros usó #devops, y otros
27
Capitulo 2
siguieron su ejemplo. esto condujo al advenimiento de lo
que hoy conocemos como DevOps.
Beneficios de transformarse en DevOps

Varias compañías de software han estado entregando aplicaciones durante
varios años. ¿Por qué necesitamos que DevOps nos diga cómo debemos
desarrollarnos ahora?
Nuestros servicios se prestan a varios clientes, incluidos los principales
bancos y minas de todo el mundo. Estoy funcionando simplemente bien con mi
marco de gestión de servicios. ¿Por qué DevOps?
La gente ha vivido durante miles de años. Lo hicieron muy bien,
reproduciéndose y sobreviviendo. ¿Qué ha cambiado en los últimos 100 años?
Hemos cambiado los modos de transporte para una mayor eficiencia; nos
comunicamos más rápido hoy; y en general, nuestra calidad de vida ha subido
varios niveles. El hecho de que algo esté funcionando no es una barrera para
que se produzcan mejoras y se transformen. DevOps introduce varias mejoras
en las áreas de cultura laboral, procesos, tecnología y estructura organizativa.
La transformación se ha basado en prácticas que fueron desarrolladas por
algunas organizaciones afines que estaban dispuestas a experimentar, y los
resultados han favorecido ampliamente a DevOps sobre otras metodologías
antiguas que aún existen en la actualidad.
Amazon, Netflix, Etsy y Facebook son algunas de las organizaciones que
han llevado sus entregas de software a un nivel completamente nuevo y ya no
compiten con los rezagados. Han establecido nuevos puntos de referencia que
son imposibles de alcanzar con cualquiera de las otras metodologías.
En la conferencia Velocity de 2011, el director de análisis de plataformas
de Amazon, Jon Jenkins, brindó una breve descripción de las formas de trabajo
de Amazon. Lo apoyó con las siguientes estadísticas.
Durante los días de semana, Amazon puede implementar cada 11,6
segundos en promedio. La mayoría de las organizaciones luchan por realizar
implementaciones semanales de manera constante, pero Amazon realiza más
de 1000 implementaciones por hora (1079 implementaciones para ser
precisos). Además, 10 000 hosts reciben implementaciones simultáneas en
promedio, y el máximo que Amazon ha podido alcanzar es 30 000 hosts.
28
Capitulo 2
recibiendo despliegues simultáneamente. ¡Guau! Estos números están
realmente fuera de este mundo. Y estas son las estadísticas de mayo de 2011.
¡Imagina lo que pueden hacer hoy!
No es solo la velocidad de las implementaciones. Hay varias ventajas
adicionales que Amazon reclamó durante la conferencia:
• Las interrupciones debidas a implementaciones de software se han
reducido en un 75 por ciento desde 2006. La mayoría de las
interrupciones son causadas por nuevos cambios (léase
implementaciones de software), y la reducción de las interrupciones
apunta al éxito logrado en la implementación de cambios de
software.
• El tiempo de inactividad debido a las implementaciones de software
también se ha reducido drásticamente, en aproximadamente un 90
por ciento.
• En promedio, ha habido una interrupción por cada 1000
implementaciones de software, lo que representa una tasa de fallas
de alrededor del 0,1 por ciento. Esto se ve muy bien para una
organización de entrega de software moderada, pero para Amazon,
el número parece alto debido a las más de 1000 implementaciones
cada hora.
• A través de la automatización, Amazon ha introducido
conmutaciones por error automáticas cada vez que los hosts fallan.
• La complejidad de la arquitectura se ha reducido
significativamente.
Principios de DevOps
Los principios de DevOps o la orientación hacia el verdadero norte están en
constante evolución. De hecho, existen múltiples versiones de los principios.
El conjunto de principios que más se cree se representa con el acrónimo
CALMS. La figura 2-2 representa una taza de una campaña de marketing para
DevOps con CALMS.
29
Capitulo 2
Figura 2-2. Principios de DevOps (crédito de la imagen:

devopsnet.com)
CALMS significa lo siguiente:
• Cultura
• Automatización
• Inclinarse
• Medición
• Intercambio
Cultura
Existe una leyenda urbana popular que dice que el difunto Peter Drucker,
conocido como el fundador de la gestión moderna, dijo: "La cultura se come la
estrategia en el desayuno". Si desea realizar un cambio alucinante y
trascendental, comience por cambiar la cultura que puede hacerlo realidad y
adáptese.
30
Capitulo 2
a la nueva forma de trabajo propuesta. La cultura es algo que no se puede
cambiar mediante un proceso de cambio rápido. Está incrustado en el
comportamiento humano y requiere una revisión del comportamiento de las
personas.
Estos son algunos de los rasgos de comportamiento que queremos cambiar
con DevOps:
• Asuma la responsabilidad de todo el producto y no solo del
trabajo que realiza.
• Sal de tu zona de confort e innova.
• Experimenta todo lo que quieras; hay una red de seguridad para

atraparte si te caes
• Comunicarse, colaborar y desarrollar afinidad con los equipos
involucrados.
• Especialmente para los desarrolladores: lo construyes, lo
ejecutas.
Automatización
La automatización es un componente clave en la metodología DevOps. Es un
habilitador masivo para una entrega más rápida y también crucial para
proporcionar comentarios rápidos. Bajo el principio de cultura, hablé de una
red de seguridad con respecto a la experimentación. Esta red de seguridad es
posible gracias a la automatización.
El objetivo es automatizar todo lo posible en el ciclo de vida de entrega de
software. Los tipos de actividades que se pueden automatizar de manera
eficiente son las que son repetitivas y las que no requieren inteligencia
humana. Por ejemplo, construir infraestructura fue una tarea importante que
involucró a arquitectos y administradores de hardware; y lo más importante, la
construcción de servidores tomó una cantidad significativa de tiempo. Este fue
el tiempo que se agregó a la entrega general del software. Gracias al avance de
la tecnología, hoy tenemos una infraestructura en la nube y los servidores se
pueden activar a través del código. Además, no necesitamos administradores
de hardware para hacerlo. Los desarrolladores pueden hacerlo ellos mismos.
31
Capitulo 2
¡Espera, hay más! Una vez que se escribe el script de aprovisionamiento del
entorno , se puede utilizar para automatizar la activación de los servidores
tantas veces como sea necesario. La automatización realmente ha cambiado la
forma en que vemos la infraestructura.
Las actividades que involucran la ejecución de tareas, como ejecutar una
compilación o ejecutar un script de prueba, se pueden automatizar. Pero, las
actividades que involucran el conocimiento humano son difíciles de
automatizar hoy. El arte de escribir el código o los scripts de prueba requiere el
uso de la inteligencia humana, y las máquinas de hoy no están en condiciones
de hacerlo. Mañana, la inteligencia artificial puede ser una amenaza para las
actividades que hoy dependen de los humanos.
Inclinarse
DevOps se ha basado en gran medida en la metodología Lean y el Sistema de
producción de Toyota (TPS). El pensamiento detrás de la metodología Lean es
mantener las cosas simples y no complicarlas demasiado. Es natural que la
llegada de la automatización pueda disminuir la complejidad de la arquitectura
y simplificar los flujos de trabajo complicados. El principio Lean ayuda a
mantenernos sobre el terreno para que podamos continuar trabajando con
cosas que son fáciles de comprender y simples de trabajar.
Hay dos partes en el principio Lean. El principal es no inflar la lógica o la
forma en que hacemos las cosas; manténgalo directo y mínimo. Un ejemplo es
el uso de microservicios, que soportan la causa al no complicar demasiado la
arquitectura. Ya no buscamos construir arquitecturas monolíticas que sean
engorrosas cuando se trata de mejoras, mantenimiento y actualizaciones. Una
arquitectura de microservicios resuelve todos los problemas que enfrentamos
ayer con las arquitecturas monolíticas; es fácil de actualizar, solucionar
problemas (mantener) y mejorar.
La segunda parte del principio es reducir el desperdicio que surge de la
metodología. Los defectos son uno de los principales desperdicios. Los
defectos son una molestia. Retrasan la entrega general, y la cantidad de
esfuerzo que se dedica a repararlos es solo una pérdida de tiempo y dinero. El
siguiente
32
Capitulo 2
tipo de desperdicio se enfoca en procesos enrevesados. Si se puede hacer algo
pasando la pelota de A a B, ¿por qué tiene que rebotar en C? Hay muchos
desperdicios de este tipo que se pueden abordar para hacer que la entrega de
software sea más eficiente y efectiva.
Medición
Si busca automatizar todo, entonces probablemente necesite un sistema para
proporcionar comentarios cada vez que algo sale mal. La retroalimentación es
posible si sabe cuáles son los resultados óptimos y cuáles no. La única forma
de saber si el resultado es óptimo o no es midiéndolo. Entonces, ¡es esencial
que mida todo si va a automatizar todo!
El principio de medición brinda orientación sobre las medidas a
implementar y controla el pulso de la entrega general del software. No es una
tarea sencilla medirlo todo. Muchas veces ni siquiera sabemos qué debemos
medir.
Incluso si lo hacemos, la parte del cómo puede ser un obstáculo. Un buen
arquitecto de procesos DevOps puede ayudar a resolver este problema. Por
ejemplo, si está ejecutando un análisis estático en su código, la extensión del
código aceptable debe estar predeterminada. No es un número aleatorio, sino
que debe haber un razonamiento científico detrás. Varias empresas permiten
que pase una prueba unitaria incluso si analiza el 90 por ciento del código.
Sabemos que, idealmente, debe ser del 100 por ciento, entonces, ¿por qué
alguien debería comprometerse por el 90 por ciento? Ese es el tipo de lógica
que debe ir detrás de medir todo y permitir una retroalimentación rápida, para
ser realista sobre el tipo de retroalimentación que desea recibir.
En las operaciones, las aplicaciones de monitoreo, la infraestructura, el
rendimiento y otros parámetros se encuentran bajo este principio. Las
mediciones en el monitoreo implicarán cuándo un evento se clasificará como
una advertencia o una excepción. Con la automatización en su lugar, es
extremadamente importante que todas las actividades críticas y la
infraestructura que las respalda, sean monitoreadas y optimizadas para la
medición.
33
Capitulo 2
También hay otras medidas que se adjuntan a los contratos y SLA y se
utilizan para la presentación de informes de forma regular. Estas medidas
también son importantes en el esquema general de las cosas.
Intercambio
El último principio es compartir, que depende de la necesidad de
colaboración y de intercambio de conocimientos entre las personas. Si
nuestro objetivo es acelerar significativamente el proceso de entrega de
software, solo es posible si las personas ya no trabajan en silos. El
conocimiento, la experiencia, los pensamientos y las ideas deben exponerse
abiertamente para que otros se unan al proceso de mejorarlos, mejorarlos y
profundizarlos.
Uno de los puntos clave de este principio es poner a todos los que trabajan
en un producto o servicio en un solo equipo y promover el intercambio de
conocimientos. Esto conducirá a la colaboración en lugar de la competencia y
el escepticismo.
Hay una serie de herramientas de colaboración en el mercado hoy en día
que ayudan a apoyar la causa. Las personas ni siquiera tienen que estar
ubicadas para compartir y colaborar. Herramientas como Microsoft Teams y
Slack ayudan a transmitir la información no solo a una sola persona sino a
todos los que importan (como todo el equipo). Con la información
transparente, no habrá razón para que otros se preocupen o se muestren
escépticos sobre las dependencias o el resultado del proceso.
Elementos de DevOps
DevOps no es un marco; es un conjunto de buenas prácticas. Comenzó a partir
de una tormenta perfecta que reunió varias prácticas (que se analiza más
adelante en este capítulo), y hoy las consideramos bajo el paraguas de
DevOps. Es posible que haya visto un gráfico con un elefante (“The Panel
Experiment and Ignite DevOps” de Andrew Clay Shafer, 16 de mayo de 2010,
34
Capitulo 2
devopsdays.org). La industria de TI en torno al desarrollo de software es tan
amplia que se siguen varias prácticas en todos los ámbitos. Esto se representa
como el elefante. DevOps, que es un cambio cultural, se puede aplicar a
cualquier parte de la industria del software y a cualquier actividad que se esté
realizando en la actualidad. Por lo tanto, puede identificar cualquier parte del
elefante (por ejemplo, pruebas) y diseñar prácticas relacionadas con DevOps e
implementarlas, ¡y ya está haciendo DevOps!
No importa dónde desee implementar DevOps, hay tres elementos
comunes que respaldan y permiten el cambio de cultura. Las tres secciones
están indicadas por un diagrama de Venn en la figura 2-3 .
Figura 2-3. Tres elementos de DevOps
Las personas, los procesos y la tecnología son los tres elementos comunes
a todas las prácticas de DevOps. De hecho, son los habilitadores para efectuar
el cambio en la cultura DevOps. Solo cuando los tres elementos se unen al
unísono podemos obtener todos los beneficios de DevOps.
Examinemos los tres elementos y veamos cómo encajan entre sí. Para
generar un cambio cultural, definitivamente necesitamos personas, y las
personas no pueden operar sin la ayuda de los procesos. Al incorporar
personas y procesos, hemos logrado el diseño funcional para implementar una
solución DevOps. Sin embargo, la pregunta que hay que hacerse es si es
eficiente.
35
Capitulo 2
Se sabe que los humanos cometemos errores. No podemos evitarlo.
¿Cómo pueden los procesos por sí solos ayudar a los humanos a identificar los
errores cometidos? Puede haber una manera de hacerlo, pero definitivamente
no es eficiente. Para hacer que las cosas se muevan más rápido y de manera
eficiente, necesitamos la pila de tecnología para ayudarnos a lograr los
objetivos del proceso.
Hoy, la gente habla de DevOps a través de la lente de la tecnología.
Lanzan varios nombres de herramientas y afirman que hacen DevOps.
Entonces, la pregunta a considerar es si realmente puede hacer DevOps solo
con herramientas. ¿Pueden las personas y los elementos tecnológicos ser
suficientes sin un proceso subyacente? Probablemente adivinaste la respuesta,
y la respuesta es no.
Nada tiene éxito sin un proceso establecido, no solo en DevOps, sino en
todos los objetivos que desee lograr, TI o de otro tipo.
Esta es la era de la inteligencia artificial. Algunos expertos afirman que las
máquinas dominarán el mundo y reemplazarán el trabajo que solía hacer la
gente. Hay varias películas como "Terminator Genisys" y "Ex Machina" que
reproducen las melodías de AI tomando las riendas y poniendo a los humanos
en peligro. Me encanta la ficción, y la toma de decisiones por parte de la IA es
algo que me gusta considerar como ficción (al menos por ahora porque los
avances tecnológicos están rompiendo nuevas barreras todos los días). Sin
embargo, volviendo a DevOps, el simple hecho de emplear tecnología con
procesos subyacentes no es suficiente. Sin personas, la creación no sucede. Sí,
la tecnología puede automatizar una serie de actividades preprogramadas, pero
¿puede desarrollar nuevas soluciones por sí sola? No me parece; no hoy de
todos modos. Las personas son el motor de la creación y los agentes del
cambio cultural.
Los tres elementos de personas, procesos y tecnología son esenciales para
construir la metodología DevOps y lograr los objetivos que se nos presentan.
Mediante la unión de los tres elementos, podemos crear una sinergia
inigualable que puede impulsar los desarrollos a un ritmo sin igual
36
Capitulo 2
Gente
La palabra DevOps se deriva de la conjunción de dos palabras, desarrollo y
operaciones. Ya lo he familiarizado con lo que se trata DevOps: un cambio de
cultura en la forma en que entregamos y operamos el software. Las personas
están en el centro de esta transformación cultural y son uno de los tres
elementos críticos que permiten la cultura DevOps.
Los equipos de desarrollo y operación se fusionan para lograr un cambio
en la cultura. El pensamiento detrás de esto es bastante sencillo. Digamos que
se desarrolla una aplicación y llega a la junta asesora de cambios (CAB) para
su aprobación. Una de las partes del CAB son los equipos operativos. Hacen
preguntas específicas sobre las pruebas que se han realizado para este
software, y aunque la respuesta del desarrollo es sí para la tasa de éxito de
todas las pruebas, los equipos operativos tienden a ser críticos. No quieren ser
bloqueadores, pero se encuentran en una posición en la que tienen que admitir
software con el que aún no están familiarizados. Los errores y defectos que
vienen con el software se convertirán en su problema después del período de
garantía (generalmente entre 1 y 3 meses). Lo más importante es que solo
cuentan con la confirmación de los desarrolladores cuando la calidad del
software está en juego.
En el mismo escenario, imagine si los equipos operativos ya fueran parte
del mismo equipo que el de desarrollo. Estar en el mismo equipo les dará la
oportunidad de familiarizarse con el proceso de desarrollo y los controles de
calidad implementados. En lugar de hacer preguntas en el CAB, pueden
trabajar progresivamente con los equipos de desarrollo para garantizar que el
software se pueda mantener y que todos los aspectos operativos posibles se
lleven a cabo de antemano. Este es uno de esos casos de estudio que muestra
el beneficio de tener un solo equipo.
En la Figura 2-4 , puede visualizar al equipo de desarrollo al borde de un
precipicio, mientras que el equipo de operaciones está al otro lado. Entre los
dos acantilados se encuentra un área de incertidumbre donde las actividades
que caen entre los dos equipos tienen la habilidad de ser impredecibles y
generalmente se discuten, generalmente sobre la propiedad. En otras palabras,
desea que las cosas sean con el equipo de desarrollo o con el equipo de
operaciones. No hay puente entre los equipos, lo que significa que puede haber
37
Capitulo 2
mucha confusión, falta de comunicación y desconfianza entre los dos equipos
opuestos.
Figura 2-4. Conflicto entre desarrollo y operaciones
Vamos a jugar las prioridades para ambos equipos. El equipo de desarrollo

aún tiene trabajo porque existe la necesidad de desarrollar nuevas funciones.
Esa es su área central, y eso es lo que deben hacer para seguir siendo
relevantes. El gran objetivo del equipo de operaciones es mantener el entorno
estable, en el sentido más básico. Deben asegurarse de que, incluso si algo sale
mal, tienen la tarea de devolverlo a la normalidad, en otras palabras, mantener
el statu quo. Entonces, aquí tenemos un equipo de desarrollo que tiene la
intención de crear nuevas funciones y un equipo de operaciones que busca
mantener estable el entorno.
¿Tiene que ser ciencia espacial para haber evolucionado hacia una
metodología llamada DevOps que promete sacudir la industria desde sus
raíces? Bueno, el entorno se mantendrá estable si no se introducen cambios.
lo. Mientras permanezca estancado, nada perturbará su estabilidad, y el

equipo de operaciones habría sido recompensado por un trabajo estelar. Pero
tenemos al equipo de desarrollo esperando entre bastidores para desarrollar
nuevas características. Las nuevas funciones que se desarrollen se
implementarán en el entorno de producción, y existe la posibilidad de que la
38
Capitulo 2
implementación de nuevas funciones pueda afectar la estabilidad. Por lo
tanto, la estabilidad es algo que nunca se puede lograr mientras se
introduzcan nuevas funciones, y ningún software permanecerá estancado sin
mejoras y expansión.
Una forma decente de abordar este dilema entre los equipos de desarrollo
y operación es unirlos y crear canales de comunicación entre los miembros del
equipo. Tanto el equipo de desarrollo como el de operaciones tienen la
responsabilidad compartida de garantizar que el desarrollo, las pruebas, la
implementación y otras actividades de soporte se realicen sin problemas y sin
fallas. Cada miembro del equipo asume la responsabilidad de todas las
actividades que se llevan a cabo, lo que se traduce en que los equipos de
desarrollo y operación trabajan conjuntamente en la solución que comienza
con la codificación y termina con la implementación. Los equipos de
operaciones no tendrán motivos para desconfiar de los resultados de las
pruebas y podrán implementarlos con confianza en la producción.
ambiente.
Proceso
Los procesos son un componente clave para asegurar el éxito de cualquier
proyecto. Sin embargo, a menudo encontramos que la mayoría de las
implementaciones de DevOps se centran más en la automatización y la
tecnología y dan un segundo plano a los procesos que se supone que son la
base de la automatización. Dicen que conducir en el asiento trasero es
peligroso, por lo que colocar procesos en esta posición y esperar que se llegue
al destino en un tiempo récord y sin contratiempos es una apuesta que juega
con la imprevisibilidad. Por lo tanto, es importante que los procesos se definan
primero junto con una arquitectura DevOps funcional y luego se traduzcan en
herramientas y automatización. El proceso siempre debe conducir
herramientas y nunca al revés.
39
Capitulo 2
Con DevOps combinando diferentes disciplinas bajo un mismo estandarte, los

procesos también deben reorganizarse para adaptarse a los nuevos objetivos. Esta
sección cubre los procesos pertenecientes al área de desarrollo.
La metodología de gestión de proyectos en cascada (como la gestión de
proyectos respaldada por PMI y PRINCE para proyectos en entornos controlados)
ya no se ve favorecida en el campo de TI. Hay varias razones que van en contra de
esta metodología, principalmente derivadas de la rigidez que aporta a la estructura
de gestión de proyectos.
La mayoría de los proyectos de TI se ejecutan con metodologías ágiles de
gestión de proyectos debido a la flexibilidad que ofrece en este mercado en
constante cambio. Según la publicación “Pulse of Profession” de PMI de 2017 (
www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/
pulse/ pulse -of-the-profession-2017.pdf ), El 71 por ciento de las organizaciones
han estado aprovechando Agile. Otro estudio de PricewaterhouseCoopers,
denominado “Confianza en la entrega de proyectos ágiles (julio de 2017)” (
www.pwc.com/gx/en/ actuarial-insurance-services/assets/agile-project-delivery-
trust.pdf ), informó que los proyectos Agile tienen un 28 por ciento más de éxito
que sus contrapartes en cascada. Esto es enorme si se tiene en cuenta que Agile
aún es nuevo y emergente y que la metodología en cascada existe desde la década
de 1960.
Cuando hablamos de gestión de proyectos Agile, hay una serie de
metodologías para elegir. Scrum, Kanban, Scrumban, Extreme Programming
(XP), Dynamic Systems Development Method (DSDM), Crystal y Feature
Driven Development (FDD) son algunos ejemplos. Sin embargo, todas las
metodologías están alineadas por un manifiesto que se formuló en una estación
de esquí en Utah en 2001. Y hay un conjunto de 12 principios ágiles que brindan
orientación para establecer la gestión de proyectos.
procesos.
40
Capitulo 2
Tecnología
La tecnología es el tercer elemento de DevOps y, a menudo, se considera el más
importante. Es cierto en cierto sentido que sin la automatización, no podemos
lograr los resultados rápidos que he compartido anteriormente a través de algunas
estadísticas. También es cierto que la tecnología por sí sola, sin la debida sincronía
de personas (roles) y procesos, es como una nave espacial en manos de niños de
jardín de infantes. Es imprescindible que las personas y los procesos de DevOps se
resuelvan primero antes de seguir este camino.
La cantidad de herramientas que afirman respaldar las actividades de DevOps
es enorme, demasiadas para contarlas.
Prácticas DevOps
La palabra DevOps se ha convertido en sinónimo de ciertas prácticas, como la
integración continua, la entrega continua y la implementación continua. Esta
sección explica y ordena las prácticas y las diferencias entre ellas.
Integración continua
Varios desarrolladores trabajan juntos en la misma pieza de código, que se conoce
como la línea principal en la jerga de desarrollo de software. Cuando varios
desarrolladores están trabajando, los conflictos que surgen debido a los cambios
realizados en las piezas de código y la lógica empleada son bastante comunes. Los
desarrolladores de software generalmente integran sus piezas de código en la línea
principal una vez al día.
Cuando surgen conflictos, lo discuten y lo resuelven. Este proceso aquí de
integrar el código manualmente en un tiempo definido ralentiza el desarrollo. Los
conflictos a veces pueden tener resultados drásticos, con cientos de líneas de
código que deben reescribirse. Imagine el tiempo y el esfuerzo perdidos debido
41
Capitulo 2
a la integración manual. Si puedo integrar el código casi en tiempo real con el
resto de los desarrolladores, la cantidad potencial de reelaboración se puede
reducir significativamente. Este es el concepto de integración continua.
Para ser más específicos, la integración continua es un proceso mediante el
cual los desarrolladores integran su código en el repositorio de código fuente
(línea principal) de forma regular, digamos varias veces al día. Cuando el código
se integra con la línea principal, cualquier conflicto saldrá a la luz tan pronto como
se integre. La resolución de conflictos no tiene por qué ser un asunto en el que
todos los desarrolladores se sientan frente al código base y se rompen la cabeza.
Solo aquellos que tienen conflictos necesitan resolverlos manualmente. Al hacer
esta resolución de conflictos varias veces al día, la extensión de los conflictos se
minimiza drásticamente.
Nota La mejor definición de integración continua fue

acuñada por Martin Fowler de Thoughtworks, quien también
es uno de los miembros fundadores del Manifiesto ágil.
La integración continua es una práctica de desarrollo de
software en la que los miembros de un equipo integran su
trabajo con frecuencia; por lo general, cada persona integra
al menos una vez al día, lo que genera múltiples
integraciones por día. cada integración se verifica mediante
una compilación automatizada (incluidas las pruebas) para
detectar errores de integración lo más rápido posible.
Muchos equipos encuentran que este enfoque conduce a
problemas de integración significativamente reducidos y
permite que un equipo desarrolle software cohesivo más
rápidamente (fuente:
www.martinfowler.com/articles/continuousIntegration.html ) .
42
Capitulo 2
Integrar el código con la línea principal es solo el comienzo. Cada vez que se
integra el código, se construye toda la línea principal y también se llevan a cabo
otros controles de calidad, como pruebas unitarias y controles de calidad del
código (análisis estático y dinámico).
43
Capítulo 2 Breve descripción general
de DevOps
Nota La compilación es un proceso en el que el

código legible por humanos se convierte en un lenguaje
legible por máquina (código ejecutable), y el resultado de
una actividad de compilación es un binario.
La prueba unitaria es un control de calidad en el que las
partes comprobables más pequeñas de una aplicación se
prueban individualmente y en forma de componentes.
El análisis estático es un examen del código fuente con
respecto a los estándares de codificación establecidos
por la industria/compañía de software, como
convenciones de nombres, espacios en blanco y
comentarios.
El análisis dinámico es un examen del binario durante el
tiempo de ejecución. dicho examen ayudará a identificar
errores de tiempo de ejecución, como fugas de memoria.
Digamos que un proyecto en particular tiene tres desarrolladores, y cada

desarrollador integra su código tres veces al día. Diariamente, esto equivale a
nueve integraciones todos los días. Según la Figura 2-5 , el código que se
integra se somete primero a una prueba de unidad, seguido de verificaciones
de la calidad del código y la compilación del software. Todo esto sucede
automáticamente cada vez que se integra el código.
Con nueve integraciones diarias, estamos contemplando la posibilidad de
tener nueve pruebas unitarias, nueve compilaciones en toda la línea principal y
nueve controles de calidad del código.
Supongamos que falla una de las compilaciones o pruebas unitarias o
controles de calidad del código. El flujo se interrumpe y el desarrollador se
pone a trabajar para corregir el defecto lo antes posible. Esto garantiza que el
44
de DevOps
flujo de código no se vea obstaculizado y que otros codificadores puedan
continuar codificando e integrar su trabajo en la línea principal.
SOURCE
INTEGRAT CODE AUT
REPOSITOR
E PRUEBAYDE O
UNIDAD
REA
EG
AU O
T
IN
T
T
RT BUILD
G E
TE
IN
A
AU O
T
CODE
QUALITY
CHEC
K
Figura 2-5. Integración continua
La integración continua permite una entrega rápida de software, y

cualquier obstáculo se evita o se identifica lo antes posible, gracias a la rápida
retroalimentación y automatización. El objetivo de la integración continua es
acelerar el proceso de codificación y generar un binario sin errores de
integración.
Entrega continua
Con la integración continua hemos logrado estas dos cosas:
• Un binario se genera con éxito.
• Se completan las comprobaciones y el análisis a nivel de código

y en tiempo de ejecución.
45
de DevOps
El siguiente elemento en el SDLC es probar el binario generado desde
varios ángulos, aspectos y perspectivas. Sí, me refiero a las pruebas como
pruebas de sistema, pruebas de integración, pruebas de regresión, pruebas de
aceptación de usuarios, pruebas de rendimiento y pruebas de seguridad; esta
lista es bastante interminable. Cuando terminamos con el número acordado
de pruebas, se considera que el binario es de calidad y se puede implementar
en producción. El binario calificado se puede implementar en producción con
solo hacer clic en un botón. La calificación de cualquiera de los binarios
como liberables en producción se denomina entrega continua (consulte la
Figura 2-6 ). Generalmente se considera como una extensión natural del
proceso de integración continua.
Figura 2-6. Entrega continua
La figura 2-6 muestra una canalización de entrega continua. Después de

cada ciclo exitoso de integración continua, el binario se somete
automáticamente a una prueba de integración. Cuando la prueba de
integración tiene éxito, el mismo binario se prueba automáticamente en el
sistema. El ciclo pasa al entorno de preproducción siempre que las pruebas
(regresión y prueba de aceptación del usuario [UAT] en esta ilustración) sean
exitosas. Cuando el mismo binario se implementa correctamente en el entorno
de preproducción (en esta ilustración) o en cualquier otro entorno anterior al
entorno de producción, el binario se califica para implementarse en
producción. La implementación en el entorno de producción no se realiza
46
de DevOps
automáticamente, sino que requiere un disparador para que suceda. Todo el
ciclo, desde la inserción del código en el repositorio del código fuente hasta la
implementación manual en el entorno de producción, es una entrega continua.
En la ilustración, he mostrado a tres desarrolladores integrando su código

y tres binarios implementables. La entrega continua no dicta que los tres
binarios deban implementarse en producción. El proceso de administración de
versiones puede decidir implementar solo el último binario cada semana.
Recuerde que el último binario consistirá en los cambios de código realizados
por todos los desarrolladores hasta ese momento.
La secuencia de automatización de las actividades que comienza en el
proceso de integración continua hasta el entorno de producción se denomina
canalización o canalización de entrega continua en este caso.
Implementación continua
La implementación continua es un paso más allá de la entrega continua. En la
entrega continua, la implementación en producción se basa en un disparador
manual. Sin embargo, en el proceso de implementación continua, la
implementación en producción ocurre automáticamente, como se muestra en
la Figura 2-7 .
CONTINUOUS
DELIVERY
CONTINUOUS INTEGRATION
INTEGRATIO REGRESSIO
INTEGRAT AUT AUT SYSTEM TEST AUT AUT UA AUT PRE-PROD MANUA PRODUCTIO
E O N TES O O N TES O O L
T N
T T
INTEGRAT AUT AUT SYSTEM TEST AUT AUT UA AUT PRE-PROD AUT PRODUCTIO
E O
N TES O O
N TES O O O
T N
T T
CONTINUOUS
DELIVERY
Figura 2-7. Despliegue continuo
47
de DevOps
Tan pronto como todas las pruebas sean exitosas, el binario se implementa
en el entorno de preproducción. Cuando la implementación en preproducción
va según lo planeado, el mismo binario se implementa directamente en
producción. En la entrega continua (Figura 2-7 ), los archivos binarios se
calificaron como implementables y el administrador de versiones no pudo
implementar todos los archivos binarios calificados en producción. Por el
contrario, en la implementación continua, cada binario calificado se
implementa en la instancia de producción.
Se podría pensar que esto es demasiado arriesgado. ¿Cómo puede
implementar algo en producción sin ningún tipo de controles, balances y
aprobaciones de todas las partes interesadas? Bueno, cada prueba que se
realiza y todos los controles de calidad ejecutados son los controles que
califican los binarios como desplegables. Todo está sucediendo de manera
automatizada. De lo contrario, haría el mismo conjunto de cosas pero
manualmente. En lugar de implementar varias veces al día, puede implementar
una vez a la semana. Todos los beneficios que se derivan de entrar temprano
en el mercado no se encuentran en los procesos manuales.
Digamos que uno de los despliegues fuera a fallar. ¡Ningún problema!
Hay un mecanismo de reversión automatizado integrado en el sistema que
revierte la implementación en segundos. Y es importante tener en cuenta que
los cambios que se discuten aquí son pequeños cambios. Por lo tanto, las
posibilidades de que estos binarios derriben un sistema son remotas.
Entrega continua frente a

implementación continua
La diferencia radica en la secuencia final, donde la implementación en la
instancia de producción es automática en la implementación continua y tiene
un activador manual para la entrega continua, como se muestra en la Figura 2-
8.
48
de DevOps
CONTINUOUS
DELIVERY
CONTINUOUS INTEGRATION
INTEGRAT AUT AUT SYSTEM TEST AUT AUT UA AUT PRE-PROD MANUA PRODUCTIO
E O N TES O O N TES O O L
T N
T T
INTEGRAT AUT AUT SYSTEM TEST AUT AUT UA AUT PRE-PROD AUT PRODUCTIO
E O
N TES O O
N TES O O O
T N
T T
CONTINUOUS
DELIVERY
Figura 2-8. Entrega continua frente a implementación continua
Cualquier organización en un viaje de implementación de DevOps

implementará el proceso de entrega continua y, al obtener la madurez
suficiente, avanzará hacia el pináculo de la madurez de DevOps: el proceso de
implementación continua.
Las organizaciones que sienten la necesidad de mantener un control total
de su entorno de producción a través de una estructura formal de aprobaciones
y visibilidad tienden a optar por la entrega continua. La banca y otros
segmentos financieros entran en esta categoría.
Hay otras organizaciones que han escalado la escalera de madurez de
DevOps y están bastante seguras de que la implementación automática no
causa un impacto significativo en su entorno de producción. Incluso si algo
fallara, la reversión también será rápida, incluso antes de que alguien pueda
notarlo. Compañías como Amazon, Netflix y Google han estado en este
espacio por un tiempo. Anteriormente compartí una estadística sobre la
administración de Amazon de una implementación cada 11,6 segundos.
¿Cómo es posible? No busque más allá de la implementación continua.
Nota aquí hay una hoja de trucos para la entrega

continua y la implementación continua:
Entrega continua: puede implementar.
49
de DevOps
Implementación continua: implementará
¿Es DevOps el fin de las

operaciones?
Con la introducción de la integración continua, la entrega continua y la
implementación continua, el enfoque ha sido tapar los defectos, aumentar la
calidad y no sacrificar la eficiencia. El pensamiento detrás de la noción de
que DevOps finaliza las actividades operativas se basa en la premisa de que
la falta de defectos no dará lugar al trabajo operativo. si no hay
50
Capitulo 2
defectos, potencialmente no hay incidentes o problemas, lo que se traduce en una

reducción masiva del trabajo operativo. Otro ejemplo es que si implementamos la
implementación continua, los procesos de gestión de cambios y versiones, tal
como los conocemos, se automatizarán en gran medida y disminuirán la necesidad
de aprobaciones y aprobaciones posteriores, la planificación de versiones y la
implementación de versiones.
Aclaremos una cosa: no importa cuánto intentemos con el uso de la tecnología
y la automatización, los defectos siempre existirán. El número de defectos se
reducirá debido a la rápida retroalimentación y automatización, pero afirmar que
todos los defectos serán identificados y rectificados es absurdo. Con la reducción
de defectos, la cantidad de trabajo operativo definitivamente disminuirá. Con el
argumento en torno a los procesos de gestión de cambios y versiones, la ejecución
de cambios y versiones se puede automatizar a través de la entrega continua y la
implementación continua, pero la parte de la planificación siempre seguirá siendo
el conocimiento de la experiencia humana. Hasta cierto punto, el trabajo operativo
relacionado con los procesos de gestión de cambios y versiones también está
empezando a disminuir.
La innovación es un arma de doble filo. Con la introducción de herramientas y
automatización, existe un nuevo requisito operativo para establecer y configurar la
pila de herramientas y mantenerla mientras el proyecto esté en marcha. Esta es una
actividad operativa que se suma al trabajo tradicional de operaciones. Si bien
algunas áreas han visto una reducción, hay otras nuevas que han brotado para
ocupar su lugar. Las actividades manuales, repetitivas y aburridas están
desapareciendo. En su lugar, el emocionante trabajo de herramientas DevOps ha
pasado a primer plano y está haciendo que los roles operativos sean aún más
lucrativos.
Entonces, si usted es una persona operativa, es hora de escalar y escalar más
allá de las actividades gerenciales. La nueva ola de mapeo de roles requiere que
las personas sean tecno-gerenciales en talento y polifacéticas. Se buscan
recursos en forma de T, no solo para operaciones sino también para desarrollo.
Los recursos en forma de I deben buscar familiarizarse con áreas de
especialización que complementen su línea de trabajo.
51
Con la llegada de DevOps, se crea una turbulencia en los proyectos de

software. Esta es una buena turbulencia porque busca elevar el nivel de entrega y
hacer que los equipos, en lugar de los individuos, sean responsables de los
resultados. Desde el punto de vista de las operaciones, está claro que su papel ha
subido un par de niveles donde las actividades mundanas, aburridas y repetitivas
han sido reemplazadas por trabajos imaginativos y desafiantes, como la
configuración de canalizaciones, la integración de conjuntos de herramientas y la
automatización de la gestión de la configuración. La naturaleza del trabajo para
operaciones ha cambiado pero no el papel que juegan como guardianes de los
entornos y solucionadores de incidentes y problemas. DevOps no ha significado el
final de las operaciones, sino que las ha rejuvenecido a un viaje emocionante que
mantendrá vivo el ingenio de las personas que trabajan en operaciones.
DIA 2

El día 2 saltamos a los conceptos de ITIL: productos, servicios, valor y relaciones

de servicio. También estudiamos las cuatro dimensiones de ITIL, que son los
pilares que mantienen estable el fuerte de ITIL.
CAPÍTULO 3
ITIL 101:
Conceptos y
fundamentos
básicos
La guía de estudio del examen de Certificación de Fundamentos de ITIL 4
comienza con este capítulo. Mientras que el Capítulo 1 abordó los matices y la
historia de ITIL, el Capítulo 2 proporcionó una visión del mundo de DevOps y
sus prácticas.
De ahora en adelante, no me referiré a ITIL 4 sino solo a ITIL. Intentaré
evitar comparar los conceptos de ITIL con la versión actual. Todas las
comparaciones y comentarios se encuentran en el Capítulo 1 .
En este capítulo, aprenderá sobre los conceptos subyacentes de la gestión
de servicios, que incluye servicios y roles que son fundamentales.
Profundizaré más en el valor, los resultados, los costos y los riesgos. El
concepto imperecedero de unir servicios con valor se realiza bajo el lema de
utilidad y garantía. Finalmente, hablaré de las relaciones de servicio.
Consejo de examen A partir de este capítulo, puede

esperar ver algunas preguntas al final del capítulo. Estas
son las preguntas típicas que puede esperar ver en su
CAPÍTULO 3 ITIL 101: CONCEPTOS Y
FUNDAMENTOS NÚCLEO
examen de Fundamentos de ITIL. Las claves de
respuesta a las preguntas se proporcionan al final del
libro.

4842-6361-7_3
Gestión De Servicios
Cuando compre un producto, digamos un teléfono inteligente, ¿cuáles son
algunas de las cosas que considerará? Seguro que mirarías las características,
la marca y el precio. Pero, ¿qué más aparece en la lista? Quizás las opciones
relacionadas con el servicio, como el costo del servicio, la garantía, la
disponibilidad de los centros de servicio, las piezas cubiertas por el servicio y
los tiempos de respuesta, sean importantes. De hecho, hoy en día, una marca
obtiene su valor no solo de los productos que tiene en el mercado sino también
del factor servicio. Apple fabrica el teléfono más popular hoy en día en
iPhone. ¿Qué más hace que el iPhone haga clic? La garantía internacional, la
proximidad a las tiendas Apple en todo el mundo, el enfoque profesional para
solucionar problemas y el enfoque sensato para mantener contento al cliente
son de suma importancia.
Repito. Una marca obtiene su valor de los servicios que ofrece. Piense
en todos los automóviles que ha tenido y en la comodidad del servicio que ha
tenido dentro del proveedor de servicios. Sí, el proveedor de servicios juega
un papel importante en mantener las cosas en movimiento. Podrían ser cosas
tangibles, como su último teléfono iPhone o su automóvil Tesla. O podrían
ser intangibles como electricidad, internet móvil y paisajismo. Los servicios
ofrecidos colectivamente caen bajo la gestión de servicios, que se ramifica
hacia varias especializaciones como TI, hospitalidad y medicina.
54
FUNDAMENTOS NÚCLEO
Definición ITIL de Gestión de Servicios
Un conjunto de capacidades organizativas especializadas para
habilitar el valor para los clientes en forma de servicios.
Las capacidades organizativas especializadas apuntan a la madurez

técnica, la experiencia, el servicio al cliente y los marcos de gestión que el
proveedor de servicios aporta para atender a los clientes, satisfacer sus
necesidades y crear valor.
Consejo de examen En el examen de Fundamentos

de ITIL, es esencial comprender la definición al pie de la
letra. En el examen aparecen preguntas que le piden
que identifique la definición correcta de, por ejemplo ,
gestión de servicios. Estará en condiciones de hacerlo
sólo si ha memorizado las definiciones. Aunque no soy
muy partidario de memorizar nada, te recomiendo que lo
hagas a partir de un examen.
punto de vista.
Las capacidades organizativas especializadas no son fáciles. Es un

proceso largo y arduo obtener conocimiento de experiencias pasadas,
capacidades (habilidades) y una dirección clara para avanzar. El liderazgo
en la gestión de servicios comienza con la identificación de la naturaleza
del verdadero valor, la lectura precisa de las partes interesadas y el
establecimiento de límites de apoyo y mejora.
Aunque la gestión de servicios es el núcleo del marco ITIL, es una parte
muy importante del marco completo de gestión de productos. No podemos
mirar la gestión de servicios sin el contexto de un producto. Un producto
impulsa el éxito del servicio. Un producto pésimo, por ejemplo, apaleado con
un servicio ejemplar no influye en la percepción del cliente. Ambos necesitan
caminar de la mano y bailar tango como un argentino.
55
FUNDAMENTOS NÚCLEO
Productos y servicios
La brecha entre un producto y un servicio se ha ido cerrando desde los albores
de la era digital. Si bien todos conocemos la diferencia básica entre los dos,
como que un producto sea tangible y algo que un cliente pueda comprar y
potencialmente romper todos los lazos con el fabricante, un servicio se trata
más de la relación entre un cliente y un proveedor de servicios. Los servicios
son generalmente intangibles y de duración determinada.
La era digital ha visto una tendencia en la que los productos se camuflan y
se venden como servicios. En otras palabras, los productos ya no son
productos, son productos en forma y forma de servicios, como un lobo con
piel de cordero. Tomemos, por ejemplo, la siempre popular aplicación MS
Office. En mis días de universidad, solía pagar cierta suma y comprar la
aplicación. Lo usé durante varios años hasta que apareció una nueva versión y
descarté lo viejo por lo nuevo. Hoy, este producto de antaño ya no se vende
como producto. Bueno, puedes comprarlo como un producto, pero ya no es un
caballero de brillante armadura. Office se vende con la apariencia de Office
365, donde pago una fracción del dinero que normalmente pago por el
producto, y lo pago todos los meses (o anualmente). Los beneficios (aunque
durante un período de tiempo termino pagando mucho más que el producto en
sí) son las actualizaciones gratuitas y la cantidad de licencias que obtengo con
una sola suscripción, además de una enorme cantidad de espacio en OneDrive.
Todo lo que Microsoft tuvo que hacer fue volver a empaquetar el producto con
algunos brillos y piruletas y salieron del otro lado con un flujo constante de
ingresos y ganancias sustanciales. ¡Bienvenido a la era digital!
ITIL se trata principalmente de servicios y de cómo los servicios hacen
que los clientes generen resultados. La creación de servicios no se puede hacer
en ausencia de una estrategia para la gestión de productos. Por lo tanto, esta
sección aborda tanto los productos como los servicios, pero profundiza en los
servicios mientras examinamos la superficie del producto.
Definición ITIL de un producto

Configuración de los recursos de una organización diseñada
para ofrecer valor a un consumidor.
56
FUNDAMENTOS NÚCLEO
Los recursos de una organización pueden venir en múltiples formas y
formas. Podrían ser las personas que trabajan en él, los procesos o los
productos que se fabrican o desarrollan. Estos recursos se pueden vender a un
consumidor de varias maneras:
• Podría venderse a un precio único.
• Se puede arrendar o alquilar por un tiempo determinado.
• El cliente podría utilizar el producto mediante suscripción.

• Las personas en una organización podrían trabajar como
contratistas en una función de aumento de personal.
No importa cómo la empresa ofrezca sus productos, el objetivo final es

proporcionar valor a través de los recursos que tiene a su disposición.
Los servicios son una bestia diferente. Son más fáciles de iniciar pero
mucho más difíciles de mantener para la organización que presta los servicios.
Ser un proveedor de servicios exitoso es una tarea que se alimenta con
imaginación y aprendizaje y mejora continuos. Con los productos devorando
el pastel de los servicios, ITIL ha hecho un replanteamiento del significado de
un servicio.
ITIL Definición de un Servicio

Un medio para permitir la creación conjunta de valor al
facilitar los resultados que los clientes desean lograr, sin que
el cliente tenga que administrar costos y riesgos específicos.
La definición de un servicio es un maravilloso reflejo de cómo se crea un

servicio, no de forma aislada. Ninguna organización puede afirmar que crea
valor a través de un servicio sin la participación activa del cliente que
aprovecha el servicio. En la definición anterior, un servicio habilita el valor
creado conjuntamente por el proveedor del servicio, el cliente y quizás otras
partes también.
Volviendo al ejemplo de Office 365, ¿cómo superó los beneficios que
ofrecía el producto de Office? Office 365, aunque costoso con un uso continuo
durante un período, tiene éxito. Ofrece actualizaciones gratuitas de productos,
y en el mundo en el que vivimos, donde las personas se lanzan a actualizarse a
57
FUNDAMENTOS NÚCLEO
la última versión, este es un imán bastante bueno. Como si fuera poco, se
ofrecen múltiples licencias según el tipo de suscripción. Y en la era de la nube,
una característica adicional de 1 TB de espacio en OneDrive está salivando.
He dejado de comprar discos duros desde que me topé con Office 365 y varios
cientos de GB están a mi disposición donde quiera que vaya. Imagínese cómo
tenía que llevarlo conmigo en discos duros cada vez que mi vida como
consultor de gestión requería viajar.
Si bien disfruto del servicio pagando una cierta tarifa, yo, como cliente, no
tengo el peso sobre mis hombros de asumir los riesgos que conlleva el
servicio. El proveedor de servicios es dueño de los riesgos por completo y no
expone al cliente a ellos. Digamos que un documento se corrompió mientras
se almacenaba en OneDrive. Es responsabilidad de Microsoft realizar copias
de seguridad frecuentes para garantizar que un cliente no termine perdiéndola.
¿De qué sirve un servicio si no es confiable, verdad? Asimismo, un servicio
consume varios costos individuales, como costos de servidores, licencias
específicas, desarrolladores, personal de soporte, etc. El proveedor del servicio
no le pide al cliente que pague un porcentaje determinado por cada uno de
estos elementos, sino un costo del servicio por disfrutar del servicio. servicios.
En otras palabras, el proveedor de servicios trabaja con sus gastos e
inversiones de capital e identifica un valor justo que el cliente necesita pagar
que sea competitivo, además de garantizar que los costos no rompan el banco
del proveedor de servicios. La segunda mitad de la definición de servicio se
trata de que el proveedor del servicio sea dueño de los riesgos y costos
específicos y no los pase directamente al cliente.
Consejo de examen entender lo que significa un

servicio es extremadamente crítico para seguir
avanzando en el estudio de Certificación de
Fundamentos de ITIL. Si aún tiene dudas persistentes,
lea nuevamente la definición del servicio. Sin una
comprensión adecuada del mismo, no estará en
condiciones de comprender los conceptos restantes.
58
FUNDAMENTOS NÚCLEO
Organización
Mencioné anteriormente que el valor no se puede crear de forma aislada.
Quise decir que una organización que crea valor por sí sola no es posible;
más bien, con el apoyo y retroalimentación de otras entidades que consumen
el servicio, es posible crear valor. En esta sección tratemos de entender qué
es una organización.
Una organización es una entidad que está compuesta por una sola persona
o por varias personas. Puede estar formado por una estructura plana simple
con números en decenas y centenas o ser gigantescas multinacionales en
cientos de miles.
Sí, has leído bien. Incluso los individuos pueden actuar como
organizaciones. Por ejemplo, un consultor independiente que ingresa a una
organización para realizar una evaluación previa a la auditoría puede
administrar su propia empresa y ser la única persona en la nómina.
ITIL Definición de una Organización

Una persona o un grupo de personas que tiene sus propias
funciones con responsabilidades, autoridades y relaciones
para lograr sus objetivos.
Una organización tiene su propio conjunto de objetivos y trabajan hacia

una meta común, sin importar cuán grandes y complejos sean. Las
organizaciones más grandes tienden a tener múltiples jerarquías, y con eso
vienen las autoridades y la cadena de mando. Sin embargo, el objetivo que
intentan alcanzar no cambia.
Una organización en el contexto de la gestión de servicios puede
desempeñar dos roles distintos:
• Proveedor de servicio
• consumidor de servicios
Un proveedor de servicios es una organización que ofrece servicios a los

clientes. Microsoft es el proveedor de servicios y, dado que pago por los
servicios, soy el cliente; y debido a que consumo los servicios ofrecidos,
también puedo asumir el papel de consumidor de servicios. Por otro lado,
59
FUNDAMENTOS NÚCLEO
cuando tomo un trabajo independiente para llevar a cabo una evaluación de
viabilidad de DevOps para Company Alpha, me pongo el sombrero de
proveedor de servicios mientras que Company Alpha se convierte en el
consumidor de servicios. Para resumir, los roles organizacionales, proveedor
de servicios y consumidor de servicios, son contextuales. La misma
organización desempeña el papel de proveedor de servicios para un cliente y
puede ser el cliente o un consumidor de servicios para otro proveedor de
servicios. Incluso es posible que dos organizaciones puedan desempeñar tanto
el papel de proveedor de servicios como el de consumidor de servicios para
diferentes conjuntos de servicios. Digamos, por ejemplo, que Microsoft
proporciona el servicio Office 365 para una empresa de telecomunicaciones
como Verizon y podría terminar consumiendo la conectividad de fibra de
Verizon entre dos oficinas de Microsoft. En este ejemplo, Microsoft y Verizon
se pusieron diferentes sombreros para diferentes conjuntos de servicios.
Figura 3-1. Ilustración de relación mutua entre proveedor de servicios

y consumidor de servicios
60
FUNDAMENTOS NÚCLEO
La figura 3-1 ilustra una relación mutua entre un proveedor de servicios y un

consumidor de servicios. Mientras que la organización de la izquierda es el
proveedor de servicios para los servicios A y B, también es el consumidor de
servicios para los servicios C y D. Asimismo, la organización de la derecha
desempeña el papel de proveedor de servicios para los servicios C y D y disfruta
de la servicios ofrecidos para los servicios A y B.
Roles de personas
Dentro de una organización hay múltiples roles. Algunos genéricos desde el punto
de vista de ITIL que son de interés son:
• Cliente
• Patrocinador
• Usuario
Dicen que el cliente siempre tiene la razón porque sabe exactamente lo que
quiere. Esto no es exactamente cierto, porque descubren lo que realmente
necesitan durante el curso del desarrollo. Entonces, en los proyectos DevOps, el
cliente se convierte en parte del equipo de desarrollo y el rol que se define se llama
propietario del producto. Desde la perspectiva de la gestión de servicios, es
exactamente lo mismo que define los requisitos de un servicio y es fundamental
para la forma y forma final del servicio.
Definición ITIL de un cliente

Una persona que define los requisitos para un servicio y asume
la responsabilidad de los resultados del consumo del servicio.
El cliente puede definir los requisitos porque sabe cómo se aprovechará el

resultado del servicio para cumplir con las metas y objetivos del negocio. Por lo
61
FUNDAMENTOS NÚCLEO
tanto, recae mucho peso sobre el hombro del cliente para dar la dirección correcta
a los equipos de desarrollo de servicios.
Un patrocinador generalmente proviene de la organización del cliente y tiene
las claves para la aprobación del presupuesto. El patrocinador es generalmente una
persona de alto nivel en la organización a quien se le confían las finanzas.
Necesitan juzgar la liberación presupuestaria en función de los requisitos y un
precio justo para los servicios en el alcance.
Definición ITIL de un patrocinador

Persona que autoriza el presupuesto para el consumo del servicio.
La persona o personas que disfrutan del servicio están definidas por el rol de
Usuario.
Definición ITIL de un usuario

Una persona que utiliza los servicios.
Un usuario desempeña un papel de dos maneras distintas.

1. Un usuario aprovecha el servicio para el trabajo que debe
realizarse.
2. Lo que es más importante, el usuario proporciona comentarios

sobre el servicio, que se utilizarán como información para
mejorar el servicio. Recuerde la definición de un servicio donde
se co-crea valor. Los usuarios desempeñan su papel al
proporcionar comentarios valiosos sobre el servicio y, por lo
tanto, ayudan al cliente a dar forma al servicio.
Considere un ejemplo en el que una organización multinacional decide
comprar computadoras portátiles para reemplazar su flota obsoleta. Los requisitos
para la computadora portátil por el bien de este ejemplo serán definidos por el
CTO, que en este caso es un cliente. El patrocinador, o la persona que tiene la
aprobación presupuestaria, es el CFO. Según los requisitos, el costo de las
computadoras portátiles varía y el director financiero calcula el presupuesto
reservado para la inversión de capital y decide si puede patrocinar las
62
FUNDAMENTOS NÚCLEO
computadoras portátiles. Cuando se adquieren las computadoras portátiles, se
distribuyen a varios empleados que son los usuarios. Por lo general, no tienen una
voz decisiva en los requisitos, ni tienen las llaves del casillero del dinero.
Ajustando este ejemplo a una tienda de comestibles de mamá y papá, el
propietario de la tienda de conveniencia desea reemplazar su computadora portátil.
Él decide sobre una determinada configuración. Él sabe exactamente si puede
pagar la computadora portátil (aunque generalmente la autorización proviene de la
esposa) que se ajuste a sus necesidades. Finalmente, después de comprarlo, es él
quien lo usa. En este caso, la misma persona desempeña el papel de cliente,
patrocinador y usuario.
Consejo de examen Desde esta sección (Gestión de

servicios), puede esperar que aparezcan un mínimo de una
pregunta y un máximo de dos preguntas en su examen de
Certificación de Fundamentos de ITIL.
Definición de valor
¿Cómo sabe que ha creado valor para el cliente a través de los servicios de TI? No
hay una respuesta fácil para esto. Tal vez, si estuviera dirigiendo una empresa de
mensajería, podría haber afirmado con confianza que entregó los documentos
entregados a una organización gubernamental, no hubo demoras, cobró
económicamente y ha cuantificado el valor para su cliente.
¿Qué sucede si está ejecutando un servicio cuyo valor no se puede
cuantificar, como una compañía de seguros donde los clientes aún no han
presentado reclamos? ¿Cómo sabrá el cliente que has creado valor? Se podría
decir que ha dado tranquilidad a sus clientes cubriendo todas las
eventualidades. Pero la realidad es que no sabes si el cliente ha percibido tu
definición de valor.
Entonces, en efecto, el cliente juzga y percibe si se crea valor para el cliente.
El proveedor de servicios, en el mejor de los casos, puede investigar a sus clientes
63
FUNDAMENTOS NÚCLEO
y encontrar posibles soluciones que puedan hacer feliz al cliente. Y al final,
todavía no puede estar seguro de que se haya creado valor para el cliente. Esto se
debe a que el valor siempre se mide a través de los ojos del cliente. Hay otros dos
componentes que definen
64
CAPÍTULO 3 ITIL 101: CONCEPTOS Y FUNDAMENTOS NÚCLEO
valor aparte de la percepción del cliente: los resultados que obtiene el negocio
y las preferencias del cliente. Se ilustran en la Figura 3-2 .
Figura 3-2. elementos de valor
Definición de valor de ITIL

Los beneficios percibidos, la utilidad y la importancia de
algo.
Al fin y al cabo, lo que destaca a la hora de sopesar el valor es la

percepción, porque como dijo un sabio: “siempre entrega más en valor
percibido de lo que recibes en valor en efectivo”.
Aunque el resultado comercial real que obtiene un cliente y sus
preferencias juegan un papel importante en la determinación del valor de un
servicio, la percepción de este triunfa la mayoría de las veces. Lea la
definición de nuevo. Dice que más que los beneficios reales, la utilidad y la
importancia de un servicio son secundarias; cómo lo ve un cliente junto con
los sesgos inherentes juegan un papel crucial en la determinación del valor de
un servicio.
65
FUNDAMENTOS NÚCLEO
Como mencioné anteriormente en el capítulo, el valor no se crea de forma
aislada. Se crea conjuntamente entre el proveedor de servicios y el cliente.
Hubo días en que el proveedor de servicios desarrolló servicios que quizás
podrían beneficiar al cliente. Lo hizo en algunos casos y no lo hizo en el resto.
Esto se convirtió en un juego de acertar o fallar. Hoy en día, se trata de
seguridad. Si un proveedor de servicios va a invertir una cierta cantidad de
dinero, entonces necesita saber que lo va a lograr. Por lo tanto, se convierte en
un socio del cliente en lugar de un proveedor de servicios. Esta mera
percepción de ver al proveedor de servicios no como un proveedor de
servicios sino como un socio (¡en el crimen!) hace una gran diferencia en la
construcción de confianza que es la base de la creación de valor. El cliente
pide abiertamente lo que quiere y busca consejo donde lo necesita. El
proveedor de servicios ya no mira por encima del hombro y se abre con ideas
y chispas creando valor. Por lo tanto, el valor no nace de una entidad sino a
través del proceso natural de co-creación, como lo somos todos nosotros.
Aquí hay un ejemplo de la vida real de co-creación de valor. Nokia fabricó
algunos de los mejores y mejores teléfonos celulares durante los años 90 y
principios de los 2000. Con otros jugadores saltando al mercado con
innovaciones y Nokia aferrándose a sus armas exitosas, perdió el mercado por
mucho. Luego conocemos la historia de Microsoft comprándolo y conectando
el sistema operativo Windows a la infraestructura de Nokia. Estos teléfonos
eran terribles, no por el hardware sino por un sistema operativo fallido.
Entonces sucedió lo impensable. En una búsqueda por reconquistar el
mercado, Nokia tenía que crear valor para sus consumidores. El hardware era
excelente, por lo que cambiarlo estaba fuera de discusión. Aunque Microsoft
se define por el sistema operativo Windows, decidieron cambiar el sistema
operativo Windows por Android, un gigante que estaba dominando el mercado
en su camarilla y que era y es un serio competidor de iOS.
Al unir dos entidades dispares, Microsoft esperaba crear valor para sus
consumidores. El resultado final, aunque no fue un golpe en el pecho, fue
mejor que su experiencia anterior. El valor se trata de co-crear y con el cliente
jugando un papel central.
66
FUNDAMENTOS NÚCLEO
Resultados
El valor hasta ahora se ha definido como algo que se crea conjuntamente entre
el proveedor de servicios y el cliente. Además, sabemos que el valor es muy
subjetivo. Dos clientes pueden tener distintas percepciones del mismo servicio
y todo depende del cliente, por lo que la cocreación de un servicio de este tipo
tiene ventajas definitivas al adaptarlo a las necesidades de ese cliente.
Definición de salida de ITIL

Un producto tangible o intangible de una actividad.
Definición de resultado de ITIL
Un resultado para una parte interesada habilitado por uno o más
productos.
El cliente basa su juicio en los resultados que puede obtener de un

servicio. El objetivo que el cliente puede lograr debido al servicio es más
importante y pertinente en comparación con el resultado real. ¿Cuál es la
diferencia entre el resultado y la salida, podrías preguntarte?
Netflix es un servicio de entretenimiento que ofrece videos a pedido en
forma de películas, programas de televisión y documentales. Los resultados
son estos videos per se. Cada una de estas películas o episodios de un
programa de televisión pueden considerarse salidas.
Mientras que los productos son tangibles o medibles, los resultados son
intangibles. Un resultado es generalmente un resultado basado en uno o más
productos. En este ejemplo de Netflix, el resultado es si estuvo completamente
entretenido o no, o si pudo vincularse con sus hijos con una película familiar.
Este resultado podría deberse a un episodio de un programa de televisión
como "Anne with an E" o a la temporada completa que consta de varios
episodios. Tu gusto por el entretenimiento es solo tuyo. Es posible que la pase
de maravilla con este programa, mientras que la familia de al lado odia el
concepto de un programa basado en mediados del siglo XX y prefiere algo
científico como "Star Trek: Picard". Verá que el mismo programa que le
encanta a un cliente podría no ser el ganador para otro.
67
FUNDAMENTOS NÚCLEO
Consejo de examen recuerde que los servicios facilitan

el resultado a través de uno o más productos. La
diferencia entre un resultado y un resultado es una
pregunta probable en el examen. Si tiene dudas
persistentes, lea la sección nuevamente.
Otro aspecto a recordar con respecto a los resultados es que la propuesta

de valor cambia cuando entran en juego los factores subyacentes o
circundantes. Un domingo por la mañana con la final de Wimbledon
retransmitida por televisión en directo, la misma familia de "Star Trek: Picard"
preferirá sintonizar la televisión en directo en lugar del programa grabado. En
ese momento, por los factores que intervienen (un deporte que les gusta), su
preferencia ha cambiado. Su percepción de un servicio que tiene valor ha
cambiado.
Mientras finalizo esta sección, con respecto a la configuración de
métricas, defina métricas para los resultados y no para los productos. A
nadie le importa si Netflix tiene más de 10 000 películas en su estantería,
pero lo que importa es su popularidad entre los espectadores. Recuerde que
a menos que mida un resultado, nunca sentirá el verdadero pulso de un
cliente.
Costos
Los costos en ITIL generalmente se relacionan con las transacciones
financieras del consumidor del servicio al proveedor del servicio.
ITIL Definición de Costos

La cantidad de dinero gastado en una actividad o recurso
específico.
68
FUNDAMENTOS NÚCLEO
Según la definición de servicio, el cliente compra servicios por un precio
determinado. Este tema se centra en los elementos que determinan el costo de
un servicio.
En cualquier organización de servicios, la mayoría de los gastos se
destinan al empleo de personas. Los costos de personal se calculan mensual o
trimestralmente y, junto con los demás costos directos e indirectos, se
determina el costo total de un servicio. Una terminología común que
empleamos en la industria de TI para las personas es FTE, que significa
esfuerzo de tiempo completo. El FTE de una persona durante un cierto período
es el factor que determina el costo de un servicio. Por ejemplo, si estamos
calculando los costos de un período mensual, usamos el término meses-
hombre. La cantidad de meses-hombre necesarios para brindar un servicio a
un consumidor más los costos directos e indirectos agregados determina el
costo de un servicio.
Profundizando un poco más en los diferentes tipos de costes:
1. Costos directos que se imponen al cliente. El costo del
servicio en sí se incluye en los costos directos, además de
que el consumidor puede recibir otras funciones
adicionales como complementos, como asistencia
prioritaria y capacitación, que se cobrarán de forma
adicional.
2. Los costos indirectos son aquellos costos que

generalmente están detrás del precio de un servicio. Esto
podría incluir el costo de la infraestructura, las horas de
trabajo, los recursos o cualquiera de los otros costos que
no se imponen directamente al cliente, sino que se cobran
bajo la apariencia de un cargo por servicio.
Este es un mundo competitivo. El proveedor de servicios desconfía de los
costos del servicio y, en la mayoría de los casos, los costos se derivan no solo
de los factores internos sino también de sus competidores. Si bien intentan
mantener los precios competitivos, es importante que los proveedores de
69
FUNDAMENTOS NÚCLEO
servicios y los consumidores de servicios mantengan una relación de servicio
en la que todos ganan. El proveedor de servicios no debe estar en una posición
en la que rompa su banco mientras brinda servicios. Piense en Uber, que
ofreció viajes baratos para ganar mercado rápidamente, pero en el proceso se
desangraron bastante. El consumidor de servicios, por otro lado, no debe sentir
que los costos pagados por los servicios son una carga, sino que debe verlos
como una inversión necesaria. Esto sucede cuando el consumidor percibe que
el precio pagado está justificado. Entonces, para resumir esto, el costo de los
servicios debe ser acorde con el mercado, los gastos del servicio y las
expectativas de los clientes.
Desde la perspectiva del consumidor, necesita analizar el servicio ofrecido
en función de sus necesidades. Esto les dará motivos para elegir un servicio
que sea beneficioso para ellos. Me suscribo al programa HP Instant Ink en el
que no pago directamente por los cartuchos de tinta, sino por la cantidad de
páginas que imprimo. Cuando comencé el programa, solía suscribirme a 100
páginas al mes; después de un par de meses, revisando los informes
disponibles en su sitio web, me di cuenta de que ni siquiera estaba alcanzando
la mitad del objetivo por el que estaba pagando. Entonces, cambié a una banda
más baja donde pagué una fracción de los costos por imprimir 50 páginas al
mes. Como consumidor, estar al tanto de los números me ayudó a tomar una
decisión que me ahorra facturas innecesarias que puedo evitar.
Riesgos
Los riesgos son inherentes a todos los negocios, incluido el negocio de
proporcionar servicios de TI. Los empresarios más populares del mundo no
habrían alcanzado alturas máximas si no hubieran asumido riesgos en varios
casos. Un proveedor de servicios de TI debe asumir riesgos para salir
victorioso.
Cuando se concibe un servicio, viene con riesgos inherentes. No se pueden
evitar. Lo inteligente sería identificarlos y gestionarlos. Es como aprovechar
los rayos del sol para generar energía en lugar de permanecer en el interior
durante el día.
70
FUNDAMENTOS NÚCLEO
ITIL Definición de Riesgo
Un posible evento que podría causar daño o pérdida o
dificultar el logro de los objetivos.
En términos generales, los riesgos los asumen los proveedores de servicios

o los consumidores de servicios. Sin embargo, en ambos casos, el consumidor
del servicio debe estar preocupado/consciente de los riesgos que afectan a un
servicio:
1. Hay riesgos que el proveedor de servicios reduce o elimina

de un servicio. Consideremos el ejemplo de un servicio de
taxis como Uber. Reducen los riesgos y peligros de conducir
y estacionar en las ciudades al proporcionar viajes de punto
a punto por un costo determinado. Sin embargo, existen
riesgos que un consumidor podría enfrentar: digamos, por
ejemplo, que se pierda la conexión de datos del consumidor.
El consumidor perderá la posibilidad de reservar taxis. Para
mitigarlo, una empresa india llamada Ola tiene un mitigador
de riesgos al reservar taxis mediante el sistema de mensajes
cortos.
2. Hay riesgos que son inherentes al proveedor de servicios por
los cuales el consumidor de servicios sentiría el impacto en
los servicios. Considerando el mismo ejemplo, digamos que
no hay taxis disponibles en el área. Aunque el teléfono
celular e Internet funcionan bien, la falta de taxis hará que el
servicio quede inutilizable.
Conversaciones relacionadas con el riesgo

En realidad, en los servicios de empresa a empresa, los riesgos no se imponen
de un lado a otro y el otro lado no se lo toma de brazos cruzados. Recuerda
que el valor se crea conjuntamente. También lo son los riesgos, a modo de
discusiones seguidas de acuerdos. Si bien la gestión de riesgos es propiedad
71
FUNDAMENTOS NÚCLEO
del proveedor de servicios, el consumidor tiene mucha piel en el juego y
normalmente se involucra de las siguientes maneras para ser un socio activo
en la reducción de riesgos:
1. Definir los requisitos es un arte. Las organizaciones de clientes emplean
consultores de requisitos profesionales para definir los requisitos, incluida
la descripción detallada del apetito por el riesgo. Cuando se redactan los
resultados deseados, el cliente y el proveedor de servicios también
identifican, discuten y acuerdan los riesgos que posiblemente se pueden
definir y gestionar.
2. Al definir los requisitos y los resultados deseados, el cliente debe explicar

cuáles son los factores críticos de éxito y las limitaciones existentes. Por
ejemplo, un cliente que emplea una agencia de auditoría podría enumerar
la entrega oportuna de los informes de auditoría como un factor crítico de
éxito, y las reglamentaciones gubernamentales que se aplican se
identifican como las restricciones vigentes . La agencia de auditoría
(proveedor de servicios) tendrá que sortear la restricción en lugar de
encontrar una solución para mitigar la restricción.
3. Se trata de que el cliente y el proveedor de servicios trabajen de la mano.
A menos que un cliente confíe en que el proveedor de servicios tiene los
mejores intereses detrás de sus acciones, la mitigación de riesgos no será
del todo posible. El cliente debe aclararse declarando todos los factores y
brindando acceso a todos los recursos posibles para que la prestación del
servicio sea exitosa. Si se espera que un proveedor de servicios trabaje con
una parte de una empresa, el cliente debe proporcionar toda la
información pertinente, como la lista de partes interesadas, la arquitectura
subyacente, etc.
Nota Un factor crítico de éxito (CsF) es algo que

debe suceder para que un servicio, proceso, plan, proyecto
u otra actividad de TI tenga éxito.
72
FUNDAMENTOS NÚCLEO
Opciones de mitigación de riesgos
Aunque la mayoría de las organizaciones maduras identifican los riesgos que
pueden afectar a un servicio, no es práctico creer que los riesgos pueden
eliminarse por completo de un servicio. Los riesgos siempre existirán. La
probabilidad de que ocurra depende del contexto. Y para cada riesgo, se puede
trazar una estrategia para identificar el curso de acción. Las cuatro acciones
más utilizadas son las siguientes:
1. Prevención de riesgos : en algunos casos, los riesgos

pueden evitarse o eliminarse del sistema. Se puede
eliminar un riesgo o se puede negar la probabilidad de que
suceda. Ejemplo: El riesgo de incertidumbres de
infraestructura y conectividad del personal de servicio se
puede evitar cancelando la política de trabajo desde casa.
2. Transferencia de riesgos : cuando los riesgos no se puedan
evitar, intente transferirlos a una parte diferente. Ejemplo:
cuando alquila un automóvil, es posible que se produzca
una pequeña grieta en el parabrisas mientras viaja por
autopistas. En lugar de pagar sumas escandalosas a la
compañía de alquiler, podría comprar un seguro en exceso
y transferir los riesgos de una rotura del parabrisas o
cualquier otro daño a la compañía de seguros. Al pagar una
pequeña cantidad, ya no es responsable de los daños y ha
transferido con éxito los riesgos a la compañía de seguros.
73
FUNDAMENTOS NÚCLEO
3. Mitigación de riesgos : Para un riesgo identificado, es
posible encontrar una solución para contrarrestarlo cuando
se materializa. Ejemplo: aunque los servidores son
estables, siempre existe el riesgo de que uno se bloquee o
se bloquee. La aplicación alojada en él dejará de estar
disponible. Para mitigar este riesgo, puede equilibrar la
carga del servidor entre varios servidores o crear un
mecanismo de conmutación por error automático azul-
verde para que un servidor pasivo se haga cargo en caso de
falla del servidor activo.
4. Aceptación del riesgo : suponga que un riesgo no se puede
mitigar o evitar, y ninguna otra parte está lista para
transferirlo; no te queda más remedio que aceptarlo.
Cuando el riesgo se materialice, estarás listo para enfrentar
la música. Ejemplo: El anuncio del gobierno de un cierre
de todas las empresas debido a pandemias no tiene
precedentes. Aunque existen mecanismos de gestión de
desastres, una crisis global de este tipo no escatima ningún
plan en marcha. En tales casos, las empresas aceptan el
riesgo y afrontan las consecuencias.
Utilidad y Garantía
ITIL tiene algo que ofrecer a los profesionales de TI de todas las áreas técnicas
y de gestión. Los conceptos de utilidad y garantía son apreciados por aquellos
que son geeks por naturaleza y académicos de corazón. ITIL se deriva en gran
medida de la electrónica digital, por lo que si puede leer el circuito,
comprenderá bastante la lógica. La figura 3-3 diagrama la lógica de la utilidad
y la garantía de ITIL.
74
FUNDAMENTOS NÚCLEO
Figura 3-3. Diagrama lógico de utilidad y garantía
El valor se crea a partir de un servicio. Para desglosarlo aún más, digamos

que crea valor solo si es apto para el propósito y para el uso. La mayoría de las
veces, estos términos se usan y abusan en las organizaciones de TI sin que
nadie sepa su significado real. Entonces, intentemos entender qué significan
realmente estos dos términos. La Figura 3-4 presenta un diagrama de este
concepto.
Figura 3-4. Puerta lógica de creación de valor
Adecuado para el propósito se refiere a la funcionalidad de un servicio.

¿El servicio viene con todas las características y funciones que se supone que
debe llevar? ¿El servicio cumple con todos los requisitos funcionales? En caso
afirmativo, entonces una de las entradas en la puerta AND será Verdadera, y
eso nos lleva un paso más cerca
75
FUNDAMENTOS NÚCLEO
a la creación de valor. El servicio central de un proveedor de servicios
móviles es brindar la capacidad de hablar a través de teléfonos celulares. Si
esto se logra, entonces podemos considerarlo adecuado para su propósito.
Por otro lado, la aptitud para el uso se refiere a la capacidad de hacer uso
de la funcionalidad del servicio. A través de la funcionalidad del servicio, se le
brinda la capacidad de lograr ciertos resultados. Pero, ¿puedes hacer uso del
servicio? Si puede, esta entrada a la puerta AND será verdadera. Si apto para
el propósito también es Verdadero, entonces crea valor. Si alguna de las
entradas es falsa, entonces no se puede crear el valor. Es como tener una red
móvil y un instrumento móvil capaz pero sin suficiente ancho de banda para
permitirle pasar sus llamadas. Es como tener un televisor de última generación
pero sin electricidad para hacerlo funcionar.
La creación de valor se representa a través de una puerta AND. Consulte
la Tabla 3-1 para ayudarlo a comprender cuándo se crea el valor.
Tabla 3-1. Matriz de creación de valor

Adecuado
Apto ¿Valor
para el
para usar creado?
propósito
Verdadero Verdadero Sí
Verdadero FALSO No
FALSO FALSO No
FALSO Verdadero No
Utilidad de un Servicio
Definición ITIL de Utilidad de un Servicio
La utilidad es la funcionalidad que ofrece un producto o un
servicio para satisfacer una necesidad particular.
El diagrama lógico de la figura 3-5 muestra una puerta OR para la parte de

utilidad de un servicio.
76
FUNDAMENTOS NÚCLEO
Figura 3-5. Utilidad de un servicio
Para que un servicio sea adecuado para su propósito, debe cumplir con
uno (o ambos) de los siguientes criterios:
1. Rendimiento compatible
2. Restricciones eliminadas
Estos criterios se representan a través de una puerta OR, y la Tabla 3-2

proporciona las condiciones en las que el servicio sería adecuado para su
propósito.
Tabla 3-2. Condiciones para que un Servicio sea Adecuado para su

Propósito
¿Rendimiento ¿Restricciones ¿Adecuado para
compatible? eliminadas? el propósito?
Verdadero Verdadero Sí
Verdadero FALSO Sí
FALSO FALSO No
FALSO Verdadero Sí
Para que un servicio cree valor, debe cumplir ciertos criterios. Uno de esos
casos es su rendimiento. Un servicio debe mejorar inherentemente el
rendimiento de los resultados comerciales que desea el cliente. Por ejemplo,
un servicio de telefonía móvil debe proporcionar eficiencia al cliente para
permitir una mejor comunicación.
El segundo criterio para el que se aplica la idoneidad son las restricciones
que se pueden eliminar a través del servicio. Si el servicio puede eliminar
77
FUNDAMENTOS NÚCLEO
barreras para un cliente, podría cumplir con los términos del servicio si es apto
para el propósito. El proveedor de servicios móviles, al brindar la capacidad de
realizar llamadas mientras juega al golf, elimina las limitaciones que
normalmente existirían si tuviera que detenerse en la mitad del juego, regresar
a su oficina y realizar la llamada. En este caso, las restricciones se han
eliminado a través del servicio que ofrece el teléfono móvil.
Para que un servicio se ajuste a su propósito, debe aumentar el
rendimiento o eliminar las limitaciones. Si puede hacer ambas cosas, mejor.
Garantía de un Servicio
Definición ITIL de Garantía de un Servicio
La garantía proporciona seguridad de que un producto o
servicio cumplirá con los requisitos acordados.
La garantía consta de cuatro partes:
1. ¿El servicio está disponible cuando se necesita?

2. ¿Hay suficiente capacidad disponible?
3. ¿El servicio es continuo?

4. ¿Es seguro el servicio?
Los cuatro criterios deben cumplirse para que el servicio sea apto para su
uso. Esto se representa a través de un diagrama AND, como se muestra en la
Figura 3-6 .
78
FUNDAMENTOS NÚCLEO
Figura 3-6. Garantía de un servicio
La Tabla 3-3 proporciona los criterios para garantizar que el servicio sea
apto para su uso. No es completo para todas las permutaciones y
combinaciones. La compuerta AND proporciona una salida FALSA siempre
que cualquiera de las entradas sea FALSA.
Tabla 3-3. Condiciones para que un Servicio sea Apto para su Uso
disponibl ¿Capacida Adecuad
e d ¿Suficientemen ¿Suficientemen o
suficiente suficiente te continuo? te seguro?
? ? ¿Usar?
Verdadero Verdadero Verdadero Verdadero Sí

Verdadero Verdadero Verdadero FALSO No
Verdadero Verdadero FALSO Verdadero No
Verdadero FALSO Verdadero Verdadero No
FALSO Verdadero Verdadero Verdadero No
Las siguientes ilustraciones proporcionan ejemplos de cada criterio que
debe cumplirse para que el servicio sea apto para su uso.
disponible suficiente?
Se suscribe a un servicio de telefonía celular y paga una prima por ese
servicio. Ahora te vas de vacaciones. Cuando llega a su resort, se queda
estupefacto al ver que el proveedor de servicios móviles no tiene cobertura
dentro del resort. ¿El servicio le brinda algún valor, aunque el proveedor
afirmó brindar muchas funciones? ¡Definitivamente no!
¿Capacidad suficiente?
Estás atrapado en un atasco de tráfico. Quiere llamar a su pareja para
informarle que no se reunirá con él para cenar, debido al terrible tráfico de la
ciudad. Tiene cobertura de servicio, pero la llamada no se realiza. El
proveedor de servicios no tiene capacidad suficiente para manejar llamadas
79
FUNDAMENTOS NÚCLEO
desde esa torre celular en particular. Aunque hay cobertura, si no puedes
hacer llamadas, ¿el servicio agrega valor? No.
80
FUNDAMENTOS NÚCLEO
¿Suficientemente continuo?
Está en medio de la ronda telefónica de una entrevista para una empresa con sede
en el extranjero. La llamada cae cada pocos minutos, lo que lo distrae de las ideas
que desea expresar y, por lo tanto, lo hace perder el hilo de sus pensamientos. El
servicio tiene cobertura y capacidad suficiente, pero ¿te está dando el valor que
percibes? ¡Diablos no!
¿Suficientemente seguro?
Está llamando a su departamento de recursos humanos para discutir la evaluación
que le ha dado su gerente. ¿Cómo se sentiría si su gerente pudiera acceder a través
de la nube a la conversación que está teniendo desde los confines de su hogar, con
la persona de recursos humanos en un continente diferente? ¿El servicio le está
dando valor? Tu sabes la respuesta.
Nota Cuando realizamos evaluaciones de servicios,

generalmente observamos los diversos aspectos de la
utilidad y la garantía del servicio y los riesgos a los que
están expuestos. por supuesto, los costos de un servicio
también se consideran durante las evaluaciones.
En resumen de estos ejemplos, para que se cumplan las condiciones de

garantía del servicio de telefonía celular, el servicio debe estar disponible, tener
capacidad suficiente, debe ser continuo y debe ser seguro. Si alguno de estos
elementos no está en su lugar, el servicio de telefonía celular no es apto para su
uso y no agrega valor.
Consejo de examen Si no se siente cómodo con las

puertas y tablas lógicas, desde el punto de vista del
examen, aún está a salvo. en el examen no se pondrá a
81
FUNDAMENTOS NÚCLEO
prueba su conocimiento sobre la fórmula de creación de
valor. Más bien, se someten a escrutinio los elementos que
componen un servicio y los significados en torno a que un
servicio sea apto para su propósito y apto para su uso.
Consejo de examen De esta sección (Valor), puede

esperar que aparezcan un mínimo de dos preguntas y un
máximo de tres preguntas en su examen de Certificación de
Fundamentos de ITIL.
Ofertas de servicios
Al igual que un plato de platos en una tarjeta de menú, un proveedor de servicios
tiene una lista de ofertas de servicios que se pone a disposición de los clientes.
Las ofertas de servicios están diseñadas para proporcionar opciones para un
cliente, mantener atractiva la gama de servicios del proveedor de servicios y, lo
que es más importante, está destinada a satisfacer todas las necesidades del
cliente.
Las ofertas de servicios se construyen esencialmente sobre los productos del
proveedor de servicios jugando con permutaciones y combinaciones de
complementos, accesos y el nivel de soporte. Entonces, en esencia, el servicio
debe tener un producto decente para establecer como base y construir servicios
sobre él. Por ejemplo, los servicios de transmisión web como Netflix y Amazon
Prime se basan en el producto que transmite videos. Usando esto como un
producto central, ofrecen múltiples opciones para que los clientes elijan.
Definición ITIL de una oferta de servicio

Una descripción formal de uno o más servicios, diseñada para
abordar las necesidades de un grupo objetivo de consumidores.
82
FUNDAMENTOS NÚCLEO
Las ofertas de servicios pueden basarse ampliamente en las siguientes
divisiones:
1. Los productos del proveedor de servicios se pueden vender al cliente como
bienes, lo que significa que es una transacción única en la que los bienes se
transfieren del proveedor de servicios al cliente. Cuando se produce la
transferencia, la responsabilidad de la conservación del
producto cae en el regazo del cliente. Tomemos, por ejemplo, cuando

compra una computadora portátil: en el momento en que se le entrega el
producto, usted se vuelve responsable de cómo se mantiene y usa.
Esta opción pronto pierde impulso, ya que el proveedor de servicios ha
visto potencialmente el final de una relación de servicio y no hay nada que
detenga al cliente. Tomemos otro ejemplo de las ventas de automóviles.
Cada vez es más evidente que los concesionarios ofrecen opciones
lucrativas a los clientes para arrendar un automóvil en lugar de comprarlo
directamente.
2. El segundo tipo de oferta es cuando el proveedor de servicios brinda acceso a

los clientes a los recursos del servicio para ser utilizados bajo ciertos
acuerdos establecidos. La gestión de los servicios sigue estando en manos del
proveedor del servicio, pero el cliente es libre de usarlo bajo un conjunto de
términos y limitaciones.
Netflix y Amazon Prime son ejemplos clásicos. Los servicios de
transmisión poseen el contenido digital y permiten a los clientes verlo en
cualquier momento por una tarifa mensual. Asimismo, el contrato de
arrendamiento de automóviles es un tipo de servicio de suscripción en el
que el cliente paga los costos periódicos por el uso del automóvil. El
cliente también se libera del mantenimiento y otras costosas
responsabilidades. Al optar por él, el cliente disfruta del coche a una
pequeña fracción de un coste que paga periódicamente (mensualmente en
general) y no tiene que preocuparse por su mantenimiento. Por otro lado, el
cliente nunca se convertirá en el (orgulloso) propietario del automóvil.
83
FUNDAMENTOS NÚCLEO
Utilizando el mismo producto, un proveedor de servicios puede ofrecer
diferentes variantes de servicios para embellecer la lista de servicios.
Usando el mismo ejemplo, Netflix ofrece su lista completa de ofertas
de transmisión en definición estándar, que es la oferta de servicio más
barata, seguida de HD y UHD a un precio más alto. Amazon Prime,
además de ofrecer videos para transmisión, ofrece películas y
programas de televisión para alquilar y también para comprar a un
precio único. Brindar variantes es beneficioso para que el proveedor de
servicios apunte a diferentes sectores de clientes con contenido y
complementos enfocados. Es beneficioso para los clientes porque solo
pagan por lo que necesitan y no por todas las campanas y silbatos que
no utilizan.
3. Los últimos en la lista de ofertas de servicios son acciones de servicio. Son la
parte de mantenimiento de las ofertas de servicio, como proporcionar soporte
de producto y garantía.
Casi todos los productos y servicios que se venden hoy vienen con
soporte y garantía. Sin las acciones de servicio adicionales, el producto
(bienes) o servicio no es tan valioso. La mayoría de los proveedores de
servicios agregan los costos relacionados con las acciones de servicio en
el precio general de los bienes y servicios para garantizar que el cliente
no sienta la carga de comprar soporte de servicio y garantía por
separado.
El soporte de servicio y la garantía también vienen en variantes. Un cliente

podría comprar soporte básico donde nunca hablaría con otro ser humano
del otro lado o pagaría más por soporte telefónico e incluso un ingeniero de
campo para visitar el hogar. La garantía también se puede extender por
períodos de tiempo adicionales por un costo adicional.
Consejo de examen La mejor manera de comprender los

diferentes tipos de ofertas de servicios es a través de las
84
FUNDAMENTOS NÚCLEO
ilustraciones que he ofrecido. Para reiterar, el primero es
comprar un producto como una computadora portátil, el
segundo es una suscripción como netflix y, finalmente, el
tercero es soporte de servicio y garantía.
Relaciones de servicio
Un servicio no puede prosperar si se desarrolla en una organización y es utilizado
por otra. El servicio solo puede mejorar y alcanzar los resultados deseados si es
un esfuerzo conjunto entre las dos entidades. Hemos llamado a este valor creación
conjunta entre el proveedor de servicios y el consumidor de servicios. Para que
esta empresa conjunta de generación de valor suceda, debe haber confianza entre
las dos entidades. La confianza se construye a través de una asociación
formidable o una relación de servicio en la que el consumidor del servicio es
transparente acerca de las necesidades, los deseos y las limitaciones existentes.
Por otro lado, el proveedor de servicios también aclara lo que es posible, lo
que puede ser posible y los desafíos a la mano. A través de esta transparencia
cristalina absoluta, la relación de servicio entre el proveedor de servicios y el
consumidor de servicios fortalece y beneficia mutuamente a ambas
organizaciones en el trabajo hacia el éxito de cada uno, más aún desde la
perspectiva del consumidor de servicios.
Definición de relaciones de servicio de ITIL

Una cooperación entre un proveedor de servicios y un
consumidor de servicios. Las relaciones de servicio incluyen la
provisión de servicios, el consumo de servicios y la gestión de
relaciones de servicios.
85
FUNDAMENTOS NÚCLEO
La prestación de servicios
El proveedor de servicios proporciona servicios. En esta sección, enumeraré las
responsabilidades de un proveedor de servicios en el suministro de servicios.
La siguiente lista no es exhaustiva, pero desde el punto de vista del examen es
suficiente y completa:
• Un proveedor de servicios gestiona todos los recursos que se
utilizan en la prestación de servicios. Esto podría incluir
infraestructura, software e instalaciones. La gestión de recursos se
refiere a la gestión de la configuración y el ciclo de vida de estos
activos.
• Ejemplo: Netflix es responsable de mantener un catálogo de su

contenido, administrar la infraestructura que se utiliza para alojar
el contenido, el software que lo respalda, las personas que lo
mantienen y todo lo demás que se requiere para la creación del
servicio de transmisión de video. El proveedor de servicios es
totalmente responsable de esto.
• Según el acuerdo con el cliente, el proveedor de servicios debe
proporcionar accesos y debe asegurarse de que los accesos
permanezcan activos durante todo el plazo del acuerdo.
• Ejemplo: Netflix tiene la responsabilidad de brindar acceso a su

contenido de video según la suscripción que elija un cliente.
• El proveedor de servicios debe estar al tanto del pulso del servicio
para verificar su desempeño y si está logrando los resultados que
el cliente pretende. El proveedor de servicios también debe
asegurarse de que el servicio mejore de manera regular y no se
estanque.
• Ejemplo: Netflix recopila todas las estadísticas que puede recopilar

a través de su software y su interfaz web. Sabe cuál de sus
contenidos de video es popular y en qué geografía. Esta
86
FUNDAMENTOS NÚCLEO
información es pertinente para que la empresa tome decisiones
comerciales, ya sea eliminar o renovar programas y el género de
contenido que preferiría la mayoría. Desde una perspectiva de
mejora continua, Netflix tiene que alimentar a sus clientes con
contenido nuevo cada semana, mejorar las velocidades a través de
sus redes de entrega de contenido y mejorar el sistema de
catalogación y navegación del software si quiere mantener a su
rebaño unido. Hoy en día existen varios servicios de este tipo y
Netflix no puede darse el lujo de dar por sentado a sus clientes.
• Las acciones de servicio, como el soporte del servicio, deben
convertirse en una parte inherente del servicio (basándose en el
acuerdo de servicio, es decir). Esto podría incluir opciones de
soporte por correo electrónico, teléfono y chat. En caso de
adquisición de bienes, también podría venir con garantía y
devolución de bienes.
• La composición de una empresa de servicios se ve a través de la

lente de su apoyo. Por lo tanto, cualquier proveedor de servicios
que esté en el negocio de la gestión de servicios debe asegurarse
de que el servicio proporcionado sea de primera línea. Las buenas
acciones de servicio darán lugar a negocios continuos de sus
clientes y el buen boca a boca les dará más ventas.
• Finalmente, el proveedor de servicios es responsable del
suministro (entrega) de los bienes que compra el cliente. Es
posible que el proveedor de servicios cobre gastos de envío a los
clientes. Sin embargo, la responsabilidad de entregarlo al cliente
recae en el proveedor del servicio.
87
FUNDAMENTOS NÚCLEO
Consumo de servicios
Solo cuando el proveedor del servicio ofrece el servicio, y es de mutuo acuerdo
con el cliente, comienza el consumo del servicio. En el lado receptor de un
servicio, se pueden esperar las siguientes responsabilidades:
• Se espera que el consumidor/cliente del servicio garantice que
los recursos necesarios para que los usuarios disfruten del
servicio estén disponibles. Por ejemplo, veamos el ejemplo de
Netflix, en el que el proveedor de servicios ofrece millones de
opciones de contenido de video y el usuario debe asegurarse,
como mínimo, de que haya una conexión a Internet que
funcione y un televisor/teléfono celular/computadora
inteligente para disfrutar del contenido. servicio.
• Cuando el servicio ofrecido no funciona como se esperaba o

si es necesario realizar una nueva solicitud, se espera que el
consumidor del servicio utilice la parte de acciones de
servicio del servicio para cumplir con la solicitud o restaurar
el servicio.
• Si se trata de bienes, después de que el proveedor de servicios
envíe los bienes, es necesario recibirlos para completar la
transacción del servicio. Esto es similar a recibir un paquete
de Amazon.
88
FUNDAMENTOS NÚCLEO
Modelo de relación de servicio

Al comienzo de esta sección hablé sobre la relación de servicio. Estas son las
actividades que se pueden realizar en conjunto para la creación conjunta de valor y
para que ambas partes puedan obtener beneficios de la transacción comercial.
El mundo de la gestión de servicios es complicado. Un proveedor de un
servicio termina siendo un consumidor de otro servicio. Esto podría suceder en
muchas a muchas relaciones. En cualquier momento dado, todos nosotros, como
individuos u organizaciones, actuamos como proveedores de servicios para otros
individuos u organizaciones o terminamos siendo consumidores de servicios de
otros individuos u organizaciones. Esto se representa en la Figura 3-7 .
Figura 3-7. Modelo de relación de servicio
Cada uno de los engranajes se refiere a las ruedas dentadas que hacen que
suceda un servicio, ya sea en provisión o consumo. Comencemos desde la derecha
con la ilustración que he usado hasta ahora sobre este tema: el servicio Netflix
para transmisión de video. El espectador es un consumidor de servicios en este
ejemplo y tiene una relación de servicio con Netflix como proveedor de
transmisión de video.
Si bien Netflix actúa como proveedor de servicios para el espectador, consume
los servicios de red de entrega de contenido ofrecidos por Akamai. En esta
relación, Netflix es un consumidor de servicios mientras que Akamai es un
proveedor de servicios.
89
Más adelante, Akamai consume servicios de Microsoft Azure para las
necesidades de su centro de datos. Entonces, en esta relación, Akamai, que jugó
como proveedor de servicios para Netflix, se está poniendo el sombrero de
consumidor de servicios y Microsoft Azure como proveedor de servicios. También
es posible que el espectador sea un consultor de DevOps contratado por Microsoft
para realizar una verificación de viabilidad. Si este es el caso, Microsoft Azure se
convierte en un consumidor de servicios para el espectador que se convierte en un
Consejo de examen De esta sección (ofertas de servicio y

relaciones de servicio), puede esperar que aparezca una
pregunta en su examen de Certificación de Fundamentos de
ITIL.
Verificación de conocimientos
Las respuestas se proporcionan en el Apéndice.
3-1. ¿A qué definición se refiere?
Una persona o un grupo de personas que tiene sus propias

funciones con responsabilidades, autoridades y relaciones
para lograr sus objetivos.
A. Patrocinador
B. Proveedor de servicio
C. Organización
D. Cliente
3-2. ¿Cuál de los siguientes factores es importante para que un
servicio sea adecuado para su propósito?
90
A. Garantía
B. Utilidad
FUNDAMENTOS NÚCLEO
C. Valor
D. Continuidad
3-3. ¿Quién soy yo si soy transparente sobre mis necesidades,

deseos y las limitaciones que existen?
A. Proveedor de servicio
B. Consumidor de servicios
C. Organización de servicios
D. Solicitante de servicio
3-4. ¿Cuáles de estos están relacionados con los resultados para
una parte interesada?
A. Producción
B. Riesgos
C. Resultado
D. Garantía
3-5. ¿Cuál de estos no es un ejemplo de una oferta de servicio?

A. Proporcionar acceso a los recursos del proveedor de servicios
B. Bienes por cobrar

C. Acciones de servicio como generar incidentes
D. Cantidad de dinero gastado en una actividad específica
91
CAPÍTULO 4
Enfoque
holístico de la
gestión de
servicios:
cuatro
dimensiones
La gestión del servicio no es lineal. Si bien hay múltiples aspectos y
componentes que intervienen en la creación de un servicio, hay varios otros en
el lado del consumo. Ambos conjuntos de componentes tienen que encontrar
el verdadero norte y colaborar para crear valor. Estos diversos componentes
que fabrican y consumen servicios de TI se reúnen en un modelo llamado
cuatro dimensiones de gestión de servicios.
Este capítulo explora las cuatro dimensiones/cuadrantes de la gestión de
servicios, y la responsabilidad no se detiene en estos cuatro cuadrantes. Hay
varios otros factores externos que influyen en la entrega y el consumo. Vamos
a examinarlos con ojo de halcón y profundizar en los matices.
CAPÍTULO 4 ENFOQUE HOLÍSTICO PARA LA GESTIÓN DE
SERVICIOS: CUATRO DIMENSIONES
Consejo de examen Las cuatro dimensiones de la
gestión de servicios dan cuenta de dos preguntas en el
examen de Fundamentos de ITIL.

4842-6361-7_4
CAPÍTULO 4 ENFOQUE HOLÍSTICO PARA LA GESTIÓN DE SERVICIOS:
CUATRO DIMENSIONES
Las cuatro dimensiones

El equilibrio es esencial en todo lo que hacemos. Un ejemplo clásico es una
dieta que se basa en el equilibrio. Casi todos los nutricionistas le dirían que
tenga ciertos grupos de alimentos en cada comida. Aunque los carbohidratos
son más temidos en estos días que las grasas, aún son necesarios para
brindarle la energía que necesita para operar durante el día. Las proteínas son
los componentes básicos para el crecimiento y la reparación de los tejidos del
cuerpo. Las verduras contienen varias vitaminas, minerales, fibra y
antioxidantes que contribuyen a un metabolismo saludable. Entonces, el
consejo sería consumirlos todos con moderación. Este es el secreto de un
cuerpo sano y atractivo. Además, querrás alimentos procesados como
chocolates y postres que en su mayoría son grasos, pero sacian tus antojos
mentales.
Asimismo, en el campo de la gestión de servicios, los servicios son muy
parecidos a nosotros.
Necesitan todos los componentes constituyentes para su crecimiento y salud.
El desarrollo en un área y el abandono en el resto introducirán inestabilidad
que alejará aún más al servicio de alcanzar sus objetivos. Al igual que los
diferentes grupos de alimentos para una dieta saludable, hay cuatro
dimensiones que se identifican como componentes constitutivos de un
servicio. Ellos son:
1. Organización y personas
2. Información y tecnología
92
3. Proveedores y socios
4. flujos de valor y procesos
Las cuatro dimensiones deben trabajar al unísono en la creación de valor

para el cliente de la manera más efectiva y eficiente. Esto se ilustra en la
Figura 4-1 .
Figura 4-1. Cuatro dimensiones de la gestión de servicios
Las cuatro dimensiones, aunque indicadas como cuatro entidades

separadas que trabajan por una causa común, no son tan distintas y separadas
como parece. Hay muchas áreas grises entre las dimensiones o aspectos que
utilizan múltiples dimensiones. Por ejemplo, los socios y proveedores pueden
93
ser parte de un flujo de valor, lo que requiere considerar ambas dimensiones
bajo una sola vista en lugar de distintas.
El siguiente punto a tener en cuenta es que los servicios de TI no operan
en una cámara de vacío. Operan en un ambiente donde los cambios son
rápidos y
CUATRO DIMENSIONES
ineludible. Antes del comienzo del año 2020, ¿quién hubiera imaginado que
un virus podría detener el mundo por completo en solo unos 3 meses? Los
servicios de TI no son inmunes a factores que están fuera de las dimensiones.
Estos factores contextuales se conocen como factores externos. Veremos esto
en detalle más adelante en este capítulo.
Nota Las cuatro dimensiones de la gestión de

servicios son aplicables a todos los servicios de TI.
Cuando cada servicio se analice bajo un poderoso
conjunto de lentes, podrá identificar los componentes
que encajan en cada una de las cuatro dimensiones.
Esta categorización le proporcionará la munición para
rejuvenecer y energizar las áreas de manera equilibrada.
Organizaciones y Personas
Los servicios están a cargo de personas, y las personas son impulsadas y
guiadas por organizaciones. Es la dimensión más crítica y se considera la
primera dimensión de la gestión del servicio.
El área de recursos humanos en la que se encuentran las organizaciones y
las personas es un amplio campo de juego que ha estado en continuo
desarrollo durante años y estará en la misma etapa durante los años y siglos
venideros. Comprender la psicología humana y decodificar las necesidades es
un campo emergente. Desde la perspectiva de la dimensión de la gestión de
servicios, nos interesan específicamente los siguientes aspectos:
94
• Estructuras organizativas
• Cultura
• Funciones y responsabilidades
• Liderazgo
Vista de pájaro de las estructuras de la

organización
Las organizaciones vienen en varias formas, estructuras y volúmenes.
Tenemos empresas oceánicas como IBM y Wipro que están repartidas por los
continentes y tienen cientos y miles de empleados trabajando para ellos y para
sus clientes. Y luego tenemos empresas emergentes donde toda la fuerza de la
empresa podría ser de un solo dígito y, con suerte, el doble. Entre las nuevas
empresas y las corporaciones globales, existe una amplia gama de
organizaciones que varían en tamaño y estructura.
Cada organización elige una estructura que funcione para ella. No hay una
estructura correcta o incorrecta. De hecho, casi todas las organizaciones
cambian su estructura en función de la atmósfera y las circunstancias
cambiantes.
El brindis de la tendencia actual es por una estructura horizontal donde
una organización no construye una organización en capas tipo lasaña. Más
bien, construye una organización plana que tiene capas mínimas y el empleado
ubicado en la parte inferior tiene acceso sin obstáculos al hombre superior.
Esto es común en la mayoría de las organizaciones emergentes y se ha
convertido en sinónimo de organizaciones que practican los principios ágiles.
Como mencioné anteriormente, nada es simple y directo. Si bien esta
estructura plana podría funcionar en una organización que tiene decenas de
empleados en su nómina, para un gigante como IBM prácticamente no es
posible. Una empresa de 350.000 personas no puede tener una organización
plana. Simplemente no es factible. Optan por varias capas para garantizar que
la estructura se adapte a la prestación eficaz y eficiente de los servicios. Las
organizaciones estructuradas verticalmente construyen capas basadas en las
responsabilidades de liderazgo, gestión y entrega.
95
Consejo de examen Mientras que las
organizaciones estructuradas planas tienden a ser
ágiles, las organizaciones estructuradas verticalmente
están impulsadas por procesos. Los procesos
aseguran que el servicio se entregue a tiempo y dentro
de las estipulaciones establecidas. Puede esperar una
pregunta sobre la estructura de las organizaciones en
su examen.

CUATRO DIMENSIONES
Las organizaciones planas son simples y la estructura hace su trabajo en

una comunicación transparente; en esencia, todos en la organización tendrán
una idea bastante buena de lo que están haciendo los demás.
Las organizaciones verticales están aisladas. Cada silo tiene su propio
conjunto de responsabilidades y entregas, y se espera que las personas
dentro de un silo practiquen una comunicación transparente. Sin embargo,
el desafío surge de la ubicación exacta de la estructura. ¿Cómo se
estructurará la organización? ¿Se colocará en silos a las personas con
habilidades similares? Entonces, durante la prestación de servicios o el
desarrollo de productos, ¿se juntan bajo una estructura organizada
matricial? Estas son algunas de las preguntas difíciles para las que los
líderes deben encontrar respuestas antes de determinar los complejos
estructurales.
Como mencionamos en el Capítulo 2 , una estructura DevOps intenta
romper los silos tal como los conocemos y acerca a las personas al producto
que se está desarrollando y administrando. En esencia, reunir a personas
conectadas con productos en un equipo es un silo en sí mismo, un silo que
alberga varios conjuntos de habilidades en lugar de una especialidad. Si bien
los silos en sí mismos no son malos, la estructura DevOps brinda la máxima
oportunidad de crear valor a través de estructuras de equipo. De hecho, la
mayoría de las organizaciones de hoy en día se están alejando de sus
estructuras tradicionales y se están adentrando en una estructura DevOps.
96
¡No solo estructuras, también cultura!

Es razonable y necesario cambiar las estructuras de una organización para
garantizar la máxima eficacia y eficiencia y minimizar los conflictos. Pero
eso solo no puede hacer la magia. La cultura subyacente que impregna una
organización importa mucho más que la estructura.
La cultura se trata de la psicología de la organización. ¿La organización es
intolerante con el desacato a la ética? ¿Es la organización respetuosa de los
deseos y deseos de los empleados desde una perspectiva de carrera? ¿La
organización es transparente en la toma de decisiones? ¿La organización
promueve la comunicación abierta? Estas son algunas de las preguntas que
pueden determinar la cultura de una organización, y esta eventualmente va a
determinar el valor que genera para sus clientes. Porque no vas a tener
empleados felices y satisfechos con una cultura que no los apoye a ellos ni a
sus aspiraciones, en pocas palabras.
Nota Devops promueve la cultura de las

responsabilidades compartidas y la inocencia. A través de
estos rasgos culturales, la aspiración es construir un
equipo que colabore y trabaje como una sola unidad en
lugar de silos con metas y objetivos en conflicto.
¿Cómo se forma una cultura? No es algo así como una estructura donde
podría cambiarla de la noche a la mañana usando un programa de Visio. La
cultura se filtra desde arriba hacia las distintas partes de la organización. Los
líderes deben imbuir los aspectos culturales de una organización, comenzar a
promoverla con sus subordinados y esperar que sus subordinados transmitan
el mensaje a sus subordinados. Los líderes tienen que compartir la visión y las
metas con el resto de la organización. No hay manera más fácil de construir la
cultura deseada en una organización. Es un trabajo duro y arduo que requiere
predicar a través del seguimiento. El área de gestión del cambio
organizacional profundiza en estos aspectos de la construcción de cultura.
97
Roles de las personas y sus

responsabilidades
Sin duda, debemos reconocer que las personas hacen que los servicios
sucedan. Sin personas, no importa cuántas actividades automaticemos, no se
corresponde con lo que las personas pueden hacer. Por lo tanto, el recurso
humano debe ser preservado, protegido y nutrido. Las estructuras y culturas
organizacionales son los cimientos que deben estar en su lugar antes de
responsabilizar a las personas de ciertas áreas de actividad.
“Personas” incluye a aquellos en posiciones de liderazgo, así como a los
empleados en los niveles inferiores de gestión y contribución individual.
98
Incluye funciones administrativas que permiten a los empleados trabajar para
servicios como recursos humanos, adquisiciones y administración, entre otros.
Elegir a las personas adecuadas es un hueso duro de roer. No he conocido una
organización que tenga todos sus patos en fila. Siempre están buscando a la
persona adecuada y tratando de cortar, cambiar y experimentar con opciones.
Las organizaciones deben tener a sus líderes correctos, más temprano que
tarde. A estos líderes se les encomendará comenzar a elegir a las personas de sus
equipos, las personas que entregan y las personas que pueden marcar la diferencia
en este juego de generación de valor. ¡Elegir líderes es absolutamente crítico!
Después de que los líderes eligen sus equipos, deben especificar sus roles y
responsabilidades. Deben asegurarse de que se tengan en cuenta las aspiraciones,
las habilidades y los intereses de la persona al definir los roles y las actividades
de las que la persona es responsable. En las organizaciones planas, los roles no
significan demasiado debido a la competencia reducida y, por lo general, las
responsabilidades tampoco están restringidas a una sola área de estudio. Por
ejemplo, también se puede esperar que un jefe técnico gestione las adquisiciones
y las ventas. Por lo tanto, es posible que los roles no importen demasiado en las
organizaciones más planas, pero definitivamente lo hacen en las organizaciones
verticales. El nivel de competencia es significativamente más alto y el rango de
responsabilidades será bastante estrecho. Un administrador de Unix no puede
hacer mucho más que administrar Unix en una corporación global. Por lo tanto,
es bastante probable que este empleado busque caminos que le prometan más
acción.
Gestionar las aspiraciones profesionales es una tarea difícil y debe gestionarse
sin excusas. Las personas que trabajan en un campo en particular se aburrirán de lo
que hacen, y su aburrimiento se hará visible en los productos de su trabajo en un
momento u otro. Antes de llegar a este punto, se deben comprender las
aspiraciones de un empleado y se deben tomar medidas de apoyo. Por ejemplo, el
aprendizaje continuo es uno de los elementos clave para la mayoría de las personas
que trabajan en TI. A casi todo el mundo le gusta aprender nuevas habilidades y
avanzar en su carrera, por lo que la cultura de la organización debe construirse
para apoyar a sus empleados en sus proyectos futuros.
99
Cuando hablamos de personas en esta dimensión, el alcance son todas las
personas involucradas en la prestación de servicios y la creación de valor. Podrían
ser personas de la organización del cliente que desempeñen el papel de propietario
del producto; podrían ser los ingenieros de una organización proveedora; o incluso
podría ser la persona involucrada en el área de ventas. Llevamos a todos a lo largo
del viaje.
Consejo de examen roles y responsabilidades es un gran

tema, y el cielo es el límite cuando hablamos de lo que se
puede aprender. Desde la perspectiva del examen, es
importante señalar que la identificación de roles y sus
responsabilidades es una tarea crítica que se realiza en la
gestión de servicios.
Inicié mi carrera en el área de ITIL, primero con operaciones y luego como

consultor. Mi interés en el tema me llevó a posiciones más altas, más
responsabilidades y la oportunidad de desarrollar marcos basados en los requisitos
del cliente. Mientras hacía más de eso, me volví experto en ver el mundo más allá
de ITIL. Con un poco de suerte, pasé al campo Agile y DevOps, y desempeñé
varios roles, incluido un maestro de scrum, gerente de proyectos ágiles, gerente de
programas, consultor de DevOps y arquitecto de DevOps. Aunque soy un
arquitecto DevOps consumado en mi organización, no he dejado de aprender. He
estado estudiando tecnologías más nuevas y adaptando metodologías para que se
ajusten al esquema DevOps para productos COTS (Commercial Off The Shelf). Al
mantenerme ocupado aprendiendo y creciendo en mi campo, siempre he sentido
que estoy en la carrera de elección donde el horizonte para crecer y aprender se
expande día a día.
Asuntos de liderazgo
Dicen que un líder es tan bueno como el equipo. Esto es cierto, pero es una calle
de doble sentido. Un líder inspirado puede cambiar la suerte de un equipo, una
100
organización o incluso una nación. Es primordial que la persona que lidera a la
gente conozca el verdadero norte: los objetivos de creación de valor.
Hay varios estilos de liderazgo y todos los caminos nos llevan a un destino
común. No es importante qué estilo encarna un líder, pero es importante que un
líder esté en el lugar para liderar el equipo. El objetivo de esta sección no es entrar
en los detalles del liderazgo. Hay varios textos disponibles sobre el tema. Utilicé
esta sección específicamente para concienciar sobre la importancia del liderazgo
en la dimensión de organización y personas de la gestión de servicios.
Todos los caminos conducen al valor

Hasta ahora en este libro, sin importar lo que haya tocado, he aterrizado de una
forma u otra en la importancia del valor. Con la entrega de servicios, un
proveedor de servicios entrega valor. Esto es lo que impulsa a un proveedor de
servicios a crear el producto, el servicio y todo lo que se construye a su alrededor.
Sin valor, no hay nada.
Por lo tanto, es absolutamente imperativo que todos los involucrados estén
orientados hacia el verdadero norte: el valor que se está creando. Esto puede ser
posible filtrando una comprensión clara de qué acciones conducen a la entrega de
valor para el cliente y cómo todos los involucrados pueden trabajar de manera
colaborativa con un solo objetivo. Podría ser a través del equipo que se acerca al
servicio como un equipo DevOps o a través de un enfoque de entrega enfocado.
No hay una forma particular de lograr valor; pero cualquiera que sea la forma
identificada, debe lograrse como una sola unidad.
Información y Tecnología
La información y la tecnología se usan juntas generalmente en la era de la
información. No hay nada de malo en ello; sin embargo, debemos entender que
ambos son distintos.
La información se refiere al conocimiento que hemos recopilado, la sabiduría
de la experiencia, los datos y todo lo demás que los acompaña. La tecnología, por
otro lado, es la electrónica y la codificación que simplifica nuestras vidas. Ya sean
101
los servidores, el centro de datos, los teléfonos móviles o la infraestructura de la
nube, todos caen en el espacio de la tecnología. Los avances en tecnología
incluyen automatización, blockchain, inteligencia artificial y aprendizaje
automático. La información y la tecnología se usan en conjunto, porque la
información se usa sobre los componentes tecnológicos. Por ejemplo, se utiliza un
inventario de activos además de una base de datos de gestión de activos, que es
una pieza de software que ayuda a gestionar los datos, incluida la recuperación con
facilidad.
Centrándonos en el tema de la dimensión de la información y la tecnología en
la gestión de servicios, se puede aplicar a dos áreas:
1. TI para servicios reales (que disfrutan los clientes/usuarios)
2. TI para la gestión de servicios (habilitador para proveedores de

servicios y consumidores de servicios)
TI para servicios reales

La información y la tecnología se aprovechan para brindar servicios de TI a los
clientes. La dimensión profundiza en la información utilizada durante el proceso
de creación, uso y gestión de los servicios de TI. Esto se puede hacer tanto del
lado del proveedor de servicios como del consumidor de servicios.
En el servicio de transmisión de video de Netflix, la TI de este servicio incluye

los servidores, la red de entrega de contenido y la tecnología de transmisión de
video. Estos son los diversos componentes de TI que tienen una relación directa
con el servicio de TI.
TI para la gestión de servicios

La información y la tecnología para la gestión de servicios son aquellos conjuntos
de componentes informativos y tecnológicos que respaldan al proveedor de
servicios y al consumidor de servicios para habilitar las TI para sus usuarios.
102
Continuando con el ejemplo de Netflix, la empresa administra un inventario de
títulos de video, un inventario del software y hardware que se utiliza para alojar el
servicio de TI, junto con las relaciones. Además, el proveedor de servicios
aprovechará la gestión del flujo de trabajo para obtener aprobaciones (como en las
solicitudes de servicio y las solicitudes de cambio) o podría ser un sistema de
emisión de tickets para registrar incidentes. Todos estos sistemas y la información
de gestión de servicios que reside en ellos no son utilizados por el usuario. Esta
información se utiliza para mejorar el servicio, para garantizar que el servicio
funcione sin obstáculos y que el usuario obtenga la mejor experiencia. Imagine
cómo se siente un usuario si la película se almacena en el búfer cada dos minutos.
Aunque la CDN proporciona los datos al usuario, podría haber un problema
planteado en la gestión del servicio para identificar la causa raíz del
almacenamiento en búfer. La solución que surge cuando se implementa es un valor
agregado para el usuario, porque tiene como objetivo solucionar el problema del
almacenamiento en búfer. Este es un ejemplo simple de cómo la TI para la gestión
de servicios ayuda/apoya/habilita un servicio de TI.
Nota
TI para servicios Aspectos de la información y la
tecnología que influyen directamente en un servicio de TI.
Nota
TI para la gestión de servicios Aspectos de la
información y la tecnología que influyen en la gestión de los
servicios de TI por parte del proveedor de servicios y la
organización consumidora de servicios. Esto no afecta un
servicio directamente. ejemplo: si un sistema de emisión de
boletos no funciona, la capacidad de registrar un incidente se
103
ve afectada, lo que retrasa la restauración de un servicio de
TI, lo que afecta indirectamente al servicio de TI.
Consideraciones para la Información

Información es poder. En manos de una entidad equivocada, tiene las
consecuencias de aniquilar por completo las empresas y la competencia. Por lo
tanto, es de suma importancia que la información se maneje con cuidado y con un
marco que la proteja de usos indebidos.
Al diseñar la gestión de la información, el arquitecto de la información debe
considerar varios aspectos, tales como:
1. Los proveedores de servicios deben identificar los diferentes tipos de

información que se necesitan para prestar los servicios y para la gestión de los
mismos. El espectro de información debe elegirse cuidadosamente para
garantizar que la información recopilada sea suficiente y no termine siendo
gastos generales. Netflix durante el registro toma nota de nuestro nombre,
geografía, dirección de correo electrónico y detalles de la tarjeta de crédito.
Estos detalles ayudarán en la entrega de servicios de transmisión de video para
sus usuarios.
2. ¿Cómo se almacena la información? ¿Existe suficiente encriptación para
protegerlo del uso indebido? Hemos escuchado de vez en cuando sobre varias
infracciones que han hecho pública información confidencial.
Las consecuencias pueden potencialmente llevar a las empresas a la

bancarrota y poner en riesgo a las personas. Por lo tanto, asegurar la
información es de vital importancia.
3. ¿Cómo gestiona un proveedor de servicios la información? La información
cambia de vez en cuando. ¿Cómo se actualiza en sus sistemas? Por ejemplo,
cuando vence una tarjeta de crédito registrada, ¿cómo pueden los usuarios
actualizarla? ¿Está en su portal o llama un agente para obtener los detalles?
Tenemos ambas instancias y ambas funcionan. La pregunta es si tenemos
104
suficiente seguridad, especialmente cuando un humano está involucrado en el
proceso.
4. Cuando un usuario decide dejar de usar un servicio, ¿qué sucede con la
información del usuario? ¿Está archivado o borrado?
5. El cumplimiento normativo es otra dimensión de la gestión de la información.
Existen regulaciones como el Reglamento General de Protección de Datos
(GDPR) para organizaciones con sede fuera de la UE que otorgan a los
usuarios el derecho a elegir cómo se aprovechan sus datos personales. Del
mismo modo, existen múltiples regulaciones en todas las geografías y en
varias industrias que especifican regulaciones de información. Su
cumplimiento debe entrar en el diseño de la gestión de la información.
6. Lo que es más importante, hoy en día es por elección que la información
reside en un sistema en particular. Otros sistemas a través de interfaces e
integraciones buscan la información necesaria. Por ejemplo, supongamos que
Netflix almacena la información de pago de los clientes en un
sistema SAP. Durante las renovaciones, el sistema de

facturación extraerá la información de pago del cliente, la
cargará y luego eliminará la información. Tales
intercambios de datos son bastante comunes. Por lo tanto,
se deben establecer los siguientes criterios para la
información en juego:
a. ¿La información buscada es relevante?
b. ¿Está disponible la información buscada?

c. ¿La información es confiable?
d. ¿La información es accesible (permisos)?

e. ¿La información registrada es precisa?
f. ¿Se puede recuperar la información de manera oportuna?
105
Consideraciones para la tecnología

Centrándonos en la tecnología, hay más preguntas sobre las que reflexionar.
1. Es bastante raro que las empresas empiecen desde cero. Entonces, ¿la
tecnología elegida encaja bien con la arquitectura existente? Esta es una
pregunta que incita a la inversión de capital a fluir en el caso de cambios
arquitectónicos importantes. Para las empresas que comienzan de nuevo,
pueden optar por cualquier cosa bajo el sol y terminarían bien, pero este es
generalmente un caso poco probable. Porque incluso ellos se basarían en algo
que ya existe en lugar de empezar de la nada. Un portal de noticias podría
optar por Wordpress como su sistema de gestión de contenido en lugar de
algo como Drupal, que está perdiendo mucho en comparación con 20 años
atrás, cuando dominaba el mercado.
2. ¿Cuál es el futuro de la tecnología elegida? Tendría cuidado de elegir algo
que acaba de llegar al mercado. ¿Qué pasa si no puede sostenerse y si tiene
fallas de seguridad importantes? Por lo tanto, es importante elegir una
tecnología que tenga futuro, al menos tanto como los expertos puedan prever.
Por ejemplo, si hubiera elegido Google Plus como opción de red social para
su organización, se habría arrepentido de la decisión porque el producto ya no
es compatible.
3. La estrategia es crucial con la tecnología. ¿Coincide la estrategia de su

organización con la decisión tecnológica? Conozco organizaciones que
buscan mantener los gastos de TI al mínimo y optan por el código abierto.
Entonces, para tales organizaciones, optar por Office 365 puede no ser la
mejor opción. Podrían optar por Google for Business combinado con
Chromebooks y toda la flota de productos de Google para reducir costos.
4. Cada organización proveedora de servicios tiene sus propios puntos fuertes.
Algunos tienen una gran cantidad de arquitectos que son decanos de Amazon
Web Services. Para esta organización, optar por la suite de Microsoft Azure
sería contraproducente. Deben poner la boca donde está el dinero .
106
5. ¿La tecnología elegida es lo suficientemente segura para almacenar la
información relacionada con el servicio? ¿Existen reglamentaciones que la
tecnología elegida cumple?
6. La automatización es fundamental hoy en día. Todas las empresas están
buscando formas de reducir los costos de TI, y la automatización ha sido un
vehículo confiable para descargar actividades mundanas. La tecnología
elegida debe acelerar empleando la automatización. La mayoría de las
tecnologías modernas lo hacen. Es poco probable que una organización opte
por mainframes hoy en día, que ofrecen la mayor resistencia a la
automatización.
7. Un aspecto de la tecnología que más se desea es la capacidad de expansión.

Si opto por una tecnología en particular para implementar una funcionalidad,
no quiero limitarme a optar por una tecnología diferente para una
característica que podría presentar dentro de 2 años. La tecnología
identificada debe ofrecer suficientes opciones de flexibilidad en la adaptación
y una hoja de ruta para el futuro impresa.
8. Con todo lo bueno que las tecnologías traen a la mesa, también está su
equipaje. ¿Cuáles son los riesgos y limitaciones que una tecnología introduce
en un servicio? Este es un aspecto crítico a considerar antes de tomar la
decisión. La decisión también expone el apetito por el riesgo de las
organizaciones que están dispuestas a arriesgarse por ciertas características
atractivas que podría ofrecer una tecnología.
Consejo de examen cualquiera de las consideraciones

expuestas en información y tecnología podría aparecer en el
examen. Por lo tanto, es imperativo que comprenda el
significado detrás de la consideración en lugar de las
preguntas reales que he planteado. Es posible que las
preguntas que he planteado no sean exhaustivas. Debe estar
en un lugar para juzgar si un aspecto particular de la
107
información o la tecnología presenta un beneficio directo o una
contradicción para la decisión inminente que se debe tomar.
Socios y Proveedores
La tercera dimensión de la gestión de servicios son los socios y proveedores.
Mientras que las dos dimensiones anteriores miraban hacia adentro, esta mira las
dependencias externas. Vivimos en un mundo donde la cooperación y la
colaboración se han convertido en la norma entre las empresas en lugar de una
ventaja añadida. Ninguna empresa puede aspirar a proporcionar servicios o
productos a sus clientes sin contar con la ayuda de otras empresas. Las otras
empresas podrían ser proveedores de materias primas, proveedores de redes o
contratistas de recursos humanos. Los días de negociaciones para ganar y
conseguir el mejor trato posible han quedado atrás. Como cliente, no solo
queremos obtener el mejor trato posible, sino también asegurarnos de que la
relación con el proveedor sea consistente y continua. Para esto, es imperativo que
el acuerdo sea una situación de ganar-ganar. Debido a este delicado equilibrio,
ITIL ha identificado socios y proveedores como uno de los pilares/dimensiones
sobre los que se construye su gestión de servicios.
Diferenciando Socios y Proveedores

Cuando comencé mi estudio sobre gestión de servicios a través de ITIL V2,
entendimos quién es un proveedor. Los roles y responsabilidades estaban claros y
sabíamos cómo manejarlos. Luego, las organizaciones comenzaron a vincularse
con otras y comenzaron a llamarlo asociación. A través del prisma del proceso de
gestión de proveedores de ITIL V2, la asociación entre empresas no era más que
un cliente glorificado que se inscribía en los servicios/productos de un proveedor.
Entonces, ¿por qué llamarlos socios?
Como mencioné anteriormente, la relación entre las empresas es fundamental,
y en este siglo de crecimiento acelerado, las empresas deben establecer relaciones
sólidas si quieren sobrevivir y prosperar. La asociación, en esencia, es
108
esencialmente una relación cliente-proveedor. Sin embargo, a un socio se le
otorgan más privilegios que a un proveedor, se le confía y, a menudo, se le da un
asiento en la mesa durante algún nivel de toma de decisiones. El valor es
realmente co-creado entre socios, y tales empresas a menudo tienden a compartir
objetivos, cultura y entorno empresarial.
La estrategia de las organizaciones es construir alianzas con otras empresas
que son responsables de la entrega de servicios y productos críticos. Las empresas
firman acuerdos genéricos en lugar de específicos, elaboran objetivos juntos y, a
menudo, intentan ser lo más flexibles posible con los demás.
La mayoría de las organizaciones de hoy tienen una asociación con Microsoft
porque varias computadoras portátiles y servidores que ejecutan funcionan con
Windows y otro software de Microsoft. Estas empresas a menudo pueden instalar
tantas licencias de software como quieran y retrospectivamente informan a
Microsoft de los números; y debido a la asociación, tienen derecho a un precio
muy reducido. Para Microsoft, la asociación genera más negocios y puede influir
en la organización para mover los servicios y productos que no son de Microsoft
hacia su ámbito. Para la organización, el soporte prioritario, la habilitación rápida
de licencias y un costo razonable para los servicios y productos es muy aceptable.
Esta es una situación en la que todos ganan.
¿Qué pasa con un proveedor? ¿Cómo los diferenciamos? La misma
organización depende de un mercado de papelería para todos sus suministros de
papelería. Proporcionan el pedido en función de sus necesidades y se suministran
los productos. La transacción finaliza con el ciclo de pago y entrega. No hay
necesidad de una sociedad, ya que hay otros cien comerciantes dispuestos a
ofrecer los mismos juegos de papelería y a un precio similar. Entonces, este
proveedor de bienes es solo un proveedor y nada más.
Esto se aplica incluso en nuestra vida diaria. Por ejemplo, compro mucho en
Amazon. Para mí, elijo lo que necesito y pago por ello. Cuando el artículo se
entrega en mi puerta, la transacción finaliza. Amazon no es crítico, ya que puedo
obtener un servicio similar de al menos media docena de proveedores. Sin
embargo, su membresía Prime cambia el sentido de ser un proveedor a una
asociación, no en el verdadero sentido sino en el espíritu. Al ser miembro Prime,
109
tengo acceso a sus ofertas 30 minutos antes que los demás. Aunque esto es trivial,
me da una sensación de privilegio e importancia de que a través de esta
membresía Prime, posiblemente pueda contarlos como socios.
Nota
Socios : construidos sobre la base de la confianza y la
necesidad mutua de servicios/productos críticos. Compromiso
a largo plazo. basado en la hoja de ruta.
Nota
Proveedores : clara separación de roles y basada en
transacciones. Impulsado por el contrato de entrega de
bienes y servicios.
Estrategia de la organización para optar

por socios
y Proveedores
Una organización puede optar por asociarse o buscar un proveedor por una
variedad de razones. Esta sección investiga algunas razones comunes para tomar
esta decisión:
1. Recuerde el clásico proceso de toma de decisiones que

involucra comprar o construir en la industria del software. Del
mismo modo, la empresa debe tomar una decisión estratégica si
va a construir todo o subcontratarlo a otra empresa porque no
es su área principal. ¿Por qué un banco querría mantener su
propio departamento de TI si puede subcontratar a especialistas
en TI que puedan administrarlo de manera eficiente para ellos?
110
2. Los costos definitivamente juegan un papel en la decisión. Si
puedo dirigir mi propio departamento de TI y gastar un 50 %
menos en comparación con la subcontratación, entonces me
inclinaría a contratar a los mejores talentos y dirigir mi propia
tienda de TI.
3. ¿Qué pasa si la gente de TI prefiere unirse a las empresas de TI
solo por la profundidad y variedad del trabajo que puede
ofrecer? Incluso si un banco quiere contratar a buenas personas,
es posible que no las consigan fácilmente. Este podría ser uno
de los principales factores para la subcontratación.
4. Podría haber tendencias sustantivas en la industria para hacerlo

de una forma u otra. ¡Sigamos a la manada y estemos seguros!
5. Los requisitos legales y reglamentarios posiblemente podrían
cambiar el rumbo hacia la subcontratación. Todos estos son
riesgos y, esencialmente, al subcontratar, una organización está
transfiriendo el riesgo al socio/proveedor.
Introducción a la integración y
gestión de servicios
En el área de gestión de servicios, la popularidad de Gestión e Integración de
Servicios (SIAM) es superada por ITIL. Este es un marco que ha estado de moda
durante un par de décadas y recientemente está haciendo olas en la industria de TI.
Mencioné anteriormente que las organizaciones tienden a tener varios socios y
proveedores que están vinculados con ellos para diversos bienes y servicios. La
gestión de proveedores y socios requiere delicadeza y habilidades de gestión que
son una experiencia propia. Las organizaciones celebran un acuerdo de asociación
con socios que pueden actuar como integradores de servicios. Una integración de
servicios actúa como una interfaz entre una organización cliente y socios y
proveedores. Todas las actividades estratégicas, tácticas y de transacciones pasan
por la capa del integrador de servicios. Esta capa puede ser un tercero (socio) o
111
puede ser una división interna dentro de la organización del cliente. No importa
dónde se sienten, su función es garantizar que todos los socios y proveedores sean
administrados de manera efectiva.
SIAM es un marco construido sobre la base de la integración de servicios y los
integradores de servicios. Entra en los diversos procesos, prácticas y mejores
prácticas en el trato con socios y proveedores desde la perspectiva de un integrador
de servicios. Lo animo a tomar este curso después de completar la certificación
ITIL 4 Foundation.
Procesos y flujos de valor

La cuarta dimensión incluye los flujos de valor y los procesos. No es ni mucho
menos el menos importante por su ubicación. Otras dimensiones tienen que ser
entendidas si esta dimensión necesita ser descifrada.
En esta dimensión, las otras tres dimensiones se juntan y cosen en un
conjunto coordinado de pasos para cocrear valor. Los elementos de gestión de
servicios, como procesos, procedimientos, actividades de trabajo, flujos de
trabajo y controles, se definen a través de esta dimensión.
La diferencia entre un flujo de valor y un proceso es significativa. Existe un
proceso para transformar las entradas en salidas definidas y predecibles. No entra
inherentemente en pasos de proceso no deseados e ineficiencias. Siempre que se
obtenga el resultado deseado, se cumple el objetivo del proceso. Un flujo de
valor va un nivel más profundo. Es como un proceso pero sólo en apariencia.
Debajo, mantiene un ojo atento a las diversas actividades dentro de un proceso
que generan desechos, con el objetivo de eliminar los desechos y mejorar la
productividad del flujo de valor, que a su vez crea más valor y a un ritmo más
rápido.
112
Descifrando flujos de valor

El término modelo operativo se refiere al conjunto de actividades que emprende
una organización. En la gestión de servicios, el modelo operativo está orientado a
la creación de valor y las actividades definidas están orientadas a la gestión eficaz
y eficiente de los productos y servicios. Esto se llama ITIL
113
cadena de valor del servicio. Hablando más específicamente, el conjunto de

patrones dentro de la cadena de valor del servicio que tiene como objetivo crear
valor se denomina flujo de valor.
Definición ITIL de flujos de valor

Una serie de pasos que emprende una organización para crear y
entregar productos y servicios a los consumidores.
Considere un conjunto de actividades que posiblemente podría realizar en una

organización. Estas actividades se realizarán en un cierto patrón, y hay varios
patrones que podrían dibujarse. Estos patrones son cadenas de valor de servicios.
Los patrones clave que se pueden identificar para generar valor se denominan
flujos de valor.
Por ejemplo, si vas a visitar a un peluquero un sábado por la mañana, la prisa
suele ser alta, por lo que es posible que tengas que esperar un rato hasta que llegue
tu turno. Después de que la cola frente a ti disminuye, el barbero pregunta por tu
preferencia y, en base a eso, te corta el cabello. Después del corte, se quita la capa
y el cabello y te da un cepillo ligero antes de que te dirijas al mostrador para pagar
el servicio. Todos los pasos que tomó, lo hizo para la creación de valor. Con el
peluquero que es el proveedor de servicios, pudo crear valor al obtener un corte de
cabello inteligente. Estas actividades que llevaron a la generación de valor son un
flujo de valor. Hay varios desperdicios que podemos identificar en este flujo de
valor, como el tiempo de espera y el aspirado que debe hacer el peluquero después
de que te vayas. El objetivo es hacer más actividades que aporten valor y menos
actividades que no. Entonces, para generar más valor, reducir el tiempo de espera
o eliminarlo es una forma definitiva de hacerlo, y tal vez una aspiradora
automática pueda eliminar las actividades de limpieza manual.
En esencia, generar valor es un proceso de dos pasos. Primero, identificamos
las oportunidades para optimizar el flujo de valor. Luego automatizamos siempre
que sea posible, generalmente actividades que no involucran el conocimiento
humano. En la Figura 4-2 se proporciona una ilustración . Las actividades en rojo
114
son las actividades generadoras de residuos que deben reducirse o, si es posible,
eliminarse.
Figura 4-2. Ilustración de un flujo de valor de servicio
Una organización consta de varios de estos flujos de valor. El objetivo de los

flujos de valor es identificarlos, especialmente las actividades que generan
residuos, y minimizarlos o eliminarlos. Al reducir el desperdicio de manera
eficiente, hemos realizado una mejora continua efectiva para el producto/servicio
que está en juego. La segunda forma de generar más valor o realizar una mejora
continua es hacer que las actividades generadoras de valor sean más eficientes y
efectivas. Esto se puede hacer mediante la automatización que disminuye el
tiempo de respuesta y la tasa de defectos debido a errores humanos.
Simplificando Procesos
Un proceso es similar a un flujo de valor, pero el objetivo es más bien obtener un
resultado deseado basado en una entrada predecible.
Definición ITIL de un proceso

Un conjunto de actividades interrelacionadas o que interactúan que
transforman entradas en salidas. Un proceso toma una o más
entradas definidas y las convierte en salidas definidas. Los procesos
definen la secuencia de acciones y sus dependencias.
Los procesos están reforzados con procedimientos, plantillas y otros artefactos

similares.
Podría visualizar un proceso como un conjunto de actividades que necesita
realizar, una tras otra, para lograr algo. Cada actividad que realiza sienta el
precedente para la siguiente, y luego la siguiente. El objetivo de un proceso es
lograr un resultado que se encuentre dentro de las líneas esperadas y deseadas.
115
Aquí hay un ejemplo para hacer el concepto simple y digerible. Un proceso es
muy similar a una receta para cocinar un plato. En una receta, tiene varios pasos
que debe seguir, según las instrucciones, para obtener el plato que desea.
Veamos la receta de una tortilla de huevo. Es algo parecido a esto:
• Paso 1: rompa un par de huevos en un tazón.
• Paso 2: Batir hasta que quede esponjoso.
• Paso 3: Agregue sal y pimienta a la mezcla.

• Paso 4: Caliente una sartén antiadherente y derrita un poco de
mantequilla hasta que se forme espuma.
• Paso 5: Vierta la mezcla de huevo en la sartén e incline la sartén hasta

que cubra la base.
• Paso 6: cocine por un minuto o dos, y voltee la tortilla y cocínela por un
minuto más.
• Paso 7: Sirva la tortilla caliente con pan tostado.

Tienes que seguir los pasos al pie de la letra para conseguir una buena tortilla
de huevo. No puede intercambiar dos pasos para obtener el mismo resultado. En
lenguaje informático, este es el proceso para hacer una tortilla de huevo.
El aspecto principal de un proceso es la interconectividad entre los pasos
individuales, y todos los pasos trabajan colectivamente hacia una meta común, un
objetivo común que se desea.
Cuando usamos procesos en ITIL de manera efectiva para productos y
servicios, podemos encontrar respuestas a una serie de preguntas. Estos incluyen
identificar el modelo de entrega de un servicio, identificar cómo funciona un
servicio, identificar los flujos de valor y definir los roles y responsabilidades de
varias partes.
116
CUATRO DIMENSIONES
MAJADERO
Nota los factores externos que influyen en los servicios

y productos están fuera del alcance del examen de
Fundamentos de ITIL. Todavía lo incitaré a leer esta sección,
ya que estos factores son prácticos e importantes en el
trabajo. Si tiene poco tiempo, omita esta sección por ahora y
regrese a ella en su
ocio.
Las cuatro dimensiones son esenciales para diseñar y operar productos y servicios.
Sin embargo, esto no sucede en el vacío. Hay seis factores externos que se
enumeran en la Figura 4-1 que influyen en los productos y servicios, ya sea
positiva o negativamente. Se debe tener cuidado para identificar las influencias
positivas y los riesgos de los potenciales negativos.
Los seis factores externos que se identifican en el estudio de las cuatro
dimensiones de la gestión de servicios van con el acrónimo PESTLE y son:
1. Político
2. Económico
3. Social
4. Tecnológico
5. Legal
6. Ambiental
117
Factores políticos
Los productos y servicios no son inmunes a las acciones políticas de la
organización o del estado. Un cambio en el liderazgo y los cambios en la
legislación afectarán la forma en que se diseña y ejecuta un servicio o un
producto. Tomemos, por ejemplo, la situación de Covid-19, donde la crisis ha
llevado a un bloqueo en varios países. Esta es una legislación que debe ser seguida
por todas las partes. Los servicios que se ofrecen pasan por cambios para
adaptarse a las condiciones cambiantes. Hago operaciones bancarias con HSBC y
cuando llego a su centro de llamadas, anuncian que sus agentes están trabajando
desde casa y posiblemente podría escuchar perros y niños de fondo. Luego
continúan diciendo que existe encriptación digital para que los agentes accedan a
información confidencial desde sus hogares.
Esto no es normal. El factor político externo ha obligado a las organizaciones
a realizar arreglos alternativos. Esta situación de un desastre que se aproxima no
habría sido una entidad sorpresiva, sino que las organizaciones de servicio están
bien preparadas para tales situaciones e incluso realizan pruebas con regularidad.
Factores económicos
La economía es el elemento vital de los servicios en funcionamiento, ya que, en
teoría, funcionan perpetuamente. Se presupuesta una cierta cantidad en función de
varios factores y las condiciones políticas y económicas determinan si la cantidad
presupuestada es suficiente o no.
Siguiendo con el mismo ejemplo, la economía ha caído a niveles sin
precedentes. Esto obligará a las organizaciones a efectuar recortes de costos en
varios segmentos de los servicios. Con un presupuesto menor, aún se espera que
los servicios funcionen, quizás con menor eficiencia. Permaneciendo con HSBC,
normalmente la llamada que realizo será contestada en menos de un minuto; la
última vez que los llamé, colgué después de esperar más de diez minutos. Estoy
seguro de que la fuerza del agente ha sido eliminada desde el inicio de Covid-19.
118
CUATRO DIMENSIONES
Factores sociales
Dicen que cada diez años cambia la generación. Donde eso importa en los
productos y servicios es en el área de necesidades, necesidades y deseos. A
medida que cambia el clima social, los servicios y productos deben cambiar con
los tiempos, sin excepciones. Las organizaciones que no cambian se marchitan
con el tiempo, ya que sus productos y servicios generalmente serían tratados
como obsoletos y la gente buscaría cosas nuevas y brillantes. Nokia es un
ejemplo clásico de perder el tren varias veces cuando se puso de moda el auge de
los teléfonos móviles con pantallas táctiles.
Factores tecnológicos
Los avances en tecnología impactan positivamente en los productos y servicios.
Por lo tanto, es imperativo que las organizaciones desarrollen un apetito por las
actualizaciones técnicas, lo que se traduce en presupuestar más fondos. En algunos
casos afectan negativamente si las organizaciones no viajan sincronizadas con la
tecnología.
Considere el ejemplo de Blockbuster, la empresa que defendió el negocio de
alquiler de películas y programas de televisión. Venga a transmitir, no mantuvieron
el ritmo y ahora están cerrados para siempre.
Factores Legales
Los productos y servicios se entregan dentro del ámbito de los límites legales. La
ley del país debe implementarse sin excepciones, y las reglas cambian de vez en
cuando. Esa es la belleza de la legalidad. Las organizaciones deben ser lo
suficientemente flexibles y adaptables para cambiar con él.
La introducción del RGPD en 2018 afectó a todos los canales web que
almacenaban datos de usuarios, que es una gran mayoría. Todos los canales
119
digitales tuvieron que hacer cambios en los sitios web para cumplir con las
exigencias de la regulación.
Factores ambientales
¿Quién hubiera imaginado que el medio ambiente puede ser un factor que influye
en los servicios y productos? Sí, juegan un papel. A medida que cambian los
entornos, también cambian las demandas de los usuarios.
Los usuarios son respetuosos con la naturaleza en estos días y prefieren
comprar servicios y productos que son orgánicos y sirven para el bien común. Esto
hará que las empresas reconsideren la forma en que se producen y mantienen sus
productos.
4-1. ¿Qué dimensión de gestión de servicios se centra en la eficiencia y la

reducción de residuos?
A. Organización y personas
B. Información y tecnología
C. Socios y proveedores
D. flujos de valor y procesos

4-2. ¿Qué dimensión de gestión de servicios se centra en cómo se
organiza el personal en una organización proveedora?
120
CUATRO DIMENSIONES
4-3. ¿Qué dimensión de gestión de servicios se centra en la cultura?
4-4. ¿Cuáles de estos no se consideran en la dimensión de información

y tecnología?
A. Información gestionada por los servicios
B. Información de apoyo y conocimientos necesarios para prestar y gestionar los

servicios.
C. Modelo genérico de entrega del servicio
D. Protección y gestión de activos de información y conocimiento

4-5. ¿Cuál de las opciones refleja con precisión la diferencia entre
un socio y un proveedor?
A. Separación clara de roles B. Los socios

mantienen bases de conocimiento.
C. Los proveedores son administrados por socios.
D. Los socios son administrados por los proveedores.
121
DÍA 3

El día 3 estudiamos el tema más importante en ITIL: el sistema de valor del

servicio y la cadena de valor del servicio. Los temas tratados en este día son los
principios rectores de ITIL y forman la base para el resto del marco.
CAPÍTULO 5
Creación de valor
con sistema de
valor de servicio
ITIL se ha destacado por la creación de valor a través de los servicios. En ITIL V3,
todos los aspectos de la gestión de servicios se vieron a través de la lente del valor.
No es diferente en ITIL 4. De hecho, el valor ocupa un lugar central con un
capítulo completo y múltiples conceptos que giran en torno a él. Lo que es
diferente es que el valor es obtener el nivel correcto de énfasis a través de un
sistema construido para entregarlo.
Este es un capítulo centrado en el sistema de valor del servicio (SVS) y la
cadena de valor del servicio (SVC), los motores que unen y ayudan a cocrear
valor. Además, exploraremos los principios rectores que se introdujeron por
primera vez en el curso de certificación ITIL V3 Practitioner. Estos conceptos
están vinculados con los conceptos de oportunidades, demandas y la
importancia de la gobernanza para garantizar una navegación sin problemas.
Consejo de examen Este es un capítulo importante desde

el punto de vista del examen. Puede esperar encontrar
nueve preguntas solo en este capítulo, que potencialmente
pueden ayudarlo a obtener un tercio de las calificaciones
necesarias para aprobar el examen.
6361-7_5
CAPÍTULO 5 CREACIÓN DE VALOR CON SISTEMA DE VALOR DE SERVICIO
Introducción al sistema de valor del

servicio
Escribí sobre el valor que se crea conjuntamente entre un proveedor de servicios y
un cliente. También mencioné cómo una sola organización ya no puede brindar
servicios. Necesita otras organizaciones, y el servicio se integra con varios
servicios y productos para ofrecer valor.
Centrémonos un nivel más profundo. Para crear valor, una organización,
digamos una organización proveedora de servicios, necesita tener varios
componentes y elementos para moverse en armonía para que esto suceda. Por
ejemplo, la organización necesitaría el poder de la tecnología junto con
personas capacitadas que puedan diseñarla y construirla. Para traer a bordo a
estas personas y otras según sea necesario, se necesita una función de
contratación y para cuidarlos bien, una función de recursos humanos. Además,
necesita que los departamentos de finanzas paguen los salarios, entre otras
funciones financieras. Solo estoy rozando la superficie y he identificado tantos
conjuntos de funciones que necesitan trabajar en armonía para ofrecer valor.
Otro ejemplo con el que todos podemos relacionarnos es el funcionamiento de
un automóvil. Un automóvil tiene un millón de piezas (o eso parece) y cada una de
ellas es necesaria para su buen funcionamiento. Se necesita combustible para hacer
funcionar el motor, y el motor convierte la energía del combustible a través de la
combustión en movimiento mecánico. Se requiere una batería para iniciar el motor
para iniciar el proceso combustible. Este movimiento mecánico se alimenta a las
ruedas a través del mecanismo de engranajes y ejes. Las ruedas en sí necesitan la
goma para una conducción suave y tracción. Si bien estas son las dinámicas
internas, necesita un mecanismo de control administrado por un conductor que
controle la dirección del movimiento con un volante y la potencia mediante la
combinación de un embrague, un acelerador y una caja de cambios. Sí, estos están
en el nivel más simple. Puedo explicar cómo funciona un automóvil y ni siquiera
estoy llegando a los complementos como luces, limpiaparabrisas, espejos, asientos
y aire acondicionado. Hay tantas otras características que poseen los autos
modernos que no tengo idea de dónde comenzar y terminar. Mi punto es que todas
estas partes de las que tomé nota tienen que funcionar de una manera particular
para que el automóvil se mueva en la dirección y velocidad deseadas.
CAPÍTULO 5 CREACIÓN DE VALOR CON SISTEMA
DE VALOR DE SERVICIO
Considerando el transporte como un servicio, entonces el mecanismo

sincrónico de un automóvil que describí es el SVS. Es un sistema de obras que
reúne varios componentes discretos en una sola entidad homogénea que entrega
valor.
Para simplificar, puedo dividir esto aún más en dos flujos que juntos definen el
SVS:
1. Componentes discretos que trabajan juntos al unísono
2. Esquema organizado de cosas que reúne los componentes discretos;
Piénselo como las políticas, los procesos y los procedimientos.
Consejo de examen sobre el tema de un sistema de valor

de servicio, puede esperar obtener al menos una pregunta
(equivalente a una marca) en su examen básico de iTil. La
pregunta se basará en su capacidad para recordar y
reconocer conceptos.
Definición de ITIL del sistema de valor del servicio

El ITIL SVS describe cómo todos los componentes y actividades
de la organización funcionan juntos como un sistema para
permitir la creación de valor.
La estructura de un SVS se muestra en la Figura 5-1 . Consta de los siguientes

componentes:
1. Oportunidad y Demanda como insumos
2. Valor como salida
3. Cadena de valor del servicio en el centro
4. Gobernanza y Prácticas a su alrededor
126
5. Los principios rectores y la mejora continua lo resumen todo
Son los diversos recursos y activos dentro de una organización los que unen
estos componentes discretos. Recuerde que una organización contendrá varios
silos. Al usar varias permutaciones y combinaciones de estos recursos
organizacionales, podemos generar valor; esto es posible a través de una estrecha
coordinación e integración.
También es cierto que no todas las organizaciones son iguales. Tiene
algunas organizaciones tradicionales que pueden ser rígidas con respecto a la
flexibilidad con la que pueden manipularse para lograr valor. Y luego están las
startups que cambian como un camaleón. La conclusión es que la cultura, la
flexibilidad y la adaptabilidad de la organización marcarán la pauta para la
creación de valor.
Los componentes de la SVS se analizan en detalle más adelante en este
capítulo, excepto los principios rectores en el Capítulo 6 ; mejora continua, que se
explica en el Capítulo 10 ; y prácticas en los Capítulos 7 al 14 . Ya hemos
discutido el valor en el Capítulo 3 .
Guiding
Principles
Governance
Service
Opportunity and
Value Value
Demand
Chain
Practices
Continual
Improvement
Figura 5-1. sistema de valor del servicio
127
Nota alternativamente, puede definir el sistema de

valor del servicio como un conjunto de cosas que
funcionan juntas como partes de un mecanismo o una
red de interconexión para crear valor a través de
productos y servicios.
Oportunidad y Demanda
Cualquier negocio que se emprende se hace sobre la base de las oportunidades
disponibles. Sin identificarlos, emprender un negocio es como pegarse un tiro en
el pie. Piense en el restaurante de su vecindario. ¿Crees que iniciaron el restaurante
sin investigar un poco sobre sus clientes potenciales, su competencia y otras
posibilidades? Las oportunidades dan lugar a negocios y esto también ocurre con
los productos y servicios.
Los nuevos productos y servicios se introducen y llevan al mercado porque
existe un conocimiento significativo de las oportunidades existentes. Con las
conexiones de telefonía celular a un costo asequible a principios de la década de
2000, los fabricantes de teléfonos celulares vieron una oportunidad y desarrollaron
nuevos teléfonos y lanzaron uno nuevo cada cierto tiempo. Se aferraron a la
oportunidad creada en el mercado (facilitado por el gobierno) para volverse
relevantes y dominarlo.
ITIL Definición de Oportunidad

La oportunidad representa opciones o posibilidades para agregar
valor a las partes interesadas o mejorar la organización.
128
La definición de ITIL de una oportunidad se ve desde la perspectiva de la
creación de valor a través de productos y servicios. Las oportunidades no se
limitan a crear y mantener un nuevo producto o servicio, sino que también pueden
ser para mejorar un servicio o cualquier otro aspecto de una organización que
pueda generar un aumento en el valor.
Si bien los proveedores de servicios ofrecen servicios, se encuentran en una
posición en la que pueden leer el pulso de un cliente y pueden detectar otras
oportunidades. Estas oportunidades podrían extender los servicios existentes a
áreas más nuevas u ofrecer servicios adyacentes, o habilitar complementos de
servicios que pueden ofrecer más valor a los clientes.
Un aspecto que va de la mano con la oportunidad o la complementa es la
demanda. Podría abrirse una oportunidad para que un proveedor de servicios
ofrezca productos y servicios. Sin embargo, sin demanda, está condenado al
fracaso. Entonces, cuando se identifica una oportunidad, se identifica la demanda
correspondiente, que se revela durante la investigación y el estudio de mercado
que se realizan.
Chevrolet en India, después de haber tenido éxito durante décadas, decidió
obtener sus automóviles de China a través de su empresa subsidiaria SAIL.
Detectaron la oportunidad de reducir los costos de producción y tal vez transferir
algunos de estos ahorros a los clientes. Sin embargo, la demanda de automóviles
chinos en la India no fue la que habían previsto. La demanda era baja y su decisión
era irreversible. Esto significó que el gigante del automóvil tuvo que salir del
mercado de automóviles en la India.
Definición de demanda de ITIL

La demanda representa la necesidad o el deseo de productos y
servicios de los clientes internos y externos.
Comprender la demanda de productos y servicios es esencial. Las empresas

deben asegurarse de descubrir la verdadera necesidad y, con el conocimiento de las
oportunidades disponibles, ofrecer productos y servicios que sean aptos para el
propósito y aptos para el uso (valor).
129
Nota los clientes internos pertenecen a la misma
organización que el proveedor de servicios. los clientes
externos están fuera de ella. La diferencia entre clientes
internos y externos se mide simplemente en términos
financieros. los clientes externos pagan dinero real y, por lo
tanto, su importancia es máxima. los clientes internos, por
otro lado, son una obligación, algo que la organización debe
atender y sin lo cual no puede vivir.
El equipo de TI interno cobra teóricamente a las unidades de
negocio internas. no se transfiere dinero real entre las
unidades de negocio y el equipo de TI, sino que solo se
anota en los libros mayores. es como sacar dinero de tu
bolsillo izquierdo y depositarlo en tu bolsillo derecho.
Gobernancia
La gobernanza es una parte integral de la SVS y está en el centro, lo que significa
que procesa las oportunidades y demandas que se presentan y tiene una voz
importante en el valor que se entrega. Entonces, entendamos de qué se trata la
gobernanza.
Nota aunque la gobernanza es parte del sistema de

valor del servicio, no está dentro del alcance del examen de
la Fundación iTil. Todavía lo animo a leer esta sección, ya
que es práctica y es importante en el trabajo. si tiene poco
tiempo, salte esta sección por ahora y regrese a ella cuando
lo desee.
130
La gobernanza se trata de proporcionar dirección a una organización, un
proyecto o un país. Los gobiernos proporcionan la dirección necesaria a través de
legislaciones para los países. A nivel de organización, tenemos
131
órganos de gobierno creados para proporcionar orientación en la definición y
aplicación de políticas. En los proyectos, los órganos de gobierno incluyen
representantes clave del cliente, el proveedor de servicios y los proveedores,
junto con patrocinadores y otros responsables del resultado. Los productos y
servicios también se crean de forma similar a los proyectos o en la parte
posterior de ellos, y tienen un órgano de gobierno para proporcionar dirección.
La gobernanza forma parte de la SVS a través de los procesos y
actividades para la gestión de los servicios. Este gobierno debe ajustarse al
gobierno a nivel de organización, que es el principal órgano de gobierno para
garantizar la evaluación, dirección y seguimiento de diversas actividades.
Cada producto o servicio tendrá un órgano de gobierno establecido para
garantizar que se cree valor y se entregue al cliente. Las direcciones
presentadas por la gobernanza del servicio/producto se basarán en los
principios y políticas de la organización. El órgano de gobierno tendrá una
visión de alto nivel de todas las actividades que crean valor y aquellas que son
generales; y lo que es más importante, el ámbito de la mejora continua
también se incluye en la gobernanza.
Cadena de valor del servicio

La cadena de valor del servicio (SVC) es el núcleo del sistema de valor del
servicio (SVS). La SVS (Figura 5-1 ) es fundamental para captar demandas y
convertirlas en valor para el cliente a través de productos y servicios. Para
generar este valor, el motor crítico que pone las cosas en movimiento es el
SVC.
Consejo de examen sobre el tema de la cadena de

valor del servicio, puede esperar obtener al menos una
pregunta (equivalente a una marca) en su examen básico
de iTil. La pregunta pondrá a prueba su comprensión de
132
la cadena de valor del servicio y su capacidad para
utilizar esa comprensión para responder a la pregunta.
CAPÍTULO 5 CREACIÓN DE VALOR CON
SISTEMA DE VALOR DE SERVICIO
Las actividades de SVC se ilustran en la Figura 5-2 .

Guidin
Principle
g
s
Governanc
e
Service
Opportunity and
Value Value
Demand
Chain
Practice
s
Continua
Improvement
l
Plan
Deliver &
Engage
Support
Products
&
Design & Services Improve
Transition
Obtain /
Build
Figura 5-2. cadena de valor del servicio
La SVC, que se rige por los principios rectores, la gobernanza, las

prácticas y la mejora continua, tiene asociadas seis actividades:
1. Plan
133
2. Comprometer
3. Mejorar
4. Obtener/Construir
5. Diseño y Transición
6. Entregar y apoyar
Los insumos para estas actividades provienen de las oportunidades y

demandas, y se invoca una combinación de estas actividades para generar
valor. Aunque he enumerado las actividades de forma numerada, no significa
que las actividades fluyan de manera secuencial. En ITIL V3, hemos visto el
flujo que comienza con la estrategia del servicio hasta el diseño del servicio,
la transición del servicio, las operaciones del servicio y la mejora continua
del servicio. En el SVC, cualquiera de las actividades se puede invocar en
cualquier momento y todas están interconectadas.
Cualquier requerimiento/demanda que implique un ejercicio de
planificación sería realizado por la actividad del plan. Siempre que intervienen
terceros, interviene la actividad de participación. Del mismo modo, cada
actividad tiene su propio alcance y será convocada cuando sea necesario. Estas
actividades trabajan juntas para generar los resultados requeridos y crear valor.
La generación de valor para un cliente se realiza a través de flujos de
valor, que son una serie de actividades que captan demandas y crean valor.
Cada flujo de valor tendrá una combinación de actividades y puede recurrir a
cualquiera de las 34 prácticas de ITIL para participar, desempeñar su función
y, a través del trabajo en equipo de actividades, prácticas y resultados, generar
valor. Esto podría lograrse recurriendo a una combinación de recursos
internos, recursos externos, prácticas, habilidades y competencias de ITIL.
Consideremos un ejemplo en el que un nuevo empleado se une a una
organización, que se ilustra en la Figura 5-3 .
134
Figura 5-3. Ilustración del flujo de valor del servicio
Hay dos flujos de valor que se han ilustrado para el escenario en el que un
nuevo empleado se une a una organización.
El primer flujo de valor es registrar al empleado (incorporación de
empleados) en la base de datos de la empresa, además de completar varios
formularios y firmar acuerdos de confidencialidad y otros documentos
necesarios. En este flujo de valor, la primera actividad sería proporcionar los
formularios para que los llene el empleado; el segundo es validar si todo está
bien; y finalmente, aceptar los cambios y generar número de empleado. El
resultado es la identificación del empleado que se genera al final del proceso.
Esto es valor tanto para el empleado como para la organización.
El segundo flujo de valor es el aprovisionamiento de una computadora
portátil para el empleado recién incorporado. Se presenta una solicitud de TI
para una nueva computadora portátil, la tienda de TI recoge la solicitud e
identifica una computadora portátil de la tienda, registran el activo en la base
de datos de activos y entregan la computadora portátil al equipo técnico para
instalar el sistema operativo necesario y El software. Una vez que se
completan todas las instalaciones, la computadora portátil se entrega al
usuario. El resultado es proporcionar una computadora portátil al empleado, lo
que no hace falta decir que se crea valor tanto para el empleado como para la
organización.
Cada uno de estos flujos de valor funciona a través de una combinación
de actividades: la entrada es la demanda (empleado que se une a una
empresa) y los resultados/valor que se crea al final del flujo de valor.
135
Para generalizar, la SVS convoca actividades de creación de valor en función
de la demanda y la SVC está en el centro de la SVS en la creación de valor
proceso.
Las siguientes secciones exploran cada una de las seis actividades de
SVC.
Consejo de examen mientras que comprender la

cadena de valor del servicio puede otorgarle 1 punto en
el examen, las seis actividades asociadas con la cadena
de valor del servicio le otorgarán otro punto. Puede
esperar una pregunta basada en las seis actividades
enumeradas (a continuación) en su examen básico de
iTil. La pregunta pondrá a prueba su comprensión y su
capacidad para usar la comprensión al responder la
pregunta.
Plan
La actividad del plan en el SVC representa la fase o conjunto de actividades
relacionadas con la identificación de estrategias para la organización
proveedora de servicios y la elaboración de planes en consecuencia. Si está
familiarizado con ITIL V3, esta actividad es como la fase de estrategia de
servicio. La principal diferencia es el modelo en cascada en V3 y un enfoque
paralelo en ITIL 4. Puede llamar a cualquiera de las actividades en cualquier
momento, y no es necesario que fluya como lo hizo antes, comenzando con la
fase de estrategia.
La actividad del plan existe para garantizar que todas las partes
involucradas en la co-creación de valor compartan una visión común (o de
mutuo acuerdo) y acuerden una hoja de ruta con una buena comprensión del
estado y los pasos futuros. Esto no solo es aplicable a los nuevos productos y
servicios, sino también a las iniciativas de mejora. La actividad de
136
planificación no se limita únicamente al flujo de valor, sino que también se
extiende a cuatro dimensiones, servicios y productos.
Las diversas entradas y salidas se ilustran en la Figura 5-4 . Esto de
ninguna manera es exhaustivo, pero se presenta para proporcionar una
comprensión del papel de la actividad.
Figura 5-4. Planificar entradas y salidas de actividades bajo la

cadena de valor del servicio
Entradas típicas para el plan

Si está en el negocio de diseñar estrategias, sabe que la información sobre la
demanda del cliente, las oportunidades que están disponibles, la competencia
y otra información relacionada con el mercado son las más necesarias. Estos
provendrán de la actividad Engage desde dentro del SVC. Recuerde que la
actividad Engage trata con todas las partes externas del proveedor de
servicios.
137
Las oportunidades de mejora identificadas junto con el estado de las
mejoras en curso y los niveles de rendimiento actuales ayudarán a hacer
planes para los productos y servicios existentes. Esto vendrá de la actividad
Mejorar dentro del SVC.
Los diversos cambios que se realizan en el producto/servicio (a través de
solicitudes de cambio) se retroalimentan a la actividad Planificar mediante las
actividades Obtener/Crear y Diseño y Transición desde dentro del SVC.
La capa de gobierno de la SVS traza los límites a través de las políticas
aplicables a ser consideradas e identifica los requisitos, riesgos y limitaciones
que están en juego.
Salidas típicas para el plan

El resultado principal de la actividad del plan será crear y proponer varios
planes estratégicos, tácticos y operativos para la organización.
Con base en las estrategias y planes identificados, la actividad proporciona
las decisiones arquitectónicas, las decisiones de cartera y las políticas que se
presentan desde la perspectiva estratégica a la actividad de Diseño y
Transición.
Además, la actividad Engage obtiene la información y los detalles sobre
los servicios y productos y los diversos contratos y acuerdos que deben
firmarse entre terceros y la organización proveedora de servicios.
El bucle de retroalimentación funciona de forma cíclica con la actividad
Mejorar. La actividad del plan, basada en su conocimiento y visión general,
también puede identificar iniciativas de mejora.
Comprometer
La actividad en el SVC que trata con terceros, tanto dentro como fuera de la
organización, es la actividad Engage. La actividad se encarga de entender las
necesidades no solo de los clientes sino también de todos los stakeholders
involucrados, y de mantener una sana relación con ellos.
138
En el antiguo ITIL, no teníamos una fase propiamente dicha, pero esta
actividad la realizaban los procesos de gestión de relaciones comerciales y
gestión del nivel de servicio.
Las diversas entradas y salidas se ilustran en la Figura 5-5 . Esto de
ninguna manera es exhaustivo, pero se presenta para proporcionar una
comprensión del papel de la actividad.
139
En un mundo que está altamente interconectado, esta actividad juega el papel
de punto de apoyo para garantizar que todas las partes interesadas se mantengan
armoniosas en relación con la visión y los objetivos comunes establecidos.
También debe asegurarse de que el pulso de las partes interesadas, ya sean clientes
o un organismo regulador, se controle de vez en cuando.
Figura 5-5. Involucrar las entradas y salidas de la actividad en la

Entradas típicas para Engage

Puede ver en la Figura 5-5 que la actividad Engage tiene varias entradas, lo que se
espera en una industria que depende de varios otros terceros para proporcionar
servicios de apoyo y habilitación.
El aporte más crítico proviene de los clientes en forma de comentarios sobre
los productos y servicios prestados. Los clientes pueden ser tanto internos como
externos. La habilidad no es solo aceptar la retroalimentación sino discernir
140
él. Cada retroalimentación debe responderse según sus méritos, y la actividad debe
garantizar que se tomen las medidas adecuadas. También encontrará en la figura
una salida que va a la actividad Mejorar. Esto se encuentra en la parte posterior de
los comentarios de las partes interesadas. Otros aportes que se pueden esperar de
los clientes podrían ser cambios en la demanda, cambios en los requisitos (o
detallar los requisitos de alto nivel) y vías para nuevas oportunidades. En una
etapa operativa, los clientes interactúan con el proveedor de servicios también a
través de incidentes y solicitudes de servicio. Cada uno de estos debe ser
priorizado y tratado con sumo cuidado. Idealmente, debería haber una práctica
para cada solicitud que llegue a la actividad Engage en el SVC.
Además de los clientes, los proveedores, el estado, el sistema legal y otras
partes interesadas también necesitan gestión. Pueden comunicarse para
comunicar cambios en la regulación, explorar asociaciones, llegar a un acuerdo o
simplemente compartir información y conocimientos sobre sus productos y
servicios.
La actividad de Entrega y soporte proporciona información periódica sobre el
rendimiento de los servicios. Este es el papel que solía desempeñar el proceso de
gestión del nivel de servicio en ITIL V3. Según el desempeño, se espera que la
actividad Engage presente el desempeño a los clientes y otras partes interesadas,
lo que se indica como un resultado en la Figura 5-5 .
Además, la actividad Mejorar proporciona información sobre las diversas
iniciativas de mejora que se están llevando a cabo en la organización junto con la
etapa de desarrollo y los plazos.
Las actividades de obtención/construcción y diseño y transición proporcionan
información y conocimientos sobre los servicios y productos. Esto es necesario
para mantener la actividad al tanto de los cambios de productos y servicios.
En la actividad Planificar, observamos el resultado de la actividad Participar,
que se muestra como una entrada.
141
Salidas típicas para Engage
Además de transmitir los comentarios de las partes interesadas a la actividad
Mejorar, podría haber oportunidades identificadas para mejorar los servicios y
productos que también se transmiten.
Las nuevas demandas y oportunidades provenientes de las partes interesadas
deben someterse al ciclo de elaboración de estrategias y planificación, y esto se
realiza como resultado de la actividad del Plan.
Las entradas recibidas de las etapas operativas se alimentan como salida a la
actividad de Entrega y soporte después de procesarla con los procedimientos
operativos estándar establecidos.
Todos los requisitos para construir un nuevo sistema o entradas de desarrollo
se alimentan a la actividad Obtener/Construir. Para acompañar esto, los cambios
en los contratos y acuerdos deben enviarse a esta actividad junto con la actividad
de Diseño y Transición, a la que se le confía la información sobre los requisitos de
productos y servicios. La actividad Diseño y Transición utiliza esta información
para generar los diseños arquitectónicos, los planes de implementación y las
implementaciones.
Con el espíritu de visibilidad y transparencia, la actividad Engage comparte
información sobre terceros, sus servicios y productos, y el conocimiento
recopilado a lo largo del flujo de valor.
Mejorar
La actividad Mejorar en el SVC existe para efectuar la mejora continua en los
flujos de valor, cuatro dimensiones, productos, servicios y todas las demás áreas
de gestión de servicios.
La actividad de mejora en ITIL V3 fue la fase de mejora continua del servicio,
que se extendió a lo largo de las otras cuatro fases.
5-6 se muestra una ilustración de las entradas y salidas de la actividad
Mejorar .
142
Figura 5-6. Mejorar las entradas y salidas de las actividades en la

Entradas típicas para mejorar

Una de las responsabilidades clave de la actividad Mejorar es garantizar que todas
las partes de la gestión del servicio estén en una trayectoria de mejora. Para
procesar y generar mejoras, la actividad Mejorar se alimenta con varias
oportunidades de mejora que se identifican en todo el sistema y también con la
información de rendimiento del producto/servicio. Esta información se utiliza
como línea base y como factor de medición para generar y comprobar las mejoras
que se producen en el sistema.
Para mejorar de manera efectiva el servicio o un producto, la actividad
Mejorar requiere aportes de los clientes y otras partes interesadas, que obtiene de
la actividad Participar, junto con el conocimiento sobre los servicios de terceros y
sus componentes asociados.
Las actividades de obtención/construcción y diseño y transición proporcionan
información y conocimientos sobre los servicios y productos. Esto es necesario
para mantener la actividad al tanto de los cambios de productos y servicios.
143
Salidas típicas para mejorar
Por lo general, se espera que la actividad Mejorar informe sobre las iniciativas de
mejora en los flujos y partes de las organizaciones.
La actividad del Plan está particularmente interesada en comprender el
desempeño de las diversas actividades en el SVC. Esto se mide y se entrega a la
actividad del Plan.
Con base en las mejoras en los sistemas, si se esperan cambios en los servicios
y productos, entonces los acuerdos y contratos relacionados también necesitan un
cambio. Esta información se alimenta a la actividad Engage.
La información de rendimiento que rodea a los servicios se proporciona a
Design and Transition, ya que tienen interés en esta información para modificar la
arquitectura y los diseños en consecuencia.
Diseño y Transición
Diseño y Transición es la próxima actividad en el SVC. Su objetivo principal es
asegurar que los diseños y las hojas de ruta de transición estén en línea con los
planes generales establecidos. Desde una perspectiva de actividad, existe para
garantizar que los productos y servicios se diseñen y hagan la transición para
cumplir con los requisitos del cliente en términos de calidad, costos y tiempo de
comercialización.
Esta actividad es similar a la fase de diseño de servicios en ITIL V3 que era
responsable del diseño general de un servicio. Hay algunas partes de la fase de
transición del servicio que se han integrado en la actividad de Diseño y
Transición.
5-7 se muestra una ilustración de las entradas y salidas de la actividad de
Diseño y Transición .
144
Figura 5-7. Entradas y salidas de la actividad de diseño y transición en la

Entradas típicas para el diseño y la transición

Los diseños generalmente se dibujan cuando se cumplen los requisitos. Estos
requisitos llegan a la actividad de Diseño y Transición a través de la actividad de
Participar. Aparte de esto, los contratos y acuerdos de proveedores y socios que
apoyan y permiten la creación de productos y servicios también se alimentan a
través de la actividad Engage.
Los diseños se dibujan dentro de los límites establecidos por la actividad del
Plan, léase como los límites estratégicos. Esto incluye la lista de productos y
carteras de servicios que se han acordado en la actividad del Plan, y las
arquitecturas y políticas empresariales correspondientes que son relevantes
durante el diseño y la planificación de la transición.
La actividad Mejorar alimenta información sobre las diversas iniciativas de
mejora que están activas, junto con los resultados de las iniciativas de desempeño
anteriores. El propósito de alimentar estos a Diseño y
145
La transición es cumplir con los objetivos de estas iniciativas a través de
diseños mejorados. La información de rendimiento después de aplicar las
mejoras se retroalimenta a la actividad Mejorar junto con otras oportunidades
de mejora identificadas.
El desempeño de los servicios de las operaciones (Entrega y Soporte) y
también de las iniciativas de mejora es un insumo para la actividad, ya que
estos datos se utilizan como línea de base para mejorar los diseños. Esto
también actúa como retroalimentación para la actividad de Diseño y
Transición, ya que está a la altura de los objetivos de nivel de servicio que se
han establecido.
La comprensión de los componentes de servicio existentes se obtiene a
través de Obtener/Crear. Esta información generalmente ayudará a reutilizar,
optimizar y ampliar según sea necesario. La actividad Obtener/Crear también
proporciona información sobre productos y servicios y los cambios que han
sufrido. Podría incluir especificaciones, errores conocidos y otros datos
operativos. Esta información es pertinente para permitir decisiones de diseño
efectivas.
Salidas típicas para el diseño y la transición

Diseño y Transición es una actividad que juega un papel crucial en todo el
SVC. Es una de las principales fuentes de información sobre productos y
servicios. Digamos, por ejemplo, que la actividad del Plan necesita esta
información porque puede influir potencialmente en las estrategias y hojas de
ruta existentes y futuras. Obtener/Crear necesitaría esta información para
desarrollar el producto o servicio. Debe transmitirse a Entrega y soporte, ya
que se trata de información pertinente para el soporte del producto o servicio.
La actividad Engage actúa como conducto para los contratos y acuerdos
que se identifican desde una perspectiva de diseño. Podría ser contratar a un
nuevo proveedor para un diseño identificado o asociarse con una empresa de
automatización para cumplir con ciertos objetivos.
Las diversas oportunidades de mejora junto con la información de
desempeño identificada por la actividad de Diseño y Transición se envían al
146
CAPÍTULO 5 CREACIÓN DE VALOR CON SISTEMA DE VALOR DE
SERVICIO
Mejorar la actividad para la gestión de las iniciativas de mejora hasta el cierre.

Las deficiencias identificadas en esta actividad se alimentan a la actividad
Mejorar en previsión de encontrar una solución permanente para ellas.
A medida que creamos nuevos productos y servicios, los requisitos y
especificaciones identificados desde una perspectiva de diseño y transición se
ingresan en la actividad Obtener/Construir. Estos datos serán utilizados por la
actividad Obtener/Crear para adquirir componentes como servidores, licencias
de software y recursos, entre otros.
Obtener/Construir
Obtener/Crear es la próxima actividad de la cadena de valor, que se ocupa de
movilizar el tipo correcto de recursos que se necesitan para entregar valor a
los clientes a través de productos y servicios, y para desarrollar productos y
servicios. Es una actividad que se encarga de garantizar que todos los
componentes de servicio necesarios que se ajusten a la factura estén
disponibles antes de que la prestación del servicio pueda comenzar a generar
valor. Por ejemplo, los componentes del servicio como la infraestructura, las
personas, las licencias de software y la automatización, entre otros, pueden
ser necesarios para desarrollar un producto o un servicio. Asegurarse de que
estos recursos estén en su lugar es uno de los trabajos de la actividad
Obtener/Construir. Una vez que estén en su lugar, el próximo objetivo es
construirlo antes de que la siguiente actividad de la cadena de valor, Entrega
y soporte, pueda tomar el relevo.
Asegurar y adquirir recursos es algo nuevo en el marco de ITIL. Hasta
ahora, el enfoque se ha centrado en identificar los diferentes tipos de activos y
recursos que se necesitaban para ejecutar un servicio con éxito. La forma en
que se obtendrían estos recursos se mantuvo principalmente fuera del alcance.
Se esperaba que los procesos de adquisiciones y recursos humanos
intervinieran y cumplieran. Con ITIL 4, estas actividades se han formalizado.
147
La actividad en torno al desarrollo de servicios se llevó a cabo por la fase de
transición del servicio.
Las diversas entradas y salidas para la actividad Obtener/Crear de otras
actividades de SVC se ilustran en la Figura 5-8 .
Figura 5-8. Obtener/construir entradas y salidas de actividades bajo

la cadena de valor del servicio
Entradas típicas para obtener/construir

En otras actividades de la cadena de valor, hemos visto que el resultado de
Plan (arquitecturas y políticas) es consumido por otras actividades de la
cadena de valor. Obtener/Crear también lo consume, ya que la información se
usa para obtener y construir según las especificaciones.
Los requisitos y especificaciones provienen de la actividad de Diseño y
Transición. Estos son esencialmente los diseños que han sido desarrollados
por la actividad. Esta información es utilizada por la actividad
Obtener/Construir para adquirir y movilizar recursos. Una vez que se han
movilizado los recursos, se desarrollan productos y servicios basados en los
diseños.
148
El conocimiento y la información de los servicios nuevos o modificados es
un aporte que proviene de la actividad de Diseño y Transición. Cualquier
nuevo servicio o cambio al existente requiere nuevos recursos para
desarrollarlos y entregarlos.
SERVICIO
La actividad Participar alimenta contratos y acuerdos a la actividad

Obtener/Construir, que proporciona los parámetros para que la actividad lleve
a cabo su negocio en función de los terceros disponibles. Los bienes y
servicios son entregados tanto por proveedores internos como externos ya
través de asociaciones. El contrato en vigor será vinculante para los bienes y
servicios a suministrar. La actividad Participar es responsable de mantener la
relación a través de la cual fluyen la información y los recursos necesarios, y
la actividad Obtener/Construir es responsable de garantizar la recepción de los
bienes y servicios en función de las especificaciones establecidas. La actividad
Engage también proporciona solicitudes de cambio y solicitudes de iniciación
de proyectos como entrada para Obtener/Crear. Las solicitudes de cambio o
las solicitudes de inicio de proyecto normalmente se presentan a través de
solicitudes de clientes, y el soporte de la actividad Obtener/Crear es esencial
para entregar el cambio o un proyecto.
En el SVC, la actividad Obtener/Crear también puede esperar recibir
solicitudes de cambio de la actividad Entregar y Soporte. En función de las
solicitudes de cambio, es necesario realizar cambios que requieren
recursos/personas adicionales, y es posible que se necesite un equipo de
proyecto para realizar el desarrollo real antes de que el producto final se
retroalimente a la actividad Entrega y soporte. Ejemplo: si se identifica una
transición de un sistema operativo, digamos que un equipo de proyecto está
involucrado para entregarlo. El equipo del proyecto opera en la actividad
Obtener/Construir. Para llevar a cabo esta actividad, que es el resultado de
una solicitud de cambio, se deben contratar personas con las habilidades
adecuadas, se debe aprovisionar la infraestructura para el nuevo sistema
operativo y también se deben adquirir las licencias del sistema operativo. Una
149
vez que los recursos están en su lugar, las actualizaciones del sistema
operativo se llevan a cabo y se prueban. Cuando está satisfecho, el producto
terminado se entrega a Entrega y Soporte para mantenimiento y trabajo
operativo.
La actividad de mejora está interesada en mejorar los productos y
servicios. Desde su perspectiva, las iniciativas de mejora y los estados se
proporcionan a Obtener/Construir para materializar las iniciativas de mejora
identificadas.
Salidas típicas para obtener/construir
De la actividad Obtener/Crear, deberíamos esperar ver resultados que
normalmente son servicios, productos, servicios modificados, productos
modificados y varios componentes individuales que conforman estos
productos y servicios.
Los componentes del servicio, que incluyen todo el conocimiento sobre el
servicio, se alimentan a la actividad de diseño y transición para permitir una
transición sin problemas a la actividad de entrega y soporte. Siguiendo con el
mismo ejemplo que antes, una vez que se realizan las actualizaciones del
sistema operativo, el producto terminado se entrega a Diseño y Transición
para planificarlo e implementarlo en producción. Después de la
implementación, las responsabilidades de administrar los servicios y los
componentes del servicio recaen en Entrega y soporte. En un ejemplo
relacionado, si la actividad Obtener/Crear fue para adquirir y configurar un
conmutador, y si se puede reemplazar sin la ayuda de un plan de transición
completo, se entrega directamente a la actividad Entrega y soporte.
Siguiendo con los componentes del servicio, el conocimiento y la
información sobre estos servicios son consumidos por todas las demás
actividades de SVC y son un resultado principal de la actividad Obtener/Crear.
Si algo se modifica o se construye de nuevo, cada actividad debe saber cómo
llevar a cabo sus respectivas responsabilidades, como Comprometerse para
involucrar a terceros cuando los contratos deben cambiarse, a la actividad
Mejorar para establecer una nueva línea de base.
150
Entregar y apoyar
La actividad de Entrega y Soporte se refiere a las operaciones y el
mantenimiento de los servicios. El propósito es mantener el statu quo del
servicio y garantizar que los servicios se entreguen de acuerdo con las
especificaciones y los diseños implementados. Es importante destacar que
todas las partes interesadas deben poder obtener valor y cumplir con sus
expectativas.
SERVICIO
Exploremos más a fondo dos términos que se utilizan aquí: entregar y

apoyar. Entrega se refiere al servicio que se entrega, la capacidad que se
extiende a los usuarios y clientes. El soporte entra en juego cuando el servicio
no funciona como se esperaba, o cuando se solicitan cambios (solicitudes de
servicio) que mejoran la experiencia del servicio.
Deliver and Support contrata a la mayoría de las personas en la industria
de TI. Por cada persona en desarrollo, puede esperar de ocho a diez personas
contratadas en el área de operaciones. Esto se debe a la naturaleza de
perpetuidad de las operaciones. Si bien los proyectos tienen un período de
tiempo limitado, las operaciones se ejecutan siempre que los productos y
servicios sean compatibles. Sin embargo, en DevOps, las líneas se vuelven
borrosas y el abismo entre los dos se reduce un poco, porque tiende a tener
un ciclo de vida de desarrollo continuo y comparte recursos entre las
actividades operativas y de desarrollo.
5-9 se ilustran las diversas entradas y salidas de la actividad Entrega y
soporte de otras actividades de SVC .
151
Figura 5-9. Entregar y respaldar las entradas y salidas de la

actividad en la cadena de valor del servicio
Entradas típicas para entrega y soporte

Deliver and Support es una actividad que asegura que los servicios se
mantengan y cualquier anomalía sea debidamente atendida. Por lo tanto, los
aportes a esta actividad provendrán principalmente de la comunidad de
usuarios en forma de incidentes y solicitudes de servicio. Estas solicitudes de
servicio llegan a la actividad Entrega y soporte a través de la actividad
Engage. Recuerde que los usuarios hablan con Entregar y Soporte a través de
la actividad Engage.
Aparte de las solicitudes de soporte, los diversos contratos y acuerdos y el
conocimiento y la información sobre los componentes de terceros se alimentan
a través de la actividad Engage. Esta información es vital para el
mantenimiento de los servicios.
En la actividad Obtener/Crear, observamos cómo se realiza la transición
del flujo de servicios que se construyen a través de la actividad Diseño y
Transición. La entrada que llega a través de la actividad de Diseño y
Transición es la información y el conocimiento sobre los productos y
152
servicios que han sido objeto de transición: la información que es necesaria
para mantener los servicios en el statu quo y el conocimiento para realizar
actividades de reparación. La actividad Obtener/Crear también alimenta la
información sobre los componentes del servicio, lo que ayuda a brindar
soporte a los usuarios finales.
Las iniciativas de mejora, los planes y los estados de las actividades de
mejora continua vienen a través de la actividad Mejorar.
Salidas típicas para entrega y soporte

La actividad de ejecución más larga y continua, Entrega y soporte, actúa como
un sistema de entrada para múltiples actividades dentro de la cadena de valor y
para los usuarios.
Los servicios que se entregan y el soporte que se extiende a través de
incidentes y solicitudes de servicio son los principales resultados para los
clientes y la comunidad de usuarios. Mientras brinda asistencia a los usuarios,
la actividad de Engage, que proporciona las entradas para brindar asistencia a
los usuarios, debe estar informada de su progreso. Digamos por ejemplo que
un usuario plantea una incidencia afirmando que
SERVICIO
la impresora en la bahía no funciona. La actividad Entrega y soporte resuelve

el problema de la impresora y envía una notificación a través de la actividad
Engage al usuario de que la impresora ahora está funcionando.
Además, cualquier cambio necesario en los contratos y acuerdos también
vuelve a la actividad de Engage.
Además de los estados de las tareas de soporte, la actividad Engage
también recibirá información de rendimiento que indica los niveles de servicio
que se han acordado para el servicio. Esta información también se alimenta a
la actividad Mejorar, que actúa como entrada para identificar iniciativas de
mejora.
La actividad Entrega y soporte también contribuye a las mejoras
mediante la identificación de oportunidades de mejora y el ingreso de esta
153
información a la actividad Mejorar para tomar medidas adicionales. En
general, esto funcionaría de dos maneras. En primer lugar, se envían
encuestas a los clientes y usuarios en busca de sus comentarios sobre el
servicio y la asistencia. Estas entradas podrían cotejarse y analizarse para
identificar oportunidades de mejora. En segundo lugar, el personal de TI que
trabaja en Deliver and Support conoce los servicios como la palma de su
mano porque los tratan muy de cerca y se encuentran en posición de
identificar oportunidades de mejora. Todos estos consejos de mejora son
como polvo de oro para cualquier proveedor de servicios.
La actividad de Diseño y Transición requiere comentarios sobre sus
diseños y transiciones que se han implementado. Esta retroalimentación viene
en forma de información de desempeño del servicio de Entrega y Soporte. Los
ejemplos de información de rendimiento del servicio incluyen informes de
disponibilidad, informes de capacidad e informes de ancho de banda de la red.
Los cambios en los servicios son bastante comunes durante las
operaciones. Podrían venir en forma de reemplazo y reconfiguración de la
infraestructura o cambios en la red o el software. Dichas actividades son
manejadas por Obtener/Crear, y esta información llega a través de la actividad
de Entrega y Soporte.
5-1. ¿Cuál de los siguientes no figura en los componentes del

sistema de valor del servicio?
A. Principios rectores
B. cuatro dimensiones
C. Prácticas
D. Mejora continua
5-2. ¿Cuál de los siguientes representa con precisión la

definición de oportunidades?
A. Representa opciones o posibilidades para agregar valor a
154
las partes interesadas o de otra manera mejorar la organización
B. Proporciona información sobre la demanda para la creación de valor para

el sistema de valor del servicio.
C. Brinda la opción de agregar recursos y activos para satisfacer la demanda
proveniente de los patrocinadores.
D. Representa las diversas opciones de valor que se pueden presentar al
cliente para que pueda ser co-creado
5-3. ¿Cuál de las siguientes actividades tiene que ver con las
partes interesadas?
A. Comprometer
B. Entregar y apoyar
C. Gestión de la relación con el cliente
D. Gestión de relaciones comerciales

SERVICIO
5-4. La función principal de Obtener/Crear es:
A. Obtener recursos y construir planes
B. Desarrollar planes de proyecto e implementarlo.
C. Asegurar recursos y desarrollar servicios
D. Proteja los productos y cree servicios
5-5. ¿Cuál de los siguientes no es un resultado de la actividad Entrega y

soporte?
A. Obtener/Construir
B. Usuarios
C. Plan
D. Diseño y Transición
155
CAPÍTULO 6
Influir a través de
principios rectores
Piense en los principios rectores como un conjunto de límites que se trazan.
Puedes jugar dentro de estos límites y, sin costo alguno, cruzarlos. Bueno, para
reformularlo, se trata más de recomendaciones y no de reglas o políticas a las que
está sujeto. La naturaleza no prescriptiva de ITIL es quizás uno de sus puntos
fuertes y continúa el legado con los principios rectores.
El concepto de principios rectores es, de hecho, nuevo para ITIL. Comenzó
mucho más tarde en 2016 con la certificación ITIL Practitioner. Para empezar tenía
nueve principios rectores, y en ITIL 4 hay siete. Esto no implica que la lista haya
sido recortada. Los principios se han renovado desde el principio, se han ampliado
y algunos de los principios se han combinado para que la lista sea completa y no
engorrosa. Los siete principios rectores de ITIL son los siguientes:
1. Centrarse en el valor
2. Comienza donde estás
3. Progreso iterativo con retroalimentación
4. Colaborar y promover la visibilidad
5. Piense y trabaje holísticamente
6. Manténgalo simple y práctico
7. Optimizar y Automatizar

6361-7_6
CAPÍTULO 6 INFLUENCIAR A TRAVÉS DE
PRINCIPIOS RECTORES
CAPÍTULO 6 INFLUENCIAR A TRAVÉS DE PRINCIPIOS RECTORES
En aras de imprimir y recordar los principios rectores, también lo he incluido

en forma cíclica en la Figura 6-1 .
Figura 6-1. Principios rectores
Consejo de examen Los principios rectores son el tema

más importante en el examen básico de ITIL por la cantidad
de puntos que puede llevar. Puede esperar obtener cinco
preguntas en su examen básico de ITIL, es decir, el 12,5 %
del total de preguntas. Las preguntas pondrán a prueba su
comprensión y se le pedirá que aplique su comprensión para
responder las preguntas. Por ello, he profundizado en este
tema para asegurar su máxima probabilidad de éxito.
157
PRINCIPIOS RECTORES
Definición de principio rector de ITIL

Una recomendación que guía a una organización en todas las
circunstancias.
En mi opinión, estos principios rectores no se limitan únicamente a ITIL y la

gestión de servicios. Puede aplicarlos a cualquier industria y sería cierto. En otras
palabras, son universales y, lo que es más importante, prácticos. Cada uno de ellos
es sentido común y, sin embargo, debe recordarse en cada paso del camino.
De varias maneras, los principios rectores de ITIL siguen el manifiesto Agile.
Por ejemplo, el software de trabajo sobre la documentación completa es un
ejemplo clásico de dónde ponemos énfasis en las cosas que embellecen pero no en
el valor central. Los principios rectores Centrarse en el valor y mantenerlo simple
y práctico encajan bien con él. Del mismo modo, responder al cambio en lugar de
seguir un plan se incorpora con Progreso iterativo con retroalimentación.
Nota estados de manifiesto ágiles (no dentro del alcance

del examen básico de ITIL):
Individuos e interacciones sobre procesos y
herramientas
Software de trabajo sobre documentación completa
Colaboración con el cliente sobre la negociación del
contrato Responder al cambio sobre seguir un plan
Cada organización implementa la gestión de servicios a su manera. Hay

varios otros marcos y metodologías en uso. Las organizaciones optarán por
combinar y mezclar diferentes metodologías
158
PRINCIPIOS RECTORES
y marcos para crear un marco personalizado que funcione para ellos. Los
principios rectores aseguran que dejan suficiente espacio para que estos
marcos se combinen y generen sinergias. Es importante tener en cuenta que
los principios rectores trabajan para crear valor para el cliente y ayudar a
mejorar los productos y servicios de forma continua.
La metodología ágil proporciona orientación sobre cómo se deben ejecutar
los proyectos de manera ágil, lo que promueve la flexibilidad y el dinamismo.
El valor se genera a través de la satisfacción de las necesidades cambiantes de
los clientes. DevOps va un paso más allá al actuar como un superconjunto para
el desarrollo y las operaciones. Mientras que los procesos de desarrollo se
gestionan a través de Agile, las operaciones se realizan a través de ITIL. La
fusión de los dos marcos/metodologías no es perfecta. Cuando tiene un equipo
común trabajando en ambos, es probable que tenga conflictos, como la forma
en que prioriza uno sobre el otro. Es en tales situaciones que los principios
rectores generales entrarían en juego para proporcionar dirección. Para el
ejemplo de la priorización, siga creando valor como norte verdadero. Luego,
sopesa los diversos elementos de desarrollo y operación contra el valor que
crean, trabaja en un elemento que genera el mayor valor y luego baja en la
lista. Por supuesto, he diluido bastante el escenario. Tendrás otros factores en
juego, y el propietario del producto actuará como determinante del valor. De
manera similar, para otros marcos como Prince, Lean, COBIT y otros, podría
aplicar el mismo conjunto de principios para ponerlos bajo una estrella polar
común.
Una organización no debe seleccionar y elegir los principios rectores que
le son aplicables, porque todos ellos vienen como un conjunto de cajas y tiene
sentido práctico practicarlos. Sin embargo, no todos los principios rectores son
aplicables en todas las circunstancias y escenarios. Una organización debe
identificar los principios rectores relevantes para el escenario y usarlos con
criterio.
159
PRINCIPIOS RECTORES
Consejo de examen Es importante identificar los siete
principios rectores.
sin embargo, lo que es más importante es el contexto en
el que se pone en práctica cada principio rector.
Centrarse en el valor
Todo ITIL se basa en la creación de valor para el cliente. Entonces, un
principio rector que dice específicamente centrarse en el valor está
exagerando, ¿no es así? No precisamente. Este principio rector, el primero de
los siete, brinda un límite definido, pasos y dirección para enfocarse en lo que
es más importante para nuestros consumidores y clientes.
Definición de ITIL del principio rector del enfoque en el valor

Todas las actividades realizadas por la organización deben
vincularse, directa o indirectamente, con el valor para sí misma,
sus clientes y otras partes interesadas.
Un proveedor de servicios existe no para brindar servicios a los clientes,

sino para brindar valor a través de los servicios. ¿Cómo logra esto un
proveedor de servicios? Según la definición de ITIL, el servicio que se ofrece
debe ser diseccionado en términos de sus entregables. Cada uno de estos
entregables debe asignarse al consumo de servicios y los procesos comerciales
al final del cliente. A través de este ejercicio, un proveedor de servicios estará
en una situación ideal para medir si los servicios ofrecidos están generando
valor y si se puede generar más valor ajustando los servicios y, en el proceso,
puede crear valor para sí mismo junto con otras partes interesadas
involucradas a través del valor. ciclo de vida de la generación.
Tomando el ejemplo de Netflix, el servicio de transmisión de video brinda
un amplio valor a los clientes a quienes les gusta entretenerse y quieren pasar
160
PRINCIPIOS RECTORES
el aburrimiento al hacerlo. Recopilan datos de sus clientes sobre el género, el
idioma y las clasificaciones de edad que transmiten sus clientes. Esta
información se utiliza para recomendar otros espectáculos disponibles a los
clientes y para financiar nuevos espectáculos que están en líneas similares a
las que indica la demanda. Este ejercicio de recopilación de datos de Netflix y
su uso inteligente es un ejemplo de cómo generar más valor para el cliente. En
el proceso, Netflix también crea valor a través del contenido que produce, lo
que podría llevar a que se registren más clientes. Otras partes interesadas,
como las productoras, los escritores de historias y los actores, también se
vuelven parte de la generación de valor y crean valor para ellos mismos a
través de la producción de videos.
La generación de valor se puede realizar normalmente mediante el
proceso de cuatro pasos:
1. Comprender al consumidor del servicio
2. Comprender la perspectiva del consumidor del servicio.
3. Obtener retroalimentación del cliente
4. Aplicando los aprendizajes
Entendiendo al Consumidor de
Servicios
La generación de valor 101 dicta que conoces a la persona que va a disfrutar
de tu servicio. A menos que comprenda los deseos, gustos, necesidades y
necesidades del consumidor, no puede aspirar a brindar un servicio que lo
haga feliz. Un consumidor de servicios generalmente está contento si el
servicio genera valor y puede cumplir con los propósitos previstos.
Un restaurante mexicano que quiere abrir en un barrio estudia el entorno
antes de montar su negocio. Dependiendo de la clase de personas y las etnias,
deciden si abren la tienda. Es probable que este restaurante funcione bien en
161
PRINCIPIOS RECTORES
un vecindario que tenga etnias que prefieran la comida picante, como los
indios. Un barrio chino típico preferiría algo más cercano a lo asiático que a lo
occidental, por ejemplo.
Además de los propios consumidores de servicios, un proveedor de
servicios debe buscar la comprensión de las otras partes interesadas en juego,
como los patrocinadores que financiarán el servicio, los clientes y otros, según
sea necesario.
Comprensión del consumidor del

servicio
Perspectivas
Conocer al consumidor es información. Conocer en profundidad a los
consumidores y sus necesidades es conocimiento. El proveedor de servicios
debe aspirar a profundizar, no solo a obtener respuestas objetivas a las
preguntas, sino a comprenderlas verdaderamente al analizar las perspectivas.
Por lo general, esto sería responder a las 6 preguntas: quién, qué, dónde,
cuándo, por qué y cómo.
Desde una perspectiva de gestión de servicios, esto se traduce en una
comprensión del proveedor de servicios:
1. ¿Por qué el consumidor utiliza este servicio?
2. ¿Cómo genera valor el servicio?
3. ¿Quién lo usa?
4. ¿Dónde y cuándo se usa?
5. ¿Qué se consigue a través de los servicios?
6. ¿Cuáles son las limitaciones financieras para el cliente?
7. ¿Qué riesgos están involucrados que se pueden prever?
162
PRINCIPIOS RECTORES
Recuerda que el valor tiene mucho que ver con la percepción. Puede que
sea brillante ofreciendo un servicio de Internet de banda ancha basado en fibra.
Pero si su marca tiene una percepción negativa, los clientes pueden irse a otra
parte. Por lo tanto, es esencial en el proceso de generación de valor medir el
valor a través de los ojos del cliente en lugar de meros números. En segundo
lugar, la percepción del valor no siempre permanece constante. Un hermoso
lugar de vacaciones en
Escocia podría tener cero visitantes en tiempos de pandemia, por ejemplo.
Finalmente, los costos y los riesgos juegan un papel importante ya sea que un
cliente elija un proveedor de servicios o no. Es posible que los clientes no
opten por servicios baratos por temor a que su calidad sea inferior al estándar
y opten por algo razonable y justo.
Obtención de comentarios del cliente

La retroalimentación es como el polvo de oro en la industria de servicios. Con
las percepciones cambiantes de valor para un cliente, mantenerse al día es un
desafío para los proveedores de servicios. Por lo tanto, intentan obtener
comentarios de sus clientes sobre varios factores. Intente asignar esto a los
1001 correos electrónicos que recibe de su proveedor de servicios en busca de
2 minutos de su tiempo. Al hacer clic en este enlace en el correo electrónico,
lo llevará a una encuesta que tiene como objetivo comprender sus
percepciones potencialmente cambiantes.
La retroalimentación trata principalmente de comprender la experiencia
del cliente (CX), que también se conoce como experiencia del usuario (UX).
CX se define como el producto de las interacciones entre una organización y
un cliente durante un período, con respecto a los productos y servicios. Esta
experiencia/retroalimentación proporcionará información sobre cómo se siente
un cliente con respecto al producto/servicio y la organización que lo
proporciona.
163
PRINCIPIOS RECTORES
Como mencioné en el paso anterior, es un juego de percepciones. CX se
basa en cómo se siente un cliente acerca de un servicio. Para el mismo
servicio, tendrá un conjunto de clientes a los que les podría encantar y una
medida igual que podría odiarlo. Tomemos el ejemplo de una película. Tienes
ciertos críticos que son extremadamente críticos y otros que saludan con
grandes elogios. Cuando mira a través del espectro, encontrará la experiencia
del cliente expresada en varios tonos de gris. Una organización proveedora de
servicios en tal situación observaría la percepción de la mayoría, y si la
retroalimentación popular es hacer ciertos cambios, definitivamente optará por
hacerlo.
Aplicación de los
principios/aprendizajes
¿Cuál es el punto de realizar encuestas, recibir comentarios y gastar toneladas
si no va a utilizar el conocimiento para realizar cambios en los productos y
servicios? Es como un pescador que se toma la molestia de adentrarse en las
profundidades del mar y atrapar un pez solo para arrojarlo de vuelta al mar.
Se recomiendan los siguientes cuatro pasos para aplicar los principios:
1. Entender al cliente, sus expectativas y percepciones.

2. Recopile comentarios sobre el servicio de los clientes,
consumidores y otras partes interesadas relacionadas. La
retroalimentación debe obtenerse a lo largo del período en
que los consumidores disfrutan del servicio.
3. El personal del proveedor de servicios debe estar al tanto
de los intereses de los clientes, sus gustos y disgustos.
Capacitar aún más al personal para mejorar la experiencia
del cliente.
4. La creación de valor debe realizarse en cada paso del
servicio, especialmente durante las operaciones. Es en las
etapas operativas cuando los usuarios interactúan más con
164
PRINCIPIOS RECTORES
el personal del proveedor del servicio. Entonces, esta es
una interacción crítica que afecta directamente la
generación de valor. Durante otras fases del proyecto,
como la iniciación, el diseño y la mejora, asegúrese de que
el cliente se tenga en cuenta en la creación conjunta de
valor.
5. Las personas del personal del proveedor de servicios y la
organización del cliente deben ser partes interesadas en el
proceso de generación de valor durante cualquier
actividad de mejora que se lleve a cabo. Haga transparente
lo que significa el valor, cómo se mide y cómo las partes
se unen para crearlo.
Consejo de examen comprender el tema asociado con

el valor como centrarse en el consumidor/cliente y sus
percepciones, comentarios y actuar en consecuencia. Es
como el ciclo pdCa. en el examen, puede esperar
preguntas que pondrán a prueba su comprensión de
cómo se crea valor.
Comienza donde estás

Piensa en la transformación del cuerpo. Para parecerse a un dios griego, solo
puede comenzar desde el estado actual de su cuerpo y comenzar su régimen
para transformar su cuerpo. No puedes simplemente decir, desechemos este
cuerpo y empecemos de nuevo. Suena ridículo, ¿no? Sí, lo hace y por una
razón.
Muchas veces, cuando las organizaciones se lanzan a ejercicios de
transformación o incluso cuando necesitan llegar al punto B desde el punto A,
165
PRINCIPIOS RECTORES
es emocionante y tentador para los involucrados comenzar todo de nuevo. Sin
los gastos generales del estado actual, los arquitectos podrían construir lo que
quisieran y diseñar obras maestras. En realidad, no funciona de esta manera.
Para comenzar algo desde cero, necesita un gran capital, y no solo finanzas.
Lleva más tiempo llegar al punto B comenzando de nuevo y, lo que es más
importante, acostumbrarse a las nuevas formas de trabajar nunca será fácil.
Finalmente, podría haber una base sólida hoy que ignoramos por completo en
aras de la emoción.
En este principio, animamos a empezar desde donde estamos en lugar de
empezar de nuevo. Buscamos reutilizar el núcleo básico en lugar de sentar una
nueva base. Y definimos un proceso para hacer este juicio.
Nota Más de una vez he mencionado que el

presente y el futuro está en el espacio devops. para una
organización tradicional de gestión de servicios y
desarrollo cambiar a DevOps es un gran desafío. La
implementación de Devops ocurre en fases, donde
intentamos y reutilizamos componentes de los procesos
existentes y los integramos en la metodología holística. Al
hacer esto, los usuarios, el personal y otras partes
interesadas no se sienten alienados de los procesos
existentes y se resisten a los nuevos.
Evaluar el estado actual

Antes de hacer una llamada para cambiar algo, vale la pena ver dónde se
encuentra actualmente. Puede que no sea un camino arduo hacia el objetivo
previsto si comienza con lo que tiene. O puede ser mejor desechar todo y
comenzar con una pizarra en blanco. La respuesta a cualquiera de estas
opciones se puede obtener si el estado actual se evalúa objetivamente.
166
PRINCIPIOS RECTORES
A menudo sucede que nos proponemos cambiar algo creándolo de nuevo,
y la evaluación del estado actual se realiza meramente como un ejercicio
académico; entonces es muy posible que terminemos con resultados de
evaluación que apunten a comenzar de nuevo. Por el contrario, si está
inclinado a construir sobre lo que tiene, la evaluación se coloreará de la
manera prevista.
Por lo tanto, es crucial que la evaluación realizada sea imparcial y se vea
puramente a través de los ojos de la objetividad. Por lo tanto, el evaluador
debe ponerse el sombrero de un niño inquisitivo que cuestiona cada
movimiento, para identificar el motivo y obtener un verdadero sentido de la
realidad.
El verdadero sentido de la realidad se puede obtener a través de la
medición. Las medidas también se pueden colorear a través de la
interpretación. Por lo tanto, se recomienda que los parámetros de medición
queden expuestos, sin ambigüedades, y que las mediciones se tomen de la
fuente y se automaticen siempre que sea posible.
medir todo
Cuando comencé mi viaje de transformación corporal, lo primero que me
preguntó mi entrenador fue si tenía una cinta métrica y una balanza. Hizo
hincapié en que las líneas de base deben medirse antes de comenzar el viaje, y
necesitábamos seguir midiendo y registrando las mediciones cada semana.
¿De qué otra manera podemos saber que algo está funcionando a menos que se
mida?
En la gestión de servicios, se recopilan varias métricas y se realiza un
seguimiento de los indicadores clave de rendimiento (KPI). Sin embargo,
donde algunas de las organizaciones pueden equivocarse es al medir los
números equivocados.
Volviendo a los productos y resultados: haga un seguimiento de los
resultados, no de los productos. La mesa de servicio a menudo está vinculada
con un KPI conocido como correcto a la primera, lo que hace que el agente
tenga la responsabilidad de resolver el problema mientras la persona que llama
167
PRINCIPIOS RECTORES
permanece en la línea y no tiene que poner el ticket en espera o pasárselo a un
colega. Para lograr este KPI, el agente podría intentar cerrar la llamada con
una resolución incompleta que conduzca a un resultado deseado pero no
necesariamente a un resultado favorable. Lo más probable es que esto deje un
mal sabor de boca al cliente y el resultado del servicio no genere valor en
ningún sentido. En lugar de medir el parámetro correcto a la primera, mida si
el cliente tuvo que volver a llamar para informar el mismo problema; medir si
el cliente siente que la solución brindada es completa; y medir principalmente
desde la perspectiva del cliente. Esto le dará el verdadero sentido de las
mediciones que le da a la organización una muestra de la realidad.
Nota La ley de goodhart es apta para esta situación y

establece: cuando una medida se convierte en un objetivo,
deja de ser una buena medida.
168
PRINCIPIOS RECTORES
Aplicación de los
Con una buena comprensión del estado actual de las cosas respaldado por
mediciones que brindan una realidad completa, estará en una posición bastante
buena para decidir optar por una revisión o una construcción/renovación sobre
el estado actual.
Reiterando y poniendo el principio en práctica, el enfoque que
probablemente adopte se parecerá a los cuatro pasos indicados en la figura 6-2
.
Figura 6-2. Aplicando el principio de empezar donde estás
Considere un ejemplo de un sitio web que necesita ser modernizado, y

se agregarán ciertas nuevas funciones de análisis y carrito de compras.
Paso 1
Haría una evaluación de los diferentes elementos del sitio web, como el
sistema de administración de contenido que ejecuta el sitio web, los datos, la
tecnología de codificación y la flexibilidad para integrarse con otras
herramientas que desee introducir.
Mientras hace esto, no se detendrá solo con el sitio web; puede evaluar el
servidor en el que está alojado, el rendimiento y la seguridad.
Al final de este ejercicio, tendrá un buen manejo de lo que está tratando.
El siguiente paso es convertir esta información en conocimiento.
169
Paso 2
Ahora es el momento de crear dos categorías: lo que funciona y lo que no.
Recuerda el dicho: si no está roto, no lo arregles.
Su sitio web se ejecuta en Wordpress, uno de los mejores sistemas de
administración de contenido. El tema que está ejecutando es antiguo y tiene
errores. El sitio web está alojado en un servidor que se comparte con otros
usuarios, lo que provoca problemas de rendimiento. El mismo aspecto
también podría aparecer en su lista de seguridad. Cuando se trata de integrar
carritos de compras, hay muchos complementos que ofrecen una fácil
integración.
Paso 3
Póngase el sombrero de un administrador de riesgos y comience a evaluar
los riesgos con el sistema actual. Qué tan seguro es Wordpress, dado que los
complementos que funcionan con él representan una amenaza al dar entrada
por la puerta trasera a los piratas informáticos y los spammers.
¿Cuáles son los riesgos asociados con continuar con el mismo servidor?
A continuación, ¿qué sucede si decide mudarse de Wordpress a una
solución alternativa como Joomla? ¿Qué riesgos ve o es todo brillante y
verde? ¿Introducirá más complejidad en el sistema de administración de
contenido a través de Joomla? Si Joomla es más seguro, ¿cuáles serían las
compensaciones entre un software fácil de usar y mantener como Wordpress y
Joomla complejo y seguro? Además, existen riesgos de mayores gastos al usar
Joomla debido a su complejidad.
Su ejercicio de evaluación de riesgos extraería todas estas preguntas, lo
que brinda una plataforma estable para la toma de decisiones.
Etapa 4
Como propietario de un sitio web, debo tomar una decisión en función de
la información recopilada en los pasos 1, 2 y 3. No quiero que los costos se
excedan. En cuanto a la seguridad, el administrador de riesgos me dice que
hay formas de proteger los sitios web de Wordpress. Por lo tanto, reutilizar
Wordpress me ayudaría a permanecer en la zona familiar para realizar
actualizaciones del sitio web y los minúsculos cambios de configuración que
realizo de vez en cuando. Decido quedarme con Wordpress.
170
El servidor es una preocupación y decido mudarme a AWS en un servidor
que es exclusivo para mí. Esto soluciona los problemas de rendimiento, y me
dijeron que el rendimiento se puede mejorar sobre la marcha agregando
recursos al servidor de forma dinámica.
PRINCIPIOS RECTORES
En cualquier caso, optar por un nuevo diseño de sitio web siempre iba a
suceder. Esto se hará como un tema de Wordpress.
Este principio se puede aplicar a productos, servicios, procesos, prácticas,
estructura de equipo o cualquier otra parte de la organización y el sistema de
valor del servicio.
Nota Es extremadamente raro que los productos,

servicios o prácticas se revisen sin reutilizar lo que ya
existe. incluso en los ejercicios de transformación,
reutilizamos lo que ya está allí y comenzamos a construir
sobre él.
Progreso iterativo con

retroalimentación
El tercer principio se relaciona directamente con el marco de gestión de
proyectos Agile, donde el trabajo se divide en partes individuales y se entrega
en varias iteraciones. DevOps es un superconjunto de construcciones ágiles
según el principio de iteraciones que se definen por retroalimentación.
El concepto de entrega ágil, como su nombre indica, se basa en la premisa
de que los requisitos cambian y un proyecto realizado con un enfoque
tradicional no crea valor, ya que la percepción del valor (requisitos) cambia en
el momento en que se entrega. Para evitar este abismo entre el valor y la
entrega, la gestión de proyectos se transformó en entrega en varias iteraciones,
171
y cada iteración sucesiva consideraría los requisitos cambiantes y los
comentarios recibidos de las partes interesadas involucradas.
Hoy en día, la mayoría de los proyectos de TI se construyen en un modelo
Agile y tienen mucho éxito porque los proyectos ya no son proyectos, sino que
giran en torno a productos. Junto con la metodología DevOps, la gestión de
productos ha reemplazado a la gestión de proyectos.
La gestión del producto implica la construcción de mejoras y el
mantenimiento del producto. Las mejoras pueden presentarse en múltiples
facetas, ya sean cambios en el producto o servicio, o el entorno tecnológico
subyacente, los procesos, las prácticas y otros elementos que intervienen en
la elaboración de un producto o servicio.
En el pasado, bajo el proceso de administración de lanzamientos,
usábamos dos técnicas para implementar lanzamientos: big bang y enfoques
por fases. En big bang, el lanzamiento se implementó en una sola iteración,
mientras que un enfoque por fases consideró múltiples iteraciones y tenía
como objetivo estudiar la primera iteración antes de pasar a la siguiente. Sin
embargo, la iteración anterior de ITIL se diseñó para funcionar en un
modelo en cascada donde primero se recopilan, diseñan, construyen,
implementan y luego se mantienen todos los requisitos.
Importancia de la retroalimentación
Como dice el refrán: “la retroalimentación es el desayuno de los campeones”.
Si un producto o servicio debe seguir siendo relevante en el mercado actual,
debe depender de los comentarios de los clientes y debe evolucionar
dinámicamente.
El papel de la retroalimentación debe mantenerse al más alto nivel y en
cada etapa del servicio prestado. Se debe solicitar retroalimentación y se debe
persuadir a los clientes para que proporcionen retroalimentación. A menos que
el proveedor de servicios sepa lo que el cliente está pensando, nunca tendrá
una comprensión precisa de los deseos y necesidades, lo que se traduce en la
entrega de valor, lo que conduce a la continuación de la relación comercial.
Por lo tanto, la carga de identificar cuándo, dónde y cómo obtener
172
retroalimentación del cliente recae únicamente sobre los hombros del
proveedor de servicios. Un proceso de retroalimentación maduro puede
esperar reunir:
1. Percepción del usuario del producto/servicio
2. Percepción del cliente del producto/servicio
3. Próximos requisitos (demanda)

PRINCIPIOS RECTORES
4. Comprensión de las deficiencias de la cadena de valor
5. Información sobre las relaciones de los clientes con sus socios,

proveedores y prestadores de servicios
Supongamos que está creando un juego de rol utilizando el marco Agile.
En la primera iteración, construyes los mundos donde los jugadores lucharán
por el dominio. El cliente (o podrían ser delegados) se familiariza con el
entorno y proporciona sus comentarios. Sus comentarios se consideran para el
desarrollo en la próxima iteración junto con el diseño de personajes. Al final
de la iteración dos, el cliente dice que está contento con el entorno, pero los
personajes no salen bien, parecen más bien insignificantes. En la iteración
tres, arreglas los caracteres. Así es como se utiliza la retroalimentación en los
proyectos Agile para entregar lo que el cliente quiere, donde el cliente se
convierte en parte del viaje en lugar de solo ser aceptado al final de todo.
Nota No todos los comentarios valen oro. También

obtienes paja. por lo tanto, es importante que se estudien
los comentarios y se comparen con el producto que está
diseñando. Si la retroalimentación tiene sentido, entonces
adelante y utilícela. de lo contrario, informe al cliente junto
con la justificación.
173
Iteraciones de alimentación de
retroalimentación
Las iteraciones son como mini proyectos. Toda la secuencia de desarrollo y
prueba tiene lugar dentro de una iteración. Lo que es más importante, las
iteraciones tienen un límite de tiempo, lo que significa que hay un marco de
tiempo definido para cuándo comienzan y cuándo terminan las iteraciones. A
menos que se notifique, una iteración sigue a otra y luego a la siguiente. Estas
iteraciones se conocen como sprints en el marco Agile.
Esto se ilustra en la Figura 6-3 .
Figura 6-3. Iteración de alimentación de retroalimentación
Entonces, aunque la iteración a través de Agile brinda una gran

flexibilidad, existen restricciones que deciden qué parte del trabajo se acepta
en una iteración; por lo general, no se recomienda que se acepten nuevos
trabajos en una iteración a mitad de camino. Además, el equipo seleccionará
tanto trabajo que sea proporcional a la capacidad disponible. La flexibilidad no
significa que los recursos que trabajan en el proyecto durarán día y noche y se
extenderán más allá de sus posibilidades para entregar más de lo que pueden
manejar.
En el ejemplo de desarrollo de juegos, normalmente al final de un sprint
se lleva a cabo una sesión de demostración para el cliente. Se espera que el
174
cliente participe y proporcione retroalimentación. Los comentarios se
consideran y analizan de inmediato y se le pide al cliente que priorice el
trabajo en los comentarios u otros elementos abiertos. Según las
instrucciones del cliente sobre la priorización, el equipo trabaja en los
requisitos en la siguiente iteración. En esencia, la retroalimentación
alimenta las iteraciones y tiene una influencia definitiva en el desarrollo que
ocurre en cada iteración. Por lo tanto, es esencial que el proveedor de
servicios obtenga retroalimentación y vuelva al cliente rápidamente para
garantizar que no se pierda el poder de la retroalimentación en la iteración.
175
PRINCIPIOS RECTORES
Si bien Agile es el camino actual y el camino a seguir, no garantiza el
éxito todo el tiempo. Hay ocasiones en las que el equipo del proveedor de
servicios puede no tener éxito en la entrega de lo que prometió. La capacidad
del proveedor de servicios para aprender de los errores y adaptarse a una
velocidad de vértigo a las carencias será definitiva. Se trata de fallar rápido y
aprender de la experiencia. Solo entonces la calidad del resultado se
mantendrá en una brillante armadura.
Aplicación de los
Hay algunas técnicas que el poder de las iteraciones y la retroalimentación
ponen sobre la mesa. Uno de los más utilizados es el producto mínimo viable
(MVP). En esto, el producto/servicio que ha concebido se construye con la
mínima configuración posible y, en ocasiones, un subconjunto del
producto/servicio final. Al invertir una fracción de recursos y esfuerzos, la
retroalimentación recibida del MVP es valiosa para la planificación y
ejecución de la entrega final.
Digamos que está construyendo un sistema bancario en línea. Cualquier
sistema de este tipo tendrá varias funcionalidades como estados de cuenta,
transferencias e instrucciones permanentes, entre otras. En lugar de planificar
la creación de todas las funcionalidades, elige la más básica: extractos de
cuenta. Desarrollarlo y luego buscar retroalimentación de los clientes. De
hecho, muchas organizaciones crean un producto MVP e invitan a los usuarios
finales a probarlo y brindarles sus comentarios. En este caso, los clientes
bancarios normales lo usarían como lo harían con el sistema bancario en línea
existente y proporcionarían sus puntos de vista. Con base en la
retroalimentación, el desarrollo del producto puede alterar el curso, hacer
correcciones y avanzar en una dirección para cumplir con lo que más les gusta
a los clientes.
176
PRINCIPIOS RECTORES
Nota el uso de iteraciones no implica que el
desarrollo ocurra a un ritmo más rápido. Las iteraciones y
MVp tampoco implican que se lancen al mercado
productos incompletos o a medio cocer. un producto se
puede dividir en varias piezas de funcionalidades
individuales. En las iteraciones, las funcionalidades
individuales se identifican para ser desarrolladas en un
período de tiempo. en concreto, en MVp se incluye el
conjunto mínimo de funcionalidades requeridas para
caracterizar el producto.
Si bien recomendamos trabajar en iteraciones alimentadas por

comentarios, no debemos perder de vista el producto final que se ha
visualizado. En otras palabras, no te desvíes del objetivo final que debes
alcanzar. Es posible que trabajar en iteraciones ponga anteojeras a los equipos
involucrados, lo cual no es del todo incorrecto. Por lo tanto, un representante
del cliente, un miembro del equipo del proyecto llamado propietario del
producto, está en el lugar para controlar el progreso en relación con la entrega
del producto final.
Hay muchas trampas en las que puede caer el equipo de desarrollo. Una de
las trampas comunes es desarrollar una vez y desarrollar bien; se realiza una
buena cantidad de análisis antes de que pueda comenzar el desarrollo. A veces,
el análisis es tan profundo y detallado que el equipo a cargo no sabría dónde
parar su análisis y este concepto se llama parálisis de análisis . Para evitar
esto, cada actividad que emprenda el equipo debe tener un límite de tiempo,
incluidos los esfuerzos de desarrollo no centrales.
Colaborar y promover la visibilidad
177
PRINCIPIOS RECTORES
La colaboración, la cooperación y la visibilidad son algunos de los factores
clave que impulsan las metodologías Agile y DevOps. Especialmente en
DevOps, sin la colaboración de los miembros del equipo y los equipos, la
idea de que un solo equipo se una para lograr el éxito de un producto es
impensable. Asimismo, el trabajo que se realice debe ser transparente para el
cliente. El cliente debe participar en las actividades del día a día. De ahí la
necesidad de que el propietario del producto sea parte del equipo de
desarrollo. Los días en que la organización de los proveedores de servicios
era una caja negra se acabaron. Bienvenido al mundo donde los clientes y
los proveedores de servicios colaboran, comparten y se convierten en socios
para crear valor y éxito.
En el pasado, el concepto de trabajo estaba muy aislado y teníamos
personas sentadas en varios equipos que dominaban un conjunto de
habilidades en particular. Fueron reunidos para la ejecución de un proyecto, y
cuando el proyecto concluyó regresaron a sus cuevas. Este es un tipo de
matriz de una organización. Incluso hoy en día, muchas organizaciones
confían en él, aunque afirman ejecutar productos en una metodología
DevOps. Los silos promueven la división y no comparten conocimientos.
Contener información y conocimiento dificultará el proceso de toma de
decisiones, lo que impacta a toda la organización.
Socios de colaboración
Los días de un solo proveedor de servicios o la entrega interna completa han
terminado. Múltiples proveedores de servicios deben trabajar juntos para
lograr la entrega de un solo producto. Por ejemplo, una aplicación podría tener
una empresa trabajando en el lado del desarrollo, otra organización
apoyándola y otra organización más cuidando sus interfaces. En tal escenario,
existen ciertos secretos comerciales que las organizaciones querrían mantener
en secreto. Sin embargo, hacerlo solo dañará al cliente porque da como
resultado una entrega deficiente, una resolución retrasada y una mayor
repetición del trabajo. Entonces, ¿las organizaciones evitan sus diferencias y
178
PRINCIPIOS RECTORES
sus propuestas de venta únicas para el mejoramiento del cliente? La respuesta
podría ser sí en ciertas situaciones. La situación podría ser cuando varios
proveedores de servicios están trabajando en la misma pieza de código o en
una tecnología compartida. Por ejemplo, el proveedor de servicios que trabaja
en soporte podría beneficiarse de los esfuerzos de codificación de otro
proveedor de servicios. Pero considere el panorama general. Cada empresa
tendrá algo que dar y algo que tomar. Entonces, si bien podrían terminar
abriendo los brazos para compartir sus habilidades, podrían ganar en un área
diferente. Después de todo, los otros proveedores de servicios fueron elegidos
por su destreza en sus respectivas áreas.
Otra oportunidad de colaboración es entre el proveedor de servicios y el
cliente. Los clientes a menudo se mantienen fuera del proyecto, ya que solo se
espera que proporcionen requisitos y acepten la entrega. Al menos así era
antes, pero ahora las cosas están cambiando y los clientes participan en todos
los niveles de la entrega, incluidas la iniciación y la planificación. Si bien
compartir entre proveedores de servicios es aceptable con una pizca de sal,
cuando se trata de clientes no es tan fácil. Los proveedores de servicios
naturalmente no se sienten cómodos para invitar al diablo a sus hogares.
Quieren evitar preguntas que puedan estar relacionadas con la capacidad, las
formas de trabajar y las tecnologías empleadas. El cliente podría terminar
siendo una limitación en lugar de un contrafuerte. Una vez más, estos
pensamientos son arcaicos, porque no solo está cambiando la mentalidad del
proveedor de servicios, sino también la del cliente. Ambos trabajan hacia un
objetivo común. Si uno falla, el otro también. El juego de la culpa no termina
con uno u otro ganando. Les duele a los dos.
El juego de colaboración entre un proveedor de servicios y un cliente debe
jugarse con reglas específicas. El cliente pasa a formar parte del equipo y es
responsable de priorizar los elementos del backlog y aclarar los requisitos. El
equipo de desarrollo y el cliente se reúnen a diario para compartir
actualizaciones, incluidas aquellas en las que están atascados. Esto
necesariamente elimina el elemento sorpresa de la ecuación. Cuando finaliza
el sprint, la demostración que presencia el propietario del producto no es algo
179
PRINCIPIOS RECTORES
así como el estreno de una película vista por primera vez. Habrían sido
testigos de su crecimiento desde el día 1, y la demostración es un evento en el
que se acepta la entrega y se brindan más comentarios, lo que ayuda durante el
resto del proceso de entrega.
Dos aspectos son importantes: el proveedor de servicios querría que el
cliente estuviera abierto a proporcionar comentarios, y el cliente debería
compartir sus comentarios abiertamente sin dudarlo. Si alguno de los
comentarios es malo o incorrecto, que así sea; no le quitará la importancia de
ser un cliente. El equipo de desarrollo usará lo que sea importante y desechará
el resto.
Medios de comunicación
El mundo es plano, ¡aunque no literalmente! Clientes, proveedores de
servicios y otras partes interesadas sentados en un solo lugar es tan raro como
los dientes de una gallina. DevOps requiere colaboración, y esto es posible a
través de conversaciones frecuentes y visibilidad del trabajo. Ser remoto
realmente no es un buen augurio para la colaboración, ¿verdad? Bueno,
tenemos la tecnología para compensarlo.
Herramientas como MS Teams, Slack y Google Meet ocupan un lugar
destacado en la lista y promueven la colaboración. Las videollamadas, los
chats grupales y los tableros para compartir información (como lo hacemos en
Facebook) son algunas de las características comunes que permiten compartir
información con la familiaridad de sentarse a la mesa. El proveedor de
servicios y el cliente deben asegurarse de que tales herramientas se conviertan
en la plataforma para todas las comunicaciones y deben alejarse de otras
formas. En los programas que administro, es una regla no escrita que se
utilicen correos electrónicos donde se requiere formalidad. De lo contrario,
todas las formas de comunicación (entre pares, entre el equipo de servicio y el
cliente, entre el equipo de servicio y los proveedores) se realizan a través de
una herramienta de colaboración. No se utilizan correos electrónicos a menos
que se busquen aprobaciones con fines legales y de auditoría.
180
PRINCIPIOS RECTORES
Para que se produzcan mejoras, el papel de la retroalimentación está en el
centro. Esta comunicación se realiza a través de los clientes que hablan con
los proveedores de servicios, por lo general. Pero, ¿qué pasa con los usuarios
generales que no tienen la oportunidad de expresar su opinión y comentarios?
Para obtener sus comentarios, se realizan encuestas y estudios para recopilar
comentarios. Con base en la percepción general y la retroalimentación, se
establece contacto con los usuarios para obtener aclaraciones si es necesario,
y se emprenden acciones de mejora.
Expansión de la visibilidad
Las diversas iniciativas y actividades que se emprenden no siempre son
conocidas por los distintos niveles de una organización. Se detiene en un
determinado nivel de gestión y no se filtra. Esta falta de visibilidad afecta a la
mayoría de las organizaciones en la actualidad y es uno de los principales
obstáculos para crear espíritu de equipo y fortalecer la lealtad. Los líderes
deben difundir el mensaje de lo que está haciendo la organización,
especialmente en iniciativas de mejora y desarrollo de productos/servicios.
Esta información debe filtrarse junto con la razón para hacerlo en primer lugar
y cómo apunta al verdadero norte: la visión y los objetivos de la misión de la
organización. Lo más importante es que este no es un esfuerzo de una sola
vez. Tales comunicaciones deben ser periódicas, y los medios también
importan.
La siguiente área donde la falta de visibilidad es común es en el
desarrollo de productos/servicios, donde los clientes sienten que después de
obtener los requisitos, el equipo de desarrollo parece haber desaparecido.
La mala visibilidad del progreso del trabajo generará pánico para el cliente
porque sin ella no hay garantía de que el producto/servicio se entregue a
tiempo y según las especificaciones. El cliente puede sentir que el trabajo
encomendado al proveedor de servicios no es importante para la
organización si no exhibe el trabajo con regularidad. Por lo tanto, es
importante mantener la comunicación a través de la visibilidad continua del
181
PRINCIPIOS RECTORES
progreso del trabajo. Agile proporciona el mejor marco para cumplir con
los objetivos de visibilidad y comunicación.
Piensa en el efecto dominó. La mala visibilidad también afectará la toma
de decisiones. ¿Cómo pueden los tomadores de decisiones brindar
orientación si tienen poca idea de cómo se mueve su barco? Por lo tanto, es
crucial para un equipo de producto o servicio que está trabajando en un
nuevo producto/servicio o mejorando uno para garantizar que la
comunicación abierta y la visibilidad adecuada sean la norma en su
organización.
Aplicación de los
El principio de colaboración y promoción de la visibilidad tiene múltiples
facetas de aprendizaje. El más importante de todos ellos es la visibilidad del
trabajo en toda la organización y la visibilidad del progreso del trabajo para
los clientes y los responsables de la toma de decisiones. Plagar la toma de
decisiones es quizás el pecado más grande que uno puede cometer en un
entorno corporativo.
En el mundo del trabajo remoto, el énfasis está en la colaboración para
lograr entregas exitosas. En primer lugar, esto no se puede lograr si las
organizaciones optan por silos. El modelo DevOps también es un silo en cierto
sentido, pero es un silo construido alrededor de un producto/servicio que
brinda valor a un cliente y así es como debemos avanzar. Mantener al cliente
como foco e integrar los equipos en torno al cliente.
La comunicación es otro aspecto clave, que según algunos estudios
representa del 65 al 75 por ciento del tiempo total del proyecto. Por lo tanto, es
imperativo que lo hagamos bien. Identifique los tipos correctos de
comunicación y comuníquese periódicamente con las personas adecuadas.
Busque retroalimentación y utilícela sabiamente.
Digo que lo use sabiamente porque no todos los comentarios son útiles.
Necesitamos abrazar los buenos y deshacernos del resto. Una interpretación
errónea común es que la colaboración es igual a consenso. Esto no es verdad.
182
PRINCIPIOS RECTORES
El consenso es una forma de liderar, pero no es la única. Hay veces que no
funciona. Un buen líder debe poder elegir un tipo de liderazgo sobre el otro.
Por ejemplo, elegimos un ejercicio para identificar la tecnología adecuada para
un producto que vamos a desarrollar. Tal decisión debe dejarse en manos de
los expertos, como los arquitectos de soluciones. Llevar a cabo una actividad
de consenso con todo el equipo es una tontería.
Nota Hay diferentes tipos de liderazgo. Los

populares son: liderazgo con el ejemplo, donde los
líderes marcan el paso; liderazgo autoritario, donde el
líder toma decisiones según su propio criterio; liderazgo
por coerción, donde el líder mueve al equipo hacia su
decisión; y liderazgo por consenso o democracia, donde
las opiniones del equipo tienen peso en la toma de
decisiones. ningún liderazgo es bueno o malo.
Necesitamos usar diferentes tipos de liderazgo en varios
escenarios. un buen líder sabrá cuándo manejar cada
uno de estos estilos.
Piense y trabaje holísticamente

Ningún producto o servicio está solo para ofrecer valor. Necesita estar
conectado a otros servicios para cumplir con todos los objetivos. Tome
cualquier ejemplo que se le ocurra , TI o no. Cada vez más nos damos cuenta
de que todas las cosas están conectadas. Si alguno de los países líderes se
hunde, las economías y los mercados de todo el mundo siguen la caída.
Durante los próximos meses y años, habrá todo tipo de problemas con la
oferta, la demanda y otros intercambios. Un producto cotidiano como el
sistema operativo Windows no puede funcionar solo. Prueba a desconectarlo
de Internet y de las aplicaciones predeterminadas. ¿Le parece útil sin Internet
183
PRINCIPIOS RECTORES
y otras aplicaciones como Office, Chrome y otras? La idea es pensar en un
mundo conectado y pensar de manera holística en lugar de aisladamente. El
desarrollo de productos de Windows no piensa con los ojos vendados cuando
se realizan cambios en el producto. Piensan en el impacto que tendrá en el
hardware en el que se asienta y en la perfecta integración con el software
fabricado por otras organizaciones, por decir lo menos. Del mismo modo, cada
vez que planifique y ejecute actividades relacionadas con productos o
servicios, no piense en pequeño, sino que abarque su alcance de un extremo al
otro del espectro.
¿Tus proveedores saben qué cambios estás trayendo a los servicios?
¿Están sus clientes alineados con los cambios de diseño propuestos del
producto que utilizan e integran con su conjunto de herramientas
empresariales? Esta es la dirección que debemos emprender y aceptar. Puede
que tengamos todas las cartas y, sin embargo, tengamos que tomar decisiones
y liderar un enfoque consultivo.
Aplicación de los
Una base de datos como una base de datos de gestión de configuración
(CMDB) identifica y documenta las integraciones y dependencias. Se debe
dibujar una imagen de este tipo para cada producto/servicio para que podamos
definir la hoja de ruta con el conjunto correcto de partes interesadas.
Una forma de definir productos y servicios es a través de la cantidad de
integraciones con las que vienen construidos. Cuantas más integraciones, más
complejidad, porque realizar cualquier cambio requeriría visibilidad para todas
las partes interesadas y también concurrencia. Incluso si la tecnología y la
codificación involucradas pudieran ser simples y directas, la complejidad
crece con las integraciones. Esta es una de las principales razones por las que
los productos de middleware se consideran los más complejos, y cada cambio
requiere mucha planificación y visión de futuro.
184
PRINCIPIOS RECTORES
Para gestionar integraciones complejas o cualquier número de
integraciones, la colaboración y la visibilidad (principio rector n.º 4) son la
clave. Sin los cuales, la gestión de productos o servicios sería casi una
pesadilla. Junto con esto, debe tener un conjunto acordado de principios,
procesos y prácticas para que todos en la cadena de valor hablen el mismo
idioma y apunten hacia el verdadero norte.
Cuanta más complejidad, más manos se necesitan para gestionarlo, y
esto podría terminar potencialmente con errores inducidos por humanos.
Por muy brillantes que seamos, nos equivocamos, y la panacea es la
automatización. Cualquier trabajo que sea repetitivo y no requiera el
conocimiento humano se puede automatizar fácilmente. Hay más sobre este
tema en el principio rector #7.
Manténgalo simple y práctico

El minimalismo es un tema que se ha acelerado desde la Segunda Guerra
Mundial. El concepto es hacer el conjunto mínimo de cosas necesarias. En
todas las áreas de la vida, como las artes, el cine, la arquitectura e incluso en
la tecnología, se ha convertido en la nueva norma. Sigue el principio de hacer
el mínimo número de cosas para lograr el objetivo siempre que esté dentro de
los límites establecidos y sea práctico.
Mantener las cosas bajo control para lograr los objetivos de una manera
mínima no es ajeno a los marcos de TI y gestión de TI. El marco de
transformación Lean, que está fuertemente asociado con Agile, guía la
optimización de los recursos, las personas, los esfuerzos y la energía de su
organización hacia la creación de valor para el cliente.
El sexto principio rector, manténgalo simple y práctico , también
incorpora los principios de Lean, y la guía trata de mantener las cosas
minimalistas y pragmáticas.
El resultado que queremos lograr es importante. El resultado podría ser un
derivado de un producto, servicio o proceso. Si el resultado se puede lograr en
menos pasos y sigue cumpliendo con las políticas organizacionales y estatales,
entonces esto lleva a lograr este principio rector. Esto podría lograrse mediante
185
PRINCIPIOS RECTORES
la eliminación de desechos, la automatización de actividades (principio rector
n.º 7) y/o la eliminación de las burocracias.
Todos sabemos que mantener las cosas simples y prácticas es la mejor
manera de lograr resultados. Sin embargo, fallamos en nuestros esfuerzos. La
razón más común es agregar controles en cada paso del camino, la decisión de
la gerencia de microgestionar las actividades e imitar las prácticas
tradicionales.
Qué archivar, qué guardar

Esta es una decisión interesante, ¿no? Cuando hay varias actividades de
proceso, varios servicios con diferentes cruces, la identificación de las
actividades y servicios que son puro desperdicio no es visible como luces de
neón en la oscuridad. Se debe realizar un ejercicio analítico detallado,
especialmente si los servicios y procesos tienen dependencias dominantes,
para identificar las fallas. Podemos llevar a cabo una actividad similar al
análisis de impacto comercial, donde cada actividad se analiza desde todos
los ángulos posibles para identificar el impacto en el negocio, en el
proveedor de servicios y en otras partes involucradas.
Durante el diseño, es natural agregar actividades para revisar otras
actividades en un intento por obtener el resultado correcto. La cantidad de
revisiones o controles agregados constituyen la mayor parte. Este todavía no
es el problema, ya que se puede lograr (prácticamente). El problema es cuando
va más allá de la llamada de la razón, cuando las revisiones o controles de la
actividad del proceso se convierten en gastos generales. ¿Hay alguna manera
de hacer que las cosas fluyan sin problemas con validaciones que se puedan
hacer automáticamente? Sí, siempre hay caminos, y el objetivo de un diseño
eficaz de gestión de servicios es encontrar este camino.
Si un gobierno desea realizar un seguimiento de las transacciones en
efectivo para garantizar que se paguen todos los impuestos y que todas las
actividades financieras que se lleven a cabo sean legales, entonces debe
establecer una serie de "torres de control", procesos y prácticas para
186
PRINCIPIOS RECTORES
monitorear. ¿Qué pasa si reducen la moneda en el sistema y ordenan los pagos
en línea como norma, incluso por montos triviales? Esto cambiaría la cultura
de un sistema, donde las personas comenzarían automáticamente a realizar
transacciones en línea, brindando al gobierno una gran cantidad de datos para
rastrear actividades ilegales a través de la tecnología.
Nota BIa es una metodología de análisis en ITIL V3

que ayuda a identificar los servicios de TI críticos para la
organización del cliente. Esta herramienta ayuda a
detallar todos los impactos posibles cuando los servicios
fallan.
por ejemplo, soy autor y trabajo a tiempo completo
escribiendo libros, artículos y blogs. Si tuviera que perder
el servicio de Internet, yo:
1. no cumplir mis objetivos de escritura
2. no ganar dinero escribiendo, lo cual es una pérdida
financiera
3. no cumplo con mis obligaciones legales, ya que fallo
en mi sLas
4. Perder la base de lectores, lo que me pone en una
desventaja competitiva frente a mis compañeros.
En este ejemplo, he desglosado los impactos de perder
un servicio de TI crítico. Los primeros tres elementos de
la lista son en blanco y negro, y a menudo se los
denomina impactos duros. El último de la lista, perdiendo
base de lectores, es un impacto suave, ya que es mi
percepción del impacto y no se puede cuantificar como lo
hice con los demás. Para resumir, BIa se ocupa de los
187
PRINCIPIOS RECTORES
impactos duros y suaves del cliente si potencialmente
pierde los servicios de TI.
Facilitadores de la simplicidad y el
pragmatismo
Siguiendo con el mismo ejemplo, si el gobierno quiere un cumplimiento del
100 por ciento, entonces debe asegurarse de que el sistema esté habilitado y
libre de conflictos. Las transferencias bancarias en línea deben ser gratuitas
incluso para cantidades pequeñas. Los residentes deben estar habilitados con
Internet gratuito para realizar actividades bancarias. Si estos están en su
lugar, las personas se sentirán habilitadas para seguir las reglas vigentes y es
una situación en la que todos ganan. Consideremos lo contrario. Si los
bancos cobran un cierto porcentaje minúsculo en cada transacción, ¿por qué
alguien querría transferir en línea si solo pudiera hacer una transacción en
efectivo? ¿A quién le gustaría perder dinero solo para mantener informado al
gobierno de su actividad financiera? Sin Internet gratis para actividades
bancarias, los residentes tendrán una salida para no cumplir.
El diseño que se implemente debe considerar las entradas, los actores, los
factores desencadenantes y los resultados de manera integral y encontrar una
solución que esté libre de conflictos. No desea introducir conflictos, que es
una forma segura de garantizar el fracaso.
Tomando un ejemplo de gestión de servicios de TI esta vez, la gestión de
cambios es un ejemplo clásico de gobernanza jugando a la pelota con las
operaciones. Existen procesos de aprobación para garantizar que los cambios
puedan entrar en el sistema. Si se le asigna un diseño para acelerar los
cambios, propondrá un proceso de gestión de cambios estándar mediante el
cual los cambios se aprueban previamente y se pueden llevar a cabo durante
los términos y condiciones acordados. Tener solo un proceso de gestión de
cambios estándar no es suficiente; hay demasiadas lagunas y conflictos.
188
PRINCIPIOS RECTORES
¿Cómo se asegura de que sea compatible? Claro, una auditoría es una forma,
pero es demasiado reactiva y la tasa de aciertos es demasiado pequeña. ¿Qué
tal integrar el proceso de gestión de cambios con algo de automatización,
como proporcionar acceso de escritura/modificación a los servidores solo
cuando se registra un cambio con el elemento de configuración del servidor
asignado, junto con la ventana de cambios? Solo durante la ventana de cambio
el servidor permite cambiar su configuración. Esto es solo la punta de un
iceberg; Se puede concebir y lograr mucho más sobre la base de esta idea para
garantizar que no se ejecuten cambios no autorizados.
Aplicación de los
El estilo de vida minimalista es popular por una razón. Le da a la gente menos
cosas de qué preocuparse y aumenta el cociente de felicidad. ¿Cómo? Elimina
las complejidades de la vida que, de otro modo, requerirían un esfuerzo
considerable para mantener. Aplique el mismo principio a la gestión de
servicios también. Mantenga las cosas simples y ejecute pruebas de conceptos
para asegurarse de que sea práctico. La forma más fácil de lograrlo es
haciendo un análisis de impacto en el negocio (como dije, y no el tradicional).
Para cada actividad, averigüe cómo está agregando valor y si lo está acercando
al resultado o no. Si te aleja de la meta o te detiene, entonces es un desperdicio
que puedes permitirte perder.
Los días de la burocracia han terminado. Las aprobaciones y la
fiscalización deben encontrar alternativas que impliquen automatización y
simplificación. Recuerda que siempre hay una forma mejor y más sencilla de
lograr las cosas; solo necesitas pensar conscientemente en encontrarlo.
Optimizar y Automatizar
El principio rector final se trata de ajustar y poner en marcha el sistema de
gestión de servicios para entregar con toda su fuerza: optimizar y automatizar
. Cuando se aplica este principio, el producto, servicio o procesos ya están en
189
PRINCIPIOS RECTORES
su lugar. Se trata de hacerlo más eficaz y eficiente, y no de la funcionalidad
en sí. La optimización se ocupa de la efectividad de eliminar los desechos del
sistema e introducir actividades o modificar las existentes para mejorar el
resultado.
La automatización, por otro lado, se ocupa de las eficiencias que se
obtienen mediante el uso de la tecnología. La automatización elimina la
intervención humana y garantiza que las actividades que se le encomiendan se
completen con éxito a la perfección. ¿Significa que los humanos no están
involucrados en la automatización? Absolutamente no. Durante la ejecución,
sí, las máquinas toman el relevo. Sin embargo, el diseño y la construcción de
la automatización lo realizan personas que identifican las actividades, definen
las entradas, diseñan los procesos de trabajo y ponen controles y equilibrios
para garantizar que se pueda confiar en la automatización. Lo que logramos a
través de la automatización es velocidad (ganancia de eficiencia) y negación
de errores humanos. Si bien los humanos son propensos a cometer errores, las
máquinas funcionan según lo programado: usted programa una vez y puede
ejecutarlo un millón de veces y obtener el mismo resultado cada vez. Sin
embargo, existe una limitación en el tipo de actividades que se pueden
automatizar. Las máquinas solo pueden realizar actividades que son de
naturaleza repetitiva, en lo que respecta a la naturaleza de las entradas, los
procesos de trabajo y las salidas. Otras actividades que requieren el
conocimiento humano no pueden automatizarse, al menos por ahora. Hay
motores de inteligencia artificial creados por organizaciones que intentan
emular cerebros humanos, aunque no es concluyente que puedan
reemplazarlos por completo.
En estos días todas las industrias emplean la automatización. Es necesario
por muchos recursos humanos que tengamos, porque ciertas actividades como
la monitorización de la infraestructura o la autocuración las hacen mejor las
máquinas.
190
PRINCIPIOS RECTORES
que nosotros; somos demasiado lentos y es posible que nos falte el enfoque para
vigilar las cosas cada segundo.
¿Por qué el principio combina optimización y automatización? ¡Parecen ser
actividades distintas, se podría decir! No precisamente. Para que el ciclo de
optimización se complete, debe terminar con la automatización. En otras
palabras, primero debemos optimizar y luego automatizar, como se indica en la
Figura 6-4 .
Figura 6-4. Optimización y automatización
Prácticas de optimización
Cualquier proceso de trabajo que se nos ocurra puede optimizarse. Piense en los
procesos y flujos de trabajo diarios con los que tratamos. Incluso después de
optimizarlos, tal vez aún pueda encontrar más oportunidades para optimizar.
Ejemplo: cuando vamos de compras, normalmente tomamos un carrito de compras
y caminamos por los pasillos recogiendo las cosas que queremos. Al final,
hacemos fila en el escritorio del cajero donde el cajero escanea cada artículo, los
empaqueta y luego pagamos. Volvemos a poner las bolsas en el carrito y lo
llevamos a nuestros autos y luego a nuestras casas. El primer nivel de
optimización puede ser lo que la mayoría de las tiendas de comestibles del Reino
Unido denominan compras inteligentes. Se entrega un escáner a los compradores
cuando comenzamos a caminar por los pasillos. A medida que recogemos
productos, los escaneamos y embolsamos los productos directamente. Al final, hay
191
un quiosco donde escaneamos el código del escáner y hacemos el pago nosotros
mismos. Como los productos ya vienen embolsados, llevamos los carritos a
nuestros carros y luego a nuestras casas. El siguiente nivel de optimización podría
ser hacer compras en línea y pagarlas . Seleccionamos algo que se llama click and
collect , que nos permite llegar al supermercado en un momento determinado y se
embolsan todos los productos que hemos pagado. Imagina el tiempo ahorrado; al
menos para mí, se trata de 2 horas ahorradas por semana. Las compras en línea
junto con la entrega pueden ser el siguiente nivel optimizado, donde también se
puede ahorrar el tiempo de conducción a la tienda de comestibles y de regreso. Mi
punto es que cada proceso, flujo de trabajo y servicio se puede optimizar tantas
veces como sea necesario, si hay suficiente capital, entusiasmo e ideas.
Llevar a cabo la optimización sigue de alguna manera el proceso de mejora
continua del servicio (CSI) que existía durante los días de ITIL V3:
• Acordar el alcance de la optimización
• Analizar las áreas que están en el alcance.
• Medir la línea de base para futuras comparaciones
• Acordar con las partes interesadas la hoja de ruta
• Asegúrese de que todas las partes interesadas participen en el proceso y

recopile sus aportes
• Ejecutar mejoras de manera iterativa
• Realice un seguimiento de las métricas que definen el éxito de la

optimización
• Compare las métricas con la línea de base para obtener el nivel de
optimización alcanzado
Prácticas de automatización
Como es el caso de la optimización, la automatización también se puede aplicar a
la mayoría de las áreas. La única limitación podría ser la aplicación de la
192
tecnología en el área en particular. Diga si se trata de un proceso de trabajo que
implica
PRINCIPIOS RECTORES
entrevistando a otros, entonces posiblemente la automatización tendría un papel

limitado. Sin embargo, incluso allí, la automatización se puede utilizar para la
selección inicial de currículos y para realizar exámenes de evaluación para todos
los candidatos.
En el área de DevOps, usamos mucho la automatización: incluida la
integración continua, la entrega y el despliegue continuos, la
automatización/pruebas continuas, el monitoreo, la recuperación automática, la
gestión de la configuración y la gestión de la nube, entre otros.
Aplicación de los principios/aprendizajes

Reiterando los aprendizajes en este principio:
• Como se indica en la Figura 6-4 , es una buena práctica

optimizar primero y luego automatizar, para garantizar que la
automatización realizada no ejemplifique y aumente la
complejidad requerida para la automatización en procesos de
trabajo no optimizados.
• Mide todo. La única manera de decidir si una optimización
ha funcionado es a través de las métricas.
• Cuando se trata de tecnología, ciertamente habrá
dependencia del capital. La mejor manera de contrarrestarlo
es comenzar con tecnologías que ya se emplean. Una vez
que den frutos, el capital podría fluir fácilmente.
• Todas las actividades de optimización y automatización
deben llevarse a cabo en iteraciones, junto con la
retroalimentación recibida de iteraciones anteriores
(principio #3).
193
6-1. Eres un consultor de gestión de servicios contratado por una empresa

para investigar las razones de las insatisfacciones de sus clientes. Al
investigar, descubre que no se satisfacen las necesidades del cliente.
Para arreglar las cosas, ¿con cuál de estos principios empezarías?
A. Piense y trabaje holísticamente
B. Comienza donde estás
C. Manténgalo simple y práctico D. Progrese iterativamente

con retroalimentación
6-2. Usted es un consultor interno de gestión de servicios contratado por un
proyecto que se ejecuta en modo DevOps. Existe la necesidad de
aumentar el margen operativo del proyecto. Descubres que los
procesos son complejos y hay muchas prácticas burocráticas. ¿Qué
principio rector sería el más adecuado en esta circunstancia?
A. Optimizar y automatizar B. Colaborar y
promover la visibilidad
C. Manténgalo simple y práctico
D. Comienza donde estás
6-3. Ejecuta un proyecto que tiene varios flujos de trabajo. El producto es

común pero las áreas de trabajo son diferentes. Por ejemplo, un flujo de
trabajo está en
PRINCIPIOS RECTORES
mejoras, el otro en la reducción de la deuda técnica y el tercero

en el soporte. ¿Cuál de los principios rectores será más
beneficioso?
194
A. Optimizar y Automatizar
B. Manténgalo simple y práctico
C. Progresar iterativamente con comentarios D. Colaborar y

promover la visibilidad
6-4. Su cliente no tiene claro cómo debe ser el producto final. Va
vacilando a medida que pasan los días. Para no perder la
competencia, ¿qué principio rector serviría en esta situación?
A. Progreso iterativo con retroalimentación
B. Piense y trabaje holísticamente C. Manténgalo simple

y práctico
D. Comience donde está
6-5. ¿Cuál de las siguientes es la mejor definición de un principio

rector?
A. Una recomendación que guía a una organización para
configurar un sistema de gestión de servicios.
B. Una guía para crear productos y servicios.
C. Un conjunto de principios prescritos que proporcionan

dirección para crear valor.
D. Una recomendación que guía a una organización en todas las
circunstancias
195
CAPÍTULO 7
Gestión de
Prácticas de ITIL
El golpe maestro de ITIL 4 es introducir prácticas en ITIL y eliminar procesos
y funciones. El problema no era tanto que fuera complejo, sino que los
conceptos subyacentes y su superposición a menudo eran complicados; y para
los buscadores de ITIL, a menudo fue una curva de aprendizaje bastante larga.
Los procesos de ITIL representaban la serie de actividades y su flujo de
trabajo que era necesario para convertir una entrada en una salida. Las
funciones eran estructuras de equipo que proporcionaban los recursos para
llevar a cabo las actividades del proceso. Prácticas y funciones involucradas en
un arreglo matricial donde los procesos requerían diferentes funciones para
llevar a cabo las actividades del proceso. En el ITIL actual, tanto los procesos
como las funciones de ITIL se combinan para trabajar al unísono como
práctica.
Una práctica se define como un conjunto de recursos organizacionales
diseñados para realizar un trabajo o lograr un objetivo. Se basa en un
conjunto de recursos organizacionales (cuatro dimensiones de la gestión de
servicios; Capítulo 4 ) que pueden ser personas, infraestructura, software o
procesos, y todos estos recursos están alineados/diseñados para lograr un
objetivo específico. La palabra clave es un objetivo específico, y no general.
Si arma una práctica para hacer hamburguesas, no arma nada más que
hamburguesas. Si quieres un burrito, entonces necesitas una práctica
diferente.

4842-6361-7_7
GESTIÓN DE PRÁCTICAS DE ITIL
Este es un capítulo que introduce la categoría de prácticas y las prácticas

individuales que forman parte de ella. Los detalles de las prácticas que están en
el alcance se retomarán en el resto de los capítulos.
Categoría de Prácticas
Recuerde que las prácticas son una parte integral del sistema de valor del
servicio (Capítulo 5 ). Cada práctica admite múltiples actividades de la
cadena de valor e incluye recursos basados en las cuatro dimensiones de la
gestión de servicios de TI.
Las prácticas de ITIL se clasifican ampliamente en tres partes distintas:
1. Prácticas generales de gestión
2. Prácticas de gestión de servicios
3. Prácticas de gestión técnica
Las prácticas de naturaleza genérica que caen bajo el dominio de la gestión
comercial general pero que también podrían funcionar con la gestión de
servicios se clasifican en prácticas de gestión general.
Las prácticas que se utilizan principalmente en la industria de gestión de
servicios se incluyen en las prácticas de gestión de servicios.
Las prácticas tecnológicas encuentran un hogar en la gestión de servicios a
través de organizaciones orientadas a la tecnología.
Prácticas generales de gestión

Las prácticas generales de gestión, como su nombre lo indica, son de
carácter genérico. Estas prácticas son comunes en todos los marcos y
metodologías.
Capítulo 7 GESTIÓN DE PRÁCTICAS DE
ITIL
Definición ITIL de Prácticas Generales de Gestión

Se han adoptado y adaptado prácticas generales de gestión
para la gestión de servicios de los dominios generales de
gestión empresarial.
Hay catorce prácticas generales de gestión en ITIL:

1. Gestión de arquitectura
2. Mejora continua
3. Gestión de la seguridad de la información
4. Conocimiento administrativo
5. Medición e informes
6. Gestión del cambio organizacional
7. Gestión de la cartera
8. Gestión de proyectos
9. Gestión de relaciones
10. Gestión de riesgos
11. Gestión financiera de servicios
12. Gestión de la estrategia
13. Administración de suministros
14. Gestión de personal y talento
En el curso para el examen ITIL Foundation, el Continuo
Las prácticas de mejora, gestión de seguridad de la información, gestión de
relaciones y gestión de proveedores están dentro del alcance.
193
Prácticas de gestión de servicios
Las prácticas de gestión de servicios se desarrollaron en los establos de
organizaciones de gestión de servicios como IBM y HP. Los procesos de ITIL
eran una colección de las mejores prácticas de tales organizaciones. A medida
que las actividades que siguieron se convirtieron en procesos teóricos, ITIL se
convirtió en un estándar de facto para la gestión de servicios. Estos procesos
han continuado en un nuevo avatar como prácticas en ITIL 4.
Definición de prácticas de gestión de servicios de ITIL

Las prácticas de gestión de servicios se han desarrollado en las
industrias de gestión de servicios y ITSM.
Hay diecisiete prácticas de gestión de servicios en ITIL:

1. Administración de disponibilidad
2. Análisis de negocios
3. Administración de capacidad y rendimiento
4. Cambio de control
5. Administracion de incidentes
6. gestión de activos de TI
7. Monitoreo y gestión de eventos.
8. Gestión de problemas
9. Gestión de la liberación
10. Gestión del catálogo de servicios
11. Gestión de la configuración del servicio
12. Gestión de la continuidad del servicio
13. Diseño de servicio
Capítulo 7 GESTIÓN DE PRÁCTICAS DE
ITIL
14. Servicio de mesa

15. Gestión del nivel de servicio
16. Gestión de solicitudes de servicio
17. Validación y prueba del servicio
En el curso para el examen de Fundamentos de ITIL, el control de
cambios, la gestión de incidentes, la gestión de activos de TI, la supervisión y
la gestión de eventos, la gestión de problemas, la gestión de versiones, la
gestión de la configuración del servicio, la mesa de servicio, la gestión del
nivel de servicio y las prácticas de gestión de solicitudes de servicio están
dentro del alcance. .
Prácticas de Gestión Técnica

Mientras que las prácticas de gestión de servicios nacieron en las
organizaciones de ITSM, las prácticas de gestión técnica encontraron su alma
mater en las organizaciones basadas en la tecnología. Estas prácticas
proporcionan el vínculo entre las actividades técnicas y las actividades
relacionadas con el flujo de trabajo.
Definición ITIL de Prácticas de Gestión Técnica

Las prácticas de gestión técnica se han adaptado de los
dominios de gestión de tecnología para fines de gestión de
servicios al expandir o cambiar su enfoque de soluciones
tecnológicas a servicios de TI.
Existen tres prácticas de gestión técnica:

1. Gestión de implementación
2. Administración de infraestructura y plataformas
3. Desarrollo y gestión de software
La gestión de la implementación está dentro del alcance de este libro.
195
7-1. ¿Cuál de las siguientes prácticas no figura en las prácticas
de gestión técnica?
A. Gestión de implementación
B. Gestión de versiones y despliegues
C. Administración de infraestructura y plataformas
D. Desarrollo y gestión de software
7-2. ¿Cuáles de las siguientes afirmaciones son verdaderas?
A. Las prácticas de gestión de servicios se generaron en
organizaciones de gestión de servicios y se adoptaron y
adaptaron a ITIL.
B. Las prácticas de gestión de servicios fueron las mejores
prácticas de la industria hotelera y de servicios.
C. Las prácticas de gestión de servicios fueron desarrolladas por
autores de ITIL y fueron adaptadas y adoptadas por
organizaciones de gestión de servicios.
D. Las prácticas de gestión de servicios eran estándares de facto
en
la mayoría de las organizaciones antes de que fueran documentadas como
ITIL.
7-3. ¿Cuál de las siguientes prácticas no figura en las prácticas
generales de gestión?
A. Gestión de la cartera
B. Gestión de programas
C. Gestión de proyectos
D. Gestión de riesgos
DÍA 4
El día 4 comienza con el estudio de las prácticas de ITIL, que ayudan a los
proveedores de servicios a gestionar las partes interesadas externas: procesos
de gestión de proveedores y servicios. Luego pasamos a las prácticas
relacionadas con la habilitación del soporte: configuración de servicios y
prácticas de administración de activos de TI. El día termina con prácticas de
mejora continua (un elemento del sistema de valor del servicio).
CAPÍTULO 8
Prácticas para
Gestionar a los
Stakeholders
ITIL reconoce que los servicios no se pueden ofrecer de forma aislada; requieren
mucho apoyo continuo para completar la entrega y el apoyo de partes externas.
Estas partes externas podrían ser clientes, usuarios, patrocinadores, proveedores u
otras agencias que podrían tener una participación en la legislación y otras partes
de cumplimiento.
La gestión de las actividades laborales dentro de una organización elimina la
dependencia de terceros, lo que es mucho menos complejo que las tareas
relacionadas con el manejo de las partes interesadas. Las prácticas que manejan a
los stakeholders serán discutidas en este capítulo. Las prácticas en las que vamos a
profundizar son:
1. Gestión de relaciones
2. Administración de suministros
3. Gestión del nivel de servicio
Consejo de examen Puede esperar que aparezcan entre

dos y tres preguntas de este capítulo.
Capítulo 8
6361-7_8
PRÁCTICAS PARA LA GESTIÓN DE PARTES INTERESADAS
Gestión de relaciones
No todas las partes interesadas están a la altura de la escala de importancia.
Algunos podrían ser como un salvavidas para un proveedor de servicios, mientras
que otros podrían variar en una escala de importancia. Entonces, la lógica dicta
que no todas las partes interesadas serán tratadas por igual. Cada una de las partes
interesadas participa en un nivel separado para obtener el máximo valor en cada
etapa identificada.
A nivel corporativo, nos relacionamos con las partes interesadas a nivel
estratégico, táctico u operativo. Tomemos un ejemplo de una empresa de TI que
utiliza MS Teams para la colaboración. El éxito de la empresa en la entrega a sus
clientes depende de qué tan bien sus equipos puedan colaborar con los otros
equipos involucrados. Entonces, MS Teams se vuelve aún más importante;
Microsoft será tratado como un socio estratégico y firmará acuerdos para
garantizar que la empresa obtenga las últimas actualizaciones y hojas de ruta de
productos visibles mucho antes que otros clientes normales. La relación estratégica
contempla una relación a largo plazo. La misma empresa de TI se asocia con una
empresa de taxis para trasladar a sus empleados hacia y desde sus hogares. Existe
un acuerdo de que la compañía de taxis retiene los precios durante todo el año
calendario y también pone a disposición cualquier número de vehículos dentro de
la hora. Esta es una relación táctica que ayuda a la empresa a mirar hacia el
mediano plazo. Luego están las transacciones operativas en las que la empresa
adquiere o realiza transacciones caso por caso. Por ejemplo, podrían hacer un
pedido de mil cartuchos para sus impresoras. No existe carga de relación entre el
proveedor y la empresa. Está basado en transacciones. No es necesario que los
gerentes de relaciones se reúnan con los funcionarios de la empresa de vez en
cuando para explorar opciones que ayuden a impulsar sus negocios.
La gestión de relaciones se ocupa de los niveles estratégicos y tácticos de
asociación y construcción de relaciones con las partes interesadas.
200
Capítulo 8
Definición ITIL de práctica de gestión de relaciones
El propósito de la práctica de gestión de relaciones es establecer
y nutrir los vínculos entre la organización y sus partes
interesadas a nivel estratégico y táctico.
Actividades de gestión de relaciones

Además, la práctica existe para garantizar que las relaciones entre las partes
interesadas florezcan y sean fructíferas para todas las partes involucradas. La
gestión de relaciones sigue un ciclo de vida (como se indica en la Figura 8-1 ) a
través de las siguientes etapas:
1. Identificación
2. Análisis
3. Supervisión
4. Mejora continua
201
Capítulo 8
Figura 8-1. Etapas de la gestión de relaciones.
Analicemos qué puede lograr la práctica de gestión de relaciones y por qué

debe ser parte del marco de ITIL. La creación de valor es el verdadero norte, y ya
hemos establecido que el valor no se crea solo, sino que se co-crea entre una
empresa conjunta entre el proveedor de servicios y el cliente; esto se ilustra
matemáticamente en la Figura 8-2 . Dado que es un ejercicio conjunto, existe ese
énfasis adicional para obtener la relación aumentando la armonía y reduciendo los
conflictos. Solo cuando todos los conjuntos de grupos cantan la misma melodía,
comienza la música.
202
Capítulo 8 Prácticas para la gestión de grupos
de interés
Figura 8-2. Fórmula de cocreación de valor
La práctica de gestión de relaciones existe principalmente para estos

propósitos:
• Las diversas partes interesadas de los productos y servicios

tienen su propio conjunto de requisitos, y es esencial
comprenderlo total y completamente. Además, algunos
requisitos serán más importantes que otros, por lo que también
es importante comprender la priorización de los requisitos.
• La priorización y los requisitos per se no están escritos en

piedra y es muy probable que cambien regularmente. Por lo
tanto, es esencial que se lleven a cabo conversaciones regulares
203
de interés
y garantizar que las relaciones sean transparentes para abrirse
por completo.
• A nivel estratégico y táctico, la co-creación de valor debe ser el

objetivo. Los conflictos, si los hay, deben resolverse; cuanto
antes, mejor.
• Gestionar la satisfacción del cliente; tomar las medidas

necesarias para mantener contentos a los clientes. También
manejar las quejas y escalaciones de los clientes.
Nota la práctica de gestión de relaciones se introdujo

por primera vez en itil en la versión de itil 2011 como el
proceso de relaciones comerciales. se consideró como un
hermano mayor del proceso de gestión del nivel de servicio,
que veremos más adelante en este capítulo.
Compromiso en la cadena de valor del

servicio
Hemos establecido que la cadena de valor del servicio es el corazón del sistema
de valor del servicio, y las actividades dentro de la cadena de valor del servicio
determinan el valor que se desarrolla y entrega. Con referencia a la práctica de
gestión de relaciones, examinemos cómo la práctica se relaciona con varias
actividades dentro de la cadena de valor del servicio en la Tabla 8-1 .
Tabla 8-1. Gestión de relaciones en SVC

Actividad de
Intervención Detalles
CVS
plan alto los requisitos se pasan al plan para el
ejercicio de planificación. mantiene
un dedo en el pulso de las tendencias
204
de interés
del mercado, que determinan la
dirección estratégica emprendida,
incluidas las decisiones de cartera.
diseño y alto Los comentarios de los clientes se
transición transmiten al diseño y la transición, lo
que mejora el servicio y reduce los
posibles problemas.
obtener/construir Medio esta actividad llega a escuchar los
requerimientos de boca del caballo, lo
que reduce posibles problemas
provenientes de desalineación de la
actividad del plan.
comprometer alto entablar acuerdos con terceros, y la
gestión de relaciones existe para
construir el vínculo con las partes
interesadas.
entregar y Medio La retroalimentación sobre los
apoyar servicios se pasa a la actividad de
entrega y soporte.
mejorar alto los servicios se mejoran gracias a las
sólidas relaciones con los clientes y
otras partes interesadas y la
retroalimentación abierta recibida.
Administración de suministros
La práctica de gestión de proveedores es una de las prácticas maduras en el marco
de ITIL. Antes de entrar en los detalles de la práctica, se debe entender la palabra
proveedor .
Un cliente obtiene servicios de un proveedor de servicios. Es probable que
el proveedor de servicios tenga otros proveedores de servicios en forma de
bienes y servicios. Estos proveedores de servicios desde la perspectiva de
205
de interés
un cliente se llaman proveedores. En resumen, el proveedor de servicios de un
proveedor de servicios se denomina proveedor. Fuera de ITIL, los proveedores
también se denominan vendedores.
Por ejemplo, un proveedor de servicios que brinda servicios de correo
electrónico a un cliente requiere servidores y centros de datos. Las empresas que
proporcionan servidores y centros de datos se denominan proveedores.
Técnicamente, pueden ser proveedores de servicios para el proveedor de servicios
de correo electrónico. Sin embargo, desde el punto de vista del cliente, se les
conoce como proveedores.
Definición ITIL de práctica de gestión de proveedores

El propósito de la práctica de gestión de proveedores es
garantizar que los proveedores de la organización y su
desempeño se gestionen adecuadamente para respaldar la
provisión fluida de productos y servicios de calidad.
Actividades de gestión de proveedores

Esta es una práctica amplia y gestiona varias actividades. Los principales son los
siguientes.
Estrategia y planificación de proveedores

Se espera que la práctica dibuje una estrategia para identificar y planificar las
actividades que gestionarán los proveedores. Esta estrategia se extrae de los
requisitos del cliente y de las capacidades del proveedor del servicio.
El proveedor de servicios evaluará qué partes del servicio se pueden ofrecer
inherentemente y cuáles se obtendrán de un proveedor. En base al análisis y toma
de decisiones, se eligen los proveedores y se planifica su vinculación.
Evaluación y Selección de Proveedores

El papel de un proveedor está en juego. Muchos posibles proveedores ofrecen sus
bienes y servicios a la práctica de gestión de proveedores, que tiene la tarea de
206
de interés
evaluar y seleccionar proveedores. La evaluación y selección normalmente se
realiza a través de un proceso de solicitud de propuestas donde los proveedores
son evaluados técnicamente primero en función de su respuesta a un cuestionario
preestablecido. Luego, entre las preseleccionadas, entran en juego los factores
comerciales a la hora de seleccionar al proveedor.
Negociaciones de contratos
La segunda ronda de selecciones que involucran factores comerciales se enmarca
en la actividad de negociación de contratos. Si bien se seleccionan proveedores
capaces, los mejores entre iguales se determinan en función de factores
comerciales.
Las negociaciones de contratos ocurren en múltiples niveles, y es posible que
no siempre ocurran al comienzo de una relación. Los contratos se revisan
periódicamente y se llevan a cabo negociaciones de tarifas según las circunstancias
del mercado.
La redacción de nuevos contratos, la renovación de contratos existentes y la
terminación de contratos son el resultado de esta actividad.
Categorización de proveedores
En la práctica de gestión de relaciones, analizamos la práctica de trabajar con
partes interesadas estratégicas y tácticas. La práctica de gestión de proveedores
es responsable de categorizar a los proveedores en tres categorías generalmente:
estratégicos, tácticos y operativos. Los proveedores más importantes
(estratégicos y tácticos) serán gestionados adicionalmente por la práctica de
gestión de relaciones.
Gestión del rendimiento

Los proveedores no están exentos de medir su eficacia y eficiencia. El proveedor
de servicios lleva a cabo comprobaciones periódicas del rendimiento para
asegurarse de que el proveedor cumple con su parte del trato. Si el proveedor se
queda corto, esto puede ser motivo de rescisión de su contrato.
207
de interés
Antes de gestionar el rendimiento y durante las negociaciones del contrato, se
acuerdan los KPI y los SLA, y también se definen los términos de medición.
Estrategias de abastecimiento
Una organización puede elegir una estrategia de proveedor en función de diversas
circunstancias entre los aspectos de seguridad, legales y legislativos. La decisión
de elegir uno u otro es de naturaleza puramente estratégica, y cada empresa puede
optar por ir en una dirección diferente.
Por ejemplo, si una aplicación necesita ser desarrollada y respaldada, la
empresa X podría optar por subcontratar todo el desarrollo y soporte del producto
a otro proveedor de servicios, incluidas todas las piezas de integración. La
empresa Y podría optar por entregar el desarrollo de la aplicación a un proveedor
de servicios y el soporte a otro. La empresa Z podría optar por dividir la aplicación
en varias funciones y entregar el desarrollo y el soporte de cada una de las
funciones a un proveedor de servicios diferente. El pensamiento detrás de cada una
de las decisiones podría provenir de:
1. Queremos que un proveedor de servicios maneje todo, lo que

conduce a un único punto de administración junto con tarifas
óptimas que surgen de la colaboración que se puede lograr.
2. El desarrollo es un pedazo de pastel diferente del soporte. La

experiencia requerida también es diferente. Necesitamos
proveedores de servicios que sean líderes en su industria, por lo
que dividir el desarrollo y el soporte es la mejor opción.
3. Es demasiado arriesgado poner todos los huevos en una sola

canasta. No queremos que ninguno de los proveedores de
servicios sienta que pueden pedirnos un rescate administrando
todos nuestros servicios. Entonces dividimos la aplicación en
varias partes y se la entregamos a diferentes organizaciones.
Entendemos que los costos podrían escalar, pero no somos una
208
de interés
organización sensible a los precios para el desarrollo y la
administración de esta aplicación.
Veamos las diferentes estrategias de abastecimiento que se emplean.
internalización
Aunque la externalización se está extinguiendo rápidamente, hay empresas
que quieren hacer todo por su cuenta. Los productos y servicios se entregan
dentro de la misma organización.
Subcontratación
La entrega de productos y servicios se entrega a diferentes organizaciones. Los
principios son los mismos que los de la externalización. En lugar de que una
organización interna proporcione servicios, se entrega a una externa. Esto ha sido
muy popular en las últimas dos décadas y media.
Abastecimiento único
El abastecimiento único es como la subcontratación, pero todos los productos y
servicios se entregan a un solo proveedor de servicios. En algunos casos, también
podría ser un integrador de servicios externo que administre múltiples proveedores
de servicios en nombre del cliente. Tener un solo proveedor tiene sus ventajas en
términos de facilidad de colaboración, intercambio de conocimientos y
optimización de costos.
Multiabastecimiento
La entrega de productos y servicios no se entrega a una sino a múltiples
organizaciones. La división de servicios podría estar en las líneas de capacidad o
sentido geográfico. Por ejemplo, las organizaciones que son supremas en SAP
podrían obtener la parte de SAP de la aplicación, una organización
comercialmente razonable podría obtener las partes genéricas de la aplicación y el
209
de interés
soporte de infraestructura podría ir a una empresa con experiencia relevante. De
esta manera, el cliente obtiene lo mejor de todos los mundos.
Sin embargo, administrar múltiples proveedores de servicios será un desafío. Esto
se mitiga incorporando un integrador de servicios en la imagen.

servicio
Tabla 8-2. Gestión de proveedores en SVC
Actividad de
CVS
plan alto la estrategia de abastecimiento proviene
de la práctica de gestión de proveedores
según el plan.
diseño y alto los requisitos, términos funcionales y
transición condiciones serán definidos por la
práctica de gestión de proveedores bajo
esta actividad.
obtener/construiralto la prestación de servicios de los
proveedores se consume directa e
indirectamente en la actividad de
obtención/construcción.
comprometer alto La práctica de gestión de proveedores
gestiona a los proveedores y todas sus
actividades constituyentes en la
actividad de contratación.
entregar y alto la gestión del desempeño se lleva a
apoyar cabo bajo esta actividad.
mejorar Medio junto con los proveedores, en esta

actividad se identifican, rastrean y
cierran oportunidades de mejora.
Gestión del nivel de servicio
210
de interés
Hasta ahora, la historia desde la perspectiva de las partes interesadas es que la
práctica de gestión de relaciones construye relaciones, interactúa con los
clientes a nivel estratégico y táctico y trata con todas las demás partes
interesadas. La práctica de gestión de proveedores se centra en todo lo
relacionado con los proveedores. La participación operativa de las partes
interesadas aún no se ha identificado como una práctica. La práctica de gestión
del nivel de servicio cumple esta función.
Definición ITIL de Gestión del Nivel de Servicio

El propósito de la práctica de gestión del nivel de servicio es
establecer objetivos claros y basados en el negocio para los
niveles de servicio y garantizar que la prestación de los servicios
se evalúe, controle y gestione adecuadamente con respecto a
estos objetivos.
La práctica de gestión del nivel de servicio existe para garantizar que los
niveles de servicio se acuerden entre las organizaciones del cliente y del proveedor
del servicio, y que se realice un seguimiento. Todo el objetivo es proporcionar los
servicios al nivel esperado de desempeño y eficiencia. Tratemos de entender qué
niveles de servicio son los primeros.
Definición de nivel de servicio de ITIL

Una o más métricas que definen la calidad del servicio esperada
o lograda.
Es una medida de un servicio acordado y definido que se considera mínimo

para que un servicio sea apto para su propósito y para su uso. Por ejemplo, cuando
ordena una pizza de Domino's, la compañía de pizza anuncia que la entregará
dentro de los 30 minutos (en algunas zonas geográficas) o que la pizza es gratis.
Los 30 minutos son una métrica o un nivel de servicio que se define y rastrea para
garantizar que se cumpla. Si no se cumple, la consecuencia en el mundo de TI
podría ser seguida por sanciones, lo que equivale a una pizza gratis si la entrega
demora más de 30 minutos.
211
de interés
Actividades principales de la gestión del

nivel de servicio
La gestión del nivel de servicio lleva a cabo las siguientes actividades en lugar de
los servicios prestados al cliente:
1. Acordar niveles de servicio con los clientes que sean

vinculantes. Ejemplo: niveles de disponibilidad, niveles de
capacidad, plazos de resolución de incidencias, etc.
2. La práctica asegura que la organización proveedora de

servicios cumpla con los niveles de servicio acordados. La
práctica tiene una supervisión de los diversos niveles de
servicio y, aunque puede que no gestione directamente los
equipos de prestación de servicios, la práctica de gestión del
nivel de servicio es responsable de cumplir con los niveles de
servicio. Para hacer esto, la práctica monitorea los niveles de
servicio, recolectando, analizando y reportando los niveles de
servicio al cliente.
3. Se realizan revisiones periódicas del servicio, especialmente si

los niveles de servicio son inferiores a los adecuados, para
identificar la causa raíz y garantizar que se implementen
acciones correctivas. Si es necesario realizar mejoras, se
incorpora a la actividad Mejorar en la cadena de valor del
servicio.
4. Como seguimiento de la actividad de revisión del servicio, la

práctica registra todas las deficiencias y problemas al cliente y
otras partes interesadas, incluida la administración interna.
Recuerde que todos los niveles de servicio acordados son para un servicio y
no para componentes individuales de un servicio. Por ejemplo, se mide la
disponibilidad del servicio de un servicio de extremo a extremo. Los servidores
individuales que componen un servicio, aunque se miden sus disponibilidades
212
de interés
individuales, no entran en el ámbito de la práctica de gestión del nivel de
servicio siempre que el servicio no se vea afectado.
Acuerdos de Nivel de Servicio

Definición de acuerdo de nivel de servicio de ITIL
Un acuerdo documentado entre un proveedor de servicios y un
cliente que identifica tanto los servicios requeridos como el nivel
de servicio esperado.
Los niveles de servicio que se acuerdan con los clientes se agrupan en un

documento llamado acuerdo de nivel de servicio (SLA). Este documento
generalmente se adjunta al documento de contrato entre el cliente y el proveedor
de servicios. Una buena práctica es mapear los SLA contra los parámetros de los
servicios que impactan directa o indirectamente en los procesos comerciales.
Nota Los requisitos de nivel de servicio (slrs) son el

conjunto de expectativas que el cliente pone sobre la mesa
con respecto a sus servicios (o aspectos de los mismos). Los
slrs están alineados con los objetivos comerciales y forman la
base para negociar y acordar los niveles de servicio entre el
cliente y el proveedor de servicios.
para mencionar algunos ejemplos de slrs, el cliente puede
solicitar que los incidentes críticos se resuelvan en una
hora, puede solicitar que se implementen cambios en los
sistemas en un día y puede solicitar una disponibilidad del
servicio de Internet del 100 por ciento. no todas las slrs son
factibles, incluso por parte de los principales proveedores de
servicios. de hecho, el costo de los servicios tiende a
aumentar exponencialmente a medida que los requisitos de
213
de interés
nivel de servicio alcanzan un alto porcentaje. entonces, el
arte de la negociación es encontrar el equilibrio entre los
niveles de servicio y el costo de brindar los servicios.
luego hay algunos slrs que son imposibles de igualar, incluso
por parte de los mejores proveedores de servicios, tal vez
implementando cambios en el sistema en un día. no todos los
cambios pueden ser factibles dado el cronograma, ya que los
cambios deben desarrollarse, probarse y luego
implementarse. se necesita mucha planificación, coordinación,
medidas de riesgo y contramedidas. si el proveedor de
servicios firma una slr declarando que todos los cambios se
implementarán en un día, se estaría preparando para un gran
fracaso.
Estos son algunos de los detalles que se incluyen en el documento SLA:

• Un catálogo de servicios es una colección de todos los servicios que
ofrece el proveedor de servicios; es como el menú para llevar de un
restaurante. Entonces, cuando se define un SLA, debe estar
referenciado al catálogo de servicios y no ser arbitrario.
• Hay varias maneras de definir y acordar los niveles de servicio. Un

servicio puede tener múltiples facetas y cada una de ellas podría ser un
nivel de servicio para ser definido y rastreado. Lograr todas las facetas
excepto una puede parecer verde en el exterior, pero el cliente podría
estar sufriendo debido a un área en particular donde los niveles de
servicio habían caído por debajo de las expectativas. Por lo tanto, es
importante definir los niveles de servicio en conjunto con el contexto
del negocio. Por ejemplo, si un proveedor de servicios de Internet
proporciona más del 99 por ciento de disponibilidad de los servicios en
un período de un mes, aún puede no ser suficiente si la disponibilidad
214
de interés
de Internet no es del 100 por ciento durante el procesamiento de las
actividades de fin de mes. Por lo tanto, un buen documento de SLA lo
divide en dos secciones o tal vez tres: una para el fin de mes, otra para
el horario laboral general y la otra para los períodos no laborales.
Y el proveedor de servicios puede afirmar que todo va bien si la disponibilidad
del servicio de fin de mes y horas de trabajo está en verde.
• El SLA debe establecerse entre el proveedor de servicios y el cliente.

Sin embargo, es importante asegurarse de que en el frente comercial,
todas las partes interesadas relevantes estén de acuerdo con los niveles
y también estén alineados en la organización del proveedor de
servicios. Esto es fundamental, porque desea que los niveles de servicio
coincidan con los procesos comerciales reales; esto se soluciona cuando
se involucran las partes interesadas comerciales correctas. Además, los
niveles de servicio esperados deben ser factibles de organizar desde el
lado del proveedor de servicios. Por lo tanto, es imperativo que la
organización de entrega junto con el equipo de diseño estén
involucrados antes de finalizar los acuerdos.
• Mencioné anteriormente que el documento SLA es una adición al

documento del contrato. Se espera que el documento del contrato esté
redactado legalmente, pero el documento SLA debe estar desprovisto
de todo lo legal. Debe redactarse de manera simple y directa, y sin
ambigüedades. Esto asegurará que tanto la empresa como el proveedor
de servicios entiendan lo que establece el acuerdo después de que los
abogados ya no estén involucrados. Esto asegurará la máxima
alineación entre las partes.
Nota El Efecto SLA de sandía

Sabes que una sandía es de color verde. Cuando lo cortas, el
interior es rojo. una cosa que es verde por fuera pero roja por
215
de interés
dentro es una metáfora popular en el mundo de la gestión de
servicios.
Considere el ejemplo que cité anteriormente sobre los
niveles de disponibilidad de Internet. Alcanzar el 99,9 por
ciento de disponibilidad en un mes no es un logro fácil. y, sin
embargo, el cliente no está contento. ¿Por qué? Debido a
que Internet falló el 0,1 por ciento del tiempo durante el
último día hábil del mes, el período en el que se procesaban
los trabajos de fin de mes. esta falla de Internet del 0,1 por
ciento contribuyó a varios retrasos y el cliente no cumplió
con sus objetivos.
el cliente no aprecia el servicio de Internet a pesar de que
califica alto en la escala de disponibilidad. en otras palabras,
el sla para la disponibilidad de Internet es verde porque el sla
establece que se debe lograr un mínimo del 99,5 por ciento.
sin embargo, es rojo desde la perspectiva del cliente porque
les falló cuando importaba. Como una sandía: verde por
fuera y roja por dentro.
este es un error común que ocurre una y otra vez. Ambas
partes deben asegurarse de que se consideren los
parámetros comerciales correctos y se establezcan
acuerdos de nivel de servicio para evitar el efecto sandía.
216
de interés

servicio
Para las actividades en la cadena de valor del servicio, la práctica de gestión del
nivel de servicio actúa como insumo y actúa como la voz del cliente desde el
punto de vista operativo.
Tabla 8-3. Gestión del nivel de servicio en SVC

Actividad de
CVS
plan alto el rendimiento del servicio operativo
influye en la actividad de planificación
en torno a los servicios y las carteras
de servicios.
diseño y Medio La retroalimentación sobre el
transición desempeño del servicio operativo
influirá en los diseños existentes y
futuros.
obtener/construir Medio Obtener/Construir recibirá niveles de
servicio para servicios y
componentes, y las diversas
capacidades de generación de
informes que sean necesarias.
comprometer alto los niveles de servicio actuarán como
un aporte crítico para comprometerse
con varias partes interesadas y el
núcleo de las revisiones del servicio.
entregar y Medio entrega y soporte recibirán los niveles
apoyar de servicio que necesitan para
mantenerse al día.
mejorar Medio Los comentarios recibidos de los
clientes actuarán como un insumo
para mejorar la actividad para iniciar
actividades de mejora.
217
de interés
8-1. ¿Cuál de las siguientes etapas no figura en la práctica de gestión de
relaciones?
A. Identificación
B. Análisis
C. Supervisión
D. Entrega continua
8-2. ¿Qué es un proveedor?
A. Un proveedor atiende al cliente como proveedor de servicios de bienes.
B. Un proveedor es generalmente un proveedor de servicios para un

C. El cliente contrata a un proveedor para gestionar los proveedores de

servicios del cliente.
D. Un proveedor es contratado por un proveedor de servicios para

interactuar con el cliente y ofrecer servicios.
8-3. ¿La práctica de gestión de relaciones trata con el cliente a qué niveles?
A. Estratégico, táctico y operativo.
B. Estratégico y táctico
C. táctico y operativo
D. Estratégico
8-4. ¿Cuál es el objetivo de la gestión del nivel de servicio?
A. La práctica de gestión del nivel de servicio existe para garantizar que

los detalles del proveedor estén documentados en el contrato entre el
cliente y las organizaciones proveedoras de servicios, y que se realice
un seguimiento del desempeño de los proveedores.
218
de interés
B. La práctica de gestión del nivel de servicio existe para garantizar que
los proveedores de servicios y los proveedores acuerden los niveles de
servicio para los servicios ofrecidos a los clientes, y que se les realice
un seguimiento.
C. La práctica de gestión del nivel de servicio existe para garantizar que el
cliente esté de acuerdo con los niveles de servicio que puede brindar el
proveedor del servicio.
D. La práctica de gestión del nivel de servicio existe para garantizar que

los niveles de servicio se acuerden entre las organizaciones del cliente
y del proveedor del servicio, y que se realice un seguimiento.
8-5. ¿Qué actividad en la cadena de valor del servicio es responsable

principalmente de proporcionar retroalimentación de los clientes?
A. Entregar y apoyar
B. Obtener/Construir
C. Participar D. Planificar
8-6. ¿Cuál de los siguientes no está incluido en un documento SLA?
A. niveles de servicio
B. Objetivos del servicio
C. Métrica
D. Indicadores clave de rendimiento
219
CAPÍTULO 9
Prácticas para
habilitar el soporte
de servicio
Un servicio es esencialmente concebido, diseñado, construido y soportado a lo
largo de su ciclo de vida. A lo largo del ciclo de vida, suceden dos cosas: los
servicios son compatibles, lo que necesariamente significa que los servicios siguen
funcionando como deberían; y si algo se rompe, se aplica una corrección de
ruptura. Luego hay varios cambios que suceden durante su vida. Las
modificaciones más pequeñas a un servicio se realizan ad hoc en la parte posterior
de la gestión de cambios. Los cambios importantes se someten a un ciclo de
mejora continua. Si bien todas estas actividades son visibles para las partes
interesadas y destacan varios logros, hay jugadores silenciosos en el juego que lo
hacen posible. Estos son los facilitadores que sustentan las prácticas de soporte de
servicios.
Este capítulo analiza las tres prácticas de habilitación de soporte que son
esenciales para administrar operaciones, ejecutar modificaciones e implementar
iniciativas de mejora. Las prácticas que vamos a analizar son:
1. Gestión de la seguridad de la información
2. gestión de activos de TI
3. Gestión de la configuración del servicio

CAPÍTULO 9 PRÁCTICAS PARA HABILITAR EL
SOPORTE DEL SERVICIO
6361-7_9
práCtiCas para Habilitar el soporte de servicio
Consejo de examen Puede esperar que aparezcan entre

una y dos preguntas de este capítulo.
Gestión de la seguridad de la
información
La seguridad de la información es una de las prácticas generales de gestión. Es un
área que ha cobrado mayor importancia cada día que pasa porque las amenazas de
piratas informáticos y malware aumentan con bastante rapidez. Ninguna
aplicación o servicio está exento de amenazas a la seguridad de la información. En
ITIL, la seguridad de la información se introduce en el diseño y no es una
ocurrencia tardía durante las etapas operativas.
Es cierto que las líneas entre la seguridad de la información en ITIL y
DevSecOps o Rugged DevOps se han desdibujado un poco. Aunque DevSecOps o
Rugged DevOps definen los límites de la seguridad de la información, la
exclusividad de la gestión de la información se mantiene en el marco de ITIL. Por
ejemplo, Rugged DevOps podría establecer los límites para configurar servicios.
Mientras que las interfaces con el servicio y con el mundo exterior se gestionan a
través de Rugged DevOps, el funcionamiento interno del servicio lo gestiona ITIL.
Sin embargo, con DevSecOps, los procesos DevOps colaboran con la práctica de
seguridad de la información de ITIL para definir e implementar controles que
administran las interfaces externas, así como los datos contenidos en ellas.
Definición de ITIL de la práctica de gestión de la seguridad de la

información
El propósito de la práctica de gestión de seguridad de la
información es proteger la información que necesita la
organización para llevar a cabo su negocio.
222
La definición de la práctica de seguridad de la información se define a un
alto nivel para cuidar el elemento de datos dentro del servicio. El resultado es
asegurar que el negocio al que servimos no se vea afectado por la
materialización de amenazas a la seguridad de la información.
La seguridad de la información se logra mediante la definición e
implementación de diversos controles, políticas, procesos y procedimientos de
trabajo de seguridad. Principalmente, son tres conjuntos de actividades que marcan
la pauta y aprovechan las definiciones de los controles, políticas y procesos:
1. Detección (supervisión)
2. Corrección
3. Prevención
Se deben definir diversas amenazas y riesgos de seguridad de la información y

establecer herramientas para detectarlos. El monitoreo de las amenazas de
seguridad se realiza en varios medios de datos, como el monitoreo de correos
electrónicos, páginas de Internet, malware, anomalías, prevención de pérdida de
datos e intrusión. Para cada una de estas áreas, existen varias herramientas
competitivas que se fortalecen día a día.
Muchas de las herramientas de detección también juegan el papel de
corrección. Una vez que detectan, pueden autocorregir la amenaza a través de una
secuencia programada de procedimientos de corrección. Cuando se trata de
seguridad de la información, el tiempo es esencial. Las amenazas deben
identificarse y rectificarse de manera oportuna para garantizar que los virus y los
ataques de intrusión no tengan tiempo para llevar a cabo su misión.
La prevención es la cura real que garantiza que las amenazas identificadas
ya no sean un problema. Puede verse como una solución permanente. Si bien la
acción correctiva proporciona una solución única, la acción preventiva no
ofrece posibilidades de que las amenazas tomen forma.
La pregunta entonces se convierte en el equilibrio que las organizaciones
deben lograr entre los tres conjuntos de acciones. La situación ideal es prevenir
todas las amenazas, pero en el proceso la innovación se sofoca. Un ambiente que
restringe la toma de riesgos va en contra del principio de Agile y DevOps.

Entonces, ¿cómo deberían las organizaciones decidir sobre el equilibrio que
223
necesitan alcanzar? Bueno, eso depende de su apetito por el riesgo y de las
posibilidades que estén dispuestos a asumir en nombre de la experimentación y la
innovación.
Áreas de Seguridad de la Información

La seguridad de la información es un campo de práctica en constante expansión.
Con la tecnología alcanzando nuevas alturas, las áreas de seguridad de la
información se están poniendo al día con la identificación y el endurecimiento de
los controles para cada uno de los aspectos tecnológicos. Hubo un tiempo en que
la seguridad se ocupaba principalmente de los virus. Hoy en día, se ha extendido a
varios ángulos, como usuarios de phishing, ataques DDoS (denegación de servicio
distribuido), ataques MITM (man-in-the-middle), entre los sospechosos
habituales, como malwares, adwares, spywares y caballos de Troya.
Cada una de estas amenazas a la seguridad de la información tiene como
objetivo diferentes sistemas, y su enfoque es diferente en cuanto a lo que apuntan
y cómo lo hacen. Todas estas amenazas se pueden explicar a través del quinteto de
seguridad de la información que consta de:
1. Confidencialidad
2. Integridad
3. Disponibilidad
4. Autenticación
5. no repudio
El quinteto se ilustra en la figura 9-1 .
224
Figura 9-1. Áreas de seguridad de la información
Nota en itil v3 se consideró la tríada de seguridad de la

información (confidencialidad, integridad y disponibilidad).
Con los avances tecnológicos, ahora es un quinteto. a
medida que exploramos áreas más nuevas, la seguridad de
la información también se ampliará a lo largo y a lo ancho.
Confidencialidad
La confidencialidad es la protección de la información contra el acceso no
autorizado. En otras palabras, solo aquellos con acceso a la información pueden
acceder a ella. Los proveedores de servicios y los clientes almacenan información
en servidores, servidores de aplicaciones de SharePoint y otros servidores de
archivos, y estos datos pueden contener estrategias comerciales confidenciales,
tácticas, información de tarjetas de crédito o información personal de los usuarios
finales. Esta información debe protegerse mediante los métodos mejor conocidos
por los profesionales de la seguridad de la información, como el cifrado y la
protección.
Para proteger la confidencialidad, los proveedores de servicios deben
asegurarse de que existan controles de acceso junto con el rigor para garantizar
que quien accede solo puede hacer lo que está permitido. Además, la clasificación
de la información es necesaria para proteger la información secreta y confidencial.
225
Integridad
La integridad es la protección de la información para que no sea modificada por
personas que no están autorizadas para hacerlo. Se integra estrechamente con la
confidencialidad y va un paso más allá en la protección de los intereses de todas
las partes involucradas. La información es valiosa si es precisa, y cuando es
modificada por usuarios no autorizados, los datos resultantes pueden derribar a las
empresas más rápido que una bala.
Hay varias formas en que se protege la integridad en estos días, siendo la
criptografía una de ellas.
Disponibilidad
La disponibilidad asegura que las partes autorizadas tengan acceso a la
información cuando la necesiten. Si proporciona el nivel correcto de encriptación
a través de la confidencialidad y garantiza la integridad a través de la criptografía,
pero no brinda accesibilidad a las personas autorizadas, todo el ejercicio de
asegurar la información es contraproducente, ¿verdad? El valor del servicio
proviene de las partes que tienen la disponibilidad para acceder a la información
cuando desean acceder a ella. Los piratas informáticos han encontrado una
manera de violar la seguridad de la información al bloquear el acceso a la
información a través de ataques de denegación de servicio distribuido (DDoS).
Varios sitios web populares, como Facebook, se ven afectados por este tipo de
ataques con bastante frecuencia. En este sentido, la denegación de acceso a la
información es una brecha en el logro de los objetivos de seguridad de la
información.
Autenticación
La autenticación es el proceso de identificar la entidad adecuada para
proporcionar acceso a las puertas de enlace y los recursos. Es un área bastante
vulnerable, ya que es utilizada principalmente por los usuarios y protegerla no
estaría solo en manos del proveedor del servicio sino de todos los usuarios.
226
Sin embargo, hay cosas que un proveedor de servicios podría hacer para
garantizar que el sistema se autentique con el nivel correcto de detalles. Por
ejemplo, un proveedor de servicios podría imponer una cierta complejidad de
contraseñas. Con contraseñas más complejas, los sistemas pueden protegerse de
ataques brutos. En estos días, la autenticación multifactor ha entrado en vigor, con
la contraseña seguida de una contraseña de un solo uso enviada a teléfonos
móviles o aplicaciones de autenticación que brindan una capa adicional de
seguridad. También existen otros medios, como escáneres de huellas dactilares y
métodos de reconocimiento facial. El objetivo es garantizar que solo la persona
adecuada pueda autenticarse y superar el umbral del sistema.
no repudio
No repudio es un término bastante nuevo. Se refiere a mantener marcas de tiempo,
artefactos y seguimiento para garantizar que una determinada acción pueda
respaldarse con pruebas suficientes. Consideremos un ejemplo: un usuario podría
suscribirse a un boletín diario. Para asegurarse de que el usuario acepta el
acuerdo, el servicio de boletín envía un correo electrónico todos los días en el que
se debe proporcionar cierta información. Se le pedirá al usuario que marque una
casilla para confirmar si acepta recibir un correo electrónico diariamente. Además,
se envía un correo electrónico al usuario para que lo confirme haciendo clic en un
enlace. Al dar seguimiento a estas acciones, el usuario no puede reclamar en
ningún tribunal de justicia que el boletín es spam enviado sin su consentimiento.
Otros ejemplos en tiempo real podrían ser las condiciones de pago y los acuerdos
firmados en varios sitios web y aplicaciones. Aunque no se utilizan contratos
formales en forma de documentos legales sellados, los acuerdos digitales tienen el
mismo propósito.
Con mi editor, firmé un contrato a través de un servicio de acuerdos en línea
llamado Docusign, donde se establecieron los términos del contrato y firmé
digitalmente los términos establecidos. El acuerdo que he firmado es válido en un
tribunal de justicia, y ni mi editor ni yo podríamos negarnos a firmarlo porque hay
amplias pruebas disponibles.
227

servicio
Debe esperar que la gestión de la seguridad de la información desempeñe un papel
importante en todas las actividades de la cadena de valor del servicio.
Tabla 9-1. Gestión de la Seguridad de la Información en SVC

Actividad de
IntervenciónDetalles
CVS
plan alto la seguridad de la información no es una
ocurrencia tardía. tiene que ser
impulsada y considerada desde las
etapas de planificación.
Diseño y alto la actividad de diseño y transición debe
transición considerar todos los aspectos de
seguridad durante el diseño de
productos y servicios, y se deben definir
los controles apropiados. Durante la
transición, se debe realizar una
transferencia efectiva de los controles de
seguridad a las operaciones.
obtener/construiralto Sobre la base de las entradas del
diseño, los controles de seguridad de la
información se traducirán en el
desarrollo de los productos y servicios,
incluidos los componentes
subcontratados a los proveedores.
comprometer alto La seguridad de la información solo
puede tener éxito si todas las partes
interesadas involucradas son parte
de los requisitos, el diseño, el
desarrollo y las operaciones. la
actividad de participación debe
garantizar que todas las partes estén
sincronizadas en los aspectos de
seguridad de la información.
228
Entregar y alto se deben priorizar los mecanismos
apoyar construidos para el monitoreo de
incidentes de seguridad. y, como cuando
se reportan incidentes de seguridad,
deben ser tratados hábilmente.
mejorar alto Si bien la mejora de los servicios es
imperativa, los aspectos de seguridad
deben ir de la mano con las iniciativas
de mejora propuestas.
Gestión de activos de TI
La gestión de activos es una práctica general en todas las industrias. La práctica se
refiere a la gestión de activos en diversas industrias. Por ejemplo, en la industria
del automóvil, un automóvil se compone de varios componentes y el propio
automóvil es un producto final terminado. Cada una de las partes individuales y el
automóvil se denominan activos. Un activo es el detalle más bajo de un
componente que se rastrea a lo largo de su ciclo de vida. Tal vez en la misma
empresa, pueden rastrear componentes como volantes y puertas como activos,
pero no los tornillos, remaches y casquillos que los mantienen unidos.
La práctica de gestión de activos de TI administra activos en la industria de TI
y, más específicamente, en las industrias que se ejecutan en el marco de ITIL. Por
lo tanto, se ha categorizado como prácticas de gestión de servicios y no como
prácticas generales de gestión.
Definición de ITIL de la práctica de gestión de activos de TI

El propósito de la práctica de gestión de activos de TI es
planificar y gestionar el ciclo de vida completo de todos los
activos de TI, para ayudar a la
organización:
• maximizar el valor
• controlar los costos
• gestionar los riesgos
229
• apoyar la toma de decisiones sobre la compra,
reutilización, retiro y disposición de activos
• cumplir con los requisitos regulatorios y contractuales
La práctica de Gestión de Activos de TI es esencial para garantizar que los
activos que contribuyen a un servicio sean críticos, y su gestión es una actividad
de back-end que, si no se lleva a cabo sin problemas, puede causar interrupciones.
Tomemos, por ejemplo, un servidor: su información de garantía debe ser rastreada
y extendida según sea necesario. Cuando se acerca al final de su vida útil, es
necesario reemplazarlo. Toda la información necesaria para ampliar o reemplazar
se incluye en esta práctica. Como establece la definición, la toma de decisiones
sobre la compra, la reutilización, el retiro y la eliminación se hace posible a través
de la práctica de gestión de activos. Gestionarlo bien y con eficacia también
reduce los riesgos que rodean a los activos de TI.
Además, los costos se pueden controlar al tener un inventario preciso y una
estimación igualmente precisa de la próxima demanda. Si la organización sabe lo
que tiene en la tienda, entonces no se irá de compras, sino que usará lo que tiene.
Asimismo, se pueden tomar decisiones de compra o alquiler cuando sea necesario,
con la ayuda de la información del inventario de activos.
Finalmente, existen varios estándares como ISO 9001 e ISO 20000 que exigen
que la información del inventario se mantenga y retenga para atenuar los riesgos
que conlleva la mala gestión de los activos de TI. Además, podría haber
regulaciones gubernamentales que solo se pueden cumplir a través de inventarios
de activos precisos.
Bien, hablamos del valor proveniente de la práctica de gestión de activos de
TI. Pero, ¿qué es este activo de TI del que estamos hablando?
Definición ITIL de activo de TI

Cualquier componente económicamente valioso que pueda
contribuir a la entrega de un producto o servicio de TI.
230
Cualquier componente que contribuya a los productos y servicios y que
tenga un costo financiero asociado es un activo de TI. Algunos ejemplos son
servidores, enrutadores, conmutadores, software o relojes inteligentes. ¿Por
qué solo componentes económicamente valiosos?, podría preguntarse. Mira la
última parte de la definición:
componentes que contribuyen a la entrega de un producto/servicio de TI. Hay
componentes de TI como procesos, políticas y marcos que contribuyen a un
servicio y pueden considerarse componentes esenciales. Sin embargo, dichos
componentes no entran dentro del ámbito de la gestión de activos de TI, ya que el
ciclo de vida es diferente y el objetivo de la gestión de activos de TI es supervisar
los inventarios que comienzan con la adquisición y terminan con la eliminación.
231
Capítulo 9
9-2 se ilustra un ciclo de vida típico de un activo de TI . Comienza con un

ejercicio de planificación que incluye estimación, previsión y obtención de
información relacionada con la demanda. A esto le sigue la adquisición del
activo o su construcción, seguido de su implementación. El activo de TI se
mantiene y actualiza hasta que llega al final de su vida útil y, al llegar al final
de su vida útil, se retira y se desecha.
Figura 9-2. Ciclo de vida de un activo de TI
Consejo de examen la definición de un activo de ti es

una de las preguntas más frecuentes en el examen
básico de itil. la pregunta se centrará en identificar la
definición correcta de una lista de opciones. por lo tanto,
232
es prudente que comprenda y memorice la definición
palabra por palabra.
Tipos de gestión de activos

En el corazón de la gestión de activos de TI se encuentra una base de datos
que consta de todos los activos de TI junto con otra información pertinente,
incluido su estado. Este es el registro de activos. Si la organización quisiera
realizar un control de inventario de sus activos, su primer y único punto de
inspección es el registro de activos. La base para llevar a cabo la
planificación y las adquisiciones es el registro de activos. Cuando los
usuarios plantean incidentes, el personal de la mesa de servicio consulta el
registro de activos para identificar el tipo de computadora portátil que se les
ha asignado. Las auditorías se llevan a cabo en función de la información
almacenada en el registro de activos contra el activo físico/software. Todas
las prácticas, ya sea la gestión de incidentes, el control de cambios, la gestión
de problemas o la gestión de implementación, pueden funcionar siempre que
el registro de activos esté disponible y sea preciso. Tal es la importancia del
registro patrimonial en las organizaciones.
El registro de activos de TI es un subconjunto del sistema de gestión de
configuración (CMS), ya sea de forma homogénea o en una estructura
federada.
Nota el registro de activos se denominaba base de

datos de activos en las versiones anteriores de itil, aunque
se suponía que era coherente con la base de datos de
gestión de configuración (CMDb), de la que hablaremos en
una sección posterior.
No todos los activos de TI se pueden administrar de la misma manera,

aunque los ciclos de vida de todos los activos de TI son similares. El tipo de
233
gestión de activos de TI está determinado por la naturaleza del activo y su
propiedad. En términos generales, la gestión de activos se puede clasificar de
la siguiente manera:
1. Gestión de activos de hardware
2. Gerencia de activos de software
3. Gestión de activos del cliente
4. Gestión de activos basada en la nube

Gestión de activos de hardware
La gestión de activos de hardware, como su nombre lo indica, es la gestión de
activos de hardware: activos que son de naturaleza física. Ejemplo: bastidores,
servidores, conmutadores, portátiles, teléfonos y dispositivos IoT.
El mantenimiento del hardware requiere procesos que sean robustos,
precisos y completos para garantizar que se tengan en cuenta todas las
circunstancias y escenarios durante su diseño. Es posible que la administración
del hardware no siempre se automatice cuando se puede monitorear. Muchas
veces es necesario realizar un inventario físico. Por lo tanto, es esencial que
todos los activos de hardware tengan una etiqueta que afirme una
identificación de activo única, para identificar el activo en el registro de
activos.
Me encargaron reunir un inventario para un gigante manufacturero
alemán que estaba repartido en 45 ubicaciones en la India. Si bien la mayoría
de los activos de TI estaban en la red, había una buena proporción detrás de
un firewall. Y muchos más estaban en las tiendas (y probablemente
olvidados). Para todos los activos en la red, pude realizar un inventario
automatizado a través de un programa Java que implementamos en todos los
sistemas. Para los que estaban en las tiendas y detrás de la red, contraté a
cerca de cien empleados que andaban buscando activos. Era como buscar
una aguja en un pajar. Después de este gigantesco ejercicio, basado en los
registros financieros internos del cliente, el inventario que realicé tenía una
precisión del 97 %, lo que superaba las expectativas del 95 %.
234
Gerencia de activos de software
Los activos de software son una bestia diferente. Con la gestión de activos de
software, gestionamos las licencias, incluido el software gratuito y el
software de prueba. Las licencias vienen en múltiples formas y tamaños: hay
licencias que están etiquetadas para activos, etiquetadas para usuarios y
licencias concurrentes, entre otras. Es imperativo que las organizaciones
cumplan en todo momento, ya que los editores de software realizan
auditorías periódicas y las sanciones por incumplimiento son bastante severas
(especialmente para los CIO).
Algunos desafíos con la gestión de activos de software son mantener el
registro de software donde se almacenan las copias con licencia y se controla
el acceso. Las licencias de software a menudo se van por el desagüe cuando
los activos de hardware se dan de baja. Por lo tanto, los procesos estrictos
deben estar en torno a los procesos de administración de hardware para
garantizar que las licencias no se pierdan.
Gestión de activos del cliente

Los activos de los clientes se refieren a los activos que se entregan a las
personas, como computadoras portátiles, teléfonos móviles, relojes
inteligentes y registradores de datos. El desafío proviene del peligro de
pérdida de datos que podría resultar debido a procesos y controles de
seguridad de la información poco estrictos. Es necesario establecer suficientes
controles para garantizar que los datos secretos y confidenciales no caigan en
las manos equivocadas.
Se emplean varias técnicas, como el uso de BitLocker en computadoras
portátiles y la realización de borrados remotos ante el olor de una
autenticación incorrecta repetida.
235
Activos basados en la nube
Los activos en la nube son una raza completamente diferente. Los activos de
hardware típicos ya no son activos físicos y, por lo general, el software
también se incluye con el hardware. La gestión de activos basados en la nube
debe considerar varios factores, como la naturaleza dinámica de la creación y
eliminación de activos. Con solo hacer clic en un botón, los servidores se
pueden crear y girar a través de canalizaciones. ¿Cómo se lleva a cabo la
gestión de activos de TI en activos que son de naturaleza dinámica?
Bueno, en tales circunstancias, empleamos la gestión de configuración.
Los activos de la nube se administran a través de una herramienta de
administración de configuración (no de configuración de servicios) que
mantiene los datos en función de los servidores que se activan y desactivan.
Los ejemplos incluyen Chef, Puppet y Ansible.
Además, ¿cómo identifica costos específicos para servicios específicos
cuando los servidores se comparten entre servicios? Ese es otro desafío que ha
planteado la aparición de la nube en la gestión de servicios de TI, que es lo que
hace que ITIL y la gestión de servicios de TI sean perennes e interesantes.

servicio
Tabla 9-2. Gestión de activos en SVC
Actividad de
CVS
plan Medio la práctica de gestión de activos
mantiene datos financieros y las
actividades de planificación
aprovechan estos datos. ayuda a la
organización a administrar los costos
y crear valor.
Diseño y alto Los estados de los activos se
transición determinan en función de las
actividades realizadas por esta
actividad.
236
obtener/construir alto esta es una parte esencial de la
gestión de activos, ya que tiene una
correlación directa con la adquisición
de activos.
comprometer bajo En ocasiones, los clientes pueden
solicitar información sobre el valor
residual de sus activos de TI.
Entregar y Medio la práctica apoya esta actividad al
apoyar identificar los activos junto con los
estados actuales.
mejorar bajo mejorar puede considerar el impacto
en sus activos por las iniciativas de
mejora recomendadas.
Gestión de la configuración del
servicio
La mayoría de los proyectos fallan debido a la falta de administración de
configuraciones y de tener un control total sobre los diversos componentes que
hacen que un proyecto funcione. La gestión de la configuración del servicio es
la base sobre la que se construye todo el proyecto. Ignorar los cimientos hará
que, lógicamente, las paredes y los techos del proyecto se derrumben en un
tiempo récord. La práctica juega un papel importante para los sistemas
formados por múltiples componentes que están integrados con otros sistemas
y se ejecutan en múltiples dependencias. ¿Suena familiar? Sí, casi todos los
sistemas de hoy son complejos, debido a la necesidad de integración y sus
respectivas fuentes de datos y consumidores de datos. En una configuración
tan complicada, es imperativo que los sistemas estén controlados por la
gestión de la configuración, de la que dependen en gran medida los proyectos.
La práctica de gestión de configuración de servicios de ITIL
(anteriormente gestión de configuración de servicios y activos) ha madurado
a lo largo de los años y ha estado impulsando la industria de servicios durante
varios años. La práctica ha sido la columna vertebral de los servicios de TI a
lo largo de los años y, dentro de ITIL, el proceso ha madurado con cada
versión. Es una práctica que determina si un proveedor de servicios tiene
237
éxito o no en la prestación de servicios de TI y define la amplitud de los
servicios ofrecidos.
Nota Notarás que uso la gestión de configuración

de servicios y la gestión de configuración. son uno y lo
mismo. Si bien la gestión de la configuración del servicio
es el nombre oficial de la práctica, generalmente se hace
referencia a la práctica como gestión de la configuración.
Definición de ITIL de gestión de la configuración del servicio

El propósito de la práctica de gestión de la configuración del
servicio es garantizar que la información precisa y confiable
sobre la configuración de los servicios y los CI que los
respaldan esté disponible cuando y donde se necesite. Esto
incluye información sobre cómo se configuran los CI y las
relaciones entre ellos.
La gestión de la configuración le brinda un modelo de los servicios de TI,

la arquitectura subyacente y las dependencias. Proporciona un reflejo preciso
de las piezas y dependencias conectadas. Es esta red de componentes la que
hace que el servicio funcione. Tenerlo en una forma viva y accesible brinda la
munición para realizar cambios en los servicios con facilidad, identificar el
impacto comercial con un análisis mínimo y resolver las interrupciones en un
santiamén.
Estas son las herramientas que necesita para ser un jugador válido en el
mercado actual, donde los cambios ocurren sobre la marcha y las listas de
deseos de los clientes cambian más rápido que la vida útil de las efímeras. Un
proyecto sin una gestión de configuración precisa y dinámica es una pesadilla
viviente. Imagine realizar cambios en una parte del sistema sin comprender el
impacto que podrían causar en otros sistemas dependientes. Esto sucede
238
comúnmente en la industria del desarrollo de software. No es raro que los
arquitectos se desconcierten cuando tienen ciertas dependencias y surgen
defectos a través de la regresión de las pruebas de aceptación bastante tarde en
el ciclo de vida del desarrollo. Esto es una especie de error porque existe una
buena probabilidad de que la entrega del software no se realice según el
cronograma prometido, y si los equipos de desarrollo intentan incluir
soluciones en el último minuto, aparecerán defectos. Si tan solo los arquitectos
tuvieran un proceso de gestión de la configuración en funcionamiento, podrían
haber identificado todo lo que necesitaba ser cambiado y podrían haber
evitado la negatividad que emana de las fallas.
Tratemos de entender el término CI, que significa elemento de
configuración.
Definición ITIL de elemento de configuración

Cualquier componente que deba administrarse para brindar
un servicio de TI.
Consejo de examen la definición de un elemento de

configuración es una de las preguntas más frecuentes en
el examen básico de itil. la pregunta se centrará en
identificar la definición correcta de una lista de opciones.
por lo tanto, es prudente que comprenda y memorice la
definición en
literal.
Un CI es un componente fundamental de un servicio que se puede

configurar, rastrear, contabilizar y controlar. Por ejemplo, en un servidor de
correo electrónico que involucra servidores, enrutadores y aplicaciones de MS
Exchange, cada servidor, enrutador, conmutador, aplicación y firewall puede
considerarse un CI. ¿Por qué? Porque estos CI se pueden rastrear, controlar,
contabilizar y auditar.
239
Puede preguntarme si un servidor es un CI o si el disco duro, la memoria y
otros componentes dentro de un servidor son CI. ¿Quién decide qué puede o
no ser un CI? Esta es una decisión que toma el arquitecto de configuración en
función de la naturaleza del servicio, su interfaz con otras prácticas, como el
control de incidentes y cambios, y lo que es más importante, el costo. Por
ejemplo, un servidor puede considerarse un CI. Por el contrario, cada uno de
los componentes de un servidor, como el procesador, la memoria y los discos
duros, pueden considerarse como CI, lo que necesariamente alude a mucho
más esfuerzo (y costo) para idear la gestión de la configuración y mantenerla.
Por lo tanto, generalmente se deja que el arquitecto tome la decisión de hacer
un juicio sobre qué nivel debe considerarse un CI. La práctica general es medir
el valor que se deriva profundizando en los servicios para derivar CI.
Cada CI tiene varios atributos adjuntos. Los atributos son varios detalles
que se registran en un CI, como el propietario, la ubicación, la fecha de
comisión, el estado y la configuración. Todos estos atributos se controlan a
través del control de cambios. Esta es la capa de control que garantiza que la
gestión de la configuración siga siendo precisa y que nadie pueda realizar
cambios sin la aprobación y el consentimiento del gobierno de control de
cambios.
CMDB, CMS y modelo de servicio

La base de datos de gestión de la configuración (CMDB), el sistema de gestión
de la configuración (CMS) y los modelos de servicio son elementos inherentes
de la práctica de gestión de la configuración del servicio.
Base de datos de gestión de configuración
Una CMDB es un repositorio que contiene todos los CI, incluidas sus
relaciones. Por ejemplo, en una CMDB, la dependencia entre los elementos de
configuración se puede definir a través de relaciones como "se ejecuta en" y
"compatible con".
240
Dentro de la CMDB, puede tener varios servicios, los CI individuales y
sus relaciones. La mayoría de las herramientas modernas de ITSM, como
ServiceNow y BMC Atrium, ofrecen marcadores de posición para registrar los
impactos ascendentes y descendentes. Si selecciona un servicio y desea usarlo
visualmente para ver cómo los CI se conectan entre sí , verá una serie de
conexiones entre los CI. Con esta imagen visual, otros procesos, como la
gestión de incidentes, pueden solucionar incidentes con facilidad, y procesos
como la gestión de cambios pueden identificar impactos ascendentes y
descendentes con solo hacer clic en un botón. Imagínese si esto no estuviera
en su lugar; toda la actividad relacionada con el análisis y la solución de
problemas sería difícil.
En una organización, podría tener varias CMDB según los requisitos, la
estructura comercial y las obligaciones del cliente. Por ejemplo, puede tener
una CMDB para las unidades comerciales A, B y C; una CMDB por separado
para el cliente ABC; y otra CMDB para infraestructura interna y software. No
hay límite, siempre que la lógica tenga sentido para administrar, controlar y
simplificar las cosas.
Sistema de gestión de la configuración

El CMS es la súper base de datos que contiene todos los CMDB y más en su
ecosfera. Es la capa que integra todas las CMDB individuales junto con otras
bases de datos en el espacio de administración de servicios de TI, como bases
de datos de errores conocidos, registros de incidentes, registros de problemas,
registros de solicitudes de servicio, registros de cambios y registros de
versiones.
Definición de ITIL del sistema de gestión de la configuración

Un conjunto de herramientas, datos e información que se
utiliza para respaldar la gestión de la configuración del
servicio.
241
Capítulo 9
La Figura 9-3 proporciona una ilustración de un CMS.
Figura 9-3. Sistema de gestión de configuración (CMS)
En esta ilustración, tiene tres CMDB diferentes: uno podría ser un ecosistema
SAP y los otros dos para diferentes ecosistemas tecnológicos. Recuerde que los CI
individuales en la CMDB posiblemente se pueden vincular a los CI que están en
otra CMDB. Ejemplo: una aplicación .net que recupera datos de un sistema SAP.
Además, en un CMS tiene varias otras bases de datos como la base de datos de
errores conocidos (KEDB), registros de incidentes, registros de problemas,
registros de solicitudes de servicio y registros de cambios. Los datos dentro del
CMS pueden interconectarse para respaldar las prácticas de gestión de servicios.
Suponga que un servidor deja de funcionar y el CI correspondiente se asigna en un
registro de incidentes. Con una solución alternativa, se genera un registro de
problema y el mismo CI se asigna allí. Se identifica una solución permanente, que
requiere que la configuración del servidor sea
242
Capítulo 9
cambió. Se genera un registro de cambio y se asigna el CI del servidor. Del mismo

modo, independientemente de la actividad que realice dentro del espacio de
gestión de servicios, todas están bajo el CMS.
Recuerde que puede haber varias CMDB en una organización, y todas las
CMDB y otras bases de datos formarán parte de un único CMS.
Modelo de servicio
Un modelo de servicio también se denomina mapa de servicio. Es una vista gráfica
de la CMDB que muestra las relaciones entre los CI interconectados. En la Figura
9-4 se muestra una vista de un modelo de servicio .
Figura 9-4. Ilustración de un modelo de servicio

En este ejemplo simplista, hay 2 servicios que funcionan con 3 aplicaciones.
Las aplicaciones 1 y 2 son necesarias para que funcione el servicio 1, y las
243
Capítulo 9
aplicaciones 2 y 3 son necesarias para que funcione el servicio 2. Estas
aplicaciones están alojadas en servidores como se muestra en la figura: la
aplicación 1 en el servidor 1 y las aplicaciones 2 y 3 en el servidor 2. Hay una
base de datos que utilizan las aplicaciones 2 y 3, y esta base de datos está alojada
en el servidor 1.
Ambos servidores están alojados en un centro de datos.
El valor no es una representación de una CMDB en un formato gráfico; radica
en su aplicación. Si se informa un incidente de que el servicio 1 está inactivo, la
práctica de gestión de incidentes observaría el modelo de servicio y determinaría
las dependencias, es decir, la aplicación 1, la aplicación 2, la base de datos, el
servidor 1 y el servidor 2. Luego, comienzan a solucionar el problema rastreando
los datos. flujo y conexiones.
Recuerde que las conexiones entre CI tienen un nombre de relación, como
padre de, hijo de, alojado en, montado en, etc. En función de estas relaciones y
dependencias, la eficiencia en la resolución de incidentes mejorará varias veces.
Otro ejemplo es el de la práctica de gestión del cambio. Si se genera un
cambio para realizar cambios de configuración en el servidor 2, según el modelo
de servicio, el administrador de cambios puede garantizar que todas las
aplicaciones y servicios que dependen del servidor 2 estén integrados en los
cambios de configuración propuestos. Esto garantizará que no se introduzcan
cambios no deseados en el sistema, y que los cambios que se introduzcan hayan
sido examinados minuciosamente por todas las partes interesadas. El modelo de
servicio también servirá como una herramienta para identificar a las partes
interesadas.
Nota el valor real de un modelo de servicio o gestión

de configuración en general no lo ve el negocio ni es visible
para el mundo exterior, pero es el motor que impulsa todas
las demás prácticas de las que dependen los servicios.
244
Actividades principales de configuración

del servicio
Gestión
Las actividades de administración de la configuración del servicio tienen varias
fases, como identificar las relaciones y los CI, validar que los CI y las relaciones
sean precisos y aprovechar la CMDB para proporcionar informes para varios
propósitos. En términos generales, se divide en cuatro actividades principales.
1. En primer lugar, los CI deben identificarse y completarse en la
CMDB. Deben definirse sus relaciones con otros CI.
2. Los cambios son comunes, lo que significa que los CI en la
CMDB cambian a medida que se aplica un cambio. El siguiente
proceso es modificar los cambios en el CI y la CMDB cuando
se implementan los cambios.
3. Los cambios no autorizados son frecuentes, lo que significa que
algunos cambios podrían realizarse fuera de la práctica de
gestión de cambios. Además, existe la posibilidad de que la
actividad de identificación no se haya realizado con un 100 por
ciento de precisión. Por lo tanto, es imperativo que la práctica
de administración de la configuración del servicio realice
validaciones periódicas en la CMDB. Estas validaciones
podrían hacerse a través de la tecnología y la automatización.
4. Para formalizar las validaciones, podría emplearse un auditor
para realizar comprobaciones con los CI que están en la CMDB
y con los que no lo están. Un auditor podría ingresar a un
centro de datos y elegir al azar un servidor de un bastidor y
extraer sus detalles en el
CMDB. Los detalles en la CMDB se comparan con el CI físico.
Un auditor también podría contar con herramientas de
descubrimiento que ayudarán a descubrir CI que no están en la
CMDB o viceversa.
245

servicio
Tabla 9-3. Gestión de configuración de servicios en SVC
Actividad de
CVS
plan bajo los CM podrían aprovecharse durante la
identificación y la propuesta de cambios
en los servicios.
Diseño y alto El diseño aprovecha los CM y también
transición proporciona entradas basadas en los
cambios de diseño. la transición
también depende en gran medida de los
CM.
obtener/construiralto Generalmente, Cis se crean en la parte
posterior de la actividad de
obtención/construcción.
comprometer bajo terceros podrían aprovechar los CM
para identificar dependencias o
proporcionar información de impacto.
Entregar y Medio esta actividad, como se explicó
apoyar anteriormente en el modelo de servicio,
aprovecha los CM para lograr
eficiencias y finalización del trabajo.
mejorar Medio La gestión de la configuración ha
evolucionado a lo largo de los años y ha
mejorado debido a las diversas mejoras
que se han producido. en base a las
necesidades del mismo, la práctica
evolucionará y se adaptará.
9-1. ¿Cuál de los siguientes es el verdadero propósito de la práctica de

gestión de seguridad de la información?
246
A. Proteger la información que necesita la organización para llevar a cabo
su negocio.
B. Proteger la información financiera y regulatoria del negocio
C. Para garantizar que los sistemas, la información y las redes estén
adecuadamente protegidos contra las amenazas a la seguridad.
D. Asegurar que se construya un cerco de seguridad para proteger el
conocimiento que la empresa tiene en sus repositorios.
9-2. ¿Cuál de las siguientes es la definición correcta de un activo de TI?
A. Un componente de TI que pasa por el ciclo de vida desde la
adquisición hasta la eliminación
B. Un componente que tiene un valor financiero y es propiedad del
proveedor de servicios para proporcionar servicios
C. Un componente de TI que se requiere para entregar un servicio
D. Cualquier componente económicamente valioso que pueda contribuir a
la entrega de un producto o servicio de TI
9-3. ¿Cuál es la diferencia entre CMDB y CMS?
A. CMS consta de todos los sistemas físicos, mientras que CMDB es una
base de datos de activos de TI.
B. CMDB tiene registros de incidentes, registros de problemas y otros
junto con información de activos de TI; CMS contiene múltiples
CMDB.
C. CMS es una base de datos de CI y CMDB consta de varios CMS.
D. CMDB es una base de datos de CI y CMS consta de múltiples CMDB.
9-4. ¿Cuál es el objetivo principal de un modelo de servicio?
A. Proporcionar una representación gráfica de la CMDB que ayudará a

los proyectos a comprender la arquitectura y tomar decisiones
relacionadas con la planificación y las mejoras.
247
B. Proporcionar una representación gráfica de los CI y sus relaciones
que ayudará a las organizaciones a identificar los CI cuyas relaciones
no están definidas, apoyando así la verificación de la CMDB.
C. Para proporcionar una representación gráfica de la CMDB que
proporcionará una arquitectura general de los servicios, y esto se
puede utilizar para tomar decisiones arquitectónicas.
D. Proporcionar una representación gráfica de la CMDB con el fin de
aumentar la productividad, reducir los tiempos de parada y brindar
soporte para la toma de decisiones.
9-5. ¿Cuál de las siguientes es la definición correcta de un elemento de
configuración?
A. Cualquier componente económicamente valioso que pueda contribuir a la
entrega de un producto o servicio de TI
B. Cualquier componente que deba administrarse para brindar un servicio de TI
C. Cualquier componente que entregue valor a un cliente a través de las
eficiencias proporcionadas por la práctica de gestión de incidentes.
D. Cualquier componente económicamente valioso que deba ser gestionado por
la práctica de gestión de servicios
248
CAPÍTULO 10
Continuo
Mejora
Lou Holtz, el famoso apoyador y entrenador, dijo una vez: “En este mundo, o
creces o te mueres. Entonces, ponte en movimiento y crece”. Esto suena cierto en
todos los aspectos de la vida, el trabajo y el entretenimiento, más aún en los
productos y servicios. Mencione un producto o servicio que haya permanecido
igual sin mejoras ni características nuevas y, sin embargo, haya dominado el
mercado durante décadas. Ninguno. Mantener el statu quo en la propiedad de
productos y servicios no nos llevará a ninguna parte más que fuera del mercado y
fuera de la mente de los usuarios. Por lo tanto, es una necesidad impuesta a los
fabricantes de productos y proveedores de servicios seguir mejorando sus ofertas y
mantener el barco en movimiento hacia nuevas costas. Piense en productos como
los teléfonos móviles, en los que se produce un nuevo teléfono cada pocos meses.
Esto no se debe a que los anteriores se hayan vuelto obsoletos, sino a mantener a
los consumidores interesados y mantener la pelota en marcha. En servicios, busque
proveedores de servicios de Internet. Sus servicios no se mantienen constantes. Se
esfuerzan por aumentar las velocidades, hacer que sus redes sean más confiables y
ofrecen varios complementos. Una vez más, esto no se debe a la escasez de sus
servicios o productos, sino a asegurar su supervivencia, que depende de las
mejoras. En el mundo de ITIL, la mejora continua existe para mantener la pelota
en movimiento, para garantizar que todo lo que se ofrece se mejore
constantemente.
Capítulo 10
6361-7_10
Mejora continua
Mejora Continua en SVS

La mejora continua es parte del sistema de valor del servicio. Revisemos SVS en
la figura 10-1 .
Guiding
Principles
Governance
Service
Opportunity and
Value Value
Demand
Chain
Practices
Continual
Improvement
Figura 10-1. Mejora continua en el sistema de valor del servicio.
En la SVS, la mejora continua es uno de los elementos críticos que ayuda a

generar valor. Junto con los principios rectores, la mejora continua garantiza que la
cadena de valor del servicio tenga el enfoque correcto para mejorar los productos y
servicios. Las mejoras no solo ocurren directamente en un producto a nivel
operativo, sino que también abarcan áreas tácticas y estratégicas.
La mejora continua en el SVS viene en las siguientes formas en ITIL:
1. El modelo de mejora continua, que consta de siete pasos que
brindan orientación sobre cómo se deben iniciar y gestionar
las mejoras a lo largo del ciclo de vida.
Mejora continua
2. En el SVC hemos hablado de la actividad de Mejorar, que se

encarga del negocio de asegurar mejoras en los servicios.
250
Capítulo 10
3. La mejora continua también es una práctica dentro de las
prácticas generales. La práctica brinda orientación sobre su
naturaleza operativa y da ruedas al modelo de siete pasos.
Consejo de examen La mejora continua es un tema

importante desde la perspectiva del examen básico de itil. es
uno de los pocos temas donde la profundidad de la
información entendida es importante para asegurar las
calificaciones. Puede esperar que aparezcan de tres a cinco
preguntas en este capítulo.
Modelo de siete pasos

El modelo de siete pasos encontró sus raíces en Lean y pasó a ITIL en su versión
ITIL V3. El modelo se ha aprovechado en todas las organizaciones con gran éxito;
los pasos involucrados son lógicos; y se puede aplicar a cualquier área, ya sea
manufactura, finanzas, servicios o vida. La figura 10-2 muestra el modelo de
mejora continua de siete pasos.
251
Capítulo 10 Mejora continua
Figura 10-2. Modelo de siete pasos de mejora continua
Nota en itil v3, el modelo de siete pasos tenía solo seis

pasos (se conocía como el modelo de mejora continua). el
paso que faltaba era el paso 5, tomar medidas, que estaba
marcado con cómo llegamos allí (paso 4).
252
Cada paso significa diferentes contextos y, por lo tanto, diferentes puntos de

vista y acciones. Las acciones en sí se definirán en función de la industria y el tipo
de mejora: estratégica, táctica u operativa. Sin embargo, lo que es consistente es el
flujo; los pasos a seguir deben seguirse, tal como se ilustra en el modelo.
El modelo es aún más significativo porque se alinea con la visión y la misión
de la organización y se conecta perfectamente con sus flujos de procesos
comerciales. Por lo tanto, los resultados también están en línea con lo que espera
la organización.
Cada acción de mejora sigue el modelo de siete pasos y, en un momento dado,
cada una de las mejoras podría estar en cualquier parte del flujo. Por ejemplo, la
mejora de los procesos podría estar en el paso 2, una mejora del rendimiento
podría estar en el paso 5 y luego otra mejora de la GUI podría comenzar en el paso
1. En la terminología Agile, el modelo de siete pasos para la mejora continua es
iterativo. en la naturaleza y encaja como anillo al dedo con la metodología Agile.
¿Qué es la visión?
La visión en el contexto empresarial comprende las metas y objetivos a largo
plazo de las organizaciones. Cada empresa, por lo tanto, comenzará con una
visión, como ser líder en servicios celulares móviles con más del 50 por ciento de
la participación de mercado (y tal vez difundir la paz en todo el mundo a través de
la espiritualidad y la consideración).
Esta es una historia de la vida real acerca de la visión. El fundador de
McDonald's, Ray Kroc, estaba en un bar con un grupo de estudiantes de MBA. Le
preguntó a uno de ellos: “¿En qué negocio crees que estamos?” El estudiante
respondió debidamente: “Estás en el negocio de vender hamburguesas”. Ray
replicó: “Estoy vendiendo hamburguesas pero ese no es mi negocio. Mi verdadero
negocio son los bienes raíces”.
Como organización proveedora de servicios, debe asegurarse de comprender
la visión de su cliente. A menos que esté sincronizado con él, comenzará a
trabajar, por ejemplo, para vender hamburguesas en lugar de los objetivos
comerciales centrales.
253
La estrategia de TI debe basarse en la visión, misión, metas y objetivos del

negocio. Esta es la única forma en que el proveedor de servicios puede
comprender y crear valor (a través de mejoras) para la organización del cliente.
El primer paso de la mejora continua considera principalmente la
visión/objetivos de la organización desde la perspectiva de la unidad de negocio
donde se llevará a cabo la mejora. Por ejemplo, una unidad de negocios de
petróleo y gas tendrá su propia visión. Cualquier mejora planificada bajo esta
unidad se adherirá a su visión en lugar de a una genérica, porque las metas y
objetivos de cada unidad de negocios son muy específicos (aparte de aumentar los
ingresos y obtener ganancias). En segundo lugar, la propia mejora se planteará con
sus propios objetivos. Tanto las visiones como los objetivos se consideran en el
paso 1.
El paso 1 intenta lograr lo siguiente:
• Comprender el contexto de alto nivel y los objetivos a cumplir

• La mejora propuesta está bien definida y acordada por todas las
partes interesadas involucradas.
• Defina todos los roles que están involucrados en el compromiso
de mejora y sus expectativas de rol
• Definir la comprensión del valor que se genera a través de la
mejora propuesta
¿Dónde estamos ahora?

Sin conocer la situación actual, es imposible medir el nivel de mejoras aplicadas al
final del ciclo. La clave del éxito para alcanzar el objetivo final es conocer el
punto de partida. Piense en ello como un viaje que está emprendiendo. Si mi
objetivo final es llegar al centro de Londres, es importante entender dónde estoy
ahora. Solo conociendo tu ubicación actual podrás llegar a tu destino.
Para comprender la posición actual, el punto de partida, la mejor herramienta
a emplear es una evaluación. Debe realizarse para recopilar el establecimiento, la
configuración y las actuaciones actuales. Realice una verificación con la varilla
254
medidora para obtener una vista instantánea, que se usará como referencia para
futuras comparaciones.
La evaluación debe basarse en todos los aspectos de un servicio, como la
cultura, las personas, la tecnología, los procesos, etc. Solo cuando se obtengan
todos los aspectos de un servicio será posible realizar una evaluación imparcial de
la línea de base actual, no basada en conjeturas.
Realizamos evaluaciones con la ayuda de mediciones objetivas, lo que
significa que medimos parámetros que se pueden medir y que proporcionan una
base para futuras comparaciones. Las mediciones no se realizan en función de
parámetros subjetivos como los factores de bienestar. Las mediciones realizadas
actúan como línea de base. Aunque, debo admitir, encontrar una línea de base y
medirla es más fácil decirlo que hacerlo. En realidad, identificar parámetros para
futuras comparaciones es una tarea ardua que requiere previsión de las mejoras
que se están introduciendo.
Nota una línea de base sirve como punto de partida y

como valor de comparación para el progreso realizado a
través de las mejoras.
Supongamos que te perdiste este paso; aún puede continuar con sus ejercicios
de mejora, pero no podrá medir las mejoras que ha realizado. Tomemos, por
ejemplo, si desea mejorar el rendimiento de un sitio web. Si no ha recopilado
datos antes de mover su sitio web a un servidor más rápido, ¿cómo sabe el alcance
o si el rendimiento ha mejorado en absoluto? Tal vez podría hacerlo en función de
la percepción, pero no es objetivo ni tan preciso.
Donde queremos estar

En esta etapa, sabemos lo que busca la organización y hemos descubierto dónde
estamos parados. Ahora el desafío es establecer una meta para el ejercicio de
mejora que nos lleve del punto A (dónde estamos ahora) al punto B (dónde
queremos estar). Pero recuerde que en este paso no nos preocupa cómo vamos a
255
llegar allí, sino simplemente identificar y reafirmarnos en el punto final que

pretendemos alcanzar.
Podrías pensar que el paso 1 (cuál es la visión) y este paso son lo mismo. No
precisamente. El paso 1 es aspiracional. La visión se establece en un nivel alto y es
de naturaleza bastante ambigua, como ser el restaurante de burritos número 1 en el
Reino Unido. ¿Cómo mides ser el número 1? ¿Se basa en las ganancias, los
ingresos o la cantidad de burritos que vende? ¿En cuánto tiempo aspirarías a ser el
número 1? Hay varias otras preguntas que pueden surgir de una visión. Sin
embargo, con el paso 3 (dónde queremos estar) definimos la meta en términos
específicos, sin ambigüedades y con objetivos precisos. Por ejemplo, quiero ser el
restaurante de burritos número 1 según la cantidad de puntos de venta de burritos
en todo el Reino Unido en los próximos 2 años.
Una forma de encontrar el destino es realizar un análisis de la brecha entre los
pasos 1 y 2. Con base en la visión, que da una dirección general y la posición
actual, se conoce la enormidad de la brecha. En base a eso, el objetivo puede
trazarse no para alcanzar la visión de inmediato, sino en múltiples iteraciones. Por
ejemplo, puedo estar comenzando con un restaurante de burritos y mi visión sigue
siendo la número 1 en 2 años. Pero prefiero caminar antes que correr, así que me
puse una meta intermedia de llegar al top 5 dentro de un año.
En este paso, también se establecen los factores críticos de éxito (CSF) y los
indicadores clave de rendimiento (KPI). Los objetivos establecidos, los CSF y los
KPI deben seguir el principio SMART, que significa específico, medible,
alcanzable, relevante y limitado en el tiempo.
Cualquier acción de mejora que se identifique debe venir armada con el
objetivo final. No debe ser perpetuo como "mejorar el tiempo de respuesta para la
resolución de incidentes". Bien, esta es una buena iniciativa, pero ¿cómo sabe el
equipo que ha logrado el objetivo de mejora? Un mejor objetivo sería mejorar el
tiempo de respuesta en un 15 por ciento más rápido que el tiempo de respuesta
actual. Entonces, en otras palabras, este es un paso que no se puede perder; si se
pierde, la acción de mejora nunca tendrá éxito porque nadie estaría en condiciones
de declarar que la acción de mejora ha alcanzado sus objetivos.
256
Nota
Factores críticos del éxito
Los CSF son algo que debe suceder para que la actividad
tenga éxito. Por ejemplo, “salvaguardar cajeros automáticos”
es un CSF en la industria bancaria, más específicamente en
los servicios de desembolso de dinero que el banco ofrece a
sus clientes. Por lo tanto, para que el desembolso de dinero
se realice con éxito, es fundamental que los cajeros
automáticos estén protegidos de ladrones, desnatadores y
piratas informáticos. es una ocurrencia común en países
como la India, donde los cajeros automáticos se llevan en
medio de la noche. En países africanos y americanos ha
habido innumerables casos de cajeros automáticos
manipulados para capturar la información de la tarjeta de
débito. para contrarrestar esto, el CSF mencionado en este
ejemplo establece la dirección.
Indicadores clave de rendimiento
Los indicadores clave de rendimiento (Kpis) son los
componentes clave que se utilizan para medir el éxito. En
pocas palabras, definen la medida y las tendencias que
hacen o deshacen el resultado de un proceso o proyecto.
como su nombre lo indica, son indicadores de rendimiento e
indican si el rendimiento está en las líneas esperadas o va
cuesta abajo. En la industria de gestión de servicios de TI,
usamos Kpis para medir el resultado de un servicio o
proceso de TI.
Definir un Kpi es un arte impulsado por la madurez de un
individuo o de la organización. es de suma importancia
257
identificar a las personas que pueden hacer que una

actividad en particular sea un éxito sorprendente o un pato
cojo. identificar Kpis no es tan fácil como diferenciar el
blanco del negro, sino que es como sacar limaduras de
hierro de un montón de arena. Necesitas usar una varita
magnética, que en este caso es la diligencia de un
profesional maduro.
¿Cómo llegamos allí?

Cuando llego al paso 4, sé dónde estoy y dónde quiero estar. La visión general
también está disponible como guía. El paso cómo llegamos allí se centra en el
proceso de ir del punto A al punto B. Llegar al punto B se puede hacer de varias
maneras, por lo que este paso es responsable de identificar la mejor opción posible
en las circunstancias dadas.
Por ejemplo, una empresa nueva sin cartera de productos desea desarrollar una
aplicación de cámara de video. Según su posición actual, deben comenzar desde
cero y llegar a una aplicación competitiva que funcione completamente. Su visión
les da una guía sobre cómo se debe hacer el diseño. La visión dice: "por todos los
medios, utilizamos aplicaciones de código abierto para crear soluciones
personalizadas". Entonces, cómo se desarrollará la aplicación tiene los límites
básicos trazados y los objetivos claramente establecidos. En este paso se lleva a
cabo el diseño de dicha actividad.
Si no cumple con este paso, no podrá cumplir con su objetivo. En otras
palabras, la actividad de mejora no logra realizar su intención.
Tomar acción
En esta etapa, el paso 5, los diseños están disponibles para que suceda el
desarrollo. El desarrollo puede ocurrir en cualquier marco, ya sea en cascada o
cualquiera de los sabores ágiles. Lo que importa en el paso 5 es que la entrega de
258
la mejora tome forma en función del diseño que viene del paso 4. Como estamos
familiarizados con Agile, los requisitos cambian todo el tiempo y necesitamos
pasar de una publicación a la siguiente rápidamente. manera. Del mismo modo, el
desarrollo de mejoras también puede tener que cambiar de dirección y pivotar
según sea necesario, para satisfacer las necesidades del negocio y la organización.
Entran en juego los aspectos típicos de la gestión de proyectos relacionados
con la gestión de riesgos, la medición del progreso, la gestión de las partes
interesadas y otras actividades. Este es un paso crítico en el proceso de mejora.
¿Llegamos allí?
Mientras que los cuerpos ocupados se enfocan en completar el trabajo en el paso
5, es posible perder de vista el objetivo y enfocarse internamente. Es entonces
cuando la naturaleza iterativa de Agile se utiliza bien al mantener una ficha estricta
y verificar el producto final con respecto a los requisitos. El paso 6, ¿llegamos
allí?, es una actividad que verifica si la mejora que se ha entregado es apta para el
uso y para el propósito.
Uno no puede darse el lujo de perder este paso, ya que mantiene el proyecto de
entrega de mejoras encaminado, centrado en los requisitos del cliente y actuando
como guía a lo largo del viaje.
Este principio paso a paso declara que una mejora es un éxito o un fracaso.
¿Cómo mantenemos el impulso?

Una mejora es como un tren. No se detiene en uno; hay varios trenes que van y
vienen a una estación. Del mismo modo, las mejoras tampoco se pueden hacer de
forma aislada. Siempre hay mejoras por hacer. No existe tal cosa como un
producto perfecto o un servicio perfecto. Mantener las mejoras funcionando una
tras otra, como los trenes que llegan a una estación, es una tarea desafiante.
El proceso de recopilación de ideas de mejora debe seguir encendiendo
nuevos fuegos a los ojos de los usuarios y otras partes interesadas. Los equipos
involucrados en las actividades de mejora deben estar lo suficientemente
259
inspirados, enfocados y motivados para definir nuevas mejoras y hacerlas

posibles. Todo esto es posible solo si la organización juega bien sus cartas a
través de un liderazgo capaz, gestión del cambio organizacional y prácticas de
gestión del conocimiento.
Lo peor que podría pasar es que las mejoras se reviertan y el servicio pase de
promedio a malo. Bueno, es muy posible que un servicio en status quo sin mejoras
se vuelva obsoleto mientras permanece estancado.
La otra cara de la moneda es que la realización de mejoras no siempre tiene
éxito. Habrá fracasos en el camino. ¿Cómo trata el liderazgo el fracaso, cómo lo
maneja el equipo y cuáles serán las implicaciones del mercado? Varias prácticas
organizacionales deben unirse para abordar situaciones, especialmente cuando van
en reversa. Se dice que aprendemos más de nuestros fracasos que de nuestros
éxitos. Por lo tanto, deben existir prácticas de gestión del conocimiento capaces de
capturar los aprendizajes que surgen de los fracasos y utilizarlos como munición
para salir del otro lado como un éxito rotundo.
Este es un paso que no debe perderse. Si se pierde, entonces el futuro del
producto o servicio estará en duda, ya que solo las mejoras pueden mantenerlos
con vida.
Práctica de mejora continua

El segundo papel de la mejora continua en ITIL 4 es el de una práctica. Se incluye
en las prácticas generales de gestión.
Nota La práctica de mejora continua es una práctica

importante desde la perspectiva del examen. Se espera que
comprendas la práctica en profundidad (y no solo los
conceptos).
260
La práctica existe para mantenerse al día con el mercado cambiante y los

requisitos cambiantes, y para garantizar que los productos y servicios obtengan las
mejoras necesarias cuando sea necesario.
Definición de ITIL de práctica de mejora continua

El propósito de la práctica de mejora continua es alinear las
prácticas y servicios de la organización con las necesidades
cambiantes del negocio a través de la mejora continua de
productos, servicios y prácticas, o cualquier elemento involucrado
en la gestión de productos y servicios.
La práctica no solo existe para identificar y ofrecer mejoras. Identificar

mejoras no es una actividad que pueda ocurrir en una sala de conferencias con una
sala de partes interesadas. Hay que encender la chispa en las personas que forman
parte de la organización, y para que las personas presenten oportunidades de
mejora, se debe inculcar una cultura adecuada. La práctica de mejora continua se
ocupa de todo el espectro de personas, procesos y tecnología para generar mejoras
para productos y servicios.
Actividades clave de la práctica de mejora

continua
Las actividades clave de la práctica de mejora continua son:
1. Construir una cultura de estar atento para identificar oportunidades

de mejora. No se puede simplemente tener un equipo de mejora
continua (como lo hacen algunas empresas)
que no hacen más que identificar mejoras. Proponer mejoras no se hace
en el vacío y requiere que el personal se exprese libremente y
experimente sin temor a las repercusiones. En resumen, todos en una
organización deben trabajar hacia la mejora continua. El liderazgo
superior en las organizaciones debe promover dicha cultura, que
coincidentemente también es la columna vertebral de la cultura DevOps.
261
2. Varias ideas y sugerencias son compartidas y discutidas. Esto

generalmente sucede con éxito en un nivel informal. Para
formalizarlo, se deben identificar formas en que las personas que
tienen una chispa lleguen a registrarla antes de que se escape de sus
células cerebrales. Solía trabajar para Atos (anteriormente Atos
Origin), y habían creado un portal llamado FISH (las ideas frescas
comienzan aquí) para capturar y administrar ideas. Cada idea
registrada fue leída, promovida y votada por los empleados de la
organización. Después de asegurar una cantidad de votos, la idea fue
revisada y priorizada por un comité de alto nivel e implementada si
cumplía con ciertas pautas. La actividad a la que toda organización
debe aspirar es a un proceso de registro de ideas de mejora continua,
y su debida evaluación y priorización de las mismas.
3. Identificar ideas y evaluarlas no cuesta dinero. La priorización se
realiza porque el dinero en el banco suele ser limitado y, a menudo,
se reserva un determinado presupuesto para mejoras. Entre miles de
ideas de mejora, se deben elegir unas pocas y asegurar un
presupuesto para su implementación. A continuación, obtener el
tiempo de los recursos que pueden realizar la mejora identificada.
4. Después de obtener el dinero para los proyectos de mejora, se debe
desarrollar un plan y entregar el proyecto. La forma en que se
entrega un proyecto depende de varios factores, pero la actividad
clave es que se lleve a cabo la implementación.
5. ¿Qué determina si una implementación fue realmente exitosa? Los
indicadores clave de rendimiento intervienen. Proporcionan
mediciones y procesos de evaluación para comprender si los
parámetros que se suponía que debían abordarse con la mejora han
mejorado o no, y si el usuario final está obteniendo más valor que
antes. Por lo general, no es sencillo, pero si se piensa lo
suficientemente bien antes de la implementación, entonces el
262
monitoreo, la medición y la evaluación deberían ser lo

suficientemente fáciles.
6. La actividad más importante y desafiante es desempeñar el papel de
coordinador. Cualquier mejora requiere que múltiples partes de una
organización se unan. Asegurar su tiempo y negociar entre ideas
variadas y hacer las cosas es difícil y requiere habilidades especiales.
Herramientas de mejora continua

Lograr mejoras constantes es arduo. Piensa en tu propia casa, en la que se espera
que sigas haciendo mejoras todos los días. Olvídate de vivir allí en paz; la tarea es
mejorar algún aspecto de su casa. Para bien o para mal, hacer las cosas es la parte
más fácil. Proponer ideas el día 1 es fácil, el día 10 está bien, pero el día 100 será
un hueso duro de roer. Hablé anteriormente sobre cómo toda la organización debe
convertirse en parte interesada en la identificación de mejoras. Asimismo, en el
ejemplo de proponer ideas para mejorar el hogar, se debe alentar a su familia
(incluidos los extensos junto con amigos y vecinos) a participar. Sin embargo, su
casa sobrevivirá sin mejoras durante varios años. Pero un producto o un servicio
que necesita venderse, que tiene un mercado, no puede. Los consumidores se
aburren. Quieren algo mejor. Están hambrientos de cambio. Necesitas alimentarlos
con nuevas características y características para mantenerlos felices. Eso es
exactamente lo que hacen periódicamente los fabricantes de teléfonos y los
editores de software. En algunos casos, es posible que las funciones mejoradas del
teléfono parezcan superficiales o, lo que es peor, inferiores a la versión anterior.
Recuerda que todo esto, las ideas y las oportunidades de mejora que se van
presentando, está saliendo del poder de las filas.
Para estar en la cima, no puedes confiar en la magia. Necesita herramientas
prácticas que pueda usar en diversas situaciones, algo que ayude en el resultado
del proceso de mejora continua. En esta sección, analizamos varias herramientas
que ayudan en el proceso de identificación y entrega de mejoras.
263
Registro de Mejora Continua

Las ideas de mejora se generan durante las discusiones, mientras se trabaja en una
tarea individualmente o con un equipo o incluso durante las revisiones del
servicio. De suma importancia cuando se generan ideas es registrarlas en un
repositorio confiable. No tenemos que ir tan lejos como para decir que debe ser
una única fuente de información, pero debe haber un repositorio de acceso común
donde los generadores de ideas puedan registrarlo sin problemas.
Esta es quizás la herramienta más crítica; en ITIL se denomina registro de
mejora continua (CIR). El objetivo de este registro es flexible; debe ser un
depósito donde las ideas se registran, revisan, priorizan y entregan/rechazan en
función de la calidad de la idea y las circunstancias.
Una organización puede tener cualquier número de CIR: digamos, por
ejemplo, un CIR para mejoras relacionadas con la infraestructura, un CIR para el
equipo de SAP, etc. Mientras exista el CIR, y el personal y otras partes interesadas
lo conozcan (y también tengan acceso), cumple su propósito. Sin embargo, se debe
tener cuidado al comparar las ideas registradas para garantizar que las ideas de
mejora no se entreguen de forma aislada, lo que lleva a reinventar la rueda.
En una organización típica, un CIR desempeña un papel similar al de una
acumulación de productos. Las historias de usuario en una cartera de productos se
revisan y priorizan periódicamente. Solo los elementos de mayor prioridad se
identifican para el desarrollo y se incluyen en el ciclo de desarrollo. Asimismo, las
mejoras pasan por el ciclo de priorización y repriorización. Una idea de mejora
permanece activa en el CIR hasta que se entrega la mejora.
Revisiones de mejora
Una vez que se registran las mejoras, deben revisarse regularmente para garantizar
que las que brindan el mayor valor se prioricen y se realicen en el ciclo más
temprano posible.
Una organización puede elegir cualquier número de formas de revisar una
mejora; podría ser tan simple como revisar la justificación comercial y tomar una
decisión basada en la intuición. O podría ser detallado y granular al intentar un
264
análisis de fortaleza, debilidad, oportunidad y amenaza (FODA). Una vista de

cuadro de mando integral también ofrece una evaluación granular sobre la mejora
que afecta a varias áreas del negocio. No es raro entregar las mejoras a terceros
también para una evaluación imparcial.
Metodología de desarrollo
El sabor de la década es ágil, pero eso no significa necesariamente que todas las
mejoras se entreguen de manera ágil. ¡Los caballos para los cursos son la norma!
Dependiendo de la mejora que se esté poniendo a través de la trituradora, se debe
identificar una metodología de desarrollo adecuada. Tomemos, por ejemplo, la
entrega de una infraestructura basada en una nueva arquitectura. Hacer esto en
Agile puede requerir más esfuerzo y no genera valor, ya que es muy poco probable
que la arquitectura cambie durante el desarrollo. En tales casos, es mejor optar por
una metodología en cascada.
La importancia de esta herramienta es elegir la metodología adecuada para la
mejora que se pone sobre la mesa. Esto se traduce esencialmente en que el equipo
de desarrollo salta de una metodología a otra y ajusta su mentalidad en
consecuencia.
Enfoque de implementación
La herramienta final en el arsenal de mejora continua es decidir cómo se entregan
las mejoras a los usuarios y otros consumidores del servicio/producto.
La experiencia nos dice, de manera similar a la metodología de desarrollo, que
las implementaciones se pueden realizar con un enfoque de gran explosión o por
fases. No solo esto, hay varios enfoques de implementación que se pueden
emplear, como una versión canary, azul/verde o prueba A/B.
Lo que es necesario es encontrar el enfoque correcto para el escenario
correcto. Si está lidiando con una mejora simple, implementarla en un enfoque de
gran explosión tiene sentido porque el impacto si las cosas van mal es quizás
insignificante. Pero si está incorporando un nuevo software de banca en línea, una
versión canary cautelosa sería útil.
265
Compromiso con la cadena de valor

del servicio
Tabla 10-1. Mejora Continua en SVC
Actividad de
CVS
plan alto la actividad de planificación
aprovecha la mejora continua en la
formación de planes y proporciona
retroalimentación a la práctica sobre
la relevancia de la mejora para la
dirección de la organización.
Diseño y alto las ideas identificadas y ratificadas
transición por la práctica de mejora continua
son entradas a la actividad de Diseño
y transición para desarrollar y hacer
la transición de las ideas a la
entrega.
obtener/ alto se diseñan las ideas de mejora, y en
construir la actividad de
obtención/construcción, se
desarrollan y retroalimentan a Diseño
y transición para la transición al
producto/servicio.
comprometer medio El alcance de la práctica de mejora
continua involucra a terceros,
incluidos proveedores y otras partes
interesadas involucradas.
entregar y alto las mejoras a las que se hace la
Apoyo transición se entregan a los usuarios
finales y el producto/servicio recibe
soporte a lo largo de su ciclo de vida.
266
mejorar alto la actividad de mejora en el SvC

proporciona gobernanza a las ideas
de mejora al priorizar y asignar
recursos a las mejoras identificadas.
10-1. ¿Cuáles de los siguientes pasos no están presentes en el modelo de

siete pasos?
A. Tomar acción
B. ¿Dónde estamos ahora?
C. ¿Lo que debe hacerse?
D. ¿Donde queremos estar?
10-2. ¿Cuál es la importancia de averiguar dónde se encuentra

actualmente la organización antes de embarcarse en la
identificación de mejoras?
A. Una línea de base sirve como punto de partida y como valor de comparación
para el progreso realizado a través de las mejoras.
B. Comprender dónde estamos actualmente nos ayuda a comprender los errores
que se cometieron anteriormente.
C. Proporciona un equilibrio en términos de las mejoras que se toman antes y
después de entregar una mejora.
D. Las realidades del terreno proporcionan un valor excelente para evaluar la
relevancia de las ideas de mejora.
10-3. ¿Qué papel juega la cultura en la identificación de mejoras?
A. La cultura de una organización permite una colaboración y coordinación que
es decisiva para generar ideas de mejora.
267
B. La identificación de mejoras debe provenir de todos los sectores. Esto no es

posible si la organización no le da a su personal la libertad de expresarse y
experimentar.
C. Se debe inculcar una cultura en una organización a través de la formación de
un equipo de mejora continua que sea responsable de la entrega de ideas de
mejora.
D. La cultura proporciona la base para que los servicios y productos mejoren y
creen valor para los clientes.
10-4. ¿Cuál es la metodología ideal para desarrollar mejoras?
A. La metodología ágil proporciona la flexibilidad y la libertad expresiva para
que se entreguen mejoras a medida que se identifiquen y ratifiquen nuevos
requisitos de mejora.
B. La metodología de cascada se emplea para la mejora, ya que la naturaleza de
las mejoras no cambia los requisitos inherentes.
C. Se empleará un modelo híbrido que involucre tanto la metodología Agile como
la de cascada, para garantizar que se consideren los requisitos cambiantes y se
cumplan los plazos de entrega.
D. Se debe identificar una metodología para la entrega de la mejora basada en la
mejora que se necesita desarrollar.
10-5. ¿Cuál es la base para mantener un registro de mejora continua
(CIR)?
A. Proporciona un punto de comparación para medir la calidad de las mejoras
identificadas por el personal de una organización.
B. CIR es el repositorio para administrar los artefactos relacionados con ideas de
mejora, códigos relacionados y otra documentación.
C. Es un repositorio que gestiona las ideas de mejora a lo largo de su ciclo de
vida.
268
D. CIR es la acumulación de productos para mejoras. La única diferencia es que

las mejoras identificadas se almacenan en el CIR y las ideas se trasladan a la
cartera de productos después de las revisiones.
269
DIA 5
Tiempo aproximado de estudio: 1 hora y 12 minutos Capítulo 11 –

1 hora y 12 minutos
El día 5 es un día importante, ya que profundizamos en las prácticas de soporte:

administración de incidentes, problemas y monitoreo y eventos. Estas prácticas se
emplean comúnmente en la industria hoy en día.
CAPÍTULO 11
Prácticas para
Gestionar
Operaciones
El corazón de ITIL se encuentra en las operaciones. Esta es la fase de la gestión de
servicios en la que esencialmente se crea o se pierde valor, los clientes quedan
asombrados o se alejan, y las organizaciones prosperan o apenas sobreviven.
Puede haber una fase en la que las mejoras o los nuevos desarrollos se detengan
(tal vez debido a una recesión económica), pero las operaciones continúan
mientras exista el final del soporte del producto o hasta que el servicio que se
ofrece a los clientes esté activo.
Dicen que necesitas poner tu dinero donde está tu boca.
Para un proveedor de servicios, la mayor parte de la acción tiene lugar durante las
operaciones. Los clientes siempre tienden a recordar las operaciones de servicio
por encima de todas las demás prácticas y actividades, ya que sus interacciones
ocurren principalmente en esta área. El proveedor de servicios también factura el
monto máximo del contrato total en la fase de operaciones. Sin embargo, este no
es el mejor lugar para poner su dinero, aunque la boca está abierta. ¡Descubrirás
las razones lo suficientemente pronto!
Las actividades operativas se ocupan del mantenimiento de productos y
servicios que han sido diseñados, construidos y en transición en las actividades
anteriores de la cadena de valor del servicio. En esta fase, no se realizan
modificaciones funcionales o no funcionales al servicio (cualquier modificación
realizada se realizará como una mejora). Se mantiene un statu quo, lo que
garantiza que el servicio funcione como se diseñó. Las prácticas operativas son
las más largas en términos de tiempo, son las más grandes en términos de
dotación de personal,

6361-7_11
y, lo que es más importante, el cliente generalmente forma una percepción del
proveedor de servicios a través de los logros de la fase operativa.
Si la estrategia es innovadora, el diseño es sólido y la transición es perfecta,
entonces puede esperar que las operaciones de servicio sean menos ruidosas y
probablemente pacíficas. En realidad, sin embargo, esto nunca sucede. Las
estrategias están destinadas a cambiar con el tiempo, los diseños tienen fallas, ya
sean artificiales o limitaciones debido a la tecnología, y las transiciones rara vez
están libres de eventos. Las innovaciones y los avances tecnológicos traen consigo
cambios en los productos y servicios. Estos cambios se diseñan, construyen y
transicionan a través de la práctica de control de cambios; después de la transición,
las prácticas operativas mantienen las especificaciones modificadas del producto o
servicio. Con la llegada de DevOps, el mantenimiento de productos y servicios es
mucho más fácil. En caso contrario, suele existir un periodo de transición y
formación del personal de apoyo. En ese caso, dado que el personal de soporte es
nuevo en los cambios, puede esperar fallas de soporte y problemas agravantes para
el cliente. La metodología DevOps ha asegurado que las operaciones sean una
obviedad y que sean negocios como de costumbre en la vida de un equipo DevOps
que crea y administra productos y servicios.
He trabajado en operaciones de servicio durante una buena parte de mi carrera
y no es algo en lo que me gustaría centrar mis células de memoria. El día normal y
corriente incluía atender llamadas sobre la marcha, dormir cuando el cliente está
durmiendo y hacer malabarismos con los planes de vacaciones en sincronía con
los compañeros. Ahora la parte buena: las operaciones de servicio contratan a la
mayoría de las personas en la industria de administración de servicios. Los
profesionales de ITIL tienen seguridad laboral siempre que puedan adaptarse a las
necesidades de flexibilidad de las organizaciones. Recuerde que no todas las
organizaciones de proveedores de servicios trabajan en modo DevOps, por lo que
hay mucho trabajo por hacer en la próxima década más o menos.
Con DevOps, se espera que un profesional de operaciones de servicio
administre más que solo operaciones de servicio, como administrar algunas de las
herramientas de CI-CD o ensuciarse las manos con la codificación. Pero una cosa
está clara: no puede esperar sobrevivir en la industria de TI como un pony de un
solo truco. Tienes que ser capaz de hacer múltiples formas de actividades. Esa es
la forma en que se perfila el futuro, y es una tendencia inmediata que estoy viendo
en la industria actual.
CAPÍTULO 11 PRÁCTICAS PARA
GESTIONAR OPERACIONES
Este capítulo cubre tres prácticas:
• Monitoreo y gestión de eventos.
• Administracion de incidentes
• Gestión de problemas
Las expectativas de monitoreo y gestión de eventos desde una perspectiva
de examen son un requisito básico de comprensión, mientras que las prácticas
de gestión de incidentes y problemas deben entenderse bien. Este es un
capítulo importante desde dos ángulos: (1) como mencioné anteriormente, las
operaciones están en el corazón de ITIL y, por lo tanto, el capítulo exige el
máximo enfoque; y (2) una serie de otras prácticas se interrelacionan con estas
prácticas, por lo que es imperativo que llegue al fondo de las prácticas
operativas.
Consejo de examen prácticas para la gestión de

operaciones es un tema importante desde la perspectiva
del examen itiL Foundation. si necesita responder
preguntas correctamente, necesita más que una
comprensión superficial de los temas. Puede esperar que
aparezcan de seis a siete preguntas en este capítulo.
Monitoreo y Gestión de Eventos

Hay varios elementos de configuración que contribuyen a un servicio. Estos
CI individuales son responsables de la entrega exitosa de un servicio. Por lo
tanto, es fundamental que si alguno de los CI no funciona como debería, se
deben tomar las medidas pertinentes para restaurarlo lo antes posible. El
concepto de vigilar los CI es un ejemplo de monitoreo en ITIL, y la acción
276
emprendida a raíz de dichos cambios (generalmente negativos) en los estados
es la esencia de la gestión de eventos.
Definición ITIL de Monitoreo y Gestión de Eventos

Práctica
El propósito de la práctica de monitoreo y gestión de eventos
es observar sistemáticamente los servicios y los componentes
de los servicios, y registrar e informar cambios de estado
seleccionados identificados como eventos.
El trabajo de la práctica de monitoreo y gestión de eventos es garantizar

que se tenga un dedo en el pulso en todo momento. El objetivo es detectar
comportamientos anormales lo antes posible para brindar ayuda. ¡Piénsalo!
Cuanto antes detecte un problema, antes podrá solucionarlo, lo que se traduce
en interrupciones del servicio mínimas.
Algunos de los CI típicos que se monitorean incluyen infraestructura,
aplicaciones, seguridad de TI, servicios y procesos comerciales. Un servicio
típico podría tener miles de CI detrás de él. Por lo tanto, no tiene sentido
monitorear cada uno de ellos. Por lo general, se supervisan los elementos de
configuración críticos que contribuirán directamente al funcionamiento de un
servicio. Si un servidor tiene establecida una conmutación por error
automática (arquitectura de alta disponibilidad) a través de otro servidor, la
frecuencia de monitoreo puede ser limitada. Es posible que las aplicaciones no
tan críticas no se controlen a la misma velocidad vertiginosa que una
aplicación de banca por Internet. La idea detrás de esto es priorizar los
servicios y CI que deben monitorearse y las acciones posteriores que deben
tomarse en caso de falla. En el mismo ejemplo, si la aplicación de banca por
Internet no funciona, las alarmas podrían comenzar a sonar para que el
personal de gestión de incidentes mayores reúna los recursos técnicos para
solucionar el problema a un ritmo rápido. El personal técnico puede ser
despertado de su sueño para abordar el problema. Ahora suponga que el
software interno de gestión del tiempo deja de funcionar; es probable que el
277
tiempo de inactividad se identifique cuando un miembro del personal lo
informe, y puede solucionarse a su propio ritmo. Clara y considerablemente,
se prioriza la aplicación de banca por Internet sobre el software de gestión del
tiempo. Todo depende del impacto y la urgencia de poner en marcha la
aplicación.
Tipos de eventos
Antes de entrar en el tipo de eventos, comprendamos el significado de un
evento.
Definición ITIL de un evento
Cualquier cambio de estado que tenga importancia para la
gestión de un servicio u otro elemento de configuración (CI).
Un evento es un cambio de estado. Que mi hija pase de tener hambre a

estar llena después de una comida también es un cambio de estado. Entonces,
el servidor ya no es accesible. Un evento en sí mismo no cambia las reglas del
juego, pero la importancia detrás de un evento es crítica. ¿Cuáles son los tipos
de eventos a los que posiblemente queramos estar atentos? Un usuario que
inicia sesión en una aplicación con éxito es un evento que puede ignorarse,
pero vale la pena tomar nota y confirmar una aplicación utilizada por las
agencias de seguridad que registran un inicio de sesión de Corea del Norte.
Nota la definición de un evento es una de las

preguntas más frecuentes en el examen básico de itiL. la
pregunta se centrará en identificar la definición correcta
de una lista de opciones. por lo tanto, es prudente que
comprenda y memorice la definición palabra por palabra.
278
Todos los eventos no son iguales. La mayoría son informativos y algunos
indican fallas o condiciones a punto de fallar. Según la aplicación, los eventos
se clasifican en términos generales de la siguiente manera.
Eventos de excepción
Los eventos de excepción significan errores. Indican una condición en la que
el sujeto monitoreado no está funcionando como debería; en otras palabras,
es posible que haya algún problema con un componente o un servicio.
Requieren la mayor atención. Por lo tanto, se clasifican en el nivel superior y
normalmente requieren una acción urgente.
Ejemplos de un evento de excepción son:
• El servidor es inalcanzable
• El espacio en el disco duro ha excedido los límites del umbral
• El administrador ha intentado iniciar sesión con una contraseña

incorrecta
• El escaneo de la PC revela malware
Nota la definición de qué eventos son excepciones y

cuáles no es una decisión de la organización en acuerdo
con el cliente. no existe una categorización universal
basada en la ilustración de eventos.
Eventos de advertencia
Es posible que haya oído hablar de los eventos apocalípticos del fin de los
días, en los que se predicen profecías sobre el fin del mundo tal como lo
conocemos. El mundo aún no ha terminado, pero hay una advertencia antes de
279
tiempo. La advertencia está destinada a acelerar la precaución y tomar un
curso correctivo antes de que ocurra algo malo.
Eventos de advertencia similares se definen en la práctica de supervisión y
gestión de eventos, y estos eventos existen para advertir sobre una excepción
inminente. Lanzan una advertencia que indica que las cosas pronto tomarán un
rumbo equivocado si no se tratan rápidamente. Son importantes porque
ayudan a una organización de TI a ser proactiva y evitar excepciones/tiempos
de inactividad. El final de los tiempos puede ser una fantasía, pero los eventos
de advertencia no lo son. Tienen una alta probabilidad de materializarse. Por lo
tanto, es imperativo que un servicio brinde el mismo tipo de urgencia que para
los eventos de excepción.
Ejemplos incluyen:
• El uso de la memoria se acerca al umbral aceptable.

• Una aplicación se está ejecutando más lento de lo normal.
• El tiempo de respuesta para una determinada transacción no está
dentro de los límites optimizados.
• La temperatura en el centro de datos no está en el nivel ideal.
Eventos informativos
Si le gustan las compras en línea, recibe esos correos electrónicos y mensajes
cuando el paquete ha sido enviado o cuando está listo para su entrega. No
significan mucho en términos de nuestra respuesta. No me preparo para recibir
un paquete tan pronto como recibo un correo electrónico por la mañana
informándome que está listo para la entrega. Pero definitivamente me sentiría
nervioso si no recibiera este mensaje.
En resumen, los eventos informativos transmiten información,
particularmente la información sobre un cambio de estado, no necesariamente
un cambio o estado anormal o anomalía. Estos eventos no requieren una
acción urgente por parte del personal de TI y, por lo general, se registran y
conservan con fines de cumplimiento y auditoría. Ejemplos incluyen:
280
• El usuario ha iniciado sesión en un servidor.
• Nueva carpeta creada en una unidad de SharePoint
• La aplicación ha procesado un trabajo por lotes

• El técnico de hardware ha entrado en el centro de datos
Tenga en cuenta que una organización proveedora de

servicios debe dedicar un tiempo y un esfuerzo
considerables a diseñar los eventos y las condiciones del
evento. no les gustaría recibir un evento bastante tarde en
el día y definitivamente no quieren perder más tiempo
procesando un evento informativo.
Actividades clave
En el antiguo marco de ITIL, la gestión de eventos era un proceso menor.
Aunque el monitoreo era parte de la gestión de eventos, no se mencionó
explícitamente. Aunque crítico, se consideró menor porque su alcance y
gestión se limitaban a unas pocas actividades y la mayor parte se manejaba a
través de conjuntos de herramientas. ITIL 4 no hace tal distinción, y la
práctica ha sido convocada para realizar varias actividades en el grupo de
gestión de servicios.
Estrategia de seguimiento
El seguimiento es una actividad que realizan las herramientas. Sin embargo,
no les da a las organizaciones la libertad de monitorear cada CI y cada nodo,
por la simple razón de que cuesta dinero obtener licencias y administrarlas
será nada menos que una pesadilla.
Es necesario implementar una estrategia para dejar las cosas claras y
proporcionar dirección y liderazgo a la gestión de eventos. La estrategia
establece condiciones sobre qué CI y servicios se monitorearán, lo que a su
vez se basará en la criticidad del servicio y el impacto comercial.
281
Diseño de Monitoreo
Discutimos los tipos de eventos en la sección anterior. Durante la actividad de
diseño de monitoreo, se talla una forma definida para cada uno de estos tipos
de eventos.
Esencialmente, identifica el tipo de eventos que entrarán en cada uno de los
cubos.
Además, deben definirse los umbrales para la activación de eventos de
advertencia y excepción. Por ejemplo, si va a producir un evento de
advertencia de la capacidad del disco duro al 95 por ciento, es posible que
no le dé al equipo de operaciones el tiempo suficiente para trabajar en el
problema de capacidad en cuestión. Más bien, dar una advertencia al 70
por ciento proporcionará tiempo suficiente y permitirá que el equipo de
operaciones tome decisiones prudentes. Dichos umbrales se identifican
para diferentes tipos de CI: un evento de advertencia para un servidor
tendrá condiciones distintas en comparación con un evento de advertencia
para una aplicación.
Los arquitectos de soluciones emplean métodos empíricos y análisis de

tendencias para determinar umbrales y otros parámetros de diseño. Las
herramientas de monitoreo también están determinadas por ellos.
Gestión de políticas
Ahora que los eventos han sido diseñados, el siguiente punto de la lista es la
gestión de los mismos. ¿Cuáles son las políticas que impulsan la gestión de
estos eventos? Esa es la esencia de esta actividad.
Cada tipo de evento que se diseña se complementa con una política y un
proceso para su gestión. Si hay una advertencia de capacidad de disco duro de
un servidor, ¿qué se debe hacer? ¿Debería enviarse una alerta al equipo del
servidor o debería crearse y asignarse automáticamente un incidente con baja
prioridad? ¿Cuál debería ser la prioridad para los eventos de excepción?
¿Todos los eventos de excepción tienen etiquetada la misma prioridad de
incidente? Las respuestas a estas preguntas son el resultado de esta actividad.
282
Implementación de Herramientas de
Monitoreo
Con los diseños de monitoreo implementados, se implementan las
herramientas de monitoreo. Herramientas como AppDynamics y Splunk
gobiernan el espacio de herramientas de monitoreo, y esta actividad garantiza
que se configuren contra los CI, nodos y servicios según el diseño.
Hay dos tipos de monitoreo que normalmente empleamos: monitoreo
pasivo y monitoreo activo.
El monitoreo pasivo es la capacidad de monitoreo nativa integrada en un
CI; por ejemplo, un firewall tiene su propia capacidad de monitoreo. Cuando
algo no funciona como debería, entonces su monitoreo capta la señal y toma
las medidas apropiadas.
El monitoreo activo es una entidad no nativa que realiza el monitoreo.
Nagios, AppDynamics y Splunk brindan monitoreo activo. Estos tienen
características en comparación con el monitoreo pasivo, ya que monitorean de
manera proactiva varios parámetros de un CI y un servicio. Digamos, por
ejemplo, que Splunk hace ping a un servidor cada minuto y si no hay respuesta
después de cierto número de pings, genera un evento de excepción. Digamos,
en este caso, que la red está caída. La herramienta de monitoreo pasivo de un
servidor no entra en juego, ya que la pérdida de la red no le da una
oportunidad justa para crear eventos.
Implementación de Procesos
Los procesos se definen para gestionar los eventos y las actividades
posteriores. No solo esto, los procesos proporcionan un marco para el
mantenimiento de las herramientas de monitoreo y las eficiencias de los
procesos a su alrededor.
Los procesos de gestión de eventos se definen a través de la actividad de
política y se implementan a través de esta actividad. La gestión de eventos
incluso brinda orientación para la implementación de la automatización, las
condiciones de umbral y las acciones de automatización.
283
La actividad también es responsable de identificar los roles del proceso y
sus responsabilidades. Sus accesos deben ser resueltos. Para desempeñar sus
funciones, están estrechamente alineados con las políticas y los procesos
definidos.
Habilitación de automatización
La mayoría de las prácticas en ITIL están enfocadas en roles y personas. La
automatización se utiliza en trabajos repetitivos y para generar eficiencia. La
práctica de monitoreo y gestión de eventos es la única práctica que va en
contra de la tendencia. Sus procesos emplean la automatización para sus
operaciones normales; sin herramientas y automatización, la práctica no
cumple. En otras palabras, las herramientas y la automatización forman la
columna vertebral del monitoreo y la gestión de eventos.
práctica.
La automatización puede ser parte de los CI a través de la función de
monitoreo pasivo que está integrada en ellos. Puede realizar conjuntos
limitados de actividades y puede ser útil para identificar cambios de nivel de
configuración. Por otro lado, las herramientas de monitoreo activo emplean la
automatización para sondear los CI y tomar las medidas necesarias en función
de la respuesta. Además, los cambios identificados en el monitoreo pasivo
pueden incorporarse a las herramientas de monitoreo activo para su posterior
procesamiento, como generar alertas e incidentes.
Compromiso con la cadena de valor del

servicio
Tabla 11-1. Monitoreo y Gestión de Eventos en SVC
Participación en la
Detalles
actividad de SVC
plan ninguno no hay participación de la práctica en la
284
actividad del plan debido a su
naturaleza transaccional y operativa.
Diseño y Medio los datos provenientes del monitoreo de
transición Cis y servicios pueden influir en los
diseños.
obtener/ Bajo Durante el desarrollo del entorno, sus
construir respectivos entornos podrían estar bajo
el control de la práctica de supervisión
y gestión de eventos.
comprometer Bajo Con base en los resultados del
monitoreo, se podría involucrar a
terceros.
Entregar y alto el quid de la práctica de monitoreo y
apoyar eventos se realiza en la actividad de
Entrega y soporte, que es la actividad
operativa de la cadena de valor del
servicio.
la identificación de anomalías y el
levantamiento de incidencias son
ejemplos de su actuación.
mejorar Medio la práctica de monitoreo y gestión de
eventos mantiene sus oídos cerca del
suelo y está en una excelente posición
para proporcionar puntos de datos para
mejoras.
Práctica de gestión de incidentes

La gestión de incidentes es una de las prácticas de ITIL más populares, desde
la perspectiva de la cantidad de trabajos que crea el proceso. Como es natural,
la mayoría de los profesionales de ITIL son conscientes de los principios por
los que se rige la práctica.
Además, la práctica funciona por más tiempo y con puntos de contacto
máximos con varias partes interesadas a lo largo de la cadena de valor del
servicio. La práctica de gestión de incidentes es la principal responsable de la
285
satisfacción del cliente y la agilidad con la que se manejan las interrupciones
del servicio.
He trabajado varios años en el área de práctica de gestión de incidentes,
algunos como administrador de incidentes y principalmente como propietario
de la práctica de gestión de incidentes. El proceso de gestión de incidentes es
dinámico y siempre terminas aprendiendo algo nuevo cada vez que surge una
nueva situación. No puedes aburrirte con el proceso, ya que cada situación es
diferente; incluso en dos situaciones similares, las posibles respuestas pueden
variar. También es el proceso que me ha mantenido despierto toda la noche en
ciertos días y ha mantenido a la alta gerencia de la organización del cliente al
borde de sus asientos en todo momento.
Si necesita ser exacto sobre la práctica de gestión de incidentes, puede
afirmar que es un proceso reactivo sin un lado proactivo. Y estaría de
acuerdo. Reacciona a las situaciones y su eficacia depende de la rapidez y
eficacia con la que se gestione la interrupción del servicio. El cliente no se
molesta si hay interrupciones del servicio, pero definitivamente se
descontentaría cuando la restauración supere las expectativas establecidas.
Nota es un hábito o una práctica general comenzar

el diseño o la implementación de prácticas de itiL en una
organización desde la práctica de gestión de incidentes.
Ya sea que esta sea la mejor práctica para comenzar o
no, me reservaré mi comentario por ahora. sin embargo,
su popularidad debido a las soluciones de ruptura que son
las normas en la industria de servicios o productos ha
hecho que la práctica sea una parte esencial de todas las
industrias, incluidas las que no son de TI.
Antes de entrar en la práctica, comprendamos el término incidente .
286
ITIL Definición de Incidente
Una interrupción no planificada de un servicio o una
reducción en la calidad de un servicio.
Los clientes disfrutan de los servicios que aportan valor. Si hay una
interrupción en el servicio, entonces el valor que proviene del servicio ya no
existe. Piense en un salón en su área. Vas allí para que te corten el pelo, que es
un servicio. El valor es una buena apariencia proveniente de un cabello bien
peinado. Si el salón cierra debido a una fuga de agua, el servicio se
interrumpe. Como cliente, ya no podrá disfrutar del servicio hasta que se
solucione la fuga de agua.
La interrupción del servicio es un incidente. Si la fuga de agua está
planeada (no puedo imaginar que pueda serlo, pero por el bien del argumento
digamos que lo es), entonces ya no es un incidente.
El segundo criterio para un incidente es una calidad de servicio inferior a
la media. Si el peluquero en el salón te hace un corte de cabello desigual y
asimétrico, entonces, aunque estás recibiendo el servicio, ya no obtienes los
beneficios de él. Estarás lejos de tener un buen aspecto con un mal corte de
pelo.
Estos casos también se consideran incidentes.
Algunos ejemplos de TI podrían ser el almacenamiento en búfer de
videos de Netflix, la imposibilidad de enviar correos electrónicos y la falla
del disco duro en una computadora portátil. En todos estos casos, el servicio
no está disponible por completo o es de mala calidad. Tales interrupciones se
denominan incidentes.
Nota si usted es una persona que apuesta, debe

colocar sus apuestas en la definición de un incidente
que aparece en el examen básico de itiL. la pregunta se
centrará en identificar la definición correcta de una lista
287
de opciones. por lo tanto, es prudente que comprenda y
memorice la definición palabra por palabra.
Ahora estamos listos para entrar en la práctica de gestión de incidentes.
Definición ITIL de práctica de gestión de incidentes

El propósito de la práctica de gestión de incidentes es
minimizar el impacto negativo de los incidentes al restaurar
la operación normal del servicio lo más rápido posible.
Sabemos lo que es un incidente: una interrupción de un servicio. Los

incidentes, aunque comunes, son malos. En nuestros respectivos proyectos y
organizaciones, nosotros tampoco queremos tener incidentes en nuestros
platos. La gestión de incidentes tiene que ver con mantener la tasa de
incidentes en el nivel más bajo y garantizar que la vida útil de un incidente sea
lo más corta posible. Esto minimiza la pérdida de un servicio y aumenta la
satisfacción del cliente.
Mirando específicamente la definición, la práctica de gestión de incidentes
existe para reducir el impacto de un incidente, lo cual es posible mediante la
resolución rápida de incidentes.
Teniendo en cuenta los ejemplos que mencioné anteriormente, como
cliente, sería más feliz si Netflix dejara de almacenar en búfer y comenzara a
reproducir la película, lo antes posible. No apreciamos la pérdida de un
servicio ni siquiera por un minuto, pero cuando comparamos, estaríamos más
contentos de ver los servicios restaurados en 10 minutos en lugar de en 20
minutos. La esencia es el tiempo. Cuanto más rápida sea la resolución, más
eficaz será la práctica de gestión de incidentes.
Los líderes pueden decir que la proactividad es el camino a seguir y el
futuro.
288
Sin embargo, cuando se trata de la práctica de gestión de incidentes, es
altamente (o completamente) reactiva y el proceso más cuidado en la industria
de gestión de servicios.
Buenas Prácticas de Gestión de

Incidentes
Suceden incidentes. No se pueden evitar. Son una parte integral de la vida de
un producto o servicio. Algunos productos y servicios suelen dar lugar a más
incidentes, mientras que el resto podría ser un número relativamente menor. Es
como si la gente se enfermara de gripe, resfriado y tos. Todo el mundo se
enferma, unos más que otros. La enfermedad es como un incidente. Se pueden
hacer dos cosas para controlarlos:
1. Encuentre una solución (cura) para que el tiempo de

inactividad (enfermedad) no dure mucho.
2. Encuentre una solución preventiva (inmunidad) para que,
en la mayoría de las causas, permanezca protegido contra
incidentes (enfermedades).
Sin embargo, es posible que tenga un incidente ocasional (resfriado

común) en el que una aplicación congelada (gripe) solo se puede resolver
mediante un reinicio del servidor (paracetamol).
El truco consiste en gestionar los incidentes de manera que el tiempo de
inactividad sea mínimo. Es difícil definir un tiempo de inactividad mínimo, ya
que cada usuario y cada servicio tiene sus propios límites para soportar los
tiempos de inactividad. Lo que es más importante, las mejoras que se ponen en
la actividad Mejorar del SVC encuentran oportunidades que podrían prevenir
incidentes, como programar un trabajo de reindexación automática de la base
de datos para evitar la lentitud en la búsqueda de datos.
A continuación, los incidentes vienen en todas las formas, colores y
tamaños. Por lo tanto, la gestión de incidentes debe ser capaz de identificar el
289
área de preocupación e involucrar al equipo adecuado. Por ejemplo, el equipo
que administra los servidores está separado del equipo que administra las
bases de datos. Y el equipo que administra las aplicaciones está separado del
equipo que administra las integraciones. Por lo que sabemos, estos equipos
podrían estar ubicados en diferentes unidades de negocios y ser parte de
diferentes organizaciones.
Estas son algunas de las buenas prácticas en la gestión de incidentes:
1. Registre todos los incidentes, incluidos los identificados
por el personal interno de TI.
2. La autoayuda es una gran ayuda para las organizaciones

en las operaciones de manos libres. Las actividades
como el restablecimiento de contraseña deben llevarse a
cabo sin intervención humana.
3. Tenga una mesa de servicio capaz como primer punto de
contacto para los usuarios y otras partes interesadas. Que
no sean solo portavoces, sino que sean la primera línea
de defensa para la práctica de gestión de incidentes.
4. Identificar una matriz de escalamiento funcional donde,

comenzando desde la mesa de servicio, se escala un
incidente a través de varios equipos para su resolución.
5. Mantenga una matriz de equipos que sean responsables
de las diferentes categorías de incidentes. Esto es útil
para una entrega rápida seguida de una resolución más
rápida de los incidentes.
6. Recuerde que todas las partes interesadas que respaldan

la cadena de valor del servicio pueden resolver
incidentes, incluidos los proveedores que brindan los
facilitadores necesarios para un servicio.
7. Recuerda los comandos que son especialmente
290
unidades entrenadas transportadas en helicóptero para
misiones especiales. Construya un equipo como los
comandos en los que se pueda confiar cuando el impacto
y la urgencia sean de suma importancia.
8. Use técnicas como swarming, donde todas las partes
interesadas se reúnen durante las etapas iniciales de
resolución. Una vez que son capaces de identificar qué
parte interesada necesita llevarla adelante, otros se
dispersan y la parte interesada a cargo continúa hasta el
final.
9. Algunos incidentes podrían dar lugar a prácticas de

gestión de la continuidad del servicio (que no se tratan
como parte de este libro), en las que se invocan los
planes de recuperación ante desastres para que se
establezca una resolución rápida (o solución alternativa).
10. Recuerde que todas las partes interesadas están obligadas
por un único principio: mantener todas las
actualizaciones registradas en un registro de incidentes.
Sin esta disciplina, es imposible darse cuenta de los
beneficios de las otras buenas prácticas que he
mencionado aquí.
Las buenas prácticas que he mencionado aquí son solo la punta del iceberg
y definitivamente no son exhaustivas, pero creo que deberían ayudarlo a
comenzar a registrar las buenas prácticas que funcionan para usted y su
organización.
Nota la gestión de la continuidad del servicio entra

en juego cuando hay un desastre. ejemplos podrían ser la
situación de CoViD, inundaciones, terremotos y disturbios.
la práctica asegura que el servicio perdure después de los
291
desastres. algunas técnicas empleadas podrían ser la
replicación de datos en tiempo real a un servidor en una
parte diferente del mundo y enviar personas a diferentes
partes de la geografía para que trabajen con la mayor
normalidad posible. Si bien esto es de naturaleza reactiva,
de manera proactiva la práctica trabajará en la creación
de resiliencia en los servicios al garantizar que la segunda
y la tercera línea de defensa entren en escena si los
servicios estuvieran bajo los efectos de un desastre.
292
PRÁCTICAS PARA GESTIONAR LAS OPERACIONES
Ciclo de vida de la gestión de incidentes

Hay varios tipos de incidentes. Un incidente único puede surgir cualquier día,
incluso después de brindar el mismo servicio durante varios años. No importa
qué tipo de incidentes se presenten y cuáles sean específicamente, el proceso
que entrega su gestión se puede estandarizar. El ciclo de vida de la gestión de
incidentes se puede explicar a través de la ilustración que se muestra en la
Figura 11-1 . Recuerde que los pasos del ciclo de vida varían entre
implementaciones. No hay pasos específicos o una secuencia que deba
seguirse. El ejemplo que se muestra en la Figura 11-1 sigue la lógica en la
identificación y secuencia de los pasos de gestión de incidentes.
Disparadores:
• Monitoreo y Gestión de Eventos
• Telephone
• Email/Chat
• Web Interface
Step 5:
Step 1:
Step 4: Incident Diagnosis
Incident
Prioritization and
Identification
Investigation
Step 6:
Step 7:
Step 2: Incident Step 3: Incident Resolution
Incident
Logging Categorization and
Closure
Recovery
Figura 11-1. Ciclo de vida de la gestión de incidentes
Nota los pasos que se muestran en esta sección

pueden o no aparecer en el examen de itiL Foundation. si
desea avanzar, no dude en omitir esta sección. sin
293
embargo, si está interesado en comprender cómo se
presenta el proceso y qué actividades se realizan y en
qué orden, ¡siga leyendo!
Paso 1: Identificación de incidentes
Tiene que haber un mecanismo para identificar los incidentes, no aparecen
solos en la puerta. La identificación de incidentes o la activación de incidentes
puede ocurrir de varias maneras. Recuerde que un proceso se inicia cuando es
impulsado por los desencadenantes identificados. Es importante que todos los
desencadenantes se identifiquen durante la etapa de definición del proceso.
Cuantos más, mejor, pero controlar todos los desencadenantes conocidos
requiere mucho esfuerzo y podría conducir a una identificación errónea de
incidentes si no se reducen. Los disparadores de gestión de incidentes más
utilizados son:
• Monitoreo y gestión de eventos : A través de la práctica de
monitoreo y gestión de eventos, se identifican incidentes; y
a través de la integración entre las herramientas de
monitoreo y la herramienta de registro de incidentes, los
incidentes se pueden registrar automáticamente.
• Por ejemplo, un servidor que deja de funcionar genera una

excepción con una herramienta de gestión de eventos. La
herramienta está diseñada para sondear el servidor cada
minuto; cuando no recibe respuesta tres veces consecutivas,
se genera un evento de excepción, que a su vez registra un
ticket de incidente.
• Teléfono : una de las formas más antiguas de presentar
quejas es levantar el teléfono y quejarse de un servicio
interrumpido. Para plantear una incidencia, los usuarios
tienen la opción de llamar a la mesa de servicio. El
desencadenante en este caso es la llamada telefónica de los
usuarios. También es posible que el personal de TI
294
encuentre una falla en uno de los sistemas y llame a la mesa
de servicio.
• Correo electrónico/chat : en lugar de llamar, los usuarios

pueden optar por una forma pasiva de comunicación por
correo electrónico o chat en tiempo real. Todavía estarían
interactuando con la mesa de servicio y haciendo que
planteen un incidente en su nombre. Este formulario es
bastante popular en el momento de escribir este libro y
permite a los proveedores de servicios atender a múltiples
usuarios a través de un único agente de la mesa de servicio.
• Interfaz web : en el mundo actual de recortes, la mesa de
servicio a menudo se reemplaza por mecanismos de
autoayuda. Las herramientas de emisión de tickets de ITSM
(Gestión de servicios de TI) brindan la interfaz para que los
usuarios generen sus propios tickets sin la ayuda de la mesa
de servicio. En cierto modo, es bueno que los valiosos
recursos se puedan utilizar en otros lugares. Pero también
podría conducir a una buena cantidad de incidentes mal
identificados que podrían aumentar la flacidez que no le
gusta ver.
La mayoría de las organizaciones también permiten a los usuarios crear

sus propios incidentes a través de una interfaz web mediante la creación de un
contenedor alrededor de la herramienta de emisión de tickets de ITSM. Para el
usuario, el formulario que llena sería simple sin las complicaciones de una
herramienta ITSM.
295
Paso 2: registro de incidentes
Todos los incidentes que se identifiquen deben ser registrados, con una marca
de tiempo que sea inalterable. Generalmente, el usuario registra los incidentes
directamente en la herramienta si hay una interfaz web.
Y las herramientas de gestión de eventos también pueden crear
incidentes, en función de los niveles de umbral y los algoritmos diseñados.
La mesa de servicio plantea incidentes en nombre de los usuarios finales
cuando llaman, envían correos electrónicos o chatean sobre sus problemas.
Hay varias herramientas de emisión de tickets de ITSM que se emplean
para registrar incidentes. Los más populares incluyen ServiceNow, BMC
Remedy y CA IT Service Management. ServiceNow está muy por delante de
sus competidores. Sus integraciones perfectas con otras herramientas y la
flexibilidad para implementar y ejecutar en una infraestructura optimizada lo
convierten en una opción fácil para las organizaciones. Esencialmente, las
herramientas de ITSM registran diferentes tipos de tickets, ya sean incidentes,
cambios o problemas, entre otros. También alojan CI y CMDB y bases de
datos de conocimiento. Cuando se genera un incidente, se puede asignar al CI
y, según el resumen del incidente, la base de conocimiento a menudo extrae
artículos de conocimiento que podrían ayudar con la resolución.
Un ticket de incidente tiene una serie de campos asociados, principalmente
para respaldar la resolución del incidente y controlar los diversos parámetros y
generar informes según sea necesario. Algunos campos comunes que se
encuentran en los tickets de incidentes son:
• Número de incidente (único)

• Nombre de usuario final
• Nombre del equipo del usuario final

• Nombre del registrador de incidentes
• Hora de registro del incidente
• Medio del incidente (teléfono/chat/web/correo electrónico)
296
• Impacto
• Urgencia
• Prioridad
• Categoría
• CI relacionado
• Resumen del incidente
• Descripción del incidente

• Grupo de resolución asignado
• ingeniero asignado
• Estado
• Código de resolución
• Hora de resolución/cierre
Paso 3: Categorización de incidentes

No todos los incidentes caen en el mismo cubo. Algunos incidentes se basan
en el servidor, algunos en la red y algunas aplicaciones/software. Es muy
importante identificar en qué cubo cae el incidente, ya que las categorías de
incidentes determinan qué grupo de resolución se asigna para resolverlo.
Por ejemplo, si hay un incidente registrado por la pérdida de Internet,
necesita que el equipo de red a cargo de manejar los problemas de red
trabaje en ello. Si este incidente se categoriza incorrectamente, por ejemplo,
aplicaciones, el incidente se asignará a un grupo de resolución que se
especializa en la solución de problemas de software y corrección de códigos.
No podrán resolver el incidente. Deben recategorizarlo y asignarlo al grupo
correcto. Pero el efecto de una categorización incorrecta es que la resolución
297
lleva más tiempo y esto anula el propósito del proceso de gestión de
incidentes. Por lo tanto, es absolutamente imperativo que el equipo que
registra el incidente esté especializado en identificar los tipos de incidentes y
categorizarlos correctamente.
En los casos de incidentes registrados automáticamente, las herramientas
de gestión de eventos están diseñadas para seleccionar una categoría
predeterminada que no falla. Los incidentes planteados por los usuarios se
clasifican automáticamente en función de las palabras clave mencionadas en el
resumen y la descripción del incidente. Es muy posible que el incidente se
categorice incorrectamente en este escenario, pero en aras de la
automatización, este es el precio que tenemos que pagar.
Paso 4: Priorización de incidentes

Considere un escenario de la vida real de una empresa que emplea a 100.000
empleados y hay un equipo de soporte de aproximadamente 100 técnicos. En
un momento dado, alrededor del 1 por ciento de los empleados plantean
incidentes por problemas que enfrentan: 1000 tickets. Por lo tanto, tiene 100
empleados de TI para manejar 1000 incidentes. No pueden manejarlos todos al
mismo tiempo. Necesitan seleccionar y elegir en cuáles trabajar primero y
hacer un seguimiento con el resto. ¿Cómo escogen y eligen? La respuesta está
en la priorización de incidencias.
No todos los incidentes tienen el mismo peso en cuanto a su impacto y
urgencia. Algunos son más urgentes, algunos causan más impacto que otros,
algunos pueden no ser urgentes y algunos no afectan gravemente ni son
urgentes. Por poner algunos ejemplos:
• Una solicitud de financiamiento a fin de mes causará un
gran impacto y debe solucionarse con urgencia.
• Una solicitud de financiación a mediados de un mes

causará un gran impacto, pero puede que no sea urgente.
• El visor de PDF que no se muestra en el formato correcto
para un solo usuario tiene un impacto bajo y no es urgente.
298
• La conectividad de red para todo un piso de usuarios
comerciales causa un gran impacto y es urgente.
• La aplicación de correo electrónico que no funciona para un
usuario VIP tiene un impacto bajo pero ocupa un lugar muy
alto en la lista de urgencias.
Por lo tanto, la prioridad del incidente se puede determinar en función del

impacto y la urgencia:
Prioridad del incidente = Impacto × Urgencia
El impacto se refiere al impacto comercial, que definitivamente es un

factor que impulsa la prioridad del incidente. El impacto comercial
normalmente se refiere a lo siguiente:
• Pérdidas financieras
• Pérdidas de productividad
• Pérdida de reputación
• Infracciones normativas o legislativas

La urgencia es una medida de la rapidez con la que se debe resolver el
incidente. Puede exigir que la mayoría del personal se dedique a un incidente
en particular de inmediato o indicar una resolución cuando los recursos de TI
estén disponibles.
Para determinar la prioridad de un incidente, imaginemos una matriz de
3×3 para derivar la prioridad del incidente en función del impacto y la
urgencia, como se muestra en la Figura 11-2 .
299
Figura 11-2. Matriz de prioridad de incidentes
Según la matriz, un incidente de alto impacto y alta urgencia se clasificaría

como prioridad 1. Un incidente de mediano impacto y urgencia se priorizaría
como 2, y así sucesivamente. La matriz que se muestra aquí es demasiado
simple para ser utilizada
300
Capítulo 11
en el mundo real. Hay demasiadas permutaciones y combinaciones para

considerar al clasificar la prioridad de un incidente, pero el principio es el
mismo.
El SLA de respuesta es el objetivo establecido para que los técnicos
respondan a los incidentes, por ejemplo, reconociendo y aceptando el
incidente en sus respectivas colas. Por ejemplo, un incidente se registró a las
10 am y el SLA de respuesta definido es de 30 minutos. En este caso, se espera
que el técnico acepte la incidencia antes de las 10:30 h.
Resolución SLA es el objetivo fijado por los técnicos para resolver
incidencias. Por ejemplo, se registró un incidente a las 10 am y el SLA de
resolución definido es de una hora. En este caso, se espera que el técnico
resuelva la incidencia antes de las 11 horas.
Ahora que tenemos las prioridades consideradas y determinadas, cada
una de las prioridades viene con su propio conjunto de SLA de respuesta y
resolución. Estos SLA se elaboran durante la fase de diseño del servicio en
el marco del proceso de gestión del nivel de servicio. En la Figura 11-3 se
muestra un SLA de respuesta y resolución de muestra para varias prioridades
.
Figura 11-3. SLA de gestión de incidentes
En el ejemplo, la prioridad más alta, P1, tiene un SLA de respuesta de 15

minutos y un SLA de resolución de 2 horas. Esto requiere que el equipo
técnico reconozca el incidente dentro de los 15 minutos (comenzar a trabajar
301
en la resolución), y se requiere que el incidente P1 se resuelva antes de las 2
horas. Digamos, por ejemplo, que una aplicación bancaria muy delicada que
permite realizar transacciones en divisas no funciona. Esta interrupción le
costará al banco una cantidad significativa de pérdidas financieras y el banco
perderá la percepción del cliente. Además, también podría enfrentar la ira del
gobierno debido a las normas regulatorias. Para garantizar que se contenga tal
escenario, una prioridad P1 con plazos estrictos permitirá que se asignen los
recursos máximos lo antes posible para resolver el incidente.
Las prioridades de incidentes y los parámetros para establecer la prioridad
son diferentes para cada cliente. Se espera que el proveedor de servicios
cumpla con los requisitos establecidos por el cliente y les cobre en
consecuencia, en función de la cantidad de recursos y activos utilizados para
cumplir con las obligaciones del servicio.
La mesa de servicio mide la urgencia y el impacto y establece la
prioridad del incidente. Las herramientas de gestión de eventos tienen la
capacidad de establecer la prioridad correcta en función de un algoritmo. A
los incidentes creados por el usuario normalmente se les asigna una
prioridad predeterminada y el grupo de resolución cambia la prioridad una
vez que comienza a resolver el incidente.
Las prioridades de los incidentes no están grabadas en piedra. Se pueden
cambiar a lo largo del ciclo de vida de un incidente. Es posible que el usuario
final haya exagerado el impacto del incidente y podría haber planteado un
incidente de mayor prioridad. Durante el proceso de resolución, el grupo de
resolución valida el impacto y la urgencia y modifica la prioridad según sea
necesario. Algunos incidentes críticos son monitoreados después de su
resolución. El período de observación podría ver la prioridad reducida hasta el
cierre.
Paso 5: Diagnóstico e Investigación

La mesa de servicio realiza el diagnóstico inicial de un incidente mediante
la comprensión de los síntomas del incidente. La mesa de servicio trata de
302
entender exactamente lo que no funciona y luego intenta llevar al usuario a
través de algunos pasos básicos de solución de problemas para resolver el
incidente. Este es un subpaso clave, ya que proporciona los puntos de datos
necesarios para una mayor investigación del incidente. Es análogo a que un
médico te pregunte sobre los síntomas que tienes: ¿Tienes dolor de
garganta? ¿Tienes tos?
¿Tienes un resfriado?
¿Te duele la cabeza? Obtienes la deriva. Asimismo, se espera que la mesa
de servicio realice una serie de preguntas para proporcionar la información
necesaria para resolver el incidente rápidamente, que es el objetivo del proceso
de gestión de incidentes.
No todas las incidencias pueden ser resueltas por el service desk. Se
escalan funcionalmente al siguiente nivel de soporte, generalmente
denominado nivel 2 o L2. El grupo L2 normalmente forma parte de un grupo
de expertos, como el grupo de servidores, el grupo de redes, el grupo de
almacenamiento o el grupo de software.
El grupo de resolución diagnostica el incidente con la información
disponible y, si es necesario, llama al usuario para obtener más información.
Es posible que la línea de preguntas de la mesa de servicio esté en el camino
equivocado, y tal vez el grupo de resolución deba comenzar de nuevo
haciendo el conjunto correcto de preguntas.
La investigación del incidente profundiza en el incidente mediante la
comprensión de uno o más de los siguientes procesos de pensamiento:
• ¿Qué espera obtener el usuario a través del incidente?
• ¿Qué ha ido mal?

• ¿Cuál es la secuencia de pasos que llevaron al incidente?
• ¿Quién se ve afectado? ¿Es localizado o global?

• ¿Hubo cambios realizados en el entorno que podrían haber
trastornado el sistema?
303
• ¿Hay algún incidente similar registrado anteriormente? ¿Hay
algún artículo de KEDB disponible para ayudar?
Paso 6: Resolución y Recuperación

Con base en la investigación, se pueden aplicar resoluciones. Por ejemplo, si
el grupo de resolución determina que un incidente en particular no está
localizado, no hay razón para que resuelva los incidentes en la PC del usuario,
sino que comienza a solucionar problemas en el servidor o la red. O tal vez
trae a los expertos que se ocupan de los problemas globales.
El éxito de la resolución cabalga sobre el camino correcto de la
investigación. Si el médico que está viendo prescribe los medicamentos
equivocados porque la línea de investigación estaba muy lejos, las
posibilidades de recuperación son casi nulas, ¿no es así?
Para incidentes que son de naturaleza generalizada (que afectan a
múltiples usuarios), una vez que se aplica la resolución, el grupo de resolución
debe realizar varias pruebas para estar absolutamente seguro de que el
incidente se ha resuelto. Por lo general, hay un período de recuperación para
observar el incidente y estar atento si algo vuelve a salir mal.
En algunas de las cuentas que he manejado en la gestión de incidentes
mayores, era una práctica habitual mantener abiertos los incidentes mayores
durante al menos una semana. Esto se hizo para observar y celebrar reuniones
diarias/horarias con las partes interesadas para tomar el pulso y controlar las
cosas que podrían salir mal.
Paso 7: Cierre del incidente

Cuando se resuelve una incidencia, es práctica habitual confirmar con el
usuario antes de cerrar el ticket de incidencia. La confirmación generalmente
la realiza la mesa de servicio, no el grupo de resolución. Entonces, el proceso
para la resolución posterior de un incidente es que el incidente se asigna a la
mesa de servicio para su confirmación y cierre.
304
Algunas organizaciones sienten que este paso agrega demasiados gastos
generales a la mesa de servicio y prefieren renunciar a esta confirmación.
Mantienen el incidente en estado resuelto durante unos tres días. Se envía un
correo electrónico al usuario informándole que el incidente se ha resuelto y,
si cree lo contrario, se espera que informe o reabra el incidente. Si no hay
respuesta dentro de los 3 días, el incidente se cerraría automáticamente. Me
gusta hacer esto y he sido un defensor del sistema de cierre automático, ya
que la confirmación puede ser autoritaria; y, desde el punto de vista de un
usuario, es irritante para el cliente recibir llamadas solo para pedir
confirmación.
Una vez que se ha cerrado un incidente, se envía una encuesta de
satisfacción del usuario solicitando comentarios sobre la puntualidad de la
resolución, la facilidad para registrar incidentes y si se mantuvo informado al
usuario sobre el estado del incidente durante todo el ciclo de vida.
Gestión de incidentes mayores

Los incidentes mayores, como su nombre indica, son incidentes de gran
impacto que tienen el potencial de causar daños irreparables a la empresa. Por
lo tanto, la gestión de servicios de ITIL sugiere que los incidentes importantes
se aborden a través de una lente diferente. Esto se puede hacer teniendo un
proceso separado, uno más estricto, por supuesto, con plazos más estrictos y
múltiples líneas de comunicación. Muchas organizaciones instituyen un
equipo separado para investigar incidentes importantes y contratan a personas
con habilidades especializadas para que estén expuestas a la presión que
hereda este trabajo.
Las personas que trabajan únicamente en incidentes mayores se
denominan administradores de incidentes mayores. Tienen todos los poderes
privilegiados para movilizar equipos y convocar a los representantes de la
dirección en cualquier momento del día (o de la noche). Dirigen el programa
cuando hay un incidente importante y se vuelven completamente responsables
de la resolución del incidente. La presión sobre ellos es inmensa y requiere
305
nervios de acero para resistir la presión del cliente, la alta dirección del
proveedor de servicios y todas las demás partes interesadas.
Una vez trabajé como administrador de incidentes importantes y no hace
mucho tiempo dirigía un equipo de administración de incidentes importantes.
El trabajo implicaba mantener el barco flotando en todo momento, y cualquier
retraso por mi parte podría poner en peligro la vida de los mineros de todo el
mundo. Durante un incidente importante, podría haber habido dos o tres
teléfonos zumbando con acción, correos electrónicos volando como dagas en
mi bandeja de entrada y cuadros de chat parpadeando y rugiendo. Fue una
buena experiencia cuando lo pienso en retrospectiva, y un momento que
atesoraré.
En una organización típica, tendrá la mesa de servicio trabajando en la
resolución de incidentes de baja prioridad. Discutiré la mesa de servicio más
adelante en este capítulo. Para rastrear, administrar y perseguir actividades
relacionadas con incidentes, hay administradores de incidentes que controlan
todas las ocurrencias. Cuando un incidente importante llega a la cola, ninguno
de estos grupos asume la responsabilidad, sino que llaman a los expertos
(gestores de incidentes importantes) para gestionar la situación. En algunos
casos, la mesa de servicio y los administradores de incidentes pueden validar
la prioridad del incidente antes de llamar a la línea de incidentes principales.
Es una buena práctica informar a todo el equipo del proveedor de servicios
y a la organización del cliente que se está produciendo un incidente
importante, para asegurarse de que todos sepan que ciertos servicios están
caídos y para evitar que los usuarios llamen a la mesa de servicio para
informar sobre el mismo incidente. . Algunas buenas prácticas a este respecto
incluyen el envío de correos electrónicos al comienzo y al final de incidentes
importantes, mensajes intermitentes en los portales de la oficina y en las
páginas de registro de tickets, y reproducir un mensaje de respuesta de voz
interactiva (IVR) cuando los usuarios llaman a la mesa de servicio.
306

servicio
Tabla 11-2. Práctica de gestión de incidentes en SVC
Actividad de
CVS
plan ninguno la actividad de planificación y la
práctica de gestión de incidentes no
necesariamente tienen que trabajar
juntas.
Diseño y Medio Durante la transición (pruebas del
transición sistema y pruebas de aceptación del
usuario), sí se producen incidencias
(según la definición que se
establezca). resolverlos rápidamente
ayudará a liberar el producto final
según el cronograma planificado.
obtener/ Medio Al igual que tener incidentes en el
construir entorno de prueba, también podrían
ocurrir en el entorno de desarrollo.
resolverlos rápidamente ayudará a
liberar el producto final según el
cronograma planificado.
comprometer alto Gran parte de la gestión de
incidentes es la comunicación a las
partes interesadas. pueden ser
clientes, usuarios o proveedores. es
una buena práctica mantener los
estados transparentes, generar
confianza con la comunidad de
partes interesadas al establecer las
expectativas correctas y obtener
confirmaciones sobre la resolución.
Entregar y alto la gestión de incidentes opera en el
apoyar espacio operativo, y la unión entre la
práctica y la cadena de valor del
servicio es significativa.
307
mejorar Medio las ideas de mejora a menudo se
generan en la parte posterior de los
incidentes. Dependiendo de la
cantidad de incidentes y su impacto,
las mejoras también se priorizan y
entregan.
Práctica de gestión de problemas
La gestión de incidentes es la primera línea de defensa para brindar un alivio
inmediato contra la interrupción de los servicios y eventuales tiempos de
inactividad. Sin embargo, de ninguna manera el proceso de gestión de
incidentes se mete en el meollo de la cuestión de poner fin a la causa detrás de
los incidentes. Su propósito es recuperar los servicios, incluso si la solución no
es permanente.
El segundo anillo de la gobernanza de procesos que garantiza la
permanencia de las soluciones es la práctica de gestión de problemas. Este es
un proceso que profundiza en la causa de los incidentes y sigue el problema
hasta la raíz, asegurando que los incidentes relacionados con la causa en
particular no se repitan.
En resumen, la práctica de gestión de incidentes se ocupa de la corrección,
mientras que la práctica de gestión de problemas se centra en la prevención.
La práctica de gestión de problemas en las prácticas de gestión de
servicios es fundamental para que el producto y el servicio prosperen. La
gestión de incidentes es buena, pero al final del día, cuantos más incidentes,
más tiempo de inactividad y más esfuerzos se requieren para recuperar los
servicios. El cliente no gana nada con el proceso, ya que intenta mantener el
soporte a flote en todo momento, pero en realidad no lo lleva a nuevos lugares.
Hay una necesidad apremiante de aportar valor a los servicios, y el valor sólo
puede generarse si se garantiza la estabilidad. Uno de los pilares para asegurar
la estabilidad del servicio es la práctica de gestión de problemas.
La práctica de gestión de problemas es de naturaleza académica. No cree
en la casualidad y no intenta (en efecto) resolver el problema del hambre en el
mundo de un solo golpe. Hay un método definido para la locura de poner
308
lápidas encima de los problemas. Represento la práctica de gestión de
problemas como la unidad de investigación de la organización proveedora de
servicios de TI.
Es posible que haya visto la popular serie de televisión CSI, donde los
crímenes se resuelven siguiendo las pistas y eliminando a los culpables. El
proceso de gestión de problemas es el CSI de la gestión de servicios de TI, y
puede comparar la gestión de incidentes con el escuadrón de policía.
Consideremos un ejemplo que involucre una aplicación que falla con
frecuencia cuando ciertas acciones se realizan simultáneamente. Se plantea un
incidente. Se diagnostica el incidente y se identifica que la resolución es
compleja. Pero la gestión de incidentes se centra en ayudar a los usuarios a
continuar con sus actividades diarias relacionadas con los servicios. Por lo
tanto, un analista de incidentes recomienda una solución mediante la cual el
usuario puede realizar acciones en la aplicación de manera secuencial en lugar
de en paralelo. El problema inmediato del usuario está resuelto, pero el
problema inminente existe. Se plantea un problema y comienza una
investigación sobre el problema. Se vuelve a crear el problema, se examina el
código base y se estudian todos los registros relevantes para depurar la causa
subyacente. La investigación vale la pena, y la causa se identifica y
posteriormente se corrige. Todas las actividades de investigación se realizan
bajo los auspicios de la gestión de problemas para identificar el problema y
encontrar una solución permanente.
Antes de continuar, quiero centrarme en el problema verbal que he usado
en esta sección. Es una palabra común en inglés pero el significado que deriva
es profundo.
ITIL Definición de Problema

Una causa, o causa potencial, de uno o más incidentes.
Hay incidentes sin resolver en los que aún no se ha determinado la

solución. La resolución de estos incidentes no es posible hasta que se conozca
la causa raíz del incidente. Sí, uno puede disparar en la oscuridad tratando de
309
hacer cien cosas, con la esperanza de que algo funcione, como reiniciar el
servidor tan pronto como el servidor se cae. Pero no siempre es tan simple. La
resolución de incidencias debe ser quirúrgica. Un problema entra en juego solo
cuando hay incidentes en los que se desconoce la causa raíz.
Esto es similar a un médico que prescribe medicamentos. Si el médico no
conoce la causa de ciertos síntomas, no podrá recetar medicamentos. Bueno,
él/ella podría adivinar, asumir y esperar que ciertos medicamentos funcionen.
Cuando no lo hacen, el médico puede recetar otro juego. A través de la gestión
de problemas, queremos evitar este comportamiento; como mencioné
anteriormente, tiene que ser quirúrgico. En la analogía médica, se debe
encontrar la causa de la enfermedad y prescribir los medicamentos correctos.
Si requiere resonancias magnéticas, análisis de sangre e hisopos, que así sea.
Lo que importa es descubrir qué está mal y encontrar una solución adecuada.
En las organizaciones de TI también, para resolver incidentes, los grupos
técnicos de resolución deben conocer la causa raíz de los problemas. Si no
conocen la causa raíz, empiezan a adivinar pidiendo a los usuarios que
reinicien las máquinas, desinstalen y reinstalen el software y otros "trucos"
que pueden suponer una pérdida de tiempo y recursos. Pero, si se aplican los
principios de la gestión de problemas y se identifica la causa raíz, la solución a
seguir será una cuestión de rutina.
Se plantea un problema cuando se desconoce la causa raíz de un incidente.
O un montón de incidentes con un hilo común no se puede resolver, ya que
aún no se ha identificado la causa raíz subyacente.
Nota la definición de un problema es algo que debe

aprender, no solo desde la perspectiva del examen de
Fundamentos de itiL, sino también para tener una mejor
base en el marco de trabajo de itiL. sin embargo, en el
examen, debe esperar ver una pregunta que le pida que
identifique la definición correcta de una lista de opciones.
310
definición palabra por palabra.
Incidentes vs Problemas
Según mi experiencia, muchos profesionales de TI en la industria de
administración de servicios de TI usan los términos incidente y problema de
manera intercambiable. Esto hace más daño que bien, especialmente si está
trabajando en una organización que toma forma después de ITIL y
especialmente si se está preparando para el examen básico de ITIL. En esta
sección, diferenciaré los dos términos con ejemplos, de modo que a medida
que avancemos hacia el proceso y otras terminologías clave, no debería haber
ninguna duda entre incidentes y problemas.
Los incidentes se generan debido a la pérdida o degradación de los
servicios. Los plantean los usuarios, el personal de TI o las herramientas de
gestión de eventos. Cuando la resolución de incidentes no es posible, porque
se desconoce la causa raíz subyacente, el equipo de TI planteará un problema.
Recuerda que los usuarios y las herramientas de gestión de eventos no
plantean problemas; en términos generales, sólo pueden venir a través del
incidente. Sin embargo, en un entorno de TI maduro, podemos configurar
herramientas de gestión de eventos para buscar patrones específicos de
eventos y, posteriormente, plantear problemas. Pero mantengamos esta
discusión fuera del alcance y restrinjamos los problemas para que se deriven
solo de los incidentes.
Consideremos el ejemplo de una aplicación de software que falla cuando
se inicia. El usuario plantea un incidente para solucionar este problema. El
equipo de resolución de software intenta iniciar la aplicación en modo seguro,
desinstala y vuelve a instalar la aplicación y, finalmente, realiza cambios en el
registro del sistema operativo, sin éxito. Cuando todas las esperanzas fallan,
brindan un aviso para la gestión del problema para encontrar la causa raíz y
brindar una solución permanente.
311
La práctica de gestión de problemas, con la ayuda de expertos en el grupo
de arquitectura de software, depura la carga de la aplicación y ejecuta una
serie de pruebas para encontrar los desencadenantes y las chispas del bloqueo.
Descubren que la causa raíz del bloqueo se debe a un conflicto con un
controlador de dispositivo de hardware. Recomiendan una solución para
desinstalar el controlador del dispositivo de hardware y actualizarlo con el
controlador más reciente. La recomendación funciona de maravilla, y la
aplicación de software que solía fallar se carga muy bien sin ningún problema.
Esta es la práctica de gestión de problemas en acción, trabajando en
problemas difíciles que pueden causar daños irreparables a la organización del
cliente si no se abordan a tiempo.
Otras terminologías clave en el

problema
Gestión
La gestión de problemas es profunda y el proceso trae una cierta complejidad
a la mesa. La complejidad comienza con algunos términos que se usan con
bastante frecuencia durante varias etapas de las actividades del proceso. Es
importante que comprenda toda la terminología que propongo aquí. Le ayuda
a usar mejores términos en el trabajo y definitivamente acumula algunas
respuestas correctas más en el examen de Fundamentos de ITIL.
Causa principal
La causa raíz es la razón fundamental por la que ocurre un incidente. Digamos
que estás en un banco y el cajero automático no desembolsa el dinero que
solicitaste. La causa subyacente o la causa raíz de la denegación de servicio en
este caso se atribuye a una falla en la red del banco. Para cada incidente, habrá
una causa raíz.
Solo cuando identifique la causa raíz podrá resolver el incidente. En la
instancia de cajero automático, a menos que sepa de la falla de la red, no
puede recuperar el servicio de cajero automático.
312
Análisis de raíz de la causa
Identificar la causa raíz de un incidente no es una tarea menor. A veces, la
causa raíz puede revelarse por sí misma, pero muchas veces será un desafío
identificar las causas raíz de incidentes complejos. Debe analizar la causa raíz
mediante el uso de técnicas que comúnmente se incluyen en la actividad
llamada análisis de causa raíz (RCA).
Recuerde que es posible que el resultado de RCA no siempre resulte en la
identificación de la causa raíz de un incidente. En tales casos, la RCA debe
realizarse utilizando técnicas complejas y con expertos pertenecientes a
campos relacionados de tecnología y gestión.
error conocido
Incluso cuando el resultado del procedimiento RCA arroja resultados y se
conoce la causa raíz, es posible que no siempre sea posible implementar una
solución permanente. En su lugar, se identifican arreglos temporales llamados
soluciones alternativas. Los casos en los que se conocen las causas principales,
junto con las soluciones alternativas, se denominan errores conocidos.
Definición ITIL de error conocido

Un problema que ha sido analizado pero no ha sido resuelto.
Puede haber varias razones por las que las soluciones no se pueden
implementar.
Por lo general, las soluciones permanentes tienen un precio elevado. La
mayoría de las organizaciones son conscientes de los precios en estos días y
es posible que no aprueben el gasto excesivo. Otras razones podrían incluir
la falta de expertos o recursos humanos para implementar la solución
permanente, o controles de gobernanza o legislación que podrían impedir la
implementación.
313
Nota la definición de un error conocido es
importante desde el punto de vista del examen itiL
Foundation. sin embargo, en el examen, debe esperar ver
una pregunta que le pida que identifique la definición
correcta de una lista de opciones. por lo tanto, es
prudente que comprenda y memorice la definición palabra
por palabra.
Base de datos de errores conocidos

Los errores conocidos se documentan y almacenan en un repositorio
denominado base de datos de errores conocidos (KEDB). La KEDB consta de
varios errores conocidos, sus causas raíz identificadas y las soluciones
alternativas que se pueden aplicar. Los registros de errores conocidos no son
miembros permanentes de una KEDB. Los errores conocidos dejarán de
existir en este repositorio cuando se implemente la solución permanente.
Solución alterna
Como mencioné, las soluciones alternativas son arreglos para resolver
incidentes temporalmente. Cada incidente puede tener una o varias soluciones
alternativas, pero ninguna de ellas aliviará el problema de forma permanente y
puede ser necesario revisar la solución alternativa aplicada periódicamente.
Definición ITIL de solución temporal

Una solución que reduce o elimina el impacto de un
incidente o problema para el cual aún no se dispone de una
resolución completa. Algunas soluciones alternativas
reducen la probabilidad de incidentes.
Por ejemplo, digamos que una impresora en su piso no funciona y no

puede esperar hasta que el técnico pueda llegar a ella. Una solución alternativa
314
clásica, en este caso, es imprimir desde una impresora en un piso diferente. La
solución alternativa resolverá su problema temporalmente al proporcionar una
salida, pero puede que no sea una solución permanente porque puede resultarle
inconveniente correr al siguiente piso cada vez. Otra solución podría ser que
no imprima el documento, sino que envíe la copia impresa al destinatario
previsto.
Existe una solución alternativa para proporcionar un alivio inmediato o
intermedio de la interrupción del servicio. En algunos casos, si no se encuentra
una solución permanente (debido a razones técnicas o financieras, etc.),
entonces la solución podría considerarse como una solución final.
Solución permanente
Cuando se conoce la causa raíz de un problema, la actividad de
seguimiento en el proceso de gestión de problemas es identificar una
solución permanente. Esta solución resuelve el problema de forma
permanente, contribuye a reducir el número de incidentes y evita futuras
interrupciones.
Como mencioné anteriormente, las soluciones permanentes tienen un
costo y es posible que las organizaciones no siempre estén dispuestas a
desembolsar el capital requerido. En tales casos, las soluciones permanentes se
conocen pero no se implementan.
315
Capítulo 11
Fases de gestión de problemas

El proceso de gestión de problemas se compone de tres fases que impulsan sus
objetivos. Se indican en la Figura 11-4 :
• Problema de identificación
• control de problemas
• control de errores
Figura 11-4. Fases de gestión de problemas
Problema de identificación
El primer paso lógico en las fases de gestión de problemas es identificar el
problema. Identificarlo no es simple ni directo. Recuerde que normalmente habrá
cientos y miles de incidentes para una organización de tamaño decente. Tamizar a
través de él para un problema va a ser un desafío a menos que las reglas de
compromiso estén bien definidas. Aquí hay algunos, y la lista no es exhaustiva:
• Los registros de incidentes deben analizarse regularmente para

identificar elementos comunes, como incidentes similares,
como fallas ocasionales del navegador Chrome, o podría ser un
CI en particular que se está descomponiendo varias veces.
316
• A través del análisis de tendencias de los incidentes, se pueden
identificar los incidentes repetitivos y los usuarios y el personal
de TI también pueden proporcionar la información.
• Los proveedores y otros terceros también podrían proporcionar
información sobre los problemas.
• El proceso de gestión de problemas podría solucionar todos los

incidentes importantes para garantizar que tales incidentes no
vuelvan a ocurrir.
• Durante el ciclo de desarrollo, los errores no resueltos podrían
transformarse en problemas durante las operaciones; el plomo
puede ser proporcionado por probadores y desarrolladores.
• Para los productos COTS, el editor de software podría

proporcionar la lista de posibles problemas.
control de problemas
El control de problemas generalmente analiza el problema identificado y encuentra
su causa raíz y una solución permanente si es posible. Si hay un puñado de
problemas, entonces tal vez se puedan analizar todos los problemas. Si son varios,
se realiza una actividad de priorización para enfrentar los problemas entre sí en el
orden de impacto y su probabilidad, que no es más que el riesgo que representa.
Los problemas más riesgosos se analizan para identificar la causa raíz.
Empleamos algunas técnicas para llegar a la raíz del problema. Algunas
técnicas son:
Lluvia de ideas
La técnica que se ha usado, mal usado y subutilizado a veces
es el poder de usar nuestro cerebro para enfocarnos en áreas
de investigación. La técnica de lluvia de ideas implica un
pensamiento concentrado sin inhibiciones.
317
En la técnica de lluvia de ideas, no hay malos pensamientos. Cada pensamiento
debe sopesarse, y luego se debe tomar una decisión. En otras palabras, las ideas no
se etiquetan como absurdas ni se burlan de ellas; todo se acepta, examina y luego
se actúa en base a los resultados del examen. Permítanme explicar la lluvia de
ideas en forma de ejemplo. Si el pensar es un carro, entonces en este carro le quito
los frenos porque no quiero que el pensar se detenga o sea impedido. No debe
haber ninguna acción tomada para detener el flujo de pensamientos. Solo uso el
volante para dirigir mis pensamientos hacia la meta que quiero lograr. Cuanto más
pensando, con la dirección correcta, más cerca estaré de mi destino.
La lluvia de ideas se puede hacer solo o en grupo. Cuantos más, mejor, ¿verdad?
No siempre. Es posible que a través de las sesiones grupales de lluvia de ideas los
pensamientos claros en su mente se desenfoquen, por lo que la lluvia de ideas
grupal debe realizarse con precaución y con un proceso para mantenerla dentro de
un marco. Osborn dice en su libro que las sesiones grupales de lluvia de ideas son
más efectivas que las individuales, ya que cree firmemente que la cantidad genera
calidad. La suposición es que un mayor número de ideas generadas proporciona
una mejor probabilidad de encontrar oro.
Técnica de los cinco por qué

Una de las técnicas más utilizadas y mal utilizadas en el proceso de gestión de
problemas es la técnica de los cinco por qué. Se utiliza durante la investigación de
un problema, específicamente durante la etapa de determinación de la causa raíz.
La técnica se enseña y se vuelve a enseñar con tanta frecuencia al personal de
gestión de problemas que se ha convertido en un estándar de facto en la actividad
del análisis de causa raíz.
318
La técnica de los cinco por qué implica hacer la pregunta "¿por

qué?" al problema en cuestión cinco veces para llegar a la causa
raíz. Fue concebido por el industrial japonés Sakichi Toyoda, el
fundador de Toyota
Industries en 1930. Pero no fue hasta que el Sistema de Producción
de Toyota se hizo popular que la técnica se generalizó en la década
de 1970. El principio de la técnica se basa en estar sobre el terreno
para averiguar las razones en lugar de estar en la comodidad de una
oficina con aire acondicionado (una filosofía de "ir y ver").
La parte que hace que la técnica sea popular es que es

extremadamente simple de usar y lleva poco tiempo procesarla y
ejecutarla. La figura 11-5 es una ilustración del uso de la técnica de
los cinco por qué para identificar la causa raíz del problema.
Revised Problem Statement: 17% on-time

flight arrivals for flights departing form the
Kempegowda International Airport
Problem: Low
percentage of on-time
flight arrivals Why are the Departures
flights delayed? are delayed
Why are departures
delayed?
Baggage Some
Check-in takes passengers
Significant Why are passengers arrive beyond
Time cut-off tim
e
generally late?
Why does baggage

Limited check-in take more time?
counters for Budget cuts
checkingin
Why are there limited

counters?
Figura 11-5. Ilustración de la técnica de los cinco por qué
319
Ishikawa
Un diagrama de Ishikawa se conoce con varios nombres, como diagrama de
espina de pescado, diagrama de fishikawa y diagrama de espina de pescado,
entre otros. El diagrama consta de una columna central que representa el
problema. Varias ramas sobresalen de la columna vertebral para indicar
posibles causas. La disposición de la columna vertebral y las ramas parece una
espina de pescado.
Las causas no son arbitrarias, como se explica en la técnica de los cinco por
qué. Hay un método para la locura en el proceso de Ishikawa de la causa
raíz de la determinación. Cada rama está designada para una categoría de
causa, y el pensamiento detrás de esto es seguir la categoría principal para
determinar la causa raíz. Uno de los modelos de espina de pescado
populares utilizados en la industria manufacturera se llama modelo 6M. Las
seis categorías de causas que se modelan son las siguientes:
• Material : causas relacionadas con el material utilizado en el proceso de

fabricación.
• Método : el proceso
• Máquina : la maquinaria real, la tecnología, etc.

• Madre naturaleza : el medio ambiente
• Medición : las técnicas de medición empleadas para obtener métricas
• Hombre : las personas involucradas
También hay otros modelos, dependiendo del tipo de industria. La

figura 11-6 es una ilustración de la técnica de Ishikawa.
320
Figura 11-6. Ilustración de la técnica de Ishikawa
El resultado de cualquiera de las técnicas podría dar lugar a las

siguientes opciones:
• Sin causa raíz

• Causa raíz y solución permanente conocida
• Causa raíz conocida pero sin solución permanente

Si no se determina la causa raíz, entonces la técnica debe
modificarse y reprocesarse para identificar la causa raíz.
Cuando se conocen la causa raíz y la solución permanente,
entonces se debe determinar si la solución permanente debe
implementarse o no. Una serie de factores podrían influir:
riesgo comercial, colateral, etc. Si se conoce la causa raíz pero
no la solución permanente, lo mejor que se puede hacer es
identificar una solución alternativa que mantendrá el fuerte
hasta que llegue la caballería (solución permanente) .
321
control de errores
Aparece un error o un error conocido si no se implementa una solución
permanente a un problema. Como mencioné anteriormente, podría haber
varias razones por las que no se implementa una solución permanente: es
posible que aún no se haya determinado técnicamente, que sea
comercialmente inviable o que los riesgos colaterales superen los beneficios.
La gestión de errores se realiza a través de una KEDB. El ejercicio implica
evaluaciones periódicas del error conocido para identificar posibles soluciones
permanentes y garantizar que los errores conocidos se socialicen bien con la
comunidad de usuarios y personal de TI. La evaluación se realiza sobre la
base del impacto para los clientes, el costo de implementar una solución
permanente, la eficacia de la solución permanente y la eficacia de las
soluciones alternativas identificadas.

servicio
Tabla 11-3. Práctica de gestión de problemas en SVC
Actividad de
CVS
plan ninguno la actividad de planificación y la
práctica de gestión de problemas no
necesariamente tienen que trabajar
juntas.
Diseño y Bajo Las entradas de gestión de problemas
transición se pueden utilizar durante las pruebas
y las actividades de transferencia de
conocimientos durante las
transiciones.
obtener/ Bajo el resultado de la gestión de
construir problemas puede conducir a la
322
detección de defectos del producto,
que se retroalimenta a la actividad de
obtención/construcción para
proporcionar las correcciones.
comprometer Medio los problemas son menores, pero es
posible que no se limiten solo a la
comunidad de TI. Los problemas de
larga data podrían hacerse visibles
para los clientes y usuarios finales a
quienes les gustaría ser parte del
proceso de resolución de problemas.
el proveedor también puede estar
involucrado si el problema puede ser
causado por él o si tiene un papel que
desempeñar en su resolución.
Entregar y alto la gestión de problemas tiene el juego
apoyar más importante en la actividad
Entrega y soporte, a través de las
actividades que involucran la
reducción de incidentes y la
resolución de problemas.
mejorar alto la gestión de problemas es la otra
cara de la actividad de mejora. Tanto
la actividad de mejora como la
práctica de gestión de problemas se
establecen para hacer que el
producto/servicio sea más estable y
libre de incidentes (léase reducción de
incidentes).
11-1. ¿ Cuál de las siguientes es la definición de evento

correcta?
A. Cualquier cambio de estado que sea significativo para un servicio o
producto o CI relacionado
323
B. Cualquier cambio de estado que desencadene cambios en los otros
procesos operativos.
C. Cualquier cambio de estado para los CI que correlacione riesgos y
problemas con el servicio y los procesos de gestión del servicio.
D. Cualquier cambio de estado que tenga importancia para la gestión de un
servicio u otro CI
11-2. ¿Cuál de las siguientes es la definición correcta de
incidente ?
A. Un problema que ha sido analizado pero no ha sido resuelto

B. Las interrupciones de un servicio se denominan incidentes.
C. Una interrupción no planificada de un servicio o una reducción en la

calidad de un servicio
D. Un método para superar un problema o limitación en un programa o
sistema.
11-3. ¿Qué tipo de herramienta se debe utilizar para registrar incidentes?

A. Herramienta especializada en el registro de incidencias, que lleva atributos
como resumen de incidencias, descripción de incidencias, prioridad,
categoría, etc. Además, debe haber espacio para la personalización de los
campos.
B. Una herramienta que brinda acceso a todo el personal de TI, los usuarios y
la mesa de servicio y que está disponible bajo demanda
C. Una herramienta que proporciona enlaces a CI, problemas y errores

conocidos
D. Una herramienta que se puede utilizar para la autorreparación de
incidentes y que puede proporcionar una resolución rápida
324
11-4. ¿Cuál es la diferencia entre un problema y un error
conocido?
A. Se crean problemas para identificar la causa raíz de los incidentes; Los
errores conocidos se crean cuando se conoce la causa raíz de un incidente
pero aún no se ha implementado una solución permanente.
B. Se crean problemas para identificar la causa raíz de los incidentes; los

errores conocidos se crean para identificar los errores del producto que se
liberan del ciclo de desarrollo.
C. Los problemas se crean para identificar una solución permanente a un
incidente; los errores conocidos se crean cuando aún no se ha
implementado la solución permanente a un incidente.
D. Los problemas se crean para identificar una solución permanente a un

incidente; los errores conocidos se crean para rastrear e identificar errores
de productos que provienen del ciclo de desarrollo.
11-5. ¿Cuál de estas no es una técnica válida de identificación de
problemas?
A. Realización de análisis de tendencias de incidentes.

B. En la parte posterior de un incidente importante
C. Análisis de cinco por qué

D. Analizando problemas recurrentes
11-6. ¿ Cuál de las actividades es una actividad de control de errores

válida?
A. Aplicación de soluciones alternativas a incidentes
B. Identificación de solución permanente

C. Análisis de la causa raíz de los errores conocidos
D. Analizando problemas recurrentes
325
DÍA 6

El día 6 estudiamos las prácticas que gestionan los cambios en los servicios:
gestión de solicitudes de servicio y gestión de cambios. También profundizamos en
las prácticas de lanzamiento e implementación que siguen a las prácticas de gestión
de cambios.
CAPÍTULO 12
Prácticas a
Administrar
cambios
Si bien las operaciones mantienen los servicios a flote y mantienen el statu quo,
para que un servicio o un producto se mantenga vivo, apenas sobrevivir está
lejos de ser suficiente. Necesita cambiar, necesita evolucionar y necesita
transformarse. Sin cambios, un servicio o un producto está prácticamente
muerto. Piense en un servicio o producto que se ha mantenido igual durante
varios años. Difícil, ¿verdad? ¿Imposible nombrar una pareja? Sí, eso es
verdad. Incluso un producto simple como los dulces del día a día cambia porque
los clientes se aburren y anhelan algo nuevo. Piensa en los avatares de Haribo o
cualquiera de tus chocolates favoritos. Muy pocos se han mantenido igual y
mantienen el cambio constante. Otra anomalía en este sentido es la coca cola
“clásica”. Aunque lo viejo dio paso a lo nuevo, la demanda popular significó
que la empresa tuvo que recuperar la fórmula anterior para revivir la fortuna de
la empresa.
Volviendo a los productos y servicios de TI, las anomalías rara vez se
extinguen. Cada producto o servicio puede sobrevivir introduciendo mejoras y
haciéndolo mejor con cada lanzamiento. Pero traer lo nuevo y desechar lo viejo no
se puede hacer como desechamos nuestros viejos televisores. Se necesitan
principios, procesos, prácticas y procedimientos para que esto suceda. Después de
todo, habrá varios usuarios que estén acostumbrados a usar los productos y
servicios de cierta manera, y el cambio para ellos será doloroso. No sólo desde la
perspectiva del usuario, cambiando

6361-7_12
CAPÍTULO 12 PRÁCTICAS PARA LA GESTIÓN DE CAMBIOS
un servicio debe garantizar que la interrupción del cambio sea nula o mínima.
Aunque el deseo de cambiar es alto en el índice de requisitos, el apetito por asumir
riesgos con los tiempos de actividad y la disponibilidad del servicio es bastante
bajo. Por lo tanto, necesitamos que ITIL proporcione un paso seguro para que los
cambios se realicen de la manera menos disruptiva, y aquí tiene: este capítulo trata
sobre las prácticas que gestionan el cambio.
Este capítulo cubre dos prácticas:
• Gestión de solicitudes de servicio

• Cambio de control
En ambas prácticas, profundizaremos para comprender sus matices, y la

expectativa es que domines bien ambas prácticas. Desde la perspectiva de su
carrera, estas prácticas son invaluables, especialmente el control de cambios. Se
considera equivalente a la práctica de incidentes, y los entrevistadores que evalúan
su conocimiento de ITIL pueden comenzar en la gestión de incidentes, pero
pasarán o terminarán en la práctica de control de cambios.
Consejo de examen Las prácticas para la gestión de

cambios son un tema importante desde la perspectiva del
examen de Fundamentos de ITIL. Si necesita responder
preguntas correctamente, necesita más que una comprensión
superficial de los temas. Puede esperar que aparezcan entre
siete y ocho preguntas en este capítulo.
Gestión de solicitudes de servicio
La gestión de solicitudes de servicio es una práctica menor en el marco de ITIL y,
a menudo, se confunde con el proceso de gestión de incidentes. Antes de entrar en
el lío de esta confusión, consideremos la definición de la práctica de gestión de
solicitudes de servicio.
CAPÍTULO 12 PRÁCTICAS PARA LA
GESTIÓN DE CAMBIOS
Definición de ITIL de práctica de gestión de solicitudes de servicio
El propósito de la práctica de gestión de solicitudes de servicio es
respaldar la calidad acordada de un servicio al manejar todas las
solicitudes de servicio predefinidas iniciadas por el usuario de
una manera efectiva y fácil de usar.
La práctica de gestión de solicitudes de servicio existe para garantizar que las
solicitudes de servicio se cumplan en función de los niveles de servicio acordados
y que las solicitudes de servicio en sí estén bien definidas. El término solicitud de
servicio se utiliza en varias industrias; generalmente significa llevar a cabo una
actividad que está predefinida. Es pertinente entender qué se entiende por
solicitud de servicio.
Definición ITIL de una solicitud de servicio
Una solicitud de un usuario o del representante autorizado de un
usuario que inicia una acción de servicio que se ha acordado
como parte normal de la prestación del servicio.
Las solicitudes de servicio son entregas predefinidas que se acuerdan con los
clientes. Pueden ser solicitados por los usuarios o sus delegados. Una solicitud de
servicio no es una queja que registra cuando un servicio no funciona. Aunque se
trata de una parte de un servicio, no está relacionado con la caída de un servicio
parcial o completo. Los ejemplos proporcionarán una comprensión bastante buena
de lo que estoy hablando:
• Un cliente puede llamar a un banco o utilizar un sistema bancario
en línea para solicitar una chequera. El agotamiento de la chequera
anterior no se considera como falta de servicio. Solicitar uno
nuevo es una entrega acordada y se realiza según el conjunto
predefinido de actividades y los plazos predefinidos.
• Puede llamar a la mesa de servicio de su empresa y solicitar que se

instale un software de código abierto en su computadora portátil.
328
GESTIÓN DE CAMBIOS
La instalación de software es un servicio, y como usuario tienes
derecho a solicitarlo. Asimismo, solicitar un ordenador portátil, un
teléfono móvil o un monitor son ejemplos de solicitudes de
servicio.
• Suponga que necesita acceso a un portal; plantea una solicitud
para obtener el acceso necesario. Este es un ejemplo de una
solicitud de servicio también. Estás buscando algo que no tienes, y
estás pidiendo algo que ya está definido y a lo que tienes derecho.
• Si no supiera cómo llegar a la estación de tren, podría llamar a las

personas interesadas y pedir información (direcciones en este
caso). La solicitud de información es otro ejemplo de una solicitud
de servicio. La información puede ser cualquier cosa que entre en
el ámbito de los servicios ofrecidos.
• Finalmente, los elogios, quejas y comentarios proporcionados por
los servicios ofrecidos o las personas involucradas en ofrecerlos
también se incluyen en la definición de solicitud de servicio.
Nota La práctica de gestión de solicitudes de servicio se

denominó gestión de cumplimiento de solicitudes en ITIL V3.
De hecho, en ITIL V2 se le llamó gestión de solicitudes de
servicio. En mi opinión, llamarlo cumplimiento de solicitudes
no fue muy bien con las empresas, los usuarios y los
profesionales, ya que la norma es que la gestión de
incidentes se realiza a través de incidentes y la gestión de
cambios se realiza a través del control de cambios. Entonces,
¿por qué no la gestión de solicitudes de servicio para
administrar las solicitudes de servicio?
329
GESTIÓN DE CAMBIOS
Catálogo de Servicios y la
Confusión con Incidentes
Las solicitudes de servicio tienen que ser predefinidas. Un usuario no puede
solicitar algo que no ha sido definido. No pueden llamar a la mesa de servicio y
decir: "Quiero que reserve un taxi". Si no se define reservar un taxi, entonces el
equipo responsable de cumplir con las solicitudes de servicio no cumplirá con la
solicitud.
¿Cómo sabe un usuario lo que puede o no puede solicitar? Todas las
solicitudes de servicio acordadas y definidas forman parte de un catálogo de
servicios. En términos generales, el catálogo de servicios debe socializarse con la
comunidad de usuarios para que conozcan los servicios de los que pueden
disponer.
Hubo un tiempo en que los incidentes y las solicitudes de servicio se ponían
en el mismo cubo y se trataban de manera similar. Digo esto como si esta práctica
ya no sucediera, lo cual no es cierto. Todavía lo hace, pero ahora se entienden
mejor los dos conjuntos de tickets para definir procesos separados y
administrarlos por separado a través de sus respectivos procesos.
Al agrupar los incidentes y las solicitudes de servicio, la organización
proveedora de servicios está cometiendo una grave injusticia con quienes han
planteado incidentes, porque los incidentes se relacionan con la pérdida del
servicio. Y como hemos establecido, las solicitudes de servicio no son pérdida de
servicio, sino obtener algo adicional a lo que ya tienen los usuarios.
El problema de tratar los incidentes y las solicitudes de servicio de la misma
manera es que el tiempo necesario para resolver los incidentes aumentará. Eso
conduce a un tiempo de inactividad adicional y, en general, una pérdida de
servicio conduce a una pérdida de productividad y, por lo tanto, a pérdidas
financieras. Las implicaciones de una solicitud de servicio no están en la misma
escala. Por lo tanto, agrupar a los dos y no diferenciarlos conduce a un mayor
tiempo de inactividad del servicio y a usuarios insatisfechos, e introduce
ineficiencias en el sistema que es mejor evitar.
330
GESTIÓN DE CAMBIOS
Nota Existe una práctica denominada gestión del

catálogo de servicios, que profundiza en los procesos y
matices de la definición y gestión del catálogo de servicios.
sin embargo, la práctica está fuera del alcance de ITIL
Foundation.
Cumplimiento de Solicitudes de Servicio

Todas las solicitudes de servicio están predefinidas. En un escenario ideal, todas
las solicitudes de servicio se enumeran para que los usuarios las vean.
Simplemente pueden ingresar, seleccionar lo que necesitan y enviarlo. Para cada
solicitud de servicio, los pasos necesarios para cumplirla son bien conocidos,
definidos, documentados y se ha comprobado que funcionan. Como están
predefinidos, es mucho más fácil y sencillo formalizarlos con procedimientos
operativos estándar para iniciar solicitudes de servicio, obtener aprobaciones y
cumplirlas.
Considere la ilustración que he presentado en la figura 12-1 . En este ejemplo,
el catálogo de servicios consta de tres solicitudes de servicio:
1. Solicitud de una computadora portátil

2. Solicitud de instalación de software de código abierto
3. Solicitud de carta de experiencia al departamento de RRHH.
331
GESTIÓN DE CAMBIOS
Figura 12-1. Cumplimiento de solicitudes de servicio.
Cada una de las solicitudes de servicio en este ejemplo sigue una ruta
separada. La solicitud de computadora portátil tiene la mayoría de los pasos, ya
que cada solicitud planteada requiere la aprobación de un gerente y la siguiente
aprobación que se busca es una aprobación financiera. Una vez que el jefe de
finanzas borra la parte financiera de la solicitud, la solicitud pasa al equipo que
asigna una computadora portátil al usuario.
En la siguiente solicitud de servicio, el software de fuente abierta aprobado
por una empresa para la instalación general por parte de sus usuarios no requiere
aprobaciones; de hecho, no requiere ningún ser humano para cumplirlo. Tan
pronto como el usuario lo solicita, se instala automáticamente a través de scripts y
software preconfigurados que envían el software a las PC.
332
GESTIÓN DE CAMBIOS
En el tercer ejemplo, un empleado solicita una carta de experiencia de la
empresa. El gerente valida los detalles presentados por el empleado y
proporciona la aprobación. La solicitud fluye al departamento de recursos
humanos, que la cumple. Alternativamente, el software podría estar detrás de
la solicitud de servicio que puede redactar y entregar automáticamente la carta
de experiencia después de la aprobación.
En cada uno de estos ejemplos, quería resaltar que el flujo es diferente y
que los equipos que están involucrados en el cumplimiento probablemente
también sean distintos. Por lo tanto, cada una de estas solicitudes de servicio
tendría un procedimiento operativo estándar escrito, junto con instrucciones
claras sobre lo que se debe hacer en cada paso.
Por lo general, es mejor iniciar solicitudes de servicio a través de un portal
donde el usuario puede autenticarse y acceder a las solicitudes de servicio que
están disponibles. Para identificar a un gerente para la aprobación, los sistemas
generalmente acceden a la base de datos de recursos humanos o una base de
datos equivalente que almacena la jerarquía de los empleados. Los equipos de
cumplimiento y aprobación financiera se identifican según las unidades de
negocio y el tipo de cumplimiento que busca la solicitud.
Nota Las solicitudes de servicio son una forma de

cambios estándar: los cambios estándar destinados a
dar servicio a la comunidad de usuarios. Por ejemplo, un
cambio estándar para instalar un parche de seguridad en
un servidor generalmente se clasifica como un cambio
estándar y una instalación de software en una
computadora portátil como una solicitud de servicio. En
principio, ambos siguen el mismo conjunto de pautas:
predefinidas, bien conocidas y de impacto casi nulo.
333
GESTIÓN DE CAMBIOS
Directrices para la implementación

La gestión de solicitudes de servicio está destinada a ser un proceso que
directo. Las incógnitas son casi nulas, y una práctica madura garantiza que los
procesos involucrados se simplifiquen y socialicen con el usuario y la
comunidad de cumplimiento. Hay algunas pautas que se definen para
garantizar que la práctica de gestión de solicitudes de servicio sea fluida,
eficiente y efectiva:
1. Se debe trazar un límite claro a través de las políticas

aplicables que definan la extensión y amplitud de las
solicitudes de servicio. En otras palabras, no debe haber
confusión sobre qué califica como una solicitud de
servicio, qué es un incidente y qué es un cambio.
2. Cada solicitud de servicio debe estar definida y no se
deben tomar atajos durante la fase de definiciones.
3. El catálogo de servicios debe estar disponible para todos

los usuarios, preferiblemente en un portal para que los
usuarios puedan elegir. Para cada una de las solicitudes de
servicio se deben definir los niveles de servicio asociados
a la misma, así como el número de saltos (aprobaciones,
etc.) que están involucrados.
4. Los flujos de solicitud de servicio deben estandarizarse
tanto como sea posible, a menos que ciertas solicitudes de
servicio requieran flujos especiales. Por ejemplo, la
mayoría de las solicitudes de servicio deben enrutarse al
gerente inmediato para su aprobación y no seleccionar y
elegir gerentes, según el tipo de solicitud de servicio.
5. Debe haber un intento consciente y sincero de

automatizar todas las solicitudes de servicio que no
requieran intervención humana. El ejemplo que compartí
334
GESTIÓN DE CAMBIOS
anteriormente de una carta de experiencia es un excelente
candidato para la automatización.
6. La práctica de solicitud de servicio debe estar dentro del
ámbito de la actividad Mejorar, donde se pueden
introducir mejoras para aumentar la eficacia y la
eficiencia de la práctica.

servicio
Tabla 12-1. Gestión de solicitudes de servicio en SVC
Actividad de
CVS
Plan ninguno No existe vinculación de la práctica
en la actividad del plan, debido a su
naturaleza transaccional y operativa.
Diseño y Medio Durante la transición, ciertos activos

Transición de servicio podrían pasar a
producción en el reverso de una
solicitud de servicio.
obtener/construir Medio los activos de servicio y los
componentes para los entornos
inferiores podrían obtenerse a través
de la práctica de gestión de
comprometer alto Hay mucha interacción entre la
práctica y la comunidad de usuarios
para establecer expectativas y
garantizar la transparencia de los
saltos y las aprobaciones.
Entregar y alto una buena parte de la prestación de
apoyar servicios proviene de la práctica de
gestión de solicitudes de servicio. El
335
GESTIÓN DE CAMBIOS
cumplimiento de las solicitudes de
servicio es parte inherente de esta
actividad.
Mejorar Bajo Si bien la gestión de solicitudes de
servicio en sí misma puede pasar
por el churner de Mejorar, la
práctica es un medio para que los
usuarios se comuniquen para
compartir complementos, quejas e
ideas de mejora.
Muchos de estos podrían ser insumos
para la actividad Mejorar.
Práctica de control de cambios
Dicen que el cambio es la única constante. También dicen que todo lo que no
crece se marchita. Esto es tan cierto en la industria de TI. No importa qué tan
antiguo sea el producto o el servicio, los cambios ocurren todo el tiempo. No
importa cuán heredado sea el servicio, aún debe mantenerse y actualizarse
según las necesidades de la organización.
Los cambios son inevitables en cualquier industria; por lo tanto, la
responsabilidad recae en la administración. La pregunta no es si hacemos
cambios o no, sino cómo lo hacemos sin impactar negativamente en el
producto o servicio.
También es cierto que la mayoría de las incidencias se producen por una
mala gestión de los cambios. Por lo tanto, esa es una razón más por la que
necesitamos reforzar el proceso de gestión de cambios para aumentar el
tiempo de actividad general y reducir la cantidad de interrupciones.
La palabra cambio significa bastantes cosas en varios contextos; podría ser
cambiar de estación, cambiarse de ropa o hacer cambios en la tapicería de los
muebles. Desde la perspectiva de ITIL, un cambio gira en torno a los servicios
y se refiere a los cambios en todas las cosas que componen un servicio.
336
GESTIÓN DE CAMBIOS
ITIL Definición de Cambio
La adición, modificación o eliminación de cualquier cosa que
pueda tener un efecto directo o indirecto en los servicios.
Un servicio se compone de varios componentes individuales; podrían
ser servidores, conmutadores, software, middleware, aplicaciones móviles
y redes. Los cambios realizados en cualquiera de estos componentes
individuales o en el servicio general en sí constituyen un cambio.
Nota El control de cambios es un tema popular en el

examen básico. Probablemente debería ver una pregunta
relacionada con la definición de un cambio que aparece en
el examen básico de ITIL. La pregunta se centrará en
identificar la definición correcta de una lista de opciones.
definición al pie de la letra.
Estos son algunos ejemplos de cambios:

• Implementación del servicio de Internet por fibra óptica a la
organización del cliente
• Transición de los servicios de correo electrónico de Exchange a

Gmail
• Desmantelamiento de computadoras centrales
• Adición de memoria adicional a los servidores

• Cambiar la propiedad de un conmutador central
• Agregar una IP a una lista negra en el firewall
• Modificación de un trabajo por lotes
337
GESTIÓN DE CAMBIOS
• Lanzamiento de una nueva versión de una aplicación para iPhone
• Actualización de una aplicación empresarial
Luego, hay otras capas que componen un servicio, ya sean procesos,

gobierno, capacidad o personal de TI, entre otros. Cambiar cualquiera de estos
aspectos afecta indirectamente a un servicio, por lo que en principio pueden
considerarse cambios; pero la mayoría de las organizaciones no los consideran
como cambios, o gestionan estos cambios por separado.
Definición ITIL de práctica de control de cambios
El propósito de la práctica de control de cambios es maximizar
la cantidad de cambios exitosos de servicios y productos al
garantizar que los riesgos se hayan evaluado correctamente,
autorizando cambios para proceder y administrando el
cronograma de cambios.
La práctica de control de cambios existe únicamente para regir los
cambios en los productos y servicios. El objetivo de la gobernanza es
garantizar que los cambios que se produzcan se examinen minuciosamente
para garantizar que se conozcan y mitiguen todos los riesgos, y para aumentar
la probabilidad de que los cambios tengan éxito.
En TI como en la vida, nada está garantizado. Entonces, cualquier cambio
propuesto viene con riesgos asociados. Si una organización teme el efecto de
los riesgos y detiene los cambios en seco, entonces esa organización no
mejorará sus productos y servicios y está condenada al fracaso. Por lo tanto,
los cambios son males necesarios, y el arte del control de cambios consiste en
controlar los cambios para garantizar que los aspectos beneficiosos se
amplifiquen mientras se minimizan los riesgos mediante acciones de
mitigación adecuadas.
Por ejemplo, la aplicación de banca en línea de un banco se actualizó
utilizando tecnologías y características más nuevas. Con más de diez millones
de clientes, cuando la nueva aplicación ocupe el lugar de la actual, cualquier
riesgo tendría un efecto profundo. Entonces, ¿cómo asegura la práctica de
control de cambios que se minimicen los riesgos? Hay varias opciones; una
338
GESTIÓN DE CAMBIOS
opción común es usar una técnica llamada prueba canary. Lanzamos la
aplicación en paralelo con la aplicación anterior, pero solo para ciertos
usuarios; digamos que unos 100 usuarios aceptan usar la nueva versión en
lugar de la anterior. La nueva aplicación es utilizada por sus usuarios limitados
y las grietas en la armadura se detectan y solucionan, antes de lanzar la
aplicación a toda su comunidad de usuarios.
La práctica de control de cambios no realiza ninguna de las actividades
técnicas, ni gestiona las actividades técnicas. Son los guardianes de los
cambios que se producen en los productos y servicios. Se aseguran de que se
implementen los controles adecuados y, cuando están satisfechos con las
pruebas, aprobaciones y mitigaciones, autorizan la implementación de
cambios.
Alcance del control de cambios

ITIL per se no especifica los límites bajo los cuales se activa la práctica de
control de cambios para gobernar los cambios en el sistema. La definición del
alcance real depende del proveedor de servicios, el cliente y los proveedores.
Un servicio de TI puede tener múltiples elementos, incluido el uso de la
red y los datos del proveedor, entre otras dependencias. Es administrado por
profesionales de TI, y la documentación del servicio también es fundamental.
¿Cambiar alguno de estos componentes periféricos implica un cambio? Sí,
pero depende del acuerdo entre el proveedor de servicios y la organización del
cliente. Administrar más elementos requiere más tiempo y recursos, lo que
aumenta los gastos. Si el cliente quiere tener control absoluto sobre los
servicios de TI, entonces sí, cada uno de los elementos que componen un
servicio debe entrar en el ámbito del control de cambios. En el mundo real, a
menudo este no es el caso, debido a las finanzas. Muchos de los componentes
indirectos se ignoran con el fin de reducir los gastos, y algunas empresas
encuentran formas innovadoras de controlar los objetos periféricos mediante
cambios estándar y solicitudes de servicio.
Desde mi experiencia, hay mucho más en el control de cambios que la
adición, eliminación y modificación de los servicios de TI. Tome el ejemplo de
ejecutar un informe ad hoc. No está agregando, eliminando o modificando
339
GESTIÓN DE CAMBIOS
nada, solo leyendo datos de la base de datos. Sin embargo, tiene el poder en
sus manos para romper los sistemas con el conjunto incorrecto de consultas
que busca en todas y cada una de las tablas, que utiliza los recursos de la
infraestructura y que podría causar problemas de rendimiento en el servicio de
TI. En este caso, si lleva esto a la gestión de cambios, es posible que puedan
identificar las consultas que consumen recursos y archivarlas o programarlas
para que se ejecuten fuera de las horas pico.
Para definir el alcance, ITIL adopta un enfoque holístico para definir lo
que se puede categorizar como un cambio. Alcanza los cambios en función de
los siguientes aspectos del diseño:
1. Servicios nuevos o modificados, donde los requisitos funcionales
están cambiando, lo que se traduce en recursos y capacidades
2. Sistemas de información de gestión (informe y comunicación) y
herramientas
3. Tecnología y arquitectura de gestión

4. Políticas, procesos y componentes derivados de procesos, como
plantillas, guías, etc.
5. Sistemas de medición, métricas, indicadores clave de rendimiento

(KPI) y metodologías asociadas
Nota El mayor éxito de un proveedor de servicios proviene

de su definición de alcance de control de cambios. y la
mejor manera es sincronizar las metas y objetivos
comerciales con los servicios, y eso con el alcance del
control de cambios. Lo que impulsa a un cliente y lo que es
más crítico para un cliente debe regirse con el mayor
escrutinio. Si la práctica de control de cambios puede
hacerlo, entonces se habrían ganado las principales
batallas.
340
GESTIÓN DE CAMBIOS
Tipos de cambios
Una talla no se ajusta a todos los cambios que suceden en los servicios. Vienen
en todas las formas y tamaños. Por lo tanto, no puede utilizar el mismo criterio
para todos los cambios. Necesita un conjunto diferente de protocolos, políticas
y procesos para manejar varios tipos de cambios. Digamos, por ejemplo, que
tropieza con una tubería de agua y se lastima el hombro. Vas al hospital, y un
médico te atiende y hace lo necesario con un mínimo de alboroto. En cambio,
si estuvo en un accidente automovilístico que requirió coserlo y colocar
algunos órganos desprendidos en su lugar, este proceso requerirá la presencia
de una operación, cirujanos, un anestesiólogo y enfermeras, entre otros, para
garantizar que usted sobreviva y el la operación es un éxito. Entre las dos
instancias, los procesos llevados a cabo son previsiblemente diferentes. Una
instancia requiere una gran cantidad de profesionales, el máximo cuidado y
cierta cantidad de planificación, mientras que la otra se puede hacer cuando
sea necesario con un conjunto de habilidades médicas básicas.
Para el paciente tropezado, no es necesario reunir cirujanos y otros.
Asimismo, en la gestión del cambio, algunos cambios deben realizarse con la
debida atención, planificación y cuidado, mientras que otros pueden llevarse a
cabo con un escrutinio mínimo.
En ITIL, hay tres tipos principales:
• Cambios normales
• Cambios de emergencia
• Cambios estándar
Nota Para su organización, puede definir tantos tipos

de cambios como necesite. ITIL no es prescriptivo, por lo
que los tipos de cambios sirven como guía en el mejor de
341
GESTIÓN DE CAMBIOS
los casos. Una vez trabajé para una organización que
tenía un cuarto tipo llamado cambio urgente que se
ubicaba entre un cambio normal y un cambio de
emergencia.
Cambios normales
Digamos que un paciente está enfermo por un problema cardíaco y necesita
someterse a una cirugía a corazón abierto. Los médicos y cirujanos
involucrados elaboran cuidadosa y meticulosamente todos los planes, reservan
las instalaciones y luego llevan a cabo el procedimiento. Estas son cirugías
planificadas, y en el mundo del control de cambios, los cambios que se
planifican con anticipación se denominan cambios normales.
La mayoría de los cambios en cualquier organización son cambios

normales, ya que ninguna organización desea realizar cambios sin contar con
los planes adecuados. Dichos cambios suelen ser largos debido a las sesiones
de planificación, la visibilidad de las partes interesadas y las aprobaciones, y
para garantizar que se administren todas las dependencias. En otras palabras,
siguen todo el proceso, que incluye autorización, revisiones y programación.
Los cambios normales generalmente se asocian con todas las campanas y
silbatos de la práctica de control de cambios y, a menudo, se analizan,
prueban, mitigan y verifican bien. La madurez de la práctica de control de
cambios de una organización a menudo se mide a través del proceso de
cambio normal y las métricas y KPI asociados con él.
Los cambios normales se asociarán con una prioridad para ayudar a
centrarse en los cambios con el máximo riesgo sobre los demás. Por ejemplo,
actualizar una aplicación de banca por Internet será un cambio importante que
requerirá los niveles más altos de revisiones y evaluaciones. La autorización
cambiará la autoridad y otros equipos dependientes junto con la revisión y
aprobación de la organización del cliente. Por el contrario, cambiar una
configuración en una aplicación para cambiar un campo de no obligatorio a
342
GESTIÓN DE CAMBIOS
obligatorio se realizará rápidamente con la aprobación mínima de las partes
interesadas.
Los ejemplos de cambios normales incluyen una actualización de la
aplicación a una versión más nueva, una migración del servidor interno a un
proveedor de servicios en la nube y el desmantelamiento de aplicaciones y
servidores de mainframe.
Todos los cambios normales tienen que ser registrados; esto se llama una
solicitud de cambio. Están registrados en una herramienta ITSM como
ServiceNow. Luego pasan por los pasos de priorización y, en base a la
priorización, se decide la cantidad de escrutinio. En el caso de la aplicación de
implementación continua en un proyecto DevOps, se generará una sola
solicitud de cambio que brindará una descripción general de alto nivel del tipo
de cambios que se realizarán durante un período. Entonces, en esencia, por
cada cambio realizado, no se generará ningún cambio nuevo. Esto diferirá
cuando el cambio sea importante.
343
Cada tipo de cambio normal se puede desglosar aún más en función de la

tecnología involucrada, el personal, los requisitos del cliente y las políticas de
gestión de cambios. Por ejemplo, los pasos involucrados en la introducción de
una actualización de software y el reemplazo de un disco duro son diferentes.
Un solo proceso estandarizado para incorporar todos los tipos de cambios,
independientemente de la tecnología involucrada, no presentará lo mejor que
puede ofrecer la práctica de control de cambios. Por lo tanto, en interés del
proveedor de servicios para mejorar la entrega, es necesario crear modelos de
cambio para diferentes tipos de cambios. Consideremos un ejemplo de un
modelo de cambio para una actualización de software y un reemplazo de disco
duro, como se indica en la Figura 12-2 .
344
GESTIÓN DE CAMBIOS
Figura 12-2. Cambiar modelo
Un modelo de cambio es una forma repetible de tratar con una categoría
particular de cambio. Un modelo de cambio define pasos específicos
acordados que se seguirán para un cambio de esta categoría.
No todas las organizaciones optan por modelos de cambio. Se ejecutan
con procesos de control de cambios que son estándar para todas las
tecnologías, equipos y clientes. Esto tiene sus limitaciones, aunque el concepto
de estandarización suena bien sobre el papel. Adaptar el proceso a través de
modelos de cambio ayuda a mejorar la entrega y proporciona un mejor control
y gobernanza de los cambios. Todo modelo de cambio debe contener lo
siguiente:
• Pasos individuales para el procesamiento de cambios, incluida la
mitigación y los riesgos
• Identificación de dependencias y cronología de las actividades

de cambio
• Identificar responsabilidades y rendición de cuentas
(básicamente RACI [responsable, responsable, consultado e
informado]) para actividades individuales
• Relacionar SLAs y KPIs para cada actividad

• Matriz de escalamiento asociada al proceso
Cambios de emergencia
Durante su sueño REM, un hombre se agarra el pecho con dolor y comienza a
sudar.
Se llama a una ambulancia y lo transportan rápidamente a un hospital cercano.
Los médicos diagnostican una serie de infartos que fueron causados por un
bloqueo en su corazón. No tienen tiempo para planificar una cirugía, sino que
deben hacerlo de inmediato si el paciente quiere sobrevivir. Así, con una
mínima planificación, realizan la cirugía. Los cambios que se realizan durante
345
GESTIÓN DE CAMBIOS
tales ejercicios de extinción de incendios se denominan cambios de
emergencia en la práctica de control de cambios.
Los cambios de emergencia son necesarios para solucionar urgentemente
un problema continuo o una crisis. Estos cambios se llevan a cabo
principalmente como una resolución a un incidente importante. La naturaleza
de tales cambios requiere una acción rápida, ya sea para obtener las
aprobaciones necesarias o las pruebas involucradas. Por lo general, los
cambios de emergencia no se prueban exhaustivamente, ya que la
disponibilidad de tiempo es mínima. En algunos casos pueden pasar sin
ninguna prueba, aunque esto no es recomendable ni siquiera para un cambio
de emergencia. En la medida de lo posible, se recomienda que los cambios de
emergencia pasen por el mismo nivel de escrutinio que los cambios normales
pero en un cronograma acelerado. Sin embargo, la parte de la documentación
del cambio se puede realizar de forma retrospectiva, y se realizan algunos
atajos en las pruebas para restaurar los servicios lo antes posible.
El éxito de los cambios de emergencia refleja la agilidad de una
organización y la práctica de control de cambios para actuar sobre las
interrupciones en un entorno con limitaciones de tiempo. y salir ileso ante los
ojos del cliente y de tu competencia.
La práctica de control de cambios de emergencia apoya la práctica de
gestión de incidentes en la resolución de incidentes, especialmente los más
importantes. Los cambios de emergencia generalmente están mal vistos y no
se prefieren. El número de tales cambios en una organización refleja
pobremente la estabilidad de los servicios que ofrece la organización.
Ejemplos de cambios de emergencia son el reemplazo de la infraestructura
de hardware y la restauración de datos de clientes a partir de volúmenes de
respaldo.
Para gestionar los cambios de emergencia, es posible que se establezca
una autoridad de gobierno separada que trabaje en estrecha colaboración con
el equipo de operaciones, y esta autoridad de gobierno esté disponible las 24
horas.
346
GESTIÓN DE CAMBIOS
Cambios estándar
Un paciente con insuficiencia renal se somete a diálisis varias veces a la
semana. El proceso para llevar a cabo un procedimiento de diálisis es bien
conocido y rara vez puede fallar. La mayoría de los pacientes establecen
tratamientos de diálisis en casa y los hacen con bastante regularidad. Los
riesgos involucrados son bajos, y si algo sale mal, el impacto también está en
el extremo inferior del espectro porque hay múltiples soluciones disponibles.
Dichos cambios para los servicios de TI que no representan un peligro para los
servicios y son de bajo perfil se denominan cambios estándar.
Los cambios estándar son cambios normales que son de bajo riesgo y bajo
impacto en la naturaleza. La categorización de los cambios como estándar
queda a discreción del proveedor de servicios y las organizaciones de clientes.
Estos tipos de cambios se entienden bien, se evalúan a fondo y se documentan
en detalle. Son cambios preaprobados: no todos los cambios, sino el tipo de
cambios. Por ejemplo, si consideramos poner en la lista negra una dirección IP
como un cambio estándar, la acción de poner en la lista negra las IP está
autorizada. Luego, cada vez que se identifica una nueva dirección IP para la
lista negra, el equipo involucrado simplemente genera un cambio estándar y
coloca la IP en la lista negra sin tener que buscar aprobaciones.
En la práctica de gestión de solicitudes de servicio, hablé de las solicitudes
de servicio como un tipo de cambios estándar. Los proveedores de servicios a
menudo toman la ruta de las solicitudes de servicio cuando tratan con
individuos y los cambios estándar cuando tratan con cambios en el nivel de
servicio.
Los cambios estándar tienen claras ventajas y crean valor para los clientes.
Siguen un proceso que es menos estricto y está libre de las múltiples
aprobaciones y plazos de entrega que a menudo se asocian con los cambios
normales. Esto proporciona al proveedor de servicios el arsenal necesario para
implementar cambios sobre la marcha, lo que aumenta la productividad y
también ayuda a ofrecer un mejor valor al cliente.
Los ejemplos de cambios estándar incluyen actualizaciones de parches
menores, reindexación de bases de datos y listas negras de IP en firewalls.
347
GESTIÓN DE CAMBIOS
Se cree que la madurez del proceso de gestión de servicios de las
organizaciones que ofrecen servicios se puede determinar en función de la
cantidad de cambios estándar en el sistema. Eso es cierto, ya que los cambios
estándar presentan un sistema para segregar los cambios difíciles de los
habituales. Los cambios comúnmente realizados son como una máquina bien
engrasada. Funciona sin problemas y se puede confiar en él en la mayoría de
las circunstancias. Alrededor del 60 al 70 por ciento de los cambios en
cualquier organización son comunes, repetibles y directos. Si se estandarizan
todos estos cambios, imagine la cantidad de aprobaciones que no es necesario
buscar y la cantidad de reuniones, llamadas telefónicas y esperas que se
pueden omitir.
La ventaja de los cambios estándar es tal que, en la mayoría de las
situaciones, se puede realizar en la parte posterior de cualquier activador
definido. Cuando un equipo quiere realizar un cambio estándar, no tiene que
acudir al equipo de gestión de cambios oa la autoridad de cambios para
obtener autorización para presentar su cambio. Simplemente registran un
cambio estándar en el sistema (sí, los registros son una necesidad absoluta) y
luego pueden llevarlo a cabo. Una vez que se implementa con éxito (lo que se
espera), el cambio se cierra. ¡Voila!
No hay necesidad de hacer ninguna revisión posterior al cambio.
Los ejemplos de cambios estándar pueden ser cualquier cosa bajo el sol de
TI que sea de naturaleza repetitiva y no plantee riesgos importantes. Eso suena
como cada implementación que hacemos bajo DevOps, ¿no es así? ¿Ve ahora
la conexión entre los cambios estándar y DevOps? Los ejemplos típicos
incluyen la instalación de parches de seguridad en los sistemas operativos, la
ejecución de trabajos por lotes y la realización de copias de seguridad no
intrusivas.
348
GESTIÓN DE CAMBIOS
Cambios estándar de defensa
Comencé mi carrera como consultor de gestión de servicios y, a lo largo de los
años, me gané la reputación de crear valor para mis clientes a través de mis
diseños y mejoras. Implementar cambios estándar era una de mis armas
secretas. Estas son las primeras cosas que miro durante una evaluación:
¿Existe una práctica sólida de control de cambios?
¿Existen disposiciones para cambios estándar?
¿Cuántos cambios se implementan como cambios estándar?

¿Se monitorean y auditan regularmente los cambios
estándar?
Los cambios estándar son el fruto de la creación de valor al alcance de la

mano para los clientes. La mayoría de los expertos y consultores en gestión de
servicios todavía tienen que enfrentarse a ella, y eso perjudica las posibilidades
de sus clientes de marcar la diferencia a través de la gestión de servicios.
Cuando trabajé como gerente de cambio empresarial para una
organización minorista en Sydney, Australia, noté que la organización no tenía
un proceso de cambio estándar activo. Un equipo de administradores de
cambios revisó y procesó entre 150 y 200 cambios cada día. Sabían tan bien
los cambios que al leer el resumen de cambios, simplemente se desplazaban
hacia abajo hasta donde la tarea de aprobación se hacía visible y presionaban
Aprobar.
Lo primero que me llamó la atención fue por qué se requería este esfuerzo
humano, ya que equivalía a un proceso a seguir en lugar de cualquier valor
visible a través del par de ojos adicionales. Me puse manos a la obra
extrayendo datos de los últimos dos años e identificando cambios que podrían
categorizarse como cambios estándar. Hice un poco de aritmética y algunas
conjeturas para calcular algunos números y, según mi análisis, la organización
podría ahorrar entre 25 y 40 horas todos los días. Consideré números modestos
para mis cálculos, y este fue el ahorro mínimo que la organización podía hacer,
basado en 200 horas de ahorro semanal y el salario promedio por una semana
349
GESTIÓN DE CAMBIOS
típicamente en Australia es de alrededor de $2,500 ($12,500 por las 200 horas
ahorradas). Este ahorro se traduce en un ahorro mensual de alrededor de $50
000 ($12 500 × 4 semanas). De la nada, la empresa podía ahorrar más de
medio millón cada año, y se lanzaron a ello, no sin una serie de advertencias
de los veteranos de la empresa.
Logré convertir alrededor del 60 % de los cambios generales en cambios
estándar en 4 meses, y los beneficios mostraron el poder de Agile y DevOps.
Varios empresarios de esta organización se sintieron aliviados de no tener que
preocuparse por obtener aprobaciones para todos sus cambios. La mejor parte
fue que no tuvieron que agrupar sus cambios en lanzamientos, por lo que los
cambios pasaron rápidamente a producción y brindaron los máximos
beneficios para el negocio.
Aviso de cambio
La práctica de control de cambios por sí sola puede no tener las habilidades
necesarias para juzgar los cambios según sus méritos. Por lo tanto, se
establece un organismo llamado autoridad de cambio para asesorar a la
práctica de control de cambios sobre los riesgos que plantea el cambio.
Tienen el poder de autorizar cambios para su implementación o rechazarlos,
y la práctica de control de cambios generalmente considera su juicio.
La autoridad de cambio se puede describir como una extensión de la
función de gestión de cambios, y existe para garantizar que los cambios
propuestos no sean perjudiciales, que se programen para minimizar los
conflictos, que se prioricen en función del riesgo y el impacto, y que se
analicen todos los resultados posibles hasta el final.
Anteriormente, una organización constaba de la autoridad de cambios,
que era de naturaleza dinámica, pero dado que el control de cambios era
central, la autoridad de cambios también operaba de manera central. Hoy en
día, en el mundo de la rápida toma de decisiones, tener una sola autoridad de
cambio es un cuello de botella para un cambio rápido. Por lo tanto, es
bastante común descentralizar el proceso de aprobación de cambios a través
de las autoridades de cambios locales. Por ejemplo, una cartera de
aplicaciones puede tener su propia autoridad de cambio y la infraestructura de
350
GESTIÓN DE CAMBIOS
la nube puede tener su propio sistema de aprobación de cambios
descentralizado. Esto ayuda a avanzar rápidamente y también a tener
tomadores de decisiones que conocen el sistema, como propietarios de
productos y servicios. El control de cambios principal o el organismo de
formulación de políticas podría seguir siendo central, lo que puede imponer
congelaciones de cambios y otras políticas y procesos en toda la empresa,
como procesos para definir cambios estándar.
En una reunión típica de autoridad de cambios, un representante de
cambios (generalmente el líder técnico) presenta el cambio. Con base en la
presentación, el comité podría optar por buscar aclaraciones; hacer preguntas;
y aprobar, aplazar o rechazar el cambio, únicamente en función del mérito.
Nota En ITIL V3, la autoridad de cambio se

denominaba junta asesora de cambios (CaB). Tanto la
autoridad de cambio como el CaB son iguales en principio
y espíritu; sólo se diferencian por el nombre.
Cambiar horario
La definición de la práctica de control de cambios habla de un cronograma de
cambios, que es una terminología importante en la práctica de control de
cambios. Una programación de cambios se refiere a un calendario de cambios
que consta de los cambios que están en proceso, los próximos cambios
aprobados y los cambios que se implementan. Míralo a través de los ojos de
un calendario. Usamos nuestros calendarios para planificar el día, proponer
nuevos espacios para reuniones conflictivas y delegar personas a ciertas
reuniones importantes que no podemos asistir. Asimismo, se utiliza un
cronograma de cambios para la planificación de los cambios, especialmente
donde existen dependencias entre un cambio y otro; asignar recursos para
supervisar e implementar cambios; y comunicar a las partes interesadas
apropiadas sobre el ciclo de vida del cambio. Los conflictos en los cambios
351
GESTIÓN DE CAMBIOS
son bastante comunes, y un calendario (calendario de cambios) ayuda a
identificarlos y mitigarlos.
Otras prácticas también aprovechan el calendario de cambios. Por
ejemplo, la práctica de gestión de incidentes utiliza la información para
identificar los cambios que se han implementado, para identificar la fuente de
un grupo de incidentes. Eso ayuda a identificar la causa de un incidente y
resolverlo rápidamente. La gestión de problemas también podría usar esta
información para identificar la causa raíz de los problemas. El cronograma de
cambios también se puede ver desde la perspectiva de los próximos cambios,
para identificar los errores del producto que se están solucionando. Las
aplicaciones de un horario de cambio son infinitas. Es importante que una
organización mantenga un cronograma de cambios centralizado para ayudar a
identificar conflictos y dependencias de manera efectiva.
Nota En ITIL V3, el cronograma de cambios se

denominó cronograma de cambios hacia adelante (FsC).
Tanto el cronograma de cambios como el FsC son iguales
en principio y espíritu, y solo difieren en el nombre.

servicio
Tabla 12-2. Práctica de control de cambios en SVC
Actividad de
CVS
Plan Bajo La realización de cambios en los
planes, y sus derivados, como
políticas, procesos y marcos, se rige
por la práctica de control de cambios.
Diseño y alto Cuando hay cambios de diseño en
352
GESTIÓN DE CAMBIOS
Transición los productos y servicios, o cuando
se introducen nuevos productos y
servicios, se crean cambios para
ponerlos en producción. La mayor
parte de la actividad de transición de
cambios se ejecuta en el reverso de
un ticket de cambio.
obtener/construir alto Los productos y servicios que se
desarrollan pasan por la práctica de
control de cambios para volverse
operativos.
comprometer Bajo algunos cambios pueden requerir
la participación de clientes,
proveedores o usuarios para
supervisar los cambios o tomar
un lugar en la autoridad de
cambios.
( continuación )
Tabla 12-2. ( continuación )
Actividad de
CVS
Entregar y alto No es ningún secreto que los cambios
apoyar son una de las principales fuentes de
incidentes, lo que lleva a una mayor
actividad de entrega y soporte. y
resolución de incidentes y problemas a
cuestas en el control de cambios para su
implementación.
Mejorar alto Las mejoras que se recomiendan pasan
por la práctica de control de cambios para
evaluar los riesgos y sopesar los
beneficios frente a la profundidad de los
cambios que se están introduciendo.
12-1. ¿ Cuál de las siguientes es la definición de cambio correcta?
353
GESTIÓN DE CAMBIOS
A. Cualquier cambio de estado que sea significativo para un servicio o
producto o elemento de configuración relacionado
B. La adición, modificación o eliminación de cualquier cosa
que podría tener un efecto directo o indirecto en los servicios
C. Cualquier cambio de estado de los elementos de configuración que
correlaciona riesgos y problemas con el servicio y los procesos
de gestión del servicio
D. Cualquier cambio que tenga importancia para la gestión de un servicio u

otras adiciones, eliminaciones y modificaciones
12-2. ¿Por qué los incidentes y las solicitudes de servicio deben tratarse
por separado?
A. Los incidentes son generados por las herramientas de monitoreo y las

solicitudes de servicio por parte de los usuarios, por lo que los niveles de
servicio son diferentes y, por lo tanto, deben tratarse de manera diferente.
B. Los incidentes son interrupciones del servicio y las solicitudes de servicio
son solicitudes adicionales. Por lo tanto, para evitar una mayor
interrupción del servicio, se deben priorizar los incidentes sobre las
C. La pérdida de solicitudes de servicio da como resultado incidentes

aumentó. Por lo tanto, las solicitudes de servicio deben tener prioridad.
D. Los incidentes y las solicitudes de servicio no deben tratarse de manera
diferente. Ambos generan inconvenientes para los usuarios finales, por lo
que es fundamental que ambos se resuelvan a un ritmo rápido.
12-3. La práctica de gestión de solicitudes de servicio existe por este
motivo:
A. Apoyar la provisión de servicios a través de la práctica de control de

cambios.
B. Para garantizar que los servicios se restablezcan al usuario final para
ayudar a aumentar la productividad y la eficacia del usuario final.
354
GESTIÓN DE CAMBIOS
C. Para respaldar la calidad acordada de un servicio mediante el manejo de
todas las solicitudes de servicio predefinidas iniciadas por el usuario
D. Proporcionar un marco general para gestionar las solicitudes de servicio y
los cambios estándar que están predefinidos y establecidos
12-4. ¿Cuál de los siguientes no es un tipo válido de cambio según ITIL?

A. cambio urgente
B. cambio normal
C. Cambio estándar
D. Cambio de emergencia
12-5. ¿Cuál es el papel principal de la autoridad de cambio?
A. Asesorar a la práctica de control de cambios sobre los riesgos que plantea

el cambio.
B. Aprobar o rechazar cambios en función de la programación de cambios
C. Autorizar los cambios estándar que deben implementarse

D. Proporcionar recomendaciones a la práctica de control de cambios para
crear solicitudes de cambio.
12-6. ¿En qué consiste un cambio de horario?

A. Cambios aprobados
B. Cambios aprobados y canalizados

C. Cambios aprobados y rechazados
D. Cambios estándar y de emergencia
355
CAPÍTULO 13
Prácticas para
gestionar
lanzamientos
El ciclo generalmente comienza con el diseño, seguido de la construcción,
prueba y transición. Las actividades de transición involucran la gestión de
mover un objeto construido a la producción. Antes de que esto pueda suceder,
debe haber un proceso simplificado para administrar el movimiento de
paquetes desde los entornos inferiores a los superiores. Debe haber políticas,
principios y procesos precisos que guíen los lanzamientos para garantizar que
la actividad no se convierta en un método caótico ambiguo. Si bien estos
representan la mitad de la historia, existe el aspecto técnico de mover los
paquetes: los métodos que usamos para implementar para minimizar los
riesgos y maximizar la previsibilidad.
En el mundo de las cascadas, los lanzamientos y despliegues sucedían
muy pocas veces, y los periodos se definían a sangre y se seguían al pie de
la letra. Entonces, la responsabilidad de un proceso para impulsarlo, los
procedimientos para implementar y los medios de implementación no fueron
tan importantes como el proceso de desarrollo y prueba.
4842-6361-7_13
CAPÍTULO 13 PRÁCTICAS PARA LA GESTIÓN DE LIBERACIONES
Hoy en la industria de DevOps, las cosas no son lo que solían ser. Las
unidades finales de producción de lanzamientos y despliegues se han
convertido en uno de los pilares del desarrollo y las operaciones. Suceden todo
el tiempo y sin supervisión humana como ocurría antes. Por lo tanto, es
imperativo ajustar los procesos y controlar las actividades a través de la
automatización para permitir que los dos conjuntos de actividades sean fluidos
y no actúen como bloqueadores, porque en DevOps, la velocidad lo es todo. Y
los bloqueadores/impedimentos están destinados a ser derribados de una forma
u otra. Este es un tema importante desde las perspectivas de DevOps, Agile e
ITIL.
Este capítulo cubre dos prácticas:
• Gestión de la liberación
• Gestión de implementación
Nota En ITIL V3, las prácticas de gestión de

lanzamiento e implementación se combinaron en un solo
proceso. En ITIL 4, el contexto ha cambiado y el mundo
se ha vuelto más digital, con muchos más lanzamientos e
implementaciones. Por lo tanto, tiene mucho sentido que
haya prácticas dedicadas a dar a ambos temas el debido
respeto que merecen.
Aunque ITIL no especifica que es necesario un conocimiento profundo

desde el punto de vista del examen, profundizaré porque son piezas críticas de
cualquier industria que considere y desde la que las mire. Me aseguraré de que
tengas un buen control de ambas prácticas.
356
Consejo de examen Puede esperar una o dos
preguntas en el examen de Fundamentos de ITIL de las
prácticas de lanzamiento e implementación. Se evaluará
su comprensión superficial de los temas.

GESTIÓN DE LIBERACIONES
Gestión de la liberación
La gestión de versiones es una práctica común a las actividades de desarrollo y
operaciones de un programa. En otras palabras, realiza versiones para
elementos que son mejoras y también realiza versiones para reparaciones,
especialmente aquellas que no son urgentes.
Antes de entrar en lo que hace la práctica de gestión de versiones,
examinemos más de cerca el término versión .
Definición ITIL de una versión
Una versión de un servicio u otro elemento de configuración, o
una colección de elementos de configuración, que está disponible
para su uso.
La definición puede sonar críptica, pero no lo será después de que la
explique.
Las mejoras o un nuevo producto o servicio que se está introduciendo se
desarrollan en un entorno inferior, como un entorno de desarrollo. El acceso a
él estaría solo con los desarrolladores. Después de completar el desarrollo y la
prueba unitaria, los desarrolladores lo promocionan a un entorno superior, por
ejemplo, un entorno de prueba. Los equipos de prueba acceden a un entorno de
prueba que realiza pruebas contra los requisitos funcionales (y el diseño
técnico). Las pruebas pueden ser realizadas por humanos (manual) o por
máquinas (automatización). Si las pruebas son satisfactorias, el software
desarrollado se traslada al siguiente entorno superior, por ejemplo, el entorno
de pruebas de aceptación donde los usuarios realizan pruebas similares a las
que hicieron los probadores en el entorno de pruebas. Si todo está bien, el
software se empaqueta como una versión; en una fecha prefijada y acordada,
se traslada al ámbito superior, que es el de producción. Este movimiento a
357
producción se conoce como liberación. En el lanzamiento, es posible que
tenga solo este software, o algunas piezas de software juntas y, a menudo,
también empaquetadas junto con soluciones de incidentes no urgentes. Cuando
el lanzamiento entra en producción, el software lanzado está disponible para
uso general, que generalmente tiene acceso controlado. Consideré un ejemplo
aquí de un software, pero es bastante probable
que junto con el software también podría haber cambios de hardware; tal vez
una capacidad de procesador mejorada o un conjunto de servidores con
equilibrio de carga. Por lo tanto, es importante imaginar un lanzamiento como
un paquete que podría contener mejoras de software, introducciones de nuevos
servicios, reparaciones y cambios de hardware. Es un paquete en el que una
serie de cambios ingresan al sistema durante la misma ventana, denominada
ventana de cambio.
¿Por qué estamos impulsando una serie de cambios de este tipo a la vez en
un paquete? ¿No es probable que falle o actúe como un punto masivo de falla?
En la mayoría de las industrias, el negocio prefiere que la producción no se
vea afectada por cambios en su mayor parte. Esto le da al negocio una
sensación de estabilidad y, en algunos casos, dada la sensibilidad del negocio,
tienen razón al establecer tales expectativas. Por lo tanto, para reducir la
cantidad de puntos de contacto o la cantidad de veces que se introducen
cambios en la producción, los lanzamientos están diseñados para realizarse
quizás una vez al mes, lo que es más popular, o al menos una vez al trimestre.
Definición ITIL de práctica de gestión de versiones
El propósito de la práctica de administración de versiones es
hacer que los servicios y funciones nuevos y modificados estén
disponibles para su uso.
Control de cambios frente a gestión de

versiones
He realizado varias capacitaciones en un salón de clases y también en línea. La
pregunta más frecuente cuando empiezo a hablar de la gestión de versiones es
esta: ¿cuál es la diferencia entre el control de cambios y la gestión de
358
versiones? Parece que lo que hace la práctica de control de cambios es lo
mismo que la gestión de versiones; eso es lo que me preguntan. Esta sección
está dedicada a esos interrogadores. En esta sección, no diferenciaré entre las
prácticas de administración de lanzamiento e implementación, ya que la
historia que traza una delgada línea entre el cambio y el lanzamiento es
sencilla si el lanzamiento y las implementaciones se consideran juntas.
En la ilustración de la Figura 13-1 , he considerado un proceso simple que

comienza desde la recopilación de requisitos hasta la implementación de
producción. Todas las actividades del proceso se han segregado como control
de cambios o gestión de versiones. Aunque algunas actividades, como la
recopilación de requisitos, se consideran parte del análisis comercial, en el
desarrollo de software se encuentran bajo el paraguas común de la gestión de
versiones, para garantizar un flujo continuo entre los requisitos y la
implementación de producción.
Figura 13-1. Control de cambios frente a gestión de versiones
El control de cambios es un proceso que es responsable de obtener todas

las aprobaciones y autorizaciones de las partes interesadas relevantes y
controlar qué cambios se introducen. La práctica de gestión de versiones, por
otro lado, se ocupa de la gestión de los tecnicismos de los cambios. Por
359
ejemplo, digamos que se ha planteado un cambio para implementar una nueva
versión del software. El proceso de control de cambios existe para poner el
cambio frente al jurado (autoridad de cambio) y ayudar a obtener aprobaciones
y autorizaciones para que el cambio se pueda implementar sin problemas. La
práctica de administración de versiones administra las actividades de
recopilación, codificación, prueba e implementación de requisitos de este
cambio.
Las prácticas de control de cambios y gestión de versiones trabajan en

estrecha colaboración, intercambiando información de actividades
relacionadas durante varias actividades, como se muestra en la Figura 13-1
. El establecimiento del alcance, la creación de un plan y la recopilación de
los requisitos se encuentran bajo los auspicios de la gestión de versiones.
Una vez que existe un plan, incluidas las dependencias y los impactos
conocidos, la gente de control de cambios hace su investigación y
aprobación formales antes de dar el visto bueno para comenzar el
desarrollo.
La aprobación del control de cambios antes del desarrollo se considera por
las siguientes razones:
• Garantiza que los esfuerzos que se dedican al desarrollo y
las pruebas no se desperdicien si la gestión de cambios
decide no aprobar los cambios.
• Si hay modificaciones a la solución propuesta por la
autoridad de cambios, entonces se puede evitar la repetición
del trabajo.
La práctica de administración de versiones administra las partes generales
de planificación, construcción, prueba e implementación del proyecto. Sin
embargo, una vez concluidas las pruebas, el estado de liberación se vuelve a
poner en el tribunal de control de cambios. La autorización del control de
cambios es un paso necesario para garantizar que se hayan cumplido todos los
criterios de entrada para que comience el despliegue. También proporciona
supervisión antes de que comiencen los cambios en la producción.
Las actividades de implementación y revisión posterior a la
implementación son propiedad del proceso de gestión de versiones, y los
360
resultados se informan debidamente a la gestión de cambios para los cierres de
cambios con el estado adecuado.
En este proceso de muestra, la versión ha sido alternada entre la versión y
las prácticas de control de cambios al menos seis veces. Puede ir más alto;
cuanto mayor sea el número de intercambios, mejor será para garantizar la
calidad de la gobernanza y compartir responsabilidades.
Fundamentos de la versión
He desglosado los fundamentos de la versión en partes para facilitar la
comprensión.
Componentes de lanzamiento
Como se discutió anteriormente, los lanzamientos incluyen componentes de
hardware y software que entran en producción. Bueno, eso no es todo. Como
parte del lanzamiento, hay otros componentes que también deben actualizarse.
La formación, por ejemplo, es un aspecto crítico. Si ciertas funcionalidades del
software están cambiando, los usuarios finales deben recibir capacitación antes
del lanzamiento, la documentación debe actualizarse en línea con las mejoras
y los nuevos servicios, y es posible que sea necesario ordenar los accesos. Esta
lista es diferente para cada aplicación que está pasando por el ciclo de
lanzamiento.
No todos los componentes de la versión provienen únicamente del
proveedor de servicios. En ocasiones, los terceros proporcionan paquetes o
componentes que pueden incluirse en el lanzamiento. Un ejemplo podría ser
un paquete que se necesita para que una integración existente funcione en las
próximas versiones del software de terceros que se integra con la aplicación
administrada por el proveedor de servicios. No solo es posible el lanzamiento
de productos de terceros, sino también de COTS y de código abierto.
Por lo tanto, el alcance de la gestión de versiones se extiende tan lejos
como se extiende el servicio; necesitan analizar los riesgos que provienen de
los sistemas de terceros, la infraestructura que aloja el software y todos los
componentes del servicio.
361
Tipos de lanzamientos
Los lanzamientos vienen en varios tamaños y ciclos. Es posible que esté
realizando un pequeño cambio en una funcionalidad que es casi inofensiva, o
podría estar actualizando el software, incluida su arquitectura. O puede estar
moviendo sus componentes de software de una infraestructura local a la nube,
lo que tiene un gran impacto si las cosas van mal. O podría estar realizando
cambios en un middleware, lo que podría afectar potencialmente a 20
aplicaciones que se alimentan de él.
Ejemplos de tipos de liberación son liberaciones menores, liberaciones
mayores y liberaciones de emergencia.
Lanzamientos principales
Las principales actualizaciones de software generalmente se incluyen en los
principales lanzamientos. El impacto comercial de los principales
lanzamientos puede oscilar entre alto y crítico. Este tipo de lanzamiento es la
madre de todos los lanzamientos y tiene prioridad si va a haber un lanzamiento
menor aproximadamente al mismo tiempo. Por lo general, se dedica una
cantidad de recursos a la construcción y ejecución de un lanzamiento, y desde
el punto de vista del cumplimiento, todos los halcones deben observarlo con
atención adicional.
En mi experiencia, los lanzamientos importantes son pocos y distantes
entre sí. En la mayoría de los casos, se realizan ad hoc, y algunas
organizaciones implementan al menos cuatro versiones principales en un año.
Por ejemplo, puede notar que las actualizaciones se aplican al sistema
operativo Windows. Algunos cambios son rápidos y es posible que ni siquiera
exijan un reinicio. Sin embargo, las adiciones, modificaciones o la eliminación
de funciones integrales ocurren en la parte posterior de las versiones
principales que pueden requerir varios minutos de instalación seguidos de
múltiples reinicios.
362
Lanzamientos menores
Como sugiere la palabra menor, los lanzamientos menores incluyen unidades
de lanzamiento que son pequeñas y por lo general no arruinan el negocio si el
lanzamiento va mal.
Los lanzamientos menores generalmente se llevan a cabo con una
frecuencia semanal o mensual. Todo depende de la cantidad de cambios que se
introduzcan y la cantidad de recursos disponibles para trabajar en ellos.
Lanzamientos de emergencia
Los lanzamientos de emergencia son las contrapartes de planificación y
ejecución de los cambios de emergencia. Entran en juego en la parte posterior
de un cambio de emergencia y se implementan (generalmente) para solucionar
un incidente y evitar un impacto comercial negativo.
El número de liberaciones de emergencia se refleja negativamente en la
organización y el proyecto. Por lo tanto, este es un tipo de lanzamiento que no
es preferido o planificado, sino que se impone por el giro de los
acontecimientos. Tampoco es raro que la política de lanzamiento permita que
los cambios de emergencia se realicen en helicóptero solo entre lanzamientos,
por ejemplo, entre dos lanzamientos menores.
Calendario de lanzamiento
Los lanzamientos normalmente tienen un período asociado a ellos. Si no lo
son, o si se llevan a cabo cuando sea necesario, estos lanzamientos se
denominan lanzamientos ad hoc. A veces, para poner una solución que tenga
un gran impacto, se realizan lanzamientos no programados. Estos se realizan
en la parte posterior de los cambios de emergencia y se conocen como
versiones de emergencia. Luego están los programados, que pueden ser
diarios, semanales, mensuales, trimestrales, semestrales, anuales, etc. Diario,
semestral y anual son bastante raros. Incluso los otros lanzamientos periódicos
pueden tener un tema asociado, como lanzamientos semanales para parches de
seguridad, mensuales para cambios de configuración y trimestrales para
cambios importantes.
363
Todos estos lanzamientos periódicos pronto desaparecerán y DevOps se
hará cargo. En DevOps, los lanzamientos se realizarán de forma modular y
cuando se complete la prueba de la funcionalidad. Nadie va a esperar a armar
las piezas para una hermosa mañana soleada. Se empuja a la producción a
medida que se prueba por completo.
Vimos el cronograma de cambios en el último capítulo, que constaba de
todos los cambios que están en trámite y en estado aprobado. También existe
un cronograma de lanzamiento que es de naturaleza similar pero contiene
todos los lanzamientos que están vigentes. Es un horario que tiene una
visibilidad entre un cliente y un proveedor de servicios. La práctica común es
que el cliente y el proveedor de servicios discutan y lleguen a un acuerdo sobre
cómo será el cronograma de lanzamiento y que establezcan las fechas junto
con los temas. Se puede publicar un cronograma de lanzamiento para todo el
año calendario en el último trimestre del año anterior. Esto da una apariencia
de previsibilidad para el negocio sobre cuándo se esperan los lanzamientos y
cuándo se deben implementar las mejoras y otros cambios.
Revisiones de lanzamiento
Los lanzamientos y cambios son similares. Al igual que una revisión posterior
a la implementación de un cambio, se realiza un ejercicio similar llamado
revisión de implementación de la versión después de cada versión principal.
Los objetivos son comprender cómo se desarrollaron las cosas e identificar los
pasos en falso y, posteriormente, las lecciones aprendidas del lanzamiento.
Esto ayudará a mejorar los próximos lanzamientos y lleva al proveedor de
servicios un nivel superior en la escala de madurez.
Cascada frente a Agile/DevOps

Permítanme explicar cómo funcionan los lanzamientos en un proyecto en
cascada, en comparación con un proyecto que se ejecuta en modo
Agile/DevOps.
364
Considere que hay tres características que se van a desarrollar. En un
enfoque en cascada, las tres características se desarrollan primero, luego se
prueban y luego se implementan/lanzan a producción.
Si el mismo proyecto se iba a ejecutar de forma Agile/DevOps, el
desarrollo, las pruebas y la implementación de las tres funciones se realizan de
forma iterativa. Si el plan de lanzamiento exige que las tres funciones se
implementen en producción en un solo lanzamiento, entonces cada una de las
funciones se implementa de forma independiente en entornos inferiores, se
empaqueta y se lanza todo a la vez a producción.
Los enfoques de cascada frente a Agile/DevOps se ilustran en la Figura 13-2 .
Figura 13-2. Lanzamientos Waterfall vs. Agile/DevOps
Gestión de versiones en Agile/DevOps

En los proyectos Agile/DevOps, la gestión de versiones no se ha transformado
por completo. Se ha vuelto más fuerte a través de las iteraciones. Las
actividades en la gestión de versiones ahora se ven con una lente diferente que
está lista para aceptar los hechos en función de las cosas que se presentan, en
lugar de predecir el futuro.
365
Uso de trenes de lanzamiento ágiles
El rango de planificación que hemos comenzado a hacer en los lanzamientos
no se limita solo a un sprint, que es la forma de trabajo Agile/Scrum. Sin
embargo, el uso del marco SAFe y la aplicación de la gestión de versiones a
los trenes de versiones ágiles (ART) nos brinda un plan estable para las
próximas 10 a 12 semanas. Todo el ART representa un lanzamiento con
paquetes de software que llegan cada dos semanas al final de cada sprint.
Cuando reunimos los sprints junto con sus resultados, el producto final es el
paquete de lanzamiento.
Aplicación de la gestión de versiones a la

implementación continua
En el mundo de DevOps, el proceso de gestión de versiones se puede adaptar
según el tipo de proceso (entrega continua o implementación continua) que
aprovechemos. Digamos que planeamos emplear una implementación
continua donde cada vez que un paquete se prueba con éxito, se implementa
automáticamente. El papel de la gestión de versiones aquí es garantizar que el
camino hacia la producción sea estable, relevante y coherente.
El proceso de gestión de versiones tendrá mucha planificación y ejecución
durante las dos fases iniciales en lugar de las dos fases finales. Aún así, si un
paquete defectuoso llega a la producción, la pelota vuelve a caer en la cancha
de la gestión de lanzamiento para arreglar la canalización y los factores
asociados que hacen que la canalización funcione (como escenarios de prueba,
scripts, etc.). Además, la administración de versiones tiene que identificar
varias ventanas de versiones para que se lleven a cabo las implementaciones
porque la posibilidad de que las implementaciones se realicen varias veces al
día es una rutina en un proceso de implementación continuo.
Aplicación de la gestión de versiones a la entrega

continua
En la entrega continua, sin embargo, la cordura se puede mantener hasta cierto
punto. El proceso de gestión de lanzamientos se vuelve bimodal, con
366
planificación de lanzamientos y compilaciones/pruebas usando el modelo de
iteración, e implementaciones y revisiones tomando el enfoque secuencial
tradicional.
El plan para la entrega continua funciona bien con ART, ya que el ejercicio
de planificación se realiza una vez cada 12 semanas y se refina a medida que
avanzan los sprints. Los sprints se ejecutan en iteraciones con los paquetes de
software, llevándolos a un estado de preparación pero sin implementarlos.
Cuando todas las piezas del lanzamiento están desarrolladas e integradas,
ocurre la implementación (secuencial) seguida de una revisión del
lanzamiento.
La mayoría de las organizaciones tenderán a seguir este enfoque,
principalmente porque les da a las personas a cargo una sensación de control.
Dado que la entrega continua aún requiere un desencadenador manual antes de
la implementación, los responsables de la toma de decisiones se sienten
cómodos al optar por un proceso que no solo acelera la producción, sino que
también espera una orden formal antes de iniciar la producción.
La madurez está marcando el camino hacia la implementación continua.
Los que toman las decisiones, después de algunos comunicados, se darán
cuenta de que sus decisiones siempre han estado respaldadas por las cifras, que
los comunicados presentados ante ellos siempre han sido buenos para la
producción y que sus decisiones se han convertido en solo una formalidad.
Entonces, el juego final siempre será con un despliegue continuo.
Técnicas de gestión de versiones

Aunque en DevOps pretendemos ser valientes y animar
experimentación, no se sacrifica el principio central de reducir los riesgos para
los servicios existentes. Si bien hacemos cambios rápidos en el servicio, el
software, el hardware y otras piezas de los servicios que disfrutan los usuarios,
la transición al servicio actualizado debe ser lo más fluida posible. Para lograr
367
esto, aprovechamos algunas técnicas que nos ayudan a mitigar los riesgos que
conllevan los cambios en entornos estables.
Prueba de concepto y piloto
Al realizar cambios importantes en un producto o servicio, primero
probamos las aguas realizando una prueba de concepto (POC). El propósito
de un POC es demostrar que el camino que está tomando funciona y evitar
avanzar demasiado con el desarrollo y las pruebas, solo para descubrir que
el resultado final que está tratando de lograr no es posible. Los POC
generalmente se llevan a cabo si está realizando cambios arquitectónicos,
cambios tecnológicos e introduciendo nuevos conceptos.
Por ejemplo, a un banco que pasa de la tecnología mainframe a una
tecnología basada en SAP para ejecutar sus motores bancarios le gustaría ver
algunas transacciones críticas demostradas en una plataforma SAP antes de
que puedan dar su visto bueno para un desarrollo completo. Si está
introduciendo la automatización de pruebas en un producto, probablemente le
gustaría ver si funciona a través de un POC antes de comenzar a realizar un
viaje completo. Del mismo modo, los cambios que son de naturaleza
transformadora podrían tomar la ruta POC para dar a los patrocinadores la
confianza de que la solución realmente funciona.
Bueno, POC es solo la mitad de la batalla para convencer a los
patrocinadores y otras partes interesadas de que una solución en particular
funciona. Después del éxito de un POC, las partes interesadas a menudo
inician la siguiente fase de desarrollo, llamada fase piloto, y no un desarrollo
completo.
Un piloto es el siguiente paso en el proceso de desarrollo después de POC,
donde la idea es tomar una parte de la funcionalidad, desarrollarla y probarla,
y ejecutarla con datos reales. Un resultado exitoso prueba aún más que el
camino tomado realmente funciona. Los probadores de liberación piloto serán
limitados; llámelos un grupo privado que prueba la funcionalidad desarrollada
y da su opinión.
368
Nota No se confunda entre las versiones piloto y
beta. Ambos son diferentes. En una versión piloto, solo
desarrolla una pequeña parte de la funcionalidad para
demostrar que la solución general seguirá su ejemplo.
una versión beta generalmente tiene errores, lo que
significa que las pruebas y la corrección aún están en
marcha. una versión beta constará de la solución
completa o de una solución que se está completando.
Lanzamiento azul-verde
Buscar tiempo de inactividad para los lanzamientos es cosa del pasado. En
los proyectos DevOps, la norma es llevar a cabo implementaciones sin
tiempo de inactividad, y la gestión de versiones debe hacer esto como
mínimo. Hay varias formas en que el proceso podría lograr esto. Un ejemplo
de ello es el enfoque de implementación azul-verde, donde dos entornos se
ejecutan en paralelo (cada uno de los entornos se designa con el color azul o
verde). La Figura 13-3 ilustra el enfoque de liberación azul-verde.
369
Figura 13-3. Enfoque de liberación azul-verde
370
Tenemos dos entornos paralelos, designados como azul y verde. Ambos

entornos son idénticos; sin embargo, uno de ellos es activo y el otro pasivo.
En este ejemplo, digamos que el entorno azul está activo y el verde es pasivo.
Esto se refiere al equilibrador de carga que enruta todas las solicitudes de los
usuarios solo al entorno azul y no al entorno verde.
Digamos que tenemos un lanzamiento disponible que requiere un tiempo
de inactividad obligatorio para instalar y configurar paquetes, seguido de
largas revisiones de cordura. En este escenario, el nodo pasivo (verde) se
implementa primero. Como no se enrutan solicitudes de usuarios, no se trata
de buscar tiempo de inactividad. Los usuarios continúan operando
normalmente en el entorno azul. Cuando la implementación es exitosa y el
entorno está listo para la producción, el balanceador de carga enruta todas las
solicitudes de los usuarios al entorno verde. Mientras los usuarios están
ocupados operando en el entorno verde, el entorno azul deja de funcionar, se
implementa y queda listo para la producción. El equilibrador de carga puede
volver a configurarse en azul o compartirse entre verde y azul; Esta es una
decisión de los arquitectos. ¡Voila! Ambos entornos se implementaron con
paquetes que requerían tiempo de inactividad, pero los usuarios nunca
sintieron los efectos del tiempo de inactividad.
Alternancias de funciones (también

conocidas como indicadores de funciones)
El uso de alternancias de funciones es una técnica de desarrollo de software
mediante la cual realiza cambios en las funciones sin realizar cambios en el
código. Durante el ciclo de vida de diseño y desarrollo, los desarrolladores
emplean la técnica de bifurcación para crear múltiples bifurcaciones de
funciones. Se introducen conmutadores (interruptores) de funciones que
activan o desactivan la función en función de ciertos criterios.
Tome el ejemplo ilustrado en la Figura 13-4 . El producto (por ejemplo, un
portal de compras) consta de tres funciones que se alternan: F1, F2 y F3.
Durante el desarrollo, se desarrollan las tres funciones, pero solo F2 y F3 se
han activado para que los usuarios las consuman. Por lo tanto, aunque la
371
función F1 está disponible en el producto, los consumidores no pueden usarla
porque la palanca está desactivada.
Cuando llega diciembre, cuando comienzan las compras navideñas, se

activa la función F1, que está diseñada para presentar ciertas promociones para
atraer compradores (es decir, se activa). Los usuarios podrán ver la función F1
en acción. Todos estos cambios de características se introdujeron sin realizar
cambios en el código; todo lo que se hizo fue cambiar los interruptores de
palanca a través de un archivo de configuración.
Figura 13-4. La función alterna la ilustración
El uso de alternancia de funciones es una técnica eficaz para minimizar los

riesgos que se presentan debido a los cambios que se introducen en el sistema.
Imagine que durante el tiempo de compras navideñas, realiza un cambio de
código y un error en el sistema hace que todo el portal se caiga durante 20
372
minutos. El tiempo de inactividad genera pérdidas de ingresos y de reputación
del portal. Para evitar tales desventuras, los cambios de función se introducen
con mucha antelación y, cuando se necesitan, se activan y desactivan.
Esta no es la única aplicación de alternancia de funciones. Puede segregar

su comunidad de usuarios en función de varios criterios, ya sea el nivel de
servicio al que está suscrito, la ubicación geográfica, etc. Al alternar funciones,
los usuarios del Reino Unido obtienen las funciones F1 y F2, los usuarios de
los Estados Unidos obtienen F2 y F3, y los usuarios de la India pueden
disfrutar de todas las funciones (F1, F2 y F3), por ejemplo.

servicio
Tabla 13-1. Gestión de versiones en SVC
Actividad de
CVS
plan Medio los planes de liberación para acordar
el cronograma, los tipos y las técnicas
de liberación se definen y acuerdan
durante esta actividad.
Diseño y alto El corazón de la práctica de gestión
Transición de versiones trabaja en estrecha
coordinación con la actividad de
Diseño y Transición.
obtener/ Medio Los componentes de la versión se
construir construyen y prueban en la actividad
de obtención/construcción.
comprometer Bajo Las mejoras y las reparaciones que
se realizan se acuerdan con la base
de clientes o provienen de varios
terceros.
entregar y Medio Las versiones cambian el servicio
Apoyo existente y esto requiere
373
documentación actualizada,
capacitación y nuevos métodos para
brindar soporte. gestión de la
liberación
la práctica proporciona los artefactos
necesarios y el conocimiento
necesario para el apoyo.
Mejorar Bajo Los elementos de mejora también
pasan por el ciclo de diseño,
construcción y lanzamiento.
Gestión de implementación
La gestión de la implementación es una de las tres prácticas de gestión técnica.
Es una práctica nueva desde la perspectiva de ITIL, o una expresión precisa
sería que la gestión de implementación fue golpeada con la gestión de
lanzamiento en ITIL V3.
Definición de ITIL de práctica de gestión de implementación
El propósito de la práctica de administración de implementación
es mover hardware, software, documentación, procesos o
cualquier otro componente nuevo o modificado a entornos
activos. También puede participar en la implementación de
componentes en otros entornos para realizar pruebas o pruebas.
La práctica existe para proporcionar orientación sobre las
implementaciones. Un malentendido general es que las implementaciones se
refieren solo a mover paquetes al entorno de producción. Sin embargo, no es
cierto. Mover paquetes de software a cualquiera de los entornos inferiores
también son implementaciones. La implementación esencialmente significa el
movimiento del punto A al punto B. Lo más probable es que el punto A sea un
repositorio de artefactos y el punto B podría ser cualquiera de los entornos que
se encuentran bajo el alcance de la práctica de administración de
implementación.
374
Además, las implementaciones generalmente se conocen como
movimiento de paquetes de software a entornos. Desde el punto de vista de
ITIL 4, el despliegue de infraestructura también entra dentro del ámbito de la
práctica. La implementación de la infraestructura es una actividad basada en la
infraestructura, entonces, ¿cómo se relaciona con el traslado de un lugar a
otro?, podría preguntarse. Hoy en día, la mayor parte de la infraestructura en
boga está en la nube, y la infraestructura de aprovisionamiento es
generalmente un ejercicio de codificación. Usando un código (denominado
Infraestructura como código), la infraestructura se puede construir en la nube.
Básicamente, está moviendo los recursos de un grupo genérico a un grupo
específico y aprovisionando una infraestructura dedicada para un uso
exclusivo. Esto es esencialmente despliegue de infraestructura, de ahí su
inclusión en el alcance de ITIL 4 bajo la práctica de gestión de despliegue.
Para reiterar, el alcance de la práctica de gestión de despliegue cubre:
1. Despliegue de paquetes de software a entornos inferiores y de

producción
2. Despliegue de infraestructura para entornos inferiores y de
producción
Enfoques de implementación
Como se discutió anteriormente, las implementaciones mueven paquetes del
punto A al punto B. El concepto es bastante simple, pero piense en el volumen,
la complejidad y las restricciones que podrían existir. Compáralo con una
empresa de mensajería como DHL que necesita enviar paquetes a todo el
mundo. ¿Cómo mueven a sus mensajeros? ¿Envían el paquete de cada cliente
por separado o agrupan a sus clientes que van a un lugar en particular juntos?
¿Qué pasa si hay mercancías peligrosas? ¿Se enviarán en un avión junto con
los otros paquetes, o se enviarán por barco u otros medios? Mientras comienza
a pensar de esta manera, puede comprender cómo las implementaciones son
bastante complejas y por qué justifican una práctica separada, con razón.
375
En función de diversas circunstancias atenuantes, existen múltiples
enfoques para las implementaciones. Algunos de los más populares son:
1. Despliegue de gran explosión
2. Despliegue por fases
3. Entrega continua
4. Despliegue de extracción
Despliegue del Big Bang

La opción del big bang se deriva de la teoría del big bang, que establece cómo
surgió el universo a partir de una sola superfuerza. Del mismo modo, cuando
se implementa el software, se implementa en todo lo que está bajo el alcance
en el mismo momento. En otras palabras, todos los usuarios experimentarán el
software (o el trauma de la implementación) al mismo tiempo.
Este tipo de implementación se conoce como implementación big bang.
También se denomina implementación paralela. Por lo general, una
implementación piloto para un conjunto de muestra de usuarios es seguida por
una implementación más grande, en este caso, una gran explosión. En la
ilustración de la Figura 13-5 , el paquete de lanzamiento se implementa en las
regiones 1, 2, 3 y 4 al mismo tiempo.
376
Figura 13-5. Enfoques de implementación por etapas y big bang
La ventaja es que todos los usuarios podrán disfrutar de los servicios

actualizados al mismo tiempo, y el proveedor de servicios puede afirmar que
es coherente con sus servicios. Esto generalmente está precedido por un piloto
(o varios pilotos) para garantizar que el software funcione.
Cuando el piloto se considera exitoso, se establece un tiempo y se informa

a los usuarios, y luego todo el alcance del sistema de destino recibirá el
paquete de lanzamiento.
La opción del big bang casi nunca se considera en estos tiempos
modernos. Es posible que haya notado que los lanzamientos ocurren primero
en ciertas regiones más pequeñas (piloto) seguidas, por ejemplo, de los
Estados Unidos. Se sabe que las actualizaciones de iOS siguen este patrón. La
desventaja de desplegar a todos a la vez es bastante significativa. Cualquier
error resultará en un desastre, y el impacto comercial negativo que sigue es
insoportable. Por lo tanto, a ninguna organización le gusta correr riesgos
empujando todo en todo el mundo de una sola vez.
Implementación por fases

La alternativa a la opción big bang es implementar por etapas. En la Figura
13-5 , un piloto inicial para un conjunto de muestra de usuarios es seguido
por una implementación por etapas en la región 1 primero, seguida por las
regiones 2, 3 y 4. Está bien que las implementaciones tengan semanas y
meses entre ellas para permita que el aprendizaje se asiente y que se
implementen acciones correctivas antes del siguiente lanzamiento. Esta es la
mayor ventaja de un enfoque por etapas. Las organizaciones pueden
administrar sus riesgos y dirigirse a su audiencia en función de varios
parámetros. Por ejemplo, supongamos que a una organización le gustaría
implementar paquetes durante los tiempos de inactividad habituales en
diferentes regiones del mundo. Esta puede ser la temporada de Diwali en
India, Navidad en el Reino Unido y Rosh Hashaná en Israel.
377
No veo ninguna desventaja obvia en el enfoque por etapas, excepto que
requiere mucha planificación continua y diferencias en la versión de
lanzamiento entre los usuarios, por lo que esto puede terminar siendo un
desafío de soporte. Pero hay varias maneras de mitigar esto.
Hay múltiples variaciones de enfoques por fases que se pueden concebir,

además de las implementaciones geográficas descritas anteriormente:
Las diferentes funciones se implementan por separado,
por lo que los usuarios pueden disfrutar de ciertas
funciones primero y luego obtener el resto más tarde.
Todos los usuarios se enfrentan al tiempo de inactividad
al mismo tiempo, aunque la implementación se realiza
en fases. Esto generalmente se refiere a una
implementación que se lleva a cabo inmediatamente
después de una anterior.
Una combinación de implementaciones geográficas,
implementaciones basadas en funciones y tiempo de
inactividad para todos
Entrega/implementación continua
Discutimos la entrega continua y la implementación continua en el Capítulo 2 .
La pieza de software que se construye y prueba está lista para implementarse
(o se implementa) en producción. Por lo tanto, la implementación no espera a
que ninguno de los parámetros, ni a que se agrupen otros paquetes, antes de
implementarse en producción. Se desarrolla y luego de una prueba exitosa, se
implementa en producción, de manera sencilla. Esto se ilustra en la Figura 13-
6.
378
Figura 13-6. Entrega/implementación continua
379
La simplicidad existe porque no hay restricciones que impidan que la
pieza de funcionalidad desarrollada entre en producción. Este es un escenario
ideal que facilita la forma en que se entregan los paquetes a los clientes sin
adornos ni emociones. Como ya sabe, en la entrega continua se necesita un
disparador manual para implementar en producción; en la implementación
continua, la implementación en producción está automatizada, lo que
significa que no hay activadores manuales para mover los paquetes a
producción.
Es simple y directo. Pero no deja de tener su rango de riesgos. Existe la
carga de hacer las cosas bien la primera vez, y el riesgo de exponer fallas a los
usuarios finales exige una determinación cuidadosa y tal vez controles de
calidad; el papel de los humanos en este proceso sería mínimo. También existe
una (excesiva) dependencia de la automatización para mantener las
canalizaciones fluyendo desde el ciclo de integración continua del desarrollo
hasta que se implementa en producción. Pero hacer que la entrega continua
funcione es un resultado basado en el pensamiento profundo y la madurez de
la organización en la ejecución de DevOps y la automatización.
Despliegue de extracción
Los tres enfoques anteriores que vimos eran enfoques de inserción, en los que
los paquetes se empujaban desde una herramienta a producción oa una
máquina de usuario final. El usuario final no tenía muchas opciones más que
aceptar estos paquetes. ¿Qué sucede si el usuario final se encuentra en medio
de una presentación para un cliente cuando se le ofrece un paquete de software
que es de naturaleza abierta? Piense en esos mensajes de reinicio que recibe en
sus computadoras portátiles y en lo molestos que pueden ser cuando está en
medio de alguna actividad. ¡Puedo decir que comparto tu dolor!
Imagínese si tuviera el poder de instalar los paquetes cuando los necesita
en lugar de hacerlo cuando lo necesitan, como después de completar todo su
trabajo y justo antes de cerrar la sesión del día. Eso sería maravilloso, en mi
opinión.
380
La opción de implementación de extracción existe, aunque no es tan
popular como los otros tres enfoques. En este enfoque, los paquetes de
software se ponen a disposición de los usuarios y se notifica a los usuarios.
Entonces, los usuarios básicamente seguirán un conjunto de instrucciones
(como hacer clic en un enlace específico) para extraer los paquetes en su
propio momento. Los paquetes de software generalmente residen en un
depósito de software llamado biblioteca de medios definitiva (DML), y los
usuarios tendrán acceso para descargar un paquete y permiso para instalarlo en
sus computadoras portátiles.
Uno de los procesos comunes para lograr esto es a través de la práctica
de gestión de solicitudes de servicio. Digamos que un usuario quiere algún
software y se le pide que registre una solicitud de servicio con los detalles
apropiados. Una vez que se aprueba la solicitud de servicio, se envía un
correo electrónico con un enlace o un mensaje de notificación desde una
ventana emergente de software de implementación de extracción. El
usuario puede elegir activar la instalación/movimiento del paquete de
software a su conveniencia. Este método es efectivo para garantizar que la
productividad del usuario no se vea afectada y para garantizar la máxima
retroalimentación de satisfacción del cliente.
Esta podría no ser una opción para todo clima. Si hay actualizaciones
de seguridad urgentes que deben implementarse más temprano que tarde,
entonces la mejor opción es posiblemente la mejor opción. En conclusión,
una organización debe tener todas las opciones bajo la manga y debe
utilizar los enfoques en las circunstancias apropiadas.
Nota El término implementación también podría

referirse a retirar ciertas funciones, lo que
necesariamente significa limpiar el código y actualizar los
paquetes más antiguos con los más nuevos.
381
Proceso de implementación
La gestión de implementación es una práctica del grupo de gestión técnica en
ITIL. No debe confundirse con una práctica que se ocupa únicamente de
herramientas y técnicas. Hay aspectos del proceso que son críticos para que el
objetivo de la práctica sea un éxito.
Puedo dividir el proceso de implementación en tres actividades principales:
1. Planificación de la implementación
2. Despliegues
3. Revisar y cerrar
Planificación de la implementación
Un buen plan te hace ganar la mitad de la batalla. Cuando se trata de
implementaciones, no es diferente. Debe planificar la implementación en
términos de tiempo, enfoque y personas involucradas en llevar a cabo la
implementación. A continuación, el modo de implementación también es
importante. ¿Se hace manualmente o mediante la automatización o una
combinación de ambos?
Ordenar la propiedad
En primer lugar, la propiedad debe ser resuelta. ¿Quién va a realizar los
despliegues? El sentido común dice que el equipo responsable de los aspectos
operativos del medio ambiente debe realizar las actividades de liberación. Esta
es una forma ideal de mantener la responsabilidad con un solo equipo y no
mantener los entornos vulnerables a los cambios de varios grupos.
Entornos complejos
¿Cómo lidia con un entorno en el que participan múltiples proveedores?
382
Es importante comenzar a trazar los límites y las responsabilidades de
cada proveedor. Su resultado probablemente dirá, por ejemplo, que el
proveedor A es responsable de todos los cambios relacionados con un sistema
SAP. Todos los paquetes que se implementarán en SAP deben ser examinados
por el equipo de SAP.
Esto se puede lograr con un CMS sólido. A menos que tenga un buen
CMS en la organización, no sabrá qué sistemas existen y cómo interactúan
entre sí. Sin esta información, estaría disparando en la oscuridad en el mejor
de los casos.
Mantenga los procesos consistentes pero no

comunes para los entornos
Hay múltiples entornos en cualquier organización donde se mueven los
paquetes de software. No se necesita el mismo nivel de escrutinio para todos
los entornos. Un proceso diferente para cada entorno es práctico. Sin embargo,
mantenga estos procesos consistentes para todas las implementaciones que se
realicen.
Por ejemplo, para un entorno de prueba, puede buscar una aprobación de
un solo paso del administrador de desarrollo antes de mover un paquete al
entorno. La aprobación es un sello de que todos los errores que se identifican
en el entorno de desarrollo se corrigen a niveles satisfactorios. Para pasar al
entorno UAT, es posible que necesite dos conjuntos de aprobaciones: una del
administrador de pruebas y la siguiente del propietario del producto. Mover
los cambios a producción puede seguir el proceso de control de cambios.
Entonces, encontrará que el proceso para mover paquetes es diferente para
cada entorno, pero es consistente para todos los proveedores y equipos que
están involucrados.
383
Implementaciones de infraestructura
Las implementaciones de infraestructura funcionan de manera similar a los
paquetes de software. El proveedor de servicios generalmente tiene la
propiedad de la infraestructura. A medida que se necesitan nuevos
componentes de infraestructura, se activan; se puede controlar cada nuevo
despliegue de componentes.
¿Qué pasa con los despliegues que realizan los proveedores? Por ejemplo,
Microsoft instala parches de seguridad y VMWare también realiza parches
urgentes. Si el proveedor tiene libertad para instalar parches según sea
necesario en las máquinas host, ¿cómo conserva el proveedor de servicios el
control de las implementaciones de infraestructura?
Es imperativo que los proveedores proporcionen la información (y
busquen la aprobación) de los parches que se están implementando con
anticipación, o que proporcionen los parches al proveedor de servicios para
planificar las implementaciones por su cuenta. De esta manera, los
proveedores de servicios seguirán teniendo el control, que es la posición
correcta para estar. Querría que el propietario tuviera el control total de los
cambios que se proponen y que se están realizando.
Despliegues
La implementación real que se llevará a cabo se realiza durante la ventana de
cambios para las implementaciones de producción y durante los tiempos
designados para los entornos que no son de producción; esto está dirigido por
los procesos para el entorno particular.
Los despliegues se realizan en base al enfoque acordado y al utillaje
identificado. Es importante que las personas involucradas en las
implementaciones sean los equipos que tienen la responsabilidad de
implementar en el entorno, y trabajarán en estrecha colaboración con los otros
equipos cuyos paquetes se están moviendo. Por ejemplo, si un proveedor
desea instalar un complemento de producto COTS en un servidor de
384
producción, el técnico del proveedor también estará presente durante la
actividad de implementación, junto con el equipo operativo que tiene la
propiedad de los entornos.
También es una buena idea realizar un seguimiento de todas las
actividades realizadas durante las implementaciones. Mantenga un registro
con marca de tiempo, para ayudar en análisis futuros según sea necesario.
Revisiones de implementación
De manera similar a la realización de revisiones posteriores a la
implementación después de realizar un cambio, también se deben emplear
revisiones específicas de la implementación. Esto proporciona una idea del
estado de la implementación y una herramienta para aprender y mejorar la
madurez del proceso de implementación.
En DevOps, se le da mucho peso al aprendizaje y la experimentación. Una
de las mejores formas de aprender es registrar lo que se hizo y luego revisar
los registros para encontrar inconsistencias.
Mediateca definitiva
El DML es un depósito para almacenar todas las copias con licencia del
software adquirido y el software que se ha desarrollado internamente. El
repositorio puede ser en línea o físico, pero debe tener control de acceso.
El software que se acepta en la DML está controlado por la práctica de
control de cambios, y solo se permite el uso de aquellas copias autorizadas por
el control de cambios en la DML durante los procesos de gestión de
lanzamiento e implementación. Se espera que el software que ingresa al DML
sea analizado, probado en calidad y verificado en busca de vulnerabilidades
antes de ser aceptado.
En el caso de un DML físico en el que se utilizan CD, DVD y otros
medios de almacenamiento, se espera que la instalación de almacenamiento
sea a prueba de incendios, pueda soportar los rigores normales de la naturaleza
y sea segura contra robos de medios.
385
El DML se diseña idealmente durante la fase del ciclo de vida del diseño
del servicio, y se consideran los siguientes aspectos durante las etapas de
planificación:
• Medio que se utilizará y la ubicación de las copias maestras que
se almacenarán
• Arreglos de seguridad para el almacenamiento en línea y fuera de
línea
• Derechos de acceso, incluido quién tiene acceso y cómo se
controla
• La convención de nomenclatura para los medios almacenados
para facilitar la recuperación y el seguimiento
• Qué tipos de software entran en el DML, por ejemplo, códigos
fuente o paquetes
• Periodo de retención
• Plan de auditoría, lista de verificación y proceso
• Continuidad del servicio de DML si ocurre un desastre
Herramientas de implementación
Los despliegues se realizan generalmente mediante herramientas. Los días de
implementaciones manuales pronto se acercan a la extinción.
Las herramientas se automatizan utilizando una herramienta integradora
como Jenkins o Bamboo, o el personal de implementación las activa
manualmente. Hoy en día, la preferencia es construir una canalización en la
que las implementaciones sean parte de la canalización, para garantizar la
coherencia y evitar la intervención humana y, por lo tanto, los errores.
Las herramientas de implementación a menudo se integran en la suite de
desarrollo, como Azure DevOps, donde la herramienta de Microsoft incluye
386
aspectos de administración de código, administración de historias de usuario y
también administra implementaciones, junto con una serie de otras
funcionalidades.
No importa cómo se construya o configure la herramienta, hay algunas
cualidades que todas las herramientas deben poseer:
1. Las herramientas deben tener la funcionalidad para almacenar registros de
auditoría, lo cual es fundamental para las actividades de análisis y gestión
de problemas.
2. Debe haber una fácil integración con la práctica de control de cambios:
por ejemplo, cada implementación debe poder confirmar el número de
solicitud de cambio y el estado antes de que pueda desencadenar
implementaciones.
3. No hace falta decir que las herramientas de implementación deben ser
fáciles de usar y estables para garantizar la coherencia.
4. Las herramientas de implementación deben ser lo suficientemente
flexibles para integrarse con las diversas herramientas de desarrollo que
hay en el mercado y también exponer las API para que incluso las
herramientas personalizadas, si las hay, puedan aprovechar las
herramientas de implementación.
5. La integración con las herramientas de gestión de solicitudes de servicio
ayudará en las implementaciones de enfoque de extracción, que se
discutió anteriormente.
6. La integración con las herramientas de administración de configuración
garantizará que las implementaciones se rijan por la práctica fundamental,
que idealmente es la única fuente de verdad.

servicio
Tabla 13-2. Práctica de gestión de implementación en SVC
387
Actividad de
IntervenciónDetalles
CVS
plan ninguno La práctica de gestión de la
implementación no figura directamente
en la planificación general, ya que
generalmente se lleva a cabo a través
de la planificación de la gestión de
versiones.
Diseño y alto La práctica de gestión de
Transición implementación juega un papel
fundamental en el diseño y la transición,
ya que la práctica está en el centro de la
transferencia de paquetes a los
entornos.
obtener/construiralto En un proyecto Devops, la diferencia
entre obtener/construir e
implementaciones es inexistente, ya que
la naturaleza incremental del desarrollo y
las implementaciones garantiza una
estrecha colaboración entre los dos.
comprometer ninguno La gestión de la implementación no tiene
un papel directo que desempeñar con
los usuarios finales u otras partes
interesadas.
entregar y ninguno La gestión de la implementación no tiene
Apoyo un papel directo que desempeñar con la
entrega de servicios o su soporte.
Mejorar Bajo Las mejoras, al igual que otras mejoras y
cambios, pasan por el ciclo de
lanzamiento e implementación.
13-1. ¿ Cuál de las siguientes es la definición de versión correcta?
A. Una versión de un servicio u otro elemento de configuración, o un
388
colección de elementos de configuración, que está disponible para su uso
B. Un servicio que se implementa en un entorno que utilizan los usuarios.
C. Una implementación que consta de paquetes de software e infraestructura
que cambian la funcionalidad del servicio.
D. Cualquier cambio que tenga importancia para la gestión de un servicio u
otras adiciones, eliminaciones y modificaciones 13-2. ¿Cuál de los
siguientes no es un tipo de liberación?
A. Lanzamiento importante
B. Lanzamiento estándar
C. Liberación de emergencia
D. Lanzamiento menor
13-3. ¿Cuál es la diferencia entre un POC y un piloto?
A. Se realiza un POC para demostrar que la solución se puede implementar.

Un piloto desarrolla e implementa una pequeña parte de la funcionalidad.
B. Se lleva a cabo un POC para proporcionar amplia prueba de que los
servicios
siguen siendo válidos. Se utiliza un piloto para garantizar que el
servicio sea adecuado para su propósito.
C. Se realiza un POC para garantizar la participación del patrocinador y para
proporcionar una prueba válida de que la solución es válida. Un
piloto proporciona especificaciones funcionales que prueban
aún más que la solución está en el camino correcto.
D. Un POC se utiliza para generar cambios de transformación en un producto
o servicio. Se aprovecha un piloto para identificar una funcionalidad que se
puede desarrollar y probar con éxito.
389
13-4. ¿Cuál de los siguientes no es un tipo válido de enfoque de
implementación?
A. Despliegue por fases
B. Despliegue continuo
C. Entrega continua D. Despliegue de emergencia
13-5. ¿Cuál es el papel de un DML?
A. Un repositorio donde se almacena el código de software y se envía a la

canalización para su posterior construcción y prueba.
B. Un repositorio que almacena repuestos de TI y software al que solo puede
acceder personal válido
C. Un repositorio para almacenar todo el software utilizado por la
organización para brindar servicios a los usuarios finales
D. Un depósito para almacenar todas las copias con licencia de los
software y software que ha sido desarrollado internamente
390
DÍA 7

El último día, observamos la práctica de la mesa de servicio, que es la práctica

final que se cubrirá en el examen. Se proporcionan consejos y trucos para ayudarlo
en el examen y también para responder algunas de las preguntas más frecuentes
desde una perspectiva profesional de ITIL.
CAPÍTULO 14
La mesa de
servicio
La mesa de servicio es un componente integral del marco de ITIL, y la mayoría de
las implementaciones de ITIL priorizan el diseño y la implementación de la mesa
de servicio y sus prácticas asociadas sobre otras. Es más una práctica dirigida por
personas que una dirigida por procesos. Hasta ahora, las prácticas que hemos visto
están definidas por sus procesos. La práctica de la mesa de servicio es diferente
del resto.
La mesa de servicio actúa como la cara de la organización proveedora de
servicios para los usuarios, proveedores, otros proveedores de servicios e incluso
clientes. La mesa de servicio es el único y primer punto de contacto para las partes
interesadas identificadas. Si tiene un problema con la factura de su teléfono móvil,
llama a su proveedor de servicios de telefonía celular y la persona al otro lado de
la línea es de la mesa de servicio.
Dado que la mesa de servicio sirve como único y primer punto de contacto, a
menudo se convierte en la cara de la organización proveedora de servicios. Por lo
tanto, se convierte en una actividad de suma gravedad garantizar que la mesa de
servicio sea adecuada para representar a la organización proveedora de servicios
con etiqueta profesional. Generalmente, la imagen de una organización depende de
la mesa de servicio. Solo piensa en ello. Si la mesa de servicio de su proveedor de
servicios de telefonía celular le da la espalda por un problema real que está
enfrentando, ¿mide el desempeño del proveedor de servicios en función de esta
interacción? Definitivamente lo haría, incluso si el servicio hubiera sido impecable
hasta ese momento, porque una sola interacción puede romper una base sólida
construida a lo largo de los años. Llegaré a las partes jugosas de la práctica de la
mesa de servicio más adelante en este capítulo. Esta es la última de las prácticas
que se incluyen en el examen ITIL Foundation.

6361-7_14
Consejo de examen Aunque vamos a discutir una sola

práctica en este capítulo, es una práctica clave y puede
esperar unas tres o cuatro preguntas en el examen de
Fundamentos de ITIL sobre la práctica de la mesa de
servicio. Se evaluará su conocimiento profundo sobre los
temas de la práctica de la mesa de servicio.
Práctica de la mesa de servicio

En el marco ITIL actual, la mesa de servicio se incluyó como una función junto
con la gestión técnica, la gestión de aplicaciones y las operaciones de TI. Una
función es un equipo o grupo de personas que tienen conjuntos de habilidades
específicas y que debían ser profesionales de procesos.
ITIL 4 ha reinventado la mesa de servicio como una práctica, en el mismo
tablón que el resto de las prácticas; no hay distinción entre procesos y funciones,
ya que el objetivo final es ser responsable de entregas definidas y objetivos
establecidos. Antes de continuar, veamos la definición de la práctica de la mesa de
servicio.
Definición de ITIL de la práctica de la mesa de servicio
El propósito de la práctica de la mesa de servicio es capturar la
demanda de resolución de incidentes y solicitudes de servicio.
También debe ser el punto de entrada y único punto de contacto
del proveedor de servicios con todos sus usuarios.
La mesa de servicio sirve como la primera línea de soporte para la
organización proveedora de servicios, además de ser el primer punto de contacto.
Si la mesa de servicio no puede respaldar la resolución de un incidente o el
cumplimiento de una solicitud de servicio, se escala a la segunda línea de soporte
y luego a la tercera si la segunda línea no está en condiciones de resolver. En una
organización que da soporte a una aplicación, generalmente la primera y la
segunda línea de soporte
CAPÍTULO 14 EL MESA DE
SERVICIO
ofrecer cambios de configuración. Si la resolución requiere cambios en el

código, se envía a la tercera línea de soporte. La tercera línea de soporte es
parte del equipo de producto/DevOps. Esto se representa en la Figura 14-1 .
Figura 14-1. Líneas de soporte típicas en una organización DevOps
De acuerdo con el propósito de la mesa de servicio, hay dos partes

principales:
1. Actuar como conducto para registrar incidentes y solicitudes de
servicio
2. Actuar como un único punto de contacto para los usuarios.
Todas las organizaciones tienen un lugar para una mesa de servicio de una
forma u otra.
Hay un lugar especial para ellos, incluso si están tripulados por máquinas. La
mesa de servicio se presenta como la cara de los clientes; quizás en la mayoría
de los casos sea la única cara, o lo que es lo mismo, el único punto de contacto
para clientes o usuarios. Cuando los usuarios se comunican con ellos, lo hacen
con un propósito: están enfrentando uno o dos problemas con los
servicios/productos o están llamando para solicitar algo. La mesa de servicio,
si bien actúa como el único punto de contacto, también es uno de los canales
394
SERVICIO
confiables para registrar incidentes y solicitudes de servicio. No es solo el acto
de iniciar sesión, sino más bien la acción de iniciar sesión y proporcionar un
número de referencia para el seguimiento,
lo que le da al usuario/cliente la confianza de que alguien está analizando el
problema. La misma confianza se ve muy disminuida o ausente cuando
aparece un mensaje automático que confirma el registro del problema.
¿Por qué una Mesa de Servicio?

Hubo un tiempo en que no existía una mesa de servicio en las
organizaciones proveedoras de servicios. No vieron la necesidad de uno en
ese momento, ya que la organización y la base de usuarios eran pequeñas.
Siempre que los usuarios tenían que reportar incidentes, conocían a los
técnicos y los contactarían directamente. Durante esos días (antes del
amanecer de la era de la información), la cantidad de usuarios finales de TI
era manejable. La relación directa con los equipos técnicos les ayudó a hacer
el trabajo.
Hoy en día, hay miles de usuarios finales de TI que trabajan las 24 horas,
en múltiples ubicaciones y utilizan varios dispositivos de TI para realizar su
trabajo. Si se pudieran imaginar los tiempos en que no había mesa de servicio
disponible, piense en todas las llamadas que el equipo técnico comenzaría a
recibir. ¿Cómo se aseguraría el equipo técnico de que la carga se distribuyera
entre el equipo? ¿Cómo sabría el equipo técnico si el usuario estaba llamando
al técnico correcto? ¿Cómo decidirían la prioridad: en qué temas trabajar
primero y cuáles retomar más tarde en el día o la semana? La respuesta es que
es imposible pensar en la gestión de servicios de TI funcionando sin una mesa
de servicio. Canaliza los factores desencadenantes y los enruta a los grupos
correctos de personas. Prioriza incidentes y solicitudes de servicio para ayudar
a los equipos técnicos a actuar primero en prioridades más altas.
Hubo un tiempo en que se requería que los proveedores de servicios de TI
proporcionaran un caso comercial para instalar mesas de servicio. ¡Ya no!
Aquí están los otros beneficios de tener una mesa de servicio:
395
SERVICIO
• Mejora la accesibilidad al personal de TI para usuarios finales,
clientes y proveedores de TI
• Optimiza el uso de los recursos de TI
• Mejora el servicio al cliente y la emoción del cliente.
• Proporciona una respuesta más rápida en las solicitudes de servicio
• Optimiza el costo de brindar soporte de TI
Permítanme explicar el último elemento aquí. No se requiere que las

personas que trabajan en la mesa de servicio posean mucha experiencia, ni se
espera que sean técnicamente sólidos. Es un puesto que abre sus puertas a
recién graduados universitarios y aquellos que deseen comenzar sus carreras
en TI. Uno de los principales requisitos para trabajar en un service desk es una
buena capacidad de comunicación, tanto telefónica como escrita.
Mencioné que se optimiza el costo de brindar servicios de TI. La mesa de
servicio contrata a buscadores de empleo de nivel inicial a quienes se les paga
menos que a un profesional técnico experimentado.
Por lo tanto, al contratar recursos menos calificados, se reducen los costos
operativos y esto proporciona una situación en la que todos ganan para los
recién graduados, los proveedores de servicios de TI y los clientes (ya que el
beneficio de la reducción de costos se transfiere al cliente).
Negocios y Tecnología
No hace mucho tiempo, cuando la TI comenzó a crecer, se planteó por primera
vez el concepto de una mesa de servicio para ayudar a los usuarios a llamar y
registrar sus problemas. En ese entonces no se llamaba mesa de servicio; el
término más utilizado fue mesa de ayuda. Incluso hoy en día, muchas
organizaciones se refieren a sus mesas de servicio como una mesa de ayuda.
Dejando a un lado las nomenclaturas, una mesa de ayuda estaba destinada
a cumplir una sola función: funcionar como un único punto de contacto para
que los usuarios informen problemas. Cuando se reinventó ITIL en su segundo
ser, se le dio un alcance más amplio a la mesa de servicio para que no solo sea
un único punto de contacto para los usuarios, sino también para los
396
SERVICIO
proveedores y clientes. Estaba destinado a ser una ventanilla única para todas
las cosas en TI; para cualquier problema con TI, comuníquese con la mesa de
servicio, sin importar cuál sea su estado. Este concepto funcionó
maravillosamente bien, con la mesa de servicio manejando varias funciones,
incluyendo reconocer a las personas que llamaron, clasificar incidentes,
hacerse cargo de ellos y también actuar como la primera línea de soporte. Se
imaginó una mesa de servicio madura para administrar de forma independiente
alrededor del cincuenta por ciento de los tickets totales que llegaron a través
del sistema. Fue un gran éxito, especialmente por la presencia de recursos
menos calificados, lo que significaba que podían establecerse en un país donde
la mano de obra era razonable.
Mientras se cerraba la brecha entre el negocio y la TI, y ambos se unían
por la cadera, la TI pasó de ser un proveedor de servicios a ser un socio
sentado en la mesa que tomaba decisiones. Si bien la TI comenzó a ocupar
parte del espacio comercial, era hora de regresar en especie. La interfaz entre
TI y el negocio, la mesa de servicio, se reinventó una vez más. ¿Qué tal si la
mesa de servicio no solo existe para problemas de TI sino también para otros
problemas como limpieza, electricidad, administración, etc.? y proporcionando
soluciones solo para problemas técnicos, pero también para una gran cantidad
de otros tipos de problemas.
La mayoría de las organizaciones han insistido en este modelo, creando
una mesa de servicio única. Para las personas que llaman, los IVR enrutan sus
llamadas al personal de la mesa de servicio que tiene habilidades
especializadas que están buscando; la misma mesa de servicio está a cargo de
personas con diferentes conjuntos de habilidades. Cada persona tiene un
conjunto de habilidades principales y uno secundario. Si una persona que
llama llama sobre un viaje, entonces el agente de la mesa de servicio que está
capacitado y capacitado en consultas relacionadas con viajes responde la
llamada.
397
SERVICIO
Canales para llegar a la mesa de

servicio
Los procesos comerciales y de TI se han simplificado a lo largo de los años, lo
que sin duda es un objetivo que se está cumpliendo y recalibrando para
lograrlo. Las organizaciones ganan más dinero o ahorran a través de la
optimización.
Están las unidades de ventas y consultoría de la organización que se dedican a
ganar dinero y crecer, y se espera que la optimización ocurra desde adentro, lo
cual es razonable y lógico. Todos los que usan el proceso o tienen un papel
que desempeñar en un proceso tienen aportes válidos para las medidas de
optimización.
Los usuarios que se comunican con la mesa de servicio es una de esas
actividades que se ha simplificado a lo largo de los años y continúa
haciéndolo. Hubo un tiempo en que los usuarios tenían que caminar hasta la
mesa de servicio (y todavía lo hacen en algunos casos extremos) para registrar
incidentes y solicitudes de servicio. Los teléfonos entraron en escena, lo que
puso a los usuarios en una cola mientras los agentes seguían su principio de
primero en llegar, primero servido para conectarse con los usuarios. El tiempo
dedicado a visitar la mesa de servicio o llamarlos fue tiempo perdido, lo que
resultó en una pérdida de productividad y se inició la reacción en cadena de
pérdidas para la organización. Entonces surgieron medidas para salvar estos
esfuerzos perdidos; una acción principal fue permitir a los usuarios ayudarse a
sí mismos a través de diversas bases de conocimientos y herramientas de
autoayuda. El ejemplo clásico es el proceso de restablecimiento de contraseña.
Hubo un tiempo en que la mesa de servicio solía hacerlo. Convertir esto en
una función de autoayuda ahorró muchas horas no solo para los usuarios sino
también para el personal de la mesa de servicio. El principio que se aplicó fue
que cualquier cosa que no requiriera el poder del cerebro humano podría
automatizarse. Hablaré sobre la mesa de servicio y la automatización más
adelante en este capítulo.
Aquí se enumeran algunos de los canales para comunicarse con una mesa
de servicio y, en el momento de escribir este artículo, son relevantes. Se
podrían diseñar e implementar nuevos medios para cuando lea esta sección.
398
SERVICIO
También me gustaría agregar que los canales para llegar a la mesa de servicio
que se mencionan aquí no son completos, sino más bien los que se usan
ampliamente.
sin cita previa

El personal de la mesa de servicio solía sentarse en grupo, y recuerdo los días
en que los visitábamos en un piso superior y registrábamos nuestras
incidencias en un registro físico. El coordinador de la mesa de servicio solía
revisar el registro cada hora y asignar incidentes a los agentes en
consecuencia. La creación de esta mesa de servicio se promocionó como una
gran mejora, ya que la práctica anterior era comunicarse directamente con los
miembros del equipo técnico. No estoy hablando de una pequeña tienda de TI,
sino de una importante.
Que yo sepa, los mostradores de servicio sin cita previa ya no existen,
aunque existen otras formas de soporte técnico sin cita previa. Sin embargo,
los medios para llegar al mostrador de servicio merecen una mención de
honor a medida que avanzamos en algunas formas modernas a medida que
revisamos la lista.
Teléfonos
Cuando realiza una búsqueda de imágenes de Google para una mesa de
servicio, encontrará que la mayoría de las imágenes que ve son de una persona
hablando por teléfono con auriculares. Los teléfonos y los mostradores de
servicio se han convertido en sinónimos . Este fue el caso hace 1 año y no
parece que vaya a cambiar en la próxima década.
Llegar a la mesa de servicio por teléfono es, con mucho, el medio más
popular. Aunque la mayoría de las organizaciones de TI han tratado de
evitarlo, las empresas tradicionales y los gobiernos confían en él incluso hoy.
El problema con los teléfonos es doble. El usuario que llama debe pasar
por las opciones de IVR y luego elegir la opción anidada correcta. Esto podría
tomar fácilmente un par de minutos. En particular, odio llamar a las mesas de
servicio de los bancos por teléfono, pero no me dan muchas opciones para
plantear ciertas solicitudes de servicio y quejas. Si bien la opción IVR es
399
SERVICIO
dolorosa, el tiempo de espera antes de hablar con una persona y el tiempo que
dedicamos a identificarnos, explicar el problema y la resolución final, imagine
el tiempo que se pierde. Si fuera a implementar el marco Lean en una
organización, ¡este sería uno de los ejes seguro!
Habiendo dicho todo eso, hablar con un humano por teléfono es lo más
parecido a hablar cara a cara. Brinda al usuario un nivel de comodidad que no
se puede obtener a través de otros medios modernos. Si bien podría detestar
hablar con la mesa de servicio, sigue siendo el medio más popular porque la
comodidad que obtienen los usuarios y la posible resolución inmediata que
podría resultar durante la misma conversación es tranquilizadora.
Correos electrónicos
Los correos electrónicos han transformado la forma en que nos comunicamos.
Aunque son pasivos, la entrega confiable de mensajes del punto A al punto B y
la opción de responder en el propio horario lo han convertido en un estándar
de facto para la comunicación. Llegar a la mesa de servicio para registrar
incidentes es una forma de comunicación, y lo popular se vuelve popular entre
los usuarios que se comunican con las mesas de servicio por correo
electrónico.
Hay pros y contras en ambos lados. Desde la perspectiva del usuario,
enviar un correo electrónico es lo más fácil posible. Envío cerca de cuatro
docenas de correos electrónicos en un día normal, así que uno más a la mesa
de servicio es una gota en el océano. Si el incidente enfrentado no es de
inmediatez, está bien desde la perspectiva del usuario. El usuario no siente que
ha perdido su tiempo, en comparación con los medios telefónicos. La
resolución llega cuando llega, que está sujeta al SLA, y el usuario puede ver la
resolución cuando tiene tiempo libre. ¡Ya no tendrá que retrasar reuniones
mientras habla con el servicio de atención al cliente!
La mesa de servicio, por otro lado, no necesita preocuparse por las colas y
las caídas de llamadas, que es uno de los KPI que deben enfrentar. Pueden
acceder al correo electrónico y responder como mejor les parezca. La ventaja
es que obtienen tiempo adicional para pensar y responder, lo que no siempre es
posible en un teléfono, donde las respuestas deben pensarse en tiempo de
ejecución. La otra ventaja es que la mesa de servicio podría mantener
400
SERVICIO
plantillas para ciertas resoluciones comunes, y todo lo que necesitan hacer es
copiar y pegar, ¡listo! ¿Cómo desean las mesas de atención telefónica que sus
voces puedan ser grabadas y reproducidas tan pronto como identifiquen el
problema común que enfrenta el usuario?
El servicio entregado a través de correos electrónicos es relativamente más
lento, pero para problemas no urgentes y solicitudes de servicio, es el mejor
canal.
chateando
Mi canal favorito para comunicarme con la mesa de servicio es el chat. Es
como un teléfono, solo que no hablamos con ellos en tiempo real, sino que
chateamos. No es intrusivo, ya que podría chatear con la mesa de servicio
mientras estoy sentado en una reunión en la que no se requiere mi
participación activa. La mesa de servicio, por otro lado, no se ata, con un
agente retenido por un usuario. Un agente puede estar chateando con cinco
usuarios al mismo tiempo. Puede que la productividad no se multiplique por
cinco, pero definitivamente sería mucho mejor que la opción telefónica. El
usuario del otro lado no siente que está enviando una comunicación
unidireccional y podría terminar chateando con sus compañeros y con la mesa
de servicio.
Es una situación en la que todos ganan. Como usuario, mi primera
preferencia es buscar la opción de chat. Además, puedo guardar la
transcripción para referencia futura. Esa es una necesidad en estos días, ya que
se sabe que los agentes de la mesa de servicio son inconsistentes con sus
soluciones, especialmente las de Amazon. Como consultor de TI, recomiendo
que mis clientes promuevan el chat sobre las otras opciones.
Portales
A medida que la autoayuda se convirtió en una norma, los portales de servicio
donde los usuarios podían plantear sus propios incidentes en un formulario
web se convirtieron en algo normal. El principio es: ¿por qué necesita un ser
humano para hacer su trabajo sucio cuando puede articularlo mejor?
Muchas herramientas de gestión de servicios proporcionan una interfaz o
un contenedor para que el usuario registre incidentes o solicitudes de servicio.
401
SERVICIO
Podría ser tan simple como un formulario donde el usuario completa los datos
relevantes, o podría estar respaldado por un motor de inteligencia artificial que
pueda comprender el problema informado y enrutarlo directamente al equipo
correcto.
De hecho, muy pocas organizaciones enrutan los boletos que llegan a
través de un portal a la mesa de servicio. La mayoría trata de saltarse la mesa
de servicio por completo, para reducir los saltos y el tiempo de inactividad.
Hay pros y contras con los enfoques, como saltarse la mesa de servicio no
brinda uniformidad en la priorización de incidentes, y la categorización podría
ser un juego de azar.
Obviamente, la ventaja es que el equipo correcto detecta los incidentes de
inmediato, y están mejor equipados con conjuntos de habilidades
especializadas y pueden resolver problemas rápidamente.
Mensajería
Las tecnologías del siglo XXI han hecho posible reportar incidentes y
solicitudes de servicio a través de un teléfono móvil. Si bien el usuario es ágil
y dinámico, por qué obligarlo a constreñirse a una computadora portátil o estar
pegado a un teléfono para levantar boletos.
Los usuarios ahora pueden generar tickets usando Whatsapp, y la mesa de
servicio chitty chatty en el otro extremo de la conversación usa la misma
plataforma para proporcionar una resolución.
La otra opción de mensajería es usar el servicio de mensajes cortos (SMS)
para reportar incidentes y solicitudes de servicio. Este es más un enfoque
tradicional que básicamente lo hace interactuar con un programa de
computadora que recibe entradas y le da un número de boleto a cambio. Un
agente de la mesa de servicio recoge los detalles y puede optar por
comunicarse con usted por teléfono, correo electrónico o, si su día no va bien,
puede enviar su resolución a través de un
mensaje de texto.
El uso de mensajes de texto todavía está de moda en algunas empresas,
pero con más y más usuarios que no optan por ellos, el servicio pronto se
disolverá. El uso de Whatsapp, por otro lado, se está recuperando, y
402
SERVICIO
Whatsapp ha proporcionado un producto diferente llamado Whatsapp
Business que facilita el canal de comunicación y ya no es una comunicación
de teléfono a teléfono. En el otro extremo, los agentes de la mesa de servicio
usan computadoras portátiles para interactuar tal como lo harían en el chat.
Algunas organizaciones también usan bots para proporcionar información que
quizás ya conozca. ¿De qué sirve, te preguntarás? ¡Todavía estoy buscando
respuestas a esta pregunta!
Medios de comunicación social
Se han tomado todos los canales de comunicación posibles para llegar a la
organización proveedora de servicios. Los últimos en la lista son los canales
de redes sociales, siendo los más populares Twitter y Facebook.
Los usuarios pueden interactuar con la mesa de servicio planteando
problemas a través de Twitter o Facebook, y las respuestas también se
envían por el mismo canal. Es bueno usar los canales existentes, pero qué
divertido es si debes lavar la ropa sucia en público. No me gusta decirle al
mundo que no puedo reparar mi computadora portátil y que estoy
contactando a otra persona para que lo resuelva.
Dado que todo es de dominio público, a menudo se desalienta a los
usuarios a utilizar los canales de las redes sociales, ya que las interacciones
que realizan no se encuentran en los canales de mensajería privados, sino en la
página pública. Sin embargo, es una característica que está disponible para
llegar a la mesa de servicio.
Estructuras de la mesa de servicio

Compare la estructura de la mesa de servicio de su organización actual con las
estructuras de otras organizaciones. Definitivamente habrá claras diferencias
entre las estructuras y la forma en que operan. ¿Por qué las organizaciones
eligen construir su propia estructura y no seguir una estructura establecida
basada en ciertos principios estandarizados? La respuesta es la estrategia.
La estrategia impulsa cómo se estructuran las organizaciones. Algunas
estructuras funcionan mejor que otras, mientras que otras pueden generar
sinergia, generando más valor con el mismo grupo de personas. Se observa
403
SERVICIO
que las organizaciones tradicionales suelen optar por una estructura altamente
jerárquica, mientras que las nuevas empresas y las organizaciones de la nueva
era optan por una estructura plana. Hay ventajas y desventajas con ambos. Si
las ventajas superan las desventajas, las organizaciones están convencidas de
su justificación para optar por él.
404
SERVICIO
Dado que la mesa de servicio está a cargo de muchas personas, es imperativo

que la estructuración requiera una reflexión seria. Hay varias formas en que se
puede estructurar una mesa de servicio. Si se cumplen los objetivos centrales de la
mesa de servicio, se puede estructurar según sea necesario. En este libro, analizaré
tres tipos comunes de estructuras de mesa de servicio. Este es un tema importante
desde la perspectiva de la gestión de servicios y desde el punto de vista del
examen. Las tres estructuras de mesa de servicio más utilizadas son:
1. mesa de servicio local
2. mesa de servicio centralizada
3. mesa de servicio virtual
Mesa de servicio local

Como indica la nomenclatura de la estructura, una mesa de servicio local tiene un
límite limitado y cumple un subconjunto de la función general. Es una mesa de
servicio que es para una oficina/ubicación/región específica. Este tipo se muestra
en la Figura 14-2 .
BANGALORE USER SYDNEY USER
S S
Local Service Desk Local Service Desk
Suppliers (Ex: Internet Suppliers (Ex: Internet

Technical and Application Operations Teams (Ex: Technical and Application Operations Teams (Ex:
Service Provider, Third Service Provider, Third
Management (Ex: SAP Batch Job Monitoring Management (Ex: SAP Batch Job Monitoring
Party Application Party Application
Team, Network Team) Team, Facilities) Team, Network Team) Team, Facilities)
Support) Support)
Zúrich USERS
Local Service Desk
Técnica y Proveedores (Ej: Internet Equipos de

Aplicación Proveedor de Servicios, Tercero Operaciones (Ej:
Gestión (Ej: Soporte de aplicaciones de fiestas) Equipo de
Equipo SAP, supervisión de
Equipo de trabajos por
Red) lotes,
instalaciones)
405
Figura 14-2. mesa de servicio local
CAPÍTULO 14 EL MESA DE SERVICIO
He considerado tres ubicaciones distintas en las que se establece una

organización, lo cual es bastante común en estos días: Bangalore, Sydney y
Zurich. Cada uno de estos lugares alberga un mostrador de servicio. El
mostrador de servicio en Bangalore atiende solo a la ubicación de Bangalore, y
los mostradores de servicio de ubicación de Sydney y Zurich también atienden
a sus respectivas ubicaciones. Dentro de la ubicación, los usuarios finales, los
equipos técnicos, los proveedores y los equipos de operaciones se comunican
con sus respectivas mesas de servicio. Las ventajas de una mesa de servicio
local son:
• La mesa de servicio, los usuarios finales y los equipos
involucrados generalmente hablan el mismo idioma, lo que
conduce a una mejor comprensión del problema y la
retroalimentación proporcionada por ambas partes.
• Compartir una cultura similar ayuda a desarrollar una buena
relación y reducir las diferencias.
• Los usuarios VIP pueden recibir un mejor servicio a través de un
servicio personalizado.
• Aumento de la satisfacción del cliente
Las desventajas de una mesa de servicio local son:
• Es una opción costosa porque la infraestructura, las aplicaciones
y otros aspectos de una mesa de servicio deben duplicarse en
cada ubicación.
• Los volúmenes de llamadas en una mesa de servicio local
normalmente no justifican su existencia.
• Los procesos y herramientas dentro de la organización pueden no
estar estandarizados y podrían dar lugar a un trato diferenciado.
406
Mesa de servicio centralizada
Las organizaciones normalmente optan por una mesa de servicio centralizada. Hay
claras ventajas, lo que ha llevado a que esta sea la estructura más popular. Una
organización movilizará y colocará un solo escritorio de servicio en una ubicación
estratégica. Esto se muestra en la Figura 14-3 .
SERVICIO
BANGALORE USER SYDNEY USER
S S

Support) Support)
Centralized Service Desk
CENTRALIZED USER ZURICH USER

TEAMS S S

Support) Support)
Figura 14-3. mesa de servicio centralizada

Una mesa de servicio centralizada se forma con una sola mesa de servicio, en
lugar de tener una mesa de servicio en cada ubicación. En este ejemplo, las
ubicaciones de Bangalore, Sídney y Zúrich no tienen un servicio de atención
individual y se forma un servicio de atención centralizado que atiende a todas las
ubicaciones. El mostrador de servicio centralizado podría formarse en cualquiera
de las ubicaciones existentes o en una ubicación nueva por completo. No importa
dónde esté instalado el servicio de atención al cliente centralizado; lo que importa
es que la organización tenga solo una mesa de servicio como único punto de
contacto para todos los usuarios finales y otras partes interesadas.
Es posible que los equipos técnicos y los proveedores aún estén localizados.
Sin embargo, cuando deben comunicarse con la mesa de servicio, deben llamar a
la mesa de servicio centralizada. En la mayoría de las configuraciones de la
organización, existen equipos técnicos centralizados que también manejan las
407
tecnologías respectivas desde una ubicación central. Estos equipos centrales, si es
necesario, se comunican con una mesa de servicio centralizada.
408
Se puede instalar una presencia local si la organización ve la necesidad de
contar con apoyo práctico. Esto es totalmente opcional.
Las ventajas de una mesa de servicio centralizada son:
• Dado que hay una configuración única, el costo de las operaciones
será económico en comparación con la configuración de la mesa
de servicio local.
• Los ahorros de costos se extienden a las optimizaciones realizadas
con los recursos de la mesa de servicio, infraestructura,
administración y otros gastos indirectos.
• La mesa de servicio se puede operar con menos recursos.
• La estandarización se puede lograr fácilmente, ya que un solo
equipo que sigue el mismo conjunto de protocolos es más fácil de
lograr que varios equipos que siguen un solo conjunto de
procesos, procedimientos, estándares y guiones.
• La administración tiene una mejor visión general del rendimiento
y la eficacia de un servicio de atención al cliente en la
configuración centralizada.
Las desventajas de una mesa de servicio centralizada son:
• Los usuarios perderán el sabor, el idioma y la cultura locales.
• Algunos usuarios pueden preferir la proximidad y el toque
personal para sus necesidades de soporte, y es posible que una
mesa de servicio centralizada no brinde esta opción para todas las
ubicaciones de la organización.
Mesa de servicio virtual

Una mesa de servicio centralizada es una buena idea. Pero, ¿qué tan fácil o difícil
es encontrar a las personas, una ubicación, la voluntad de trabajar toda la noche,
controles regulatorios amigables para respaldar las operaciones las 24 horas del
día, los 7 días de la semana y otras campanas y silbatos que lo hacen realidad? A
través de la tecnología, podemos lograr
409
SERVICIO
una mesa de servicio centralizada sin el factor de colocación para los empleados
de la mesa de servicio. Podríamos tener una mesa de servicio centralizada incluso
cuando los agentes de la mesa de servicio se encuentran en diferentes partes del
mundo y operan como una sola unidad. Veamos cómo se logra esto.
La figura 14-4 representa una mesa de servicio virtual y es casi como la mesa
de servicio centralizada. Parece lo mismo, ya que el principio subyacente entre las
dos configuraciones es el mismo. Pero en una mesa de servicio virtual, logramos la
centralización a través de la tecnología. Y la mesa de servicio virtual impone el uso
de un sistema común de gestión del conocimiento del servicio (SKMS) para
garantizar la estandarización y el fácil intercambio de información.
410
Figura 14-4. mesa de servicio virtual
Hoy, tenemos la tecnología para llevar a los agentes de la mesa de servicio a la
plataforma de la mesa de servicio desde la comodidad de sus hogares. Varias amas
de casa están trabajando en call centers desde sus casas. Las llamadas telefónicas
se enrutan a sus líneas personales o ingresan a través del protocolo de voz sobre
Internet en la computadora personal del agente. El usuario final no notará ninguna
diferencia entre una mesa de servicio centralizada y una mesa de servicio virtual,
ya que la tecnología integra a la perfección partes inconexas en una sola unidad.
Del mismo modo, las organizaciones están deslocalizando, deslocalizando y
externalizando varias mesas de servicio a países donde el talento está disponible
en abundancia y donde los costos operativos son marginales en comparación con
la ubicación del mercado del cliente.
En este libro, discuto dos formas de crear una mesa de servicio virtual: el
modelo de seguimiento del sol y la mesa de servicio especializada.
El modelo follow-the-sun funciona mejor en una organización global que
alberga a usuarios de todo el mundo y tiene la necesidad de brindar soporte a los
usuarios las 24 horas del día, los 7 días de la semana y los 365 días del año. En
lugar de tener una mesa de servicio centralizada en una sola ubicación, se puede
distribuir en varias ubicaciones en todo el mundo. El concepto de este modelo es
que la mesa de servicio en una ubicación esté operativa durante el día. Durante la
noche, el siguiente mostrador de servicio, donde todavía es de día, toma el relevo
hasta el anochecer.
Consideremos el ejemplo de una organización con configuraciones de mesa de
servicio en Bangalore, Tokio y Detroit. Tokio ve la primera luz del día y el
mostrador de servicio comienza a funcionar, digamos, alrededor de las 9 am hora
local. Las llamadas de usuarios de todo el mundo se enrutan al servicio de atención
al cliente de Tokio. El servicio de atención al cliente en Bangalore estará operativo
a las 9 a. m., hora local. El mostrador de servicio de Tokio cierra cuando se pone el
sol (6:00 p. m.). Las llamadas de los usuarios comenzarán a aterrizar en el servicio
de atención al cliente de Bangalore. A medida que comienza el día en Detroit (6
am), la mesa de servicio en esa ciudad entra en vigencia y se vuelve operativa. El
servicio de atención al cliente en Bangalore cierra y el servicio de atención al
cliente de Detroit se hace cargo. A medida que termina el día en Detroit, la mesa
de servicio de Tokio se iniciaría al día siguiente y el ciclo continúa.
411
SERVICIO
Este modelo está de moda en algunas organizaciones importantes. Cuando
llame a la línea de atención al cliente, notará que la llamada a veces es
contestada por personas con acentos extranjeros (múltiples acentos) y, a veces,
por personas con acentos locales. Esto, como habrás observado, sucede
durante un período particular. Digamos, cuando llame por la noche, alguien en
la India será su agente de atención al cliente. Y cuando llame durante el día, es
posible que escuche a un agente de la mesa de servicio hablando inglés
americano. Esto es virtualización resoplando en segundo plano; usted, como
usuario, habrá llamado al mismo número cada vez, y todos los aspectos
técnicos del enrutamiento de llamadas se realizan en el back-end. ¿No es
genial?
El siguiente tipo de mesa de servicio virtual no se basa en la hora, las
zonas o la luz del día. Toma forma en base a la experiencia en un área. En esta
mesa de servicio, es posible albergar diferentes tipos de expertos en diferentes
ubicaciones. Y, a través del poder de IVR y el enrutamiento, es posible enrutar
la llamada al experto respectivo que se encuentra en todo el mundo.
Consideremos un ejemplo de una organización con la configuración de la
mesa de servicio especializada. Cuando un usuario llama, el IVR le solicita
que seleccione el tipo de problema que enfrenta: computadora portátil,
computadora de escritorio, red, almacenamiento o aplicación. Cuando el
usuario selecciona una computadora portátil, la llamada se enruta a un grupo
de soporte de computadoras portátiles ubicado en Londres. Hablarán con él y
se encargarán de la resolución. Si el usuario selecciona la aplicación, la
llamada se enruta a Manila, y los expertos en aplicaciones que se encuentran
en Manila son responsables de la resolución del problema de la aplicación del
usuario. Del mismo modo, es posible que los equipos de expertos estén
repartidos por todo el mundo y, según el problema en cuestión, la mesa de
servicio respectiva se haga cargo.
Este tipo de configuración es común en las organizaciones de
servicios de TI, ya que normalmente tienden a contratar conjuntos de
habilidades específicas para las ubicaciones. Las ventajas de una mesa de
servicio virtual son:
412
SERVICIO
• Las organizaciones pueden volverse resilientes con mesas de
servicio virtuales, por lo que pueden confiar en una u otra
mesa de servicio si una fallara y eliminar el único punto de
falla.
• Puede ser una opción menos costosa en comparación con la
mesa de servicio centralizada, ya que el despliegue de
profesionales que trabajan desde casa puede reducir los costos
de recursos.
• También puede ser menos costoso si la organización no tiene
que desembolsar costos de infraestructura, ya que los agentes
de la mesa de servicio trabajan desde sus hogares.
• Hay reglas en algunos países para pagar un salario adicional
si se obliga a los profesionales a trabajar más allá de un
tiempo determinado, lo que puede eliminarse con un servicio
de atención virtual.
Las desventajas de una mesa de servicio virtual son:
• Alinear todas las mesas de servicio en procesos,
procedimientos, terminologías e idiomas comunes es una
tarea onerosa y requiere mucha capacitación, correcciones de
rumbo y administración constante.
• La coordinación entre los equipos de la mesa de servicio
virtual y los equipos técnicos puede ser un desafío.
• Los usuarios finales pueden sentir una diferencia en la calidad
del servicio, como cuando llegan a diferentes mesas de
servicio.
• Se necesitan muchos esfuerzos de administración, y existe la
necesidad de automatización para transferir boletos de una
mesa de servicio a otra.
413
SERVICIO
Cualidades que se esperan del

personal de la mesa de servicio
La mesa de servicio es el primer punto de contacto para los usuarios. También
es un punto de contacto para varios equipos. Por lo tanto, es imperativo que la
comunicación y las habilidades blandas sean los talentos más deseados que se
esperan del personal de la mesa de servicio. El éxito de una organización
proveedora de servicios depende de qué tan bien se movilice y capacite la
mesa de servicio.
Comunicación para empezar

Considere un ejemplo donde el servidor de aplicaciones de correo electrónico
está roto. La mayoría de las organizaciones funcionan con correos
electrónicos, por lo que esta interrupción seguramente perturbará a los
usuarios y muchos llamarían a los números de la mesa de servicio. Si bien la
mesa de servicio recibe numerosas llamadas en busca de respuestas al sistema
de correo electrónico roto, deben mantener la calma y asegurarles a los
usuarios que se identificó el problema y que los ingenieros lo están
solucionando. Al recibir llamadas repetidas de varios usuarios, es natural que
cualquiera se sienta irritado. Pero cuando se enfrentan a los usuarios, deben
ponerse una máscara y hablarles como si fuera la primera llamada telefónica
del día. En el back-end, el personal de la mesa de servicio debe seguir
buscando actualizaciones de los ingenieros involucrados para proporcionar el
tiempo estimado de resolución. Entonces, en esencia, se espera mucha
comunicación de múltiples canales, y el personal contratado para este rol
debe ser capaz de lograrlo.
técnicamente orientado
Eso no es todo. La mesa de servicio se ve como la primera línea de soporte, lo
que necesariamente significa que el personal involucrado también debe estar
técnicamente orientado. Deben conocer los pasos de solución de problemas,
los elementos técnicos involucrados y ser lo suficientemente buenos para
414
SERVICIO
resolver al menos el 50 por ciento de los problemas generales que surgen. Por
supuesto, la mayoría de las organizaciones hoy en día han creado sistemas de
base de conocimiento que ayudan al personal de la mesa de servicio en hacer
las preguntas correctas al tratar con los problemas. Pero, al final del día,
encontrar la causa y solucionar problemas requiere inteligencia y habilidades
técnicas. Esto también es obligatorio. El personal de la mesa de servicio debe
poder comprender el problema y priorizarlo correctamente, porque desea que
un incidente de correo electrónico que afecta a mil personas se resuelva más
rápido que un individuo que no puede registrar su tiempo. A continuación, la
mesa de servicio debe comprender bastante bien el meollo del incidente para
escalarlo al grupo funcional correcto si no pueden resolverlo. Por ejemplo, si
la mesa de servicio no puede resolver un problema de Outlook, debe saber si
el incidente debe enviarse al equipo de intercambio (central) o al equipo de
campo que puede abordar el problema en persona.
Sondeando hacia el éxito

En mi opinión, sondear a los usuarios es uno de los conjuntos de
habilidades fundamentales necesarios para la mesa de servicio. La persona
que hace las preguntas correctas tiene más probabilidades de obtener la
respuesta rápida y correcta. Profundicé más en el arte de la comunicación
para la gente de TI en mi primer libro, Workshop in a Box: Communication
Skills for IT Professionals (Impackt Publishing, 2015), donde saqué a la luz
los diversos conjuntos de habilidades de comunicación que un profesional
de TI necesita alcanzar. por los cielos
Empatizar con los usuarios

Por último, pero no menos importante de los conjuntos de habilidades, es
mostrar empatía con los usuarios que sufren interrupciones de TI y que no
pueden cumplir con sus objetivos. No estoy exagerando el tema. Los usuarios
comerciales que no pueden completar sus trabajos debido a un problema
técnico están obligados a estar enojados, molestos e implacables. Para tratar
415
SERVICIO
con estos usuarios, el personal de la mesa de servicio puede realmente
ayudarlos al comprender sus problemas, y eso es solo el comienzo. Una vez
estuve enojado con Amazon porque un producto que devolví no había sido
reembolsado. Mientras chateaba con varios agentes, me dijeron el estado y me
dieron una autorización para demostrar que se había reembolsado, y algunos
agentes me pidieron que consultara con el banco. El banco confirmó que no
había recibido un reembolso a tal efecto. Llamé a Amazon y me atendió un
personal de la mesa de servicio que parecía mayor: no una de las voces más
jóvenes. Se disculpó profusamente por tener que contactar a Amazon tantas
veces y por la eventual demora. Ella no solo reembolsó el monto usando un
cupón de regalo, sino que también lo completó con £ 10 por los retrasos y la
experiencia por la que tuve que pasar. Si bien estaba feliz de recuperar el
monto en mi cuenta, la recarga me aseguró la alta calidad del servicio al
cliente que puedo esperar en Amazon. Todos los malos sentimientos
desaparecieron en un momento, no por el relleno, sino por el gesto y la
empatía que compartió. Otra habilidad que está fuertemente asociada con la
empatía es la inteligencia social, y estas habilidades realmente pueden
diferenciar al mejor personal de la mesa de servicio del resto.
¿Mesa de servicio bajo la nube de

automatización?
La automatización ha dejado su huella en cada parte de nuestras vidas; a veces
se siente que no podemos funcionar de manera efectiva sin la automatización.
No puedo acordarme de pagar las facturas de mi tarjeta de crédito a tiempo,
pero la automatización me ayudará a garantizar que no termine pagando
cargos por pagos atrasados. No quiero enterarme un buen día de que mis
cartuchos de tinta se han agotado, así que quiero que alguien los controle y me
envíe uno nuevo cuando esté a punto de agotarse (la suscripción de tinta
instantánea de HP es un ejemplo) .
Estamos en un mundo competitivo. Hay varias organizaciones que ofrecen
los mismos servicios y los consumidores obtienen el mismo nivel de servicio
416
SERVICIO
de varios proveedores de servicios. ¿Cómo eligen a cuál agarrarse? El truco es
el precio. El servicio que cuesta menos es el más preferido, manteniendo
niveles de servicio similares. La responsabilidad de reducir costos recae en el
proveedor de servicios. No pueden simplemente reducir por capricho, ya que
hay costos de prestación de servicios, gastos generales y dependencias que
deben tenerse en cuenta. salario no garantiza buenos niveles de servicio. La
mejor opción es emplear una automatización que pueda imitar a las personas y
realizar actividades repetitivas que las personas solían hacer. Si bien puede
haber una inversión de capital, a la larga esto seguramente brindará
importantes beneficios al proveedor del servicio. ¡Voila! La solución de
automatización podría derribar múltiples pájaros de un tiro. Esto ayudará a los
proveedores de servicios a reducir sus costos de servicio; luego también
pueden transmitir los beneficios a los consumidores, lo que atraerá a más
consumidores y hará que el negocio sea más rentable.
Sí, hay varios beneficios de la automatización además del ángulo del costo
del servicio. Una de las áreas donde se ha aplicado la automatización es en la
mesa de servicio. Cada vez es más difícil en estos días hablar con una persona
real. Cuando llama al número de la mesa de servicio, se le pide que pase por
un laberinto de bucles IVR y, al final, cada uno de ellos termina con el sistema
en lugar de un ser humano. El punto no es debatir sobre humanos versus
máquinas, sino mirarlo desde la perspectiva del resultado. Mientras habla con
las máquinas, ¿obtiene el usuario las respuestas que busca? Si la respuesta es
sí, entonces la automatización es un gran sustituto. Si la respuesta es no,
entonces la empresa que presenta las máquinas como su primer punto de
contacto seguramente se verá afectada en las calificaciones de satisfacción del
cliente.
En mi opinión profesional, la automatización es excelente para una mesa
de servicio; no del todo, pero sí en ciertos procesos. Cuando llama a un banco,
el proceso de verificación de su identidad cuando se realiza a través de la
automatización es excelente, pero necesita un humano al otro lado de la línea
si tiene una pregunta sobre una transacción en particular. Las máquinas nunca
podrán reemplazar a los humanos cuando se trata de comunicarse a nivel
personal y mostrar empatía donde importa, al menos no hasta ahora.
417
SERVICIO
Personalmente, nunca chatearía con bots de chat, porque la información que
brindan generalmente se puede obtener a través de otras áreas, como los
monitores de seguimiento y las áreas de cuenta. ¿Por qué pasar por la
experiencia humana cuando sabes que estás hablando con un programa de
computadora?
Dejando de lado mi opinión, la tecnología ha recorrido un largo camino.
Esta es la era de la inteligencia artificial, la automatización de procesos
robóticos (RPA) y el aprendizaje automático. Estamos llegando a un lugar al
que ya nos han llevado las películas de Terminator. Las máquinas están
aprendiendo rápido y tratando de parecerse a los humanos en todo lo que
hacemos. Hoy en día existen sistemas de inteligencia artificial que pueden
aprender y codificar de un ser humano. Entonces, la próxima vez, no
necesitamos un desarrollador para escribir programas. Un programa de
computadora puede ser entrenado para reproducir en el desarrollo de nuevas
aplicaciones.
El motor de inteligencia artificial de IBM, Watson, se asoció con el
gigante japonés de telecomunicaciones SoftBank en 2015 para enseñarle a
Watson a aprender y hablar japonés, un idioma considerado el más difícil de
aprender para las máquinas. El resultado de esto es reemplazar los canales de
atención al cliente de la empresa a través de robots que funcionan con esta IA.
Compromiso con la cadena de valor

del servicio
Tabla 14-1. Mesa de servicio en SVC
Actividad de
Detalles de participación
CVS
plan Ninguno La mesa de servicio no está
involucrada durante las actividades de
planificación.
Diseño y Medio La mesa de servicio a menudo se
418
SERVICIO
Transición aprovecha para comunicar a los
usuarios los cambios y los nuevos
servicios presentados a los usuarios.
También son parte del soporte vital
temprano y otras actividades
relacionadas con la liberación.
Obtener/Construir Bajo Durante la actividad Obtener/Construir,
la mesa de servicio podría
aprovecharse para registrar incidentes
y la mesa de servicio perteneciente a
entornos inferiores.
comprometer alto La mesa de servicio interactúa con los
usuarios y con otras partes interesadas,
y actúa como un único y primer punto
de contacto, desempeñando un papel
central en la mayoría de los procesos.
( continuación )
Tabla 14-1. ( continuación )
Actividad
Detalles de participación
de CVS
entregar y alto La mesa de servicio juega un papel central en
Apoyo la coordinación con los usuarios durante la
resolución de incidentes y la comunicación
con las diversas partes involucradas.
Mejorar Medio La mesa de servicio es un canal capaz de
recibir comentarios de los usuarios que
podrían traducirse en mejoras. La mesa de
servicio también entra en el ámbito de la
mejora continua, donde sus procesos y
actividades se mejoran a través de la
actividad Mejorar en el SvC.
14-1. ¿Cuál es el propósito de la mesa de servicio?
419
SERVICIO
A. Actuar como primer punto de contacto para los clientes.
B. Proporcionar la primera línea de soporte a los usuarios.
C. Capture la demanda de resolución de incidentes y solicitudes de servicio
D. Actuar como canal de comunicación entre terceros y el personal de TI

14-2. ¿Cuál de las siguientes no es una estructura típica de mesa de
servicio?
A. mesa de servicio virtual
B. mesa de servicio de TI
C. mesa de servicio centralizada
D. mesa de servicio local

14-3. ¿Cuáles de estos conjuntos de habilidades son más necesarios con el
personal de la mesa de servicio?
A. Empatía
B. Comunicación
C. Técnico
D. Todo lo anterior
14-4. ¿Cuál de los siguientes canales ayuda a los usuarios a obtener el

estado actual de los tickets? i. portalii. Redes sociales iii.Personal
de TI iv. robots de chat
A. i, ii y iv B. i, iii y iv
C. yo y iii
D. i, ii, iii y iv
14-5. ¿Bajo cuál de las actividades de SVC la mesa de servicio juega un

papel importante?
420
SERVICIO
A. Obtener/Construir
B. Diseño y Transición
C. Mejorar
D. Comprometer
421
CAPÍTULO 15
Consejos y trucos
para realizar el
examen ITIL
El examen de Fundamentos de ITIL es uno de los exámenes más buscados en la
industria de TI. Es una de las certificaciones que se consideran obligatorias durante
el tiempo de empleo.
Asistí a la capacitación de ITIL v2 cuando comencé con la gestión de
servicios de TI. Esto fue hace 15 años. No pasé el examen de práctica. Estaba
estupefacto. Luego me senté durante los siguientes 2 días tratando de descifrar el
patrón de preguntas, las pistas y los obsequios. En el siguiente examen de
práctica, obtuve un 80 por ciento; y en el examen de ITIL en papel, solo me
equivoqué en una pregunta. Aun así, no me había recuperado de mi fracaso en el
primer examen de práctica. Sentí que era responsabilidad del entrenador ayudar
en los preparativos para el examen de certificación. El entrenador debería haber
estado allí y haberlo hecho, ya que estaría en la mejor posición para proporcionar
una visión general de la disposición del terreno. Esto es exactamente lo que
planeo hacer en este capítulo.
Mi experiencia como capacitador me ha ayudado a profundizar mi
conocimiento del examen ITIL 4 Foundation. A veces siento que puedo leer la
mente del formulador de preguntas. ¡No precisamente! Los consejos que comparto
en este capítulo son los que generalmente compartiría en una sesión de
capacitación con mis alumnos, y más del 90 por ciento de mis alumnos aprobaron
el examen en su primer intento. Además, un buen número de mis alumnos también
han optado por mi formación en cursos avanzados de certificación ITIL.
Capítulo 15
6361-7_15
CONSEJOS Y TRUCOS PARA PRESENTAR EL EXAMEN IITL
Si bien el examen de certificación de ITIL es la mitad de la historia, lo que

sucede a continuación es una pregunta que la mayoría de la gente me hace en mi
red de LinkedIn y en mi blog. En este capítulo, responderé las preguntas más
frecuentes relacionadas con las carreras de ITIL.
Examen básico de ITIL 4: consejos y

trucos
Primero me certifiqué en ITIL Foundation en su segunda versión: ITIL v2. Al
momento de tomar el examen, estaba fresco en ITIL. El siguiente fue ITIL V3, que
tomé después de 4 años de experiencia laboral. El mundo era muy diferente en
esos 4 años: la forma en que percibía y leía el examen.
Tuve muchas más distracciones con ITIL V3 porque tenía la experiencia.
Empecé a relacionar los temas con mis actividades laborales y los procesos en el
trabajo no eran exactamente como se definen en ITIL. En resumen, con
experiencia a mis espaldas, fue mucho más difícil que sin experiencia.
ITIL 4 es un nuevo examen en el bloque. Se comporta de manera similar a
ITIL V3 en el patrón del examen, el estilo y la forma en que aparecen las
preguntas. Entonces, si tiene ITIL V3 a sus espaldas, ¡ha estado allí y lo ha
hecho! Si es nuevo, lea la siguiente sección para obtener algunos de los consejos
y trucos que creo que lo ayudarán. Esto, de ninguna manera, es completo y estos
consejos están formulados en base a mis experiencias y las de mis entrenadores.
Recuerda que con un examen para el que te preparas mucho, la alegría está en el
resultado. Es conmovedor cuando el resultado PASS se muestra en la pantalla,
es decir, si realiza una prueba por computadora en lugar de papel.
Preparación
Este libro es todo lo que necesitas en forma de material de lectura. Tenga la
seguridad de que no necesita referirse a nada fuera de él. Lea el libro en su
totalidad. La información proporcionada en esta guía de estudio se basa en el plan
de estudios del examen de Fundamentos de ITIL. Hay mucho más en ITIL de lo
420
Capítulo 15
que he mencionado. Las prácticas que están fuera del examen ITIL Foundation, las
puedes encontrar en mi blog: http://abhinavpmp.com .
Por el bien del examen, apégate al contenido del libro y estarás en buena
forma. Cuando esté certificado por ITIL, entonces comience a leer el material de
ITIL de otras fuentes; así no te distraerás entre necesidades y adornos.
Siendo ingeniero por la academia, he desarrollado varios malos hábitos (duh),
pero el que importa es cuando leo. Solía estudiar (ya veces abría el libro por
primera vez) la noche anterior para mis internos y exámenes. Hice algo similar
cuando escribí mi certificación ITIL V3 Foundation; de hecho, volví a casa un
poco antes de lo habitual y estudié durante unas 5 horas. Esta no es la mejor
manera de estudiar para un examen, así que catalogé partes de este libro para
leerlas durante siete días. Algunos días requieren más trabajo que otros. Pero la
intención es animarte a no estudiar como un estudiante de ingeniería.
Aquí hay algunos otros consejos y trucos que puede usar para prepararse para
el examen:
1. La única forma de cumplir con un cronograma es si hay un objetivo
por delante. Puede fijarse un objetivo en el futuro y seguir adelante y
reservar su examen antes de comenzar a leer el libro. Esto le ayuda a
mantenerse en el camino y concentrarse en su objetivo. Programe el
examen de Fundamentos de ITIL de uno de los institutos de examen
(EI). En el momento de escribir este artículo, PeopleCert era el EI
diseñado; tienen opciones en línea donde están disponibles los
exámenes supervisados.
2. Está previsto que el libro se lea después del trabajo, ya que la
mayoría de nosotros trabajamos desde la mañana hasta la noche.
Sentí que 7 días eran suficientes y, según los comentarios que recibí
de la primera versión, era ideal para profesionales que trabajan. Así
que me apegué al mismo plan en esta versión.
421
Capítulo 15
3. El ITIL que siguen las empresas puede no ser palabra por palabra
como en el marco; recuerde que ITIL no es prescriptivo. Entonces, el
mayor escollo es que los participantes respondan preguntas basadas
en su experiencia y no en el marco. Es absolutamente necesario que
desacople los procesos de trabajo de los del marco. Desaprende lo
que has aprendido de tu experiencia laboral. Desde la perspectiva del
examen, lo único que importa es el contenido de este libro y nada
más. Les digo a mis alumnos que tienen suficiente experiencia que a
los recién graduados de la universidad les resulta fácil aprobar el
examen porque comienzan desde cero, mientras que la gente con
experiencia comienza desde una posición negativa.
4. Toma muchas notas. Aunque toda la información que necesita está
impresa, no es equivalente a escribir sus propias notas, con su propia
mano y con sus propias palabras. Tome notas en cada momento,
incluidos los consejos y trucos que le ofrezco en este capítulo. La
investigación ha demostrado que tomar notas lo ayuda a comprender
mejor los conceptos y lo ayuda a hacer las preguntas correctas.
5. ITIL es de la vieja escuela cuando se trata de definiciones y palabras
clave. El éxito en el examen se deriva de identificar las palabras
clave correctas en las preguntas y las opciones de respuesta. Por lo
tanto, es imperativo que aprenda las definiciones de los conceptos de
ITIL, o al menos esté familiarizado con las palabras clave. Siga mis
consejos para el examen en los capítulos, donde he resaltado las
definiciones más frecuentes. Por ejemplo,
un incidente es una interrupción no planificada de un

servicio. Las palabras clave a recordar son interrupción no
planificada en este caso. Del mismo modo, encuentra las
palabras clave, enciérralas, resáltalas, subráyalas, haz lo
que sea que te ayude a memorizarlas.
422
Capítulo 15
6. ITIL se aprende mejor a través de ejemplos. He proporcionado
amplios ejemplos en este libro. Lo animo a que presente sus propios
ejemplos (y nada más) para ayudarlo a comprender mejor los temas.
Exámenes de prueba
Es común con cualquier certificación que intente algunos trabajos de prueba
después de haber estudiado todos los temas. Lo mismo ocurre con el examen de
Fundamentos de ITIL. Aquí hay algunos consejos en relación con la realización de
exámenes de prueba:
1. Axelos ha proporcionado un documento de muestra completo
que puede descargar desde su sitio web: www.axelos.
com/certifications/sample-papers . Debe registrarse antes de
poder descargarlo.
2. No intente realizar el cuestionario de muestra de ITIL antes de
haber terminado de leer todo este libro. Los documentos de
muestra deben usarse para evaluar su posición en términos de
comprensión, y se aprovecha mejor cuando se ha leído,
entendido, anotado y digerido todo el libro.
3. Responda la muestra de Axelos inmediatamente después de
haber completado todo este libro. Esto le dará una buena idea de
qué tan bien ha entendido el marco ITIL. El examen real tendrá
el mismo patrón que este, por lo que, con toda probabilidad,
también puede esperar encontrar algunas preguntas
directamente seleccionadas del documento de muestra.
4. Hay una serie de preguntas de ITIL disponibles en Internet.
Trate de responder tantas como sea posible. No puedo
garantizar que todas las preguntas sean de la misma calidad que
las preguntas del examen. Mientras busca preguntas de ITIL
Foundation en línea, es muy posible que también se encuentre
con preguntas de ITIL V3 , ya que la versión actual estuvo
423
Capítulo 15
activa durante más de 12 años. Mantente alejado de eso. Hay
muchas diferencias entre los dos marcos. También intente los
ejercicios presentados al final de cada capítulo.
el día del examen

El día D trae muchas permutaciones: la regla de qué pasaría si y los pensamientos
posteriores desdibujan las maquinaciones de ITIL que ha ingerido durante la
última semana más o menos. Por lo tanto, mi regla general es dormir lo suficiente
la noche anterior y luego, el día del examen, no reviso el material y probablemente
vea una película o un programa de televisión para distraerme del desorden.
Algunos de estos consejos son genéricos (puedes usarlos para cualquier examen) y
otros son específicos. Lo estoy poniendo todo aquí.
1. Trate de programar el examen en la primera mitad del día, cuando esté fresco
y enérgico.
424
Capítulo 15 CONSEJOS Y TRUCOS PARA
PRESENTAR EL EXAMEN IITL
2. Es importante que sepa que el examen de Fundamentos de ITIL no plantea
preguntas capciosas, en las que las preguntas están tergiversadas para
confundir a los candidatos. Las preguntas son sencillas, ya que intentan
evaluar su conocimiento de los conceptos de ITIL.
3. El examen ITIL Foundation es una prueba de su conocimiento de los
conceptos. Las preguntas más difíciles que encontrará son aquellas con
connotaciones negativas: ¿Cuál de estas NO es una . . . ?
4. Lea la pregunta de forma completa, completa y precisa. Entender lo que se
pregunta. Verifica una y otra vez si la pregunta tiene una connotación
negativa. Después de entender la pregunta, mire las opciones de respuesta.
5. Recuerde que ITIL es una guía y no un libro de reglas. Por lo tanto, las
opciones de respuesta con palabras clave como solo, siempre, nunca, debe y
otras probablemente sean incorrectas.
6. No tengas prisa por terminar el examen. Vencer al reloj no es un criterio para
aprobar el examen. Responda todo lo que pueda en la primera escaramuza y
luego repase las que no le parezcan seguras. Aprendí este consejo cuando
tomé mi examen PMP y me ayudó inmensamente. Pasé un tiempo mínimo en
las preguntas que podía responder y la cantidad máxima de tiempo en las
preguntas que necesitaban pensar. No salgas temprano de la sala de examen.
Revisa las respuestas hasta el último minuto posible.
7. También es posible que esté buscando una opción de respuesta después de
leer la pregunta y puede que no esté allí. No entrar en pánico. Comprenda la
pregunta y cada una de las opciones. Identifique la respuesta más cercana y
siga su instinto. Además, uno de mis alumnos que tiene la costumbre de
obtener certificaciones (la última vez que hablé con él, tenía 57
certificaciones) me dijo que las respuestas detalladas son generalmente la
respuesta correcta en tales situaciones. Tal vez, ¿esto es algo para tener en
mente?
8. Tienes 60 minutos para completar 40 preguntas. Eso es 1.5 minutos para cada
pregunta, lo cual es mucho tiempo en mi opinión. Alrededor de la mitad de
las preguntas del examen serían sencillas, lo que puede ayudarlo a avanzar en
425
medio minuto. Y hay algunos (en minoría) que te harán pensar. Tómate el
tiempo donde lo necesites.
9. Habrá algunas preguntas con las que quizás no esté seguro y necesite algo de
tiempo para pensar. En tal escenario, deje la pregunta sin respuesta y siga
adelante. Enfréntate primero a los más fáciles y simples, y luego vuelve a los
más difíciles.
10. No hay marcas negativas; una respuesta incorrecta no acaba descontando
puntos de la nota global. Así que al menos debería intentar responder a todas
las preguntas.
Preguntas frecuentes sobre carreras

basadas en ITIL
En mi blog y en mi canal de YouTube, muchos profesionales de TI, con
experiencia que va desde debutar hasta diez años, a menudo me hacen preguntas
relacionadas con carreras basadas en ITIL. Aunque me han llegado cientos de
consultas, la naturaleza y la dirección de las consultas son similares. En esta
sección, proporcionaré una lista de preguntas frecuentes (FAQ) sobre carreras en
ITIL y las responderé.
¿Qué tan diferente es ITIL de la gestión de

proyectos?
ITIL es un marco para la gestión de servicios. Las actividades que se realizan
como parte de la gestión del servicio son generalmente perpetuas, lo que
significa que no tendrá una fecha de finalización definitiva. La gestión de
proyectos, por otro lado, es finita. Tiene fechas definidas de inicio y
finalización. El proyecto deja de existir una vez finalizado y, por lo general,
pasa a otro proyecto. Para resumir, ITIL y la gestión de proyectos están en
diferentes hemisferios. Sin embargo, tanto la gestión de proyectos como la de
servicios se han incluido bajo el paraguas de DevOps.
426
¿Necesito experiencia en TI para obtener

la certificación ITIL?
La respuesta corta es no, no necesita experiencia en TI para obtener la certificación
ITIL Foundation.
Aquí está el largo. No te certificas en ITIL porque sí, ¿verdad? Intenta
encontrar un rol en línea con ITIL y ser empleable a través de la certificación. Si
no tiene experiencia en TI, puede obtener la certificación ITIL Foundation,
siempre que comprenda los conceptos. Sin embargo, para que usted comience a
trabajar en una organización de ITIL, sería una enorme montaña que escalar. Los
conceptos de ITIL se utilizan en el lugar de trabajo en estrecha colaboración con
las topologías y los marcos de TI, y la discapacidad sin el conocimiento de TI lo
dejará con ganas de cada obstáculo de actividad que encuentre. Mi consejo es que
también se inscriba en alguna capacitación de TI para conocer la infraestructura,
las redes y las aplicaciones de TI. En resumen, no hay ITIL sin TI.
Estoy en Desarrollo de Software. Quiero

cambiar mi carrera a ITIL-Based. ¿Qué
puedo recoger?
En la era de DevOps, todos los roles deben conocer los procesos ágiles, así como
las prácticas y los procesos de gestión de servicios. Sin la comprensión de todo el
marco de DevOps, no es posible que surja un equipo. Si está en el desarrollo de
software o en cualquier otro rol en un proyecto DevOps, independientemente de
tener que cambiar de carrera, aprenda ITIL. Cuando esté listo para cambiar, lo
hace aún más fácil, ya que sería un recurso pi con múltiples conjuntos de
habilidades, lo que lo hace más empleable.
Para roles de desarrollo de software en proyectos que no son DevOps, mi
respuesta es la misma. Aprenda DevOps para tener una carrera fructífera; la opción
de cambiar siempre estará disponible, y su experiencia con el desarrollo de
software lo ayudará a administrar los servicios (como en SaaS).
427
Divergiendo sobre este tema, encuentro que ITIL es un atajo para aquellos
interesados en pasar a la mesa de gestión en lugar de una técnica, ya que ITIL
está lleno de una serie de funciones de gestión que están en juego. Por ejemplo,
puede tratar de administrar incidentes trabajando como administrador de
incidentes o administrar cambios trabajando como administrador de cambios. En
resumen, en el lado de la gestión de las cosas, los roles son bastante
intercambiables si tiene la mentalidad adecuada para ello.
Por ejemplo, si eres una persona metódica y organizada, te recomiendo un
cambio al rol de gerente. Si usted es un comunicador que puede unir a las partes, y
si le gusta la acción, el administrador de incidentes es el rol que debe asumir. Y si
usted es del tipo de persona investigadora, el administrador de problemas debe ser
su elección.
¿Cuáles son los roles de nivel de entrada

en ITIL?
La mesa de servicio es el rol de nivel de entrada más popular en ITIL. Otros roles
que se ofrecen para comenzar son los roles de informes de servicios, control de
operaciones (supervisión de ejecuciones por lotes), cumplimiento de solicitudes y
administración de acceso.
Sin embargo, cada organización puede etiquetar ciertos roles como nivel de
entrada, según su madurez y las expectativas de sus clientes. He visto a ciertas
organizaciones contratar profesionales de TI con apenas un año de experiencia
como administradores de incidentes y problemas. Tengo mis reservas contra la
contratación de profesionales sin experiencia para tales funciones. Creo que estos
roles se desarrollan con la experiencia, y una persona con menos experiencia
puede no ver todos los aspectos que un activista experimentado podría abordar.
¿Cuál es la progresión normal del rol en

las operaciones de servicio?
Las operaciones de servicio ofrecen la mayor cantidad de puestos de trabajo en
cualquier organización proveedora de servicios. En lo que respecta a la progresión,
428
la mesa de servicio seguida de la solicitud de servicio y la gestión de acceso se
consideran roles de nivel junior. La siguiente jerarquía de roles en las operaciones
de servicio es un administrador de incidentes seguido por un administrador de
problemas. En algunas organizaciones, la gestión de incidentes se coloca por
encima de la gestión de problemas, porque los incidentes se consideran críticos
sobre los problemas. Los roles de gestión de incidentes se dividen en
administradores de incidentes y administradores de incidentes principales. Los
principales administradores de incidentes suelen ser profesionales experimentados
con más de diez años de experiencia en ITIL a sus espaldas.
Aunque la gestión de cambios es un proceso en transición de servicio, para la
mayoría de los propósitos prácticos, los roles se consideran operaciones de
servicio. Los roles de administrador de cambios se consideran en línea con los
roles de administrador de problemas.
¿Cuáles son los roles técnicos en ITIL?

Hay una serie de roles técnicos en ITIL. Las prácticas que se incluyen en la gestión
técnica (gestión de implementación, gestión de infraestructura y plataforma, y
desarrollo y gestión de software) ofrecen una gran cantidad de roles que son de
naturaleza técnica.
Los ejemplos incluyen ingenieros de nube y DevOps que son responsables de
la administración de la configuración y las integraciones de aplicaciones, y
desarrolladores de software que trabajan en el área de administración de
aplicaciones.
Soy excelente en el servicio al cliente. ¿A

qué rol debo aspirar?
Recomiendo roles orientados al cliente para aquellos que tienen una habilidad
natural para conectarse y establecer una buena relación con las personas. Estos
roles incluyen el administrador de nivel de servicio, el administrador de relaciones
comerciales y el administrador de prestación de servicios. Además, tendrá
funciones de ventas en todas las organizaciones, donde se espera que se reúna con
los clientes y demuestre las capacidades de gestión de servicios.
429
¿Cuál es el rol de ITIL que más ha

disfrutado?
Esta pregunta me la hicieron hace unos ocho años. Entonces mi respuesta fue
diferente; era diferente cuando escribí la primera versión de este libro; y ahora es
completamente diferente.
Mi respuesta en la primera versión fue: disfruto trabajar como consultor. Mi
trabajo consiste en encontrar una solución a un problema empresarial o de gestión,
y proporcionar todos los planes necesarios para implementarlo. El trabajo implica
muchas interacciones con los clientes, aprovecha al máximo mi experiencia en
ITIL y los breves plazos asociados con los proyectos de consultoría aseguran que
no me sature con el tiempo.
Mi respuesta actual es: ya no trabajo a tiempo completo en la línea de gestión
de servicios. Solo trabajo como arquitecto o consultor cuando se me presenta un
proyecto desafiante. Debido a mi conocimiento de ServiceNow y otras
herramientas y puentes, mi arquitectura implica especificaciones de integración de
procesos y todas las decisiones de diseño necesarias.
430
APÉNDICE
Respuestas a
Verificaciones de
conocimiento
Capítulo 3
3-1.
C. Esta es la definición de una organización. 3-2.
B. La utilidad es apta para su propósito y la garantía es apta para su uso.
3-3.
B. Un consumidor de servicios debe ser transparente acerca de sus
necesidades si tiene la intención de obtener un servicio para ellos.
3-4.
C. El resultado se refiere a los resultados logrados por la parte
interesada/cliente/consumidor.
3-5.
D. Esta es la definición de un costo. No es una oferta de servicio. Los tres
restantes están relacionados con la oferta de servicios.
APÉNDICE RESPUESTAS A LAS
PRUEBAS DE CONOCIMIENTO
A. K. Kaiser, obtenga la certificación ITIL® 4 Foundation en 7 días ,
https://doi.org/10.1007/978-1-4842-6361-7
Capítulo 4
4-1.
D. El objetivo principal es crear valor mediante el aumento de la
eficiencia, lo que se logra mediante la reducción de los desechos.
4-2.
A. Organización y personas se enfoca en la estructura de la organización
incluso en la organización proveedora. No es la dimensión de socios y
proveedores.
4-3.
A. La organización y las personas se centran en la cultura de la
organización. 4-4.
C. El modelo de entrega es una consideración para los flujos de valor y la
dimensión de los procesos
4-5.
A. Hay una clara separación de funciones para los proveedores, ya que la
relación se basa en transacciones. El foco no está en la relación.
Capítulo 5
5-1.
B. Cuatro dimensiones no es inherentemente una parte del sistema de
valor del servicio.5-2.
A. Representa opciones o posibilidades para agregar valor a las partes
interesadas o mejorar la organización.
5-3.
R. La actividad Engage trata con todas las partes interesadas, ya sean
usuarios, clientes o terceros.
5-4.
C. La actividad Obtener/Crear existe principalmente para asegurar todos
los recursos necesarios para construir servicios y desarrollarlos.
5-5.
C. Consulte la Figura 5-9 .
434
Capítulo 6
6-1.
B. Mientras intenta mejorar y remediar, la mejor opción es comenzar con
la posición actual.
6-2.
C. Los procesos complejos y las prácticas burocráticas son bastante
comunes en las organizaciones. Esto conduce a más caos y reducción de la
productividad. Manteniendo las cosas simples y según sea necesario, se puede
aumentar la productividad y se pueden reducir los costos de los recursos.
Optimizar y automatizar es la siguiente mejor opción.
6-3.
D. Cuando tiene múltiples flujos de trabajo en un solo producto, es
fundamental que todos los equipos apunten al verdadero norte. Deben
compartir una base de datos de gestión del conocimiento común y repositorios
de artefactos comunes. Lo más importante es que deben hablar entre ellos si
están atascados. Una herramienta de colaboración que crea visibilidad del
trabajo ayudará a identificar conflictos.
6-4.
R. Mientras el cliente decide la composición del producto final, el
equipo puede comenzar a construir el producto base. Esto se logra mejor a
través de formas ágiles de trabajo, y el principio rector que se relaciona
con esto es el progreso iterativo con retroalimentación . A medida que se
finalizan las características, se puede llevar a cabo en iteraciones.
6-5.
D. Una recomendación que guía a una organización en todas las circunstancias
Capítulo 7
7-1.
R. La gestión de versiones y despliegues era un proceso en ITIL V3 y no
figura en ITIL 4.
7-2.
A. Las prácticas de gestión de servicios comenzaron en las organizaciones
de gestión de servicios de TI y se organizaron en las mejores prácticas en
forma de ITIL.
435
7-3.
B. La gestión de programas no es una práctica de gestión general.
Capítulo 8
8-1.
D. La identificación, el análisis, el seguimiento y la mejora continua son
las cuatro etapas de la gestión de relaciones.
8-2.
B. Un proveedor brinda apoyo para la prestación de servicios a través de
un proveedor de servicios. Generalmente, los proveedores son proveedores de
servicios de un proveedor de servicios.
8-3.
B. La gestión de relaciones involucra a los clientes desde una perspectiva
estratégica y táctica.
8-4.
D. La gestión del nivel de servicio acuerda los distintos niveles de servicio
con el cliente y se realiza un seguimiento de forma regular.
8-5.
C. Si bien los comentarios pueden provenir de cualquier actividad, la
responsabilidad principal recae en Engage para servir de enlace con los
clientes y comprender el pulso.
8-6.
B. Los niveles de servicio, las métricas y los indicadores clave de
rendimiento son inherentes a un documento SLA. Sin embargo, los objetivos
del servicio generalmente se incluyen en un acuerdo formal (en la mayoría de
los casos, un contrato) entre un cliente y un proveedor de servicios.
Capítulo 9
9-1.
A. Para proteger la información que necesita la organización para llevar
a cabo su negocio 9-2.
D. Cualquier componente económicamente valioso que pueda
contribuir a la entrega de un producto o servicio de TI 9-3.
D. Una CMDB es una base de datos de elementos de configuración que
tienen relaciones construidas entre ellos. En un CMS, podría haber múltiples
436
CMDB. Entonces, en este sentido, CMS es un superconjunto y CMDB es un
subconjunto.
9-4.
D. Si bien todas las opciones son correctas hasta cierto punto, esta
opción es el objetivo principal de tener un mapa de servicio para comenzar.
Si bien es deseable tener una vista arquitectónica que ayude en la
planificación y la toma de decisiones, en el terreno, los técnicos se
beneficiarían más cuando se enfrenten a incidentes y cuando los
administradores de cambios tengan que tomar una decisión mientras
aprueban los cambios. Para identificar elementos de configuración
huérfanos, no necesariamente necesita un modelo de servicio; podrías
hacerlo con la CMDB directamente.
9-5.
B. Cualquier componente económicamente valioso que pueda contribuir a
la entrega de un producto o servicio de TI
Capítulo 10
10-1.
C. Lo que se debe hacer no es uno de los pasos definidos en el modelo de
siete pasos.
10-2.
A. Es el punto de partida o línea base que le da a la organización un
punto de referencia que sirve para dos propósitos: (1) como línea base de
medición, y (2) para diseñar las acciones de mejora que nos lleven de la
situación actual al estado deseado.
10-3.
B. Las mejoras no se pueden identificar en el vacío. No todo puede ser
hecho por un equipo específico. La organización debe unirse para identificar
mejoras. Para que esto suceda, se debe establecer una cultura que oriente a
las personas a pensar en mejoras; esto proviene esencialmente de la valentía
y la expresividad.
10-4.
D. No existe una metodología universal que sea ideal cuando se trata del
desarrollo de mejoras. Cada mejora es diferente, y el truco consiste en
mantener flexible la selección de la metodología para identificar una u otra
dependiendo de la naturaleza del trabajo.
437
10-5.
C. CIR es un repositorio para el registro de ideas. Las ideas permanecen
en el CIR durante todo su ciclo de vida.
Capítulo 11
11-1.
D. Cualquier cambio de estado que tenga trascendencia para la gestión
de un servicio u otro elemento de configuración 11-2.
B. Las interrupciones de un servicio se denominan incidentes.
11-3.
C. Lo que es más importante, la herramienta de registro de incidentes
debe proporcionar la capacidad de vincularse con tickets de problemas, tickets
de cambio, elementos de configuración y otros tipos de registros de gestión de
servicios. A través de estos vínculos, se pueden lograr la identificación de
mejoras, la definición de cambios y la realización de actividades de gestión de
problemas.
11-4.
A. Los problemas se crean para identificar la causa raíz de los incidentes
(que es el primer paso antes de implementar una solución permanente); cuando
se conoce la causa raíz pero aún no se ha implementado una solución
permanente, se crea un error conocido para realizar un seguimiento de los
errores conocidos en el servicio/producto 11-5.
C. Se realiza un análisis de cinco por qué para identificar la causa raíz de
un problema que ya se ha identificado.
11-6.
B. Identificar soluciones permanentes a errores conocidos en la KEDB
es una de las principales actividades que se llevan a cabo en esta fase. El
objetivo de esta fase es garantizar la reducción de errores conocidos ya sea
encontrando una solución permanente o haciendo permanente la solución
alternativa aplicada.
Capítulo 12
12-1.
438
B. La adición, modificación o eliminación de cualquier cosa que pueda
tener un efecto directo o indirecto en los servicios 12-2.
B. Los incidentes se refieren a la pérdida del servicio. Las solicitudes de
servicio no son pérdida de servicio, sino obtener algo adicional a lo que los
usuarios ya tienen.
12-3.
C. Para respaldar la calidad acordada de un servicio al manejar todas las
solicitudes de servicio predefinidas iniciadas por el usuario de una manera
efectiva y fácil de usar. Aunque la respuesta en las opciones no es la
definición completa, hasta ahora es la definición más cercana y apropiada
para la gestión de solicitudes de servicio.
12-4.
A. Los cambios urgentes no existen en ITIL. Indiqué esto como un
ejemplo de un tipo de cambio personalizado en una organización con la que
estaba asociado.
12-5.
A. El asesoramiento sobre cambios es un organismo que brinda
orientación para el control de cambios sobre los cambios, los riesgos que
plantean y para identificar posibles cambios que podrían ser maliciosos.
12-6.
B. Un cronograma de cambios consta de todos los cambios aprobados y
los cambios que están en proceso de aprobación; esto incluye cambios que
también se han implementado.
Capítulo 13
13-1.
A. Una versión de un servicio u otro elemento de configuración, o una
colección de elementos de configuración, que está disponible para su uso 13-
2.
B. La versión estándar no es un tipo de versión. Es, sin embargo, un tipo
de cambio.
13-3.
A. Un POC proporciona una prueba sustancial de que la solución que se
concibe va por el camino correcto. Un piloto lleva el POC más allá al
439
desarrollar una pequeña parte de la funcionalidad, proporcionando así una
prueba más.
13-4.
D. Tenemos liberaciones de emergencia pero no despliegues de
emergencia. El enfoque de implementación se trata de cómo llevamos a cabo
las implementaciones y no de la urgencia o el tiempo.
13-5.
D. Un depósito para almacenar todas las copias con licencia del software
adquirido y el software que ha sido desarrollado internamente
capitulo 14
14-1.
C. El propósito de la práctica de la mesa de servicio es capturar la
demanda de resolución de incidentes y solicitudes de servicio. También actúa
como un único punto de contacto para los usuarios. La respuesta A es
incorrecta porque se refiere a ser el primer punto de contacto con los clientes.
14-2.
B. Si bien todas las estructuras atienden a TI, una estructura llamada mesa
de servicio de TI no ha recibido ese nombre.
14-3.
D. Un buen personal de la mesa de servicio debe ser bueno en la
comunicación, empático con los usuarios y debe ser técnicamente sólido.
14-4.
R. En general, los usuarios pueden obtener actualizaciones de los boletos a
través de un portal de servicios, en los canales de redes sociales que los
proveedores de servicios han habilitado y a través de bots de chat.
Comunicarse con el personal de TI puede o no brindarle las actualizaciones
que está buscando, y no es preferible que los usuarios se comuniquen
directamente con el personal de TI.
14-5.
D. Engage: la mesa de servicio interactúa principalmente con los usuarios
y con otras partes interesadas identificadas, que es una función central dentro
de la actividad de Engage.
440
Índice
Defender los cambios estándar, 346,
347
Junta asesora de cambios (CAB), 349
Cambiar autoridad, 348
A Práctica de control de cambios
Entrega ágil, 167
autoridad de cambios, 348
metodología ágil, 26, 156 cronograma de cambios, 349
Parálisis por análisis, 172. cambios de emergencia, 343, 344
inteligencia artificial, 36, 414 ejemplos, 336
registro de bienes, 232 definición de ITIL, 336
autenticación, 226 cambios normales, 340, 341,
automatización, 14, 26, 31, 32, 343
184–186, 282 productos y servicios, 337
Disponibilidad, 226 alcance, 338, 339 cambios
estándar, 345–347
en CVS, 350
B actividades técnicas, 337
Línea de base, 255
Cambiar modelo, 343
despliegue de big bang, 375, 376
Cambiar horario, 349
Cultura sin culpa, 24
gestión de activos de clientes, 234
Enfoque de liberación azul-
Activos basados en la nube, 234
verde, 369, 370
Socios colaboradores,
173–175
Lluvia de ideas, 312, 313 Comunicación, 175, 177
Confidencialidad, 225.
Elemento de configuración, 237
C Base de datos de gestión de
ensayo canario, 337 configuración (CMDB), 179,
Categorización, incidente, 294 239
Mesa de servicio centralizada, Sistema de gestión de la
404–406 configuración
(CMS), 232, 239–241
4842-6361-7
ÍNDICE
Práctica de mejora continua CIR, CVS, 267

264, 265 enfoque de despliegue, SVS, 250
266 Registro de mejora continua (CIR),
metodología de desarrollo, 264, 265
266 revisiones de mejora, Servicio de Mejoramiento contínuo
265 definición de ITIL , (CSI), 186
261 actividades clave, 261– Entrega continua, 44–47,
263 377, 378
modelo de siete pasos Despliegue continuo, 46, 47,
recolectando mejoras, 260 377, 378
llegamos allí, 259 cómo Integración continua, 41–44
llegamos allí, 258 tomar Negociaciones de contratos, 207.
acción, 258, 259 Procedimientos de corrección, 223.
visión, 253, 254 Costos, 67–69, 230
dónde estamos ahora, 254, Factores críticos de éxito (CSF), 72,
255 256, 257
donde queremos Cultura, 96, 97
ser, 256, 257 Experiencia del cliente (CX), 160
D 147 150
Enfoques de gestión de implementación
despliegue del big bang, 375, 376
entrega continua/
despliegue, 377, 378
LMD, 383, 384
infraestructura, 373 ITIL
Biblioteca de medios definitiva
definición, 373 proceso
(DML),
implementaciones, 382
379, 383, 384
planificación ( ver
Entregar y apoyar la actividad, SVC, Implementación
despliegue por fases, 376, planificación)
despliegue de extracción 377 ,
revisar y cerrar, 383
378, 379
en CVS, 386
herramientas, 384, 385
444
ÍNDICE
Planificación de despliegues alcance, 27 turbulencia, 50

entornos complejos, 380 gestión de proyectos en
despliegues de cascada
infraestructura, 381 metodología, 25
mantener los procesos Denegación de servicio distribuida
consistentes, 381 ataques (DDoS), 224, 226
ordenar la propiedad, 380 Gestión de configuración dinámica,
Herramientas de despliegue, 384, 237
385
mi
Actividad de diseño y transición,
Factores económicos, 117.
SVC,
Práctica de control de cambios de
141–144
emergencia, 343, 344
Herramientas de detección, 223
Liberaciones de emergencia, 363
DevOps
Actividad de participación, SVC,
metodología ágil, 26
136–139
automatización, 26 beneficios
Factores ambientales, 119
de transformar, 28, 29
control de errores, 317
elementos, 35
Procesos de gestión de eventos, 282
personas, 37–39
Eventos, tipos, 277–279 Eventos
procesos, 39, 40
de excepción, 277
tecnología, 41
operaciones, 21
resumen, 23, 24
prácticas
F
Alternancias de funciones, 370–372
entrega continua, 44–47
implementación continua, Comentario
46, 47 iteración de alimentación,
continuo 169–171 proceso, 168 rol,
168
integración, 41–44
Técnica de los cinco por qué, 313,
principios de
314
automatización,
31, 32 cultura, 30 Centrarse en el principio rector del
Lean, 32, 33 valor aplicando
medir, 33 principios/aprendizajes,
compartir, 34 161 comentarios del
cliente, 160 definición de ITIL,
445
ÍNDICE
157 perspectivas del progresar iterativamente con

consumidor del servicio, 158, retroalimentación, 167–172
159 comience donde está, 162–
generación de valor, 158 167 piense y trabaje de
Adelante programa de cambios manera integral, 178, 179
(FSC), 350
Examen básico, tiempo de empleo
de ITIL, 419 consejos y trucos
examen de base,
H
gestión de activos de
ITIL ( cont. )
hardware, 233
exámenes de prueba,
423, 424 yo, j
el día del examen, Mejorar la actividad, SVC, 139–141
424–426 preparación, Interrupciones de la gestión
420–423 de incidentes, 285, 286
entrenador, 419 buenas prácticas, 287–
Preguntas frecuentes (FAQ), 289
Carreras basadas en ITIL, 427–431 definición de ITIL, 286
ciclo vital
categorización, 294
GRAMO confirmación y cierre, 300,
Prácticas generales de dirección, 301
192, 193 diagnóstico y
Gobernanza, SVS, 129, 130 investigación, 298, 299
Los principios rectores identificación, 291, 292
colaboran y promueven la registro, 292–294
visibilidad, 172–178 priorización de
centrarse en el valor, incidentes, 295–298
157, 158 Definición de resolución y recuperación, 300
ITIL, 155 manténgalo incidentes mayores, 301, 302
simple y práctico, 180– SLA, 297 calidad de servicio
183 inferior a la media, 285 en
optimizar y automatizar, SVC, 303
184–187 Matriz de prioridad de incidentes,
296 Eventos informativos, 279
446
ÍNDICE
Servicios reales de información y profesional directivo, 16

tecnología, 101 consideraciones, certificación de maestría, 17
105–107 definición del servicio, 13
gestión de servicios, 102 ciclo de vida del servicio, 12
Arquitecto de información, 103–105 líder estratégico, 16
Actividades de gestión de seguridad ITIL V3 era digital, 4
de la información, 223 surgimiento de DevOps, 5–7
autenticación, 226 disponibilidad, herramientas de gestión de
226 eventos, 14 gobernanza, 14
confidencialidad, 225 definición de servicio, 13 ciclo
definición, 223 de vida del servicio, 7, 9
integridad, 226 no prácticas, 12
repudio, 227 SVC, reinventado, 9, 10
228 Despliegues de infraestructura, 381
amenazas y riesgos, Integridad, 226
223; Mensaje de respuesta de voz
Biblioteca de infraestructura de interactiva (IVR), 302
tecnología de la información Diagrama de Ishikawa, 315
(ITIL) técnica de Ishikawa, 316
Preguntas frecuentes sobre práctica de gestión de activos de TI
carreras basadas en ITIL, activos de clientes, 234 activos
427–431 de nube, 234
certificación de la
fundación, 17
gestión de activos de hardware, 233
criterios de elegibilidad, 18 definición de ITIL, 229, 230 ciclo
examen, 19 de vida, 231 activos de software,
historia, 10, 11 233 SVC, 235
ITIL 4
automatización,
14 jerarquía de k
certificación, 15– Indicadores clave de rendimiento
17 (KPI),
gobernabilidad, 14 164, 256, 257
servicio incompatible error conocido, 309
ciclo de vida, 7
447
ÍNDICE
Base de datos de errores conocidos norte

(KEDB), 309
netflix, 66, 87
No repudio, 227.
L Cambios normales, 340, 341, 343
Liderazgo, 100 Progresión normal de funciones en
operaciones de servicio, 429;
Metodología esbelta, 32
Principio esbelto, 32
Marco de transformación Lean, 180
O
Factores legales, 118.
Obtener/Crear actividad, SVC,
Mostrador de servicio local, 403,
144–147
404
Oportunidad, 127, 128
Registro de incidentes, 292–294
Optimización, 185, 186
METRO Organización, 59–61
Grandes lanzamientos, 362 Estructuras organizativas, 95, 96
Gerente Profesional (MP), 16
Principio de medida, 33
Minimalismo, 180 pag q
Producto mínimo viable Diferenciación de socios y
(MVP), 171 proveedores, 108–110 estrategia
Lanzamientos menores, 363 de la organización para optar,
Exámenes simulados, 423, 424 110, 111
Habilitación de automatización de Responsabilidades de las personas,
gestión de eventos y supervisión, 97–99
282 diseño, 280 tipos de eventos, Roles de personas, 61–63, 97–99
277–279 definición de ITIL, 276 Percepción, 64, sesenta y cinco
gestión de políticas, 281 Despliegue por fases, 376, 377
procesos, 282 Actividad del plan, SVC, 134–136
Gestión de pólizas, 281
estrategia, 280 SVC, 283 Factores políticos, 116.
Prácticas categoría, 192 dirección
general, 192, 193 gestión de
herramientas, implementación, 281, servicios, 194, 195 gestión de
282 grupos de interés
manejo de relaciones,
448
ÍNDICE
200–204 R
nivel de servicio ( ver Gestión Actividades de la práctica de gestión
del nivel de servicio) de relaciones, 201–204
gestión de proveedores ( ver participación en SVC, 204, 205
práctica de gestión de Definición de ITIL, 201
proveedores)
Gestión de versiones
dirección técnica, 195 Agile/DevOps, 365–367
Priorización de incidentes, 295–298 frente a control de cambios,
Control de problemas, 312–317 358–360 componentes, 361
Identificación de problemas, 311, actividades de desarrollo y
312 operaciones, 357
Gestión de problemas liberaciones de
contra incidentes, 306, 307 emergencia, 363
actividades investigativas, 305 Definición de ITIL, 358
fases lanzamientos principales,
control de errores, 317 362 lanzamientos
control de problemas, 312– menores, 363 revisiones
317 de lanzamiento, 364
Problema de calendario de lanzamiento,
identificación, 363, 364 en CVS, 372
311, 312 producto y tecnicas
servicio, 304 en SVC, 318 liberación azul-verde, 369,
terminologías 370 opciones de función,
KEDB, 309 error 370–372
conocido, 309 solución prueba de concepto y piloto,
permanente, 310 368 cascada frente a
RCA, 308 enfoques Agile/DevOps,
causa raíz, 308 365
soluciones alternativas, 310 Proceso de gestión de versiones, 168
incidentes no resueltos, 305 Calendario de lanzamiento, 363, 364
Procesos, 39, 40, 114, 115 Opciones de mitigación de riesgos,
gestión de productos, 168 72, 73
productos, 56, 57 Conversaciones relacionadas con el
Prueba de concepto (POC), 368 riesgo, 70, 71
Despliegue de extracción, 378, 379 transferencia de riesgos, 72
449
ÍNDICE
Automatización robótica de procesos de ITIL, 392 proveedores de

(RPA), 414 servicios de TI, 394
Roles y responsabilidades, 99 organizaciones, 394
Análisis de causa raíz (RCA), 308 propósito, 393 cualidades
esperadas del personal
comunicación para comenzar
S con, 411
Gestión del catálogo de servicios, empatizando con
330 usuarios, 412, 413
Actividades de gestión de sondeando hacia el éxito, 412
configuración de servicios, 243. técnicamente orientado, 411,
CMDB, 239 412
CMS, 239–241 organización de proveedores de
Definición de ITIL, 236 servicios, 391
modelo de servicio, estructuras
241, 242 centralizado, 404–406
CVS, 244 locales, 403, 404
Consumidor de servicios, 60 virtuales, 406, 408–
consumo de servicios, 86 410 en CVS, 415, 416
Mesa de servicio, nube de Funcionalidad de servicio, 75
automatización 302 , 413– Integración y gestión de servicios
415 (SIAM), 111, 112
beneficios, 394 negocios y Acuerdo de nivel de servicio (SLA),
tecnología, 395, 396 213–215
canales para llegar, 396, 397 Compromiso de gestión de
charlando, 400 nivel de servicio en SVC,
Correos 216
electrónicos, 399 Definición de ITIL, 211, 213
mensajería, 401 actividades primarias, 212
portales, 400 redes documento SLA, 214, 215
sociales, 402 Requisitos de nivel de servicio
teléfonos, 398 (SLR), 213
walk-ins, 397 Gestión de servicios factores
solicitantes de empleo de económicos, 117 factores
nivel inicial, 395 definición ambientales, 119
450
ÍNDICE
cuatro dimensiones, 92–94 Prestación de servicios, 84–86

Servicios reales de TI, 101 Consumo relaciones de servicio,
consideraciones, 103–107 86
gestión de servicios, 102 definición de ITIL, modelo 83 ,
definición de ITIL, 54 liderazgo, 87, 88 servicios de
55 factores legales, 118 provisiones, 84–86
organizaciones y personas, 59–61 Práctica de gestión de solicitudes de
cultura, 96, 97 liderazgo, 100 servicio
estructuras organizativas, 95, niveles de servicio acordados,
96 327
funciones y definición, 326 cumplimiento,
responsabilidades, 330–332 pautas de
97–99 implementación,
valor, 100 332–334
socios y proveedores solicitud de cumplimiento
diferenciadora, 108–110 gestión, 328 catálogo
estrategia de organización de servicios, 329 en SVC,
para 334
optando, 110, 111 Solicitudes de servicio, 327
integración de servicios y Actividades de la cadena de valor del
administración, 111, 112 servicio (SVC), 131, 134 gestión de
roles de las personas, 61–63 activos, 235 práctica de control de
factores políticos, 116 cambios, 350
procesos, 114, 115 productos y mejora continua, 267 entrega y
servicios, 55–58 factores actividad de apoyo,
sociales, 118 factores 147–150
tecnológicos, 118 actividad de diseño y transición,
flujos de valor, 112–114 141–144 involucrar
prácticas de gestión de servicios, actividad, 136–139
194, 195 involucrar, 210
modelo de servicio, 241, 242 mejorar la actividad,
Ofertas de servicios, 80–82 139–141 práctica de
Operaciones de servicio, 274. gestión de incidentes, 303
Proveedor de servicios, 60, sesenta y gestión de la seguridad de la
cinco, 84, 273 información, 228
451
ÍNDICE
monitoreo y evento Ciclo de vida de entrega de

administración, 283 software (SDLC),
obtener/construir actividad, 22
144–147 planificar actividad, Cambios estándar, 345–347
134–136 práctica de gestión de Análisis de fortaleza, debilidad,
problemas, 318 oportunidad y amenaza
gestión de relaciones, 205 (FODA), 265
gestión de versiones, 372 Categorización de prácticas de
gestión de configuración de gestión de proveedores, 207
servicio, 244 mesa de servicio, negociaciones de contratos,
415, 416 207
gestión de niveles de servicio, Definición de ITIL, 206 gestión
217 gestión de solicitudes de del rendimiento, 208
servicio, 334 estrategias de
gestión de proveedores, 210 abastecimiento, 208–210
Flujo de valor del servicio, 112–114, evaluación y selección de
133 proveedores, 207
Componentes del sistema de valor estrategia de proveedores
del servicio (SVS), 125, 126 y planificación, 206
mejora continua, 250 Proveedores, 110
componentes discretos, 126 Sistema Estrategia y planificación de
de valor de servicio (SVS) ( cont. proveedores, 206
) componentes discretos en un Líneas de soporte en organización
solo DevOps, 393
entidad homogénea, 125 T
gobernabilidad, 129, 130
Prácticas de gestión técnica, 195.
Definición de ITIL, 125
Innovaciones tecnológicas, 274;
oportunidad y demanda,
Sistema de producción de Toyota
127, 128
(TPS), 32
estructura, 125 SVC ( ver
Cadena de valor del servicio
(CVS))
tu
creación de
Experiencia de usuario (UX), 160
valor, 124
Utilidad, diagrama lógico, 74
Gestión de activos de software, 233
452
ÍNDICE
Utilidad de las conversaciones relacionadas,

condiciones de 70, 71 consumidor de servicios,
servicio, 76 70 proveedor de servicios, 100
adecuación al utilidad del servicio, 75, 76
propósito, 76 garantía de servicio disponible
Suficiente, 78 capacidad
suficiente, 78 condiciones, 78
definición de ITIL, 75 continuo suficiente, 79
Definición de ITIL, 77
suficientemente seguro, 79
diagrama logico, 75
Fórmula de cocreación de valor, 203
Mesa de servicio virtual, 406, 408–
410
V Visión, 253, 254
Valor costos,
67–69 WXYZ
creación Eventos de advertencia, 278, 279
puerta lógica, 74 matriz, 75 Garantía de servicio Y
definición, 63 elementos, 64 diagrama, 77
ITIL definición, 64 resultados, condiciones, 78
66, 67 criterio, 78
salidas, 66 riesgos definición diagrama lógico, 74
de ITIL, 69 Metodología de gestión de proyectos
opciones de mitigación, 72, en cascada, 25, 40 Efecto SLA
73 sandía, 216
soluciones alternativas, 310
453
ÍNDICE
454

7 Dias Con ITIL Spa

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

7 Dias Con ITIL Spa

Cargado por

Copyright:

Formatos disponibles

Conviértase en

Abhinav Krishna Káiser

ISBN-13 (pbk): 978-1-4842-6360-0 ISBN-13 (electrónico): 978-1-4842-6361-7

Copyright © 2021 por Abhinav Krishna Kaiser

Dedicado a mi esposa Radhika y mis hijos Anagha

Capitulo 2: Breve descripción general de DevOps 21

Beneficios de transformarse en DevOps 28

Capítulo 4: Enfoque holístico de la gestión de servicios:

Capítulo 5: Creación de valor con el sistema de valor del

Cadena de valor del servicio 130 Planificar 134 Participar 136

Capítulo 6: Influir a través de principios rectores 153

Prácticas de optimización 185 Prácticas de automatización

Capítulo 7: Gestión de Prácticas de ITIL 191

Capítulo 8: Prácticas para Gestionar a los Stakeholders 199

Capítulo 9: Prácticas para habilitar el soporte de servicio 221

Gestión de la configuración del servicio 235 CMDB, CMS y

Capítulo 10: Mejora continua 249

Capítulo 11: Prácticas para gestionar operaciones 273

Compromiso con la cadena de valor del servicio 318

Capítulo 13: Prácticas para administrar versiones 355

Capítulo 14: La mesa de servicio 391

Capítulo 15: Consejos y trucos para realizar el examen ITIL

Apéndice: Respuestas a las pruebas de conocimiento 433

personalizaciones a las estructuras de la organización, y la mayoría de los procesos

En el primer día de su viaje de ITIL 4 Foundation, conocerá la descripción general,

© Abhinav Krishna Kaiser 2021 3

¿Por qué ITIL 4?

ITIL V3 no era para la era digital

proceso que se basa en un cierto nivel de burocracia. Y la burocracia tarda en

Ciclo de vida del servicio incompatible

5. Servicio de Mejoramiento contínuo

Las cinco fases están representadas en la Figura 1-1 .

Figura 1-1. Ciclo de vida del servicio ITIL V3

Muestra la estrategia de servicio en el núcleo para indicar la importancia y la

fase de transición del servicio. Después de la implementación, los servicios pasan

El marco se convirtió en un libro llamado Reinventar ITIL en la era de

Breve historia de ITIL

servicios y soporte de servicios. Las certificaciones ITIL también se basaron en

ITIL V3 e ITIL 4: Las diferencias

y explosivo como la brillantez de Tim Ferriss. En otras palabras, la semejanza se

El ciclo de vida del servicio está muerto

Introducción a las prácticas

El servicio tiene una nueva definición

Hoy en día, un proveedor de servicios no puede ocultar los servicios y

La gobernanza es un chico nuevo en el

La automatización está de moda

Jerarquía de Certificación ITIL 4

ITIL Managing ITIL Strategic

ITIL ITIL ITIL ITIL ITIL ITIL

Create, Drive High Direct, Direct, Digital

Figura 1-2. Ruta de certificación ITIL 4

INTRODUCCIÓN AL NUEVO ITIL

2. Líder Estratégico ITIL (SL)

Profesional de gestión de ITIL

2. Especialista en ITIL: impulsar el valor de las partes interesadas

3. Especialista en ITIL: TI de alta velocidad

4. Estratega de ITIL: dirigir, planificar y mejorar

ITIL MP es equivalente a ITIL Expert en el esquema de certificación V3.

Líder Estratégico ITIL

La certificación prueba el conocimiento de ITIL desde la perspectiva de la

1. Estratega de ITIL: dirigir, planificar y mejorar (común con MP)

Certificación de la Fundación ITIL

• Libro cerrado: no puede hacer referencia a ningún libro, notas u