Necesito una Unidad de Intervención Inmediata

Frecuentemente cuando se ponen en marcha nuevos servicios, incidimos sobre cientos de usuarios que deben adquirir rápidamente nuevos conocimientos y adaptarse a nuevas maneras de trabajar. Es en este momento cuando necesitamos poner foco en una Gestión del Cambio precisa y especializada que nos ayude a conseguir poner a todas estas personas en marcha rápidamente.

El problema

Cuando hacemos este tipo de despliegues, se produce un rápido aumento de las necesidades de soporte: gran cantidad de usuarios necesitan apoyo en un corto espacio de tiempo. Los equipos de soporte se ven fuertemente afectados por esta situación, que además deben combinar con dar apoyo a las necesidades cotidianas del negocio.

La gestión del cambio debe proporcionar una base de conocimientos, materiales de formación y procedimientos que sean comprensibles, que se mantengan actualizados y que sobre todo puedan ser consultados de manera fácil por los usuarios afectados.

La solución

El empleo de soluciones especializadas y temporales, que puedan montarse, usarse y desmontarse fácilmente y en modalidad de pago por uso. Soluciones que no interfieran con los entornos corporativos y que proporcionen la flexibilidad y el acceso global que requieren los usuarios.

La Propuesta de G2

El próximo Jueves 7 de Mayo de 2020 haremos un webinar explicando cómo montamos una de estas plataformas express para habilitar una Unidad de Intervención Inmediata. 

Inscríbete aquí:  https://atlassian.gedos.es/inscripcion-webinar/ 

El Service Desk como Unidad de Intervención Inmediata

Llevo en el sector de las TIC unos 33 años y desarrollando proyectos unos 28. Aún así, mis participaciones en proyectos de software más intensas se han dado durante los últimos 10 años, temporada en la que desde G2 hemos hecho una suave deriva dentro de la gestión de servicios a la gestión completa del ciclo de vida del servicio, cosa que me ha permitido participar en los equipos de desarrollo aportando visiones de Lean, de Agile y de DevOps.

Durante estos años, una de las lecciones más importantes que he aprendido es que no hay DONE sin Materialización del Valor. Es decir, que por mucho que los equipos de desarrollo piensen que han finalizado un paquete de funcionalidades, hasta que no están en manos de usuario y siendo utilizadas, no son más que promesas incumplidas de un valor futuro.

Ya escribía sobre esto aquí

http://www.gobiernotic.es/2009/12/el-ultimo-del-ano-y-va-sobre-valor.html

y aquí

http://www.gobiernotic.es/2010/05/la-evolucion-cuantica.html

Ya más maduro, sobre el año 2013 reflexionaba sobre la problemática que nos presentaba el hecho de acelerar el flujo utilizando técnicas de automatización y el cuello de botella se trasladaba a otro sitio: el usuario, la última frontera.

http://www.gobiernotic.es/2013/06/el-punto-debil-de-devops.html

Así que llegamos a la conclusión de que una de las fases que más pueden influir en la materialización del valor generado por un proyecto es la de la Gestión del Cambio: poner en manos de los usuarios la nueva aplicación y conseguir desplegar lo antes posible y sobre el número de usuarios adecuados, el conocimiento, la práctica y los nuevos circuitos que harán que la promesa de valor se convierta en realidad.

¿De qué serviría un nuevo sistema para canalizar las oportunidades de venta que llegan por los diferentes canales si los comerciales no lo saben usar o lo usan mal?

¿De qué serviría el precioso sistema de seguimiento de indicadores si los que deben tomar decisiones en base a esos indicadores no lo saben usar o aquellos que alimentan los datos lo hacen mal o a deshora?

¿Cómo diablos vamos a conseguir poner a todas esas personas en teletrabajo si cuando les damos las herramientas técnicas no saben usarlas?

Así, pues, se nos hace fundamental ayudar a los equipos en esta etapa de Gestión del Cambio, y tradicionalmente las empresas ponen foco en una serie de acciones: 

• generación de materiales de formación
• formación a usuarios clave
• formación a formadores
• formación al equipo de soporte
• documentación de las preguntas más frecuentes

Pero...  ¿A qué se parece la realidad cuando te enfrentas a desplegar una solución para cientos o miles de usuarios? 

Pues lo primero que te pasa es que la aproximación de formar a usuarios claves o formación de formadores es quizás un poco lejana al usuario final. 

Tardas demasiado en llegar a ellos y con personas que en realidad son “proxies” del conocimiento: muy buena tiene que ser la formación a formadores (teórica y práctica) para que ellos puedan transmitir de manera fluida todo lo que se supone que debe saber el usuario final. Y muy buenos tienen que ser los materiales de formación, no podemos aspirar a que ellos generen sus propios materiales.

Lo segundo es que habrá situaciones que hayan quedado fuera de la formación y que durante las sesiones de formación a usuario final aparezcan en forma de preguntas que el recién estrenado profesor no sea capaz de resolver. ¿Tenemos un canal para poner en contacto al profesor con el equipo de desarrollo para que le resuelvan la duda de un día para otro? ¿Tenemos una manera de documentar este conocimiento modificando rápidamente el material de formación o de consulta?

En tercer lugar, los recién formados alumnos comienzan a trabajar con el nuevo sistema y lógicamente tienen dudas, encuentran cosas que no saben hacer o peor aún, encuentran errores. Esto, que en condiciones normales significaría una pequeña porción del trabajo habitual del Centro de Soporte, se puede convertir rápidamente en una avalancha de llamadas para las que, por si fuera poco, el técnico de soporte debe invertir mucho más tiempo en resolver porque a) no tiene la práctica y la formación habitual (es un producto nuevo) y b) necesita dar formación al usuario, dando una respuesta que al tiempo de resolver su problema, sea pedagógica para facilitar la incorporación del usuario en la nueva solución.

Para terminar de rizar el rizo, nos vamos a encontrar con que si el Centro de Soporte está colapsado atendiendo este tipo de interacciones, ¿cómo vamos a atender los contactos habituales, los que se refieren a otro tipo de servicios que incluso podrían ser más prioritarios? ¿Cómo atenderemos el Business as Usual?

En definitiva, vemos que para una situación más o menos excepcional como es el roll-out de un proyecto que tiene afectación a un elevado número de usuarios en un breve espacio de tiempo, debemos buscar soluciones adecuadas y excepcionales, huyendo de la solución tradicional de “lo pasaremos a través de soporte ” y construyendo una solución adecuada a esta situación de trato especial al usuario. (de hecho, a esta fase de los proyectos se le llama precisamente la fase de HyperCare)

Posiblemente pensarás que este tipo de roll-outs son poco habituales, que las cosas las hacemos de manera iterativa e incremental y que eso de un gran proyecto en modo cascada está pasado de moda. Te doy toda la razón del mundo, pero también es cierto que la gran mayoría de proyectos que significan sustituir una plataforma por otra, aquellos que tienen una puesta en marcha en formato big-bang, aquellos que ponen un producto mínimo viable en manos de un gran número de usuarios y todos aquellos que se ponen en marcha por motivos de extremada urgencia (por ejemplo, motivados por la activación de planes de continuidad) son candidatos a recibir este tipo de tratamiento. 

¿Y cuál es la respuesta?

Bueno, en G2 llevamos tiempo ya dándole vueltas a esto y ayudando a nuestros clientes a crear esto que llamamos Unidades de Intervención Inmediata. 

Para ello, nos inspiramos en el concepto de Arquitectura Efímera: son instalaciones que se diseñan y se piensan teniendo en cuenta que serán poco duraderas. Están orientadas a transmitir sensaciones, mensajes o emociones a través de las formas durante un breve espacio de tiempo (semanas o quizás meses), como puede ser una instalación artística en un aeropuerto, el stand alucinante que viste en la última feria a la que asististe o un hospital de campaña montado de manera urgente para atender una situación como la que estamos viviendo.

Estas arquitecturas efímeras están pensadas para transmitir un mensaje concreto durante un tiempo concreto, de la misma manera que en IT necesitamos transmitir un mensaje concreto (la tranquilidad de dar el paso a usar una nueva herramienta) durante un tiempo concreto (el que necesite el negocio hasta haber estabilizado el uso del nuevo sistema).

Así, nuestra propuesta es la generación de una plataforma de soporte completamente nueva, especialmente orientada a apoyar a los usuarios en la transición a esta nueva manera de trabajar que supone el despliegue del nuevo servicio y que se concibe desde el inicio como una plataforma efímera: se monta rápido, se usa rápido, se destruye rápido y sólo se paga por el tiempo que se usa.

El próximo Jueves 7 de Mayo de 2020 haremos un webinar explicando cómo montamos una de estas plataformas express para habilitar una Unidad de Intervención Inmediata. En esta charla veremos cuáles son las ventajas que le aporta al cliente, tanto al equipo de soporte, como al equipo de administración de herramientas y a los usuarios finales.

Si te ha picado el gusanillo de la curiosidad, inscríbete en nuestra página del G2 Atlassian Team y trae preparadas todas las preguntas que quieras plantearle al equipo que con gusto las resolveremos.

Lo esencial es invisible a los ojos

A mediados de los años 70 yo cursaba 3º de E.G.B. Carmen, la profesora que nos había acompañado desde primero, se despedía de nuestra clase deseándonos a todos un gran futuro con una gran sonrisa y para que no nos olvidásemos de ella jamás, nos regaló a cada uno de sus alumnos un ejemplar de El Principito con una dedicatoria especialmente pensada para cada uno de nosotros.

Ese libro me ha acompañado toda mi vida y la historia ha ido variando de interpretación a medida que yo iba creciendo y ganando en comprensión del mundo que me rodea; al principio me llamaba mucho la atención la figura de las boas abiertas y cerradas y cómo era cierto que los mayores no entendían las cosas que les contábamos pequeños porque están tan influenciados por su mundo de mayores y han perdido la habilidad de imaginar que los pobres no entienden nada…

Luego me convertí en profesor y me di cuenta de que las cosas difíciles hay que explicarlas como las explican los niños. Por eso mis clases están llenas de anécdotas, ejemplos y preguntas: tengo que conseguir que los adultos que tengo delante vean el elefante dentro de la boa y no un simple sombrero (a veces, otros profesores más serios ven mis clases y me advierten de que quizás mis alumnos tan serios no van a estar muy cómodos con mi forma de dar clases, pero en general consigo despertar al niño que todos llevan dentro)

Pasaron los años y fui a parar a la mejora continua, los procesos y el uso de LeanIT y aquí volvió a entrar El Principito en acción. Uno de los principios fundamentales del pensamiento Lean es aprender a ver el flujo de valor. El libro que describe el método para representar el flujo de valor (Value Stream Mapping) se llama Learning to See: Value Stream Mapping to Add Value and Eliminate MUDA y ya nos deja claro cuál es el reto

Siempre que hay un producto para un cliente, hay un flujo de valor.
El reto consiste en verlo

…y eso que John Shook, Mike Rother, Jim Womack y Daniel Jones venían del mundo de la fabricación, donde los materiales se mueven, son tangibles y con un poco de paciencia puedes ver cómo fluyen! Quizás por eso pusieron tanto empeño en recordarnos que es un reto: lo que tenemos que ver no es un flujo de materiales sino un flujo de valor.

El flujo de valor en IT

Cuando pretendemos aplicar los métodos de gestión Lean a las tecnologías de la información nos encontramos con que algunos aspectos son esencialmente diferentes al mundo de la fabricación. Uno de estos aspectos diferentes es el concepto de Servicio IT: el servicio es intangible, es invisible, se crea en el momento de consumirse… tiene muchas características que hacen que ver ese flujo sea un reto mucho mayor aún si cabe.

Y cómo vemos y representamos el flujo de valor?

Uno de los personajes que más impactan de El Principito es el zorro. El zorro pide al Principito que lo domestique, pues eso significa crear vínculos y hacer que ambos sean importantes el uno para el otro; pasa el tiempo y el Principito se debe marchar y en la despedida el zorro le dice

–Adiós –dijo el zorro–. He aquí mi secreto. Es muy simple: no se ve bien sino con el corazón. Lo esencial es invisible a los ojos.

Hay varias técnicas para hacer aflorar aquello que es invisible a los ojos, para visualizar el flujo de valor y para representarlo de una forma visual que sea comprensible para todos. La primera, las más utilizada, la que nos enseñan John Shook y sus compañeros es la del Value Stream Mapping:

1. Identifica el flujo que quieres representar. Es decir, pon foco, no trates de representar *todos* los flujos de valor de tu departamento de golpe, que no podrás. Selecciona algo pequeño para empezar, una petición de servicio, por ejemplo. (puntero mental: aquí entra en juego el concepto S+C de Rob England)
   
2. Reúne a un equipo de personas con representantes de las diferentes unidades organizativas o grupos de trabajo por los que pasa la ejecución de este flujo. Si puedes incorporar a un cliente también, mejor que mejor.
3. Provoca un diálogo constructivo en el equipo con el fin de descubrir qué tareas y en qué orden hacemos cada uno para completar la petición (demanda del cliente).
4. Identifica qué tareas debe de hacer el cliente para poder hacer la petición (pull) y qué momentos de la verdad hay durante toda la ejecución de la petición
5. Ten la mente abierta, deja que todo el mundo se exprese y no intentes arreglar nada en ese momento: ahora estamos descubriendo el flujo, no analizándolo ni mejorándolo.
6. Cuando hayas terminado, da un paso atrás y míralo todo con perspectiva: ¿Dónde empieza? ¿Es ahí donde debe de empezar? ¿Dónde acaba? ¿Estás seguro? ¿Hay demanda fallo adicional? ¿Cuál?
7. Repite desde el punto 3 para dar un par de vueltas más

En realidad hacen falta algunos pasos más, porque después de representar el flujo de valor querrás analizarlo y para eso te harán falta más datos, sobre todo de cantidades: cuántas veces hacemos las actividades, cuántas repeticiones, cuánto tiempo tardamos, cuántos recursos hay que lo puedan hacer, cuánta variabilidad, cómo son los patrones de demanda… es decir, tendremos que llenar de números el mapa del flujo que acabamos de hacer, y esos números no son nada fáciles de conseguir.

Aquí entra en juego el método CDO de estimación de valores: piensa en el indicador que quieres calcular. Visualízalo en tu mente. Extiende el brazo todo lo que puedas. Abre la mano separando los dedos y ahora mueve la muñeca de forma oscilatoria mientras piensas “mmmmhhh más o menos soooon cuarenta!”. CDO, son las siglas de los Cinco Dedos Oscilantes (Gracias Jordi Cirera por enseñarme tan magnífica técnica!).

Si no queremos trabajar con estimaciones, entonces tendremos que acudir a sistemas de medicion, pero la gran mayoría de veces nos encontraremos con que no tenemos sistemas de medición adecuados para las tareas que estamos intentando analizar y aquí es donde viene la debacle: si tengo que montar sistemas de medición cada vez que quiera mejorar algo, va a ser más caro remedio que la enfermedad (al menos a corto plazo, claro!) y por eso es por lo que los que trabajamos en Lean utilizamos métodos de estimación y conceptos como el del valor de la información para descubrir qué variable de las que componen nuestro modelo de estimación influye más en la reducción de la incertidumbre.

En los últimos años, ha entrado con fuerza una nueva disciplina en el mundo del análisis de la información: la Minería de Procesos. Se trata de un conjunto de técnicas que tienen su origen en la Universidad Tecnológica de Eindhoven y que nos permite realizar algo parecido a una ingeniería inversa de los procesos utilizando para ello la información de logs y trazas que su ejecución deja en los Sistemas de Información.

Partiendo de estos logs, la primera etapa de la minería de procesos es el Descubrimiento del modelo de proceso, utilizando conceptos tan alucinantes como el algoritmo Alfa o el Heuristic Miner.

Una vez que hemos descubierto el modelo del proceso a partir de las trazas, viene el momento del Enriquecimiento: tenemos toda la información al respecto de quién hace las tareas, cuánto se tarda en ejecutar, cuánto tiempo están las tareas en las colas, qué tipología de tareas, en qué momento se crean los casos y cuánto tiempo tardan… lo tenemos todo, y la minería de procesos es capaz de incorporar toda esa información en el mapa del proceso de forma que puedes comprenderla rápidamente, e incluso puedes hacer un Replay y volver a ver la ejecución de cada uno de los pasos de tu proceso.

Cuando ves un mapa de estos, ocurre que de repente ¡Plaf! lo esencial se hace visible a los ojos… en realidad no estamos mirando con el corazón sino que hemos utilizado las matemáticas para hacer visible lo que hasta el momento sólo eran sensaciones o suposiciones.

La minería de procesos nos abre las puertas a entender cómo funcionan en realidad nuestros procesos, a descubrir los puntos de mejora, las características de cada uno de los pasos del proceso para saber si son estables, capaces, de calidad… Nos abre la puerta a una mejora continua objetiva e incluso a poder demostrar fácilmente si nuestras iniciativas de mejora continua realmente están dando resultados o no, en base a analizar el proceso antes y después de los cambios.

Las posibilidades son enormes, sólo hay que abrir la mente y ver con el corazón para que no se te escape lo esencial.

Más Información

Talleres de Mejora Continua en G2
Monografía sobre Minería de Procesos en la revista Novática (ATI)
Conferencia “Buceando en Standard+Case” en el congreso TFT13
Conferencia sobre el uso de la Minería de Procesos en la Auditoría de Sistemas de Información (ISACA)
Entrevista en Flux Capacitor sobre la presencia en el Process Mining Camp
Conferencia “Process Mining and Lean” en el Process Mining Camp 14
Artículo “Las posibilidades de uso de la Minería de Procesos en ITSM”, finalista para el premio Novática 2013

Crónica de una reparación

Se ve que estos meses son de fallar las cosas, así que esta vez traigo un ejemplo que, si bien es poco importante, me pareció interesante como caso de estudio de cosas que se pueden mejorar en un servicio de atención al cliente.

Antes que nada, no se vayan a pensar que soy un quejica que protesta por cualquier frivolidad: el caso, insisto, no es algo grave ni especialmente molestoso; sólo sirve para analizar un poco el proceso de atención al cliente.

El asunto es que a finales de Agosto se rompió el teléfono fijo de casa. Lo habían traído los Reyes estas navidades pasadas y estaba en garantía, de modo que allá que partimos al centro comercial donde lo habíamos comprado con la esperanza de que nos lo cambiaran por otro.

Aquí aparece el primer mensaje del caso de estudio: vamos a la tienda a realizar una Petición de Servicio porque un aparato se ha roto… ese es el tipo de Demanda más dañino con el que nos podemos encontrar, porque el Centro de Atención al Cliente tendrá que trabajar para algo que no le aporta valor a la organización y sólo me aporta valor a mi porque se ha roto. Se llama Demanda Fallo (Failure Demand) y es algo a evitar a toda costa.

Pregunta: ¿Cuánto invierte tu organización en Demanda Fallo? ¿Se podría evitar? ¿Estaría mejor invertido ese dinero en otro tipo de actividades? [ ¿Cuánto dedicas a mantenimiento correctivo y a gestión de incidencias? ]

Ya habíamos tenido contacto con el Centro de Atención al Cliente de esta tienda, así que sabíamos que nos tocaría aguantar un buen rato de cola… un buen rato, sí, pero… ¿1,5 horas? Así fue… llegamos, pillamos el número del Turn-O-Matic y esperamos… las niñas aburridas, el calor, el ruido… nos leímos el catálogo de ofertas, dimos un paseo por la tienda, esperamos en la calle, esperamos en el CAC… hasta que nos tocó el turno!

Aquí tenemos otro aspecto interesante relacionado con aquellos principios de Lean: 1,5 horas de espera para contactar con un CAC es algo exagerado. El mostrador del CAC tenía 4 terminales, pero sólo había una muchacha atendiendo. Siempre hay unas colas terribles en este lugar, lo que demuestra que el foco está puesto en la venta (asesores, cajeras, de todo! No falta personal en la zona de ventas!)

Después de la espera, la muchacha que nos atendió tomó nota de mis datos y me dijo que enviarían el teléfono a reparar, me pidió la dirección de email y el número de móvil. Me dijo que contara 30 días y que me avisarían para pasar a buscarlo. Firmé el comprobante (en el que decía que lo había entregado todo con el embalaje original) y me fui con la familia a que nos diera el aire en otro sitio.

30 días sin teléfono! No está mal en los tiempos modernos! Aquí no había SLA ni nada parecido, pero en otras ocasiones (un DVD roto, un TDT sin mando… nada importante) ya nos habían dicho siempre que 30 días.

En casa teníamos plan de contingencias: mi mujer, que es súper ordenada y lo guarda todo, tenía el teléfono antiguo; le fallaba el display pero podíamos llamar, así que podíamos esperar 30 días sin mayores problemas.

No habría pasado nada ni yo hubiera escrito esta entrada si no hubiera sido porque un buen día, una semana después de toda esta historia, me llegó un SMS a mi móvil (sin número de origen) que decía literalmente

LE ROGAMOS TRAIGA LOS ACCESORIOS DEL PRODUCTO DEPOSITADO EN NUESTRAS DEPENDENCIAS.

¿Mande? Yo entregué todos los accesorios! Y tengo un comprobante que así lo dice, pero.. el SMS no tenía número, no me habían enviado un mail así que no podía responder… y yo pensaba ¿Otra hora de espera para nada? y ya me iba calentando yo solito…

Total, que cuando llegué a casa llamé por teléfono al sitio en cuestión, a ver si podía aclarar qué accesorio les faltaba… riiing, riiing y me contesta una de esas máquinas odiosas que te preguntan 7 cosas (por ejemplo, me preguntaba 2 veces en qué idioma quería que me atendiera) para al final llegar a que me pedía un número de expediente y me respondía (a la tercera o cuarta, cuando torpe de mi conseguí atinar con el número que me estaba pidiendo) que tenía que pasar por el Centro del Atención al Cliente.

Luego me fui a la web, donde después de mucho buscar encontré un sitio donde si entrabas un número y los apellidos me dijo… ¡Que el aparato estaba listo para su recogida!

Una lección más: cada interacción con el cliente, ya sea humana o mecanizada se convierte en lo que llamamos un momento de la verdad. El servicio de atención se la juega en cada uno de esos momentos y se puede romper toda una buena imagen de atención con un momento de la verdad mal diseñado [un SMS que no me permite responder] o mal ejecutado [una máquina que no me permite interactuar]

Así… ¿qué querían estos señores, que llevara accesorios o que recogiera mi teléfono? Sea como sea, estaba condenado a ir de nuevo a la fatídica tienda… cogí a la familia, otra vez, y nos fuimos al centro comercial.

Entro en el CAC, me voy directo al Turn-O-Matic, cojo mi número y miro al indicador luminoso… que estaba apagado! Miro a mi alrededor y no veo nada que me indique por qué numero van, así que le pregunto a la chica (la misma de la otra vez) y me dice “No, es que está roto.. tiene que pedir la tanda”…

¡Qué graciosa! ¡La tanda, como en la pescadería! Así que pregunto “Quién es última?” y me responden 2 o 3 a la vez… ¡Ya la hemos liado! Mientras nos ponemos de acuerdo han entrado por lo menos 3 personas más al CAC que han ido a coger su numero y no se han dado cuenta de la movida… madre mía la que se está montando!!

Bueno, ahora que la cosa va por tanda no me puedo mover de allí, así que la espera se hace eterna. Unos 40 minutos más tarde me toca el turno y le digo a la chica que me había llegado un SMS diciendo que tenía que entregar accesorios, pero que los accesorios ya los había entregado todos…

“Ah, si..” – Me dijo – “Eso te lo envían cuando te van a hacer una sustitución del aparato; déjame que mire el expediente… a ver… si, aquí está: no tiene reparación, pero como no hay en stock, te haré un vale por el importe del teléfono” y me hizo una tarjeta por unos 40€ que es lo que costaba el maldito aparato…

Aquí podemos ver otra de las “alegrías” del caso: el momento de la verdad estaba tan mal diseñado que enviaba mensajes falsos al cliente! Precisamente el mensaje que me hizo poner de mal humor. Y por si fuera poco, es error habitual que los empleados conocen y les parece tan normal que nadie lo ha resuelto.

Finalmente, me ahorro de discutir con la señorita al respecto de si cuando yo pagué utilicé dinero de verdad o si les pagué con un vale; así que recojo la tarjeta-vale, me voy a la tienda y me compro un teléfono de la misma marca, mejor, más moderno y más barato.. cosas de la tecnología.

Podemos aplicar las ideas de Lean para analizar este caso, más allá de los comentarios que he ido intercalando:

1. El concepto de PathWay nos podría ayudar aquí: habilitar “rutas” especiales para actividades especiales... por ejemplo, una cola para entregar material y otra cola para recogerlo, ya que el procedimiento de entregar el material es mucho más lento que el de recogerlo.
2. El concepto de derroche en forma de tiempos de espera innecesarios, colas, movimiento de materiales (si realmente se llevaron el teléfono a un centro de reparaciones, el gasto fue importante!). ¿Qué tal si se decide que aparatos de menos de 100€ que no funcionen y lo que no funcione no sea una pieza móvil directamente se reembolsan? (Y si después resulta que si que funcionaba o tenía fácil reparación, lo vendes en un outlet tipo cash-converters)
3. El concepto, ¡cómo no! de momento de la verdad: esa máquina de enviar SMS hay que utilizarla lo menos posible: si el cliente ha proporcionado una dirección de email, se le debe enviar un mail para que la comunicación sea bidireccíonal. Y por supuesto, enviando los mensajes correctos! Por otra parte, cuando el Turn-O-Matic no funcione, pon un cartel que así lo indique, que ya nos organizaremos como en la pescadería.
4. El concepto de Actividad de Valor Añadido y Actividad de No Valor Añadido (VA y NVA): si representásemos el mapa de flujo de valor para esta transacción, veríamos que, a grosso modo, hay unas 200 horas de NVA frente a 10 minutos de VA… un ratio de aportación de valor al consumidor del 0,083% (!!!!)
5. El concepto de reducción de las esperas: ¿qué tal si paralelizamos y ponemos a 4 personas a atender en los momentos en los que haya picos de trabajo? Si, ya se que esto de la atención al cliente no aporta ventas pero así como vamos ahora, a)Algunos no vuelven a comprar b)Las extensiones de garantía esas que ofrecen no se deben vender mucho.
6. Walk the Gemba: Womack lo ha defendido en prácticamente todos sus libros; la verdadera gestión se debe ejercer desde el conocimiento de lo que ocurre en el lugar donde se encuentra la verdad (Gemba), osea, donde se trabaja; el director se pasa habitualmente por el CAC? Seguramente no… seguramente no lo utiliza cuando se le rompe uno de sus gadgets, y por lo tanto tienen que ser los clientes los que te hagan ver cómo funciona, visto desde fuera, la atención al cliente.

Bueno.. insisto, este ladrillo es más un ejercicio de análisis que una queja… y quien sabe! Igual los chicos de esa tienda lo leen alguna vez, les sirve de “consultoría gratuita” y la próxima vez que se me rompa alguno de sus productos me llevo una sorpresa tan grata como la del post anterior.

Una grata sorpresa

Hace poco tuve una avería de hardware con mi portátil y, como está en garantía, llamé al servicio técnico donde diagnosticaron y enviaron a un técnico para que sustituyera unas piezas. La misma tarde que vino el técnico me llamó por teléfono la chica que me había atendido en el ServiceDesk para confirmar si el técnico había llevado a cabo la intervención y para saber si podía dar el caso por cerrado. Al decirle que sí, me indicó que me llegaría una encuesta de satisfacción por correo y que si no me importaría rellenarla.

Al día siguiente me llegó la encuesta de satisfacción donde me preguntaban una serie de asuntos relativos al soporte, al técnico, etc… pero la última pregunta fue una muy grata sorpresa: destilaba pensamiento Lean por todas partes.

La aportación de valor al cliente se resumen en el Pensamiento Lean en una serie de principios que, expresados por la voz del cliente, suenan como

• Resuelve mi problema completamente
• No malgastes mi tiempo
• Dame exactamente lo que quiero
• Agrega valor allá donde yo quiero
• Resuelve mi problema cuando yo quiero

Las preguntas de la encuesta iban enfocadas a saber si se había resuelto mi problema correctamente, en plazos, en el momento que yo había indicado… preguntas habituales para saber si estoy o no satisfecho con el soporte dado. Pero la última pregunta estaba orientada a saber si yo había percibido que habían malgastado MI tiempo… el tiempo del consumidor, algo cada vez más precioso y que pocas compañías se preocupan de cuidar.

La evolución cuántica

Hoy quería escribir al respecto de los diferentes ejes que dirigen la generación de valor por los servicios TI. El primer aspecto que debemos considerar es el de recorrido histórico: la Informática es una profesión relativamente joven que en pocas décadas ha conseguido revolucionar la forma en la que las empresas utilizan la información, tanto para los procesos internos y de soporte como para articular sus relaciones con clientes y proveedores.

La evolución ha sido meteórica y ha motivado cambios profundos en la forma de hacer negocios, pero esa velocidad de cambio (y no me refiero al cambio puramente tecnológico, sino al cambio en la forma en la que las organizaciones se relacionan con clientes y proveedores) es cada vez ligeramente más lenta.

Uno de los motivos importantes es que las TIC se han convertido en un factor higiénico: las siglas TI están pasando lentamente de significar Tecnologías de la Información a significar Tecnologías Invisibles y, cuando están presentes no las notamos pero cuando faltan se produce una situación dramática.

Hay muchos inventos de la Humanidad a los que les ha ocurrido esto, de hecho es la forma habitual de evolucionar (a saltos, cuánticamente): ¿Es importante la electricidad? ¡Desde Luego! Pero estamos tan acostumbrados a ella que ya no nos parece un invento revolucionario; simplemente está: pulsamos un interruptor, una luz se enciende y nos parece lo más normal del mundo.

En las empresas ocurre exactamente lo mismo: el ERP está y cuando hay que procesar un pedido se rellenan unos formularios y nadie le da mayor importancia… hasta el día en que no funciona: entonces el mundo se viene abajo.

Es por esta razón que para aquellos servicios que están en marcha las características realmente vitales, aquellas que siempre veremos sobre la mesa del CIO son la capacidad y la disponibilidad: las Tecnologías Invisibles se convierten en un factor higiénico y queremos, sobre todo, que sigan siendo Invisibles.

Pero las Tecnologías Invisibles no son revolucionarias, no facilitan que las organizaciones se diferencien significativamente de su competencia ni que ganen cuotas importantes de mercado ni que inventen (o accedan a) mercados nuevos. Para eso es necesario que en ocasiones las TI dejen de ser invisibles y pasen a significar Tecnologías Innovadoras, ayudando a crear nuevas formas de operar, de relacionarse con clientes y proveedores, de facilitar el consumo de nuestros productos y servicios o simplemente reduciendo significativamente los costes de la compañía facilitando un comportamiento más agresivo y diferenciador en el mercado.

Este segundo eje de aportación de valor es el que se articula consiguiendo que TI y negocio trabajen juntos, integrados, para la definición, diseño y construcción de nuevos Servicios TI innovadores y, en mayor o menor grado, revolucionarios.

Pero no nos olvidemos de un aspecto importante: una vez diseñado y construido, el servicio TI no es nada más que una simple herramienta en manos de aquellos que verdaderamente deben crear valor para la compañía: los USUARIOS: aquellas personas que usan la herramienta que TI les ha proporcionado generando los verdaderos resultados para la organización.

En resumen, vemos que la aportación de valor de TI hacia la organización se compone del factor revolucionario aportado por las Tecnologías Innovadores y de la presencia permanente del factor higiénico aportado por las Tecnologías Invisibles, mientras que el valor generado por el negocio gracias a las Tecnologías de la Información estriba en el correcto USO de las TI, de manera que podemos ampliar la definición de valor propuesta por ITIL V3 con una aportación que trata de mostrar el valor generado por el negocio gracias al uso de las TIC como:

VGN=VS x USO, donde

VGN= Valor Generado por el Negocio

VS=Valor aportado por el servicio TI

USO=Uso de las TIC por parte del Negocio

por lo que

VGN=(Utilidad x Garantía) x Uso

Esta función devuelve el valor cero en caso de que cualquiera de sus tres componentes sea nulo.

NOTAS:

(1) Este artículo nace como reflexión para la mesa redonda del itSMF al respecto del valor aportado por el concepto de servicios, pero no me pareció adecuado como discurso porque disponía de poco tiempo y no encajaba 100% con la temática.

(2) La primera mención a las Tecnologías Invisibles se la escuché a Ian Clayton en el congreso de Octubre de 2009.

Un poco de Lean Thinking en el Service Desk

El foco principal del Pensamiento Lean es la reducción al mínimo posible de las actividades que no aportan valor al cliente, al tiempo que busca eliminar los despilfarros (waste/muda) que se producen a lo largo de todo el flujo de valor tanto en la provisión como en el consumo de bienes y servicios.

Si unimos esta idea con la concepción de valor que nos aporta ITIL V3, vemos que estamos ante la posibilidad de eliminar aquellas actividades dentro de la cadena de provisión (o de consumo) de Servicios TI que no aportan un valor claro al usuario en términos de Utilidad (para qué sirve el servicio) y de garantía (cómo de bien hace el servicio lo que debe hacer).

Como ya comentamos hace algún tiempo en el artículo “Una queja no es una incidencia” en el ServiceDesk atendemos una gran cantidad de interacciones de usuario diferentes, de las cuales y siempre bajo la óptica de valor ITIL V3, algunas no aportan valor alguno al usuario mientras que otras si.

A pesar de que desde algún punto de vista muy interno a las TIC podemos pensar que resolver incidencias aporta un gran valor al usuario que, frustrado y malhumorado, no puede realizar su trabajo debido a que un servicio o alguno de sus componentes no puede desempeñar adecuadamente sus funciones, hemos de pensar (en términos de garantía) que un servicio aporta más valor cuando no falla nunca que cuando somos buenísimos arreglándolo y por lo tanto, una de las consecuencias inmediatas que aparecen del hecho de aplicar el Pensamiento Lean al ServiceDesk es que se levanta la necesidad de reducir en todo lo posible la resolución de incidencias (actividad que aporta escaso o nulo valor al usuario) en aras de potenciar al máximo otras actividades que sí que aportan valor (como por ejemplo la Gestión de Peticiones).

Y así es como volvemos a llegar a la misma conclusión pero por otro camino diferente: reducir las incidencias gracias a una adecuada Gestión de Problemas y aprovechar el contacto con el usuario que nos reporta la incidencia para capturar el máximo nivel de detalle al respecto de qué es lo que la está causando y qué es lo que necesita hacer el usuario (es posible que podamos aprovechar la ocasión para explicarle una forma mejor de hacer lo que quiere, otras posibilidades o mejores usos de las herramientas de las que dispone). Cualquier cosa que facilite que la incidencia no se vuelva a producir.

Posiblemente esto vaya en contra de la forma tradicional de montar un Service Desk, en contra de las métricas del tipo “numero de llamadas por operador”, “coste medio de la incidencia”, etc., pero si conseguimos reducir el número de incidencias estaremos reduciendo el coste total de propiedad del servicio que es, en definitiva, de lo que se trata y no de reducir el coste medio de la incidencia, sino el coste global de las incidencias: mientras que 1.000 incidencias de 1€ cada una, son 1.000€ y 10 incidencias de 100€ cada una, son también 1.000€ ¿Qué entorno creen ustedes que es mejor para los usuarios, más productivo para la organización y más satisfactorio para el personal de soporte?

Moralejas:

• Incidencias sin Problemas, es un despilfarro.
• El mejor servicio es el que no falla y la mejor Gestión de Incidencias es la que no tengo que usar nunca.
• El Coste por Llamada (o por incidencia) es un invento de los outsourcers. A la organización le interesa el Coste Total de Propiedad del servicio.

ACTUALIZACION Debí haber enlazado este WhitePaper en su momento

Reducing Opex to fund Innovation

View more documents from G2, Gobierno y Gestión de TI, SL.

El último del año … y va sobre Valor

Mucho se oye hablar sobre el valor que aportan las TIC, mucha tinta (digital) se ha gastado y en los foros hay más de una discusión al respecto… ¿Qué valor aportan las TIC?, ¿Cuanto valor aporta un servicio? ¿Cuál es el valor real de las inversiones en TIC?

Muchas preguntas con muchas respuestas, pero a mi últimamente me ronda una idea en la cabeza: me da la sensación de que hay una respuesta a todo esto que va más allá de las respuestas tradicionales.

Hace mucho, mucho tiempo, cuando estaba recién egresado de la Universidad, me dedicaba a hacer programas en Clipper. Por aquella época era normal (aún sigue siéndolo, pero menos…) que mis hermanos me preguntaran si yo sabía usar un programa de contabilidad, o hacer un plano con el AutoCad o cosas así.. claro, ante la respuesta de “Pues… la verdad es que no!” siempre decían lo mismo: “Pero tío.. tú no eres informático?”

Al principio trataba de explicarles a qué me dedicaba en concreto, pero era complicado así que un buen día me salió la metáfora perfecta:

mira, brother… yo en realidad no soy mecánico; no tengo ni idea de coches ni de motores: sólo me dedico a fabricar llaves inglesas.

¿Se preguntarán los fabricantes de llaves inglesas cuál es el valor que aporta su herramienta?

Una de las grandes aportaciones de ITIL V3 es la definición del valor que aportan los servicios TIC en términos de Utilidad y Garantía. Utilidad –aquello para lo que sirve el servicio – y Garantía – en qué términos lo entregamos –

Así que la llave inglesa aporta valor en el sentido en que puede apretar y aflojar tuercas en un rango de X pulgadas y en el sentido en que puede aplicar una fuerza Y sin romperse ni doblarse ni malearse su material.

¿Y si utilizo la llave inglesa para hacer palanca para abrir una botella de cerveza? ¿No me aporta valor? O si la uso para clavar un clavo, para separar dos ladrillos mientras busco el metro, para rascarme la espalda…

En fin, que la llave inglesa no sólo me aporta el valor que pensó el fabricante que yo necesitaría, sino que me aporta todo el valor que mi imaginación como usuario de la herramienta sea capaz de sacarle.

Si llevamos este razonamiento al mundo de las TIC, veremos que una cosa es el valor que yo, como “fabricante” o “proveedor” de servicios aporto a mi cliente al ajustarme a sus necesidades declaradas, y otra cosa muy distinta es el valor que aporta al negocio el uso correcto, adecuado e incluso innovador e imaginativo de las herramientas que IT pone a disposición de los usuarios.

En conclusión, el valor que las TIC aportan al negocio se compone de la provisión adecuada de servicios TIC unida a un uso adecuado y exigente (que saque el mejor partido posible) de esas herramientas/servicios; y esto nos lleva a otra situación interesante: el VALOR no es una cuestión del Departamento de Informática, porque el USO no está en sus manos, sino que está en las manos de las organizaciones (departamentos, áreas, etc) de usuarios (que no siempre coinciden con el cliente).

Así, la aportación de valor al negocio es una cuestión cultural y organizativa… CORPORATIVA.

Feliz Año Nuevo!