Búsqueda


31 de julio de 2006

¡¡Ya tenemos diccionario!!

¡Qué bien! Ya tenemos diccionario. Mucho antes de que se inaugurase el capítulo español del itSMF unos cuantos ya estábamos trabajando en conseguir las versiones oficiales de los libros Service Support y Service Delivery en castellano. Justo ahora hace un año, que entre claras y piscinas, aprovechaba las horas de las siestas para darle un repaso a la traducción del capítulo de Gestión Financiera y, claro, como es normal tenía (y sigo teniendo) ganas de ver materializado el trabajo hecho.

Pero para que una buena traducción tenga un buen nivel de solidez, lo primero que se tuvo que hacer fue sentar las bases de un vocabulario. Así que antes del verano de 2005 nos pusimos a trabajar en el consenso de un glosario de términos del mundo de la Gestión de Servicio (dicho así suena un poco raro y tendremos que acostumbrarnos al resultado final de este glosario, porque Service Management ha quedado para la historia como “Gestión de Servicio”, ni “Gestión del Servicio” ni “Gestión de Servicios).

Ahora, más de un año más tarde al fin ve la luz de forma oficial, ya formado el itSMF España y con el peso que eso le otorga, el Diccionario Inglés-Español de Términos de Gestión del Servicio de Tecnologías de la Información (TI) (NOTA MENTAL: ¿perdón? ¿Ha dicho “Gestión del Servicio”? ¿No habíamos quedado en que era “Gestión de Servicio”?… ¡ya avisé de que tendríamos que acostumbrarnos!)

En fin, que es un trabajo que ha sido muy duro. Poner de acuerdo a tantas “fuerzas” era difícil y conseguir un consenso al 100% era imposible. Y eso que no estamos hablando de una traducción que tuviera que ser útil también para el mercado latinoamericano (que tiene una forma de hablar totalmente distinta) así que podemos estar contentos con el resultado.

Sólo me hubiera gustado que en lugar de poner algo así como “HAN PARTICIPADO: OGC, itSMF INTERNATIONAL, itSMF ESPAÑA Y EXIN” pusiera los nombres de los participantes, porque esto se comenzó a escribir antes de existir el itSMF España y además los voluntarios nos alimentamos de palmaditas en nuestro ego, y cuando no llegan pues nos las tenemos que dar nosotros mismos (que es, al fin y al cabo, lo que yo estoy haciendo en este post).

Así, pues, desde aquí mi más sincera felicitación a todos aquellos que han participado en la definición de este diccionario. A saber (al menos los que yo tengo constancia):

De la época Van-Haren:

  • Pablo Espinar
  • Raul Assaf
  • Eva Mendez-Perez
  • Lluis Martínez
  • Antonio de Pastors
  • Ferran Puentes
  • Mike Pieper

De la época ITSMF:

  • Antonio Gallego
  • Carlos Moreno
  • Javier Benito
  • José Herrera
  • José Wuilbert
  • Lluis Martínez
  • Mariano Hernández
  • Pablo Espinar
  • Michael Pereiras
  • Nigel Barron
  • Chris Lang
  • Cristina Martinez
  • Sergei Mendoza

Seguro que me dejo a alguien, sobre todo a los que han participado después de la creación del itSMF España (comité de publicaciones, comité de estándares…)

21 de julio de 2006

I Congreso itSMF España

Bueno, pues ya tenemos fecha para el primer congreso del itSMF España. El gran evento será el día 23 de Noviembre, en el Hotel Puerta de América en Madrid.

Anuncio_Congreso_logos

Aún no está cerrado el programa de conferencias, pero corren rumores de que contaremos con la presencia de algunos de los personajes más influyentes en el mundo del ITSM, como puede ser Jan Van Bon. Esta será una ocasión histórica, al fin y al cabo será la prueba irrefutable del funcionamiento del capítulo español del itSMF que, a un año de su fundación ya es capaz de montar un evento importante y con (esperamos) una gran participación.

Para más información, registro y reserva de plazas (pocas, pero bien avenidas): http://www.itsmf.es

¡¡Nos vemos en Noviembre!!

18 de julio de 2006

Los 12 monos de Jorge

Me decía el otro día el amigo Jorge que, para explicar a sus alumnos lo que es la Cultura Corporativa, les cuenta la parábola de los 12 monos. Igual se suponía que yo tenía que conocerla, pero me quedé a cuadros cuando me lo dijo y le tuve que pedir (siempre pasa cuando tu interlocutor supone que tú sabes algo obvio y en realidad no tienes ni idea de lo que te está contando) que me explicara su parábola como si fuera un alumno suyo; esta fue más o menos su historia aderezada con unos cuantos comentarios:

Los 12 monos de Jorge:

Se realiza un avanzado experimento científico en el que se van a analizar los patrones de conducta de los grupos sociales que se organizan de forma espontánea en las Organizaciones. Para ello se encierran 12 monos en una sala en la que previamente se ha puesto una escalera en el centro y, colgando del techo, un cable en cuyo extremo se ha atado un precioso plátano maduro.

Los monos entran en la habitación y lo exploran todo hasta que uno de ellos ve colgando del cielo el plátano más apetecible que ha visto en su vida. Sube por la escalera, se estira sobre sus dos patas traseras y coge el plátano, pero este no cede por estar atado a un cable. Tira un poco más, tira más fuerte y justo cuando el cable cede su presa y arranca el plátano. En el mismo instante en que el plátano se suelta del cable, una gran ducha de agua fría cae sobre la habitación dejando a los 12 monos empapados y helados sin saber qué pasa.

Esta escena se repite día tras día, cada vez que un avispado mono intenta alcanzar el manjar que cuelga del techo, hasta que llega un momento en que, conocedores de la recompensa que les espera, los 11 monos restantes apalizan sin piedad a cualquier mono espabilado que intente trepar por la escalera. Con esto hemos conseguido la Fase 1 del experimento: el entrenamiento.

La siguiente fase del experimento consiste en sacar uno de los 12 monos e introducir en la sala a un mono que no ha tenido contacto con el grupo y, por lo tanto, no sabe nada. El mono nuevo, al entrar en la habitación lo mira todo de arriba a abajo y pronto llega a la conclusión de que está rodeado de monos tontos, ya que ve claramente el plátano colgando del techo y ninguno de los monos le presta ninguna atención. Se felicita a sí mismo por haber tenido tanta suerte y ni corto ni perezoso da un salto sobre la escalera con la intención de zamparse el platanito de marras, pero antes de llegar a pisar el primer peldaño le cae una manta de hostias que no sabe ni de donde le llegan, pues los 11 monos le están pegando una paliza de órdago.

Al día siguiente sacamos de la habitación a otro de los monos ya experimentados y volvemos a colocar dentro a un mono nuevo. La historia se repite una vez más, con el agravante de que el mono que entró nuevo ayer es el que más fuerte pega. Sin saber por qué, pero “por si acaso”.

Continuamos con el experimento y día a día vamos sustituyendo a todos los monos antiguos hasta que tenemos la sala con 12 monos que no han probado el plátano, no lo han cogido nunca y jamás han visto la ducha helada; pero como a uno de ellos se le ocurra subirse a la escalera no dudarán en aplicar todo su conocimiento y pegarle una paliza al mono que lo intente… más que nada, porque es “como se hacen las cosas”.

Conclusión 1:

Eso es la Cultura de Empresa: así se hacen las cosas, como siempre se han hecho, sin saber muy bien (o nada) por qué, pero “es como se hace”. Tenemos las organizaciones llenas de personas que ejecutan un trozo de proceso sin tener ni idea de qué es lo que estamos haciendo, por qué ni para qué. Incluso hay veces que nadie en la organización sabe que eso se está haciendo y quizás esa actividad ya no sirve para nada pero, como nadie se lo ha comunicado al pobre que lo hace, él sigue dándole a la manivela cada día.

Conclusión 2:

Por eso es bueno (necesario, y hasta imprescindible en algunos casos) documentar los procesos, procedimientos y formas de actuar. Los monos nuevos podrían saber porqué no se puede arrancar el plátano. Si no hay documentación, la transmisión (si la hay) es oral… ¿te acuerdas de jugar al túnel de los secretos? Por la entrada del tunel entraba un mensaje que se transmitia de boca a oreja. Si el tunel era lo suficientemente largo, el mensaje que salía del tunel no tenía absolutamente nada que ver con el mensaje original.

Conclusión 3:

Imagina lo que le pasó al Mandril Consultor que contrataron los jefes de los 12 monos para tratar de mejorar el clima del departamento, porque cada vez que alguno se acercaba a la escalera, le caía un tortazo.

16 de julio de 2006

Me he quedado mudo

Hoy quería escribir un post, pero me he quedado sin aliento y sin palabras al coger el periódico y ver, en primera página, lo que está pasando en Oriente Medio.

No tengo palabras, ni inspiración. Sólo espanto y decepción por lo asquerosos que podemos llegar a ser los seres humanos.

Y más encima, tener que aguantar que los presidentes de los países de Occidente nos insulten tratándonos de bobos integrales con sus declaraciones.

Joder! Como decían en los años 80: “Que paren el mundo, que yo me bajo”

 

 

10 de julio de 2006

¿ServiceDesk o Gestión de Incidencias? Una queja no es una incidencia

Reconozco que había prometido hablar sobre el documento de progresos de ITIL V.3, pero me está dando una pereza impresionante escribir ese post. La idea era primero comentar los contenidos de V3 y después dar mi opinión personal sobre las formas empleadas en la redacción del documento, porque leyendo entre líneas se ven cosas muy curiosas.

Mientras me viene la inspiración, las ganas y el tiempo de hacerlo, he querido escribir sobre las diferencias que podemos encontrar a nivel de conceptos entre la idea del Service Desk y la Gestión de Incidencias. Para algunos puede resultar muy clara, pero estas últimas dos semanas he tenido que explicar la diferencia al menos tres o cuatro veces a personas distintas y eso me ha hecho pensar que seguramente sea una de las FAQs de los que se inician en este mundillo.

Siempre leemos que Service Desk es una función y no un proceso, y eso es algo que al principio te deja un poco extrañado.

¿Una función? ¿De qué me hablas?

Pues la idea es simple… muy simple: el ServiceDesk es un centro de recepción y tratamiento de llamadas o contactos por cualquier medio que en ITIL reciben el nombre de Service Calls o Llamadas de Servicio según la traducción oficial del glosario. Cuando un usuario contacta con el Service Desk puede necesitar cualquier cosa del departamento de Informática: un alta de un nuevo empleado, la formación en las aplicaciones XXX para tres secretarias nuevas, un manual de usuario para el entorno YYY, notificar una queja, pedir ayuda para rellenar un formulario en el ERP que no conoce o solicitar soporte porque la impresora no le funciona.

Total, que la función (operativa) del Service Desk es registrar todas estas llamadas, categorizarlas, priorizarlas, canalizar su resolución, documentar el progreso y mantener continuamente informado al usuario del estado de su Llamada de Servicio. Es decir, iniciar para cada llamada de servicio el proceso adecuado para su tratamiento y, en el caso concreto las llamadas de tipo “Incidencia” iniciar el proceso de Gestión de Incidencias.

En definitiva, por eso es por lo que se llama “función”: no realiza las actividades de un único proceso sino que es un “multiplexor” de procesos y la clave de todo, el gran quid de la questión está en que las personas que atienden el teléfono / leen el correo / consultan las llamadas entradas por la intranet… esas personas que son los “dispatchers” de llamadas de servicio, deben tener muy, pero que muy, muy claros los criterios de clasificación de las llamadas, para iniciar de forma correcta el tratamiento de cada tipo. Para eso, será necesario que cuando se definan los criterios de clasificación se establezcan definiciones claras y concisas de qué es cada cosa.

¿Y qué indicadores le podríamos poner a esta función? Pues indicadores que tengan que ver con la actividad de dispatching. No te dejes liar si resulta que algunos de los procesos que se deben iniciar son ejecutados por las mismas personas (esto pasa en casi todas partes en que se mezcle la función de recepción de llamadas con la resolución de incidencias de primer nivel, por ejemplo). Los indicadores apropiados para la función de ServiceDesk son los típicos de un call-center, tamaño de colas, ratios de abandono, etc.. juntos con los que miden la calidad de la función principal: la correcta clasificación de las llamadas. Parece mentira, pero clasificar de una forma correcta las llamadas ahorra tiempo y esfuerzo, elimina frustraciones en el siguiente nivel (el que debe iniciar las tareas del proceso y se da cuenta de que aquello no es lo que pensaban), mejora los tiempos de resolucion y la percepción en general que tiene el usuario. Así que contar con un indicador de % de llamadas mal clasificadas sería aconsejable, y si además puedes contar con la dimensión "tipo de llamada", mejor que mejor: así podrás saber qué tipología es la que se está clasificando mal y tratar de corregirlo.

Luego, y por separado, podrás medir cada uno de los diferentes procesos que se hayan iniciado desde el ServiceDesk,

Otra de las preguntas más habituales a este respecto es “¿Y entonces, cómo gestiono las quejas, o las peticiones de formación?” pues en este caso, la respuesta es fácil aunque no del gusto de todo el mundo: tú mismo. Tú mismo porque ITIL no da respuesta a todas las preguntas que te puedan surgir; en el Service Support se habla sobre el proceso de resolución de Incidencias, pero no hay información al respecto de cuáles son las recomendaciones de definición de proceso para la gestión de otros tipos de llamada que puede atender el ServiceDesk.

Por último, otra de las cosas a tener en cuenta en este ámbito es el conjunto de criterios a la hora de elegir herramientas que nos puedan ayudar. Ya atacaremos el tema de la selección de herramientas en profundidad algún día que tenga tiempo e inspiración, pero haremos un pequeño apunte a este respecto: si piensas montar el concepto de ServiceDesk como punto único de contacto, lo bueno sería que tu herramienta te permita registrar diferentes tipos de llamadas (a diferencia de una herramienta de HelpDesk que únicamente te dejará registrar incidencias) e iniciar diferentes vías de procesamiento en función de la categoría (distintos grupos de escalado, distintos flujos de estados, distintos campos obligatorios…) porque al fin y al cabo, una queja no es una incidencia.

Como dice el libro aquel, Una queja es un Tesoro

1 de julio de 2006

{ eon8 } Deployed

Vaya pedazo de experimento el que ha hecho en los últimos meses el muchacho este. De repente me llegó un mail de un amigo diciendo “hey, tío! Has visto esto?”.

Me conecto a la página y veo una página que da un poco de susto con una cuenta atrás que terminara el 1 de Julio. Un poco de Google me lleva a ver que hay toneladas de entradas en los forums de gente que lleva rato “pillada” tratando de imaginar qué es eso del EON8. Los hay que dicen que es el fin del mundo, un ataque terrorista, un ataque de virus, una campaña de marketing… ¡Hasta ha conseguido su propia entrada en la Wikipedia (si no la escribió él mismo para darle más credibilidad al tema, claro!)

Eon9

Reconozco que también me lo pensé un poco, aunque al final aposté por una campaña de marketing para el lanzamiento de un nuevo videojuego. Había gente que decía que estaba “demasiado currado para ser un fake”, aunque si rascabas un poco no estaba tan currado (sobre todo la parte de comentarios del tipo == BEGIN E8 COMMENT == en los foros.

No pude verlo en directo, porque la cuenta atrás acababa a las 6 de la mañana, pero hoy lo primero que he hecho ha sido conectarme a ver qué había pasado y ahí estaba Mike con su fantástico sentido del humor explicando qué había hecho, cómo había hecho el experimento y en su despedida… la canción final de “La vida de Brian”

Me quito el sombrero, reflexiono al respecto de lo fácilmente sugestionables que somos y confirmo que me encantaría ver un análisis de todo esto, con todos los datos… número de hits, entradas en los foros, número de consultas al whois

UPDATE1: ¡¡Hay que ver lo rápidos que son los americanos para esto del negocio!! Ya han sacado una tienda de merchandising E8... hasta un tanga E8 tienen!

UPDATE2: Aqui hay un articulo que explica la historia, por si te has quedado con ganas de saber más.

UPDATE3: Un club de fans? ¡¡Esto es lo último!! Estamos mal, eh? pero que muy mal!