BPIC 2014 Student Challenge

¿Tienes la impresión de que la minería de procesos es una de las cosas más interesantes que has aprendido en tus estudios este año? ¿Estás pensando en hacer un proyecto de final de carrera o de fin de master centrado en la temática de la minería de procesos? ¿Te ves a ti mismo como analista de procesos en una gran compañía o trabajando como consultor en mejora de procesos una vez que termines tus estudios? Si es así, entonces el BPIC 2014 Student Challenge es el reto y la oportunidad que estabas buscando.

Cada año, el BPI Challenge agrupa a los mejores profesionales de minería de procesos e investigadores de todo el mundo en una actividad que les permite comparar sus habilidades y perspectivas en el análisis de procesos. Esta competición pública se basa en un conjunto de datos extraído de una aplicación del mundo real, proporcionada por una gran compañía que se plantea cuestiones relevantes al respecto del funcionamiento de sus procesos; no estamos hablando de un ejercicio teórico… esto es la vida real!

La invitación está abierta, todo el mundo será bienvenido. Puedes consultar los resultados de años anteriores 2013 y 2012 para hacerte una idea de cómo funciona y qué resultados son los que se han obtenido en las otras ediciones del campeonato.

Este año, por primera vez, se organiza además un campeonato de estudiantes. Como estudiante, esto significa que, mientras que estás analizando los mismos datos reales que los equipos de profesionales e investigadores, tu entrega se juzgará en un track especial y se comparará únicamente con los trabajos presentados por otros estudiantes, lo que hace la liga más justa.

El programa de mentores

Pero aún hay más: Gracias al programa de mentores, puedes conseguir acceso exclusivo y soporte de algunos de los profesionales más experimentados en el sector de la minería de procesos (algunos de los cuales también se presentarán al concurso en el track principal):

Fluxicon organiza un programa de mentores en el cual cada equipo de estudiantes se emparejará con un profesional con experiencia en la minería de procesos que se prestará su apoyo para preparar el trabajo a presentar. Comprobarás por ti mismo que para redactar las conclusiones finales de tu estudio es fundamental tener conocimiento del área analizada y un buen conocimiento del proceso a estudiar, y tu mentor será el encargado de ayudarte en este terreno si de repente te encuentras encallado.

Tienes de plazo hasta el 31 de Mayo para solicitar tu emparejamiento con un mentor, y esto se va a hacer en modo FIFO: el primero en llegar será el primero en ser emparejado, así que no lo dudes, date prisa y consigue tu mentor ahora mismo en este enlace:

https://fluxicon.wufoo.com/forms/mentorship-program-bpi-challenge-2014/

El equipo de Fluxicon intentará emparejarte con un mentor de tu zona geográfica o al menos de tu mismo idioma. Esto debería facilitar la comunicación y ¡quien sabe! quizás os podéis conocer en persona! Pero no pierdas el tiempo, porque hay un número muy limitado de mentores disponibles para esta edición del BPIC.

¿por qué deberías participar?

¿Estás listo para montar tu equipo? Aquí te dejamos algunas ideas de por qué creemos que deberías participar:

• Perfeccionar tus habilidades: Los data scientists son una de las profesiones más buscadas en estos momentos. Comienza pronto a desarrollar tus habilidades como analista, añade algunas medallas importantes a tu currículum y ábrete las puertas a un nuevo conjunto de oportunidades laborales.
• Construye relaciones: Tener un tutor te facilitará presentar un mejor trabajo a concurso, pero por encima de esto, seguro que aprenderás una o dos cosas valiosas de tu mentor, quizás aparte de los contenidos del campeonato en sí mismo.
• Porque mola: La minería de procesos es una de las técnicas de análisis de datos más interesantes hoy por hoy. Está basada en datos y al mismo tiempo es visual. Además, con el BPIC 2014 tendrás la oportunidad de bucear en datos reales y ganar una visión única de cómo funciona un proyecto de minería de procesos en el mundo real.
• Ops! También hay premios! El equipo ganador obtendrá un iPad esponsorizado por la Universidad de Tecnología de Eindhoven.  También, para uno de los miembros del mejor equipo holandés el grupo de interés especial en minería de procesos de la asociación holandesa de industria patrocinará el viaje a Halifa, Israel, para la ceremonia de entrega de premios durante el congreso BPM 2014.

Recomendamos equipos de dos a cuatro personas. Pos supuesto, puedes participar en solitario, pero pensamos que hacerlo en equipo será mucho más divertido.

detalles de participación

Fecha Límite: 12 de Julio de 2014, 23:59 CET

Dónde: https://www.easychair.org/conferences/?conf=bpic2014

Tu proyecto debe contener un informe en PDF de 30 páginas como máximo incluyendo imágenes y tablas, utilizando el formato  LNCS/LNBIP especificado por Springer (y del que existen plantillas Word y LaTeX). Se pueden añadir apéndices, pero deben incorporar únicamente información que sea de apoyo al texto principal.

Puedes conseguir más información en la web del BPI Challenge.

AYUDANOS A CORRER LA VOZ!

Si no eres estudiante, pero conoces a estudiantes que se puedan querer presentar, o conoces a alguien que a su vez conozca estudiantes… ayudanos a correr la voz y a hacer que esta edición del BPIC 2014 sea especial!

Gracias!

The BPIC 2014 Student Challenge is supported by the Rabobank, Fluxicon, Eindhoven University of Technology, the IEEE Task Force for Process Mining, and the SIG Process Mining of the Ngi-NGN.

 

POSTDATA

Este texto es una traducción más o menos libre del texto original publicado en el blog de Fluxicon.

Este año, el equipo de Fluxicon ha contado con nosotros (G2) para actuar como mentores para estudiantes hispanohablantes… así que espero que te presentes y podamos jugar juntos!!

Los datos que se analizarán provienen de una implantación de HP Service Manager 9.X en Rabobank, por lo que podremos analizar información de procesos ITIL® de Incidencias y Cambios en un entorno real del sector bancario… qué más se puede pedir? :-)

¡¡Te esperamos!!

Standard, Case y los procesos estructurados

En Diciembre del 2012 Rob England presentó en el congreso TFT12 una aproximación bastante novedosa a cómo enfocamos los procesos en ITSM. Esta nueva aproximación recibió el nombre de Plus! Standard+Case a falta de encontrar un nombre mejor que transmitiera el significado y además fuera lo suficientemente “pegadizo” para convertirse en el hit del verano ITSM.

Tuvo buena acogida y en Mayo de 2013 se presentaba el libro en el que Rob describía con pelos y señales esta nueva aproximación Plus! the Standard+case Approach: See Service Response in a New Light ;  luego, en Junio de 2013 durante el congreso TFT13 Rob presentó de nuevo su visión (esta vez con mayor profundidad y mejor estructura).

El modelo S+C plantea una realidad en la que podemos encontrar dos tipos complementarios de procesos: los que tienen una forma completamente estructurada y los que no.

Aquellos que tienen una forma estructurada son los procesos que cumplen a rajatabla la definición que encontramos en todos los libros:

 

un proceso es una serie estructurada de acciones que buscan cumplir un objetivo concreto, con [ blah blah blah …]

 

En fin, si eres lector de este blog seguro que ya te suena esta definición… Los procesos de este tipo se predefinen, son una serie estructurada de acciones y por lo tanto las actividades tienen estructura, tienen un orden predefinido.

El ejemplo ITSM que mejor encaja en esta definición es un cambio estándar. Según la definición que podemos encontrar en los libros de ITIL®

(ITIL Service Transition) A pre-authorized change that is low risk, relatively common and follows a procedure or work instruction – for example, a password reset or provision of standard equipment to a new employee. Requests for change are not required to implement a standard change, and they are logged and tracked using a different mechanism, such as a service request. See also change model.

Para este tipo de proceso podemos predefinir las actividades, los recursos necesarios, los niveles de aprobación, el presupuesto y el tiempo de ejecución, porque son completamente predecibles. Este es el tipo de proceso que encaja a la perfección con los conceptos de industrialización, reducción de la variación y con la aplicación de métodos industriales como Six Sigma.

Así, si utilizamos el ejemplo de la provisión de un equipo estándar para un nuevo empleado nos podemos hacer a la idea de que podemos comprometernos en plazos y en costes, podemos hacer una estimación de los recursos y perfiles que necesitaremos y podemos tener predefinidos los procedimientos a utilizar para cada tipo de equipo estándar o perfil de empleado a satisfacer.

De hecho, incluso podemos plantearnos analizar el tiempo medio de entrega, pensar en la desviación estándar de este tiempo de entrega y utilizar mecanismos como el VSM o DMAIC para reducir esta desviación estándar aportando estabilidad al proceso de entrega.

…y por el otro lado están los procesos que no son tan estructurados, aquellos en los que no podemos definir las actividades con anterioridad porque son un tipo de proceso en el que cada actividad proporciona un conjunto de información que influye en cuál será la siguiente actividad de que ejecute en el proceso. Así, un médico avanza en el diagnóstico de un paciente a medida que va obteniendo resultados de las diferentes pruebas que realiza y decide la siguiente prueba en función de su conocimiento y del resultado de las pruebas anteriores. Igualmente, un investigador avanza en la resolución de un crimen realizando pruebas e indagaciones que alimentan el conjunto de información de la que dispone hasta llegar a una conclusión… pero al iniciar el caso, ni el médico ni el investigador sabían a ciencia cierta cuál era el camino que seguirían.

En el mundo de la gestión de procesos de negocio (BPM) a este tipo de situación se le denomina Case Management y uno de sus aspectos fundamentales es que no podemos predeterminar el conjunto de actividades que se llevarán a cabo y por lo tanto no podemos predecir con exactitud los recursos, perfiles, plazos o costes en los que incurriremos. Esta naturaleza impredecible de los casos hace que no podamos (o no debamos) utilizar mecanismos industriales como Lean o Six Sigma para su control precisamente porque no están estandarizados. De hecho, Taiichi Ohno decía

 

When there is no standard, there is no Kaizen

 

 

Entonces, para gestionar adecuadamente el mundo de los casos, lo que necesitamos son políticas, orientación para que el profesional que está llevando adelante un caso sepa cuánto tiempo, recursos, presupuesto, perfiles puede utilizar para avanzar en su ejecución. Pongámonos en situación imaginando que tenemos una de esas incidencias complicadas que no sabemos cómo resolver (es decir, con la información de la que disponemos en el momento cero más nuestro conocimiento, no sabemos hacia dónde ir). En esta situación no podemos aspirar a que los tiempos objetivo de resolución se cumplan, o que el coste por incidencia sea inferior a XX€. En realidad, lo que ocurrirá es que se irán realizando pruebas o consultando con otras fuentes de información más elaboradas (escalado a N2 o N3) hasta que lleguemos a una conclusión. Bajo este paradigma, ¿en qué momento debemos parar?

Podríamos derivar todo el hilo de la historia hacia aspectos teóricos de si la gestión de incidencias o la gestión de problemas, que si los workarounds y los SLA… pero lo cierto es que en realidad lo que pasa es que no tenemos ni pajotera idea de cuándo podremos tener la cosa resuelta, de la misma manera en que cuando se presenta un caso difícil un médico no sabe cuándo tendrá el diagnóstico… hasta que no dé con el bicho, no habrá diagnóstico (recuerdo a mis padres haciendo biotipificaciones y antibiogramas como pieza fundamental del diagnóstico y cura de un paciente) y por eso en este tipo de casos nos debemos regir por políticas que establezcan qué tipo y cantidad de recursos está la compañía dispuesta a invertir/utilizar para la resolución del caso.

Desde el momento en que Rob comenzó a hablar de esto supe que tendría éxito. No está diciendo nada que no supiéramos anteriormente con respecto a procesos estructurados o no estructurados, pero lo que sí que es importante y tiene que cambiar cómo nos enfrentamos a la realidad del día a día de la Gestión de Servicios es que, siendo conscientes de que existen estos dos mundos, debemos aplicar diferentes métodos para su gestión:

• Podemos trabajar con SLAs de tiempo y predicciones de coste en el mundo Standard y debemos trabajar con políticas y marcos de referencia que limiten el numero de recursos a invertir en el mundo Case.
• Los perfiles a asignar en el mundo Standard son totalmente diferentes a los que debemos emplear en el mundo Case, y de hecho cada persona puede sentirse más o menos cómoda trabajando en el mundo Standard o en el mundo Case en función de sus aptitudes o su carácter.
• Las herramientas a utilizar son diferentes, o al menos deben poder contemplar realidades standard (de flujo predefinido)  y realidades case (de flujo abierto, bayesiano)
• Los indicadores son radicalmente diferentes: cuando buscaremos medias y desviaciones estándar en el mundo Standard, buscaremos ratios de utilización de recursos y grados de documentación (para facilitar “la estandarización del caso”)

La clave de Standard+Case no se encuentra en la definición o no de procesos estructurados… eso ya lo sabíamos.

Lo esencial que nos cuenta este libro es que debemos tener una serie de patrones que nos ayuden a movernos en los dos entornos.

¿Has pensado ya en cómo articularás tu próximo contrato de outsourcing?

Consumada la venta de ITIL

Es curioso cómo son las cosas… hay días en que parece que los astros se alineen para dar esas coincidencias extrañas que pasan sólo muy de vez en cuando. Esta mañana he estado repasando un poco la línea temporal sobre historia de ITSM que tengo para mis clases y me di cuenta que una de las últimas entradas era la publicación del concurso para formar una joint-venture que impulsara las best-practices del gobierno británico (ITIL, MoV, Prince, etc..). Como no había tenido novedades al respecto y el tema había levantado bastante debate entre los profesionales del sector, me puse a buscar a ver si había algo de información al respecto del resultado, pero no encontré nada.

Luego, después de comer miré el correo y zas! ahí estaba la notificación de que se había publicado la nota de prensa con el resultado de esta aventura: la formación de una Joint-Venture con una empresa que yo no conocía de nada: Capita PLC

Esta Joint-Venture tiene aspectos muy curiosos. Empezamos leyendo la composición: 51% Capita, 49% Cabinet Office (o gobierno británico o su majestad la reina… los actuales dueños, vamos). Cuando salió la noticia del concurso hubo mucha discusion al respecto de si una JV sería vender ITIL® o no… para mi ahora está claro: si te asocias con alguien y ese alguien tiene más del 50% del asunto, lo has vendido. A partir de ahora, en las decisiones importantes, quien manda es Capita, no la Cabinet Office.

Otro aspecto interesante son los matices de la nota de prensa del gobierno británico:

Capita plc will own a 51% share of the new company. It will bring commercial expertise and enable investment needed to develop the products and break into new international markets. The government will retain 49% to ensure taxpayers benefit as the business grows.

Ojo, que no dice que se quedan el 49% para asegurar el buen crecimiento de los estándares ni la calidad de los mismos ni nada por el estilo… se quedan el 49% para asegurarse el beneficio. Y punto. A lo largo de toda la noticia se habla constantemente de los beneficios económicos y de las grandes perspectivas de comercialización que tienen los productos. Si alguna vez hubo alguna posibilidad de que ITIL® pasara a formar parte de la cultura general en forma de material libre, ya nos podemos olvidar… y eso significa también que la cultura de compartir y enriquecer los contenidos de las Best Practices de una manera similar a las comunidades open source desaparecerá rápidamente.

Y todo esto para qué? ¿A qué se dedicará la nueva empresa?

The new company will accredit exam institutes and training organisations to run exams and courses. It will act as an exam institute itself for the Project and Programme Management portfolio, including PRINCE2® products. Professionals using the qualifications will benefit too.

Asi que quedará como ente acreditador para los institutos examinadores y empresas de formación… ¿Qué pasará con APMG? En su página web apenas si hay una pequeña mención al tema… como si lo dijeran con la boca chica. Ellos hicieron ya un movimiento con ISACA que les puede salvar el trasero al menos en lo que a ITIL se refiere: están en el negocio de las certificaciones de COBIT 5, y eso puede ser muy grande si lo saben mover bien.

Y EXIN también ha movido ficha, anunciando en su pagina web la noticia e incluyendo un comentario esperanzador al respecto de que CAPITA respetará el ecosistema actual. De todas formas, tanto APMG como EXIN tienen sus salvavidas particulares en caso de que a estos británicos se les vaya la pinza.

¡Qué curioso es este mundillo!

Te puede interesar mirar atrás:

El futuro de ITIL (Noviembre de 2006)

La vuelta al cole (Septiembre de 2006)

Un paseo por la historia

Siempre que doy un curso, ya sea de ITIL®, de ISO/IEC 20000, o de Gestión de Servicios acabo pintando en la pizarra una línea histórica para tratar de poner las cosas en contexto. Al final, me he animado y he montado un timeline con los principales hitos que han sucedido en todo este mundillo.

No tengo muy buena memoria, así que se agradecen todas las puntualizaciones, añadidos y sugerencias que se te ocurran!

 

Historia ISO/IEC 2000 & ITIL on Dipity.

Ptolomeo VS Copérnico

En la antigüedad, los primeros científicos miraban al cielo y trataban de darle una explicación razonable a lo que observaban. Una de las primeras cosas que vieron fue que todas las estrellas del firmamento se desplazaban por la cúpula celestial al unísono, manteniendo las distancias y proporciones entre ellas, por lo que usando la imaginación y contando historias sobre ellas pudieron trazar líneas imaginarias y dibujar las constelaciones que han llegado hasta nuestros días.

Pero también observaron que había algunas de estas estrellas que no se comportaban como las demás; éstas, a las que llamaron πλανήτης planētēs (los “herrantes”) se movían por el cielo siguiendo unos patrones concretos, adelantando y retrasando su marcha por el cielo y pasando siempre por las mismas zonas, en una franja alrededor de la esfera celeste que cruzaba 13 ó 14 constelaciones: el Zodiaco

Allá por el año 140 d.c. Claudio Ptolomeo se planteaba cómo justificar científicamente el recorrido de los planetas por el cielo. Aplicando las suposiciones de la época para la cosmología, puso a la Tierra en el centro del universo y todo giraba en torno a ella; de esta manera, para poder modelar el movimiento que realizan los planetas alrededor de la tierra tuvo que utilizar el concepto de epiciclos definir un sistema complejísimo que efectivamente era capaz de predecir la posición de los herrantes en el cielo para las diferentes épocas del año.

Este modelo perduró durante más de 1.000 años, hasta que allá por el año 1543 el polaco Nicolás Copérnico publicó una obra que revolucionaría las bases de la ciencia del momento: de las revoluciones de las esferas celestes, donde tomaba el testigo de las hipótesis de Aristarco de Samo y se resistía a que la realidad fuese tan terriblemente complicada: puso al Sol en el centro del modelo y de repente todo se simplificó terriblemente, dejando un modelo justificado matemáticamente, que era mucho más sencillo y que plantaba la semilla de la Revolución Científica.

Este fin de semana tuve de nuevo contacto con las teorías Geocéntrica y Heliocéntrica durante una visita al CosmoCaixa, y de repente me saltó a la cabeza la idea de que es increíble que la Humanidad se haya pasado más de 1.000 años defendiendo un modelo que, a pesar de lo terriblemente complejo que era, se daba por bueno porque realmente permitía demostrar las observaciones. Todo se basaba en la creencia de que la Tierra era el centro del Universo y que todo giraba en torno a ella, cosa bastante normal ya que aparentemente todo gira en torno al observador.

Hizo falta un salto hacia adelante de una mente que quiso cuestionar el Statu-Quo del conocimiento del momento (y que viéndose en el final de sus días no tuvo miedo de publicar el libro frente a la amenaza de la Inquisición) para que la ciencia pudiese sentar las bases de lo que es hoy en día.

De ahí a extrapolar el concepto (llevado posiblemente por la coincidencia en el uso de los epiciclos para explicar la complejidad del modelo PDCA multinivel) al mundo de la Gestión de Servicios no había mucho: desde los inicios de la Informática hemos pasado por diferentes teorías, la Calculocéntrica, la Infocéntrica, la UsuarioCéntrica, la CPD-Céntrica o la Distributo-Centrica… y en el mundo de la Gestión hemos pasado por la ProyectoCéntrica, la PresupuesCéntrica y llevamos 20 años encallados en la ServiCéntríca tratando de avanzar…

Aparecen algunas voces ingeniosas que hablan del fin de la Gestión de Servicios, por la teoría CloudCéntrica o por la teoría ProcesodeNegocioCéntrica, e incluso a veces se ven nuevos aromas que vienen del mundo de la industria con teorías ClienCéntricas y ValorCéntricas…

Pero desde luego, la teoría ServiCéntrica con #ITIL como principal estandarte parece que se demuestra demasiado compleja como para representar una realidad que, si bien más difícil, la mayoría de veces es más simple. No se si no deberíamos dar un salto adelante, romper los “silos funcionales” no ya dentro de IT sino dentro de la organización y buscar un modelo UsuarioCéntrico en el que nos centremos en el conjunto total de necesidades que tiene un usuario para ejecutar sus actividades y se las resolvamos, completa y sinérgicamente… o quizás en un modelo ConsumidorCéntrico que establezca al consumidor final como centro del universo.. pero en este caso, ¿en qué punto de la cadena de valor paramos?

De todas formas, ¿De verdad los clientes reciben valor en forma de activos estratégicos denominados servicios y cuando los consumen quedan exentos de los riesgos y los costes? O la cosa podría enfocarse de un modo un poco más fácil?

El fin de los buenos tiempos de la V2

… y al final todo lo bueno se acaba… ya me lo decía mi madre y así lo aprendí desde pequeño. El pasado día 29 de Octubre, en la reunión de capítulos internacionales del itSMF en Barcelona, la OGC anunció oficialmente el fin de ITIL V2.

Desaparece la formación, desaparecen los exámenes y desaparecen los libros, de manera que para finales del 2010 habrá dejado de existir cualquier posibilidad de obtener certificaciones en ITIL V2 y para mediados del 2011 ya no podremos comprar nunca más los libros rojo y azul que marcaron historia en la Gestión de Servicios TIC.

El calendario es claro:

• El examen de V2 Foundations desaparece para Junio de 2010
• El examen de V2 Service Manager desaparece para Agosto de 2010
• Los exámenes de V2 Practicioner desaparecen en Diciembre del 2010, junto con el de Foundations Bridge.
• El Manager Bridge (para convertir tu Service Manager en ITIL Expert), finaliza en Junio de 2011
• Las publicaciones de Service Support y Service Delivery desaparecen en Junio de 2011

La frase literal del anuncio de la OGC está clara:

Removal of version2 will complete on 30 June 2011

Esto va a sacudir un poco el sector:

1. Todos aquellos que quieran conseguir el ITIL Expert a corto plazo, tendrán que correr si quieren utilizar la vía “barata” cruzando desde el ITIL V2 Service Manager
2. Todos aquellos que quieran que su titulación Service Manager actual siga siendo válida unos pocos años más, tendrán que pasarse a ITIL V3 Expert
3. Todos aquellos que piensen que las certificaciones en ITIL V3 no tienen el mismo valor que las de V2, se pasarán al esquema de certificaciones en “ITSM according to ISO 20000” que está promoviendo EXIN o a otras similares.

Así que prepárense amigos! El año 2010 va a ser el año de la formación en ITIL V2; creo que se darán más cursos de Service Manager que en los últimos 3 años juntos.

Desde mi punto de vista, una pésima decisión de la OGC; pero una forma brillante de terminar de exprimir el jugo a un producto que ellos mismos habían hecho entrar en la etapa de cierre, al tiempo que admiten públicamente que ITIL V3 no está del todo correcto y que necesita una “re-escritura”…

¿Nos enviarán una copia de la nueva versión a los que compramos los libros anteriores?

¿Nos mantendrán las titulaciones a los que nos examinamos de la V3, o tendremos que hacer de nuevo los exámenes de la 3.1?

Veamos qué nos depara el futuro, y espero que quien gane la redacción de los libros de ITIL 3.1

a)disfrute de sus 10.000 libras (bueno, parece que el libro de Estrategia está un poco peor de lo que pensaban, y pagan 15.000 por él) y

b)haga un buen trabajo.

Cómo aprobar el ITIL Service Manager ( y IV)

Sé que llego tarde. A estas alturas, ya se están examinando los últimos Service Managers de ITIL V2 y dentro de poco esta ruta de certificación quedará cerrada para siempre y de repente, vengo yo con este post anacrónico. Pero tenía una deuda pendiente y espero llegar a tiempo para saldarla.

Los posts anteriores tenían que ver sobre todo con la preparación al examen, pero el que me faltaba por escribir era el post dedicado especialmente al día del examen. El mío me queda ahora ya un poco lejos, pero trataré de exponer los trucos necesarios para pasar el examen y con nota:

La Duración: Este es un examen largo; no olvides que son unas cuatro horas en las que tendrás que escribir mucho y a mano... y este es un ejercicio físico que ya tenemos olvidado. Llévate algo de beber, a ser posible dulce pero no empalagoso, tipo glucosade o cosas por el estilo (no olvides que "la glucosa es el alimento de las neuronas") y sobre todo, pasa por el servicio antes de tu examen de Gestión de Servicios!

Las Manos: Espero que durante las clases y los ejercicios de preparación al examen hayas hecho muchos trabajos redactados a mano, porque ahora es el momento de demostrar cómo estás de forma física en los dedos de la mano con la que escribas. Mi experiencia particular fue que en el primer examen escribí unas 34 páginas, lo fueron algo así como 7 minutos por página incluyendo el tiempo de pensar lo que quieres poner... no puedes permitir que te frene ningún aspecto físico.

A mí, lo que me pasó fue que me dolían tanto las yemas de los dedos y el sitio donde debía haber estado ese callo que tanto esfuerzo me costó cultivar durante mis tiempos de estudiante, que no me podía concentrar en lo que quería escribir; estoy seguro de que la calidad de lo que escribí en las últimas 10 páginas dejaría mucho que desear.

En el segundo examen no me pillaron con semejante tontería: todos los dedos iban debidamente forrados de esparadrapo... no hay dolor --> Incrementa la concentración y, por lo tanto, las probabilidades de aprobar.

El Contenido: Creo que ya lo he dicho anteriormente, pero por si acaso hay que recordarlo: este es un examen de ITIL V2 Service Support y Service Delivery. El resto de lo que sepas no le interesa al corrector del examen. Céntrate en dar contenidos que tengan que ver exactamente con lo que pone en el libro rojo y el libro azul... toda tu experiencia como Service Manager ahora no sirve para nada si no la escribes en términos de ITIL.

Es muy importante recordar esto: estás aquí para aprobar un examen que te dará una de las certificaciones más importantes del mundo ITSM... no para demostrar todo lo que sabes; para aprobar un examen... para aprobar un examen... métetelo en la cabeza: para aprobar un examen.

¿Y cómo se aprueba un examen? Pues ganándote esos malditos 50 puntos que necesitas... a por ellos!!

El Corrector: Piensa en el corrector. Ese pobre tipo que debe corregir cuarenta exámenes en dos semanas, cada examen de 40 páginas escritas a mano por gente que ha perdido la costumbre de escribir a mano y que además está en una situación de nerviosismo importante... si le facilitas la vida, estará automáticamente a favor tuyo y subconscientemente te dará ese par de decimillas que pueden ser la diferencia entre el pin rojo y el pin verde.

Por lo tanto, hay que ganárselo: lo que escribas debe ser fácil de leer así que buena letra, frases cortas y bien puntuadas, redacción clara (no es una novela ni un post de este blog tradicionalmente ladrillero... es un examen), escribe las páginas por una sola cara, numera todas las páginas y, si tienes tiempo, pon un extracto del enunciado al principio de cada página por si se pierde, y en otro color.

Para después poder entregar el examen ordenado (si no, no estás cuidando al corrector) lo ideal es que cada respuesta empiece en una página individual y así puedes tenerlas ordenadas en bloques de respuestas.

La Carrera:  Esto es una carrera contrarreloj que se gana sumando puntos. Olvídate de tu mentalidad secuencial, y no intentes responder las preguntas de una en una... este es el mejor y más importante de los trucos que tengo para darte:

Cuando te den el examen, leete todas las preguntas, completas. A medida que las vayas leyendo, verás que hay algunas que "están tiradas, facilisima"; esas márcalas con 3 palitos. Las que estés más o menos, las marcas con 2 palitos y las que veas que no tienes claras, con 1 o ningún palito.

Al final de la lectura, tendrás todas tus preguntas clasificadas según el grado de "confortabilidad" que tú sientes para responder... así que coje primero todas las preguntas marcadas con 3 palitos y respondelas en orden de puntuación que te den (cada pregunta tiene asociados unos puntos y están reflejados en el texto del examen); luego las de 2 palitos, luego las de 1 y, si te queda tiempo, ponte a pensar en qué poner en las de 0 palitos.

La Puntuación: ¿Te dieron un modelo de respuestas de ejemplo durante las clases? Fíjate bien.. en ese manual, aparecen los criterios de puntuación que luego seguirán los correctores (que tienen también una guía de corrección para que el reparto de notas sea homogéneo y no dependiente del corrector). Así, por ejemplo, el mío pone cosas como:

Pregunta: El proveedor de la aplicación de correo tiene su propio Service Desk. [blah blah] ¿Los usuarios deberían contactar directamente con el ServiceDesk del proveedor y qué alternativas hay posibles? [10p]

Respuesta: Los usuarios no deben contactar con este SDesk porque entonces Pecunia pierde el control y la información (no te acuerdas de aquello del SPOC?)

Alternativas: El Sdesk de Pecunia re-enruta las llamadas directamente al HelpDesk del proveedor o bien se pide al proveedor que forme al equipo de Pecunia para que ellos den el primer nivel.

Criterios de Puntuación:

• 4 puntos, por no permitir a los usuarios llamar al proveedor
• 3 puntos por cada alternativa
• 10 puntos máximo.

¿Qué significa esto? Pues directamente que cada pregunta no es todo o nada y que por lo tanto, incluso en aquellas preguntas marcadas con 1 o ningún palito, puedes rapiñar unos puntillos que son importantes para aprobar... no importa que la respuesta quede incompleta, si de una pregunta que vale 8 puntos puedes sacar 3, bienvenidos!! (volvemos al punto de "La Carrera"... se trata de rapiñar el máximo de puntos, no de escribir un libro docente).

El Caso de Negocio:  El espíritu que hay detrás del examen es ver si eres capaz de centrarte en el caso de negocio, por lo que es muy importante que hayas leido y preparado el documento que te dieron. Siempre que la pregunta vaya ligada al caso de estudio que te proporcionaron, adecúa tu respuesta al caso y cita (en la medida que sea posible) las políticas y conceptos que hay tanto en el caso de estudio como en el texto que te han dado con el examen. Si hablas sobre los beneficios de la Gestión de Problemas "en genérico" posiblemente no puntúes la respuesta, mientras que si hablas de la Gestión de Problemas en CTI S.L. y su problemática de transporte internacional, te llevarás la máxima puntuación para la pregunta.

Bueno... la verdad es que no se me ocurren más consejos que darte, salvo que duermas bien antes del examen, que vayas relajad@ y que pienses un poquito antes de responder cada pregunta, pero no demasiado... te tiene que salir instintivo, que para eso llevas un par de meses preparándote.

Postdata: Si apruebas usando estos consejos, pásame un mail o deja un comentario.

OTRAS LECTURAS DE INTERES:

Cómo aprobar el ITIL Service Manager I
Cómo aprobar el ITIL Service Manager II
Cómo aprobar el ITIL Service Manager III

De birras con el sector duro

I amar prestar aen
Han mathon ne nen
Han mathon ne chae
A han noston ned wilith
[...]

El mundo está cambiando
Lo siento en el agua
Lo siento en la tierra
Lo huelo en el aire
Mucho de lo que era, se ha perdido...
pero nadie vive que lo recuerde

Interpretación libre del Señor de los Anillos

Los días 21 y 22 de Abril se hizo historia. Tuve el increíble privilegio de que Jan van Bon me invitara a la conferencia organizada por itSMF-NL (si no la cuna, el sitio donde ITIL creció) y por bITa Center en un pequeño pueblo de Holanda llamado Ede.

Cuando vi el cartel de la conferencia, no le presté demasiado interés al título; ya se sabe, que eso es cosa de "los de marketing" y poco importa... pero esta vez iba en serio: Beyond ITIL. Beyond Control. Tenía que significar algo así como "Más allá de ITIL. Más allá del Control" y yo le di el significado de..."Hasta el infinito y más allá", pero no tardaría en darme cuenta de cuán equivocado estaba.

Cuando comencé a ver a los ponentes, vi (en realidad ya lo sabía, pero lo pude confirmar en ese momento) a Rob England entre ellos: mi apreciado IT Skeptic iba a estar en Holanda!

Pero cuando llegué allí, me encontré con que no sólo compartiría mesa con Jan y Rob... además había personajes de la talla de Ian Clayton, Paul Wilkinson o Brian Johnson (no! el cantante de AC/DC, no.. ese no!) y la preconferencia fue una fantástica tarde/noche que acabó más allá de las 12 de la noche entre cervezas, charla y crítica... mucha crítica.

Al día siguiente, una apretada agenda de conferencias (lástima, casi todas en Holandés y sin traducción, pero con un track en inglés que fue más que suficiente) en el que se fue perfilando claramente que el sentido de "Más allá de ITIL" en realidad era algo así como "Ya está bien de ITIL" y lo de "Más allá del control" en realidad era "Y nos vamos a librar del control".

Señores, el pensamiento crítico que ha hecho visible Rob England en su blog y que en realidad viene como una corriente subterránea acercándose desde hace dos décadas, ha confluido en Ede esta semana, ha marcado historia y la comunidad más avanzada del mundo en temas de Service Management ha dicho claramente que hacen falta alternativas, mejoras y nuevos puntos de vista.

El mundo está cambiando (I amar prestar aen), pronto veremos alternativas más prácticas, abiertas, colaborativas y sobre todo, no ligadas a un copyright, trademark o propiedad exclusiva.

Porque mucho de lo que era, se ha perdido...pero nadie vive que lo recuerde, aunque en el caso de ITIL autores como Brian Johnson que participaron en los primeros libros de ITIL V1 sí que recuerdan cuál era el espíritu original: la comunidad de usuarios, el cliente, la Gestión del Servicio, el cliente, la profesión y el cliente.

Programa de Dirección Estratégica de las TIC

El próximo día 16 de Abril se inicia en el IDEC-UPF (Universitat Pompeu Fabra) el Programa de Dirección Estratégica de las TIC, un programa formativo orientado a "capacitar al Director TIC para desarrollar una visión estratégica maximizando su aportación de valor al negocio"

El temario de este programa es realmente interesante:

Módulo 1: Definición de la Estrategia

Módulo 2: Implantación de la Estrategia

Módulo 3: Las Herramientas de Gestión TIC

Módulo 4: Potenciación de competencias propias del Director TIC

El año pasado, Jordi Navarro, Director del programa y antiguo cliente (de hecho, los primeros contactos que tuve con él fueron... no recuerdo bien si configurando DTC's para los terminales de radiofrecuencia o configurando terminales HP 700/96 para sus sistemas HPUX 9.XX. Debía ser el año 93 más o menos), me comentó la posibilidad de participar en esta edición del Programa.

Me encanta la formación, así que acepté inmediatamente

Total, que allí estaré; impartiendo la sesión de ITIL dentro del módulo 3 y colaborando en los contenidos de la sesión dedicada al Cuadro de Mando Integral.

Si asistes al Programa y eres lector habitual, déjate ver!!

La extremada complejidad del Catálogo de Servicios

Desde que comencé a trabajar con los conceptos de Gestión de Servicios, haciendo mis primeros pinitos en la implantación de herramientas de OpenView, siempre he usado el correo como el primer ejemplo del concepto de Servicio.

Así, el correo electrónico es más que el servidor, más que el sendmail que corre sobre él y más que las líneas de comunicaciones, sino que es el concepto agregado de todo ello.

Pero siendo como es el más extendido de todos los servicios, el más usado como ejemplo y el primero en ser documentado desde todos los puntos de vista que exige una correcta gestión de servicios (desde el SLA hasta la monitorización pasando por el soporte presencial o la capacidad), es curioso que no hayamos llegado a un acuerdo sobre cómo se debe plantar el simple y vulgar correo en un catálogo de servicios.

Y es precisamente el hecho de que no esté estandarizado (aunque sea de facto) el correo ni ningún otro de los servicios más comunes (impresión, archivos compartidos, navegación Internet, telefonía...) lo que me demuestra esta increíble complejidad que se oculta tras el (simple) concepto de Catálogo de Servicios.

Cuando miras el servicio de correo desde el punto de vista del usuario, ves un buzón con algunas funcionalidades adicionales como puede ser antivirus, antispam, quota de buzon, etc.

Cuando lo miras desde el punto de vista de la operación, ves servidores, líneas, software...

Cuando lo miras desde el punto de vista del ServiceDesk, ves las incidencias y los diferentes tipos de peticiones que se pueden realizar sobre el correo: backup y restauración del buzón, reseteo de la contraseña, movimiento del buzón, etc.

Y cuando, además modernizas el servicio, resulta que te encuentras con que a ese mismo buzón el usuario accede desde un cliente pesado por MAPI, desde un cliente ligero por OWA, desde otro sistema por IMAP4 y desde una blackberry.

¿Es el mismo servicio el correo accedido desde un cliente pesado que desde una blackberry? Quizás desde el punto de vista del usuario sea lo mismo o muy similar, pero desde el punto de vista de la Gestión de la Disponibilidad no es lo mismo medir la disponibilidad del buzón (backend) que la disponibilidad del acceso Blackberry (con sus frontends y la disponibilidad de la red GPRS).

Y así podríamos seguir encontrando toneladas de pequeñas diferencias y matices que hacen que una cosa sea distinta de la otra... Así que, o llegas a un acuerdo y dejas de buscarle las cinco patas al gato, o te has tirado meses sólo discutiendo sobre el correo y aún te faltan 30 servicios más por documentar!

¿Y todo esto por qué pasa? Pues en mi humilde opinión porque ITIL define un concepto único que es el catálogo de servicios como piedra angular de la Gestión de Servicios (evidentemente, si quieres gestionar servicios necesitas saber a qué servicios te refieres, ¿No?) cuando en realidad hay que pensar en un concepto de catálogo multidisciplinar y que permita diferentes puntos de vista, a la vez que te debe permitir canalizar el diálogo con todas las partes implicadas... y eso es extremadamente difícil de lograr.

Lo fácil es tener una lista de servicios, quizás enriquecida con algunos atributos que te permitan describir de una u otra manera estos servicios, y luego tener diferentes "ampliaciones" de estos conceptos.

Así, puedes tener lo que yo llamo "carta de servicios", que es la representación del catálogo especialmente orientada a clientes, indicando qué pueden pedir o esperar de IT; o puedes tener un catálogo interno de servicios, con la arquitectura tecnológica y los conceptos de medición para el área de operaciones/explotación; y así los diferentes "sabores" de catálogo que te permitan gestionar cada una de las facetas de los diferentes servicios.

Y entonces llegan Charlie Betz y Rob England y siembran la duda cuando ya pensabas que lo tenías claro, aquí y aquí.

Tienes opiniones al respecto? Cómo es el correo en tu catálogo de servicios? Qué haces con los diferentes canales de acceso?

Aquí podríamos estar hablando durante horas, así que no dejes de añadir tu granito de arena, porque tu catálogo ¿es un catálogo de productos, de servicios TIC, de peticiones, de servicios profesionales o de buenas intenciones?

Crónica del evento itSMF CAT del 6 de Febrero de 2008

El pasado 6 de Febrero se realizó en Barcelona el evento anual del capítulo Cataluña del itSMF. Fue una jornada interesante, con una asistencia más que respetable (sobre unas 120 personas) teniendo en cuenta el corto plazo que hubo para hacer publicidad del acto y en el que pude ver un montón de caras conocidas.

Para mi, lo más importante del evento fueron las presentaciones realizadas por los representantes locales, que presentaron su visión actual en la Gestión de Servicios. Hablaron personalidades del CTTI (Centro de Telecomunicaciones y Tecnologías de la Información), del Banco de Sabadell, de Gas Natural y de Cuatrecasas Abogados, así que estaban representados distintos sectores, además de grandes organizaciones presentes en Cataluña.

En general, me llamó la atención que se trataron de forma recurrente tres temas principales:

CATALOGO DE SERVICIOS

Todos los ponentes resaltaron la importancia del catálogo de servicios, presentando cada uno una visión diferente. Es curioso ver cómo los cuatro ponentes locales mezclaron rápidamente el concepto de Servicio TIC con el de Servicio Profesional y en seguida el concepto de Catálogo de Servicios fue derivando en el siguiente punto tratado por todos los demás:

GESTION DE LA DEMANDA

Convertir el catálogo de servicios en un catálogo de peticiones y a partir de ello, centralizar toda la demanda del usuario a través del ServiceDesk (ya sea telefónico o web-based) en base a peticiones permitidas. Además apareció en varias ocasiones el concepto de Oficina de Proyectos como canalizador de la demanda "grande" y transmisor de la estrategia corporativa hacia la estrategia TI.

GESTION DE LA EXTERNALIZACION

La presentación de Brigitte Noordegraaf, de Quint Wellington Redwood, versó sobre el tema de la externalización, pero posteriormente en la mesa redonda la gran mayoría de preguntas se focalizaron en este aspecto. Me sorprendió mucho que el modelo de outsourcing que plantea Quint no contempla la devolución del servicio, e incluso cuando le lancé esta pregunta a Brigitte simplemente contestó que no se suele dar el caso (en mi opinión es importantísimo contemplar la devolución del servicio ya sea por finalización o por cancelación del contrato, lecciones aprendidas de los concursos de la Generalitat)

Hubo varias perlas, frases lanzadas al aire (para el que las quisiera coger), algunas de las cuales les paso a detallar:

Jordi Bosch: (Generalitat de Catalunya)

La capacidad de compra de la Administración Pública hace de regulador en épocas de crisis.

[...]

Es misión de ustedes, los asistentes a este tipo de evento, realizar una labor de socialización de ITIL de tal manera que vayan filtrando estos conceptos a las capas más altas en la dirección  de las empresas

Ricard Pons: (IBM)

No podemos estocar servicios, así que tenemos que proporcionarlos en el momento en que nos los pidan. Lo único que podemos hacer es influenciar en la demanda.

Ivor McFarlane: (IBM)

Sharon Taylor nos pidió que relacionásemos el contenido de los libros de la V3 con la fotografía que hay en la portada. ¿Ven lo que hay en la portada del Service Transition? Es una foto en Rayos X de unas vainas de guisante. ¿Para qué sirve? Obviamente, para saber si dentro hay guisantes o no. Como pueden ver, aquí falta un guisante (justo debajo de la palabra "Transition").

¿Me podrían decir si esta vaina es aceptable?

Obviamente, no pueden si no saben para qué se va a usar. Si es para hacer unos guisantes salteados, da absolutamente igual: abriremos las vainas y sacaremos los guisantes para saltearlos, pero si es para hacer un "Vainuá a le menoriette" (cuando queremos que la comida parezca buena, le ponemos nombres en francés) para la Reina, le pondremos en un plato las vainas abiertas y cuando el maitre la lleve a la mesa, su majestad pensará  "oh! alguien me ha robado un guisante, el guisante de la Reina!)"

La clave es saber para qué se va a usar el servicio.

David Wheeldon: (HP)

Normalmente, las organizaciones querrán invertir lo mínimo posible en los entornos en producción y desviar el máximo de inversión hacia el desarrollo de nuevos proyectos/servicios ya que esto es lo que produce nuevas funcionalidades que permiten mejoras en el negocio. Las inversiones en los entornos en producción son poco visibles.

Brigitte Noordegraaf: (Quint)

El 78% de los contratos de outsourcing se realizan con el principal objetivo de reducir costes. Si lo que quieres es reducir costes, ¡lo primero es saber cuánto te cuesta!

[...]

El primer mandamiento es implementar un marco de gobierno efectivo tanto para el proyecto de externalización como para el seguimiento del contrato.

Xavier Virgili: (Banc de Sabadell)

Con el paso del tiempo, no hemos aprendido "negocio" del usuario; le hemos enseñado informática al usuario, y eso ahora se nos ha dado la vuelta.

[...]

De repente nos dimos cuenta de la criticidad relativa del proceso de negocio frente al servicio TIC, y descubrimos que si no iba el correo, el banco no se hundía.

[...]

Antes de poder establecer SLA's se requiere una cultura del indicador en toda la compañía. Establecer SLA's sólo para las TIC no tiene sentido (en este momento, el cliente escéptico del que hablaba en un post anterior me miró y se echó a reír)

Francesc Muñoz: (Cuatrecasas Abogados)

El problema de plantearnos SLA's internos está en captar indicadores de negocio que se puedan reflejar en los SLA's.

Josep Bastida: (Gas Natural)

La clave para la Gestión de la Demanda está en establecer correctamente las expectativas del cliente y exigir siempre un Business Case o estudio de ROI del cliente para aceptar la demanda.

[... ]

El Catálogo de Servicios debe ir ligado a un sistema de Gestión de Peticiones. No puedes pedir nada que no esté en el catálogo.

En conclusión, el evento fue interesante, pero había que leer entre líneas. El networking (como siempre) estuvo a la orden del día y la organización, excelente.

Espero que el año que viene los ponentes sean de un nivel más operativo para poder ver la realidad "en acción" y que haya mucho más cliente que proveedor en el público. Esos son mis deseos para el evento itSMF 2009 (y espero poder trabajar para que se conviertan en realidad)

Libro: Service Management, strategies that work

Poco antes de Navidad, un amigo me comentó de pasada que se estaba leyendo un libro, que se lo había comprado pensando en encontrar material sobre Gestión de Servicios TIC y que le había sorprendido muchísimo encontrarse con una excelente documentación sobre IT Governance.

Coincidió por esas fechas que unos pocos de los lectores de este blog se decidieron a comprar algún que otro libro en la Biblioteca GobTIC, así que me cayó por Navidad un cheque-regalo de Amazon para gastar y pensé que estaría bien dedicarlo a este libro.

¡Qué grata sorpresa!

Aun no me lo he terminado de leer, pero tenía ganas de comentarlo con ustedes porque realmente da gusto leerlo. Sólo la introducción ya da una visión de IT Governance fresca y agradable de leer (qué lejos de ese estilo serio y gris de las publicaciones de ISACA, que parecen sacadas de una notaría), unas definiciones de conceptos como Servicio que he sentido realmente próximas y la diferenciación entre Servicios IT y Servicios profesionales que llevo aplicando desde los primeros proyectos realmente importantes allá por el año 99.

En realidad es un conjunto de whitepapers, de los cuales alguno como el de definición de un modelo de costes para los servicios TIC llevan tiempo circulando por la red (todos los autores son de Pink Elephant, así que allí podremos encontrar algunos de ellos).

El índice de contenidos es el siguiente:

• Introducción: ¿Alineación con el Negocio, o Integración con el Negocio?
• IT Governance al descubierto
• El proveedor externo de servicios gestionados
• Implementación de Procesos
• Definición, modelado y contabilidad de costes para servicios TI
• La CMDB Federada
• Desarrollando un marco de trabajo de medición basado en Calidad
• La Teoría de las Limitaciones y la mejora continua del servicio

Es una lectura que recomiendo fervientemente: al menos a mi, personalmente, ha conseguido algo que hacía tiempo que no me pasaba con literatura profesional: la Magia ha vuelto a recorrer mi cuerpo.

Título: Service Management Strategies That Work-guidance for Executives

Autores: Gary Case, Troy DuMoulin, George Spalding, Anil C. Dissanayake.

ISBN: 978-9087530488

Si quieres echarle un ojo, en GoogleBooks  puedes hacerlo e incluso leer (y disfrutar) del prefacio y la introducción.

¿Ya lo has hecho? ¿Qué Opinas?

Un poquito más de alimento para el ego

El tan famoso IT Skeptic ha publicado recientemente sus premios y nominaciones especiales (en formato Skeptic, cómo no!) para el año 2007. Es un post que no tiene desperdicio y que me ha hecho reir un rato.

Pero cuando he llegado al apartado especial donde otorgaba el Premio Stalin a la revisión de la historia a la OCG por eliminar cautelosa y silenciosamente el apartado 1.1.1 de los libros de ITIL V2 me ha salido una amplia sonrisa de satisfacción, ya que se otorga este premio especialmente gracias al post "El misterio del 1.1.1 Deleted" publicado originalmente por aquí y posteriormente comentado en el website del IT Skeptic.

Ahh! Estas cosillas son las que dan ganas de escribir.

Definiendo Servicios: mejor desde la ignorancia

LLega un momento en cualquier implantación/definición de procesos de Gestión de Servicios en el que, axiomáticamente, hay que definir los servicios. Hay compañias que empiezan la casa construyendo un catálogo de servicios bien detallado, hay otras que comienzan definiendo procesos y herramientas y al ir a pensar en los datos necesarios para la herramienta aparece el campo "Servicio" que hay que rellenar con algo, así que al menos hay que obtener la lista de servicios.

Sea como sea, cuando llega el momento de pensar en la lista de servicios invariablemente aparece la necesidad de definir el concepto servicio después vienen las discusiones al respecto de cuáles son los servicios que prestamos al resto de la organización (el negocio como lo llamamos habitualmente).

Bueno, vamos a empezar por una definición de servicio que estoy utilizando últimamente y que me cuadra bastante:

SERVICIO TIC:

Uno o más Sistemas TIC [...] proporcionados por el Departamento de IT y que facilitan los procesos de negocio de la Organización. Un Servicio TIC debe ser percibido por el cliente como una entidad coherente o como un producto consumible.

Lo que más me gusta de esta definición es aquello de debe ser percibido como una entidad coherente o como un producto consumible. Y aquí es donde viene la segunda parte del título del artículo: mejor desde la ignorancia.  Esa percepción a la que nos referimos, es la percepción del usuario, no la nuestra desde dentro de IT.

Escribo este post en un avión, volando desde Bruselas a Barcelona y precisamente lo que me ha inspirado el sentido de ignorancia es que yo no tengo ni idea de qué es lo que hace falta para conseguir que el avión me lleve desde un sitio a otro, los mecanismos, las capacidades, la atención del personal de cabina, etc... yo tengo claramente la percepción de vuelo y veo claramente que hay diferencias entre volar en una compañia Low-Cost o volar en Iberia Business Class... veo los diferentes niveles de servicio, pero no sé (ni quiero saber) las tripas que componen este servicio.

Cuando llega el momento de definir la lista de servicios que ofrece IT al negocio, mejor hacerlo desde la ignorancia (en el buen sentido de la palabra): vayámonos al negocio y preguntémosle qué es lo que ellos perciben como un producto consumible, qué es lo que ellos usan/piden/consumen de IT y tendremos gran cantidad del trabajo hecho y de discusiones internas eliminadas; porque nosotros, como IT ,conocemos las tripas del servicio y nos plantearemos dudas complejas sobre la estructura de servicios.

Un ejemplo simple: un servicio puede ser "el teléfono móvil". Si lo veo como usuario, es un aparato que sirve para llamar por teléfono desde cualquier punto del pais, con posibles ampliaciones al extrangero. Si lo veo como un entendido en la materia puede ser que decida diferenciar entre el servicio "teléfono móvil 3G", "teléfono móvil UMTS", "teléfono móvil satelital", porque, desde el punto de vista de IT son cosas diferentes.

Pero el usuario ni ve ni comprende estas diferencias... sólo quiere llamar por teléfono. (o sólo quiere volar... da igual el resto)

Se positivamente que este post me va a traer problemas, porque yo mismo he defendido en más de una vez que el correo POP es diferente servicio que el correo WEB o que el correo BlackBerry basándome en que a)los parámetros de medición son diferentes, b)los niveles de servicio son diferentes c)las infraestructuras/tecnologías que hay debajo son diferentes.

Pero en el fondo, el usuario sólo quiere leer el correo... lo que varía es cómo lo lee.

No pretendo sentar cátedra en este tema... sólo reflexiono en voz alta porque ninguna de las dos aproximaciones me da respuesta a todas las preguntas. Pero... desde la ignorancia las cosas se ven de una manera mucho más simple.

Cómo aprobar el ITIL Service Manager (III)

La etapa de estudio (bis)

En el artículo anterior hablamos de la etapa de estudio, pero entiendo que los consejos que daba son quizás demasiado genéricos. En este post voy a tratar de aterrizar un poco más al mundo terrenal para ver algunos aspectos prácticos relacionados con el tipo de preguntas que verás en el examen.

Para empezar, hay que tener en cuenta el caso de estudio. Durante los cursos vimos un par de empresas tipo (Pecunia y Graphical Machinery) como casos de estudio para los ejercicios a realizar durante las clases; luego, al final del segundo curso te darán el caso de estudio en el que se basarán algunas (bastantes) preguntas del examen. En mi caso fue una empresa llamada CTI, Compañía de Transporte Internacional, S.L., una empresa de transporte de mercancías y pasajeros por toda Europa.

Verás que en el caso de estudio aparecen descripciones organizativas de la compañía (departamentos, estructura de Dirección, etc), descripciones funcionales del área TI y algunas (pocas) descripciones técnicas de los sistemas que soportan los procesos de negocio de la empresa. Lo que más importa son las descripciones de los departamentos (quiénes son tus clientes), las descripciones de los procesos de negocio y las políticas de la compañía. Este apartado de políticas viene a ser un mini resumen de los puntos más importantes del Plan Estratégico de la empresa estudiada y, por lo tanto, todo lo que puedas justificar en el examen gracias a estas políticas mejor... estarás "alineando las TIC con el Negocio".

De esta manera, en CTI había, por ejemplo, un apartado de las políticas que decía:

Para poder obtener ventajas de estas oportunidades y también para poder reducir el problema en los niveles de utilización y tener entregas justo a tiempo (just-in-time), el Departamento de Estrategia y Políticas cree que la forma adecuada de avanzar es con el uso de las Tecnologías de la Información para cambiar los procesos de gestión de la empresa.

si te piden justificar la necesidad del proceso de Gestión de la Disponibilidad y tu utilizas, entre otros argumentos, el hecho de que la estrategia corporativa pasa por entregas Just-in-time, quedarás como un señor y te llevarás un par de puntillos.

...y para llevarte toda una buena colección de puntillos, nada mejor que entender claramente el proceso de corrección. En el libro que te han dado durante el curso, aparece al final un apartado que se llama "marking guidelines", estas guías de puntuación le indican al corrector cómo se debe puntuar y te indican a tí cómo debes escribir el examen para ganar el máximo de puntos.

Veamos un par de ejemplos: en una de las preguntas de Service Support te preguntan

¿Qué medidas puede adoptar una compañía para asegurar que la CMDB está actualizada? (10 puntos)

Aquí podríamos escribir un libro completo, pero se nos irían las 3 horas del exámen en una pregunta de sólo 10 puntos (sobre 100), así que veamos lo que dicen las "marking guidelines"

Se deberían incluir al menos las siguientes medidas:

• Gestión de Cambios: todos los CIs deben ser sometidos al control de la Gestión de Cambios
• Comprobaciones operativas: como aquellas realizadas por el personal de HelpDesk cuando se reporta un incidente (lo que yo llamo "Auditoría Contínua")
• Comprobaciones procedimentadas: comprobaciones específicas que se han introducido en los procedimientos de tal forma que cualquier modificacion queda registrada.
• Auditorías Regulares
• Uso de herramientas de descubrimiento que permitan detectar cualquier cambio no autorizado tan pronto como se realice.
• Automatización de algunas actividades.

Se sugiere otorgar 1,5 puntos por cada uno de estos puntos si han sido correctamente explicados o por otros puntos adicionales si son correctos y están bien explicados hasta un máximo de 10.

Ahora ya vemos cómo va la cosa: si te piden una lista o un conjunto de ideas, te van a dar algo de puntuación por cada elemento que pongas, así que una respuesta incompleta aporta más que una no-respuesta.

Vamos a ver otro ejemplo, en el que no sólo cuenta el contenido sino también el continente (versión resumida):

Eres el IT Service Manager de una organización que se está planteando el cambio de mainframe a cliente/servidor. Prepara un informe para el Director de IT analizando los efectos de este cambio en tus áreas de responsabilidad, poniendo un énfasis especial al apartado de costes, beneficios y problemas que puedan generarse por esta migración. (20 puntos)

Ahora también podríamos escribir otro libro, pero veamos en qué se fijan los correctores:

3 puntos por un informe correcto, bien estructurado y bien escrito, con una estructura de Sumario Ejecutivo y contenido principal dividido tanto en

• Beneficios Genéricos
• Costes
• Problemas

o bien en apreciaciones específicas para cada uno de los procesos.

Adicionalmente, se espera que se enfoquen al menos 8 impactos en el área de costes, 7 impactos en el área de problemas y 5 impactos en el área de beneficios, otorgándose un punto por cada uno de ellos no superando los 20 puntos si se han otorgado los 3 por "estilo".

Eso significa que te puedes llevar 1 punto por cada idea que se te ocurra en el momento del examen, y aunque no estén todas, siempre podrás llevarte 3 puntos por el estilo adecuado en el informe.

Algunas preguntas que yo recuerdo del examen mio:

1. Relación entre 4 subactividades de la Gestión del Cambio y la Gestión de los Proyectos: Esta me dió mucha rabia.. me acordaba perfectamente del dibujo en el libro del Service Support, pero no me lo sabía.
2. Indicadores en la Gestión del Cambio que sirvan para evaluar a un proveedor externo: fantástica, gracias a mi experiencia profesional... no la encontrarás en los libros.
3. Escribir un memorando con el rol, cuatro responsabilidades y dos retos para el Gestor de ITSCM: esta es de las difíciles... larga, en formato especial (memorando... es como escribir un mail, pero en papel) y había que saberse los roles bien e inventarse los retos a partir de los problemas que te vas a encontrar en implantación (por ejemplo).

En general, veremos que el examen de Service Support está muy basado en el libro y se te pedirán cosas "de la biblia", pero el examen Service Delivery es más difícil y más abstracto. Recuerdo haber comentado a la salida del segundo examen algo así como

El primer examen fue relativamente simple, muy basado en el libro azul. Mucho de actividades y metricas, un memo y poca cosa sobre el caso de estudio.
El segundo fue mucho más difícil. Casi nada de actividades y preguntas poco concretas (aporte cuatro argumentos para... ). Yo creo que para aprobar el segundo hay que prepararse bien todo lo que son "Beneficios", "Problemas" y "Costes" de cada uno de los procesos.

Cómo aprobar el ITIL Service Manager (II)

Una vez finalizados los cursos de Service Manager, te toca estudiar. Tal y decía un anónimo comentarista en el post anterior, Exin aconseja cerca de 320 horas de estudio, contando con las 80 horas de curso presencial, pero ese tiempo es simplemente una estimación que va a variar sensiblemente con tu capacidad de aprendizaje y con la experiencia que tengas previamente.

La etapa de Estudios

Dependiendo de la planificación que haya de cursos y exámenes, tendrás más o menos tiempo para estudiar, pero normalmente debería oscilar entre las 3 y las 6 semanas. Con esto me refiero al tiempo que transcurre desde que terminas el segundo curso y hay una convocatoria a examen. Durante ese tiempo tendrás que estudiar bastante y preparar cada uno de los procesos, a la vez que sigues trabajando y tratando de llevar una vida normal... así que vas a dormir poco, posiblemente.

Los principales consejos que te puedo dar durante este tiempo:

1. Estás estudiando para el ITIL Service Manager: no lo olvides. El examinador no querrá saber lo bueno que eres en Six Sigma ni CMMI, sino lo bueno que eres en ITIL. Aquí tu experiencia cuenta, pero sólo si sirve para apoyar lo que dicen los libros. Cuando estaba estudiando encontré decenas de cosas que no me gustaban en los libros, que ya están obsoletas, que son mejores en COBIT o cualquier otro estándard... en el momento del estudio y del examen eso no interesa. Lo que dice "la biblia" va a misa (al menos durante las 6 horas de exámenes) así que estudiate la biblia y no te desvies de sus pasos.
2. Estudia de memoria solo aquello que sea necesario: No te vas a poder aprender de memoria los dos libros de Support y Delivery, así que guarda tu memoria sólo para aquello que realmente sea importante. Sobre todo en el examen de Service Support, te harán preguntas del tipo "Describir las actividades del proceso XXX". Aqui seguramente te darán más puntos por decirlas todas y, si además las dices en orden, un par de puntillos extra.
3. Mnemotecnia: Yo tengo muy mala memoria, así que tuve que usar trucos de mnemotecnia para recordar esas actividades en orden. La más famosa de todas es la frase que resume las actividades de la Gestión de Configuraciones: "Perhaps, I Can See Vampires" (Plan, Identify, Control, Status accounting, Verification & audit). Pues como esa, hay varias y mejor aún si te las inventas tu, porque seguro que no se te olvidan.
4. Hacer Esquemas: A mi personalmente me ayuda mucho hacer esquemas y resúmenes. Es decir, escribir lo que quiero aprender. Durante el curso, mucha gente se intercambió esquemas, "fact sheets", "mind maps" y demás documentación bajada de Internet o obtenida en las intranets de sus compañias. Yo me las quedé, por si me hiciera falta consultar algo, pero en realidad lo que hice para estudiar fue hacerme mis propias "fact sheets" cada vez (y me las hice 2 o 3 veces por proceso). El contenido de cada esquema debe ser:
   • Definiciones más importantes del proceso
   • Actividades y SubActividades
   • Entradas y Salidas
   • Indicadores
   • Relaciones con otros procesos
   • Job Descriptions (sobre todo para Delivery y para el Change Manager)
5. El caso de Estudio: el caso de estudio es un documento que te entregarán al final del segundo curso y que es una descripción de una compañia ficticia sobre la que versará todo el examen. Es decir, muchas de las preguntas del examen serán al respecto de las Gestión de Servicios TIC en la compañía XXX . No es necesario que te lo sepas "de pe a pa" porque te lo darán como parte del enunciado del examen, pero debes haberlo leido y analizado un par de veces para, sobre todo, tener agilidad en las respuestas.
6. Practica la escritura: No estamos acostumbrados a escribir a boli, así que debes entrenar tus muñecas para resistir 3 horas seguidas escribiendo.
7. Entiende lo que estudias: llegado el momento del examen, el conocimiento debe fluir solo. No debes "recordar la respuesta" sino que debes "saber la respuesta"... recordar requiere un tiempo para rescatar de la memoria. Saber es inmediato, así que debes saber las cosas y no recordarlas.
8. Utiliza los exámenes de ejemplo: Exin vende un libreto con dos examenes de ejemplo (creo recordar). Cómpralo (o si estudias en grupo, comprenlo entre todos) y haz los examenes de pruebas, así verás cómo son el tipo de preguntas que te van a hacer.

Cómo aprobar el ITIL Service Manager (I)

Cuando estudiaba para pasar el examen del ITIL Service Manager (Managers Certificate in IT Service Management) pensé en escribir uno o varios artículos explicando mis ideas al respecto de cómo se puede obtener esta difícil certificación, pero mi sentido de la prudencia me dictó esperar.. ¿Cómo escribir sobre la técnica para aprobar si aún no había hecho el examen y, sobre todo, si aún no sabía si había aprobado o no?

Ayer me llamaron por teléfono para darme la noticia de que había aprobado los dos exámenes, y hoy me llegó el email en el que me decían la nota: ahora sí que puedo explicar cómo aprobé los dos exámenes de Service Support y Service Delivery a la primera.

Prerrequisitos:

Los conocimientos requeridos para poder superar los exámenes son:

1. Estudios de grado medio o superior, o profesionales con una gran experiencia práctica o autodidactas
2. El certificado de fundamentos de gestión de servicios (basado en ITIL®) (ITIL Foundations)
3. Buena capacidad de comunicación oral y escrita
4. Aptitudes para la oratoria, para la elaboración de presentaciones, para la preparación de reuniones y el trabajo en equipo
5. Al menos dos años de experiencia profesional como gestor o consultor en el campo de la gestión de TI

Oficialmente, los requisitos para poder asistir al examen son los siguientes:

1. Análisis de los procesos de la gestión de servicios TI dentro de una organización
2. Diseño de la estructura de organización
3. Descripción de los procesos de la gestión de servicios TI
4. Evaluación y auditoria de los procesos de gestión de servicios TI
5. Implementación de los procesos de cambio
6. Redacción de reportes e informes
7. Aptitudes de gestión

Es obligatoria la asistencia al curso de preparación. Este curso son 80 horas de formación en la que se tratarán uno por uno los diferentes procesos del núcleo de ITIL, en Service Support y Service Delivery.

Durante el Curso:

Son 80 horas de formación (intensas, en 2 semanas de trabajo habitualmente) en las que habrá una gran componente práctica y se realizarán muchos ejercicios, tanto en grupo como individuales. Los profesores realizarán una evaluación continua de cada uno de los alumnos donde analizarán aspectos como los puntos 3 y 4 de los conocimientos necesarios y tu capacidad en el punto 7 de los requerimientos (Aptitudes de Gestión).

Personalmente, creo que es en esta parte donde más se aprende en el curso: si traes el Foundations bien aprendido y ese par de años de experiencia que te piden, de los libros Service Support y Service Delivery poca cosa te van a enseñar, pero... siempre se puede aprender algo de técnicas de reuniones, gestión de proyectos, presentaciones en publico, desarrollo oral y escrito, etc.

Si, además, tienes la suerte de que el curso sea multi-empresa, tendrás la oportunidad de trabajar en equipo con personas de otras organizaciones y aprenderás mucho de su estilo, técnicas, maneras de hacer, etc.

Los consejos a seguir en esta etapa:

1. Aprovecha el tiempo: Tienes 80 horas para pensar únicamente en ITIL, no las desperdicies.
2. Sácale el jugo a tus compañeros: Es una ocasión única para compartir e intercambiar experiencias, sensaciones, opiniones, tarjetas de visita,etc.
3. Aprende a escribir: Cada examen dura 3 horas. En esas 3 horas tienes que desarrollar muchas ideas, así que debes acostumbrarte a sintetizar, no soltar unos rollos impresionantes, acotar las ideas y expresar lo más importante. Utiliza las prácticas del curso para aprender a hacer esto.
4. Estudia todo el tiempo que puedas: Durante esas semanas de curso  estarás inmerso en un ambiente en el que sólo se hablará de ITIL... pero tu debes aprovechar todo el tiempo posible para estudiar: 10 días de curso, 10 procesos: eso hace que te puedas preparar cada día el proceso que te van a explicar al día siguiente. ¿Puedes ir al centro de estudios en transporte público? Pues esa media horita en metro, tren o guagua son esenciales para preparar el tema del día siguiente.
5. ¿Tienes Pareja? ¡Avísale de dónde te metes! Las dos semanas de curso son intensas, como te he dicho antes: no sólo tendrás 80 horas de clases, sino que además te tienes que preparar la clase del día siguiente y hacer ejercicios puntuables que te pondrán los profesores "como deberes", así que en casa te van a ver poco el pelo durante este tiempo... avisales y pideles que te ayuden a concentrarte.

Bueno, hasta aquí esta primera parte. Seguiremos más adelante con consejos sobre los momentos de estudio posteriores al curso y sobre las técnicas a utilizar durante el examen.

Mejora Continua

Todo pasa y todo queda,
pero lo nuestro es pasar,
pasar haciendo caminos,
caminos sobre el mar.

Ante la entrada de ITIL V3, se abrió en el seno del itSMF España un antiguo debate (ver aquí o aquí ) sobre la terminología a utilizar de forma oficial y unificada, tanto en los libros oficiales de ITIL como en los exámenes oficiales (de EXIN) y en la norma española UNE-ISO/IEC 20000.

Después de mucho diálogo y arduas discusiones, después de evaluar los pros y los contras, después de evaluar el impacto en el sector, en el mercado, en los estándares, en las personas... después de un ceñudo, largo y dificil debate, la Junta de Gobierno del itSMF España ha decidido por votación y con la participación de todos sus comités que se realizarán cambios en el diccionario oficial para ajustarlo a la realidad social que todos vivimos en el día a día.

Así, la Junta de Gobierno ha decidido

1. Respetar el nombre de los procesos de V2 que coinciden con la V3, y
cambiar sólo tres de ellos debido a que el uso habitual en las empresas no
coincidía con el término estandarizado.

Los términos de V2 que se CAMBIAN son:
Gestión del Incidente se cambia por “Gestión de Incidencias”
Gestión del Problema se cambia por “Gestión de Problemas”
Gestión del Cambio se cambia por “Gestión de Cambios”

Los términos de V2 que se MANTIENEN son:
Centro de Servicio al Usuario (SD)
Gestión de la Comfiguración
Gestión de la Entrega (V2)
(como en V3 cambia el nombre es "Release and Deployment Management" y el
alcance de release es otro distinto, se acuerda el nombre del porceso a “
Gestión de la Versión y del Despliegue”
Gestión del Nivel de Servicio
Gestión de la Capacidad
Gestión de la Disponibilidad
Gestion de la Continuidad del Servicio de TI
Gestión Financiera (v2) en V3 deja de ser proceso como tal, pero existe el
término
Gestión de la Seguridad de la Información
Gestión de Suministradores
Gestión de la Aplicación (actividad)
Gestión de Aplicaciones (función)
Gestión de Redes
Gestión Técnica
Operación de TI
Informes del Servicio

Además para el resto de la terminología se va a abrir al público un periodo
de sugerencias y debate en la web de itSMF.es  sobre el excel realizado por
el GT de Terminología.

Y por lo tanto se abre también un debate para la discusión y posterior aprobación del diccionario de términos ligados a ITIL V3. Este debate se realizará a través del foro del itSMF España y se puede consultar aquí.

Caminante, son tus huellas
el camino y nada más;
caminante, no hay camino,
se hace camino al andar.