ICC Shared Services Service Desk team members presented 10 April 2019 to the IT Service Management Forum at Semana Informatica (IT Week) at the Computer Engineering Congress of Valencia, the most relevant IT event held in this region of Spain.
Recientemente y medio por accidente alguien me pasó un enlace hacia un proceso estándar que se titulaba: Proceso Operativo Estándar sobre cómo gestionar las relaciones con terceros interesados. Mi primera reacción fue pensar «creo que esto es pasarse de la raya» y la segunda fue «alguien ha confundido un rol, con procesos».
¿Hasta que punto deben llegar los procesos, las guías y los manuales estándar en IT? No pongo en duda su existencia, pongo en duda su exceso, y pongo en duda hasta donde deben llegar.
¿Tiene sentido un procedimiento de incidentes de 80 páginas? ¿Tenemos clara la diferencia entre proceso y procedimiento?
Hace ya un tiempo hablé en UNICC de agilidad. En concreto del manifiesto ágil y una pequeña introducción a algunos conceptos.
Para ilustrar Scrum usé el famoso Ball Point Game, y debo confesar que es más difícil de lo que parece conseguir que la gente lo haga bien. Requiere de práctica conseguirlo, y quizás de algún coach más presente.
Aún así es divertido ver cómo la gente se auto organiza y ver cómo avanza el juego.
Vale, scrum no me vale para todo, pero la agilidad no se acaba en scrum, hay agilidad más allá de scrum…
Volvamos a los orígenes, a Toyota Manufacturing, a Lean… eso es producción, es operación, algo habría, algo que permitiera ser escalable, ¿no?
Lo hay, se llama Toyota Kata, y es 100% escalable, y tiene time boxes, y tiene objetivos y feedback y preguntas… y anda todo esto me suena y sí, cuenta con un liderazgo en el que la opinión de los de abajo cuenta, y no se penaliza por equivocarse y arriesgar…
Kata parte de objetivos que se definen desde la dirección y se bajan en cascada preguntando cómo se podría alcanzar hasta tener objetivos operativos alcanzables con un grado de descomposición asumible (suena a épica, historia, tarea…)
El agilismo mola, tiene el factor cool que hace años tenía ITIL. Y claro hay que ser ágiles en operaciones, pero nadie dice cómo.
La mayor parte de la gente tiene SCRUM como referente de la agilidad, pero la historia no acaba en SCRUM, pero de nuevo: tiene el factor cool y un factor añadido, los pilares de SCRUM son fácilmente asimilables.
Featured image by Richard Barrett-Small. Link to source
Llevo algo más de un año como coordinador de un Service Desk en una agencia de Naciones Unidas. Muchos cambios han ocurrido desde mi llegada, hemos convergido de dos equipos ha un solo equipo, ha habido rotación de personal…
Si bien seguimos usando métodos algo rudimentarios he ido poco a poco introduciendo conceptos que vienen de metodologías ágiles.
Quizás lo que más ha mejorado los indicadores del equipo ha sido la facilitación gráfica. Hemos pasado de elementos de texto listado a dos cuadros de mando que nos simplifican la tarea.
Featured image by klesta
Hace un par de años los señores de Gartner publicaron un estudio sobre el coste por ticket como métrica de Service Desk. Sin explicar los factores que componían el estudio aventuraban una cifra objetivo: 19 dólares. Esta métrica, y ese valor objetivo tienen un problema: ¿que incluyen esos 19 dólares? No venía muy desglosado, tampoco se presentaba un benchmark sobre qué tipo de organizaciones habían sido estudiadas, ni el alcance del servicio prestado.
Featured image by Sussan Nilsson
La transformación digital se supone que pone el foco en el cliente, las nuevas metodologías nos indican que hay que ser «customer centric» y sin embargo el Service Desk, Front Desk, Call Center, o como quieras llamarlo parece no estar en la vanguardia de esa transformación y acaba siendo el servicio que paga los platos rotos.
Verdes fuera y rojos por dentro, los SLA nos pueden llevar a engaño. Los SLA en principio nos deben indicar si un servicio está funcionando de acuerdo a las expectativas del cliente. De hecho es práctica común desarrollar dichos indicadores de forma conjunta con el cliente.
Pero ¿qué sucede cuando los indicadores están en verde, pero el cliente sigue descontento? Los indicadores pueden ser una trampa y llevar a la desconfianza. El problema surge cuando los SLA no reflejan la realidad de lo que el cliente espera.
Diseñar un proceso es algo más complejo de lo que parece. Siempre recordaré el primer intento de establecer el proceso de gestión de entregas en un gran cliente: fue un desastre. El fallo fue de sobre-ingeniería de proceso: intentar diseñar algo para cubrir todos los posibles escenarios, por remotos que pareciesen, desde el principio, sin probar lo que estábamos haciendo.
