Búsqueda


Mostrando entradas con la etiqueta Nivel Medio. Mostrar todas las entradas
Mostrando entradas con la etiqueta Nivel Medio. Mostrar todas las entradas

20 de septiembre de 2018

Scrum en organizaciones Lean: más madera para el Product Owner!

Dentro de mi viaje particular al Nirvana del Flow, esta semana he tenido un momento importante. Facilitando un evento Kaizen para el equipo de almacén de un cliente, intentando corregir unos “problemillas” que había con unos bultos que se traspapelaban por el camino hemos seguido todos los pasos de rigor: plantear el problema, hacer un VSM, identificar oportunidades de mejora, análisis de causas etc etc.

Lo de siempre en el mundo Lean, siempre tan interesante gracias a la participación de todos. Aparte de todo lo que aprendí del mundo de los almacenes y la logística, que es impresionante, pude vivir (otra vez!) la excitación que te genera ver que el equipo Kaizen no se enfoca en las guerras personales y empieza a trabajar de manera creativa en comprender el problema y plantear contramedidas, siempre de manera transversal y cross-departamental. ¡Es alucinante!

Pero por el camino empecé a notar que la cosa se podía complicar. En seguida aparecieron propuestas de pequeños cambios en el proceso, pequeñas modificaciones en la operativa (con el consiguiente problema de Gestión del Cambio con el personal y sus diferentes turnos) y el nacimiento de nuevas necesidades de información, controles y sistemas de información.

¿Quien dijo que los procesos industriales son más fáciles de gestionar porque están estandarizados?

Este proceso que estábamos analizando es fácil de comprender, pero la cantidad de casuísticas que tiene es impresionante y ahí aparecía una de las lecciones importantes del Kaizen… recuerdas? “Kaizen … yo me flagelo y hago un sacrificio por el bien común”.

Para conseguir un proceso más homogéneo y sin tantas excepciones y casos especiales todos deben hacer pequeñas concesiones para conseguir optimizar el proceso de forma global en lugar de perseguir las optimizaciones locales e independientes para cada uno de los interesados. En este caso, el equipo de almacén se ve afectado por los requisitos, limitaciones o presiones impuestas en el proceso aguas arriba (por ejemplo, presiones en la planificación establecidas dos o tres eslabones antes de llegar a la preparacion de un pallet que debe ser expedido).

Y ahora vamos a pensar un poco más allá; este post no pretendía ser una explicación sobre una sesión de Kaizen. ¿Te imaginas una empresa en la que los diferentes equipos hacen sesiones de Kaizen para ir mejorando poco a poco los procesos de negocio? En el almacén, en compras, en logísticas, en pedidos… en todas partes gente haciendo pequeñas modificaciones y pequeñas mejoras sobre los procesos, haciendo que la empresa lentamente vaya evolucionando a mejores cotas de calidad, eficiencia y valor para el cliente. ¿Mola, no?

¿Y dónde están los informáticos?

¡Esa es la reflexión clave! Si los procesos evolucionan continuamente, informática debe ser capaz de soportar esas modificaciones de forma continua, debe facilitar la adaptación permanente de los sistemas de información a las necesidades y a los cambios provocados por la mejora contínua del negocio.

Es lo que hacemos siempre, no? Desde luego, no me cabe la menor duda de que siempre estamos intentando mantener un ritmo decente de modificaciones/evoluciones a nuestros sistemas de información, pero en un entorno Lean donde la evolución y el cambio son constantes el nivel de exigencia es mucho mayor.

¿Y cómo respondemos en informática a esta situación de elevada demanda de pequeños cambios sobre los mismos sistemas de información?

Con equipos especializados en esos sistemas de información, focalizados en el proceso, orientados a la ejecución de tareas que finalizan con un incremento de producto totalmente funcional.. respondemos a las células de producción con células de producción. Los equipos ágiles son especialmente necesarios en estos entornos donde no dar respuesta incremental a estas demandas significa frenar la mejora de los procesos de negocio.

Por eso es tan y tan importante provocar la transformación ágil en los entornos Lean para hacer que flujo, valor y calidad vayan de la mano en todos los sentidos. Y cuando tengas en marcha equipos ágiles, si usas Scrum por favor, asegúrate de que al menos el Product Owner asiste a las sesiones Kaizen de su cliente.

Ni te imaginas el aprendizaje y la cantidad de información y de ideas enriquecedoras que el equipo de desarrollo se va a llevar de esas sesiones: es ver a tus usuarios tratando de resolver sus problemas utilizando tus herramientas.


Postdata: en este evento Kaizen que estoy facilitando está presente la Product Owner y varias personas del equipo de desarrollo… está siendo una experiencia super enriquecedora para todos!

2 de agosto de 2017

No es el problema. Eres tú frente al problema.

La primera vez que oí hablar sobre el modelo Cynefin fue allá por el año 2012 cuando estaba colaborando con Rob England en la traducción del libro Gestión Esencial de Servicios al castellano. En aquel momento me pareció un framework muy interesante para clasificar los problemas y cómo nos enfrentamos a ellos; luego Rob lo utilizó en su libro Plus! Standard+Case y en el congreso TFT13 yo le dí una vuelta más tratando de enlazar los conceptos de S+C, Cynefin y Minería de Procesos.

Pero luego vino el esquema de certificación de la Lean IT Association y la certificación LITA Kaizen. Cuando me preparaba, volvió a aparecer el modelo de Cynefin y esta vez venía con fuerza, como parte central del proceso de resolución de problemas que plantea la LITA combinando Kaizen con Six Sigma (DMAIC) y Cynefin.


Fue mientras daba una clase de Kaizen que me vino la iluminación; uno de esos momentos A-HA! que sólo puede tener el profesor cuando por el simple hecho de poner las cosas en orden en su cabeza para poderlas explicar, éstas encajan de una manera especial y plop! se hace la luz.

El modelo Cynefin ve los problemas como un cúmulo de causas y efectos; aquellos en los que la relación causa - efecto es clara, los entiende como “Simples”, mientras que en aquellos en que la relación causa - causa - causa/efecto intermedio - causa - efecto es intrincada, con multiples ramificaciones y multitud de causas contribuyendo a la aparición de los efectos los clasifica como “Complejos” y aquellos en los que las relaciones entre los eventos no son permisibles los clasifica como “Caoticos”.

Las relaciones causa-efecto con diferentes niveles de complejidad existen; el problema es que tú no eres capaz de percibirlas o de comprenderlas.

Pero, lo caótico no es el problema. Las relaciones causa-efecto con diferentes niveles de complejidad existen; el problema es que tú no eres capaz de percibirlas. Sin embargo si eres capaz de aprender nuevas ideas, si eres capaz de cambiar la perspectiva o el espectro en el que te mueves (en la vista, por ejemplo, cambiar a espectro infrarojo te permite ver las cosas desde otro punto de vista; en matemáticas, pasar de una serie temporal a un histograma te permite comprender otras facetas del problema analizado; en Telecos, Fourier cambió para siempre la forma de entender las ondas), si eres capaz de pensar de una manera diferente es cuando empujas el problema hacia niveles Cynefin de menor complejidad.

Aquí es justo cuando me viene a la cabeza ese momento en que Neo comprende.

Cómo clasificas el problema dice más de ti que del problema en sí.

Cómo clasificas el problema dice más de ti que del problema en sí. Y esta es una de las razones por las que utilizamos Kaizen para enfrentarnos a los problemas que nos parecen complejos o complicados: utilizamos un equipo para atacar el problema; un equipo multidisciplinar que, gracias a las diferentes perspectivas, experiencias y formas de vivir y de entender el problema hará que el grupo entero gane un nuevo nivel de conocimiento al respecto del problema y sus relaciones con los factores que contribuyen a su aparición. Ese es uno de los motivos por los que, casi sin darnos cuenta, los equipos multidisciplinares y la diversidad hacen empresas más eficientes: los problemas parecen menos cuando los enfrentas en buena compañía.

PS:: Este post viene provocado como reflexión ante una pregunta de Javier Garzás en linkedIn… como siempre, un placer! :-)

29 de abril de 2016

¿Transformación Digital? No sin DevOps!!

Se me repite la ocasión en que vuelvo a casa despues de un curso de DevOps Foundations. Probablemente disponer de tres horas de tranquilidad después de tanta actividad hace que me aparezcan algunas ideas y me den ganas de escribir.

Una de las slides que presento en la versión para managers de este curso está sacada del documento State of DevOps Report 2015, publicado por Puppet Enterprise y que representa un informe sobre el estado de la cuestión que han venido publicando desde 2013 y que se ha ganado el respeto de la comunidad.

La primera vez que vi esta gráfica se me pusieron los pelos de punta y creo que es de una importancia tan grande que es necesario dedicarle un post, una noticia en el periódico y hasta un libro si fuera necesario con tal de hacer entender a todos los directivos del pais lo que significa.

Vamos a ir por partes: en el eje vertical tenemos tenemos la frecuencia de despliegues en la organización., pero atención, representada en una escala logarítmica donde 1 significa un despliegue al día… pero es que 2 significan 10 despliegues al día y 3 significan 100 despliegues al día; no nos dejemos engañar por la inocencia de esa gráfica.

En el eje horizontal tenemos, en escala también logarítmica, el tamaño de los equipos de desarrollo. Asi que me he permitido el lujo de calcular “a ojo” los valores de la curva, meterlos en un excel y hacer una gráfica parecida pero con escala lineal, para no suavizar el impacto del puñetazo que nos dan estos datos


¿Y qué significa esto? Pues básicamente que

a) Los “low performers” (aquellos que con sus prácticas actuales no llegan a más de 100 desarrolladores y que aún así están haciendo como mucho tres o cuatros despliegues a la semana.

b) El rendimiento de los “low performers” cae rápidamente cuando crecen en número de desarrolladores. Esto es típico de las aproximaciones tradicionales: al añadir más personal, crece la desorganización y el waste y por lo tanto la eficiencia cae en picado. En la siguiente gráfica he quitado a los high performers para poder percibir esta situación:


c) Con respecto a los “Mid Performers”, podemos ver que soportan relativamente bien la incorporación de cada vez más personal y lentamente aumentan el número de despliegues al día. Fijémosnos en que esto significa, desde el punto de vista del negocio, que podemos llegar a doblar el número de desarrolladores (e incurrir en costes mucho más elevados, ya que el aumento de costes no es lineal al numero de personas) y aún así no llegan al despliegue diario (en el fondo, quizás aqui el aspecto importante de verdad es que puedes doblar los recursos, pero no doblarás la velocidad de despliegues, sino que se mantendrá relativamente constante)

d) Finalmente, los “High Performers”. Estos son los preocupantes. Estos se mantienen más o menos cercanos hasta llegar a los 300 desarrolladores. Entonces comienza su escalada brutal: pasan a los cinco despliegues al día y rápidamente con capaces de llegar a los 80 despliegues al día apenas triplicando los recursos (osea, triplico los recursos y multiplico por 15 los resultados (!!!)

Posiblemente en estos momentos estés pensando que eso en el fondo son unos números más o menos trucados, quizás que en tu empresa hay doscientos programadores y que eres capaz de hacer 40 despliegues a la semana (que son unos 5 al día) y que eso está chupado, o simplemente que “¿y para qué quiero yo hacer tantos despliegues al día?”.

Perdón, que me ha faltado la última excusa, bastante frecuente además, la de “si, claro… pero ¿cuántos de esos despliegues son buenos? ¿Qué nivel de fallos tienen estos tios a esa velocidad?”. Te lo respondo en la siguiente tabla, tambien sacada del mismo State of Devops Report 2015

Ok, pues esto nos muestra que se está produciendo una brecha inmensa que está separando a los high performers del resto del mundo a una velocidad pasmosa y eso es un problema.

Ahora piensa en todos aquellos que están hablando sobre Transformación Digital. En el fondo están tratando de aplicar soluciones del mundo digital a los problemas que tienen sus clientes y buscando nuevas vías de contactar con ellos, de mantenerlos ligados a su marca, productos y servicios y rompiendose la cabeza para innovar en sectores que posiblemente sean muy tradicionales: ¿cómo ofrecer novedades en el sector banca, seguros, retail?

Y resulta que todo el concepto de Transformación Digital se basa en cuatro palabras: experimentar, innovar, aprender y digitalizar. Una empresa que aborde una iniciativa de transformación digital tiene que ser consciente de que esto no es un proyecto con inicio y fin, sino una transformación: ahora eres una cosa y luego serás otra, pero esa otra cosa, ese punto de destino es móvil y cambiante; las empresas transformadas ya no son empresas rígidas sino que son empresas líquidas que se adaptan de forma continua a un entorno, a un mercado y a unos clientes que cambian continua y rápidamente.

¿Y cómo puedes conseguir eso en un entorno digitalizado? Pues con velocidad. Necesitas que en IT tu flujo de aportación de valor sea muy rápido y que tu lead time sea muy corto con un nivel de acierto elevadísimo… y eso es exactamente lo que están consiguiendo los high performers de nuestra gráfica de arriba.

Resulta que los high performers han llegado a una situación en la que su lead time de experimentacion es muy corto, su capacidad de desplegar pruebas en los entornos de produccion es altisima, su riesgo muy bajo y su capacidad de recuperarse ante los errores es increible… los high performers pueden probar nuevos productos, nuevas lineas de negocio y nuevas maneras de comunicarse y satisfacer a sus clientes 200 veces más rápido que una empresa “normal”: o espabilamos o se nos comen!!

Así pues, la próxima vez que te plantees la transformación digital de tu compañía piensa primero en los cimientos sobre los que debes consruir ese cambio:

  • una cultura de colaboración
  • una organización transversal que huye de los silos verticales
  • equipos multidisciplinares
  • flujo de valor
  • aprendizaje
  • automatización

En definitiva, Lean-IT, Agile y DevOps o lo que nosotros llamamos Agile IT Management.

Y esos cimientos debes construirlos rápido: los high performers llevan años haciéndolo así que no te van a dejar respirar.

No tardes y empieza ya!

20 de noviembre de 2015

La muerte del proyecto o el Nirvana del Flow

Voy en el AVE volviendo de impartir un (otro) curso de Lean-IT; eso significa que llevo al menos tres días en los que mi cabeza sólo tiene un foco: el flujo, el waste, el valor, la Voz del Cliente y todo ese tipo de conceptos. Cuando consigo ese nivel de concentración pasan cosas interesantes, las ideas van sedimentando y de tanto explicar conceptos, otros más grandes se van consolidando encima de ellos.

Cierro los ojos y veo el flujo, como Neo. Me imagino una situación ideal, el Nirvana del flow y tiene pinta de un equipo multidisciplinar y no demasiado grande, bien avenido, motivados y con muchas ganas de cumplir su misión: entregar un software a su comunidad de usuarios que funciona, que hace lo que necesitan los usuarios incluso sorprendiéndoles con algún que otro truco sacado del sombrero de chistera del product owner o del UX Designer. Un software que va a la velocidad que quieren los usuarios, que está disponible, que no falla y que además cumple con las normativas y mantiene la seguridad en regla.

Pero ese equipo, además, resulta que se mantiene en contacto permanentemente con los usuarios, con los clientes (no obligatoriamente son la misma persona!) y de esa manera va incorporando nuevas funcionalidades y características al sistema de información y a la manera en que la empresa tiene de ponerlo al alcance de los usuarios (nuevos modos de contratación, nuevos modelos de facturación, nuevas formas de estar en contacto con los usuarios o incluso nuevas maneras de ayudar a los usuarios a sacarle el máximo provecho a tan preciado software).

¿Y sabes cómo empezó todo? Con una pequeña idea que probaron en un laboratorio de esos semestrales que la empresa facilita: “la semana que viene hay hackaton”, dijeron… se juntaron uno de marketing con un desarrollador, un experto en usabilidad y uno que trabaja en soporte, pero que le encanta jugar los fines de semana montando contenedores Docker, dejaron salir todo lo que tenian dentro y plof! Apareció una primera idea que parecía que podía tener éxito.

Cuando terminó el hackaton le mostraron a sus compañeros el resultado (basto, poco pulido, pero con una pequeña muestra de funcionalidad) y hubo quien apreció la viabilidad, así que la empresa decidió apostar y les pidió que en dos meses tuvieran montado un MVP (un Producto Minimo Viable) que pudieran presentar para ver si lo lanzaban.

A medida que pasaba el tiempo la lista de ideas iba creciendo: algunos usuarios piloto daban su opinión y encontraban nuevas maneras de usar la aplicación, muchos de los desarrolladores soñaban con nuevas funcionalidades y habia quien pensaba que añadiendo integraciones hacia otras partes de la organización podrían sacarle mucho más partido.

El equipo no era novato y ya había vivido esas sensaciones antes. Hicieron un gran esfuerzo para mantener a raya el WIP. Había que morder el pastel a pequeños trozos, masticarlos bien y hacer la digestión. Poco a poco aquello que era apenas una maqueta pasó a ser un MVP y el MVP fue creciendo hasta convertirse en un producto a secas y al cabo de los años hasta le quitaron el logo de “Beta” que tenía en la home page.

Durante todo este tiempo, el equipo permaneció relativamente estable. Algunos entraban y otros salían, pero el indice de rotación se mantuvo relativamente bajo. Sí que es cierto que cuando el producto comenzó a tener éxito, las nuevas ideas entraban mucho más rápido de lo que les daba tiempo a fabricarlas, así que trabajaron duramente para automatizar todo lo que podían para que los ciclos de desarrollo-integración-pruebas-aceptación-despliegue fueran lo más cortos posible, eliminando siempre que podían los frenos al flujo y habilitando bucles de feedback para que todo el equipo supiera en cada momento qué estaba pasando.

También es cierto que a medida que el volumen de usuarios iba creciendo el tamaño de las actividades de soporte y apoyo era cada vez mayor. Compredieron que no era sostenible así que decidieron poner en marcha todos los mecanismos que les facilitaran reducir este tipo de demanda: tolerancia cero a la deuda técnica, controles de calidad cada vez más exhaustivos, un interfaz de usuario brillante y fácil de usar, formación a los usuarios y una magnífica base de conocimientos que permitiera a los usuarios resolver sus dudas. Para terminar de poner la guinda a este pastel se inventaron el rol de “usuario ayuda a usuario” y habilitaron un foro de soporte en el que unos usuarios ayudaban a otros, todo inspirado por un potente motor de gamificación que permitía ganar puntos que podrías canjear en algunos establecimientos colaboradores (si ayudas en el foro puedes conseguir un pase VIP para el estreno de Star Wars!!).

Han pasado algunos años, y el producto sigue en constante evolución: siempre hay ideas nuevas, siempre hay necesidades nuevas y siempre hay formas nuevas de interactuar con el cliente, de forma que el equipo no se ha disuelto, siguen siendo aquellos que empezaron junto con otros que se han sumado a la aventura.

Lo que más me sorprende de todo esto es el cambio tan profundo de mentalidad: nunca ha habido un proyecto… nunca ha habido una planificación a un año vista ni tan sólo un roadmap (porque el roadmap lo hacen los clientes en as reuniones quincenales que tienen con el product owner. El roadmap nunca es a 5 años vista, sino que es a dos meses vista).

Esta manera de pensar ha sido “la muerte del proyecto” tal y como lo conocemos. Ahora ya no hay proyectos en esta empresa; lo que hay son experimentos que dan lugar a un ciclo de vida de producto (o de servicio, según lo quieras mirar). El proyecto tiene fecha de fin: acaba cuando se termina de construir, pero en este modelo no terminamos nunca de construir.

Hay algunos en el equipo que empiezan a dar señales de aburrimiento. Tienen ganas de nuevas aventuras, pero no piensan en cambiar de empresa. ¡Ni locos!

El mes que viene hay hackaton. ¿Te animas?

———
REFERENCIAS:

Para los conceptos de MVP y experiementación para incorporar la innovación, Lean Startup de Eric Ries
Para los ciclos cortos de desarrollo y contacto con el cliente, Agile
Para la automatización de los ciclos de desarrollo-pruebas-despliegue, Integración Continua de Jezz Humble
Para la cohesion de equipos multidisciplinares (de verdad), DevOps y Agile. Gene Kim y Jezz Humble
Para la motivación de los equipos y mantenerlos a tu lado, Management 3.0 de Jurgen Appelo
Para aprender más de todo esto sin tener que leerte la Biblioteca de Alejandria, G2 Gobierno y Gestión de TI

10 de julio de 2015

… y no hay mucho más que decir…



  1. Crear constancia en la mejora de productos y servicios, con el objetivo de ser competitivo y mantenerse en el negocio, además proporcionar puestos de trabajo.
  2. Adoptar una nueva filosofía de cooperación en la cual todos se benefician, y ponerla en práctica enseñándola a los empleados, clientes y proveedores.
  3. Desistir de la dependencia en la inspección en masa para lograr calidad. En lugar de esto, mejorar el proceso e incluir calidad en el producto desde el comienzo.
  4. Terminar con la práctica de comprar a los más bajos precios. En lugar de esto, minimizar el costo total en el largo plazo. Buscar tener un solo proveedor para cada ítem, basándose en una relación de largo plazo de lealtad y confianza.
  5. Mejorar constantemente y por siempre los sistemas de producción, servicio y planeamiento de cualquier actividad. Esto va a mejorar la calidad y la productividad, bajando los costos constantemente.
  6. Establecer entrenamiento dentro del trabajo (capacitación).
  7. Establecer líderes, reconociendo sus diferentes habilidades, capacidades y aspiraciones. El objetivo de la supervisión debería ser ayudar a la gente, máquinas y dispositivos a realizar su trabajo.
  8. Eliminar el miedo y construir confianza, de esta manera todos podrán trabajar más eficientemente.
  9. Borrar las barreras entre los departamentos. Abolir la competición y construir un sistema de cooperación basado en el mutuo beneficio que abarque toda la organización.
  10. Eliminar eslóganes, exhortaciones y metas pidiendo cero defectos o nuevos niveles de productividad. Estas exhortaciones solo crean relaciones de rivalidad, la principal causa de la baja calidad y la baja productividad reside en el sistema y este va más allá del poder de la fuerza de trabajo.
  11. Eliminar cuotas numéricas y la gestión por objetivos.
  12. Remover barreras para apreciar la mano de obra y los elementos que privan a la gente de la alegría en su trabajo. Esto incluye eliminar las evaluaciones anuales o el sistema de méritos que da rangos a la gente y crean competición y conflictos.
  13. Instituir un programa vigoroso de educación y auto mejora.
  14. Poner a todos en la compañía a trabajar para llevar a cabo la transformación. La transformación es trabajo de todos.

William Edwards Deming, 1986

2 de octubre de 2013

El servicio TI

Hace unos cuantos días que en un foro del underground ITSM se está discutiendo al respecto de la definición del concepto de Servicio TI. Parece mentira que a estas alturas tengamos estas discusiones, pero la verdad es que eso de “un medio de darle valor al cliente, bla bla bla” lo ha hecho un poco difícil, al tiempo que “un sistema de información que soporta un proceso de negocio” era demasiado simple.

La discusión viene de lejos… si bien en este caso todo empezó por esta entrada de blog que escribió Aale Ross ( http://pohjoisviitta.fi/itsm-from-the-top-of-the-world/improving-itil-3-forget-the-service-lifecycle/ ) también han salido a relucir otras discusiones como esta ( http://www.itskeptic.org/what-service) o esta otra mucho más reciente (http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers&discussionID=276434337&gid=68677&goback=.nmp_%2A1_%2A1_%2A1_%2A1_%2A1_%2A1_%2A1_%2A1_%2A1_%2A1#commentID_null )

Esto no hace más que demostrar que la comunidad de Gestión de Servicios TI no se acaba de poner de acuerdo al respecto de lo que es un servicio TI.

Ya me iba a casa, incluso tenía el PC apagado! pero de repente se me encendió una idea que no quería dejar de compartir aquí. ¿Y si lo miramos desde otro punto de vista?

Servicio

En castellano la palabra “servicio” tiene otras acepciones… ¿No? Pero no es a eso a lo que yo me refiero. ¿Quien puso el WC ahí? ¿Quién lo mantiene?

Si pensamos como usuarios, la definición del servicio está clara… y las expectativas también: espero que funcione, que desagüe, que no huela mal, que esté limpio… características del servicio.

Si le preguntamos al departamento de mantenimiento de edificios qué servicios ofrece al respecto de los lavabos, seguramente me dirá que “limpieza”, “desinfección”, “provisión de fungibles”… es decir nada de lo que yo como usuario entiendo como servicio.

Lo que ellos hacen son actividades orientadas a asegurar que el WC está y se comporta como yo (usuario) espero: lo limpian, lo desinfectan, lo mantienen en correcto funcionamiento… se preocupan de que el WC entregue UTILIDAD y GARANTIA, pero es servicio NO ES EN SI MISMO el trabajo de asegurar la utilidad y la garantía.

En Informática nos pasa lo mismo: nos empeñamos en decir que nuestros servicios son “el mantenimiento de aplicaciones” o “la administración de sistemas”, cuando en realidad eso son actividades que hacemos para asegurar que los sistemas de información entregan utilidad y garantía.

Siguiendo por esta línea, me quedo con la definición de servicio IT que llevo utilizando mucho tiempo: un sistema de información gestionado (osea, con todas esas actividades realizadas por personas a su alrededor orientadas a asegurar que se entrega la utilidad y la garantía).

Un sistema de información, no una aplicación.

Con visión de usuario. Outside-In.

8 de julio de 2013

Standard, Case y los procesos estructurados

41LQdp24ikL._SX385_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

taiichi-ohno

 

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?

21 de junio de 2013

¿Qué tal se te da el multitasking?

Ya sabemos que multitaskear es bastante malo para la salud mental, para tu rendimiento y para la calidad de los resultados del trabajo… pero también sabemos que hay un mito alrededor de que los hombres no sabemos hacer más de una cosa a la vez…

Quieres comprobar si el mito es cierto? Aquí te dejo un experimento que te demostrará qué tal se te da esto, cómo te comparas con la media y, sobre todo, que desvelará el secreto de si el género afecta o no a la capacidad de multitaskear…

24 de abril de 2012

Lean Management: la clave para un outsourcing de primera clase

El 2011 ha sido el año de Lean-IT: han aparecido publicaciones y foros, se ha realizado el I European Lean IT Summit, han surgido de la nada nuevos esquemas de certificación y se han impartido clases y dado conferencias por todo el país.

Esto probablemente ha sido motivado porque se acabaron definitivamente las vacas gordas y ahora nos enfrentamos a una larga temporada de vacas flacas; los directivos buscan maderos a los que agarrarse y poder seguir entregando los niveles de servicio demandados pero, eso sí, dentro de unos niveles de calidad aceptables y, sobre todo, dentro de los márgenes económicos en los que se pueden mover en esta nueva situación.

El Pensamiento Lean se mueve siempre basado en una serie de principios, que podemos resumir en el siguiente gráfico:

Principios_Lean

Por otra parte, un proveedor de servicios IT en modalidad de outsourcing o prestación de servicios continuados se encuentra en estos momentos con la necesidad acuciante de cumplir con las necesidades del cliente (representado principalmente en el modelo tradicional de entrega de servicios por “cumplir las exigencias del contrato” o “satisfacer los SLA”), posiblemente reducir los importes de estos contratos (hacer más con menos) y por otra parte satisfacer sus propias necesidades de rentabilidad (mantener los márgenes de beneficio).

Así, nos encontramos en una situación en la que por una parte la demanda tira del beneficio hacia abajo y mantiene, si no aumenta, la tensión sobre las exigencias de nivel de servicio; por otra parte, el proveedor se ve en la obligación de mantener el beneficio obtenido por la prestación, por lo que alguno de los puntos del triángulo de los servicios se verá afectado.

Pero esto no debe ser necesariamente así. La primera lectura es que si disponemos de menos financiación, habrá que dar menor rendimiento o peores niveles de servicio, y es aquí donde Lean-IT nos puede ayudar especialmente. Veamos cómo siguiendo los diferentes principios que hemos presentado anteriormente:

IDENTIFICAR EL VALOR: Lean asume que los atributos de un producto o servicio que establecen el valor aportado para el consumidor son variables y que por lo tanto debemos realizar una alineación permanente con estos atributos. Eso repercute directamente en la necesidad permanente de contacto con el cliente/consumidor para identificar en cada momento qué es lo importante, ajustando la producción a esas necesidades. Desde el punto de vista de un proveedor de servicios, esto significa que necesitamos contratos lo suficientemente flexibles como para soportar fácilmente variaciones en las necesidades, eTriangulo_Leann los ámbitos, en los niveles de servicio entregados y, lógicamente, en los niveles de facturación y por lo tanto se debe trabajar en equipo para formalizar estos contratos ágiles con mecanismos de facturación variable. Por otra parte, un proveedor de servicios con espíritu Lean no sólo se centrará en el cumplimiento del contrato; pondrá su interés en el propósito de su cliente… ¿Recuerdas la definición de servicio según ITIL? “Un medio de generar valor al cliente facilitando los resultados que desea obtener…” esto es lo que significa ese interés en el propósito: entender y facilitar los resultados que el cliente desea obtener.

IDENTIFICAR, REPRESENTAR Y OPTIMIZAR EL FLUJO DE VALOR: Como dicen Mike Rother y John Shook en su libro “Learning to See”, siempre que hay un producto para un cliente, hay un flujo de valor. El reto consiste en verlo. Este principio Lean hace aflorar uno de los principales problemas organizativos que existen: la jerarquía es a nivel funcional, a nivel de unidades organizativas mientras que el flujo de valor hacia el cliente/consumidor es transversal y cross-funcional. Cuando se aprende a representar y ver el flujo de valor se puede detectar una multitud de actividades que se realizan que no aportan nada a esos parámetros o atributos de valor que hemos identificado en el punto anterior: es lo que el Pensamiento Lean denomina waste (desperdicio, ineficiencia, derroche) y que nos permitirá optimizar el flujo, dejándolo libre de todas estas actividades que sólo incorporan más tiempo de proceso, más volumen de actividad y más ineficiencia global. Aquí es donde entra en juego la posibilidad de hacer más con menos, hacer más de lo que aporta valor, más de lo que al cliente le sirve para lograr su propósito, con menos consumo de recursos, con menos ineficiencia y con menos actividades que no aportan valor. En el fondo, aquí de lo que estamos hablando es de poder lograr los objetivos marcados utilizando menos recursos con lo que podremos ajustar el presupuesto tal y como nos lo exigen los tiempos que corren, al tiempo que podemos mantener los niveles de servicio esperados.

FACILITAR EL “PULL”: Durante las sesiones de formación en Lean Thinking es habitual realizar simulaciones o juegos de mesa en los que se demuestran algunos de los conceptos explicados durante las clases. Uno de estos juegos consiste primero en simular un sistema basado en PUSH (empujar la producción hacia el mercado, producir en base a previsiones y acertar a que el producto se consuma en el momento esperado) y posteriormente otro sistema basado en PULL (en el que es la demanda y el consumo el disparador de la producción, principio básico para la producción Just in Time). Los resultados son espectaculares en estos juegos, donde llegamos a ver incrementos en el resultado final (no sólo en la productividad, sino en los resultados económicos finales: se produce ajustadamente a lo que se puede vender y por lo tanto no hay sobrecostes de almacenamiento, sobre-stock, materiales, etc..)

Pero nosotros, en IT, no nos movemos en una cadena de montaje. Lo nuestro no es una producción en serie con poca variabilidad en el producto entregado y por lo tanto las herramientas Lean no se pueden aplicar directamente sin modificaciones; nos movemos en el mundo de los servicios, intangibles, variables y con una característica fundamental que los hace únicos: la coproducción. El usuario sincroniza el acto del consumo con el acto de la producción que se realiza desde el área de IT (no en el 100% de los casos, pero sirve como generalización). Es por eso que en esta situación el PULL o acto de “estirar de la cadena de producción” se convierte en un factor crítico. Debemos facilitar el consumo y debemos conseguir alisar en lo posible la demanda.

En el caso de nuestro hipotético proveedor de lo que podremos llamar “LeanSourcing”, el hecho de estar permanentemente cerca del cliente, co-planificando la demanda y pensando con él en maneras de conseguir que haya el mínimo posible de picos, hace que el proveedor pueda organizar mucho mejor los recursos necesarios, entregar los recursos adecuados, planificar sus propias necesidades de contratación y de formación, racionalizar, en definitiva, sus costes.

Un ejemplo interesantísimo de este caso se produce cuando vemos a empresas que tienen externalizado su AM&O (Application Management & Operations ) y que colaboran con su proveedor para planificar la demanda de nuevos desarrollos y evolutivos en ventanas a 3 meses vista. Cuando esta planificación se hace de forma apropiada, el cliente consigue a las personas más adecuadas para cada uno de los trabajos y el proveedor, con un conocimiento previo de la demanda que tendrá del cliente, puede planificar mejor sus equipos e incluso planificar las necesidades de contratación o de formación que tendrá.

BUSQUEDA DE LA PERFECCION: Este principio asume que la perfección es un estado utópico, inalcanzable; no por ello debemos tirar la toalla, sino que debemos iniciar actividades de adaptación continua a las necesidades de ese “blanco móvil” que es el valor desde el punto de vista del consumidor. Bajo este paraguas aparecen las herramientas de mejora continua, tanto del sistema de producción como del producto/servicio producido.

Aquí aparece el trabajo en equipo, el aprovechar la inventiva, imaginación y conocimiento de todo el equipo, hacer participar a los diferentes integrantes del flujo de valor en las propuestas de mejora y un concepto importantísimo en toda iniciativa de gestión Lean: Walk the Gemba, pasear, visitar, conocer cómo se realiza el trabajo de verdad (Gemba es una palabra japonesa que tiene el significado de “lugar donde se encuentra la verdad” y “lugar donde se produce la acción”). Hablando con expresiones más castizas, comprenderemos mejor cuáles son las necesidades de mejora del sistema productivo si somos capaces de ponernos en la piel de cada uno de los que intervienen en el flujo de valor; y podremos comprender las necesidades de mejora del producto/servicio que entregamos si nos ponemos en la piel del consumidor/usuario que utiliza nuestros productos/servicios.

Otro ejemplo especialmente interesante del grado de comprensión que se adquiere cuando se vive el Gemba es el caso de una empresa en la que, después de varias sesiones destinadas a plantear las mejoras necesarias en la gestión de facturas de proveedores, el analista se pasó una mañana validando facturas y conformando albaranes. Mientras lo iba haciendo, iba exclamando “¡Pero este trabajo lo he hecho ya dos veces!”, “¡Aquí me faltaría un campo para registrar esta información!” o “¡Necesito una consulta que agilice este paso!”

consumo_leanUn LeanSourcer no desarrollará su trabajo de manera deslocalizada sin exigirle a su cliente que los equipos de trabajo puedan visitar, ver y vivir de vez en cuando el Gemba del usuario, sentir sus problemáticas y poder así plantear mejoras a los servicios entregados.

En conclusión, cumplir con la exigencia que hacen los clientes hoy en día de hacer más con menos sin perder la calidad es un reto que se puede conseguir traduciendo la consigna en “hacer lo necesario, bien a la primera, y con el menor consumo de recursos posible”, que es justamente el leitmotiv de la gestión Lean, aunque para ello es preciso que ambos componentes de la ecuación, cliente y proveedor, trabajen en equipo para conseguirlo. Se construye de esta forma un sistema productivo en el que todos ganan y, en esta relación win-win se consolidan relaciones de larga duración en las que el cliente y el proveedor se convierten en partners.

NOTA: Este artículo se publicó por primera vez en la revista Service Talk de Abril 2012 (Año VII – Edición I), publicada por el itSMF de España.

5 de abril de 2011

Conceptos LEAN : YOKOTEN

dragonball2La palabra japonesa Yocoten significa “despliegue horizontal”. Está directamente relacionada en el mundo LEAN con el acto de aprender de nuestros éxitos (en contra del tradicional “aprender de nuestros errores”, que también tiene su sentido). El significado que hay detrás de este término es el comprender cuáles son las prácticas que hemos llevado a cabo en el diseño, fabricación o entrega de un producto (bien o servicio) y ser capaces de “replicar” ese éxito.

Este aprendizaje continuo sobre cuáles son las prácticas que nos han funcionado bien no sólo es aplicable internamente en una organización, sino que también las podemos extrapolar al exterior, a otras organizaciones (sean o no de nuestro sector) y eso es lo bonito del tema… el conocimiento transversal, el aprender de los demás y el llevar adelante nuevas iniciativas de cambio y mejora inspiradas en éxitos de otros (contribuyendo de esta manera al crecimiento de la sociedad en su conjunto).

Así, cuando leemos los libros en los que se describe el Sistema de Producción de la Toyota, vemos algunas prácticas que a ellos les han resultado provechosas y las trasladamos a nuestra organización, estamos haciendo Yokoten; cuando entendemos cuáles han sido los factores de éxito de la implantación de un servicio en una rama de la compañía y la trasladamos, comunicamos, enseñamos y aplicamos finalmente en las otras ramas, estamos haciendo Yokoten; cuando una administración pública aprende de otra administración pública o es capaz de replicar ejemplos de éxito en sus diversas sedes, departamentos, consejerías, Ayuntamientos… estamos haciendo Yokoten.

Esto enlaza de perlas con el mundo de la Gestión de Servicios TI, ya que para empezar tenemos toneladas de “marcos de referencia” y de “prácticas recomendadas”; cuando entendemos quénos aporta ITIL® y aplicamos algunas de sus enseñanzas en nuestra organización, estamos practicando Yokoten.

Ahora bien, para eso (sobre todo internamente) es necesario no sólo aprender de nuestros errores, sino aprender de nuestros éxitos y para ello necesitamos comprender qué componentes o factores de un servicio que damos son los que contribuyen de forma importante a que éste sea un buen servicio:¿POR QUÉ NUESTRO SERVICIO ES BUENO?

Ahora, como dicen los “Lean Thinkers”, ves y mira (Go see), porque seguramente la clave de por qué tu servicio es bueno no la encontrarás en tu despacho: la verás en el lugar donde se trabaja, donde se produce el servicio, donde se consume el servicio y sobre todo en las manos de aquellos que usan tu servicio para un propósito superior. Sal fuera, observa, pregunta, muestra respeto y aprende.

17 de noviembre de 2010

Momentos de la Verdad

La semana pasada estuve impartiendo un curso de Gestión LEAN de Servicios, que tiene un primer bloque dedicado a la gestión de servicios, pero no desde el punto de vista que para nosotros (los de IT) es tradicionalmente “itilero”, sino desde un punto de vista más universal, basado en USMBOK™.

En este apartado se comienza con una definición de servicio que encaja perfectamente con lo que yo llamo Servicios Profesionales, pero que queda ampliado incluso para cubrir el concepto de Servicio IT tal y como lo describe ITIL V2.

La definición aportada por USMBOK es

Acto, hecho o rendimiento que una parte o persona puede ofrecer a otra, una transacción

Acto que una persona puede ofrecer a otra… no está mal! No se parece demasiado al famoso “email” que hemos utilizado los últimos 20 años para ejemplarizar el concepto de servicio, se parece un poco más al “servicio de Telefonía” que me ofrece mi operador, encaja perfectamente con el concepto de servicio que vemos en la recepción de un hotel y se aproxima bastante a la definición de servicio que nos propone ITIL® V3 (cito de memoria, porque ahora voy en el tren de vuelta a casa)

Un medio de proporcionar valor al cliente facilitándole los resultados que quiere obtener sin la propiedad de los riesgos ni los costes.

Ambas definiciones, la de USMBOK™ y la de ITIL® V3 vienen derivadas de la vertiente servicios de la ciencia que rodea al Product Management.

Ahora bien, durante el curso hubo un alumno que preguntó cuál era el servicio, la telefonía o el acto de telefonear (cada “instancia” de llamada)… hummm Interesante pregunta, da para filosofar un rato, pero menos mal que el USMBOK tiene la respuesta para eso… se llama transacción, (Service Transaction) y es el periodo en el que el cliente/consumidor del servicio hace uso de él… qué curioso! es como enviar un eMail.

Medico Mediano (800x533)Esta transacción de servicio tiene determinados momentos en los que el consumidor entra en contacto con la organización proveedora de servicios (hablas con el camarero, haces la llamada de teléfono, llamas al 900-XXX-XXX para decir que no te funciona la ADSL o te identificas en la recepción del hotel) y es en estos momentos en los que (como aquella colonia de cuyo nombre no consigo acordarme) “te la juegas en las distancias cortas”. Estos momentos son los que en USMBOK se denominan “momentos de la verdad”,término acuñado por Jan Carlzon en su libro “moments of truth”, donde dice algo así como

Last year, each of our 10 million customers came into contact with approximately five SAS employees, and this contact lasted an average of 15 seconds each time.Thus, SAS is "created" 50 million times a year, 15 seconds at a time. These 50 million "moments of truth" are the moments that ultimately determine whether SAS will succeed or fail as a company. They are the moments when we must prove to our customers that SAS is their best alternative

Así, Carlzon defiende que la percepción de calidad y por ende la satisfacción del cliente con el servicio depende no sólo del resultado obtenido por el consumo del servicio (en este caso, un vuelo con SAS) sino que también se ve profundamente influido por (y aquí está la gracia) todas y cada una de las interacciones que se realizan entre la organización proveedora del servicio y su cliente/consumidor, involucrando a todo el personal en los resultados de calidad del servicio.

De hecho, incluso la organización proveedora de servicios puede crear momentos de la verdad “artificales” precisamente para controlar y moldear la percepción de calidad o la satisfacción del cliente: no te ha pasado nunca que de repente viene un camarero y te pregunta “Qué tal su sopa, señor?” o que un distribuidor te llama para decirte “su paquete ha llegado al centro logístico, esperamos entregárselo mañana” y tú, instintivamente, piensas "”Qué bien, estos, no?”

Si nos lo llevamos esto al mundo ITILero de la Gestión de Servicios TIC veremos (y esto ya lo sabemos todos, pero hay que recordarlo de vez en cuando) que la cara bonita de IT no es sólo el ServiceDesk, sino que somos todos y cada uno de los trabajadores que participamos en la creación/entrega del servicio en cada uno de los contactos que tenemos con nuestros clientes (el técnico de soporte onsite, el analista, el programador, el operador de explotación, la recepcionista, la directora de desarrollo y la CIO) lo que nos genera una muy importante sensación de trabajo en equipo que va mucho más alla de las fracturas cross-funcionales tradicionales que nos encontramos en el 90% de los departamentos de IT (dejamos en el 10% restante a los departamentos que funcionan como la seda 0,001% y a aquellos formados por 1 única persona 9,999% ) [Nota del autor… estos números son figurativos, no me los vaya a tomar nadie como verídicos!!]

Así, podemos ver que hay muchísima bibliografía relativa al mundo de los Servicios (El libro de Carlzon es del 87… como ITIL V1) que nos puede ayudar a convertirnos en proveedores excelentes de servicios TI de igual manera que ha ayudado a otras empresas de otros sectores totalmente diferentes (aviación, banca, restauración, hostelería…) a diseñar y comercializar unos servicios excelentes.

La verdad está ahí fuera… usa Google para buscarla!

25 de julio de 2010

4 detalles que me gustan de la UNE-ISO/IEC-20000-1

image El documento de la UNE-ISO/IEC 20000-1:2007 es cortito pero muy condensado. Tiene 22 páginas, y si le quitamos el índice, portada y cosas por el estilo nos quedan apenas 13 páginas de contenido para acotar los requisitos obligatorios (los debe de la norma) que debe cumplir un Sistema de Gestión de Servicios TI.

Siendo tan comprimidita, no se anda con florituras y dice las cosas directas al corazón; por esa razón he querido hacer un pequeño compendio con las mejores joyas que nos podemos encontrar escondidas entre los requisitos.

1.-Responsabilidad de la Dirección: El principio de liderazgo se materializa en el primer capítulo “efectivo” de la norma (3. Requisitos de un sistema de gestión). Tradicionalmente en los proyectos “itileros” se dice siempre que uno de los factores críticos de éxito es contar con el apoyo o “esponsorización” de la dirección. La norma convierte esto en requisito obligatorio indicando

La alta dirección debe proveer, a través de liderazgo y de acciones, evidencias de su compromiso para desarrollar, implementar y mejorar sus capacidades de gestión del servicio […]

Ojo al detalle, que dice “la alta dirección”… no una dirección cualquiera sino la alta. El fantástico porque a continuación dice

La dirección debe:

[…]

  • Designar un miembro de la dirección como responsable de la coordinación y gestión de todos los servicios

Y eso, llevado al extremo, requiere que, o bien la alta dirección “baje a galeras” para coordinar y gestionar servicios o bien (y aquí esta el arma secreta) que este responsable forme parte de la dirección… y plof! ya tenemos al CIO en el Comité de Dirección.

2.-Competencias y Formación: El capítulo 3.3 de la norma, referido a Competencia, Concienciación y Formación obliga a las organizaciones a mantener un alto grado de coherencia entre los roles, las competencias requeridas para asumirlos y las capacidades del personal. De esta forma se intenta garantizar que todo el personal que participa en la gestión del servicio está capacitado para realizar su trabajo.

3.- Planificación de la Implementación del SGSTI. El capítulo 4.1 habla de la planificación de la gestión. Este punto me gusta especialmente porque fuerza a que la definición de los procesos no sea sólo un diagrama de flujo con cuatro explicaciones, sino que sea una definición “hecha y derecha”, siguiendo el modelo ITOCO:

Se debe planificar la gestión del servicio. Como mínimo, el plan debe definir lo siguiente:

[…]

c)los procesos que se van a ejecutar;

d)el marco de los roles y responsabilidades de la dirección, incluyendo al directivo de alto nivel responsable directo, al propietario del proceso y a la dirección de la gestión la dirección de los suministradores;

e)las interfaces entre los procesos de gestión del servicio y el modo en que tienen que coordinarse las actividades;

[…[

h)los recursos, el equipamiento y los presupuestos necesarios para alcanzar los objetivos definidos;

4.- Forzando la Transición “como Dios manda”. El apartado 5 de la norma declara los requisitos necesarios para implantar “servicios nuevos o modificados” en el entorno de producción. Este es un punto esencial para conseguir mantener la estabilidad del entorno productivo y por eso los requerimientos son (o podemos hacer que sean) especialmente estrictos. De este capítulo hay dos frases que me gustan especialmente:

Objetivo: Asegurar que tanto los servicios nuevos como las modificaciones a los existentes se pueden gestionar con los costes y la calidad acordados.

Básicamente eso significa que los servicios que entren a producción se pueden gestionar; osea, que hemos tenido todo el cuidado necesario para asegurar que se extiende el SGSTI para contemplar y gestionar el nuevo servicio (roles, procesos, procedimientos, herramientas, informes, etc etc etc).

Los nuevos servicios o las modificaciones en los existentes deben ser aceptados por el proveedor del servicio antes de ser implementados en el entorno de producción real

¡¡Toma Ya!! Al fin, el dueño del entorno de producción tiene la posibilidad de aceptar o no la entrada en producción de un nuevo servicio (o modificado)… ¿Ha pasado los tests?, ¿se ha hecho la formación a los operadores y administradores? ¿se han redactado los manuales de explotación? ¿sabemos cómo se monitoriza? etc, etc, etc

En fin, ya hemos visto algunas de las joyitas que trae la norma y como pueden ver, es importantísimo hacer una lectura muy detallada de los contenidos para tener bien claro con qué nos vamos a encontrar.

7 de abril de 2010

Un poco de Lean Thinking en el Service Desk

efx-Lean-Fix_Web 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

17 de diciembre de 2009

Reducing OPEX to fund innovation

Hoy se ha publicado en el ITSM Portal una columna que explica la necesidad de controlar y reducir los costes de operación de los servicios TI para poder garantizar que existan fondos para la innovación y la creación de ventajas diferenciales en las compañías.

Incluyo a continuación un pequeño extracto, pero si quieres leer toda la columna, puedes hacerlo en http://www.itsmportal.com/columns/reducing-opex-fund-innovation

IT is like a living creature under continuous evolution. The ability to head this evolution towards a permanent alignment with business operational and strategic needs is one of the most wanted skills in the CIOs, together with the art of empowering and retaining the skilled and talented resources needed to realize the evolution.

fig3

Given these tough economy times, most organizations are not allowed (or incapable) to assign additional funds to new projects and initiatives. As a consequence, IT spending is frozen or even further reduced. In the mean time, the business requires IT to participate in the innovation needed for their market differentiation, either through the delivery of new capabilities to the user communities or to the business processes, or by reducing production costs. Operational budget (OPEX) is intended to run the business as usual, while investment funds (CAPEX) will generate new ways to run the business that will act as an additional component for the expected differentiation. Therefore, CIOs need to be able to transfer part of the budget from OPEX to CAPEX sections.

 

Espero vuestros comentarios y, cómo no, vuestros votos.

29 de julio de 2009

Acelerando el ciclo de diseño de servicios

Los chicos de JustInMind han publicado una nueva versión de su producto JustinMind Prototyper. Es una aplicación que, desde que la conozco, me llama poderosamente la atención, porque pienso que es una herramienta justinmindmuy importante para acelerar los ciclos de diseño y desarrollo, al tiempo que reduce de una manera considerable los riesgos de rechazo que podamos tener en el momento de la validación o de la entrega de las aplicaciones desarrolladas “en casa”.

Lo importante de JP no es sólo que nos permite hacer maquetas que le podemos presentar al cliente antes de comenzar a desarrollar (lo que tantas y tantas veces hemos visto hacer con imágenes o con diseños en powerpoint “que lo aguanta todo”), sino que además incorpora todos los mecanismos que nos van a permitir realizar hacer una maqueta funcional (osea, que funciona) y que el propio cliente (o sus Key Users) pueden probar, validar y comentar, al tiempo que facilita el flujo de revisión y aprobación por parte del cliente de cada una de las secciones de la maqueta.

La gran ventaja de esto: movemos la validación de usuario a una etapa anterior al desarrollo lo que reduce considerablemente el riesgo.

Si en tu casa desarrollas software, es un indispensable para al menos evaluarlo (te puedes bajar una versión de trial y el runtime es gratuito): mejor servicio al cliente (que puede “tocar” su aplicación antes de que la desarrolles), menores ciclos en el desarrollo (ya que el equipo de desarrollo “ve” lo que tiene que construir), menores ciclos de aceptación (ya que el cliente obtiene exactamente lo que vió en la maqueta) y menor riesgo de rechazo (de clientes, que han participado en el diseño, y de usuarios, que pueden haber incluso recibido  una primera formación utilizando la maqueta).

17 de junio de 2009

Lean ITSM

Hace ya un par de años escuché una conferencia de Ian Clayton sobre la aplicación de los conceptos del Lean Manufacturing al mundo de los servicios TIC. Después de eso, pudimos ver de nuevo a Ian en el congreso itSMF de Barcelona, el pasado mes de Noviembre y este año 2009 han comenzado ya a oirse muchos más mensajes sobre este tipo de aproximación a la Gestión de Servicios.

Las ideas de Lean Manufacturing se basan principalmente en el uso óptimo de los recursos (materiales y humanos) para los procesos de producción, reduciendo al mínimo el mal uso de los mismos y eliminando aquellas actividades que no aporten un valor claro al resultado final del proceso productivo. Estas ideas tienen su origen en los inicios de la revolución industrial, siendo notorio el caso de Henry Ford aplicando estos principios en la cadena de producción o el caso (de ejemplo en toda la bibliografía al respecto) del Sistema de Producción de Toyota (TPS)

Es probablemente debido a esta aproximación de “reducción del mal uso” o del despilfarro (waste, en terminología Lean) que en estos tiempos de crisis estamos asistiendo a un auge importante de estas ideas en el ámbito de la Gestión de Servicios TIC, ya que sus promotores afirman (no sin razón) que en la cadena de provisión de los servicios TIC existe una gran cantidad de puntos en los que se producen “fugas” que afectan directamente a los costes o al valor proporcionado por estos servicios.

leanAsí, vemos que el enfoque Lean IT Service Management aplica sus esfuerzos, por una parte en la reducción del despilfarro tanto en el acto de consumir el servicio (usuarios) como en el acto de proporcionar el servicio (IT) y por la otra a la maximización del valor ofrecido a los clientes y usuario. Esto se hace mediante un ciclo continuo de identificación de los puntos de de despilfarro, priorización de las acciones de mejora y aplicación de estas mejoras; no parece muy distante de los mecanismos de mejora continua que tradicionalmente vemos en otros modelos de gestión como ITIL, ISO 20.000 o Cobit, pero la diferencia principal aquí está en la focalización en aportar exactamente lo que se necesita, usando el mínimo de recursos en el momento adecuado en función de la demanda de los servicios (no olvidemos que la sobreproducción o sobrecapacidad en un servicio es una fuente importante de waste porque los servicios no se pueden estocar)

En general, se identifican 8 formas distintas de despilfarro en una cadena de provisión de servicios TI y es en ellas en las que se pone el foco de estudio y optimización:

ELEMENTO DE DESPILFARRO EJEMPLOS
Sobreproducción Sobredimensionamiento de las arquitecturas técnicas
Entrega de múltiples aplicaciones solapadas o de baja aportación de valor
Aprovisionamiento a niveles más rápidos de los que el usuario realmente requiere
Defectos Reworking
Cambios de baja calidad
Esperas Aplicaciones con bajo rendimiento
Mecanismos manuales para el escalado de peticiones
Falta de integración entre sistemas
Desplazamientos Soporte on-site innecesario o poco optimizado
Procesos Extra Documentación de detalles que se vuelven obsoletos demasiado rápido
Integraciones innecesarias en una CMDB
Sobreinventario Shelfware
Logística Innecesaria Movimientos de material poco óptimos
Cambios de equipos “en cadena”
No uso del Conocimiento Ideas útiles que se pierden para siempre
pérdida de oportunidades de mejora
Repetición de tareas de investigación por mal uso del conocimiento adquirido

Otro de los conceptos importantísimos dentro de LeanITSM es la identificación y comprensión de la cadena de valor (value-stream) en la provisión del servicio al usuario. Identificando todos los pasos que se siguen desde la petición hasta la entrega final (“flow”) podremos trabajar en la identificación de los puntos de despilfarro y mejorar cada uno de estos aspectos.

En conclusión (y para no hacer demasiado largo este ladrillo): el mundo de la producción industrial tiene mucha más antigüedad que el mundo de la gestión TIC, y podemos aprender mucho de ellos (desde conceptos como el BOM que viene a ser “la CMDB del mundo industrial”, pasando por la mejora continua y sistemática que ofrece Six Sigma hasta la optimización de la relación coste/valor mediante Lean).

Por cierto, si eres miembro del itSMF y quieres saber más, no olvides darle un muy buen ranking a la temática Lean ITSM en la encuesta para los contenidos del próximo congreso internacional… seguro que nos sorprenderán con nuevas ideas!

6 de abril de 2009

¿Proveedor o Partner?

Cuando era pequeño, las mañanas de los sábados se dedicaban inevitablemente a las compras semanales para la familia. Salíamos mi madre y yo, carrito de la compra en ristre, rumbo al supermercado y después de ahí al mercado central, a hacer la compra de la fruta y la verdura.

Estas salidas siempre fueron motivo especial de alegría (nunca se sabe lo que vas a encontrar en el mercado!) y de aprendizaje, ya que mi madre siempre aprovechaba cualquier ocasión para enseñarme las cosas de la vida y el mercado era la fuente principal de lecciones sobre Relación con Proveedores.

hierbasÍbamos siempre a los mismos puestos, siguiendo siempre la misma ruta, y comprando siempre a las mismas tenderas, salvo que alguna no tuviese lo que buscábamos y en ese caso ellas mismas nos indicaban a qué puesto teníamos que ir (bueno, en realidad era la propia tendera la que decía “Manolo, vete al puesto de Josefa y pídele una calabaza. Que sea buena, que es para la Señora Bernardita”, y allá que iba el señor Manolo a buscarnos la mejor calabaza del mercado)

Era bastante habitual que volviésemos a casa, además de con el carrito lleno, con una caja de fruta remadura que no se podía vender y que nosotros convertíamos en mermelada o con unos cuantos calabacines que de puro feos no tenían salida, pero que convertidos en puré estaban exquisitos.

La clave está en comprar siempre en el mismo sitio, en tejer una relación de confianza con las señoras de los puestos para que te cuiden porque eres un buen cliente. Los que compran cada día en un sitio, buscando siempre el mejor precio, seguramente se ahorran unas pesetillas, pero no se llevarán el mejor género porque ese se guarda para la gente de confianza

Ni mi madre ni yo somos de madrugar, así que las visitas al mercado eran más bien tardías… pero siempre había buen género para la Señora Bernardita.

Cuando se establece una relación ventajosa entre un cliente y un proveedor, en la que el cliente trata con respeto y lealtad al proveedor y éste responde con implicación y valor añadido se están dando los primeros pasos para convertir a este proveedor en un Partner.

Partner es una palabra inglesa, que significa literalmente “an associate who works with others toward a common goal”, un asociado que trabaja con otros para conseguir (y aquí es donde viene lo bueno) lograr unos objetivos comunes. Los objetivos de un partner tienen que ser comunes a los de sus asociados, o no será un partner.

Así, es necesario que el proveedor vea en el cliente una relación de larga duración y que desee cuidarla (idea totalmente contraria a la “cultura del pelotazo” en la que si le puedo enchufar sea como sea el mega-proyecto al cliente ya soy feliz).

Esta relación de larga duración le dará al proveedor algo que es especialmente importante: conocimiento de su cliente. Cuando conoces a tu cliente, puedes precisamente dar esa pieza de valor añadido de la que hablábamos antes…. Amazon puede ser mi proveedor de libros, pero jamás (al menos por ahora) podrá ser mi “partner en asuntos de libros”, porque no me conoce, no sabe mis gustos y no puede escuchar mis opiniones al respecto (van por ese camino, pero aún les queda mucho!)

Sin embargo, el señor de la librería a la que siempre voy ya sabe qué libros me gustan y me puede sugerir “llévate este que me acaba de llegar que seguro que te gustará”; y esa sugerencia estará en línea con mis gustos literarios (confianza, valor añadido) y no será dada porque ese sea el libro que más margen le esté dando al librero ese mes (cultura del pelotazo).

Pero para que el proveedor pueda tener ese conocimiento y ese interés en fomentar la relación a largo plazo, le hace falta algo que tiene que aportar el cliente: lealtad y flexibilidad. La lealtad hace que “siempre vaya a comprar al mismo sitio” y la flexibilidad hace que no intente apretar al señor Manolo para que me ponga las naranjas al mismo precio que el más barato del mercado, porque el señor Manolo tiene que ganarse la vida.

Y aquí está el equilibrio necesario: el Partner tiene que poderse ganar la vida y el cliente tiene que permitírselo, al tiempo que vigila que no “se le suban los humos” y deje de ser interesante la relación.

CLIENTE PARTNER
Respeto Implicación
Lealtad Conocimiento
Transparencia Valor Añadido
Flexibilidad No excesiva ambición
Confianza Confianza

Y así, a través de este tipo de relación entre organizaciones, el cliente se beneficia de productos y servicios ofrecidos con un “extra” de valor añadido que es realmente importante (y más en estos tiempos que corren) y el partner se beneficia por tener clientes fieles que hacen de altavoz de sus excelencias.

Sobre las ventajas de la confianza y el conocimiento del cliente a la hora de proponer productos y servicios de alto valor añadido ya hablaremos en otra ocasión-

Por último, si quieres leer un poco más sobre el tema, te recomiendo los primeros capítulos de Universal Service Management Body of Knowledge (USMBOK), de Ian Clayton.

24 de febrero de 2009

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

logo Service Manager JPG.ashx 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