1
00:00:00,001 --> 00:00:03,440
[MÚSICA]

2
00:00:03,440 --> 00:00:11,160
Bienvenidos, oyentes, a otro episodio deITIL 4 Sin

3
00:00:11,160 --> 00:00:13,440
Filtros, Elevando el ITSM.

4
00:00:13,440 --> 00:00:16,440
Hoy vamos a hablar de esos momentos en los que todo falla

5
00:00:16,440 --> 00:00:17,520
y hay que correr.

6
00:00:17,520 --> 00:00:18,360
Oh, sí.

7
00:00:18,360 --> 00:00:22,160
De esos días donde el sistema se cae, el teléfono no para.

8
00:00:22,160 --> 00:00:25,960
Y tú solo piensas, ¿quién me manda a trabajar en esto?

9
00:00:25,960 --> 00:00:26,840
Hola, Alex.

10
00:00:26,840 --> 00:00:27,840
Hola, Julián.

11
00:00:27,840 --> 00:00:30,000
El tema es gestión de incidentes,

12
00:00:30,000 --> 00:00:32,760
pero tranquilos que no lo vamos a complicar.

13
00:00:32,760 --> 00:00:35,920
Nos acompañan dos invitados de lujo que sí saben cómo manejar

14
00:00:35,920 --> 00:00:40,140
el caos sin perder la calma, Raquel y Marcos.

15
00:00:40,140 --> 00:00:42,520
Así que quédate con nosotros que esto promete.

16
00:00:42,520 --> 00:00:45,920
[MÚSICA]

17
00:00:45,920 --> 00:00:52,080
¿Nunca les ha pasado esa sensación de pánico cuando

18
00:00:52,080 --> 00:00:56,000
justo vas a pagar online o a enviar ese trabajo crucial y

19
00:00:56,000 --> 00:00:59,480
zas, la aplicación o la web se quedan colgadas?

20
00:00:59,480 --> 00:01:02,160
¿Ese momento de querer lanzar el ordenador por la ventana?

21
00:01:02,160 --> 00:01:03,360
Uf, total.

22
00:01:03,360 --> 00:01:05,800
O la plataforma de streaming que falla justo cuando empieza el

23
00:01:05,800 --> 00:01:07,880
partido o tu serie favorita.

24
00:01:07,880 --> 00:01:10,160
Un drama moderno, vamos.

25
00:01:10,160 --> 00:01:12,680
Pues precisamente de cómo evitar o, bueno,

26
00:01:12,680 --> 00:01:16,080
minimizar esos dramas, va nuestro análisis de hoy.

27
00:01:16,080 --> 00:01:18,760
Vamos a explorar cómo las organizaciones intentan

28
00:01:18,760 --> 00:01:21,760
restaurar la normalidad lo más rápido posible tras una

29
00:01:21,760 --> 00:01:23,160
interrupción inesperada.

30
00:01:23,160 --> 00:01:26,360
Sí, nos metemos de lleno en la gestión de incidentes, ¿eh?

31
00:01:26,360 --> 00:01:29,760
Usando como guía la práctica ITIL4 y también un documento

32
00:01:29,760 --> 00:01:32,640
bastante interesante sobre una técnica llamada swarming.

33
00:01:32,640 --> 00:01:38,760
Nuestra misión hoy, destilar lo esencial sobre cómo manejar

34
00:01:38,760 --> 00:01:42,560
estas interrupciones de forma eficaz, de forma ágil,

35
00:01:42,560 --> 00:01:46,400
para que todo vuelva a funcionar como debería.

36
00:01:46,400 --> 00:01:48,720
A ver, empecemos por lo básico.

37
00:01:48,720 --> 00:01:52,280
¿Qué es exactamente un incidente en este contexto?

38
00:01:52,280 --> 00:01:53,520
Buena pregunta.

39
00:01:53,520 --> 00:01:58,560
Según ITIL, un incidente es cualquier interrupción no

40
00:01:58,560 --> 00:02:02,520
planificada de un servicio o una reducción en su calidad.

41
00:02:02,520 --> 00:02:04,720
Ojo, no tiene que ser un apagón total,

42
00:02:04,720 --> 00:02:07,800
una lentitud exasperante o que falle una función concreta

43
00:02:07,800 --> 00:02:08,920
también cuenta, ¿eh?

44
00:02:08,920 --> 00:02:09,880
Entendido.

45
00:02:09,880 --> 00:02:13,400
O sea, no solo cuando algo se rompe del todo.

46
00:02:13,400 --> 00:02:16,760
Y el objetivo es, imagino, arreglarlo rápido para

47
00:02:16,760 --> 00:02:18,280
minimizar el daño, ¿no?

48
00:02:18,280 --> 00:02:21,080
Que los usuarios estén contentos y la empresa pues

49
00:02:21,080 --> 00:02:22,560
mantenga su reputación.

50
00:02:22,560 --> 00:02:23,760
Exactamente.

51
00:02:23,760 --> 00:02:26,440
Se trata de restaurar la operación normal del servicio

52
00:02:26,440 --> 00:02:27,920
cuanto antes.

53
00:02:27,920 --> 00:02:31,200
Y esa operación normal, pues, se define normalmente en los

54
00:02:31,200 --> 00:02:33,880
acuerdos de nivel de servicio, los SLA,

55
00:02:33,880 --> 00:02:36,360
o en documentos técnicos internos.

56
00:02:36,360 --> 00:02:39,840
Un detalle curioso es que a veces implica arreglar algo que

57
00:02:39,840 --> 00:02:41,880
el usuario ni nota, como, no sé,

58
00:02:41,880 --> 00:02:43,800
un servidor que empieza a sobrecalentarse,

59
00:02:43,800 --> 00:02:45,720
pero aún no afecta el rendimiento visible.

60
00:02:45,720 --> 00:02:49,280
Eso es interesante, actuar antes de que el problema escale.

61
00:02:49,280 --> 00:02:51,080
Para gestionar esto de forma eficiente,

62
00:02:51,080 --> 00:02:53,480
he oído hablar de los modelos de incidente.

63
00:02:53,480 --> 00:02:56,560
¿Suenan a plantillas o recetas?

64
00:02:56,560 --> 00:03:00,200
Son precisamente eso, enfoques predefinidos, ya probados,

65
00:03:00,200 --> 00:03:02,320
para tipos comunes de incidentes.

66
00:03:02,320 --> 00:03:05,800
Un bloqueo de cuenta, un fallo de impresora, cosas así.

67
00:03:05,800 --> 00:03:08,840
Aceleran la resolución usando pasos ya conocidos.

68
00:03:08,840 --> 00:03:09,360
Vale.

69
00:03:09,360 --> 00:03:12,320
Pero claro, no todos los incidentes son tan sencillos.

70
00:03:12,320 --> 00:03:14,760
Existen los llamados incidentes mayores.

71
00:03:14,760 --> 00:03:17,680
Que imagino que son los que provocan esas crisis de todo el

72
00:03:17,680 --> 00:03:18,640
mundo a cubierta.

73
00:03:18,640 --> 00:03:19,800
Tal cual.

74
00:03:19,800 --> 00:03:23,400
Tienen un impacto muy, muy significativo en el negocio.

75
00:03:23,400 --> 00:03:26,960
A veces lo paralizan y exigen una respuesta inmediata,

76
00:03:26,960 --> 00:03:28,160
coordinada.

77
00:03:28,160 --> 00:03:29,960
Pueden ser complejos, ¿sabes?

78
00:03:29,960 --> 00:03:31,800
Con efectos en cascada.

79
00:03:31,800 --> 00:03:34,160
Aquí entra en juego una figura clave,

80
00:03:34,160 --> 00:03:37,160
el major incident manager, el MIM.

81
00:03:37,160 --> 00:03:40,120
Y a menudo se usan enfoques como el swarming del que hablábamos

82
00:03:40,120 --> 00:03:40,760
antes.

83
00:03:40,760 --> 00:03:43,920
¿Y si no hay una solución definitiva a mano, qué se hace?

84
00:03:43,920 --> 00:03:45,400
¿Rezar un poco?

85
00:03:45,400 --> 00:03:46,500
Bueno.

86
00:03:46,500 --> 00:03:49,280
Antes de rezar, se busca un workaround,

87
00:03:49,280 --> 00:03:51,280
una solución temporal.

88
00:03:51,280 --> 00:03:54,360
El clásico ejemplo es reiniciar el router cuando internet va

89
00:03:54,360 --> 00:03:55,080
mal.

90
00:03:55,080 --> 00:03:57,640
No arregla la causa de raíz, pero oye,

91
00:03:57,640 --> 00:03:59,080
te permite seguir funcionando.

92
00:03:59,080 --> 00:04:01,520
Ah, el famoso apagar y volver a encender,

93
00:04:01,520 --> 00:04:02,680
el recurso universal.

94
00:04:02,680 --> 00:04:03,840
Ese mismo.

95
00:04:03,840 --> 00:04:05,120
Pero cuidado, ¿eh?

96
00:04:05,120 --> 00:04:08,160
Depender constantemente de workarounds sin resolver el

97
00:04:08,160 --> 00:04:12,120
problema de fondo genera lo que llamamos deuda técnica.

98
00:04:12,120 --> 00:04:13,440
Deuda técnica.

99
00:04:13,440 --> 00:04:14,960
Suena serio.

100
00:04:14,960 --> 00:04:16,080
Y lo es.

101
00:04:16,080 --> 00:04:17,520
Es como pedir un préstamo.

102
00:04:17,520 --> 00:04:20,360
Te saca de la pura hora, pero acumula intereses en forma de

103
00:04:20,360 --> 00:04:23,040
problemas futuros o mayor esfuerzo para arreglarlo

104
00:04:23,040 --> 00:04:23,840
después.

105
00:04:23,840 --> 00:04:26,440
Es un riesgo oculto si no se gestiona bien.

106
00:04:26,440 --> 00:04:27,280
Deuda técnica.

107
00:04:27,280 --> 00:04:28,480
Me quedo con el concepto.

108
00:04:28,480 --> 00:04:30,000
Potente.

109
00:04:30,000 --> 00:04:33,520
Vale. ¿Y cómo es el ciclo de vida típico de un incidente?

110
00:04:33,520 --> 00:04:36,760
¿Desde que pasa hasta que, bueno, se cierra?

111
00:04:36,760 --> 00:04:39,840
Simplificando mucho, las etapas son detección,

112
00:04:39,840 --> 00:04:42,880
que idealmente es automática, con monitorización,

113
00:04:42,880 --> 00:04:47,120
registro, documentar qué pasa, clasificación, priorizar,

114
00:04:47,120 --> 00:04:49,880
dirigirlo a quien toca, diagnóstico,

115
00:04:49,880 --> 00:04:53,800
investigar la causa, resolución, aplicar la solución,

116
00:04:53,800 --> 00:04:56,520
sea temporal o definitiva, y cierre,

117
00:04:56,520 --> 00:05:00,400
confirmar que todo va bien y documentar lo hecho.

118
00:05:00,400 --> 00:05:01,840
Parece lógico, sí.

119
00:05:01,840 --> 00:05:04,600
Y hay dos procesos principales funcionando aquí, ¿verdad?

120
00:05:04,600 --> 00:05:06,280
No solo apagar fuegos.

121
00:05:06,280 --> 00:05:07,160
Exactamente eso.

122
00:05:07,160 --> 00:05:08,160
Exacto.

123
00:05:08,160 --> 00:05:10,840
Por un lado, la gestión y resolución diaria de cada

124
00:05:10,840 --> 00:05:13,360
incidente que ocurre, el día a día.

125
00:05:13,360 --> 00:05:16,240
Y por otro, la revisión periódica de incidentes.

126
00:05:16,240 --> 00:05:20,440
Esto es mirar atrás, analizar tendencias y ver cómo mejorar

127
00:05:20,440 --> 00:05:22,640
todo el proceso continuamente.

128
00:05:22,640 --> 00:05:25,600
Ah, y es vital que alguien sea dueño del incidente de

129
00:05:25,600 --> 00:05:28,560
principio a fin, que haya una responsabilidad clara.

130
00:05:28,560 --> 00:05:30,560
Fundamental esa responsabilidad, sí.

131
00:05:30,560 --> 00:05:33,760
Ahora, ¿qué se necesita para que todo esto funcione bien?

132
00:05:33,760 --> 00:05:36,800
Hablemos de los habilitadores, empezando por las personas y la

133
00:05:36,800 --> 00:05:37,560
organización.

134
00:05:37,560 --> 00:05:39,960
Pues mira, se necesitan roles definidos,

135
00:05:39,960 --> 00:05:43,320
como el incident manager o el MIM que mencionamos.

136
00:05:43,320 --> 00:05:46,920
Y cada vez más se tiende a estructuras menos jerárquicas,

137
00:05:46,920 --> 00:05:49,040
más planas y colaborativas.

138
00:05:49,040 --> 00:05:51,120
Aquí es donde brilla el swarming.

139
00:05:51,120 --> 00:05:52,280
El swarming otra vez.

140
00:05:52,280 --> 00:05:53,680
Explícalo un poco más.

141
00:05:53,680 --> 00:05:55,320
¿Cómo funciona eso en la práctica?

142
00:05:55,320 --> 00:05:58,680
Pues en vez de escalar el problema nivel a nivel,

143
00:05:58,680 --> 00:05:59,180
¿sabes?

144
00:05:59,180 --> 00:06:03,400
El típico L1, L2, L3, se junta un equipo con distintas

145
00:06:03,400 --> 00:06:06,120
habilidades, un equipo multifuncional,

146
00:06:06,120 --> 00:06:08,720
desde el principio para atacar juntos los incidentes

147
00:06:08,720 --> 00:06:09,480
complejos.

148
00:06:09,480 --> 00:06:12,440
Suena más directo, menos burocrático,

149
00:06:12,440 --> 00:06:15,880
pero ¿no puede generar un poco de caos si todos opinan a la

150
00:06:15,880 --> 00:06:16,380
vez?

151
00:06:16,380 --> 00:06:18,960
Podría ser un riesgo si no se coordina bien, claro.

152
00:06:18,960 --> 00:06:21,760
Pero la idea es que la colaboración sea enfocada,

153
00:06:21,760 --> 00:06:23,040
dirigida.

154
00:06:23,040 --> 00:06:25,440
Los beneficios suelen superar los riesgos.

155
00:06:25,440 --> 00:06:28,840
Se resuelve más rápido, se evitan esos traspasos ineficientes

156
00:06:28,840 --> 00:06:31,440
entre equipos y, además, el equipo aprende

157
00:06:31,440 --> 00:06:32,960
colectivamente.

158
00:06:32,960 --> 00:06:36,040
Fomenta una cultura de responsabilidad compartida,

159
00:06:36,040 --> 00:06:38,880
sin buscar culpables, sino soluciones y aprendizaje

160
00:06:38,880 --> 00:06:39,560
continuo.

161
00:06:39,560 --> 00:06:42,800
Me gusta esa idea de cultura colaborativa y sin culpas.

162
00:06:42,800 --> 00:06:44,920
Suena más sano.

163
00:06:44,920 --> 00:06:47,240
¿Y qué hay de la información y la tecnología?

164
00:06:47,240 --> 00:06:49,960
Sin datos y herramientas, poco se puede hacer, imagino.

165
00:06:49,960 --> 00:06:50,640
Exacto.

166
00:06:50,640 --> 00:06:53,800
Necesitas información fiable, de la arquitectura,

167
00:06:53,800 --> 00:06:57,560
de los servicios afectados, de los SLA's, de todo.

168
00:06:57,560 --> 00:07:00,240
Y registros de incidentes muy detallados,

169
00:07:00,240 --> 00:07:02,960
qué pasó, quién intervino, cuándo, el impacto,

170
00:07:02,960 --> 00:07:04,640
las acciones tomadas.

171
00:07:04,640 --> 00:07:08,960
Y aquí, la automatización es absolutamente crucial.

172
00:07:08,960 --> 00:07:12,520
La palabra mágica, automatización.

173
00:07:12,520 --> 00:07:15,040
¿En qué partes se puede automatizar realmente?

174
00:07:15,040 --> 00:07:16,440
Dame ejemplos.

175
00:07:16,440 --> 00:07:17,720
En casi todas.

176
00:07:17,720 --> 00:07:20,640
Detección automática con herramientas de monitorización,

177
00:07:20,640 --> 00:07:23,520
registro a través de portales o incluso chatbots,

178
00:07:23,520 --> 00:07:25,840
clasificación usando inteligencia artificial o

179
00:07:25,840 --> 00:07:29,000
machine learning, diagnóstico con scripts automáticos que

180
00:07:29,000 --> 00:07:32,720
hacen pruebas, resolución remota o incluso autocorrección para

181
00:07:32,720 --> 00:07:35,680
ciertos fallos y el cierre mediante flujos de trabajo

182
00:07:35,680 --> 00:07:37,040
automatizados.

183
00:07:37,040 --> 00:07:39,440
Vaya, casi todo el ciclo.

184
00:07:39,440 --> 00:07:42,200
Sí, la idea es liberar a los expertos humanos para las

185
00:07:42,200 --> 00:07:46,000
tareas más complejas, las que requieren juicio y reducir los

186
00:07:46,000 --> 00:07:48,120
errores humanos en tareas repetitivas.

187
00:07:48,120 --> 00:07:49,840
Tiene todo el sentido.

188
00:07:49,840 --> 00:07:52,600
Y no podemos olvidarnos de los socios y proveedores,

189
00:07:52,600 --> 00:07:56,240
que hoy en día son parte de casi cualquier servicio tecnológico.

190
00:07:56,240 --> 00:07:57,480
Cierto, cierto.

191
00:07:57,480 --> 00:08:00,120
La mayoría de los servicios dependen de terceros.

192
00:08:00,120 --> 00:08:03,080
Es vital tener acuerdos claros sobre cómo van a colaborar

193
00:08:03,080 --> 00:08:05,240
ellos en la resolución de incidentes.

194
00:08:05,240 --> 00:08:07,600
Necesitas canales de comunicación fluidos,

195
00:08:07,600 --> 00:08:10,960
interfaces bien definidas, que todo funcione como una orquesta

196
00:08:10,960 --> 00:08:11,880
bien afinada.

197
00:08:11,880 --> 00:08:14,680
Claro, que no se pasen la pelota unos a otros.

198
00:08:14,680 --> 00:08:17,800
Finalmente, ¿cómo sabemos si lo estamos haciendo bien?

199
00:08:17,800 --> 00:08:20,480
¿Cuáles son los factores clave de éxito?

200
00:08:20,480 --> 00:08:23,120
Pues los podríamos resumir en tres principales.

201
00:08:23,120 --> 00:08:25,480
Detectar los incidentes lo antes posible,

202
00:08:25,480 --> 00:08:29,520
resolverlos de forma rápida y eficiente y, muy importante,

203
00:08:29,520 --> 00:08:32,040
mejorar continuamente cómo se gestionan.

204
00:08:32,040 --> 00:08:36,560
Detectar pronto, resolver bien, mejorar siempre, me gusta.

205
00:08:36,560 --> 00:08:39,080
Y esto se mide claro, no solo una sensación.

206
00:08:39,080 --> 00:08:40,440
Por supuesto.

207
00:08:40,440 --> 00:08:42,320
Se mide con métricas.

208
00:08:42,320 --> 00:08:46,000
Tiempo medio de detección, tiempo medio de resolución,

209
00:08:46,000 --> 00:08:49,440
el porcentaje de incidentes resueltos en el primer contacto,

210
00:08:49,440 --> 00:08:52,680
la satisfacción del usuario, el nivel de automatización que

211
00:08:52,680 --> 00:08:53,960
has alcanzado.

212
00:08:53,960 --> 00:08:57,080
Medir es la base para poder mejorar, sin duda.

213
00:08:57,080 --> 00:08:58,280
Perfecto.

214
00:08:58,280 --> 00:09:00,600
Entonces, recapitulando un poco.

215
00:09:00,600 --> 00:09:03,240
La gestión de incidentes busca restaurar el servicio

216
00:09:03,240 --> 00:09:04,360
rápidamente.

217
00:09:04,360 --> 00:09:06,920
Para ello, son esenciales procesos claros,

218
00:09:06,920 --> 00:09:09,680
modelos reutilizables, una fuerte apuesta por la

219
00:09:09,680 --> 00:09:12,840
automatización y enfoques colaborativos como el swarming.

220
00:09:12,840 --> 00:09:14,400
Todo ello con una visión integral,

221
00:09:14,400 --> 00:09:16,560
considerando las cuatro dimensiones de la gestión de

222
00:09:16,560 --> 00:09:19,760
servicios y un foco constante en la mejora continua.

223
00:09:19,760 --> 00:09:21,280
En esencia, sí.

224
00:09:21,280 --> 00:09:24,120
Es construir la base para que los servicios tecnológicos sean

225
00:09:24,120 --> 00:09:27,880
fiables y, bueno, inspiren confianza tanto dentro como

226
00:09:27,880 --> 00:09:29,240
fuera de la organización.

227
00:09:29,240 --> 00:09:32,840
Y aquí va una reflexión final para quien nos escucha.

228
00:09:32,840 --> 00:09:36,240
Teniendo en cuenta todo esto, la automatización creciente,

229
00:09:36,240 --> 00:09:39,040
el poder de la colaboración tipo swarming,

230
00:09:39,040 --> 00:09:42,600
hasta qué punto un enfoque aún más proactivo y colaborativo

231
00:09:42,600 --> 00:09:46,480
podría transformar radicalmente no sólo la fiabilidad de los

232
00:09:46,480 --> 00:09:49,480
servicios, sino la propia relación de confianza entre una

233
00:09:49,480 --> 00:09:51,720
organización y sus clientes.

234
00:09:51,720 --> 00:09:52,760
Ahí lo dejo.

235
00:09:52,760 --> 00:09:54,720
De qué pensar, desde luego.

236
00:09:54,720 --> 00:09:56,480
Una buena pregunta para cerrar.

237
00:09:56,480 --> 00:09:59,320
Gracias por acompañarnos en este análisis detallado.

238
00:09:59,320 --> 00:10:02,280
Este análisis detallado de "Con Punto y Koma" ha sido traído a

239
00:10:02,280 --> 00:10:03,760
ustedes por Lina IT Group.

240
00:10:03,760 --> 00:10:12,200
Excelente análisis.

241
00:10:12,200 --> 00:10:15,520
Gracias por acompañarnos y hasta el próximo episodio de ITIL

242
00:10:15,520 --> 00:10:18,640
4 sin filtros, elevando el ITSM.

243
00:10:18,640 --> 00:10:20,600
Hasta la próxima.

244
00:10:20,720 --> 00:10:23,960
[MÚSICA]

245
00:10:23,960 --> 00:10:27,320
[MÚSICA]

246
00:10:27,320 --> 00:10:30,660
[MÚSICA]