1
00:00:00,001 --> 00:00:06,000
[Música]

2
00:00:06,000 --> 00:00:09,000
Hola, hola. Bienvenidos de nuevo a ITIL4 Sin Filtros,

3
00:00:09,000 --> 00:00:14,000
el espacio donde hablamos de gestión de servicios sin vueltas ni jerga innecesaria.

4
00:00:14,000 --> 00:00:15,000
Yo soy Juan Carlos.

5
00:00:15,000 --> 00:00:16,000
Y yo soy Camila.

6
00:00:16,000 --> 00:00:21,000
Y hoy vamos a hablar de una de esas prácticas que…

7
00:00:21,000 --> 00:00:25,000
salvan el día en silencio.

8
00:00:25,000 --> 00:00:28,000
Nunca se lleva los aplausos, pero siempre está ahí.

9
00:00:28,000 --> 00:00:31,000
Mjmm, hablamos de la gestión de problemas.

10
00:00:31,000 --> 00:00:35,000
Piensa en ella como el técnico que está detrás del escenario en un concierto.

11
00:00:35,000 --> 00:00:37,000
Si todo funciona, nadie lo nota.

12
00:00:37,000 --> 00:00:40,000
Pero si algo falla, se cae todo el show.

13
00:00:40,000 --> 00:00:41,000
[Risa]

14
00:00:41,000 --> 00:00:43,000
Tal cual.

15
00:00:43,000 --> 00:00:48,000
Y ojo, la gestión de problemas no se trata de resolver incidentes cuando ocurren.

16
00:00:48,000 --> 00:00:52,000
Para eso está la gestión de incidentes.

17
00:00:52,000 --> 00:00:54,000
Esto va más allá.

18
00:00:54,000 --> 00:00:57,000
Se trata de evitar que vuelvan a pasar.

19
00:00:57,000 --> 00:00:58,000
Exactamente.

20
00:00:58,000 --> 00:01:02,000
Imagina que tu sistema se cae todos los lunes a las 9 de la mañana.

21
00:01:02,000 --> 00:01:04,000
Gestión de incidentes lo levanta.

22
00:01:04,000 --> 00:01:08,000
Gestión de problemas se pregunta, ¿por qué se cae cada lunes?

23
00:01:08,000 --> 00:01:09,000
Mhm.

24
00:01:09,000 --> 00:01:15,000
Y según ITL4, el objetivo de esta práctica es clarísimo.

25
00:01:15,000 --> 00:01:20,000
Reducir tanto la probabilidad como el impacto de los incidentes,

26
00:01:20,000 --> 00:01:23,000
identificando sus causas reales.

27
00:01:23,000 --> 00:01:27,000
Sí, es como ser un detective digital.

28
00:01:27,000 --> 00:01:29,000
Sin gabardina, pero con logs y dashboards.

29
00:01:29,000 --> 00:01:32,000
Hoy vamos a desmenuzar esta práctica paso a paso,

30
00:01:32,000 --> 00:01:35,000
con ejemplos reales y sin saltearnos nada.

31
00:01:35,000 --> 00:01:40,000
Bueno, Juan, la gestión de problemas se divide en tres fases.

32
00:01:40,000 --> 00:01:46,000
Identificación del problema, control del problema y control del error.

33
00:01:46,000 --> 00:01:50,000
Sí, es como decir qué está fallando, por qué está fallando

34
00:01:50,000 --> 00:01:53,000
y, por último, qué hacemos con eso.

35
00:01:53,000 --> 00:01:56,000
Tal cual.

36
00:01:56,000 --> 00:02:00,000
En la primera fase, notas que algo raro está pasando,

37
00:02:00,000 --> 00:02:03,000
incidentes que se repiten, patrones extraños

38
00:02:03,000 --> 00:02:06,000
o algún usuario reporta algo inusual.

39
00:02:06,000 --> 00:02:09,000
Después, en el control del problema se investiga a fondo.

40
00:02:09,000 --> 00:02:12,000
Logs, métricas, hipótesis, colaboración.

41
00:02:12,000 --> 00:02:15,000
Se activa el modelo de mejora continua.

42
00:02:15,000 --> 00:02:18,000
Y, por último, el control del error.

43
00:02:18,000 --> 00:02:22,000
Ahí se decide si conviene aplicar una solución definitiva,

44
00:02:22,000 --> 00:02:27,000
implementar un workaround o simplemente dejarlo bajo vigilancia.

45
00:02:27,000 --> 00:02:30,000
Claro. No todos los problemas se resuelven en el acto.

46
00:02:30,000 --> 00:02:34,000
Algunos se mantienen activos por un buen tiempo.

47
00:02:34,000 --> 00:02:37,000
Pero activos intencionalmente.

48
00:02:37,000 --> 00:02:44,000
Deben estar documentados, asignados y, sobre todo, revisados regularmente.

49
00:02:44,000 --> 00:02:46,000
Entonces, hablemos de enfoque.

50
00:02:46,000 --> 00:02:50,000
La gestión de problemas puede ser reactiva o proactiva.

51
00:02:50,000 --> 00:02:54,000
Sí, reactiva es cuando ya pasó un incidente

52
00:02:54,000 --> 00:02:58,000
y quieres entender qué lo causó para que no se repita.

53
00:02:58,000 --> 00:02:59,000
Así es.

54
00:02:59,000 --> 00:03:04,000
En proactiva, bueno, es detectar un problema antes de que se convierta en incidente.

55
00:03:04,000 --> 00:03:07,000
Puede venir de una alerta, un boletín de seguridad,

56
00:03:07,000 --> 00:03:11,000
una auditoría técnica, incluso de la comunidad de usuarios.

57
00:03:11,000 --> 00:03:12,000
Exacto.

58
00:03:12,000 --> 00:03:17,000
Por ejemplo, un proveedor publica una vulnerabilidad crítica.

59
00:03:17,000 --> 00:03:21,000
Actúas antes de que explote. Eso es gestión proactiva.

60
00:03:21,000 --> 00:03:26,000
Pero ojo, incluso lo proactivo sigue siendo una reacción al problema.

61
00:03:26,000 --> 00:03:30,000
No evitas que exista el error, pero sí que te afecte.

62
00:03:30,000 --> 00:03:34,000
Muy cierto. Se recomienda aplicar ambos enfoques.

63
00:03:34,000 --> 00:03:37,000
Lo importante es encontrar el equilibrio.

64
00:03:37,000 --> 00:03:42,000
Una vez que detectas un problema, lo primero es registrarlo.

65
00:03:42,000 --> 00:03:44,000
Eso marca el inicio del proceso.

66
00:03:44,000 --> 00:03:47,000
Después, viene la clasificación.

67
00:03:47,000 --> 00:03:51,000
Debes entender qué tipo de problema es

68
00:03:51,000 --> 00:03:55,000
y a qué equipo o rol le corresponde investigarlo.

69
00:03:55,000 --> 00:04:01,000
Claro, ¿es algo de red, base de datos, un error en el contrato con un proveedor?

70
00:04:01,000 --> 00:04:05,000
La clasificación debe ayudarte a dirigirlo al lugar correcto.

71
00:04:05,000 --> 00:04:09,000
Y eso depende mucho de cómo esté organizada tu empresa.

72
00:04:09,000 --> 00:04:13,000
Si trabajas por productos, clasificas por producto.

73
00:04:13,000 --> 00:04:17,000
Si es por dominios técnicos, sigues esa línea.

74
00:04:17,000 --> 00:04:20,000
También se considera el impacto y la urgencia.

75
00:04:20,000 --> 00:04:27,000
Si el problema afecta al sistema de pagos en plena temporada alta, bueno, no puedes esperar hasta mañana.

76
00:04:27,000 --> 00:04:33,000
Pero si ya tienes un workaround que lo mantiene bajo control, quizás no sea urgente.

77
00:04:33,000 --> 00:04:36,000
Todo depende del contexto del negocio.

78
00:04:36,000 --> 00:04:40,000
Entonces, ya registraste y clasificaste el problema.

79
00:04:40,000 --> 00:04:41,000
¿Qué sigue?

80
00:04:41,000 --> 00:04:44,000
No se trata solo de lanzar un ticket y cruzar los dedos.

81
00:04:44,000 --> 00:04:46,000
Para nada.

82
00:04:46,000 --> 00:04:51,000
Aquí entra en juego una técnica clave llamada "swarming".

83
00:04:51,000 --> 00:04:53,000
Y te digo, es de mis favoritas.

84
00:04:53,000 --> 00:04:55,000
La mía también.

85
00:04:55,000 --> 00:04:59,000
El swarming es básicamente juntar a las personas correctas.

86
00:04:59,000 --> 00:05:03,000
Puede ser gente de desarrollo, soporte, infraestructura.

87
00:05:03,000 --> 00:05:07,000
Y que todos colaboren en tiempo real hasta encontrar la causa.

88
00:05:07,000 --> 00:05:08,000
Sí.

89
00:05:08,000 --> 00:05:15,000
Y es súper útil cuando el problema, eh, no está claramente en un solo dominio.

90
00:05:15,000 --> 00:05:18,000
A veces involucra varias áreas al mismo tiempo.

91
00:05:18,000 --> 00:05:19,000
Ya sabes.

92
00:05:19,000 --> 00:05:20,000
¡Exacto!

93
00:05:20,000 --> 00:05:24,000
Es mucho mejor que estar rebotando tickets de un equipo a otro.

94
00:05:24,000 --> 00:05:27,000
Y, siendo sinceros, es más eficiente.

95
00:05:27,000 --> 00:05:30,000
Y hasta divertido, si te gusta resolver rompecabezas.

96
00:05:30,000 --> 00:05:33,000
La idea del swarming es lograr claridad.

97
00:05:33,000 --> 00:05:39,000
Cuando todos aportan desde su especialidad, el análisis avanza más rápido.

98
00:05:39,000 --> 00:05:43,000
Y se puede asignar el problema con más precisión.

99
00:05:43,000 --> 00:05:44,000
Sí.

100
00:05:44,000 --> 00:05:48,000
O en algunos casos, eh, se detecta un workaround que se puede aplicar de inmediato.

101
00:05:48,000 --> 00:05:50,000
Y eso también es valioso.

102
00:05:50,000 --> 00:05:56,000
Ahora, hay situaciones donde no se puede resolver el problema en el momento.

103
00:05:56,000 --> 00:05:59,000
Tal vez porque la solución es muy costosa.

104
00:05:59,000 --> 00:06:02,000
O depende de un proveedor externo.

105
00:06:02,000 --> 00:06:08,000
En esos casos, lo que se hace es registrar un error conocido y aplicar un workaround.

106
00:06:08,000 --> 00:06:14,000
Es decir, una solución temporal que reduce el impacto mientras se resuelve el fondo del asunto.

107
00:06:14,000 --> 00:06:16,000
Exactamente.

108
00:06:16,000 --> 00:06:21,000
Es como ponerle una curita a una fuga mientras se consigue la pieza de repuesto.

109
00:06:21,000 --> 00:06:25,000
No es lo ideal, pero mantiene el servicio funcionando.

110
00:06:25,000 --> 00:06:30,000
Pero ojo, esos errores conocidos generan lo que llamamos deuda técnica.

111
00:06:30,000 --> 00:06:36,000
Cada vez que evitamos resolver un problema de raíz, incrementamos el trabajo pendiente.

112
00:06:36,000 --> 00:06:40,000
Y esa deuda se vuelve costosa con el tiempo.

113
00:06:40,000 --> 00:06:49,000
Porque ralentiza futuros desarrollos, aumenta riesgos y puede ocasionar incidentes repetitivos.

114
00:06:49,000 --> 00:06:55,000
Por eso, ITIL recomienda revisar periódicamente todos los errores conocidos.

115
00:06:55,000 --> 00:07:00,000
Ver si ya existe una solución viable o si es momento de mejorar el workaround.

116
00:07:00,000 --> 00:07:07,000
Y también asegurarse de que esa solución temporal no se vuelva permanente por costumbre.

117
00:07:07,000 --> 00:07:10,000
Porque pasa más de lo que uno cree.

118
00:07:10,000 --> 00:07:13,000
Lo sé, porque he estado ahí.

119
00:07:13,000 --> 00:07:18,000
Ahora, hablemos de algo que realmente ayuda a gestionar los problemas de forma eficiente.

120
00:07:18,000 --> 00:07:20,000
Los modelos de problemas.

121
00:07:20,000 --> 00:07:28,000
Sí, los modelos son como plantillas o guías paso a paso para problemas que ya se han visto antes.

122
00:07:28,000 --> 00:07:32,000
Por ejemplo, si cada cierto tiempo se cae un servicio por un tema de caché,

123
00:07:32,000 --> 00:07:36,000
y ya sabes cómo solucionarlo, ¿para qué reinventar la rueda?

124
00:07:36,000 --> 00:07:45,000
¡Exacto! Documentas el patrón, las acciones recomendadas, los equipos involucrados y hasta posibles medidas preventivas.

125
00:07:45,000 --> 00:07:48,000
Todo eso queda en el modelo.

126
00:07:48,000 --> 00:07:51,000
Y eso reduce mucho el tiempo de análisis cuando vuelve a ocurrir.

127
00:07:51,000 --> 00:07:57,000
Además, ayuda a los equipos nuevos o menos experimentados a actuar con confianza.

128
00:07:57,000 --> 00:08:01,000
Y ni hablar del valor que tiene para la mesa de servicio.

129
00:08:01,000 --> 00:08:06,000
Cuando pueden acceder a un modelo claro, todo fluye mejor.

130
00:08:06,000 --> 00:08:09,000
La verdad, usar modelos es una señal de madurez operativa.

131
00:08:09,000 --> 00:08:14,000
Te permite escalar el conocimiento sin depender de una sola persona.

132
00:08:14,000 --> 00:08:22,000
Bueno, Juan, llega un punto en el que te preguntas, ¿cómo sabemos si todo esto está funcionando bien?

133
00:08:22,000 --> 00:08:28,000
Buena pregunta. O sea, puedes tener el proceso súper definido, pero si no lo mides…

134
00:08:28,000 --> 00:08:31,000
es como manejar con los ojos cerrados.

135
00:08:31,000 --> 00:08:37,000
Y aquí es donde entran las métricas. No estamos hablando de contar tickets a lo loco, ¿eh?

136
00:08:37,000 --> 00:08:39,000
Se trata de medir impacto, no actividad.

137
00:08:39,000 --> 00:08:46,000
Por ejemplo, una métrica clave es la cantidad de incidentes que se resolvieron gracias a un análisis de problema,

138
00:08:46,000 --> 00:08:48,000
no solo por reiniciar un servidor.

139
00:08:48,000 --> 00:08:55,000
O también el número de errores conocidos que siguen abiertos y cuánto están afectando al negocio.

140
00:08:55,000 --> 00:09:00,000
Hay una métrica que a mí me gusta mucho, el Índice de Desempeño en Gestión de Problemas.

141
00:09:00,000 --> 00:09:03,000
Lo llaman PPI, Problem Performance Index.

142
00:09:03,000 --> 00:09:05,000
¿Y cómo funciona?

143
00:09:05,000 --> 00:09:11,000
Se calcula considerando los problemas nuevos, los que se resolvieron y los que se cerraron.

144
00:09:11,000 --> 00:09:17,000
Básicamente, mide si estás identificando y resolviendo, no solo acumulando tareas.

145
00:09:17,000 --> 00:09:23,000
Eso está buenísimo, porque te obliga a encontrar un equilibrio entre detectar y actuar.

146
00:09:23,000 --> 00:09:27,000
No sirve de nada llenar el backlog si nadie hace nada con eso.

147
00:09:27,000 --> 00:09:32,000
Y ojo, estas métricas deben adaptarse al contexto de tu organización.

148
00:09:32,000 --> 00:09:36,000
No hay una fórmula mágica, lo importante es que reflejen valor real.

149
00:09:36,000 --> 00:09:43,000
Exacto. O sea, si el área de ventas pierde $100,000 dólares al mes por un error no resuelto,

150
00:09:43,000 --> 00:09:45,000
esa es la métrica que importa. Punto.

151
00:09:45,000 --> 00:09:48,000
Ahora que ya entendemos el qué y el cómo,

152
00:09:48,000 --> 00:09:51,000
em, hablemos del con qué.

153
00:09:51,000 --> 00:09:53,000
Las herramientas marcan una diferencia enorme.

154
00:09:53,000 --> 00:09:55,000
Totalmente.

155
00:09:55,000 --> 00:09:59,000
Y no estamos hablando solo de automatizar por automatizar.

156
00:09:59,000 --> 00:10:03,000
La clave es que las herramientas se adapten al proceso, no al revés.

157
00:10:03,000 --> 00:10:09,000
Exacto. Por ejemplo, las plataformas de monitoreo pueden detectar comportamientos anómalos

158
00:10:09,000 --> 00:10:12,000
antes de que un usuario llame a la mesa de servicio.

159
00:10:12,000 --> 00:10:15,000
Eso permite una identificación proactiva.

160
00:10:15,000 --> 00:10:20,000
Y si además integras inteligencia artificial o análisis predictivo,

161
00:10:20,000 --> 00:10:26,000
puedes identificar patrones entre incidentes que, a simple vista, parecerían aislados.

162
00:10:26,000 --> 00:10:31,000
Eso es poder real. Y ni hablar de los sistemas de gestión del conocimiento.

163
00:10:31,000 --> 00:10:36,000
Cuando están bien organizados, te dan acceso inmediato a errores conocidos,

164
00:10:36,000 --> 00:10:39,000
soluciones previas y workarounds documentados.

165
00:10:39,000 --> 00:10:45,000
Sí, pero ojo, de nada sirve tener mil artículos si nadie los encuentra.

166
00:10:45,000 --> 00:10:51,000
Ahí entra en juego el diseño del sistema, la estructura, los filtros, todo eso importa.

167
00:10:51,000 --> 00:10:56,000
¡Cuántas veces he visto bases de conocimiento que son más laberintos que ayuda!

168
00:10:56,000 --> 00:11:02,000
Uf, muchas veces. Y bueno, también está el tema de los flujos de trabajo.

169
00:11:02,000 --> 00:11:11,000
Herramientas como plataformas ITSM que te permiten relacionar problemas con incidentes, cambios, activos…

170
00:11:11,000 --> 00:11:14,000
Y eso permite trazabilidad completa.

171
00:11:14,000 --> 00:11:21,000
Sabes qué cambio resolvió qué problema, qué error lo causó y a qué componente estaba vinculado.

172
00:11:21,000 --> 00:11:24,000
Eso es oro puro para mejorar continuamente.

173
00:11:24,000 --> 00:11:28,000
Y no olvidemos el monitoreo de errores conocidos.

174
00:11:28,000 --> 00:11:35,000
Si un workaround lleva seis meses activo, la herramienta debería decirte "revísalo,

175
00:11:35,000 --> 00:11:39,000
ya es hora de aplicar una solución definitiva".

176
00:11:39,000 --> 00:11:47,000
Las herramientas no son mágicas, pero cuando están bien configuradas, se convierten en un aliado estratégico.

177
00:11:47,000 --> 00:11:52,000
Te ayudan a escalar, priorizar y a enfocarte en lo que realmente importa.

178
00:11:52,000 --> 00:11:58,000
Juan, algo que no podemos dejar fuera es el papel de los proveedores y terceros.

179
00:11:58,000 --> 00:12:04,000
Porque, muchas veces, el problema ni siquiera está dentro de tu infraestructura.

180
00:12:04,000 --> 00:12:11,000
Exactamente. Puede que el error esté en una API de terceros, en un componente de red de alquilado,

181
00:12:11,000 --> 00:12:15,000
o incluso en un servicio en la nube que no controlas directamente.

182
00:12:15,000 --> 00:12:21,000
Y cuando eso pasa, si no lo tienes previsto en tus procesos, te quedas cruzado de brazos.

183
00:12:21,000 --> 00:12:28,000
Por eso, ITIL recomienda que tus modelos de problema incluyan instrucciones claras sobre cómo escalar a terceros,

184
00:12:28,000 --> 00:12:32,000
qué información compartir y cómo hacer seguimiento.

185
00:12:32,000 --> 00:12:35,000
Y eso también se tiene que reflejar en los contratos.

186
00:12:35,000 --> 00:12:43,000
Si dependes de un proveedor para resolver algo crítico, tiene que haber un acuerdo formal que defina tiempos,

187
00:12:43,000 --> 00:12:48,000
responsabilidades y canales de comunicación y escalamiento.

188
00:12:48,000 --> 00:12:59,000
Ahora, vayamos más lejos. Hablemos sobre lo que ITIL propone para medir la madurez de esta práctica, usando niveles de capacidad.

189
00:12:59,000 --> 00:13:05,000
Son cinco niveles, desde el más básico, donde la práctica es improvisada y poco estructurada,

190
00:13:05,000 --> 00:13:12,000
hasta el más alto, donde se mejora continuamente con base en métricas y resultados reales.

191
00:13:12,000 --> 00:13:22,000
Y ojo, no se trata de llegar al nivel 5 en todo. Eso sería… costoso y probablemente innecesario.

192
00:13:22,000 --> 00:13:28,000
Sí, no todas las organizaciones necesitan ese nivel de sofisticación.

193
00:13:28,000 --> 00:13:34,000
Lo importante es definir en qué procesos vale la pena invertir más capacidad.

194
00:13:34,000 --> 00:13:39,000
Claro, si tienes un servicio crítico, como pagos o atención al cliente,

195
00:13:39,000 --> 00:13:44,000
ahí sí conviene llegar a un nivel alto de madurez en la gestión de problemas.

196
00:13:44,000 --> 00:13:51,000
Y en otros servicios menos críticos, tal vez te basta con tener un nivel intermedio bien implementado.

197
00:13:51,000 --> 00:13:54,000
En resumen, no se trata de hacerlo perfecto en todas partes,

198
00:13:54,000 --> 00:13:59,000
sino de alinear tu nivel de capacidad con lo que realmente necesita el negocio.

199
00:13:59,000 --> 00:14:09,000
Bueno, Juan, antes de cerrar, ¿te parece que compartamos algunos consejos prácticos que nuestros oyentes pueden aplicar en su día a día?

200
00:14:09,000 --> 00:14:15,000
Claro que sí, porque una cosa es la teoría y otra es cuando te cae el problema un viernes a las 6 de la tarde.

201
00:14:15,000 --> 00:14:20,000
¡Literal! Así que, vamos con algunos puntos clave.

202
00:14:20,000 --> 00:14:24,000
Primero, empieza a registrar problemas hoy mismo.

203
00:14:24,000 --> 00:14:29,000
Aunque el proceso no esté del todo afinado, si no hay visibilidad, no hay mejora.

204
00:14:29,000 --> 00:14:30,000
Totalmente.

205
00:14:30,000 --> 00:14:37,000
Segundo, la gestión de problemas no es una función administrativa, es una práctica estratégica.

206
00:14:37,000 --> 00:14:42,000
Se trata de reducir riesgos, proteger ingresos y dar continuidad al negocio.

207
00:14:42,000 --> 00:14:46,000
Tercero, publica tu lista de problemas más importantes.

208
00:14:46,000 --> 00:14:53,000
Que sea visible para todos. Ya sabes, cuando los problemas están sobre la mesa, aparecen soluciones inesperadas.

209
00:14:53,000 --> 00:14:57,000
Cuarto, organiza un grupo multidisciplinario.

210
00:14:57,000 --> 00:15:04,000
El enfoque de Swarming funciona porque une talentos diversos para atacar un problema desde todos los ángulos.

211
00:15:04,000 --> 00:15:08,000
Y eso muchas veces acorta días de análisis.

212
00:15:08,000 --> 00:15:13,000
Quinto consejo, y este es clave, prioriza con el foco en el valor.

213
00:15:13,000 --> 00:15:20,000
No todo lo técnico es urgente. A veces un problema pequeño en un proceso clave puede tener un impacto gigante.

214
00:15:20,000 --> 00:15:24,000
Y no olvides los principios guía de ITIL.

215
00:15:24,000 --> 00:15:30,000
Especialmente, comienza donde te encuentres, colabora y promueve la visibilidad.

216
00:15:30,000 --> 00:15:33,000
Y manténlo simple y práctico.

217
00:15:33,000 --> 00:15:38,000
Y simple no significa superficial, significa enfocado.

218
00:15:38,000 --> 00:15:41,000
Bien pensado, bien ejecutado.

219
00:15:41,000 --> 00:15:45,000
Bueno, si llegaste hasta aquí, felicidades.

220
00:15:45,000 --> 00:15:52,000
Hoy te llevas no solo la teoría, sino también una forma más clara de ver los problemas y actuar sobre ellos.

221
00:15:52,000 --> 00:15:56,000
Y si has aprendido algo, compártelo con tus colegas.

222
00:15:56,000 --> 00:16:00,000
O con esa persona que siempre dice, "Esto se arregla reiniciando".

223
00:16:00,000 --> 00:16:03,000
Que escuche este episodio, por favor.

224
00:16:03,000 --> 00:16:08,000
Te esperamos en el próximo episodio de ITIL 4 Sin Filtros,

225
00:16:08,000 --> 00:16:13,000
donde convertimos las buenas prácticas en conversaciones reales.

226
00:16:13,000 --> 00:16:19,000
Hasta la próxima. Y recuerda, no solo apagues el incendio, encuentra lo que lo está provocando.

227
00:16:19,000 --> 00:16:25,000
[Música]